社内の問い合わせ対応やログ監視の一次切り分けにAIエージェント（自律的にタスクを処理するAIの仕組み）を導入すべきか、検討を任されたインフラ担当者は少なくないはずです。
経営層から「AIで自動化できないか」と聞かれたとき、答えに困る理由ははっきりしています。「AIは有効か」という問いには誰も答えられません。答えられるのは「この作業を、この量で自動化したとき、構築と運用のコストより早く回収できるか」という狭い問いだけです。SREの視点で見れば、これはSLO（サービスレベル目標）設計やIaC（Infrastructure as Code、インフラ構成をコードで管理する手法）導入の可否判断と同じ構造をしています。投資対効果を数式で出し、損益分岐点が現実的な運用量の内側に入るかどうかを見極める作業です。
この記事では、AIエージェント導入を判断する際の軸を整理し、実際に数字を当てはめて損益分岐点を出す手順まで示します。
判断が必要になる場面
オンコール対応の一次トリアージ、障害チケットの分類、ログからの異常検知の要約など、AIエージェントの導入候補は現場に多くあります。
こうした場面で「なんとなく便利そうだから試す」という進め方をすると、後になって運用コストが積み上がり、撤退判断もできないまま塩漬けになりがちです。SLO運用やIaC移行と同様に、導入前に定量的な基準を持つことが実務上の安全策になります。
判断軸1: 手動運用の実コスト（フルロード原価）
最初に置くべき軸は「今の人手対応にいくらかかっているか」を正直に見積もることです。
給与だけでなく福利厚生や間接コストを含めた時給換算（フルロードコスト）、1件あたりの処理時間、ミスによる手戻りコスト、そして人が張り付いているせいで手が回らない他業務の機会損失まで含めます。これらを月間処理件数に掛け合わせると、現状維持にかかっている本当のコストが見えてきます。エラーコストと機会損失を含めると、想定より高い数字になることがほとんどです。
判断軸2: エージェントの構築費用と実行単価
2つ目の軸は「エージェント自体のコスト」で、こちらは一時費用と継続費用を分けて考える必要があります。
一時費用は要件定義、プロンプトや評価基準の調整、既存システムとの連携、稼働後1か月程度のモニタリング調整までを含みます。継続費用は推論トークン代、外部API呼び出し費用、プロンプトのドリフトやモデル切り替えに伴う保守作業です。
継続費用は仕様書からの推測ではなく、実際のプロンプトとモデルで100〜200件のテストバッチを回し、平均実行単価を算出する必要があります。ここを曖昧にすると、処理量が増えるほどコストが膨らむクラウド従量課金型の性質上、投資対効果の計算全体が崩れます。
判断軸3: アーキテクチャ選択（単一呼び出しか多段チェーンか)
3つ目の軸は見落とされがちですが、SREの観点では可用性設計に直結する重要な判断です。
タスクを「抽出→要約→ドラフト作成」のように多段チェーンで処理するか、1回のモデル呼び出しで完結させるかという選択です。段数が増えるほど、途中のどこかで静かに失敗する（サイレントフェイル）リスクが増え、オブザーバビリティ（システム内部の状態を外部から観測できる性質）の確保も難しくなります。
単一呼び出し構成に絞り込めれば、実行単価が下がり損益分岐点も早く到達しやすくなります。マイクロサービス設計で「サービス分割しすぎると障害点が増える」のと似た構造だと捉えると理解しやすいはずです。
判断軸4: 損益分岐点となる処理量
最後の軸が、実際に導入可否を決める数式です。
損益分岐点(件数) = 一時構築費 / (手動処理単価 - エージェント実行単価)たとえば手動処理単価が1件あたり4.5ドル（人件費＋エラーコスト込み）、エージェント実行単価が0.15ドルなら、1件あたりの削減額は4.35ドルです。構築費が6,000ドルなら、損益分岐点はおよそ1,380件になります。
月間2,000件処理しているなら初月で黒字化しますが、月間200件なら回収に約7か月かかります。プロセス自体がその間に変わる可能性を考えると、判断は大きく変わってきます。
選択肢の比較
| 観点 | AIエージェント導入 | 現状の人手運用継続 |
|---|---|---|
| 初期コスト | 構築費が発生（一時費用） | ほぼゼロ |
| スケール耐性 | 処理量増加でも実行単価はほぼ一定 | 処理量増加に比例して人件費増 |
| 例外処理 | 判断が難しい少数ケースは苦手 | 柔軟に対応できる |
| 可観測性の負荷 | プロンプトドリフト監視が追加で必要 | 追加の監視コストなし |
ケース別の推奨
- 月間処理件数が損益分岐点を明確に上回り、かつ12か月以内に処理量が減る見込みがないなら、構築を進める判断が妥当です
- 処理内容が定型的で、抽出とドラフト作成のように1回の呼び出しにまとめられるタスクなら、多段チェーンより単一呼び出し構成を優先すべきです
- 損益分岐点までの回収期間が3か月以内に収まるなら、プロンプトドリフトのモニタリング体制を整えたうえで着手する価値があります
- 障害対応の一次切り分けなど、SLOのエラーバジェット管理と連動させられるタスクなら、オブザーバビリティ基盤との統合も含めて検討する価値があります
あえて見送るべき条件
判断ミスを防ぐために、見送るべき条件も明確にしておく必要があります。
処理量が少なく、かつ判断のばらつきが大きい「例外処理が多いタスク」は、たいてい損益分岐点をクリアしません。全体の作業のうち判断力が必要な2割程度の部分は、人手に残したほうがコスト的に安全です。
また、テストバッチでの実行単価測定を省略してエージェントを見切り発車で構築するケースも見送るべきです。推測でコストを見積もると、運用開始後にトークン代が想定を大きく超え、赤字運用に陥るリスクが高まります。プロンプト仕様書だけを見て判断するのは危険です。
さらに、対象プロセス自体が半年以内に変更される可能性が高い場合も要注意です。損益分岐点に到達する前に業務フローが変わってしまい、構築費用を回収できないまま作り直しになる可能性があります。
まとめ
AIエージェント導入の可否は、感覚ではなく損益分岐点の数式で判断できます。
まず手動運用のフルロードコストを正直に算出し、次にテストバッチで実行単価を実測すること。この2つが揃って初めて、損益分岐点の計算が意味を持ちます。
処理量が損益分岐点を超えるかどうかは、SLOのエラーバジェットを設計するときと同じ感覚で、実測データに基づいて判断する姿勢が欠かせません。まずは対象タスクの月間処理件数と現状コストを洗い出すところから始めてみてください。