SUMIFS関数で日付条件を指定したとき、結果が常に0になってしまって困ったことはありませんか。原因は主に「日付形式の不一致」「範囲が異なる」「文字列扱いの問題」などが考えられ、条件の書き方次第で意図した集計が可能になります。この記事では、SUMIFSで「0になる日付」問題の解消方法を事例を交えて最新情報をもとにわかりやすく解説します。
目次
SUMIFS 0になる 日付で考えられる主な原因
SUMIFSで日付条件を指定した結果が0になる場合、その原因は複数考えられます。まずはどんな条件ミスやデータ上の問題があるかを整理しましょう。日付そのものの形式、セルの中身・書式設定など、意外と見過ごされがちな点を丁寧に確認することが重要です。
日付が文字列として保存されている
見た目は日付でも、内部では文字列になっているケースがあります。この状態だと比較演算（「>=」「<=」など）で正しく評価されず、SUMIFSがその行を除外してしまいがちです。日付列に対してISNUMBER関数やDATEVALUE関数を使って確認・変換することが効果的です。
日付形式とロケール（地域設定）の不一致
Excelやスプレッドシートでは、日付の表記順（年／月／日など）や区切り文字がロケール設定によって異なります。例えば「MM/DD/YYYY」と「DD/MM/YYYY」が混在していると、期待した日付として認識されないことがあります。正しい形式で入力するか、DATE関数を使って明示的に指定する方法が安全です。
SUMIFSの範囲のサイズが合っていない
SUMIFSを使う際には、sum_rangeと各criteria_rangeのサイズ（行数・列位置）が完全に一致している必要があります。もし日付列の範囲だけ短かったり長かったりすると、その条件全体が意図どおりに評価されず、結果が0になることがよくあります。
比較演算子の記述ミス
条件が「>=2026/1/1」などのように文字列で書かれているか、「DATE(2026,1,1)」など関数で指定されているかで挙動が変わります。特に比較演算子（>=, , <）をクォーテーション内外で誤って書くと、期待どおり評価されません。"&DATE(…)"のような記述を正しく使うことがポイントです。
SUMIFS 0になる 日付問題を解決する条件の書き方
上記で挙げた原因をふまえて、SUMIFS関数で日付条件を指定するときの**正しい書き方パターン**を整理します。これらを実践すれば、結果が0になる問題の大多数は解決できます。
DATE関数を使って日付を明示する
比較演算子と組み合わせて「”=”&DATE(2026,1,1) と指定することが安全で、ロケールの違いによる誤解釈を防げます。
セル参照を活用する
条件としてセル参照を利用する書き方も柔軟性がありおすすめです。たとえば開始日・終了日を別セルに入力しておき、SUMIFSの条件に「”>=”&開始セル」「”<="&終了セル」とすることで、たびたび条件を変更する必要がある場合でも式を修正せず済みます。
日付の範囲条件でAND論理を使う
特定の期間を対象とする場合には、開始日以上でありかつ終了日以下という**2つの条件**を指定する必要があります。SUMIFSは複数条件を論理ANDで適用するため、
sum_range, criteria_range, “>=”&開始日, criteria_range, “<="&終了日 という形で使うと正確な集計が可能です。
時間部分の存在を意識する
日付＋時間が入力されている場合、時間部分があると純粋な日付一致で比較できないことがあります。例えば「2026/7/5 14:30」と「2026/7/5」は同じ日でも異なる値。INT関数で時間を切り捨てたり、日付のみを扱っている列を使うなどの工夫が必要です。
実例で見るSUMIFS 0になる 日付の修正手順
ここでは実際にどのように調査して修正に至るかの手順を示します。具体例で問題点を洗い出せば、どのような書き方を直すべきかが明確になります。
問題の把握：式とデータを確認する
まずはSUMIFSの式を確認し、sum_rangeとcriteria_rangeの範囲が一致しているか、比較演算子の形式、DATE関数やセル参照の使い方、対象の日付列の書式（文字列かどうか、時間が含まれるか）などをチェックします。見た目だけで日付形式か判断せず、ISTEXTなどの関数で判定することが有効です。
データのクリーニング：文字列の日付を日付型に変換
文字列として扱われている日付は、DATEVALUE関数やテキスト操作、もしくは「テキストを列に変換」機能などで正しい日付シリアル値に変換します。さらに列全体の表示形式を日付形式に変更しておくと、見た目でも内部形式が把握しやすくなります。
式の修正：比較演算子とDATE関数を正しく使う
式の中での比較条件を見直し、文字列で日付を直接書く形式を避け、「”&DATE(…)”」のように関数を使う形式か、セル参照を組み合わせた形式に修正します。また、開始日と終了日など範囲条件を正しくセットしてAND条件が満たされるようにします。
時間部分への対処：時間要素がある場合の処理
時間が含まれていると日付が一致しないことがあるため、時間を切り捨てるかINT関数で日付部分のみを比較条件・データに使うかを考えます。もし時間情報が不要であれば、元データ列か比較列を丸めて扱うことで不一致を回避できます。
よくある間違いとその予防策
SUMIFSで日付を指定して0になるケースは、似たような間違いが繰り返されることがあります。それぞれを意識しておくことで問題を未然に防ぐことが可能です。
月や年だけで条件を書いてMONTH関数を使う誤用
例えば「MONTH(日付列)=7」のように直接MONTH関数をcriteria_rangeで使う式は、SUMIFSでは正しく機能しないことがあります。MONTH関数をcriteria_rangeとして使うと範囲の形が合わずに無視されるか0になります。代わりに、開始日と終了日を設定して期間指定したAND条件を使うことが望ましいです。
比較演算子の内外における構文エラー
例えば「>=1/1/2026」という書き方をする時、Excelの設定によっては「日付を文字列」と解釈されてしまうことがあります。また比較演算子をクォーテーションで囲む範囲、式全体の結合などでミスをすると期待値が返らないので、「”<="&DATE(…)」などと書くことが安全です。
見た目の日付にだまされる書式設定ミス
セルの表示形式を「日付」にしていても、実際は文字列だったり、日付シリアル値が異常だったりする場合があります。セルを選んで数式バーで確認したり、別列でISNUMBERを使ってチェックすることで見える化できます。
範囲の行数ずれやセルの空白
条件範囲（criteria_range）と集計範囲（sum_range）の行数や列範囲がずれていたり、途中に空白セルや非表示行が混ざっていると、それも原因となります。範囲を統一して指定し、空白・空セルの扱いを明確にすることで精度が向上します。
SUMIFS 0になる 日付が改善した例と応用
正しい書き方を適用したことで0が解消された例をいくつか紹介します。これによりどのような状況でどの方法を使うとよいかイメージしやすくなります。
例1：月初と月末を使った範囲指定
特定の月（例：2026年6月）の売上合計を求めたい場合、「>=」でその月の1日、「<」で翌月の1日とする範囲指定が有効です。こうすることで月全体をきちんとカバーでき、時間や表示形式の違いによるズレを防げます。式が0だったものが正しい値に変わることが多いです。
例2：セル参照とDATE関数で可変条件を設定
開始日と終了日を別セルに入力しておき、条件式でそのセルを参照する形にすると、毎月・毎年の変化にも対応できます。例えば「”>=”&$A$1」「”<="&$A$2」といった書き方で、他の列も同じ範囲を使う場合にはsum_range・criteria_rangeを揃えておくことが重要です。
例3：時間部分が含まれていたデータの丸めと集計
データに「日付＋時間」が含まれていたケースで、時間が異なるために一致しないものがあったものの、INT関数で日付のみを抽出する列を用意してそちらを条件として使った結果、正しく集計できるようになった例があります。この処理で0を防げることが多いです。
例4：インポートされたCSVデータの文字列日付を変換
CSVなど外部ソースからインポートしたデータが文字列扱いになっているケースで、DATEVALUEやテキストを列に変換機能で日付型に変換したあと、SUMIFSの式で比較演算子を正しく使ったら結果が0から正常な値に戻った例があります。データの整備が成否を分けるポイントです。
まとめ
SUMIFS関数で日付条件を入れた際に結果が0になる原因は、多くが「日付そのものの形式」「範囲のズレ」「比較条件の文法ミス」「時間部分の混入」などにあります。たとえ見た目が日付であっても内部的に文字列なことがよくあるため、ISNUMBERやDATEVALUE等で形式を確認・変換することが第一歩です。
また、比較条件はDATE関数やセル参照を使って明示的に指定し、開始日・終了日の範囲指定を正しく書くこと、演算子の使い方を間違えないことが重要です。さらに、sum_rangeとcriteria_rangeのサイズを一致させることも忘れてはいけません。
それらを適用すれば、SUMIFSの「0になる日付」問題はほぼ解消できます。もし式やデータに不安があれば、今回紹介したチェック観点を順に確認してみてください。
コメント