ハードコーディングが危険な理由｜パスワード流出の仕組みと回避策を初心者向けに解説

「ハードコーディング（hard coding）」とは、本来は外部ファイルや環境変数などに分けて管理すべきデータや設定値を、プログラムのソースコード内に直接書き込んでしまうことです。「ハードコード」とも呼ばれます。

たとえば、システムにアクセスするためのパスワードや、外部サービスと連携するためのAPIキーを、プログラムの中に「そのまま文字として」書いてしまうイメージです。鍵（パスワード）を毎回鍵穴に差し込む代わりに、「ドアに鍵を直接くっつけてしまう」ような状態と言えます。開け閉めは楽ですが、鍵の意味がなくなってしまいます。

ソフトコーディングとの違い
ハードコーディングの対義語は「ソフトコーディング（soft coding）」です。ソフトコーディングでは、データや設定値をコードの外側（設定ファイル・データベース・環境変数など）に置き、プログラムはそれを読み込む形にします。こうすることで、コードを変更せずに設定だけを変えられます。

ハードコーディングの具体例（良い例・悪い例）

実際のコードで比べてみましょう。ここではPythonを例に使いますが、考え方はどの言語でも同じです。

悪い例：ハードコーディング（パスワードを直書き）

# NG：パスワードをコードに直書きしている
import mysql.connector

conn = mysql.connector.connect(
host="192.168.1.100",
user="admin",
password="example_password_do_not_use",   # ← これがハードコーディング！
database="customer_db"
)

このコードをGitHubなどで公開した瞬間、パスワードが世界中に流出する可能性があります。

良い例：環境変数を使う

# OK：パスワードを環境変数から読み込む
import mysql.connector
import os

conn = mysql.connector.connect(
host=os.environ.get("DB_HOST"),
user=os.environ.get("DB_USER"),
password=os.environ.get("DB_PASSWORD"),  # ← コードに書かない
database=os.environ.get("DB_NAME")
)

環境変数の値はコード内に書かないため、ソースコードだけをGitHubに上げてもDB_PASSWORDの値は含まれません。ただし、.envファイルやサーバー設定を誤って公開しないよう注意が必要です。

税率の例で見る「変更が大変な問題」

# NG：消費税率を数値で直書き（マジックナンバー）
price_a = 1000 * 1.08
price_b = 500 * 1.08
price_c = 3000 * 1.08

# OK：定数として定義しておく

TAX_RATE = 1.10  # 税率が変わってもここだけ直せばOK
price_a = 1000 * TAX_RATE
price_b = 500 * TAX_RATE
price_c = 3000 * TAX_RATE

消費税率が10%に変わったとき、悪い例では「1.08」と書かれた全箇所を探して直す必要があります。見落とした箇所があれば計算ミスが発生します。良い例ではTAX_RATE = 1.10の1行を変えるだけで済みます。

マジックナンバーとの関係

ハードコーディングと深く関係する用語に「マジックナンバー」があります。マジックナンバーとは、コードの中に突然現れる「意味の説明がない数値」のことです。

# マジックナンバーの例
if user_age >= 20:   # この「20」は何を意味するのか？
    allow_purchase()

「20」が何を意味するのか、コードを読んだだけではわかりません。成人年齢？会員ランクの基準？後から読む人（未来の自分も含む）が混乱します。

定数に名前を付けることで、意味が明確になります。

# 改善後
ADULT_AGE = 20  # 成人年齢

if user_age >= ADULT_AGE:
allow_purchase()

マジックナンバーはセキュリティ上の直接的なリスクは低いですが、コードの可読性・保守性を大きく損ないます。ハードコーディングの問題点として一緒に語られることが多い概念です。

なぜハードコーディングしてしまうのか

「ハードコーディングはダメ」と知っていても、現場では起きてしまいます。その背景には、よくある4つの理由があります。

とりあえず動かしたい（速度優先）

開発の初期段階や試作（プロトタイプ）を急いで作るとき、「まずは動けばいい」という気持ちから直書きしてしまいます。問題は、その「仮」のコードがそのまま本番環境に出てしまうケースが多いことです。

