|

OpenBotをAPIYIに接続できない?3つの環境変数でAI同僚が自分でパソコンを起動

OpenBotをAPIYIに接続できない?3つの環境変数でAI同僚が自分でパソコンを起動

著者注:OpenBot には「モデルを選ぶ」画面がありません。モデルは .env とテナントパッケージの model.yaml で指定します。この記事では、環境変数3行と YAML 1行を変更して APIYI に接続する方法を解説します。まず3つのコンピュータツールだけを許可し、「Webページを開く+ファイルを読む+監査ログを確認する」という一連の操作で動作を検証します。

CopilotKit の OpenBot をクローンし、.env.example を開いて、フロントエンドの画面もあちこち探してみたものの、「モデルプロバイダーを選択」というドロップダウンが見つからない。OpenAI で直接使えるクレジットカードは持っておらず、APIYI の従量課金で claude-opus-5-5 を使いたいのに、モデルの設定場所さえ分からない。

先に結論を言うと、OpenBot には「モデルを選ぶ」スイッチがありません。モデルは .env とテナントパッケージの model.yaml で指定します。APIYI への接続にコードの変更は不要です。環境変数を3行、YAML を1行変更するだけで済みます。設定後はまず3つのコンピュータツールだけを許可し、動作確認が済んでから必要に応じてほかのツールも開放しましょう。

この記事は「ワンクリックで動く」チュートリアルではありません。OpenBot 自体はテンプレートであり、動かすには Docker、Bun 1.4 以上、CopilotKit Intelligence のプロジェクト、そしてモデル用の APIキーが必要です。これらの前提条件も、この記事で分かりやすく説明します。また、GitHub には OpenBot という名前のプロジェクトが2つありますが、この記事で扱うのは CopilotKit の OpenBot です。

この記事でできるようになること:3か所の設定を自分で正しく変更し、3つのツールから始めて、「Webページを開く+ファイルを読む+監査ログを確認する」という一連の操作で動作を検証できます。400、401、モデルが存在しない、ツールが呼び出されない、起動が拒否されるといったよくある問題に備えて、トラブルシューティング表も用意しています。

openbot-apiyi-env-config-guide-ja-image-0


OpenBotのモデルは画面から設定しない

OpenBotは製品ではなくテンプレート

CopilotKit/OpenBotは、2026年8月17日に作成されたMITライセンスのオープンソースリポジトリです。2026年11月2日時点で9,561スターを獲得しており、最新の正式リリースはv0.2.0(2026年10月12日)です。READMEの冒頭には、引き続きBetaと明記されています。

OpenBotが掲げるのは、AIの同僚一人ひとり(リポジトリ内ではBotと呼ばれます)に専用のコンピューターを持たせることです。そこには本物のブラウザ、個別のログイン状態、自分のファイル、そして利用を許可されたツールが備わっています。

READMEには、これは「A template, not a product(製品ではなくテンプレート)」だとはっきり書かれています。登録して使えるホスト型サービスはなく、依存パッケージとしても公開されていません。リポジトリをクローンし、examples/配下のサンプルテナントパッケージを独自の同僚・チャンネル・スキルに置き換えて、自分で実行するのが正しい使い方です。つまり、「モデルはどこで選ぶのか」という問いの答えは、画面ではなく設定ファイルにあります。

OpenBotを動かすための4つの前提条件

以下の表は、モデルを接続する前に準備しておく必要があるものです。どれか一つでも欠けると、その後の設定を検証できません。

前提条件 具体的な要件 説明
Docker PostgreSQL(pgvectorを含む)と付属のBotを実行 scripts/start.shがDockerサービスを起動し、マイグレーションを実行
Bun 1.4以上 依存パッケージのインストールにbun installを使用
CopilotKit Intelligence プロジェクトとライセンスが必要。無料プランあり ローカル評価環境はmacOS + Docker Desktop。ローカルライセンスの有効期間は30日で、npx copilotkit@latest local renewで更新可能
モデルのキー OpenAI互換エンドポイントのキー この記事ではAPIYIのトークンを使用。base_urlはhttps://api.apiyi.com/v1

特に見落としやすいのがIntelligenceです。.env.exampleのコメントには、IntelligenceのURL、gateway URL、またはキーがない場合、サーバーは起動を拒否すると明記されています。原文では「There is no degraded mode.(機能を制限して動作するモードはない)」と書かれています。

