AIエージェントが書いたコードを隔離の強さを示して実行するOSS「plimsoll」とは

「AIエージェントに書かせたコードを社内で動かしたいが、どこまで隔離すれば安心なのか判断がつかない」「外部の実行環境は『安全に隔離』とうたっているが、実際にどの程度の壁の中で動いたのかを確かめる手段がない」——AIエージェントの業務への組み込みを進める開発部門と、それを審査する情報システム部門の両方から上がり始めている声です。道具選びの問題に見えますが、そうではありません。本当は、隔離の強さが、宣伝文句ではなく確かめられる記録として残っているかが問われています。この記事では、AIエージェントが書いたコードを隔離して動かし、その強さを毎回の結果に書き込むOSS「plimsoll」について、一次情報で確かめられる仕組み、作者自身が認めている限界、運営実績の乏しさという注意点、企業が導入前に確かめるべき点を整理します。導入や設定の手順は扱いません。

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

plimsoll は、GitHub上で公開されているOSSです。リポジトリの説明によると、AIエージェントが書いたような信頼できないコードを、サンドボックス（外部に影響が及ばないよう隔離した実行環境）の中で動かすサービスで、実行ごとに、どの強さの隔離の中で動いたかを報告します。名前は、船の外側に描かれ、誰でも積み荷の限度を確かめられる満載喫水線（プリムソル線）に由来するとREADMEは説明しています。

公開の時期と規模を確かめておきます。リポジトリが作られたのは2026年9月10日で、最後の更新は10月22日です。2026年10月23日時点で、スターは27、複製（フォーク）は2、記録された変更（コミット）は98件です。公開済みの版（リリース）は複数あり、確認した最新は10月19日の0.22.0で、正式版の前の段階です。リリースの一覧を見ると、9月末から10月にかけて短い間隔で版を重ねています。

ライセンスはApache-2.0で、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。本体は Go という開発言語で書かれ、常駐して実行の受け付けを担う本体（デーモン）と、各種の開発言語から呼び出すための部品で構成されています。運営しているのは組織のアカウントですが、そのアカウントもリポジトリと同じ2026年9月10日に作られ、フォロワーは0、公開しているリポジトリは3つです。会社名や連絡先のウェブサイトは登録されていませんでした。

なぜ今、AIエージェントが書いたコードの隔離が問われるのか

AIエージェントに計算や集計、データの加工をさせると、AIはその場でコードを書き、それを動かして答えを出そうとします。便利な一方、そのコードは人が一行ずつ読んで確かめたものではありません。読ませた文書に紛れた指示に従って、意図しない処理を書く可能性もあります。そのため、AIが書いたコードは社内の重要な仕組みから切り離した場所で動かすのが基本になりつつあります。

問題は、その切り離し方の強さがまちまちなことです。同じ仮想の箱でも、利用者の端末やサーバーと中核の部分（カーネル）を共有する軽い方式から、仮想マシンとしてまるごと分ける重い方式まであります。plimsoll の資料は、外部の実行環境のサービスが隔離の強さを説明文には書いても、その実行が実際にどの強さで動いたかを結果として返さないことを問題として挙げています。資料には、うたっていたメモリの上限が実際には効いていなかった実行環境の事例にも触れられています。

企業の側から見ると、これは審査と記録の問題です。「隔離して動かしている」と報告を受けても、どの方式で、どの実行が、どの壁の中で動いたかが残っていなければ、事故のときに検証できません。plimsoll は、隔離の強さを説明書の一文ではなく、実行ごとの記録の値として扱おうとする試みだと位置づけられます。

仕組み1：隔離の強さを四つの段階で結果に書き込む

plimsoll は、隔離の強さを弱い順に四つの段階で表します。READMEと資料によると、段階は、同じ処理の中で動かすだけの「プロセス」、軽い仮想の箱で分ける「コンテナ」、中核の部分を肩代わりする仕組みで守る「カーネル」、仮想マシンで分ける「仮想マシン」の四つです。実行のたびに、実際に使った段階が結果に値として入るのが特徴です。

