nanが出るときの確認ポイント。まず見るべき設定と入力

2026年4月19日

URLをコピーしました！

ナンが出るときの確認ポイントは、まず見るべき設定と入力を押さえるだけで原因の切り分けが一気に楽になります。
表計算、パイソン、アール、ビジネスインテリジェンスツールまで、ナンはよく出るのに正体が見えづらいもの。この記事では最短で直すための実務チェック順をまとめます。

ナンとはまず知っておきたい意味と起きる場面

ナンは「数ではない」の略で、数値として扱えない状態を表す特殊な値です。
多くの環境ではナンなど表記ゆれがありますが、意味は同じと考えて大丈夫です。

よくあるのは、0で割る、欠損値が混ざる、文字列が紛れ込む、計算途中で無限大が出るといったケースです。
特にデータ分析や集計では、最初は小さな入力ミスでも、後段の計算で一気にナンが増殖して見えるため、早めの確認が重要です。

ナンが厄介なのは、エラーとして止まらずに処理が進むことが多い点です。
気づいたときには集計結果や可視化が崩れていて、どこで壊れたか追いにくくなります。

私も最初は「計算式は合っているのに数値が出ない」状態にハマりましたが、原因の多くは設定か入力のどちらかに寄っています。
このあと紹介する「まず見るべき設定と入力」の順番で追うと、再現性高く直せます。

ナンが出るときの確認ポイント最初に見るべき設定

ナンが出るときの確認ポイントとして、最初に「設定」を疑うのはかなり有効です。
入力データを疑う前に、環境側の前提がズレていると、どんなに入力を整えてもナンが出続けます。

たとえばシーエスブイの読み込み設定ひとつで、数値列が文字列として扱われることがあります。
エクセルやグーグルスプレッドシートでも、表示形式や小数点区切り、ロケールの違いで数値認識が変わります。

設定の確認は地味ですが、ここを飛ばすと調査が長引きます。
私の経験上、チームで作業しているときほど、誰かの環境差やテンプレ設定が原因になりやすいです。

まず見るべき設定チェックリスト

並列で確認しやすいよう、最低限のチェック項目をリスト化します。

文字コードと区切り文字（シーエスブイでカンマかタブか）
小数点と桁区切り（例 1,234.56 と 1.234,56）
型推定の挙動（自動で文字列扱いになっていないか）
欠損値の扱い（空欄、ヌル、欠損値、-、0 の解釈）
無限大の扱い（正の無限大、負の無限大をナンに変換していないか）
計算設定（0除算時にナンを返す仕様か）

設定が原因の場合、同じデータでも環境が変わるとナンの出方が変わります。
「自分のパソコンでは出ないが、別の環境では出る」なら設定差の可能性が高いです。

ナンが出るときの確認ポイント入力データで最初に疑うこと

次に見るべきは入力です。
ナンが出るときの確認ポイントとして、入力の揺れを潰すだけで改善するケースが最も多い印象です。

特に多いのが、見た目は数値でも実体は文字列のパターンです。
全角数字、余計な空白、通貨記号、単位、改行コードなどが混ざると、数値変換に失敗してナンになりやすいです。

また、欠損の混入も定番です。
1行だけ空欄があり、その列を平均するとナンが出る、結合キーが欠けて結合後に欠損が増える、などは現場でよく起きます。

入力を見るときは、全行を眺めるより「ナンが出た場所の周辺」を集中的に見るのが効率的です。
ナンは結果であって原因ではないので、計算に使った元データまで戻って確認します。

入力ミスの典型パターンと見分け方

数値列に文字が混ざる（例 10a、-、不明）
余計な空白やタブ（例 123、123）
全角の混入（例 １２３、－）
単位付き（例 100円、20kg）
欠損（空欄、ヌル、欠損値が想定外で入る）
結合後に欠損が増える（キー不一致で片側がナン）

ここは一度ハマると時間を溶かします。
私は「空白1文字」や「全角マイナス」でナンが出ていたことがあり、見つけたときは拍子抜けしましたが、再発防止のために入力チェックを仕組みにするのが大事だと痛感しました。

