Oracle AI Database Private Agent Factory 26.4 を 26.7 へ Upgrade してみてみた

Last updated at 2026-08-25Posted at 2026-08-24

Oracle AI Database Private Agent Factory 26.4 を 26.7 へ Upgrade してみてみた

Oracle AI Database Private Agent Factory（PAF）26.7 がリリースされました。

リリース 26.7 の主な新機能

エージェント間（A2A）コラボレーション：承認済みの外部エージェントをエージェント・ビルダーのワークフローに接続し、新しい外部ノードを介してサブタスクを委任できます。公開したエージェントを承認済みの A2A 呼び出し元と共有することもできます。
エージェント・メモリ：設定可能・検査可能・消去可能なワークフロー・レベルのメモリにより、チャット全体にわたって状況に応じた事実、好み、ガイドラインを保持します。
IDおよびアクセス管理（IAM）：ユーザー・グループを管理し、閲覧者・編集者・管理者といったロールを明示的に割り当てて、特定のデータ・ソース、モデル、ツールへのアクセスを保護します。
モデル・プロバイダの拡張：Anthropic、Azure OpenAI、OpenRouter、Oracle Private AI Services のサポートが追加されました。
キャンバス機能の強化：ビジュアル・キャンバス上での元に戻す／やり直し、エージェント仕様ファイルとしてのワークフローの Export / Import、Web 検索・メール・Slack 用のデータベース内ツール・ノードなどが含まれます。

前回作成した PAF 26.4 の構築記事は、その時点の Marketplace を利用した記録としてそのまま残します。

前回の記事：Oracle AI Database Private Agent Factory 26.4 を構築してみてみた

PAF 26.7 のドキュメントとインストール・キットは公開されていますが、筆者が 2026年8月18日（JST） に確認した OCI Marketplace の画面では 26.7 が見当たりませんでした。

一方、PAF 26.7 の Upgrade Guide には、既存の Marketplace インスタンスへ最新のインストール・キットを持ち込み、既存環境を維持したまま Upgrade する手順が用意されています。

PAF 26.7では、Agent Memory、A2A、IAM、Agent Builder、Model / Data Source、運用機能まで大きく拡張されています。
ということで、新しい Marketplace Stack を作り直すのではなく、前回作成した既存の PAF 26.4 環境を活かしたまま 26.7 へ Upgrade してみてみます。

なお、今回の検証では最初の Upgrade で Podman / SELinux に起因するコンテナ・イメージ Build エラーにも遭遇しました。原因の切り分けから復旧、再 Upgrade 成功まで確認できたため、後半の「おまけ 1」にトラブルシューティングとしてまとめています。

■ はじめに

● PAF 26.7 のリリース

PAF 26.7 の User's Guide は Release 26.7 / August 2026 として公開されています。リリース日は 2026年8月14日 と記載されています。

Oracle の公式ダウンロード・ページでは、次の 26.7 インストール・キットが公開されています。

アーキテクチャ	公式ダウンロード・ページ上のキット
Linux x86-64	`oracle_agent_factory_X86_26.7.0.tar.gz`
Linux ARM64	`oracle_agent_factory_arm64_26.7.0.tar.gz`

今回、Software Delivery Cloud から実際にダウンロードされた x86-64 版のファイル名は次でした。

oracle_agent_factory_x86_26.7.0.tar.gz

Linux ではファイル名の大文字・小文字を区別するため、以降のコマンドでは実際に取得したファイル名を使用します。

● PAF 26.7 の主な更新内容

PAF 26.7 では、単に Version が更新されたのではなく、Agent の作り方、Agent 間連携、権限管理、Model、Data Source、運用方法まで幅広く機能が拡張されています。

公式の What's New では、26.7 の更新内容は大きく Main Features、Agent Builder、Data Source / Knowledge Agent、User Experience などに分けて紹介されています。

今回の Upgrade にあたり、特に気になった更新を整理すると次のとおりです。

観点	PAF 26.7 の主な更新	ポイント
Agent の会話・連携	Oracle Agent Memory / Agent-to-Agent Collaboration	会話の Context を保持する Memory と、Agent2Agent（A2A）Protocol による外部 Agent 連携が追加
Security / Governance	Identity and Access Management	User、Group、Role、Resource Access を PAF 内で管理できるように強化
Deployment / 運用	Container Image Deployment / Linux Support 拡大 / CLI	Container Image からの Production Deployment、Ubuntu / RHEL 対応、CLI Administration が追加
Model	Model Provider Support 拡大	Private AI Services、OpenAI Compatible、Anthropic、Azure OpenAI、OCI Generative AI Dedicated Model などに対応
Agent Builder	新しい Node を多数追加	Data Analysis Agent、Deep Data Research Agent、Oracle Database、File System、Jira、Vision、Image Input、URL Crawler、External Agent などを Workflow から利用可能
Data / Knowledge	OCI Object Storage / Knowledge Agent 強化	OCI Object Storage を Data Source として利用でき、`.doc` / `.pptx` 対応や Knowledge Agent の Model 選択も強化
Workflow / 外部連携	Agent Spec / API Key Integration など	Workflow の Export / Import、Version 管理、API Key を使った外部 Application からの Agent 利用などを強化

この中でも、個人的に大きいと感じるのは Agent Memory、A2A、IAM、Agent Builder Node の拡張です。

これまでのように PAF 内で Agent や Workflow を作成して利用するだけでなく、

会話 Context を保持する
        +
Agent 同士を連携する
        +
User / Group / Role でアクセスを管理する
        +
Database / Jira / File / Vision / External Agent などを
Workflow の Node として組み合わせる

という方向へ機能が広がっています。

実際に 26.7 へ Upgrade した画面でも、左メニューに A2A Agents や Resource Management など、26.4 にはなかった機能を確認できます。

なお本稿では 26.7 の新機能そのものをすべて検証するのではなく、既存の PAF 26.4 環境を 26.7 へ安全に Upgrade し、既存の Model、Data Source、Agent などが引き継がれることを主な検証対象とします。26.7 の各新機能については、Upgrade 後の環境を使って別途確認していきます。

● Marketplace の表示と実際の Upgrade

OCI Marketplace へ新しいバージョンが反映されるタイミングと、ドキュメントやインストール・キットの公開タイミングが一致しない場合があります。

ただし、PAF 26.7 の Upgrade Guide には Upgrade Your Marketplace Instance が用意されており、既存の Marketplace VM に新しい Staging Directory を作成して Upgrade できます。

今回は、新しい Marketplace Stack を作り直すのではなく、次の流れで既存環境を更新します。

PAF 26.4 Marketplace Instance
        |
        | 26.7 Installation Kit を配置
        v
新しい Staging Directory を作成
        |
        | Podman / SELinux を事前確認
        v
interactive_install.sh
        |
        | Container Image Build
        | Database Snapshot / Migration
        | Knowledge Agent Upgrade
        v
PAF 26.7
        |
        | Version / Model / Data Source / Agent を確認
        v
Upgrade 完了

● 今回の Upgrade で特に確認すること

PAF 26.7 の Upgrade Guide では、26.4 以前から 26.7 以降へ Upgrade した場合の検証として、Version だけでなく次の確認が案内されています。

