Alessandro Cotrufo、エンタープライズAI最大の課題はコンテキストだと語る

Alessandro Cotrufoは、モデルを最優先するエンタープライズAIの定石に異議を唱え、Google Newsの見出しはその立場を一つの明確な対立軸に集約している。より優れたモデルは主要な制約ではない。より困難なのは、AIが回答や行動を求められる際に、新鮮で関連性が高く、統制されたビジネスコンテキストを与えることだ。

Carroll County Mirror-Democratに帰属するこの見出しは、Cotrufoの発言について独立して検証できる詳細をほとんど提供していない。ただし、彼の公開活動はRedisとの関わりを示し、一貫して同じコンテキスト優先の主張を展開している。Redisもまた、本番環境のAIエージェントに向けた近年の製品戦略に、この立場を組み込んでいる。

この区別は重要だ。企業は長年にわたり、OpenAI、Google、Anthropic、Metaなどのプロバイダーが提供するモデルを比較してきた。Cotrufoの主張は、ベンチマークスコアから、それらのモデルを取り巻くシステムへと検証の焦点を移す。彼が正しければ、モデルを変えても、欠落した記録、古いポリシー、壊れた権限設定、文書化されていない意思決定は修復できない。

これは、モデルがもはや重要ではないという主張ではない。モデルの品質は依然として、推論、指示追従、ツール利用、出力の正確性に影響する。ここでの転換は、モデル選定が、はるかに大きな信頼性の問題を構成する一要素として見られるようになっていることだ。

Google Newsの見出しが示す、より広範なRedisの戦略

最も重要な進展は新しい基盤モデルではない。エンタープライズコンテキストを明確なインフラストラクチャカテゴリーへと変えようとする取り組みが広がっていることだ。

Google Newsの元の掲載は、Cotrufoの見解を従来のエンタープライズAIの優先順位に対する直接的な挑戦として位置付けていた。しかし、その元記事は配信された見出し以外では検証が難しい。したがって読者は、特にアクセス可能な一次情報で裏付けられていない詳細について、正確な帰属を慎重に扱うべきだ。

Cotrufoの公開投稿は、より広い立場を示す強い証拠となっている。彼の活動では、エージェントは知能の問題ではなくコンテキストの問題を抱えていると説明されている。また、本番環境のAIはデータ、特徴量、意思決定をリアルタイムで一貫させることに依存すると主張している。

この表現は、Redisの現在の製品方針と密接に一致する。2026年5月、同社はエージェントを断片化されたエンタープライズデータに接続するためのコンテキストおよびメモリシステムとしてRedis Irisを発表した。Redisはコンテキストエンジンを、エージェントとその行動に必要な情報の間にあるレイヤーと説明している。

同社のコンテキストエンジンのドキュメントには、4つのマネージドサービスが挙げられている。LangCacheは意味的に類似したプロンプトへの応答を再利用する。Agent Memoryは短期および長期の情報を保持する。Context Retrieverはエージェントにビジネスデータへの構造化されたアクセスを提供する。Data Integrationはリレーショナルデータベースからの変更を同期する。

このアーキテクチャは、Cotrufoの主張を具体的な商業的テーゼへと転換する。モデルが推論できるのは、特定の推論ステップで利用可能な情報に限られる。最新の返金ポリシーがアクセス不能なシステムに閉じ込められているなら、より優れた推論でも魔法のようにそれを取得することはできない。

同じ制約は、エージェントが矛盾する記録に直面する場合にも当てはまる。顧客データベースではある人物がアカウント所有者として表示され、サポートプラットフォームでは別の人物が表示されるかもしれない。メールスレッドには最新の例外対応が記されていても、正式なシステムには記録されていない場合がある。

モデルはこうした矛盾をめぐって流暢な文章を生成できる。しかし、周辺アーキテクチャがそのルールを提供しない限り、どのシステムに権威があるかを独力で判断することはできない。したがってコンテキストには、単なる追加テキストではなく、意味、所有権、権限、タイミング、来歴が含まれる。

ここに本記事の中心的な緊張関係がある。モデルベンダーは汎用能力を向上させ続ける一方で、エンタープライズ導入では非公開の運用条件に起因する障害に直面する。そうした条件は企業ごとに異なり、しばしばモデルのトレーニングサイクルより速く変化する。

