この記事で分かること
結論：SUMIFSは「複数条件で足す」関数。財務モデルでは期間集計の主役
SUMIFS関数は、複数の条件をすべて満たす行だけを合計する関数です。構文は次のとおりです。
=SUMIFS(合計範囲, 条件範囲1, 条件1, [条件範囲2, 条件2], …)
合計範囲が先頭に来ます。条件は最大127組まで指定でき、指定した条件はすべてAND（かつ）で結合されます。条件範囲と合計範囲は同じ行数・列数でなければなりません。
Excel一般の解説では「条件付き合計の便利関数」で終わりますが、IB・PE・FAS・FP&A・経営企画の現場でSUMIFSが本当に効くのは、次の3つの場面です。
- 月次データを四半期・年度に束ねる：月次で持っている売上・費用・CFを、決算期に合わせた四半期／通期に集計する。財務モデルの「Historicals」と「Forecast」をつなぐ土台になります。
- 部門別・勘定科目別の予実表を組む：試算表や仕訳明細のような縦持ちデータから、部門×勘定科目のマトリクスを一発で生成する。
- コホート集計・ディールリスト集計：顧客×月のMRR、年×業種のディール件数と金額のように、2軸以上の切り口で集計する。
いずれも共通するのは、元データは縦持ち（ロング形式）のまま触らず、集計側の表からSUMIFSで引くという設計です。元データを直接加工しないので、翌月データを追記するだけで表全体が更新されます。関数の全体像はハブ記事のExcel関数の早見辞典にまとめています。本記事はそのうちSUMIFSに絞り、財務実務での使い方だけを扱います。
構文と引数の順序：SUMIFとの違いを最初に潰しておく
SUMIFSでつまずく人の大半は、姉妹関数であるSUMIFと引数の順序が逆であることが原因です。
| 関数 | 構文 | 条件の数 | 実務での位置づけ |
|---|---|---|---|
| SUMIF | =SUMIF(条件範囲, 条件, [合計範囲]) | 1つのみ | 使わない。条件が1つでもSUMIFSで統一する |
| SUMIFS | =SUMIFS(合計範囲, 条件範囲1, 条件1, …) | 最大127組（AND） | 期間集計・予実・コホート集計の標準 |
| SUMPRODUCT | =SUMPRODUCT((条件式)*(条件式)*金額範囲) | 制限なし（AND/ORとも可） | OR条件・加重平均・計算列を作れない場面 |
実務上のルールとして、SUMIFは使わないと決めてしまうのが最も安全です。条件が1つのときにSUMIFで書き、後から「部門でも絞りたい」となった瞬間に引数を並べ替える必要が生じ、そこで事故が起きます。最初からSUMIFSで書いておけば、条件範囲と条件のペアを末尾に追加するだけで済みます。
もう一つ押さえておくべき性質は、SUMIFSの条件はすべてANDで結合されるという点です。「業種がソフトウェアまたはITサービス」のようなOR条件は、SUMIFS単体では書けません。この制約への対処は後述します。
実務例1：月次モデルを四半期・年度に束ねる
財務モデルで最も多いSUMIFSの用途が、月次の実績・計画を四半期や通期に集計する処理です（用語集：期間集計とSUMIFS）。以下は説明用の仮設例で、3月決算企業の月次売上高（単位：百万円）とします。
| A列：年月（日付） | C列：売上高 | D列：期間キー |
|---|---|---|
| 2025-04 | 120 | FY2025Q1 |
| 2025-05 | 128 | FY2025Q1 |
| 2025-06 | 135 | FY2025Q1 |
| 2025-07 | 141 | FY2025Q2 |
| 2025-08 | 132 | FY2025Q2 |
| 2025-09 | 150 | FY2025Q2 |
| 2025-10 | 155 | FY2025Q3 |
| 2025-11 | 162 | FY2025Q3 |
| 2025-12 | 178 | FY2025Q3 |
| 2026-01 | 145 | FY2025Q4 |
| 2026-02 | 149 | FY2025Q4 |
| 2026-03 | 171 | FY2025Q4 |
| 合計（12か月） | 1,766 |
方法A：不等号条件で日付範囲を指定する
期間キー列を作らずに集計する場合は、開始日と終了日を不等号で挟みます。ここが初学者の最大の関門です。
=SUMIFS($C$2:$C$13, $A$2:$A$13, “>=”&$F2, $A$2:$A$13, “<=”&$G2)
F2に期首日（2025/10/1）、G2に期末日（2025/12/31）を入れておき、比較演算子の文字列と日付を&で連結します。この式でFY2025Q3の495が返ります（155+162+178）。
ポイントは、比較演算子だけを引用符で囲み、日付は引用符の外でセル参照することです。">=$F2" と書くと「$F2という文字列以上」という無意味な条件になり、結果は0になります。逆に ">=2025/10/1" と直接書くのは、環境の日付書式設定に依存するうえ、期間を変えるたびに数式を書き換えることになるため避けます。日付は必ず DATE(2025,10,1) かセル参照で渡してください。
月末日を自動で求めるにはEOMONTH関数が便利です。=EOMONTH($F2,2) は開始日から2か月後の月末（2025/12/31）を返すため、四半期の終了日をハードコードせずに済みます。EOMONTH・EDATEの挙動は用語集のEOMONTH・EDATE関数を参照してください。
方法B：期間キー列を作って完全一致で集計する
四半期・年度・半期・LTMなど複数の粒度で何度も集計するモデルでは、元データ側に期間キー列を1本足すほうが圧倒的に読みやすく、速くなります。3月決算の場合、日付を3か月前倒しすればカレンダー年と会計年度が一致するため、次の式でキーを作れます。
="FY"&YEAR(EDATE(A2,-3))&"Q"&ROUNDUP(MONTH(EDATE(A2,-3))/3,0)
2025/4/1 → EDATE(-3)で2025/1/1 → YEAR=2025、MONTH=1、ROUNDUP(1/3)=1 → 「FY2025Q1」。2026/3/1 → 2025/12/1 → 「FY2025Q4」。決算期が3月以外の場合は、ずらす月数を変えるだけで対応できます。
あとは集計表側で完全一致を取ります。
=SUMIFS($C$2:$C$13, $D$2:$D$13, $F2)
F2に「FY2025Q3」と入っていれば495。通期は =SUMIFS($C$2:$C$13, $D$2:$D$13, "FY2025*") でも =SUMIFS($C$2:$C$13, $E$2:$E$13, "FY2025")（E列に年度キーを別途持つ）でも取れます。
| 期間 | 対象月 | 売上高（百万円） | 構成比 |
|---|---|---|---|
| FY2025Q1 | 2025年4〜6月 | 383 | 21.7% |
| FY2025Q2 | 2025年7〜9月 | 423 | 23.9% |
| FY2025Q3 | 2025年10〜12月 | 495 | 28.0% |
| FY2025Q4 | 2026年1〜3月 | 465 | 26.3% |
| FY2025通期 | 2025年4月〜2026年3月 | 1,766 | 100.0% |
ここで必ず入れるべきなのが、四半期の合計＝月次の合計を確認する検算セルです。=SUM(四半期4本)-SUM(月次12か月) がゼロでなければ、期間キーの取りこぼしか二重計上が起きています。この種のチェックの設計は検算チェックの設計で詳しく扱っています。
なお、四半期データから直近12か月（LTM）を組む場合も発想は同じで、対象期間の起点・終点をセルで持ち、不等号条件で切り出します。決算期の異なる企業を比較可能な期間に揃える作業はLTM・NTM・Calendarizationの実装と用語集の決算期とカレンダー年度の変換を参照してください。
実務例2：試算表・仕訳データから部門×勘定科目の予実表を作る
経営企画・FP&Aの月次業務で最も定型的なのが、会計システムから出した試算表や仕訳明細をもとに予実表を作る作業です。会計システムの出力は「年月・部門コード・勘定科目コード・勘定科目名・金額」という縦持ちであることがほとんどで、これはSUMIFSに理想的な形です。
=SUMIFS(実績金額列, 年月列, “>=”&$B$1, 年月列, “<=”&$C$1, 部門列, $A5, 勘定科目列, B$4)
$A5に部門名（行見出し）、B$4に勘定科目名（列見出し）を置き、複合参照で1つの数式を右方向・下方向にコピーするだけでマトリクスが埋まります。B1・C1に対象期間の開始日・終了日を置けば、期間の切替もセル1つで完了します。
| 部門 | 勘定科目 | 予算 | 実績 | 差異 |
|---|---|---|---|---|
| 営業部 | 人件費 | 40 | 42 | +2 |
| 営業部 | 外注費 | 10 | 8 | −2 |
| 営業部 | 広告宣伝費 | 20 | 25 | +5 |
| 開発部 | 人件費 | 55 | 58 | +3 |
| 開発部 | 外注費 | 18 | 22 | +4 |
| 管理部 | 人件費 | 20 | 19 | −1 |
| 管理部 | 外注費 | 4 | 3 | −1 |
| 管理部 | 広告宣伝費 | 2 | 2 | 0 |
| 合計 | 169 | 179 | +10 |
この8行から作った部門別・科目別のクロス集計は次のとおりで、どちらの方向から足しても差異合計は+10で一致します。
- 科目別：人件費 予算115・実績119（+4）、外注費 予算32・実績33（+1）、広告宣伝費 予算22・実績27（+5）
- 部門別：営業部 予算70・実績75（+5）、開発部 予算73・実績80（+7）、管理部 予算26・実績24（−2）
実務で追加すべき論点が3つあります。
(1) 勘定科目コードの範囲集計。科目名は表記揺れが起きますが、科目コードは体系的に振られているため、=SUMIFS(金額列, コード列, ">=5000", コード列, "<=5999") のように範囲で括れば「販管費全体」を一発で取れます。コード体系とモデル科目の対応づけは勘定科目マッピングと月次試算表から財務モデルのHistoricalsを作る方法で整理しています。
(2) 借方・貸方の符号。仕訳明細をそのまま使うと借方列と貸方列が分かれています。金額列を符号付きに正規化するか、=SUMIFS(借方列,…) - SUMIFS(貸方列,…) と差し引く形にします。ここを曖昧にしたまま集計すると、収益と費用が混ざって符号が反転します。
(3) 予算と実績のデータソースが違う場合。予算は計画系のシート、実績は会計システムという構成が普通なので、両者で部門名・科目名の表記が一致しているかを先に検証します。=COUNTIFS(実績側科目列, 予算側科目名) がゼロの科目を洗い出すチェック列を1本作っておくと、「片方にしか存在しない科目」が静かに集計から漏れる事故を防げます。表記揺れの潰し方はExcelの財務データクリーニング実務にまとめています。
予算体系そのものの設計は予算編成プロセスや変動予算と固定予算を、差異の要因分解はPrice-Volume-Mix分析の実務を参照してください。SUMIFSは「差異を出す」までの部分を担当し、「なぜ差異が出たか」を語るのは要因分解の仕事です。
実務例3：SaaSの顧客×月データからMRRを集計する
スタートアップファイナンスやVCデューデリジェンスでは、顧客ID×月の課金データからMRRを組み立てます。以下は説明用の仮設例で、顧客6社・単位は千円です。SUMIFSで扱うため、データは顧客×月の1行1レコード（ロング形式）で持ちます。
| 顧客ID | 初回課金月 | 年月 | MRR | 前月MRR | 差額 | 区分 |
|---|---|---|---|---|---|---|
| A | 2025-01 | 2025-03 | 60 | 50 | +10 | Expansion |
| B | 2025-01 | 2025-03 | 0 | 40 | −40 | Churned |
| F | 2025-01 | 2025-03 | 35 | 30 | +5 | Expansion |
| C | 2025-02 | 2025-03 | 30 | 30 | 0 | Flat |
| E | 2025-02 | 2025-03 | 20 | 25 | −5 | Contraction |
| D | 2025-03 | 2025-03 | 80 | 0 | +80 | New |
| 2025-03 計 | 225 | 175 | +50 |
前月MRRをSUMIFSで引く
SUMIFSは「同じ行の中で条件を評価する」関数なので、そのままでは前月との比較ができません。そこで前月MRRを補助列として引いてくるのが定石です。
=SUMIFS($D:$D の代わりに $D$2:$D$500, $A$2:$A$500, $A2, $C$2:$C$500, EDATE($C2,-1))
顧客IDが同じで、年月が1か月前の行のMRRを引きます。EDATEで前月を求めるため、月末日でも月初日でも一貫していれば正しく動きます。該当行がなければSUMIFSは0を返すので、新規顧客は自動的に「前月0」になります。
ここで決定的に重要な設計上の注意があります。解約した顧客について、解約月にMRR=0の行を作っておかないと、SUMIFSは「行が存在しない＝何も返さない」ため、Churnedを検知できません。顧客Bのように、解約月にゼロ行を明示的に持たせるか、顧客マスタ×月のグリッドを先に作ってからMRRを引く設計にします。
区分は =IF(前月=0,"New",IF(当月=0,"Churned",IF(当月>前月,"Expansion",IF(当月<前月,"Contraction","Flat")))) で振り、あとは区分別にSUMIFSで束ねればMRRブリッジが完成します。
| 項目 | 数式（対象月＝2025-03） | 金額（千円） |
|---|---|---|
| 期首MRR（2025-02） | SUMIFS(MRR, 年月, 2025-02) | 175 |
| New MRR | SUMIFS(差額, 年月, 対象月, 区分, "New") | +80 |
| Expansion MRR | SUMIFS(差額, 年月, 対象月, 区分, "Expansion") | +15 |
| Contraction MRR | SUMIFS(差額, 年月, 対象月, 区分, "Contraction") | −5 |
| Churned MRR | SUMIFS(差額, 年月, 対象月, 区分, "Churned") | −40 |
| 期末MRR（2025-03） | SUMIFS(MRR, 年月, 対象月)と一致すること | 225 |
コホート集計
初回課金月を条件に加えれば、そのままコホート集計になります。=SUMIFS(MRR列, 初回課金月列, $A5, 年月列, B$4) で、行に初回課金月、列に対象月を取ったコホート表が作れます。この仮設例では、2025年1月コホートの初月MRRは120（A50＋B40＋F30）、3か月目は95（A60＋B0＋F35）となり、NRRは95÷120＝79.2%です。2025年2月コホートは55→50で90.9%になります。ただし数社規模のコホートは1社の解約で大きく振れるため、実務では母数を十分に確保して評価します。
MRRの定義や4区分の考え方はMRRとは？計算方法・ARRとの違いで詳しく扱っています。用語集のARR・MRR、コホート分析、チャーンレート・NRRも参照してください。
SUMIFSは「集計」まで。モデルとして成立させるには設計が要ります
ここまでの数式は単体では動きますが、実務のモデルでは期間軸の持ち方、補助列の置き場所、検算の入れ方、シート間の参照ルールまで含めて設計しないと、他人が引き継げるファイルにはなりません。財務モデリングのためのExcel実務講座では、こうした「壊れない集計レイヤー」の作り方を手を動かしながら学べます。
実務例4：PE・M&Aのディールリストを年×業種で集計する
PEファンドやFAの現場では、案件リストから「年別・業種別のディール金額と件数」を作る場面が繰り返し発生します。マーケットマップ、ピッチ資料のトラックレコード、投資委員会向けのソーシング状況報告などが典型です。
| 業種 | 2024年 EV | 2025年 EV | 合計 |
|---|---|---|---|
| ソフトウェア | 470 | 640 | 1,110 |
| 医療・ヘルスケア | 480 | 305 | 785 |
| 産業機械 | 260 | 310 | 570 |
| 合計 | 1,210 | 1,255 | 2,465 |
| 件数（COUNTIFS） | 4件 | 4件 | 8件 |
| 平均EV | 302.5 | 313.8 | 308.1 |
公表日が日付列で入っている場合、年の条件は不等号2つで挟みます。
=SUMIFS(EV列, 業種列, $A5, 公表日列, “>=”&DATE(B$4,1,1), 公表日列, “<=”&DATE(B$4,12,31))
B$4に年（2024・2025という数値）を置けば、列見出しの年をそのままDATE関数に渡せます。件数は同じ条件でCOUNTIFS、平均は=IF(COUNTIFS(…)=0, "n.a.", SUMIFS(…)/COUNTIFS(…)) とします。AVERAGEIFSでも同じ結果ですが、該当0件のとき#DIV/0!になるため、分母チェックを自分で書けるSUMIFS÷COUNTIFS方式のほうがモデルでは扱いやすくなります。
ディール金額はEVかエクイティバリューかで意味がまったく異なるため、集計する前にリストの金額列がどちらなのかを定義列で明示しておきます。この区別が曖昧なままの集計表は、投資委員会で必ず指摘されます。実際の日本のPE市場の集計や、ファンド別の投資実績は日本のPE市場統計とPEファンド検索で確認できます。
ワイルドカードと部分一致、そしてOR条件の壁
SUMIFSの条件は文字列に対してのみワイルドカードが使えます。
"*ソフト*"：「ソフト」を含む（0文字以上の任意文字列）"ソフト*"：「ソフト」で始まる"?A"：任意の1文字＋A"~*"：アスタリスクそのものを検索（~でエスケープ）
注意点が3つあります。第一に、ワイルドカードは数値・日付には効きません。科目コードのような数値列に "5*" と書いても意図した動作にはなりません。第二に、SUMIFSの文字列比較は大文字小文字を区別しません。顧客IDが「a001」と「A001」で混在している場合、意図せず合算されます。第三に、条件に指定した文字列の中にたまたま * や ? が含まれていると、完全一致のつもりが部分一致として評価されます。
OR条件は素直には書けない
SUMIFSの条件はすべてANDなので、「ソフトウェア または ITサービス」は1本のSUMIFSでは表現できません。実務では次の3つを使い分けます。
| 方法 | 書き方 | 向き・不向き |
|---|---|---|
| 単純加算 | =SUMIFS(…,"ソフトウェア")+SUMIFS(…,"ITサービス") | 2〜3個なら最も読みやすい。増えると横に伸びて監査しづらい |
| 配列定数 | =SUM(SUMIFS(…,{"ソフトウェア";"ITサービス"})) | 条件を配列で渡し、返る配列をSUMで束ねる。条件をセル範囲で持てば保守しやすい |
| 区分列を足す | 元データに「大分類」列を追加し、完全一致で集計 | 推奨。分類ルールがデータ側に見える形で残り、後任が読める |
AND条件とOR条件が入り混じる、あるいは「金額×為替レート」のような掛け合わせを条件付きで合計したい場合は、SUMIFSではなくSUMPRODUCTの出番です。=SUMPRODUCT((業種列="ソフトウェア")*(年列=2025)*EV列) のように論理式の積和で書けるため、条件の自由度が段違いに高くなります。使い分けの詳細はSUMPRODUCT関数の使い方と用語集のSUMPRODUCT関数を参照してください。
テーブル構造化参照・動的配列との組み合わせ
元データをExcelのテーブル（Ctrl+T）にしておくと、SUMIFSの範囲が構造化参照になり、行の追加に自動追随します。
=SUMIFS(tblPL[金額], tblPL[部門], $A5, tblPL[勘定科目], B$4, tblPL[年月], “>=”&$B$1, tblPL[年月], “<=”&$C$1)
翌月の明細を貼り付ければテーブル範囲が自動拡張し、集計表は数式を触らずに更新されます。範囲の取りこぼし（新しい行が集計範囲外になる）という最頻出の事故が構造的に起きなくなります。
Microsoft 365環境では、条件側にスピル範囲を渡して結果をスピルさせることもできます。=UNIQUE(tblPL[部門]) をH2に置き、=SUMIFS(tblPL[金額], tblPL[部門], H2#) と書けば、部門の増減に応じて集計表の行数まで自動追随します。
ただし重要な制約があります。SUMIFSの「合計範囲」と「条件範囲」の引数には、実在するセル参照しか渡せません。数式で計算した配列（例：数量列*単価列）を合計範囲に直接指定することはできず、その場合はヘルパー列を作るかSUMPRODUCTを使います。この制約こそが、月次モデルで「期間キー列を実際の列として持つ」設計が推奨される理由でもあります。動的配列そのものの使い方はExcel動的配列関数の実務と用語集の動的配列関数で扱っています。
なお、集計軸をユーザーが切り替えるタイプの表では、SUMIFSの条件セルをシナリオ切替の仕組みとつなぐと運用が楽になります。CHOOSE関数によるシナリオ切替はCHOOSE関数の使い方を参照してください。1対1でデータを引く場面はSUMIFSではなく検索関数の領域で、INDEX/MATCHとXLOOKUP実践で解説しています。
パフォーマンスと、監査に耐える書き方
列全体参照を避ける
最も多い性能劣化の原因が =SUMIFS(C:C, A:A, …, B:B, …) という列全体参照です。1列あたり約104万行を毎回走査するため、集計セルが数百個あれば計算量は容易に数億回規模になります。テーブルの構造化参照を使うか、明示的に $C$2:$C$50000 のように上限を切ってください。SUMIFSは列全体を指定してもデータのある範囲までしか走査しないよう最適化される場合がありますが、揮発性関数や他ブック参照が混ざると最適化が効かなくなるため、そもそも列全体を書かないのが安全です。
再計算を重くする組み合わせ
- 条件にOFFSET・INDIRECT・TODAYなどの揮発性関数を組み込む（1セル変更で全SUMIFSが再計算される）
- SUMIFSの範囲を別ブックに置く（閉じたブックへの参照ではSUMIFS・COUNTIFSは#VALUE!を返します。これは仕様であり、ブックを開けば解消します）
- 数万行×数百セルの集計を全部SUMIFSで組む
3つ目に該当したら、関数で粘らずにピボットテーブルやPower Query、あるいはパワーピボットとデータモデルへ移行するのが正しい判断です。モデル全体の重さの診断は重い財務モデルの高速化にまとめています。
監査しやすく書く4つの規律
- 条件は必ずセル参照にする。
"営業部"や">=2025/10/1"を数式に直書きすると、条件を変えるたびに全セルを書き換えることになり、変更漏れが生まれます。行見出し・列見出しを条件に使い、期間は入力セルで持ちます（ハードコーディングの回避）。 - 範囲は絶対参照、見出しは複合参照。
$C$2:$C$500と$A5・B$4を正しく使い分ければ、1つの数式をマトリクス全体にコピーできます。「同じ表の中に違う数式が混在していない」ことが、レビュアーにとって最大の安心材料です。 - 合計の二重チェックを置く。行合計と列合計の一致、集計表の総合計と元データのSUM一致。この2本を必ず入れます。
- 色分けルールを守る。入力セル（青字）と数式セル（黒字）を分けておけば、条件セルがどこかを見ただけで把握できます。数式の追跡手法はExcelの数式監査の技術と用語集の数式の追跡と検証を参照してください。
よくある間違い8選
| 症状 | 原因 | 対処 |
|---|---|---|
| #VALUE!が返る | 合計範囲と条件範囲の行数・列数が不一致／閉じたブックへの参照 | 範囲の始点・終点行を揃える。テーブル参照にすれば構造的に防げる |
| 結果が必ず0になる | ">=$F2" のように演算子とセル参照をまとめて引用符に入れた | ">="&$F2 と書き、演算子だけを文字列にする |
| 引数の意味が逆で誤集計 | SUMIFの順序（条件範囲が先）でSUMIFSを書いた | SUMIFSは合計範囲が先頭。社内でSUMIF禁止と決めるのが確実 |
| 一部の行だけ拾えない | コードが「1001」（文字列）と1001（数値）で混在 | 取込時に型を統一。区切り位置やVALUE関数で数値化する |
| 日付条件が効かない | 日付が文字列として入っている／時刻が付いていて月末が範囲外 | シリアル値に変換。時刻付きは "<"&翌月1日 で挟むと安全 |
| 金額が実態より大きい | 元データに小計行が混じっており二重計上 | 明細のみのデータに整形。集計表の総合計と元データSUMを突合 |
| 名前が一致しない | 前後の空白・全角半角の揺れ・改行コード混入 | TRIM・CLEAN・ASCで正規化してから集計する |
| 新しい行が集計されない | 範囲を固定行数で切っており、追記分が範囲外 | テーブル化して構造化参照にする。件数チェック行を置く |
エラー値そのものの意味はExcelのエラー値にまとめています。SUMIFSで最も怖いのは、エラーで止まらずに静かに0を返すケースです。だからこそ、集計表と元データの合計一致を必ず検算セルで担保します。
よくある質問（FAQ）
Q. SUMIFSとSUMIFはどちらを使うべきですか。
A. SUMIFSに統一してください。条件が1つでもSUMIFSは動作しますし、引数順序の混乱もなくなります。後から条件を追加する際も、末尾にペアを足すだけで済みます。
Q. 条件が「AかつB」ではなく「AまたはB」のときはどうしますか。
A. 2〜3個ならSUMIFSを加算するのが最も読みやすい方法です。恒常的に使う切り口なら、元データに大分類の列を1本足して完全一致で集計するのが保守性の面で最善です。条件が複雑に入り組む場合はSUMPRODUCTに切り替えます。
Q. 月次データを四半期にまとめるとき、期間キー列と不等号条件のどちらが良いですか。
A. 同じデータを四半期・半期・年度・LTMなど複数の粒度で何度も集計するなら期間キー列を作るほうが速く、読みやすくなります。期間の開始日・終了日をユーザーが自由に動かす分析用シートなら、不等号条件が適しています。両方を併用しても構いません。
Q. SUMIFSがゼロを返しますが、目視ではデータが存在します。
A. 型の不一致（文字列の数値・文字列の日付）、前後の空白、比較演算子の連結漏れの3つがほぼすべての原因です。まず =COUNTIFS(条件範囲, 条件) に置き換えて、そもそも条件に合致する行が何行あるかを確認してください。0件ならデータ側の問題、1件以上なら合計範囲の指定ミスと切り分けられます。
Q. 何行くらいまでならSUMIFSで組んで問題ありませんか。
A. 明確な閾値はありませんが、目安として数万行×集計セル数百個を超えると再計算の遅さを体感し始めます。その規模に達したらピボットテーブルやPower Query、Power Pivotへの移行を検討してください。ファイルの再計算に数秒以上かかる状態は、モデルの信頼性そのものを損ないます。
まとめ
SUMIFSは =SUMIFS(合計範囲, 条件範囲1, 条件1, …) という構文で、合計範囲が先頭に来ること、条件はすべてANDで結合されることの2点さえ押さえれば、財務実務で必要な集計の大半をカバーできます。ファイナンスでの主戦場は、月次データの期間集計、部門×勘定科目の予実表、顧客×月のMRR・コホート集計、年×業種のディール集計の4つです。
いずれも「元データは縦持ちのまま触らず、集計表側から引く」という共通の設計思想で組みます。日付条件は ">="&セル参照 の形で書き、繰り返し使う粒度は期間キー列として実列で持たせる。条件はハードコードせず見出しセルを参照し、行合計・列合計・元データとの一致という検算を必ず置く。この規律を守れば、SUMIFSで組んだ集計レイヤーは他人が引き継げるものになります。
OR条件や掛け合わせが必要になった時点でSUMPRODUCTへ、行数が数万を超えて重くなった時点でピボットやPower Queryへ。関数に固執せず、道具を切り替える判断ができることが実務では最も価値を持ちます。
集計レイヤーの設計から、財務モデルとして組み上げる
SUMIFSの使い方が分かっても、実際のモデルではデータ取込・期間軸・集計・出力の各レイヤーをどう分けるかが成否を決めます。財務モデリングのためのExcel実務講座では、投資銀行・PEの現場で使われる設計作法と検算の入れ方を体系的に扱います。
出典・参考（2026年8月21日確認）
- Microsoft サポート「SUMIFS 関数」「SUMIF 関数」「COUNTIFS 関数」「EOMONTH 関数」「EDATE 関数」（引数の構文、条件127組の上限、ワイルドカード、閉じたブック参照時の#VALUE!に関する記載）
- Microsoft サポート「Excel の仕様および制限」（ワークシートの行数・列数）
- Microsoft サポート「動的配列数式とスピル配列の動作」（スピル参照演算子 # の挙動）
- 本記事中の売上高・予実・MRR・ディール金額はすべて説明用の仮設例であり、実在の企業・案件の数値ではありません。
※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための仮設例です。