AIエージェントの過剰設計：「GPU代付きif文」の現実とコスト構造
プロダクション環境に展開されているAIエージェントのうち、実質的にGPUコストを伴う単なる条件分岐に過ぎないケースが少なくない、という指摘が近年開発者コミュニティで話題になっている（Half the AI agents in production are if-statements with a GPU bill）。
ここでいう「if文」とは、入力データが固定フォーマットであり、出力も明確に定義されている処理のことだ。メールアドレスの抽出、顧客IDの照合、金額に応じた承認フローの分岐——これらは本来、正規表現やSQL、条件分岐で十分処理できるタスクである。にもかかわらず、多くのプロダクションシステムではこれらの処理にLLM推論を介在させており、毎回の呼び出しでトークン単価分のGPUコストが発生している可能性がある。
この現象の背景には、技術選定の動機が「業務要件の最適解」ではなく「履歴書に載せる華やかさ」に偏っている構造的問題がある。エージェントフレームワークやベクターデータベースを設計に組み込むことで、採用活動時に差別化できる——いわゆる「履歴書駆動型AIエンジニアリング」（Resume-Driven AI Engineering）が、本来不必要なLLM依存を生み出しているという指摘もある（同記事）。
LLMは構造的に確率的な出力を持ち、同じ入力に対しても異なる応答を返す可能性がある。また、推論には数百ミリ秒から数秒の遅延が伴う。決定論的な処理——つまり「同じ入力には必ず同じ出力」が求められる処理——にこの特性を持つモデルを適用することは、品質面では再現性の欠如を、コスト面では不要なGPU利用を生む、という二重の非効率を意味する。
本記事では、この過剰設計を是正するための設計指針を提示する。LLM推論が本当に必要なケースと、既存の決定論的技術で十分であるケースを明確に分離し、コストと堅牢性の両立を実現する方法を、具体的な実装パターンとともに解説する。
設計指針の前提：LLMと既存技術の棲み分け原則
LLMはデフォルトの選択肢ではない。構造化されていないテキストの解釈、曖昧さの許容と解決、文脈依存の意味的推論——これらの特性がタスクの本質的な要件として存在する場合にのみ、LLMの適用が正当化される（同記事）。
この原則を具体的な技術選定に落とし込むと、以下の4つの判断基準が得られる。
固定フォーマットのデータ抽出 → 正規表現
入力データが既知のフォーマットを持つ場合（メールヘッダー、APIレスポンス、ログ行など）、正規表現による抽出が確実・高速・無償である。LLMに「このテキストからメールアドレスを抽出して」とプロンプトを与える必要はない。パターンが固定されている以上、re.searchや言語標準ライブラリの正規表現機能が同等以上の品質を、GPUコストゼロで提供してくれる場合が多い（同記事）。
事実ベースの検索 → SQL
顧客ID、日付、ステータスコードなどの事実属性による検索は、ベクターデータベースによる類似度検索ではなく、インデックス付きのSQLフィルタリングが適切である（同記事）。顧客ID「C-2024-00382」を「探す」のに、埋め込み空間での近傍探索を行うのは、正確さが求められる検索に対して不自然な設計だ。
明確な分岐ロジック → 決定木
業務ルールが「金額が50万円以下なら課長承認、50万円超なら部長承認」のように明確に定義されている場合、自律型エージェントにこの判断を委ねる理由はない。決定木やif-elseで実装すれば、実行パスが一意に定まり、デバッグと監査が容易になる（同記事）。
| 判断軸 | LLM適用が正当化されるケース | 既存技術で十分であるケース |
|---|---|---|
| 入力データ形式 | 自由記述・非構造化テキスト | 固定フォーマット（CSV、JSON、ログ） |
| ロジックの明確さ | ルールが未定義・文脈依存 | 条件が明文化可能 |
| 求められる出力 | 要約・分類・意味的解釈 | 正確な一致・抽出・分岐 |
| コスト・速度 | トークン課金＋数百ms〜数秒 | 無償・ミリ秒以下 |
この表を設計レビュー時のチェックリストとして用いることで、「なぜこの処理にLLMを使っているのか」という問いに明確に答えられない箇所を特定できる。答えられない箇所が、リファクタリングの候補となる。
データ抽出層：正規表現とSQLによる決定論的処理の実装
データ抽出層は、生データ（メール本文、ログ、APIレスポンス）からLLMが消費する構造化データへの変換を担う層である。この層でLLMを介在させると、後続の推論精度がノイズに汚染されるだけでなく、前処理自体にコストと遅延が発生する。
正規表現による固定フォーマット抽出
メールヘッダーからメールアドレスや契約IDを抽出する場合の実装例を示す。
import re
def extract_contract_id(raw_text: str) -> str | None:
"""メール本文から契約ID（例: CT-2024-00382）を抽出する"""
match = re.search(r'CT-\d{4}-\d{5}', raw_text)
return match.group(0) if match else None
def extract_email_addresses(raw_text: str) -> list[str]:
"""メール本文からメールアドレスをすべて抽出する"""
# 簡易的な正規表現パターン。実際の運用ではRFC 5322準拠のパターンやライブラリを検討すること
return re.findall(r'[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}', raw_text)この実装はGPUコストがゼロであり、実行時間はミリ秒以下である。また、正規表現のパターンはコードレビューで検証可能であり、単一ケースに対するユニットテストで完全にカバレッジを確保できる。LLMのプロンプトでは「99%は正解だが1%でハルシネーションする」では済まされない、正確性が求められる抽出処理には、この決定論的アプローチが適切だ。
SQLによる事実ベースの照合
抽出した契約IDをもとに、データベースから顧客情報を取得する段階では、ベクター検索ではなくインデックス付きのSQLが適する。
SELECT customer_id, customer_name, contract_status, contract_amount
FROM contracts
WHERE contract_id = $1;顧客IDや日付のような事実属性の検索は、埋め込み空間での類似度探索ではなく、B-treeインデックスによる正確な一致検索が本来の設計である。ベクターデータベースをこの用途に使うと、検索精度が「似ている」に留まり、正確性が求められる業務処理では許容できない誤検出リスクが生じる。
flowchart LR
A["生データ（メール・ログ・API）"] --> B{"フォーマットが固定か？"}
B -->|Yes| C["正規表現 / 標準ライブラリで抽出"]
B -->|No| D["LLMによる意味的抽出"]
C --> E["構造化データ（JSON）"]
D --> E
E --> F{"事実属性の照合か？"}
F -->|Yes| G["インデックス付きSQLで検索"]
F -->|No| H["LLM推論へ"]
G --> I["後続処理"]
H --> I
このパイプラインの設計思想は「LLM呼び出しを最小化」することにある。固定フォーマットのデータは正規表現で処理し、事実照合はSQLで処理し、LLMはそれでは処理できない非構造化・曖昧なケースにのみ到達させる。これにより、LLMへの入力データがノイズの少ない構造化データとなるため、後続の推論精度向上にも寄与する。
ロジック層：決定木とif文による分岐の明確化
業務ルールが明確に定義されている場合、判断の根拠はコードで記述可能な条件式に還元できる。例えば「金額が50万円未満なら自動承認、100万円未満なら部門長承認、それ以上なら経営陣承認」といった承認フローは、if-else文で完全に表現可能である。この種の処理をLLMに委ねると、プロンプトの微調整や温度パラメータの設定変更によって予期せぬ分岐が生じるリスクが常につきまとう。一方、コード上の決定木は実行パスが一意に定まり、どの入力がどの分岐を通ったかをログから直接追跡できる。
自律型エージェントの根本的な課題は、判断の透明性の欠如にある。エージェントが「なぜそのアクションを選んだか」を事後に説明させるには、追加の推論呼び出しが必要になり、コストとレイテンシが二重に発生する。対して決定論的なコードでは、スタックトレースと入出力のログだけで因果関係が完全に再現される。監査対応や障害時の根本原因分析において、この差は実務上無視できない。
実務上推奨されるのは、「LLMは最後の砦」として位置づけるアーキテクチャである。ルールエンジン（決定木）で処理可能なケースはコードで処理し、ルールでカバーできない例外ケースのみをLLMへ迂回させる。これにより、通常時の処理コストはゼロに近づき、LLMの出力品質がシステム全体に与える影響範囲も最小限に抑えられる。
flowchart TD
A["業務リクエスト"] --> B{"金額が50万円未満か？"}
B -->|Yes| C["自動承認"]
B -->|No| D{"金額が100万円未満か？"}
D -->|Yes| E["部門長承認"]
D -->|No| F{"ルールでカバーできない例外か？"}
F -->|Yes| G["LLMによるケース分析"]
F -->|No| H["経営陣承認"]
G --> I["承認フローへ"]
H --> I
この構造の利点は、LLMの出力が「承認の可否」ではなく「例外の分類と推奨アクション」に限定される点にある。LLMの確率的な出力が直接ビジネス判断に接続されるのを防ぎ、最終的な承認は人間またはコードが行う。この分離により、LLMの出力品質に起因する障害の爆炸半径を制御できる。
実装パターン：LLM不要なエージェントの設計例
以下は、固定フォーマットの請求書テキストからフィールドを抽出し、金額に応じた承認フローを決定する最小実装例である。Pythonの標準ライブラリのみを使用しており、外部依存もGPU推論も不要である。
import re
def parse_invoice(raw_text: str) -> dict:
"""固定フォーマットの請求書テキストからフィールドを抽出する"""
contract_id = re.search(r"契約ID[:\s]*([A-Z]{2}\d{6})", raw_text)
amount = re.search(r"金額[:\s]*(\d+(?:,\d{3})*)円", raw_text)
if not contract_id or not amount:
raise ValueError("必須フィールドが検出されませんでした")
return {
"contract_id": contract_id.group(1),
"amount": int(amount.group(1).replace(",", "")),
}
def determine_approval(amount: int) -> str:
"""金額に応じた承認フローを決定する"""
if amount < 500_000:
return "auto_approve"
elif amount < 1_000_000:
return "dept_head"
else:
return "executive"
def process_invoice(raw_text: str) -> dict:
fields = parse_invoice(raw_text)
fields["approval_route"] = determine_approval(fields["amount"])
return fields
この実装がもたらす効果は具体的である。まずGPU費用を回避できる可能性がある。LLM推論の呼び出しが存在しないため、トークン単価に基づくコストが発生しない。次にレイテンシが短縮される傾向にある。正規表現のマッチングと整数比較はCPU上で高速に完了し、LLM推論の数百ms〜数秒という待ち時間が消える。
テスト容易性の面では、この設計は決定論的であるためユニットテストで高いカバレッジを達成できる。parse_invoiceには正常系・不正フォーマット・境界値を、determine_approvalには各閾値の前後の値を入力すれば、すべての分岐を網羅できる。LLMベースの実装では、同じ入力でも出力が揺れ動くため、テストの再現性を保つためにモックや固定シードが必要になる場合があり、テスト自体の保守コストが増大する可能性がある。
さらに、この実装に必要なのは正規表現の基礎知識と条件分岐の理解である。既存のWeb開発やバックエンド開発のスキルがそのまま活きるため、チーム内にLLMの専門知識を持つ人材がいない場合でも、実装と保守を既存メンバーが担える可能性がある。これはPoC段階で「AIチームを立ち上げる必要がある」という前提を見直す、実務上重要なポイントである。
LLMを適用すべきケース：曖昧さと推論の必要性
前述の除外基準——固定フォーマット、事実照合、明確な分岐ルール——のいずれにも該当しないタスクこそ、LLMの適用が検討される領域である。具体的には、以下の3つが代表的である。
第一に、感情分析である。顧客からのクレームメールやレビューテキストは、文脈・比喩・皮肉・文脈依存のニュアンスを含む。これらの意味的解釈を正規表現で実現するには、膨大なパターンを列挙する必要があり、未知の表現に対しては漏れが発生する可能性がある。LLMは文脈全体を考慮して感情の方向性と強度を推論できる点で、この種のタスクに適している場合がある。
第二に、自由記述の要約である。営業担当が自由に記述した商談メモや、形式がばらばらの顧客対応ログから、構造化されたサマリーを生成する処理は、入力フォーマットが固定されていないため正規表現では処理不可能である。また、要約には「何を重要視するか」の文脈依存な判断が伴うため、決定木でも表現しきれない。
第三に、多様な形式からの意味的抽出である。PDF、メール、チャットログなど形式が異なる複数ソースから、同じ意味を持つ情報を統合して抽出する処理は、形式ごとに正規表現を書くだけでは対応できない場合がある。LLMは形式の違いを吸収して意味レベルで情報を統合できる可能性がある。
LLMを適用する場合のコスト管理として、実務で有効な手法が2つある。一つはキャッシュ戦略である。同じ意味の問い合わせが繰り返し発生する場合は、過去の推論結果をキーでキャッシュし、LLM呼び出しを省略する可能性がある。もう一つはモデルの段階的活用である。簡単な分類タスクには軽量モデルを使い、複雑な推論のみを高性能モデルに委ねることで、平均コストを下げる余地がある。これらの最適化は、LLMを「デフォルト」ではなく「必要な箇所だけ」に限定する設計思想と相乗的に機能する可能性がある。
設計判断のトレードオフ：柔軟性 vs 堅牢性
前述の設計指針を適用するにあたり、避けて通れないのが「柔軟性」と「堅牢性」のトレードオフである。LLMベースの設計は、プロンプトの修正だけで処理内容を変更できるため、ルールが頻繁に変化する探索フェーズでは有利に働く場合がある。一方、出力が確率的である以上、同じ入力に対して異なる結果が返る可能性があり、本番環境での予測可能性は構造的に低い傾向にある。決定木やif文ベースの設計は、実行パスが一意に定まるため監査とデバッグが容易だが、ルール変更にはコード修正と再デプロイを伴う。この対立を「どちらが優れているか」で判断するのではなく、プロジェクトのフェーズに応じて比重を調整することが実務上の選択肢の一つである。
フェーズ別の判断基準
PoCや要件定義の段階では、まだ処理ルールが定まっていないことが多く、LLMの柔軟性を活用して素早くプロトタイプを回すのは合理的な選択である場合がある。この段階で「正規表現で書けるか」を厳密に検証すると、逆に要件発見の機会を失う可能性がある。しかし、本番移行の判断基準として「この処理は決定論的に書けるか」を再評価し、書ける部分は置き換えることが、運用コストと品質の両面で有効な場合がある。
ここで重要なのは、技術選定の動機が「ビジネス要件と制約条件」に基づいているかを確認することである。履歴書に載せるためにエージェントフレームワークやベクターDBを選ぶ「履歴書駆動型AIエンジニアリング」が問題視されている背景（DEVの解説記事）は、技術の選定がタスクの本質ではなく自己表現の手段にすり替わった結果、プロダクション環境の一部が実質的にif文であるという状態を生んだ点にあると指摘されている。選定基準を「このタスクに確実性・速度・コストの観点で最適なのは何か」に固定することで、こうした過剰設計を防ぐ助けになる。
| 評価軸 | LLMベース設計 | 決定論的設計（正規表現/SQL/決定木） |
|---|---|---|
| 柔軟性 | プロンプト修正で対応可能 | コード修正と再デプロイが必要 |
| 堅牢性・予測可能性 | 確率的出力で結果が揺れる | 実行パスが一意に定まる |
| 実行コスト | GPU推論コストが毎回発生 | ほぼゼロ（CPU処理のみ） |
| 開発速度（初期） | プロンプト作成で素早く動作確認 | ルールの形式化に時間がかかる |
| 保守性・監査 | 原因追跡が困難 | 実行パスを追跡可能 |
この表から読み取れるのは、両者は排他的ではなく、ハイブリッドに組み合わせることで互いの弱点を補完できるという点である。次のセクションでは、既存のエージェントをこのハイブリッド構造へリファクタリングする具体的な手順を述べる。
実装手順：既存エージェントのリファクタリング戦略
すでに構築中または運用中のAIエージェントに対して、不要なLLM呼び出しを特定し置き換えるリファクタリングは、4つのステップで進めることができる。重要なのは、一度に全部を書き換えるのではなく、各LLM呼び出しを個別に評価して段階的に移行することである。
ステップ1：LLM呼び出しの可視化
まず、本番環境のログからLLM呼び出しの頻度、入力トークン数、出力トークン数、レイテンシを収集する。このデータに基づいて、呼び出しコストの上位から順に並べ替えることで、リファクタリングの優先順位が明確になる場合がある。多くの場合、全体コストの大半を占めるのは少数の呼び出しパターンであり、これらを置き換えるだけで効果が得られる可能性がある。
ステップ2：入出力の形式とロジックの明確化
上位の呼び出しについて、入力データが構造化されているか、出力が固定フォーマットか、分岐条件が明示的に定義できるかを分析する。この段階で「実は正規表現で書ける」「実はSQLのWHERE句で済む」と判明するケースがある。
ステップ3：置き換え可能性の評価
各呼び出しに対して、正規表現・SQL・決定木のいずれで置き換え可能かを判断する。判断基準は前節の比較表を参照すればよい。置き換えが困難な場合（曖昧な自然言語の解釈が必要な場合など）は、LLMの適用を維持しつつ、入力前処理の最適化のみを行う。
ステップ4：段階的な移行と品質担保
置き換え対象を1つずつ実装し、既存のLLM出力と比較テストを行う。精度に問題がなければ本番に切り替える。このとき、LLM出力を「正解」として盲目的に採用するのではなく、ビジネス要件に対してどちらが適切かを評価する視点を持つことが重要である。
sequenceDiagram
participant A as 分析担当
participant B as 設計担当
participant C as 実装担当
participant D as QA担当
A->>A: LLM呼び出しログの収集と可視化
A->>B: 呼び出し頻度・コストの報告
B->>B: 各呼び出しの置き換え可能性評価
B->>C: 置き換え対象の設計書
C->>C: 正規表現/SQL/決定木の実装
C->>D: 比較テスト用の差分データ
D->>D: LLM出力と新実装の比較検証
D->>C: 検証結果（合格/修正指示）
C->>C: 本番への段階的切り替え
このプロセスを回すことで、システム全体のレスポンス時間が短縮され、GPU推論コストも削減される可能性がある。特に、本番環境の一部が実質的にif文であるという指摘（DEVの解説記事）を踏まえると、リファクタリングの潜在効果は大きいと考えられる。
運用と監視：ハイブリッドアーキテクチャの管理
LLM部分と決定論的部分が混在するハイブリッドアーキテクチャでは、監視の設計を「LLM部分」と「決定論的部分」の2層で分ける必要がある。それぞれで追跡すべき指標と、アラート発火の条件が異なるためである。
LLM部分の監視
LLM呼び出しに対しては、入力トークン数・出力トークン数・推論時間・モデル名を毎回ログに記録する。これらから単位呼び出しあたりのコストを算出し、閾値を超えた呼び出しを自動で検知する仕組みを構築する可能性がある。特に、温度パラメータの設定ミスやプロンプトのバグによってトークン数が異常に増大するケースは、コストスパイクの典型的な原因となる。また、同じ入力に対する出力の一貫性をサンプリングして確認し、モデルのバージョン更新やプロンプト変更による品質劣化を早期に検知する。
決定論的部分の監視
正規表現やSQLによる処理は、LLMのような確率的な振る舞いはしないが、入力データの形式変更（例：契約IDの桁数変更、メールヘッダーのフォーマット変更）によってマッチング率が急低下するリスクがある。マッチング率（抽出できた件数/入力件数）を継続的に監視し、閾値を下回った場合にアラートを発火させることで、データソース側の仕様変更を迅速に検知できる。
フォールバック設計とKPIの紐付け
LLM部分の不確実性に対するフォールバックとして、出力が期待されるフォーマットに適合しない場合に決定論的なデフォルト値を返す、あるいは人間によるレビューへエスカレーションする、といった多段のフォールバックを設計する。運用面では、ビジネスKPI（平均処理時間、1件あたりコスト、抽出精度）と技術指標（LLM呼び出し率、マッチング率、エラー率）を紐付けたダッシュボードを構築し、定例レビューで両者を同時に確認する体制が有効である場合がある。これにより、「コストは下がったが精度が劣化した」というトレードオフの盲点を防ぐことができる。
まとめ：実務に即したAIエージェント設計へ
本記事では、プロダクション環境のAIエージェントの一部が、GPUコストを伴う単なるif文であるという現状（DEVの解説記事）を起点に、LLM適用の境界を明確に引く設計指針を提示した。正規表現、SQL、決定木といった既存技術は、固定フォーマットの抽出・事実ベースの検索・明確な分岐ロジックに対して、確実性・速度・コストのすべてでLLMを上回る場合がある。一方で、構造化されていないテキストの解釈や曖昧さの解決が必要な場面では、LLMの推論能力が不可欠である。
技術選定の判断基準は、流行りのフレームワークや履歴書への記載ではなく、「このタスクに確実性・速度・コストの観点で最適なのは何か」に固定すべきである。履歴書駆動型AIエンジニアリングがもたらす過剰設計は、PoC段階では目立たないが、本番移行後にGPU費用と保守性の両面でコストとして返ってくる可能性がある。現在構築中または運用中のAIエージェントについて、本記事のリファクタリング手順を適用することで、無駄なGPU費用を削減しながら、より信頼性の高いシステムへと進化させる可能性がある。
関連記事
- AIエージェントの暴走を防ぐ：while(true)ループの限界とEventStoreによる状態管理の実践
- AIエージェントの「無視された失敗」をCIで検知：tracelintを用いた決定論的品質ゲートの設計
- LLMの構造化出力で業務データを自動抽出！実践テクニックとライブラリ活用法
参考
本記事は海外の技術トレンド「Half the AI agents in production are if-statements with a GPU bill」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。