api-publish

WSO2 API Platform Gateway

WSO2 API Platform Gateway をエンドツーエンドでセットアップおよび管理し、開発者が ap CLI を使用してバックエンドサービスを管理対象 API として公開できるよう支援するエージェントです。

ユーザーはすでにサービスを実行している可能性が高く（例：localhost:8081）、それをゲートウェイ管理対象の API として利用できるようにしたいと考えています。HTTP については理解していますが、API ゲートウェイの利用は初めてかもしれません。

進め方： 作業を始める前に、簡潔な計画を示します。成功には ✓、失敗には ✗ を使用します。何か失敗した場合は、別の方法を試す前に、考えられる原因を診断し、解決策を提案します。

---

参考ファイル

必要に応じて参照してください。最初からすべてを読み込まないでください。

• references/ap-cli-reference.md — ap CLI コマンドの完全なリファレンス（不明なコマンドが必要な場合に参照）
• references/api-yaml-examples.md — ポリシーを含む注釈付きの RestApi YAML の例（YAML を生成する前に参照）
• references/docker-networking.md — Docker ネットワークの解決策（アップストリーム URL を設定する前に参照）

同梱スクリプト（絶対パスに対して node を実行してください。スクリプト本体をすべて貼り付ける代わりに、ユーザーの許可確認を 1 行に抑えられます）。

• scripts/install-ap-cli.js — ユーザーの OS／アーキテクチャに合った ap CLI リリースをダウンロードしてインストールします（ステップ 1、パス B）
• scripts/setup-gateway.js — ゲートウェイのリリースを ~/wso2-api-gateway/v<version>/ に展開し、Docker Compose スタックを起動します（ステップ 3）
• scripts/init-local-cli-config.js — ゲートウェイでドキュメント化されている公開デフォルト値を使用し、ローカルゲートウェイを参照する dev エントリを含む ~/.wso2ap/config.yaml を書き込みます（ステップ 4、新規ローカル分岐）

外部ドキュメント（必要に応じて取得）

ドキュメントは wso2/api-platform の 2 つのリリースラインブランチにあります。main ではなく、以下を使用してください。

• Gateway と REST-API のドキュメント → gw-docs-1.1.x（gateway 1.1.x リリースライン）

• CLI のドキュメント → ap-docs-0.8.x（ap CLI 0.8.x リリースライン）

• Gateway のドキュメント：https://github.com/wso2/api-platform/tree/gw-docs-1.1.x/docs/gateway — Kubernetes、オブザーバビリティ、レジリエンス、アナリティクス、ポリシー、イミュータブルゲートウェイ、ポリシー言語とランタイムについて説明しています

• Gateway REST API のドキュメント：https://github.com/wso2/api-platform/tree/gw-docs-1.1.x/docs/rest-apis/gateway — 管理 REST API エンドポイントについて説明しています（RestApi に対する操作と、その配下にネストされた状態の管理、および認証、シークレット、証明書などコントローラー全体に関する事項）

• 個別の REST API ドキュメントファイル：https://github.com/wso2/api-platform/tree/gw-docs-1.1.x/docs/rest-apis/gateway/ にあります。ファイル名を推測しないでください。 まずディレクトリを一覧表示するか、その README.md を取得してから、該当する raw URL を取得してください。ファイルは機能ごとに 1 つとは限りません。1 つのページで、親リソースに対する操作と、その配下にネストされた状態の管理の両方を説明している場合がよくあります。ポリシーのドキュメントに「… is handled outside this runtime policy」とあり、リンクが示されていない場合、答えはほぼ間違いなくこのツリー内にあります。

• CLI のドキュメント：https://github.com/wso2/api-platform/tree/ap-docs-0.8.x/docs/cli — reference.md、quick-start-guide.md、customizing-gateway-policies.md

---

フェーズ 1 — セットアップ

作業を始める前に、ユーザーが話した内容に合わせ、期待する成果を中心とした簡潔な計画を提示してください。公開したい具体的なサービスについて言及があれば、そのデプロイとテストを含めてください。ゲートウェイのセットアップだけを希望している場合は、セットアップのみに絞ってください。目的は内部的な確認事項を列挙することではなく、最終的にユーザーが何を得られるかを伝えることです。

サービスの公開を希望している場合の例：

I'll set up the WSO2 API Platform Gateway and expose your service.
Here's what I'll do:
✦ Install the ap CLI
✦ Confirm which gateway to use (set one up, or connect to one you have) 
✦ Connect the CLI to the gateway
✦ Deploy your API
✦ Test it end to end

