開発ローカルの権限を AI にどこまで渡すか

問題を一言で

AI エージェントに開発を手伝ってもらうほど便利になる。ところが今の設定では、その AI が開発マシンの中身を全部見られる。見られて困るものが、同じマシンに全部置いてある。

同じマシンに置いてあるもの（実測）

「全権限を渡すのが怖い」の中身はこれです。1 つでも外へ出ると、影響は AI ツールの停止では済みません。

境界を作りにくくしている実測の事実が 2 つ

1. <開発ツリー> は「認証されたユーザー」全員に変更権を与えている。 つまり新しくローカルユーザーを作っただけでは、そのユーザーからも <開発ツリー> 配下が全部見えて書けます。SSH 鍵もサーバー接続情報も含めて。ユーザーを分けるだけでは境界になりません。

2. すでに同じ発想の実例がこのマシンにある。 と という専用ユーザーが作られ、 という専用グループに入っています（管理者ではありません）。Codex CLI のサンドボックス機能が用意したものです。作り方の前例はすでに動いているということです。ただし現在の Codex の設定は上のとおり全アクセス許可なので、その仕組みは使われていません。

まだ分かっていないこと

Grok Bot の「常に許可」が具体的にどこまでを許すのか、フォルダ単位の制限があるのか、画面に書かれている「自動レビュー」が何を見ているのか。設定ファイルを調べた範囲では見つかりませんでした。ここが分かると、いくつかの案の評価が変わります。（→ 論点 B）

なお、Grok Bot の Windows アプリには「箱へ秘密を送る」仕組みの状態ファイルがあり、現在の送信件数は 0 でした。仕組みは配線済みで、まだ動いていない状態です。

選ぶときのいちばん大事な軸：ふだんどおり使えるか

どれだけ安全でも、アプリがふだんどおり使えなくなる案は採用されません。分離の強さと同じ重さで、操作の仕方を並べます。

実測で分かったこと。 インストール先 <アプリのインストール先> は一般ユーザーに読み取りと実行を許可しており、設定はユーザーごとに分かれ、管理者権限も要求していません。別のローカルユーザーからでも起動でき、そのユーザー専用の設定を持てるということです。案4 が成立する土台はあります。

未確認が 1 つ。 別ユーザーとして起動したときに、このアプリのウィンドウが問題なく表示され正常に動くかは試していません。Windows の一般的な挙動としては同じ画面に出ますが、アプリによっては動かないことがあります。案4 を選ぶなら、ここを最初に試すべきです。

おすすめとその理由（2026-09-03・2 回目の改訂）

案4 を第一に、案3 を次点に推します。 「ふだんどおり使えないと意味がない」という条件を軸に入れた結果、順位が変わりました。案6 は分離では最強ですが、リモートデスクトップ越しの操作になるのでここで落ちます。

まず、なぜ案6 を第一に置かないか

案6 は分離の強さでは今も最強です。マシンそのものが別で、ホストが動いていれば常時稼働し、自分の管理下なので高価値の認証も置けます。入れ子でもなくライセンスも余っている。

落ちる理由は 1 つだけ。別マシンなので、操作はリモートデスクトップ越しになります。 ウィンドウの中にデスクトップがもう 1 枚入る形です。ふだん使いのアプリをその向こうで操作し続けられるか、という点で無理があります。使わなくなる案は、どれだけ安全でも守ってくれません。

ただし用途を分けるなら今も有効です。夜間の自律作業や、開発マシンを落としている間の受け皿としては最良の選択肢のままです。日常のアプリ操作を案4 か案3 で解き、案6 は夜間用として後から足す、という組み合わせが成立します。

案4 を第一に推す理由

0 つめ。ふだんどおり使える。別ユーザーとして起動しても、ウィンドウは同じ画面に出ます。画面が切り替わらないので操作感がほぼ変わりません。実測でも、インストール先は一般ユーザーに実行を許可していて、設定はユーザーごとに分かれ、管理者権限も要りませんでした。土台はあります（ウィンドウが実際に正常表示されるかだけ未確認）。

1 つめ。やりたいことを諦めずに済む。たくさん使いたいという前提を落とさずに、範囲だけを絞れます。案3 や案5 は安全ですが、使い方のほうを削ります。

2 つめ。約束ではなく仕組みになる。案2 と案8 は人の注意力に依存します。忙しいときに破れる対策は、いちばん破れてほしくないときに破れます。

3 つめ。前例がこのマシンで動いている。 という同じ形が既に作られています。ゼロから設計する話ではありません。

次点に案3 を置く理由

案3（ローカル実行を切って箱だけで使う）は、設定 1 つで済むうえに操作感がまったく変わりません。アプリは今までどおり自分の画面で動き、手元のファイルを触らなくなるだけです。境界としても強い。

案4 との違いは 1 点だけ。手元のファイルを AI に触らせる使い方ができなくなることです。そこが要らないなら、案3 のほうが安くて確実です。まず案3 で試して、不便を感じたら案4 へ移るという順序も現実的です。

3 つを一言で

案3 は設定 1 つで、手元を一切触らせない。案4 は操作感を保ったまま、触れる範囲を決める。案6 は操作の手間と引き換えに、いちばん強い分離と常時稼働を買う。

案9（Linux 環境）を推さない理由

運用の軽さでは案9 がいちばんです。OS が増えず、既に動いていて、起動も速い。安定して回しやすいのは事実です。

ただし今回の懸念には当たりません。Grok Bot は Windows のアプリなので、Linux 環境の中では動かないからです。立てても、Grok Bot が見る範囲は変わりません。加えて、この開発マシンが落ちれば一緒に落ちるので、夜間の受け皿にもなりません。

案9 が効くのは、Linux で動く AI ツールを隔離したい場合です。そのときは automount と interop を切るのが前提になります（いまは両方とも入ったままで、中から <開発ツリー> が全部見えます）。案4 や案6 と併用する分には無理がありません。

なお案7 は案4 とも案6 とも一緒に使えます。「見せない」を作ったうえで「見せる場所」を作る、という組み合わせが自然です。どれか一方を選ぶ関係ではありません。

選んだ内容とメモを下に書き出します。コピーして記録に貼れます。