リサーチ設計とは｜AI時代に4フレームで問いを組む型

この記事の要点

リサーチ設計とは「調べに行く前に地図を書く」計画のことで、Creswell や Yin の学術定義でも、コンサルの論点設計でも、担う機能は3つ（目的の明確化・方法論の選択・検証可能性の担保）に集約されます。主要フレームワークは4つ、イシューツリー（Barbara Minto の MECE）、リサーチクエスチョン（FINER 基準・PICO/PICOC）、ロジックツリー（Why/How/KPI）、仮説駆動リサーチ（内田和成・Popper・リーンスタートアップ・Teresa Torres）です。AI 時代には、イシューツリーが Perplexity Deep Research の query fan-out と ParallelResearch 論文のツリーとして、RQ が LangChain Open Deep Research の User Clarification 工程として、それぞれ AI Agent アーキテクチャに直接埋め込まれつつあります。実務では、コンサル流の順番（産業レポート→省庁資料→企業資料→検索）、安宅和人のよいイシューの3条件、Odaiji の AI プロンプト8項目テンプレを組み合わせて、30分でブリーフを書き上げるのが定石です。よくある失敗は5つ（範囲爆発・検証不可・二重問い・MECE 違反・上位論点の欠落）。調査の連鎖を組織資産として蓄積したいなら、意味空間・ナレッジグラフ・文字列インデックスの3層設計を持つ Snorbe が別軸の選択肢になります。

リサーチ設計とは何か 学術的定義と実務的定義を並べて理解する

リサーチ設計とは、「何を、誰に、どうやって調べて、その結果をどう検証するか」を先に決める計画のことです。難しく言えば「調査プロセスの設計」ですが、シンプルに言えば「調べに行く前に地図を書く」作業です。

いま Deep Research 系ツールが一気に普及したことで、この地図を書くスキルが再評価されています。ツールが5分でレポートを返してくれるからこそ、「何を調べるか」を最初に決めきる力が、そのまま調査の質を左右するようになったからです。

学術の世界と実務の世界では、リサーチ設計の言葉の使い方が少し違います。まずこの違いを整理してから、両者に共通する3つの機能を見ていきます。

学術世界の定義 Creswell と Yin と Bryman

学術系リサーチャーがリサーチ設計を学ぶとき、まず読むのは John W. Creswell の教科書です。『Research Design: Qualitative, Quantitative, and Mixed Methods Approaches』（Sage, 5th ed., 2018）は、リサーチ設計を「哲学的前提・研究プロセスの主要要素・文献レビュー・理論の使用・執筆と倫理を包括する研究計画」と定義しています。ここには、定量・定性・混合の3アプローチが横断的に位置づけられます¹。

Creswell の第5版で強化されたのは、「認識論的・存在論的な立ち位置と、研究の問い、方法論を紐づけて考える」議論です²。質的研究の場合、中心的な問い（central question）は「中心的現象の説明を求める広い問い」で、「how / what で始めて open-ended かつ emerging design を伝える」ことが推奨されます³。

一方、ケーススタディを設計する人が参照するのは、Robert K. Yin『Case Study Research and Applications』（Sage, 6th ed., 2017）です。Yin はケーススタディを「現代の現象を実生活の文脈内で調査する経験的探究であり、現象と文脈の境界が明確でないときに用いる」と定義しました⁴。適用の3条件は、①how / why の問い、②研究者が事象を制御できない、③現代的現象（歴史的ではない）、の3つです⁵。

社会科学系では、Alan Bryman『Social Research Methods』が定番の教科書です。Bryman はリサーチ設計を「データ収集と分析の枠組みで、研究プロセスの諸次元への優先順位づけの意思決定を反映する」と定義し、研究戦略（質的／量的）と組み合わせて使うと明示しています⁶。

Mixed Methods（混合研究法）は、Creswell & Plano Clark『Designing and Conducting Mixed Methods Research』（Sage, 3rd ed., 2017）で3類型が定式化されました⁷。Harvard Catalyst のガイドが実務向けに整理していて、次の3つが基本形です⁸。

• Convergent Parallel：質的・量的データを同時収集分析して、収束と乖離を議論する
• Explanatory Sequential：量的データ収集分析から始めて、深い説明を要する部分に質的調査を続ける
• Exploratory Sequential：質的調査から出発、結果を用いて新しい測定尺度を開発、次に量的検証

日本語圏では、亀井智子（聖路加国際大学）が J-STAGE 論文で、混合研究法を「量的・質的の両者を含み、研究の妥当性・信頼性を高めつつ、パラダイム論争に一つの方向を与える『第三のパラダイム』」と位置づけています⁹。

実務世界の定義 コンサル・PdMの型

実務では、学術の Research Design よりも「調査設計」「問い設計」といった言葉が使われることが多いです。コトバンクの社会学小辞典は、調査設計を「だれ（調査対象）に対して、何を（調査項目）、どのような方法（調査法）で調査するかの計画を立てること」と定義しています¹⁰。

コンサル寄りの実務では、「テーマ→論点→リサーチクエスチョン→命題／仮説」の4層構造で整理されます¹¹。学術の RQ 定式化と実務の論点設計は、名前が違うだけで、やろうとしていることはほぼ同じです。

PdM（プロダクトマネージャー）の世界では、SVPG の Marty Cagan が Product Discovery の framing を「チームがビジネス目的・顧客問題・ユーザープロファイル・成功基準に整合しているかの確認」「discovery 期間中に対処すべき主要リスク（Value/Usability/Feasibility/Business Viability）の特定」と位置づけています¹²。ここでも、調査に入る前に「何を明らかにするか」を先に決める、という構造は同じです。

リサーチ設計が担う3つの機能

学術と実務の定義を並べると、リサーチ設計が担っている機能は、次の3つに整理できます。

1. 目的の明確化（Research Aim）：Creswell の研究プロセスの起点、Bryman や Yin の RQ 設定
2. 方法論の選択（Methodological Choice）：質的・量的・混合の選択、哲学的前提と一致させる、ケーススタディや比較といった類型を選ぶ
3. 検証可能性の担保（Validity / Reliability）：内的・外的・構成概念・基準関連の4種類の妥当性と、再テスト・折半・内的整合性による信頼性評価¹³¹⁴

この3つは、AI 時代の Deep Research にも、そのまま当てはまります。目的が曖昧だと出力が散る。方法論を選ばないと同じ問いに同じ答えばかり返ってくる。検証可能性を担保しないと、それっぽいレポートで満足して終わってしまう。

日本語の3語の使い分け 調査設計 研究設計 問い設計

日本語では、リサーチ設計に相当する言葉が3つあって、微妙にニュアンスが違います。

• 調査設計：市場調査・世論調査・アンケート調査の文脈で使われることが多い言葉です。対象・項目・方法を決めるという実務的なニュアンスが強めです。
• 研究設計：Research Design の直訳で、学術（特に看護・社会科学・心理学）で使われます。査読論文や学位論文で「研究デザイン」として登場します。
• 問い設計：実務コンサル寄りの用法で、「テーマ→論点→リサーチクエスチョン→命題／仮説」の4層構造で語られることが多いです。近年は AI プロンプト設計の文脈でも「問いの設計力」として使われます。

3つの言葉は、指しているものは同じでも、聞き手に届くイメージが違います。学術寄りの文脈なら「研究設計」、市場調査なら「調査設計」、AI プロンプトや戦略コンサル寄りなら「問い設計」を使うと、話が通じやすいです。

セクション1のまとめです。リサーチ設計とは、学術と実務が別々の言葉で語ってきた「調べに行く前に地図を書く」作業のことで、3つの機能（目的の明確化・方法論の選択・検証可能性の担保）を担います。次のセクションでは、実際の地図の描き方を、4つの主要フレームワークを巡る旅として見ていきます。

