survey

調査

Web、論文、ソーシャルメディア、業界から特定のトピックに関する情報源を収集し、索引付きの Markdown レポートを作成します。

このスキルは、documenting-with-sources で定義されている、出典を明記した文章の共通規則に従います。執筆を始める前に documenting-with-sources を読んでください。

品質基準

すべての情報源に適用します。

• 信頼できる情報源を優先します（査読済み論文 > 公式ブログ > 大手業界メディア > 個人ブログ）。
• 著者が個人の場合は、所属先と役職を記載します。不明な場合は調べてください。
• 論文については、書誌情報（著者、所属先、掲載先、発行年）に加えて、被引用数を記載します。
• 必ず URL を添えてください。
• 必ず日付を添えてください。
• 公式ドキュメントとサードパーティの記事は、信頼性の異なる層として扱います。混在させず、読者が違いを判別できるようにしてください。

本文の構成：主張と根拠の形式

本文は、主張と根拠の形式で記述します。まず主張を述べ、その後に根拠を示します。

1. 本文：執筆者自身の言葉で、主張または要約を最初に述べます。
2. 直後に、writing-quotation の形式に従って、出典からの引用をコードブロックで記載し、主張の根拠を示します。
3. 閉じるフェンスの次の行に、出典参照 [source-name (YYYY/MM)] を記載します。

読者は、まず「何が述べられているのか」を把握し、その後に「根拠は何か」を確認できます。逆の順序（先に引用し、後から主張すること）は禁止です。引用が何を示すものなのかを、読み進めるまで読者が判断できないためです。

悪い例（先に引用）：

The standard recipe of pretraining on huge corpora and then running classical preference-label RLHF is now widely treated as obsolete.

[industry-tracker (2026/03)]

主流のモデルでは、モジュール式のポストトレーニングスタックへ移行しました。

良い例（先に主張）：

古典的な RLHF パイプライン（人間の選好ラベル → 報酬モデル → PPO）は、最先端のモデルでは使われなくなり、各要素を分離したモジュール式のスタックに置き換えられています。

The standard recipe of pretraining on huge corpora and then running classical preference-label RLHF is now widely treated as obsolete. Every leading model released in the past year uses a different post-training stack.

[industry-tracker (2026/03)]

出典参照ラベル

documenting-with-sources で定義されている [label (YYYY/MM), location] の形式では、調査スキルがラベル欄に掲載元または情報源の名前（メディア名、サイト名など）を記載します。特定できない場合は、場所を省略します。

見出しと内容の整合性

セクションの見出しと、その下に置く項目は正確に一致させてください。

• 見出しが「人間側のガードレール」の場合、その下には人間の行動と規律だけを記載します。ツールや CI/CD は別の見出しに分けてください。
• 見出しが「失敗事例」の場合、成功事例や推奨事項を混在させないでください。
• ある情報源が複数の観点にまたがる場合は、関連するセクションに分けて記載するか、最も適切なセクションに記載し、他の観点について明示的に注記してください。
• 最終化する前に、すべての見出しを確認し、その下の内容が見出しに合っていることを確かめてください。

出力先

成果物は {CWD}/reports/ に .md ファイルとして書き出します。ディレクトリが存在しない場合は作成してください。中間成果物を出力するサブエージェントも同じディレクトリを使用します。

ワークフロー

1. ユーザーの依頼から、主張または仮説と、情報収集の範囲を特定します。
2. 範囲に応じて、複数言語での検索も含め、検索クエリを設計します。
3. 調査をサブエージェントに割り当てます（観点ごとに 1 つ、並行して実施）。
4. サブエージェントの出力を統合し、メインエージェントが最終版を作成します。
5. 成果物を {CWD}/reports/ に書き出します。

サブエージェントへの委任ルール

サブエージェントに委任する際は、次のルールに従ってください。

• 観点ごとに分け、並行して割り当てます（例：「論文・学術界」「メディア・ブログ」「ソーシャルメディア」「業界の動向」）。
• 各サブエージェントに、documenting-with-sources の品質基準と規約を伝えます。特に「関連性や解釈を捏造しない」ことを改めて強調してください。サブエージェントは、呼び出し元との会話の文脈に引きずられ、根拠のない関連付けを作り出しがちです。
• サブエージェントの出力は最終成果物ではありません。メインエージェントが次の作業を行います。
  • 重複の削除。
  • 情報の補完（追加調査による所属、引用数などの不足情報の補足）。
  • 構成の統一（表、統一されたセクション構成）。
  • 批判的な意見と、それを裏付ける証拠の切り分け。
  • 調査の限界（取得できなかった情報、未確認の URL など）の明記。
  • 捏造された関連付けの削除（documenting-with-sources の該当セクションを参照）。
  • 見出しと内容の整合性の確認（前述を参照）。

成果物の構成

# Survey of {topic}

Date: YYYY-MM-DD
Scope: {scope description}

## Table of Contents

1. [{angle 1}](#1-angle-1-slug)
2. [{angle 2}](#2-angle-2-slug)
...
N. [Criticism & concerns](#n-criticism-concerns)
N+1. [Overall assessment](#n1-overall-assessment)
N+2. [Investigation limits](#n2-investigation-limits)

## 1. {angle 1} (e.g. academic papers)
## 2. {angle 2} (e.g. media coverage)
## 3. {angle 3} (e.g. social-media reactions)
## 4. {angle 4} (e.g. industry signals)
## N. Criticism & concerns
## N+1. Overall assessment
## N+2. Investigation limits

トピックに合わせてセクションの構成を調整してください。

目次の要件

レポートの先頭に、メタデータブロックの直後、本文の前に必ず目次を配置してください。目次なしでレポートを作成することは禁止されています。

• セクションが10個以上、または個別項目（論文、記事など）が15個以上ある場合は、2階層の目次を使用します。第1階層にはセクション名、第2階層にはそのセクションの主な項目（論文タイトル、記事の見出しなど）を記載します。
• 短いレポート（セクションが5個以下で、各セクションの項目数も少ない場合）は、1階層の目次で構いません。
• アンカーリンクを付けます。リンク先には、レンダラーのスラッグ規則（小文字化、スペースをハイフンに置換、特殊文字を除外）を使用します。
• スラッグ規則が不確かな場合でもリンクは記載し、省略せずにレンダラーによるスラッグ化に任せます。
• 目次の項目とセクション見出しは、一字一句一致させます。省略や言い換えはしないでください。