【Developers Summit 2026】Memory Is All You Need:コンテキストの「最適化」から「継続性」へ～RAGを進化させるメモリエンジニアリングの最前線～

Embed

Start on current slide

Slide 1

Slide 1 text

Memory Is All You Need: コンテキストの「最適化」から「継続性」へ～RAGを進化させるメモリエンジニアリングの最前線～ Kohei Ogawa Principal AI Data Software Solution Developer Cloud X, Cloud Business Unit February 20th, 2026 #devsumi

Slide 2

Slide 2 text

自己紹介 2 小川航平 Principal AI Data Software Solution Developer, Cloud X, Cloud Business Unit, Oracle Corporation Japan @shisyu_gaku フォロー&DM Welcomeです！データ基盤・ML基盤・生成AIプロジェクトを軸に、ビジネス／技術アーキテクトとパートナリングの観点で横断的に支援・推進。新卒でMicrosoftに入社しAzure Data&AI領域のCloud Solution Architectを担当後、コミュニティのグロースを支援するスタートアップにてAWSを用いた Webフルスタック開発と開発チームのリードを歴任。現在はAWS, Azure, Google Cloud に続くOracleのクラウドであるOCIのAI Agent／AI Database／Multi-Cloud を中心に、自社製品の価値設計と啓蒙、他社製品との共存リファレンスアーキテクチャの提唱、社会実装・プロトタイピングを担う。また、イベント登壇、OSS への貢献、書籍執筆にも多数注力。共著『ChatGPT 大規模言語モデルの進化と応用』を刊行など。 #devsumi

Slide 3

Slide 3 text

1. メモリエンジニアリングって何？ 2. MITのビジネスレポートで何が語られてた？ 3. 身近なメモリの機能って何がある？ 4. メモリエンジニアリングの設計を進めていく中でぶつかる課題と、気をつける観点は？ 5. なぜメモリエンジニアリングにOracleのAI Databaseが良いのか 6. メモリエンジニアリングへの理解を深めるコードや文献は論文以外何がある？ ※本セッションは、理論や概念的な話が多いセッションです・・・！ 3 Copyright © 2026, Oracle and/or its affiliates 本日30分でお伝えしたいことセッション資料公開済みです。 QRまたは、セッションタイトルで検索してみてください。

Slide 4

Slide 4 text

Slide 5

Slide 5 text

前提その１：LLMは関数のようなもの。記憶する機構を実装しなければ何も覚えない。 5 Copyright © 2026, Oracle and/or its affiliates 裏側でプロンプトを都度引っ張り、くっつけ覚えているように振る舞わせている。 Langchainなどで会話やメモリのコード実装したことがある方はイメージがつきやすいかも・・・ LLM ステートレスな関数のようなもの Tokens In Tokens Out Session A LLM Tokens In Tokens Out Session B 別のセッションで共有されない独立したインスタンスのようなもの ✓ 自然に継続的に学習しているわけではない ✓ 新規セッションの会話のたびに一度全てリセットされる ✓ コンテキストウィンドウは「一時的な作業メモリ」である #devsumi

Slide 6

Slide 6 text

前提その２：LLM のコンテキストウィンドウは指数関数的に拡大している 6 Copyright © 2026, Oracle and/or its affiliates LLM 指示ツール結果小規模ナレッジ約1年前数千〜数万トークンが限界 10万〜100万トークン級まで保持可能へ LLM は“短期記憶”が飛躍的に拡張された LLM 現在長い会話履歴多段の推論ログ複数ツールの結果大規模ナレッジ・・・ 1つのLLMが一度に保持できる“記憶”の量が急増 #devsumi

Slide 7

Slide 7 text