Login
Model Management の Generative / Embedding Model
Data Sources
Published Agent または Agent Builder Flow
Diagnostics Bundle

本稿でも、単に Version が 26.7.0.0.0 になったことだけではなく、既存設定と実利用まで確認します。

■ 本稿の対象環境

項目	内容
Upgrade 元	PAF 26.4.0.0.0
Upgrade 先	PAF 26.7.0.0.0
Marketplace 確認日	2026年8月18日（JST）
Upgrade 実施日	2026年8月19日
導入方式	OCI Marketplace
OS	Oracle Linux Server 8.10
CPU	8
Memory	31 GiB
接続ユーザー	`opc`
コンテナ・ランタイム	Rootless Podman 4.9.4-rhel
CPU Architecture	`x86_64`
既存 Staging Directory	`/u01/staging`
新規 Staging Directory	`/u01/staging_upgrade_26_7`
PAF URL	`https://<PAF_HOST>:8080/agentFactory/`

Upgrade 中は PAF の停止時間が発生するため、メンテナンス時間を確保して実施します。
Upgrade 作業は root ではなく、既存環境と同じ opc ユーザーで実行します。
新しいキットは、既存の Staging Directory へ展開しません。
Upgrade 前に OCI Boot Volume Backup を取得します。
Marketplace 環境では、26.7 の公式 Upgrade Guide に従い、Installer 実行前に SELinux を一時的に Permissive へ変更します。

■ Upgrade の設計を先に理解

コマンドを実行する前に、今回の Upgrade で「何を変えて、何を残すのか」を整理します。

● 今回は VM を作り直さず、既存 Marketplace Instance を更新する

今回の目的は、新しい Marketplace Stack を作成することではありません。

既存の PAF 26.4 Marketplace Instance に 26.7 Installation Kit を配置し、既存の Metadata、Database、Model、Data Source、Agent などを引き継いだまま Upgrade します。

既存 PAF 26.4 VM
      |
      | 26.7 Installation Kit
      v
新しい Staging Directory
      |
      | interactive_install.sh
      v
26.7 Image Build
      |
      | Database Snapshot / Migration
      | Knowledge Agent Upgrade
      v
PAF 26.7

つまり、今回守りたいものは VM そのものではなく、PAF の構成とデータです。

● 旧 Staging Directory と新 Staging Directory を分ける理由

Upgrade 元の /u01/staging には、現在稼働している 26.4 の管理情報があります。26.7 の Kit は別の /u01/staging_upgrade_26_7 へ展開します。

/u01/staging
  -> 26.4 の既存環境

/u01/staging_upgrade_26_7
  -> 26.7 Upgrade 用

このように分離しておくことで、Upgrade 失敗時にも旧環境と新環境のログやファイルを切り分けやすくなります。

● Backup は 2 層で考える

今回の Upgrade では、復旧手段を次の 2 層で用意します。

層	目的	今回の対策
OCI / VM 層	VM 全体を戻せるようにする	Boot Volume Backup
PAF / Database 層	Upgrade 中の DB 変更に備える	Installer の Database Snapshot

Installer が Database Snapshot を取得するからといって、VM レベルの Backup を省略しない構成にしています。

● Installer が実行する処理を先に理解する

今回の実機ログでは、interactive_install.sh は大きく次の順番で処理しました。

1. 既存 Metadata を検出
2. 26.7 Container Image を Build
3. 既存 26.4 Container を停止
4. Database Snapshot を取得
5. Database Wallet / Schema を Migration
6. Knowledge Agent / Deep Research Agent を Upgrade
7. 26.7 Container を起動
8. Production deployment を完了

この流れを理解しておくと、途中で失敗した場合に「Build の問題なのか」「DB Migration の問題なのか」「起動後の問題なのか」を切り分けやすくなります。

● Upgrade 成功は 3 段階で判定する

Installer の最後に [SUCCESS] Upgrade flow completed. と表示されただけでは、Upgrade 成功とは判断しません。今回の検証では、次の 3 段階で確認します。

確認レイヤー	確認内容	成功条件
Installer	Build / Migration / Deployment	各処理が `Successful` / `SUCCESS`
Host	Container / HTTP	起動 Image が `26.7.0.0.0`、HTTP 応答あり
Application	UI / Model / Data Source / Agent	Version と既存構成、実利用が正常

これは今回の 1 回目の Upgrade で、26.7 Build に失敗して 26.4 へ Recovery したあとにも [SUCCESS] Upgrade flow completed. と表示されたためです。

● Upgrade の全体手順

以上を踏まえ、次の順番で進めます。

Upgrade 前のベースラインを記録する
PAF の論理構成を記録する
OCI Boot Volume Backup を取得する
PAF 26.7 Installation Kit を取得する
新しい Staging Directory を作成して Kit を展開する
Rootless Podman / SELinux を事前確認する
interactive_install.sh を実行する
Host 側で 26.7 の起動を確認する
PAF UI で Version を確認する
既存設定と Agent の実利用を確認する
Diagnostics Bundle を取得する
Upgrade 前後の結果をまとめる

■ 1. Upgrade 前のベースラインを記録

ここでは「Upgrade 前に正常だった状態」を残します。Upgrade 後に問題が出たとき、OS / Disk / Podman / HTTP のどこから差分が発生したかを判断するための基準値になります。

● PAF の Version を確認

PAF へ Administrator でログインし、About 画面から Version が 26.4 であることを確認します。

● Marketplace の表示を確認

2026年8月18日（JST）に確認した OCI Marketplace の画面も記録しておきます。

「Marketplace に 26.7 が存在しない」と一般化せず、筆者が確認した日時と環境での表示として記録しています。

● OS とアーキテクチャを確認

PAF VM へ SSH 接続します。

export SSH_KEY="$HOME/.ssh/<private_key_file>"
export PAF_HOST="<PAF_VM_PUBLIC_IP_OR_FQDN>"

ssh \
  -i "$SSH_KEY" \
  -o ServerAliveInterval=60 \
  -o ServerAliveCountMax=5 \
  "opc@${PAF_HOST}"

VM 側で確認します。

date
hostname -f
uname -m
cat /etc/os-release

実行結果です。

[opc@paf-264-server ~]$ date
Tue Aug 18 13:45:20 GMT 2026

[opc@paf-264-server ~]$ hostname -f
<PAF_VM_FQDN>

[opc@paf-264-server ~]$ uname -m
x86_64

[opc@paf-264-server ~]$ cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.10"
VERSION_ID="8.10"
PRETTY_NAME="Oracle Linux Server 8.10"

対応する Kit は次です。

`uname -m`	使用する Kit
`x86_64`	x86-64 版
`aarch64` / `arm64`	ARM64 版

今回の環境は x86_64 のため、x86-64 版の Kit を使用します。

● CPU、Memory、Disk を確認

nproc
free -h
df -h / /u01 /tmp

[opc@paf-264-server ~]$ nproc
8

[opc@paf-264-server ~]$ free -h
              total        used        free      shared  buff/cache   available
Mem:           31Gi       6.0Gi        19Gi        73Mi       5.8Gi        24Gi
Swap:         7.4Gi        72Mi       7.4Gi

