9
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

仕様をわかったつもりでAIに仕事をさせるな

9
Last updated at Posted at 2026-04-15

AIにコードを書かせるようになって、ふと思うことがあります。
本当に「何を作りたいか」を言葉にできているだろうか。
曖昧なままプロンプトを打ち込んでいないだろうか。

そもそも自分は仕様を理解しているのか?

AIコーディングエージェントを導入したチームから、よくこんな声を聞きます。
「AIに任せたのに、思った通りのものが出てこない」
「結局人間が書き直している」
「テスト環境がないから、動くかどうかは後で確認するしかない」
私はこの手の話を聞くたびに、少しだけ背筋が寒くなります。
なぜならそれは、AIの問題ではなく、人間側の仕様理解が曖昧なまま走り出してしまっているサインだからです。

「Spec Driven」なのにSpecがない、という矛盾

例えばですが、仕様駆動開発(SDD、Spec Driven Development)を掲げているのに、(仕様はあります!だけど)仕様書がふわっとしている。
完成の定義(Definition of Done、DoDとかDoneの定義とか言われます)がないまま、AIにコードを書かせる。
受入条件(AC:Acceptance Criteria)を書いているけど、テストできる状態まで共通認識ができていない。

それはAIへの盲信や責任転嫁に近いのではないでしょうか。
完成図のないパズルは、どれだけ手が速くても完成しません。
AIがどれだけ速くタイピングできても、ゴールが描けていなければ走り出す方向すら決まらないのです。

あなたのAIは「タイピングの速いジュニア」にすぎない

上記に少しでも該当するなと感じた方、
AIコーディングエージェントは、魔法の杖ではありません。
「ものすごく速くタイピングできるけれど、ドメイン知識も業務の常識も持っていないジュニアエンジニア」くらいに思っておくとちょうどいいです。
そんなジュニアに、曖昧な要件をふわっと投げたらどうなるか。
もっともらしいけれど実は動かないコードが、平然と出てきます。
そして完成基準(ACやDoD)やテスト環境がなければ、その嘘に誰も気づけません。

「あとでテストする」はなぜ危険か

「とりあえずコードはできた、テストは後で」
このスタンスは、AI時代において最悪のアンチパターンだと私は感じています。
AIがなかった時代でも、動かないコードを積み上げた先に待っていたのは地獄の結合テストでした。
AI時代はその速度が上がるだけで、本質は変わりません(むしろ負債の生成速度が桁違いに上がります)。
即時フィードバックのない環境でAIに書かせ続けるのは、ブレーキの壊れた車にターボエンジンを積むような話ですよね。
速ければ速いほど、元の位置に戻ってくるだけでも手間とリスクを背負います。

AIがなかった時代に、私たちは何をしていたか

少し立ち止まって思い返してみてください。
AIがなかった時代、私たちは要件を聞き、仕様を言語化し、受入条件を決め、テストを設計していました。
そのプロセスは面倒で、地味で、時間のかかるものでした。
でも、それがあったからこそ、プロジェクトは(なんとか)前に進んでいたのです。
AIが来たからといって、このプロセスが不要になったわけではありません。

むしろ逆で、AIの生成速度に負けないだけの「判断の質」を、人間が上流で担保しないといけなくなった。
そう捉え直したほうがいい気がしています。

こう考えると、AIの使い方が変わる

仕様が言語化できないなら、コードは一行も書かせない。
これくらいの感覚でちょうどいい、と私は思っています。

このような境界を溶かすために、AIをプログラマーではなく、ビジネスと開発の翻訳家として活用してみることができると思います。
コードを書かせる前に、まずAIに仕様を整理してもらう。
「この機能で考慮すべきケースをリストアップして」
「この要件に対する受入テスト項目をマークダウンで出して」

そんな使い方から始めると、人間の頭の中の整理が一気に進みます。
繰り返しになりますが、AIにはコンテキストや情報を与えないとドメイン知識がありません。
Webで拾ってきた知識だけで意思決定や協力を得ないように意識しましょう。
(機密情報の扱いとオプトアウトの設定は念入りに確認することを忘れずに)

テストできない、を言い訳にしない

レガシー環境でテストできないというのも、よく聞く話です。
でも、本番環境に繋がないと何も確認できないというのは、アーキテクチャ側の課題として捉え直すべきなのではないでしょうか。
境界の手前までをモックやスタブを用意したりして、そこまではローカルで自動テストが回るようにしておく。
AI時代の開発では、この「境界の引き直し」が静かに、でも決定的に重要になってきている気がします。変更箇所の予期せぬ変更に気づくトリガーの仕込み方と、コーディングしてもらう影響範囲を明確に意識する・設計通りに分離させるスキルはより重要になりました。
このレベルの確認ができないものは、着手せずに別の活動に時間を使う方が良いと個人的には思います。

おわりに

結局のところ、AIは人間の思考を「拡張するツール」であって、「代替するツール」ではないのだと思います。
0に何を掛けても0、という当たり前の話です(でも、ついつい忘れがちなんですよね)。

何を作るべきかを見極める力、そして正しく動いていることを担保する力。
この二つは、AIがなかった時代にも大切でしたし、AIが来てさらに大切になりましたし、高速に流せるようになりました。

仕様をわかったつもりにならず、人間とAIで一緒に言語化するところから始めていきましょう。

9
5
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
9
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?