DatabricksとMicrosoft、ガバナンスを備えたビジネスコンテキストを軸にAI提携を拡大

DatabricksとMicrosoftは、10年にわたる提携を2030年代まで延長した。これはGoogle Newsの読者に、エンタープライズAIをめぐる競争が変化したことを明確に示す動きだ。次の争点は、単に最も賢いモデルを提供する企業がどこかではない。ガバナンス、ID管理、コスト可視化を損なうことなく、エージェントを信頼できるビジネスデータへ接続できるプラットフォームがどこかにある。

両社は2026年7月23日、拡大した契約を発表した。Databricksは自社業務のより多くをAzure Databricks上で稼働させ、Microsoft設計のCobaltプロセッサーの利用を拡大する。Microsoftは、Microsoft 365、Teams、Copilot、Power BI、OneLake、Purview、Foundryなどの製品にDatabricksの技術をより深く組み込む。

ここに中心的な緊張関係が生まれる。Microsoftはすでに、Fabricと自社のコンテキスト技術をエンタープライズAI向けデータ基盤として推進している。一方Databricksは、同じ環境に別のセマンティック層、ガバナンス層、エージェント層を持ち込む。両社の提携は顧客の選択肢を広げるが、購入者が調整しなければならない管理プレーンの重複も生み出す。

拡大した契約はクラウド容量の提供にとどまらない

Databricksは、Microsoftの戦略的なAzure顧客であると同時に、Microsoftの最重要ワークプレイス製品に組み込まれるデータインテリジェンス層になりつつある。

拡大されたエンタープライズAI契約は、両社の関係を2030年代まで延長する。エンタープライズ向けデータプラットフォームは何年にもわたり使われ続けることが多いため、その期間には意味がある。顧客は、移行コストの高いデータパイプライン、アクセス方針、業務定義、ダッシュボード、運用プロセスへ投資する。

Databricksは、中核となる業務運営と分析をAzure Databricks上で実行する計画だ。また、このプラットフォーム上に統合された社内レイクハウスを構築する。レイクハウスは、データレイクの柔軟性と、従来データウェアハウスに関連付けられてきた管理機能を組み合わせたものだ。

このコミットメントは、Microsoftにとって価値ある顧客事例となる。Databricksは事実上、自社プラットフォームのAzure版を業務上重要な用途で使用することになる。ただし、この取り決めは顧客が導入成果を評価できるようになるまでは、企業側の主張にとどまる。

インフラ面も同様に重要だ。Databricksは現在MicrosoftのCobalt 100プロセッサーを使用しており、Cobalt 200の採用を予定している。Cobaltは、Azure内のクラウドワークロード向けに設計されたMicrosoftのArmベースのサーバープロセッサーファミリーだ。

Microsoftによると、Cobalt 200は前世代と比べて最大50%高い性能を提供し、メモリ暗号化を標準で有効にする。この数値はMicrosoftのプラットフォームに関する主張であり、すべてのDatabricksワークロードで一律の改善を意味するものではない。性能はソフトウェア、ワークロード設計、メモリ要件、デプロイ構成に左右される。

したがって、この契約がMicrosoftにもたらすのは追加のクラウド消費だけではない。Databricksの分析やAIエージェントに関連するワークロードの下層に、Microsoft設計のプロセッサーが配置される。これは、単なるコンピューティング容量の貸し出しではなく、垂直統合されたインフラによって競争しようとするAzureの取り組みを強化する。

Microsoftは、Databricks GenieとUnity AI Gatewayの統合を製品ポートフォリオ全体で深める。Genieは、ユーザーやソフトウェアエージェントが自然言語を通じてビジネスデータを照会できるようにする。Genie Ontologyは、企業固有の用語や関係性を基盤となるデータに対応付けるセマンティック層を提供する。

Unity AI Gatewayは、モデル、エージェント、利用状況、コストを一元的に制御する。これは、一貫したポリシーを適用しながら、異なるAIシステム間のリクエストを企業が管理できるようにすることを目的としている。Unity Catalogはその下層に位置し、データ資産とAI資産のガバナンスシステムとして機能する。

計画されている統合の対象には、Microsoft Entra、Azure Data Lake Storage、OneLake、Power BI、Purview、Foundry、Power Platform、Microsoft 365、Teams、Copilotが含まれる。これは2つの分析ツールをつなぐ限定的なコネクターではない。従業員がすでに業務を行っているアプリケーションへ、ガバナンスを備えたDatabricksのコンテキストを持ち込もうとする取り組みだ。

