OracleがGoogleのGeminiを自社のエンタープライズアプリ全体に統合すると発表した。ERPやHCMにAIが標準で載ってくる流れである。開発を生業にしている側にとって重要なのは「Geminiが載る」ことではなく、AIをどこで持つかの主導権がSaaSベンダー側に移りつつあるという点だ。受託開発・SIerの事業判断として何が変わるかを整理する。
要点 (事実のみ)
- Oracleが Google Cloud とのパートナーシップを拡大し、Gemini モデルを自社のエンタープライズアプリケーション全体へ統合すると発表した (2026年7月31日報道)。
- 統合先は Oracle AI Agent Studio for Fusion Applications、Oracle Fusion Applications、NetSuite、および Fusion Cloud の ERP / HCM / SCM / CX。
- 提供されるモデルは Gemini 3.1 Flash Lite (効率と価格性能を重視) と Gemini 3.5 Flash (複雑な推論や、動画・プレゼン作成を含む専門的タスク向け)。マルチモーダル機能が拡張される。
- 既存の OCI Enterprise AI との統合として位置づけられ、業務内容に応じて最適な価格性能のモデルを選べる「モデル選択の柔軟性」が強調されている。
- Google Cloud VP の Satish Thomas 氏は、アプリケーションとエージェントのワークフロー内で Gemini を使いやすくする設計だと述べている。Oracle EVP の Chris Leone 氏は、顧客の選択肢が増えることで複雑な業務課題に対応するエージェントを構築できるとしている。
主導権はモデルから「業務の入口」へ移っている
この手の発表を「OracleがGeminiを採用した」というモデル選定の話として読むと、意味を取り違える。
注目すべきは、統合先が Agent Studio と Fusion Applications、つまり業務データと業務プロセスを握っている場所であることだ。ERP・HCM・SCM・CXは、企業の受注・在庫・人事・顧客のデータが集まる。そこにAIエージェントを構築する環境が標準で載るということは、「AIを使うために、まずどこに行くか」の入口をERPベンダーが押さえに来たということである。
モデル自体は差し替え可能な部品になった。実際、Oracleは「モデル選択の柔軟性」を売り文句にしている。柔軟に選べるということは、モデルで囲い込めないことを認めているのと同義だ。ロックインの主戦場は、モデルからワークフローとデータに移っている。
開発会社・SIerにとって、受託の付加価値はどこに残るか
同業として率直に言えば、この流れは受託の一部を確実に削る。「ERPのデータを使って社内問い合わせに答えるチャットを作る」といった案件は、標準機能でできるようになれば発注されない。
一方で、残る領域ははっきりしている。私が見る限り3つある。
1. ERPの外にあるデータとの接続。 現場のExcel、メール、紙、業界固有の外部システム——企業の業務は ERP の中だけで完結していない。標準搭載のエージェントが触れるのは ERP が持っているデータだけである。業務の実態と、ERPが把握している範囲のギャップこそが受託の領域になる。
2. 業務プロセスそのものの設計。 どの業務をエージェントに任せ、どこで人が判断するかは、製品を導入しただけでは決まらない。この工程は「使われないシステム」が生まれる要件定義の失敗で書いた構造と同じで、機能があることと業務に乗ることは別問題だ。
3. 権限とデータガバナンスの設計。 ERPのデータに触れるエージェントは、権限設計を誤ると事故が大きい。人事評価や与信情報を、権限のない社員の質問に対する回答根拠として引いてしまう、といった事故は設計を省略すると簡単に起きる。ここは社内RAG構築とは？費用の内訳と失敗しない進め方で書いたとおり、費用の大半が集中する箇所でもある。
逆に言えば、モデルを扱えることや、エージェントを実装できること自体は、もう差別化にならない。標準機能として降りてくるからだ。差別化が残るのは、顧客の業務を理解して「何を任せ、何を任せないか」を決められるかどうかである。
発注側 (ERPを使っている企業) が今から確認すること
ERPベンダーがAIを載せてくると、「自社で作るべきか、標準機能を待つべきか」という判断が発生する。順番はこうだ。
- やりたいことが、ERPが持っているデータだけで完結するか。 完結するなら、標準機能のロードマップを確認してから作るかを決める。作ってから標準搭載されるのが最も無駄
- 完結しないなら、不足しているデータはどこにあるか。 ERPの外にあるなら、接続の設計が主要な工数になる
- その業務の判定基準を人の言葉で書けるか。 書けないなら、製品が何であれ動かない (AI PoCの進め方5ステップ)
- 失敗したときに人が拾える工程か。 ERPのデータを更新する処理を最初に任せるのは避ける
1番目は特に重要である。ベンダーの標準ロードマップと重なる機能を自前で作ると、1〜2年後に二重投資になる。相談を受けたときも、まずここを確認している。
AIの前に、基盤が揃っているか
もう一点、この発表が前提にしていることがある。ERPが入っていて、そこにデータが集まっている企業でなければ、この話は始まらない。
日本の中堅・中小企業では、受注はメール、在庫はExcel、原価は担当者の頭の中、という状態が珍しくない。この状態でAIを導入しても、参照するデータが存在しない。順番としては業務基盤の整備が先になる (AIはERPと業務基盤なしには機能しない、業務の棚卸しのやり方)。
華やかな発表ほど、成立条件は地味である。ERPベンダーがAIを載せる競争が進むほど、「そもそも自社のデータはどこにあるか」を把握している企業とそうでない企業の差が開いていく、というのが私の見立てだ。
自社の業務のどこからAIを差し込むべきか、標準機能を待つべきか自前で作るべきかの切り分けでお困りなら、開発のご相談からお問い合わせいただければ、現状のシステム構成を確認したうえでご一緒する。
出典: Oracle integrates Google's Gemini AI models into enterprise apps (ITPro, 2026-07-31)
