1. はじめに 2026年8月5日、Kiro Crewが公開されました。 https://kiro.dev/crew/ Kiro Crewは、Kiro CLIを実行基盤として、自分のPCやサーバー上で動かせるオープンソースの開発ワークスペースです。 公式ページでは、セッションをまたぐMemory、定期実行、長時間タスク、複数エージェントの並列実行、Webダッシュボードなどが紹介されています。Kiro IDEやKiro CLIを置き換えるというより、Kiro CLIと既存の.kiro設定を使いながら、作業をセッションの外まで広げるプロダクトという位置付けです。 今回はEC2上のUbun

PSSL の佐々木です 移動中に Claude Code を回しておきたいのですが、満員電車でノート PC を開くのは無理です。カバンに入れたまま処理だけ走らせておきたいです。 そうすると解決したい問題が 2 つ出てきます。 フタを閉じるとスリープして処理が止まる テザリングだとスマホのバッテリーが減るうえ、PC とスマホが不意に離れると Wi-Fi が切れる この 2 つを潰す設定をまとめます。Windows 側はすべて PowerShell で完結させます。 最近はPCがスリープしないようにちょっとだけPCを開けたまま手に持ち歩く人もいるみたいですが、PCを落としたり普通に邪魔なのでカバンに入れた状態でもClaudeが動くための環境を作りました。 この設定は普通に会社から怒られるかもしれないので自己責任でお願いします。 1. フタを閉じても止めない 管理者権限の PowerShell で実行します。 powershell # フタを閉じたときの動作を「何もしない」に（バッテリー駆動時） powercfg /setdcvalueindex SCHEME_CURRENT SUB_BUTTONS LIDACTION 0 # 電源接続時も同様 powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS LIDACTION 0 # スリープ移行そのものを無効化（0 = 無効） powercfg /change standby-timeout-dc 0 powercfg /change standby-timeout-ac 0 # ディスプレイは切ってよい（1分） powercfg /change monitor-timeout-dc 1 # 反映 powercfg /setactive SCHEME_CURRENT LIDACTION の値です。 0 ... 何もしない 1 ... スリープ 2 ... 休止状態 3 ... シャットダウン 現在値の確認はこちら。 powershell powercfg /query SCHEME_CURRENT SUB_BUTTONS powercfg /a # モダンスタンバイ対応かの確認 WSL 側も落ちないようにしておきます。 %USERPROFILE%\.wslconfig に追記して wsl --shutdown 。 ini [wsl2] vmIdleTimeout = -1 処理自体は tmux の中で回しておくと、復帰後にそのまま続きが見られます。 bash tmux new -s claude claude --dangerously-skip-permissions # Ctrl+b → d でデタッチ   Macの場合はさらに簡単でamphetamineというアプリを入れておくと蓋を閉じてもスリープしなくなります。 https://apps.apple.com/jp/app/amphetamine/id937984704?mt=12 2. テザリングをやめてリチャージWi-Fiにする テザリングをやめる理由は 2 つです。スマホのバッテリーが目に見えて減ること、そして満員電車で体勢が変わって PC とスマホが離れると Wi-Fi が切れることです。これを解決するためにリチャージWi-Fiを買いました。 リチャージWi-FiはTypeCをPCに直刺しするとネットにつながります。(特に設定もなく、さしてしばらくするとネットにつながるようになります。) リチャージWi-Fiは100GB8000円ぐらいから売っていて、100GB使い切ったらポータルサイトでチャージするとまた使えるようになります。 https://www.amazon.co.jp/【リチャージWiFi】バッテリーレス-100GB-リチャージ-一体型【M4-100GB-365日】/dp/B0DXVNKZ8T/ref=asc_df_B0DXVNKZ8T?mcid=c2d7374fee12300a9c74a8ba8ade9134&tag=jpgo-22&linkCode=df0&hvadid=707549940401&hvpos=&hvnetw=g&hvrand=8194794017880763317&hvpone=&hvptwo=&hvqmt=&hvdev=c&hvdvcmdl=&hvlocint=&hvlocphy=1009285&hvtargid=pla-2444400325634&psc=1&hvocijid=8194794017880763317-B0DXVNKZ8T-&hvexpln=0 カバンにPCを入れるとこんな感じです。リチャージWi-Fiが映えますね カバンが汚いのは見なかったことにしてください。   3. 注意：フタを開けたら充電が空になっていることがある ここまでやると、フタを閉じてもディスプレイが消えるだけで中身は全力で動き続けます。当然ながら バッテリーの減りはかなり速い です。 私は移動中に走らせたまま忘れて、目的地でフタを開けたら電源が落ちていた経験があります。 客先での商談がある場合には注意が必要が必要です。 そのため、 カバンにはモバイルバッテリー（PD 対応）を一緒に入れておく 長時間走らせるときは充電しながらにする 移動が終わったら設定を戻す 4. まとめ 満員電車で立ったまま何もできない時間が、そのまま実行時間になります。設定は 10 分で終わるので、通勤が長い方は一度入れておくと効きます。 次は軽くて大容量のバッテリーが欲しいです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post 満員電車でも Claude Code を動かし続ける技術 first appeared on SIOS Tech Lab .

