AIにコードを書かせる人が増えました。でも、AIが書いたコードは、なぜそう作ったかが後で分からなくなりがちです。この記事は、その混乱を防ぐ進め方を紹介します。解説はグーグルの技術者デイブ・レンシンさんです。うれしいのは、特別な道具がいらないことです。新品のAIに設計を見せて、意味が通じるか試すだけです。
目次
- なぜ今この話が大事か
- ゾウとキンギョという2つの役
- 「設計を先に書く」はどこが新しいか
- 自分にどう関係するか
なぜ今この話が大事か
AIは頼めば大量のコードを書きます。でも指示があいまいだと、それらしく見えて中身がずれたコードが増えます。直すほど別の場所が壊れ、後で収拾がつきません。だから「何を作るか」を先に固める必要が出てきました。
ゾウとキンギョという2つの役
レンシンさんは、AIを2つの役に分けて使います。ゾウは、長く相談して記憶が濃くなったAIと、その相談から作る設計書です。設計書とは、何をどう作るかを言葉でまとめた文書です。キンギョは、記憶ゼロのまっさらなAIです。
コツは、いきなり答えを頼まないことです。まず「足りない点を質問して」と頼み、15分ほど問答します。すると考えがはっきりし、設計書の質が上がります。
できた設計書を、新品のキンギョに渡します。中身を正しく説明できなければ、設計書に説明不足があるサインです。
図で表すとこうなります。
これまで
[人]→[AIにコード]→中身が不明
これから
[人]⇄[ゾウ:記憶が濃いAI]
→[設計書]
→[キンギョ:新品AIで確認]
→[コード]
上は今よくあるやり方です。人がいきなり書かせるので、後で中身を追えません。下がレンシンさんの案です。記憶の濃いAIと相談して設計書を作り、新品のAIに見せて通じるか確かめてから、コードに進みます。
「設計を先に書く」はどこが新しいか
「設計や仕様を先に書く」考え自体は新しくありません。2025年から広まった「仕様駆動開発」も同じ立場です。これは先に仕様書を書き、AIに作らせるやり方です。技術コンサル会社のThoughtworksは、これを「まず文書、次にコード」と説明します。OpenAIのショーン・グローブさんも同じ考えです。2025年の講演で「仕様こそが新しいコードだ」と述べました。
では、レンシンさんの案の新しさはどこか。設計書が本当に足りているかを、安く試す方法を示した点です。新品のAIに渡して通じなければ、人にも通じない。この一手間が具体的なテストになります。
自分にどう関係するか
ここからは私の見立てです。この考えは、コードを書かない仕事にも使えます。企画書やマニュアルを、事情を知らない人に読んでもらうのと同じです。一読で伝われば、その文書は足りています。何度も質問されるなら、書き直す合図です。AIが下書きを量産する時代ほど、何を作るかを言葉で詰める力が価値になります。
今日覚えること
- AIには答えより先に、足りない点を質問させる 🐘
- 設計書は新品のAIに見せ、通じるか確かめる 🐟
一次ソース(最初に発表した元): デイブ・レンシン(グーグルの技術者)が個人ブログMediumで公開(2026年4月)。
https://drensin.medium.com/elephants-goldfish-and-the-new-golden-age-of-software-engineering-c33641a48874
ニュースレター『Leadership in Tech』は、この記事を紹介した媒体です。最初の発表元ではありません。
裏取りに使った参考: Thoughtworks「Spec-driven development」。
https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices