Kiro Prompt Jam に参加して学んだ、AIの精度を上げるための4つのポイント

2026年3月24日（火）に開催された「Kiro Meetup #7: Prompt Jam — Kiroと一緒に早解きバトルに挑戦！」に参加しました。
本記事では、イベントの内容を振り返りながら、得た学びや気づきを整理します。

１. イベントの概要

AWSが提供する仕様駆動開発の開発ツールである『Kiro』にフォーカスした、AWS主催のイベント「Kiro Meetup」の第7回として開催されました。
これまでの回は「Kiro のアップデートに関する説明」と「Kiro を利用する企業による事例紹介」で構成されていましたが、今回はアップデート情報の説明に加え「ゲーム形式の Jam」で構成され、これまでとは異なる構成となっていました。

AWS Jam とは AWS が提供するハンズオン形式の学習コンテンツの1つです。実際に AWS 環境を操作し、与えられた課題を解決しながら AWS のスキルを習得できます。

• イベントタイトル
  『Kiro Meetup #7: Prompt Jam — Kiroと一緒に早解きバトルに挑戦！』
  
  

• イベント説明

AWSの生成AIアシスタント Kiro を使って、チーム対抗の早解きゲーム Prompt Jam に挑戦しましょう！次々と出題される課題を Kiro と一緒に解いて、正確さとスピードを競います。課題はプログラミングだけでなく、クイズや推理など意外なジャンルも含まれます。プログラミングの経験よりも、Kiro への指示の出し方が勝敗を分けるかも！？チームは会場で組むので、おひとりでのご参加も大歓迎です。
イベント冒頭に Kiro の最新アップデートもご紹介します。最近追加された新機能や活用のヒントをお伝えしますので、すでに Kiro をお使いの方にも、これから試してみたい方にも楽しんでいただける内容です。後半の Prompt Jam で、学んだばかりの機能をさっそく実戦投入してみてください。

• 持ち物
  今回のイベント参加にあたっては自身のPCを持ち込む必要があり、かつ Kiro をインストールしておく必要がありました。
  

２．Kiro のアップデート情報の説明

まず、re:Invent 後の2026年第一四半期の Kiro のアップデート情報の説明が行われました。

主なアップデートは次の通りです。

• ドキュメントの添付機能の追加（IDE）
  9種類のドキュメントのドラッグ&ドロップによる添付ができるようになりました。
  （PDF, CSV, DOC, DOCX, XLS, XLSX, HTML, TXT, Markdown）
  例えば Excel 形式の設計書などを直接読み込むことができるようになったため、今までシステム仕様を Markdown 形式に手作業により変換した上で取り込むといった作業が不要となり、作業効率化が期待できます。
  
  

• Claude Sonnet 4.6 & Opus 4.6 に対応
  2026年2月17日にAnthropic社から公開された「Claude Sonnet 4.6」がKiroでも正式にサポートされました。「Claude Sonnet 4.6」は前モデルである4.5と比較して性能が大きく向上しており、一部ベンチマークは Claude Opus を上回る結果を出しています。
  加えて、最上位高性能モデルである「Claude Opus 4.6」も正式サポートされました。
  また、この両モデル利用にあたっては、コンテキストウィンドウの制限も200kbから1MBに拡張されました。
  
  

• Design First（設計ファースト）Specの実装
  技術設計やシステムアーキテクチャの検討から始める仕様駆動開発の手法が追加されました。
  今までは、要件（Requirements）を定義してから設計（Design）に進んでいましたが、利用技術が明確な場合や非機能要件の制約がある場合は設計から始めた方が適しているケースがあります。
  こういったケースを考慮して、設計（Design）から始めて要件（Requirements）に進む手法として、Design First（設計ファースト）Specが実装されたものです。
  
  

• Pre & Post タスク実行
  Specタスク実行前後に自動処理を挿入するフックを設定することができるようになりました。
  Pre Task と Post Task の2つです。

  • Pre Task：タスクのステータスが"In Progress"に変わる前に発火する
  • Post Task：タスクのステータスが"Completed"に変わると発火する
    
    例えば、Pre Taskとしてセットタスクスクリプトの実行、Post Taskとしてテストの実行、といったものが考えられます。
    
    

今回のアップデートの情報は、AWSから公式資料として展開されましたのでぜひこちらをご参照ください。

３．Prompt Jam

Jamは、2人1組のチームを組み、与えられた課題を Kiro に指示を出して解く、という内容です。
課題を解き、正しい回答と判定されるとチームにポイントが入り、累積ポイントを競うというものでした。

Jam の時間は約40分間、計6問の課題が与えられました。
課題の内容、数は全チーム同じで、どの順番で課題を解いても良いというルールです。

与えられた課題イメージは以下のようなものです。

• 提示されたいくつかの例から法則を見つけて関数を実装する。
• 引数として受け取った文字列のうち特定の文字を変換して返す関数を実装する。
• 特定の法則で作成された画像を解析し、隠れている文字を回答する。
• 指定されたAWS職員の方のとある個人情報を探す。

"Prompt Jam" ということもあり、課題の傾向としてはプログラミング要素は小さく、課題の規則性や論理的な部分を押さえ、いかに Kiro に適切な指示（プロンプト）を与えるか、という点に重点が置かれていたと感じました。
また、約40分間という時間制限かつチーム対抗戦であったこともあり、「スピード感を持って手探りで試行する姿勢」、そして「スピードを得るための工夫」と「課題の解く過程で得られた手法やポイントを次の課題にどう活かすか」がポイント獲得の重要な要素だったと思います。

