DevOps Agentでカスタムメモリストアを作成してカスタムエージェントにメモリを持たせてみた

こんにちは。たかやまです。

以前、DevOps Agentのメモリ機能を確認する記事を書きました。

• DevOps Agentのメモリ機能を確認してみた | DevelopersIO

このときのメモリストアは、自動学習されるmonitorsとユーザーが手動で入力するdirectivesのmanagedストア2種類だけでした。

チャットからメモリを追加することはできましたが、投入先はあくまで既存のストアで、ストアそのものを新しく作る手段はありませんでした。

そんな中、2026年8月27日のアップデートで、ユーザー側で自由にカスタムメモリストアという形でメモリを作成できるアップデートの他、4件のアップデートが入りました。

今回はカスタムメモリストアを実際に作成してエージェントにメモリを持たせるところまで試しつつ、あわせて他のアップデートも確認してみます。

さきにまとめ

• カスタムメモリストアの作成
  • コンソール（Knowledgeページ → Memoriesタブ → Create memory store）とチャット依頼からでも作成できるようになった
  • エージェントはストアの中身を読む前に、nameとdescriptionだけで関連性を判断する
  • descriptionは「何を保持するか」+「いつ使うべきか」の2点構成で書くのが公式の推奨パターン
  • メモリストアは単発調査のスクラッチパッドやツール出力のキャッシュではなく、繰り返し使える結論を保存する場所として設計されている
• メモリのフォルダ整理
  • メモリのnameを/区切りにするとフォルダのようにネストでき、エージェントは索引を先に読んで関連する少数のファイルだけを開く（progressive disclosure）
• Learned Skillsのメモリ化
  • これまでLearned Skillsと呼ばれていたトポロジー・依存関係・パイプライン構造・ツール利用パターンの知見がmanagedストアとして統合された
  • 統合は自動で行われ、ユーザー側の作業は不要
• カスタムエージェントへのメモリストアの付与
  • カスタムエージェントにもメモリストアをアタッチできるようになった
  • アタッチしたストアだけを読み書きし、新規カスタムエージェントはストア未アタッチの状態で始まる
  • カスタムメモリストアは読み書き可能、マネージドメモリストアは読み取り専用

そもそもメモリとは

4件の詳細に入る前に、メモリが何をするものかだけ押さえておきます。

ひとことで言うと、セッションをまたぐと失われてしまう知識をエージェントに引き継がせる仕組みです。

調査のたびに同じ環境を調べ直したり、同じ根本原因に一から辿り着いたりしなくて済むように、分かったことを残しておく場所と考えると分かりやすいです。

公式ドキュメントでは、メモリを使う利点として4点が挙げられています。

似た機能にSkillsとAgent instructionsがありますが、役割が違います。

Skillsが「手順」を教えて能力そのものを拡張するのに対し、メモリは「事実」を渡して判断の速さと正確さを助けるものになります。

実体は1つのMarkdownファイルで、それを管理する箱としてメモリストアという概念があります。

エージェントはセッション開始時にストアの中身を渡されるわけではなく、まずストアの名前と説明の一覧だけを受け取ります。
そこでタスクとの関連性を判断し、関係のありそうなストアだけを開きます。

ストアの中でも同じことが起きて、説明を見てから関係のあるメモリだけを読みます。

この「説明を見て、開くかどうかを決める」という動きが、今回のアップデートの土台になっています。

それでは次からアップデートを確認していきます。

アップデート確認

アップデート1 : カスタムメモリストアを作成できるようになった

まず1件目です。

ユーザーが自分でカスタムメモリストアを作成できるようになりました。

What's Newには「チーム、サービス、または繰り返し発生する問題に関する運用知識をグループ化するための独自のメモリストアを作成できるようになった」と記載されています。

カスタムメモリストアの作成方法

作成はコンソールとチャットのどちらからでも行えます。コンソールから作る場合の手順は次のとおりです。

1. Agent Space Operator Web Appの「ナレッジ」ページを開く
2. 「メモリ」タブを選択する
3. 「ストアの追加」を選択する

