目次

はじめに

こんにちは。KDDIアイレットの松﨑です。

Backlog や New Relic などの MCP（Model Context Protocol）サーバーを Claude Code や Claude Desktop で使うとき、API キーはどこに置いていますか。

多くの解説では、設定ファイル（claude_desktop_config.json や .mcp.json）の env に API キーをそのまま書く方法が紹介されています。手軽ですが、キーが平文でディスクに残る方法です。

これをシークレット管理ツール経由に置き換える話題では、1Password CLI や AWS Secrets Manager を使う日本語記事はすでに多く見つかります。

一方で、Keeper を使う方法の日本語情報はほとんどありません。会社の標準パスワードマネージャーが Keeper で、1Password の記事をそのまま真似できない——私がまさにその状況だったので、実際に構築した手順をまとめます。

この記事のゴールは次の 3 つです。

  • MCP サーバーの設定ファイルから API キーの平文をなくす
  • Keeper の 2 種類の CLI（KSM と Commander）の違いと選び方が分かる
  • 実際にハマった落とし穴（notation が使えない・最小環境問題など）を先回りで回避できる

前提環境

項目 バージョン等
OS macOS（Apple Silicon）
Keeper Commander CLI 18.x
Node.js 20 以上（MCP サーバーの実行に使用）
MCP サーバーの例 backlog-mcp-server
MCP クライアント Claude Code（CLI）／ Claude Desktop

なお、この方法は MCP クライアントに依存しません。

後述するラッパースクリプトは「キーを環境変数に入れて標準的な MCP サーバー（stdio）を起動する」だけなので、コマンド型 MCP サーバーを起動できるクライアント（Claude Code / Claude Desktop / Cursor / VS Code 系拡張）で共通に使えます。

結論: MCP 起動時に Keeper から注入する

先に結論です。設定ファイルには API キーの代わりにラッパースクリプトのパスだけを書き、キーは起動のたびに Keeper から取得します。

[MCP クライアント (Claude Code / Claude Desktop)]
        │  command に指定されたラッパーを起動
        ▼
[ラッパースクリプト run-backlog-mcp.sh]
        │  keeper find-password <RECORD_UID> で API キーを取得
        │  環境変数 BACKLOG_API_KEY に注入
        ▼
[MCP サーバー本体 (backlog-mcp-server)]
        │
        ▼
[Backlog API]

この構成の利点は 2 つあります。

  • 設定ファイルにもスクリプトにも API キーの平文が残らない（Keeper Vault にだけ存在する）
  • キーのローテーションが Keeper のレコード更新だけで完結する（設定ファイルの変更が不要）

Keeper には CLI が 2 つある

ここが Keeper 特有のポイントで、最初に整理しておくと迷いません。Keeper には性格の異なる CLI が 2 種類あります。

Keeper Secrets Manager CLI（ksm） Keeper Commander CLI（keeper）
想定用途 マシン向けのシークレット管理 管理操作・Vault の対話操作
認証の単位 Application（デバイス登録） 自分のアカウントで Vault にログイン
必要な権限 Secrets Manager 機能の有効化と共有フォルダ（Application）の作成権限 特別な権限は不要
シークレット取得 ksm exec / Keeper Notation（keeper://...） keeper find-password

機械からシークレットを取る用途には本来 KSM が向いています。

ただし KSM は Application の作成＝Secrets Manager 機能の有効化が必要で、企業アカウントでは一般ユーザーにこの権限が付与されていないことがあります。私の環境でも共有フォルダを作成できず、KSM は使えませんでした。

そこで採用したのが Commander CLI（keeper）です。自分の Vault に直接ログインして使うため、Secrets Manager の権限が無くても利用できます。

「KSM の権限が無いから Keeper 連携は無理」と諦める必要はありません。この記事では Commander 方式で進めます。

Keeper Commander のセットアップ

インストール

GitHub のリリースページから macOS 用の pkg（Apple Silicon は arm64、Intel は x86_64）を取得してインストールします。

