Microsoft Discoveryとは？Discovery appとの違いや料金、使い方を徹底解説

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とは？

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と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の料金と利用開始の流れ

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

料金体系

公式の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リポジトリで案内されている通り、以下のステップになります。

0. アカウントの準備
   GitHubアカウントと、有効なGitHub Copilotサブスクリプションを事前に準備します。
   
   

1. Discovery appのダウンロード
   Microsoft Discoveryの公式リポジトリにアクセスし、Windows向けのインストーラーをダウンロードします。
   
   Discovery appのダウンロード
   
   

2. Discovery appのインストールと初回起動
   インストーラーのウィザードに従ってDiscovery appをインストールします。アプリを起動したら、GitHubアカウントでサインインしましょう。
   
   Discovery appのインストールと初回起動
   
   

3. プロジェクトの作成と作業の開始
   サインインが完了すると、「Welcome to Microsoft Discovery」というスタート画面が表示されます。画面中央の「New project」をクリックして新しいプロジェクトを作成するか、「Open folder」をクリックして既存のフォルダを開き、作業を開始します。
   プロジェクト開始後は、左側のサイドバーから「TASKS」を作成し、「BOOKSHELF」や「ENGINES」を設定して具体的な研究や分析のワークフローを構築していくことになります。

Discovery appのスタート画面

セットアップは数分で完了するため、まずは個人で触ってからチームへ展開する判断ができます。

Azureサブスクリプションやクラウド認証情報は不要なため、IT部門の事前承認プロセスを通さずに評価できる点が大きな特徴です。

クラウド版（Microsoft Discovery）

クラウド版（Microsoft Discovery）の導入は、主にAzureポータルを用いた以下のステップで進行します。

1. ネットワーク・ID・ストレージの設定
   まず、仮想ネットワークやサブネット、ユーザー割り当てマネージドID（UAMI）、およびAzure Blob Storageといった基礎インフラを準備し、管理者に必要なロールを割り当てます。
   
   ロールの割り当て画面 引用：クイック スタート: Microsoft Discovery インフラストラクチャの概要
   
   

2. スーパーコンピューターの作成
   次に、GPUやCPUを集中的に使用するワークロードやシミュレーションを実行するための「スーパーコンピューター」リソースを作成し、ノードプールを構成します。
   
   スーパーコンピューターの作成 引用：クイック スタート: Microsoft Discovery インフラストラクチャの概要
   
   

3. ワークスペースの作成
   スーパーコンピューター、エージェント、ナレッジベースなどを単一のセキュアな境界にまとめるコラボレーション環境「ワークスペース」を作成し、マネージド リソース グループへの権限を設定します。
   
   ワークスペース作成画面 引用：クイック スタート: Microsoft Discovery インフラストラクチャの概要
   
   

4. Microsoft Discovery Studioでのプロジェクトとエージェント実行
   ワークスペースの準備が整ったら、「Microsoft Discovery Studio」にサインインしてプロジェクトを作成します。チャットモデルを展開し、エージェントを用いて実際の調査を実行します。
   
   Microsoft Discovery Studioホーム画面 引用：クイック スタート: Microsoft Discovery インフラストラクチャの概要

クラウド版はAzureのID管理・ロールベースアクセス・プライベートネットワーク・監査ログといったエンタープライズ統制機能と組み合わせて使う前提で設計されています。

Azureネイティブのガバナンス機能がそのまま使えるため、シャドウIT・統制例外を生まずに展開できる点もメリットです。

---

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

Discovery appまたはクラウド版のセットアップが済んだあと、Discoveryをどう動かすかは、大きく「Bookshelfへの資料登録」「タスク作成」「エージェント実行」「結果分析と再利用」の4ステップに分かれます。

ここでは、Discovery appではVS Code統合を含むローカルUI、クラウド版ではDiscovery Studioを中心に、資料登録からタスク実行・結果活用までの流れを整理します。

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

Bookshelfに研究資料を登録