永続スレッドと記憶はIntelligenceが保持しているため、これがなければ会話のたびにコンテキストが失われます。そのため、OpenBotを「完全にオフライン」で使えるソリューションとは言えません。

OPENAI_BASE_URLの変更はデプロイ全体に適用される

READMEには「no model ships in the box(モデルは同梱されていない)」とあります。モデルはパッケージに含まれず、認証情報は管理者が提供します。認証情報は暗号化されてデータベースに保存され、ログには出力されません。

モデルを決めるのはデプロイ単位の環境変数です。中でも重要なのがOPENAI_BASE_URLです。公式の説明では、同じAPIに対応するエンドポイントであれば、マルチプロバイダーのゲートウェイ、プロキシ、自分のハードウェアで実行しているモデルなどを指定できます。.env.exampleのコメントには、/v1/chat/completionsをサポートするエンドポイントなら何でも使えると、さらに具体的に書かれています。

この変数は個々のBotではなく、デプロイ全体に適用されます。API serverが内蔵エージェント向けに使うクライアント、独自にクライアントを構築するagent-bot、BOT_PROVIDER=openaiのagent-langgraphという3か所すべてが、この変数を読み込みます。公式によると、この仕組みのメリットは、同じデプロイ内でリクエストの半分が新しいアドレスに向かい、残りの半分が古いアドレスに向かう、といった事態を防げることです。

openbot-apiyi-env-config-guide-ja-image-1


3か所の変更で APIYI に接続:OpenBot の環境変数を設定する

OpenBot と APIYI の接続ポイント

APIYI は OpenAI 互換のインターフェースを提供しています。base_url に https://api.apiyi.com/v1 を設定すると、リクエストは /v1/chat/completions に送られ、OpenBot の OPENAI_BASE_URL の要件を満たせます。

もう一点、OpenBot はモデル名をそのまま送信します。APIYI の /v1/models が返すモデル名は、プレフィックスのない claude-opus-5-5 です。そのため、公式ゲートウェイの例を参考にして openai/ プレフィックスを付けないでください。公式例の openai/gpt-5.6-terra は、モデル名に名前空間が付いているエンドポイントでのみ使用できます。

まずは設定の一覧を確認し、続いて手順に沿って進めましょう。

変更箇所 設定値 理由
.env の OPENAI_API_KEY APIYI のコンソールで作成した sk-... トークン 組み込みエージェントと2つの付属 Bot は、デフォルトでこのキーを使用するため
.env の OPENAI_BASE_URL https://api.apiyi.com/v1 デプロイ全体のモデルリクエストを APIYI の互換エンドポイントに向けるため
.env の BOT_MODEL claude-opus-5-5 起動する Bot が使用するモデルを指定するため。未設定の場合はプロバイダー仕様ファイルの設定値が使われます
examples/<あなたのパッケージ>/model.yaml の default_model claude-opus-5-5 サンプルパッケージの現在の設定は gpt-5.6-terra で、変更しないとモデルが存在しないというエラーが発生するため
.env の BOT_RESPONSES_API false のままにする APIYI の Responses エンドポイントでは Claude が 400 エラーを返すため

ステップ1:専用トークンを用意する

  1. APIYI のトークンページ api.apiyi.com/token で新しいキーを作成し、残高上限と有効期限を設定します。用途には「OpenBot のローカル評価」と記入します。
  2. ローカル環境から curl で GET https://api.apiyi.com/v1/models を1回送信します。リクエストヘッダーは Authorization: Bearer sk-... です。

確認基準:HTTP 200 が返り、一覧に claude-opus-5-5 が含まれていること。2026-11-02 に実際に試したところ、259個のモデルが取得でき、claude-opus-5-5 と claude-opus-5-5-thinking の両方が含まれていました。

トークンを別に作るのは、「このマシン専用」と「本番用」を分けるためです。テンプレート段階では Bot が試行錯誤を繰り返すため、残高上限を設けておくと安心です。

ステップ2:.env の3行を変更する

公式のクイックスタートに従い、まず cp .env.example .env と bun install を実行します。続いて npx --yes copilotkit@latest login、npx --yes copilotkit@latest project select、bun scripts/setup-learning.ts を順に実行し、runtime key と Learning container を .env に書き込みます。その後、以下の3行を変更します。

  1. OPENAI_API_KEY=sk-あなたのAPIYIトークン
  2. OPENAI_BASE_URL=https://api.apiyi.com/v1
  3. BOT_MODEL=claude-opus-5-5

