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

▼ イベントセッションリンク
https://event.shoeisha.jp/devsumi/20260218/session/6494

▼ 概要
AI Agent開発はこれまで、「Prompt Engineering」から「Context Engineering」へと進化してきました。そして今、その次の段階として「Memory Engineering」という新たなフロンティアに突入しています。
MITのレポート「The GenAI Divide: State of AI in Business 2025」が示すように、AIプロジェクトの成功を分ける鍵は、エージェントが「記憶」を持ち、状況に応じて適応できるかどうかにあります。しかし、単なるベクトル検索に基づく RAG だけでは、人間の脳が持つような複雑な記憶構造――短期記憶・長期記憶・エピソード記憶・手続き記憶――を十分に扱うことはできません。

本セッションでは、最新のメモリ領域に関する研究論文を紹介しつつ、アプリケーションエンジニアが実際に直面する 「実装の複雑さ」 に踏み込みます。短期記憶、長期記憶、スキル管理、目的別に派生した各種 xxxRAG のために、用途ごとに異なるデータベースを乱立させる必要はありません。Oracle AI Database を 「Memory Core」 と位置づけ、単一のデータベース上であらゆるメモリ領域を統合・管理することで、エンタープライズ企業で運用可能なAI Agentを構築するアーキテクチャを具体的に解説します。

Transcript

