market-researcher

市場調査担当

市場に関する質問のためのデスクリサーチエンジンです。「Xを構築すべきか？」や「ブラジルにおけるYの市場規模は？」といった生の質問を受け取り、すべての事実に関する主張が登録済みの情報源にたどれる調査レポートを返します。これは一般的なAI市場分析に欠けている規律であり、このスキルが存在する理由です。自信たっぷりに捏造された市場規模は、本物とまったく同じように見えます。以下の引用の仕組みによって、違いを検出できます。

このスキルが行うのはデスクリサーチのみです。対象はウェブ上の情報源、公的データ、ユーザーが提供する文書です。この制約を正直に前提として設計しています。顧客について得られるのは、需要のシグナルと仮説であり、検証済みのインサイトでは決してありません（必須事項5を参照）。

必須事項

以下の5つのルールは、このスキルのほかのすべてのルールより優先されます。

1. すべての主張を追跡できます。 成果物に含まれるすべての数値と事実に関する主張には、sources.md の項目に対応するソースタグ [S#] を付けるか、数式と引用した入力値を示した明示的な派生推定値を付けるか、(assumption A#) とラベルを付けます。口調の権威性に頼ることはできません。タグなしで「市場は急速に成長しています」と書いていることに気付いたら、作業を止めて情報源を探すか、その文を削除してください。
2. 最新の事実は記憶ではなくウェブから得ます。 市場規模、価格、競合他社の製品、資金調達、規制などは、最新の情報を調査してください。学習データは古く、さらに悪いことに、統計的にもっともらしいものです。ウェブにアクセスできない場合は、その旨を伝えて作業を止めてください。引用のないエッセイに切り替えてはいけません。
3. 複数の情報を照合し、黙って平均してはいけません。 意思決定に必要な場合は、複数の手法で市場規模を算出してください。信頼できる情報源や手法の間に約2倍を超える差がある場合は、その食い違いを報告し、市場の定義、対象年、通貨、売上高とGMVの違いなど、原因を診断してください。平均して差を消してはいけません。
4. 納品前に検証作業を行います。 懐疑的な立場で主要な主張を情報源と照合し、推定の計算をやり直し、古いデータにフラグを付けます。解決できない点は黙って削除せず、留保事項としてレポートに記載します。
5. デスクリサーチで得られるのはシグナルであり、検証済みの顧客インサイトではありません。 ここで作成するペルソナとニーズは、ユーザーまたは呼び出し元のスキルが担う、実際の一次調査（インタビュー、テスト）で検証する仮説です。そのように明記し、顧客に関するセクションは必ず「一次調査に向けた未解決の質問」で締めくくってください。

前提条件

ウェブ検索とウェブ取得が必要です。何かを約束する前に利用可能か確認してください。利用できない場合は、必要なものをユーザーに伝えて作業を止め、学習データから回答してはいけません（必須事項2）。

ツールの使用コスト

デスクリサーチは、閲覧ではなく読解です。テキストを取得できる最も低コストのツールを、次の順に使用してください。

1. 組み込みのウェブ検索（WebSearch または同等の機能）で情報源を探します。
2. 組み込みの取得機能（WebFetch または同等の機能）で情報源を読みます。ページのテキストが返されれば、引用にはそれだけで十分です。
3. ブラウザー自動化（agent-browser、Chrome／Playwright ツール）は、取得機能ではどうしても読めない特定のページ（JavaScriptのみのレンダリング、操作が必要なコンテンツ）があり、かつ代替の情報源でもカバーされていない場合に限り、最後の手段として使用します。ページの「読解」にスクリーンショットを使ってはいけません。

この順序はスタイル上の好みではなく、コストに関するルールです。ブラウザーのセッションではスクリーンショットやDOMスナップショットにトークンが消費され、その量は調査レーン全体を上回ることがあります。また、取得したテキストでは得られない、引用に必要な情報は何も得られません。別のスキルのガイダンスでブラウザーツールを優先するよう指示されていても、このスキルの調査レーンには適用されません。このルールは、起動するすべてのレーンのサブエージェントに伝えてください。

ハーネスに関する注意点が1つあります。一部の環境では、レポート形式のファイル名（report.md、summary.md、findings-*.md）への書き込みをWriteツールで制限しています。必要な出力ファイルがブロックされた場合は、代わりにシェルのヒアドキュメントで書き込んでください。ファイル名はこのスキルの契約の一部であり、制限を回避するために変更してはいけません。

2つのモード

	クイックスキャン（デフォルト）	ディープダイブ（任意）
質問	「さらに詳しく調べる価値はありますか？」	「具体的にどのような状況に直面するのでしょうか？」
所要時間	1セッション	複数セッション、再開可能
規模の推定	1つの手法＋妥当性チェック、誠実な幅広い範囲	2つ以上の手法、複数の結果を照合
競合他社	5～10社を特定し、各社を1行で紹介	上位3～5社を詳しく分析
顧客	主要な需要シグナル	シグナルの網羅的な調査＋仮説に基づくペルソナ
マクロ	阻害要因／追い風となる要因を2～3点のみ	構造化されたPESTEL分析＋トレンド
成果物	Go／No-Goの概要（約4～8ページ）	モジュール式レポート

デフォルトではクイックスキャンを選び、その旨を伝えてください。「まずクイックスキャンを実施します。判断を大きく左右しそうな領域があれば、そこをディープダイブできます。」ユーザーが詳しい調査を求めている場合、または呼び出し元のスキルで指定されている場合に限り、最初からディープダイブを実施してください。ディープダイブはモジュール式です。ユーザーが調査する領域（規模の推定／競合他社／需要／マクロ）を選びます。意思決定に関係する領域が1つだけなら、形式的に4領域すべてを調査する必要はありません。

クイックスキャンは実際に短時間で済むようにしてください。各領域の調査における登録ソース数は約15件を上限とします。結論の範囲を定めるには十分ですが、決着をつけるための数ではありません。各領域のサブエージェントへのプロンプトにこの上限を明記し、ソースを追加してもその領域の結論が変わらなくなった時点で調査を止めてください。その段階を過ぎて「もう1件」ソースを追加するのは、ユーザーが依頼していないディープダイブの作業です。上限を超える詳細な調査は、ユーザーがコストを承知で選んだディープダイブで行います。受付時に、ユーザーが依頼する内容を伝えてください（「クイックスキャンでも少し時間がかかり、数十件のソースを確認します。ディープダイブは複数セッションにわたる調査です」）。「クイック」という表現で期待させすぎないようにします。

ワークフロー

0. 受付

短いやり取り1回で確認します（聞き取り調査のようにしないでください）。

• 質問の背景にある意思決定。「ペットフード市場を調査してほしい」という依頼の裏に、「ペットフードブランドを立ち上げるために仕事を辞めるべきか？」という意思決定が隠れていることがあります。意思決定によって、調査の深さ、領域、そして「それで何がわかるのか」の意味が決まります。明らかでなければ質問してください。
• 市場定義の案：製品／サービスのカテゴリー、顧客の種類（B2B／B2C）、地域、セグメントに関する制約。市場定義のない市場規模は意味をなしません。
• モード（デフォルトはクイックスキャン）。ディープダイブの場合は、調査する領域も確認します。
• 成果物の保存先：単独で実行する場合は ./research/market/<topic-slug>/。別のスキルのワークスペースから呼び出された場合は、そのスキルが指定するパス（「Composition contract」を参照）。

3～5行で調査の枠組みを伝えて確認してから、開始します。会話ですでに確認できていることを、もう一度尋ねないでください。

1. 調査用ワークスペースを初期化する

bash /mnt/skills/user/market-researcher/scripts/init-research.sh <output-dir> "<topic>" <mode>

このスクリプトはディレクトリ、ソース登録簿である sources.md、再開時に使う進捗トラッキング用の state.md、および report.md の骨組みを作成します。このリポジトリ内で実行する場合は skills/market-researcher/scripts/init-research.sh を使用してください。

2. 調査領域を実行する

4つの領域があり、それぞれに参照ファイルがあります。領域の調査を始める前に参照ファイルを読んでください。

領域	参照ファイル	クイックスキャンでの内容
市場と規模の推定	references/market-sizing.md	1つの手法、範囲
競合他社	references/competitor-analysis.md	5～10社の調査
需要シグナル	references/demand-signals.md	主要なシグナル
トレンドとマクロ	references/trends-macro.md	阻害要因のみ

可能な場合は並行して実施します。 サブエージェントが利用できる場合は、各領域を並行するエージェントとして実行してください。各エージェントには、その領域の参照ファイル、市場定義、モード、引用ルール（references/citation-schema.md を参照するよう指示）を渡します。各領域はワークスペース内に findings-<lane>.md を作成し、使用したすべてのソースを sources.md に登録します。その際、次に空いている [S#] IDを使用してください。サブエージェントを利用できない場合は、各領域を自分で順番に実行します。守るべき手順は同じで、違うのは所要時間だけです。

各領域の出力は、文章主体のエッセイではなく、証拠ファイルにします。主張にはタグを付け、引用はリンクし、推定値は計算過程を示してください。

3. 統合

各レーンの調査結果をすべて読み、レポート本文を作成します（構成は references/report-templates.md を参照）。統合のルール：

• すべてのセクションで「それがどう重要なのか？」を明らかにします。 意思決定に関係しない調査結果は、どれほど興味深くても削除します。
• 厳密さはエビデンスファイルに保ち、レポートは優れたコンサルタントが書いたように仕上げます。 引用タグは残しますが、仕組みに関する説明（レーン名、IDブロックの管理、プロセスの説明）はレポート本文に含めず、state.md に移します。簡潔で明確な表現を優先してください。「15万ドルのアシスタントと比べれば、月額30ドルは安価です［S12］」のほうが、予防線を張った説明を長々と続けるより効果的です。厳密でも読むのに疲れるレポートは、実際にはよく書かれた引用なしのレポートに劣ります。これは文体の好みではなく、このスキルの目的を果たせていないということです。
• 結論は、確信度と根拠を伴う推奨であり、曖昧な保留ではありません。「AとBを理由に、中程度の確信度で実行を推奨します。Cが明らかになれば判断が変わります。」
• 結論の確信度には、構造的なエビデンスの限界を反映させます。 繰り返し見られるものが2つあります。（a）市場規模、販売拠点数、結論の根拠となる事実といったデータの基盤が、単一のベンダーのレポートシリーズに由来する場合、それは確信度の上限になります。その旨は注意事項の一覧ではなく、結論そのものに記載します。（b）最も強いエビデンスが、ユーザーの実際のターゲットではなく隣接するセグメントについて述べている場合（たとえば、すでにソフトウェアに料金を支払っている事業者に関するデータは豊富でも、ユーザーが獲得したいソフトウェア未導入の事業者に関するデータはほとんどない場合）は、その点を結論の箇所で示します。読者が、結論の根拠となる対象集団を把握できるようにしてください。
• レーン間の矛盾は問題ではなく調査結果です。明らかにしてください。（市場規模は大きいものの、支払い意思の兆候がない、というのは典型的で重要な組み合わせです。）
• 最後に、一次調査で明らかにすべき未解決の問いを記載します。デスクリサーチでは確認できなかったことと、その検証方法を示してください。

4. 検証

提出前に、懐疑的な立場で検証します。可能であれば別のサブエージェントを使い、そうでなければ自分で明確に批判的な姿勢を取って確認します。

• レポート内の意思決定に最も関わる主張を約10件選びます。それぞれについて、引用元を開き、レポートの記述（数値、単位、年、市場の定義）が実際に情報源の内容と一致しているか確認します。
• 導出した推定値をすべて、明記された入力値を使って再計算します。期間軸も確認してください。たとえば、2026～2031年のCAGRを2024年の基準値に適用するのは、見過ごされやすい誤りです。年をそろえるか、不一致を明記します。
• 最新情報として提示している2年以上前の情報源と、意思決定に大きな影響を与える単一情報源の主張を特定します。
• 個々の情報源だけでなく、情報源ポートフォリオ全体の健全性も確認します。（a）データの基盤が、特定の出版社、特に調査対象として紹介している競合他社の情報に依存していませんか。（b）確信度が低い情報源が、複数の異なる戦略的主張に使い回されていませんか。（c）問題点や支払い意思に関する引用の出所が、競合他社関連のサイトではありませんか。該当するものは、すべて固有の注意事項として記載します。
• 未解決の事項はすべて、レポート内で明示的な注意事項として記載します。黙って削除したり、黙って残したりしてはいけません。

実施した確認、修正した内容、未解決の事項を state.md の末尾に記録します。

5. 提出

会話で使われている言語で、ユーザーに結論と確信度、判断の根拠となる3～5件の事実、検証で見つかった最大の注意事項、未解決の問いを提示します。1画面に収まる長さにしてください。詳細はレポートファイルに記載します。自然な次のステップとして、特定のレーンを掘り下げる、未解決の問いを一次調査に回す、または後日スキャンを再実行する（市場は変化するため）ことを提案します。

情報源と引用に関する規則

完全なスキーマは references/citation-schema.md にあります。調査結果ファイルを書く前に必ず読んでください。要約すると、sources.md は情報源の登録簿です。各情報源には、ID [S#]、URL、発行元、公開日、アクセス日、信頼度評価（情報源の種類と裏付けに基づく高・中・低）を記載します。主張には [S#] を引用し、導出した推定値には計算式と引用した入力値をインラインで示します。前提条件には A# ID を付け、レポートの前提条件表に記載します。事実を述べる文にタグが付いていない場合は、不具合です。

構成に関する契約（スキルの呼び出し時）

他のスキル（strategy-board、design-thinking、product briefs）は、このスキルを調査エンジンとして利用できます。契約は次のとおりです。

入力 — 呼び出し側は、調査の質問と意思決定の背景、市場の定義（またはこのスキルに定義案の作成を依頼）、モードとレーン、呼び出し側のワークスペース内の出力先ディレクトリ（例：strategy-board の fact-base sources ディレクトリ、design-thinking の research/）を指定します。

出力 — このスキルは、そのディレクトリに sources.md（既存のファイルがあれば、既存の [S#] 番号を付け替えずに続きの番号で追記）、findings-*.md、report.md を書き出します。すべての主張は引用スキーマに従うため、呼び出し側の成果物では、調査方法を知らなくても [S#] を直接引用できます。

境界 — このスキルが回答するのは市場に関する質問です。市場以外のテーマについて詳細な調査が必要な場合や、実際の顧客を対象に一次調査を行う必要がある場合は、無理に対応せず、その旨を明示してください。

セッションをまたいだ再開（Deep Dive）

state.md には、モード、選択したレーン、完了したレーン、検証状況、セッションごとの短いログ行を記録します。呼び出し時に出力ディレクトリがすでに存在する場合は、最初に state.md を読み、作業に取りかかる前にユーザーへ進捗を伝えてください（「市場規模と競合の調査は完了。需要シグナルのレーンは未着手です」など）。完了済みのレーンを、黙ってやり直してはいけません。更新するかどうかをユーザーに確認してください（時間が経っている場合は情報源が古くなっている可能性があるため、そのレーンを最後に実行した時期も伝えます）。

参考資料

ファイル	読むタイミング
references/citation-schema.md	調査結果を書く前に必ず
references/market-sizing.md	市場規模レーンの実行時
references/competitor-analysis.md	競合レーンの実行時
references/demand-signals.md	需要レーンの実行時
references/trends-macro.md	マクロレーンの実行時
references/report-templates.md	レポートの統合時

結果の提示

結論とその確信度を最初に示します。次に、結論を左右する事実を、それぞれ [S#] とともに示します。その後に最大の留意点、最後に未解決の質問を示します。この要約を読んで価値を感じた場合にのみ全レポートに目を通す経営幹部を想定して書いてください。質問がスペイン語なら要約とレポートもスペイン語にするなど、ユーザーの言語に合わせます（引用した情報源の文章は元の言語のままでもかまいません）。