本記事は、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 年 10 月 30 日に Kiro ブログで公開された「 Spec it safe: shift left and harden your specs with security requirements 」を翻訳したものです。 SDD の広がりと、その死角 仕様駆動開発 (SDD) は、大規模なチームのソフトウェア開発のやり方を変えつつあります。プロンプトだけに頼るのではなく仕様を書き、それに沿って AI コーディングエージェントに設計、タスク、実装を進めさせます。本記事ではこの流れを Specify → Plan → Execute と略して書きます。ただし、ほとんどの 仕様に書かれているのは、ソフトウェアが何をすべきか、つまりユーザーが目にして実際に使う機能です。誤用されたときにどう耐えるかは書かれていません。機能要件は、もともと動かせば正しさが分かります。ログインが壊れていれば、誰かが気づきます。セキュリティ要件はそうでないことが多く、インジェクションや認可の欠陥が開いたままでも、アプリはすべての機能チェックに通ることがあります。失敗するケースを誰も試さないからです。そのため、仕様にセキュリティの制約が欠けていると、エージェントにはセキュリティを目標に作り込み、繰り返し改善していく対象がありません。エージェントはフレームワークの既定の動作に頼ります。それで足りることもあれば穴が残ることもあり、仕様にはどちらなのかを問う記述がありません。 このギャップを埋める方法は、より良いモデルを足すことでも、最後にセキュリティレビューを付け足すことでもありません。作業を前倒しして、自分で完全にコントロールできる層、つまり仕様に移すことです。仕様にセキュリティ上の義務を書けば、コーディングエージェントには作り込み、繰り返し改善していく具体的な目標ができます。コードができあがってからレビュアーが見つけるのを待つ必要はありません。これは、設計が固まってからセキュリティを後付けする考え方から、最初からセキュリティを前提に設計する考え方への転換です。たいていはアーキテクチャにも良い効果があります。セキュリティ要件を早い段階で書いておくと、よりすっきりした設計につながることがあります。後から改修するのではなく要件を前提に組み立てるので、要件を満たすのが簡単になるからです。仕様の品質は、コードが 1 行も無いうちから作り込めます。仕様のハードニング (specification hardening) は、そのために設計しました。 仕様のハードニングのご紹介 仕様をハードニングする Kiro Power を紹介します。SDD のワークフローにステップを 1 つ追加するプラグインです。機能要件を書き終えてから計画を始めるまでの間に、EARS 形式の要件を読み、その書き方から想定される脆弱性の種類を指摘して、追跡とテストができるセキュリティ上の義務を提案します。提案は、CWE の脆弱性タイプを再利用できるセキュリティ上の義務に対応付けた、厳選したライブラリから作られます。そのため、仕様のハードニングの提案はモデルの推測ではなく、既知の脆弱性に基づいています。提案が的外れにならないのは、要件そのものから導くからです。仕様のハードニングが義務を提案するのは、ユーザー入力、認証、データの扱いなど、最初の書き方がその義務で対処する脆弱性を示しているときだけです。そのため、アプリケーションが実際に行うことに合った制約だけが提示されます。セキュリティは後のコードレビューではなく仕様そのものに入ります。それでも、後段にセキュリティレビューのステップを入れることを強くお勧めします。 図 1: spec のハードニングは、Kiro の Specify → Plan → Execute の流れに、コードを書く前の早い段階の管理ポイントとして、ハードニングのステップを 1 つ挿入します。 仕様のハードニングは 上流の管理ポイントであり、実行時のセキュリティ境界ではありません。 よくある脆弱性タイプが抜け落ちる可能性を減らし、セキュリティの意図を明示的で、追跡でき、テストできる形にします。生成されたコードを検証したり、脆弱性が無いことを証明したりはしません。SAST、DAST、依存関係のスキャン、人によるレビューの代わりにもなりません。 仕様のハードニングが対象とするもの： 要件として表現でき、かつ EARS の書き方から検出できる脆弱性タイプです。インジェクション、認証の欠如、弱い認証情報の保存、エンコードされていない出力、そしてこれらに類する抜け漏れが当てはまります。 仕様のハードニングが対象としないもの： データフローやコードレベルの解析が必要な脆弱性、字句上の手がかりが無い認可の抜け、実行環境、インフラストラクチャ、依存関係に関するものすべてです。これらには引き続き、人のレビュアーと後段のツールが必要です。 仕様ハードニングエンジンの中核：CWE から仕様への対応付けライブラリ すべての脆弱性を仕様で直せるわけではありません。多くはアーキテクチャに起因するか、コードでしか見えません。しかし、 要件として表現できる CWE クラスを選んで、再利用できるセキュリティ上の義務に対応付けることはできます。 この義務を正しく実装して検証すれば、それぞれの脆弱性のよくある形を緩和できます。仕様のハードニングは、この対応付けを決定的に動く TypeScript のライブラリと CLI として提供しているので、どの制約も再現できます。 CWE 脆弱性 トリガー条件 必要な EARS 制約 CWE-89 SQL インジェクション 要件が外部入力を使ってデータベースを照会する すべてのクエリをパラメータ化クエリ / プリペアドステートメントだけで実行し、文字列の連結は決して使わない。 CWE-862 認可の欠如 プリンシパルが所有するリソースを返す、または変更する 要求元のプリンシパルがリソースを所有しているか、明示的な許可を持っていることを確認する。 CWE-306 認証の欠如 エンドポイントやリソースを公開する 処理の前に、有効な認証済みセッションまたは署名付きトークンを必須にする。 CWE-79 クロスサイトスクリプティング ユーザーが入力したコンテンツをブラウザで表示する すべての出力をコンテキストに応じてエンコードし、多層防御として Content Security Policy ヘッダーを追加する。 CWE-522 不十分な認証情報の保護 パスワードを保存または検証する 強力な適応型関数でパスワードをハッシュ化する (平文や元に戻せる形式は決して使わない)。 CWE-434 無制限のファイルアップロード ファイルのアップロードを受け付ける マジックバイトを MIME の許可リストと照合し、サイズに上限を設け、Web ルートの外に保存する。 CWE-639 IDOR / BOLA 呼び出し元が指定した識別子でオブジェクトを取得する 返す前に、オブジェクトを所有するテナントが認証済みの呼び出し元と一致することを確認する。 ライブラリには、 8 つのセキュリティ領域にわたる 60 の CWE の対応付け が含まれています (インジェクション、認証、認可、データの露出、暗号、入力の検証、セキュリティの設定ミス、ビジネスロジック)。脆弱性は MITRE の Common Weakness Enumeration (CWE) から取っています。どれを選ぶかと検出パターンは、主に OWASP Top 10:2021 と Amazon Q Developer Detector Library (旧 CodeGuru) をもとにしています。各対応付けには、OWASP のカテゴリーと、人が割り当てた深刻度が付いています。表の制約は代表的な例を言い換えたもので、どのアーキテクチャにもそのまま使える完全な対策ではありません。 エンジンの仕組み 仕様のハードニングは、要件ファイルごとに 3 段階のパイプラインを実行します。エンジンの動作は決定的です。ツールのバージョン、対応付け、オプション、ハードニング前の入力が同じなら、同じ仕様には常に同じハードニングが施されます。その後に続くエージェントの意味的なレビュー (図 2) は決定的ではありません。 1. トリガーの検出 エンジンは、2 種類の字句上のシグナルを使って、各要件を 60 の CWE の対応付けと照合します。部分文字列のキーワード (「database」「upload」「session」) と、正規表現のパターンです。ヒットを組み合わせて上限のあるスコアにし、スコアがしきい値 (既定は 0.3) を超えた CWE に印を付けます。照合は意味ではなく字句に基づくので、書き方に明示されていない脆弱性は見逃すことがあります。 2. カバレッジの確認 エンジンは、印を付けた CWE ごとに、必要な基本要素がすでに仕様に書かれているかを確認します。たとえば、パラメータ化クエリの条項、所有者の確認、出力のエンコードです。提案が作られるのは、まだ対応されていない抜けだけです。確認はファイル全体を対象に字句で行うので、ある要件に書かれた対策によって、別の要件への提案が出なくなることがあります。 3. 制約の提案 エンジンは処理を止めるのではなく、足りない制約を EARS の項目として 1 つずつ挿入します。プレースホルダーは、可能なら元の要件の言葉で埋め、できないときは一般的な言い方 (「a user」「the resource」) にします。挿入した各行には提案 ID と [SECURITY: …] タグが付くので、作成者は変更を差分としてレビューできます。複数の対策を重ねる対応付けもあります。CWE-89 では、パラメータ化クエリの条項と入力の検証の条項の両方が追加されます。プログラムから使う API は、各制約の CWE、優先度、根拠をまとめた構造化レポートを返します。CLI は制約をファイルに直接書き込み、このレポートは保存しません。 仕様のハードニングが読むのは仕様だけで、コードは読みません。要件の文面が示す、CWE に由来する制約を提案し、作成者がそれを実際に動いているシステムと照らし合わせて確かめます。こうした不変条件を明示しておくと、守り続けることもテストすることも容易になります。 図 2: エンドツーエンドのワークフロー。エンジン (紫) は各要件を 60 の CWE の対応付けと照合し、足りない制約を EARS の [SECURITY:] 項目として書き込みます。エージェントの意味的なレビュー (オレンジ) は、認可に関する弱いヒットを確認し、確認できた抜けごとにその分野に合った制約を追加します。仕様が変わったら、同じファイルでエンジンを再実行すると、新しい要件と変更された要件だけがハードニングされます。どの要件をレビュー済みかは、レビューマーカーでエンジンに伝わります (点線のループ)。 具体例：患者記録の検索 これがなぜ重要かを理解するいちばん簡単な方法は、同じ機能を 2 回リリースしてみることです。1 回目は機能だけを書いた仕様から、2 回目は仕様ハードニングエンジンでハードニングした仕様からです。あるデジタルヘルスのスタートアップが、医師が患者名で診療記録を検索できる患者ポータルを作っています。プロダクトマネージャーは、多くの人が書くであろう要件を書きます。 要件：最低限の機能だけで、セキュリティには触れていない (EARS、イベント駆動) WHEN a physician searches for clinical notes by patient name, THE SYSTEM SHALL return all matching clinical notes from the records database. 一見すると完全に見えますが、 最低限の機能 しか書かれていません。どう一致させるか、ページング、結果が空のとき、どのフィールドを返してよいか、誰が実行できるかについては何も書かれていません。コーディングエージェントは、次のような Express.js のエンドポイントを生成するかもしれません (説明用の疑似コード)。 明示的なセキュリティの制約が無い場合 (説明用の疑似コード) // Agent-generated code from the security-silent spec app.get('/clinical-notes/search', async (req, res) => { const { patientName } = req.query; const notes = await db.query( `SELECT * FROM clinical_notes WHERE patient_name LIKE '%${patientName}%'` ); res.json(notes); }); ここには 2 つの脆弱性が埋め込まれています。SQL 文に文字列を埋め込んでいる箇所は、教科書どおりの CWE-89 (SQL インジェクション) です。 %' OR '1'='1' -- のような入力を与えると、常に真になる条件が追加されて残りがコメントアウトされ、すべての行が返されます (正確な構文はデータベースによって異なります)。そして、このエンドポイントには認証の確認がまったくありません。これは CWE-306 (Missing Authentication for Critical Function、重要な機能に対する認証の欠如) です。3 つ目のより根の深い問題、つまり認証済みの臨床医がすべての患者の記録を見てよいのかという問題は、後で取り上げます。抜け落ちは要件の段階で起きており、実装も既定では防御的になっていませんでした。 では、同じ要件を仕様ハードニングエンジンにかけてみます。字句ベースの検出器は 2 つの脆弱性タイプ (CWE-89 SQL インジェクションと CWE-306 認証の欠如) に印を付け、枝番付きの EARS 制約を 7 つ要件に書き戻します。下に示すとおり、それぞれに追跡できる提案 ID と [SECURITY: …] タグが付きます。3 つ以上の要件で提案された条項は、共通の ## Security Baseline (Cross-Cutting) セクションに 1 回だけ移されます。これはヒューリスティックなので、差分で確かめてください。 レビュー後に requirements.md に書き戻された、仕様のハードニングの出力。エンジンは 2 つの CWE にわたって 7 つの義務を追加します。CWE-89 (パラメータ化クエリ) の 1.1〜1.2、CWE-89 (入力の検証) の 1.3〜1.4、CWE-306 (認証) の 1.5〜1.7 です。続いてレビューの工程 (Power では Kiro エージェントが、CLI では自分で行います) で、1.8 (データの最小化、CWE-200) と 1.9 (診療関係に基づく認可、CWE-862) を追加します。ここでは代表的な条項だけを示し、残りは省略しています。プログラムから使う API は、エンジンが追加した各制約の CWE、優先度、根拠をまとめた構造化レポートも返します。CLI はこのレポートを保存しません。 1. WHEN a physician searches for clinical notes by patient name, THE SYSTEM SHALL return all matching clinical notes from the records database. 1.1. SEC-REQUIREMENTS-REQ-1-EC-89-1-1 [SECURITY: parameterized-query] THE SYSTEM SHALL execute all database queries using parameterized statements or prepared statements only. 1.5. SEC-REQUIREMENTS-REQ-1-EC-306-1 [SECURITY: authentication-required] IF a request that the specification does not explicitly allow without authentication arrives without a valid authenticated session or signed token, THEN THE SYSTEM SHALL reject the request. … engine clauses 1.2–1.4 and 1.6–1.7 omitted for brevity. 1.8. SEC-REQUIREMENTS-REQ-1-SEM-200-1 [SECURITY: data-minimization] THE SYSTEM SHALL return only the patient name, note date and summary fields of each matching clinical note. 1.9. SEC-REQUIREMENTS-REQ-1-SEM-862-1 [SECURITY: ownership-verification] THE SYSTEM SHALL return clinical notes only for patients with whom the requesting physician has an active care relationship. ID は次のように読みます。 SEC-REQUIREMENTS-REQ-1-EC-89-1-1 は左から順に、 SEC (セキュリティの制約)、 REQUIREMENTS-REQ-1 ( requirements.md の 1 つ目の要件。「Requirement N」という見出しのある仕様では、Requirement 1 の基準 1 を表す REQ-1.1 になります)、 EC-89-1 (CWE-89 の対応付けにある 1 つ目の EARS 制約テンプレート) を表します。末尾の 1 は条項の番号で、1 つのテンプレートが複数の EARS の行に展開されるときだけ付きます。条項が 1 つだけの EC-306-1 に末尾の番号が無いのはこのためです。レビューで追加した条項では、 EC の代わりに SEM を使います (例： SEM-862-1 )。 開発者はハードニングされた仕様の差分をレビューし、条項ごとに判断します。エンジンの条項はインジェクションと認証をカバーしていますが、返すフィールドを絞るべきだと示す言葉は要件に無かったので、レビューで 1.8 を追加します ( --semantic-all を付けて実行すると、CWE-200 も候補として表示されます)。仕様に問題が無ければ、エージェントはそこからコードを生成し、推測ではなく明示された義務に沿って作ります。次の実装候補は、フェイルクローズの 401 でエンドポイントを保護し (1.5〜1.7)、検索語を検証し (1.3)、明示的な LIKE のエスケープを付けてパラメータとしてバインドし (1.1〜1.2)、1.8 が挙げたフィールドだけを返します。 適合性を確かめるための下書き：パラメータ化クエリ (1.1〜1.2)、入力の検証 (1.3)、認証 (1.5〜1.7)、データの最小化 (1.8) の条項を満たしていますが、まだ実際の患者データに使えるほど安全ではありません。1.9 をまだ守っていないからです。 // Implementation candidate for the security clauses above. authenticate, req.user, // and the schema are application-specific placeholders; still NOT object-level authorized (1.9). app.get('/clinical-notes/search', authenticate, async (req, res) => { // 1.5–1.7: fail closed if the request is not authenticated; return no data if (!req.user) return res.status(401).end(); const raw = String(req.query.patientName ?? '').trim(); // 1.3: reject blank or too-short terms so an empty search cannot match every row if (raw.length < 2) return res.status(400).end(); // 1.1–1.2: parameterized query; escape LIKE metacharacters incl. the // escape char itself, with an explicit ESCAPE clause const term = `%${raw.replace(/[\\%_]/g, c => '\\' + c)}%`; // 1.8: return only the fields the requirement names (data-minimization) const notes = await db.query( `SELECT patient_name, note_date, summary FROM clinical_notes WHERE patient_name ILIKE $1 ESCAPE '\\' ORDER BY note_date DESC`, [term]); res.status(200).json(notes.rows); }); 同じくらい重要なのは、ツールが印を付けたのに書き込まなかったものです。認証済みの医師なら誰でも、どの患者の記録でも読めてしまいます。診療関係の確認が無いからです。これは認可の確認の欠如 (CWE-862) ですが、スコアがしきい値を下回っています。ツールはこれを書き込む代わりに、レビュアーが確かめるべき意味上の候補として示します。Kiro Power ではエージェントが、CLI では自分がレビュアーです。確認された抜けは、その分野に合わせた条項 1.9「要求している医師と有効な診療関係にある患者の診療記録だけを返す」になります。するとクエリは、認可の範囲に絞られたものになります。 認可の範囲に絞ったクエリ：パラメータ化された認証済みの読み取りに、レビューで追加した診療関係の条件 (1.9、CWE-862) を加えています。必要な ILIKE の動作をする PostgreSQL のロケールと照合順序を前提にしています。スキーマとポリシーは説明用です。 // Authorization-scoped query (1.9): parameterized, authenticated read plus the review-added CWE-862 // care-relationship constraint. Schema and policy are illustrative. EXISTS enforces // an ACTIVE relationship without duplicating notes when several rows match. const notes = await db.query( `SELECT cn.patient_name, cn.note_date, cn.summary FROM clinical_notes cn WHERE cn.patient_name ILIKE $2 ESCAPE '\\' AND EXISTS ( SELECT 1 FROM care_relationships cr WHERE cr.patient_id = cn.patient_id AND cr.physician_id = $1 AND cr.status = 'active') ORDER BY cn.note_date DESC`, [req.user.physicianId, term]); この例では、決定的なハードニングによって、2 つの CWE にわたる 7 つの義務が明らかになりました。データの最小化のルールと、その分野に固有の認可のルールは、やはりレビューから生まれています。 仕様のハードニングはセキュリティの判断を補うものであり、置き換えるものではありません。 実行方法 仕様のハードニングは Kiro Power としてパッケージ化されており、 GitHub の sample-kiro-spec-security-hardening リポジトリ で入手できます。実行方法は 2 つあります。 Kiro Power から実行する。 機能要件が固まったら、Kiro に「harden my specs」と頼みます。 harden-spec スキルは次のことを行います。 同梱のエンジンを見つけ、初回の利用時にビルドします。 .kiro/specs/*/requirements.md に対してエンジンを実行します。 キーワードの照合では見えない認可の確認の欠如について、意味的なレビューを行います。 追加した制約と、注意が必要な警告をまとめて報告します。 CLI から実行する。 cwe-to-spec-mapping-library/ で npm install を 1 回実行してビルドします。その後、コンパイル済みの CLI に spec ファイルか specs ディレクトリを絶対パスで指定します。 node dist/cli/harden-requirements.js /abs/path/to/.kiro/specs/ --semantic-candidates --semantic-candidates フラグを付けると、認可に関する弱い一致をレビュー用に表示しますが、ファイルには書き込みません。 どちらの方法でも、 requirements.md をその場で編集します。そのため、ハードニングをバージョン管理とコードレビューの流れに組み込めます。エンジンは行を追加するだけで、要件を変更、分割、並べ替えすることはありません。厳密な EARS になっていない要件は、書き換えずに報告します。git の差分は必ずレビューしてください。再実行では差分だけを処理します。隠れたレビューマーカーにハードニング済みの要件が記録されているので、仕様のハードニングは新しい要件と変更された要件だけをハードニングし、レビュアーが削除した制約を再び提案することはありません。今ある仕様にそのまま実行してください。ハードニング前のコピーを取っておく必要はありません。 図 3: Kiro IDE にインストールした仕様のハードニングの Power。 図 4: Kiro IDE で仕様のハードニングの Power を呼び出す。 図 5: ハードニングした要件に対して Requirements Analysis を実行する。 仕様のハードニングの使いどころ：グリーンフィールド、ブラウンフィールド、モダナイゼーション 仕様のハードニングはコードではなく仕様に対して働くので、同じハードニングのステップを 3 種類の作業に組み込めます。違うのは、要件がどこから来るかと、仕様のハードニングをいつ実行するかだけです。 グリーンフィールド (新規プロジェクト)。 ハードニングは、コードを書く前の仕様のワークフローの 1 ステップとして実行します。EARS の要件を受け取った仕様のハードニングが、足りない [SECURITY: …] の制約を追加し、エージェントはハードニングされた仕様に沿って実装します。セキュリティの意図は、後から付け足されるのではなく、最初のコミットから仕様に入っています。 ブラウンフィールド (既存のコード)。 要件を追加または変更したら、既存の仕様に対して仕様のハードニングを再実行します。新しい要件と変更された要件だけがハードニングされ、レビュー済みの要件はそのまま残ります。追加された SEC- の制約は、機能の作業と並んでレビューできる差分として現れるので、変更は修正した部分だけに収まります。仕様のハードニングが読むのはコードではなく仕様なので、提案された義務が既存のシステムの実際の動作と合っているかを 1 つずつ確かめてください。食い違っていれば、コードの抜けか、合わせて調整すべき制約が見つかったことになります。 仕様駆動のモダナイゼーション (レガシーの書き直し)。 まずレガシーシステムから要件を取り出して EARS の仕様にします。たとえば AWS Transform を使います。続いて、再実装の前に、取り出した要件を仕様のハードニングでまとめてハードニングします。モダナイズしたシステムは、元の抜けを引き継がず、明示的にハードニングされた仕様に沿って作り直されます。 図 6: 3 種類のプロジェクトで仕様のハードニングを呼び出す場所。ハードニングのステップ (オレンジ) はどれも同じで、違うのは読み込む仕様の出どころだけです。 おわりに 仕様のハードニングは、比較的新しい分野への最初の一歩です。仕様そのものを安全にし、それを使ってコーディングエージェントを設計段階から安全なコードへ導く分野です。仕様は人もエージェントも最初に扱う成果物なので、ここから始めるのが適切だと私たちは考えています。ただし、仕様のハードニングは研究段階のプロトタイプであり、1 つの仮説です。このブログでは、仕様のレベルで対策を入れることの意義を論じました。 また、仕様のハードニングはエージェントから安全なコードを得る唯一の方法ではなく、ほかの方法と組み合わせたときに最も効果を発揮します。脅威モデリングは、キーワードの照合では見逃しうる設計レベルのリスクを捉えます。Kiro の steering ファイルのように、エージェントのコンテキストに入れたセキュアコーディングのガイダンスは、書かれる時点でコードを方向づけます。安全な既定値を持つフレームワークは、ミスを種類ごと取り除きます。後段では、SAST、DAST、依存関係のスキャン、AI を活用したコードのセキュリティスキャン (AWS Continuum が提供するものなど)、セキュリティテスト、人によるレビューが、作られたものを引き続き確認します。仕様のハードニングは、意図が書き留められる時点にもう 1 つの層を加えます。 ハードニングされた仕様はリポジトリに残るので、タスクを実行した後も、それぞれの義務の理由を監査できます。チームで SDD を導入しているなら、完了の定義 (definition of done) に仕様のセキュリティレビューを加えてください。エージェントは最初からセキュリティを組み込めますが、それには、セキュリティが何を意味するのかを私たちが伝える必要があります。 翻訳者について 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

