「エラーでマクロが途中で止まらなくなって便利！」と気軽に使いがちですが、実はこれ、使い方を誤ると「重大なバグを隠蔽してデバッグ不可能にする」という最大の事故原因になります。

この記事では、On Error Resume Next が持つ危険性と、それを安全に制御するためのペアとなる命令 On Error GoTo 0 の関係性、そしてバグを生ませない正しい書き方を解説します。

1. On Error Resume Next とは？（危険な「居眠り運転」モード）

On Error Resume Next は、コードの実行中にエラーが発生してもマクロを停止させず、「そのまま無視して次の行の処理に進め」という命令です。

ファイルを開く処理や、特定のオブジェクトが存在するかチェックする処理など、「エラーが起きる可能性を想定して安全にスルーしたい場面」で非常に重宝します。

しかし、一度この命令を実行すると、プロシージャ（SubやFunction）が終わるまでVBA全体が「どんなエラーが起きても一切知らせてくれない居眠り運転モード」になってしまいます。

2. なぜ「On Error GoTo 0」がないとヤバいのか？（バグ隠蔽の恐怖）

On Error Resume Next を書いたあと、解除せずに放置すると何が起きるでしょうか？

例えば、後続のコードで変数名のスペルミス（タイポ）をしたり、ゼロ割り計算が発生したりしても、VBAはエラーメッセージを出さずに黙ってその行をスキップします。

このように、「本当はエラーを出して教えてほしいバグ」まで隠蔽されてしまい、不具合の原因追求（デバッグ）が極めて困難になります。

3. バグを出さない！「ピンポイント挟み」の設計パターン

バグを出さないための鉄則は、「エラーを無視させたい最小限の範囲（1〜2行）だけを挟み込み、すぐに解除する」ことです。ここで登場するのが On Error GoTo 0 です。

On Error GoTo 0 は、VBAのエラー無視モードを強制終了し、「通常の安全状態（エラーが起きたら黄色い画面で知らせる状態）」にリセットする命令です。

【正しいコードの書き方例】

4. まとめ

• On Error Resume Next は、エラーを無かったことにする魔法ではなく「一時的な判定用ツール」。
• 解除せずに放置すると、後続コードのバグやタイポが隠蔽され、デバッグ地獄に陥る。
• 危険な処理を通過させたら、直後に必ず On Error GoTo 0 を書いて通常状態に戻す。

「On Error Resume Next を書いたら、セットで On Error GoTo 0 を書く」。この基本を守るだけで、VBAコードの安全性と信頼性は劇的に向上します！

開発初期や自分1人で使う分にはこれで問題なく動きますが、いざ運用を開始してしばらく経つと、ある「絶望的な問題」にぶち当たることになります。

この記事では、VBAで本格的なアプリを作る際に、なぜ「プログラム本体（画面・処理）」と「データ」を分離するべきなのか、その理由と実務で使える構成パターンを解説します。

1. 「一体型（1ファイル）」が抱える運用上の罠

1つのExcelファイルにすべてを詰め込む「一体型」で開発・運用を続けると、次のようなトラブルが発生します。

• バージョンアップ時の「データ移行地獄」：機能追加やバグ修正をした新しいファイル（v1.1.xlsm）を配布する際、ユーザーが旧ファイル（v1.0.xlsm）に入力した大量のデータを新しいファイルへ手動で移し替えなければならなくなります。
• ファイル破損によるデータ全喪失リスク：Excelマクロは、長年運用してデータ量が肥大化したり処理を重ねたりすると、ファイル自体が破損して開かなくなるリスクが少なからずあります。一体型だと、プログラムだけでなく貴重な蓄積データまで一緒に消えてしまいます。
• 複数人で使えない：1つのファイルを誰かが開いていると「読み取り専用」になり、他の人がデータを更新できなくなります。

2. プログラムとデータを分離する（データ分離）のメリット

