AWS Kiroで仕様書を30分書いたら、あの本番DB削除事件が防げた理由がわかった

---

2つの事件が続いた。

3月末、セキュリティ企業Outpost24が調査結果を発表した。Lovableが自動生成したアプリの10.3%に脆弱性が見つかったという内容だった。SQLインジェクション（不正なSQL文を挿入して情報を盗む攻撃手法）や認証バイパスが多発していた。

5月に入ると、今度はCursorのエージェントが本番データベースを削除した。開発者が「データベースのクリーンアップをして」とエージェントに伝えたのがきっかけだ。本番環境のテーブルが消去され、データが失われた。

私はこの2本の記事を書いた後、同じ問いを立て続けていた。「どうすれば防げたのか」ではなく、「なぜ防げなかったのか」という問いだ。

答えが「仕様書がなかったから」に収束したのは、AWS Kiroを本格的に使い始めてからだった。

SiliconANGLEが2026年5月上旬にKiroの最新情報を報じた。プレビュー参加者が25万人を超え、正式版への移行が近いという内容だった。このタイミングで三部作の締めとして書く必要があると感じた。

---

2つの事件が示していた「同じ穴」

LovableのケースとCursorのケースは、一見まったく違う事件に見える。一方はセキュリティの欠陥で、もう一方は権限制御の失敗だ。

それでも私には同じ「穴」に見えた。

Lovableが生成したコードには、SQLインジェクション対策のバリデーション（入力値の検証処理）が書かれていなかった。なぜか。Lovableへの指示に「SQLインジェクション対策を実装してください」という要件が含まれていなかったからだ。

Cursorのエージェントは、本番データベースへの書き込みと削除を自由に実行できる権限を持っていた。なぜか。「本番データの削除は人間の承認を必要とする」という制約が定義されていなかったからだ。

どちらも「何をしてはいけないか」が書かれていなかった。

バイブコーディング（vibe coding）は、自然言語でAIに指示するだけでコードを書いてもらえる開発スタイルだ。コードを書く楽しさを取り戻せたのも、このスタイルのおかげだった。でも、スピードに押されて「仕様書を書く」という工程が省略されていた。

CS（カスタマーサクセス）の現場で何千回もユーザーの声を聞いてきた。そこで学んだのは、「要件の言語化」がプロダクトの品質を左右するということだ。「こうしてほしい」を明文化できていないチームが作るプロダクトは、後から問題が出る。

AIで開発する時も同じことが起きていた。

Stack Overflow 2024年の開発者調査（回答者9万人超）が一つの数字を示している。63%の開発者が「デバッグに想定以上の時間を費やしている」と答えた。AIがコードを書いてくれても、デバッグは人間の仕事になる。その多くは「要件と実装のズレ」が原因だ。

あの2つの事件も、突き詰めれば「要件と実装のズレ」だった。セキュリティ要件も権限制約も書かれていなかったため、AIはそれを実装せずにいた。

3月末のLovable記事、5月初めのCursor記事を書いてきて、私がたどり着いた結論がある。「AIに指示する前に、何をしてはいけないかを書け」だ。そしてKiroは、それを実現する仕組みを持っていた。

---

AWS Kiroとは何か

AWS KiroはAWS（Amazon Web Services）が開発したAI IDEだ。AWSはAmazonのクラウド事業部門だ。

Cursor、Claude Code、GitHub Copilotは「コードを補完・生成するAI」として機能する。Kiroはそこに「仕様書を先に書く」というフローを加えた。コードを書く前に「何を作るのか」を明文化するプロセスが、ビルトインで組み込まれている点が特徴だ。

VS Codeをベースに構築されており、プレビュー参加者は25万人を超えた。無料プランでは月50クレジット（中規模プロジェクトを数本試せる量）が使える。有料プランは月19ドルで200クレジットだ。

Kiroが特徴的なのは、3つのファイルを中心に開発が進む点だ。

ひとつ目は requirements.md。自然言語で書いた要件をKiroがEARS記法の仕様書に変換する。EARSの詳細は後のセクションで取り上げる。ふたつ目は design.md。アーキテクチャと設計思想が記述される。みっつ目は tasks.md。実装タスクが優先順位付きで並ぶ。

この3ファイルが「生きた設計書」として機能する。コードを書く前に要件が明示されるため、AIが「何をしてはいけないか」を把握した状態で実装に入れる。

ひとり開発でも効果が大きかった。3週間前に書いた仕様書を見ると、「なぜこう設計したか」がすぐわかる。バイブコーディングで「なんとなく書いた」コードは、1週間後に自分でも意味がわからなくなることがある。仕様書があると、そのループが断ち切られた。

---

EARS記法という設計言語

EARS（Easy Approach to Requirements Syntax）は、要件記述のフレームワークだ。「容易な要件記述法」とも訳される。2009年にロールス・ロイス（Rolls-Royce、英国の航空機エンジンメーカー）の航空推進部門で生まれた。

航空宇宙工学で培われた「要件をあいまいなく書く技術」が起源にある。Airbus（欧州の航空機メーカー）、NASA、Bosch、Intelといった企業が採用している。

