multi-agent-patterns

Claude Code のマルチエージェントアーキテクチャパターン

マルチエージェントアーキテクチャでは、作業を複数のエージェント呼び出しに分散し、それぞれが焦点を絞った独自のコンテキストを持ちます。適切に設計すれば、この分散によって単一エージェントの限界を超える機能を実現できます。設計が不適切だと、調整のオーバーヘッドがメリットを損ないます。重要な洞察は、サブエージェントの主な目的は、役割分担を人間のように見せることではなく、コンテキストを分離することだという点です。

基本概念

マルチエージェントシステムは、作業を分散することで単一エージェントのコンテキスト上の制約に対処します。主なパターンは、中央制御を行うスーパーバイザー／オーケストレーター、柔軟に引き継ぐピアツーピア／スウォーム、階層化された抽象化を行う階層型の3つです。重要な設計原則はコンテキストの分離です。サブエージェントの主な目的は、組織上の役割を再現することではなく、コンテキストを分割することです。

効果的なマルチエージェントシステムには、明示的な調整プロトコル、迎合を避ける合意形成の仕組みが必要です。また、ボトルネック、意見の乖離、エラーの伝播などの障害モードにも注意を払う必要があります。

マルチエージェントアーキテクチャを採用する理由

コンテキストのボトルネック

単一エージェントには、推論能力、コンテキスト管理、ツール連携に本質的な限界があります。タスクが複雑になるにつれ、コンテキストウィンドウは蓄積された履歴、取得したドキュメント、ツールの出力で埋まっていきます。パフォーマンスは、中間情報の見落とし、注意力の不足、コンテキストの汚染といった予測可能なパターンに従って低下します。

マルチエージェントアーキテクチャは、作業を複数のコンテキストウィンドウに分割して、こうした制約に対処します。各エージェントは、サブタスクに焦点を絞ったクリーンなコンテキストで動作します。結果は調整レイヤーで集約され、単一のコンテキストが全体の負担を背負うことはありません。

並列化の利点

多くのタスクには並列化可能なサブタスクが含まれていますが、単一エージェントではそれらを逐次的に実行する必要があります。調査タスクでは、独立した複数の情報源を検索したり、異なるドキュメントを分析したり、競合するアプローチを比較したりする必要がある場合があります。単一エージェントはこれらを順番に処理し、手順を進めるごとにコンテキストを蓄積します。

マルチエージェントアーキテクチャでは、各サブタスクを新しいコンテキストを持つ専用エージェントに割り当てます。すべてのエージェントが同時に作業し、その後、結果をコーディネーターに返します。実際の所要時間は、すべてのサブタスクの合計ではなく、最も時間のかかるサブタスクの所要時間に近づきます。

専門化の利点

タスクによって、異なるエージェント構成が適しています。システムプロンプト、ツールセット、コンテキスト構造がそれぞれ異なる場合があります。汎用エージェントは、あらゆる構成をコンテキストに保持しなければなりません。特化型エージェントは、必要なものだけを保持します。

マルチエージェントアーキテクチャを使うと、組み合わせの爆発を招くことなく専門化を実現できます。コーディネーターが特化型エージェントに処理を振り分け、各エージェントはそれぞれの領域に最適化された無駄のないコンテキストで動作します。

アーキテクチャパターン

パターン 1：スーパーバイザー／オーケストレーター

スーパーバイザーパターンでは、中央のエージェントが制御を担い、専門エージェントに作業を委任して結果を統合します。スーパーバイザーはグローバルな状態と実行経路を維持し、ユーザーの目的をサブタスクに分解して、適切なワーカーに割り当てます。

User Request -> Supervisor -> [Specialist A, Specialist B, Specialist C] -> Aggregation -> Final Output

使用する場面： 明確に分解できる複雑なタスク、複数の領域にまたがる調整が必要なタスク、人間による監督が重要なタスクです。

メリット： ワークフローを厳密に制御でき、人間が介入する仕組みを実装しやすく、事前に定義した計画への準拠を確保できます。

デメリット： スーパーバイザーのコンテキストがボトルネックになり、スーパーバイザーの障害がすべてのワーカーに波及し、スーパーバイザーがサブエージェントの応答を誤って言い換える「伝言ゲーム」の問題が発生します。