コンテキストを増やすだけでは性能は上がらない 7 Copyright © 2026, Oracle and/or its affiliates メモリを適切に設計できていない場合の課題ユーザ指示長い会話履歴多段の推論ログ複数ツールの結果大規模ナレッジ・・・ https://research.trychroma.com/context-rot 多くのコンテキストを記憶させると、性能が低下することが複数の論文で明らかになっている Context Poisoning 文脈の汚染 Context Distraction 文脈の注意散漫 Context Confusion 文脈の混乱 Context Clash 文脈の衝突 • 会話履歴の中の古い意図が残り続ける • ノイズを含んだツール結果が混在する • 長い履歴の一部が誤解釈される • 関係ないログが多数混ざる • 必要な情報が埋もれて見つからない • 推論の優先度判断が曖昧になる • 過去の回答と現在の回答が食い違う • 反対の指示が混ざる • 似た文章が複数あり、照合が乱れる • 異なるツールの結果が食い違う • 会話の前後で条件が変化 • RAGと履歴が矛盾する #devsumi

Slide 8

Slide 8 text

AIAgent開発の進化： ”何を覚え、何を忘れ、何を思い出すのか”の設計 8 Copyright © 2026, Oracle and/or its affiliates パラダイムシフト/置き換えではなく積み上げプロンプトエンジニアリング (2023年) コンテキストエンジニアリング (2024年) メモリエンジニアリング (2025年) “何を聞くか”を設計する • Chain-of-Thought • Few-shot “何を渡すか”を設計する • RAG • Function Calling 一問一答の精度向上「今この瞬間」の情報最適化 “何を覚え、何を忘れ、何を思い出すのか”を設計する蓄積・忘却・想起の最適化 #devsumi

Slide 9

Slide 9 text

Slide 10

Slide 10 text

MITレポートが示す残酷な現実：投資は加速しているが、成果は二極化 10 Copyright © 2026, Oracle and/or its affiliates 市場での動きとAI Agent開発の現場ユースケース模索ツール理解 PoC 本番稼働 PoCの壁！使い続けてもらうための壁！突破すべき壁が高い生成AIプロジェクト応答速度精度業務の棚卸し使いこなし術 ✓何を作ろう ✓どう作ろう ✓どう活用方法を布教させよう回答根拠/再現性データアクセス制御/セキュリティコミュニティ/ナレッジ共有の場 95% は成果なし 5% の本場稼働 300-400億ドルの投資額に達したものの・・・・・・・・・・・・（2025年1月-6月）調査規模 ───────────────────────────── ● 300以上の公開AIプロジェクトの分析 ● 52の組織へのインタビュー ───────────────────────────── MIT 「The GenAI Divide: State of AI in Business 2025」 #devsumi

Slide 11

Slide 11 text

Slide 12

Slide 12 text

モデルの品質や規制が障壁ではなくアプローチの違い 12 Copyright © 2026, Oracle and/or its affiliates つまり、記憶の設計が必要 ✓現状何が起きているか ✓原因：なぜ失敗するか ✓解決案：どうすれば良いか ❶ 導入は進んでいるが定着していない。汎用ツール利用率は 80%だが、業務特化型の成功実装は5%。 ❷ 構造変化が起きているのは 2つの産業のみ（テクノロジー、メディア・通信）。 7つは実験止まり。 ❸ 公式導入が進まない裏で「シャドー AI」経済が拡大。社員の90%以上が個人的に ChatGPTやClaudeを利用。 ❹ 予算の70%はセールス・マーケティング向け。しかし真のコスト削減はオペレーションとファイナンスにある。 ❺ 失敗の主因は「学習しないツール」。コンテキストを記憶せず、フィードバックから学ばないAIは業務に定着しない。 ❻ 単純作業ではAIが好まれるが、複雑な業務では90%が人間を支持。「記憶」と「適応力」の欠如が信頼の壁。 ❼ 内製（Build）は外部パートナーシップ（Buy）の2倍失敗する。成功率33% vs 67%。 ❽ チャットボットからエージェントへ。記憶と自律性を持つAgent が分断を越える鍵。 ❾ 経営者の選定基準第1位は「時間とともに改善する能力」。一度学習させればスイッチングコストは極めて高くなる。 ❿ 影響を受けるのはコア社員ではなく、 BPOや外部エージェンシーなどの「外部リソース」。 ⓫ 3つの転換点 1. 記憶しないツールの導入を中止 2. 特化型ベンダーと共創 3. 売上向上より確実なコスト削減 ※資料共有予定 #devsumi

