第6章 メモリ：使うほどにあなたを理解するBotへ

Botのメモリは、セッションを跨ぐ作業コンテキストです。すべてのチャットをメモリとして扱うと、一時的な便宜上の対応を恒久ルールと誤認しやすく、さらには古いデータに基づいて不適切な判断を下すリスクがあります。

• 5つのコンテナ分類と長短クロックを理解し、メモリとスキルを明確に区別する。
• チーム連携では昇格プロトコルを策定し、変動データはリアルタイムにソース元へ確認する。
• Gitでバックアップパイプラインを構築し、クラウドPCがリセットされても完全に復元できるようにする。

6.1 公式メモリ機能：Botは一体何を記憶しているのか

Botは好み、事実、サマリーを記憶します。詳細は Grok Bot の使用 を参照してください。

Botをデータベース代わりにしてはいけません。

• 変動データはソースシステムに残し、重大な意思決定は情報源を直接確認する。
• 記憶違いや前提が古くなった場合は、会話を通じて直接修正または削除する。
• セキュリティと権限は承認ポップアップと Auto-review で担保し、決してメモリに依存しない。
• 長期的なルールは冒頭で明確に指示し、単発タスクの指示はそのターンのみ適用させる。

画面上部の名前をクリックして設定を変更します。iPhone で Bot を複製する場合：

• 継承されるもの：設定、スキル、Routine、アバター
• 継承されないもの：会話、メモリ、添付ファイル

今後も使用する可能性がある場合は、サイドバーで「非表示」に設定することを推奨します。直接削除すると履歴が消去されます。注意点：すべての Bot はクラウドPCを共有しているため、Bot を削除してもファイルやログイン状態はクリアされません。残存データはファイルシステムから手動でクリーンアップする必要があります。

6.2 メモリの階層化：5つのコンテナと長短クロック

データは共有層と専用層に分かれています。「4.6 仮想マシン、メモリとバックアップ」fs69.md を参照してください。

5つのコンテナモデルについては、『Grok Bot Memory Engineering: How One Agent Learns With a Team｜rari』fs57.md を参照してください。

实时数据源 (LIVE SOURCE)  -> 存在 Linear、Datadog、CRM、代码库或知识库里的当前事实
团队技能 (TEAM SKILL)     -> 由 Bot 所有者维护的标准化、可重复执行的操作流程
团队记忆 (TEAM MEMORY)    -> 经过核准的全员共享决策与稳定业务定义
私人便签 (PRIVATE NOTE)   -> 个人专属偏好与单人工作上下文
任务状态 (TASK STATE)     -> 当前正在执行的任务进度与临时上下文

コンテナを混同してはいけません。ログはその都度破棄し、ワークフローはスキルへ、個人の習慣はプライベートノートへ記録し、P0レベルの重要定義のみをチームメモリへ登録します。

汚染を防ぐには、長短クロックによるトラフィック分離を活用します。

• 長期クロック：スタイルや定義など月年単位で変わらないものは、メモリに書き込みます。
• 短期クロック：残高など随時変動するものは、アクション前に必ずソース元へ問い合わせます。

パスワードや Token は決してメモリに入れず、ドキュメントにはポインタのみを保持します。リアルタイムな状態は API で確認し、メモリを根拠に権限を許可してはいけません。

6.3 メモリとスキルの境界線：何を知っているか（知識）とどう実行するか（手順）

メモリ（週アクティブ40%減）	スキル
事実と設定	プロセスと承認

優れたワークフローはプロンプトをスキルとして保存します：

将我们用于此任务的流程保存为名为“每周账户健康状况”的技能。
包括源系统、风险定义、输出格式，以及联系客户始终需要批准这条规则。

画面デモの3ステップ：

1. チャットでコンピュータービューを開く
2. 「タスクを教える」を選択して成果物を入力
3. 画面デモを実施

制限時間は10分で、マイク音声やパスワードは録音・録画されません。@mvanhorn 氏によれば10分を超えると失敗しやすいため、短いフェーズに分割して連携させることが推奨されています。fs46.md

Lauren Tan 氏によるトラブルシューティングの優先順位：根本原因の解消 > テスト検証 > 専用ルール策定 > メモリの修正。チームスキルは Creator または Manager が公開し、ダイレクトメッセージでの設定は個人専用となります。

fs57.md

6.4 チームメモリの管理：書き込みプロトコル、権限分離、衝突防止

