こんにちは。ACS事業部の越川です。
皆さんは普段使っているAIツールが、どのように「記憶」しているかを意識したことはありますか？
同じ質問をしても、ツールによって返ってくる答えの精度がまるで違う。その差の正体は、モデルの性能だけではありません。そのツールが 何を覚えていて、何を忘れるか という記憶の設計が大きく影響しています。
この記事では、当社で業務利用できるAIツールを中心に、それぞれの記憶の仕組みを比較します。自分が使っているツールの「記憶の癖」を知ることで、AIとの付き合い方が変わるはずです。
- 当社のAIツール利用体制
- NotebookLM — 人間がソースを選び、AIの記憶を組み立てる
- Gemini — 巨大なコンテキストウィンドウという「短期記憶」
- GitHub Copilot — リポジトリに紐づく28日間の記憶
- Claude Code — ファイルベースの2層記憶
- ChatGPT — ユーザーに紐づく永続メモリ（参考）
- 比較してわかること — 記憶の設計思想はツールごとに違う
- 記憶の「編集者」になる
- おわりに
- 参考文献
- ACS 事業部のご紹介
当社のAIツール利用体制
比較に入る前に、当社のAIサービス利用体制を整理します。当社では生成AIハンドブック（情報システム部・品質保証部発行）に基づき、AIサービスを以下の3分類で管理しています。
| 分類 | 定義 | 該当ツール例 |
|---|---|---|
| 全社共通 | 情報システム部がコーポレート部門として全社に提供 | Google Workspace AI、NotebookLM、Slack AI |
| 申請利用 | 利用者が申請し、情報システム部から払い出された環境で利用 | Gemini |
| 部署内利用 | 事業部主導で承認プロセスを経て導入・運用 | GitHub Copilot、Claude Code |
いずれも、入力データがAIモデルの学習に利用されない設定が前提です。また、許可済みサービスであっても、案件ごとのNDA・著作権契約が最優先されます。
この体制の中で、各ツールが「記憶」をどう扱っているかを見ていきます。
NotebookLM — 人間がソースを選び、AIの記憶を組み立てる
NotebookLMは全社共通で利用できるツールです。特徴的なのは、AIの記憶を人間が明示的に組み立てるという設計です。
ユーザーがGoogle Driveの資料やWebページをソースとしてアップロードし、そのソースの範囲内でAIが回答します。つまり「何を食わせたか」がそのまま記憶になります。
私が実感しているNotebookLMの価値は、組織の共通言語を揃えるツールとしての使い方です。
企業理念、事業戦略、社内で使われている用語。これらの意味を他のメンバーと解釈一致させることは、組織の一員として最も重要なことの一つです。当社ではGoogle Driveに社内資料が集約されているので、関連する複数の資料をNotebookLMに食わせて質問することで、様々なドキュメントを引用しながら、間違えることなく自分の言葉としてまとめることができます。社内プレゼン用のスライド作成も、この方法で格段に楽になりました。
記憶の設計という観点で言えば、NotebookLMはキュレーション型です。AIが勝手に覚えるのではなく、人間がソースを選ぶことで記憶の範囲を決める。何を読ませるかという判断が、そのまま出力の質を左右します。
Gemini — 巨大なコンテキストウィンドウという「短期記憶」
Geminiは申請制で利用できます。記憶の観点で注目すべきは、200万トークンという巨大なコンテキストウィンドウです。
これは何を意味するかというと、1回の会話で膨大な量の情報を「短期記憶」として保持できるということです。長大なドキュメントをそのまま渡して要約させたり、複数ファイルを横断して分析させたりする使い方に向いています。
また、Gemini Code Assistには、Pull Requestのフィードバックから自動的にコーディング標準を学習する「PRメモリ」機能もあります。チームのコードレビューの蓄積が、そのままAIの記憶になっていく設計です。
ただし、セッションが終われば会話の内容は引き継がれません。巨大な短期記憶を持つが、長期記憶は持たない。この特性を理解した上で使うことが重要です。
GitHub Copilot — リポジトリに紐づく28日間の記憶
GitHub Copilotは、ACS事業部で部署内利用しているツールです。
Copilotの記憶機能として特徴的なのはリポジトリメモリです。コードの特定の位置への引用付きでメモリを保存し、28日間で自動削除されます。さらに、引用元のコードが変更されていないかを検証してから記憶を利用する設計になっています。古くなった記憶を自動的に捨て、参照元の整合性まで確認するという、記憶の信頼性を担保する仕組みです。
ACS事業部でのCopilotの使い方は、約1年かけて大きく変化しました。2025年前半はコード補完やChatが中心で、Agentモードの存在すら知らないメンバーがほとんどでした。2025年後半に一部の先進メンバーがAgentモードを試し始め、社内で発信したことで認知が広がりました。2026年に入ると社内イベントやブログでの知識共有が加速し、現在ではAgentモードが主流になりつつあります。TeamプランのPremium Requestsを使い切る勢いで活用するメンバーが増え、事業部としてリクエストの増枠に至りました。
この変化は記憶の話と直結します。コード補完の段階では、AIはカーソル周辺の文脈だけで十分でした。しかしAgentモードでは、プロジェクト全体の構造や設計方針を理解した上で提案する必要があります。使い方が高度になるほど、AIに渡すコンテキスト——つまり記憶の設計——が重要になるのです。
Claude Code — ファイルベースの2層記憶
Claude Codeも、ACS事業部で部署内利用しているツールです。
Claude Codeの記憶は2層構造で設計されています。
- CLAUDE.md（インストラクション）: 人間が書くプロジェクトの指示書です。コーディング規約、ワークフローのルール、守るべき制約などを記述します。Git管理が可能で、チームで共有できます
- MEMORY.md（自動学習メモリ）: Claude Codeが会話の中から自動的に学習・記録するファイルです。起動時に最初の200行を読み込み、それ以降はオンデマンドで参照します
このブログの執筆ワークフローを例にすると、CLAUDE.mdには「文末は必ず『です・ます』で終える」「社内の人間は全て『メンバー』と表記する」といったルールが書かれています。MEMORY.mdには、過去の会話から学んだ私の好みや作業の傾向が記録されています。
強みは ファイルベースで版管理できる 点です。記憶の中身を人間がレビューし、編集し、Gitで履歴を追えます。AIの記憶がブラックボックスにならない設計です。
ChatGPT — ユーザーに紐づく永続メモリ（参考）
参考として、ChatGPTの記憶の仕組みも紹介します。
ChatGPTでは、ユーザーが明示的に記憶を指示した内容を サーバーサイドで永続化 します。ユーザーアカウントに紐づくため、デバイスをまたいで記憶が引き継がれます。機密情報は自動的に除外される設計になっています。
プロジェクトではなくユーザー個人に記憶が紐づく点が、他のツールとの大きな違いです。
比較してわかること — 記憶の設計思想はツールごとに違う
ここまでの5つのツールを整理します。
| ツール | 記憶の場所 | 有効期間 | 更新の主体 |
|---|---|---|---|
| NotebookLM | アップロードしたソース | ノートブック単位で永続 | 人間がソースを選ぶ |
| Gemini | コンテキストウィンドウ | セッション限り | 会話の中で自動 |
| GitHub Copilot | リポジトリメモリ | 28日で自動削除 | 自動学習 + 整合性検証 |
| Claude Code | CLAUDE.md / MEMORY.md | プロジェクト単位で永続 | 人間が書く / 自動学習 |
| ChatGPT | サーバーサイド | ユーザー単位で永続 | 人間が明示的に指示 |
共通しているのは、すべてのツールが 何を記憶するか の制約を持っているという点です。無限に覚えるツールは一つもありません。NotebookLMはソースの選択で、Geminiはセッションの終了で、Copilotは28日の期限で、Claude Codeは200行の読み込み制限で、それぞれ記憶の範囲を区切っています。
これは人間の記憶と似ています。私たちもすべてを覚えていられるわけではなく、感情や重要度によって何が記憶に残るかが変わります。
違うのは、記憶の管理を誰がどうやるかです。
- 人間の記憶: 感情・体験・重要度という内的な重み付けで自然に管理される
- AIの記憶: ウィンドウサイズ・ファイル設計・有効期限という外的な仕組みで管理される
AIは記憶を保持できますが、その中から 何が重要で、何を残すべきかを自ら判断することはできません 。NotebookLMにどの資料をソースとして読ませるか。CLAUDE.mdにどんなルールを書くか。ChatGPTに何をRememberさせるか。これらの取捨選択はすべて人間が行う必要があります。
記憶の「編集者」になる
AIツールの記憶を活かすために、普段の業務で意識できることを3つ挙げます。
1. 何を覚えさせるかを意図的に選ぶ
どのツールでも、記憶に入れた情報が自動的に整理されることはありません。NotebookLMにソースを追加するとき、CLAUDE.mdにルールを書くとき、「その情報は本当に必要か」を一度立ち止まって考えることが大切です。情報が多すぎると、かえってノイズになります。
2. 「なぜ」をセットで記録する
記憶の信頼性は「なぜそうするか」が添えられているかどうかで決まります。ルールだけを残すと、状況が変わったときにAIはそのルールを盲目的に踏襲します。理由があれば、状況に応じた判断ができます。
3. 定期的に記憶を見直す
GitHub Copilotが28日でメモリを削除するのは、古くなった記憶が邪魔になるからです。人間も同じで、AIに覚えさせた内容を定期的に見直し、古いルールを更新・削除することが大切です。
おわりに
AIツールは日々進化していますが、「記憶をどう設計するか」という問いは変わりません。今日紹介したツールの記憶の仕組みも、半年後には変わっているかもしれません。
大事なのは、自分が使っているツールの記憶の癖を知り、 何を覚えさせて、何を忘れさせるかを意図的に選ぶ こと。AIの記憶の編集者として関わり続けることが、AIとうまく協働するための第一歩だと思います。
当社では生成AIハンドブックのもと、全社共通から部署内利用まで、ガバナンスを保ちながらAIを活用する体制を整えています。こうした仕組みの中で、一人ひとりがAIの記憶を上手に使いこなしていくことが、組織全体のAI活用の質を上げていくことにつながるのではないでしょうか。
参考文献
- How Claude remembers your project - Claude Code Docs
- About agentic memory for GitHub Copilot - GitHub Docs
- NotebookLM でデータを保護する仕組み - Google
- Memory overview - LangChain Docs
- Memory FAQ - OpenAI
ACS 事業部のご紹介
私の所属する ACS 事業部では、開発者ポータル Backstage、Azure AI Service などを活用し、Platform Engineering ＋ AI の推進・内製化を支援しています。
www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp
また、GitHub パートナーとしてお客様に GitHub ソリューションの導入支援を行っています。 GitHub Copilot などのトレーニングなども行っておりますので、ご興味を持っていただけましたらぜひお声がけいただけますと幸いです。
一緒に働いていただける仲間も募集中です！ ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です
