ExcelのIFS関数で「それ以外」を返す方法（TRUEで締める理由と実務テンプレ）

はじめに

この記事では、ExcelのIFS関数で「それ以外」を安全に返す書き方を、理由と実務テンプレまで含めて整理します。

IFSは便利ですが、最後の条件を入れ忘れると想定外のデータで結果が崩れやすいです。

条件分岐の式は小さなミスが結果の誤判定につながるので、考え方から順に押さえます。

本記事は「どう書くか」だけでなく、「なぜその書き方が安全か」もセットで扱います。

この記事で解決できること

IFS関数で最後の条件に何を書けばよいかが分かります。

「それ以外」を入れないと何が起きるかが分かります。

TRUEを置く位置と、デフォルト値を決めるコツが分かります。

条件の順番をどう決めれば誤判定を防げるかが分かります。

空白や文字列などの想定外データで崩れない作り方が分かります。

境界値の扱いを間違えないためのチェック方法が分かります。

テスト用の代表値を用意して結果確認する手順が分かります。

IFとIFSとSWITCHの使い分けの目安が分かります。

数式が長くなり過ぎたときに別設計へ逃がす判断が分かります。

想定する読者と前提

Excelの基本操作と数式入力ができる人を想定します。

IFS関数を一度は使ったが、最後の条件で迷った経験がある人を想定します。

複数条件の判定や、分類ラベル付けの作業をしている人を想定します。

同じ分類を繰り返し使うために、式を壊れにくく保ちたい人を想定します。

結論：IFSの最後はTRUEで「それ以外」を受け止める

IFSの最後にTRUEを置くと、どの条件にも当てはまらないデータをまとめて拾えます。

IFSは上から順に条件を見て、最初にTRUEになった結果を返す関数です。

そのため最後にTRUEを置けば、そこまでで拾えなかったものが必ずTRUEに当たります。

「それ以外」が必要なときは、最後をTRUEにしてデフォルト値を返すのが最も分かりやすい型です。

この型を先に固定すると、条件追加や仕様変更が来ても崩れにくくなります。

最後にTRUEを置く基本形

基本形は、最後の条件にTRUEを入れて、最後の結果に「それ以外」の戻り値を書きます。

戻り値は、分類名だけでなく、確認用の合図や後工程に渡すコードでも構いません。

例として、A2の点数でランクを返す形は次のようになります。

=IFS(A2>=80,”A”,A2>=60,”B”,A2>=40,”C”,TRUE,”D”)

この式は、A2が80以上ならAを返し、60以上ならBを返し、40以上ならCを返し、それ以外はDを返します。

境界値を含めるかどうかは、>=と>の選び方で決まります。

1行でわかるコピペテンプレ

とにかく「それ以外」を入れたいだけなら、最後をTRUEにして戻り値を決めるだけで十分です。

=IFS(条件1,結果1,条件2,結果2,TRUE,それ以外の結果)

「それ以外の結果」には、文字列だけでなく数値や空文字も入れられます。

デフォルトを空文字にするかどうかは、後から検出したいかどうかで決めます。

IFS関数の基本（最低限だけ）

IFSは複数のIFを1つの式にまとめて、読みやすくしたいときに使います。

IFの入れ子を減らすことで、括弧の数え間違いも起きにくくなります。

ただし読みやすさは、条件の並べ方と命名の工夫で決まります。

条件の意味が曖昧なままだと、IFSにしても結局読めない式になります。

IFSの構文と判定の流れ

IFSの構文は、条件と結果の組を並べる形です。

IFS(条件1,結果1,条件2,結果2,条件3,結果3,…)

条件は必ずTRUEかFALSEになる式にします。

IFSは上から順に条件を評価して、最初にTRUEになった結果を返します。

上の条件で拾ったものは、下の条件に到達しません。

この挙動を前提に、上ほど優先度が高い並びにします。

条件を足すときは、既存条件との重なりを必ず確認します。

重なりがあるなら、意図した優先順位になっているかをテストで確かめます。