Google Newsはこの主張を簡潔な見出しにしたが、より重要なシグナルを提供したのはRedisだ。同社はコンテキスト処理を、カスタム統合の寄せ集めではなく、協調された本番環境レイヤーとして位置付けている。

この枠組みはRedis自身の利益にもなる。同社は状態を保存し、情報を取得し、データを高速に移動させるインフラを販売している。その診断を、単一のプラットフォームがすべてのコンテキスト障害を解決するという中立的な証明と混同すべきではない。

それでも、根底にある問題は一社のベンダーを超えている。Google Cloudは現在、AIコンテキストエンジニアリングを、AIシステムが利用するデータ環境とメモリを設計することと定義している。この独立した足並みの一致は、このカテゴリーが主流のエンタープライズアーキテクチャの一部になりつつあることを示唆する。

つまりニュースは、重点の変化だ。企業は、どのモデルが最も賢いかを問うことから、どの情報が、どのルールの下で、どの瞬間にモデルへ届くのかを問う方向へ移行している。

モデルのアップグレードでは、欠落したビジネス知識を修復できない理由

より強力なモデルはより良く推論できるが、企業が一度も提供していない非公開の事実に基づいて推論することはできない。

基盤モデルは、大規模なトレーニングコレクションから幅広いパターンを学習する。そのため、一般的な文章作成、コーディング、要約、分析に役立つ。しかし、企業の最新契約、内部API、承認ルール、顧客履歴を自動的に把握できるわけではない。

返金依頼を処理するサポートエージェントを考えてみよう。モデルは一般的な小売慣行を知っており、説得力のある応答を作成できるかもしれない。その有用性は、適用されるポリシー、購入記録、製品カテゴリー、顧客ステータス、承認済みの例外対応を受け取れるかどうかに依存する。

ポリシー文書の欠落は一つの障害モードを生む。古いコピーも別の障害を生む。過剰な検索は、無関係な資料の中に決定的な段落を埋もれさせ、より大きなコンテキストウィンドウの有用性を期待ほど高められないこともある。

コンテキストエンジニアリングは、この選択の問題に対処する。これは、推論時にモデルが受け取る指示、記録、メモリ、ツールの説明、運用状態を組み立てるプロセスだ。目的はすべてを提供することではない。次の意思決定を支える、最小限で信頼できるセットを提供することだ。

AIシステムが複数のステップにまたがって行動する場合、この要件はさらに難しくなる。従来のチャットボットは一つの独立した質問に答えられる。エージェントは、アカウントを調べ、ポリシーを比較し、承認を要求し、チケットを更新し、顧客に通知するかもしれない。

各ステップで関連する状態は変化する。エージェントはすでに確認した内容を記憶し、新しいデータを認識し、同じ行動を繰り返さないようにしなければならない。また、読み取れる情報と実行できる操作の境界も維持する必要がある。

より大きなモデルでも、こうしたエンジニアリング上の責務はなくならない。曖昧な指示からより適切に回復できる可能性はあるが、依然として有効な認証情報と、完了したアクションの信頼できる記録を必要とする。

このことは、コンテキストが検索拡張生成、すなわちRAGより広い概念である理由を説明する。RAGは知識ソースを検索し、生成前に関連資料をプロンプトへ追加する。回答の根拠付けには役立つが、検索だけではエージェントの作業環境を構成するすべてを管理できない。

本番用のコンテキストレイヤーには、セッションメモリ、ユーザー設定、データベーススキーマ、ライブイベント、アクセス制御、ツール出力、ワークフロー状態も含まれうる。何を保持し、何を破棄し、何を更新するかを判断しなければならない。

Stack Overflowは、企業固有のソフトウェア開発を例にこの隔たりを示した。エンタープライズコンテキスト問題の分析では、汎用アシスタントは公開ライブラリを知っていても、組織の非公開アーキテクチャや過去の技術的意思決定までは把握していない可能性があると指摘している。

記事は、Slackチャンネルで利用されるUberの社内アシスタントGenieを紹介している。Stack Overflowによれば、Genieは人間が検証した社内ナレッジリポジトリとOpenAIモデルを組み合わせている。エンジニアは、裏付けのない回答を受け入れるのではなく、ソースを確認できる。