プログラム（UserFormや標準モジュール）を置く「Appファイル」と、蓄積データを保存する「Dataファイル」を明確に分けることで、これらの問題が一気に解決します。

• アップデートが「ファイルの差し替え」だけで完結する
  データ側は一切触らず、プログラム側のファイル（App.xlsm）だけを最新版に差し替えれば、ユーザーのデータを1件も移行させることなく一瞬でバージョンアップが完了します。
• データ保護と堅牢性の向上
  万が一VBAの処理中にクラッシュしたりプログラムファイルが壊れたりしても、データファイルは別にあるため安全です。バックアップや復旧も容易になります。
• 将来的な機能拡張（DB化・複数人利用）がスムーズ
  データアクセス部分が独立しているため、将来的にデータ保存先をExcelからAccess（データベース）やクラウドへ移行したくなった場合でも、プログラム側の最小限の修正で対応できます。

3. 実務で使われる「データ分離」の3つの構成パターン

分離型アプリを作る際、実務では用途や規模に合わせて主に以下の3パターンが使われます。

4. まとめ

• 「使い捨ての簡易ツール」や「1回きりのデータ整形」なら、一体型（1ファイル）でも問題ない。
• 「日々データを蓄積する」「機能を追加・修正していく」「他人に配って使わせる」アプリなら、最初から「プログラム」と「データ」を分離する設計が鉄則。

VBA開発で「保守性の高いコード」を書く第一歩は、プログラミング言語の書き方だけでなく、こうしたファイル構成（アーキテクチャ）の設計から始まります。長期間安心して使えるVBAアプリを目指して、ぜひデータ分離設計を取り入れてみてください！

このコード自体は「ボタンが押されたときにメッセージを表示する」というシンプルなものですが、ここにデータ処理や集計などのロジックまで何でもかんでも書き込んでしまうのは、保守性や安全性の観点から大きなNGです。

この記事では、UserFormモジュールとはそもそも何者なのか、そして「なぜビジネスロジックをここに書いてはいけないのか（連打防止とモジュール分離の設計）」を解説します。

1. UserFormモジュールとは？（標準モジュールとの違い）

VBAのプロジェクトエクスプローラを開くと、通常の「標準モジュール（Module1など）」のほかに、フォームに対応した「UserFormモジュール（UserForm1など）」が存在します。

• 標準モジュール：どこからでも呼び出せる汎用的なマクロや関数（プロシージャ）を置く場所。
• UserFormモジュール：画面上のコントロール（ボタンやテキストボックス等）のイベント（ボタンが押された、入力値が変わったなど）を受け取り、UIを描画・操作する特別な場所。

冒頭の BtnStart_Click も、フォーム上のボタンが押された瞬間に自動で発火するイベントプロシージャの一つです。

2. 「ここに書きすぎてはダメ！」な理由とビジネスロジックの分離

イベントを簡単に拾えるからといって、UserFormモジュールの中にデータの加工、ファイルの読み書き、複雑な計算といったビジネスロジック（処理の本質）を直接書き込んでしまうのはNGです。

理由は主に以下の通りです。

• コードが肥大化・複雑化する：1つのフォームモジュールに何百行ものデータ処理が詰まり、「あの処理はどこに書いてあったっけ？」と迷子になります。
• 再利用性が極めて低い：フォームモジュール内のコードは原則そのフォームに紐づいているため、ショートカットキーや他のシートから同じ処理を実行したくなったときに流用できません。
• 二重実行（連打）対策が漏れやすい：画面のボタンを無効化するだけでは、キーボードショートカットや外部からの直接呼び出しによる割り込み実行を防ぎきれません。

3. 「画面制御と処理」を分ける設計思想

保守性と安全性の高いプログラミングを目指すなら、UserFormモジュールは画面操作（UI制御）に特化させ、実際の処理は標準モジュールへ任せるのがベストプラクティスです。

