AIを使っていて、一番困りやすいのは性能の不足よりも 役割の混線 です。
調査をしてほしいのに書き始める。戦略を決めてほしいのに、いきなり修正に入る。公開判断まで勝手に進める。こういうズレが重なると、AIは便利でも運用は安定しません。
そこで必要だったのが、サブエージェント というより 役割ごとの担当分け でした。
この記事では、私がAIやサブエージェントに求めてきたもの、今回どう整理したか、そして次回はこの記事のURLを渡すだけで使い回しやすくする考え方までまとめます。
先に結論を言うと、サブエージェントは AIを増やす機能 ではなく、仕事を混ぜないための設計 として使うのが一番しっくりきました。
そもそも、なぜサブエージェントが必要になったのか
きっかけはシンプルで、1つのAIに全部を頼むと 進むけれど積み上がらない と感じる場面が増えたからです。
その場ではそれっぽい答えが返ってきます。
でも次の会話になると前提が抜ける。分析と執筆が混ざる。前回決めたルールが引き継がれない。結果として、毎回少しずつ同じ説明をやり直すことになります。
特に大きかったのは、次の3つでした。
- 競合差分を見ずに本文へ入りやすい
- 今回は分析をしてほしいのか、執筆をしてほしいのかが会話の流れでずれる
- 良い判断をしても、次回のAIや次のスレッドに引き継ぎにくい
要するに、単発では動くのに、運用としては弱い という状態です。
ここを変えるには、AIの性能を上げるより先に、役割と入口を固定する必要がありました。
もう1つ大きかったのは、ターミナルや1本の会話で作業していると、どうしても 今やっている1つの仕事 を順番に進める形になりやすいことです。
分析をして、そのあと戦略を考えて、そのあと書いて、そのあと整理する。これは自然な流れですが、全部を1本で抱えると途中で役割が混ざりやすくなります。
ここにサブエージェントや役割分担を入れると、分析は分析担当 方針決定は戦略担当 修正は執筆担当 のように、それぞれの仕事を役割ベースで進めやすくなります。
全部を完全に同時並行にできるというより、仕事の筋道を分けたまま進められる のが大きいです。結果として、直列作業だけに引っ張られず、全体の効率も上がりやすくなります。
たとえば Analyst は、調べて材料を集めることが役割なので、他の役割とある程度並行しやすいです。
競合差分やデータ確認だけなら、まだ本文を書かなくても進められます。だから分析担当は、本線の横で先に動かしやすい役です。
一方で Strategist は、その分析結果がないとかなり危うくなります。
何を先に直すか、どこが勝ち筋か、どこまで手を入れるべきかは、Analyst が拾ったデータや競合差分がないと当てずっぽうになりやすいからです。
同じことは Writer にも言えます。
執筆担当は、分析も戦略もないまま動くと、それらしく書けてしまうぶん逆に危ないです。何が検索意図なのか、どこが競合差分なのか、今回どこまで直すべきなのかがないと、修正はどうしても適当になりやすいからです。
つまり、役割はバラバラに独立しているのではなく、並行しやすい役 と 前の役の材料が必要な役 がある、ということです。
この依存関係が見えてくると、サブエージェントは単なる分業ではなく、仕事の順番と接続を整える設計だと分かりやすくなります。
だから、サブエージェントが必要になったというより、同じ前提を何度も作り直さなくて済む仕組み が必要になった、という言い方のほうが実感に近いです。
私がAIに求めていたのは、万能さではなく役割の明確さ
AIを触っていると、つい「全部まとめてやってほしい」と思いがちです。
でも実際に欲しかったのは、万能な1人ではありませんでした。
私が求めていたのは、次の4つです。
- まず事実と競合差分を集めること
- 何を先に直すかを決めること
- 必要な範囲だけを書き換えること
- 今どこまで終わったかを整理すること
つまり、分析 戦略 執筆 整理 です。
人のチームなら当たり前に分ける仕事を、AIにも分けてほしかったわけです。
この4つは、自分の中では 四天王 と呼ぶのがしっくりきています。
Analyst、Strategist、Writer、Coordinator の4役がそろって、ようやく流れが安定するからです。
ここで大事なのは、AIを人格分裂させたいわけではないことです。
むしろ逆で、いま何の役をやっているのか をはっきりさせたかったのです。
1つのAIで全部やると、どこがつらかったのか
1本の会話で全部やると、次のような問題が起きやすいです。
- 競合分析なしで本文修正に入る
- 優先順位を決める前に、思いつきで記事を触る
- 必要最小限の修正ではなく、全面改稿に寄っていく
- 今どこまで進んだかが曖昧になる
これはAIの能力不足というより、流れの設計不足 に近いです。
分析と判断と執筆と整理を同じ箱に入れると、人でもAIでもぶれやすくなります。
だから、今回の整理では役割を明示しました。
言い換えると、AI運用の 四天王 を決めたわけです。
| 役割 | やること | やらないこと |
|---|---|---|
| Analyst | データ確認、検索意図確認、競合1位との差分抽出 | 差分確認なしで本文を書き始めない |
| Strategist | 優先順位、勝ち筋、変更範囲を決める | 全部の記事を一度に広げない |
| Writer | 必要な範囲だけ修正し、パッチとログを残す | 全文リライトしない |
| Coordinator | STATUS更新、進行整理、公開判断 | 勝手に公開や削除をしない |
この 四天王 を置いたことで、少なくとも 今は何を求めているのか がぶれにくくなりました。
さらに言うと、この4分割は「担当を増やした」というより、起きていたズレに名前を付けた 感覚に近いです。
分析が足りないのに書いてしまう。判断がないのに作業を広げてしまう。整理役がいないので、前回の知見が消える。そうした詰まりどころを、それぞれ別の役として切り出しました。
今回、サブエージェント運用をどう整理したか
今回の整理で入れたルールは、かなり実務的です。
抽象的な「AI活用術」ではなく、ブログ改善の運用にそのまま乗る形にしました。
たとえば、こうです。
- 最初に
AGENTS.mdを読む - その次に
core_rules.mdを読む - 今回の依頼がどの役割かを判断してから動く
STATUS.mdEVALUATION_RULES.mdbrand_voice.mdを前提にする- 競合1位の差分確認なしで執筆に入らない
- 進行は
Analyst -> Strategist -> Writer -> Coordinatorの順に置く
ここで効いたのは、サブエージェントを増やしたことそのものではなく、担当の境界線を文書で固定したこと でした。
AIは、その場の流れで何でもやれてしまうからこそ、境界を置かないと簡単にはみ出します。
逆に言うと、境界線さえはっきりしていればかなり扱いやすくなります。
いまのブログ運用では、どの役割が効いているか
いまの運用では、特に Analyst と Strategist を分けたのが大きかったです。
なぜなら、ブログ改善で失敗しやすいのは「書き方」より先に「何を直すか」の判断だからです。
たとえば、表示回数は多いのにCTRが低い記事なら、本文改善ではなくタイトル改善が先かもしれません。
季節性がある記事なら、全面改稿より更新日の鮮度と導線調整が先かもしれません。
ここで Strategist だけ先に動かすと、判断はどうしても勘に寄ります。
だから、Strategist が効くというより、Analyst の材料を受け取った Strategist が効く と言ったほうが正確です。
この判断を飛ばしてWriterに入ると、がんばって書いたのに伸びない、ということが起きやすいです。
さらに言えば、Writer は Analyst と Strategist のあと だから意味があります。
競合差分と優先順位が見えているからこそ、タイトルだけ直すべきか、導入まで触るべきか、FAQまで入れるべきかを絞れます。これがないと、書けるけれど外す、という状態になりやすいです。
逆に、Coordinatorを常駐させる考え方も効いています。
これは裏方ですが、かなり大事です。
- いまどこまで終わったかを残す
- 次に誰が動くかを明示する
STATUS.mdを更新して判断を残す
この整理役がいないと、良い判断をしても次の会話で消えやすいです。
すると、前に避けたはずのミスをまた繰り返す可能性があります。分析で気づいたこと、戦略で決めたこと、執筆で学んだことが整理されていないと、次の作業はまた最初からやり直しになりやすいからです。
しかも整理は、記録のためだけにあるわけではありません。
次に見るべきファイル、次に動く役割、次に試すべき改善が整理されているだけで、作業はかなり速くなります。つまり 整理そのものが再発防止 であり、同時に 作業の高速化 でもあります。
次回は、このURLをAIに渡して使い回したい
ここから先でやりたいのは、毎回ゼロから説明しないことです。
つまり、このURLを読んでから動いてください と渡せる状態にすることです。
そのために、この記事には考え方だけでなく、次回AIに渡したい要点も入れておくのがよいと思っています。
次回AIにURLを渡すなら、最低限これが伝われば十分です。
- まず役割を決めてから動くこと
- 競合差分なしで執筆しないこと
STATUS.mdEVALUATION_RULES.mdbrand_voice.mdを前提にすること- 全文リライトではなく必要最小限の修正を優先すること
- 最後に進行状況と次アクションを明文化すること
これなら、単なる感想記事ではなく 運用ルールの参照ページ としても使えます。
URLを渡して再利用するなら、記事の役割は2つある
このページを再利用する前提で考えると、記事には2つの役割があります。
1つ目は、なぜこういう設計にしたのか を説明することです。
これがないと、ルールがただの細かい縛りに見えます。
2つ目は、次回のAIがすぐ読める要約 を置くことです。
これがないと、URLを渡しても長い記事をただ読ませるだけで終わります。
だから、ブログにするなら次のような順番が使いやすいです。
- どんな問題があったか
- 何を求めてきたか
- どう整理したか
- 次回AIに渡したい要約
- 関連リンク
記事でありながら、運用メモにもなる形です。
次回AIに渡すための要約
もし次回、別のAIや別スレッドにこのページを渡すなら、ここだけ読めばよいようにしておくと使いやすいです。
- このブログでは、AIを万能担当としてではなく
役割担当として使う - 役割は
AnalystStrategistWriterCoordinatorの四天王で考える - 最初に
AGENTS.mdとcore_rules.mdを読む - 競合1位との差分確認なしで本文修正に入らない
- Writer は必要最小限だけ直す
- Coordinator は毎回、進行状況と次アクションを整理する
これを記事内に置いておけば、次回はURLを渡したうえで、今回はStrategistとして読んでください のように短く頼みやすくなります。
サブエージェントは機能というより、運用の土台だった
今回あらためて思ったのは、サブエージェントは派手な機能というより、AI運用の土台 に近いということです。
何を分析させるのか。
誰に優先順位を決めさせるのか。
どこまで書かせるのか。
最後に誰が整理するのか。
ここが決まると、AIとの会話はかなり安定します。
逆にここが曖昧だと、どんな高性能なAIでも毎回少しずつずれます。
だから、私にとってサブエージェントは「AIを増やす話」ではなく、AIに何を求めるかを先に言語化する話 でした。
関連記事としては、ツール寄りの話を知りたい人は以下も参考になります。
関連記事:
- Claude Codeのsubagents入門。初心者が今日1体作って動かす最短ガイド
- Claude Codeのagent機能とは？いままでとの違いと簡単な使い方
- Codex Mac appの使い方を初心者向けに解説｜始め方・CLIやCursorとの違いまで
FAQ
Q1. サブエージェントは、AIを何体も同時に動かすことですか？
Q2. サブエージェントを使うと、AIの精度は上がりますか？
Q3. URLを渡して再利用したいなら、何を書いておくとよいですか？
まとめ
AIとサブエージェントについて整理してみると、欲しかったのは新しい機能より 役割の明確さ でした。
分析、戦略、執筆、整理の四天王を分けるだけでも、会話のぶれはかなり減ります。
そして、この記事をURLとして残しておけば、次回は「このページを前提にして動いてください」と渡しやすくなります。
ブログ記事でありながら、次のAIへの運用メモにもなる。そこまで含めて、今回やりたかった整理でした。
