Backlog APIキーを1Passwordで管理してMCPから利用する
作成日: 2026/05/13
最終更新日: 2026/05/13
#Backlog
#Claude-Code
#1Password
やりたいこと
BacklogのAPIキーをローカルファイルに保存せず、1Passwordで管理し、Claude CodeのMCPサーバー起動時に取得して環境変数として渡したい。
動機
Claude Codeを実行するたびに、手動で export BACKLOG_API_KEY="..." するのは面倒
どこかのファイルに export BACKLOG_API_KEY="BacklogのAPIキー" と書いておく方法もあるが、様々なcredentialの置き場所が分散すると管理がしんどい
「あれのキーはどこだっけ?」
「このキーを更新したいけど、どのファイルを直すんだっけ?」
となりやすい
そもそもローカルファイルに秘匿情報を保持しておくのは、今どきあまり良い運用ではなさそう
APIキーを平文で書きたくない
AWSでは、そもそもアクセスキーを発行せずに認証する流れが強くなっている
自分の場合、認証情報はほぼ1Passwordで管理している
1箇所にまとまっていると認知負荷が低い
更新・棚卸しもしやすい
BacklogのWebログイン情報も1Passwordに保管している
APIキーも同じ1Password上にセットで保管しておくと、「どのBacklogのキーか」が分かりやすい
PyCharm経由でClaude Codeを起動すると環境変数が引き継がれない
方針
1Passwordに保管して1Passwordからとれないの?とChatGPTに聞いてみたらふつうにできた。
APIキーは1Passwordに保存
MCP起動時に op read で取得
環境変数はMCPプロセス内だけで利用
よさみ
セキュリティが高い(平文ファイルなし)
PyCharmなど起動元に依存しない
MCP単位で責務が閉じる
APIキーの更新は1Password側だけで完結
手順
1. 1PasswordにAPIキーを保存
Vault: {Vault名}
Item名: {プロジェクト名}-Backlog
フィールド名: api_key
2. 1Password CLIの準備
code:bash
brew install 1password-cli
op signin
私の場合、ChatGPTの説明を良く読まず「op signin」する前に自分でweb検索した 1Password アプリとの連携 を見て「1Passwordアプリ側で連携の設定」をしちゃったので、この辺の動きが良くわかんないんですが、そもそも1Passwordのアカウントが複数ある場合は、op signin コマンドを叩くとログインするアカウントを選択できるようですだそうです。
私は1Passwordのアカウントを一つしか持っていないので、1Password アプリとの連携 に書いてくださっているとおりの動きになりました。
3. 動作確認
code:bash
op read "op://{Vault名}/{Item名}/api_key"
APIキーが取得できればOK
4. MCP設定を更新
code:json
"backlog": {
"command": "zsh",
"args": [
"-lc",
"export BACKLOG_API_KEY=\"$(op read op://{Vault名}/{Item名}/api_key)\" && npx -y backlog-mcp-server"
],
"env": {
"BACKLOG_DOMAIN": "{プロジェクトの}.backlog.com"
}
}
ポイント
${BACKLOG_API_KEY} は使わない(親プロセスに依存するため)
zsh -lc でシェルを起動し、その中で環境変数をセット
APIキーはどのファイルにも平文で保存されない
参考にしたページ
AWSの認証情報を平文で保存しないように、1Password CLIに移行してみた
アクセスキーを保護する
もうIAMユーザーのアクセスキーは必要ない!?aws loginでAWS CLIを利用する方法
aws loginていうのできたんですねえ、良さそうですね
Simplified developer access to AWS with ‘aws login’
aws login で個人アクセスキーを捨てられる? 試してハマった話と、正しい使い分け
Identity Centerへ移行もOIDCを使うもTODOとして積んでいるだけでできてない...(泣)
ロールはやってるな
でも、今はもうほぼAWS CloudShell使ってCLI発行してるので、個人の IAM User アクセスキー使ってローカルからCLI発行することってほぼないなあ..何かを大量にDLしたい場合以外は (容量制限1GB)。というかそういう話じゃなくて、そもそも永続的なアクセスキーを発行していてローカルに保持してること自体がダメなんだけど。