マルチアカウントエージェント
── 一つの記憶を、複数のClaudeが共有するとき

1. Claudeには記憶がない、という前提

Claude.aiはセッションをまたいで記憶を保持しない。これはよく知られた事実であり、多くの人がこれを「限界」と呼ぶ。会話が終われば、前回の文脈は消える。新しいセッションを始めるたびに、また一から説明しなければならない。

しかし、この「限界」は前提の設定ミスから生まれている。Claudeに記憶させようとするから詰まる。正しい問いは「どこに記憶を置くか」だ。

答えはGitHubにある。セッションが終わっても、GitHubリポジトリは消えない。そこに書いたものは永続する。次のセッションでClaudeがそのリポジトリを読めば、記憶は復元される。Claudeの「中」に記憶を持たせるのではなく、Claudeの「外」に記憶を置く設計。これがこのアーキテクチャの核心だ。

2. アカウントを増やすとはどういうことか

Claude.aiは複数のアカウントを持てる。Anthropicはこれを制限していない。一つは個人用、一つはビジネス用、一つは特定プロジェクト専用——そういう使い方が想定されている。

通常の使い方では、アカウントを増やすほどに文脈が分散する。Aというアカウントで話した内容をBというアカウントは知らない。断絶が生まれる。

しかし、全アカウントが同じtr/リポジトリを参照するなら話が変わる。

アカウントA（朝の業務確認）→ tr/ を読む → 判断 → tr/ に書く
アカウントB（エッセイ執筆専用）→ tr/ を読む → 執筆 → tr/ に書く
アカウントC（プロジェクト管理専用）→ tr/ を読む → 更新 → tr/ に書く

それぞれのアカウントは独立したセッションを持ちながら、同じ記憶から出発し、同じ記憶に書き戻す。断絶ではなく、役割分担が生まれる。

3. 役割分担という設計思想

人間の組織では、総務・開発・営業という役割分担がある。同じ会社の人間が、異なる専門性を持って動く。これを一人の万能社員にやらせようとすれば、質が落ちる。

マルチアカウントエージェントも同じ発想だ。一つのアカウントにすべてをやらせようとしない。それぞれのアカウントに、Claude Projectのシステムプロンプトで専門性を与える。

たとえば、エッセイ執筆専用アカウントのシステムプロンプトにはtr/skills/essay/SKILL.mdの内容が深く組み込まれている。プロジェクト管理専用アカウントは、GitHub Projectのタスク構造と更新アクションに精通している。朝のブリーフィング専用アカウントは、morning-briefingスキルをデフォルトで起動する。

アカウントごとにキャラクターが違う。しかし、全員が同じ記憶を持っている。

4. 記憶の設計こそが、エージェントの設計だ

このアーキテクチャで重要なのは、記憶の「構造化」だ。全アカウントが共有するtr/memory/には、明確な役割分担がある。

tr/memory/context/claude-flow.md — システム全体の設計思想と背景
tr/memory/daily/YYYY-MM-DD.md — その日の作業ログと次のアクション
tr/project/cache/project.json — タスク一覧の最新キャッシュ
tr/skills/ — 各アカウントが参照するスキル定義

どのアカウントが起動しても、まずこれらを読む。これが「起動手順」として憲法（CLAUDE.md）に明記されている。記憶を読むことから始める——これが、すべてのClaudeを同一のエージェントたらしめる儀式だ。

そして作業が終われば、write_memoryアクションで日次ログを更新する。次にどのアカウントが起動しても、その続きから始められる。

5. 分身は増殖できる

このアーキテクチャの最大の特性は、スケールコストがほぼゼロだということだ。新しいアカウントを作り、同じtr/リポジトリへのPATを渡し、役割を定義したシステムプロンプトを書く。それだけで、新しい分身が誕生する。

分身は何人いても、脳は一つだ。記憶が分散しない。判断基準が揺れない。一方の分身が昨日書いた知見を、今日別の分身が参照して次の判断に活かす。組織のように機能する、一人のエージェント。

これは個人の業務自動化の文脈だけでなく、チームでの活用も示唆する。複数人が同じtr/を共有すれば、Claudeは「共有秘書」になる。全員の文脈を知りながら、担当者ごとに異なる専門性で動く。