OpenAIが2026年9月1日に公開した「Enterprise Signals」分析によれば、AI活用の上位10%の企業は一般企業の8.3倍の出力トークンを利用者あたりに生成しており、1月の2.6倍から格差が急拡大している。支援から実行へと移る企業AI導入の分岐点を、Basis・Clay・Exaの3事例と研究現場の動きから読み解く。

OpenAIは2026年9月1日、公式ブログ「How AI-native companies turn workflows into operating capability」を公開した。同社が定期分析している「Enterprise Signals」のデータでは、AI利用度上位10%の「フロンティア企業」は、1人のアクティブユーザーあたり典型企業の8.3倍の出力トークンを生成している。この倍率は2026年1月には2.6倍だった。わずか8ヶ月で3倍以上に開いたこの差は、AIの「利用の有無」ではなく「仕事の任せ方」の差であると同社は分析している。

格差の正体はトークン量ではなく「業務の委任深度」

出力トークン数そのものが価値を測る指標ではない、という点には注意が必要だ。OpenAI自身も、トークン量は「人がAIに多くの仕事を任せている」ことのシグナルにすぎず、成果はサイクルタイムや品質・コストといったワークフローの結果で測るべきだと述べている。

同社が指摘するフロンティア企業の共通点は3つある。第一に、エージェントを会社のコンテキスト（CRM・Slack・ドキュメント等）やツールに接続していること。第二に、雑務ではなく実務的な仕事を委任していること。第三に、うまくいったワークフローを再利用可能な形にして繰り返していること。つまり差はモデルの性能ではなく、業務設計の側に生まれている。

3つの事例に見る「支援」から「実行」への移行

OpenAIは具体例として3社の取り組みを紹介している。いずれも企業自身の発表であり、効果の数値は各社の主張である点に留意されたい。

会計事務所向けAIエージェントを開発するBasisでは、入社初日のオンボーディングが2時間から30分に短縮されたと報告されている。仕組みは、会社固有のオンボーディング手順をCodex用の再利用可能な「スキル」として定義し、初日に従業員がエージェントから案内を受けながら環境構築を進めるものだ。HR側は例外や頻出質問が発生するたびにスキルを更新でき、プロセスが特定の担当者の稼働状況に依存しなくなったという。

営業チーム向けの自己学習型レベニューエンジンを開発するClayは、散在する商談コンテキストの問題に取り組んだ。CRM・メール・Slack・商談資料に分散する情報を、顧客アカウントごとに専用サブエージェントが夜間にレビューして更新し、朝になると調整エージェントが優先アクションのリストに整理する。担当者は毎晩およそ1時間のメール整理が不要になったと同社は主張する。推奨の根拠となる一次ソースが常に参照できるため、営業担当者は行動前に情報を検証できる。

検索APIを開発するExa Labsでは、「Exa everywhere」と掲げる統合機会の発見から実装までを、優先順位・必要な情報源・人間によるレビューを明確にしたワークフローとしてCodexに委任している。エージェントがリポジトリを監視し、プルリクエストを作成し、テストを実行し、週次のアップデートを準備する。どの機会を追うか、外部へのコミットメントをどう管理するかは人間が決める設計だ。

3社に共通するのは、エージェントの成果物が必ずテスト・レビューを通じて人間に見える形になっている点、そして改善をワークフロー自体に組み込んでいる点である。

研究現場でも進む「実用化の加速」

産業応用の裏側では、基盤研究から実装への流れも加速している。MIT Newsが2026年9月2日に報じたところによれば、MIT-IBM Computing Research Lab出身の研究者らが、量子機械学習や信頼できるAIの研究成果をIBMの企業向けエージェントフレームワークや推論基盤に移している。

その一例がvLLM Hookだ。IBM Researchの科学者らが発表したこの手法（arXiv:2603.06588、査読前のプレプリント）は、LLM推論エンジンvLLMにプラグインとして組み込み、隠れ層の活性化といったモデル内部のシグナルからプロンプトインジェクションやハルシネーションの可能性を検出する。推論プラットフォーム上でそのまま動く軽量な設計が特徴で、安全対策を実運用に載せるための足回りと言える。

