Microsoftの新機能Hooks、毎回動くが失敗で素通り── 指示文の決まりは AI の判断しだいで働き、Hooks も失敗すれば素通りするので、止める操作は権限で塞ぐ

2026 年 10 月 6 日、Microsoft が Copilot Studio の AI エージェントに「Hooks」を加えたと報じられた。Hooks は、会話の始まりやツールの実行のたびに、あらかじめ結び付けたワークフローを必ず呼ぶ機能で、いまはプレビュー版として出ている。AI エージェントに毎回守らせたい社内の決まりは、指示文に書けば毎回守られるのか。守られるとは限らない。毎回働かせるには Hooks という外の仕組みが要り、Hooks が失敗した回にも止めるには、つないだ先のシステムの権限が要る。

01指示文に書いた決まりは、AI が必要と判断したときだけ働く

Microsoft の説明書は、ツールと Hooks の動き方を一つの表で書き分けている。ツールは、エージェントが「いまの話に関係がある」と判断したときにだけ動く。Hooks は、決めた出来事が起きるたびに動く。

指示文に書いた決まりも、読んで場面に当てはめるのはエージェント自身である。そのため私は、指示文の決まりもツールと同じく、AI が必要と判断したときにだけ働くと考える。

そうなると、社内の決まりを AI エージェントに守らせる場所は三つに分かれる。指示文、Hooks、そしてエージェントがつながる先のシステムの権限である。記録を残す、承認の有無を見るといった毎回要る決まりは、指示文から Hooks へ移す。送ってはいけないメールや消してはいけない記録といった、止めるべき操作は権限でも塞いでおく。Hooks の処理が失敗すると、その回は決まりが働かないまま、AI の作業が先へ進んでしまうからだ。

02Hooks は 6 種の出来事のたびにワークフローを呼び、その返事で次の動きを変える

説明書によると、一つの Hooks は「出来事」と「動作」の二つでできている。出来事は、エージェントの動きの中で Hooks が待ち受ける時点を指す。動作は、その時点で動かす中身で、いまは必ずワークフローになる。ワークフローとは、Microsoft の自動処理の仕組みで組んだ一連の手順のことだ。

出来事は 6 種ある。会話の開始、利用者の送信、ツール実行の前、ツール実行の後、ツールの失敗、ツールの外で起きたエラーである。出来事が起きると、Copilot Studio は結び付けたワークフローを呼ぶ。何が起きたかを渡し、ワークフローの返事を会話に戻す。

どの出来事でも、ワークフローには同じ情報が届く。Copilot Studio がワークフローに渡すのは、出来事の名前と時刻、そして会話や利用者についての付帯情報である。Microsoft はこの付帯情報を metadata と呼ぶ。metadata には会話の ID、利用者の ID と表示名、チャネル、エージェントの名前が入る。説明書は、利用者とエージェントの両方を記した監査の記録を書く使い方を例に挙げている。

範囲もはっきりさせておく。説明書の冒頭には、プレリリースの文書であり内容は変わりうると書かれている。Hooks を使えるのは、GitHub Copilot のハーネスという仕組みで動くエージェントとワークフローだけである。ハーネスとは、エージェントを動かす土台の仕組みを指す。作る・試す・使うには従量の課金がかかり、Copilot Credits を消費することがある。

03米国の医薬規則は 1997 年から、作業のたびの記録と、手順を決まった順に行うことを求めている

説明書は Hooks の用途として四つを挙げている。一つ目は、会話の始めに利用者の地域や未解決の案件を調べ、AI に渡す使い方だ。二つ目は、AI がツールを使う前に中身を見て、社内の決まりに反していれば止める使い方である。三つ目は、ツールの結果から機密の値を伏せたり、監査の記録を書いたりする使い方だ。四つ目は、失敗したときに再試行・飛ばす・中止のどれにするかを決める使い方である。