Discoveryを立ち上げて最初に行うのが、Bookshelfへの資料登録です。

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

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

• Discovery app（ローカル版）
  Bookshelfパネルでshelfを作成し、「Ingest Documents」からPDF・Markdown・Office形式・コードなどのテキストベース資料を取り込む
  
  Discovery appで研究資料を登録
  
  

• クラウド版
  対象文書をAzure Blob Storageに配置し（マネージドIDのアクセス権付与が必要）、AzureポータルでストレージコンテナーリソースとStorage Assetを作成した後、Discovery StudioでKnowledge Baseを作成してインデックス化する。Bookshelfでサポートされる主な形式は「.pdf」・「.docx」・「.pptx」・「.xlsx」・「.txt」・「.html」（※PDFファイルは1ファイルあたり2,000ページの上限あり）
  
  Azureポータルで研究資料を登録
  
  

• CSV・JSON・実験データ——Bookshelfへの直接登録ではなくStorage Assetとして扱い、タスク側から参照する

• ELN・LIMSなど外部システム——Bookshelfではなくカスタムツール連携として、エージェントから呼び出す

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

タスクを設定

研究資料の登録が完了したら、次は探索エンジンに解いてほしいタスクを定義します。

以下のようにチャットインターフェースからプロンプトを入力して共有セッション（Shared Session）を作成し、自然言語の指示からエージェントに作業を開始させます。

Microsoft Discovery Studioのチャットインターフェイス 引用：クイックスタート: Microsoft Discovery Studio でエージェントと共有セッションの使用を開始する

あるいは、以下のように構造化されたタスクを明示的に定義します。

構造化タスクの定義画面

タスクは作業を理解し、実行し、評価するために必要な情報を保持します。主な構造は次の通りです。

• 名前（Name）——タスクの目的を要約した簡潔な名称
• 共有セッション（Shared Session）——タスクが実行される共有セッション
• 説明（Description）——実行内容、目標、制約などの詳細
• 検証の要件（Validation Requirements）——AIの出力結果が成功条件を満たしているかを判定する客観的な評価基準
• 割当先（Assignee）——タスクを実行する特化エージェント
• 優先順位（Priority）・依存タスク（Dependent tasks）——他のタスクとの相対的な重要度や、実行順序の制約

この中で特に品質を左右するのが検証の要件（Validation Requirements）の設定です。

タイトルと説明が何をすべきかを指示するのに対し、検証要件は「いつその作業が基準を満たしたとみなすか」を定義します。

ここが曖昧だとAIがそれらしい仮説を返してくる可能性があるため、「予測値には信頼区間または誤差推定値が含まれること」のように、明確で検証可能なステートメントとして記述します。

エージェントによるタスクの実行

タスクが実行されると、探索エンジンの認知機能が依存関係や親子関係を解釈し、自動的に適切な特化エージェントにタスクを割り振って実行します。たとえば「分析」という親タスクの下で、依存関係のないサブタスクを並列実行し、それらが完了した後に後続のタスクを実行するといったワークフローの順序付けをエンジンが担います。

実行が完了すると、エンジンは結果を自動的に検証します。検証要件を満たしていない場合、ステータスは未完了（Incomplete）となり、認知機能は同じエージェントや別のエージェントで再試行を試みます。

エージェントによるタスクの実行 引用：チュートリアル & How-To ビデオ

認知機能が複数のアプローチを試みても検証に合格する結果を出せなかったり、人間の判断が必要だと判断された場合、タスクはユーザーの注意が必要（Needs User Attention）ステータスに移行します。

この設計により、研究員はタスクの実行履歴や検証コメントを確認し、追加指示の提供、タスク条件の修正、あるいは現在の結果をそのまま受け入れるといった判断（ヒューマン・イン・ザ・ループ）を下すことができます。AIが暴走して無意味な計算リソースを浪費するリスクを抑える重要な仕組みです。

長時間かかる計算についても、実行を投げた後にDiscoveryを閉じても問題ありません。結果がまとまると次回のアクセス時に確認できます。

