事後報告（ポストモーテム）の読み方: 品質低下の3つの問題
読むポイントを順に案内します。
Anthropicが、2025年8月から9月にかけてClaudeの応答品質が下がった3つの問題について、原因と対応を説明した技術ブログです。公開日は2025年9月17日と表示されていたとのことです（要約経由）。
読む文書：A postmortem of three recent issues（Anthropic Engineering）
1日付と見出しの順を見る
構成は、導入、どう提供しているか、時系列、3つの問題、コンパイラの不具合の詳細、検出が難しかった理由、今後の変更、謝辞の順です（要約経由）。
ここで注意：事後報告は「何が起きたか」「なぜか」「なぜ気づけなかったか」「何を変えるか」の4問に答える形が多いです。見出しがその4問に対応しているか確かめます。
2影響の期間と割合を問題ごとに控える
1つ目は、短い文脈の依頼が別のサーバーに送られた問題で、8月5日に始まり、最悪の1時間は8月31日で、あるモデルの依頼の一部に影響したと書かれています。2つ目は意図しない文字が出る出力の破損で8月25日から。3つ目はコンパイラの不具合で、8月25日に入った変更がきっかけとのことです（要約経由）。
ここで注意：問題ごとに期間、対象のモデル、対象の経路（自社API、クラウド経由）が違います。1つにまとめず、問題ごとにメモを分けます。
3原因の書き方を読む
3つとも、設定や経路の誤り、実行時の最適化、コンパイラの不具合といった基盤側の不具合として説明されています。会社は、需要を理由に品質を下げることはない、不具合は基盤の問題だけが原因だった、という趣旨を書いているとのことです（要約経由）。
ここで注意：これは会社自身の説明です。第三者の検証ではありません。「会社が何と書いたか」と「外部が確かめたこと」は分けて読みます。
4なぜ検出が難しかったかを読む
評価（テスト）で劣化を捉えきれなかった、プライバシー保護のためエンジニアが利用者の会話を自由に見られなかった、不具合ごとに症状がプラットフォームで違い、報告がばらばらに見えた、などが挙げられています（要約経由）。
ここで注意：検出の難しさの説明は、仕組みの弱点が分かる部分です。ただし、これは会社の自己評価で、全体の評価は別の話です。
5再発防止の約束を、できたかどうかと分けて読む
より敏感な評価を作る、本番環境で品質評価を継続して走らせる、フィードバックの調査道具を作る、アプリのボタンやClaude Codeの/bugコマンドで報告してほしい、と書かれています（要約経由）。
ここで注意：「〜する」は公開日時点の約束です。実際に実施されたかは、この文書だけでは分かりません。
この種の文書を読むときの型
事後報告は、期間、対象、原因、検出、再発防止の5点を自分の言葉で表にして読みます。「会社の説明」「分かっていること」「まだ分からないこと」を分けて書くと、断定と推測を混ぜずに済みます。
確認できていない点（3件）
- WebFetchの要約経由のため、原文の文言は確認していません（引用は空にしています）。
- 日付、割合、モデル名の細部は要約で確認したもので、原文の表記と照らしていません。
- 再発防止策がその後実施されたかどうかは、この文書の範囲では確認できていません。
確認日：2026年10月16日。取得は要約経由のものを含みます。原文は、上のリンク先で必ず確かめてください。
ラボの資料は、公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。日付や仕様は変わるので、使う前に各ページの出典で確かめてください。事実と「僕らの見立て」は、分けて書いています。