4. nameとdescriptionを入力し、「ストアの作成」を選択する

チャットから作る場合は、DevOps Agentに自然言語で依頼するだけです。公式ドキュメントには次のような依頼例が挙げられています。

"Create a memory store named operational-procedures that holds the standard runbooks for our routine maintenance tasks." - Creates a store for standard operating procedures.

日本語翻訳 :
「operational-proceduresという名前のメモリストアを作成し、定期メンテナンスタスク用の標準運用手順書を保管してください。」- 標準的な運用手順書用のストアを作成します。
https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-memories.html

作成したカスタムストアは、DevOps Agentが自動生成するmanagedストアと同じように利用されます。

このアップデートで意識したいのが、descriptionの書き方です。

エージェントはメモリストアを事前にロードされず、nameとdescriptionだけを見てメモリを利用するか判断します。

A store's description is the most important thing you write, because it's how the agent decides whether the store is relevant—before it reads anything inside. ... A precise description gets the store opened at the right moment; a vague label such as notes or misc gives the agent nothing to match against, so it skips the store even when the answer is inside.

日本語翻訳 :
ストアのdescriptionは、あなたが書くもののうち最も重要です。なぜなら、エージェントが中身を読む前に、そのストアが関連するかどうかを判断する材料になるからです。（中略）正確なdescriptionは適切なタイミングでストアを開かせますが、notesやmiscのような曖昧なラベルはエージェントが照合する材料を何も与えないため、答えがストア内にあってもストアをスキップしてしまいます。
https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-memories.html

「答えがストア内にあってもスキップされる」と明記されているとおり、descriptionの精度が実用性に直結します。

公式が推奨するdescriptionの書き方は、「何を保持するか」+「いつ使うべきか」という2つの点を明確にすることです。

Write a description that states two things: what the store holds, and when the agent should use it. A reliable pattern is to end with the situations it applies to—for example, "Read when investigating checkout or billing latency."

• Too vague: "Payments notes."
• Effective: "Standing runbooks, known issues, and escalation contacts for the payments service. Read when investigating checkout, billing, or refund incidents."

日本語翻訳 :
descriptionには2つのことを書いてください。ストアが何を保持しているか、そしてエージェントがいつそれを使うべきかです。信頼できるパターンは、末尾に適用される状況を書くことです。例えば「Read when investigating checkout or billing latency.」のようにします。
曖昧すぎる例: 「Payments notes.」
効果的な例: 「Standing runbooks, known issues, and escalation contacts for the payments service. Read when investigating checkout, billing, or refund incidents.」
https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-memories.html

もう1つ見落としそうなのが、descriptionは人に向けた指示文ではなく、ストアの主題についての平叙文として書くという点です。「〜してください」ではなく「〜についての情報」と書くイメージですね。

ストアに入れる/入れない内容

descriptionの次に注意したいのが、メモリストアに何を保存するかです。

保存するのは、「後から思い出す価値のある結論」だけで、調査中のメモ書きを置く場所でも、ツールの実行結果を一時的に置いておく場所でもない、と公式ドキュメントに明記されています。

A memory store holds durable, synthesized knowledge—facts about your environment, recurring root causes, standing conventions and directives, and the findings and summaries you distill from past work. Store the conclusion worth recalling later, not raw data.

A memory store is not a scratchpad for a single investigation, and it isn't a key-value cache for a tool's output.

日本語翻訳 :
メモリストアが保持するのは、耐久性のある統合済みの知識、すなわち環境に関する事実、繰り返し起こる根本原因、標準的な取り決めや指示、そして過去の作業から導いた所見や要約です。後で思い出す価値のある結論を保存してください。生データではありません。
メモリストアは単発調査のためのスクラッチパッドではなく、ツール出力のためのキー・バリューキャッシュでもありません。
https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-memories.html

公式ドキュメントが具体例として挙げているのは「checkoutサービスはpayments APIを同期的に呼び出している」のような、調査で明らかになった結論の保存です。

