AIエージェントと本番環境の間で操作を検査して止めるOSS「Claw Patrol」とは

「障害対応をAIエージェントに手伝わせたいが、本番のデータベースに触れる鍵を渡すのはためらう」「エージェントの設定で禁止したはずの操作が、別の道具を経由すると通ってしまうのではないか」——本番環境の運用を預かるインフラ担当やセキュリティ担当と話すと、最近こうした声をよく聞きます。多くの場合、答えはエージェントの設定を細かく詰めることだと考えられがちです。しかし本当に問うべきなのは、エージェント自身に、自分の行動の取り締まりを任せてよいのかという点です。この記事では、エージェントの外側で通信を検査し、操作ごとに通すか止めるかを決めるOSS「Claw Patrol」を取り上げ、何を通し何を止めるのか、どこで動くのか、企業が導入前に決めておくべき点を整理します。導入や設定の手順は扱いません。

Claw Patrolとは何か。2026年10月時点で確かめられる事実

Claw Patrolは、GitHubで公開されているOSSです。リポジトリの説明は「エージェントのためのセキュリティ・ファイアウォール」の一言で、READMEでは「エージェントと本番環境の間に入り、通信を回線の段階で読み解き、利用者が書いた規則に照らして一つひとつの操作を通すか止めるかを決める」と説明されています。例として、データベースを壊すような命令を止めることや、クラスタ上の部品を消す操作を、人が承認するまで保留にできることが挙げられています。

公開元を確かめます。リポジトリは、実行環境のDenoを開発している組織のアカウントで2026年4月28日に作られました。組織のアカウント自体は2018年8月に作られ、公開しているリポジトリは235件あります。ライセンスはMITです。このラインの精査を行った2026年10月18日時点で、スターは1,085、派生は71、最後の更新は10月3日でした。1日あたりのスターの伸びは約6.3件で、実績のある組織が出したものが、自然な速さで注目を集めている形と読めます。

公開の経緯も一次情報で確かめられます。開発元の公式ブログは2026年5月21日に紹介記事を出しており、筆者にはDenoの生みの親として知られる人物を含む6人が名を連ねています。記事の中で開発元は、本ソフトをアルファ版と明記しています。リリースは小刻みに出ており、確認した時点の最新は10月3日の0.5.14でした。

なぜDenoはエージェントの外側に関所を置いたのか

公式ブログによると、開発元は自社の配信基盤やパッケージの登録所などの本番サービスの運用にエージェントを使っています。そのためにはクラウド、データベース、コンテナの管理基盤、コードの置き場といった広い範囲へ触れる権限が要ります。そこで開発元が出した結論が、エージェントに自分自身を取り締まらせることはできないというものでした。道具も鍵も、エージェントのプロセス自身が握っているからです。

もう一つの理由は、使っているエージェントの多くが他社製で、中身を書き換えられないことです。エージェントの振る舞いを内側から変えられない以上、取り締まりはエージェントの外に置くしかないという考え方になります。ブログはこれを設計の原則の一つ目に挙げています。

ブログは、既存の手段も四つに分けて検討しています。言語モデルの入出力を見張る仕組み、ウェブの通信だけを中継する仕組み、プロセスを閉じ込める仕組み、鍵を差し込んで中継する仕組みです。開発元の見立てでは、どれも問題の一部にしか応えておらず、データベースのようにウェブ以外の通信まで命令の種類ごとに止められるものはなかったとしています。Claw Patrolは、この隙間を埋めるために作られたと説明されています。

仕組み：ゲートウェイ・端末・管理画面の三つ

公式ドキュメントによると、Claw Patrolは三つの部分で成り立っています。一つ目はゲートウェイです。利用者が管理するサーバーの上で動き、規則と鍵と、通信を読み解くための証明書の発行元を持ち、許可した通信だけを本来の行き先へ送ります。二つ目は端末で、エージェントが動く機械です。端末はゲートウェイに参加し、エージェントの通信をゲートウェイ経由で流します。ゲートウェイと端末は同じプログラムで動くとされています。

三つ目は管理画面です。ゲートウェイの上で動くウェブの画面で、運用者が管理者用の合言葉で入り、鍵の登録、端末の参加の承認、規則の作成を行います。端末の参加には一度だけ使える番号が使われ、管理画面で確認して承認する流れになっています。つまり、規則と鍵と承認の権限が、ゲートウェイと管理画面に集まる構造です。

