エンタープライズコンテキストでAI価値を生み出すというAtlanの主張、焦点をモデルの先へ移す
Atlanは、エンタープライズAIにおけるモデル優先のアプローチに異議を唱え、有能なシステムであっても、有用な業務を行うために必要なビジネス理解を欠いていると主張している。10月28日のMIT Technology Review Insightsの記事で扱われた、エンタープライズコンテキストによるAI価値の創出は、この主張を検証の対象とする。組織に必要なのは、もう1つのインフラ層なのか、既存の知識をより適切に管理することなのか、あるいはその両方なのかが問われている。
この主張自体にも商業的な背景がある。この記事はMIT Technology Reviewの報道部門ではなく、カスタムコンテンツ部門によるものだ。Atlanのカンファレンス資料では、関連する調査が同社とともに制作されたものとされている。ベンダーの製品ポジショニングも後押しする診断を評価する際、この関係性は重要である。
MicrosoftのWork IQは有用な比較対象となる。別のサプライヤーも、ビジネスコンテキストを中心にエンタープライズAI戦略を構築しているからだ。中心的な緊張関係は、ベンダー間の競争を超えている。組織は業務を実行できるAIを求めているが、その定義、権限、運用ルールには人間による解釈が必要になることが多い。モデルへのアクセスを購入しても、それらの問題が解決されるわけではない。
エンタープライズコンテキストによるAI価値の創出は、モデルの先へ進む
10月28日のエンタープライズコンテキスト分析は、Atlanが好む視点を通じて、よく知られた導入上の問題を提示している。AIツールは素早く応答できても、対象とするビジネスを誤解する可能性がある。Atlan共同創業者のPrukalpa Sankarは、コンテキストインフラがこの隔たりを埋める助けになると主張する。
コンテキスト層とは、企業データを解釈するために必要なビジネス定義、関係性、ポリシー、その他の情報をAIシステムに提供するインフラである。情報を見つけることと、そのビジネス上の意味を理解することは別の作業であるため、この概念は重要だ。ある文書に回答が含まれていても、その回答が依然として権威あるものかどうかまでは示されない。
今回の動きは、新たに検証された技術的ブレークスルーではなく、エンタープライズAIの価値がどこから生まれるかについて、より明示的に打ち出された商業的主張である。
この区別により、ニュースを適切な規模で捉えられる。この記事は、コンテキストインフラだけがより高い財務的リターンをもたらすことを立証してはいない。期待外れの導入結果を説明し、それに対処する方向性を示している。購入者は、この説明を特定の実装とは分けて評価すべきだ。
例として、営業ワークフローを考えてみよう。アシスタントが顧客レコードを見つけ、最近の会話を要約し、契約更新の提案を作成する。取得した各文書は、それぞれ単独では正確かもしれない。それでも、アシスタントが請求先法人と親会社を混同したり、承認済みの例外を見落としたりすれば、その提案は失敗しうる。
より優れたモデルなら、曖昧さを認識して有用な質問をするかもしれない。適切に維持されたビジネス定義なら、生成が始まる前に曖昧さを解消できるかもしれない。これらのアプローチは補完関係にあるが、失敗の異なる部分に対処する。すべてのミスをモデルの問題として扱うと、その違いが見えなくなる。
したがって、エンタープライズコンテキストによるAI価値の創出は、購買に関する対話を変える。購入者は、どのシステムが最も優れた回答を生み出すかだけでなく、組織内で回答を有効にするものは何かを問わなければならない。そこには、基礎となるルールを誰が承認し、最後にいつ変更されたかも含まれる。
公開における関係性にも注意を払うべきだ。Atlanのコンテキスト研究イベントでは、同社との協力で制作された調査への早期アクセスが宣伝されていた。これは、この主張をベンダー支援による議論への貢献として扱うことを支持する。ただし、根底にある問題を退ける根拠にはならない。
実務上の含意は、広範な営業的メッセージより限定的だ。コンテキストはエンタープライズAI失敗のもっともらしい原因だが、その重要性はワークフローごとに確立されなければならない。組織には依然として、提案された介入と測定可能な改善を結び付ける証拠が必要である。そのつながりがなければ、コンテキストは検証が難しいもう1つの説明にとどまる。
ビジネスオーナーもAI信頼性の問題を引き受ける
コンテキストをめぐる主張は、技術チームだけでなくビジネスオーナーにも負荷をかける。アシスタントが承認済みポリシーを誤解するなら、モデルの変更が役立つかもしれない。部門間でポリシー自体について意見が食い違うなら、ソフトウェアが一貫して適用できるようになる前に、組織がその不一致を解消しなければならない。
エンタープライズAIは、放置されてきた知識の所有責任を運用上の問題に変える。
AI開発者は、どのポリシーが別のポリシーに優先するかを決定する権限がなくても、文書リポジトリを接続できる。セキュリティチームは、財務部門が顧客をどう定義するかを決めずとも、アクセス制限を施行できる。これらの責任は交差するが、同じ人物に属するものではない。
これは、会話型インターフェースを導入するのとは異なる実装負担を生む。誰かが権威ある情報源を特定し、所有者を割り当て、例外を文書化し、それらの決定を維持しなければならない。この作業によって、従業員がこれまで非公式な会話で処理してきた意見の相違が表面化する可能性がある。自動化により、そうした不一致を未解決のまま放置することは難しくなる。
財務責任者にとっての圧力は、一貫性に関するものだ。収益について回答するアシスタントには、適切な会計定義、報告期間、組織的な対象範囲が必要である。流暢な説明も、誤った指標を選べば埋め合わせにはならない。ビジネスオーナーは、意図された解釈を利用可能かつレビュー可能な状態にしなければならない。
サービス責任者にとっての圧力は、適用可能性に関するものだ。エージェント、すなわち業務を完了するために手順を選択したりツールを使用したりするAIシステムには、関連する顧客の状況が必要である。有効な返金ポリシーは、契約や地域によって異なる場合がある。一般的なポリシーを取得することは、意思決定の一部にすぎない。
これらの例は、報告された顧客成果ではなく、説明のためのものだ。ソフトウェアが文章の下書きから行動の推奨へと進む際に、コンテキストの所有責任がなぜ重要になるのかを示している。誤った要約は修正作業を生む。誤った行動は、別のチームが解消しなければならない義務も生み出しかねない。
調達チームも関連する課題に直面する。コンテキストプラットフォームは共通定義を約束できるが、契約によって部門間の合意を保証することはできない。購入者は、サプライヤーの責任と組織の責任を区別する必要がある。さもなければ、インフラの購入によって、未完了の運用上の意思決定が隠される可能性がある。
ナレッジワーカーも、より小さな規模で同じ問題を経験する。検索可能なアーカイブは人々が資料を見つけるのに役立つ一方、権威あるナレッジベースは、どの資料が業務の指針となるべきかを定める。個人とチームの知識の区別は、個人の記憶が共有の意思決定に影響する場面で重要になる。
短期的な対応は、対処する失敗に従うべきである。情報源の資料が不足しているなら、より良いカバレッジが必要になる。定義が対立しているなら、所有責任と解決が必要になる。推論が誤っているなら、モデルやアプリケーションの変更が必要になる。これらのカテゴリを単一の正確性スコアにまとめると、どこに介入が必要かを見えにくくする可能性がある。
時間の経過とともに、焦点は保守へ移る。ビジネスコンテキストは、製品、契約、チーム、ポリシーの変化に伴って変化する。導入時には良好に機能していた仕組みでも、モデル更新がなくても信頼性を失う可能性がある。したがってコンテキストをめぐる主張は、継続的な運用責任に関する主張でもある。
Microsoftはコンテキストがプラットフォームの問題になりつつある理由を示す
Microsoftは、エンタープライズコンテキストも共有インフラとして説明しているため、具体的な比較対象となる。6月11日に公開した社内でのWork IQ活用に関する説明で、同社は組織内の情報が、より関連性の高いAI応答をどのように支えるかを示している。コンテキストをアシスタントを取り巻く環境の一部として位置付けている。
Microsoftによれば、Work IQは職場のシグナルを利用し、既存の権限を尊重する。同社の社内例には、会議情報と参加者を結び付けることや、従業員の状況をガイダンスに適用することが含まれる。これらは事業リターンを独立して測定したものではなく、同社が報告した例である。それでも、同じ一般的な問題に取り組むサプライヤーの姿勢を示している。
競争上の問いは、ビジネス理解をどこに置くべきか、そしてどれほど広く再利用できるかにある。
Microsoftの職場インテリジェンスのアプローチでは、コンテキストは同社の職場環境内で発展するものとして説明されている。Atlanの主張は、システム横断でビジネス理解を提供することに重点を置く。両サプライヤーが類似した表現を用いる場合でも、これらの立場は購入者に異なる問いをもたらす。
特定のソフトウェア環境に集中している組織にとって、そこに組み込まれたコンテキストは自然な出発点になりうる。既存の文書、ID、コラボレーション記録がすでに近くにあるからだ。それでも購入者は、どの情報源が対象となっているか、また導かれた解釈がその環境を超えて適用できるかを確認する必要がある。
複数の業務システムを使う組織では、再利用がより重要になる。財務アシスタント向けに維持される定義が、オペレーションアシスタントで使われる定義と知らないうちに乖離すべきではない。共有コンテキストは、その重複を減らすことを約束する。成功するかどうかは、統合とガバナンスの詳細に左右される。
これは、集中型アーキテクチャと分散型アーキテクチャの単純な対決ではない。アーキテクチャとは、コンポーネントとその責任の配置である。中央サービスが古くなった定義を配布することもありうる一方、アプリケーション固有のコンテキストが限定された範囲内で正確さを保つこともある。配置だけでは品質は決まらない。
より有用な比較は、変更に関するものだ。定義が変わったとき、どのアプリケーションが更新を受け取るのか。アクセスが取り消されたとき、どの保存済み表現がその情報の露出を止めるのか。回答に異議が唱えられたとき、レビュー担当者は使用された情報源とルールを再構築できるのか。これらの問いは、プラットフォーム設計と運用上の結果を結び付ける。
ポータビリティにも注意を払うべきだ。購入者は、承認済みの定義を所有責任、バージョン履歴、アクセス制限を失わずにツール間で移動できるかを問うべきである。テキストをエクスポートすることは、その権威性を維持することより容易だ。言葉を残しても適用可能性を失う移行は、元の問題を再現しかねない。
したがって、このベンダー比較は、いずれかのサプライヤーのアプローチが優れていると立証することなく、より広い判断を支える。複数のアプリケーションが同じビジネス理解を必要とするため、コンテキストはプラットフォームの責任になりつつある。それは共有インフラの機会を生む一方、多くのアプリケーションが共通の誤りに依存するリスクも伴う。
購入者にとって有用な対応は、実際の組織的境界をまたぐワークフローを検証することだ。整然とした文書コレクションに限定されたデモでは、中心的な問いに答えられない。重要な証拠は、情報が部門、アプリケーション、意思決定の所有者の間を移動する際にも、コンテキストが一貫性を保つかどうかである。
検索の証拠は、より限定的な主張を支える
検索拡張生成（RAG）は、モデルが回答する前に関連情報を取得して提供する手法です。生成された応答を外部知識と結び付ける確立された方法であり、その限界は、エンタープライズコンテキストをめぐる議論が注目を集める理由の一端を説明しています。
Anthropicが2024年9月に発表した研究は、技術的な例を示しています。同社のContextual Retrievalは、ドキュメントの断片をインデックス化する前に説明情報を追加する手法です。目的は、文章が元のドキュメントから切り離された際に失われ得る意味を保持することにあります。
Anthropicは、コンテキスト技術を組み合わせることで検索失敗が49%減少し、さらにリランキングを加えると67%減少したと報告しました。リランキングとは、取得した資料を関連性に応じて並べ替える二次的な選別工程です。これらは企業の評価に基づく結果であり、エンタープライズの財務リターンを測定したものではありません。
より良い検索はコンテキストに関する主張を支えますが、包括的なエンタープライズコンテキストプラットフォームが必要であることまでは立証しません。
Contextual Retrievalの研究は、断片に周辺の意味が欠けるためにシステムが関連情報を見落とすという、特定の失敗を扱っています。これは、相反する社内ポリシーを解決することよりも限定的です。また、ユーザーがある操作を実行する権限を持つかどうかを判断することよりも限定的です。
この区別は購買判断において重要です。サポートアシスタントが、ドキュメント断片に識別情報がないために回答を見落とすなら、検索の改善を検討する価値があります。正しい箇所を見つけてもそれを誤って適用するなら、失敗は別の場所で起きています。幅広いインフラ提案は、どの失敗に対処するのかを説明すべきです。
契約の例を考えると、この分離はより明確になります。ある文章には顧客が例外の対象であると記されていますが、顧客名は前のページにあります。その関係を保持すれば、検索を改善できる可能性があります。しかし、その例外が現在も有効かを確立するには、日付、改訂、権限に関する追加情報が必要です。
したがって、システムは正確に検索できても、誤った業務上の推奨を出す可能性があります。逆に、限定的で適切に保守された情報源を用いるワークフローであれば、大規模な共有コンテキストサービスなしでも十分に機能するかもしれません。適切な介入は、実際のタスク、情報要件、失敗した場合の影響によって決まります。
エンタープライズコンテキストによるAI価値の創出は、この依存関係の連鎖を通じて評価すべきです。情報源の網羅性はシステムが何を見つけられるかに影響します。情報源の解釈は何を理解するかに影響します。意思決定ルールは何を推奨するかに影響します。アクション制御は何を実行できるかに影響します。一部の改善が、全体にわたる改善を自動的に意味するわけではありません。
この考え方は、デモンストレーションの読み方も変えます。成功した回答は、特定の構成が特定の条件下で特定の質問を扱えたことを示すにすぎません。部門をまたぐ一般的な信頼性を示すものではありません。購入者には、曖昧な入力、変更されたポリシー、相反する情報源を含む証拠が必要です。
最も強い技術的根拠は、元の失敗、コンテキストへの介入、そして生じた差異を特定します。モデルとタスクを比較可能な状態に保つことは、何が変化したのかを切り分ける助けになります。検索の成功を意思決定の正確性と分けて報告すれば、結果を解釈しやすくなり、限定的な改善がより広範な主張へと膨らむことを防げます。
より多くのコンテキストは、誤った回答をさらに広げる可能性がある
懐疑的な見方は、単純な問題から始まります。業務コンテキストは誤っている可能性があります。共有された定義は、古い、不完全、または争いのあるものであるかもしれません。それを一貫して提供すると、出力の整合性は高まっても、誤りは残る可能性があります。一致は一貫性を示す有用な証拠ですが、真実を示す十分な証拠ではありません。
コンテキスト層は、その権限が正当であることを確立せずに、権威を配布してしまう可能性があります。
これは、組織が非公式な知識を保守対象のルールへと変換する際に重要になります。経験豊富な従業員は、文書化されたプロセスが状況に適合しない場合を知っていることがあります。その判断をエンコードするには、どの例外が正当かを決めなければなりません。会話から文言を自動抽出しても、それをポリシーにすべきかどうかは決まりません。
会議の参加者が一時的な回避策を説明するかもしれません。別の従業員が古い慣行を繰り返すかもしれません。プロジェクト文書に、放棄された提案が記録されているかもしれません。それぞれの情報源は情報を提供しますが、権威の度合いは異なります。これらを同等に扱うと、生成が始まる前にガバナンスの問題が生じます。
モデルレベルの制約もあります。NISTの生成AIリスクプロファイルは、自信をもって生成される虚偽または誤ったコンテンツを意味する「confabulation」を、特徴的なリスクとして説明しています。また、生成された説明や引用がユーザーを誤解させる可能性も指摘しています。関連する情報源があるからといって、出力を評価する必要性がなくなるわけではありません。
NISTの分析は、コンテキスト論を慎重に解釈することを支持します。より良い情報は知識の欠落に対処し得ますが、正しい推論を保証するものではありません。システムは有効なルールを誤って適用したり、不確実な推論を過度に断定したりする可能性があります。コンテキストの品質と出力の信頼性には関連がありますが、異なる観点からの検証が必要です。
権限はもう一つの重要な論点です。従業員が文書を読めるからといって、自動化システムがその内容に基づいて行動することまで許可されているとは限りません。コンテキストサービスは、下流のアクションを管理する制御と明確に結び付いている必要があります。そうでなければ、正確な情報が権限のない意思決定を支えてしまう可能性があります。
財務面の根拠も依然として不確実です。定義の維持、異議の解決、権限の確認、失敗のレビューには、いずれもスタッフの時間が必要です。その作業の一部は、AIを超えて既存プロセスを改善するかもしれません。それでも購入者は、導入の経済性を判断する際にそのコストを考慮すべきです。
組織は回答を改善しながら、それを生み出す総作業量を増やしてしまう可能性があります。一方で、レビュー工数を十分に削減し、大規模な保守を正当化できる組織もあるでしょう。意味のある比較には、生成の目に見える速度ではなく、ワークフロー全体を含める必要があります。これは分析上の要件であり、元記事が報告した成果ではありません。
エンタープライズコンテキストによるAI価値の創出には、限界を受け入れることも必要です。ポリシーの対立が未解決のままであれば、有用なアシスタントはその対立を明示すべきです。権限が不明確であれば、適切に判断を回付すべきです。常に自信のある回答を出すシステムは、コンテキストインフラが明らかにすべき組織上の不確実性そのものを隠してしまう可能性があります。
したがって、懐疑的な立場はコンテキスト投資の否定を必要としません。必要なのは、その投資が何を変えるのかについて、より具体的な主張です。サプライヤーは、どのエラーの頻度が下がるのか、どの責任が顧客に残るのか、どの失敗モードが続くのかを明らかにすべきです。そうすることで、提案は検証可能になります。
次の証拠は、コンテキストと完了した業務を結び付けるべきだ
今後数か月で最も有用な兆候は、新たな用語ではなく導入に関する証拠でしょう。10月の議論は、モデル能力と並んで業務理解にもっと注意を払うべきだという明確な命題を提示しています。次の段階は、その命題がどこで測定可能な利益を生むのかを判断することです。
保守された業務知識が変化する状況下で完了した業務を改善するとき、コンテキスト論はより強くなります。
最初の兆候は、実際のワークフロー内で記録された比較です。購入者は、定義されたコンテキスト介入の前後に何が起きたかを示す結果を探すべきです。その比較には、情報源の誤り、意思決定の誤り、人による修正、完了したタスクを含めるべきです。改善を切り分けた結果であれば、その主張を強めることになります。
選ばれた成功事例の回答だけを示すデモンストレーションでは、中心的な不確実性は残ります。モデル、インターフェース、情報源の収集、レビュー工程を同時に変更する比較も同様です。こうした変更は製品を改善し得ますが、エンタープライズコンテキストの寄与を分離することを難しくします。
次の兆候は、業務変更後の信頼できる振る舞いです。ポリシー改訂、権限の取り消し、顧客名の変更は、有用な観察点を作ります。システムは影響を受けるアプリケーション全体で変更を反映するでしょうか。以前の回答を説明できるだけの履歴を保持するでしょうか。一貫した挙動は、共有インフラの必要性を支えることになります。
矛盾が続けば、この主張は弱まります。すべてのアプリケーションが依然として手作業での修復を必要とするなら、提案された共通層は重複した保守を排除していません。古い情報が派生ストアに残るなら、組織は修正がどのように伝播するのかを理解する必要があります。初期設定の品質だけでは、これらの問いに答えられません。
最後の兆候は、総運用負荷です。組織は、コンテキスト保守を考慮した後に、レビュー担当者が出力の修正に費やす時間が減るかどうかを確認すべきです。また、未解決の案件が適切な担当者に届くかも追跡すべきです。隠れた準備作業の増加がそれを上回るなら、目に見えるレビュー作業の削減に意味はほとんどありません。
これらの兆候は、特定のサプライヤーが勝利することに依存しません。Microsoft、Atlan、アプリケーション開発者は、それぞれ異なるアプローチで証拠を提供できます。有用な区別は、利用可能な機能についての主張と、継続的な利用についての観察との間にあります。購入者には両方が必要ですが、混同すべきではありません。
ナレッジワーカーにとって、目先の関連性は実用的です。情報の所在を知るアシスタントは、検索の手間を減らせます。どの情報が適用されるかを理解するアシスタントは、意思決定を支援できます。その追加的な理解の価値は、ユーザーがそれを確認し、異議を唱え、保守できるかどうかに左右されます。
誤った回答が明確な手戻りにつながるワークフローから始めてください。あらゆる修正をプロンプトの問題として扱うのではなく、基礎となるポリシーを所有する人々と失敗を見直してください。情報の欠落を、定義の対立、推論の誤り、不適切なアクションから切り分けてください。そのうえで、提案されているコンテキスト投資がその特定の失敗に対処するかを検討してください。個人の業務では、保守されたパーソナルナレッジシステムが関連資料の整理に役立ちますが、共有の意思決定には依然として共有された権限が必要です。この区別が導入後も維持されるとき、エンタープライズコンテキストによるAI価値の創出は信頼できる命題となります。次のサプライヤーには、変更されたルール、異議のある情報源、そして未解決のままにすべき判断を、そのシステムがどのように扱うのかを示すよう求めてください。
