※ 本記事は、Daniela Pavlencoによる”Image-Aware AI Agent Memory: From Visual Inputs to Searchable Context“を翻訳したものです。
2026年11月8日
Oracle AI Agent Memory 26.8は、永続的なエージェントメモリをテキスト以外にも拡張し、企業向けエージェントのメモリ層に視覚的なコンテキストを取り込みます。アプリケーションは、画像を永続的な文書レコードとして保存し、メッセージに添付し、説明やキャプションで検索できます。元画像を描画、調査、転送する必要がある場合にだけ、バイトデータを明示的に要求します。
本記事は、画像対応メモリの処理経路に焦点を当てます。視覚的な証拠をどう取り込み、Oracle AI Databaseに永続化し、説明やキャプションで検索可能にするか、通常の取得では画像のバイトデータを省いて軽量に保つ理由、必要なときに元の画像データを明示的に読み込む方法を説明します。
関連ノートブック:画像対応AIエージェントメモリ
主なポイント
- Oracle AI Agent Memory 26.8は、管理対象のDOCUMENT表に、視覚的な証拠を画像レコードとして永続化できます。
- 画像は単独のレコードにも、テキスト部分と画像部分を順序付きで持つMESSAGEコンテンツの一部にもできます。
- 画像検索はテキストベースです。説明やキャプションを検索用の表現として使います。
- 通常の読取りではバイトデータを返しません。これは想定どおりの、企業向けの中核的な動作です。
- 元画像の描画や転送が必要な場合は、include_bytes=Trueで明示的にバイトデータを取得します。
- 関連ノートブックは、生成したサポート用の証拠画面を使い、画像の処理経路全体を実演します。