Claude Code での実装： Task ツールを使用して、専門のサブエージェントを呼び出すメインコマンドを作成します。スーパーバイザーコマンドに調整ロジックを持たせ、専門的な作業のためにサブエージェントを呼び出します。

1. Analyze the user request and decompose into subtasks
2. For each subtask, dispatch to appropriate specialist:
   - Use Task tool to spawn subagent with focused context
   - Pass only relevant context to each subagent
3. Collect and synthesize results from all subagents
4. Return unified response to user

伝言ゲームの問題： スーパーバイザーがサブエージェントの応答を誤って言い換え、忠実性が失われると、スーパーバイザーアーキテクチャの性能が低下することがあります。解決策は、統合によって重要な詳細が失われる場合に、サブエージェントが応答を直接渡せるようにすることです。Claude Code では、スーパーバイザーがすべてを書き直すのではなく、サブエージェントが共有ファイルに直接書き込むか、出力をそのまま返すようにします。

パターン 2：ピアツーピア／スウォーム

ピアツーピアパターンでは、中央集権的な制御をなくし、事前に定義されたプロトコルに基づいてエージェント同士が直接通信します。明示的な引き継ぎの仕組みを通じて、どのエージェントからでも別のエージェントに制御を移せます。

使用する場面： 柔軟な探索が必要なタスク、厳密な計画が逆効果になるタスク、事前の分解が難しい、要件が変化するタスクです。

メリット： 単一障害点がなく、幅優先の探索を効果的に拡張でき、創発的な問題解決の振る舞いを実現できます。

デメリット： エージェント数に応じて調整の複雑さが増し、中央で状態を管理する役割がないと動作が分散するおそれがあり、確実に収束させるための制約が必要です。

Claude Code での実装： 発見したニーズに応じて、他のコマンドを呼び出せるコマンドを作成します。タスクリストや状態ファイルなどの共有ファイルを、調整の仕組みとして使用します。

1. Analyze current state from shared context file
2. Determine if this agent can complete the task
3. If specialized help needed:
   - Write current findings to shared state
   - Invoke appropriate peer command/skill
4. Continue until task complete or hand off

パターン 3：階層型

階層構造では、エージェントを戦略、計画、実行の抽象度ごとのレイヤーに分けて配置します。戦略レイヤーのエージェントは目標と制約を定め、計画レイヤーのエージェントは目標を実行可能な計画に分解し、実行レイヤーのエージェントは個々のタスクを実行します。

Strategy Layer (Goal Definition) -> Planning Layer (Task Decomposition) -> Execution Layer (Atomic Tasks)

使用する場面： 明確な階層構造を持つ大規模プロジェクト、管理レイヤーがあるエンタープライズワークフロー、高レベルの計画と詳細な実行の両方が必要なタスクです。

メリット： 組織構造を反映し、関心事を明確に分離でき、レベルごとに異なるコンテキスト構造を実現できます。

デメリット： レイヤー間の調整にオーバーヘッドがかかり、戦略と実行の間で不整合が生じる可能性があり、エラーの伝播が複雑になります。

Claude Code での実装： 抽象度の異なるレベルにコマンドを配置して、プラグインを構成します。高レベルのコマンドは戦略に重点を置き、中レベルの計画コマンドを呼び出します。計画コマンドはさらに、個々の実行コマンドを呼び出します。

設計原則としてのコンテキスト分離

マルチエージェントアーキテクチャの主な目的は、コンテキストを分離することです。各サブエージェントは、他のサブタスクで蓄積されたコンテキストを持ち込まず、自身のサブタスクに集中できる、クリーンなコンテキストウィンドウで動作します。

分離のメカニズム

指示の受け渡し： シンプルで明確に定義されたサブタスクでは、コーディネーターが焦点を絞った指示を作成します。サブエージェントは、自身のタスクに必要な指示のみを受け取ります。Claude Code では、Task ツールを介してサブエージェントに最小限で的を絞ったプロンプトを渡します。

ファイルシステムメモリ： 共有状態を必要とする複雑なタスクでは、エージェントが永続ストレージに対して読み書きを行います。ファイルシステムを調整メカニズムとして使うことで、共有状態の受け渡しによるコンテキストの肥大化を避けられます。これは Claude Code に最も適した自然なパターンです。エージェントは Markdown ファイル、JSON 状態ファイル、または構造化ドキュメントを通じてやり取りします。