MicrosoftとDatabricksによれば、数千の組織がAzure Databricksを利用している。両社は既存顧客としてBanco Bradesco、Electrolux、Sumitomo Mitsui Banking Corporation、Unilever、Cincinnati Redsを挙げた。これらの事例はプラットフォームの適用範囲を示すが、新たな統合がどれほど広く本番環境に導入されているかを証明するものではない。

この契約には、共同エンジニアリング、販売、サポートに関する取り組みも含まれる。こうした運用面の詳細はAI機能ほど注目されないが、エンタープライズの購入者にとって重要だ。2社のベンダーがそれぞれ本番システムの一部を担う場合、共通のサポート経路は生じやすい曖昧さを軽減できる。

したがって、最も重要な変化は構造的なものだ。DatabricksはMicrosoftのインフラとワークプレイスアプリケーションにさらに接近し、MicrosoftはDatabricksを主要なコンテキストおよびガバナンス層として受け入れる。この組み合わせは、エンタープライズデータの意味を誰が定義するのかをめぐる、より大きな戦いの舞台を整える。

ビジネスコンテキストがエンタープライズAIのボトルネックとなった理由

エンタープライズエージェントは、データを取得できても、そのデータが特定の組織内で何を意味するかを解釈できなければ失敗する。

汎用モデルは、売上、在庫、解約率、利益率がビジネス上の概念であることを知っている。しかし、ある企業がそれらをどのように算出するかを自動的に把握しているわけではない。また、どのダッシュボードが正式なものか、どの顧客レコードに閲覧制限があるか、どの地域別定義を適用すべきかも推論できない。

この隔たりが、提携でビジネスコンテキストが重視される理由を説明する。企業はすでに、データベース、文書、分析システム、コラボレーションツールに膨大な情報を保存している。より困難な課題は、これらの情報源を共有された定義、権限、リネージ、運用ルールへ結び付けることだ。

危険にさらされているアカウントを特定するよう依頼された営業エージェントを考えてみよう。モデルには契約履歴、サポート活動、製品利用、支払い状況、アカウント所有者の情報が必要になるかもしれない。さらに、企業がリスクをどのように定義するか、どの従業員が各レコードを閲覧できるかを理解しなければならない。

検索だけではこの問題を解決できない。エージェントは関連文書を見つけられても、古い指標、権限のない項目、互換性のない定義を組み合わせてしまう可能性がある。流暢な回答はこうした失敗を隠し、不正確な応答を実際以上に信頼できるものに見せてしまう。

Genie Ontologyは、Databricksが提示する回答だ。Databricksはこれを、ガバナンスされたエンタープライズデータからビジネス概念と関係性を学習するコンテキスト層と説明している。エージェントにエンティティ、指標、用語、信頼できる情報源への一貫した理解を与えることを目指す。

Unity Catalogはガバナンスの基盤を提供する。MicrosoftのUnity Catalogドキュメントによると、アクセス制御、リネージ、監査、分類、品質監視、AIガバナンスを管理する。これらの制御は、テーブル、ファイル、モデル、関数、AIサービスを対象とする。

この組み合わせが重要なのは、権限のないオントロジーでは機密性の高いコンテキストを公開しかねないためだ。一方で、セマンティックな意味を持たないガバナンスは、アクセスを制限できても不整合な回答を許してしまう。Databricksは両方の層を同じリクエスト経路に結び付けようとしている。

Microsoftも自社製品を通じて同様の結論に達している。Microsoft 365 Copilotはワークプレイス活動からコンテキストを取得し、FabricとOneLakeはエンタープライズデータを整理する。Purviewはガバナンス機能を提供し、EntraはID管理を担う。

この提携は、単一の情報源だけではビジネスの全体像を得られないことを認めている。顧客レコードは業務データベースに、財務上の定義は分析モデルに、手順はSharePointに、最新の議論はTeamsに存在するかもしれない。有用なエージェントには、こうした境界をまたぐ権限を考慮したアクセスが必要だ。

これこそ、この話題がGoogle Newsを通じて得る注目を超えて重要である理由だ。この提携は、より大きなベンチマークスコアを持つ単一モデルを発表したわけではない。実際の企業内でエージェントが説明可能な回答を生み出せるかを決める、目立たないシステム群を組み合わせている。