出典

4つの主要フレームを巡る旅 イシューツリー RQ ロジックツリー 仮説駆動

リサーチ設計を組むときに使われるフレームワークは、大きく4つに集約できます。イシューツリー、リサーチクエスチョン（RQ）、ロジックツリー、仮説駆動リサーチの4つです。それぞれに原典があり、得意な場面があり、AI 時代との相性も違います。ここでは Grand Tour（主要フレームを巡る旅）として、順に立ち位置を見ていきます。

イシューツリー Barbara MintoのMECEを可視化する図

イシューツリーは、Barbara Minto が1960年代後半にマッキンゼー在籍中に体系化した MECE 原則を可視化したものです¹⁵。McKinsey Alumni Center の記事によれば、ミントは「レポートを編集する過程で、アイデアを常にピラミッド型に再構成していることに気づき、その集合が『相互に排他的（ME）』かつ『全体を網羅（CE）』であるべきだ」と定式化しました¹⁶。

Wikipedia のイシューツリー項目は「問いをグラフィカルに分解したもので、左から右に読むにつれ詳細になる。診断型（Why Tree）と解決型（How Tree）に大別される」と整理しています¹⁷。

MECE は「Mutually Exclusive（重複なし）」と「Collectively Exhaustive（漏れなし）」の頭文字です。ミント自身が「MECE のアイデアはアリストテレスまで遡る」と述べていて、現代版として体系化・名称化したものです¹⁸。実務では、要素分解／因数分解／時系列・ステップ分け／対称概念の4切り口が有名です¹⁹。

マッキンゼーの7ステップ問題解決は、Charles Conn & Robert McLean『Bulletproof Problem Solving』で定式化されています。①問題定義 → ②論点分解（Disaggregate the Issues、イシューツリー）→ ③優先順位付け（Prune the Tree）→ ④作業計画 → ⑤クリティカル分析 → ⑥知見合成 → ⑦効果的コミュニケーション、の順です²⁰。

主戦場は、論点を分解して並列に探索したいときです。弱点は、分解軸の選定ミス（ディメンジョンや抽象度の不統一）と、上位論点の定義失敗で下流全体が空振りになるパターンです²¹²²。

リサーチクエスチョン（RQ） 研究全体の羅針盤

学術系では「研究全体の羅針盤」と呼ばれます。Enago は「査読論文・学位論文審査で『RQ が明確でない』は最も致命的批判の一つ」と指摘しています²³。

RQ を評価する古典的な基準が FINER です。Hulley et al.『Designing Clinical Research』（Lippincott, 3rd ed., 2007）で提唱されました²⁴。

• Feasible（実行可能）：時間・資金・被験者・技術力
• Interesting（関心を引く）：研究者・広い読者を惹きつけるか
• Novel（新規性）：先行研究を confirm/refute/extend するか
• Ethical（倫理的）：IRB 承認可能か
• Relevant（関連性）：科学・臨床・政策に効くか

原著では「よい RQ は So what? テストを通るべき」と強調されています。Farrugia et al.（Can J Surg, 2010）は外科系プロトコルの文脈で「A well-defined and specific research question is more likely to help guide us in making decisions about study design and population.」と述べています²⁵。

もう一つ大事な RQ フレームが PICO です。Population（対象）、Intervention（介入）、Comparison（比較）、Outcome（結果）の4要素で、Cochrane Handbook がシステマティックレビューの question モデルとして採用しています²⁶。派生形として PICOT（時間軸追加）、PICOS（study design 追加）、PECO（環境曝露）などがあります。PICOC は Petticrew & Roberts が社会科学向けに拡張したもので、Kitchenham & Charters『Guidelines for Performing Systematic Literature Reviews in Software Engineering』がソフトウェア工学の SLR 手続きとして採用しています²⁷。

UCL Library の Systematic Searching ガイドは、目的別に15種以上の RQ フレームを整理しています。質的研究は SPIDER、実装/組織変革は SPICE、リアリスト評価は CIMO、scoping review は PCC、環境曝露は PECO、といった具合です²⁸。

主戦場は、調査の焦点を絞って検索語まで落とし込みたいときです。とくに Deep Research 系ツールを使うとき、PICO で問いを構造化してから投げると、返ってくるレポートの網羅性がぐっと上がります。

ロジックツリー Why/How/KPIの3類型

ロジックツリーは、問いやテーマを根（ルート）として、下位要素・論点・原因へと枝葉状に展開する手法です²⁹。3つの類型があります。

• Why ツリー：原因追究（Toyota 5 Whys の思想を樹形図化）
• How ツリー：解決策・施策展開
• KPI ツリー：数式的な因数分解（売上 = 客数 × 客単価、のような形）

イシューツリーとロジックツリーの違いは、対象範囲の広さです。ロジックツリーは「問い・概念・要素」全般を対象とする広義の手法で、イシューツリーは「問い（イシュー）」の分解に特化したサブセットです³⁰³¹。ロジックツリーは因果分解・打ち手展開が軸足、イシューツリーは論点構造化が軸足、という違いもあります。

5 Whys（なぜを5回繰り返す）はトヨタの豊田佐吉が原型を作り、大野耐一が体系化・普及しました。大野は「5回のなぜを繰り返すことがトヨタの科学的アプローチの基礎であり、それによって問題の本質と解決策が明確になる」と述べています³²。Why ツリーはこの思想を樹形図として構造化したものです。

主戦場は、Where（どこに問題があるか）→ Why（なぜ起きているか）→ How（どうすればよいか）の3段構えです³³。

仮説駆動リサーチ 内田和成 齋藤嘉則 Popper リーンスタートアップ

仮説駆動リサーチは、「先に仮の答えを置いて、それを確かめに行く」思考法です。日本の実務では、2冊の古典がよく参照されます。

内田和成『仮説思考 BCG流 問題発見・解決の発想法』（東洋経済新報社, 2006）は、仮説を「十分な情報がない段階、あるいは分析が済んでいない段階でもつ、仮の答え・仮の結論」と定義し、「仕事の速さ・出来栄えを決めるのは分析力ではなく仮説である」と主張しています³⁴。

齋藤嘉則『問題解決プロフェッショナル 思考と技術』（ダイヤモンド社）は、「ゼロベース思考」「仮説思考」の2つの思考、「MECE」「ロジックツリー」の2つの技術、「ソリューション・システム」の1つのプロセスで、問題解決を体系化しています³⁵。

哲学的な源流は、Karl Popper の反証可能性（falsifiability）です。『The Logic of Scientific Discovery』（1934）で提唱されました。Stanford Encyclopedia of Philosophy によれば「A (theoretical) sentence is falsifiable if and only if it logically contradicts some (empirical) sentence that describes a logically possible event that it would be logically possible to observe.」となります³⁶。「1000羽の白い白鳥はすべての白鳥が白いことを証明しないが、1羽の黒い白鳥はそれを反証する」という有名な例で語られる、検証と反証の非対称性の思想です。

ビジネス側では、Eric Ries『Lean Startup』（2011）の Build-Measure-Learn ループが仮説駆動の代表格です³⁷。Value Hypothesis（価値仮説）と Growth Hypothesis（成長仮説）を先に置いて、Validated Learning をゴールに Pivot / Persevere を判断するという設計です。

PdM の世界では、Teresa Torres の Continuous Discovery が実装されています。Opportunity Solution Tree（OST）で「頂点にビジネスアウトカム、中段に機会（unmet needs）、下段に検証すべき solution」を配置し、「What do I need to learn this week?」という短周期の RQ を明示化します³⁸³⁹。Torres は「If your research questions aren’t changing every week, you’re not learning every week.」と述べています。

