HooksとJoule：エンタープライズエージェントにコントロールプレーンが登場

--- title: HooksとJoule：エンタープライズエージェントにコントロールプレーンが登場 slug: hooks-and-joule-enterprise-agents-get-a-control-plane meta_title: エンタープライズエージェントにコントロールプレーンが登場 meta_description: MicrosoftはCopilot StudioにHooksを追加し、ワークフローがエージェントの判断ではなくイベントで起動するようにした。一方SAPはJouleをガバナンスされたエージェント型ワークレイヤーへと押し進めた。 category: ai tags: Microsoft Copilot Studio,Hooks,SAP Joule,エージェント・ガバナンス,決定論的ガードレール,エンタープライズAI,ワークフロー自動化,コントロールプレーン ---

MicrosoftとSAPは今月、数日違いでエージェント機能を投入した。そしてこの2つのリリースは同じことを認めている。ビジネスワークフローを開始するかどうかをモデルに決めさせるのは、信頼性リスクである。

MicrosoftのHooksが行うこと

Microsoftは、Hooksと呼ばれるCopilot Studio機能をプレビュー中である。これは、エージェントが実行すべきだと判断したときだけでなく、何かが起きたときにエージェント型ワークフローを自動的に実行する。フックには2つの部分がある。エージェントのライフサイクルが発するイベントと、そのイベントの発生時に起動するアクションである。イベントがトリガーされると、Copilot Studioはバインドされたワークフローを呼び出し、何が起きたかに関する詳細を渡し、ワークフローの応答を会話へ読み戻す。

ツールとの違いが要点である。ツールは、エージェントが関連性があると判断したときに実行される。フックは、イベントが発生するたびに実行される。

Microsoftは4つのシナリオを挙げている。会話が始まる前に未解決のサポートケースを検索し、セッション開始時にコンテキストを追加する。ツールが実行される前に検査し、ビジネスルールに違反する場合はアクションをブロックする。機密データを墨消ししたり、監査記録を書き込んだりして、ツールの結果を後処理する。失敗を処理し、エージェントに再試行、スキップ、または停止するよう指示する。

注意点は機能そのものと同じくらい有益である。フックは特定のエージェントに紐付けられ、フックを追加してもその下にあるワークフローは変わらない。フックは失敗してもエージェントを停止しない。ワークフローがタイムアウトするか、読み取れないものを返した場合、エージェントはフックが何も返さなかったかのように続行する。ワークフローは公開されなければ実行されない。入力は信頼できないものとして扱うべきであり、ワークフローを編集するとそれを使用するすべてのフックに影響する。

最後の点は、静かな保守上の危険である。1つのワークフローが複数のエージェントにサービス提供できるため、あるユースケース向けの変更が他のエージェントにも波及する。共有アーティファクトに宿るガバナンスにはバージョン管理の規律が必要であり、それはほとんどの自動化チームがこれまで構築する必要がなかった能力である。

この設計には、名指しする価値のあるギャップもある。静かに失敗するフックは、何も制御しない制御である。Microsoftが入力を検証するよう促しているのは重要である。エージェントは本当の回答と空の回答を区別できず、後からログを読む監査人も区別できないからだ。

SAPが同じ時期に行ったこと

SAPはJouleアシスタントを、自社がエージェント型ワークレイヤーと呼ぶものへと拡張し、Autonomous Enterpriseイニシアチブと結び付けた。同社によると、エージェントハブは現在、約150社にまたがる10万以上のエージェントを監督しており、50以上のドメインアシスタントが200以上の専門エージェントをオーケストレーションしている。また、Autonomous Close Assistantは財務クローズを数週間から数日へ圧縮できると主張している。

両者を合わせて見ると、パターンは明らかである。ベンダーは解釈と意思決定を分離しつつある。モデルは請求書を読み取り、コードが支払われるかどうかを決める。

タイミングは偶然ではない。両ベンダーは、顧客の導入環境で同じ失敗パターンを目の当たりにした。デモでは機能したエージェントが、本番環境で誰も見ていない瞬間に誤った判断を下すのだ。その修正は、意思決定をモデルの外へ移すものである。

