AWS Kiro登場、バイブコーディングは規律フェーズへ

[[IMG:hero]]

「バイブコーディング、楽しいんですよ。マジで楽しい。」

私は2026年に入ってからCursorとClaude Codeをほぼ毎日使ってきました。業務ツールも、副業の検証アプリも、書きたいと思った瞬間に書ける。コードから一度離れた挫折組の人間にとって、これは本当に革命でした。

ただ、ここ1〜2カ月、少し違和感が出てきました。「動くものは作れる、でも動き続けるかは怪しい」「気分で書いたコードが、3週間後に自分でも読めない」。同じ違和感を、業界の有名どころが続けて記事にし始めました。直近1カ月だけで3つです。Cursor Composer 2の評価記事、IBMの「構築から運用」フェーズ宣言、そしてAWS Kiro。並べてみると、ぜんぶ同じ違和感への返答に見えました。

並べてみて気づきました。これ、同じ方向を指している。バイブコーディング全盛期から、次の「規律フェーズ」への合図です。今日はその合図の中心にあるAWS Kiroを、元・挫折エンジニアの目線で分解します。

バイブコーディング、楽しさの裏で増えてきた違和感

最初に、私の最近の失敗を1つ書かせてください。読者と同じ目線で書きたいので、隠さず行きます。

3月、社内の顧客対応用ダッシュボードをCursor＋Claude Codeで一気に作りました。Slack通知も、Notionからの自動取込も、フィルタUIも、3日で形になって。「これマジで神なんですよ」って同僚に見せて回りました。CS出身でコードから離れていた人間が、ですよ。気分が上がるに決まっています。

問題は2週間後に起きました。仕様の追加依頼が来て、自分のコードを開いたら、何を考えて書いたのかわからない。Claudeに「これ何やってる関数？」と聞いたら、Claude自身も「文脈が複数の可能性に解釈できます」と返してきました。書いた本人とAIが揃って迷子になる現象です。

これは私だけの問題じゃありません。海外でいくつかデータが出ています。

• METR（Model Evaluation & Threat Research）のRCT実験では、AIツール使用時の開発作業が「期待値より遅くなる」結果が出た（出典はMETR公式記事）
• GitClear社の調査では、AI支援コードのリファクタ率と削除率が伝統的コードより高い傾向
• Cisco CodeGuardやTenzaiなど複数のセキュリティスキャナが、バイブコーディング由来コードに10〜45%の脆弱性を検出したと報告している

私の体感とこれらのデータは、同じ方向を指していました。「動くものを作る楽しさ」と「動き続ける品質」の間に、まだ橋がかかっていないんです。

ここで救世主面して仕様駆動開発を語るつもりはありません。私もまだ手探りです。ただ、その手探りの最中に出てきたAWS Kiroが「仕様先行ってこういうことだよ」と図解で示してくれた。だから今日はその図解の中身を共有します。

AWS Kiroが提示した「仕様駆動型AI開発」の中身

[[IMG:1]]

AWS Kiroは、AWSが提供するAIファースト統合開発環境（IDE）です。Visual Studio Codeのフォークが土台。AIエージェントと「仕様、設計、実装」の順で対話するフローを軸に据えています。日本語の詳細解説はまだ少なめです。XenoSpectrumの2026年5月22日付記事が、国内では先行例として紹介されています。

Kiroのキモは、コードを書く前に3つのファイルを「対話的に」作るプロセスを強制してくる点です。

1. requirements.md — 何を作るか。EARS記法（Easy Approach to Requirements Syntax）でユーザーストーリーと受け入れ基準を書く
2. design.md — どう作るか。データフロー、APIシーケンス、TypeScriptインターフェース、ER図、ユニットテスト戦略まで含む
3. tasks.md — どんな順で実装するか。離散的なタスクと、それぞれの要件番号への参照を持つ

このプロセスがいい点は明確です。書くタイミングを強制しているだけで、書いている内容自体は昔の「ちゃんとした開発」と同じです。要件定義、基本設計、タスク分解。経験者なら当たり前のはず。それがバイブコーディングのスピード感の中ですっぽり抜け落ちていました。Kiroは、その3つを「先に書け」と要求してきます。

もう1つ重要なのが**Steering Files（ステアリングファイル）**という概念です。プロジェクト固有のルールを、Kiroが常に参照するMarkdownとして置いておく仕組みになります。たとえば「Tailwind v4を使う」「APIエラーは必ずエラーバウンダリで包む」みたいな前提です。CLAUDE.mdやAGENTS.mdをすでに使っている方なら、同じ系譜だと納得できるはず。Kiroはこれをコア機能として組み込みました。

料金はFree / Pro / Pro+ / Powerの4ティアがKiro公式の料金ページで公開されています（2026年5月時点）。無料プランから始められる設計で、詳細は一次ソースで確認してください。サポートOSはMac/Windows/Linuxの3つ。モデルもClaude Sonnetを含む複数から選べます。

なぜ今「仕様先行」なのか。3つの数字が示した臨界点

[[IMG:2]]

