AIエージェントの外向き通信を検査して記録を残すOSS「Pipelock」の仕組みと導入前の注意点

「AIエージェントに社内の作業を任せたいが、持たせた鍵を外へ送られたら気づけるのか」「エージェントが何をしたか、後から第三者に説明できる記録がほしい」——AIエージェントの利用ルールづくりを担う情報システムやセキュリティの担当者が、いま共通して抱えている二つの問いです。どちらも、エージェントの中にもう一つ見張り役を入れれば片づくように見えます。しかし本当に必要なのは、エージェントの内側の仕組みではありません。エージェントの外側に、通信が必ず通る関所を置き、その関所の判断を後から確かめられる形で残すことです。この記事では、その関所の役割を担うOSS「Pipelock」を取り上げ、仕組みと記録の限界、公開済みのセキュリティ勧告と修正された版、企業が導入前に確かめるべき点を整理します。導入や設定の手順は扱いません。

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

Pipelockは、GitHubで公開されているOSSです。READMEでは「AIエージェントのためのオープンソースのファイアウォール」と名乗り、エージェントとネットワークの間に置いて、仲介した通信を検査すると説明しています。あわせて、判断の結果を、仲介役が署名した記録として残すことを特徴に掲げています。

配布の形を確かめます。リポジトリは2026年2月8日に作られ、中核部分のライセンスはApache-2.0です。2026年10月18日時点でスターは934、派生は109、最後の更新は10月17日でした。一日あたりのスターの伸びは約3.7件で、急に注目が集まった形ではありません。開発に使われている言語はGoで、最新の版は10月14日に公開された3.7.0です。

開発者は、作者の個人アカウント（luckyPipewrench）のプロフィールで、本業は配管工だと紹介しています。海外のセキュリティ専門メディアは2026年5月、作者のジョシュア・ウォルドレップ氏が「PipeLab」という取り組みの下で開発していると報じました。リポジトリは現在、pipelab という組織のアカウントの下にありますが、その組織のアカウントは2026年10月9日に作られたばかりで、フォロワーは1です。この点は後の章で詳しく扱います。

なぜエージェントの外向き通信を見張る必要があるのか

AIエージェントは、文章を返すだけでなく、ファイルを読み、コマンドを走らせ、外のサービスへ問い合わせます。作業のためにAIサービスの利用の鍵や社内システムの認証情報を持たせることも珍しくありません。READMEが最初に挙げている問題は、まさにここです。鍵を持ち、外へ通信できるエージェントは、たった一回の外向きの通信で、その鍵を社外へ送れてしまうという指摘です。

このとき、エージェントの中に組み込んだ安全の仕組みだけに頼ると限界があります。作者は報道の取材に対し、エージェントの中の仕組みは「エージェントが呼び出し続けている間しか働かない」と述べています。外から受け取った文章に命令を紛れ込ませる攻撃（プロンプトインジェクション）でエージェントの動きが変えられれば、中の仕組みは呼ばれないまま素通りされるおそれがあります。

そこでPipelockは、見張り役をエージェントの外に置きます。報道によると、設計の考え方は秘密を持つ側はネットワークに直接出られず、ネットワークに出る側は秘密を持たないという役割の分離です。二つの間に検査の関所を挟み、すべての通信がそこを通るようにします。エージェントがどれだけ巧みに振る舞っても、通り道が一本なら、関所で止められるという考え方です。

仕組み1：エージェントとネットワークの間に立つ仲介役

READMEによると、Pipelockは複数の通り道を仲介します。ウェブの通信を中継する役、WebSocketの通信を中継する役、そしてMCP（AIエージェントが外部の道具を呼び出すための共通の約束事）のサーバーを包み込んで、行きと帰りの両方を検査する役です。エージェント同士がやり取りするための約束事（A2A）の通信も、ウェブとMCPの通り道の上で検査するとされています。

