AIコーディングのセキュリティ: Claude Codeのベストプラクティス（2026）

これらに頼る前に、コマンド名や権限モードをClaude Codeの公式ドキュメントで確認してください。

なぜAIコーディングには異なるセキュリティの考え方が必要なのか

昔ながらのオートコンプリートは、テキストを提案するだけでした。Claude CodeのようなAIコーディングエージェントは、根本的に異なる存在です。リポジトリ全体を読み、実際のシェルコマンドを実行し、ファイルを編集し、外部ツール（MCP、web fetch、GitHub）を呼び出します。これら3つの能力が重なることで、従来のlintやコードレビューでは決して捉えられなかった攻撃対象領域が生まれます。

最もわかりやすいたとえ方は—Backslash Securityの分析（2025年9月18日）から借りたものですが—エージェントを「root権限を持った非常に高速なインターン」として扱うことです。このインターンはあなたの10倍の速さでコードを打ちますが、同時に間違ったディレクトリをrm -rfしたり、APIキーをコミットに貼り付けたり、たった今読んだGitHub issueに隠された「コマンド」に律儀に従ったりもします。悪意があるわけではなく、何が危険かという文脈を欠いているだけなのです。

重要な洞察はこうです。リスクは「AIが悪いコードを書く」ことではありません。リスクは権限（エージェントがあなたのマシンで何ができるか）と入力への信頼（エージェントが誰を信じるか）に潜んでいます。ですから正しいセキュリティ戦略は「提案される一行一行を注意深く読む」ことではなく、体系的なガードレールを構築することです。権限を制限し、環境を隔離し、出入りするデータを管理し、そして最終的な判断には必ず人間を関与させ続ける。この記事の残りの部分では、各レイヤーをどう実践するかを一つずつ解説していきます。

AIコーディングの6つの主なセキュリティリスク

何かに対策を打つ前に、何から守ろうとしているのかを知る必要があります。実務で最も頻繁に遭遇する6つのリスクカテゴリを、それぞれ具体的なシナリオとともに挙げます。

これら6つのリスクは、以下の6つのベストプラクティスにほぼ一対一で対応します。すべてを一度にやる必要はありません—ただし、あるレイヤーを飛ばすなら、自分がどのリスクを受け入れているのかを正確に把握しておきましょう。

ベストプラクティス1 - シークレットと機密データを管理する

根本原則: シークレットは、エージェントが平文で読める場所のどこにも存在してはならない。防御には安価なものから堅牢なものまで4つのレイヤーがあります。

1. シークレットをリポジトリの外に置く。 .gitignoreで.envをGitの外に保ち、フラットファイルよりもシークレットマネージャー（Vault、Doppler、1Password CLI、CIの環境変数）を優先しましょう。これはAIがなくてもやるべきことですが—AIはその後始末をより深刻にするだけです。

2. 機密ファイルをエージェントのコンテキストから外す。Claude Codeのセキュリティドキュメントでの方法は、.claude/settings.jsonでpermissions.denyにRead()ルールを使うことです—パターンに一致するファイルをエージェントは読めなくなります。

{
 "permissions": {
 "deny": [
 "Read(./.env)",
 "Read(./.env.*)",
 "Read(./**/secrets/**)",
 "Read(./**/*.pem)",
 "Read(./**/*.key)"
 ]
 }
}

（古いガイドの中には.claudeignoreファイルに言及するものもあります。お使いのCLIバージョンがまだ対応しているなら結構ですが、公式ドキュメントが推奨するのはRead()を用いたpermissions.denyです。）

3. シークレットの自動スキャン。人間の目を信用してはいけません。gitleaks（またはgit-secrets、TruffleHog）をpre-commit hookとCIに組み込み、キーを含むコミットがマシンから出ていく前にブロックしましょう。

# pre-commit: block the commit if a secret is detected
gitleaks protect --staged --redact --verbose

4. 漏洩したらローテーションする。キーがコンテキストやコミットに入り込んでしまったら、恒久的に侵害されたものとして扱いましょう—コミットを削除するだけでは不十分です。キーはすでにログ/モデル/履歴に残っているかもしれないからです。正しい手順は次のとおりです。古いキーを失効させる -> 新しいキーを発行する -> シークレットマネージャーを更新する -> アクセスログに異常がないか確認する。必要になる前にローテーションのランブックを用意しておきましょう。

ベストプラクティス2 - 権限を制御し、サンドボックスで実行する

