生成AIが登場した頃、プロンプトには神秘的な雰囲気がありました。「うまく書けばすごいものが出てくる」「書き方のコツがある」といった文脈で語られ、プロンプトエンジニアリングという言葉まで生まれました。

この時期のイメージを引きずっているチームがまだ多い、と私は感じています。でもAIの性能が上がった今、プロンプトに求められるのは「明快で、誤解のない、指示そのもの」です。神秘性は消えて、代わりに「ビジネス文書としての品質」が問われるようになりました。

任せるのではなく、指揮するという発想

多くの現場で見かけるのは、AIに「任せる」感覚での使い方です。「いい感じにやっておいて」と投げて、出てきたものを受け取る。

私が提案したいのは、「指揮する」という発想への切り替えです。指揮者はオーケストラで、演奏自体は奏者に委ねます。でも全体のテンポ、強弱、入りのタイミング、全体の設計は指揮者の仕事です。

AIと人間の関係も、これに近づいていくべきだと考えています。演奏はAIに委ね、設計は人間が握る。これが、プロンプトを組織で運用するときの基本姿勢です。

指揮するプロンプトに含まれる4つの要素

要素1：コンテキスト（前提情報）——AIは背景を知らなければ文脈に沿った判断ができません。「既存システムは10年もので、SOAPを使っている」といった前提を先に渡します。

要素2：制約条件——「これは使える、これは使えない」を明示。技術スタック、禁止事項、品質要件など。制約がないとAIは無限の可能性から適当に選びます。

要素3：期待するアウトプット形式——コードのみか解説付きか、配置場所、コメントの言語など。「察してくれるはず」はAIには通じません。

要素4：評価基準——「どういう結果なら合格か」を最初に明示。テストが通る、スタイルガイドに従う、セキュリティベストプラクティスが守られる、など。事後のレビューで修正するより、ずっと効率的です。

これら4要素は、人間のプロジェクトマネジメントで言えばスコープ、制約、成果物、完成基準にあたります。

「考えさせる」のか「作らせる」のか、の使い分け

プロンプト設計でもうひとつ重要な観点があります。AIに何を期待するか、という軸です。

考えさせる使い方：「この設計でいいか、問題点を洗い出して」「このバグの原因を仮説として挙げて」——AIの発散的な思考を借りる使い方。

作らせる使い方：「この仕様に従ってこの関数を実装して」——決められた成果物を出させる使い方。

この2つは、求めるプロンプトの書き方が違います。考えさせるときはやや抽象的な問いのほうが視野が広がります。作らせるときは制約と評価基準をガチガチに固めたほうが精度が上がります。

要件定義とテストが、プロンプトの精度を上げる

ここで、第4話と第5話の内容が戻ってきます。要件定義書と、Given-When-Then形式の受け入れ条件が整っていれば、プロンプトの4要素のうち3つまでが既に揃っているのです。

• コンテキスト → 要件定義書の「前提・背景」
• 制約条件 → 要件定義書の「非機能要件」「やらないこと」
• 評価基準 → 受け入れ条件（テストとして実行可能）

残るはアウトプット形式の指定だけ。つまり仕様駆動開発とテスト駆動を回している組織なら、プロンプトはほぼ自動的に精度が上がるのです。4つの象限は独立ではなく連動している——プロンプトの話をしていても、結局は要件定義とテストの話に戻ってきます。

属人プロンプトからチームプロンプトへ

多くの現場で起きているのが、プロンプトの「属人化」です。特定個人のプロンプトは精度が高いが、その人がいないと品質が落ちる。しかも書かれたプロンプトはチャット履歴の中に埋もれて再利用もレビューもされない。

これは組織としては危うい状態です。個人の暗黙知に依存した品質は再現性を持ちません。プロンプトをチームで共有し、レビューし、バージョン管理する。ドキュメントやコードと同じ扱いにする——具体的な仕組みは次回、第8話で踏み込みます。

もし、AIがジャズセッションのように動いたらどうなるか

指揮者のいるオーケストラは楽譜に沿って演奏します。一方、ジャズセッションには指揮者も楽譜もありません。奏者たちはお互いの音を聴きながら即興で演奏を作ります。

「AIにはジャズセッションのように動いてほしい」と感じる場面、ありますよね。これが次回第8話で扱うAIオーケストレーションの典型イメージです。

ただ、立ち止まって考えてみてください。ジャズセッションはなぜあの自由度で成立するのか。奏者が全員プロで、互いのスタイルを理解し、暗黙のルール（コード進行、リズム、スタンダード）を共有しているからです。初心者が集まれば、自由ではなく不協和音になります。

AIのオーケストレーションも同じ構造。自由な運用にはそれにふさわしい前提が要ります。要件定義、受け入れ条件、制約——これらが明示されて初めて、AIの自律が価値を生むのです。

まとめ — 指揮者のいるオーケストラは、美しい音を出す