このアプローチは、企業がAIの品質を評価する方法も変える。購入者は、エージェントの応答が正確に聞こえるかだけで判断できない。どの情報源を使用したのか、どの定義を適用したのか、データがいつ変更されたのか、ユーザーに閲覧権限があったのかを把握する必要がある。

この要件により、ビジネスコンテキストはインフラになる。製品、チーム、レポーティング構造が変化しても、定義と関係性は最新に保たれなければならない。権限は従業員、サービスアカウント、エージェントに追随する必要がある。監査証跡は、アクションを、それを形成したデータとポリシーに結び付けなければならない。

運用上の負担は大きい。当初は正確だったオントロジーも、チームが新しい指標を作成したり既存の指標名を変更したりすると劣化する可能性がある。ガバナンスされたカタログにも、競合する資産が含まれ得る。組織には、エージェントが承認済みの知識を使用しているかを検証する所有者、レビュー工程、評価セットが必要だ。

ナレッジワーカーにとっても、同じ原則がより小さな規模で当てはまる。AIは、信頼できる情報源をプロジェクトを取り巻くコンテキストと組み合わせられると、より有用になる。構造化されたナレッジブレンディングのワークフローは、取得したすべての項目を同じ信頼性のものとして扱うことなく、関連資料をつなげるのに役立つ。

MicrosoftとDatabricksは、企業が組織規模で同様の投資を行うと見込んでいる。アプリケーションを横断してコンテキスト、ガバナンス、ID管理を維持するプラットフォームは、その上に構築されるすべてのエージェントに対する影響力を得る。

Google Newsが浮き彫りにするエンタープライズ管理プレーンをめぐる争い

主な競争はMicrosoft対Databricksではなく、統合されたコンテキストスタック対断片化したエンタープライズデータシステムである。

「エンタープライズ管理プレーン」という表現は、データとAIシステム全体にわたり、権限、定義、ルーティング、監視、ポリシーを設定する層を指す。MicrosoftとDatabricksは、両社の統合技術にその役割を担わせたい考えだ。課題は、これらのコンポーネントが管理可能な単一システムとして動作することを証明する点にある。

統合には複数の実用的な経路がある。Genieは、自然言語によるデータアクセスをTeamsやMicrosoft 365 Copilotにもたらすことができる。Unity AI Gatewayはモデルとエージェントのトラフィックを統制できる。OneLakeは、別途コピーを作成することなく、Microsoft FabricのデータをDatabricksに公開できる。

MicrosoftのOneLakeフェデレーションガイドでは、Azure DatabricksがUnity Catalogを通じて対応するOneLakeデータを照会できると説明されている。現在のフェデレーションは読み取り専用であり、複数のID、ワークスペース、テナント設定を必要とする。

こうした制限は、戦略的ビジョンと実運用の導入の違いを示している。製品発表ではデータが統合されていると説明できる。しかし管理者は依然として、ID、認証情報、カタログ権限、ネットワークアクセス、ワークスペースポリシーを設定しなければならない。

それでも、コピーを作成しないアプローチは現実的な懸念に対応する。エンタープライズデータを複数プラットフォーム間で複製すると、ストレージ、同期、ガバナンス、セキュリティに関する作業が増える。フェデレーションにより、あるシステムが別のシステムで管理されるデータを照会できるが、パフォーマンスと可用性への依存関係が生じる可能性がある。

この提携は、競合するクラウドおよびデータプラットフォームにも圧力をかける。Snowflakeはクラウドデータウェアハウスから、アプリケーション、ガバナンス、エンタープライズAIへと事業を拡大している。Google CloudはBigQuery、Vertex AI、Gemini、自社のデータガバナンス技術を組み合わせる。Amazon Web Servicesは幅広い分析ポートフォリオとともにBedrockを提供している。

これらの競合各社は、同じ戦略目標を共有している。いずれも、顧客がすでに使っているデータ、IDシステム、統制の近くでエンタープライズエージェントを動かしたい考えだ。デフォルトのコンテキストレイヤーとなるベンダーは、モデル選定、アプリケーション開発、インフラ投資に影響を及ぼせる。

Databricksは主要クラウドをまたいで稼働するため、この競争を複雑にしている。顧客がDatabricksを選ぶ理由の一つは、すべてのデータワークロードを単一のクラウドネイティブな分析スタックに縛り付けないためでもある。Azureとの統合深化には利点がある一方、同等の機能が他の環境でも維持されるかを買い手は注視するだろう。