主戦場は、時間がない中で「アタリを付けて掘る」ときです。AI の高速反復と組み合わせると有効性が大きく高まる、というのが後のセクションで見る展開になります。

4フレーム対比表

4つのフレームを7軸で並べると、こう整理できます。

軸	イシューツリー	リサーチクエスチョン	ロジックツリー	仮説駆動
目的	論点分解	焦点絞り込み	因果分解・打ち手展開	検証設計
使いどころ	プロジェクト初期の論点棚卸し	検索式構築、SR プロトコル	原因追究、施策展開、KPI 分解	時間ない中でアタリを付けて掘る
出発点	上位イシュー（問い）	central question / PICO 要素	症状・課題	仮の答え（仮説）
終着点	サブイシュー群（MECE）	検索式・データ収集計画	打ち手 or 根本原因	検証結果と Pivot/Persevere 判断
AI 時代の相性	◎	◎	△	◎
弱点	分解軸選定ミス、上位論点の定義失敗	過度な絞り込みで探索範囲狭まる	単独では因果を保証できない	仮説に固執すると確証バイアス
原典	Barbara Minto、Conn & McLean	Hulley、Cochrane、Creswell	グロービス／マッキンゼー系解説	内田和成、齋藤嘉則、Popper、Ries

この4つは、どれか1つを選ぶというより、案件ごとに組み合わせて使うのが実務です。プロジェクトの初期にイシューツリーで論点を棚卸しし、そこから RQ で調査の焦点を絞り、仮説駆動で検証設計をする、という流れが典型的な組み方です。

補助フレーム 上位（設計層）と下位（表現層）

4つの主要フレームの周囲には、補助的なフレームが多数あります。これらは「設計層」「表現層」「発想層」に整理できます。

設計層（上位、思考を組み立てる層）にあるのは、ロジックツリー、イシューツリー、仮説思考、5 Whys、Build-Measure-Learn、反証可能性の6つです。表現層（下位、思考を伝える層）にあるのは、5W1H（Who/What/When/Where/Why/How）で事実整理と論点洗い出し、PREP（Point-Reason-Example-Point）で提案・説得の骨格、STAR（Situation-Task-Action-Result）で経験・実績のナラティブ提示、SCQA（Situation-Complication-Question-Answer）でイントロダクション構造、といった型が並びます。SCQA はバーバラ・ミント『考える技術・書く技術』の思想が源流です⁴⁰。

発想・統合層としては、KJ法（川喜田二郎『発想法』中公新書, 1966）が有名です。カード作成 → グループ化 → 図解化 → 叙述化の4ステップで、ボトムアップに情報を統合する技法です⁴¹。IDEO のプロトタイピング（Empathize → Define → Ideate → Prototype → Test の5段階）も、この層に位置づけられます⁴²⁴³。

セクション2のまとめです。リサーチ設計の主要フレームは4つ（イシューツリー、RQ、ロジックツリー、仮説駆動）、周辺に表現層と発想層のフレームがあります。次のセクションでは、これらのフレームが AI 時代の Deep Research 系ツールとどう相性が良いのか、実装レベルで見ていきます。

出典

AI時代のリサーチ設計 Deep Researchとの相性で見る4フレーム

2025年前後から、Deep Research 系ツールが一気に主流化しました。OpenAI Deep Research が2025年2月に登場し、o3 モデルでサブ質問への自動分解と Web 検索・コード実行を組み合わせるようになりました⁴⁴⁴⁵。同じ月には Perplexity Deep Research が「Humanity’s Last Exam で 21.1%、多くのタスクを3分以内」と発表しました⁴⁶。Google Gemini Deep Research は Gemini 3 モデルで Web・Gmail・Drive・Chat を横断し、リサーチプランの Edit UI まで持っています⁴⁷。

学術寄りでは Elicit がミニ系統的レビュープロセス（検索→スクリーニング→データ抽出→合成、全主張が原論文の逐語引用にリンク）を持ち⁴⁸、Consensus が2億件超の査読論文を Consensus Meter で合意度可視化しています⁴⁹。

日本発では、Snorbe（Deskrex）が2026年5月に一般提供を開始しました。意味空間・ナレッジグラフ・文字列インデックスの3層で調査結果を蓄積、ホワイトスペースを自動検出、対話を跨いで文脈を記憶する自己進化型として設計されています⁵⁰。Felo AI Research は2億件超の学術論文と30言語超のマルチリンガル対応で、レポート・プレゼン・マインドマップを3分で生成します⁵¹。

これらのツールを使ってみると、多くの人が同じ壁にぶつかります。「出力が散る」「浅い」「網羅性がない」という不満です。原因は、ツール側ではなく、人間側の問い設計にあります。

問いの粒度が調査品質を決める

この観察は、日本語の実務ブログ上で独立に立ち上がっています。ショッキン氏は note で「回答があること」と「十分な深さで調べられていること」は別物だと指摘し、「Deep Research にぜんぶ丸投げじゃなくて、『この分野をこういう深さで頼む』みたいな、ざっくり情報の広さ×深さのマッピング図を描く感覚で指示出すのが大事」と書いています⁵²。

のばぺん氏は「プロンプトは、ただの質問じゃなくて、『何を重視して、何をスルーしていいか』っていう思考のナビ」と表現しています⁵³。河野将希氏は「何を調べるのか、どんな問いを立てたいのかが明確であれば、Deep Research は驚くほど効率的に解を提示してくれます」と、コンサル視点で整理しています⁵⁴。

技術者側からは、松尾淳平氏が Zenn で「抽象的な指示を分解し、役割を分け、ループを回し、必要な記憶を次に引き継ぐロジックを自前で持つ必要があります」と、アーキテクチャレベルで書いています⁵⁵。

これらの実務観察を並べると、Deep Research の限界は「AI の性能」ではなく「問いの粒度設計」にあるという結論に収束します。ここで、リサーチ設計の4フレームが再評価される流れが生まれています。

プロンプト=表現層 リサーチ設計=戦略層

もう一つの整理として、Zenn 上で複数の記事が「プロンプト工学とリサーチ設計は別の層」だと指摘しています。

suwash 氏は「プロンプトエンジニアリングが特定の応答を引き出す『戦術』なら、コンテキストエンジニアリングは一貫して高品質なパフォーマンスを保証する『戦略』」と定義しました⁵⁶。emuni 氏は、プロンプト→コンテキスト→ハーネスの3層進化論を提示し、「同じ問題でも、どの層で解決するかによって、運用コスト・再現性・スケーラビリティが大きく変わってきます」と述べています⁵⁷。

英語圏では、The AI Career Lab が「Prompt Engineer という肩書は職務記述書の1行に格下げ」「A prompt that runs a thousand times a day against real customer data isn’t a clever paragraph — it’s a spec with an evaluation suite attached.」と、職種消失を宣言しています⁵⁸。

各社の公式ドキュメントも、この流れに沿っています。Anthropic は「Research → Outline → Draft → Edit → Format」のように連鎖する部分タスク分解を推奨しています⁵⁹。OpenAI も「複雑タスクをサブタスクに分割」「参照テキストを与える」といった中核戦略を、エージェント向けにユーザーの問いを sub-requests に分解し完了確認する設計として整理しています⁶⁰。

つまり、AI 側は「問いをサブタスクに分解して、順に解いていく」設計を実装済みです。人間側に必要なのは、その分解の元となる「戦略層の問い設計」で、まさにリサーチ設計のフレームが担う役割です。

各フレームの AI 時代の相性

4フレームを AI 時代の Deep Research 系ツールと突き合わせると、次のように整理できます。

