AWSume（オースム）とは？インストール・MFA設定と開発終了後のAWS CLI移行

AWSume（オースム）は、AWSの複数アカウント・複数IAMロールをコマンド1つで切り替えるCLIツールです。名前は「AWS Assume Made Awesome」に由来し、AWSコンサルティング企業のTrek10がMITライセンスで公開してきました。ただし2026年9月、開発元はGitHubのREADMEで保守の終了を告知し、AWS CLIへの移行を勧めています。この記事では、AWSumeの仕組み・インストール・MFAの使い方に加えて、今から導入してよいか、既存の利用者がAWS CLI v2の標準機能へどう移るかまでを扱います。

まとめ：AWSumeの要点

• 正体：IAMロールの引き受け（AssumeRole）とMFA認証をまとめ、一時認証情報を実行中のシェルの環境変数へ書き込むPython製CLI。Unix系ではドットソースするエイリアスが必須。
• 現状：2026-09-10に保守終了を告知。PyPIでpip installして入る最新版は2024-01-05公開の4.5.4のままで、今後の修正は期待できない。
• 強み：MFA認証済みのセッションを最大12時間キャッシュし、既定では1時間で切れるロール認証情報をMFAの再入力なしで取り直せる。
• 判断：新規導入は勧めない。AWS CLI v2（2.9.0以降のexport-credentials、2.32.0以降のaws login、IAM Identity Centerのaws sso login）で大半を置き換えられる。
• 使い続ける場合：既存の~/.aws/configはそのままAWS CLIでも読めるので、移行は設定の書き換えより運用手順の置き換えが中心になる。

AWSumeの仕組みと開発終了の現状

AssumeRoleとMFAを1コマンドにまとめる仕組み

aws sts assume-roleを直接呼んで別アカウントのロールを使う場合は、返ってきたキー・シークレット・セッショントークンを手でexportする必要があります（AWS CLIのロールプロファイルに任せる方法は後半の移行章で扱います）。AWSumeはこれをawsume <プロファイル名>の1行にまとめ、次の環境変数を今のシェルへ設定します。以降のAWS CLIやSDKは--profileを付けなくてもこの認証情報で動きます。

子シェルを立ち上げるaws-vault execと違い、AWSumeは親シェル自身の環境変数を書き換えます。子プロセスからは親の環境を変えられないため、.（source）で読み込ませるエイリアスが必要になります。

2026年9月の保守終了告知とPyPIの配布状況

trek10inc/awsumeのREADMEは冒頭に「This project is no longer actively maintained.」と掲げ、AWS CLIがプロファイル切替・認証情報管理・SSOを標準で扱えるようになったことを理由に、AWS CLIへの移行を勧めています。リポジトリとPyPIのパッケージはそのまま残り、フォークして開発を続けることは認められています。

注意したいのは版の食い違いです。終了告知のコミット（2026-09-10、件名「chore: deprecate project and bump version to 4.5.6」）でソースの版は4.5.6に上がり、終了メッセージも埋め込まれましたが、PyPIのawsumeで安定版として配布されているのは2024-01-05公開の4.5.4です（2026-10-27時点）。pip install awsumeで入るのは4.5.4で、告知メッセージは表示されません。今後Pythonやboto3の更新で不具合が出ても、本家での修正は期待できません。

AWSumeのインストールとエイリアス設定

pipx／pipによるAWSumeの導入

公式のQuick Startによると、前提はPython 3.5以上で、推奨の導入方法はpipxです。Homebrewは公式にはサポートされていません。

# 推奨：pipx（ツールごとに隔離した環境へ入れる）
pipx install awsume

# もしくは pip
pip install awsume

# 追加機能（SAML・プロファイル名のあいまい一致・コンソール表示）
pipx install "awsume[saml,fuzzy,console]"

シェル別のエイリアス設定

Bash／Zshでは、次のエイリアスがないと環境変数が今のシェルに残りません。Fishは専用スクリプトawsume.fishを読み込む別のエイリアスを使います。

# Bash／Zsh
alias awsume=". awsume"

# Fish
alias awsume="source (which awsume.fish)"

インストール時に~/.bash_profileや~/.bashrcへの自動追記が試みられるので、終わったらターミナルを開き直すかログインスクリプトを読み込み直します。自動追記を止めたいときはAWSUME_SKIP_ALIAS_SETUP=trueを付けてインストールし、後からawsume-configureで設定できます。配布物にはBash／Zsh用のほかawsume.fish・awsume.ps1・awsume.batが含まれ、Fish・PowerShell・Windowsのコマンドプロンプトでも動きます。

AWSumeによるロールの切り替え

~/.aws/configのロールプロファイル設定

AWSume自身の設定（既定のリージョンやロールの秒数など）は~/.awsume/config.yamlに置かれますが、プロファイルは~/.aws/configと~/.aws/credentialsをそのまま読みます。前提として、source_profileに指定するプロファイル（下の例ではdefault）に長期のアクセスキーがあり、そのIAMユーザーに対象ロールのsts:AssumeRoleが許可され、ロールの信頼ポリシーもそのユーザーを受け入れている必要があります。ロールを引き受けるプロファイルにはrole_arnとsource_profileを書きます。

