社内に溜まった市場調査・顧客調査のレポートを横断して探し、新しい企画の検討に使える調査結果を、調査の時期と対象と根拠のページ付きで返す

処理の起点を決める

取り込みと検索で、起点が2つあります。

取り込みは、取り込みのフォルダにレポートと調査の条件の票が揃ったときに動きます。 票が無いレポートは取り込まず、調査の担当に知らせます。条件の無い結果を検索に出さないためです。 新しい調査は年に数十本なので、毎晩の定時ではなく、置かれたときに動かします。

過去の600本は、最初にまとめて取り込みます。 調査の条件の票は、調査の台帳と各レポートの調査概要のページから調査の担当が作ります。600本の票を作る作業が、導入でいちばん大きな手間です（第11章）。

検索は、企画の担当が問いを入れて送ったときに動きます。 問いは「〜は〜か」の文章で入れてもらいます。単語だけで入れると、意味の近さの検索が効きにくくなります。

入力データを集める

質を決めるのは、図表のタイトルと注記です。 スライドのグラフは画像で、数字そのものは文章として取り出せないことが多いためです。図表のタイトル（「夕食の準備にかける時間（平日）」）と注記（「n=1,200、2025年2月」）が文章になっていれば、そのページは問いに当たります。数字は、当たったページを原本で見て確かめます。

利用の範囲は、調査の条件の票で決めます。 all_company（社内全体）、department（購入した部門だけ）、planning_only（経営企画だけ）のような値です。契約の内容を、調査の担当が票に写します。

調査の種類も、答えの読み方を変えます。 自社の定量調査、インタビューのような定性調査、購入した業界のレポート、公開統計を整理した資料では、同じ「60％」でも重さが違います。 票の survey_type で分け、答えにも必ず出します。

見る権限は、文書レベルのセキュリティの役割に書きます。 公式のドキュメントでは、${user.roles} のような変数で利用者の属性に応じて絞り込めるとされています。

PUT _plugins/_security/api/roles/research_reader
{
  "index_permissions": [{
    "index_patterns": ["reports"],
    "dls": "{\"bool\": {\"should\": [ {\"term\": {\"license_scope\": \"all_company\"}}, {\"terms\": {\"owner_dept\": [${user.roles}]}} ]}}",
    "allowed_actions": ["read"]
  }]
}

文書レベルのセキュリティの絞り込みは、役割をまたいで「または」で合わさります。 公式のドキュメントでは、複数の役割の絞り込みは論理和で結ばれるとされています。経営企画の人に広い役割を足すと、その人は両方の範囲を見られます。

データの取得方法を決める

レポートは、Lambda がページごとに分けます。 公式の取り込みの処理にも、長い文章を塊に分ける text_chunking がありますが、分けた結果は文字列の並びで、元のページの番号は残りません。 根拠をページで示したいので、分割はページを単位に自前で行います。

text_chunking を使う場合は、塊の数の上限に注意します。 公式のドキュメントでは、max_chunk_limit の既定は100で、それを超えた分の文章は最後の塊に足されるとされています。100ページを超えるレポートを丸ごと渡すと、後ろの数十ページが1つの塊になり、その部分は問いに当たりにくくなります。

索引の項目は、次のように持たせます。

ページの文章からベクトルを作るのは、取り込みのパイプラインです。 公式のドキュメントでは、text_embedding の処理で入れ子の項目を指定するときは、入力の項目は完全な経路で、ベクトルの項目は名前だけで書き、ベクトルは入力と同じ入れ子の中に入ります。 pages.text を入力に、embedding を出力に指定します。埋め込みのモデルは Amazon Bedrock の Cohere Embed を ML Commons のコネクタでつなぎ、公式のチュートリアルにあるとおり、多言語が要る場合は cohere.embed-multilingual-v3 を使えます。

AIへ渡す前に整形する

1. ページに分ける … PDFはページ、スライドは1枚を1ページにします
2. 見出しと図表のタイトルを取り出す … ページの最初の行と、図表の近くの短い行を heading に入れます
3. 調査概要のページに印を付ける … 調査の方法と対象が書かれたページは、検索の答えにいつも添える候補にします
4. 長いページを分ける … 文字の多いページ（報告書形式のPDF）は、段落で2つ以上に分け、同じページ番号を付けます
5. 文章の無いページを外す … 表紙や区切りのページ、画像だけのページはベクトルを作りません
6. 調査の条件の票と結ぶ … 票が無ければ取り込みで止めます

4番目で同じページ番号を付けるのは、根拠をページで示すためです。 埋め込みのモデルには入力の長さの上限があり、公式の説明でも、多くの埋め込みのモデルには入力のトークンの上限があるので、長い文章は分けるとされています。

AIに処理させる

AIの仕事は、当たったページから調査結果を書き出し、調査の条件を添えることだけです。 ページを探して並べるのは検索基盤です。

1行目が、いちばん外せない線です。 2023年の首都圏の調査で55％、2025年の全国の調査で62％と並ぶと、AIは「おおむね6割前後」とまとめます。その一文が企画書に載ると、どの調査にも無い数字が根拠のように使われます。

最後の行も大事です。 当たったページが問いと関係が薄いとき、AIは手元の結果を問いに合わせて説明しがちです。「該当なし」は、新しい調査が要るという大事な結論です。

指示内容を固定する

あなたは生活用品メーカーの経営企画部で、社内の調査レポートから調査結果を探す係です。
渡された検索結果だけを根拠にしてください。一般的な市場の知識で補わないでください。

【問い】{question}
【検索結果】レポートごとに、調査の条件（実施時期、対象、回答数、手法、種類）と、当たったページの文章