結果の分析と後続タスクへの引き渡し

タスクが完了（Complete）ステータスになると、エージェントによって生成された結果やデータ資産が出力として提示されます。これは単なるテキストのレポート出力ではなく、その後の研究ワークフローを駆動するための構造化されたデータとして扱われます。

タスクの出力には、AIが推論したテキスト結果に加えて、入力または出力となったファイル、データセットなどのリソースへの参照が含まれます。さらに実行履歴として、どのエージェントがいつ実行され、どのような判断プロセスを経たかという全履歴が記録されています。

タスクの実行結果の分析画面 引用：チュートリアル & How-To ビデオ

結果を確認した後に重要となるのが、得られた結果を後続タスクへ引き渡すプロセスです。あるタスクが完了すると、その結果は下流タスクの入力データとして自動的に利用可能になります。

また、探索エンジンが導き出した結果は長期的なメモリ ナレッジグラフに保存されるよう設計されており、1回の共有セッションで得られた知見を、将来のイテレーションや組織内の別のプロジェクトで再利用することができます。

Discoveryの本領は結果分析で得た知見が新タスクにフィードバックされ、探索空間が拡張されていく循環にあります。単発の質問応答ではなく、研究テーマに沿った長期的な仮説検証ループを組織で回すプラットフォームとして設計されている点を意識すると、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で支援される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の公式導入事例

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導入で押さえるべき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エージェント運用を整える第一歩としてご活用ください。

---

まとめ——Microsoft Discoveryが向くのは「R&Dループ全体をエージェント化したい」組織

本記事では、Microsoft Discoveryの中核アーキテクチャ・2形態の使い分け・料金・使い方・他社比較・研究シナリオ・導入事例・判断観点までを、2026年6月時点の最新情報で整理しました。

要点を改めて振り返ります。

• Microsoft DiscoveryはR&D向けエージェント型AIプラットフォーム
  2026年6月にBuild 2026でGA、化学・材料・生命・半導体・エネルギー領域の文献〜仮説〜実験〜分析ループをエージェント連携で回す設計
  
  

• 中核はDiscovery Engine——グラフ知識基盤＋LQM＋HPCの統合
  結果は長期メモリのナレッジグラフに書き戻され、組織の研究知が時間経過とともに資産化される
  
  

• 提供形態はEnterprise版とDiscovery appの2つ
  appは無料DL＋有効なGitHub Copilotサブスクリプションで起動可能、現場検証からエンタープライズ展開へ段階アップグレード
  
  

• 料金はメッセージ課金＋Azure従量、appは無料DL＋Copilotクレジット
  本格運用のコスト中心はHPCジョブ実行料と使用モデル別のToken単価
  
  

• 他社FWとはスコープが異なる
  Google Co-Scientistは仮説生成特化、NVIDIA BioNeMoは創薬・バイオ特化、DiscoveryはM365・Foundry・Fabric統合を前提としたR&Dオーケストレーション基盤
  
  

• 公式事例はMajorana 2・Yale・Insilico・PNNL・自社冷却液の5件
  特に非PFAS浸漬冷却液を約200時間で特定した冷却液事例は、数年単位の探索を一週間に短縮
  
  

• 導入判断は「データ境界／組織前提／既存システム統合」の3観点
  Discoveryはハブ設計なので、既存R&Dツールを刷新せず周辺にエージェントオーケストレーション層を被せられる

Microsoft Discoveryが向くのは、R&D業務の運用基盤そのものをエージェント前提で再設計したい組織です。逆に、単発ツール置き換えや個別タスクの効率化だけを狙う場合は、汎用CopilotやChatGPTで十分ワークします。

自社R&Dが「文献〜仮説〜実験〜分析のループで語れる分業構造」を持つなら、まずDiscovery appを現場研究員に配布して価値検証し、その先にエンタープライズ版・PoC設計へ進むのが、最も再現性の高い第一歩になります。