2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

あなたはもう試した？判断特化AI「Jev」で遊ぼう！
@asahide
in

Autonomous AI Database から Jev を呼んでみた

2
Posted at

1. はじめに

TypeSafe AI の Jev は、文章を生成しない AI モデルです。入力（state）と型付きの質問（questions）を JSON で渡すと、Noul（真偽を 0〜1 で）、Choice（最大 255 択から 1 つ）、Score（段階）の答えを確率つきで返します1。公式ドキュメントによれば、1 回のリクエストに複数の質問を入れても並列に評価され、質問を増やしても応答時間はほとんど変わりません2。

Oracle Autonomous AI Database（以下 ADB）の Select AI は、プロバイダとして OpenAI や OCI Generative AI などを選べますが、Jev は一覧にありません。OpenAI 互換の API でもないため、利用する場合は PL/SQL から REST API を直接呼び出します。ADB には DBMS_CLOUD.SEND_REQUEST と UTL_HTTP の 2 系統があり、API キー（Bearer トークン）をどう渡せば呼び出せるのかを Always Free の ADB で確かめました。あわせて、Jev の「まとめて聞ける」性質が DB の中から呼んでも同じように機能するのかを、50 本の SQL を一度に判定させて測ります。

1.1. 結論（先出し）

  • DBMS_CLOUD.SEND_REQUEST は、URI を https:// ではなく bearer:// で始めると呼び出せる。資格証明の password に入れた API キーが Authorization: Bearer として送られる（公式の「顧客管理エンドポイント」の URI 形式）
  • URI を https:// のまま渡すと、同じ資格証明が AWS の署名（AWS4-HMAC-SHA256）で送られて 401 になる（8 章の付録）
  • UTL_HTTP でも呼び出せる。ACL を登録し、SET_HEADER で Authorization を付ける。ただし UTL_HTTP.SET_CREDENTIAL は Basic と Digest しか受け付けず、Bearer は ORA-29261
  • 50 本の SQL を state に並べて Noul 50 問を 1 回のリクエストで送ると 0.5〜0.6 秒で 50 問すべて正答。1 問だけ聞いたときと同じ 0.5〜0.6 秒の範囲だった

1.2. 検証ゴール

# 確かめること 確認できれば OK の条件
1 ADB から Bearer 認証の REST API（Jev）を呼ぶ方法はどれか。SEND_REQUEST の 4 通り（資格証明 NULL、https:// と資格証明、https:// とヘッダー指定、bearer:// と資格証明）、UTL_HTTP の SET_HEADER、UTL_HTTP.SET_CREDENTIAL の 6 方式 200 と Jev の JSON が返る方式が確定し、失敗した方式はエラー文と「実際に送られた Authorization ヘッダー」の両方が記録されている
2 Jev の Noul と Choice（255 択）が ADB の中から動くか Noul は DELETE 文に 0 付近・SELECT 文に 1 付近を返す。Choice は 255 本の SQL から DROP や TRUNCATE などを上位に並べる
3 50 本の SQL を state に入れて Noul 50 問を 1 回のリクエストで送ったとき、DB の中からどれだけの秒数で返るか 1 回の呼び出しで 50 問すべてに答えが返り、所要秒数と正答数が記録されている

同じ判定を OCI Generative AI の Llama 3.3 70B（Select AI の generate）でも実行しましたが、これは比較のために測っただけで、記事の主題ではありません。5.3 章に数字だけ添えます。

2. 検証環境

項目 値
ADB Oracle Autonomous AI Database Serverless（Always Free、Autonomous Transaction Processing、ap-tokyo-1、1 OCPU）
DB バージョン Oracle AI Database 26ai Enterprise Edition 23.26.3.3.0
実行ユーザー ADMIN
Jev jev-latest（応答の model は jev-1.13.0）。エンドポイントは https://api.typesafe.ai/v1/systemone（米国）1
比較用 LLM OCI Generative AI（ap-osaka-1）の Llama 3.3 70B。Select AI プロファイル OCI_OSAKA（リソースプリンシパル認証）
クライアント Windows 11 の python-oracledb 4.0.1（thin モード）。PL/SQL ブロックを実行して秒数を測る
PC からの直接呼び出し 同じ Windows 11 の PowerShell 7 から Invoke-RestMethod で Jev を呼ぶ（ADB を経由しない比較用）

