Claude Code のような AI エージェントに本格的に作業を任せようとすると、AWS の操作、外部 API への呼び出し、決済処理など、認証情報を渡す場面が増えてきます。
ただし、AI に認証情報をそのまま読める状態で渡すのは危険です。bash 経由で外に出されたり、ログに残ったり、indirect prompt injection で使えと命令されたりすれば、秘密値はあっさり漏れます。
そこで、AI には認証情報そのものを渡さず、必要な操作だけを実行させる仕組みを作れないかと考え始めました。設計の選択肢を整理すると、AI への認証情報の渡し方は大きく4段階に分かれます。
①は AI 自身が .env を読む状態で、漏洩リスクが最大。④は IAM role や Bedrock のように、AI が秘密値を一度も見ず SDK が裏で認証を処理する形です。多くの個人開発者にとっての現実解は ② と ③ で、組織で AI を本格導入するなら ③ か ④ を目指すことになります。
この記事では、③ に該当する 1Password を AI エージェント用の認証情報受け渡しに使ってみた経緯を書きます。結論から書くと、用途を区切れば現在も使っているし、無人化したい段階になると壁にぶつかる、という話です。
1Password が候補として有望に見える理由
最初に思いついたのが 1Password でした。理由は単純で、
- 個人〜小規模で secret 集中管理といえば定番のツール
- CLI (
op) が成熟していて、op run -- <command>で env に注入してサブプロセスを起動できる。秘密値はプロセス環境にしか存在せず、shell 履歴にも残らない - Secret References (
op://Vault/Item/field) で.envを「キー=参照」に置き換えられる。git に乗せても安全 - 1Password アプリ連携を有効にしておけば、
op run実行時に必要に応じて Touch ID プロンプトが走り、UX が良い
実際のワークフローはこの1行で済みます。
op run --no-masking --env-file=.env.tpl -- claude
.env.tpl の中身は、値ではなく参照だけを並べます。
AWS_ACCESS_KEY_ID=op://Private/AWS/access_key_id AWS_SECRET_ACCESS_KEY=op://Private/AWS/secret_access_key
※ここのキーは、一例です。実際に渡したかったのは、これではありません。
op run の実行時に Secret References が解決され、env として claude に渡されます。
4段階モデルでいうと ③ にあたる構成です。秘密値は 1Password vault という暗号化ストアに集約されていて、Touch ID 認証を経て AI エージェントの env に注入される。AI は env で値を見ますが、vault 自体には触れません。② の「平文の .env をホストに置く」よりも、認証・監査・ローテの面で大きく前進しています。
ただし注意点として、env 注入された値は claude とその子プロセスにも環境変数として継承されます。さらに /proc/PID/environ 経由で読める、プロセスダンプや ps 出力・各種ログに混入する、といった漏洩経路もあります。AI 本体に秘匿値を渡す設計であることに変わりはないので、.env.tpl には必要最小限のキーだけを書くのが望ましいです。また、渡すキーの有効期限は短くすべきです。完全にAI が値を見ない状態にしたいなら ④ まで進める必要があります。
1Passwordで十分な利用シーン：短時間・有人タスク
ここまで最初に思いついたと書きましたが、この後も用途に応じて 1Password と op を使い続けてる想定です。
たとえば、週1回の Google Analytics データ取り込みのようなケースです。GA4 API 用の認証情報を 1Password に格納し、op run -- python ga_import.py の形で env 注入して、数分で完了します。
なぜこの用途では問題にならないのか整理すると、
- 起動を人が見届けている。
op run起動時の Touch ID プロンプトに答えられる - 扱う認証情報が静的な API key 中心。タスク途中で値が失効する心配がない
- 頻度が週1回程度なので、毎回 Touch ID で認証するコストが許容範囲。むしろ「明示的に認証する儀式」がアクセス制御として機能している側面がある
- 完全自律で AI に任せている訳ではなく、人が起動 → スクリプトが走る → 完了を確認、というサイクル
つまり、broker の機能（認証で守られた vault からの env 注入）は使いつつ、無人での長時間自律は諦めている形です。1Password の制約と、タスクの性質が整合しているので現役で使えています。
1Password を捨てた話でも、AI 用途では使えないと結論した話でもありません。用途が合えば手頃で便利、という話です。
無人バッチと短命トークンで当たる壁
問題は、もう一段階自動化を進めようとしたときに出てきます。AI に席を外して数時間の作業を任せたい、あるいは GA 取り込みを cron や AWS Lambda で日次・週次の自動化に切り替えたい、といった場面です。
ここで重要な前提として、op run による env 注入は起動時に1回だけ走ります。注入された値は claude プロセスのライフタイム中ずっと env として有効で、途中で 1Password に再アクセスする必要はありません。なので「30 分のセッション制約があるから長時間タスクで止まる」という話ではない、というのを最初に整理しておきます。
壁が立つのは別の2つの場面です。
- 無人バッチの場合: そもそも起動時刻に人がいません。cron で深夜に走らせても、Touch ID を押せる人がいないので op run の認証が通らない。タスク自体は数分で終わるのに、認証の入口で詰まる
- 短命トークンを長時間タスクで使う場合: AWS STS のような短命クレデンシャルを op run で注入しても、有効なのは注入された時点のスナップショット。タスクが途中でトークン期限切れになると、子プロセスはリフレッシュできないので止まる
永続的な API key（Anthropic API key、Stripe、GitHub PAT 等）だけを扱うなら、有人起動さえできれば op run は長時間タスクでも問題なく回ります。30 分制約が問題になるのは op を再実行するとき、たとえばプロセス内で動的に他の secret を取りに行く設計や、別プロセスが op を呼ぶ設計の場合です。すでに env 注入が済んだ claude プロセス自体には関係しません。
私自身が壁を経験したのは2つ目で、別件で AWS の短命クレデンシャルを使った時に、実行中にトークンが期限切れになって作業が止まりました。op run は永続キーの broker としては筋が良いけれど、「短命トークンを実行中にリフレッシュする」用途には別の仕組みが必要です。
今後目指す方向性
無人運用に進めるなら、選択肢は2つあります。
無人起動の問題には、1Password の Service Account に切り替える方法があります。Service Account はトークンベース認証のため、Touch ID のような対話的な認証を介さずに起動でき、cron や CI で動かす用途には適しています。一方で、Service Account は人間ユーザーとは別の認証体系で動作し、通常の Personal vault や Shared vault とは切り離された運用になります。そのため、「人間用」と「機械用」のシークレットを分離し、専用の vault 構成を設計し直す必要があります。また、利用にはプランの制約や rate limit があり、実運用ではビジネス向けプランを前提とした設計になるケースが多く、導入時にはそれなりの設計コストおよび利用料がかかります。
短命トークンのリフレッシュ問題は、env 注入を前提とした設計では本質的に解けません。op run は起動時に解決された値を env に渡すだけであり、aws-vault exec も基本的には同様に、その時点のクレデンシャルをプロセスに引き渡す形になります。いずれの場合も、プロセス内部にクレデンシャルの更新ロジックがなければ、実行中に期限切れが発生した時点で処理は停止します。
本質的な解決は、プロセス自身がクレデンシャル更新の仕組みを内側に持つことです。AWS なら IAM role や instance profile を AWS SDK が直接参照し、credential provider chain が裏でリフレッシュを回す形にする。env で短命トークンを渡し回す設計から脱却できます。AI モデル本体を Bedrock 経由で呼べば Anthropic API key 自体も不要になり、4段階モデルでいう ④ に到達します。AWS をすでに業務でも個人でも使い倒している人なら、この経路への切り替えコストは比較的小さく済みます。
私自身は AWS 寄りの判断をしがちな自覚があるので、後者を本命に置いています。最終的には、長期クレデンシャルをAIに渡すのではなく、IAM RoleやOIDCなどを使い、AIプロセス自体が一時クレデンシャルを取得する構成に寄せるのが望ましいと考えています。必要に応じて、Secrets Managerなどのストアを組み合わせて運用する形になります。
いま現在、見えている課題の整理
ここまでの試行錯誤で、幾つかの課題と設計パターンが見えてきました。
ひとつめ。broker を評価するときは人が起動を見届けるかと扱うクレデンシャルの寿命をセットで見ること。このツールは AI 用途で使える / 使えないという二分法は粗すぎます。有人起動 × 永続 API key、なら op run は長時間タスクでも快適に回ります。一方で「無人で起動する必要がある」「短命トークンを実行中にリフレッシュする必要がある」のいずれかが要件に入ってくると、op run 単体では不足で、別の経路を検討する必要があります。
ふたつめ。業界定番だからという理由で AI エージェント用ツールを選ばないこと。1Password も aws-vault 或いはHashiCorp Vaultも、人間の シークレット管理では定番です。けれど「AI エージェントに無人で使わせる broker」という別問題に転用すると、評価軸が変わります。①自動リフレッシュの可否、②構築・運用コスト、③ユースケースとの整合、の3軸で見るのが筋。①はプランや使い方で挙動が変わるので、想定タスクの実行時間と無人度を先に決めて評価すると判断を間違えにくい。
みっつめ。4段階モデルで自分の現在地を確認し、次の一歩を選ぶ。① にいるなら ② へ、② にいるなら ③ へ、③ で運用しつつ自動化要件が出たら ④ を検討する、という段階的な進化が自然です。いきなり ④ に飛ぶ必要はないし、過渡期の混在は妥当な選択です。
最後に、broker だけで安全は完成しないことも書いておきます。AI ができる操作の範囲は、Claude Code の settings.json の allow / deny、hook、sandbox / container といったパーミッション側で別途設計する必要があります。broker は「クレデンシャルの渡し方」の話、permission は「AI ができる操作の範囲」の話。両方をペアで設計しないと穴が残ります。
自分の用途（タスクの長さ × 無人度 × 規模）に当てはめて、判断軸を選んでみてください。これは単なるツール選定の話ではなく、どこまでの権限をAIに委譲するのかという設計判断そのものでもあります。最近は、ずっとそのことを考えています。
