AI エージェント用のシークレットを 1password で管理する方法
こんにちは。Rimo CTO の山田です。
今回は、社内でAIエージェントの活用を進めていく中でシークレット管理の問題にぶつかったのでその話を書こうと思います。
社員に適切なツール権限を与え、それをAI エージェントに安全に渡す方法
社内でAI活用を進めるうえで、最近かなり重要になってきたのが「AI エージェントにどのように権限を渡すか」という問題です。
たとえば Claude Code のような AIエージェントを社員に使ってもらうと、単なるコード生成や調査にとどまらず、
Slack を操作する
各種SaaSのAPIを叩く
社内ツールをCLI経由で操作する
のようにツールと連携して使いたくなります。
そこで問題になるのが、ツールの認証情報をどう扱うかです。
認証情報を扱う上での課題
AI エージェントにツールの権限を渡す際には、主に以下の3つの観点で問題が出てきます。
1. セキュリティ（シークレットの扱い）
.env やローカルファイルにシークレットを置くと、Gitへの誤コミットやプロンプトインジェクションによる漏洩リスクがある
ファイルやログを通じて意図せずシークレットが公開される可能性がある
そのため、ファイルに残さず、実行時にのみ利用する設計により、よりリスクを低減できます
2. リスク（権限の強さ）
一部のツールは API KEY 1つで広範な操作が可能
例：freee や CloudSign など
データ更新・削除・送信などが可能なため、誤操作やプロンプトインジェクション時の影響が大きい
エージェントを利用する社員のリテラシーや技術力に合わせて、どこまでの権限を付与するかを決めるといった運用が必要
3. 認証（実行環境の制約）
Remote 環境（例：claude.ai）では人間のログイン操作が使えない
ローカルの認証状態も共有できない
そのため、API KEY やトークンベースの認証に寄せた設計が必要になる
この3点を踏まえた上で、AI エージェントに認証情報をどう渡すかを設計する必要があります。
MCPだけでは足りない
Claude Code には公式のコネクタ(MCP)の仕組みがあり、OAuth ベースでの認証が組み込まれている場合はそれがセキュリティ的にもベストです。
ただ、MCPでは足りない場面がけっこう出てきます。
MCPが用意されていないツールを使いたい
APIを直接叩きたい
SKILLとして既存CLIを呼びたい
ここで必要になるのが、API KEYやトークンをAIエージェントに渡すという作業です。
対象とする2つの実行環境
扱うのは以下の2パターン。
1. Local 環境
Claude Code / CoWork をローカルで動かす
手元の環境で自由にCLIが使える
2. Remote 環境
claude.ai 上で Claude Code を動かす
環境変数を登録して実行する形式
この2つを同じ思想で扱えるようにしたい、というのが今回のテーマです。
基本方針: シークレットは外に置いて、実行時に注入する
設計のコアはシンプルです。
シークレットはファイルに書かない
Secret Manager（今回は1Password）に集約する
実行時にだけ1passwordから渡す
これにより、
Gitへの誤コミット事故が減る
管理が1ヶ所に集まる
local / remote を同じ構成で管理できる
というメリットがあります。
今回はシークレットの管理ツールとして、 1Password を選択しました。
これは以下のような理由があります。
セキュリティに関しては実績と信頼のあるツールに利がある
権限管理の仕組みがある
非エンジニアが使う場合でも使いやすい
1Password の基本
1Password はパスワードやシークレットを安全に管理できるサービスで、ざっくり以下の単位で理解するとよいです。
保管庫（Vault）
シークレットを入れておく箱です。
アクセス権は基本的にこの保管庫単位で管理します。
アイテム（Item）
実際の中身です。
API KEY
パスワード
トークン
接続情報
などを1つのアイテムとして保存します。
権限管理
誰がどの保管庫を見られるかを制御します。
ここが重要で、どの社員がどの秘密情報にアクセスできるかを明確にできます。
Service Account（SA）
人間ではなく、AI エージェントやスクリプトが使うための仮想的なユーザーアカウントのようなものです。
実践例: OPENAI_API_KEY を渡す
ここからは OPENAI_API_KEY を例に話します。
検証に使った github の実際のコードはこちらで公開しています。
1password 側でシークレットを登録
ここでは、 yyamada-ai という保管庫を作成し、 OPENAI_API_KEY というアイテムを登録しています。
local 環境で参照
ローカルでは、Service Account は基本不要で、op signin で人間がそのまま認証します。
ここでは、 1password アプリを CLI と連携させて認証をしています。
実行イメージ
必要時に 1password から認証情報を取得する方法を SKILL にしており、
以下のように OpenAI の API 呼び出しを指示すると、SKILL 経由で 1password のシークレットに安全にアクセスされます。
1password では `op://<保管庫>/<アイテム>/<フィールド名>` のような文字列が、 op run コマンド実行時に実際のシークレット文字列に置換される仕組みになっています。
ref: https://developer.1password.com/docs/cli/secret-references
remote 環境での課題
一方、claude.ai 上の remote 環境では op signin ができません。
op signin ではインタラクティブな操作が必要なため、 remote 環境だとエラーになってしまいます。
ここで初めて Service Account（SA）の出番になります。
Service Account(SA) の位置づけ
Service Account を使えば、人間によるログイン不要で、op コマンドを実行できます。
ローカル、remote での棲み分けは以下の通りです。
ローカル → 人間のログインを使う（SA不要）
remote → 人間ログインができないのでSAで代替
remote 環境の組み立て
ステップ1: SAを作る
1Password で Service Account を作成。
ステップ2: SAに保管庫を紐づける
エージェントが触ってよいシークレットが入った保管庫を紐付けます。
ステップ3: SAトークンを環境変数に
claude.ai 側に Service Account の トークンを環境変数として登録します。
ステップ4: opコマンド経由でシークレットを取得
ここでもローカル環境と同様のSKILLで、 1password のシークレットを取得してもらっています。
セキュリティ設計
1. opコマンドの直接実行は塞ぐ
Claude Code の .claude/settings.json で
op の直接実行は禁止 (deny)
必要な処理だけ wrapper スクリプト経由で許可
という構成にします。
op item get コマンドなどシークレットの実際の文字列を直接出力するコマンドもあるため、 エージェントに直接任意の op コマンドを叩けるようにしてしまうと、プロンプト経由で任意のシークレットを閲覧・出力される余地が出てしまいます。
そこで、特定の op コマンド(op run など)だけを実行可能な shellscript を作ることで回避できます。
2. シークレットの取得は op run に寄せる
1password はシークレット管理に力を入れていて、op run コマンドを使うと実際のシークレットの内容がそのまま出力されないようになっています。
例えば、以下のように printenv した場合にも、 パスワードは表示されず、 <concealed by 1Password> という文字列が出力されます
export DB_PASSWORD="op://app-prod/db/password"
op run -- printenv DB_PASSWORDhttps://developer.1password.com/docs/cli/reference/commands/run/#examples
運用イメージ
基本
各社員は1Passwordアカウントを持つ
業務で使うシークレットは保管庫に入れる
エージェントはその保管庫の中身を使う
remote用
必要に応じてSAを作る
SAにアクセス権を与える
応用: Agentごとに権限を分けたい
ここまでの前提は、1つのエージェントに対して使ってよいツールの権限はまとめて渡す、というものでした。
ただ、場合によってはエージェントごとにアクセスできる権限を分けたいケースもあると思います。
そのような場合は、SAを複数作成し、それに合わせて保管庫も複数作ることを想定しています。
気をつけておきたい1password の制限
1. Service Account は最大100
1Password の制約として、 1つのアカウントで Service Account は100個までしか作れません。
https://developer.1password.com/docs/service-accounts
ここが最大の制約です。
今後 1password 側が制約を緩めてくれることに期待しています。
2. 権限管理は手動が多い
1Password では、SA 経由でユーザーのグループ管理をしたり、SA 経由で既存の保管庫の権限を管理したりするのは難しいです。
つまり「誰にアクセス権を与えるか」の権限管理は、基本的に 1Password 上での人手管理になり、権限管理自体をAIエージェントに任せることはできません。
まとめ
AI エージェントを本気で業務に入れると、「どう権限を渡すか」が問題になってきます。
今回の要点だけ並べると、
シークレットを1Passwordに集める
localでは人間の認証（op signin）を使う
remoteではService Account で代替する
AIエージェントによるopの実行コマンドは制限する
このへんを押さえておくと、実用と安全のバランスがとれた運用に落とせる、というのが今の自分の結論です。