はじめに
AWS Bedrockで生成AIを試そうと思ったら、突然Boto3がエラーを吐くように。。。
「え、Bedrock死んだ？Quota制限？無料枠の限界？」と焦りながら、公式ブログやQiita記事を読み漁るも、どうも状況が違う。
そんな中、AWSから届いていた“本人確認メール”の存在に気づく。 でも文面が怪しすぎて、完全にフィッシング
だと思ってスルーしていた。 Copilotに相談してみたら「怪しいですね…」と共感されて終わる。うん、わかる。
その後、CloudShellまで使えなくなっていることに気づき、ようやく「これは本物かも」と思い直してサポートセンターに問い合わせ。 結果的に、本人確認メールの案内通りに書類をアップロードしたところ、約1時間後に制限が解除された。
この記事では、
-
AWS無料アカウントでBedrockが使えなくなった理由
-
本人確認メールの真偽を見極めるまでの流れ
-
実際に提出した書類と対応手順
を、ゆるっとまとめてみます。
1. 発端：Bedrockが沈黙
ある日、いつものようにSDKからBedrockを叩いたら、Boto3が謎のエラーを吐き始めた。
botocore.errorfactory.ValidationException: An error occurred (ValidationException) when calling the InvokeModel operation: The provided model identifier is invalid.
Bedrockのコンソール上には「The provided model identifier is invalid」のエラーメッセージが表示されるようになっています。
「え？Bedrock落ちた？」「無料枠の限界？」「Quota制限？」と、頭の中で疑問がぐるぐる。 とりあえず AWS公式ブログ を読んでみたり、Noteの体験談や Qiita記事 を参考にしてみたり。
でも、どれも「Quotaを上げたら解決した」系の話ばかり。レート制限見ても０にはなってない。そもそもBedrockは使えてた時点から何もマネコン触ってない。
「これは…何か別の問題かも？」と、ようやく違和感を覚え始めたその時。 ふとメールボックスに目をやると、AWSから届いていた“本人確認メール”の存在に気づく。
件名はそれっぽいし、差出人も no-reply@amazonaws.com。でも文面が怪しすぎる。 「これ、フィッシングじゃないの…？」という疑念が頭をよぎる。
2. Copilotに相談してみた
Bedrockが沈黙し、モデルIDが“invalid”扱いされる謎の状況。 「これはもう人間じゃわからん」と思い、AIに頼ることとした。そう、Copilotである。
メールに書かれていた本人確認の案内文をそのまま貼り付けてみた。 するとCopilotは、冷静にこう言った。
「怪しいですね…。不用意にリンクをクリックしたり、個人情報を送ったりするのは絶対に避けてください。」
うん、わかる。 こっちも怪しいと思ってる。だから相談してるんだよ。
Copilotはフィッシングの可能性を丁寧に解説してくれたけど、結局「怪しいですね」で終わった。 共感はしてくれるけど、決定打はくれない。 まあ、AIも慎重になる時代だ。
この時点では、まだ「フィッシングっぽいけど、ちょっと本物っぽい」くらいの微妙なライン。 でも、Copilotとのやり取りで少し冷静になれたのは事実。 そして次の瞬間、事態はさらに深刻になる。
3. CloudShellも死んでる
Copilotとのやり取りで「怪しいメールだな〜」と共感しつつも、まだ半信半疑だった。 Bedrockが使えないだけなら、Quotaの問題かもしれないし、モデルIDの指定ミスかもしれない。 そこで、まずはマネジメントコンソールからAWSのサポートセンターに問い合わせることとした。
UIは意外と親切で、カテゴリを選んで状況を説明。
この時点では、まだ「Quota制限かも？」という認識だった。 しかし、問い合わせを送信した後に、CloudShellが起動しないことに気づく。「え、BedrockだけじゃなくてCloudShellも？」 これはもう、Quotaの問題じゃないと確信。アカウント全体が何かしらのフラグを食らってる気配が濃厚。
そこで、AWSサポートに「この本人確認メールは本物かどうか」を確認する追加の問い合わせを送信
あとは祈るだけのフェーズに突入した。
4. まさかの本人確認メールだった
問い合わせから約2日後、AWSサポートから返信が届いた。 内容を読んでみると、あの怪しいと思っていたメールは本物だった。
「添付いただいたメールの送信元アドレス no-reply@amazonaws.com についても AWS が管理するもので相違ございません。 メールに記載されたセキュアリンクより、必要書類のアップロードについてご対応をお願いいたします。」
Copilotも「怪しいですね…」って言ってたし、自分も完全にフィッシングだと思ってた。 でも、CloudShellが使えないという物理的な異変があったことで、ようやく納得がいった。
AWSからの案内によると、本人確認のために以下の情報を提出する必要があるとのこと：
-
登録住所と電話番号が記載された書類（請求書など）
-
使用しているクレジットカードの明細（必要に応じて）
-
企業名やウェブサイトURL（法人の場合）
無料アカウントでもここまで求められるのか…と驚きつつ、対応を開始。
5. 提出と復旧
まずは、携帯キャリアのサイトにログインして、請求書をPDFでダウンロード。 住所と電話番号が記載されているページだけを抜き出し、不要な情報はマスクして準備完了。
AWSの指定されたアップロードフォームにファイルを提出。 「これでダメなら、Bedrockともお別れか…」と覚悟しつつ待っていたら、約1時間後に制限が解除された。
Bedrockが復活し、CloudShellも起動。Claudeが帰ってきた。 SDKも正常に動作し、あの「model identifier is invalid」エラーも消えていた。
6. 教訓とまとめ
今回の件で得られた教訓は、思った以上に多かった。
-
AWS無料アカウントでも本人確認を求められることがある
特に生成AI系のサービス（Bedrockなど）を使っていると、セキュリティチェックが厳しくなるのかもしれない。 -
怪しいメールでも、CloudShellが死んでたら本物かも。
メールだけでは判断できない。マネジメントコンソール側の挙動とセットで見ることが重要。 -
Copilotは共感してくれるけど、決断は自分でしよう
AIは頼れるけど、最終的な判断は人間の直感と経験がモノを言う。 -
ちなみに提出書類は、住所と電話番号が載っていればOK。
不要な情報はマスクして問題なし。セキュリティ的にも安心して提出できる。
以上です。Bedrockが使えなくなった等、同じような状況に陥った人の参考になれば幸いです。