この記事は、前編「IT界でもbeat itを奏でるマイケルジャクソン🕺」の続きです。
まだの方はぜひ前編からどうぞ。
はじめに
前編では、映画『Michael/マイケル』をきっかけに知ったソフトウェア工学界の巨匠、
マイケル・A・ジャクソン先生の人物と「3つの奇跡」を紹介しました。
そして先生の思想が一番詰まった論文「The World and the Machine」(ICSE '95)のコアメッセージがこれでした。
要求 — すなわち問題 — は世界の側にある。機械は我々が構築する解決である。
正直、最初は「30年前の論文かぁ、どうせ今読んだら古いんやろな〜」と思っていました(先生ごめんなさい)。
でも読み込んでいくと真逆でした。
むしろ AIがコードを書いてくれる今こそ、この論文の価値は上がっている と感じたんです。
後編では、論文の中身をAI時代に引きつけて再解釈していきます。
お付き合いください。
この記事でわかること
- 「世界と機械」の視点で見ると、AIコーディングで何が変わって何が変わらないのか
- プロンプトの失敗を30年前に説明していた「逆噴射の悲劇」
- vibe codingの誘惑を30年前に言い当てていた「4つの否認」
- プロンプトを書く前に読みたい「von Neumannの原則」
まず結論(要点だけ)
- AIが安くしたのは「機械」を作るコスト。「世界」を理解するコストは1円も安くなっていない
- プロンプトの事故は、たいてい機械側のバグではなく 世界についての仮定 のバグ
- だからAI時代のエンジニア・開発チームの価値は、世界を正しく記述する力に寄っていく
「機械」は安くなった。「世界」は安くなっていない
マイケル先生の整理では、ソフトウェア開発には常に2つの関心事があります。
| 世界(The World) | 機械(The Machine) | |
|---|---|---|
| 何か | 問題が存在する場所。顧客・業務・物理現象 | 僕らが作る解決。コンピュータ+ソフトウェア |
| 関心事 | 要求(世界側で達成されるべき条件) | プログラム(機械の振る舞いの記述) |
| 2026年の状況 | 何も変わっていない | AIが書いてくれるようになった |
この30年でプログラミング言語もフレームワークも激変して、ついにAIがコードを書くようになりました。
でもよく見ると、進化したのは全部 機械側 なんですよね。
一方、世界側——顧客が本当は何に困っているのか、業務がどう回っているのか、物理的に何が起こりうるのか——を理解するコストは、まったく安くなっていません。
Claude CodeやCopilotをどれだけ課金しても、あなたの会社の承認フローの闇 は1ミリも解明されません。
つまりAI時代に希少になるのは、機械の記述(コード)ではなく 世界に対する記述 です。
プロンプトの事故は「逆噴射の悲劇」の再生産
前編で紹介した逆噴射の話を、一度AIの目線で見てみます。
要求は「滑走路に接地している時だけ逆噴射を許可する」。
でも機械は「接地」を直接知れないので、開発者は世界についての仮定——車輪が回っていればパルスが出る、車輪が回っていれば滑走路上にいる——を置いて、「パルスが出ていれば逆噴射OK」という仕様に翻訳しました。
証明までして、完璧でした。
そして大雨の日、ハイドロプレーニングで「接地しているのに車輪が回らない」が起こり、飛行機は滑走路をオーバーランします。
機械は仕様通り完璧に動いた。何ができてなかったのかのは世界についての理解、仮定でした。
これ、AIコーディングの事故と完全に同じ構造だと思います。
| 逆噴射の悲劇 | AIコーディングの事故 |
|---|---|
| 要求(世界側で実現したいこと) | 本当にやりたかったこと |
| 世界についての仮定 | プロンプトに書いた(または書き忘れた)前提 |
| 仕様 | プロンプト |
| 機械は仕様通り完璧に動いた | AIはプロンプト通り完璧に実装した |
| ハイドロプレーニング | 「え、そんなケースあるの?」 |
AIは、プロンプトに書かれた前提が間違っていても、その間違いを高速かつ完璧に実装 してくれます。
人間がコードを書いていた時代は、実装しながら「ん?この仕様、雨の日どうなるんや?」と気づく余地がありました。
実装へのコストが低い時代、その「気づきの余白」は消えていると言えるのではないか。
30年前は数年に一度の教訓だった逆噴射の悲劇を、僕らは毎日小さく再生産できるようになったわけです。
vibe codingの誘惑は30年前に予言されていた
前編の最後で触れた 4つの否認 の中身がこちらです。
エンジニア・開発チームが「世界」から目を背けて「機械」に閉じこもるときの、言い訳のパターン集です。
| 否認 | ざっくり言うと |
|---|---|
| 既知による否認 | 「この手の問題はもう分かりきってるから、いまさら分析不要っしょ」 |
| ハッキングによる否認 | コンピュータいじりが楽しすぎて、地味な問題分析に時間を使いたくない |
| 抽象化による否認 | 数学的にきれいな問題だけ相手にして、泥臭い現実世界を見ない |
| 曖昧さによる否認 | 機械の記述を書いただけなのに「現実世界を分析した」ことにしてしまう |
この中で、AI時代に一番効いてくるのが「ハッキングによる否認」だと思っています。
コンピュータは強烈に面白い。手元でゴーレムを生み出し、その精巧な動作を眺める快楽を前にして、誰が問題記述やドメイン分析なんかに時間を使いたいだろうか?
と書かれていました。
プロンプトを投げれば動くものがすぐ出てくる。楽しい。
もう一回投げる。もっと楽しい。
要件の整理?ドメインの理解?あとあと!
——この誘惑、1995年の時点で「ハッキングによる否認」として言語化されていました。
AIはコードを書くコストを下げたと同時に、然るべきでない場面で発揮してしまう楽しさを否定することを減らしてしまった んですよね。
念のため言うと、僕はvibe coding否定派ではないです。
プロトタイピングや自分が持つスキルをブーストさせることにおいては最強の武器やと思います。
ただ「プロダクト作成の中で技術を追求すること」と「世界の問題を解くこと」は別物である、という30年前の警告は、頭の片隅に置いておきたいなと。
プロンプトを書く前に:von Neumannの原則
論文の後半では、世界をちゃんと記述するための原則がいくつか紹介されています。
筆頭が von Neumannの原則。
フォン・ノイマンの言葉として、こんな趣旨が引かれています。
概念が明確でないところで厳密な手法を使っても意味がない
そして、より口語的なバージョンがこちら。
自分が何の話をしているか分かっていないうちに、厳密になっても仕方がない。(拙訳)
これ、プロンプトの原則そのもの だと思います。
そもそも「何を作りたいか」「用語が何を指すか」「やってほしいことを言語化できているか」が自分の中で曖昧なら、
出てくるのは「厳密に間違ったコード」です。
具体例を出すとこうです。
× 「いい感じの会員管理システムを作って」
→ 「会員」の意味が曖昧なまま、AIは厳密に、間違ったものを作る
○ 「会員 = 入会済みで、退会も除名もされていない人。その一覧と検索を作って」
→ 用語の定義が、そのまま仕様の土台になる
ジャクソン先生は、世界の記述では用語ひとつひとつに「それを世界の中で認識するためのルール(認識規則)」を与えよ、と言います。
「会員とは何か」「注文とは何か」を曖昧なままにするな、と。
ちなみに論文では、図書館システムで「会員(member)」を安易に基本用語に選ぶこと自体が誤りで、「入会する」「退会する」といった 出来事 から定義せよ、とまで踏み込んでいます。
徹底してる。
AIとの対話で一番大事なのは、小手先のプロンプトのテクニックより「自分の頭の中の概念を明確にすること」だと思います。
30年前に提唱されていることが、現代にも通じると思います。
まとめ
- AIが安くしたのは機械のコスト。世界を理解するコストはそのまま。なので相対的に 世界側の理解の価値が上がる
- プロンプトの事故は逆噴射の悲劇と同じ構造。AIに指示してもブレているのは 世界についての理解・仮定
- vibe codingでの勘違いは30年前に予言済み
- プロンプトの前にvon Neumannの原則。何の話か分かってないうちに厳密になるな
参考
- Michael Jackson, "The World and the Machine", Proceedings of ICSE '95
- 飯泉純子「問題は『問題』にある — An Overview of Problem Frames」ソフトウェア・シンポジウム2009 モデリングWG
- 前編:IT界でもbeat itを奏でるマイケルジャクソン🕺