Microsoft Discoveryとは？研究開発向けエージェント型AIプラットフォームを徹底解説

Microsoft Discoveryは、Microsoftが2026年6月2日のBuild 2026で一般提供を開始した、研究開発（R&D）向けのエージェント型AIプラットフォームです。

化学・材料科学・生命科学・半導体・エネルギーといった分野で、文献調査から仮説生成・インシリコ実験・ラボ自動化までを一気通貫で支援する設計になっており、自社の量子チップ「Majorana 2」開発でも実運用されています。

本記事では、Discovery Engineと知識基盤の中核アーキテクチャ、Microsoft Discovery appとの使い分け、Majorana 2・Insilico Medicine・Yale Engineeringなど公式事例、料金体系、Google Co-Scientist・NVIDIA BioNeMoとの違い、そしてエンタープライズ導入で押さえるべき判断軸までを、2026年6月時点の最新情報で体系的に解説します。

Microsoft Discoveryとは？Build 2026でGAした研究開発向けエージェント型AIプラットフォーム

Microsoft Discoveryは、Microsoftが2026年6月2日のBuild 2026で一般提供（GA）を開始した、研究開発（R&D）向けのエンタープライズ・エージェント型AIプラットフォームです。

Discoveryが既存の汎用AIアシスタントと根本的に違うのは、文献調査・仮説生成・インシリコ実験・ラボロボティクスまで、科学的手法のループ全体をエージェント群が連携して回すという設計思想にあります。

研究の単発タスクをAIで効率化するのではなく、化学・材料科学・生命科学・半導体・エネルギーといったR&D業務の運用基盤そのものを、Microsoft 365・Microsoft Fabric・Microsoft Foundryと相互運用しながらエージェント化することが目的です。

従来の研究ツールとの違い——分断ステップから統合ループへ

以下の表で、Discoveryが対象とする領域と従来の研究ツールが対象としてきた領域の違いを整理しました。

観点	従来の研究ツール	Microsoft Discovery
主目的	個別ステップの効率化（文献検索／シミュレーション／実験計画）	文献〜仮説〜実験〜分析のループ全体をエージェント連携で回す
データ統合	ツール単位で分断	グラフベースの知識基盤で外部文献と社内データを横断
計算リソース	オンプレ／クラウドを別運用	Azure HPC・GPU・専用ハードを統合
知識の蓄積	プロジェクト終了で散逸しがち	長期メモリのナレッジグラフに資産として残る
エンタープライズ統合	別途インテグレーションが必要	M365・Foundry・Fabricと相互運用前提

こうして並べてみると、Discoveryが「既存R&D環境の上で、探索・実験・分析のワークフローをエージェントで統合する基盤」として設計されていることが見えてきます。

汎用CopilotやChatGPTのように個人タスクを補助するのではなく、研究組織のワークフロー全体に踏み込む製品です。

---

Microsoft Discoveryの中核——Discovery Engineと知識基盤

Microsoft Discoveryの設計を理解する上で最も重要なのが、中核に置かれた「Discovery Engine（探索エンジン）」と、それを支えるグラフベースの知識基盤です。

ここからは、Discoveryが「単なるエージェント実行環境」ではなく「科学的手法を模倣する推論エンジン」だと位置づけられる理由を、構成要素ごとに整理します。

Discovery Engineが模倣するのは「科学的手法のループ」

Discovery Engineは、Microsoftが「コグニティブ・オーケストレーター」と呼ぶ中核コンポーネントです。

公式ドキュメントによれば、Discovery Engineの役割は特化したエージェント群が大量の知識から推論し、仮説を生成し、広大な検索空間で複雑な仮説ツリーを検証する科学的手法を模倣することにあります。

Discovery Engineが回す科学的手法ループ（出典：Microsoft Azure Blog）

上記の全体像は、Scientific reasoning（古典的シミュレーション＝HPCで実行）→ Hypotheses generation（特化AIモデルで推論）→ Experimentation & Analysis（インシリコ・物理ラボで検証、QuantumとRoboticsを併用）という三段階のループです。

さらに右下のRoboticsから得た実験データはLab automationを経て次のループにフィードバックされ、Quantumで得たデータはAIの学習データとして循環します。

このループ構造を踏まえると、Discoveryが回す処理は次の4ステップに整理できます。

• エビデンス収集
  社内研究データ・特許・公開文献・実験記録を横断検索し、テーマに関連する事実を集約する
  
  

• 仮説生成
  集めたエビデンスから、検証可能な仮説を複数生成する。競合する理論があれば並列で扱う
  
  

• 実験・シミュレーション実行
  インシリコ実験（計算機上のシミュレーション）・物理ラボとの連携・LQMによる定量予測を組み合わせて検証する
  
  

• 結果分析と次のループへの反映
  得られた結果をナレッジグラフに書き戻し、次の仮説生成の起点にする
  
  

この一連のループが、研究者が現場で日常的に回している思考プロセスをそのまま自動化したものになっています。

汎用LLMが「単一の問いに対する単一の応答」を返すのとは異なり、Discovery Engineは仮説と反証の繰り返しを前提に組まれているのが本質的な違いです。

グラフベース知識基盤——独自データと外部文献を結び付ける

Discovery Engineのもう一つの柱が、グラフベースの知識基盤です。

通常のRAG（Retrieval-Augmented Generation）が文書チャンクをベクトル化して類似検索するのに対し、Discoveryの知識基盤は分子・反応経路・遺伝子・材料特性・実験条件といった科学的エンティティをノードとして表現し、関係性をエッジで結ぶ設計になっています。

公式ドキュメントは、この基盤の特徴を「競合する理論、実験結果、ドメイン固有の仮定の間で推論できる」と説明しています。同じ分子でも論文Aと論文Bで異なる挙動が報告されている場合、AIは両方を並列に保持して評価することができます。

加えて、探索エンジンの結果は長期メモリのナレッジグラフに保存されるため、過去の検証履歴が次の研究プロジェクトでも再利用されます。

研究員が異動しても暗黙知が組織に残る、というR&D部門にとって最も解決したかった課題に踏み込んだ設計です。

LQM・HPC・量子コンピューティングとの統合

Discovery Engineの推論を実際の計算に落とすレイヤーとして、Microsoftは大規模定量モデル（LQM：Large Quantitative Model）・HPC（高性能計算）クラスター・将来の量子コンピューティングとの統合を公式に明言しています。