# ~/.aws/config
[profile dev]
source_profile = default
role_arn = arn:aws:iam::123456789012:role/DevRole
mfa_serial = arn:aws:iam::111122223333:mfa/my-user
region = ap-northeast-1

mfa_serialはロールのプロファイルに書けば、AWSumeもAWS CLIも読みます（AWSumeは無ければsource_profile側を見ます）。委託先や他社のアカウントのロールを引き受けるときは、external_idも同じプロファイルに書けます。外部IDを付けたロールの作り方はAWS運用代行の受け入れ設定：委託先IAMロールと外部ID・監視通知をCLIで準備する手順で扱っています。

切り替え・確認・解除のコマンド

awsume dev          # devの一時認証情報を今のシェルへ設定
awsume -l           # 使えるプロファイルの一覧
awsume dev -s       # 別のシェルへ貼るためのexport文を表示
echo $AWSUME_PROFILE
awsume -u           # AWS関連の環境変数をクリア（--unset）

環境変数を今のシェルへ書き込む方式なので、同じシェルで本番と検証を続けて扱うと前の設定が残ります。切り替える前にawsume -uを挟むか、ターミナルのタブを環境ごとに分けてください。

MFAトークンの入力とキャッシュ設定

mfa_serialとセッションの12時間キャッシュ

プロファイルにmfa_serialを書くと、実行時にMFAコードを求められます。公式の概要ページによると、AWSumeは元のプロファイルでget-session-tokenを呼んで12時間有効の認証情報を取り、~/.awsume/cache/に保存します。そのうえでassume-roleを呼ぶので、1時間でロール認証情報が切れても、AWSumeを再実行すればMFAコードを入れ直さずに新しい認証情報を取れます。これがAWS CLIの標準動作との最大の違いです。

MFAはTOTPコードを入力する方式が前提です。公式ドキュメントは仮想MFAデバイスでの利用を案内しており、FIDO/U2Fのセキュリティキーは、AWSumeのMFAコード入力には使えません。ロール認証情報の長さは--role-durationで最大43,200秒（12時間）まで指定できますが、ロール側の最大セッション時間を超えては取れません。

1Password CLIによるMFAコードの自動入力

毎回スマートフォンを開く手間を省くなら、--mfa-tokenに1Password CLIのop item get --otpの出力を渡します。

awsume dev --mfa-token "$(op item get "AWS Account" --otp)"

この指定を毎回書かずに済ませる第三者製のawsume-1password-plugin（PyPIの最新は1.2.5）もあります。MFA入力の手間は確かに減りますが、本体の保守が止まったため、今後のPythonや1Password CLIの更新との互換性は自分で確かめ続けることになります。新たに組むなら次章のAWS CLI側の仕組みを先に検討してください。

autoawsumeによるロール認証情報の自動更新

awsume dev -a（--auto-refresh）を付けると、バックグラウンドでautoawsumeが起動し、元の認証情報が有効な間（最長12時間）ロール認証情報を取り直し続けます。止めるときはawsume -k（--kill-refresher）です。

主なオプションとプラグイン

4.4.0でロールからロールへの多段の引き受け（ロールチェーン）、4.5.0でcredential_processを持つプロファイルにも対応しました。-oで書き出したプロファイルは、AWSumeを知らないツールからも--profileで使えます。

AWS CLI v2の標準機能への移行手順

AWSumeの機能とAWS CLIの対応表

AWS CLIのロールプロファイルとMFA再入力の間隔

前章の[profile dev]は、書き換えずにAWS CLIでも読めます。AWS CLIのロール設定のドキュメントによると、ロールのプロファイルを指定するとAWS CLIが一時認証情報を取得して~/.aws/cli/cacheに保存し、失効すると自動で取り直します。

awsume -u               # AWSumeが入れたキーを先に消す
export AWS_PROFILE=dev
aws sts get-caller-identity   # 初回とロール認証情報の失効時にMFAコードを求められる

AWSumeが設定したAWS_ACCESS_KEY_IDなどが残っていると、AWS CLIの優先順位ではそちらがAWS_PROFILEより先に使われ、移行したつもりで古い認証情報のまま動きます。AWSumeを削除した後なら、新しいシェルを開いてから実行してください。なおAWS_PROFILEと--profileを両方指定した場合は--profileが優先されます。

違いはMFAの間隔です。AWS CLIはMFA済みのセッションを12時間保持する仕組みを持たないため、ロール認証情報が切れるたびにMFAコードを求めます。毎時の入力が負担なら、ロールの最大セッション時間（1〜12時間で設定）を延ばし、プロファイルのduration_seconds（既定3,600秒・下限900秒）を上げるか、次のIAM Identity Centerへ寄せるのが筋です。なお、ロールからロールを引き受けるロールチェーンのセッションはSTSの仕様で最大1時間に制限され、延ばせません。

export-credentialsによる環境変数への書き出し

