9月18日、The Next Webが「Oracle hit 80% AI adoption in three months, then hit a bottleneck」と題した記事を公開した。Oracleが社内AI展開で3ヶ月以内に従業員の80%が利用するまでに至ったものの、コスト膨張とワークフローのボトルネックという新たな課題に直面している実態を詳しく報じている。
「自社でAIを使いこなせていなかった」と共同CEOが認めた
Oracleはここ2年で数百億ドル規模のAIインフラ投資を行い、他社のAI基盤を支える立場にある。だが皮肉なことに、自社従業員が実用的なAIツールを手にしたのは今年4月のことだ。
共同CEOのClay Magouyrk氏は社内タウンホール（全社ミーティング）でこう語ったという。
「1年前、私たちはAIを自分たちのために本当に役立てる方法を見つけられていなかったと思う。」
— Clay Magouyrk（Business Insider報道より）
当時、OracleはカスタマーサポートにAIを導入していたが、開発者・財務・営業チームへの展開はまだだった。
3ヶ月で80%採用——ただしコストで驚く
4〜5月にかけて、グローバルCIOのJae Evans氏率いるチームがChatGPT EnterpriseとOpenAIのコーディングツールCodexを展開した。対象は約16万人の従業員。ローンチ前に企業標準・セキュリティ統制・内部ポリシーを整備した上での導入だ。
結果、3ヶ月以内に従業員の80%が利用するまでになった。
だが請求書が届いたとき、Evans氏によればコストの規模に驚いたという。ツールが手軽に使い始められるため、想定以上に利用が広がったからだ。
これに対してOracleが取った対策は「モデルの見える化」だ。現在は従業員が自分の使っているAIモデルと、各モデルのコストを確認できるようになっている。元記事によれば、具体的には以下のような使い分けを促しているという。
- 高性能モデル（元記事では特定モデル名が記載）：廉価モデルの約2.5倍のコスト
- ルーティン業務向けの廉価モデル：コストを抑えた日常業務用として従業員を誘導
同様のコスト管理アプローチは他社でも見られる。元記事によれば、JPMorganもエンジニアのAIモデル利用を月2,000ドル上限に制限しているとされる（出典：The Next Web記事内の言及）。
「コードが速く書ける」≠「リリースが速い」という現実
生産性の数字は目を引く。Evans氏によれば、開発者が1週間で完成させる成果物が、以前はチームで2〜3四半期かかっていたという。
しかしそれが顧客へのデリバリー高速化には直結していない。Magouyrk氏はこう述べた。
「コードを速く書けるようになっても、それですべてが1000倍速くなるわけではない。」
— Clay Magouyrk
テスト・検証・デプロイ・リリース管理のプロセスがまだ追いついていないのだ。AIがコードを生成するスピードに、人間側のワークフローが対応できていない状態が続いている。
セキュリティでも同じ構図——偽陽性60〜70%の壁
セキュリティ分野でも似たパターンが生じている。元記事によれば、OracleはAnthropicの特定モデルの早期アクセスパートナーの一社として、社内コードベースへの脆弱性検出を試みたという（元記事ではモデル名・プログラム名が記載されているが、一般には馴染みの薄い名称のため、詳細は元記事を参照されたい）。
このモデルについてAnthropicは「主要OSとブラウザのゼロデイ脆弱性を特定・実証できる」と説明しているとされる。
※「悪用できる」という表現が元記事に登場する場合、これはセキュリティ研究の文脈における「脆弱性を再現・実証できる」意味であり、攻撃ツールとして機能するという意味ではない点に注意されたい。
OracleがこれをZZ内部コードに適用したところ（「ZZ」は元記事に記載された内部プロジェクトコードと思われるが、詳細は元記事を参照されたい）、2週間で前年1年分を上回る潜在的脆弱性が検出された。
ただし**偽陽性率が60〜70%**に達するため、エンジニアが修正に着手する前に検証ステップを設けなければならなかった。
結果として、ボトルネックはなくなったのではなく移動したにすぎない。
- AIがコードを書く速度 > 会社がリリースできる速度
- AIが欠陥を見つける速度 > 人間が検証できる速度
より高精度なモデルは廉価なモデルの2.5倍のコストがかかる。こうした課題を社内タウンホールで率直に共有している点が、今回の報道で特筆される。
なお、元記事はOracleが人員削減を進めている時期に重なるタイミングでの報道であることも触れているが、本記事が扱うAI導入の課題とは直接の因果関係は示されていない。
エンジニアへの示唆
OracleのケースはAI導入における普遍的な構造問題を浮き彫りにする。採用率やコード生成速度は比較的早く改善できるが、テスト・検証・リリースという下流プロセスがそれに追いつかない。ツールの導入コストが「使い始めやすさ」によって想定外に膨らむ点も、企業規模での展開では見落としがちなリスクだ。
類似の構造的課題はOracleに限らず、AI導入を進める大手企業で共通して報告されるようになっている。GitHubのCopilot導入事例を分析したGitHubの調査レポートでも、コード生成速度の向上と実際のデリバリー速度の乖離は重要な論点として挙げられている。AIツールの選定・コスト管理・ワークフロー再設計をセットで検討することが、導入フェーズを超えた「定着」には不可欠と言えるだろう。
詳細はOracle hit 80% AI adoption in three months, then hit a bottleneckを参照していただきたい。
