Kiro + MCP で実装とテストを自動化する

はじめまして！APでエンジニアインターンをしている鈴木鴻太です。

今回は、AWSで開催されたkiroの仕様書駆動体験1dayハッカソンに参加し、そこで得た「未来の開発のあり方」について考察し、実際に検証した過程をご紹介します。

僕が考察する今後レギュラーになってくる開発手法

僕はkiroを使った仕様書駆動開発を体験したことで、「これからの時代は“仕様書”と“受け入れ基準・テスト条件”の2つを起点にし、LLMに“テスト基準を越えるまで”実装を繰り返させる――そんな開発スタイルが主流になっていくのでは？」と感じました。

以下V字のうち、システムテストまでAIに自動化させるといったイメージです。

この考えをもとに、kiroに加えてPlaywright MCPとChrome DevTools MCPという2つのツールを組み合わせ、実際に「仕様書とテスト要件を一体化した開発」がどこまで自動化できるのかを検証しました。

検証フェーズ

検証の全体像

今回の検証では、以下の構成でテスト自動化を組み立てました：

AIエージェント：Kiro
テストツール：Playwright MCP ＋ Chrome DevTools MCP
テスト対象：カウンターボタン（ボタンをクリックするたびに数字が増えるシンプルなWebアプリ）
↓以下画像

検証項目：機能テストとパフォーマンステスト

検証方法と選定理由

従来のテスト自動化では、テストコードの記述やCI/CDへの組み込みが必須でした。しかし、今回の試みではAIエージェントがMCP経由でブラウザを直接操作することで、より自然言語ベース・統合的なテストプロセスを目指しています。

この方式を選んだ主な理由は下記の通りです：

自然言語でテスト指示が可能
　「ボタンを5回クリックして」など、直感的な指示で実行できる
複数ツールの統合が容易
　機能テスト・パフォーマンス測定のツール切り替え不要
柔軟な検証が可能
　テスト手順や基準の変更が容易

定義した受け入れ条件

検証に入る前に、今回のアプリとそのテスト全体に対し9つの要件と受け入れ条件を明確に定義しました。
この“要件を仕様としてAIに渡す”という考えこそ、仕様書駆動＋テスト自動化の根幹になっています。

主要な要件・受け入れ基準（抜粋）

基本機能要件：「押してね」ボタンで連続する数字がインクリメントされること（1から開始。無制限クリックOK）
UI応答性／パフォーマンス要件：100ms以内でUI反映、50ms以内のJS実行、LCPは2.0秒以下、CLSは0.1以下
機能テスト自動化要件：Playwright MCPでクリックと数字検証を自動化（高速クリックも含む）
パフォーマンステスト自動化要件：Chrome DevTools MCPで各Core Web Vitals、UI応答、JS時間の自動計測
異常系テスト要件：数字が正しく増えない場合もAIが気付けること
テスト結果/履歴記録要件：Markdown形式で全履歴・実測値・合否・スクリーンショット等を時系列記録
自律的な問題分析・修正要件：AIが失敗理由を分析し、修正版を提案・再テストできるように設計（今後拡張予定）

テスト条件の整理

機能側：クリック操作・数字シーケンス・UI識別・高速操作の検証
パフォーマンス側：LCP, CLS, UI応答, JS実行時間の閾値基準
結果記録側：Markdown/時系列/合否/スクショ/タイムスタンプ

実際の検証手順

1. 機能テスト（Playwright MCP）

Playwright MCPを使い、UI操作および表示内容の自動検証を行いました。

検証フロー：

ページロード（file://kiro-test/index.html）
ボタンを10回クリック
数値表示が1〜10まで正しくインクリメントされるか確認
スクリーンショット撮影
ブラウザをクローズ

実行コマンド例（概念）：

await mcp_playwright_playwright_navigate({ url: fileUrl, headless: false, width: 1280, height: 720 });
await mcp_playwright_playwright_click({ selector: '#counter-button' });
const visibleText = await mcp_playwright_playwright_get_visible_text();

結果：

ボタンクリックテスト：合格
数字シーケンス検証：合格（1～10）
UI要素識別テスト：合格

2. パフォーマンステスト（Chrome DevTools MCP）

Performanceメトリクス取得にはChrome DevTools MCPを活用しました。

検証フロー：

ページに移動
パフォーマンストレース開始
ページリロード
トレース停止・メトリクス取得
JavaScript実行時間測定（10回繰り返し）
スクリーンショット撮影