IF関数との違い（複数条件の見え方）

IFは入れ子にすると、括弧が増えて読みづらくなりがちです。

IFSは条件と結果が交互に並ぶので、条件の並びを目で追いやすいです。

ただしIFSも条件数が増えると長くなるので、保守性を意識した整理が必要です。

同じ条件を何度も書くなら、先に補助列で判定フラグを作る方法もあります。

式が長くなったら、列を分けて中間判定を作る方法もあります。

中間判定を作ると、どの条件でつまずいているかを追いやすくなります。

いつIFSより別関数が向くか（概要）

値が完全一致の分岐が中心ならSWITCHの方が短くなることがあります。

分岐ラベルが固定で、追加や削除が少ない場合は特に向きます。

複雑な条件で分岐するならIFSが向きます。

範囲条件やAND条件が混ざる場合は、IFSの方が自然に表現できます。

条件分岐そのものを避けられるなら、参照表を作ってXLOOKUPなどで引く方が保守しやすい場合があります。

参照表にすると、分類ルールを数式ではなく表として管理できます。

同じ分類を複数シートで使うなら、参照表方式の方が一括修正が楽です。

分類ルールが頻繁に変わる現場ほど、参照表方式のメリットが大きいです。

手順：IFSで「それ以外」を設定する（失敗しない型）

IFSの式を安定させるコツは、条件の並び方と例外データの扱いを先に決めることです。

この2点が曖昧だと、式が動いていても結果の意味がぶれます。

式を先に書き始めるより、判定ルールを文章で整理してから組む方が速いことが多いです。

特に境界値と例外値の扱いは、先に決めておくほど修正が少なくなります。

ステップ1：条件を上から並べるルールを決める

IFSは最初にTRUEになった条件が勝つので、上に置くほど優先度が高い設計になります。

この性質は便利ですが、並べ方を間違えると結果が静かに誤ります。

重なり得る条件を下に置くと、意図せず上の条件で拾われてしまいます。

範囲条件は、広い条件を下に、狭い条件を上に置くのが基本です。

例えば「80以上」「60以上」「40以上」のように上から大きい順に並べると、判定が自然になります。

境界値がどの区分に入るかは、>=と>のどちらを選ぶかで変わります。

迷ったら、極端な値を入れて結果が想定どおりかを確認します。

境界の近くにある代表値も入れて、意図したランクに入るかを確かめます。

ステップ2：最後にTRUEを置いてデフォルトを返す

最後にTRUEを置くと、条件漏れや想定外データをまとめて処理できます。

これは「最後に必ず当たる受け皿」を作る設計だと考えると分かりやすいです。

デフォルトは「不明」「要確認」「その他」など、業務上安全な値にします。

デフォルトが空文字でもよいケースはありますが、後工程で見落としやすい点に注意します。

後で必ずチェックする運用なら、空文字より要確認の方が見つけやすいです。

確認が必要なデータを確実に拾うなら、デフォルトを目立つ文字列にするのも手です。

ステップ3：想定外データに備えた戻り値を決める

空白や文字列が入る可能性がある列は、先に「入力のゆれ」をどう扱うかを決めます。

入力のゆれを放置すると、式の正しさ以前にデータ品質で結果が壊れます。

数値として扱えない値が来るなら、デフォルトで「要確認」を返して後でフィルタする方が事故が減ります。

0が意味を持つ列なら、空白と0が混ざっても判定できるように条件を分けます。

エラー値が来る可能性があるなら、IFERRORで包むか、エラーを出す前段の式を見直します。

エラーを隠すのではなく、要確認に落として検出しやすくする設計も選べます。

作業者が複数いる場合は、デフォルトの意味をチーム内で共有します。

共有しておくと、後から「要確認」の行をどう処理するかが揃います。

実務テンプレ3選（そのまま使える例）

ここでは、よくある分類作業を「IFS＋TRUE」で安全に締める例をまとめます。

例はそのまま使えるようにしていますが、境界値とデフォルトの意味は必ず自分の業務に合わせます。