指揮者のいないオーケストラを想像してみてください。各奏者は優秀です。でも全体のテンポがバラバラ、入りのタイミングが合わない。技術的には間違っていないのに、音楽としてはどこか崩れている。

AIに「任せる」だけの組織は、これに似ています。個々の成果物は悪くない。でも全体としての設計思想が見えない。長く続けるほど音がズレていく。

そこに指揮者が立つ。同じ奏者、同じ楽譜なのに、全体がひとつの音楽に変わる。これがプロンプトを「指揮する」ということです。指揮者の仕事は、演奏することではありません。全体の設計を持ち、一人ひとりに伝える。AIの時代に私たち人間に残された役割は、この指揮者の立ち位置にあるのではないかと感じています。

テストの数や「カバレッジ率」（テストが実行するコード範囲の割合）という指標を、経営報告で見たことがあるかもしれません。「テストカバレッジ90%」といった数字ですね。一見、品質の証拠に見えます。

ただ、ここに落とし穴があります。カバレッジ率は「テストが実行された範囲」を示すだけで、「きちんと検証された範囲」を示すわけではないのです。

ビジネスに例えましょう。ある管理職が社員50人全員と面談し「面談カバレッジ100%」と書ける状態でも、面談が形式的な顔合わせだけなら何も把握できません。数字は100%、実質は何も検証していない——テストのカバレッジ率も同じことが起こり得ます。

なぜAI時代に、この落とし穴が深刻化するのか

AIに「この機能のテストを書いて」と頼むと、一応それっぽいテストが返ってきます。カバレッジ率も上がり、数字の見た目は良くなります。ところが中身を吟味すると、「機能を実行しているだけで、正しく動いているかを確認していない」ケースが結構な割合で混ざります。

なぜか。AIは「カバレッジを上げる」目標があればそれを満たすテストを書けます。でも「何を本当に守りたいのか」というビジネス判断はAIにはできません。だから人間が指示を出さないと、数字は上がっても中身が空っぽなテストが量産されます。

テストの「質」を見るための3つの観点

観点1：重要な機能が、ちゃんと守られているか——すべての機能に同じ厚みのテストは要りません。ビジネス上の重要機能（決済処理、個人情報の取り扱い、契約更新ロジックなど）ほどテストが厚くあるべき。重要度とテストの厚みが釣り合っているかを見るのが管理職の視点です。

観点2：壊したときに、ちゃんと気づけるか——テストの本質的な役割は、将来誰かがコードを変更したときに壊れたら知らせてくれること。良いテストは「このコードを壊したら、このテストが失敗する」関係がはっきりしています。「このテストは、コードが壊れたときに気づける構造になっていますか？」と問えます。

観点3：テストそのものが、信頼できるか——同じコードなのに、ある日は通る、ある日は落ちる不安定なテストがあると、開発チームは「テストはまた失敗している。でも気にしなくていい」という感覚になります。最も危険な状態です。「テストの失敗が、たまにある『誤報』として扱われていませんか？」と問えます。

経営に「テストの質」を説明するときの言葉

経営層に「テストの質を上げたい」と相談するとき、どう説明すれば伝わるでしょうか。私が使うのは、この言い換えです。「テストに投資するのは、保守フェーズでの支払いを前倒しすること」だと。

テストが弱いプロジェクトは、リリース後に払うコストが大きい。障害対応、リファクタリング、緊急パッチ——これらはすべて後から降ってくるコストです。しかも降ってくるタイミングは、往々にして「今それどころじゃない」とき。

テストを充実させる投資は、このコストを「計画的に今払う」選択。恐いのは、見えないコスト。経営にとって、計画可能なコストは恐くありません。

AIにテストを書かせるなら、人間は何を見るか

AIにテストを書かせる運用は便利です。ただし、AI生成テストには大きな弱点があります。「実装が正しい前提」でテストを書く傾向があるのです。

AIはコードを見て、「そのコードが意図どおりに動くか」のテストを書きます。「意図」を既存コードの振る舞いから推測するため、実装が間違っていてもその間違った振る舞いに合わせてテストが書かれてしまうことがあります。実装に追随するテストは、実装の間違いを増幅するだけです。

AIにテストを任せるなら、人間は「そもそも何を守るべきか」を明確に指示する必要があります。この指示があってこそ、AIのテスト生成能力は味方になります。

まとめ — テストの質を、4段階で自己診断する

あなたの会社のテストの扱い方は、どの段階にあるでしょうか。

• レベル1：テスト数やカバレッジ率を測っていない → まず測定から
• レベル2：数は測っているが、中身の質までは確認していない → 「重要機能が守られているか」を問い始める
• レベル3：重要機能のテストは厚いが、AIに任せきりの箇所もある → AI生成テストのレビュー追加
• レベル4：重要度・壊れたら気づけるか・信頼できるかの3観点で管理 → AI時代のテスト運用として成熟

