今日の発見:会議型ワークフローを動かしたら、エージェントが私より先に事実を確認してくれた。
このブログを始めたとき、最初から思っていたことがあります。
エージェントを、本物のチームとして動かしたい。
記事化エージェント、SEOエージェント、デザインエージェント、ライティングエージェント——それぞれに役割を与えて、毎日少しずつ磨いてきました。
でも、ずっと気になっていたことがありました。
「みんな順番に動いているだけで、議論していない」
人間のチームを見ていると、意見を持った人同士が議論することで、良いものが生まれます。
それをAIエージェントでできないか。
そう思ってClaude Codeに相談したのが、今日の話の始まりです。
① ずっと気になっていたこと
エージェントたちは、それぞれ良い仕事をしてくれています。
SEOエージェントはキーワードを提案してくれます。
デザインエージェントはブロックの使い方を教えてくれます。
ライティングエージェントは文体を整えてくれます。
でも、私はいつも「順番に聞いて回る」側でした。
SEOエージェントに聞いて、次にデザインエージェントに聞いて、結果を自分でまとめる。
これはチームではなく、「個別に話を聞く」作業です。

② 設計した仕組み:2フェーズの会議型ワークフロー
Claude Codeと相談して、「会議型ワークフロー」を設計しました。
全体の流れはこうなっています。
| ステップ | 担当 | やること |
|---|---|---|
| フェーズ1 | 読者エージェント | 専門用語を検知 → 私が補足説明を考える |
| フェーズ2 | SEO・デザイン・ライティング | 下書きをそれぞれ独立して診断 |
| 集約 | 編集長エージェント | 全診断をまとめて修正依頼書を作成 |
2つのフェーズを順番に説明します。
まず新しいエージェントを作りました。「読者エージェント」です。
会議型ワークフローを設計するとき、「エージェントの視点だけでは読者のことが抜け落ちるのでは」と思いました。
正確な読者の視点を再現するのは難しい。
でも、少なくとも「専門用語でつまずいて内容が入ってこない」という状況は防げるはずです。
読者に内容を理解してもらいたい——その想いから、会議の前段として読者エージェントを追加することにしました。
このエージェントの役割は1つ——「記事の中で説明されていない専門用語を見つける」こと。
ターゲット読者(AIもブログも初めての非エンジニア)が読んで、置いてけぼりになりそうな言葉を拾い出します。
私に「どう説明しますか?」と聞いてきます。
私が答えると、下書きに補足説明として加えられます。
✏️ ペンブロックとは?
このブログで使っているWordPressのSWELLというテーマに入っている機能で、「✏️」マークつきの説明ブロックのこと。記事の中で専門用語や補足説明を、目立つ形で挿入するために使っています。まさにこれがそうです。
フェーズ1が終わって、補足説明が加わった下書きを使います。
SEOエージェント、デザインエージェント、ライティングエージェントの3つが、同じ下書きをそれぞれ独立して診断します。
ポイントは、各エージェントには下書きしか見せないこと。
他のエージェントの意見を見せないことで、それぞれが独立した視点を保てます。
3つの診断が出揃ったら、編集長エージェントが集約して「修正依頼書」を1本にまとめ、記事化エージェントに渡します。
③ 実際に動かしてみた
今日の実験には、「SEOエージェントをデータで動かすために、GSCと連携した話」という下書きをサンプルに使いました。
読者エージェントがまず動きました。
「GSC、API、インデックス、メタディスクリプション、Google Cloud——これらについて読者向けに説明が必要です。どう説明しますか?」
私がそれぞれについて答えると、下書きに補足説明ブロックが加わりました。
こんな言葉で答えました。
SEOは「お店の看板の出し方」。
メタディスクリプションは「本の裏表紙のあらすじ」。
APIは「免許証のようなもの」。
読者エージェントが終わると、フェーズ2の会議型に移りました。
SEO・デザイン・ライティングの3エージェントが、順番に診断を出しました。
④ 予想外のことが起きた
会議が進んでいたとき、ライティングエージェント(この記事のタイトルでは「ライターAI」と表記しています)からこんな指摘が出ました。
サンプルに使っていた下書きには、ラッコキーワードの自動化ツールが有料プランでしか使えないとわかった場面があります。その箇所には、こう書かれていました。
(下書きより)
ラッコキーワードのMCPを使えば自動でリサーチできるとわかりました。
でも、月2,475円〜の有料プランが必要です。
悔しかったです。
ライティングエージェントはこの部分を読んで、こんな指摘を出しました。
悔しかったです」という表現がありますが、事実メモにはその感情の記述がありません。アイビーさんが実際にそう感じていたか確認をお願いします。
正直に言うと、驚きました。
私はそのとき「悔しい」という感情を持っていませんでした。
実際は「有料でやればできるのか!」という発見に近い感覚で、むしろ知的好奇心の方が近かった。
でも、表現の修正以上に、感じるものがありました。
なぜこれが「感動」だったか。
これまでも、事実確認はしていました。
下書きができたら私が読んで、事実と違う表現があれば自分で指摘して修正してもらう。その繰り返しでした。
今回も最終的には同じことが起きていたはずです。
でも今回は違いました。
私が読む前に、エージェントが自ら気づいて確認を求めてきた。
それが初めてのことでした。
このブログでずっと気になっていたのは、エージェントに下書きを書いてもらうと、「私が言っていない言葉」が混じることでした。
AIは「この文脈ならこういう感情のはずだ」と推測して書くことがあります。
それが自然に聞こえる文章であればあるほど、気づきにくい。
今日のライティングエージェントの指摘は、その問題に初めて改善の兆しが出た瞬間でした。

⑤ 今日わかったこと
ニュアンスの違いは、まだ出てくる
今日1回動かしただけで、すでに1件見つかりました。
これからも、「私が言っていない言葉」は混じり続けるはずです。
でも、それを拾う仕組みができた。
ライティングエージェントには「学習記録」の仕組みがあります。
今日のフィードバック——「悔しかったという表現は事実と違った」——が記録として残り、次の記事のときに活きてきます。
1回の会議で終わりではなく、動かすたびに少しずつ精度が上がっていく仕組みができた。
そのことが今日、いちばん大きな収穫でした。
今日の発見は、そのままエージェントの学習記録に残しました。
次の記事のブレインダンプから、感情の確認が入るようになります。
それが実際に機能するかどうか——それが次の確認です。
まとめ
今日やったことを振り返ります。
- 会議型ワークフローを設計・実装して、初めて動かした
- 読者エージェントが専門用語を拾い、私が例え話を考えて補足説明を加えた
- ライティングエージェントが「悔しかった」という事実と違う表現を見つけて、確認を求めてきた
- ずっと気になっていた「私らしくない表現が混じる問題」に、改善の兆しが出た
ぜひまた読んでいただけると嬉しいです。
