【Excel VBA】DataObjectの「クリップボード参照エラー」対策!MSFormsを使わない代替実装案

Microsoft Forms 2.0 Object Libraryへの参照設定を外し、レイトバインディング(遅延結合)で動作させる: 特定の環境で発生する「オブジェクトライブラリが登録されていません」というエラーを回避するため、事前に参照設定を行わず、プログラム実行時に動的にオブジェクトを生成する手法に切り替えます。

MSHTML(HTMLDocument)をクリップボードの代替コンテナとして活用する: MSFormsを使用せずに、Windowsの標準コンポーネントであるHTMLDocumentオブジェクトの命令(parentWindow.clipboardData)を利用して、文字列のコピーと貼り付けを安定的に実行します。

Windows APIを直接呼び出し、OSレベルでクリップボードを操作する: DLL(user32.dll、kernel32.dll)の関数を宣言し、メモリの確保からクリップボードのオープン、データの転送までをVBAから制御することで、Officeの構成に依存しない最強の互換性を確保します。

1. DataObjectが引き起こす「参照設定の呪い」と実行時エラーの正体

VBAでクリップボードに文字列を送る際、最も一般的なのが New DataObject を使用する方法です。しかし、この手法は「Microsoft Forms 2.0 Object Library (FM20.DLL)」への参照設定が必須であり、これが実務の現場では深刻なトラブルの種となります。

開発者のPCでは正常に動いても、他人のPCで実行した瞬間に「参照不可」としてコードが止まってしまうことが多々あります。これは、PCにOutlookがインストールされていない、あるいはOfficeのビット数(32/64bit)の混在によってレジストリ情報が書き換わっていることが原因です。特に「オートメーションエラー」や「ライブラリが登録されていません」といった不透明なエラーメッセージは、ユーザーの信頼を大きく損ないます。本稿では、この「参照設定の呪い」から解放され、どのPCでも誠実に動作するクリップボード操作の代替案を詳説します。

2. 手順①:最も手軽な「MSHTML」を利用したテキストコピー

特別な参照設定を一切行わず、かつ短いコードで実装できるのが、Internet Explorerのコンポーネント(現在はWindowsの標準機能として残存)を利用する方法です。

Sub CopyToClipboard_MSHTML(ByVal txt As String)
    With CreateObject("htmlfile")
        .ParentWindow.ClipboardData.SetData "text", txt
    End With
End Sub

技術的洞察: この手法は htmlfile オブジェクト(MSHTML.dll)をレイトバインディングで呼び出しています。MSForms.DataObjectのような専用のライブラリ登録を必要とせず、文字列をクリップボードの「Text」形式としてセットできます。ただし、近年のWindowsセキュリティ更新により、ブラウザのセキュリティゾーン設定によっては動作が制限される場合があるため、社内インフラのポリシーを確認した上で導入してください。

3. 手順②:ダミーUserFormによる「FM20.DLL」の自動参照トリック

どうしても DataObject の使い勝手を優先したい場合、誠実な「ハック」として知られるのが、プロジェクトに中身が空の 「UserForm」 を1つだけ追加しておく方法です。

1. VBE(Visual Basic Editor)の 「挿入」 メニューから 「ユーザーフォーム」 をクリックします。
2. 作成された「UserForm1」には何も配置せず、そのまま放置します。
3. これで、Excelが自動的に Microsoft Forms 2.0 Object Library へのパスを通し、参照不可の状態を回避できるようになります。

この手法のデメリットは、ファイルサイズがわずかに増加することと、プロジェクト内に不要なフォームが存在することでコードの純粋性が失われる点です。個人開発であれば問題ありませんが、納品物や共有ツールとしては、次に解説するAPI方式が最もプロフェッショナルな選択となります。

4. 手順③:Windows APIによる「Office非依存」の最強実装

Officeのバージョンやインストール状況に一切左右されない、極めて堅牢な方法がWindows APIの直接呼び出しです。コードは長くなりますが、一度モジュール化してしまえば最強の武器になります。

