『モデル + ハーネス』で読み解く AIエージェント入門

Oracle AI Jam Session #38 『モデル + ハーネス』で読み解く AIエージェント入門 の登壇資料。
「ChatGPT に何か頼むと、まるで友達のように会話を覚えていて、調べものをして、答えてくれる。あれはどういう仕組みなの？」——本セッションは、AIエージェントをこれから触るエンジニアのための入門編です。

出発点はシンプルな事実です。LLM はステートレスで、記憶も状態も持ちません。「考える」「ツールを使う」「会話を覚える」「自分で終わりを判断する」——エージェントらしさはすべて、モデルを取り巻く設計（ハーネス）が生み出しています。この エージェント = モデル + ハーネス という視点を軸に、Function Calling、エージェントループ、メモリ、そして エージェントのデザイン・パターン（Tool Use／Reflection／Planning／RAG／Multi-Agent／MCP など）を整理します。 また、メモリのアーキテクチャの例として Unified Memory Core を、その実装例として Oracle AI Agent Memory や JSON Duality についてもご紹介いたします。

後半は、実際に開発したマルチモーダル RAG エージェントを題材に、設計判断・評価のしかた・つまずきと対処といった「現場の学び」を共有し、ライブデモで動きを体感していただきます。「分かった」で終わらず「作れそう」と思っていただくことがゴールです。

Transcript

