Private Agent Factory 26.7 の Custom Flow を A2A（Agent2Agent）で呼び出してみた

Posted at 2026-10-13

はじめに

Private Agent Factory（以下、PAF）で作った Custom Flow は、A2A（Agent2Agent）プロトコルを使って別のエージェントから利用できます。ある PAF で用意した検索や業務処理を、同一の PAF 上の Custom Flow から呼び出したいとき、別の PAF の Custom Flow から呼び出したいとき、全く異なるエージェント基盤上のエージェントから呼び出したいときに使える仕組みです。

今回は、日本語 Wikipedia を検索する小さな Custom Flow を公開し、別の Custom Flow のサブエージェントとして接続する構成を紹介します。検証には同じ PAF を公開側と呼び出し側の両方に使いました。

今回の環境では、HTTPS 通信に使う TLS 証明書（一般に SSL 証明書とも呼ばれます）に自己署名証明書を使用しています。そのため、呼び出し側の PAF がその証明書を信頼できるように証明書の outbound trust store への登録が必要でした。また、同じ PAF 内で A2A の要求と応答を処理するため、複数ワーカーでの実行設定も必要でした。

そもそもこの検証をしたきっかけは、Tools に分類されているコンポーネントでも、ReAct Agent の Tool として直接接続できないものがあったことです。Wikipedia search も、入力から検索して結果を返す Custom Flow にすれば、A2A 経由で処理を委譲できます。この方法を使うと、検索処理を公開側に持たせて、他の Custom Flow で共有することができます。また、業務データベースへのアクセスであれば特定のエージェントやエージェント基盤にデータベースアクセスを閉じ込めて、呼び出し側は必要な結果だけを受け取ってデータベースには触らせないといった目的にも使うことができますね。

検索を公開する Custom Flow と、回答を作る Custom Flow を分ける

今回の構成は次のとおりです。図は接続関係を示したものです。

公開側は検索キーワードを受け取り、記事の概要と URL を返します。LLM は呼びません。Wikipedia Search Agent という名前ですが、AIエージェントではなく、単純に受け取った検索キーワードで、Wikipedia を検索して結果を返すだけです 。質問の解釈、検索キーワードの選択、取得した情報からの回答作成は、呼び出し側の Agent が担当します。

A2A では、エージェントの名前や機能、接続先、認証方式を記載した Agent Card を取得して接続先を確認します。PAF ではこれを External agents に登録し、 Custom Flow 上の External Agent コンポーネントから利用します。公式の A2A ガイドにも、公開側と呼び出し側の手順が用意されています。

対象環境は次のとおりです。

項目	今回の環境
PAF	26.7（コンテナイメージタグ `26.7.0.0.0`）
実行方式	Podman、production モード（`SETUP_MODE=prod`）
HTTPS	ポート `8080`、自己署名証明書

PAF の構築は済んでいる前提です。コマンドは PAF を動かしている Linux ホストの Bash で実行します。ログインには、その環境で PAF のコンテナを管理している OS ユーザー（Marketplace からデプロイした場合は、opcユーザー）を使います。<PUBLIC_IP>、<STAGING_DIR>、<DB_USER>、<AGENT_ID> は、山括弧（<>）ごと各環境の値に置き換えてください。

別の PAF から接続する場合も、公開と登録の流れは共通です。その場合は呼び出し側から公開側の Agent Card と A2A エンドポイントへ到達できる必要があります。今回の単一ワーカーによる待ち合わせの問題は、同じ PAF に接続した際に確認したものです。

1. Wikipedia Search Agent を作る

Agent Builder で Custom Flow を作り、名前を Wikipedia Search Agent としました。Custom Flow の Description は、wikipedia_search_agent としています。

私が試した限り Custom Flow の Description の記述が長くなると呼び出しに失敗することがありました。現時点では、Description は短い名前にしておくのがおすすめです。

コンポーネントの設定は以下です。Chat input と Chat output は、ポート接続以外にこの例固有の設定はありません。

コンポーネント	項目	設定値
Chat input	入力	実行時に検索キーワードを入力
Wikipedia search	Search Query	Chat input の Message 出力を接続
Wikipedia search	Language	`ja`
Wikipedia search	Number of Results	`10`
Chat output	Message	Wikipedia search の Message 出力を接続

接続するポートは2組です。

接続元	接続先
Chat input：Message	Wikipedia search：Search Query
Wikipedia search：Message	Chat output：Message

