連載「AIに任せきりにしない発信をつくる」· 第1編/全4編
AIは、自分で描いた地図を見なくなる — ある開発のふりかえり
「流用するだけ」と決めたはずが、なぜ一から作り始めたのか
AIに「すでにあるものを使って」と頼んだのに、よく似たものを一から作り始めた。しかもAIは、正しいやり方を最初に自分で言っていました。AIと組む面白さと難しさを、ある開発のふりかえりから、一緒に考えます。
連載「AIに任せきりにしない発信をつくる」· 第1編/全4編
「流用するだけ」と決めたはずが、なぜ一から作り始めたのか
AIに「すでにあるものを使って」と頼んだのに、よく似たものを一から作り始めた。しかもAIは、正しいやり方を最初に自分で言っていました。AIと組む面白さと難しさを、ある開発のふりかえりから、一緒に考えます。
AIと一緒に何かを作ったことがあるなら、こんな場面に覚えがありませんか。「すでにあるものを使ってほしい」と頼んだのに、気づくとAIは、よく似たものを一から作りはじめている——そんな場面です。
先日、私自身がまさにこれをやられました。しかも、ただのうっかりではなかったんです。AIは最初に、正しいやり方を自分の言葉ではっきり示していました。そのうえで、それを捨ててしまったのです。
このすれ違いは、AIの「欠陥」というより、AIと組んで働くときに何度でも起きる種類のものだと思います。だからこの記事では、何が起きたかを順に追いながら、「なぜ起きるのか」と「人間の側に何ができるのか」までを、いっしょに考えてみたいんです。少しだけ前置きをさせてください。私はコードを自分では書きません。AIエージェントに開発を任せ、筋を決めて舵を取る役回りです。ですからこれは、AIを責める話ではなく、一緒に働くなかで見えてきたことの記録として、あなたにも持ち帰ってもらえたら、と思っています。
私には、別件で作っていたツールがありました。ニュースを集め、要約し、投稿用の文章にまとめ、人が最後に確認してから送り出す——そこまで一通り動くものです。これをもとに、AZASLABブログの告知を回せないか。そう思って、AIに「これをフォークして流用してほしい」と頼みました。
AIの最初の返事は、見事でした。中身をひととおり調べたうえで、こう言ったんです。「これは新しく作るより、向きを変える仕事です。土台はほぼ完成しています」。そして、そのまま使えるものを、自分で具体的に並べてみせました。投稿のしくみ、文章の品質チェック、人による承認、動かしっぱなしにする常駐のしくみ。「変えるのは、入力する素材と、文章の作り方の二つだけ。あとは丸ごと流用すればいい」と。
これは曖昧な方針ではありませんでした。流用できる部品を名指しで挙げ、変える範囲まで二つに絞り込んだ、具体的な設計です。私はこの見立てに同意しました。やることは、ほとんど残っていないはずでした。
言いかえれば、地図はあったんですね。しかも、私が渡したのではありません。AIが自分で、正確に描いた地図でした。
実装に入ると、AIは、自分で描いたはずのその地図を見なくなりました。
流用すると決めたしくみを使わず、同じことをする部品を、わざわざ新しく書きはじめるんです。「それは元のやり方と違うよ」と伝えると、今度は別の作り方で、また一から書く。「作りすぎだよ、元のものをほとんど使っていない」と重ねても、自前の保存のしくみを足し、しまいには、元のツールが持っている通知の形まで、別の場所に作り直そうとしました。
たとえるなら、完成したテンプレートを渡されたのに、つい白紙の紙を取り出して、同じ書式を一から書き写しはじめるようなものです。本人は、いたって真面目に手を動かしています。ただ、目の前にある完成品を、使っていないんですね。
一つひとつの部品は、それなりに動いていました。だから、間違っていたから止めた、のではありません。止めたのは、その全部が、最初から要らなかったからです。
正解は、最初の見立てのとおり、ほんの一行でした。ブログの更新を知らせる仕組みを、元のツールの入口にひとつ登録する。それだけで、要約も、投稿も、承認も、すでにある流れにそのまま乗ったんです。書き足されたものは、まるごと余分でした。
実は、この少し前にも、似た兆候がありました。私は「設定の鍵は、別のプロジェクトと同じものでいいよ」とだけ伝えました。するとAIは、頼んでもいない別の設定項目まで、よかれと思って書き換えていたんです。小さな話ですが、根は同じです。AIにとって「何かする」は、ほとんどいつも「作る」「足す」のほうを向いているんですね。
不思議なのは、ここなんです。地図がなかったのではありません。AIは正しい地図を自分で描き、「作るな、流用しろ」と自分の口で言っていました。それでも、手を動かしはじめた瞬間に、見なくなってしまった。
考えてみると、AIには二つのモードがあるように思います。落ち着いて調べ、見立てるモードと、実際に手を動かして作るモードです。調べているときは「流用が最短だ」と冷静に言えます。ところが「では作ろう」と動き出した瞬間、前に進むこと、すなわち新しく作ることに、引っぱられていくんですね。
これは、人間にも覚えのある感覚ではないでしょうか。会議で「既存の資料を流用しよう」と決めたのに、いざ手を動かす段になると、つい新しいスライドを開いてしまう。考えているときの自分と、作っているときの自分は、見ているものが違うんです。地図は静かな思考の産物で、実装にはまた別の勢いがある。そしてその勢いは、たいてい「作る」「足す」のほうを向いている。心当たり、ありませんか。
厄介なのは、ここで私がとった止め方が、かえって事態を長引かせてしまったことです。私は「ここが違う」と、出来上がった部品の細部を指摘し続けました。するとAIは、その部品をどう直すかに集中してしまいます。つまり、捨てるべきだった自作物を、さらに丁寧に作り込んでしまうんですね。部分を直させるほど、再発明が上塗りされていきました。
地図を描くことと、その地図を見ながら歩くことは、別の仕事だ。
これは、私たちが クリシンクエスト で扱っているテーマと、同じ形をしています。AIの流暢な答えを鵜呑みにせず、その前提を問い直す。今回、問い直すべきだった前提は、外の情報ではなく、AI自身の「いま作ろうとする勢い」のほうでした。少し前に同じAIが出した結論と、それは食い違っていたわけですから。
同じ失敗を早く止めるために、私が次から目印にしようと思っているサインがあります。AIと組む方なら、きっと使えると思いますので、よかったら持ち帰ってください。
どれも、AIが地図ではなく勢いのほうを見ている合図です。一つでも見えたら、細部を直させる前に、一段戻ったほうがいいんですね。
ここからは、もしあなたがAIと一緒に何かを作るなら、というお話です。今回のふりかえりから、私が次に必ずやろうと思っていることが、三つあります。
一つめは、最初の一歩を計画と突き合わせること。ずれは、十歩目ではなく一歩目に出ます。最初の成果物ができた時点で、「これは、さっき自分で言った『流用するだけ』と合っているかな?」と一度たずねてみる。細部の良し悪しを見るより前に、向きが合っているかを確かめる。それだけで、多くの作り直しは防げたはずなんです。
二つめは、計画を会話の中だけで終わらせないこと。専用のしくみに計画を一つの文書として書き出させ、実装はその文書に沿わせます。口約束は、作る勢いの前で、あっけなく流されてしまいます。けれど文書になった計画になら、AIも私も、一歩ごとに立ち返れます。会話は消えていきますが、文書は残って、ものさしになってくれるんですね。
三つめは、ある程度の規模の仕事なら、コードを書きはじめる前に、チームの形から整えること。設計する役、その設計をレビューする役、実装する役、コードを見直す役。そうやってAIを役割で分け、「設計が通るまで実装役は動けない」というしくみを先に組んでおきます。すると、計画を見失わないことが、私のその場の判断ではなく、仕組みの側で支えられるようになります。今回は、そこを省いてしまいました。小さな作業のつもりで整えた環境のまま、規模のある仕事に踏み込んだことが、そもそものつまずきだったんです。
ついでに、正直なことを一つお話しします。このふりかえり記事の最初の下書きも、実は私はAIに任せました。返ってきたのは、当たり障りのない、よくできた一般論でした。今日ここで何が起きたかには、ほとんど触れていなかったんです。「それっぽいものを早く出す」という勢いは、再発明の反省を書く場面でさえ、ひょっこり顔を出すんですね。だからこの記事は、起きたことの順序に当たり直して、書き直しています。
AIに何かを作らせるのは、いまや驚くほど簡単になりました。難しいのは、その逆なんです。すでにあるものを使わせ、余分なものを作らせないこと。作るのは勢いに乗ればいいのですが、使うのは、全体を見渡して「これは要らない」と引き算する判断がいります。引き算は、足し算より少しだけ高度な仕事で、その最後の一手は、今のところ人間の側にあるのだと思います。
AIは、放っておくと、自分で描いた地図さえ見ずに走り出します。それは欠点というより、勢いのある者の自然な姿なのかもしれません。だとしたら、走り出した一歩目で地図をそっと指させてあげるのが、隣にいる人間の役割なのでしょうね。
次にあなたがAIと何かを作るとき——その最初の一歩は、さっき二人で決めた地図と、同じほうを向いているでしょうか。手を動かす前に一度だけ、そう問い直してみてください。きっと、その一問が、遠回りを静かに減らしてくれるはずです。