1コマンドでのオブザーバビリティ統合により、OpenClaw AIエージェントの運用はAlibaba Cloudのモニタリングプラグインを通じて透明化されます。
❓あなたはこれを経験したことがありますか？
OpenClaw（オープンソースのAIエージェントフレームワーク）は、より多くの企業にとって「デジタル社員」になりつつあります。メールを処理し、コードを書き、ファイルを管理し、コマンドを実行します。ほぼ何でもやります。多くのチームが、数十、あるいは数百のOpenClawインスタンスを展開しています。彼らは大規模な「デジタル・ロブスターファーム」を作りました。
しかし、問題が起きます。
ロブスターの飼育者なら、少なくとも池を眺めることはできます。では、あなたのOpenClawはどうでしょう？ 今日それが消費したトークン数は分かっていますか？ 予算を静かに食い潰しているのはどのモデルですか？ 3:00 AMに「ロブスター」が /etc/passwd を読みに誘導されたかどうか分かっていますか？
多くの人の答えはこうです：分かりません。
あなたは慎重にOpenClawをデプロイしました。ですが、こうした問題が発生すると、原因を特定するための適切なツールがなく、行き詰まってしまいます。
この記事では、1コマンドでOpenClawにX線装置を装備する方法を説明します。これにより、LLMの呼び出し、ツール実行、トークン消費のすべてが見えるようになります。
1. ロブスターは何をしている？3つの「見えない死角」があなたの確信に影響する
始める前に、3つの「死角」について話しましょう。OpenClawを使っているなら、少なくとも1つはあなたを悩ませていたはずです。
死角1：推論プロセスは迷路で、デバッグは推測に頼る
ユーザーメッセージを処理するまでにOpenClawが辿る完全な経路は、あなたが思っているよりも複雑です。単純な質問でも、次のような旅をするかもしれません：
ユーザー入力 → システムプロンプトの組み立て → モデル推論ラウンド1 → ツール呼び出しが必要か判断 → ツール呼び出し（検索やコード実行など） → ツール結果を返す → モデル推論ラウンド2 → 別のツールを呼び出す → 最終応答を生成
どこかのステップで失敗すると、最終的な出力は期待から外れる可能性があります。トレーシング分析がなければ、「入力−出力」のブラックボックスに直面します。問題がどこにあるのかを当てるしかありません。プロンプトが悪いのか？ モデルが幻覚（ハルシネーション）を起こしているのか？ ツールが間違ったデータを返したのか？
プロンプトのチューニングはひらめきに頼ります。トラブルシューティングは運に頼ります。これは科学ではありません。ある種の魔術です。
死角2：トークン課金はブラインドボックスのようで、月末に痛みを伴う
LLMはトークン単位で課金されます。誰もが知っています。しかし、エージェントとしてのOpenClawには、APIを直接呼び出した場合とは異なるトークン消費パターンがあります。文脈の雪だるま効果があるのです。
各会話ラウンドで、エージェントは過去の会話履歴、システムプロンプト、ツール呼び出し結果をコンテキストに詰め込みます。最初のラウンドでは2000トークンを使うかもしれません。5ラウンド目では20,000に膨らむかもしれません。ツールが大量のHTMLやJSONの塊を返すと、状況はさらに悪化します。
さらに厄介なのは、コストの出どころが分からないことです。モデルが高すぎるのか？ エージェントのプロンプトが冗長すぎるのか？ コンテキストが適切なタイミングでクリップされていないのか？ 細粒度の消費データがなければ、最適化はできません。
死角3：システム状態はシュレーディンガーの猫のよう
OpenClawの運用には、メッセージキュー、Webhook処理、セッション管理が関わります。ユーザーが「なぜ応答しないのか」と聞いたとき、問題はどの層にある可能性もあります。モデル推論がタイムアウトしたのか？ ツール呼び出しが停止しているのか？ メッセージキューが積み上がっているのか？ ゲートウェイが失敗したのか？
リアルタイムのメトリクス監視がなければ、ユーザーのクレームが出てからしか問題に気づけません。その頃には、ユーザーのグループに影響が出ているかもしれません。⏰
2. 解毒薬はここにある：openclaw-cms-plugin + diagnostics-otel、TracesとMetricsが一緒に働く
この3つの「死角」に対処するために、私たちの解決策は2つのプラグインを組み合わせて使用します。これらは異なるレイヤーで問題を解決します：
どちらもOpenTelemetry標準プロトコルに依拠しています。データは一様にAlibaba CloudのCloud Monitor 2.0へレポートされます。同じプラットフォーム上でデータを閲覧・分析できます。
このopenclaw-cms-pluginは本トピックの中心です。これはOpenClaw向けに設計された、トレースレポーティング用のプラグインです。OpenTelemetry GenAIセマンティクスに従い、OpenClawの各実行に対して構造化されたトレースを生成します。
具体的には、次の種類のスパンを記録します：
これらのスパンには親子関係があります。合わせることで、完全なトレースが形成されます。このようなトレースビューを、Cloud Monitor 2.0のコンソールで確認できます：
一目で、LLMが何回呼び出されたか、使われたトークン数はいくつかが分かります。また、どのツールが呼び出されたか、どのステップが最も時間を要したか、そしてエラーが発生したかどうかも確認できます。
「推測」から「見える化」へ進むのは、それほど簡単です。
diagnostics-otelはOpenClawのビルトイン拡張機能です。トークン消費率、呼び出しQPS、応答時間の分布、キューの深さ、セッション状態など、実行時メトリクスデータを出力します。インストールスクリプトが自動的にそれを見つけて有効化します。ほかに何かする必要はありません。
待ってください、diagnostics-otelはトレースも報告しないのですか？ なぜopenclaw-cms-pluginが必要なのでしょう？
良い質問です。diagnostics-otelはトレースレポーティングをサポートしています。ですが、生成されたトレースを注意深く見てみると、根本的な問題が見えてきます。すべてのスパンが独立していて、親子関係がないのです。
diagnostics-otelはイベント駆動型アーキテクチャを使ってスパンを生成します。各イベントは異なるトレースIDで、独立してスパンを作ります。次の5種類のスパンを生成します：
● openclaw.model.usage: モデル呼び出し（トークン使用量を記録）
● openclaw.webhook.processed/openclaw.webhook.error: webhook processing
● openclaw.message.processed: メッセージ処理（レコード処理結果と所要時間）
● openclaw.session.stuck: セッション固着アラート
これらのスパン間には、トレースコンテキストの伝播がありません。つまり、単に独立したデータポイントです。関連付ける唯一の方法は、sessionKey のようなビジネスフィールドを使うことです。
Webhook [openclaw.webhook.processed] traceId: abc123
Message [openclaw.message.processed] traceId: def456 ❌ 異なるトレースID
Model [openclaw.model.usage] traceId: ghi789 ❌ 異なるトレースID
しかし、openclaw-cms-plugin は完全なトレーシングのために設計されています。すべてのスパンが同じトレースIDを共有します。明示的な親子関係によって呼び出しツリーにリンクされます。リクエスト全体像は次のとおりです：
enter_openclaw_system traceId: aaa111
└── invoke_agent main traceId: aaa111 ✅ 同じトレースID
├── chat qwen3-235b traceId: aaa111 ✅ 同じトレースID
├── execute_tool search traceId: aaa111 ✅ 同じトレースID
└── execute_tool exec traceId: aaa111 ✅ 同じトレースID
さらに、トレースの整合性に加えて、2つの間にはデータの豊富さという根本的な違いがあります：
端的に言うと、diagnostics-otel のトレースは独立した「レコードカード」の集合であり、openclaw-cms-plugin のトレースは完全な「インボケーションマップ」です。前者は「何が起きたか」を教えてくれるだけですが、後者は「すべてのステップ」を教えてくれます。両方を一緒に使ってください。1つはシステムメトリクスを扱い、もう1つはビジネストレー スを扱います。両者は完璧に補完し合います。
3.1分でセットアップ：1コマンド統合チュートリアル
十分な理論はこれでおしまい。さっそく始めましょう。統合プロセス全体は1分未満で完了します。
3.1 インストールコマンドを取得する
Cloud Monitor 2.0 コンソールにログインします。アプリケーション監視のワークスペースに移動してください。［Integration Center > AI application observability］を選択し、［OpenClaw］をクリックします。
サイドバーでアプリケーション名を入力し、［Click to obtain］をクリックすると、統合コマンドがすぐに生成されます。右上のアイコンをクリックして、1回でコピーできます。
3.2 1コマンドでインストールを開始する
OpenClaw が実行されているマシン上でターミナルを開きます。コピーしたコマンドを貼り付けて Enter を押します：
curl -fsSL https://arms-apm-cn-hangzhou-pre.oss-cn-hangzhou.aliyuncs.com/openclaw-cms-plugin/install.sh | bash -s -- \
--endpoint "https://Your ARMS-OTLP address" \
--x-arms-license-key "Your license key" \
--x-arms-project "Your project" \
--x-cms-workspace "Your workspace" \
--serviceName "Your service name"
あとは落ち着いて実行を見守るだけです。☕
インストールスクリプトは自動的に次のことを行います：
[INFO] 前提条件を確認しています...
[OK] Node.js v24.14.0
[OK] npm 11.9.0
[OK] OpenClaw CLI が見つかりました
[INFO] プラグインをダウンロードしています...
[OK] ダウンロード完了
[INFO] 展開しています...
[OK] 展開完了
[INFO] npm の依存関係をインストールしています...
[OK] 依存関係のインストール完了
[INFO] diagnostics-otel の拡張を探しています...
[OK] diagnostics-otel が見つかりました： /home/.../extensions/diagnostics-otel
[OK] diagnostics-otel の依存関係はすでに存在します
[INFO] 設定を更新しています...
[OK] 設定を更新しました
[INFO] OpenClaw ゲートウェイを再起動しています...
[OK] ゲートウェイを再起動しました
════════════════════════════════════════════════════
✅ openclaw-cms-plugin は正常にインストールされました！
════════════════════════════════════════════════════
それは何をするの？
✅ 環境を確認します（Node.js、npm、OpenClaw CLI）。
✅ openclaw-cms-plugin を OpenClaw の拡張フォルダーにダウンロードして解凍します。
✅ プラグインの実行時依存関係をインストールします。
✅ diagnostics-otel の拡張を自動的に見つけます。依存関係が不足している場合は、自動的にインストールします。
✅ openclaw.json の設定を更新します（両方のプラグインの設定を一度に書き込みます）。
✅ 設定を適用するためにゲートウェイを再起動します。
設定ファイルを手動で編集する必要はありません。インストールスクリプトは、さまざまな想定外のケースを賢く処理します。既存の設定を上書きするのではなく、更新内容をマージします。さらに、優先度に基づいて diagnostics-otel の複数のインストール可能な場所も検索します。
3.3 インストールを確認する
インストール後は、OpenClaw にチャットしてみてください。1〜2分待ちます。Cloud Monitor 2.0 コンソールを開きます。右側のサイドバーで［AI application observability］に移動します。あなたの OpenClaw アプリケーションが表示されます。おめでとうございます。これでロブスターはブラックボックスではなくなりました。
3.4 削除したくなったら？ もっと簡単です
使うのをやめたい場合（ただ、たぶんそんなことはないと思います）でも、1コマンドでできます：
curl -fsSL https://arms-apm-cn-hangzhou-pre.oss-cn-hangzhou.aliyuncs.com/openclaw-cms-plugin/uninstall.sh | bash
削除スクリプトは自動的にプラグインフォルダーと、openclaw.json 内の関連するすべての設定をクリーンアップします。また、diagnostics-otel の設定も無効にします。トレース用プラグインだけ削除してメトリクスを残したい場合は、--keep-metrics パラメータを追加してください。
きれいに、手早く。副作用なし。
4. 注目ポイント：インストール後に何が見えるの？
統合はただのスタートです。真にワクワクするのは、統合後に見えてくること、そして解決できることです。
返却形式: {"translated": "翻訳されたHTML"}4.1 完全なトレース：その「思考プロセス」をついに理解する
これは openclaw-cms-plugin の中核的な価値です。Cloud Monitor 2.0 は、すべてのユーザーリクエストに対して構造化されたトレースを表示します：
enter_openclaw_system (Request entry: sender and source)
└── invoke_agent main (Agent execution procedure)
├── chat qwen3-235b (LLM invoke: model inference + token usage details)
├── execute_tool search (Tool calling: search)
└── execute_tool exec (Tool calling: code execution)
会話の1ラウンドでは、プラグインはエージェントレベルの LLM 呼び出しと、各独立したツール呼び出しを記録します。エージェントが内部でツールループを実行している場合（例：「invoke tool → get result → invoke next tool」）は、各ツール呼び出しがツールスパンとして個別に記録されます。これには、入力パラメータ、戻り値、実行ステータスが含まれます。ツールチェーン全体の実行手順が、はっきりと見て取れます。
現在のバージョンでは、会話の1ラウンド内の LLM 呼び出しは集計されて 1 つの LLM スパンになります。そのラウンドの最終的な合計トークン使用量と、入力/出力コンテンツを記録します。今後のバージョンではこれをさらに洗練します。各独立した LLM 推論ごとに個別のスパンを生成できるようにします。そうすれば、複数ラウンドのツールループにおける途中の推論ステップも、完全に可視化されます。
各スパンには、豊富なプロパティが注釈として付与されます：
● 所要時間—どのステップが最も遅いかを一目で確認
● モデル情報—どのモデルとプロバイダーが使用されたか
● トークン使用量—input_tokens、output_tokens、cache_read_tokens、total_tokens を、項目ごとに内訳表示
● ツールのパラメータと戻り値—どのツールが呼び出され、どのパラメータが渡され、どんな結果が返ってきたか
● エラーメッセージ—エラーが発生した場合は赤で表示
これはどういう意味でしょうか？
従来は、ユーザーが「答えが間違っている」と言った場合、チャット記録を確認して推測する必要がありました。今はトレースを見ます。検索ツールが空の結果を返しているのが分かります。そのうえで、モデルがその空の結果をもとに「創造的に」段落をでっち上げていました。問題の切り分けにかかる時間が、「2時間」から「2分」へと下がります。⚡
4.2 トークン使用量の内訳—すべての1円がどこに消えるかを正確に把握
トレース内の各 LLM スパンには、完全なトークン使用量のプロパティが含まれます：
gen_ai.request.model と gen_ai.provider.name を使います。どのモデルが、どのステップで、何トークン消費したかを正確に把握できます。
実際のシナリオを考えてみましょう。会話トレースの中に 5 回の LLM 呼び出しが見つかりました。3 回目の呼び出しの input_tokens が 12,000 に到達しているのを見つけます。そこをクリックします。ツールが HTML の1ページ分を返しており、それがすべてコンテキストに詰め込まれているのが分かります。「トークンを飲み込むブラックホール」を見つけたのです。最適化の方向性が、今ここで見えてきます。
トークン使用量は、「ぐちゃぐちゃな帳尻合わせ」から「詳細な台帳」へと変わります。
4.3 システム稼働メトリクス—リアルタイムで脈動が見える
diagnostics-otel プラグインがエクスポートするメトリクスデータは、Cloud Monitor 2.0 上で稼働中のメトリクスゲージを構築できます。これによりリアルタイム監視が可能になります：
● トークン使用率と料金の推移—モデルと時間の次元で分解
● 呼び出し QPS と応答時間—システムのスループットは正常か
● MSMQ の深さと待ち時間—滞留があるか
● セッション詰まり（stall）数—どこかのロブスターが「死んだふり」をしていないか？
● コンテキストサイズの推移—コンテキストが制御不能に膨張していないか？
Ccloud Monitor 2.0 のアラーティング機能と組み合わせることで、毎日のトークン消費が日次で 50% まで急増した場合の自動アラート、キューの深さがしきい値を超えた場合の自動アラート、セッションの詰まりに対する自動アラートを実現します。ユーザーからの苦情を待つのではなく、問題が発生した瞬間にすぐ分かります。
4.4 GenAI セマンティック規約—その場しのぎではなくプロフェッショナルな標準
openclaw-cms-plugin が報告するトレースデータは、OpenTelemetry の GenAI セマンティック規約に厳密に準拠している点に注意してください。これらは、私たちが任意に定義したフィールド名ではなく、国際的な標準です。
つまり：
標準化されたデータ構造—gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.tool.name のようなプロパティ名は業界標準に一致します。これにより、他のツールとの統合が容易になります。
正規化されたメッセージ形式—gen_ai.input.messages、gen_ai.output.messages、gen_ai.system_instructions は、標準の JSON スキーマに従ってフォーマットされます。これにより、TextPart、ReasoningPart、ToolCallRequestPart、ToolCallResponsePart のように複数のメッセージタイプをサポートできます。
将来の拡張性—GenAI セマンティック規約が進化しても、プラグインはスムーズなアップグレードを可能にします。
4.5 標準のさらに先へ—Alibaba Cloud GenAI 規約の「追加の一皿」
OTel のオープンソース標準と互換性がある一方で、openclaw-cms-plugin は Alibaba Cloud GenAI セマンティック規約の拡張機能も実装しています。コミュニティの Standard Edition と比べて、いくつかの「追加の一皿」が提供されます：
ENTRY スパン—トレースの明確な「入口」
返却形式: {"translated": "翻訳されたHTML"}OTelコミュニティの仕様では、LLM（推論）、tool（ツール呼び出し）、agent といった span タイプのみが定義されています。「entry point（入口）」という概念がありません。Alibaba Cloud の仕様では、ENTRY span タイプを拡張して、AIアプリケーションの呼び出し入口を具体的に識別できるようにしています。openclaw-cms-plugin では、これが enter_openclaw_system span です。これは「誰がリクエストを開始したか」（gen_ai.user.id）と「現在のセッションID」（gen_ai.session.id）を記録します。これにより、ユーザーおよびセッションの次元でトレースを可視化し、分析・追跡を行えます。
セッション単位の関連付け —gen_ai.session.id
OTel標準では gen_ai.conversation.id が用意されています。ですが、エージェントアプリケーションの場合、「conversation」よりも「session」のほうが適しています。Alibaba Cloud の仕様では、ENTRY、AGENT、LLM span をまたいで適用される gen_ai.session.id が導入されています。これにより、Cloud Monitor 2.0 でセッションIDを直接検索し、そのセッション配下のすべてのトレースを一度に取得でき、セッション内容を素早く完全復元できます。
gen_ai.span.kind — AI向けの span 分類システム
OpenTelemetry 標準の SpanKind には、CLIENT、INTERNAL、SERVER のような汎用タイプしか含まれていません。AIアプリケーショントレースでは、SpanKind だけでは LLM の推論とツール呼び出しを区別できません。Alibaba Cloud では、GenAI 向けの分類システムを定義する gen_ai.span.kind プロパティを導入しています：LLM、TOOL、AGENT、ENTRY、TASK、STEP（ReAct ラウンド）、CHAIN、RETRIEVER、RERANKER。Cloud Monitor 2.0 はこの分類を使って、AIアプリケーションの構造を自動検出し、専用の AI トレースビューを表示します。LLM の呼び出しはオレンジ、ツール呼び出しはピンク、エージェントはグリーンで表示されます。これにより、トレース全体の「役割分布（role distribution）」を一目で把握できます。
これらの拡張は、標準互換性を損ねません。openclaw-cms-plugin が報告するデータは、OpenTelemetry に対応したどのバックエンドでも、通常どおり基本情報を表示します。しかし、Cloud Monitor 2.0 を使うことで、完全な AI アプリケーションの可観測性体験が解放されます。
この標準化されたアプローチは、将来のデータ分析やプラットフォームの進化にも役立ちます。
5.ブラックボックスから透明へ：可観測性があなたのロブスター養殖を変える方法
X線装置の導入は、あなたの「ロブスター養殖」の方法を根本から変えます：
これは単なる改善ではありません。「目隠し養殖」から「精密養殖」への飛躍です。
農家は「水の色を目視で確認する」から、「水質センサー、カメラ、そして自動給餌システムを使う」へグレードアップします。同じロブスターを扱っていても、コントロールレベルは完全に変わります。
もう一つ：セキュリティ監査
パフォーマンスチューニングやコスト管理を超えて、企業のAIエージェント導入には避けられないテーマがあります。それは「セキュリティコンプライアンス」と「挙動監査」です。エージェントはコマンドを実行し、ファイルを読み書きし、ネットワークリクエストを開始できます。挙動監査の機能がなければ、エージェントがこっそり午前3時にSSH鍵を読み取ったのかどうかを知ることはできません。
私たちの可観測性チームは、別のソリューションでこの能力をカバーしています：Alibaba Cloud Simple Log Service（SLS）のOpenClawワンクリックソリューションです。OpenClawセッション監査ログと、アプリケーションの運用ログを収集します。高リスクコマンドの検知、プロンプトインジェクションの検知、機密データ漏えいの分析など、すぐに使えるセキュリティ監査ダッシュボードを提供します。これにより、あらゆるエージェント操作を追跡可能にします。
セキュリティ監査に関心があるなら、こちらの記事を読んでください：https://www.alibabacloud.com/help/sls/enable-managed-openclaw-with-sls（SLSワンクリック連携と監査ソリューションにより、OpenClawの制御された操作が可能になります）。
Cloud Monitor 2.0 はパフォーマンスとコストを管理し、SLS はセキュリティとコンプライアンスを管理します。合わせて、「ロブスター養殖」のための完全な統制システムを構成します。
6.FAQ
プロセスに関するよくある質問への回答です：
Q: 連携はOpenClawのパフォーマンスに影響しますか？
A: 影響はごくわずかです。openclaw-cms-plugin はOpenTelemetryのバッチエクスポートメカニズムを使います。spanデータはメモリにバッファリングされ、一定間隔でバッチとして報告されます。これはエージェントの通常の処理フローをブロックしません。
Q: メトリクスなしでトレースだけをインストールできますか？
A: はい。インストール時に --disable-metrics パラメータを追加して、diagnostics-otel の設定をスキップします。
Q: diagnostics-otel のトレースは、openclaw-cms-plugin のトレースと競合しますか？
A: インストールスクリプトは、デフォルトで diagnostics.otel.traces を false に設定します。openclaw-cms-plugin がトレースのレポートを担当します。重複せず、それぞれ独立して動作します。
Q: diagnostics-otel を設定しています。インストールは私の設定を上書きしますか？
A: いいえ。トレース、ログ、サンプルレート、その他の設定は変更されません。エンドポイントやヘッダーなどの必要なフィールドを追加するだけです。
Q: 対応している OpenClaw のバージョンは何ですか？
A: バージョンは 26.2.19 以降である必要があります（それ以前のバージョンでは diagnostics-otel プラグインが除外されます）。openclaw-cms-plugin は標準の OpenClaw Hook メカニズムを使って動作します。特定バージョンの内部APIに依存しません。
Q: トークン消費量が常に 0 なのはなぜですか？
A: OpenClaw は V2026.3.8 でバグを導入しました。これにより、トークン消費量の収集が誤って行われます。コミュニティには修正の対応を急ぐよう促しています。関連する課題リンク：https://github.com/openclaw/openclaw/issues/46616
7.まとめ
最初の質問に戻りましょう：あなたのロブスターが海中で何をしているか、わかっていますか？
答えが「わからない」なら、X線装置を導入する時です。
openclaw-cms-plugin + diagnostics-otel、そしてたった1コマンド：10分で連携完了し、OpenClaw に3つの中核機能をもたらします：
✅トレーシング分析— すべての LLM 呼び出し、ツール実行、トークンの流れをエンドツーエンドで可視化。
✅リアルタイムメトリクス— トークン消費率、呼び出しQPS、キューの深さ、セッション状態などをリアルタイムで監視。
✅GenAI のセマンティック標準— 標準化されたデータ構造。コスト分析、パフォーマンス最適化、例外検知の土台を築きます。
ロブスターにブラックボックスの中で「おまかせ（フリースタイル）」をさせないでください。X線装置を導入しましょう。すべてのステップを見える化し、追跡可能にし、最適化できるようにします。
結局のところ、見えるロブスターは良いロブスターです。✨
❓相互作用時間！
OpenClaw を使う中で遭遇した、最も厄介な「ブラックボックス問題」は何でしたか？
今はどのように OpenClaw の問題を切り分けていますか？共有したい小技はありますか？
可観測性を有効にした後、最も見たいデータは何ですか？
コメントで「ロブスター養殖」の気づきを共有してください。質問をお持ちください。私たちはここにいます！
