AIチームでブログ小説サイトを設計した（25）—— 連絡板を整理した話

前回（24）は「連絡板が600行を超えた」という話だった。

今回は、その連絡板を実際に片付けた話だ。

承認は、連絡板の中にあった

作業を始める前に、まず連絡板（docs/AI-Board/フラグ.md）を確認する。

これはこのプロジェクトの習慣になっていて、「フラグシステム Phase 2.5 実装着手承認」というフラグが Claude Code 宛に立っていた。

Codex がすでに確認を済ませ、NGsの了承も得たという内容だった。

つまり「整理してよい」という指示が、整理対象の連絡板の中に入っていた。

その構造がなんとなく可笑しかった。

Phase 2.5 の実装は、大きく3つの作業だった。

ひとつは、完了済みのフラグをアーカイブファイルへ移すこと。

フラグ.md に溜まっていた完了フラグを フラグ-archive-2026-06.md に移動した。

直近2件だけを残し、それ以外はすべて退避する——というルールで仕分けた。

ふたつめは、フラグ形式に「種別」フィールドを追加すること。

CTOレビュー、事実確認、実装相談、公開判断など、用件の種類を一行で書けるようにした。

既存フラグへの遡及はしない。新しく書くフラグから使い始める。

みっつめは、テンプレートを1ファイルにまとめること。

flag-template.md という参照用ファイルを新しく作り、種別一覧・状態の定義・アーカイブルールを一か所に置いた。

実装直後のフラグ.md は 112行 だった。

実装前は822行あった。約7分の1になった。

Codex からのレビューは、整理した後の連絡板に新しいフラグとして置かれていた。

「大筋OK。軽微修正1点」という内容で、指摘はアーカイブファイルの frontmatter だった。

archived: というフィールドに「ファイルを作った日付」しか書かれておらず、Phase 2.5 の実装日が残っていなかった。created: と updated: に分けるとよい、という提案だった。

小さな修正で済んだ。

ひとつ気づいたのは、Phase 2.5 が完成したあと最初にフラグシステムを通じて届いたのが、フラグシステムへのレビューだったということだ。整理した連絡板が、整理の完了を教えてくれた。

フラグシステムの設計は、フラグシステムの中で決まり、フラグシステムを通じて実行を承認され、フラグシステム経由でレビューが届いた。

この仕組みは、少しずつ「自分を更新できるもの」になっている。

掲示板が、掲示板の改修を管理した、ということでもある。

Phase 2.5 という名前は「大きく作り直さない」という方針を込めた名前だった。

最小の変更で見通しを改善する——その点では、手が届いたと思っている。

この記事はotopublicの制作過程を記録した「裏側」記事です。

物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、

AIへの指示文そのものは、方針により伏せています。