AIエージェントを使い捨ての仮想マシンに隔離して鍵の流出を防ぐOSS「Matchlock」とは

「AIエージェントにコードを書かせて実行まで任せたい。でも、社員の端末や社内のサーバーで好きに動かされるのは怖い」「エージェントに渡した接続用の鍵が、知らないうちに外へ送られていたらどうしよう」——開発部門がAIエージェントを使い始めた企業の、情報システム担当者から聞こえてくる声です。こうした不安は「AIを賢く縛る指示を書けば解決する」と考えられがちですが、そうではありません。本当は、AIが騙されても被害が外へ広がらない場所で動かし、鍵そのものを渡さない作りが要になります。この記事では、AIエージェントを使い捨ての小さな仮想マシンに閉じ込め、通信先の限定と鍵の受け渡しを外側で行うOSS「Matchlock」について、一次情報で確かめられる仕組み、実験段階であることの意味、隔離では防げない危険、導入前に決めることを整理します。導入や操作の手順は扱いません。

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

Matchlock は、GitHub上で公開されているAIエージェント向けの隔離の道具です。READMEによると、AIエージェントを使い捨ての小さな仮想マシン（マイクロ仮想マシン）で動かす、命令を打ち込んで操作する道具で、通信先を許可したものに絞る仕組み、外側の中継で鍵を差し込む仕組み、仮想マシン単位の隔離を備えるとされています。あわせて Go・Python・TypeScript から呼び出すための部品（開発用の部品集）も用意されています。

公開の時期と規模を確かめておきます。リポジトリは2026年2月5日に作られ、最後に更新されたのは2026年10月4日です。2026年10月21日時点で、スターはおよそ620、複製（フォーク）は38、本流への取り込みの記録は500を超えています。リリースの一覧では、確認時点の最新版は7月26日公開の0.2.17で、春から夏にかけて月に数回の頻度で版が重ねられてきました。ライセンスはOSI（オープンソースの定義を管理する団体）が承認しているMITで、この記事では「OSS」と呼びます。

作者は個人のアカウントで、2012年に作られ、公開しているリポジトリは88あります。会社名の記載はなく、技術メモのブログへのリンクが置かれています。そしてREADMEの冒頭には、「実験段階であり、開発が進行中で、互換性のない変更が入りうる」という注意書きがあります。この一文は、後で扱う導入判断の前提になります。

なぜ今、AIエージェントの隔離が話題なのか

AIエージェントは、文章を返すだけの対話のAIと違い、自分でコードを書き、部品を取り込み、命令を実行し、外部の仕組みに接続します。READMEも、エージェントはコードを実行する必要があるが、手元の機械に無制限の権限を与えるのは危険だという問題意識から書き始めています。

危険の典型は、プロンプトインジェクション（読み込んだ文書やウェブの情報に紛れた命令にAIが従ってしまう攻撃）です。エージェントが騙されて悪意のある処理を実行すれば、端末の中のファイルや、環境に置かれた接続用の鍵が狙われます。AIの判断を完全に正しくすることはできないため、騙されることを前提に、被害が広がらない場所で動かすという考え方が広がっています。

このラインでも、AIエージェントを隔離して動かす道具をいくつか取り上げてきました。隔離の方式は、手元の権限を絞るもの、コンテナを使うもの、仮想マシンを使うものなどさまざまです。Matchlock は、そのなかでも仮想マシンという比較的強い境界と、鍵を中に入れない工夫を組み合わせた点に特徴があります。2026年2月には海外の開発会社のブログが紹介記事を出しており、関心の高さがうかがえます。

仕組み1：使い捨ての小さな仮想マシンで動かす

READMEによると、Matchlock はエージェントに1秒足らずで立ち上がる完全な Linux の環境を渡します。中でエージェントが部品を入れたりファイルを書いたりして散らかしても、外側の機械には影響しない、と説明されています。作業用に共有したフォルダも、終わると消える分離された写しとして扱われるとされます。