設定ファイルの扱いが面倒

環境変数や設定ファイルを使いこなすには、一定の知識が必要です。「どう書けばいいかわからない」という理由で、とりあえず直書きしてしまうことがあります。

「このコードは公開しない」という思い込み

「社内用だから大丈夫」「GitHubには上げないから平気」という油断が事故につながります。コードは思わぬ形で外部に出てしまうことがあります。

引き継いだコードがすでにハードコーディングされていた

前任者が書いたコードをそのまま使い続けるケースです。「変えると動かなくなるかもしれない」という不安から、問題を知りながら放置してしまいます。

ハードコーディングの問題点

ハードコーディングには、セキュリティ以外にも多くの問題があります。

メンテナンス性の低下

値が変わるたびにソースコードを修正してビルド（コンパイル）し直す必要があります。小さな変更でも大きな手間がかかります。

修正漏れによるバグ

同じ値が複数の場所に書かれていると、一部だけ修正して他を忘れるリスクがあります。たとえば税率の例で、100箇所あるうち99箇所直して1箇所だけ「1.08」のままだと、その部分だけ計算が狂います。

再利用性の低下

特定の環境を前提に書かれたコードは、別のプロジェクトや環境では使いにくくなります。「少し変えれば使えるのに、直書きの部分が邪魔で全部書き直しになった」という経験をした開発者は少なくありません。

テストがしにくくなる

本番の設定値がコードに混ざっていると、テスト環境で動かすときに設定を差し替えるのが難しくなります。「テスト用の値に変えてコードを書き換える→テスト→本番用に戻し忘れる」という事故も起こりやすくなります。

セキュリティリスク

特にパスワード・APIキー・暗号鍵などを直書きした場合、コードが漏えいした瞬間に機密情報も漏えいします。これは後述する被害事例でも明らかです。

セキュリティリスクを詳しく見てみよう

ハードコーディングによるセキュリティリスクの中でも、特に深刻なのが認証情報（クレデンシャル）の漏えいです。

GitHubへの誤公開

開発者がソースコードをGitHubなどのコード共有サービスに公開する際、パスワードやAPIキーが書かれたファイルをうっかり含めてしまうケースがあります。一度公開されると、たとえすぐ削除しても、Gitの履歴、フォーク、キャッシュ、第三者が取得したコピーなどに残る可能性があります。また、インターネット上のボットが自動的にGitHubをスキャンして認証情報を探しているため、短時間で悪用される可能性もあります。

内部犯行・退職者による漏えい

社内のエンジニアや退職者がコードのコピーを持ち出した場合、ハードコーディングされた認証情報も一緒に流出します。パスワードが分離管理されていれば、流出後すぐに変更できますが、コードに直書きされていると変更するためにはコードの修正・デプロイ（公開）作業が必要になり、対応が遅れます。

デバイスのデフォルトパスワード問題

IoT機器（ルーターや監視カメラなど）のファームウェアに管理者パスワードがハードコーディングされているケースがあります。このパスワードは全製品共通であることが多く、一度知られると全世界の同型機種が攻撃対象になります。

実際の被害・注意事例2選

事例①：2022年 Uber社への大規模不正アクセス

ライドシェア大手のUberは、2022年9月に大規模な不正アクセスを受けました。攻撃者は、Uberの社内ネットワークに侵入し、PowerShellスクリプト（自動化作業用のプログラム）の中にハードコーディングされた管理者アカウントの認証情報を発見したと報じられています。この情報をもとに、社内の複数のシステムへの高レベルアクセス権を次々と取得したとされています。

結果として、社内の脆弱性管理システム・コード管理システム・クラウドサービスなど、多数の重要システムへのアクセスが許されてしまったと報じられました。この事例は、管理者権限を持つ認証情報をスクリプトや共有領域に残すことが、侵害後の被害拡大につながる危険性を示しています。
参考：The Uber Hack’s Devastation Is Just Starting to Reveal Itself｜WIRED
参考：Unpacking the Uber Breach｜CyberArk