多くの組織はレベル1か2にいます。いきなり4を目指す必要はありません。次の1段階に進む小さな投資から始めるのが現実的です。

最近こんな声をよく聞きます。「AIが精度高くコード書いてくれるなら、テストなんて要らないのでは？」

気持ちは分かります。AIが賢く間違いも少ないなら、二重チェックする必要はなさそう。ただ、これは根本的な勘違いです。ここでいう「テスト」は、動きを確かめる検査だけを指すのではありません。「何をもって正解とするかを、先に決めておく」という役割こそが、テストの本質なのです。

実際にAI開発の現場で起きている問題を考えてみましょう。ChatGPTやCopilotにコード生成を頼むとき、多くの開発者が経験するのは「動くコードは出てくるが、本当に求めていた機能なのか分からない」という状況です。AIは忠実にプログラムを書いてくれますが、「何が正解の動作か」までは判断してくれません。

従来の開発では、コードを書いてから「これで合ってるかな？」と確認していました。AI時代は逆転します。「何をもって正解とするか」を先に決めて、それをAIに伝える。この順序の転換が、AI時代の開発効率を左右する分水嶺になっています。

「正解の形」を先に決める、とはどういうことか

ビジネス文書を思い浮かべてください。部下に「A社向けの提案書を作って」と頼むとき、何も補足せずに任せたらどうなるでしょう。ページ数、構成、金額の根拠、提出形式——すべてが部下の解釈次第になります。

できる管理職は、「完成したときに、こんな形であるべき」という基準を先に伝える。「10ページ以内」「競合比較を必ず含める」「金額の根拠を別紙で添付」「PDFで提出」——こう伝えれば迷わず作業でき、差し戻しも最小限で済みます。

これが「正解の形を先に決めておく」ということ。テスト駆動開発は、この考え方をAI時代のコード作りに持ち込むだけなのです。

さらに具体例を挙げてみましょう。ECサイトのカート機能を考えてみます。従来なら「カート機能を作ってください」と依頼して、出来上がったものを確認します。テスト駆動のアプローチでは、まず以下のような「完成基準」を書き出します：

• 商品を3個まで追加できる
• 同じ商品は個数で集約される
• 在庫切れ商品は追加できない
• カート内の合計金額が正しく計算される
• 空のカートでは決済ボタンが無効化される

これらの基準があると、AIも人間の開発者も「何を作るべきか」が明確になります。完成したときの姿が見えているから、迷子になりません。

AI時代にこそ、一見時代遅れに見えるやり方が効く

テスト駆動開発は2000年代初頭から語られる歴史あるやり方で、「今どきテスト駆動？」と感じる方もいるかもしれません。ところが、AIが普及した今、この「時代遅れ」に見える手法が奇妙な形で復権しつつあります。

理由はシンプル。AIに正しく働いてもらうには、「何が正解か」を先に定義しておく必要があるからです。AIは指示された範囲で忠実に動くので、ゴールが曖昧だと迷走します。「完成の基準」を先に書いておくという行為は、AI時代には必須の準備なのです。

GitHub Copilotの開発チームが公開している調査データでは、明確なテスト仕様がある場合、生成されるコードの品質が30%向上し、開発者の作業時間が25%短縮されるという結果が出ています。テスト駆動の「古典的な」アプローチが、最新のAIツールと最も相性が良いという皮肉な現実があります。

さらに興味深いのは、OpenAIがGPT-4の学習に使用したコードの多くが、テスト駆動で書かれた高品質なオープンソースプロジェクトだったという事実です。つまり、AIそのものが「テスト駆動で書かれたコード」から学習している。AIにとって理解しやすいコードの書き方を、私たちは20年前から知っていたのです。

テストコードは「実行できる仕様書」である

従来、テストは「書いたコードが正しいか確認するもの」でした。コードが先、テストが後。新しい発想では、テストは「何を正解とするかを先に定義するもの」になります。テストが先、コードが後です。

つまりテストコード＝実行可能な仕様書。第4話の「受け入れ条件を要件定義書に書く」話と繋がります。「ログイン画面で、正しいメールアドレスとパスワードを入力したら、ホーム画面に遷移する」といった条件を、そのままコードに落とすイメージです。仕様書とテストが一体化した状態。要件定義書とそこから派生した「実行できる仕様書」が揃えば、AIに渡す指示の精度は一気に上がります。

具体的な例を見てみましょう。パスワードリセット機能のテストコードです：

「有効なメールアドレスを入力してリセットボタンを押すと、確認メールが送信される」
「無効なメールアドレスの場合はエラーメッセージが表示される」
「メール内のリンクをクリックすると、新しいパスワード設定画面に移動する」
「新しいパスワードは8文字以上である必要がある」

