本記事は、Kiroween 2026 の公式ページ「 Kiroween 2026 」（Devpost、英語）と「 Official Rules 」の内容を、2026 年 10 月 31 日時点の情報で日本語にまとめたものです。参加条件や日程の正式な内容は英語の公式ページに従います。各節の原文は、下の表のページで読めます。 この記事の節 原文（英語） 誰が参加できるか Official Rules の「3. Eligibility」 日程 Schedule 、Official Rules の「1. Dates and Timing」 何を作るか、提出するもの Overview の「Requirements」、Official Rules の「4. How To Enter」 賞 Overview の「Prizes」、Official Rules の「8. Prizes」 審査 Overview の「Judging Criteria」、Official Rules の「6. Judges & Criteria」 始めるまでの準備 Resources 、 FAQ Kiro が毎年ハロウィンの時期に開いているハッカソン Kiroween が、今年も始まりました。作品づくりと提出の受付は日本時間 2026 年 10 月 31 日（土）午前 1 時に始まっていて、締め切りは日本時間 12 月 5 日（土）午前 7 時です。オンラインで参加でき、賞金の総額は 10 万ドルです。10 月 31 日の時点で 2,882 人が参加登録しています。 昨年の Kiroween では、数千人の開発者が Kiro を使い、廃れた技術をよみがえらせたり、意外な技術を組み合わせたりした作品を作りました（昨年の告知は「 これが Kiroween です 」）。今年は Kiro IDE、Kiro CLI、Kiro Web に加えて、Kiro Crew も使えます。 誰が参加できるか 居住地で成年に達している個人、3 人までのチーム、法人や団体が参加できます。参加できない国・地域の一覧に日本は含まれていません。個人として参加しながら、別のチームに加わることもできます。 Kiro の一部の機能や AI モデルは地域によって使えないことがあり、自分の地域で使えるかどうかは参加者の責任で確かめることになっています。 日程 公式ページの時刻は米国太平洋時間です。米国の夏時間が 11 月 1 日に終わるため、日本との時差は 10 月中が 16 時間、11 月以降が 17 時間です。 項目 米国太平洋時間 日本時間 参加登録の開始 2026 年 10 月 13 日 8:30 2026 年 10 月 14 日 0:30 作品づくりと提出の開始 10 月 30 日 9:00 10 月 31 日 1:00 Devpost Build Session 11 月 11 日 10:00 11 月 12 日 3:00 無料の Kiro クレジットの申請締め切り 12 月 1 日 12:00 12 月 2 日 5:00 登録と提出の締め切り 12 月 4 日 14:00 12 月 5 日 7:00 審査期間 12 月 16 日 13:00〜2027 年 1 月 29 日 13:00 12 月 17 日 6:00〜2027 年 1 月 30 日 6:00 結果発表 2027 年 2 月 3 日 9:00 ごろ 2027 年 2 月 4 日 2:00 ごろ 締め切りの延長はなく、締め切り後の提出は受け付けられません。 何を作るか Kiro（IDE、CLI、Web、Kiro Crew のどれか、または組み合わせ）を使って動くソフトウェアを作り、次の 4 つのカテゴリーから 1 つを選んで提出します。カテゴリーは昨年と同じで、1 つの作品が入れるカテゴリーは 1 つだけです。 Resurrection（復活）：お気に入りの廃れた技術をよみがえらせます。古くなった技術を今の技術で作り直すか、これからの課題を解くものにします。 Frankenstein（フランケンシュタイン）：ふつうは組み合わせない技術をつなぎ合わせて 1 つのアプリにし、思いがけない力を引き出します。 Skeleton Crew（スケルトンクルー）：分かりやすさを保てるほど小さく、いろいろな用途に使えるほど柔軟なコードの骨組み（テンプレート）を作ります。その骨組みから作った 2 つの別々のアプリで、使い道の広さを示します。 Costume Contest（コスチュームコンテスト）：どんなアプリでも構いませんが、作り込まれた、忘れられないほど不気味なユーザーインターフェースを見せます。不気味なデザインは、アプリの機能を引き立てるものにします。 作品は提出期間（米国時間 10 月 30 日〜12 月 4 日）に新しく作ったものに限ります。10 月 30 日より前に作り始めたものは、Kiroween 2025 の作品も含めて対象外です。フレームワーク、ライブラリ、スターターテンプレートは使えますが、それ以外に以前からあったコードを取り込んだ場合は申告します。Kiro の使い方が足りないと審査員が判断した作品は、失格になることがあります。 提出するもの GitHub の公開リポジトリの URL。GitLab と Bitbucket は使えません。作品を動かすのに必要なソースコード、素材、手順をすべて入れ、リポジトリの画面の About 欄に表示されるようにオープンソースライセンスのファイルを置きます。ルートには、スペック、フック、ステアリングを使ったことを示す /.kiro ディレクトリを置き、 .gitignore に入れないようにします（入れると失格になることがあります）。Skeleton Crew では、2 つのアプリを別々のフォルダーに置きます。 動いているアプリの URL。ログインが必要なら、審査員向けの認証情報と手順を提出フォームに書きます。この欄は公開されず、審査員だけが見ます。 機能を説明する文章。 デモ動画。3 分未満にし（審査員は 3 分を超えた部分を見るとは限りません）、作った端末の上で作品が動く様子を映して、YouTube に公開します。許可を得ていない第三者の商標や、著作権のある音楽などは入れません。 Kiro をどう使ったかの説明。Kiro をどれだけうまく使って作ったかが、審査員に分かるように書きます。 5 つ目の説明に書く内容として、公式ページは次の例を挙げています。 Kiro IDE、CLI、Web、Crew のうち何を使ったか。複数使ったなら、どう違ったか カスタムエージェントを作ったか、使ったか。どの Kiro で試し、作業にどう効いたか エージェントフック でどの作業を自動化し、開発の進め方がどう良くなったか スペック駆動開発 で、Kiro に実装させるスペックをどう組み立てたか。バイブコーディングと比べてどうだったか ステアリング で Kiro の応答をどう良くしたか。いちばん効いたやり方は何か MCP で Kiro の機能を広げたことが、作品づくりにどう役立ったか。MCP がなければ難しかったことは何か プロパティベーステスト（PBT） で、ユニットテストでは見逃したかもしれない問題が見つかったか。どの要件に PBT を使ったか Kiro powers のどれを使ったか。powers がなければ使わなかった外部のツールや連携はあったか 提出物は英語で用意します。英語以外で作った場合は、デモ動画、説明文、テスト手順を含め、提出物すべての英訳を付けます。 賞 賞金の総額は 10 万ドルです。1 つの作品が受け取れるのは、総合賞かカテゴリー賞のどちらか 1 つです。ボーナス賞は、条件を満たせばいくつでも受け取れます。 賞 賞品 数 総合 1 位 30,000 ドル 1 総合 2 位 20,000 ドル 1 総合 3 位 10,000 ドル 1 Best Resurrection、Best Frankenstein、Best Skeleton Crew、Best Costume Contest（カテゴリー賞） 各 5,000 ドル 各 1 ボーナス賞は次のとおりです。応募するボーナス賞は提出フォームで選びます。 賞 賞品 数 条件と選び方 Best Startup Project 10,000 ドル 1 スタートアップの創業者であること。LinkedIn のプロフィールとスタートアップの Web サイトを提出します。 Best Ghost of Kiroween Past 2,000 ドル 1 Kiroween 2025 に参加登録していたこと。昨年の記録と照らし合わせて確かめられます。作品は今年新しく作ったものに限ります。 Best Kiro Crew App 1,000 ドル 1 今回作った Kiro Crew のアプリの GitHub リポジトリと、機能の説明を提出します。アプリのリポジトリを付けた作品のうち点数の上位 50 件から、Kiro チームが役立ち度と技術の新しさで選びます。 Best Student Project（4 つのカテゴリーごと） 各 1,500 ドルと Kiro Pro Max 1 年分 各 1 チーム全員が学生であること。全員分の LinkedIn のプロフィール、学生用のメールアドレス、学年と学位、学校名を提出します。在学の証明を求められることがあります。 Best Demo 1,000 ドル 1 手続きは要りません。総合点で上位 10% に入った作品のうち、審査の観点 Presentation の点数がいちばん高い作品が選ばれます。 Bonus Blog Prize 2,000 Kiro クレジット 100 提出期間中に、Kiro と作品についての記事を外部のブログサービスで公開します。Kiroween 2026 のために書いた記事であることを本文に明記します。記事の URL を提出し、条件を満たした作品のうち点数の上位 100 件が選ばれます。 Social Blitz Prize Kiro Pro+ 3 か月分 5 提出期間中に、先頭に #KiroweenHackathon26 を付けて SNS に投稿し、Kiro のいちばん好きなところと、それで開発の進め方がどう変わったかを書きます。投稿の URL を提出します。Kiro チームが、自分の言葉で書いているか、Kiro についての気づきがあるか、画像や動画の質を見て 5 件を選びます。 Kiro Crew のアプリは、Crew の中で動き、ダッシュボードの画面、エージェント、スキル、MCP サーバー、定期実行の処理などを追加できるものです。作り方は Kiro のドキュメントの「 Apps 」に、Kiro Crew そのものは「 Kiro Crew の紹介 」にまとまっています。 審査 審査は 2 段階です。1 段階目では、テーマに合っているか、Kiro を使っているかを合否で判定します。通った作品は 2 段階目で、次の 5 つの観点からそれぞれ 10 点満点で採点されます（配点は各 20%）。 観点 見られること Potential Impact 実在する利用者の実際の課題を解くと、説得力をもって示せているか。デモで見せた内容がその課題に応えているか。役に立ち、分かりやすく、誰でも使えるか。実際に使われそうか Technological Implementation Kiro をどれだけ深く、うまく使ったか。AI を使った開発の進め方を考えて決めたか。Kiro のいろいろな機能を効果的に使い、試行錯誤しているか Design 技術の試作で終わらず、まとまった製品として体験できるか。デザインが分かりやすく、作り込まれ、意図をもって作られているか Innovation/Idea 発想が独創的で、既存のものと違うか。珍しい技術や公開データセットなどを独自に組み合わせているか Presentation 動画で作品が最初から最後まで動く様子を示せているか。何の課題を、誰のために、なぜ解くのかが伝わるか。分かりやすく、記憶に残るか 昨年からの主な違い 対象の Kiro として Kiro Crew が追加、Kiro Crew のアプリを対象にした Best Kiro Crew App ができました。 審査の観点が、昨年の Potential Value、Implementation、Quality and Design の 3 つから 5 つになりました。Innovation/Idea と Presentation が別の観点になり、動画とピッチの出来も全体の 20% として採点されます。 Best Ghost of Kiroween Past、Best Student Project、Best Demo が新しくでき、昨年の Most Creative と Influencer Judges’ Choice はなくなりました。 Bonus Blog Prize は昨年の 100 ドル × 50 件から 2,000 Kiro クレジット × 100 件に、Social Blitz Prize は 100 ドル × 5 件から Kiro Pro+ 3 か月分 × 5 件に変わりました。 リポジトリは GitHub の公開リポジトリに限られました。 始めるまでの準備 公式ページ の「Join hackathon」から参加登録します。無料の Devpost アカウントが必要です。 Official Rules を、作り始める前に読みます。 無料の Kiro クレジット 4,000 を申請します。申請は Resources タブにあるフォームから、米国時間 12 月 1 日 12:00（日本時間 12 月 2 日 5:00）までです。Kiro のアカウントと Kiro のユーザー ID（AWS アカウントで使っている場合は AWS アカウント ID）が要ります。クレジットのコードは審査のうえ 48 営業時間以内に届きます。コードは米国時間 12 月 4 日までに引き換え、引き換えたクレジットは米国時間 12 月 31 日 23:59（日本時間 2027 年 1 月 1 日 16:59）に失効します。もらえるのは参加者 1 人につき 1 回で、追加はありません。 Kiro の Discord の #kiroween-hackathon チャンネルで、Kiro チーム、Kiro アンバサダー、ほかの参加者に質問できます。米国時間の隔週月曜 9:30（日本時間では火曜 2:30）には、Kiro チームのオフィスアワーもあります。 米国時間 11 月 11 日 10:00（日本時間 11 月 12 日 3:00）の Devpost Build Session では、Kiro での始め方が紹介されます。10 月 31 日の時点では、申し込みの受付はまだ始まっていません。 チームで出る場合は、Participants タブで仲間を探せます。チームは 3 人までで、代表者 1 人がチームとして提出します。 提出フォームの「Enter a Submission」は早めに開いて、下書きをこまめに保存します。締め切り後は提出内容を編集できません。 作品の発想に迷ったら、 Kiroween 2025 の作品ギャラリー で昨年の作品を見られます。登録と提出は Kiroween 2026 の公式ページ から行い、締め切りは日本時間 12 月 5 日（土）午前 7 時です。 著者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