keeper version    # Commander Version: 18.x.x と出れば OK
which keeper      # 通常 /usr/local/bin/keeper

ログイン（SSO の場合）

keeper shell

keeper shell のプロンプトで自分のアカウントにログインします。

login you@example.com

SSO 連携されている環境では選択肢で o を入力するとブラウザが開くので、認証を完了して「Copy login token」でトークンをコピーし、ターミナルに貼り付ければログイン完了です。

永続ログインの設定（必須）

ここが重要です。MCP サーバーはクライアントの起動のたびに非対話でキーを取りに来ます。毎回 SSO 認証を求められては成立しないので、デバイスを登録して永続ログインを有効にします。keeper shell 内で次を実行します。

this-device register
this-device persistent-login ON
this-device ip-auto-approve ON
this-device timeout 24h

設定後、通常のターミナルから非対話で状態確認できれば成功です。

keeper login-status     # => Logged in

API キーをレコードに保存して取得する

ログイン用パスワードとは別に、API キー専用のレコードを作ります（用途を分けておくと、共有やローテーションの範囲を最小化できます）。

  1. 連携先サービス（Backlog なら「個人設定 → API」）で API キーを発行する
  2. Keeper Vault でレコードを新規作成し、Password 欄に API キーを格納する（タイトル例: Backlog API (MCP)）
  3. レコードの UID を控えて、CLI から取得できるかテストする
keeper find-password <RECORD_UID>   # API キーが 1 行返れば OK

ここで 1 つ目の落とし穴です。Keeper のドキュメントには keeper:///field/password という Keeper Notation の記法が出てきますが、これは KSM / SDK 用で、Commander の get コマンドでは解釈されません。

私は最初にこれを試して「Cannot find any object」エラーに悩みました。Commander では find-password を使います。

ラッパースクリプトで MCP サーバーに注入する

キーを取得して環境変数に注入し、MCP サーバー本体を起動するラッパーを作ります。Backlog MCP サーバーの例です。

なお、Backlog MCP Server 自体の基本的な使い方は、弊社の記事「Backlog MCP ServerをClaude Codeから利用する」も参考にしてください。

run-backlog-mcp.sh:

#!/usr/bin/env bash
set -euo pipefail

# MCP クライアントは最小環境でこのスクリプトを起動するため、PATH を明示する
export PATH="/usr/local/bin:/opt/homebrew/bin:$PATH"

# API キーを Keeper から取得して注入（平文はどこにも保存しない）
export BACKLOG_API_KEY="$(keeper find-password <RECORD_UID>)"
export BACKLOG_DOMAIN="your-space.backlog.jp"

exec npx -y backlog-mcp-server

なお npx -y は実行のたびに npm から最新版を取得します。動作を固定したい場合は backlog-mcp-server@<検証済みバージョン> のようにバージョンを指定してください。

chmod +x run-backlog-mcp.sh
./run-backlog-mcp.sh   # 単体テスト: 起動して入力待ちで止まれば成功（Ctrl+C で抜ける）

コメントにも書いたとおり、MCP クライアントはユーザーのシェル設定（~/.zshrc など）を読み込まない最小環境で MCP サーバーを起動します。

ターミナルでは動くのにクライアント経由だと失敗する場合、ほぼこれが原因です。keeper や npx が見つかるよう、スクリプト内で PATH を明示的に export しておきます。

MCP クライアントへの登録と動作確認

ラッパーができたら、各クライアントに「コマンド = スクリプトの絶対パス」を登録するだけです。env に API キーは書きません。

Claude Code（CLI）の場合

claude mcp add backlog -- /path/to/run-backlog-mcp.sh
claude mcp list    # 登録確認

Claude Desktop の場合

~/Library/Application Support/Claude/claude_desktop_config.json の mcpServers に追記します。

{
  "mcpServers": {
    "backlog": {
      "command": "/path/to/run-backlog-mcp.sh"
    }
  }
}