これらの条件をテストコードとして先に書いておくと、AIも人間の開発者も同じゴールに向かって作業できます。しかも、実装が完了したら自動で検証できる。仕様書が自動実行される状態です。

従来の仕様書は「こうあるべき」という記述で終わりでしたが、テストコードは「実際にそうなっているか」まで検証してくれます。仕様書と品質検査が一体化した、新しい形のドキュメントなのです。

テスト駆動がAIの不確実性を吸収する3つの仕組み

仕組み1：ゴールが明確になる——完成基準が先にあれば、AIは何を満たせばOKか迷いません。

仕組み2：生成のブレを吸収する——AIの出力にはブレがあります。「完成基準」があれば、基準を満たしているという品質の下限が担保されます。

仕組み3：レビューの基準になる——「この基準を満たすためにこうなっている」という関係が、意図と実装の整合を確認する道しるべになります。

3つに共通するのは、完成基準があることで、AI・書き手・レビュアーの全員が同じ地図を持てること。地図があれば、迷子は減ります。

実際の開発現場での効果を数字で見てみましょう。ある金融系システムの開発チームでは、テスト駆動を導入してからAI生成コードの採用率が60%から85%に向上しました。理由は明確で、「基準を満たしているかどうか」がすぐに判定できるため、AI生成コードへの信頼度が格段に上がったからです。

また、別のECサイト開発プロジェクトでは、機能追加の際のデグレード（既存機能の不具合）が70%減少しました。新機能を追加する際も、既存のテストが「守るべき動作」を明示しているため、AIも人間も何を壊してはいけないかが分かります。

興味深いのは、テスト駆動を採用したチームでは「AI生成コードのレビュー時間」が平均40%短縮されていることです。レビュアーが「このコードは何をするものか」を推測する時間が不要になり、「基準を満たしているか」の確認に集中できるためです。

テスト駆動を「コスト」ではなく「仕様化投資」として見る

経営層からテストを書く時間は「コスト」に映りがちです。視点を変えてみてください。テストを書く時間の大半は、何をもって正解とするかを言語化する時間です。仕様を明確にする思考時間。

「テストを書くコスト」と「仕様を明確化するコスト」は、実は同じ作業の表裏。一度の投資で両方が手に入ります。この論理を、経営にテスト駆動の価値を説明するときに使えます。「テストを書く時間が増える」ではなく、「仕様を明確化する時間を、実行可能な形で確保している」と。

実際のROI（投資対効果）を計算してみましょう。ある企業の事例では：

• テスト作成時間：開発時間の15%増加
• デバッグ時間：60%削減
• 仕様変更時の影響範囲調査：70%削減
• AIコード生成の精度向上による開発速度：30%向上

結果として、プロジェクト全体では25%の時間短縮を実現しています。初期投資の15%に対して、25%のリターンを得ているわけです。

さらに注目すべきは「技術的負債の削減効果」です。明確な仕様がある状態で開発されたコードは、後から修正や機能追加をする際のコストが大幅に下がります。ある調査では、テスト駆動で開発されたシステムの保守コストは、従来手法の約半分というデータもあります。

CFOや経営企画の方に説明する際は、「開発効率化への投資」「技術的負債の予防投資」「AIとの協働効率向上への投資」という3つの側面から価値を伝えると効果的です。

非IT部門の管理職が、何を監督すればいいか

「テストの中身は専門的だから、自分には分からない」と感じている方に朗報です。テストコードを自分で読む必要は、一切ありません。ただし、テスト設計の方針を監督する役割は、非IT部門の管理職でも十分に担えます。

コードを読めなくても、以下の3つの観点は問えます。

• 「このサービスの中で、いちばん大事な機能は何ですか？ それはテストで守られていますか？」
• 「重要な機能ほど、テストが厚くなっていますか？」
• 「まだテストが足りていない部分は、どこですか？」

この3つを投げ続けられる管理職がいる組織は、AI時代にも強いです。技術を分かる必要はなく、「何を守るべきか」を問い続ける役割が、管理職には期待されています。

より具体的な監督のポイントを整理しましょう：

週次レビューで確認すべき3つの指標

1. コア機能のテストカバレッジ——売上に直結する機能、顧客満足度に影響する機能が優先的にテストされているか
2. AIコード採用率——テスト基準が明確な領域でのAI活用が進んでいるか
3. 仕様変更時の影響範囲——新機能追加時に既存機能を壊していないか、自動検証できているか

月次の戦略レビューで問うべき質問

• 「テスト駆動の導入によって、開発速度は向上していますか？」
• 「AIとの協働効率は改善されていますか？具体的な成果は？」
• 「顧客からの不具合報告は減っていますか？」
• 「開発チームの残業時間は削減されていますか？」

重要なのは、技術的な詳細を理解することではなく、ビジネス成果に繋がっているかを継続的に問うことです。テスト駆動開発は手段であり、目的は「より良いサービスをより効率的に作ること」なのですから。