[opc@paf-264-server ~]$ df -h / /u01 /tmp
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/ocivolume-root  139G   33G  107G  24% /

新しい Kit の展開、コンテナ・イメージ、Database Snapshot、ログなどに使用できる空き容量があることを確認します。

● Podman の状態を記録

podman version

podman ps --format \
  'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

podman images --format \
  'table {{.Repository}}\t{{.Tag}}\t{{.Created}}\t{{.Size}}'

[opc@paf-264-server ~]$ podman version
Client:       Podman Engine
Version:      4.9.4-rhel
OS/Arch:      linux/amd64

[opc@paf-264-server ~]$ podman ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
NAMES                    IMAGE                                  STATUS      PORTS
oracle-applied-ai-label  localhost/applied-ai-label:26.4.0.0.0  Up 2 days   0.0.0.0:8080->8080/tcp

Upgrade 前の情報を保存します。

mkdir -p "$HOME/paf_upgrade_26_7_record"
chmod 700 "$HOME/paf_upgrade_26_7_record"

podman ps --all --no-trunc \
  > "$HOME/paf_upgrade_26_7_record/podman-ps-before.txt"

podman images --no-trunc \
  > "$HOME/paf_upgrade_26_7_record/podman-images-before.txt"

● PAF の応答を確認

ss -lnt | grep ':8080'

LISTEN 0      4096               *:8080             *:*

VM 内から PAF URL を確認します。

curl -k -sS -o /dev/null \
  -w 'HTTP %{http_code}\n' \
  https://localhost:8080/agentFactory/

HTTP 200

● Metadata の存在を確認

Metadata の内容には環境情報が含まれるため、Blog では内容を表示せず存在だけを確認します。

METADATA_FILE="$HOME/.local/state/Oracle/AgentFactory/metadata.json"

if [[ -f "$METADATA_FILE" ]]; then
  echo "metadata.json: found"
else
  echo "metadata.json: not found"
fi

metadata.json: found

■ 2. PAF の論理構成を記録

Host が起動していても、Model、Data Source、Agent などの論理構成が引き継がれていなければ Upgrade 完了とはいえません。ここでは Upgrade 後に比較する対象を先に確定します。

Upgrade 前後で比較するため、PAF UI の状態を記録します。

● Upgrade 前の確認表

確認項目	Upgrade 前
PAF Version	26.4.0.0.0
User 数	1
Generative Model 数	1
Embedding Model 数	2
Data Source 数	3
Knowledge Agent / Knowledge Base	標準: 1 / ユーザー作成: 0
Data Analysis Agent 数	0
Custom Flow 数	0
Published Agent / Flow	1（Knowledge Assistant の API Endpoint を確認）

● Model Management

Upgrade 前の Model Configuration を確認します。Generative Model は PAF_OCI_GENAI_CHAT、Embedding Model は 2 件です。

● Data Sources

Database Data Source は 3 件で、いずれも Connected です。

● Knowledge Agent / Custom Flow

Knowledge Agent は標準の次の 1 件でした。

Oracle AI Database Private Agent Factory Knowledge Assistant

Custom Flow は My Custom Flows で 0 件でした。

Published 状態は、Knowledge Assistant の Integration options に API Endpoint URL が表示されることで確認しました。

■ 3. 復旧できる状態を作る

Upgrade では Database Migration や Container Image の切り替えが発生します。問題が起きた場合に「調査を続ける」か「VM を戻す」かを選べるように、作業前に復旧ポイントを作ります。

PAF Installer は Upgrade 中に Database Snapshot を作成しますが、VM レベルでも復旧手段を準備します。

● OCI Boot Volume Backup

OCI Console から Boot Volume Backup を作成します。

OCI Console
  > Compute
  > Instances
  > 対象の PAF VM
  > Boot volume
  > Create boot volume backup

Backup 名は次のようにしました。

paf-26-4-before-upgrade-to-26-7-20260818

Available になったことを確認します。

今回 Custom Flow は 0 件だったため Flow Export の実作業はありませんでした。重要な Custom Flow が存在する環境では、Upgrade 前に .paf として Export しておくと安心です。

■ 4. Upgrade に使用する 26.7 Kit を確定

ここで確認したいのは「最新 Kit を持っていること」だけではなく、VM の CPU Architecture と一致する Kit を使うことです。今回の VM は x86_64 のため x86-64 版を使用します。

Oracle の公式ダウンロード・ページから、VM の Architecture に合う 26.7 Kit を取得します。

https://www.oracle.com/database/technologies/private-agent-factory-downloads.html

License Agreement を確認し、x86-64 版をダウンロードします。

今回ダウンロードされたファイルは次です。

oracle_agent_factory_x86_26.7.0.tar.gz

● Kit を PAF VM へ転送

今回は wget.sh ではなく、ローカル端末へダウンロード済みの .tar.gz を直接 scp しました。

ローカル端末で実行します。

scp \
  -i "$SSH_KEY" \
  oracle_agent_factory_x86_26.7.0.tar.gz \
  "opc@${PAF_HOST}:~/"

26.7 の Marketplace Upgrade Guide では wget.sh を利用する手順も案内されています。本稿では、すでに Software Delivery Cloud から Kit を取得済みだったため、.tar.gz を直接転送しています。

■ 5. Upgrade 用 Staging Directory を分離して Kit を展開

旧 /u01/staging は 26.4 の既存環境として残し、26.7 は別 Directory へ展開します。Upgrade に失敗したときに旧環境と新環境を混在させないためです。

● 新しい Staging Directory を作成

既存の /u01/staging は再利用せず、Upgrade 専用の Directory を作成します。

sudo mkdir -p /u01/staging_upgrade_26_7
sudo chown opc:opc /u01/staging_upgrade_26_7
chmod 750 /u01/staging_upgrade_26_7

cd /u01/staging_upgrade_26_7
pwd

/u01/staging_upgrade_26_7

新しい Staging Directory は既存の Staging Directory とは分けます。また、NFS Mount 上へ作成しません。

● Kit を Staging Directory へ配置

VM の Home Directory へ転送した Kit をコピーします。

cp \
  "$HOME/oracle_agent_factory_x86_26.7.0.tar.gz" \
  /u01/staging_upgrade_26_7/

cd /u01/staging_upgrade_26_7
ls -lh oracle_agent_factory_x86_26.7.0.tar.gz

実機では約 2.3 GB でした。

● SHA-256 を記録

Oracle Software Delivery Cloud の View Digest Details と比較できるように、VM 側でも SHA-256 を取得しておきます。

sha256sum oracle_agent_factory_x86_26.7.0.tar.gz \
  | tee "$HOME/paf_upgrade_26_7_record/oracle_agent_factory_x86_26.7.0.tar.gz.sha256"

● Installation Kit を展開

tar -xzf oracle_agent_factory_x86_26.7.0.tar.gz
ls -la

展開後、interactive_install.sh が存在することを確認します。

test -f interactive_install.sh \
  && echo "interactive_install.sh: found"

interactive_install.sh: found

今回の Kit では実行権限が付いていました。

■ 6. Container Image を Build できる状態か事前確認

26.7 Upgrade の最初の大きな処理は新しい Container Image の Build です。そのため、Installer を起動する前に Podman 自体が正常に Container を実行できるか確認します。

