Azure OpenAI On Your Dataとは？廃止予定までの構成と移行の判断

Azure OpenAI On Your Dataは、Azure AI 検索などのデータストアをチャット補完APIに直結させ、自社の文書を根拠にした回答と引用を返すマネージド機能です。ただし2026年8月16日に確認したMicrosoft Learn日本語版は、この機能を「廃止されており、まもなく廃止間近」と表記し、サービスの終了日を2026年10月14日と明記しています。この記事では推論時の三工程、認証設計、五つの検索方式とチャンクサイズの指定、引用（citations）の返り方を一次情報から押さえ、残された期間の使い方と自前実装との線引きを実装者向けに整理します。

まとめ：新規採用は見送り既存構成の移行設計から着手する

結論から書きます。2026年8月16日時点で、Azure OpenAI On Your Dataを新規案件の本番構成に選ぶ理由はありません。終了予定日まで二か月を切り、対応モデルもGPT-4oとGPT-4o-miniの四バージョンに固定されたままだからです。

すでに本番で動かしているなら、止めるのではなく移し替えの設計に入ってください。案内されている移行先はFoundry Agent ServiceとFoundry IQの組み合わせで、取り込み済みのインデックスはAzure AI 検索側の資産として残るため引き継げます。判断材料が足りないなら、まずAzure OpenAI Serviceそのものの提供範囲と料金体系を確認し、どこまでがマネージドの守備範囲かを切り分けてください。

On Your Dataが自社データ接続で担う三工程と構成要素の対応

この機能は「チャット補完APIにインデックスをぶら下げる」だけの薄いラッパーではありません。応答を返すまでに、内部で複数回のモデル呼び出しと検索が走ります。まず内訳を押さえます。

意図生成・取得・応答生成の三段階に分かれる推論時の工程の中身

公式ドキュメントは推論時の処理を三段階に分けています。第一の意図生成は、質問と会話履歴と内部指示をまとめたプロンプトでモデルを呼び、検索意図の一覧へ変換する工程です。第二の取得では意図ごとにデータソースへ問い合わせ、類似度のしきい値で無関係なチャンクを落として再ランク付けと集約を行います。第三の応答生成で、選ばれたチャンクと質問をモデルに渡して最終回答を作ります。

見落としやすいのは、モデル呼び出しが一回ではなく二回だという点です。意図プロンプトと生成プロンプトの両方に課金されます。公式の実測表ではgpt-4-0613で生成プロンプト3,997トークン・意図プロンプト1,385トークンという内訳で、単純なチャット補完の試算では実費が倍近くずれます。

取り込み側で作られる三つの資産と統合ベクター化への切り替え時期

取り込み（インジェスト）は推論とは別系統の処理です。ポータルからのアップロードでもAPI呼び出しでも、ファイルは解読・チャンク分割・埋め込み生成を経てAzure AI 検索のインデックスに入ります。この工程設計の考え方は製品共通で、取り込み系と推論系を分けて設計するRAGパイプラインの原則と同じ構造です。

2024年9月にインジェストAPIは統合ベクター化へ切り替わり、内部でカスタムスキルを使わなくなったぶん生成される資産が整理されました。

• {job-id}-index：チャンクと埋め込みを保持する検索インデックス
• {job-id}-indexer：スケジュールを指定したときだけ残り、指定がなければ取り込み完了時に消える
• {job-id}-datasource：取り込み元への接続定義

チャンクを格納する中間コンテナは、この切替以降は作られません。「チャンクコンテナを確認する」前提の社内手順書は、実態と合わなくなっています。例外はBlob Storageにインデクサースケジュールを設定した場合で、インデックス名を接頭辞にした四つ（index / indexer / datasource / skillset）が残り、スケジュールは指定周期の0.5倍で組まれます。

接続できるデータソース八種における正式提供とプレビューの線引き

選べる接続先は八種類ありますが、正式提供の表記は多くありません。既存のAzure AI 検索インデックスとAzure Cosmos DB for MongoDB（仮想コア）を除き、ファイルアップロード、URL/Webアドレス、Blob Storage、Elasticsearch、Pinecone、MongoDB Atlasはプレビュー扱いです。

本番構成なら、選択肢は実質的に既存インデックスへの直接接続に絞られます。URL取り込みはHTTPS・1URLあたり5MB未満・入れ子のリンクは1階層かつ最大20リンクという制限があり、社内Wikiを丸ごと食わせる用途には届きません。取り込めるファイル形式も、.txt / .md / .html / .docx / .pptx / .pdf の六種です。

Azure AI 検索との連携で決める認証とインデックスの前提条件

接続方式は後から変えると影響範囲が広い設計判断です。認証とインデックス要件を先に固めてから取り込みに進んでください。