事例②：GitHub認証情報の漏えいによりリポジトリがコピーされた事例

GitHubなどのコード管理サービスでは、認証情報が漏えいすると、非公開リポジトリへの不正アクセスや、ソースコードのコピーにつながる可能性があります。コードの中にAPIキー・パスワード・トークンなどが含まれている場合、リポジトリのコピーと同時に認証情報も流出するおそれがあります。

サイバーセキュリティ.comでは、マネーフォワードグループが利用するGitHubの認証情報が漏えいし、第三者の不正アクセスによりリポジトリがコピーされた事例が報じられています。同社は判明後、GitHubの認証情報の無効化や、ソースコードに含まれていた各種認証キー・パスワードの無効化などを実施したとされています。

この事例は、コード管理サービスの認証情報そのものを守ることに加えて、ソースコード内に認証キーやパスワードを残さない運用が重要であることを示しています。

株式会社マネーフォワード、GitHubへの不正アクセスを発表　リポジトリがコピーされ個人情報の一部流出の可能性

2026.5.7

画像：株式会社マネーフォワード

ハードコーディングを避ける方法

ハードコーディングを避けるための主な方法を紹介します。難しく考える必要はありません。「コードの外に出す」という発想が基本です。

環境変数を使う

OSの「環境変数」という仕組みを使って、パスワードやAPIキーをコードの外に保存します。コードからは「このOSの環境変数を読む」という命令だけを書きます。

# Linux/Macでの環境変数の設定例（ターミナルで実行）
export DB_PASSWORD="example_password_do_not_use"

# Pythonでの読み込み例

import os
password = os.environ.get("DB_PASSWORD")

.envファイルを使う（開発環境向け）

「.env（ドットイーエヌブイ）」という設定ファイルに認証情報をまとめ、コードから読み込む方法です。必ず.gitignoreに追加して、Gitの管理対象から除外してください。

# .envファイルの例
DB_HOST=192.168.1.100
DB_USER=admin
DB_PASSWORD=example_password_do_not_use
DB_NAME=customer_db

⚠ .envファイルは絶対にGitHubにアップしないこと！

設定ファイル（YAML・JSON形式）

アプリケーションの設定をYAMLやJSON形式の外部ファイルに書き出す方法です。環境ごと（開発用・本番用）に設定ファイルを切り替えられます。

定数として定義する（機密情報以外）

パスワードなどの機密情報ではなく、税率・最大文字数・タイムアウト秒数などの「変わりうる値」については、コードの先頭で定数として定義します。機密情報は必ず環境変数やシークレット管理ツールを使ってください。

ハードコーディングが許容されるケース

「ハードコーディングは絶対NG」というわけではありません。以下のケースでは、ハードコーディングが認められることがあります。

変わらない定数を分かりやすく定義する場合

円周率（π = 3.14159…）や数学定数など、永遠に変わらない値はコードに書いても問題ありません。むしろ定数名で意味を明確にすることが推奨されます。

試作（プロトタイプ）段階で本番に出ない前提の場合

「動作確認用のサンプルコード」や「ハンズオン用の教材」などで、本番環境には絶対に使わないことが明確な場合は許容されます。ただし「プロトタイプ→そのまま本番」という流れには要注意です。

極めて単純な個人の1回限りスクリプト

自分一人だけが使い、絶対に共有しない使い捨てスクリプトであれば、実害は生じにくいです。しかし習慣づけのためにも、普段から分離管理を心がけることをおすすめします。

現場で使えるチェックリスト

コードをレビューするとき・コミット（保存）する前に確認しましょう。

ハードコーディング防止チェックリスト

パスワード・APIキー・トークンがコードに書かれていないか？
環境ごとに変わるIPアドレス・URL・サーバーパスワード・ファイルパスがベタ書きされていないか？
「1.08」「20」などの意味不明な数値（マジックナンバー）がないか？
.envファイルが.gitignoreに追加されているか？
設定値が環境ごと（開発・本番）に切り替えられるか？
シークレット管理ツールを導入しているか（本番環境の場合）？
git commitの前にgit diffでコードの差分を確認したか？

