APIキーは.envファイルにしまう。非エンジニアのためのAPIキー×.env運用ガイド

APIキーと.env（ドットエンブ）ファイルのセット運用とは、外部のクラウドサービスやAIを利用するための認証キー（APIキー）を、プログラムのコードに直接書き込まず、専用の秘密設定ファイル（.env）に分けて保管し、環境変数として間接的に読み込ませる安全管理の手法です。

ChatGPTの機能を自社システムに組み込む、Google広告やGA4のデータを社内レポートツールへ自動連携するなど、外部サービスとAIツールを組み合わせる機会が急速に増えています。その際、開発現場で必ずセットで登場するのが「APIキー」と「.envファイル」です。

APIキーを「サービスに入るための金庫の鍵」とするなら、.envファイルは「その鍵を人目に触れないようにしまっておく専用の引き出し」にあたります。強力な鍵を発行しても、机の上に置きっぱなし（コードへの直書き）では誰にでも持ち出されてしまいます。

経営者や事業責任者が自らコードを書く必要はありません。しかし、この「鍵は引き出しにしまう」という原則を知らないまま外部の制作会社やAIコーディングエージェントに開発を依頼すると、設定の抜け落ちに気づけず、高額な請求や深刻な情報漏洩を引き起こします。

本記事では、非エンジニアの経営層に向けて、APIキーと.envファイルを組み合わせた安全な運用の流れを、手元での開発から本番環境（Cloudflare / Vercel等）でのキー管理まで一気通貫で解説します。

1. なぜ「APIキー」と「.envファイル」はセットで理解すべきなのか

現在のAI活用やWebシステム開発において、APIキーと.envファイルは決して切り離せない関係にあります。まず、両者をセットで押さえるべき理由と、非エンジニアが主導権を持つべき背景を整理します。

1-1. 「鍵」と「引き出し」で理解する関係性

APIキーは、OpenAIやGoogle、Stripeといったサービス提供元が「このリクエストは正規の契約者からのものだ」と判断するための身元証明にあたる文字列です。この文字列さえあれば、誰であっても自社の契約枠・自社の支払い方法でサービスを使えてしまいます。

• APIキー（鍵）：サービスを使う強力な権利を持つ文字列
• .envファイル（引き出し）：鍵をコード本体から切り離し、人目から隠しておくための置き場所

鍵を発行しても、プログラムのコードの中にそのまま書き込んでしまえば、誰でも見える場所に放置しているのと同じです。逆に、引き出し（.env）を用意しても、そこに正しくしまう運用ルールが機能していなければまったく意味がありません。

1-2. 非エンジニアの経営者が主導権を持つべき理由

「ファイル構成やセキュリティはエンジニアに一任すればいい」と考えられがちですが、AI時代においてこの前提は大きく崩れつつあります。

• AIコーディングエージェントの普及：Claude Code、ChatGPT、Cursorなどを活用し、専任のエンジニアを介さずに事業担当者や経営者自身が直接AIに開発を指示する場面が急増しています。指示を出す人間が「APIキーは.envに保存する」という原則を知らないと、AIのチャット欄にキーをそのまま貼り付けて渡してしまい、情報漏洩の起点となります
• 外部委託先の確認役：制作会社やフリーランスに開発を依頼した際、納品されたコードにAPIキーが直接書かれていたり、公開除外の設定が抜けていたりすることがあります。確認する経営者側に基礎知識がなければ、納品物の安全性を判断できず、相手が手を抜いたことに気づけません

目に見えにくいセキュリティの「型」を社内に根づかせることが、安全にAIを活用するための経営管理の第一歩です。

2. APIキーと.envファイルの基本構造と環境変数の仕組み【図解】

APIキーと.envファイルがどのように連携して動いているのか、その仕組みを非エンジニア向けに噛み砕いて説明します。

2-1. .envファイルの中身と書き方

.envファイルは、特別なソフトウェアを必要としない、ただのテキストファイルです。プロジェクトの一番上のフォルダに配置し、「設定名＝実際の値」という形式で1行ずつ記述します。

# 外部AI・各種サービスの認証キー設定
OPENAI_API_KEY=sk-proj-1234567890abcdefghijklmnopqrstuvwxyz
GOOGLE_MAPS_API_KEY=AIzaSyA1234567890abcdefghijklmnopqrstuvwxyz
STRIPE_SECRET_KEY=sk_live_9876543210fedcba9876543210fedcba

2-2. 「環境変数から読み込む」とはどういう動きか

プログラム本体のコードには、上記のような生のキー文字列を一切書き込みません。代わりに、「環境変数（パソコンやサーバーが持っているシステム上の変数）から読み込みなさい」という指示だけを書きます。

// プログラム側の書き方（Node.js の例）
// コードに実際のキーは書かず、名前で呼び出す
const apiKey = process.env.OPENAI_API_KEY;

const openai = new OpenAI({ apiKey: apiKey });

プログラムが起動するときに、dotenvなどの読み込み用の仕組み（Node.jsなら --env-file オプション等）が.envファイルの中身を環境変数として取り込みます。コードはその名前（例：OPENAI_API_KEY）を通して、間接的に鍵の値を呼び出して使います。

