◉CLAUDE LABEN
●2.1.283 — 週末の Claude Code リリースはなく、最新は 9月25日の 2.1.283 のまま。権限モード未設定時の既定が auto に変わった点は、許可ルールとの照合が要ります●PLANS — Pro と Team Standard の既定モデルが Sonnet から Opus へ。Claude Code 2.1.280 の変更で、プラン選びの前提が変わっています●10/07 — Claude Desktop / Cowork の管理構成キー旧綴りの受付終了まで残り9日。締切後は読み込みが fail-closed になります●AUTO — 「許可ルールに書いたコマンドが auto モードで拒否される」という問いが出ています。呼ぶ形を許可ルールに揃える話題です●NEW — 既定の Opus が 5.5 に変わった週、別名のまま残していた3箇所の確認●CURSOR — Cursor 経由で Claude を使うとクレジットがモデル原価に比例して減る構造。1日50件を超えるなら定額の Claude Code Pro が安定という整理が出ています●2.1.283 — 週末の Claude Code リリースはなく、最新は 9月25日の 2.1.283 のまま。権限モード未設定時の既定が auto に変わった点は、許可ルールとの照合が要ります●PLANS — Pro と Team Standard の既定モデルが Sonnet から Opus へ。Claude Code 2.1.280 の変更で、プラン選びの前提が変わっています●10/07 — Claude Desktop / Cowork の管理構成キー旧綴りの受付終了まで残り9日。締切後は読み込みが fail-closed になります●AUTO — 「許可ルールに書いたコマンドが auto モードで拒否される」という問いが出ています。呼ぶ形を許可ルールに揃える話題です●NEW — 既定の Opus が 5.5 に変わった週、別名のまま残していた3箇所の確認●CURSOR — Cursor 経由で Claude を使うとクレジットがモデル原価に比例して減る構造。1日50件を超えるなら定額の Claude Code Pro が安定という整理が出ています
記事一覧/API & SDK
⬡ API & SDK/2026-06-28上級

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

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

Claude API123MCP54idempotency3automation55reliability15

✦ プレミアム記事

無人で動かしている自動投稿が、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/月 または ¥2,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駆動開発
※ アフィリエイトリンクを含みます