このうち二つの働きは、以前から規則で求められてきた。操作を毎回記録することと、決まった順序から外れた操作を止めることだ。少なくとも医薬品の電子記録の規則は、この二つを人の注意に頼らず、システムに担わせるよう求めてきた。その規則が、米国の 21 CFR Part 11 である。Part 11 は医薬品の電子記録と電子署名の扱いを定めた規則で、1997 年に公示された。このうち 11.10 条は、閉じたシステムで記録を扱う者に、次の手立てを求めている。

表の二つの列には、同じ働きが別の時代の言葉で書いてある。ただし、Part 11 が AI エージェントにそのまま当てはまるかを、私はこの記事で確かめていない。言えるのは一点だけである。記録を毎回残すことと手順の順番を守ることは、担当者の注意に任せず、システムに担わせる。医薬の世界では、この考え方が 1997 年から規則に書かれている。

Hooks を使う場面は、医薬以外にもある。説明書は二つの例を挙げる。一つは、問い合わせ窓口で、顧客の未解決の案件を会話の初めに渡す例だ。もう一つは、社内の質問への答えから機密の値を伏せる例だ。どちらも、担当者が気をつければ済むはずの作業である。それを Hooks で毎回確実に行う。

04エージェントは名前と説明を読み、ツールを呼ぶかを会話ごとに決める

Part 11 は、記録を残す作業を人の注意任せにしなかった。AI エージェントでは、ツールを使うかどうかを「調整役」と呼ばれる仕組みが決める。Copilot Studio のツールの説明書によると、調整役は利用者の発言を一つずつ見て、ツールが要るかどうかを決める。その際、調整役はツールの名前と説明文を読んで判断する。説明書は、この名前と説明文が決め手になると書いている。

記録を残すワークフローをツールとして置くと、記録を残すかどうかも調整役が決めることになる。そのため、会話の流れや説明文の書き方しだいで、記録の手順が呼ばれる回と呼ばれない回が出る。同じ手順を Hooks として登録すると、AI の判断に関係なく、出来事が起きるたびに手順が動く。

LLM は、やり取りを重ねると出来そのものが下がる。そういう測定がある。LLM は、ChatGPT などの土台にある大規模言語モデルである。Laban らの研究チームは 2025 年、主要な LLM を、何度もやり取りする会話と一度で頼む場合とで比べた。試したどのモデルも、やり取りを重ねると成績が大きく下がった。文章やコードを作る 6 種の課題で、成績は平均 39% 下がった。

この 39% は、課題の出来そのものが下がった幅を表す。AI がツールを呼び損ねた割合を測った数字とは別物である。それでもこの研究から、会話が長くなると LLM の答えの質が揺れることは分かる。決まりを守るかどうかを、エージェントが毎回思い出すことに頼る設計がある。その設計では、使う側は、この揺れがツールの呼び出しにも及ぶのかを確かめないまま受け入れることになる。

05Hooks が止められるのはツールを使う直前だけで、失敗すれば素通りする

Hooks はエージェントの判断を通さずに動く。それでも Microsoft の説明書は、Hooks の限界を二つ挙げている。

一つ目の限界は、Hooks が操作を止められる場面が一つしかないことだ。ツール実行の前に動く Hooks は、返事に deny と書けば、その呼び出しを止められる。Microsoft の説明書にも、止められるのはツールを使う直前だけだと明記してある。ほかの 5 種の Hooks は、AI に情報を足したり値を書き換えたりできる。けれども、AI エージェントの操作は止められない。

二つ目は、Hooks そのものが失敗したときの動きである。Hooks の処理が失敗したり時間切れになったりしても、AI エージェントは止まらない。エージェントは、Hooks から返事が無かったものとして次の作業へ進む。ワークフローから読み取れない返事が届いたときも同じ扱いになる。そのため、ツールを使う前に動く Hooks が失敗すると、止めるはずだった操作がそのまま実行される。

説明書はこの点に触れている。業務に欠かせない決まりを、Hooks だけで守ろうとしないよう注意している。Microsoft 自身も、Hooks を決まりを守る唯一の手段とは位置付けていない。

Hooks を設定する手順にも、見落としやすい点が一つある。ワークフローは保存しただけでは動かず、公開して初めて動く。Hooks を足したエージェントも、保存して公開するまで利用者の会話には効かない。試しの画面で動くかどうかと、利用者の会話で動くかどうかは、別々に確かめることになる。

