仕様を書く人になる — AIに実装させる前に決めるべきことと、その粒度

AIに「経費CSVを取り込んで月次集計を出すツール」と投げると、30秒で動くコードが返ってきます。実行するとそれらしい結果が出ます。ここで問題が始まります。文字コードは何を想定しているのか、空のCSVなら何をするのか、金額が桁をあふれたら止まるのか続くのか。全部コードを読まないと分からない。読み終える頃には、仕様書を書いたほうが早かったと気づきます。

手戻りの原因はAIの実装能力ではなく、人間が渡した仕様が一意ではないということです。AIは聞き返さずに前提を自分で置いて完成させる。その前提はコードの中にしか残らない。仕様を先に書くことと、コードをレビューしながら仕様を決めることは、思考量は変わらない。違うのは成果物が残るかです。仕様には粒度がある。L0は目的だけ（捨てるスクリプト向け）、L1は入出力の形まで（正常系だけ通る）、L2は境界値と異常系まで（実運用向け）、L3は却下案の理由まで（セッション跨ぎ向け）。どの粒度で止めるかは、誰が使うか、何回使うか、止まったら困るか、で判断します。

AI鬼が注目するのは、仕様を書くスキルが「AIに仕事を投げる側の必須技能」になったという現実です。AIはもっともらしい前提を自分で置く生き物です。その前提が業務側の常識と食い違っていても、一般論として筋が通っていればコードにします。別セッションでAIが勝手に「エラー行はスキップは危険だから全体中断に改善しました」と直してくるのは、仕様に理由を書いていないからです。「月末に1行のミスで全体が止まると運用が回らない」と書いておくことだけが防波堤になります。