aws-vault vs Granted：macOSでAWSクレデンシャルを安全に管理するツール比較

はじめに

AWSの開発を行う際、~/.aws/credentialsにアクセスキーを平文で保存していませんか？これはセキュリティ上のリスクが高く、万が一ファイルが流出した場合、AWSアカウントが不正利用される恐れがあります。

この記事では、macOSでAWSクレデンシャルを安全に管理するための2つのツール「aws-vault」と「Granted」を比較し、セットアップ手順から日常的な使い方、マルチアカウント運用時のワークフローまでを紹介します。

なぜ平文のクレデンシャルが危険なのか

デフォルトのaws configureを実行すると、アクセスキーが~/.aws/credentialsに平文で保存されます。

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

このファイルが以下の経路で流出するリスクがあります：

• dotfilesリポジトリへの誤コミット
• マルウェアによるファイル読み取り
• ディスクバックアップからの漏洩
• 共有端末での他ユーザーからのアクセス

aws-vaultとGrantedは、いずれもOSのキーチェーンにクレデンシャルを暗号化保存し、STSで一時的な認証情報を生成することでこの問題を解決します。

前提・環境

• macOS（Keychain Access対応）
• Homebrew導入済み
• AWS CLIインストール済み
• IAMユーザーのアクセスキー（MFA設定済み）

AWSアクセスキーの作成

aws-vaultやGrantedにクレデンシャルを登録するには、IAMユーザーのアクセスキーが必要です。まだ作成していない場合は、以下の手順でAWSコンソールから作成します。

1. AWSマネジメントコンソールにログインし、IAM → ユーザー → 自分のユーザー名をクリック

2. セキュリティ認証情報タブを開き、「アクセスキーを作成」をクリック
   

3. ユースケースで「コマンドラインインターフェイス (CLI)」を選択し、確認チェックボックスにチェックを入れて「次へ」
   

4. 説明タグ（任意）を設定し、「アクセスキーを作成」をクリック
   

5. アクセスキーIDとシークレットアクセスキーが表示されるので、両方をコピーして安全な場所に控える
   

重要: シークレットアクセスキーはこの画面でしか確認できません。紛失した場合は新しいキーを作成する必要があります。IAMユーザーあたり最大2つのアクセスキーを持てるため、ツール移行時には新しいキーを作成し、移行完了後に古いキーを無効化→削除するのが安全です。

ツールの仕組み（共通）

aws-vaultとGrantedはどちらも同じ原理でクレデンシャルを管理します。個別のツール説明に入る前に、共通の仕組みを押さえておきましょう。

クレデンシャル管理のラッパー

aws-vaultとGrantedはAWS CLIやSDKを置き換えるものではなく、クレデンシャルの取得・管理だけを担当するラッパーです。実際のAWS操作（S3、EC2、Lambdaなど）は従来どおりAWS CLI/SDKが行います。

ツール自体はGo製の独立バイナリで、内部でAWS Go SDKを使ってSTS APIを直接呼び出します（AWS CLIは経由しません）。取得した一時クレデンシャルを環境変数（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN）にセットし、AWS CLIやSDKがそれを読み取る仕組みです。AWS CLIはクレデンシャルの解決順序として環境変数を最優先で参照するため、~/.aws/credentialsは一切使われなくなります。

macOS Keychain統合

aws-vaultとGrantedはどちらもmacOS Keychainを使ってクレデンシャルを安全に管理します。

1. 専用キーチェーン: クレデンシャルはログインキーチェーンではなく、専用のキーチェーン（例: ~/Library/Keychains/aws-vault.keychain-db）に暗号化して格納されます。~/.aws/credentialsに平文で保存する場合と異なり、ファイルが流出しても復号できません
2. 一時認証情報: 保存された長期クレデンシャルからSTSのGetSessionTokenで一時クレデンシャルを生成（デフォルト1時間有効）。アプリケーションには一時クレデンシャルのみが渡されます
3. コード署名: 両ツールのmacOSリリースビルドはコード署名されており、Keychainアクセス時の繰り返しのパスワードプロンプトを防ぎます

ツール別の保存方法: aws-vaultはaws-vault add <profile>、Grantedはgranted credentials add <profile>でクレデンシャルをKeychainに保存します。

~/.aws/configの設定

