Stateful Agent Orchestration（SAO）: AIエージェントの記憶の壁を超える方法論
2026年1月13日
はじめに：AIエージェントの「記憶喪失」問題
Claude、GPT、Gemini——AIエージェントは今や開発の現場で欠かせない存在になりました。コードレビュー、バグ修正、新機能実装、ドキュメント作成。彼らは驚くほど優秀です。
ただし、1セッションの間だけは。
従来のAIエージェント:
Session 1 → [認証機能の設計完了] → セッション終了 → 記憶消失 💨
Session 2 → 「認証機能の続きをお願い」→ 「何の話ですか？」
これが、私たちが「記憶喪失問題」と呼んでいる現象です。
大規模なプロジェクトでは、この問題が致命的になります。1週間かけて設計したアーキテクチャも、3日間で積み上げた実装の経緯も、新しいセッションが始まった瞬間にゼロになります。毎回最初から説明し直し、毎回同じ間違いを繰り返すことになります。
SAO（Stateful Agent Orchestration）は、この問題を解決するために生まれた方法論です。
SAOとは何か
SAO（Stateful Agent Orchestration）は、AIエージェントの記憶制限をドキュメントによる状態永続化で解決する方法論です。
一言でいえば、「AIの脳の外部に、永続的な記憶を置く」アプローチになります。
SAO適用後:
Session 1 → [作業] → 状態をドキュメントに保存 📝 → セッション終了
Session 2 → ドキュメントから状態を復元 📖 → [続きから作業]
人間がプロジェクトの引き継ぎ資料を作るように、AIエージェントも「引き継ぎ可能な形式」で作業状態を保存します。次のセッション（あるいは次のエージェント）は、その資料を読んで作業を継続できます。
具体例で理解する
概念だけでは掴みにくいので、まず具体例でSAOの動きを見てみましょう。
例1：ToDoアプリに認証機能を追加する
既存のToDoアプリに「ユーザー認証機能」を追加するプロジェクトです。
Phase構成
| Phase | 名前 | 説明 |
|---|---|---|
| 1 | 認証基盤 | Supabase Auth設定、DBスキーマ、基本API |
| 2 | Google認証 | OAuth設定、ログインボタン、コールバック処理 |
| 3 | メール認証 | サインアップ/ログインフォーム、バリデーション |
| 4 | パスワードリセット | リセットメール、新パスワード設定画面 |
SAOがない場合（従来）
【1日目】
Claude: DBスキーマを設計して、Supabase Authを設定しました
→ セッション終了
【2日目】
User: 昨日の続きお願い
Claude: すみません、どこまで進んでいましたか？何を設計しましたか？
User: えーと、DBスキーマと...（説明に10分）
Claude: 理解しました。では...（また最初から確認しながら進める）
SAOがある場合
【1日目】
Claude: Phase 1 Step 2まで完了しました
→ README.mdに進捗を記録
→ 「Step 3: API実装が未着手」と明記
→ セッション終了
【2日目】
Claude: README.mdを確認... Phase 1 Step 3から再開します
→ 説明なしで即座に続きから作業開始
実際に生成されるドキュメント
SAOプロジェクトでは、以下のようなドキュメントが生成・更新されます：
# Phase 1: 認証基盤
| 進捗 | `進行中` 🔄 |
| 開始日 | 2026-01-10 |
| 担当 | Claude |
## Step別進捗
### Step 1: DBスキーマ作成
| 状態 | `完了` ✅ |
- [x] usersテーブル作成
- [x] sessionsテーブル作成
- [x] マイグレーション適用確認
### Step 2: Supabase Auth設定
| 状態 | `完了` ✅ |
- [x] プロジェクト設定確認
- [x] 認証プロバイダ有効化
- [x] リダイレクトURL設定
### Step 3: 認証API実装
| 状態 | `未着手` |
- [ ] サインアップエンドポイント
- [ ] ログインエンドポイント
- [ ] ログアウトエンドポイント
## 更新履歴
| 日付 | 更新者 | 内容 |
|-----|-------|------|
| 2026-01-10 | Claude | Step 1-2 完了 |
次のセッションでは、このREADMEを読むだけで「Step 3から開始」と即座に判断できます。
例2：大規模リファクタリング（1週間以上）
レガシーなREST APIをGraphQLに移行するプロジェクト。50以上のエンドポイントがあり、1セッションでは到底終わりません。
Phase構成と依存関係
Phase 1: 基盤構築（GraphQLサーバー設定、スキーマ設計）
│
├──► Phase 2: ユーザー系API（User, Profile, Settings）
│
├──► Phase 3: コンテンツ系API（Post, Comment, Like）
│
└──► Phase 4: 通知系API（Notification, Subscription）
│
↓
Phase 5: 旧API廃止
Phase 1完了後、Phase 2-4は並行して進められます。全部完了してからPhase 5に進みます。
セッションをまたいだ実行
【月曜】Session 1: Phase 1 完了
【火曜】Session 2: Phase 2 Step 1-3 完了
【水曜】Session 3: Phase 2 完了、Phase 3 開始
【木曜】Session 4: Phase 3 Step 1-2 完了 ← ここでブロッカー発生
【金曜】Session 5: ブロッカー解消、Phase 3 完了
【翌週月曜】Session 6: Phase 4 完了
【翌週火曜】Session 7: Phase 5 完了 → プロジェクト完了 🎉
7つのセッションをまたいでも、各セッションでエージェントは「今どこにいるか」「次に何をすべきか」を即座に把握できます。
SAOの仕組み
具体例でイメージが掴めたところで、SAOの仕組みを詳しく見ていきましょう。
4つの柱
SAOは4つの原則に基づいています。
1. ゴールの定義：Why / What / Success State
SAOでは、単に「何をするか（What）」だけでなく、「なぜやるのか（Why）」「成功したら何ができるのか（Success State）」を明確に定義します。
┌─────────────────────────────────────────────────────────────┐
│ Why（なぜやるのか） │
│ → 現状の課題、痛み、動機 │
├─────────────────────────────────────────────────────────────┤
│ What（何を実現するか） │
│ → 具体的な機能、成果物 │
├─────────────────────────────────────────────────────────────┤
│ Success State（成功したら何ができるのか） │
│ → 完成後の世界、ユーザーができるようになること │
└─────────────────────────────────────────────────────────────┘
なぜこれが重要か？
AIエージェントは実装中に無数の判断を迫られます。「この機能は必要か？」「このエッジケースは対応すべきか？」
「What」だけでは判断できません。「Why」と「Success State」があれば、エージェントは自律的に判断できます。
# design.md の例
## Why（背景・動機）
現状、ToDoの完了/未完了は自分しかわからない。
チームで共有したいが、毎回スクショを撮ってSlackに貼るのは面倒。
## What（実現すること）
ToDoリストの共有機能を実装する。
## Success State（成功後の世界）
- チームメンバーが、リンク1つで他人のToDoリストを閲覧できる
- 「今日何やったの？」と聞かなくても進捗がわかる
この定義があれば、実装中に「通知機能も付けるべき？」と迷ったとき、「Success Stateの達成に必要か？」で判断できます。答えは「No、閲覧できれば十分」です。
このゴール定義は、プロジェクト全体と各Phaseの2階層で行います（詳しくは後述の「ゴールの階層構造」で説明）。
2. 構造化ドキュメント
{project}/
├── README.md # 入口・全体進捗
├── design.md # ビジョン・設計思想
├── phase1/
│ ├── README.md # Phase進捗・チェックリスト
│ └── implementation-plan.md # 詳細実装計画
├── phase2/
│ └── ...
└── phase3/
└── ...
ドキュメントの構造自体が、プロジェクトの構造を反映します。READMEを開けば現在地がわかり、design.mdを読めば目指す方向がわかります。
3. 明示的な状態管理
Phase/Step の状態遷移:
未着手 ───→ 進行中 ───→ 完了
│
↓
ブロック中
「なんとなく終わった」は許されません。すべてのPhase、すべてのStepに明示的なステータスがつきます。チェックリストの✅が、客観的な進捗を示します。
4. 標準化された引き継ぎ
セッション開始時（引き継ぎを受ける側）:
- プロジェクトREADME を読む → 全体像を把握
- design.md を読む → ビジョンと設計思想を理解
- 現在のPhase README を読む → 詳細な進捗を把握
- implementation-plan.md を読む → 具体的な実装方法を確認
- 作業開始
セッション終了時（引き継ぎをする側）:
- チェックリストを更新
- ステータスを更新
- 更新履歴に追記
- 未完了タスクを明記
- コミット・プッシュ
これにより、「次のエージェントに何を伝えればいいか」を考える必要がなくなります。プロトコルに従えばよいのです。
プロジェクト構造：Project → Phase → Step
SAOは階層構造でプロジェクトを管理します。
Project（プロジェクト全体）
│
├── Phase 1（大きな作業単位）
│ ├── Step 1（具体的タスク）
│ ├── Step 2
│ └── Step 3
│
├── Phase 2
│ └── ...
│
└── Phase N
Project: 達成したい最終目標です。「認証システムの実装」などが該当します。
Phase: 意味のある中間マイルストーンです。Phase単位で「完了」と言える状態になります。
Step: 具体的なタスクです。1セッションで完了できる粒度に設定します。
Phase設計の5要素
各Phaseは、以下の5つの要素で定義されます。
┌─────────────────────────────────────────────────────────────┐
│ Phase N: {Phase名} │
├─────────────────────────────────────────────────────────────┤
│ 1. Purpose（目的） │
│ → このPhaseで何を達成するか │
│ │
│ 2. Why It's Needed（なぜ必要か） │
│ → なぜこのPhaseが先に必要か、前のPhaseとの関係 │
│ │
│ 3. Goals（ゴール） │
│ → このPhaseで実現する機能的要件 │
│ → 「〜できるようになる」という形式 │
│ │
│ 4. Success Criteria（成功基準） │
│ → 客観的に検証可能な完了条件 │
│ │
│ 5. Dependencies（依存関係） │
│ → 先に完了している必要があるPhase │
└─────────────────────────────────────────────────────────────┘
Goals：機能的要件を列挙する
SAOのGoals定義の特徴は、「このPhaseで実現する機能的要件」を明確に列挙することです。
# Phase 1: 認証基盤 の Goals
- ユーザーがメールアドレスでサインアップできる
- ユーザーがログイン/ログアウトできる
- セッションがページリロード後も維持される
- 未認証ユーザーが保護されたページにアクセスできない
なぜ機能的要件で書くのか？
- 検証が明確: 「できる/できない」で完了を判断できる
- スコープが明確: 何を作るかが具体的にわかる
- 次のPhaseへの橋渡し: Phase 1で実現した機能がPhase 2の前提になる
Phase 1のGoalsが達成されていないと、Phase 2の実装は困難です。この連鎖が、依存関係に「理由」を与えます。
具体例：認証システムのPhase設計
### Phase 1: 認証基盤
#### Purpose
認証に必要なDB、API、設定を構築する
#### Why It's Needed
Google認証もメール認証も、この基盤の上に構築される
#### Goals
- ユーザーがメールアドレスでサインアップできる
- ユーザーがログイン/ログアウトできる
- セッションがページリロード後も維持される
#### Success Criteria
1. usersテーブルにテストユーザーを作成できる
2. /api/auth/session が正常にレスポンスを返す
3. 認証ミドルウェアが未認証リクエストを401で拒否する
#### Dependencies
- None
ゴールの階層構造
「4つの柱」で説明したWhy / What / Success Stateは、プロジェクト全体のゴールです。SAOでは、これに加えて各Phaseにもゴールを定義します。
┌─────────────────────────────────────────────────────────────┐
│ プロジェクト全体のゴール（design.md） │
│ │
│ Why: なぜこのプロジェクトが必要か │
│ What: 何を実現するか │
│ Success State: 完了後に何ができるようになるか │
│ │
│ → 「北極星」。迷ったときに立ち返る場所 │
├─────────────────────────────────────────────────────────────┤
│ Phase 1 のゴール │ Phase 2 のゴール │
│ │ │
│ Purpose: このPhaseで何を達成するか │ Purpose: ... │
│ Why It's Needed: なぜ先に必要か │ Why It's Needed: ... │
│ Goals: 実現する機能的要件 │ Goals: ... │
│ Success Criteria: 完了条件 │ Success Criteria: ... │
└─────────────────────────────────────────────────────────────┘
プロジェクト全体のSuccess Stateに到達するために、各PhaseのGoalsを達成していく。この階層構造が、大規模プロジェクトを「分割統治」する仕組みです。
よくある設計書・計画書との違い
SAOは「AIエージェント向けの設計書」です。従来の設計書・計画書とは、いくつかの点で異なります。
1. 計画は「提案」であり「命令」ではない
従来の計画書:
計画 → 承認 → 実行（計画通りに）
変更が必要 → 変更申請 → 再承認 → 実行
SAOの計画書:
計画 → 実行開始 → 現実との差異を発見 → 自律的に判断・修正 → 特記して記録
SAOでは、implementation-plan は「完璧な計画書」ではなく「提案」として扱います。
エージェントは以下の姿勢で作業に臨みます：
- 計画を疑う: 計画が現実と乖離している可能性を常に意識する
- 不足を補う: 計画に不足があれば、後続ステップの内容を先に確認する
- 自律的に判断: 後続ステップでも補われない場合は、自分で判断し追加実装する
- 特記する: 計画外の追加実装は、Phase READMEの進捗に必ず特記する
## 更新履歴（特記事項の例）
| 日付 | 更新者 | 内容 |
|-----|-------|------|
| 2026-01-13 | Agent | Step 2 完了。計画にないエラーハンドリングを追加実装（理由: API仕様変更のため） |
2. 「読み手」がAIエージェントである
従来の設計書:
- 人間が読んで「理解」することを前提
- 行間を読む、暗黙の了解がある
- 図やダイアグラムで視覚的に伝える
SAOの設計書:
- AIエージェントが「即座に状態を把握」できることを前提
- すべてが明示的、曖昧さを排除
- テキストベースで構造化（マークダウン）
# 従来の設計書でありがちな記述
「認証機能を実装する。詳細は別途相談。」
# SAOでの記述
### Phase 1: 認証基盤
| 進捗 | `進行中` 🔄 |
#### Goals
- ユーザーがメールアドレスでサインアップできる
- ユーザーがログイン/ログアウトできる
- セッションがページリロード後も維持される
#### Success Criteria
1. サインアップ後、ログインできることを確認
2. ログアウト後、保護ページにアクセスできないことを確認
3. 「状態」が一級市民
従来のプロジェクト管理:
- 進捗は会議で口頭報告
- ステータスはExcelやJiraで別管理
- 設計書と進捗管理が分離
SAO:
- 進捗はドキュメント自体に埋め込まれる
- ステータスは設計書の一部
- 設計書を読めば進捗もわかる
ドキュメントを開いた瞬間に「今どこにいるか」がわかります。
4. 「引き継ぎ」が前提
従来の設計書:
- 書いた人が実装することが多い
- 引き継ぎは例外的なイベント
- 引き継ぎ時に「引き継ぎ資料」を別途作成
SAO:
- 毎セッション引き継ぎが発生する前提
- 引き継ぎプロトコルが標準化
- ドキュメント自体が引き継ぎ資料
AIエージェントは毎回「記憶喪失」します。だからこそ、すべてのセッションが「引き継ぎ」であり、ドキュメントは常に「次のエージェントが読む」前提で書かれます。
比較表
| 観点 | 従来の設計書 | SAOの設計書 |
|---|---|---|
| 読み手 | 人間 | AIエージェント |
| 計画の扱い | 命令（従う） | 提案（批判的に評価） |
| 状態管理 | 別システム | ドキュメントに埋め込み |
| 引き継ぎ | 例外イベント | 毎セッション発生 |
| 曖昧さ | 許容（行間を読む） | 排除（すべて明示） |
| ゴール定義 | What中心 | Why + What + Success State |
SAOを使うべき場面
使うべき場合
- 1セッションで完了しない規模 — 複数日・複数週間にわたるプロジェクト
- 3つ以上のフェーズがある — 段階的な実装が必要
- 複数のエージェント/人が関わる — 引き継ぎが発生する
- 1週間以上かかる — 記憶の永続化が必要
使わなくてよい場合
- 1セッションで完了する
- 単純なバグ修正
- 独立した小タスク
オーバーヘッドを考慮してください。 SAOはドキュメント作成のコストがかかります。小さなタスクには向きません。
メリットとデメリット
メリット
| メリット | 説明 |
|---|---|
| 継続性 | セッションが切れても、作業を継続できる。これが最大のメリット |
| 透明性 | 進捗が可視化される。「今どこにいるのか」が一目でわかる |
| 再現性 | 別のエージェントでも、同じプロトコルに従えば作業を引き継げる |
| 品質保証 | 各Stepに完了条件が定義されているため、「なんとなく終わった」がない |
デメリット
| デメリット | 説明 |
|---|---|
| オーバーヘッド | ドキュメント作成・更新のコストがかかる。小さなタスクには向かない |
| 初期学習コスト | SAOの方法論を理解し、テンプレートの使い方を覚える必要がある |
| 硬直性のリスク | 計画に固執しすぎると、柔軟性が失われる。批判的アプローチが必要 |
今すぐ試してみる
SAOはnpxコマンド一つで、あなたのプロジェクトに導入できます。
クイックスタート（Claude Code向け）
# プロジェクトのルートディレクトリで実行
npx init-sao-claude
これだけで、以下がセットアップされます：
.claude/
├── sao/
│ └── concepts/
│ ├── README.md # SAO方法論の解説
│ └── templates/ # プロジェクトテンプレート
│ ├── project-readme.md
│ ├── design.md
│ ├── phase-readme.md
│ └── implementation-plan.md
└── commands/
├── sao-starter.md # /sao-starter コマンド
└── sao-step.md # /sao-step コマンド
使い方
セットアップ後、Claude Codeで以下のコマンドが使えるようになります：
/sao-starter my-feature
→ 新しいSAOプロジェクト「my-feature」を作成。Claudeが要件をヒアリングし、Phase構成を提案してくれます。
/sao-step my-feature
→ プロジェクト「my-feature」の次のStepを実行。完了したら自動でステータスを更新します。
実際の流れ
User: /sao-starter auth-system
Claude: 認証システムについて教えてください。
1. 何を実現したいですか？
2. 対象ユーザーは？
3. 必須機能は？
...（ヒアリング）
Claude: 以下のPhase構成で進めます：
- Phase 1: 認証基盤（DB、基本API）
- Phase 2: ログイン/サインアップUI
- Phase 3: パスワードリセット
- Phase 4: セッション管理強化
よろしいですか？
User: OK
Claude: プロジェクトを作成しました。
.claude/sao/projects/active/auth-system/
/sao-step auth-system で実装を開始できます。
User: /sao-step auth-system
Claude: Phase 1 Step 1から開始します。
...（実装）
Step 1完了。ステータスを更新しました。
次は /sao-step auth-system でStep 2を実行できます。
次のセッションでも：
User: /sao-step auth-system
Claude: README.mdを確認... Phase 1 Step 2から再開します。
...（説明なしで即座に続きから作業）
まとめ
SAO（Stateful Agent Orchestration）は、AIエージェントの記憶制限という根本的な問題に対する、実践的な解決策です。
4つの柱:
- ゴールの定義（Why / What / Success State）
- 構造化ドキュメント
- 明示的な状態管理
- 標準化された引き継ぎ
使いどころ:
- 大規模プロジェクト
- 複数セッション/複数エージェントが関わる作業
- 継続的な開発
今すぐ始める:
npx init-sao-claude
AIエージェントは優秀です。しかし、その能力を大規模プロジェクトで発揮するには、「記憶の壁」を超える仕組みが必要になります。
SAOは、その壁を超えるための一つの答えです。