AI開発ツールに任せる前の権限チェック

AI開発ツールにコード修正を頼む時、モデル選びより先に決めたいことがある。どのファイルを読めるか、どこまで変更できるか、どの操作から外部へ影響が出るかだ。

「危ないコマンドだけ確認する」では足りない。安全そうな編集でも、作業範囲が広すぎれば関係ない設定を変えられる。ブラウザ操作では、正しいページを開けても、いま見ているタブを上書きされたら困る。公開処理では、本文が正しくても同じ日に二重実行されれば事故になる。

この記事の改稿時には、実際の制作自動化で権限境界を検証した。ブラウザ分離は、前面アプリ、既存Braveの起動状態、ウィンドウ、タブ、フォーカスの5判定がすべて維持された。一方、公開側の重複防止ロックは当日分を2件検出し、追加の変更を止めた。つまり、役に立ったのは「AIを信頼するか」という抽象論ではなく、外部へ影響が出る直前に機械的な停止線を置いたことだった。

以下では、個人開発や副業の小さなプロジェクトで使えるように、権限を5段階に分け、最初の10分で確認する方法までまとめる。

結論：権限は「読む・変える・実行する・接続する・確定する」に分ける

AI開発ツールの権限は、オンかオフかの二択ではない。最低でも次の5段階に分けると、便利さを落としすぎずに事故の範囲を狭められる。

段階	代表的な操作	最初の設定	人の確認が必要な場面
読む	ソース、設定、テスト結果の確認	作業プロジェクト内だけ許可	秘密情報、仕事用領域、ブラウザ情報が含まれる時
変える	ファイル編集、新規ファイル作成	バージョン管理された範囲だけ許可	プロジェクト外、設定の大幅変更、依存関係追加
実行する	テスト、整形、ビルド、シェルコマンド	確認系と検証系から始める	削除、移動、インストール、長時間処理
接続する	Web取得、API呼び出し、ブラウザ操作	接続先と用途を限定する	ログイン、別アカウント、既存タブへの操作
確定する	公開、送信、共有、購入、権限変更	自動許可しない	実行対象とアカウントを確認した直後だけ

ポイントは、ファイル編集と外部確定を同じ権限にしないことだ。記事やコードをローカルで完成させるところまでは自動化しやすい。しかし、公開ボタンを押す、メールを送る、共有範囲を広げるといった操作は、失敗した時の影響がプロジェクト外へ広がる。

最初からすべてを手動確認にすると、確認疲れで重要な警告まで流しやすい。逆に、すべてを許可すると、成功条件を満たしていない処理まで連続して進む。低リスクの確認・編集は通し、高リスクの確定だけを狭く止めるのが現実的だ。

最初の10分で確認する4つのコマンド

AIに編集を任せる前に、まず現在地と差分の見え方を確認する。特別な監視ツールがなくても、Git管理のプロジェクトなら次の4つで最低限の土台を作れる。

1. 現在地を確認する

pwd

同じ名前のフォルダが複数ある環境では、ここを飛ばすと別のコピーへ変更を入れやすい。プロンプトに「このプロジェクトだけ」と書くより、実行前に絶対パスを確認する方が確実だ。

2. 変更前の状態を短く確認する

git status --short --untracked-files=no

すでにある変更は、AIが作ったものとは限らない。先に状態を見ておけば、既存の作業を消さず、今回触るファイルだけを分けられる。未追跡ファイルが大量にある制作環境では、最初からすべて表示せず、対象パスへ絞る方が確認しやすい。

3. 編集後の空白・構文上の崩れを確認する

git diff --check

このコマンドだけでプログラムの正しさは保証できない。ただし、不要な末尾空白や競合マーカーなど、差分に混じった基本的な異常を早く見つけられる。テストと役割を混ぜず、「差分の衛生確認」として使う。

4. 公開対象の実体を固定する

shasum -a 256 path/to/output-file

動画、電子書籍、配布ファイルなどは、品質確認したファイルと送信するファイルが同じかをハッシュで照合できる。ファイル名だけでは、書き出し直した別版を取り違える可能性が残る。確認時の値と送信直前の値が一致しなければ、確定処理を止める。

この4つは万能なセキュリティ対策ではない。それでも、「どこを触るか」「変更前に何があったか」「差分が壊れていないか」「確認した成果物と同一か」という4つの問いに答えられる。

読み取り権限も無制限にしない

読み取りは変更を伴わないため、安全に見えやすい。しかし、環境変数、認証ファイル、ブラウザのプロファイル、過去ログには、外へ出したくない情報が含まれることがある。読める範囲が広いほど、プロンプトやログへ混ざる範囲も広くなる。

