理解は生成できても、判断力は生成できない

たとえば、ウェブサイトに検索ボックスを追加したいとする。

プロジェクトを直接操作できるAIエージェントに要件を伝える。エージェントはファイルを変更し、チェックを実行したうえで、機能が完成したと報告する。実装内容とチェック結果も添えられている。ページを開き、必ず存在する語句で検索すると、結果が表示された。

説明は理解できる。チェックも通っている。ページも正常に見える。この時点で、この機能がどういうものかはもうわかった、受け入れてよい、と考えやすい。

ところが、見つからない語句に変えると、ページでエラーが起きる。「何も見つからないとエラーになる」と伝えると、エージェントは自分で問題を再現し、原因を調べ、コードを修正し、テストも一つ追加する。そしてこう報告する。もとのコードは検索結果に少なくとも一件のコンテンツがあることを前提にしていたが、結果がない場合にも対応し、チェックも通った、と。

説明を読めば、原因はわかる。そこから「エッジケースも考慮しなければならない」という教訓を引き出すのも簡単だ。それはもちろん正しい。以前から聞いたことがあり、まったくその通りだと思っていたかもしれない。問題は直り、教訓も得た。次の機能に進んでよさそうに見える。

だが、要件を伝えてから修正を確認するまで、自分にこう問いかけることはなかったかもしれない。なぜ最初に、必ず存在するあの語句だけを検索したのか。「チェックが通った」というとき、いったい何がチェックされていたのか。結果が表示されただけで、なぜ機能が完成したと思えたのか。

AIはコードに潜んでいた前提を取り除いた。だが、自分の判断に潜んでいた前提には、気づかなかったかもしれない。

私たちはとうに、教訓があふれる時代を生きている。誰かが長年の経験を一言に凝縮し、私たちはそれを数秒で読み終える。「エッジケースも考慮する」もそうなら、「結論を急がない」もそうだ。教訓を理解するのは難しくない。難しいのは、次に物事が順調に進んだとき、本当に立ち止まり、その結果がまだ何を証明していないのかを考えることだ。

AIは、その間隔をさらに縮めた。以前なら、一つの問題に長く行き詰まることもあった。いくつかの原因を推測し、いくつかの方法を試して、ようやく最初の考えのどこが成り立たなかったのかがわかった。今はエラーが起きると、すぐに説明と修正が一緒に届く。何が起きたかを説明できるようにはなっても、物事の見方を修正する機会があったとは限らない。

こうして、説明と自分とのあいだに隔たりが生まれる。説明はすでに整っているのに、自分ではまだ一度もその過程をたどっていない。次に少し違う問題に出会うと、やはりどこから見ればよいのかわからない。

理解は生成できる。だが、判断力までその説明と一緒に受け取れるわけではない。

エラーを起こしたあの検索ボックスに戻ろう。二つの入力を残しておく。一つは結果があり、もう一つは結果がない。修正を頼むときには、以前のチェックでなぜ二つ目の場合がカバーされなかったのかも調べてもらう。そして、自分もなぜそれを見落としたのか考えてみる。コードを調べ、テストを追加する作業は、引き続きエージェントに任せてよい。ただ、さきほどの「チェックが通った」という一言だけでは、自分の判断を支えるのに不十分だったとわかり始める。

修正後には、自分で新しい、絶対に見つからない語句を一つ選んで試す。ページでエラーは起きない。これで何を確かめたのかがわかると同時に、この一回だけでは、ほかのケースにも問題がないとは保証できないこともわかる。今後、機能が一度うまく動くのを見たとき、自然にもう一つ問いかけるようになるかもしれない。今試したのは、最も順調に進む一通りだけではなかったか、と。

これはごく小さな変化だが、「エッジケースも考慮しなければならない」と覚えるより、判断力に近い。その言葉がようやく、自分のしたことと結びつく。どのように確認し、何を見落とし、自分が早すぎる段階で確認を終えていたことにどう気づいたのかと。

学ぶために修正を拒む必要はない。すべてのコードを自分で書き直す必要もない。残す価値があるのは、自分で推測し、試し、間違いに気づき、もう一度判断するまでの過程だ。AIもその過程に加わり、調査や試行にかかる時間を短くしてくれる。だが、毎回この過程まで飛ばしてしまえば、問題は解決しても、次の問題に対する自分の判断が変わるとは限らない。

次にあの検索ボックスを開いたとき、まず絶対に見つからない語句を入力する。そのとき初めて、「エッジケースも考慮しなければならない」は、ただ賛同するだけの言葉ではなくなる。