AI駆動開発の実運用ノート

本編の目次 › 第4部 規律の仕組み化 › 記憶の設計

AI駆動開発の実運用ノート No.102記憶は「肥大」と「同期の取りこぼし」で壊れた

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第4部「規律の仕組み化」から、「記憶の設計」のお話です。

実録記憶は2通りの壊れ方をした

書きすぎでも壊れ、同期漏れでも壊れる
事故何が起きたか確立された型
肥大による停止長文の作業記録を貯め込み、読み出しがサイズ超過エラーで機能停止記憶は要点のみ。実装詳細はイシュー管理へ押し出す(正本の分離)
同期の取りこぼし「コミット成功」に見えて記憶が引き継がれない——DB の書き込みが別ファイルに滞留し、検知フックは「失敗時ほど発動しない」条件になっていた同期は1コマンドに固める・手動手順の禁止・検知器の条件自体を疑う
だから何

「成功したように見えて何も起きていない」サイレント失敗は、記憶・バックアップ系の最頻の死因(第5部 に続く)

設計した記憶が、実際に2通りの壊れ方をしました。

一つは「肥大」です。長い作業記録を貯め込んだ結果、読み出しがサイズ超過で機能停止しました。 書きすぎて読めなくなったわけです。

もう一つは「同期の取りこぼし」です。「コミット成功」に見えるのに、記憶が引き継がれません。 書き込みが別のファイルに滞留していて、しかもそれを検知するはずのフックが「失敗時ほど発動しない」条件になっていました。

「成功したように見えて、実は何も起きていない」。

このサイレント失敗が、記憶やバックアップ系の最も多い死因です。 止まってくれる失敗より、静かに成功を装う失敗のほうが厄介です。 第5部で扱うバックアップの話にもそのままつながります。詳細は事例02に。

つづく