Excel VBA 質問スレ Part84

**デフォルトの名無しさん** · 2025/10/01(水) 14:36:42.66

ExcelのVBAに関する質問スレ
コード書き込みや作成依頼もOK

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
Excel VBA 質問スレ Part83
https://mevius.5ch.net/test/read.cgi/tech/1749348402/

**デフォルトの名無しさん** · 2025/10/02(木) 00:16:11.64

2行目2例目

**デフォルトの名無しさん** · 2025/10/02(木) 02:40:54.02

パワークエリは2010ならアドオンで使えるんだから使えるってのは間違ってないよ

**デフォルトの名無しさん** · 2025/10/02(木) 21:54:27.31

Date.Fromは日付と時刻型を日付のみ型に変換する関数だと思っていましたが、実は引数はAnyでテキストでも数値でも日付と解釈可能ならdateにしてくれるんですね
今までの苦労は何だったんだろう

**デフォルトの名無しさん** · 2025/10/02(木) 22:49:07.56

おそらくスレがないので、すれ違いで申し訳ないのですが、
エクセルVBAはブックごとにマクロを具有しますが、Outlook VBAはどこにマクロを持つのでしょうか
アドインのようなものになるのでしょうか
ggrksと言われそうですが…

**デフォルトの名無しさん** · 2025/10/02(木) 22:59:10.74

C:\Users\＜ユーザー名＞\AppData\Roaming\Microsoft\Outlook
らしいです

**デフォルトの名無しさん** · 2025/10/03(金) 00:42:58.97

こっち消化しろよ

Excel VBA 質問スレ Part80(ﾜｯﾁｮｲあり)
https://mevius.5ch.net/test/read.cgi/tech/1700826110/

5 · 2025/10/03(金) 01:16:30.02

>>6
ありがとございます
ちょっと調べてみます

**デフォルトの名無しさん** · 2025/10/03(金) 05:06:39.02

>>7
ワの有無は別スレと見做される

**デフォルトの名無しさん** · 2025/10/03(金) 09:19:09.56

積極的にそうすべきというほどの強い意見ではないけれども、現状ﾜｯﾁｮｲありとなしとを使い分ける需要がさほどないということであれば、先に>>7のスレを消化するというのもありかもね。スレ交代のタイミングでちょうど良いし。

**デフォルトの名無しさん** · 2025/10/03(金) 13:09:50.91

ワに書き込めるわけ無いだろ
いいかげんにしろよ

**デフォルトの名無しさん** · 2025/10/03(金) 13:30:51.70

>>11
そうやってID変えながら荒らす気まんまんやん

**デフォルトの名無しさん** · 2025/10/03(金) 23:57:43.31

ワッチョイ気にするのか…

**デフォルトの名無しさん** · 2025/10/04(土) 10:49:20.79

前スレで話題に出たパワークエリはM言語という言語でVBAとは相容れない
VBAと連携する方法もないではないがWSHの言語間程度の違いはある
知りたい人が居るならPower Query M言語スレを別に立ててやるべきだと思う

**デフォルトの名無しさん** · 2025/10/04(土) 13:15:46.24

>>14
Power Queryだけでスレを立てても知名度が低すぎるから人が集まらないのと、「基本を知ってしまえば後は分からない事は何もない」から「話がすぐ終わる」（泣）
Excel自動化という点で同じなのでここで（震え声）

Excelの関数に正規表現関数が有る事を今思い出した（なければ自作すればいい）
だから今時はもうLeft関数、Mid関数、Right関数で無理矢理やらなくていいんだ。

**デフォルトの名無しさん** · 2025/10/04(土) 13:53:38.50

Excel女子の言い分を真に受けると
https://exceljoshi.cocoo.co.jp/media/excel-powerquery
必要なひとは使えばいいんじゃね？となる
Excelエキスパートの君らには、あんまし使いどころが無いんだろう

**デフォルトの名無しさん** · 2025/10/05(日) 06:02:00.45

