最初に

最近、Codex と Claude Code で開発をかなり続けています。
最初はほぼ Vibe Coding で進めて、機能が増えてきたあたりから、徐々に Spec Coding 寄りになっていきました。

この2つの進め方を続けていて、ふと思ったのは、かなり古いフレームワークが思いのほかよく当てはまる、ということでした。

それが、性善説と性悪説です。

孟子と荀子、そんな話のようですが、AI 開発の文脈では意外に実用的です。
今回は、それを開発の流れに沿って短くまとめます。

先に結論

結論から書くと、AI は性善でも性悪でもない。「似てる」だけ です。

性善説（Vibe Coding）は前半で有効、性悪説（Spec Coding）は後半で有効
いずれか一本にする必要はなく、「段階で切り替える」のが正解
信頼を担保するのは「信仰」ではなく「仕組み」（仕様・テスト・レビュー）

「Vibe Coding は速い、でも後半は結局何を信じていいかわからない」と感じている人には、かなり刺さる内容です。

1. まず、性善説と性悪説とは何か

伝統的な性善説・性悪説は、人の本性についての議論です。
性善説は「人はもとから良い」、性悪説は「人はもとから悪い」と言います。

でもこの議論で実際に決まっているのは、「善悪」そのものではありません。
決まっているのは**「仕組み」**です。

性善と信じれば、人に委ねても大丈夫だから、仕組みは軽くできます。
性悪と信じれば、ルールとチェックと監視を作る必要が生まれます。

つまり性善・性悪の議論は、どのくらい信頼するか、そしてどんなチェックを作るかの議論だったのだと思います。

このフレームワークは、AI 開発にもかなりそのまま当てはまります。

2. AI の本質は「似てる」だ

Codex や Claude Code を使うとき、本質的な問いはこれです。

この AI、信頼できるのか？

答えは、大きく2つに分かれます。

「AI は性善だ」というなら、Vibe Coding です。
意図を渡して、あとは自律的に動かす。

「AI は性悪だ」というなら、Spec Coding です。
要求・制約・受入基準を明文化して、検証させてから受け取る。

ただ正直、AI の本性は善でも悪でもありません。
AI は「良い開発者の書き方を似せている」だけです。

だから「それっぽく正しそう」と「本当に正しい」は、別の話になります。
ここが人の性善・性悪と根本的に違うところで、AI 版の性善・性悪議論は、倫理の話ではなく「検証のコストをどこに置くか」の話になります。

3. 性善説（Vibe Coding）で得られるもの

性善説で回すと、本当に速いです。
その速度は本物です。

細かな仕様書が不要なので、始めるコストが小さい
ラフな形、スパイク、プロトタイプが圧倒的に速い
破棄しても安いので、試せる

この段階で Spec Coding に入ると、むしろ無駄です。
前半は性善説で回していい。むしろそうすべきです。

4. 性善説で回し続けていると、どこで壊れるか

ただ、性善説を続けていくと、後半で別の種類のしんどさが出てきます。

「それっぽい」のに、挙動が微妙に違う
機能が増えるほど、暗黙の前提同士がぶつかる
差分が肥大して、人間がレビューしきれなくなる
AI が根本原因に届かず、似た修正を繰り返す

これらに共通するのは1つです。
信頼が無制限で、検証がゼロなこと。

新人を丸ごと信じて全部任せているのと同じです。
相手が良ければ最高ですが、ズレたときに、どこでズレたのか見えなくなります。

5. 性悪説（Spec Coding）が効く理由

Spec Coding は、本質的には性悪説のアプローチです。
「間違えたと仮定して、間違えが必ず見える仕組みを作る」

何をすべきか、何をすべきでないかを明文化する（仕様）
テストを最初から存在させる
小さく出して、検証させてから受け取る
人間は「なぜその実装なのか」を見る

これは、人に対してルールとチェックを置く性悪説型のマネジメントと同じ構造です。

生産性が高いほど、この構造は効いてきます。
コアな部分ほど、最初から性悪説で回す方が強いと思います。

6. でも性悪説だけで回すと、これもしんどい

一方で、性悪説一本足にも問題があります。

仕様の書下しコストが高く、変更に追いつかなくなる
信じていないと、新人の過保護な管理と同じになって速度が落ちる
仕様自体が間違っていると、AI はそれを忠実に間違った形で実行してくれる

特に最後の項目が、AI 開発の特徴です。
人がズレるときは、まだズレの度合いにばらつきがありますが、AI は「仕様に忠実なほど、間違ったものがきれいに完成します」。

性悪説をデフォルトにすると、「遅くて、なおかつ脆い開発」になりやすい。
仕様書は更新し続けなければ二重管理になり、これも後半で確実に効いてきます。

7. 答えは「使い分けて、切り替える」こと

なので答えは、性善か性悪かの二者択一ではありません。
段階で切り替えることです。

新規 / プロトタイプ → 性善説で回す
本番 / コア / チーム開発 → 性悪説で回す
変更の影響範囲が大きいほど、検証を重くする

言い換えれば、Trust, but verify です。

新人の扱いも同じです。
仕事を任せる（trust）一方で、レビューと CI というチェックを作る（verify）。
信頼できているのは、その人個人ではなく、その仕組みです。

AI への信頼も全く同じで、実行は任せ、信頼は仕組みが担います。
仕様、テスト、CI、レビュー。
「信じる」のは人間、「担保する」のは仕組み、と分けるのが、後半まで回る形だと感じています。

8. 今すぐやれること

実行前に「何をすべきか」「何をすべきでないか」を書く。1行でも良い
影響範囲が広い変更は、テストを受入条件にする
PR は小さく、一言で説明できる粒度にする
レビューは分担する。規約と命名は AI、設計と前提は人間
壊れたとき、最初に疑うのは「仕様」であって AI ではない

まとめ

AI は性善でも性悪ではなく、「似てる」だけ
性善説（Vibe Coding）＝前半の速度
性悪説（Spec Coding）＝後半の安全
二者択一ではなく、段階で切り替える
信頼を担保するのは、仕組みである

Vibe Coding は本当に速いです。
でも、後半で差が出るのは、AI を信じるかどうかではありません。

AI 時代の問題は「AI を信じるか」ではなく、「信じていいだけの仕組みを何作るか」だ。