AIの書いた章を、私はこう壊した

前回、叩き台を出す席はAIに任せられるが、壊す席には人が座る、と書きました。今回は実録です。本を一冊書くあいだ、AIの書いた章を、読者役の私がどう壊したか。壊す側の仕事の中身を書きます。

私の立場を先に。本文は一行も書いていません。AIが部ごとに章を納品し、私が読者として通読し、違和感を返す。この本の想定読者は「設計の本を何冊か買ったが通読できなかった人」で、私自身がその代表でした。分からない側の人間が、検証者を務めたわけです。

壊し方には、種類がありました。

枠組みごと壊す

最終章の初稿は、二通りの働き方を対比する構図で始まっていました。AIに頼り切る朝と、モデルを育てる朝。文章としては整っていて、読み物として面白い。

でも、現場の実感と違いました。私の現場では、モデルを設計する工程と、AIに実装を量産させる工程は、対立ではなく相補的な二つの工程です。片方を悪者にした瞬間、話が嘘になる。対比の枠組み自体が成り立たない、と返しました。

章の入り口は全面撤回になりました。代わりの入り口は、私自身の言葉から作られました。「AIで爆速で実装して要件を確かめられるのは、純粋に楽しい」。考えることと確かめることの距離が消えた楽しさから始める構成に変わりました。AIの構図が整っていることと、現場の事実であることは別です。これは検証者にしか判定できません。

物語を壊す

ある章の冒頭は、販売企画の変更をめぐる担当者の会話で始まっていました。読んでいて頭に入らない。名前も期間も対象も変えたのに同じ企画として扱い、承認も取り直さない。業務としてそれは変則的で、実感が湧かないのです。

返した違和感から、冒頭は別の物語に差し替えられました。十年のあいだに旧姓も住所もメールもランクも変わったのに、同じ会員である、という話。読者自身の体験に根ざした例のほうが、同じ概念をはるかに速く運びます。AIは概念の説明として正しい例を出せますが、読者の実感に届く例かどうかは、読者にしか分かりません。

比喩を壊す

AIは、うまい比喩を一文に圧縮する癖があります。「理由を、算盤として書き残す」。「言葉とモデルのずれは、利子を生む」。書き手には自明でも、初読では止まる。

止まった箇所で、私は直させる前に質問しました。「この比喩は何を言っている?」。返ってきた説明は筋が通っていた。元本は言葉とモデルのずれ、利払いは説明のたびの「実は」、返済はモデルの改訂。説明を聞いて納得できたなら、比喩は残して、開く。 圧縮された一文に、その比喩が何をするのかまで本文で書かせました。この作業の副産物で、同じ比喩が別の章で「利子」と「利息」に揺れていたことも見つかりました。

前提を壊す

「有名な系」という一語で、私は止まりました。数学の用語だと知らなければ読めない。別の章では、コード例が途中で書き方を変えていたのに、何の断りもなかった。書ける人には当たり前の切り替えでも、書けない読者には見えない段差です。

ここから決め事が一つ増えました。「書ける人には当たり前」の前提も無言にしない。 学術用語を輸入しない、新しめの構文は初出で一言補う。これは私が書けない側だったからこそ出た規律で、書ける人が読者役なら、たぶん通り過ぎていました。

誤解で壊す

もう一つ、私の誤解が章を育てた例があります。「これは要するに、カプセル化されたクラスのことでは?」と聞いたのです。区別がつかないなら、結局同じものではないか、と。

AIの答えは「そこまでは正しい」と認めるところから始まりました。そのうえで、その理解では守れない抜け道のコードを一つ見せ、規律をコードだけでは書けないから名前を付けて共有するのだ、と展開した。この一節は初稿にはなく、私の誤解から生まれました。誤解は困りごとではなく、モデルへの入力です。 本の中で業務の人に説いていることが、本を書く現場でそのまま起きていました。

壊す側の規律

壊し方を並べてみて、共通していたことがあります。違和感を、即断で直させなかったこと。まず理由を言葉にして、AIに説明を求め、納得してから直す。即断で直すと、私の思い込みが本に入ります。検証者にも、検証が要るのです。

そしてこの工程が、一冊のなかでいちばん骨が折れました。AIの文章はもっともらしいので、疲れていると素通りする。素通りした週は、後の章に矛盾として返ってきました。

開発に写せば、これは現場のエキスパートが仕様の叩き台を壊す場面そのものです。壊す人に要るのは技術ではなく、「分からない」「実感と違う」と言える立場でした。ボトルネックはモデルにある。モデルは、壊されながらしか育ちません。

次回は原則回に戻ります。ここまで「育てる」と言ってきたモデルは、結局どこに残るのか。言葉がそのままコードの名前になり、平文のモデルはAIもそのまま読める、という話です。

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

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

▼ 前の話

▼ 次の話