> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.
# APIキーを安全に管理するには？
> APIキーのセキュリティに関する体系的なガイドで、IPホワイトリスト、モデルのホワイトリスト、支出上限、漏えいしたキーの確認方法を解説します
## 短い回答
1つのキーの最大支出力は**アカウント残高**です。つまり、どれか1つのキーが漏えいすると、最悪の損失はアカウントに残っている全額になります。
キーの保護は、次の4つに集約されます。**用途ごとに別々のキーを発行する、各キーに権限境界を与える、1つのキーが使える金額を上限設定する、そして他人に見られる可能性のある場所からキーを遠ざけることです。**
**最も見落とされがちな項目**: キーで「無制限クォータ」を有効のままにすると、その1本のキーを通じてアカウント残高全体が露出します。特にテスト用キーには、必ず支出上限を設定してください。
## 1. トークンに権限境界を設定する
トークンを作成する際は、\*\*「高度なオプションを有効にする」\*\*にチェックすると、IPホワイトリストと利用可能モデルの設定が表示されます。
### IP ホワイトリスト（本番環境に推奨）
これは**利用できる中で最も強力な保護**です。設定すると、指定した IP からのリクエストだけがそのトークンを使用できます — たとえキーが漏洩しても、他のマシンからは無意味です。
| 形式 | 例 |
| ------- | ------------------ |
| 単一 IP | `192.168.1.1` |
| CIDR 範囲 | `192.168.1.0/24` |
| 複数のアドレス | 複数のエントリをまとめて記載できます |
本番サーバーは通常、固定 IP を持つため、IP ホワイトリストとの相性が非常に良いです。サーバーの**公開送信元 IP**を入力し、内部アドレスではありません。
**動的 IP の接続では有効にしないでください。** 家庭用ブロードバンドやオフィスネットワークでは送信元 IP が変動し、変わった瞬間にすべての呼び出しが失敗します。そのような環境では、代わりに課金上限を設定してください。
### 利用可能モデルのホワイトリスト（専用トークン向け）
「利用可能モデル」を空欄のままにすると、制限はありません — そのトークンはプラットフォーム上のどのモデルでも呼び出せます。ここに入力すると、そのトークンは**一覧に記載したモデルのみ**使用できます。
これはメリットとデメリットの両方があります:
単一用途のトークン: 画像生成だけを行うサービス、社外の共同作業者と共有するトークン、またはモデルごとの予算分離。
日常的な個人利用や試験的なテストには向きません。モデルを切り替えるたびにコンソールへ戻る必要があり、モデルのエイリアスが一致しないと呼び出しが失敗することがあります。
ほとんどの場合、利用可能モデルの設定は**おすすめしません**。[トークンに利用可能モデルを設定する必要はありますか？](/ja/faq/token-model-whitelist)で、トレードオフの詳細を確認してください。
## 2. トークンに支出上限を設定する
これは**すべての人**に当てはまり、テストキーではなおさらです。
トークンを作成するときは、「無制限クォータ」をオフにして、「認可クォータ」に金額を入力してください。あるいは、フィールドの下にあるプリセット（\$5 / \$20 / \$50 / \$100 / \$200 / \$500）のいずれかを使ってください。
クォータの目的は、**許容できる金額に損失を抑えること**です。
* \$20 のクォータの漏えいしたキーによる損失は、最大でも \$20 です
* 「無制限クォータ」を有効にした漏えいしたキーでは、**アカウント残高の全額**に達する可能性があります
トークンの最大支出力は、**アカウント残高によって制限されます**。\$500 のクォータを設定しても、その金額が予約されたり凍結されたりするわけではありません。あくまで、そのトークンの消費に対する上限です。実際に使える金額は、利用可能な残高に依存します。
## 3. 本番用キーとテスト用キーを分けて管理する
本番トラフィックとローカルテストで1つのキーを併用しないでください。分けておけば、問題のあるテスト token を本番に触れずにすぐ無効化できます。
| | 本番キー | テストキー |
| ------------- | -------------------- | --------------------------- |
| **IPホワイトリスト** | 推奨（サーバーIPが固定されるため） | 通常はオフ（IPが変わるため） |
| **許可クォータ** | トラフィックから見積もり、余裕を持たせる | **必ず設定してください**、\$5–\$50 を推奨 |
| **利用可能なモデル** | 任意; 安定したワークロードでは固定する | モデル切り替えをしやすくするため空欄にする |
| **有効期限** | 無期限に設定できる | 有効期限を設定する |
| **数** | プロジェクトまたはサービスごとに 1 つ | テストタスクごとに 1 つ、完了したら無効化する |
コンソールで tokens に**見分けやすい名前**を付けてください（例: `prod-image-service`、`test-model-compare-0729`）。デフォルト名のままにするより、問題が起きたときに適切な token を見つけて無効化するのがずっと速くなります。詳細は [Tokens とグループ](/ja/faq/token-and-groups) をご覧ください。
## 4. これらの場所からキーを遠ざける
### コードリポジトリ
ここは、圧倒的に最も一般的な漏えい経路です。キーが Git にコミットされると、**ファイルを削除した後でもコミット履歴に残り続け**、リポジトリにアクセスできる人なら誰でも掘り出せます。
代わりに環境変数から読み取ってください：
```python theme={null}
import os
api_key = os.environ["APIYI_API_KEY"] # Correct
api_key = "sk-your-api-key" # Wrong: a real key hardcoded in source
```
`.env` を `.gitignore` に追加し、**コミットする前にスキャンしてください**。このコマンドは自己チェックとして使えます：
```bash theme={null}
grep -rnE '(^|[^A-Za-z0-9])sk-[A-Za-z0-9]{10,}' .
```
そのパターンの `(^|[^A-Za-z0-9])` プレフィックスは重要です。これがないと、`sk-` が `task-`、`risk-`、`disk-` のような通常の単語内に現れて大量の誤検知を生み、実際の検出結果が埋もれてしまいます。
### 公開ドキュメント、スクリーンショット、ログ
ドキュメントや技術記事を公開する前に、本文、コードサンプル、そして**スクリーンショット**を見直してください。コンソールのスクリーンショット、ターミナルの録画、エラーログには、完全なキーが入っていることがよくあります。すべての例で `sk-your-api-key` のようなプレースホルダーを使ってください。
**公開 GitHub リポジトリは特に危険です。** 自動ボットによって継続的にスキャンされ、漏えいしたキーは数分以内に悪用されることがよくあります。プロジェクトをオープンソース化する前に、コードにもコミット履歴にも実際のキーが含まれていないことを確認してください。
### AI と AI エージェントとの会話
このリスク経路はまだ数年前に登場したばかりで、最も過小評価されがちです。
チャット欄にキーを貼り付けても一時的に感じられますが、実際には次のようなことが起こります：
AI コーディングツールは通常、会話全体をマシン上のプレーンテキストファイルとして保存し、無期限に保持して自動で削除することはありません。
古いセッションを再開すると、トランスクリプト全体がコンテキストとして再送信されるため、キーはそこに静止したままではありません。
これらのツールは編集前後にファイルのスナップショットを取ることが多いため、キーを含むスクリプトは何度も複製されることになります。
それらのファイルは**あなたとして実行されているあらゆるプログラム**から読み取れるため、コードリポジトリよりも境界が弱くなります。
**AI ツールとエージェントには必ず使い捨てキーを使ってください**: 別途作成し、少額のクォータ（たとえば \$5）と短い有効期限を設定し、作業が終わったらすぐにコンソールで削除してください。本番用キーを AI ツールに渡してはいけません。
## キーがすでに漏えいしてしまった場合の対応
[token ページ](https://api.apiyi.com/token) に移動し、影響を受けた token を削除または無効化してください。これは、被害の拡大をすぐに止める唯一の対応であり、**調査の前に**行います。
今度は支出上限と適用される権限の境界を設定した新しい token を発行し、アプリケーション設定を更新してください。
露出期間中の異常を [call logs](/ja/faq/call-logs) で確認してください。見覚えのないモデル、異常な量、または勤務していなかった時間帯のリクエストがないかを見ます。
key が実際にどこで漏えいしたのか — コード、ドキュメント、スクリーンショット、チャットの記録 — を突き止めて、それぞれを削除してください。そうしないと、代替 key も同じ経路で漏えいします。
## よくある質問
最も可能性が高いのは、IPが間違っていることです。必要なのはサーバーのパブリック送信元 IP で、`192.168.x.x` のような内部アドレスではありません。
自宅のブロードバンドやオフィスネットワークから呼び出している場合、送信元 IP は ISP によって変わるため、そのような環境は IPホワイトリストには向いていません。代わりに支出上限を使ってください。
切り分けるには、まず IPホワイトリストをクリアし、呼び出しが復旧することを確認してから、正しい IP を1つずつ追加し直してください。
いいえ。認可済みクォータは、その token の**支出上限**にすぎず、前払いでも仮押さえでもありません。
アカウントに \$50 しかない状態でも、5つの token にそれぞれ \$100 のクォータを設定できます。その \$50 を共有する形になり、使い切るとどれも動作しなくなります。token の最大利用額は常にアカウントの残高によって制限されます。
上限はありません。必要なだけ作成してください。
プロジェクトと環境の組み合わせごとに分けることをおすすめします。たとえば `prod-support-bot`、`prod-image-service`、`test-model-eval` です。より細かく分けた token なら、ほかに影響を与えずに1つだけ無効化でき、各 token の支出状況とログを個別に確認できます。
いいえ。クォータを使い切ると呼び出しは拒否されますが、token 自体は残ります。コンソールで token を編集して認可済みクォータを引き上げれば再開できます。新しく作成したり、設定を更新したりする必要はありません。
そのため、支出上限を設定する価値があります。取り戻せるブレーキであって、一方通行の破棄ではありません。
呼び出しログを確認してください。特に重要なのは、**一度も使っていないモデル**、**勤務時間外の呼び出し**、**ワークロードに見合わないリクエスト量** の3つです。
詳しい手順は [予期しないキー使用を調査するにはどうすればよいですか?](/ja/faq/troubleshoot-key-usage) をご覧ください。
## 関連ドキュメント
token の作成、編集、グループ化に関する完全なリファレンスです。
利用可能なモデルを設定するかどうかと、注意すべき点をまとめています。
ログを使って、予期しない使用の背後にいる実際の呼び出し元を特定します。
APIYI がトラフィックを暗号化し、プラットフォーム側でデータを保護する方法です。
セキュリティは決して軽視できません。上記の設定はすべて[token管理ページ](https://api.apiyi.com/token)にあります。数分の設定で、リスクの大部分を防げます。