Microsoftも同様の緊張関係に直面している。Fabric、Power BI、OneLake、Purview、Copilotはすでに幅広いデータおよびAIプラットフォームを構成している。Databricksをこのスタックにより深く組み込むことで、顧客は確立されたレイクハウスとデータエンジニアリングのツールを利用できる。その一方で、カタログ、セマンティックモデル、インターフェース、ガバナンス責任の重複も生じる。

たとえばPower BIのチームは、すでに認定済みの指標とセマンティックモデルを維持しているかもしれない。Databricksのチームは、関連するロジックをメトリックビューやGenie Ontologyで定義している可能性がある。明確な所有責任がなければ、適切に統制された二つのシステムでも、同じ経営上の質問に異なる答えを出しかねない。

この提携の成否は、その重複をどう解消するかにかかっている。複数のツールを一つのポータルに置くだけの統合では、共有コンテキストは生まれない。リクエストがプラットフォームの境界をまたぐ際にも、製品は定義、権限、リネージを維持しなければならない。

Microsoftによると、単一のModel Context Protocol接続によって、Copilot StudioとGitHub CopilotのエージェントがAzure Databricksワークスペースの情報を踏まえて推論できるようになる。MCPは、AIアプリケーションがツールとコンテキストを要求するための標準インターフェースである。コネクター作業を減らせる可能性はあるが、共通プロトコルだけでポリシー設計が不要になるわけではない。

MCPで公開される各機能には、依然として認可モデルが必要だ。企業は、どのエージェントがどのサービスを呼び出せるか、どのデータを取得できるか、そしてアクションを実行できるかを決めなければならない。また、接続されたコンテンツに埋め込まれた悪意ある指示への防御も必要になる。

これこそが、Google Newsの見出しの下にある、より本質的な競争だ。両社は単にMicrosoft製品を通じてDatabricksの機能を提供しようとしているのではない。エンタープライズデータとAI主導の業務の間に、共有された意思決定レイヤーを確立しようとしている。

このレイヤーが機能すれば、従業員はTeamsで質問し、承認済みのDatabricksデータに基づく回答を得られる可能性がある。各コンポーネントを理解することをユーザーに求めずに、Entra ID、Unity Catalogの権限、社内定義、Microsoftアプリケーションのコンテキストを適用できる。

失敗すれば、従業員は一貫性のないデータの上に重ねられた、また一つの洗練されたインターフェースに直面することになる。管理者は重複したポリシーを管理することになり、セキュリティチームは、なぜエージェントが特定の結果を返したのかを再構成するのに苦労するだろう。その違いは統合図ではなく、本番環境での証拠によって明らかになる。

統合の深化はリスクも集中させる

エージェントをより豊富なビジネスコンテキストへ接続すれば有用性は高まるが、権限、定義、アクションに誤りがあった場合の影響も大きくなる。

両社は、統制、選択肢、コスト効率を強調している。ただし、これらは確立済みの成果ではなく、目標として扱うべきだ。より深い提携は統合作業を減らし得る一方、Microsoft-Databricksの統合アーキテクチャへの依存を高める可能性がある。

最初の懸念はガバナンスの複雑さだ。企業はEntra ID、Purviewの分類、Unity Catalogの権限、OneLakeの設定、Power BIのアクセス許可、アプリケーション固有の統制を連携させる必要があるかもしれない。各製品が適切に設計されていても、統合されたポリシー全体を監査するのは難しいままであり得る。

権限の不整合は、直接的なセキュリティリスクとなる。従業員は地域別売上についてエージェントに尋ねる権限を持っていても、個々の顧客の詳細にはアクセスできない場合がある。エージェントは、データを取得し、結果を要約し、ツールを呼び出し、別のモデルにコンテキストを渡す際にも、その境界を維持しなければならない。

自律型エージェントがユーザーに代わって行動する場合、ID管理はさらに複雑になる。組織は、従業員の権限と、エージェントのサービスIDおよび委任権限を区別しなければならない。誰がアクションを開始し、どのシステムがそれを承認したのかを示す記録も必要になる。

セマンティックな誤りは別種の問題を生む。Genie Ontologyはビジネス概念を信頼できるデータに対応付けることを目指すが、企業があらゆる指標について争いのない単一の定義を維持していることはほとんどない。財務、営業、製品の各チームは、正当な理由から類似した指標を異なる方法で算出することが多い。