1. Memory Is All You Need: コンテキストの「最適化」から「継続性」へ ～RAGを進化させるメモリエンジニアリングの最前線～ Kohei Ogawa Principal AI Data Software Solution Developer Cloud X, Cloud Business Unit February 20th, 2026 #devsumi
2. 自己紹介 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
3. 1. メモリエンジニアリングって何？ 2. MITのビジネスレポートで何が語られてた？ 3. 身近なメモリの機能って何がある？ 4. メモリエンジニアリングの設計を進めていく中でぶつかる課題と、気をつける観点は？ 5. なぜメモリエンジニアリングにOracleのAI Databaseが良いのか 6. メモリエンジニアリングへの理解を深めるコードや文献は論文以外何がある？ ※本セッションは、理論や概念的な話が多いセッションです・・・！ 3 Copyright © 2026, Oracle and/or its affiliates 本日30分でお伝えしたいこと セッション資料公開済みです。 QRまたは、セッションタイトルで 検索してみてください。
4. 4 Copyright © 2026, Oracle and/or its affiliates はじめに #devsumi
5. 前提その１：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
6. 前提その２：LLM のコンテキストウィンドウは指数関数的に拡大している 6 Copyright © 2026, Oracle and/or its affiliates LLM 指示 ツール結果 小規模ナレッジ 約1年前 数千〜数万トークンが限界 10万〜100万トークン級まで保持可能へ LLM は“短期記憶”が飛躍的に拡張された LLM 現在 長い会話履歴 多段の推論ログ 複数ツールの結果 大規模ナレッジ ・・・ 1つのLLMが一度に保持できる“記憶”の量が急増 #devsumi
7. コンテキストを増やすだけでは性能は上がらない 7 Copyright © 2026, Oracle and/or its affiliates メモリを適切に設計できていない場合の課題 ユーザ 指示 長い会話履歴 多段の推論ログ 複数ツールの結果 大規模ナレッジ ・・・ https://research.trychroma.com/context-rot 多くのコンテキストを記憶させると、 性能が低下することが複数の論文で明らかになっている Context Poisoning 文脈の汚染 Context Distraction 文脈の注意散漫 Context Confusion 文脈の混乱 Context Clash 文脈の衝突 • 会話履歴の中の古い意図が残り続ける • ノイズを含んだツール結果が混在する • 長い履歴の一部が誤解釈される • 関係ないログが多数混ざる • 必要な情報が埋もれて見つからない • 推論の優先度判断が曖昧になる • 過去の回答と現在の回答が食い違う • 反対の指示が混ざる • 似た文章が複数あり、照合が乱れる • 異なるツールの結果が食い違う • 会話の前後で条件が変化 • RAGと履歴が矛盾する #devsumi
8. AIAgent開発の進化： ”何を覚え、何を忘れ、何を思い出すのか”の設計 8 Copyright © 2026, Oracle and/or its affiliates パラダイムシフト/置き換えではなく積み上げ プロンプトエンジニアリング (2023年) コンテキストエンジニアリング (2024年) メモリエンジニアリング (2025年) “何を聞くか”を設計する • Chain-of-Thought • Few-shot “何を渡すか”を設計する • RAG • Function Calling 一問一答の精度向上 「今この瞬間」の情報最適化 “何を覚え、何を忘れ、 何を思い出すのか”を設計する 蓄積・忘却・想起の最適化 #devsumi
9. 9 Copyright © 2026, Oracle and/or its affiliates MIT調査レポート：学習しないAIは業務で定着しない？！ #devsumi
10. 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
11. なぜ、社内向けデモ/PoCで上手くいっていても本番環境では失敗する 11 Copyright © 2026, Oracle and/or its affiliates コンテキストはノイズ化する コンテキストが汚れていない状態 コンテキストが汚れている状態 #devsumi
12. モデルの品質や規制が障壁ではなくアプローチの違い 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
13. モデルの品質や規制が障壁ではなくアプローチの違い 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
14. 14 Copyright © 2026, Oracle and/or its affiliates 改めて、記憶(メモリ)ってどの話？ #devsumi
15. すでに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
16. Memory Engineeringする上で気をつけたい3つの観点 16 Copyright © 2026, Oracle and/or its affiliates コスト、レイテンシー、信頼性 コスト 信頼性 レイテンシー 検索、リランク、要約の多段パイプラインの 処理時間の累積。 何を記憶するかの判断自体が時間を消費する。 Agentへの入力が巨大に。 「全部をプロンプトに入れる」は ステップ数に比例してコスト爆発。 コンテキストが長くなるほど、 注意の分散で信頼性が下がる。最適化は必須。 #devsumi
17. 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
18. 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
19. 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
20. 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
21. 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
22. 人間の脳構造をエンジニアリングすると、一般的に必要な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
23. xxxRAGの乱立・・・実装の複雑さはDBの増加からくる 23 Copyright © 2026, Oracle and/or its affiliates データ対応、回答精度向上を目的にDBを増やし続けた結果・・・・ ➢ データ同期の複雑化 ➢ コンテキストの断片化 ➢ 運用コストの増大 課題 #devsumi
24. Oracle AI Databaseであれば1つで済む 24 Copyright © 2026, Oracle and/or its affiliates メモリコアとしてのConverged DBという思想 #devsumi
25. Converged DB思想：ありとあらゆるデータベースパラダイムを単一のプラットフォームで実現 Oracle Database 26ai Copyright © 2026, Oracle and/or its affiliates 25 26 #devsumi
26. 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
27. 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
28. JSONで管理されるAgentのメモリを分析・検索・集計したい＝できる 28 Copyright © 2026, Oracle and/or its affiliates JSON Relational Duality ViewというJSONをRelationalとしてRelationalをJSONとして扱える機能がある #devsumi
29. 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
30. 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 (ルータ機能あり)
31. どの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
32. 32 Copyright © 2026, Oracle and/or its affiliates メモリエンジニアリングの実装例は？ #devsumi
33. 忘却機構の実装とその他DB操作によるメモリの管理 33 Copyright © 2026, Oracle and/or its affiliates DBで記憶を管理するからこそデータの扱いが柔軟に NOOP ADD 新規永続的な記憶を レコードとして追加 UPDATE 既存の信念や制約を 修正する。矛盾を防ぐ。 No Operation。 意図的にメモリ側には何もしない。 ほとんどのインタラクションは ノイズである。 記憶しないという明示的な判断。 DELETE 忘却。古い情報や ハルシネーションを削除する。 時系列や重み付けを活用。 ユーザ #devsumi
34. 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
35. 35 Copyright © 2026, Oracle and/or its affiliates 最後に #devsumi
36. Oracle Code Night オラクルのテクノロジーだけに限定しない、Developer（開発者）の Developer（開発者）による Developer（開発者）のための開発者向けコミュニティ Meetup セミナー ほぼ毎週、さまざまなテーマで開催中！ Oracle Code Night開催情報は Connpassで公開中！ Oracle Code Night セッションアーカイブは YouTubeで公開中！ #devsumi
37. 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
38. 38 Copyright © 2026, Oracle and/or its affiliates ご清聴いただきありがとうございました #devsumi