エージェントが実行を担うようになるほど、この種の「実行を見える化し、止める仕組み」の重要性は増す。MIT-IBMの事例は、企業導入のボトルネックがモデル性能から信頼性・安全性の実装へと移りつつあることを示唆している。

導入競争で効くのは「測定」と「実験の余白」

OpenAIはブログの締めで、企業リーダーへの処方箋として6段階のフレームを示している。要点は、戦略的優先度・システム・引き継ぎ・測定可能な賭け金が交わる「重要なワークフロー」を1つ選び、責任者とKPI・ベースラインを先に定義し、エージェントの職務記述書（トリガー・成果物・権限）を書き、実験の余地を残した上で、うまくいったものを標準化するというものだ。

1月から9月の8ヶ月で2.6倍から8.3倍へと開いた格差は、ツールの導入率ではなく運用の成熟度を反映している。エージェントへの委任を増やす企業と増やさない企業の差が、可視化され始めた段階だと考えられる。日本企業の多くはまだ「支援」の段階にとどまっているが、差が開き始めた初期であるほど、測定と実験の設計が後発の追い上げコストを左右することになりそうだ。

プロンプトやツールを自ら書き換えて能力を伸ばす「自己進化型」のLLMエージェントが研究の最前線に現れている。だが2026年8月末にarXivへ投稿された査読前の複数の論文によれば、自己書き換えは「戻せない変更」を残すリスクを伴い、防御側の仕組みもまた静的なままでは機能不全に陥る可能性が指摘されている。本記事では、進化と制御の両面を扱った3本の論文から、エージェント設計の次の論点を整理する。

自己進化がもたらす「回復不能」な変異の問題

LLMエージェントは、システムプロンプトやツール定義、実行ハーネスまでを実行時に自分で変更する方向へ進んでいる。能力向上には有効だが、一度成功した自己改変が、別の状態では安全に取り消せない——こうした「回復可能性」の問題を体系化したのが、2026年8月28日にarXivへ投稿された（査読前）EvoUndoである。

この研究は600件の未見タスクで自己進化を実験し、能力を実際に向上させた変異197件が回復可能性の検証に失敗したと報告している。つまり、うまく動いた自己書き換えの3分の1近くが、「元に戻す」操作を保証できない状態を残していたことになる。従来の反復的な修復プロンプトではこの自然発生した失敗を1件も回復できず、状態を正確に指定する「グラウンディング」と、復元言語の表現力を拡張することで、初めて回復率が9割を超えたという。

注目すべきは結論の方向性だ。論文は、信頼できる自己進化には検証・状態特定・復元言語の設計を共同設計する必要があり、プロンプトの繰り返しでは不十分だと主張している。エージェントフレームワークの設計者が「進化機能」を足すだけでなく、その取り消し機構までを一緒に設計すべき、という示唆と読める。

攻撃側も進化する:静的防御の限界

自己進化の議論は防御側にも及ぶ。同じく8月26日にarXivへ投稿された（査読前）別の論文は、ジェイルブレイク攻撃への対策が静的である限り、いたちごっこに終わると指摘する。多くの防御は配置時に安全挙動が固定され、新種の攻撃手法に対して経験を蓄積できない。

この論文が提案するのは、攻撃が成功するたびにその失敗を「手法レベルのルール」として抽象化し、外部のルールメモリに蓄えて再利用する、テスト時自己進化型のマルチエージェント防御だ。有害なトピックではなく攻撃の構造（ロールプレイ、難読化、多段階の迂回など）でルール化するため、1つのルールが同種の攻撃族全体に一般化されるという。仕組みは外部メモリとプロンプトのみで動作し、モデルのパラメータ更新を必要としないため、ブラックボックスのAPIモデルにも適用できるとされる。