Slide 13

Slide 13 text

モデルの品質や規制が障壁ではなくアプローチの違い 13 Copyright © 2026, Oracle and/or its affiliates つまり、記憶の設計が必要 ✓現状何が起きているか ✓原因：なぜ失敗するか ✓解決案：どうすれば良いか ❶ 導入は進んでいるが定着していない。汎用ツール利用率は 80%だが、業務特化型の成功実装は5%。 ❷ 構造変化が起きているのは 2つの産業のみ（テクノロジー、メディア・通信）。 7つは実験止まり。 ❸ 公式導入が進まない裏で「シャドー AI」経済が拡大。社員の90%以上が個人的に ChatGPTやClaudeを利用。 ❹ 予算の70%はセールス・マーケティング向け。しかし真のコスト削減はオペレーションとファイナンスにある。 ❺ 失敗の主因は「学習しないツール」。コンテキストを記憶せず、フィードバックから学ばないAIは業務に定着しない。 ❻ 単純作業ではAIが好まれるが、複雑な業務では90%が人間を支持。「記憶」と「適応力」の欠如が信頼の壁。 ❼ 内製（Build）は外部パートナーシップ（Buy）の2倍失敗する。成功率33% vs 67%。 ❽ チャットボットからエージェントへ。記憶と自律性を持つAgent が分断を越える鍵。 ❾ 経営者の選定基準第1位は「時間とともに改善する能力」。一度学習させればスイッチングコストは極めて高くなる。 ❿ 影響を受けるのはコア社員ではなく、 BPOや外部エージェンシーなどの「外部リソース」。 ⓫ 3つの転換点 1. 記憶しないツールの導入を中止 2. 特化型ベンダーと共創 3. 売上向上より確実なコスト削減 ※資料共有予定 #devsumi

Slide 14

Slide 14 text

Slide 15

Slide 15 text

すでにMemory EngineeringされているものにDeveloperは触れている 15 Copyright © 2026, Oracle and/or its affiliates 3つの身近なプロダクトでのメモリ実装 ✓ChatGPT メモリ機能 ✓Codex メモリ機能 ✓Claude Code メモリ機能 “メモリに保存されました” ※細かい裏側は不明点が多いユーザモデルユーザプロフィールを管理するDB • 会話の中でユーザの好みや背景情報を抽出し、データベース化 • 長期的なユーザプロファイルにより、セッションを跨いでユーザの特性を理解 • ユーザが記憶の利用を制御可能(記憶の管理) Pattern1: ユーザメモリ Pattern2: タスクメモリ Pattern3: ファイルベースの外部メモリ session1 session2 session3 Context Stream/Project State • セッションを横断したプロジェクト単位で文脈を保持 • コード全体や過去の修正履歴を現在の推論に統合 • 作業の流れを記憶し単発で終わらない１つのプロジェクト • メモリがブラックボックスではなく、ファイルシステム上の実体として存在する • ルール上、振る舞いの定義、チームでの共有 • ユーザが記憶を直接編集、削除、共有(Git管理)できる。パーソナライズ: ユーザプロファイルの永続化作業継続: プロジェクトコンテキストの維持記憶の明示化:プロジェクトメンバーへの共有 ※画像はclaude code以外のmdも混ざっている状態(あくまで例) #devsumi

Slide 16

Slide 16 text

Memory Engineeringする上で気をつけたい3つの観点 16 Copyright © 2026, Oracle and/or its affiliates コスト、レイテンシー、信頼性コスト信頼性レイテンシー検索、リランク、要約の多段パイプラインの処理時間の累積。何を記憶するかの判断自体が時間を消費する。 Agentへの入力が巨大に。「全部をプロンプトに入れる」はステップ数に比例してコスト爆発。コンテキストが長くなるほど、注意の分散で信頼性が下がる。最適化は必須。 #devsumi

