Azure AI Searchで社内文書RAGを作る前に決める、インデックスと検索方式の項目

1. 公式で確認すること／自社で決めることの切り分け

• インデックス、公式ドキュメントで確認する：項目の属性（searchable、filterable、retrievableなど）の意味と、作成後の変更制限、自社で決める：項目名、チャンクの切り方、絞り込みに使うメタデータ
• 検索方式、公式ドキュメントで確認する：各方式の仕組み、GAかプレビューか、自社で決める：質問の傾向に合う方式、評価用の質問集
• 権限、公式ドキュメントで確認する：方式ごとの対応データソースとGA/プレビューの別、自社で決める：権限情報の元データ、グループ単位かユーザー単位か
• 更新、公式ドキュメントで確認する：インデクサー（取り込み側から引く）とプッシュAPI（自社コードで送る）の選択肢、自社で決める：更新頻度、削除と権限変更の反映期限

特にインデックスは、Search Index Overviewのページによると、項目の属性は検索時の使い方を決め、フィルター可能な文字列は単語分割されず完全一致で比較されます。属性はAPIやSDKの既定値に頼らず明示するよう案内されています。

2. インデックス項目：設計メモ（前半）

RAGでは通常、1文書を1件にせず、見出しや段落単位のチャンクを1件として入れます。以下はこの記事の編集上の提案です。公式の必須要件ではありません。

記入欄つきの項目表

• chunk_id、型：Edm.String（key）、searchable：－、filterable：－、retrievable：○、用途・記入メモ：一意のID。keyは文字列型で1つだけ
• parent_id、型：Edm.String、searchable：、filterable：、retrievable：、用途・記入メモ：元文書のID。更新・削除時の対応付けに使う
• title、型：Edm.String、searchable：、filterable：、retrievable：、用途・記入メモ：文書名・見出し
• content、型：Edm.String、searchable：○、filterable：、retrievable：○、用途・記入メモ：回答の根拠にする本文
• content_vector、型：Collection(Edm.Single)、searchable：○、filterable：、retrievable：、用途・記入メモ：次元数は使う埋め込みモデルに合わせる
• source_url、型：Edm.String、searchable：、filterable：、retrievable：○、用途・記入メモ：回答に出典として表示する
• doc_type、型：Edm.String、searchable：、filterable：、retrievable：、用途・記入メモ：規程、マニュアル、議事録など
• updated_at、型：Edm.DateTimeOffset、searchable：、filterable：、retrievable：、用途・記入メモ：鮮度の絞り込み・表示用
• group_ids、型：Collection(Edm.String)、searchable：、filterable：○、retrievable：、用途・記入メモ：閲覧できるグループ（後述）

決めるときの注意が3つあります。

• 属性は明示する。 同ページによると、REST APIは多くの属性が既定で有効、.NET SDKは逆に既定で無効です。既定値任せにすると環境ごとに挙動がずれます。
• filterableな文字列は完全一致。 単語分割されないため、「就業規則」で探す項目に「就業規則（2026年版）」は一致しません。区分値は正規化した短い値にします。
• retrievableをfalseにしても秘匿にはならない。 同ページは、この設定では検索結果の文書フィールドとして返されなくなる一方、インデックス内容に依存する検索機能での内部利用は防げないと説明しています。機密情報を入れる前に、アプリや機能の要件を確認します。

3. 検索方式：判断表（設計メモ・中盤）

RAG and Generative AIのページ（ページ上の日付は2026年8月、確認時点で9月更新）は、方式を大きく2つに分けています。1つは、アプリが1回クエリを投げるクラシックRAG。もう1つは、LLMが質問を分解して並列に検索するエージェント型検索です。同ページでは、エージェント型のクエリ計画はプレビュー扱いです。一方、GA機能だけを使いたい場合や、既存の制御コードを残したい場合はクラシックRAGが向くとされています。

クラシックRAGで中心になるハイブリッド検索は、Hybrid Search Overviewによると、search（全文）とvectorQueries（ベクトル）を1回のリクエストに入れて並列実行し、RRFという方法で1つの結果にまとめます。製品コード、専門用語、日付、人名のような検索では、キーワード検索が完全一致を見つけやすいと説明されています。

• キーワードのみ、向く質問の例（説明用）：「規程番号 HR-12」の検索、公式資料から読み取れる注意：言い換えの質問に弱い、自社の判断：□採用 □不採用
• ハイブリッド、向く質問の例（説明用）：規程番号も言い換えの質問も来る、公式資料から読み取れる注意：selectで返す項目を絞る。並べ替え（orderby）を指定すると関連度順を上書きする、自社の判断：□採用 □不採用
• ハイブリッド＋セマンティックランカー、向く質問の例（説明用）：上位結果の並べ替え精度を上げたい、公式資料から読み取れる注意：クラシックでは任意機能。同ページはk=50を推奨、自社の判断：□採用 □不採用
• エージェント型検索、向く質問の例（説明用）：会話の流れを踏まえた複雑な質問、公式資料から読み取れる注意：クエリ計画はプレビュー、自社の判断：□採用 □不採用

フィルターを検索の前後どちらで適用するかは、セマンティックランカー利用時は後段が候補になるものの、同ページはクエリで試して確認するよう案内しています。評価用の質問集を先に作ることが、ここでの宿題です。

4. 権限の絞り込み：どの方式を使うか決める

Document-Level Access Controlは、4つの方式を挙げています（ページ上の日付は2026年8月）。