通信の運び方も確かめます。端末とゲートウェイの間は、WireGuardかTailscaleという仮想の専用回線でつながります。ゲートウェイは暗号化された通信をいったんほどき、中の手順を読み解いてから規則に照らします。さらに、端末からは直接届かない社内の網へ、ゲートウェイから先に中継することもできるとされています。本番への入口を一か所に集めることで、見張る場所を一つにする考え方です。

何を見て、何を止めるのか

Claw Patrolの特徴は、通信の宛先だけでなく中身まで読む点です。READMEによると、規則の条件は、ゲートウェイが手順ごとに取り出した事実に対して書きます。データベース（Postgres、ClickHouse）なら命令の種類と表の名前、クラスタ管理（Kubernetes）なら操作の対象と動作と区画、ウェブの通信（HTTP）なら方式、宛先の道筋、付随する情報、本文です。設定の資料には、遠隔ログインの手順も対象として載っています。

判定の結果は、許可か拒否かのほか、承認者に回すこともできます。設定の資料によると、規則には優先順位を付けられ、一時的に無効にしたり、特定の鍵を使う通信だけに絞ったりもできます。READMEに載っている開発元の実際の規則の例は、本番クラスタの秘密情報を読む操作を拒否するもので、理由として「秘密の値をエージェント経由でクラスタの外に出してはならない」と書かれています。「何をしてはいけないか」を、操作の単位で書けることが、この道具の中心です。

公式サイトによると、規則は保存した時点で効き、外へ出るすべての要求に対して判定が走るとされています。また、管理画面で観察した操作から拒否の規則を作り、設定に書き戻すこともできると説明されています。一方で、どの規則にも当てはまらない通信を既定で通すのか止めるのかは、確認した資料の範囲でははっきり書かれていませんでした。導入を考えるなら、最初に確かめたい点です。

人の承認と、AIによる審査の組み合わせ

止めるか通すかを機械的に決めにくい操作は、承認者に回せます。承認者には二種類あります。一つは人の承認で、チャットの通知や管理画面、外部への通知を通じて、人が許可か拒否かを選びます。公式サイトによると、決められた時間内に誰も応じなければ、その要求は拒否される作りです。例として示された設定では、待つ時間は10分でした。

もう一つは、言語モデルによる審査です。利用者が書いた方針の文章に照らして、モデルが要求を判定します。判定結果は使い回されるとされています。9月11日の更新では、審査がうまく動かなかったときの扱いが実際に効くようになり、既定は「止める側に倒す」になったとリリースノートにあります。審査役が落ちたときに素通りにならない設計は、守りの側から見て重要です。

二つは組み合わせられます。ブログでは、利用者への返信文をまずモデルが書式と語調で確かめ、そのあとチャット上で人が承認または修正する流れが、開発元の実例として紹介されています。設定の資料では、規則に複数の承認者を並べた場合は、全員の承認がそろって初めて通るとされています。AIを一次の確認に使い、最後の判断を人に残す形が、道具の作りとしても用意されているわけです。

鍵をエージェントに渡さない設計

Claw Patrolのもう一つの柱は、鍵の扱いです。公式ドキュメントによると、本物の鍵はゲートウェイの設定で宣言し、管理画面で接続して初めて使える状態になります。エージェントには本物の鍵は渡らず、ゲートウェイが通信の途中で差し込む仕組みです。ブログでは、エージェントは仮の文字列だけを持ち、回線の上で本物に置き換えられると説明されています。

これが意味するのは、エージェントが外から紛れ込んだ命令にだまされた場合でも、エージェントの手元から本物の鍵を持ち出すことはできないという点です。公式サイトも、だまされたエージェントが持っている鍵は漏れうるという問題を挙げ、その対策としてこの方式を位置づけています。

セキュリティ方針の文書は、この点を本ソフトの中核の約束として書いています。本物の秘密はゲートウェイにしか存在せず、鍵を使う要求はゲートウェイを通してしか行えず、そこで規則が適用される、というものです。設定の資料によると、鍵は持ち主ごとのまとまりに束ねられ、どの持ち主の要求がどの鍵とどの行き先に届くかが決まります。10月3日の更新では、登録されていない相手には鍵を渡さない設定も加わりました。