Wikipedia search には JSON と Message の出力があります。この例では、人が読める形に整形された Message を使います。Number of Results は検索結果の記事数で、既定値は4、設定範囲は1〜10です。1記事から取り出す段落数ではありません。コンポーネントの公式説明

保存したら、Playground で検索キーワードを入力します。確認するのは、記事タイトル、概要、URL が返ることです。

この Custom Flow が取得するのは主に記事冒頭の概要です。今回調べた PAF 26.7 の実装では、検索結果ごとに summary API の extract を取得していました。概要の取得に失敗した場合などには、検索一致箇所の短い抜粋へ切り替わり、URL が空になる場合もあります。

そのため、記事本文の「歴史」などに書かれた情報まで回答できるとは限りません。Number of Results を増やしても、同じ記事を深く読む動作にはなりません。このブログでは、記事本文を取得するための追加処理は扱いませんが、REST API Tool で Wikipedia の API を呼び出せば簡単に実装できそうです。

2. Publish した Custom Flow の A2A access を有効にする

公開側の Custom Flow を保存して Publish し、チャット画面を開きます。Integration options → A2A で A2A access を有効にし、Agent Card URL をコピーしてください。続けて、この Custom Flow 専用の A2A API key を生成します。

Agent Card URL は次の形です。

https://<PUBLIC_IP>:8080/agentFactory/a2a/agents/<AGENT_ID>/agent-card

Publish だけでは A2A 接続は有効になりません。公開条件と有効化の手順

API key は後ほど Bearer token として登録します。URL には埋め込みません。

3. 自己署名証明書を呼び出し側の信頼ストアへ登録する

最初の discovery は、次のエラーで失敗しました。

CERTIFICATE_VERIFY_FAILED: self-signed certificate

ブラウザで PAF の画面を開けていても、PAF 自身が HTTPS 接続先を信頼できるとは限りません。ブラウザの証明書設定と、PAF が外向きの通信に使う outbound trust store は別です。今回の環境では、自身が配信する自己署名証明書も、この信頼ストアに登録する必要がありました。

登録には公式ドキュメントの管理者 APIを使います。公式ドキュメントは CA・中間 CA 証明書の追加を説明しており、以下の自己署名サーバー証明書を使う例は今回の検証に基づきます。既存の信頼ストアで検証できる接続先なら、この追加作業は不要です。

接続先の名前と証明書を確認する

同一環境への接続なので、ホスト上にある公開証明書を使います。

BASE_URL='https://<PUBLIC_IP>:8080'
CERT_FILE='<STAGING_DIR>/applied-ai/volume/config/app/latest/certs/cert.pem'

openssl x509 -in "$CERT_FILE" \
  -noout -subject -issuer -dates -fingerprint -sha256 -ext subjectAltName

出力例

$ openssl x509 -in "$CERT_FILE" \
>   -noout -subject -issuer -dates -fingerprint -sha256 -ext subjectAltName
subject=CN = agentfactoryvm.subxxxxxxxxxx.ocigenerativeai.oraclevcn.com
issuer=CN = agentfactoryvm.subxxxxxxxxxx.ocigenerativeai.oraclevcn.com
notBefore=Oct  7 07:13:33 2026 GMT
notAfter=Oct  8 07:13:33 2027 GMT
SHA256 Fingerprint=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
X509v3 Subject Alternative Name: 
    DNS:agentfactoryvm.subxxxxxxxxxx.ocigenerativeai.oraclevcn.com, DNS:localhost, IP Address:xxx.xxx.xxx.xxx, IP Address:127.0.0.1

IP アドレスで接続する場合は、証明書の SAN（Subject Alternative Name）にその IP が含まれることを確認します。

openssl x509 -in "$CERT_FILE" -noout -checkip '<PUBLIC_IP>'

出力例

$ openssl x509 -in "$CERT_FILE" -noout -checkip 'XXX.XXX.XXX.XXX'
IP XXX.XXX.XXX.XXX does match certificate

今回、CN は内部 FQDN のままでしたが、SAN に接続先 IP があり、IP の一致検査に成功しました。

FQDN や IPアドレスを指定して自己署名証明書を再作成する場合は、Generate Your Own SSL Certificatesを参照してください。

outbound trust store に登録するのは cert.pem です。秘密鍵の key.pem は使いません。別の PAF へ接続する場合には、その接続先を検証するための証明書を、呼び出し側に登録します。

管理者としてPAFにログインし、証明書を追加する