今回の環境では、Rootless Podman の graphRoot が標準の場所ではなく /scratch 配下に設定されていました。PAF 26.7 の Upgrade では新しいコンテナ・イメージを Build するため、Upgrade 前に Podman の単体実行まで確認しておきます。

● SELinux と graphRoot を確認

getenforce

podman info --format 'graphRoot={{.Store.GraphRoot}}'
podman info --format 'runRoot={{.Store.RunRoot}}'

GRAPHROOT="$(podman info --format '{{.Store.GraphRoot}}')"

echo "$GRAPHROOT"
ls -ldZ "$GRAPHROOT"
sudo ls -ldZ /var/lib/containers

今回の環境では次の状態でした。

SELinux : Enforcing

graphRoot=/scratch/podman_storage/storage/graphroot

/scratch/podman_storage/storage/graphroot
  -> unconfined_u:object_r:default_t:s0

/var/lib/containers
  -> system_u:object_r:container_var_lib_t:s0

graphRoot をカスタム・パスへ変更している一方、SELinux Type が default_t になっていました。

Red Hat の Knowledge Base でも、Rootless Podman の graphRoot を別 Path へ変更している場合は、適切な SELinux Label を設定する必要があると案内されています。

● graphRoot の状態から対応を判断

確認結果に応じて、対応を分けます。

graphRoot	SELinux Type	対応
標準 Path	`container_var_lib_t` など Container 用 Label	追加修正せず次へ進む
カスタム Path	Container 用 Label	追加修正せず Podman 単体テストへ進む
カスタム Path	`default_t`	Label を修正してから Podman 単体テスト

今回の環境は カスタム Path + default_t だったため、次の修正を実施しました。

● `default_t` の場合は SELinux Context を修正

sudo semanage fcontext -a -e /var/lib/containers \
  "$GRAPHROOT"

sudo restorecon -R -v "$GRAPHROOT"

確認します。

ls -ldZ "$GRAPHROOT"

drwxr-xr-x. 8 opc root unconfined_u:object_r:container_var_lib_t:s0 ... /scratch/podman_storage/storage/graphroot

SELinux Type が container_var_lib_t になりました。

この修正は、カスタム graphRoot が不適切な SELinux Label になっている環境での対処です。すべての PAF 環境で無条件に実施するものではありません。

● Podman 単体テスト

PAF Installer を実行する前に、Oracle Linux 8 Container を単体で起動します。

podman run --rm \
  container-registry.oracle.com/os/oraclelinux:8 \
  /bin/sh -c 'echo "Container test: OK"'

Container test: OK

この状態で既存 PAF 26.4 も正常であることを確認します。

podman ps --format \
  'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

curl -k -sS -o /dev/null \
  -w 'HTTP %{http_code}\n' \
  https://localhost:8080/agentFactory/

oracle-applied-ai-label  localhost/applied-ai-label:26.4.0.0.0  Up ...
HTTP 200

● Marketplace Upgrade 用に SELinux を一時的に Permissive にする

PAF 26.7 の公式 Upgrade Guide では、Marketplace Deployment の Upgrade 前に次を実行するよう記載されています。

sudo setenforce permissive
getenforce

Permissive

これは Runtime の SELinux Mode を一時的に変更するもので、永続設定は変更しません。Upgrade 完了後に Enforcing へ戻します。

■ 7. PAF 26.4 から 26.7 へ Upgrade を実行

ここから実際に PAF を変更します。先に確認した Backup、Staging 分離、Podman、SELinux の条件が整ってから Installer を起動します。

● 作業開始前の最終確認

次を確認してから Installer を実行します。

OCI Boot Volume Backup が Available
PAF へのユーザー・アクセスを停止
実行中の Agent / Flow がない
新しい Staging Directory を使用
VM Architecture と Kit が一致
Podman 単体テストが成功
Marketplace 向け手順に従い SELinux が一時的に Permissive
Snapshot 用を含む Disk 空き容量がある
SSH Session が切断されにくい設定で接続している

● Installer 実行前に処理の境界を確認

実行中に注目するポイントは次の 3 つです。

1) Image Build

applied-ai-label:26.7.0.0.0

が SUCCESS になることを確認します。

2) Database / Agent Migration

Database Snapshot
Upgrade DB Migration
Knowledge Agent Upgrade
Deep Research Agent Upgrade

が Successful になることを確認します。

3) Production Deployment

✓ Production deployment complete.

まで到達することを確認します。

この 3 つを通過して初めて、Host 側の Version 確認へ進みます。

● Interactive Installer を実行

cd /u01/staging_upgrade_26_7
./interactive_install.sh

今回の環境では既存 Metadata が自動検出され、Upgrade Flow に入りました。

[INFO] Metadata detected at '/home/opc/.local/state/Oracle/AgentFactory/metadata.json'. Running upgrade flow for 'opc'.
[INFO] Ensuring ownership of '/u01/staging/applied-ai/volume'.
[INFO] Running 'make build' for upgrade.

Production Mode を選択します。

1) prod
2) quickstart
Enter choice (1 or 2): 1

You selected Production mode. Confirm? (yes/no) [yes]: yes

Marketplace 向けの 26.7 Upgrade Guide では、新しい Staging Directory で ./interactive_install.sh を実行する流れが案内されています。本稿では Marketplace 専用手順に従い、--reset は追加していません。

● 26.7 Container Image の Build 成功を確認

最初に新しい Application Image が Build されます。成功時は次のようになりました。

STEP 25/25: CMD ["prod"]
COMMIT applied-ai-label:26.7.0.0.0
Successfully tagged localhost/applied-ai-label:26.7.0.0.0

+------------------+---------+--------+-------------------------------+----------------------+---------------------------------------+
| Image            | Status  | Size   | Created                       | Image ID             | Tags                                  |
+------------------+---------+--------+-------------------------------+----------------------+---------------------------------------+
| applied-ai-label | SUCCESS | 6.5 GB | 2026-08-19T03:28:15.70080038Z | 32712e1a9d1c6b9467f4 | localhost/applied-ai-label:26.7.0.0.0 |
+------------------+---------+--------+-------------------------------+----------------------+---------------------------------------+

● Database Snapshot / Migration を確認

続いて Upgrade 処理が実行されました。

Existing metadata file found: /home/opc/.local/state/Oracle/AgentFactory/metadata.json
Starting upgrade process...
Database snapshot before upgrade is mandatory. Proceeding with snapshot.
Take Knowledge Agent (KA) tables snapshot? (Consumes additional storage) [Y/n]: [Y]
Upgrading the application to version: 26.7.0.0.0

今回の結果は次のとおりです。

+------------------------------------------------+------------+
| Stage                                          | Status     |
+------------------------------------------------+------------+
| Configuring the application                    | Successful |
| Storing App Secret Key                         | Successful |
| Database Snapshot                              | Successful |
| Database Wallet Migration                      | Successful |
| Upgrade DB Migration                           | Successful |
| Configured Version Snapshot Link               | Successful |
| Knowledge Agent Upgrade                        | Successful |
| Knowledge Agent Restart                        | Successful |
| Deep Research Agent Upgrade                    | Successful |
| Starting Oracle Private AI Agent agent_factory | Successful |
| Configured Version Link                        | Successful |
+------------------------------------------------+------------+