登録後にクライアントを再起動（Claude Desktop は Cmd+Q で完全終了してから起動）し、動作を確認します。

# キー単体の確認: Backlog API に直接アクセスして自分の情報が返るか
API_KEY="$(keeper find-password <RECORD_UID>)"
curl -sS "https://your-space.backlog.jp/api/v2/users/myself?apiKey=${API_KEY}"

# ラッパー経由で MCP が起動しているかの確認
pgrep -fl run-backlog-mcp.sh

Claude 側で「Backlog のプロジェクト一覧を取得して」のように依頼してツールが動けば成立です。

なお、この curl はクエリに API キーを含むためシェル履歴に残ります。あくまで確認用の一時的なコマンドとし、確認後は履歴から削除しておくと安心です。

つまずきポイント 3 選と運用メモ

構築中に実際にハマった箇所を「何が起きたか → 原因 → 解決」で共有します。

1. Keeper Notation が Commander では使えない

前述のとおり、keeper get keeper:///field/password は「Cannot find any object」になります。

Notation は KSM / SDK 用の記法で、Commander では find-password を使うのが正解です。

同じ Keeper でも CLI によって記法が違う点は、ドキュメントを行き来していると見落としやすいところです。

2. ターミナルでは動くのに MCP クライアント経由だと失敗する

MCP クライアントは最小環境で MCP サーバーを起動するため、シェルの PATH や環境変数を引き継ぎません。

ラッパースクリプト内で必要な環境変数をすべて明示的に export することで解決しました。「手元では動くのに」系のトラブルは、まずここを疑うのが早いです。

3. SSL インスペクション環境で証明書エラーになる

通信内容を復号検査（SSL インスペクション）するプロキシのある企業ネットワークでは、keeper（Python 製）が接続先の証明書を「知らない発行元」と判断し、Certificate validation error でログインに失敗することがあります。

この場合は、OS 標準の CA 証明書と社内 CA 証明書を 1 つにマージしたバンドル証明書を作り、環境変数で参照させます。

# OS 標準 CA と社内 CA を 1 つの PEM にまとめる（macOS の例）
security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain > ~/ca-bundle.pem
security find-certificate -a -p /Library/Keychains/System.keychain >> ~/ca-bundle.pem

# keeper は Python 製、MCP サーバーは Node 製のことが多いので両方に効かせる
export REQUESTS_CA_BUNDLE="${HOME}/ca-bundle.pem"
export NODE_EXTRA_CA_CERTS="${HOME}/ca-bundle.pem"

ポイントは、社内 CA の単一証明書だけを指定するのではなく、OS 標準 CA を含むバンドルを参照させることです（単一証明書を指定すると、今度は一般のサイトの検証に失敗します）。

該当環境の方は、ラッパースクリプト内でもこの 2 つの環境変数を export しておいてください。

数ヶ月運用してみて

この構成で数ヶ月運用していますが、日常の手間はほぼありません。

  • キーのローテーション: Keeper のレコードを更新するだけ。設定ファイルもスクリプトも触らない
  • セッション切れ: 永続ログインのセッションが切れると MCP がキーを取得できなくなります。keeper login-status が Not logged in なら keeper shell から再ログインすれば復旧します
  • 横展開: 他のサービス（New Relic など）も、レコードとラッパーを 1 本ずつ足すだけで同じ方式に乗せられます

おわりに

MCP サーバーの API キーを Keeper Commander CLI 経由で注入する構成を紹介しました。まとめると次のとおりです。

  • 設定ファイルの env に平文で書く代わりに、ラッパースクリプトで起動時に keeper find-password から注入する
  • KSM の権限が無い環境でも、Commander CLI なら自分の Vault だけで完結できる
  • ハマりどころは「Notation は Commander で使えない」「クライアントは最小環境で起動する」「SSL インスペクション環境の証明書」の 3 つ

シークレット管理ツールが 1Password でなくても、同じ発想は他のツールにも応用できます。「会社の標準が Keeper だから」と平文運用を続けている方の参考になれば嬉しいです。