Excel VBAでカレンダーの予定をUserFormに表示できないときの直し方｜エラー原因の特定・予定表の読み込み・自動表示を解説

Excelで作成したカレンダーや予定表の内容をVBAのUserFormへ表示し、デスクトップ上の予定確認用ウィンドウとして使いたい場合、コードのわずかな違いでコンパイルエラーや実行時エラーが発生することがあります。

この種のトラブルでは、画像だけからコード全体を推測して修正するより、「どの行で止まっているのか」「エラー番号とメッセージは何か」「予定表のどの列をUserFormへ表示したいのか」を順番に確認することが解決への近道です。

ここでは、Excelの予定表から当日または指定日の予定を取得してUserFormへ表示する基本構成と、エラーが起きたときの確認方法を、VBA初心者でも追いやすい形で解説します。

最初に知っておきたい「UserFormをデスクトップに表示」の意味

Excel VBAのUserFormは、Excelから起動されるフォームです。そのため通常の使い方では、Windows単体の独立アプリとして常駐しているわけではなく、Excelのプロセスが動作している間に表示されます。

UserFormは通常、UserForm1.Showのように表示します。ただし標準の表示方法ではモーダル表示となり、フォームを閉じるまでExcel側を操作できません。Excelも操作しながら予定表フォームを出しておきたい場合は、UserForm1.Show vbModelessとする方法があります。

MicrosoftのVBAドキュメントでも、Showメソッドにはモーダルとモードレスの表示方法があり、モードレスの場合はフォームを表示したまま後続処理やExcel側の操作を行えることが説明されています。[参照] Microsoft Learn「Show method」

エラーが出たら「デバッグ」を押して止まった行を確認する

VBAでエラーが出たときに最も重要なのは、エラーダイアログに書かれた番号と説明、そして「デバッグ」を押したあと黄色く表示される行です。

例えば「実行時エラー ‘9’: インデックスが有効範囲にありません」で止まった場合、Worksheets("カレンダー")と書いているのに実際のシート名が「予定表」になっている、といった可能性があります。「実行時エラー ’13’: 型が一致しません」なら、日付として処理しようとしたセルに文字列が入っている、といった原因が考えられます。

「エラーになります」だけでは原因を一つに絞れません。エラー番号・エラーメッセージ・黄色く止まったコード行の3点が、修正に必要な最重要情報です。

まず予定表を単純な構造にするとUserFormへ表示しやすい

カレンダーが見た目重視の月間カレンダー形式になっている場合、そのままVBAで予定を探すとコードが複雑になります。VBA処理用には、1行につき1件の予定を記録する一覧表を用意すると安定します。

例えば「予定表」というシートを作り、A列に日付、B列に開始時刻、C列に予定内容を入れます。

月間カレンダーは表示用、この一覧表はデータ管理用と役割を分ければ、UserFormではA列の日付が今日と一致する行だけを探せばよくなります。

当日の予定をUserFormのTextBoxへ表示する基本例

UserFormに複数行表示できるTextBoxを配置し、そのオブジェクト名をtxtScheduleとした場合、次のような考え方で当日の予定を取得できます。

Private Sub UserForm_Initialize()
    Dim ws As Worksheet
    Dim lastRow As Long
    Dim i As Long
    Dim result As String

    Set ws = ThisWorkbook.Worksheets("予定表")
    lastRow = ws.Cells(ws.Rows.Count, "A").End(xlUp).Row

    For i = 2 To lastRow
        If IsDate(ws.Cells(i, "A").Value) Then
            If DateValue(ws.Cells(i, "A").Value) = Date Then
                result = result & Format(ws.Cells(i, "B").Value, "hh:mm") & "  " & ws.Cells(i, "C").Value & vbCrLf
            End If
        End If
    Next i

    If result = "" Then result = "今日の予定はありません。"
    Me.txtSchedule.Value = result
End Sub

この例ではUserFormが初期化されたタイミングで予定表を調べ、A列の日付が今日と一致した行について、B列の時刻とC列の予定をTextBoxへ追加しています。

実際のブックでは「予定表」というシート名、A・B・C列の位置、txtScheduleというコントロール名を自分の環境に合わせて変更する必要があります。

UserFormを開くコードは標準モジュールへ書く

UserFormを起動する処理は、標準モジュールに分けておくと管理しやすくなります。VBEで「挿入」→「標準モジュール」を選び、例えば次のプロシージャを作成します。

