API や認証付き HTTP を自動化するとき、「鍵」をどこに置くかで事故率が変わる。リポジトリやチャットに平文を残すほど共有・履歴・漏えいのリスクが増える。ここでは 認証情報を環境変数に載せ、実行中のプロセスからだけ読み、HTTP ヘッダなどにセットしてリクエストする、という流れを整理する。シェルの source と親子プロセスの話も触れる。

認証が要る API では、渡す情報がサービスごとに違う

手段はサービスごとに異なる。「API を叩く = 常に API キーが要る」わけではない。とはいえ スクリプトや CI（継続的インテグレーション。GitHub Actions などの自動実行）から繰り返し呼ぶときは、API キーや Bearer トークンを Authorization ヘッダなどに載せるパターンがよくある。この記事では主にその流れ（環境変数に置き、ヘッダへ載せる）を整理する。

実装のたびに ヘッダ名・プレフィックス（Bearer など）・期限は公式ドキュメントで確認し、定められた形で渡す。

手入力と暗記は現実的ではない

毎回キーボードから打ち込む運用は、入力ミス・シェル履歴への混入・複数サービスの取り違えを起こしやすい。自動化するなら、環境変数名をサービスごとに固定し、curl や SDK からは $VAR で参照する形に寄せておくと頭の負荷と事故の両方を減らしやすい。

平文はリポジトリやチャットに残さない想定で

ソースや議事に実値を貼るほど、共有範囲が広がるたびに再発行コストが上がり、Git の履歴には一度入ると追いにくい。公開・非公開を問わず、キー名だけを載せた .env.example のようなファイルはリポに置きやすいが、値が入った .env は .gitignore し、git の対象外にするのが一般的なパターンである。

チャットや AI 用ウィンドウにトークンを貼るのも避けた方がよい。作業用の ローカル専用ファイルに保存する、パスワードマネージャで管理する、といった方法がある。

環境変数とは（リポのファイルとは別レイヤー）

環境変数は、動いている プロセス（いま動いているプログラムの単位。ターミナルのシェルや、そこから起動したコマンドなど）に付いている 名前=値 の一覧だ。OS が子プロセス起動時に親からコピーして渡すことで、ターミナルから叩いたコマンドなどに同じ名前が届く。

すべてのアプリやウィンドウで自動共有されるわけではなく、同じシェルから起きた子に届きやすい、という理解が実務向き。別ターミナルでは改めて読み込みが必要になることが多い。

準備: export と env ファイルと source

1. ホーム配下など git 外のファイルに、例として次を書く（保存するファイルのパスは、自分の環境に合わせて決めてよい）。

   export EXAMPLE_SERVICE_API_KEY='ここに実値（リポには書かない）'

2. 作業セッションの最初に、そのファイルを現在のシェルに取り込む:

   source ~/.config/サービス名/env

   取り込みは source（または . ファイル） で行う。bash ~/.config/.../env のように別の Bash プロセスでファイルを実行すると、いま入力しているシェルには環境変数が残らない。¹

3. 毎回の手入力を減らすなら、~/.zshrc などに次のような一行を足す運用がある（同期やバックアップ範囲は自分で確認する）。

   [[ -f ~/.config/サービス名/env ]] && source ~/.config/サービス名/env

権限はターミナルで chmod コマンドを使って狭める。例として、env ファイルを所有者だけが読み書きできるようにするなら次のようにする（パスは自分のファイルに合わせる）。

chmod 600 ~/.config/サービス名/env

600 は「所有者: 読み取り＋書き込み／グループとその他: なし」を意味する。Finder など GUI から変えてもよいが、記録に残しやすいのはコマンドのことが多い。

**CI（GitHub Actions など）**では、画面に値を貼る代わりにプラットフォームの Secrets に登録し、ワークフローから ${{ secrets.NAME }} のように環境変数として注入するのが定番だ。GitHub のドキュメント（Secrets の利用） を参照するとよい。

API を叩くとき: 読み取ってヘッダに渡す（画面に「出力」しない）

脚本（コマンドをファイルにまとめ、ターミナルなどから実行するもの。例: シェル脚本）や curl は Authorization: Bearer $API_KEY のように環境変数を展開してヘッダに載せればよい。ここでいう目的は HTTP リクエストへ載せることであり、ターミナルに値を表示することではない。確認に echo $API_KEY 全文を使うと履歴やログに残りやすいので、**「長さだけ」「空でないか」**などで検証する習慣があると安全側に寄せやすい。

まとめ

• 認証が要る API では方式に応じた情報が必要で、自動化では APIキーや Bearer トークンを使うことが多い。
• 毎回の手入力や暗記には頼りにくい。命名を揃えた環境変数に寄せる。
• 平文をリポ・チャットに残さない。.env.example は名前だけ、実値は git 外や Secrets。
• 環境変数はプロセス側の状態であり、リポのファイルとは別に扱う。
• 準備: export を書いたファイルを source し、必要なら .zshrc で自動読み込み。
• 実行時: 変数を読み取り、HTTP ヘッダ等にセット。画面への露出は控える。

参考（公開ドキュメント）

• 環境変数（Wikipedia 英語） — 概念の横断整理（リンク先は英語）。
• GitHub Actions の Secrets 利用（日本語ヘルプ）
• Using environment variables in Node.js（Node.js 公式） — ランタイムからの参照イメージ。

脚注

Footnotes

1. bash と source: bash ~/.config/.../env のようにファイルをコマンドとして起動すると、OS は新しい Bash プロセス（子）を1つ立て、その中で export が実行される。環境変数の変更はその子プロセスの中だけで効き、子が終わると一緒になくなる。いま文字を打ち込んでいる対話シェル（親）は別プロセスなので、変数は引き継がれない。一方 source ファイル（Zsh でも同様。. ファイル は source の短い別名）は、いま動いているシェル自身がファイルの中身を「この場で」読み込み実行する。だから export した値が、そのまま同じターミナルセッションに残る。 ↩