LLMを実務の「決定エンジン」にするための泥臭いエンジニアリング戦略

多くのエンジニアが、LLMを導入した瞬間に「魔法のような自動化」が完成すると錯覚している。しかし、現実はそう甘くない。Jendrik Jördening氏が指摘するように、LLMを単なるチャットボットとしてではなく、データベースのIDを選択するような「決定エンジン」として組み込もうとした瞬間、我々は『モデル・ビュー・コントローラー（MVC）』の境界が崩壊する悪夢に直面する。かつてPandasでデータフレームを操作し、決定木や回帰モデルで明確なargmaxを叩き出していた時代とは異なり、LLMは確率的な生成物であり、その出力は常に「揺らぎ」を孕んでいる。

我々が直面する最大の技術的負債は、LLMの出力が「文字列」であるという点だ。データベースの外部キー制約や一意性制約を維持しなければならないシステムにおいて、LLMが生成した曖昧な文字列をそのままクエリに流し込むことは、深夜の障害対応を自ら予約するようなものだ。特に、コンテキストウィンドウの肥大化は致命的だ。過去の履歴をすべてプロンプトに詰め込めば、モデルは「ハルシネーション」という名の無限ループに陥り、本来存在しないはずのIDや、文脈を無視したランダムな数値を平然と出力する。これは単なる精度の問題ではなく、システム全体の整合性を破壊する「データ層の汚染」である。

さらに、セキュリティの観点からも無視できないリスクがある。プロンプトインジェクションによって、本来の業務ロジックが上書きされ、承認フローがバイパスされるリスクは、コンプライアンスを重視するエンタープライズ環境では致命的だ。Jördening氏が強調するように、LLMを「知識ベース」として信頼してはならない。知識はデータベースに格納し、LLMにはそのデータベースのインデックスを引かせるための「インターフェース」としての役割のみを期待すべきなのだ。我々エンジニアは、LLMを「賢い脳」として崇めるのではなく、極めて不安定で気まぐれな「非決定的な関数」として扱い、その出力をいかにして決定論的なコードでラップするかに全力を注ぐべきである。

LLMをプロダクション環境に投入する際、まず最初に行うべきは「ルール0：非決定性の排除」である。これは単なるスローガンではない。温度パラメータ（temperature）を0に設定し、ランダムシードを固定することは、エンジニアリングにおける最低限の礼儀だ。しかし、それでもなおLLMは裏切る。Jördening氏がDeutsche Bahnの遅延証明自動化プロジェクトで経験したように、同じプロンプトでも実行タイミングによって出力が変わるという事実は、分散システムにおけるデッドロックよりも厄介なバグを生む。

この問題を解決するための具体的な戦略は、LLMの出力を「構造化」することに尽きる。かつて我々がJSONのパースに費やした膨大な時間は、今やStructured Outputsという技術によって解決されつつあるが、それでもなお「モデルに何をさせるか」の設計が重要だ。以下の表は、LLMをシステムに統合する際に我々が直面する「決定論的アプローチ」と「LLMアプローチ」の対比である。

重要なのは、LLMに「知識」を求めず、「変換」を求めることだ。例えば、駅名からEVA番号（8桁の識別子）を特定させる際、モデルの内部知識に頼るのではなく、駅名と番号のリストをプロンプトに含め、そこから選択させるという「RAG（Retrieval-Augmented Generation）の極小版」のようなアプローチが不可欠となる。モデルに「推論」させるのではなく、「与えられた選択肢の中から最も適切なIDを抽出」させる。この「抽出」というタスクに限定することで、LLMのハルシネーションを劇的に抑制できる。

また、コードの管理についても言及しておく必要がある。CursorのようなAIコーディングツールが普及した今、我々のリポジトリは「AIが生成したコードの断片」で溢れかえっている。Jördening氏が「make 0, 1, 2…」とスクリプトを番号付けして管理せざるを得なかったように、AIが生成したコードをそのまま放置することは、スパゲッティコードを量産する行為に他ならない。AIが書いたコードであっても、それをレビューし、テストし、クリーンアップするのは我々エンジニアの責任だ。AIは「コードを書く速度」を加速させるが、「コードの品質」を保証するわけではないという冷徹な事実を忘れてはならない。

結局のところ、LLMをプロダクションに組み込むということは、我々がこれまで培ってきた「決定論的なソフトウェア工学」と「確率的なAI」の間の溝を埋める作業に他ならない。多くの企業がAI導入を急ぐあまり、LLMをブラックボックスとして扱い、その結果として「なぜか動くが、なぜか壊れる」という最悪のシステムを構築している。銀行のCEOがAI導入を理由に数千人の労働者を「低価値な人的資本」と切り捨てるようなニュースが流れる中、我々エンジニアに求められているのは、AIに仕事を奪われることへの恐怖ではなく、AIという「不安定な部品」をいかにして堅牢なシステムの一部として組み込むかという、極めて高度なアーキテクチャ設計能力である。

明日からあなたが取るべき処方箋は明確だ。まず、LLMの出力を「信頼できる情報源」として扱うことを即座にやめること。すべてのLLM出力は「未検証の入力」として扱い、必ずバリデーション層を通すこと。次に、LLMの推論過程を可視化し、監視するための「オブザーバビリティ」を構築すること。MCP（Model Context Protocol）のような新しい標準が登場しているが、それらもまた、既存の監視ツールやログ基盤と統合できなければ、ただの「追跡不可能なブラックボックス」を増やすだけだ。

我々は今、ソフトウェア開発の歴史において、かつてアセンブラから高級言語へ、あるいはモノリスからマイクロサービスへと移行した時と同じような大きな転換点に立っている。しかし、今回の変化は「コードを書く」ことよりも「システムを制御する」ことの難易度を飛躍的に高めている。AIが生成したコードや推論結果を、我々が責任を持って制御できるか。それとも、AIの気まぐれに振り回され、深夜の障害対応に追われ続けるのか。問いはシンプルだ。あなたはAIを「制御」しているか、それともAIに「制御」されているか。この問いに対する答えが、今後数年間のあなたのエンジニアとしてのキャリアを決定づけることになるだろう。