Public Sub ShowSchedule()
    UserForm1.Show vbModeless
End Sub

このShowScheduleを実行すると、UserForm1がモードレスで表示されます。フォーム名を「frmSchedule」などへ変更している場合は、その実際のオブジェクト名を使います。

「UserForm1」という表示上のCaptionと、VBEのプロパティにある(Name)は別物です。コードではCaptionではなく(Name)を指定する点にも注意してください。

よくあるエラー1：シート名が実際の名前と違う

予定表を読み取るVBAで非常に多いのが、Worksheetsに指定したシート名の不一致です。

例えばコードがSet ws = ThisWorkbook.Worksheets("Calendar")となっているのに、Excel上のシート名が「カレンダー」なら、そのシートを取得できません。スペースの有無や全角・半角も含めて一致している必要があります。

またThisWorkbookは「そのVBAコードが保存されているブック」を表します。現在画面で選択している別ブックを意味するActiveWorkbookとは異なるため、複数のExcelファイルを開いている環境では特に区別が重要です。

よくあるエラー2：UserFormの部品名がコードと一致していない

コードにMe.txtSchedule.Valueと書いていても、実際のTextBoxの名前がTextBox1なら一致しません。この場合はVBEでUserFormを開き、対象コントロールのプロパティにある(Name)を確認します。

Labelでも同様で、コードではLabel1.Caption、TextBoxではTextBox1.Valueのように、コントロールによって一般的に使用するプロパティも異なります。

ネット上からコードをコピーした場合は、そのコードを書いた人のUserFormと自分のUserFormで部品名が違う可能性が高いため、「コードだけコピーすれば動く」と考えず、フォーム設計との対応を確認しましょう。

よくあるエラー3：日付に見えても文字列になっている

Excelのセルに「2026/8/30」と表示されていても、それがExcelの日付シリアル値ではなく単なる文字列として保存されている場合があります。その状態で日付計算を行うと、型不一致などの原因になることがあります。

そのため例のコードでは、いきなりDateValueで変換せず、最初にIsDateで日付として解釈可能か確認しています。

また、予定表のセルに日付だけでなく「2026/8/30 9:00」のように時刻まで含まれている場合、単純な= Dateでは一致しないことがあります。その場合にDateValueで日付部分だけを比較する方法が役立ちます。

よくあるエラー4：最終行の取得方法に問題がある

予定の件数が変化する表では、固定で「2行目から100行目」とするより、データが入っている最終行を取得する方法が一般的です。

lastRow = ws.Cells(ws.Rows.Count, "A").End(xlUp).Rowは、A列の最下部から上へたどって最後にデータが存在する行番号を取得する典型的な方法です。

ただしA列の途中や末尾に日付以外のデータがある場合は、その構成に合わせて変更する必要があります。予定をExcelテーブルとして管理している場合は、ListObjectを使った処理にする方法もあります。

エラーを隠す「On Error Resume Next」は最初から使わない

インターネット上のVBAコードでは、エラー対策として冒頭にOn Error Resume Nextが書かれている場合があります。しかし原因調査中に多用すると、どの行で問題が起きたのか分からなくなることがあります。

MicrosoftのVBAドキュメントによると、On Error Resume Nextはエラー発生後に次のステートメントへ処理を進めます。一方、On Error GoToを使えばエラー処理部分へ制御を移せます。[参照] Microsoft Learn「On Error statement」

初心者のデバッグでは、まずエラーを隠さず止めるほうが原因を発見しやすくなります。正常動作を確認した後で、必要な箇所へ適切なエラー処理を追加しましょう。

エラー番号と場所を表示する処理を入れると調査しやすい

実際に使うマクロには、エラー番号と説明を表示する簡単なエラーハンドラーを追加しておくと便利です。

Public Sub ShowSchedule()
    On Error GoTo ErrHandler

    UserForm1.Show vbModeless
    Exit Sub

ErrHandler:
    MsgBox "エラー番号: " & Err.Number & vbCrLf & _
           "内容: " & Err.Description
End Sub

このようにすると、「エラーが出た」という情報だけでなく、VBAが返した具体的な番号と説明を確認できます。

エラー処理を入れた場合でも、開発中はVBEの「ツール」→「オプション」→「全般」にあるエラートラップ設定などにも注意します。デバッグ環境によって止まり方が異なる場合があります。

Excelを開いたときにUserFormを自動表示する方法

予定確認用フォームとして使う場合は、ブックを開いたタイミングでUserFormを自動表示できます。これは標準モジュールではなく、VBEの「ThisWorkbook」に記述します。

