複数のフォルダやサービスをサブエージェントで一括調査（横断調査・棚卸し）すると、最後に集計が手作業へ逆戻りする——この記事は、それを「報告の構造化」で解く話です。

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