OCI Enterprise AIのHosted ApplicationでWeb APIを公開する最小検証手順

Last updated at 2026-10-08Posted at 2026-10-05

はじめに

OCI Generative AIのEnterprise AIでは、Responses APIを使ったモデルの呼び出しと、独自のAI処理を実装したコンテナのHosted実行を組み合わせて、AIアプリケーションを構築できます。本稿で使うProject・Application・Deploymentの役割は次のとおりです。

リソース	役割	本稿での使い方
Project（プロジェクト）	OCIのOpenAI互換APIを呼び出す際に指定する管理単位	Project OCIDを`GENAI_PROJECT_OCID`として渡し、Responses APIの呼び出しに使用する
Application（アプリケーション）	Hostedで動かすAIアプリの認証、ネットワーク、環境変数、スケーリングを管理する	Web APIを公開し、Generative AIへの接続情報を環境変数で設定する
Deployment（デプロイメント）	Applicationで実行するコンテナイメージとタグを指定する	OCIRの`iam-demo-app:verify-v1`を選び、デプロイして有効化する

ProjectはOpenAI互換APIの利用に必要です。Applicationには実行時の設定をまとめ、Deploymentでイメージを配置します。今回はこの仕組みを使い、Hosted Application自身がリクエストを受け取り、Responses APIで生成した回答を返す最小構成を検証します。

本稿で検証する構成

1つのコンテナをHosted Applicationへ配置し、認証なしのWeb APIとして公開します。Hosted内からGenerative AIを呼ぶ通信はResource Principalで認証します。

ブラウザ／HTTPクライアント
  ↓ HTTPS（Hostedへのアクセスは認証なし）
Hosted Application（FastAPI・Web API・Web画面）
  ↓ Resource PrincipalでIAM認証
OCI Responses API（Chicago）

適用条件：ご利用環境のHosted Application作成画面で「認証なし」を選択できることを前提にします。2026年10月5日に確認した公開の作成手順にはIdentity DomainとOCI IAMのみが記載されており、認証なしの具体的なAPIパラメーターは確認できませんでした。Applicationはコンソールで作成し、認証なしを明示します。選択肢がない環境ではこの手順のまま実施できません。

全リソースを Chicago（us-chicago-1） に作成します。tenancy直下にPolicyを新規作成せず、既存の検証用Compartmentを使います。実環境の検証結果は実施後に記入してください。

操作	使用するもの
IAM、Project、OCIR、Application・Deploymentの作成・削除	OCIコンソール
イメージのビルド・Push	方法①：PCのDocker、方法②：Git＋OCI DevOps
HealthCheck・推論の確認	ブラウザ・APIテスト用アドオン、またはBashスクリプト（curl）

1. 準備

ChicagoでGenerative AIのProjectsとResponses APIを利用できること。
検証用Compartment、本稿ではiam-agent-labを使用すること。別名なら本文の名前を置換する。
構築するユーザーに、対象CompartmentのGenerative AI、OCIRの管理権限があること。
対象CompartmentのPolicy管理権限があること。Dynamic Group管理権限がない場合は2.2のワークアラウンドを選ぶ。Policy管理権限もない場合はCompartment管理者へ依頼する。
DockerとOCI CLIは準備済みであること。Git版を使う場合はGitも利用できること。

サンプルコード

サンプルコード一式をダウンロード

ソース一式ZIPを展開し、ターミナルでoci-iam-hosted-app-demoへ移動すること。

以降のコマンドはBash形式です。Bash・curlが利用できるターミナルで実行します。アプリ用のPythonやjqを別途準備する必要はありません。ターミナルで一度bashを実行してBashに入り、次の設定を行います。

bash

Bashに入った後、次を実行します。コマンド失敗時は後続へ進まず、原因を解消して5.1の変数から再設定します。

set -euo pipefail

ソース一式にはapp/（Python・HTML・Dockerfile）、prepare-images.sh、test-deployment.sh、build_spec.yamlが含まれます。アプリ・Dockerfileは同梱のものをそのまま使います。

イメージ作成は方法①・方法②のどちらでも構いません。5章で片方だけ実施してください。 同じ1つのイメージをOCIRへ配置できれば、その後のデプロイ・検証手順は共通です。