仮想マシンを動かす土台は、構成図では Linux 向けの Firecracker と、Apple の仮想化の仕組みが挙げられています。対応する環境は、仮想化の機能を備えた Linux と、Apple 製の独自の半導体を積んだ Mac です。仮想マシンはそれぞれが自分専用の基本ソフトの中核を持つため、同じ中核を共有するコンテナより境界が強いと一般に言われます。第三者の解説記事も、この点を Matchlock の利点に挙げています。

さらに同じ解説記事によると、仮想マシンの中でも権限を落とす仕組みや、使える命令を絞る仕組みを重ねているとされます。ただし、この点はREADMEの本文では詳しく確かめられませんでした。「仮想マシンだから絶対に抜けられない」わけではないことも押さえておくべきです。仮想化の土台そのものに弱点が見つかる可能性は、どの製品でもゼロではありません。

仕組み2：通信先を許可したものに絞る

Matchlock の守りの中心の一つが、通信先の限定です。READMEは、通信を許す接続先や差し込む鍵を指定したときに、明示的に許可した接続先への通信だけを通し、それ以外を遮断すると説明しています。これにより、騙されたエージェントが盗んだ情報を外へ送ろうとしても、送り先がない状態を作れる、というのが設計の狙いです。

加えて、通信の口そのものを持たない完全な切り離しの動かし方も用意されているとされます。外部と一切やり取りしない作業なら、この形がもっとも単純で強い守りになります。開発用の部品集では、許可リストの外にある社内の私的な住所帯（社内の機械に割り当てられる番号の範囲）への通信を、通信の設定を渡した時点で既定で遮断する、とも書かれています。

ここで注意したいのは、既定の振る舞いの書き方です。通信の仲介を説明した文書では、許可リストが空のときは、すべての接続先を許すとされています。READMEの説明も「指定したときに封じる」という書き方で、何も指定しない場合に外への通信がどう扱われるかは、読み方によって受け止めが分かれます。第三者の記事は「既定ですべて拒否」と紹介しており、一次情報と第三者の説明が一致していない点は、導入前に必ず自社で確かめるべき事項です。

仕組み3：鍵を仮想マシンの中に入れない

Matchlock のもう一つの特徴が、鍵の扱いです。READMEによると、エージェントが外部の仕組みに接続するとき、本物の鍵は外側の機械が通信の途中で差し込み、仮想マシンの中には代わりの文字列しか見えないとされています。中のエージェントが鍵を読み出そうとしても、得られるのは意味のない代わりの値だけです。

鍵は接続先と結び付けて登録する作りで、特定の接続先への通信にだけ差し込まれます。通信の仲介の文書では、差し込む場所は通信の見出しの部分と接続先の住所の部分に限られ、送る中身（本文）への差し込みは意図して行わないと説明されています。本文に鍵を混ぜることで、許可した接続先経由で鍵を書き出させるような事故を避ける狙いと読み取れますが、これは推測です。

この作りの意味は大きいと言えます。従来は、エージェントが外部の仕組みを使うためには鍵を環境に置くしかなく、騙されたエージェントがそれを読み出して外へ送る危険がありました。READMEは、エージェントが騙されて悪意のある処理を実行しても鍵は漏れず、データの行き先もない、と述べています。ただし、これは作者が掲げる設計の目標であり、第三者による検証の結果ではない点は区別しておきます。

仕組み4：通信の中身を外側で止める・書き換える

通信の仲介の文書によると、Matchlock は外側の機械で、暗号化された通信をいったん解いて中身を確かめる中継を行います。そのうえで、接続先・要求の種類・住所の一部などの条件に合う通信について、通す・止める・書き換えるという規則を設定できるとされています。

書き換えの例として、要求の見出しを足したり消したりすること、返ってきた中身の中の特定の文字列を置き換えることが挙げられています。たとえば、返答に含まれる社内の識別番号を伏せ字にする、といった使い方が文書の例として示されています。規則に応じた処理は仮想マシンの中ではなく外側で動くため、エージェント自身はこの規則を書き換えられない作りだと読み取れます。