みんながみんな大量のデータ集計や高度な集計をやるわけでは無いからPower Queryを必要とする人はいないと言われれば確かにそうですね。
だけどExcelで集計をすると言うのであればVBAでは無理です。

**デフォルトの名無しさん** · 2025/10/05(日) 07:06:17.38

VBAでも無理ではないでしょ
ゴミのように書きにくく読みにくく遅いだけで

**デフォルトの名無しさん** · 2025/10/05(日) 07:10:15.40

Excel女子でもVBAで出来てるから｢無理です｣は言い過ぎ　VBA女子ってのも居るそうだ
https://exceljoshi.cocoo.co.jp/media/work-efficiency-vba-reporting
何であれ、事前の下拵え(前準備)がだいじだと説いてるその通りだけど具体例は有料っぽい
まぁ、女子に頼らなくてもそこら中に転がってるけど
https://note.com/bunsekiya_tech/n/n7da42fbfa7b4

**デフォルトの名無しさん** · 2025/10/05(日) 07:40:58.07

VBAでやるときは各レコードをどこにどう書くかということをガチガチに固めておく必要があるのに対し、DBとかパワークエリだとそこら辺が抽象化できるイメージかなぁ。

**デフォルトの名無しさん** · 2025/10/05(日) 07:58:20.71

>>20
本当にそれなんですよ
パワークエリーやSQLなら列同士の集計やグループバイ、Join、UnPivotができるけど、VBAでUnpivotは流石にキツい

**デフォルトの名無しさん** · 2025/10/05(日) 08:28:28.60

LET、XLOOKUP、FILTER、GROUPBYあたりを駆使すればワークシート関数でも結構いける
わざわざ別アプリ起動してマイナー言語でとはならないかな・・・

**デフォルトの名無しさん** · 2025/10/05(日) 08:39:23.86

それこそ事前の準備で済む話　いきなり大容量のデータに接続してあれこれしようとするから混乱する
結果から想定されるデータ群に仕様を整えておくのが先ず最初にすべきこと
ADO が非推奨と成り果てたからVBA内でSQL使おうにも先細りなんだろうけど、まだやれない訳じゃ無いし(最新版じゃ無理なのか)
何であれ、いきなり野良データに接続してあんなことやこんなことしようとする方が無謀　データの事前整形はイロハのイ

**デフォルトの名無しさん** · 2025/10/05(日) 09:10:22.53

>>23
その事前のデータ整形がパワークエリーなんですよ
そもそもPower BIはパワークエリーとパワーピボットの二つが合わさった製品だし
ADOが非推奨だとは知らなかったです
やっぱりVBAはダメダメなんですね

**デフォルトの名無しさん** · 2025/10/05(日) 09:12:20.05

>>22
GROUPBY関数は最近になってやっとM365だけで使える様になった引数の翻訳も終わっていない関数じゃ無いですか
しかもGROUPBYに渡す元データのUnPivotはどうするんですか？
UnPivot関数はありませんよ？

**デフォルトの名無しさん** · 2025/10/05(日) 09:18:37.32

パワークエリーは
let
変数名 = 関数
in
ただこれだけです
各ステップ名にそれぞれの関数の戻り値（型）が代入されるだけです
一体どれだけ簡単なのかと
名前付きfunction関数なら
(変数名型) =>
let
変数名 = 関数
in
ただこれだけ

**デフォルトの名無しさん** · 2025/10/05(日) 09:28:11.50

会社で本格的なデータベースを構築しているとか、サーバーが使える、あるいは業務にしているのならそりゃSQLを推奨しますよ
しかし日本企業がそんなにITの導入をしているとは私はまったく思えません
だから当然必然的にExcelの標準機能一択になるわけです
世の中の企業にはVBAを禁止している会社もあると聞きます
だったら尚更パワークエリー
あとSQLはETLではないからSQLにできないことも多い

**デフォルトの名無しさん** · 2025/10/05(日) 09:41:07.01

