Microsoft Discoveryは、Microsoft Azure上で研究開発向けのエージェントAIワークフローを構築・管理するための企業向けプラットフォームです。2026年6月5日にAzure Updatesで「Launched / General Availability」として公開・更新され、R&D組織は本番利用を前提に検討できる段階になりました。あわせて、個人や小規模チームがローカル環境で試せるMicrosoft Discovery appはプレビューとして提供されています。(マイクロソフト Azure)
ただし、すぐに全社展開すべき更新ではありません。管理者は、対応リージョン、サブスクリプションの有効化、RBAC、ネットワーク、ストレージ、モデルデプロイ、課金の見積もりを先に確認する必要があります。特に既存のAzure OpenAI ServiceやMicrosoft Foundry活用とは管理対象が異なるため、「AIエージェントを試す」段階と「R&D業務に組み込む」段階を分けて判断することが重要です。
Microsoft AzureのAI/Copilot更新で何が変わるのか
今回の要点は、Microsoft Discoveryが一般提供になったことです。Azure Updatesにおける「Launched」は、Azureの説明上、本番利用可能な状態として扱われるステータスです。(マイクロソフト Azure)
Microsoft Discoveryは、単なるチャット型AIではありません。研究テーマに対して仮説を立て、必要なエージェントやツールを選び、シミュレーションや分析を実行し、結果を検証しながら次の作業へ進む「エージェント型の研究開発ワークフロー」を管理するための基盤です。Microsoft公式ブログでは、科学・工学領域のR&Dワークフローを構築・統制する包括的なプラットフォームとして説明されています。(マイクロソフト Azure)
一方で、Microsoft Discovery appはプレビューです。こちらはローカルデスクトップで使う入口として提供され、GitHub Copilotアカウントを使って開始できます。企業の機密データや大規模計算を扱う本番環境というより、個人検証、学術用途、小規模PoCに向いた位置付けです。(マイクロソフト Azure)
まず押さえるべき変更点
| 項目 | 変更内容 | 実務上の意味 |
|---|---|---|
| 提供状態 | Microsoft Discoveryが一般提供 | R&D向けの本番導入候補として評価できる |
| 対象 | 科学・工学・製造・材料・創薬などの研究開発組織 | 通常の業務チャットAIではなく、研究開発プロセスの自動化・統制が主眼 |
| 実行基盤 | Azure上のワークスペース、プロジェクト、エージェント、ツール、ストレージ、計算基盤 | Azure管理者の設計・権限管理・コスト管理が必要 |
| ローカル利用 | Microsoft Discovery appがプレビュー | 個人検証やPoCの入口として使えるが、企業統制やSLAはクラウド版と同等ではない |
| 連携領域 | Microsoft Foundry、Azure OpenAI、Azure Machine Learning、HPCなどと関連 | 既存のAzure AI基盤と切り離さず、R&D基盤全体として設計する必要がある |
Microsoft Discoveryとは何か
Microsoft Discoveryは、エージェント型オーケストレーション、高度な推論、グラフベースの知識基盤、高性能コンピューティングを組み合わせたAzure上のR&D向けプラットフォームです。公式ドキュメントでは、Azureのエンタープライズクラウド基盤上で、セキュリティ、コンプライアンス、透明性、ガバナンスの枠組みに沿って運用できるよう設計されていると説明されています。(Microsoft Learn)
中心になるのがDiscovery Engineです。これは、ユーザーの目的をもとに作業を分解し、専門エージェントに割り当て、進捗を監視し、結果に応じて計画を修正する認知的なオーケストレーターです。一般的なAIチャットが「質問に答える」ものだとすれば、Discovery Engineは「研究タスクを継続的に進める」ための仕組みです。(Microsoft Learn)
たとえば、材料研究で「候補物質を探索し、性能・安全性・コスト・製造容易性を比較したい」という目的を設定すると、文献調査、既存データの参照、シミュレーション、結果の要約、次に検証すべき候補の提示といった工程を、複数のエージェントやツールを使って進めるイメージです。
影響範囲：誰が確認すべきか
Microsoft Discoveryの一般提供は、すべてのAzure利用者に即時の設定変更を求めるものではありません。影響が大きいのは、R&D部門、AI基盤担当、Azure管理者、データ基盤担当、セキュリティ担当です。
| 立場 | 確認すべきこと |
|---|---|
| Azure管理者 | 利用可能リージョン、サブスクリプション有効化、リソースプロバイダー、RBAC、VNet、Private Link、課金 |
| AI/MLエンジニア | チャットモデルデプロイ、エージェント設計、ツール実行、Microsoft Foundryとの使い分け |
| R&D部門 | どの研究テーマをエージェント化するか、検証基準をどう定義するか |
| セキュリティ担当 | 機密データ、知財、監査ログ、CMK、ネットワーク分離、データ持ち出しリスク |
| 開発者 | コンテナ化されたツール、Azure Container Registry、ストレージ入出力、API利用 |
| 経営・事業責任者 | PoCから本番展開へ進む判断基準、費用対効果、研究成果の再現性 |
通常のWebアプリや業務システムには直接影響しません。また、既存のAzure OpenAI Serviceのアプリが自動的にMicrosoft Discoveryへ移行されるわけでもありません。Microsoft Discoveryは、ワークスペース、プロジェクト、エージェント、Bookshelf、Supercomputerなどを持つ別のAzureリソース体系として導入・管理します。(Microsoft Learn)
管理者が最初に確認すべきAzure設定
サブスクリプションがMicrosoft Discoveryに対応しているか
公式クイックスタートでは、Microsoft Discoveryアクセスが有効化されたAzureサブスクリプションが前提条件とされています。また、Bicepによるデプロイドキュメントでは、サブスクリプションがMicrosoft Discoveryチームによって許可リスト登録されている必要があると説明されています。(Microsoft Learn)
そのため、まず確認すべきことは「自社テナントでAzureポータルからすぐ作れるか」ではなく、次の3点です。
- 利用予定サブスクリプションでMicrosoft Discoveryが有効化されているか
- Microsoft.Discoveryリソースプロバイダーを登録できる権限があるか
- Microsoftアカウント担当者経由の利用申請が必要か
対応リージョンとクォータを確認する
公式ドキュメントでは、Microsoft Discoveryリソースの本番リージョンとしてEast US、Sweden Central、UK Southが示されています。単一デプロイでは、同じリージョン、同じサブスクリプション、同じリソースグループにまとめることが推奨されています。(Microsoft Learn)
日本リージョンでの利用を前提に設計している組織は注意が必要です。データ所在地、社内規程、越境移転、ネットワーク遅延、社内監査の要件を確認してからPoCを始めましょう。対応リージョンは将来拡張される可能性があるため、導入時点の公式ドキュメントで再確認してください。
必要なリソースプロバイダーを登録する
Microsoft Discoveryでは、Microsoft.Discoveryだけでなく、ネットワーク、ストレージ、マネージドID、コンテナ、Key Vault、Cognitive Services、検索など複数のAzureリソースプロバイダーが関係します。公式クイックスタートでは、Microsoft.Network、Microsoft.Storage、Microsoft.ManagedIdentity、Microsoft.CognitiveServices、Microsoft.ContainerRegistry、Microsoft.ContainerService、Microsoft.KeyVault、Microsoft.Search、Microsoft.Bingなどの登録確認が求められています。(Microsoft Learn)
本番用サブスクリプションで直接試すより、まず検証用サブスクリプションを用意し、必要なプロバイダー登録、Azure Policy、RBACの影響を確認するのが安全です。
ネットワーク設計で失敗しやすいポイント
Microsoft Discoveryは、研究データや知財を扱う前提のサービスです。そのため、ネットワーク設計を後回しにすると、PoCから本番移行する段階で作り直しになる可能性があります。
公式ドキュメントでは、Microsoft Discoveryはネットワークセキュリティとして、Network Security Perimeterによるネットワーク強化と、Private LinkによるデータプレーンAPI向けプライベートエンドポイントを提供すると説明されています。2026-02-01-preview以降のAPIバージョンで管理されるワークスペースとBookshelfでは、ネットワーク強化が既定で有効です。(Microsoft Learn)
VNetとサブネットは最初に設計する
クイックスタートでは、Supercomputer、AKS、Workspace、Private Endpoint、Agent、Search向けに複数のサブネットを用意する構成が示されています。さらに、1つの仮想ネットワークは1つのMicrosoft Discoveryワークスペースにのみ関連付けられるため、複数ワークスペースを作る場合はワークスペースごとにVNetとサブネットを分ける必要があります。(Microsoft Learn)
開発部門ごとに自由にワークスペースを作らせると、アドレス空間やサブネット設計が破綻しやすくなります。最初に「事業部ごと」「研究領域ごと」「機密度ごと」のどの単位でワークスペースを分けるかを決めてください。
Private Endpointを使う場合の注意点
Private Endpointを構成すると、ワークスペースやBookshelfのデータプレーンAPIへの通信をAzureバックボーン内に閉じることができます。publicNetworkAccessを無効にすれば、プライベートエンドポイント経由以外のアクセスは拒否されます。(Microsoft Learn)
ただし、制限もあります。クロスリージョンのPrivate Endpointはサポートされず、Private EndpointはDiscoveryリソースと同じリージョンに置く必要があります。また、ワークスペース、Bookshelf、Supercomputerごとに一意で重複しないサブネットが必要です。さらに、SupercomputerのAKS APIサーバーは公開FQDNを持ち、プライベートクラスター対応は将来リリース予定とされています。(Microsoft Learn)
ID、RBAC、マネージドIDの確認項目
Microsoft Discoveryでは、Azure RBACとマネージドIDの設計が重要です。公式クイックスタートでは、Platform Admin、Scientist、Engineerなどのユーザーに対するロール割り当てに加え、User Assigned Managed Identity（UAMI）へ必要な権限を付与する流れが示されています。(Microsoft Learn)
管理者は、少なくとも次を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 管理者権限 | Owner、RBAC Administrator、User Access Administratorなど、ロール割り当て可能な権限を持つ担当者を明確にする |
| ユーザー権限 | Microsoft Discovery Platform Administrator、Foundry User、Storage Blob Data Contributorなどを最小権限で割り当てる |
| UAMI | Supercomputer、Workspace、Storageアクセスに使うUAMIを分離するか、検証用に単一化するかを決める |
| Managed Resource Group | Workspace作成後に自動生成される管理リソースグループへのFoundry Userロール割り当てを忘れない |
| 監査 | 誰がエージェント、ツール、モデル、ストレージへアクセスできるかを棚卸しする |
PoCでは権限を広めに付けがちですが、R&Dデータは知財に直結します。研究者の利便性だけでなく、データ閲覧、ツール実行、モデル利用、出力ファイル取得の境界を分けて設計しましょう。
ストレージとデータ管理で見るべきポイント
Microsoft Discoveryでは、エージェントやツールが生成したファイル、ディレクトリ、データセットを「リソース」として管理します。会話内で生成されたリソースは、discovery://resources/...形式の安定したURIで参照され、基盤側がAzure Storageとの対応を管理します。(Microsoft Learn)
重要なのは、ツールが出力した中間ファイルが自動的にユーザーにすべて表示されるわけではない点です。エージェントが明示的に共有したリソースだけがDiscovery Studio上で見えるようになります。これにより中間計算結果の混在を防げますが、逆に言えば、必要な成果物を共有するようエージェント設計やツール設計に入れておかないと、利用者が結果を確認できません。(Microsoft Learn)
Blob StorageとCORS設定を忘れない
公式クイックスタートでは、調査の入力・出力データを保存するAzure Blob Storageを作成し、discoveryoutputsコンテナーを用意する手順が示されています。また、Discovery StudioやVS Code連携のために、https://studio.discovery.microsoft.com、https://vscode.dev、https://*.vscode-cdn.netをCORSの許可オリジンに設定する必要があります。 (Microsoft Learn)
検証時にありがちな失敗は、「エージェントは動いたが、出力ファイルをブラウザから取得できない」というケースです。これはストレージのファイアウォール、クライアントIP許可、Private Link、CORS設定のどこかが不足していることが多いため、最初の環境構築時に出力ファイルの表示・ダウンロードまで確認しておきましょう。
BookshelfとKnowledge Baseの扱い方
Microsoft DiscoveryのBookshelfは、顧客データをKnowledge Baseに変換し、エージェントの推論根拠として使うための機能です。Knowledge Baseには、ベクターデータベースと知識グラフが含まれます。公式ドキュメントでは、ASIC設計チームが仕様書、シミュレーション結果、関連文献をKnowledge Base化し、設計ワークフローの推論を根拠付ける例が示されています。(Microsoft Learn)
ただし、Bookshelfは万能検索基盤ではありません。大量の社内文書から関連資料を探す用途には、Azure AI SearchやSharePoint Searchなどの汎用検索を使い、Microsoft Discoveryにはテーマが絞られた、直接ワークフローに関係するデータを取り込む方が現実的です。(Microsoft Learn)
Bookshelf利用時の注意点
| 注意点 | 実務上の対応 |
|---|---|
| 暗号化、パスワード保護、秘密度ラベル付きファイルはインデックス対象外 | 取り込み前に対象ファイルの状態を確認する |
| 1つのBookshelfに作成できるKnowledge Baseは現時点で1つ | 研究テーマごとにBookshelfを分ける設計を検討する |
| 増分インデックスは現時点で未対応 | 更新頻度の高いデータは再インデックス手順とコストを見積もる |
| 大規模データはコストと時間が増える | SmallまたはMediumサイズから始める |
| テーマが広すぎるKBは精度が落ちやすい | 研究目的、対象物質、製品ライン、実験条件などで範囲を絞る |
Bookshelfは「社内文書を全部入れる場所」ではなく、「この研究判断に必要な根拠を整理して入れる場所」と考えると失敗しにくくなります。
Discovery Engineを使うべき場面と使わない場面
Discovery Engineは、長時間・多段階・複数ツールを伴う研究開発タスクに向いています。公式ドキュメントでは、複数ステップ、依存関係、オープンエンドな探索、長時間実行、複数ツールや複数知識領域の調整が必要な問題に適していると説明されています。(Microsoft Learn)
逆に、単発の質問、即時回答が必要な確認、単純な検索や計算には向きません。すべてをDiscovery Engineへ渡すと、かえって遅くなります。
向いているタスクの例
- 候補材料を複数条件で探索し、シミュレーションと文献根拠を突き合わせる
- 創薬候補の活性、結合性、副作用リスク、合成経路を段階的に検討する
- 製造条件の最適化案を複数の実験データから絞り込む
- 研究テーマごとに専門エージェントを分けて、結果を統合する
向いていないタスクの例
- 既知の物性値を1つ調べる
- 研究メモを短く要約する
- 単純な表計算を実行する
- 人間がすべての手順を逐次制御したい作業
Discovery Engineで重要なのは、タスクごとに「成功条件」を書くことです。公式ドキュメントでも、各タスクにはタイトル、説明、少なくとも1つの検証要件が必要であり、検証要件がないと結果を客観的に評価できないとされています。(Microsoft Learn)
開発者が確認すべきエージェントとツールの設計
Microsoft Discoveryのエージェントは、Microsoft Foundry Agent Serviceを土台にしつつ、研究開発向けの推論ループ、エージェントチーム、研究ツール、Knowledge Baseを扱えるよう拡張されています。エージェントはDiscovery Studioで作成・管理し、自然言語の指示によって振る舞いを定義できます。(Microsoft Learn)
開発者にとって重要なのは、エージェントだけで完結させようとしないことです。シミュレーション、データ処理、専門ソフトウェア実行などは、コンテナ化されたツールとして定義し、Supercomputer上で実行する設計になります。Microsoft Discoveryのアーキテクチャでは、ToolはAzure Container Registryに保存され、Supercomputerによって実行されます。(Microsoft Learn)
エージェント設計の実務チェック
| 項目 | チェック内容 |
|---|---|
| 目的 | 「何を調べるか」ではなく「どの判断を支援するか」を書く |
| 成功条件 | 精度、対象範囲、除外条件、根拠提示、出力形式を明確にする |
| モデル | ワークスペースレベルのチャットモデルデプロイを用意する |
| ツール | 研究ソフト、シミュレーション、解析コードをコンテナ化できるか確認する |
| 入出力 | 出力ファイルをStorage Assetとして共有する流れを設計する |
| 監査性 | どのデータを参照し、どの結果を根拠にしたか残せるようにする |
プレビュー時代の検証資産がある場合は、Agent V2とDiscovery Engineへの見直しが必要になる可能性があります。公式ドキュメントでは、Discovery Agent V2が従来設計から再設計され、固定的なワークフローではなく、Discovery Engineによる動的なマルチエージェントオーケストレーションを使う方向が示されています。静的なWorkflow agentsは非推奨とされています。(Microsoft Learn)
Microsoft Discovery appからクラウド版へ移行する判断基準
Microsoft Discovery appは、ローカル環境で素早く試せる入口です。公式比較では、Microsoft Discovery appは個人や科学コミュニティ向けのローカル実行、Microsoft Discoveryは本番グレードで統制されたR&D向けのクラウド展開と整理されています。(Microsoft Learn)
appで始めてよいケース
- 個人研究や学習でエージェント型R&Dを試したい
- 公開文献やローカルファイルだけでPoCしたい
- Azure環境の準備前に、研究部門がユースケースを具体化したい
- GitHub Copilotアカウントで小さく検証したい
クラウド版へ進むべきケース
- 複数人で同じ研究プロジェクトを扱う
- 機密データ、知財、規制対象データを扱う
- Azure HPCやGPUなど大規模計算が必要
- アクセス制御、監査、SLA、企業サポートが必要
- R&Dの成果を組織知として蓄積したい
公式ドキュメントでは、appで作成したエージェントや知識をクラウド版へ持ち上げる考え方が示されています。ただし、自動移行ツールはまだなく、エージェント定義、プロンプト、ローカルKnowledge Baseの内容を再利用・インポートする形になります。(Microsoft Learn)
課金とコスト管理で注意すべきこと
Microsoft Discoveryの課金は、Azureホスト型サービスとローカルappで異なります。公式ドキュメントでは、Discovery appは追加のプラットフォーム料金を持たず、GitHub Copilotサブスクリプションの利用に依存すると説明されています。一方、Azureホスト型のMicrosoft Discovery servicesは、Azureリソース消費と、エージェント実行に伴うメッセージベース課金の二段構成です。(Microsoft Learn)
Azureホスト型では、次の費用を分けて見積もる必要があります。
| 費用項目 | 内容 |
|---|---|
| Azureリソース費用 | Compute、Storage、Container Registry、Key Vault、Search、ネットワークなど |
| モデル利用費 | ワークスペースにデプロイしたチャットモデル、Azure OpenAIまたはFoundry関連の利用 |
| Microsoft Discovery runtime | エージェント実行や作成・更新・削除・キャンセルなどのUser Message課金 |
| データ転送・ストレージ | 出力ファイル、ログ、Bookshelfインデックス、Blob Storage利用 |
| 運用費 | 監査、セキュリティレビュー、データ管理、モデル評価、PoC運用工数 |
公式ドキュメントでは、Create、Update、Delete、Run、Submit、Cancelなどの操作が課金対象になり、GET、一覧取得、ステータス確認、ログ取得などの読み取り系操作は課金されないと説明されています。例示として、1 User Messageあたり0.20米ドルが示されていますが、実際の価格はリージョンや契約、通貨によって変わる可能性があるため、Azure Cost Managementで対象リソースをフィルタリングして確認してください。(Microsoft Learn)
セキュリティと暗号化で確認すべきこと
研究開発データは、公開前の発明、試験結果、製造条件、薬剤候補、顧客固有データなどを含む可能性があります。そのため、Microsoft Discoveryの導入では、通常のアプリ開発以上にデータ保護を重視する必要があります。
Customer-managed keys（CMK）を使う場合、公式ドキュメントではBookshelf、Supercomputer、Workspaceが対象リソースとして示されています。ただし、CMKは作成時設定であり、リソース作成後にMicrosoft-managed keysとCMKを切り替えることはできません。(Microsoft Learn)
CMKを使う場合の注意点
- Key VaultはMicrosoft Discoveryリソースと同じリージョンに置く
- Soft deleteとPurge protectionを有効化する
- Azure RBACによるアクセス制御を使う
- RSA 2048、3072、4096のキーサイズ要件を確認する
- キーローテーション時は、Microsoft Discoveryリソース側で新しいキー バージョンを参照する必要がある
- CMK対応リソースではLog Analytics専用クラスターの要件も確認する
後から暗号化方式を変えられない設定は、PoCでは見落とされがちです。本番利用が視野にあるなら、最初の検証環境からCMK要件を確認しておく方が安全です。
導入前チェックリスト
Microsoft Discoveryを試す前に、次の順番で確認すると手戻りを減らせます。
| 順番 | 確認項目 | 完了条件 |
|---|---|---|
| 1 | ユースケース定義 | 研究テーマ、利用データ、期待する判断、成功条件が明文化されている |
| 2 | 利用形態の選択 | appでPoCするか、Azureホスト型で検証するか決まっている |
| 3 | サブスクリプション | Microsoft Discovery利用が有効化され、必要なリソースプロバイダーを登録できる |
| 4 | リージョン | 対応リージョン、データ所在地、社内規程に問題がない |
| 5 | RBAC | 管理者、研究者、開発者、UAMIの権限が分離されている |
| 6 | ネットワーク | VNet、サブネット、Private Endpoint、NSG、DNS、クライアントアクセスが設計済み |
| 7 | ストレージ | Blob Storage、CORS、出力コンテナー、アクセス経路が確認済み |
| 8 | モデル | 必要なチャットモデルデプロイとクォータを確認済み |
| 9 | Bookshelf | 取り込むデータ範囲、ファイル形式、再インデックス方針が決まっている |
| 10 | 課金 | Azureリソース費用、User Message、モデル利用、検証期間の上限を設定済み |
| 11 | セキュリティ | CMK、監査、機密データ、利用禁止データ、出力レビューの方針がある |
| 12 | 移行判断 | appやPoCからクラウド本番へ進む基準が決まっている |
まずは小さなPoCから始めるのが現実的
Microsoft Discoveryの一般提供は、Azure上でエージェント型R&Dを本格的に進める組織にとって大きな更新です。特に、科学文献、社内データ、シミュレーション、専門ツール、HPCを組み合わせて、研究開発の仮説生成から検証までを繰り返す組織には有力な選択肢になります。
一方で、導入にはAzure管理の設計が必要です。サブスクリプション、対応リージョン、RBAC、VNet、Private Endpoint、Blob Storage、Bookshelf、モデルデプロイ、課金を確認しないまま始めると、PoCの成果を本番へ移せない可能性があります。
次に取るべき行動は明確です。まず、研究部門とIT部門で1つの具体的なユースケースを選び、Microsoft Discovery appで小さく検証するか、Azure上に検証用サブスクリプションを用意して最小構成を作るかを決めましょう。そのうえで、成功条件、扱うデータ、必要なツール、出力形式、コスト上限を定義してから、Microsoft Discoveryの本格導入を判断するのが安全です。
コメント