まとめ — 古いやり方が、新しい時代の最適解になる

古典が最新になる、という話があります。テスト駆動開発は「古い」技法と思われがちでしたが、AIの波が押し寄せた今、奇妙な形で復権しつつあります。

新しい問題には新しい解が求められると思いがちですが、AI時代の品質担保に必要だったのは20年前からあった答えだった。逆説的なこの構造を、私は連載の中でいちばん皮肉に感じています。

テスト駆動を早々に捨てた組織ほど、AI駆動開発の時代に不利になっていく。古いから弱いのではなく、古いからこそ、多くの開発現場の試練に耐えた強度を持っている。その強度が、今こそ必要なのです。

なぜ「古典」が最強なのか——3つの理由

第一に、時間の検証を経ていること。20年間、世界中の開発現場で使われ続けてきた手法には、流行り廃りを超えた本質的な価値があります。

第二に、AIが学習したコードの多くがテスト駆動で書かれていること。AIにとって理解しやすく、質の高いコードのパターンを、私たちは既に手にしていました。

第三に、不確実性への対処法として普遍的であること。AI開発の不確実性も、20年前のアジャイル開発の不確実性も、本質は同じ。「変化に対応しながら品質を保つ」という課題に対する、時代を超えた解なのです。

今後、AIの能力はさらに向上し、コード生成の精度も上がっていくでしょう。しかし、「何をもって正解とするか」を定義する作業は、人間にしかできません。そして、その定義を実行可能な形で表現する技術が、テスト駆動開発なのです。

古いやり方を馬鹿にするのは簡単ですが、新しい時代にこそ古典の価値が見直される。歴史は繰り返しますが、技術の世界でも同じ現象が起きています。AI時代のテスト駆動開発は、まさにその象徴的な事例と言えるでしょう。

引用元

• GitHub Copilot productivity study
• Test-Driven Development in AI Era: Best Practices

少し前までの開発現場では、仕様書の地位は決して高くありませんでした。「仕様書より動くコード」という言葉に象徴されるように、重厚な仕様書は『遅い開発』の象徴のように扱われてきた時期もあります。

ところがAIの登場で風向きが変わりつつあります。理由はシンプルで、AIは仕様書を読んで動くからです。人間の開発者なら文脈を察して空白を埋めてくれましたが、AIは書かれていることに忠実で、書かれていないところは自分で解釈して埋める。仕様書の解像度が、そのままアウトプットの精度になるのです。

「察してもらう」発想の限界

日本の開発現場には、「察してもらう」文化が根強く残っています。「これくらいは分かるでしょう」という暗黙の合意が、チーム内の阿吽の呼吸として機能してきました。

問題はAIがこの「察する」を一切しないこと。書かれた指示を書かれたとおりに実行し、曖昧な部分は自分なりに解釈して埋めます。AI時代は「察してもらう」文化から「書き切る」文化へのシフトが避けられません。これはコミュニケーションの質を落とすことではなく、AIという新しいチームメンバーに合わせた言語を持つということです。

仕様駆動開発（Spec-Driven Development）とは何か

仕様駆動開発を一言で説明するなら、仕様書を開発の中心に据え、コードもテストもそこから派生させる考え方です。

従来の流れは「仕様書 → コード → テスト」でしたが、実態は「コードを書きながら仕様を確定させる」「テストは後付け」が多かった。仕様駆動開発では、仕様書が開発全体の起点になります。仕様書からAIへのプロンプトが生成され、仕様書からテストケースが導出され、仕様書の更新がコード変更のトリガーになる。

ウォーターフォールとの違いは、仕様書が固定ではないこと。プロジェクト進行とともに育てていきます。アジャイルの対立概念ではなく、アジャイルの精度を上げる補強策として機能します。

AI時代の要件定義書に書くべき4つの要素

要素1：機能要件と非機能要件の境界——機能要件は「何をするか」、非機能要件は「どう動くべきか」。「商品を検索できる」が機能要件なら、「3秒以内に結果を返す」「1万人同時アクセスに耐える」が非機能要件です。AIは機能要件に引っ張られる性質があるため、動き方・使い勝手の要件を明示することが重要です。

要素2：期待する振る舞いとエッジケース——「入力が空のとき」「最大値を超えたとき」「同時アクセスがあったとき」など、起こりうるケースを列挙。正常系の例しか与えないと、生成コードも正常系中心になります。

要素3：禁止事項・やらないことリスト——解像度を一気に上げる最強ポイント。「この画面では決済機能は扱わない」「このモジュールからはデータベースに直接アクセスしない」など。社内ルールの「やってはいけないことリスト」を開発でも作るイメージです。

要素4：テスト可能な受け入れ条件——「使いやすいUI」ではなく「3クリック以内で目的の画面に到達できる」のように、誰が見ても同じ判定ができる条件で書きます。「〜の状態で、〜をしたら、〜になる」という型が便利です。

