ElevenAPIのAPI認証とキー管理

API認証とは、サービスが受信リクエストがアカウント上で操作する権限があるかどうかを確認する仕組みです。例えば、ElevenAPIでは、API認証情報によって、従量課金クレジットの消費、音声や音楽の大規模生成、そして一部の導入環境では機密性の高いオーディオへのアクセスが許可されます。

キーが漏洩すると費用が発生し、あなたのアカウントでコンテンツを生成される恐れがあります。また、過剰な権限でプラットフォームにアクセスされ、データ漏洩や他の攻撃経路につながる可能性もあります。2020年の時点でも、90%以上のデベロッパーが毎日何らかのプロセスでAPIを利用していました。今では、モデルコンテキストプロトコル（MCP）やAIの普及により、APIはあらゆる場所で使われています。

この記事では、APIを正しく認証する方法と、キーのライフサイクル全体（スコープ設定、ローテーション、組織的な管理、監査、インシデント対応）にわたる管理方法を解説します。チームでAPI認証とキー管理を適切に導入するための参考になります。読み進める際は、認証リファレンスやワンタイムトークンのリファレンスも開いておくと便利です。

要点まとめ

• ElevenAPIは、xi-api-keyヘッダーという1つのシークレットで全リクエストを認証します。つまり、キーを持つ人は誰でもクレジットを消費し、アカウントでオーディオを生成できます。
• 長期間有効なAPIキーをブラウザやモバイルアプリ、ユーザーが確認できるアーティファクトに含めてはいけません。必ず自分が管理するサーバー上で保持してください。
• クライアントサイドで利用する場合は、サーバー側で発行した短期間有効なワンタイムトークンで認証し、長期間有効なキーは絶対に使わないでください。
• キーのスコープを最小権限に設定し、環境ごとに分けて定期的にローテーションすることで、漏洩時の被害範囲を最小限に抑えられます。
• 監査や異常検知によって、キーの漏洩や予期しない利用を防ぐことができます。

API認証とは？

API認証とは、サービスが受信リクエストが特定のアカウントで操作する権限があるかどうかを、処理開始前に確認する仕組みです。リクエスターが認証情報を提示し、サービスがそれを検証し、認証されればレスポンスを返します。

簡単に言えば、「このリクエストはこのアカウントで操作する権限があるか？」という問いに答えるものです。このプロセスはAPI認可（authorization）とは異なり、認可は認証済みリクエストがシステム内で何を許可されているかを定めます。

キー管理とは？

キー管理とは、APIキーのライフサイクル全体を管理するための幅広い運用方法を指します。キーの作成、保存、利用、ローテーション、アクセスの取り消し方法などを決めるものです。これらの仕組みにより、APIキーのセキュリティをエンドツーエンドで守ります。

厳格なキー管理システムを導入することで、キーの漏洩を防ぎ、公開されるリスクを減らせます。

なぜAPIキーのセキュリティが重要なのか：脅威モデル

認証とキー管理の定義ができたところで、キーの取り扱いを誤った場合に何が起こるのかを正確に把握しておきましょう。まず脅威モデルを確認することで、以降の各対策がどのような目的で必要なのかが明確になります。各対策は、キーの漏洩確率や漏洩時の被害を減らすためのものです。

ElevenAPIは、xi-api-keyヘッダーという1つのシークレットで認証します。キーを持つ人は誰でも認証され、リクエスト自体に二段階認証などはありません。

キーがあればクレジットを消費できます。テキスト読み上げ、スピーチtoテキスト、音楽、サウンドエフェクトはすべて従量課金制で、有効なキーを持つ攻撃者は、クォータや残高が尽きるまで生成を続けることができます。

大規模な生成も可能です。当社のレートリミットモデルは単純なリクエスト数/分ではなく、同時実行数ベースです。例えば、あるモデルファミリーで同時実行数5のプランなら、1つのキーで多くの同時生成が可能です。攻撃者がこの仕組みを理解していれば、悪用を並列化できます。