これは最もROIの高いレイヤーです。Claude Codeには、エージェントが独断で何をできるかを決める複数の権限モードがあります。

率直な警告: bypassPermissions（および--dangerously-skip-permissionsフラグ）は、まさに名前のとおり—危険です。名前に「dangerously（危険なほど）」という語が入っているのは意図的なものです。本物のシークレット、本番アクセス、顧客リポジトリがある場所では絶対にオンにしないでください。エージェントを無人で動かす必要がある場合（バッチ処理、CI）は、メインマシン上ではなくサンドボックス内で行いましょう。

settings.jsonでは最小権限を適用します。安全なものは既定で許可し、リスクのあるものは確認（ask）し、独断で決して実行してはならないものは拒否（deny）する。コピーしてすぐ使えるテンプレートです。

{
 "permissions": {
 "allow": [
 "Read(./src/**)",
 "Bash(npm run test:*)",
 "Bash(git status)",
 "Bash(git diff:*)"
 ],
 "ask": [
 "Bash(git push:*)",
 "Bash(npm install:*)",
 "Write(./src/**)"
 ],
 "deny": [
 "Bash(rm -rf:*)",
 "Bash(curl:*)",
 "Bash(sudo:*)",
 "Read(./.env)",
 "Read(./.env.*)"
 ]
 }
}

コンテナで隔離する。被害範囲を抑える最も強力な方法は、エージェントをdevcontainer/Docker内で実行することです—必要なディレクトリだけをマウントし、不要なネットワークアクセスを遮断し、本番の認証情報を持ち込まない。たとえエージェントがプロンプトインジェクションを受けて不正なコマンドを実行しても、壊せるのはそのボックスだけで、あなたのマシンは無傷です。権限設定のより深い解説は、Claude Codeの権限を安全に設定するガイドを参照してください。

あるいはネイティブサンドボックスを使う（Dockerより軽量）。Claude Codeには/sandboxコマンドがあります—ビルドするイメージも、設定するdevcontainerも不要のOSレベルの隔離です。macOSに組み込まれたSeatbelt、Linux/WSL2ではbubblewrap + socat。コンテナと同様にファイルシステムとネットワークを隔離しますが、起動が速く、Dockerのインストールも不要です—フルのdevcontainerを立ち上げることなく、単一タスク（見慣れないリポジトリの監査、信頼できないコードの実行）を素早く隔離したいときにぴったりです。注意: これは権限モードとは異なるレイヤーです—権限モードはエージェントが行動する前に何について確認されるかを制御し、サンドボックスは不正なコマンドを実行してしまってもエージェントが実際に何をできるかを制御します。両者は補完し合うもので、置き換えるものではありません。複雑な設定を伴う長期的な開発環境にはコンテナが依然として最も強力な選択肢で、ネイティブサンドボックスは素早く一時的な隔離に向いています。詳しいセットアップはClaude Codeのサンドボックス化をご覧ください。

ベストプラクティス3 - プロンプトインジェクションと信頼できないコンテンツを防ぐ

プロンプトインジェクションは、最も特徴的で最も過小評価されているリスクです。その仕組みは、エージェントがあなたの指示と読み取ったデータをきれいに区別できないという点にあります。そのデータに命令文が含まれていると、エージェントはそれを実行すべきタスクとして扱ってしまうことがあります。

信頼できないコンテンツのよくある発生源:

• issue / PR / コメント（GitHub上で外部の人が書いたもの）。
• エージェントが取得するwebページ—「このURLのドキュメントを読んで」と頼んだとき。
• MCPサーバーやサードパーティツールからの出力。
• クローンしたばかりでまだ読んでいないリポジトリ内のファイル。

4つの対策原則、小難しい理論は不要です。

1. 外部入力を扱うときは自動承認しない。エージェントがissue/webページ/MCP出力を読み始めた瞬間に、一つひとつ確認する方式へ戻しましょう—acceptEdits/bypassを動かしたままにしないこと。
2. 見慣れないソースにはplanモードを使う。エージェントには読ませて提案させつつ、あなたが承認するまで実行はブロックします。
3. 隔離する。ベストプラクティス2と同様に、信頼できないデータはシークレットのないサンドボックスで扱いましょう。
4. 「丁寧なコマンド」に警戒する。ある出力が突然、コマンドの実行、パッケージのインストール、見慣れないファイルの読み取りを「提案」してきたら—手を止めてよく読みましょう。それは典型的なインジェクションの兆候です。