イシューツリーは AI との相性が◎です。Perplexity Deep Research は単一クエリを 8〜12 のサブクエリに fan-out し、並列 Web 検索とツリー状の分解構造でリサーチを実行しています⁶¹。arXiv 論文 ParallelResearch（2510.05145）は「deep research を planning nodes と research nodes の交互ツリーとしてモデル化し、各 planning node が非重複サブクエリを生成する」設計を提案しました⁶²。これは、まさに Barbara Minto の MECE 原則をそのまま LLM Agent の中に実装したアーキテクチャです。60年前に紙のレポート編集から生まれたフレームが、AI Agent の内部構造として蘇っている、というのは面白い一致です。

リサーチクエスチョンも◎の相性です。LangChain『Open Deep Research』の設計思想では、Deep Research Agent の第1フェーズが「User Clarification + Brief Generation」で構成されています。「users rarely provide sufficient context in a research request」を前提に、追い質問で context を引き出し、「research supervisor が指標として使える focused brief」に翻訳する、という流れです⁶³。これは学術の RQ 定式化と構造的にほぼ同じです。学術界が Hulley『Designing Clinical Research』で提唱した「よい RQ は So what? テストを通るべき」という思想が、そのまま LLM Agent アーキテクチャの最上流に組み込まれている、と言い換えられます。

学術寄りの研究では、Liu et al.『CoQuest』（CHI 2024）が LLM Agent が研究者と RQ を共創する UI を提案し、breadth-first と depth-first を比較しています⁶⁴。

ロジックツリーは△の相性です。AI は因果推論が単独では弱く、ロジックツリーの因果分解を人間側で組み立てる必要があります。ただし、Chain of Thought（Wei et al., 2022）⁶⁵、Self-Consistency（Wang et al., 2022）⁶⁶、Tree of Thoughts（Yao et al., 2023）⁶⁷といった推論プロンプティング手法で、因果的な段階推論の性能は徐々に改善しています。当面は「AI に因果を組ませる」より「人間が因果を組んで AI に検証させる」使い方が現実的です。

仮説駆動は◎の相性です。Deep Research は「仮説立案⇄検索」を高速に繰り返す実装です。ChatSense の解説では「初回検索で基本情報を収集→分析→新たな疑問・仮説を生成→再検索→……という継続的思考サイクルで、表面情報から本質的洞察へ段階的に深化する。人間のアナリストが数時間かける調査を10分程度に短縮できる」と整理されています⁶⁸。

学術寄りでは、Sakana AI Scientist（arXiv:2408.06292、v2 は 2504.08066）がアイデア生成→コード実装→実験→論文執筆→自動査読までを一気通貫で行う実装を発表しています⁶⁹⁷⁰。ただし Beel et al.（arXiv:2502.14297）の評価では「文献レビューが単純なキーワード検索止まりで novelty 判定が甘い」という指摘もあります⁷¹。仮説駆動を AI に任せきりにするのはまだ早いですが、人間が仮説を組んで AI に反復検証させる使い方は、既に高い成果を出しています。

ナレッジグラフとリサーチ設計

もう一つ、AI 時代のリサーチ設計を語る上で外せないのが、ナレッジグラフです。

Microsoft GraphRAG は「私有データから LLM がナレッジグラフを自動抽出し、階層的コミュニティ要約を作って RAG の Retrieval を根本的に改善。narrative data での全体理解に強い」と発表されています⁷²⁷³。global search と local search の二層設計は、リサーチの粒度切替（俯瞰 vs 深掘り）と一対一で対応します。イシューツリーの上位論点と下位論点の関係が、そのまま実装されている構造です。

Neo4j LLM Knowledge Graph Builder は、PDF・Web・YouTube 等の非構造テキストを lexical graph + entity graph に自動変換し、GraphRAG/Vector/Text2Cypher を切替できます⁷⁴。Ontotext はがん研究の Target Discovery、金融アセット管理、電力網最適化などで KG + LLM の実運用事例を出しています⁷⁵。

日本発の Snorbe（Deskrex）は、意味空間・ナレッジグラフ・文字列インデックスの3層で調査結果を蓄積する設計です。プレスリリースでは「既存のツールでは『一問一答型』の設計に留まっており、『調査の連鎖』を十分に支援できていませんでした。Snorbe は調査結果だけでなく調査のプロセスそのものを構造化し、組織の知的資産として蓄積・活用できる」と位置づけられています⁷⁶。

ナレッジグラフ型のリサーチエージェントは、リサーチ設計の「検証可能性の担保」を、単発の調査から組織の記憶に持ち上げる方向に進化しています。学術的な文脈で言えば、「validity と reliability を、個別の論文レベルではなく、リサーチプログラム全体でモニタリングする」という設計思想の実装です。

セクション3のまとめです。Deep Research 系ツールの発展は、AI 側の性能だけでなく、リサーチ設計フレームの再評価を促しています。イシューツリー・RQ・仮説駆動の3フレームは AI Agent アーキテクチャに直接埋め込まれつつあり、人間側の使いこなし方が調査品質を決める段階に入っています。次のセクションでは、30分で組めるリサーチ設計テンプレと、よくある失敗5つを見ていきます。

出典

30分で組むリサーチ設計テンプレとよくある失敗5つ

ここまでで、リサーチ設計の3機能（目的の明確化・方法論の選択・検証可能性の担保）と、4つの主要フレーム、そして AI 時代の相性を見てきました。ここからは実務に落として、「30分でリサーチ設計を組む型」と、「よくある失敗5つ」を並べて見ていきます。

コンサル流の順番 産業レポートから当たる

コンサル流のデスクリサーチには、明確な順番があります。Rally Note は「デスクリサーチには順序に明確な『型』があり、①産業レポート、②省庁資料・信頼できる統計、③企業資料（IR・決算・プレスリリース）、④Google 検索やニュース、の順で当たる」と整理しています⁷⁷。

この順番が大事な理由は、抽象度と信頼性のバランスです。産業レポートは業界全体を俯瞰でき、省庁資料は数字の信頼性が高く、企業資料は個別事例の解像度が高く、Google 検索は最新性が高い。俯瞰から個別へ、抽象から具体へ、という流れで積み上げていくと、途中でスコープが定まって、無駄な情報を吸い込まなくて済みます。

Biz-Con Plus は「コンサルは調査結果をまとめるとき、いきなりパワポを作らない。最初に作るのは『論点メモ（1〜2ページのテキスト）』で、結論／主要示唆3つ／根拠5〜8ファクト／今後調査すべき点から成る」と書いています⁷⁸。この論点メモが、リサーチ設計の「目的の明確化」と「検証可能性の担保」を同時に担う便利な道具です。

ConStep はコンサル1年目の型として「Week 1 で親イシュー → サブイシュー → 各論点への仮説とアプローチ → Work Plan、という順で組む。論点設計は『解くべき問い』の構造化、仮説思考は『その問いへの仮の答え』を先に置く思考法で、両者は補完関係」と整理しています⁷⁹。

安宅和人 よいイシューの3条件

安宅和人『イシューからはじめよ』は、リサーチ設計を語る上で外せない実務書です。「よいイシューの3条件は、①本質的（答えが出るとその先の方向性が大きく変わる）、②深い仮説がある（常識とは違うが賛否両論になるような）、③答えを出せる」と整理されています⁸⁰。

この3条件は、Deep Research にプロンプトを投げるときのチェックリストとしてもそのまま使えます。「本質的か」→ そのレポートが返ってきたら意思決定が変わるか。「深い仮説があるか」→ プロンプトに「私はこう考えているが、反証があれば教えてほしい」と書けるか。「答えを出せるか」→ 5〜30分の Deep Research で結論に到達できるか。3条件を通らない問いは、AI に投げても薄いレポートが返ってきます。

