Gitリポジトリは、AIエージェントの「記憶」になるのか
AIエージェントを使っているのに、毎回AIに同じ説明をしていないでしょうか。
前回どこまで進めたのか。
何を決めたのか。
なぜその判断にしたのか。
次に何を確認すべきなのか。
それが会話ログの奥に埋もれている限り、AIは優秀な相棒というより、毎回オンボーディングが必要な新人に近い存在です。本当に残すべきなのは、会話全文ではありません。 次の人や次のAIがすぐ動ける、短い引き継ぎです。
resume（会話の再開機能）で前回の作業を開く。
AGENTS.mdやCLAUDE.mdにプロジェクトの作法を置く。
判断や未完了事項は、 人が見直せる引き継ぎノートに残す。
AIの記憶を一か所に詰め込むのではなく、役割ごとに置き場所を分ける。 それだけで、AIは「毎回新人」から、仕事の文脈を引き継げる存在に近づきます。
そこで面白いのが、Gitリポジトリを「コード置き場」ではなく、AIエージェントの引き継ぎノートとして使う考え方です。AIが作業前に読み、作業後に更新し、人間が差分を見てレビューする。pullして、作業して、commitして、次のAIへ渡す。これは単なるメモ術ではなく、AIとの作業をチームの資産に変えるための設計です。
AIの「記憶」は、会話を覚えることだけではない
AIエージェントを単発の相談相手として使うなら、会話履歴だけでもかなり便利です。OpenAIのCodex CLIにある codex resume や、Claude Codeの claude --resume です。これらは前回の作業机をそのまま開く仕組みとして、個人の生産性を支える頼もしい機能です。
ただ、実際の業務で重宝するのは「会話全文」だけではありません。担当交代時に申し送る、翌週に判断理由を振り返る、あるいは別のAIツールに作業を渡す。こうした場面では、時系列のログを掘り返すよりも、決定事項や判断理由が整理された引き継ぎノートがあるほうが、迷いにくく作業を続けられます。
会話を再開するための「会話の再開」と、業務を継続するための引き継ぎノート。これらが違う役割だと分かれば、便利な再開機能に、業務上の正本管理 という重荷を背負わせずに済みます。
Gitで管理するメモリ：チームで「判断」を運用する
Gitで管理するメモリの面白さは、記憶の量ではなく、その透明性と履歴にあります。リポジトリ内で版管理される引き継ぎノートや指示を、チームの資産として扱う方法です。
Gitの基本コンセプトが示す通り、Gitは変更履歴を追跡し、以前の状態へ戻るための仕組みです。Gitで管理するメモリで効いているのは、ツールとしてのGitそのものではなく、変更履歴・レビュー・更新責任の3点が同じ場所に揃うことです。
特に次のような場面では、Gitの持つレビュー可能性が効いてきます。
- 複数人が同じAI作業ルールを更新する
- 外部委託先へ判断理由を渡す
- モデルやツールを変えても残したい判断がある
- 後から「なぜこの指示に変えたか」を確認したい
既存の業務ツールとの使い分けも明快です。進捗・担当・期限・顧客要望はLinearやJiraの正本に任せ、コードやAI作業に近いルール、実装判断、再発する注意点などはリポジトリ側の引き継ぎノートに置く。このように分けると、人間には進捗の正本が、AIとチームには判断の履歴が、それぞれ使いやすい形で届きやすくなります。
まず4つの置き場所に分ける
AIエージェントの記憶を整理するときは、情報を次の4つの置き場 所に振り分けるところから始めます。置き場所が分かれていれば、何を残して、何を残さないでよいかも自然に決まります。
- 会話の再開（session resume） — 前回の作業を開き直す。直前のやり取り、作業途中の文脈、試行錯誤の流れを一時的に保持するのに向いています。
- ルールファイル / プロジェクトメモリ — 毎回説明したくない「作法」を渡す。ビルドコマンド、レビューの観点、禁止事項、コーディング規約などが向いています。
- 引き継ぎノート — 人とAIが次に使う進捗状況を残す場所。決定事項、判断理由、未解決事項、次のステップ、見直し条件などが向いています。
- 業務DB・検索基盤などの正本 — 会社として正式に参照する。顧客情報、契約状態、FAQ、社内規程など、AIの記憶の外側にある「事実」です。
手元の情報をどこに置くか迷ったら、次の3点を確認してみてください。
- これは次回の会話でだけ使う一時的な文脈か？（→ 会話の再開で十分）
- チームやAIが毎回読むべき、安定したルールか？（→ プロジェクトメモリへ）
- 後で人が「なぜこうなったか」を振り返るための記録か？（→ 引き継ぎノートへ）
変わりやすい数値や担当者名を本文に固定せず、「最新の確認先」と「いつ時点の情報か」を残すのがコツです。Linear、Jira、Notionといった既存ツールとも役割を分担しましょう。進捗や顧客要望はタスク管理ツールを正本にし、人間向けの読みやすい方針文書はNotionに、そしてAIが作業開始時に読むべきルールやコードに近い 判断はリポジトリ側に置く。この分担が見えると、AIに任せる範囲を決めやすくなります。
代表的な仕組みは、得意な記憶が違う
同じ「メモリ（memory）」や「コンテキスト（context）」という言葉でも、ツールごとに担当している役割は違います。Codex、Claude Code、GitHub Copilot、Clineの代表的な仕組みを、置き場所ごとの得意分野で見直してみます。
resume（会話の再開機能）は作業内容を次の日に持ち越せる
resumeの価値は、昨日の集中力を今日にすぐ持ち越せることです。CodexやClaude Codeの会話の再開機能（codex resume や claude --resume）を使えば、調査や実装の途中で中断しても、コマンド一つで元の作業机に戻れます。個人作業の摩擦を減らすには、まず頼りたい機能です。
AGENTS.md / CLAUDE.md はプロジェクトの作法を共有しやすい
AGENTS.mdやCLAUDE.mdの価値は、AIに毎回プロジェクトの作法を説明しなくてよくなることです。CodexのAGENTS.mdガイドやClaude Codeのドキュメントにあるような、ビルド・テストコマンドやコーディング規約の指定がこれにあたります。「AI向けのマニュアル」をリポジトリに置いておく感覚です。
自動メモリと構造化ドキュメントは「再説明」を減らす
GitHub Copilot Memoryのような「自動メモリ」は、ツール側がコード根拠（citation）を伴う事実を蓄積・検証することで、人間が前提を繰り返す負担を減らしてくれます。
一方、ClineのMemory Bankは、人とAIが明示的に進捗や構造をMarkdownで更新していく方法論です。「ツールが裏側で覚える記憶」と「自分たちで意図的に残す構造化ドキュメント」。この違いを意識しておくと、運用責任の置き場所を判断しやすくなります。
引き継ぎノートに残すべきもの
引き継ぎノートは、単なるメモというより、次に作業する人やAIが最短で「判断の背景」へ戻れる案内役です。具体的に残したいのは、次の5つの要素です。
- 進捗状況: どこまで終わったか
- 決定事項: 何を採用し、何を見送ったか
- 判断理由: なぜその選択をしたか
- 未解決事項: まだ確認していないこと
- 次のステップ: 次に誰が何を見るか
これらを引き継ぎノートとして機能させるには、さらに更新日、オーナー、根拠リンク、見直し条件を添えるのが実務上のポイントです。
反対に、会話の全文を書き写したり、機密情報そのものを引き継ぎノートに詰め込んだりすると、次に開いた人 が探す情報が増えるだけで、引き継ぎの手間は逆に重くなってしまいます。1行の記録があるだけで、翌週に再開するときの手がかりになります。
APQCのナレッジマネジメントに関する整理でも、必要な知識を必要な人へ適切なタイミングで流す重要性が説かれています。AIエージェントの記憶設計も、結局はここで言う「必要な判断を、次に必要な人とAIへ渡せる形にする」話に近いはずです。
記憶を増やすほど便利になるわけではない
うまく管理できるからこそ、AIに任せる範囲を少しずつ広げやすくなります。一方で、古い前提や誤った判断が残っていると、AIがそれをもっともらしく再利用してしまい、「正しいはずの古い情報」がノイズになるリスクもあります。
Claude Codeのドキュメントでも、会話の再開時に過去の実行結果が再利用されるため、時刻などの値が古くなりうることが示されています。また、IPAの導入ガイドラインなどが指摘するように、機密情報の扱いや過剰な権限付与も、記憶として残す前に立ち止まるべき場所です。
運用の目安として、安定ルールは直接書き、変わりやすい値は正本への確認先だけを書き、機密情報は管理システム名にとどめるという使い分けを持っておくと安心です。
小さく始めるなら、まず3つだけ分ける
最初から完璧な引き継ぎノートを作る必要はありません。次にAIエージェントと対話するとき、作業の最後に次の3つへ仕分けるところから始めると、チームにとっても扱いやすい整理になります。
- 会話の再開で続けるもの: 個人が前回の続きに戻るだけの一時的な文脈。
- プロジェクトメモリに置く安定ルール: 次回以降も守ってほしい「作法」。
- 引き継ぎノートに残す進捗・判断・注意点: チームや将来の自分に渡したい実務上の索引。
まず試すなら、作業の最後にこの項目を書き残すところから始められます。
### 2026-05-23 引き継ぎノート（例）
- 目的: 認証APIのエラーハンドリング調査
- 進捗状況: 異常系のテストケース洗い出し完了。実装は未着手
- 決定事項: エラーレスポンスはRFC 7807に準拠（理由：フロントエンド側の要件）
- 未解決: タイムアウト時の再試行回数の閾値
- 次のステップ: インフラ担当の鈴木さんに負荷分散側の設定を確認
- 根拠リンク: [内部設計ドキュメントへのURL]
- オーナー / 見直し予定: 開発チームA / 次回スプリント定例後に更新
この引き継ぎノートは、AIに読ませるためだけの文書ではありません。人が担当交代するとき、外部委託先へ渡すとき、後から判断理由を確認するときにも使います。AI活用だけでなく、人間の引き継ぎにも扱いやすい整理になります。
まず「毎回説明していること」を洗い出す
AIエージェントの活用は、大きなシステムを組む前から始められます。最初の一歩は、自分の業務でAIに毎回同じ説明をしている前提を洗い出すことです。
次にAIを開いたとき、進捗・判断・未確認・次のステップの数行が残っていれば、続きはかなり楽になります。最初は、毎回AIに説明している前提を3つ（会話の再開・プロジェクトメモリ・引き継ぎノート）に分けるところからで十分です。「毎回新人」にしないための引き継ぎ設計は、そこから始まります。
よくある質問
- AIの自動メモリに任せてよい？
- 再説明の手間を減らすには便利ですが、重要な決定事項や会社として残したい判断まで任せきるのはまだ早いかもしれません。必須ルールや重い判断は、人が目を通せるドキュメントに寄せるほうが、中長期的な信頼性は高まります。
- LinearやJiraに全部書けばよいのでは？
- 進捗、担当者、期限、顧客要望は、業務ツールの正本に置くと無理なく回せます。開発現場であれば、AIエージェントが作業開始時に読むべき安定ルールや実装判断までタスク管理ツールに詰め込むと、情報が混ざり、かえって次の作業へ進みづらくなることがあります。何の正本か、誰が主に読み書きするかで分けるところから始められます。
- Gitを使わない部署ではどう考える？
- Gitにこだわる必要はありません。大事なのは、変更履歴があり、人が見直せて、更新責任者がわかることです。Notionや既存のタスク管理ツールでも、これらの条件を満たせば、引き継ぎノートとして機能します。
- 古い前提や誤りはどう減らす？
- 自動で増え る記憶に頼り切るのではなく、更新日・見直し条件・担当者を決めて、定期的に消せる状態で運用しましょう。安定ルール、状況、判断履歴、正式データを分けておけば、不要になった前提を整理する場所も明確になります。
更新履歴（最終更新: 2026年5月23日）
- 初回公開
著者プロフィール
大崎 一徳 / エンジニア
中小企業向けに、AI導入・業務自動化・ツール開発を支援しています。 PoC から本番運用まで一貫して伴走し、「現場で使われ続ける仕組み」をつくることを大切にしています。
Udacity Deep Learning Nanodegree 修了
日本ディープラーニング協会（JDLA）主催 第1回ハッカソン GPU Eater賞受賞（チーム ニューラルポケット）