UserFormの役割は、あくまで**「UI側の連打防止を行い、ユーザーの操作を受け取って、標準モジュール側にあるメイン処理へバトンを渡すこと」**だけに留めましょう。

【正しいコードの書き方の例】

① UserFormモジュール側（受付・UI制御のみ）

② 標準モジュール側（ビジネスロジックと二重実行ガードを記述）

4. まとめ

• UserFormモジュールは、画面の表示制御や連打防止（Enabled = False など）を行う窓口として割り切って使う。
• 実際の計算やデータ処理などのビジネスロジックは標準モジュールに分離（カプセル化）する。
• 標準モジュール側にも実行フラグ（Static 変数）を仕込むことで、UIを経由しない二重起動も完璧に防御できる。

「フォームのボタンイベントだから全部ここに書いちゃえ」とコードを詰め込むと、後で機能拡張や不具合対応をするときに苦労することになります。役割をすっきり分けて、美しく堅牢なVBAコードを保ちましょう！

この記事では、「戻り値」と「事後条件」の明確な違いから、DbCの考え方を取り入れた推奨コメントテンプレート、さらに事前条件をコードで強制する実践的なテクニックまでを解説します。

1. 「戻り値」と「事後条件」の違い

Excel VBAにおいては、戻り値（出力）と事後条件を以下の理由から明確に区別して考える必要があります。

• 戻り値 (Return Value): プロシージャが計算・処理した結果として呼び出し元へ返す「値」のこと。（Functionプロシージャのみ）
• 事後条件 (Postconditions): プロシージャが正常終了した時点で、「システム（またはオブジェクト）がどのような状態になっていることを保証するか」という約束です。

2. 契約による設計を取り入れた推奨フォーマット

前回のフォーマットの「前提条件・依存関係」と「出力」部分を、DbCの概念である Requires（事前条件） と Ensures（事後条件） に再構築した、より堅牢なコメントテンプレートです。

3. 実践における DbCコメントのメリット

この書き方をチームで徹底すると、保守や引き継ぎにおいて以下のような絶大なメリットがあります。

• 責任の切り分けが明確になる：エラーが起きた際、「事前条件を満たさずに呼び出した側（親）」が悪いのか、「事後条件を満たせなかった側（子）」の実装が悪いのか、責任の所在（契約違反者）が瞬時に判明します。
• ブラックボックスでも安全に使える：「事前条件」さえ整えて呼び出せば、「事後条件」の状態になることが約束されているため、中の複雑なコード（処理内容）を一切読まなくても、安全にそのプロシージャを再利用できます。

このように、コメントに書いた「事前条件」「事後条件」を意識することで、VBAのコードの品質は他のモダン言語に匹敵するレベルまで引き上げることが可能です。ぜひ毎日の開発に取り入れてみてください！

VBAでファイルの最終更新日時を取得する方法としては FileSystemObject (FSO) を使う方法が有名ですが、実は組み込み関数の FileDateTime を使うと、よりシンプルで手軽に取得できます。

この記事では、FileDateTime 関数の基本的な使い方から、実務で必須となる「エラー対策」を施した関数、そして実際にローカルファイル（C:\temp）から取得した実行結果までをご紹介します。

1. 実装コード（関数 ＆ テストコード）

安全にファイル存在チェックを行い、タイムスタンプを返す汎用関数と、動作確認用のテストプロシージャです。これを標準モジュールに貼り付けて使用します。

2. イミディエイトウィンドウの実行結果

実際に C:\temp\test.txt を用意して Test_GetFileTimestamp を実行したところ、次のように正確な更新日時が取得できました。

3. このコードのポイントと注意点

• FileDateTime関数の手軽さ：オブジェクトの生成（CreateObject）が不要なため、VBAの標準機能だけで非常にスッキリ記述できます。
• 必ず存在チェックを入れること：FileDateTime は、指定したファイルが存在しない場合に実行時エラー（強制終了）になります。そのため、事前に Dir 関数で存在確認を行うか、エラーハンドラを用意するのが実務では必須です。
• ローカルパスが必須：OneDriveのWebURL（https://...）などのクラウドパスは直接指定できません。必ず C:\... のようなローカルの物理パスに落とし込んで使用してください。