選択する方法	PCに必要なもの	実施する節
① Gitなし・Dockerでビルド／Push	Docker	5.1 → 5A → 6章以降
② Gitあり・OCI DevOpsでビルド／配置	Git。Dockerは不要	5.1 → 5B → 6章以降

2. コンソールでIAMを設定する

2.1 Dynamic Group

2.2のワークアラウンドを使う場合、この節は省略します。 通常方式では、Identity & Security → Domains → 対象ドメイン → Dynamic groupsで次の1つを作成します。<COMPARTMENT_OCID>を検証CompartmentのOCIDへ置換します。既存の適切なグループを使う場合は作成不要です。

名前	Matching rule
`dg-iam-agent-hosted`	`ALL {resource.compartment.id = '<COMPARTMENT_OCID>', ANY {resource.type = 'generativeaihostedapplication', resource.type = 'generativeaihostedapplicationiam', resource.type = 'generativeaihosteddeployment'}}`

2.2 実行用Policy

Identity & Security → Policiesで、作成先をiam-agent-labにしてiam-agent-lab-runtimeを作成します。次の通常方式・ワークアラウンドのどちらか一方を使用します。

通常方式：Dynamic Groupを使用する

<DOMAIN>は2.1のDynamic Groupを作成したIdentity Domain名です。

Allow dynamic-group '<DOMAIN>'/'dg-iam-agent-hosted' to read repos in compartment iam-agent-lab
Allow dynamic-group '<DOMAIN>'/'dg-iam-agent-hosted' to manage generative-ai-family in compartment iam-agent-lab

Resource Principalで認証したリソースへアクセス権限を付与するPolicyです。tenancy直下には作成しません。 対象CompartmentのPolicy管理権限がない場合はCompartment管理者へ、Dynamic Group管理権限がない場合は、下記のワークアラウンドを使用できます。

ワークアラウンド：Dynamic Groupを作成できない場合

2.1のDynamic Groupを作成せず、同じCompartment内のPolicyに次の2行を設定します。<呼び出し元CompartmentのOCID>をHosted ApplicationとDeploymentを作成するCompartmentのOCIDへ置換します。今回、アクセス先も同じiam-agent-labを使用します。

Allow any-user to read repos in compartment iam-agent-lab where all {request.principal.compartment.id = '<呼び出し元CompartmentのOCID>'}

Allow any-user to manage generative-ai-family in compartment iam-agent-lab where all {request.principal.compartment.id = '<呼び出し元CompartmentのOCID>'}

request.principal.compartment.idは呼び出し元の所属Compartmentを条件にする変数です。in compartment iam-agent-labはアクセス先の範囲です。公式の変数定義。条件にはCompartment名ではなくOCIDを使用します。

3. コンソールでProject・OCIR・Auth Tokenを用意する

Chicagoを選び、Analytics & AI → Generative AI → Projects → Create projectでiam-agent-labにProjectを作成します。Project OCIDを控え、使用するモデルのAPI識別子がChicagoで利用可能なことを確認します。
Developer Services → Containers & Artifacts → Container Registryで、Chicago / iam-agent-labに次のPrivate Repositoryを1つ作成します。
- iam-demo-app
Object Storage Namespaceを控えます。
My profile → Tokens and keys → Auth Tokens → Generate tokenで検証用Auth Tokenを発行します。Dockerログイン（方法①）に使います。トークンは発行時にしか取得できません。安全に保存し、画面キャプチャには含めません。

HostedがPrivate Repositoryからイメージを取得する権限は2章のread reposで付与します。Hosted側へOCIR Auth Tokenは設定しません。手動のスキャン設定は本手順に含めません。Deploymentは6章でコンソールから作成します。

4. サンプルのAPIとWeb画面

アプリは0.0.0.0:8080で待ち受けます。Hostedのコンテナ要件に合わせ、linux/amd64でビルドします。

パス	方法	応答・用途
`/health`	GET	JSON：アプリの稼働確認
`/ready`	GET	JSON：Chicago・Project・モデルIDの設定確認。認可確認は含まない
`/api/chat`	POST	JSON：メッセージを受けてGenerative AIの回答を返す
`/ui`	GET	HTML：同じHosted URL配下の`/api/chat`を呼ぶ検証画面

