「ハードコーディングとは何のことか、実はよくわかっていない」という新人エンジニアの方は多いのではないでしょうか。ソースコードの中に、本来は変更されうる値をそのまま書き込んでしまう、あの書き方のことです。この記事では、ハードコーディングとは具体的に何を指すのか、よくある例、なぜ問題視されるのかを、対策方法まで含めて整理します。筆者自身も新人時代にハードコーディングが原因でレビュー差し戻しを経験したので、その実体験も交えて解説します。
ハードコーディングとは？（基礎知識）
ハードコーディングの意味
ハードコーディングとは、本来は設定ファイルや変数として外部化すべき値を、プログラムのソースコード内に直接書き込むことを指すプログラミング用語です。英語の hard coding をそのままカタカナにした言葉で、「ハードコーディングする」という動詞の形でもよく使われます。「オンコーディング」と呼ばれることもありますが、指している内容はほぼ同じです。たとえば接続先のURLやパスワードを、文字列としてそのままコードに埋め込む書き方が典型例です。
ソフトコーディングとの違い
対義語として使われるのがソフトコーディングです。ソフトコーディングとは、値を設定ファイルや環境変数、データベースなど外部から読み込む形にする書き方を指します。ハードコーディングは実装が早い一方、ソフトコーディングは変更に強いという違いがあります。両者はどちらが常に正しいというものではなく、用途に応じて使い分けるものだと筆者は考えています。
ハードコーディングの具体例
ハードコーディングとは何かを理解したところで、実際のコードで見てみましょう。次のような書き方はハードコーディングの典型例です。
def connect_db():
return connect("192.168.1.10", user="admin", password="P@ssw0rd123")
上記のように接続先のIPアドレスやパスワードをそのままコードに書いてしまうと、環境が変わるたびにコードそのものを書き換える必要が出てきます。ほかにも、次のようなケースがハードコーディングに当たります。
- ファイルの保存先パスを
C:\Users\taro\dataのように直書きする - 消費税率や送料などを計算式の中に数値のまま埋め込む、いわゆるマジックナンバー
- 外部APIのエンドポイントURLやAPIキーを文字列として記述する
- 一覧表示の件数上限などを関数の中に直接書く
ハードコーディングのメリットとダメな理由
ハードコーディングとはメリットもデメリットも併せ持つ書き方です。それぞれ順番に見ていきます。
メリットは実装の速さ
ハードコーディングにもメリットはあります。設定ファイルを別途用意する必要がなく、その場ですぐ動くコードが書けるため、検証用のスクリプトや使い捨てのツールでは十分に実用的な書き方です。ハードコーディングとは実装の速さとのトレードオフだと捉えると理解しやすいです。
ダメな理由（デメリット）
一方で、本番環境や長期間保守するプロダクトでハードコーディングをすると、次のような問題が起きやすくなります。
- 環境（開発・検証・本番）ごとに値が違う場合、その都度ソースコードを書き換えてビルドし直す必要がある
- 同じ値を複数箇所に書いていると、一部だけ修正し忘れて不具合につながる
- パスワードやAPIキーをそのまま書くと、GitHubなどにコードを公開した際に認証情報が漏洩するリスクがある
筆者も新人の頃、検証用に書いたAPIキーをそのままコードに残した状態でリポジトリにプッシュし、先輩エンジニアのレビューで指摘を受けたことがあります。幸い公開前に気づいてもらえたので実害はありませんでしたが、キーの再発行やコミット履歴の整理に3時間ほど時間を取られました。履歴からキーを完全に消す作業は想像以上に手間がかかると、このとき実感しました。この一件以来、値を書く前に「これは環境が変わっても同じ値か」を自問するようにしています。
セキュリティの観点でも、認証情報のハードコーディングは代表的な脆弱性のひとつとして知られています。OWASPの脆弱性分類（CWE-798）によると、認証情報をコードに直接埋め込む実装は明確なリスクとして扱われています。
ハードコーディングを避けるための対策
ハードコーディングとはどう向き合えばよいのか、代表的な対策をStep形式で3つ紹介します。
Step 1: 環境変数や設定ファイルに切り出す
ハードコーディングとは反対の方向性で考えます。最も基本的な対策は、変更されうる値を環境変数や .env ファイル、YAML・JSON形式の設定ファイルに切り出すことです。コード側は設定ファイルを読み込むだけにしておけば、環境が変わっても再ビルドせずに値だけ差し替えられます。
Step 2: シークレット管理サービスを使う
パスワードやAPIキーのような機密情報は、設定ファイルにすら平文で書かないようにします。AWS Secrets ManagerやHashiCorp Vaultのようなシークレット管理サービスに預けるのが望ましい方法です。コードからは都度APIで値を取得する形にすれば、リポジトリ自体に機密情報が残りません。
Step 3: 静的解析ツールで検出する
git-secretsやtrufflehogのようなツールを使うと、コミットの前後にハードコーディングされた認証情報を自動検出できます。ハードコーディングとは人的ミスで紛れ込むことが多いため、人の目によるレビューだけに頼らず、機械的なチェックを仕組みとして挟んでおくと安心です。
ハードコーディングはどこまで許容されるのか
ハードコーディングとは何が問題かを見てきましたが、実務では「どこまで厳密にやるべきか」で悩む場面も多いはずです。個人的な感覚を含めて整理すると、次のように考えるとバランスが取りやすいと感じています。
- 学習用のサンプルコードや使い捨てのPoC（概念実証）であれば、ハードコーディングのままでも実用上の問題は小さい
- チームで共有するリポジトリや本番環境で動くコードは、環境ごとに変わる値を最初から外部化しておくべき
- マジックナンバーのように「意味を持つ数値」は、定数として名前を付けるだけでも可読性が大きく上がる
ハードコーディングを避ける習慣は、レビューする他人のためというより、数ヶ月後にコードを読み返す未来の自分のためという側面が大きいと感じています。「この数値は何のためにあるのか」を後から自分で調べ直す時間は、意外とバカにできません。
よくある質問（FAQ）
ハードコーディングとはそもそも悪いことなのですか？
常に悪いわけではありません。使い捨てのスクリプトや学習用コードでは問題になりにくい一方、本番環境や共有リポジトリでは保守性やセキュリティ面のリスクが大きくなります。そのため避けた方がよいとされています。マジックナンバーとハードコーディングは同じ意味ですか？
ハードコーディングとは値をコードに直接書き込むこと全般を指す言葉で、マジックナンバーはそのうち意味の説明がないまま埋め込まれた数値を指します。定数として名前を付けるだけでも改善につながります。ソフトコーディングにすればハードコーディングの問題は解決しますか？
ハードコーディングとは逆の方向に振り切って設定を外部化しすぎると、かえって見通しが悪くなることもあります。値の変更頻度や重要度に応じて、外部化するかどうかを判断するのが現実的です。ハードコーディングされたパスワードはどうやって見つけられますか？
git-secretsやtrufflehogのようなツールを使えば、正規表現のパターンに一致する文字列(APIキーらしき形式のものなど)を機械的に検出できます。目視でのコードレビューだけに頼らず、こうしたツールをCI/CDのパイプラインに組み込んでおくと見落としを減らせます。チーム開発でハードコーディングを防ぐルールはありますか？
まずはコーディング規約に「環境依存の値は設定ファイルまたは環境変数に外部化する」というルールを明文化し、プルリクエストのレビュー観点に加えます。あわせてgit-secrets等の静的解析ツールをレビュー前の自動チェックとして導入すると、ハードコーディングとは無縁のチームに近づけます。まとめ
ハードコーディングとは、変更されうる値をソースコードに直接書き込むことで、実装は早いものの保守性やセキュリティの面でリスクを抱えやすい書き方です。学習用コードやPoCでは許容できる場面も多い一方、本番環境や共有リポジトリでは環境変数化やシークレット管理サービスの活用を検討してください。筆者自身、新人時代のヒヤリとした経験から、値を書く前に「環境が変わっても同じ値か」を確認する習慣がついています。ハードコーディングとは何かを理解したうえで、対策を仕組み化しておくと安心です。