あなたのアカウントでコンテンツを生成される可能性もあります。キーで生成されたオーディオはすべてあなたのワークスペースに紐づき、使われる音声や入力内容によっては評判や法的な問題につながることもあります。

キーが漏洩する原因はありふれており、他の認証情報が漏れる場合と同じです：

• クライアントサイドコード内のAPIキー： ブラウザバンドルやモバイルバイナリ、シングルページアプリに含めて配布されたキーは、実質的に公開状態です。ミニファイしても難読化にはなりません。
• リポジトリ内のAPIキー： Gitにハードコードされたキー（後で公開されたり広くクローンされたプライベートリポも含む）、.envファイルなど意図せず管理対象になったファイルも含まれます。
• ログやトレース内のAPIキー： リクエストロガーやエラートラッカー、オブザーバビリティパイプラインはHTTPヘッダーを記録することが多いです。xi-api-key内のキーがログストアやAPMベンダー、またはそれらにアクセスできる人の手に渡ります。
• CIやスクリーンショット内のAPIキー： ビルドログ、サポートチケット、共有ターミナルなど。

以下の各セクションは、これらの発生確率や影響を減らす方法を解説しています。

最重要ルール：APIキーは必ずサーバーサイドで管理

この記事の他の内容はAPIキー認証と管理のリスク低減策ですが、このルールがすべての基礎です。必ず最優先で実施してください。

仕組みがシンプルな分、最重要ルールは「長期間有効なAPIキーは自分が管理するサーバーだけに置く」ことです。ブラウザ、モバイルアプリ、デスクトップクライアント、ユーザーがダウンロード・確認できるアーティファクトには絶対に含めないでください。クライアントサイドコードに含まれている場合は、すでに漏洩したものとみなしてください。

SDKはELEVENLABS_API_KEYを自動で読み込むため、何も渡さず一度だけクライアントを初期化するのが最もシンプルです。

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

// Reads process.env.ELEVENLABS_API_KEY when apiKey is omitted - never a literal.
const elevenlabs = new ElevenLabsClient();