UnPivot て、Excelの原始的な機能で、貼り付け時に行/列入れ替え貼り付けだけで済むんじゃないのか？
そんな単純じゃない！もっともっと厳しいデータなんだ！ってことなのか？
取り込んだデータが行列逆だったら、真っ先にそれするもんじゃないのか？　基本のキ？

**デフォルトの名無しさん** · 2025/10/05(日) 09:51:23.22

>>28
UnPivotと行列入れ替えは全くの別物ですよ
行列入れ替えは本当にただ
　列
行
を
　行
列
にするだけなんだけど、UnPivotは横持ちデータを縦持ちデータに変換する事を言います
例えば
　1月2月3月4月5月〜
各エリア
〜
という表があればその各月のデータを
エリア列|月列
とリスト表形式に整えてくれます
これ無くして高度な集計はできません

**デフォルトの名無しさん** · 2025/10/05(日) 09:51:47.38

社内にサーバー(NAS含む)も仕立てていない企業が蓄えてる大容量のデータって
いや、Power Query を否定するつもりは無いけど、今のExcelの標準の機能で殆ど賄えやしないか？
ものっそ古いデータもあって、当時はデータの統一性もまばらで、セル内改行してるだの
文字の位置合わせにスペース使ってるだの、予想外のデータだったりすることもあるんだから
イロハのイ、基本のキは守っておいて損は無いんだけど

**デフォルトの名無しさん** · 2025/10/05(日) 09:58:16.44

自分はSQL派なので事前に定義されたテーブルにデータを入れておくという考え方の方になじみがあるけど、表っぽいデータなら大抵はうまい塩梅に整形できますぜということならパワークエリにもそれなりに活用場面は出てくると思う。ただ、クエリ部分をSQLからパワークエリに置き換えるのはちょっと躊躇を覚えるかな。標準規格があって、ペンダーが複数いるという安心感はかなり大きいので。
SQLを除いてExcelおよびその関連機能であるVBA、パワークエリだけで考えたときに、それぞれどういう長所・短所があるかというのはそれはそれで1つの議論ではあるね。

**デフォルトの名無しさん** · 2025/10/05(日) 10:08:01.77

なんでVBAで流石にUnPivot旬は難しいと言えるかと言うと、UnPivotする為にはそれぞれの項目とその数に応じて大量に行の挿入を行う必要があるからです

これをVBAでやろうとすると行ズレ問題に頭を悩ませるし、セル操作、Rangeは非常に遅いし、2次配列の操作はVBAは非常に貧弱だからです

一応、パワークエリーが登場する前（本当はMicrosoft Queryという前身機能があったらしいですが）のVBAのまず最初にやる事はUnPivotだったらしいので、絶対にできないとは言いません
しかし、パワークエリーならボタンぽちぽちで済む事を全部コードに書かなきゃならないので非常に面倒くさい上に不具合もあります

サーバーがある、本物のSQLが使用できる環境があると言うのなら当然止めません
既に正規化されているデータだけを扱うと言うのであれば尚更でしょう
しかし世の中その様なデータばかりを扱うとは到底思えません

**デフォルトの名無しさん** · 2025/10/05(日) 10:09:32.03

>>31
表っぽいデータなら「大抵」ではなく、「全て」うまい塩梅に整形できますぜ　です
なぜならそれがETLだからです

**デフォルトの名無しさん** · 2025/10/05(日) 10:30:14.94

その「ボタンぽちぽち」で出来てしまう点を懸念してンだけどねw
野良データがガサツでも、ぽちぽちしたらちゃんとした表に仕上がりました！　で、そのデータの
信ぴょう性とかファクトが担保されるのか？という面で、イとかキは疎かにしちゃいけない、と
で、そのイとかキをしてる最中に｢これとこれをこうすりゃこう仕上がる｣という、データ加工の
手順や経緯や法則がきちんと把握できてく(それが判ればほぼほぼ基本機能で済むケースが多いのも現実)

