aws login (CLI v2.32) で S3 クライアントを動かす：CyberduckとrcloneのCredential解決経路を比較する

TL;DR

• 2025年11月リリースの aws login は、認証情報を ~/.aws/login/cache/ に保存する新方式
• 既存のS3クライアントの多くは、この新しい保存場所を直接読まない設計
• AWSが公式に提示している回避策は credential_process を介したブリッジ
• Cyberduck 9.4.1 (stable, 2026-03-03) は credential_process 未対応、ただしnightly snapshotでは対応済み（#11664 として実装、次の安定版で来る見込み）
• rclone は AWS SDK for Go v2 を使うため credential_process を解釈し、env_auth = true で素直に動く
• どちらにしても、~/.aws/config 側にブリッジ用プロファイルを定義する必要がある

検証日: 2026-05-09

---

1. aws login とは何か

AWS CLI v2.32.0以降で利用可能な、AWSマネジメントコンソールのサインイン情報をそのまま使ってブラウザ経由で短期クレデンシャルを取得するコマンドです。長期アクセスキーを発行・保管する必要がなくなり、IAM Identity Centerを設定していないチームでも、短期クレデンシャル運用に移行できます。

$ aws --version
aws-cli/2.32.0 Python/3.13.4 Darwin/24.6.0 source/arm64

$ aws login
# ブラウザが立ち上がり、AWSコンソールにサインイン
# 認証完了後、短期クレデンシャルがローカルにキャッシュされる

セッションの有効期限は最大12時間です。

2. クレデンシャルの保存場所が世代ごとに違う

aws login を扱うときに最初に押さえる必要があるのは、AWSがクレデンシャルの保存場所を世代ごとに増やしてきたという事実です。

世代	認証方式	保存場所	設定ファイルでの目印
第1世代	静的アクセスキー	~/.aws/credentials	aws_access_key_id
第2世代	IAM Identity Center (旧SSO)	~/.aws/sso/cache/ と ~/.aws/cli/cache/	sso_session
第3世代	aws login (console credentials)	~/.aws/login/cache/	login_session

各S3クライアントが「aws login に対応しているか」は、実質的に「~/.aws/login/cache/ を直接読むか、credential_process を介して間接的に取得できるか」という問いに帰着します。

3. AWS公式の回避策：credential_process ブリッジ

AWSは公式ブログ "Simplified developer access to AWS with 'aws login'" で、新方式に未対応のツール向けの回避策として credential_process の利用を提示しています。~/.aws/config に「クレデンシャルが必要になったらこのコマンドを呼び出して取得せよ」と書く方式です。

# ~/.aws/config

[profile signin]
login_session = arn:aws:iam::123456789012:user/your-username
region = ap-northeast-1

[profile bridge]
credential_process = aws configure export-credentials --profile signin --format process
region = ap-northeast-1

bridge プロファイルを参照すると、AWS CLIが内部的に signin プロファイルから短期クレデンシャルを取得し、JSON形式で返します。これを credential_process を解釈できる任意のツールが受け取れる、という仕組みです。

ただし credential_process を解釈できるかどうかは、ツール側のSDKバージョンや実装に依存します。

4. Cyberduckの対応状況（2026-05-09時点）

Cyberduckについて事実関係を整理します。

4-1. 安定版 9.4.1 (2026-03-03)

Cyberduckの公式changelog を見る限り、9.4.1までの安定版に credential_process のサポートは入っていません。

aws login を9.4.1で使うには、以下のいずれかの選択肢になります。

選択肢A: aws configure export-credentials --format env-no-export で取得した短期クレデンシャルを、手動で ~/.aws/credentials の特定プロファイルに書き出す。Cyberduckは aws_access_key_id / aws_secret_access_key / aws_session_token をプレーンに読めるので、これで動きます。ただしトークン期限切れ（最大12時間）ごとに再書き込みが必要です。

# 取得 → 書き出しを自動化するシェル関数の例
refresh_aws_for_cyberduck() {
  eval "$(aws configure export-credentials --profile signin --format env-no-export)"
  cat > ~/.aws/credentials.cyberduck <<EOF
[cyberduck]
aws_access_key_id=$AWS_ACCESS_KEY_ID
aws_secret_access_key=$AWS_SECRET_ACCESS_KEY
aws_session_token=$AWS_SESSION_TOKEN
EOF
}

選択肢B: SSO経由のCyberduck設定パターン（aws sso login → aws sts get-caller-identity で ~/.aws/cli/cache/ をseedする方式）を流用する。ただしこれは aws sso login 用の運用であり、aws login で取得したトークンとは別系統のキャッシュなので、運用としては筋が通らない選択です。

4-2. nightly / snapshot ビルド