なお、チームの順位と「どのチームがどの課題をすでに解いたのか」、といった情報は常に正面のスクリーンに表示されていました。

獲得した累計ポイント上位3チームには Kiro の SWAG（景品）がもらえるというおまけ要素もありました。

４．学んだこと・得たこと

４．１ 要点を整理してから指示を出すことで精度の向上が期待できる

課題文をそのまま Kiro に与えるのではなく、以下のように段階的に指示を出すことで回答精度が向上する可能性があると感じました。

① 課題文から要点やパターンを分析、整理させる
② 整理した内容が正しいかを人間が確認する
③ その要点を前提として解答を生成させる

今回私は時間に追われたこともあり、出題された課題の文面をそのまま Kiro に与えました。その状態でも回答まで辿り着いたものもありましたが、回答を導き出せないものや時間を要したものがありました。
Jam 終了後に解き方の解説があり、各課題には明確な傾向やポイントが設けられていたことから、まずはそれらを見つけてから回答を考えさせる、という段階を明確に踏ませることで正解率は大幅に上がった可能性があると考えました。

今回経験したことは、実際にシステムを開発する際にも応用できると考えます。
例えば、大量の要件が記載された文書を読み込ませて Requirements を生成したのち即 Design フェーズに進むのではなく、まずは要件を分析させて傾向や現状見えていない関係性などを洗い出して整理した上で後続工程に進む方が Kiro も正しく目的や要件を理解した上で次フェーズに進むことができ、結果的に品質の向上が期待できると考えます。

４．２ 目的に応じた AI のモデルを指定することの重要性

今回のような課題を分析し答えを導き出す、実業務でいうと例えば大量の情報から要件や関係性を分析する場合は、生成AI のモデルを指定することで意図した結果を得られる可能性が高まると思いました。
具体的には、分析のタスクを指示する際は、"Auto"モードではなく、Claude Opus を指定して生成させる、といったことです。

今回、私は初期設定である"Auto"モードで課題を Kiro に解くよう指示をしましたが、回答に辿り着きませんでした。
一方で、チームメンバーが Claude Opus を指定した上で全く同一の指示を Kiro に与えたところ解くことができた、という経験をしました。

高品質なモデルをすべての場面で使うことはコストもかかることから現実的ではないため、目的に応じて指定をすることが大切と感じました。

４．３ 人間による状況確認や妥当性検証の重要性

生成AI に処理を任せ切るのではなく、途中で人間が状況や状態を確認し、正しい方向に進んでいるのか判断することが重要だと感じました。

具体的には、以下のような進め方です。

① 一定のステップごとに出力を確認する
② 期待する方向とズレていないか判断する
③ 必要に応じてプロンプトを修正する

「特定の法則で作成された画像を解析し、隠れている文字を回答する」という課題では、この重要性を強く実感しました。

Kiro に指示をしたところ、さまざまなアプローチで画像を加工し隠れている文字を探そうと試行錯誤してくれました。しかしながら、セッションに流れてくる Kiro からの応答は芳しいものではなく、ひたすら異なるアプローチで画像を加工生成するということを繰り返していました。

結果的に時間切れでこの課題は回答することができなかったのですが、Jam 終了後に Kiro が加工生成した画像を私が確認したところ、人間の目では隠れていた文字を読み取れるレベルの画像がすでに生成されていました。これは Kiro が認識することができなかったため、Kiro は加工失敗と判断し画像解析・加工を繰り返していたものと考えられます。
これは私が「Kiro に指示を出して回答が出来上がるのを待つ」、という待ちの姿勢が強すぎ、途中経過の確認や過程の成果物の確認を怠ったことが敗因だったと思います。

この結果から、「AIに任せて待つ」のではなく、「途中で人間が方向性を確認し判断する」ことの重要性を強く認識しました。

４．４ 試行結果を記録し、次タスクに活かすことで効率化できる

タスクごとに得られた知見を蓄積し、次のタスクで活かすことで効率化できると感じました。

具体的には、以下のような方法が考えられます。

① 成功・失敗した手順を Markdown などに記録する
② 次のタスク実行時に記録した内容を参照させることで、同じ試行錯誤を繰り返さないよう制御する

私たちのチームも、「回答を作成し提出する」という手順を Markdown ファイルに記録させ効率化を図りました。残念ながら指示の出し方が良くなかったのか、直接効率化につながるような誘導にはならなかったのですが、アプローチ自体は悪くなかったと思います。

他のチームから共有された工夫としては、「正しく回答できなかった一連の手順を Markdown ファイルに記録し、次回以降の課題において参照させ同じ轍を踏まないようにコントロールした」という方法です。

このように、成功・失敗の両方を記録し再利用することで次タスクの効率化が期待できます。

Kiroには Steering File など、動作を誘導する仕組みが用意されています。これらを活用することで、仕様駆動開発に限らず、仕様検討や調査といったタスクにも応用できると感じました。

５．さいごに

今回の Prompt Jam に参加して、生成AI に直接的な指示を与えて結果を待つのではなく、プロセスを考えた上で指示を出すことの重要性を実感しました。

指示を出す前の要点の整理、途中の人間による状況確認、そして生成の過程で得た内容の記録と再利用、といった一連の流れを意識することで、生成精度や効率性が大きく変わると感じています。

そして、これらは実際のシステム開発においても応用できる考え方と思います。

生成AI 任せにするのではなく、指示内容を含め人間がどういったことをすれば意図した結果を得られるのか、を考えながら利用していきたいと思います。