# AIエージェント開発の意思決定ポイント 🎯 ポイント 税額計算をLLMにやらせていませんか？ AIエージェント開発で最もよくある間違いの一つは、コードで一瞬で解ける処理をLLMに推論させてしまうことです。トークンの浪費、結果の不安定、デバッグ困難。逆に、自然言語の解釈まで全部if-elseで書こうとして、エッジケースの爆発に溺れるのも同じくらい危険。LLMとコード、どちらに任せるかの線引きを明確にしましょう。 📋 概要 AIエージェントの各処理ステップについて「LLMに自然言語で推論させるか、従来のコードやツールに委譲するか」という設計判断です。LLMは確率的で同じ入力に異なる出力を返す可能性がありますが、曖昧な入力の解釈や未知のケースへの対応に優れます。コードは決定論的で常に同じ結果を返し、テストも容易ですが、事前に想定していないケースには対応できません。この非対称性を正しく活用することが、信頼性とコスト効率を決定づけます。 🔍 意思決定のポイント 判定のヒューリスティックは単純です：「if-elseで書けるか？」 📌 ルール・手順・アルゴリズムで完全に記述できる → コードに委譲。税額計算、在庫集計、日付比較、スキーマ検証、フォーマット変換。これらをLLMに任せるのはトークンの浪費であり、しかも誤る可能性があります。LLMは算術演算や正確な文字列操作が苦手です。 📌 入力が自然言語で意図の解釈が必要 → LLMに推論させる。ユーザーの曖昧な要求を構造化する処理はLLMの得意分野。「明日の会議をリスケして」の「明日」がいつで「リスケ」が何を意味するかの解釈はif-elseでは対応しきれません。 📌 分類のカテゴリが動的に変わる、判断基準が文脈依存 → LLM。事前にすべてのケースを列挙できない場合、コードではエッジケースの爆発が起きます。 📌 生成・要約・翻訳など創造性を伴う処理 → LLM。これらはコードでは実現できません。 📌 計算結果の誤りが許されない → コード必須。金融計算、権限判定、在庫管理。確率的なLLMに任せるべきではありません。 💡 要点と詳細 🔹 LLMは「何をすべきか」の判断に優れ、コードは「どうやるか」の実行に優れます。この非対称性がエージェントシステムの設計原則です。LLMが計画・分類・解釈を担当し、コードが計算・検証・実行を担当する分業が最も一般的で効果的な構成です。 🔹 見極めの基準は「入力が決まれば出力が一意に決まるか」です。一意に決まるなら、それはコードの仕事です。計算、検索、フォーマット変換、バリデーション、データベース操作はすべてコードに分類されます。 🔹 LLMに任せすぎた場合の典型症状：同じ入力で異なる結果が返り「前回と結果が違う」というクレーム。トークン消費量が想定を大幅超過し、分析するとコードで代替可能な処理に費やされている。テストのフレーク率が高くCI/CDが不安定。 🔹 コードに任せすぎた場合の典型症状：新しいタイプのリクエストが来るたびに分類ルールやパーサーの追加が必要で開発速度が低下。if-elseの積み重ねが肥大化し保守困難。想定外の入力に一律エラーを返し、本来対応可能な要求を棄却。 ⚖️ トレードオフ LLMは柔軟性と汎用性を得る代わりに、再現性・コスト・デバッグ容易性を犠牲にします。コードは決定論性と効率性を得る代わりに、柔軟性を犠牲にし、新しいケースへの対応にコード追加が必要です。 🏆 デフォルトは「決定論的に解ける処理はコードに委譲」。LLMはコストが高く、結果が不安定で、デバッグが困難です。LLMに任せるのは「コードでは解けない」処理に限定するのが原則。これは「確率的な判断をLLMに、決定論的な制御をコードに」という設計思想の根幹です。 🛠️ ユースケース 🧮 経費精算ボット → ハイブリッド。領収書画像からの情報抽出と経費カテゴリの判定はLLM。税額計算、合計算出、経費規定との照合はコード。 🔍 カスタマーサポート → ハイブリッド。ユーザーの問い合わせ意図の分類はLLM。注文状況の検索、返金処理の実行、在庫確認はコード（API/DB呼び出し）。 📊 データ分析アシスタント → ハイブリッド。「先月の売上を地域別に比較して」の意図解釈はLLM。実際のクエリ生成・実行・集計はコード。結果の要約と解釈はLLM。 ⚠️ アンチパターン：LLMに「123 × 456を計算して」と聞く。LLMは算術が苦手で間違えることがあります。こんな処理は`123 * 456`の1行で確実に正解が出ます。 #AIエージェント# #ソフトウェアアーキテクチャ#