1.はじめに 2.背景・目的：なぜ外側からの統制が必要か 3.検証対象：Agent Governance Toolkit と今回確認した範囲 4.検証の概要：実行条件 5.STEP 1の検証結果：3つの統制機能は何をしているか 5-1.ポリシー適用：何を許可・記録・遮断するか 5-2.ゼロトラストエージェントID：最上位に誰を置くか 5-3.信頼性エンジニアリング：統制の状態をどう観測するか 6.STEP 2の検証結果：実際のAIエージェントで実行前に介入できるか 補足：Claude Code の「ツール」と「フック」 6-1：統制ツールの判定で、ツール使用が確認待ちになる 6-2：危険な操作はAIエージェント自身が先に止めることもある 7.考察：3つの機能から見えてくること 8.まとめ：AIエージェントを統制するために必要なこと 付録：検証に使った手順 執筆者 商標 1.はじめに 本記事では、Microsoft が公開している AIエージェント統制向けのオープンソースツール「Agent Governance Toolkit」を動かし、 AIエージェントの行動を外側から統制する仕組み が、実際にどのように働くかを観察しました。 なお、Agent Governance Toolkit は、2026年6月時点で Public Preview として公開されています。 対象読者 ：AIエージェントの企業導入、AIガバナンスの仕組みづくりに関心のある方 ※本記事は2026年6月時点の情報に基づいています。 2.背景・目的：なぜ外側からの統制が必要か AIエージェントの企業導入が進むと、「便利に使えるか」だけでなく、「使わせてはいけない操作をどう止めるか」「誰が最終的に責任を持つか」「期待した範囲で動いているかをどう継続的に観測するか」も課題になります。 前回の記事 では、Claude金融エージェントを題材に、AIエージェントの出力に HITL（Human-in-the-Loop：人間が確認・承認する仕組み） がどのように組み込まれているかを観察しました。HITL は重要な仕組みですが、AIエージェント自身が出力で「承認が必要」と示しても、それだけでは実行時の強制力としては不十分な場合があります。指示の取り違えや不正な入力の影響により、宣言と異なる動作をする可能性があります。 そのため、AIエージェントにすべてを委ねるのではなく、行動が実際に起きる手前で、外側の独立した仕組みによって判定・記録・制御する考え方が必要になります。 本記事では、この「外側からの統制」を実際に動かして確認します。Microsoft の Agent Governance Toolkit が提供する複数の統制機能を試し、それぞれが何をしているのか、どこまで強制力を持つのかを観察しました。 3.検証対象：Agent Governance Toolkit と今回確認した範囲 Agent Governance Toolkit は GitHub 上で公開されており *1 、AIエージェントの統制に関するいくつかの機能を含んでいます。 このツールが扱う主な統制の領域は、README の記載をもとに、本記事では次のように整理しました。 領域 内容 本記事での扱い ポリシー適用 行動をルールに基づいて許可・記録・遮断する 確認する ゼロトラストエージェントID どのAIエージェントの行動かを見分け、信頼関係や権限を扱う 信頼性エンジニアリング AIエージェントの動作状態や異常を継続的に観察する 実行サンドボックス AIエージェントが動作する環境を切り離し、影響の及ぶ範囲を抑える 対象外 本記事では、このうち「 ポリシー適用 」「 ゼロトラストエージェントID 」「 信頼性エンジニアリング 」の3つを実際に動かして確認しました。 一方「実行サンドボックス」は、AIエージェントが動作する環境を切り離す機能ですが、この機能は実行環境の構成に左右される部分があり、今回の検証環境では確認対象外としました。 4.検証の概要：実行条件 検証の考え方 このツールでは、AIエージェントが実行しようとする行動、たとえば「どのツールを使うか」「どのようなコードを実行するか」といった情報を入力すると、あらかじめ定めたルールに従って判定結果を返します。 本検証は、2段階で行いました。 STEP 1では、AIエージェントが「こういう行動をしようとした」という状況をデータとして与え、Agent Governance Toolkit 単体で各機能の判定や出力を確認しました。 STEP 2では、実際のAIエージェント（本検証ではClaude Codeを使用）に統制機能を組み込み、ツール使用の手前で外側の仕組みが介入するかを確認しました。 実行環境 STEP 1は、WindowsのPowerShellからツールを導入し、Python環境で判定の仕組みを単体で確認しました。STEP 2では、Claude Code にAgent Governance ToolkitのClaude Code用サンプルを組み込み、実際のツール使用に介入する様子を確認しました。 STEP 項目 内容 1 実行基盤 PowerShell、Python 3.13.11 ツール Agent Governance Toolkit （本検証では agent-os-kernel を利用） 2 実行基盤 Claude Code 2.1.150 （Node.js 24.18.0 経由のプラグインを使用） ツール Agent Governance Toolkit の Claude Code 用公式プラグイン（agent-governance-claude-code）。 ポリシーは examples/claude-code-agt の例を使用 導入方法 GitHub リポジトリのクローン、pip・npm でのインストール いずれのバージョンも本検証時点のものです。 5.STEP 1の検証結果：3つの統制機能は何をしているか ここからは、実際に動かした3つの機能を順に見ていきます。それぞれ、「 ポリシー適用（行動を判定する） 」「 ゼロトラストエージェントID（ 誰の行動かを識別する） 」「 信頼性エンジニアリング（ 全体を観測する） 」という、異なる役割を持っています。 5-1.ポリシー適用：何を許可・記録・遮断するか 最初に確認したのは、AIエージェントの行動をルールに従って判定する機能です。判定のルールは、AIエージェントのコードの中ではなく、独立した設定ファイル（YAML形式）として記述しました。制御ルールをAIエージェント本体から切り離して管理する、というこのツールの基本的な考え方に沿ったものです。 動かす前は、ルールによる制御とは「許可」か「遮断」かの二択を返すものだと考えていました。実際に動かしてみると、判定には「記録（監査）」という第3の選択肢があり、さらに判定結果が証跡として残るようになっていました。 判定の種類（許可・記録・遮断） AIエージェントの行動を表すツール名を入力として与え、「破壊的な操作は遮断」「メール送信は記録対象」というルールで判定させた結果です。 入力された行動 判定 効いたルール web_search（Web検索） 許可（allow） なし（初期設定） read_file（ファイル読取） 許可（allow） なし（初期設定） send_email（メール送信） 記録（audit） audit-email-send delete_file（ファイル削除） 遮断（deny） block-destructive execute_code（コード実行） 遮断（deny） block-destructive 注目したいのは、判定が「許可」「遮断」の二択ではなく、その中間に「 記録（audit） 」がある点です。記録は、行動自体は通すものの、後から確認できるよう証跡を残す判定です。メール送信のように、一律に禁止はできないが、誰がいつ送ったかは把握しておきたい操作に対応します。なお、今回のポリシーで確認できたのは許可・記録・遮断の3種類ですが、これはこのツールが扱う判定のすべてではありません。 ルールはYAMLファイルに記述されているため、変えたいときはAIエージェント本体に手を入れるのではなく、ファイルを差し替えるだけで済みます。 監査ログ（何が記録されるか） 判定の内容は、証跡として残ります。ファイル削除を遮断した1件の記録です。 { "policy": "business-agent-policy", "rule": "block-destructive", "action": "deny", "context_snapshot": {"tool_name": "delete_file", "agent_id": "demo-agent"}, "timestamp": "2026-06-25T06:45:24.694632+00:00" } context_snapshot に、判定の対象となった行動の中身（どのAIエージェントが、どのツールを使おうとしたか）が記録されています。これにより、後から「いつ、どのAIエージェントが、何をしようとして、どう判定されたか」をたどれます。遮断した行動だけでなく、許可した行動についても同じ形式で記録が残り、 止めたものだけでなく通したものも含めて1件ずつ記録する 動作を確認できました。 内容ベースの制御（行動の中身で判定する） ツール名だけでなく、渡される中身そのものを見た判定もできます。「危険な文字列を含む場合は遮断」というルールでの結果です。 入力された実行内容 判定 効いたルール SELECT * FROM users 許可 なし（無害な参照） DROP TABLE users 遮断 block-sql-injection ls -la 許可 なし（無害な一覧表示） rm -rf /data 遮断 block-shell 同じ「データベース操作」でも参照（ SELECT ）は許可され、テーブル削除（ DROP TABLE ）は遮断されています。行動の種類だけでなく、その中身を見て、危険なものだけを遮断していることが確認できました。一方で、今回遮断できたのは、 DROP TABLE や rm -rf を危険な文字列として、あらかじめルールに書いていたからです。企業では、対象となるシステム、データベース、API、業務操作が多く、危険な操作のパターンも業務ごとに異なります。したがって実運用では、何を危険とみなすかをどう設計し、そのルールを誰が維持するかが大きな課題になります。 5-2.ゼロトラストエージェントID：最上位に誰を置くか 次に確認したのは、AIエージェントを見分け、権限の階層を管理する機能です。ポリシー適用が「どの行動を許すか」だったのに対し、こちらは「誰の行動か」「誰が最終的に判定するか」を扱います。 階層の検証 AIエージェントの統制を階層構造で考えたとき、その最上位（最終的な判定者）に誰を置けるかを確認しました。 設定 階層 AIか 判定 human-controller 最上位（level 0） いいえ 受理 ai-supervisor 最上位（level 0） はい 拒否 team-lead-agent 下位（level 1） はい 受理 注目したいのは、今回確認した階層の設定では、 最上位（level 0）にAIエージェントを置こうとすると拒否され、人間を最上位に置く構成が求められた 点です。AIエージェントは下位（level 1）には置けますが、この設定では最終的な判定をする最上位（level 0）には置けませんでした。 これは、AIエージェントが別のAIエージェントの行動を最終承認してしまう、という状況を構造として防ぐ仕組みと考えられます。前回の HITL が「人間が確認する」という運用だったのに対し、こちらは「最終的な判定は人間側に置く」という考え方を、判定の仕組みそのものに組み込んでいます。 5-3.信頼性エンジニアリング：統制の状態をどう観測するか 3つ目に確認したのは、統制システム全体の状態を、数値として観測する機能です。1件ずつの判定（ポリシー適用）を集計し、全体の状態を把握する役割です。 この機能は、AIエージェントの行動判定が起きるたびに数値を記録する想定で動かしました。今回確認した範囲では、違反の検出数、遮断数、リクエスト数などを、監視でよく使われる形式（Prometheus形式）の数値として出力できました。 agent_os_violations_total{action="delete_file",severity="high"} 1.0 agent_os_violations_total{action="execute_code",severity="high"} 1.0 agent_os_violations_blocked_total{action="delete_file"} 1.0 agent_os_requests_total{action="web_search",status="allow"} 1.0 agent_os_requests_total{action="read_file",status="allow"} 1.0 agent_os_requests_total{action="delete_file",status="deny"} 1.0 agent_os_active_agents 1.0 それぞれの指標の意味は以下のとおりです。 指標 意味 violations_total 検出した違反の総数（行動・深刻度ごと） violations_blocked_total 遮断した違反の数 requests_total 処理したリクエスト数（許可・遮断の状態ごと） active_agents 現在動いているAIエージェントの数 注目したいのは、各指標が行動や状態の ラベル付き で記録される点です。これにより、「どの行動で、どの深刻度の違反が、何件起きたか」「許可と遮断がそれぞれ何件か」を集計できます。こうした指標を継続的に集めれば、統制の状態を時系列で観測することにつなげられると考えられます。 6.STEP 2の検証結果：実際のAIエージェントで実行前に介入できるか STEP 2では、実際のAIエージェントを動かし、その行動が外側の仕組みで実行前に介入されるかを確認しました。題材には、Claude Code を使いました。Agent Governance Toolkit には、Claude Code に統制を組み込むための公式サンプルが用意されています。これを使うと、Claude Code がツールを使おうとする手前で、ポリシーに基づいた判定を挟むことができます。 補足：Claude Code の「ツール」と「フック」 このSTEPの土台となる2つの言葉を整理します。 ツール と フック です。外側からの統制が「いつ、どこで」働くかは、この2つで決まります。 Claude Code のようなAIエージェントは、ファイルを読む・書く、コマンドを実行するといった操作を、 ツール と呼ばれる機能で行います。AIエージェントが「ファイルを書き換えたい」「コマンドを実行したい」と判断すると、対応するツールを呼び出します。 用語 意味 どこが行うか ツール AIエージェントが外部環境に対して行う操作機能 Claude Code Read ファイルを読む Write ファイルに書く Bash シェルコマンドを実行する フック ツールが実行される手前で、外部の処理に橋渡しする組み込み口 ポリシー判定 渡された情報を、許可・確認・遮断に振り分ける Agent Governance Toolkit ここで外側からの統制で最も重要なのが、 いつ・どこで止めるか です。今回の統制は、Claude Code が持つ フック という仕組みに、統制ツール（Agent Governance Toolkit）を組み込みました。フックは、AIエージェントがツールを使おうとする、 その直前 に発動します。下の図のように、AIエージェントがツールを呼び出そうとするたびに、実行の手前でフックがその情報を外側の統制ツールに渡し、統制ツールがポリシーに照らして判定します。 ─────────── Claude Code（AIエージェント） ─────────── 利用者の依頼 → 行動を決める → ツールを呼び出そうとする │ │ フック（組み込み口）がツール使用の情報を渡す ▼ ─────── Agent Governance Toolkit（外側からの統制） ─────── ポリシーで判定する → 許可 / 確認 / 遮断 │ │ 判定結果を返す ▼ ─────────── Claude Code（AIエージェント） ─────────── 判定に従う（止まる / 実行する） 判定そのものは、Claude Code ではなく、 外側のAgent Governance Toolkitが行います 。Claude Code は「このツールを使おうとした」という情報を渡し、返ってきた判定に従うだけです。 行動が起きてからではなく、起きる直前に、外側で止める 。これが、出力に「やめておくべき」と書かせる前回の方法と大きく違う点です。 ただし、フックのような組み込み口は、エージェント実行環境側に必要です。Claude Code はフックの仕組みを備えていますが、すべてのAIエージェントが同じ仕組みを持っているわけではありません。また、フックがあっても、それを誰が設定し、どの範囲に適用するかは運用に依存します。つまり統制は、エージェントの外に置いた独立した仕組みでありながら、エージェント側に組み込み口があり、その設定が確実に適用されて初めて働きます。この点は後で改めて触れます。 STEP 2の実際の操作で現れたのは、 主に「許可（allow）」と「確認（review）」 でした。review は、行動を即座に通すのでも遮断するのでもなく、実行の手前で一度止めて、人間に確認を求める判定です。なお、遮断（deny）にあたる動作は、後述するように今回の操作の範囲では現れませんでした。 6-1：統制ツールの判定で、ツール使用が確認待ちになる Claude Code に、ファイルを1つ作るよう依頼しました。ファイルの作成は、それ自体は危険な操作ではありません。しかし、今回適用したポリシーでは、ファイルへの書き込みを確認の対象に指定していました。 実行しようとした手前で、ファイルを作成してよいかの確認が表示され、人が承認するまで実行は止まりました。ただし、Claude Code は、ファイルの書き込みに対してもともと確認を求める作りになっています。そのため、この確認が表示されたこと自体は、統制ツールが止めたのか、Claude Code がもとから持つ確認なのか、これだけでは区別がつきません。そこで、何がこの確認を判定したのかを、監査ログで確認しました。 { "timestamp": "2026-06-27T07:25:13.935Z", "agentId": "claude-code:e3c691d7-...", "action": "tool.Write", "decision": "review", "previousHash": "09c9c9c5...", "hash": "b686a97b..." } 記録を見ると、この書き込み（ tool.Write ）が review と判定されていました。この監査ログは統制ツールが残すもので、Claude Code 標準の確認では作られません。つまり先ほどの確認は、統制ツールがポリシーに従って review と判定し、人の確認を挟んだ結果でした。処理されたのは、統制ツールが通したからではなく、確認に対して人が承認したからです。ファイルの作成は、AIエージェント自身が危険とみなす操作ではありません。それでも、外側のポリシーが確認の対象に指定していれば、実行の手前で確認待ちになる、ということです。 さらに、各記録には previousHash と hash があります。 previousHash には、1つ前の記録の hash が入ります。各記録がこのように直前の記録のハッシュ値を抱えるため、途中の記録を後から書き換えると、その先のハッシュ値の連鎖が合わなくなり、改ざんに気づけます。単に記録を残すだけでなく、記録そのものが書き換えられていないことを後から確かめられる作りになっていました。企業の統制では、監査の証跡が後から改ざんされていないことが重要になるため、これはSTEP 1の判定の確認だけでは見えなかった点でした。ただし、これは改ざんを検知できる仕組みであって、改ざんそのものを防ぐものではありません。ログの保管先自体が適切に保護されていることは、別途必要になります。 6-2：危険な操作はAIエージェント自身が先に止めることもある 検証の途中で、Claude Code に、外部から取得したスクリプトをそのまま実行するよう依頼しました。これは、今回のポリシー上は遮断（deny）の対象にあたる操作です。 しかし実際には、外側の仕組みが遮断（deny）と判定する前に、Claude Code 自身が危険な操作と判断し、実行を止めました。そのため、外側の仕組みによる遮断そのものは、今回の操作の範囲では現れませんでした。 今回の検証で使った同梱ポリシーでは、遮断（deny）の対象が、外部から取得したスクリプトの実行のような、明確に危険な操作に向けて書かれていました。こうした操作は、外側の仕組みが判定するより先に、Claude Code 自身も危険とみなして止めます。そのため、「AIエージェント自身は実行しようとするのに、外側のポリシーが遮断する」という、遮断だけを純粋に取り出せる操作が、同梱ポリシーの範囲では用意しにくいものでした。今回の操作で遮断の動作までたどり着かなかったのは、この理由によります。 7.考察：3つの機能から見えてくること 今回動かした3つの機能は、役割は異なりますが、いずれも「 AIエージェントの外側から統制する 」という共通の考え方に基づいています。 ポリシー適用は、行動を許可・記録・遮断に振り分けます。ゼロトラストエージェントIDは、誰の行動かを見分け、最終的な判定を人間側に置きます。信頼性エンジニアリングは、全体の状態を数値で観測します。「何を許すか」「誰が決めるか」「どんな状態か」という、統制に必要な異なる側面を、それぞれが担っていると整理できます。 前回の記事で観察した HITL の制御と並べると、今回の統制の違いがはっきりします。 観点 前回 （AIエージェントの出力に組み込まれた制御） 今回 （AIエージェントの外側の独立した仕組み） 制御の主体 AIエージェント自身 外側の独立した統制層 強制力 出力に「承認が必要」と示す（宣言） 行動の手前で判定する（強制） 判定の仕組み AIエージェントの判断による ルールや実装された判定ロジックによる 最上位の判定者 運用として人間が確認 階層の設定として人間側に置く 記録 出力に含まれる 独立した監査ログ・数値に残る 前回の記事で残った課題は、AIエージェントの出力上の宣言だけでは、実際の行動を強制的に制御できないという点でした。今回確認した Agent Governance Toolkit の各機能は、その課題に対して、行動の手前で判定し、記録し、必要に応じて介入する仕組みを提供するものです。 ただし、外側からの統制は、ツールを導入するだけで自動的に効くものではありません。AIエージェントが外部システムに接続する経路が、この判定の仕組みを必ず通るように設計されている必要があります。 迂回できる経路があれば、統制は機能しません 。 また、今回 Claude Code に介入できたのは、Claude Code 側にフックという組み込み口があり、そこに統制を組み込んだからです。つまり、外側からの統制を企業で機能させるには、個々のエージェントへの組み込みだけでなく、 統制を通らないAIエージェントを作らせない開発ルールや運用ルールも必要 になります。これは、統制に組み込まれていないAIエージェントをどう扱うか、という次の論点につながります。 8.まとめ：AIエージェントを統制するために必要なこと ここまで、Microsoft の Agent Governance Toolkit を題材に、AIエージェントを外側から統制する仕組みを動かしてきました。STEP 1で判定の仕組みを単体で確認し、STEP 2で実際の Claude Code に組み込んで、その判定が実行前のツール使用に介入するところまでを見ました。 これらの検証を通して見えてきたのは、特定のツールの使い方というより、AIエージェントを統制するうえで共通して必要になる要素です。今回の検証をもとに整理すると、次のようにまとめられます。 統制に必要なこと 今回の検証で見えた裏づけ 行動を、通す・記録する・止めるに振り分ける判断 許可・記録・遮断の3種類の判定。単純な可否ではなく、通すが記録は残す、という中間の判定が必要になる 最上位の判定者を人間側に置く構造 権限の階層で、最上位にAIエージェントを置けず、人間を最上位に置く構成が求められた 改ざんを検知できる形で記録を残す仕組み 誰が何をしようとして、どう判定されたかが、ハッシュで連鎖した監査ログに残る 統制をAIエージェントに組み込み、その組み込みを徹底させる仕組み Claude Code のフックに組み込んで初めて統制が働いた。組み込みの有無は設定・運用に依存する すべての経路が統制を通る全体の設計 判定が正しくても、それを迂回できる経路があれば統制は機能しない 統制の外で動くAIエージェントを生ませない仕組み 統制に組み込まれていないAIエージェントが抜け道になる 前半の3つ（振り分ける判断・人間への権限固定・改ざんを検知できる記録）は、統制ツールそのものが提供する機能です。今回 Agent Governance Toolkit で実際に確認できた部分にあたります。一方、後半の3つ（組み込みの徹底・経路の設計・統制外をなくす仕組み）は、ツールだけでは完結せず、組織の設計やルールと組み合わせて初めて成り立つものです。AIエージェントを企業で安全に統制するには、 ツールが提供する判定の仕組みと、それを全体に行き渡らせる組織の仕組みの、両方が必要になります 。 今回の検証結果は一つのツールに基づくものであり、そのまますべてのAIエージェント統制ツールに一般化できるものではありません。それでも、ここで整理した「統制に必要なこと」は、別のツールや基盤を検討する際にも、何が備わっていて何が足りないかを見極めるための土台になると考えます。前回の HITL（内側の制御）と、今回の外側からの統制は対になる関係にあり、実運用では両方を組み合わせる設計が重要になります。そのうえで、統制を組み込まないAIエージェントをどう生ませないかが、その先の課題になります。 付録：検証に使った手順 STEP 1では、WindowsのPowerShellからツールを導入し、Python環境で各機能を確認しました。STEP 2では、Claude Code に公式サンプルの統制を組み込んで確認しました（いずれも2026年6月時点）。 STEP 1：環境準備 GitHub リポジトリをクローンし、Python の仮想環境を作成したうえで、ツールをインストールしました。 git clone https://github.com/microsoft/agent-governance-toolkit.git pip install agent-os-kernel 本検証では、ポリシー適用とゼロトラストエージェントIDの確認に agent-os-kernel を利用しました（本検証時点で利用した手順です）。信頼性エンジニアリングの確認では、これに加えて監視向けのライブラリ（ prometheus_client 、 opentelemetry-api 、 opentelemetry-sdk ）を導入しました。なお、2026年6月時点の公式READMEでは、統合パッケージである agent-governance-toolkit[full] も案内されています。導入時は公式リポジトリの最新手順を確認してください。ポリシー適用・ゼロトラストエージェントIDの判定そのものは、外部のLLMやAPIキーを必要とせず、ローカルで動作します。 STEP 1：ルールの記述例 制御ルールは、AIエージェント本体とは別のYAMLファイルとして記述しました。破壊的な操作を遮断し、メール送信を記録対象とするポリシーの例です。 name: business-agent-policy version: "1" defaults: action: allow rules: - name: block-destructive condition: { field: tool_name, operator: in, value: [delete_file, drop_table, execute_code] } action: deny priority: 100 - name: audit-email-send condition: { field: tool_name, operator: eq, value: send_email } action: audit priority: 90 STEP 2：Claude Code への組み込み STEP 2では、リポジトリに含まれる Claude Code 用の公式プラグイン（agent-governance-claude-code）を読み込み、同梱のポリシー例（examples/claude-code-agt/config/review-heavy-policy.json）を指定して Claude Code を起動しました。 cd agent-governance-claude-code npm install cd .. $env:AGT_CLAUDE_POLICY_PATH = (Resolve-Path .\examples\claude-code-agt\config\review-heavy-policy.json).Path claude --plugin-dir .\agent-governance-claude-code STEP 2：Windows環境での注意点 今回利用した公式サンプルは、Windows 環境ではそのままでは起動できませんでした。統制を組み込むための起動スクリプトの呼び出しでエラーになるためです。フックの設定ファイル（hooks.json）で、起動コマンドが Windows では実行できない形式を指していたことが原因でした。今回は、この起動コマンドを node に直接置き換えることで動作しました。公式サンプルはmacOS / Linux を前提とした記述になっている部分があり、Windows で動かす場合はこうした調整が必要になる場合があります。 執筆者 倉田 裕紀（NTT西日本　技術革新部　AI技術担当） AIエンジニアとして、社内外のAIプロジェクトを技術支援しています。 趣味は筋トレです。 商標 「Microsoft」は Microsoft Corporation の商標または登録商標です。 「Claude」は Anthropic, PBC の商標または登録商標です。 「GitHub」は GitHub, Inc. の商標または登録商標です。 「Python」は Python Software Foundation の商標または登録商標です。 「Prometheus」は The Linux Foundation の商標です。「OpenTelemetry」は The Linux Foundation のプロジェクトです。 その他、本文中に記載されている会社名、製品名、サービス名などは、各社の商標または登録商標です。 *1 : Microsoft「Agent Governance Toolkit」: https://github.com/microsoft/agent-governance-toolkit