Anthropicのセキュリティドキュメントには、プロンプトインジェクションへの防御に特化したセクションがあります。一般原則は、自分で制御できないデータに触れるときは、エージェントを可能な限り最小権限のモードに保つことです。

autoモードには独自のインジェクション防御がある。2026年8月時点で、autoモードはPro/Max/Teamプランで既定の開始モードとなっています—これにより、今や一部の特殊なケースにとどまらず、ほとんどの読者に直接関係する話になっています。仕組みはこうです。autoモードで行動をレビューする分類器は、あなたのメッセージ、ツール呼び出し、CLAUDE.mdだけを読み—ツールの結果は決して読みません。別のサーバー側レイヤーが、Claudeが読み取る前にツールの結果を敵対的なコンテンツがないかスキャンします。これは部分的な防御であって、絶対的な保証ではありません—autoモードを、上記4つの対策原則を省略してよい理由と考えてはいけません。

ベストプラクティス4 - AIが生成したコードは必ずレビューする

譲れないルール: 人間の関与なしにAIのコードをマージしてはならない。コード生成の速さは「盲目的なマージ」に陥りやすくします—そして、最も多くの脆弱性が本番に到達するのはまさにそこです。

厄介な問題がAIスロップです。見た目は洗練され、変数名も美しく、コメントもあり、ハッピーパスでは動く—しかし入力検証を飛ばしていたり、SQLインジェクションの穴を残していたり、値をハードコードしていたり、セキュリティのエッジケースを取りこぼしていたりするコードです。「正しそうに見える」ので、急いでいるレビュアーの目をすり抜けます。それを見抜き回避する方法は、コードレビューでAIスロップを避けるを参照してください。

