注目のアップデート
- Agentic Retrieval の推論努力パラメータに 適応的な推論努力
autoが追加されました。まず軽量な検索パスを走らせ、根拠が足りないときだけ LLM クエリ計画へ昇格します。上限はmediumで打ち止めです。 - クエリヒント（query hints） が加わり、ユーザーの自然文からフィルターとブーストをモデルに生成させられるようになりました。
- サーバー送信イベント（SSE）によるストリーミング取得が可能になりました。ただしトークン単位のデルタではなく、メッセージ単位となります。
-
resultsProcessing: "none"でナレッジソース単位に再ランクをバイパスできます。ベクトル検索や MCP ツールの元順序を保ちたいケース向けです。 -
neverQuerySource: trueで、ナレッジベースの構成を変えずに 1 リクエストだけソースを除外できます。 -
citationUrlにより、参照ドキュメントを認証付きで引き直せる URL が返るようになりました。 - ナレッジベースのモデルサポートが
gpt-5.5、gpt-5.6-sol/gpt-5.6-terra/gpt-5.6-lunaまで拡大しました。
0. 今回の変更一覧
| # | 項目 | 説明 | 主な新プロパティ / 操作 |
|---|---|---|---|
| 1 | Search Service 2026-08-01-preview
|
新しいデータプレーン プレビュー API | ー |
| 2 | 自動取得推論努力 | 軽量パスから始めて必要なときだけ LLM へ昇格 | retrievalReasoningEffort.kind = "auto" |
| 3 | クエリヒント | 自然文からフィルター・ブーストを生成 |
queryHints、queryHintOverrides
|
| 4 | ナレッジベースの取得既定値 | 実行時間・件数・トークン予算を保存 | retrieveDefaults |
| 5 | ソース単位の再ランク制御 | 再ランクをバイパスして元順序を保持 | resultsProcessing = "none" |
| 6 | 要求時ソース除外 | 1 リクエストだけソースを外す | neverQuerySource = true |
| 7 | 取得結果のストリーミング | SSE でイベント逐次配信 | Accept: text/event-stream |
| 8 | 引用 URL | 参照元ドキュメントの認証付き引き直し | citationUrl |
| 9 | リスト操作のカーソルページング | 大規模なオブジェクト一覧を安定分割 |
pageSize、searchType=prefix、@odata.nextLink
|
| 10 | ファイルナレッジソースの更新 | サーバーレス対応、上限緩和、マルチパート、更新、CORS |
/knowledgesources('...')/files 群 |
| 11 | Work IQ のカスタム Entra アプリ | 顧客所有アプリ + フェデレーション資格情報で OBO | ー |
| 12 | インデックス付きナレッジソースのプライベートネットワーク | 生成インデクサー経由のプライベート取り込み | ー |
| 13 | ナレッジベースのモデルサポート拡大 |
gpt-5.5 / gpt-5.6 ファミリ |
models |
プレビュー機能には SLA がなく、運用ワークロードには推奨されないという条件が付きます。また
2026-08-01-previewは Microsoft 以外のサービスへの接続もサポートするため、データが Azure のコンプライアンス境界の外で処理・保存される可能性がある点が明記されています。
1. 全体像：Retrieve パイプラインの変更点
Agentic Retrieval の retrieve アクションは、おおまかに次の流れで動きます。8 月に追加された制御点を黄色のノードと [新] で示します。
この図を頭に入れておくと、以降の個別解説がどこの話なのかを見失わないと思います。でも複雑ですよね… 私は RAGOps Studio OSS プロジェクトを通じて、この複雑性をいかに分かりやすく伝えるかについて探求しています。
2. 適応的推論努力 auto：常時 LLM ベースのクエリ計画を実行しない判断
2.1 何が問題だったか
Agentic Retrieval の推論努力には、これまで 3 段階がありました。
kind |
挙動 | 主な制約 |
|---|---|---|
minimal |
LLM を呼ばない。クエリ文字列をそのまま検索エンジンへ渡す |
outputMode は extractiveData のみ、回答合成と Web ナレッジソース非対応、ナレッジソースは最大 10 |
low |
LLM でクエリ計画 | 回答トークン最大 5,000、セマンティック再ランクは最大 50 ドキュメント（L3 分類時は 10） |
medium |
より踏み込んだクエリ計画 | 回答トークン最大 10,000、セマンティック再ランクは最大 50 ドキュメント（L3 分類時は 20）、一部リージョンのみ |
「今日は何が来るかわからないユーザー入力」に対して、minimal を選べば "Contoso 100 の返品期限は" のような単純な検索は速くて安いのに、"A 社と B 社の四半期ごとの粗利率の差分要因を、地域別に" のような複合質問で根拠を取りこぼします。かといって全部 medium にすれば、単純な質問にも毎回クエリ計画のトークンを払うことになります。
2.2 auto の設計
auto は、この判断を Azure AI Search サービス側に委譲します。
medium との違い
auto の「最大 medium」とは、auto と medium が同じ処理を行うという意味ではないです。入口と最適化目的が異なります。
| 観点 | medium |
auto |
|---|---|---|
| 開始経路 | LLM 支援の深い取得処理を使用する | まず軽量な取得を行い、十分な根拠が得られれば終了する |
| LLM クエリ計画 | 深い取得処理の一部として使用する | 軽量パスで根拠が不足した場合だけ使用する |
| 初回検索後の処理 | 高精度セマンティック分類器が結果を評価する | 根拠が十分かをサービスが判断するが、その判定器の内部構成は公開されていない |
| 追加反復 | 初回結果が不十分なら、改訂したクエリ計画で 1 回だけ追加検索する。L3 分類で再スコアリングする | 必要に応じて LLM 経路へ進む。到達できる深さは medium までだが、毎回 medium の追加反復まで実行するとは明記されていない |
| 最適化目的 | 取得の完全性と LLM 支援検索の有用性を最大化する | 要求ごとに取得深度と待ち時間のバランスを取る |
| 利用可能リージョン | 一部リージョンのみ | Agentic Retrieval をサポートする全リージョン |
つまり、単純な質問では差が大きくなります。medium は深い取得処理へ入り、auto は軽量パスだけで返せます。難しい質問では auto も LLM クエリ計画へ進みますが、auto が常に medium と同じセマンティック分類、L3 再スコアリング、追加反復を実行するとは仕様に書かれていません。
2.3 auto の検証コード
Python の場合、azure-search-documents 12.1.0b2 が必要となります。
pip install azure-search-documents==12.1.0b2
# 単純要求と複合要求で auto の実行経路を比較
AUTO_TEST_QUERIES = {
"単純要求": "データ可視化",
"複合要求": (
"API を実装し、PyTorch モデルを配備し、運用指標を可視化するために必要な "
"Agent Skills を選び、各 SKILL.md の手順を組み合わせて作業順を整理してほしい"
),
}
KNOWLEDGE_SOURCE_NAME = AZURE_CONFIG["AZURE_SEARCH_KS_NAME"]
def evaluate_auto(label, query):
request = kb_models.KnowledgeBaseRetrievalRequest(
intents=[kb_models.KnowledgeRetrievalSemanticIntent(search=query)],
retrieval_reasoning_effort=(
kb_models.KnowledgeRetrievalAutoReasoningEffort()
),
include_activity=True,
knowledge_source_params=[
kb_models.SearchIndexKnowledgeSourceParams(
knowledge_source_name=KNOWLEDGE_SOURCE_NAME,
always_query_source=True,
include_references=True,
)
],
)
response = kb_client.retrieve(retrieval_request=request).as_dict()
activities = response.get("activity", [])
activity_types = [activity.get("type") for activity in activities]
reasoning = next(
(
activity
for activity in activities
if activity.get("type") == "agenticReasoning"
),
{},
)
return {
"条件": label,
"要求": query,
"activityTypes": activity_types,
"modelQueryPlanningへ昇格": "modelQueryPlanning" in activity_types,
"報告された取得推論": reasoning.get("retrievalReasoningEffort"),
"報告された論理推論": reasoning.get("logicalReasoningEffort"),
"参照数": len(response.get("references", [])),
}
AUTO_COMPARISON = [
evaluate_auto(label, query)
for label, query in AUTO_TEST_QUERIES.items()
]
AUTO_COMPARISON
RAGOps Studio による auto Activity Flow の可視化
RAGOps Studio for Azure AI Search を 2026-08-01-preview にアップデートしました！
クエリによって Agentic Retrieval Activity Flow がどのように変化したか一目瞭然ですね🤩
3. クエリヒント：フィルターを「書く」から「教える」へ
3.1 従来の限界
検索インデックスのナレッジソースには、以前から決定的なフィルターがありました。
-
baseFilter: そのナレッジソースの全取得に常に適用される固定フィルター -
filterAddOn: リクエスト時に渡す追加フィルター。baseFilterと AND で合成される
どちらも OData 式をアプリ側が組み立てる必要があります。OData 式は私も Azure-AI-Search-Workshopで徹底講義していますが、記法を覚えるのが難しいです。
Agentic Retrieval の入り口はユーザーの自然文です。「モデル X200 の日本語の設置手順」という一文から productFamily eq 'Model-X200' and language eq 'ja-JP' を作るには、結局アプリ側にもう一段の意図解析が必要でした。
3.2 queryHints の構造
2026-08-01-preview では、検索インデックスのナレッジソースに queryHints を保存できます。
{
"queryHints": {
"filters": [
{
"field": "productFamily",
"fieldValues": ["Model-X100", "Model-X200"],
"filterInstructions": "ユーザーがモデル名を指定した場合にのみフィルタリングする。"
}
],
"boosts": [
{
"kind": "fieldValue",
"field": "language",
"fieldValues": ["en-US", "ja-JP"],
"boost": 2.0,
"boostInstructions": "ユーザーが指定した言語を優先してください。"
},
{
"kind": "multiWordExpression",
"fieldValues": ["deferred tax", "wash sale"],
"boost": 3.0,
"boostInstructions": "完全なフレーズとして使用されるブーストドメインの用語。"
}
]
}
}
各ヒントの要件と上限は次のとおりです。
| ヒント種別 | 対象フィールド要件 |
fieldValues の意味 |
上限 |
|---|---|---|---|
filters |
filterable なインデックスフィールド | 必須。許容値の完全な集合。ユーザー入力がどの値にも対応しない場合、プランナーはそのフィールドでフィルターしないよう指示される | ユニークフィールド最大 5、値あたり 128 文字、全値合計 2,048 文字 |
boosts (kind: fieldValue) |
searchable なフィールド（language / standard / default アナライザー） | 任意の例示。省略時は boostInstructions で値の選び方を説明 |
ユニークフィールド最大 5、フィールドあたり最大 20 値、値あたり 128 文字、合計 1,024 文字 |
boosts (kind: multiWordExpression) |
field は指定しない |
ドメイン固有フレーズの例示 | 1 個のみ、最大 20 値、値あたり 128 文字、合計 1,024 文字 |
ここで面白いのは、fieldValues が 列挙（enum）としての役割を持っている点です。フィルターヒントでは「この値以外は存在しない」とモデルに教えることで、幻覚的なフィルター生成を構造的に抑え込んでいます。プロンプトに「以下の値のみ使え」と書く代わりに、API のスキーマとして持たせた形です。
3.3 合成規則と確認方法
queryHintOverrides を省略すると、ナレッジソースに保存した queryHints が使われます。指定した場合は、保存済みの queryHints 全体を置換します。生成されたフィルターは baseFilter および filterAddOn と AND で結合されます。
適用されたかどうかは includeActivity: true を付けて searchIndex アクティビティの queryHintProcessing を見ます。
{
"type": "searchIndex",
"queryHintProcessing": {
"generatedBoost": "language:(ja\\-JP)^2"
},
"searchIndexArguments": {
"queryType": "full"
}
}
ドキュメントは「クエリヒントはベストエフォートなので、厳密な式の一致を検査するのではなく、確認材料として扱え」と明記しています。ここは重要で、queryHints は決定的なフィルターの代替ではありません。監査要件やアクセス制御に関わる絞り込みは、引き続き baseFilter や ACL / RBAC 側で担保すべきです。
4. 既定の取得制限値 retrieveDefaults
retrieveDefaults は、ナレッジベースを利用するすべての取得要求に対して、最大実行時間、最終文書数、出力トークン量の標準上限を一元管理する機能です。検索精度を直接向上させる機能ではなく、応答時間、応答サイズ、引用数、後段の LLM に渡すトークン量を予測しやすくするために使用します。
| ナレッジベースに保存する設定 | Retrieve 要求で対応する設定 | 制御対象 |
|---|---|---|
maxRuntimeInSeconds |
maxRuntimeInSeconds |
取得処理の最大実行時間 |
maxOutputDocuments |
maxOutputDocuments |
最終応答に含める最大文書数 |
maxOutputSizeInTokens |
maxOutputSize |
最終文書全体の最大トークン量 |
保存値と要求値では、出力トークン量のプロパティ名が異なります。ナレッジベースでは maxOutputSizeInTokens、個別の Retrieve 要求では maxOutputSize を使います。
各項目の有効値は、それぞれ独立して次の順序で決まります。
- Retrieve 要求で明示した値
- ナレッジベースの
retrieveDefaultsに保存した値 - 両方に値がない場合は Azure AI Search のサービス既定値
例えば、通常は最大 8 文書、12,000 トークンとし、特定の画面だけ Retrieve 要求で最大 1 文書に上書きできます。この場合、文書数だけ要求値が使われ、ほかの項目には保存済みの既定値が使われます。
5. 再ランクの省略 resultsProcessing="none"
resultsProcessing="none" は、指定したナレッジソースの再ランクを省略して元の結果順を保持します。ただし、複数ソースを使う場合、最終結果はアクティビティ間でラウンドロビンに配分されます。また、重複排除、文書上限、トークン上限は引き続き適用されます。
6. 要求単位のソース除外 neverQuerySource
neverQuerySource=true は、ナレッジベース定義を変更せず、1 回の要求だけ指定 Knowledge Source を候補から除外します。同じソースに alwaysQuerySource と同時指定はできません。
knowledgeSourceParams の型は、実際の Knowledge Source の種類と一致させる必要があります。例えば、検索インデックスには SearchIndexKnowledgeSourceParams、Web には WebKnowledgeSourceParams を使います。種類が一致しない場合は InvalidRequestParameter が返されます。
7. SSE ストリーミング取得
retrieve_stream() は取得処理のイベントを SSE で逐次受信します。このセルではイベント種別と内容を到着順に表示します。回答本文はトークン単位ではなく、完成時のイベントとして返されます。
# 検証する要求
QUERY = (
"Notebook でデータを分析し、遅い Python 処理も調査するために必要な "
"Agent Skills の SKILL.md を取得してほしい"
)
# SSE で検索
request = kb_models.KnowledgeBaseRetrievalRequest(
intents=[kb_models.KnowledgeRetrievalSemanticIntent(search=QUERY)],
output_mode=kb_models.KnowledgeRetrievalOutputMode.ANSWER_SYNTHESIS,
retrieval_reasoning_effort=(
kb_models.KnowledgeRetrievalMinimalReasoningEffort()
),
include_activity=True,
)
# 到着したイベントを順番に表示
with kb_client.retrieve_stream(retrieval_request=request) as stream:
for event in stream:
print(event.event_type)
display(event)
以下が段階的に出力される
event: retrieval.started
data: {"requestId":"<request-id>","outputMode":"answerSynthesis"}
event: activity.started
data: {"id":0,"type":"searchIndex","startedAt":"<timestamp>"}
: heartbeat
event: activity.completed
data: {"id":0,"startedAt":"<start>","completedAt":"<end>"}
event: answer.completed
data: {"messageIndex":0,"message":{"content":[{"type":"text","text":"..."}]}}
event: references.completed
data: [{"type":"searchIndex","id":"0","activitySource":0}]
event: response.completed
data: {"statusCode":200,"response":{}}
8. 引用 URL citationUrl
citationUrl により、参照に対応するバックエンドインデックスのドキュメントフィールドを、認証付きで取得できます。
# 検証する要求と Knowledge Source
QUERY = "Jupyter Notebook のデータ分析で使う Agent Skill の SKILL.md を取得してほしい"
KNOWLEDGE_SOURCE_NAME = AZURE_CONFIG["AZURE_SEARCH_KS_NAME"]
# 参照を含めて検索
request = kb_models.KnowledgeBaseRetrievalRequest(
intents=[kb_models.KnowledgeRetrievalSemanticIntent(search=QUERY)],
retrieval_reasoning_effort=(
kb_models.KnowledgeRetrievalMinimalReasoningEffort()
),
knowledge_source_params=[
kb_models.SearchIndexKnowledgeSourceParams(
knowledge_source_name=KNOWLEDGE_SOURCE_NAME,
always_query_source=True,
include_references=True,
)
],
)
result = kb_client.retrieve(retrieval_request=request)
# citationUrl を含む参照を表示
result.as_dict().get("references")
'references': [{'type': 'searchIndex',
'id': '0',
'activitySource': 0,
'rerankerScore': 1.080982,
'docKey': 'skill-005',
'title': 'notebook-data-analysis',
'citationUrl': 'https://.search.windows.net/indexes/agent-skills-sample-index/docs/skill-005?$select=name%2Cdescription%2Cskill_md%2Ctask_category%2Ctrigger_phrases%2Csupported_tools%2Cresource_paths%2Cid%2Cfile_path&api-version=2026-08-01-preview',
'sourceData': None}]}
9. 管理リソース一覧のカーソルページング
これは検索結果の文書をページ送りする機能ではありません。Azure AI Search サービスに作成済みのインデックス、データソース、インデクサー、スキルセット、ナレッジベース、ナレッジソースなどの管理リソース一覧を、1 回ですべて返さず数件ずつ取得する仕組みです。リソースの棚卸し、監査、移行、管理画面などで、多数の設定資産を列挙するときに使用します。
2026-08-01-preview では、対応する一覧 API の $top、$skip、$count が、pageSize、search、@odata.nextLink を使うカーソル方式へ置き換わりました。カーソルはページ番号ではなく、Azure AI Search が生成した次の要求先を表す不透明な URLです。クライアントは内容を解釈せず、その URL 全体を次の要求に使用します。
なぜカーソル方式に変更したのか
Docs では、採用理由や内部実装を明記していません。公開仕様から確実に言える設計上の変化は、一覧の現在位置を計算する責任がクライアントからサービスへ移ったことです。
| オフセット方式 | カーソル方式 |
|---|---|
クライアントが $skip=2000 のように開始位置を数値で指定します。 |
サービスが次の位置を含む不透明な URL を返します。 |
| クライアントが位置や総件数を扱います。 | クライアントは @odata.nextLink の有無だけを扱います。 |
| API は位置指定という内部的な考え方を公開します。 | サービス内部の継続状態をトークン内へ隠蔽できます。 |
| 任意の位置を指定できます。 | 前方向にのみ順次取得できます。 |
10. ファイルナレッジソースの更新
2026 年 6 月に登場したファイルナレッジソース（インデクサーパイプラインを別途組まずにナレッジベースへ直接ファイルを上げられる仕組み）が、8 月に実用寄りへ大きく前進しました。
| 機能 | 2026-05-01-preview |
2026-08-01-preview |
|---|---|---|
| 最大ファイル数 | 100 | 200 |
| 最大ファイルサイズ | 全ティア 50 MB | Free / Basic は 50 MB、それ以外の Dedicated ティアと Serverless は 100 MB |
| 価格モデル | Dedicated | Dedicated と Serverless の両方 |
| アップロード形式 | 生のファイルコンテンツのみ | 生コンテンツ、または マルチパート + カスタムメタデータ |
| ファイル一覧 | 一覧のみ |
パス（prefix）やファイル名で絞り込み、詳細情報を返却 |
| 既存ファイルの置換 | 削除して再アップロード | Update 操作で置換 |
| ブラウザーからの直接アクセス | 不可 | CORS 設定可 |
アップロード / 更新の処理時間上限は 180 秒で変わりません。
11. Work IQ ナレッジソースのカスタム Microsoft Entra アプリ
Work IQ ナレッジソース（Microsoft 365 の業務データへアクセスするリモートナレッジソース、2026 年 6 月に追加）の認証モデルが変わりました。
- 旧: プレビュー機能登録 + 個別のアクセス要求
- 新: 顧客所有の Microsoft Entra アプリとフェデレーション資格情報による代理アクセス（OBO）
クエリ時は x-ms-query-work-iq-source-authorization ヘッダーでアプリオーディエンスのユーザーアサーションを渡し、取得エンジンがこれを Work IQ スコープのトークンに交換します。他のナレッジソースが使う x-ms-query-source-authorization とはヘッダー名が異なる点に注意してください。
意味合いとしては、Microsoft 側のゲート（プレビュー登録・個別承認）から、顧客側のガバナンス（自社テナントのアプリ登録と同意）へ移行したということです。アプリ登録は自社のテナントに存在し、権限付与も自社の管理者が行います。
12. インデックス付きナレッジソースのプライベートネットワーク取り込み
Blob、インデックス付き SharePoint、インデックス付き Azure SQL のナレッジソースが、生成されたインデクサー経由でのプライベートネットワーク取り込みをサポートするようになりました。
エンタープライズ導入では重要なアップデートです。ナレッジソースは裏側でインデクサーを自動生成しますが、そのインデクサーがパブリックエンドポイント経由でしかデータソースに到達できないなら、「ストレージアカウントのパブリックアクセスを全面禁止」というよくある社内規程に引っ掛かります😭。この更新により、ナレッジソースの手軽さと、ネットワーク分離の要件を両立できるようになりました。
6 月に入った Microsoft Foundry 向けのネットワークセキュリティ境界と共有プライベートリンクのサポートと合わせると、対象の取り込み元と Microsoft Foundry モデル接続について、プライベート接続を構成できる範囲が拡大しました。
GitHub
サンプルデータ付き。
RAGOps Studio — for Azure AI Search