完全なコンテキストの委任： サブエージェントに全体の把握が必要な複雑なタスクでは、コーディネーターがコンテキスト全体を共有します。サブエージェントは独自のツールと指示を持ちますが、判断のために完全なコンテキストを受け取ります。コンテキスト分離の目的が損なわれるため、使用は最小限にしてください。

分離のトレードオフ

完全なコンテキストの委任は最大限の能力を発揮できますが、サブエージェントを使う目的が損なわれます。指示の受け渡しは分離を維持できますが、サブエージェントの柔軟性を制限します。ファイルシステムメモリはコンテキストを受け渡さずに共有状態を実現できますが、一貫性の課題が生じます。

適切な選択は、タスクの複雑さ、調整の必要性、作業の性質によって異なります。

合意形成と調整

投票の問題

単純な多数決では、推論が不十分なことによるハルシネーションが、妥当な推論と同等に扱われます。介入しなければ、合意することへの根本的な偏りにより、マルチエージェントの議論が誤った前提への合意に陥る可能性があります。

貢献の重み付け

エージェントの貢献度を、確信度や専門知識に応じて重み付けします。確信度が高いエージェントや、その分野の専門知識を持つエージェントの意見を、最終判断でより重視します。

討論プロトコル

討論プロトコルでは、複数のラウンドにわたってエージェント同士が互いの出力を批評します。複雑な推論では、敵対的な批評により、協調的な合意形成よりも高い精度が得られることがよくあります。

Claude Code での実装： あるエージェントが別のエージェントの出力を批評するレビュー段階を設けます。初期作業用、批評用、必要に応じて批評に基づく修正用に、それぞれ別のコマンドを用意します。

トリガーに基づく介入

マルチエージェントのやり取りを監視し、特定の行動指標を検出します。

• 停滞トリガー： 議論が進展しないときに作動します
• 追従トリガー： エージェントが独自の推論を行わず、互いの回答を模倣しているときに検出します
• 逸脱トリガー： エージェントが当初の目標から離れているときに検出します

失敗モードと軽減策

失敗：スーパーバイザーのボトルネック

スーパーバイザーはすべてのワーカーからコンテキストを蓄積し、容量超過や性能低下が起きやすくなります。

軽減策： ワーカーが要約した内容のみを返すよう、出力に制約を設けます。ファイルベースのチェックポイントを使用して状態を永続化し、コンテキストに履歴全体を保持しないようにします。

失敗：調整のオーバーヘッド

エージェント間の通信はトークンを消費し、遅延を生じさせます。複雑な調整によって、並列化のメリットが失われることがあります。

軽減策： 明確な引き継ぎプロトコルを設けて、通信を最小限に抑えます。エージェント間の通信には構造化ファイル形式を使用します。可能な場合は結果をまとめて処理します。

失敗：逸脱

エージェントが中央で調整されずに異なる目標を追求すると、意図した目的からずれていくことがあります。

軽減策： 各エージェントの目標範囲を明確に定義します。共有目標に向けた進捗を確認する収束チェックを実装します。エージェントの実行に反復回数の上限を設けます。

失敗：エラーの伝播

あるエージェントの出力に含まれるエラーが、その出力を利用する下流のエージェントに伝播します。

軽減策： エージェントの出力を利用側に渡す前に検証します。再試行ロジックを実装します。コンポーネントに障害が発生しても、正常に縮退するよう設計します。

Claude Code でのパターンの適用

監督役としてのコマンド

次の処理を行うメインコマンドを作成します。

1. タスクを分析して計画を立てます
2. Task ツールを使って、専門的な作業を行うサブエージェントを割り当てます
3. 結果を収集します（戻り値または共有ファイルを使用）
4. 最終出力を統合します

専門家としてのサブエージェント

専門分野ごとにサブエージェントを定義します。

• 各サブエージェントは、1つの専門分野に集中します
• サブエージェントには、専門分野に関連する限定的なコンテキストを渡します
• サブエージェントは、コーディネーターが集約できる構造化された出力を返します

共有メモリーとしてのファイル

エージェント間の連携にはファイルシステムを使用します。

• 状態ファイルでエージェント間の進捗を追跡します
• 出力ファイルに並行作業の結果を集約します
• タスクリストで残作業を調整します

例：コードレビューのマルチエージェント構成

