7月22日、Cameron Palmerが「Should you even use an LLM?」と題した記事を公開した。Palmer氏はAI実装コンサルタントとして、自身のリード発掘システムで痛烈な失敗を経験した——LLMエージェントに処理を丸投げした結果、800件以上のリードを手作業で確認し直す羽目になったという。この記事では、その教訓をもとに構築された「LLMを導入すべきか」を判断するための6つの問いからなる意思決定フレームワークが詳しく紹介されている。
LLM任せで生じた800件の手作業——失敗から生まれたフレームワーク
Palmer氏が最初に構築したリード発掘システムは、Webサーチ・重複排除・バリデーション・CRMへの挿入という一連のパイプラインを1つのLLMエージェントに丸投げする設計だった。結果として、発掘したリードの10〜20%が不正確・重複・不適切な形で登録され、800件以上のリードを手作業で確認し直すことになった。エージェントが実行のたびに異なるアプローチを取るため、デバッグも極めて困難だった。
この失敗の根本原因は、「どこにAIを適用できるか？」という問いから始めたことにある。正しい順序は「何の問題を解くのか？」を先に定め、その後に適切なツールを選ぶことだ。
LLMの本質的な特性として、柔軟性と引き換えに決定論性（determinism）を犠牲にする点がある。決定論性とは「同じ入力を与えれば必ず同じ出力が返る」性質のことで、従来のプログラムが備えているこの特性をLLMは持たない。同じプロンプトを同じモデルに2回投げれば、明確に異なる結果が返ってくることがある。テストや障害分析が難しいのはこのためだ。
6つの問い：LLMを使う前に確認すること
フレームワークの核心は以下の6問だ。これらを順番に問うことで、LLMが本当に必要かどうかが整理できる。
1. ワークフロー全体を事前に完全に定義できるか？
できるなら、LLMは不要かもしれない。CI/CDパイプラインのように、実行前に全ステップが確定するケースは典型例だ。
2. 同じ入力に対して同じ出力が必要か？
LLMは非決定論的だ。決済システムのように同一請求に対して同一の計算結果を返さなければならない場合、LLMは適さない。
3. 実行中に生じる曖昧さの解釈が必要か？
これがLLMの最も強い領域だ。ただし「実行前に解消できる曖昧さ」は対象外で、事前に整理してからプレーンなコードを使うべきだ。
4. 出力結果を安価かつ正確に検証できるか？
コードはテストで即座に検証できる。一方、医療診断の正確性確認や「この事業戦略は成功するか？」という問いへの答えは、検証に専門知識や長い時間を要する。検証コストが高い用途はLLMに向かない。
5. 出力が間違っていたときの影響は何か？
「もし」ではなく「いつ」の問題として考える。15ドルの誤割引と5000ドルの誤割引では影響の深刻さがまるで違う。また、LLMを「顧客に直接割引を与えるボット」ではなく「人間のサポート担当者にアドバイスするボット」として設計すれば、誤りの影響を一段緩衝できる。
6. LLMベースの解決策は、シンプルな代替案を大幅に上回るか？
Palmer氏が推奨するのはKISS原則（Keep It Simple, Stupid）だ。「シンプルに保て、バカになるな」とも訳されるこの設計思想は、ソフトウェアエンジニアリングの世界で長く参照されてきた原則であり、複雑さはバグとコストの温床になるという考え方に基づく。コードベースの代替案が品質（エラー率・コスト等）の95%を達成できるなら、そちらを選ぶべきだとしている。
実例：自分のリード発掘システムへの適用
Palmer氏は自身のシステムにこの6問を当てはめ、LLMを「曖昧さが存在するステップのみ」に絞り込んだ。
| ステップ | LLMが必要か |
|---|---|
| 検索クエリ生成（既存リードのギャップを読んで生成） | 必要（曖昧さあり） |
| 検索実行（Decodo Search経由） | 不要（決定論的） |
| 重複排除 | 不要（決定論的） |
| CRMへの挿入 | 不要（決定論的） |
| バリデーション（理想顧客に合致するか） | 必要（自然言語の判断） |
検証についても「名前・会社・役職を10秒見れば判断できる」という低コストな確認が可能なため、LLM活用に適した領域と判断している。
この設計思想はLLMエージェントの設計論として近年注目を集めており、「エージェントにどこまで任せるか」という境界設定の問題は、Anthropicのエージェント設計ガイドラインでも中心的なテーマとして扱われている。Palmer氏のアプローチはその実践的な一例として位置づけられる。
結論：LLMと決定論的コードを組み合わせる
Palmer氏の結論は「LLMを使うかどうかは二者択一ではない」だ。現実の解決策の多くは、LLMと決定論的コードの組み合わせになる。LLMは曖昧さが存在するステップに限定して使い、残りはプレーンなコードで処理する——この設計思想が、デバッグ可能でコスト効率の良いシステムを生む。
「AIファースト企業」という看板を掲げることではなく、適切な問題に適切なツールを使うことが目標であるべきだ、というのが記事の主張だ。
詳細はShould you even use an LLM?を参照していただきたい。