あわせて、次の4点も確認します。BOT_PROVIDER はデフォルトの openai のまま、BOT_RESPONSES_API は false のままにします。KEY_ENCRYPTION_KEY は openssl rand -base64 32 で生成します。AGENT_BOT_MODEL は概念実証用の agent-bot だけに使われ、デフォルトは gpt-5.5 です。BOT_MODEL とは互いに影響しません。agent-bot も起動する場合は、/v1/models でこの名前が存在することを確認するか、使いたいモデル名に変更してください。

確認基準:grep OPENAI_ .env の出力に含まれるキーとアドレスが正しく、アドレスの末尾が /v1 で、余分なスラッシュやスペースがないこと。コンテナ内から同じエンドポイントにアクセスする際、別のルートを使う必要がある場合は、OPENAI_CONTAINER_BASE_URL で上書きできます。ただし、APIYI はパブリックアドレスなので、通常はこの変数を使う必要はありません。

ステップ3:テナントパッケージの model.yaml を1行変更する

examples/fintech/model.yaml、またはコピーしたテナントパッケージのファイルを開きます。現在の設定は model.provider: openai、model.credential_secret_ref: openai-api-key、model.default_model: gpt-5.6-terra です。

  1. default_model を claude-opus-5-5 に変更します。
  2. provider は openai のままにします。公式では openai または anthropic のみ指定できます。APIYI の OpenAI 互換エンドポイントを使う場合は openai を選びます。
  3. credential_secret_ref を平文のキーに変更しないでください。この項目は保存済みの認証情報を参照しています。

確認基準:bash scripts/start.sh を実行した後、ヘルスチェックがすべて通過し、http://localhost:3010 を開くと、デフォルトの同僚である General Assistant と Knowledge が表示されます。

ここで、事前に知っておきたい注意点があります。通常、サーバーの起動時には、OpenAI または Anthropic に「このキーで default_model を呼び出せるか」を確認します。呼び出せない場合は model-unavailable または model-credential-rejected が出力されます。しかし、OPENAI_BASE_URL が設定されていると、このチェックはスキップされます。そのため、APIYI に接続する場合、モデル名を間違えても起動時にはエラーが出ず、最初のメッセージを送って初めて問題が明らかになります。起動に成功したことは、サービスが立ち上がったことを示すだけで、モデルの設定が正しいことを保証するものではありません。

openbot-apiyi-env-config-guide-ja-image-2

バージョンについて:v0.2.0 と main ブランチの違い

ここは明確にしておきたいポイントです。main ブランチの CHANGELOG の Unreleased セクションには、次の変更が記載されています。組み込み Bot の openai/... モデルで、OpenAI でも Azure でもない OPENAI_BASE_URL を使う場合、Responses API ではなく、そのエンドポイントの /chat/completions を呼び出すようになります。公式によると、その理由は、ほとんどの OpenAI 互換エンドポイントが Chat Completions のみを提供しているためです。この変更では、どちらかを強制的に選択できる COPILOTKIT_OPENAI_API=responses|chat も追加されています。

この変更は、正式タグである v0.2.0 にはまだ含まれていません。v0.2.0 をチェックアウトした場合、組み込み Bot はサードパーティの base URL を使っていても、引き続き Responses を呼び出す可能性があります。後述する実際の検証結果も踏まえると、これが 400 エラーの原因である可能性が高いです。対処法は2つあります。main ブランチが引き続き変更されていることを理解したうえで評価するか、この変更が正式リリースされるまで導入を待つかです。

🚀 クイックスタート:OpenBot を設定する前に、まず APIYI apiyi.com のトークンを使い、関数定義を1つ含めて /v1/chat/completions を単独で呼び出してみましょう。finish_reason に tool_calls が返ることを確認できれば、その後のトラブルシューティングでは OpenBot の設定に絞って調べられます。


まずは3つのツールだけを許可:OpenBotの初期権限を絞る

なぜOpenBotのツールを最初からすべて有効にしないのか