ツール呼び出しの生の結果をそのまま保存して後で取り出す、という使い方は想定されていません。調査中の生データはエージェントが作業コンテキストに持っているため、そこで賄えるという整理です。

1件のメモリを大きな書き殴りにせず、単一の事実や教訓に絞ることも推奨されています。
メモリには調査を横断して有効な情報だけを保存し、一度きりの作業データは調査そのものに留めておくという住み分けです。

アップデート2 : メモリをフォルダで整理できるようになった

メモリの整理方法にフォルダ機能が加わりました。

What's Newには「共通のプレフィックス（例えばalarms/）でグループ化すると閲覧可能なフォルダ構造が作られる」と記載されています。

メモリのnameはストア内のパスとして扱われるため、/区切りでネストさせることでフォルダのように整理できます。

A memory's name is its path within the store, so you can group related memories into folders instead of keeping a single flat list. Use / in a name to nest memories—for example, alarms/checkout-latency or services/checkout/overview.

日本語翻訳 :
メモリのnameはストア内のパスであるため、単一のフラットな一覧を保つ代わりに、関連するメモリをフォルダへグループ化できます。nameに/を使ってメモリをネストしてください。例えばalarms/checkout-latencyやservices/checkout/overviewのようにします。
https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-memories.html

「ops-investigation-knowledge」というカスタムメモリストアに alarms/ プレフィックスを付与したメモリの作成を依頼してみます。

今回は sample-automated-aws-devops-agent-network-incident-response の調査を効率化するためのメモリの作成を依頼するプロンプトを投げます。

このAgent Spaceに接続されているAWSアカウントには、ネットワーク障害の調査を練習するためのサンプル環境がデプロイされています。
ALBの背後のEC2で動くNode.jsアプリが、RDS・NAT Gateway経由のインターネット・S3ゲートウェイエンドポイント・Bedrock Interfaceエンドポイントへの疎通を定期的にチェックし、失敗をカスタムメトリクスとしてCloudWatchへ送っています。

この環境のCloudWatch Alarmを調査して、次にアラームが発報したときに調査を早く進められるようにメモリを作成してください。

## やってほしいこと

1. `DevOpsAgentSample` ネームスペースのカスタムメトリクスと、それを監視しているCloudWatch Alarmを一覧で把握してください
2. 各アラームについて、どのリソースへの疎通を監視しているか、発報したときに何が起きている可能性があるかを、実際のテンプレートやリソース構成から確認してください
3. 確認した内容を、アラームごとにメモリとして保存してください

## メモリの作り方

保存先のストアは `ops-investigation-knowledge` という名前で新規に作成してください。
ストアのdescriptionは、何を保持していて、いつ参照すべきかがわかるように設定してください。

CloudWatch Alarmに関するメモリは、必ず `alarms/` プレフィックスを付けた名前にしてください。
例えば `alarms/database-connection-failures` のような形式です。
アラームごとに1件ずつ、合計4件のメモリを作成してください。

アラーム個別ではない情報（この環境全体のネットワーク構成、4つのアラームに共通する設定など）は、`alarms/` を付けずに保存してください。

## 各メモリに含めてほしい内容

- そのアラームが監視しているメトリクスと、監視対象のリソース
- 発報時に疑うべき原因の候補（セキュリティグループ、ルートテーブル、VPCエンドポイントポリシー、IAM、NAT Gatewayなど、この環境の構成から実際にあり得るもの）
- 最初に確認すべき項目と、その確認方法
- 調査時に紛らわしい点があればその注意書き

## 保存する内容についての注意

後から思い出す価値のある結論だけを保存してください。
今回の調査で取得したメトリクスの数値やAPIレスポンスそのものは保存せず、そこから分かった事実や調査の勘所を残してください。

作成が終わったら、作成したストアとメモリの一覧を、名前とdescriptionがわかる形で見せてください。

作成が完了すると alarms フォルダが作成され、その配下にメモリが作成されることが確認できました。

フォルダに分けても、エージェントの動きは冒頭で触れたとおりです。