POST <API endpoint>/api/chatへ送るJSONは次の形式です。Authorizationヘッダーは付けません。

{"message":"OCIのResource Principalを一文で説明してください。"}

成功時はHTTP 200で、{"answer":"生成された回答","response_id":"..."}を返します。7章ではAPIテスト用アドオンまたはスクリプトのどちらか一方で推論を確認します。

Web画面は/ui（末尾スラッシュなし）で開きます。JavaScriptは相対URLを使うため、Hostedの長いエンドポイントのパスを保ったままAPIを呼びます。OCIの鍵やトークンをブラウザへ渡しません。

コンテナ要件はJSON／ストリーミングの応答を説明しています。HTML応答の通過は実環境で確認が必要です。本検証ではJSON APIの動作を必須判定とし、HTML画面表示は別に確認します。

5. イメージを作成してOCIRへ配置する（どちらか一方）

方法①・方法②のどちらでも検証できます。両方を実施する必要はありません。

5.1 共通の設定値

展開したoci-iam-hosted-app-demoのルートで、<...>を置換して実行します。モデルIDはChicagoで利用できるものにします。

export OcirHost='ord.ocir.io'
export OcirNamespace='<NAMESPACE>'
export OcirLogin='<NAMESPACE>/<DOMAIN>/<USERNAME>'
export GenaiProjectOcid='<Project OCID>'
export GenaiModelId='xai.grok-4.3'
export ImageTag='verify-v1'
AppImage="${OcirHost}/${OcirNamespace}/iam-demo-app:${ImageTag}"

従来型OCIRユーザーのログイン名は<NAMESPACE>/<USERNAME>の場合があります。Auth Tokenはコード・Dockerfile・環境変数・Gitへ保存しません。

5A. 方法①：Gitなし・DockerによるビルドとPush

準備済みのDockerへ接続できることを、次のコマンドで確認します。スクリプトはHostedの要件に合わせて--platform linux/amd64を指定します。

docker version
docker info

Server側へ接続できることを確認し、同梱スクリプトを実行します。

bash prepare-images.sh --push

Passwordには3章のAuth Tokenを入力します。このスクリプトはDockerで1イメージをlinux/amd64でビルドし、SDK importとローカルHTTPを確認して、OCIRへPushします。ローカルでは推論を呼びません。

artifacts/images-<実行ID>/summary.txtがStatus=PASS、ImagePushed=trueになること。
OCIRコンソールでRepositoryにverify-v1が存在すること。

スクリプト内部の主要コマンドはdocker build --pull --platform linux/amd64 -f .../Dockerfile ...、docker login ord.ocir.io、docker push ...です。スクリプトと手動コマンドを重複実行する必要はありません。Gitへのアップロードは行いません。成功後は6章へ進みます。

5B. 方法②：Git＋OCI DevOpsによるビルドとOCIRへの配置

この手順ではOCI Code RepositoryをGitの保存先にします。OCI DevOpsのManaged Buildで1イメージを作り、Deliver ArtifactsでOCIRへ配置します。Oracle Linux 8のBuild RunnerはPodmanを使用しますが、これはOCI側の処理です。公式Managed Build手順

5B.1 DevOps用の権限

DevOps、Notifications、Loggingを管理できるユーザーが作業します。既存権限が不足する場合、Compartment管理者がiam-agent-lab内のPolicyへ以下を追加します。<DOMAIN>/<BUILDERS_GROUP>は作業ユーザーの実際のグループです。

Allow group '<DOMAIN>'/'<BUILDERS_GROUP>' to manage devops-family in compartment iam-agent-lab
Allow group '<DOMAIN>'/'<BUILDERS_GROUP>' to manage ons-family in compartment iam-agent-lab
Allow group '<DOMAIN>'/'<BUILDERS_GROUP>' to manage log-groups in compartment iam-agent-lab
Allow group '<DOMAIN>'/'<BUILDERS_GROUP>' to manage log-content in compartment iam-agent-lab

Dynamic Group方式では、IAM管理者がdg-iam-agent-buildを作成します。<COMPARTMENT_OCID>を置換します。作成権限がない場合は、このDynamic Groupの作成と下記のDynamic Group用Policyを省略し、後述のDevOps用ワークアラウンドを使用します。

