AIは、自分の約束を覚えていない

前回、「注意して見張るのではなく、構造で縛る」と書きました。今回は実録です。本を一冊書くあいだ、私とAIの間で最後まで働き続けた小さな仕組み——「あとで回収する」と約束した伏線の台帳——の話をします。

技術書には伏線があります。「この話は第12章で戻ってきます」と予告して先へ進む。序章で置いたたとえ話を、終盤で回収する。『モデルを育てる』では、この種の約束が全部で二十四本ありました。

問題は、誰がその約束を覚えているか、です。

AIは、前の章の約束を知らない

以前「AIとの長い会話は、なぜ壊れるのか」で書いたとおり、この本は章ごとに会話を区切って書きました。つまり第3章を書いた会話と第18章を書く会話は、別物です。第3章で「この意味は最終章で回収します」と書いたAIは、最終章を書く時点ではその約束を知りません。

では私が覚えているか。覚えていません。二十四本の約束の張った場所と回収先を、数か月にわたって頭の中に置いておける人はいないでしょう。

「覚えておく」を、人の記憶にもAIの記憶にも置かない。置く場所は文書しかない——これが台帳の出発点でした。

台帳の形

最初は、管理用の文書に箇条書きを足していただけでした。「序章の路線図のたとえ→14章で回収」。それが十本を超えたあたりで、表に組み直しました。番号・伏線の中身・張った場所・回収先の四列。未回収と回収済みの二枚に分ける。

運用の決め事は二つだけです。章を書く前に、未回収の欄を読む。伏線を張ったら、回収したら、同じ会話の中で台帳を更新する。「あとで台帳に書く」は、会話が終わった瞬間に消えるからです。

もう一つ、人の目を補う網も張りました。「第N章で」「最終章で」という予告の言い回しを、全章から機械的に検索する。台帳に載っていない約束が本文に紛れていないかを、通読ではなく検索で確かめる。前回の「柵」の、執筆版です。

この形が便利だったので、同じ型をもう一つ作りました。本文で「巻末の参考文献に挙げます」と書いた箇所の台帳です。こちらは全項目が消化されるまで執筆完了としない、という完成条件つき。約束は、負債です。負債には元帳が要ります。

台帳が生んだ事故

うまくいった話だけでは実録になりません。台帳は、一つ事故を起こしました。

終盤のある章で、AIが「本書の約束どおり、この語はこう呼び分けます」と書いたのです。読んで、引っかかりました。そんな約束、本文のどこにも書いていない。あったのは執筆管理用の文書の中だけでした。AIは台帳と決め事を毎回読んでいますから、それを「本書がすでに宣言したこと」と取り違えたのです。

読者に見えるのは本文だけです。台帳は書き手の記憶であって、読者の記憶ではない。この事故のあと、完成前の検査項目が一つ増えました。「約束どおり」「先に述べたように」の先行文が、本文に実在するか。 記憶の外部化は、その記憶を誰が読めるのかまで設計しないと、こういう形で漏れます。

開発に写すと

この話は、そのままコードの世界にあります。「TODO: あとで直す」のコメント。設計文書の「将来対応」。会議で交わした「次のスプリントで」。どれも約束であり、負債です。

AIにコードを書かせるようになって、この負債の発生速度は上がりました。AIは一つの会話の中では律儀に「あとで対応します」と書きますが、次の会話ではそれを知りません。人が覚えている量には上限がある。ならば、約束を張ったその場で元帳に載せ、決まった地点で元帳を読み返すしかありません。私の場合の「決まった地点」は章を書く前でした。開発なら、機能に着手する前、レビューの前でしょう。

そして元帳は、人にもAIにも読める平文で置く。人の記憶でもAIの記憶でもない第三の場所に、約束を置いておく。これが本を一冊書いて、最後まで働き続けた仕組みの正体です。

何を約束したかは、その仕事の一部です。ボトルネックはモデルにある——約束の台帳もまた、育てるべきモデルの一枚でした。

次回は原則回に戻ります。台帳も柵も、結局は「人の注意をどこに使うか」の話でした。人の注意という、いちばん希少な資源をどこに配り、どこをAIに委ねるか——その線引きの原則を書きます。

この連載の元になった書籍『モデルを育てる ― 要件を探り、MVPで確かめ、境界で分ける実践ドメイン駆動設計』(有原悠)は、ここで書いた台帳で伏線を回収しながら書き上げた本です。架空の小売チェーン「アオバ堂」を舞台に、要件の探り方からAIとの協働までを一冊で扱っています。

※Kindle Unlimited読み放題対象です。

▼ 前の話

▼ 次の話