説明を見て開くかどうかを決める動きがここでも働き、まず索引となるファイルを読んで、タスクに関連する少数のファイルだけを開きます。
公式ドキュメントではこれを progressive-disclosure と呼んでいます。

Because a memory's location signals what it holds, the agent reads an index first and opens only the few files relevant to the task, the same progressive-disclosure pattern described above.

日本語翻訳 :
メモリの置き場所そのものがその内容を示す信号になるため、エージェントはまず索引を読み、タスクに関連する少数のファイルだけを開きます。これは前述したものと同じprogressive-disclosureのパターンです。
https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-memories.html

アップデート3 : Learned SkillsがMemoriesへ移行された

3件目はシンプルです。

DevOps Agentは調査を重ねるうちに、担当するインフラのトポロジーやコード依存関係を学習し、それを「Learned Skills」としてSkillsタブに蓄積していきます。
今回のアップデートで、この学習済みの知見がMemoriesへ移行されることになりました。対象は次の4種です。

移行は自動で、ユーザー側の作業は不要です。

During the move, the console keeps showing a learned skill on the Skills tab until its memory is ready, and then points you to its new home on the Memories tab. After the move, you view and manage your learned skills on the Memories tab of the Knowledge page.

日本語翻訳 :
移行中、コンソールはそのメモリの準備が整うまでlearned skillをSkillsタブに表示し続け、準備が整うとMemoriesタブにある新しい保存場所への導線を示します。移行後は、KnowledgeページのMemoriesタブでlearned skillsを閲覧・管理します。
https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-learned-skills.html

以下のように「スキル」を確認すると、tool-use-best-practices / chat-tool-use-best-practices / understanding-agent-space / understanding-pipeline-topology が移行された旨が表示されます。

「メモリ」側を確認すると、tool-use-best-practices / chat-tool-use-best-practices / understanding-agent-space / understanding-pipeline-topology が移行されたことが確認できます。

移行先はいずれもmanagedストアなので、ユーザーが削除することはできません。

アップデート4 : カスタムエージェントにメモリストアをアタッチできるようになった

4件目です。DevOps Agentのカスタムエージェントは、これまでSystem prompt・Tools・Skillsの3要素で構成されていました。

• 【アップデート】DevOps Agentでカスタムエージェントが作成できるようになりました | DevelopersIO

これまでMemoryについては、組み込みエージェントがAgent Space内の全メモリストアにアクセスできる一方で、カスタムエージェント側は関与しない仕組みでした。

今回のアップデートで、カスタムエージェントにMemory storesというメモリを構成できるようになりました。

カスタムエージェントの構成要素

カスタムエージェントのドキュメントを確認すると、構成要素としてMemory storesが加わっています。

Memory stores – Collections of memory that you attach to give the agent focused, informational context, such as your topology, past root causes, standing directives, or a store you created. A custom agent reads the memory stores you attach to it, and can write to the custom stores among them (managed stores such as monitors and directives stay read-only), so you give it the knowledge its job needs and leave the rest out. A new custom agent starts with no memory stores attached, so it has no memory access until you attach one.

日本語翻訳 :
Memory stores（メモリストア） — トポロジー、過去の根本原因、常設の指示（directives）、または自分で作成したストアなど、エージェントに焦点を絞った情報コンテキストを与えるためにアタッチするメモリの集合です。カスタムエージェントは、アタッチしたメモリストアを読み取り、そのうちのカスタムストアには書き込むこともできます（monitorsやdirectivesのような管理ストアはread-onlyのままです）。これにより、そのタスクに必要な知識だけを与え、それ以外は含めないようにできます。新規カスタムエージェントはメモリストアが何もアタッチされていない状態で始まるため、アタッチするまではメモリへのアクセスが一切ありません。
https://docs.aws.amazon.com/devopsagent/latest/userguide/working-with-devops-agent-custom-agents-index.html

ポイントは2つあります。

1つは、アタッチしたストアが単なる読み取り専用の参照先ではないという点です。managedストア（monitors・directives）はread-onlyのままですが、カスタムストアについては書き込みも可能になっています。