ALL {resource.type = 'devopsbuildpipeline', resource.compartment.id = '<COMPARTMENT_OCID>'}

Compartment内のPolicyへ次を追加します。ドメインは上記Dynamic Groupを作成したドメインです。

Allow dynamic-group '<DOMAIN>'/'dg-iam-agent-build' to manage devops-family in compartment iam-agent-lab
Allow dynamic-group '<DOMAIN>'/'dg-iam-agent-build' to manage repos in compartment iam-agent-lab
Allow dynamic-group '<DOMAIN>'/'dg-iam-agent-build' to use ons-topics in compartment iam-agent-lab
Allow dynamic-group '<DOMAIN>'/'dg-iam-agent-build' to use log-content in compartment iam-agent-lab

この検証用PolicyもCompartment範囲です。tenancy直下には作成しません。DevOpsの公式Policy例

DevOps用ワークアラウンド：Dynamic Groupを作成できない場合は、Compartment内のPolicyに次を設定します。<呼び出し元CompartmentのOCID>はBuild Pipelineを作成するCompartmentのOCIDです。上記の作業ユーザー用Group Policyは別途必要です。

Allow any-user to manage devops-family in compartment iam-agent-lab where all {request.principal.compartment.id = '<呼び出し元CompartmentのOCID>'}
Allow any-user to manage repos in compartment iam-agent-lab where all {request.principal.compartment.id = '<呼び出し元CompartmentのOCID>'}
Allow any-user to use ons-topics in compartment iam-agent-lab where all {request.principal.compartment.id = '<呼び出し元CompartmentのOCID>'}
Allow any-user to use log-content in compartment iam-agent-lab where all {request.principal.compartment.id = '<呼び出し元CompartmentのOCID>'}

2.2と同じ一般IAM仕様を応用した案で、指定Compartment内のPrincipal全体に権限を付与します。Build・OCIR配置での認可は実環境で確認します。

5B.2 DevOps ProjectとGit Repositoryを作成する

全てChicago / iam-agent-labで作成します。

Developer Services → Application Integration → NotificationsでTopic iam-agent-demo-topicを作成します。Subscriptionを作成し、必要な確認を完了します。既存の利用可能なTopicを使う場合は作成不要です。
Developer Services → DevOps → Projects → Create DevOps projectで名前をiam-agent-demo-buildとし、上記Topicを指定します。これは3章のGenerative AI Projectとは別です。
ProjectのLoggingを有効にします。Log Groupをiam-agent-lab内に作成・選択します。Pipeline実行にはProjectのLoggingが必要です。Project作成
Code Repositories → Create repositoryで、名前iam-agent-demo-code、既定ブランチmainの空Repositoryを作成します。
RepositoryのClone → HTTPSからURLをコピーします。Chicagoのホストであることを確認します。

5B.3 コードをGitへPushする

ソース一式のルートから実行します。Gitの認証には、ユーザー名<TENANCY_NAME>/<DOMAIN>/<USERNAME>と3章のAuth Tokenを使います。Git用の先頭はTenancy nameです。OCIRログイン用Namespaceと取り違えないでください。 ユーザー名・トークンはGitの認証画面へ入力し、URLへ埋め込みません。HTTPS認証

SourceDirectory="$PWD"
GitCloneUrl='<コンソールからコピーしたChicagoのHTTPS Clone URL>'
GitWorkDirectory="$(dirname "$SourceDirectory")/oci-iam-demo-git"
git clone "$GitCloneUrl" "$GitWorkDirectory"
# 下記のソースだけをコピーする。資格情報や実行結果はコピーしない。
for name in app build_spec.yaml .gitignore prepare-images.sh test-deployment.sh; do
  cp -R "$SourceDirectory/$name" "$GitWorkDirectory/"
done
cd "$GitWorkDirectory"
# 未設定の場合のみ、公開してよい値をこのRepositoryへ設定
git config user.name '<コミット作成者名>'
git config user.email '<コミット作成者メール>'
git add app build_spec.yaml .gitignore prepare-images.sh test-deployment.sh
git diff --cached --name-only