Product DiscoveryのVUFB リスク

PdM 側では、SVPG の Marty Cagan が Product Discovery の framing で4つのリスクを整理しています。Value（価値、顧客がこれを買うか）、Usability（可用性、使いこなせるか）、Feasibility（実現可能性、作れるか）、Business Viability（事業性、ビジネスとして成立するか）の4つです⁸¹。

リサーチ設計の視点では、この4リスクは「何を検証しに行くか」の4分類です。同じテーマでも、Value を検証するリサーチと Feasibility を検証するリサーチでは、集める情報が全く違います。イシューツリーを引くとき、まず4リスクのどれを扱うのかを決めておくと、下流の分解軸がぶれません。

AI調査エージェント向けプロンプト8項目テンプレ

Deep Research 系ツールに投げるプロンプトも、テンプレ化が進んでいます。Odaiji.com は「目的／前提／範囲／評価軸／出力形式／除外／期限／品質基準」の8項目テンプレを提示しています⁸²。

ノーコード総合研究所は「Perplexity Deep Research 活用の肝は、質問の粒度よりも調査設計の明文化。目的・評価指標・範囲・形式・引用ルールを最初に固定するとLLM の探索と要約が安定する」と書いています⁸³。応答は「主語・時制・内容指定・条件指定」の4部品で決まる、というのも実践的な整理です。

AI エージェントナビは「仮説を先に提示してその検証を依頼し、反証も求める」と添えることでバランスの取れた調査になると指摘しています⁸⁴。Popper の反証可能性の思想を、そのままプロンプト設計に組み込む発想です。

Incremys は「plan → collect → extract → verify → deliver」を AI エージェント型リサーチの汎用フローとして提示し、「自動化が進んでもパフォーマンスは『ブリーフ（目的・スコープ・期待形式・エビデンス水準）の明確さ』に依存し続ける」と結論づけています⁸⁵。ここでも、リサーチ設計＝ブリーフの明確化、という構造は同じです。

しょこら氏は CO-STAR フレームワーク（Context/Objective/Style/Tone/Audience/Response）を紹介しつつ、「曖昧な Yes/No 質問（『コーヒーは体に良いですか？』）は詳細な情報を引き出せない。『コーヒーを飲むことのメリットとリスクは何ですか？』と聞くことでバランスの取れた回答が得られる」という例で、二重問いを避ける実務を示しています⁸⁶。

チーム利用時のドキュメント化

個人で使うだけなら8項目テンプレで十分ですが、チームで蓄積するなら、もう一段ドキュメント化が必要です。Sansan の UX リサーチセンター（2021年6月発足）は「デプスインタビューやユーザビリティテストの『目的の確認→調査方法→対象者選定→調査票／インタビューフロー作成→報告書・調査ログ→ペルソナ・共感マップ・CJM などモデリング成果物』までを標準ワークフローとしてドキュメント化」しています⁸⁷。

Notion は Google が公開した UXR 手順を Notion 化した公式テンプレ『UX Research Plan Template』を提供しています⁸⁸。ResearchOps 実務者の Medium 記事では「組織化するツールはスプレッドシート、Notion、Airtable、Confluence のどれでもよい。重要なのは構造とアクセスコントロール」と指摘されています⁸⁹。

よくある失敗5つ

リサーチ設計でハマる失敗パターンは、大きく5つに整理できます。実務ブログや失敗事例集を横断すると、繰り返し出てくる失敗です。

1つ目は範囲爆発（スコープクリープ）です。Lucidchart は「開始後に『ちょっとこの観点も』『関連してこの業界も』が積み重なり、当初の設計が際限なく膨張する」現象を指摘しています⁹⁰。予防策は、リサーチ設計時点で「除外項目」を明示的に書き出しておくことです。Odaiji 8項目テンプレの「除外」欄が、この機能を担います。

2つ目は検証不可（Non-testable）です。Popper の反証可能性を担保しない仮説を持つと、いくら調査しても結論が出ません⁹¹。「この商品は素晴らしい」といった主観的な命題は反証しようがないので、リサーチの目的にはできません。「この商品はターゲット層の月間利用回数を X% 上げる」のように、観測可能な命題に落とし込む必要があります。

3つ目は二重問い（ダブルバーレル質問）です。Research Plus は「1つの設問に複数の論点を含めながら回答は1つしか求めない誤り」と定義しています⁹²。AI エージェントへの問いでも「A と B は何が違う？そしてどっちを使うべき？」のような二重問いは、分割必須です。分割せずに投げると、Deep Research が両方を中途半端に扱って、どちらも浅くなります。

4つ目は MECE 違反です。分解軸のディメンジョン（抽象度）が統一されていない、クライテリア（分類基準）が未設定、といったパターンが典型です⁹³。イシューツリーを引くとき、同じ階層の枝葉の抽象度をそろえる、という基本を守るだけで、下流の探索の網羅性が大きく改善します。

5つ目は上位論点の欠落です。StrategyU は「defined the problem appropriately or are there deeper issues」を反復検証する必要があると指摘しています⁹⁴。CREX の失敗事例集は「調査のための調査」で終わる典型パターンを実例付きで解説していて、「そもそも解くべき問いを間違えていた」という失敗が、時間もお金も一番失うタイプの失敗だとわかります⁹⁵。

この5つに加えて、「顧客の言うこと vs 顧客の行動」のギャップ問題も見逃せません。Point Marketing は「お客様のおっしゃることと、実際の行動は全く違う。顧客の希望ばかりを聞いてその通りにしてはいけない」と警告しています⁹⁶。言語データ（インタビュー・アンケート）に偏りやすいので、行動データ（ログ・観察・シャドーイング）とのトライアンギュレーションを設計段階で組んでおかないと、一次要因を見逃します。

30分テンプレのまとめ

以上を組み合わせて、30分でリサーチ設計を組むミニテンプレを提示します。

• 5分：親イシューを1文で書く（安宅の3条件を通す）
• 5分：Odaiji 8項目（目的・前提・範囲・評価軸・出力形式・除外・期限・品質基準）を埋める
• 5分：4リスク（Value/Usability/Feasibility/Business Viability）のどれを検証するか決める
• 5分：仮説を2つ書き出す（賛否両論になるやつ）
• 5分：MECE でサブイシュー3〜5個に分解する
• 5分：反証データが出たら仮説を撤回する条件を明示する

30分で埋まれば、Deep Research 系ツールにも、人間チームにも、そのままブリーフとして渡せる状態になります。

セクション4のまとめです。実務でリサーチ設計を組むときは、コンサル流の順番、安宅の3条件、Product Discovery の4リスク、AI 向け8項目テンプレ、5つの失敗パターン、の5つを組み合わせるのが定石です。次のセクションでは、これらのリサーチ設計を「調査の連鎖」として蓄積する Snorbe という別軸の選択肢を見ていきます。

出典

調査の連鎖を蓄積する Snorbeという別軸の選択肢

ここまでで、リサーチ設計の4フレームと、AI 時代の相性、実務テンプレを見てきました。ただ、実務で Deep Research 系ツールを使い込むと、もう一段の壁にぶつかります。それは「調査の連鎖」の問題です。

一問一答型 Deep Research の限界

Perplexity Deep Research、OpenAI Deep Research、Google Gemini Deep Research のいずれも、基本的な設計は「1回のクエリを丁寧に扱う」です。プロンプトを投げて、5〜30分で1本のレポートが返ってきます。ここまでは、これまでの3セクションで見た通りです。

問題は、その次です。「今日調べた結果を、明日の調査に接続する」機能が、多くのツールで弱いままです。ChatSense の解説は「継続的思考サイクルで、表面情報から本質的洞察へ段階的に深化する」と紹介しますが⁹⁷、この「継続的」は1回のセッション内での継続であって、日をまたぐ調査プロジェクトの継続ではありません。