aws-vaultとGrantedはどちらも~/.aws/configを読み込みます。設定形式は共通で、ツール間で同じファイルをそのまま共用できます。

[profile my-profile]
region = ap-northeast-1
output = json

[profile my-profile-admin]
source_profile = my-profile
role_arn = arn:aws:iam::123456789012:role/AdminRole
mfa_serial = arn:aws:iam::123456789012:mfa/my-iam-username
region = ap-northeast-1
output = json

• source_profile: クレデンシャルを持つベースプロファイル名を指定
• role_arn: AssumeRoleするロールのARN
• mfa_serial: MFAデバイスのARN（IAMコンソールの「セキュリティ認証情報」タブで確認）。仮想MFAの場合、識別子は通常IAMユーザー名と同じ
• region: デフォルトのAWSリージョン
• output: CLI出力形式。json（デフォルト）、text、table、yamlから選択

ソースプロファイルとAssumeRoleの関係

上記の設定では2種類のプロファイルがあります。

1. ソースプロファイル（my-profile）— IAMユーザーの長期クレデンシャルを持つベースプロファイル。Keychainへのクレデンシャル登録が必要
2. AssumeRoleプロファイル（my-profile-admin）— クレデンシャルを持たず、source_profile経由でソースプロファイルの認証情報を使いSTSのAssumeRoleを実行。~/.aws/configの設定だけで動作する

つまり、クレデンシャルの登録が必要なのはソースプロファイルのみです。AssumeRoleプロファイルをいくつ追加しても、追加のクレデンシャル登録は不要です。

複数のソースプロファイルがある場合

組織ごとに異なるIAMユーザーを持つ場合も、ソースプロファイルごとに1回ずつクレデンシャルを登録すれば、配下のAssumeRoleプロファイルはすべて動作します。

# ソースプロファイル①: classmethod社のIAMユーザー
[profile classmethod]
region = ap-northeast-1

[profile project-a-prod]
source_profile = classmethod
role_arn = arn:aws:iam::111111111111:role/AdminRole
mfa_serial = arn:aws:iam::000000000000:mfa/my-user

# ソースプロファイル②: foo-corp社のIAMユーザー
[profile foo-corp]
region = ap-northeast-1

[profile project-c-stg]
source_profile = foo-corp
role_arn = arn:aws:iam::222222222222:role/DevRole
mfa_serial = arn:aws:iam::333333333333:mfa/my-user

クレデンシャルの登録はclassmethodとfoo-corpの2つだけです。project-a-prodからproject-c-stgへの切り替えは、ソースプロファイルが異なっていても同じ操作で行えます。

aws-vault

概要

aws-vault は、99designs社が開発したGo製のCLIツールです。AWSクレデンシャルをOSのキーチェーンに暗号化して保存し、STSのGetSessionTokenやAssumeRoleを使って一時的な認証情報を生成します。

インストール

brew install --cask aws-vault

初期セットアップ

1. クレデンシャルの保存

aws-vault add my-profile

アクセスキーIDとシークレットキーの入力を求められます。入力した情報はmacOS Keychainに暗号化して保存されます。

このコマンドはKeychainへの保存のみを行い、~/.aws/credentialsや~/.aws/configには一切書き込みません。保存されたプロファイルはaws-vault listで確認できます。

2. 動作確認

aws-vault exec my-profile-admin -- aws sts get-caller-identity

MFAトークンの入力を求められ、成功すると以下のような出力が得られます：

{
    "UserId": "AROA3XFRBF23EXAMPLE:session-name",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/AdminRole/session-name"
}

aws-vaultのexecコマンドは、サブシェル（子シェルプロセス）を生成してAWSクレデンシャルを注入します。この仕組みを理解しておくと、後述のトラブルシューティングやGrantedとの比較がスムーズになります。

ターミナル起動
└── zsh (親シェル)                        ← 通常の作業環境
    └── aws-vault exec my-profile-admin  ← サブシェルを生成
        └── zsh (子シェル + AWS環境変数)  ← AWS操作はここで行う
            exit                          ← 子シェル終了
    ← 親シェルに戻る（AWS環境変数は消える）

サブシェルは親シェルとは独立したプロセスです。AWS認証情報は子シェルの環境変数にのみ存在するため、exitで子シェルを終了すると認証情報も一緒に消えます。これがaws-vaultで「アカウント切り替えのたびにコンテキストが失われる」原因です。

