★ 今後、Office2022以降、「Microsoft Query」と「QueryTableオブジェクト」は、無くなるのか? ~ Excel2019でCSVを吸い込む処理を「マクロの記録」機能で見ながら ~
  
※まだ書きかけです。すみません。
※間違ってたらすみません。
※メモ書きなので、自分でも意味不明な箇所も多いです。ごめんなさい。
  
  ★ はじめに~なぜ、「Microsoft Query」と「QueryTableオブジェクト」が無くなると「マズイ」のか?
  ★ サンプルのダウンロード
  ★ プログラムの概要
  ★ 「QueryTableオブジェクト」は、無くなるのか?
  ★ 「Microsoft Query」は、無くなるのか?
  ★ CSVを吸い込む動作を、Excel2019のマクロの記録で記録し、少し修正したプログラム(QueryTableが無くならなそうな理由がわかる記録マクロ)
  
★ はじめに~なぜ、「Microsoft Query」と「QueryTableオブジェクト」が無くなると「マズイ」のか?

なぜ、「Microsoft Query」と「QueryTableオブジェクト」が無くなると「マズイ」のでしょう?

端的に言うと、「Power Query」が、(ホントは言いたくないのですが)「役立たず」だからです。

特に、
「Microsoft Query」と
「QueryTableオブジェクト+SQL+VBA+ODBC接続」
が20年以上の前から扱える人間にとっては・・・。

まず、「Power Query」は、「Microsoft Query」と「QueryTableオブジェクト」などの「後継」「ではない」のですが、でも位置的なそんな風に見えなくもない感じで追加された機能です。
要するに、
「リレーショナルデータベースのような考え方をもとに、そのようなこととか、それ以上のことまでも、いろいろやっちゃいましょう」的な
感じです。
「Microsoft Query」と「QueryTableオブジェクト」などよりもより複雑なことができます。
特に、「クロス集計表をリスト形式の表に変換したり」、のときによく使われるようです。

  

が、
そもそもの「画面の動きが遅すぎ」たり、
そもそもの「操作自体が複雑すぎて(機能が細かすぎて)」、
また、
「SQLを理解していないと操作できないため、一般事務員さんのほとんどが、難しすぎて使えない」
「VBA化するのが ” 超 ” 面倒くさい(基本、” できない ”と思っていい)」、
「構造や操作が複雑すぎるため、作業するための時間コストもかかりすぎ」、
なくせに、
「大したことに使えない」
ですし、
また、
何といっても、実際に、
「Power Query の市販書籍やWeb記事で書かれていることの半分以上が、Microsoft Query か QueryTableオブジェクト+SQLを使うほうが早くて、簡単で、動きも速い(半分以下の時間で同じことができる)」
と、そういう機能です。

機能てんこ盛りにしたけど、「Microsoft Query」と「QueryTableオブジェクト」などよりも遅くて使いずらくて、それらとVBAがあれば、かなりの部分が不要になってしまう機能です。

「VBA使わなくてもいい」、というのが売りなのですが、かえってVBAよりも難しくなってしまっています。

PowerQuery【01】PowerQuery(パワークエリー)で出来ること 』を読むと、
「Accessのクエリに慣れている人なら30分~1時間、Vlookup関数しか使ったことが無い人なら1時間以上」と書いてありますが、そんな「甘いモン・簡単なモンじゃない」です。
それは、「表と表を結合するだけ」のときのお話です。
(ただ、このWebページは図も多くて結構わかりやすいWebページだと思います。ご活用にどうぞ。)

  

おまけに

「リレーションも組みづらい」

です。
  

「あほか?」
「バカなの?」

という感じです。

  

つまり、
『ああ、こんな程度のクエリ機能(=データ抽出機能)だったら、
 「Microsoft Query」か
 「QueryTableオブジェクト+SQL+VBA+ODBC接続」
 のほうが100倍マシ!
 どうみても、早くて速くてコストも安くて
 VBAで自動化しやすい』・・・
ということなのです。