Metadata file check passed
✓ Production deployment complete.
[SUCCESS] Upgrade flow completed.

これで Installer 上は Upgrade 完了です。

● SELinux を Enforcing に戻す

公式手順で一時的に Permissive へ変更した場合は、Upgrade 後に戻します。

sudo setenforce enforcing
getenforce

Enforcing

戻した後も PAF と Podman が正常であることを確認します。

■ 8. Host 側で 26.7 への切り替えを確認

Installer のメッセージだけではなく、実際に起動している Container Image と HTTP 応答を確認します。これが Host レイヤーの Upgrade 成功判定です。

● 26.7 Image を確認

podman images --format \
  'table {{.Repository}}\t{{.Tag}}\t{{.Created}}\t{{.Size}}'

REPOSITORY                                    TAG         CREATED        SIZE
localhost/applied-ai-label                    26.7.0.0.0  7 minutes ago  6.99 GB
container-registry.oracle.com/os/oraclelinux  8           26 hours ago   259 MB
localhost/applied-ai-label                    26.4.0.0.0  2 months ago   6.78 GB

26.4 Image も残っていますが、実際に起動している Image を次で確認します。

● Container の起動状態を確認

podman ps --format \
  'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

NAMES                    IMAGE                                  STATUS        PORTS
oracle-applied-ai-label  localhost/applied-ai-label:26.7.0.0.0  Up 7 minutes  0.0.0.0:8080->8080/tcp

起動中の Container が 26.7.0.0.0 になっていることを確認できました。

● PAF URL を確認

curl -k -sS -o /dev/null \
  -w 'HTTP %{http_code}\n' \
  https://localhost:8080/agentFactory/

HTTP 200

■ 9. UI 側で Version 26.7 を確認

Host 側で 26.7 Container が起動していても、UI へログインできなければ利用できません。ここでは Application レイヤーの入口として Login と Version を確認します。

Browser から PAF へアクセスします。

https://<PAF_HOST>:8080/agentFactory/

Administrator でログインできることを確認します。

Upgrade 通知が表示される場合は内容を確認します。

About 画面では次を確認できました。

Version      : 26.7.0.0.0
Install date : 2026年8月19日 03:32

ホスト側と UI の両方で 26.7.0.0.0 を確認できたため、PAF 26.7 への Upgrade は成功です。

■ 10. 既存設定だけでなく実利用まで確認

設定が「一覧に存在する」ことと「実際に使える」ことは別です。Model / Data Source / Agent は件数だけでなく、Connection Test や実際の Agent 実行まで確認します。

Version だけではなく、Upgrade 前の構成が引き継がれていることを確認します。

● Administrator Login

26.4 で使用していた Administrator Account で 26.7 へログインできました。

Administrator Login : OK

● Model Management

Upgrade 前に存在した Model Configuration が引き継がれていました。

Generative Model: PAF_OCI_GENAI_CHAT
Embedding Model: 2 件

・Embedding Model の接続テスト

Embedding Model は Connection Test が成功しました。

Connection successful

・Generative Model の接続テスト

PAF_OCI_GENAI_CHAT は Configuration 自体は引き継がれていましたが、Model Management の Test connection は次の結果になりました。

Couldn't connect
Files not provided for Configuration

一方、後述のとおり、同じ Primary Configuration を使う Knowledge Assistant からは正常に回答できました。

そのため今回の結果は「Generative Model が利用できない」とは判定せず、Model Management の保存済み OCI GenAI / Instance Principal Configuration に対する Test Connection で確認した挙動として分離して扱います。詳細は「おまけ 2」にまとめます。

● Data Sources

Upgrade 前の Database Data Source は 3 件でした。26.7 の Data Sources 画面で、次を確認します。

3 件が表示されること
Status が Connected
Credential Error がないこと

● Knowledge Assistant

Upgrade 前から存在していた標準 Knowledge Assistant を実行します。確認用 Prompt は次にしました。

Oracle AI Database Private Agent Factory とは何ですか？

26.7 の Knowledge Assistant から正常に日本語回答が返り、Sources も表示されました。

Application Log でも次を確認できました。

Retrieving LLM connection entry: PAF_OCI_GENAI_CHAT
Retrieved connection details for: PAF_OCI_GENAI_CHAT
Knowledge Agent request completed | method=POST endpoint=/v1/assist status=200

つまり、Primary の PAF_OCI_GENAI_CHAT を利用した Knowledge Assistant の実行は成功しています。

● Custom Flow

Upgrade 前は Custom Flow が 0 件でした。26.7 側でもユーザー作成 Flow は 0 件であることを確認します。

Custom Flow : 0

● Published Agent / Flow

Upgrade 前は標準 Knowledge Assistant の Integration options から API Endpoint URL を確認していました。26.7 側でも同 Endpoint が表示されることを確認します。

■ 11. SSO を使用している場合の注意

PAF 26.7 の Upgrade Guide には、26.4 以前から 26.7 以降へ Upgrade する場合、必要な Role Transition のため SSO がいったん無効化される旨が記載されています。

SSO を利用している環境では、Upgrade 後に Local Administrator でログインし、Application Settings から SSO を再度有効化します。Callback URL も確認します。

https://<hostname>:8080/agentFactory/callback

今回の検証環境では Local Login を使用しているため、この作業は対象外です。

■ 12. Upgrade 後の Diagnostics を保存

正常終了時にも Diagnostics を残しておくと、後から問題が見つかった場合に Upgrade 直後の状態と比較できます。

Upgrade 後の記録として Diagnostics Bundle を取得します。

cd /u01/staging_upgrade_26_7
make diagnose

今回、追加の Model Management 調査時に取得した Bundle は次でした。

diagnose_logs/2026-08-20T11-03-09.zip

Diagnostics Archive には環境 Metadata、URL、ログ、構成情報などが含まれる可能性があります。外部共有や Blog 掲載はせず、共有が必要な場合は情報区分と社内ルールを確認します。

■ 13. Upgrade 前後を比較して完了判定

最後に「Version が変わった」だけで終わらせず、Upgrade 前に記録した構成と実利用結果を並べて完了判定します。

現時点の確認結果をまとめます。

確認項目	Upgrade 前	Upgrade 後	結果
PAF Version	26.4.0.0.0	26.7.0.0.0	✅
Administrator Login	成功	成功	✅
User 数	1	1	✅
Generative Model 数	1	1（Upgrade 直後）※調査用に後から 1 件追加	✅
Generative Model Test connection	成功	`Couldn't connect`	⚠️ おまけ 2 参照
Embedding Model 数	2	2	✅
Embedding Model Test connection	成功	成功	✅
Data Source 数	3	3	✅
Knowledge Agent / Knowledge Base	1	1	✅
Knowledge Assistant 実行	成功	成功 / HTTP 200	✅
Data Analysis Agent 数	0	0	⏳
Custom Flow 数	0	0	✅
Published Agent / Flow	1	`<Endpoint を最終確認>`	✅
Diagnostics Bundle	-	取得	✅