Slide 17

Slide 17 text

AI エージェントの中身 17 Copyright © 2026 Oracle and/or its affiliates 最新の生成AIは言語モデルとDatabaseとToolによって構成される(＝RAG＋Action の統合) Tool群 ❷Retrieval ❹Action User/UI ❶Plan ❸ Reason クエリ/ (Threads作成) User/UIへResponse Agent処理フロータスク分解/Tool選定取得情報の解釈・意思決定意思決定から実世界に反映関連情報を検索ベクトルストアリレーショナル /DWH ナレッジグラフドキュメント/ 全文検索 Web/外部 API Data Source 類似検索数値検索認証/アクセス制御データ生成・更新ワークフロー/ 業務プロセス実行コミュニケーション/ 通知リソース/ インフラ制御外部サービス・API 呼び出し Actuators データを探索データを操作 #devsumi

Slide 18

Slide 18 text

AIエージェントの課題は、”今は”知能レベルではない。記憶である。 18 Copyright © 2026, Oracle and/or its affiliates コンテキスト共有にかかる時間と大きすぎるトークン消費 AI Agentのタスク 1つのタスク実行を呼び出されるツールコール回数 50回入力トーク数と出力トークン数の比率 100：１エージェントが適切に解釈し、アクションするために、何度も「一から考え直している」状態ぐるぐる思考中・・・ ※メモリエンジニアリングが不足している状態で複雑なタスクを解こうとする場合 https://manus.im/ja/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus #devsumi

Slide 19

Slide 19 text

Tool群 Retrieval の課題メモリエンジニアリングが不十分だと、検索に必要な文脈が毎回膨れ上がる 19 Copyright © 2026, Oracle and/or its affiliates ❷Retrieval ❹Action User/UI ❶Plan ❸ Reason クエリ/ (Threads作成) User/UIへResponse Agent処理フロータスク分解/Tool選定取得情報の解釈・意思決定意思決定から実世界に反映関連情報を検索ベクトルストアリレーショナル /DWH ナレッジグラフドキュメント/ 全文検索 Web/外部 API Data Source 類似検索数値検索認証/アクセス制御データ生成・更新ワークフロー/ 業務プロセス実行コミュニケーション/ 通知リソース/ インフラ制御外部サービス・API 呼び出し Actuators データを探索データを操作ワーキングメモリ直近の会話履歴システムプロンプト過去のツール結果・・・課題・・・全てをくっつけてコンテキストが肥大化してしまうエピソード記憶意味記憶/方針記憶長期記憶/知識ベース外部データベース #devsumi

Slide 20

Slide 20 text

Tool群 Reason の課題メモリエンジニアリングが不十分だと、推論が毎回ゼロから再構築される 20 Copyright © 2026, Oracle and/or its affiliates ❷Retrieval ❹Action User/UI ❶Plan ❸ Reason クエリ/ (Threads作成) User/UIへResponse Agent処理フロータスク分解/Tool選定取得情報の解釈・意思決定意思決定から実世界に反映関連情報を検索ベクトルストアリレーショナル /DWH ナレッジグラフドキュメント/ 全文検索 Web/外部 API Data Source 類似検索数値検索認証/アクセス制御データ生成・更新ワークフロー/ 業務プロセス実行コミュニケーション/ 通知リソース/ インフラ制御外部サービス・API 呼び出しデータを探索データを操作課題❶ トークン消費が爆発課題❷ 推論精度が不安定課題❸ マルチターンで整合性が崩れる課題❹ 実行コストが急増＋Retrievalの結果や方針プロンプトも追加され、 Reason のたびに履歴全体を再解釈、コンテキストサイズは指数的に増加・・・・ #devsumi

Slide 21

Slide 21 text