証明書の登録には、PAF の管理者 API を使います。この API を呼び出すには、管理者としてログイン済みであることを示す認証情報が必要です。まず curl でログインし、PAF が返すセッション Cookie を取得します。その Cookie を証明書の登録リクエストに添えて送ることで、管理者として登録を行います。

以下のコマンドでは、PAF の管理者アカウントでログインし、取得した Cookie の値を変数 AGENT_FACTORY_SESSION に保存します。先ほど発行した A2A API key は、ここでは使いません。

まとめて貼り付けられるように、処理全体を { ... } で囲んでいます。Bash は閉じ括弧まで読み込んでから実行するため、途中の read が貼り付けたコードを入力として読み取るのを防げます。最後の } まで貼り付け、必要なら Enter を押してください。

{
  read -r -p 'Agent Factory の管理者メールアドレス: ' ADMIN_EMAIL

  AGENT_FACTORY_SESSION="$(
    curl --silent --show-error \
      --cacert "$CERT_FILE" \
      --dump-header - --output /dev/null --location \
      --user "$ADMIN_EMAIL" \
      --header "Origin: $BASE_URL" \
      "$BASE_URL/agentFactory/v1/loginValidation" |
    tr -d '\r' |
    awk -F'[=;]' '/agent_factory_session=/{print $2; exit}'
  )"

  if [ -n "$AGENT_FACTORY_SESSION" ]; then
    echo 'セッションを取得しました'
  else
    echo 'セッションを取得できませんでした。ここで中止してください'
  fi
}

最初の入力要求に管理者メールアドレスを入力し、続く curl の入力要求に管理者のパスワードを入力します。セッションが取得できなければ、次へ進まず認証情報を確認してください。

直前のログイン用コマンドでは、curl が HTTPS で PAF に接続しています。その中の --cacert "$CERT_FILE" は、「接続先の証明書を確認するときに、手元の cert.pem を信頼する証明書として使う」という curl への指定です。この指定が効くのは、その curl コマンドによる通信だけです。PAF 自身が A2A 接続に使う信頼ストアには、まだ登録されていません。

次のコマンドで、証明書を PAF の信頼ストアに登録します。ここでも --cacert は curl の接続時の確認に使います。証明書ファイルを PAF に送るのは、末尾の --form "certificate=@${CERT_FILE}" です。送信先の管理者 API /agentFactory/v1/certs が、その証明書を信頼ストアに追加します。

curl --silent --show-error \
  --cacert "$CERT_FILE" --include \
  "$BASE_URL/agentFactory/v1/certs" \
  --header "Origin: $BASE_URL" \
  --header "Cookie: agent_factory_session=$AGENT_FACTORY_SESSION" \
  --form "certificate=@${CERT_FILE}"

今回の追加結果は 201 Created で、応答には次の値がありました。

{
  "data": {
    "filename": "cert.pem",
    "certificates_added": 1,
    "duplicated_certificates_already_present": 0
  },
  "errorMessages": [],
  "messages": []
}

登録内容を確認するには、証明書の登録に使った URL（/agentFactory/v1/certs）に GET リクエストを送信します。

curl --silent --show-error \
  --cacert "$CERT_FILE" --include \
  "$BASE_URL/agentFactory/v1/certs" \
  --header "Origin: $BASE_URL" \
  --header "Cookie: agent_factory_session=$AGENT_FACTORY_SESSION"

unset AGENT_FACTORY_SESSION ADMIN_EMAIL

今回の user_certificates_count は1でした。応答の sha256_fingerprint と、手元の証明書のフィンガープリントを照合します。同じ証明書が登録済みの場合は、追加時の応答が 200 OK になることもあります。

証明書の追加後、TLS の検証エラーは解消しました。この変更だけのための PAF 再起動は不要でした。

4. Oracle AQ を構成して複数ワーカーで起動する

この作業は、Private Agent Factory を1ワーカーで動作させている場合にだけ必要です。
ワーカー数は、PAFが稼働している Linux 上で、以下のコマンドでプロセス数を調べることで確認できます。

podman exec oracle-applied-ai-label bash -c \
  'ps -eo pid,ppid,args | grep "[g]unicorn_config/uvicorn_config.py"'

親プロセス1行と、その PID を親に持つワーカーが見えるはずです。

以下のように表示されたら1ワーカーで稼働しています。

