毎回Current Contextを更新しなかった理由

1. リード

AI と一緒に開発していると、毎回「今の最新状態」を書き換えたくなる。会話は速いし、理解もすぐ深まる。だから、少し前の確認結果より、今この場の説明の方が新しくて正しそうに見えることがある。私も最初は、その感覚にかなり引っ張られていた。

けれど Qiita 執筆プロジェクトの PROJECT_RULES.md は、そういう更新を認めていない。Version 更新、Release Candidate 公開、正式リリース、Operational Validation 完了、大きな設計変更、新しい Season の開始、あるいは明示的な依頼があったときだけキャッチアップする。それ以外では、開発状況を推測して現在地を更新しないと書かれている。

実際に CURRENT_CONTEXT.md の確認日は 2026-07-26 で、そこでは v1.0.0 の正式リリース、同日の v1.1.0 正式リリース、HEAD commit、Release 対象 commit、Season 2 の着手ゲート確認までが、確認済み事実として整理されている。今回のテーマは、毎回 Current Context を更新しなかったことが、情報の遅さではなく「最新っぽさの創作」を防ぐ運用だったという話だ。

2. 背景

PROJECT_RULES.md のキャッチアップ手順はかなり具体的だ。読む順番まで固定されていて、docs/chatgpt/10_NEXT_SESSION_PROMPT.md、docs/chatgpt/01_CURRENT_STATUS.md、CURRENT_STATUS.md、docs/chatgpt/11_LESSONS_LEARNED.md、CHANGELOG.md、最新の GitHub Release、必要な場合だけ最新コミット、という流れになっている。

さらに、確認後に CURRENT_CONTEXT.md へ何を更新するかも決まっている。確認日、確認した最新コミット、現在の Version、レビュー状況、新しく完成した機能、既知の制限、次に公開できる記事テーマ、Season と記事内容の整合性。この順を見ると、Current Context は思いついた時に足すメモではなく、確認済みの現在地だけを再構成するための管理表だと分かる。

2026-07-26 の CURRENT_CONTEXT.md もその形になっている。対象リポジトリ、HEAD commit c8272f7e279fd55be3c4d15b334c655b467f59f8、最新 Release v1.1.0、Season 2 着手ゲートとしての v1.0.0 正式リリース確認、そして v1.1.0 で完了したことと、やっていないことが並んでいる。これは「その日に確認した断面」であって、会話の流れに合わせて毎回伸び縮みする説明ではない。

3. 今回のテーマ

今回のテーマは、Current Context を毎回更新しないことで、「会話では新しそうに見えること」と「正本で確認した最新事実」を混同しないようにしていたということだ。

非エンジニアの立場では、更新しないことは少し不安に見える。日付が古いと、そのまま置いておいてよいのかと思うからだ。だがこのプロジェクトでは、古いかどうかより先に、何を根拠に更新したかが重い。確認のトリガーも、読む順番も、更新項目も固定しておくと、「新しそうだから書き換える」が入り込みにくくなる。

4. 実際の出来事

PROJECT_RULES.md は、キャッチアップのタイミングをかなり限定している。Version 更新時、Release Candidate 公開時、正式リリース時、Operational Validation 完了時、大きな設計変更時、新しい Season の開始時、あるいは「キャッチアップしてください」「最新の GitHub 状態を反映してください」と明示的に依頼されたときだけだ。逆に言うと、日々の会話で理解が進んだことや、「そろそろこうなっていそうだ」という感覚は、更新トリガーとして採用していない。

この線は 2026-07-26 の CURRENT_CONTEXT.md の中身とよく噛み合っている。その日に確定したのは、v1.0.0 が正式リリース済みであること、同日に Dashboard UI 改善だけをまとめた v1.1.0 が Latest として正式リリース済みであること、main HEAD は status 同期用ドキュメント更新であること、そして Season 2 で使ってよい事実と、まだ書いてはいけない内容だ。

