なぜClaude Code運用でAIガバナンスが必須なのか。自律エージェント時代の権限管理

AIエージェントが鍵を握る時代の幕開け

AIがコードを書き、決済し、サーバーを構築する。そんな未来が目の前にある。

Claude Codeのような自律型エージェントは開発者の生産性を引き上げる。

だが、代償は小さくない。

権限管理を誤れば、リポジトリは消え、クラウドの請求額は跳ね上がり、機密情報は流出する。

これからの開発者に求められるのは、コードを書く技術ではない。

AIという「自律的な部下」にどこまでの自由を与え、どこで首輪をかけるかというAIガバナンスの設計能力だ。

数字で言えば、1つのプロンプトミスが数千ドルの損失に直結する。

そんな時代の歩き方を解説する。

内部の守りと外部への証明

AIエージェントを巡る技術動向は、大きく2つの方向に進化している。

1つは、Claude Codeに代表される「ローカル環境での自律的な実行権限」の制御だ。

もう1つは、AgentKitに代表される「外部サービスに対するAIの身元証明」の構築だ。

内側の守りについて触れる。

AIエージェントは、ターミナルを叩き、ファイルを編集する。

これは強力だが、同時にリスクを伴う。

AIが勝手にrm -rfコマンドを実行したり、.envファイルを読み取って外部に送信したりする可能性がある。

これを防ぐために、最新のツールにはManaged Settingsという仕組みが導入されている。

組織やプロジェクトレベルで「やってはいけないこと」を固定する機能だ。

開発者が個別に設定を変更しようとしても、上位のポリシーが優先される。

denyルールが常にallowルールに勝つ。

この優先順位の徹底がAIガバナンスの第一歩だ。

次に、外側への顔について触れる。

AIエージェントがインターネット上で買い物をしたり、APIを叩いたりする際、相手側のサービスは「これは本当に人間が許可した操作か」を判断する必要がある。

この疑問に答えるのが、World IDのような人間性証明技術を活用したAgentKitだ。

AIエージェントに「この人間に雇われている」というデジタルな証明書を持たせる。

これによって、AI同士が直接取引を行うエージェント経済圏が成立する。

ブロックチェーン技術をベースにしたx402プロトコルなどが、その決済インフラとして注目されている。

開発者は「コードの書き手」から「ポリシーの設計者」へ

Claude Codeは、リポジトリの中身を把握し、シェルを実行し、外部ドメインと通信する。

この「全権掌握」の状態は、セキュリティホールになり得る。

ここで重要になるのが、OSレベルでのサンドボックス化だ。

bubblewrapのようなツールを使い、AIがアクセスできるファイルシステムを物理的に隔離する。

システム領域やSSH鍵が置かれているディレクトリを、AIからは見えない状態にする。

ネットワーク通信も、許可されたドメイン以外は遮断する。

これが「防御的設定」の核心だ。

さらに、プロンプトインジェクションへの対策も欠かせない。

外部から読み込んだファイルの中に、AIを操るための悪意ある命令が隠されている可能性がある。

これを防ぐには、AIが実行するアクションに対して、人間が介入する承認プロセスを組み込む必要がある。

特に破壊的な操作や、機密情報の読み取り、外部へのデータ送信については、Askモードを強制する。

自動化の恩恵を多少削ってでも、このガードレールは外さない。

しんたろー：設定は面倒だ。でも、一度でも「AIに本番DBを飛ばされる悪夢」を想像すれば、この手間は安い。僕も自分のプロジェクトで、うっかり環境変数を読み取られそうになり冷や汗をかいた。ツールを信じることと、権限を丸投げすることは別物だ。

また、外部サービスとの連携においては、AgentKitのような仕組みがスタンダードになる。

AIが勝手にクレジットカードを使って買い物をする未来はすぐそこだ。

その時、サイト側は「このAIは正当なユーザーの代理人か」を瞬時に判断しなければならない。

ここで使われるのが、World IDによる認証だ。

虹彩認証などで「唯一無二の人間」であることを証明したIDをAIに紐付ける。

これによって、AIの行動が「人間の責任」であることが法的に、かつ技術的に担保される。

開発者は、この「身元証明」のフローをシステムアーキテクチャに組み込む必要がある。

実務で直面するガバナンスの壁と解決策

具体的に開発現場で何をすべきか。

まず、プロジェクトのルートディレクトリに.claude/settings.jsonを作成する。

ここに、そのプロジェクト固有の権限設定を記述する。