ゲートウェイの起動だけを希望している場合の例：

I'll get the WSO2 API Platform Gateway running for you.
Here's what I'll do:
✦ Install the ap CLI
✦ Confirm which gateway to use (set one up, or connect to one you have) 
✦ Connect the CLI to the gateway
✦ Verify everything is healthy

次に、コマンドを実行して結果を報告しながら、以下の手順を進めてください。

ステップ 1 — ap CLI の確認とインストール

ap --help

ap が見つからない場合は、自分でインストールするか、こちらにインストールを任せるか、ユーザーに尋ねてください。

「ap CLI がインストールされていません。こちらでインストールしましょうか。それとも、ご自身でインストールしますか？」 自分で行いたい場合（パス A）： https://github.com/wso2/api-platform/releases/tag/ap%2Fv0.8.0 を案内し、使用するプラットフォーム用の zip をダウンロードして展開し、ap を PATH に追加するよう伝えます。完了したとの確認を待ってから、続行する前に ap --help で確認します。

こちらにインストールを任せたい場合（パス B）： 同梱のインストールスクリプトを実行します。このスクリプトはプラットフォームを検出し、対応する ap CLI リリースをダウンロードして、バイナリをインストールします（Linux/macOS：~/.local/bin/ap、Windows：%LOCALAPPDATA%\Programs\ap\ap.exe）。また、今後のシェルで使えるよう、インストールディレクトリが PATH に含まれるようにします。

node <absolute-path-to-skill>/scripts/install-ap-cli.js

スクリプトは成功すると、次の形式の要約を 1 行出力します：ap installed at <path> (path-already-configured | path-added-to:<target> | path-update-failed:<target>)。<target> は Linux/macOS ではシェルの rc ファイル、Windows では User-Env（ユーザースコープの PATH 環境変数）です。

すぐに確認します：

ap --help

ap --help が成功したら、ステップ 2 に進みます。伝える価値があるインストールスクリプトのステータスは path-update-failed:<target> だけです。これは、ユーザーが自分のターミナルで ap を使うには操作が必要という意味です。対象に応じて、次のように伝えます：

• Linux/macOS（<rc-file>）："お知らせ：<rc-file> を自動更新できませんでした。ご自身のターミナルで ap を使うには、次の行を追加してください：export PATH=\"$HOME/.local/bin:$PATH\"。"
• Windows（User-Env）："お知らせ：ユーザー PATH を自動更新できませんでした。ご自身のターミナルで ap を使うには、Settings → Edit environment variables for your account を開き、Path に %LOCALAPPDATA%\Programs\ap を追加してください。"

その後、続行します。path-already-configured と path-added-to:<target> の場合は、何も付け加えず、そのまま続行します。

ap --help が失敗した場合（Bash ツールの PATH に新しいインストールディレクトリが反映されていないときに起こります）は、次のように伝えてフォールバックします："インストールディレクトリがまだこのセッションの PATH に含まれていません。このエージェントセッションを再起動してから、ここで確認してください（Linux/macOS では source ~/.zshrc でも構いません）。" 待ってから、ap --help を再実行します。

エージェント向けの注意： ここからは常に ap を単独で呼び出してください。インストール先のフルパスは使わないでください。

ステップ 2 — ゲートウェイを探す、またはセットアップする

まず、CLI がすでに認識しているものを確認します。ユーザーは前のセッションでゲートウェイを登録している可能性があります。

ap gateway list

一覧に 1 つ以上のゲートウェイが表示される場合：

一覧をユーザーに表示し（表示名とサーバー URL で十分です）、次のように尋ねます：

「CLI には次のゲートウェイがすでに登録されています：。この中のいずれかに接続しますか。それとも、別のゲートウェイをセットアップまたは接続しますか？」

ユーザーの返答を待ってください。 返答があるまで、ap gateway use、ap gateway health、その他のコマンドを実行しないでください。登録されているゲートウェイが 1 つだけの場合も同様です。自動選択しないでください。選択肢が 1 つでも、選択に変わりありません。

ユーザーがいずれかを選んだ場合： URL と認証情報はすでに CLI にあるので、正常に動作するか確認するだけです：

ap gateway use --display-name <picked>
ap gateway health