2026年9月14日（月）に開催された「第1回 Google Workspace 活用ユーザー交流会」の模様をお届けします。 本イベントには約20社、30名以上のお客様にご参加いただきました。この記事では、前半の事例講演（第1部）の内容と、私たちGoogle Workspaceを担当しているSEチームが企画・進行を務めた後半のワークショップ（第2部）の様子を中心にご紹介します。 ■ 第1部：ソフトバンクおよびユーザー企業様による活用事例のご紹介 第1部では、ソフトバンクのAI・DX人材育成サービス「Axross Recipe（アクロスレシピ）」担当者より、「ソフトバンクの実践に学ぶA

みなさんこんにちは。 「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”弦音”です。 今回は「何のためにやるの？」がテーマです。 ＜ソフトウェアレビューをエンジニアリングっぽく語ってみる　記事一覧＞ ※クリックで開きます 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2） 【第4回】［#5］レビューの終わり方～レビュー評価・ふりかえり（2/2） 【第5回】［#2］何のためにやるの？ レビューって、何してますか？ 「これ、レビューしておいて」「さて、レビューしようか」 さて、レビューと言われて何を思い浮かべますか？ 誤字脱字を探すのでしょうか。 仕様の抜け漏れを調べるのでしょうか。 設計や実装に問題がないかを評価するのでしょうか。 どれもレビューで行われることですが、これだけだとレビューの目的を十分に表しているとはいえません。 レビューでは、成果物を読み、内容をさまざまな観点から評価します。その結果、問題や改善の余地が見つかれば、指摘や提案として伝えます。 ここで見つける問題や改善の余地とはどのようなことでしょうか。 レビューで指摘すること レビューでまず思い浮かぶのは、成果物に含まれる欠陥をみつけることです。 ここでいう欠陥とは、成果物に含まれる不備があることや、要求・仕様に合っていないことを意味します。 たとえば、次のようなものです。 要求や仕様と異なる内容が記載されている お客様が本当にやりたかったことと仕様がずれている 計算式や条件分岐に誤りがある 必要な処理や仕様が抜けている 前提条件が考慮されていない 仕様の解釈が曖昧で、関係者によって理解が分かれる ドキュメント内に誤字脱字衍字がある このような欠陥は、発見した時点で指摘し、修正する必要があります。 しかし、レビューで扱うのは、すでに存在している欠陥だけではありません。 現在は問題なく動作するように見えても、将来、問題につながる可能性があります。たとえば、データ量が増えると性能が低下する恐れがある、構造が複雑なので保守が難しい、アクセス権限の設定が不十分である、といったケースです。これらはレビューでは欠陥ではなくリスクとして扱います(一緒に扱うこともあります)。 また、欠陥やリスクには該当しなくても、よりよい方法を提案できる場合があります。処理結果は同じでも、より効率的なアルゴリズムを選べるかもしれません。現在の仕様でも要求を満たしていても、別の仕様のほうが利用者にとって使いやすいかもしれません。 このように、レビューで指摘するものには、次の三つがあります。 欠陥 ：要件や仕様を満たさない不備や欠点 リスク ：将来、障害や損失につながる可能性 改善点 ：欠陥やリスクではないものの、よりよくできる点 レビューでは、これらを見つける(指摘する)ことが目的だ、と考えてよさそうです。 レビューで指摘するものの深堀（何に着目しているか） レビューで指摘する欠陥やリスク、改善点にはどのようなものがあるかもう少し見ていきましょう。 たとえば、次のようなものがあります。 表1　レビューで着目しているものの例 機能性 要求された機能を実現できるか 信頼性 障害が発生しにくく、発生時にも適切に対応で 効率性 性能に関すること。必要な処理速度やデータ量に対応できるか 安全性 不正アクセスや情報漏えいなどのリスクを抑えられているか 使用性 利用者にとって理解しやすく、操作しやすいか 保守性 将来の修正や機能追加を行いやすいか 運用性 監視、障害対応、バックアップなどを適切に行えるか 互換性 他のシステムや既存の仕組みと適切に連携できるか 法令・規約への適合性 関連する法令や規約、社内標準などに適合しているか レビューでは、対象となる成果物や開発の段階に応じて、必要な品質の観点から内容を評価します。 たとえば、要求された機能を実現していても、個人情報の扱いが不適切であれば、安全性や法令・規約への適合性に関する問題になります。 また、仕様に適合した処理であっても、プログラムの構造が複雑であれば、将来の変更時に欠陥を作り込むリスクが高まります。 このように、レビューの目的に、機能が成立しているかどうかだけではなく、利用者、運用、保守、性能、安全性、法令などの観点から、成果物に必要な品質が備わっているかを確認するということがあります。 問題を早い段階で発見する これらの問題は一部を除いて(この一部、は大事なので次で説明しますね)、テストで見つければいいじゃないか、と、思う人も多いでしょう。確かに、多くの問題はテストして(モノを動かして)見つけることができます。でも、レビューで見つけることの良さがあるのです。レビューを行うことの良さの一つに開発の早い段階で発見できる、ということがあります。 ソフトウェア開発では、要求、仕様、設計書、プログラムなどの成果物を順に作成していきます。 ある段階の成果物に欠陥やリスクが残ったまま次へ進むと、それらが後続の成果物に引き継がれます。 たとえば、要求に含まれる問題を発見しないまま仕様を作成し、その仕様をもとに設計や実装を進めると、後になって複数の成果物を修正する必要が生じます。 安全性や法令・規約への適合性に関する問題であれば、設計やデータの扱いを根本から見直さなければならない場合もあります。 一方、要求や仕様の段階で問題を発見して指摘できれば、その段階で修正できます。 問題の発見が後の工程になるほど、指摘後に必要となる修正の範囲や影響は大きくなりやすくなります。 そのためレビューの目的には、問題が後の工程へ広がる前に発見し、手戻りや将来のリスクを小さくするということもあるのです。 表2　欠陥の修正：レビューとテストの比較 項目 レビュー テスト 発見してから修正にかかる時間 短い(数分～数時間) 長い(数日～数週間) 修正に必要なプロセス 指摘されたところの修正、再レビュー 原因究明(デバッグ)、修正、ビルド、再現環境の構築、テスト 再確認方法 修正箇所をレビューアが確認 テスト、リグレッションテスト レビューでしか見つけられない問題 先ほど「問題は一部を除いて、テストで見つければいい」の、一部とはどのようなものでしょうか。既に答えの出ているものもありますが、このようなものがあります。 要求そのものがあいまい 記述があいまい 仕様と要求に齟齬がある 変更や保守、障害発生時の対応が難しい コードがコーディング基準に則っていない ドキュメントやコードが読みにくい ドキュメントやコードの管理がめちゃくちゃ 思い当たるものはありますか。このようにレビューでは要求や仕様の不備、設計上のリスク、保守・運用への影響、関係者間での認識の齟齬、標準への遵守、など、テストでは見つけにくい・見つけられない問題を指摘するという目的もあるのです。 複数の視点から評価する レビューは何人で行いますか？ ひとりで行うセルフレビューもありますが、チームや組織で行うものもあるでしょう。 レビューには、作成者とは異なる視点から成果物を評価するという意味もあります。 成果物を作成した人は、その内容や背景をよく理解しています。しかし、前提を疑わなくなったり、自分の見落としに気づきにくくなったりすることがあります。 別の人がレビューすることで、異なる知識や経験を取り入れられます。 データベース、性能、セキュリティ、過去の障害、利用者、運用など、それぞれの立場から成果物を評価することで、一人では発見しにくい欠陥やリスク、改善点が見つかることがあります。 たとえば、次のような指摘です。 「この処理は、データ量が増えたときに性能上のリスクになりそうだ」 「この仕様では、利用者が意図しない操作をする可能性があるのではないか」 「この設計では、将来の機能追加による変更範囲が大きくなりそうだ」 ひとりでレビューする場合でも、一晩寝かせておく、帽子をかぶりなおす(比喩表現です)など、違う人を演じると問題を見つけられるといったハックもありますね。 このように、レビューの目的として、作成者では発見しにくい問題や改善点を見つけ、成果物の品質を高めるということもありそうです。 過去の問題を繰り返さない 複数の人がレビューに参加し、問題や知識を共有することには、さらに別の意味があります。 それは、過去に発生した問題を、次の開発に生かせることです。 たとえば、以前のプロジェクトで、特定の条件を考慮していなかったために、本番環境で障害が発生したとします。 その経験を関係者の記憶だけに頼っていると、時間の経過や担当者の交代によって失われてしまいます。 そこで、過去の障害や問題から得られた知識を、チェックシートやデータベースとしてまとめておき、レビューで評価する観点として活用します。そうすれば、同じような成果物を作成するときに、過去と同じ問題がないかを検討できます。 レビューには、目の前にある成果物の欠陥やリスクを発見するだけでなく、過去の経験を組織の知識として蓄積し、同じ問題を繰り返さないようにする目的もあります。 レビューによって得られる副次的な効果 レビューを通して、作成者とレビュアーが互いの考えや前提を知ることもあります。 「この仕様は、こういう意図で作成されたのか」 「この処理には、このような前提があったのか」 このような理解が進めば、チーム内の認識合わせにつながります。 また、 「このアルゴリズムより、こうしたほうが性能が出る」 「この処理は××ライブラリを応用するとよい」 などの知見を得られることもあります。 さらに、 「この機能の実現はどうしたらよいか」 という議論に発展してしまうこともあります。（組織によってはレビューの場での議論は禁じられていることもあるので注意） このような場に同席することによって、経験の浅いメンバーは、経験者がどのような観点で成果物を評価し、どのような問題を指摘するのか、どのような知見があるのかといったことを学ぶこともできます。 このように、レビューにはコミュニケーションや教育、議論の場を提供するといった目的もあります。 ただし、これは、レビューの第一義の目的ではないでしょう。副次的な効果と捉えてよいと思います（諸説あります）。 まとめ：「レビューってなにするの？」にもいろいろある ここまで見てきたように、レビューと一口に言ってもいろいろな目的があることがわかりました。 成果物に含まれる欠陥を見つける（指摘する） 成果物に必要な品質が備わっているか確認する 問題が後の工程へ広がる前に発見し、手戻りや将来のリスクを小さくする テストでは見つけにくい・見つけられない問題を指摘する 作成者では発見しにくい問題や改善点を見つけ、成果物の品質を高める 過去の経験を組織の知識として蓄積し、同じ問題を繰り返さないようにする コミュニケーションや教育、議論の場を提供する 何を目的とするかによって、レビューで注目する点や、やり方は変わります。 レビューしようと思った時、目的は何かな？ということをまず考えてみてください。そうすればよりよいレビューをおこない、より良い結果を得ることになるでしょう。 この記事を担当したメンバー 弦音（ 吉澤智美／ @tulune ） 物を作るのは好きだけどじっくり壊すのも好き。ということで、レビューやらテストやらの集まりに生息。NPO法人ASTER テスト設計コンテスト担当理事。 https://aster.or.jp/testcontest/ 【連載】ソフトウェアレビューをエンジニアリングっぽく語ってみる｜記事一覧 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2） 【第4回】［#5］レビューの終わり方～レビュー評価・ふりかえり（2/2） 【第5回】［#2］何のためにやるの？ The post 【第5回】［#2］何のためにやるの？｜ソフトウェアレビューをエンジニアリングっぽく語ってみる first appeared on Sqripts .