この例は、すべてのコンテキスト対応エージェントが成功することを証明するものではない。モデルの知能と組織的知識が異なる仕事を担う理由を示している。モデルは言語能力と推論能力を提供する。知識レイヤーは企業固有の制約と証拠を提供する。

組織的知識には、構造化データベースにはほとんど現れない説明も含まれる。あるチームは、以前の移行時に失敗したためライブラリを廃止したかもしれない。別のサービスでは、古いコンプライアンス上の約束により通常とは異なる承認が必要になる場合がある。

こうした事実は、会議メモ、チャットスレッド、ローカルファイル、従業員の記憶に残りがちだ。したがって、利用可能なコンテキストレイヤーの構築は、検索の問題になる前に組織上の問題として始まる。

検索可能なナレッジベースは、散在する資料をよりアクセスしやすくできる。ただし、検索品質では、欠けた所有権、不明確なポリシー、誰も維持していない文書を補うことはできない。

Cotrufoの立場が最も強くなるのはこの点だ。企業は最新モデルを選ぶだけで、文書化されていない運用から抜け出すことはできない。自社の内部実態を、機械が理解できる形にしなければならない。

真の競争は、モデルの乗り換えとコンテキストへの投資の間にある

主要な競争軸は、モデルを繰り返し置き換えることと、各モデルを取り巻くデータ、メモリ、ガバナンスへ持続的に投資することの間にある。

モデル優先のチームは、成果が弱い場合に別のプロバイダーを試し、プロンプトを拡張し、より大きなコンテキストウィンドウを選択する。このような実験は、元の失敗が推論品質や指示追従に関わる場合には役立つことがある。

しかし、元の記録が誤っている場合には効果が限られる。営業エージェントが前四半期の製品カタログを受け取ったとしても、ベンチマーク首位のモデルがすべての変更を確実に推測できるわけではない。権限が欠けていれば、モデルは制限された契約を安全に取得できない。

コンテキスト優先のチームは、システムが下すべき意思決定から始める。権威ある情報源、必要な鮮度、ユーザー権限、履歴状態、許容できる不確実性を特定する。そのうえで、モデルはその運用環境の中で評価される。

このアプローチは調達時の問いを変える。購入者は依然として、モデルの精度、レイテンシー、セキュリティ、互換性を比較しなければならない。同時に、周辺アプリケーションが正しい証拠を取得し、アクセス境界を尊重しているかも検証する必要がある。

Google Newsの検索は、リリースが明確なイベントと認知しやすい名称を生むため、目立つモデル発表を前面に出しがちだ。コンテキストの作業は目立ちにくい。データ契約、評価スイート、検索パイプライン、アイデンティティシステム、保守手順に現れる。

しかし、こうした目立たない要素こそが、エージェントがデモから反復的なワークフローへ移行できるかを左右する。洗練されたデモでは、しばしば慎重に選ばれた文書と予測可能な質問が使われる。本番環境では、矛盾する入力、権限変更、欠落フィールド、例外的なケースが露わになる。

コンテキスト優先の主張は、ベンダーロックインにも影響する。ビジネス上の意味が一つのモデルプロバイダーのプロンプトや独自のメモリシステム内に存在する場合、乗り換えは高コストになる。個別に統制されたコンテキストレイヤーであれば、モデルが変わっても組織的知識を維持できる。

その利点は自動的に得られるものではない。コンテキストストアやオーケストレーション製品は、それ自体が依存関係を生み出しかねない。データ形式、ベクトルインデックス、ツールスキーマ、評価履歴、アクセス方針によって、企業は依然として特定のアーキテクチャに縛られる可能性がある。

そのため企業は、長期的に維持すべき資産と交換可能なコンポーネントを分けて考えるべきだ。長期的な資産には、ソースの所有権、業務上の定義、承認ルール、評価ケース、追跡可能な記録が含まれる。モデル、検索アルゴリズム、オーケストレーションフレームワークは、こうした資産に対して検証可能な状態に保つべきである。

Redisの戦略はこの区分を反映している。同社のRedis Iris announcementでは、エージェントに対してメモリ、構造化データ、検索、キャッシュ、最新の運用情報を提供するレイヤーが説明されている。モデルはそのレイヤーの上に位置し、理論上は変更可能だ。