【レポートごとに書くこと】
1. 問いに関係する結果を、ページの文章のまま短く。根拠のページ番号を付ける
2. その結果の調査の条件（実施時期、対象、回答数、手法）
3. 注意：実施から3年超、対象が問いと違う、定性の調査、数字がグラフにしか無い など

【厳守事項】
- 複数の調査の数字を足したり、平均したり、「おおむね〜」とまとめたりしないでください。
- 結果を解釈したり、企画への示唆を書いたりしないでください。
- ページの文章に無い数字を書かないでください。グラフにしか無ければ「原本で確認」と書いてください。
- 調査の条件は検索結果の値をそのまま写してください。無ければ「票に記載なし」と書いてください。
- 問いに関係する結果が無いレポートは書かないでください。
  1本も無ければ「該当なし」とだけ書いてください。

「おおむね〜とまとめない」を明記しないと、AIは親切に要約します。 合算や平均を禁じるだけでは、「いずれの調査でも過半数が」のような言い方でまとめます。まとめる言い方そのものを禁じます。

検索結果は、Claude の検索結果ブロックで渡します。 当たったページ1つを1つの search_result にし、source にレポートの番号とページ番号、title に調査名と実施時期、content にページの文章と調査の条件を入れます。引用を有効にすると、答えの文に、渡した source と title の引用が付きます。 引用は既定で無効で、1つのリクエストの検索結果はすべて同じ設定にします。

出力形式を固定する

検索は、次のように組みます。

GET /reports/_search
{
  "size": 8,
  "_source": { "excludes": ["pages"] },
  "query": { "bool": {
    "filter": [ { "range": { "fielded_on": { "gte": "now-5y/d" } } } ],
    "must": { "nested": {
      "path": "pages", "score_mode": "max",
      "query": { "neural": { "pages.embedding": {
        "query_text": "共働き世帯の平日の夕食の準備時間は短くなっているか",
        "model_id": "<model_id>", "k": 50 } } },
      "inner_hits": { "size": 3, "_source": ["pages.page", "pages.heading", "pages.text"] }
    } }
  } }
}

score_mode を max にしているのは、レポートの点数をいちばん近いページで決めるためです。 公式のドキュメントでは、入れ子の文書の点数を全部取ると親の文書の点数は既定で平均になり、最も高い点数を使うには score_mode を max にします。平均にすると、関係の無いページの多い分厚いレポートほど下がります。

inner_hits は、当たったページを返すために付けます。 公式のドキュメントでは、入れ子の項目で当たった文書は、既定ではどの入れ子の要素が当たったかを返さず、inner_hits を付けると返ります。

画面に返す形は、次のJSONです。

{
  "question": "共働き世帯の平日の夕食の準備時間は短くなっているか",
  "results": [
    { "report_id": "R-2025-014", "title": "", "fielded_on": "2025-02",
      "survey_type": "定量", "population": "全国 25〜49歳 共働き世帯の女性・男性",
      "sample_size": 1200, "method": "インターネット調査",
      "findings": [ { "text": "", "page": 31 } ],
      "cautions": ["数字はグラフのみ。原本で確認"] },
    { "report_id": "R-2022-006", "title": "", "fielded_on": "2022-06",
      "survey_type": "定性", "population": "首都圏 30代 共働き世帯", "sample_size": 12,
      "method": "訪問インタビュー",
      "findings": [ { "text": "", "page": 8 } ],
      "cautions": ["実施から3年超", "定性の調査"] }
  ],
  "no_match": false
}

1つ目の理由は、調査の条件を結果と同じ要素に入れられることです。 画面でも企画書への写しでも、結果と条件が別れません。 第3章の（c）がここで止まります。

2つ目は、cautions で注意を項目として出せることです。 「定性の調査」「実施から3年超」が画面の色で分かります。

3つ目は、no_match で「該当なし」を記録できることです。

システムへ連携する

人が確認する

この構成の確認は、必須です。 調査の結果は、企画の判断の根拠になります。

1. 調査の条件の票を確かめる … 取り込みのときに、調査の担当が票の時期・対象・回答数を調査概要のページと見比べます
2. 根拠のページを開く … 企画の担当が、使う結果のページを原本で開き、数字と文脈を確かめます
3. 条件を企画書に写す … 結果を使うときは、実施時期・対象・回答数を必ず一緒に写します
4. 購入レポートの使い方を確かめる … 社外に出す資料に使うときは、経営企画に利用の範囲を確かめます

2番目を省かないでください。 ページの文章が当たっていても、グラフの数字は文章に無いことが多く、AIの書き出しは図表のタイトルまでです。

1件あたり14分を目安にします。 結果の一覧を読み、使う結果のページを2〜3枚開いて確かめる時間です。

調査の担当は、月に1回、よく当たるレポートの票を見直します。 多くの問いの根拠になるレポートほど、票の誤りが多くの企画書に広がります。

例外に対処する

4行目で、権限の無いレポートの存在を示すのは、同じ調査の発注を避けるためです。 中身は見せませんが、経営企画に聞けば使えるかもしれないことは伝えます。

記録を残す

• 取り込んだレポート、調査の条件の票、止めたものとその理由
• 問い、検索の結果（レポートとページ）、Claude の答えと引用
• 「該当なし」になった問い
• 企画の担当が原本を開いたページ

3つ目は、調査の計画の材料です。 経営企画が四半期ごとに「該当なし」の問いを並べ、次に行う調査の候補にします。 同じ問いを複数の事業部が持っていれば、1つの調査にまとめられます。