Jev の API キーは TypeSafe のダッシュボードで発行しました。SEND_REQUEST を使う方式では DBMS_CLOUD.CREATE_CREDENTIAL で DB の資格証明に入れ、UTL_HTTP を使う方式では手元の環境変数からバインド変数で渡しています。

今回の構成を図 1 に示します。左が呼び出し元の ADB で、右上が Jev、右下が比較用の OCI Generative AI です。ADB の枠内に並べた 4 つの箱が今回試した呼び方で、成功したのは上の 2 つです。

図 1: 構成図（ADB から SEND_REQUEST の bearer:// スキームか UTL_HTTP で Jev を呼ぶ）

図 1: 構成図（ADB から SEND_REQUEST の bearer:// スキームか UTL_HTTP で Jev を呼ぶ）

3. ADB から外部の REST API を呼ぶ方法

ADB の PL/SQL から HTTPS の API を呼ぶ手段は、公式ドキュメント「Call Web Services from Autonomous AI Database」に 2 つ挙がっています3。DBMS_CLOUD.SEND_REQUEST はクラウドの REST API 向けで、認証ヘッダーは資格証明から自動で付きます。UTL_HTTP は一般の HTTP クライアントで、公開ホストならウォレットの設定は不要ですが、ホストごとに ACL の登録が必要です。

Jev のように Bearer トークンで認証する API に対して、それぞれをどう使うと何が起きたかを表 1 にまとめます。