そういう基盤がキチンと制作者も受け取る側も共有出来てるなら、どんなアプリ使おうとも構わんけど
作る側がその辺ないがしろにして｢この機能サイコー！｣だけで盲信して得意満面に仕上げてきた表ほど
役に立たないものも無いってのも現実　まあ、老婆心だけだけどw

**デフォルトの名無しさん** · 2025/10/05(日) 10:50:37.84

たぶん想定されている使われ方が結構違うんだろうね。

DBの場合、事前に設計されたテーブルを前提としているから、テーブル設計で失敗していない限りそもそもpivotとかunpivotとかが必要になる機会自体そんなにないと思うのよ。古いシステムからデータを取り込んだりするときくらいじゃない？　だからpivot / unpivot の利便性をメリットとして挙げられてもあんまりピンと来ない感がある。
パワークエリの方は、どちらかというと表っぽいデータ（いわゆる野良データも含む）をアドホックに処理できることに重点を置いているんでしょう。そういう場面ならpivot / unpivot が簡単にできると便利というのは分かる。

>>34
イとかキって何だと思ったが、イロハのイとキホンのキか。34を読んだだけでこれに気付いたのって凄くない？w

**デフォルトの名無しさん** · 2025/10/05(日) 10:51:30.92

そんなのVBAだろうとPQだろうと同じ
当たり前
当たり前のこと毎週書いてろw

**デフォルトの名無しさん** · 2025/10/05(日) 11:44:07.60

元データがちゃんと正規化されているリスト表だけだったらSQLでも十分
それはその通りです

でも世の中残念ながらそうじゃないんです
これはなぜETLというツールがいくつもあるのかという話です
大量の列があるデータをソフトウエアがCSVで出力されるケースを私は実際に知っているのです
そしてその時に私はUnPivotを知りました

**デフォルトの名無しさん** · 2025/10/05(日) 11:49:26.34

これだけは言えると思うのは
確かにSQLは1列に一つの種類の値、型のデータを扱うのなら最適化されているので高速ですが、そうでない場合、データのクリーニング、前処理が必要は場合は必ずしもそうではないと思います

あとデータソースは各種サーバーに出来るので、まずはお試しでやってみる、という叩き台やテストを「お手軽に」する事もできます

**デフォルトの名無しさん** · 2025/10/05(日) 12:15:13.64

そりゃデータの整形や前処理はSQLじゃなくて、ホスト言語の方の守備範囲だからね。
だから整形・前処理の部分で比較するなら、「コードを書く必要があるけど汎用性の高いホスト言語（JavaScriptとかPythonとか）」と、「ノーコードで済んで利便性が高いけどMSにロックインされるパワークエリ」という比較になるんじゃない？
表っぽいデータをアドホックに次々と分析していくような用途ならパワークエリの方が便利だろうし、永続的なデータを扱うならSQLの方が安心感がある。

フォーマットが完全に固まっているならVBAも選択肢に入ってくるだろうし。

**デフォルトの名無しさん** · 2025/10/05(日) 12:58:00.67

>>29
UNPIVOTはCHOOSECOLSとVSTACKで余裕

**デフォルトの名無しさん** · 2025/10/05(日) 13:40:37.24

>>29
=LET(
UNPIVOT,LAMBDA(table,values,
DROP(REDUCE(0,SEQUENCE(COLUMNS(values)),LAMBDA(a,v,
LET(
value,INDEX(values,v),
VSTACK(a,HSTACK(EXPAND(value,ROWS(table),,value),CHOOSECOLS(table,v)))
)
)),1)
),
UNPIVOT(C1:G10,{"月","火","水","木","金"})
)

**デフォルトの名無しさん** · 2025/10/05(日) 14:06:08.15

