複数プロジェクトを掛け持ちしていると、何を決めて何につまずいたかの記録は属人化しがちです。私たちはAIエージェントに秘書役をやらせ、決定・進捗を自動で記録に残す3層の仕組みを設計しました。ワークスペース全28プロジェクトに配置した今、実際に機能しているのは3層のうち1層だけですが、それでも別セッションから後を追える満足感は大きいです。この記事では、2週間かけたアプリ版秘書を結局作り直した失敗談も含め、今動いている実態をそのまま書きます。
背景・課題
複数のプロジェクトを掛け持ちしていると、何を決めたか・何につまずいたかの記録は個人の記憶に依存しがちです。新しいセッションを始めるたびに、前回までの経緯を思い出すところから始まります。
きっかけは、AIとの会話でコンテキストが埋まるほど精度が落ちるという話をどこかで見たことでした。であれば、コンテキストを圧迫する前に記録として外に残しておけばいい。そう考え、決定・進捗を自動で記録に残す「秘書」をAIエージェントにやらせることにしました。
やったこと
最初に作ったのは、本格的なWebアプリ版の秘書でした。Express+Viteでビューア・サーバー・AIチャット機能を備えた仕組みを、2026年5月28日から6月10日まで約2週間かけて構築しました。Codexレビューを4ラウンド重ね、「APPROVE」まで得ています。
ところが動かしてみると、パーサーがHTMLコメント内の項目を実タスクとして誤カウントするバグが見つかりました。作り込むほど壊れる場所も増える構造で、結局この仕組みごと作り直すことになります。
作り直した先が、今の軽量な3層構成です。Tier0はメインのAIエージェントがその場で直書きする自動記録、Tier1は/wrapコマンドで手動起動するプロジェクト秘書の同期整理、Tier2は夜間バッチによる横断集約です。ワークスペース配下の全28プロジェクトに、この体制を配置しました。
結果
全28プロジェクトに秘書ログを配置できました。ただし実際に動いているのはTier0だけで、Tier1の/wrapもTier2の夜間バッチも、手動でも自動でも使われていません。Tier2は2026年7月3日、トークン消費だけが残るという理由で休止しています。
それでも、後から追える・別セッションでも状況を把握できるという満足感はかなり大きいものでした。実感を裏付ける具体例が2つあります。
1つは、この記事自体です。今回の執筆では複数のプロジェクトのログを横断的に読み返し、数週間前のバグ修正の詳細や失敗の経緯を、記憶ではなく記録から正確に引用しています。この記録が無ければ、この記事は書けませんでした。
もう1つは、ルールが横断的に広がっていく効果です。あるプロジェクトで見つかった教訓が、大元の秘書ログを通じて全プロジェクトへ標準化されて広がっている例が複数見つかりました。
つまずきと対処
うまく回らなかったのは、タスク管理としての層でした。state.mdとtasks.mdは、決定を記録するTier0とは別に、進行中のタスクや状態を追うために用意したものです。
2026年7月5日の棚卸しで、30日以上更新されていないstate.mdが全28プロジェクト中19件見つかりました。フラグを立てて対処したはずが、2026年7月15日時点でも19件すべてが未解消のまま10日間動いていません。tasks.mdも、28プロジェクト中9プロジェクトがほぼ空の状態です。
さらに、Tier1の/wrapコマンドは用意されているものの、結果を確認すると誰も手動で呼び出していませんでした。仕組みとして存在することと、実際に使われることは別だと痛感した点です。
こうした結果を踏まえ、今はTier1・Tier2を無理に使わせようとはしていません。Tier0の自動記録だけを実態として運用し、それ以外は動いていないものとして扱っています。
まとめ
3層で設計した秘書体制のうち、実際に機能しているのは1層だけ。それが今の私たちの現在地です。恰好の良い話ではありませんが、誇張せずそのまま書きました。
理想の完成形を目指して作り込むより、今実際に回っている最小の仕組みを保つほうが、結局は長続きします。Webアプリ版を2週間かけて作り直した経験も、state.mdが動かなかった経験も、次に別の仕組みを設計するときの判断材料として記録に残っています。
同じように複数の案件やプロジェクトを掛け持ちし、決定や失敗の記録が属人化している状況があれば、一度ご相談ください。お問い合わせからお気軽にご連絡ください。
