『後でやる』を腐らせない：deferred判断をcheckpoint化する記憶設計

AI agent と作業していると、**「これは今決めなくていい、後でやろう」**という判断が頻繁に出てきます。Phase 分離、Issue 化、TODO 追加。どれもよくある対処です。

しかし6ヶ月後、その「後でやろう」は確実に忘れられます。本記事は、deferred 判断を 「いつ何を見たら判断するか」のチェックポイントとして、AI agent の外部記憶に固定する運用ルールの記録です。

事の発端：3ヶ月前のTODOコメントが「腐っていた」

リポジトリを整理していて、こんな TODO コメントを見つけました。

1
# TODO: もしレスポンス時間が500msを超えるようになったら、
2
# キャッシュ層を入れる検討をする

書いた日付: 3ヶ月前。現在のレスポンス時間: 800ms。

つまり、判断トリガーはとっくに発火していたのに、コメントは静かに残ったままでした。誰も気づかなかった理由は単純で、

コメントを見るには該当ファイルを開く必要がある
そのファイルは最近誰も触っていない
レスポンス時間のメトリクスは別の場所で観察されている

「判断条件」と「判断する場所」が物理的に分離されているため、トリガーが満たされても誰も気づきません。

TODO / Issue が腐る構造的理由

「後でやる」を記録する代表的な手段は、TODOコメント、Issue、ドキュメントです。それぞれの腐り方を整理すると:

TODOコメントが腐る理由

ファイルを開かないと見えない
リファクタリングで消されることもある
grep しないと全件把握できない
判断条件と現状が乖離しても警告されない

Issue が腐る理由

大量に積まれていると埋もれる
「後で見る」ラベルがついた瞬間に忘却される
判断トリガーをチェックする仕組みがない

ドキュメントが腐る理由

書いた本人しか参照しない
検索性が低い
書かれた内容と現実の同期手段がない

共通するのは、「いつ判断するか」のトリガー部分が外部システムと結合していないことです。

checkpoint 化：判断トリガーを記憶に外部化する

そこで運用ルールを作りました。

deferred 判断は、TODO/Issue/ドキュメントに書く前に、checkpoint として AI agent の長期記憶に登録する。

checkpoint には以下を含めます。

1
type: deferred_decision
2
created: 2026-05-17
3
trigger:
4
  what: response_time
5
  threshold: 500ms
6
  source: dashboard URL or query
7
decision: キャッシュ層を入れるか
8
context: |
9
  現状 200ms。事故時の調査でキャッシュなしでも当面は OK と判断。
10
  ただし負荷増加時にレスポンス劣化が予想されるため、500ms 超で
11
  再評価する。
12
related_files:
13
  - src/api/handler.py
14
related_decisions:
15
  - "[[performance_strategy]]"

これを Claude Code の memory 機能（または同等の永続記憶）に登録します。

トリガー監視の自動化

checkpoint の真価は、トリガー条件を自動監視できる点です。

1
checkpoints = load_all_checkpoints()
2
for cp in checkpoints:
3
    if cp.type != 'deferred_decision':
4
        continue
5
    current_value = fetch_metric(cp.trigger.source)
6
    if current_value > cp.trigger.threshold:
7
        notify(f"Trigger fired: {cp.decision}")

これを週次で走らせれば、「3ヶ月前に置いた deferred 判断のトリガーが先週発火した」を自動で気づけるようになります。

AI agent との連携：セッション開始時の checkpoint 確認

このパターンの最大の効用は、次のセッションで agent が自動的に確認してくれることです。

1
## CLAUDE.md
2

3
セッション開始時に、以下を確認する:
4

5
1. 関連する deferred_decision checkpoint が存在するか
6
2. そのトリガー条件が現在満たされているか
7
3. 満たされている場合、ユーザーに「3ヶ月前に保留した
8
   判断のトリガーが発火しています」と通知
9

10
該当ファイルやドメインを触る作業の場合は、この確認を
11
最初に行うこと。

これにより、次に同じファイルを触る時に agent が「過去の保留判断」を思い出して提示してくれます。

適用例：3パターンの deferred を checkpoint 化

Pattern A: パフォーマンス閾値による判断

1
type: deferred_decision
2
trigger:
3
  what: query_p99_latency
4
  threshold: 1000ms
5
  source: grafana/dashboards/db-perf
6
decision: インデックス追加 or テーブル分割

Pattern B: データ量による判断

1
type: deferred_decision
2
trigger:
3
  what: table_size
4
  threshold: 10_000_000 rows
5
  source: SELECT COUNT(*) FROM logs
6
decision: アーカイブテーブルへの分離

Pattern C: 時間経過による判断

1
type: deferred_decision
2
trigger:
3
  what: months_since_created
4
  threshold: 6
5
  source: created_at (2026-05-17)
6
decision: ライブラリ X の deprecation 対応着手

どのケースも、「いつ・何を見たら判断するか」が機械検証可能な形になっています。

TODO/Issue との使い分け

すべての deferred を checkpoint にする必要はありません。使い分けは以下のとおりです。

ケース	推奨
「次のコミットで直す」	TODOコメント
「今 sprint 中に対応」	Issue
「条件が変わったら判断」	checkpoint
「タイミングが来たら検討」	checkpoint
「とりあえずメモ」	discussion / note

ポイントは、**「いつ判断するかが今は分からないが、トリガーは定義できる」**ものが checkpoint の対象です。

なぜ AI 駆動開発で重要になるのか

人間だけのチームでは、「あの時保留した判断」は誰かの記憶や、四半期計画の会議などで思い出されてきました。

しかし AI agent との協働では、

agent はセッション間で記憶を持たない
人間はセッションごとに違うコンテキストで agent と対話する
「過去にこう判断した」が agent に伝わらない

ので、deferred 判断が指数関数的に消えていきます。これを補うのが checkpoint です。

agent の「外部記憶」を、人間の判断履歴の保管庫として使う。これが AI 駆動開発における意思決定マネジメントの肝だと思います。

副次効果：判断の質が上がる

このルールを運用していると、「保留する」こと自体の質が上がります。

なぜなら、checkpoint に書くためには 「何を見たら判断するか」を最初に決める必要があるからです。これが書けない deferred は、本当は「保留」ではなく「曖昧」だったと気づきます。

1
書ける deferred: 「P99 latency が 500ms 超えたらキャッシュ検討」
2
書けない deferred: 「将来的に何かあったら見直す」

書けない deferred は、その場で再考します。本当に保留できる類のものなのか、それとも今決めるべきなのか。checkpoint 化のプロセスが、判断のフィルタになるのです。

まとめ：deferred を「腐らない記憶」に変える

「後でやる」という判断は、TODO/Issue/ドキュメントに書いた瞬間から腐り始めます。理由は、判断トリガーと判断する場所が分離しているからです。

対処は、

deferred を checkpoint 化（トリガー条件を構造化して記録）
トリガー監視を自動化（週次で発火を検出）
agent にセッション開始時の確認を委譲（過去の保留判断を思い出す責務を agent に渡す）

の3つです。これにより、3ヶ月前の保留判断が自動的に蘇るようになります。

AI agent との協働で最も難しいのは、**「セッションをまたぐ意思決定の連続性」**を担保することです。checkpoint は、その連続性を機械検証可能な形で保つための、最も実用的な道具だと考えています。

「後でやる」と言った瞬間に checkpoint を書く習慣。これだけで、リポジトリの中の「忘れられた判断」が劇的に減ります。