エージェントに必要なのは、「アクティブ顧客」のようなラベルだけではない。適用される事業部門、報告期間、除外条件、ソースシステム、定義の責任者も必要だ。こうした詳細がなければ、共有オントロジーは意見の相違を解消するのではなく、隠してしまう可能性がある。

鮮度も別のリスクとなる。チームの再編、製品の投入、契約の満了、ポリシーの変化に伴い、ビジネスコンテキストは変化する。統制されていても古い情報に基づくエージェントは、追跡可能でありながら誤った回答を生成しかねない。

コスト管理にも独立した検証が必要だ。Unity AI Gatewayは、モデルとエージェントの利用状況を追跡・統制するために設計されている。しかし、エージェントをより多くの職場向け画面に組み込むことで、総リクエスト数は増える可能性がある。利便性によって、集中ルーティングが節約を生むより速く、新たな利用が生まれるかもしれない。

インフラに関する主張にも同様の慎重さが求められる。Microsoftによる、Cobalt 200が最大50%高い性能を提供するという説明は、すべてのDatabricks顧客がその結果を得ることを示すものではない。買い手には、レイテンシ、スループット、メモリ、信頼性、総リソース使用量を対象とした、ワークロード固有のベンチマークが必要だ。

Microsoftが引用した、同社委託のForrester調査では、複合的なAzure Databricks導入組織が3年間で331%のリターンを得たと報告されている。Microsoftは、モデル化された結果がすべての顧客を代表するものではないと注記している。この種の調査は計画の参考にはなるが、買い手自身によるワークロードと移行の分析を置き換えるべきではない。

独立したベンチマークは、その構成が対象環境に近い場合により有用となる。Microsoftは、Azure DatabricksとAWS上のDatabricksを比較した10テラバイトの意思決定支援テストも引用している。インスタンス選定、オートスケーリング、データレイアウト、ネットワーク、ワークロード構成の違いは、こうした比較を大きく変え得る。

より広い商業上の問題は、ベンダー集中だ。拡大された契約は2030年代まで続き、ロードマップの安定性を示唆している。同時に、インフラ、分析、ガバナンス、コンテキスト、職場からのアクセスを、密接に結び付いた一組のベンダーに集約するよう企業を促す。

この集中は、サポートと調達を簡素化し得る。しかし、切り替えコストを高める可能性もある。移行時にはテーブルを転送するだけでは済まず、ポリシー、セマンティック定義、エージェントツール、アプリケーション統合、評価プロセスもともに移す必要があるためだ。

Databricksのマルチクラウドという立場は、部分的な対抗力となる。Unity Catalogなどのプラットフォームコンポーネントは、単一サービスの外にある資産の管理を顧客に支援できる。それでも、最も深いMicrosoft統合は当然ながらAzureで最も機能しやすく、クラウド間に実務上の差を生み出す可能性がある。

今回の発表には、これらの問いを決着させるのに十分な本番環境の証拠がない。Azure Databricksを利用する顧客の名前は挙げられているが、Genie Ontology、Unity AI Gateway、新たな製品横断体験の導入状況は定量化されていない。コンテキストに基づくエージェントのエラー率も公表していない。

エンタープライズの買い手は、タスクレベルの証拠を求めるべきだ。システムは、定義済みの一連の業務上の質問に一貫して答えられるか。不正なリクエストを拒否するか。監査担当者は、各回答に使われたソース、権限、モデル、ビジネス定義を再現できるか。

また、失敗時の挙動も試験すべきだ。信頼できるエージェントは、欠損データ、矛盾する定義、古いソース、取り消されたアクセス権、利用できないサービスに対応しなければならない。理想的な条件下での高精度は、通常の企業変化の中で安全に稼働することを示すものではない。

したがって重要なリスクは、MicrosoftとDatabricksに技術がないことではない。統合の広がりが、組織が生じたシステムを統制する能力を上回ることにある。ビジネスコンテキストがAIを改善するのは、その意味に対して誰かが責任を持ち続ける場合に限られる。

エンタープライズの買い手が次に注目すべきこと

次の三つのシグナルは、この提携が実用的なコンテキストレイヤーを生み出すのか、それとも密接に売り込まれた統合の集まりにとどまるのかを示す。

