Honeycomb MCPは移行が必須に — 自己ホスト版はアーカイブ済み

観測データ基盤Honeycombが提供していた自己ホスト版のMCPサーバーhoneycomb-mcpは、GitHub上でアーカイブ済みになりました。ローカルでNodeプロセスを起動する運用は終わり、Honeycombが管理するホスト型サーバーhttps://mcp.honeycomb.io/mcpへの接続が唯一の選択肢です。移行そのものはコマンド1行で終わりますが、認証方式とツールの数が変わるため、単純な置き換えでは済みません。

自己ホスト版のHoneycomb MCPに何が起きたか

honeycombio/honeycomb-mcpリポジトリは2024年12月に公開され、2025年8月21日の更新を最後にアーカイブされています。READMEの冒頭には「この自己ホスト版MCPサーバーは非推奨です」という警告が残り、ホスト型ドキュメントへの移行を案内する形になりました。

自己ホスト版の設計は次のような前提に立っていました。

• ユーザーが自分のマシンでNodeプロセスを1つ起動し続ける
• 通信はSTDIOで、サーバー自体には認証機構がない
• 環境変数HONEYCOMB_API_KEYにクエリ・SLO・Trigger閲覧を含む広範囲な権限のAPIキーを渡す
• Honeycomb Enterprise契約のチームのみが対象

ツールはデータセット一覧・クエリ実行(COUNT/AVG/P95などの集計)・カラム分析・SLO/Triggerの閲覧・トレースへのリンク生成・OpenTelemetry計装ガイドの9種類程度に絞られていました。ローカルで動かす分、外部からの侵入経路は限られますが、キー自体が漏れれば全操作が可能という設計でもあります。

ホスト型Honeycomb MCPへ接続する

前提として、HoneycombチームのHoneycomb Intelligence機能がTeam Ownerによって有効化されている必要があります。無効なままだと接続自体はできても、ツールが1つも見えません。

Add the Honeycomb MCP server at https://mcp.honeycomb.io/mcp and authenticate with OAuth.

自然文でこう頼むだけで、Claude CodeがMCPサーバーを追加してOAuth認証のフローを開始します。手動で設定する場合は次のコマンドです(EUリージョンのチームはmcp.eu1.honeycomb.ioを使います)。

claude mcp add honeycomb --transport http https://mcp.honeycomb.io/mcp

登録後、ブラウザでHoneycombへのサインインと権限許可を済ませれば接続完了です。Honeycombはエージェント向けのスキル集も別リポジトリ(honeycombio/agent-skill)で配布しており、Claude Codeのプラグインとして入れると/honeycomb-setupコマンドでリージョン設定と認証、スキルの導入までまとめて済ませられます。

claude plugin marketplace add honeycombio/agent-skill
claude plugin install honeycomb

CIやスケジュール実行のように対話的なOAuthが使えない場合は、APIキー認証に切り替えます。Honeycombのアカウント設定でManagement API Keyを発行し、mcp-remote経由でBearerトークンとして渡す構成です。

{
  "mcpServers": {
    "honeycomb": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.honeycomb.io/mcp",
        "--header",
        "Authorization: Bearer $HONEYCOMB_API_KEY"
      ],
      "env": {
        "HONEYCOMB_API_KEY": "<KeyID>:<SecretKey>"
      }
    }
  }
}

キーは<Key ID>:<Secret Key>の形式で、コロンが必須です。書き込み系ツールを使わないならReadスコープだけで十分で、MCPとEnvironmentsの両方に読み取り権限を付けます。

自己ホスト版から何が変わったか

移行で変わるのは接続方法だけではありません。実行場所・認証・利用可能な機能のいずれも別物になります。

Enterprise限定という縛りが外れた一方、get_service_map(サービス依存関係のスナップショット)のように一部のツールだけEnterprise限定のバッジが付いたまま残っています。全面的な下位互換ではなく、機能ごとに条件が分かれる形です。

増えたツールで何ができるようになったか

新設されたget_workspace_contextはチーム名・現在時刻・環境ごとのデータセット数を返すだけの単純なツールですが、エージェントはたいてい何か具体的な作業に入る前にまずこれを呼び、自分がどのHoneycombチームのどの環境に接続しているかを確認してから動き出します。自己ホスト版には無かった「エージェントが最初に自分の立ち位置を確認する」という起点が明示的なツールとして加わった形です。

自己ホスト版はクエリ・SLO・Trigger監視という「数値を見る」用途が中心でした。ホスト型はそこにトレース単位の調査を足しています。get_traceは特定のトレースIDのスパンをウォーターフォール表示に変換し、list_spansとget_span_detailsは「どのスパン名がよく現れ、どの属性を持つか」をエージェントが自分で探索できるようにします。COUNTやP95のような集計だけでなく、1件のリクエストがどこで詰まったかまで自然文で追えるようになった点が実質的な差です。