LQMは、汎用LLMが言語の確率分布を扱うのに対し、数式・時系列・物理シミュレーションといった定量データを直接扱える生成AIの一種です。創薬・材料・電池・金融リスクなど、数値が支配的なドメインで威力を発揮します。

以下の表で、Discoveryのエージェントが利用できる計算リソースを整理しました。

計算リソース	役割	代表的なユースケース
LQM（大規模定量モデル）	定量データの推論・予測	分子物性の予測・反応収率の見積もり
HPCクラスター	大規模並列計算	分子動力学シミュレーション・CFD（流体解析）
GPU / 専用アクセラレータ	深層学習・推論	分子生成モデル・材料探索
物理ラボ統合	実験装置・ロボットの遠隔操作	ハイスループット実験・サンプリング
量子コンピューティング（将来統合）	古典計算では非効率な領域の探索	量子化学計算・組合せ最適化

注目すべきは、量子コンピューティングまで将来統合のロードマップに含まれていることです。

Microsoft自身がMajorana 2というトポロジカル量子チップを開発しており、Discoveryと量子チップの両輪で「古典計算では届かないR&D課題」に挑む構想を明示しています。

ガバナンス・拡張性——R&D特有の機密データに対応

エンタープライズ向け製品としてDiscoveryに組み込まれているのが、エージェント主導の調査が戦略的優先順位・セキュリティ・コンプライアンスから逸脱しないようにする統制機構です。

公式ドキュメントでは、中央集権的なエージェント管理、監査証跡、チェックポイントを提供すると説明されいます。これは、R&D部門が抱える「未公開の特許情報や合成経路を外部に漏らさずにAIに使わせたい」という強い要請に対応した設計です。

加えて、既存ビジネスツール・パートナーソリューション・オープンソースモデルとの統合を前提に作られており、特定ベンダーへのロックインを避けつつ拡張できる点も訴求されています。

Discoveryが掲げる3つの設計原則（出典：Microsoft Azure Blog）

Microsoftは、これまで述べてきたDiscovery Engine・知識基盤・LQM・ガバナンスの設計を**「Empower AI Agents（エージェントの能力解放）」「Automate discovery loop（探索ループの自動化）」「Scale quality（品質のスケール）」**という3原則に整理しています。

「エージェントの知能で頭打ちにせず実験と結果からの学習に拡張すること」「企業固有のIPと人材を活かしながら継続的に知識を蓄積すること」「エンドツーエンドの統制と説明可能性で目標達成率を最大化すること」の三つが、これまで紹介した個別機能の背後にある共通の設計指針です。

---

Microsoft Discoveryで支援される6つの研究シナリオ

ここからは、Microsoftが公式に「Discoveryで支援できる主要シナリオ」として整理している6つの研究ユースケースを順に見ていきます。

公式ドキュメントのKey Scenariosに明示された6カテゴリを、日本語化して整理したものです。

知識・文献の探索（Knowledge & Literature Discovery）

最も基礎的なシナリオが、社内研究データ・特許・論文・実験記録を横断するセマンティック検索とグラフベース検索です。

通常の社内ナレッジ検索と違うのは、論文・特許・社内レポートを単一のグラフ構造で結びつけ、学際的な接続点をAIが提示してくれる点にあります。

公式は「文献レビューを数週間から数分に短縮できる」と説明しており、ターゲット化合物の既往研究調査や、新素材の特許マッピングといった研究の入り口で時間を奪われていた工程を大きく削減する効果を見込んでいます。

仮説と実験設計（Hypothesis & Experiment Design）

研究者が自然言語で研究目標を記述すると、Discoveryが仮説を提案し、多段階の実験計画や研究計画を構造化して返すシナリオです。

Discoveryのタスク作成フォームと実行ステータス（p53 Cancer Vaccine Analysisの例）（出典：Microsoft Azure Blog）

左側のフォームでは研究テーマ・共有セッション・記述・Validation Criteria・担当エージェント・優先度・依存タスクを構造化して入力でき、右側のパネルではDiscovery Engineが「p53 Cancer Vaccine Analysis」のような実テーマに対してPhase 4〜7のサブタスクをblastAgent・iedbAgent・evodiffAgent・sciencegpt5Agent等の特化エージェントに割り振り、Status Overviewで完了率（例ではTotal Tasks 7のうち完了4・要確認3）まで一覧化しています。

「次にどの分子修飾を試すか」「シミュレーションの後にどのラボ実験をかけるか」といった意思決定をAIが補助します。

このシナリオの実務的な価値は、人間の直感を超えた探索範囲を試せる点にあります。研究者が無意識に避けていたアプローチも、AIが選択肢として並べてくれるため、低価値・冗長な実験を減らす効果が期待できます。

インシリコ・スクリーニングと最適化

候補分子・材料・設計を物理ベースモデルとAIモデルで大規模に評価し、物理試験の前に有望なものに絞り込むシナリオです。

数千の候補を仮想スクリーニングしたり、異なる条件下での材料性能をシミュレーションしたり、エンジニアリング設計をパラメータスイープで最適化したりといった用途が想定されています。

このシナリオは、後述するMicrosoft自身の**データセンター冷却液開発の事例（約200時間で非PFAS浸漬冷却液プロトタイプを特定）**で代表的に示された使い方です。

結果分析とインサイト生成

実験やシミュレーション後の多次元データを自動分析し、相関・異常値・主要ドライバーを特定し、自然言語で説明するシナリオです。

以下の画面では、Discoveryが整理した「Confidence Summary Table」が左に並び、各findingに対してHIGH/MODERATE/SPECULATIVEの確度ラベル・キー証拠・注意点が一覧化されています。右側ではATRA・ATOによる急性前骨髄球性白血病（APL）への分化誘導など、ナレッジベース由来の根拠リンクとともに詳細所見が出力され、画面下部には「AI-generated content may be incorrect」の注意書きが固定表示されます。

「なぜ特定の化合物だけが性能を発揮したか」「シミュレーションのどこに異常があるか」を、AIがレポート形式で返してくれます。

Leukemia ResearchワークスペースでのConfidence Summary Tableと詳細findings（出典：Microsoft Azure Blog）

ここで重要なのは、結果分析の出力が単発のレポートで終わらず、ナレッジグラフに書き戻されて次の仮説生成に使われる点です。組織の研究知が時間経過とともに自動で蓄積されていく仕組みになっています。

