"500エラー"を前に立ち尽くすAIはもういない――問題解決を支える4つの手法、Memoryという最後のピース

―― 前回紹介した5つのピースに、実は一つ足りないものがあった。AIが"問題解決"の現場で本当に頼れる存在になるための、6つ目のピースの話。

第1章｜前回のおさらいと、抜けていた"6つ目のピース"

前回、企業でAIを活用するために最低限知っておきたい5つのことという記事で、AIを「優秀だが権限ゼロの新人エンジニア」に例えました。

その新人を戦力に変えるために必要な5つのピースが、これでした。

この5つが揃えば、AIは「本番業務の相棒」になる ―― そう書きました。

ですが、実際にAIエージェントを本番の障害対応に投入してみると、あるシーンで違和感に気づきます。

深夜、予期せぬ「500 Internal Server Error」。原因を特定し、一刻も早く復旧させなければならないプレッシャーの中で、私たちはついAIエージェントに「すべて」を委ねようとしてしまいます。

「関連するランブックも、監視ダッシュボードの数値も、過去の対応履歴も、すべてコンテキストウィンドウに放り込めば、AIが解決してくれるはずだ」

これが罠です。情報をただ「燃え盛る火の中に投げ込む」ようなやり方では、AIは情報の海で溺れ、ピント外れな汎用的回答しか出せなくなります。

この"問題解決"というシーンだけを切り出して見たとき、5つのピースのうち実際に効いてくるのはRAG・MCP・Skillsの3つです。そして、そこにもう一つ、前回のマップにはなかったピースが必要になります。**Memory（記憶）**です。

今回は、この4つ ―― Skills・MCP・RAG・Memory ―― を、「AIが問題を解決する」という一つのシーンに絞り込んで掘り下げます。

第2章｜Skills：迷いを消すための「手順書」と「判断力」

まず、エージェントに「スキル（Skills）」を授けます。前回の記事でも触れた通り、業務手順をMarkdown1枚に落とし込み、AIに「やり方」を資産として持たせる仕組みです。

障害対応であれば、こんな「トリアージ・スキル」が考えられます。

• エラー率の推移を確認する
• 直近のデプロイステータスを照合する

ここで重要な設計思想が「プログレッシブ・ディスクロージャ（段階的開示）」です。エージェントは最初から全知識をコンテキストに展開するのではなく、状況がそれを必要とした瞬間だけ、該当するスキルを引き出す。これにより、コンテキストウィンドウのノイズを最小限に抑え、思考の鮮度を保てます。

優れたスキルは、単なる手順の羅列ではありません。「これ以上の独力での探索はリスクが高い」と判断し、人間にエスカレーションすべきタイミングまでを定義しておく ―― これが「判断力」の部分です。特定の運用ドメインにおいては、LLMの汎用的なトレーニングデータよりも、この「構造化された手順」の方が遥かに確実な成果をもたらします。

Skillsは「いつ、どう動くか」を教えるピース ―― ここは前回の位置づけと変わりません。

第3章｜MCP：外部世界とつながるための標準プロトコル

手順が定義されていても、エージェントが現実のデータに触れられなければ意味がありません。そこで、エージェントと外部エコシステムの「架け橋」となるのがMCP（Model Context Protocol）です。

前回の記事では「AIに手足を与える」プロトコルとして紹介しました。障害対応の文脈でも役割は同じです。AIエージェントが「ホスト」となり、各外部システムが「MCPサーバー」の背後に配置されるアーキテクチャを採用することで、接続のたびに独自の連携コードを書く必要がなくなります。

エージェントが特定のロギングスタックのクエリ方法を個別に学習せずとも、標準化されたパイプラインを通じてリアルタイムのログやメトリクスを吸い上げられる ―― これがMCPの効きどころです。

「エラー率を調べろ」というスキルが発動したとき、MCPはその命令を具体的なデータ取得アクションへと変換します。前回「RAGがknow moreならMCPはdo more」と整理しましたが、障害対応という一発勝負の現場では、このdo moreの速さがそのまま復旧時間に直結します。

第4章｜RAG：人間が書き記した「知識の図書館」

次に、システム固有の「静的な知」を補完するのがRAGです。前回は「社内文書を検索してプロンプトに注入し、根拠付きで答えさせる仕組み」として紹介しました。

対象となるのは、マニュアル、依存関係マップ、過去の構成図といった、人間が意図的に書き記し、Vector Databaseに蓄積されたドキュメント群です。エージェントが問いを投げると、セマンティック検索によって関連性の高い「知の断片」が抽出され、コンテキストウィンドウへと届けられます。

