最初に
最近、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 を信じるか」ではなく、「信じていいだけの仕組みを何作るか」だ。