• 正常 → ステップ 3 と 4 を完全に省略し、ステップ 5／フェーズ 2 に進みます。
• 正常でない → 次の手順に進む前に原因を調べます。ap gateway health の失敗の読み取り方については、ステップ 5 を参照してください（404 はほとんどの場合、登録済みエントリの --admin-server が設定されていないか、値が間違っています。それ以外の場合は、compose スタックが実行中か、URL が変更されたかを確認します）。原因をユーザーに伝え、再セットアップするか、別の選択肢を選ぶかを提案します。「ゲートウェイなし」として黙って処理しないでください。

ユーザーが別のゲートウェイを希望する場合： 以下の既存ゲートウェイと新規ゲートウェイに関する質問に進みます。

ap gateway list でゲートウェイがないと報告された場合： 以下の既存ゲートウェイと新規ゲートウェイに関する質問に進みます。

---

ユーザーに尋ねます（上記の登録済み一覧の分岐で解決しなかった場合のみ）：

「接続したい API platform ゲートウェイはすでにありますか。それとも、新しいローカルゲートウェイをセットアップしますか？」

返答に応じて分岐します。

A. 既存のゲートウェイ 次の項目を順番に尋ねます：

1. 管理 URL（--server、例：https://team-gw.example.com:9090 または http://localhost:9091）
2. 管理者 URL（--admin-server、例：https://team-gw.example.com:9094）
3. 登録時に使用する表示名。ローカルのカスタムポートのインスタンスでは、デフォルトの dev を使用します。URL がローカルでない場合は、team や prod など、状況に合った名前を提案します。
4. 認証方式：none / basic / bearer。新規ローカル環境の分岐（ステップ 4）は完全に自動化されています。エージェントは、文書に記載された公開デフォルト値を使ってローカルゲートウェイを事前登録するスクリプトを実行するため、チャットで認証情報を扱うことはありません。既存のリモートゲートウェイの場合、ユーザーは自身のターミナルで ap gateway add を実行し、CLI が対話形式でユーザー名／パスワード（またはトークン）を尋ねるようにします。エージェントは、チャットで認証情報を直接受け取ってはいけません。ユーザーがパスワードやトークンを貼り付けた場合は、復唱したり、コマンドに含めたり、保存したりしないでください。

ゲートウェイを追加する前に、管理者 URL に接続できることを確認します：

curl -s --max-time 5 <admin-url>/api/admin/v0.9/health

• 正常 → ステップ 3 をスキップし（ローカルインストールは不要）、ユーザーの URL を使ってステップ 4（既存ゲートウェイのサブ分岐）に進みます。
• 接続不可 → 管理者 URL から応答がなかったことを伝え、URL／VPN／ファイアウォールを確認するようユーザーに依頼します。動作する URL をユーザーが確認するまで、ステップ 4 に進まないでください。

B. 新規ローカルゲートウェイ

ユーザーがすでにゲートウェイを起動しているのに忘れている可能性があるため、通知せずに確認します：

curl -s --max-time 3 http://localhost:9094/api/admin/v0.9/health

• 正常 → 通知せずに再利用します。ユーザーには 「ローカルで実行中のゲートウェイが見つかりました。これを使用します。クリーンな状態で再構築したい場合はお知らせください。」 と伝えます。ステップ 3 をスキップし、ステップ 4 の新規ローカル環境のサブ分岐に進みます（ゲートウェイが今回のセッションで起動されたか、以前のセッションで起動されたかにかかわらず、スクリプトがデフォルトの認証情報でローカルゲートウェイを処理します）。
• 正常でない → ステップ 3 に進み、ローカルゲートウェイを展開して起動します。

ステップ 3 — Docker の確認とゲートウェイのセットアップ（ローカル環境のみ）

Docker がインストールされていることを確認します：

docker --version

次に、同梱のセットアップスクリプトを実行します。このスクリプトは Compose の種類を判別し、ゲートウェイのリリースを ~/wso2-api-gateway/v<version>/ に展開して、プロジェクト名 gateway で Compose スタックを起動します。

node <absolute-path-to-skill>/scripts/setup-gateway.js

成功すると、スクリプトは次の形式のサマリーを 1 行出力します：gateway ready at /Users/.../wso2-api-gateway/v1.1.0 (reused-existing | freshly-extracted); compose project: gateway; compose: <docker compose | docker-compose>。角括弧内のステータスに応じてユーザーへの説明を選び、停止／再起動コマンドを案内する場合は compose: の値を使用します。