どの段階になるかは、実際にコードを動かす裏側の仕組み（プロバイダー）で決まります。資料によると、ブラウザーの外でも動く共通の実行形式（WebAssembly）で本体の中で動かす方式は「プロセス」、Docker の標準の方式は「コンテナ」、Google が公開している gVisor を使う方式は「カーネル」、Firecracker という軽量の仮想マシンを使う外部のサービスなどは「仮想マシン」の段階とされています。

注意したいのは、最も弱い「プロセス」の段階について、資料自身が敵意のあるコードには使わないようにと書いていることです。この段階には基本ソフトの壁がなく、実行の仕組みに抜け穴があれば、本体の処理そのものに影響が及びます。資料は、本番で敵意のあるコードを扱うなら仮想マシンの段階か、gVisor を使う方式を選ぶよう勧めています。

仕組み2：最低の段階を指定し、満たさなければ実行しない

plimsoll では、実行を頼むときに「この段階より弱い隔離なら動かさないでほしい」という最低の段階（床）を指定できます。READMEによると、本体が満たせない床を指定された依頼は、コードを一切動かす前に断られます。断ったときには「何も実行していない」という印と、その理由が付きます。

この印には実務上の意味があります。資料によると、印のない失敗は、コードが動き始めた後に起きた可能性があるため、自動で再実行してはいけないとされています。逆に、印のある失敗は何も動いていないので、別の環境に回しても二重の実行にはなりません。さらに、公式の部品は結果が戻ってきたときにも段階を確かめ直し、食い違いがあれば別の失敗として扱うと説明されています。

また、本体の側でも全体の床を起動時に決められると資料は書いています。依頼ごとの床と全体の床の両方で守ることで、設定の誤りで弱い隔離のまま動いてしまう事態を防ぐことが狙いだと読み取れます。人が決めた基準を、仕組みの側で機械的に守らせる考え方です。

仕組み3：認証情報を隔離の中に入れずに外部の窓口を呼ばせる

AIが書いたコードに社内のシステムを呼び出させたい場面は多くあります。しかし、呼び出しに必要な合言葉や鍵（認証情報）をそのままコードに渡すと、コードが誤って、あるいは紛れた指示に従って、それを外へ漏らすおそれがあります。plimsoll はこの問題に、許可（グラント）と仲介役（ブローカー）という仕組みで応えています。

資料によると、許可は一回の実行に結びつき、一つの窓口の、一覧にした経路だけを呼べるようにするものです。許可がなければ、その実行は外部と一切通信できません。実際の呼び出しは隔離の外にある仲介役が行い、呼び出し元と経路が許可と完全に一致するかを確かめてから、認証情報を自分で付けます。認証情報は実行ごとに発行され、隔離の中には入らないとされています。

資料は限界も書いています。仲介役は呼び出しの中身（本文）を読まないため、本文で何を頼むかまでは制限できず、それは呼ばれる側のシステムで制限する必要があります。呼び出し回数の上限や停止の仕組みも実行ごとに働くもので、同時に動く多数の実行をまとめて抑えるものではありません。仲介役があれば呼ばれる側の守りが要らなくなるわけではないという点は、導入を考える側が押さえておくべきところです。

仕組み4：実行の記録を指紋で残し、あとから確かめる

READMEによると、plimsoll は実行ごとに、送られた依頼と返した結果のそれぞれについて、内容から計算した固有の値（ハッシュ。内容が一文字でも違えば値が変わる指紋のようなもの）を返します。公式の部品はこの値を計算し直して、途中で書き換えられていないかを確かめます。別に用意された署名の道具は、確かめた結果に署名し、一連の呼び出しの途中が欠けていれば受け付けず、実行を再現することもできるとされています。

READMEは、この仕組みの応用として、AIが書いた制御のプログラムを、そのプログラムからは読めない試験の条件で試す例を示しています。台車の上の棒を倒さないように支える教材の問題で、合格したプログラムを2回動かすと同じ指紋になり、符号を誤った最初の案は5.96秒で棒を倒して指紋も変わった、と説明されています。AIが書いたものを、閉じ込めるだけでなく、条件をそろえて試験し、その証拠を残すという使い方です。