const audio = await elevenlabs.textToSpeech.convert("JBFqnCBsd6RMkjVDRZzb", {
  text: "Generated entirely server-side.",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

本番環境では、プロセス起動時にシークレットマネージャー（AWS Secrets Manager、GCP Secret Manager、HashiCorp Vault、または各プラットフォーム相当）から読み込むようにし、イメージやリポジトリにコミットした.envに埋め込まないでください。

クライアントサイドアプリ向けワンタイムトークン

最重要ルールは絶対ですが、正当な理由でクライアント自体がElevenAPIにアクセスする必要がある場合もあります。例えば、ブラウザでストリーミングテキスト読み上げを再生する、モバイルアプリで音声を録音して文字起こしする、ユーザーのタブでリアルタイムエージェントを動かすなどです。この場合、長期間有効なキーは使えません。解決策は、漏洩してもリスクの低い「短期間有効なワンタイムトークン」をクライアントに渡すことです。

サーバー側で長期間有効なキーを保持し、独自のセッションロジックでユーザーを認証・認可した後、短期間有効なトークンを発行してクライアントにのみ渡します。トークンはすぐに期限切れとなり、発行時の操作範囲に限定されるため、漏洩しても価値はほとんどありません。対応エンドポイントやリクエスト形式の詳細はワンタイムトークンのリファレンスをご覧ください。

以下はブローカーエンドポイントの基本ロジックです。独自のセッションロジックでユーザーを認可し、ドキュメント記載のトークンエンドポイントでトークンを発行します。リクエストはサーバーから長期間有効なxi-api-keyで送信し、クライアントには短期間有効なトークンだけが返されます。

// ... express app and route boilerplate
app.post("/api/voice-token", async (req, res) => {
  // 1. Authorize the user with YOUR session/auth system first.
  if (!req.session?.user) return res.status(401).json({ error: "unauthorized" });

  // 2. Mint a short-lived token server-side. The long-lived key travels only
  //    in this server-to-server request, never to the browser.
  const response = await fetch("https://api.elevenlabs.io/v1/tokens", {
    method: "POST",
    headers: {
      "xi-api-key": process.env.ELEVENLABS_API_KEY as string,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({}), // populate per the tokens reference
  });

  // 3. Return only the short-lived token. The API key never leaves the server.
  res.json({ token: await response.json() });
});

その後、ブラウザはこのトークンで接続し、長期間有効なキーがページに入ることはありません。

キーの最小権限スコープ設定

最小権限（Least privilege）は、各キーに必要最低限の権限だけを持たせるという原則です。ElevenAPIでは、キーごとにできること・できないことを制限する権限ベースの設定が可能です。

すべての権限を持つキーは、漏洩時の被害範囲が最大となり、しかもデフォルトで作りやすいです。より良い方法は「どのキーもいずれ漏洩する」と想定し、漏洩しても必要な範囲しか操作できないようにしておくことです。

まずはスコープ制限から始めましょう。これは、キーが呼び出せるAPIエンドポイントを制限します。例えば、文字起こし専用のキーにはテキスト読み上げの権限は不要ですし、音楽機能用のキーには音声管理の権限は不要です。

次にクレジットの上限設定です。キーごとにカスタムのクレジット上限を設定することで、漏洩時の金銭的被害や自作コードの暴走も抑えられます。

さらにIPホワイトリストも有効です。特定のIPアドレスやCIDR範囲からのみキーを利用できるように制限でき、ホワイトリスト外のIPからのリクエストは403で拒否されます。これは現在プレビュー中のエンタープライズ向け機能で、アカウントマネージャー経由で利用できます。

最後に、開発・ステージング・本番でキーを共有しないでください。環境ごとに別々のキーを発行し、それぞれにスコープと上限を設定しましょう。これにより、開発用PCからの漏洩が本番クレジットに影響せず、1つの環境だけをローテーションでき、利用ログも環境ごとに分かれて見やすくなります。

APIキーのローテーション

キーのローテーションとは、定期的に新しいキーに入れ替える運用です。漏洩や不正利用が疑われる場合にも実施します。

定期的にローテーションすることで、気付かないうちに漏洩しても悪用できる期間を短縮できます。ローテーションを簡単にするには、最初からその運用を前提にコードを設計しておくことが大切です。

基本テクニックは「キーの重複運用」で、これによりダウンタイムなしで切り替えできます：

1. 新しいAPIキーを生成：既存キーと同じスコープ・上限・IP制限で新しいキーを発行し、両方を有効にします。
2. キーを更新：シークレットマネージャー内のシークレットを新しいキーに更新し、インスタンスがそれを読み込むようにします（再起動、再読み込み、シークレットマネージャーのリフレッシュなど）。
3. トラフィックを確認：新しいキーでトラフィックが流れているか確認し、古いキーの利用が止まったことを確認します。
4. キーアクセスの削除： 一定期間トラフィックがないことを確認したら、古いキーを無効化します。

重複期間中は両方のキーが有効なので、認証情報不足でリクエストが失敗することはありません。また、設定ミスのインスタンスは古いキーを使い続けるため、切り替え前に発見できます。

ローテーションをイベント化しないためには、設定変更だけで切り替えられるようにコードを設計しましょう。1か所からキーを読み込み、リフレッシュ可能なタイミングで切り替え、どのシークレットが有効かを1つのスイッチで決められるようにします。

// Rotation is driven by configuration, not code edits. The secret manager (or
// the deploy that injects env vars) is the single point of change.
// ELEVENLABS_KEY_ACTIVE selects which slot is live, enabling overlap.
let client: ElevenLabsClient | undefined;

function activeKey(): string {
  const slot = process.env.ELEVENLABS_KEY_ACTIVE ?? "primary";
  const name = slot === "primary" ? "ELEVENLABS_API_KEY_PRIMARY" : "ELEVENLABS_API_KEY_SECONDARY";
  return process.env[name] as string;
}

function getClient(): ElevenLabsClient {
  return (client ??= new ElevenLabsClient({ apiKey: activeKey() }));
}

// Call after a secret refresh to pick up the rotated key without a deploy.
function resetClient(): void {
  client = undefined;
}

重複期間中はPRIMARYとSECONDARYの両方を設定し、ELEVENLABS_KEY_ACTIVEを切り替えます。アプリケーションコード自体は変更不要です。

ローテーションの頻度は、バックエンドキーなら90日ごとが標準的です。高価値または広く利用されるキーはより頻繁に、漏洩時は即時に実施してください。プロビジョニング・切り替え・確認・無効化を自動化すれば、ローテーションを日常的なバックグラウンド処理にできます。

ワークスペースのアクセス制御と権限管理

スコープ設定やローテーションで個々のキーを守る一方、ワークスペースの管理機能で誰がキーを発行できるかを制御します。これにより、組織のポリシーを定義・運用でき、今後のキー管理全体に影響します。

まず、人間用と機械用の認証情報を分けましょう。人は自分のアカウントと権限でダッシュボードにサインインし、サービスはキーやサービスアカウントで認証します。個人のアクセス権で発行したキーでサービスを動かしたり、1つの機械用キーを複数人で共有したりしないでください。理由はオフボーディングです。人が退職したりサービスを廃止した際、正確な認証情報だけを無効化できるようにするためです。

サービスアカウントも同じ目的です。人間に紐づかない機械用のIDを持たせ、独自のスコープで運用することで、監査ログの正確性も保てます。

次に、個人ごとではなくロール（役割）ごとにアクセス権を割り当てましょう。ワークスペースではグループやメンバーごとの権限管理が可能です。各グループに必要最小限の権限だけを付与し、定期的にメンバーを見直し、1つの認証情報（人間・機械問わず）が役割以上のことをできないようにしましょう。

監査と検知

ここまでで漏洩時の被害を減らす方法を説明しました。ここでは、そもそも漏洩が発生したかどうかを検知する方法を解説します。良い検知には3つの習慣が重要です。

1つ目は、どのキー（識別子のみ、シークレット値は記録しない）がどの種類のリクエストに、どこから、どれだけ使われたかを記録することです。xi-api-keyヘッダーはすべてのログ・トレース層から除去しましょう。HTTPミドルウェアやAPM設定でリダクションルールを設ければ、キーがログストアに残る最も一般的な経路を遮断できます。

2つ目は、クレジット消費の異常監視です。キーごとのクレジット消費量を時系列で追い、ベースラインからの逸脱（急激な増加、深夜の生成、アイドル状態のキーが突然アクティブになるなど）を検知してアラートを出しましょう。

3つ目は同時実行ヘッダーの監視です。すべてのレスポンスでcurrent-concurrent-requestsとmaximum-concurrent-requestsヘッダーを返しています。これにより余裕がどれだけあるか分かり、意図しない最大値張り付きは悪用の強いシグナルです。生のHTTPエンドポイントを使えばレスポンスヘッダーを直接確認できます：

const resp = await fetch("https://api.elevenlabs.io/v1/text-to-speech/JBFqnCBsd6RMkjVDRZzb", {
  method: "POST",
  headers: {
    "xi-api-key": process.env.ELEVENLABS_API_KEY as string,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ text: "Monitoring headroom.", model_id: "eleven_flash_v2_5" }),
});

const current = resp.headers.get("current-concurrent-requests");
const maximum = resp.headers.get("maximum-concurrent-requests");
// Emit these to your metrics pipeline; alert on sustained saturation you did not cause.

これらのシグナルでアラートが発報されるようにしましょう。誰も見ていないダッシュボードでは検知できません。クレジット急増や同時実行飽和のシグナルは、障害時と同じアラート経路に組み込み、明確な担当者を決めてください。

インシデント対応

どれだけセキュリティや監視を強化しても、最終的にはキーが漏洩する前提で備える必要があります。被害を最小限に抑える手順を決めておけば、迅速な対応ができ、影響も抑えられます。

APIキー漏洩時のインシデント対応フロー例：

1. 漏洩したキーを即時無効化： 全体像が分かるまで待たず、すぐに無効化してください。無効化されたキーは生成できず、代替キーの発行も可能です。これが最も重要なアクションです。
2. 新しいキーにローテーション： 漏洩キーが本番トラフィックに使われていた場合は、重複運用の手順を逆に実施します。新しいキーを発行し、トラフィックを切り替え、漏洩キーが完全に停止したことを確認します。キーを設定から読み込む設計なら、これは設定変更だけで済みます。
3. 利用ログから被害範囲を確認： 漏洩を封じ込めたら、被害を定量化します。キーが有効・公開されていた期間、消費されたクレジット、アクセスされたエンドポイント、正当な利用か悪用かなどを確認します。
4. 関連シークレットもローテーション：キーだけが漏洩することは稀です。リポジトリやログストア、CIパイプラインで漏洩した場合は、同じ場所にある他のシークレットも漏洩していると考え、あわせてローテーションしてください。
5. 漏洩経路の遮断： キーがどのように漏洩したかを特定し、再発防止策を講じます。.gitignoreへの追加と履歴削除、ロガーでのヘッダー除去、ビルドアーティファクトからのシークレット分離、CIシステムのアクセス制限などを実施してください。
6. 事後報告書の作成：タイムライン、被害範囲、根本原因、追加した具体的な対策（スコープ制限、IPホワイトリスト、CIでのシークレットスキャナー、ローテーション頻度の向上など）を記録します。

これらの手順を守ることで、API漏洩時の対応フローを事前に用意できます。

コンプライアンス対応：SOC2、HIPAA、データ保持

認証はより広範なコンプライアンス評価の一要素であり、ここで主張できること・できないことには注意が必要です。以下は事実ベースの出発点としてご参照ください。ご自身の用途への適用可否は別途ご確認ください。

ElevenLabsはSOC2準拠です。対象プランや用途によっては、HIPAA準拠やゼロ保持モードも利用できます。ゼロ保持モードでは、リクエスト内容は処理後に保存されません。入力や生成オーディオが機密性の高い場合に重要です。

どのモードが適用されるかは、プランや設定、処理内容によって異なります。利用前にご自身のアカウントで適用可否や詳細条件を必ずご確認のうえ、上記のアクセス制御と組み合わせてご利用ください。コンプライアンス認証はプラットフォームのデータ取扱いを規定し、キー管理は誰が代理操作できるかを規定します。後者はユーザー自身の責任です。

良いAPIキーセキュリティの姿

サーバーサイド専用キーで最大の漏洩リスクを排除。ワンタイムトークンで本当にAPIにアクセスが必要なクライアントも安全に。スコープや環境ごとの分離で漏洩時の被害を限定。設定ベースのローテーションで復旧も簡単に。ワークスペース管理で人と機械のIDを分離。監査で悪用を請求書のサプライズではなくアラートに。手順書でインシデントを手続き化。

これは、あらゆる高価値シークレットを守る基本的な衛生管理を、特に「お金を消費し大規模にオーディオを生成できる」キーに適用したものです。

実際のリクエスト形式に合わせて導入する際は、認証リファレンスやワンタイムトークンリファレンスで対応エンドポイント一覧を確認してください。監視すべき同時実行モデルの理解には、モデルリファレンスやAPIクイックスタートもご参照ください。

ElevenAPIインテグレーションのセキュリティ強化

強固なAPI認証は、他の多くのセキュリティ対策の土台となります。サーバーサイド専用キーの利用、クライアント向けワンタイムトークンの導入、最小権限スコープ、ローテーションの組み込みなどの対策で、大規模なリスクを未然に防げます。

対応エンドポイントやヘッダー形式の詳細は、ElevenAPIドキュメントをご参照ください。準備ができたら、ElevenLabsからAPIキーをリクエストして、今日から開発を始めましょう。

API認証とキー管理に関するよくある質問