ハードコーディングとは？ベタ打ちが招く事故と対処

30秒で分かる定義

ハードコーディング（Hardcoding、読み方：はーどこーでぃんぐ）とは、財務モデルの数式の中に数値を直接書き込むことです。ベタ打ち、数式内の数値直書きとも呼ばれ、帳尻を合わせるために入れる調整値は特にプラグ（Plug Number）と呼ばれます。=B10*0.3 の 0.3 や、=B10-B11+50 の 50 がこれにあたります。数字は正しく出ますが、その前提がどこにあるか誰にも分からず、前提が変わっても永久に更新されないため、モデリングの世界では原則として禁止されています。

なぜ実務で重要なのか

ハードコードの怖さは、発見されにくいことにあります。エラーは出ず、数字は一見もっともらしく、感応度分析を回しても動きません。「税率を変えて感応度を見たのに結果が変わらない」という現象が起きたら、まず疑うべきはハードコードです。M&A案件で税制改正を織り込む、PEの投資検討で金利前提を上げる、といった場面で、前提を変えたのにモデルの一部だけが古い値のまま動かない状態は、意思決定を直接誤らせます。投資銀行のレビューでは、ジュニアが提出したモデルに対しシニアが最初に確認する項目の1つがこれです。財務モデルのクオリティチェック（QC）完全ガイドでも、ハードコードの洗い出しは基本工程に位置づけられます。

計算式（または仕組み）

何がハードコードで、何がそうでないかの線引きを整理します。

判断の基準は単純です。

税率、成長率、原価率、金利、倍率、日数前提——これらはすべて議論の対象です。一方、月数の12や日数の365は、誰も交渉しません。この線引きで実務上ほぼ迷いません。

整数設例で確認する

設例（架空数値）。単位は百万円です。税引前当期純利益1,000の会社で、法定実効税率を30%として税金と純利益を計算します。

• 税金 ＝ 1,000 × 30% ＝ 300　／　純利益 ＝ 1,000 − 300 ＝ 700

ここで税率前提を35%へ見直したとします。前提セルを参照している箇所は正しく更新され、税金 ＝ 1,000 × 35% ＝ 350、純利益 ＝ 1,000 − 350 ＝ 650 になります。

ところが、税金計算行の1期分だけが =1000*0.3 とハードコードされていた場合、その期の税金は300のまま、純利益は700のままです。正しい650との差は50（700 − 650 ＝ 50）となり、税率5ポイント分の影響がその期だけ反映されません。

この50の差がどこへ効くかを追います。純利益は利益剰余金を通じてBSへ流れるため、以後の期の利益剰余金がすべて50ずつ過大になり、BSの貸借は合ったまま自己資本だけが50大きい状態になります。ROEも歪みます。自己資本が3,000なら、正しい純利益650でのROEは 650 ÷ 3,000 ＝ 約21.7%、ハードコード状態では 700 ÷ 3,000 ＝ 約23.3% と、1.6ポイント高く見えます。

貸借が合っているのに数字が間違っている——これがハードコードの最も厄介な性質です。バランスチェックでは検出できません。

PL・BS・CFへの影響

ハードコードは三表のあらゆる場所に潜り込みますが、被害が大きいのは決まった箇所です。PLでは税率・償却率・原価率のベタ打ちが利益を直接歪めます。BSでは、貸借差額を埋めるためのプラグが最も危険です。差額が発生している時点でどこかに誤りがあるのに、その差額を「その他資産」や「その他負債」に押し込むと、原因が永久に隠蔽されます。CFでは、間接法の調整項目に手入力の数字が混ざると、営業CFと現金残高の整合が形式的にだけ取れた状態になります。

正しい対処は、差額を埋めるのではなく差額の原因を突き止めることです。バランスしない原因の絞り込み手順はモデルがバランスしない時のデバッグ手順で体系的に扱っています。

財務モデル・Excelでの使い方

ハードコードを作らない・見つける・やむを得ず使う場合に印を付ける、の3点で運用します。