ラボ自動化とロボティクス・ワークフロー

自動化されたラボやロボットと連携し、実験プロトコルの生成・実行指示・結果取り込みまで閉じたループを回すシナリオです。

ハイスループット化学・生物実験、自動材料試験環境、パイロット規模プロセス最適化といった、すでにラボオートメーション基盤を持つ組織で効果が出やすい領域です。

公式ドキュメントは「人間の監督下でclosed-loop実験を実現する」と明記しており、AIが暴走しないようヒューマン・イン・ザ・ループを前提とした設計になっています。

共有ナレッジワークスペース

最後のシナリオが、データ・結果・文書・議論を一つの基盤で結びつける研究組織向けのワークスペース機能です。

プロジェクトを跨いだ知識グラフ、チーム横断・分野横断のコラボレーション、Microsoft 365との連携といった機能が含まれます。

研究員のオンボーディング短縮、組織を超えた知見共有、研究の連続性確保といった、R&D部門の運営課題に直接対応する位置付けです。

これら6シナリオは独立しているわけではなく、Discovery Engineを通じて連動します。文献調査で見つけた事実が仮説生成に使われ、仮説が実験計画に落ち、実験結果が再びナレッジグラフに戻る——というループ全体がDiscoveryの本来の使い方です。

---

Microsoft DiscoveryとMicrosoft Discovery appの使い分け

Microsoft Discoveryは2つの補完的なエクスペリエンスで提供されています。エンタープライズ向けクラウドサービスの「Microsoft Discovery」と、ローカルで動くデスクトップアプリの「Microsoft Discovery app」です。

両者は同じコア概念（エージェントフレームワーク、Bookshelf、Discovery Engine）を共有しており、APIも共通です。一方で展開規模・データ統合・ガバナンス・コラボレーションに明確な差があります。

2形態の機能差を一覧で整理

以下の表で、Microsoft DiscoveryとMicrosoft Discovery appの主な違いを公式ドキュメントベースで整理しました。

観点	Microsoft Discovery（クラウド版）	Microsoft Discovery app（ローカル版）
提供状態	一般提供（GA）	プレビュー
サポート	Microsoftエンタープライズサポート契約・SLAあり	GitHub経由のコミュニティサポート
セットアップ	Azureサブスクリプション・エンタープライズクラウドリソースが必要	Windows向けにダウンロード、有効なGitHub Copilotサブスクリプション（または互換ライセンス）が必要
計算リソース	Azure HPC・GPU・専用ハードのスケーラブルクラスター	ローカルマシンのCPU・GPU
コラボレーション	マルチユーザー対応、プロジェクト・エージェント・データをワークスペース内で共有	シングルユーザー、1台に1サインインまで
データ統合	プライベートデータ・エンタープライズクラウドデータの両方を活用	ローカルファイルと公開リソースのみ、企業データとの直結なし
セキュリティ	エンタープライズセキュリティ・コンプライアンス基準に準拠	ローカルOSセキュリティ、Responsible AI上限の固定セーフガード
コスト	User Messages単位の実行課金＋Azure基盤リソース従量課金	無料DL、GitHub Copilotクレジットを消費
想定用途	本番R&D・大規模計算・高度ガバナンスの公式運用	個人・小規模での探索、PoC、教育用途

この比較から見えるのは、両者が**「同じ製品の異なる入口」として設計されている**点です。エンタープライズ版だけだとIT部門の合意形成や予算策定に時間がかかってしまうため、ボトムアップで現場研究員が試せる小さなドアを別途用意した、というのがMicrosoftの戦略になっています。

Biosciences Workspace内のMolecule Projectの起点画面（出典：Microsoft Azure Blog）

サイドバーには「Molecule Project」「Biosciences Workspace」というワークスペース構造と、Github Copilot chat・New shared session・New task・Resourcesといった操作メニューが並びます。

中央の「What would you like to discover today?」プロンプト入力欄からタスクを始め、下部には「Run literature review of top candidates for molecules」のような直近セッションが残る設計です。

両形態とも同じVSCodeベースのUIを採用しているため、Discovery appで操作を覚えた研究員はクラウド版に移っても操作体系をそのまま引き継げます。

Discovery appからクラウド版への移行シナリオ

公式ドキュメントは、appからクラウド版に移行すべき条件を明確に示しています。

• コラボレーション
  複数メンバーで共同調査する、チーム共有・アクセス制御・IT統制が必要になった場合
  
  

• 計算
  ローカルマシンでは捌けない大規模シミュレーション、数百万データポイントの推論、大規模知識ベースの推論が必要になった場合
  
  

• コンプライアンス
  機密・特許データを扱う、Azureテナンシーにデータを留める必要がある、医療・金融など規制業界で監査が必要な場合
  
  

ここで重要なのは、appで作ったエージェントやスキルはクラウド版に移植可能な点です。公式は「自動マイグレーションツールはまだないが、エージェント定義・プロンプト・ローカルナレッジベースを再利用してクラウド版にインポートできる」と明示しています。

つまり、個人研究者がappでプロトタイプを作り、価値が見えた段階でチームをエンタープライズ版に移行する段階的アップグレードが公式に推奨されたシナリオになっています。

利用開始時の選び方

最初にどちらを選ぶかは、組織の状況で決めるのが現実的です。

• 個人研究者・学生・大学のラボなら、まずMicrosoft Discovery app
  GitHubアカウントと有効なGitHub Copilotサブスクリプション（または互換ライセンス）だけで起動できるため、Azureサブスクリプションがない環境でも数分で試せる
  
  

• 企業のR&D部門で本番運用を見据えるなら、最初からMicrosoft Discovery（クラウド版）
  Microsoftアカウント担当者にコンタクトを取り、PoC計画とAzureサブスクリプションを整える前提で始める
  
  

• PoCを社内で進めたいが本格契約には踏み切れない場合は、appで価値検証してからクラウド版へ卒業
  appで現場の研究員に試してもらい、ROIが見えた段階でIT部門・経営層への提案材料にする
  
  

両形態の根本にある思想は「個人の好奇心から組織の本番運用まで、同じ製品ファミリで連続的にカバーする」という点に集約されます。

---

Microsoft Discoveryの公式導入事例

GA時点でMicrosoftが公開している導入事例は、自社案件と外部研究機関・企業の事例が混在しています。本セクションでは特に公式情報が充実している5事例を整理します。

Majorana 2量子チップ——Microsoft自身のドッグフーディング