一方で、限界も書かれています。この規則が働くのはウェブの通信（HTTPとHTTPS）に限られ、それ以外の方式の通信は書き換えの対象になりません。Linux では、ウェブで使う二つの番号の口への通信を中継に回す仕組みだと説明されています。ウェブ以外の通信がどう扱われるかは、確認した文書の範囲では詳しく書かれていません。社内で使う場合は、実際の通信の行き先を自社の監視で確かめることが前提になります。

想定される使い方と、使う場面

READMEと第三者の解説から読み取れる主な使い方は、コードを書いて実行するAIエージェントを、開発者の端末やサーバーとは切り離した場所で動かすことです。第三者の記事によれば、市販の開発向けAIエージェントを中で動かす例も用意されているとされます。

機能の面では、仮想マシンを使い捨てにする使い方のほか、長く動かし続ける使い方、外から中へ口をつなぐ使い方、コンテナの設計図から中で環境を組み立てる使い方なども挙げられています。開発用の部品集を使えば、自社のアプリの中から仮想マシンを立ち上げ、命令を実行し、結果を受け取る、という組み込み方もできるとされます。

企業の目線で整理すると、使う場面は大きく三つ考えられます。一つ目は、開発者がAIエージェントに試作のコードを書かせて試すときの作業場所。二つ目は、外部から取り込んだ出どころの不確かなコードを試しに動かす場所。三つ目は、自社のサービスの中でAIにコードを実行させる機能を作るときの土台です。ただし、いずれも実験段階の道具を業務の土台に据えることの是非を、先に判断する必要があります。

コンテナや他の隔離の手段との違い

AIエージェントを隔離する手段は、Matchlock のほかにもいくつかあります。第三者の解説記事は、コンテナは追加の設定なしでは強い境界にならないこと、外部の事業者が提供する実行環境は手元で完結しないことなどを挙げて比べています。ここでは、防御の担当者が判断に使える観点に絞って、一般的な手段と並べます。

観点	Matchlock（仮想マシン型・手元）	コンテナで隔離	外部事業者の実行環境
隔離の境界	仮想マシン単位。中核を共有しない	中核を共有する。追加の設定で強める	事業者の方式による
鍵の扱い	外側で差し込み、中には代わりの値だけ	環境に置くのが一般的	事業者の仕組みによる
通信先の限定	許可リストで限定できる（既定の振る舞いは要確認）	別途の設定が要る	事業者の機能による
データの置き場所	自社の機械の中	自社の機械の中	事業者の環境
成熟度	実験段階と明記。個人が主に開発	広く使われ、運用の知見が多い	商用の支援がある

表のとおり、Matchlock は境界の強さと鍵の扱いで優れる一方、成熟度では劣ります。どれか一つが常に正解ということはなく、扱うデータの重要度と、運用を支える体制で選ぶのが現実的です。商用の支援を受けられない点は、障害時の対応を自社で抱えることを意味します。

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

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。Matchlock の判定は「紹介可」です。根拠は次のとおりです。

一つ目は、ライセンスがOSI承認のMITであることです。二つ目は、作者のアカウントが2012年に作られ、多くのリポジトリを公開している、実績のある個人であることです。三つ目は、公開済みのセキュリティ勧告がないことです。四つ目は、精査した範囲で、導入の際に自動で動く処理が見つからなかったことです。スターの伸びも1日あたり2から3程度で、不自然な急増は見られません。

ただし、問題が見つからなかったことは安全の保証ではありません。READMEは自ら実験段階と明記しており、リポジトリにはセキュリティ上の問題の報告窓口を定めた方針の文書も置かれていません。隔離の道具は、それ自体に弱点があると守りの前提が崩れるため、一般の道具以上に慎重な確認が要ります。紹介可は「記事として紹介してよい」という意味であり、「業務で使ってよい」という判断ではない点に注意してください。

注意点：実験段階であることと、運営の体制

最大の注意点は、READMEの冒頭にある実験段階の注記です。互換性のない変更が入りうるということは、版を上げたときに設定の意味や既定の振る舞いが変わる可能性がある、ということです。隔離の道具では、既定の振る舞いの変化がそのまま守りの穴になりえます。