Private Sub Workbook_Open()
    UserForm1.Show vbModeless
End Sub

ただし、この処理が動くにはブックがマクロ有効形式で保存され、マクロの実行が許可されている必要があります。通常は.xlsxではVBAを保存できないため、.xlsmなどマクロを保持できる形式を利用します。

また、Excelを完全に終了すれば通常のUserFormも終了します。「WindowsへログインしたらExcelを起動して予定フォームを表示したい」という場合は、Excel VBAだけでなくWindows側のスタートアップなども別途検討する必要があります。

一定時間ごとに予定表示を更新したい場合はApplication.OnTimeを使える

フォームを朝から表示したままにすると、途中で予定表を編集してもUserFormの内容は自動的には更新されません。そのような場合は更新ボタンを用意する方法が最も単純です。

さらに自動更新が必要なら、ExcelのApplication.OnTimeを使って指定時刻に標準モジュールのプロシージャを実行できます。MicrosoftもApplication.OnTimeを「指定した時刻にプロシージャを実行する」メソッドとして公開しています。[参照] Microsoft Learn「Application.OnTime」

ただしApplication.OnTimeで指定するプロシージャには制約があり、引数を持たせることはできず、フォームや独自クラス内のプロシージャを直接指定することもできません。そのため、標準モジュールに更新用のPublic Subを置き、そこからフォームを更新する設計が安全です。

「常に最前面に表示」は通常のUserForm機能とは別

「デスクトップに表示」という希望が「ほかのアプリより常に前面へ出しておきたい」という意味なら、単純なvbModelessだけでは実現できません。モードレスはExcelを操作可能にする設定であり、Windows全体で常に最前面に固定する設定ではないためです。

常に最前面へ固定する実装ではWindows APIを使う例がありますが、32bit版Officeと64bit版Officeで宣言方法が異なり、64bit対応ではPtrSafeやLongPtrを正しく扱う必要があります。API宣言を古いWeb記事からそのままコピーするとコンパイルエラーになることがあります。

まずは通常のUserFormを正常に表示できるところまで完成させ、その後に必要であれば最前面化を追加するほうがトラブルを切り分けやすくなります。

画像でVBAの質問をするときに不足しやすい情報

長いコードを画像にして質問すると、回答者が文字を検索・コピーできず、全角スペース、引用符、ピリオド、似た変数名などの細かな違いも確認しづらくなります。コード全体が長い場合でも、少なくともエラーで停止するプロシージャはテキストとして提示したほうが原因を特定しやすくなります。

特に必要なのは、エラー番号、エラーメッセージ全文、「デバッグ」を押して黄色くなる行、そのプロシージャのコード、UserForm上のコントロール名、予定表シートの列構成です。

例えば「実行時エラー9、Set ws = Worksheets("予定表")で停止。シート名はCalendarです」と分かれば、シート名の不一致という原因をすぐ確認できます。画像1枚だけの場合より格段に解決しやすくなります。

おすすめのトラブル解決順序

複雑なカレンダーマクロを一度に直そうとせず、次のように機能を分解して確認すると原因を絞り込めます。

特に大切なのは、UserForm表示・予定取得・自動更新・最前面化を最初から1本の巨大なコードにしないことです。それぞれを単体で動かしてから組み合わせれば、どの段階でエラーが発生したのか明確になります。

まとめ：UserFormのエラーは「止まった行」から順番に切り分ける

Excelのカレンダーで作成した予定をUserFormへ表示する仕組みは、VBAで実現できます。Excelを操作しながらフォームを表示するならUserForm1.Show vbModelessを利用し、予定データは日付・時刻・予定内容を1行ずつ持つ一覧表にしておくと処理しやすくなります。

一方、実際に表示されるエラーの画像やコードがなければ、「どこを1行直せば解決するか」までは特定できません。エラー番号とメッセージを控え、「デバッグ」で黄色になる行を確認することが最優先です。

そのうえで、シート名、UserFormやTextBoxのオブジェクト名、日付のデータ型、最終行の取得方法を確認します。まず単純なUserForm表示と当日予定の取得だけを完成させ、Workbook_Openによる自動起動、Application.OnTimeによる更新、Windows APIによる最前面表示などは後から追加するのが安全です。

複雑なコードほど、エラーを隠すのではなく「どこまで正常に動いているか」を小さな単位で確認することが、最短の解決方法になります。