チームで調査結果を残すCanvas投稿機能(canvas_agent_invoke/canvas_agent_poll_response)も新規です。チャットセッションが終わると消えていた調査過程を、Boardと同じようにチームで見返せる形に変換します。もう1つ、list_aiconversations/get_aiconversationは自分たちが運用するAIエージェントが出すgen_ai.*属性のテレメトリを解析するツールです。Claude CodeのOpenTelemetry出力をHoneycombに送っている場合、このツールでエージェント自身の呼び出し回数やエラー率を追う使い方ができます。

Board自体の作成・更新(create_board/update_board)、Trigger・SLO・通知先の作成・更新も新たにMCP経由でできるようになりました。自己ホスト版はSLOとTriggerを閲覧するだけでしたが、ホスト型はしきい値を跨いだら通知するTriggerを対話の中で作るところまで任せられます。書き込み系ツールはすべてmcp:writeスコープが要ることに注意します。

利用シーン別にどのツールが効くか

すべてのツールを覚える必要はありません。役割によって触るツール群は自然に絞られます。

run_queryのようなクエリ系ツールは大半が毎分100回、get_workspace_contextのような読み取り専用の探索系は毎分200回までとレート制限に幅があります。書き込み系(create_triggerなど)は毎分20回、get_service_mapのように重い集計は毎分10回とさらに絞られているので、自動化ワークフローに組み込む場合はこの粒度を踏まえてリトライ間隔を設計します。

Claude Code自身をHoneycombで観測する

ホスト型ならではの使い方として、Claude CodeのOpenTelemetry出力先をHoneycombにし、Honeycomb MCP経由でClaude Code自身の挙動を調べるという構成があります。エージェントを使ってエージェントを調べる、いわゆるメタ観測です。

Claude CodeはOpenTelemetryのGenAIセマンティック規約に沿ったトレースを出力しており、これはlist_aiconversations/get_aiconversationが前提にしているデータ形状と同じです。エクスポート先の環境変数を設定し(CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1でより詳細なトレースが有効になります)、OTEL_EXPORTER_OTLP_ENDPOINTをHoneycombのOTLPエンドポイントに向け、OTEL_EXPORTER_OTLP_HEADERSにIngest APIキーをx-honeycomb-teamヘッダーとして設定すれば、テレメトリが流れ始めます。

流れ始めたあとは、次のような質問がそのまま使えます。

• 「今週トークンを一番使ったClaude Codeセッションはどれ?」— gen_ai.usage.input_tokensとoutput_tokensをセッションIDやユーザーごとに集計します
• 「失敗率が一番高いツールはどれ?」— tool.nameとtool.outcomeでグループ化し、不安定なMCPサーバーやHooks、Bashパターンを洗い出します
• 「今日、権限プロンプトでブロックされたツール呼び出しと待ち時間は?」— claude_code.tool.blocked_on_userスパンを掘り下げます

この仕組みはClaude Code固有ではなく、gen_aiセマンティック規約に沿ったテレメトリを出す他のエージェントにも同じMCPワークフローが使えます。

よくあるつまずき

• ツールが1つも表示されない: 認証は成功しているのに何も呼べないなら、まずTeam OwnerにHoneycomb Intelligenceの有効化を確認してもらいます。個人の認証設定では解決しません
• APIキー認証が拒否される: <Key ID>:<Secret Key>のコロンが抜けている、またはBearerプレフィックスの位置がクライアントの期待と噛み合っていないケースが大半です。ヘッダーに直接Bearerを含める方式と、環境変数側に含める方式のどちらかに揃えます
• 急にツールが失敗し始める: MCPのセッションは24時間で切れます。新しいチャットを開始すれば再接続されます
• レート制限エラー: 大半のツールは毎分50回が上限で、get_service_mapは毎分10回とさらに厳しく設定されています。頻発するなら呼び出し頻度を見直すか、プランのアップグレードを検討します
• 無認証だった頃の感覚でOAuth画面が出て戸惑う: 自己ホスト版はローカルのAPIキーを渡すだけで動いていたため、ホスト型で初めてブラウザの認証画面が挟まると設定ミスに見えることがあります。これは仕様どおりの挙動で、認証自体は正常です

まとめ

自己ホスト版honeycomb-mcpをClaude Code経由で使っていたチームは、アーカイブされた今も手元のプロセスが動く限り機能自体は止まりません。ただし更新は今後入らず、いずれ壊れても直されない状態です。移行作業自体はclaude mcp addコマンド1行と、チーム側でのHoneycomb Intelligenceの有効化確認だけで完了します。トレース調査やCanvas投稿など、旧版になかった機能も一緒に手に入るため、後回しにする理由は薄いといえます。

MCP接続の--transportオプションやスコープ管理の詳細はClaude Code MCP設定ガイドにまとめています。Claude Code自体のOpenTelemetry出力を設定していない場合はClaude CodeのOpenTelemetryで利用量とコストを可視化が前提の設定手順です。MCPのHost/Client/Server構造そのものを理解したい場合はMCPアーキテクチャの三層構造が参考になります。