実験では、複数のブラックボックス攻撃族に対して攻撃成功率を大幅に下げつつ、良性の利用を損なわず、適応的な複合攻撃に対しても頑健だったと報告されている。ただしこれは著者ら（シンガポール国立大学の研究グループ）の実験に基づく主張であり、査読を経た段階ではない点には注意が必要だ。

命令の仲裁そのものが攻撃面になる

進化や防御といった機能面とは別に、より根源的な脆弱性を指摘する研究もある。8月28日投稿の（査読前）論文「Recognition Without Enforcement」は、LLMエージェントがシステムプロンプト・ユーザー・メモリ・ツール由来の複数の命令を仲裁する際、その仲裁が信頼境界を強制しているとは仮定できない、と論じる。

著者らは「認識と強制のギャップ」と呼ぶ現象を特定した。ソースの書式特徴（ロールテンプレート上の位置、チャネルのメタデータ、整形の手がかり）はモデル内部で線形に読み取れる一方で、その情報が実際の拒否や実行の制御に結びついているとは限らない。つまりモデルは「どこからの命令か」を認識できていても、それを権限の強制に使えていないケースがあるというのだ。

システムプロンプトインジェクション対策が「見分けられること」と「守れること」を混同してきた可能性を示す指摘であり、エージェントに外部ツールやメモリを持たせるフレームワークでは、仲裁機構そのものを検証対象にするべきだという方向性を裏付ける。

フレームワーク設計の次の論点は「可逆性」と「経験の蓄積」

3本の論文は、それぞれ異なる層に問題を設定している。EvoUndoは自己改変の可逆性を、ジェイルブレイク防御の研究は防御経験の蓄積を、命令仲裁の研究は信頼境界の強制を扱う。共通するのは、静的に固定された設計では、動的に変化するエージェントの挙動に追従できないという視点だ。

実務への含意は2つに絞れる。第一に、エージェントに自己書き換えを持たせる場合は、変更の記録と検証済みの復元手段を同時に実装すべきである。EvoUndoの実験が示すように、反復プロンプトによる場当たり的な修復は機能しない可能性が高い。第二に、防御は配置時に完成するものではなく、失敗を構造化された知識として蓄え続ける仕組みに移行する必要がある。ルールメモリのような外部化された経験は、パラメータ更新できない環境でも動作する現実的な選択肢だ。

読者に一つ問いたい——自社のエージェント実装で「戻す」手段を設計に組み込んでいるだろうか。自己進化はもはや研究テーマではなく、実装に先立って決めるべき要件になりつつある。

OpenAIは2026年8月25日、初の自社開発推論チップ「Jalapeño」の初の計測結果を公開した。公開ベンチマーク「InferenceX」で、GPT-OSS 120B・DeepSeek R1・Kimi K2.5 1Tの3モデルにおいて、比較対象の商用システムに対しピーク時1ワットあたり1.5〜1.9倍の処理量と、1.7〜3.6倍低いエンドツーエンドのレイテンシを示したと同社は主張する。本記事は、この数字が何を意味するのかを、同社の公開資料から読み解く。

OpenAIは2026年8月25日、エンジニアリングブログで自社初のカスタム推論チップ「Jalapeño」の性能計測結果を初めて公開した（OpenAI Engineering Blog）。翌日には、このチップを含むコンピュート戦略の全体像を説明する記事「The full stack behind abundant intelligence」も公開している（OpenAI)。以下、断りのない限り数値はすべてOpenAI自身の発表値であり、独立機関による検証結果ではない点に注意されたい。

チップ単位ではなく「ワットあたり」で示された性能

OpenAIが今回の計測で用いたのは、SemiAnalysisが公開するベンチマーク「InferenceX」だ。これはAIリクエストのサービング処理全体を測定するもので、OpenAIは「性能はチップ単位ではなく消費電力あたりで評価すべきだ」という立場をとっている。