特に重要なのは、.envやconfigフォルダ、あるいは.gitディレクトリへのアクセスを明示的にdenyに設定することだ。

また、rm -rfやcurl、wgetといったコマンドの使用も、基本的には制限するか、実行のたびに確認を求める設定にする。

次に、組織レベルでの統制だ。

大規模なチームでAIエージェントを導入する場合、個々の開発者の裁量に任せるのは危険だ。

Managed Settingsを活用し、全社共通のセキュリティポリシーを強制する仕組みを構築する。

これには、OpenTelemetryなどを用いた実行ログの監査も含まれる。

AIがいつ、誰の指示で、どのファイルに触れ、どのコマンドを実行したのか。

これをすべて記録し、後から追跡できるようにしておく。

これは万が一の事故が起きた際の「原因究明」と「責任の所在」を明確にするために不可欠だ。

さらに、インフラ構成も変わる。

これまでは「開発者のローカルマシン」で動かしていたAIエージェントを、専用のセキュアなコンテナ環境で動かす運用が主流になる。

ローカルのファイルを直接触らせるのではなく、必要なファイルだけをマウントした隔離環境だ。

ここでSandboxing機能を有効にし、ネットワークの出入り口を絞る。

もしAIが暴走しても、その被害をコンテナ内に封じ込めることができる。

しんたろー：最近はコードを書いている時間よりも、設定ファイルとにらめっこしている時間の方が長い。1人SaaS開発と言いつつ、実はAIという部下のマネジメントをしている感覚に近い。でも、この設定をコードとして管理できるようになれば、運用の負荷は下がるはずだ。自動化を安全に進めるためには、そのための型を人間が作るしかない。

また、外部APIとの通信においては、ドメイン制限を徹底する。

Claude Codeには、内蔵のウェブ取得ツールがあるが、これも許可リスト方式で運用する。

意図しないサイトへのデータ送信を防ぐためだ。

コマンドの引数レベルの制限に頼るのではなく、より上位の「通信先」や「実行環境」のレベルで制限をかける。

よくある質問

Q1: Claude Codeの権限設定で最も優先すべきことは？

Managed Settingsによるdenyルールの強制だ。

開発者が個別に設定を変更できないよう、組織レベルで.claude/settings.jsonのポリシーを固定する。

特に.envやSSH鍵へのアクセス、rm -rfなどの破壊的コマンドを明示的に拒否するように設定する。

また、サンドボックス機能でfailIfUnavailable: trueを設定し、セキュリティ環境が構築できない場合は実行を停止させるハードフェイル構成にする。

Q2: AIエージェントの外部取引におけるリスクはどう防ぐべきか？

AgentKitのような「人間による承認」をプロセスに組み込むことが不可欠だ。

AIが勝手に決済や外部APIへの書き込みを行う際、World IDのような認証基盤を用いて、その行動が特定の人間によって許可されたものであることを証明するプロトコルを導入する。

これによって、受け手側のサイトは「このリクエストは信頼できる」と判断できるようになる。

x402のようなオープンな標準規格を使うことで、不正利用のリスクを低減し、透明性の高い取引が可能になる。

Q3: サンドボックス導入は開発効率を下げないか？

短期的にはセットアップの手間が増えるが、長期的には心理的安全性は高まり、生産性は向上する。

隔離環境がない状態では、AIに大胆なリファクタリングを任せるのは難しい。

しかし、OSレベルで保護された環境であれば、万が一AIが間違ったファイルを消そうとしてもシステムが阻止する。

この「失敗しても大丈夫」という環境こそが、AIエージェントの能力を最大限に引き出す鍵だ。

bubblewrapやsocatといったツールの導入は、開発環境構築の標準的なステップだ。

自由と規律のバランスが、次世代の開発を定義する

AIエージェントは、手から作業を奪い、代わりに決断を求めてくる。

何をさせ、何をさせないか。

その境界線を引くことこそが、これからの開発者のメインジョブになる。

Claude Codeを使いこなしつつ、AgentKitで外部との信頼を築く。

この「内と外」の両面からのガバナンスが、プロジェクトを次のステージへ引き上げる。

しんたろー：結局のところ、AIを使いこなすっていうのは、AIを信じすぎないことだ。最高のツールを、最悪の事態を想定しながら使う。この矛盾を受け入れた先に、本当の意味での1人SaaS開発の成功がある。さて、僕も自分の設定ファイルを見直して、もっと攻めの開発ができる環境を整えるとしよう。