security-guidanceをオンにして、Claudeが書きながら自分のコードをチェックするようにしましょう。これは自動的に動くネイティブプラグインで、あなたが呼び出しを覚えておく必要はありません。3つのレイヤーが自ら起動します—(1) Claudeがファイルを編集するたびに即座のパターンマッチング（モデル呼び出しなし、無料、eval(、os.system、dangerouslySetInnerHTMLのような明確なパターンを捕捉）。(2) 既定でOpus 4.7によるターン終了時のバックグラウンドレビュー。(3) commit/push時の、関連する呼び出し元やサニタイザーも読むより深いエージェント的レビュー。/plugin install security-guidance@claude-plugins-officialでインストールし、.claude/claude-security-guidance.mdと.claude/security-patterns.yamlで独自のルールをカスタマイズできます。これは書き込みやコミットをブロックしません—見つけた指摘をClaudeが修正できるよう提示するだけです。/security-review（下の項目2）がオンデマンドの一回きりのスキャンであるのに対し、security-guidanceはセッション中ずっとバックグラウンドで動く継続的なレイヤーです。無料のマルチエージェント深層スキャンについては、当社のセキュリティ監査記事のclaude-securityプラグインをご覧ください。

実践的なレビューのワークフロー:

1. 説明ではなく差分を読む。エージェントが「検証を追加した」と言っても、正しくできているとは限りません。差分で確認しましょう。
2. /security-reviewを実行する—Claude Code組み込みのセキュリティレビューコマンド—手作業でレビューする前に、よくある脆弱性（インジェクション、ハードコードされたシークレット、認証の欠落）を素早くスキャンします。
3. 機密性の高い領域を優先する: 認証、認可、ユーザー入力の処理、DBクエリ、シェルコマンド、ファイル操作。
4. テストとlinter/SASTを実行する—他のPRと同じように。AIだからといってCIが免除されるわけではありません。

より厳密さが求められるプロジェクトでは、その都度ではなくスケジュールで動く完全なClaude Code向けセキュリティ監査ワークフローを用意しましょう。

ベストプラクティス5 - MCPサーバーやプラグインを精査し、hookをガードレールとして使う

有効にするMCPサーバーやプラグインはすべて、エージェントの権限で動くサードパーティのコードです。「便利」だが悪意あるサーバーは、あなたに気づかれずにファイルを読み、ネットワーク通信を行い、データを流出させられます。原則はこうです。

• 信頼できるサーバーだけを有効にする—読めるソースが公開されている公式のものを優先。
• あまり知られていないサーバーはインストール前にソースを読む—特に広範なネットワークやファイルアクセスを持つものは。
• MCPにも最小権限をBashと同じように—実際に必要な範囲だけを付与する。

精査する前にMCPの仕組みを理解するには、MCPとは何か、どう動くのかを読んでください。

最後の砦としてのPreToolUsehook。これは活用されていないが非常に強力なレイヤーです。このhookはエージェントがツールを実行する前に動き、実行を完全にブロックできます。たとえば、危険なコマンドパターンをブロックする例です。

#!/usr/bin/env bash
# .claude/hooks/pre-tool-use-guard.sh
# Read the JSON payload from stdin, block dangerous commands
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command // ""')

if echo "$cmd" | grep -Eq 'rm -rf|curl .*\| *(ba)?sh|:\(\)\{|dd if='; then
 echo "Blocked: dangerous command rejected by guardrail." >&2
 exit 2 # a non-zero exit code => Claude Code cancels the action
fi
exit 0

このhookをsettings.jsonでPreToolUseイベントに登録します。denyだけに頼るのに対する利点は、hookが動的なロジック（正規表現、変数チェック、ログ記録）を可能にし、うっかり緩いモードを有効にしてしまっても安全網になることです。

AIコーディングセキュリティのチェックリスト（今すぐコピーして使う）

すべてのベストプラクティスを実行可能なリストにまとめました。印刷するか、プロジェクトのREADMEに貼り付けてください。

1. [ ] シークレット: .envを.gitignoreに入れ、シークレットマネージャーを使い、リポジトリに平文のキーを置かない。
2. [ ] 読み取り拒否: permissions.denyが.env、*.pem、*.key、およびシークレット用ディレクトリのRead()をブロックする。
3. [ ] スキャン: gitleaks（または同等品）がpre-commitとCIで動く。
4. [ ] ローテーション: キーが漏洩したときに失効+再発行するランブックが存在する。
5. [ ] 権限: settings.jsonが最小権限（allow/ask/deny）に従い、サンドボックス外ではbypassPermissionsを使わない。
6. [ ] サンドボックス: リスクのあるタスクは、本番の認証情報を持たないDocker/devcontainerで動かす。
7. [ ] プロンプトインジェクション: issue、web取得、MCP出力を扱うときはplan/askモードに切り替える。
8. [ ] レビュー: マージ前に差分を読む + /security-reviewを実行 + CI/SAST、決して盲目的にマージしない。
9. [ ] MCP/プラグイン: ソースを読んだ信頼できるサーバーだけを有効にし、最小限の範囲を付与する。
10. [ ] hook: PreToolUseガードレールが破壊的なコマンドをブロックする。
11. [ ] 自動レビュー: security-guidanceプラグインがオンで、Claudeがファイルを編集するたびに自動でレビューする。
12. [ ] サンドボックス: Dockerより軽い隔離が必要なタスクには/sandboxをオンにする。

本当の限界と、AIに任せてはいけないとき

正直に言えば、上記のガードレールはすべてリスクを減らすものであって、消し去るものではありません。はっきり述べておくべき限界がいくつかあります。

AIは人間による脅威モデリングの代わりにはならない。AIはあなたのビジネス文脈も、データがどれほど機密かも、漏洩の法的な影響も理解しません。「これは自動化しても安全か」という判断は、依然としてあなたのものです。

エージェントに本番や本物のシークレットを触らせない。エージェントを本番データベースに接続しない、インフラへの書き込み権限を持つ認証情報を与えない、自由にデプロイさせない。ここでのミスは取り返しがつきません。

承認疲れは現実のリスク。権限の確認が頻繁に出すぎると、人は反射的に「許可」を押し始めます—せっかく設けた防御そのものを台無しにしてしまうのです。対策は、本当に安全な操作についてallowを調整し、確認が本当に検討すべきものだけに現れるようにすること。うるさいからといって全部オフにするのではありません。

要するに、AIを使って速く動きつつ、取り返しのつかない判断は人間の手に残しておくことです。ガードレールは自信を持って速く動けるために存在するのであって、考えるのをやめるためにあるのではありません。

既製キットでセキュリティを標準化する

プロジェクトごとにPreToolUsehook、settings.jsonテンプレート、レビュースキルをすべて一から書くのは面倒です—特にチーム全体を同じ標準に揃えたいときは。時短になるのが、Claude Code向けのセキュリティレビュースキルとガードレールワークフローをまとめた既製キットです。Claude Code向けAgentKitキットは、一連のレビュー/ワークフロースキルを同梱しているので、ゼロから作り直す必要はありません。自分に合うか確かめたいなら、AgentKitの価格を確認（リンク経由で20%オフ）できます（Engineer Kitは$99、サイトには継続課金の記載はなく、生涯アップデート付き）。それでも、自分のプロジェクトに合わせて読み、適応させるべきです—どんなキットも、自分自身の脅威モデルを理解することの代わりにはなりません。

よくある質問（FAQ）

AIコーディングは実際のプロジェクトで安全に使えますか?

はい、正しいガードレールを構築すればです。シークレットを手の届かない場所に置き、最小権限を徹底し、サンドボックスで実行し、マージ前にすべてのコードをレビューする。リスクは広すぎる権限と信頼できない入力から来るのであって、AIを使うこと自体からではありません。ガードレールがなければリスクは高く、あればコントロール可能です。

Claude Codeは私のコードをどこかに送信しますか?

Claude Codeは処理のために必要なコンテキストをAnthropicのAPIに送信します—それがその仕組みです。露出を抑えるには、permissions.denyで機密ファイルの読み取りをブロックし、Anthropicのドキュメントでデータ保持ポリシーを確認し、極めて機密性の高いコードは専用の環境に隔離しましょう。

エージェント経由でAPIキーが漏れるのをどう防げばよいですか?

3つのレイヤーです。(1) リポジトリに平文のキーを置かず、シークレットマネージャーを使う。(2) permissions.denyで.envやキーファイルのRead()をブロックする。(3) gitleaksをpre-commitとCIに入れ、シークレットを含むコミットをブロックする。もし漏れてしまったら、すぐに失効させてローテーションする—コミットを削除するだけでは不十分です。

bypassPermissionsは有効にすべきですか?

本物の作業マシンでは、ほぼ絶対に使ってはいけません。bypassPermissionsと--dangerously-skip-permissionsはすべての承認レイヤーを取り除きます—シークレットも本番アクセスもない隔離されたサンドボックスでのみ使ってください。日常の作業ではdefaultのまま。全部オフにするのではなく、allowを調整して確認を減らしましょう。

AIのコードにはどれくらいレビューすれば十分ですか?

エージェントの説明を信じるのではなく差分を読み、/security-reviewを実行し、他のPRと同じようにCI/SASTとテストを走らせ、機密性の高い領域（認証、入力、DB、シェル）を精査しましょう。AIスロップに気をつけてください—正しそうに見えるのに検証を飛ばしていたり、セキュリティのエッジケースを取り違えていたりするコードです。

AIコーディングは顧客（NDA）のプロジェクトで使っても大丈夫ですか?

契約が許可していて、かつ厳格に隔離する場合に限ります。顧客ごとに別々のワークスペースを用意し、別の顧客のコードを含むディレクトリの上でエージェントを決して開かず、本物の認証情報を範囲に入れず、始める前にサードパーティサービスへのデータ送信に関するNDAの条項を確認しましょう。

autoモードは単独でプロンプトインジェクションを防いでくれますか?

部分的には、です。autoモードで行動をレビューする分類器は、あなたのメッセージ、ツール呼び出し、CLAUDE.mdだけを読み—ツールの結果は決して読みません。別のサーバー側レイヤーが、Claudeが読み取る前にツールの結果を敵対的なコンテンツがないかスキャンします。これは部分的な防御であって、絶対的な保証ではありません—信頼できないコンテンツを扱うときは、4つの対策原則（見慣れない入力での自動承認をしない、planモードを使う、隔離する、「丁寧なコマンド」に警戒する）を依然として適用すべきです。

まとめと次のステップ

AIコーディングのセキュリティは、オン/オフで切り替える機能ではありません—それは6層のガードレールです。シークレット、権限、サンドボックス、プロンプトインジェクションの遮断、コードレビュー、そしてMCP + hookの精査。まずROIの最も高い2つのレイヤー—シークレット用のpermissions.denyと最小権限のsettings.json—から始め、残りは時間をかけて足していきましょう。上のチェックリストをプロジェクトのREADMEに貼り付けて、チーム全体が一つの標準に従うようにしてください。

次に読む: 権限を安全に設定すると完全なセキュリティ監査。チーム全体向けの既製セキュリティスキルセットが欲しいなら、AgentKitを試す（リンク経由で20%オフ）こともできます—ただし、必ず自分自身の脅威モデルに合わせて読み、適応させてください。