コーディングエージェントに小さなタスクを1つ任せたとしよう。失敗しているテストを修正するだけ。ところが20分後、無関係な3つのファイルが書き換えられ、シェルで見つけた DATABASE_URL に対してデータベースマイグレーションが実行され、誰かが使用中のブランチに force push されている。プロンプトではそんなこと一切頼んでいない。エージェントはマシンを自由に使えたので、マシンを自由に使ったのだ。
権限とは、エージェントが何に触れてよいかを事前に決める仕組みだ。コーディングエージェントの権限とは、ある実行中にそのエージェントがどのファイル、コマンド、認証情報、リポジトリに到達できるか、そしてどこで人が介入しなければならないかを定めるルールである。これを正しく設定すれば、指示から外れたエージェントは、あなたが引いた箱の中で安全に失敗する。誤れば、たった1回のまずい実行が本番環境にまで届いてしまう。
本記事では、権限モデルをレイヤーごとに順を追って見ていき、各ステップの失敗パターンに名前を付け、最後に今日から実行できるチェックリストを示す。各レイヤーを具体的に理解するために Sharkly を使う。Sharkly の役割は、あなたのコーディングエージェントの上位に位置し、このスコープを1か所で管理することだからだ。あなたにはすでにコーディングエージェントがいる。Sharkly はそれらをチームに変える。そしてチームには、誰が何をしてよいかというルールが必要だ。
エージェントの権限が存在する3つのレイヤー
コーディングエージェントの権限は、1つの設定項目ではない。3か所に分かれて存在し、どれか1つに穴があれば残りの2つが台無しになる。
- ランタイムは、エージェントが呼び出せるツールを決める。ファイルの読み取り、ファイルの編集、シェルコマンドの実行、ネットワークアクセスなどだ。これは Claude Code、Codex、Gemini CLI、あるいは実際に作業を実行する任意のエージェントを指す。
- マシンは、それらのツールが何に到達できるかを決める。どのディレクトリ、どの認証情報、どの環境変数、どのネットワークか。Sharkly の Computer は「エージェントに必要なオペレーティングシステム、ファイル、認証情報、ネットワークアクセス、ツールを提供する」ため、マシンこそが実際の影響範囲となる。
- タスクは、意図の境界を決める。この実行がどのリポジトリにスコープされるか、エージェントが設定してよいステータスは何か、そして人が結果を承認する地点はどこか。
はっきり述べておくべき境界が1つある。権限は承認ゲートではない。権限とは、エージェントができることだ。承認ゲートとは、人が決める場所である。両方が必要だ。厳しい権限だけでゲートがなければ、誰も結果を確認しない。ゲートがあっても権限が緩ければ、誰かが目を向けた時点で手遅れになっている。
ステップ1：ランタイムのツールを範囲限定する
まずはエージェントが実際に行動する場所から始めよう。ほとんどのコーディングエージェントには権限システムが備わっている。ツールの許可リストと拒否リスト、そして破壊的な処理が実行される前の確認プロンプトだ。たとえば Claude Code では、特定のツールを許可または拒否でき、シェルコマンドを実行する前に確認を求める。正確な設定名はランタイムによって異なり、頻繁に変わるので、去年見つけたスニペットではなく、お使いのエージェントの最新ドキュメントを読んでほしい。
安全なデフォルトは、読み取りには寛容に、書き込みには厳しく、だ。リポジトリの読み取り、テストの実行、型チェック、ビルドは確認なしでエージェントに任せよう。ファイル編集とシェルコマンドは、プロンプトまたは明示的な許可リストで制限する。
この失敗パターンには名前がある。納期に追われた誰もが手を伸ばす、丸ごとスキップモードだ。どのランタイムにもすべてのプロンプトを無効化するフラグがあり、監視下のセッションでは便利である。危険なのは、これを無人実行でもオンのままにしておくことだ。決して確認を求めないエージェントは、誤っていた計画に従って作業しているとき、誤解した対象を平気で削除する。見ているときは自動承認を使い、その場を離れるときはオフにしよう。
ステップ2：マシンとその認証情報を範囲限定する
マシンがエージェントにすべてを渡してしまえば、ランタイムのツールリストは無意味だ。普段使いのマシンでシェルコマンドを実行できるエージェントは、すべての SSH キー、すべての .env、そしてあなた自身のログインが到達できるあらゆる認証情報を読み取れる。この失敗は静かだ。エージェントが本来見るはずのない本番キーを使うまで、何もおかしく見えない。
影響範囲を縮める方法は2つある。1つ目は、本当の秘密を保管しているノート PC ではなく、スコープを絞った環境でエージェントを動かすこと。Sharkly は、有効期限が短く1回限りのインストールトークンで Computer を登録する。ドキュメントの表現は率直だ。そのトークンを再利用可能なイメージ、スクリプト、Task、コメントに書いてはいけない。Computer がコンテナであれ、サーバーであれ、予備のマシンであれ、エージェントの到達範囲はその環境の到達範囲であり、あなたのものではない。オフラインの間もエージェントに作業させたいなら、開いたままのノート PC ではなく、リモートの Computer で動かそう。
2つ目は、その実行に必要なものだけを渡すことだ。Sharkly の実行環境は、明示的な設定から組み立てられる。アタッチされたリポジトリ、環境変数、シークレットのバインディング、作業ディレクトリである。Space のデフォルトより狭いコードスコープが必要な場合は、エージェントにリポジトリをアタッチしよう。そうすればフロントエンド担当の Agent が課金サービスをチェックアウトすることはない。各実行は専用の分離された worktree に保つ。これは、まずい編集が1つのチェックアウト内にとどまるか、2つのエージェントが同じ作業ツリーを破壊するかの違いだ。すべてのフィールドに社内ルールが当てはまる。入力するのは製品が求めている設定だけにし、無関係なフィールドや起動コマンドにパスワードやトークンを貼り付けてはいけない。
ステップ3：タスクを範囲限定し、マージは人に委ねる
最後のレイヤーは意図だ。正しくサンドボックス化され、認証情報もスコープされたエージェントでも、間違った作業をすることはある。自分のタスクを完了にする、未完成の変更を共有ブランチに push する、PR をマージ可能と判断する、といったことだ。
ここが、人とエージェントの契約が属する場所だ。エージェントは調査し、実行し、テストし、報告する。人は方向性を示し、権限を与え、結果を承認する。自動化は、チームの判断が必要なところで止まる。エージェントにはドラフト PR を開き、テスト出力を添付することを許すべきだが、その PR を承認したり、保護されたブランチにマージしたりはすべきでない。ホスト側のブランチ保護とタスク上の人によるレビューが、この一線を保つ2つの鍵である。
Sharkly では、タスク自体がこの制限を担う。Task type Workflow が、Agent が選択できるステータスを制約するので、Agent が人だけが持つ「Done」や「Released」の状態へ作業をこっそり移すことはできない。Agent が判断を必要とするときは、タスクを人によるレビュー待ち、または人の返信待ちのままにし、それが Inbox に表示され、担当者が承認したり、変更を依頼したり、再アサインしたりできる。実行、ブロッカー、結果、レビューはすべて1つのタスクに戻ってくる。5つのターミナルに散らばることはない。
ここもまた、自作のセットアップがスケールしなくなる地点だ。エージェント1つ、リポジトリ1つ、慎重なエンジニア1人なら、権限モデル全体を頭の中に収められる。2つ目、3つ目のエージェント、さらに多くのリポジトリ、そしてチームメイトが加わると、「ここで各エージェントは何をしてよいのか」という問いに、誰も記憶だけでは答えられなくなる。タスクボードは、そうしたルールを共有可能で検査可能な設定に変える。誰が作業を割り当てたか、その実行のスコープは何だったか、どんなエビデンスが返ってきたか、誰が承認したか。それがコーディングエージェントの上位にある管理レイヤーだ。worktree、スコープされた認証情報、ブランチ保護を使って手作業で構築することもできるし、既存のコーディングエージェントを Sharkly 経由で実行して、権限・タスク・レビューを1か所で管理することもできる。
今日から実行できる権限チェックリスト
実際のリポジトリに触れさせるすべてのエージェントについて、このリストを上から確認しよう。
- ランタイム：読み取りとテストは確認なしで許可し、編集とシェルコマンドは制限する。無人実行では丸ごとスキップモードをオフにする。
- マシン：エージェントは普段使いのマシンではなく、スコープされた Computer 上で動かす。インストールトークンとアクセストークンは1回限りにし、決してコミットしない。
- 認証情報：その実行に必要な環境変数とシークレットのバインディングだけを使う。無関係なフィールドには何も貼り付けない。
- リポジトリのスコープ：エージェントには作業に必要なリポジトリだけをアタッチし、Space 内のすべてのリポジトリを渡さない。
- 分離：各実行に専用の worktree を持たせ、まずい変更が共有チェックアウトを壊せないようにする。
- タスクのスコープ：エージェントは作業中のステータスは設定できるが、人だけが持つ承認済み・リリース済みの状態へタスクを移すことはできない。
- マージ：エージェントの PR と main の間には、ブランチ保護と、タスク単位のエビデンスを伴う人によるレビューが立ちはだかる。
どこか1行でも緩いなら、それがなぜ重要かを思い知らされるインシデントの後ではなく、次の実行の前に締めておこう。
FAQ
コーディングエージェントの権限と承認ゲートの違いは何ですか？ 権限は、エージェントが技術的に何を行えるかを定義する。どのファイル、コマンド、認証情報に到達できるかだ。承認ゲートは、エージェントが行ったことを受け入れるかどうかを人が判断する地点である。両方が必要だ。厳しい権限でも、人が確認すべき作業は残るし、エージェントにそもそも害を及ぼす権限があれば、承認ゲートは役に立たない。
コーディングエージェントに自分の PR をマージさせることは許されるべきですか？ いいえ、デフォルトでは許されるべきではない。エージェントにはドラフト PR を開き、検証出力を添付させ、マージは人または必須レビューに委ねよう。根拠は人とエージェントの契約だ。エージェントは実行して報告し、人は承認してリリースする。エージェントが作業の大部分を行うhuman-in-the-loop ワークフローでも、これは変わりない。
すべての権限確認プロンプトをオフにしてエージェントを実行するのは安全ですか？ あなたが監視している間だけだ。自動承認モードは、誤ったステップを止められる監視下のセッションでは役立つ。無人実行や夜間実行では、プロンプトまたは許可リストをオンのままにし、エージェントをスコープされたマシン上で動かして、ミスが封じ込められるようにしよう。