マネージドIDとAPIキーで変わるロール割り当ての設計と作業手順

認証はシステム割り当てマネージドIDかAPIキーの二択で、既定はマネージドIDです。APIキーは設定が速い反面、保管とローテーションが自前の運用課題として残ります。マネージドIDの割り当ては次の順です。

1. Azure OpenAIリソースのシステム割り当てマネージドIDを有効化する
2. そのIDに対し、Azure AI 検索サービス側で Search Index Data Reader と Search Service Contributor を割り当てる
3. APIを呼ぶ利用者アカウントに、Azure OpenAIリソースの Cognitive Services OpenAI User を割り当てる

ポータルの「次へ」を押した時点で構成が自動検証されるため、権限不足はその場で分かります。ポータルで一度通してからコードに移すほうが、原因の切り分けで迷わず速く済みます。

既存のインデックスを再利用するときに満たすべき三つの制約条件

手元のインデックスをそのまま繋ぎたいという相談は多いのですが、条件が三つあります。検索可能フィールドが最低一つあること、CORSの許可元の種類を all・許可される配信元を * にすること、複雑なフィールド（入れ子構造）を含まないことです。

三つ目でつまずく例が目立ちます。自前のインデクサーで階層のあるJSONを取り込んでいると複合フィールドが残るためで、平坦化して作り直す時点で再利用という狙いが崩れます。見積もりの段階でスキーマを確認してください。フィールドマッピングはコンテンツデータ・タイトル・ファイル名の三系統を指定し、この雑さがそのまま引用表示の粗さになります。

利用者ごとに回答へ使える文書を絞る仕組み（Entra IDのグループメンバーシップで検索結果をトリミングするセキュリティフィルター）も、既存インデックスにしか有効化できません。自動生成したインデックスには適用できないため、権限つきの社内文書を扱うなら、この一点でデータソースは既存インデックス一択に決まります。

検索方式とチャンクサイズの指定で回答精度はどこまで動かせるのか

取得の質を決めるつまみは、取り込み時に固定されるものと実行時に変えられるものに分かれます。触る順番を間違えると、無駄な再取り込みで半日溶けます。

五つの検索方式と追加課金とSKU要件の対応関係を先に押さえておく

Azure AI 検索をデータソースにした場合、指定できる検索方式は五つです。ベクターを含む方式には埋め込みモデルのデプロイが、セマンティックを含む方式にはBasic以上のSKUが要ります。

既定の挙動は「インテリジェント検索」と呼ばれ、埋め込みモデルがあればハイブリッド＋セマンティックが自動で選ばれます。方式選択の考え方は製品共通で、BM25とベクトル検索を統合するハイブリッド検索の仕組みを押さえると、この選択が何を足し合わせているのか読み解けます。多言語の判断は単純です。キーワードとセマンティックはクエリとデータの言語一致が前提のため、日本語と英語が混在するならベクター検索を有効にしてください。

既定1,024トークンのチャンクサイズを動かすときの判断基準

チャンクサイズの既定値は1,024トークンで、256・512・1,536も選べます。チャンクサイズと取得ドキュメント数の積が、そのままモデルに渡る情報量の上限になります。

公式は症状ベースの調整指針を示しています。答えが含まれているはずなのに「分かりません」が多いなら粒度を上げるため256か512へ下げる。正しい詳細は返るのに他の情報が欠けるなら文脈を多く拾うため1,536へ上げる。この二つです。分割方針はチャンク分割の代表的な手法とサイズ設計に譲りますが、ここで効くのは一点、変更には文書の再取り込みが要るという事実です。

strictnessとtop_n_documentsで先に試す実行時の調整

再取り込みが要らない調整から先に試してください。実行時パラメータは再読み込みなしで変えられます。

関連情報が抜け落ちるなら厳密さを1寄りに下げ、無関係な文書が混ざるなら5寄りに上げます。システムメッセージにあたる指示はrole_informationで渡すものの、これは取得工程に効かず生成の振る舞いを変えるだけです。

取得ドキュメント数の実効上限には構造的な制約があります。使用可能トークンの20%は応答用に予約され、残り80%にメタプロンプトと質問・会話履歴が入り、余った分を取得済みチャンクが使うためです。チャンクサイズ1,536で取得数20は掛け算なら30,720トークンですが、残枠に収まらなければ切り捨てられます。画面で選べることと、全部がモデルへ届くことは別です。

引用の返り方とAPI版差から読み取る実装時の注意点と調べる順番

回答本文だけを表示して終わると、この機能を選んだ意味の半分を捨てます。引用と取得ログの構造を押さえます。

citationsの五フィールドと本文中の[docN]を差し替える実装

応答のアシスタントメッセージにはcontextが付き、その下にcitations、intent、all_retrieved_documentsが並びます。引用の各要素が持つフィールドは五つです。