1. 『モデル + ハーネス』で読み解く AIエージェント入門 Oracle AI Jam Session #38 荒川裕二 日本オラクル株式会社 AIプラットフォーム統括 Agentic AI ソリューション部
2. エージェント ＝ モデル ＋ ハーネス 2 Copyright © 2026, Oracle and/or its affiliates
3. マルチモーダルRAGアプリの開発で学んだことをお伝えします 3 Copyright © 2026, Oracle and/or its affiliates
4. マルチモーダルRAGアプリの開発で学んだことをお伝えします ハーネスを頑張って、 正答率が 65% から 87 % になった件 4 Copyright © 2026, Oracle and/or its affiliates
5. 使っているテクノロジースタック フロントエンド Next.js + TypeScript + Tailwind CSS バックエンド • • • • • 5 Oracle AI Vector Search：テキスト・ベクトル検索、ミックスモーダル（テキスト＋画像）・ベクトル検索 OracleText：全文検索 Oracle Agent Memory：エージェントの長期記憶 JSON Relational Duality：分析はリレーショナルなテーブルで、外部へのエクスポートは JSON で一撃 OCI Generative AI (Enterprise AI Models) • xAI Grok 4.3：画像キャプション生成とエージェントの推論 • Cohere Embed 4：テキスト埋め込み、ミックスモーダル埋め込みの生成 Copyright © 2026, Oracle and/or its affiliates
6. モデル ＋ ハーネス 今日の合言葉 エージェント ＝ モデル ＋ ハーネス Agent = Model + Harness ハーネス（周辺の設計） ループ制御 ツール実行 モデル (LLM) メモリ 終了判定 賢さ・意味判断は モデル。記憶・ツール・ループ・終了判定は ハーネス（普通のコード）。 “エージェントらしさ”はすべて、モデルを取り巻く設計＝ハーネスが生み出す。 ハーネス ＝ モデル（LLM）以外の普通のコード 6 Copyright © 2026, Oracle and/or its affiliates
7. モデル ＋ ハーネス 今日の３つのサブテーマ 7 1 LLM は仕事を早く切り上げたがる 2 LLM は記憶しない 3 トレースがないと何も直せない Copyright © 2026, Oracle and/or its affiliates
8. エージェントとは：5 ステップのループ エージェント＝環境を感知し、 目標達成のために行動するシステム ①ミッション受領 ⑤ 観察→繰り返す 1 回で答えず、達成するまで ③④⑤ が回り続ける ② 状況スキャン 「1 回検索して 1 回答える」から 「達成するまで回る」への転換 この“回る”が今日の主役 ④ 行動（ツール実行） 出典：A. Gulli『Agentic Design Patterns』 8 Copyright © 2026, Oracle and/or its affiliates ③ 思考・計画
9. エージェントの自律性のレベル 今回試したアーキテクチャ レベルが高い＝偉い、ではない。要件に対して最小のレベルを選ぶ。 Relfextion ReAct Naive RAG Agentic RAG Level 1 Level 3 Plan-ExecuteReflect マルチエージェント Level 2 協調する複数エージェント 戦略的問題解決 計画して複数ステップ ツール接続 Level 0 RAG・API 呼び出し 素の LLM ツールも記憶もない推論エンジン 出典：A. Gulli『Agentic Design Patterns』 9 Copyright © 2026, Oracle and/or its affiliates ※単純なRAGはエージェントに分類されないことが多いが “Agentic Design Patterns”では、 Level 1 のエージェントに分類されている
10. Workflow と Agent の違い＝「制御の所在」 Workflow（人が手順を固定） Agent（LLM が手順を決める） LLM が次の一手・ツールを動的に選ぶ 検索 ステップ 1 ステップ 2 ステップ 3 LLM 計算 LLM は部品として呼ばれるだけ 取得 Anthropic の推奨 まず最小・最単純から。エージェント化はコストとレイテンシを引き換えにする。 現実の設計は多くがハイブリッド（骨格は固定・要所の判断だけ LLM）。 手厚いハーネス 10 Copyright © 2026, Oracle and/or its affiliates
11. LLM はステートレス（記憶しない）⇒ 記憶を担うのはハーネス 質問 ユーザー 毎回：システム指示＋会話履歴＋今回の質問 アプリ（ハーネス） アプリが管理するシステム指示と会話履歴 LLM（状態なし） 毎回まっさらな関数呼び出し 僕の記事のリストを 作って 会話履歴 ＋ 今回の質問「僕の記事のリストを作って」 「会話を覚えている」のは、アプリが履歴を毎回送り直しているから 記憶・状態の置き場所を決めるのはアプリ側の設計＝ハーネス ハーネス 11 Copyright © 2026, Oracle and/or its affiliates LLM
12. 設計パターンの地図（『Agentic Design Patterns』（21 章から 7 選） Tool Use Reflection Planning RAG Multi-Agent / MCP Guardrails Routing パターンは単体でなく組み合わせて使う。 本プロジェクト＝ Routing（意図分類） + Planning ＋ Tool Use ＋Reflection + RAG 出典：『Agentic Design Patterns』 12 Copyright © 2026, Oracle and/or its affiliates ハーネス LLM
13. 設計パターン ①：Routing（振り分け） ★ 採用 入力に応じて処理経路を振り分ける（意図分類）。 仕組み： 入力の意図を判定し、 適切なハンドラ/ツールへ送る。 使いどころ： 多様な入力を 1 つの入口でさばく。 QA 入力 分類 振り分け 資料検索 記憶 本プロジェクトでは：質問の意図（QA / 資料検索 / 記憶）を分類して分岐 ハーネス 13 Copyright © 2026, Oracle and/or its affiliates LLM
14. 設計パターン ②：Planning（計画・分解） ★ 採用 いきなり答えず、まず手順・部分課題に分解する。 仕組み： 目標を小さな課題に割り、 順に（または並行で）解く。 使いどころ： 多段・複雑で 1 発では解けないタスク。 部分課題１ 目標 LLMが分解 部分課題２ 部分課題３ 本プロジェクトでは：質問を複数の観点（aspect）に分解し、多段ホップで解く。 14 Copyright © 2026, Oracle and/or its affiliates
15. 設計パターン ③：Tool Use（道具を使う） ★ 採用 LLM に「外部世界へ手を伸ばす手足」を与える。すべてのエージェントの基礎。 仕組み： 使える関数（名前・説明・引数）を渡し、LLM は呼び出しを構 造化して返す。実行はアプリ。 使いどころ： 検索・計算・API 呼び出し・DB アクセス。 検索 LLM 計算 取得 本プロジェクトでは：Oracle DBを検索/取得する少数の関数（テキスト/画像ベクトル・全文・前後ページの 4 種）。 15 Copyright © 2026, Oracle and/or its affiliates
16. エージェントの手足：Tool Use ① アプリがツール定義 をLLMへ渡す ② LLMが tool_call を返す ③ アプリが 関数を実行 ④ アプリ結果を LLM に戻す ⑤ LLMが最終回答 / 次の呼び出し ②〜④ の繰り返し ＝ エージェントループ LLM は「この関数をこの引数で呼びたい」と構造化データで返すだけ。実際に実行するのはアプリ側（ここも モデル + ハーネス）。 LLM ネイティブの function calling と構造化出力を使うパターンもあれば、 カスタムのJSONやXMLを出力させるパターンもある 出典：『Agentic Design Patterns』Ch.5 Tool Use 16 Copyright © 2026, Oracle and/or its affiliates ハーネス LLM
17. 設計パターン ④：Reflection（自己点検） ★ 採用 自分の出力を自分で点検・修正する（自己批評ループ）。 仕組み： 生成 → 批評（足りない点は何か）→ 修正、を繰り返す。 生成 批評 使いどころ： 品質を上げたい・取りこぼしや誤りを減らしたい。 解決するまで繰り返す 本プロジェクトでは：reflect が「解決済み/未解決/次にやるべきこと/十分性」を構造化出力で返す 17 Copyright © 2026, Oracle and/or its affiliates 修正
18. 設計パターン ⑤：RAG（検索で補う） ★ 採用 訓練データにない社内情報・最新情報を、検索で補って答える。 仕組み： 質問 → 検索 → 取得した文脈 → それを根拠に回答。 質問 検索 使いどころ： 根拠つき回答・社内知識・最新情報。 DB 本プロジェクトでは：本体そのもの（マルチモーダル RAG） ベクトル（テキスト、画像）＋キーワード検索で取得し、引用付きで回答 18 Copyright © 2026, Oracle and/or its affiliates 回答 （引用付き）
19. 設計パターン ⑥：Multi-Agent／A2A／MCP（連携） 役割分担（複数エージェント）と、ツール/エージェントを繋ぐ共通プロトコル。 仕組み： 複数の自律エージェントが通信して協調（A2A）／ツール接続の 標準が MCP。 使いどころ： 大規模・多専門で 1 体では手に負えないとき。 Agent Agent A2A（エージェント間通信） MCP（ツール接続の標準） 本プロジェクトでは：あえて単一エージェント（要件に対し過剰＝引き算）。MCP は開発時の DB 調査で活用。 19 Copyright © 2026, Oracle and/or its affiliates Agent
20. 設計パターン ⑦：Guardrails / Safety（安全の番人） 入力検証・出力フィルタ・行動制約で、危険な入出力・過剰な行動を弾く。 仕組み： エージェントの入口と出口に“番人”を置く（外向きの番人） 使いどころ： 本番運用・エンタープライズでは必須 入力 番人 エージェント 入口と出口に“番人”（外向きのガードレール） 本プロジェクトでは、 Guardrails（外向き）は省略しています。 20 Copyright © 2026, Oracle and/or its affiliates 番人 出力
21. 作ったもの：マルチモーダル RAG エージェント 取り込み データベース モデル(LLM) エージェント / UI 資料 (PPT / PDF) Oracle AI Database 26ai ページ画像化 RAG エージェント コーパス（ベクトル込み） キャプション 生成(VLM) 会話履歴 ベクトル生成 実行トレース 抽出テキスト トークン / コスト Vision Language Model：xAI Grok4.3 埋め込みモデル：Cohere Embed 4 21 Copyright © 2026, Oracle and/or its affiliates チャット UI（トレース可視化） 検索ツール4 種 • • • • テキスト→イメージ・ベクトル検索 テキスト→テキスト・ベクトル検索 全文（キーワード）検索 隣接ページ取得 ハーネス
22. Naive RAG 正答率：65% Naive RAG 検索ツール3 種 検索それぞれ 1 回 • • • テキスト→イメージ・ベクトル検索 テキスト→テキスト・ベクトル検索 全文（キーワード）検索 網羅性：79% 回答 1 回 ここで終わり 自己点検も再試行も無い ＝エージェント要素ゼロ • • • 1ページで正答できるものは好成績 複数ページにまたがる手順は正答率20% 推移的質問全滅 終了：ループが無い 22 Copyright © 2026, Oracle and/or its affiliates ※網羅性：回答に必須な重要情報をどれだけ回答に含められているか
23. Naive RAG が複数ページの手順回答を失敗した原因 検索でヒットしたページ 検索で取りこぼしたページ p.20 p.21 p.22 p.23 p.24 p.25 p.26 p.27 手順が欠ける 23 Copyright © 2026, Oracle and/or its affiliates p.25
24. Naive RAG が複数ページの手順回答を失敗した原因 検索でヒットしたページ 検索で取りこぼしたページ p.20 p.21 p.22 p.23 p.24 p.25 p.26 p.27 p.25 手順が欠ける エージェントにして、 足りないページを自分で取りに行ってもらえばいいのでは？ 24 Copyright © 2026, Oracle and/or its affiliates
25. ReAct 型エージェンティック RAG 正答率：71% ReAct ループ どのツールを呼ぶか決定 ツール実行 → 観察を会話に追記 検索ツール3 種 • • • • 網羅性：81% テキスト→イメージ・ベクトル検索 テキスト→テキスト・ベクトル検索 全文（キーワード）検索 隣接ページ取得 New! • • • Naïve RAG:69% Naïve RAG:79% 1ページで正答できるものは好成績 複数ページにまたがる手順は正答率60% 推移的質問全滅 LLM が「もうツールは呼ばない」 と言ったら回答 終了：LLM が決める 25 Copyright © 2026, Oracle and/or its affiliates ※網羅性：回答に必須な重要情報をどれだけ回答に含められているか
26. ReAct 型のトレースを分析すると 検索でヒットしたページ 検索で取りこぼしたページ p.20 p.21 p.22 p.23 p.24 p.25 p.26 p.27 p.25 手順が欠ける かなり良くなったが、この症状がまだ残っていた 欠けていることを認識して取りに行くが中途半端 26 Copyright © 2026, Oracle and/or its affiliates
27. モデル ＋ ハーネス サブテーマ ① 1 LLM は仕事を早く切り上げたがる 手順を聞くと、途中までを回答したり、途中が抜けた回答をする 27 途中まで 途中が抜ける 手順 1〜3 で終わる （連続5ページの途中で切れる） 手順 1、２、５を答える （連続5ページの途中が抜ける） Copyright © 2026, Oracle and/or its affiliates
28. 原因：LLM の早期終了バイアス すべてを取りきらず 適当なところで満足する p.1 p.2 途中で「十分」と自己判定 p.3 p.4 p.5 ✕ もう十分 完了判定を LLM の“気分”に委ねる設計は再現性がない 研究でも既知の失敗様式：マルチエージェント失敗分類で「早すぎる終了」が独立カテゴリ（6% 超） エージェントの「早期離脱（early-exit）」行動を扱う論文も登場 出典：Cemri et al. arXiv:2503.13657 “Why Do Multi-Agent LLM Systems Fail?”；arXiv:2505.17616（early-exit） 28 Copyright © 2026, Oracle and/or its affiliates
29. 素朴な ReAct の構造とその限界 シンプルで速い。しかし構造的に防げない： Thought （推論） 早期終了：終了判定が LLM 任せ Action （行動） scratchpad （どんどん 長くなる） 文脈膨張：観測を毎回まるごと再入力 Observation （観測） 出典：Yao et al. “ReAct: Synergizing Reasoning and Acting in Language Models” ICLR 2023, arXiv:2210.03629 29 Copyright © 2026, Oracle and/or its affiliates
30. 「プロンプトで頑張る」に頼らない モデル A Ver6：△ 不安定 「途中で止めるな」 「最後まで探せ」 従うかはモデル次第 モデルB Ver5：✓ 従う 実測でモデル間差あり バージョンアップして振舞いが変わることも モデル B Ver6：△ 不安定 モデルは短命：コスト・性能で差し替えが前提 モデルとプロンプトに依存＝モデルを替えるたびに壊れる＝技術的負債 ⇒ 振る舞いの保証はハーネスへ 30 Copyright © 2026, Oracle and/or its affiliates
31. やっぱりハーネス！ 31 Copyright © 2026, Oracle and/or its affiliates
32. 決定論ゲート＝ハーネスによるのガードレール ハーネス（普通のコード） LLM（型付きサブルーチン） 不変条件：終了/継続・予算/上限・「諦めない条件」 意味判断：関連性・値の抽出・回答合成 入力は構造シグナルのみ（件数・反復数・未試行手段・予算残） 「もう十分」は助言にすぎない LLM 出力の受理可否を決める（最終決定権） 内容理解が要る判断だけを担う 完璧です！終わります！ if 〇,△,□,★ then 完了 〇と△と□を見つけました！ リトマス・テスト：条件式に話題・資料名が出てきたら設計が間違い（＝特定のコーパスや質問専用の症状パッチ）。上限は設ける。 外部の裏付け：「モデルの停止 ≠ ゴールの達成。完了確認はハーネスの責務」— The Agent Loop Decoded 出典：Oracle “The Agent Loop Decoded” 32 Copyright © 2026, Oracle and/or its affiliates
33. 実装したゲートたち（抜粋）と「見える」仕掛け LLMの判断に委ねず 強制 隙間を強制的に埋める p.20 p.21 p.22 p.23 p.24 p.25 p.26 p.27 前方継続：末尾方向へ強制的に取り続ける 前方継続：手順が「まだ途中」の間は次ページを取り続ける（上限 4） モダリティ網羅：諦める前に未試行の検索手段（画像/テキスト/キーワード）を使い切る ギャップ補完：飛び飛びに取れた手順の内部の穴を埋める 終了の論理合成：「(強制タスクが空)∧(全観点が決着∨予算切れ)」から終了を計算で導く（LLM の「十分」で打ち切らない） どのゲートがいつ働いたかは、実行トレースに 33 Copyright © 2026, Oracle and/or its affiliates タグで記録（→ ストーリー③）
34. ゲートはどう働くか LLM の言い分は「助言」 → 受理するかを決めるのはハーネス（普通のコード） ① モダリティ網羅 リフレクト（LLM） 「この観点は無理」 「もう無理」と言うが、まだ試していない 検索手段（画像／テキスト）がある？ 試していない検索手段がまだある ⇒ 「無理」を取り消して、未試行の手段を強制タスクに積む ② 前方継続／ギャップ補完 続きがある → 次のページ取得を強制タスクに積む（上限 4 ページ） 「これは解決済み」 「もう十分」 「解決済み」と言うが、手順は まだ続きがある（次のページがある）？ 途中が抜けてない？ ③ 終了の合成 ギャップがある ⇒ 途中ページ取得を強制タスクに積む すべて満たす ⇒ 終了 ⇒ 回答 (強制タスクが空)かつ(全観点が決着、または、予算切れ) どれか未達 → もう 1 ホップ もう 1 ホップ＝諦めない 予算の上限（例）：反復 6 回・検索 20 件・空回り 2 回／前方継続は 4 ページまで —— ゲートは必ず止まる 34 Copyright © 2026, Oracle and/or its affiliates
35. Plan-Execute-Reflect型エージェンティックRAG 正答率：77% Plan-Execute-Reflect 検索ツール3 種 計画：質問を複数の観点に分解 • • • • 網羅性：93% テキスト→イメージ・ベクトル検索 テキスト→テキスト・ベクトル検索 全文（キーワード）検索 隣接ページ取得 Naïve RAG:69% Naïve RAG:79% ループ 検索計画 → 検索実行 → リフレクト • • 全般的に好成績だが、複数ページにまたがる手 順は正答率60%に留まる 推移的質問全滅 ゲート群が 足りない分を積む 終了の判定（決定論的論理） 終了：ハーネスが決定する 観点とタスクをすべて完了 35 Copyright © 2026, Oracle and/or its affiliates ※網羅性：回答に必須な重要情報をどれだけ回答に含められているか
36. Plan-Execute-Reflect型のトレースを分析すると 検索でヒットしたページ 検索で取りこぼしたページ p.20 p.21 p.22 p.23 p.24 p.25 p.26 p.27 p.28 抜けは無くなった！ 情報は取れているのに、LLMが回答に含めないことがある 36 Copyright © 2026, Oracle and/or its affiliates
37. Plan-Execute-Reflect型のトレースを分析すると 検索でヒットしたページ 検索で取りこぼしたページ p.20 p.21 p.22 p.23 p.24 p.25 p.26 p.27 p.28 抜けは無くなった！ 回答生成は ハーネスではできない。 困った！ 情報は取れているのに、LLMが回答に含めないことがある 37 Copyright © 2026, Oracle and/or its affiliates
38. Reflexion型エージェンティックRAG 正答率：87% Reflexion ループ Plan-Execute-Reflectを丸ごと 1 周 回答を丸ごと自己評価 証拠を持ち越して 質問を再分解 全ラウンドからベストを採用 終了：ハーネスが決定する 論理＋ベストの採用 38 Copyright © 2026, Oracle and/or its affiliates 検索ツール3 種 • • • • 網羅性：96% テキスト→イメージ・ベクトル検索 テキスト→テキスト・ベクトル検索 全文（キーワード）検索 隣接ページ取得 • • 全般的に好成績 推移的質問も正答 Naïve RAG:69% Naïve RAG:79%
39. ハーネスの階段：5 つの回答モード 同じアプリに回答モードが 5 つ——同じモデル・同じ検索ツール・同じ DB、変えるのはハーネスだけ（タブで切替） Naive RAG：検索 1 回 → 回答 1 回（エージェント要素なし） ReAct ハーネスの 手厚さ Plan-Execute-Reflect＋ゲートで制御 Reflexion： Plan-Execute-Reflectの回答を丸ごと自己評価 → 再分解してもう 1 周 自動＝cascade：Naive RAGで即答 → 自己点検 → 未達ならReflexionへ 1 回だけ昇格して回答入れ替え Reflexion Plan-Execute-Reflect 自動＝cascade Naive RAG 39 Copyright © 2026, Oracle and/or its affiliates ReAct ハーネス • 前方継続ゲート • ギャップ補完ゲート • モダリティ網羅ゲート • 終了の論理合成ゲート
40. 4 つのモードの動きを並べて見る 同じモデル・同じ検索ツール・同じ DB 違うのは「ループの有無」と「終了を誰が決めるか」 Naive RAG ReAct Plan-Execute-Reflect ループ 検索 1 回 ループ 計画：質問を複数の観点に分解 どのツールを呼ぶか決定 回答 1 回 ここで終わり 自己点検も再試行も無い ＝エージェント要素ゼロ Plan-Execute-Reflectを丸ごと 1 周 ループ ツール実行 → 観察を会話に追記 LLM が「もう呼ばない」 と言ったら回答 検索計画 → 検索実行 → リフレクト ゲート群が 足りない分を積む 終了の判定（決定論的論理） 終了：ループが無い 40 Copyright © 2026, Oracle and/or its affiliates Reflexion 終了：LLM が決める 終了：ハーネスが決定する 観点とタスクをすべて完了 回答を丸ごと自己評価 証拠を持ち越して 質問を再分解 全ラウンドからベストを採用 終了：ハーネスが決定する 論理＋ベストの採用
41. 効果測定のまとめ：ハーネスの階段 同一モデル（grok）・同一の質問 31 問・判定LLM 固定で 4 モードを一斉比較 65% Naive RAG 71% ReAct +22pt ＝ハーネス の階段 ハーネスの 手厚さ 77% Plan-Execute-Reflect＋ゲート 87% Reflexion 差が出る質問タイプ：連続ページの手順（ Naïve RAG 1/5 ⇔ Reflexion 5/5）・多段の推移（Reflexionのみ正解） Naïve RAGは最速（答えが 1 ページに載っている質問や、資料に無いことを正しく「無い」と言う質問では他と互角）⇒ 用途次第では十分 ハーネスが品質を決める 41 Copyright © 2026, Oracle and/or its affiliates
42. モデル ＋ ハーネス サブテーマ② 2 LLM は記憶しない API は毎回まっさら（ステートレス）。なのに ChatGPT は「その件の続きですね」と返す。 覚えているのは誰か？ → アプリ（ハーネス）。 この後、アプリが持つべき記憶を 3 つの層に分けて見ていく。 42 Copyright © 2026, Oracle and/or its affiliates
43. 会話メモリー＝“詰め直し”の設計 NG：全履歴をベタ積み OK：再構成して渡す 直近 6 ターンの要約 長い文脈は諸刃の剣 中間の情報は読み落とされる （Lost in the Middle） 直前の引用ページ ID 膨張・コスト増・精度低下 今回の質問 位置（左＝先頭 / 右＝末尾） コンテキストエンジニアリング＝「情報は豊かに、トークンは絞って」各フェーズに必要最小限だけ渡す。 出典：Liu et al. “Lost in the Middle” TACL 2024, arXiv:2307.03172；Anthropic “Effective context engineering for AI agents” (2025) 43 Copyright © 2026, Oracle and/or its affiliates
44. セッションをまたぐと全部忘れる → 長期記憶が欲しい 会話 A（月） 会話 B（火） 会話 C（水） ユーザー：私の名前は山田太郎です。 ＡＩ ：山田さん、こんにちは！ ユーザー：僕の記事を集めて ＡＩ ：どなたでしたっけ？ ユーザー：日本オラクルの山田太郎ですよ、 覚えておいてね ＡＩ ：山田さん、かしこまりました ユーザー：うちの会社の製品資料は？ ＡＩ ：どの会社ですか？ ユーザー： 会話メモリーはこの中だけ 会話メモリーはこの中だけ 会話メモリーはこの中だけ 長期記憶（会話を越えて「事実・好み・指針」を蓄積し、次の会話で思い出す） 覚えていてほしい：呼び名・略語の定義／好み（簡潔に答えて 等）／役割・担当 明示的な記憶の永続化や 自動抽出による永続化 44 Copyright © 2026, Oracle and/or its affiliates
45. 事実記憶の例 長期記憶なし 任意のブログを回答してしまっている 45 Copyright © 2026, Oracle and/or its affiliates 長期記憶あり 私＝荒川裕二のブログを回答している
46. 長期記憶は甘くなかった 実際に起きた「記憶汚染」 私、「山田太郎」さんに改名されちゃいました！ コーパス資料 （例文「私は山田太郎です」） AI の回答 （例を紹介） 抽出器 （「私は山田太郎」） 誤った記憶 （「ユーザーは山田太郎」） 原因：無差別に会話履歴を抽出器に放り込んだのでAI の回答にあったコーパス内容が個人事実として記憶された 出典：本プロジェクト実話（dev_journal 2026-07-04）；OWASP Top 10 for LLM Applications 2025 / Agentic（Memory Poisoning） 46 Copyright © 2026, Oracle and/or its affiliates
47. 長期記憶は甘くなかった 実際に起きた「記憶汚染」 私、「山田太郎」さんに改名されちゃいました！ コーパス資料 （例文「私は山田太郎です」） AI の回答 （例を紹介） 抽出器 （「私は山田太郎」） 誤った記憶 （「ユーザーは山田太郎」） 対策：user 発話のみ渡す 原因：無差別に会話履歴を抽出器に放り込んだのでAI の回答にあったコーパス内容が個人事実として記憶された 対策：抽出源をユーザー発話のみに限定（記録段の決定論ゲート）＝汚染防御はアプリ責務 OWASP もエージェント固有脅威に「メモリ汚染」を挙げる（セッションを跨いで残るのが怖い） 出典：本プロジェクト実話（dev_journal 2026-07-04）；OWASP Top 10 for LLM Applications 2025 / Agentic（Memory Poisoning） 47 Copyright © 2026, Oracle and/or its affiliates
48. 実装には Oracle AI Agent Memory が使える 会話ターン 自動抽出 (fact/pref/guideline) OAM_ 表 （Oracle DB） 次の質問で 想起 in-database（自スキーマの表・ベクトル込み）＝外部送信なし 全レコードに user/agent/thread/時刻のスコープ → 検索・一覧・削除 API フレームワーク非依存（LangGraph / Claude Agent SDK / OpenAI / 自作） 想起は参考文脈に留め、回答の根拠（引用）には昇格させない 記憶の管理タブ 一覧 / 意味検索 / 個別削除 ユーザー単位の全削除 ＝忘れられる権利 出典：Oracle AI Agent Memory（oracle.com/database/ai-agent-memory/・docs.oracle.com/en/database/oracle/agent-memory/） 48 Copyright © 2026, Oracle and/or its affiliates
49. メモリーは 3 層で設計する 層 覚えるもの 寿命 実体（本プロジェクト） 短期（ターン内） 作業状態（観点・取得ページ・選択） 1 ターンで破棄 AgentState（型付き状態） 会話（セッション） 履歴の要約・直近の引用・フォーカス 会話の間・DB 永続 ChatSession ＋ Oracle DB 事実・好み・指針 会話を跨いで永続 Oracle AI Agent Memory 長期（横断） どの層も「記憶しているのはアプリ」＝ハーネスの設計物。LLM は記憶しない。 読んで注入するだけ＝memory-augmented → encode / store / retrieve / inject / forget を管理＝memory-aware 話題で引けない記憶もある：常時適用の指示は 49 Copyright © 2026, Oracle and/or its affiliates 恒久設定へ人間承認で昇格（捕捉=LLM／適用=決定論注入）
50. モデル ＋ ハーネス サブテーマ③ 3 トレースがないと何も直せない エージェントは非決定的。同じ質問でも毎回同じ動きをしない。 何を検索した？ 50 何がヒットした？ LLMの推論は非決定的（※） なぜ終わったの？ temperature = 0 でも非決定的になる 過程の記録が必須 ハーネスで制御 Copyright © 2026, Oracle and/or its affiliates ※ 理由は “Defeating Nondeterminism in LLM Inference” で詳細に説明されている。
51. おすすめ トレースを「アプリのデータ」として DB に永続化 毎ターン記録 1 つの Oracle Database 観点分解 検索（ツール・引数・ヒット） documents / pages（コーパス） ゲート ホップ / ラウンド 送付・引用・未使用ページ 秒数 conversations / messages message_traces / trace_searches トークン・コスト UI「実行トレース」パネルは、この表 を読んでいるだけ 外部トレーシング（LangSmith / LangFuse 等）も OpenAI 互換なら数 行で併用可 trace_hops（ホップ別） feedback（評価） ゲート発火・失敗した実行・記憶想起・自動昇格の判定まで永続化 ※ログを異なる障害ドメインに保管するという原則は別途確立することが前提です 51 Copyright © 2026, Oracle and/or its affiliates 「発火ゼロ」も 0 と記録（負の証拠）
52. 実話：AI が MCP 経由で“全自動デバッグ” コーディング エージェント MCP Oracle DB （トレース表など） コーパスにあるのに回答できないのはなぜ？→ 調査・説明・修正＋テストまで 私（人）がやったのはレビューとマージだけ。SQL は書いていない トレースが DB にあるから、調査の道具が SQL ＝ AI が自走できる（MCP＝AI とツールを繋ぐオープン標準） 出典：MCP: Anthropic (2024) / modelcontextprotocol.io 52 Copyright © 2026, Oracle and/or its affiliates
53. 同じ DB に置く威力：JOIN で横断調査 conversations 例①「 が付いた回答は、 どの検索ツールの取りこぼしか」 message_traces 例②「画像検索は引用に貢献しているか」 → 1,172 トレースを集計して縮小を判断 （呼出 12% → 引用 4.7%） 1 本の SQL trace_searches 例③「その引用ページの実際の中身は」 （コーパス本体を検索する必要がある） feedback pages ログ基盤が別サービスだと、この JOIN のたびにエクスポートと突き合わせが要る。 ※コーパス：DB に登録されているドキュメント群のこと 53 Copyright © 2026, Oracle and/or its affiliates
54. JSON Relational Duality：正規化で書いて、1 つの JSON で読む conversations Duality View messages 同じデータ・二つの顔 { 会話 + 引用 + トレース + トークン使用量 } 自己完結した 1 つの JSON ドキュメント traces 書く / 分析・集計する側 持ち出す / AI に渡す側 分析＝正規化表が最適 持ち出し・AI （ChatGPTなど）への受け渡し＝自己完結の 1 文書。Duality は同じデータを両方で読み書き（1 read・ETL 不要） 54 Copyright © 2026, Oracle and/or its affiliates
55. 全部を同じ場所に ＝ Unified Memory Core アプリ (チャット UI) コーディングエージェント (MCP) Unified Memory Core（1 つの Oracle DB） コーパス（ベクトル込み） 会話履歴 長期記憶 実行トレース メトリクス (トークン・秒) フィードバック Oracle AI Agent Memory JSON Duality 同じ場所に置く御利益 会話×トレース×評価×コーパスを 1 本の SQL で JOIN 調査 一貫したアクセス制御と監査 バックアップ・削除の一元化 分析 SQL AI から見た単一の接続先 さらに先へ：この記憶層は、明日モデルが学べることを決める（訓練ループとの合流点）— “Design your memory layer accordingly” ※ログを異なる障害ドメインに保管するという原則は別途確立することが前提です 55 Copyright © 2026, Oracle and/or its affiliates
56. 評価（Eval）：「直した/壊した」を機械で判定する ① ゴールデンセット ② 品質ベンチ（LLM-as-a-Judge） 40 ターン・不変条件で採点 ＝退行の検知 改善の計測（4 モード比較 65〜87% はこれ） 絶対正解しないといけない問題。1つでもFailしたらその修正は却下 どれだけ良くなったかを評価する問題。いまだに完全に正答できないものも含まれている 点数が落ちたらその修正は却下 落とし穴：判定員 LLM に引用元の実物を渡さないと「資料にない」と誤判定（judge にもグランディングが要る） ゲート追加 / 修正・モデル差し替え・既定値変更は、必ず eval の前後比較してから確定。 評価と修正を自動化する場合は、評価用ハーネス（評価プロンプトも含む）は明示的に固定！！！！！！ ※ LLM って結構ずるをします 56 Copyright © 2026, Oracle and/or its affiliates
57. 2 種類のガードレール＋データ権限 外向きの番人（入出力の安全） 内向きの番人（制御フロー） プロンプトインジェクション・過剰な権限 決定論ゲート＝早期終了・取りこぼしを防ぐ 不変条件。 データ権限は AI 任せにしない：認証ユーザー ID を DB セッションまで伝搬（会話・記憶・監査を持ち主で分離） Oracle Deep Data Security 基本的なお作法：SQL は必ずバインド変数／シークレットをコード・ログに出さない／外部送信しない設計 57 Copyright © 2026, Oracle and/or its affiliates
58. コストとレイテンシの現実：測ってから絞る 送付ページ上限 24 → 8：入力 −39%・品質不変 89% 100% Before(24) 証拠の再送 After(8) -39% エージェントのコスト＝ループ回数 × 毎回の入力再送（賢くするほど高く・遅くなる） 入力トークンの約 9 割が reflect＋answer の証拠再送 トークン・コストをトレースに常時記録 → 質問 1 件あたりの単価が言える状態に Tool Output Offloading 生の検索結果は DB に置き、文脈には参照 ID だけ（必要時に展開） 58 Copyright © 2026, Oracle and/or its affiliates
59. モデル ＋ ハーネス 合言葉の回収：全部ハーネスの話だった エージェント ＝ モデル ＋ ハーネス ① 早く切り上げたがる ② 記憶しない ③ 見えないと直せない ゲートが「諦めない」を保証 （ハーネスの階段で 65%→87%） 3 層のメモリーをアプリが持つ（汚染対策 も） トレースと記憶を 1 つの DB に（AI が SQL で自走） 賢さ・意味判断は モデル に、一貫性・記憶・可観測性は ハーネス に。 エージェントを作るとは、ハーネスを設計すること。 59 Copyright © 2026, Oracle and/or its affiliates
60. 最初の一歩（持ち帰りロードマップ） 60 1 ツールを 1 つだけ繋ぐ（Function Calling で社内文書検索など） 2 ループを自分で書いて動かす（原理の体得・停止条件を自分で決める） 3 ゴールデン質問を 5 問作り、変更のたびに回す 4 トレースを出す（ログでも可ですが DB が推奨。スキーマはAIが考えてくれます） 5 それからフレームワーク/マネージドサービスを検討（最小・最単純から） Copyright © 2026, Oracle and/or its affiliates
61. 参考文献・リソース 書籍 A. Gulli『Agentic Design Patterns』（体系教材） 論文 Yao et al. ReAct (ICLR 2023, arXiv:2210.03629)／Shinn et al. Reflexion (NeurIPS 2023, 2303.11366)／Liu et al. Lost in the Middle (TACL 2024, 2307.03172)／Cemri et al. 2503.13657 設計ガイド Anthropic “Building Effective AI Agents” / “Effective Context Engineering”／Oracle “The Agent Loop Decoded” セキュリティ OWASP Top 10 for LLM Applications 2025／OWASP Top 10 for Agentic Applications（Memory Poisoning） Oracle 技術 Oracle AI Agent Memory／JSON-Relational Duality Views（26ai）／Unified Memory Core・OCI Observability for Agentic AI （Developers Blog） 標準 61 Model Context Protocol（modelcontextprotocol.io） Copyright © 2026, Oracle and/or its affiliates
62. Appendix：用語ミニ辞典 62 エージェントループ 推論とツール呼び出しの繰り返し Function Calling ReAct 推論と行動を交互に繰り返す基本形 Plan-Execute-Reflect 計画→実行→内省の型（本題材） ハーネス モデルを取り巻く周辺設計 決定論ゲート 構造シグナルで受理判定する安全網 LLM に道具を与える仕組み コンテキストエンジニアリング 各フェーズに最小情報を渡す設計 RAG 検索で外部知識を補う MCP AI とツールを繋ぐオープン標準 LLM-as-a-Judge LLM に採点させる評価 ゴールデンセット 不変条件で採点する回帰テスト Unified Memory Core Copyright © 2026, Oracle and/or its affiliates 記憶を 1 基盤に集める設計
63. Appendix：決定論ゲート一覧（抜粋） DEPTH（深さ補完） FORWARD（前方継続） GAP-FILL（ギャップ補完） 手順が続く間、末尾へ歩き続ける（上限4） 飛び飛び手順の内部の穴を埋める MODALITY（モダリティ網羅） 諦める前に未試行の検索手段を使い切る EXPLORE（近傍探索） 手がかりがあるのに諦める前に近傍を見る ASPECT（観点探索） 各観点を最低 1 回は専用検索する 画像網羅 explanatory は image を一度は試す 資料多様化 単一資料に collapse した誤確定を防ぐ 観点網羅（再回答） 列挙網羅（観点内・資料網羅） 非退行の受理（深掘り採用・網羅再回答） 自動昇格（ ） 送付核の保護 63 説明系は前後±1 を必ず一度見る Copyright © 2026, Oracle and/or its affiliates resolved なのに引用されない観点を1回再回答 回答に未反映の列挙項目・資料が残る間、有界で再回答 被覆が厳密に増えたときだけ差し替え（改悪で上書きしない） answerable=false ∨ 引用 0 で即昇格・他は昇格寄り評価器の助言（1 回限り） 解決値・列挙根拠のページは送付の切り詰めから保護（総量は天井で有界）