対比: Grantedのassumeはsourceコマンドでスクリプトを読み込み、現在のシェルに直接環境変数をセットします。サブシェルを生成しないため、exitは不要で、シェルのコンテキスト（カレントディレクトリ、コマンド履歴など）がそのまま維持されます。

よく使うコマンド

よくあるトラブル

サブシェル内でセッションが切れた場合、exitでサブシェルを抜けてから再度execします（MFA再入力が必要）。通常はこれだけで十分です。

exit                                # サブシェルを抜ける
aws-vault exec my-profile-admin   # 新しいセッションを取得（MFA再入力）

exitはaws-vault固有のコマンドではなく、シェルのビルトインコマンドです。aws-vaultのexecがネストされたシェルプロセスを起動するため、exitでそのシェルを終了すると親シェルに戻ります。

exitを実行せず直接aws-vault exec my-profile-adminを実行する場合、下記のエラーが出ます。

aws-vault: error: exec: running in an existing aws-vault subshell

すでにaws-vaultのサブシェル内にいるので、exitでサブシェルを抜ける必要があります。

まれに再度execしてもエラーが続く場合は、キャッシュされた古いセッションが原因の可能性があります。clearで明示的にキャッシュを削除してください。

aws-vault clear my-profile-admin  # キャッシュされたセッションを削除
aws-vault exec my-profile-admin   # 新しいセッションを取得

Granted

概要

Grantedは、Common Fate社が開発したGo製のCLIツールです。aws-vaultと同様にKeychainにクレデンシャルを暗号化保存しますが、サブシェルを使わずに現在のシェルで直接クレデンシャルを切り替えられるのが最大の特徴です。

インストール

brew tap common-fate/granted  # Common Fate提供のtapを追加
brew install granted

インストール後、バージョンを確認します。

granted -v

初回実行時に、シェルプロファイルにエイリアスの追加を求められます。これによりassumeコマンドが使えるようになります。設定後、ターミナルを再起動してください。

初期セットアップ

1. IAMクレデンシャルの安全な保存

granted credentials add my-profile

アクセスキーIDとシークレットキーの入力を求められ、キーチェーンに直接保存されます。同時に~/.aws/configにcredential_processの設定が自動追記されます。

[profile my-profile]
credential_process = granted credential-process --profile=my-profile
region = ap-northeast-1
output = json

credential_processはAWS CLI/SDKのネイティブ機能で、クレデンシャルが必要な時に指定されたコマンドを自動的に実行して認証情報を取得します。この設定があれば、assumeやaws-vault execを使わなくてもaws s3 ls --profile my-profileのように通常のAWS CLIコマンドがそのまま動作します。aws-vaultにはこの自動追記機能はないため、Granted固有の利点です。

既に~/.aws/credentialsに平文で保存されたクレデンシャルがある場合は、以下のコマンドでまとめてキーチェーンに移行できます。

granted credentials import

2. 動作確認

assume my-profile-admin

プロファイルを指定せずにassumeだけ実行すると、インタラクティブなファジー検索でプロファイルを選択できます。

assume
# → プロファイル一覧がファジー検索で表示される

よく使うコマンド

よくあるトラブル

source: no such file or directory: assumed

シェルのエイリアス設定が正しくない場合に発生します。~/.zshrc（または~/.zshenv）に以下のエイリアスが設定されているか確認してください。

# 正しいエイリアス
alias assume="source assume"

# 誤ったエイリアス（古いバージョンのGrantedが生成する場合がある）
# alias assume="source assumed"  ← "d"が余分

過去のバージョンではassumedというバイナリ名が使われていたため、アップデート後にエイリアスが古いまま残っていることがあります。修正後、ターミナルを再起動してください。

[✘] a profile with name my-profile already exists

granted credentials addは新しいプロファイルの作成とクレデンシャルの保存を同時に行うため、~/.aws/configに既にプロファイルが存在する場合はエラーになります。

既存のプロファイルにクレデンシャルを追加するには、granted credentials importを使います。ソースプロファイル（クレデンシャルを持つベースプロファイル）の認証情報を~/.aws/credentialsに一時的に記述してからインポートします。

# 1. ソースプロファイルのクレデンシャルを一時的に記述
# ~/.aws/credentials に [my-profile] セクションを追加