同社によれば、Context Retrieverは定義済みの業務エンティティから制御されたツールを生成する。このアプローチは重要である。無制限のデータベースアクセスを許せば、エージェントが理解も利用権限もないデータに触れるおそれがあるからだ。

ツールは利用可能な操作を限定できる。任意のクエリを許可する代わりに、エージェントには顧客識別子で注文を取得する、承認済みの関数を与えられるかもしれない。その関数は行レベルのアクセス制御を適用し、予測可能なスキーマを返せる。

これは単にプロンプトに添付される文書ではなく、実行可能なポリシーとしてのコンテキストである。エージェントが何を要求できるのか、どのデータを閲覧できるのか、そのデータをどのように解釈すべきかを表現する。

RelationalAIの最高経営責任者であるMolham Arefは、市場の別の領域から関連する主張を展開している。2026年6月のenterprise context layerに関する議論で、文書だけでは運用上の意思決定の背後にある関係性や業務ロジックを捉え切れないと述べた。

この違いは、サプライチェーン、価格設定、リスク、不正分析において重要だ。これらの領域は文章だけでなく、構造化された取引と変化する関係性に依存している。AIシステムは、レコード同士がどう結び付くか、どの計算が業務上の概念を定義するかを理解する必要がある。

したがって競争は、単にRedis対ほかのデータベース企業という構図ではない。より深い争点はアーキテクチャにある。一方の道筋では、モデルを製品の中心に据え、必要に応じてデータを接続する。もう一方では、モデルを統制された情報システム内の推論コンポーネントとして扱う。

Cotrufoの主張は後者を支持する。その魅力は、基盤モデルの代替が容易になる一方で、企業データの整理が依然として難しいほど高まる。

より良いコンテキストは、それ自体に精度とセキュリティのリスクをもたらす

コンテキストは根拠のない回答を減らせる一方、統制が不十分なコンテキストは、より機微な情報にアクセスしながらAIシステムを自信満々に誤らせる可能性がある。

これはCotrufoの主張に対する最も強い反論である。コンテキストを最大の問題と呼ぶと、解決策は単純に聞こえる。より多くのデータを接続し、メモリを追加し、適切なレコードを取得すればよい、という具合だ。

しかし、その各操作にはリスクが伴う。メモリサービスは、以前の会話で生じた誤った前提を保持する可能性がある。検索は、すでに置き換えられたポリシーを表示するかもしれない。同期パイプラインは、ソースシステムのエラーをより速く拡散させる可能性がある。

コンテキストが増えるほど、露出も増え得る。顧客記録、社内メッセージ、運用システムに接続されたエージェントは、より価値の高い標的になる。取得した文書に含まれる悪意ある指示は、エージェントの行動を誘導し直したり、制限された情報を引き出したりしようとする可能性がある。

したがってアクセス制御は、ユーザーとタスクに従う必要がある。ある地域のアカウントを閲覧できる従業員が、エージェントの共有インデックスに両方の情報が含まれているという理由でグローバルなアクセス権を得るべきではない。検索の関連性は、権限を裏付けるものではない。

同じ理由で、プロベナンスも重要だ。重要な回答はすべて、どの記録が根拠となったか、それらの記録がいつ変更されたか、どのシステムが所有しているかを明らかにすべきである。その追跡経路がなければ、コンテキストは説明責任のない確信を生み出す。

メモリは別のガバナンス上の問いも生む。確認済みのユーザー設定のように、セッションをまたいで保持すべき情報もある。一方で、一時的な指示や、検証されていない前提など、期限切れにすべき情報もある。

チームには、会話履歴と永続的な事実を区別する保持ルールが必要だ。また、訂正の経路も必要になる。ユーザーが誤りを修正した場合、システムは古いメモリを更新または無効化し、後で両方のバージョンを取得してしまわないようにしなければならない。

セマンティックキャッシュにも同様のトレードオフがある。過去の応答を再利用すれば、レイテンシを削減し、不必要なモデル呼び出しを避けられる。ただし、キャッシュの期限が切れる前に基礎となるポリシーが変更されれば、古い回答を返す可能性もある。

したがって安全なキャッシュには、類似性マッチング以上のものが必要だ。期限ルール、ソースバージョンの認識、最新データを要する判断への除外規則が求められる。キャッシュされた説明は許容できても、キャッシュされた口座残高は許容できない場合がある。