「古いログファイルを自動で掃除したい」「特定のデータファイルが新しく更新されているかチェックしたい」といった場面で非常に役立ちますので、ぜひ活用してみてください！

セル範囲（Range）であれば RemoveDuplicates メソッドが使えますが、メモリ上の配列（Array）を処理するには少し工夫が必要です。

この記事では、高速かつシンプルに配列の重複を削除できる Scripting.Dictionary を使った汎用関数と、その実装コード・実行結果をご紹介します。

1. サンプルコード（重複削除関数 ＆ テストコード）

文字列や数値が混在するVariant型の1次元配列を受け取り、重複を排除した新しい配列を返す関数と、動作確認用のテストプロシージャです。これを標準モジュールに貼り付けて使用します。

2. イミディエイトウィンドウの実行結果

上記の Test_RemoveDuplicates を実行すると、イミディエイトウィンドウに次のように出力されます。

3. このコードのポイント

• Dictionaryの活用：Scripting.Dictionary の「キー（Key）の重複を許さない」という特性を利用することで、ループで一つずつチェックしながら高速に一意な値を抽出しています。
• dict.Keys の利用：Dictionaryに登録されたキーの一覧は、そのまま dict.Keys プロパティで0ベースの1次元配列として取得できるため、非常にスマートに記述できます。
• 幅広いデータ型に対応：Variant 型で受け取っているため、文字列だけでなく数値配列の重複削除にもそのまま流用可能です。

配列のデータを整理・集計したいときは、ぜひこの関数を標準モジュールに組み込んで活用してみてください！

将来的に、こうしたVBAのコーディングルール違反を自動でチェックしてくれる「ローカルRAG（検索拡張生成）システム」を作りたい！と考えた筆者は、社外にコードを漏らさず完全オフラインで動かせるローカルLLM環境を構築することにしました。

この記事では、その第一歩として、Mac（Apple Silicon）環境にローカルLLM実行アプリ「LM Studio」を導入し、最適なモデルをセットアップする手順を実際の体験ベースで解説します。

1. なぜローカルLLM（LM Studio）を選ぶのか？

業務で扱うVBAコードや社内独自のコーディングルールは、セキュリティの観点から外部のクラウドAIにそのまま送信するわけにはいきません。そこで注目したのが、手元のPC内で安全にAIを動かせるツール「LM Studio」です。

• 完全オフライン・安全：外部サーバーへデータを送信しないため、機密性の高いコードやルールも安心して扱えます。
• Apple Siliconへの最適化：MacのユニファイドメモリやGPUを活用し、Mシリーズ Mac上で非常に高速な推論が可能です。
• APIサーバー化が容易：ワンクリックで「OpenAI互換のAPIエンドポイント」を起動できるため、将来的にPythonと連携したRAGシステムに組み込みやすいのが最大のメリットです。

2. Macへのインストール手順

まずはLM StudioをMacにインストールします。対応OS（macOS 11.0以降のApple Silicon搭載機）を確認の上、以下のステップを進めます。

• 手順1: ダウンロード
  公式サイト（lmstudio.ai）にアクセスし、「Download Mac (Apple Silicon / M-series)」をクリックして .dmg インストーラーを入手します。
• 手順2: アプリケーションの配置
  ダウンロードしたファイルを開き、LM Studio アイコンを Applications（アプリケーション） フォルダへドラッグ＆ドロップして起動します。（※セキュリティ警告が出た場合は右クリックして「開く」を選択）

3. 最適なモデルの選定とセットアップ

プログラムのコード解釈や日本語の指示出しに非常に強いオープンソースモデル**「Qwen2.5-7B-Instruct-1M」**をダウンロードしてセットアップします。