複数人で Bot を共有する場合、1人が間違えて学習させると全員に影響が及びます。

观察 (OBSERVE) -> 分类 (CLASSIFY) -> 核实 (VERIFY) -> 晋升 (PROMOTE) -> 重核 (RECHECK)

メモリへの書き込みは5つのステップに従います：

1. 観察 (OBSERVE)：修正指示や新たな決定事項をキャプチャする。
2. 分類 (CLASSIFY)：個人の好みと共有ルールを明確に区別する。
3. 検証 (VERIFY)：ドキュメントやコードと照合し、口頭での推測の登録は厳禁とする。
4. 昇格 (PROMOTE)：責任者の承認を経て、ルールおよび公式リンクとして保存する。
5. 再確認 (RECHECK)：重大な操作の直前や有効期限の到来後に、改めてソース元を再検証する。

claim: "对外发布 API 变更前必须完成安全评审"
scope: "team"
source: "https://intranet.example/docs/launch-checklist"
owner: "security-team"
status: "approved"
review_after: "2026-11-01"

外部カードは情報元と責任者を確認した上で、指示を送信して登録します。

ナレッジの共有は権限の共有ではありません：

• 個人 OAuth：Gmail などのプラグイン呼び出しは本人の認可を経由し、権限の不正利用を防ぎます。
• サービスキー：全員で共有し、最小権限の原則に従い、通常は読み取り専用にします。
• Slack での注意点：チャンネル内で機密データを取得すると全員に露出してしまいます。公開チャンネルにはサマリーのみを投稿し、機密データはダイレクトメッセージへ誘導します。

コンフリクト（競合）の裁定：重要な操作を直ちに一時停止 -> 正式なソースを確認 -> 責任者が裁定 -> ソース元を更新 -> メモリを修正。

不適切なメモリのトラブルシューティング（例外対応を恒久ルールと誤認した場合など）：

1. 調査：Bot にメモリを一覧表示させてエラーを特定し、元の会話やタスクを追跡する。
2. 修正：まずソース元のドキュメントを修正してから、指示を送信してメモリを削除・変更する。
3. 検証：別のメンバーのアカウントに切り替えてテストし、意図しないブロックが発生しないことを確認した上で、過去のチケットの誤りを是正する。

6.5 メモリのバックアップと復元：クラウドPCを代替可能なコンテナとして扱う

同一アカウント内のすべての Bot は /workspace を共有します（v0.68.1 の解像度は 1920×1200）。

クラウドPCは公式によっていつでもリセットされる可能性があります（2026-10-10 に実際に発生しました）。インストール済みのパッケージやコミットされていない状態はすべて消去され、ローカルデータは失われると復旧できません。背景は fs69.md を参照してください。

バックアップ手順と認証情報のセキュリティ

運用 Bot「メモリマネージャー」を作成し、4つのステップでプライベート Git リポジトリへバックアップします。

1. 新しい Bot を作成して「メモリマネージャー」と命名し、すべての Bot の規約、ルール、メモリを定期的にエクスポートする役割を明記する。
2. /workspace でプライベート Git リポジトリを連携し、bots-backup/charters/（指示プロンプト）、bots-backup/memories/（ルール）、environment/（スクリプトおよび services-ledger.md を含む）を作成しておく。
3. 毎週定期実行される Routine を設定し、設定とメモリを Markdown として保存する。
4. Routine により Git コマンドを自動実行し、リモートのプライベートリポジトリへコミット＆プッシュする。

バックアップ手順と認証情報のセキュリティ

/workspace/
└── bots-backup/
    ├── charters/          <- 各 Bot 的长期规则 (如 researcher.md, writer.md)
    ├── memories/          <- 团队共用决策与业务定义 (如 definitions.md)
    └── environment/
        ├── services-ledger.md  <- 服务总账，记录工具依赖与启动命令
        └── restore.sh          <- 虚拟机一键重置恢复脚本

• 平文の Token を Git にコミットすることは厳禁です。自動化スクリプトはローカルの ~/.env からのみシークレットキーを読み取ります。
• ログイン、2段階認証、または CAPTCHA に遭遇した場合は、人間が画面操作を引き継ぎます。Bot は Cookie のみを引き継ぎ、平文のパスワードに触れることはありません。詳細は Grok Bot の使用 を参照してください。

6.6 すぐに使える実践プロンプト集

3層指示フレームワーク

Bot を構築する際は曖昧な紹介文を書くのではなく、3層フレームワークを用いてルール、責務、現在の注力事項を明確にします。詳細は fs46.md を参照してください。

3層指示フレームワーク

BASE INSTRUCTIONS (基础规则，本账号所有 Bot 通用)
- 涉及产生财务支出、向外部发送任何信息、删除文件等操作前，必须等待人工确认。
- 当结论涉及重要业务决策时，必须调取当前权威来源进行核对，严禁单凭记忆作答。
- 若执行受阻，用单行明确说明受阻点，禁止擅自寻找不可靠的绕行方案。
- 阶段性工作交接结果统一写入 /workspace/shared/handoffs/ 目录。

ROLE (角色职责)
- 你的身份：每周账户健康状况审计专员。
- 你负责的固定作业：获取客户产品用量与工单信号，标记流失或扩张迹象。
- 验收标准：每项结论必须附带源系统监控图表或工单链接。
- 允许操作：读取日志、检索系统指标、在共享目录生成评估报告。
- 严禁操作：未经明确批准，绝不私自联络客户，绝不修改账户权限。

CURRENT FOCUS (当前重点)
- 本周重点核查用量环比下降超过 30% 的企业级客户名单。

チームスキルへの変換

タスクの実行が成功したら、直接指示を出してスキルとして定着させます。

チームスキルへの変換

请将本次执行的工作流整理并保存为团队技能，名称设为“客户流失风险排查”。
要求包含以下内容：
1. 触发场景与必需的前置凭据。
2. 调取指标数据的具体步骤与判定阈值。
3. 输出结果的格式规范（必须包含数据源链接）。
4. 明确安全红线：向客户发送邮件或调整账户配置必须经由人工批准。
完成后在对话中回复技能概要。

共有メモリへの書き込み

責任者の承認を受けたルールは、ソース元と責任者を明記して書き込みます。

请为全团队记住以下判定规则：
对于所有对外发布的 API 变更，必须在发布前检查现行上线清单，并获取安全团队的正式签字评审。
若上线流程发生变更，以上线清单源文档为准，记忆仅作为指引。
来源文档：https://intranet.example/docs/api-checklist
责任人：security-team
复核日期：2026-11-01

メモリマネージャーのデプロイ

「メモリマネージャー」Bot 内で、自動バックアップ Routine を設定する指示を送信します。

你是本账号的记忆管家。你的职责是定期归档全账号所有 Bot 的章程与共享记忆。
请配置一个每周运行的例行任务（Routine）：
1. 提取所有 Bot 当前的 Description/Instructions 规则，在 /workspace/bots-backup/charters/ 下按 Bot 名称分别保存为 .md 文件。
2. 提取当前所有已保存的团队共用记忆，整合保存为 /workspace/bots-backup/memories/team-memory.md。
3. 检查文件是否有更新。若有变更，自动执行 git add .、提交并推送至已配置好的私有 Git 仓库。
4. 若 Git 推送失败，在当前对话中告警并说明报错信息；若无变更则保持静默，不要频繁推送无意义通知。

不適切なメモリのクリーンアップ

誤ったルールや古いルールが参照されているのを発見した場合は、指示を出して直接修正・削除します。

请检查并列出你当前记录的所有团队记忆中涉及“企业客户续约审批”的条目。
删除其中“所有企业客户续约必须经由 VP 逐笔批准”的内容。
该规则仅为上周特定情况下的临时特例，不是长期标准。
从现在起，企业客户续约标准重新以财务知识库的正式文档为准：https://intranet.example/finance/renewals
确认修改后，请向我展示修正后的相关记忆列表。

6.7 代表的な事例の振り返り

事例1：SpaceXAI データ分析Bot

SpaceXAI チームは、45,000 テーブルにおよぶ超大規模データウェアハウスを照会する必要がありました。

• 膨大なデータを無理にメモリに詰め込んではいけません。彼らは Bot に読み取り専用のデータウェアハウス認証情報を設定し、テーブル探索やクエリ実行をスキルライブラリとして定着させました。
• メモリには指標の定義基準や補正ルールのみを保持し、変動データはリアルタイムに取得・計算します。

詳細は fs57.md を参照してください。

事例2：マルチBot協調によるツイートプロファイリングパイプライン

0xlangeai 氏は、キュレーター、アナリスト、デザイナー、エンジニアの4つの Bot を構築してツイートプロファイリングパイプラインを運用しました。

• 異なる Bot 同士は互いのチャット履歴を読み取ることができません。
• Bot 間の連携はファイルシステムを介して成果物を受け渡す必要があります。キュレーターが tweets.md を生成し、アナリストがそれを読み取って profile.md を出力し、デザイナーがこれに基づいて design.md を作成し、エンジニアがコードを取得してビルド・リリースします。

詳細は fs69.md を参照してください。

事例3：Jon ONeill 氏の配管ディスパッチシステム

Jon ONeill 氏は、Gmail、Slack、ServiceTitan、顧客ポータルにまたがるチケットスケジューリングを自動化しました。

• 単一の万能ディスパッチ Bot にすべてのルールを担わせると、混乱とエラーが生じやすく、最終的に停止せざるを得なくなりました。
• タスクを専門の Bot に分割：Gary が Gmail を監視し、Steve が ServiceTitan の工期を確認し、Quinn が SMS を送信し、Sarah が Slack で従業員と連携し、Atlas が全体を統括します。
• 責務を細分化したことで、毎日5〜6件の緊急チケットを安定して処理し、10分以内に全プロセスのスケジューリングを完了できるようになりました。

詳細は fs46.md を参照してください。

6.8 よくある落とし穴

• 変動データはリアルタイムに問い合わせる：在庫数をメモリに保存してはいけません。古いデータによる Bot の誤判断を防ぎます。
• 環境設定は必ずスクリプト化する：クラウドPCで手動設定を行うと、リセット時にすべて消去されます。
• 個別チャットの指示をチーム全体に適用しない：特別承認をそのまま共有すると、チーム全体の振る舞いを汚染してしまいます。
• Bot を分けるだけではデータ分離できない：同一アカウント内ではファイルを共有するため、アクセス権限と Ask-first（事前確認）承認で制御します。
• パスワードをチャット入力欄に送信しない：ログへの漏洩を防ぐため、安全な認証情報ストレージを利用するか、人間が画面操作を引き継ぎます。
• Slack で機密データを照会しない：公開チャンネルで質問すると、プライベートな情報が全員の目に触れることになります。

6.9 完了後の検収方法

メモリの境界をテストするには、コミュニティの著者 rari（@0xwhrrari）氏が設計した M01〜M05 テストケースを直接実行します。

M01 个人偏好隔离测试 -> 成员 A 在私聊中设定个性化偏好，使用成员 B 账号发起提问，确认 B 绝不继承 A 的私聊偏好。
M02 团队规则晋升测试 -> 成员 A 提交一条经审批的团队规则并写入团队记忆，成员 B 发起任务时应生效该规则，但看不到 A 当时的私聊对话。
M03 状态时效回源测试 -> 在团队记忆中保留一条旧状态，在源系统修改为新状态。向 Bot 提问，Bot 必须调取最新源数据，而不是采信记忆中的旧状态。
M04 冲突自动阻断测试 -> 两个成员分别向 Bot 给出互相矛盾的业务说法。Bot 应识别出冲突并主动停止高风险操作，指出需要责任人裁决，而不是悄悄采纳最后一条说法。
M05 共享渠道边界测试 -> 在 Slack 共享频道线程中，要求 Bot 调用某成员的个人连接器。Bot 必须正确发起审批，且回复内容只包含团队可见的脱敏结论。

ここでは、必ず2つの異なる実際のチームアカウントを用いてクロス検証を行ってください。単一のアカウントでは分離境界を検証できません。

1. GitHub または GitLab のプライベートリポジトリにログインし、bots-backup/charters/ 配下の各 Bot のルールファイルがコミットされており、ルールや権限が保持されていることを確認します。
2. bots-backup/memories/team-memory.md を確認し、チームの判定ルールとソースシステムのリンクが完全に揃っていることを確認します。
3. クラウドPCのテストディレクトリで環境復元スクリプトを実行し、依存関係やディレクトリのエラーがなく、1行のスクリプトでサービスを直接起動できることを確認します。

6.9 完了後の検収方法

   bash /workspace/bots-backup/environment/restore.sh

参考文献・関連記事

• 公式ドキュメント：Grok Bot の使用
• コミュニティ記事：rari『Grok Bot Memory Engineering: How One Agent Learns With a Team』fs57.md
• コミュニティ記事：『4.6 仮想マシン、メモリとバックアップ』fs69.md
• コミュニティ記事：Matt Van Horn『Every Grok Bot Hack I Know (Aug 2026)』fs46.md