評価は最後のガードレールであり続ける。チームはモデルだけでなく、アプリケーション全体をテストすべきだ。有用なテストは、検索精度、ソースの鮮度、権限適用、ツールの完了、必要な根拠がない場合の挙動を測定する。

システムには拒否またはエスカレーションする能力が必要だ。常に回答を出すエージェントは、もっともらしい言葉でコンテキストの欠落を埋めてしまう。本番環境での信頼性は、利用可能な根拠が行動を正当化しないときにそれを認識できるかどうかにも左右される。

National Institute of Standards and Technologyのgenerative AI profileは、設計、展開、監視、ガバナンス全体にわたるリスク管理を重視している。このライフサイクルの見方は、情報品質や権限がローンチ後に変化するコンテキストエンジニアリングに適している。

ベンダーの主張も、顧客環境で検証する必要がある。Redisは、自社サービスが永続的なメモリ、統制されたアクセス、ほぼリアルタイムの同期を提供できるとしている。こうした機能は、正確なソースデータと適切に設定されたルールがなければ、正しい業務判断を保証するものではない。

また、広範なコンテキストという論旨が、モデル間の違いが無関係になったことを証明するわけでもない。より優れた推論、より強力な多言語性能、より信頼性の高いツール選択を必要とするタスクもある。弱いモデルは、優れたコンテキストを誤用し得る。

実際的な立場は、Google Newsの見出しほど絶対的ではない。エンタープライズの信頼性は、モデル能力とコンテキスト品質の相互作用から生まれる。Cotrufoによる有益な補正は、買い手が前者を精査する一方で後者への投資を不足させてきたことだ。

コンテキストエンジニアリングは、あらゆるエンタープライズAIベンダーに圧力をかける

コンテキストへのシフトは、モデル提供企業、データプラットフォーム、アプリケーションベンダー、企業の買い手に対し、ワークフロー全体での信頼性を証明するよう求める。

基盤モデル企業には、自社モデルをより接続しやすく、統制しやすく、評価しやすく、置き換えやすいものにする圧力がかかる。生の能力は依然として重要だが、エンタープライズの買い手は、予測可能なツール利用と明確な統制をますます求めている。

クラウドプラットフォームが直面する課題は異なる。すでにデータ、アイデンティティ、アプリケーションインフラを管理しているからだ。その機会は、すべての顧客を単一のモデルやデータ形式に縛り付けずに、これらの資産をエージェントプラットフォームへ統合することにある。

データベース企業と検索企業にとって、コンテキストは拡大市場である。Redisはリアルタイムの状態とメモリを強調する。他のベンダーは、ベクトル検索、ナレッジグラフ、セマンティックレイヤー、データウェアハウスに注力している。それぞれが既存の強みを、欠けていたエンタープライズレイヤーとして位置付けている。

アプリケーションベンダーにも優位性がある。自社製品にはすでにワークフロールールとユーザー権限が含まれている。顧客サービスプラットフォームはチケットを理解し、営業プラットフォームはアカウントと商談を理解している。

ただし、アプリケーション固有のコンテキストは分断を深める可能性がある。営業、請求、サポート、製品システムを横断して動作するエージェントは、異なるアイデンティティや定義を調整しなければならない。単一のアプリケーションが自動的にビジネス全体を表現するわけではない。

コンサルティング企業や社内プラットフォームチームには、これらのシステムを統合する圧力がかかる。その価値は、孤立したデモを構築することから、再利用可能なコンテキストサービス、評価基準、ガバナンス統制を定義することへと移行する。

エンタープライズの買い手が負う責任は最も重い。ベンダーはコネクターやメモリシステムを提供できるが、どのソースが正しいのかを決められるのは企業だけだ。「アクティブ顧客」「承認済み割引」「解決済みインシデント」が実際に何を意味するかを定義しなければならない。

この作業は、しばしばAI以前から存在した意見の不一致を明らかにする。同じ指標名でも、二つの部門が異なる計算方法を使っているかもしれない。エージェントはその対立を生み出さないが、露呈させ、増幅する可能性がある。

ナレッジワーカーも注意を払うべきだ。コンテキスト設計は、誰の判断がコード化されるかに影響するからだ。正式な文書だけがシステムに入れば、有用な例外や実務経験が失われる可能性がある。あらゆる非公式な会話を入れれば、プライバシーと品質のリスクが高まる。