最初のシグナルは、Microsoftの業務用画面全体での本番提供状況だ。Azure Databricksのリリースノートによると、Databricks Genieは2026年7月にTeamsでパブリックプレビューに入った。買い手は、一般提供、地域カバレッジ、管理者向け統制、文書化されたサービス制限を注視すべきだ。

プレビュー版はインターフェース設計を示せるが、一般提供では通常、より明確なサポート上の約束と導入時の期待値が示される。Teams、Microsoft 365 Copilot、Foundry内での導入は、Databricksのコンテキストが日常業務に持ち込めるという主張を強めるだろう。

この体験の質は、製品ロゴの数よりも重要だ。MicrosoftとDatabricksは、権限、リネージ、引用、ビジネス定義がリクエスト経路全体で維持されるかを示すべきだ。また、管理者が誤った回答をどのように調査するのかも説明する必要がある。

二つ目のシグナルは、測定可能な顧客導入だ。両社は著名なAzure Databricksユーザーを挙げたものの、拡大された提携にはビジネスコンテキストに焦点を当てた事例研究が必要である。そうした事例では、タスク、データソース、ガバナンスモデル、評価方法、確認された制約を説明すべきだ。

有用な事例では、在庫エージェントを質問から意思決定まで追跡することが考えられる。Genieが社内用語をどう解釈するか、Unity Catalogがアクセスをどう制限するか、OneLakeがどうデータを供給するか、Copilotがどう結果を提示するかを示すものだ。また、情報が矛盾した場合に何が起きるかも報告すべきである。

顧客の証拠は、運用上の指標を含む場合により強固になる。関連する指標には、回答精度、遮断された不正アクセス試行、定義の更新に要する時間、人間へのエスカレーション率、承認済みソースに裏付けられた回答の割合が含まれる。

意思決定が速くなったという逸話は、導入の紹介にはなり得る。しかし、そのアーキテクチャが部門横断かつ変化するデータの中でも信頼性を維持するかを立証することはできない。買い手は、自社のユーザー、権限、用語を反映する評価を期待すべきだ。

三つ目のシグナルは、競合各社の反応である。Google Cloud、AWS、Snowflake、Salesforce、Oracleなどのエンタープライズベンダーは、データ、セマンティクス、ガバナンス、エージェントを独自に組み合わせようとしている。次のリリースによって、Microsoft-Databricksのアプローチが市場の参照点となるかが分かるだろう。

より簡単なクロスプラットフォームのガバナンス、オープンなセマンティック標準、ビジネス定義に照らしてエージェントの挙動を検証するツールに注目したい。また、競合他社が別々のカタログとポリシーシステムを維持する必要性を減らせるかも見極めるべきだ。

オープンなインターフェースが、ロックインを自動的に防ぐわけではない。可搬性は、定義、権限、リネージ、評価、エージェントツールを大規模な再構築なしにシステム間で移せるかどうかにかかっている。競合各社は、これらの資産をより容易に移転できるようにすることで、MicrosoftとDatabricksに圧力をかけられる。

Google Newsは今後も、モデルやエージェントに関する製品発表を取り上げ続けるだろう。企業の意思決定者は見出しの裏側を見極め、コンテキスト、アイデンティティ、ポリシーをどの企業が掌握しているのかを問うべきだ。こうしたレイヤーこそが、印象的なデモが信頼できる業務システムへと発展するかを左右する。

今回拡大された提携により、MicrosoftはDatabricksをAzureのインフラと日常的に使われる業務ソフトウェアへ近づけ、自社の回答を強化する。Databricksにとっても、ガバナンスとコンテキスト技術を数百万人規模の潜在的なビジネスユーザーに近づける強化となる。ただし、いずれも一貫性のある導入を保証するものではない。

実務上の次の一手は、大規模なエージェント施策に取り組む前に、制約を設けたワークフローを1つ検証することだ。承認済みのデータ、明確な定義、既知の権限、測定可能な成果を備えたタスクを選ぶ。そのうえで、通常の依頼、曖昧な質問、古い情報、禁止されたアクセスを試験する。

統合スタックがこうした条件下でも意味とポリシーを維持できるなら、この提携は単なる流通拡大以上の成果をもたらしたことになる。チームが依然として競合する定義や管理策を手作業で突き合わせているなら、ビジネスコンテキストという約束は未完のままだ。次のGoogle News報道は、また別の統合リストではなく、その証拠によって評価されるべきだ。