AWS Events APIが出たので、re:Inventのセッション選びをClaude Codeに手伝ってもらった

柴田です。

re:Inventの開催が近づいてきましたが、皆さんはもうセッション選びを始めていますか？

今年はAWS Events APIという公式のAPIが公開され、セッションカタログの取得やお気に入りの登録、予約をプログラムから行えるようになりました。
今回、このAPIとClaude Codeを組み合わせてセッションの選択にチャレンジしてみましたので、実装してみて分かったことなどを紹介したいと思います。
なお、ポータルでの予約は米国太平洋時間の10月6日（日本時間では10月7日）、Events APIからの予約は10月8日から始まります。執筆時点では予約が始まっていないため、今回はカタログの取得やお気に入りの登録だけ試しました。

docs.aws.amazon.com

APIとClaude Codeでセッションを選ぶ

re:Inventのセッションは毎年とても多く、ポータルでセッションを検索し、お気に入りを選んで、スケジュールを組むというのがなかなか大変でした。今年も9月末の時点で2,000件以上が登録されており、大変だなと思っていたところにEvents APIが出たので、APIとClaude Codeで選ぶことにしました。

Pythonのスクリプトでカタログを全件取得して手元に保存し、Claude Codeと相談して面白そうなセッションを選び、お気に入りの登録もAPIから行いました。

Claude Codeと相談して候補を決める

Pythonスクリプトを実行し、ローカルにセッション情報を保存した後にClaude Codeに「私におすすめのセッションはないか」と聞きました。普段の仕事でもClaude Codeを使っているので、私の担当業務を踏まえて候補を出してくれます。その中からいくつかを選ぶと、Claude Codeがwishlist.txtに選択した情報を保存します。以下が記録の一例です。

GHJ306-S   # 11/30 月 14:00-17:00 Caesars Palace  GameDay ft. Datadog
SVS347-R   # 11/30 月 09:00-10:00 Caesars Forum   Low latency web apps with Serverless
（一部抜粋）

続けて、「お気に入りに登録しておいて」と頼むとClaude Codeがスクリプトを実行し、お気に入りを登録してくれました。

基本的な動作を確認できたので、自分にあったスケジュールをClaude Codeと一緒に考えました。録画されない可能性が高いChalk talkなどを優先し、会場の移動を減らし、夜のイベント（プライベートの予定）がある日は昼の負担を軽くするといったことを判断しながら提案してくれました。

「できるだけ詰め込むとどうなる？」「昼食はちゃんと食べたい」など、色々と条件を伝えながら、1週間のスケジュールを立てました。

差分レポートで変更を追う

カタログは頻繁に変わるので、スクリプトでは取得のたびに全件のスナップショットを保存し、前回との差分を書き出すようにしました。例えば次のような変更がありました。

- AIM332-R1 | 2026-12-01 13:00 | Agentic fairness: Practical methods to detect bias in AI-driven decisions
  - venue: None → MGM Grand
  - room: Wynn/Encore | Level 1 | Chopin 2 → Level 1 | Boulevard 167
  - sessionTime: 2026-12-01 60 14:30 → 2026-12-01 60 13:00

Wynn/EncoreからMGM Grandへ会場が移り、時間も早まっています。

MCPではなくREST APIを選んだ理由

AWS Events APIではMCPサーバー（https://api.awsevents.com/mcp）も提供されています。今回は、次の2点からREST APIを使う選択をしました。

1つ目は、会話に入るデータの量です。 APIにはセッションの検索や絞り込みの機能が無いため、新着の確認をMCPで行うと、毎回2,000件あまりのセッションを全件読み込むことになります。そのため、Claude Codeとの会話に入るデータが多く、トークン使用量が増えることが懸念されました。スクリプトにして必要なときだけ情報を取得することで、Claude Codeに処理したい部分だけ抜き出して渡すということができます。

2つ目は結果の不確かさです。予約とお気に入りは複数のセッションをまとめて実行できますが、一部が失敗していても実行自体は成功となるため、一部の予約ができていなくとも誤って完了と報告する可能性があります。 MCPサーバーのページでも、GetScheduleで結果を確かめさせるよう勧めています。このあたりはスクリプトで登録と完了チェックを実行するのが確実だと考えました。

参考: Using the MCP server - AWS Events API

実装するときの注意点