暗号化された通信については扱いが分かれます。暗号化を途中でいったん解いて中身を見る設定にした場合は中身まで検査し、そうでない場合は行き先の名前と住所の水準でしか検査しないとREADMEに明記されています。どこまで見えているかは設定しだいだということです。

もう一つ、READMEは重要な前提を書いています。代理の通信設定を無視する道具は、仲介役を素通りできます。そうした道具まで止めるには、ネットワークの水準で外への道を閉じる仕組みが別に要るとされています。Pipelockには基本ソフトの機能を使って実行の場を囲う機能もありますが、報道は、ネットワークの隔離そのものは自社の設定（コンテナの内部ネットワークや、Kubernetesの通信制御など）に頼ると伝えています。

仕組み2：何を検査し、どう止めるのか

READMEによると、検査の対象は、秘密情報の持ち出し、外部からの命令の紛れ込み、社内の機器を踏み台にした不正な問い合わせ（SSRF）、道具の説明文への細工、危険な道具の呼び出しの連なりです。READMEは、持ち出しを見つけるための型が65、返ってきた内容に紛れ込んだ命令の型が34、道具の使い方に関する規則が30、危険な呼び出しの連なりの型が10あると記しています。これは作者側の説明で、本記事で効果を確かめたものではありません。

動き方は三つの方式から選びます。許可した行き先だけを通す厳しい方式、単純な攻撃は止めて巧妙なものは知らせる釣り合いを取った方式、記録を中心にする監査の方式です。加えて、特定の開発支援の道具に合わせた設定のひな形（プリセット）や、モデルそのものが敵対的に振る舞う前提で守りを固めるひな形も用意されています。どの方式で動かすかによって、止まる範囲は大きく変わります。

このほか、外部からの指示ですべての通信を止める緊急停止の仕組み、わざと置いたおとりの情報が外へ出ていないかを見る仕組み、検査結果をログ集約の仕組みへ送る機能があると説明されています。一つ注意したいのは、READMEが、利用者が設定したMCPの接続先については社内の住所への接続を例外的に許すと書いている点です。ただし、クラウドの管理情報を返す特別な住所への接続は、その場合も止めるとされています。便利さのために開けている例外がどこにあるかを、導入前に把握しておく必要があります。

仕組み3：署名付きの記録「アクションレシート」

Pipelockのもう一つの柱が、判断ごとに残す記録です。公式サイトの仕様書は、これを「アクションレシート」と呼び、仲介役がエージェントの外で、ある操作に対してどの判断を下したかを示す署名付きの記録だと説明しています。エージェント自身が書いた作業の記録に頼らずに確かめられる点が要です。

仕様書によると、一枚の記録には、操作の識別子、操作の種類、時刻、行き先、通り道、判断の結果、その判断に使った規則の要約値、誰の権限で誰が行ったか、元に戻せる操作かどうかなどが含まれます。記録の中身は決まった形に整えてから要約値を計算し、その値にEd25519という方式で署名します。

記録は一枚ずつ独立しているわけではありません。同じまとまりの記録には通し番号が振られ、各記録が一つ前の記録の要約値を持ちます。そのため、途中の一枚を書き換えると、それ以降のつながりがすべて崩れる形になっています。公開鍵を持つ人なら、ネットワークにつながずに手元で、署名とつながりの両方を確かめられるとされています。

記録が証明できること、できないこと

署名付きの記録は、監査や事故の振り返りで強い味方になります。ただし、仕様書は記録の限界も自ら明記しています。この限界を知らずに使うと、記録を過信することになります。何を証明しないかを、READMEと仕様書がはっきり書いている点は、評価してよいところです。

仕様書に書かれた限界は次のとおりです。第一に、記録は操作が実際に及ぼした結果まで証明しません。第二に、仲介役を通らなかった操作がなかったことは証明しません。第三に、仲介役そのものが乗っ取られれば、記録を偽造されるおそれがあります。第四に、署名の鍵は運用する側が持つため、鍵を持つ人なら都合のよい記録をまとめて作れます。第五に、エージェントが署名の鍵に触れられないことが、記録の証拠としての価値の前提になります。