要件定義書が「テストにもプロンプトにも効く」理由

4要素で書かれた要件定義書には、テストコードとAIプロンプトの共通の源泉になるという副次効果があります。

「〜の状態で、〜をしたら、〜になる」という形式は、そのまま自動チェックの仕組みに落とせる。同時に同じ要件定義書からAIプロンプトも生成できる。要件定義書は、品質四象限の象限①を固めるだけでなく、象限②（テスト）と象限③（プロンプト）に血液を送る動脈でもあるのです。

Galactic Brain の実務での運用例

参考までに、Galactic Brainでの実際の運用をお伝えします。要件定義書は、チームで共有し改訂履歴が見える形で管理しています（業界ではGitと呼ばれるツールで実現）。仕様書はAIに「前提知識」として読み込ませる仕組みに載せ、コード生成時に必ず参照される状態にしておきます。

このとき、仕様書に対しても「レビュー」を走らせます。コードだけでなく仕様書をレビューする文化を作ることで、解像度の低い部分が早期に発見されます。完璧な方法ではありませんが、従来の「コード中心・仕様書は参考資料」という運用よりも、手戻りが明らかに減りました。

明日から始められる3ステップ

ステップ1：既存の要件定義書を1本、4要素でチェックする——「機能/非機能の境界」「エッジケース」「やらないこと」「テスト可能な条件」が書かれているかチェック。最初の3つは抜けているはずです。

ステップ2：欠けている要素を1つだけ書き足してみる——全部を一気に整えようとしない。まず「やらないこと」だけ書き足してみる。これだけで仕様の輪郭がぐっと立ち上がります。

ステップ3：次の案件から、仕様書をAIに渡す前に4要素チェックを通す——新しい案件で仕様書ができたら、AIに渡す前に4要素のチェックをルーチン化する。これが組織としての仕様駆動開発の第一歩です。

まとめ — 導入前と導入後の風景

Before（導入前）：要件は「雰囲気」で共有される。AIに渡すプロンプトも個人の解釈で書かれる。コードは動くが「これで合っていますか？」と聞くと誰も答えられない。テストは通っているが何を保証しているかは曖昧。半年後、保守担当者が「この仕様、どこに書いてあります？」と困惑する。

After（導入後）：要件定義書に4つの要素がきちんと書かれている。AIはそれを読んで解像度の高いコードを出す。テストは要件定義書から派生しているので、何を保証しているかが明確。半年後に新メンバーが、要件定義書を読むだけでプロジェクトの全貌を再構築できる。

この違いは、時間が経つほど大きくなります。仕様駆動開発は、短期の効率化ではなく長期の知識資産を作る投資です。

意外に思われるかもしれませんが、AIは指示どおりに動きます。問題は「あなたが書いた指示」と「あなたが本当に求めているもの」のあいだにズレがあったときに起きます。

人間の同僚なら「これ、こういう意図ですよね？」と聞き返してくれる。でもAIは基本的に聞き返しません。曖昧な部分はAI自身が自分なりに解釈して、勝手に埋めていきます。こうして「あなたが頼んでいないコード」が、さも頼まれたかのように生成されるのです。

「雰囲気プロンプト」の3つの症状

私が支援現場でよく見かけるのが、「雰囲気プロンプト」と呼びたくなる要件の書き方です。

• 症状1：意図だけ書いて、細部を省略する——「ユーザー登録機能を作って」とだけ書き、入力チェックやエラー処理を省略する
• 症状2：例示だけで済ませて、境界条件を書かない——スクリーンショットだけ貼って、画面外で起きることを書かない
• 症状3：「いい感じに」「よろしく」で括ってしまう——人間同士なら文脈が補うが、AIはこの「いい感じ」を想像で埋める

曖昧さが生むコストは、なぜ経営から見えないのか

曖昧さが生むコストが深刻なのは、経営から見えにくいからです。コードは動いている、テストも通っている、リリースもされた——ここまではポジティブに見えます。

実際のケーススタディを見ると、曖昧な要件定義によって手戻り工数が40%増、開発期間が25%延長するプロジェクトも珍しくありません。月1000万円の開発費なら、それだけで250万円の超過コストです。さらに市場投入の遅れによる機会損失を考慮すれば、影響額は数千万円規模に膨らむことも。

しかし「仕様の解釈違いで、追加改修が必要になりました」「本番で想定外の挙動が出ました」「保守性が低いのでリファクタリングを」という報告が上がってきたとき、これらはすべて最初の要件定義の曖昧さから派生した一連のコストですが、経営報告では別々の項目として計上されます。

原因と結果が切り離され、経営が「なぜ手戻りが多いのか」と問うても、現場は「個別対応」としか説明できない。曖昧さが生むコストは、見えないまま積み上がっていきます。

要件定義の「解像度」という考え方

