TL;DR
- AIをリサーチに使うときは「代理」ではなく「コラボレーター」と置き直す。代理だと丸投げになり、要約は上滑りする
- 検索・読解・統合・出力の4レイヤーにAIを常駐させると、人間の判断が抜けない範囲でAIの圧縮力が活きる
- 研究ノート（Source Notes）とAIサマリー（Synthesis Notes）を物理的に分けるとハルシネーションの混入が止まる
- リサーチ・ダッシュボードに「一次ソース率」「決裁レイテンシ」「結論安定度」を載せると、研究の進み具合が"気分"でなく"指標"で見える
この記事の目的と成功基準
- 目的: AIをリサーチに使うときの設計を「丸投げ要約」から脱却させ、4レイヤー × ダッシュボードで運用に乗る形に組み直すこと
- 想定読者: 一次情報の量に押されてアウトプットが詰まっている技術ライター・研究者・PM
- 成功基準: 「AI 研究 ワークフロー」「AI リサーチ ダッシュボード」関連クエリの検索表示回数増、および関連記事（AI Mode時代の技術ブログ設計、AIエージェントSkill Hub）への回遊率
はじめに: AIに丸投げした要約はなぜ上滑りするのか
2026年5月時点で「AIに論文を投げて要約させる」体験はもう特別ではなくなった。Google Gemini の Deep Research、OpenAI の Deep Research、Anthropic Claude のリサーチ用途、NotebookLM、いずれも実用ラインに入っている。
それでも、AIで作ったリサーチ要約をそのまま記事や提案書に貼ると、ほとんどの場合"上滑り"する。読み返すと正しいが、踏み込みがない。一次情報の選別、相反する主張の比較、自社の文脈での意味づけ、こういう"判断"の部分がごっそり抜け落ちているからだ。
このサイトでは AI記事制作で品質を落とさない設計 や AI Mode時代の技術ブログ設計 で「AIで書く」レイヤーを整理してきた。今回はその上流、「AIで研究する」レイヤーを実務に乗る粒度で書き起こす。
結論を先に置くと、必要なのは"優秀なAI"ではない。AIを4つのレイヤーに分けて常駐させ、人間の判断ポイントを物理的にノートに固定し、進み具合をダッシュボードで指標化する設計だ。
AIを「代理」ではなく「コラボレーター」に位置づけ直す
最初に直す必要があるのは、AIへの期待値の置き方だ。
「代理」は、AIにタスクの全部を渡して結果だけ受け取るモデルだ。短いタスク、定型タスクには合うが、研究には合わない。研究は「何を問いと置くか」「どの情報を一次として採用するか」「結論をどこまで主張するか」という判断の連鎖でできていて、ここを渡してしまうとアウトプットの根が浅くなる。
代わりに採用するのが「コラボレーター」モデルだ。AIには圧縮（要約）・翻訳（言い換え）・反証（別解の提示）を任せ、判断・選別・主張の責任は人間が持つ。これは、Anthropic が公開している Claude のリサーチ用途ガイダンスでも、OpenAI の Deep Research のリリースノートでも一貫して強調されている方針と整合する。
役割分担の原則
- 人間が握るもの: 問いの定義、一次情報の採否、相反する主張の裁定、結論の主張範囲
- AIに任せるもの: 検索クエリ展開、長文の圧縮、用語の翻訳、別の角度からの反証、構成のたたき
- 共同で詰めるもの: 仮説の妥当性、論点の網羅性、語り口の調整
「AIに何を任せるか」を最初にこの粒度で決めておかないと、レビュー段階で"AIの主張なのか自分の主張なのか"が分からなくなる。
役割分担表（レイヤー別）
| レイヤー | 人間 | AI | 共同 |
|---|---|---|---|
| 検索 | 問いの定義、対象範囲の確定 | クエリ展開、英日往復、関連語提案 | 採用ソースの選別 |
| 読解 | 結論への賛否判断、信頼度評価 | 長文の章別要約、表化、用語整理 | 矛盾点の抽出 |
| 統合 | 主張の枠組みづくり、独自視点 | 差分抽出、反証視点の生成 | アウトラインの構築 |
| 出力 | 主張・トーン・最終判断 | 草稿生成、校正、別案出し | 編集レビュー |
この表を最初に書き出しておくと、レビュー時に「これは人間が判断すべき項目を AI に任せていないか？」というセルフチェックが成立する。
検索・読解・統合・出力の4レイヤーにAIを常駐させる
「コラボレーターに置き直す」を運用に落とす形が、検索 / 読解 / 統合 / 出力の4レイヤー設計だ。各レイヤーに別々のAI体験を当てる。
検索レイヤー: Deep Research 系の使い分け
検索レイヤーでAIに任せるのは「クエリ展開」と「探索の幅出し」だ。Google の Gemini Deep Research、OpenAI の Deep Research、Perplexity の研究モード（Deep Research）はいずれも、複数の検索を並列で実行し、出典付きで返す設計になっている（2026年5月時点の各社公式リリースで明記）。
ここでの判断ポイントは2つ。
- 出典がついているか（URLが踏める形で残るか）
- その出典が一次か二次か（公式・査読・公的データを"一次"とする）
二次情報のリスト（要約系メディアやまとめ記事）だけが返ってくる検索は、研究には使わない。検索結果の中から一次情報だけを抜き取り、後段の「読解レイヤー」に回す。
読解レイヤー: PDF・論文・公式ドキュメントを章別に圧縮する
読解レイヤーでは、抜き取った一次ソースを章別に圧縮する。
ここで NotebookLM や Claude のロングコンテキスト読解が効く。1本の論文・公式ドキュメントを章ごとに要約し、用語を統一し、図表を本文へリンクし直す。重要なのは、ここで作るのは「Source Notes（出典に紐づくノート）」であり、自分の主張を入れないことだ。
ノートの先頭に「この章で著者が主張していること」と「この章では触れられていないこと」を書く欄を必ず置く。前者は要約、後者は論点抽出になる。AIには前者だけを任せ、後者は人間が書く。
統合レイヤー: 差分シンセシスとノート分離
統合レイヤーは、複数の Source Notes を束ねて自分の主張を作るレイヤーだ。
ここでAIに任せるのは「差分の抽出」と「反証の生成」だけにする。3本の論文で結論が割れているなら、その差分を整理させる。1つの結論しか見ていない場合、AIに「逆の立場ならどう反証するか」を生成させる。これは Andy Matuschak が書いている "Evergreen notes" の文脈や、Zettelkasten の「Atomic Notes と Permanent Notes の分離」の発想にも近い。
統合レイヤーで作るのは「Synthesis Notes（自分の主張に紐づくノート）」だ。Source Notes と Synthesis Notes は別ファイル・別フォルダに分ける。ここを混ぜると、後で「これは出典の主張なのか、自分の主張なのか」が辿れなくなる。
出力レイヤー: 草稿・反証・編集レビュー
出力レイヤーはアウトプット直前。Synthesis Notes を元に草稿を作り、AIに反証と編集レビューをさせる。
ここで重要なのは、AIに新規の主張を作らせないこと。草稿は Synthesis Notes の範囲内で書き、AIには「主張が飛躍していないか」「根拠が弱い段落はどこか」を指摘させる。これは AI記事制作で品質を落とさない設計 で扱った"レビュー側にAIを置く"設計と整合する。
研究ノートとAIサマリーを分離する
4レイヤー設計を支えているのが、ノートの分離原則だ。
二段構成: Source Notes と Synthesis Notes
実装上は、リサーチ用フォルダを次の2階層に分ける。
sources/（Source Notes）: 1ファイル = 1出典。AIが書いた要約と、その章で触れていない論点メモを並置synthesis/（Synthesis Notes）: 1ファイル = 1主張。複数の Source Notes を引用しながら自分の論を組む
このとき、sources/ はAIに編集させていい領域、synthesis/ はAIに編集させない（指摘だけ受ける）領域、と運用ルールで区切る。
引用ルールとハルシネーション対策
ハルシネーションを構造で止めるための運用ルール3つを書いておく。
- Source Notes に書く要約には必ず元URLとアクセス日を併記する。元URLが踏めない要約は採用しない
- Synthesis Notes でAI生成文を採用する場合、引用元の Source Notes へのリンクを必ず付ける。リンクが付けられない主張はAIが作ったものとみなして採用しない
- 数値・固有名詞・日付は人間が再確認する。AIに任せていい圧縮は文章構造であって、ファクトの検証ではない
この3点は、OpenAI のモデル仕様 と Anthropic の Claude ドキュメント（hallucinations の項） が共通して挙げている "Limitations" の項目（ハルシネーション、最新性、数値の不正確さ）に対応する形になっている（2026年5月時点）。
リサーチ・ダッシュボードに何を載せるか
4レイヤー設計とノート分離だけでは、運用がブレる。「今どれくらい進んだか」が"気分"のままだと、人は無限に追加情報を集めてしまう。ここで効くのがリサーチ・ダッシュボードだ。
ダッシュボード指標表
| 指標 | 計測対象 | 定義 | 推奨閾値（目安） |
|---|---|---|---|
| 一次ソース率 | Synthesis Notes 内の引用URL | 公式・査読・公的データの URL 数 ÷ 引用URL総数 | 70%以上 |
| 決裁レイテンシ | 1主張 | Synthesis Notes 着手から「主張確定」までの日数 | 3営業日以内 |
| 結論安定度 | 1主張 | 直近3回の編集で結論文の意味が変わった回数 | 1回以下 |
| 反証カバレッジ | 1主張 | AIが生成した反証論点のうち、本文内で扱った割合 | 60%以上 |
| 出典更新ラグ | Source Notes | 最終アクセス日から現在までの日数（中央値） | 90日以内 |
数字そのものより、「閾値を割ったら必ず人間が見直す」という運用が大事だ。一次ソース率が下がっていれば、二次情報を引きすぎている合図。決裁レイテンシが長すぎれば、Synthesis に至る前のノイズが多すぎる合図になる。
なお、上表の閾値（一次ソース率70%、決裁レイテンシ3営業日、結論安定度1回、反証カバレッジ60%、出典更新ラグ90日）は経験則であり、筆者がリサーチ案件を回した際の社内運用での暫定値だ。テーマの新規性、チームの規模、扱う領域の更新頻度で適正値は動くため、最初の1-2件で実測したうえで自チーム条件に合わせて再調整してほしい。たとえば法令・医療など更新が遅い領域では出典更新ラグを180日まで緩めるのが現実的だし、生成AI系のように週次で公式情報が動く領域では30日まで詰めたほうがいい。
計測の置き場所（運用の具体例）
ダッシュボードを抽象論で終わらせないために、計測の置き場所を1つ決めておく。実装の例を挙げる。
- Notion の場合:
Synthesis Notesデータベースに引用URL（マルチセレクト）と一次/二次プロパティを追加し、ロールアップで一次ソース率を自動計算。着手日/確定日プロパティから決裁レイテンシをフォーミュラで算出する - Obsidian の場合: Dataview プラグインで
sources/フォルダの frontmatter（primary: true/false、accessed: YYYY-MM-DD）を集計し、Synthesis Notes 側に埋め込み表示する - Excel / Google Sheets の場合: 1主張 = 1行で「引用URL数」「うち一次」「着手日」「確定日」「結論変更回数」を手入力し、ピボットでレイヤー別の傾向を見る
- GitHub Issue の場合: 1主張 = 1 Issue、ラベル（
source/primary、source/secondary）と Project ボードのカラム遷移日時から計測する
筆者の運用は Notion + Obsidian の併用で、sources/ を Obsidian、synthesis/ を Notion に置いて Notion 側のロールアップで一次ソース率を週次レビューしている。粒度としては「主張1つにつき指標5つを必ず埋める」を最低ラインにし、埋まっていない主張は Synthesis から外す運用にしている。
一次ソース率・決裁レイテンシ・結論安定度
特にこの3つは独立した意味を持つ。
- 一次ソース率: 信頼性を測る。低いまま記事に出すと、後で書き直しになる
- 決裁レイテンシ: スピードを測る。長すぎる場合、問いの定義が甘い
- 結論安定度: 設計の固さを測る。低い場合、Synthesis Notes の論理が組み上がっていない
このダッシュボードは、エージェント運用に近いリサーチオプスの考え方になる。AIエージェント Skill Hub の設計 や AIエージェントの可観測性 で扱った"運用を指標で見る"発想と同じだ。
失敗パターンと運用Tips
最後に、4レイヤー設計を運用してきて踏みやすい失敗を整理しておく。
- 要約の上滑り: AIが書いた章別要約をそのまま Synthesis に持ち込んでしまうケース。Source と Synthesis のフォルダ分離で物理的に防ぐ
- 引用切れ: AIが要約の途中で URL を落とすケース。Source Notes には URL とアクセス日を最初に書く運用にする
- 反証バイアス: AIに反証を出させると、論点が広がりすぎて収束しないケース。反証カバレッジ指標で「本文に取り込む割合」を上から制約する
- 出典更新ラグの蓄積: 半年前のドキュメントがそのまま引かれているケース。出典更新ラグ指標を月1で点検する
- コンテキストの肥大: 1チャットに全資料を放り込んで議論するケース。レイヤー単位でセッションを分け、Source / Synthesis でツール自体を変えるのがおすすめ
- AIへの過依存: 「AIに聞いたから合っているはず」状態。数値・固有名詞・日付は人間で再確認するルールを切り出して明文化する
このあたりは AI開発のコンテキスト負債 や MCP 権限設計の判断軸 と発想を共有する。AIを運用に組み込むほど、構造で守りに行く設計が必要になる。
FAQ
Q1: Source Notes と Synthesis Notes の違いは？
Source Notes は読んだ一次情報そのものの要約と引用で、書誌情報・URL・引用ページを記録する一次層のメモだ。Synthesis Notes は複数の Source Notes を再構成した自分の主張・仮説で、出典への参照は持つが原典のコピーは含まない二次層のノートになる。両者を物理的に別ディレクトリ（sources/ と synthesis/）で管理する理由は、AI に Source Notes を読ませて Synthesis Notes を書く運用が成立するためだ。混在すると AI が自分の生成物を一次情報として再利用してしまう。
Q2: ハルシネーション対策の最低ラインは？
経験則として 「数値・固有名詞・日付は人間で必ず再確認する」 を運用ルールに切り出すのが最低ラインだ。AI に新規主張を作らせず、Source Notes に存在する事実だけを Synthesis Notes に転記させる方針にすると、ハルシネーション率は実用上ゼロに近づく。OpenAI と Anthropic の公式ドキュメントが共通して挙げる Limitations（ハルシネーション・最新性・数値の不正確さ）に対応する形でガードレールを設計する。
Q3: Gemini Deep Research / OpenAI Deep Research / Perplexity 研究モードのどれを使うべき？
用途で使い分けるのが現実解だ。網羅的な Web 探索 + 出典付き要約は Gemini Deep Research、長文 PDF・社内資料との組合せは Claude（Anthropic）、リアルタイムなニュース系は Perplexity 研究モードが強い。本記事の4レイヤー設計でいうと、検索層は Gemini / Perplexity、読解層は Claude、統合層は人間 + Claude、出力層はチームの主流ツール、という分担が回しやすい。1ツール固定にせず、レイヤー単位で替えられる前提で運用する。
Q4: 個人と組織で運用は変えるべき？
Synthesis Notes の所有者と更新権限のルールを変える必要がある。個人運用なら Synthesis Notes は自分のメモで完結するが、組織運用では「誰が Synthesis を書けるか」「Source Notes は誰でも追加できるか」を明文化しないと、二次情報の信頼性が崩れる。最小構成では、Source Notes は Pull Request ベースで誰でも追加可、Synthesis Notes は1人の Owner が承認してマージする運用が安全だ。
Q5: ダッシュボード5指標（一次ソース率 / 決裁レイテンシ / 結論安定度 / 反証カバレッジ / 出典更新ラグ）の更新頻度は？
週次で更新、月次でレビューが現実的な粒度だ。一次ソース率と出典更新ラグはダッシュボード自動集計で十分（Notion / Obsidian / Excel いずれでも可）。決裁レイテンシと結論安定度は手動記録が必要で、Synthesis Notes に「決定日」「変更履歴」フィールドを持たせて週次で集計する。反証カバレッジは月次レビューで「反証検討済み」のチェック率を集計する。閾値（70% / 3営業日 / 60% / 90日）はあくまで経験則の暫定値で、自チームのワークロードに合わせて再調整する前提だ。
まとめと次に読む記事
- AIをリサーチに使うときは、「代理」ではなく「コラボレーター」に置き直す
- 検索・読解・統合・出力の4レイヤーにAIを常駐させる
- Source Notes と Synthesis Notes を物理的に分離する
- ダッシュボードで一次ソース率・決裁レイテンシ・結論安定度を見える化する
- ハルシネーション対策は、賢いプロンプトより構造で止める
リサーチが組み上がったら、次は「AIで書く」レイヤーを設計する。順番に読むなら、AI記事制作で品質を落とさない設計 → AI Mode時代の技術ブログ設計 → 古い技術記事をAI検索時代に合わせて更新する運用 の順で接続できる。
リサーチ設計テンプレを配布しているので、自社のワークフローを4レイヤーに分解してみたい場合は、記事診断から相談してほしい。
