🤖 【AI × AWS】aws login 超入門 ─ AIにAWSを任せる前に知っておきたい認証の話
最近では、Claude Code をはじめとしたAIエージェントにCLI操作を任せる場面が増えてきました。
便利な一方で、AWSのような「実行＝即お金や本番環境に直結」する世界では、認証情報（クレデンシャル）の整理が甘いと、AIが意図しない環境を勝手に操作してしまうリスクがあります。
この記事では、AWS CLI v2.32.0 から導入された aws login コマンドの基本と、AIに作業を任せる前にハマりやすいポイントを、AWS CLI初心者向けにまとめます。
なお、本記事を読み進める前に、default プロファイルが整理されていない方は、まず以下の関連記事をご覧いただくことをおすすめします。
🔰 前提：AWS CLIのプロファイルとは
AWS CLIは、認証情報や接続先リージョンを プロファイル（設定の塊）として保持します。プロファイルは2つのファイルに分かれて保存されます。
| ファイル | 役割 |
|---|---|
~/.aws/credentials |
アクセスキーなど 認証情報 |
~/.aws/config |
リージョンや出力形式など 設定情報 |
それぞれのファイル内に [プロファイル名] 単位でブロックが並びます。
# ~/.aws/credentials の例
[default]
aws_access_key_id = ...
aws_secret_access_key = ...
[my-dev-profile]
aws_access_key_id = ...
aws_secret_access_key = ...
aws s3 ls のように プロファイル指定なし でコマンドを実行すると、default が暗黙的に使われます。
つまり、default の中身がそのまま「自分の操作対象のAWS環境」になります。ここが今回の話の出発点です。
🆕 aws login とは
aws login は、AWS CLI v2.32.0 以降で利用できる、ブラウザベースの認証コマンドです。
IAMユーザー、ルートユーザー、IAMフェデレーションIDのコンソール認証情報を使って、CLI用の一時認証情報をローカルに取得します。
主な特徴
- 実行するとブラウザが立ち上がり、AWSマネジメントコンソール経由でサインインする
- 認証成功後、最大12時間有効な一時認証情報が取得される
- 認証情報はローカルにキャッシュされる
- Windows：
%USERPROFILE%\.aws\login\cache - Linux/macOS：
~/.aws/login/cache
- Windows：
実行例
# default プロファイルとしてログイン
aws login
# プロファイル指定でログイン
aws login --profile my-dev-profile
ブラウザで認証が完了すると、ターミナルに次のようなメッセージが表示されます。
Logged in with role `arn:aws:sts::012345678910:user/iam-user`,
and configured profile `default` to use `us-east-1`.
This session will expire on October 14, 2025 at 2:04 PST.
After this time, you can renew your session with `aws login`.
従来の認証コマンドとの違い
aws で始まるサインイン系コマンドはいくつかあり、用途が混ざりやすいので整理します。
| コマンド | 用途 | 主な対象 |
|---|---|---|
aws configure |
静的なアクセスキーを保存する | IAMユーザーの長期キー（最近は非推奨傾向） |
aws sso login |
IAM Identity Center でサインインする | 組織でSSOを使っている環境 |
aws login |
コンソール認証情報でブラウザ経由サインインする | ローカル開発の手軽な選択肢（v2.32.0以降） |
📝 Memo: aws sso login との混同に注意
IAM Identity Center（旧 AWS SSO）を使っている環境では、引き続き aws sso login を使います。
aws login とは別物なので、組織の運用ルールに合わせて使い分けてください。
⚠️ aws login と default プロファイルの関係
ここからが、AIに作業を任せるときに最も気をつけたいポイントです。
aws login を プロファイル指定なし で実行すると、default プロファイルにログインセッション情報が書き込まれます。
1. 既存セッションがある場合は上書き確認プロンプトが出る
default に 別のログインセッション が設定済みの状態で aws login を実行すると、以下のような上書き確認プロンプトが表示されます。
Profile signin is already configured to use session arn:aws:iam::0123456789012:user/ReadOnly.
Do you want to overwrite it to use arn:aws:iam::0123456789012:user/Admin instead? (y/n):
別ID/別ロールで default を上書きしてしまわないためのストッパーです。
ただし、default がまったくの未設定や、後述するように静的キーのみが設定されている状態では、このプロンプトは出ずに default が作成・更新されます。
2. 落とし穴：静的キーが残っていると aws login が黙って無視される
ここが本記事のいちばん大事な部分です。
~/.aws/credentials の [default] に 静的アクセスキー（aws_access_key_id 等）が残ったまま aws login を実行すると、ターミナル上は次のような 成功メッセージ が表示されます。
Updated profile default to use arn:aws:sts::xxxxxxxxxxxx:assumed-role/RoleName/username credentials.
しかし、AWS CLIの認証情報の優先順位ルールにより、静的キーが優先されて使われ続けます。
つまり、見た目上は新しいIDでログインしたつもりが、実際の操作は古い静的キーで実行される、という危険な状態になります。
確認方法は aws configure list の TYPE 列です。
❌ 静的キーが優先されている状態（aws login が効いていない）
> aws configure list
NAME : VALUE : TYPE : LOCATION
profile : <not set> : None : None
access_key : ****************LIHG : shared-credentials-file : ...
secret_key : ****************d6gd : shared-credentials-file : ...
region : ap-northeast-1 : config-file : ~/.aws/config
✅ aws login の認証情報が正しく使われている状態
> aws configure list
NAME : VALUE : TYPE : LOCATION
profile : <not set> : None : None
access_key : ****************XXXX : login : ...
secret_key : ****************YYYY : login : ...
region : ap-northeast-1 : config-file : ~/.aws/config
TYPE 列が login になっていれば正しく aws login の認証情報が使われています。
shared-credentials-file のままだった場合は、関連記事の手順で default の静的キーを削除してください。
⚠️注意：成功メッセージは「実際に使われている」ことを保証しない
aws login の成功メッセージは、あくまで「設定ファイルへの書き込みが成功した」というだけで、その認証情報が実際に使われていることまでは保証しません。
aws login 後は 必ず aws configure list で TYPE 列を確認する 習慣をおすすめします。
🤖 AIエージェントにAWSを任せるときの注意点
ここまでの話を踏まえて、AI（Claude Codeなど）にAWS関連コマンドを任せる際の実践的なコツをまとめます。
コツ1. プロンプトで --profile の明示を強制する
AIは省略可能なオプションを省きがちです。指示する側で明示しましょう。
これ以降のAWS CLIコマンドは、必ず --profile dev-sandbox を付けて実行してください。
プロファイル指定を省略しないでください。
コツ2. 作業前に aws configure list を実行させる
実行直前に状況を確認させることで、想定外のプロファイルで動き出す事故を防げます。
コマンドを実行する前に、毎回 aws configure list --profile dev-sandbox を実行してください。
TYPE 列が login になっていることを確認してから次に進んでください。
コツ3. 強い権限のキーを default に置かない
default には極力、何も設定しないか、参照系の限定権限のみに留めるのが安全です。
本番環境への接続情報は、必ず名前付きプロファイル（例： honban-prd）に分離します。
これは、AIが --profile を省略してしまった場合の 被害最小化策 にもなります。
コツ4. 破壊的な操作の前に必ず確認ステップを挟ませる
delete / terminate / put / update 系のコマンドは、AIに勝手に実行させないようにします。
削除や変更を伴うコマンドを実行する前に、必ず実行予定の完全なコマンドを提示し、
私からの「OK」を受け取ってから実行してください。dry-run オプションが利用できる場合は先に dry-run で実行してください。
⚠️注意：default が汚れたままAIにAWSを任せるのは危険
default に強い権限のキーが残った状態でAIに --profile 省略の余地を与えると、本番環境に対して破壊的な操作が走るリスクがあります。
AIに任せる前に、まず default のクリーンアップから始めることを強く推奨します。
✅ まとめ
-
aws loginは、AWS CLI v2.32.0以降で使える ブラウザベースの認証コマンド - プロファイル指定なしで実行すると
defaultに書き込まれる -
defaultに静的キーが残っていると、aws loginの認証情報は 黙って無視 される - 設定後は 必ず
aws configure listのTYPE列を確認 する - AIにAWSを任せるときは、
--profile明示・事前確認・default分離・破壊操作の確認、をプロンプトに盛り込む
aws login を活かすには、まず default プロファイルをきれいにしておくことが第一歩です。
未整理の方は、関連記事をあわせてご覧ください。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。