目次
AIエージェントのPoCで、業務ルールはどこに書かれているだろうか。多くの現場では、答えは「プロンプトの中」である。「100万円を超える発注は担当者に回すこと」「顧客の個人情報は社外に送らないこと」「処理のたびに記録を残すこと」。こうした文章を指示書に並べ、デモで守られていることを確かめて、本番化の審査に進む。
ところが、本番化の審査で情報システム部門や内部監査から返ってくる問いは、たいてい同じだ。「そのルールは、必ず守られると言えるのか」。プロンプトに書いたルールは、モデルが読んで従おうとする「お願い」であって、守られることを保証する仕組みではない。この問いに答えられず、PoCが審査の手前で止まる例は少なくない。
2026年10月6日、Microsoftはこの問いに対する1つの答えを製品として出した。Copilot Studioの新機能「Hooks（フック）」である。本稿では、この発表を手がかりに、業務ルールをどこに置けば本番で守られるのか、そしてフックという仕組みにも潜む落とし穴を整理する。結論を先に言えば、問われているのは「ルールを書いたか」ではない。「破られたら事故になるルールを、モデルの外で、失敗しても素通りしない形で執行しているか」である。
10月6日、「エージェントの裁量」を外す仕組みが製品になった
2026年10月6日に同じ日に出た3つの発表。MicrosoftはCopilot StudioにHooksをプレビューで追加し、エージェントの判断を待たず、決められたタイミングで必ずワークフローを実行する。用途は開始時の文脈取得、実行前のルール検査と遮断、実行後のマスキングと記録、エラー時の対応。SAPはAutonomous Enterpriseを一般提供し、財務・サプライチェーン・購買・人事などの業務エージェントを提供、エージェントをシステム上の従業員として扱い人による監督と監査可能性を前提にすると説明。SailPointはAIエージェント向けの自律型ID統制を発表し、AIエージェントを本番運用する企業は79%、エージェント専用のID統制を入れた企業は2%と示した。業務エージェントが本番に入る日に、必ず守らせる仕組みも製品になった
Copilot StudioのHooksは、「イベント」と「アクション」の2つでできている。イベントはエージェントの動きの中の決まったタイミング、アクションはそのときに実行するワークフローだ。イベントが起きると、Copilot Studioは対応するワークフローを自動で呼び出し、何が起きたかの情報を渡し、返ってきた結果を会話に戻す。
これまでの「ツール」との違いは、誰が実行を決めるかにある。ツールは、エージェントが「いま必要だ」と判断したときにだけ呼ばれる。フックは、イベントが起きるたびに必ず動く。エージェントの裁量を挟まない。Microsoftが示した用途は次の4つだ。
- 開始時： 会話が始まる前に、顧客の問い合わせ履歴などを引いて文脈として渡す
- 実行前： エージェントがこれから行う操作を業務ルールと照合し、違反していれば止める
- 実行後： 個人情報を伏せる、応答の形式を整える、監査用の記録を作る
- エラー時： ツールが失敗したときに、やり直す・飛ばす・止めるを指示する
同じ考え方は、ほかの開発基盤にも広がっている。GitHub Copilot SDKは、セッションの開始から終了まで、ユーザーの入力やツールの呼び出しごとに独自の処理を差し込めるフックを提供している。Anthropicの開発者向けツールにも、ツール実行の前後に決まった処理を挟むフックの仕組みがある。「大事なことはモデルの判断に任せず、決まった場所で必ず実行する」という設計が、主要な基盤で標準になりつつある。
同じ10月6日には、ほかにも2つの発表があった。SAPは「Autonomous Enterprise」を一般提供とし、財務、サプライチェーン、購買、人事などの業務エージェントを揃えた。同社はエージェントを「システムの中の従業員」として扱い、人による監督と監査可能性を前提にすると説明している。ID管理のSailPointは、AIエージェント向けの自律型ID統制を発表し、同社の調査としてAIエージェントを本番運用している企業は79%、エージェント専用のID統制を導入している企業は2%という数字を示した。
基幹業務にエージェントが入る日に、エージェントに「必ず守らせる」ための仕組みも製品として出てきた。3つの発表を並べると、この構図が見えてくる。
なぜプロンプトに書いたルールは本番で崩れるのか
プロンプトに書いたルールはお願いにとどまることを示す3つのデータ。Intuit ASTRAは13モデルと10の業務場面で検証し、ルール順守スコアは上位0.88に対し下位は0.40未満、脱獄に強いモデルでもツール利用中はルールを破る。CSA調査は2026年4月公表で、エージェントが想定の権限を超えた経験のある組織は53%、一度もないは8%、過去1年の事故経験は47%。長い作業では、モデル間でルール順守率に46ポイントの差が開いたと報じられ、冒頭の指示ほど後半で優先されなくなる。違反は1回の行動ではなく行動の並びで起きる。顧客データを読み、社外へメールを送る。単独では許可された行動でも、続けば漏えいになる。モデルに覚えさせるのではなく、実行の直前に毎回確かめる必要がある
プロンプトのルールが本番で崩れることは、複数の調査で確かめられている。
Intuitの研究チームは2025年12月、エージェントがルールを守り続けられるかを測る試験の枠組み「ASTRA」を公開した。コーディング支援、売上分析、配送ドローンなど10の場面を用意し、13のオープンなモデルに複数手順の作業をさせた。ルール順守の指標は、上位のモデルで0.88〜0.89、下位では0.40を下回った。注目すべきは、一般的な「脱獄」の指示を拒否できるモデルでも、ツールを使う作業の中ではルールを破ったことだ。有害な文章を書かないことと、作業の途中で決められた手順を守ることは、別の能力なのである。モデルの大きさと順守の度合いにも、はっきりした関係はなかった。
企業の現場でも同じことが起きている。Cloud Security Alliance（CSA）が2026年4月に公表した調査では、53%の組織で、AIエージェントが想定した権限を超えて動いたことがあると答えた。「一度もない」と答えたのは8%にすぎず、47%は過去1年にAIエージェントが関わるセキュリティ事故を経験していた。
崩れやすさには、作業の長さも関わる。エージェントの作業が長くなるほど、冒頭に書かれた順守事項が後回しにされていく傾向が報じられており、モデルによって順守率に最大46ポイントの差があったという。指示書は文脈の先頭に置かれるため、長い作業の後半ほど影響が薄れやすい。
もう1つ、見落とされがちな点がある。2026年3月に公開されたKapteinらの論文は、企業が本当に防ぎたい違反の多くは、1回の行動ではなく「行動の並び」で起きると指摘する。顧客データを読む。社外にメールを送る。どちらも単独なら許可された行動だが、この順に続けば情報の持ち出しになる。プロンプトにどれだけ丁寧に書いても、モデルはそれまでの行動の履歴を毎回点検しているわけではない。
ここから言えるのは、プロンプトのルールは「守られやすくする」ことはできても、「守られることを保証する」ことはできないということだ。本番化の審査で問われる「必ず守られるのか」に答えるには、ルールの一部をモデルの外に出し、実行の直前に毎回確かめる仕組みが要る。
業務ルールは3つの層に分けて置く
業務ルールを置く3つの層。第1層はお願いで、プロンプトや指示書。性質は確率的で、守るかどうかはモデル次第、長い作業や外部入力で崩れる。置くものは口調、手順の目安、判断の観点など破られても事故にならないこと。第2層は必ず通るフック。性質は決定論的で、開始・実行前・実行後・エラー時に毎回必ず動く。置くものは金額上限や承認要否の検査、個人情報のマスキング、監査記録の作成。第3層は外で止めるポリシーエンジンとID統制。エージェントの外側で執行し、製品をまたいで同じ規程を当てられる。置くものは権限そのもの、全社共通の禁止事項、行動の並びに対する規程、即時停止。破られたら事故になるルールを第1層に置いたままにしない。例としてMicrosoft Agent Governance Toolkitは全行動を実行前に検査し、p99で0.1ミリ秒未満と公表
では、業務ルールをどこに置けばよいのか。実務では、次の3つの層に分けて考えると整理しやすい。
第1層は「お願い」、つまりプロンプトや指示書である。 確率的に効く層で、守られるかどうかはモデル次第だ。ここに置いてよいのは、口調や手順の目安、判断するときの観点など、破られても事故にならないことに限られる。
第2層は「必ず通る」、つまりフックである。 エージェントの動きの決まった場所で、毎回必ず実行される。金額の上限や承認が必要かどうかの検査、個人情報のマスキング、監査記録の作成など、その業務の中で必ず実行すべき確認や処理を置く。Copilot Studioの「実行前」のフックがまさにこれにあたる。
第3層は「外で止める」、つまりエージェントの外側にあるポリシーエンジンやID統制である。 Microsoftが2026年4月にオープンソースで公開した「Agent Governance Toolkit」は、エージェントのすべての行動を実行前に止めて規程と照合する仕組みで、判定にかかる時間はp99で0.1ミリ秒未満と公表されている。規程はYAMLやOPA Rego、Cedarといった形式で書け、LangGraphやOpenAI Agents SDKなど複数の開発基盤と組み合わせられる。SailPointが打ち出した「必要なときだけ権限を与える（Just-in-Time）」仕組みも、この層に入る。ここには、権限そのもの、全社共通の禁止事項、行動の並びに対する規程、即時停止の手段を置く。
第2層と第3層の違いは、どの範囲に効くかだ。フックはそのエージェント基盤の中で効く。Copilot Studioで作ったエージェントにはCopilot Studioのフックが効くが、SAPのエージェントやSaaSに組み込まれたエージェントには効かない。大企業では、複数の基盤でエージェントが同時に動くのが普通になる。全社で共通にしたい規程は、第3層に置かないと、基盤ごとに書き方も効き方もばらばらになる。
この整理を日本の大企業の言葉に置き換えると、次のようになる。決裁規程の金額基準や職務分掌は、第2層か第3層で執行する。個人情報や機密情報の扱いは、第3層で全社共通に縛り、各エージェントの第2層でもマスキングを重ねる。第1層の指示書は、「業務マニュアル」に近い位置づけになる。マニュアルを渡しただけで内部統制が効いているとは言わないのと同じで、プロンプトにルールを書いただけで統制が効いているとは言えない。
落とし穴：フックが落ちると、検査は素通りになる
フックが落ちたらエージェントはどうするか。Copilot Studio Hooksの注意点として、プレビュー時点では失敗・タイムアウト・読めない応答のとき、エージェントは結果なしとして続行する。fail-openは素通りで、検査が落ちても処理は進む。利点は業務が止まらないこと、危険は検査済みに見えて未検査になること。向く処理は要約の整形、補助情報の付与、分析用ログ。fail-closedは止める設計で、検査が落ちたら実行しない。利点は未検査の実行が起きないこと、代償は検査側の障害で業務が止まること。向く処理は送金・発注・外部送信、個人情報の持ち出し、権限変更。どちらにするかは技術の設定ではなく業務ごとの経営判断。fail-closedにしたい処理は、検査の結果が許可と明示されたときだけ実行する作りにする
フックは強力だが、導入すれば安心というものではない。Copilot Studioのフックについては、重要な注意点が示されている。フックとして呼んだワークフローが失敗したり、時間切れになったり、エージェントが読めない応答を返したりした場合、エージェントは「フックが何も返さなかった」ものとして処理を続ける。つまり、フックはエージェントを止めない。
これは、システム設計の言葉でいう「fail-open（失敗したら開く）」の動きだ。検査が落ちても業務は止まらない。その代わり、検査が実際には行われていないのに、外からは「フックで検査している」ように見える状態が生まれる。
反対の考え方が「fail-closed（失敗したら閉じる）」である。検査が落ちたら、その操作は実行しない。未検査の実行は起きないが、検査側に障害があれば業務も止まる。
どちらが正しいということはない。要約の書式を整えるフックや、補助的な情報を付け足すフックなら、落ちても業務を続けたほうがよい。一方で、送金や発注、社外への送信、個人情報の持ち出し、権限の変更につながる操作の前に置く検査は、落ちたら止めるべきだ。どちらにするかは技術の設定ではなく、業務ごとのリスクをどこまで許容するかという経営判断である。
fail-closedにしたい処理では、作り方にも注意が要る。フックが「違反」と返したときに止めるのではなく、フックが明示的に「許可」と返したときだけ実行する形にしておく。こうすれば、フックが落ちても、時間切れになっても、操作は実行されない。プレビュー段階の機能では仕様が変わる可能性もあるため、正式提供の時点で、失敗時の挙動をあらためて確かめる必要もある。
日本の大企業にとって、この論点は特に重い。内部統制の評価では、「統制が設計されているか」だけでなく、「期間を通じて有効に運用されていたか」が問われる。フックが一定の割合で黙って落ちていたなら、その間の取引は統制を通っていないことになる。統制を入れたことではなく、統制が効いていた証拠を示せるかが、本番化の審査でも、その後の監査でも問われる。
本番化の前に入れる4つの実務
本番化の前に入れる4つの実務。1つ目はルールの仕分けで、プロンプト内の禁止・必須事項を破られたら事故かで仕分け、事故になるものを第2層・第3層へ移す。2つ目は失敗時の動作を決めることで、フックごとに素通りか停止かを業務部門と決め、決裁規程・職務分掌と対応づけて記録する。3つ目はフック自体を試験することで、違反する操作をわざと流し止まることを確かめ、検査側の障害や遅延も再現して試す。4つ目は運用の指標にすることで、遮断件数・フック失敗率・素通り件数を毎週見る。失敗率の上昇は事故の予兆。ルールを書いたではなくルールが効いている証拠を示せる状態が本番化の条件
では、PoCを本番に進める前に、何をしておけばよいのか。次の4つを勧めたい。
1. ルールの仕分け。 PoCのプロンプトに書かれている禁止事項と必須事項をすべて書き出し、1つずつ「これが破られたら事故になるか」で仕分ける。事故になるものは、第2層のフックか第3層のポリシーに移す。多くのPoCでは、この棚卸しをするだけで、本番化の審査で突かれる論点の大半が見えてくる。
2. 失敗したときの動作を決める。 フックごとに、落ちたら素通りさせるか止めるかを決める。この判断は開発者に任せず、業務部門とリスク管理部門が加わって決め、決裁規程や職務分掌のどの条項に対応するかとあわせて記録しておく。これが、審査や監査で「なぜこの設計なのか」を説明する根拠になる。
3. フックそのものを試験する。 エージェントの出力を評価するだけでなく、統制が効くことを試験する。規程に違反する操作をわざと流して止まるかを確かめ、検査側のワークフローを止めたり遅らせたりして、そのときにエージェントがどう振る舞うかも確かめる。この試験は一度きりではなく、モデルやプロンプトを変えるたびに回帰試験として流す。
4. 運用の指標にする。 本番稼働後は、フックが遮断した件数、フック自体が失敗した割合、失敗して素通りになった件数を、毎週見る指標に加える。遮断件数の急増はエージェントの振る舞いの変化を、フック失敗率の上昇は統制の穴を知らせる予兆になる。
この4つは、本番化を阻む5つの壁のうち、ガバナンスの壁と指標の壁に直接効く。ガバナンスの壁は、規程を「書いた」だけでは越えられず、規程が「効いている」と示せて初めて越えられる。そして、効いていることを示すには、遮断件数や失敗率といった数字が要る。
まとめ ― 「ルールを書いた」から「ルールが効いている」へ
10月6日の3つの発表は、AIエージェントが基幹業務に入っていく段階で、何が問われるようになるかを示している。SAPの業務エージェントが一般提供され、エージェントを本番で動かす企業は8割に迫る。一方で、エージェントに合わせた統制を入れている企業はまだごく一部だ。その隙間を埋める道具として、フックやポリシーエンジン、エージェント向けのID統制が揃い始めた。
ただし、道具は道具である。Copilot Studioのフックが示すように、検査の仕組みそのものが落ちたときにどう振る舞うかまで決めておかなければ、統制は「あるように見えるだけ」になる。そして、どのルールを外に出し、どこで止め、何を許容するかは、各社の業務と規程を知る人にしか決められない。経営会議で問うべきは「エージェントにルールを教えたか」ではなく、「破られたら困るルールが、どこで、どう執行され、効いている証拠がどこにあるか」である。
Wizitは、PoCで止まったAIを本番運用とROIまで動かし切る実装パートナーとして、大企業の現場でこうした本番化の設計に取り組んでいます。PoCのプロンプトに埋もれた業務ルールの棚卸しから、フックとポリシーへの移し替え、失敗時の動作と決裁規程の対応づけ、統制が効いていることを示す運用指標の設計まで、業務部門・情報システム部門・リスク管理部門の間に入って手を動かす形でご支援しています。
---
出典:
- Cloud Wars「Need AI Agents to Run Workflows With No Exceptions? Microsoft Has a Hook for That」（2026年10月6日）
- SiliconANGLE「SAP expands Joule into an agentic work layer as Autonomous Enterprise goes live」（2026年10月6日）
- Compare the Cloud「SailPoint launches autonomous identity agents to address governance gap affecting 79% of enterprises」（2026年10月6日、SailPoint「Horizons of Identity Security」レポートに基づく）
- GitHub Docs「Working with hooks」（GitHub Copilot SDK）、Anthropic「Claude Code Hooks」ドキュメント
- Help Net Security「AI agents break rules in unexpected ways」（2025年12月9日、Intuit の ASTRA に関する研究）
- Cloud Security Alliance「More Than Half of Organizations Experience AI Agent Scope Violations」（2026年4月16日、Zenity 委託調査）
- Maurits Kaptein ほか「Runtime Governance for AI Agents: Policies on Paths」（arXiv:2603.16586、2026年3月17日）
- Microsoft Open Source Blog「Introducing the Agent Governance Toolkit」（2026年4月2日）、Help Net Security（2026年4月3日）
- KuCoin News「AI Agents Gradually Ignore Compliance Rules as Sessions Grow Longer」（長時間セッションでの順守率低下に関する報道）