運用する側から独立した証拠にするには、外部の公開の記録簿に要約値を刻む仕組みがあり、READMEはその機能に触れています。ただし、運用する側に依存しない検証の流れはまだ実証の途中だと書かれています。つまり、記録は「関所がこう判断した」ことの証拠であって、「運用者が誠実だった」ことの証拠ではないと捉えるのが正確です。

似た手段と何が違うのか

エージェントの通信を管理する方法は、Pipelock以外にもあります。一次情報で確認できた範囲をもとに、代表的なやり方と比べます。いずれも設定を誤れば効果を失う点は同じで、優劣ではなく、守る対象と運用の体制に合わせて選ぶ話です。

見る点	エージェント内の安全機能	社内の一般的な通信の中継	Pipelock
置き場所	エージェントの中	社内ネットワークの出口	エージェントとネットワークの間
乗っ取られたときの効き方	素通りされるおそれがある	通信は通るが中身の意味までは見ない	関所を通る限り検査される
MCPの道具の呼び出し	道具ごとの作りに依存	通常は対象外	包み込んで行きと帰りを検査
秘密情報の持ち出しの検査	作りに依存	製品や設定による	型と規則で検査（作者の説明）
判断の記録	エージェント自身の記録	通信の記録	署名とつながりで確かめられる記録
素通りの道	中の仕組みを呼ばなければ効かない	経路を外れた通信	代理設定を無視する道具

表のとおり、Pipelockの特徴は、AIエージェントに特有の通り道であるMCPまで検査し、判断を確かめられる形で残す点にあります。社内の通信の中継を置き換えるというより、エージェント向けの関所を一段足すものと読むのが妥当でしょう。どのやり方にも共通するのは、通り道を一本にそろえなければ、関所は効かないという点です。

安全性の評価：注意付きとした根拠

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

根拠にした事実は次のとおりです。まず、公開済みのセキュリティ勧告が5件あり、重大度は低が2件、中が3件です。次に、現在リポジトリを所有している組織のアカウントは2026年10月9日に作られたばかりで、フォロワーは1、公開しているリポジトリは9件です。移管された直後で、組織としての実績を外から確かめる材料が少ないことが、注意を付けた大きな理由です。

一方で、安心材料もあります。勧告はいずれも修正版が出ており、2026年10月18日時点の最新版3.7.0は、5件すべての修正を含む版より新しい版です。中核部分はApache-2.0で、スターの伸びに不自然な水増しの兆候は見られませんでした。リポジトリの直下には、ビルドのための設定ファイルがあるものの、取り込むだけで自動で動く処理は確認していません。ただし、勧告が修正済みであることも、問題が見当たらないことも、安全の保証ではない点は添えておきます。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。

公開済みのセキュリティ勧告と修正された版

GitHubのセキュリティ勧告の一覧には、2026年8月から10月にかけて5件が公開されています。ここでは、各勧告がどの版に影響し、どの版で修正されたかを整理します。守りをすり抜ける具体的なやり方は、この記事では扱いません。

勧告	重大度	影響の概要	影響する版	修正された版
CVE-2026-92145（8月20日公開）	中	設定を短い間に続けて変えると、古い設定のまま動き続ける場合があった	2.6.0より前	2.6.0
CVE-2026-91178（9月8日公開）	中（5.8）	通信の行き先に含まれる一部の秘密情報を見落とす場合があった	3.4.0より前	3.4.0
CVE-2026-91180（9月19日公開）	中（5.3）	止める設定にした画像などの内容が、エージェントに届く場合があった	2.2.0から3.4.0	3.5.0
CVE-2026-91179（10月3日公開）	低	敵対的なモデルを想定したひな形で、守るはずの設定ファイルを置き換えられる場合があった	3.5.0以前	3.6.0
番号なし（10月3日公開）	低	守るはずのファイルへの書き込みの保護が、一部の構成で効かない場合があった	3.5.0以前	3.6.0