よくある質問（FAQ）

Q. ハードコーディングはどのプログラミング言語でも起きますか？

はい、言語を問わず起こります。Python・JavaScript・Java・PHP・Rubyなど、あらゆる言語で発生します。言語ではなく「コードの書き方・管理の仕方」の問題ですので、どの言語を使っていても対策が必要です。

Q. 「プライベートリポジトリ」なら安全ではないの？

プライベートリポジトリ（非公開設定のGitHub等）でも完全に安全とは言えません。権限設定のミス・アカウント乗っ取り・リポジトリの誤公開・退職者のアクセス権放置など、思わぬ経路で漏えいする可能性があります。認証情報はプライベートかどうかにかかわらず、コードから分離して管理することが基本です。

Q. すでにハードコーディングしてしまったコードはどう直せばいい？

まず最優先で、漏えいしている可能性のあるパスワードやAPIキーを無効化・再発行してください。次に、環境変数や設定ファイルに値を移してコードを修正します。Gitの履歴にも残っている場合は、git filter-repoやBFG Repo-Cleanerなどのツールで履歴から削除する方法があります。ただし、履歴から削除しても、すでに第三者に取得された認証情報は安全にならないため、必ず無効化・再発行を先に行ってください。

Q. 環境変数はどこで設定するの？

開発環境（手元のPC）では、ターミナルでexport 変数名=値と設定するか、.envファイルを使います。本番サーバでは、サーバの設定ファイル（/etc/environmentなど）やDockerの設定、クラウドサービスの管理コンソールで設定します。Heroku・Vercel・AWSなどのクラウドサービスには、管理画面で環境変数を設定する機能があります。

Q. ハードコーディングを自動で検出するツールは？

あります。代表的なものとして「git-secrets」「truffleHog」「detect-secrets」「GitGuardian」などがあります。これらはコードの中のパスワードっぽい文字列やAPIキーのパターンを自動で検出してくれます。CIパイプライン（コードを自動でテスト・ビルドする仕組み）に組み込んで、コミット時に自動スキャンする運用が現場では推奨されています。

Q. 設定ファイルに書いたパスワードも漏えいリスクは？

設定ファイル自体をGitで管理してしまうと、結局ハードコーディングと同じリスクがあります。.envや設定ファイルは必ず.gitignoreに追加して、Gitの管理対象から除外してください。本番環境では、設定ファイルの代わりにシークレット管理ツールの利用を強くおすすめします。

まとめ

ハードコーディングとは、パスワードやAPIキーなどの機密情報、あるいは税率や定数といった変更されうる値を、ソースコード内に直接書き込んでしまう行為です。一見すると手軽で便利に思えますが、コードが外部に漏れた瞬間に機密情報も一緒に流出するという深刻なリスクをはらんでいます。2022年のUber社への攻撃でも明らかになったように、ハードコーディングされた認証情報は攻撃者にとって格好の足がかりになります。

対策の基本は「コードと設定を分離する」というシンプルな考え方です。環境変数や.envファイルを使う習慣をつけるだけでも、リスクは大幅に減らせます。企業の本番環境では、AWS Secrets ManagerやHashiCorp Vaultといった専用のシークレット管理ツールを導入することで、より安全な運用が実現できます。また、truffleHogやGitGuardianのような自動検出ツールをCIパイプラインに組み込むことで、ヒューマンエラーによるうっかりコミットも防ぐことができます。

「まずは動かしたい」という気持ちはよく理解できますが、その「仮のコード」が本番に出てしまうケースは後を絶ちません。チェックリストを活用しながら、コードをコミットする前に一度立ち止まって確認する習慣が、最大の防御策になります。ハードコーディングをしない開発文化を根付かせることが、セキュリティ事故を未然に防ぐ一番の近道です。