まず結論
1つのチャットで全部やろうとすると、会話が長くなるほど相談相手の精度が落ちます。だから役割ごとに分けました。
- 戦略チャット：全体の地図。締切、応募戦略、優先順位の判断
- アプリA担当チャット：日々の運用と成績の読み解き
- アプリB担当チャット：新プロジェクトの観察と要件
ただし分けると、今度は「情報が届かない」という別の問題が出ます。その解決策として作ったのが、限られた条件のときだけ発行する”連絡便”でした。
なぜ分けるのか ── 会話は長くなるほど”薄まる”
初学者向けに、いちばん大事な仕組みから説明します。AIとの会話には、一度に覚えていられる量の上限があります。長くなると、古いやり取りを自動的に要約して圧縮していきます。
ここで何が起きるか。1つのチャットに「締切の話」「バグの調査」「新プロジェクトの観察」を全部詰め込むと——
- 相談したいことと関係ない情報が、大量に文脈に混ざる
- 圧縮されるとき、今いちばん大事な話が、雑談と同じ重みで要約される
- 結果、答えの精度が落ちる。回答も的外れになりやすい
会議で例えると分かりやすいです。経営会議と、現場の障害対応と、新規事業の調査を、同じ1つの会議室で同時にやっているようなもの。誰も集中できません。だから会議を分ける——それだけの話です。
分けたら、今度は「分断」が起きた
ところが、分ければ万事解決ではありませんでした。チャットAで見つけた発見が、チャットBに届かないのです。部署を分けたら縦割りになった、という、どこの組織でも起きるあれです。
最初は「重要そうなことは全部、他のチャットにも伝える」と考えました。でもこれは失敗の入口です。全部流すと、それはもう分けていないのと同じで、戦略チャットが日々のバグ報告で埋まってしまいます。
そこで決めたのが、「便」を出す条件を3つに絞ることでした。
① 本番の動作に影響する変更を決めたとき
② 応募資料の素材になりうる発見をしたとき
③ スケジュールや判断に響く事実が出たとき
この3つ以外は、担当チャットの中で完結させて外に流しません。理由は「信号対雑音比を守るため」です。連絡が多すぎる相手からの通知は、やがて読まれなくなります。本当に大事なことだけが届く経路にしておく——バックアップの警報を”狼少年”にしなかったのと、まったく同じ発想でした。
実例：この仕組みが、今週ちゃんと働いた
今週、この体制が機能する場面がありました。
あるチャットの文書に、もう一方のプロジェクトに関する数字が、直接書き写されていました。ところが、その値が古いと判明したのです。もう一方のチャット側で実データを測り直したら、違う値が正しかった。
ここで大事なのは、対応が「新しい数字に書き換える」ではなかったことです。取った方法はこうでした。
数字の直書きをやめて、「向こうの記録を参照」の形に変える。
なぜか。数字を直接書き写すと、原本が更新されたときに古い値だけが取り残され、いつか誰か（未来の自分）が読んで、また歩き出すからです。私のブログでおなじみ「真実は1箇所に」の原則を、チャットとプロジェクトをまたいで適用した形になります。
原本はどちらか一方に置き、他方は”参照”だけ持つ。この向きさえ固定しておけば、更新は1箇所で済み、食い違いは原理的に起きません。組織で言えば「マスターデータはどこか」を決めるのと同じ話でした。
引き継ぎ文のコツ ── 中身を写さず、場所を指す
チャットを分けると、新しいチャットを始めるときの引き継ぎも必要になります。ここにもコツがありました。
やりがちなのは、これまでの経緯や数字を引き継ぎ文にびっしり書き写すこと。でもこれは「二重の真実」を自分で作る行為です。時間が経てば引き継ぎ文の数字は古くなり、本物の記録と食い違います。
だから私の引き継ぎ文は、10行ほどの”地図”だけにしました。「要件はこのファイル」「経緯はこのフォルダ」「作業の型はこのファイル」——中身を写さず、読む場所だけを指す。
そして極めつきが、引き継ぎ文の末尾に入れたこの一行です。
この文とファイルが食い違ったら、ファイルのほうが正しい。
引き継ぎ文自体もいつか古くなる——その前提を、引き継ぎ文の中に埋め込んでおく。自分で自分に予防線を張る形で、これは書いていて少し感動しました。
いちばん大事な前提：チャットは”作業ログ”であって、原本ではない
ここまでの全部を支えている考え方が、ひとつあります。
プロジェクトの記憶の本体は、チャットの中にはない。決定事項も、経緯も、数字も、すべてリポジトリ（Gitで管理された文書）に残してあります。チャットはそこに至るまでの相談の記録——つまり作業ログにすぎません。
だからこそ、チャットを分けても、閉じても、失われるものがない。新しいチャットは冒頭の10行から文脈を組み立て直せるし、必要なら過去の会話を検索して経緯も辿れる。「AIに記憶させる」のではなく「AIが読める場所に記録を置く」——この順番が、長期プロジェクトでは決定的でした。
おわりに ── AIとの会話にも、設計がいる
やってみて思うのは、これは技術の話というより組織設計の話だということです。
- 集中を守るために、部署を分ける
- 縦割りを防ぐために、連絡の条件を絞る
- 食い違いを防ぐために、原本の場所を1つに決める
- 引き継ぎでは、中身ではなく在り処を渡す
どれも、人間の組織なら当たり前にやっていることでした。相手がAIになっても、原則は変わらない。むしろAIは文脈に忠実な分、雑音の影響を素直に受けるので、こちらが交通整理をしてあげる価値が大きい、というのが実感です。
個人開発なのに”組織”を作っているようで少しおかしいのですが、週2〜3時間しか使えない身にとっては、この整理がそのまま時間の節約になっています。同じようにAIと長期プロジェクトを進めている方の参考になれば。
学習メモ / AI活用 / プロジェクト管理 / 個人開発
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