サーバーも持ち合わせずVBAも禁止されてる企業って書いてみたり
とあるアプリが大量の列があるCSVを吐き出したケースがあって、それでUnpivotを知ったとか書いてるし
やっぱ新しいおもちゃに大興奮してるとしか読めない
野良と言えどもサイバー空間上にあるデータは、まがりなりにもDBのお作法に沿った整形されてるんじゃないのか？
WEBページやクラウドデータとかに接続するなら尚更
手強い野良っつーのは社内に保管されてる過去20年のデータみたいな意味で、>>30 に書いた例なんかかわいい方
とも思えるファイルがゴロゴロしてることもある　それを上から十行ぐらいナナメ読みして憶測で判断してたら
しっぺ返し喰らう
その大量に吐き出されたCSVだって、実はD列のデータだけじゃ無くてAA列だのBB列だののデータと組でようやく意味を為す
なんてぇケースだってごまんと見て来た　キとかイとかw　データを扱うお作法は蔑ろにしてはいけない
データクレンジングとか昨今は呼ぶのか？　それは機能に任せる前に、人間の目で手でまずは洗浄しておくべき
キカイは命令された事しかやらない・できない　その命令する側が手抜きしてたら手抜きされたデータの塊になるだけ

**デフォルトの名無しさん** · 2025/10/05(日) 14:30:19.32

>>40-41
そういうのは余裕とは言わないw 凄いとは思うけど、人が読んだり書いたりするコードじゃないでしょ。AIに生成させるとかならありかもしれないが。

2020年代になってから関数が大量に追加されているのって、AI使用が視野に入っているからなのかなとちょっと思った。

**デフォルトの名無しさん** · 2025/10/05(日) 19:35:04.95

>>42
複合キーを利用する、複数列の値を使用する、結合するという事はできますよ

**デフォルトの名無しさん** · 2025/10/05(日) 20:29:32.36

そもそもExcelになぜPythonが導入されたかと言うと、パワークエリーで前処理、集計したデータを非公式に導入したPythonでさらに高度な集計を行う、と言う事が行われていたからです。
そう言う事が行われているくらい非常に協力な機能なのです。
JavaScriptのコードも動かせます。

**デフォルトの名無しさん** · 2025/10/05(日) 21:56:29.73

言いたいことがちょっとわからない

Python in Excelの話をしてるの？
Officeアドインの話をしてるの？
Officeスクリプトの話をしてるの？

**デフォルトの名無しさん** · 2025/10/05(日) 22:15:43.84

>>46
全てパワークエリーの話です

**デフォルトの名無しさん** · 2025/10/05(日) 22:33:36.02

パワークエリって、（SQLの代替というよりも）データフレーム系のライブラリ（PythonでいうところのPandasとか）に近い機能なんじゃないかな。自分はデータフレーム系のライブラリってほとんど触ったことがないから分からないけれど。

**デフォルトの名無しさん** · 2025/10/05(日) 23:04:56.42

>>45
へー、MSがPythonを組み込んだ理由の客観的証拠を示してごらん

**デフォルトの名無しさん** · 2025/10/06(月) 02:26:33.81

>>49
キチガイの妄想なんだから答えるわけないだろw

**デフォルトの名無しさん** · 2025/10/06(月) 08:37:55.38

VBAをPythonに置き換えようと開発進めてたけど、
サードパーティーのアドオンが優秀なので公式でやる必要が無くなった（ここまでMS開発者ブログより）
でも成果物を使わないのも勿体ないから使ってる（俺の妄想）
ってことだろ

**デフォルトの名無しさん** · 2025/10/06(月) 09:38:05.20

>>48
普段SoR系のシステムばかり見てる人には馴染みのない話かもしれないけど、
ビジネスアナリティクスの世界では、SQLは汎用的なデータ分析ツールとして結構カジュアルに広く使われているのです

**デフォルトの名無しさん** · 2025/10/06(月) 10:52:24.34

まーた新しいオモチャ拡げ出したぞw　SoR系だからSQLが重宝されてきたんだろうに
アナリティクスなんて概念、後発も後発　まあ、SoRに於いてSQLでAnalyticsしてた
という見方もできるわけで、もはや何言っても相手に響かないからお口チャックしときなよ