どこで動くのか：三つの置き方と、通信を読むための証明書

READMEは、三つの置き方を示しています。一つ目は中継役そのものを動かす形、二つ目は端末をゲートウェイに参加させ、端末全体の通信をゲートウェイへ流す形、三つ目はエージェント一つのプロセスとその子どもだけを包み、その通信だけをゲートウェイに流す形です。三つ目は、Linuxでは網を分ける仕組み、macOSでは網の拡張機能を使うとされ、macOSでは利用者による拡張機能の承認が要ります。

ゲートウェイを自社で動かすことが前提で、公式サイトに提供元が運営する版の案内は見当たりませんでした。つまり、関所は自社が管理するサーバーの上に置くことになります。本番の網に近い場所に置き、エージェントが動く機械からは関所を通してしか本番に届かないようにする、という配置が想定されていると読めます。

ここで押さえておきたいのが証明書の扱いです。公式ドキュメントによると、ゲートウェイは最初の起動時に独自の証明書の発行元を作り、端末が参加するときにその発行元が端末の信頼の一覧に登録されます。これにより、包んだプロセスの暗号化された通信を読み、書き換えられるようになります。端末から見ると、ゲートウェイが暗号化通信の中身を読める立場に入るということです。10月1日の更新では、参加のときにゲートウェイの証明書を確かめ、登録する発行元を固定するよう改められています。

記録と、規則の変更を確かめる仕組み

公式サイトは、すべての操作が記録され、管理画面から個々の要求をたどってゲートウェイが捉えた内容を確かめられると説明しています。設定の資料によると、捉えた要求の記録と接続のまとまりの記録は、既定で30日保たれ、行き先ごとに保存期間を変えることもできます。なお、ゲートウェイの動作の記録を書き出すファイルは、監査用の記録ではないと明記されている点に注意が要ります。何を監査の証跡とするかは、導入する側が決める必要があります。

もう一つの特徴は、規則の変更を試す仕組みです。公式サイトによると、記録した操作を見本として保存し、規則に照らし直して、判定が変わったものを報告させることができます。この照らし直しには、ゲートウェイもデータベースも認証も要らないとされています。規則を書き換えたときに、昨日まで止めていた操作が今日から通ってしまうといった事故を、本番に出す前に見つけるための仕組みです。

加えて、言語モデルの呼び出しを外部の監視基盤へ送る機能があり、その場合も会話の中身は既定で送らない設定になっていると設定の資料にあります。記録を外へ送るかどうか、送る場合に何を含めるかは、社内の情報の扱いの決まりと照らして決める話です。

似た手段と何が違うのか

エージェントの行動を制御する方法は、ほかにもあります。開発元のブログが挙げた分類と、確認できた範囲の事実をもとに比べます。優劣ではなく、どこで止めるかの違いとして読んでください。

見る点	エージェントの設定で禁止	プロセスを閉じ込める	Claw Patrol
止める場所	エージェントの内側	エージェントが動く端末	エージェントと本番の間の関所
見ている対象	エージェントが使う道具の呼び出し	端末の中のファイルや網への出入り	データベースの命令やクラスタ操作などの通信の中身
他社製のエージェント	提供元の作りに左右される	外から包める	外から包める
鍵の置き場所	エージェントの手元	多くはエージェントの手元	ゲートウェイだけ
端末の中のファイルの保護	設定しだい	主な目的	対象外と明記
人の承認	提供元の作りに左右される	仕組みによる	規則に組み込める

表のとおり、Claw Patrolが強いのは「本番に向かう通信を、命令の単位で止める」部分です。逆に、端末の中で何が読まれるかは守備範囲の外です。閉じ込める仕組みと関所は、置き換えではなく重ねるものと考えるのが妥当でしょう。ブログでも、閉じ込める仕組みは手元の資源を守るのに役立つと述べたうえで、開発元自身はエージェントを専用の仮想マシンで動かしていると書いています。

安全性の評価：紹介可とした根拠

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。Claw Patrolの判定は「紹介可」です。