それは言い過ぎだとしても、
でも、少なくとも、
「Power Query」でやる作業の半分くらいは、絶対に、
「Microsoft Query」か
「QueryTableオブジェクト+SQL+VBA+ODBC接続」
によって、
「Power Query」でやる半分以下の時間で、
完了します。

  
だからです。

  

もちろん、「Power Query だけにしかできないこともあるはず」なので、そういう時にこそ、「Power Query 」を大いに活用したいです。

でも、例えば「リレーションがこんなに組みづらい」なんて、「マジ、バカなの?」としか言いようが無いです。
  

例えば「リレーション」については、「Microsoft Query」に限った話でなら、
たしかにテキストファイルとExcelファイルなどの「異なるファイル同士だと」直接リレーションできないですが、でも、「同じファイルの種類同士」なら、リレーションはドラッグ一発で簡単に、どのようにも組めます。
2つの表のあいだであれば、何本でも、ドラッグでしゅしゅしゅしゅーとやるだけです。その間・10~20秒ほど。
2つ以上の表のあいだでも、3つの表でも4つの表でも、同じようにドラッグでしゅしゅしゅしゅーとやるだけです。これも10~20秒ほど。
リレーション結果は一時コンソールですぐに状況チェックできますので、「SQLが分からない人」でも、何回でもやり直しも利き、結果、できます。
相手がテキストファイルなら、いったんExcelに取り込めば問題ありません。
これは
・事務の人でも営業の人でもSEやプログラマでなくても、
・VlookUp関数なんか使ったことがなくても、
「誰でも」
「カンタンに」
「できる。」
ことを意味しています。
  

でも、そんな大切な大切な「Microsoft Query」と「QueryTableオブジェクト」は、実は、「20年以上前からExcelやOfficeに実装されている」「とっても古い」「技術、機能」なのです。

なので、もしかしたら、今後の新バージョンのExcelで「廃止」という可能性もあるのです。

とっても心配です。

なので、Excelの上級者には(「とっても古い技術、機能」だということだけで)、
『 「Microsoft Query」と「QueryTableオブジェクト」なんかどうせ消える機能だから使いものにならない 』
という風に「決めつけて」・そして「言う」、愚かな人も居ます。

古女房なんて捨てて浮気しよう、というわけです。

特に、「クロス集計表からリスト形式の表に変換するにすごく便利!」ということを声高に言う人が、そういうことを言ったりします。

でも、「Power Query」でできるのは、
「単純なレイアウトのクロス集計表」を「リスト形式の表に変換する」ことだけです。

例えば
「メチャクチャなレイアウトの表(例えば3行一組で不規則なセル結合や空白行もある請求書など)」を「リスト形式の表に変換する」なんてことはすぐにはムリです。
もしかしたらできるかもしれませんが、簡単ではありません。
できたとしても、処理がすっごく複雑になり、それこそ、「SEかプログラマ」にしか扱えません。
当然、「普通の事務や営業の人」にはムリです。

結局、そういう表は、「Microsoft Query」よりも、「VBA」で「クレンジング(整形)」したほうが早いし、「速い」のです。
(※もっと言うと、VBAよりもワークソート関数のMatchやIndexのほうが早いかもしれません。)

で、現場では、「現実」としては、
「単純なレイアウトのクロス集計表」よりも、
「不規則なセル結合も含んだメチャクチャなレイアウトの表」の方が多いです。
でも、整理された表であれば、すでに「MicrosoftQuwry」があるので、それがあれば、おおむね事足ります。

「Power Query」と組みあわせて使うことももちろんできます。

なので、「Power Query」は、
・「Microsoft Query」
・「VBA」
・「SQL」
・「QueryTableオブジェクト」
をすでに20年前から使っている人にとっては、あまり大きな使い道は少ない気がします。
すごく使い道がある方もいらしゃると思いますが、とりあえず、僕にはまだ必要性が出てきていません。

「PowertBI」を「しょっちゅう」使う人「だけ」ではないでしょうか?
(※「PowertBI」ではパワークエリ(M言語、DAXなど)が必須らしいので)

もちろん、そのほかにも「大いに利用できるシーン」は「絶対に」あるはずなので、「ムダ機能」では「絶対にない」ですが。

