見出し画像

「AIがあまり賢くない」と感じたら｜企画書をサブエージェントの仕事へ分けてみる ✨

CodeLab株式会社

【TL;DR】

AIへ立派な企画書を渡しても、一人のエージェントへ全工程を任せると精度が安定しないことがあります。
企画書を、調査・設計・作成・検証などの独立した役割へ分けると、必要な情報へ集中しやすくなります。
工程の難度に応じてモデルとeffortを使い分ければ、費用を抑えられる可能性もあります。
ただし、サブエージェントを増やせば必ず速く・安くなるわけではありません。
人間が各担当のルールと完了条件を確認し、分ける価値がある仕事だけを任せることが大切です。

先日、コンサル系の仕事をしている友人から「AIを使ってみたけれど、思ったほど賢くない」という相談を受けました。

そこで「サブエージェントは使っている？」と聞いてみたのですが、あまりピンときていない様子でした。

話を聞くと、友人もAIへ丸投げしているわけではありません。先に企画書のような資料を作り、それをAIエージェントへ渡して作業させています。

これは間違った使い方ではありません。わたしも最初に指示書を作ります。

それでも結果に差が出る理由は、企画書を作ったあとの工程を、どこまで具体的な仕事として見ているかにありました。

👀 同じ企画書でも見えている景色が違う

コンサルタントの友人は、目的、対象顧客、課題、施策、期待効果など、仕事の最上流をきれいに整理します。その企画書を一人のAIエージェントへ渡し、「これを完成させて」と依頼します。

上流設計としては筋が通っています。しかし、企画書と完成品の間には、多くの見えにくい作業があります。

たとえば新サービスの提案資料なら、次のような工程です。

  • 市場データと一次情報を探す

  • 顧客像と利用場面を具体化する

  • 主張を支える根拠を確認する

  • 資料の構成を設計する

  • 各ページの文章を書く

  • 数字や論理の矛盾を検証する

  • 読み手の立場からレビューする

プログラマは普段から、大きな仕様を画面、API、データ、テストなどへ分けます。一つの処理を関数やモジュールへ分解し、入力と出力を決め、最後に接続します。

その癖があるため、わたしは企画書をAIへ渡したあとも、工程を小さな役割へ分けます。調査担当、構成担当、作成担当、検証担当をサブエージェントとして設計し、それぞれのルールを一度自分で読み、調整します。

企画書はゴールを示します。サブエージェント設計は、ゴールへ到達する仕事の分担を示します。

🧠 なぜサブエージェントへ細分化するのか

不要な履歴を親の会話へ残さない

調査では大量の検索結果や資料を読みます。テストでは長いログが出ます。それらを同じ会話へ積み上げると、作成や最終判断の段階でも古い試行錯誤が残ります。

Claude Codeの公式ドキュメントでは、通常のサブエージェントは新しい独立コンテキストで始まり、大量の出力をその中で処理して、要約だけを親へ返せると説明されています。

Claude Code公式ドキュメント

https://code.claude.com/docs/en/sub-agents

ここで「コンテキストは小さいほどAIが賢くなる」と単純化するのは正確ではありません。必要な情報まで削れば、当然判断を誤ります。

大切なのは、今の仕事に関係する情報の密度を高めることです。調査担当には調査条件、文章担当には確定した構成、検証担当には主張と出典を渡します。

失敗箇所と責任範囲が分かりやすい

一人のAIが調査から完成まで行うと、結果が悪いときに原因を特定しにくくなります。根拠が悪いのか、構成が悪いのか、文章化で意味が変わったのかが混ざるからです。

役割ごとに成果物と完了条件を決めれば、どこから直すべきか分かります。うまくいった担当は再実行せず、失敗した工程だけ交換できます。

独立した仕事を並列に進められる

競合調査、公式資料の確認、想定読者の課題整理など、互いの途中結果を待たない仕事は並列化できます。

順番に一時間ずつ行う仕事を同時に始められれば、完了までの時間を短くできます。ただし、三人分のAIが動くため、処理時間が短くなっても総トークンまで減るとは限りません。

役割ごとに道具と権限を絞れる

調査担当にはWeb検索だけ、文章担当には原稿ファイルの編集だけ、検証担当には読み取りだけを許可する、といった分離ができます。

サブエージェントは単なる「別人格」ではありません。固有のシステムプロンプト、利用できるツール、権限を持たせられます。役割に不要な道具を見せなければ、誤操作やツール選択の迷いも減らせます。

専門ルールを再利用できる

「一次情報を優先する調査担当」「数字と引用を照合する検証担当」のルールは、次の企画でも使えます。一度人間が確認して調整すれば、属人的なコツを再利用可能な作業手順へ変えられます。

工程ごとにモデルとeffortを選べる

サブエージェントごとに、使うモデルやeffort（考える深さ）を変えられる仕組みもあります。たとえば、曖昧な企画判断や重要な設計は高性能なモデルと高いeffortへ任せ、入力・出力・正解条件が明確な整形や抽出は、軽量なモデルや低いeffortで試せます。下流工程には定型作業が増えやすいため、全工程を最高設定で動かすより費用を抑えられる可能性があります。