例1：評価ランク（A/B/C/それ以外）

点数が入るセルA2を基準に、AからCを返し、それ以外をDにする例です。

=IFS(A2>=80,”A”,A2>=60,”B”,A2>=40,”C”,TRUE,”D”)

境界値が含まれるかどうかは、>=と>のどちらを使うかで決まります。

境界値の扱いを仕様として決めてから式に落とします。

点数が未入力の可能性があるなら、最後を「要確認」にするのも手です。

例2：売上区分（閾値で判定してそれ以外を返す）

売上が入るセルB2を基準に、区分名を返す例です。

=IFS(B2>=1000000,”大口”,B2>=300000,”中口”,B2>=1,”小口”,TRUE,”未入力/要確認”)

0や空白が混ざる列なら、最後のデフォルトで「未入力/要確認」を返すと確認が楽になります。

0が意味を持つ列なら、0専用の条件を入れて扱いを分けます。

例3：日付区分（四半期・上期下期などの分類）

月が入るセルC2から、上期と下期を返す例です。

=IFS(C2>=4,C2<=9,”上期”,C2>=10,C2<=3,”下期”,TRUE,”要確認”)

このままだと条件の書き方が不正なので、範囲条件はANDを使うか、比較を分けて設計します。

正しい例は次のように、ANDを使って範囲を1つの条件にします。

=IFS(AND(C2>=4,C2<=9),”上期”,AND(C2>=10,C2<=12),”下期”,AND(C2>=1,C2<=3),”下期”,TRUE,”要確認”)

日付から月を取り出す場合は、MONTH関数で月番号を作ってから判定すると見通しが良くなります。

四半期を作りたい場合は、月番号から四半期番号を計算してからラベル化すると楽です。

よくあるミスと対処（薄さを潰すチェックポイント）

IFSがうまく動かない原因は、条件の重なりと、データのゆれに集中します。

ミスを先に知っておくと、式のテストにかける時間が減ります。

ミス1：条件の順番が逆で想定外が発生する

広い条件を上に置くと、下の条件が永遠に当たりません。

例えば「60以上」を上に置いて「80以上」を下に置くと、80以上がすべて60以上で拾われます。

必ず優先順位が高い条件を上に置きます。

条件を追加したときは、既存条件の上か下かを意識して入れ替えも検討します。

ミス2：空白・文字列・エラー値で意図しない結果になる

空白が0として扱われるかどうかは、式の形やセルの状態で揺れることがあります。

文字列の数値が混ざる列は、VALUEで数値化するか、デフォルトで要確認に落とします。

エラー値が混ざる可能性があるなら、IFERRORで包んで全体を止めない設計にします。

エラーを隠すのではなく、要確認へ落とす設計も選択肢になります。

ミス3：最後にデフォルトを入れずに取りこぼす

IFSはどの条件もTRUEにならないと、エラー相当の状態になります。

この取りこぼしがあると、後工程の集計やフィルタが崩れます。

最後にTRUEを置いて、必ず何かを返す形にします。

取りこぼしを検出するために、デフォルトを目立つ値にする運用も有効です。

IF / IFS / SWITCH の使い分け（比較で理解を固定する）

関数は正解が1つではないので、選ぶ基準を決めると迷いが減ります。

同じ結果が出る式でも、読みやすさと保守のしやすさで選ぶと事故が減ります。

使い分け早見表（判断軸：可読性・条件数・保守性）

次の表は、よくある分岐パターンでの向き不向きをまとめたものです。

範囲条件か完全一致かを意識すると、選択がぶれにくくなります。

表のとおり、範囲条件が多いならIFSが基本になります。

範囲条件をSWITCHで無理に書くと、可読性が落ちやすいです。

SWITCHが強いケースと弱いケース

値が「東京」「大阪」「名古屋」のように完全一致で分岐するならSWITCHが合います。

コードや種別のように、固定のラベルを返したいときは特に便利です。

「以上」「未満」や複数条件の組み合わせが必要ならIFSの方が自然です。

