シライショウタ（Bot開発エンジニア）
先週、コード補完の確認中に、モデルは存在しない `refreshSessionToken(scope, force=true)` を平然と出した。引数の並びも戻り値ももっともらしい。だが公式SDKにはその関数がない。続けて根拠を聞くと、今度は著者名、開催年、巻号までそろった論文を挙げた。題名は見覚えがあるのに、DOIだけが空中に浮いていた。誤りは雑ではない。体裁だけが妙に整っている。その整い方に、私はまず注目した。
ばけ物はもちろん至って古い世相の一つではあるが、それを観（み）ようとする態度だけがこの頃やっとのことで新しくなり始めたのである。（柳田國男『おばけの声』）
柳田の一節が鋭いのは、あるかないかを争う前に、見方を切り替えろと促す点にある。LLMの誤生成も同じだ。外れ値として捨てるだけでは足りない。コードなら、既存APIの命名規則に寄せた偽関数が出やすい。文献なら、学会名、ページ範囲、出版社の順に殻を作り、中身だけ欠ける。トークン予測は事実を知らないが、形式の連なりはよく知っている。だから崩れる場所にも癖が出る。
私はある時同志の青年を集めて試みに「ばけ物は何と鳴くか」を比較してみたことがあった。大よそ人間のしたりいったりすることに理由のないものがあろうはずがない。（柳田國男『おばけの声』）
この「理由」を、私は運用の側で見る。誤った補完は、その場で消えればまだ軽い。厄介なのは、急ぎの実装メモに貼られ、社内Wikiの雛形に残り、次の案件で再利用されるときだ。すると偽関数は個人の見落としではなく、参照可能な前例になる。モデルは過去の書式をまね、利用者は整った書式を信じる。その往復で、検証前の文が居座る。
必要なのは、風雅な命名ではなく採集票だ。どのモデルが、どのタスクで、どんな形式の誤りを出したか。関数名なら公式リファレンス、論文なら DOI と収録先、仕様説明なら版番号を見る。照合箇所を先に決めておけば、もっともらしさに判断を預けずに済む。柳田を読む利点は、異常を大きな物語へ持ち上げることではない。反復する癖を記録し、止める場所を実務の中に作ることだ。