この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。MicrosoftのIFERROR・IFNA関数の公式説明を確認し、架空の備品台帳でエラーを見分ける方法を整理しました。

検証ステータス：📘 公式仕様確認済み・Excel実機操作未実施

ExcelのIFERRORでミスを隠していない？IFNAと比較してエラーを見分ける

検索結果が見つからないとき、セルにエラーが表示されると表が壊れたように見えます。そこで検索式をIFERRORで囲み、エラーをすべて空白にする方法がよく使われます。しかし、その空白は「商品が存在しない」という意味でしょうか。それとも「式そのものが壊れている」のでしょうか。両者を同じ表示にすると、月次集計の数字が間違っていても気づきにくくなります。 、見つからない商品コードと、参照先の設定ミスを意図的に分けます。どちらも見た目はエラーですが、業務上の対応は正反対です。前者は台帳への追加確認、後者は数式の修理が必要です。IFERRORとIFNAの違いを、エラーを消す機能の便利さだけでなく、原因を残す仕組みとして理解します。

対応環境と準備

新規ブックを開き、A1に「コード」、B1に「名称」と入力します。A2にはP101、B2にはノート、A3にはP102、B3にはペン、A4にはP103、B4には付箋を入れてください。実際の社員番号や顧客コードを使う必要はありません。D1に「探すコード」、E1に「検索結果」を入れ、D2にP102、D3にP999を入力します。

この段階では、検索元の台帳にP102は存在しますが、P999はありません。あえて存在しない値を含めることで、未登録と数式エラーを混同しない実験ができます。データを追加するたびに式の参照範囲を変更するのではなく、まず固定した小さな範囲で動きを確かめましょう。

最初の実験：IFERRORで何が消えるか

E2に次の式を入力し、E3までコピーします。VLOOKUPの最後のFALSEは、似たコードではなく完全一致を求める指定です。A列から探し、見つかった行の2列目、つまりB列の名称を返します。

=IFERROR(VLOOKUP(D2,$A$2:$B$4,2,FALSE),"未登録")

仕様どおりなら、D2のP102には「ペン」、D3のP999には「未登録」と表示される想定です。検索先にない値をVLOOKUPが見つけられないと、通常は#N/Aを返します。IFERRORはそのエラーを受け取って、指定した文字列へ置き換えます。見つからないコードを利用者向けの言葉にするという目的なら、確かに便利です。

では、式の列番号を2から3に変更してください。参照範囲A2:B4は2列しかありません。それなのに3列目を返すよう要求するため、VLOOKUPは#REF!を返す条件になります。ところがIFERRORで囲んでいると、これも「未登録」に置き換わります。実際にはP102が台帳に存在するのに、表示だけを見る担当者には存在しないように見えてしまいます。

ここが最初の発見です。IFERRORが隠すのは「見つからない」という事象だけではありません。計算中のさまざまなエラーをまとめて指定値に変えるため、表示をきれいにするほど障害の手掛かりを失う場合があります。空欄や「未登録」が増えたとき、登録漏れだけを疑うのは危険です。

条件を1つ変える：IFNAならどうなるか

次はE2の式をIFNAに置き換え、E3までコピーします。検索範囲やデータは変更しません。違いは、エラーを受け取る関数だけです。

=IFNA(VLOOKUP(D2,$A$2:$B$4,2,FALSE),"未登録")

P102は「ペン」、P999は「未登録」という期待結果になります。ここまではIFERRORと同じです。しかし、VLOOKUPの列番号を3に変えると、IFNAは#REF!を隠しません。IFNAが置き換える対象は#N/Aに限られるためです。つまり、登録されていないコードは利用者向けの表示にしつつ、式の設計ミスはエラーとして残せます。

この違いを確認するため、もう一度列番号を2へ戻してください。戻す操作が重要なのは、正常条件と異常条件を一つずつ切り替えるためです。複数の条件を同時に変えると、どの変更が表示を変えたのか判断できなくなります。小さな実験でも、比較の前提をそろえることが障害切り分けの基本です。

エラーが通る道筋を図で読む

次の図は、検索式が返した結果をIFNAとIFERRORがどう扱うかだけに絞っています。図の上側は元の検索結果、下側は利用者が見る表示です。二つの関数を混ぜて使う設計図ではなく、選択のための比較図です。

flowchart TD
  A[検索式の結果] --> B{結果は何か}
  B -->|正常値| C[両方とも値を表示]
  B -->|#N/A| D[両方とも代替文字列]
  B -->|#REF!など| E[IFNAはエラーを表示]
  B -->|#REF!など| F[IFERRORは代替文字列]

