AIチームでブログ小説サイトを設計した（24）—— 連絡板が育ちすぎた話

AIチームの連絡手段として使ってきた「フラグ.md」が、気づけば600行を超えていた。

これはそのファイルをどう次の段階に進めるか、を考えた話だ。

連絡板という発想

このサイトの制作には、Claude Code（実装担当）と Codex（CTO）という二つのAIが関わっている。

人間（NGs）を中心に、この二者が判断を持ち寄りながら作業を進めている。

問題は、AIには「前の会話を自動で覚えておく」機能がない、ということだ。

セッションをまたいで「あのとき何を決めたか」「あちらは何を待っているか」を渡す仕組みが必要だった。

そこで作ったのが docs/AI-Board/フラグ.md。

「Codex宛」「Claude Code宛」の二つのセクションに、用件をカードのように並べるだけのシンプルな形だ。

カードには「未読」「対応中」「確認済み」「完了」の状態を書き、相手が読んだら更新する。

フラグシステムの稼働から数週間で、ファイルは600行を超えた。

CTOレビューの依頼、事実確認の結果、設計相談への返答、実装指示への確認——

あらゆる種別の連絡が、一つのファイルの中に時系列で積み上がっていった。

全部「完了」になっているとしても、読むたびにスクロールしなければ現在の状態が見えない。

NGsが「フラグシステムは次の段階に移行できそう？」と聞いたのは、このタイミングだった。

確認してみると、Codex がすでに対策を考えていた。

Claude Code宛セクションに、Codexから「フラグシステム次段階移行プラン作成依頼」というフラグが置かれていた。

連絡板に「連絡板の次を考えてほしい」という依頼が入っていた、という少し可笑しい状況だ。

Codex の提案をまとめると、こうなる。

– フラグ.md には「未読」「対応中」と、直近の完了だけを残す

– 古い完了フラグは月別アーカイブファイルへ移す

– フラグに「種別」フィールドを追加する（CTOレビュー、事実確認、実装相談、公開判断など）

– Gemini Gem への執筆依頼はフラグ外に置く

最後の点は重要な整理だった。

このプロジェクトには Claude Code と Codex に加えて、story-02 専用の Gemini Gem が加わっている。

ただし Gemini Gem は「セッションの外でフラグを継続的に読む」という使い方に向いていない。

執筆の実行は Gem に直接指示するが、その結果のレビューや正典への反映は引き続き Claude Code と Codex が担う——という役割分担を明確にすることで、フラグシステムの対象範囲を絞り込めた。

Claude Code 側が提案したのは、大きく作り直さない「Phase 2.5」という呼び方だ。

最小の変更で見通しを改善する。

完了フラグを月別アーカイブに退避し、フラグ.md をアクティブな用件だけに絞る。

テンプレートは種別ごとに分けず、1ファイルにまとめて種別フィールドを追加する形にする。

現時点ではまだ実装前で、NGsの承認を待っている段階だ。

フラグシステムは「掲示板」として機能してきた。

用件を貼る、読んだら返す、終わったら完了にする——それだけで、セッションをまたいだ連絡はほぼ回っていた。

問題になったのはアーカイブではなく、種別の混在だ。

CTOレビューの依頼と、実装の確認と、設計の相談が、同じカード形式で並んでいる。

フラグが増えてくると、「何が残っていて、何が終わっているか」を把握するコストが上がる。

整理の方向は、たぶんシンプルなままでいい。

ファイルを軽くして、種別で探しやすくする。それだけで、次の段階には十分だと思っている。

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

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

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