ただ、「Power Query」と「PowerBI」の関係がどうなのかわかりませんが、「PowerBI」ほうが、使い道が多そうです。
  

というわけで・・・、
「普通の事務や営業の人」でも扱える「Microsoft Query」や「QueryTableオブジェクト」は、非常に便利で貴重な存在なのです。

でも、確かに古い技術なので「無くなる」可能性もあって心配です。

ここでは、「ならいつ無くなりそうか?」「いつまで残りそうか?」などを少し「推測」してみたいと思います。

  

前置きが長くなりすぎてすみません。

ここでやっと「結論」を言いますと、多分ですが、

あと5年(2026年2月21日まで)は

「無くならない」

と思います。

(※VBA自体の構造・記述用法自体が大きくが変わらない限りは。)
  

「Microsoft Query」はわかりませんが、「QueryTableオブジェクト」は特にそう言えると思います。
「QueryTableオブジェクト」はExcelVBA自体が無くならない限り、無くならないかもしれません。
少なくとも、「テーブル機能(ListObjectオブジェクト)の内部でも使われているので、あと10年(20③1年2月21日くらいまで)は残るのではないかと推測されます。

また、Microsoft365や、2022の次の次以降くらいのOfficeではわかりませんが、
「永続版の2019」なら、「おそらく」「ずっと」「使い続けることができます」。
(特に、WindowsのPro版で、OSの進化を止め、2019もスタンドアロンインストーラをダウンロードすれば。)

  

では以降で、その「QueryTableオブジェクト」が

『 あと5年は(多分10年くらいは)「無くならない」』

という理由について、少しお話をしたいと思います。

大した話でも、大した理由でもないのですが・・・(^^)

  

★ サンプルのダウンロード
以下のリンクからダウンロードしてください。(ESETでのウィルスチェックをしてあります)

サンプルのダウンロード

ダウンロードしたら、「1.csv」というCSVファイルがありますので、それを「D:\1」というフォルダを作ってそこに入れてください。

なお、このサンプルプログラムは「1.csv」でないと、また、「D:\1」に置かないとエラーになりますので、ご注意ください。

「2019でのCSV吸込み.xlsm」が実行用のファイルです。

  

★ プログラムの概要

このプログラムは、Microsoft365の「Excel2019」にて、「マクロの記録」で記録したモノを、少し理解しやすいように、若干作り変えたプログラムです。
ここから意外なことが分かりました。
(Power Queryで使われる「クエリ」の「接続」が自動作成されたあとに、それが
 Power Queryで使われる「クエリ」の「接続」が「つくられた」「にもかかわらず」、
 でも、いまだに、「QueryTableオブジェクト」がListObjectオブジェクトの中に、
 自動生成されていました。)

「2019でのCSV吸込み.xlsm」が実行ファイルです。

Ctrl+F11キーにてVBEを開いたのち、

「CSVImport01()」を実行すると、「D:\1」に置いた「1.csv」の内容を吸い込みます。
(同時にクエリの「接続」と「名前の定義」「テーブル(含QueryTableオブジェクト付き)」も自動作成されます。マクロの記録をしてもその動きを取ります)

「PwQueryDelete」を実行すると、吸い込んだものを削除します。
イミディエイトで「PwQueryDelete」とコピペしてEnterすれば、吸い込んだものが、
削除されます(クエリの「接続」、名前の定義、テーブル、とともに)。
そのあと、再度、「CSVImport01()」を実行できます。
(※いったん削除してからでないと、次回の「CSVImport01()」はエラーになります)

  

★ 「QueryTableオブジェクト」は、無くなるのか?

結論から言うと、「QueryTableオブジェクト」は、今後も当分のあいだ、無くならないと思います。(VBAの構造自体や記述方法自体が大きく変わらない限りは。)
なので、そのまま「SQL」も使えるので便利ですね。