表示された対象にAuth Token、秘密鍵、.oci、.env、実行結果が含まれていないことを確認し、Pushします。同梱.gitignoreはこれらのファイルを除外します。

git commit -m 'Add Hosted Generative AI Web API demo'
git branch -M main
git push -u origin main

build_spec.yamlはRepositoryのルートへ置きます。app/をさらに別の親フォルダーへ入れません。Git版で5B.3以降を同じBashセッションで続ければ、5.1の変数は保持されます。

5B.4 Managed Buildを追加する

DevOps ProjectのBuild Pipelines → Create build pipelineでiam-agent-demo-imagesを作成します。
Add stage → Managed Buildを選び、名前をbuild-imagesにします。
Build RunnerはOracle Linux 8・x86/amd64を選択します。利用可能なx86の既定Shapeを使用し、Private network accessは設定しません。
Build sourceはOCI Code Repository、Repositoryはiam-agent-demo-code、branchはmain、source nameはSource1にします。
Build specification pathをbuild_spec.yaml、timeoutを1800秒にして追加します。

同梱のビルド定義は次のとおりです。イメージを作成・import確認し、1つをBuildの出力として渡します。この段階ではOCIRへPushしていません。

version: 0.1
component: build
timeoutInSeconds: 1800
shell: bash
failImmediatelyOnError: true
env:
  variables:
    IMAGE_TAG: "verify-v1"
steps:
  - type: Command
    name: Build and check the amd64 image
    command: |
      set -euo pipefail
      cd "${OCI_PRIMARY_SOURCE_DIR}"
      podman build --pull=always --platform linux/amd64 --format docker -t "iam-demo-app:${IMAGE_TAG}" -f app/Dockerfile app
      test "$(podman image inspect "iam-demo-app:${IMAGE_TAG}" --format '{{.Os}}/{{.Architecture}}')" = linux/amd64
      podman run --rm --entrypoint python "iam-demo-app:${IMAGE_TAG}" -c "import httpx; from openai import OpenAI; from oci_openai import OciResourcePrincipalAuth; c=OpenAI(api_key='placeholder',project='placeholder',http_client=httpx.Client()); assert hasattr(c,'responses'); c.close(); print('App imports OK')"
outputArtifacts:
  - name: app_image
    type: DOCKER_IMAGE
    location: iam-demo-app:verify-v1

5B.5 Deliver Artifactsを追加する

DevOps ProjectのArtifacts → Add artifactで、Container image型の参照を1つ作成します。URI内の<NAMESPACE>を実値へ置換し、Parameterizationは無効にします。

DevOps Artifact名	Container image URI	Build result Artifact name
`app-image`	`ord.ocir.io/<NAMESPACE>/iam-demo-app:verify-v1`	`app_image`

PipelineでManaged Buildの後ろの＋ → Add stage → Deliver Artifactsを選び、名前をdeliver-imagesにします。上記1つのDevOps Artifactを選び、各Build result Artifact nameを表どおり設定します。build_spec.yamlのoutputArtifacts.nameと一致させます。公式Deliver Artifacts手順

DevOps Artifactは配置先を指す参照です。実際のイメージ格納先は3章で作成したOCIR Repositoryです。

5B.6 ビルドして配置を確認する

PipelineでStart manual runを選び、mainと対象コミットを確認して実行します。今回は自動Triggerを作成しません。
Managed BuildとDeliver Artifactsの両方がSucceededになるまで待ちます。
OCIRコンソールでRepositoryにverify-v1が存在することを確認します。
失敗時はBuild runのLogsを確認します。clone失敗はDevOps権限・Repository設定、配置の403はDynamic Group・manage repos・対象Compartmentを確認します。

画面キャプチャ⑤（Git版のみ）：Gitのコミット、Pipelineの2ステージSucceeded、OCIRのタグ。Auth Token・ログ中の個人情報をマスクします。

タグを変更する場合は、5.1の$ImageTag、build_spec.yamlのIMAGE_TAGとoutputArtifacts.location、DevOps ArtifactのURIを同じタグへ変更してコミット・Pushします。成功後は6章へ進みます。

6. ApplicationとDeploymentを作成する

6.1 Applicationをコンソールで作成する

