DevOps Agentのメモリ機能を確認してみた
こんにちは。たかやまです。
DevOps AgentはWhat's New乗らない形で頻繁にアップデートを繰り返しています。
実際独自にChangelogとして、個別に Document History を参照させる形をとっているようです。
その中で6/12に複数アップデートが入っており、何本かブログ化されています。
- 【アップデート】DevOps AgentがリモートMCPサーバーとして利用可能になりました！ | DevelopersIO
- 【アップデート】DevOps Agentでカスタムエージェントが作成できるようになりました | DevelopersIO
このブログでは6/12のアップデートで追加されたDevOps Agentのメモリ機能について確認してみたいと思います。
さきにまとめ
- DevOps Agent Memoriesは、過去の調査結果や環境固有の情報をMarkdownファイルとして蓄積し、エージェントの判断精度を高める仕組み
- Managed Memory Storeとして
monitors（自動学習）とdirectives（ユーザー手動）の2種類が用意されている - チャットからメモリの作成・更新・削除が可能
- 現時点（2026/06/16）ではチャットで作成したメモリに YAML frontmatter が付与されず、調査時のメモリ読み込みでエラーになる事象を確認
DevOps Agent Memories とは
DevOps Agent Memoriesは、Agent Spaceに固有のコンテキストをMarkdownファイルとして蓄積・管理する仕組みです。
過去の調査で判明した根本原因や、環境固有の設定、ユーザー固有設定といった情報を記憶しておくことで、エージェントがより迅速で正確な判断を行えるようになります。
似た仕組みとしてSkillsやAgent Instructionsがありますが、それぞれ以下のように役割が異なります。
| 観点 | Skill | Agent Instructions | Memory |
|---|---|---|---|
| 知識タイプ | 手続き的（手順の指示） | 手続き的（常時適用される指示） | 情報的（合成されたコンテキスト） |
| コンテンツ形式 | MarkdownまたはZIPバンドル | Markdownのみ | Markdownのみ |
| コンテキスト注入 | オンデマンド（descriptionのマッチングでエージェントが判断） | 常時（全セッション） | オンデマンド（descriptionのマッチングでエージェントが判断） |
| 作成者 | ユーザー（UI、CLI）、DevOps Agent | ユーザー（UI、CLI） | ユーザー（Chat経由）、DevOps Agent（Learning Agent） |
ポイントとして、Memoriesはエージェントの能力を拡張するものではなく、意思決定に必要なコンテキストを提供する位置づけになります。
SkillsやAgent Instructionsとは異なり、「何をやるか」ではなく「何を知っているか」を補完する役割を担います。
イメージとしてはClaude CodeのAuto Memoryのような機能になります。
Memory Store
MemoriesはMemory Storeという単位で整理されます。
各Memory Storeには名前と説明が付けられており、エージェントはその説明をもとに、調査中に参照すべきかどうかを判断します。
現時点では、DevOps Agentが自動で作成・管理するManaged Memory Storeとして以下の2種類が用意されています。
monitors
モニターごとの再発する根本原因の履歴を保持するストアです。
各メモリファイルは特定のモニター（アラームやメトリクス）に対応しており、そのアラームに対してどのような原因カテゴリがインシデントを引き起こしたかをリスト化しています。
Agent Space内に過去2週間以内の調査がある場合、Learning Agentが1日1回動作して最近の調査を分析し、メモリを抽出・保存します。2週間更新がないメモリは自動削除され、ストアが上限に達した場合は最も古いメモリから削除されます。
directives
ユーザーが手動でエージェントの振る舞いを誘導するための指示を記録するストアです。
インフラの規約や命名規則など、常に従ってほしいルールを書き込む用途で使います。
例えば以下のような指示を記録できます。
- 「Lambdaはもう使っていない。サービスはFargateで動いている」
- 「ストレージサービスの名前はOrders Storage Serviceである」
やってみる
ではここからは実際に確認してみたいと思います。
冒頭にも載せていますが、メモリは左下の「ナレッジ」 > 「メモリ」タブから確認できます。
現在は何も記録されていませんが、いくつか操作を試してみたいと思います。
メモリの作成
冒頭記載した monitors は2週間以内の調査結果から学習エージェントが1日1回メモリを作成します。
When there are investigations in the past 2 weeks in the Agent Space, a Learning agent runs once per day to analyze recent investigations, then extract and store memories in this store. Memory items in this store are deleted when they have no updates for 2 weeks. If the store becomes full, the oldest memory item is deleted to make room.
翻訳 :
エージェントスペース内に過去2週間の調査が存在する場合、学習エージェントが1日1回実行され、最近の調査内容を分析し、このストアにメモリを抽出・保存します。メモリ項目は2週間更新がない場合に自動で削除され、ストアがいっぱいになった場合は最も古いメモリから順に削除されます。
作成まで時間がかかりそうなので、手動で作成できる directives のメモリを作成してみます。
ナレッジページを開いてチャットからメモリを作成してみます。
今回はクラスメソッドが提供するアカウントのセキュリティ制御についてメモリに記録したいと思います。
メモリの保存案が出るので、問題なければ保存を依頼します。
DevOps Agentは create-memory ツールを使用してストアにメモリを作成します。
メモリの確認
メモリの確認はナレッジページの「メモリ」タブから行えます。
先ほどチャットから作成したメモリはユーザー側で作成したので directives としてストアに保存されていますね。
DevOps Agentが作成するものは monitors として保存されるのかと思います。こちらは追って確認してみたいと思います。
内容を表示するとバージョン管理されていることがわかります。
現在はスキルのように手動で更新することはできないようで、メモリのチャットアイコンからDevOps Agentに更新を依頼することで修正できます。
メモリの動作確認
メモリの動作として、以下のサンプルシナリオを利用して確認してみます。
サンプルアプリではクロスリージョン推論でBedrockアクセスを行っており、こちらの接続ができない場合にアラートが上がりDevOps Agentが調査を行うようになっています。
クラスメソッドのメンバーズサービスでは、利用しないリージョンに対して制限をかける「リージョン制限」機能を提供しています。
今回の検証のアカウントではクロスリージョン推論を利用している環境なので、リージョン制限をかけるとBedrockアクセスができなくなります。
メモリにはこちらのリージョン制限についての情報が記録されているので、こちらを参照して調査を行ってみます。
が、調査をトリガーしたところメモリのRead部分でエラーが発生してしまいました。
記載としてDevOps Agentスキルと同様に YAML frontmatter が必要なようですが、チャットで作成されたメモリには YAML frontmatter がないためエラーが出ているようです。
手動で修正できないので今後のアップデートで修正されることを期待したいと思います。
ちなみにチャットからは作成したメモリを参照することができます。
少し強引ですが、チャットからメモリ参照させて再度調査を依頼することで環境情報を加味させた根本原因を得ることができました。
最後に
今回はDevOps Agentの新機能であるメモリを試してみました。
過去の調査結果や環境固有の情報をエージェントが記憶してくれるのは、繰り返し発生するインシデント対応で特に効果がありそうです。
directivesストアを活用すれば、自社固有のインフラ構成や運用ルールをエージェントに伝えておくこともできるので、調査精度の向上が期待できます。
一方で、チャットから作成したメモリにYAML frontmatterが付与されず調査時にエラーになる点は今後の修正で改善されることを期待したいところです。
monitorsストアの自動学習についても、実際にどのようなメモリが生成されるか引き続き確認していきたいと思います。
以上、たかやま(@nyan_kotaroo)でした。