' 標準モジュールの先頭に記述(64bit/32bit両対応)
#If VBA7 Then
    Private Declare PtrSafe Function OpenClipboard Lib "user32" (ByVal hwnd As LongPtr) As Long
    Private Declare PtrSafe Function EmptyClipboard Lib "user32" () As Long
    Private Declare PtrSafe Function CloseClipboard Lib "user32" () As Long
    Private Declare PtrSafe Function SetClipboardData Lib "user32" (ByVal wFormat As Long, ByVal hMem As LongPtr) As LongPtr
    Private Declare PtrSafe Function GlobalAlloc Lib "kernel32" (ByVal wFlags As Long, ByVal dwBytes As LongPtr) As LongPtr
    Private Declare PtrSafe Function GlobalLock Lib "kernel32" (ByVal hMem As LongPtr) As LongPtr
    Private Declare PtrSafe Function GlobalUnlock Lib "kernel32" (ByVal hMem As LongPtr) As Long
    Private Declare PtrSafe Sub MoveMemory Lib "kernel32" Alias "RtlMoveMemory" (dest As Any, src As Any, ByVal Length As LongPtr)
#Else
    ' (32bit用のDeclare文をここに記述。現代ではVBA7用のみでも概ねカバー可能)
#End If

Sub SetTextToClipboard(ByVal sText As String)
    Dim hMem As LongPtr, pMem As LongPtr
    Dim sUTF16 As String
    sUTF16 = StrConv(sText, vbUnicode) ' 文字コード調整
    
    If OpenClipboard(0) Then
        EmptyClipboard
        hMem = GlobalAlloc(&H42, LenB(sText) + 2)
        pMem = GlobalLock(hMem)
        MoveMemory ByVal pMem, ByVal StrPtr(sText), LenB(sText) + 2
        GlobalUnlock hMem
        SetClipboardData 13, hMem ' 13 = CF_UNICODETEXT
        CloseClipboard
    End If
End Sub

技術的解説: このコードは、Windowsの共有メモリ空間に文字列を直接書き込み、それをクリップボードのハンドル(CF_UNICODETEXT)に渡しています。DataObjectが内部で行っている処理をすべて手動で再現しているため、参照設定の有無に一切関係なく動作します。まさに「超解決」にふさわしい、OSレベルでの解決策です。

5. 比較:クリップボード操作手法の安定性と難易度

手法	参照設定	互換性	実装の重さ
DataObject (New)	必須	低(他PCでエラー多発)	極小
ダミーUserForm	自動追加	中(参照不可は防げる)	小
MSHTML (htmlfile)	不要	中(セキュリティ設定に依存)	小
Windows API	不要	最高(OS標準機能のみ)	大(記述量が多い)

6. 実務での選択:どの方法を「誠実な解」とするべきか

クリップボード操作は一見シンプルですが、環境依存の罠が最も多い領域です。プロフェッショナルな実務家としてのアドバイスは以下の通りです。

• 小規模な自社ツールなら: ダミーのUserFormを1つ入れて、DataObjectの恩恵に預かるのが開発スピード面で誠実な判断です。
• 多人数への配布、納品物なら: 面倒でもWindows APIのコードを1つの「モジュール」として用意し、それを使い回すべきです。ユーザーの手元で「ライブラリが見つかりません」という初歩的なエラーを出すことは、開発者の専門性を疑われる原因になります。
• 軽量なスクリプトなら: MSHTMLを利用した手法が、最もスマートにコードの見た目を保つことができます。

まとめ:ライブラリに依存しない「自立したコード」を目指して

VBA開発において、特定のライブラリ(参照設定)に依存することは、将来的なOfficeのアップデートや環境の変化に対して脆弱性を受け入れることを意味します。DataObjectのエラーは、まさにその依存関係が破綻した時に発生する警報です。

今回紹介したAPI方式やMSHTML方式は、ライブラリの管理という「人間の管理コスト」を、「コードの堅牢性」という技術的解決に置き換えるものです。道具が提供する便利な機能の裏側を理解し、いざという時にOSの基本機能(API)まで遡って制御を奪還できること。この深みのある知識こそが、Excelという広大なプラットフォーム上で、誰にでも・どこでも・安定して動く「誠実なツール」を生み出すための唯一の道です。DataObjectの不具合を単なるエラーとして嘆くのではなく、より堅牢な実装へと昇華させるきっかけとして、自身のライブラリをアップデートしてください。

📊

Excelトラブル完全解決データベース この記事以外にも、100項目以上のエラー解決策をまとめています。困った時の逆引きに活用してください。