運営の体制も確かめておきます。作者は会社名を示していない個人で、第三者の記事が公開された2026年2月時点では、関わる開発者は二人とされていました。個人が主に開発するOSSは身軽で改善が速い反面、作者の都合で更新が止まる可能性を抱えます。弱点が見つかったときの報告窓口の方針がない点も、運用の前に記録しておくべき事項です。

片付けの仕組みにも注意が要ります。動作の状態を説明した文書では、停止の途中で失敗すると資源が残りうること、残った資源をあとから整理する仕組みがあることが説明されています。Mac などでは通信の設定の後片付けが対象外とされている点もあり、「使い捨て」が常に完全に片付くとは限らないことを理解しておく必要があります。

隔離しても防げないこと：許可した接続先の悪用

隔離の道具を入れると、それだけでAIエージェントの危険が片付いたように感じがちです。しかし、第三者の解説記事は、隔離はプロンプトインジェクションそのものを止めないと指摘しています。騙されたエージェントは、許可された接続先に対しては、正規の鍵を使って何でもできてしまうからです。

たとえば、エージェントに社内の課題管理の仕組みへの接続を許していれば、騙されたエージェントがそこで課題を書き換えたり、情報を書き込んで外部の人に見える形にしたりする可能性があります。鍵が仮想マシンの外にあっても、鍵を使った操作そのものは外側の中継が代わりに通してしまうため、許可した接続先の中で起きる悪用は防げません。同じ記事によると、作者もこの問題は別の層で解くべきだと述べています。

また、作業用に共有したフォルダを通じて情報が持ち出される経路についても、記事の時点ではファイル単位の制御が整っておらず、今後の課題とされていました。さらに、エージェントが実行した命令や通信の試みを記録する仕組みも、当時は今後の提案として挙げられていました。現在の状況は確認した一次情報では確かめきれず、記録が足りない前提で、自社の監視を組み合わせるのが無難です。

悪用されうるリスク

Matchlock は守りのための道具ですが、性質上、悪用の可能性がまったくないわけではありません。一つは、暗号化された通信を外側で解いて中身を見る中継を持つ点です。これは鍵を差し込むために必要な仕組みですが、設定を誤れば、本来見るべきでない通信の中身を中継が扱うことになります。中継の設定を誰が管理するかは、社内で明確にしておく必要があります。

二つ目は、使い捨ての環境であることの裏返しです。仮想マシンの中で何が行われたかの痕跡が、終了とともに消えてしまう可能性があります。攻め手が同じ種類の隔離環境を、痕跡を残しにくい作業場所として使うことも理論上は考えられますが、これは推測であり、Matchlock に固有の危険というより、使い捨ての実行環境一般の性質と見るのが妥当です。

三つ目は、導入の経路です。READMEには、配布元のスクリプトを取得してそのまま実行する導入の方式も示されています。この方式は手軽ですが、配布元が乗っ取られた場合の影響を受けやすい方式でもあります。隔離の道具の導入こそ、社内の確認手順を省かないことが大切です。

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

Matchlock を社内で試すかどうかを決める前に、少なくとも次の順で確かめておくと、後からの手戻りを防げます。

企業が取るべき対策

Matchlock を使うかどうかにかかわらず、AIエージェントを業務で動かす企業が取るべき対策は共通しています。第一に、エージェントを社員の端末や本番のサーバーで直接動かさないことです。仮想マシンでもコンテナでも、被害を閉じ込める場所を用意したうえで動かすことを社内の規程に書き込みます。

第二に、鍵をエージェントに渡さない、渡すなら権限を最小にすることです。Matchlock のように外側で差し込む方式が取れない場合でも、読み取り専用の鍵にする、期限を短くする、使える範囲を絞るといった工夫で、漏れたときの被害を小さくできます。第三に、通信先を許可したものに限り、それ以外を遮断することです。

第四に、エージェントが何をしたかを、エージェントの外で記録することです。使い捨ての環境では中の記録が消えるため、外側の通信の記録や、接続先の操作の記録を残しておきます。第五に、隔離の道具そのものを、他の道具と同じく調達・更新の管理の対象にすることです。守りの道具が古いまま放置されると、守っているつもりで穴が開いている状態になりかねません。

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

隔離の道具を入れても、何を許すかを決めるのは人です。許可する接続先、渡す鍵の権限、扱うデータの範囲を、AIに判断させてはいけません。エージェントは作業を進めるために「この接続先も必要です」と提案してくることがありますが、その提案をそのまま受け入れれば、隔離の意味が薄れます。

エージェントが接続先の追加を求めてきたら、なぜ必要なのか根拠を書かせ、人がその根拠を読んで判断する手順を入れます。動いている途中で許可リストを変えられる仕組みもあるとされるため、変更してよい人と、変更を記録する方法を先に決めておきます。人が確認する範囲を先に決めることが、隔離を形だけで終わらせないための要点です。避けたい使い方を挙げます。

• エージェントに求められるまま、作業の途中で許可する接続先を増やしていく
• 隔離しているからと、強い権限の鍵をそのまま登録する
• 何も指定しなければ外への通信は止まっていると思い込み、確かめずに使う
• 使い捨ての環境だからと、エージェントの操作の記録を残さない
• 実験段階と明記された版を、変更点を読まずに更新する

どの例も、道具が悪いのではなく、人が決めるべきことをAIや既定の設定に委ねたことで起きる失敗です。隔離の強さは、何を許したかで決まります。

よくある質問：隔離すればAIエージェントは安全に使えるのか

答えは「被害が広がる経路の一部を断てるが、それだけでは足りない」です。Matchlock のような隔離は、手元の機械への被害と、鍵の読み出しを防ぐことに強みがあります。一方で、許可した接続先の中での悪用、共有したフォルダを通じた持ち出し、エージェントが正規の権限で行う誤った操作は、隔離だけでは防げません。

では隔離に意味がないのかというと、そうではありません。騙されたエージェントが端末の中のファイルを読み、知らない接続先へ送る、という典型的な被害の筋道を断てることは大きな前進です。大切なのは、隔離・権限の最小化・通信の限定・記録・人の確認を重ねることで、どれか一つに頼らないことです。

もう一つ、「実験段階の道具を業務で使ってよいのか」という問いもありそうです。この記事の立場では、まず重要度の低い作業で試し、既定の振る舞いを自社で確かめてから範囲を広げるのが無難です。判断は扱うデータの重要度と、自社で障害に対応できる体制によります。

• Matchlock の機能・対応環境・通信の仲介と鍵の扱い・動作の状態の管理・ライセンス・リリースの状況は、GitHubのリポジトリ（README・ライセンス文書・リリースの一覧・セキュリティの欄・通信の仲介と動作の状態の文書）を2026年10月21日に確かめた範囲に基づきます。実験段階のため、版の更新で内容が変わる可能性があります
• 仮想マシンの中での権限の絞り込み、記録の仕組み、ファイル単位の制御の状況は、2026年2月の第三者の解説記事の記述を含み、現在の状況は一次情報では確かめきれませんでした
• 何も指定しないときの外への通信の扱いは、一次情報と第三者の説明が一致しておらず、この記事では断定していません
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Matchlock は、AIエージェントを使い捨ての小さな仮想マシンで動かし、通信先を許可したものに絞り、本物の鍵を仮想マシンの外に置いたまま通信の途中で差し込むOSSです。ライセンスはMITで、実績のある個人が2026年2月から開発を続けており、精査の範囲では勧告や導入時に自動で動く処理は見つかりませんでした。

一方で、READMEは自ら実験段階と明記し、報告窓口の方針もなく、何も指定しないときの通信の扱いには説明の食い違いがあります。隔離は許可した接続先の悪用を止めず、問題が見つからなかったことも安全の保証ではありません。許す接続先と鍵の権限を人が決め、AIには根拠を書かせ、記録を外側に残したうえで、重要度の低い作業から試すことが、Matchlock との現実的な付き合い方です。

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