はじめに
こんにちは、KUDs です。
この記事では、Mac に AWS CLI をインストールして、コマンドから AWS を操作できる状態にするところまでを解説します。
所要時間は20分ほど、費用はかかりません。
ひとつ、この記事の特徴をお伝えしておきます。
前回非推奨とお伝えした、アクセスキーを作らずに設定します。
AWS CLI の設定というと aws configure にアクセスキーを貼り付ける手順が定番で、検索して出てくる記事のほとんどがそう書かれています。
ただ、2025年11月に aws login という新しい方法が追加され、AWS 公式の推奨も入れ替わりました。こちらのほうが安全で、しかも手順が短いです。
とはいえ新しい機能なので、環境によってはうまくいかないこともあります。
その場合に備えて、従来のアクセスキーを使う手順も後半に載せてあります。 どちらでも先に進めるようにしてありますので、安心して読み進めてください。
この記事について
この記事は、AWS を初めて触る方向けのシリーズの1本です。
シリーズ全体の地図と読む順番は、ロードマップにまとめてあります。
この記事は、前回までの3つが終わっていることが前提です。
ひとつめは、作業用の IAM ユーザーを作ってあること。
ふたつめは、Homebrew が入っていること。この記事ではこれを使ってインストールします。
みっつめは、 Visual Studio Code と Claude Code for VSCode が入っていること。ぶっちゃけなくてもいいですが、VSCode に慣れるのも含めてます。
なお、Homebrew を入れていない方や、macOS のバージョンが古くて入れられない方向けの手順も用意してありますので、そのまま読み進めていただいて大丈夫です。
AWS CLI とは何か
AWS CLI（コマンドラインインターフェイス）は、ターミナルから AWS を操作するための公式コマンドです。
これまでマネジメントコンソール（Web の管理画面）でボタンを押してやっていたことを、aws で始まるコマンドで実行できるようになります。
aws s3 ls
たとえばこれは「S3 のバケット一覧を表示する」コマンドです。
なぜ CLI を入れるのか
「画面から操作できるなら、コマンドは要らないのでは」と思うかもしれません。
理由は2つあります。
1つめは、作業を記録・再現できるからです。
画面のクリックは記録に残りませんが、コマンドは文字として残ります。同じ環境をもう一度作りたいとき、コマンドが残っていれば貼り付けるだけで済みます。
2つめが、このシリーズにとって本命の理由です。
Claude Code のような AI に AWS を操作させるには、CLI が必要だからです。
AI がやっているのは、魔法でも特別な連携でもありません。
あなたの Mac にインストールされた aws コマンドを、あなたの代わりに組み立てて実行しているだけです。
つまり、ここで CLI を入れておかないと、このあとの回で Claude Code が何もできません。
逆に言えば、ここさえ終われば AI に AWS を任せる準備が整います。
手順1: AWS CLI をインストールする
ここからはターミナルアプリではなく、VSCode 内のターミナルを使いましょう。
VSCode を開いて、Command + J (Windows の場合は Control + J)でターミナルを開けます。
brew install awscli
これで完了です。
以下のコマンドを実行して、インストールが完了しているか確認しましょう。
which -a aws
以下のような出力が出れば OK です。
/opt/homebrew/bin/aws
「aws というコマンドは /opt/homebrew/bin/ というディレクトリ(フォルダ)に配置されてますよ。」という意味です。
お気づきの方もいるかも知れませんが、Claude にたった一言「Brew で AWS CLI をインストールして」と言えば終わりです。（前回までに Claude も Homebrew も導入済なので）
ただ、今回は「本来ならこういう手順でパッケージをインストールするんだな〜」を体感してもらうために敢えてコマンド実行してもらってます。
手順2: バージョンを必ず確認する
この手順は飛ばさないでください。
aws --version
こんな出力が返ってきます。
aws-cli/2.36.24 Python/3.13.4 Darwin/24.5.0
先頭の数字が 2.32 以上であることを確認してください。
なぜこの確認が必要かというと、この記事で使う aws login という機能が、AWS CLI 2.32.0 以上でないと使えないからです。
そしてもうひとつ理由があります。
AWS の公式インストール手順には、次のように書かれています。
Because AWS doesn’t maintain third-party repositories, we can’t guarantee that they contain the latest version of the AWS CLI.
（AWS はサードパーティのリポジトリを管理していないため、そこに最新版の AWS CLI が含まれることを保証できません）
つまり Homebrew 版は AWS が公式に管理しているものではなく、将来的にバージョンが古い可能性があるということです。
執筆時点（2026年8月）では 2.36.24 が入るので問題ありませんが、念のため自分の目で確認しておくのが確実です。
バージョンが古かった場合
まず更新を試してください。
brew upgrade awscli
それでも 2.32.0 未満だった場合は、次の「Homebrew を使わない場合」の手順で入れ直してください。
Homebrew を使わない場合
Homebrew を入れていない方、macOS が Sonoma 未満の方、Homebrew 版が古かった方は、AWS 公式のインストーラーを使ってください。
- 以下の URL をブラウザで開くと、
AWSCLIV2.pkgのダウンロードが始まります - ダウンロードした
AWSCLIV2.pkgをダブルクリック - 画面の指示に従って進める（Mac のパスワードを求められます）
こちらは AWS 自身が配布しているものなので、常に最新版が入ります。
インストール後は、同じく aws --version で確認してください。
インストール方法の詳細は公式ドキュメントにあります。
Windows をお使いの方へ
Windows でもほぼ同じ手順で進められます。違うのはインストール方法だけです。
インストール
以下からインストーラーをダウンロードしてダブルクリックしてください。
https://awscli.amazonaws.com/AWSCLIV2.msi
PowerShell から入れる場合はこちらです。
irm https://awscli.amazonaws.com/v2/install.ps1 | iex
インストール後、コマンドプロンプトを開き直してから aws --version で確認します。
aws login 以降の手順は Mac とまったく同じです
手順3: aws login でサインインする
ここがこの記事の主役です。
その前に：なぜアクセスキーを作らないのか
前回の記事でも触れましたが、改めて整理しておきます。
アクセスキーは「長期の認証情報」で、有効期限がありません。
一度作ると、自分で無効化するまでずっと使えてしまいます。そして ~/.aws/credentials というファイルに平文のまま保存されます。
つまり、うっかり GitHub に上げたり、画面共有で映してしまったりすると、そのまま悪用されます。しかも気づくまで有効なままです。
AWS 公式の認証方法の一覧は「推奨順」に並んでいるのですが、2026年8月時点でこうなっています。
| 順位 | 方法 | 評価 |
|---|---|---|
| 1位 | コンソール認証情報（aws login） | (Recommended) 推奨 |
| … | … | … |
| 6位 | IAM ユーザーの長期認証情報（アクセスキー） | (Not recommended) 非推奨 |
AWS 自身が「非推奨」と書いているものを、わざわざ最初に教える理由はないと考えました。
なので、この記事では aws login を使います。
事前準備: IAM ユーザーに権限を1つ追加する
aws login を IAM ユーザーで使うには、SignInLocalDevelopmentAccess というポリシーが必要です。
前回作った作業用ユーザーに既に追加済のはずです。もしこの記事から始められた人は追加しておきましょう。
- マネジメントコンソールで「IAM」を開く
- 左メニューの「ユーザー」→ 前回作ったユーザーを選択
- 「許可を追加」→「直接ポリシーをアタッチする」
SignInLocalDevelopmentAccessを検索してチェック- 「許可を追加」
このポリシーが許可するのは「ブラウザ経由で認証して、一時的な認証情報を受け取ること」だけです。
AWS のリソースを操作する権限は含まれていないので、付けても権限が広がりすぎる心配はありません。
aws login を実行する
準備ができたら、ターミナルで実行します。
aws login
初回はリージョンを聞かれます。 日本から使うなら東京リージョンを入力してください。
AWS Region [us-east-1]: ap-northeast-1
すると、自動的にブラウザが開きます。
そこで、いつもマネジメントコンソールにログインするときと同じようにサインインしてください。
IAM ユーザーの場合は、アカウント ID（またはエイリアス）とユーザー名、パスワードを使います。
サインインが完了すると、使う認証情報を選ぶ画面が表示されます。
選んだらターミナルに戻ってください。こんなメッセージが出ていれば成功です。
Logged in with role `arn:aws:sts::012345678910:user/iam-user`, and configured profile
`default` to use `ap-northeast-1`. This session will expire on ...
もしくは以下のようなメッセージです。
Updated profile default to use arn:aws:iam::123456789012:user/my-dev-user credentials.
これで設定は完了です。 アクセスキーは1つも作っていません。
何が保存されたのかを見てみる
せっかくなので、何が起きたのかを確認しておきましょう。
cat ~/.aws/config
中身はこれだけです。
[default]
login_session = arn:aws:iam::012345678910:user/my-dev-user
region = ap-northeast-1
パスワードもアクセスキーも入っていません。「誰としてログインしたか」と「どのリージョンを使うか」だけです。
実際の認証情報は ~/.aws/login/cache に一時的なものとして保存され、15分ごとに自動で更新されます。
セッションは最大12時間で切れます
ひとつだけ、知っておいてほしいことがあります。
このログインは最大12時間で切れます。
翌日にターミナルを開いて aws コマンドを実行すると、エラーが出ることがあります。
壊れたわけではないので、慌てずにもう一度実行してください。
aws login
これだけで復活します。 ブラウザが開くので、またサインインするだけです。
「毎回ログインが必要なんて面倒」と思われるかもしれませんが、これは面倒なのではなく、そういう仕組みだから安全なのだと考えてください。パソコンを盗まれても、12時間後には何もできなくなります。
作業を終えるとき
明示的にサインアウトしたい場合は、こうします。
aws logout
キャッシュされていた認証情報が削除されます。
共用のパソコンを使っている場合や、作業が一区切りついたときに実行しておくと安心です。
aws login の詳しい仕様は公式ドキュメントにまとまっています。
手順4: 動作確認をする
設定できたか確認します。
自分が誰として操作できるのかを見る
aws sts get-caller-identity
こんな結果が返ってくれば成功です。
{
"UserId": "AIDXXXXXXXXXXXXXXXXXX",
"Account": "012345678910",
"Arn": "arn:aws:sts::012345678910:user/my-dev-user"
}
Arn の末尾が、前回作った IAM ユーザー名になっていることを確認してください。
ルートユーザーになっていたら要注意です。 前回の記事に戻って、作業用ユーザーを作るところからやり直してください。
認証情報がどこから来ているかを見る
このコマンドは覚えておくと、後々とても役に立ちます。
aws configure list
NAME : VALUE : TYPE : LOCATION
profile : (not set) : None : None
access_key : ****************FQMW : login :
secret_key : ****************2ZTp : login :
region : ap-northeast-1 : config-file : ~/.aws/config
見てほしいのは Type の列です。
ここが login になっていれば、aws login の認証情報が使われています。
もしここが shared-credentials-file になっていたら、別の認証情報が優先されています。あとで説明するトラブルの原因になるので、覚えておいてください。
試しに Claude Code に聞いてみる
パネルを開いて、こう入力してみてください。
AWS を触ってみたいんですが、今 AWS CLI は設定できてますか？
AWS CLI は既に設定されています！ ✓
- AWS CLI バージョン: 2.36.24
- アクセスキー: 設定済み ✓
- シークレットキー: 設定済み ✓
- リージョン: ap-northeast-1（東京）
すぐに AWS を使い始められます。何をしたいですか？例えば：
- S3 バケットの操作
- EC2 インスタンスの管理
- その他の AWS サービス
あれ？シークレットキーですか？ aws login で一時認証情報を取得しているつもりでしたが、シークレットキーが配置されてしまっていますか？
その通りです。申し訳ありません — 誤った指摘でした。
aws configure list の出力から読み取れることは：
- TYPE が
login→aws loginによる一時認証情報が使われている ✓ - LOCATION が空白 → ファイルパスが記載されていない = 一時認証情報
つまり、あなたの設定は正しく機能していて、一時認証情報が使われていました。
混乱させてしまい失礼しました。
モデルにも依りますが、AI は平気で嘘をつきます。気をつけましょう。笑
いま何が起きたのか
大事なので、仕組みを確認しておきます。
Claude Code は、魔法で AWS を操作したわけではありません。
あなたの Mac に入っている aws コマンドを、あなたの代わりに組み立てて実行しただけです。
つまり、現時点で既に Claude は AWS を操作できる状況です。
ただ、開発に進む前にあと1ステップあります。
初心者の方には特に知っておいてほしい Claude Code の安全装置がありますので、次のステップでお話しします。
うまくいかないときは
Q. ブラウザが開きません / ファイアウォールの警告が出ました
A. セキュリティソフトが通信を止めている可能性があります。--remote を付けて実行してください。URL が表示されるので、それを手動でブラウザに貼り付け、表示された認証コードをターミナルに戻して入力します。
aws login --remote
Q. aws: command not found と出ます
A. ターミナルを一度閉じて開き直してください。インストール直後は、開いていたターミナルに変更が反映されていないためです。
Q. aws login なんてコマンドはない、と言われます
A. AWS CLI のバージョンが古いです。aws --version で確認してください。2.32.0 未満なら、Homebrew で入れた場合は brew upgrade awscli、公式インストーラーで入れた場合は aws update または最新のインストーラーを実行し直してください。
Q. AccessDenied が出てログインできません
A. SignInLocalDevelopmentAccess ポリシーの付け忘れです。この記事の「事前準備」に戻って追加してください。
Q. ログインは成功したのに、コマンドを打つと ExpiredToken エラーになります
A. これは要注意の症状です。 以前に aws configure でアクセスキーを設定したことがある場合、そちらが優先されてしまっています。
aws configure list を実行して、Type の列を見てください。login ではなく shared-credentials-file になっているはずです。
解決するには、~/.aws/credentials に残っている古いキーを削除してください。
Q. 会社のパソコンで、ブラウザのログインがうまくいきません
A. 会社の環境ではセキュリティ設定で弾かれることがあります。この記事の後半にあるアクセスキーの手順で進めてください。
【フォールバック】どうしてもうまくいかない場合
ここからは、aws login がどうしても動かなかった方向けの手順です。
うまくいった方は、この節を読む必要はありません。 次の章まで飛ばしてください。
先にお伝えしておくと、これは次善の策です。
先ほどの表のとおり、AWS 公式の推奨順位ではこの方法は最下位（非推奨）に位置づけられています。それでも「設定できずに先に進めない」よりはずっと良いので、手順を載せておきます。
アクセスキーを作る
- マネジメントコンソールで「IAM」→「ユーザー」→ 作業用ユーザーを選択
- 「セキュリティ認証情報」タブ →「アクセスキーを作成」
- ユースケースで「コマンドラインインターフェイス（CLI）」を選択
- 注意事項のチェックボックスにチェック → 次へ
- 「アクセスキーを作成」
アクセスキー ID と シークレットアクセスキー が表示されます。
シークレットアクセスキーは、この画面を閉じると二度と表示されません。 必ず控えておいてください。
aws configure で設定する
aws configure
4つ聞かれるので、順に入力します。
| 聞かれること | 入力するもの |
|---|---|
AWS Access Key ID | 作成したアクセスキー ID |
AWS Secret Access Key | シークレットアクセスキー |
Default region name | ap-northeast-1 |
Default output format | json |
動作確認は aws login の場合と同じです。
aws sts get-caller-identity
保存されるものを見てください
cat ~/.aws/credentials
アクセスキーが、そのままの文字列で保存されています。
[default]
aws_access_key_id = AKIAXXXXXXXXXXXXXXXX
aws_secret_access_key = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
暗号化はされていません。このファイルを見られたら、あなたの AWS アカウントは操作されます。
アクセスキーを使う場合に守ってほしいこと
- チャットやメールに貼らない（AI とのチャット欄も含みます。設定ファイルに書いてあるので、AI に見せる必要はありません）
- GitHub に上げない（公開リポジトリに上がったキーは、数分で悪用されます）
- 画面共有のときは
cat ~/.aws/credentialsを実行しない - 使い終わったら IAM の画面から無効化・削除する
⚠️ あとで aws login に切り替えるときの注意
ここが一番ハマるポイントです。必ず読んでください。
この方法で設定したあと、「やっぱり aws login を使おう」と思って実行すると、ログインは成功するのに、すべてのコマンドが ExpiredToken で失敗するという状態になります。
原因は、~/.aws/credentials に残っているアクセスキーのほうが優先されるからです。
aws login は成功しているので、何が悪いのか非常に分かりにくいです。
切り替えるときは、先に ~/.aws/credentials の中身を削除してください。
これをやらずに実行すると、以下のようなエラーが出ます。
aws: [ERROR]: An error occurred (Configuration): Profile 'default' is already configured with Access Key credentials.
削除したあと aws configure list を実行し、Type の列が login になっていれば正しく切り替わっています。
そして、IAM の画面で古いアクセスキーを無効化・削除するところまでやってください。 使わないキーを残しておく理由はありません。
覚えておくと便利なコマンド
この記事で出てきたものを含め、よく使うものをまとめておきます。
| コマンド | 何をするか |
|---|---|
aws --version | バージョンを確認する |
aws login | サインインする（12時間で切れたら再実行） |
aws logout | サインアウトして認証情報を消す |
aws sts get-caller-identity | いま自分が誰として操作できるかを確認する |
aws configure list | 認証情報がどこから読まれているかを確認する |
aws s3 ls | S3 のバケット一覧を表示する（動作確認に便利） |
太字の2つは、トラブルが起きたときに最初に打つコマンドです。
「動かない」と思ったら、まずこの2つで現状を確認する癖をつけておくと、解決がぐっと速くなります。
よくある質問
Q. aws login と aws configure sso は違うものですか？
A. 違います。aws configure sso は IAM Identity Center を使う場合の方法です。前回の記事で説明したとおり、個人の単一アカウントで IAM Identity Center を有効にするとクレジットが失効するため、このシリーズでは使いません。
Q. アクセスキーを作らないと、プログラムから AWS を使えないのでは？
A. 使えます。aws login で取得した一時的な認証情報は、AWS CLI だけでなく SDK からも利用できます。ただし一部の SDK やバージョンは未対応なので、プログラムを書く段階になったら公式ドキュメントで対応状況を確認してください。
Q. パソコンを再起動したらログインし直しですか？
A. いいえ。再起動してもセッションは残ります。切れるのは最大12時間経過したときです。
Q. 複数の AWS アカウントを使い分けられますか？
A. できます。aws login --profile 名前 のようにプロファイルを分けて管理します。ただし最初のうちは1つで十分なので、慣れてからで大丈夫です。
Q. aws login の情報が少なくて不安です
A. 正直なところ、2025年11月に追加された新しい機能なので、日本語の解説はまだほとんどありません。詰まったときに検索で解決しにくいのは事実です。
そのぶんこの記事ではトラブルシューティングを厚めに書き、うまくいかない場合の代替手順も載せてあります。それでも解決しない場合は、公式ドキュメントを参照してください。
Q. これで料金は発生しますか？
A. しません。AWS CLI のインストールも aws login も無料です。料金が発生するのは、実際にリソースを作ったときだけです。
さいごに
Mac に AWS CLI をインストールし、コマンドから AWS を操作できる状態にするまでを解説しました。
やったことは3つです。
- AWS CLI をインストールする（バージョン 2.32.0 以上）
aws loginでサインインする（アクセスキーは作らない）aws sts get-caller-identityで動作を確認する
これで、あなたの Mac は AWS を操作できる状態になりました。
そして重要なのは、手元に長期の認証情報が1つも残っていないことです。
入門記事の手順どおりに進めた結果、パソコンの中に有効期限のないアクセスキーが眠っている、という状態を避けられました。
次回は、AI が想定外の操作をしないようにするための安全設定を行います。
「AI がうっかり消してしまう」を防ぐ仕組みを入れてから、実際にモノを作る回に進みます。
シリーズの全体像は、ロードマップから確認できます。
KUDs のサービス
KUDs では、実際に AWS 上で動く Web サービスを公開しています。
ご質問やご指摘は contact@kuds.jp までお寄せください。
「ここで詰まった」という報告は、記事を良くするうえでいちばんありがたいフィードバックです。
コメント