一方、nightly changelog を確認すると、次のリリースに向けた開発トランクには以下の機能がすでに入っています。

Feature Connect with credentials from credential_process configuration directive in ~/.aws (S3) (#11664)

Issue #11664 は2021年5月に立てられた credential_process サポート要望で、5年越しの実装です。当然 Issue #17848（2026年1月）はその duplicate として close されています。

つまり、Cyberduckで aws login をクリーンに扱いたい場合、現時点の選択肢は次のマイナーリリースを待つか、nightlyビルドを使うかになります。本番運用でnightlyを使うのは推奨されないため、安定版を待つのが基本路線です。

5. rclone での実装

rcloneは内部で AWS SDK for Go v2 を採用しており、credential_process を含む各種AWS認証方式を解釈します。rclone公式ドキュメント にも、env_auth = true を指定することで「AWS CLIや他のAWS SDKがサポートする全認証方式が利用できる」と明記されています。

5-1. 設定ファイル

~/.aws/config 側に aws login 用とブリッジ用のプロファイルを定義します（前述の例と同じ）。

# ~/.aws/config

[profile signin]
login_session = arn:aws:iam::123456789012:user/your-username
region = ap-northeast-1

[profile rclone-bridge]
credential_process = aws configure export-credentials --profile signin --format process
region = ap-northeast-1

rclone側のリモート設定は以下のようになります（rclone config コマンドで対話的に作るか、~/.config/rclone/rclone.conf に直書きします）。

# ~/.config/rclone/rclone.conf

[s3-aws]
type = s3
provider = AWS
env_auth = true
profile = rclone-bridge
region = ap-northeast-1

5-2. 動作確認

# まず aws login で短期クレデンシャルを取得
$ aws login --profile signin

# rclone がブリッジ経由でクレデンシャルを取得できるか確認
$ rclone lsd s3-aws:
          -1 2026-04-15 10:32:14        -1 my-bucket-1
          -1 2026-04-20 14:21:08        -1 my-bucket-2

トークン期限が切れたら aws login --profile signin を打ち直すだけで、rclone側もブリッジ経由で新しいクレデンシャルを自動的に取り直します。~/.aws/credentials への手動書き出しは不要です。

5-3. Web GUIで使う

CLIに抵抗があるなら rclone gui でWebベースのGUIが立ち上がります。

$ rclone gui
NOTICE: Serving remote control on http://127.0.0.1:5572/
NOTICE: Serving GUI on http://127.0.0.1:5572/...

ブラウザが自動で開き、ログイン後はファイルブラウザ・アップロード・ダウンロード・同期などの基本操作がGUIから可能です。rclone gui は rclone rcd --rc-web-gui のシンタックスシュガーで、内部的には同じものです。

ただし rclone gui のUIは活発に磨かれているわけではなく、より洗練された体験を求める場合は Rclone UI のような第三者プロジェクトのデスクトップアプリも検討の余地があります。

5-4. ファイルシステムマウント

rclone mount を使えば、S3バケットをローカルドライブとしてマウントできます。Mountain Duckの代替として機能します。

# macOS（要 macFUSE）
$ rclone mount s3-aws:my-bucket /Volumes/s3-aws --vfs-cache-mode writes

# Windows（要 WinFsp）
$ rclone mount s3-aws:my-bucket S: --vfs-cache-mode writes

5-5. はまり処

rcloneのWebGUIからAWS環境を構築しようとしてもうまくいきません。完全にWebGUIの仕組みの想定を越えている模様。なので、GUIを使うにしてもCUIと同じように先にrclone.confを自力で作ってからアクセスする必要があります。

6. まとめ

aws login という新コマンドは、ローカル開発のセキュリティを一段引き上げる良い設計です。一方で、保存場所が新設されたことで、サードパーティツールの対応にラグが生じます。

ツール	対応状況 (2026-05-09)	経路
AWS CLI	ネイティブ対応	~/.aws/login/cache/ 直読み
AWS SDK 各種	最新版でネイティブ対応	同上
rclone	動作する	credential_process ブリッジ経由
Cyberduck 9.4.1 (stable)	動作しない	手動エクスポートが必要
Cyberduck nightly	動作する	credential_process ブリッジ経由

ツールを選ぶ際は、現時点の機能だけでなく、AWS認証方式の世代交代に対する追従速度も判断材料にすると良さそうです。新しい認証方式が出るたびに credential_process 経由で動かせるツールは、結果的に長持ちします。

参考リンク

• Login for AWS local development using console credentials - AWS Documentation
• Simplified developer access to AWS with 'aws login' - AWS Security Blog
• Cyberduck Changelog
• Cyberduck nightly changelog
• Cyberduck Issue #11664: Support credentials_process in ~/.aws/credentials profile
• rclone S3 documentation
• rclone gui documentation