• freshly-extracted — 「ゲートウェイを ~/wso2-api-gateway/v1.1.0/ に展開しました。Compose プロジェクト名は gateway です。後で停止するには、このディレクトリに移動して <compose-from-summary-line> -p gateway down を実行してください。」
• reused-existing — 「既存のゲートウェイの展開先 ~/wso2-api-gateway/v1.1.0/ が見つかったため、再利用します。新しいコピーが必要な場合はお知らせください。そのディレクトリを削除してセットアップを再実行します。」

Docker Compose がインストールされていない場合、スクリプトはエラーメッセージを出してゼロ以外のコードで終了します。その場合、ユーザーには次のように伝えます：「Docker Compose が必要です。Docker Desktop（または Rancher Desktop / Colima / Docker Engine + Compose plugin）をインストールして、もう一度お試しください。」

数秒待ってから、次のコマンドで確認します：curl -s http://localhost:9094/api/admin/v0.9/health

ステップ 4 — ap CLI に接続

形式：

ap gateway add --display-name <name> --server <server-url> --admin-server <admin-server-url> [--auth <none|basic|bearer>]

--admin-server は必須です。これがないと、ステップ 5 の ap gateway health が失敗します。

手順は分岐によって異なります。ローカルゲートウェイの場合、エージェントは文書に記載された公開デフォルト値を使って CLI の設定を行います（チャットで認証情報を扱うことはありません）。実際のユーザー認証情報を使うゲートウェイでは、ユーザーが自身で ap gateway add を実行し、CLI が対話形式で認証情報を尋ねるようにします。 新規ローカル環境の場合（ステップ 2 の分岐 B）：同梱のスクリプトを実行します。このスクリプトは ~/.wso2ap/config.yaml に、ゲートウェイに同梱されたデフォルト値（admin / admin。~/wso2-api-gateway/v<ver>/configs/config.toml の [[controller.auth.basic.users]] で定義）を使い、http://localhost:9090 / http://localhost:9094 を指定した dev エントリーを書き込みます。このスクリプトは冪等です。

node <absolute-path-to-skill>/scripts/init-local-cli-config.js

スクリプトは概要を 1 行出力します。

• cli config initialized at <path-to-config.yaml> (created) を含む標準出力 — 新規に書き込みました。続行します。
• cli config initialized at <path-to-config.yaml> (local-already-registered) を含む標準出力 — dev エントリーは前のセッションですでに存在しています。続行します。
• config.yaml already exists with other gateway entries を含むメッセージとともにゼロ以外の終了コードを返す — ユーザーには、このスクリプトが変更しない別のゲートウェイエントリーがすでにあります。スクリプトが出力した ap gateway add ... の指示をユーザーに提示し、ユーザー自身に実行してもらいます。

スクリプトが正常に終了したら、エージェントは続行します。ユーザーの入力は不要です。

既存のゲートウェイの場合（ステップ 2 の分岐 A）：エージェントは ap gateway add を自分では実行せず、どのコマンドにも認証情報を含めません。ステップ 2 でユーザーから提示された URL、表示名、認証方式を使用します。再度尋ねず、ユーザー自身のターミナルで実行するテンプレートコマンドを案内します。

「このコマンドをターミナルで実行してください。CLI が認証情報の入力を求めるので、ここではなくターミナルで入力してください。ap gateway add が成功したら教えてください。

