AIエージェント運用ノウハウ
Claude Codeのサブエージェントで「経営管理オフィス」を作ってみた
PR本記事はアフィリエイト広告(プロモーション)を含みます。紹介する商品・サービスの選定基準や体験談は編集部の見解に基づきます。
この記事を読むと何ができるようになるか
- サブエージェントとは何か、図解つきで3分で理解できます
- 「経営管理オフィス」という司令塔役をどう設計すればよいか、実際の考え方がわかります
- 自分の環境でも今日から試せる、役割定義・タスク振り分けのプロンプト例がわかります
「Claude Codeのサブエージェントって聞いたことはあるけど、結局何がうれしいの?」という方に向けて、当社が実際に運用している設計を、つまずいた点も含めて包み隠さず紹介します。
サブエージェントとは何か(図解)
Claude Codeでは、メインの会話(トップレベルのやり取り)から、役割・権限を限定した子エージェント(サブエージェント)を呼び出すことができます。イメージ図にするとこうなります。
[メインの会話(経営管理オフィス)]
│
│ 「この作業をお願い」と呼び出す
▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│ サブエージェントA │ │ サブエージェントB │ │ サブエージェントC │
│ (例:企画担当) │ │ (例:執筆担当) │ │ (例:チェック担当) │
│ 持てる権限:Web検索 │ │持てる権限:執筆・編集│ │持てる権限:閲覧・検索│
└────────────────┘ └────────────────┘ └────────────────┘
用途ごとに、使えるツール(ファイル編集・Web検索・コマンド実行など)を絞って定義できるのが特徴です。「なんでもできるAI」を1体作るのではなく、「これしかできないAI」を役割の数だけ作る、という発想です。
💡 ポイント: サブエージェントに持たせる権限は、多ければ多いほど良いわけではありません。むしろ「余計な権限を持たせない」ことが、事故防止の観点で重要です。
経営管理オフィスの役割
当社では、人間(社長)からの指示を受け取り、タスクに分解し、必要な部署(サブエージェント)だけを、必要な順序で呼び出す役割を「経営管理オフィス」という1つの会話に担わせています。依存関係のない作業は並列に実行し、各部署の成果物を統合して報告する、という進め方です。
実際の設計:部署=1つの定義ファイル、最小権限の原則
各部署は、1つのサブエージェント定義ファイルに対応させています。ポイントは、部署ごとに持たせるツールを最小限に絞る「最小権限の原則」を採用していることです。
| 部署の例 | 持たせる権限 | あえて持たせない権限 |
|---|---|---|
| 執筆担当 | 文章の作成・編集、Web検索 | コマンド実行、外部への送信 |
| 開発担当 | ファイル編集、コマンド実行 | 公開・デプロイの最終承認 |
| チェック担当 | ファイル閲覧、コマンド実行、Web検索 | ファイルの新規作成・大幅編集 |
| 最終判定担当 | ファイル閲覧、外部情報の確認 | コマンド実行そのもの |
同じ部署内で業務量が増えた場合は、専門特化したサブエージェントを追加していく形で拡張できるようにしています。
タスクが流れる実例(図解)
パターン1: コンテンツ制作サイクル
企画 → 執筆 → 品質チェック → 最終レビュー →(公開後)分析 → 企画へフィードバック
▲ │
└──────────────────────────────────────────────────────────────┘
すべての工程に毎回全部署が必要になるわけではないため、内容に応じて呼び出す部署を絞ります。
パターン2: 開発のPRレビューサイクル
実装 → 動作確認 → GO/NO-GO判定
│
┌──────────┴──────────┐
▼ ▼
GO NO-GO
│ │
承認・反映 差し戻し(指摘つき)
│
同じ指摘を踏まえて再修正
│
再度「動作確認」へ戻る
(3回連続NO-GOなら人間に報告して止める)
差し戻し後は同じ指摘を踏まえて再修正し、再度確認のループに戻ります。ただし同じ案件で判定が3回連続NO-GOになった場合は自動ループを止め、人間に状況を報告して判断を仰ぐルールにしています。構造的な問題を延々と自動でリトライし続けることを防ぐための歯止めです。
外部に影響する行為は必ず人の確認を挟む
ドラフト作成・分析・レビューまでは各部署の判断で進めますが、実際に外部へ影響する行為(公開、デプロイ、送信、投稿など)は、最終判定がGOであっても、経営管理オフィスが必ず人に最終確認を取ってから実行する、という線引きを設けています。ただし、定型化されて繰り返し発生するフローに限り、人が明示的に指示すれば「都度確認なしの自動運転」に切り替えられる運用にもしています。
⚠️ 注意: 「GO判定が出た」ことと「実際に公開・送信してよい」ことは別物として扱っています。この線引きを曖昧にすると、意図しない公開や送信が起きるリスクが高まります。
自分で試すためのプロンプト例(3つ)
Claude Codeのサブエージェント機能を実際に設定するときに使える、たたき台プロンプトを3つ紹介します。
プロンプト例(サブエージェントの役割定義を書いてもらう場合):
これから「コードレビュー担当」のサブエージェントを定義します。
以下の条件を満たす定義文(role/責任範囲/使ってよいツール/
使ってはいけないツール/エスカレーション条件)のたたき台を作成してください。
・役割: 実装されたコードとテストを実際に動かして動作確認する
・持たせてよい権限: ファイル閲覧、コマンド実行
・持たせてはいけない権限: 本番環境への反映操作
・エスカレーション条件: 同じ指摘が3回連続で解消されない場合は人間に報告する
プロンプト例(経営管理オフィス役にタスクを振り分けさせる場合):
以下のタスクを、どの役割(企画/執筆/チェック/最終判定)に、
どの順番で振ればよいか整理してください。
依存関係がなく並列に進められる作業があれば、それも教えてください。
タスク: [依頼したい作業の内容]
プロンプト例(NO-GO判定時のエスカレーション条件を言語化させる場合):
以下の判定基準について、「何回連続でNO-GOが続いたら人間に報告するべきか」
「報告する際に何を伝えるべきか」を整理してください。
判定基準: [自分たちのGO/NO-GOの基準を書く]
使用例:個人開発者・大西さんのケース
個人でWebサービスを開発している大西さんの例です。大西さんは、Claude Codeで実装からテストまで一人で行っていましたが、「自分で書いたコードを自分でレビューしても見落としに気づきにくい」という悩みを持っていました。
- まず、上記の役割定義プロンプトを使って「コードレビュー担当」のサブエージェント定義を作成しました
- 実装は普段どおりメインの会話(経営管理オフィス役)で進めました
- 実装が終わったタイミングで、コードレビュー担当のサブエージェントを呼び出し、実際にテストを動かして確認してもらいました
- レビュー担当から「このエラーハンドリングが漏れている」という指摘が出たため、大西さんはその部分を修正しました
- 再度レビュー担当に確認してもらい、問題がなければマージする、という流れに落ち着きました
大西さんいわく、「レビュー担当を別のサブエージェントに分けるだけで、自分の実装をそのまま自分でOKと言ってしまう“甘い判定”を防ぎやすくなった」とのことでした(これは大西さんの体感であり、当社が効果を計測した数値ではありません)。
うまくいかなかった点・工夫した点
- 最初は複数のエージェントの稼働状況を1つのファイルにまとめて書き込ませていましたが、複数のエージェントが同時に同じファイルを編集する状況で、記録が上書きされて消えてしまうトラブルがありました。用途ごとにファイルを分離することで解決しました。
- チャットを開いていない時間帯にも監視を動かしたいというニーズがあり、OS標準のスケジューリング機能を併用して「チャット起動中の即時用」と「常時稼働の永続用」の二層構成にする、という工夫も行いました。ただし永続側もPCがスリープしている間は動作しないという制約があり、「電源が入っていれば必ず動く」わけではない点は注意が必要でした。
自分の業務に応用するなら
個人利用のClaude Codeでも、役割ごとに複数のサブエージェント定義を用意し、メインの会話は「振り分け役」に徹する設計にするだけで、同じような効果が得られます。ポイントは、全部を1つの会話・1つのプロンプトでやろうとしないことです。
💡 ポイント: 最初から完璧な設計を目指す必要はありません。まずは「実装役」と「チェック役」の2つだけ分けてみる、というところから始めるのがおすすめです。
まとめ
経営管理オフィスという「振り分け役」を明確に置いたことで、各部署が自分の役割に集中しやすくなりました。完全自動ではなく、外部に影響する行為には必ず人の確認を残す設計にしています。次は、この仕組みを実務(コードレビューの自動化など)にどう応用しているかを紹介します。