AgentOps を採用する前に読む: 2行で始めるエージェント計測とその境界

エージェントの実行ログが散らかる問題をどこで受けるか

LLM を1回呼ぶだけのアプリなら、リクエストとレスポンスを自分でログに吐けば済む。ところが CrewAI や LangGraph のようなフレームワークを使うと、1回のユーザー操作の裏でエージェントが何度もモデルを呼び、ツールを叩き、別のエージェントに処理を渡す。この連鎖を後から再現しようとすると、フレームワークごとに異なるコールバックの書き方を覚え、モデルごとに異なるトークン数の数え方を揃え、コスト単価を自分で掛け合わせる作業が発生する。AgentOps が引き受けるのはこの部分だと README は説明している。README の機能表には Replay Analytics and Debugging、LLM Cost Management、Framework Integrations、Self-Host の4項目が並び、step-by-step agent execution graphs と spend の追跡が柱として挙げられている。対象読者は、プロトタイプから本番に移る段階でエージェントの挙動を説明できるようにしたい開発者である。単発のチャットボットではなく、複数ステップのワークフローを持つエージェントを運用している人ほど、この種のツールが必要になる。

agentops.init が何を拾い、何を送るのか

README が示す最小構成は2行である。プログラムの先頭で agentops.init() を呼び、API キーを渡す。終了時に agentops.end_session('Success') を呼ぶ。この2行で、そのプロセス内の LLM 呼び出しに対する analytics が自動的に得られると README は説明している。仕組みとしては、SDK がフレームワーク側のコールバックやクライアントラッパーに接続し、モデル呼び出し、ツール実行、セッションの区切りをイベントとして収集し、ダッシュボードに送る、という流れが読み取れる。README の統合ロゴには OpenAI Agents SDK、CrewAI、AG2 (AutoGen)、Microsoft、LangChain、Camel AI、LlamaIndex、Cohere が並び、説明文には Agno、LangGraph、Groq、Mistral、Ollama、Anthropic といった名前も見える。つまり AgentOps は自前でエージェント実行エンジンを持つのではなく、既存フレームワークの上に計測層をかぶせる立場を取っている。もう一つの入口がデコレータで、README には from agentops.sdk.decorators import session として @session を関数に付ける例がある。これを付けた関数がセッションのルート span になり、その中の処理が子 span としてぶら下がる、という構造が README のコメントから読み取れる。フレームワークの自動検出に頼らず、自分のワークフロー単位でまとまりを定義したい場合に使う入口である。

導入は pip install agentops と API キーの2ステップ

インストールは pip install agentops の1コマンドで、README の Quick Start はこれだけを載せている。次に app.agentops.ai/settings/projects で API キーを取得し、コードの先頭で agentops.init() に渡す。README の例では agentops.init( < INSERT YOUR API KEY HERE >) と書かれ、環境変数名や設定ファイルのキー名は README には明記されていない。ここは注意点で、キーをソースに直書きする例が公式の Quick Start に載っている形になっている。本番に組み込むなら、環境変数やシークレットマネージャ経由に置き換える前提で読むべきである。初期化の位置について README は main.py や __init__.py といったプログラムの先頭を指定しており、フレームワークの初期化より前に呼ぶ必要があると読める。終了側は agentops.end_session('Success') で、引数にセッションの結果を表す文字列を渡す形になっている。成功以外にどんな値を渡せるのかは README からは分からない。セルフホストしたい場合は、README が app/README.md のセットアップガイドを参照するよう案内しており、Dashboard と API バックエンドの両方を自分のマシンで動かす手順がそこに置かれている、という構成だけが確認できる。

セルフホストできることと、MIT ライセンスが及ぶ範囲

README は The AgentOps app is open source under the MIT license と明記し、app ディレクトリへのリンクを置いている。つまり SDK だけでなく、ダッシュボードと API バックエンドを含むアプリ本体も MIT で公開されている、という建て付けである。これは計測データの送信先を自分で管理したいチームにとって意味のある構成で、SaaS のダッシュボードだけが提供される製品とは前提が違う。ただし README から確認できるのはライセンス表記と app/README.md への導線までで、セルフホスト版が SaaS 版と同じ機能を全部持つのか、認証や課金まわりの扱いがどうなっているのかは読み取れない。MIT ライセンスは著作権表示と許諾表示を残せば改変と再配布を許す条件であり、これは法的助言ではないが、社内で改変版を配る場合でも表示義務が残る点は押さえておきたい。ライセンスの解釈や、SaaS 利用時のデータ処理条件については、リポジトリの LICENSE と利用規約を直接確認する必要がある。

