複数のAIモデルを行き来しながら長期プロジェクトを進めるために作った協業構造
(github.com/lim8603)AI協業では、記憶はチャットではなくリポジトリにあるべきです
ここ数か月、GPT-5系モデル、Claude、Copilot、Gemini など複数のAIモデルを切り替えながら開発作業をすることが多くなりました。以前は1つのツールだけでも十分でしたが、今では作業の種類に応じてより適したモデルを選ぶのが自然な流れになっています。
たとえば構造設計は GPT-5.4 のような大型モデルが安定しており、コード作成は Claude Sonnet / Opus 系のほうが正確な場合があり、フロントエンドのデザインやアイデア探索では別のモデルを使うほうが効率的なこともあります。しかもモデルの更新速度が非常に速いため、特定のツールに固定するよりも、状況に応じて選択を変え続けることになります。
問題はここから始まります。
モデルを変えるたびに、セッションが変わるたびに、AIはプロジェクトをまったく覚えていません。結局、毎回同じ説明を繰り返すことになります。このプロジェクトが何なのか、今どこまで進んでいるのか、どんな決定をすでに行ったのか、どの構造を維持すべきか、何をしてはいけないのかといった基本的な文脈を、何度も伝え直さなければなりません。
最初は単に面倒な程度でしたが、プロジェクトの規模が大きくなるほどこのコストは目立って増えていきました。特に複数のモデルを行き来しながら作業すると、実際の開発よりもコンテキストを説明し直すことに多くの時間がかかっているように感じました。そこで自然と、こんな問いを持つようになりました。
"AI協業において、記憶はチャットにあるべきなのか。それともプロジェクト自体が記憶を持つべきなのか？"
Prompt Engineeringでは解決できない問題
AIをうまく使う方法として Prompt Engineering はよく語られます。しかし長期プロジェクトを進めてみると、プロンプト以上に重要な問題があります。それが コンテキストが維持されない問題 です。
プロンプトは一度のリクエストをうまく作る方法であり、プロジェクトは複数回の作業が連なっていく過程です。プロジェクトを安定して進めるには、少なくとも次の情報が継続的に維持される必要があります。
- 現在の要件
- これまでの決定記録
- 作業計画
- 完了した作業
- 変更履歴
- 今後やるべきこと
これらの情報が維持されなければ、モデルがどれほど優秀でも同じミスを繰り返すことになります。そこで私は、プロンプトをもっと上手に作る方向ではなく、コンテキストそのものを管理する方法を作り始めました。こうしたアプローチは一般に Context Engineering と呼ばれますが、私も同じような問題を経験しながら、この概念をプロジェクト単位の協業に適用し始めました。
チャットではなく、リポジトリが記憶を持つべきだ
最初に変えたのは、コンテキストを保存する場所でした。従来はすべての文脈がチャットの中にありましたが、チャットはセッションが終われば消えてしまいます。そこで プロジェクトのルート内にコンテキストを保存する構造 を作りました。
.cowork/ というフォルダを作り、ここにプロジェクトの状態を記録するようにしました。たとえば requirements、architecture decision record、task の一覧、テスト記録、リリース記録、セッションログなどです。
セッションを開始するときは必ず現在の状態を読み、計画を立て、承認し、実行し、結果を記録する流れに従います。会話は揮発しますが、文書は残ります。だからモデルが変わっても、プロジェクトは継続できます。
Plan → Approve → Execute ルール
AI協業で最も頻繁に経験した問題の1つは、モデルがいきなりコードを修正してしまう状況でした。以前の決定を無視したり、構造を壊したり、すでに合意した方向とは異なる変更を加えたりすることが繰り返されました。
そこで1つの作業ルールを作りました。常に Plan → Approve → Execute の順序を守ることです。まず計画を作り、人が確認し、その次に実行します。このルール1つだけでも、長期プロジェクトで発生するエラーは大幅に減りました。
Artifact is Memory
このフレームワークで最も重要だと考えている原則は、「Artifact is Memory」 という一文で表せます。記憶はチャットにあるのではなく、プロジェクトの成果物にあるべきです。
そうしておけば、モデルが変わっても、セッションが変わっても、ツールが変わっても、IDE が変わっても、プロジェクトの状態を維持できます。特に複数モデルを同時に使う環境では、この原則は思っている以上に重要に働きます。
ここでいう成果物とは、最初から文書として書かれたものだけを意味しません。AIとのやり取りの中でも、要件の精緻化、設計判断、作業計画、レビュー結果のように、プロジェクトに実際に残すべき情報が継続的に生まれます。問題は、こうした内容がチャットの中にとどまる限り、一時的な文脈として消費されやすいことです。
そのため私は、AIとの会話のうち意味のある内容を自動的に分類して記録し、それを再びプロジェクト成果物として使う方法を重視しています。単に会話ログを積み上げるのではなく、会話から出た核心的な内容を決定記録、要件文書、作業計画、セッションログのような形に整理し、再利用可能な状態で残すのです。
こうすると会話は一時的なインターフェースにとどまらず、プロジェクトを継続的に前へ進める作業材料へと変わります。結局、記憶すべきなのは会話そのものではなく、会話を通じて抽出された構造化された成果物だと考えています。
複数のモデルを行き来しながら作業するときに生じる問題
最近は1つのモデルだけを使うことはほとんどありません。モデルごとに得意分野が違うため、作業段階に応じて別のモデルを使うことになり、設計、コード修正、レビュー、文脈分析といった作業を複数のセッションと複数のモデルの間で繰り返すことになります。
このとき、コンテキストがチャットの中にしかなければ、モデルを切り替えるたびにプロジェクトを説明し直さなければなりません。そこで、コンテキストをチャットではなくリポジトリ内に置く構造を作りました。
作ったもの: cowork-context-framework
この過程を整理して、1つのフレームワークにしました。プロジェクト内にコンテキストを保存し、セッションを復元し、決定を記録し、作業を追跡し、モデルが変わっても続けて作業できるようにする構造です。
以前はテンプレートの形で使いながら実プロジェクトに適用してある程度の検証を行い、その経験をもとに構造を整理して framework の形へ昇格させました。AIと長期プロジェクトを進める際に必要な最小限の協業構造は、このような形だと考えています。
似たような試みをしたことがある人がいるか気になります
- 複数のAIモデルを併用した経験がある方
- セッションが切れて同じ説明を繰り返したことがある方
- agent / workflow / harness のような構造を作ったことがある方
- プロジェクトコンテキストを別途管理してみた方
似たような経験があれば、意見を聞いてみたいです。
まだコメントはありません。