最大の事例は、Microsoft自身が次世代トポロジカル量子チップ「Majorana 2」の開発にDiscoveryを活用したケースです。

公開された実物写真では、金色の基板パッケージの中央にMicrosoft刻印のついた小さなチップダイが収まり、その周囲を緻密なワイヤーボンディングが取り囲んでいます。Majorana 2は、前世代のqubitに比べて信頼性が1,000倍向上し、qubitの平均寿命が20秒・最大1分に達した量子チップとして、Build 2026で同時発表されました。

Majorana 2量子チップ（出典：Microsoft Source）

Discoveryのエージェントは、Majorana 2開発において次のような役割を果たしたとされています。

• 製造ワークフローの管理と自動化
• 測定プロセスの自動化
• 材料スタックの最適化
• 過去のqubit製造工程で見逃されていた欠陥の特定
• ほぼ20年分の実験データ（多様な形式で散在）を横断したパターン相関分析

特に最後の「20年分のデータ相関分析」は、Discoveryの長期メモリ・ナレッジグラフ機能が実証された代表的なユースケースです。Microsoftほどの規模の研究組織でも、過去データの活用は人手では難しかったという事実が裏付けられています。

Microsoftの量子チップ研究ラボ（出典：Microsoft Source）

クリーンスーツを着用した研究者が複数モニターで測定データを追う研究現場の様子から、Majorana 2の開発が「物理ラボの精密実験」と「Discoveryによるデータ統合・自動化」の両輪で進められていることが見て取れます。

チップ設計そのものはハードウェアエンジニアの専門領域ですが、20年分の実験データ相関や測定プロセスの自動化は、ラボ単独では現実的に手が回らない作業でした。

Yale Engineering——水溶性レドックスフロー電池の小分子設計

Yale Engineeringは、グリッド規模の蓄電を見据えた水溶性有機レドックスフロー電池向けの小分子設計でDiscoveryを活用しています。

化学設計空間は人間が直感で当たれる範囲が極めて狭く、AIが大規模スクリーニングをかけることで人間主導の実験では届かなかった候補化合物にたどり着くというパターンです。

エネルギー貯蔵領域は、再生可能エネルギーの普及で需要が拡大しており、こうした基礎研究のスピードアップが社会実装のボトルネックを直接的に解消することにつながります。

Insilico Medicine——Nach01ファウンデーションモデルとの統合

創薬AI企業のInsilico Medicineは、自社の創薬基盤モデル「Nach01」をMicrosoft Discoveryに統合する形で連携しています。

Nach01はInsilicoが開発した創薬特化のファウンデーションモデルで、これをDiscoveryプラットフォームに乗せることで、エンタープライズ・グレードのAIネイティブ創薬ワークフローを実現する構想です。

この事例が興味深いのは、DiscoveryがMicrosoft純正モデルだけで閉じる設計ではなく、外部の特化モデルを取り込むハブとして機能することを示している点です。

製薬企業や材料メーカーが自社蓄積の特化モデルを活用するシナリオで、Discoveryが土台として使われる典型例になります。

Pacific Northwest National Laboratory——エネルギー貯蔵と生体システム工学

米国のエネルギー省管轄研究所であるPacific Northwest National Laboratory（PNNL）も、エネルギー貯蔵と生体システム工学の研究にDiscoveryを利用しているとMicrosoft公式ブログで紹介されています。

国立研究機関での採用は、Discoveryがエンタープライズ商用利用に限定された製品ではなく、公的研究機関のセキュリティ・コンプライアンス要件も満たす設計であることの裏付けにもなります。

Microsoft自社のデータセンター冷却液開発——約200時間で非PFAS冷却液プロトタイプを特定

Build 2025のプライベートプレビュー段階で発表され、現在も代表事例として参照されているのが、Microsoft自身のGPUサーバー向け次世代冷却液開発のケースです。

Discoveryは約200時間で非PFASのデータセンター用浸漬冷却液プロトタイプを特定し、4か月未満で合成して一次特性が予測と整合したとMicrosoft公式ブログで発表されています。

数年単位の探索が必要だった新化学物質の候補選定を、エージェント基盤が一週間程度に短縮した好例として、業界誌でも繰り返し引用されているケースです。

先進素材・医療・産業工学・半導体——拡大する2026年のパートナー事例

Microsoftが2026年4月22日に公開したアップデートでは、GA直前のプレビュー段階で4社の追加事例が公表されています。

先進素材・特殊化学のSyensqoはR&Dから営業・マーケまでAIエージェントを横断展開、腫瘍学AIのGigaTIMEはH&Eスライドから腫瘍微小環境を推測するモデルをDiscoveryに統合（研究用途限定）、産業工学物理AIのPhysicsXはMicrosoft Surfaceの冷却ファン設計で従来数週間かかったシミュレーションを数日に短縮、半導体EDAのSynopsysはAgentEngineer™ベースのマルチエージェントワークフローをDiscoveryで運用する形で半導体設計プロセスを刷新しています。

これらの事例は、Discoveryが化学・医療・産業工学・半導体という異なるR&Dドメインを横断する基盤として運用できることを示しています。

Microsoft Discoveryの導入企業・パートナー一覧（出典：Microsoft Azure Blog）

公式ブログに掲載された導入企業からは、本記事で取り上げたYale Engineering・Insilico Medicine・Pacific Northwest National Laboratory・Syensqo・Synopsys・PhysicsXに加えて、GSK・Brembo・Cambridge Consultants・Ginkgo Bioworks・NobleAI・SandboxAQ・Synthesize Bio・Wisconsin大学・Wiley・Citrine・Clinisys・InstaDeep・InSilicoTrialsなど、製薬・素材・自動車・出版・大学研究機関にわたる広い顔ぶれが見て取れます。

化学から医療、半導体からエネルギーまで、R&Dを抱える業界全体にDiscovery採用の動きが広がっている状況です。

---

Microsoft Discoveryの料金と利用開始の流れ

R&D向けのエージェント基盤を導入する際、最初に押さえたいのが料金構造と利用開始までのプロセスです。Microsoft Discoveryは2形態それぞれで課金モデルが異なる点に注意が必要です。

料金体系——Discoveryはメッセージ課金＋Azure従量課金、appは無料DL＋Copilotクレジット

公式のMicrosoft Discovery PricingとBilling overviewでは、両形態の料金体系が次のように整理されています。

