AI エージェントに開発マシンの鍵を渡していいのか。借り物のサンドボックスを実測して、9 案を比べた
AI エージェントの作業場として借りている Linux サンドボックスから、Claude と ChatGPT のサブスクリプション認証を引き上げました。規約違反だったからではなく、自分が管理していない実行環境に、失うと痛いアカウントの認証を置いていたからです。そして調べている途中で、引き上げた先の自分の開発マシンには、境界が 1 本も引かれていないことに気づきました。実測のコマンド出力と規約の条文、9 つの選択肢の比較まで。結論はまだ出ていません。
この記事のテーマ
各リポジトリの設計書とメモを、Windows の開発マシンと借りている Linux サンドボックスの両方から読めるようにしたい。始まりはそれだけでした。ところが計画書に書いてあった前提を実機で 1 つずつ確かめたところ、3 つとも崩れました。箱は永続ボリュームを持たない使い捨てのコンテナで、しかもその寿命を握っているのは提供元でした。共有したかった 1.3GB の実体は、Markdown 6.1MB でした。
途中で「借りている箱に、他社のサブスク認証を置いていいのか」という問いが出ました。条文を引くと、禁止されているという根拠は見つかりません。代わりに見つかったのは、その箱が 12 か所の資格情報を 30 秒ごとに外部へ複製する仕組みを持っていたことでした。本当の問いは規約ではなく、預け先のほうにありました。
記事全体の要約。境界のない現状、9 つの対策案、実測から得られた教訓。
音声で聴く（AI ラジオ解説・24 分）
この記事を NotebookLM でラジオ風に音声化したものです。移動中や作業しながらでもどうぞ。
引き上げた先に、壁が 1 本も無かった
一日じゅう「借りている箱に何を預けるか」を考えていて、最後に気づいたのがこれでした。認証を引き上げた先の Windows マシンは、同じベンダーのアプリが「常に許可」で実行できる場所だったのです。しかもそのマシンには、サーバーの接続情報も SSH の鍵 7 本も顧客のナレッジベースも、全部そろっています。
境界になりそうなものを 3 つ実測しましたが、どれも効いていませんでした。開発ツリーの権限設定のせいでユーザーを分けても素通りし、AI アプリの実行許可は常に許可のまま、別の AI ツールは承認なしの全アクセス設定でした。
1 つ締めても隣が開いていれば意味がない。いちばん緩いツールが、そのマシンの実際の境界になる。
安全さだけで選ぶと、使われなくなる
取りうる手を 9 つ並べて、分離の強さで順位を付けました。1 位は専用の仮想マシンです。そこに「どの案でも、ふだんどおりアプリを使えないと意味がない」という指摘が入り、評価軸が 1 本足りていなかったと分かりました。
使い勝手の軸を足すと順位が入れ替わり、第一候補は制限ユーザーと ACL の組み合わせになりました。分離では最強だった専用 VM は、日常操作がリモートデスクトップ越しになるので落ちます。捨てるのではなく、夜間の自律作業の受け皿として後から足す位置づけに変えました。
どれだけ安全でも、ふだんどおり使えなくなる案は採用されない。使われない対策は、守ってくれない。
検討シート（マスク版）
9 案と残る 4 論点をまとめた検討シートを、固有名を伏せた形で置いてあります。単一の HTML ファイルで、案ごとにメリットとデメリットと採用ボタンがあり、選んだ内容を Markdown で出力できます。
開発ローカルの権限を AI にどこまで渡すか（検討シート・公開版）
この記事で触れているツール
複数の AI コーディング CLI を並列で走らせ、承認をブラウザ 1 タブに集約するローカルダッシュボード many-ai-cli を作っています。リポジトリは GitHub にあります。