もう1つは、新規カスタムエージェントの初期状態がメモリアクセスゼロだという点です。組み込みエージェントのようにデフォルトで何かへアクセスできる状態ではなく、明示的にアタッチして初めてメモリを参照するようになります。

実行フローの中でのメモリの扱い

カスタムエージェントの実行フロー全体を見ると、メモリの読み書きがどのステップで発生するかも書かれています。

When a custom agent executes, it:

1. Loads its system prompt, tools, skills, and attached memory stores from the configuration you defined.
2. Connects to the Agent Space MCP toolbox and accesses only the tools you assigned to it.
3. Loads its assigned skill documents, making their instructions and domain knowledge available during invocation.
4. Reads the memory stores you attached, using their descriptions to open only the memories relevant to the task, and records what it learns back to any attached custom stores.

日本語翻訳 :
カスタムエージェントが実行されるとき、次の処理を行います。

1. 定義された設定から、システムプロンプト、ツール、スキル、アタッチされたメモリストアを読み込む。
2. Agent SpaceのMCPツールボックスに接続し、割り当てられたツールのみにアクセスする。
3. 割り当てられたスキルドキュメントを読み込み、実行中にその指示とドメイン知識を利用可能にする。
4. アタッチされたメモリストアを読み込み、その説明文を使ってタスクに関連するメモリだけを開き、学習した内容をアタッチされたカスタムストアへ書き戻す。

https://docs.aws.amazon.com/devopsagent/latest/userguide/working-with-devops-agent-custom-agents-index.html

アタッチしたメモリストアをすべて丸ごと読み込むわけではなく、ストアの名前と説明文（description）を使ってタスクに関連しそうなものだけを開く設計です。

そして実行の最後には、学習した内容をアタッチ済みのカスタムストアへ書き戻します。
カスタムエージェントを繰り返し実行するほど、そのエージェント専用の知識が蓄積されていくイメージですね。

組み込みエージェントとの比較

組み込みエージェント（インシデント対応など）とカスタムエージェントで、メモリへのアクセス範囲がどう違うのかは比較表にまとまっています。

Custom agents compared to built-in capabilities - AWS DevOps Agent

組み込みエージェントはインシデント対応という性質上、Agent Space内のあらゆる知識に無条件でアクセスできる設計になっている一方、カスタムエージェントはユーザーが用途を定義するぶん、参照範囲も明示的に絞る設計になっているようです。

メモリストアのアタッチ手順

フォームから作成する場合は、作成フォーム内にMemory stores欄があります。
カスタムメモリストアは書き込むことができますが、managedメモリストアはReadOnlyでの参照となります。

Memory stores (optional) – Select the memory stores the agent can access. Use the search field to find stores by name. The agent reads the stores you attach and can write to attached custom stores; managed stores are read-only.

日本語翻訳 :
Memory stores（任意） — エージェントがアクセスできるメモリストアを選択します。検索フィールドを使ってストアを名前で検索できます。エージェントはアタッチしたストアを読み取り、アタッチしたカスタムストアには書き込むことができます。管理ストアはread-onlyです。

https://docs.aws.amazon.com/devopsagent/latest/userguide/custom-agents-creating-a-custom-agent.html

Chatで作成・編集する場合は、自然言語でアタッチ・削除を依頼する形になります。

You can attach memory stores when you create an agent, using either the form or Chat, and change them later by editing the agent. To attach or remove stores in Chat, ask the agent.

日本語翻訳 :
エージェント作成時にフォームまたはChatのいずれかでメモリストアをアタッチでき、後からエージェントを編集して変更することもできます。Chatでストアをアタッチ・削除するには、エージェントに依頼します。
https://docs.aws.amazon.com/devopsagent/latest/userguide/custom-agents-creating-a-custom-agent.html

メモリストアを使ったカスタムエージェントの実行

ではメモリストアを付与したカスタムエージェントの実行として以下のプロンプトを登録したカスタムエージェントを実行します。

プロンプトの中で調査内容の将来性のある結論をメモリストアに書き戻すようにしています。

あなたは、AWS環境のセキュリティ状況を月次でレポートするエージェントです。