表から読み取れるのは、勧告の多くが守りの仕組みが想定どおりに効かない場合があったという性格のものだという点です。守りのための道具の勧告は、道具そのものが攻撃の入口になるというより、守れているつもりで守れていない隙間を指すことが多くなります。

運用への示唆は二つあります。一つは、3.6.0より前の版を使っているなら、更新が前提になることです。もう一つは、設定を変えた直後に、意図した設定で動いているかを確かめる手順を持つことです。設定の反映に関する勧告では、修正版にすぐ移れない場合の当座の対応として、短い間に何度も設定を変えないことと、変更後に効いている設定を確かめることが挙げられています。

所有組織の移管とライセンスの二層構造

リポジトリは、作者の個人アカウントの下で公開されたあと、組織のアカウントに移ったとみられます。作者のプロフィールでは、固定表示のリポジトリがすべて組織側を指しています。一方で、READMEのバッジや案内、勧告に書かれた部品の配布元の名前には、まだ個人アカウント側の住所が多く残っています。移った経緯を説明する告知は、リリースノートなど確認した範囲では見つかりませんでした。

移管そのものは、個人の開発が組織の運営に移る過程で珍しくありません。ただ、導入する側から見ると、どの住所の配布物が正式なものか、今後どちらの名前で更新が続くかが分かりにくい状態です。正式な配布元がどこかを、導入前に文書で確かめておくことを勧めます。

ライセンスにも注意が要ります。中核部分はApache-2.0ですが、複数のエージェントを扱う上位の機能は別のフォルダに置かれ、利用の条件が異なるエラスティック・ライセンス2.0で、使うにはライセンスの鍵が要ります。READMEによると、配布されている完成品には有料の機能のコードも含まれ、正しい鍵がある場合にだけ有効になります。自分でソースから組み立てた場合は、無償版の機能だけのものになるとされています。どちらの形で使うかによって、ライセンスの確認の範囲が変わる点を、法務と共有しておきましょう。

悪用されうるリスク

Pipelockは守りのための道具で、攻撃に使うための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「関所を入れたから持ち出しは防げる」という安心が、確認を止めてしまうことです。関所は、通り道を通った通信しか見ません。

次に挙げるのは推測ですが、検討の材料として無視できません。仲介役は、通信の中身を見るために強い立場に置かれます。暗号化を解いて中身を見る設定にすれば、その仲介役は社内の秘密がもっとも集まる場所の一つになります。仲介役そのものが狙われたときの影響は大きいと考えておくべきです。記録の署名の鍵が漏れれば、記録の信頼も崩れます。

また、勧告が示すように、守りの道具にも隙間は見つかります。古い版のまま使い続ければ、守れているつもりで守れていない状態が続きます。なお、Pipelockが攻撃に使われた事例や、Pipelockを経由した被害の報告は、2026年10月18日時点で確認した一次情報からは見つけられませんでした。

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

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

この手順の要は、動かす前に「通り道が一本か」と「記録の鍵を誰が持つか」を決めておくことです。関所は、入れた瞬間から「見張っている」という安心を生みます。その安心が何を意味するのかを先に決めておかないと、素通りの道が残ったまま、記録だけが積み上がる日が続きます。

企業が取るべき対策

一つ目は、エージェントに持たせている鍵の棚卸しです。関所を入れる前に、そもそも持たせる必要のない鍵を外します。持ち出されて困る鍵を、最初から持たせないのが、もっとも確実な持ち出し対策です。

二つ目は、外への道の把握です。エージェントが動く端末や実行の場から、関所を通らずに外へ出られる道がないかを、実際の通信の記録で確かめます。三つ目は、版と勧告の追跡です。守りの道具こそ、更新が止まると守れていない期間が生まれるため、勧告の一覧を定期的に見る担当を決めます。

