Claude Codeのエージェントチームを会議させてみた。ライターAIが下書きの事実ミスを見つけてくれた

Claude Codeのエージェントチームを会議させてみた。ライターAIが下書きの事実ミスを見つけてくれた

今日の発見:会議型ワークフローを動かしたら、エージェントが私より先に事実を確認してくれた。

このブログを始めたとき、最初から思っていたことがあります。

エージェントを、本物のチームとして動かしたい。

記事化エージェント、SEOエージェント、デザインエージェント、ライティングエージェント——それぞれに役割を与えて、毎日少しずつ磨いてきました。

でも、ずっと気になっていたことがありました。

「みんな順番に動いているだけで、議論していない」

人間のチームを見ていると、意見を持った人同士が議論することで、良いものが生まれます。

それをAIエージェントでできないか。

そう思ってClaude Codeに相談したのが、今日の話の始まりです。


目次

① ずっと気になっていたこと

エージェントたちは、それぞれ良い仕事をしてくれています。

SEOエージェントはキーワードを提案してくれます。

デザインエージェントはブロックの使い方を教えてくれます。

ライティングエージェントは文体を整えてくれます。

でも、私はいつも「順番に聞いて回る」側でした。

SEOエージェントに聞いて、次にデザインエージェントに聞いて、結果を自分でまとめる。

これはチームではなく、「個別に話を聞く」作業です。


② 設計した仕組み:2フェーズの会議型ワークフロー

Claude Codeと相談して、「会議型ワークフロー」を設計しました。

全体の流れはこうなっています。

ステップ担当やること
フェーズ1読者エージェント専門用語を検知 → 私が補足説明を考える
フェーズ2SEO・デザイン・ライティング下書きをそれぞれ独立して診断
集約編集長エージェント全診断をまとめて修正依頼書を作成

2つのフェーズを順番に説明します。


STEP
フェーズ1:読者エージェント

まず新しいエージェントを作りました。「読者エージェント」です。

会議型ワークフローを設計するとき、「エージェントの視点だけでは読者のことが抜け落ちるのでは」と思いました。

正確な読者の視点を再現するのは難しい。

でも、少なくとも「専門用語でつまずいて内容が入ってこない」という状況は防げるはずです。

読者に内容を理解してもらいたい——その想いから、会議の前段として読者エージェントを追加することにしました。

このエージェントの役割は1つ——「記事の中で説明されていない専門用語を見つける」こと。

ターゲット読者(AIもブログも初めての非エンジニア)が読んで、置いてけぼりになりそうな言葉を拾い出します。

私に「どう説明しますか?」と聞いてきます。

私が答えると、下書きに補足説明として加えられます。

✏️ ペンブロックとは?

このブログで使っているWordPressのSWELLというテーマに入っている機能で、「✏️」マークつきの説明ブロックのこと。記事の中で専門用語や補足説明を、目立つ形で挿入するために使っています。まさにこれがそうです。

STEP
フェーズ2:会議型(疑似並列)

フェーズ1が終わって、補足説明が加わった下書きを使います。

SEOエージェント、デザインエージェント、ライティングエージェントの3つが、同じ下書きをそれぞれ独立して診断します。

ポイントは、各エージェントには下書きしか見せないこと。

他のエージェントの意見を見せないことで、それぞれが独立した視点を保てます。

3つの診断が出揃ったら、編集長エージェントが集約して「修正依頼書」を1本にまとめ、記事化エージェントに渡します。

③ 実際に動かしてみた

今日の実験には、「SEOエージェントをデータで動かすために、GSCと連携した話」という下書きをサンプルに使いました。

読者エージェントがまず動きました。

「GSC、API、インデックス、メタディスクリプション、Google Cloud——これらについて読者向けに説明が必要です。どう説明しますか?」

私がそれぞれについて答えると、下書きに補足説明ブロックが加わりました。

こんな言葉で答えました。

こんな言葉で

SEOは「お店の看板の出し方」。

メタディスクリプションは「本の裏表紙のあらすじ」。

APIは「免許証のようなもの」。

読者エージェントが終わると、フェーズ2の会議型に移りました。

SEO・デザイン・ライティングの3エージェントが、順番に診断を出しました。


④ 予想外のことが起きた

会議が進んでいたとき、ライティングエージェント(この記事のタイトルでは「ライターAI」と表記しています)からこんな指摘が出ました。

サンプルに使っていた下書きには、ラッコキーワードの自動化ツールが有料プランでしか使えないとわかった場面があります。その箇所には、こう書かれていました。

(下書きより)
ラッコキーワードのMCPを使えば自動でリサーチできるとわかりました。
でも、月2,475円〜の有料プランが必要です。
悔しかったです。

ライティングエージェントはこの部分を読んで、こんな指摘を出しました。

悔しかったです」という表現がありますが、事実メモにはその感情の記述がありません。アイビーさんが実際にそう感じていたか確認をお願いします。

正直に言うと、驚きました。

私はそのとき「悔しい」という感情を持っていませんでした。

実際は「有料でやればできるのか!」という発見に近い感覚で、むしろ知的好奇心の方が近かった。

でも、表現の修正以上に、感じるものがありました。

なぜこれが「感動」だったか。

これまでも、事実確認はしていました。

下書きができたら私が読んで、事実と違う表現があれば自分で指摘して修正してもらう。その繰り返しでした。

今回も最終的には同じことが起きていたはずです。

でも今回は違いました。

私が読む前に、エージェントが自ら気づいて確認を求めてきた。

それが初めてのことでした。

このブログでずっと気になっていたのは、エージェントに下書きを書いてもらうと、「私が言っていない言葉」が混じることでした。

AIは「この文脈ならこういう感情のはずだ」と推測して書くことがあります。

それが自然に聞こえる文章であればあるほど、気づきにくい。

今日のライティングエージェントの指摘は、その問題に初めて改善の兆しが出た瞬間でした。


⑤ 今日わかったこと

ニュアンスの違いは、まだ出てくる

今日1回動かしただけで、すでに1件見つかりました。

これからも、「私が言っていない言葉」は混じり続けるはずです。

でも、それを拾う仕組みができた。

ライティングエージェントには「学習記録」の仕組みがあります。

今日のフィードバック——「悔しかったという表現は事実と違った」——が記録として残り、次の記事のときに活きてきます。

1回の会議で終わりではなく、動かすたびに少しずつ精度が上がっていく仕組みができた。

そのことが今日、いちばん大きな収穫でした。

今日の発見は、そのままエージェントの学習記録に残しました。

次の記事のブレインダンプから、感情の確認が入るようになります。

それが実際に機能するかどうか——それが次の確認です。


まとめ

1回の会議で、ずっと気になっていた問題に改善の兆しが出た。動かすたびに精度が上がっていく仕組みができました。

今日やったことを振り返ります。

  • 会議型ワークフローを設計・実装して、初めて動かした
  • 読者エージェントが専門用語を拾い、私が例え話を考えて補足説明を加えた
  • ライティングエージェントが「悔しかった」という事実と違う表現を見つけて、確認を求めてきた
  • ずっと気になっていた「私らしくない表現が混じる問題」に、改善の兆しが出た

ぜひまた読んでいただけると嬉しいです。


よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

50代・AI初心者がClaude Codeを使いながらブログ副業に挑戦中。失敗もつまずきも全部記録していきます。一緒に歩んでいきましょう!

目次