Seasonが変わっても「まだ書いてはいけない内容」を残した理由

1. リード

Season が切り替わると、書けることが一気に増えたように感じる。正式リリースが確認され、新しい Version も出て、連載の節目も変わる。そうなると、次の計画や次の改善も、もう語り始めてよいように見えてくる。

けれど、この Qiita 執筆プロジェクトではそうしなかった。CURRENT_CONTEXT.md には Season 2 で使ってよい事実だけでなく、まだ書いてはいけない内容も明記されている。公開版リポジトリ切り出しが進行中であるかのような表現、次 Version の機能が着手済みであるかのような表現、v1.1.0 以後の未来計画を既定路線として書くこと、未実装機能や未確定 Version を事実として書くこと。それらを、Season 2 に入ったあとも消していない。

今回は、Season が変わったあとでも「書いてよいこと」だけでなく「まだ書いてはいけないこと」を残し続けたのはなぜかを整理しておきたい。

2. 背景

PROJECT_RULES.md では、Qiita プロジェクトの役割をかなり強く限定している。ここは OS 本体の設計や実装を変える場所ではなく、記事制作、図解、タイトル改善、公開運用を進めるための独立プロジェクトだ。だから記事側の流れに合わせて、OS 本体の未来を先回りで語ってはいけない。

禁止事項もはっきりしている。未実装機能を書くこと、将来予定を実現済みの事実として書くこと、Version を前倒しすること、Release 前の内容を完成形として扱うこと、推測で穴を埋めること、GitHub の正本と異なる情報を書くこと。さらに不明な事実は本文へ入れず、執筆メモで止めると決められている。

そのうえで CURRENT_CONTEXT.md の確認日は 2026-07-26 になっている。この日には v1.0.0 が正式リリース済みであること、同日に Dashboard UI 改善だけをまとめた v1.1.0 も正式リリース済みであること、そして Season 2 で記事化できるトピックと、まだ書いてはいけない内容が整理された。つまり Season 2 は、書けることが自由に増えた段階ではなく、確認済みの範囲と禁止範囲が同時に固定された段階として始まっている。

3. 今回のテーマ

今回のテーマは、Season を切り替えたあとも禁止リストを残したことで、「新しい段階に入った」という空気がそのまま未来の創作へ流れ込むのを防いでいたということだ。

Season の切り替えは読者にも書き手にも強い効果がある。区切りが変わると、「ここから新章だ」「次の話題に進める」という感覚が出やすい。だが、その感覚と、正本で確認した事実の範囲は同じではない。だから Season 2 に入ったあとも、何をまだ書いてはいけないかを残しておく必要があったのだと思う。

4. 実際の出来事

CURRENT_CONTEXT.md の Season 2 現在地はかなり明確だ。v1.0.0 は正式リリース済みで、v1.1.0 も正式リリース済み。v1.1.0 で完了したこととして、Dashboard UI 改善、9画面の最終 UI 受入、275 tests passed が挙がっている。一方で、やっていないこととして、新 Connector、DB / SQL / スキーマ変更、AI 要約・自動提案、新しい書き込み Action、Human Approval の省略が並んでいる。

この「やったこと」と「やっていないこと」の両方があるから、Season 2 で何を語れるかが定まる。たとえば、v1.0.0 の正式 Go が新機能追加ではなく運用条件の明確化と再検証で成立したこと、v1.1.0 が Dashboard UI 改善だけに範囲を絞ったこと、ChatGPT / Cursor / GitHub / Human Approval の役割分担が固定されたことは書いてよい。だが同じファイルには、公開版リポジトリ切り出しが進行中であるかのような表現や、次 Version の新機能が着手済みであるかのような表現は書いてはいけないと残されている。

ここで大きいのは、禁止対象が一つの計画だけではないことだと思う。CURRENT_CONTEXT.md の「まだ書いてはいけない内容」は、未来計画の既定路線化、未実装機能の事実化、未確定 Version の前倒しまで含んでいる。つまり「この計画はまだ未着手です」と書くだけでなく、Season 2 に入ったからといって未来全体をなめらかに接続してはいけないと明示している。