最初は次の順番で広げるとよい。

対象のソースファイルだけ
同じプロジェクト内のテストと設定
必要なエラーログの該当部分
外部ドキュメントの公式ページ

ホームディレクトリ全体、ブラウザプロファイル全体、過去の巨大ログは最初から渡さない。必要になった時に、目的と対象を1つずつ説明できる範囲で追加する。

ログも全文を渡す必要はない。まず error、failed、status、output_path のような判定項目を絞り、原因が見えない時だけ前後を広げる。これは入力データを減らすだけでなく、AIが無関係な過去情報へ引っ張られるのを防ぐ。

ファイル編集は「戻せる範囲」だけ自動化する

編集権限を渡す時の基準は、「AIが賢いか」ではなく「失敗しても差分から戻せるか」だ。次の条件がそろう範囲なら、自動編集の利点を得やすい。

Gitなどで変更前との差分を確認できる
今回触るパスが明示されている
既存のユーザー変更を消さない
テストまたは機械検証がある
生成物と設定ファイルの保存先が分かれている

反対に、プロジェクト外への移動、既存データの削除、認証設定の上書きは別扱いにする。編集できるからといって、削除まで同じ許可に含める必要はない。

依存関係の追加も注意したい。パッケージを1つ追加すると、ロックファイルや間接依存まで変わることがある。必要性、追加されるファイル、テスト結果が説明できない場合は、その場で自動承認しない。まず既存の機能で代替できないかを確認する。

AIへ頼む文面も「直して」だけでは広すぎる。たとえば次のように、対象・禁止・合格条件を一緒に書く。

対象は src/example.py と対応テストだけ。既存の公開APIは変えない。失敗しているテストを再現し、最小修正後に同じテストと差分確認を行う。

この形なら、編集の自由度を残しつつ、関係ないリファクタリングが広がりにくい。

コマンド実行は「確認・変更・外部影響」で分ける

シェルコマンドを一括で許可すると、ls と削除処理が同じ扱いになる。実務では、コマンド名だけでなく作用で3つに分ける方が分かりやすい。

確認系

pwd、rg、git status、git diff、テストの一覧表示など。基本は読み取りで、作業対象を把握するために使う。ただし、秘密情報を表示するコマンドや巨大ログの出力は対象を絞る。

ローカル変更系

フォーマッター、テスト用ファイル生成、ビルド、依存関係追加など。変更先が作業範囲内で、差分と後始末を確認できる場合に許可する。

外部影響系

アップロード、送信、公開、課金を伴うAPI、リモートの削除、権限変更など。コマンド自体が短くても影響は大きい。アカウント、対象、内容、添付、公開範囲を実行直前に確認する。

AnthropicのClaude Code CLIリファレンスには、許可・不許可ツールや権限モードに関する指定があり、権限確認を省くオプションには注意喚起が付いている。設定名を暗記するより、「何を自動許可し、何を止めるか」を先に決めてから公式仕様へ落とし込む方が設定漏れを減らせる。

ネットワークとブラウザは別の権限として扱う

ローカルファイルを編集できても、任意の接続先へ通信できる必要はない。ネットワークを分ける理由は、誤送信だけではなく、取得したページ内の指示や不明なリダイレクトに作業が引っ張られるのを防ぐためでもある。

GitHubのCopilot cloud agentのファイアウォール設定では、インターネット接続を制限する目的と、許可リストの考え方、保護範囲の限界が説明されている。これは特定製品だけの話ではない。接続先を必要最小限にする、警告を記録する、ファイアウォールだけで完全防御と考えない、という3点はローカルのAI開発でも使える。

ブラウザ操作では、さらに「どのタブを使うか」を分ける。自動化専用の新規タブや独立したコンテキストを使い、利用者が見ている前面タブを移動・再読み込みしない。作業後は自動化が開いたタブだけを閉じる。

今回の分離検証では、5つの判定がすべて成功した。ここで重要なのは、目的のページを開けたかだけではない。前面アプリ、既存ウィンドウ、既存タブ、フォーカスが維持されたことまで成功条件に含めた点だ。

OpenAIのCodex利用案内でも、ブラウザの完全なCDPアクセスは機密性の高い内部状態を扱いうるため、明示的な承認と管理設定の対象として説明されている。便利だから常時有効にするのではなく、コンソールやネットワーク確認が必要な時だけ範囲を広げる方がよい。

公開・送信の直前には3つの機械的な門を置く

外部確定を安全にするには、人間の注意力だけへ頼らない。少なくとも次の3つを機械判定にする。

1. 品質ゲート

必要項目、テスト、リンク、ファイル形式、秘密情報の混入などを確認する。不合格なら品質基準を下げず、修正または別候補へ切り替える。