形態	課金モデル	主な費用要素
Microsoft Discovery（クラウド版）	User Messages単位の実行課金＋Azure基盤リソース従量課金	User Messages（1メッセージあたり$0.20、リージョン別調整）＋計算リソース（HPC・GPU）・ストレージ・ネットワーク
Microsoft Discovery app（ローカル版）	無料ダウンロード	GitHub Copilotサブスクリプションのクレジット消費（呼び出すモデル・エージェント実行量に応じて）

クラウド版の課金単位は「User Messages」で、create/update/delete/run/submit/cancelなどの実行系API呼び出しが1メッセージとしてカウントされます（read-only系のGET・list・status取得・ログ閲覧は非課金）。

1 User Messageは10件のバックエンド操作に相当する設計で、$0.20/メッセージ換算で100メッセージ＝$20というのが公式の例示です。
これに加えて、ワークスペースに紐づくAzureのコンピュート・ストレージ・ネットワーク・Microsoft Foundryのモデル呼び出し等が通常のAzure従量課金として別途発生します。

一方でDiscovery appは無料ダウンロードかつGitHub Copilotクレジット消費という極めてシンプルな課金モデルで、個人研究者が気軽に試せる設計になっています。

アプリ自体は無料で、起動には有効なGitHub Copilotサブスクリプションが必要です。

Discovery appのインストールと初期起動

Discovery appを試したい場合の流れは公式GitHubリポジトリで案内されている通り、以下のステップになります。

• GitHubアカウントと有効なGitHub Copilotサブスクリプションを準備する
• Microsoft Discovery GitHubからWindows向けインストーラーをダウンロードする
• インストール後にアプリを起動し、GitHubアカウントでサインインする
• 初期画面でBookshelf・Engines・Tasksの状態を確認する

Discovery appの起動画面（Microsoft Discovery PRE）（出典：Microsoft Azure Blog）

起動直後の画面では「Microsoft Discovery PRE」のロゴとともに「What would you like to discover today?」というプロンプト欄が中央に置かれ、初学者向けに「Help me get started」「Research」「Explore agentic capabilities」の3つの入り口ボタンが提示されます。TRY ASKINGセクションには「Help me set up my project」「Get started with Discovery Engine and tasks」のサンプル質問が並び、SHORTCUTSセクションからは「Add knowledge bases to my bookshelf」「Getting started guide」「Open Discovery documentation」にワンクリックで飛べる構成です。

プレビュー段階を示す「PRE」マーク・左下の「Bookshelf: No shelves」「Engines: 0」「Tasks: 1 ready」のステータスバーで、設定すべき項目が一目で分かるレイアウトになっています。

セットアップは数分で完了するため、まずは個人で触ってからチームへ展開する判断ができます。Azureサブスクリプションやクラウド認証情報は不要なため、IT部門の事前承認プロセスを通さずに評価できる点が大きな特徴です。

クラウド版（Microsoft Discovery）の導入フロー

エンタープライズ版を導入する場合は、Microsoftアカウント担当者経由でPoCを設計するアプローチになります。

• Microsoftの担当営業・パートナー経由で要件ヒアリングを依頼する
• Microsoft Discoveryチームに対象Azureサブスクリプションのallow-list申請を行い、利用許可を得る
• 必要なリソースプロバイダー登録・管理者権限の付与・GPU/HPCクォータ予約を済ませる
• Azureサブスクリプション・ネットワーク構成・Entra ID統合の前提を確認する
• 公式のBicepテンプレートを用いて初期インフラを一括デプロイする
• Discovery Studioでプロジェクトリソースを管理しながらエージェントを構築する
• M365・Foundry・Fabricとの統合を順次設定する

クラウド版はAzureのID管理・ロールベースアクセス・プライベートネットワーク・監査ログといったエンタープライズ統制機能と組み合わせて使う前提で設計されています。Azureネイティブのガバナンス機能がそのまま使えるため、シャドウIT・統制例外を生まずに展開できる点もメリットです。

「いきなりクラウド版」か「appで先行検証」かの判断

実務で多いのは、最初にappで小さく検証してからクラウド版に拡大するパターンです。

クラウド版はPoC設計・Azureコスト見積もり・IT部門承認・予算策定まで含めると2〜3か月単位の準備期間が現実的で、その間に現場の研究員が「価値があるか分からないまま待たされる」と熱量を失うリスクがあります。

一方でappは数分で起動し、現場研究員自身が**「自分の研究テーマでDiscoveryに何が起きるか」を体感**できます。価値が見えた段階で経営層・IT部門にエンタープライズ版の提案を持っていく流れが、最もスムーズな導入パターンになります。

---

Microsoft Discoveryの使い方——資料登録からタスク実行・結果活用までの操作フロー

Discovery appまたはクラウド版のセットアップが済んだあと、研究員が日常的にDiscoveryをどう動かすかは、大きく「Bookshelfへの資料登録」「タスク作成」「エージェント実行」「結果分析と再利用」の4ステップに分かれます。ここでは、Discovery appではVS Code統合を含むローカルUI、クラウド版ではDiscovery Studioを中心に、資料登録からタスク実行・結果活用までの流れを整理します。

以下の表で、4ステップそれぞれの目的と主な操作画面を整理しました。

各ステップが独立した工程ではなく、結果分析の出力がタスク作成側にフィードバックされる循環構造になっている点を先に押さえておくと、後半の解説が理解しやすくなります。

ステップ	目的	主な操作画面
Bookshelfに資料を登録	研究テーマ関連の知識源をエージェントに読み込ませる	Bookshelfパネル / Ingest Documents、Discovery Studio（Storage Asset・Knowledge Base作成）
タスクを作成	研究目標をValidation Criteriaごと構造化してエージェントに渡す	New taskフォーム・Shared session
エージェント実行	特化エージェントに調査・仮説生成・シミュレーションを並列実行させる	Status Overview・サブタスクパネル
結果分析と後続タスクへの引き渡し	AI出力の確度を評価し、次の仮説生成に接続する	Confidence Summary Table・詳細findings

この4ステップは順番に流すというよりも、一つの研究テーマをループで回して探索範囲を広げていく前提で設計されています。1回のタスクで完結せず、結果分析で得た知見をNotebookやタスク結果として残し、必要に応じて再取り込み・再インデックス化して次の探索に接続する循環を意識しておくと、Discoveryの本来の使い方を活かせます。

