- Bearer API キーを使用して Novita AI へのリクエストを認証する。
- コンソールで API キーを作成し、安全に保存する。
- Linux、macOS、Windows でキーを環境変数として設定する。
- キーの有効期間と、OpenAPI がサポートするキー操作を確認する。
- キーのモデルアクセスとネットワークアクセスポリシーを構成する。
認証
Novita AI は API アクセスに Bearer 認証を使用します。API キーをAuthorization リクエストヘッダーに含めて送信します:
API キーを作成する
1
キー管理を開く
コンソールで キー管理 に移動します。
2
新しいキーを作成する
API キーを作成 を選択し、キーの用途を表す名前を付けます。たとえば
production や local-testing などです。3
キーをコピーして保存する
完全なキーは作成時に一度だけ表示されます。すぐにコピーし、シークレットマネージャーや環境変数などの安全な場所に保存してください。紛失した場合、復元することはできません。代わりに新しいキーを作成してください。
アクセス制御を構成する
アクセス制御は任意で、API キーごとに構成します:- API キーのモデルアクセス は、チームで有効になっているモデル範囲内で、キーが呼び出せるモデルを制御します。
- API キーのネットワークアクセス は、キーをモデル呼び出しに使用できる送信元 IP を制御します。
キーの形式と有効期間
- すべてのキーは
sk_プレフィックスで始まります。 - キーが完全な形で表示されるのは、作成時の一度だけです。その後は、コンソールにマスクされた形式で表示されます。
- 各アカウントは最大 10 個の API キーを作成できます。
有効期限はキーの作成時に設定します。その後は 変更できません: キーを更新したり、すぐに失効させたりすることはできません。永続 キーは無期限に有効なため、漏えいしたキーがより長く使用可能なままになります。永続キーは適切な場合にのみ使用してください。有効期限はコンソールでのみ構成できます。OpenAPI はキーを作成したり、その有効期限を設定、変更、削除したりしません。
OpenAPI がカバーする範囲
API キーの作成と削除はコンソールでのみ行います。Novita OpenAPI にはキーを作成または削除するエンドポイントがなく、キーの有効期限の構成もサポートしていません。 キー関連の OpenAPI エンドポイントでは、キーの一覧表示と、そのモデルおよびネットワークアクセスポリシーの管理ができます:- API キーの一覧表示 — チームのキーを一覧表示します。オプションでモデルアクセスの概要も表示されます。
- API キーのモデルアクセスポリシーを取得 — 単一キーのモデルアクセスポリシーを読み取ります。
- API キーのモデルアクセスポリシーを設定 — キーのモデルアクセスポリシーを設定または更新します。
- API キーのモデルアクセスポリシーをリセット — キーのモデルアクセスポリシーをデフォルトにリセットします。これはポリシーのみをリセットし、キー自体は削除しません。
- API キーの IP アクセスポリシーを取得 — 単一キーのネットワークアクセスポリシーを読み取ります。
- API キーの IP アクセスポリシーを設定 — キーで許可される送信元 IP を設定または更新します。
- API キーの IP アクセスポリシーを削除 — キーのネットワークアクセスポリシーをクリアし、送信元 IP 制限がない状態に戻します。
キーを環境変数として保存する
ソースコードにキーをハードコードすると、たとえばファイルをコミットしたときにキーが露出する可能性があります。NOVITA_API_KEY のような環境変数から読み取ることで、キーをソースコードに含めずに済みます。
一時的 vs. 永続的
export (Linux/macOS) または set (Windows) で設定したキーは、現在のターミナルセッションでのみ有効で、閉じると失われます。これは簡単なテストに適しています。セッションをまたいでキーを保持するには、以下に示すように永続的に設定し、変更を反映するために新しいターミナルを開きます。
変数は設定されているのにコードからまだ見つからない
一時的に設定して新しいターミナルを開いた
一時的に設定して新しいターミナルを開いた
export または $env: で設定したキーは、コマンドを実行したターミナルセッションにのみ存在します。新しいターミナルやタブはそれを継承しません。キーを永続的に設定する (>> ~/.zshrc、setx) か、使用中のセッションで export/$env: コマンドを再度実行してください。永続的に設定したが再起動していない
永続的に設定したが再起動していない
永続的な変更 (シェルプロファイルまたは
setx) は、変更後に起動したターミナルに適用されます。新しいターミナルを開き、次に IDE またはエディターを再起動して、更新された環境を読み取れるようにします。Windows では、setx はすでに開いているターミナルには影響しません。サービスマネージャーがシェル環境を継承しない
サービスマネージャーがシェル環境を継承しない
systemd、supervisor、Docker、または CI ランナーによって起動されたプロセスは、対話型シェルプロファイルを読み取りません。変数は ~/.bashrc ではなく、サービスの独自構成 (たとえば systemd ユニットの Environment=、docker run -e フラグ、または CI プロジェクトのシークレット) で設定してください。sudo でコマンドを実行した
sudo でコマンドを実行した
sudo はデフォルトで環境を引き継がないため、ユーザーがエクスポートした変数は昇格されたプロセスから見えません。環境を保持するには sudo -E を使用するか、昇格されたコンテキストで変数を設定してください。