ただし、READMEは、試験そのもの（模擬の仕組み、条件、合格の基準）は利用者が用意するものだと明記しています。plimsoll が提供するのは壁と証拠であり、何をもって合格とするかを決めるのは人の側です。指紋が一致することは同じ結果が出たことを示すだけで、その結果が業務上正しいかどうかは別に確かめる必要があります。

対応する実行環境と、つなげられるAIの開発の道具

資料によると、plimsoll が対応する裏側の仕組みは複数あります。本体の中で動かす方式、Docker を使う方式（標準の方式と gVisor を使う方式）、外部の有料の実行環境のサービス（E2B や Docker Cloud のサンドボックス）、NVIDIA の仕組みを使う方式、Kubernetes 上の実行環境などです。このうち外部のサービスは実行ごとに料金がかかると書かれています。

本体は利用者が自分で立てて運用する前提で、何も設定しなければ実行の機能そのものが無効になっていると資料は説明しています。呼び出すための部品は、Go、Python、TypeScript 向けに用意され、Google や Vercel などのAIエージェントを作る道具から使うための案内もあります。10月19日の版では、MCP（AIと外部の道具をつなぐ共通の取り決め）のサーバーも加わり、AIの道具から直接コードの実行を頼めるようになったとリリースの記録にあります。

段階ごとの裏側の仕組みと、その段階の根拠を整理すると次のとおりです。いずれも資料の記載に基づくもので、この記事では実際に動かして確かめてはいません。

隔離の段階	主な裏側の仕組み（資料の記載）	段階の根拠として資料が挙げるもの	資料が書く注意
プロセス	本体の中で WebAssembly として動かす	本体のテストと設定	敵意のあるコードには使わない。抜け穴は本体に及ぶ
コンテナ	Docker の標準の方式、NVIDIA の仕組み	起動時の点検（書き込み不可、通信なし など）	利用者の端末と中核の部分を共有する
カーネル	Docker で gVisor を使う方式	登録の確認と起動時の点検	実際にその壁が使われたことの証明ではない
仮想マシン	外部の有料サービス（Firecracker など）	提供元が何であるか	仮想マシンの土台は計測していない

表の右端が示すとおり、段階の表示は、設定と起動時の点検にもとづく判断であって、物理的な証明ではないと資料自身が認めています。この点は次の章以降で詳しく扱います。

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

plimsoll が想定しているのは、AIエージェントを組み込んだ自社のサービスや社内の仕組みで、AIが書いたコードを動かす場面です。たとえば、社内のデータの集計をAIに頼み、AIが書いた集計のコードを隔離して動かす使い方が考えられます。その際、業務で扱うデータの重さに応じて、求める隔離の段階を決めておける点が、plimsoll の考え方の中心です。

もう一つは、AIが書いたプログラムの試験の場面です。READMEの例のように、AIが書いたプログラムを、AIからは見えない条件で試し、合否と指紋を残す使い方です。AIに書かせたコードを採用する前の確認の手順に組み込めば、誰が、どの条件で、どの結果を確かめたかを後から追えるようになると考えられます。

一方で、資料によると、実行中に外部から部品を取り込むことはできず、必要な部品は事前に実行環境の型に組み込んでおく必要があります。複数の本体をまとめて管理する仕組みもないとされています。手軽にAIの出力を試す道具というより、自社で運用の体制を持てる組織向けの部品と見るのが実態に近いでしょう。

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

このラインでは、OSSを取得・導入・実行せず、公開されている情報と精査の記録をもとに安全性を判定しています。plimsoll の判定は「注意付き」です。根拠は、運営の実績が外から確かめにくいことです。

運営する組織のアカウントは、リポジトリと同じ2026年9月10日に作られ、フォロワーは0、公開しているリポジトリは3つです。会社名や連絡先も登録されていません。READMEも、作者は一人で、外部の利用者はまだいないと書いています。誰が、どんな体制で保守しているかを外から確かめる手がかりが少ないのが現状です。