## Goal
Security Hub、GuardDuty、Inspectorの検出結果を横断してまとめた月次レポートを作成する。先月から何が変わったか、今月何に対応が必要かが読み手に伝わることを目的とする。

## Approach
1. 対象期間のSecurity Hubの検出結果を収集する。重要度（CRITICAL、HIGH、MEDIUM、LOW）ごと、セキュリティ標準（AWS基礎セキュリティのベストプラクティス、CIS、PCI DSS）ごとに集計する。有効化されている各標準のコンプライアンススコアも記録する。
2. 対象期間のGuardDutyの検出結果を収集する。重要度ごと、検出タイプの系統ごと（Backdoor、CryptoCurrency、Recon、UnauthorizedAccessなど）に集計する。どのリソースが関係していたかも特定する。
3. 対象期間のInspectorの検出結果を収集する。スキャン種別（EC2、ECRコンテナイメージ、Lambda）ごとに分けて集計する。重要度が高いCVEを挙げ、そのうち修正が提供されているものがどれかを記載する。
4. 前月分についても同じ集計を行い、今月の数値と比較する。件数の比較は各サービスのAPIから両方の期間を取得して行い、メモリストアに保存された数値には依存しない。
5. security-monthly-report-context メモリストアを読み、レポートの形式に関する取り決め、承認済みリスクとして対応しないと判断済みの検出結果、繰り返し発生することが分かっている検出結果、環境固有の事情を取得する。ストアが空の場合、またはタスクに関連するメモリがない場合は、その旨をレポートの末尾に記載したうえで処理を続ける。
6. 今月新たに出た検出結果、今月解消された検出結果、複数月にわたって未解消のまま残っている検出結果を切り分ける。長期間未解消のものは、最も優先して報告する。承認済みリスクに該当するものは、判断済みの項目として区別する。
7. 未解消のCRITICALとHIGHの検出結果それぞれについて、影響を受けるリソース、最初に検出された時期、サービスが推奨する対処方法を記載する。
8. 今回の分析で判明した「今後も繰り返し参照する価値のある結論」を security-monthly-report-context ストアへ書き戻す。対象は、複数月にわたって再発している検出結果とその構造的な原因、環境固有の事情によって検出され続けている項目、新たに対応しないと判断された項目とその理由に限る。今月の検出件数やコンプライアンススコアといった数値そのものは、APIから再取得できるため書き戻さない。

## Constraints
- 読み取り専用で動作する。Security Hub、GuardDuty、Inspectorの検出結果を抑制、アーカイブ、解決済みに変更するなど、状態を変更する操作は一切行わない。
- 認証情報、アクセスキー、トークン、個人を特定できる情報をレポートに含めない。検出結果にこうした値が含まれる場合は、値そのものを転記せずに検出内容だけを記述する。
- AWSアカウントはアカウントエイリアスまたは短いラベルで表記し、12桁のアカウントIDをそのまま記載しない。
- 対象期間の範囲だけを扱う。期間の指定がない場合は前月1か月を対象とする。
- サービスがそのアカウントまたはリージョンで有効化されていない場合は、検出結果ゼロと書かずに「有効化されていない」と明記する。データがないことと検出結果がないことは別の意味を持つ。
- 重要度を自分で判定しない。サービスが付与した重要度をそのまま使う。
- 複数のサービスで同一の内容が検出されている場合（InspectorのCVEがSecurity Hubにも現れる場合など）は、重複して数えず1件として報告し、両方で検出されている旨を注記する。
- メモリストアへ書き戻すのは、後から思い出す価値のある結論だけとする。APIのレスポンスそのもの、今月の検出件数、コンプライアンススコアの数値は書き戻さない。これらは必要なときにAPIから再取得できる。
- メモリは1件につき1つの事実または教訓に絞る。複数の話題をまとめて1件に詰め込まない。
- メモリを書き戻すときは、既存のメモリと同じ内容を重複して作成しない。同じ話題のメモリが既にある場合は、新規作成ではなくそのメモリを更新する。

