0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIエージェントについて調べたことをもう一歩深掘りしてみた ~評価・可観測性・コスト管理・ガードレールまで~

0
Last updated at Posted at 2026-10-01

はじめに

以前、「AIエージェントについて自分で調べてみてわかったこと」という記事を書きました。

前回の記事では、

  • AIエージェントは「目的達成のために自律的に動くAI」であること
  • Function Callingを利用して外部ツールを実行する仕組みであること
  • 法務・障害対応・カスタマーサポート・採用・データ分析など、幅広い分野で活用が進んでいること
  • LangChain・LangGraph・FastAPIなどの技術がよく使われていること

について、案件で見かけた用語をベースにざっくり整理しました。

ただ、前回はあくまで「AIエージェントで何ができるか」という活用例の紹介が中心で、

  • AIエージェントがちゃんと動いているかどうか、どうやって確認するの?
  • AIに勝手に重要な操作をされたら怖いけど、どう歯止めをかけるの?
  • LLMを何度も呼び出すAIエージェントって、料金がすごいことにならないの?
  • 会話が終わった後、AIエージェントは何を覚えていてくれるの?

といった、実際に運用する上で気になる疑問には踏み込めていませんでした。そこで今回は、前回の記事からもう一歩踏み込んで、AIエージェントの「評価・可観測性(Observability)」「ガードレールとHuman-in-the-Loop」「メモリ管理」「コスト管理」について調べながら整理してみました。

この記事はこんな方におすすめ

  • 前回の記事でAIエージェントの活用例はつかめたので、実際に運用する上での注意点を知りたい方
  • AIエージェントの動作をどう検証・監視すればいいか気になる方
  • AIエージェントに重要な操作を任せる際の安全対策を知りたい方
  • AIエージェントがユーザーの情報をどう記憶しているのか気になる方
  • LLMを何度も呼び出すAIエージェントのコストが気になる方

まず前回のおさらい

前回の記事のポイントを簡単に振り返ります。

ユーザー
   ↓
LLM
   ↓
Function Calling
   ↓
外部ツール(API・DB・AWS・検索システム)
   ↓
結果取得
   ↓
LLM
   ↓
回答
  • AIエージェントは「目的」を与えると自ら必要な処理を考えて実行するAI
  • Function Callingにより、AIが必要に応じて外部ツールを呼び出せる
  • 法務・障害対応・カスタマーサポート・採用・データ分析など幅広い活用例がある
  • LangChain・LangGraph・FastAPI・AWSとの相性が良い

前回は、この「AIエージェントが何をしてくれるか」という活用例の紹介にとどまっていました。今回はまず、実際にAIエージェントを動かしたときに「本当にちゃんと動いているか」をどう確認するのか、というところから深掘りしていきます。

AIエージェントの「動き」をどう検証する?

前回紹介した障害対応エージェントやデータ分析エージェントのように、AIエージェントは1つのタスクの中で何度もLLMを呼び出したり、複数のツールを実行したりします。調べてみると、この「AIが裏側で何をしたか」を追跡できる状態のことを**可観測性(Observability)**と呼び、AIエージェントの運用では欠かせない考え方であることが分かりました。

タスク開始
   ↓
「どのツールを」「どの順番で」「いくらのコストで」呼び出したか
   ↓
1つずつ記録(トレース)
   ↓
失敗した場合:どのステップで・なぜ失敗したかを特定できる

具体的には、1つのタスクの中で「どのステップで、どのプロンプトが、どんな出力を返し、どのツールを呼び、どこで失敗したか」を構造化して記録するトレーシングという手法がよく使われるようです。LangSmithやLangfuseといったツールでは、こうしたトレースを一覧できる画面や、成功率・レイテンシ・コストをまとめて可視化する機能が提供されています。

さらに、トレースを取るだけでなく、「回答が簡潔かどうか」「ハルシネーションが起きていないか」といった品質面を継続的にチェックする**評価(Evaluation)**の仕組みも重要とのことでした。前回紹介した法務エージェントや障害対応エージェントのように、判断を任せる領域が広がるほど、「ちゃんと動いているか」を継続的に検証する仕組みなしでは安心して運用できない、という点は今回の発見でした。

AIに重要な操作を任せて大丈夫?→ガードレールとHuman-in-the-Loop