公式ドキュメントでは、ツールの数について次のように述べています。「A model picks the right tool reliably out of about ten, and unreliably out of thirty.」つまり、ツールが10個程度ならモデルは適切なものを安定して選べますが、30個になると選択の信頼性が下がります。OpenBotのソースコードには13個のコンピュータ操作用ツールが登録されており、MCPディレクトリ内のツールも加えると、初日からこの水準を簡単に超えてしまいます。

12個を超えるツールを持つBotには、各実行時に、現在のメッセージに合致するskillが必要とするツールだけが渡されます。ただし、公式が強調しているように、これはあくまで見える範囲を絞る仕組みです。「It is not a boundary, and it never substitutes for one」。つまり、セキュリティ境界ではなく、その代わりにもなりません。実際の境界となるのは、AdminでBotごとに設定する権限付与(grant)、AGENT_COMPUTER_POLICYのアクションポリシー、そして監査行の3つです。また、初期設定はdeny: []とallow: ["true"]で、すべての操作が許可される点にも注意してください。

起動時に許可する3つのツール

ツール名 役割 起動時の設定
computer_navigate ブラウザでURLを開く ✅ 許可
computer_snapshot ページのスナップショットを取得 ✅ 許可
computer_read_file ワークスペースのファイルを読み取る ✅ 許可
computer_click / computer_type / computer_key クリック、入力、キー操作 ⏸ 動作確認後、必要に応じて許可
computer_write_file ファイルに書き込む ⏸ 動作確認後、必要に応じて許可
computer_run_command シェルコマンドを実行 ⛔ 明示的に拒否

computer_run_commandは個別にブロックする必要があります。Compose環境でCOMPUTER_SEPARATE_WORKSPACESを有効にすると、各Botは自分専用のフォルダでシェルを起動します。しかし公式も「Commands can still read other folders」と認めており、コマンドからほかのフォルダを読み取ることは可能です。真に分離するにはcomputers.mode: sandboxが必要です。起動時からこのリスクを負う必要はありません。

AGENT_COMPUTER_POLICYを記述する

ポリシーはJSONで記述し、ルールにはCEL式を使います。tool.name、page.host、file.pathなどのフィールドを参照できます。まずは次のように設定しましょう。

  1. .envに次の1行を記述します:AGENT_COMPUTER_POLICY={"mode":"enforce","deny":["tool.name == 'computer_run_command'"],"allow":["tool.name in ['computer_navigate','computer_snapshot','computer_read_file']"]}
  2. AdminでGeneral Assistantにこの3つのツールを付与し、それ以外は付与しません。
  3. サービスを再起動します。JSONの形式が間違っているとサーバーは起動に失敗するため、問題に気づきやすくなります。

ここでは、2つの評価ルールを押さえておきましょう。1つ目は、denyがallowより先に評価されることです。そのため、後からallowの範囲を広げても、シェルは引き続きブロックされます。2つ目は、エンジンがフェイルクローズで動作することです。ポリシーが存在しない、または空の場合は何も許可されません。denyの記述が不正な場合は拒否として扱われ、allowの記述が不正な場合は許可されません。原則はひとつ、まず権限を絞り、必要に応じて広げることです。動作確認に合格したら、クリック、入力、ファイル書き込みを一つずつ追加し、その都度監査を確認しましょう。

openbot-apiyi-env-config-guide-ja-image-3


OpenBot と APIYI の接続確認とトラブルシューティング

動作確認:Webページを開き、ファイルを読み、監査ログを見る

公式アーキテクチャでは、ツール呼び出しは次の順序で処理されます。まず対象を解析し、現在のポリシーに照らして評価したうえで、監査ログに1行を記録します。その後、実際にコンピューターへ操作を送ります。送信した操作が失敗した場合は、2行目の監査ログが記録されます。コンピューター自体はポリシーを判断せず、制御の境界はサーバーのゲートウェイにあります。そのため、動作確認では「実行できること」と「記録されること」の両方を確認しましょう。

  1. /workspace に notes.md を置き、適当な内容を2行書きます。
  2. General Assistant に「公開されているWebページを開いてタイトルを教え、さらに /workspace/notes.md の内容を読んで」と依頼します。
  3. 続けて「ls / を実行して」と依頼します。この操作は拒否され、どのルールによってブロックされたかが回答に示されるはずです。
  4. Audit ページを開き、navigate、snapshot、read_file の許可記録と、run_command の拒否記録が表示されることを確認します。エクスポートする場合は、GET /api/admin/audit-events?format=csv を呼び出せます。1回あたり最大5,000行です。

