※購入先、ダウンロードへのリンクにはアフィリエイトタグが含まれており、それらの購入や会員の成約、ダウンロードなどからの収益化を行う場合があります。

IFS関数の使い方|複数条件をミスなく判定する書き方とTRUEの活用

IF関数で条件分岐を作っているうちに、いつの間にか式が長くなり、括弧だらけで「どこを直せばいいのか分からない」「ひとつ直したら別の結果が崩れた」と感じたことはないでしょうか。点数評価や料金区分、ステータス判定など、条件が3つ以上に増える場面では、IFの入れ子は読みづらくなり、修正のたびにミスが入りやすくなります。

そんなときに役立つのがIFS関数です。条件と結果をペアで並べて書けるため、判定ロジックが見通しやすく、追加・変更も比較的安全に行えます。ただし、IFSは「上から順に判定して最初に当たった結果で確定する」性質があるため、条件の並べ方や「それ以外」の作り方を押さえないと、誤判定や#N/Aエラーの原因にもなります。

本記事では、IFS関数の基本構文から、TRUEを使った「それ以外」の作り方、IFネストからの安全な置き換え手順、境界値や優先順位で誤判定を防ぐ条件設計のコツまで、例を交えながら丁寧に解説いたします。読み終えるころには、複数条件の判定式を「分かりやすく、壊れにくく」整え、自分の業務シートに自信を持って適用できるようになります。

※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。

IFS関数でできることとIF関数との違い

Excelで条件分岐を作るとき、多くの方が最初に使うのがIF関数です。ところが、実務で扱う表は「条件が2つ」では終わりません。評価区分、料金区分、在庫判定、締め日ルールなど、条件が増えるほどIFの入れ子(ネスト)が深くなり、式が読みにくく、修正しづらくなります。
IFS関数は、複数条件を「上から順に判定して、最初に当てはまった結果を返す」ため、長いIFネストを読みやすく整理しやすいのが特長です。式の見通しが良くなるだけでなく、あとから条件を追加・修正する際の事故(括弧の崩れ、条件の入れ替え漏れ)も減らしやすくなります。

IFS関数が向いているケース

IFS関数が真価を発揮するのは、次のような「段階的な判定」「上から優先順位で選ぶ判定」です。

  • 段階評価(点数・成績・査定)
    例:90以上はA、80以上はB、60以上はC、それ以外はD

  • 料金区分・送料区分(購入額・重量・距離などで段階がある)
    例:1万円以上は送料無料、5千円以上は500円、それ以外は800円

  • ステータス判定(複数の状態を優先順位で決める)
    例:キャンセルなら「取消」、未入金なら「未払い」、出荷済みなら「発送済」、それ以外は「処理中」

  • 数値の範囲で分類する業務
    年齢区分、勤続年数区分、在庫日数区分など

逆に、次のような場合はIF関数のままでも十分なことがあります。

  • 条件が2つ程度で、今後も増えにくい

  • 1つの条件だけを見て「真/偽」で返すだけ

  • 既存のテンプレがIFで統一され、変更が難しい(運用都合)

重要なのは「IFSが常に正解」ではない点です。条件が増える見込みがある、読みやすさ・保守性を上げたい、という局面でIFSを選ぶと効果が出やすいです。

IFネストとの違いと読みやすさの考え方

IFネストは「偽だったら次のIFへ」という構造です。例えば以下のように、深くなるほど括弧が増えます。

  • IFネストの例
    =IF(A2>=90,"A",IF(A2>=80,"B",IF(A2>=60,"C","D")))

IFSは「条件, 結果」をペアで並べる構造です。

  • IFSの例
    =IFS(A2>=90,"A",A2>=80,"B",A2>=60,"C",TRUE,"D")

読みやすさの観点で見ると、IFSは「どの条件で何を返すか」が横並びに見えます。IFネストは内側に入っていくため、どこがどの条件の結果なのか追いづらいことが多いです。
ただし、IFSには大きな注意点があります。条件は上から順に判定され、最初にTRUEになった時点で確定するため、条件の並べ方=優先順位になります。これを理解せずに条件を追加すると、「思っていた結果と違う」誤判定が起きやすくなります。以降の章で、誤判定を防ぐ設計のコツも含めて詳しく解説します。


IFS関数の書き方と引数の意味

IFS関数を使いこなすうえで、まず押さえるべきは「構文」と「評価順」です。ここを曖昧にしたまま例題だけで覚えると、少し複雑な表に当てはめたときに事故が起きます。

基本構文と評価順

