サーカスLT会 #1 @大阪に参加して登壇してきた話

Last updated at 2026-09-11Posted at 2026-09-11

はじめに

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つです。