プロファイルを解釈しない自作スクリプトや、認証情報を環境変数で渡す必要があるコンテナ実行などでは、AWS CLI 2.9.0で入ったaws configure export-credentialsがAWSumeの代わりになります。

# Bash／Zsh
eval "$(aws configure export-credentials --profile dev --format env)"

# PowerShell
aws configure export-credentials --profile dev --format powershell | Invoke-Expression

--formatはenv・env-no-export・powershell・windows-cmd・fish（2.33.8で追加）・processから選べます。processはcredential_processの形式で出すため、別のツールの設定に組み込めます。書き出した環境変数は実行した時点の値で、autoawsumeのように更新はされません。期限が切れたら同じコマンドを実行し直します。

IAM Identity Center・aws loginへの認証方式の移行

組織でIAM Identity Centerを使っているなら、aws configure ssoでアカウントとロールの組み合わせごとにプロファイルを作り、aws sso loginでまとめてログインする形が最も手間がかかりません。長期のアクセスキーを手元に置く必要もなくなります。設定の書き方はaws sso loginの設定手順：aws configure ssoの書き方・期限切れエラー・デバイスコード認可にまとめています。

Identity Centerを使わないIAMユーザーでも、2025年11月公開のAWS CLI 2.32.0で入ったaws loginを使えば、マネジメントコンソールのサインインでCLIの一時認証情報を取れます。前提として、IAMの側でAWS管理ポリシーSignInLocalDevelopmentAccessか同等の権限を付けておく必要があります。AWSのドキュメントによると、この認証情報は最長12時間自動で更新されます。手元のAWS CLIが古い場合は、AWS CLIのインストールと運用｜OS別の導入手順・v2の設定・SSO認証・v1サポート終了への移行の手順で更新してから試してください。

AWSumeを使い続ける判断と見送るケース

結論として、新規導入は見送り、既存の利用者は次のアカウント追加や端末の入れ替えを機に移行するのが妥当です。AWSumeは4.5.4のまま配布が続いていますが、AWS側の認証方式の追加に追随する修正は期待できません。条件ごとの判断は次のとおりです。

• MFAの毎時入力を避けたいIAMユーザー運用：AWSumeの12時間キャッシュが効く数少ない場面。移行先はaws loginか、Identity Centerの導入。
• CI/CDや共有サーバー：AWSumeは対話的なMFA入力と個人の長期キーを前提にした道具で、無人実行には向かない。GitHub ActionsのOIDC連携などでロールを直接引き受ける。
• FIDO/U2Fのセキュリティキーを必須とする組織：AWSumeはTOTPのコード入力が前提で合わない。
• 長期キーを平文で置きたくない場合：OSのキーチェーンに保管するaws-vaultが選択肢になるが、99designsの本家も放棄を告知しており、保守が続いているのはByteNessのフォーク（2026-10-23にv7.17.2）。ブラウザで複数アカウントを開く用途ならfwd:cloudsecが保守するGrantedも候補になる。

アカウントが増えて認証の設計そのものを見直す段階なら、IAM Identity Centerの導入から権限セットの設計までをまとめて扱うAWS・Google Cloud・Azureのインフラ構築支援も相談先になります。踏み台を使わずにEC2へ入る構成はSSM Agentとは？役割・インストール・バージョン確認と自動更新の手順【2026年版】が参考になります。

よくある質問（FAQ）

AWSumeの意味・読み方は？

「AWS Assume Made Awesome」を縮めた造語で、英語のawesomeにかけて「オースム」と読まれます。AssumeRole（ロールの引き受け）を快適にする、という意味です。

AWSumeのインストール方法は？

Python 3.5以上を用意し、pipx install awsume（推奨）またはpip install awsumeで入れます。Unix系ではalias awsume=". awsume"の設定が必要です。入るのはPyPIの4.5.4です。

AWSumeは開発終了後も使えますか？

2026年10月時点で、PyPIから4.5.4を入手できます。ただし2026-09-10に保守終了が告知されており、不具合やAWS側の変更への対応は期待できません。新たに組むならAWS CLI v2のexport-credentialsやaws sso loginを使ってください。

aws-vaultとの違いは？

AWSumeは~/.aws/credentialsの認証情報を使い、今のシェルの環境変数を書き換えます。aws-vaultは長期キーをOSのキーチェーンに保管し、子プロセスに一時認証情報を渡します。どちらも本家の保守は止まっており、aws-vaultはByteNessのフォークが保守を続けています。

AWSumeのGitHubリポジトリはどこですか？

Trek10のtrek10inc/awsumeで公開され、ドキュメントは公式サイトawsu.meにあります。リポジトリはアーカイブされておらず、READMEに保守終了の告知が載っています。

関連記事

• AWS CLIのインストールと運用｜OS別の導入手順・v2の設定・SSO認証・v1サポート終了への移行
• aws sso loginの設定手順：aws configure ssoの書き方・期限切れエラー・デバイスコード認可
• AWS運用代行の受け入れ設定：委託先IAMロールと外部ID・監視通知をCLIで準備する手順
• SSM Agentとは？役割・インストール・バージョン確認と自動更新の手順【2026年版】