AIアプリのAPIキーはどこに置く？ブラウザ公開を防ぐ管理方法

1. 環境変数なら秘密になるのか

判断の起点は、設定画面で値が伏せられているかではなく、その値がブラウザへ届くかです。例えば、問い合わせ文の要約に使う外部AIサービスの秘密キーと、画面に表示する公開可能なアプリ識別子は、用途が異なります。本稿では設定項目ごとに、用途、秘密にする理由、読み取る処理、配信先を記録する設計を提案します。名前に「KEY」が含まれるかだけで分類せず、その値を持つことで何の操作が可能になるかを調べ、仕様が不明なら公開対象から外します。

取得済みのNext.js公式ガイドでは、NEXT_PUBLIC_を付けた環境変数は、参照箇所の値がビルド時にブラウザ向けJavaScriptへ埋め込まれると説明されています。例えば秘密のAIキーにこの接頭辞を付ける設計は、サーバー専用の秘密値を保管する目的に合いません。また、この方法で埋め込まれた値はビルド後の環境変数変更には追従しないため、設定変更だけで既存の配信物が更新されたと判断しないことが重要です。[2]

同ガイドは、NEXT_PUBLIC_のない環境変数をNode.js環境で利用する説明も示しています。ただし本稿では、非公開の変数名を使うことと、アプリの応答で秘密を返さないことを別の確認項目にします。例えば設定確認用APIが環境変数一覧を返す設計なら、変数名だけを点検しても配信経路の確認にはなりません。画面初期化データやエラー応答へ何を載せるかまで追い、値を読む場所から外へ出す場所までを確認対象にします。[2]

• 設定項目を公開可能な値、サーバー専用の秘密値、仕様確認待ちに分類する。
• 秘密値の参照元と、HTML・JavaScript・API応答への出力先を対応付ける。

2. サーバー処理では何を引き受けるか

本稿では、ブラウザから業務上の入力を受ける処理と、秘密キーを使って外部AIへ接続する処理をサーバー側でつなぐ構成を提案します。例えば議事メモの要約では、ブラウザは対象メモの識別子と要約条件を送り、サーバーが必要な内容を取得して送信内容を組み立てます。ブラウザに秘密キーを渡して直接呼び出させる構成とは分けて考えます。画面に返すのは業務上必要な結果に限定し、接続設定や認証ヘッダーを返す設計にはしません。

秘密キーをサーバーへ移すだけで、利用者の操作権限まで決まるわけではありません。本稿では、AI実行用APIで利用者の認証、所属先、対象データへのアクセス権、許可する操作を確認する設計を提案します。例えば閲覧専用の担当者には要約を許可しても、外部への送信や保存済み回答の更新は別の判断にします。OWASPが示す秘密情報への最小権限を踏まえ、外部接続用の資格情報についても、利用可能な権限設定を調べ、必要な用途に絞ります。[1]

RAGでは、本稿の設計案として、検索対象を決める情報を画面の指定だけに任せず、サーバーが利用者の所属や文書の閲覧条件と照合する流れを置きます。例えば他部署の文書識別子を入力された場合は、その文書を検索や回答生成へ渡さないことを確認します。さらに、AIへ送る本文、検索断片、戻り値を項目単位で整理します。キーを隠す確認と、個人情報を含むデータの送信範囲の確認は目的が異なるため、レビュー項目も担当する判断も分けて残します。

• AI実行用APIで、利用者と対象データと操作の組み合わせを確認する。
• 外部送信する本文・検索断片・添付情報を業務上必要な範囲に整理する。

3. 秘密値はどこで保管し、誰が扱うか

OWASPは、秘密情報の保管、払い出し、監査、ローテーションを管理し、アクセスを必要な範囲に限定する方針を示しています。本稿では、稼働環境へ値を渡す環境変数と、その元になる秘密値の保管先を区別して整理することを提案します。例えば管理基盤で保管した値をアプリ起動時に渡す場合は、保管先の閲覧権限と、稼働プロセスが値を受け取る経路をそれぞれ確認します。環境変数を選んだことだけで、保管や監査の設計が済んだとは扱いません。[1]

開発、検証、本番で同じ秘密キーを共有すると、どの環境から利用されたかを切り分ける手掛かりが減ります。OWASPも秘密の共有による漏えい元の特定の難しさを指摘しています。本稿では、環境と用途で分離できるかを検討し、開発用には架空データを使う運用を提案します。例えばRAGの索引作成と対話処理で資格情報を分ける案は、提供元が必要な分離を認めるかを確認して採否を決めます。分割自体を目的にせず、交換時の影響範囲を説明できる単位にします。[1]

CI/CDも秘密を扱う経路です。OWASPはCI/CDの権限を絞り、本番環境と同様に保護する考え方を示しています。本稿では、ビルド処理が本当に本番AIキーを必要とするかを先に確認することを提案します。例えば画面の生成だけなら秘密を渡さず、接続試験は権限を限定した別工程に分ける案を検討します。デプロイ失敗時の出力、診断用の設定表示、作業記録へ値を貼る手順も確認し、秘密を読める人と設定を変更できる人を区別して管理します。[1]