理由は、後述のプログラムの中にコメントとしても書いたのですが、ここでもそれをコピペしておきます。
「Call ActiveWorkbook.Queries.Add・・・」の終わりのところです。

  
' なお、のちほど、ListObjectオブジェクト(テーブル機能)の
' 自動生成の箇所で、QueryTableオブジェクト が生成されているのを見ると、
' 「QueryTableオブジェクト」自体は
' 2022以降のバージョンでも当分は廃止されなさそう。
'
' なので、レコードの単純な抽出作業なら、
' 「最初から」
' 「PowerQuery」は使わずに、
' 「QueryTableオブジェクト+SQL+VBA+ODBC接続」
' を今後も使い続けてもMicrosoft365であっても問題は無さそうです。
'  (※テキスト系のファイルの吸い込み時は
'   「ODBCデータソース」を使わないと
'   SQLが使えませんが、でもそれでも。
'   ファイル名指定するだけで済み、
'   PowerQueryのように列名の設定は原則要らないので。設定することも可能ですし。
'   また、OSから「ODBCデータソース」が無くなることも考えにくいですから。)
' 永続版の単発のExcelならさらに問題なし。
'  また、
'  「QueryTableオブジェクト+SQL+VBA+ODBC接続」
'  でやったほうがやっぱりラクちん。

とりあえず、理由は、以上です。

  

後述のプログラムの、
「Set o_QTItem = ActiveSheet.ListObjects.Add( _・・・」
の行の数行下に
「Destination:=Range("$A$1")).QueryTable」
と書かれているので、そこで
「あ!、ここでQueryTableオブジェクトを生成してる!」
と分かります。

  

より明確に確認するには、後述のプログラムの
「Dim o_QTItem As QueryTable」
の行を、
「Dim o_QTItem As Object」
に書き換えて、
F8キーのステップ実行しながら、
「o_QTItem 」を
ローカルウィンドウかウォッチウィンドウで確認すればOKです。

「Set o_QTItem = ActiveSheet.ListObjects.Add( _・・・」
のところを実行した瞬間に、
ローカルウィンドウかウォッチウィンドウにて、
「型」の列に、
「Object/QueryTable」
と表示されますので確実です。
  

ちなみにですが、SQLは「クエリの」「接続」を使った場合でも(Power Queryでも???)使えるもようです。
ただ、「M言語」での事前のテーブル定義をするみたいなんですが、それをVBA化するのがとてもめんどくさいです。(後述のサンプルプログラムを見るとわかると思うのですが、事前に列名調べていろいろコネコネしないといけないので・・・)

「QueryTableオブジェクト+SQL+VBA+ODBC接続」や「Microsoft Query」ではそのような面倒くさいことは起こりません。

  

★ 「Microsoft Query」は、無くなるのか?

これはなんともわかりませんが、「QueryTableオブジェクト」が無くならないところを見ると、「Microsoft Query」もなんとなくそれに合わせてしばらくは無くならない気がします。

また、OSの「ODBCデータソース」が無くならない、あるいは、その中で「テキストドライバー」が無くならない限り、同様に、「Microsoft Query」は生き残ってしまうような気もしています。

でも、「QueryTableオブジェクト」よりは、生き残る可能性は低いかもしれません。

理由は、「Microsoft Query」は、例えば32bit版のExcelでなら、
C:\Program Files (x86)\Microsoft Office\Office14\MSQRY32.EXE(2010の場合)
C:\Program Files (x86)\Microsoft Office\root\Office16\MSQRY32.EXE(2019の32場合)
などに位置している、Excelからは独立したソフトウェアなので・・・

2022で無くならなければ当分、無くならないかも?です。

ちなみにですが、SQLは「クエリの」「接続」を使った場合でも(Power Queryでも???)使えるもようです。
ただ、「M言語」での事前のテーブル定義をするみたいなんですが、それをVBA化するのがとてもめんどくさいです。(後述のサンプルプログラムを見るとわかると思うのですが、事前に列名調べていろいろコネコネしないといけないので・・・)

「QueryTableオブジェクト+SQL+VBA+ODBC接続」や「Microsoft Query」ではそのような面倒くさいことは起こりません。

  

★ CSVを吸い込む動作を、Excel2019のマクロの記録で記録し、少し修正したプログラム(QueryTableが無くならなそうな理由がわかる記録マクロ)