AWS Top Engineers 向け GameDay、Kiro「も」チームメンバーに迎えて優勝してきた

AWS Top Engineers 向け GameDay、Kiro「も」チームメンバーに迎えて優勝してきた

AWS Top Engineer向けGameDayにて2位と約33%の大差で優勝!AIエージェント「Kiro」をチームメンバーとして迎え、いかに指揮・統制したのか。人間が「情報のハブ」として意思決定に専念、AIの実行力を最大限に発揮させることが勝因でした。
2026.02.20

2026年2月、Japan AWS Top Engineers 向けに開催された AWS GameDay "Microservice Magic" に参加し、13チーム中1位(450,585pt)で優勝しました。

チームは所属企業の異なる AWS Top Engineer 2名に、次世代を担う若手ITスペシャリスト1名を加えた3名構成。私はこのチームで、AIエージェントを指揮・統制する役割を主に担いました。

この記事では、ユニコーンレンタル社のNDA(守秘義務)を遵守しつつ、トップエンジニアが集う戦場で「AIとどう共闘したのか」「なぜこれほどの差がついたのか」という戦略の舞台裏を共有します。


最終スコア・順位

順位 チーム名 スコア
1 Amazing13 450,585
2 四天王 339,659
3 マルチクラウドセキュリティの教科書 336,546
4 Team EHA 305,584
5 We love Dr.Werner 295,773

GameDay とは

AWS が主催する、チーム対抗のクラウド運用競技です。テーマや形式は毎回異なり、構築力が問われるもの、運用力が問われるもの、セキュリティが中心のものなど様々です。

今回のテーマは「Microservice Magic」。与えられたAWS環境上でマイクロサービスを扱う内容で、「運用力が問われる回」でした。

参加チーム数は13。制限時間は約3時間半でした。


AIエージェント(Kiro)の活用

今回の GameDay では、Amazon の AI コーディングアシスタント Kiro が公式に提供されていました。VSCode Server にはプリインストール済みで、SSOログインによるライセンス認証を行うだけですぐに使える状態。個人端末での利用も案内されており、最上位モデルの Opus 4.6 も従量課金を気にせず自由に使える環境でした。

昨年末に参加した「Security Battle Royale」でも Kiro を活用していましたが、当時はまだ最上位モデルである Opus は利用できない状態でした。

https://dev.classmethod.jp/articles/aws-gameday-2025-security-battle-royale/

今回の GameDay で真価を発揮したのは、間違いなく Kiro の Opus 4.6 です。状況の把握、原因の推定、対策の立案——あらゆる場面において、以前のモデルとは次元の違う性能を実感しました。

個々の応答(レスポンス)自体は決して速いわけではありません。しかし、それを補って余りある推論の深さと、一発で正解を射抜く精度の高さがありました。試行錯誤の手数が劇的に減ったことで、結果として問題解決までのスピードが圧倒的に引き上げられたと感じています。

終盤、同モデルの応答が頻繁にタイムアウトし、Sonnet 4.6 に切り替える場面もありました。ただ、この時点では主要な作業がほぼ完了しており、大きな影響はありませんでした。結果的に、Opus のポテンシャルを最大限に引き出せた競技だったと思います。

やらせたこと

  • インフラの構築・設定変更
  • 異常発生時の原因調査と対応
  • 対策の設計・実装・改善
  • エージェント間でコンテキストを共有するための工夫

CLI版を選んだ理由

Kiro にはIDE統合版もありましたが、今回はCLI版を選択しました。
IDE統合版は対話的なアシストには優れていますが、今回のような高密度な並列作業においては、CLI版が持つ『実行環境のポータビリティ』と『多重化の容易さ』が大きなアドバンテージとなりました。AIを単なるツールではなく、独立した実行ユニットとして扱う場合、CLIの方が圧倒的に制御の自由度が高いと感じています。

複数エージェントの並列運用

