ソートリーダー
LLMファーストかコードファーストか？ 生産AIにおけるインテリジェンスの所在
Unite.AI を Google の優先ソースに追加
モデルが処理すべきこと、コードが処理すべきこと、そしてそれらをどう接続するかを決める方法。
数年前、AIアプリケーションのアーキテクチャは次のようなものでした：プロンプトを大規模言語モデルに送信 -> 応答を取得 -> ユーザーに表示する。現在ではそれだけが全てではありません。モデルは意図を解釈し、情報を取得し、ツールを選択し、APIを呼び出し、計画を立て、マルチステップのワークフローを実行するよう求められます。
その変化により、分野は二つに分かれました – LLM‑First または Code‑First
LLM‑First アーキテクチャでは、モデルが中心に位置し、次に何が起こるかを決定します。リクエストを読み取り、ツールを選択し、操作の順序を決め、途中結果をチェックし、必要に応じて方針を変更します。
Code‑First アーキテクチャでは、ソフトウェア／コードがシーケンス、ビジネスルール、バリデーション、権限、実行を担当します。ここでの LLM は、言語の理解や生成が必要なときにコードから呼び出される専門家のようなものです。
どちらが優れているかについて議論するのが好きな人は多いです。しかしそれは間違った論点だと思います。より重要な問いは、各種インテリジェンスがどこに位置すべきかです。私が見た最も強力な本番システムは、決して純粋にどちらか一方だけではありません。確率的推論と決定論的制御を組み合わせており、その組み合わせは意図的に行われています。
LLMファーストが魅力的な理由
要件を明示できる場合、従来のソフトウェアはうまく機能します。たとえば、ユーザーが商品を選び、金額を入力し、支払いを送信するという流れです。許容される状態、バリデーションルール、エラー条件、取引シーケンスをコードで定義します。これで完了です。
自然言語はそう簡単に協調しません。ユーザーが次のように入力すると想像してください：「異常に見える取引を見つけ、何が起きたかを説明し、最初に調査すべきことを教えて」
そのリクエストに対して固定された手順はありません。ここではシステムが「異常」とは何かを判断し、どのデータが重要かを特定し、場合によっては複数のツールを呼び出し、応答を評価し、利用者が使える説明を書き出さなければなりません。エンジニアチームやノーコードでも、事前にすべての表現や要望の組み合わせを予測することはできません。
ここでLLMは重要な役割を果たし、人間の言語と決定的サービスの間の柔軟な推論層として機能します。また、エージェントが大きな注目を集めている理由でもあります。 Google Cloud のエージェント AI アーキテクチャ ガイダンスは、エージェントをAIモデルが推論エンジンとして機能し、ツールが外部システムやデータにアクセスできるようにするアプリケーションと定義しています。
Anthropic の Building Effective AI Agents ガイダンスは私が繰り返し言及する区別です。あるワークフロー、モデルとツールはコードが定義したパスに従います。あるエージェント、LLMは自らのプロセスを指示し、ツールの使い方を決定します。同じガイダンスでは、問題を解決できる最もシンプルなアーキテクチャから始め、反射的にエージェント的複雑性を追加しないことが推奨されています。その助言は二度強調したいです。
「モデルに決定させる」ことの限界
モデルは何が起こるべきかを推論できますが、推論は規則を実行することとは同じではありません。
例えば金融ワークフローを考えてみましょう。LLM は「先月と同じ金額を同じベンダーに送金する」という指示を理解するのは得意かもしれません。しかし、送金が許可されているかを判断したり、規制上限を計算したり、口座所有権を確認したり、セキュリティポリシーを上書きしたり、取引を実行したりすべきでしょうか？
おそらくそうではありません。これらの作業は決定的で、テスト可能、監査可能、実行可能であり、まさに従来のソフトウェアが得意とする領域です。モデルがツールにアクセスできるようになるとリスクが高まります。 OWASP の生成 AI セキュリティ ガイダンスは警告します過剰なエージェンシーは重大なリスクとして位置付けられます：LLMベースのシステムにタスクが必要とする以上の機能、権限、または自律性を与えることです。テキストを生成するだけの奇妙または改ざんされた出力は一つの問題ですが、モデルが現実世界で行動できるようになると、はるかに大きな問題になります。
これらは、モデルが決して行動すべきでないという意味ではなく、モデルの自律性は決定論的な権限によって制限されるべきだという意味です。
コードファーストは依然として重要
AI の進化が速いため、従来のエンジニアリングが時代遅れだと感じやすいです。しかし、私は逆に主張します。AI は、優れた決定論的システムの重要性を高めるものであり、むしろ重要になります。
タスクが正確な再現性を要求する場合、コードは依然として適切な選択です。認証は最も単純な例です。モデルが誰かに管理者権限があるかを「推論」すべきではありません。アプリケーションは権威あるアイデンティティおよびアクセス管理システムに問い合わせるべきです。金銭計算、権利チェック、データバリデーション、規制制約、取引上限、スキーマバリデーション、そして不可逆的な処理にも同様です。これらはベストエスティメートではなく、明示的な契約が必要です。
これは、より広範なガバナンスの考え方と合致しています。 NIST AI Risk Management Framework は、組織に対し設計、開発、展開、利用の各段階で AI リスクを管理するよう求めます。その付随する Generative AI Profile は、リスクの程度に応じて、生成システムに追加の監視、文書化、レビュー、コントロールが必要になる可能性があると付け加えます。
そこで、すべての設計判断を2つの質問に分けると役立つと考えています。
何が起こるべきか？
そして
何が許容されるか？
LLM は最初の質問にしばしば役立ちます。決定論的システムが通常は二番目を担うべきです。
ハイブリッドパターン：確率的に推論し、決定論的に実行する
ほとんどのエンタープライズアプリケーションにとって実用的な答えはハイブリッドです。LLM は解釈と推論の層として機能し、決定論的サービスは実行と強制の層として機能します。
例を挙げます。AI アシスタントが開発者に一時的な API テスト環境の構築を支援し、開発者が次のように入力したとします。「顧客オンボーディングワークフロー用のサンドボックスを作って」。
LLM はそれを解釈し、どのワークフローが意図されているかを推測し、ドキュメントを読み、関連しそうな API を提案できます。しかし、実際に環境を作成することは自由形式の生成テキストに依存すべきではありません。コードは要求された API が存在するかを確認し、契約を検証し、認可をチェックし、リソース制限を強制し、承認済みの構成を生成してデプロイを実行できます。
大まかな分割は次のとおりです。
- LLM： 理解、推論、分類、提案、要約。
- コード： 検証、認可、計算、永続化、強制、実行。
それぞれが得意な作業を担当し、相手の強みを偽ることは求められません。
エージェントが強力になるほど、境界は重要になる
この分離は、アシスタントからエージェントへ移行するにつれて重要性が増します。誤った回答をするアシスタントは利用者に不便をもたらすだけですが、プロダクションへの書き込み権限を持つエージェントははるかに大きな混乱を引き起こす可能性があります。
修正策は必ずしも自律性を取り除くことではありません。自律性を段階的に追加しつつ、明示的な制御ポイントを維持することが重要です。 Googleのマルチエージェントシステムに関するガイダンスは、ビジネスクリティカルなシナリオにおいて、動的なAI動作と決定論的なセキュリティ制御、可観測性、明確に定義された自律性、そして人的監視を組み合わせることを推奨しています。
人的承認は、非公式な安全ネットではなく、ワークフロー自体に組み込むこともできます。 Microsoft’s agent framework documentation は、たとえば、要求された操作が人によって明示的に承認されるまでツール呼び出しを一時停止させることをサポートしています。
原則はシンプルです。行動の結果が大きいほど、その周囲の決定論的制御は強固であるべきです。
LLM にタスクを委任する前に自問すべき5つの質問
コンポーネントを LLM ファーストにすべきかコードファーストにすべきか判断する際、私は次の項目を検討します。
- タスクに客観的に正しい答えが1つだけありますか？ もしそうなら、決定論的なコードを選択すべきです。税金計算、権限付与、スキーマ検証は、モデルが今日異なる解釈をしたからといって変えるべきではありません。
- 曖昧な言語や非構造化情報が含まれますか？ その場合、LLM が実質的な価値を提供する可能性があります。
- モデルが誤った場合、何が起こりますか？ 会議の要約に適したアーキテクチャは、支払い開始に適したアーキテクチャとは大きく異なります。
- 出力は独立して検証可能ですか？ LLM が生成した計画は、決定論的ルールが実行前に結果のアクションをチェックできる場合、はるかに安全になります。
- 本当にエージェントが必要ですか？ 手順が既に分かっている場合、いくつかの的確な LLM 呼び出しを組み込んだ通常のワークフローの方が、通常はシンプルでコストも低く、テストや運用も容易です。
最後の質問は特に注目すべきです。エージェントは、すべてのステップを予測できない状況に対処できる点で強力です。しかし、もし 予測できる 場合、それらを無制限の推論問題に変えることは、知性を高めることなく変動性を増すだけです。
信頼性はアーキテクチャ上の特性であり、プロンプトではない
多くのチームは、信頼性向上をほぼ完全にプロンプトエンジニアリングで実現しようとします。プロンプトは重要ですが、全てを担うことはできません。
プロダクションシステムは、モデルの出力が時折不完全、形式が崩れ、予期せぬもの、あるいは単に間違っていると想定すべきです。OWASP Top 10 for LLM applications は、プロンプトインジェクション と 不適切な出力処理 を列挙しており、重要な習慣を強調します。すなわち、モデルの出力を下流システムへの信頼できない入力として扱い、自動的に実行すべき指示としては扱わないことです。
それにより、問いかけが変わります。「モデルに常にルールに従わせるプロンプトを書きたい」ではなく、「モデルがミスをした場合でもルールが破られないようにシステムを設計するにはどうすればよいか？」と問うべきです。
これはソフトウェアアーキテクチャの問題であり、プロンプトの問題ではありません。プロンプトはエージェントに未承認の操作を行わないよう指示できますが、認可サービスは実際にそれを阻止できます。この二つの制御は同等ではありません。
議論を超えて：インテントファーストシステム
これらすべてを考えると、LLMファーストとコードファーストの議論は第3の考え方、すなわちインテントファーストアーキテクチャへと向かっていると信じるようになりました。
インテントファーストシステムでは、アプリケーションはユーザーが何を達成しようとしているかを理解することから始まります。ここがLLMが最も価値を発揮する場所です。なぜなら人々は自分の欲求を正確に表現することが稀だからです。そこからシステムはその曖昧さを段階的に構造化された決定論的な操作へと変換していきます。
「顧客の支払い問題を解決してください」といったリクエストは、意図の理解、取引の取得、失敗理由の特定、解決策の提案、承認の要求、承認された操作の実行というパイプラインに変換される可能性があります。
これらの段階のうちいくつかは言語モデルの推論から恩恵を受けますが、他は固定サービスであるべきです。アーキテクチャは AI とコードのどちらが「勝つ」かで決まるのではなく、不確実性が許容できる場所で決まります。
結論
モデルが向上すれば、スタックのより大きな部分をモデルに任せたくなる誘惑があります。時にはそれが正しい判断になることもあります。他のシステムでは、最も洗練された設計は、意図的にモデルにより少ない権限を与えるものです。
最終的に、プロダクションAIエンジニアリングはインテリジェンスを適切な境界に配置することです。解釈、推論、統合、適応が価値を生む場面では言語モデルを使用し、一貫性、認可、精度、強制が重要な場面では決定論的ソフトウェアを使用します。その上で、狭く観測可能で十分にテストされたインターフェースを介して両者を接続します。
エンタープライズAIの未来は、純粋にLLMファーストでもコードファーストでもなく、不確実性がインテリジェンスを必要とする場面ではLLMを、確実性が制御を必要とする場面ではコードを用いる形になるでしょう。
この区別は、どのモデルを選ぶか以上に重要になるかもしれません。
