OpenAI / Anthropic / Google の生成AI APIを社内の複数メンバーが利用するようになった組織で、APIキー管理のポリシー整備が情シス担当者の実務課題として浮上している。この記事では、AI APIキー管理の漏洩リスク分類と管理方式の選択判断フローを情シス目線で整理する。
この記事を読んだほうが良い人
- ChatGPT / Claude / Gemini API を社員が個別に取得して利用している100名規模企業の情シス担当者
- APIキーをスプレッドシートやSlackで共有している運用を見直したい方
- GAS (Google Apps Script) で社内ツールからAI APIを呼び出しているが、キーの保存方法に不安がある方
- AI活用のガバナンス整備をこれから本格的に進める担当者
AI APIキーが引き起こす3つのリスク
APIキーを管理方針なしで運用した場合のリスクは、大きく3つに分類できる。
| リスク区分 | 主な被害 | 発生しやすい状況 |
|---|---|---|
| 漏洩 | 第三者によるAPIの無断利用・データ窃取 | ソースコード・スプレッドシートへの平文直書き |
| 費用超過 | 大量リクエストによる月次コストの急増 | 漏洩したキーを使ったボット的アクセス |
| コンプライアンス違反 | 個人情報を含むプロンプトの外部送信 | 利用ルールが未整備のまま全社員が無制限に利用 |
漏洩リスクの実態
漏洩の典型的な経路は「ソースコードへの直書き → Gitリポジトリへの誤コミット」だ。GitHubにはAPIキーの形式をパターンで検出してリポジトリオーナーに通知するSecret Scanning機能がある（GitHub公式ドキュメントより）が、一度コミット履歴に入った文字列を完全に除去するには専門的な操作が必要になる。気づいた時点で即時無効化し、新規発行に切り替えることが現実的な対処だ。
Slackチャンネルへの直貼りも頻繁に起きる経路の一つだ。「○○さんにとりあえず共有します」とキーを貼ったメッセージは、チャンネル参加者全員が閲覧できる状態で過去ログに残り続ける。外部委託先や退職者が同じチャンネルに残っていた場合のリスクは想定よりも大きい。
費用超過リスクの実態
漏洩したキーが悪意ある第三者に使われた場合、短時間で高額の請求が発生することがある。OpenAIなど主要ベンダーはハードリミット（月次上限額）の設定機能を提供しているが、デフォルトでは設定されていないことが多い。上限を設定していない状態でキーが漏洩すると、数日で数十万円規模の請求が来るケースも実際に報告されている。費用上限の設定は「APIキーを作ったらすぐやること」として運用ガイドに明記しておくべき項目の一つだ。
コンプライアンスリスクの実態
APIキー管理と並行して「社員がAI APIに送るプロンプトに顧客情報や個人情報を含めない」というデータ利用ルールの整備も必要になる。キー管理だけ整備してデータ送信ルールが未整備な状態は、個人情報保護法・GDPRの観点では片手落ちで、外部監査の際に指摘対象となりやすい。
この3つのリスクは独立した問題だ。「費用上限を設定した」だけでは漏洩リスクは消えない。対策の優先順位を決める前に「今どのリスクが最も深刻か」を関係部署と合意しておくことが出発点になる。
APIキーをどこに置くかの判断フロー
AI APIのシークレット管理方式は大きく3択だ。組織の規模と利用環境に合わせて選ぶ判断軸を以下に整理する。
| 管理方式 | 適した用途 | コスト | 主な制約 |
|---|---|---|---|
| GAS Script Properties | GWS 組織内のGASオートメーション | 無料 | GASスクリプト内からのみアクセス可能 |
| GCP Secret Manager | 複数サービスから利用するアプリ・本番環境 | 有料（従量課金） | Google Cloudプロジェクトの設計・IAM管理が必要 |
| チームパスワードマネージャー | 人が手動でコピペして使う場面・ツール設定値 | チームプランの費用 | プログラムからの自動取得には追加設定が必要 |
GAS Script Properties は、GWSを利用している組織がGASでAI連携スクリプトを作るときに最も手軽な選択肢だ。キーをスクリプトコードから分離して保存できるため、コードを共有してもキー自体は伝わらない。ただし、スクリプトに編集権限を持つメンバーはスクリプトエディタのUIから値を閲覧できる。スクリプトへの共有範囲を必要最小限に絞ることが、この方式を使う前提条件だ。
GCP Secret Manager は、複数のサービスが同じシークレットを参照する環境向けだ。Google CloudのIAM (Identity and Access Management) と連携しているため、誰がいつシークレットにアクセスしたかの監査ログも取得できる。GASスクリプト単体の用途には設計コストが上がるが、GCPプロジェクトをすでに運用している場合は一元管理の観点から検討する価値がある。Secret Managerはキーのバージョン管理にも対応しており、ローテーション中のサービス停止を防ぎやすい構成を取れる。
チームパスワードマネージャー (1Password Teams・Bitwarden for Business等) は、非エンジニアがブラウザ拡張などを通じてシークレットを参照したい場合に向いている。既に全社導入済みであれば、まずそこに格納することで「Slack直貼り」を即座に防げる。一方、プログラムから直接参照するにはCLIやSecrets Automation機能といった追加設定が必要だ。
判断の分岐点は「そのシークレットをどこから使うか」と「誰がアクセスを管理するか」の2点に尽きる。GASスクリプト内でのみ使うならScript Properties、複数サービスから参照するならSecret Manager、人が設定画面にコピペして使うならチームパスワードマネージャーが基本的な目安になる。現状が「何も管理していない」であれば、どの方式でも今すぐ移行することが優先だ。理想的な方式にこだわって移行が遅れるより、即日着手できる方式を選んだほうが結果的にリスクを下げられる。
GAS Script PropertiesでAPIキーを秘匿する方法
GAS (Google Apps Script) のScript Propertiesは、PropertiesService APIを通じて読み書きするキーバリューストアだ。スクリプトプロパティに保存した値はエディタのソースコード上には表示されず、コードのリポジトリ共有時にキーが漏洩するリスクをほぼゼロに抑えられる（Google Apps Script公式ドキュメントより）。
初期登録：キーをScript Propertiesに保存する
APIキーを登録する一時的な関数を作成する。実行後はキーの文字列を空にするか、この関数をコードから必ず削除すること。文字列が残ったままでは秘匿の意味がなくなる。
// APIキーをScript Propertiesに登録する（初回1回だけ手動実行し、その後この関数を削除する）
function saveApiKey() {
const props = PropertiesService.getScriptProperties();
props.setProperty('OPENAI_API_KEY', 'sk-ここに実際のAPIキーを入力');
props.setProperty('ANTHROPIC_API_KEY', 'sk-ant-ここにClaudeのAPIキーを入力');
// 登録確認：プロパティ名の一覧だけをログに出す（値は出力しない）
Logger.log('登録完了: ' + Object.keys(props.getProperties()).join(', '));
}
Logger.log で登録されたプロパティ名の一覧が出力されることを確認できる。値そのものをログに出力しないよう注意すること。確認後、この関数はスクリプトから削除するのが鉄則だ。
本番コード：キーを取得して使う
以下は getApiKey ヘルパー関数と、OpenAI Chat Completions を呼び出す関数の実装例だ。
// Script PropertiesからAPIキーを取得するヘルパー関数
function getApiKey(keyName) {
const key = PropertiesService.getScriptProperties().getProperty(keyName);
if (!key) {
throw new Error(keyName + ' がScript Propertiesに未設定です。saveApiKey() を実行して登録してください。');
}
return key;
}
// AI API呼び出しの実装例（OpenAI Chat Completions）
function callOpenAI(prompt) {
const apiKey = getApiKey('OPENAI_API_KEY');
const payload = {
model: 'gpt-4o-mini',
messages: [{ role: 'user', content: prompt }]
};
const response = UrlFetchApp.fetch('https://api.openai.com/v1/chat/completions', {
method: 'post',
contentType: 'application/json',
headers: { 'Authorization': 'Bearer ' + apiKey },
payload: JSON.stringify(payload),
muteHttpExceptions: true
});
// HTTPエラーコードを明示的にチェックする
if (response.getResponseCode() !== 200) {
const errorBody = JSON.parse(response.getContentText());
throw new Error('OpenAI API Error ' + response.getResponseCode() + ': ' + JSON.stringify(errorBody));
}
return JSON.parse(response.getContentText()).choices[0].message.content;
}
getApiKey 関数を汎用化しておくと、ClaudeやGeminiのキーを追加するときも同じパターンで対応できる。変更が必要なのは model の値とエンドポイントURLのみで、キー取得ロジックはそのまま使い回せる。複数のAIプロバイダを使い分ける場合は OPENAI_API_KEY、ANTHROPIC_API_KEY、GOOGLE_AI_API_KEY のようにプレフィックスを統一しておくと、プロパティ一覧を見たときに用途が一目でわかる。
Script Propertiesの制約と注意点
Script Propertiesはスクリプト単位で分離されている。スプレッドシートAのスクリプトに保存したキーは、スプレッドシートBのスクリプトからは読めない。複数のGASスクリプトで同じAPIキーを使う場合は、それぞれのスクリプトにキーを登録するか、GCP Secret Managerへの移行を検討する段階に来ているサインと考えるといい。
Script Propertiesはスクリプトプロジェクトのオーナー変更や削除時に値が失われる可能性もある。キーの原本はチームパスワードマネージャーや他の安全な場所に必ず保持しておくこと。「Script Propertiesに入れたら台帳から外した」という状態は最も危険なパターンだ。
AI API 漏洩対策の最小運用ポリシーチェックリスト
保管場所を整えることと同じくらい、継続的な運用ルールが重要だ。以下のチェックリストで現状を確認してほしい。
台帳・発行管理
- キー台帳の整備: 発行済みのAPIキーを用途・担当者・取得日・ベンダーを含む台帳で管理している
- 組織アカウントでの発行: 個人のクレジットカードではなく、組織のアカウントにキーが紐付いている
- 環境の分離: 本番用キーと開発・テスト用キーを別々に発行している
台帳は凝ったシステムでなくて構わない。Googleスプレッドシートの1シートで「キーID（末尾4文字）/ 用途 / 発行者 / 発行日 / 費用上限設定済みか / 最終ローテーション日」の列を持たせるだけで、棚卸しと管理の基盤になる。
アクセス制御と費用管理
- ソースコードへの直書き禁止: キーはコードに埋め込まず、Script Properties・Secret Manager・パスワードマネージャーのいずれかで管理している
- 最小権限の付与: キーに必要最小限のスコープのみ付与している（ベンダーが提供する制限機能を活用する）
- 費用上限とアラートの設定: ベンダーの管理コンソールで月次利用額の上限または通知を設定している
費用上限の設定先は各ベンダーのAPIキー管理画面から確認できる。OpenAIはProjectごとに月次ハードリミットを設定できる。Anthropicは利用量アラートの設定が可能だ。設定値の目安は「通常月の想定利用額の2倍でアラート、3倍でハードストップ」が出発点として扱いやすい。
退職者・異動者対応とローテーション
- 退職・異動時の手順明文化: 担当者変更の際にキーを失効・再発行する手順をオフボーディングに組み込んでいる
- 定期ローテーション: キーを定期的（最低でも年2回が目安）に更新し、古いキーを失効させる運用が決まっている
- 漏洩疑い時の即時対応手順: キーが外部に漏れた可能性が生じた場合に、即時無効化 → 新規発行 → 被害確認を行う手順が文書化されている
退職者対応でよく見落とされるのが「個人アカウントで発行したキー」だ。組織のGCPプロジェクトや公式APIコンソールから発行されていれば一元管理できるが、担当者が個人のGoogleアカウントで発行したキーは退職時に台帳から外れる可能性がある。発行元アカウントの確認を台帳に含めておくことで、このリスクを早期に発見できる。
一度にすべての項目を満たせなくても構わない。まず「キー台帳の整備」と「ソースコードへの直書き禁止」の2点から着手すると、最も発生しやすいリスクに対処できる。チェックリストを別ドキュメントとして新たに作るより、既存のオフボーディング手順書に直接組み込む形のほうが実際に運用される可能性が高い。
なお、APIキーを発行したあとの月次費用の可視化と上限管理については、DRASENASの関連記事でまとめているので、あわせて参照してほしい。
棚卸しから始めて、段階的に整備する
整備を後回しにするとキーの本数が増えてから台帳化する手間がかかる。以下の3ステップで段階的に進めることを勧める。
ステップ1（今日〜今週中）：現状の棚卸し
現在使っているAIサービスのAPIキーを全件書き出す。OpenAIならAPIキー管理画面、Anthropic（Claude）ならConsoleのキー一覧、Gemini APIならGoogle AI Studioのキー管理画面から、発行済みキーをそれぞれ確認できる。Slackの検索機能で sk- のようなキーのプレフィックスを検索すると、過去に直貼りされたキーが見つかることもある。発見した場合は即時無効化が最善の対応だ。
ステップ2（1〜2週間以内）：保管場所を移行する
スプレッドシートやSlackに残っているキーをScript Properties・Secret Manager・パスワードマネージャーのいずれかへ移行する。GASスクリプトを使っている場合は、前節のコード例をそのまま使って移行できる。移行後は旧キーをベンダーの管理画面から失効させること。失効させずに「使わなくなった」だけの状態で放置しないよう注意が必要だ。
ステップ3（移行完了後〜継続）：ルールを社内に浸透させる
「新しいAI APIキーを取得するときはXXXで管理する」というルールを社内のオンボーディング資料やIT利用ガイドラインに1行追記する。IT部門からの周知だけでは徐々に形骸化するため、開発・業務改善を担当するチームのリーダーと合意を取り、入口（新規キー発行時）のルールとして定着させることが継続運用の要になる。
GASでAI APIを活用している場合は、今日からでもScript Propertiesへのキー移行を始められる。コードを数十行書き換えるだけで、漏洩の最多経路である「ソースコードへの直書き」を解消できる。管理方式の高度さよりも「全員が同じルールに従える仕組み」を整えることが、AI APIキー管理整備の本質だ。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。
「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
※ この記事は DRASENAS Blog の転載です。オリジナルではコードや設定手順が随時アップデートされています。