四つ目は、記録の運用です。署名付きの記録は、見る人がいなければ意味を持ちません。止めた通信の件数や種類、想定外の行き先を、決めた頻度で確認します。五つ目は、調達のときの確認です。運営の体制、移管の経緯、正式な配布元、弱点の報告への窓口、ライセンスの条件を、導入前に文書で確かめます。

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

Pipelockは、AIエージェントに外との通信を任せるための守りの道具です。任せる範囲が広がるほど、何が外へ出たかを人が把握しにくくなります。だからこそ、先に決めるのは、AIにも道具にも判断させない部分です。

具体的には、どの行き先を許すか、どの鍵を持たせるか、どの方式で動かすか、記録を誰が見るか。この四つは人が決めて記録に残します。関所が止めた理由や、許した理由は記録に根拠として残るため、判断の根拠を人が後から確かめる運用にできます。やってはいけない向き合い方を挙げます。

• 「関所を入れたから」を理由に、エージェントに持たせる鍵を減らさない
• 代理の通信設定を無視する道具が残っていないかを確かめない
• 監査の方式のまま本番に出し、止まっているつもりで運用する
• 署名の鍵をエージェントと同じ場所に置く
• 勧告の一覧を見ず、古い版を使い続ける
• 記録は取っているが、それを見る人と頻度を決めていない

裏を返せば、人が決める範囲ははっきりしています。どこへ出してよいか、何を持たせるか、誰が鍵を持つか、誰が記録を見るか。この四つが決まっていないまま関所を入れても、守りの厚みは増えません。

よくある質問：入れれば情報の持ち出しは防げるのか

答えは「それだけでは足りない」です。Pipelockが検査できるのは、関所を通った通信です。関所を通らない道が残っていれば、そこから出ていく情報は見えません。通り道を一本にそろえる設計と組み合わせて初めて、関所が効くという点が抜け落ちやすいところです。

では入れる意味がないのかというと、そうではありません。エージェントの外に関所を置くことで、エージェントが乗っ取られても、関所を通る限りは検査が働きます。判断ごとに確かめられる記録が残るため、何を止め、何を許したかを第三者に説明しやすくなります。

もう一つ、「署名付きの記録があれば監査の証拠として十分か」という問いもありそうです。仕様書は、鍵を持つ運用者なら都合のよい記録を作れると明記しています。社外への説明に使うなら、鍵の管理を誰が行い、外部の記録簿に刻む仕組みをどう使うかまで決めておく必要があります。

• Pipelockの機能・版・勧告・ライセンスは、GitHubのリポジトリとREADME、リリースノート、セキュリティ勧告、公式サイトの仕様書を2026年10月18日に確かめた範囲に基づきます。内容は変わる可能性があります
• 検出できる攻撃の数や性能の数値は作者側の説明で、本記事で検証したものではありません
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順や、勧告の回避のやり方は扱いません

まとめ

Pipelockは、AIエージェントと外のネットワークの間に立ち、HTTP・WebSocket・MCPなどの通信を検査して、秘密情報の持ち出しや外部からの命令の紛れ込みを止めるOSSです。判断ごとに署名とつながりで確かめられる記録を残す点が特徴です。中核部分はApache-2.0で、公開済みの勧告5件はいずれも修正版が出ています。一方で、所有する組織のアカウントは作られたばかりで、上位の機能には別のライセンスが付いています。

関所は、通り道を通った通信しか見ません。記録は関所の判断の証拠であって、運用者の誠実さや、関所の外で何も起きなかったことの証拠ではありません。どこへ出してよいか、何を持たせるか、誰が鍵を持つか、誰が記録を見るかを人が先に決め、版の更新を追い続けること。この前提をそろえたうえで使うことが、AIエージェントに外との通信を任せる時代のPipelockとの付き合い方です。

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