半年で38版になった
社内向けのWebツールを、半年かけて作った。Claudeとチャットで対話しながら、少しずつ。
私は現場の人間で、専門の開発者ではない。
作っているあいだ、ずっと困っていたことがある。
チャットが切れると、AIは何も覚えていない。
前回どう決めたのか。なぜその形にしたのか。どこを触ってはいけないのか。
全部ゼロに戻る。新しいチャットを開くたびに、私は同じ説明を繰り返していた。
3回目までは我慢できた。10回目で、これは無理だと思った。
いま、引き継ぎのための文書は第38版になっている。
半年で38回、書き直したことになる。
その過程で分かったのは、うまくいかないやり方が先にいくつもあったということだった。
「要約しておいて」では続かない
最初にやったのは、いちばん素直な方法だった。
チャットが切れそうになったら、AIに要約させる。それを次のチャットの冒頭に貼る。
これでいけると思っていた。
抜けたことは、次のチャットで分かる
うまくいかなかった。
要約には、必ず抜け漏れがある。
問題は、その抜け漏れが、抜けた時点では分からないことだ。
新しいチャットで作業を始めて、しばらく進んでから気づく。
「前に決めたはずのことが、反映されていない」と。
そのたびに、前のチャットまで戻った。
最新のやり取りをコピーして貼り、「これが引き継げていない」と説明して、もう一度、資料を作り直させる。
引き継ぎのやり直しに、作業と同じくらい時間がかかった。
そして厄介なのは、要約を作ったAI自身が、自分が何を落としたかを知らないことだった。
「ちゃんと全部書いて」と頼んでも、同じところが抜ける。
厚くすると、今度は進まなくなる
抜けるなら、厚く書けばいい。そう考えて、引き継ぎ文書を詳しくしていった。
すると、別の壁に当たった。
ここで初めて、AIの仕組みを理解した。
AIは、やり取りのたびに、そのチャットを最初から読み直している。
つまり会話が伸びるほど、1回のやり取りで読む量が増えていく。
そこに容量の大きな資料が貼ってあれば、なおさらだ。
ラリーを重ねるほど、1回あたりの消費が膨らんでいく。
当時は無料プランだった。
引き継ぎ文書を厚くしたぶん、消費も跳ね上がった。
貼り付けて、返事が1つ返ってきて、そこで終わり。
ひどいときは1往復も終わらないうちに制限に達し、5時間待ってやり直す。それを何度も繰り返して、数日間まったく進まなかった。
有料プランに変えて、これは解消した。
ただし、ここで気づいたことがある。
引き継ぎを厚くするほど、進まなくなる。この2つは、そのままでは両立しない。
分かったこと
必要だったのは、会話を全部渡すことではなかった。
渡すべきは「話したこと」ではなく、「決まったこと」だった。
会話は長い。決定は短い。
そして次のチャットで必要になるのは、決定のほうだけだ。
引き継ぎプロンプトに何を書いたか
いま第38版にある章立てを、そのまま並べても意味がないと思う。
業務の中身に寄った章も多いし、真似できるものでもない。
代わりに、どの欄が、どんな失敗から生まれたかを書く。
全部そうだった。最初から書こうと思って書いた欄は、ひとつもない。
渡すファイルを取り違える
AIは、こちらが渡したものしか見ていない。
そして厄介なことに、渡されたものが最新かどうかを、自分では判断しない。
版の取り違えが、3回起きた。
そのうち1回は、引き継ぎ文書そのもので起きた。
第20版まであるのに、うっかり第15版を渡してしまった。
AIはそれが最新かを確かめないまま、「第16版」を作ろうとした。
第16版は、とっくに存在していた。
気づいたのは私で、AIではない。
だから冒頭に欄を作った。
「この作業には、このファイルが要ります」と、作業前に必ず言わせる。
あわせて、最新版の一覧を持たせた。
同じ見落としを、何度も繰り返す
資料を直すたびに、表紙の日付を直し忘れた。
1回目は事故で済む。2回目は不注意だと思う。
4回目で、これは自分の注意力の問題ではないと分かった。
そこで、確認手順のいちばん先頭に固定した。
「中身を1か所でも直したら、まず表紙の日付を直す」と。
回数を数えていたから、先頭に上げるという判断ができた。
数えていなければ、たぶん5回目も同じことをしていた。
決めたことを、蒸し返される
AIは前向きに提案してくる。それ自体はありがたい。
ただ、すでに決着したことまで蒸し返してくる。
一度は検討して、理由があって外したはずのものが、次のチャットでまた出てくる。
そのたびに、なぜ外したのかを説明し直すことになる。
そこで「これは勧めないこと」という但し書きを書くようにした。
いま、その但し書きは11件たまっている。
「やらないと決めたこと」を書く欄が要る。
決めたことだけ書いても、決めなかったことは何度でも戻ってくる。
廃止したことが、いつまでも残る
一度やめた手順を、AIが案内し続けたことがあった。2回、同じ指摘をした。
「もうやらない」だけでは足りなかった。
「案内にも書かないこと」と、明示的に禁じる形に変えた。
やめたことは、やめたと書かないと、消えない。
なぜこの作業をしているのかが、分からなくなる
これがいちばん最近、第38版で足した欄だ。
決定は書いていた。次にやることも書いていた。地雷も教訓も書いていた。
それでも、「そもそも、なぜこれを始めたのか」が、どこにも書いていなかった。
数か月経つと、当事者である私自身が思い出せなくなる。
AIに至っては、はじめから知らない。
だから経緯の章を作って、いちばん上に置いた。
いつ引き継ぐかを、自分で決めない
最後に、少し変わった欄がある。
引き継ぎのタイミングを、AI側から提案させることにした。
- やり取りが10往復に達したら
- 決定がいくつかたまり、影響範囲まで洗い出せたら
そのどちらかで、「引き継ぎ用のプロンプトを作りましょうか」と言わせる。
理由は単純で、人間が判断すると必ず後手に回るからだ。
前に書いたとおり、会話が伸びるほど1回のやり取りは重くなる。
「まだ大丈夫」と思っているうちに消費が膨らみ、気づいたときには、引き継ぎを作るぶんの余力が残っていない。
並べてみて分かるのは、どの欄も、痛い目を見てから作られているということだ。
だから、この章立てをそのまま真似する必要はない。
自分が2回繰り返した失敗を、1つ書き足す。それだけでいい。
いちばん効いたのは「教訓」だった
前の章で並べた欄は、どれも役に立っている。
ただ、いちばん効いたのは別の欄だった。
「教訓」という欄がある。
AIがやりがちな間違いと、その防ぎ方を、気づいたときに1行ずつ足していくところだ。
いま、52件たまっている。
日付を入れて書いている。いちばん古いものは8月20日。
1日で14件増えた日もある。その日は、資料をまとめて直していた。
実際に書いてあるもの
抜き出すと、こういう調子だ。
関数名を推測で書かない。現物から拾う「決めていない」と「決めた」は違う「対応済みかもしれない」は、必ず現物で確かめる書かれていないことを、書かれている記述から推測して断定しない検索語が雑だと、無関係な当たりを大量に拾うコードのコメントも、資料の記述も疑う残タスクの一覧そのものが、実態と食い違っていることがある「空のはず」のフォルダも、1つずつ目で開いてから消す一括置換しない。同じ文字列でも意味が違う「白紙にしたい」の範囲を勝手に広げないどのファイルに入っているかを思い込まない（1日に2回間違えた）
最後の1件には、回数まで書いてある。
同じ日に2回やったから、書かずにいられなかった。
並べてみたら、型があった
52件も並ぶと、さすがに気づく。
バラバラに見えて、実は同じことを何度も書いていた。
大きく4つだった。
① 推測で埋める確認していないことを、確認したかのように書く。
関数名を推測で書く。画面の症状から原因を推測する。略称の意味を確かめずに使う。
② 「〜のはず」で進む「まだやっていないはず」「対応済みかもしれない」——確かめずに前提にする。
空のはずのフォルダを、開かずに消そうとする。
③ 書いてあるものを疑わないコードのコメント、資料の記述、残タスクの一覧。
書いてあるからといって、実態と合っているとは限らない。
むしろ、古くなっているほうが多い。
④ 探し方が雑検索語が粗くて無関係なものを大量に拾う。
定数にまとめられた名前は、文字列で探しても見つからない。
同じ文字列でも意味が違うのに、一括で置き換えてしまう。
型が分かると、対策が書ける
1件ずつの教訓は、正直あまり効かない。
数が増えると、こちらも全部は覚えていられないからだ。
だが型にまとめると、対策が書けるようになる。
- ①には「推測で書かず、現物から拾う」
- ②には「『はず』を見たら、その場で確かめる」
- ③には「書いてあるものも、現物と突き合わせる」
- ④には「探す前に、探し方が合っているか確かめる」
同じ間違いは、同じ型で起きる。
だから型ごとに手を打てば、1件ずつ潰すより効く。
突き詰めると、1つだった
そして、4つ並べたところで気づいた。
全部、同じことを言っている。
確かめていないことを、確かめたように書く。
推測で埋めるのも、「はず」で進むのも、書いてあるものを疑わないのも、探し方が雑なのも——結局これだ。
そして、これはAIだけの話ではない。
私も同じことをしていた。
「たぶんこうなっているはず」で資料を書き、あとで現物と違っていて直す。
教訓を書き足しながら、半分は自分に言っていた。
だから、開発スタイルの欄にはこう書いてある。
記憶に頼った確認は避け、すべてデータで確認することを基本とする。
それでも間違える
52件も教訓を書けば、さすがに減るだろうと思っていた。
減った。ただし、ゼロにはならなかった。
表紙の日付の直し忘れは、注意書きを入れたあとに4回目が起きている。
「どのファイルに入っているかを思い込まない」という教訓が書かれたのは9月1日で、そのときにはもう50件近い教訓が並んでいた。
それでも、同じ日に2回間違えている。
書けば防げる、というものではなかった。
「防ぐ」から「早く見つける」へ
途中で、考え方を変えた。
間違いを起こさせないのではなく、間違いをその場で見つける。
具体的には、こういう決めごとにした。
- 書き換える箇所ごとに照合を入れる。1か所でも見つからなければ、ファイルを作らずに止める
- 照合の結果は全件を画面に出させる。「できました」だけでは受け取らない
- 完成したら画像にして目で見る
3つ目が、地味に効く。
文字だけ見ていると、表がはみ出していても気づかない。
信用する、しないの話ではない
これは「AIは信用できない」という話ではないと思っている。
自分も同じくらい間違えるからだ。
違うのは、確かめる手順を決めてあるかどうかだけだ。
決めていなければ、人もAIも同じように間違える。決めてあれば、どちらも減る。
だから引き継ぎプロンプトに書いたのは、「AIを疑え」ではなく、「どうやって確かめるか」のほうだった。
誰でも使える形にする
ここまで書いてきたことは、私の業務とはほとんど関係がない。
版の取り違え。同じ見落としの繰り返し。決めたことの蒸し返し。
どれも、AIと長く作業すれば必ず出てくる。
最小構成は3つ
いきなり38版のような文書を作る必要はない。というより、作れない。
始めるなら、この3つでいい。
① 決まったこと何を、なぜそう決めたか。理由まで書く。
理由がないと、次に条件が変わったときに判断できない。
② やらないと決めたこと検討して外したもの。
これを書かないと、何度でも同じ提案が返ってくる。
③ 教訓同じ間違いを2回やったら、1行足す。それだけ。
1版目は粗くていい
私の1版目がどんな内容だったかは、記録も残っていないし、正直もう覚えていない。
ただ、いまの形とは似ても似つかなかったとは言える。
38版は、38回書き直した結果だ。
最初から設計したものではない。
失敗のたびに1行ずつ足していったら、こうなった。
だから、最初は粗くていい。
足りない欄は、そのうち痛い目を見て気づく。
おわりに
AIは速い。
半年前の私に、社内で使えるツールが作れるとは思っていなかった。
けれど、速いことと、続けられることは別だった。
チャットは切れる。AIは覚えていない。
そのたびにゼロから説明していたら、たぶん途中でやめていたと思う。
半年前の自分に一言だけ渡せるなら、これを渡す。
会話を残すな。決定を残せ。
会話は長い。決定は短い。
そして次に必要になるのは、決定のほうだけだ。
いま第38版まで来て、まだ完成していない。
たぶん完成しない。次に痛い目を見たら、また1行増える。
それでいいのだと思う。
この記事は Zenn にも掲載しています。