• セキュリティフィルター、状態（確認時点）：同ページでは「generally available」、向くケース：独自の認可の仕組み、プッシュ型インデックス
• ACL／RBACスコープ、状態（確認時点）：プレビュー、向くケース：ADLS Gen2やBlobの既存権限
• Purview秘密度ラベル、状態（確認時点）：プレビュー、向くケース：Purviewで分類済みの文書
• SharePointのACL、状態（確認時点）：プレビュー、向くケース：SharePoint上の文書

プレビュー機能は、同ページの注記でSLA対象外、本番ワークロードには非推奨で、変更または制限される可能性があるとされています。利用時は対象機能の状態を確認してください。

セキュリティフィルターは、Security Filter Patternによると、グループ名やユーザーIDの文字列をインデックスに持たせ、検索時のフィルターで一致する文書だけを返す方式です。文字列の照合にすぎず、認証や認可そのものは行いません。 呼び出し元が誰かの判定と、所属グループの取得は、自社のアプリ側で行う必要があります。公式の例では、グループ項目をCollection(Edm.String)、filterable: true、retrievable: falseにし、次のように絞り込みます。

"filter": "group_ids/any(g:search.in(g, 'group_id1, group_id2'))"

チャンク分割をする場合は、権限メタデータの扱いも設計に含めます。Document-Level Access Controlのページには、スキルセットで分割するとACL項目はインデクサーのフィールドマッピングからインデックスプロジェクションに移る、との説明があります。親文書とチャンク間で権限情報を適切に引き継ぐ方法を確認してください。

5. 更新方法：反映のタイミングを決める

RAGのページによると、データの取り込みには、インデクサーとスキルセットで組むパイプラインと、前処理済みの内容をプッシュAPIで送る方法があります。どちらを選ぶかは、元文書の置き場所と、チャンク化を誰が行うかで決まります。

とくに権限は、元の権限を変えただけでは検索結果に反映されません。Document-Level Access Controlのページには、元システムでの変更は、インデクサーの再実行やプッシュAPIでの更新といった同期の後にしか反映されない、とあります。セキュリティフィルターでは、グループ項目だけをmergeOrUploadで更新する例が公式に示されています。「異動・退職・共有解除から何時間以内に反映するか」を決めてください。

6. 設計メモの雛形（コピーして使う）

以下は、記入欄だけの雛形です。

# 社内文書RAG 設計メモ（作成日：  / 作成者：  ）

## 0. 対象
- 対象文書（種類・件数の目安）：
- 想定する質問10件（実際の質問から）：
- 回答に出典を付けるか：

## 1. インデックス項目
- 1件（チャンク）の単位：
- 項目表（名前／型／searchable／filterable／retrievable／用途）：
- 属性を明示するか（REST・SDKの既定値差の確認）：
- インデックスに入れない情報（個人情報・機密）：
- 項目変更が必要になったときの方針（新インデックス作成など）：

## 2. 検索方式
- 採用方式（キーワード／ハイブリッド／＋セマンティック／エージェント型）：
- 採用機能のGA／プレビュー確認日と確認ページ：
- 評価用の質問と、期待する文書：
- 返す項目（select）と件数（top／k）：

## 3. 権限の絞り込み
- 権限の元データ（どのシステムか）：
- 方式（セキュリティフィルター／ACL／ラベル／SharePoint）：
- GA／プレビューの確認日：
- 呼び出し元の識別とグループ取得を行う場所：
- チャンクへの権限項目の付与方法：
- 権限なしユーザーでの確認テスト（誰で、何件）：

## 4. 更新
- 取り込み方式（インデクサー／プッシュAPI）：
- 文書の追加・変更・削除の反映頻度：
- 権限変更の反映期限：
- 失敗時の確認担当と確認方法：

記入例（説明用の例・架空のデータ）

以下は動作確認をしていない仮の例です。

- 1件の単位：就業規則を「条」単位で分割
- 項目：chunk_id / parent_id / title / content / content_vector / source_url / doc_type / updated_at / group_ids
- 採用方式：ハイブリッド（条番号の検索と言い換えの質問を両方想定）
- 権限：セキュリティフィルター（GA）。所属グループは社内IDシステムから取得
- 更新：週1回の再取り込み＋グループ変更は当日中にmergeOrUpload
- 権限テスト：人事グループ／一般社員の2アカウントで、給与規程の質問を比較

AIに設計メモの抜けを点検させる依頼文

メモを書いたら、次の依頼文でAIに点検させると、記入漏れや矛盾を見つけやすくなります。実際の機密文書や社員名は入れず、上の記入例のような置き換えデータにしてください。

次の設計メモを、抜け・矛盾・曖昧な記述の観点で点検してください。
- 項目表の属性と、検索・絞り込みの使い方が食い違っていないか
- 権限項目がチャンクごとに入る設計になっているか
- 更新方法に、削除と権限変更の反映期限があるか
- プレビュー機能に依存している箇所はどこか
指摘は「箇所／理由／確認すべき公式ページの種類」の表で出し、
公式の仕様を断定せず、私が確認すべき点として挙げてください。

【設計メモ】
（ここに貼り付け）

AIの指摘は確認の手がかりです。GAかプレビューかなどの仕様は、必ずMicrosoft Learnの該当ページで自分で確かめてください。人が最終的に確認するのは、権限なしユーザーで見えてはいけない文書が出ないこと、評価用の質問で期待した文書が上位に来ることの2点です。