生成AIの活用は、「1つのAIに何でも聞く」段階から、「役割ごとにAIを分担させる」段階に移ってきているようです。
リサーチも、文章作成も、チェックも、全部同じAIに投げていた時代から、専門担当を並べて仕事を回す時代へ。
業界全体がそういう方向に動いている、という話をあちこちで見かけるようになりました。
ということで、今回はいよいよ自分ごとの話です。
前回の記事(WordPressとClaude Codeを連携させてみた話)で、「5つのサブエージェントを作ったが、まだ本格稼働前」という話をちらっと書きました。
実はこの記事自体が、その5エージェント体制(リサーチ・構成・執筆・画像・校正)で作られています。
前回の伏線を、今回でようやく回収できました。
サブエージェントって、そもそも何？
「専門担当のAI」に仕事を振る仕組み
「サブエージェント」とは、公式ドキュメントによると、メインの会話とは別に独立した文脈を持ち、専用のツールと専用の「システムプロンプト」を設定できるAIアシスタントのことです。
用語解説を挟みます。
「システムプロンプト」とは、サブエージェントに「あなたは〇〇の専門家として振る舞ってください」と最初に与える役割設定の文章のことです。
そして、複数のサブエージェントに指示を出し、結果をまとめる司令塔役を「オーケストレーター」または「親エージェント」と呼びます。
社長と現場チームの関係に近いですね。
社長(親エージェント)が方針を決め、現場担当(サブエージェント)がそれぞれの専門作業をこなし、社長に報告する。
そんなイメージです。
私が実際に作った5人の担当
私が構築したのは「リサーチ担当」「構成担当」「執筆担当」「画像担当」「校正担当」の5役割です。
今回の記事も、この体制で作られました。
まさにこの見出し自体が実例になっているわけですね。
設定ファイルはMarkdownで書いて、「.claude/agents/」フォルダに置くだけ。
特別なプログラミング作業は不要でした。
呼び出し方も難しくなく、「執筆担当を使って」と自然言語で頼むだけです。
このお手軽さは、正直ありがたいですね。
サブエージェントに任せるメリットと向き不向き
コンテキストを汚さない・精度が上がる
「コンテキストウィンドウ」とは、AIが一度に覚えていられる情報量の枠のことです。
サブエージェントを使うメリットは、大きく5つあります。
- コンテキストの節約(サブエージェントの作業内容が親エージェントの文脈を汚さない)
- ツール制限による誤操作防止
- 設定の使い回し(複数プロジェクトで再利用できる)
- 役割特化のシステムプロンプトによる一貫した品質
- 安価なモデルへのルーティングによるコスト削減
このあたりは、実際に使ってみて「なるほど」と思った部分です。
何でも分業させればいいわけではない
独立したリサーチや、繰り返し作業、深掘り調査などは分業に向いているタスクです。
一方で、並列実行はトークン消費が増えるという注意点もあります。
3並列で実行すると、トークン消費が約3倍になりうるとのこと。
何でもかんでも並列にすればいいというわけではなさそうです。
「Agent Teams」という、リード役が複数の協調セッションにタスクを割り振る機能もあります。
公式ドキュメントによると、これは実験的機能でデフォルトは無効とのこと、まだ発展途上という印象です。
正直、ここは今後のアップデートを待ちたいところですね。
どんな成果物ができるのか？ 具体例3つ
記事執筆・コンテンツ制作の分業
私の場合は前述の通り「リサーチ・構成・執筆・画像・校正」の5役割体制です。
他社の事例も見てみると、probl.meでは「Interview→Research→Writer→SEO Reviewer→Proofreader→Publisher」という6役割体制を組んでいるとか。
WorkTypesLabでは、1記事の作業時間が「3〜4時間」から「約15分」に短縮され、月間投稿数が「8本」から「30本」に増加したという話です。
一方で、probl.meでは実際に「未検査コンテンツの利用」といった不具合が起きた記録もあるそうです。
分業させれば安心、というわけではなく、人間のチェックはやはり必要ということですね。
私が校正担当を置いているのも、この考え方に近いです。
コードレビューを9人がかりで見る
「HAMY Blog」を運営する個人開発者の事例では、テストランナー、リンター、コードレビュアー、セキュリティレビュアー、パフォーマンスレビュアーなど、9種類の専門エージェントを並列実行して、優先度付きのサマリーを出力しているそうです。
その方の報告によると、レビュー精度が「50%未満」から「約75%」に向上したとのこと。
これはあくまで自己申告値ですが、分業の効果を示す一例として興味深いですね。
テストの計画から自動修復まで
Playwright Agentsという仕組みでは、Planner(アプリを自動探索してテスト計画書を作成)→Generator(計画書をテストコードに変換)→Healer(テスト失敗時にUIを検査し自動修正提案)という3エージェント構成をとっているそうです。
テストの世界でも、分業の流れは進んでいるようですね。
普通のチャット型AIと何が違うのか
「1問1答」と「計画→実行→検証」の違い
| 観点 | Chat型AI | Claude Code(サブエージェント対応) |
|---|---|---|
| ツール使用 | 基本は文章生成のみ | ファイル読み書き・コマンド実行・Web検索等を自律的に実行 |
| タスクの分解 | されない(1問1答) | 目標を自分でサブタスクに分解し実行・検証 |
| 会話の往復 | 毎回指示が必要 | 一度の指示で計画→実行→修正→完了まで自律的に進む |
| 作業の並列化 | 存在しない | サブエージェント等で並列実行が可能 |
| コンテキストの扱い | 1本の会話履歴がそのまま蓄積 | サブエージェントが横道作業を専用文脈で行い要約だけ返す |
こういった特性を持つAIは「エージェント型AI」と呼ばれます。
目標を自分でサブタスクに分解し、ツールを使いながら自律的に達成まで動き続けるAIのことです。
なぜチャット型AIには「サブエージェント」という発想がないのか
チャット型AIは「1つの会話＝1つの文脈」で完結する仕組みです。
ファイルシステムやターミナルへのアクセス権を持たないため、複数担当を並べて動かすという発想自体が成立しません。
この違いが、Claude Codeのようなツールとの一番の分かれ目だと感じています。
余談
実際に体制を動かしてみて、いくつか気づいたことがあります。
まず、校正担当は指摘はしてくれますが、実際にファイルを書き換える権限は持たせていません。
なので、指摘を反映するかどうかの最終判断と修正作業は、私(親エージェント側)が行う必要がありました。
「指摘だけして直接触らない」という役割分担が、かえって安全装置として機能した形です。
次に、画像担当が作った「SVG」画像を実際にサイトに使うには、「PNG」形式に変換する必要がありました。
この変換作業だけは専用の担当がいなかったので、その都度追加の手作業が発生しました。
分業してもすべてを担当に任せきれるわけではなく、担当の間を橋渡しする工程は、結局人間(または親エージェント)が担う必要があるようですね。
最後に、記事を公開する操作(WordPressへの投稿)についてです。
システム側の安全チェックによって、「下書きとして作成」までは自動で進んでも、「即座に公開」がブロックされることがありました。
結果的に「公開してよいか一度確認を挟む」という、ちょうどよい歯止めになったと感じています。
まとめ
前回の記事で「まだ本格稼働前」だった5エージェント体制は、この記事自体を制作する形で実際に動き始めました。
とりあえず、伏線回収完了です。
残っている課題もあります。
並列実行によるトークン消費の増加、Agent Teamsなど発展途上の機能があること、そして分業させても人間のチェック工程(校正担当や自分自身の確認)は依然として必要であること。
このあたりは、まだ手放しでは頼れないですね。
今後の展開に期待しています。
コメント