$ podman exec oracle-applied-ai-label bash -c \
>   'ps -eo pid,ppid,args | grep "[g]unicorn_config/uvicorn_config.py"'
    306       1 /home/aaiuser/install/agent_factory/third_party/python3/bin/python3.12 /home/aaiuser/install/agent_factory/third_party/python3/bin/gunicorn --config /home/aaiuser/install/agent_factory/gunicorn_config/uvicorn_config.py
    350     306 /home/aaiuser/install/agent_factory/third_party/python3/bin/python3.12 /home/aaiuser/install/agent_factory/third_party/python3/bin/gunicorn --config /home/aaiuser/install/agent_factory/gunicorn_config/uvicorn_config.py

インストーラーで DB接続のテストを実施する前に Oracle AQ のセットアップを完了していないとこの状態になります。

私の環境で、証明書を登録しても、discovery の画面は同じエラーが表示されてしまいました。しかし、サーバーログの内容は変わっていました。

ログファイルは、<STAGING_DIR>/applied-ai/volume/log/app/latest/log/agent_factory.logでした。

"<STAGING_DIR>"は、Marketplace からデプロイして1度もアップグレードしていなければ /u01/staging です。

ログのエラーメッセージ

TimeoutError: The read operation timed out

今回の PAF は1ワーカーで動いていました。実装を調べると、discovery は自身の Agent Card を同期 HTTP 呼び出しで取得する構造でした。応答を待つ間にワーカーのイベントループが止まり、同じワーカーで処理するはずの Agent Card リクエストが進みません。

独立した診断プロセスからは、正しい信頼ストアとキーを使って約1.5秒で Agent Card を取得できました。一方、UI からの自己接続ではタイムアウトし、4ワーカー化後に成功しました。コードの構造とログの時間関係も合わせて、単一ワーカーでの待ち合わせが原因と判断しています。

この待ち合わせを避けるには、要求を待つ処理と応答する処理を別のワーカーで受けられるようにします。考え方としては2以上ですが、今回動作を確認した設定は4ワーカーです。ワーカーを増やす方法は同期呼び出し自体の修正ではないため、同時利用が増える場合は別途動作を確認してください。

Private Agent Factory のリポジトリに Oracle AQ を構成する

複数ワーカー化は、公式のスケーリング手順に従って行います。最初に、PAF のリポジトリがある DB／PDB に DB 管理者として接続します。Private Agent Factory 画面の管理者や Private Agent Factory 専用のリポジトリユーザーではなく、データベースの管理者です。

公式ページの Configure Oracle AQ にある SQL 全体を使い、<DB_USER> をリポジトリユーザー名に置き換えて実行します。SQL は権限付与、キューテーブルとキューの作成、開始、サブスクライバーの追加を含みます。想定外のエラーが出たら再起動へ進まず、DB の設定を確認します。

以下は構成を確認する SQL です。通常の大文字ユーザー名を使う例です。

SELECT OWNER, NAME, QUEUE_TABLE, ENQUEUE_ENABLED, DEQUEUE_ENABLED
FROM DBA_QUEUES
WHERE OWNER = '<DB_USER>' AND NAME = 'AAI_SOCKETIO_QUEUE';

SELECT CONSUMER_NAME
FROM DBA_QUEUE_SUBSCRIBERS
WHERE OWNER = '<DB_USER>' AND QUEUE_NAME = 'AAI_SOCKETIO_QUEUE'
ORDER BY CONSUMER_NAME;

今回確認したのは、AAI_SOCKETIO_QUEUE の ENQUEUE／DEQUEUE がともに YES、サブスクライバーが AAI_SIO_1 から AAI_SIO_8 までの8件という状態です。

ワーカー数を指定して再起動する

ここからはアプリケーションが一時停止します。実行中のチャットやフローがない時間に、ホスト側で次を実行します。

podman exec -u root oracle-applied-ai-label bash -c \
  'export AGENT_FACTORY_ASGI_WORKERS=4; /home/aaiuser/install/agent_factory/manage_app.sh --all --restart'

これは検証環境で成功したコマンドです。2026年10月13日に確認した公式ページでは、末尾が manage_app.sh restart all という表記でした。使用している版のスクリプトと手順を確認してください。

再起動時には、途中の待機表示だけで判断せず、最後まで確認します。

async server waiting for workers | workers=0/4 ready=0/4
async server waiting for workers | workers=4/4 ready=0/4
async server ready | master_pid=<MASTER_PID> workers=4/4
Started the Oracle Private AI Agent agent_factory processes for component(s): all.

プロセス一覧でも確認できます。

podman exec oracle-applied-ai-label bash -c \
  'ps -eo pid,ppid,args | grep "[g]unicorn_config/uvicorn_config.py"'