「仕様先行が大事」みたいな話は、正直、エンジニア業界では何十年も言われ続けています。なぜ今あらためてAWS Kiroのような専用IDEが出てきたのか。私の解釈はこうです。

バイブコーディングが「書く側」の速度を一気に押し上げたから、書いた後の問題が露出した。これまでは要件定義に2週間かかっていたから、雑な仕様でも「書きながら直す」時間があった。今は3日で形になるので、雑な仕様のまま3日後にメンテ地獄に突入する。

3つの数字を並べてみます。

• METR RCTの「19%遅い」現象: 経験豊富な開発者ほど、AIに頼って速くなるどころか、結果的に遅くなる傾向が観測された。原因の一つに「仕様の曖昧さに気付かないまま進めてしまう」が挙げられている
• GitClearの「削除率上昇」: AI支援で書かれたコードは、書いた直後に削除・大幅修正される割合が、伝統的コードより目に見えて高い。仕様確定前に書きすぎている兆候
• Cisco CodeGuard・Tenzaiの「10〜45%脆弱性検出」: 複数のセキュリティスキャナが、バイブコーディング由来コードのセキュリティ欠陥比率を高めに報告。仕様段階での認証・認可・入力検証の欠落が主因とされる

3つに共通するキーワードが「仕様欠落」です。スピードが上がったぶん、欠落のコストが見えやすくなった。AWS Kiroは「だから書く前に仕様作っとけ」を、IDEレベルで強制してくる。これは精神論ではなく、開発フローの構造変更です。

私自身、この3つの数字を最初に見たときの感想は「やべ、自分のことだ」でした。元・挫折組としては、プロのエンジニアが直面している問題が、ようやくAIで「同じ土俵」に立てるレベルになったとも言えます。同じ問題を、同じ道具で解ける時代になりました。

成熟化トリオの読み解き。Cursor 2・IBM・Kiroが指す同じ方向

ここ1カ月で出てきた3つの動きを、私は勝手に「成熟化トリオ」と呼んでいます。

出来事	時期	中身	同じ方向の合図
Cursor Composer 2	2026年4月	エージェント駆動の長尺タスク実行を強化。SiliconANGLE評価は「Cursorの主役化」、The Register評価は「コード品質に懸念」と両論。判断の基準が必要に	バイブの主役IDEが「実行責任」を取り始めた
IBMの「構築から運用」フェーズ宣言	2026年5月	AIエージェントの主戦場は「構築」ではなく「運用」だと表明したとされる。プロンプトの単発実行ではなく、エージェントが長期的に動き続ける品質の議論が中心に	動く瞬間より、動き続けることが評価軸に
AWS Kiro発表（再注目）	2026年5月	仕様駆動型AI開発IDEとして、コード生成より先に仕様・設計・タスク分解の対話を強制	「書く前に何を書くか決めろ」がIDE標準に

3つの方向はバラバラに見えて、同じ問いへの答えになっています。「バイブで速くなった先で、何が課題か」。

• Cursorは「実行責任」を、エージェントとIDEに持たせる方向
• IBMは「運用責任」を、AIエージェントの設計段階から組み込む方向
• AWS Kiroは「仕様責任」を、IDEワークフローで強制する方向

責任の所在を明確にする、というのが共通しています。動けばOKではなくて、誰が・何に・どこまで責任を持つかを設計に入れる。これがバイブコーディング次の規律フェーズの本質だと、私は思っています。

「使うとき呼ぶAI」は終わったというナギの見立てとも、地続きの話です。AIを「呼んで使う」から「常駐で運用する」に変わると、当然ながら設計の重みが増します。Kiroの仕様先行は、その流れの中の自然な進化です。

自分の業務ツール開発で「Kiro的フロー」を試した話

[[IMG:3]]

Kiroをまだ本格導入していない方向けに、私が今週やった「Kiro的フロー」のミニ実験を共有します。Kiro本体を入れなくても、Claude CodeやCursorで近いことが試せます（Kiro実機ではなく、同じ3ファイル構成の模擬実験です）。

題材は「Slackで届いた問い合わせを、Notionに自動分類して保存するBot」。CS出身の私としては、まさに自分の仕事を楽にするツールです。

Step 1: requirements.mdを先に書く（所要15分）

# SlackからNotionへ問い合わせ分類するBot 要件

## ユーザーストーリー
- CSメンバーとして、Slackチャンネル#supportに届いた問い合わせを
  Notionの「問い合わせDB」に自動で保存したい
- 保存時に「種別（バグ/質問/要望）」が自動分類されていてほしい

## 受け入れ基準（EARS記法）
- WHEN Slackに新規投稿が来る THE システムは Notionに新規行を作成する
- WHEN 投稿本文に「動かない」「エラー」「落ちる」が含まれる
  THE システムは 種別を「バグ」と判定する
- IF Notion APIが3回連続で失敗した THE システムは
  CS Lead宛にDMで失敗を通知する

Step 2: design.mdで設計（所要20分）