私がよく使う言葉が、「要件定義の解像度」です。写真にたとえると分かりやすい。同じ被写体を撮っても、ピントが合った写真とぼやけた写真では、見えるものがまるで違います。

解像度の高い要件定義には、意図に加えて以下のものが含まれます。

• 期待する振る舞い（正常系）
• 期待しない振る舞い（エッジケース）
• やらないこと（スコープ外）
• テスト可能な受け入れ条件

ポイントは、「何を作るか」だけでなく、「何を作らないか」まで書くこと。AIは書かれていない領域を自分で解釈して埋める性質があるため、「作らない」と明示しない限り、作られてしまう可能性があるのです。

すぐに実践できるアプローチとして、Given-When-Then形式（BDDの考え方）で要件を記述してみてください。「特定の状況で（Given）、何かが起きたとき（When）、期待する結果（Then）」という形で書くだけでも、曖昧さは大幅に削減されます。

解像度が低いまま走ると何が起きるか

解像度の低い要件定義でプロジェクトを走らせると、品質は段階的に劣化していきます。

• 初期：リリース直後は動くが、想定外の使い方で崩れる。問い合わせが増え始める
• 中期：「これってこういう仕様でしたっけ？」という会話が増え、解釈がじわじわぶれる
• 後期：プロジェクトから数ヶ月・1年経つと誰も元の意図を覚えておらず、塩漬け状態になる

AI駆動開発ではこのサイクルが従来より速く回ります。速く作れるぶん、速く劣化もする——短期的には効率よく見えて、中長期では予想以上のコスト増として跳ね返ってきます。

まとめ — 5分でできる要件定義の点検実験

記事を閉じたあと、5分でできる小さな実験を提案します。

あなたの会社の要件定義書を1本、手元に開いてみてください。目で追いながらこう問うてみる——「この要件定義書をAIに渡したら、AIはどれくらいの確信を持ってコードを書けるだろうか」。

書いた人の頭の中でしか完結していない部分が、きっと見つかるはずです。その「書かれていない部分」こそが、AIに勝手に埋められてしまう空白にほかなりません。次回はこの空白を埋める具体的な方法論に入ります。

AI駆動開発を導入したチームの経営報告を眺めると、数字の上では良いことが並びます。開発スピードが上がった、コストが下がった、新機能のリリース頻度が増えた。ところが、現場の実感はどこかズレている。

劣化は派手な事故として現れません。困るのは、静かに、じわじわと、再現性が失われていく現象のほう。気づいたときには、取り戻すのに時間がかかる状態になっている——この「見えにくさ」こそが、AI時代の品質劣化の本質です。

パターン1：仕様が曖昧なまま動いてしまうコード

「これ、仕様どおりに動いていますか？」と聞くと「動いています」と返ってくる。続けて「仕様って、どこに書いてありますか？」と聞くと、空気が少し変わる——これが最近よく見る光景です。

プロンプトに書いた内容が実質的な仕様になっている。コードは動いているが、仕様は書いた人の頭の中にしかない。半年後「ここの動き、こうじゃないと困るんですけど」と言われて、初めて仕様が曖昧だったことが露呈します。

パターン2：ライブラリ選定が場当たり的になる

ここで言う「ライブラリ」とは、他の人が作った便利な道具セットのこと。ビジネスで例えるなら、契約書や稟議書のテンプレートに近いイメージです。使うテンプレートがバラバラだと、組織全体の文書が統一感を失うのと同じことが、コードの世界でも起きます。

AIはそのつど最適っぽいものを提案するだけ。統一する意思は人間の側が持つべきもの。「任せている」感覚でAIを使うと、道具選びが属人的どころか「都度的」になり、コードベース全体の筋が通らなくなります。

パターン3：テストの「形骸化」が加速する

AIに書かせたコードにAIがテストも書くフロー。効率的に見えますが、生成されたコードに対して生成されたテストは「通るように」書かれがちです。

テストの独立性が崩れ、コードの振る舞いを外から監視するはずのテストが、コードと同じ出自の目で書かれている——これは検証というより自己正当化に近い状態。カバレッジは上がり、見かけのテスト本数も増えます。でも「このテストが何を保証しているんですか？」と聞くと、答えが出てこない。

パターン4：ドキュメントとコードの乖離

AI駆動開発では、コードの生成速度が上がります。その結果、ドキュメントの更新が追いつかなくなる。1週間前に書いたドキュメントがもう古い。2週間前の設計図と今のコードが合っていない。

AIはコードを書いてくれますが、ドキュメントを維持する「意志」を持たせる仕組みが組織に整っていないのです。結果、新しく入ったメンバーが参照できる資料がなくなり、暗黙知が増え、属人化が進みます。

パターン5：障害対応の再現性が落ちる

障害が起きて調査を頼むと時間がかかる。AIに聞いても同じ質問への答えが毎回少しずつ違う。できあがったシステムの中で何が起きているかを、誰も全貌で把握していない——これがAI時代特有の「再現性の喪失」です。