図で重要なのは、#N/Aと#REF!の分岐です。前者は検索先に値がない場合などに生じます。後者は参照の問題を示すため、登録担当者に問い合わせるより数式の参照先を直す必要があります。なお#N/Aが必ず「未登録」を意味するわけではありません。検索値の作り方や元データの型が合っていない場合もあるので、表示文字列は業務の意味に合わせて決めます。

なぜ「空白にすればよい」が危ないのか

IFERRORの第2引数を空文字列にすると、エラーのあるセルが空白に見えます。見た目はすっきりしますが、利用者は「もともと値がない」のか「式が失敗した」のか区別できません。特に帳票を別シートへ転記する処理や、空白セルを除外する集計がある場合、エラーを消したことが別の判断へ影響します。

たとえば発注表の品名を検索し、見つからない行だけを後から修正する運用を考えます。未登録コードを「要確認」と表示すれば、担当者が調査できます。一方、参照範囲を間違えた全行が同じ「要確認」になると、台帳側に問題があるように誤解されます。原因別に表示を分けるだけで、問い合わせ先と復旧作業が変わるのです。

もう一つ注意したいのは、エラーがない場合の空欄です。検索対象の名称セルが本当に空欄なら、VLOOKUPの返り値の見え方は、エラーを置き換える処理とは別に確認する必要があります。IFNAは「空欄を埋める関数」ではありません。欠損データを検出したいなら、検索式の前後で空欄の扱いを別に設計しましょう。

よくある失敗を原因別に切り分ける

まず#N/Aが表示されたら、探すコードが検索列にあるか、前後に空白が混ざっていないか、数字と文字列が混在していないかを確かめます。見た目が同じ「001」と数値の1は同じデータとは限りません。コードの先頭ゼロが意味を持つ業務では、入力形式を統一することが重要です。

次に#REF!が表示されたら、参照範囲の列数とVLOOKUPの列番号を見直します。今回の実験では2列の範囲に3列目を要求したことが原因です。参照先の列を削除した場合にも参照エラーが起き得ます。式を丸ごとIFERRORで覆う前に、内側のVLOOKUPだけを一時的に別セルで確認すると原因が分かりやすくなります。

VALUE!や#NAME?など別種のエラーが出た場合は、検索値の有無ではなく、式の引数や関数名、入力の形式を先に調べます。IFNAはこれらを隠さないので、故障の種類がそのまま手掛かりになります。逆にIFERRORは多くのエラーを同じ文字列へ変えるため、調査用の列には向かないことがあります。

検索表の範囲を固定したまま行を増やすと、新しい行が検索対象から外れる場合があります。テーブル機能などで範囲を管理する選択肢もありますが、まずは現在の検索範囲に目的の行が含まれるかを確認してください。式のエラーを表示することと、検索対象が正しいことは別の問題です。

業務での使い分け：利用者表示と診断を分ける

IFNAを選びやすいのは、検索対象が見つからない場合だけを「未登録」「要確認」へ変えたいときです。台帳の整合性を点検する途中では、参照ミスや式の不備を残す価値があります。特に、複数人が同じブックを更新する場合、数式の変更に気づけるようにしておくと、原因の調査が早くなります。

IFERRORにも適切な用途があります。たとえば複数の種類のエラーを同じ案内にまとめることが仕様として決まっており、内部の計算結果を別途監視できる画面です。ただし、エラーを全部「未登録」と呼ぶと意味が変わります。利用者向けの表示を統一する場合でも、内部の診断列や検証手順を残しておくと安心です。

実務では、検索対象の一覧、検索式、表示用の式を分けて考えましょう。まず生の検索式でどのエラーが起きるか確認し、次に業務上想定されるエラーだけを置き換えます。新しい商品コードや列の追加時には、正常なコード、存在しないコード、意図的に壊した参照という三種類で試すと、変更の影響が見えます。

今回の例で最も大切なのは「エラーが消えた＝問題が解決した」ではないということです。エラー表示は邪魔な文字ではなく、原因を伝える信号です。利用者が判断できる表示と、作成者が修理できる情報の両方を残すことが、長く使えるExcel帳票につながります。

公式資料

• Microsoft Support：IFERROR関数

• Microsoft Support：IFNA関数

公式仕様確認日：2026年11月7日。掲載式の実機実行は未実施です。