OracleはエージェントオーケストレーションをERP内に組み込んだ——ガバナンスの計算式が変わる

OracleはFusion Clawを発表した。同社はこれを、主要ERPプラットフォームの内部に直接組み込まれた初のネイティブAIエージェント・オーケストレーション層だと説明している。その訴求は的を絞っており、示唆に富む。エージェントを別のコンソールから実行し、企業ポリシーを守ってくれることを願うのではなく、Fusion Clawでは業務ロジックがすでに存在するFusion Applicationsの中で、標準業務手順、リスク閾値、意思決定権限を定義できる。

重要なのはこの配置場所だ。ここ2年間、エージェントをめぐる議論は能力、つまりモデルがタスクを完遂できるかどうかに集中してきた。今月登場した重要な発表は、別の問いに答えている。それは、稼働を始めたエージェントを企業が監視し続けられるか、という問いだ。

誰もが口にするギャップ

この変化を説明する数字は、もはやおなじみだ。大企業の約85%がAIエージェントを試験しているが、エージェント技術を本番環境に移行したのは約5%にとどまり、パイロットが規模拡大に至るのはおよそ11〜14%だ。Gartnerは、エージェント型AIプロジェクトの40%以上が2027年までに中止されると予測し、その理由をモデルの品質ではなく統合と調整の問題に帰している。逆の見方をするIDCは、2028年までに世界で約13億のAIエージェントが使用されると予想している。

両者を合わせて考えると、ボトルネックは移動する。モデルは多くの作業にとって十分な水準にある。欠けているのは配管、すなわちアイデンティティ、権限、監査証跡、そして自ら行動するソフトウェアに従うようには設計されていないシステム間の調整だ。

製品カテゴリーとして出荷されるガバナンス

Oracleは、驚くほど多くのエージェント・ガバナンス基盤が登場した今月の参入企業の一つにすぎない。OpenAIはPresenceを発表した。これは、明確に定義された職務範囲、限定された知識アクセス、承認済みのアクションを備えた音声エージェントとチャットエージェントを展開するための運用層であり、請求サポート、保険金請求、従業員のITリクエストを対象としている。これと同時にClassie Superviseが登場し、すでに本番稼働しているエージェントを企業がリアルタイムで追跡・会計処理できるようにした。

SalesforceとAWSはAgentforce 360 for AWSを発表した。この共同プラットフォームのAtlas Reasoning Engineは、Amazon Bedrockを通じてAnthropicのClaudeモデル上で動作し、特筆すべきは、エージェントのあらゆる意思決定について改ざん不能な監査証跡を生成することだ。CrowdStrikeは初期導入企業の一つに名を連ね、セキュリティと併せて調達の簡便さを挙げている。これは「5つを組み立てるより1つを買う方がよい」という、いかにもエンタープライズらしい言い方だ。

ほかにも、OneTrustはAI Control PlaneとGovernance Command Centerでプラットフォームを拡張し、ChatGPT、Claude、Copilot、Gleanとの統合を実現した。Red Hatは、エージェントがアクションを実行できるようになるとモデルレベルの保護措置では不十分だと主張し、アイデンティティ、ランタイム、ネットワーク、インフラストラクチャにわたる多層防御を提唱してきた。Nvidiaは100社以上のパートナーと構築したOpen Agent Safety Platformを発表した。これは、逸脱したエージェントをミリ秒単位で隔離するよう設計されている。

これらの製品はそれぞれ、異なる高度から同じ問題に取り組んでいる。Oracleの賭けは、監査証跡は並行して存在するログではなく、トランザクションそのものであるべきだという点にある。エージェントの承認済みアクションがERP内部のルールとして定義されていれば、エージェントが下すあらゆる意思決定は、財務チームとコンプライアンスチームが他のあらゆる業務に用いている統制、権限、レポーティングの対象にすでに置かれていることになる。

なぜERPが自然な住処なのか

ガバナンスの比重が大きい領域が本番エージェントの最初の住処として理にかなうのは、代替案のほうがもっと悪いからだ。財務チームは、システム・オブ・レコードの外に存在し、説明できないアクションを実行し、別のツールにログを残すエージェントに請求書処理を任せることを正当化できない。オーケストレーションをERPに組み込めば、エージェントはワークフローの他の部分がすでに持っているロールベースのアクセス、職務分離、監査体制をそのまま継承する。

これもまた、Oracleの動きが競合を圧迫する理由だ。オーケストレーション層がコアプラットフォームの機能になれば、単体のエージェントゲートウェイは、購入し、保護し、突き合わせる必要のある余分なコンポーネントに見えてくる。購入企業は、さらに別の外部コントロールプレーンを追加するより、1つか2つの組み込み層に標準化するほうが良いと気づくかもしれない。

