Claude Code（Anthropic製のCLI型AIコーディングエージェント）をMCPサーバー連携やOpenTelemetryによる監視体制の中で運用しているエンジニアに向けて、v2.1.274のリリース内容を整理します。
MCP（Model Context Protocol、LLMが外部ツールやデータソースに接続するための標準プロトコル）は、Claude Codeが社内APIやデータベースに接続する際の共通レイヤーとして使われています。今回のリリースでは、この接続待機の挙動と、モデル呼び出しの可観測性に関わる変更が入っています。単純な機能追加のリストに見えますが、非対話型（non-interactive）実行やLLM運用のモニタリング設計をしている現場には無視できない項目です。
何が変わったのか
最も実務的な変更は CLAUDE_CODE_MCP_STARTUP_WAIT_MS という環境変数の追加です。これはClaude Codeが最初のターン（1回のプロンプト実行）を処理する前に、MCPサーバーの接続確立をどれだけ待つかを制御します。
これまでClaude Codeは、非対話型モード（-p フラグなどでスクリプトから呼び出す使い方）でも、MCPサーバーの起動・接続を待ってから応答を返す挙動でした。CI/CDパイプラインやバッチ処理に組み込んでいる場合、この待機時間が予測できないレイテンシの原因になっていた可能性があります。
CLAUDE_CODE_MCP_STARTUP_WAIT_MS=0 に設定すると、MCPサーバーの接続を待たずに処理を進められます。ツール呼び出しが不要な単純なタスクを自動化パイプラインで流している場合、これで起動待ちの時間を削れます。
OpenTelemetryトレースへのeffort属性追加
もう一つの重要な変更が、claude_code.llm_request というOTel（OpenTelemetryの略、分散トレーシングとメトリクス収集の業界標準規格）のトレーススパンに effort 属性が追加されたことです。これは既存の api_request イベントに合わせる形での拡張になります。
ここでの effort は、Claude のモデルに指定する推論の強度（reasoning effort）を表す属性だと考えられます。Claude Code は --effort フラグでモデルの思考の深さを調整できる仕組みを持っており、これがトレース上でも追跡可能になったことを意味します。
LLMパイプラインを運用していると、「同じモデルなのにレイテンシやコストが安定しない」という問題に遭遇します。effort属性がトレースに乗ることで、リクエストごとの推論強度とレイテンシ・トークン消費量の相関を、Datadog や Grafana などのOTel対応ダッシュボードで可視化できるようになります。
これはLLMの評価パイプライン設計において地味ながら重要な進歩です。モデル評価の現場では「精度とコストのトレードオフ」を定量化する必要がありますが、effort設定が可視化されていないと、A/Bテストの結果にどのパラメータが影響したのか追跡しづらくなります。
関連する信頼性改善
リリースには、MCP周りの接続安定性に関する修正も複数含まれています。
- Streamable HTTP（MCPの新しい通信方式）のツール呼び出しが、サーバー側で長めのタイムアウトを設定していても約5分で強制的にタイムアウトしていた不具合の修正
- legacy HTTP+SSE（Server-Sent Events、旧方式のMCP通信）のみに対応したサーバーが、最初のリクエストに422や4xxエラーを返した場合に接続失敗する不具合の修正
- MCPサーバーが
listChangedを宣言せずに変更通知を送った場合、プロンプトやリソースのリストが更新されない不具合の修正
これらはMCPプロトコルの実装差異に起因する問題です。MCPはまだ仕様が発展途上のプロトコルで、サーバー実装によってSSEベースの旧仕様とStreamable HTTPの新仕様が混在しています。自前でMCPサーバーを実装している場合、どちらの方式で応答しているか、listChanged を宣言しているかを再確認する価値があります。
背景: なぜMCP接続の待機制御が必要か
MCPはAnthropicが2024年に公開したオープンな仕様で、LLMエージェントが外部システム（データベース、API、ファイルシステムなど）に統一的な方法でアクセスするための規格です。RAG（Retrieval-Augmented Generation、検索で得た情報を元に生成する手法）を実装する際、ベクトルDBやドキュメントストアへの接続をMCP経由で行う構成も増えています。
しかし接続確立には時間がかかります。認証、ハンドシェイク、ツール一覧の取得などのステップがあり、サーバー側の起動が遅い場合、Claude Code側の処理全体がブロックされてしまいます。CLAUDE_CODE_MCP_STARTUP_WAIT_MS はこの依存関係の強さを調整するためのノブと言えます。
同様の設計思想は、KubernetesのreadinessProbeや、gRPCのconnect timeoutにも見られます。外部依存が必須なら十分に待つ、不要ならタイムアウトを切って処理を進める、という選択を明示的に設定できる点は共通しています。
今日確認できること
実際にClaude Codeを運用しているなら、以下を確認する価値があります。
claude --versionバージョンが v2.1.274 以降か確認します。古い場合は claude update や配布元のパッケージマネージャーで更新できます。
非対話型実行をパイプラインに組み込んでいる場合は、環境変数を試してみます。
export CLAUDE_CODE_MCP_STARTUP_WAIT_MS=0
claude -p "タスクの内容"MCPツールを使わないタスクであれば、起動待ちがなくなり応答が速くなるはずです。ツールが必要なタスクで 0 にすると接続前にツールが使えず失敗する可能性があるため、用途を分けて設定するのが安全です。
OTelでモニタリングしている環境では、claude_code.llm_request スパンに effort 属性が乗っているか確認します。設定は OTEL_EXPORTER_OTLP_ENDPOINT などのOpenTelemetry標準の環境変数、および OTEL_LOG_MANAGED_SETTINGS=1 によるmanaged-settings関連イベントのログ出力を、公式ドキュメントのテレメトリ設定セクションで確認するのが確実です。
まとめ
v2.1.274は機能追加というより、運用の可視性と安定性を高める調整のリリースです。
CLAUDE_CODE_MCP_STARTUP_WAIT_MSでMCP接続待機を制御し、非対話型パイプラインのレイテンシを見直せますeffort属性がOTelトレースに追加され、推論強度とコスト・レイテンシの相関を追跡しやすくなりました- Streamable HTTPやlegacy SSEのMCP実装差異による接続不具合が複数修正されています
MCPサーバーを自前運用している場合は、通信方式（Streamable HTTPかSSEか）と listChanged 宣言の有無を一度点検しておくと、今回の修正の恩恵を受けやすくなります。