Chicagoを選択し、Analytics & AI → Generative AI → Applications → Create applicationを開きます。

項目	値
Compartment	`iam-agent-lab`
Application Name	`iam-agent-demo-app`
Authentication	認証なし。画面のNone / No authentication等の対応する選択肢を明示的に選ぶ
Minimum / Maximum replicas	`1` / `1`
Storage / Cache / Database	無効
Outbound Networking	Default / service-managed
Endpoint	Public
環境変数 `GENAI_REGION`	`us-chicago-1`
環境変数 `GENAI_PROJECT_OCID`	3章のProject OCID
環境変数 `GENAI_MODEL_ID`	5.1のモデルID

DefaultというApplication type名だけで認証なしと判断せず、認証設定を確認します。Identity Domainの入力を要求される設定は今回の対象ではありません。作成してActiveになるのを待ち、Application OCIDを控えます。VCN・Container Instanceは不要です。

認証なしはHostedへの入口の設定です。Hosted→Generative AIのResource Principal認証と2章のPolicyは必要です。OCI_RESOURCE_PRINCIPAL_*などのサービスが提供する予約環境変数は追加・上書きしません。

画面キャプチャ③：認証なしの選択肢と、作成後のApplicationの認証・ネットワーク・環境変数の設定。

6.2 DeploymentをOCIコンソールで作成する

ChicagoのGenerative AI → Applicationsで、6.1のApplicationを開きます。
Deployments → Create deploymentを選びます。
次のイメージ情報を設定します。名前を入力できる場合はiam-agent-demo-deployにします。

項目	値
Repository compartment	`iam-agent-lab`
Repository	`iam-demo-app`
Version tag	`verify-v1`。変更した場合は5章でPushしたタグ
Deploy and activate	有効

Create deploymentを押します。イメージのアドレスがord.ocir.io/<NAMESPACE>/iam-demo-app:verify-v1に対応することを確認します。
DeploymentがActiveとなり、コンテナが起動してReadyになるまで待ちます。作成直後のActive表示だけでAPIの動作確認を完了したと判断せず、7.1のHealthCheckへ進みます。

公式のコンソール作成手順。失敗時はWork requestのエラーと、2章のread repos、イメージURI、タグを確認します。再作成前に既存Deploymentを確認してください。

コンソール作成時にスキャン要件を変更できる項目は公開手順では確認できていません。本手順ではスキャン設定を追加せず、コンソールの設定で作成します。スキャンを理由に失敗した場合は、Work requestの内容を記録して追加対応を判断します。スキャン不要で必ず作成できるという保証はありません。

Application詳細のAPI endpointをコピーし、/actions/invokeまでを指定します。ホスト・APIバージョン・Applicationのパスは画面の値をそのまま使用し、hostedApplicationsIam等へ手動で書き換えません。末尾の/<custom_path>は削除します。

HostedBaseUrl='<ChicagoのAPI endpoint。/actions/invokeまで>'

7. 動作確認する

以降の<HostedBaseUrl>は、6.2でコピーした**/actions/invokeまでのURL**です。<custom_path>は置換用の文字列で、実際のURLには含めません。ブラウザ・アドオンには実際のURLを入力します。

7.1 Web画面で確認する場合

ブラウザで<HostedBaseUrl>/ui（末尾スラッシュなし）を開き、メッセージを1回送信して回答が表示されることを確認します。API確認に加えて推論1回が実行されます。DevToolsのNetworkで/api/chatがHTTP 200であること、リクエストにOCIのAuthorizationやAuth Tokenが含まれないことを確認します。HTML応答の通過は実環境で確認し、JSON APIとは別に結果を記録します。

7.2 ブラウザでHealthCheckを確認する

認証ヘッダーを設定せず、アドレスバーへ次のURLを入力して開きます。

URL	期待する応答
`<HostedBaseUrl>/health`	HTTP 200、`{"status":"ok"}`
`<HostedBaseUrl>/ready`	HTTP 200、`{"status":"ready"}`

ブラウザのDevToolsを開き、Networkを表示します。
/healthを開くか再読み込みし、応答のStatusが200、本文が{"status":"ok"}であることを確認します。
/readyも同じ方法で確認します。