最初から大量並列を狙っていたわけではありません。序盤はエージェント1体にタスクを渡し、処理を待つ間は運営が用意してくれたコーヒーやお菓子を楽しんでいるような感覚でした。
(GameDayは飲み物や軽食が充実しており、運営からもリフレッシュが推奨される、もてなしの手厚いイベントです)。
しかし、エージェントのバックグラウンド処理の待ち時間が増えてくると、リフレッシュから戻った人間がターミナルを追加し、新しい Kiro を立ち上げ、コンテキストを共有して戦線に投入する——という流れが自然に生まれました。

一般的に「戦力の逐次投入」は悪手とされますが、AIエージェント相手ではこれが機能しました。新しいエージェントにコンテキストを共有するコストが非常に低かったからです。

運用サイクルはこうでした:

  1. エージェントにタスクを指示し、処理中は別のエージェントや他の作業に移る
  2. 完了したエージェントから状況報告を求める
  3. コンテキストが溜まったエージェントはCompact(コンテキスト圧縮)させて休憩
  4. Compact完了後、進捗を確認してから作業を再開

エージェント間でコンテキストを共有する工夫を行い、各エージェントが自律的に状況を把握できるようにしました。

作業の並列化により対応のスピードは大幅に向上しました。問題が発生した際も、インシデント対応の基本である「暫定対策」と「原因調査」をエージェント間で分担できたことが、短時間での対応力向上につながりました。一方で、エージェント間で操作の競合が発生する場面もあり、協調の仕組みには改善の余地が残りました。

作業環境の冗長化

AIに頼る作業スタイルでは、作業環境自体がSPOF(単一障害点)になりえます。今回、代替手段を用意していたことで作業を止めずに済む場面がありました。「作業環境の冗長化」はAI活用時代の必須事項だと実感しました。

人間の役割 — 情報のハブと意思決定

AIエージェントに任せきりだったかというと、全くそうではありません。「人間にしかできない仕事」が明確にありました。

まず、AIが安定稼働するまでの初期立ち上げフェーズでは、チームメンバーが手動操作で土台を作りました。自分がAIの準備に集中できたのは、メンバーが序盤を支えてくれたからです。AI安定化後も、メンバーは異変の検知やパトロール的な監視——いわばセンサーとして機能し続けました。人間はソロではありませんでした。

その上で、AIエージェントとの連携における人間の役割は2つありました。

AIエージェントは目の前のタスクを完遂することに長けていますが、「過去(既存のコードや設定)」を見るのは得意でも、「今(リアルタイムの状況変化)」や「未来(これから何が起きそうか)」を統合するのは苦手です。CLIベースのエージェントはブラウザ上の情報に直接アクセスできないという制約もあります。

1つは、AIがアクセスできない情報を適切に咀嚼して伝える「情報のハブ」。もう1つは、状況の変化に応じて「今はこれに集中せよ」と優先順位を再定義する意思決定です。

AIは与えられたタスクを驚くほど速く的確にこなしますが、「何を見せるか、いつ見せるか、どのタスクを捨てるか」は人間が決める必要がありました。今回の勝因の一つは、メンバーが作った土台の上で、この「人間による意思決定」と「AIの実行力」がうまく噛み合ったことだと思っています。


振り返って思うこと

Kiro に指示を出して作業を進めてもらう体験は、優秀なエンジニアが複数名いる感覚に近いです。ただし、AIエージェント同士の協調は人間のチーム以上に難しいことも実感しました。全てが順調だったわけではなく、競技の焦りの中で省略してしまった「当たり前のこと」が失点につながる場面もありました。

それでも、人間がオーケストレーターとしてAIエージェントを束ねる形は、チーム戦において大きなアドバンテージでした。AIをいかに高度に使いこなすか——その「使い手の練度」が問われる時代になったと感じています。

GameDay は回によって求められるものが異なりますが、AIエージェントの活用は今後ますます重要になると感じています。機会があればぜひ参加してみてください。

gameday202602

この記事をシェアする

FacebookHatena blogX

関連記事