Windows 10以降、「ワールドワイド言語サポートでUnicode UTF-8を使用」という設定項目が追加されました。プログラミングの世界ではUTF-8が標準となって久しい現在、この設定は魅力的に映るかもしれません。しかし、VBAユーザーにとって、このチェックボックスは触れてはいけないスイッチです。
今回は、文字エンコーディング（文字コード）に詳しくない方に向けて、なぜVBAユーザーはUTF-8設定を避けるべきなのか、そしてなぜVBAを使い続ける必要があるのかを解説します。
Windowsの「UTF-8を使用」設定とは？
コンピュータは文字を数値として扱います。「あ」という文字をどの数値に対応させるか、そのルールを「文字エンコーディング」と呼びます（一般には「文字コード」とも呼ばれます）。
通常、日本語版のWindowsでは、古いソフトウェアとの互換性を保つために「Shift-JIS」（正式にはCP932、Windowsコードページ932）という文字エンコーディングが標準で使用されています。一方、Web開発や最新のプログラミング言語（PythonやJavaScriptなど）では、世界中の文字を統一的に扱える「UTF-8」が標準です。
Windowsの「ワールドワイド言語サポートでUnicode UTF-8を使用」オプションは、Windows全体をこのUTF-8標準に切り替えるための機能です。UTF-8を標準とするMacとのファイル共有時に文字化けが減るなどのメリットがあり、将来的にはWindowsの標準になると言われています。
VBAユーザーは要注意：この設定をしてはいけない
VBAを使用するパソコンでは、この設定を有効にしてはいけません。
理由は単純です。VBA（Visual Basic for Applications）の開発環境であるVBE（Visual Basic Editor）がUTF-8に対応していないからです。VBAは30年近く前の設計を引き継いでおり、日本語環境ではShift-JISで動くことを前提に作られています。
もしWindowsの設定をUTF-8に切り替えてしまうと、以下のような問題が発生します。
- コード内の日本語が文字化け：変数名やコメント、文字列が解読不能な記号の羅列になります。
- 既存のマクロが動かなくなる：最悪の場合、ファイルが破損したり、VBEが開かなくなったりします。
なお、この設定は正式名称に「ベータ」という語が含まれており（「ベータ：ワールドワイド言語サポートでUnicode UTF-8を使用」）、VBAのような古いアプリでの動作は保証されていません。
VBAがUTF-8に対応する未来はあるか？
「MicrosoftがVBAをアップデートして、UTF-8に対応させればいいのでは？」と思うかもしれません。
しかし、その可能性は低いと私は考えています。VBAの基礎部分は非常に古く、これを現代のUTF-8に対応させるには、根本からの作り直しに近いコストがかかります。Microsoftの現在の注力分野（クラウド、AI、Web）を考えると、レガシーなVBAをUTF-8に対応するための投資が行われるとは考えにくいのが現状です。
Office Scriptへの移行が難しい「本当の理由」
VBAが進化しないなら、後継とされる「Office Script（TypeScript）」に移行すればいい、という話によくなります。Office ScriptならUTF-8に完全対応しており、文字エンコーディングの問題は解決します。
しかし、多くの実務でVBAからOffice Scriptへの完全移行は困難です。それはなぜでしょうか？
よく「ユーザーフォームが作れないから」と言われますが、問題の本質はもっと深いところにあります。
1. Word版のOffice Scriptが存在しない
まず、大前提として知っておくべき事実があります。Office Scriptは現在、実質的にExcel専用の機能であり、Word版は一般公開されていません。
Wordで文書作成の自動化やフォーマット整形のマクロ（VBA）を利用している方は多いと思いますが、これらを移行する先となる技術がそもそも存在しないのです。
Excelのマクロは一部移行できたとしても、Wordのマクロに関しては、VBAを使い続ける以外に選択肢がありません。
2. 問題の本質は「UI（ユーザー・インターフェイス）の操作」
Excel単体で見たとしても、VBAとOffice Scriptには決定的な違いがあります。それは、UIを介して、Excelという「アプリケーション自体」を操作できるかどうかです。
VBAができること：アプリケーション全体を制御できます。
- メニューやリボンから実行できる機能（書式設定、並び替えなど）をコードから直接制御する
- 「検索と置換」や「並び替え」ダイアログボックスを表示し、設定値の取得や指定を行う
- ウィンドウのサイズを変える、アプリを最小化する
Office Scriptができること：ブックの中身（データ）の操作に限定されます。
- セルの値を書き換える
- グラフを作る
- ピボットテーブルを更新する
Office Scriptはあくまで「データの処理」に特化しており、アプリケーション自体のメニューやウィンドウを制御する機能を持っていません。これが、VBAを手放せない最大の理由です。
当面の対応
では、UTF-8化が進む世界で、VBAユーザーはどうすればいいのでしょうか？
私の考えは、「Copilot（AI）の進化を待つ」です。
Web技術をベースにしているOffice Script自体に、VBAのような強力なUI操作機能が付与されることは、セキュリティの観点からも考えにくいでしょう。このため、将来的にはCopilotがVBAの役割を担う可能性があると私は予想しています。（同じように、WordやExcelを外部から操作するPower Automateにも、VBAのような機能が付与されることもないでしょう。）
- 現在：VBAコードを書いて、リボンやダイアログを操作させている。
- 将来：Copilotに「この表を売上順に並び替えて」と指示し、AIがExcelのUIを操作する。
AIがVBAと同じレベルでOfficeアプリのUIを自由に制御できるようになるその日まで、以下の運用が現実的な選択だと考えます。
- WindowsのUTF-8設定はOFFのままにする（VBAを守るため）。
- データ処理中心の新しいタスクは、Office ScriptやPower Automateでの作成を検討する。
- UI操作が必要な既存業務は、引き続きVBAを使う。
「VBAは古い」と言われますが、ExcelやWordというアプリケーションの手足となって動けるのは、今でもVBAだけなのです。
コメント