親プロセス1行と、その PID を親に持つワーカー4行があれば4ワーカーです。合計5行を5ワーカーと数えないようにします。

再起動後も同じワーカー数にするには

上のコマンドの export は、そのとき起動するプロセスに適用されます。保存されたコンテナ設定を書き換える処理ではありません。

今回の環境では、明示指定がなく、AQ の準備を示すマーカー socketio_aq_ready.json もない場合、起動処理は1ワーカーに戻る構造でした。DB に AQ を構成したことと、このマーカーがあることは別です。なお、このマーカー socketio_aq_ready.json は、インストーラーで DB 接続テストを行った段階で既に Oracle AQ がセットアップされていると自動的に生成されるようです（まだ、試していません）。

設定変更の永続化にはこの AQ の準備を示すマーカー socketio_aq_ready.jsonを作ってあげれば良さそうですね。実際にやってみたところうまくいきました。

まず、<STAGING_DIR>/applied-ai/volume/data/app/latest/markers/socketio_aq_ready.json ファイルを作成して、以下の内容を記載します。

{
  "ready": true,
  "queue_name": "AAI_SOCKETIO_QUEUE",
  "subscriber_prefix": "AAI_SIO",
  "subscriber_count": 8,
  "required_workers": 8,
  "auto_setup": false
}

subscriber_count と required_workers は、先程の Oracle AQ の設定に合わせています。

<STAGING_DIR> で、make restartを実行してコンテナを再起動します。

再起動したらプロセス一覧を確認します。

podman exec oracle-applied-ai-label bash -c \
  'ps -eo pid,ppid,args | grep "[g]unicorn_config/uvicorn_config.py"'

親プロセス1行と、その PID を親に持つワーカー8行があれば8ワーカーです。

AQ の準備を示すマーカー socketio_aq_ready.jsonを手動で作成することは公式のドキュメントには記載がありません。将来のアップグレードで上書きされる可能性もありますので、アップグレード時にはワーカー数を確認した方がよいでしょう。

5. 公開した Custom Flow を External agents に登録する

Private Agent Factory で、Utilities → A2A Agents → External agents → Add external agent を開き、次を入力します。

項目	値
Agent Card URL	公開側からコピーした URL
Authentication	`Bearer token`
Bearer token の入力欄	公開側で発行した A2A API key の値のみ

キーの名前は「API key」ですが、認証方式は Bearer token です。入力値に Bearer は付けません。

Discover agent を押し、名前、Description、Skills、Endpoint と、互換性の表示を確認します。証明書登録とワーカー数を増やした後に、次の画面まで進めました。

この画面では Wikipedia Search Agent が検出され、External agent is compatible. と表示されています。Description と Skills の説明は wikipedia_search_agent、通信方式は JSON-RPC です。IP アドレスと ID はマスクしています。

検証で取得した Agent Card は A2A 1.0 の JSON-RPC 接続を示し、処理の送信先は次の形でした。

https://<PUBLIC_IP>:8080/agentFactory/a2a/agents/<AGENT_ID>/rpc

この画面の左下の Add external agent で登録し、Enable を実行して Connected となることを確認します。登録直後は Disabled です。検出成功の画面だけでは、有効化や実行の確認は済んでいません。登録と状態の公式ドキュメント

6. Wikipedia Agent から検索を委譲する

呼び出し側は、別の Custom Flow として Wikipedia Agent を作ります。Description は、たとえば「Wikipedia Search Agent に検索を委譲し、取得した記事概要を基に回答する」としています。この節の値は実行確認に使った設定例です。

コンポーネント	項目	設定例
Agent	LLM	LLM Management に登録済みの、tool calling に対応するモデル
Agent	Custome instructions	後述のプロンプト例
Agent	Agent description	エージェントの説明
External Agent	Select A2A client to use	登録・有効化した Wikipedia Search Agent
External Agent	Agent description	`wikipedia_search_agent`
Chat output	Message	Agent の Message 出力を接続

接続元	接続先
Chat input：Message	Agent：Prompt
Agent：Message	Chat output：Message
External Agent：Agent	Agent：Sub-agents

サブエージェントとして使う場合、External Agent の Input はこの委譲には使われません。Agent が委譲時のメッセージを作って渡しますExternal Agent の公式説明。このとき、 Agent は、 External Agent が LLM という頭脳を持って自然言語で指示を受け付けることができるものとしてメッセージを構築するようです。検索キーワードだけを渡すよう指定しないと、質問文や作業指示を渡す場合があります。今回は、委譲先が LLM を持たないただのフローですので、自然文を渡さないように Agent の Custome instructions にプロンプト（後述）を記載します。

