← 用語集一覧へ戻る

ハードコード

Hard-coding
coding-style beginner
本来は設定やデータとして外に出しておきたい値を、コードの中に直接ベタ書きしてしまうこと。
ハードコード (Hard-coding)

概要（サマリー）

本来は設定やデータとして外に出しておきたい値を、コードの中に直接ベタ書きしてしまうこと。

たとえば、パスワード、APIキー、税率、送料、商品価格、URL などをコードの中へそのまま書いてしまうと、あとで変更しにくくなったり、秘密情報が漏れやすくなったりする。
このような「変わる可能性がある値」「環境ごとに違う値」「隠すべき値」を直接書いてしまうのがハードコードである。

AIにコードを書かせるときも、「ここはハードコードしないでください」と伝えると、設定ファイルや環境変数、定数、引数などへ切り出した、変更しやすいコードになりやすい。

詳細解説

ハードコード（Hard-coding）とは、本来は外から渡したり、設定として管理したり、データとして分けたりすべき値を、コードの中に直接書いてしまうことである。
日本語では「ベタ書き」と説明されることも多い。

たとえば、次のようなコードがあるとする。

const tax = price * 0.1;

この 0.1 が常に固定で、将来も絶対変わらないなら問題になりにくいこともある。
しかし、税率は将来変わる可能性がある。
その場合、この数字を何か所にもベタ書きしていると、後から全部探して直さなければならなくなる。

つまりハードコードは、
その場では手軽だが、後から困りやすい書き方
になりやすい。

なぜハードコードが問題になりやすいのか

ハードコードが問題になるのは、値と処理が強く結びつきすぎるからである。
本来は別で管理した方がよいものをコードに埋め込むと、次のような問題が起こりやすい。

  • 値の変更がしにくい
  • 同じ値を何か所も直す必要が出る
  • コードが読みにくくなる
  • 環境ごとの差し替えが難しくなる
  • 秘密情報が漏れやすくなる

つまりハードコードは、短期的には楽でも、
保守性・安全性・再利用性を下げやすい
のである。

どんなイメージで考えればよいか

初心者向けには、次のようなたとえがわかりやすい。

壁に直接予定を書き込む

ホワイトボードやメモ帳ではなく、部屋の壁に直接予定を書いてしまうようなもの。
あとで変更したくなったときに困る。

服のサイズを縫い付けて固定する

着る人に合わせて変えたいのに、最初からサイズを固定してしまうと使い回ししづらい。

店の看板に毎日の価格を書く

日替わりで変わる値段を看板へ直書きしていると、毎回大変になる。
別の価格表にしておいた方が楽である。

どんなものがハードコードになりやすいのか

ハードコードされがちなものには、次のようなものがある。

  • APIキー
  • パスワード
  • メールアドレス
  • URL
  • 税率
  • 送料
  • 商品価格
  • 管理者名
  • 固定メッセージ
  • 環境ごとに違う設定値

つまり、変わる可能性がある値 や 外へ出して管理したい値 は、ハードコードすると問題になりやすい。

セキュリティ面で危険なハードコード

特に危険なのは、秘密情報のハードコードである。
たとえば、

などをコードへ直接書いてしまうと、GitやGitHubへそのまま残る危険がある。
これにより、不正利用や情報漏えい、課金トラブルにつながることがある。

このため、秘密情報は通常、

  • 環境変数
  • .env
  • 秘密情報管理サービス

などへ分けて管理するのが基本である。
ただし、.env を使う場合も、通常は .gitignore に入れて、GitHubへ公開しないようにする必要がある。

ハードコードと定数の違い

初心者が混同しやすいのが、定数との違いである。

たとえば、同じ 0.1 でも次のように書く。

const TAX_RATE = 0.1;
const tax = price * TAX_RATE;

これはコード中に値があるという意味では似ているが、少なくとも

  • 意味が分かりやすい
  • 修正箇所が1か所で済む