思慮深いsecond brainは、個人が意思決定とその裏付け資料を保存する助けになる。エンタープライズシステムには、共有所有権、権限、保持、監査可能性に関する追加の統制が必要だ。

開発者は、コンテキストパイプラインを本番ソフトウェアとして扱う必要がある。検索プロンプト、文書パーサー、ランキングルール、メモリポリシー、ツールスキーマには、すべてバージョン管理とテストが必要である。どのレイヤーの変更も、エージェントの挙動を変え得る。

プロダクトマネージャーには、利用状況を超える指標が必要になる。頻繁に利用されるアシスタントでも、低品質な助言を提供している可能性がある。より良いシグナルには、検証済みのタスク完了、訂正率、エスカレーションの傾向、ソースの網羅性、定義済みワークフローで削減された時間が含まれる。

セキュリティチームは、最終レビュー担当ではなく中心的な参加者になる。エージェントの権限は、ユーザーアイデンティティ、タスクの範囲、現在のポリシーに一致しなければならない。ログには、情報へのアクセスと実行された操作の両方を示す必要がある。

したがってCotrufoの枠組みは、組織全体にわたって注目を再配分する。エンタープライズAIプログラムは、主としてモデル統合プロジェクトではなくなる。知識、権限、メモリ、フィードバックを構造化する継続的な取り組みとなる。

これは「より賢いモデルを導入する」というメッセージよりも要求が厳しい。しかし、コンテキストが持続的な差別化要因になり得る理由も説明している。競合他社は似たモデルをライセンスできても、同じ組織的知識や運用規律を共有しているわけではない。

Google Newsの読者が次に注目すべきこと

コンテキスト優先という論旨は、カテゴリー発表がもう一巡することではなく、本番環境での証拠によって検証される。

最初のシグナルは、測定可能なワークフロー性能だ。企業は、従業員がチャットボットを開いたかどうかだけでなく、コンテキストを認識するエージェントが定義済みのタスクを正確に完了したかどうかを報告すべきである。訂正率、エスカレーション、ソースの有効性、成功したツール操作は、導入数の合計より多くを明らかにする。

企業が同じ基盤モデルを維持したままこうした指標が改善するなら、Cotrufoの主張はより強まる。モデルのアップグレードがコンテキストの変更より大きな改善を生むなら、見出しが示す優先順位は擁護しにくくなる。

第二のシグナルはモデルの可搬性だ。ベンダーは、企業がモデルを変更してもコンテキストレイヤーを維持できるとますます主張している。買い手は、同一のタスク、根拠、権限、評価を複数の提供企業で実行して、その約束を検証すべきである。

切り替えが成功すれば、組織固有のコンテキストが永続的な資産になりつつあることが示される。高コストな書き換えや大幅な挙動変化が生じれば、モデル中立をうたうシステムに隠れた依存関係があることが明らかになる。

第三のシグナルは、実運用下でのガバナンスだ。コンテキストプラットフォームは、データを漏洩させたり古い回答を再利用したりすることなく、取り消された権限、変更されたポリシー、削除されたレコード、汚染されたコンテンツを扱えることを示さなければならない。

静的なデモでは優れた性能を示す一方、ポリシー更新後に機能しなくなるシステムは、エンタープライズの課題を解決したとは言えない。鮮度、追跡可能性、修正は継続的に機能しなければならない。

Google Newsの見出しが注目に値するのは、エンタープライズAIの優先順位における実際の変化を捉えているからだ。ただし、Cotrufo、Redis、あるいはその他のベンダーがすでにコンテキストの問題を解決した証拠として読むべきではない。

開発者とエンタープライズの購買担当者にとって、直ちに取るべき行動は明確だ。ソース記録から最終判断まで、本番ワークフローを一つ監査する。モデルが何を見ているのか、何を見落としているのか、各事実を誰が管理しているのか、そして誤りがどのように修正されるのかを特定する。

次に、モデルを変更することで観察された障害が解消されるかを検証する。解消されないなら、ボトルネックはおそらく別の場所にある。Cotrufoの主張が長期的な意義を得るのは、コンテキストへの投資が、現実のビジネス上の圧力の下で、より安全かつ正確な業務を生み出す場合に限られる。