前回、障害対応エージェントが「CloudWatch確認→原因分析→Slack通知」までを自動化できると紹介しましたが、これがもし「原因を推測して勝手にサーバーを再起動する」ところまで自動化されていたら、少し怖いと感じる方も多いと思います。調べてみると、こうした不安に対処するための考え方がガードレールと**Human-in-the-Loop(HITL)**でした。

ガードレールとは、ユーザーの指示やAIの判断が安全かつ適切かどうかを、実行前にチェックする層のことです。ワードフィルタのような単純な仕組みだけでなく、ドメイン知識を与えた「ガードレール専用のLLM」に判定を任せる設計も使われているようです。

Human-in-the-Loopは、AIの判断をそのまま実行させず、人間の承認を挟む仕組みです。調べてみると、エージェントが実行しうる操作を洗い出し、「不可逆性」と「影響範囲」の2軸で整理した上で、承認の厳しさを段階的に変える、という設計が実務では行われているようです。

操作の例 不可逆性 影響範囲 承認の付け方
ログを確認する 低い 小さい ログのみ記録(事後レビュー)
Slackに通知を送る 低い 中くらい 事後レビュー
サーバーを再起動する 高い 大きい 事前承認が必須
契約書の内容を確定する 高い 大きい 事前承認が必須
AIエージェントの提案
   ↓
Slack等に「承認する / 差し戻す」ボタンを提示
   ↓
人間が判断
   ↓
承認された場合のみ実行

前回紹介した法務エージェントの「feedback loop」も、法務担当者がレビュー結果を評価し、その結果を次回以降の判断に活かす仕組みでしたが、これはまさにHuman-in-the-Loopの一種だったのだと今回改めて理解できました。Human-in-the-Loopは「AIを信頼していないから見張る」というより、AIエージェントが組織の中で安心して使われ続けるための設計だと分かり、印象が変わりました。

AIエージェントは何を覚えていてくれるの?→メモリ管理を調べてみた

前回紹介したカスタマーサポートエージェントや採用エージェントのように、同じユーザーと何度もやり取りするタイプのAIエージェントでは、「前回のやり取りを覚えているか」が使い勝手を大きく左右します。調べてみると、AIエージェントの記憶は単に会話履歴を長く持たせることではなく、複数の階層に分けて設計するのが標準になってきているようです。

感覚記憶(今の入力)
   ↓
短期記憶(LLMのコンテキストウィンドウ。高速だが容量に上限あり)
   ↓
長期記憶(会話をまたいで保持。ベクトルDBなどに保存)
   ↓
エピソード記憶(過去の出来事や経緯を要約して保持)

長いコンテキストウィンドウと長期記憶は別物であり、必要なのは過去の情報をすべて持ち込むことではなく、必要な記憶を必要な粒度で、必要なタイミングで呼び戻すことだ、という考え方が印象的でした。実際、2026年時点では、Mem0(軽量)・Zep(ベクトル検索とグラフを組み合わせた本番向け)・Letta(旧MemGPT、OSのメモリ管理に着想を得た階層型)といった専用のメモリフレームワークを使い分けるのが一般的になってきているようです。

前回、法務エージェントの「feedback loop」で「徐々にその会社の担当者に近い判断ができるようになる」と紹介しましたが、これはまさに、会話をまたいで蓄積される長期記憶があってこそ実現できる仕組みだったのだと、今回調べてみて理解が深まりました。

LLMを何度も呼ぶAIエージェント、コストは大丈夫?

前回、AIエージェントは「LLM→Function Calling→外部ツール→LLM→回答」という流れを紹介しましたが、これを1つのタスクで何度も繰り返すと、LLMの呼び出し回数、つまりコストが積み上がっていくことになります。調べてみると、実務では主に3つの方法でコストを抑えているようです。

手法 内容
プロンプトキャッシュ 同じシステムプロンプトなどを繰り返し使う場合、キャッシュを読み出すだけで済ませる(入力料金の大幅な削減になる)
モデルルーティング 複雑な推論には上位モデル、単純な分類・要約には廉価モデルを使い分ける
トークン管理 システムプロンプトを圧縮したり、JSON Schemaで出力形式を指定して無駄な説明文を減らす
タスクの難易度を判定
   ↓
簡単な分類・要約 → 廉価モデルへルーティング
複雑な推論・長文生成 → 上位モデルへルーティング
   ↓
同じコンテキストは可能な限りキャッシュを利用

