機能追加できないのは、指示が悪かったからではない
この問題を検索すると、たいてい同じ助言に行き着きます。指示を具体的に書きましょう。小さく作って少しずつ足しましょう。テストと改善を繰り返しましょう。どれも正しく、実際に効きます。
ただ、この助言には前提が抜けています。指示を具体的に書けるのは、いま何がどこにあるかを自分が把握できている場合だけです。三か月前にAIが作ったものの中身を読んでいない状態で、具体的な指示は書けません。書けるのは「ここに機能を足して」という曖昧な依頼だけです。
小さく作る、という助言も同じです。小さく作ったものを足していった結果として複雑になるのですから、「小さく作る」は開始時点の助言であって、三か月後の自分を助けません。
つまり、詰まっているのは指示の書き方ではありません。指示を書くために必要な前提が、手元に無い状態です。ここを取り違えると、プロンプトを磨く方向に努力が向かい、いつまでも抜けられません。
拡張を止める4つの構造
relmeaでは、開発を14の段階に分けて進めています。そのうち後半の2段は、新規開発ではなく「既存のアプリに機能を足す」ための独立した段として置いています。拡張を最初から別工程として扱っているのは、拡張が最初の設計に強く依存すると分かったからです。
実際に手が止まる原因は、次の4つに集約されます。
1. どこに何があるかが、どこにも書かれていない
AIは頼まれたものを作りますが、頼まれていない地図は作りません。画面の一覧、扱っているデータの種類、外部サービスとのつなぎ目。これらが一枚にまとまっていないと、機能を足すときに「どこを触ればいいか」を毎回AIに探させることになります。探させると、AIは似た場所を見つけて、そこに足します。似た場所は、たいてい正解ではありません。
2. 同じ情報が、何箇所にも散っている
いちばん多い詰まり方です。たとえば価格という情報が、画面の表示部分・計算部分・保存部分の3箇所に別々に書かれている。ひとつ直しても、残り2つは古いままです。動きはするので、間違っていることに気づけません。
人が書いたコードでも起きることですが、AIに継ぎ足しで作らせると起きやすくなります。AIは前回の会話を覚えていないので、既にある定義を探すより、その場で新しく書くほうを選びがちだからです。
3. 壊れたことが分かる手段が無い
機能を足したあと、他の機能が無事かどうかを確かめる方法がありません。全部の画面を手で触って確認するしかない状態です。面倒なので、確認は省略されます。省略した回の直後に壊れます。
これは技術の話に見えますが、実際には順番の話です。確かめる方法は、壊れてから用意するものではなく、作るときに一緒に用意しておくものです。
4. 触ってよい範囲が決まっていない
「ここに機能を足して」と頼むと、AIは目的を達成するために必要だと判断した範囲を、遠慮なく書き換えます。ログイン処理や決済のような、触られると困る部分も対象に入ります。範囲を先に決めていないと、頼んだ機能は動くようになったが別の何かが静かに壊れている、という結果になります。
「動いている」と「拡張できる」は別のもの
ここまでの4つに共通しているのは、どれも動作確認では見つからないという性質です。画面は出ますし、ボタンも押せます。エラーも出ません。
作ることの速度が上がった結果、この差が広がりました。以前は一行ずつ書いていたので、書いている最中に自分の頭の中でも中身が確認されていきました。作る作業と理解する作業が同時に進んでいたわけです。作る時間がほぼゼロになると、理解する作業だけが丸ごと後ろに残ります。
自分が読んでいないものが動いている。この状態は以前は存在しませんでした。拡張で詰まるのは、その残された理解の請求書が、三か月遅れで届くからです。
「毎回ぜんぶ読ませれば済む」のではないか
ここまで読むと、ひとつ疑問が浮かぶと思います。いまのAIは長い文章を扱えるのだから、依頼のたびにアプリ全体を読ませればいいのではないか、という疑問です。
半分は正しく、半分は外れています。読ませること自体はできます。ただ、渡す情報を増やすほど出力が安定するかというと、そうはなりません。渡された情報の全部が同じ重さで扱われるわけではないからです。大事な一行が、その他大勢の行に埋もれます。
実際に起きるのは、こういうことです。全体を渡して「ここに機能を足して」と頼むと、AIは似た書き方の場所を見つけて、そこに寄せて書きます。全体を読んでいるのに、参照するのは目についた一部です。地図を渡された人と、資料の束を渡された人の違いに近いと考えると分かりやすいかもしれません。
必要なのは量ではなく、順序と地位です。これは変えてはいけない、これは今回の対象、これは参考。この3つの区別が付いた状態で渡せば、分量はむしろ減ります。前章の4項目は、この区別を先に作っておくための作業でもあります。
最初に決めておく4つ
逆に言えば、作りはじめる前に4つだけ決めておくと、三か月後の自分がかなり楽になります。どれも技術的な知識を必要としません。
- 画面の一覧を、先に文章で書く。何の画面がいくつあり、それぞれ何をする場所なのか。作る前に書けば、AIはそれを地図として使います。あとから書こうとすると、出来上がったものを読んで書き起こす作業になります。
- 扱う情報の種類と、その置き場所を1箇所に決める。価格・顧客・注文のように、アプリが扱う情報を並べ、それぞれの正しい定義がどこにあるかを決めます。「この情報の正解はここにある」が決まっていれば、散らばりは起きません。
- 壊れたと分かる方法を、機能ごとに1つ書く。難しい仕組みは要りません。「注文を1件入れて、一覧に出れば正常」という一文で十分です。これが機能の数だけあれば、追加のたびに順に確認できます。
- 触ってはいけない部分を先に名指しする。ログイン・支払い・顧客情報のように、壊れると取り返しがつかない部分を挙げておき、依頼のたびにその一文を添えます。
4つとも、作る前なら文章で書けます。作ったあとに書こうとすると、出来上がったものを読み解く作業になり、その読み解きこそが今できずに困っていることです。順番を逆にしないでください。
すでに追加できなくなっているアプリをどうするか
いま手元にあるものが、既にこの状態だという場合もあります。作り直すべきかと聞かれることがありますが、多くの場合、作り直す必要はありません。
先にやるのは、機能を足すことではなく、地図を書くことです。AIに対して「新しい機能を足して」ではなく、「いまこのアプリに何の画面があり、どの情報をどこで扱っているかを一覧にして」と頼みます。読ませて、まとめさせる。この作業はAIが得意な部類です。
出てきた一覧を自分で読み、事実と合っているかを確認します。ここは省略できません。AIは読み取れなかった部分を、それらしく埋めることがあるためです。合っていない箇所を直せば、それがそのまま「先に決めておくはずだった地図」になります。
地図ができてから、機能追加の依頼をします。触ってはいけない部分の一文を添えて、確認の方法も一緒に指定する。これだけで、崩れ方はかなり変わります。
人が持つ判断と、AIに渡す作業
relmeaでは、この領域の線引きを次のように置いています。読み取り・一覧化・下書き・確認の実行はAIに渡します。何を触らせないか、どこまでを一度に変えるか、出てきたものを受け入れるかどうかの判断は、人が持ちます。
作れる速度が上がったぶん、人が持つべき仕事は「作ること」から「確かめる基準を決めること」へ移りました。拡張できるかどうかは、この移動を済ませたかどうかで決まります。三か月後に困るかどうかは、実のところ、作りはじめた日に決まっています。