はじめに
AzureでWebアプリを開発している際、DBの接続文字列やAPIキーなどの「機密情報」をどう扱うべきか悩んだことはありませんか？
「ソースコードに直書きするのはNG」というのは共通認識ですが、いざAzureで管理しようとすると「App Serviceの環境変数（構成）」と「Azure Key Vault」のどちらを使うべきか、その境界線が分かりにくいものです。
今回は、私が実際に開発で「Key Vaultを使いたかったけれど、結局環境変数で対応した」という経験をベースに、それぞれの違いと使い分けのポイントを整理しました。
なぜソースコードに「機密情報」を書いてはいけないのか？
まず大前提として、パスワードや接続文字列をソースコードや appsettings.json にハードコーディングしてはいけません。
• GitHubなどのリポジトリ経由で漏洩するリスク
• 環境（開発・本番）ごとの切り替えが困難になる
この対策として、Azureには主に2つの逃げ道があります。
1. App Serviceの「環境変数（構成）」による管理
今回私が採用したのが、Azure App Serviceのメニューにある「構成（環境変数）」に値を設定する方法です。
メリット
• 設定が非常に簡単： Azureポータルからポチポチ入力するだけで即反映されます。
• コードの修正が最小限： .NETであれば Configuration["Key名"] で読み取る標準的な手法がそのまま使えます。
デメリット
• 閲覧権限の問題： Azureポータルの該当リソースにアクセスできる人なら、誰でも値が見えてしまいます。
• 共有ができない： 別のApp ServiceやFunctionsでも同じ値を使いたい場合、それぞれにコピーする必要があります。
2. Azure Key Vaultによる管理
本来、より高いセキュリティを求めるならこちらが本命です。
メリット
• 最高レベルの機密性： 値そのものを隠蔽でき、誰がいつアクセスしたかのログも残ります。
• 一元管理： 複数のサービスで一つのパスワードを使い回す場合、Key Vault側を更新するだけで全サービスに反映されます。
デメリット
• 設定のハードル： 「マネージドID（Managed Identity）」の設定や、アクセス権限（RBAC）の付与など、初見では少し難解な概念が登場します。
結局、どう使い分けるのが正解？
結論から言うと、以下のような基準で使い分けるのがスムーズです。
• App Serviceの環境変数（構成）で管理すべきもの
• アプリの動作設定（例：ログレベル、デバッグモードのON/OFF）
• 頻繁に変更する非機密なパラメータ（例：表示件数の上限、外部APIのベースURL）
• Azure Key Vaultで管理すべきもの
• 機密情報（例：データベースの接続パスワード、外部サービスのAPIキー）
• 証明書や暗号化キー（例：SSL証明書、署名用秘密鍵）
【Tips】「とりあえず動かす」から「理想」へのステップアップ
もし私のように「Key Vaultは難しそうで、今回は環境変数で済ませた」という場合でも、実は「Key Vault参照」という機能を使えば、後から簡単に移行できます。
App Serviceの環境変数に、直接値を入れるのではなく以下のような形式で記述します。
@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)
これなら、アプリのコードは1行も変えずに、裏側の保存先だけをKey Vaultに格上げすることができるのです。
まとめ：まずは「外に出す」ことが第一歩
Azure開発において、「Key Vaultを使いこなせなかった」というのは決して失敗ではありません。「ソースコードから機密情報を追い出した」という時点で、セキュリティレベルは大きく向上しているからです。
1. まずはApp Serviceの環境変数で「外出し」に慣れる。
2. 余裕が出てきたら「Key Vault参照」に挑戦してみる。
このステップで進めるのが、挫折しないAzure運用のコツだと感じました。