Supervisor Command: review-code
├── Subagent: security-review (security specialist)
├── Subagent: performance-review (performance specialist)
├── Subagent: style-review (style/conventions specialist)
└── Aggregation: combine findings, deduplicate, prioritize

各サブエージェントには、レビュー対象のコードと専門分野に関する重点のみを渡します。監督役がすべての指摘を統合し、1つのレビューにまとめます。

ガイドライン

1. マルチエージェントシステムの主な利点として、コンテキストの分離を重視して設計します
2. 組織の比喩ではなく、連携のニーズに基づいてアーキテクチャパターンを選択します
3. Claude Code のマルチエージェントパターンでは、ファイルベースの通信をデフォルトで使用します
4. 状態を明確に受け渡す、明示的な引き継ぎプロトコルを実装します
5. 単純な同意ではなく、合意形成のために批評や議論のパターンを使用します
6. 監督役がボトルネックになっていないか監視し、ファイルによるチェックポイントを実装します
7. エージェント間で受け渡す前に出力を検証します
8. 無限ループを防ぐため、反復回数の上限を設定します
9. 障害シナリオを明示的にテストします
10. シンプルに始め、単一エージェントのアプローチで不十分な場合にのみ、マルチエージェントの複雑さを追加します

メモリーと状態の管理

複数のセッションにまたがるタスクや、永続的な状態が必要なタスクには、ファイルベースのメモリーを使用します。

作業メモリー

コンテキストウィンドウそのものです。すぐにアクセスできますが、セッションが終了すると消失します。アクティブな情報だけを保持し、完了した作業は要約します。

セッションメモリー

セッション中に作成され、進捗を追跡するファイルです。

• タスクリスト（完了した作業と残作業）
• 中間結果
• 判断ログ

長期メモリー

セッションをまたいで保持される永続ファイルです。

• プロジェクトレベルのコンテキストを記載する CLAUDE.md
• 指定されたディレクトリ内のメモリーファイル
• Markdown または JSON 形式の構造化ナレッジベース

マルチエージェント向けのメモリーパターン

• 引き継ぎファイル： エージェント A が状態を書き込み、エージェント B が読み取って続行します
• 結果の集約： 複数のエージェントが別々のファイルに書き込み、監督役がすべてを読み取ります
• 進捗の追跡： 共有タスクリストをすべてのエージェントが更新します
• 知識の蓄積： エージェントが共有ナレッジファイルに調査結果を追記します

ニーズを満たす、最もシンプルなメモリーの仕組みを選びます。ファイルベースのメモリーは透明性が高く、デバッグしやすいうえ、インフラストラクチャも不要です。

メモリーシステムの設計

メモリーは、エージェントがセッションをまたいで継続性を保ち、蓄積された知識をもとに推論できるようにする永続化レイヤーです。シンプルなエージェントはメモリーをコンテキストのみに依存するため、セッションが終了するとすべての状態が失われます。高度なエージェントでは、直近のコンテキストのニーズと長期的な知識の保持を両立させる、階層化されたメモリーアーキテクチャを実装します。ベクトルストアからナレッジグラフ、時間的ナレッジグラフへと発展するにつれ、検索と推論の改善に向けて、構造化メモリーへの投資が増えていきます。

基本概念

メモリーは、直近のコンテキストから永続ストレージまでの幅広い領域に存在します。一方の極にあるコンテキストウィンドウ内の作業メモリーは、遅延なくアクセスできますが、セッションが終了すると消失します。もう一方の極にある永続ストレージは、無期限に保持されますが、コンテキストに取り込むには検索が必要です。

シンプルなベクトルストアには、関係性や時間的な構造がありません。ナレッジグラフは推論に必要な関係性を保持します。時間的ナレッジグラフは有効期間を加え、時間を考慮したクエリに対応します。実装の選択は、クエリの複雑さ、インフラストラクチャの制約、精度要件によって異なります。

詳細なトピック

メモリアーキテクチャの基礎

コンテキストとメモリのスペクトラム メモリは、即時コンテキストから永続ストレージまで連続的なスペクトラム上に存在します。一方の極では、コンテキストウィンドウ内のワーキングメモリがゼロレイテンシのアクセスを提供しますが、セッションが終了すると消えてしまいます。もう一方の極では、永続ストレージが無期限に保持されますが、コンテキストに入るには取得が必要です。効果的なアーキテクチャは、このスペクトラムに沿った複数の層を使用します。