Model Management の Test Connection では気になる挙動がありましたが、PAF 26.7 自体の Upgrade、Application 起動、Knowledge Assistant の実利用は正常に完了しました。

■ おまけ 1：1 回目の Upgrade が失敗したときのトラブルシューティング

この章のポイントは、Error を見てすぐ PAF の問題と決めつけず、同じ現象を PAF 外の Podman 単体でも再現できるかを確認したことです。再現できたことで、調査対象を PAF から Podman / SELinux へ絞り込めました。

今回、最初の interactive_install.sh 実行では Upgrade に失敗しました。

ただし Installer が旧 26.4 を Recovery したため、最後に [SUCCESS] Upgrade flow completed. と表示され、一見成功したようにも見えました。ここはかなり注意が必要でした。

● STEP 11/25 で Image Build が失敗

1 回目は次の Error で停止しました。

STEP 11/25: RUN yum install ...

/bin/sh: error while loading shared libraries:
libtinfo.so.6: cannot change memory protections

Error: building at STEP ...

Build Summary も次のとおりです。

+------------------+--------+------+---------+----------+------+
| Image            | Status | Size | Created | Image ID | Tags |
+------------------+--------+------+---------+----------+------+
| applied-ai-label | FAILED | N/A  | N/A     | N/A      | N/A  |
+------------------+--------+------+---------+----------+------+

そのため 26.7 Image が存在せず、Deployment も失敗しました。

Error: ✗ Neither Prod Mode nor Quickstart Mode deployment is currently possible.
Missing required images.

● Installer は旧 26.4 を Recovery

その後 Installer は次の Recovery 処理に入りました。

Starting Recovery of Previous Install
...
Successfuly able to restore the previous install
...
[SUCCESS] Upgrade flow completed.

ここでの [SUCCESS] は 26.7 Deployment の成功ではなく、Upgrade Flow が Recovery まで完了したことを含む表示でした。

実際に確認すると起動中 Image は 26.4 でした。

oracle-applied-ai-label  localhost/applied-ai-label:26.4.0.0.0

このため、Upgrade 成否は最後の [SUCCESS] だけでは判断せず、少なくとも次を確認するのが重要です。

podman ps --format \
  'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

podman images --format \
  'table {{.Repository}}\t{{.Tag}}\t{{.Created}}\t{{.Size}}'

● Podman 単体でも同じ Error が再現

SELinux と Rootless Podman を調査しました。

getenforce

podman info --format 'graphRoot={{.Store.GraphRoot}}'

GRAPHROOT="$(podman info --format '{{.Store.GraphRoot}}')"

ls -ldZ "$GRAPHROOT"
sudo ls -ldZ /var/lib/containers

結果です。

Enforcing

graphRoot=/scratch/podman_storage/storage/graphroot

/scratch/podman_storage/storage/graphroot
  -> unconfined_u:object_r:default_t:s0

/var/lib/containers
  -> system_u:object_r:container_var_lib_t:s0

さらに PAF と関係なく Podman 単体で確認しても同じ Error になりました。

podman run --rm \
  container-registry.oracle.com/os/oraclelinux:8 \
  /bin/sh -c 'echo "Container test: OK"'

/bin/sh: error while loading shared libraries:
libtinfo.so.6: cannot change memory protections

ここで PAF 26.7 固有ではなく、Podman / SELinux 側の問題であることを切り分けられました。

● graphRoot の SELinux Label を修正

Red Hat の案内に沿って、カスタム graphRoot に /var/lib/containers 相当の Label を設定しました。

sudo semanage fcontext -a -e /var/lib/containers \
  "$GRAPHROOT"

sudo restorecon -R -v "$GRAPHROOT"

ls -ldZ "$GRAPHROOT"

unconfined_u:object_r:container_var_lib_t:s0

もう一度 Podman 単体テストを実行します。

podman run --rm \
  container-registry.oracle.com/os/oraclelinux:8 \
  /bin/sh -c 'echo "Container test: OK"'

Container test: OK

既存 PAF 26.4 も確認します。

oracle-applied-ai-label  localhost/applied-ai-label:26.4.0.0.0  Up ...
HTTP 200

この状態で Upgrade を再実行し、2 回目は 26.7 Image Build と Database Migration が成功しました。

COMMIT applied-ai-label:26.7.0.0.0
Successfully tagged localhost/applied-ai-label:26.7.0.0.0
| applied-ai-label | SUCCESS |

Upgrade DB Migration        Successful
Knowledge Agent Upgrade     Successful
Deep Research Agent Upgrade Successful

✓ Production deployment complete.
[SUCCESS] Upgrade flow completed.

最終的に、次のとおりとなりました。

oracle-applied-ai-label  localhost/applied-ai-label:26.7.0.0.0  Up ...
HTTP 200

現在の PAF 26.7 Marketplace Upgrade Guide には、Installer 実行前に sudo setenforce permissive を実行する手順も明記されています。本稿のメイン手順ではこの公式手順を反映しています。

今回の graphRoot Label 修正は、カスタム graphRoot が default_t になっていた実機での追加トラブルシューティングです。

● 失敗時は Diagnostics を先に取得

Upgrade に失敗した場合は、古い／新しい Staging Directory を削除せず、まず Diagnostics を取得します。

cd /u01/staging_upgrade_26_7
make diagnose

今回の失敗直後には次が生成されました。

diagnose_logs/2026-08-19T02-56-25.zip

Podman 状態も保存しておきます。

podman ps --all --no-trunc \
  > "$HOME/paf_upgrade_26_7_record/podman-ps-failure.txt"

podman images --no-trunc \
  > "$HOME/paf_upgrade_26_7_record/podman-images-failure.txt"

■ おまけ 2：OCI GenAI / Instance Principal の Test Connection を確認

この章では「設定が存在する」「Test Connection が成功する」「Agent から実利用できる」を分けて確認します。Upgrade 後の正常性は 1 つの Test 結果だけで判断しないことがポイントです。

Upgrade 後の Model Management 確認で、もう 1 つ興味深い挙動がありました。

● Upgrade された Generative Model の Test Connection が失敗

26.4 から引き継がれた PAF_OCI_GENAI_CHAT は画面上に存在していました。しかし Test connection を実行すると、次のようになりました。

Couldn't connect
Files not provided for Configuration

Application Log では次です。

LLM connection name: PAF_OCI_GENAI_CHAT
Provider: oci
Testing LLM connection for provider: oci
Invalid LLM connection input for provider=LLMProvider.OCI: Missing field: user

● 同じ設定を 26.7 で新規入力すると保存前は成功

切り分けのため、同一の OCI GenAI / Instance Principal 設定で PAF_OCI_GENAI_CHAT_267_TEST を作成しました。保存前の Test Connection は成功しました。

Testing LLM connection for provider: oci_instance_principal
Creating LLM object for OCI Instance Principal provider
Connection successful. Prompt: Hi!. Response: Hello! How can I assist you today?

● 保存して Reload すると新規設定も失敗

ところが Configuration を Save して画面を Reload したあと、同じ Configuration を再び Test すると次になりました。

Couldn't connect
Files not provided for Configuration

Application Log でも、保存前と異なり Provider が oci として Test されていました。

