CLAUDE LABEN
CODE — Claude Codeにリモート管理者向けTrusted Devicesが追加。リモートセッション前に端末を検証できますCODE — ストリーミング時のCPU使用が約37%削減され、長時間の自動運用がより安定しますCODE — フルスクリーンのマウスクリック操作と音声入力の修正、Linuxの音声検出改善が入りましたAUTH — 静的APIキーを、短命でスコープ付きのWIF資格情報へ置き換えられるようになりましたTEAM — SlackでClaudeを直接タグ付けし、作業しながらタスクを委譲できるようになりましたWORKFLOW — dynamic workflowsがリサーチプレビューで登場。込み入った作業を自分で手順に分解しますCODE — Claude Codeにリモート管理者向けTrusted Devicesが追加。リモートセッション前に端末を検証できますCODE — ストリーミング時のCPU使用が約37%削減され、長時間の自動運用がより安定しますCODE — フルスクリーンのマウスクリック操作と音声入力の修正、Linuxの音声検出改善が入りましたAUTH — 静的APIキーを、短命でスコープ付きのWIF資格情報へ置き換えられるようになりましたTEAM — SlackでClaudeを直接タグ付けし、作業しながらタスクを委譲できるようになりましたWORKFLOW — dynamic workflowsがリサーチプレビューで登場。込み入った作業を自分で手順に分解します
記事一覧/API & SDK
API & SDK/2026-06-28上級

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

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

Claude API91MCP37idempotency3automation45reliability10

プレミアム記事

無人で動かしている自動投稿が、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-06-25
API リクエスト1本でリモート MCP サーバーに直接つなぐ — Messages API の MCP コネクタ実装メモ
ローカルに MCP クライアントを立てずに、Messages API の mcp_servers と mcp_toolset だけでリモート MCP サーバーのツールを呼ぶ実装をまとめました。allowlist/denylist 設計、レスポンス処理、無人運用での落とし穴まで。
API & SDK2026-06-14
Claude Agent SDK のツールを冪等にする — 二重実行を止める冪等性キーと Outbox の実装メモ
Claude Agent SDK のリトライやセッション再開で決済を二重処理する事故を防ぐ実装メモ。決定的な冪等性キー・Outbox・軽量ラッパーの3パターンを、動くコードと運用メトリクスつきで設計します。
API & SDK2026-06-02
MCP の tools 以外の3つの能力を使い分ける:resources・prompts・sampling の設計
MCP サーバーで何でも tools にしてしまう設計の限界を、resources・prompts・sampling という3つの primitive で解きほぐします。壁紙アプリのアセット管理サーバーを題材に、判断基準と実装、クライアント対応の現実的な制約までまとめました。
📚RECOMMENDED BOOKS
大規模言語モデル入門
山田育矢
LLM開発
生成AIプロンプトエンジニアリング入門
我妻幸長
プロンプト
Claude CodeによるAI駆動開発入門
平川知秀
AI駆動開発
※ アフィリエイトリンクを含みます
もっと見る →