一方で、ライセンスはOSI承認のApache-2.0で、公開済みのセキュリティ勧告はありません。精査の記録では、導入時に自動で動く処理の登録は見当たらず、根元に作業の手順をまとめたファイルが一つあるだけでした。スターの伸びは1日あたり0.6ほどで、不自然な水準ではありません。ただし、問題が見つからなかったことは安全の保証ではありません。とくにこのOSSは、信頼できないコードを動かす仕組みそのものであり、ここに欠陥があれば影響は大きくなります。

運営体制と、作者自身が書いている限界

plimsoll の特徴の一つは、作者が限界を率直に書いていることです。セキュリティの方針の文書には、独立したセキュリティの会社による監査は一度も受けていないと明記されています。安全面の取り組みは作者自身の見直しとテスト、実行時の確認であり、見直しの記録は公開されていないとされています。

同じ文書によると、正式版の前の段階のため、修正を受けられるのは最新の版だけで、過去の版への修正の提供や長期の保守はありません。READMEも、互換性を壊す変更が移行の猶予なしに入ることがあると書いています。脆弱性の報告は GitHub の非公開の報告の窓口で受け付け、7日以内の受領の連絡と、90日以内の判断を目安にしています。窓口と目安が文書で決まっていることは評価できますが、それを支えるのは一人の作者です。

限界をまとめた資料には、ほかにも、段階の表示は暗号による物理的な証明ではないこと、実行環境の型の土台が更新で変わりうること、自動の更新は何もないことなどが並んでいます。これらは欠点の隠し事ではなく、使う側が知っておくべき前提です。導入を検討する組織は、この限界の一覧を、自社の審査の記録に写して判断の根拠にするのがよいでしょう。

悪用されうるリスクと、誤った安心の危険

plimsoll は守りのための道具であり、攻撃のための道具ではありません。ただし、守りの道具ならではのリスクがあります。第一は、段階の表示を過信することです。資料によると、「カーネル」の段階は、gVisor の登録と起動時の点検が通ったことを示すだけで、実際にその壁が使われたことの証明ではありません。「仮想マシン」の段階も、提供元が何であるかから推し量ったもので、仮想マシンの土台は計測していないとされています。

第二は、仕組みそのものが狙われることです。plimsoll の本体は、信頼できないコードと、認証情報を発行する仲介役の両方を扱います。セキュリティの方針の文書も、隔離の外への脱出、許可を超えた権限の取得、発行した認証情報の隔離への流出などを報告の対象に挙げています。こうした欠陥があれば、守りのつもりの仕組みが、社内のシステムへの入り口になる可能性があります。現時点で、具体的な欠陥や被害の報告は確認できていません。

第三は、運営の継続性です。作者が一人で、組織のアカウントにも実績がない状態では、保守が止まったときに修正を受けられなくなるおそれがあります。正式版の前で最新版にしか修正が出ないため、追随できなければ、古い版に既知の欠陥が残り続けることも考えられます。いずれも、仕組みの出来とは別に、運営の体制から来るリスクです。

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

plimsoll のような隔離の仕組みを検討するときは、少なくとも次の順で確かめておくと、後からの手戻りを防げます。ここでの確認は、文書の読み込みと社内の判断の範囲で、導入や設定の手順は扱いません。

企業が取るべき対策

plimsoll を採用するかどうかに関わらず、AIが書いたコードを動かす企業が整えるべきことがあります。第一に、AIが書いたコードを、社内の重要な仕組みと同じ場所で動かさないことを規程に書き込むことです。どの段階の隔離を最低とするかを、扱う情報の重さごとに決めます。

第二に、隔離の強さを記録として残すことを、外部の実行環境のサービスを選ぶときの条件にすることです。plimsoll のように段階を結果に書き込むかどうかは、調達の際の質問の一つになります。第三に、AIが書いたコードに渡す認証情報は、実行ごとに発行し、短い時間で失効させ、コードの手元に置かないことを原則にします。