モデル側の動作は、APIYI でのみ実測しています。2026年11月2日に、claude-opus-5-5 で /v1/chat/completions を呼び出し、read_file の関数定義を渡したところ、HTTP 200 が返されました。所要時間は4.06秒、finish_reason は tool_calls、引数は {"path":"/workspace/notes.md"} でした。トークン使用量はプロンプトが393トークン、completion が55トークンです。stream: true を追加した場合も HTTP 200 が返され、SSE チャンク内で関数名と引数が少しずつ出力され、最後は data: [DONE] で終了しました。これは、APIYI の chat エンドポイントが Claude のツール呼び出しを OpenAI 形式で返せることを示しています。これは「モデルはどの関数を呼ぶかだけを決め、実行は担当しない」エージェントに必要な仕組みです。

トラブルシューティング:よくある5つの失敗

症状 最も可能性の高い原因 対処法
400 field messages is required リクエストが Responses エンドポイントに送られている。実際に claude-opus-5-5 で APIYI の /v1/responses を呼び出すと、このエラーが返ることを確認済み BOT_RESPONSES_API=false を確認する。v0.2.0 では内蔵 Bot がまだ Responses を呼び出している可能性があるため、main ブランチに切り替えて COPILOTKIT_OPENAI_API=chat を設定する方法もある(ただし未リリース)
401 キーが間違っている、有効期限が切れている、またはトークンの残高上限を使い切っている APIYI のトークンページで有効期限と残高を確認し、curl で /v1/models を再テストする
モデルが存在しない default_model が gpt-5.6-terra のまま、または名前の先頭に openai/ が付いている 両方に接頭辞なしの claude-opus-5-5 を指定する。起動時のチェックはスキップされるため、メッセージを送信して確認する必要がある
ツールが呼び出されない モデルがツール呼び出しに対応していない、grant が付与されていない、またはポリシーによってツールがブロックされている 公式によると、ツール呼び出しのない Bot はコンピューターを操作できない。まず監査ログに拒否の記録がないか確認する
起動が拒否される Intelligence の設定が不足している、ポリシーの JSON に誤りがある、または provider spec にプロバイダーを追加したのに PROVIDER_IDS を更新していない Intelligence の3項目を設定し、JSON を検証する。APIYI に接続する場合はプロバイダーを追加する必要はなく、openai のままでよい

💡 トラブルシューティングのヒント:エラーが発生したら、まず同じリクエストを APIYI apiyi.com の /v1/chat/completions に直接送ってみましょう。直接の呼び出しは成功し、OpenBot では失敗する場合、問題は OpenBot の設定またはバージョンにあります。直接の呼び出しも失敗する場合は、トークンとモデル名を確認してください。こうすることで、まず問題の範囲を絞り込めます。

OpenBot で Claude を使う場合のコスト目安

APIYI は従量課金制で、固定月額料金はありません。2026年11月2日時点で確認した claude-opus-5-5 の価格は以下のとおりです。claude-opus-5-5-thinking も同じ価格です。

課金項目 単価(100万トークンあたり)
入力 $4
出力 $20
キャッシュ読み取り $0.2

モデルと価格の最新情報は、プラットフォームのモデル一覧をご確認ください。今回実測したツール付きリクエストの場合、入力393トークン、出力55トークンなので、1回あたりの費用はごくわずかです。ただし、Bot が複数ターンにわたってブラウジングやファイルの読み取りを始めると、コンテキストは急速に増えます。トークンの残高上限も併せて設定することをおすすめします。


よくある質問

Q1:OpenBot を APIYI に接続するには、ソースコードの変更が必要ですか?

必要ありません。`.env` の `OPENAI_API_KEY`、`OPENAI_BASE_URL`、`BOT_MODEL` の3行を変更し、テナントパッケージの `model.yaml` にある `default_model` を変更するだけです。provider spec と `PROVIDER_IDS` の変更が必要なのは、まったく新しいプロバイダータイプを追加する場合だけです。APIYI は OpenAI 互換インターフェースを使用するため、これには該当しません。

Q2:なぜ openai/claude-opus-5-5 のようにプレフィックスを付けないのですか?