# 2. インポート実行
granted credentials import my-profile

# 3. ~/.aws/credentials から平文のクレデンシャルを削除

ポイント: AssumeRole用のプロファイル（role_arnとsource_profileを持つもの）にはクレデンシャルの登録は不要です。ソースプロファイルのクレデンシャルだけをインポートすれば、すべての子プロファイルが自動的に動作します。

aws-vault vs Granted 比較

基本比較

シェル動作の設計思想とマルチアカウント運用

両ツールのシェル動作の違いは、単なるUXの差ではなくセキュリティと利便性のトレードオフに基づく設計判断です。この違いは、複数のプロジェクト×環境（stg/prod）を扱う場合に大きなワークフローの差として現れます。

aws-vault：サブシェルによるクレデンシャルの隔離

aws-vault exec project-a-stg      # サブシェル1（source: classmethod）
# 作業する...
exit                                # サブシェルを抜ける
aws-vault exec project-c-stg      # サブシェル2（source: foo-corp）
# 作業する...
exit
aws-vault exec project-a-stg      # 戻る（MFA期限切れなら再入力）

• クレデンシャルはサブシェル（子プロセス）の環境変数にのみ存在し、exitでプロセスごとメモリから消える
• 誤って別プロファイルのクレデンシャルでコマンドを実行するリスクがない
• シェルの設定変更（エイリアス追加など）が不要で、どのシェルでもそのまま動作する
• ただし、切り替えのたびにexit → execが必要で、シェルのコンテキスト（カレントディレクトリ、コマンド履歴）が失われる

Granted：環境変数エクスポートによるワークフロー効率

assume project-a-stg              # 環境変数をセット（source: classmethod）
# 作業する...
assume project-c-stg              # 環境変数を上書き（source: foo-corp）
# 作業する...
assume project-a-stg              # 戻る、exitは不要

• サブシェルを使わないため、シェルのコンテキストを維持したままassume一発で切り替え可能
• ただし、クレデンシャルは現在のシェルに残り続けるため、assumeの実行を忘れると前のプロファイルで操作してしまう可能性がある

どちらが「正しい」ということではなく、何を優先するかの違いです。セキュリティ重視ならaws-vaultのプロセス隔離、マルチアカウントの切り替え頻度が高いならGrantedの効率性が活きます。

AWSコンソールアクセスの違い

# aws-vault: 1ブラウザセッションに1アカウント
aws-vault login project-a-stg     # ブラウザでコンソールを開く
aws-vault login project-b-prod    # 上のセッションからログアウトされる

# Granted: 複数アカウントを同時にブラウザで開ける
assume -c project-a-stg           # タブ1: project-a-stg のコンソール
assume -c project-b-prod          # タブ2: project-b-prod のコンソール（別コンテナ）
assume -c project-c-dev           # タブ3: project-c-dev のコンソール

Grantedはブラウザのコンテナ機能を使って、複数のAWSアカウントに同時ログインできます。マルチアカウント運用では非常に便利です。

セッション更新の違い

IAM + MFA構成の場合、セッション期限切れ時の動作が異なります。

補足: MFAトークンの入力自体はどちらのツールでも省略できません。違いは、再認証時にシェルのコンテキストが維持されるかどうかです。

awsumeについて

awsumeは、Grantedと同様に現在のシェルに環境変数をエクスポートする方式のPython製ツールです。autoawsumeによる自動リフレッシュやプラグインシステムなど優れた機能がありますが、以下の理由から本記事ではaws-vaultとGrantedの2択をお勧めします。

• クレデンシャルが~/.aws/credentialsに平文で保存される（Keychain統合なし）
• Python依存（ランタイムのインストールやバージョン管理が必要）
• Go製バイナリと比較してCLIの起動が遅い

どちらを選ぶべきか

aws-vaultが向いているケース

• シンプルなIAM + MFA構成で、少数のアカウントを管理
• チームで既にaws-vaultを使っている（切り替えコストを避けたい）
• 最小限の依存でシングルバイナリを好む

Grantedが向いているケース

• 複数プロジェクト × 複数環境（stg/prod）のマルチアカウント運用
• AWS SSO / IAM Identity Centerを使用（または移行予定）
• 頻繁にアカウントを切り替える開発ワークフロー
• 複数アカウントのAWSコンソールを同時に開きたい