Bookshelfに研究資料を登録する——AI推論の元データを整える

Discoveryを立ち上げて最初に行うのが、Bookshelfへの資料登録です。Bookshelfは取り込んだ文書からベクトル検索インデックスと知識グラフを構成するリソースで、公式ドキュメント上は現時点で「1つのBookshelfに1つのKnowledge Baseが紐づく」構造として説明されています。テーマや案件を分けたい場合は、Bookshelf単位で切り分けて整理するのが安全な運用になります。

Discovery appとクラウド版で、対応形式と取り込み経路が異なる点は事前に押さえておきます。

• Discovery app（ローカル版）——Bookshelfパネルでshelfを作成し、「Ingest Documents」からPDF・Markdown・Office形式・コードなどのテキストベース資料を取り込む
• クラウド版——対象文書をAzure Blob Storageに配置し、Discovery StudioでStorage AssetとKnowledge Baseを作成してインデックス化する。Bookshelfでサポートされる主な形式は.pdf・.docx・.pptx・.xlsx・.txt・.html
• CSV・JSON・実験データ——Bookshelfへの直接登録ではなくStorage Assetとして扱い、タスク側から参照する
• ELN・LIMSなど外部システム——Bookshelfではなくカスタムツール連携として、エージェントから呼び出す

Discovery appの初期画面には「Add knowledge bases to my bookshelf」というショートカットが並びます。一方、クラウド版はAzure Blob Storageに文書を配置し、Discovery StudioでStorage AssetとKnowledge Baseを作成してインデックス化する経路になるため、appで慣れた手順をそのままクラウドに持ち込むと動かないケースがある点だけ意識しておくと事故が減らせます。

ここで押さえておきたいのは、Bookshelfに入れた資料の質がそのままエージェント出力の品質を左右するということです。玉石混交の資料を大量に投入するより、テーマに関連する一次資料に絞って登録するほうが、AIの推論精度は高くなります。

タスク作成フォームで研究目標とValidation Criteriaを構造化する

Bookshelf登録が済んだら、次はDiscovery Engineに解いてほしい研究タスクを作成します。中央のプロンプト欄「What would you like to discover today?」に自然言語で研究目標を書くか、「New task」ボタンから構造化フォームに沿って入力する2通りの方法があります。

構造化フォームで指定できる主な項目は次の通りです。

• タイトル——タスクを識別する名称
• 共有セッション——チームメンバーとの共同作業単位
• 記述——研究目標・背景・制約条件を自然言語で詳細記述
• Validation Criteria——AI出力を検証するための評価基準
• 担当エージェント——このタスクに割り当てる特化エージェント
• 優先度・依存タスク——ワークフロー内の実行順序

この中で特に品質を左右するのがValidation Criteria（検証基準）の設定です。

ここが曖昧だとAIが「それらしい仮説」を大量に返してノイズが増えるため、実務では「定量的な閾値」「参照すべき先行研究」「除外条件」の3点を明示するのがコツになります。

たとえば創薬のリード化合物探索なら「IC50値10μM以下」「既知の毒性プロファイルデータベースで安全性が確認済み」「特定の受容体サブタイプへの選択性が確認できる」といった条件を具体的に書き込むことで、AIの出力が投資判断に耐える精度に近づきます。

特化エージェントの並列実行と「Needs User Attention」の確認

タスクを送信すると、Discovery Engineは内容を解析して複数の特化エージェントに自動でサブタスクを割り振り、並列実行を開始します。

公式画面例では、p53 Cancer Vaccine Analysisのタスクに対してblastAgent・iedbAgent・evodiffAgent・sciencegpt5Agentといった複数のエージェントが同時に動く様子が示されています。研究員は個別のツール操作をせず、タスクを送るだけで裏側の役割分担が自動化される設計です。

実行中は画面右側の「Status Overview」パネルで、以下の情報がリアルタイムに追跡できます。

• 全体の完了率（例：Total Tasks 7のうち完了4、要確認3）
• 各サブタスクの状態（Executing / Validating / Complete / Needs User Attention など）
• 個別エージェントごとの中間出力
• エージェント間の依存関係と実行順序

途中でAIが判断に迷う場面では**「Needs User Attention」ステータス**（Learnドキュメント上の内部状態はFlaggedHuman）として人間の判断を仰ぐ設計になっており、研究員は実行履歴とValidationコメントを確認したうえで、追加指示・条件修正・結果採用のいずれかを判断します。ヒューマン・イン・ザ・ループが標準搭載されているため、AIが暴走してノイズだけ蓄積するリスクを抑えられます。

長時間かかるHPC計算や大規模シミュレーションについては、実行を投げた後にDiscoveryを閉じても問題ありません。結果がまとまるとワークスペースに通知が届き、次回起動時に分析画面が用意されています。

Confidence Summary Tableの読み方と次のループへの接続

エージェントの実行が完了すると、Confidence Summary Tableという表形式で結果が提示されます。ここが単なるレポート出力ではなく、Discoveryの真価が現れる画面です。

Confidence Summary Tableの主な項目を整理すると次のようになります。

表示項目	内容
Finding	AIが導いた主要な知見
Confidence	4/5 HIGH・3/5 MODERATE・1/5 SPECULATIVE のようにスコア分数付きで示される確度ラベル
Key Evidence	判断の根拠となった文献・データ
Caveat	出力の注意点・前提条件・限界

Confidenceは単なるラベルではなくスコア分数付きで表示されるため、Key Evidenceに並ぶ根拠がどの程度そのラベルを支えているかが定量的に読み取れます。参照リンクは表の列としては用意されておらず、詳細findingsを開くと本文中のインライン引用（inline citations / source references）としてナレッジグラフ上の根拠ノードへたどれる作りです。

ここで実務的に重要なのが、HIGH / MODERATE / SPECULATIVEの3段階ラベルをそのまま社内意思決定に使わないことです。SPECULATIVEは「実験を投じる価値がある仮説」であってエビデンスがまだ薄い状態を意味し、HIGHでも「既知データからの推論」に留まっているケースが含まれます。研究部門長は各ラベルの意味とスコア分母を社内で定義し直したうえで、投資判断のフィルターとして運用するのが現実的です。