データフロー、エラー処理、認証情報の置き場所、テスト戦略までを1枚にまとめます。ここをClaudeと対話しながら詰めると、コードを書く前に「あ、それ抜けてた」が3つくらい出ます。私の場合は「同じ投稿の重複保存をどう避けるか」が抜けていました。

Step 3: tasks.mdで分解（所要10分）

• T1: Slack Bolt SDKの初期化（受け入れ基準: 1, 2に対応）
• T2: Notion API呼び出しモジュール（受け入れ基準: 1）
• T3: 種別判定ロジック（受け入れ基準: 2）
• T4: リトライとDM通知（受け入れ基準: 3）
• T5: ユニットテスト（受け入れ基準: 1, 2, 3）

Step 4: コード書く

ここに来てようやくClaude Codeに「T1から実装して」と渡します。事前に3ファイルを共有しているので、生成精度が体感で明らかに上がりました。何より、3週間後に自分が読み返したとき、なぜこう書いたかが残っています。

所要時間は、要件・設計・タスクで45分。コード本体が2時間。昔の私なら、いきなりコードに3時間溶かして、半分は捨てていたフローです。45分の前置きで2時間が浮きました。

ハマりポイント3つと、初心者に伝えたい注意事項

正直に書きます。Kiro的フローは万能じゃありません。私がハマった3点を先に共有しておきます。

ハマりポイント1: 仕様を書きすぎる地獄

最初、requirements.mdを書くのが楽しくなりすぎて、5,000字くらいの大作を作ってしまいました。そこから設計・タスクに進む頃には、もう実装する気力が消えていました。ユーザーストーリー3〜5本、受け入れ基準10条以内。これを目安にしてください。完璧を求めず、書きながら直す前提で。

ハマりポイント2: design.mdをコードで埋める罠

design.mdに、ついコードスニペットを長く書き込みたくなります。やめましょう。design.mdは「方針」、コードはtasks.md以降。混ぜると後で迷子になります。インターフェース定義（型）は書いてOK、実装本体はNG、と私は線を引いています。

ハマりポイント3: 3ファイル全部更新し続ける負担

仕様変更があるたびに3ファイル全部直すのは、正直しんどい。私は「重大な変更だけ反映」のルールにして、軽微な変更は実装側だけ直しています。ただし、後から振り返って「仕様と実装が違いすぎる」とならないよう、週1で同期する時間を5分だけ取っています。

初心者向けの一言: もしこれが「自分には早い」と感じるなら、まずrequirements.mdだけ書いて、design.mdとtasks.mdは省略してください。「書く前にユーザーストーリーだけ書く」を1週間続けるだけでも、Claudeに渡すプロンプトの質がはっきり変わります。コードを書けなくてもいい時代という見立てに乗るためにも、ユーザーストーリーを書く力は早めに鍛えた方がいい筋肉です。

まとめ「動けばOK」と「仕様先行」のいい関係、今週やる1案件

長くなりました。ここまで読んでくださってありがとうございます。

今日の話を3点に圧縮します。

• AWS Kiroは仕様駆動型AI開発のIDE。requirements.md / design.md / tasks.mdの3ファイルを対話的に作るフローが核
• Cursor Composer 2・IBM「運用フェーズ」宣言・AWS Kiroの3つは、バイブコーディングの次の規律フェーズを示す同じ方向の合図
• いきなりKiroを入れなくても、Claude CodeやCursorで「仕様先行」のミニ実験は今週できる。requirements.mdだけでも書いてみる価値あり

私のスタンスを最後に書きます。「動けばOK」精神は、これからも捨てません。最初に動くものを作る楽しさは、コードから離れた私を呼び戻してくれた、まさにその感覚だから。

ただ「動けばOK」だけだと、3週間後に泣くことを学びました。「動けばOKで作って、動き続けるよう仕様を後付けする」のはやめます。代わりに、**「仕様を15分先に書き、動けばOKで実装し、そのまま動き続ける」**にフローを変える。これだけです。

今週の宿題を1つ。今あなたが書こうとしている、または最近書いたコードのrequirements.mdを15分で書いてみてください。書けば、何が抜けていたかが見えます。それが、規律フェーズへの一歩目です。

私もまた来週、ハマったポイントを記事にして共有します。一緒に泥だらけになりながら、一緒にうまくなりましょう。

---

出典

• AWS Kiro公式サイト: https://kiro.dev/
• AWS Kiro料金ページ: https://kiro.dev/pricing/
• AWS Kiro仕様書ドキュメント: https://kiro.dev/docs/specs/quick-plan
• AWS Kiroステアリングドキュメント: https://kiro.dev/docs/steering/
• XenoSpectrum「AWS Kiro解説」2026-05-22（URL確認中）
• METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• GitClear「AI Copilot Code Quality 2024」（URL確認中）
• Cisco CodeGuard / Tenzai セキュリティスキャナ報告（URL確認中）
• IBM「The shift from build to operate for AI agents」公式発表（URL確認中）
• 内部参照: ナギ 「使うとき呼ぶAI」は終わった
• 内部参照: ナギ コードを書けなくてもいい時代