LLM connection name: PAF_OCI_GENAI_CHAT_267_TEST
Provider: oci
Testing LLM connection for provider: oci
Invalid LLM connection input for provider=LLMProvider.OCI: Missing field: user

● DB 上の Configuration を比較

旧設定と新規設定を DB 上で比較しました。

SELECT connection_name,
       llm_provider,
       is_primary,
       is_active,
       connection_details_json
FROM   aai_llm_connection
WHERE  connection_name IN (
         'PAF_OCI_GENAI_CHAT',
         'PAF_OCI_GENAI_CHAT_267_TEST'
       )
ORDER BY connection_name;

結果として、どちらも次の属性でした。

llm_provider     = oci
credentials_type = INSTANCE_PRINCIPAL

Model ID、Endpoint、Compartment も同一でした。

Blog へ SQL 結果を掲載する場合は、Compartment OCID などを必ず Mask します。

● Knowledge Assistant の実利用は成功

さらに切り分けるため、Primary の PAF_OCI_GENAI_CHAT をそのまま使用して Knowledge Assistant に質問しました。

Oracle AI Database Private Agent Factory とは何ですか？

画面では正常に回答が返り、Sources も表示されました。Log でも次を確認しています。

Retrieving LLM connection entry: PAF_OCI_GENAI_CHAT
Retrieved connection details for: PAF_OCI_GENAI_CHAT

Knowledge Agent request completed | method=POST endpoint=/v1/assist status=200

つまり今回の環境では、次のようになりました。

Model Management / Test connection
  -> Couldn't connect

Knowledge Assistant / 実利用
  -> 正常回答
  -> HTTP 200

このため、本稿では PAF 26.7 の保存済み OCI GenAI / Instance Principal Configuration に対する Test Connection の挙動として記録し、PAF 26.7 の Upgrade 失敗とは扱っていません。

また、Upgrade 後の正常性確認では Model Management の Test Connection だけではなく、実際の Agent からも実行確認することが重要だとわかりました。

■ 問題発生時に安易に実行しない操作

Upgrade に失敗した場合は、Diagnostics を取得する前に古い Directory や Container / Volume を削除しないようにします。

# Oracle Support や公式手順から指示されない限り安易に実行しない
make uninstall
podman rm -f <container>
podman volume rm <volume>
rm -rf <old_staging_directory>
rm -rf /u01/staging_upgrade_26_7

interactive_install.sh --reset についても、Marketplace 専用の Upgrade 手順で要求されていない状況では独自に追加しません。利用する場合は、対象 Release の公式手順または Oracle Support の指示を確認します。

■ コマンドだけをまとめる

● ローカル端末

export SSH_KEY="$HOME/.ssh/<private_key_file>"
export PAF_HOST="<PAF_VM_PUBLIC_IP_OR_FQDN>"

scp \
  -i "$SSH_KEY" \
  oracle_agent_factory_x86_26.7.0.tar.gz \
  "opc@${PAF_HOST}:~/"

ssh \
  -i "$SSH_KEY" \
  -o ServerAliveInterval=60 \
  -o ServerAliveCountMax=5 \
  "opc@${PAF_HOST}"

● PAF VM：事前確認

date
hostname -f
uname -m
cat /etc/os-release

nproc
free -h
df -h / /u01 /tmp

podman version

podman ps --format \
  'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

curl -k -sS -o /dev/null \
  -w 'HTTP %{http_code}\n' \
  https://localhost:8080/agentFactory/

● PAF VM：Staging と Kit 展開

mkdir -p "$HOME/paf_upgrade_26_7_record"
chmod 700 "$HOME/paf_upgrade_26_7_record"

sudo mkdir -p /u01/staging_upgrade_26_7
sudo chown opc:opc /u01/staging_upgrade_26_7
chmod 750 /u01/staging_upgrade_26_7

cp \
  "$HOME/oracle_agent_factory_x86_26.7.0.tar.gz" \
  /u01/staging_upgrade_26_7/

cd /u01/staging_upgrade_26_7

sha256sum oracle_agent_factory_x86_26.7.0.tar.gz \
  | tee "$HOME/paf_upgrade_26_7_record/oracle_agent_factory_x86_26.7.0.tar.gz.sha256"

tar -xzf oracle_agent_factory_x86_26.7.0.tar.gz

● PAF VM：Podman / SELinux 事前確認

getenforce

GRAPHROOT="$(podman info --format '{{.Store.GraphRoot}}')"

echo "$GRAPHROOT"
ls -ldZ "$GRAPHROOT"
sudo ls -ldZ /var/lib/containers

カスタム graphRoot が default_t だった今回の環境では次を実施しました。

sudo semanage fcontext -a -e /var/lib/containers \
  "$GRAPHROOT"

sudo restorecon -R -v "$GRAPHROOT"

ls -ldZ "$GRAPHROOT"

Podman 単体テストです。

podman run --rm \
  container-registry.oracle.com/os/oraclelinux:8 \
  /bin/sh -c 'echo "Container test: OK"'

Marketplace Upgrade Guide に従い、Installer 実行前に一時的に Permissive にします。

sudo setenforce permissive
getenforce

● PAF VM：Upgrade

cd /u01/staging_upgrade_26_7
./interactive_install.sh

● PAF VM：Upgrade 後

sudo setenforce enforcing
getenforce

podman images --format \
  'table {{.Repository}}\t{{.Tag}}\t{{.Created}}\t{{.Size}}'

podman ps --format \
  'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'

curl -k -sS -o /dev/null \
  -w 'HTTP %{http_code}\n' \
  https://localhost:8080/agentFactory/

cd /u01/staging_upgrade_26_7
make diagnose

■ まとめ

今回は、OCI Marketplace で構築した PAF 26.4 を、PAF 26.7 のインストール・キットを使用して Upgrade しました。

Marketplace に 26.7 の新しい Stack が表示されるのを待って環境を作り直すのではなく、既存の PAF VM に新しい Staging Directory を作成して Upgrade できました。

今回のポイントは次のとおりです。

PAF 26.4 の Marketplace Instance をそのまま 26.7 へ Upgrade できた
26.7 Kit は VM の Architecture に合うものを使用した
既存の Staging Directory を再利用しなかった
Upgrade 前に OCI Boot Volume Backup を取得した
Rootless Podman のカスタム graphRoot と SELinux Context を事前確認した
Marketplace 向け 26.7 公式手順に従い、Upgrade 中のみ SELinux を一時的に Permissive にした
26.7 Container Image Build、Database Snapshot、DB Migration、Knowledge Agent Upgrade が成功した
起動中 Container が localhost/applied-ai-label:26.7.0.0.0 であることを確認した
About 画面でも Version 26.7.0.0.0 を確認した
Embedding Model の Connection Test が成功した
Generative Model の Test Connection では気になる挙動があったものの、Knowledge Assistant の実利用は HTTP 200 で正常に成功した
Upgrade 失敗時は [SUCCESS] Upgrade flow completed. だけで判断せず、実際に起動している Image Tag を確認することが重要だった
最後に make diagnose で Diagnostics Bundle を取得した

今回の検証で一番重要だったのは、コマンドを順番に実行することよりも、どのレイヤーを何のために確認しているかを分けることでした。

