社内向けチャットボットに「注文を検索して、遅延した便を教えて」といった複数手順のタスクを任せたい、という相談が増えています。
こうしたAIエージェント（目標を与えると自分で手順を考えて実行するAIシステム）は、単純な文章生成AIとは仕組みが違います。従来のチャットボットはユーザーの質問に対して答えを生成するだけですが、AIエージェントはAPIやデータベースといった外部ツールを呼び出し、結果を観察し、目標達成まで行動を繰り返します。
この記事は、SRE（サイト信頼性エンジニアリング）やインフラ基盤を担当していて、自社サービスにAIエージェントを組み込むべきか判断を求められている方に向けたものです。可用性・コスト・運用負荷の観点から、導入すべきか見送るべきかを整理する材料になれば幸いです。
なぜ「ただのAPI連携」と同じ扱いにできないのか
従来型のソフトウェアは、開発者が明示的に定義した手順通りに動きます。処理Aの後に処理Bを実行する、という順序はコードに書かれた通りで、実行結果は決定論的（同じ入力なら同じ出力になる性質）です。
一方でAIエージェントは、LLM（大規模言語モデル。自然言語を理解し生成するAIモデル）が「次に何をすべきか」を都度判断します。同じ入力でも呼び出すツールの順序や回数が変わることがあり、これは通常のマイクロサービス間API連携の設計原則とは前提が異なります。
たとえば注文管理APIを呼ぶ回数が1回で済むケースもあれば、エージェントが「情報が足りない」と判断して3回呼び出すケースもあります。これはリトライ処理のバグではなく、推論の結果として起きる正常な挙動です。この非決定性こそが、SLO設計やオブザーバビリティ（システム内部の状態を外部から観測できる度合い）の設計を難しくする最大の要因です。
判断軸1: SLOを定義できるタスクか
SLO（サービスレベル目標。可用性やレイテンシの達成目標値）は、測定可能で再現性のある指標に対して初めて意味を持ちます。
AIエージェントのタスクは「目標は達成したが手順は毎回違う」という性質を持つため、レイテンシSLOを1本の数値で定義しにくい場面があります。ツール呼び出し回数がタスクごとに変動するなら、p99レイテンシは呼び出し回数の分布込みで捉える必要があります。
確認すべきは、そのタスクが「最終的な成功・失敗」を明確に判定できるかどうかです。判定できるなら、レイテンシではなく「タスク完了率」や「人間の承認に回った割合」をSLIとして採用する設計がなじみます。
判断軸2: 権限とツール呼び出しをIaCで管理できるか
AIエージェントに与える「ツール」とは、外部API・データベース・社内システムへのアクセス権限そのものです。
この権限をコードやコンソール操作でその場しのぎに付与すると、誰がいつどのAPIにアクセス可能かを追跡できなくなります。TerraformやPulumiといったIaC（インフラをコードで定義・管理する手法）で、エージェントに紐づくIAMロールやAPIスコープをバージョン管理下に置けるかどうかは、本番投入前に必ず確認すべき点です。
たとえば「注文情報の参照は許可するが、返金処理の実行は人間の承認を必須にする」といった境界線は、コードとしてレビュー可能な形にしておく必要があります。この権限設計をTerraformのモジュールとして再利用できる状態にできないプロジェクトは、まだ導入の準備段階にあると考えたほうが安全です。
判断軸3: オブザーバビリティで推論過程を追跡できるか
通常のアプリケーションログは「何が実行されたか」を記録しますが、AIエージェントでは「なぜその行動を選んだか」という推論過程も記録対象になります。
目標受領からツール選択、実行、結果観察、次の判断に至る一連の流れをトレースとして残せないと、障害発生時に「なぜこのAPIが誤って呼ばれたか」を再現できません。OpenTelemetryのようなトレーシング標準を使い、LLMへの呼び出しとツール実行をひとつながりのスパンとして記録できるかどうかが分岐点になります。
既存のAPMツールがLLM呼び出しやツール実行ステップをスパンとして扱えるか、ダッシュボードで可視化できるかを、導入前に確認しておく必要があります。
判断軸4: コストの上限を仕組みで止められるか
AIエージェントはタスク完了まで自律的に推論とツール呼び出しを繰り返すため、想定より多いループ回数でLLM APIコストが積み上がる可能性があります。
従来のAPI連携ならリクエスト数はコードのループ回数で決まりますが、エージェントは推論の結果として呼び出し回数が変動します。最大ステップ数の上限、1タスクあたりのトークン予算、月次の予算アラートといった仕組みを事前に組み込めるかが、コスト面での分かれ目です。
選択肢の比較
| 方式 | 可用性設計 | コスト予測性 | 向いている場面 |
|---|---|---|---|
| 従来型APIオーケストレーション | 決定論的で設計しやすい | 高い(呼び出し回数固定) | 手順が固定された定型業務 |
| 人間承認つきAIエージェント | 境界を区切れば運用可能 | 中程度(上限設定次第) | 判断は自動化したいが実行は人が承認 |
| 完全自律型AIエージェント | 非決定的で難易度が高い | 低い(変動幅が大きい) | 探索的タスクで失敗の影響が小さい場合 |
ケース別の推奨
注文検索や在庫確認のように「参照系で失敗しても実害が小さい」タスクなら、人間承認つきAIエージェントから始める選択が現実的です。
返金処理や設定変更のような「実行すると取り消しにくい」操作が絡むなら、AIエージェントには判断だけを任せ、実行はTerraformで管理された既存のCI/CDパイプラインに委譲する構成が安全です。
監視体制がまだPrometheus + Grafana程度の基本構成にとどまり、分散トレーシングを導入していないチームは、まずオブザーバビリティ基盤を整備してから検討する順番をおすすめします。
あえて見送るべき条件
次のような状態なら、AIエージェント導入は時期尚早と判断してよいと考えられます。
- SLIとして測定できる成功条件を定義できていない
- 権限管理がコンソールでの手動設定に依存している
- 障害発生時にツール呼び出しの履歴を追跡する手段がない
- LLM APIコストの上限を止める仕組みがコード化されていない
- オンコール担当者がエージェントの推論ログを読む訓練を受けていない
これらは「AI技術が未成熟だから」ではなく、既存のSRE的な運用基盤が追いついていないために起きる問題です。基盤を整えてから再挑戦する方が、結果的に手戻りが少なくなります。
導入前に確認すること
AIエージェドは便利な自動化手段ですが、可用性設計の前提が従来のAPI連携とは異なります。
導入を検討する際は、まずタスクの成功条件をSLIとして言語化できるか試してみてください。次に、ツール呼び出しの権限をTerraformなどのIaCでレビュー可能な状態にできるか確認します。
そのうえで、OpenTelemetryなどでLLM呼び出しとツール実行をトレースできる体制があるか、そしてコスト上限をコードで止められるかを点検すれば、導入判断の材料はそろいます。