このスペクトラムには、ワーキングメモリ（コンテキストウィンドウ、ゼロレイテンシ、揮発性）、短期メモリ（セッション永続、検索可能、揮発性）、長期メモリ（セッション間永続、構造化、半永続）、永続メモリ（アーカイブ、クエリ可能、永久）が含まれます。各層は、レイテンシ、容量、永続性の特性が異なります。

単純なベクトルストアが不十分な理由 ベクトル RAG は、クエリとドキュメントを共有の埋め込み空間に埋め込むことで、セマンティック検索を提供します。類似性検索は、最も意味的に類似したドキュメントを取得します。これはドキュメント検索には効果的ですが、エージェントのメモリとしては構造が欠けています。

ベクトルストアは関係情報を失います。エージェントが「顧客 X が日付 Z に製品 Y を購入した」と学習した場合、ベクトルストアは直接尋ねられればこの事実を取得できます。しかし、「製品 Y を購入した顧客は他にどのような製品を購入したか？」という問いには答えられません。関係の構造が保持されていないからです。

ベクトルストアは時間的な有効性にも苦戦します。事実は時間とともに変化しますが、ベクトルストアには、明示的なメタデータとフィルタリング以外に「現在の事実」と「古い事実」を区別する仕組みがありません。

グラフベースのメモリへの移行 ナレッジグラフはエンティティ間の関係を保持します。孤立したドキュメントチャンクの代わりに、グラフはエンティティ A がエンティティ B に対して関係 R を持つことをエンコードします。これにより、単なる類似性ではなく関係をたどるクエリが可能になります。

時間的ナレッジグラフは、事実に有効期間を追加します。各事実には「有効開始」と、任意で「有効終了」のタイムスタンプがあります。これにより、特定の時点の知識を再構築するタイムトラベルクエリが可能になります。

ベンチマーク性能比較 Deep Memory Retrieval（DMR）ベンチマークは、メモリアーキテクチャ全体にわたる具体的な性能データを提供します。

メモリシステム	DMR 精度	取得レイテンシ	備考
Zep（時間的 KG）	94.8%	2.58s	最高精度、高速取得
MemGPT	93.4%	変動	良好な汎用性能
GraphRAG	~75-85%	変動	ベースライン RAG 比 20-35% の向上
ベクトル RAG	~60-70%	高速	関係構造を失う
再帰的要約	35.3%	低	深刻な情報損失

Zep は、フルコンテキストのベースラインと比較して取得レイテンシが 90% 削減されることを示しました（GPT-5.2 で 2.58s 対 28.9s）。この効率は、コンテキスト履歴全体ではなく、関連するサブグラフのみを取得することから生まれます。

GraphRAG は、複雑な推論タスクにおいてベースライン RAG 比で約 20-35% の精度向上を達成し、コミュニティベースの要約によりハルシネーションを最大 30% 削減します。

メモリレイヤーアーキテクチャ

レイヤー 1: ワーキングメモリ ワーキングメモリはコンテキストウィンドウそのものです。現在処理されている情報への即時アクセスを提供しますが、容量は限られており、セッションが終了すると消滅します。

ワーキングメモリの使用パターンには、エージェントが中間結果を追跡するスクラッチパッド計算、現在のタスクのために対話を保持する会話履歴、アクティブな目標の進捗を追跡する現在のタスク状態、現在使用されている情報を保持するアクティブな取得済みドキュメントなどがあります。

ワーキングメモリを最適化するには、アクティブな情報のみを保持し、完了した作業が注意から外れる前に要約し、重要な情報には注意が向きやすい位置を使用します。

レイヤー 2: 短期メモリ 短期メモリは現在のセッションをまたいで持続しますが、セッションを越えては持続しません。永続ストレージのレイテンシなしで検索と取得の機能を提供します。

一般的な実装には、セッション終了まで持続するセッションスコープのデータベース、指定されたセッションディレクトリへのファイルシステムストレージ、セッション ID をキーとするインメモリキャッシュなどがあります。

短期メモリのユースケースには、コンテキストを詰め込むことなくターンをまたいで会話状態を追跡すること、後で必要になる可能性があるツール呼び出しの中間結果を保存すること、タスクチェックリストと進捗追跡を維持すること、セッション内で取得した情報をキャッシュすることがあります。

