一人だけ、Kiroが静止する日

Transcript

1. 一人だけ、Kiroが静止する日 AIエディタの「超過の、そのまた上限」に、月末にぶつかった中小企業の実話 長田英幸 ／ 【関西開催】Amazon Quick & Kiro Festival!! /

   2026-09-10

2. 02

3. この話について 生成AIに開発を頼らざるを得なくなった小さな会社の記録です。 Kiroのコスト管理を整える中で、ある落とし穴に落ちて這い上がるま で。 派手な技術の話ではなく「知らなかった仕様に、いちばん困るタイミ ングで気づいた」という運用の話。 03

4. 背景：エンジニアが増えない、だからAIに頼る 中小企業。エンジニアを募集しても、なかなか採用に至らない。 人が増えないなら、今いるメンバーが生成AIを使いこなすしかない—— そういう空気が社内にできた。 Kiroの契約は会社としてIAM Identity Centerで一元管理。誰がどのアカ ウントを使い、どれだけ消費するかを会社側で把握できる状態が出発 点だった。 04

5. きっかけ：「今月のAWS代、高すぎ！」 ある月「今月のAWSの請求、高すぎないか」と声が上がり、私にKiroの クレジット利用状況の監視指示が下りた。 ところが管理コンソールのKiroのページでは、社員一人ひとり（Kiroア カウント単位）まで絞り込めなかった。 全体の消費は見えても「誰がどれだけ使っているか」が見えない。監 視しろと言われたのに、肝心の粒度が足りなかった。 05

6. 解決策：利用状況CSVを貯めて、自動で報告させる 色々と調べた……というのは半分嘘で、実際はKiro君がかなり頑張ってくれた。 たどり着いたのが、Kiroが毎日02:00 UTCに出力するユーザーアクティビティレ ポート（CSV）。 これをS3に貯め、バッチで集計し、会社のビジネスチャットに画像付きで報告す る仕組みを作った。 ユーザー単位の消費量・プラン・超過状況（Overage_Cap 等）が、CSVならちゃ んと取れる。

   出典URL – Kiro Docs: Viewing per-user activity kiro.dev/docs/enterprise/monitor-and-track/user-activity/ 06

7. 07

8. 08

9. 通知の設計：毎朝、そして毎週の始業時に Botの動き方もKiroに相談しながら決めた。 私個人宛て——毎朝の勤務開始時に利用状況が届くように。 会社のグループチャット——毎週の営業開始日（週明けの始業時間）に サマリーが届くように。 人が「見に行く」のではなく、通知が「向こうからやってくる」形に 。この時点では正直「これで安心」と思っていた。 09

10. 事件：月末の朝、「Kiroが動かない！」 月末が差し迫ったある日の朝、出社したエンジニアの第一声が「Kiro が動かない！」だった。 よりによって月末。幸い長期案件で、月末＝納期の締め日ではなかっ たのが救い。 しかも止まったのは全員ではなく、その一人だけ。何が起きているの か、最初はまったく分からなかった。 10

11. 正体：超過にも、さらに上限があった Kiroの超過利用（overage）には、Service Quotasで管理される上限（cap）が存 在した。 そのエンジニアは最上位プランを使い、プランのクレジットを使い切り、さらに 超過分もどんどん使っていた。 その超過分がcapに到達したことで、その人だけが利用停止になっていた。 「制限を超える使い方に、さらに制限がある」——この構造を初めて知った。 出典URL –

    Kiro Changelog: Custom Overage Caps via Service Quotas kiro.dev/changelog/general/custom-overage-caps-via-service-quotas/ 11

12. 対処のつまずき：すぐには上がらなかった 必死にKiroに相談しながら、Service Quotasの上限引き上げをリクエス ト。ところが、すぐには反映されない。 意外にもオペレーター対応（サポート経由）に。AWSサポートに起票 し英語でも問い合わせ、途中でなぜか一方のケースがクローズされる など一筋縄ではいかず。 その日は該当エンジニアはコーディングができず、資料作成などに切 り替えて過ごした。 後で調べると、Service

    Quotasは「小さい増加は自動、大きい増加はサ ポート送りで時間がかかる」標準的な挙動。月末の駆け込み申請が一 番響いた。 12

13. いちばん大事な誤解：capは「1人ずつ」に効く capはアカウントに1つ設定する値。だが公式には「プロファイル内の 各ユーザーに効く上限（for every user）」を意味する。 「安いプランの社員が大勢で使っても、合計さえ超えなければ誰も止 まらない」は誤解。実際は一人ずつ上限に達し、達した人だけが止ま る。 全社合計を1つの数字で頭打ちにする仕組みではない。人数が増えれば 全体の超過額も人数分ふくらみ得る。

    capは「暴走の安全弁」であって「全社予算の蓋」ではない——ここが 要だった。（出典：Kiro Docs / Maximum allowed overage per Kiro profi 13 le）

14. 学びと、これから 超過が「ゼロから立ち上がった日」に気づく。上限に達してから慌てず、余裕の あるうちに引き上げておく。 監視のしきい値を100%ではなく手前に置く。 今回の一件で、通知にはcapの状況も追加。「一人ひとりが、自分の上限にどれ だけ近いか」を見る運用に変えた。 人が増えないからAIに頼る——その選択は変わらない。だからこそ、AIを「止め ない」ための運用を小さく積み上げる。 一人だけ静止した、あの月末の朝を、二度目にしないために。 14

15. Kiro Crewはいいぞ♪ 15