ローカルに保存していたAWS MCPサーバーの認証情報を1Password CLIに移行してみた

くどうです。

Claude DesktopなどからIAM認証情報が必要なAWSのMCPサーバー（AWS Pricing MCPなど）を使うとき、多くの場合 ~/.aws/credentials で平文保存しがちなのではないでしょうか。私はそうでした。

ローカルにアクセスキーが平文で残るのはセキュリティ上避けたいので、1Password CLI（op）を使ってシークレットをVaultから都度取得し、環境変数としてMCPプロセスに注入する構成 に移行しました。

本記事では、その移行手順と、ハマりどころをまとめます。

前提

• macOS
• Claude Desktopインストール済み（Claude Desktop以外からMCPを使っている方は不要です）
• 1Passwordデスクトップアプリ インストール済み
• もともとAWS Pricing MCP（その他IAM認証情報が必要なMCP）を ~/.aws/credentials 経由で動かしていた

ゴール構成

ローカルに平文の aws_access_key_id / aws_secret_access_key を一切残さず、MCPプロセス起動のたびに1Passwordから取得する形になります。

手順

1. 1Password CLI を導入する

下記の記事の「1Password CLIのインストール」から「動作確認」までを実施します。

https://dev.classmethod.jp/articles/1password-cli-credential/

荒平さん、ありがとうございます！

2. ローカルに.env ファイルを作成

まずローカルにファイルを作って動作確認し、最終的には1Passwordの仮想マウントに移行します。

op run に読み込ませる .env ファイルを作成します。
※任意の場所でOKですが、 .config はLinuxで一般的に推奨される置き場所です。

下記をターミナルから実行します。

mkdir -p ~/.config/aws-pricing-mcp
vi ~/.config/aws-pricing-mcp/.env

ファイルの中身：<アイテム名> には、自分で設定した1Passwordのアイテム名を入力します

例

AWS_ACCESS_KEY_ID="op://Private/<アイテム名>/access key id"
AWS_SECRET_ACCESS_KEY="op://Private/<アイテム名>/secret access key"

アイテム名はコレ

私の場合

AWS_ACCESS_KEY_ID="op://Private/AWS-mcp-key/access key id"
AWS_SECRET_ACCESS_KEY="op://Private/AWS-mcp-key/secret access key"

この時点ではまだ平文の認証情報は保存されていません。 あくまで1Passwordの参照が書かれているだけです。 op run 実行時にこの参照が解決されて、実際の値が環境変数として子プロセスに渡されます。

3. .envファイルを仮想的にマウントする

ローカルに.envファイルを置きたくないので、下記の記事を参考に1Passwordで仮想的にマウントします。

※今回作った.envファイルには流出したらまずい情報は書いてありませんが、企業のポリシーなどで「ローカルに.envはおくな！」と指定されている場合を想定しています

下記の記事の「1. 1Password Developer機能の有効化」から「6. .envにアクセスできるか確認する」までを実施します。

https://dev.classmethod.jp/articles/1password-environments-env-management/

和田さん、ありがとうございます！

4. ターミナルで動作確認

Claude Desktopの設定を変える前に、CLIで.envがきちんと読めるか確認しておきます。

# 環境変数として展開されるか
op run --env-file=$HOME/.config/aws-pricing-mcp/.env -- env | grep AWS_

# AWS API が叩けるか
op run --env-file=$HOME/.config/aws-pricing-mcp/.env -- aws sts get-caller-identity

↓get-caller-identity で IAM User の情報が返ってくれば成功です

5. claude_desktop_config.json を編集

MCPサーバーを設定しているファイル
/Users/<USERNAME>/Library/Application Support/Claude/claude_desktop_config.json
を編集します。

※Claude Desktop以外でMCPサーバーを使ってる方は、お使いのMCPサーバーを管理している設定ファイルを編集してください

変更前:

{
  "mcpServers": {
    "aws-pricing": {
      "command": "uvx",
      "args": [
        "awslabs.aws-pricing-mcp-server@latest"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

変更後:

{
  "mcpServers": {
    "aws-pricing": {
      "command": "op",
      "args": [
        "run",
        "--env-file=/Users/<USERNAME>/.config/aws-pricing-mcp/.env",
        "--no-masking",
        "--",
        "uvx",
        "awslabs.aws-pricing-mcp-server@latest"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      }
    }
  }
}

ポイント:

• command を op に変更
• --no-masking を付ける
  • op run はデフォルトで子プロセスの標準出力からシークレットらしき文字列をマスクしますが、これがMCPプロトコルのJSON出力を壊してしまうため無効化します
• -- 以降が本来の起動コマンド（uvx awslabs.aws-pricing-mcp-server@latest）

6. Claude Desktop を終了 → 起動

ウィンドウを閉じるだけでは設定は反映されません。Cmd+Q またはメニューから「終了」を選んで完全終了してから起動し直します。

起動すると、1Passwordからの認証が求められます。

動作確認

Claude DesktopでAWS Pricing MCPを呼ぶようなプロンプトを投げて確認します。

「EC2のt3.nanoの東京リージョンの価格を教えてください。」

正しく価格情報（例: $0.0068 / hour）が返ってくれば成功です。
ちゃんとaws-pricingを使用していることがわかります。

ハマりポイント

認証が失敗してMCPサーバーが使えない

主な原因は以下の3つでした。

1Passwordデスクトップアプリの "1Password CLIと連携" 設定が無効

1Passwordの設定を開きます

開発者 ＞ 1Password CLIと連携 のチェックを入れます

op や uvx コマンドにPATHが通ってない

ターミナルから which op や which uvx を叩き、出たパスを参考にフルパスで記載するとよいです。

{
  "command": "/opt/homebrew/bin/op", ←フルパスで書く
  "args": [
    "run",
    "--env-file=/Users/<USERNAME>/.config/aws-pricing-mcp/.env",
    "--no-masking",
    "--",
    "/Users/<USERNAME>/.local/bin/uvx", ←フルパスで書く
    "awslabs.aws-pricing-mcp-server@latest"
  ]
}

やってみてどうだったか

うれしい点

• ローカルディスクに平文の認証情報を残さない ← これが一番デカいです
• 複数マシン間で 1Password Vault を共有していれば同じ設定がそのまま使える
• 他の MCP サーバーやスクリプトでも同じパターンを使い回せる

あまりうれしくない点

• Claude Desktopを立ち上げるたびに 1Password アプリからの認証が求められる
  • MacのTouch IDを設定していればそんなに手間ではない

AWS 認証情報が必要なMCPサーバーは同じパターンが使える

awslabs が公開している AWS 系 MCP サーバーのうち、AWS 認証情報が必要なもの は基本的に同じ op run パターンが流用できます。

最新の一覧は awslabs/mcp やOpen Source MCP Servers for AWSを参照してください。

認証情報が不要なもの（参考）

以下は AWS API を叩かずに完結するため、特に気にする必要はありません。

• awslabs.aws-documentation-mcp-server
• awslabs.aws-diagram-mcp-server
• awslabs.frontend-mcp-server

など

最新の一覧は awslabs/mcp やOpen Source MCP Servers for AWSを参照してください。

IAM User を分けるかどうか

複数の MCP サーバーで認証情報を共有するか、用途別に分けるかは思想によりますが基本的に分けることをオススメします。
なぜなら、MCPサーバーごとに使用するIAMの権限が違うので、最小権限に則ってIAMポリシーを設定するべきだからです。

MCPサーバー別に IAM User を分ける場合:

~/.config/
├── aws-pricing-mcp/.env      → pricing:* のみ
├── aws-cloudwatch-mcp/.env   → cloudwatch:Get*, logs:* など
├── aws-iam-mcp/.env          → iam:* (Read系のみ)
└── aws-ccapi-mcp/.env        → ReadOnlyAccess または個別ポリシー

上記のようにサーバーごとに .env と Vault のアイテムを分けて管理するのがよいでしょう。

おわりに

みなさんもローカルから認証情報をできるだけ排除しましょう！！
組織のセキュリティポリシー的にも個人のセキュリティ衛生的にも嬉しいかと思います。

この記事が誰かの参考になれば幸いです。