Tool群 Action の課題メモリエンジニアリングが不十分だと、アクションが独立し整合性が崩れる 21 Copyright © 2026, Oracle and/or its affiliates ❷Retrieval ❹Action User/UI ❶Plan ❸ Reason クエリ/ (Threads作成) User/UIへResponse Agent処理フロータスク分解/Tool選定取得情報の解釈・意思決定意思決定から実世界に反映関連情報を検索ベクトルストアリレーショナル /DWH ナレッジグラフドキュメント/ 全文検索 Web/外部 API Data Source 類似検索数値検索認証/アクセス制御データ生成・更新ワークフロー/ 業務プロセス実行コミュニケーション/ 通知リソース/ インフラ制御外部サービス・API 呼び出しデータを探索データを操作 Actuators はステートレスで前回の判断や進捗を保持しないため、毎回 Reason の結果を再提示する必要があり、整合性は“記憶”に依存する。課題❶：重複・無駄なAPI／DB更新が発生しやすい課題❷：ワークフロー途中での失敗リカバリが難しい課題❸：データの整合性・一貫性を保証しづらい課題❹：どの判断に基づく操作か後で説明しにくい Actuators #devsumi

Slide 22

Slide 22 text

人間の脳構造をエンジニアリングすると、一般的に必要なDB/ストレージ技術は多い 22 Copyright © 2026, Oracle and/or its affiliates 認知基盤ごとに扱う必要のあるデータも技術も異なる README・設計書・既存コードの意味検索過去の修正履歴・以前の議論の参照 CLAUDE.md のルール・コーディング方針モジュール依存関係・クラス構造理解今のスレッド内のやり取り・直前の差分短期記憶（Working Memory）意味記憶（Semantic Memory）エピソード記憶（Episodic Memory）手続き記憶（Procedural Memory）関係性記憶（Graph Memory）認知基盤ユースケース必要なDB/ストレージ技術 In-memoryDB, Key-Value Store VectorDB, Document DB, Full-text Search Engine RDB, Time-series DB, Vector DB Document DB, JSON Store Graph DB, Knowledge/Property Graph Store #devsumi

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

SQLであらゆるデータを検索: データの種類だけ検索の書き方があるが、SQLさえ分かれば良い単一言語でありとあらゆる検索パラダイムを活用可能 26 Oracle SQL Relational Query Keyword Query Spatial Query Vector Search Graph Query JSON Query Time-Series Query Hierarchical Query Analytical Query XML Query Streaming Query Blockchain Query Converged Database ありとあらゆる検索パラダイム {SQL} ありとあらゆるデータ Copyright © 2026, Oracle and/or its affiliates 26 #devsumi

Slide 27

Slide 27 text

SQL Retrieval Agent ：Converged Database × マルチワークロードのデータに対して自然言語で問い合わせる自然言語をSQLへ変換するOracleのSelect AI技術 27 自然言語 Oracle SQL Relational Query Keyword Query Spatial Query Vector Search Graph Query JSON Query Time-Series Query Hierarchical Query Analytical Query XML Query Streaming Query Blockchain Query Converged Database ありとあらゆる検索パラダイム select ai {SQL} ありとあらゆるデータ解釈生成マルチワークロード OLTP + OLAP(DHW) Copyright © 2026, Oracle and/or its affiliates 26 #devsumi

Slide 28

Slide 28 text

Slide 29

Slide 29 text

AI Agentのための統合メモリ基盤としてのDatabaseの姿 29 Copyright © 2026, Oracle and/or its affiliates 1つのデータベースでOLTPもOLAPのワークロードも様々な記憶を管理する構造化データ非構造化データ地理データグラフデータ LLM プロセス Unified Memory • OLTP (短期記憶) • OLAP (長期記憶) • セマンティックメモリ短期/長期/意味記憶/ エピソード記憶を統合管理その他、ベクトルデータなどコンテキストの共有サポート回答エージェント業務オペレーションエージェント分析エージェントコンテキストの共有により、AI Agentに必要不可欠な記憶を統合管理できる唯一のAIデータベース OLTP: 高速トランザクション (会話ステートのリアルタイム管理) OLAP: パターン分析・洞察 (長期記憶からの学習) 共通メモリ基盤供給と書き込み #devsumi