実行コマンド例（概念）：

await mcp_chrome_devtools_performance_start_trace({ reload: true, autoStop: false });
await mcp_chrome_devtools_performance_stop_trace();
await mcp_chrome_devtools_evaluate_script({ function: '...カウンター処理...' });

結果（抜粋）：

メトリクス	実測値	判定基準	合否
LCP	217ms	≤2.0秒	合格
CLS	0.00	≤0.1	合格
JavaScript実行時間	0.01ms（平均）	≤50ms	合格

LCP内訳：TTFB 0.7ms／レンダリング遅延 216ms
JS実行時間：最小0ms／最大0.1ms／平均0.01ms（10回測定）

テスト結果の記録

テスト結果は自動的に test-results.md に記録され、下記の情報が時系列で残ります：

総合判定（合格／不合格）
各テスト詳細
パフォーマンスメトリクス（統計値）
スクリーンショットへのリンク
実行環境・条件

気付きと学び

実際に得られた知見

1. AIエージェントによる柔軟なテスト実行

従来の自動テストはスクリプト化が前提ですが、Kiro＋MCPでは自然言語での即応テストが可能です。
指示文を修正するだけでロジックや手順を即座に切替でき、探索的テストや要件変化への迅速対応に適しています。

2. MCPツールの統合の容易さ

Playwright MCPとChrome DevTools MCPをひとつのAIワークフロー上で同時利用でき、機能・性能検証を一気通貫で回すことができました。従来必要だった手作業や別ツールでの結果統合は不要です。

3. パフォーマンスメトリクスの詳細取得

Chrome DevTools MCPにより、Core Web Vitalsの細かい内訳（例：TTFB、レンダリング遅延）も取得できるため、ボトルネック分析が容易です。

4. テスト結果の自動履歴管理

Markdownファイルへの自動記録によって、履歴比較・品質推移・視覚確認（スクリーンショット）の管理が一気に楽になりました。

メリット・新しい発見

メリット：

テストコード量の削減（自然言語指示＋抽象化されたAPI）
多様なツールの統合が自動化可能
柔軟なシナリオ変更への即応性
パフォーマンス分析の精度向上

新しい発見：

AIエージェント環境がテスト実行基盤になる
MCPによる周辺ツール拡張性（APIテスト、DBテスト等）も期待大
Markdown記録で可読性・共有性が高い

課題・注意点と対応策

テストスクリプトの実行環境の制約：
Kiroエージェント環境限定のAPIのため、CI/CD本体に組み込むには別途工夫が必要。

対応策：

KiroとCI/CDパイプラインの連携構築
エージェント用／CI用スクリプトの分割

非決定的な動作の可能性：
AIエージェントの解釈や実行タイミングにより、出力が前後することがある。

対応策：

重要シナリオは厳密なスクリプトで手厚く担保
判定ロジックを明示し、結果検証を厳密化

パフォーマンス測定の環境依存性：
結果はローカル環境依存が大きい。本番想定なら条件を揃える必要あり。

対応策：

本番近似環境での測定
複数回実施・統計値の採用
実行環境の記録

スクリーンショット管理：
テスト実行ごとにファイルが増えるため、ライフサイクル管理・保存ルールが必要。

対応策：

定期削除／重要ファイル選別
クラウドストレージ化

今後の展望

CI/CD統合：
GitHub Actions連携や自動テストコメントなど、パイプライン自動化との一体運用を進めたい。

テスト結果可視化：
データのグラフ表示やアラート機能、履歴比較なども今後取り入れていく予定です。

まとめ

今回の取り組みを通じて、定義した要件と受け入れ条件をAIエージェント（kiro）に明確に渡すことで、「実装＋テスト自動化」のサイクルを一気通貫でAIが担えることを検証できました。

従来はプログラミングとテストの自動化は分業的でしたが、「仕様＝テスト条件＝AIによる開発・検証基準」とする新しい“仕様書駆動開発”の形が具体的に実現できたと感じています。
これにより、従来は「8割AIに書かせて残りの2割を開発者が担当する...」といったところを「9割AIに書かせて残りの1割を開発者が担当する...」といった温度感にできるのではないかと思っています。

また、今後は複雑な要件や大規模プロジェクトにも幅を広げ、「要件定義→実装→自動テスト→履歴記録→自律的な修正提案」まで含めてAIが開発を担う。そんな実践フェーズがやってくると思っています。