複数のフォルダやサービスをサブエージェントで一括調査（横断調査・棚卸し）すると、最後に集計が手作業へ逆戻りする——この記事は、それを「報告の構造化」で解く話です。
Claude Code（Anthropicの公式CLI）でサブエージェントを並列に走らせて「たくさんの対象をまとめて調べる」と、最初は気持ちよく動きます。たとえば複数のフォルダを複数のサブエージェントに割り当てて同時に調査させる（実際の同時実行数は環境やセッションの状況に依存します）——ここまでは速い。
ところが、返ってきた報告を見て手が止まります。
- ある子は箇条書き、別の子は長い散文、また別の子は表で返してくる
- 同じ「最終更新日」でも、片方は
2026-06-14、片方は「先週あたり」と曖昧 - ある子は「リスク」に触れ、別の子はその欄ごと存在しない
- 結局、親（あなた）が全部の報告を読んで、手で1つの表にまとめ直す羽目になる
並列化して調査は速くなったのに、集計が新しいボトルネックになる。これは「サブエージェントを並列で使う」記事ではあまり語られない、実務で必ずぶつかる壁です。
この記事では、筆者がサブエージェントで横断調査（多数のファイル・フォルダ・サービスの棚卸し）を自動化するなかで効いた、「報告を構造化して受け取る」型を紹介します。コードを書かせる用途ではなく、「読む・調べる・要約する」をエージェントに任せるときの話です。
原因：報告フォーマットを指定していない
並列調査がうまく集計できないのは、モデルの賢さの問題ではありません。何をどんな形で返してほしいかを指定していないのが原因です。
人間に「このフォルダ調べておいて」とだけ頼んだら、報告の粒度は人によってバラバラになります。サブエージェントも同じで、出力形式を決めなければ、各自が「良かれと思う形」で返してきます。10体が10通りの形で返せば、機械的に並べることはできません。
逆に言えば、全員に同じ「報告書のフォーマット」を渡せば、結果は揃います。
解決：報告を「決まった型」で返させる
やることはシンプルで、サブエージェントへの指示に 「この形式の項目だけを埋めて返して」 と、出力の型を明示します。
Before（自由記述・集計できない）
project/service_a フォルダを調査して、状況を報告して。
→ 返ってくるのは毎回ちがう形の散文。その数だけ読んで手で揃える羽目に。
After（型を固定・そのまま並べられる）
project/service_a フォルダを調査し、必ず次の項目「だけ」を埋めて返してください。
余計な前置き・感想は書かないこと。
- folder: フォルダ名
- last_update: 最終更新日（YYYY-MM-DD。判断できなければ unknown）
- status: 稼働 / 準備中 / 停止 のいずれか
- blockers: 前に進めない要因（無ければ「なし」）
- risks: 気づいたリスク（無ければ「なし」）
- next_action: 次に取るべき具体アクション1つ
同じ項目リストを渡したサブエージェントは、返ってくる報告が全部同じ並び。親はそれを縦に積むだけで一覧表になります。
JSONで返させるとさらに機械処理しやすくなります（
{"folder": "...", "last_update": "...", ...}の配列で受け取り、そのまま表やCSVに変換できる）。ただし項目名と「該当なしの書き方」は必ず指定してください。ここを曖昧にすると、空欄・null・「特になし」が混在して結局揃いません。
あわせて 「JSON以外は出力しない」と明示しておくと安定します。それでもモデルは前置きや ``` で囲う癖が出ることがあるので、受け取り側はパース失敗を握れるようにし（崩れたら該当エージェントだけ再実行）、コードフェンス除去などの後処理を入れておくと安全です。
なぜこれが効くのか（4つの利点）
報告を構造化するだけで、並列調査の質が変わります。
- 親がそのまま集計できる — 全報告が同じ項目なので、縦に並べれば比較表になる。親コンテキストで長文を読み直す必要がない。
-
抜け漏れが可視化される — 「判断できなければ unknown と書く」と決めておくと、調べきれなかった箇所が
unknownとして表に並ぶ。空欄で握りつぶされない。 - 粒度が揃う — 「next_action は具体アクション1つ」と縛ると、ある子が長文、ある子が一言、というバラつきが消える。
- 検証・再実行がしやすい — 後述の検証フェーズで「risks 欄だけ」を別エージェントに渡す、といった部品的な扱いができる。
特に2つ目の 「分からないことを unknown と明示させる」 は重要です。型を決めずに自由記述させると、サブエージェントは欄を埋めるために推測で断定しがちです。「ファイルから読み取れない場合は unknown と書き、推測で埋めないこと」と一文入れるだけで、それっぽい作り話を大きく減らせます（完全になくせるわけではないので、重要な項目は後述の検証フェーズで裏取りします）。
一段上：構造化した報告は、そのまま「検証」の入力になる
報告が同じ型で揃う一番の旨味は、特定の欄だけを取り出して次の工程に渡せることです。たとえば1回目の調査で集まった risks 欄だけを抜き出し、別のサブエージェントに裏取りさせる——という部品的な使い方が、構造化していると一気にやりやすくなります。
（1回目の調査で集まった risks 一覧を渡して）
次のリスク指摘について、それぞれ本当に成立するかを検証してください。
報告形式は各項目つき:
- claim: 検証対象の指摘（そのまま転記）
- verdict: 成立 / 不成立 / 判断不能
- evidence: 根拠（どのファイルのどの記述か）
コツは、検証エージェントに「成立を前提に確認」させるのではなく、**「本当に成立するか疑ってかかる」**よう促すこと。1回目の調査エージェントは「何か見つけよう」として弱い指摘も拾いがちなので、別の独立したエージェントに「不成立なら不成立と言ってよい」と検証させると、もっともらしいだけの指摘を落とせます。
ただし検証エージェントも同じLLMで、独立コンテキストでも誤判定（不成立を成立と取り違える／その逆）はあり得ます。最終判断は親（人間）が確認する前提で、あくまで「明らかに弱い指摘を機械的にふるい落とす」目的で使うのが安全です。
落とし穴：スキーマは「盛りすぎない」
構造化が効くと、つい報告項目を増やしたくなります。が、項目が多いほどサブエージェントは埋めることに気を取られ、肝心の調査が浅くなります。実務で効いたコツは次の通りです。
| コツ | 理由 |
|---|---|
| 必須項目は5〜7個までに絞る | 多いと1項目あたりの調査が浅くなる |
| 「該当なし」の書き方を指定する（例: なし / unknown） | 表記が割れると集計時に揃わない |
| 「読み取れないことは unknown。推測で断定しない」と明記 | 欄を埋めるための作り話を抑える |
| 値の取りうる範囲を例示する（status: 稼働/準備中/停止） | 自由語彙だと表記揺れが出る |
| 前置き・感想を書かないよう指示する | 余計な散文が混じると機械処理が崩れる |
まとめ
| 型 | 要点 |
|---|---|
| 報告を構造化する | 自由記述ではなく、固定した項目だけを埋めさせる |
| unknown を許可する | 分からない箇所を推測で埋めさせず、明示させる |
| 項目は絞る | 必須5〜7個。盛りすぎると調査が浅くなる |
| 検証に回す | 構造化済みの指摘を別エージェントで裏取りする |
サブエージェントの並列実行は「同時に走らせる」だけでは半分しか活きません。返ってきた結果をどう受け取るかを設計して初めて、調査から集計までを一気通貫で回せます。
まず1つだけ試すなら
全部を一度にやる必要はありません。次の調査タスクで、サブエージェントへの指示の最後にこの一文を足すだけで十分です。
報告は次の項目だけを埋めて返すこと（前置き不要）:
- 対象 / 状態 / 気づいたリスク / 次の一手
分からない項目は「unknown」と書き、推測で断定しないこと。
これだけで、バラバラだった報告が、そのまま並べて比較できる形に変わります。まずは小さな横断調査から試してみてください。
関連記事（サブエージェントシリーズ）
- 基礎編：サブエージェントを実務で使い倒す
- 第1弾：報告を「決まった型」で受け取る（本記事）
- 第2弾：“もっともらしい嘘”を独立した検証で裏取りする
- 第3弾：親のコンテキストを汚さない受け渡し
補足：試すための無料リポジトリ
サブエージェント運用の土台になるCLAUDE.md設計や、各サブエージェントに渡す計画・コミットの型を、そのまま使えるスキルとして無料リポで公開しています（個人事業主・StreamSoltyとして運営しています）。
無料スターター（GitHub・CC BY 4.0）:
https://github.com/noguso245-jpg/claude-code-skills-starter
クローンして自分のプロジェクトにコピーすればそのまま使えます。役に立ったら GitHub で ⭐ Star をいただけると、新しい無料スキルを追加する励みになります。
最新のTipsはXでも発信しています: @k___n___t_1125