発表によれば、GPT-OSS 120B、DeepSeek R1 670B、Kimi K2.5 1Tという3つの公開モデルにおいて、Jalapeñoは比較対象の商用システムに対して、ピークスループット時でワットあたり1.5〜1.9倍のAI処理量を達成し、エンドツーエンドのレイテンシは1.7〜3.6倍低かった。特に対話的なワークロードでは2.1〜4.1倍の性能を示したとされる。最大のテストモデルだったKimi K2.5 1Tでは、ワットあたりピーク性能が約1.5倍、レイテンシが3.4倍低いとしている。

注目すべきは、スループットとレイテンシを同時に改善した点だ。既存のハードウェアではこの2つはトレードオフになることが多く、片方を立てるともう片方が犠牲になりがちだった。OpenAIは「1つのアーキテクチャで両立した」と主張している。なお、チップの定格は700ワットだが、テストしたワークロードでは実効消費電力は550ワット以下に収まっていたという。

推論のフェーズごとのボトルネックに合わせた設計

言語モデルの推論は複数のフェーズで構成され、ボトルネックが異なる。プロンプトを処理する「prefill」は計算集約的、トークンを逐次生成する「decode」はメモリ帯域に制約される。さらにコア間やチップ間のデータ移動がレイテンシを加算し、待機中の処理ユニットが遊ぶこともある。

Jalapeñoの設計思想は、このデータ移動と通信遅延を最小化することだという。レスポンス生成中のKVキャッシュなどのモデル状態を明示的にローカルに配置し、推論フェーズごとに計算・メモリ・ネットワークの適切な組み合わせを activate する。ネットワーク自体がアーキテクチャの一部であり、ワークロード全体を1つの接続システム内に収めることでデータ移動を減らす。その結果、prefillとdecodeの両方に対応でき、バランスが変化するエージェンティックなワークロードにも追随できる「バランスの取れたアクセラレータ」になったと同社は説明する。

AIがチップを設計し、チップがAIにプログラムされる

この発表で興味深いのは、開発プロセスそのものにもAIを組み込んだ点だ。OpenAIによれば、初期設計からテープアウト（マスク作成）まで9か月だったとされ、AIが実装の探索や検証ループの短縮に寄与したという。また演算回路の最適化にもAIを用い、スケジュール内により多くの計算性能を収めたとしている。

プログラミング面でも、エンジニアはローカルテンソル・明示的な通信・予測可能な同期でワークを記述し、AIがそのマッピングやスケジューリングを最適化する構造だ。実際、元の生産計画に含まれていなかった3つのオープンウェイトモデルを、CodexとGPT-Astraを使って2か月で高性能化したとされる。さらに、GPT-OSSの一部のattentionブロックとMoEブロックでは、AIが生成した実装が人間の専門家による実装より1.5〜1.8倍高速だったと報告されている。ただし同社自身も「これはモデル全体ではなく選択されたブロックの数値だ」と限定しており、解釈には幅がある。

主張として読むべき数字と、検証のこれから

これらの数値はすべてOpenAIによる自己申告であり、「comparison systems（比較対象システム）」が具体的にどの商用システムかは公開資料では明示されていない。ベンチマークのInferenceXは公開されたものであり、正規化には各アクセラレータの公称チップ消費電力を用いたとされるが、独立した第三者検証はまだ公表されていない。

一方、この発表の位置づけは明確だ。OpenAIはJalapeñoを「マルチジェネレーションのプラットフォームの始まり」と位置づけ、すでに次世代の開発を進行中としている。同社のコンピュートポートフォリオはMicrosoft・NVIDIAに加え、AWS、AMD、Broadcom、Cerebras、CoreWeave、Oracleなど多岐にわたり、自社シリコンはその中の「ファーストパーティの選択肢」を増やすものだ。モデル・サービングソフト・チップ・メモリ・ネットワークを協調設計するフルスタック戦略が、推論コストの低減という形でどこまで実証されるか。今後の独立検証と、次世代チップの実測値を見る必要がある。