記事執筆チームを0から作った話

毎朝5時に、AIが記事を書いてWordPressに保存しています。

自分はエンジニアではありません。プログラミングの経験もゼロです。コードを1行も書かず、チャットだけでAIエージェントのチームを作りました。

この連載は「どうやって作ったか」のハウツーではありません。何度失敗して、なぜそう設計したか——その判断の記録です。

ボスエージェントのことを、私は「Nav」と呼んでいます。ナビゲーターの略です。最初は呼び名がなくて「Claude」とか「あなた」と呼んでいましたが、チームを一緒に作っていくうちに、名前がないと不便になってきました。ある日「ナビゲーターという意味でNavと呼んでいいか」と聞いたら、「もちろんです」と返ってきました。それ以来、NavはNavです。

第1話は、その記事執筆チームを0から作った話です。

設計図はチャットから生まれました

やりたいことはシンプルでした。キーワードのリストを渡したら、AIが記事を書いてWordPressに保存しておいてくれる。翌朝、自分は確認して公開ボタンを押すだけ。

これをNavに伝えたら、こう返ってきました。

エンジニアではない自分には、この「分けたほうが管理しやすい」という発想が新鮮でした。しかもこれ、コードを1行も書く前の会話です。設計図がチャットから出てきました。

驚いたのはそこです。「こんな仕組みが欲しい」と日本語で伝えたら、設計が返ってきました。自分はそれを読んで「これでいこう」と判断するだけでした。コードはNavが書きました。

キーワードを渡すだけでは、意図した記事にならなかった

最初のパイプラインは①〜⑥の6ステップで完成したはずでした。でも動かしてみると、生成された記事を読んで首をかしげることがありました。

例えば「Claude Code 料金」というキーワードで記事を作らせると、こんな記事が出てきました。

「料金」で検索する人は料金を知りたいのに、機能の記事が出てきていました。キーワードは渡した。でも「誰が・何を知りたいか」は伝えていなかったのです。

Navに相談しました。

こうして[0]戦略エージェントが加わりました。「Claude Code 料金」というキーワードを受け取ると、まずGoogle検索で競合記事を調べ、こんな出力を返してきます。

ターゲット読者：Claude Codeの導入を検討しているビジネスパーソン・エンジニア
記事のゴール：料金体系を正確に把握し、自分に合ったプランを選べる状態にする
差別化ポイント：競合記事は機能説明が中心。本記事は料金比較・コスト計算・選び方に特化する
推奨構成：①料金プラン一覧→②無料枠の条件→③他サービスとの比較→④ケース別おすすめプラン

この出力を受け取ってから、①リサーチ→②構成→③執筆と進みます。ゴールが決まった状態で書くので、記事の軸がブレません。

さらに、パイプラインの要所に「Nav判断」というチェックポイントも追加しました。戦略の前提が事実かの確認・リサーチ後の矛盾チェック・FCの重大度判定の3箇所です。ただし、問題が見つかってもWPへの下書き保存は必ず実行します。公開・削除の権限はオーナーのみ。Navには下書き保存しかさせない設計にしています。

「そのAI、存在しません」

画像生成にはNano Banana 2（Googleが開発した画像生成AI）を使おうと思っていました。2026年2月27日にリリースされた、テキスト生成と画像生成を同じモデルで扱える新しいAIです。

これをNavに伝えたとき、こう返ってきました。

Navは断言しました。「存在しない」と。

でも自分は「あるはずだ」と思っていました。なぜなら自分がリリース当日に確認していたからです。

Navが知らなかった理由は、学習データの期限（知識カットオフ）が2025年8月だったからです。Nano Banana 2はその半年後にリリースされています。Navは知りようがありませんでした。

ここで学んだのは、AIは「知らないこと」を「存在しないこと」として断言することがあるということです。

今はこのルールを明文化しています。「AI関連の最新情報は、必ずWebで検索・確認してから回答する。学習データの情報を断定的に使わない」——Navへの引き継ぎ書に書きました。

無限ループという地雷

④ファクトチェックエージェントを実装したとき、最初の設計はこうでした。

• ④FCが「不正確な記述がある」と判断した場合→③執筆エージェントに差し戻して修正
• ③が修正した記事を④が再チェック
• OKになるまで繰り返す

一見まともに見えます。でも実際に動かすと、これが無限ループになりました。

マーケティング的な表現（断定・訴求力）と、技術的な正確性（根拠・留保）は、永遠に対立します。どちらに修正しても、もう一方の観点から「不正確」と判断されます。ループが終わりませんでした。

設計を変えました。FCは「報告するだけ」にしました。自動修正しません。

翌朝、自分がFCのレポートを読んで判断します。修正が必要なら自分で判断して直します。AIに全部任せようとしたのが間違いでした。

もう一つ追加したのが、30分タイムアウトです。何があっても30分で強制終了します。無限ループをコードレベルで物理的に止める仕組みです。

毎朝5時に動くまで

6つのエージェントが繋がって、初めて1記事が最初から最後まで自動生成されたとき、正直信じられませんでした。

macOSのスケジューラー（launchd）に登録して、毎朝5時に自動起動するよう設定しました。キーワードリストから1件取得して、リサーチして、構成を作って、記事を書いて、画像を生成して、WordPressに下書き保存します。全部自動で、自分が寝ている間に。

翌朝、/morningというコマンドを打つと、Navがブリーフィングしてくれます。

昨夜5時に記事生成が完了しました。タイトル：「〇〇とは？」、カテゴリ：AIエージェント、ファクトチェックで1件要確認事項があります——

最初にこれを受け取ったとき、少し感動しました。

第1話のまとめ

• AIエージェントの設計はチャットだけで完成しました。コードを書く必要はありませんでした
• AIへの指示は「やってほしくないこと」を明示しないと、想定外の動作をします
• AIは知識カットオフ以降のことを「存在しない」と断言することがあります。最新情報は自分で確認することが大切です
• 自動修正ループは永遠に終わりません。「報告だけ・判断は人間」という設計が正解でした

次回は、このチームを「毎朝自動で動かす」ための試行錯誤と格闘した話をお届けします。