この変化を買い手にわかりやすくするガバナンスの枠組みがある。規制当局は、エージェントが安全かどうかという問いから、安全でない場合に誰が支払うのかという問いへ移行した。決定論的トリガー、必須分岐、監査証跡を指し示せるベンダーには答えがある。自律性を売るベンダーにはない。

なぜ密度が変化を強制するのか

10万エージェントになると、ボトルネックは能力ではなく監督になる。各エージェントが何をし、なぜそうし、誰の権限で行ったのかを知ることは、エージェントを動かすこととは別の問題である。

SAPが報告した数字は、この点を具体的にする。50以上のドメインJouleアシスタントが200以上の専門エージェントをオーケストレーションし、約150社で展開され、Autonomous Close Assistantが財務クローズを数週間から数日へ圧縮している。その密度では、非公式な監督は破綻する。誰もすべてのトレースを読まず、重要な失敗とは誰も気づかない失敗である。

コストも同じ形をしている。Copilot Studioの価格に関する実務家の分析の1つは、Copilot Creditあたり約0.01ドルと見積もっており、アクションのコストは1～100クレジット、典型的なグラウンディング付きワークフローは約30クレジット、つまり約0.30ドルである。ボリュームが来るまでは取るに足らないように見える。10万回の実行は約3万ドルであり、エージェントは人間がクリックするのを待たない。月間消費量の厳格な上限は、管理者の好みではなくアーキテクチャ要件になる。

第3の圧力もある。開発者の間で週次のAIコーディングエージェント利用率が90％とする調査もあるように、これらのワークフローの土台にあるロジックの多くはそれ自体が機械によって起草されている。それにより、テストゲート、コードレビュー、再生可能なログの価値が高まる。90％という数字の出典はJetBrainsの調査であり、より速いコード生成が自動的により速いデリバリーを生むわけではないという並行する知見とも一致する。

3層パターン

そこから導かれるアーキテクチャは3つの部分から成る。インテント層はモデルに雑然としたリクエストを解釈させる。決定論的実行層は、小さく、ステートレスで、テスト可能な関数を実行する。コントロールプレーンは、予算、権限、監査証跡を強制する。

サーバーレスエッジワーカーは中間層に適している。リクエストあたりのコストが低く、分離されており、バージョン管理も容易だからだ。このパターンは目新しいものではない。決済システムが信頼できない入力を常に扱ってきた方法に似ている。変わったのは、業界が今やインシデントの後ではなく、デフォルトでこれをエージェントに適用していることである。

Microsoft自身が挙げるユースケース一覧は、このパターンにきれいに当てはまる。セッション開始時のコンテキスト追加、ツール実行前の検証、結果の後処理、失敗の処理はすべて、ライフサイクルにおけるインターセプトポイントである。Hooksはそれらを、決定論的コードがエージェントのこれから行おうとしていることを確認できる場所として形式化する。

このワークフロー設計には副次的な利点がある。エージェントの振る舞いを事後に説明可能にするのだ。入力と出力をログに記録するフックは、エージェント自身が決して生成しない監査記録を生み出す。規制当局に説明責任を負うチームにとって、その記録は、意図した振る舞いを説明することと実際の振る舞いを実証することの違いである。

繰り返す価値のある警告が1つある。単一ベンダーのスタジオ内に書かれたガバナンスロジックは、借りているガバナンスロジックである。重要なビジネスルールは、移行可能なコードに置くべきである。耐久性のある価値が今やコントロール層にあるからだ。

競争環境を読み解くと、両ベンダーは異なる出発点から同じ結論に到達した。SAPはビジネスプロセスソフトウェアから来ており、承認ルーティングが母国語である。Microsoftはローコードスタジオから来ており、トリガーと条件はすでにおなじみである。どちらももはや自律性を売っていない。両方とも「ノー」と言う能力を売っている。

この枠組みは、買い手がこれらの製品を評価する方法も変える。もはやどのエージェントが最も賢いかという問題ではない。無人で実行できるほど正確に制約できるのはどれか、そして予期しないことをしたときに記録を残すのはどれかである。