移行について

aws-vaultからGrantedへの移行は比較的簡単です。~/.aws/configの設定はそのまま共用できます。ただし、aws-vaultのKeychainからGrantedのセキュアストレージへ直接クレデンシャルを移行する方法はありません。IAMコンソールで新しいアクセスキーを作成し、granted credentials addで登録するのが確実です。移行後に古いキーを無効化→削除してください。両方のツールを同時にインストールしておくことも可能です。

Claude Codeとの連携

aws-vaultやGrantedは、Claude CodeのようなAIコーディングエージェントと組み合わせることで、AWS操作をさらに効率化できます。Claude Codeの「スキル」機能を使えば、クレデンシャル管理ツールをラップした安全なAWS操作ワークフローを構築できます。

非インタラクティブ環境での制約

Claude Codeはコマンドを非インタラクティブに実行するため、サブシェルに「入って作業する」ことができません。各コマンドが独立したプロセスとして実行されるため、サブシェル内の環境変数は次のコマンドに引き継がれません。

# ✗ サブシェル方式は使えない
aws-vault exec my-profile          # サブシェルが開くが、次のコマンドは別プロセス
aws s3 ls                            # ← クレデンシャルが存在しない

# ✓ コマンドラッパー方式を使う
aws-vault exec my-profile -- aws s3 ls  # 1コマンドで完結

同様に、Grantedのassumeはシェルの環境変数をセットしますが、Claude Codeでは各コマンドが新しいシェルプロセスで実行されるため、assumeでセットした環境変数は次のコマンドには残りません。

そのため、非インタラクティブ環境では以下の2つの方法が使えます。

1. exec方式 — aws-vault exec / granted exec でコマンドをラップする。毎回プレフィックスが必要だが、どちらのツールでも使える
2. credential_process方式 — AWS CLIが自動的にGrantedを呼び出す。通常のawsコマンドがそのまま動作する（Granted限定）

Grantedのcredential_processはAWS CLI/SDKが必要に応じて自動的にクレデンシャルを取得するため、スキル内のスクリプトで--profileを指定するだけで認証が透過的に行われます。

スキルの構成例

以下は、aws-vaultを使ったBedrock Knowledge Base運用スキルの例です。

.claude/skills/bedrock-ops/
├── SKILL.md              # スキル定義（コマンド一覧、安全ルール）
├── scripts/
│   ├── session.py        # セッション管理（check / create / ensure）
│   ├── aws_safe.py       # 安全ガード付きAWSコマンド実行
│   └── setup_project.py  # プロジェクト初期設定
├── aws-project.json      # プロファイル、アカウントID、安全ルール（コミット対象）
└── aws-project.local.json # TOTPシークレット（.gitignore対象）

ポイントは、クレデンシャル管理ツールが認証を担当し、スキルがワークフローと安全ガードレールを担当するという分離です。

安全ガードレールの設計

AIエージェントにAWS操作を委譲する場合、以下のような安全ルールをスキルに組み込むことが重要です。

# 実行例: S3にファイルをアップロード
/bedrock-ops s3 sync ./data s3://my-bucket/knowledge-base/

# → まずドライランが実行され、変更内容が表示される
# → ユーザーが確認後、--execute で本番実行

aws-vaultのexecやGrantedのassumeでセッションを確立した上で、スキルが安全な範囲でAWSリソースを操作する構成により、AIエージェントに安心してAWS操作を委譲できます。

まとめ

aws-vaultとGrantedはどちらもAWSクレデンシャルをKeychainに安全に保存し、一時認証情報で運用できる優れたツールです。

• セキュリティ面は同等: どちらもKeychain暗号化 + STS一時認証
• 日常のワークフローに差が出る: サブシェル方式（aws-vault）vs 環境変数エクスポート方式（Granted）
• マルチアカウントではGrantedに軍配: アカウント切り替えの手軽さ、ファジー検索、複数コンソール同時ログインが便利

今からセットアップするなら、特にマルチアカウント環境ではGrantedをお勧めします。既にaws-vaultを使っていて単一アカウントであれば、無理に移行する必要はありません。

参考

• aws-vault GitHub
• aws-vault USAGE.md
• Granted 公式サイト
• Granted ドキュメント
• Granted Getting Started