06記録は Hooks に任せ、止める操作は権限でも塞ぎ、入力は疑う

Hooks が操作を止められるのは、ツールを実行する前だけである。また、Hooks の処理が失敗すれば操作はそのまま通る。この二つを踏まえると、決まりは置き場所ごとに分けて考えることになる。

記録を毎回残すよう指示文に書いても、AI エージェントが記録を残さない回は出うる。ツールが動くのは、エージェントが関係ありと判断した回だけだ。長い会話では、LLM が課題をこなす成績が平均 39% 下がるという測定もある。この 39% は呼び損ねの割合ではない。それでも、AI の判断に任せた部分の出来が揺れることは、この数字から読み取れる。抜けると困る記録は、出来事が起きるたびに必ず動く Hooks の側に登録しておく。こうすれば、記録の抜けを後から探す手間も減る。

止める決まりは、Hooks と権限の両方に置く。Microsoft の説明書は、大事な決まりを守る手段を Hooks だけにしないよう注意している。セキュリティの非営利団体 OWASP も、LLM への攻撃についての指針で二つの対策を挙げている。権限を必要な分だけにすることと、危険の大きい操作に人の承認を挟むことである。AI エージェントにデータを書き込む権限を最初から渡さなければ、Hooks が失敗した回でも書き込みは起きない。

三つ目は、Hooks に流れ込む文の扱いである。利用者の入力やツールの結果、エラーの文には、エージェントが作っていない文が混じりうる。Microsoft の説明書は、こうした文を信用せず、使う前に中身を確かめるよう求めている。プロンプトインジェクションは、入力に紛れ込ませた文で AI の動きを乗っ取る攻撃である。OWASP は、これを確実に防ぐ方法があるかは分からないとしている。判定のワークフローで入力の文をそのまま信じて使えば、判定そのものを操られうる。

07Hooks の失敗の頻度は未公表、使う側の手がかりは記録

決まりを三つの場所に分けて置いても、Hooks が実際に何回素通りしたかは、外から分からない。Microsoft は失敗の頻度を公表していない。説明書もプレビュー版の文書で、仕様は変わりうると断っている。

同じ考え方の仕組みは、別の会社の製品にもある。Anthropic の開発用 AI である Claude Code には、決まった時点で必ず動く hooks がある。Claude Code の説明書は、hooks なら LLM が選ぶのを待たずに特定の操作を必ず起こせると書く。そのため決定的に制御できるという。Anthropic の Claude Code も Microsoft の Copilot Studio も、毎回の処理を AI の判断に任せない作りになっている。ただし、この作りが今後ほかの製品へ広がるかは、手元の出典からは分からない。

使う側が確かめられるのは記録である。Copilot Studio には、エージェントの動きをたどる活動の記録がある。説明書は、不具合をこの記録で調べるよう案内している。導入する側は、公開の前に試しの会話を流し、Hooks の呼び出しと判定が記録に残るかを見ておく。

私が導入する側なら、ツール実行の前の Hooks を一度わざと失敗させてみる。止めるはずの呼び出しが通ってしまう様子を、自分の目で見ておくためだ。そうすれば、権限の側でも塞ぐ理由を上司や監査の担当者に具体的に説明できる。Microsoft が素通りの頻度を公表するまでは、この試しの記録が手がかりになる。失敗した回に何が通るかを、使う側はこの記録で確かめる。

指示文に書いた決まりをどの場面に当てはめるかは、AI エージェントが自分で判断する。毎回守らせたい決まりは Hooks に結び、止めるべき操作は接続先の権限でも塞いでおく。そうしておけば、Hooks が素通りした回にも決まりは残る。

Hooks は、指示文やツールと違い、AI の判断を通さずに決まりを毎回呼び出せる。けれども Microsoft 自身が、それだけに頼るなと書いている。決まりを一つ書き出すたびに、毎回要るか、止める必要があるかを問う。そのうえで置き場所を決める。この手間を省かないことが、エージェントに仕事を任せる人の責任になる。