0除算や無効演算でナンが出るケースと対処

ナンが出るときの確認ポイントとして、計算式そのものの破綻も見逃せません。
代表例は0で割る処理です。環境によってはエラーで止まらず、結果がナンとして返ってきます。

ほかにも、平方根に負の数を入れる、対数に0以下を入れる、指数計算が発散するなど、数学的に定義されない演算でナンは出ます。
このタイプは入力が正しくても起きるため、式の前提条件をコードやシート側で守る必要があります。

対処の基本は「計算前に条件分岐する」か「ナンを出さない入力に補正する」ことです。
ただし補正は意味を変える可能性があるので、業務上の定義を決めたうえで実施します。

たとえば、分母が0なら結果を空欄にする、0なら0を返す、あるいはフラグ列で異常を記録して別途集計するなど、選択肢はあります。
個人的には、後から追えるように「異常を隠しすぎない」実装が好みです。

よくある無効演算と対処の考え方

0除算
分母が0の行を除外、または結果を欠損扱いにする
対数や平方根の定義域外
事前に値域チェックして除外、または別カテゴリに分ける
オーバーフローや発散
スケーリング、上限下限のクリップ、安定化した式に置換

「ナンが出るのは悪」ではなく、異常を検知できているサインでもあります。
大事なのは、どの条件でナンが出るのかを仕様として言語化することです。

欠損値ナンの扱い方置換と削除の判断基準

欠損値やナンをどう扱うかは、直し方以上に結果の解釈を左右します。
ナンが出るときの確認ポイントとして、置換するのか、削除するのか、別の列で保持するのかを決める必要があります。

欠損をゼロで埋めるのは簡単ですが、意味が変わるリスクがあります。
売上データの欠損を0にすると「売上がなかった」扱いになり、実際は未計測だった場合に分析が歪みます。

一方で、機械学習や集計の都合で欠損を埋めたい場面もあります。
そのときは平均や中央値で埋める、前後値で補間する、カテゴリを追加するなど、目的に合わせた戦略が必要です。

私の現場感覚だと、最初にやるべきは「欠損がなぜ発生したか」の分類です。
入力漏れ、計測不能、結合ミス、対象外など、理由が異なる欠損を同じ処理で埋めると判断が危うくなります。

欠損処理の選択肢比較表

方針	代表的な方法	メリット	注意点
削除	欠損行を除外	実装が簡単で解釈が明快	データが減り偏りが出る
定数で置換	0、-1、空文字など	迅速に処理できる	意味が変わりやすい
統計量で置換	平均、中央値、最頻値	外れ値に強い方法も選べる	分布が歪む可能性
補間	前後値、線形補間	時系列で自然になりやすい	急変点を潰すことがある
フラグ追加	欠損フラグ列を作る	欠損の影響を追跡できる	列が増える、運用設計が必要

ナンが出るときの確認ポイントは「消すか埋めるか」だけではありません。
欠損の意味を残しておくと、後で分析結果の説明がしやすくなります。

すぐ使える切り分け手順まず見るべき設定と入力の順番

最後に、ナンが出るときの確認ポイントを「手順」としてまとめます。
迷ったらこの順番で進めると、最短で原因に近づけます。

最初は「設定」、次に「入力」、その後「計算式」「欠損処理」「再発防止」の順です。
原因究明は、広く薄く探すより、疑う箇所を順番に狭める方が圧倒的に早いです。

また、再発防止までやって初めて解決だと思っています。
一度直しても、同じフォーマットのデータが来たときに再びナンが出るなら、仕組みとして負けています。

切り分けチェック表

ステップ	何を見る	具体例	期待する成果
1	設定	区切り文字、ロケール、型推定	数値が正しく読み込める
2	入力	空白、全角、単位、欠損	ナンの発生源が見える
3	計算式	0除算、定義域、発散	ナンが出る条件を特定
4	欠損処理	削除か置換か、フラグ	結果の解釈が安定
5	再発防止	妥当性検証、テスト	同じ原因で壊れない