コスト追跡とセッションリプレイが効かない場面

この手のツールが最も力を発揮しないのは、計測対象が SDK の外側にある場合である。AgentOps はフレームワーク統合とクライアントラッパーを通じてイベントを集める設計だと README から読めるので、HTTP リクエストを自作したり、独自の推論サーバーを立ててモデルを呼んだりしている部分は、統合が用意されていなければ素通りする可能性が高い。README に挙がっていないフレームワークを使っている場合、その統合が存在するかどうかは docs.agentops.ai 側で確認するしかない。もう一つの境界はセッションの終了処理である。README は end_session('Success') をプログラム末尾で呼ぶ形を示している。逆に言えば、例外で異常終了した場合や、常駐プロセスとして動き続けるエージェントのように終了時点が定まらない場合、セッションがどう閉じられるかは README からは分からない。バッチ処理のように開始と終了が明確なワークロードと、長時間動き続けるサーバー型のエージェントでは、同じ2行の意味が変わってくる。後者を運用しているなら、セッションの区切りをどう設計するかを先に決めておく必要がある。

OpenTelemetry 系バックエンドとの違いは何か

比較対象として素直なのは、エージェント実行を OpenTelemetry のスパンとして出力し、Langfuse や Phoenix のような OTLP 対応のバックエンドに送る構成である。違いは主にどこで統合を吸収するかにある。AgentOps は CrewAI、AG2、LangChain といったフレームワークごとの統合を SDK 側に同梱し、agentops.init の1行で有効化する体験を前面に出している。対して OTLP 経由の構成は、計測の粒度や属性名を自分で設計でき、既存の可観測性スタックにそのまま流し込める代わりに、フレームワークのコールバックを自分でスパンに変換するコードを書くことになる。どちらが優れているという話ではなく、フレームワーク統合を自前で保守したくないなら AgentOps、計測項目を自分で定義して他のサービスと同じパイプラインに載せたいなら OTLP 側、という住み分けになる。AgentOps 自身が OTLP を出力できるかは README からは確認できないので、既存の可観測性基盤に統合したい場合は、そこが最初に確認すべき点になる。

0.4.x 系の更新頻度と、採用前に見るべきもの

リリース履歴を見ると 0.4.19 が 2025-08-01、0.4.20 が 2025-08-15、0.4.21 が 2025-08-29 で、およそ2週間おきに版が上がっている。0.x の段階が続いており、マイナー番号の更新で挙動が変わる可能性を前提に置いたほうがよい。実際、README には v1 と v2 の統合ページへのリンクが混在しており、docs.agentops.ai/v1/integrations/crewai と docs.agentops.ai/v2/integrations/openai_agents_python が並んでいる。ドキュメントの版が統合ごとに分かれている状態は、追従コストを見積もる上での材料になる。依存関係に agentops を固定バージョンで入れるのか、範囲指定にするのかは、この更新間隔と自チームのリリースサイクルを突き合わせて決めることになる。確認すべきは3点で、第一に自分のフレームワークが docs.agentops.ai の統合一覧に載っているか、第二に agentops.init に渡すキーを環境変数やシークレット管理に逃がせるか、第三に app/README.md の手順でセルフホスト版が実際に立ち上がるかである。この3点が自チームの条件で通るなら、2行を足すコストは小さい。

編集部の結論

すでに CrewAI、Agno、OpenAI Agents SDK、LangChain、Autogen、AG2、CamelAI のいずれかでエージェントを組んでおり、LLM 呼び出しのコストとステップ実行の流れを後から追いたいチームには、agentops.init の2行を試す価値がある。逆に、計測データを外部の SaaS に一切出せない、あるいは自前の OpenTelemetry バックエンドで統一したいチームは、app/README.md のセルフホスト手順で Dashboard と API を立てられるかを先に確認すべきで、そこが通らないなら採用は見送る判断になる。採用を決める前に、自分のフレームワークが docs.agentops.ai の統合ページに載っているか、agentops.end_session('Success') を呼ばずにプロセスが落ちた場合の挙動、そして 0.4.19 から 0.4.21 までのリリース間隔が示す更新頻度を、実際の依存関係の中で確かめてほしい。

公式情報源

1. AgentOps-AI/agentops on GitHub
2. License: MIT
3. Project website
4. README
5. Releases