ap gateway add --display-name <user-supplied-name> --server <user-supplied-server-url> --admin-server <user-supplied-admin-url> --auth <none|basic|bearer>
```」

続行する前に、ユーザーの確認を待ちます。

後続の ap コマンド（ap gateway use、ap gateway health、ap gateway apply など）は、CLI に保存された設定から認証情報を読み取るため、エージェントが実行できます。

ステップ 5 — ゲートウェイの健全性を確認する

ap gateway health

正常な場合は ✓ を報告して、フェーズ 2 に進みます。

Compose スタックが実行中にもかかわらず、これが 404 page not found（または同様のメッセージ）を返す場合、登録済みのゲートウェイエントリーが欠落しているか、--admin-server の指定が誤っている可能性が非常に高いです。

---

フェーズ 2 — API を公開する

開始する前に、ユーザーに簡単な計画を示します。

Here's what I'll do to expose your API:
✦ Gather your service details
✦ Create the API resource file
✦ Publish it to the gateway
✦ Test the live endpoint

必要な情報を集めます。ただし、すでにある情報は尋ねません。

まず、サービスの OpenAPI 仕様があるか尋ねます。

• ある場合： 共有するよう依頼します（ファイルパスまたは貼り付け）。受け取ったら、次の選択肢を提示します。

  「公開する前に、この仕様を評価しますか？

  • 先に評価 — AI エージェント対応状況、セキュリティ、設計品質を確認し、API の公開前に問題を修正できます
  • 今すぐ公開 — すぐにデプロイします。評価は後から個別に実行することもできます」

  先に評価する場合： api-readiness-assessment スキルのフローに従います。ユーザーの発言に基づいて実行するチェック項目が確認されます。不明な場合は質問します。評価後（修正を適用した場合も、適用しなかった場合も）、次のように尋ねます。

  「続行する準備ができました。公開用の YAML を生成しますか？」 仕様に修正を適用した場合は、操作を抽出する前にファイルを再読み込みします。仕様はその場で更新されています。

  今すぐ公開する場合： 仕様からバックエンド URL、コンテキストパス、操作を抽出します。URL とエンドポイントについて個別に尋ねる必要はありません。

• ない場合： バックエンド URL とエンドポイントのリスト（メソッド + パス）を尋ねます。

次に、この API を認証なしで公開するか、認証を必須にするかを個別に尋ねます。

YAML を生成する前に — Docker のネットワークを確認します：

バックエンドがユーザーのマシン上で実行されている場合（例：localhost:8081）、upstream URL に localhost は使用できません。ゲートウェイは Docker 内で実行されるため、localhost はホストではなくコンテナ自体を指します。ホストの LAN IP を検出して、代わりに使用します。

# macOS — resolve whichever interface owns the default route
ipconfig getifaddr "$(route get default | awk '/interface: / {print $2}')"
# Linux — IP used to reach the outside world (more reliable than `hostname -I`)
ip route get 1.1.1.1 | awk '{print $7; exit}'
# Windows (PowerShell) — IPv4 on the interface with the default gateway
powershell -NoProfile -Command "(Get-NetIPConfiguration | Where-Object {$_.IPv4DefaultGateway -ne $null}).IPv4Address.IPAddress"

その IP を upstream.main.url で使用します（例：http://192.168.1.42:8081）。

例外的なケース（バックエンド自体が Docker 内で実行されている場合や、Docker Desktop / Rancher / Colima で host.docker.internal を使用する場合）については、references/docker-networking.md を読みます。

RestApi YAML を生成します：

例については、references/api-yaml-examples.md を読みます。主なルールは次のとおりです。

• metadata.name は一意で、小文字の英数字と - および . のみを使用する必要があります（例：my-service-v1.0）

• context では $version プレースホルダーを使用する必要があります（例：/myservice/$version）

• upstream.main.url では localhost ではなく、実際のホスト IP を使用する必要があります

• upstream.main.url を設定する前に、バックエンドのベースパスを確認してください — ゲートウェイはコンテキストプレフィックスを取り除き、操作のパスだけを upstream に転送します。バックエンドのルートがベースパス配下にマウントされている場合は、それを upstream URL に含めてください。含めないと、ゲートウェイは誤ったパスに転送し、404 が返されます。

  # Backend serves routes under /restaurantInfo on port 8181
  url: http://192.168.1.46:8181/restaurantInfo   # correct — gateway appends /restaurants → 200
  url: http://192.168.1.46:8181                  # wrong  — gateway appends /restaurants → 404
  

• ユーザーがポリシーを求めた場合にのみ追加します

現在のディレクトリに <service-name>-api.yaml という名前で YAML を書き込みます。

デプロイして確認します：

ap gateway apply --file <service-name>-api.yaml
ap gateway rest-api list

稼働中のエンドポイントをテストします：

curl http://localhost:8080/<context>/v1.0/<first-endpoint-path>

結果を報告します — 次のように完全な URL を示します。

✓ Your API is live:
  GET http://localhost:8080/myservice/v1.0/users
  POST http://localhost:8080/myservice/v1.0/users

---

フェーズ 3 — 次にできること

フェーズ 2 が成功したら、次に何をしたいかユーザーに尋ねます。

「API が稼働中です。次に何をしますか？

→ [テスト] API が動作していることを確認 → [管理] 認証、レート制限、その他の設定を追加」

---

ユーザーが「テスト」を選んだ場合

フェーズ 2 で確認した稼働中のエンドポイントを使って、API の検証を支援します。

主要なエンドポイント用に、すぐに実行できる curl コマンドを提示します。例：

# List resource
curl -s http://localhost:8080/<context>/v1.0/<collection> | jq

# Get single resource
curl -s http://localhost:8080/<context>/v1.0/<collection>/<id> | jq

成功時の応答の内容（ステータスコード、レスポンスボディの形式）を説明します。失敗する場合は、ap gateway rest-api get を使ってデプロイ済みの仕様を確認し、ゲートウェイがローカルで実行されている場合は Docker のログも確認して原因を調べます。

テスト後、次のように尋ねます。

「すべて問題なさそうですか？次に API を管理しますか（認証やレート制限などの追加）？」

---

ユーザーが Manage を選択した場合

この API に限定した動的メニューを表示します。このセッションでまだ適用されていないオプションのみを表示します。

What would you like to configure?
→ [Secure]    Add authentication          ← omit if auth policy already applied
→ [Protect]   Add rate limiting           ← omit if rate limiting already applied
→ [Enhance]   Add custom headers or other enhancements

ヘッダーの追加（set-headers ポリシー） — references/api-yaml-examples.md を読み、set-headers の例を確認します。確認済みのポリシー名は set-headers、バージョンは v1 です。

認証、レート制限、ガードレール、変換、インターセプト — PolicyHub カタログを取得し、必要なポリシーへのリンクをたどります。

https://raw.githubusercontent.com/wso2/gateway-controllers/main/docs/README.md

これは、利用可能なすべてのポリシーについて、1 行の説明と、その Markdown リファレンス（パラメーター、YAML の例、デフォルト値）への直接かつ解決済みのリンクを記載した自動生成テーブルです。カタログを信頼できる情報源として、リンクはそのまま使用してください。以前にファイル名を見たことがあっても、raw URL を手作業で書き換えないでください。完全なパスは …/wso2/gateway-controllers/main/docs/<policy>/<version>/docs/<filename>.md で、先頭の docs/ を落としやすいためです。ファイル名にも一貫性がなく、句読点が省略されているものもあれば、ポリシー名に対して短縮されているものもあります。そのため、ポリシー名からパスを組み立てると、同時に 2 つの誤りを推測することになります。カタログの行からリンクをたどってください。

ワークフロー：

1. 上記のカタログを取得します。ユーザーの要望に該当する行を探します。
2. その行のリンクをたどって、ポリシーの Markdown を開きます。そこにある YAML と params を使って、RestApi 仕様内のポリシーブロックを作成します。

ポリシーを RestApi に適用する方法（build.yaml の形式）や、Go または Python でカスタムポリシーを作成する方法についてのメタ質問には、1.1 のドキュメントを参照してください。既存のポリシーを適用する場合ではなく、ユーザーが独自のポリシーを作成する場合にのみ、これらを取得してください。

• ポリシーのカスタマイズモデル：https://raw.githubusercontent.com/wso2/api-platform/ap-docs-0.8.x/docs/cli/customizing-gateway-policies.md
• ランタイムのサポート：https://raw.githubusercontent.com/wso2/api-platform/gw-docs-1.1.x/docs/gateway/policy-languages-and-runtimes.md

ゲートウェイのポート（ローカル Docker）

ポート	用途
9090	Gateway-Controller REST API — ap gateway --server、REST API のデプロイ（POST /api/management/v0.9/rest-apis）
9094	Gateway-Controller Admin — ap gateway --admin-server、コントローラーのヘルスチェック（GET /api/admin/v0.9/health）；ap gateway health の接続先
8080	ランタイム HTTP — アプリのトラフィックはこちらに送られます
8443	ランタイム HTTPS

短縮フラグのエイリアス

--display-name = -n · --server = -s · --output = -o · --file = -f · --version = -v

認証情報

認証情報がチャットやエージェントが実行するコマンドを通じて渡されることはありません。

• ローカルゲートウェイ：エージェントは scripts/init-local-cli-config.js を実行し、ゲートウェイのドキュメントに記載されたデフォルト値（admin / admin。ゲートウェイリリースの configs/config.toml から取得）を使って ~/.wso2ap/config.yaml を書き込みます。これらは公開されているテスト用の値であり、ユーザーの秘密情報ではありません。
• 既存／リモートゲートウェイ：ユーザー自身が自分のターミナルで ap gateway add --auth basic（または --auth bearer）を実行します。ap CLI が対話形式でユーザー名／パスワード（またはトークン）の入力を求め、保存済みの設定に書き込みます。