障害が起きてから復旧するまでの時間（業界ではMTTR＝平均復旧時間と呼びます）が延びる。再現性が確保できないから、「もう一度同じ問題が起きないように」の学びも蓄積しない。経営に最も痛く効く症状です。

5つのパターンと品質四象限の対応関係

バラバラに見える5つのパターンは、共通の根を持ちます。第1話で提示した「品質四象限」に戻って対応関係を整理すると：

• パターン1（仕様曖昧） → 象限①要件定義の弱さ
• パターン2（ライブラリ場当たり） → 象限③プロンプト＋象限④工程設計
• パターン3（テスト形骸化） → 象限②テスト駆動＋象限③プロンプト
• パターン4（ドキュメント乖離） → 象限①要件定義＋象限④工程設計
• パターン5（再現性喪失） → 象限④工程設計の全体

裏を返せば、四象限を意識的に設計し直せば、これらの症状は確実に改善していきます。

まとめ — 5つのパターンで自己診断する

記事を閉じる前に、5つのパターンを使った簡単な自己診断を試してみてください。

• 「強く心当たりがある」が 1つ → 初期段階。今のうちに手を打てば軽く済みます
• 「強く心当たりがある」が 2〜3つ → じわじわ劣化が進んでいるサイン
• 「強く心当たりがある」が 4つ以上 → 品質四象限の再設計が急務かもしれません

どの段階にあっても、ここから処方箋を一緒に見ていきます。次回以降、4つの象限をひとつずつ掘り下げます。

AIに書かせたコードが、動いている。でも、何かが引っかかる——そんな感覚を、あなたは最近抱いていないでしょうか。

速く作れるようになった。開発コストも下がった。それなのに、どこか腑に落ちない。障害対応が重くなった気がする。レビューで拾えるものが減った気がする。気のせいでしょうか。

気のせいではない、というのが私の結論です。私たちが長年使ってきた「品質担保」という考え方の前提そのものが、AI駆動開発によっていくつも揺らいでいる。そう感じ始めたのが、この連載を書き始めた動機です。

退いた者が、もう一度呼ばれるとき

スタートレックの主人公ジャン=リュック・ピカードは、かつて宇宙艦の艦長として名を馳せた人物。物語が始まる時点では引退してワイナリーで静かに暮らしています。ところがある出来事をきっかけに、彼はもう一度、世界に呼び戻されていく。

「古い人がもう一度呼ばれる」という構造。彼が呼ばれたのは、若い頃の栄光を再現するためではありません。時代が新しい難題に直面したとき、問いを立て直せる人が必要になったからです。

AI駆動開発の現場も同じ構造を持っています。「何を信じていいのか」「どこまで任せていいのか」——こうした問いに向き合うには、古い知の側から問い直す作業が要ります。

揺らいだ3つの前提

前提1：コードは「書く」ものだった——AI時代には、コードは「書かれる」よりも「生成される」ものになります。意図はプロンプトに宿り、コードは生成の結果として現れる。書き手と成果物の間に、一段のレイヤーが挟まったのです。

前提2：レビューは「読めばわかる」ものだった——生成されたコードはたいてい動きます。細かいミスも少ない。でも「なぜこの実装にしたのか」「なぜこのライブラリを選んだのか」という判断の根拠が見えにくくなります。

前提3：テストは「書けば足りる」ものだった——AIが生成したコードをAIにテストさせると、そのテストは「通るように」設計されがちです。テストの独立性が、AIの導入によって危うくなります。

答えは「品質四象限」にある

この3つの揺らぎに、どう向き合えばいいか。私が到達した答えが、本連載の背骨となる「品質四象限」というフレームワークです。

• 象限①：要件定義の精緻化（何を作るかの解像度）
• 象限②：テスト駆動での設計（何が正しいかの定義）
• 象限③：プロンプトによるAIコントロール（AIをどう動かすか）
• 象限④：工程設計（いつ・どう進めるか）

4つの象限は独立した項目ではなく、お互いを支え合いながらAI時代の品質を四方から守る仕組みです。どこか一つが欠けると、残り3つも連動して弱くなります。

この連載で扱わないもの

本連載では、以下を意図的に扱わないと最初に宣言しておきます。専門家としての線引きを明示するためです。

• ROI計算・投資対効果論
• 契約・法務・知財論
• 採用・HR論

これらは別軸で論じるべき重要テーマですが、1本の連載ですべてを語るとどの主張もぼやけます。今回は品質担保という柱に集中します。

もし、この記事を読みながら「うちにも思い当たるふしがある」と感じた瞬間があったなら。それはおそらく、品質四象限のどこかがすでに揺らいでいるサインです。どこが揺らいでいるのか——ここから14回かけて、一緒に言葉にしていきましょう。