最近、エンジニアリングのバックグラウンドも持つ当社の経理アナリストの1人が、自分が構築している自動化について不満を漏らしに私のところへやってきた。
彼女の任務は、当社データベース内の請求書リストと、Stripeから出力したデータダンプを照合することだった。彼女の直感は、今日の多くの人と同じだった。エージェント型にしよう、というものだ。彼女はAIエージェントに指示を与え、プロセスを説明するスキルを書き、条件を追加し続けた。
数日後の彼女の結論はこうだった。「うまくいくこともあるが、まったく機能しないこともある」
AIエージェントを使って構築した経験があるなら、おそらくあなた自身も、似たような言葉を口にしたことがあるはずだ。
なぜこのようなことが繰り返されるのか。
ITリーダーは、AIによる成果を示すよう圧力を受けている。動くデモは注目と予算を集めるが、慎重なアーキテクチャは同じ緊急性を持って扱われることがほとんどない。そのためチームは、長く使えるものではなく、デモで見せやすいものを最適化する。そして、「AIそのものがシステムを動かすべきだ」という前提が静かに定着していく。
それは印象的なデモにはなり得る。だが、必ずしも持続的なシステムになるわけではない。
ひび割れは、アプリケーションがデモから数千件のトランザクションへ移行したときに現れる。コストは上がり、レイテンシー（応答遅延）は増え、同じ入力が常に同じ挙動を生むとは限らない。今日有効な請求書が、AIが同じ指示を異なる形で解釈したために、明日無効になってはならない。
企業が求めているのは予測可能なシステムである。したがって問いは、「AIにこれをどう動かさせるか」から、「このシステムのどの部分に本当に知能が必要なのか」へと移すべきだ。
AIを加える前にシステムを分解する
有効なアプローチは、AIシステムを2種類の構成要素に分けることだ。
決定論的な構成要素
期待される挙動を明確に定義できる領域である。データを検証する、形式を変換する、合計を計算する、レコードを照合する、APIを呼び出す、ビジネスルールを適用する、といった作業だ。
従来型のソフトウェアはこうした仕事に非常に適しており、LLM（大規模言語モデル）はその構築を容易にする。AIは自動化を書く手助けをできるが、実行時の一部になる必要はない。
判断駆動型の構成要素
これは、答えを事前に簡単には決められない意思決定である。情報が非構造化されている場合もあれば、文脈が重要になる場合、あるいは従来型のルールではエンジニアリングコストに見合わない場合もある。
これを「AIコンポーネント」ではなく「判断駆動型」と呼ぶことで、有益な問いが生まれる。ここで本当に知能が必要なのはなぜか、という問いだ。
AIは機械を作る助けとして使うべきである。自動的にAIそのものを機械にしてはならない。
考える必要がある領域を減らす
多くのアーキテクチャは、問題全体をLLMに送る。よりよい設計はその逆だ。システムのできるだけ多くを決定論的にし、事前定義されたルールが実用的でなくなる箇所だけで知能を使う。目標は、考える必要がある領域を縮小することにある。
AIレイヤーが小さくなれば、通常、トークン数は減り、レイテンシーは低下し、テストは容易になり、挙動はより予測可能になる。
すべてのタスクに最も賢いモデルが必要なわけではない。構造化された出力を自然言語に変換する、OCR（光学式文字認識）の結果を整理する、単純なリクエストを分類するなど、軽い知能だけで足りるものもある。一方で、複雑な財務情報を分析する、曖昧な要件からコードを生成する、競合する要素を比較検討するといった深い知能を要するものもある。
知能を要する各タスクについて、次のように問うべきだ。
• この意思決定にはどの程度の知能が必要か。
• どれくらいの頻度で実行されるのか。
• 誰がコストを負担するのか。
安価なモデル呼び出しでも、数百万回繰り返されれば大きな運用費になり得る。モデル選択は単なるAI上の判断ではない。ビジネスアーキテクチャ上の判断である。
経理の例に戻る
当社のアナリストのエージェントが信頼できないことがわかったとき、私は彼女に、プロセス全体を知的にしようとするのをやめるよう提案した。
彼女はすでに、スキルファイルの中に大半のシナリオを文書化していた。そこで、そのルールをエージェントに繰り返し解釈させるのではなく、AIを使ってそれらをスクリプトに変換する手助けをさせた。
決定論的なコードが2つのデータソースを共通形式に変換し、検証し、検証器を実行した。LLMに到達したのは、失敗したケースと通常とは異なるケースだけだった。
AIの役割はもはや照合を実行することではなかった。例外を調べ、人間の言葉で説明することだった。
2日目の終わりまでに、ワークフローのおよそ95%は決定論的になった。知能は有用な場所に集中し、プロセスは再現可能になった。
教訓は単純だった。
最良のエージェント型システムとは、ほんの少しだけエージェント型であるシステムかもしれない。
AIを脳のように考える
人間の体には強力な脳があるが、脳が心拍や反射の一つひとつを意識的に決めているわけではない。予測可能な機能は専門化されたシステムが担い、判断が必要なときに脳が関与する。
自動車も同様である。エアバッグを作動させるべきかを生成AIに判断してほしいとは思わない。安全システムは予測可能に動作しなければならない。知能が有用になるのは、環境が不確実な場合である。
そして、信号機を青にすべきかどうかを数秒ごとにLLMへ尋ねる都市もない。
複雑なシステムが成功するのは、すべての構成要素が知的だからではない。知能が適切な部分に配置されているからだ。企業のAIも同じように機能すべきである。
マクロからミクロへ設計する
AIエージェントを構築する前に、ビジネスプロセスをより小さなプロセスへ分解し、さらに個々の意思決定へと分解する。
各意思決定について、こう問うべきだ。これは決定論的にできるか。
答えがイエスなら、決定論的にする。そうでない場合は、どのレベルの知能が必要かを問い、その後で初めてモデルを選択する。
当社は、今後提供予定のAIベースのSaaSプロダクトを構築する際にも、同じ原則を適用している。現在のアーキテクチャ上の見積もりでは、決定論的な実行と実行時の知能を切り分けることで、初期のアプローチと比べ、想定されるトークン消費量を約90%削減できる可能性がある。
正確な削減幅はさまざまだが、より大きな利点はアーキテクチャの明確さにある。テスト、監視、スケーリング、信頼が容易になるのだ。
AIはソフトウェア工学を置き換えるのではなく、補完すべきだ
実験は重要である。しかし、それはいずれエンジニアリングへと移行すべきだ。
目標は、可能な限り自律的なシステムではなく、最も信頼できるシステムであるべきだ。
知能は、それが不釣り合いなほど大きな価値を加える場所にだけ使うべきである。
それがエージェントを意味する場合もある。LLMによって生成され、何年にもわたり決定論的に実行される単なるスクリプトで十分な場合もある。
予測不能な挙動、高いトークン消費量、あるいはデモでは輝くが本番環境ではつまずくエージェントに苦しむ企業にとって、答えは別のプロンプト、エージェント、モデルではないかもしれない。時には、システムに対してもう一度アーキテクチャの観点から見直しをかけるだけでよいこともある。
最も有用な問いは、最も単純な問いかもしれない。
このシステムのどの部分に、本当に考える必要があるのか。