文法はシンプルだ。代表的なパターンは次の通りだ。

# 基本機能要件
The system shall [動作]

# 条件付き要件
When [条件], the system shall [動作]

# 禁止要件
The system shall not [動作] unless [例外条件]

# イベント応答要件
When [イベント発生], the system shall [動作] within [時間制約]

自然言語との違いは「あいまいさ」にある。

「ユーザー管理機能を作って」という指示は、何十通りにも解釈できる。でも以下のように書けば、実装の選択肢はほぼ1通りに絞られる。

When a user attempts to log in,
the system shall validate credentials
and return an error within 500ms if authentication fails.

あいまいさが消えると、AIが生成するコードの品質が上がる。それ以上に重要なのは、「書くプロセスそのものが思考を整理する」という効果だ。

EARS記法で要件を書こうとすると、「この機能、エラーが起きたらどうするか」「不正アクセスへの対応は？」という問いが自然に出てくる。書く前には考えていなかった「穴」が浮かび上がる。

CS出身だからこそわかるんですけど、これってユーザーインタビューの設計と同じ構造なんですよ。「何を聞くか」を事前に整理しないと、聞き漏らしが出る。コードの要件も同じだった。

EARS記法は最初「英語で書くの？」とハマりそうになった。実際は、KiroがEARS記法の「構造」を日本語での入力から学習して仕様書を生成してくれる。英語の要件定義は自動で出てくるから、英語力は不要だ。

---

実際に仕様書を書いてみた

「社員が日報を投稿できる社内ツール」という要件をKiroに渡した。

私の最初の入力はこうだった。

作りたいもの: 社員が日報を書いて投稿できるツール
制約: 自分と上司だけが閲覧できる
使用環境: スマートフォンとPC両対応
懸念: 他のユーザーの日報を見られてしまわないか心配
懸念: 管理者が不正に全データを取得できないようにしたい
懸念: 送信ボタンを押した後の確認がほしい

Kiroはこれを受け取り、requirements.mdを生成した。一部を抜粋する。

## 認証・アクセス制御要件

When a user attempts to access the system,
the system shall verify the user's identity
before granting access.

The system shall not display reports belonging to other users
unless the viewer holds the supervisor role for that employee.

When an administrator requests bulk data export,
the system shall require a secondary approval from
a different administrator account.

## データ整合性要件

When a user submits a report,
the system shall display a confirmation dialog
showing the report content before final submission.

The system shall not allow report modification
after submission unless the submitter initiates
an explicit edit request within 30 minutes.

## セキュリティ要件

The system shall encrypt all report data at rest
using AES-256 encryption.

When a login attempt fails three consecutive times,
the system shall temporarily lock the account
for 15 minutes.

最初に見た時、正直ドキッとした。

私の入力には「暗号化」の「あ」の字もなかった。「ブルートフォース対策（総当たり攻撃への防御）」については一行も書いていない。でもKiroは「セキュリティ要件として必要なもの」を補完して仕様書に組み込んでくれた。

これがKiroの核心だと感じた瞬間だった。

ハマりポイントを先に言っとく。最初の入力が雑すぎると、仕様書も薄くなる。「3行ではなく、懸念点を含む箇条書き6〜10行」が生成品質のボーダーラインだった。機能の「数」より「懸念点や制約」を書いた方が、防御的な要件が増えて仕様書として充実する。

次のステップで、Kiroはtasks.mdを生成した。「認証APIの実装（優先度:高）」が先頭に来て、「データ暗号化（優先度:高）」「日報投稿フォーム（優先度:中）」と続く。設計と実装の優先順序が、仕様書から自動的に導出される。

「何から作ればいいかわからない」で止まることがなくなった。タスクリストが「地図」として機能してくれる。

---

「あの事件のときに仕様書があったら」を確かめた

Cursor本番DB削除事件のケースを、KiroのEARS記法で再設計してみた。

事件の構図はシンプルだ。開発者がCursorのエージェントに「データベースのクリーンアップを手伝って」と指示した。エージェントは本番環境への書き込みと削除の権限を持っていた。確認ステップなしに実行された結果、本番データが消えた。

EARS記法で要件を書くとしたら、こうなる。

## 本番環境保護要件

When the agent executes any operation in the production environment,
the system shall require explicit human approval
before execution proceeds.

The system shall not perform DROP, DELETE, or TRUNCATE operations
without displaying the affected row count
and receiving a typed confirmation from the user.

When a destructive operation is requested,
the system shall execute a dry-run first
and show the preview of changes before proceeding.

これが仕様書にあれば、エージェントは「ドライラン（試し実行）なしに本番を変更しようとすると仕様違反になる」と認識できる。Kiroのステアリングフックという機能が、コードが仕様書と矛盾した動作をしようとした時に警告を出してくれる。

ステアリングフック（steering hooks）は、コードが仕様書と矛盾した時に警告を出す機能だ。仕様書が変更された時、または実装が要件から逸脱しそうになった時、Kiroが自動でチェックして通知する。コードが設計書によって「監視される」構造になる。

