そもそも「外部APIキー」とは何か
まず前提をそろえましょう。
外部APIキーというのは、
Google Maps
reCAPTCHA
外部メールサービス（SendGrid など）
決済サービス
各種外部API
といった「外部サービス」を使うときに発行される“秘密の鍵”です。
このキーを知っている人（プログラム）は、そのサービスをあなたの名義で利用できます。
つまり、パスワードにかなり近い“機密情報”だと考えてください。
だからこそ、
テーマファイルの中にベタ書き
プラグインの設定画面に平文で保存
GitHub にそのままコミット
といった扱い方は、とても危険です。
ここで出てくるのが、
「APIキーの置き場所を wp-config.php に移動する」
という考え方です。
なぜ APIキーを wp-config.php に移動すると安全になるのか
wp-config.php は「外から直接読まれにくい場所」にある
wp-config.php は、WordPress の設定の中枢です。
データベース接続情報
認証用のキー・ソルト
テーブル接頭辞
など、もともと機密情報が集まるファイルです。
多くのサーバー構成では、
PHP が正しく動いている限り、wp-config.php の中身がブラウザにそのまま表示されることはありません。
もし URL で wp-config.php にアクセスされても、
PHP として実行されるだけで、ソースコードは見えません。
一方で、
テーマの functions.php にベタ書き
テンプレート内にキーを埋め込む
といったやり方だと、
誤った出力やバグで中身が露出するリスク
Git 管理や配布時にキーごと外に出てしまうリスク
が高くなります。
「機密情報は、もともと機密を置く前提で設計されている場所に集約する」
これが wp-config に移動する一番の意味です。
コードと秘密情報を分離できる
もう一つ大きなメリットがあります。
テーマやプラグインのコード
外部APIキーなどの秘密情報
を分けて管理できる、という点です。
例えば、
テーマやプラグインのファイルは Git で管理wp-config.php はサーバーごとに個別管理（Git に入れない）
という運用にすると、
GitHub にコードを公開しても、
APIキーはリポジトリに含まれない
という状態を作れます。
これは、「コードは共有してもいいが、秘密情報は共有しない」という、
エンジニアとしてとても健全な分離です。
具体的なイメージ：wp-config にキーを置いて、コードから参照する
ステップ1：wp-config.php に定数として定義するイメージ
例えば、Google Maps APIキーを使うとします。
wp-config.php に、こんな感じで書きます。
define( 'MY_GOOGLE_MAPS_API_KEY', 'ここに本物のAPIキー' );
これで、WordPress 全体から MY_GOOGLE_MAPS_API_KEY という定数で
APIキーを参照できるようになります。
ポイントは、
「キーの“本物の値”は wp-config.php にだけ書く」
ということです。
ステップ2：テーマやプラグイン側では「定数を読むだけ」にする
テーマの functions.php やプラグインのコードでは、
直接キーを書かずに、定数を参照します。
$api_key = MY_GOOGLE_MAPS_API_KEY;
// これを使って外部APIを呼び出す
こうしておけば、
テーマやプラグインのファイルを配布しても
Git に上げても
APIキーそのものは含まれません。
「コードは公開してもいいが、wp-config は公開しない」
という前提が守られている限り、キーは外に漏れにくくなります。
例題：やってはいけないパターンと、wp-config に移したパターン
悪い例：テーマファイルにベタ書き
functions.php にこんなコードがあるとします。
$api_key = 'AIzaSyXXXXXXX...'; // ここに本物のキー
この場合、
テーマを他のサイトにコピーしたとき
GitHub にテーマを上げたとき
開発者にテーマ一式を渡したとき
すべてにおいて、APIキーが一緒に漏れます。
さらに、もし何かのバグでこの変数が画面に出力されてしまったら、
ブラウザからも丸見えです。
良い例：wp-config に定義して、コードから参照
wp-config.php：
define( 'MY_SERVICE_API_KEY', '本物のキー' );
テーマやプラグイン：
$api_key = MY_SERVICE_API_KEY;
この構成だと、
テーマやプラグインを配布しても、
APIキーは含まれない。
サーバーごとに wp-config.php の中身を変えれば、
開発環境・本番環境で別のキーを使うことも簡単。
という、セキュリティ的にも運用的にも良い状態になります。
重要ポイント：wp-config に移すこと自体が「魔法の盾」ではない
「wp-config も守る」意識は必須
wp-config に移したからといって、
それだけで絶対安全になるわけではありません。
サーバー設定が崩れて PHP がソースのまま表示される
バックアップファイルとして wp-config.php.bak などを置いてしまう
誤って wp-config.php を ZIP に含めて配布してしまう
といった事故があれば、
当然ながら中身は見られてしまいます。
なので、
wp-config はドキュメントルート直下ではなく一つ上に置く構成にする
バックアップファイルを公開ディレクトリに置かないwp-config.php を Git に入れない
といった「wp-config 自体を守る」意識もセットで必要です。
それでも「テーマやプラグインに書くよりは圧倒的にマシ」
とはいえ、
テーマやプラグインの中にキーをベタ書き
→ 配布・共有・公開のたびに漏洩リスク
という状態に比べれば、
「秘密情報は wp-config に集約する」
という方針は、セキュリティレベルを一段引き上げてくれます。
エンジニアとしては、
コードと秘密情報を分ける
秘密情報は“秘密を置く前提の場所”に集める
という設計ができているだけで、
かなり「ちゃんと考えている人」側に入ります。
プログラミングの感覚で捉える「APIキーを wp-config に移動」
これは「環境変数に秘密情報を出す」のと同じ発想
他の言語やフレームワークでは、
APIキーやDBパスワードは.env ファイルや環境変数に置く
というのが定番です。
WordPress の世界では、wp-config.php がその役割を担っています。
つまり、
「コードから秘密情報を追い出して、設定ファイルに集約する」
という、現代的な設計に一歩近づく行為が、
「APIキーを wp-config に移動する」ということです。
「あとから差し替えやすい」という運用上のメリットも大きい
もう一つ、エンジニア的に嬉しいポイントがあります。
APIキーを wp-config に置いておけば、
本番用のキー
ステージング用のキー
ローカル開発用のキー
を、wp-config.php ごとに変えるだけで切り替えられます。
テーマやプラグインのコードは一切いじらずに、
環境ごとに設定だけ変える——
これは、安全性と開発効率の両方を上げる設計です。
まとめ：「外部APIキーを wp-config に移動」は“秘密を秘密らしい場所に戻す”作業
「外部APIキーの置き場所を wp-config に移動」というテーマの本質は、
APIキーという“パスワード級の機密情報”を
テーマやプラグインのコードから追い出し
wp-config.php という「機密前提の設定ファイル」に集約する
ということです。
押さえておきたいポイントは、
APIキーはパスワードと同じくらい大事な秘密情報であること
コードと秘密情報を分けることで、漏洩リスクと運用コストを同時に下げられること
wp-config 自体も守る前提で、「秘密はそこに集める」という設計にすること
一度、自分のテーマやプラグインの中を検索してみてください。api_key や AIza など、それっぽい文字列がベタ書きされていないか。
もし見つかったら、それは「wp-config に引っ越しさせるべき秘密」が眠っているサインです。