重要なのは、この時点で同じファイルが「未着手」や「やっていないこと」も残していることだ。公開版リポジトリ切り出しの安全な計画、新 Version の機能実装は未着手。v1.1.0 では新 Connector、DB / SQL / スキーマ変更、AI 要約・自動提案、新しい書き込み Action、Human Approval の省略はやっていない。もし Current Context を毎回の会話で更新していたら、この未着手や非実施項目が、会話の勢いで少しずつ滑らかにつながってしまったかもしれない。

読む順番が固定されていることも大きい。たとえば Release だけを先に見れば、正式版が出た事実だけは分かる。だが 10_NEXT_SESSION_PROMPT.md や 01_CURRENT_STATUS.md、CURRENT_STATUS.md、11_LESSONS_LEARNED.md、CHANGELOG.md を飛ばすと、その正式化が何の条件で成立したのか、何をまだやっていないのかが抜けやすい。Current Context の更新をイベント時に限り、そのたびに同じ順番で読むから、あとから見返したときも「なぜその表現になったか」を追いやすい。

この運用は、Qiita 側の連載にも効いている。2026-08-14 の時点でも CURRENT_CONTEXT.md の確認日は 2026-07-26 のままだが、だから弱いわけではない。むしろ v1.0.0 の正式 Go、v1.1.0 の範囲、既知の制限、まだ書いてはいけない内容が、その確認時点の根拠付きで固定されている。毎回新しい顔をした説明へ置き換えないから、記事側も同じ土台を使い続けられる。

私は、ここがかなり実務的だと思っている。AI と会話していると、分かったことがすぐ文章になる。文章になると、まだ確認していないことまで「もう整理できている話」に見えやすい。だがキャッチアップのタイミングが固定されていれば、その誘惑を一度止められる。更新したいときは、まず正本を読み直し、決められた項目だけを更新する。この順番があるだけで、Current Context は会話の要約ではなく、確認済みの断面として保ちやすくなる。

5. 考えたこと

私は以前、Current Context を毎回更新しないのは、少し不親切だと思っていた。最新の会話があるのに、なぜ確認日が 2026-07-26 のままなのか、と感じるからだ。だが今は逆で、毎回更新しないからこそ、その日付に意味が残るのだと思っている。これは「最後に触った日」ではなく、「最後に確認手順を通した日」だからだ。

AI と一緒に進めるほど、この差は大きい。会話は理解を深めるには強いが、現在地の唯一の根拠には向かない。会話は速く、自然で、つながりもよい。だからこそ、未来の予定や未確認の期待まで、現在地と同じ温度で語れてしまう。PROJECT_RULES.md が更新タイミングと確認順を固定しているのは、その滑らかさにブレーキをかけるためだと思う。

もう一つ大きいのは、記事を書く側の錯覚も防げることだ。連載を続けていると、前回までの流れから「次はたぶんこうだろう」と自然につなぎたくなる。だが Current Context がイベント時の確認結果として止まっていれば、そのつなぎ方が本当に正本と一致しているかを考え直せる。更新しないことは放置ではなく、確認なしに未来へ寄らないための停止線だった。

私はこの運用を、遅さではなく勇気だと思っている。毎回「最新です」と言う方が気持ちはいい。だが強いのは、毎回そう言わずに済む境界を持つことだった。確認した日にだけ更新する。その代わり、一度更新した断面には根拠が残る。このやり方の方が、あとで読み返したときにずっと信用しやすい。

6. 学び

• Current Context は毎回の会話メモではなく、確認手順を通した断面として扱う方が強い
• 更新タイミングをイベントに限定すると、未確認の期待を現在地へ混ぜにくい
• 読む順番を固定すると、Release だけを見た早合点や、会話だけを見た思い込みを減らせる
• 「確認日が古い」ことより、「何を根拠に更新したか」が重要になる
• AI と一緒の執筆では、更新しないこと自体が創作防止の仕組みになる

7. 次回メモ

この続きで書くなら、Season の切り替え前に必ずキャッチアップする理由につながる。Current Context をいつ更新するかが決まっているからこそ、Season の境界も会話ではなく確認結果で切れるからだ。