Azure AI Foundryで「Azure OpenAI On Your Data（classic）」を使って社内データ検索やCopilot風チャットを作っている場合、最初に押さえるべき結論は明確です。新規開発はclassic前提で始めず、既存環境はサポート対象モデル、データ接続、RBAC、Azure AI Searchのインデックス、移行先を早めに確認する必要があります。 Microsoftの公式情報では、Azure OpenAI On Your Dataは廃止に向かう機能として扱われ、新しいモデルのオンボーディングは停止され、Foundry Agent ServiceとFoundry IQへの移行が推奨されています。(Microsoft Learn)
一方で、すでにAzure OpenAI On Your Dataを使って「社内文書に基づく回答」「FAQチャットボット」「Teams向け業務Copilot」「Azure AI Search連携のRAG」を運用している組織では、すぐに止めるのではなく、現行構成を棚卸ししながら段階的に移行するのが現実的です。この記事では、Azure AI Foundryのclassic向け公式情報と、2026年5月14日に更新されたFoundry Models関連情報を踏まえ、管理者・開発者が確認すべきポイントを実務目線で整理します。(Microsoft Learn)
Azure AI FoundryのAI/Copilot更新で何が変わるのか
Azure OpenAI On Your Data（classic）は、Azure OpenAIモデルを自社データに接続し、検索結果を根拠に回答を生成するための機能です。モデルを追加学習するのではなく、Azure AI Searchなどで関連文書を検索し、その文脈を使って回答を生成するRAG型の仕組みとして使われてきました。(Microsoft Learn)
今回の公式情報で特に重要なのは、「機能が便利になった」というより、classic機能としての扱いが明確になり、移行計画が必要になったという点です。
| 確認項目 | 変更・注意点 | 実務上の影響 |
|---|---|---|
| 対象ポータル | 対象記事はFoundry（classic）ポータル向けで、新しいFoundryポータル向けの記事ではない | 新規構築時にclassic手順をそのまま採用すると、将来の移行負担が増える |
| 機能の位置付け | Azure OpenAI On Your Dataは廃止に向かう機能として案内されている | 既存運用は継続可否だけでなく、移行ロードマップを持つ必要がある |
| モデル対応 | 新しいモデルのオンボーディングは停止され、対応モデルが限定されている | モデル更新だけで機能改善する計画は立てにくい |
| 推奨移行先 | Foundry Agent ServiceとFoundry IQへの移行が推奨されている | RAG基盤を「データ接続」から「エージェント＋ナレッジベース」へ見直す必要がある |
| データ取り込み | 2024年9月以降、インジェストAPIはAzure AI Searchの統合ベクター化を使う方式に切り替わっている | 旧来のカスタムスキルやチャンク用コンテナーを前提にした運用確認は見直しが必要 |
Microsoftは、Azure OpenAI On Your DataでサポートされるモデルをGPT-4oの一部バージョンとGPT-4o-miniの特定バージョンに限定しており、GPT-4o-miniが終了すると、On Your Data APIエンドポイントとサポート対象データソースコネクターが機能しなくなると説明しています。(Microsoft Learn)
Azure OpenAI On Your Data（classic）でできること
Azure OpenAI On Your Dataは、社内文書やWebコンテンツ、Blob Storage、Azure AI SearchインデックスなどをAzure OpenAIに接続し、検索結果を根拠に回答を生成するための機能です。トレーニングやファインチューニングを行わずに、指定したデータソースの情報を使って回答できる点が特徴です。(Microsoft Learn)
典型的な流れは、次の3段階です。
| 段階 | 内容 | 管理・開発で見るべきポイント |
|---|---|---|
| 取り込み | ファイルや既存データソースを接続し、Azure AI Searchにチャンク化・埋め込みを行う | 対応ファイル形式、インデックス設計、ベクター列、取り込み失敗時のログ |
| 開発 | REST API、SDK、Foundryポータルからアプリケーションを作る | data_sources、検索パラメーター、フィールドマッピング、認証方式 |
| 推論 | ユーザー質問を検索意図に変換し、関連チャンクを取得・再ランク付けして回答する | 厳密さ、取得文書数、トークン消費、回答根拠、アクセス制御 |
対応ファイル形式は、.txt、.md、.html、.docx、.pptx、.pdfです。ただし、表・列・箇条書きが多い文書やスキャンPDFでは、取り込み後の回答品質が落ちることがあります。公式ドキュメントでも、特殊な書式や長文データではデータ準備スクリプトの利用が推奨されています。(Microsoft Learn)
実務では、「対応形式だからそのまま投入する」のではなく、次の観点で前処理を行うと失敗が減ります。
- 社内規程やマニュアルは、章・節・見出しが失われない形式で取り込む
- PDF内の表は、必要に応じてMarkdownやテキストに変換してから検証する
- よく質問されるFAQは、1問1答形式だけでなく、関連する条件や例外も同じチャンクに入るよう調整する
- 古い版と最新版が混在する文書は、メタデータで版数や有効日を管理する
影響範囲：どのシステムが確認対象になるか
影響を受けるのは、Azure AI FoundryやAzure OpenAIを使っている全システムではありません。主に、Azure OpenAI On Your Data（classic）のデータソース連携機能に依存している構成が対象です。
特に確認すべき構成は次の通りです。
| 対象 | 確認すべき理由 |
|---|---|
| Foundry（classic）ポータルから「Add your data」を使ったチャット | 対象機能そのものに該当する |
| Azure AI SearchをデータソースにしたRAGアプリ | フィールドマッピング、検索種別、認証、インデックス構成の影響を受ける |
| Blob Storageやローカルファイルアップロードを使う構成 | 取り込み、スケジュール更新、ストレージ権限の確認が必要 |
| URL/Webアドレスをデータソースにした構成 | HTTPS、サイズ、アクセス制御の制限に注意が必要 |
| Copilot Studio、Teamsアプリ、Webアプリへのデプロイ | tenant、プレビュー機能、認証、展開先の制約を確認する必要がある |
APIでdata_sourcesを指定しているアプリ | モデル対応、関数呼び出しとの競合、移行時のAPI設計変更に注意が必要 |
逆に、Azure AI SearchとAzure OpenAIを自前で組み合わせた完全独自のRAG実装は、On Your Dataのデータソースコネクター停止の直接影響を受けにくい場合があります。ただし、使用しているAzure OpenAIモデルの廃止スケジュールやリージョン可用性は別途影響するため、モデルライフサイクルは必ず確認してください。モデル廃止スケジュールでは、GPT-4o-mini 2024-07-18の廃止日が2026年10月1日、置き換え候補がGPT-4.1-miniとして示されています。(Microsoft Learn)
管理者が最初に確認すべき設定
サポート対象モデルと廃止スケジュールを確認する
Azure OpenAI On Your Data（classic）は、新しいモデルを順次追加していく前提の機能ではなくなっています。公式情報では、サポート対象がGPT-4oの特定バージョンとGPT-4o-mini 2024-07-18に限定されています。(Microsoft Learn)
管理者は、まず次の情報を一覧化してください。
| 確認項目 | 具体例 |
|---|---|
| Azure OpenAIリソース | リソース名、リージョン、サブスクリプション |
| デプロイ名 | アプリ側で指定しているモデルデプロイ名 |
| モデル名・バージョン | GPT-4o 2024-11-20、GPT-4o-mini 2024-07-18など |
| デプロイ種別 | Standard、Global Standard、Provisionedなど |
| 利用アプリ | Webアプリ、Teamsアプリ、社内FAQ、問い合わせ対応など |
| 代替候補 | Foundry Agent Service、Foundry IQ、独自RAG、別モデル |
モデル廃止は「ある日突然アプリが壊れる」形で影響することがあります。Microsoftのモデルライフサイクルでは、Retiredになったモデルへの推論リクエストは410 Goneを返すと説明されています。Provisionedデプロイは自動アップグレードされないため、手動移行が必要です。(Microsoft Learn)
マネージドIDとRBACを見直す
Azure OpenAI On Your Dataでは、Azure OpenAI、Azure AI Search、Azure Blob Storageの接続認証として、システム割り当てマネージドIDまたはAPIキーを選択できます。公式ドキュメントでは、セキュリティ上の理由からシステム割り当てマネージドIDが既定で選択されると説明されています。(Microsoft Learn)
本番環境では、APIキーをコードや設定ファイルに直接埋め込む運用は避けるべきです。どうしてもキー認証を使う場合は、Azure Key Vaultで管理し、ローテーション手順を用意してください。
RBACで特に見落としやすいのは、推論時にもAzure OpenAI側のIDがAzure AI Searchのインデックスフィールドを取得する必要がある点です。ネットワークとアクセス構成の公式情報では、推論時にもAzure OpenAI IDにSearch Service Contributorロールが必要と説明されています。(Microsoft Learn)
ネットワーク制限とプライベートエンドポイントを確認する
Azure OpenAI、Azure AI Search、Storage Accountでパブリックネットワークアクセスを無効化している場合、取り込みと推論の両方で通信経路を確認する必要があります。公式情報では、選択したネットワークをIPルールで許可する構成は、サービス側IPが動的であるためサポートされないと説明されています。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| Azure OpenAI | カスタムサブドメイン、マネージドID、信頼されたサービス、プライベートエンドポイント |
| Azure AI Search | RBAC有効化、マネージドID、信頼されたサービス、共有プライベートリンク |
| Storage Account | 信頼されたサービス、Blob用プライベートエンドポイント、SAS発行権限 |
| Webアプリ | VNet統合、Private DNS、Azure OpenAIへの名前解決 |
| 開発端末 | VPN、hosts設定、Foundryポータルからの到達性 |
「ポータルでは動くがWebアプリでは動かない」「取り込みはできるが推論時に失敗する」といった問題は、権限とネットワークのどちらか片方だけを確認しているケースで起きやすいです。
ドキュメントレベルのアクセス制御を確認する
社内データを扱うRAGでは、「回答が正しいか」だけでなく、「そのユーザーに見せてよい文書だけを根拠にしているか」が重要です。Azure OpenAI On Your Dataでは、Azure AI Searchをデータソースにした場合にドキュメントレベルのアクセス制御がサポートされ、Microsoft Entraグループメンバーシップに基づいて検索結果を絞り込めます。(Microsoft Learn)
ただし、既存のAzure AI Searchインデックスでのみ有効にできるため、あとから慌てて追加するとインデックス再設計が必要になることがあります。機密文書を扱う場合は、少なくとも次を確認してください。
group_idsなどの権限フィールドがCollection(Edm.String)かつfilterableで定義されている- 各文書に許可グループの値が入っている
- API利用時はユーザーのグループ情報に基づく
filterをリクエストに含めている - フィールドマッピングで権限フィールドが正しく指定されている
- テストユーザーを複数用意し、見えてはいけない文書が回答に混ざらないか検証している
開発者が確認すべき実装上の注意点
フィールドマッピングは回答品質に直結する
既存のAzure AI Searchインデックスを使う場合、Content data、Title、File name、URLなどのフィールドマッピングが重要です。公式情報では、Content dataやTitleにマッピングされたフィールドが質問回答の情報として使われ、File nameにマッピングされたフィールドが引用名の生成に使われると説明されています。(Microsoft Learn)
実務では、次のようなミスがよく起きます。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 本文ではなく概要フィールドだけをContentに指定 | 回答が浅くなる、詳細に答えられない | 回答に必要な本文フィールドをすべてContentに含める |
| タイトルやファイル名が未設定 | 引用が分かりにくく、ユーザーが根拠を確認できない | 文書名、章タイトル、URLをメタデータとして整備する |
| 古い文書と新しい文書を区別していない | 古い規程に基づく回答が出る | 有効日、版数、ステータスをメタデータで管理する |
| 権限フィールドをマッピングしていない | ドキュメントレベル制御が無効になる | アクセス制御用フィールドを設計段階で追加する |
検索種別はコストと精度のバランスで選ぶ
Azure OpenAI On Your Dataでは、キーワード検索、セマンティック検索、ベクター検索、ハイブリッド検索などを利用できます。セマンティック検索やベクター検索には追加コストが発生する場合があり、ベクター検索を使うには埋め込みモデルのデプロイやインデックス側のベクター列が必要です。(Microsoft Learn)
選び方の目安は次の通りです。
| 用途 | 推奨しやすい検索方式 | 理由 |
|---|---|---|
| 型番、製品コード、エラー番号を探す | キーワード検索 | 完全一致や語句一致が効きやすい |
| 社内規程やFAQを自然文で検索する | セマンティック検索 | 言い換えに強く、回答候補の関連性を上げやすい |
| 表現ゆれや多様な言い回しが多い文書を探す | ベクター検索 | 意味的に近い文書を拾いやすい |
| 問い合わせ対応やナレッジ検索全般 | ハイブリッド検索 | キーワードと意味検索の両方を活かせる |
| 日本語文書を高精度に扱う | セマンティック検索またはハイブリッド | 公式情報では日本語を含む複数言語でセマンティック検索が推奨されている |
チャンクサイズは「大きければよい」ではない
Azure OpenAI On Your Dataでは、取り込む文書をチャンクに分割して処理します。公式ドキュメントでは、既定のチャンクサイズは1,024トークンで、データセットによっては256、512、1,536トークンなどの調整が有効な場合があると説明されています。(Microsoft Learn)
目安として、FAQや短い規程条文は小さめのチャンク、背景説明や手順が長いマニュアルは大きめのチャンクが合うことがあります。ただし、チャンクサイズを変更するには再取り込みが必要です。まずはランタイムパラメーターである厳密さや取得ドキュメント数を調整し、それでも改善しない場合にチャンクサイズを変更するのが効率的です。(Microsoft Learn)
toolsとdata_sourcesを同時に使う場合は挙動を確認する
Azure OpenAIの一部モデルでは、関数呼び出しに使うtoolsやtool_choiceを指定できます。ただし、Azure OpenAI On Your Dataの公式情報では、toolsとdata_sourcesが同じリクエストに含まれる場合のポリシーが明示されています。tool_choiceがnoneの場合はツールが無視され、データソースだけが使われます。tool_choiceが未指定、auto、またはオブジェクト指定の場合は、データソースが無視される扱いになります。(Microsoft Learn)
つまり、「社内データを検索しつつ、必要に応じて業務APIを呼び出す」ような高度なエージェントを作りたい場合、classicのOn Your Dataだけで自然に実現できるとは限りません。このような用途では、Foundry Agent Serviceや独自オーケストレーションへの移行を検討した方が設計しやすくなります。
トークン消費は検索回数と会話履歴で増える
On Your DataのRAGパイプラインでは、ユーザーの質問を検索意図に変換する呼び出しと、取得した文書チャンクを使って回答を生成する呼び出しが行われます。公式情報では、意図プロンプトと生成プロンプトの両方を考慮してトークン使用量を見積もる必要があると説明されています。(Microsoft Learn)
コストや遅延を抑えるには、次の設定を見直してください。
| 設定 | 増やすと起きやすいこと | 調整の考え方 |
|---|---|---|
| 取得ドキュメント数 | トークン増、回答の根拠は増える | まず5件前後で評価し、根拠不足なら増やす |
| 厳密さ | 高すぎると「分からない」が増える、低すぎるとノイズが増える | FAQ、規程、マニュアルごとに評価セットを作る |
| 会話履歴 | 文脈は保てるがトークン消費が増える | 長い会話では履歴要約や新規会話開始を検討する |
| システムメッセージ | 制御力は上がるがプロンプトが長くなる | 禁止事項や回答形式を絞って書く |
inScope | trueでは根拠データに限定しやすい | 社内データに基づく回答では原則trueで検証する |
移行先としてのFoundry Agent ServiceとFoundry IQ
Microsoftは、Azure OpenAI On Your Dataのワークロードについて、Foundry Agent ServiceとFoundry IQへの移行を推奨しています。Foundry IQは、複数のナレッジソースを持つナレッジベースを作成し、エージェントがユーザー権限を考慮しながら根拠付き回答を生成するための仕組みです。Azure Blob Storage、SharePoint、OneLake、パブリックWebデータなどをナレッジソースとして扱えます。(Microsoft Learn)
Foundry Agent Serviceは、モデル、ツール、フレームワーク、ガバナンスを統合し、会話管理、ツール呼び出し、コンテンツ安全性、ID、ネットワーク、監視といった本番運用向けの要素を扱うサービスとして説明されています。(Microsoft Learn)
移行先の選び方は、次のように考えると分かりやすいです。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| classicを短期継続 | すでに本番運用中で、すぐ停止できない | モデル廃止、コネクター停止、移行期限のリスクを常に確認する |
| Foundry Agent Service + Foundry IQ | 社内データ検索、権限付き回答、複数データソース、将来のエージェント化を進めたい | 一部機能はAPIバージョンやプレビュー状態に依存するため、本番適用前に確認する |
| 独自RAG実装 | 検索、再ランキング、プロンプト、ログ、評価を細かく制御したい | 開発・運用・セキュリティ設計の負担が増える |
| Copilot Studio中心 | 業務ユーザー向けにMicrosoft 365やTeamsで展開したい | データ接続、テナント、権限、リージョン制約を事前確認する |
Foundry IQの一部機能は一般提供されていますが、他の機能はプレビューのままです。公式情報では、利用できる機能がSearch Service REST APIバージョンに依存し、ポータルからのagentic retrieval機能アクセスはプレビュー扱いである点も説明されています。(Microsoft Learn)
現実的な移行手順
Azure OpenAI On Your Data（classic）からの移行は、単にモデル名を変える作業ではありません。データソース、検索品質、権限、ユーザー体験、コストを一緒に確認する必要があります。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 現状棚卸し | 利用アプリ、モデル、データソース、インデックス、認証方式を一覧化 | 構成管理表 |
| リスク判定 | 廃止対象モデル、classic依存、権限不備、ネットワーク制約を確認 | 優先度リスト |
| 評価セット作成 | よくある質問、正解文書、期待回答、NG回答を用意 | 回答品質テストセット |
| 移行先設計 | Foundry IQ、Agent Service、独自RAGのどれに寄せるか決める | 移行アーキテクチャ |
| 並行検証 | 現行On Your Dataと移行先で同じ質問を比較 | 精度・遅延・コスト比較 |
| 権限テスト | 一般ユーザー、管理者、閲覧不可ユーザーで回答差分を確認 | セキュリティ検証結果 |
| 段階展開 | 一部ユーザーや一部データソースから切り替える | リリース計画 |
| 旧環境整理 | 不要なインデックス、ストレージ、キー、Webアプリを削除 | コスト削減とリスク低減 |
移行時に最も失敗しやすいのは、「回答が似ているからOK」と判断してしまうことです。RAGの移行では、回答文面だけでなく、根拠文書、引用、アクセス制御、古い文書を参照していないか、トークン消費、応答速度まで確認してください。
展開時に注意すべきCopilot、Teams、Webアプリのポイント
Azure OpenAI On Your Data（classic）では、データ接続後にCopilot、Teamsアプリ、Webアプリとして展開する選択肢があります。公式情報では、Copilot Studioへの直接デプロイはプレビューで、米国リージョンのみ利用可能とされています。また、Azure OpenAIとCopilot Studioで使うテナントは同じである必要があります。(Microsoft Learn)
Teamsアプリについても、既定ではセットアップ時に使ったAzureアカウントと同じテナント内での利用を前提に安全に構成されます。別テナントのTeamsアカウントで使うとエラーになります。(Microsoft Learn)
展開前には、次を確認してください。
- 対象ユーザーが同一テナント内にいるか
- カスタムTeamsアプリのアップロードが許可されているか
- WebアプリからAzure OpenAIにプライベート接続できるか
- Azure AI Searchキーや接続情報を設定ファイルに直接残していないか
- 引用表示や根拠確認がユーザーにとって分かりやすいか
- 本番利用する機能がプレビュー扱いではないか、またはプレビュー利用を許容できるか
よくあるトラブルと対処法
Azure OpenAI On Your Data（classic）のトラブルは、モデル単体の問題ではなく、データ取り込み、検索、権限、ネットワーク、クォータが絡んで発生します。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| インデックス作成に失敗する | Azure AI Searchのインデックス数やインデクサー数の上限超過 | 未使用インデックスを削除する、上位SKUを検討する |
| 取り込みがタイムアウトする | 大きすぎる文書、複雑なPDF、前処理負荷 | 文書を分割する、形式を整える、表をテキスト化する |
| 権限エラーが出る | Storage AccountやSearchへのロール不足 | マネージドIDとRBACロールを確認する |
| 回答が「分かりません」ばかりになる | 厳密さが高すぎる、チャンクが細かすぎる、検索対象が不足 | 厳密さ、取得文書数、チャンクサイズを調整する |
| 関係ない文書を根拠にする | メタデータ不足、検索方式の不一致、古い文書混在 | フィールドマッピング、版数管理、検索方式を見直す |
| Azure AI Searchで503が出る | 検索クエリが並列実行され、レプリカやパーティションが不足 | レプリカ・パーティション増強、リトライ処理を追加する |
公式情報でも、インデックスクォータ超過、前処理タイムアウト、権限不足、Azure AI Searchのスロットリングが代表的な問題として挙げられています。(Microsoft Learn)
今すぐやるべきチェックリスト
Azure AI FoundryでAzure OpenAI On Your Data（classic）を使っている管理者・開発者は、次の順番で確認してください。
- 現在のアプリがAzure OpenAI On Your Data（classic）の
data_sourcesやFoundry（classic）ポータルのデータ接続に依存しているか確認する - 使用中モデルの名前、バージョン、デプロイ種別、リージョン、廃止日を一覧化する
- GPT-4o-mini 2024-07-18やGPT-4o各バージョンを使っている場合、モデル廃止スケジュールと代替候補を確認する
- Azure AI Searchのインデックス、フィールドマッピング、ベクター列、セマンティック検索設定を点検する
- システム割り当てマネージドIDとRBACロールを確認し、APIキー直書きをなくす
- ドキュメントレベルのアクセス制御が必要なデータでは、Entraグループと検索フィルターを検証する
- Foundry Agent ServiceとFoundry IQ、または独自RAGへの移行方針を決める
- よくある質問と期待回答を使って、現行環境と移行先を並行評価する
- Webアプリ、Teams、Copilot Studioに展開している場合は、テナント、リージョン、プレビュー機能、ネットワーク制約を確認する
Azure OpenAI On Your Data（classic）は、社内データを使った生成AI活用の入口として便利な機能でした。しかし、今後のAzure AI Foundryでは、単純な「データ接続付きチャット」から、ナレッジベース、権限、ツール呼び出し、監視、ガバナンスを備えたエージェント基盤へ重心が移っています。
既存環境を運用している場合は、まず構成とモデルを棚卸しし、回答品質とアクセス制御を評価できるテストセットを作ることが最優先です。そのうえで、Foundry Agent ServiceとFoundry IQへの移行、または独自RAG基盤への置き換えを段階的に進めると、廃止リスクを抑えながらAzure AI Foundryの新しい構成へ移行できます。
コメント