「1982年の予言」がAI時代についに実現？ RADに学ぶ、正しい「バイブス・コーディング」の作法

――40年前に生まれた開発手法が、いまAIエージェント時代の"正解"を教えてくれる

こちらのビデオを紹介します。

https://www.youtube.com/watch?v=J0zbWsutyA8

はじめに：1982年の「予言」と、いま私たちがやっていること

1982年、コンピュータ科学者のジェームズ・マーティンは『プログラマーなきアプリケーション開発（Application Development Without Programmers）』という、当時としてはかなり刺激的なタイトルの本を出しました。

それから40年あまり。

「AIエージェントが自然言語の指示だけでアプリを組み上げる」――そんな光景が日常になったいま振り返ると、彼のビジョンがいかに先を見ていたかに驚かされます。

私たちは、まさにあの"予言"が現実になる瞬間に立ち会っているわけです。

そして面白いのは、この新しい開発スタイルを乗りこなすための知恵が、実は30年以上前の手法にすでに書かれていたという点です。

それが、今日紹介する 「RAD」 です。

RADとは何か：計画よりスピードを選んだ手法

――ウォーターフォールへのアンチテーゼとして生まれた

RAD（Rapid Application Development：迅速なアプリケーション開発） は、1991年にジェームズ・マーティンによって体系化された開発手法です。

当時主流だったウォーターフォールモデルが「最初にすべてを綿密に計画する」ことにこだわったのに対し、RADが優先したのは、

• 速度
• 反復
• ユーザーからのフィードバック

の3つでした。

ではなぜ、こんなに優れた考え方が30年も主流になれなかったのか。

理由はシンプルで、当時のCASE（コンピュータ支援ソフトウェア工学）ツールが非力すぎたからです。複雑で洗練されたアプリケーションを組むには、ツール側の力がまったく足りていませんでした。

そのギャップを、現代のAIエージェントが見事に埋めてしまった――これが今回の話の出発点です。

RADは、次の4フェーズで構成されます。

• 要件計画（Requirements Planning） 解決すべき課題、対象ユーザー、機能、そして「制約」を定義する軽量な計画フェーズ
• ユーザー設計（User Design） ユーザーが実際に触って反応できるプロトタイプを素早く作る
• 構築（Construction） 短いサイクルで機能を作り込み、テストとフィードバックを回し続ける
• カットオーバー（Cutover） 本番デプロイ、データ移行、ユーザー教育

かつて数年がかりだったプロジェクトを90日程度に圧縮するこの手法が、AI時代のいま、最強の武器として再評価されています。

衝撃の事実：あなたの「プロンプト」は、実は要件定義書だった

――バイブス・コーディングの正体はRADそのもの

いま「バイブス・コーディング（Vibe Coding）」という言葉がエンジニアの間でよく聞かれます。雰囲気（バイブス）でAIに指示を出してアプリを作り上げるあのスタイル、実はこれ、RADの「要件計画」そのものです。

ファイナンス部門の担当者が、AIのチャットに「経費精算アプリを作ってほしい」と打ち込む。

誰が使うのか、どんなルールが必要なのかを自然言語で書き出すその行為は、RADが求めていた「軽量な計画」と完全に一致します。

つまり、

プロンプトは、事実上の要件定義書になった。

私たちは無意識のうちに、40年前に提唱されたRADの第一フェーズを、チャットウィンドウという現代のインターフェースで実践しているのです。

プロトタイプは「捨て石」ではなく「本尊（Keeper）」

――RADが教える、UI設計の本質

AIが数分でアプリを生成してしまう時代、RADの「ユーザー設計」フェーズは新しい意味を持ち始めています。

RADの根本にある前提はこうです。

• ユーザーは、実物を見て触るまで、自分が本当に何を欲しいのか分かっていない

AIが生成したプロトタイプは、使い捨ての試作品ではありません。RADではこれを 「Keeper（本尊）」 と呼びます。

• 「この画面、ちょっとわかりにくい」
• 「背景色がAIっぽくて気に入らない」

こうしたフィードバックをユーザーが返し、AIがそれを即座に反映して修正を重ねる。そうやってプロトタイプそのものが、そのまま最終製品へと育っていきます。

見過ごせないリスク：AI生成コードの45%に潜む「脆弱性」

――「存在しないルール」はテストできない

ただし、このスピード感には落とし穴もあります。

最新の研究によると、AIが生成したコードサンプルの約45%に、何らかのセキュリティ上の問題やロジックの弱点が含まれているとされています。

たとえば、あるファイナンスチームがバイブス・コーディングで経費精算アプリを作ったとしましょう。

もしプロンプトに「自分自身の経費を、自分で承認してはいけない」という制約を書き漏らしていたら――AIはそのロジックを実装しません。

結果として起きるのは、

• 社員が「900ドルの出張費」を自分で申請し、自分で承認する

という、組織として致命的な欠陥（セルフ承認）です。

厄介なのは、ユーザーがどれだけ熱心にアプリをテストしても、この欠陥は見つかりにくいという点です。

なぜなら、

ユーザーは「そこに存在しないルール（欠陥）」をクリックして確認することはできないから。

解決策：再発見された「スペック駆動開発」という半身

――生成機とスペック、2つの車輪

このリスクを乗り越えるには、ジェームズ・マーティンのビジョンの**「もう半分の真実」**に立ち返る必要があります。

彼の構想には、もともと2つの要素がありました。

• 精密な記述（スペック）
• コード生成機

現代のAIは強力な「生成機」ですが、私たちは**「スペック」というもう片方の車輪**を置き去りにしていました。

これが、いま注目されている 「スペック駆動開発（Spec-driven Development）」 です。

プロトタイプを通じて得た知見（例：セルフ承認の禁止）を、口頭の修正で終わらせず、「スペック」として明文化する。

ひとたびスペックに書き込まれれば、それはAIが生成したコードを検証するためのテストへと変換されます。

プログラマーの役割は、

• 一行ずつコードを書くこと

から、

• 精密なスペックを書き、AIの出力を検証すること

へと進化しつつあります。

まとめ：プログラマーは絶滅するのか

RADの4フェーズ（計画・設計・構築・移行）は、いまやAI開発における最も洗練されたフレームワークになりました。

では、1982年の問いに答えを出しましょう。プログラマーはいなくなるのでしょうか。

皮肉なことに、答えは 「いいえ」 です。

1982年の『プログラマーなきアプリケーション開発』というリクエストは、いまもなお**「2つ目の承認（セカンド・サインオフ）」**を待ち続けている状態だと言えます。

プログラマーは絶滅するどころか、これまで以上に重要な**「守護者」**になりました。コードの細部に埋没する作業からは解放された一方で、

• システムの仕様を定義し
• AIが出力した結果の正しさを検証する

という、より高度で知的な領域へとシフトしているのです。

AIにコードを任せられるようになった今、私たちは自分自身にこう問いかける必要があります。

AIが生成した魔法のような成果物に対して、私たちは「正しい問い（スペック）」という2つ目の承認を与える準備ができているだろうか？