という点で、単純なベタ書きより良いことが多い。

つまり、ハードコードが問題になるのは主に
意味が見えないまま、変更しそうな値が処理の中に直接散らばっている状態
である。

何でもハードコードが悪いわけではない

ここは大事な点である。
初心者は「数字や文字を直接書いたら全部ダメ」と思いやすいが、そこまで極端ではない。

たとえば、

  • for (let i = 0; i < 10; i++)
  • padding: 8px;
  • status === "open"

のように、文脈上かなり自然で、変更頻度も低く、意味も明確なものは、必ずしも悪いハードコードとは限らない。
ただし、上の 10 のような数値も、仕様上の上限や業務ルールを表しているなら、定数名を付けた方がよい場合がある。

重要なのは、

  • 変更されやすいか
  • 環境ごとに違うか
  • 秘密情報か
  • 意味が分かりにくいか
  • 再利用性を下げるか

で判断することである。

よく問題になる「マジックナンバー」

ハードコードの文脈でよく出るのが マジックナンバー である。
これは、意味の説明なしに突然出てくる数字のことを指す。

たとえば、

if (status === 7) { ... }

のように 7 が何を意味するのか分からないと、後から読む人が困る。
このような数字は、定数名などへ置き換えた方が分かりやすいことが多い。

つまりハードコードの問題には、
変更しにくさ だけでなく、意味の分かりにくさ も含まれる。

ハードコードを避ける方法

ハードコードを減らす方法としては、次のようなものがある。

1. 環境変数に出す

APIキー、DB接続情報、外部URLなど。

2. .env に書く

環境ごとに変わる設定や秘密情報。
.env は、環境変数として読み込ませる値をファイルにまとめておくためのものと考えるとわかりやすい。

3. 定数にまとめる

税率、固定ステータス、制限値など。
ただし、APIキーやパスワードのような秘密情報は、定数にしても安全にはならない。定数化は、コード内に置いても問題ない公開可能な固定値に向いている。

4. 設定ファイルへ分ける

送料、プラン設定、文言設定など。

5. データベースで管理する

商品価格、記事タイトル、ユーザー情報など。

つまり、値の性質に応じて
コードの外へ逃がす
のが基本的な考え方である。

コーディングでの具体例

たとえば次のようなコードがある。

fetch("https://api.example.com/v1/users");

これ自体は動くが、URLが本番用と開発用で変わるなら不便である。
その場合は、環境変数や設定値に切り出した方がよい。

また、次のようなものもよくある。

if (user.role === "admin") { ... }

この "admin" が仕様として固定されているなら問題ないこともあるが、複数個所で散らばっているなら定数化した方がよいかもしれない。

つまり大事なのは、
その値が「その場限りの自然な値」なのか、「後で管理したくなる値」なのか
を見極めることである。

AIコーディングで重要な理由

AIは、指示しないと手っ取り早い形で値をベタ書きすることがある。
たとえば、

  • APIキーをそのままコードへ書く
  • URLを直書きする
  • 定数にすべき数値を各所へ散らばせる
  • メッセージ文を何度も重複させる

といったことが起こりうる。

そのためAIに対しては、

  • ハードコードしないでください
  • APIキーは環境変数から読んでください
  • 設定値は定数化してください
  • 環境ごとに切り替えられるようにしてください

のように指示すると、かなり質が上がりやすい。

つまりハードコードを理解していると、
AIに保守しやすいコードを書かせやすくなる
のである。

より詳しくAIに聞いてみよう

  • ハードコードとは何かを、中学生でもわかるように説明してください。
  • ハードコードと定数化の違いを、具体例つきで教えてください。
  • APIキーやパスワードをハードコードしてはいけない理由を説明してください。
  • どんな値は環境変数に出すべきか、初心者向けに整理してください。
  • AIに「ハードコードしないで」と伝えるときの具体的な指示例を教えてください。