AIと「仕様」を作るときにやってはいけないこと／やるべきこと【実践編】

AIに「仕様書を書いて」と頼んだことがある人は多いと思う。
そして多くの場合、こう感じたはずだ。

それっぽいけど、実装に使えない。
現場の事情がまったく反映されていない。
なぜこの設計なのか分からない。

結論から言うと、これはAIの性能不足ではない。
使い方を間違えているだけだ。

やってはいけないこと①

AIに「最初から正解の仕様」を書かせる

これは一番多い失敗。

「◯◯の仕様書を作ってください」と丸投げすると、
AIはもっともらしく、一般論的で、破綻しやすい仕様を書いてくる。

理由は単純で、AIは現場を知らないからだ。

過去にどこで詰まったか。
どこが壊れやすかったか。
どこをユーザーに触らせると事故が起きるか。

こうした“痛み”は、人間の側にしかない。

やってはいけないこと②

AIを「設計者」にしてしまう

AIは設計者にはなれない。

設計とは、
トレードオフを選び、
何かを捨て、
その結果に責任を持つことだからだ。

AIは案を出すことはできる。
整理もできる。
話を広げることもできる。

でも、「どれを選ぶか」は決められない。

ここを勘違いすると、
誰も責任を取らない仕様が出来上がる。

やってはいけないこと③

完成形から話し始める

意外と多いのがこのパターン。

「最終的に、こういうシステムを作りたい」
から仕様作りを始めるケースだ。

一見、合理的に見えるが、落とし穴がある。

途中の思考プロセスが抜け落ちる。
なぜその選択をしたのかが残らない。
あとから変更すると、全体が崩れる。

AIは完成形を渡されると、
そこに辻褄を合わせるように仕様を埋めにいく。

結果として、
理由のない設計、修正に弱い構成、引き継げない仕様になりやすい。

ここからが本題だ。

やるべきこと①

仕様の前に「体験」を話す

AIと仕様を作るとき、
最初に渡すべきなのは要件定義ではない。

過去の体験や違和感だ。

たとえば、

昔、複数の処理を並列で走らせたことがある。
そのとき、どこまで進んでいるか分からなくなった。
再実行したら二重処理が起きた。

こうした話は、AIにとって設計の素材になる。

完成形ではなく、
「なぜ困ったのか」を渡すのがポイントだ。

やるべきこと②

AIには「整理役」をやらせる

この段階でAIに期待する役割はひとつだけ。

「それ、構造にするとこうですよね？」
と言わせること。

処理を状態に分ける。
流れとして整理する。
名前を付ける。

ここでAIは非常に優秀だ。

ただし、決断はさせない。

やるべきこと③

判断は人間が全部やる（ここが一番難しい）

これは正論だが、実際には難しい。

なぜなら、AIの提案は
たいてい「悪くない」からだ。

それっぽい。
一応、筋は通っている。
すぐ使えそうに見える。

だからこそ、境界が曖昧になる。

ひとつの判断基準はこれだ。

「この設計、失敗したら自分は説明できるか？」

説明できないなら、それはAIに決めさせている。
説明できるなら、それは自分の判断だ。

AIの案を、
採用するのか、捨てるのかを即決する。

ここを曖昧にしないことが重要になる。

やるべきこと④

仕様は“一気に完成させない”

良い仕様は、一度で完成しない。

少し話す。
整理させる。
違和感を指摘する。
もう一度、構造を見る。

この往復の中で、
仕様が立ち上がってくる。

AIとの対話ログは、
そのまま設計の履歴になる。

人間とAIの役割分担（文章で覚える）

判断するのは人間。
責任を持つのも人間。

AIに任せていいのは、
頭の中にある考えを整理し、言語化し、広げることまで。

考えるのは人間。
可視化するのがAI。

この線を越えさせない。

なぜこのやり方がAI時代に強いのか

このやり方で作った仕様は、

修正に強く、
属人化しにくく、
別の案件にも転用でき、
「なぜそうなったか」がきちんと残る。

完成した仕様書よりも、
作り方そのものが資産になる。

まとめ

AIと仕様を作るとは、
AIに答えを出させることではない。

考えている自分の頭を、
AIを使って可視化し、
何度も眺めて、修正することだ。

仕様は「書くもの」ではなく、
対話の中で育てるもの。

この前提を持つだけで、
AIは一気に“使える相棒”になる。

補足

このやり方は、
業務フロー設計、AIエージェント設計、業務自動化全般にそのまま使える。

「AIに何をさせるか」よりも、
**「どこで人間が決めるか」**を先に決める。

それだけで、失敗率は大きく下がる。