• 洗い出し：ジャンプ機能の「セル選択」で「数式」かつ「数値」を含むセルを選択すると、数式内に数値を含むセルを絞り込めます。予測期間のブロックに対してこれをかけるのが最も効率的です
• 目視での発見：数式表示モードに切り替えると、数値が混ざった数式が視覚的に浮き上がります
• やむを得ない場合の作法：どうしても数式内に置く必要がある場合（一時的な検証など）は、セルを目立つ色（赤字や黄色背景）にして、行末のコメント列に理由と解消予定を書きます。色を付けたハードコードは「宿題」として管理でき、色の付いていないハードコードは事故になります
• 入力セルは青字という規約を徹底すれば、黒字の計算セルの中に数値が紛れている状態自体が異常として認識されます。詳細はモデルの書式規約を参照
• 前提の受け皿を先に作る：ハードコードの多くは「前提を置く場所が無かったから」発生します。前提一覧シートを先に用意しておけば、そもそも数式に埋め込む動機が生まれません

異常値を自動で光らせる仕組みは条件付き書式でエラーを光らせるにレシピをまとめています。

実務家が確認するポイントとよくある誤解

誤解1：「数値が入っているセルはすべてハードコード」→ 正しくは、前提セルに数値が入っているのは当然です。問題なのは数式の中に数値が混ざっている状態です。入力セルと計算セルの区別が付いていないと、この誤解が生じます。

誤解2：「ハードコードは急いでいるときの必要悪」→ 正しくは、前提セルを1つ足す作業と数式に直接書く作業の時間差は数秒です。時間の問題ではなく習慣の問題です。

誤解3：「バランスチェックが通っていればハードコードは無い」→ 正しくは、多くのハードコードはバランスを崩しません。むしろプラグは、バランスを合わせるために入れられます。バランスチェックとハードコード検出は別の作業です。

確認ポイント：受領モデルでは、感応度分析を意図的に極端な値で回してみるのが有効です。税率を0%と50%にして結果が想定通り動かない箇所があれば、その経路のどこかにハードコードがあります。

日本実務での扱い

日本の税制では法定実効税率が改正で変動し得るため、税率をハードコードしたモデルは改正のたびに全面的な見直しを迫られます（2026年7月時点）。同様に、消費税率、償却方法、繰越欠損金の控除限度割合といった制度依存の数値も、必ず前提セルとして外出ししておく必要があります。税制関連の前提をモデルへ乗せる方法はタックスモデリング入門で扱っています。

また、日本の事業会社では、決算や予算の集計に長年使われてきたExcelファイルに、担当者しか意味を知らない調整値が数式内へ埋め込まれたまま残っているケースが少なくありません。金融商品取引法に基づく内部統制報告制度（J-SOX）の観点からも、根拠が説明できない数値が計算に混入している状態は、決算・財務報告プロセスの統制上の弱点として指摘され得ます。M&Aの財務DDでは、対象会社の管理資料にこの種の調整が発見された場合、その調整が過去いつから入っているかを確認し、正常収益力の算定に影響しないかを検証します。財務DDの視点は財務DD（QoE）入門を参照してください。

面接・モデルテストで問われるポイント

Q：モデルレビューでハードコードを見つけたら、どう対応しますか？
「まず、その数値が何を意味するかを作成者に確認します。前提であれば前提シートへ外出しし、参照に置き換えます。差額を埋めるプラグであれば、埋めるのではなく差額の原因を特定する作業に切り替えます。原因が分からないまま数字を合わせると、後から必ず別の形で表面化するためです。時間の制約でその場で直せない場合は、セルを赤くして未解消として記録し、モデルの数字を使う側にその存在を伝えます。存在を隠したまま提出することが最も避けるべき対応です。」

深掘りでは「365や12を数式に書くのは許されるか、その線引きは何か」「プラグとバランス調整の違い」が問われます。

よくある質問（FAQ）

Q. 実績値を数式に直接入力するのもハードコードですか？
A. 実績値は入力セルに置くべきデータであり、計算式の中に書くのは避けます。=1200+800 のように実績を足し込む書き方は、後から内訳を検証できなくなるため、2つの数字をそれぞれ別のセルに置いて合計を計算する形にします。

Q. どうしても外出しできない数値がある場合はどうしますか？
A. 外出しできないケースはほとんどありません。強いて挙げるなら、極めて短命な検証用の一時計算だけです。その場合もセルに色を付け、検証が終わったら削除するか正式な形へ書き直します。「一時的」と自分で判断した数値ほどファイルに残り続けるため、色による目印は必須です。

出典・参考（2026-07-21確認）

• 国税庁（法人税率・法定実効税率に関する情報） https://www.nta.go.jp/
• ICAEW「Twenty principles for good spreadsheet practice」 https://www.icaew.com/
• 金融庁「財務報告に係る内部統制の評価及び監査の基準」（内部統制報告制度） https://www.fsa.go.jp/

※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための架空数値です。