IFS関数の基本形は次の通りです。

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

ポイントは「条件」と「結果」が必ずセットで並ぶことです。
そして評価は次の順で進みます。

  1. 条件1を判定する

  2. 条件1がTRUEなら結果1を返して終了

  3. 条件1がFALSEなら条件2を判定する

  4. 条件2がTRUEなら結果2を返して終了

  5. 以後、同様に「上から順に」判定する

このため、上に書いた条件ほど優先されます
次の例で感覚を掴みます。

  • 例:点数で評価を返す(A2が点数)

    • =IFS(A2>=90,"A",A2>=80,"B",A2>=60,"C",TRUE,"D")

この式は、「90以上ならA」「80以上ならB」「60以上ならC」「それ以外はD」という順番の優先順位が、そのまま式の並びに表れています。

また、IFSは条件が増えても「条件, 結果」を追加するだけです。IFネストのように括弧の閉じ忘れに悩まされにくいのも実務では大きな利点です。

条件は上から順に判定される注意点

IFSで最も多いミスは「条件の順序が逆」になってしまうことです。
例えば、点数評価を次のように書いてしまうとどうなるでしょうか。

  • 間違い例
    =IFS(A2>=60,"C",A2>=80,"B",A2>=90,"A",TRUE,"D")

この式は「60以上ならC」で最初に確定してしまうため、90点も80点も全部Cになります。後ろに90以上があっても、そこに到達しません。
つまり、IFSでは次の考え方が必須です。

  • 範囲が狭い条件(厳しい条件)を上に置く

  • 範囲が広い条件(ゆるい条件)を下に置く

点数評価なら「90以上→80以上→60以上」のように、高い順に並べるのが基本です。
料金区分なら「1万円以上→5千円以上→それ以外」のように、高額条件から並べるのが基本です。

さらに、条件の境界(以上/超過、未満/以下)が混ざると、思わぬ抜けや重なりが起きます。境界の話は後半の「誤判定を防ぐ条件設計のコツ」で詳しく扱いますが、まずは「上から順に決まる」性質を強く意識してください。


IFS関数でそれ以外を作る方法と#N/A回避