懐疑的な読み方

ガバナンスという枠組みはもっともであり、本番に至らないパイロットに痛い目を見せられてきた市場では、優れたマーケティングでもある。ただし、あらゆる評価に持ち込むべき注意点がいくつかある。監査証跡は、誰かがそれを読んで初めて役に立つのであり、エージェントの意思決定の改ざん不能なログは、悪い意思決定をそもそも防ぐ統制とは同じではない。あるベンダーのプラットフォームにオーケストレーションを組み込むことは、新たな種類のロックインも生む。エージェントの履歴とポリシーがアプリケーションスイートの内部に住むことになるからだ。そして中止の統計は諸刃の剣でもある。エージェントの展開を容易にするプラットフォームは、それ自体では調整の問題を解決しない。その問題は、ソフトウェアと同じくらいプロセスのオーナーシップにも存在する。

これをどう活かすか

今月の発表から出てくる実践的な助言は一貫している。請求書処理やアクセスレビューのように、狭く価値の高いプロセスを1つ選び、厳格なログ記録と承認を備えた既存システムの中にエージェントを1つだけ配置する。そして主要ベンダーがFusion Clawにどう反応するかを注視する。彼らが独自のオーケストレーション層を出荷するなら、1つか2つに標準化するほうが、さらに別の外部ゲートウェイを追加するより重要になるだろう。

より大きな変化は、発表の内容が似通っているために見落としやすい。エージェントの能力は見出しではなくなった。今や見出しは、エージェントに仕事、予算、そして引き綱を与えられるか、そして企業が事後に、エージェントが正確に何をしたのかを証明できるかどうかだ。

統合をめぐる問い

個々の発表から一歩引いて眺めると、構造的な問いが浮かび上がる。すべての主要プラットフォームが独自のオーケストレーション層を出荷すれば、購入企業は複数の重複するコントロールプレーンを抱え込むことになる。それぞれが独自のポリシー言語、独自の監査ログ、そしてエージェントに何を許可するかを記述する独自の方法を持つ。それは、ガバナンスが本来提供すべきものの正反対だ。標準化団体やオープンソースプロジェクトは、ポータブルなエージェントのアイデンティティと認可にすでに取り組んでいるが、商業的なインセンティブは逆方向に働く。独自仕様のコントロールプレーンは、顧客が離れない強力な理由になるからだ。

Oracleがこの層をERPに組み込むと決めたことで、この問題は具体的になる。Fusion Applicationsを運用する企業には、組み込みのオーケストレーションを使う明白な理由があり、それと突き合わせなければならない2つ目の外部層を信用しない、同じくらい明白な理由もある。ベンダーはそれを承知している。問いは、顧客がスイートごとに1つのコントロールプレーンという断片化したガバナンススタックを受け入れるのか、それともそれらすべてを横断して監査できる何かを求めるのか、という点だ。

短期的に最もありそうな答えはハイブリッドだ。ERPやCRMといったコアシステムは、すでに統制しているプロセスのオーケストレーションを担うだろう。監査証跡はトランザクションの隣に属するからだ。それ以外のすべて、つまり複数のシステムにまたがるエージェントを含めて、それらすべてと対話しようとする単体の層に依存することになる。プラットフォームを評価するチームは、両方を見据えて計画し、市場が統合された場合にポリシー定義を言い換えられるように設計しておくべきだ。

売り手が言わないこと

2つの主張は精査に値する。1つ目は、監査証跡が説明責任と等しいという主張だ。エージェントが下したあらゆる意思決定を記録するログは、インシデントの後に価値があるが、インシデントを止める統制とは同じではない。改ざん不能な記録と予防的なガードレールは別の製品であり、各発表はそれらを曖昧にしがちだ。2つ目は、プラットフォームが出荷した時点でガバナンスは解決済みの問題になるという主張だ。今月挙げられた失敗事例のほとんどは、設定ミスの権限、不明確なオーナーシップ、そしてエージェントが従えるほど正確にどのチームも記述できなかったプロセスに関わるものだった。ソフトウェアはポリシーを強制できる。しかし、ビジネスが実際にどのポリシーを望んでいるかは決められない。

実験段階を過ぎたチームにとって有用なのは、購入する前に答えを書き出すことだ。エージェントはどのプロセスに触れてよいのか、その範囲内で最悪何をしうるのか、そうなったときに誰が呼び出されるのか、そしてアクセスを要求するときエージェントはどのように識別されるのか。現在の助言にあるように、厳格なログ記録と承認を備えた既存システムの中にエージェントを1つ配置すれば、この4つの答えを一度に試すことになる。プラットフォームはそのテストを実行しやすくしてくれる。しかし、あなたに代わって実行はしてくれない。