この分離によって、「プログラムの動き（コード）」と「秘密の鍵（データ）」が独立します。これにより、コードを外部の開発者と共有したりGitHubに公開したりしても、手元の鍵は漏れない仕組みが完成します。

3. .gitignoreによるGit除外と「履歴に残るリスク」

コードと秘密情報を分ける最大の理由は、変更履歴を管理する仕組み「Git」や、コードを共有・公開する場所「GitHub」への誤公開を防ぐためです。

3-1. .gitignore（ドット・ギット・イグノア）の絶対ルール

開発者やAIエージェントがコードを保存・共有する際には「Git」というツールを使います。このとき、プロジェクト内に.gitignoreという除外設定ファイルを置き、その中に .env と記述しておくのが絶対のルールです。

# .gitignore の書き方の例
node_modules/
dist/

# ↓ この1行で .env がGitの送信対象から外れる（アップロードされない）
.env
.env.local

.gitignore に .env が登録されていれば、うっかり全ファイルをまとめてアップロードしようとしても、システムが自動的に.envファイルを無視し、自分のパソコンの中だけに留めてくれます。

3-2. 一度でも保存された秘密情報は「消えない」

最も注意すべきなのは、「.gitignoreへの登録を忘れたまま、一度でもGitに保存（コミット）してしまうと、後からファイルを削除しても手遅れになる」という点です。

Gitは過去の変更履歴をすべて記録・保存する仕組みです。最新のフォルダから.envファイルを消去して送り直しても、過去の履歴を1つさかのぼれば、当時のファイルに書かれていたAPIキーを誰でも簡単に復元し、取り出せてしまいます。

GitHub等に誤ってAPIキーを送ってしまった場合、ファイルを消すことではなく、そのAPIキーを発行元の管理画面で即座に無効化し、新しいキーを発行し直す（ローテーションする）ことが唯一の根本対策です。

3-3. 自動で検知する仕組み（gitleaks等）

最近の開発現場では、Gitに保存する直前にコードの中にAPIキーらしき文字列が含まれていないかを自動で調べて止めるツール（gitleaks や detect-secrets など）の導入が進んでいます。また、GitHub自体にも秘密情報を検知して通知する仕組み（Secret scanning）が備わっています。

開発会社に依頼する際、「保存前に秘密情報を調べる仕組みは入っていますか」と確認するだけでも、事故の確率を大きく下げることができます。

4. ローカル開発・本番環境・AI連携の管理手法【環境別の比較表】

「.envファイルさえあれば完全に安全」と誤解されがちですが、.envはあくまで「手元のパソコン」で作業するための仕組みです。一般公開する「本番サーバー」や「AIエージェントへの依頼時」には、それぞれ別の適切なやり方が存在します。

本番環境（Cloudflare / Vercel）での二段構え

本番公開のときは、手元の.envファイルをサーバーにアップロードしてはいけません。代わりに、ホスティングサービスの管理画面にある「環境変数（Environment Variables）」の設定欄に、キーの値を直接登録します。

このとき、サービスによって値の保護レベルが異なる点に注意が必要です。

• Cloudflare：シークレットとして登録した値は、保存後に管理画面から中身を再表示することが一切できません
• Vercel：環境変数は登録時に「Config（設定値）」か「Secret（秘密情報）」を選びます。Configは権限を持つメンバーが後から値を確認できます。APIキーは必ず「Secret」を選んでください。Secretは保存後にだれも値を表示できず、変更するときは新しい値で上書きするだけになります（2026年8月の仕様変更で、以前の「Sensitive」指定はSecretに置き換わりました）

「管理画面に入れておけば誰にも見えない」と思い込まず、その画面に誰がアクセスできる権限を持っているのかを合わせて決めておくことが重要です。

5. 実践ステップ：AIツールと外部サービス連携の安全な進め方

ここでは「自社サイトに、天気情報を自動取得してAIが応答するチャットボットを入れる」という小規模な開発を想定し、実務の流れを順番に追ってみます。

Step 1：外部サービスの管理画面でAPIキーを発行する

天気情報サービス（またはOpenAI等）の公式サイトにログインし、管理画面から新しいAPIキーを発行します。多くのサービスでは、セキュリティ保護のためキーの全文が表示されるのは「発行直後の一度だけ」です。

Step 2：手元のパソコンの.envファイルに自分の手で書き込む

プロジェクトのフォルダ内に .env ファイルを作成し、テキストエディタで直接書き込みます。

• 避けたい行動：チャットツールやメールで、開発担当者やAIに「APIキーは sk-1234... です」と貼り付けて送信する
• 望ましい行動：権限を持つ担当者が、自分の手で手元の .env ファイルに WEATHER_API_KEY=sk-1234... と直接入力する

Step 3：コードには「環境変数を読み込む処理」だけを書かせる

開発者やAIエージェントには、生のキーを書かせず、環境変数から呼び出す処理だけを実装してもらいます。

AIへの指示例：「天気情報APIを呼び出す処理を実装してください。APIキーの文字列はコードに直接書かず、.env ファイルから process.env.WEATHER_API_KEY として読み込むように記述してください。キーの文字列を私に尋ねないでください。」

