CLAUDE LABEN
MEMORY — Claude Codeの長時間セッションのメモリリークが一掃されました。MCP stdioサーバのstderrが最大64MB蓄積する問題やLSPドキュメントの開きっぱなしが修正されていますTABLES — 非常に大きなmarkdownテーブルが描画を止める不具合を修正。200行を超えるテーブルは先頭200行と「… N more rows」表示になりますSPEED — deny/askルールを多く抱えたセッションで毎ターン数秒遅くなる問題を修正。ルールマッチャがコンパイルして再利用されますTOOLS — MCPツールが多いprint/SDKセッションでは、ツールプールの組み立てをキャッシュし最大7倍速いラウンドになりましたARTIFACTS — Claude CodeのArtifactsは、セッションの作業をその場で更新される共有Webページに変えます。PR解説やダッシュボードに使えますDEADLINE — 7月24日にOpus 4.7のfastモードが削除されます。speed: "fast" はエラーになるため、Opus 4.8のfastモードへ移行が必要ですMEMORY — Claude Codeの長時間セッションのメモリリークが一掃されました。MCP stdioサーバのstderrが最大64MB蓄積する問題やLSPドキュメントの開きっぱなしが修正されていますTABLES — 非常に大きなmarkdownテーブルが描画を止める不具合を修正。200行を超えるテーブルは先頭200行と「… N more rows」表示になりますSPEED — deny/askルールを多く抱えたセッションで毎ターン数秒遅くなる問題を修正。ルールマッチャがコンパイルして再利用されますTOOLS — MCPツールが多いprint/SDKセッションでは、ツールプールの組み立てをキャッシュし最大7倍速いラウンドになりましたARTIFACTS — Claude CodeのArtifactsは、セッションの作業をその場で更新される共有Webページに変えます。PR解説やダッシュボードに使えますDEADLINE — 7月24日にOpus 4.7のfastモードが削除されます。speed: "fast" はエラーになるため、Opus 4.8のfastモードへ移行が必要です
記事一覧/API & SDK
API & SDK/2026-06-28上級

接続が切れた瞬間、その投稿は通ったのか — 無人パイプラインで MCP 書き込みを二重実行せずにやり直す

接続断で中断した MCP の書き込みツール呼び出しは、サーバー側で実行されたかどうか分かりません。素朴な再試行が二重投稿を生む理由と、冪等キーと照合読み取りで安全にやり直すラッパーの実装を、無人パイプラインの実例とともにまとめました。

Claude API115MCP44idempotency3automation52reliability14

プレミアム記事

無人で動かしている自動投稿が、X への投稿リクエストの途中で接続を切られたことがあります。返ってきたのはタイムアウトのエラーだけで、投稿が通ったのかどうかは分かりませんでした。ログには「失敗」と残っていたのに、数分後にタイムラインを見ると、同じ内容がちゃんと投稿されていたのです。サーバー側では成功していて、こちらに結果が届かなかっただけ、という状態でした。

このとき素朴に「失敗したならやり直そう」と再実行していたら、同じ投稿が2つ並んでいたはずです。個人開発で複数サイトの告知を自動化している立場からすると、これは品質以前の事故です。読者から見れば、同じ内容を2回流すだけで「雑な運用をしている」という印象になります。書き込み系のツール呼び出しを無人で回すなら、この「通ったのか分からない」状態を正面から設計しておく必要があります。

「失敗」と「不明」は別物です

エラーには2種類あります。サーバーが「あなたのリクエストは受け付けません」と明確に拒否した失敗と、応答が返る前に通信が切れた不明です。前者は安全にやり直せます。サーバーは何もしていないと分かっているからです。

やっかいなのは後者です。リクエストはサーバーに届いて処理されたかもしれないし、届く前に切れたのかもしれません。こちら側からは区別がつきません。これは分散システムでよく知られた問題で、送信側は「相手が実行したか」を確実には知り得ません。タイムアウト、接続のリセット、ストリームの途中切断は、すべてこの「不明」に分類すべきものです。

2026年6月27日の更新で Claude Code の MCP まわりのレジリエンスが上がり、ストリームの途中で接続が切れても部分応答を保持するようになりました。受信側の粘りは確実に改善しています。それでも、書き込みツールの呼び出しが途切れた瞬間に残る「サーバー側で実行されたか」という不確実性は、受信側の改善だけでは消えません。ここはアプリケーション側で設計する領域です。

実装でつまずきやすいのは、エラーの分類です。HTTP の 5xx は「サーバーが処理に失敗した」とも「処理はしたが応答だけ落ちた」とも取れるため、安易に failed へ寄せると危険です。私は迷ったエラーはすべて uncertain に倒す方針にしています。uncertain は復旧フェーズで照合して決着するので、過剰に uncertain と判定しても二重実行にはつながりません。逆に、本来 uncertain なものを failed と誤判定すると即座に二重実行へ直結します。分類に迷ったら安全側、つまり uncertain へ倒すのが鉄則です。本番運用では、この誤判定こそが最も怖い落とし穴です。安全側へ倒すという一点を守るだけで、二重実行の大半は回避できます。

なぜ素朴な再試行が二重実行を生むのか

リトライ処理を書くとき、多くの人は状態を2つで考えます。成功か、失敗か。失敗ならやり直す。この設計が二重実行の温床です。

「不明」を「失敗」に丸めてしまうと、実はサーバー側で成功していたケースまで再実行してしまいます。投稿なら二重投稿、課金なら二重請求、メール送信なら二通目です。私が最初に踏んだのもこれでした。リトライ用のラッパーを except Exception: で雑にくくり、中で無条件に再送していたのです。テスト環境では一度も再現せず、本番で接続が不安定になった夜に初めて二重投稿が出ました。

正しくは、状態を3つに分けます。成功(committed)、明確な失敗(failed)、不明(uncertain)です。再実行してよいのは failed のときだけで、uncertain のときは「やり直す前に確かめる」という一手を必ず挟みます。

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
接続断を『失敗』ではなく『不明(uncertain)』として扱う3状態の台帳設計と、なぜ2状態では破綻するのか
冪等キーを受け付けない MCP ツールを、相関トークンの照合読み取りで二重実行から守る Python ラッパーの実装
再実行してよい場合・してはいけない場合を、二重実行のコストと取りこぼしのコストで判断する表
Stripe による安全な決済 · いつでもキャンセル可能

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Claude Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • コピー&ペーストで使える実装コード付き
  • 毎日新しい上級ガイドを追加
  • ¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

API & SDK2026-07-08
MCP コネクタを申請・無人運用に回す前に、各ツールを契約テストで確かめる
手元で動いた MCP コネクタをそのまま無人ジョブに繋ぐと、応答形状の誤読や書き込みの二重発火で静かに壊れます。ツール記述・応答契約・冪等性・レイテンシを機械検証する小さなハーネスの作り方を、実測値とともにまとめました。
API & SDK2026-06-30
ツール出力が大きすぎてコンテキストを溶かす問題 — カーソルで小分けに返すページング設計
一覧系のツールが数百件をそのまま返すと、エージェントのコンテキストは一回の呼び出しで溶けます。カーソルベースのページングでツール出力を小分けに返し、トークン予算を守る設計を実装コード付きで解説します。
API & SDK2026-06-25
API リクエスト1本でリモート MCP サーバーに直接つなぐ — Messages API の MCP コネクタ実装メモ
ローカルに MCP クライアントを立てずに、Messages API の mcp_servers と mcp_toolset だけでリモート MCP サーバーのツールを呼ぶ実装をまとめました。allowlist/denylist 設計、レスポンス処理、無人運用での落とし穴まで。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →