name: deploy-production
description: アプリケーションを検証し、本番環境にデプロイします。

プロンプトを超えて：Anthropicのエージェント記憶、夢、グラフワークフローへのアプローチ

1. checklist.md を読んでください。
2. 完全なテストスイートを実行してください。
3. 移行計画を確認してください。
4. scripts/verify-release.sh を実行してください。
5. 停止して、デプロイ前に人間の承認を求めてください。

重要な仕組みは**段階的開示（プログレッシブ・ディスクロージャー）**です。

Claude はスキルが関連するかどうかを判断するのに役立つ短い説明を見ます。完全なスキル本文とサポートファイルは、そのプロセスが必要な場合にのみ読み込まれます。

Mukta 氏はこれを本棚に例えています。

人は会話を始める前にすべての本を覚えておく必要はありません。関連情報が含まれているかもしれない本がどれかを知っていて、適切なタイミングでそれを取り出せばよいのです。

スキルは「増え続けるコンテキストファイル」問題の解決に役立ちます：

- 安定した高レベルの事実は `CLAUDE.md` に残せます。
- 詳細なプロセスはスキルに移せます。
- サポート資料は必要な時までアクティブなコンテキストの外に置いておけます。

Anthropic 公式のスキルドキュメントによると、チームが同じ指示・チェックリスト・複数ステップのプロセスを繰り返し会話に貼り付けている場合、または `CLAUDE.md` の一部が簡潔な事実ではなくプロセスに発展している場合に、スキルを作成することが推奨されています。

### スキルには依然として人間の管理が必要

スキルは再利用可能ですが、それでも誰かが以下を決定する必要があります：

- どのワークフローにスキルを作る価値があるか
- プロセスをどのように構築するか
- どのファイルを含めるか
- スキルがいつ時代遅れになるか
- 誰に編集権限があるか

エージェントはスキルの作成と維持を支援できますが、このシステムは依然として部分的に人間の管理に依存しています。

これが4つ目のアプローチにつながります。

## 第4世代：ファイルシステムを記憶として扱う

Mukta 氏は、ファイルシステムベースの記憶を、Anthropic が現在多くのエージェント記憶システムで好んでいるパターンであると説明しています。

その理由は非常に実用的です。

エージェントはすでに以下のことが得意です：

- ファイルの一覧表示
- ファイル名の検索
- `grep` の実行
- Markdown の読み取り
- ディレクトリの閲覧
- テキストの編集
- バージョンの比較

高度に特化した記憶インターフェースを発明する代わりに、チームは記憶をファイルとして整理し、エージェントに通常のファイルシステムツールを提供することができます。

可能なレイアウトの一つは次のとおりです：

```Plaintext
memory/
├── organization/
│   ├── principles.md
│   ├── terminology.md
│   └── security-policy.md
├── teams/
│   ├── engineering/
│   │   ├── architecture.md
│   │   └── release-process.md
│   └── support/
│       ├── escalation-rules.md
│       └── response-style.md
├── projects/
│   └── billing-redesign/
│       ├── decisions.md
│       ├── known-issues.md
│       └── current-status.md
└── agents/
    └── agent-104/
        └── scratchpad.md

このレイアウトは、異なるレベルの記憶をサポートします：

• 組織レベルのルール
• チームの知識
• プロジェクトのコンテキスト
• ユーザー設定
• 特定エージェントの作業メモ

これも段階的開示を体現しています。

エージェントはディレクトリを検索し、現在のタスクに関連するファイルのみを読み込むことができます。

ファイルはインターフェースであり、物理ストレージとは限らない

ファイルシステムスタイルのインターフェースは、すべての企業記憶が管理されていないファイルとしてノートパソコン上に存在することを要求するものではありません。

基盤となる実装は依然として以下を使用できます：

• データベース
• バージョン管理されたオブジェクトストレージ
• アクセス制御サービス
• 検索インデックス
• 監査ログ
• トランザクションAPI

重要な点は、エージェントがシンプルでナビゲート可能な抽象化を得られることです。

質疑応答セッションで、ある聴衆がこれはデータベースの再発明と同じかどうか尋ねました。

Mukta 氏は、このアーキテクチャが馴染みのあるソフトウェアエンジニアリングの原則に回帰していることを認めました。チームはどの動作が決定的であるべきかを理解すれば、モデルが毎回即興で行うのではなく、それらの動作を制御フレームワークに移行できます。

本番グレードの記憶のための4つのガードレール

Markdown ファイルでいっぱいのフォルダは、単一ユーザーには有効かもしれません。

しかし、何千ものエージェントが共有の組織記憶を更新できるようになると、危険になります。

Mukta 氏は4つの本番原則を強調しました：

1. バージョン管理
2. 並行性制御
3. 権限管理
4. 可搬性

1. すべての記憶変更にバージョンを確立する

すべての記憶更新には履歴が必要です。

有用なメタデータには以下が含まれます：

• 以前のバージョン
• 新しいバージョン
• タイムスタンプ
• 人間またはエージェントの作成者
• 元のセッション
• サポートする会話記録
• 変更理由
• 承認ステータス

出所の追跡がない記憶エントリは、信頼を得るのが困難です。

エージェントが次のように追加したと仮定します：

- 金曜日の本番デプロイは承認不要です。

出所・レビュアー・改訂履歴がなければ、別のエージェントがこの記述を権威あるものと見なす可能性があります。

バージョン管理は以下をサポートします：

• レビュー
• ロールバック
• 監査
• 比較
• 根本原因分析

バージョン管理された記憶システムは、次の質問に簡単に答えられるべきです：

このルールの出現につながったのはどのインタラクションですか？

2. 並行エージェントが互いに上書きするのを防ぐ

2つのエージェントが10:00に同じ記憶を読み取ったとします。

エージェントAは10:02に更新を書き込みました。

エージェントBはこの変更を知らず、10:03に自分のバージョンを書き込み、誤ってエージェントAの更新を削除しました。

Mukta 氏はハッシュベースの並行性パターンを説明しました：

エージェントは記憶を読み取り、ハッシュAを記録する
        ↓
エージェントは更新を起草する
        ↓
エージェントは再度記憶を読み取り、ハッシュBを記録する
        ↓
ハッシュA == ハッシュB の場合：
    更新をコミットする
そうでない場合：
    再読み込み、リベース、再試行する

これが楽観的並行性制御です。

モデルはどのような変更を提案するかを決定できますが、制御フレームワークは古い書き込みが新しいバージョンを置き換えるのを決定的に防ぐべきです。

3. 読み取りと書き込みの権限を区別する

すべてのエージェントがすべての記憶を編集できるべきではありません。

合理的な権限モデルの例は次のとおりです：

記憶の範囲	典型的なアクセス方法
組織原則	ほとんどのエージェントは読み取り専用。審査プロセスを通じてのみ書き込み
セキュリティポリシー	関連エージェントは読み取り専用。制限された人間による制御書き込み
チームプロセス	チームは読み取り専用。指定されたメンテナーが書き込み
プロジェクト決定	プロジェクトエージェントは読み取り専用。提案された編集は承認が必要
エージェント下書き領域	単一エージェントが読み書き
ユーザー設定	ユーザー範囲のエージェントがアクセス
機密の顧客コンテキスト	厳格なロールベースのアクセス

エージェントは不確かな観察を組織全体のルールに変えるべきではありません。

権限の境界は Dreaming にも適用されるべきです。統合タスクは、そのアイデンティティがアクセスを許可された会話記録と記憶のみを受け取ることができます。

4. 記憶を可搬性にする

記憶は組織の最も価値あるAI資産の一つになる可能性があります。

それには以下が含まれます：

• 決定
• 修正
• ワークフロー
• 設定
• 失敗パターン
• ツール知識
• ドメイン固有の指示

Mukta 氏は、チームがこの資産を単一製品内でのみ動作するように設計することを避けるべきだと考えています。

可搬性のある記憶システムは以下を持つべきです：

• 明確なAPI
• エクスポート可能な形式
• 文書化されたスキーマ
• 安定した識別子
• 標準的なアクセス制御
• ツールに依存しない出所追跡

可搬性により、同じ丁寧に整理されたコンテキストが以下をサポートできます：

• Claude Code
• Claude マネージドエージェント
• 内部ツール
• 他のエージェントシステム
• 人間向けドキュメントワークフロー

なぜセッション内記憶では不十分か

うまく設計された記憶ツールでも、2つの構造的な限界があります。

限界1：エージェントは気が散りやすい

エージェントはタスクを完了しながら記憶を整理しなければなりません。

記憶への書き込みは、現在の目標に使用できるリソースを消費します。

エージェントは以下の可能性があります：

• 過剰に保存する
• 過少に保存する
• 未検証の結論を保存する
• 時間的プレッシャーの下で記憶作業をスキップする
• より大きなパターンではなく局所的な詳細だけに焦点を当てる

制限2：エージェントは1つのセッションしか見えない

あるエージェントが、特定のコマンドが一度失敗したことに気づくかもしれません。

しかし、同じコマンドが他の300のセッションでも失敗していることを、そのエージェントは見ることができません。

サポートエージェントが、ある顧客が特定のポリシーに困惑しているのを見るかもしれません。

しかし、同じ困惑が地域全体で繰り返し発生していることを見ることはできません。

システム全体をカバーする学習メカニズムには、より広い可視性を持つプロセスが必要です。

このプロセスこそ、Anthropicが**「ドリーミング」**（Dreaming）と呼ぶものです。

ドリーミング：記憶を整理するための帯域外プロセス

ドリーミングは、通常の作業が完了した後にエージェントの履歴をレビューする非同期プロセスです。

Anthropicの現在のAPIリリースノートでは、Claudeホスト型エージェントの「ドリーミング」機能は研究プレビューとして説明されています。

一度の「ドリーム」は以下を読み取ります：

• 既存の記憶ストレージ
• 過去のセッション記録

その後、再編成された出力用記憶ストレージを作成し、そこで以下のことが可能です：

• 重複エントリの統合
• 古い情報の置き換え
• 見落とされていた洞察の浮上
• コンテンツの再編成
• 改善された記憶の提案

これはモデルの再トレーニングではありません。

基盤となるモデルの重みは変更されません。

改善は、永続化されたコンテキストを変更し、将来のセッションがこれらのコンテンツを検索できるようにすることから生まれます。

学校のアナロジー

Muktaは、通常の記憶と「ドリーミング」の違いを説明するために学校を使いました。

想像してみてください：

• 生徒が宿題を完了します。
• 教師が各宿題を採点します。
• 教務主任が学校全体の総合結果を精査します。

教師は1人の生徒が間違いを訂正するのを助けることができます。

教務主任は、地理の生徒全員が同じ知識ポイントで間違いを犯していることに気づくことができます。それは、カリキュラムの概要にその内容がまったく含まれていないからです。

システムレベルの修正は、各試験用紙を個別に採点することではありません。

カリキュラムの概要を更新することです。

エージェント用語：

• 生徒の宿題 = 個別セッション
• 教師のフィードバック = セッション内の記憶更新
• 学校のカリキュラム = 共有記憶ストレージ
• 校長のレビュー = ドリーミング処理
• カリキュラム更新 = 提案された記憶変更

これにより、システムは単一のエージェントでは気づくことができないパターンから学習できるようになります。

ドリーミング処理のメカニズム

簡略化されたドリーミング処理パイプラインは次のようになります：

フローチャート TD
    A[既存の記憶ストレージ] --> D[ドリームオーケストレーター]
    B[セッション記録] --> D
    C[ツール呼び出しとメタデータ] --> D
    D --> E1[レビューエージェント 1]
    D --> E2[レビューエージェント 2]
    D --> E3[レビューエージェント 3]
    E1 --> F[パターン集約器]
    E2 --> F
    E3 --> F
    F --> G[提案された記憶変更]
    G --> H{人間による承認}
    H -->|承認| I[更新された記憶ストレージ]
    H -->|拒否| J[既存の記憶を保持]

レビュープロセスは、ユーザーとアシスタントのメッセージだけでなく、より多くのものを検査できます。

有用な証拠には以下が含まれます：

• ツール呼び出し
• ツールの失敗
• 再試行回数
• 実行メタデータ
• 人間による修正
• 評価スコア
• 受け入れられた出力と拒否された出力
• スキルの使用状況
• モデルバージョン
• レイテンシーとコスト

ドリームエージェントはその後、次のようなパターンを探します：

• 同じコマンドが繰り返し失敗している。
• 複数のエージェントが特定の内部用語を誤解している。
• 特定の記憶エントリがもはや有効でない。
• 2つのファイルに重複したルールが含まれている。
• チームが同じフォーマットの問題を繰り返し修正している。
• 特定のツール設定が複数のプロジェクトでエラーを引き起こしている。
• 特定のポリシーが欠落しており、エージェントが推測を余儀なくされている。

Mukta氏は、Anthropicの設計には関連するセッション記録の例と、パターンの発生頻度を示す統計データを含めることができると述べました。

これらの証拠は、人間が提案された記憶変更が妥当かどうかを判断するのに役立ちます。

ドリーミング処理は提案を行うべきであり、黙ってすべてを書き換えるべきではない

ドリーミング処理は広範なアクセス権を持ち、エージェントクラスター全体の将来の動作に影響を与える可能性があります。

これにより、自動かつ無審査の更新はリスクを伴います。

より安全なワークフローは次のとおりです：

1. 承認されたセッション記録を分析します。
2. 繰り返し発生するパターンを特定します。
3. パターンを裏付けるセッションに関連付けます。
4. 提案された記憶変更を起草します。
5. 問題の発生頻度を推定します。
6. 人間またはポリシー制御のレビュー担当者による承認を要求します。
7. 出典記録付きの承認された更新を提出します。
8. 将来のパフォーマンスが向上したかどうかを測定します。

例えば：

## 提案された記憶更新

**対象：** `teams/engineering/test-process.md`

**観察された問題：**  
エージェントが63の関連セッションのうち18のセッションで、単体テストコマンドを使用して統合テストを実行しました。

**証拠：**  
セッション `s-102`、`s-111`、`s-118`、`s-124`、……

**提案された追加内容：**  
- データベースコンテナを必要とするすべてのテストに `npm run test:integration` を使用します。
- `tests/integration/` 配下のファイルには `npm test` を使用しないでください。

**信頼度：** 高

**人間の判断：** 保留中

これにより人間による監督が維持され、エージェントクラスターが分析作業の大部分を実行できるようになります。

なぜドリーミング処理はより多くのトークンを使用するのにコストを削減できるのか

ドリーミング処理には追加のモデル呼び出しが必要です。

一見すると、これは不要なオーバーヘッドのように思えます。

Mukta氏は、よりクリーンな記憶ストレージは総コストを削減できると述べています。なぜなら、将来のエージェントが最初の試行で正しくタスクを完了する可能性が高くなるからです。

最初の試行。

有用な経済的比較は次のとおりです：

ドリーミングのコスト
対比
繰り返される失敗、再試行、手戻り、過度に長いコンテキストのコスト

潜在的な節約は以下から得られます：

• 再試行の減少
• 繰り返しの説明の減少
• 無関係なコンテキストの減少
• より良いツール選択
• 最初の試行での正確さの向上
• 新しいエージェントの立ち上げがより迅速に
• 人間による繰り返しの修正の減少

Anthropicはまだ、各組織がどれだけ節約できるかを示す一般的なベンチマークを公開していません。具体的な価値は以下に依存します：

• タスクの反復度
• 記憶の質
• エラーのコスト
• セッション数
• レビュー設計
• モデルとツールの価格設定

多数のエージェントが関連する作業を実行し、同じパターンに繰り返し遭遇する場合、「ドリーミング」は最も報われる可能性が高くなります。

ホスト型エージェントなしのシンプルな毎週のドリーミングプロセス

チームは完全なプラットフォーム統合を待たずに、このコンセプトをテストできます。

手動バージョンは毎週実行できます。

ステップ1：関連セッションをエクスポートする

レビュー担当者が閲覧権限を持つ会話記録のみを収集します。

以下のように整理します：

• プロジェクト
• チーム
• ワークフロー
• 権限範囲
• 期間

ステップ2：現在の記憶を提供する

以下を含めます：

• CLAUDE.md
• 関連スキル
• プロジェクト記憶ファイル
• チーム説明
• 既知の問題ドキュメント

ステップ3：証拠に裏付けられた提案を要求する

プロンプトは次のように書くことができます：

これらの承認されたセッション記録と現在の記憶ファイルをレビューしてください。

繰り返し発生する失敗、ユーザーによる繰り返しの修正、古い指示、
欠落したプロセス、重複したエントリを特定してください。

各提案された変更について：
1. 対象ファイルを指定してください。
2. 裏付けとなるセッションIDを提示してください。
3.

このパターンが出現する頻度を説明する。
4. 最小限の効果的な修正を起草する。
5. ファイルを直接編集しない。

ステップ4：提案の審査

以下の修正は却下する：

• 単一の曖昧な出来事に基づくもの
• 証拠の裏付けが不足しているもの
• 範囲が広すぎるもの
• セキュリティ上重要に関わるもの
• レビュー担当者の権限範囲を超えるもの
• 決定的なコードとして実装する方が適切なもの

ステップ5：承認された修正を提出する

バージョン管理を使用し、コミットまたは監査記録にソース証拠を含める。

ステップ6：結果を測定する

同じ失敗が後続のセッションで減少するかを追跡する。

測定がなければ、「夢を見る」ことは学習システムではなく、ドキュメント生成作業になる。

時間とともに蓄積される記憶からタスク内の構造へ

記憶が答えるのは：

エージェントは以前の作業から何を覚えておくべきか？

グラフ構造エンジニアリングが答えるのは、別の質問である：

現在のタスクのどの部分が実際に相互に依存しているのか？

BAAIの元記事は、記憶の話題を、AI開発コミュニティで流通しているグラフ構造エンジニアリングのガイドラインに結び付けている。

そのガイドラインの中心的な主張は、多くの「ワークフロー」は本質的にすでにグラフである——ただ設計が悪いだけだ、というものだ。

リスト形式で書かれたワークフローは、人為的に直列プロセスに変換されることが多い：

調査
    ↓
要約
    ↓
比較
    ↓
ファクトチェック
    ↓
執筆

これらのステップの一部は、確かに前の出力に依存しているかもしれない。

他のステップは、意味もなく待っているだけかもしれない。

ノード、エッジと実際のデータフロー

ワークフローグラフでは：

• ノードはタスクを表す。
• エッジは実際の依存関係を表す。
• データはエッジに沿って流れる。

例：

調査ノードは調査結果を産出する。

執筆ノードはこれらの調査結果を消費し、草稿を産出する。

検証ノードは草稿を消費し、チェック済みの結果を産出する。

これらの矢印は妥当である。なぜなら、各下流ノードは上流ノードの出力を必要とするからである。

疑似エッジテスト

コミュニティのグラフガイドラインは、各矢印に対して単純なテストを提案している：

次のタスクは本当に前のタスクの出力を必要とするか？

答えがノーであれば、その依存関係は疑似依存である。

次のワークフローを考えてみよう：

競合他社Aの調査
    ↓
競合他社Bの調査
    ↓
競合他社Cの調査
    ↓
比較レポートの作成

競合他社Bの調査は、通常、競合他社Aの調査の出力を必要としない。

競合他社Cの調査は、通常、競合他社Bの調査の出力を必要としない。

これらのタスクは並行して実行できる：

flowchart TD
    A[比較基準の定義] --> B1[競合他社Aの調査]
    A --> B2[競合他社Bの調査]
    A --> B3[競合他社Cの調査]
    B1 --> C[比較レポートの作成]
    B2 --> C
    B3 --> C

疑似エッジを削除することで待ち時間を減らすことができる。

3つの調査タスクがそれぞれ10分、12分、15分かかる場合：

• 順次実行では約37分かかる。
• 並行実行では、オーケストレーションのオーバーヘッドに加えて約15分の待ち時間で済む。

グラフは、個々のエージェントを速くするわけではない。

変更するのはスケジューリングの方法である。

ダイヤモンドパターン

疑似エッジを削除すると、一般的な形状が現れる：

1. 1つのタスクが複数の独立したブランチに分割される。
2. これらのブランチは並行して実行される。
3. 結果が集約される。
4. 最終ノードが結果を総合する。

これは通常、ダイヤモンドと呼ばれる。

調査の例は次のようになるだろう：

flowchart TD
    A[調査質問] --> B1[市場データ]
    A --> B2[顧客エビデンス]
    A --> B3[競合分析]
    B1 --> C[チェッカー]
    B2 --> C
    B3 --> C
    C --> D[最終総合]

総所要時間は、主に最も遅いブランチによって決まり、すべてのブランチの所要時間の合計ではない。

並行作業にはチェッカーが必要

並行処理は新たなリスクを導入する。

1つのワーカースレッドが、薄弱、陳腐化、または裏付けのない出力を生み出す可能性がある。

システムが検証なしにすべてを統合すると、1つの悪いブランチが最終回答を汚染する可能性がある。

そのため、グラフガイドラインは総合の前にチェッカーを配置する。

チェッカーは次のように問いかけることができる：

• この主張には裏付けがあるか？
• ソースは最新か？

出力は要求された形式に適合していますか？

• ワーカースレッドは割り当てられたタスクを完了しましたか？
• コードはテストに合格しましたか？
• 結果は他のブランチと競合していますか？
• 機密データは存在しますか？
• この出力は安全に続行できますか？

有用なチェッカーには明確な受け入れ基準が必要です。

例：