はじめに
最近、AI エージェントへの秘密情報の渡し方が改めて話題になっています。.env を読ませないつもりでも、プロンプトインジェクションや不注意なコマンド実行によって、中身が漏れるケースが報告されています。
私は秘密情報を .env に常駐させる運用を、できるだけ避けるようにしています。その代わりに、Bitwarden CLI を使って必要なときだけ秘密情報へアクセスし、しかも Claude Code 側には期限付きで範囲を絞った token だけを渡す、という形にしています。
この記事では、その考え方と基本的な使い方、そして実際に使ってみた所感を紹介します。
検証環境
- OS: Windows 11
- ターミナル: Git Bash (Git for Windows v2.52.0)
- Bitwarden Secrets Manager CLI: 2.0.0
対象読者
- Claude Code などの AI エージェントに開発作業をさせている方
-
.envに長期の認証情報を置く運用に不安を感じている方 - Bitwarden を使っており、CLI で secret を扱う方法を知りたい方
- Windows + Git Bash 環境で
bwsを試したい方
なぜ .env を避けたいのか
.env は便利です。アプリの起動も簡単ですし、多くのツールが素直に読んでくれます。その一方で、いったんファイルとして置いてしまうと、読める場所にある限り、思わぬ経路で参照される余地が残ります。
Claude Code の公式ドキュメントにおいても利用者側に、信頼できない内容を直接流し込まないこと、承認するコマンドを確認すること、重要な変更を見直すことを求めています。つまり、ツール側の防御だけに期待するのではなく、そもそも長期シークレットを常駐させない設計が重要です。
Bitwarden CLI には 2 種類ある
Bitwarden CLI とひとことで言っても、実際には 2 系統あります。ここを最初に分けておくと話が分かりやすくなります。
ひとつは Password Manager CLI の bw です。
これは普段の Bitwarden vault を操作するための CLI です。bw login や bw unlock を使って vault を開き、bw get password や bw get notes で情報を取り出せます。
もうひとつは Secrets Manager CLI の bws です。
こちらは Secrets Manager 用です。machine account に対して access token を発行し、その token で project 単位の secret を取得したり、run でコマンド実行時だけ環境変数として注入したりできます。さらに access token には有効期限を設定できます。
今回、Claude Code と組み合わせる文脈でおすすめしたいのは bws です。理由は単純で、個人 vault 全体ではなく、machine account が読める範囲だけを Claude Code 側へ渡せるからです。
まずは全体像
長期シークレットを .env に置く運用と、Bitwarden Secrets Manager を使う運用の違いを、ざっくり図にすると次のようになります。
左側は、秘密情報そのものが先にローカルへ置かれる形です。右側は、まず Bitwarden 側で権限範囲を区切り、その上で期限付き token を使って必要なときだけ取り出す形です。Bitwarden Secrets Manager では machine account ごとに project への権限を付けられ、access token に有効期限も設定できます。
bw の基本的な使い方
先に bw の基本だけ触れておきます。Bitwarden の普段の vault を CLI から触るときの入口です。メールアドレスとマスターパスワードで bw login する場合、認証と同時に session key が発行されます。したがって、表示された値を BW_SESSION 環境変数へ設定すれば、そのまま bw get や bw list を使えます。別途 bw unlock が必要になるのは、bw login --apikey や bw login --sso を使った場合、または lock 後に新しい session key を取り直したい場合です。session key は bw lock または bw logout で無効化できます。
# Password Manager CLI のインストール例
npm install -g @bitwarden/cli
# ログイン
bw login
# 表示された session key を環境変数へ設定
export BW_SESSION="..."
# 例: item から password を取得
bw get password Github
# 例: note を取得
bw get notes Github
# 終わったら lock
bw lock
unset BW_SESSION
bw は普段の手作業にはとても便利です。たとえば個人用の API key や、検証用アカウントのメモを引くには十分です。ただし、Claude Code に仕事をさせるという文脈では、個人 vault ベースの運用は少し広すぎることがあります。
Claude Code 向けの本命は bws
Bitwarden Secrets Manager CLI の bws は、machine account 用の access token で認証します。machine account には project ごとの権限を付けられるため、Claude Code に見せてよい secret の範囲を最初から狭くできます。また access token は発行時に有効期限を設定できます。デフォルトは無期限ですが、期限付きにしておけば、万一どこかで漏れても被害時間を短くできます。
この考え方のよいところは、AI に完全な安全を期待しない点です。Claude Code 側の防御を活かしつつ、そもそも渡す権限を小さくし、しかも長く残さないようにします。
Secrets Manager 側で最初にやること
bws を使うには、Bitwarden Secrets Manager 側で project、machine account、access token を準備します。
まず、Secrets Manager の organization を用意し、project を作成します。次に、その project にアクセスできる machine account を作成し、最後に有効期限付きの access token を発行します。
bws の導入方法
Windows 向けの zip ファイルを取得する
Windows では、GitHub Releases から zip ファイルを取得して導入するのが分かりやすいです。執筆時点で確認した bws CLI v2.0.0 の release は 2026 年 2 月 5 日付で、GitHub の bitwarden/sdk-sm Releases に公開されています。
今回使用する Windows 向け asset は、次の zip ファイルです。
- ファイル名:
bws-x86_64-pc-windows-msvc-2.0.0.zip - SHA-256:
4284944f3b0c7b97a4d4105c715cd814c744ceff0405481a213937955e31d866 - サイズ:
5.36 MB
直接ダウンロードする場合の URL は次の通りです。
https://github.com/bitwarden/sdk-sm/releases/download/bws-v2.0.0/bws-x86_64-pc-windows-msvc-2.0.0.zip
bws.exe を配置する
zip ファイルを展開すると bws.exe が入っています。パスを通したらバージョンとヘルプを確認します。
bws --version
bws 2.0.0
bws --help
Bitwarden Secrets CLI
Usage: bws.exe [OPTIONS] [COMMAND]
Commands:
config Configure the CLI
completions Generate shell completion files
project Commands available on Projects
secret Commands available on Secrets
run Run a command with secrets injected
help Print this message or the help of the given subcommand(s)
Options:
-o, --output <OUTPUT>
Output format
[default: json]
[possible values: json, yaml, env, table, tsv, none]
-c, --color <COLOR>
Use colors in the output
Possible values:
- no: Force colors off
- yes: Force colors on
- auto: Automatically detect if colors are supported in the terminal
[default: auto]
-t, --access-token <ACCESS_TOKEN>
Specify access token for the service account
[env: BWS_ACCESS_TOKEN]
-f, --config-file <CONFIG_FILE>
[default: ~/.config/bws/config] Config file to use
[env: BWS_CONFIG_FILE=]
-p, --profile <PROFILE>
Profile to use from the config file
[env: BWS_PROFILE=]
-u, --server-url <SERVER_URL>
Override the server URL from the config file
[env: BWS_SERVER_URL=]
-h, --help
Print help (see a summary with '-h')
-V, --version
Print version
access token を設定して動作確認する
machine account に対して発行した access token で認証します。
export BWS_ACCESS_TOKEN='YOUR_ACCESS_TOKEN'
bws secret list
[
{
"id": "****",
"organizationId": "****",
"projectId": "****",
"key": "TEST_BWS_SECRET",
"value": "01234567",
"note": "",
"creationDate": "2026-03-08T04:52:16.239886700Z",
"revisionDate": "2026-03-08T04:52:16.239886700Z"
}
]
bws の基本的な使い方
bws には、secret の一覧取得、個別取得、コマンド実行時の注入といった基本機能が用意されています。代表的なのは secret list、secret get、run です。
secret list の出力には id、key、value などが含まれます。一覧取得の時点で value も出力されます。そのため、検証時は便利ですが、ログや標準出力へ無造作に流し続けないほうが安全です。
個別の secret を取得する場合は、key ではなく id を指定します。ここで指定する SECRET_ID は、bws secret list の結果に含まれる UUID です。たとえば、次のように実行します。
bws secret get <SECRET_ID>
{
"id": "****",
"organizationId": "****",
"projectId": "****",
"key": "TEST_BWS_SECRET",
"value": "01234567",
"note": "",
"creationDate": "2026-03-08T04:52:16.239886700Z",
"revisionDate": "2026-03-08T04:52:16.239886700Z"
}
必要な value だけを使いたい場合は、JSON をパースして取り出します。jq を導入済みなら、次のように書けます。
bws secret get <SECRET_ID> | jq -r '.value'
Windows 環境で jq を前提にしたくない場合は、パイプで別コマンドへ渡すよりも、Node.js から bws を直接呼び出して JSON を読むほうが問題が起きにくいです。次の例では、bws secret get の結果から value だけを取り出しています。
node -e "const { execFileSync } = require('node:child_process'); const raw = execFileSync('bws', ['secret', 'get', '<SECRET_ID>'], { encoding: 'utf8' }); console.log(JSON.parse(raw).value);"
bws run が便利
Secrets Manager CLI で特に便利なのが bws run です。これは、secret を環境変数として注入した状態でコマンドを実行する機能です。既存のスクリプトや開発用コマンドを大きく書き換えずに済むため、導入しやすいのが利点です。
たとえば、特定の project に属する secret だけを使って npm test を実行する場合は、次のように書けます。
bws run --project-id <PROJECT_ID> -- 'npm test'
--project-id を付けると、指定した project の secret だけが注入されます。
run は、既定では secret の key をそのまま環境変数名として使います。そのため、secret の key は TEST_BWS_SECRET のように、英数字と _ だけで構成された POSIX 互換の名前にしておくと扱いやすくなります。
たとえば、Secrets Manager 側に次の secret を登録しておくと、動作確認しやすいです。
- key:
TEST_BWS_SECRET - value:
これはテスト用シークレットです
この secret を使う確認用スクリプトは、次のように書けます。
const value = process.env.TEST_BWS_SECRET;
if (!value) {
console.error("TEST_BWS_SECRET is not set");
process.exit(1);
}
console.log("TEST_BWS_SECRET =", value);
これを print-secret.js として保存したうえで、次のように実行します。
bws run --project-id <PROJECT_ID> -- 'node .\print-secret.js'
TEST_BWS_SECRET = 01234567
Claude Code と組み合わせるときの考え方
重要なのは、Claude Code に何をどこまで渡すかです。私は、運用を次の 3 段階に分けて考えるのがよいと思っています。
第 1 に、長期シークレットを .env に置かないことです。これだけでも、ローカルに常駐する秘密情報はかなり減ります。
第 2 に、Claude Code 用の machine account を作り、project を分け、期限付き access token を使うことです。これで、見えてよい範囲と時間を絞れます。Bitwarden Secrets Manager では machine account ごとに project への権限を付けられ、access token の期限も指定できます。
第 3 に、secret を Claude Code 全体へ常時注入するのではなく、必要なコマンドだけ bws run で包むことです。たとえば、テストだけ secret が必要なら test 実行時だけ、デプロイだけ secret が必要なら deploy 実行時だけ、という形にできます。
注意点
bws secret get は value を含む JSON を返します。標準出力をそのままログに残す運用だと、別の場所で漏れることがあります。必要な値だけを取り出し、不要な出力を減らしたほうが安全です。
また、bws run を細かいコマンドごとに新しい session として大量に使うと、同一 IP から短時間に多くの session を張る形になり、rate limit にかかることがあります。短時間の作業単位で token を使い回すほうが扱いやすいケースもあります。
なお、これで Claude Code をどう使っても安心、というわけではありません。権限確認、ネットワークアクセスの承認、信頼できない内容を直接流し込まないことなど、Bitwarden CLI を導入してもそこは依然として重要です。
まとめ
AI エージェントに仕事をさせる時代になるほど、秘密情報の扱いは、アプリ本体以上に気を使う場面が増えます。.env は便利ですが、長期シークレットを置きっぱなしにする設計は、AI と組み合わせたときにリスクがあります。
その点、Bitwarden CLI、特に Secrets Manager CLI の bws は使いやすい選択肢です。machine account で読める範囲を絞れますし、access token に期限も付けられます。さらに bws run を使えば、必要なコマンドの実行時だけ secret を注入できます。
もちろん、これで全部解決という話ではありません。それでも、長期シークレットを .env に置くよりは、かなり扱いやすくなります。Claude Code に長く強い鍵を渡すのではなく、短く狭い鍵を必要なときだけ渡す。この発想に切り替えるだけでも、日々の運用はかなり変わると思います。