はじめに

2026年8月7日（金）にグランフロント大阪（GFO）のBIPROGYフロアにて開催された 「サーカスLT会 #1」 に、登壇者として、また会場提供sideとして参加してきました。

記念すべき第1回に、登壇と会場提供の両方で関われたのが貴重な経験でしたので、当日の様子を記事にしてみました！

地方のAWSコミュニティイベントの雰囲気を知りたい方、次回以降の参加を迷っている方の参考になれば幸いです。

サーカスLT会とは

首都圏以外を巡業する、AWSに関するLT会です。

発端は、2026 Japan AWS Jr.Champions（以後、Jr.Champions）に選出された地方在住の若手エンジニアの方々の、

首都圏だけでなく「地方」でもAWSのコミュニティイベントを開催して、より多くのAWS好きな方と交流したい！

という思いだったそうです。

サーカスの巡業のように月1回ペースで各地を回っていくことから、「サーカスLT会」という名前になったとのこと。

ちなみに、立ち上げ当事者の「ssakita」さんの記事は以下になります。
自分たちで立ち上げた「サーカスLT会」、第1回を大阪で開催してきた🎪

会場の雰囲気

今回の参加者は 27名（オフライン20名 / オンライン7名）、LTは全8本という構成でした。

第1回ということもあり、AWSコミュニティの常連の方から今回が初参加という方まで、バックグラウンドがかなりバラバラだったのは印象的でした。

そして開始前、Jr.Championsの方々がホワイトボードに素敵なイラストを描いていました！

LT大会

今回のテーマは 「AWSに関することなら何でも」。テーマが広い分、AIエージェントのお話から、現Jr.Championsの方による「なるまでに頑張ったこと・これから頑張ること」、元Jr.Championsの方からのアドバイスまで、技術的な話とコミュニティ関連の話が入り混じって、とても幅広い印象でした。

全8本すべてはご紹介しきれないので、ここでは特に印象に残った1本を取り上げます。

マナティさん「AIエージェントのコストガバナンスをAWSで実現したい」

AIエージェントの「暴走コスト」をどう抑えるか、というテーマのLTでした。

冒頭で紹介されていたのが、2026年5月に Uberが年間のAI予算を4ヶ月で使い切った という事例。従来型のシステムはユーザー数が増えなければコストも読めますが、AIエージェントは「何をどこまでやっていいか」の制限がないと、使い方や並列実行の仕方によって

日によって10倍以上の差

が出てしまう、というお話でした。

その対策として紹介されていたのが AgentCore の制御機能です。

Policy … 「金額が $10 を超えるアクションは禁止」といったルールを Cedar で宣言的に定義し、エージェント側が無視できない形で強制する
Rate Limits（最新アップデート） … ユーザー / グループ単位のレート制限、トークン数上限（例：エンジニア1人あたり10万トークン/分）、リクエスト数上限（例：チーム全体で100回/秒）、同時セッション数の制限
高額な操作については 人間の承認を必須にする

補足：この制御が効く「範囲」がポイントです

Policy と Rate Limits は、どちらも AgentCore Gateway を通る通信にかかる仕組みです。ここを押さえておくと、設計時の判断がしやすくなります。

ツール呼び出しやモデル呼び出しを Gateway 経由にまとめておけば、以下の単位でまとめて上限をかけられます。

制御できるもの	期間の単位	効く範囲
リクエスト数	秒 / 分	すべてのターゲット
同時実行数（処理中のリクエスト数）	秒	すべてのターゲット
トークン数	分	推論ターゲットのみ

トークン数の上限は推論ターゲット限定なので、「トークンで縛りたい呼び出しは推論ターゲットとして Gateway に載せる」という整理が必要になります。

逆に、Gateway を通らない経路は対象外です。「AgentCore を入れればコストに上限がかかる」わけではないので、どの呼び出しを Gateway に寄せるか が設計上のポイントになります。

なお AgentCore Harness（Runtime 上で動くマネージドなエージェントループ）側には、これとは別に呼び出し単位の上限が用意されています。maxIterations（推論・アクションのサイクル数、既定75）／timeoutSeconds（1回の実行時間、既定3600秒）／maxTokens（1回の呼び出しで使えるトークン予算）を設定でき、暴走したエージェントが際限なく回り続けるのを防げます。

もうひとつ、Policy でしきい値を判定できるのは ツールに渡される入力パラメータ（送金額・購入金額など）です。AIの利用料そのものに上限をかける機能ではない、という点には注意です。

参考：Rate limit metrics（AWS公式ドキュメント） / Configure rate limits for AI traffic on AgentCore gateway

そして締めが「コストガバナンスは運用でカバーするのではなく、設計段階でルールとして実装しておく必要がある」「Policy と Rate Limits の組み合わせで制御できる」という内容。

生成AIのPoCをやっていると「とりあえず動かしてみる」が優先されてコスト面はつい後回しになりがちなので、最初から制御の仕組みを入れておくという考え方は、大事だなと思いました。

私も登壇しました

私は 「AWS検証環境の削除し忘れ対策を、簡易的に自動化してみた！」 というテーマで登壇しました。

個人の検証環境でリソースを消し忘れ、カード明細を見て初めて気づく、というあるあるを踏んでしまったのがきっかけです。Lambda → Bedrock（Claude）→ SNS の構成で、未関連付けEIP・未アタッチEBS・停止中EC2・アイドルなNAT Gatewayを検知してメール通知が飛ぶ仕組みを作った話をしました。

実装ポイントは2つです。

判定はコード、文章化はAI … 「何が未使用か」はLambda側の決定的なロジックに閉じ込め、Bedrockには優先度付けと説明文の生成だけを任せる
Lambdaに削除系の権限を渡さない … 参照系APIのみに絞り、自動化しても誤削除が起きない設計にする

📄 詳細はこちらに書いています：AWS検証環境の削除し忘れ対策を、簡易的に自動化してみた！

当日の雰囲気を写真で

↑Jr.Championsの方々が準備されているご様子

LT後は集合写真📷

LT大会終了後は、参加者全員で写真撮影をしました！

次回は富山！

次回のサーカスLT会は 2026年9月25日（金）に富山 で開催されるとのことです。

気になった方はぜひ以下のリンクからご参加を検討してみてください！
サーカスLT会 #2 @富山

BIPROGYグループの技術への取り組み

We Are Hiring!