2. 同一性ゲート

レビューした成果物と送信する成果物が同じかを、絶対パス、更新日時、ハッシュなどで確認する。動画や電子書籍のようなバイナリは、ハッシュ照合が特に分かりやすい。

3. 一意性ゲート

同じ日、同じ対象、同じ処理が二重実行されないようにロックを置く。今回の確認では、日付単位のロックが当日分2件を検出し、追加変更を停止した。ここでロックを削除して続行すると、重複防止の意味がなくなる。確認済みの外部状態を調べるまで、処理を止めたままにするのが正しい。

品質、不変性、一意性は役割が違う。良い内容でも別ファイルを送れば失敗するし、正しいファイルでも二重公開なら失敗する。3つを別々に判定することで、原因も追いやすくなる。

AIが自動で越えない停止線

次の条件は、処理が途中でも人へ戻す。

想定していたアカウントと違う、または確認できない
ログイン、2段階認証、CAPTCHA、不明な認証画面が出た
APIキー、認証情報、個人情報が表示・送信される可能性がある
購入、課金、契約、広告出稿など金銭確定がある
外部データの削除、権限変更、共有範囲拡大がある
公開対象が直前確認から変更されている

これらは「AIなら突破できるか」を試す場面ではない。止まった時点で、外部操作直前までの成果物、停止理由、人が行う次の1操作を残す。

反対に、文章の品質不足、テスト失敗、第一候補の弱さは、すぐ人へ丸投げする理由ではない。失敗箇所を修正し、回数を決めて再検証し、直らなければ別候補へ切り替えられる。安全停止と品質改善を分けると、必要以上に自動化を止めずに済む。

設定後に行う小さな再現テスト

権限表を作っただけでは、本当に境界が働くか分からない。最初は本番データを使わず、次の順番で確認する。

読み取りだけの依頼で、作業範囲外へ進まないか確認する
テスト用ファイル1件を変更し、差分が対象内に収まるか確認する
失敗するテストを実行し、エラーを理由に危険な迂回をしないか確認する
外部送信はドライランにして、送信直前で停止できるか確認する
同じ処理を2回起動し、2回目がロックで止まるか確認する

見るべき数字は多くない。変更ファイル数、再試行回数、外部操作件数、停止理由の4つで十分だ。外部操作件数がドライランで0、変更ファイルが指定範囲内、2回目が停止すれば、最低限の境界は機能している。

失敗した時は、許可を一気に広げない。どの操作だけ足りなかったかを特定し、その1点だけ変更して再実行する。権限追加の理由が説明できない場合は、設定より手順の方を見直す。

そのまま使える権限チェックリスト

AI開発ツールを起動する前に、次を確認する。

[ ] 現在の作業パスを確認した
[ ] 読み取り範囲をプロジェクト内へ絞った
[ ] 変更前のGit状態を確認した
[ ] 触ってよいファイルと触らないファイルを書いた
[ ] 削除と依存関係追加を通常編集から分けた
[ ] ネットワーク接続先と目的を説明できる
[ ] ブラウザは専用タブまたは独立環境を使う
[ ] テストと差分確認のコマンドを決めた
[ ] 公開対象の同一性をハッシュ等で確認できる
[ ] 二重実行を止めるロックがある
[ ] 認証、秘密情報、金銭、削除、権限変更の停止線がある

全部を高度な仕組みにする必要はない。最初は対象パス、許可する操作、停止条件、検証コマンドを短いテキストへ残すだけでもよい。重要なのは、翌日も同じ基準で判断できることだ。

まとめ

AI開発ツールへ任せる範囲は、モデルへの信頼度ではなく、操作の影響で決める。

読む、変える、実行する、接続する、確定するを分ける
ローカル編集は、差分から戻せる範囲で自動化する
ネットワークとブラウザ操作はファイル編集と別権限にする
品質、同一性、一意性の3ゲートを外部確定前に置く
認証、秘密情報、金銭、削除、権限変更では自動で進まない

権限を狭くする目的は、AIを動けなくすることではない。確認系と低リスク編集を速く通し、外へ影響する操作だけを確実に止めるためだ。まずは作業範囲を1つに絞り、テスト用の変更1件とドライラン1回で境界が働くか確認するとよい。

この記事は、公開済み本文の重複・一般論・販売導線を減らし、実際のブラウザ分離検証と二重実行防止の結果、再現コマンド、公式資料を追加して改稿した。AI支援で構成と検証を行い、外部へ影響する操作は人の確認と機械ゲートを分けて扱っている。検索順位のために日付だけを変えるのではなく、読者が自分の環境で権限境界を試せることを目的にしている。

参考資料：