• モデルの検索とダウンロード
  アプリ起動後、左側メニュー等の検索画面から Qwen2.5-7B-Instruct-1M を検索し、ファイル一覧の中から qwen2.5-7b-instruct-1m-q4_0（または Q4_K_M などの量子化バージョン）を選んで「Download」を押します。
• モデルのロードと動作テスト
  ダウンロード完了後、モデルを選択して読み込ませ、チャット画面で動作テストを行います。

実際にチャットで質問テストを行った際のやり取りがこちらです。

【実際のチャットテスト例】

ここで「あれ、Qwenって答えないな？」と少し驚くかもしれませんが、これはチャット画面上でアプリ側が裏で「あなたはLM Studio内で動くアシスタントです…」というシステムプロンプトを自動付加している仕様のためです。今後PythonからAPI経由で直接叩く際は、この挙動は消えてQwen本来の賢い応答になります。

また、ロード直後や最初の1回目は、メモリ展開やウォームアップ（最初の1文字が出るまでの待機時間）の計算が入るため、数秒〜十数秒ほど時間がかかる点も覚えておくと慌てずに済みます（2回目以降はスムーズに高速出力されます）。

4. まとめ

• VBAのコーディングルールチェック用RAGを見据え、安全かつ強力なローカルLLM環境（LM Studio ＋ Qwen2.5-7B）をMac上に構築した。
• アプリの「Discover」から Qwen2.5-7B-Instruct-1M（qwen2.5-7b-instruct-1m-q4_0）をダウンロードしてロードするだけで、手元にAI環境が整う。
• チャット画面特有のシステムプロンプトや初回ロード時の挙動にさえ慣れてしまえば、次はPythonと連携させたAPI自動化へスムーズに進むことができる。

次回は、このローカルLLMサーバーに対してPythonからリクエストを送り、VBAのルールチェックを自動化する実験（RAGの土台作り）に挑戦します。お楽しみに！

このコード自体は「シートがアクティブになったときにイミディエイトウィンドウに文字を出力する」という非常にシンプルなものですが、ここに何でもかんでも書き込んでしまうのは、保守性の観点から大きなNGです。

この記事では、Worksheetモジュールとはそもそも何者なのか、そして「なぜビジネスロジックをここに書いてはいけないのか（Viewとしての役割分担）」を解説します。

1. Worksheetモジュールとは？（標準モジュールとの違い）

VBAのプロジェクトエクスプローラを開くと、通常の「標準モジュール（Module1など）」のほかに、各シート（Sheet1 (Sheet1) など）に対応した「シートモジュール（Worksheetモジュール）」が存在します。

• 標準モジュール：どこからでも呼び出せる汎用的なマクロや関数（プロシージャ）を置く場所。
• Worksheetモジュール：そのシート固有のイベント（セルが変更された、選択範囲が変わった、シートがアクティブになったなど）をフックして、自動実行させるコードを置く特別な場所。

冒頭の Worksheet_Activate も、シートが選択された瞬間に自動で発火するイベントプロシージャの一つです。

2. 「ここに書きすぎてはダメ！」な理由とビジネスロジックの分離

イベントを簡単に拾えるからといって、Worksheetモジュールの中にシートの判定処理、データの集計、データベースや外部ファイルとの連携といった複雑なビジネスロジック（処理の本質）を直接書き込んでしまうのはNGです。

理由は主に以下の通りです。

• コードが迷子になる：「あの処理はどこに書いてあったっけ？」となったとき、標準モジュールを探せばいいのか、特定のシートモジュールを探せばいいのか分からなくなります。
• 再利用性が低い：シートモジュール内のコードは、基本的に「そのシート」に紐づいているため、他のシートや別のブックから流用することが極めて困難になります。
• デバッグや保守がしんどくなる：イベントドリブンで勝手に発火するため、意図しないタイミングでロジックが走り、不具合の原因追跡（デバッグ）が難しくなります。