IFS関数でつまずきやすいのが、「どの条件にも当てはまらない場合」をどう扱うかです。IF関数には最後に「偽の場合」を書けますが、IFSにはそれがありません。
そのため、受け皿を用意しないと、条件が全部FALSEになったときにエラー(#N/A)になることがあります。

最後にTRUEを置く理由

「それ以外」を作る定番は、最後にTRUEを置く方法です。TRUEは常に真なので、そこまで到達した時点で「他の条件が全部外れた」という意味になります。

  • 例:点数評価(それ以外=D)

    • =IFS(A2>=90,"A",A2>=80,"B",A2>=60,"C",TRUE,"D")

この書き方の利点は次の通りです。

  • 「それ以外」が明確になり、#N/Aを避けやすい

  • 条件漏れがあっても、とりあえず何かしらの結果が返る(運用上の事故を減らす)

  • 後から条件を追加するときも、TRUEの前にペアを差し込めばよい

注意点として、TRUEの受け皿があると「本当は例外として扱うべき値」まで飲み込まれることがあります。
例えば「空白は空白のまま返したい」「エラーはエラーとして通知したい」という運用なら、TRUEに入れる値を工夫するか、空白判定・エラー判定を上位に入れる必要があります。

#N/Aが出る典型パターン

IFSで#N/Aが出るのは、基本的に「どれにも当てはまらない」からです。典型パターンは次の通りです。

  1. TRUEの受け皿を入れていない
    条件が外れたときの行き先がないため、#N/Aになります。

  2. 空白セルが混ざっている
    例:空白はどの条件にも当てはまらない → TRUEがないと#N/A
    TRUEがあっても「空白がDになってしまう」など運用上の違和感が出ます。

  3. 文字列と数値が混在している
    数値比較のつもりが文字列扱いになっており、条件が全部FALSEになるケースがあります。

  4. 境界値の書き方に漏れがある
    例:「80以上」「60以上」のはずが「>80」「>60」になっていて、ちょうど80・60がどれにも当たらないなど。

IFSは「条件が当たらないと結果が出ない」関数です。まずは「必ず当てはまる最後の受け皿」を用意するか、当てはまらないケースを上位条件として設計してください。

それ以外を入れる前の確認チェックリスト

以下のチェックリストを、IFSを作るときの最終確認にしてください。1つでも抜けると、運用開始後にトラブルになりやすいです。

  • 最後に TRUE, "それ以外の結果" を入れている(または当てはまらないケースが存在しない設計にしている)

  • 空白セルがあり得る場合、空白の扱いを決めている(空白なら空白、空白なら未入力など)

  • 条件の境界(以上/未満、超過/以下)を揃えている

  • 条件の並びが優先順位になっている(広い条件が上に来ていない)

  • 比較対象の型が揃っている(数値は数値、文字列は文字列)

  • 例外値(欠席、取消、対象外など)を上位条件で先に処理している


IFネストからIFS関数へ安全に置き換える手順

既存ファイルでIFネストがすでに使われている場合、「読みやすくしたいからIFSに置き換える」というニーズは多いです。ただし、置換は慎重に進めないと、結果が変わってしまう事故が起きます。
安全に置き換えるためには、「棚卸し → 置換 → 比較テスト」の流れが最も確実です。

置換前にやるべき棚卸し

置換の前に、元のIFネストが何を意図しているのかを明確にします。特に次の点を言語化してください。

  • 優先順位:どの条件が最優先か(例:取消が最優先、次に未入金、次に出荷済など)

  • 境界値:>= と >、<= と < が混ざっていないか

  • 例外処理:空白、エラー、対象外の扱いはどうなっているか

  • 結果の種類:返す値が文字列か数値か(後工程で集計・ピボットに影響します)

  • 条件の重なり:同じ行が複数条件に当てはまり得るか(その場合、どれを優先するか)

棚卸しが曖昧だと、IFSに移したときに「どれを上に置くべきか」が決まらず、誤判定を作り込みやすくなります。まずは現状のルールを可視化してください。

置換ステップ(同一結果の比較テスト)

置換は、次の手順で進めるのが安全です。ポイントは「元の列を消さずに比較する」ことです。

  1. 元のIFネストの結果列を残す
    既存の列はそのままにし、隣に検証用の列を作ります。

  2. 検証用の列にIFS式を作る
    条件は「優先順位が高いものから順に」並べます。最後にTRUEの受け皿も用意します。

  3. 比較用の列を作る(一致・不一致を判定)
    例えば =IF(旧結果=新結果,"OK","NG") のようにし、NGだけ抽出できる状態にします。

  4. NG行だけをフィルタして原因を特定する
    多くの場合、原因は「境界値」「条件順」「空白」「例外値」です。差分行の入力値を確認します。

  5. 修正して再テストする
    1回で終わらないこともあります。差分が0になるまで調整し、置換の正当性を担保します。

  6. 本番置換(列差し替え)
    差分が0になり、運用上の例外(空白時など)も意図通りになったら、列を差し替えます。

この比較テストを省略して置換すると、「たまたま手元の数行では合っていたが、月末のデータで崩れた」という事故が起きがちです。置換は“式を書く作業”というより、“ロジックを移植する作業”だと捉えると失敗しにくくなります。

IFネスト例とIFS置換例の見比べ

実際に見比べると、IFSのメリットが分かりやすいです。

目的IFネストの例IFSの例
点数でA/B/C/Dを返す=IF(A2>=90,"A",IF(A2>=80,"B",IF(A2>=60,"C","D")))=IFS(A2>=90,"A",A2>=80,"B",A2>=60,"C",TRUE,"D")

IFSは括弧がなく、条件と結果が並ぶため、修正点が見つけやすいのが強みです。
例えば「70以上ならC+」を追加するなら、IFSは A2>=70,"C+", をTRUEの前に差し込むだけで済みます。IFネストの場合、どこの入れ子に差し込むかを間違えると式が壊れやすく、修正後に読み直すコストも増えます。


誤判定を防ぐ条件設計のコツ

IFS関数のトラブルの多くは「関数の使い方」ではなく、「条件設計」に原因があります。
とくに、次の3点を押さえると誤判定が激減します。

  • 境界値の揃え方

  • 重複条件と優先順位

  • 条件が多いときの参照表化

境界値の揃え方

境界値とは「どこからどこまでをその区分にするか」という境目のことです。
例えば点数評価なら、80点ちょうどをBにするのかCにするのか、という話です。

おすすめは、上から「以上」で揃える方法です。
例:90以上、80以上、60以上、TRUE

  • =IFS(A2>=90,"A",A2>=80,"B",A2>=60,"C",TRUE,"D")

この書き方だと、境界値は自動的に上位から吸収されます。80点は「90以上」ではないので次へ進み、「80以上」でBになります。60点も同様にCになります。
一方で、以下のように「超過(>)」を混ぜると穴ができます。

  • 悪い例(60ちょうど、80ちょうどが抜ける可能性)
    =IFS(A2>90,"A",A2>80,"B",A2>60,"C",TRUE,"D")

この場合、80点は「>80」を満たさず、60点も「>60」を満たさないため、意図と異なる分類になります。境界値は、ルールとして揃えるのが安全です。

さらに厳密に範囲を定義したい場合は、ANDを使って「80以上かつ90未満」のように書く方法もあります。ただし、式が長くなりやすいので、まずは「以上で上から並べる」が簡潔で安定しやすいです。

重複条件と優先順位

実務データでは、同じ行が複数条件に当てはまることがよくあります。例えば、次のようなケースです。

  • 「欠席」なら評価しない

  • ただし点数は入力されている(過去データの整合性が崩れている)

  • その場合でも欠席を優先したい

このとき、欠席判定を上に置かないと、点数条件が先に当たって評価が返ってしまいます。
優先したい条件ほど上に置くのがIFSの鉄則です。

  • 例:欠席を最優先にする
    =IFS(B2="欠席","",A2>=90,"A",A2>=80,"B",A2>=60,"C",TRUE,"D")

また、状態判定でも同様です。
「取消」「未入金」「出荷済」のように優先順位があるなら、取消→未入金→出荷済…の順に書きます。
逆に、優先順位が曖昧なまま条件を追加すると、後から「なぜこの行は発送済なのに未払い表示なのか」といった混乱につながります。条件を追加するときは、必ず“優先順位のルール”もセットで決めてください。

条件が多いときは参照表化も検討(XLOOKUP等)

条件が多くなるほど、IFS式は長くなります。読める範囲なら問題ありませんが、次のようなケースではIFSより参照表(マスタ)化のほうが運用が安定します。

  • 区分が頻繁に変わる(料金改定、送料改定、評価基準改定など)

  • 担当者が複数で、式修正の属人化を避けたい

  • 監査やレビューで「区分の根拠」を表として提示したい

  • 区分が多すぎて、IFSが見通せなくなってきた

例えば「コード→名称」のように完全一致なら、参照表+XLOOKUPで表引きにするほうが明快です。
範囲判定でも、区切りの表(下限・上限・結果)を作り、表側を更新する運用に変えると、式の修正が不要になります。

誤判定防止チェックリスト

IFSを作った/直した/条件を追加したときは、次のチェックリストで事故を防げます。

  • 条件は上から順に「優先順位が高いもの」を並べた

  • 広い条件(例:60以上)が上に来ていない

  • 境界値(>= と >、<= と <)を揃えた

  • 重複し得る条件がある場合、どれを優先するか決めて上に置いた

  • 最後にTRUEの受け皿がある(または漏れがない設計)

  • 空白・エラー・対象外などの例外値の扱いを明確にした

  • 置換や修正の後は、差分比較でテストした(特に境界値の行を重点確認)


IFS関数とSWITCH関数・参照表の使い分け

IFSは便利ですが、目的によってはSWITCHや参照表のほうが読みやすく、保守しやすい場合があります。ここでは「どれを選べばよいか」を判断しやすく整理します。

SWITCHが向くケース(完全一致)

SWITCHは、ある値が「Aならこれ」「Bならこれ」という完全一致の分岐が得意です。
例えば、次のようなケースです。

  • 支店コードが「TKY」なら「東京」「OSK」なら「大阪」…

  • 等級が「S」「A」「B」「C」…と決まっている

  • 入力値が固定の選択肢になっている(ドロップダウンなど)

この場合、IFSで A2="TKY" を何度も書くより、SWITCHのほうがすっきりします。
また、完全一致は参照表化とも相性が良いので、「変更頻度が高い」なら参照表、「変更頻度が低く式内で完結させたい」ならSWITCH、といった選び方もできます。

IFSが向くケース(大小比較・範囲)

IFSが最も力を発揮するのは、数値の大小や範囲で区分けするときです。

  • 点数が一定以上か

  • 金額が一定以上か

  • 日数が一定以上か

  • 期限まであと何日かで段階を変えるか

このような「>=」や「<」を使う判定は、IFSが自然で読みやすくなります。
条件を高い順に並べる、最後にTRUEを置く、という基本を守れば、実務で多くの段階判定を安定して運用できます。

マスタ表運用が向くケース(変更頻度が高い)

最後に、参照表(マスタ)運用が向くケースを明確にしておきます。次の条件に当てはまるほど、IFSより表運用の価値が上がります。

  • 区分や閾値が頻繁に更新される
    例:送料ルールがキャンペーンで変わる、評価基準が毎期見直される

  • 担当者が変わりやすい/複数人で管理する
    式より表のほうが引き継ぎしやすい

  • 根拠を説明する必要がある
    監査、稟議、部門間共有などで「この区分はこの表に基づく」と示しやすい

  • 条件が多すぎて式が長文化している
    読むだけで時間がかかり、修正時に事故が起きやすい

参照表化は「関数を覚える」より一段上の改善策です。IFSを使っていて式が肥大化してきたら、「そもそも表に出して管理したほうが良いか」を一度検討すると、長期的な保守コストが下がります。


よくある質問

IFS関数はどのExcelで使えますか

IFS関数は、Excelのバージョンによって利用可否が異なります。社内のPCが古いExcelの場合、IFSが使えず、互換性のためにIFネストのままにする必要が出ることがあります。
実務では「自分の環境で動く」だけでなく、「共有先・配布先で動く」ことが重要です。ファイルを共有する相手のExcelバージョンが古い可能性があるなら、配布前に必ず動作確認をしてください。
また、同じ社内でも部署ごとにバージョンが異なることがあるため、運用ルールとして「使用可能関数の範囲」を決めておくとトラブルが減ります。

条件の途中を変えたら結果が変になりました

IFSは上から順に判定し、最初に当たった条件で確定します。途中に条件を追加したり、条件の内容を少し変えたりすると、次のような現象が起きます。

  • 以前は下位条件に到達していた行が、上位条件に先に当たる

  • 境界値の条件を変えたことで、想定外の区分に吸収される

  • 例外(空白、取消など)を後から追加したが、上に置いていないため効かない

対策としては、次の2つが効果的です。

  1. 優先順位を再設計し、条件の並びを見直す

  2. 旧結果と新結果を並べて差分比較をする

特に差分比較は、原因行が特定できるため、修正が速くなります。条件を触ったら必ず「境界値(60・80・90のような境目)」の行を重点的に確認してください。

ANDやORはIFSと一緒に使えますか

使えます。IFSの「条件」部分にAND/ORを入れれば、複合条件を作れます。

  • 例:点数80以上かつ出席なら合格、それ以外は不合格
    =IFS(AND(A2>=80,B2="出席"),"合格",TRUE,"不合格")

  • 例:部署が営業または企画なら対象、それ以外は対象外
    =IFS(OR(C2="営業",C2="企画"),"対象",TRUE,"対象外")

複合条件は便利ですが、条件が複雑化しやすいのが難点です。
複雑になってきたら、条件の一部を別セルに切り出して(例:=AND(...) を別列に作る)、IFSはその結果を参照する形にすると読みやすくなります。

空白やエラーを除外したいときはどうしますか

空白やエラーが混ざる列は、先に処理しておくと安定します。典型は次の2パターンです。

パターン1:空白なら空白を返す(未入力は表示しない)

  • =IFS(A2="","",A2>=90,"A",A2>=80,"B",A2>=60,"C",TRUE,"D")

パターン2:空白なら「未入力」と明示する(入力漏れ検知)

  • =IFS(A2="","未入力",A2>=90,"A",A2>=80,"B",A2>=60,"C",TRUE,"D")

エラーが混ざる可能性がある場合は、IFERRORで包む方法もありますが、まずは「なぜエラーが混ざるのか」を確認するのが先です。
入力側の整備(数値列に文字が入らないようにする、入力規則を設定する)とセットで考えると、判定式のトラブルが減ります。


まとめ

IFS関数は、複数条件の判定を読みやすく整理でき、IFネストの長文化による保守トラブルを減らしやすい関数です。使い方の要点は次の通りです。

  • 条件は上から順に評価され、最初に当たった結果で確定する

  • 「それ以外」を作るなら、最後に TRUE の受け皿を置くと安定しやすい

  • 誤判定を防ぐには、条件順・境界値・重複条件の優先順位を設計する

  • IFネストから置換するときは、元の結果と並べて差分比較し、境界値や例外値を重点確認する

  • 完全一致ならSWITCH、変更頻度が高いなら参照表化など、用途に応じた使い分けも有効

次の一歩としては、いま使っているIFネストの式を1本選び、隣にIFS版を作って差分比較してみてください。差分が出た行には必ず理由があり、そこを潰すほど「壊れない判定式」に近づきます。条件を追加・変更した際も、必ず境界値の行を確認し、結果が意図通りかをテストしてから運用に反映すると安心です。