• content：引用本文。唯一の必須フィールド
• title：インデックスのタイトル列から生成される引用タイトル
• url：引用元のURL
• filepath：引用元のファイルパス
• chunk_id：どのチャンクかを示すID

回答本文には [doc1] [doc2] という参照記号が埋め込まれて返るため、クライアント側でcitationsの配列順（1始まり）と突き合わせ、リンクへ置換する実装が要ります。なおintentは「このプロパティは無視すること」とリファレンスに明記されており、実装で参照する対象ではありません。

filter_reasonの値で文書が落ちた理由を切り分ける

精度が出ないときに最初に見るのはall_retrieved_documentsです。取得された全文書が、検索クエリ・元の検索スコア・再ランクスコアとともに入っています。

切り分けに効くのがfilter_reasonです。値がscoreなら厳密さのしきい値による元スコアでの足切り、rerankなら足切りは通過したが再ランクスコアと取得ドキュメント数の枠から漏れた、という意味になります。未設定ならフィルタされていません。つまりscoreが並べば厳密さを下げる、rerankが並べば取得ドキュメント数を増やす、と対処が一意に決まります。取得はされたが引用に使われなかった文書へ、APIがUNCITED_REFERENCE型を返す点もデバッグの手がかりになります。

api-versionの版差で壊れるパスとプロパティの命名規則

APIは2024-02-15-previewで作り替えられ、サポート版は2024-02-15-preview、2024-02-01、2024-05-01-previewの三つです。破壊的変更は四点あります。

• パスが /extensions/chat/completions から /chat/completions へ変更
• プロパティ名と列挙値がキャメルケースからスネークケースへ変更
• データソース種別 AzureCognitiveSearch が azure_search へ改名
• 引用と意図がツールメッセージからcontext直下へ移動

落とし穴は表記の混在です。概念解説ページにはinScopeなどの旧表記が残る一方、リファレンスはスネークケースへ変わったと明記しています。実装時はリファレンスを優先してください。data_sourcesを指定するとlogprobsが使えない点も注意が要ります。呼び出しの基本形はAzure OpenAI APIのリソース作成から呼び出しまでの手順と共通です。

2026年10月14日の提供終了に向けた移行先と残り期間の使い方

ここからは判断の話です。前提として新しいモデルのオンボーディングはすでに停止しており、Azure OpenAI Service本体のモデルにも個別の提供終了スケジュールがあります。本体側の廃止が先に来れば、機能の終了日を待たずに構成が動かなくなる二重の期限です。安価なモデルへ載せ替えて運用費を圧縮する手も、最初から封じられています。

Foundry IQのナレッジベースが引き受ける取得処理の範囲

Foundry IQはナレッジベース・ナレッジソース・エージェント検索の三要素で構成され、基盤の索引と取得はAzure AI 検索が担います。On Your Dataで使っていたインデックスの知識が、そのまま生きる構造です。

できることは広がりました。ナレッジソースとしてBlob StorageのほかSharePointやOneLake、パブリックWebデータを繋げられ、複数のエージェントが一つのナレッジベースを共有できます。エージェント検索は複雑な質問をサブクエリへ分解して並列実行し、結果を意味的に再ランクして統合します。意図生成が一段だったOn Your Dataに対し、クエリ計画を持つ多段パイプラインへ変わったわけです。アクセス制御リストの同期とPurviewの秘密度ラベル遵守も入りました。ただし2026年8月13日更新の時点で正式提供とプレビューが混在するため、移行検証では必要な機能がどちらの区分かを確認してください。

残り期間別に決める新規案件と既存案件それぞれの扱い方と判断基準

判断を言い切ります。新規案件での本番採用は見送りです。二か月後に終わる基盤の上へ業務を載せる合理性がありません。要件定義中の案件があるなら、Foundry IQ側で組み直す前提に切り替えてください。

既存案件は三つに分かれます。第一に、社内向けの少人数利用で停止許容度が高いものは、終了日に合わせた計画停止と移行でかまいません。第二に、業務が依存して止められないものは、インデックス資産を引き継ぎつつFoundry IQへ並行構築し、切り替え後にOn Your Data経路を落とす二重化が要ります。第三に、要件が「特定インデックスへの単純な検索と要約」だけなら、自前の最小構成へ落とすほうが安く済みます。この見極めを含む移行設計は、RAG構築支援のような外部の実装知見を入れて短期集中で片付けるほうが現実的です。

自前でRAGを組む構成とOn Your Dataを分ける判断基準

最後に、この手のマネージド機能を選ぶべきか否かの線引きを整理します。移行先を決めるときにも同じ軸が使えます。

制御をどこまで手放してよいかで線を引くための四つの判断軸を持つ