Agent description は短い名前にする

今回試してみた限りでは、公開側 Custom Flow の Description が、呼び出し側の External Agent の Agent description に設定されます（書き換えても上書きされます）。今回の PAF 26.7 の動作を調べてみた限りでは、この Agent description が内部のサブエージェント名にも使われていました。

長い説明文を設定した際には、LLM が長い Description を流用した宛先名に含まれていた「複数指定」という文言を類義語の「多数指定」と言い換えてしまい名前の完全一致に失敗して呼び出せない例がありました。この段階では A2A の HTTP 通信に進んでいません。

そこで、この例では wikipedia_search_agent という短い値を使い、詳しい利用条件は親 Agent の Custome instructions に書きます。

Agent の Custome instructions のプロンプト例は以下です。

## タスク
- ユーザーの質問を理解して、質問に答えるために必要な事項（１つ、もしくは、複数）を特定します。
- 特定した事項すべてをwikipedia で調査します。
- 返された記事概要の範囲で回答します。
- 記事概要から回答するために必要な情報が得られなかった場合は、概要にない情報は確認できないと報告します。

## 出力フォーマット
- 回答は、ユーザーの質問への回答と回答生成に参照したソースのURLの順とします。
- ソースの URL の一部がパーセントエンコーディング（URLエンコーディング）されている場合は、原文に戻します。
- 質問には必ず質問文と同じ言語で回答します。

## wikipedia search agent 
wikipedia で調査するときは、wikipedia_search_agent を使います。
wikipedia_search_agent は、検索キーワードのみを受け付けます。
wikipedia_search_agent は、複合的な質問や推移的な質問は理解できないので、質問を分解して、検索キーワードだけを wikipedia search tool へ渡します。
検索条件を絞り込むために検索キーワードを複数列挙することはできます。
wikipedia_search_agent は最大10回まで使用できます。

ユーザーの質問：

保存後、Playground の新しいチャットで、たとえば次の質問を入力します。

discovery に失敗したら、画面表示より最新ログを見る

今回、画面にはどちらの原因でも同じメッセージが出ました。

External agent could not be discovered. Check the Agent Card URL and try again.

切り分けには、操作をやり直した直後のログが役立ちました。

ログ・症状	今回確認した原因と対応
`CERTIFICATE_VERIFY_FAILED: self-signed certificate`	outbound trust store に公開証明書を追加
証明書登録後の `The read operation timed out`	同一環境への同期接続が1ワーカーで待ち合わせ。AQ 構成後に4ワーカー化
サブエージェント名の不一致で委譲に失敗	A2A 通信の前段。Agent description と親の指示を確認
再起動後にタイムアウトが再発	実際のワーカー数と永続設定を確認

ホスト上の主なログは次の場所です。

<STAGING_DIR>/applied-ai/volume/log/app/latest/log/agent_factory.log
<STAGING_DIR>/applied-ai/volume/log/app/latest/log/agent_factory_asgi.log
<STAGING_DIR>/applied-ai/volume/log/app/latest/nginx/access.log

HTTP のステータスだけにも注意が必要です。今回、未認証のアクセスはログイン画面へ転送され、その HTML が 200 を返しました。Agent Card の取得を確認する際には、JSON が返り、カードの項目が含まれることまで見ます。

別の PAF や全く異なるエージェント基盤から利用するときも、公開側の検索処理を共有できる

この例の公開側は、検索キーワードを受け取って概要と URL を返すだけの Custom Flow です。別の PAF から利用する場合も、同じ Agent Card URL と認証方式で登録する構成を取れます。検索処理は公開側で管理し、各呼び出し側で質問の解釈や回答の作り方を設定します。

今回は、その接続を同一環境内で試したことで、証明書の信頼設定とワーカーの同時実行設定に行き当たりました。検出後は、登録・有効化、委譲、A2A 通信、回答の根拠を順に確認します。再起動や証明書更新の後にも同じ確認を行えるようにしておくと、Custom Flow を共有して使う際の運用に役立ちます。

あとがき

Wikipedia の検索をする専用エージェントを A2A で公開するというのは、用途としてはあまり面白くありませんが、この仕組みが本当に威力を発揮するのはデータベースへアクセスするエージェントです。業務データを格納したデータベースにアクセスできるエージェントは極力限定したいですよね？

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

Private Agent Factory 26.7 の Custom Flow を A2A（Agent2Agent） で呼び出してみた