Step 4：.gitignoreを確認して手元で動作確認する

.gitignore に .env が登録されていることを確認したうえで、手元のパソコン環境でプログラムを動かします。キーが正しく読み込まれ、天気データが取得できれば、開発段階のテストは完了です。

Step 5：本番環境の設定画面に登録して公開する

プログラムのコードだけをGitHubなどに送信し、VercelやCloudflare Pagesと連携させます。次に、各サービスの管理画面の「Settings」から環境変数の設定欄（Vercelは「Environment Variables」、Cloudflare Pagesは「Variables and Secrets」）に進み、名前に WEATHER_API_KEY、値に実際のAPIキーを入力し、秘密情報として（VercelはSecret、CloudflareはEncrypt）保存します。保存後に再デプロイすれば、コードにキーを一切出さないまま、本番環境でチャットボットが安全に稼働します。

6. 実務でよく起きる4つのトラブル事例と即時対応手順

型を知らないことで現場で起きやすいトラブルパターンと、万が一事故が起きたときの正しい対応手順を整理します。

トラブル1：プロジェクトフォルダごと外部に共有してしまう

.env ファイルを含んだフォルダ全体をZip圧縮し、チャットツールやクラウドストレージ経由で外部の委託先へ丸ごと送ってしまう例です。「秘密情報（.env）とコードを分けて渡す」という根本の考え方が抜けていることが原因です。

トラブル2：AIとの会話履歴（チャットログ）から漏れる

「エラーが出るので直してほしい」と、APIキーが入ったままのコードや.envの中身をチャット欄に丸ごと貼り付けてしまう例です。貼り付けた内容は会話履歴として残り続け、AIサービスの共有機能やアカウントの乗っ取りを通じて第三者の目に触れるリスクがあります。

トラブル3：退職者・元委託先の手元にキーが残る

過去に関わったエンジニアのパソコンに、本番用のキーが書かれた.envファイルが残ったままになっている例です。契約が終わってもキー自体は有効なため、悪意の有無にかかわらず、そのキーを使われても正規の利用と区別がつきません。担当が変わるタイミングでのキーの無効化・作り直しが必須です。

トラブル4：.env.example に本物のキーを書いてしまう

チーム共有用のひな形ファイルである .env.example に、誤って本物のキーを貼り付けたままGitに送信してしまう例です。.env（自分の手元に置く本物）と .env.example（値を空にした共有見本）の役割の違いを、チーム内で認識合わせしておく必要があります。

漏洩が分かったときの3つの緊急対応手順

1. 無効化：発行元（OpenAI等）の管理画面で、漏れたキーを即座に削除・無効化する
2. 再発行：新しいキーを発行し、手元の.envと本番環境（Vercel等）の設定値を差し替える
3. 履歴の確認：課金履歴を確認し、身に覚えのない高額請求や不正なデータ抽出がないか調べる

「コード上のキーの文字列を消して、Gitへ送り直す」だけの対応は避けてください。過去の履歴から取り出せるため、悪用は止まりません。必ず発行元での無効化を行ってください。

7. 非エンジニアが開発者やAIエージェントに渡せるチェックリスト

プログラミングコードが書けなくても、開発依頼時や納品チェックのときに、以下の項目をそのまま担当者やAIに提示すれば、事故を未然に防ぐ強力な管理になります。

• APIキーやパスワードなどの認証情報は、すべて .env ファイルに保存し、コード本体には直接書き込まないこと
• .env および .env.local などの設定ファイルは、必ず .gitignore に登録してGitの管理対象から外すこと
• チーム開発用に、キーの値を空欄にした見本ファイル（.env.example）を作成して共有すること
• 社内チャット、メール、タスク管理ツール、AIのチャット入力欄に、APIキーの生のテキストを貼り付けないこと
• 本番公開時は .env ファイルをアップロードせず、Cloudflare、Vercel、GitHub Secretsなどの管理画面に直接キーを登録すること
• 万が一キーが露出した場合は、コードの修正より先に発行元の管理画面で即座に無効化し、新しいキーを発行すること

8. まとめ：正しい保管の型が情報漏洩を防ぐ最大の防壁

AIツールやクラウドサービスの活用が広がるほど、連携する外部サービスは増え、社内で管理すべきAPIキーの数も増えていきます。

非エンジニアの経営者や事業責任者が押さえておくべき点は、突き詰めれば以下の2点だけです。

• APIキーは「サービスに入る金庫の鍵」であり、コードへの直書きやチャットへの貼り付けなど、むき出しで扱ってはならない
• .envファイルは「鍵をしまう引き出し」であり、.gitignoreで流出を防ぎ、本番ではクラウドの管理画面に登録する

難しい専門用語やプログラミング言語を覚える必要はありません。開発を依頼するたびに、「APIキーは.envに入れて、環境変数として読み込んでいますか」「本番環境の設定画面に登録しましたか」と一言確認する習慣を持つだけで、自社を高額請求や情報漏洩から守ることができます。目に見えない部分だからこそ、正しい保管の「型」を組織に定着させることが、AI時代の最大の防壁となります。