レイヤー 3: 長期メモリ 長期メモリはセッションをまたいで無期限に持続します。これにより、エージェントは過去のインタラクションから学習し、時間をかけて知識を構築できます。

長期メモリの実装は、シンプルなキーバリューストアから高度なグラフデータベースまで多岐にわたります。選択は、モデル化する関係の複雑さ、必要なクエリパターン、許容できるインフラストラクチャの複雑さによって決まります。

長期メモリのユースケースには、セッションをまたいでユーザー設定を学習すること、時間とともに成長するドメインのナレッジベースを構築すること、関係履歴を持つエンティティレジストリを維持すること、再利用可能な成功パターンを保存することがあります。

レイヤー 4: エンティティメモリ エンティティメモリは、一貫性を維持するためにエンティティ（人、場所、概念、オブジェクト）に関する情報を特に対象として追跡します。これにより、複数のインタラクションをまたいでエンティティが認識される、初歩的なナレッジグラフが作成されます。

エンティティメモリは、ある会話で言及された「John Doe」が別の会話でも同じ人物であることを追跡することで、エンティティの同一性を維持します。時間をかけてエンティティについて発見された事実を保存することで、エンティティのプロパティを維持します。エンティティ間の関係が発見され次第追跡することで、エンティティの関係を維持します。

レイヤー 5: 時間的ナレッジグラフ 時間的ナレッジグラフは、明示的な有効期間でエンティティメモリを拡張します。事実は単に真か偽かではなく、特定の期間に真であるという形になります。

これにより、「日付 X 時点でのユーザーの住所は何でしたか?」といったクエリが、その日付範囲で有効な事実を取得することで可能になります。古い情報が新しいデータと矛盾する場合のコンテキスト衝突を防ぎます。エンティティが時間とともにどのように変化したかについての時間的推論を可能にします。

メモリ実装パターン

パターン 1：ファイルシステムをメモリとして使用 ファイルシステム自体をメモリレイヤーとして利用できます。このパターンはシンプルで、追加のインフラストラクチャを必要とせず、ファイルシステムベースのコンテキストを効果的にするジャストインタイム読み込みも実現できます。

実装では、ファイルシステムの階層を整理に利用します。意味が伝わる命名規則を使用します。事実は構造化形式（JSON、YAML）で保存します。時間を追跡できるよう、ファイル名またはメタデータにタイムスタンプを使用します。

利点：シンプルさ、透明性、移植性。 欠点：セマンティック検索ができない、関係を追跡できない、手動での整理が必要。

パターン 2：メタデータを用いたベクトル RAG 豊富なメタデータで拡張したベクトルストアは、フィルタリング機能を備えたセマンティック検索を提供します。

実装では、事実やドキュメントを埋め込み、エンティティタグ、時間的な有効性、情報源の帰属、信頼度スコアなどのメタデータとともに保存します。クエリでは、セマンティック検索と併せてメタデータフィルターを指定します。

パターン 3：ナレッジグラフ ナレッジグラフでは、エンティティと関係を明示的にモデル化します。実装では、エンティティの種類と関係の種類を定義し、グラフデータベースまたはプロパティグラフストレージを使用して、一般的なクエリパターンに対応するインデックスを維持します。

パターン 4：時間的ナレッジグラフ 時間的ナレッジグラフでは、事実に有効期間を追加することで、過去の時点を指定したクエリを可能にし、古くなった情報によるコンテキストの衝突を防ぎます。

メモリ検索パターン

セマンティック検索 埋め込みの類似度検索を使用して、現在のクエリと意味的に類似したメモリを取得します。

エンティティベースの検索 グラフの関係をたどり、特定のエンティティに関連するすべてのメモリを取得します。

時間的検索 有効期間フィルターを使用して、特定の時点または期間内に有効なメモリを取得します。

メモリの統合

メモリは時間の経過とともに蓄積されるため、増加を抑え、古くなった情報を削除するには統合が必要です。

統合のトリガー メモリが大幅に蓄積されたとき、検索結果に古くなった情報が多すぎるとき、スケジュールに従って定期的に、または明示的に統合が要求されたときに統合を開始します。

統合プロセス 古くなった事実を特定し、関連する事実を統合し、有効期間を更新し、不要になった事実をアーカイブまたは削除して、インデックスを再構築します。