はじめに
PoC（Proof of Concept）をやるとき、今まで何をしていたか思い出してほしい。
- まずブログや公式ドキュメントを読み漁る
- ハンズオンやチュートリアルを写経する
- 理解が追いついたら自分の環境で試す
- CloudFormation のデプロイで
CREATE_FAILEDが出たら原因を調べる - 動いたら「なんで動いたんだっけ？」と振り返る
この「勉強 → 実装 → 理解」のサイクルに、どれだけ時間を費やしてきただろうか。
AI IDE「Kiro」を使い始めてから、このサイクルが根本的に変わった。結論から言うと、人間の役割が「作る人」から「理解して判断する人」にシフトした。これは怠けているのではなく、むしろ PoC の本質に近づいたと感じている。
従来の PoC フロー
┌─────────────────────────────────────────────────────┐
│ 従来の PoC │
│ │
│ ① 情報収集（ブログ、本、公式ドキュメント） │
│ ② 勉強（概念理解、ベストプラクティス把握） │
│ ③ 設計（自分で構成を考える） │
│ ④ 実装（手組みでコードを書く） │
│ ⑤ デバッグ（CFn の ROLLBACK_COMPLETE と格闘） │
│ ⑥ ドキュメント作成（後回しになりがち） │
│ │
│ 所要時間: 数日〜数週間 │
│ ボトルネック: ①②の勉強時間 │
└─────────────────────────────────────────────────────┘
正直に言えば、PoC の目的は「この技術が使えるか検証すること」であって、「この技術を完璧に理解すること」ではない。しかし従来のフローでは、まず理解しないと手が動かなかった。
特に世の中に情報が少ない新しい技術やサービスの PoC では、ブログも本も参考になるものがなく、ひたすらトライ＆エラーを繰り返すことになる。この時間が本当に辛い。
Kiro 時代の PoC フロー
┌─────────────────────────────────────────────────────┐
│ Kiro 時代の PoC │
│ │
│ ① やりたいことを Kiro に説明する │
│ ② 要件定義書が自動生成される │
│ ③ 承認する（人間） │
│ ④ 設計が始まる │
│ ⑤ 承認する（人間） │
│ ⑥ タスク化され IaC が作成される │
│ ⑦ 眺めながら「これどういう意味？」と聞いて学ぶ │
│ ⑧ すべて理解できたらデプロイを命令する │
│ ⑨ 完成！ドキュメントも自動生成済み │
│ │
│ 所要時間: 数時間〜1日 │
│ ボトルネック: ⑦の理解・判断 │
└─────────────────────────────────────────────────────┘
ボトルネックが「勉強」から「理解・判断」に変わった。 これが最大の変化だ。
具体的にどう変わったか
Step 1: やりたいことを説明する
従来なら「まず AWS のドキュメントを読んで、VPC のサブネット設計を理解して、セキュリティグループのルールを調べて…」と準備が必要だった。CIDR の計算で /24 と /28 の違いを確認し、ルートテーブルの経路がどう伝搬するかを把握し、やっとテンプレートを書き始める。
Kiro では違う。
「3層アーキテクチャの VPC を作りたい。
Web 層はパブリック、App 層と DB 層はプライベート。
NAT Gateway は冗長化して、各 AZ に配置。」
これだけ伝えればいい。技術的な詳細を事前に調べる必要はない。Kiro が「こういう構成でいいですか？」と聞き返してくるので、対話の中で詰めていく。
Step 2: 要件定義の自動生成
Kiro の Spec 機能が要件定義書（requirements.md）を自動生成する。ここで面白いのは、自分が見落としていた観点を AI が指摘してくれること。
- 「NAT Gateway のルーティングはどうしますか？」
- 「VPC エンドポイントは必要ですか？」
- 「フローログの保存先は？」
従来なら、これらの観点に気づくまでにドキュメントを何ページも読む必要があった。AI との対話で数分で網羅できる。
Step 3: 承認する（人間）
ここが重要。AI に丸投げではない。 要件定義の内容を読み、「これで良い」と判断するのは人間だ。
承認の基準は：
- 自分がやりたいことと合っているか
- 過剰な要件が含まれていないか
- セキュリティ上の懸念はないか
「理解してから承認する」のではなく、「承認しながら理解する」。わからない部分は Kiro に聞けばいい。
Step 4-5: 設計と承認
設計書（design.md）が自動生成される。Mermaid 形式のアーキテクチャ図、コンポーネント一覧、依存関係マップが含まれる。
ここで出てくる設計は、ベストプラクティスに基づいている。Well-Architected Framework の考え方が自然に取り込まれている。従来なら「これがベストプラクティスなのか？」と不安を抱えながら進めていたところを、AI が根拠を示しながら設計してくれる。
Step 6: タスク化と IaC 生成
設計が承認されると、実装タスクに分解され、CloudFormation や Terraform のテンプレートが生成される。
この段階で人間がコードを書く必要はない。 生成された IaC を読むだけでいい。
Step 7: 学びのフェーズ（ここが本質）
ここが Kiro 時代の PoC で最も価値がある部分だ。
生成された IaC を読みながら、わからない部分を Kiro に質問する：
「この SecurityGroup の Ingress ルールで、
SourceSecurityGroupId を使っているのはなぜ？
CIDR で指定するのとどう違うの？」
Kiro は文脈を理解しているので、そのプロジェクトの設計意図を踏まえて回答してくれる。公式ドキュメントの一般論ではなく、今まさに作っている構成に即した説明が返ってくる。
これは「ブログで勉強する」のとは質的に違う学びだ。
- ブログ: 汎用的な説明。自分の環境に当てはまるか判断が必要
- Kiro: 自分の構成を前提とした、コンテキスト付きの説明
Step 8: デプロイ
すべてを理解し、問題ないと判断したらデプロイを命令する。
「このテンプレートをデプロイして。
スタック名は poc-web3tier-vpc で。」
ここでも人間が最終判断を下している。AI は提案し、人間が承認する。この関係が崩れない限り、安全性は担保される。
Step 9: ドキュメント
PoC が終わった時点で、以下が揃っている：
- 要件定義書（なぜこの構成にしたか）
- 設計書（何を作ったか）
- タスクリスト（どう作ったか）
- IaC テンプレート（再現可能なコード）
従来なら PoC 完了後に「ドキュメント書かなきゃ…」と憂鬱になっていたところが、プロセスの副産物として自動的にドキュメントが生まれている。
人間の役割はどう変わったか
| 従来 | Kiro 時代 | |
|---|---|---|
| 情報収集 | 人間がブログ・本を読む | AI が知識を持っている |
| 設計 | 人間が構成を考える | AI が設計し、人間が承認する |
| 実装 | 人間がコードを書く | AI がコードを生成する |
| デバッグ | 人間が CFn イベントログと格闘する | AI が修正を提案する |
| 理解 | 事前に勉強する | 事後に質問して学ぶ |
| 判断 | 理解した上で判断する | 判断しながら理解する |
| ドキュメント | 後から書く（書かないことも…） | プロセスの副産物として生成 |
人間がやるべきことは「判断」と「質問」の 2 つに集約された。
ブログや本で勉強する時代は終わったのか
「終わった」は言い過ぎだ。正確には、PoC の文脈では優先度が下がった。
従来の勉強が有効な場面：
- 基礎概念の体系的な理解（AWS 認定試験の学習など）
- 設計思想や哲学の理解（なぜそうなっているかの背景）
- コミュニティの知見やノウハウの共有
Kiro が得意な場面：
- 「今すぐ動くものを作りたい」PoC
- 具体的な構成に対する「これはどういう意味？」という疑問
- ベストプラクティスの適用（AI が最新の推奨構成を知っている）
つまり、「体系的に学ぶ」と「実践的に学ぶ」が分離した。PoC は後者の領域であり、Kiro はそこに特化している。
実例: Proxmox VE の PoC
今まさに Kiro で進めている PoC がある。オンプレの仮想化基盤「Proxmox VE」の検証だ。
これが従来のやり方だったら、こうなる：
- Proxmox VE の公式ドキュメントを英語で読む
- 日本語のブログを探す（情報が少ない）
- インストール手順を理解する
- ネットワーク構成を調べる
- ストレージの設計を考える
- 手動でインストールして試す
- エラーが出たらフォーラムを漁る
Kiro でやったこと：
- 「Proxmox VE のシングルノード PoC 環境を構築したい」と伝えた
- Kiro が要件を整理してくれた（インストール、ネットワーク、ストレージ、VM管理、LXC、バックアップ、GUI、文書化）
- 要件を承認した
これだけで、8つの要件と詳細な受入基準が自動生成された。 自分が「LXCコンテナもやるべきだな」「バックアップ・リストアの検証も入れよう」と気づく前に、AI が網羅的に提案してくれた。
Proxmox VE は AWS のようなクラウドサービスと違って、物理サーバーへのインストールが必要だ。IaC で完結する世界ではない。それでも Kiro の Spec 機能は「何を検証すべきか」「どういう順序で進めるか」「合格基準は何か」を構造化してくれる。
PoC の本質は「動かすこと」だけではなく、「何を検証すれば判断できるか」を明確にすることだ。そこを AI が支援してくれるのは、物理インフラの PoC でも変わらない。
PoC で特に効くのはなぜか
PoC には特有の事情がある：
- 世の中に情報が少ない: 新サービスや新機能の PoC では、ブログも本もまだ存在しない
- トライ＆エラーが前提: 正解がわからない状態で進める
- 完璧さは求められない: 動くことの証明が目的
- 速度が重要: 判断材料を早く得たい
Proxmox VE はまさにこの典型だ。日本語の情報は限られているし、エンタープライズ向けの設計ガイドはほぼ存在しない。従来なら英語のフォーラムを読み漁って数日かけるところを、Kiro との対話で数時間で要件が固まった。
これらの特性は、Kiro のアプローチと完全にマッチする：
- AI は公式ドキュメントと API 仕様から構成を提案できる（ブログ不要）
-
ROLLBACK_COMPLETEになったら AI がイベントログを読み解いて修正案を出す（人間のデバッグ時間削減） - CloudFormation / Terraform テンプレートの生成は AI の得意分野
- 数時間で PoC が完了する
注意すべきこと
AI を信用しすぎない
Kiro が生成した IaC が常に正しいとは限らない。特に以下は人間が確認すべき：
- セキュリティグループのルール（意図しないポートが開いていないか）
- IAM ポリシー（過剰な権限が付与されていないか）
- コスト影響のあるリソース（NAT Gateway、RDS など）
「理解」を省略しない
「動いたからOK」で終わらせると、本番で同じ構成を使うときに判断ができなくなる。Step 7 の「学びのフェーズ」を飛ばさないこと。
PoC の目的は「動くこと」の証明だが、その過程で得られる理解こそが、本番構築への橋渡しになる。
PoC の範囲を明確にする
AI が提案する構成は「ベストプラクティス」に寄りがちだ。PoC で必要な最小構成を人間が判断し、過剰なものは削る。PoC はシンプルであるべきだ。
PoC 環境は Sandbox — 使い捨てが前提
PoC 環境は検証が終わったら即座に消す。これが鉄則だ。
理由は単純で、お金がもったいない。NAT Gateway は置いてるだけで月 $30 以上かかるし、RDS は停止しても 7 日で自動起動する。「あとで使うかも」と残しておくと、月末の請求で後悔することになる。
IaC で構築しているからこそ、この使い捨て運用が成立する：
検証したい → cfn deploy → 検証する → cfn delete → 完了
再現が必要になったら、同じテンプレートでまたデプロイすればいい。5 分で同じ環境が立ち上がる。「環境を維持するコスト」と「再構築するコスト」を比較すれば、IaC がある限り後者が圧倒的に安い。
Kiro で生成した IaC テンプレートは Git に残っている。Spec の設計書も残っている。環境を消しても知識と再現性は失われない。これが「Sandbox 思考」の PoC だ。
そしてもう一つ重要なこと。Sandbox だから、AI が間違えても怖くない。 AI が生成した CloudFormation テンプレートに誤りがあっても、Sandbox 環境なら本番に影響しない。CREATE_FAILED になったら原因を AI に聞いて修正させればいい。最悪、スタックごと消してやり直せばいい。
この「失敗してもノーダメージ」の安心感が、AI とのトライ＆エラーを加速させる。本番環境で AI の出力を恐る恐る試すのと、Sandbox で気軽に壊して直すのでは、学習の速度がまったく違う。
まとめ
Kiro を使った PoC は、「人間が全部やる」から「AI と分業する」へのシフトだ。
- AI の仕事: 情報収集、設計、実装、ドキュメント生成
- 人間の仕事: 意思決定、承認、質問、理解
「勉強してから作る」時代から、「作りながら学ぶ」時代へ。PoC のスピードは劇的に上がり、しかも理解の深さは変わらない（むしろ、自分の構成に即した説明を受けられる分、深くなる場合もある）。
ブログや本が不要になったわけではない。でも PoC に限って言えば、AI に作らせて、それを教材にして学ぶ方が圧倒的に効率的だ。
これからの PoC は、「やりたいことを言語化できる力」と「AI の出力を評価・判断できる力」が問われる。プログラミングスキルよりも、アーキテクチャの目利き力が重要になる時代だと感じている。
こういう時代にAWS + Kiroの相性の良さはまさにカモネギ(笑)
是非、活用してPoCしまくってください。
環境情報
- Kiro 0.12.224（VSCode 1.107.1 ベース）
- OS: Windows 11（x64）
- Spec 機能（要件定義 → 設計 → タスク → 実装の構造化ワークフロー）
- PoC 対象: Proxmox VE（オンプレ仮想化基盤）