Skip to main content
API キーは Novita AI へのリクエストを認証します。このページでは、キーの作成と保存、複数の環境での使用方法、アクセス制御の構成について説明します。 このページでは、次のことができます:
  • Bearer API キーを使用して Novita AI へのリクエストを認証する。
  • コンソールで API キーを作成し、安全に保存する。
  • Linux、macOS、Windows でキーを環境変数として設定する。
  • キーの有効期間と、OpenAPI がサポートするキー操作を確認する。
  • キーのモデルアクセスとネットワークアクセスポリシーを構成する。

認証

Novita AI は API アクセスに Bearer 認証を使用します。API キーを Authorization リクエストヘッダーに含めて送信します:
リクエスト例:

API キーを作成する

1

キー管理を開く

コンソールで キー管理 に移動します。
2

新しいキーを作成する

API キーを作成 を選択し、キーの用途を表す名前を付けます。たとえば production や local-testing などです。
3

キーをコピーして保存する

完全なキーは作成時に一度だけ表示されます。すぐにコピーし、シークレットマネージャーや環境変数などの安全な場所に保存してください。紛失した場合、復元することはできません。代わりに新しいキーを作成してください。

アクセス制御を構成する

アクセス制御は任意で、API キーごとに構成します: 専用ガイドでは、ポリシーの動作、権限、構成、拒否エラーについて説明しています。

キーの形式と有効期間

  • すべてのキーは sk_ プレフィックスで始まります。
  • キーが完全な形で表示されるのは、作成時の一度だけです。その後は、コンソールにマスクされた形式で表示されます。
  • 各アカウントは最大 10 個の API キーを作成できます。
キーを作成するとき、4 つの有効期限オプションから 1 つを選択します: 永続 / 90 日 / 30 日 / 24 時間。
有効期限はキーの作成時に設定します。その後は 変更できません: キーを更新したり、すぐに失効させたりすることはできません。永続 キーは無期限に有効なため、漏えいしたキーがより長く使用可能なままになります。永続キーは適切な場合にのみ使用してください。有効期限はコンソールでのみ構成できます。OpenAPI はキーを作成したり、その有効期限を設定、変更、削除したりしません。
期限切れのキーは使用時に拒否されますが、その構成は引き続き表示され、削除操作も引き続き利用できます。有効期限はキーの無効化とは異なります。アクセスを復元するには、新しいキーを作成します。キーを有効期限前に無効化するには、コンソールで削除します。削除はすぐに有効になります。

OpenAPI がカバーする範囲

API キーの作成と削除はコンソールでのみ行います。Novita OpenAPI にはキーを作成または削除するエンドポイントがなく、キーの有効期限の構成もサポートしていません。 キー関連の OpenAPI エンドポイントでは、キーの一覧表示と、そのモデルおよびネットワークアクセスポリシーの管理ができます:

キーを環境変数として保存する

ソースコードにキーをハードコードすると、たとえばファイルをコミットしたときにキーが露出する可能性があります。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 -E を使用するか、昇格されたコンテキストで変数を設定してください。

関連項目

最終更新日 2026年9月17日