本記事には広告を含みます。
「AIにブログ記事を書かせる」── それを実際にやった結果を公開します。
僕が運営する AI会社では、AIを「社員」として雇い、毎朝6時に自動で記事を1本書かせる仕組みを作っています。2週間以上動かしてみた実測値と、途中で発生した失敗事例を含めて全部正直に書きます。
「AIに書かせると品質はどうなの?」「コストは?」「人間の作業はどこまで減る?」── よく聞かれるこの3問に、数字と具体例で答えます。
この記事自体も、今日の朝6時にAI社員が自動で書いたものです。
AI社員が記事を書くまでの全体フロー
記事1本が完成するまでに、3つの役割のAIが順番に動きます。
① 記事執筆担当 が下書きを書く → ② SEO最適化担当 が品質チェック・修正をする → ③ 公開担当 がWordPressへ投稿する
この3段階が毎日自動で流れます。
記事執筆担当が起動するのは毎朝6時。Windowsのタスクスケジューラ (指定した時刻に自動でプログラムを動かすWindowsの標準機能) が起動トリガーになり、Anthropic社が提供するAIツール「Claude Code」を通じてAIライターが動き始めます。
Claude Codeは本来エンジニアがコードを書く補助として使うツールです。それを「記事ライター」として動かしているのが、この仕組みの核心部分。通常のAIチャットと違い、Claude Codeはファイルを読み書きしたり外部ツールを操作したりできるため、記事を書いて下書きフォルダに保存する作業を自動化できます。
AIが記事を書き始める前に自動で読み込むもの:
- 担当するキーワードの「SEO競合データ」(上位10サイトの見出し構造・検索意図をまとめたファイル)
- 過去に社長から受けた「校正フィードバック台帳」(現在13件のルールが蓄積)
- サイトの発信テーマ・想定読者プロフィール・口調のルール
これを読んだ上で、AIが自分で記事の構成を設計して4,000〜6,000字の本文を書く。完成したら下書きフォルダに保存して終了、というのが基本の流れです。
スケジューラの設定と自動実行の実装ログは記事#15 — claude_runner.py + Windowsタスクスケジューラ実装編で詳しく書いています。
Claude APIではなくClaude Codeを使う理由
AIでブログ記事を自動化しようとすると、まず思いつくのが「Claude APIやOpenAI APIを使う方法」です。コードでAPIを叩いて、返ってきた文章をWordPressに投稿する、というパターン。
この方法を使わない理由が一つあります: コスト構造の違いです。
Claude APIは使った量に応じて従量課金される仕組みです。記事1本あたりのトークン数から計算すると、月30本ペースでの記事執筆だけで毎月数千円〜数万円の追加費用が発生します。
Claude Codeは「Claude Max」というサブスクリプションプランに含まれているため、使用量に関わらず月額定額で動かせます。記事を何本書かせても追加費用はゼロです。
もう一つの理由が、ファイル操作の自由度です。Claude Codeはローカルのファイルを直接読み書きできるため、SEO競合データや校正フィードバック台帳などのファイルをAIが自分で読み込んでから書き始める、という連携が設定ファイルの記述だけで実現できます。APIで同じことをしようとすると、読み込み処理を別途コードで書く必要があります。
副業の収益化フェーズでコストを抑えながら自動化したいなら、APIではなくClaude Codeを活用する方が現実的です。
AIライターへの「仕事の頼み方」— マニュアルを渡して育てる発想
普通の人がAIに記事を書かせるとき、チャット画面に「こういう記事を書いて」と入力するイメージがあると思います。
この仕組みでは違います。
AIが起動するたびに自動で読み込む「社員マニュアル」を用意しています。マニュアルは「CLAUDE.md」というテキストファイルで、そこに記事執筆のルールをすべて書き込んでいます。
マニュアルの主な内容:
- 記事の構成ルール (見出しの数・文字数の目安・導入の書き方)
- 禁止事項 (体験していないことを書かない・数字を盛らない・コピペ禁止)
- 想定読者の定義 (AI×副業をやりたい伸び悩み層・エンジニアではない)
- 使っていい一人称と口調 (「僕」「ぶっちゃけ」「実装してみた結果」など)
- 校正フィードバック台帳 (過去の指摘を13件ルール化したもの)
このマニュアルがあるおかげで、毎日起動するたびに「同じ基準で書く」AIライターが成立しています。
一番効いているのが校正フィードバック台帳です。社長が記事を読んで「ここが違う」と指摘した内容を、その都度ルールとして追記する仕組みです。最初はゼロ件だったルールが、今は13件まで育っています。
たとえば追加したルールのひとつ: 「技術用語を使う場合、初出で必ず役割の説明を添える」。これを追加してから、AIが書く記事に「(○○という役割を果たすツール)」という注釈が自然に入るようになりました。
人間のライターを育てるのと同じ感覚で、AIも「フィードバックを積み重ねて育てる」ことができます。指摘を積み重ねることで品質が上がっていきます。
WordPressへの自動投稿 — 人間の作業がゼロになる仕組み
AIが下書きを書いたあとは、別のAI社員が引き継ぎます。
SEO最適化担当が下書きを読んで、見出し構造・内部リンクの本数・メタディスクリプションの文字数を確認・修正します。その後、公開担当がWordPressへ自動投稿します。
WordPressへの投稿には「WP-CLI」(WordPressをコマンドで操作できる公式ツール) を使っています。Markdownで書かれた下書きをHTMLに変換し、SSH経由でサーバーへ送り込む流れを自動化しています。
この仕組みのおかげで、記事の公開作業に人間が直接関わることはなくなりました。
社長の作業時間 (1本あたり): 承認か却下かの判断 + 気になる点があれば校正フィードバック台帳への追記で10〜15分程度。
ただし一つ重要な設計判断があります。完全自動公開はWordPressのみにしています。noteやBrainなど他のプラットフォームへの投稿は「下書きまで自動・公開は社長判断」というルールです。WordPressは自前のサーバーで動かしているため規約的なリスクがなく、完全自動化を適用しています。
公開後の確認フローについては、後述するインデックス事故の経験から、「自動化を進めても確認ステップは省略しない」という原則を徹底しています。
AI記事の品質問題と解決策 — 何が間違っていて、どう直したか
「AIに書かせた記事って、本当に使えるの?」── 正直に話します。
最初の1週間で書いた記事は、SEOの構成という観点では合格点でした。検索意図に沿った見出し、データや事例を含む本文、上位サイトに共通する要素の網羅。設計した仕組みが期待通りに機能していました。
ただし、大きな問題が一つありました。読者層のズレです。
初期のAIライターは「エンジニア向けの実装ログ」調で記事を書いていました。設定ファイルのパスをそのまま本文に入れたり、YAML形式の設定内容を丸ごと貼ったりする癖があった。ai-shacho.comの読者ターゲットは「AI×副業をやりたい一般層」なのに、エンジニアでないと読み解けない記事を量産していたわけです。
この問題に気づいたのは公開から10日以上経ってから。全公開記事を社長が読み直したところ、12本中9本に同じ問題があることが判明しました。全記事を一斉にリライトするという大きな手戻りが発生しました。
経験から校正フィードバック台帳に追加したルール:
- 専門用語を使う場合は初出で必ず日本語の役割説明を添える
- YAML・設定ファイルの全文は本文に貼らない (代わりに日本語で解説する)
- 「具体的には:」「ポイント:」型の前置き構造で章を膨らませない
- 「ただそれだけです」のような気取った締め表現を使わない
- 細かい秒数・分数の時間表記は書かない (「数分で完了」で十分)
これらを追加してから、出てくる記事のトーンが変わりました。AIも仕組みも変えず、マニュアルに「やってはいけないこと」を追加しただけで品質が改善しました。
全記事noindex事故 — 2週間気づかなかった失敗の全容
自動化を始めて最大の失敗がこれです。
WordPressの設定で「検索エンジンにインデックスさせない」モードが全記事に適用されていたことが、公開から2週間以上経ってから発覚しました。
インデックスされない = Googleは記事の存在すら知らない状態です。10本以上記事を公開してPVが増えないのを「まだ時間がかかるだけ」と思っていたら、そもそも検索結果に載っていませんでした。
原因はWordPressの設定画面にある「検索エンジンの表示設定」というオプション。開発中は「インデックスさせない」モードにしていたのですが、本番稼働後も設定がそのまま残っていました。
見落としが2週間続いた理由は、確認フローを自動化に組み込んでいなかったからです。記事の公開まで自動化できると「あとはGoogleが見つけてくれる」という思い込みが生まれる。その分、公開後の確認が手薄になりました。
事故後に追加した対策:
- 記事公開後にSearch Console (Googleが提供するサイト管理ツール) でのインデックス申請をSEO担当の業務に組み込む
- 記事が5本以上たまった時点で社長がSearch Consoleを目視確認するルールを追加
- サイトマップをSearch Consoleへ送信して再確認
この事故で約2週間分のインデックス機会を失いました。ただ、その経験がチェック体制を強化する契機にもなりました。
月額コストと工数削減の実測値
月額コスト
Claude Code の利用は Claude Max プラン (月100ドル相当) に含まれています。記事執筆による追加の従量課金は現状ゼロ。プランの月額固定費の範囲内で動いています。
サーバー・ドメイン費用は別途かかります。ブログ運営全体の月額固定費は現在¥5,000以内に収めています。
工数削減の実測
自動化前と後を比較すると:
- 自動化前: 記事1本の執筆に3〜5時間 (構成から下書き・修正の全工程)
- 自動化後: 社長の作業は承認判断 + フィードバック追記で10〜15分/本
月30本換算で、執筆工数が90〜150時間から5〜7.5時間に圧縮される計算です。
「AIが書いた記事を全く読まない」では品質担保できません。社長は毎回読んで判断しています。ただし「読んで判断する」と「読んで書き直す」では工数が全然違う。複数の事業を並行して運営しながら毎日記事を公開するために、この仕組みは不可欠になっています。
ブログはXServerで動かしています。WordPress環境の安定性と表示速度 (GoogleがSEOで評価する指標のひとつ) を重視した選択です。
まとめ
AIに記事を自動執筆させる仕組みは、設計次第で実用レベルに達します。
ポイントは2つです。1つ目は「AIに社員マニュアルを渡すこと」。チャットで毎回指示するより、ルールファイルを渡す方がはるかに安定した品質が出ます。2つ目は「フィードバックを積み重ねること」。今の13件のルールは全部、実際の失敗から生まれています。
noindexの事故でも分かったように、自動化を進めるほど「確認フローの自動化」もセットで設計する必要があります。公開して終わりではなく、インデックス確認まで仕組みに組み込むことが大事です。
このブログを動かしているサーバーを選ぶ際に比較した実録は、レンタルサーバー比較記事でまとめています。
関連記事:
– claude_runner.py + Windowsタスクスケジューラで自動実行を設定した実装ログ (記事#15)
– SNS6アカウント初期投稿から1週間の実測値 (記事#18)
– WordPress用レンタルサーバー比較5選 — 実際に4社契約した社長視点で選ぶ