Teresa Torres の Continuous Discovery は、この壁を的確に指摘しています。彼女は「If your research questions aren’t changing every week, you’re not learning every week.」と述べていて、リサーチクエスチョンが毎週アップデートされる仕組みを持つことが、学習し続けるチームの条件だと定義しています⁹⁸⁹⁹。

一問一答型の Deep Research では、毎週の RQ アップデートを人間側で全部管理することになります。「先週のレポートで何が分かって、今週は何を追加で調べるべきか」を、人間がメタに把握し続ける必要があるわけです。これがボトルネックになります。

統合型リサーチプラットフォームへのフレーム内蔵化

この壁を意識してか、リサーチプラットフォーム側が、フレームワークを内蔵する方向に進化しています。

Elicit は、ミニ系統的レビュープロセス（PICO 相当）を UI に組み込んでいます¹⁰⁰。検索→スクリーニング→データ抽出→合成、全主張が原論文の逐語引用にリンク、という流れが、そのままツールの標準ワークフローになっています。Consensus は、PICO で検索戦略を自動構築し、引用グラフ探索を提供しています¹⁰¹。学術系フレームを、ユーザーが意識せずに使えるように内蔵する方向です。

Snorbe（Deskrex）は、この方向をさらに一歩進めて、ナレッジグラフでリサーチ設計そのものを蓄積可能な資産にする設計を採用しています。

Snorbe の3層設計

Snorbe は、意味空間・ナレッジグラフ・文字列インデックスの3層でリサーチ結果を蓄積するリサーチエージェントです¹⁰²。

意味空間は、これまでの調査結果を意味的な類似度で検索できるようにするレイヤーです。ベクトル埋め込みで、キーワード完全一致では拾えない意味的関連を検索できます。

ナレッジグラフは、調査対象と対象、対象と論点、論点と論拠、といった関係性を構造化して保存するレイヤーです。ここが Snorbe の中核で、「調査の連鎖」を組織の知的資産として蓄積する仕組みです。学術のリサーチ設計で言う「validity と reliability を、個別の論文レベルではなく、リサーチプログラム全体でモニタリングする」機能を、ここで実装しています。

文字列インデックスは、原典の逐語引用を正確に取り出すためのレイヤーです。Elicit や Consensus と同じ思想で、レポートの全主張が原典にリンクで戻れる状態を保ちます。

この3層が組み合わさることで、「今週の RQ が来週の RQ に自然に繋がる」設計が実装されています。プレスリリースでは「Snorbe は調査結果だけでなく調査のプロセスそのものを構造化し、組織の知的資産として蓄積・活用できる」と位置づけられています¹⁰³。

専門DB6種の統合

Snorbe のもう一つの強みは、専門データベースを6種類統合していることです。JPO（日本特許庁）、EPO（欧州特許庁）、Google Patents、arXiv、PubMed、Semantic Scholar の6種です。

これらのデータベースは、それぞれ独自の検索クエリ言語を持っています。特許なら CPC/IPC 分類、論文なら MeSH 用語や arXiv カテゴリ、といった具合です。従来は、各データベースのクエリ言語を覚えて、検索式を組んで、結果を手作業でマージする必要がありました。学術の RQ 定式化を PICO で書けても、それを検索式に落とし込むところが別作業だ、というのは既存の RQ フレームの弱点として本記事の Section 2 でも触れました。

Snorbe は、この壁を「自然な日本語のクエリで、専門DB を横断検索する」形で埋めています。ユーザーは「AI エージェントの記憶設計に関する最新論文と、関連特許を出してほしい」と自然な日本語で投げるだけで、arXiv / PubMed / Semantic Scholar と、Google Patents / JPO / EPO を同時に叩ける設計です。

対話を跨いで文脈を保持する体験

もう一つ、Snorbe が既存の Deep Research ツールと違うのが、「対話を跨いで文脈を保持する」設計です。

一問一答型の Deep Research では、セッションが変わると、AI 側は前回何を調べたかを覚えていません。ユーザー側が「先週こういうことを調べて、こう結論づけたので、今週はここから続けたい」とプロンプトに書き直す必要があります。

Snorbe は、これまでの調査履歴がナレッジグラフとして蓄積されているので、次のセッションで「前回の続きから」を自然に扱えます。プレスリリースでは「自己進化型」と表現されていて、使えば使うほど個人・組織固有の知識構造が育っていく設計です¹⁰⁴。

これは、リサーチ設計の視点から見ると、Teresa Torres の週次 RQ アップデートを、ツール側が自然に支援する構造です。「先週の RQ で分かったことは A と B、まだ分からないのは C と D、来週の RQ は D の深掘り」という流れを、ナレッジグラフが自動で構造化してくれます。

今から試せる反復ループの入口

Grand Tour の締めくくりに、Snorbe で今から試せる反復ループを整理します。

1日目：Snorbe に、これまで自分が扱ってきたテーマの1つを投げてみます。自然な日本語で「〇〇分野の最新動向を、論文と特許を横断で調べてほしい」と書けば、専門DB6種を叩いて結果が返ってきます。

2日目：返ってきたレポートを見て、「深掘りしたい論点」を1つ選び、追加のクエリを投げます。前日のセッションの文脈が保持されているので、「昨日調べた〇〇の論点をもう一段深く」と書くだけで、続きから探索できます。

3日目以降：ナレッジグラフが育っていくので、「今週の RQ は先週の何と繋がっているか」を Snorbe 側が示してくれます。ここから、Teresa Torres の週次 RQ アップデートを、ツール側が半自動で支援する体験が始まります。

一問一答型の Deep Research を使いこなすトラックも、もちろん有効です。Perplexity、OpenAI、Gemini、Elicit、Consensus のいずれも、1回のクエリを丁寧に扱う設計としては十分な性能を持っています。Snorbe は、これらの選択肢に「調査の連鎖を蓄積する」という別軸を加える、新しい選択肢として位置づけられます。

リサーチ設計は、AI 時代になって死んだのではなく、逆に真価を発揮する段階に入りました。イシューツリー・RQ・仮説駆動の3フレームが AI Agent アーキテクチャに組み込まれ、人間側の問い設計が調査の質を決めるようになりました。ここに、調査の連鎖を蓄積する仕組みが加われば、リサーチ設計は「1回1回の調査計画」から「組織の知的資産を育てる継続的なプロセス」に進化します。

このプロセスを今から回してみたい方は、Snorbe の公式サイト（https://lp.deskrex.ai/）から使い始められます。

出典

よくある質問

Q1. リサーチ設計と調査設計、研究設計、問い設計は何が違いますか

指しているものは同じですが、聞き手に届くイメージが違います。「調査設計」は市場調査・世論調査・アンケート調査の実務的な文脈で使われます。「研究設計」は Research Design の直訳で、学術（特に看護・社会科学・心理学）の教科書で使われます。「問い設計」は実務コンサル寄りの用法で、AI プロンプト設計の文脈でも使われます。学術寄りの場面なら「研究設計」、市場調査なら「調査設計」、AI プロンプトや戦略コンサル寄りなら「問い設計」を選ぶと、話が通じやすいです。

Q2. イシューツリーとロジックツリーとリサーチクエスチョンは、どう使い分けますか

得意な場面が違います。イシューツリーは論点分解が軸足で、プロジェクト初期に「何を扱うか」を棚卸しするときに使います。ロジックツリーは因果分解と打ち手展開が軸足で、Why ツリー（原因追究）、How ツリー（施策展開）、KPI ツリー（数式分解）の3類型があります。リサーチクエスチョンは焦点絞り込みが軸足で、FINER 基準や PICO で調査対象を検索式まで落とし込みます。実務では、イシューツリー→リサーチクエスチョン→仮説駆動の順で組み合わせて使うのが典型です。