複数条件が必要な場合は、先に補助列で分類キーを作ってSWITCHへ渡す方法もあります。

IFSを選ぶべき条件数の目安

条件が3つ以上になってIFの入れ子が読みにくいと感じたら、IFSに切り替えるのが目安です。

条件数が増えたときに、どこを直せばよいかが見えやすくなります。

ただし条件が増え続けるなら、参照表にして引く設計も検討します。

参照表方式は、仕様変更が多い分類作業で特に効果があります。

チェックリスト：公開前に確認するポイント

最後に、IFSの式を壊れにくくするための確認項目を並べます。

実際のデータで数件テストして、意図した結果になるかも確認します。

条件が重複していないか

上の条件で拾われる範囲が、下の条件の範囲と重なっていないかを確認します。

特に「以上」「未満」を混ぜたときは、境界値がどちらに入るかを明確にします。

重なる場合は、優先順位が仕様どおりになっているかを確認します。

優先順位が曖昧なら、先に業務ルールとして文章で決めてから式に反映します。

例外値（空白・0・文字列・エラー）を想定できているか

入力列に空白や文字列が入り得るかを確認します。

0が意味を持つ列なら、空白と0を同じ扱いにしないようにします。

入り得るなら、デフォルトで要確認を返すか、前処理で整形するかを決めます。

入力のゆれが頻繁に起きるなら、別列で整形してからIFSに渡す方が管理しやすいです。

「それ以外」の戻り値が業務上安全か

デフォルトを空文字にすると、未処理が見えなくなることがあります。

後工程で検出できる値を返す方が、運用上安全なことが多いです。

「要確認」のような値にしておくと、フィルタや条件付き書式で見つけやすくなります。

デフォルトを決めるときは、最終的に誰がどこで確認するかまで想像して決めます。

FAQ

よくある疑問を短く整理します。

業務でつまずきやすいポイントだけに絞って補足します。

迷ったときは、式の目的を「分類」なのか「判定」なのかで言語化すると整理しやすいです。

IFSの最後にTRUEを書くのはなぜ？

最後にTRUEを置くと、それまでの条件に当てはまらない値を必ず拾えるからです。

IFSは上から順に評価して最初に当たった結果だけを返すので、最後のTRUEはデフォルトの受け皿になります。

「それ以外」を設けないと、条件漏れのデータが混ざった瞬間に想定外の結果になりやすいです。

「それ以外」で空文字を返してもいい？

空文字は見た目がきれいですが、未処理が埋もれるリスクがあるので、用途が明確なときだけにします。

後工程で集計やフィルタをするなら、空文字より「要確認」のような検出しやすい値の方が安全です。

見た目を空にしたい場合は、表示形式や別列での表示制御で対応する選択肢もあります。

IFSで範囲条件（以上・未満）を組むときの注意は？

範囲はANDでまとめて1つの条件にするか、条件の順番が崩れない形に設計します。

範囲が重なると上の条件が勝つので、境界値がどちらに入るかを先に決めてから式に落とします。

月や点数のように連続値を扱うときは、テスト用の入力例をいくつか作って確認すると安心です。

まとめ

IFSの「それ以外」は、最後をTRUEにしてデフォルトを返す型にすると安定します。

最後にTRUEを置く設計は、条件漏れを防ぐための保険として機能します。

条件の順番は仕様そのものなので、重なりを意識して上から設計します。

優先順位を明確にしたうえで並べることで、後から見直したときも意図が読み取りやすくなります。

想定外データは必ず出る前提で、要確認に落とせるデフォルトを用意します。

デフォルト値は単なる埋め草ではなく、運用を支える重要な設計要素です。

IFとIFSとSWITCHは、範囲条件か完全一致かで選ぶと迷いが減ります。

関数選択の基準を自分なりに持っておくと、式が複雑になり過ぎるのを防げます。

次に読むと理解が深まる関連記事は、同じくExcel関数の具体例と注意点を扱う記事が向きます。

実際に手を動かしながら複数の例を試すことで、IFSの設計感覚が身につきます。