こんにちは！日々の開発、本当にお疲れ様です。
新しい機能が形になっていくワクワク感は素晴らしいものですが、それに伴って増えていくのが「秘密情報」の管理の悩みです。APIキー、データベースのパスワード、クラウドのアクセスキー……。これらをうっかりソースコードに書き込んでしまい、GitHubにプッシュして青ざめた経験、ありませんか？（私はあります、遠い目……）
今回は、CI/CDツール「CircleCI」を使い始めたばかりのあなたへ向けて、「APIキーやパスワードを絶対に漏らさないための正しい環境変数管理術」を徹底的に解説します。
これをマスターすれば、セキュリティの不安から解放されるだけでなく、チーム開発での認証情報の共有が劇的にスマートになりますよ。さあ、一緒に安全で快適な自動化の世界へ一歩を踏み出しましょう！
—
1. なぜCircleCIの環境変数管理が重要なのか？
私たちが作るアプリケーションの多くは、外部サービス（AWS、Stripe、Slackなど）と連携しています。その際、必ず必要になるのが「認証情報（Secrets）」です。
もし、これらの機密情報を`.yml`ファイルやソースコードに直接書き込んでしまったらどうなるでしょう？
そう、コードを共有した瞬間に、世界中にパスワードを配っているようなものです。
そこで登場するのが、CI/CDツール側の環境変数機能です。コードの外側（CircleCIのサーバー上）で安全に機密を保持し、ビルドやテストが走る瞬間だけ安全にアプリに読み込ませる。これが、モダンな開発における鉄則です。
—
2. CircleCIにおける2つの環境変数管理アプローチ
CircleCIでは、主に2つの方法で環境変数を管理できます。それぞれの役割と使い分けを、優しく紐解いていきましょう。
1. Project Environment Variables（プロジェクト単位）
- 特定のプロジェクト（リポジトリ）だけで使う秘密情報を管理します。
2. Contexts（コンテキスト：組織・プロジェクト横断）
- 複数のプロジェクトで使い回したい秘密情報や、アクセス権限を厳格に管理したい場合に使います。
初心者のうちは「プロジェクト単位」で十分ですが、チームが大きくなったり、マイクロサービス化が進むと「Contexts」が最強の武器になります。今回は両方ともしっかり押さえていきましょう！
—
3. 基礎セットアップ：プロジェクト環境変数の設定方法
まずは、最も基本である「プロジェクトごとの環境変数設定」から行います。例として、AWSのアクセスキーを安全に渡すシナリオを考えてみましょう。
手順：CircleCIダッシュボードからの設定
1. CircleCIのWebダッシュボードにログインします。
2. 対象のプロジェクトの横にある歯車アイコン（Project Settings）をクリックします。
3. サイドメニューから Environment Variables を選択します。
4. Add Environment Variable ボタンを押します。
- Name: `AWS_ACCESS_KEY_ID` （大文字とアンダースコアが基本です）
- Value: `AKIAIOSFODNN7EXAMPLE` （実際の秘密の値）
5. 保存すれば完了です！
設定した環境変数を `.circleci/config.yml` で使ってみよう
設定した環境変数は、特別なコードを書かなくても、自動的にCircleCIのコンテナ内に渡されます。以下のような設定ファイルで呼び出すことができます。
version: 2.1
jobs:
build:
docker:
- image: cimg/node:18.16.0
steps:
- checkout
# 環境変数が正しく渡されているか確認する（HelloWorld的テスト）
- run:
name: Check Environment Variables
command: |
echo “AWS Keyの先頭文字は: ${AWS_ACCESS_KEY_ID:0:4}…”
if [ -z “$AWS_ACCESS_KEY_ID” ]; then
echo “エラー：環境変数が設定されていません！”
exit 1
else
echo “成功：環境変数は安全に読み込まれています。”
fi
workflows:
version: 2
main-workflow:
jobs:
- build
この設定（HelloWorld的な動作確認用ジョブ）をリポジトリにプッシュしてCircleCIを走らせてみてください。ログ画面に「成功：環境変数は安全に読み込まれています。」と表示されたら大成功です！
—
4. 【本丸】Contextsを使って環境変数をスマートに共有・管理する
さて、ここからが少しステップアップした内容です。
もし、あなたが「フロントエンド用リポジトリ」「バックエンド用リポジトリ」「バッチ処理用リポジトリ」の3つを管理していて、すべてで共通の本番データベースのパスワードや、共通のSlack通知用Webhook URLが必要になったとします。
プロジェクトごとにいちいち同じ環境変数をコピペ設定するのは……面倒ですし、パスワード変更時のメンテンス地獄が見えますよね。
ここで登場するのが Contexts（コンテキスト） です。
Contextsのメリット
- DRY原則の適用: 一度Context内に環境変数を登録すれば、どのプロジェクトからでも呼び出せます。
- 強固な権限管理: 「このContextを使えるのは特定のGitHubチームだけ」といった制限をかけられます（本番環境用のキーなどを守るのに必須！）。
Contextsの設定手順
1. CircleCIダッシュボードのサイドメニューから Organization Settings（組織設定）を開きます。
2. Contexts をクリックし、Create Context ボタンを押します。
3. コンテキスト名を入力します（例: `production-secrets` や `shared-api-keys`）。
4. 作成したコンテキストの中に、環境変数（例: `STRIPE_SECRET_KEY`）を追加します。
config.yml で Contexts を呼び出す方法
作成したContextをパイプラインで利用するには、`.circleci/config.yml` の `workflows` セクションで `context` キーを指定します。
version: 2.1
jobs:
deploy-to-production:
docker:
- image: cimg/base:stable
steps:
- checkout
- run:
name: 本番デプロイ処理
# ここでは説明用のダミーコマンドです
command: echo “Stripeの秘密キーを使ってデプロイ処理を実行中… キーの長さ: ${#STRIPE_SECRET_KEY}”
workflows:
version: 2
production-workflow:
jobs:
- deploy-to-production:
# ここで先ほど作成したContextを指定する！
context:
- production-secrets
- aws-common-creds # 複数のContextを並べて指定することも可能です
たったこれだけです！ `context: production-secrets` と1行書くだけで、そのジョブ内でのみ、組織レベルで安全に管理された秘匿情報にアクセスできるようになります。
—
5. シニアが教える、セキュリティ運用の心得（ハック）
最後に、現場で事故を起こさないための「心構えとハック」をいくつか授けます。
1. ログへの露出（マスク機能）に過信しすぎない
CircleCIは、登録された環境変数の値がビルドログに出力されると、自動的に `` (アスタリスク) でマスクしてくれます。しかし、変数を加工（例: Base64エンコードしたり、一部だけ切り出したり）した場合、マスク機能が効かずにログに平文で流れてしまうことがあります。ログ出力のテストは慎重に行ってください。
2. 定期的なローテーション
APIキーは「一生モノ」ではありません。Contextsの変数を書き換えるだけで、コード側を変更せずに安全にキーの差し替え（ローテーション）ができるのが、この仕組みの最大のメリットです。
3. 権限（Security Groups）の絞り込み
本番環境用のContextには、デプロイ権限を持つシニアエンジニアや特定のチームのみがアクセスできるように、CircleCIのアクセス制限機能（Restrict Context）を必ずかけましょう。
—
おわりに
いかがでしたでしょうか？
今回はCircleCIの環境変数管理と、Contextsを使ったスマートな共有・権限管理について解説しました。
最初は設定項目が多くて難しく感じるかもしれませんが、「コードの外側に秘密を置き、必要な場所だけに安全に渡す」という原則さえ掴んでしまえば、あなたの開発環境は鉄壁のものになります。
セキュリティがしっかりしていると、心置きなくダイナミックなコードを書くことができます。
これをマスターすれば、毎日のデプロイ作業が劇的に安心で楽しいものになりますよ。明日からの開発に、ぜひ取り入れてみてくださいね！