Q3. Deep Research にプロンプトを投げるとき、どう設計すれば深い調査になりますか

「目的／前提／範囲／評価軸／出力形式／除外／期限／品質基準」の8項目を明文化するのが実務的な定石です（Odaiji.com のテンプレ）。加えて、「仮説を先に提示してその検証を依頼し、反証も求める」と書き添えると、確証バイアスを避けたバランスの取れたレポートが返ってきます。CO-STAR フレームワーク（Context/Objective/Style/Tone/Audience/Response）も有効です。曖昧な Yes/No 質問ではなく、複数観点を要求する構造化された質問にすることで、Deep Research の探索が深くなります。

Q4. 学術の PICO は実務でも使えますか

使えます。PICO は Population（対象）、Intervention（介入）、Comparison（比較）、Outcome（結果）の4要素で、もともと Cochrane Handbook がシステマティックレビュー用に採用したフレームですが、社会科学向けに拡張された PICOC（Context 追加）はソフトウェア工学の SLR（Systematic Literature Review）でも標準化されています。実務のマーケットリサーチでも、「どのユーザー層を対象に、どの施策を投入して、何と比較して、どんな成果を測るか」を PICO で書き出すと、調査の焦点が絞れます。

Q5. AI 時代に「リサーチスキルは死んだ」というのは本当ですか

半分本当で、半分嘘です。従来型の「情報を集めて要約する」というリサーチ作業は、Deep Research 系ツールに大部分を置き換えられました。SBクリエイティブのビジネス+IT は「コンサル『大失業時代』がいよいよ現実に？」と題した記事で、この置き換えを扱っています。ただし、「何を調べるかを設計する」リサーチ設計スキルは、逆に価値が跳ね上がっています。プロンプトエンジニアという肩書きが職務記述書の1行に格下げされる中で、その上位にある「What 定義力」「コンテキストエンジニアリング」の価値が上がっている、というのが日英両方の論考の帰結です。

Q6. チームで使えるリサーチ設計テンプレはありますか

いくつか有力な選択肢があります。Notion が公開している『UX Research Plan Template』は Google の UXR 手順を Notion 化した公式テンプレです。Sansan は UX リサーチセンター（2021年6月発足）で「目的の確認→調査方法→対象者選定→調査票／インタビューフロー作成→報告書・調査ログ→ペルソナ・共感マップ・CJM」までの標準ワークフローを社内でドキュメント化しています。ツールはスプレッドシート、Notion、Airtable、Confluence のどれでも構いません。重要なのは構造（親イシュー・サブイシュー・仮説・検証条件を明示する型）とアクセスコントロールを整えることです。

---

1. ChatSense — Deep Research. https://chatsense.jp/function/deep-research↩︎

2. Product Talk — Continuous Discovery. https://www.producttalk.org/glossary-discovery-continuous-discovery/↩︎

3. Lenny’s Newsletter — Teresa Torres. https://www.lennysnewsletter.com/p/teresa-torres-on-how-to-interview↩︎

4. Elicit — Reports. https://elicit.com/solutions/reports↩︎

5. Consensus. https://consensus.app/search↩︎

6. 毎日新聞 — Snorbe プレスリリース. https://mainichi.jp/articles/20260526/pr2/00m/020/361000c↩︎

7. ノーコード総合研究所 — Perplexityプロンプトマスターガイド. https://nocoderi.co.jp/2025/05/03/perplexity-prompt-master-guide/↩︎

8. AIエージェントナビ — Perplexity Deep Researchガイド. https://aiagent-navi.com/ai-agent/perplexity-deep-research-guide/↩︎

9. Incremys — Perplexity AI Agent. https://www.incremys.com/en/resources/blog/perplexity-ai-agent↩︎

10. しょこら — Deep Researchプロンプト設計ガイド. https://note.com/chocolats/n/n6a388e3d72c1↩︎

11. Sansan Tech Blog — UXリサーチセンター. https://buildersbox.corp-sansan.com/entry/2021/06/11/123000↩︎

12. Notion — UX Research Plan Template. https://www.notion.com/templates/ux-research-plan↩︎

13. Medium — ResearchOps. https://medium.com/@shannon.alexandrine/research-ops-how-to-start-structure-and-scale-your-research-operations-98ca3aae1515↩︎

14. Lucidchart — スコープクリープ対策. https://lucid.co/ja/blog/how-to-avoid-scope-creep↩︎

15. ChatSense — Deep Research. https://chatsense.jp/function/deep-research↩︎

16. Product Talk — Continuous Discovery. https://www.producttalk.org/glossary-discovery-continuous-discovery/↩︎

17. Lenny’s Newsletter — Teresa Torres. https://www.lennysnewsletter.com/p/teresa-torres-on-how-to-interview↩︎

18. ChatSense — Deep Research. https://chatsense.jp/function/deep-research↩︎

19. Elicit — Reports. https://elicit.com/solutions/reports↩︎

20. Consensus. https://consensus.app/search↩︎

21. 毎日新聞 — Snorbe プレスリリース. https://mainichi.jp/articles/20260526/pr2/00m/020/361000c↩︎

22. ノーコード総合研究所 — Perplexityプロンプトマスターガイド. https://nocoderi.co.jp/2025/05/03/perplexity-prompt-master-guide/↩︎

23. AIエージェントナビ — Perplexity Deep Researchガイド. https://aiagent-navi.com/ai-agent/perplexity-deep-research-guide/↩︎

24. Incremys — Perplexity AI Agent. https://www.incremys.com/en/resources/blog/perplexity-ai-agent↩︎

25. しょこら — Deep Researchプロンプト設計ガイド. https://note.com/chocolats/n/n6a388e3d72c1↩︎

26. Sansan Tech Blog — UXリサーチセンター. https://buildersbox.corp-sansan.com/entry/2021/06/11/123000↩︎

27. Notion — UX Research Plan Template. https://www.notion.com/templates/ux-research-plan↩︎

28. Medium — ResearchOps. https://medium.com/@shannon.alexandrine/research-ops-how-to-start-structure-and-scale-your-research-operations-98ca3aae1515↩︎

29. Lucidchart — スコープクリープ対策. https://lucid.co/ja/blog/how-to-avoid-scope-creep↩︎

30. Stanford Encyclopedia of Philosophy — Karl Popper. https://plato.stanford.edu/entries/popper/↩︎

31. Research Plus — ダブルバーレル質問. https://freeasy24.research-plus.net/blog/w378↩︎

32. Panhouse Blog — Issue Tree. https://panhouse.blog/memo/20210919/↩︎

33. StrategyU — Issue Tree. https://strategyu.co/issue-tree/↩︎

34. CREX — 市場調査の失敗事例. https://crexgroup.com/ja/data/column/market-research-basics/market-research-failure-cases-2/↩︎

35. Point Marketing — 顧客の言葉と行動のギャップ. https://point-marketing.jp/1143↩︎

36. arXiv 2310.06155 — CoQuest. https://arxiv.org/html/2310.06155v3↩︎

37. arXiv 2201.11903 — Chain-of-Thought Prompting. https://arxiv.org/abs/2201.11903↩︎

38. Google Research — Self-Consistency CoT. https://research.google/pubs/self-consistency-improves-chain-of-thought-reasoning-in-language-models/↩︎

39. arXiv 2305.10601 — Tree of Thoughts. https://arxiv.org/abs/2305.10601↩︎

40. ChatSense — Deep Research. https://chatsense.jp/function/deep-research↩︎

