朝の定期処理は終わっている。でも、売上表を読むはずのAIがMCPサーバーへつながらないまま、手元の情報だけで回答していた。エラーで止まれば気づけます。怖いのは、道具が欠けた状態でも自然な文章が返ってくることです。
Claude Code v2.1.274では、非対話実行の最初のターンがMCP接続を待つ時間を、CLAUDE_CODE_MCP_STARTUP_WAIT_MSで制限できるようになりました。待ち時間を決めるだけの小さな追加ですが、定期処理では「何秒待つか」「接続できなければ止めるか」を運用側で決める入口になります。
v2.1.274で追加・修正されたこと
公式リリースには、MCP起動待ちに関係する変更が四つあります。
CLAUDE_CODE_MCP_STARTUP_WAIT_MSを追加。最初の非対話ターンがMCPサーバーへの接続を待つ時間に上限を設定できます。0は待たない指定です。- 古いHTTP+SSE方式だけを話すMCPサーバーが、最初の要求へ422などの4xxを返した場合の接続失敗を修正。
- Streamable HTTPのMCPツール呼び出しが、サーバー側で長いtimeoutを設定していても約5分で切れる問題を修正。
- 403
insufficient_scopeをログイン期限切れと誤って表示せず、不足している権限を示して/mcpでの再認証へ案内するよう修正。
同じリリースでは、MCPサーバーがlist-changed通知を送った際のpromptやresourceの更新、破損した会話記録によるunexpected tool_use_idの無限再試行も直しています。接続、実行中、復旧のそれぞれで、止まり方と原因表示を改善した更新です。
待ち時間は「速さ」ではなく実行条件
起動待ちを短くすれば、cronやCIは早く動き始めます。ただし、必要なMCPが間に合わない状態で処理を始めてよいとは限りません。
たとえば、顧客台帳をMCP経由で読む月次レポートなら、その接続は必須です。接続できないまま文章だけ作ると、数字が古い、顧客が抜ける、根拠が追えないという事故になります。逆に、MCPは補助検索だけで、入力ファイルが正本なら、接続を待たずに処理を続けられる場合もあります。
先に決めるのは秒数ではありません。仕事ごとにMCPを「必須」と「補助」に分けます。必須が一つでも欠けたらHOLD。補助だけが欠けた場合は、出力に制約を残して限定GO。この順番なら、待ち時間の設定が単なる高速化で終わりません。
定期処理に入れる三段階の受け入れテスト
僕なら、本番の定期処理へ入れる前に三つだけ試します。
- 正常系。必要なMCPをすべて起動し、最初のターンが接続完了後に始まるか確認する。出力には、実際に使ったMCPと取得時刻を残します。
- 遅延系。検査環境でMCPの起動を意図的に遅らせ、設定した上限で待ちが終わるかを見る。その後、必須MCPなしで処理が続かないことも確認します。
- 権限不足系。検査用の資格情報から必要scopeを外し、403が「期限切れ」ではなく権限不足として判別できるか確認する。再認証後に同じテストを繰り返します。
記録するのは、Claude Codeのバージョン、実行入口、待ち時間、MCP名、transport、接続結果、失敗理由、ジョブの最終状態です。顧客データや認証情報そのものは記録しません。接続診断のために、別の情報漏えいを作る必要はありません。
OpenTelemetryで「つながらなかった」を残す
Claude Codeの公式監視文書では、OpenTelemetryを有効にすると、mcp_server_connectionイベントで接続、切断、接続失敗を記録できます。server名、transport、scope、エラー詳細が対象です。tool_decisionとtool_resultを組み合わせれば、MCPツールが許可されたか、実際に実行されたかも追えます。
v2.1.274では、claude_code.llm_requestのtrace spanにeffort属性も追加されました。また、claude_code.managed_settings_resolvedイベントで、管理設定の取得元やpolicy helperの状態を確認できます。後者の設定値は編集済みの形で、OTEL_LOG_MANAGED_SETTINGS=1を有効にした場合に記録されます。
監視を有効にすれば安全になるわけではありません。公式文書も、prompt、応答本文、ツール引数、API bodyの記録は個別のフラグで制御し、既定では本文を伏せる設計を示しています。接続状態を調べたいだけなら、prompt全文や顧客ファイルまで収集しない。ログは少ないほうが扱いやすく、漏えい時の範囲も抑えられます。
待ち時間の決め方
一律に30秒や60秒と決めるより、ジョブの性質から上限を置くほうが扱いやすいです。まず、普段のMCP起動時間を複数回測ります。そのうえで、通常のばらつきを吸収できる時間を設定し、超過を障害として数えます。最初から長い上限を置くと、本当に止まっているのか、ただ待っているのか分からない時間が増えます。
請求、在庫、顧客対応など、遅延より欠落のほうが痛い処理では、必須MCPの接続確認を優先します。数分遅れても、正しい台帳を読んでから出力するほうが安全です。社内の下書きや補助検索なら、短い上限で切り上げ、使えなかった情報源を明記して続きを人へ渡せます。
0を指定する運用は慎重に扱います。待たないこと自体が問題なのではありません。ジョブの開始前に別のヘルスチェックがあり、必要な接続を確認済みなら合理的です。そうした前段がないまま0にすると、起動直後の一時的な遅れまで「ツールなしで実行してよい」という判断に変わります。
障害時の出力を先に決める
MCP接続に失敗したとき、AIへ長い説明を書かせる必要はありません。ジョブID、失敗したMCP名、時刻、再試行の有無、最終状態だけを通知し、業務の成果物は作らないほうが安全です。途中まで作ったレポートを正式版の保存先へ置くと、人が完成品と誤認します。
再試行も無制限にしません。v2.1.274は、破損した会話記録でunexpected tool_use_idが起きた際、可能なら自己修復し、無理なら/rewindの案内付きでループを終える修正を含みます。これは終了条件の重要性を示す例です。接続障害でも、回数と総時間に上限を置き、それを超えたら人へ渡します。
完了判定には「文章を保存した」ではなく、「必須MCPが接続済み」「対象ツールを実行済み」「正本の取得時刻を記録済み」を使います。AIの返答は成果物ですが、完了の証拠ではありません。どの入口から何を読んだかまで確認して、初めて業務を閉じられます。
GOとHOLDの境目
非対話処理でMCPを使っているチームは、v2.1.274を検証対象にしてよいでしょう。三段階テストが通り、必須MCPの未接続時にジョブが失敗扱いになり、監視側でも原因を判別できれば限定GOです。
必須MCPが欠けても成功扱いになる、待ち時間を超えて止まり続ける、403の原因を区別できない、ログへpromptや認証情報が出る場合はHOLDです。接続先を増やす前に、失敗時の終了条件とログ項目を直します。
CLAUDE_CODE_MCP_STARTUP_WAIT_MSは、MCPの可用性を保証しません。サーバー障害、権限設定の誤り、取得データの品質、ツールが返した内容の正しさも別に検査が必要です。今回の設定が決めるのは、最初のターンで何秒待つかだけです。
それでも、定期処理では十分に意味があります。AIへ仕事を委譲するとき、入口で使う道具がそろっているかを確認し、欠けていれば止める。自然な文章が返ったかではなく、必要な情報源を使って完了したかで判定するほうが、業務の事故を減らせます。
一次情報
機能の説明は上記の公式リリースと公式文書に基づきます。MCPの必須・補助分類、三段階テスト、限定GO/HOLDはmonobloによる運用提案です。