ただし「下流なら必ず低性能でよい」わけではありません。公開前の事実確認、セキュリティ、法務のように失敗の影響が大きい仕事には、強いモデルが必要です。工程名ではなく、曖昧さ、失敗時の影響、結果を機械的に検証できるかで選び、実際の成果を比べて調整します。

Claudeのeffort公式ドキュメント

https://platform.claude.com/docs/en/build-with-claude/effort

❌ 企画書をそのまま一人へ渡すだけでは足りない

NG例

添付した企画書をもとに、競合調査、提案内容の設計、
資料作成、事実確認、レビューまで行い、完成版を作ってください。

ゴールは分かりますが、どの工程で何を根拠に判断し、何ができれば完了なのかが曖昧です。長い作業の途中で前提が変わっても、最後の成果物だけを見るまで気づけません。

⭕ 親エージェントを現場監督にする

わたしなら、企画書を受け取る親エージェントを「現場監督」にします。親は全部を自分で処理せず、仕事を分け、必要な担当だけを呼び、成果物を統合します。

たとえば次の四役です。

  1. 調査担当：一次情報を集め、事実と推測を分ける

  2. 設計担当：企画書と調査結果から構成を作る

  3. 作成担当：確定した構成に沿って成果物を作る

  4. 検証担当：根拠、数字、論理、要件漏れを確認する

このとき、名前だけ付けても不十分です。各担当について、役割、入力、使える道具、禁止事項、成果物、完了条件を人間が確認します。

特に重要なのは、サブエージェントのルールを一度直接読むことです。「調査担当だから調査はできるだろう」と任せず、情報源の優先順位、出典の残し方、確認できない事実の扱いまで調整します。

📝 実際に使えるAIチーム設計プロンプト全公開

# 役割
あなたは、企画書を実行可能なAIチームへ変換する作業設計者です。

# 目的
以下の企画書を分析し、一人のエージェントへ全工程を任せず、
必要な作業単位とサブエージェントを設計してください。

# 設計ルール
- まず単一エージェントで十分な作業か判断する
- 分ける場合は、各担当の目的を一つにする
- 各担当の入力、参照資料、ツール、権限を明記する
- 成果物の形式と完了条件を明記する
- 独立して進められる作業だけ「並列可」とする
- 大量の検索結果やログは担当内で要約し、親には要点だけ返す
- 担当間で共有が必要な決定事項を明記する
- 各担当の推奨モデルとeffort、その理由を示す
- 工程名ではなく、曖昧さ・失敗時の影響・検証しやすさで設定を選ぶ
- 最後に統合担当と、人間が確認する承認ポイントを置く
- サブエージェントを増やす利益が起動・統合コストを上回らない場合は分けない

# 出力
1. 全体の作業工程
2. サブエージェント一覧
3. 各担当のルール案
4. 並列実行できる組み合わせ
5. 依存関係
6. 人間が直接確認すべき項目
7. 単一エージェントのまま残す作業
8. 各担当の推奨モデル・effortと切り替え条件

# 重要
この段階では実行しないでください。
人間が各担当のルールを確認・修正してから実行します。

# 企画書
ここに企画書を貼り付ける

OpenAIのエージェント設計ガイドも、まず単一エージェントを十分に使い、複雑な条件分岐や似たツールが増えて不安定になったときに複数へ分けることを勧めています。

OpenAI公式ガイド

https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

⚠️ サブエージェントを増やしすぎない

サブエージェントは、AIを無条件に賢くする魔法ではありません。

新しい担当は親の会話履歴を知らないため、必要な前提を委譲文へまとめる必要があります。共有事項が多い作業を無理に分けると、同じ説明を何度も読み直し、結果の統合にも時間がかかります。

分割に向くのは、大量の出力を隔離したい仕事、独立して調査できる仕事、専用の道具や権限を持たせたい仕事、成果物と完了条件を明確にできる仕事です。

反対に、短い修正、頻繁な相談が必要な仕事、前工程の細かな判断を共有し続ける仕事は、一人のエージェントで進めたほうが速いことがあります。

人数を増やすのではなく、責任を分ける価値がある場所だけ分ける。

✅ まとめ：AIの能力を疑う前に仕事の渡し方を見る

コンサルタントの友人とプログラマのわたしは、どちらも先に企画書を作っていました。違いは、その先です。

友人は企画書を一つの完成した依頼として見ていました。わたしは、その中に調査、設計、作成、検証という別々の仕事を見ていました。

  • [ ] 企画書と完成品の間の工程を洗い出したか

  • [ ] 独立できる仕事だけをサブエージェントへ分けたか

  • [ ] 各担当へ必要なコンテキストだけを渡したか

  • [ ] ツール、権限、禁止事項を役割ごとに絞ったか

  • [ ] 各担当のルールを人間が直接確認したか

  • [ ] 難度とリスクに合うモデル・effortを選んだか

  • [ ] 完了条件と統合方法を決めたか

  • [ ] 分割コストが利益を上回っていないか

「AIが賢くない」と結論づける前に、一人へ会社全体の仕事を渡していないか確認してみよう。

他の記事もぜひ読んでみてください 😊👇
https://note.com/codelab_hwata

いいなと思ったら応援しよう！