[[20250927160735]]　『SUMIFS関数の引数について』（Σ）　ページの最後に飛ぶ

『SUMIFS関数の引数について』（Σ）

 時系列データにおいて、日付列を条件の範囲に指定して集計
 という計算をよくやります。

 =SUMIFS(A1:A10,YEAR(B1:B10),YEAR(TODAY())-1)

 上記数式がエラーになる理由が「範囲はセル範囲でなくてはならず、配列を指定できない」
 ということを最近知りました。

 SUMPRODUCTやピボットテーブルで解決できるのはわかりますが
 解決方法を知りたいわけではなく、単純な疑問です。

 「VBAやその他関数(VLOOKUPなど)ではセル範囲と配列の互換性が保たれているのに
 なぜSUMIFSなどの一部の関数ではこのような制約が設けられているのか？」

 設計上そうなっていると言ってしまえば終わりですが
 後学のためにもしわかる方いらっしゃればご教示ください。

＜使用 Excel：Microsoft365、使用 OS：Windows11 ＞

 ＞ 設計上そうなっていると言ってしまえば終わりですが
 これに尽きると思うのですが、多分、一般ユーザーで事情を知っている人は居ないでしょう。

 推理するしかないですが、以下私見。
 　Sumifsの前身にSumifがあり、その性格を一部受け継いだ。
 　Sumifは、合計範囲（第3引数）を条件範囲と同じサイズにする必要がない奇妙な(便利な？）関数だった。
  （ただしSumifsでは必須に変更された）
 　つまり、合計範囲は、左上のセル位置が適切であれば何でもよかった。
 　この仕様のせいで検索範囲もセル範囲に限定して考慮された。
 　セル範囲じゃないと、仕様がややこしいことになるので。

 この仮説の弱いところは、第３引数を持たないCountifもセル範囲だけなのは何故かが説明できない。

 Sumifの仕様確定後、平仄を合わせるべく再変更したのか、それとも
 端からSumifもCountifも計算対象として、セルしか頭になかったのか、それとも
 ロジックをシンプルにしてパフォーマンスを上げる方針があったのか・・

（半平太） 2025/09/28(日) 08:47:10

 すでにご存じのとおり、Excelは昨日や今日開発されたものではなく、長い歴史があります。
 PCのメモリーやCPUが今より格段に低いころに決めたものに左右されることもあります。
 SUMIFSが作られた当時はセル範囲を指定することでも十分な効果があるという判断だったのでしょう。
 また、ものによっては後方互換性の観点に引きずられることもあるものと思います（一般論として）。
 もし現在改めて新規開発するのであれば、ご指摘のような点も踏まえて対応されることでしょう。

 こうした話は既に指摘いただいているように、一般ユーザーに知らされることはありません。
 ですから求める回答はマイクロソフト社の技術担当の方（できれば過去のことにも詳しい人）に
 尋ねるより無いと思います。質問者さんからMS社に尋ねられるのも一法かと思います。

（xyz） 2025/09/28(日) 13:23:47

 >半平太さん
 ありがとうございます。
 基本的にSUMIFSしか使ってこなかったので、SUMIFのそのような制約は存じ上げませんでした。
 VLOOKUPやINDEXでも定数配列しか使用できない以上
 そもそもセル範囲ではなく配列を引数に渡せること自体が稀
 と考える方が正しいのかもしれませんね。
 あくまでVBAとしての配列とワークシート関数の配列は別物と考えられてそうですし。

 >xyzさん
 ありがとうございます。
 ご指摘の通り、開発者しか知らないんでしょうね。笑
 PC性能の向上に伴い、ワークシート関数の汎用性も高める動きになった、くらいの感想です。
 余談ですが、以前当掲示板にて「Redim preserveの次元の制約について」質問したところ
 かなり多くの面白い意見を頂戴いたしましたので、皆さんの私見を預かりたく投稿した次第です。

（Σ） 2025/09/28(日) 23:35:54

 ↓ここに田中さんの見解が詳しくまとめられています。一度読まれてみては？

http://officetanaka.net/excel/function/tips/tips115.htm

（名無し） 2025/09/29(月) 09:41:05

コメント返信：

[ 一覧(最新更新順) ]

[[20250927160735]] 『SUMIFS関数の引数について』（Σ） ページの最後に飛ぶ

[[20250927160735]]　『SUMIFS関数の引数について』（Σ）　ページの最後に飛ぶ