「プロンプトエンジニアリング」「コンテキストエンジニアリング」に続く第3の波「メモリエンジニアリング」とは？
メモリエンジニアリングの話に入る前に、小川氏は2つの前提を示した。
前提の1つ目は「LLMは関数のようなもの。記憶する機構を実装しなければ何も覚えない」。LLMにトークンを入力すると、トークンが出力される。ここで過去の入力を反映した内容が出力されるのは、都度プロンプトを付加しながら“覚えているように”振る舞わせているだけで、実際にはLLMが自然と継続的に学習しているわけではない。新規セッションのたびに一度すべてリセットされる。コンテキストウィンドウは「一時的な作業メモリ」なのだ。
前提の2つ目は「LLMのコンテキストウィンドウは指数関数的に拡大している」。約1年前までは数千から数万トークンが限界だったが、現在では10万から100万トークンまで保持できるようになっており、LLMの“短期記憶”は飛躍的に拡張された。
しかし、その一方で、「『単にコンテキストを増やすだけでは性能は向上しない』と、広く知られている」と小川氏は指摘する。多くのコンテキストを記憶させると、性能が低下することは複数の論文で明らかになっている。その理由は、次の4つだ。
1つ目に「Context Poisoning（文脈の汚染）」がある。これは、会話履歴の中の古いコンテキストが残り続け、ノイズを含んだツール結果が混在してしまう事象だ。結果として、長い履歴の一部が誤解釈される。
2つ目に「Context Distraction（文脈の注意散漫）」だ。関係ないログが多数混ざることで、必要な情報が埋もれて見つからず、推論の優先度判断が曖昧になる。
3つ目に「Context Confusion（文脈の混乱）」。過去の回答と現在の回答が食い違い、反対の指示が混ざる。あるいは似た文章が複数あり、照合が乱れることがある。
そして、最後に「Context Clash（文脈の衝突）」を挙げた。異なるツールの結果が食い違うことで、会話の前後で条件が変化。RAGと履歴が矛盾してしまう。
その解決策を探るために、ここで改めてAIエージェント開発の主流にこれまでどのような開発手法があったのか、振り返ってみよう。
まずは、プロンプトエンジニアリングが話題になった。Chain-of-ThoughtやFew-shot Learningなどを用いて、一問一答の精度向上を目指す、“何を聞くか”を設計するアプローチだ。
次に波が来たのは、コンテキストエンジニアリングだ。RAGやFunction Callingによって、「今この瞬間」の情報最適化を図る、“何を渡すか”を設計するものである。
そして現在、一部の界隈でじわじわと注目され始めているのがメモリエンジニアリングだ。メモリの中で“何を覚え、何を忘れ、何を思い出すのか”を設計する、蓄積・忘却・想起の最適化のアプローチだ。
では、なぜ今、メモリエンジニアリングが注目され始めているのか。その理由を次に詳しく見ていく。
生成AIプロジェクト失敗の1つは、「記憶」と「適応力」の欠如？
小川氏はメモリエンジニアリングの注目が高まっている根拠として、MITのレポート「The GenAI Divide：State of AI in Business 2025」を引き合いに出した。同レポートは、2025年1月から6月にかけて、300以上の公開された生成AIプロジェクトを分析したほか、52の組織へインタビューを実施した結果がまとめられたものである。
そこで語られていたのは、生成AIプロジェクトに対する投資額は300〜400億ドルに達したものの、95%は成果なし、本番稼働にこぎつけたのはわずか5%という厳しい結果であった。この数字は、これまで多くの生成AIプロジェクトを支援してきた小川氏自身の体感と、大きくズレていないという。
なぜ生成AIプロジェクトの遂行は、そんなにも難しいのか。失敗の原因と解決案として挙げられていたものの中から、メモリに関するものだけを抜粋すると、以下の通りとなる。
まず、失敗の主因は「学習しないツール」にある。コンテキストを記憶せず、フィードバックから学ばないAIは業務に定着しない。また、単純作業ではAIが好まれるが、複雑な業務では90%が人間を指示。「記憶」と「適応力」の欠如が信頼の壁となっている。
「記憶」と「適応力」の欠如という課題に対して、どのような解決策が考えられるだろうか。小川氏は3つの転換点を紹介した。まず第1に「記憶しないツールの導入を中止すること」、そして第2に「特化型ベンダーと共創すること」、そして第3に「売上向上より確実なコスト削減すること」。
特に強調されるのが、第1の「記憶しないツールの導入を中止すること」だ。ここでは、「モデルの品質や規制が生成障壁となってAIプロジェクトが失敗するのではなく、“記憶の設計”に関する問題である」ことが明らかになったのだ。
そのうえで、小川氏は「開発者であれば、メモリエンジニアリングされているものに触れているはずだ」と語り、「ChatGPT」のメモリ機能と「Codex」のメモリ機能と「Claude Code」のメモリ機能の3つの例を挙げた。
メモリエンジニアリングに必要な、多岐にわたるDB／ストレージ技術をどう整理するか
メモリエンジニアリングを自社で挑戦する際に気をつけたいのが、「コスト・レイテンシー・信頼性」の3つの観点だという。
まずコストの観点でいうと、大量のプロンプトを入力することになるため、ステップ数に比例してコストが増大する。そのため、記憶させる量の上限を決める必要がある。
また、レイテンシーは、検索・リランク・要約の多段パイプラインの処理時間の累積だ。“何を記憶するかの判断自体”が時間を消費することを念頭におきながら、LangChainであれば何ホップ分を要約するか、時系列で要約するのかなど、記憶のさせ方を意識的に選びたい。
さらに、コンテキストが長くなればなるほど、アテンションの分散によって信頼性が下がる。ノイズとならないよう、どんなコンテキストを重視して記憶させるのか、あらかじめ設計しておかなければならない。
「AIエージェントを適切に作ろうと思ったら、最終的に人間の脳のメカニズムや動きを模倣することになる」と語る小川氏は、認知基盤ごとのユースケースと必要なデータベースやストレージを、次のように整理した。
今のスレッド内のやり取り、直前の差分を覚える「短期記憶」は、In-memory DB、 Key-Value Storeにため込む。一方、README・設計書・既存コードの「意味検索」を保存するのが、Vector DB、Document DB、Full-text Search Engineだ。
また、過去の修正履歴・以前の議論の参照する「エピソード記憶」のストレージには、RDB、Time-Series DB、Vector DBがある。CLAUDE.mdのルール・コーディングの方針は「手続き記憶」として、Document DB、JSON Storeに保存する。最後に、モジュール依存関係・クラス構造理解の「関係性記憶」は、Graph DB、Knowledge/Property Graph Storeにため込む。
このように認知基盤の違いによって、必要となるデータベースやストレージは多岐にわたる。その結果、Graph RAGやAgentic RAGなどの“◯◯RAG”が乱立し、どんどん実装が複雑になってしまう。
この課題を解消するのが、メモリコアとしての記憶領域をConverged DBに置いたOracle AI Databaseだ。これにより、ありとあらゆるデータをひとつのデータベースで扱える。さらに、これまではデータの種類だけ、検索の書き方を覚えなければならなかったが、Converged DBを扱うために必要なのは、SQLだけだ。もっと言えば、Oracle AI Databaseでは自然言語でSQLを生成できるため、SQLさえ不要である。
Oracle AI Databaseには、「JSON Relational Duality View」という、JSONをRelational Dataとして、またRelational DataをJSONとして扱える機能がある。そのため、データの結合や移動のコストがゼロとなり、1つの基盤で分析・検索・集計ができるメリットがある。
つまり、Oracle AI DatabaseはこれからのAIエージェントに必要不可欠な“記憶（短期／長期／意味記憶／エピソード記憶）”を統合管理できる、唯一のAIデータベースなのだ。
「Oracle AI Databaseは、AzureやGoogle Cloud、AWSといった他社のクラウド環境でも使うことができる。Oracle Cloud Infrastructure（OCI）は、お客様のデータセンタからOCIへのデータ転送料が無料。OCIからインターネットへのデータ転送も毎月10TBまで無料だ。他社のクラウド環境で構築した生成AIアプリケーションにメモリ機能を加えたいなら、メモリ機能だけでもOracle AI Database を使ってみてもらいたい」と語り、小川氏はセッションを締めくくった。
日本オラクル株式会社からのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
