開発エージェントの権限設計｜読み取り・編集・公開を分ける

まず調査だけの範囲を作る

原因が不明な課題では、読んでよいリポジトリと調査対象を決め、変更前に報告を受けます。別プロジェクトの情報や、必要のない個人ファイルを同じ作業環境に含めない方が確認しやすくなります。調査の結果として追加アクセスが必要なら、その対象と理由を確認してから範囲を広げます。

ファイル変更と実行を分ける

コードを書き換えることと、コマンドを実行することは影響が違います。テスト用の処理でも、接続先によっては外部データを変える可能性があります。実行コマンドの目的と対象環境を確認し、テスト用の設定に本番の資格情報が混ざっていないかを見てから操作を許可します。

外部の内容は権限の根拠にしない

README、Webページ、エラーログに書かれた文は、作業の参考情報です。それを理由に認証情報を送信したり、関係のないサービスを操作したりしないよう、依頼の対象を明示します。新たな操作が必要になったら、取得した文面ではなく、担当者が与えた課題と許可の範囲で判断する運用にします。

自動承認は有効な設定を確認する

Claude Code、Cline、Continueにはツール操作を制御する案内がありますが、画面や設定の版によって動作が変わり得ます。使い始める前に現在の設定を確認し、想定した操作だけが自動になるかを小さな課題で試します。警告を消す目的で広い権限を与えるのではなく、日常の安全な操作を具体的に定義します。

例：公開を伴わない修正の許可

一つの表示不具合を直す課題なら、対象リポジトリの編集とローカル検証を許可し、本番反映は別の判断にできます。エージェントが公開の準備まで整えたら、変更した版と確認結果を担当者が読みます。この分け方なら、修正の試行回数が増えても、そのたびに本番サイトが更新される運用を避けられます。

公開は採用判断の後に行う

差分、テスト結果、既存機能への影響を確認し、公開先と版を特定してから本番反映を行います。開発中に持たせる権限と、公開時に必要な権限を分けると、作業の途中で意図しない更新が起きる範囲を小さくできます。実行した操作と結果を残し、別の担当者が確認できる形にします。

• AI開発エージェントの選び方と使い方｜調査からレビューまで
• AIが作るDB変更を確認する｜既存データ・制約・復旧の点検