生成AI基盤を選定する企業にとって、判断材料はGPUの性能だけではありません。どのアクセラレーターを利用できるのか、社内データへ安全に接続できるのか、モデルの出力を実際の業務処理までつなげられるのかという複数の条件を、まとめて評価する必要があります。Oracleが発表した計画は、この一連の課題をクラウド基盤から業務アプリまで一つの流れとして扱おうとするものです。



Oracleは、GoogleのAIアクセラレーターであるTPUを自社のパブリッククラウドで提供する方針です。GoogleがTPUを別のハイパースケーラーへ供給するのは今回が初めてとされています。ハイパースケーラーとは、大規模なデータセンターを世界的に展開し、計算資源やストレージを大量に提供するクラウド事業者を指します。Oracleは2027年から配備を始め、その後、利用可能なTPU容量を段階的に増やす計画です。

今回の発表で注目すべき点は、TPUの追加だけにとどまりません。OracleはCerebras SystemsとOpenAIのAIチップも導入する意向を示し、ChatGPTからOracleの業務アプリを操作できる連携サービスも明らかにしました。AI計算資源の選択肢を広げると同時に、生成AIを顧客管理や受発注といった実務へ接続する構想です。提供地域、価格、具体的な性能条件などは現時点で明らかにされていないため、企業が導入を判断する際には今後の詳細を確認する必要があります。

多数のAIチップを並べても、チップ間でデータを十分な速度で受け渡せなければ、システム全体の性能は伸びません。大規模なAI処理では、モデルの計算を複数のアクセラレーターへ分散させるため、ネットワークの遅延や消費電力が計算効率を左右します。Oracleのデータセンターに配備されるTPUは、Googleが開発したICIとOCSという二つの接続技術を利用する予定です。



ICIは銅線を使ってデータを転送する技術です。OCSは光信号を用い、小さな機械式ミラーで光線の進行方向を切り替え、接続先のサーバーへ導きます。一般的な光接続では、光信号をいったん電気信号へ変換し、その後に再び光へ戻す処理が必要になる場合があります。GoogleのOCSはこの変換工程を省く設計であり、電力消費を抑えられると説明されています。

ICIとOCSは、単に転送速度を高めるための付属機能ではなく、TPUをまとまった計算クラスタとして動かすための基盤です。クラウド利用企業の視点では、単体チップの公称性能だけでなく、実際の処理で何台を効率よく連携できるかが重要になります。ただし、Oracle環境で利用できる構成規模や、障害発生時の経路切り替え、サービス品質に関する条件はまだ示されていません。AI基盤を比較する際には、アクセラレーターの種類と併せて、クラスタ全体の通信設計や運用条件を見るべきでしょう。

TPU同士の通信をGoogleのICIとOCSが担うのに対し、TPUクラスタとOracleのデータセンター内にあるデータベースやストレージとの接続には、Oracle独自のAcceleronが使われます。異なる企業が設計した計算基盤を接続するうえで、この境界部分は性能だけでなく、顧客ごとのデータ分離や通信制御にも関わる重要な層です。



Acceleronの中核には、ネットワーク処理とサイバーセキュリティ処理に最適化されたSmartNICがあります。SmartNICは、通常であればサーバーのCPUが担当する通信管理などを専用ハードウェアへ移す仕組みです。OracleとGoogle Cloudの担当者は、ハードウェアレベルのテナント分離、高性能ファブリック、ゼロトラスト・パケットルーティングによって、Oracleのデータベース、ストレージ、TPUクラスタ間のデータを高スループットかつ低遅延で転送すると説明しています。

企業の生成AIでは、計算能力よりもデータ移動が制約になるケースも考えられます。たとえば、業務データを保管する場所とAIを実行する場所が離れていれば、転送時間や通信コスト、アクセス管理が複雑になります。Oracleは自社のデータベースやストレージとTPUを同一クラウド基盤内で結ぶことで、こうした課題へ対応しようとしています。ただし、高スループットや低遅延という説明が、個々の顧客環境でどの程度の効果をもたらすかは、モデルの種類、データ量、構成によって変わるでしょう。導入検討では、実データに近い条件での検証が欠かせません。

Oracleが用意しようとしているのは、単一のAIチップに統一されたクラウドではありません。GoogleのTPUに加え、Cerebras Systemsのウエハースケール・アクセラレーターと、OpenAIの推論用アクセラレーターJalapeñoも配備する意向です。異なる特徴を持つ計算資源をそろえ、処理内容に応じて選べる基盤を目指していると考えられます。



Cerebrasのチップはシリコンウエハーほどの大きさを持ち、数兆個のトランジスタを搭載するとされています。通常の小型チップを多数接続する方法とは異なる設計思想です。OpenAIのJalapeñoは推論処理を目的としたアクセラレーターで、OpenAIは一部のオープンソースモデルについて、競合する半導体より1.5倍高速に実行できると説明しています。ただし、比較対象、モデル、精度、消費電力などの条件がそろわなければ、この数値だけで製品間の優劣を判断することはできません。

企業にとって重要なのは、チップのブランド数ではなく、学習、追加調整、推論といった処理に適した資源を選べるかどうかです。複数のアクセラレーターを扱える環境には選択肢が増える利点がある半面、ソフトウェアの互換性、性能測定、運用手順が複雑になる可能性もあります。Oracleが各チップをどのサービス形態で提供し、共通の管理機能や開発環境をどこまで整えるのかは、今後の評価点です。企業側も特定チップの性能値だけを比較せず、自社モデルを移行できるか、必要な容量を継続的に確保できるかまで確認する必要があります。