根拠は次のとおりです。運営は実行環境のDenoを開発する組織のアカウントで、2018年に作られ、公開リポジトリは235件あります。スターの伸びは1日あたり約6.3件で、不自然な水増しの兆候は見られませんでした。ライセンスはMITで商用も含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下には導入用のスクリプトがありますが、利用者が自分で実行するもので、取り込んだだけで自動的に動く処理ではありません。

セキュリティ方針の文書があり、弱点の報告は非公開の窓口で受け付け、数日以内に受領を返すとしています。対象となるのは最新のリリースだけで、修正は次のリリースで配られます。ただし、勧告がないことは安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。本ソフトが本番への入口と鍵を一か所に集める性格を持つ以上、評価は導入する側でも重ねる必要があります。

導入前に知っておきたい注意点

第一に、開発元自身がアルファ版と位置づけている点です。対応する手順も開発元が必要とする範囲に限られ、ほかの手順は協力者が足していく前提だとブログに書かれています。リリースも9月から10月にかけて小刻みに出ており、版を固定して検証し、更新の確認を担当として決めておく必要があります。セキュリティ方針の文書が対象とするのは最新版だけです。

第二に、端末を閉じ込める仕組みではない点です。セキュリティ方針の文書は、プロセスを包む使い方について、サンドボックス（外と断ち切った実行の場）ではないと明記しています。包まれたプロセスは、その利用者の権限で端末の中のファイルや環境の情報を読めます。プロセス単位の通信の横取りも「できる限り」の扱いで、すり抜ける接続が生じうることは既知の制限とされています。

第三に、ゲートウェイの重みです。規則、鍵、証明書の発行元、承認の権限が一か所に集まります。ゲートウェイや管理画面が奪われれば、本番への鍵と、暗号化通信を読める立場をまとめて渡すことになります。最近の更新でも、管理画面への他のサイトからの要求の拒否、内部の網への中継を既定で断る設定、参加の資料を一度だけ渡す改めなどが続いています。守りが今まさに固められている途中の道具だと受け止めておくのが現実的です。

第四に、どの規則にも当てはまらない通信の既定の扱いが、確認した範囲でははっきりしなかった点です。また、日本語で仕組みや注意点を整理した資料は、確認した範囲では見つけられませんでした。

悪用されうるリスク

Claw Patrolは守りのための道具で、攻撃のための道具ではありません。それでも、置き方しだいで生まれうる危険はあります。最も大きいのは、「関所を入れたから本番に入れても大丈夫」という安心が独り歩きすることです。関所は規則に書いたものしか止めず、関所を通らない経路は見ていません。

次に挙げるのは推測ですが、検討の材料になります。ゲートウェイは暗号化された通信を読める立場にあり、本物の鍵を集めて持っています。このため、攻撃者から見れば、まとめて狙う価値のある場所になりえます。管理画面の合言葉の扱いや、ゲートウェイの置き場所の守りが甘ければ、守りのための設備がそのまま入口になる筋書きは考えられます。

もう一つは、エージェントが関所を迂回する経路です。セキュリティ方針の文書が認めているとおり、プロセス単位の横取りは完全ではありません。エージェントが動く端末から本番へ直接届く道が残っていれば、規則は意味を失います。端末全体の通信を流す置き方と、プロセス単位で包む置き方のどちらを選ぶかで、すり抜けの余地は変わると考えられます。どちらを選んだ場合も、本番の側で関所以外からの接続を受け付けない設定を重ねておくのが安全側の考え方です。なお、Claw Patrolが実際に悪用された事例は、2026年10月18日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときに確かめること

検討するときは、動かす前に、資料と社内の取り決めで確かめられる点から整理します。下の手順は、OSSを動かす前の段階で終えられるものに絞っています。

この手順の要は、関所を置くことと、関所を通らない道を閉じることを同時に決めることです。関所だけを置いて他の道が開いたままなら、規則をどれだけ丁寧に書いても守りは成り立ちません。

企業が取るべき対策

一つ目は、エージェントに渡している本番の鍵の棚卸しです。Claw Patrolを使うかどうかにかかわらず、エージェントの手元に本物の鍵が置かれていないかを確かめます。鍵はエージェントではなく、管理された場所に置くという考え方は、この道具の設計から学べる一般的な教訓です。

