仕組み
記録される情報
完了した各調査では以下の情報が自動保存されます：| 情報 | 例 |
|---|---|
| Root Cause | 「データベース接続のリークによるコネクションプールの枯渇」 |
| 修復手順 | AIが推奨した優先度付きアクション |
| 影響を受けたサービス | インシデントに関係したサービス |
| 重大度 | インシデントの重大度レベル |
| 信頼度 | AIがRoot Causeについてどの程度確信を持っていたか |
想起インジケーター
調査が過去のインシデントの知識を活用した場合、RCA結果にバッジが表示されます：N件の類似インシデントの情報を参照これは、AIが以前の調査を参照して分析をガイドしたことを示します。バッジにホバーすると詳細を確認できます。
メモリが最も効果を発揮する場面
- 繰り返し発生する問題 — データベース接続の問題・メモリリーク・デプロイのリグレッション—パターンが繰り返されるたびに診断が速くなります。
- 類似したRoot Cause — サービスAのCPUスパイクが設定変更によって引き起こされた場合、次にサービスBでCPUスパイクが発生したとき、AIは設定を最初に確認します。
- チームの知識の継承 — エンジニアが異動や退職しても、デバッグのノウハウはシステムに残ります。
- 迅速な解決 — ゼロから始める代わりに、AIは過去の実績に基づいた仮説からスタートします。
継続的な改善
Incident Memoryはチームがcloudthinkerを使い続けるほど賢くなります：- 強化 — 複数のインシデントで同じRoot Causeが繰り返されると、そのパターンが強化され、将来の検索で優先されます
- 更新 — インシデントを再調査すると、古いメモリが新しい調査結果に置き換えられ、知識を最新に保ちます
- 重複排除 — 同一の調査結果は自動的にマージされ、重複を防ぎます
設定
Incident Memoryはワークスペースでメモリ機能が有効になっている場合、デフォルトで有効です。追加のセットアップは不要です。Incident Memoryは、結論に達したRCA調査（Root Cause特定・誤報・未発見）からのみ学習内容を記録します。キャンセルまたは失敗した調査は保存されません。
ベストプラクティス
- 詳細なインシデント説明を提供する — より豊富なコンテキストにより、AIが過去のインシデントからより良いマッチを見つけられます
- RCAを完了まで実行する — 結論に達した調査が最も有用なメモリに貢献します
- トポロジーを接続する — 影響を受けたサービスがマッピングされたインシデントは、将来のマッチングがより正確になります
- 必要に応じて再調査する — 同じインシデントに対して2回目のRCAを実行すると、より良い調査結果でメモリが更新されます
関連ドキュメント
Root cause analysis
AIエージェントがインシデントを調査し、メモリが活用するエビデンスチェーンを構築する方法を理解します。
Runbooks
エージェントがインシデント中に修復手順を見つけて実行できるようオペレーショナルランブックを接続します。