# 呼び方 認証の渡し方 結果
1 SEND_REQUEST credential_name => NULL、headers に Authorization: Bearer ORA-20000: The credential specified does not match the URL provided（送信前に失敗）
2 SEND_REQUEST（URI は https://） ユーザー名 BEARER_TOKEN、パスワードにキーを入れた資格証明 ORA-20403: Authorization failed for URI（AWS 署名で送られ 401）
3 SEND_REQUEST（URI は https://） 2 の資格証明に加えて headers に Authorization: Bearer ORA-20401: Authorization failed for URI（2 と同じ 401 だが、ヘッダーを足すとエラー番号が変わった）
4 SEND_REQUEST（URI は bearer://） 2 と同じ資格証明 成功。200 で Jev の JSON が返る
5 UTL_HTTP `SET_HEADER('Authorization', 'Bearer '
6 UTL_HTTP 資格証明を SET_CREDENTIAL(req, 'JEV_CRED', 'Bearer') で渡す ORA-29273: HTTP request failed / ORA-29261: bad argument

表 1: 6 つの呼び方と結果

3.1. bearer:// スキームで SEND_REQUEST を呼ぶ

SEND_REQUEST は、URI のホスト名が事前登録されたもの（oraclecloud.com や amazonaws.com など）なら認証方式を自動で決めます。それ以外の「顧客管理エンドポイント」については、DBMS_CLOUD の URI 形式のドキュメントに次のように書かれています4。

DBMS_CLOUD cannot determine the proper authentication scheme for customer-managed endpoints URIs. In those cases, DBMS_CLOUD relies on the proper URI scheme to identify the authentication scheme for the customer-managed endpoint.

指定できるスキームを表 2 に示します。

URI スキーム 認証 資格証明の使われ方
basic:// Basic 認証 ユーザー名とパスワードを Basic 認証に使う
bearer:// Bearer トークン password を Bearer トークンとして Authorization ヘッダーに入れる
oci:// OCI ネイティブ OCI の署名キーで署名する
public:// 認証なし 資格証明を使わない
s3:// S3 互換 ユーザー名とパスワードをアクセスキーとシークレットキーとして SigV4 で署名する

表 2: 顧客管理エンドポイント用の URI スキーム（公式ドキュメント4 の表を要約）

Jev は Bearer トークン認証なので、URI を bearer://api.typesafe.ai/v1/systemone にし、パスワードに API キーを入れた資格証明を渡すと 200 が返りました（表 1 の 4）。httpbin に送って確かめると、Authorization: Bearer ... が付き、basic:// なら Basic ...、public:// なら Authorization 無しで送られていました。User-Agent は DBMS_CLOUD PLSQL Client/1.0.0 です。

認証が不要な API なら public:// を使い、credential_name は NULL で構いません（httpbin に対して 200。https:// のまま NULL にすると宛先に関係なく ORA-20000 でした）。公式ドキュメントに記載されているとおり、SEND_REQUEST で任意の REST API を呼ぶ際は、URI のスキームで認証方式を自分で指定します。Bearer トークンは DB の資格証明に保持できるため、PL/SQL 側にキーを埋め込んだり渡したりする必要はありません。

3.2. UTL_HTTP でも成功するが、SET_CREDENTIAL は Bearer を受け付けない

UTL_HTTP は SET_HEADER で任意のヘッダーを付けられるので、Authorization: Bearer を自分で書けば成功します（表 1 の 5）。5.1・5.2 章の実測は SEND_REQUEST とこの経路の両方で、5.3 章の 50 問バッチはこの経路で取っています。資格証明を使う SET_CREDENTIAL は、パスワードを PL/SQL に書かずに認証を付けるための手続きで3、構文の scheme はデフォルト 'Basic' です。公式ページには他に指定できる値が書かれていません。実測では 'Basic' が httpbin に対して Authorization: Basic ... を付けて 200 でした。'Digest' は 200 でもヘッダー無しです（Digest 認証はサーバーからの 401 応答を受けてからヘッダーを送るため）。'Bearer' 'bearer' 'OAuth' はいずれも ORA-29261 でした。UTL_HTTP で Bearer を使うなら、キーは SET_HEADER にバインド変数で渡すことになります。

ADB の Select AI 自身も LLM の呼び出しに UTL_HTTP を使っている（待機イベントに UTL_HTTP 由来の区間が出る）ことは前作で確かめており5、これと同じ経路です。

4. 手順

4.1. ACL の登録

UTL_HTTP は宛先ホストごとに ACL が必要です。SEND_REQUEST で顧客管理エンドポイントを呼ぶ公式の例にも、先に ACL を登録する手順が書かれています4。ADMIN で次を実行しました。ポートは 443 だけに絞っています。

BEGIN
  DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE(
    host       => 'api.typesafe.ai',
    lower_port => 443,
    upper_port => 443,
    ace        => xs$ace_type(privilege_list => xs$name_list('http'),
                              principal_name => 'ADMIN',
                              principal_type => xs_acl.ptype_db));
END;
/

UTL_HTTP で ACL を登録していないホストに送ると ORA-29273: HTTP request failed だけが返り、原因が ACL だとは分かりません。切り分け用の httpbin.org も同じ手順で登録しました。

4.2. SEND_REQUEST で Jev を呼ぶ PL/SQL

資格証明を作り、URI を bearer:// で始めて SEND_REQUEST を呼びます。ユーザー名は使われないので任意の文字列で構いません。本文の JSON は :body にバインドしています。

BEGIN
  DBMS_CLOUD.CREATE_CREDENTIAL(
    credential_name => 'JEV_CRED',
    username        => 'BEARER_TOKEN',
    password        => 'ts-xxxxxxxxxxxxxxxx');  -- Jev の API キー
END;
/

DECLARE
  l_resp DBMS_CLOUD_TYPES.resp;
BEGIN
  l_resp := DBMS_CLOUD.SEND_REQUEST(
              credential_name => 'JEV_CRED',
              uri             => 'bearer://api.typesafe.ai/v1/systemone',
              method          => DBMS_CLOUD.METHOD_POST,
              headers         => JSON_OBJECT('Content-Type' VALUE 'application/json'),
              body            => UTL_RAW.CAST_TO_RAW(:body));
  :status := DBMS_CLOUD.GET_RESPONSE_STATUS_CODE(l_resp);
  :text   := DBMS_CLOUD.GET_RESPONSE_TEXT(l_resp);
END;
/

4.3. UTL_HTTP で Jev を呼ぶ PL/SQL

同じ本文を UTL_HTTP で送るコードです。キーは :key にバインドします。ADB の公開ホスト宛てなので SET_WALLET は不要です。

DECLARE
  l_req  UTL_HTTP.req;
  l_res  UTL_HTTP.resp;
  l_buf  VARCHAR2(32767);
  l_txt  CLOB;
BEGIN
  l_req := UTL_HTTP.BEGIN_REQUEST('https://api.typesafe.ai/v1/systemone', 'POST', 'HTTP/1.1');
  UTL_HTTP.SET_HEADER(l_req, 'Content-Type', 'application/json');
  UTL_HTTP.SET_HEADER(l_req, 'Authorization', 'Bearer ' || :key);
  UTL_HTTP.SET_HEADER(l_req, 'Content-Length', LENGTHB(:body));
  UTL_HTTP.WRITE_TEXT(l_req, :body);
  l_res := UTL_HTTP.GET_RESPONSE(l_req);
  :status := l_res.status_code;
  DBMS_LOB.CREATETEMPORARY(l_txt, TRUE);
  BEGIN
    LOOP
      UTL_HTTP.READ_TEXT(l_res, l_buf, 32767);
      DBMS_LOB.WRITEAPPEND(l_txt, LENGTH(l_buf), l_buf);
    END LOOP;
  EXCEPTION
    WHEN UTL_HTTP.end_of_body THEN NULL;
  END;
  UTL_HTTP.END_RESPONSE(l_res);
  :text := l_txt;
END;
/

4.4. Jev に渡す JSON

Noul は「この文は真か」を 0〜1 で返します。state に判定対象を、questions に質問を入れます。

{
  "model": "jev-latest",
  "state": "SQL statement: DELETE FROM sales WHERE order_date < DATE '2025-01-01'",
  "questions": {
    "readonly": {
      "type": "noul",
      "instructions": "Is this SQL statement read-only (it does not modify data or schema)?"
    }
  }
}

応答は次のとおりです。noul が 0.01 なので「参照専用ではない」と判定しています。

{"model":"jev-1.13.0","answers":{"readonly":{"type":"noul","noul":0.01}},"usage":{"input_tokens":304,"output_tokens":20}}

Choice は criteria に選択肢を並べ、1 つを選ばせます。今回は s001〜s255 のキーで SQL 文を 255 本入れ、「本番で最も危険な文はどれか」と聞きました。255 本のうち 250 本は SELECT * FROM <表> WHERE id = <n> で、DROP TABLE・DELETE（WHERE 無し）・TRUNCATE TABLE・UPDATE（給与を 10 倍）・ALTER TABLE ... DROP COLUMN の 5 本を 17・88・133・201・249 番目に混ぜてあります。

まとめて聞くには、state に判定対象を番号つきで並べ、questions を対象の数だけ付けます。50 本の SQL なら次の JSON で、q1〜q50 の Noul が 1 回の応答に含まれます。

{
  "model": "jev-latest",
  "state": "SQL statements proposed by an AI agent:\n[1] SELECT * FROM orders WHERE id = 100\n[2] DELETE FROM sales WHERE id = 200\n ...（50 本）",
  "questions": {
    "q1": {"type": "noul", "instructions": "Is statement [1] read-only (it does not modify data or schema)?"},
    "q2": {"type": "noul", "instructions": "Is statement [2] read-only (it does not modify data or schema)?"},
    "...": {}
  }
}

50 本の内訳は読み取り 35 本（単表の SELECT、JOIN と GROUP BY、WITH 句）と変更 15 本（DELETE、UPDATE、TRUNCATE、DROP、ALTER、INSERT、MERGE）で、順序は固定シードでシャッフルしています。

5. 結果

5.1. Noul 1 問

手元の PC から直接呼んだ場合と、ADB の中から 2 つの方式で呼んだ場合を表 3 に並べます。ADB 経由の値には、東京の ADB から米国の Jev までの往復が含まれます。

呼び出し元 DELETE 文の noul（所要時間） 短い SELECT 文を 10 回呼んだ所要時間（最小 / 中央値 / 最大）
PC（PowerShell） 0.01（670 ms） 472 / 540 / 623 ms
ADB（SEND_REQUEST、bearer://） 0.01（616 ms） 485 / 539 / 609 ms
ADB（UTL_HTTP） 0.01（591 ms） 467 / 563 / 969 ms

表 3: Noul 1 問の判定と所要時間

判定は 3 経路とも同じで、所要時間もほぼ同じでした。PC から呼んだときの SELECT 文は 0.99（457 ms）で、SELECT 文に 1 付近を返す想定（1.2 章）と一致します。ADB の中で呼んでも、PC から呼ぶ場合と比べて所要時間の増加は見られません（中央値の差は 1 ms と 23 ms）。

5.2. Choice 255 択

255 本の SQL から「最も危険な 1 本」を選ばせた結果が表 4 です。混ぜた 5 本のうち、UPDATE 以外の 4 本が 3 経路とも上位 4 位に入りました。confidence は確率分布の集中度で、1 位の確率が 0.49〜0.61 にとどまるため 0.48〜0.6 になっています。

順位 PC から（765 ms） ADB SEND_REQUEST（731 ms） ADB UTL_HTTP（1,018 ms）
1 DROP TABLE orders 0.61 DROP TABLE orders 0.57 DROP TABLE orders 0.49
2 TRUNCATE TABLE sales 0.23 TRUNCATE TABLE sales 0.22 TRUNCATE TABLE sales 0.34
3 DELETE FROM customers 0.08 DELETE FROM customers 0.11 DELETE FROM customers 0.08
4 ALTER TABLE products DROP COLUMN price 0.02 ALTER TABLE products DROP COLUMN price 0.02 ALTER TABLE products DROP COLUMN price 0.03
confidence 0.6 0.56 0.48

表 4: Choice 255 択の上位 4 件

順位は 3 回とも同じでしたが、確率の値は 1 位で 0.61・0.57・0.49 と差があります。同じ本文でも確率は揺れるものとして、本記事では順位で比較します。トークンは 3 回とも入力 6,554・出力 2,571 でした。UPDATE 文（salary = salary * 10）は 250 本の SELECT と同じ 0.01 以下で、「危険」の候補には上がりませんでした。

5.3. 50 問をまとめて聞く

50 本の SQL を state に入れ、Noul 50 問を 1 回のリクエストで送った結果が表 5 です（UTL_HTTP 経由）。3 回とも 50 問すべて正答で、所要時間は Noul 1 問のとき（5.1 章）と同じ 0.5〜0.6 秒の範囲でした。

回 所要時間 正答 トークン
1 589 ms 50 / 50 入力 2,396 / 出力 895
2 533 ms 50 / 50 入力 2,396 / 出力 895
3 507 ms 50 / 50 入力 2,396 / 出力 895

表 5: Noul 50 問を 1 回のリクエストで送った結果

noul の値は、読み取りの 35 本が 0.89〜1.0、変更の 15 本がすべて 0.01 で、0.5 を境に分かれ、0.02〜0.88 の値は 1 本もありませんでした。

比較のために、同じ 50 本を OCI Generative AI の Llama 3.3 70B に「YES か NO だけで答えよ」と 1 本ずつ聞くと、こちらも 50 本すべて正答で、1 本あたり 116〜266 ms（中央値 121 ms）、50 本の合計は 6,590 ms でした。

6. 考察

6.1. SEND_REQUEST は URI スキームで認証方式を指定する

DBMS_CLOUD.SEND_REQUEST の credential_name は「対応するクラウドネイティブ API で認証するための資格証明」、headers は「認証ヘッダーは自動で設定されるので、カスタムヘッダーだけ渡す」と説明されています6。登録済みでないホストに対しては URI スキームで認証方式を指定する、というのが URI 形式のドキュメントの記述で、bearer:// basic:// public:// s3:// oci:// の 5 つがあります4。bearer:// で渡すと資格証明が Bearer ヘッダーになり、https:// のまま渡すと同じ資格証明が SigV4 で署名されました（表 1、8 章）。

https:// のときに S3 互換扱いになる（8 章）のは、ユーザー名とパスワードだけの資格証明を持つ形式が表 2 の中では basic:// と s3:// の 2 つで、スキーム指定が無いときのデフォルトが後者になっているためと考えられます（公式にデフォルトの記述は見つけられませんでした）。

UTL_HTTP でも同じ API を呼び出せます（表 1 の 5）。使い分けは次のとおりです。キーを DB の資格証明に置いて PL/SQL から見えなくしたいなら SEND_REQUEST の bearer://、ヘッダーやレスポンスの読み方を細かく制御したいなら UTL_HTTP です。

6.2. まとめて聞くと 1 回で済む理由

Jev のドキュメントには「質問は並列に評価される。質問を足しても応答時間はほとんど変わらない」とあります2。50 問を 1 回のリクエストで送っても 0.5〜0.6 秒で、1 問のときの中央値（539〜563 ms）と同じ範囲でした（表 3・表 5）。生成型の LLM に 1 本ずつ YES/NO を聞く方法だと、1 本が 0.1〜0.3 秒でも 50 本で 6.6 秒かかります。

ただし 1 問だけなら、東京の ADB から大阪の Llama 3.3 70B に判定させるほうが速いという結果でした（中央値 121 ms 対 539〜563 ms）。Jev の公開されているエンドポイントは 2026 年 9 月時点で米国のみで1、東京からの往復がそのまま所要時間に加わるためと考えられます。1 問ずつ聞く使い方なら近いリージョンの生成モデル、N 本をまとめて判定する使い方なら Jev、という使い分けになりそうです。

Jev のコンテキストは 32,000 トークンなので7、まとめて入れられる本数には上限があります。今回の 50 本（1 本 40〜100 文字の SQL）で入力 2,396 トークンでした。

6.3. AI が作った SQL のガードには SQL Firewall がある

今回は「SQL が参照専用か」を Jev に判定させましたが、これは題材として分かりやすかったからで、本番で AI の生成した SQL を止める用途なら、ADB では SQL Firewall が使えます。SQL Firewall は許可リストとの照合だけで（確率を使わずに）SQL を実行前に止める機能で、確率で判定する Jev とは性質が違います。前作で ADB での有効化と止まり方を確かめています8。LLM の出力を別の AI モデルで判定する構成は、判定が揺れる（5.2 章の確率の揺れ）ぶん、実行可否の最終判断には使えないと考えられます。

6.4. API キーの置き場所

SEND_REQUEST の bearer:// なら、キーは CREATE_CREDENTIAL で作った資格証明に入れたままで、PL/SQL の本文にもバインド変数にも出てきません。資格証明はスキーマオブジェクトなので、権限のあるユーザーしか使えず、パスワードを読み出すこともできません3。今回の用途ではこちらのほうが手順が少なく済みます。

UTL_HTTP でキーを渡すには SET_HEADER にバインド変数で入れるしかありませんでした（SET_CREDENTIAL は Bearer を受け付けない）。バインド変数で渡した値は、V$SQL_BIND_CAPTURE や統合監査の設定によっては記録される可能性があります。今回は残るかどうかを確かめていないので、UTL_HTTP を選ぶならバインドキャプチャと監査ポリシーの対象を確認したうえで決めるのがよいと考えられます（要追加検証）。

7. まとめ

  • ADB から Jev のような Bearer 認証の REST API を呼ぶなら、DBMS_CLOUD.SEND_REQUEST の URI を bearer:// で始める。キーは DB の資格証明に置ける
  • 認証方式は URI スキーム（basic:// bearer:// public:// など）で自分で指定する。https:// のまま渡すと AWS 署名で送られる（8 章）
  • UTL_HTTP と ACL でも呼び出せるが、キーはバインド変数で渡すことになる
  • Jev は 50 問を 1 回で 0.5〜0.6 秒、50 問正答。1 問ずつなら近いリージョンの生成モデルのほうが速く、N 本まとめて判定するときに向く

本記事の計測は 2026 年 9 月 19 日時点のものです。Jev はベータ提供のため、仕様や料金（入力 100 万トークンあたり 0.042 ドル、出力は無料9）は変わる可能性があります。

8. 付録: https:// のまま渡すと何が送られるか

本筋ではありませんが、bearer:// に辿り着く前に https:// のまま SEND_REQUEST を呼んで 401 になった原因を残しておきます。表 1 の 2・3 に当たります。

表 1 の 2 で使った資格証明は、Data Share 機能の PL/SQL パッケージ DBMS_SHARE のドキュメントに「ユーザー名 BEARER_TOKEN で作った資格証明は Bearer トークン扱い」と書かれているのを見て試したものです10。しかしこれは Data Share の仕組みで、SEND_REQUEST の認証には使われませんでした。実際に何が送られたのかを知るために、同じ資格証明で https://httpbin.org/post（受け取ったヘッダーをそのまま返す公開サービス）に送ると、次のヘッダーが付いていました（署名の値だけ伏せています）。

Authorization: AWS4-HMAC-SHA256 Credential=BEARER_TOKEN/20260919///aws4_request, SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date, Signature=<64 桁の 16 進数>
X-Amz-Content-Sha256: 44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a
X-Amz-Date: 20260919T071138Z
User-Agent: DBMS_CLOUD PLSQL Client/1.0.0

AWS の API 認証で使う署名バージョン 4（SigV4）の形式です。OCI の DB が AWS の署名を作るのは、DBMS_CLOUD が OCI Object Storage だけでなく、Amazon S3、Azure Blob Storage、Google Cloud Storage、S3 互換ストレージも扱うパッケージだからです4。

api.typesafe.ai は登録済みのホストではないため、https:// のまま渡した場合は表 2 のいずれの個別スキームにも該当せず、ユーザー名とパスワードの資格証明が S3 互換（s3:// 相当）として扱われたと考えられます。Credential=BEARER_TOKEN/20260919///aws4_request のリージョンとサービス名が空なのは、URL から取れなかったためと考えられます。

参考

  1. TypeSafe AI Docs: Quickstart（エンドポイント POST /v1/systemone、Bearer 認証、model jev-latest、curl の例） ↩ ↩2 ↩3

  2. TypeSafe AI Docs: Choice（選択肢は最大 255。質問は並列に評価され、質問を足しても応答時間はほとんど変わらない。probabilities の和は 1、confidence は分布の広がりから計算） ↩ ↩2

  3. Call Web Services from Autonomous AI Database（Oracle 公式。公開ホストへの UTL_HTTP と ACL の例、SEND_REQUEST の位置づけ、SET_CREDENTIAL の構文と資格証明オブジェクトの説明） ↩ ↩2 ↩3

  4. DBMS_CLOUD URI Formats: Additional Customer-Managed URI Formats（Oracle 公式。登録済みでないホストは URI スキーム basic:// bearer:// oci:// public:// s3:// で認証方式を指定する。public:// を send_request に渡す例と、ACL を先に登録する例） ↩ ↩2 ↩3 ↩4 ↩5

  5. Select AI Agent は DB の中でどう動いているか（前作。RUN_TEAM の LLM 呼び出しは UTL_HTTP で、待機イベントは TCP Socket (KGAS)） ↩

  6. DBMS_CLOUD REST APIs: SEND_REQUEST Function and Procedure（Oracle 公式。credential_name はクラウドネイティブ API 用、認証ヘッダーは自動設定） ↩

  7. Jev (typesafe) · Cloudflare AI docs（コンテキスト 32,000 トークン、入出力 JSON の形） ↩

  8. Oracle Autonomous Database の SQL Firewall を試してみた（前作。許可リストに無い SQL を実行前に止める） ↩

  9. Introducing System One Models & Jev（TypeSafe AI Blog）（入力 0.042 ドル / 100 万トークン、出力は無料） ↩

  10. Generate Bearer Token（DBMS_SHARE）（Oracle 公式。ユーザー名 BEARER_TOKEN の資格証明は Data Share 向け） ↩

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?