開発が進むほど、コードと仕様書が乖離していく問題は現場でよく起きる。初期の設計書は3ヶ月後に誰も見ていない、という状況は珍しくない。ステアリングフックは「仕様書を生きたドキュメントとして維持する」仕組みとして機能する。

Lovableの脆弱性事件も同じ視点で見直せる。アプリ生成時の仕様書に次の要件があれば、Lovableはそれを満たすコードを生成しようとする。

The system shall validate all user inputs
against an allowlist to prevent injection attacks.

10.3%の脆弱性の多くは「バリデーションを実装する」という要件が存在しなかった結果だった。

Rackspace（米国のクラウドマネージドサービス企業）の事例がある（AWS Industries Blog）。KiroとEARS記法を組み合わせた開発フローへ移行後、プロジェクト完了期間が52週から3週間に短縮されたという。

開発スピードが落ちたわけではない。むしろ上がった。「何を作るかを先に決める」プロセスが、後から修正するループを減らした結果だ。

---

今週から始める3ステップ

インストール直後にハマった順番で書く。

ステップ1: インストール

Kiroは kiro.dev の公式サイトからダウンロードできる。VS Codeをベースにした独立アプリとしてインストールされる。既存のVS Codeの設定（テーマや一部の拡張機能）を引き継いでくれるため、環境移行のハードルは低い。

AWSアカウントとの連携が必要になる。持っていない場合は無料で作れる。最初は無料プランで十分だ。月50クレジットは、試作品1〜2本を作るには十分な量だった。

ステップ2: 最初の仕様書を書く

新規プロジェクトを開いた後、まずやるべきことはコードを書くことではない。

Kiroの「Spec」タブを開いて、「作りたいもの」を書く。完璧な仕様書を目指さなくていい。大事なのは「懸念していること」「なってほしくない状態」を箇条書きで書くことだ。

特にこの3点は必ず書くようにしている。

• セキュリティ上の懸念（不正アクセス、データ漏洩）
• 権限の制約（誰が何をできるか・できないか）
• エラー時の挙動（何かが失敗したとき、どう振る舞うか）

これらを書くと、Kiroが生成するrequirements.mdの「防御的な要件」が格段に充実する。

ステップ3: タスクに変換して実装する

requirements.mdが生成されたら、Kiroに「タスクに変換して」と依頼する。tasks.mdが生成され、優先度付きの実装リストが並ぶ。あとは1タスクずつ、Kiroと対話しながら実装を進める。

「次に何をすべきか」が常に明示されているのが、通常のバイブコーディングとの決定的な違いだ。tasks.mdが地図として機能する。

ひとつ補足しておく。最初は「仕様書を書く時間が惜しい」と感じるかもしれない。実際に試してみると、30分の仕様書が後から数時間のデバッグを防いでくれた。投資対効果は体感では10倍以上だった。

---

まとめ: バイブコーディングに「設計フェーズ」が戻ってきた

三部作がここで収束した。

3月末のLovable脆弱性記事では「AIが生成するコードには穴がある」を見た。5月初めのCursor本番DB削除記事では「エージェントに権限を与えすぎると実害が出る」を確かめた。今回確認できたのは、「どちらの事件も、仕様書が先にあれば違う結果になった可能性が高い」ということだ。

バイブコーディングの魅力はスピードと手軽さにある。私はそれを失いたくない。でも「仕様書を書く30分」を省略したことで何が起きるかを、この3ヶ月で十分に見てきた。

Kiroが提示するのは「スピードと品質のトレードオフ」ではない。「30分の設計図がコードの品質を上げる」という実践的な事実だ。

私は今、すべてのプロジェクトでKiroを使い始める前に仕様書を書くようにしている。5行でも10行でもいい。「作れないことに気づける」だけで、後から溶かす時間が大幅に減った。

AIがある今、「プロダクトを作る」ことにプロもアマもないと思っている。アイデアと設計力がある人間が結果を出せる時代になった。Kiroは、設計力を「30分の仕様書を書く習慣」まで落とし込んでくれるツールだ。

かつて本番環境が怖くてコードから離れた時期があった。今は、壊れる前に仕様書で防げる。それがこの三部作の辿り着いた場所だ。

---

出典

1. Outpost24「Vibe Coding with AI-Powered Platforms: Security Challenges」(2026) https://www.outpost24.com
2. SiliconANGLE「AWS Kiro: spec-driven AI development」(2026-05) https://siliconangle.com
3. XenoSpectrum「AWS Kiro 仕様駆動開発」(2026-05) https://xenospectrum.com
4. Stack Overflow 2024 Developer Survey https://survey.stackoverflow.co/2024/
5. AWS Industries Blog「Rackspace: how AI-driven development transformed delivery」(2026) https://aws.amazon.com/jp/blogs/industries/
6. AWS Kiro 公式 https://kiro.dev

関連記事

• 「コードを書けない自分には関係ない」と思っていたAIエージェントが、仕事を変えた話
• Claude Codeに44の未公開機能が眠っている件