前回、「RAGの精度が出ない原因の8割はドキュメント品質」と書きました。障害対応の文脈でも同じことが言えます。ランブックが整備されていなければ、RAGは検索対象を持たず、機能しようがありません。RAGは、あくまで"人間が過去に書いたもの"の範囲でしか賢くならない――ここに、次のMemoryが必要になる理由があります。

第5章｜Memory：経験から学ぶ「AI自身の知恵」――前回の地図になかったピース

ここが今回の本題です。最も「エージェントの人間味」を感じさせる要素が、Memory（記憶）です。

RAGと混同されがちですが、本質は情報の「出所」にあります。

例えば、ある難解な500エラーの真因が、どのランブックにも載っておらず、エージェントが以前「苦労して（the hard way）」ようやく突き止めたものだったとします。Memory機能を持つエージェントは、その時の試行錯誤を「自身の経験」として引き出し、二度と同じ轍を踏みません。解決後には新たな教訓をMemoryに書き戻すことで、自己進化を続けます。

昨日までの苦闘が、今日のエージェントにとっては洗練された「勘」へと変わる ―― これがMemoryがもたらす真のブレイクスルーです。

前回の5つのピースの表に、この行を1つ足す必要があります。

RAGが「知る」、MCPが「やる」、Skillsが「どうやるか」を教えるのに対し、Memoryは「前も同じ失敗をしたか？」に答えるピースです。5つのピースは"新人にどう教育を施すか"のマップでしたが、Memoryはその新人が"自分自身で経験を積み、成長していく"ための仕組みだと言えます。

第6章｜4つを問題解決の現場でつなぐと、何が見える

障害対応という一つのシーンで、4つのピースがどう連携するかを整理します。

1. Skillsが「トリアージ手順」を呼び出す
2. その手順の中でMCPが監視ダッシュボードやログを取得する
3. わからない箇所があればRAGが過去のランブックを検索する
4. それでも解けない未知のパターンに遭遇したら、Memoryが「これ、前にも似たケースがあった」と過去の経験を引き当てる

ケース1：既知の定型障害（デプロイ起因のエラー急増）

• 必須：Skills（トリアージ手順）＋MCP（メトリクス取得）
• RAGやMemoryが無くても対処できる最小構成

ケース2：ランブックには載っていない複合障害

• 必須：Skills＋MCP＋RAG（関連ドキュメントの横断検索）
• ドキュメントの品質が対応速度を左右する

ケース3：ドキュメント化されていない過去の"謎エラー"の再発

• 必須：4つすべて。特にMemoryが無いと、エージェントは前回と同じ試行錯誤をゼロからやり直すことになる

前回の記事で示した5つのピースのうち「ローカルLLM」と「Policy as Code」は、この問題解決シーンでは前提条件（居場所とガードレール）として背後に控えている、という位置づけになります。

第7章｜明日からできる、2つのアクション

理屈はわかった。では、何から始めるか。

(1) 「苦労して突き止めた」原因を、一つだけ書き戻してみる

直近で対応した障害のうち、ランブックに載っていなかった原因を一つ選び、エージェントのMemoryに残せる形（会話ログでも専用ストアでも）で記録してみる。これがMemory活用の第一歩です。

(2) RAGの検索対象とMemoryの書き戻し先を、意識して分ける

「これは人間が整備すべき知識か、それともエージェントが経験として積み上げるべきものか」を仕分けるだけで、RAGとMemoryの役割分担が明確になります。

結び｜AIエージェントを最適化する「黄金律」

AIエージェントにどのような知識を、どの経路で授けるべきか。前回の5つのピースに、今回のMemoryを加えると、こうなります。

• RAG：人間が書き記した既存の知識（マニュアル、文書）を活用する
• MCP：独自のコードを書かず、標準的な方法で実世界のデータへアクセスする
• Skills：繰り返される具体的な手順や判断基準を型化する
• Memory：エージェント自身の過去の成功・失敗経験から学ばせる

適切な情報を、適切なタイミングで、適切な形式で与える「オーケストレーション」こそが、エラーを前に立ち尽くさない、賢いAIエージェントを構築するための唯一の道です。

前回、あなたの会社に必要な5つのピースを問いました。今回はもう一つ聞かせてください。あなたのAIエージェントは、"前回と同じ失敗"を、ちゃんと覚えていますか？