【通算095｜要求AI 12】Kiro検証の棚卸し——見えた6つの問題と、解決の方向

2026年7月25日 21:04

これまでの Kiro の検証記事。

雑な一文から始めて、要件定義書・設計書・タスクリスト、そして未完に終わった実装まで。1週間のKiro検証で見えた問題を、ここで棚卸ししておきたい。良かった点は連載で書いてきたとおりだ（3層のトレーサビリティ、本物のテスト、ファイルが正の思想）。今日は問題の側を整理する。

見えた6つの問題

① クラウド従量制という構造。 レート制限で止まり、月間上限で強制終了した。生成の品質に問題はなかったのに、完走できるかどうかはクレジット残高が決めた。クラウドのLLMを従量で使う以上、これは避けられない構造だ。

② 沈黙の空転。 一番高くついたのはこれだ。エラーも出さず、スピナーだけが回り、85分で無料枠の4割が消えた。異常を知る手がかりは、ツールの画面の外——ファイルの更新時刻とクレジットの数字——にしかなかった。

③ 業務を聞かない。 検証を通じて、Kiroが業務の質問をしたことは一度もない。雑な指示には「世間一般の答え」を、詳しい指示には「書いた分だけ」を返す。要求の質は、最初から最後まで人間任せだった。

④ 忠実さの罠。 指示を構造化するほど、Kiroは指示に忠実になる。書いたことは正確に反映される——そして書き漏らしたものは、静かに消える。前回の検証で「取り下げ機能」が消えたように。

⑤ 紛れ込み。 頼んでいない「下書き」状態が設計に紛れ込み、要件・設計・タスク・実装の全工程を誰にも気づかれず通過した。AIの学習知識にある「定番」は、書かなくても入り込む。善意の発明（利益相反チェック）と同じ顔でやってくるから、始末が悪い。

⑥ 人間のチェックの形骸化。 タスクリストには「疑問があればユーザーに聞く」というチェックポイントが3か所書かれていた。実行されたのは0回。文書に書かれた人間の出番は、実行エンジンの中で「完了したはず」と推論され、素通りされた。

並べてみると、6つは2つのグループに分かれる。

実行環境の問題（①②）——これはツールの中では解決できない。クラウド従量制をやめるか、監視の仕組みを外に持つしかない。

要求の質の問題（③④⑤⑥）——AIは要求の質を引き上げてくれない。書いた分だけ。ならば、書く側の技術で立ち向かうしかない。実は30年前の要求工学が、まさにこの「書く側の技術」を蓄積している。

次の手は2つの軸で考える。

上流の軸: 要求を「4つの視点」（内容の枠）と「型のある書き方」で整える。型のある書き方——実は今回の検証の中に、そのヒントがずっと写り込んでいた。Kiroの要件定義書に並んでいた「WHEN 〜, THE システム SHALL 〜」という定型文。あれには名前と、ジェットエンジンから始まる歴史がある
実行環境の軸: クレジットの壁がない場所——ローカル・定額の環境でSDDを回せないか

この2つを、次から順に掘っていく。