これは 2026-07-26 という日付とも相性がいい。同じ日に v1.0.0 と v1.1.0 が正式リリースされると、どうしても勢いが出る。正式版が出て、そのまま改善もまとまったのだから、次の計画もすぐ近くにあるように感じる。だが Current Context は、その勢いに乗って次 Version や公開版リポジトリ切り出しを前進済みとして扱っていない。むしろ同じ日に区切りが密集したからこそ、書いてはいけない内容を明示して、境界を太くしている。

PROJECT_RULES.md でも同じ方向が繰り返されている。情報源の優先順位は GitHub のコードとドキュメント、docs/chatgpt/、CURRENT_STATUS.md、Release、Issue / Milestone の順で、会話の勢いや期待感はそこに入っていない。Season 切り替え前には必ずキャッチアップし、確認後に CURRENT_CONTEXT.md を更新する。つまり新しい Season は、気分で始まるものではなく、確認済みの境界で始まる。だから始まったあとも、その境界の外側を禁止リストとして持ち続ける必要があった。

私はここがかなり実務的だと思っている。連載を書いていると、「次はこれを書きたい」がすぐ生まれる。しかも Season 2 のように正式版以後の話へ入ると、読者も書き手も「これから先」の話を期待しやすい。だがその期待に合わせて禁止リストを消してしまうと、まだ確認していない未来まで現在地の延長として語りやすくなる。Current Context はその滑り方を止めるために、使えるトピックの横へ禁止トピックも並べているのだと思う。

もう一つ大きいのは、禁止リストがあることで、逆に完了済みの範囲も強く見えることだ。v1.0.0 は正式 Go、v1.1.0 は UI 改善まで完了、と言い切れるのは、その外側を混ぜていないからだ。もし Season 2 に入った瞬間に未来計画まで「次に続く流れ」として書き始めていたら、どこまでが確定済みの成果で、どこからが期待なのかが曖昧になる。書いてはいけない内容を残すのは、未来を止めるためだけでなく、今すでに確定している事実の輪郭を守るためでもある。

5. 考えたこと

非エンジニアの立場では、新しい Season に入ったのに禁止リストが残っていると、少し窮屈に見える。話が前に進みにくいようにも感じる。だが今は逆で、その窮屈さがあるからこそ、Season の区切りに意味が残るのだと思っている。

Season を切ること自体は簡単だ。タイトルを変えればよいし、語り口も変えられる。難しいのは、Season が変わっても正本の外へはみ出さないことだ。Current Context に「書いてよいこと」と「まだ書いてはいけないこと」が並んでいるのは、その難しさを分かったうえでの設計に見える。

ここでは、未来を考えないことが求められているのではない。未来を事実として書かないことが求められている。公開版リポジトリ切り出しの必要性を理解していても、それを進行中と書いてはいけない。次 Version の構想が頭にあっても、着手済みのように書いてはいけない。Season 2 へ入ったからといって、その線が自動で緩むわけではない。この考え方があると、連載の勢いと事実の境界を分けやすい。

私は、禁止リストは消極的なものではなく、執筆の地面を守るための能動的なものだと思っている。AI と一緒に文章を整えるほど、未来の話はきれいにつながる。だがきれいにつながることと、確認済みであることは違う。Season が変わったあとも禁止リストを残すのは、その違いを毎回見える場所に置くためだった。

6. 学び

• Season の切り替えは、書けることを無制限に増やす合図ではない
• CURRENT_CONTEXT.md に禁止リストが残っていると、未来計画や未実装機能を現在地へ混ぜにくい
• 「やっていないこと」と「まだ書いてはいけないこと」を両方残すと、完了済みの Version 境界が強くなる
• 同じ日に v1.0.0 と v1.1.0 が出たような勢いの強い局面ほど、禁止リストが効く
• 未来を考えることと、未来を事実として書くことは別に管理した方が連載の整合を守りやすい

7. 次回メモ

この続きで書くなら、Season 2 で使ってよいトピックと禁止トピックを同じ Current Context に置いた意味へつながる。前に進むための候補と、踏み越えてはいけない線を同じ場所で管理していたからだ。