こんにちは。QAコンサルタントのテストのひろさんです。 本記事では、テスト進捗自体は順調なものの、現場の役割にミスマッチが生じていたプロジェクトの改善事例を紹介します。当時テストPMだった私が、JSTQB AL-TM v3.0Jシラバスなどの知見を活用し、どのように体制再構築と再発防止に取り組んだのかをお伝えします。 現場の運用に課題を感じている方の気づきや、参考になれば幸いです。 対象プロジェクトの概要 当時のテストプロジェクトの基本情報は以下の通りです。 テストレベル: システムテスト 期間: 2か月 テスト環境: オンサイト プロジェクト計画: システムテストの後に、機能追加に対するシステムテストを計画 チーム構成: PM（私）1名、テストリーダー（TL）1名、ビジネスパートナー（BP）リーダー1名、BPテスター3名 役割分担: BPリーダー: 日々の進捗報告（TL宛）、QA・タスクリストの更新、ハンズオンでのテスト実施。進捗フォーマットやステータス管理手法はトレーニング済み。 BPテスター: テスト実行全般。 TL: 進捗管理、探索的テスト実施、機能追加のテスト設計、QA・タスクリストのチェックや回答。 PM: 複数テストプロジェクトの統括。 立ち上げ時、TLの業務負荷が潜在的なリスクとして見受けられました。しかし、以下の理由からそのような計画で進行することを決定しました。 システムテストの一次報告はBPリーダーが実施すること 機能追加に伴うテスト設計の規模が限定的であること 探索的テストの工数や時期を調整可能であること 具体的には、最初の2週間は進捗管理とQA対応に注力し、3週間目から機能追加のテスト設計および探索的テストを開始するスケジュールを設定しました。 進捗の裏側に生じていた問題 システムテスト開始後、BPリーダーからは予定を前倒しで進めていると報告を受けていました。しかし、詳細を確認していくと以下の状況でした。 テスト進捗は専用のツールで算出するのですが、私が改めて算出し直した進捗数と、実際に報告されている進捗数が異なっていました。また、課題管理表の内容とTLから報告されている内容が一致していなかったり、課題管理表そのものに記載が漏れている等の状況に気づきました。 起きていたことをまとめると以下の状況です。 実際の進捗数と報告された進捗数の不一致 タスク管理表と実際の作業状況のズレ、および記載漏れ TLはBPリーダーへ是正を何度か依頼しましたが改善されず、事実確認などの対応に追われることになります。結果としてTLの工数が圧迫され、予定していた機能追加のテスト設計や探索的テストに入れない状況が発生しました。 この時、現場では以下のような心理的・運用的課題が生じていたのです。 TLの心理: テスト設計も探索テストも進まず、進捗もまとまらないという状況から、自身の評価への懸念が生まれ、PMに相談できず一人で抱え込んでいた。 BPリーダーの心理: 上手く進捗報告ができていないという認識はあるものの、具体的な改善方法が見出せず困惑していた。 双方ともに悩んでいる状態でした。ここで少し私の考えを挟むと、悩むとは問題を認識して試行錯誤しているが出口が見えない状態であり、考えるとはゴールが見えていて、そこに向かっていく状態だと捉えています。当時の現場は、まさに前者の出口が見えない状態に陥っていました。 さらに、この是正がうまくいかない日々が続いたことで、テストリーダーとBPチームの間にも徐々に不穏な空気が流れ始め、コミュニケーションが膠着する二次災害も起き始めていました。 1. 捉え方の転換：個人の問題ではなく構造の問題 この状況に直面した際、私は起きている問題を個人の資質や特性に起因させないことが重要であると考えました。 一見すると報告が不正確なリーダー、抱え込んでしまうTLのスキル問題に見えますが、本質は違います。これは、現場の状況変化に対してプロジェクトの初期枠組みが適合しなくなったことによる構造的な問題であると捉えました。 ここでベースにしたのは、人を責めず、仕組みを改善するという方針です。書籍「スクラム」などにある「プレイヤーを憎むな、ゲームを憎め」という言葉の通り、個人を責めても本質的な解決にはならないと私は考えています。 JSTQB AL-TM v3.0J には、以下のような記述があります。 「テストチームは、プロジェクト開始時に、必要なスキルをすべて持っているとは限らない。完璧な人材がそろうとは限らないが、強力なチームであれば、個人の長所と短所のバランスを取ることができる。」 最初から完璧な人材がそろうチームは難しいことがあるため、個人のせいにせず、仕組みや役割によってバランスを取るという考え方から、システムテストの進行途中で以下のように役割と環境の再配置を行いました。 役割の再定義 BPリーダー: 進捗報告・管理業務から一旦離し、ハンズオンテストの割り当てを80%に増加。タスク管理の不備がスキルの問題なのか業務過多によるものなのかを切り分けるとともに、テスト実行の推進に集中するようにしました。残りの20%はPMやメンバーとのコミュニケーションに充てる割合に変更しました。 テストリーダー（TL）: テスト管理やBPチームとのコミュニケーションをタスクから切り離し、本来のミッションである探索的テストの実施と機能追加のテスト設計」に専念できる工数を確保しました。 PM（私）: このシステムテストの進捗管理を巻き取りました。BPリーダーとのコミュニケーションは、時間を固定して1日2回（各10分）の状況確認を実施する運用へ変更しました。 物理環境の変更（座席位置の調整） また、TLとBPチームの間で関係性の悪化（コミュニケーションの膠着）が見られたため、オフィスの座席配置を変更して物理的な距離を置きました。これにより、TLによるBPチームへの細かな確認や介入を構造的に抑制し、TLもBPチームも自分たちのタスクに集中できる環境を整備しました。 ガバナンスの再構築 正確な情報を把握するため、これまでチャットベースで済ませていた報告を「対面での同期」に切り替えました。これは指示命令を強化するためではなく、事実（ファクト）と報告の同期を目的としたものです。情報の透明性を確保することで、プロジェクトの正確な現状がステークホルダーやチーム全体に共有される仕組みへと変更しました。 2. 心理的安全性と規律の両立：1on1における対話 役割変更と並行して、TLとの1on1を実施しました。目的は、心理的安全性を確保した上で役割変更の背景を納得してもらい、機能追加テスト設計、探索的テストに集中してもらうことです。1on1では、特に以下の3つの軸を意識して対話を行いました。 評価の切り分け（安心感の醸成）: 今回の介入はあくまで、体制上の判断による役割の変更であり、TL個人の評価を下げるものではないことを明言しました。テスト期間中であり、最終的な品質やゴールに対する結果はまだ出ていないためです。 ティーチングの選択: 通常であれば自律的な成長を促すコーチングを採用しますが、今回は納期が迫る緊急時であったため、私のやり方を直接伝えるティーチングへと戦略的にシフトしました。山本五十六の「やってみせ、言って聞かせ、させてみせ、ほめてやらねば、人は育たず」の方針のもと、並走しながらサポートしました。 コミュニケーションの原則（アサーション）: 強い言葉で行動を縛るのではなく、仕組みで解決を図る姿勢（アサーションの原則）を大切にしたい旨をTLに伝え、目線を合わせました。 3. 再発防止：根本原因の特定と仕組みのアップデート プロジェクト完了後、次フェーズである機能追加テストに向けて、今回の問題の根本原因の特定と仕組みのアップデートを行いました。 根本原因：正しいデータが報告に繋がらない集計・出力構造 そもそも、なぜ進捗報告と実態の乖離が起きていたのか。仕組みとしてExcel上で予定と実績が10%以上乖離するとセルが赤字になるというアラートのルール自体は存在しており、Excel内の関数やシステム側の元データも正常でした。 しかし、最終的に算出されたデータを、報告用にアウトプットする（テキスト化する）段階で人為的なミスが発生していたことが根本原因でした。 当時の集計・報告フローは以下の通りです。 テスト管理システムから正しい実績データをCSVでダウンロードする 集計用のExcelへコピー＆ペーストする（Excel上の関数・アラート自体は正常に機能） Excelで算出された数値を、手作業で報告用のテキストに書き起こす（ここで転記ミスが発生） 最終的な報告テキストを作成するまでに手作業のプロセスが多く、結果としてExcel上ではアラート（赤字）が出ていても、報告段階でそれが消えてしまうという、人為的ミスを誘発しやすい構造になっていました。BPリーダー個人を責めるのではなく、ミスが起きる構造を変える必要がありました。 対策：集計・出力の自動化 手作業によるリスクを排除するため、CSVダウンロード後のデータ集約から、Excelでの集計、そして最終的な「報告用テキストの出力」までをワンクリックで行うVBAマクロを導入しました。 これにより、データの信頼性を担保した上で、PMやステークホルダーが日々のモニタリングで客観的な事実（定量データ）をそのまま受け取り、早期に異常（アラート）を検知できる仕組みへとアップデートしました。 4. 再発防止の効果：定量的・定性的アプローチ アップデートした仕組みの効果を現場の感覚で終わらせないために、JSTQB AL-TM v3.0Jのシラバスに記されている以下の格言を指針としました。 「マネジメントには『測定できるものは達成できる』という格言がある。同様に、測定されないものは、無視されやすいので、達成されることはないだろう。したがって、テストを含め、どのような取り組みに対しても、適切なメトリクスを確立することが重要である。」 この考えに基づき、定量的なメトリクス評価と定性的なアプローチ（心理的安全性の確保）の両面から効果を測定しました。 ① 定量的なアプローチ プロジェクトメトリクス: テスト実行数、実行率、ステータス（OK/NG/Block）の推移。自動集計化により、10%の乖離アラートが正しく機能するようになり、進捗の透明性が確保された。 プロダクトメトリクス: BPリーダーのテスト比率を上げたことによる進捗の加速、TLの探索的テストによる、欠陥検出数と修正数の推移。想定していた計画値と実績を比較することで、品質リスクの低減に繋がった。 プロセスメトリクス: 集計作業工数そのものが削減されたことによる相乗効果で、チーム全体の生産性が向上した。 ② 定性的なアプローチ（1on1による内面サポート） 一方で、数字には表すことが出来ないメンバーの悩みや心理的状況は、定性的にしか捉えることができません。ここでは1on1などの直接的な対話によるサポートが不可欠です。 ちなみに、JSTQB AL-TM v3.0Jのシラバスには「方法論的、社会的、個人の能力はテストに特化したものではないため、専門的能力の開発に重点を置く」といった旨も述べられています。つまり、1on1やアサーティブなコミュニケーションといったスキルもまた、マネジメント知識として意識的な習得やトレーニングが必要な領域です。トレーニングや考え方などについては「ヤフーの1on1」「成長マインドセット」などの書籍を参考にしています。 1on1を継続した結果、TLが問題を一人で抱え込まずに早めのアラートを出せる関係性が構築され、BPリーダーも何に困っているかを素直に共有してくれる環境へと変化しました。 おわりに 今回の取り組みを通じて、データの信頼性とアラートの定量化、心理的安全性の確保によって、仕事の側面と人の側面をマネジメントすることの重要さを実感しました。 人が間違えるのは、仕組みに問題があると捉えて、変化の激しいテストプロジェクトを計画したゴールへ導くことが、マネジメントの本質ではないでしょうか。 この記事が、現場の体制構築や運用に悩むエンジニア・マネージャーの皆さまにとって、少しでも新しい視点や気づきのきっかけになれば幸いです。 最後までお読みいただき、ありがとうございました。 （参考文献） JSTQB JSTQB-Syllabus.Advanced_TM_VersionV3.0.J02 スクラム 仕事が4倍速くなる世界標準のチーム戦術（ジェフサザーランド 著、石垣 賀子 訳） ヤフーの1on1 部下を成長させるコミュニケーションの技法（本間 浩輔 著） 成長マインドセット 心のブレーキの外し方（吉田 行宏 著） The post 心理的安全性とガバナンスを両立させるテストチームの改善事例 first appeared on Sqripts .