3. 「ここはView（表示・受付）だけよ」という設計思想

ソフトウェア設計の世界（MVCモデルなど）に倣うなら、Excel VBAのシートモジュールは「View（UI・画面の窓口）」として扱うのがベストプラクティスです。

シートモジュールの役割は、あくまで**「ユーザーの操作（イベント）を受け付け、標準モジュール側にあるメインの処理へバトンを渡すこと」**だけに留めましょう。

【正しいコードの書き方の例】

① シートモジュール側（Viewとしての受付のみ）

② 標準モジュール側（ビジネスロジックを記述）

4. まとめ

• Worksheetモジュールは、シート独自のイベント（Worksheet_Activate など）を受け取るための「View（窓口）」として割り切って使う。
• 実際の計算やデータ処理などのビジネスロジックは標準モジュールに分離（カプセル化）する。
• シートモジュールから標準モジュールを呼ぶ際は、Me キーワードなどを渡すことで柔軟に連携できる。

「シートのイベントだから全部ここに書いちゃえ」とコードを詰め込むと、後でメンテナンスに苦労することになります。役割をすっきり分けて、きれいなVBAコードを保ちましょう！

この記事では、イミディエイトウィンドウの実行結果をもとに、VBAにおける「浮動小数点数の誤差のなぞ」と、それを解決する「通貨型（Currency）」の秘密、そして実務における使い分けの基準を分かりやすく解説します。

1. イミディエイトウィンドウの実験結果

まずは、VBAのイミディエイトウィンドウで次のような引き算の評価式を実行した結果を見てみましょう。

なぜ 1.1 - 1.0 の結果が 0.1 と一致しないのでしょうか？その理由は、コンピュータが小数を扱うときに使用する「浮動小数点数（Double型など）」の仕組みにあります。

コンピュータは内部で数値をすべて「2進数」で表現しています。「1.1」や「1.0」といった小数は、2進数に変換すると無限小数になってしまい、正確に表現できません。その結果、ごくわずかな丸め誤差（端数）が発生し、1.1 - 1.0 の計算結果は厳密には 0.09999999999999988 のような値になってしまいます。そのため、0.1 と比較したときに一致せず False になってしまいます。

2. 通貨型（Currency）の「@」が持つ秘密

では、2つ目の式にある 1.1@ - 1.0@ = 0.1@ が True になるのはなぜでしょうか？

ここで使われている @ は、VBAで「通貨型（Currency型）」の数値リテラルであることを明示する型文字です。通貨型には次のような強力な特徴があります。

• 固定小数点数での演算：浮動小数点数のような「2進数による丸め誤差」が発生しません。
• 小数点以下4桁までの精度：内部的には整数として扱われ（10,000倍した整数で計算）、小数点以下4桁までの正確な計算を保証します。
• 金額や端数計算に最適：消費税の計算や、わずかなズレも許されない厳密な引き算・足し算のために用意されています。

数値の末尾に @ をつけることで、VBAはこれをDouble型ではなくCurrency型として正確に計算するため、誤差が生じずピッタリ一致して True になります。

3. VBAコードでの実装例

実際のVBAコードで、通貨型と通常の浮動小数点数（Double型）の挙動の違いを確認してみましょう。

4. 通貨型（Currency）と 倍精度浮動小数点型（Double）の使い分け

万能に見える通貨型ですが、どのような場面でもCurrencyを使えばいいというわけではありません。以下の基準を目安に使い分けましょう。

【通貨型（Currency）を使うべきケース】

• お金や金額・税金の計算をするとき（1円たりともズレが許されない業務システムなど）
• 小数点以下の桁数が固定されており、厳密な一致判定（=）を行いたいとき
• ※扱える範囲は「整数部が最大15桁、小数部が4桁まで」となります。

【倍精度浮動小数点型（Double）を使うべきケース】