Slide 30

Slide 30 text

xxxRAGをユーザプロンプトに応じて、動的にルーティングする 30 Copyright © 2026, Oracle and/or its affiliates Select AI Agentによるコンテキストの受け渡し構造化データ非構造化データ地理データグラフデータ LLM プロセス Unified Memory • OLTP (短期記憶) • OLAP (長期記憶) • セマンティックメモリ短期/長期/意味記憶/ エピソード記憶を統合管理その他、ベクトルデータなどコンテキストの共有サポート回答エージェント業務オペレーションエージェント分析エージェントコンテキストの共有により、AI Agentに必要不可欠な記憶を統合管理できる唯一のAIデータベース OLTP: 高速トランザクション (会話ステートのリアルタイム管理) OLAP: パターン分析・洞察 (長期記憶からの学習) 共通メモリ基盤供給と書き込み AIDB内でAI Agentが動作する！ =Select AI Agent (ルータ機能あり)

Slide 31

Slide 31 text

どの3クラウド上の生成AIアプリケーションともOracleのAIDB技術は連携できる！ OCIなら OCI お客様データセンタ転送量無料 Free Free OCI 毎月10TB 無料インターネット Free 10TB Free AI Foundry Bedrock Vertex AI Generative AI Oracle Database @Azure Oracle Database @Google Cloud Oracle Database @AWS データを移動させるのにかかる金銭的コストが安い他社のクラウド環境でもOracle技術が使えるデータを移動させるコストが安い特にメモリの部分はOracleのAIDB技術を使っても良いかも？？ #devsumi

Slide 32

Slide 32 text

Slide 33

Slide 33 text

忘却機構の実装とその他DB操作によるメモリの管理 33 Copyright © 2026, Oracle and/or its affiliates DBで記憶を管理するからこそデータの扱いが柔軟に NOOP ADD 新規永続的な記憶をレコードとして追加 UPDATE 既存の信念や制約を修正する。矛盾を防ぐ。 No Operation。意図的にメモリ側には何もしない。ほとんどのインタラクションはノイズである。記憶しないという明示的な判断。 DELETE 忘却。古い情報やハルシネーションを削除する。時系列や重み付けを活用。ユーザ #devsumi

Slide 34

Slide 34 text

Memory Engineeringのサンプルコード 34 Copyright © 2026, Oracle and/or its affiliates コードベースで実装を理解 https://blogs.oracle.com/developers/comparing-file-systems-and-databases-for-effective-ai-agent-memory-management メモリ拡張機能を実装するパッケージ FileSystemとDBを対象にメモリエンジニアリングのメモリの管理の観点で比較(コードあり) メモリとコンテキストエンジニアリングのサンプルコード https://github.com/RichmondAlake/memorizz/edit/main/README.md https://github.com/oracle-devrel/oracle-ai-developer-hub/blob/main/notebooks/memory_context_engineering_agents.ipynb #devsumi

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Oracle Code Night オラクルのテクノロジーだけに限定しない、Developer（開発者）の Developer（開発者）による Developer（開発者）のための開発者向けコミュニティ Meetup セミナーほぼ毎週、さまざまなテーマで開催中！ Oracle Code Night開催情報は Connpassで公開中！ Oracle Code Night セッションアーカイブは YouTubeで公開中！ #devsumi

Slide 37

Slide 37 text

Developer Day 2026 に登壇しませんか？今年もCFP (Call for Proposals)形式で登壇者を募集！皆さんからのご応募お待ちしております！！開催日： 2026年 5月 21日(木) 13:00 ~ 開催会場：日本オラクル株式会社 CFP募集期間： 2026年 2月27日(金) 23:59まで (予定) セッションタイプ：ブレイクアウトセッション / LTセッション選択制セッションテーマ： Database / AI / Cloud Native / Security and Management / Cloud Infrastructure / Core Technology (OS, プログラミング言語, etc.) / その他… 詳細・応募 https://www.oracle.com/jp/developer/events/developer-day #devsumi