OracleとOpenAIの協業は、データセンター内のチップに限られません。Oracleは、同社のクラウドアプリケーションとChatGPTを接続するAI Workspaceを展開します。従業員は会話画面から情報を探すだけでなく、ChatGPTにOracleアプリ上の処理を実行させ、必要に応じて外部アプリも連携させられる構想です。



Oracleが示した例は、仕入先の遅延によって顧客の注文に問題が生じた場面です。解決には、代替商品の検索、在庫確認、顧客要件の把握、輸送手段の検証、財務的な影響の評価、注文内容の更新が必要になる場合があります。AI Workspaceは、最終的に注文問題を解消するという目標を維持しながら、複数のアプリ、AIエージェント、データ、ツールを調整すると説明されています。

ここでの変化は、質問に回答するチャットボットから、複数のシステムをまたいで作業を進める仕組みへの移行です。業務担当者が画面を切り替えながら情報を転記する代わりに、AIが一連の処理を調整できれば、例外対応に必要な時間を短縮できる可能性があります。その一方で、注文変更や財務判断まで扱う場合、AIに許可する操作範囲、人間の承認を挟む地点、誤操作時の復旧方法が欠かせません。AI Workspaceの価値は会話の自然さだけでは測れず、権限、監査記録、データの整合性を含む業務設計によって決まるでしょう。

既製のチャットボットだけでは、自社固有の承認手順やデータ処理に対応できないことがあります。Oracleが発表したApp Composerは、非技術部門の利用者がAIアシスタントを使ってカスタムソフトウェアを作成し、管理するためのツールです。作成したソフトウェアを脆弱性の観点から検査し、Oracleが管理するクラウド基盤へ展開するところまでを扱います。



Oracleの説明では、展開と運用は同社が管理する一方、顧客企業のIT部門はアクセス権、利用を承認するデータ、ポリシー、コストを統制します。現場部門が必要なアプリを素早く作り、IT部門が企業全体のルールを維持するという役割分担です。生成AIによる開発の敷居が下がるほど、誰が何を作り、どのデータへ接続したのかを把握する仕組みも必要になります。

同時に提供されるAI Security Meshは、OpenAIのサイバーセキュリティ向けAIモデルを利用し、顧客アプリケーションの弱点を発見します。検出した脆弱性を深刻度に応じて優先順位付けし、それぞれに修正案を提示する機能です。ただし、AIによる検査や提案があるからといって、安全性が自動的に保証されるわけではありません。修正内容が業務機能へ与える影響や、見逃された問題の有無を確認する工程は残ります。企業はApp Composerの導入と同時に、公開前のレビュー、権限の定期確認、問題発生時の責任分担を決めておくべきです。

Oracleは、大企業向けの計算基盤や業務連携だけでなく、中小企業を対象としたOracle AI SMB Bundleも発表しました。「無料で開始できる」製品群として位置づけられ、AI Workplace、App Composer、NetApp QuickStart会計プラットフォーム、ChatGPT Business、Codexが含まれます。顧客には年間1万2,000ドル分のクラウドクレジットを提供するとしています。



中小企業が生成AIを導入する際には、モデルの利用契約、アプリ開発環境、クラウド基盤を個別に選ぶ作業そのものが負担になり得ます。必要な製品を一つのパッケージとして提示する方法は、初期検証を始めるまでの手続きを減らす狙いがあるとみられます。App Composerを利用して専任の開発者が少ない組織でも業務アプリを作り、ChatGPT BusinessやCodexを日常業務や開発作業へ組み込むという利用像です。

もっとも、「無料で開始できる」ことと、継続運用に必要な費用が低いことは同じではありません。クラウドクレジットの対象範囲、消費後の料金、サポート条件、データの保存場所などは、契約前に確認する必要があります。日本の中小企業が利用を検討する場合には、日本語での支援体制、既存の会計・販売管理システムとの接続、社内に運用責任者を置けるかも判断材料になるでしょう。製品数の多さより、最初の一業務を無理なく運用できる構成を選ぶことが現実的です。

今回の発表は、生成AIの競争軸がモデル単体から、チップ、ネットワーク、企業データ、業務アプリ、セキュリティをどう接続するかへ広がっていることを示しています。日本企業が注目すべきなのも、TPUを利用できるという一点だけではありません。自社のデータがどこにあり、AIがどの操作まで実行し、その過程を誰が統制するのかを一つの業務フローとして確認する必要があります。



検証時には、次の四点を分けて確認すると判断しやすくなります。

- 計算資源では、自社のモデルが各アクセラレーターで動作し、必要な容量を確保できるかを測定します。
- データ接続では、データベースやストレージからAIまでの遅延、転送量、アクセス権を確認します。
- 業務実行では、AIに許可する操作、人間の承認地点、失敗時の復旧手順を定義します。
- 統制では、開発したアプリの検査、監査記録、費用上限、責任者を明確にします。

Oracleの構想は、これらの接続点を自社クラウド内でまとめて提供する方向を示していますが、サービスの多くは展開予定または提供開始段階です。導入候補の企業は、製品群を一度に採用するより、受注遅延への対応や社内アプリ作成など、効果を測れる一つの業務から試すほうがよいでしょう。処理時間、担当者の作業量、誤操作、クラウド消費額を検証前後で記録すれば、AI基盤の性能と業務上の成果を切り分けて評価できます。その結果を基に、TPUなどの新しい計算資源が本当に必要か、既存環境でも目的を達成できるかを判断できます。