## Output
「セキュリティ月次レポート - <YYYY-MM>」というタイトルのアーティファクトを1つ作成する。以下のセクションを含める。

- サマリ。サービスごとの検出件数を重要度別に示し、先月の数値と差分を併記する
- Security Hubのコンプライアンススコアを標準ごとにまとめた表。先月からの変化を併記する
- 今月新たに出たCRITICALとHIGHの検出結果の一覧。影響を受けるリソース、検出日、推奨される対処方法を記載する
- 1か月を超えて未解消のまま残っている検出結果の一覧。未解消の期間が長い順に並べる
- 対象期間中に解消された検出結果の一覧
- 今月判断が必要な項目。すでに承認済みリスクとして扱っている項目とは分けて記載する

レポートは日本語で作成する。事実ベースの記述に徹する。数値が変化した箇所は、増減の方向を言葉で述べるだけでなく、変化前後の数値を明記する。

メモリストアを参照できなかった場合、または参照したが関連するメモリがなかった場合は、レポート末尾にその旨を記載する。承認済みリスクの情報がない状態で作成したレポートであることが読み手に伝わるようにする。

メモリストアとして「security-monthly-report-context」というメモリを用意してアタッチしています。

では、このカスタムエージェントを実行してみます。

実行するとアタッチしたメモリを参照していることが確認できます。

生成されたアーティファクトにもプロンプトの指示通りメモリを参照していることが確認できます。

またカスタムエージェント側でメモリストアにメモリを書き戻していることも確認できました。

メモリ全体の上限とストア管理

4件を通して、メモリはmanaged・custom問わず共通の上限を持ちます。

ストア数もメモリ数も無制限ではないので、細かすぎるトピック単位で乱立させるより、ある程度まとまった単位でストアを設計したほうがよさそうです。

作成後のメモリストアは、Operator Web AppのKnowledgeページから閲覧・管理できます。
メモリの詳細ページにはバージョンセレクタがあり、過去のバージョンを選んで内容を遡れます。

また、ストア単位でもメモリ単位でも、削除せずにトグルで有効・無効を切り替えられます。

無効にするとエージェントはそのストア内のメモリに一切アクセスしなくなるので、ストアを消さずに参照だけ止めたいときに使えそうです。

最後に

今回はDevOps Agentの2026年8月27日付アップデートから、メモリ関連の4件をまとめて確認してみました。

これまでのMemoriesはmanagedストアのみ利用可能でしたが、今回のアップデートでユーザーがカスタムストアを作成できるようになりました。

作成したストアの中はフォルダで整理でき、これまでLearned Skillsと呼ばれていた自動学習の知見も同じメモリとして扱われるようになっています。
さらにカスタムエージェントには、必要なストアだけを選んでアタッチできます。

メモリストアを使ううえで最も重要になるのがdescriptionです。
エージェントはストアの中身を読む前にnameとdescriptionだけで開くかどうかを判断するため、ここが曖昧だと答えがストアの中にあってもスキップされます。
公式ドキュメントでも、descriptionには「何を保持するか」と「いつ使うべきか」の2点を書くことが推奨されています。

フォルダ整理も同様にdescriptionと同じ仕組みの上で動いており、alarms/のようなプレフィックスで分けておくと、エージェントは索引から関連するメモリだけを開きます。

また、メモリに何を残すかという点も意識したいです。

メモリストアは調査中のメモ書きやツールの実行結果を置く場所ではなく、後から思い出す価値のある結論を残す場所として設計されています。
1件のメモリを単一の事実や教訓に絞ることも推奨されており、ストアあたり200メモリという上限もあるため、この辺りの設計も意識したいですね。

エージェントに何を覚えさせて、どのエージェントにどこまで渡すかを設計できるようになったので、カスタムエージェントの使い方のアプローチが増えたと思います。

descriptionの書き方とメモリに残す情報の粒度は、今後カスタムストアを運用していくうえで意識していきたいポイントです。

こちらの記事がどなたかの助けになれば幸いです。

以上、たかやま(@nyan_kotaroo)でした。