セッション着手前に状態を実体から再取得する：注入されたスナップショットは最大1日陳腐化する

AI エージェントにタスクを渡すとき、私たちはセッション開始時に「文脈」を一緒に渡します。プロジェクトの状態を記したメモリファイル、今日やるべきタスクの説明文、関連 Issue のラベル——こうした情報がセッションの冒頭に注入され、AI はそれを足場に作業を始めます。

ところが、この**注入された情報は「過去のある時点のスナップショット」**にすぎません。それを書いた時点から実際に着手するまでの間に、状態は動きます。最大で1日ほど陳腐化したスナップショットを「最新」と信じて着手すると、すでに終わっている作業を二重に実装したり、もう存在しない前提を追いかけたりします。

本記事は、複数のセッションで繰り返し遭遇したこの陳腐化事故と、「着手の直前に、状態を実体から能動的に再取得する」という規律で防いだ記録です。

事の発端：注入されたタスク文の前提が、すでに崩れていた

陳腐化が牙を剥いた場面は、いくつもありました。共通するのは「注入された情報を額面通りに受け取ると、間違った作業に突き進む」という構造です。

ケース1：すでに完了済みの作業を「残作業」と書かれていた。 タスク文には「残りの作業は、設定ファイルにガードを1箇所追加するだけ」と書かれていました。ところが実体を確認すると、そのガードは6日前にすでに実装・マージ済みでした。Issue のラベルが planning のまま残っていたのは、マージ先のブランチの都合でラベル自動遷移が発火しなかっただけ。注入されたタスク文を信じて着手していたら、すでにあるものをもう一度実装するところでした。

ケース2：すでに下された判断を「これから判断する」と書かれていた。 別のタスク文は「観察の最終日に、本番昇格を判断する」という指示でした。しかし Issue のラベルを再取得すると、その施策は前日にすでに本番昇格済みで、ラベルも production に変わっていました。観察期間は完了しており、「これから判断する」べきものは何も残っていなかったのです。さらにタスク文に書かれた発火時刻も、古いテンプレートから引き継いだ誤った値でした。

ケース3：参照すべき成果物の日付がずれていた。 「昨日の日付の成果物を確認せよ」というタスク文を受け取ったとき、実際には今日の新しい成果物がすでに生成されていました。タスク文の日付を鵜呑みにすると、確認すべき最新の成果物ではなく、古い方を見てしまいます。

どのケースも、注入されたテキストは「書かれた時点」では正しかったはずです。問題は、書かれてから着手するまでの時間差で状態が動き、テキストだけが過去に取り残されたことにあります。

なぜ問題か：「注入＝最新」という暗黙の仮定

陳腐化が事故になる根っこには、「セッションに注入された情報は最新である」という暗黙の仮定があります。AI も人も、目の前に提示された文脈を、つい「今この瞬間の真実」として扱ってしまいます。

しかし、複数のセッション・複数のプロセスが同じ状態を更新する環境では、この仮定は成り立ちません。

メモリファイルは手書きのスナップショットであり、最後に更新された時点で時間が止まっている
タスク文は、それを書いた人（あるいは前のセッション）の観察時点を反映している
Issue のラベルや状態は、別のセッション・自動化・他人の操作で動き続けている

つまり、注入された情報と実体（SoT＝Source of Truth）の間には、構造的にラグが存在します。観察してからタスクが着手されるまでの間（今回の事例では最大1日）に、別の経路で状態が進む。そのラグの中で「注入＝最新」と仮定すると、二重実装・幻の前提追跡・古い成果物の確認、といった事故に直結します。

注入される情報	スナップショットの時点	着手時点でのリスク
メモリファイル	最後の手書き更新時	完了済みを未完了と誤認
タスク説明文	前セッションの観察時	崩れた前提のまま突進
Issue ラベル	別経路の更新前	状態（done/closed）の見落とし

学び：着手の直前にSoTを能動的に読み直す

このケースを普遍化すると、ひとつの運用規律になります。手動タスクの着手直前に、状態を実体（SoT）から能動的に再取得し、注入された情報と食い違ったら実体を正とする、ということです。

ポイントは「着手の直前」と「能動的」の2点です。

セッション冒頭に一度読んだだけでは足りません。冒頭の情報こそが陳腐化しているスナップショットだからです。だから、実際に手を動かす一歩手前で、もう一度、今度は実体を読みに行きます。具体的には次のようなアクションです。

