SigV4とは?AWSの「署名」の話

SigV4は「リクエストにハンコを押す仕組み」

SigV4(シグ・ブイフォー)は、正式には AWS Signature Version 4 といいます。AWSのサービスにリクエストを送るとき、「これは確かに私が出したリクエストで、途中で誰にも書き換えられていません」と証明するための署名の方式です。

Claude CodeでAmazon Bedrock経由のClaudeモデルを使う設定をしたことがある人なら、「AWSの認証情報(アクセスキーなど)を設定しろ」と言われた経験があるはずです。その裏側で実際に何が行われているかというと、リクエストごとにSigV4の署名が計算されて、HTTPヘッダーに付けられて送られています。

宅配便の伝票にたとえると

荷物を送るとき、伝票には差出人の名前と中身の情報を書きますよね。ここで、もし伝票に「割印」のようなものがあって、差出人しか作れない特殊な模様が押されているとします。受け取る側はその模様を見て、「確かにこの人が出した荷物だ」「配送中に中身のリストが書き換えられていない」と判断できます。

SigV4がやっているのはまさにこれです。送信先のURL、HTTPメソッド、日時、ヘッダー、リクエストボディといった情報をまとめてハッシュ化し、秘密の鍵(シークレットアクセスキー)を使って計算した文字列を、署名としてリクエストに添えます。AWS側は同じ計算を自分でもやり直し、結果が一致すれば「本物だ」と認めます。

パスワードをそのまま送らないのがポイント

ここが地味に大事なところで、シークレットアクセスキーそのものはネットワーク上を流れません。流れるのは「その鍵を使って計算した結果」だけです。計算結果から元の鍵を逆算するのは現実的に不可能なので、通信を盗み見られても鍵は盗まれません。

さらに署名には日時が含まれています。そのため古い署名を再利用しようとしても弾かれます。「昨日のリクエストをそのままコピーして送りつける」といった攻撃(リプレイ攻撃と呼ばれます)への対策になっているわけです。

署名に使われる材料

材料	役割
アクセスキーID	「誰が」を示す公開された識別子
シークレットアクセスキー	署名計算に使う秘密の鍵。送信はされない
リージョン・サービス名	この署名がどこ宛てに有効かを限定する
日時	署名の有効期限を作り、使い回しを防ぐ
リクエストの中身	URL・ヘッダー・ボディ。改ざんを検出する

自分で計算する必要はほぼない

仕様を読むと「正規化リクエストを作って、署名文字列を組み立てて、段階的に鍵を導出して……」とけっこう手順が多く、正直、手で実装しようとすると1文字のスペースの違いで署名が合わなくなって心が折れます。

ただ幸いなことに、普段そこを自分で書くことはまずありません。AWS CLIや各言語のAWS SDK、そしてClaude CodeがBedrockに接続するときの内部処理が、すべて自動でやってくれます。私たちがやることは、正しい認証情報とリージョンを環境に用意しておくことだけです。

うまくいかないときに疑う場所

署名エラーが出たときは、たいてい難しい話ではなく単純な設定ミスです。よくあるのは、アクセスキーやシークレットキーのコピペミス、リージョンの指定が実際の呼び出し先と食い違っている、あるいはマシンの時計がずれている、といったあたりです。

特に時計のずれは見落としやすい原因です。署名は日時を含めて計算されるので、端末の時刻が大きくずれていると、正しい鍵を使っていても「有効でない署名」として拒否されることがあります。仮想マシンやコンテナを長時間スリープさせたあとに突然エラーが出た、というようなケースでは時刻同期を確認する価値があります。

覚えておきたいこと

SigV4は「AWSへのリクエストが本人のもので、改ざんされていないことを証明する署名方式」です。仕組みの詳細を暗記する必要はありませんが、認証エラーが出たときに「これは署名の話だから、鍵・リージョン・時刻あたりを見ればいい」と当たりを付けられるだけで、トラブル対応の速度がだいぶ変わります。