Azure AI / Azure OpenAI 2026年4月29日の公式ブログ解説: Azure AI Foundry IQ の役割

Microsoft Tech Community の Making Sense of Azure AI Foundry IQ は、Azure AI Foundry IQ をどのようなknowledge layerとして使うべきかを整理する記事です。エージェントが組織内知識へ安全にアクセスするための境界を説明しています。

要点

• Foundry IQ は Azure AI Search 上に構築された managed knowledge layer として説明されている
• SharePoint、Azure Blob Storage、OneLake、既存Azure AI Search indexなど複数のcontent sourceを単一の権限-aware エンドポイントとして扱える
• SQL実行、集計、リアルタイム数値精度を担うものではなく、主に非構造化テキスト検索・引用付き回答のための層として位置づけられている
• knowledge baseを複数エージェントやアプリで再利用し、検索 パイプラインの重複を減らす考え方が示されている

今回のブログ記事で語られていること

今回のブログ記事は、enterprise teamsがAI エージェントを作るとき、難しいのはモデル選びだけではなく、組織内の知識へどのように正確・安全・継続的にアクセスするかだと説明しています。社内文書はSharePoint、Blob Storage、OneLake、wiki、既存検索indexなどに分散しており、エージェントごとに検索 パイプラインを作ると、接続、chunking、埋め込み、routing、権限が重複し、保守が難しくなります。Foundry IQ はこの課題に対し、複数のknowledge sourceを一つのknowledge baseとして定義し、エージェントやアプリから権限-aware エンドポイントとして利用できるようにする層として紹介されています。

記事では、Foundry IQ が何をするか、何をしないかが明確に区別されています。エージェントがknowledge baseに問い合わせると、Foundry IQはクエリの実行計画を立て、関連するknowledge sourceを選び、検索を実行し、ユーザー 権限を適用し、citation付きのgrounded resultsを返します。一方で、Foundry IQはSQL queryを実行したり、数値集計をしたり、リアルタイムの分析精度を保証したりするものではありません。つまり、業務データベースに直接問い合わせる分析レイヤーではなく、非構造化文書やナレッジをエージェントが安全に参照するためのmanaged 検索 layerです。

この整理は、AI エージェント設計において重要です。多くの失敗は、knowledge baseを万能データアクセス層のように扱うことから起こります。規程、手順書、FAQ、提案書、設計資料などの文書ベース回答には向きますが、最新売上の集計、在庫数の正確な照会、トランザクションデータの計算には別の仕組みが必要です。この記事は、Foundry IQを使うべき場面、使うべきでない場面、Azure AI Search API/SDKでknowledge baseを直接queryする方法の方向性を示しており、enterprise knowledge copilotの基盤設計に役立ちます。

今回のブログ記事が関係する人

• Azure AI Foundryでknowledge copilotやエージェントを作る開発チーム
• SharePoint、Blob、OneLake、Azure AI Searchを横断した社内検索を設計する人
• 権限-aware 検索 と引用付き回答を標準化したいプラットフォーム担当

実務でまず確認したいこと

1. Foundry IQで扱うknowledge sourceと、扱わない構造化データを分ける
2. 権限 enforcementとcitationの出方を実データで検証する
3. 複数エージェントでknowledge baseを再利用する運用単位を決める

結局、今回のブログ記事をどう読むべきか

Foundry IQは、社内知識をエージェントへ安全に渡すためのmanaged 検索 layerです。万能なデータアクセス基盤ではなく、文書・知識・権限付き検索を標準化する部品として読むと設計を誤りにくくなります。