メモリやタスク文に書かれた状態を、ディスク上の実ファイルで確認する（成果物が実際に存在するか、その日付は何か）
Issue の状態は、ラベルを直接取得して確認する（gh issue view <N> --json state,labels のように、テキストではなく実体を引く）
食い違いがあったら、注入されたテキストではなく、実体（ラベル・実ファイル）を正とする

この一手を挟むだけで、「すでに done のものを実装する」「もう存在しない前提を追う」「古い成果物を見る」といった事故のほとんどが、着手前に検出できます。

1
# 着手の直前に「実体」を引き直す（テキストを鵜呑みにしない）
2
gh issue view <N> --json state,labels   # Issue の状態・ラベルを実体から取得
3
ls -la <成果物ディレクトリ>/             # 成果物が実在するか・日付はいつか
4
# → 注入された情報と食い違ったら、実体を正とする

二重実装の罠を構造的に防ぐ

この規律が一番効くのは、「二重実装の罠」を防ぐ場面です。

タスク文が「これを実装せよ」と言っているとき、それがすでに実装済みである可能性を常に疑う。着手前に「同じことがもう done になっていないか」を実体で確認する。もし done なら、正しいアクションは「実装する」ではなく「すでに実装済みであることを確認し、状態を正しく閉じる（ラベルを done に遷移させる等）」になります。

実際、前述のケース1では、ガードがすでにマージ済みだったため、コードは1行も書かず、代わりに「実装済み・意図検証 PASS」を記録してラベルを正しい状態に進める、という対応を取りました。**「何もコードを書かないのが正解」**という結論は、着手前に実体を確認しなければ絶対に出てきません。注入されたタスク文だけを見ていたら、確実に二重実装していました。

運用Tips：再取得を「形式知」にする

この規律は、属人的な注意力に頼ると必ず抜けます。だから形式知化して、着手手順に組み込むのが要点です。

着手前チェックリストに「SoT 再取得」を入れる。 「実装を始める前に、Issue ラベルと実ファイルを引き直したか？」を必須項目にする。
食い違い時のルールを明文化する。 「注入された情報と実体が食い違ったら、実体（ラベル・実ファイル）を正とする」と決めておく。判断を迷わないために、優先順位を先に固定する。
メモリやタスク文に「鮮度の但し書き」を書いておく。 「このスナップショットは最大1日陳腐化しうる。着手前にラベルを再取得せよ」と、情報そのものに自分の賞味期限を書き添える。読み手（次のセッションの自分や AI）が、それを最新と誤認しないように。
AI への依頼にも明示する。 「タスク文の前提を額面通りに受け取らず、着手前に Issue 状態と実ファイルで裏取りせよ」と頼む。AI は提示された文脈を最新と扱いがちなので、再取得を指示として渡す。

1
## タスク着手前チェック（SoT 再取得）
2

3
1. タスク文・メモリの「状態」を額面通りに信じない
4
2. 着手の直前に実体を引き直す:
5
   - Issue 状態/ラベル（gh issue view --json state,labels）
6
   - 成果物の実在と日付（ls / 実ファイル確認）
7
3. 食い違ったら「実体」を正とする
8
4. 「実装せよ」の前に「すでに実装済みでないか」を疑う
9
   （二重実装の罠の回避）

まとめ：スナップショットは過去、SoTは現在

セッションに注入される情報は便利な足場ですが、それは過去のある時点のスナップショットです。観察から着手までのラグの中で状態は動き、テキストだけが過去に取り残されます。「注入＝最新」という暗黙の仮定が、二重実装や幻の前提追跡を生みます。

今回の学びをまとめます。

注入されたメモリ・タスク文・ラベルは、最大1日ほど陳腐化したスナップショット
「注入＝最新」と仮定すると、完了済みの二重実装や崩れた前提の追跡に突き進む
着手の直前に、状態を実体（実ファイル・Issue ラベル）から能動的に再取得する
注入された情報と食い違ったら、実体を正とする
この再取得を形式知（チェックリスト・依頼文）に落とし、属人性を排す

「実装せよ」と書かれていても、まず「もう実装済みでないか」を実体で疑う。たった一手の再取得ですが、これがあるかどうかで、すでに終わった作業をもう一度やってしまうか否かが決まります。スナップショットは過去、SoT は現在——着手の足場にすべきは、常に現在の方です。