二つ目は、危険な操作の定義です。データの削除、権限の変更、秘密情報の読み出しなど、エージェントにさせてはいけない操作を、業務の担当者と一緒に言葉で決めておきます。関所の規則は、その定義を機械が読める形に移したものにすぎません。三つ目は、承認の運用です。承認を求める通知が多すぎれば、人は中身を見ずに許可するようになります。承認に回す操作は絞り込み、通知の量を人が見られる範囲に収めることが大切です。

四つ目は、関所そのものの守りです。ゲートウェイを置くサーバーの権限、管理画面に入れる人、更新の担当を決めます。五つ目は、調達のときの確認です。アルファ版であること、最新版だけが修正の対象であること、弱点の報告の窓口があることを踏まえ、社内で使える段階かどうかを文書で判断します。

AIに任せる範囲と、人が決める範囲

Claw Patrolは、AIに本番の仕事を任せるための守りの道具です。規則の中に言語モデルによる審査を組み込むこともできます。だからこそ、AIに判断させない部分を先に決める必要があります。

具体的には、どの操作を常に拒否するか、どの操作を人の承認に回すか、承認者が応じないときにどう扱うか、どの鍵をどの持ち主に結びつけるか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。言語モデルの審査を使う場合も、判定の根拠を書かせ、最後に人が確かめる流れにしておくと、後から判断を振り返れます。やってはいけない向き合い方を挙げます。

• 関所を入れたことを理由に、エージェントが動く端末から本番へ直接届く道を残したままにする
• 危険な操作の判定をすべて言語モデルの審査に任せ、人の承認を挟まない
• 承認の通知を大量に流し、担当者が中身を見ずに許可する状態を放置する
• 管理画面の合言葉を複数人で使い回し、誰が規則を変えたか分からなくする
• アルファ版であることを確かめずに、全社の本番環境へ一度に広げる
• 規則を書き換えたあと、以前止めていた操作が通らないかを確かめない

裏を返せば、人が決める範囲ははっきりしています。何を止め、誰が承認し、どの道を閉じ、誰が関所を守るか。この四つが決まっていないまま関所を置いても、守りの厚みは増えません。

よくある質問：関所があればエージェントを本番に入れてよいのか

答えは「それだけでは足りない」です。Claw Patrolは、関所を通る通信のうち、規則に書いたものを止めます。関所を通らない通信と、規則に書いていない操作は止まりません。端末の中のファイルや環境の情報は守備範囲の外だと、公開元自身が明記しています。

では入れる意味がないのかというと、そうではありません。本物の鍵をエージェントの手元から外せること、データベースの命令やクラスタの操作を一件ずつ判定できること、危険な操作を人の承認待ちにできることは、エージェントがだまされたときの被害を確かに小さくします。操作が記録として残り、後からたどれる点も、運用の助けになります。

もう一つ、「言語モデルの審査があれば人の承認は要らないのではないか」という問いもありそうです。確認した範囲では、審査の正確さを示す数値は見つけられませんでした。開発元自身の実例も、モデルの確認のあとに人の承認を置く形です。AIは一次の確認に使い、取り返しのつかない操作の最終判断は人に残す、という分け方が妥当でしょう。

• Claw Patrolの機能・版・置き方・制限は、GitHubのリポジトリとその中の文書、公式サイトと公式ドキュメント、リリースノート、開発元の公式ブログを2026年10月18日に確かめた範囲に基づきます。アルファ版のため内容は変わる可能性があります
• どの規則にも当てはまらない通信の既定の扱い、言語モデルの審査の正確さは、確認した一次情報の範囲では十分に確かめられませんでした。導入の判断では最新の資料を確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Claw Patrolは、AIエージェントと本番のシステムの間に関所を置き、データベースの命令やクラスタの操作、ウェブの通信の中身を読んで、規則ごとに許可・拒否・承認待ちを決めるOSSです。本物の鍵はゲートウェイだけが持ち、人の承認や言語モデルの審査を規則に組み込めます。Denoの開発元が自社の運用のために作り、MITで公開しています。GitHub上にセキュリティ勧告は登録されていません。

一方で、開発元はアルファ版と位置づけ、端末を閉じ込める仕組みではないと明記しています。関所を通らない経路、規則に書いていない操作、関所そのものの守りは、道具ではなく人が決める範囲です。止める操作、承認する人、閉じる道、関所を守る人を先に決めたうえで使うことが、エージェントに本番を任せる時代のClaw Patrolとの付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。