Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
一人だけ、Kiroが静止する日
Search
Hideyuki Nagata
September 10, 2026
Programming
57
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
一人だけ、Kiroが静止する日
【関西開催】Amazon Quick & Kiro Festival!!
https://kansai-cbs.connpass.com/event/402868/
での登壇資料です。
Hideyuki Nagata
September 10, 2026
More Decks by Hideyuki Nagata
See All by Hideyuki Nagata
源内ハンズオン概要編
hideg
0
250
2025年の活動の振り返り
hideg
0
200
re:Inventから予想するAlexa+スキル開発
hideg
1
2.8k
JAWS UG AIML支部の紹介
hideg
0
150
Amazon Nova Canvasの新機能Virtual try-onで実装するプリクラ風アプリ
hideg
0
330
Generative AI Use Cases (GenU)カスタマイズに挑戦
hideg
0
560
generative-ai-use-cases(GenU)の推しポイント ~2025年4月版~
hideg
1
900
自己紹介
hideg
0
210
生成AI対応版Alexaへの期待
hideg
1
250
Other Decks in Programming
See All in Programming
【DroidKaigi 2026】「アクセシビリティを利用するとき、 アクセシビリティもまたこちらを利用している」 〜マルウェアによる攻撃と防衛について〜
halunoyo
0
410
[GoCon2026] When Goroutines Are Not Enough: Runtime Locality in High-Throughput Go
takehaya
3
390
Foundry Localでエージェント開発
seosoft
0
140
Snowflakeで業務アプリを作ろう。 Snowflakeのアプリ機能解説&実践ガイド
ayumu_yamaguchi
1
140
Hono + Inertia + React で LP を構築した話
oukayuka
2
220
[DroidKaigi 2026] Bring your own phones to Gradle Managed Devices
f2lk
0
110
From 6 People Classroom Meetup to 100 People Regional Conference / FOSS4G Hiroshima 2026
furukawayasuto
0
110
Seeing Through Serverless: Observability for AWS Lambda with ADOT and CloudWatch Application Signals
seike460
PRO
1
120
kubernetes コンポーネント開発入門 / 新卒N年目の勉強会&交流会!〜〇〇への誘い〜 #n_study
mazrean
0
170
Deep dive into the select statement (GopherCon UK)
jespino
0
170
新人はどこまで自力でやり、どこからAIに頼るべきか/エンジニア育成に向き合う_先輩たちの悩みと知見共有会
toppan_digital_dev
1
570
業務時間外もAIに働いてもらう話
colorful12
3
10k
Featured
See All Featured
Build your cross-platform service in a week with App Engine
jlugia
234
19k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.6k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
520
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
6.1k
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
230
Optimizing for Happiness
mojombo
378
71k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
480
The SEO Collaboration Effect
kristinabergwall1
1
550
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
25
2.1k
How to train your dragon (web standard)
notwaldorf
97
6.8k
Design in an AI World
tapps
1
310
Transcript
一人だけ、Kiroが静止する日 AIエディタの「超過の、そのまた上限」に、月末にぶつかった中小企業の実話 長田英幸 / 【関西開催】Amazon Quick & Kiro Festival!! /
2026-09-10
02
この話について 生成AIに開発を頼らざるを得なくなった小さな会社の記録です。 Kiroのコスト管理を整える中で、ある落とし穴に落ちて這い上がるま で。 派手な技術の話ではなく「知らなかった仕様に、いちばん困るタイミ ングで気づいた」という運用の話。 03
背景:エンジニアが増えない、だからAIに頼る 中小企業。エンジニアを募集しても、なかなか採用に至らない。 人が増えないなら、今いるメンバーが生成AIを使いこなすしかない—— そういう空気が社内にできた。 Kiroの契約は会社としてIAM Identity Centerで一元管理。誰がどのアカ ウントを使い、どれだけ消費するかを会社側で把握できる状態が出発 点だった。 04
きっかけ:「今月のAWS代、高すぎ!」 ある月「今月のAWSの請求、高すぎないか」と声が上がり、私にKiroの クレジット利用状況の監視指示が下りた。 ところが管理コンソールのKiroのページでは、社員一人ひとり(Kiroア カウント単位)まで絞り込めなかった。 全体の消費は見えても「誰がどれだけ使っているか」が見えない。監 視しろと言われたのに、肝心の粒度が足りなかった。 05
解決策:利用状況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
07
08
通知の設計:毎朝、そして毎週の始業時に Botの動き方もKiroに相談しながら決めた。 私個人宛て——毎朝の勤務開始時に利用状況が届くように。 会社のグループチャット——毎週の営業開始日(週明けの始業時間)に サマリーが届くように。 人が「見に行く」のではなく、通知が「向こうからやってくる」形に 。この時点では正直「これで安心」と思っていた。 09
事件:月末の朝、「Kiroが動かない!」 月末が差し迫ったある日の朝、出社したエンジニアの第一声が「Kiro が動かない!」だった。 よりによって月末。幸い長期案件で、月末=納期の締め日ではなかっ たのが救い。 しかも止まったのは全員ではなく、その一人だけ。何が起きているの か、最初はまったく分からなかった。 10
正体:超過にも、さらに上限があった 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
対処のつまずき:すぐには上がらなかった 必死にKiroに相談しながら、Service Quotasの上限引き上げをリクエス ト。ところが、すぐには反映されない。 意外にもオペレーター対応(サポート経由)に。AWSサポートに起票 し英語でも問い合わせ、途中でなぜか一方のケースがクローズされる など一筋縄ではいかず。 その日は該当エンジニアはコーディングができず、資料作成などに切 り替えて過ごした。 後で調べると、Service
Quotasは「小さい増加は自動、大きい増加はサ ポート送りで時間がかかる」標準的な挙動。月末の駆け込み申請が一 番響いた。 12
いちばん大事な誤解:capは「1人ずつ」に効く capはアカウントに1つ設定する値。だが公式には「プロファイル内の 各ユーザーに効く上限(for every user)」を意味する。 「安いプランの社員が大勢で使っても、合計さえ超えなければ誰も止 まらない」は誤解。実際は一人ずつ上限に達し、達した人だけが止ま る。 全社合計を1つの数字で頭打ちにする仕組みではない。人数が増えれば 全体の超過額も人数分ふくらみ得る。
capは「暴走の安全弁」であって「全社予算の蓋」ではない——ここが 要だった。(出典:Kiro Docs / Maximum allowed overage per Kiro profi 13 le)
学びと、これから 超過が「ゼロから立ち上がった日」に気づく。上限に達してから慌てず、余裕の あるうちに引き上げておく。 監視のしきい値を100%ではなく手前に置く。 今回の一件で、通知にはcapの状況も追加。「一人ひとりが、自分の上限にどれ だけ近いか」を見る運用に変えた。 人が増えないからAIに頼る——その選択は変わらない。だからこそ、AIを「止め ない」ための運用を小さく積み上げる。 一人だけ静止した、あの月末の朝を、二度目にしないために。 14
Kiro Crewはいいぞ♪ 15