第四に、隔離の仕組みそのものを、重要な仕組みとして扱うことです。正式版の前の、作者が一人のOSSを使うなら、版の追随と脆弱性の情報の確認を誰が担うかを決め、ソフトウェアの部品表（SBOM）に載せて管理します。第五に、呼ばれる側の社内のシステムでも、呼び出しの中身と量を制限することです。資料のとおり、仲介役は本文を読まず、上限も実行ごとにしか働かないため、最後の守りは呼ばれる側に置きます。

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

plimsoll は、人が決めた基準を機械的に守らせる道具です。逆にいえば、どの段階を求めるか、どの窓口のどの経路を許すか、何をもって試験の合格とするかは、AIに判断させてはいけません。AIエージェントがコードを書くのは便利ですが、そのコードにどこまでの権限を与えるかをAI自身に決めさせれば、隔離の意味がなくなります。

人が決めるのは、用途ごとの最低の段階、許可する経路の一覧、試験の条件と合格の基準、そして結果を採用するかどうかです。AIが書いたコードを採用するときは、AIにそのコードが何をするかの根拠を書かせ、人が確認する範囲を先に決めておくことを手順に入れます。避けたい使い方を挙げます。

• AIエージェントに、実行を頼むときの最低の段階を自分で選ばせる
• 最も弱いプロセスの段階のまま、社外の文書を読んだAIが書いたコードを本番で動かす
• 結果に「仮想マシン」と書かれていることを、物理的に証明された隔離だと受け取る
• 仲介役があるからと、呼ばれる側の社内のシステムで中身や量の制限をしない
• 許可の一覧を自動で作る道具の出力を、絞り込まずにそのまま使う

資料も、窓口の仕様から許可の一覧を作る道具について、すべての操作が一覧に入るため使う前に絞り込む必要があると書いています。道具が作った下書きを人が削るという役割分担が、この種の仕組みを安全に使う前提です。

よくある質問：結果に書かれた隔離の段階は信じてよいのか

結果に書かれた段階は、plimsoll の本体が集めた証拠、つまり設定と起動時の点検にもとづく判断です。資料は、これが暗号による物理的な証明（アテステーション。機械そのものが、どのソフトウェアが動いているかを証明する仕組み）ではないと明記し、そうした証明を必要とする脅威の想定は満たせないとしています。段階の表示は、何もないよりは確かな手がかりだが、最終的な保証ではないと受け止めるのが妥当です。

では、記録が残ること自体に意味はないのかといえば、そうではありません。依頼ごとに床を決め、満たさなければ動かさず、結果に段階と指紋が残る作りは、設定の誤りや思い込みによる事故を減らすことに役立つと考えられます。過信せず、しかし記録としては活用するという距離感が、現時点の plimsoll との付き合い方です。物理的な証明が必要なら、それを提供する別の仕組みと組み合わせて考える必要があります。

• plimsoll の機能・仕組み・限界は、GitHubのリポジトリ（README、隔離の段階・許可・限界の資料、セキュリティの方針、リリースの一覧）を2026年10月23日に確かめた範囲に基づきます。正式版の前のOSSで、内容は短い間隔で変わっています
• 運営する組織や作者の素性、実際の利用の規模、各段階の隔離が実際に働くかどうかは、確認した一次情報の範囲では確かめられませんでした。この記事では実際に動かして確かめてはいません
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

plimsoll は、AIエージェントが書いたコードを隔離した環境で動かし、実際に使った隔離の強さを四つの段階で毎回の結果に書き込むOSSです。求める最低の段階に届かなければ何も動かさず、認証情報を隔離の中に入れずに外部の窓口を呼ばせ、実行の記録を指紋で残します。隔離の強さを宣伝文句ではなく記録として扱うという考え方は、AIが書いたコードを動かす企業にとって参考になります。

一方で、運営する組織のアカウントはリポジトリと同じ日に作られてフォロワーは0、作者は一人で外部の監査もなく、段階の表示は物理的な証明ではないと作者自身が認めています。用途ごとの最低の段階と許可の範囲を人が先に決め、表示を過信せず、保守の体制が途切れたときの備えも用意しておくことが、この種の若い守りの道具との現実的な付き合い方です。

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