Kiro仕様駆動開発の現場実践、コンテキスト汚染を遮断するディレクトリ設計

• 現場の事実：内製SPA開発においてKiro CLIを導入し、未経験者がspecモードとhooksを活用して実装を完遂。
• 技術の核心：使用済みspecのarchive化や.kiroignoreにより、コンテキスト汚染を遮断する厳格な設計を採用。
• 実務への直結：AIによる「テストの骨抜き」を防ぐため、仕様マスターとテスト対応表の自動同期フローが有効打となる。

深夜のデバッグ作業で、AIチャットに「このエラーを直してくれ」と懇願した経験は誰にでもあるはずだ。最初の数回は小気味よく動作していたコードが、対話を重ねるにつれて前後の文脈がスパゲッティのように絡まり合い、最終的には存在しない関数の呼び出しを無限ループのごとく繰り返す。我々エンジニアがAI駆動開発（AI-Driven Development）で真っ先に直面する壁が、この「コンテキスト汚染」である。LLMは与えられた入力の質に完全に従属する存在であり、ノイズが混入した瞬間に精度の崖を転がり落ちる。今回取り上げる内製Webアプリケーション開発の実践ログにおいて、著者が最初に辿り着いた「一番大事なこと」がコンテキストの純度維持であった点は、まさに現場の泥臭い戦いから得られた至言と言える。

著者が採用した開発基盤「Kiro（kiro-cli）」の運用において、最も注目すべきはディレクトリ構成を通じた物理的な情報の遮断だ。リポジトリルートに配置された.kiroignoreと、.kiro/specs/archiveという隔離ディレクトリの存在がその象徴である。機能開発時に作成されるrequirements.md、design.md、tasks.mdといった仕様群は、機能リリース後にそのまま残しておけば、次の機能追加時に「古い仕様」としてエージェントの推論を狂わせるノイズと化す。過去の仕様書を速やかにarchiveディレクトリへ隔離し、.kiroignoreでKiroの参照対象から完全にパージするアプローチは、LLMのトークン制約とアテンションの散漫化を防ぐための極めて合理的で実用的な防御壁だ。コンテキストウィンドウをクリーンに保ち続ける仕組みを規律として組み込めるかどうかが、実務におけるAI駆動の成否を分ける分水嶺となる。

Kiroが提供する「specモード」は、単なるコード補完ではなく、要件定義からタスク分解までを段階的に進める仕様駆動開発（SDD）を前提としている。しかし、AIにタスクを丸投げした瞬間に発生するのが、動くけれども保守不能なコードが量産されるという悪夢だ。このリスクを回避するために現場が構築したパイプラインは実に洗練されている。.kiro/hooks/tdd-test-first.jsonをトリガーとし、新規ファイルが作成される前に必ずテストの作成を検討させるフックの導入だ。これにより、AIが勝手に推論の近道を選んでテストのない実装コードを吐き出す挙動を構造的にブロックしている。

実装終了後のワークフローも綿密に練られている。単にテストが通ったからコミットするのではなく、カスタムスキルである/update-test-coverageを叩き、docs/this-tool/requirements.mdという仕様マスターと、それに対応するテストの突合表（requirements-test-coverage.md）を即座に更新させる。このステップを踏むことで、「コードが変更されたが仕様書が放置されている」あるいは「仕様とテストの対応関係がブラックボックス化している」という、受託・内製を問わず発生するレガシーコード化の温床を根本から断ち切っている。AIにコードを書かせること以上に、AIを使って仕様とテストの同期性を維持させる仕組みこそ、我々が導入すべき真の自動化プロセスだと痛感させられる。

AIにタスクを委譲し、驚異的な速度で機能が追加されていく快感の裏で、著者が吐露している課題感は極めて示唆に富んでいる。第一の課題は、テストの「骨抜き」リスクだ。AIにテストコードを書かせると、アサーションが甘く、単にカバレッジのパーセンテージを埋めるためだけの無意味なテストを平然とパスさせてしまうことがある。いわゆるモックだらけで何も保証していないテストスイートの完成だ。このテストが網羅的かつ堅牢であるかをジャッジするには、皮肉にも人間の側に相応のソフトウェア工学のバックボーンと、エッジケースを見抜く設計経験が求められる。コーディングという手を動かす作業から解放された結果、より高難度な「テストの質を吟味する監査能力」が開発者に突きつけられているのだ。

そして第二の課題が、開発プロセス全体の律速段階が「人間の介入」そのものにシフトした点である。Kiroの実行ステップを見守り、ファイル変更の許可を出し、ブラウザで挙動を確認する。タスク処理の実行速度がどれほど劇的に向上しようとも、最終的な動作検証と合否判定を人間が逐一レビューしている限り、パイプライン全体のターンアラウンドタイムは人間の認知限界で頭打ちになる。ループエンジニアリングにおける「Human in the Loop」のボトルネック化だ。著者が言及しているように、Model Context Protocol（MCP）経由でPlaywrightなどのヘッドレスブラウザを駆動させ、E2Eテストや画面確認までを機械の責務としてどこまで委ねられるか。人間が見るべきテストと機械に委ねる検証の境界線を再定義しない限り、チーム全体の生産性が真のブレークスルーを迎えることはないだろう。

フロントエンド未経験の開発者がAIを活用して業務システムを完成させたという事実は、一見すると「コーディングスキルの民主化」という甘美なストーリーに見える。だがその実態は、コンテキストの厳格なパージ、TDDのフック化、仕様とテストの同期といった、高度なソフトウェアアーキテクチャの規律をAIエージェントに強制する枠組みを設計できたからに他ならない。我々シニアエンジニアが明日から自らのプロジェクトに適用すべき実践的な処方箋は明白だ。まずはローカルの開発環境において、AIに参照させるコンテキストの「賞味期限」を定義し、終わったタスクの仕様書をプロジェクトから隔離するルールを構築することだ。LLMを盲信するのではなく、GitのコミットフックやCLIの機能を使って、テストのないコード生成を物理的に阻止するガードレールを敷かなければならない。

構文の暗記やフレームワーク特有のボイラープレートの記述といった瑣末なノウハウの価値が急落していく中で、エンジニアに残された領域は何か。それは、ドメインの境界を見極め、AIが吐き出したテストが「本当にクリティカルな障害を防ぎ得るか」を冷徹に疑い、検証可能な仕様へと落とし込む能力である。機械がコードを書き、機械がテストを実行する時代において、我々はAIを走らせるための強固なレールを敷く設計者でいられているだろうか。それとも、AIが吐き出す不完全なコードの承認ボタンを機械的に押し続けるだけの、安価な監視員へと成り下がってはいないだろうか。自らの日々の開発フローを今一度見つめ直す必要がある。