例えば、前回紹介したカスタマーサポートエージェントのように「まず分類Agentで問い合わせを振り分ける」という構成であれば、分類の部分は廉価なモデルに任せ、回答生成の部分だけ高性能なモデルを使う、という使い分けが考えられます。前回は技術スタックの一覧として「LLM:OpenAI API、Claude」のように紹介しましたが、実際には「どのステップにどのモデルを割り当てるか」という設計自体が、コストと品質のバランスを取る重要なポイントになる、というのは今回の発見でした。

Pythonでトレーシングの考え方を覗いてみる

イメージをつかむために、AIエージェントの各ステップを簡単なデコレータで記録する例を見てみます(実際の運用ではLangSmithやLangfuseのようなツールを使うのが一般的です)。

import time
import functools

trace_log = []

def trace_step(step_name):
    def decorator(func):
        @functools.wraps(func)
        def wrapper(*args, **kwargs):
            start = time.time()
            try:
                result = func(*args, **kwargs)
                trace_log.append({
                    "step": step_name,
                    "status": "success",
                    "duration": time.time() - start,
                })
                return result
            except Exception as e:
                trace_log.append({
                    "step": step_name,
                    "status": "failed",
                    "error": str(e),
                })
                raise
        return wrapper
    return decorator

@trace_step("describe_table")
def describe_dynamodb_table(table_name: str):
    # AWSのAPIを呼び出す想定
    return {"table_name": table_name, "billing_mode": "PAY_PER_REQUEST"}

describe_dynamodb_table("orders")
print(trace_log)

こうしたデコレータで「どのステップが」「成功したか失敗したか」「どれくらい時間がかかったか」を記録しておくことで、前半で紹介したトレーシングの考え方を簡易的に再現できます。実際にはこれにコストやトークン数の記録も加え、専用のObservabilityツールに送るのが一般的なようですが、仕組みの根っこは「各ステップの実行結果を構造化して残しておく」というシンプルな考え方なのだと分かりました。

個人的に調べてみて思ったこと

前回は、AIエージェントについて「目的達成のために自律的に動くAI」で、法務や障害対応など幅広い分野で活用が進んでいる、という理解にとどまっていました。今回さらに調べてみると、

  • AIエージェントの動作を検証するには、各ステップを記録するトレーシングと、品質を継続的にチェックする評価の仕組みが必要なこと
  • 重要な操作を任せる際には、不可逆性と影響範囲で整理したガードレールとHuman-in-the-Loopが安全網になること
  • AIエージェントの記憶は、短期記憶・長期記憶・エピソード記憶といった階層で設計されており、専用フレームワークの活用が進んでいること
  • LLMを何度も呼び出すコストは、プロンプトキャッシュ・モデルルーティング・トークン管理で抑える工夫がされていること

が分かりました。特に「AIエージェント=便利な自動化の仕組み」という前回の理解に対して、実際にはそれを安心して運用し続けるための「検証」「安全対策」「記憶の設計」「コスト管理」という、地味だけれど欠かせない仕組みがセットになっているのだと実感しました。華やかな活用事例の裏には、こうした運用面の設計が支えているのだと分かったのは大きな収穫でした。

まとめ

今回は、AIエージェントについて前回の記事よりもさらに一段深掘りしてみました。重要なポイントをまとめると、

  • AIエージェントの動作は、トレーシングによって各ステップを記録し、評価の仕組みで品質を継続的にチェックする必要がある
  • 重要な操作には、不可逆性×影響範囲で整理したガードレールとHuman-in-the-Loopによる承認フローが有効
  • AIエージェントの記憶は短期・長期・エピソード記憶の階層で設計され、Mem0やZepなどの専用フレームワークが使われ始めている
  • LLMの呼び出しコストは、プロンプトキャッシュ・モデルルーティング・トークン管理で抑えることができる

前回は「AIエージェントで何ができるか」という活用例の紹介でしたが、今回はそれを安全かつ継続的に運用するための「評価・可観測性」「ガードレール」「メモリ管理」「コスト管理」まで踏み込むことができました。まだ実際に自分の手でLangSmithのようなツールを使ったトレーシングを試したり、メモリフレームワークを実装したりはできていないので、今後は手を動かしながら検証していきたいと思います。
同じようにAIエージェントの運用面に興味がある方の参考になれば幸いです。
最後まで読んでいただき、ありがとうございました!

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?