NEWS

ニュース

2026.06.03 技術ブログ

SOPS で AI エージェントのシークレット管理 — Claude Code に「平文を見せない」3つのガードレール

Claude Code などの AI エージェントを本格運用するとき、「シークレットをどこにどう置くか」 は避けて通れない設計判断です。Git リポジトリに暗号化したまま秘匿情報を保存できる SOPS（現 CNCF Sandbox プロジェクト）は GitOps と相性がよく、小〜中規模チームや個人開発での有力な選択肢です。

ただし、シェルやファイル操作の権限を持つ AI エージェントと組み合わせる場合、「AI が自分で復号して中身を覗き見・漏洩させない」 ためのガードレール設計が前提になります。本記事では SOPS のメリットと AI エージェント特有のリスク、そして推奨構成をまとめます。

SOPS を AI エージェント運用で使うメリット

SOPS は YAML / JSON の 値だけを暗号化し、キー（変数名）は平文で残す 設計です。これは「設定の存在は知らせるが値は見せない」という AI エージェント運用と非常に親和性が高い構造です。AWS KMS・GCP KMS・Azure Key Vault・age・PGP など、環境に合わせたバックエンドを選べる柔軟さも魅力です。

AI エージェント特有の3つのリスクとガードレール

① 平文をコンテキストに載せない

エージェントに sops -d secrets.enc.yaml を実行させると、復号結果がエージェントの会話ログやツール出力に平文として取り込まれるリスクがあります。「一度でも平文がコンテキストに乗ったらアウト」という前提で設計するのが安全です。

対策: ランタイム（実行環境）側で sops exec-env を使い環境変数として注入します。AI エージェント自身には復号コマンドを実行させません。

# secrets.enc.yaml の中身を環境変数化してアプリを起動
sops exec-env secrets.enc.yaml 'npm run dev'

さらに .claude/settings.json で以下の deny ルールを設定し、AI が .env や復号済みファイルに触れられないようにします。

{
  "permissions": {
    "deny": [
      "Bash(sops:*)",
      "Bash(env)",
      "Bash(printenv:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(~/.config/sops/**)"
    ]
  }
}

sops の禁止だけでなく env / printenv も塞ぐのがポイントです。

② 平文をコミットさせない

AI が「復号 → 編集 → 保存」という素朴な手順を踏むと、暗号化されていない平文が Git にコミットされる事故につながります。

対策: gitleaks や detect-secrets などの pre-commit hook を仕込み、平文の秘密情報が含まれていないか機械的にチェックします。SOPS ファイルの編集は人間が sops <ファイル名> で行うルールにし、AI には「設定ファイルにどんなキーがあるか」だけを教える運用にします。

③ 復号鍵をエージェント環境に置かない

最も深刻なリスクは、復号鍵そのものが AI エージェントの実行環境に置かれているケースです。KMS の権限や age の秘密鍵がエージェントから到達可能な場所にあると、プロンプトインジェクションを食らった瞬間、AI が自ら鍵を使ってすべての秘匿情報を復号・外部送信することが原理的に可能になります。

対策: プロダクション環境の復号鍵は CI/CD パイプラインや特定のセキュアな実行環境のみに限定します。開発中の AI エージェントには開発環境用の最小権限の鍵だけを与えます。

「AI に env を渡す」の正しい意味

「AI に env を渡す」という言葉には混ざりやすい2軸があります。

軸	やること	env の値が必要か
A. AI がコードを書く・読む	ソース編集、設定ファイル編集	不要。変数名だけ知っていればよい
B. AI が動作確認する	アプリ起動、curl テスト	env が必要なのはアプリ本体。AI 自身は不要

正しい分離パターンは、ターミナル A（アプリ用・env あり）とターミナル B（AI 用・env なし）を分けることです。AI はアプリの公開インターフェース（HTTP API・CLI 出力・ログ）経由で動作確認し、env の値そのものは知らなくてよい設計が理想です。

どうしても AI に env を渡す必要がある場合は、「漏れても被害が限定的な値（dev 用最小権限値）」だけを L3 として渡す 3 段階レイヤー設計で管理します。

まとめ

SOPS は「秘密情報を Git で安全に持ち運ぶ」目的で非常に有効なツールですが、「SOPS を入れた = 安全」ではありません。Claude Code のような強力な AI エージェントと組み合わせるなら、以下の3つのガードレールを必ず併用してください。

平文をコンテキストに載せない — sops exec-env でランタイム注入、permissions.deny でアクセス禁止
平文をコミットさせない — pre-commit hook で機械的にチェック
復号鍵をエージェント環境に置かない — プロダクション鍵は CI/CD 専用、開発鍵は最小権限

「SOPS + AI エージェント向けの権限分離 = 安全」という発想が、これからのシークレット管理の最低ラインです。

一覧へ戻る