結果を確認したら、次に行うのが採用findingの後続タスクへの引き渡しです。Discovery appでは、採用したfindingをNotebookに保存したりBookshelf検索結果をpin留めしたりして後続の検討に残せます。Copilot Chatに「Save this to my notebook: ...」のように渡して保存する使い方も公式Quick Startで案内されています。クラウド版では、タスク結果・Storage Assets・dependsOnによる依存関係を通じて、下流タスクへ入力として継承させる形が公式のフローです。Bookshelfそのものに反映したい場合は、成果物を文書・データとして整理し、再取り込み・再インデックス化する手順を経由します。これによってエージェントの実行結果が組織の長期記憶として蓄積され、後続プロジェクトが自動的に恩恵を受ける構造ができます。

なお画面下部には常時「AI-generated content may be incorrect」の注意書きが固定表示されており、Microsoft側もAI出力が完全ではないことを明示しています。研究の意思決定に使う際は、Confidence Summary Tableだけで判断せず必ず一次資料への遡上と物理実験による検証を挟む運用が推奨されます。

これら4ステップを1サイクル回すのが基本の使い方ですが、Discoveryの本領は結果分析で得たfindingが新タスクにフィードバックされ、探索空間が拡張されていく循環にあります。単発の質問応答ではなく、研究テーマに沿った長期的な仮説検証ループを組織で回す道具として設計されている点を意識すると、Discoveryの使い方が大きく変わってきます。

---

Microsoft Discoveryと他社の科学R&D AIプラットフォームの違い

科学R&D向けのAIプラットフォームは、Microsoft Discoveryの他にもGoogleとNVIDIAから類似製品が出ています。

エンタープライズ採用を判断する際に、ここの違いを押さえておくことが選定の鍵になります。

Google AI Co-Scientist——仮説生成に特化したマルチエージェント

Googleは2025年にAI Co-Scientistを発表し、2026年6月時点ではGemini Enterprise上のPreview機能としてAlphaEvolveとともに提供されています。

Gemini 2.0をベースに、Generation/Reflection/Ranking/Evolution/Proximity/Meta-reviewの6つの専門エージェントとそれらを統括するSupervisor agentを連携させ、研究者の制約条件下で詳細な研究提案を生成する設計です。

Stanford大学やImperial College Londonとの共同検証で、抗菌薬耐性に関連する新しい遺伝子転移メカニズムの提案や、肝線維症の創薬候補の特定といった成果を出しています。

Co-ScientistとMicrosoft Discoveryの違いは、スコープと統合範囲にあります。

Co-Scientistは仮説生成・実験設計といった研究の上流工程に強みを持つ一方、Discoveryは仮説〜実験〜分析〜ナレッジ蓄積までのループ全体を対象に置く点で守備範囲が広い設計です。

NVIDIA BioNeMo——創薬・バイオに特化したスキルセット

NVIDIA BioNeMoは、創薬・バイオに特化したAIプラットフォームで、構造予測・分子生成・ドッキング・配列解析・ゲノミクスといった機能を「BioNeMo Skills」として呼び出せるスキルセットを提供しています。

2026年6月に発表された「BioNeMo Agent Toolkit」により、AIエージェントが上記Skillsを組み合わせて創薬ワークフローを実行できるようになりました。

Discoveryとの違いは、カバー領域の専門化と汎用性です。BioNeMoは創薬・バイオサイエンスに特化することで深い専門ツールを揃えており、製薬大手のAI創薬で広く採用されています。

一方でDiscoveryは創薬以外の化学・材料・半導体・エネルギー・先端製造まで広く対象としており、エンタープライズR&D全般のオーケストレーションプラットフォームとして位置付けられています。

3プラットフォームの位置づけ比較

以下の表で、Microsoft Discovery・Google Co-Scientist・NVIDIA BioNeMoの位置づけを整理しました。

観点	Microsoft Discovery	Google AI Co-Scientist	NVIDIA BioNeMo
主たる強み	エンタープライズR&Dのオーケストレーション	仮説生成・実験設計のマルチエージェント	創薬・バイオ特化のSkillsとAgent Toolkit
ベースモデル	Microsoft Foundry経由の各種モデル＋LQM	Gemini 2.0ベース・6専門エージェント＋Supervisor	NVIDIA独自の創薬・バイオ向けモデル群
計算基盤	Azure（HPC・GPU・将来量子）	Google Cloud	NVIDIA GPU・DGX Cloud
エンタープライズ統合	M365・Foundry・Fabricと一体運用	Gemini Enterprise上のPreview提供（AlphaEvolveも併走）	製薬企業のオンプレ／クラウド両対応
知識基盤	グラフベース＋長期メモリ・ナレッジグラフ	多段階エージェントの推論ツリー	Skills連携で都度生成
想定ユーザー	製造業・素材・製薬・半導体のR&D部門	研究機関・学術	製薬企業・バイオ研究

これら3つは競合関係というより、選定対象が違うケースが多くなります。「Microsoft 365やFabricとの統合を前提にしたエンタープライズR&Dの全面DXならDiscovery」「学術連携で仮説生成にフォーカスするならCo-Scientist」「創薬パイプラインの専門ツール群を求めるならBioNeMo」というのが現実的な使い分けです。

既存R&D特化ツールとの関係

最後に、もう一段抽象度を上げて、Discoveryと既存のR&D特化ツール（AIエージェント基盤全般・電子実験ノート・LIMS・化学設計ソフト等）の関係を整理しておきます。

Discoveryは既存ツールを置き換える製品ではなく、既存ツールをエージェントから呼び出すハブとして動く設計です。既存のシミュレーションソフトや実験管理システムが社内に残っていても、それらをDiscoveryからAPIや外部ツール連携を通じて呼び出してエージェントワークフローに組み込めます。

このため、既存R&Dシステムを刷新する必要はなく、周辺にエージェントオーケストレーション層を被せる形で段階的に導入できます。これは既存資産が大きい大企業のR&D部門にとって、現実的な導入経路として機能します。

---

Microsoft Discovery導入で押さえるべき3つの観点

Microsoft Discoveryのようなエンタープライズ・エージェント基盤を実際に導入する際、汎用Copilot・ChatGPTとは異なる検討ポイントがいくつか発生します。

データ境界——「どこまでをDiscoveryに渡すか」を最初に線引きする

R&D部門のデータは、公開してよい範囲・社内限定の範囲・特許前で絶対に外に出してはいけない範囲の3層構造になっているのが普通です。

ところがDiscoveryのようなエージェント基盤は、Bookshelfに資料を投入することで初めて性能を発揮します。