画像対応メモリのワークフロー
| リリースの機能 | 変更点 | 重要な理由 |
|---|---|---|
| 画像のDOCUMENTレコード | バイトデータ、MIMEタイプ、説明、メタデータ、状態とともに、管理対象メモリスキーマへ画像を永続化できる。 | 視覚的な証拠を、永続的なコンテキストとして保てる。 |
| メッセージの画像部分 | MESSAGEに、順序付きのテキスト部分と画像部分を含められる。 | ユーザーメッセージと一緒に渡された画面や画像を保持できる。 |
| テキストによる画像取得 | 画像に関連する説明やキャプションで検索する。 | 自然言語で関連する視覚的な証拠を取得できる。 |
| デフォルトでのバイトデータ省略 | 要求がなければ元画像のバイトデータを返さない。 | 通常の取得が軽くなり、意図せずバイナリをエージェントのコンテキストに流すのを避ける。 |
| 明示的なバイトデータの読込み | include_bytes=Trueで要求する。 | 表示、転送、監査に必要な元画像を利用できる。 |
| 実行時の検証 | 永続化やモデル処理の前に画像を検証する。 | 設定可能な制限を持つ、より安全な取込み経路になる。 |
画像対応メモリが重要な理由
永続メモリは、会話のターンやセッションをまたいでエージェントを役立てますが、多くの企業業務はテキストだけではありません。顧客はエラー画面を添付し、現地技術者は製品画像をアップロードし、財務ワークフローには領収書が含まれるかもしれません。テキストしか保存しないと、後の判断で重要になる視覚的な証拠を失うおそれがあります。たとえば後のサポート会話で、以前のエラー状態に言及しても、元の視覚コンテキストがなければ、参照を正しく解釈する証拠を持っていない可能性があります。
画像対応メモリは、視覚的な証拠を永続的なコンテキストに変えて、この不足を補います。重要な設計判断は、検索のたびに元画像のバイトデータを返す必要はないということです。データベースに保存し、テキスト表現で検索し、アプリケーションが明示的に求めた場合だけバイトデータを読み込めます。
画像対応メモリの仕組み
画像入力、文書の永続化、検索用の表現、制御された読取りという4つの層で考えると分かりやすくなります。
| 層 | 技術的な動作 | ノートブックでの確認 |
|---|---|---|
| 入力 | バイトデータ、MIMEタイプ、説明、メタデータ、スコープを渡す。 | PNGを生成し、image_bytesをadd_image_asyncに渡す。 |
| 永続化 | document_type=imageのDOCUMENT行として保存する。 | IMGDEMO268_DOCUMENTをSQLで調べ、DBMS_LOB.GETLENGTH(blob)を確認する。 |
| 検索 | 説明やキャプションを画像検索用のテキスト表現にする。 | search_async(record_types=[‘image’])が今回の画像を返す。 |
| 読取り | 通常はバイトデータを省き、明示的な読込みで返す。 | include_bytes=Falseではbytes=None、include_bytes=Trueではバイトデータの要約が返る。 |
データベースのセットアップと実行要件
関連ノートブックは、認証情報に環境変数またはColabシークレットを使うため、Autonomous AI Databaseでも、ほかのOracle AI Database環境でも同じコードを実行できます。接続プールを開く前に、python-oracledbでDeveloper Hubのプログラム識別子も設定し、データベースセッションをこのサンプルに関連付けられるようにします。
import oracledb
oracledb.defaults.program = "devrel-developerhub-image-aware-agent-memory"
管理対象のメモリストアを初期化する
画像対応メモリは、ほかのAgent Memoryワークフローと同じ管理対象ストアのパターンを使います。ノートブックでは、ストアが管理対象オブジェクトを作れるのか、既存スキーマを使う必要があるのか分かるよう、スキーマポリシーを明示します。オブジェクト作成が可能なユーザーなら、チュートリアルではCREATE_IF_NECESSARYが便利です。本番起動時には、スキーマ変更は意図的に行うべきなので、REQUIRE_EXISTINGの方が安全です。
schema_policy = (
SchemaPolicy.REQUIRE_EXISTING
if MANAGED_SCHEMA_EXISTS
else SchemaPolicy.CREATE_IF_NECESSARY
)
store = OracleDBMemoryStore(
pool=db_pool,
embedder=embedder,
memory_store_id=CONFIG["MEMORY_STORE_ID"],
schema_policy=schema_policy,
search_strategy=SearchStrategy.VECTOR,
vector_dim=CONFIG["MEMORY_EMBEDDING_DIMENSION"],
)
サポートの証拠となる模擬画像を生成する
顧客の画面を読み込まず、ノートブック内で画像を作ります。これにより、再現可能で安全に公開できる例になります。画像は、決済処理のタイムアウト急増、重大度、リージョン、推奨する次の対応というサポート案件を模擬します。後続の処理への視覚入力であり、AIが生成した回答ではありません。
単独の画像レコードを保存する
最初の書込みでは、生成画面を単独の画像レコードとして保存します。user_idとagent_idで範囲を限定しますが、スレッドには関連付けません。これは意図的で、まず独立した画像メモリ、次にメッセージに付随する画像を示すためです。
stored_image_id = await memory.add_image_async(
image=image_bytes,
description=image_description,
mime_type=ImageMimeType.PNG,
image_id=DEMO_CONFIG["image_id"],
user_id=DEMO_CONFIG["user_id"],
agent_id=DEMO_CONFIG["agent_id"],
metadata={
"demo": "image-aware-memory",
"case_id": DEMO_CONFIG["case_id"],
"image_id": DEMO_CONFIG["image_id"],
"region": DEMO_CONFIG["region"],
"severity": DEMO_CONFIG["severity"],
},
)
DOCUMENT行を調べる
正常に永続化したことを確認するため、保存したレコードIDで管理対象のDOCUMENT表を問い合わせます。document_typeがimageであることと、DBMS_LOB.GETLENGTH(blob)で画像のバイトデータがOracle AI Databaseにあることを確認します。
SELECT
record_id,
document_type,
description,
DBMS_LOB.GETLENGTH(blob) AS byte_length,
status,
JSON_SERIALIZE(metadata RETURNING VARCHAR2(4000)) AS metadata_json
FROM IMGDEMO268_DOCUMENT
WHERE record_id = :record_id
テキストで画像レコードを検索する
画像検索は、画素を直接比較するのではなく、保存した画像に関連する説明やキャプションを使います。それらを索引付けし、自然言語の問合せで関連画像を取得します。
image_results = await memory.search_async(
query="Which image evidence shows checkout timeout spikes in eu-frankfurt-1?",
record_types=["image"],
user_id=DEMO_CONFIG["user_id"],
agent_id=DEMO_CONFIG["agent_id"],
metadata_filter={"image_id": stored_image_id},
max_results=5,
)
(訳注:”Which image evidence shows checkout timeout spikes in eu-frankfurt-1?” eu-frankfurt-1でチェックアウト処理のタイムアウトが急増していることを示す画像はどれですか?)
metadata_filterによって、ノートブックを繰り返しても今回の結果だけを確認できます。なければ、同じストアにある過去のデモ画像も一致する可能性があります。期待する出力はmatched_current_demo_image=Trueです。
デフォルトの読取りでは元画像のバイトデータを省く
画像の読取りは、デフォルトでは元のバイトデータをロードせず、レコード情報を返します。バイナリを転送せず、説明やメタデータにアクセスできます。ノートブックのbytes=Noneは応答から省かれたことを示し、元画像は引き続きデータベースに格納されています。
images_without_bytes = await memory.list_images_async(
image_id=stored_image_id,
user_id=DEMO_CONFIG["user_id"],
agent_id=DEMO_CONFIG["agent_id"],
include_bytes=False,
)