マネージド接続を選ぶ判断は「楽かどうか」ではなく「制御を手放してよいか」で決まります。軸は四つです。

一つ目は検索クエリの制御です。質問文から検索意図を内部生成するため書き換えロジックに手を入れられず、業務用語の辞書や同義語展開を自前で持ちたいなら向きません。二つ目はランキングの制御で、再ランクの内部ロジックは非公開です。三つ目は前処理の制御で、対応ファイル形式は六種に固定されています。四つ目は取得後の制御で、取得結果から外部APIを呼ぶ分岐が挟めません。

四つのうち二つ以上を握る必要があるなら、マネージド接続は選ばないでください。逆に、既存インデックスへの素直な質問応答で引用表示があれば足りるなら、自前実装は過剰です。グラフ構造を持たせた検索まで踏み込むなら方式が別で、GraphRAGをAzure上で動かす現行構成のように索引の作り方から設計する話になります。

tools併用で取得が無効になる仕様が示す設計面での限界と分岐点

設計上の限界が分かりやすく出るのが、関数呼び出しとの併用です。toolsとdata_sourcesの両方が入ったリクエストに、ドキュメントは二つのポリシーを示しています。

tool_choiceがnoneならツールは無視され、回答生成にはデータソースだけが使われます。それ以外、つまり未指定かautoかオブジェクト指定の場合はデータソースのほうが無視され、応答には選ばれた関数名と引数が入ります。モデルが結果的に関数を選ばなかったときでも、データソースは無視されたままです。

「社内文書を検索しつつ、必要なら基幹システムのAPIも叩くエージェント」は、この機能単体では成立しません。エージェント的な振る舞いが要件に入っている時点で、選ぶべきはFoundry Agent Serviceか自前実装になります。この分岐は要件定義の早い段階で潰せます。

よくある質問

実装前後で問い合わせの多い論点を、一次情報に沿って五つ整理します。

Azure OpenAI On Your Dataはいつ使えなくなりますか？

2026年8月16日に確認したMicrosoft Learn日本語版では、終了日は2026年10月14日と記載され、「廃止されており、まもなく廃止間近」という表記も併記されています。日付は一次情報側で更新される可能性があるため、移行計画では公式ドキュメントの当該注記を直接確認してください。

取り込んだインデックスは移行後もそのまま使えますか？

インデックス自体はAzure AI 検索側のリソースなので、機能の終了で消えるわけではありません。移行先のFoundry IQも基盤の索引と取得にAzure AI 検索を使います。ただしナレッジソースの定義やスキーマ要件が同一とは限らず、そのまま接続できるかは個別検証が要ります。統合ベクター化への切替以降に作られたかどうかで内部構造も違うため、作成時期の確認から入ってください。

チャンクサイズと厳密さはどちらを先に調整すべきですか？

厳密さと取得ドキュメント数を先に動かしてください。実行時パラメータは再読み込みなしで変更できる一方、チャンクサイズの変更には文書の再取り込みが要るためで、公式も同じ順序を推奨しています。一通り試しても改善しない場合に限ってチャンクサイズを検討する流れが、手戻りを減らします。判断材料にはfilter_reasonの分布を使ってください。

回答に引用が付かないのはどう調べればよいですか？

まずall_retrieved_documentsで文書が取得されているかを見ます。取得済みなのに引用へ現れないならUNCITED_REFERENCE型で返っている可能性があり、取得自体がなければfilter_reasonがscoreなら厳密さを下げ、rerankなら取得数を増やします。引用のタイトルが空なら、フィールドマッピングの指定漏れを疑ってください。

Azure AI 検索で503エラーが返る原因は何ですか？

一つのユーザーメッセージが複数の検索クエリへ変換され、並列で検索リソースへ送られる仕組みが原因になり得ます。レプリカとパーティションが少ない構成では、支えられる秒間クエリ数を超えてスロットリングが起きます。対処はレプリカとパーティションを増やすか、待機と再試行を入れるかの二択です。

関連記事

• Azure OpenAI Serviceとは？できること・料金・導入事例まで実務目線で解説：土台となるサービス全体の提供範囲と料金体系
• Azure OpenAI APIの使い方｜リソース作成からPython・REST呼び出しまでの実装手順：素のチャット補完呼び出しを組み立てる手順
• GraphRAGをAzureで動かす方法｜Accelerator終了後の現行構成と実装手順：索引の作り方から設計する別方式のRAG構成
• 埋め込みモデルとは？仕組みと日本語モデルの選び方・RAG実装での判断基準：ベクター検索で使う埋め込みデプロイの選定材料
• RAG構築の手順とは？データ整備から精度向上・本番運用までの進め方：製品に依存しない工程全体を発注検討の視点で整理