ここからは、APIを使う上で少し気を付ける必要があると思った点を紹介します。

サインイン

re:Invent 2026は参加登録が必要なイベントなので、カタログの取得にはre:Invent 2026への参加登録を行った、Builder IDを使う必要があります。 Authorization Code + PKCE（Proof Key for Code Exchange）でトークンを取得しますが、クライアントIDは全利用者で共通の公開値なので、アプリケーションの登録は要りません。

参考: Endpoints and values - AWS Events API

自作のアプリケーションで使えるリダイレクトURIとポートには指定があり、ループバックアドレスのポート8484〜8489の/callbackで待ち受けます。 MCPと同時に使うときはポート番号の重複に気を付けてください。

認可リクエストの組み立ては次のとおりです。

challenge = base64.urlsafe_b64encode(
    hashlib.sha256(verifier.encode()).digest()
).rstrip(b"=").decode()  # base64url、パディングなし

url = f"{OAUTH}/authorize?" + urllib.parse.urlencode({
    "response_type": "code",
    "client_id": CLIENT_ID,
    "redirect_uri": "http://127.0.0.1:8484/callback",
    "scope": "openid email events/access",
    "identity_provider": "AWSBuilderID",  # ← 付けないとIdPの選択画面が挟まる
    "code_challenge": challenge,
    "code_challenge_method": "S256",
    "state": state,
})

code_challenge_method=S256を明示しなかったり、チャレンジをbase64url以外で送ったりするとトークン交換が失敗しますのでご注意ください。

お気に入りの登録はHTTPステータスではなく結果を確認する

お気に入りの登録はPOST /v1/events/{eventId}/favoritesに、sessionIdsの配列に1回に1〜10件のセッションIDを詰めて送ります。複数のセッションをまとめて送るので、HTTPのステータスが200で返ってきても、一部のセッションが失敗している可能性があります。成否は必ずsuccessfulやfailedの中身で判断します。以下は、応答のイメージです。

{
  "result": {
    "successful": ["<sessionId-1>"],
    "failed": [
      { "sessionId": "<sessionId-3>", "code": "scheduleConflict", "conflictsWith": ["<sessionId-4>"] }
    ]
  }
}

スロットリングとページ送り

1分あたりのAPIリクエスト数の上限は操作ごとに決まっています。お気に入りと予約はリクエストの回数ではなくセッションの数で数え、1分あたり30セッションまでです。

参考: Quotas and throttling - AWS Events API

セッション一覧は1ページに何件返るかをこちらで指定できません。必ず、nextTokenをチェックして返ってこなくなるまで繰り返し取得します。

参考: ListSessions - AWS Events API

時刻のタイムゾーン

個人の予定を登録するときは、時刻の書き方に注意が必要です。個人の予定の開始と終了時刻はUTCで書く必要があり、またZや+01:00のようなオフセットも付けません。たとえばラスベガスで12月1日17:30から始まる予定なら、2026-12-02T01:30:00と送る必要があります。

実際に使って気付いたこと

ここからは、9月末時点のデータで、気になったポイントを紹介します。

会場の項目が空のセッションが多い

2043件のうち896件でvenueが空でした。ただ、896件のroomをみると、Wynn/Encoreで始まるものが521件、Caesars Palaceで始まるものが329件ありました。残りの46件はroomも時間も無いデータでした。また、venueに値が入っているデータを見るとMGM Grand、Caesars Forum、Venetianの3つだけが登録されており、Wynn/EncoreとCaesars Palaceが設定されているデータがありませんでした。

現状のデータでは会場を知りたい場合、venueだけでは無くroomの情報も見た方が良さそうです。

キーノートなどはカタログに無い

9月末時点のカタログには、キーノートやアクセシビリティ系の項目がありませんでした。キーノートは予約できませんが、カレンダーには入れておきたいので、今後追加されるかは継続的に見ておこうと思います。

まとめ

AWS Events APIを使うと、re:Inventのセッションカタログと自分のスケジュールをプログラムから扱えるようになります。これで、大量のセッションの中から効率よく自分の知りたいセッションを選ぶことができるようになりました。予定の調整も、Claude Codeに任せることで気軽に組み替えられるようになりました。

ただ、ついついカタログを見てしまいます。ポータルを見るのも楽しみの一つなのかもしれません。