デフォルトの読み出しと、明示的なバイトデータの読込みの比較
この動作は企業アプリケーションで特に重要です。通常の検索と読取りから元のバイトデータを省くことで、結果を小さく、速くし、不要な場所に画像データを送るリスクを減らします。元画像をいつ表示、転送、調査するかも、明確に制御できます。
説明、キャプション、メタデータ、識別子などの検索可能なコンテキストと、画像バイナリ自体を分離します。大容量または機密性の高い画像データを、すべての取得経路で動かさずに、視覚的な証拠をメモリで使えます。
バイトデータを明示的に読み込む
元画像の表示や転送が必要なときは、バイトデータを明示的に要求します。ノートブックではinclude_bytes=Trueを使い、バイナリ全体を出力せず、短い要約を表示します。
images_with_bytes = await memory.list_images_async(
image_id=stored_image_id,
user_id=DEMO_CONFIG["user_id"],
agent_id=DEMO_CONFIG["agent_id"],
include_bytes=True,
)
メッセージに画像の証拠を添付する
2つ目の経路では、メッセージに視覚的な証拠を添付し、順序付きのマルチモーダルMESSAGEを示します。ユーザーメッセージは、テキスト部分の後に画像部分を持ち、ノートブックは、message_idにひも付いたDOCUMENT行として画像が保存されることを確認します。元の会話ターンで、ユーザーの文章と画像がどう結び付いていたかを維持するため、順序が重要です。
message_content = [
TextContent(
text=f"Customer attached visual evidence for {DEMO_CONFIG['scenario']}."
)._to_dict(),
ImageContent(
bytes=image_bytes,
mime_type=ImageMimeType.PNG,
description=image_description,
)._to_dict(),
]
message_ids = await thread.add_messages_async(
[{"role": "user", "content": message_content}]
)
期待する確認結果は、submitted_text_parts=1、submitted_image_parts=1、stored_image_documents=1です。これが、マルチモーダルメッセージで画像の証拠を保持できる具体的な証明です。
| ノートブックの出力 | 技術的な意味 | 重要な理由 |
|---|---|---|
| document_type = image | 管理対象スキーマに画像レコードを保存した。 | 視覚入力を永続メモリとして表している。 |
| byte_length > 0 | 画像BLOBを永続化した。 | ノートブック内のローカルファイルだけではない。 |
| bytes = None | 通常の読取りでバイトデータを省いた。 | 通常の取得で元のバイナリを渡さない。 |
| matched_current_demo_image = True | 今回生成した画像が検索で返った。 | 説明に基づく画像検索が機能している。 |
| <bytes omitted: …> | 明示的な読込みでバイトフィールドが返った。 | 必要に応じて元画像を取得できる。 |
| stored_image_documents = 1 | message_idに画像行がひも付いている。 | マルチモーダルメッセージを一貫して永続化できる。 |
ノートブックが実演すること
内部で生成した模擬的なサポート証拠画像により、処理全体を実演します。視覚的な証拠を作り、管理対象画像レコードとして永続化し、データベースに裏付けられたDOCUMENT行を確認し、テキストで検索し、通常の取得を軽量に保ち、描画や転送が必要な場合だけバイトデータを読み込む方法を示します。
安定した公開ワークフローである、保存、メタデータ、検索、通常時のバイトデータ省略、明示的な読込み、マルチモーダルメッセージの永続化に、意図的に焦点を絞っています。
- oracleagentmemory 26.8をインストールして確認する。
- シリーズのほかのノートブックと同じ認証情報のパターンで、Oracle AI Databaseに接続する。
- 明示したSchemaPolicyで、管理対象スキーマを初期化またはアップグレードする。
- 顧客データを含めず、模擬のサポート証拠画像を生成する。
- 説明とメタデータ付きの管理対象画像レコードとして保存する。
- DOCUMENT内に永続化され、バイトデータがデータベースに格納されていることを確認する。
- 説明やキャプションに対する意味検索で画像を探す。
- 通常の読取りでバイトデータが省略されることを示す。
- 画像データが必要な場合に、明示的に読み込む。
- マルチモーダルメッセージに画像を添付し、テキストと画像の会話上の順序を保つ。
企業向けの画像メモリのパターン
画像対応の経路が有用なのは、企業で通常個別に制御すべき、永続的な画像保存、検索用テキスト表現、元のバイトデータへのアクセスという3つを分離するためです。画像はOracle Databaseに保持し、説明やキャプションを検索に使い、要求がない限り通常の検索結果にバイトデータを流しません。
これにより、サポート自動化、運用、文書の多い業務、視覚的な証拠を覚えるコパイロットで、毎回の検索を巨大なバイナリにせず画像メモリを使えます。ユーザー、エージェント、案件、テナント、ワークフローのメタデータで範囲を限定できます。ただし、これは検索の絞込みであり、認可の代わりではありません。誰が保存、検索、元画像の読込みをできるかは、アプリケーションで制御すべきです。
- ローカルファイルや一時的なアップロード状態に頼らず、管理対象のDOCUMENTレコードとして画像を永続化する。
- 説明やキャプションを検索用の表現にする。
- メタデータで適切なユーザー、エージェント、案件、テナント、ワークフローに範囲を限定する。
- 通常はバイトデータを省き、取得を軽量に保つ。
- 元画像の表示、転送、調査が必要な場合に明示的に読み込む。
- 特定の会話ターンに属する視覚的な証拠は、メッセージに添付する。
まとめ
画像対応メモリは、企業エージェントで視覚コンテキストを使う実践的なパターンを提供します。Oracle AI Databaseで画像を永続化し、説明やキャプションをテキストの検索表現とし、通常の取得から元のバイトデータを外します。実際のアプリケーションでは、メモリの読取りを毎回重く、危険で、管理しにくいものにせず、視覚的な証拠を記憶する必要があるため、この組合せが重要です。
関連ノートブックは、再現可能なサポート証拠のシナリオで中核の処理を示します。画像生成、保存、データベースでの永続化確認、意味検索による取得、通常の読取りでバイトデータを読み込まないことの確認、必要時の明示的な読込み、順序付きマルチモーダルメッセージへの添付を行います。各手順は、本番ワークフローでも再利用できる動作に対応します。
サポートエージェント、運用コパイロット、ワークフローアシスタント、案件管理システムを作るチームにとって、画面、フォーム、領収書、製品写真などを長期的なメモリの一部にできるということです。エージェントは視覚コンテキストのテキスト表現から検索、推論し、元画像をいつ取得、表示するかはアプリケーションが制御します。
今回のリリースは、Oracle AI Agent Memoryをテキストだけから、より豊富な企業コンテキストへ進めます。グラフ対応の検索は事実の時間的な変化を捉え、画像メモリは、その事実がなぜ重要かを説明することの多い視覚的証拠を捉えます。両方により、発言だけでなく、仕事の背後にある証拠、状態、履歴も記憶するエージェントを構築できます。
よくある質問
エージェントのメッセージに画像を添付できますか
はい。順序付きのテキストと画像を含む、マルチモーダルなメッセージに対応します。サポートの画面、フォーム、領収書、製品写真など、画像が会話の文脈に属するときに役立ちます。
画像のバイトデータはどこに保存されますか
Oracle AI Databaseの管理対象文書レコードに永続化します。毎回バイトデータを返さなくても、メタデータや説明を検索、確認できます。
何によって画像を検索できるのですか
呼出し側が提供する説明や、生成したキャプションなど、画像に関連するテキストを使います。エージェントは、意味に基づくテキスト問合せで視覚的な証拠を取得できます。
画像検索は画素を直接比較しますか
いいえ。ノートブックでは、説明やキャプションを使うテキストベースの検索を実演します。
bytesがNoneになる理由は何ですか
通常の読取りでは、意図的にバイトデータを省くためです。結果を小さくし、明示的に要求されない画像データを移動しないようにします。
include_bytes=Trueはいつ使うべきですか
元画像の描画、転送、調査が必要で、呼出し側にアクセス権がある場合だけ使ってください。
なぜデフォルトで元の画像データを省くのですか
結果を小さく、速く、管理しやすくするためです。元画像が必要なときに限り、明示的に読み込めます。
生成キャプションや抽出処理とも組み合わせられますか
はい。説明は、呼出し側が与えても、画像を扱えるモデルを使うアプリケーション処理で作っても構いません。ノートブックの実行例は、安定した保存、検索、通常のバイトデータ省略、明示的な読込み、マルチモーダルメッセージの永続化に焦点を当てます。