• 秘密値の保管先、読み取り主体、変更権限、利用環境を台帳に残す。
• ビルドと接続試験で必要な資格情報を分けられるか確認する。

4. 本番公開前の確認表

本稿では、コードの設定レビューだけでなく、本番相当のビルドと配置経路を通した確認を提案します。開発中の画面で問題が見えなくても、公開用のビルドで配信される値は別途確認が必要です。試験では実在の個人情報を使わず、識別できる検証用の値を用意し、正常系と意図した失敗時の出力を調べます。表は実施済みの結果ではなく確認計画です。担当、対象の版、確認日時、証跡の場所を別に記録し、未実施や対象外を合格と混同しない運用にします。

• 各行に未実施・確認済み・要対応・対象外の状態と、その根拠を記録する。
• 証跡には秘密値そのものを残さず、確認対象を識別できる情報を使う。

5. キーが露出したとき、何から変更するか

OWASPは、露出した秘密の速やかな失効、新しい秘密への交換、露出箇所からの除去を示しています。したがって、公開ファイルから文字列を消すだけを対応完了とはしません。本稿では、露出を疑う情報を受けた際に、対象キーを識別し、失効操作を行える担当へつなぐ手順を事前に定めることを提案します。例えば画面配信物に含まれていた場合は、該当する環境と配信版を記録し、キーの利用履歴など確認可能な情報を集めます。これだけで影響の有無を断定しないことも重要です。[1]

通常の交換と、露出に伴う緊急の失効では判断が異なります。本稿では、通常交換は検証環境で反映方法を確かめてから切り替え、露出時は旧キーを使える状態で残す影響を優先して判断する運用を提案します。新旧キーを同時に利用できるか、失効がいつ反映されるかは提供元の仕様確認事項です。新しいキーでの成功だけでなく、許可された確認環境で旧キーが拒否されることも確かめます。確認できない場合は、失効操作の記録と未確認事項を区別して残します。[1]

• 失効権限を持つ担当と、連絡が取れない場合の判断経路を決める。
• 旧キーの利用可否、新キーの動作、露出箇所の除去を別々に記録する。

6. 再実行と保守引継ぎに何を残すか

本稿では、キー交換後の確認対象に、画面からの即時実行だけでなく、予約処理、Webhookを受けた処理、失敗分の再実行も含めることを提案します。例えば文書の索引更新が待ち行列に残っている場合、その処理が実行時に設定を読むのか、受付時の設定を保持するのかで確認箇所が変わります。再開前には、処理済みの文書と未処理の文書を区別し、再実行で同じ更新を重ねない設計を点検します。旧キーを戻すのではなく、新しい設定で再開できる手順を用意します。

OWASPは、秘密にアクセスできる人、交換方法、交換で影響する依存先、連絡先を文書化するよう示しています。本稿では、引継ぎ資料にキーの実値を載せず、保管先の識別子、用途、責任者、反映手順、確認方法を残す構成を提案します。例えば保守担当は、台帳から対象の処理と承認者を特定し、必要な権限を得て交換します。緊急時の代替経路も実際に利用できるか確認し、手順を読めることと、操作権限を持つことを別々に点検して引き継ぎます。[1]

• 非同期処理の設定参照時点と、再実行対象の選び方を記録する。
• 引継ぎ資料には実値ではなく保管先、承認経路、復旧の確認方法を残す。

よくある質問

公開直前に、キーを管理する担当者が不在になった場合は？

本稿では、代替担当が必要な承認と操作権限を持つかを確認し、持たない場合はAI機能の公開を切り離すか延期する判断を提案します。個人のチャットへキーを転送して引き継ぐのではなく、管理基盤の権限付与手順に沿って引継ぎを行います。

本番相当の確認環境がない場合、確認済みにできますか？

できた確認と未確認の経路を分けます。例えば公開用ビルドをローカルで調べても、配置先で付加される応答やログまで確認したことにはなりません。本稿では、未確認事項の責任者と解消条件を定め、必要なら対象機能を無効にした状態で公開判断を行うことを提案します。

期限付きで開発者に本番キーの閲覧を認めてもよいですか？

まず、実値を読まずに設定変更や診断を行えないかを検討します。例外が必要な場合、本稿では目的、対象、承認者、終了期限、終了時の権限解除を記録することを提案します。期限が来れば自動的に権限が消えるかどうかは、利用する管理基盤の仕様確認が必要です。

外部AIが停止している間も、業務入力を受け付けるべきですか？

入力を保留できる業務か、その場で結果が必要な業務かで分けます。本稿では、保留するなら保存する情報、保存期限、再実行の判断者を先に決めることを提案します。個人情報を一時保存する範囲が決まっていない場合は、入力を受け付けず再操作を案内する選択肢も検討します。

参考・関連資料

• [1] Secrets Management - OWASP Cheat Sheet Series ↗
• [2] How to use environment variables in Next.js ↗

公式資料の確認日：2026-10-15。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。