/healthはアプリの稼働確認、/readyは環境変数の設定確認です。両方成功してもGenerative AIの認可・推論が成功したことにはなりません。推論を呼ばないため、HealthCheckの再確認で推論リクエストは増えません。Hostedサービス内部の自動HealthCheck設定は、このブラウザ確認とは別です。

7.3 APIテスト用アドオンで確認する

例としてTalend API Tester – Free Editionを使用します。同じMethod・URL・Headers・Bodyを指定できる別のアドオンでも構いません。公式のリクエスト編集手順

アドオンを開き、新規リクエストを作成します。

まずHealthCheckを確認します。

項目	値
Method	GET
URL	`<HostedBaseUrl>/health`
Header	`Accept: application/json`
Authorization	設定しない。既存のAuthorizationヘッダーがあれば削除
Body	なし

Sendを押し、HTTP 200と{"status":"ok"}を確認します。URLを<HostedBaseUrl>/readyへ変更し、HTTP 200と{"status":"ready"}も確認します。

次にAI処理を確認します。7.3のスクリプトを使う場合は、このPOST確認を省略できます。

項目	値
Method	POST
URL	`<HostedBaseUrl>/api/chat`
Header	`Content-Type: application/json`
Header	`Accept: application/json`
Authorization	設定しない
Body形式	JSON / Raw text

Bodyに次を入力します。

{"message":"OCIのResource Principalを日本語で一文で説明してください。"}

Sendを1回だけ押し、応答を待ちます。HTTP 200で、JSON本文に空でないanswerとresponse_idがあればAPIの確認は成功です。リクエストを再送するたびに推論が追加で実行されます。

7.4 スクリプトで確認する場合（7.3のPOSTの代替）

同じBashセッションで実行します。URLは**/actions/invokeまで**で、末尾に/api/chatを付けません。スクリプトがパスを追加します。

bash test-deployment.sh "$HostedBaseUrl"

認証ヘッダーなしのhealth・readyと推論1回を確認し、結果をartifacts/deployment-<実行ID>/へ保存します。summary.txtがHTTP_PASS_CONTENT_CHECK_PENDINGになり、chat.jsonに空でないanswerとresponse_idがあることを確認します。HTTP 200だけでは回答内容の合格判定にはなりません。

7.5 失敗時の確認

HealthCheckの入口で401/403ならHostedの認証なし設定を確認します。404なら<custom_path>を残していないか、URLとパスを確認します。/readyが503ならGENAI_REGION=us-chicago-1、Project OCID、モデルIDを確認します。

/api/chatの本文にstage=responsesがある場合はHosted→Responses APIの呼び出しで失敗しています。upstream_status=401/403はResource Principal・Policy・ProjectのCompartmentを確認します。Dynamic Group方式ならMatching rule、ワークアラウンドならrequest.principal.compartment.idのOCIDを確認します。HTTPに到達しない場合はPublic endpoint・Deploymentの状態・コピーしたURLを確認します。推論を連続で再送せず、原因を確認してから再実行します。

8. コンソールで後片付けする

この検証で新規作成したものだけを、次の順で削除します。

Hosted Deployment → Hosted Application → Generative AI Project。
Git版で新規作成したDevOps Pipeline・Artifact参照・Code Repository・DevOps Project・Logging・Notifications Topic／Subscriptionを削除する。共有リソースは残す。
OCIRの検証用イメージ・Repository。
検証専用Policy・Dynamic Group、検証用Auth Token。共有Compartmentは削除しません。

削除完了を確認してから次へ進みます。依存リソースが残っている場合は、所有する検証用リソースだけを先に削除します。

方法①を使用したPCでは、Dockerのログインと検証用イメージも片付けます。方法②だけなら、このコマンドは不要です。

docker logout "$OcirHost"
docker rmi "$AppImage"

参考資料

Public＋認証なしのAPIはURLを知る第三者も呼び出せる設定です。検証後はDeploymentとApplicationを削除します。

作成側ではBash構文、ビルド定義、アプリとスクリプトの模擬応答での処理を確認しています。実際のDocker／DevOpsビルドとOCIRへのPush、認証なしでのHostedアクセス、HTML応答の通過、OCI上のResource Principal認可と推論は未実施で、実施者が検証します。

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