• 科学技術計算や統計・物理演算など、非常に大きな数値や小さな数値を扱うとき（例: 1.23e-10 のような指数表現が必要な場合）
• 小数点以下が5桁以上ある細かい数値を扱うとき（Currency型では小数点以下5桁目以降が四捨五入されて切り捨てられてしまうため）
• マクロ内で単純な四則演算や平均値・割合などを出すだけで、厳密なイコール判定をしないとき

5. まとめ

• 通常、VBAの数値リテラルは何も指定しないとDouble型になり、小数の計算などでわずかな丸め誤差が発生する。
• 金額計算や、厳密な小数の比較が必要な場面では、末尾に @ をつけるか、変数に Currency型 を明示する。
• 小数第5位より細かい値や科学的な計算を扱う場合は、従来通り Double型 を選ぶ。

「なぜか小数の計算結果が微妙にズレてしまう…」とお悩みのときは、データの性質に合わせて通貨型（Currency）や型文字 @ の活用を検討してみてください！

この記事では、WorksheetFunction.Max を使う際のデータ型に関する注意点（仕様）と、予期せぬエラーを防ぐためのエラー処理、さらに安全に最大値を求めるループ処理の実装コードを解説します。

1. WorksheetFunction.Max を使う際の注意点（仕様の解説）

WorksheetFunction.Max は非常に便利ですが、「何を引数に渡すか」によって、数値以外のデータ（文字列や論理値など）が含まれていた場合の挙動が変わります。特に「セル範囲」を渡す場合と、「VBAの配列」を直接渡す場合で違いがあるため注意が必要です。

【比較対象となるデータ型の挙動まとめ】

• 数値：セル範囲＝計算される ／ VBA配列＝計算される
• 日付 (Date)：セル範囲＝計算される（シリアル値） ／ VBA配列＝計算される（シリアル値）
• 論理値 (Boolean)：セル範囲＝無視される ／ VBA配列＝計算される（True=1, False=0）
• 数値化できる文字列 (例: "100")：セル範囲＝無視される ／ VBA配列＝計算される（自動で数値化）
• 数値化できない文字列 (例: "abc")：セル範囲＝無視される ／ VBA配列＝エラーになる（実行時エラー1004等）

このように、VBAの配列を直接 WorksheetFunction.Max に渡すと、数値に変換できない文字列が混ざっていた瞬間にエラーで処理が止まってしまいます。そのため、実務で使用する際はエラー処理（エラートラップ）が必須となります。

2. 実践コード①：WorksheetFunctionを使ったコード（エラー処理付き）

配列内に計算不ような文字列（"abc"など）が混ざっていた場合に備え、On Error GoTo ステートメントを使ってエラーを検知するコードです。

【ポイント】
コードをシンプルに保ちたい場合におすすめです。ただし、エラーになった場合は「最大値が分からない」状態で処理が終わってしまうという弱点があります。

3. 実践コード②：ループ処理を使ったコード（安全・汎用型）

配列内に文字列が混ざっていてもエラーで止めず、「数値として扱えるものだけを拾って最大値を見つける」という柔軟な処理をしたい場合は、ループ処理（For ～ Next）と IsNumeric 関数を組み合わせるのがベストです。Excel以外の環境（AccessやWordのVBA）でも動作します。

【ポイント】
IsNumeric 関数を使うことで、実行時エラーを未然に防ぎながら安全に比較を行います。業務システムなど、予期せぬデータが混入する可能性がある配列を処理する場合に非常に強力です。

4. まとめ

• 手軽に書きたい・配列に数値しか入らないと確信できる場合
  ⇒ WorksheetFunction.Max ＋ 念のためのエラー処理（On Error）
• 文字列などが混ざる可能性があり、安全に数値だけを比較したい場合
  ⇒ ループ処理 ＋ IsNumeric 関数での判定

用途とデータの性質に合わせて使い分けてみてください！