「とりあえず社内文書を全部入れてみる」というアプローチは魅力的に見える一方、データ境界の設計を後回しにすると、未公開の合成経路や顧客情報がエージェントの出力に混入するリスクが残ります。

導入初期で必ずやるべきは次の3点です。

• どのプロジェクトのデータを、どのワークスペースで使うかをマトリクスで定義する
• 特許出願前データには別ワークスペースを切り、AIモデルの学習に使われないテナント設定を確認する
• Discoveryクラウド版のAzureテナンシー境界（リージョン・サブスクリプション）が法務・知財部門の要請と整合するかを確認する

クラウド版はAzureネイティブのガバナンスがそのまま使える設計のため、Microsoft Entra IDのロールベース制御やプライベートネットワーク機能と組み合わせて統制を構成するのが現実的なアプローチです。

組織前提——研究機関中心の事例をどう自社に転用するか

公式の導入事例を見ると、Yale Engineering・PNNL・Insilico Medicine・Microsoft自社（量子チップ・冷却液）と、研究機関と先端テック企業のR&D事例が多くを占めます。

製造業の中堅メーカーや素材メーカーが自社に当てはめる際は、事例の前提条件を慎重に解釈する必要があります。

• これらの事例は、高度な研究設備・データ基盤・専門人材といったベースを既に持つ組織が多い
• データ量・データ品質も研究機関水準で揃っており、社内データの整備が前提として済んでいることが多い
• 研究員自体がAI/MLリテラシーを持っているケースが多く、エージェントへのプロンプト設計力もある

つまり、中堅製造業がいきなりMajorana 2級の事例を目指すとベースインフラ・データ整備・人材の3点で足元から大きなギャップが生じやすいと考えられます。

現実的には、社内の数十名規模のR&D部門で1テーマに絞ったPoCから始め、データ整備とAIリテラシー強化を並行で進める形が成功確率を高めるでしょう。

既存R&Dシステムとの統合コスト——刷新ではなく接続で考える

R&D部門には、電子実験ノート（ELN）・LIMS・化学設計ソフト・分子シミュレーション基盤・ハイスループット実験装置といった長年運用してきた専門システムが存在します。

Discovery導入で陥りやすい誤解が、「これらを全部Discoveryに置き換える」と発想してしまうことです。

Discoveryは既存システムをAPI経由で呼び出すハブとして設計されているため、既存資産を残したまま接続層としてDiscoveryを上に乗せるのが正しいアプローチになります。

統合コストで詰まりやすいのは、次の3点です。

• 既存システムがAPIや外部ツール連携で呼び出せる構造になっているか（特に古いLIMS・ELNはオンプレ専用でAPIが限定的なことが多い）
• 既存システムからのデータをDiscoveryのナレッジグラフに継続的にフィードするETL設計
• エージェントが既存システムに書き込みを行う場合の監査ログ・ロールバック設計

このあたりは、ループエンジニアリングやOpen Knowledge Formatで語られるエージェント自律設計の議論と接続する論点で、Discoveryを採用するかどうかに関わらず、エンタープライズAIエージェント全般で押さえる必要があります。

これら3つの観点を導入初期で整理しておくと、PoC段階で「使えなかった」という失敗を避けやすくなります。

逆に言えば、ここを曖昧なままPoCを始めると、Discoveryの性能ではなく社内側の前提が足りていないために価値が出ないという結末に陥りやすい領域です。

---

R&D前段のAIエージェント運用を業務に定着させる

Microsoft DiscoveryのようなR&D特化のエージェント基盤を本格採用する前段で、多くの企業が直面するのが「社内全体のAIエージェント運用ノウハウがまだ薄い」という課題です。

研究現場でDiscoveryを使いこなすには、エージェントへのプロンプト設計・データ整備・統制ルールの整備といった、汎用AIエージェント運用の土台が必要になります。ここが薄いまま研究用エージェントを導入しても、PoC段階で頓挫しやすいパターンが見えてきています。

AI総合研究所では、PoCから全社展開までの進め方、部門別ユースケース、AI運用における統制・セキュリティのチェックポイントを220ページにまとめた「AI業務自動化ガイド」を無料で公開しています。研究開発部門向けエージェント導入の前段として、業務側のAIエージェント運用を整える第一歩としてご活用ください。

---

まとめ

本記事では、2026年6月2日にBuild 2026で一般提供開始したMicrosoft Discoveryについて、中核技術・6つの研究シナリオ・Discovery appとの使い分け・公式導入事例・料金・競合との違い・導入観点まで、2026年6月時点の最新情報で解説しました。要点を改めて整理します。

• Microsoft Discoveryは研究開発向けエージェント型AIプラットフォームで、化学・材料・生命科学・半導体・エネルギーといったR&D領域を対象に、文献調査〜仮説生成〜実験〜分析のループ全体をエージェント連携で回す設計になっている
  
  

• 中核のDiscovery Engineはグラフベース知識基盤・LQM・HPCを統合し、結果を長期メモリのナレッジグラフに蓄積することで、組織の研究知が時間経過とともに資産化される
  
  

• エンタープライズ向けの「Microsoft Discovery」とローカル向けの「Microsoft Discovery app」の2形態で提供。appは有効なGitHub Copilotサブスクリプションがあれば起動でき、現場検証からエンタープライズ展開への段階的アップグレードが可能
  
  

• 公式事例はMajorana 2量子チップ・Yale Engineering・Insilico Medicine・PNNL・自社冷却液開発の5件が代表的で、特に約200時間で非PFAS浸漬冷却液プロトタイプを特定した冷却液事例は数年単位の探索を一週間に短縮した代表例
  
  

• 競合のGoogle Co-Scientist・NVIDIA BioNeMoとはスコープが異なる。DiscoveryはM365・Foundry・Fabricとの統合を前提としたエンタープライズR&Dのオーケストレーションプラットフォームに最適化されている

R&D部門のAI導入を考える企業にとってMicrosoft Discoveryは、「使うかどうか」よりも「自社のR&D業務を、エージェント前提で再設計できるか」という問いを突きつける製品です。まずはDiscovery appを現場研究員に試してもらい、価値が見えた段階でエンタープライズ版・PoC設計に進むという段階的アプローチが、最も現実的な第一歩になります。

研究開発のスピードがAIエージェントによって桁違いに変わる2026年は、組織として「エージェントを動かす土台」を整えるかどうかが、その後のR&D競争力を大きく左右する分岐点になります。