賢い方に道を作らせる:ローカルLLMを含んだシステムの詰まない設計

ローカルLLMという言葉を聞いても、中小企業の実務者には何のことか分かりにくいはずだ。簡単に言えば、データを社内に保ったまま動かせるAIのこと。クラウドのGPTやClaudeに丸ごとデータを送らない、という選択肢である。理由は二つ。顧客情報や経営数字を外に出したくない。呼び出し費用が高い。この制約の中で、経営判断を支援するシミュレータを、繰り返し試行錯誤させたいわけだ。

ここで詰まる。ローカルLLMの推論能力は最先端モデルに遠く及ばないからだ。だから自分で設計するなら、プロンプト、ツール、エージェント構成を緻密にチューニングする必要がある。しかし「何が足りないのか」を見つけるのが極めて難しい。設計者の頭には全体像があるから「こうすればいい」は明白に思える。けれど、その明白さは渡したプロンプトとツール定義の中に実は無いのだ。エージェント（システム側のAI）は、渡された文面だけから選ぶしかない。足りなければ選べず、与えすぎれば選ぶ精度が落ちる。必要十分な一点を狙わねばならないのに、その一点を見つける手段に乏しい。

一方、コーディングエージェント（AIプログラマ）に任せればどうか。それらしく作ってくれるが、実務で回すとボロボロだ。仕様書を書いて設計するフィードフォワード方式では、ローカルLLMの推論能力の低さを補い切れない。設計空間が広すぎるまま評価ループに入れると、エージェントは「何を変えるべきか」を探索することに苦労し、改善が収束しない。解決の鍵は、コーディングエージェントに「設計軌跡」をあらかじめ渡すことだという。つまり、ローカルLLMを使ったシステム設計の手順書を与えたうえで、評価ループを回させる。ブラックボックスではなく、中身が見える状態で、段階的に設計させるわけだ。これは技術者向けの話に見えるが、中小企業にとっての含意は単純だ。ローカルLLMの道を選ぶなら、単なるプロンプト工夫では足りない。設計思想の手取り足取りまで必要になるということ。費用と手間のバランスを見直す時機が来ている。