powered by TechFeed
表示モード
Deep Dive

LLMは「LLMを呼べばいい」と気づけない — AIシステム設計で複雑な非AI的アプローチに走る理由

11月8日、Sean Goedeckeが「LLMs are terrible at designing AI systems」と題した記事を公開した。この記事では、LLMはAIを活用したシステム設計において自らLLMを適切に使おうとせず、不要に複雑な非AI的アプローチに走りがちであるという問題について詳しく論じている。

11月8日、Sean Goedeckeが「LLMs are terrible at designing AI systems」と題した記事を公開した。この記事では、LLMはAIを活用したシステム設計において自らLLMを適切に使おうとせず、不要に複雑な非AI的アプローチに走りがちであるという問題について詳しく論じている。


LLMは「LLMを呼べばいい」と気づけない

LLMはコードを書くのは得意だ。しかしAI的な発想が必要な問題を与えると、往々にして的外れなアプローチを選んでしまう。

Goedeckeが紹介している事例が象徴的だ。あるユーザーが「記憶同士の矛盾を検出するメモリツール」をvibe-coding(AIに任せてコーディング)しようとした。この手のタスクは5年前なら非常に困難だったが、今ならLLMに矛盾をスキャンさせるだけで十分に解決できる。

ところがAIエージェントが選んだのは、記憶アイテムを構造的な論理アトム(Answer Set Programming)に変換し、ソルバーで機械的に比較するという複雑なシンボリックシステムだった。Answer Set Programmingとは、論理プログラミングの一形式で、制約充足問題や知識表現に用いられる手法だ。自然言語の2文が同じ命題を表しているかを解析的に判定するためにこれを使おうとしたわけだが、そもそも解決不可能なアプローチである。

さらに皮肉なのは、そのLLM自身がこの問題の困難さを「知っていた」点だ。ユーザーが痺れを切らして「なぜ動かないのか」と問うと、ClaudeはすぐさまこれがThe Symbol Grounding Problemに関連する130年来の未解決問題であると説明した。Symbol Grounding Problemとは、記号(シンボル)が現実世界の意味とどのように結びつくのかという哲学・認知科学上の難問であり、自然言語処理においても根本的な壁として立ちはだかる。LLMはその困難さを知りながら、何週間も行き詰まったアプローチを繰り返し続けていたのだ。

Goedecke自身も同様の経験をしている。自身のプロジェクトAutodeck(AIによるスペースドリピティションカード生成)を構築する際、エージェントはカードの分類に正規表現やキーワード検索を使おうとし続けた。LLMをもう一度呼べばすむ話なのに、だ。


なぜLLMはLLMを使おうとしないのか

Goedeckeは3つの説明を提示している。

1. 学習データの大半がLLM登場以前のコード

モデルが学習したコードの多くは、LLMがオプションとして存在しなかった時代のものだ。ただし、この説明には穴がある。LLMはjQueryやBackbone.jsではなく、モダンなVanilla JSやReactを選ぶ。他の分野では新しい知識に追従しているのに、なぜかLLMの活用だけは追従できていない。

2. RLVRの学習環境でLLMを呼び出せない

LLMの訓練の多くは、自動採点器がコードの出力を評価する強化学習手法であるRLVR(Reinforcement Learning with Verifiable Rewards:検証可能な報酬を用いた強化学習)で行われる。この環境では、別のLLMを呼び出すためのAPIキーやクレデンシャルが使えない可能性が高い。コストが高く、低速で、リスクもある。結果として、強化学習の過程でLLMを呼ぶコードを書く行動が抑制されているかもしれない。

3. AIエージェントはソフトウェア設計がそもそも苦手

Goedeckeが最も支持しているのはこの説明だ。シンボリックなアプローチを選んでしまう問題は、単なる特異なバグではなく、AIエージェントが「ジョブに適したツールを選べない」という一般的な限界の現れだ。彼はほかにも、破綻する合意アルゴリズムを構築しようとする(古いデータを許容すればいいだけなのに)、イベント駆動システムに同期チェックを導入する、といった同様の設計ミスを目撃してきた。


「賢くて、かつ愚かである」という矛盾

Goedeckeはこう締めくくる。

LLMを人間のエンジニアと同じ基準で評価しようとしてはいけない。高度なシンボリックソルバーを実装できる人間なら、それが機能しないことも当然わかる。そのアプローチを提案してきたなら、何か理由があると思うだろう。LLMだけが、これほど「賢くて、かつ愚かである」ミスを犯せる。

この指摘はLLMと仕事をするエンジニアにとって実践的な示唆を含む。LLMがどこで成功し、どこで失敗するかを事前に予測できれば、得られる価値は大きい。予測できなければ、無駄なトークンと時間を費やし続けることになる。

なお、元記事の脚注では別の事例も紹介されている。あるユーザーがOpus(Claude)に対してジャッジモデルを使うよう「暗示」したところ、エージェントはジャッジモデルではなく一連の正規表現チェックを構築し始めたという。LLMに対してAI的なアプローチを「ほのめかす」だけでは不十分であり、明示的に指示しなければ非AI的な手段に回帰してしまうことを示す好例だ。


詳細はLLMs are terrible at designing AI systemsを参照していただきたい。