問題は、AIが文章を書けないことではない
AIは、その場で文章やコードを作るのは得意です。しかし実際の仕事は、一回の会話では終わりません。 数日後に再開し、別の担当や別のAIセッションへ移り、前回の判断を確認しながら続きを進めます。
そのとき必要なのは、会話全文を毎回持ち込むことではなく、何のための作業で、何が正本で、いまどこにいて、次に何をするのかを確認できることです。
Repositoryを、仕事のContextとして使う
Repository Contextでは、Repositoryをコード置き場だけとして扱いません。 コード、原稿、仕様と一緒に、そのRepositoryをAIが理解して再開するための文脈を持たせます。
最低限、次の情報が読めれば再開できます。
- このRepositoryは何のためにあるか
- どの文書・データ・システムが正本か
- 現在どこまで進んでいるか
- すでに何を決めたか
- 何をしてはいけないか
- 何が未決か
- 次に何をするか
すべての情報を一つのファイルへ詰め込むことが目的ではありません。原本は適切な場所に置き、AIが必要な正本へ戻るための入口と現在地を軽く保ちます。
汎用最小版
Repository Contextは、大きなシステムとして始める必要はありません。まずは4つのMarkdownファイルをプロジェクトのルートに置くだけで始められます。
project/
├── AGENTS.md
├── REPOSITORY_CONTEXT.md
├── NEXT.md
└── HISTORY.mdAGENTS.md
AIに読ませる作業ルール。最初に読むもの、承認境界、やってはいけないこと、完了条件を書きます。
REPOSITORY_CONTEXT.md
プロジェクトの現在地。目的、正本、進行状況、採用済み判断、未決事項を書きます。
NEXT.md
未処理と次アクション。いまやること、判断待ち、後で戻ること、まだ始めないことを書きます。
HISTORY.md
完了した作業と採用済み判断。後で「なぜそうしたか」へ戻るための履歴を書きます。
どこに置くか
最初のおすすめは、既存プロジェクトのルート、または新しい非公開Gitリポジトリです。GitHubは便利な参照実装ですが、Repository ContextそのものはGitHub専用ではありません。
| 置き場所 | 向いている場合 | 注意点 |
|---|---|---|
| 既存プロジェクトのルート | すでにコードや原稿のプロジェクトがある | 既存READMEやルールとの重複を整理する |
| 非公開GitHubリポジトリ | 複数端末・複数AI・差分管理を使いたい | 公開/非公開の境界を誤らない |
| ローカルGit | 個人作業や実験を軽く始めたい | 別端末や別AIとの共有は自分で設計する |
| Obsidian + Git | 人間が読むノート中心で進めたい | AIが直接作業する場合は運用を工夫する |
Dropbox、Google Drive、Notionは、原本保管や台帳には向いています。ただし最小版の置き場所としては、差分・履歴・AI作業の再現性が弱いため、Git側から参照先として書くのが扱いやすいです。
どのAIでも使えるようにする
Repository Contextは、特定のAI製品に依存しません。ChatGPT、Claude、Gemini、Codex、Cursor、Copilot、ローカルLLMなど、Markdownを読めるAIであれば使えます。
違いが出るのは、次の部分です。
- AIがファイルを直接読めるか、人間が貼る必要があるか
- AIがRepositoryへ直接書き戻せるか、人間が反映するか
- Gitの差分確認やレビューをどこまで使えるか
- 外部サービス更新やデプロイを任せるか、人間承認にするか
どのAIを使う場合でも、最初の指示は同じで構いません。
まず AGENTS.md と REPOSITORY_CONTEXT.md を読んで、
このプロジェクトの目的、現在地、正本、次アクションを確認してください。使い方
- 既存プロジェクト、または新しいフォルダを用意する
- 4つのテンプレートを置く
REPOSITORY_CONTEXT.mdに、目的、正本、現在地、禁止事項を書くNEXT.mdに、次の3件だけを書くHISTORY.mdに、今日始めたことを書く- AIへ
まずAGENTS.mdとREPOSITORY_CONTEXT.mdを読んでと伝える
使用例
たとえば、小さなWebサイトをAIと作る場合は、サイトの目的、公開URL、原稿の正本、デザイン方針、公開してはいけない情報を REPOSITORY_CONTEXT.md に書きます。
website-project/
├── AGENTS.md
├── REPOSITORY_CONTEXT.md
├── NEXT.md
├── HISTORY.md
├── site/
└── docs/研究メモを育てる場合は、原文PDFや外部資料をすべてコピーするのではなく、正本の場所、引用方針、未確認点、次に読む資料を記録します。
テンプレート
初回公開では、zipではなくMarkdownファイルを個別に開ける形にしています。内容を確認して、自分のプロジェクトへコピーしてください。
zip一括ダウンロード、GitHub Template Repository、Obsidian版、英語版は準備中です。まずは中身が見えるMarkdownテンプレートとして公開します。
チャットは作業面、Repositoryは継続面
会話の中では、アイデアを広げ、比較し、文章を書き、実装を進めます。ただし、重要な決定や成果物をチャットだけに残さない。 作業が固まったら、Repositoryの正本へ戻します。
この役割分担にすると、長いチャットを永遠に継ぎ足さなくても、別セッションがRepositoryを読み直して作業を再開できます。
HandoffとACK
長い作業や専門領域を別セッションへ渡すときは、Handoffを作ります。受け取った側は正本を確認し、理解した目的、担当範囲、現在地、次アクションをACKとして返します。
- 前の担当がHandoffを書く
- 新しい担当がHandoffと参照正本を読む
- 復元した内容をACKとしてRepositoryへ返す
- 担当作業を進める
- 意味のある判断・成果物を正本へ反映する
このWebサイトの構築でも、実際に同じ手順を使っています。サイトを作る行為そのものが、Repository Contextの検証Caseになっています。
Context Economy
全文を残せば取りこぼしは減ります。しかし、Contextが大きくなるほど、読む量、検索量、推論コストも増えます。
そこで、何を原文で残し、何を要約し、何を索引だけにし、どのタイミングで正本へ戻るかを設計します。 「情報を多く持つこと」ではなく、必要な情報へ低コストで戻れることを重視します。
何に向いているか
- 一回のチャットでは終わらない開発・研究・制作
- 複数のAIセッションや担当者を跨ぐ仕事
- 原稿、コード、証憑、業務データが複数の保存先に分かれる仕事
- 判断理由や未決事項を失いたくないプロジェクト
- AIを単発生成ツールではなく継続的な協働相手として使いたい組織
入れないもの
Repository Contextは、何でも保存する場所ではありません。次のものは入れないでください。
- secret、password、API token、credential
- 顧客情報、個人情報、私的メッセージ
- メール本文、契約書、請求書などの未加工原本
- 公開してよいか未確認の内部情報
- 推測で補った日付、数値、出典
必要なのは、原本そのものではなく、原本へ戻るための索引、判断、状態、次アクションです。