41. arXiv 2408.06292 — AI Scientist. https://arxiv.org/abs/2408.06292↩︎

42. arXiv 2504.08066 — AI Scientist v2. https://arxiv.org/abs/2504.08066↩︎

43. arXiv 2502.14297 — Evaluating Sakana’s AI Scientist. https://arxiv.org/html/2502.14297v2↩︎

44. ChatSense — Deep Research. https://chatsense.jp/function/deep-research↩︎

45. Product Talk — Continuous Discovery. https://www.producttalk.org/glossary-discovery-continuous-discovery/↩︎

46. Lenny’s Newsletter — Teresa Torres. https://www.lennysnewsletter.com/p/teresa-torres-on-how-to-interview↩︎

47. Elicit — Reports. https://elicit.com/solutions/reports↩︎

48. Consensus. https://consensus.app/search↩︎

49. 毎日新聞 — Snorbe プレスリリース. https://mainichi.jp/articles/20260526/pr2/00m/020/361000c↩︎

50. ノーコード総合研究所 — Perplexityプロンプトマスターガイド. https://nocoderi.co.jp/2025/05/03/perplexity-prompt-master-guide/↩︎

51. AIエージェントナビ — Perplexity Deep Researchガイド. https://aiagent-navi.com/ai-agent/perplexity-deep-research-guide/↩︎

52. Incremys — Perplexity AI Agent. https://www.incremys.com/en/resources/blog/perplexity-ai-agent↩︎

53. しょこら — Deep Researchプロンプト設計ガイド. https://note.com/chocolats/n/n6a388e3d72c1↩︎

54. Sansan Tech Blog — UXリサーチセンター. https://buildersbox.corp-sansan.com/entry/2021/06/11/123000↩︎

55. Notion — UX Research Plan Template. https://www.notion.com/templates/ux-research-plan↩︎

56. Medium — ResearchOps. https://medium.com/@shannon.alexandrine/research-ops-how-to-start-structure-and-scale-your-research-operations-98ca3aae1515↩︎

57. Lucidchart — スコープクリープ対策. https://lucid.co/ja/blog/how-to-avoid-scope-creep↩︎

58. Stanford Encyclopedia of Philosophy — Karl Popper. https://plato.stanford.edu/entries/popper/↩︎

59. Research Plus — ダブルバーレル質問. https://freeasy24.research-plus.net/blog/w378↩︎

60. Panhouse Blog — Issue Tree. https://panhouse.blog/memo/20210919/↩︎

61. StrategyU — Issue Tree. https://strategyu.co/issue-tree/↩︎

62. CREX — 市場調査の失敗事例. https://crexgroup.com/ja/data/column/market-research-basics/market-research-failure-cases-2/↩︎

63. Point Marketing — 顧客の言葉と行動のギャップ. https://point-marketing.jp/1143↩︎

64. arXiv 2310.06155 — CoQuest. https://arxiv.org/html/2310.06155v3↩︎

65. arXiv 2201.11903 — Chain-of-Thought Prompting. https://arxiv.org/abs/2201.11903↩︎

66. Google Research — Self-Consistency CoT. https://research.google/pubs/self-consistency-improves-chain-of-thought-reasoning-in-language-models/↩︎

67. arXiv 2305.10601 — Tree of Thoughts. https://arxiv.org/abs/2305.10601↩︎

68. ChatSense — Deep Research. https://chatsense.jp/function/deep-research↩︎

69. arXiv 2408.06292 — AI Scientist. https://arxiv.org/abs/2408.06292↩︎

70. arXiv 2504.08066 — AI Scientist v2. https://arxiv.org/abs/2504.08066↩︎

71. arXiv 2502.14297 — Evaluating Sakana’s AI Scientist. https://arxiv.org/html/2502.14297v2↩︎

72. Microsoft Research — GraphRAG. https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/↩︎

73. Microsoft Research — GraphRAG Project. https://www.microsoft.com/en-us/research/project/graphrag/↩︎

74. Neo4j — LLM Knowledge Graph Builder. https://neo4j.com/labs/genai-ecosystem/llm-graph-builder/↩︎

75. Ontotext — Case Studies. https://www.ontotext.com/knowledge-hub/case-studies/↩︎

76. ノーコード総合研究所 — Perplexityプロンプトマスターガイド. https://nocoderi.co.jp/2025/05/03/perplexity-prompt-master-guide/↩︎

77. ChatSense — Deep Research. https://chatsense.jp/function/deep-research↩︎

78. Product Talk — Continuous Discovery. https://www.producttalk.org/glossary-discovery-continuous-discovery/↩︎

79. Lenny’s Newsletter — Teresa Torres. https://www.lennysnewsletter.com/p/teresa-torres-on-how-to-interview↩︎

80. Elicit — Reports. https://elicit.com/solutions/reports↩︎

81. Consensus. https://consensus.app/search↩︎

82. 毎日新聞 — Snorbe プレスリリース. https://mainichi.jp/articles/20260526/pr2/00m/020/361000c↩︎

83. ノーコード総合研究所 — Perplexityプロンプトマスターガイド. https://nocoderi.co.jp/2025/05/03/perplexity-prompt-master-guide/↩︎

84. AIエージェントナビ — Perplexity Deep Researchガイド. https://aiagent-navi.com/ai-agent/perplexity-deep-research-guide/↩︎

85. Incremys — Perplexity AI Agent. https://www.incremys.com/en/resources/blog/perplexity-ai-agent↩︎

86. しょこら — Deep Researchプロンプト設計ガイド. https://note.com/chocolats/n/n6a388e3d72c1↩︎

87. Sansan Tech Blog — UXリサーチセンター. https://buildersbox.corp-sansan.com/entry/2021/06/11/123000↩︎

88. Notion — UX Research Plan Template. https://www.notion.com/templates/ux-research-plan↩︎

89. Medium — ResearchOps. https://medium.com/@shannon.alexandrine/research-ops-how-to-start-structure-and-scale-your-research-operations-98ca3aae1515↩︎

90. Lucidchart — スコープクリープ対策. https://lucid.co/ja/blog/how-to-avoid-scope-creep↩︎

91. Stanford Encyclopedia of Philosophy — Karl Popper. https://plato.stanford.edu/entries/popper/↩︎

92. Research Plus — ダブルバーレル質問. https://freeasy24.research-plus.net/blog/w378↩︎

93. Panhouse Blog — Issue Tree. https://panhouse.blog/memo/20210919/↩︎

94. StrategyU — Issue Tree. https://strategyu.co/issue-tree/↩︎

95. CREX — 市場調査の失敗事例. https://crexgroup.com/ja/data/column/market-research-basics/market-research-failure-cases-2/↩︎

96. Point Marketing — 顧客の言葉と行動のギャップ. https://point-marketing.jp/1143↩︎

97. ChatSense — Deep Research. https://chatsense.jp/function/deep-research↩︎

98. Product Talk — Continuous Discovery. https://www.producttalk.org/glossary-discovery-continuous-discovery/↩︎

99. Lenny’s Newsletter — Teresa Torres. https://www.lennysnewsletter.com/p/teresa-torres-on-how-to-interview↩︎

100. Elicit — Reports. https://elicit.com/solutions/reports↩︎

101. Consensus. https://consensus.app/search↩︎

102. 毎日新聞 — Snorbe プレスリリース. https://mainichi.jp/articles/20260526/pr2/00m/020/361000c↩︎

103. 毎日新聞 — Snorbe プレスリリース. https://mainichi.jp/articles/20260526/pr2/00m/020/361000c↩︎

104. 毎日新聞 — Snorbe プレスリリース. https://mainichi.jp/articles/20260526/pr2/00m/020/361000c↩︎