AIエージェントにコードを書かせ、実行までさせる働き方が当たり前になってきました。そこで避けて通れないのが、「APIキーのような秘密情報を、AIにどう渡すか」という問題です。本記事は、筆者が自分の作業環境でこの問題に向き合い、Bitwarden Secrets Managerというシークレット管理サービスを導入するまでの実践記録です。
先にお断りしておくと、シークレット管理サービスにはBitwarden以外にも有力な選択肢が複数あります。1Password Secrets Automation、Doppler、HashiCorp Vault、AWS Secrets Managerなどが代表格で、それぞれに得意分野があります。本記事は各サービスを比較検討した上での推薦記事ではなく、「今回はBitwarden Secrets Managerを使ってみた」という一人の実践者の記録として読んでいただければと思います。
.envファイルは悪ではない
まず強調しておきたいのは、多くの開発現場で使われている.envファイル（APIキーなどの設定値を書いておくテキストファイル）は、決して「悪い方法」ではないということです。ローカルでの開発、個人プロジェクト、少人数のチームなど、多くの場面で.envファイルは十分に実用的です。導入の手間がほぼゼロで、ほとんどの開発ツールが対応しており、仕組みが単純で誰にでも理解できる。これらは立派な長所です。
一方で、.envファイルには構造的な弱点が二つあります。一つは、秘密情報が平文（暗号化されていないそのままの文字列）でディスクに保存されること。ファイルを開けば誰でも中身を読めますし、パソコンごと盗まれれば秘密も一緒に漏れます。もう一つは、Gitへの誤コミット事故です。バージョン管理から除外する設定（.gitignore）を忘れたまま公開リポジトリにアップロードしてしまい、APIキーが世界中に公開される――この種の事故は、残念ながら今も後を絶ちません。
シークレット管理サービスが効いてくる場面
では、シークレット管理サービスは何を解決してくれるのか。.envファイルと比べて優位になるのは、主に次の観点です。
- 平文でディスクに残らない ― 秘密情報は暗号化された保管庫に置かれ、プログラムの実行時にだけ環境変数として展開される。実行が終われば手元には何も残らない
- アクセス制御と監査ログ ― チームやプロジェクト単位で「誰がどの秘密情報にアクセスできるか」を管理でき、アクセスの記録も残る
- ローテーション（定期的な交換）のしやすさ ― キーを交換するとき、保管庫の値を書き換えるだけでよく、コードや設定ファイルの変更が不要
- 誤コミット事故のリスク低減 ― そもそも秘密情報を書いたファイルが手元に存在しないので、間違えてアップロードしようがない
そして今回、筆者にとって決め手になったのがもう一つの観点です。AIエージェントと一緒に作業をするとき、AIにキーの値そのものを見せずに済むということです。AIエージェントは便利ですが、会話に貼り付けた情報は処理のためにサービス提供者のサーバーへ送られます。APIキーを会話に直接貼るのは、避けられるなら避けたい。シークレット管理サービスを使えば、「AIには使わせるが、見せはしない」という分離が実現できます。
導入の流れ ― 全体像
実際の導入は、大まかに次の5ステップで進みました。
ステップ1：シークレットの登録。BitwardenのWeb画面（Web Vault）でSecrets Manager用のプロジェクトを作り、APIキーを登録します。名前（例：OPENAI_API_KEY）と値のペアで保存する、というシンプルな作りです。ここで大事なのは、この登録作業を自分の手で、ブラウザ上で直接行うことです。AIエージェントとの会話にキーを貼り付けて「登録しておいて」と頼んでしまっては、本末転倒です。
ステップ2：CLIの導入。コマンドラインから保管庫にアクセスするための公式ツール「bws」をインストールします。Macならパッケージ管理ツール経由で数分で終わります。
ステップ3：アクセストークンの設定。bwsが保管庫にアクセスするための認証情報（アクセストークン）を発行し、自分のシェル環境の環境変数に設定します。ここも自分の手で行い、トークンの値をAIに渡さないようにします。
ステップ4：bws runでシークレットを注入。ここがこの仕組みの核心です。bws run -- python3 script.pyのように実行すると、bwsが保管庫からシークレットを取り出し、そのプログラムの実行中だけ環境変数として渡してくれます。プログラム側は「環境変数からキーを読む」という普通の書き方のままでよく、.envファイルは不要になります。
ステップ5：動作確認。実際にAPIを呼び出すスクリプトを動かし、キーがプロセスにだけ渡っていること、ディスク上のどこにも平文で残っていないことを確認して完了です。筆者の場合、AIエージェントにスクリプトの作成と実行を任せましたが、AIが行うのは「bws run経由で実行する」ことだけなので、キーの値は最後までAIの目に触れませんでした。
追加の安全対策 ― 「見せない」から「見えない」へ
運用を始めてすぐ、一つの論点に気づきました。bwsには、登録したシークレットの値を画面に表示できるコマンドも用意されています。管理用としては当然の機能ですが、AIエージェントが作業の途中で「確認のため」にこの種のコマンドを実行すれば、値が出力としてAIに渡ってしまいます。
そこで、AIエージェント側の設定で、値が表示されうるコマンドを明示的に禁止しました。実際、この記事のためのフロー図をAIに生成させた際、AIは登録済みシークレットの一覧を確認しようとしてコマンドを実行し、設定によって拒否されています。人間が注意し続けるのではなく、仕組みとして「見えない」状態を作る。この防御的な設定は、手間の割に効果が大きいと感じています。
気づき ― 保管場所そのものの安全性
今回の作業でもう一つ、重要な気づきがありました。それは、秘密情報の「置き場所」を一段ずらしただけでは、問題は解決しないということです。
ステップ3で設定したアクセストークンは、保管庫全体への入口の鍵です。もしこのトークンをシェルの設定ファイルに平文で書いてしまえば、「平文でディスクに残る」という.envファイルと同じ弱点を、より重要な鍵について抱え込むことになります。せっかく保管庫を導入しても、その鍵を玄関マットの下に置いていては意味がありません。トークン自体の保管には、OSのキーチェーンを使う、セッションごとに手動で設定する、といった一段上の注意が必要です。
シークレット管理は「導入したら終わり」ではなく、「秘密の連鎖のどこが一番弱いか」を考え続ける営みだ、というのが今回の率直な学びです。
まとめ ― 使い分けの指針
最後に、.envファイルとシークレット管理サービスの使い分けを整理します。
- .envファイルで十分な場面 ― 個人のローカル開発、試験的なプロジェクト、秘密情報の数が少なく共有相手もいない場合
- シークレット管理サービスを検討すべき場面 ― チームで秘密情報を共有する場合、キーの定期交換が求められる場合、誤コミット事故を仕組みで防ぎたい場合、そしてAIエージェントに実行を任せつつキーは見せたくない場合
AIに作業を任せる範囲が広がるほど、「AIに何を見せて、何を見せないか」の線引きは重要になります。その線を人間の注意力ではなく仕組みで引く手段として、シークレット管理サービスは有力な選択肢です。まずは個人の作業環境という小さな範囲から試してみることをお勧めします。
DSB Consultingでは、AI活用を前提としたセキュリティ・ガバナンス体制づくりを支援しています。AIエージェント導入時の情報管理について相談したい方は無料相談をご利用ください。