特に面白かったのは、PAF 26.7へUpgradeできたことだけではありません。
Installerの最後に[SUCCESS]と表示されても、実際には旧26.4へRecoveryされている場合がありました。そこからPodman単体で同じエラーを再現し、PAF、Container Image Build、SELinuxというレイヤーに分けて原因を追えたことが、今回一番大きな発見でした。

Oracle AI Database Private Agent Factoryは、Agentを作るだけの環境から、Memory、A2A、IAM、外部ModelやData Sourceを組み合わせるPrivate AI Agent Platformへ広がり始めています。一方で、その土台にはDatabase、Container、OS、Securityといった従来の技術がしっかり存在します。

Oracle Databaseを長く触ってきた立場から見ると、新しいAI Agentの機能と、これまで扱ってきたDatabase／Infrastructureの知識がつながっていくところに、かなり面白さを感じるものがありました。

次は、26.7で追加されたAgent MemoryやA2Aを実際のWorkflowへ組み込み、Agentがどのように会話を引き継ぎ、外部Agentと連携できるのか確認してみてみたいです。

事前確認
  -> Upgrade 前の正常状態を残す

Backup
  -> 戻せる状態を作る

Podman / SELinux
  -> 26.7 Image を Build できる土台を確認する

Installer
  -> Build / Migration / Deployment の各境界を見る

Host 確認
  -> 実際に 26.7 Image が起動したことを確認する

Application 確認
  -> 設定の存在だけでなく Agent の実利用まで確認する

この考え方で確認すると、Upgrade が失敗した場合も原因を切り分けやすくなり、成功した場合も「Version が変わったから完了」ではなく、既存環境が実際に利用できるところまで確認できます。

次は、PAF 26.7 で追加・変更された機能も確認してみたいと思います。

■ 参考情報

今回の検証では、主に次のドキュメントを参考にしました。

● Oracle AI Database Private Agent Factory 26.7

Oracle AI Database Private Agent Factory 26.7 Documentation
- PAF 26.7 のドキュメント・トップページです。
What's New in Oracle AI Database Private Agent Factory 26.7
- Agent Memory、Agent-to-Agent（A2A）Collaboration、Identity and Access Management、Agent Builder の機能拡張など、PAF 26.7 の主な更新内容を確認できます。
Upgrade Agent Factory
- PAF の Upgrade 手順です。
- 本稿では、既存の OCI Marketplace Instance を 26.4 から 26.7 へ Upgrade する際の基本手順として参照しています。
Oracle AI Database Private Agent Factory Downloads
- PAF Installation Kit のダウンロード・ページです。
- 本稿では Linux x86-64 用の PAF 26.7 Installation Kit を使用しました。
Collect Diagnostic Information
- make diagnose を使用した Diagnostics Bundle の取得方法を確認できます。

● 前回の記事

Oracle AI Database Private Agent Factory 26.4 を構築してみてみた
- 今回 Upgrade した元環境を、OCI Marketplace から構築した記録です。

● Podman / SELinux

今回の環境では、Rootless Podman のカスタム graphRoot に設定された SELinux Context が原因で、最初の Upgrade 時に Container Image の Build が失敗しました。

Red Hat - Why podman cannot change the memory protections when running containers?
- Rootless Podman でカスタム graphRoot を使用する場合の SELinux Label に関する情報です。
- 今回確認した libtinfo.so.6: cannot change memory protections の切り分けで参考にしました。

Oracle AI Database Private Agent Factory は継続的に機能追加・更新されています。

本稿では PAF 26.7 / 2026年8月時点のドキュメントと実機環境をもとに検証しています。
実際に Upgrade する際は、対象 Release の最新ドキュメントもあわせて確認してください。

■ 解説

■ おまけ

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Oracle AI Database Private Agent Factory 26.4 を 26.7 へ Upgrade してみてみた

Oracle AI Database Private Agent Factory 26.4 を 26.7 へ Upgrade してみてみた

■ はじめに

● PAF 26.7 のリリース

● PAF 26.7 の主な更新内容

● Marketplace の表示と実際の Upgrade

● 今回の Upgrade で特に確認すること

■ 本稿の対象環境

■ Upgrade の設計を先に理解

● 今回は VM を作り直さず、既存 Marketplace Instance を更新する

● 旧 Staging Directory と新 Staging Directory を分ける理由

● Backup は 2 層で考える

● Installer が実行する処理を先に理解する

● Upgrade 成功は 3 段階で判定する

● Upgrade の全体手順

■ 1. Upgrade 前のベースラインを記録

● PAF の Version を確認

● Marketplace の表示を確認

● OS とアーキテクチャを確認

● CPU、Memory、Disk を確認

● Podman の状態を記録

● PAF の応答を確認

● Metadata の存在を確認

■ 2. PAF の論理構成を記録

● Upgrade 前の確認表

● Model Management

● Data Sources

● Knowledge Agent / Custom Flow

■ 3. 復旧できる状態を作る

● OCI Boot Volume Backup

■ 4. Upgrade に使用する 26.7 Kit を確定

● Kit を PAF VM へ転送

■ 5. Upgrade 用 Staging Directory を分離して Kit を展開

● 新しい Staging Directory を作成

● Kit を Staging Directory へ配置

● SHA-256 を記録

● Installation Kit を展開

■ 6. Container Image を Build できる状態か事前確認

● SELinux と graphRoot を確認

● graphRoot の状態から対応を判断

● default_t の場合は SELinux Context を修正

● Podman 単体テスト

● Marketplace Upgrade 用に SELinux を一時的に Permissive にする

■ 7. PAF 26.4 から 26.7 へ Upgrade を実行

● 作業開始前の最終確認

● Installer 実行前に処理の境界を確認

● Interactive Installer を実行

● 26.7 Container Image の Build 成功を確認

● Database Snapshot / Migration を確認

● SELinux を Enforcing に戻す

■ 8. Host 側で 26.7 への切り替えを確認

● 26.7 Image を確認

● Container の起動状態を確認

● PAF URL を確認

■ 9. UI 側で Version 26.7 を確認

■ 10. 既存設定だけでなく実利用まで確認

● Administrator Login

● Model Management

・Embedding Model の接続テスト

・Generative Model の接続テスト

● Data Sources

● Knowledge Assistant

● Custom Flow

● Published Agent / Flow

■ 11. SSO を使用している場合の注意

■ 12. Upgrade 後の Diagnostics を保存

■ 13. Upgrade 前後を比較して完了判定

■ おまけ 1：1 回目の Upgrade が失敗したときのトラブルシューティング

● STEP 11/25 で Image Build が失敗

● Installer は旧 26.4 を Recovery

● Podman 単体でも同じ Error が再現

● graphRoot の SELinux Label を修正

● 失敗時は Diagnostics を先に取得

■ おまけ 2：OCI GenAI / Instance Principal の Test Connection を確認

● Upgrade された Generative Model の Test Connection が失敗

● 同じ設定を 26.7 で新規入力すると保存前は成功

● 保存して Reload すると新規設定も失敗

● DB 上の Configuration を比較

● Knowledge Assistant の実利用は成功

■ 問題発生時に安易に実行しない操作

● `default_t` の場合は SELinux Context を修正