OpenBot はモデル名をそのまま送信するため、エンドポイントが公開している表記を使います。APIYI(apiyi.com)の `/v1/models` に掲載されているのは、プレフィックスのない `claude-opus-5-5` です。プレフィックスを付けると、かえってモデルが見つからなくなります。

Q3:BOT_RESPONSES_API を有効にして Responses API を使えますか?

Claude に接続する場合は有効にしないでください。実測では、`claude-opus-5-5` で APIYI の `/v1/responses` を呼び出すと、400 エラー `field messages is required` が返されました。一方、`gpt-5.4-mini` では 200 が返されました。公式ドキュメントでも、エンドポイントが Responses API を実際に実装している場合にのみ、このスイッチを有効にするよう求めています。

Q4:OpenBot のシステム全体を動かして検証しましたか?

いいえ。検証したのは APIYI 側のみです。モデル一覧、ツール付きのチャット呼び出し、ストリーミング出力、Responses エンドポイントのエラーを確認しました。OpenBot のシステム全体(Docker と Intelligence プロジェクト)は執筆に使用したマシンでは動かしておらず、記事中の OpenBot の内部動作に関する記述は、公式リポジトリとドキュメントに基づいています。

Q5:従量課金制のキーを Bot に使い過ぎられないようにするには?

APIYI(apiyi.com)のトークンページで、キーの残高上限と有効期限を設定し、本番用のキーとは分けて管理してください。さらに、この記事で紹介した3ツールの方針を組み合わせることで、Bot ができることと使える金額の両方に上限を設けられます。


まとめ

OpenBot と APIYI の接続:押さえておきたいポイント

  • モデル設定は画面上にはない:.env の3行と、テナントパックの model.yaml の1行に記述します。
  • base_url はデプロイ全体に適用される:OPENAI_BASE_URL を変更すると、3種類の Bot がまとめて切り替わります。
  • 起動成功だけではモデルが正しいか分からない:ゲートウェイ接続後はチェックがスキップされるため、最初のメッセージを送って確認します。
  • バージョンに注意:/chat/completions を呼び出す変更は、まだ main ブランチの Unreleased にあり、v0.2.0 には含まれていません。
  • 最初に許可するツールは3つだけ:deny は allow より優先されます。shell は個別に拒否し、まずは権限を絞ってから徐々に広げましょう。
  • APIYI の従量課金で始める:専用トークンに残高上限を設定し、claude-opus-5-5 はプレフィックスなしの名前で指定します。

OpenBot のモデル設定が見つかりにくいのは、そもそも画面上にないからです。.env の3行、model.yaml の1行を正しく設定し、Responses を無効のままにして、3つのツールだけを許可するポリシーから始めれば、全体の流れが明確になります。動作確認では、Webページを開けること、ファイルを読み取れること、拒否された操作が監査ログに記録されることの3点を確認しましょう。

まずは APIYI(apiyi.com)の専用トークンを使い、チャットとツール呼び出しを単独でテストしてから、OpenBot に接続することをおすすめします。問題が発生しても、どちらに原因があるか素早く切り分けられます。


📚 参考資料

  1. CopilotKit/OpenBot リポジトリ:README、Requirements、Quick start
  2. リンク: github.com/CopilotKit/OpenBot
  3. 内容:テンプレートの位置づけ、前提条件、v0.2.0 Release の情報

  4. OpenBot 設定ドキュメント:モデルの環境変数、model.yaml、起動時の検証

  5. リンク: github.com/CopilotKit/OpenBot/blob/main/docs/configuration.md
  6. 内容:OPENAI_BASE_URL、BOT_MODEL、BOT_RESPONSES_API の原文での定義

  7. OpenBot アーキテクチャドキュメント:gateway、ポリシー、監査

  8. リンク: github.com/CopilotKit/OpenBot/blob/main/docs/architecture.md
  9. 内容:ツールの呼び出し順序、監査データのエクスポートインターフェース

  10. APIYI ドキュメントセンター:OpenAI 互換モード、関数呼び出し、モデル一覧

  11. リンク: docs.apiyi.com
  12. 内容:base_url の記述方法、tools の形式、claude-opus-5-5 の価格

著者:APIYI 技術チーム
技術に関するお問い合わせ:APIYI 公式サイト apiyi.com からお問い合わせください。接続方法に関する資料は、docs.apiyi.com のドキュメントセンターをご覧ください。

関連記事

類似投稿