こんにちは！開発現場の裏側でシステムの安定稼働を支える、あなたの身近な先輩エンジニアです。
皆さんは、開発したVB.NETアプリケーションをいざ本番環境で動かしたとき、突然「ピキーン」と音もなく画面が消え去り、Windowsのイベントビューアーに謎のクラッシュログだけが残された……という冷や汗モノの経験はありませんか？
「なぜ落ちたのか分からない」「ユーザーから『いきなりアプリが消えた』と言われて頭が真っ白になった」
そんな悪夢を断ち切り、どんな予期せぬ例外（バグ）が起きたとしても、最後の最後に「ごめんなさい、安全に終了します」と優しくユーザーに伝え、裏でこっそり原因を記録する。それがプロのエンジニアが実装する「クラッシュレス化（最終防衛ライン）」です。
ここをクリアすれば、あなたの書くVB.NETアプリケーションの信頼性はプロの領域へと一気にステップアップします。さあ、一緒に最後の砦の築き方をマスターしていきましょう！
—
1. なぜアプリは突如としてクラッシュするのか？
通常、私たちが書くコードの中では `Try…Catch` ステートメントを使ってエラーを捕捉しますよね。
Try
‘ 危険な処理（ファイルの読み込みやデータベース接続など）
Dim result As Integer = 100 \ 0
Catch ex As Exception
‘ ここでエラーをキャッチして優しく処理
MessageBox.Show(“エラーが発生しました: ” & ex.Message)
End Try
しかし、世の中には「Try…Catchで囲めない場所」や「囲むのをうっかり忘れてしまう致命的なバグ」が存在します。
例えば、マルチスレッドの内部で起きた未処理の例外や、Windowsフォームの描画イベントの奥深くで起きた致命的なメモリ違反などです。これらが放置されると、.NETランタイムそのものが耐えきれなくなり、容赦なくアプリケーションを強制終了（クラッシュ）させます。
この「最後の断末魔」すらキャッチできずにアプリが消滅するのを防ぐために用意されたのが、`AppDomain.CurrentDomain.UnhandledException` という .NET Framework / .NET Core が誇る最強の最終防衛ラインです。
—
2. 最終防衛ラインの全体像を図解する
イメージとしては、アプリケーションのライフサイクル全体を包み込む「セーフティネット」を張る感覚です。
[ ユーザーの操作 / メイン処理 / バックグラウンド処理 ]
│
▼ （予期せぬ致命的例外が発生！）
┌──────────────────────────────────────────────┐
│ .NET Runtime の管理下 │
│ │
│ 通常ならここで強制終了（クラッシュ） 💥 │
│ │ │
│ ▼ │
│ 【AppDomain.UnhandledException イベント】 │ ← ★ここが最後の砦！
│ ・エラーログの自動保存（ダンプ出力など） │
│ ・ユーザーへの優美な終了メッセージ通知 │
└──────────────────────────────────────────────┘
│
▼
安全にプロセスを終了
この仕組みをメイン画面（フォーム）が立ち上がるよりも前の段階（アプリケーションの起動時）に仕込んでおくのがポイントです。
—
3. 実装コード：クラッシュレス化の全貌
それでは、実際のVB.NETコードを見てみましょう。コンソールアプリでもWindowsフォームアプリでも考え方は同じですが、今回は視覚的に分かりやすいWindowsフォームを前提とした実装例を解説します。
プロジェクトの最も最初に対話が始まる場所（Sub Main や フォームの初期化イベントなど）に、以下のコードを仕込みます。
Imports System.IO
Imports System.Threading
Public Class MainForm
‘ アプリケーション起動時に一度だけ呼び出す初期化メソッド
Public Shared Sub InitializeCrashHandler()
‘ AppDomainのグローバル例外キャッチイベントにイベントハンドラを登録する
AddHandler AppDomain.CurrentDomain.UnhandledException, AddressOf HandleUnhandledException
‘ UIスレッド特例（Windowsフォームの場合）の例外キャッチも合わせて固める場合
AddHandler Application.ThreadException, AddressOf HandleThreadException
End Sub
‘ =========================================================================
‘ 1. メインスレッド・バックグラウンドスレッド等での致命的例外をキャッチ
‘ =========================================================================
Private Shared Sub HandleUnhandledException(sender As Object, e As UnhandledExceptionEventArgs)
Dim ex As Exception = TryCast(e.ExceptionObject, Exception)
‘ 1. ログファイルへの書き出し（絶対に例外を外に漏らさないようTryで囲む）
Try
Dim logMessage As String = $”{DateTime.Now}: 致命的エラーが発生しました。” & vbCrLf &
If(ex IsNot Nothing, ex.ToString(), “不明な例外オブジェクト”) & vbCrLf &
$”IsTerminating: {e.IsTerminating}” & vbCrLf &
New String(“-“c, 50) & vbCrLf
File.AppendAllText(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, “fatal_error.log”), logMessage)
Catch
‘ ログ書き込み中のエラーは何もしない（無限ループを防ぐため）
End Try
‘ 2. ユーザーへの優美なメッセージ通知
MessageBox.Show(
“アプリケーションで予期せぬ致命的なエラーが発生しました。” & vbCrLf &
“ご不便をおかけして申し訳ありません。作業内容は保存されていない可能性があります。” & vbCrLf &
“詳細なログが [fatal_error.log] に保存されました。”,
“システムエラー”,
MessageBoxButtons.OK,
MessageBoxIcon.Error
)
‘ 注: e.IsTerminating が True の場合、このメソッドを抜けるとアプリは強制終了します。
End Sub
‘ =========================================================================
‘ 2. UIスレッド（ボタンクリックなど）でキャッチされなかった例外をキャッチ
‘ =========================================================================
Private Shared Sub HandleThreadException(sender As Object, e As ThreadExceptionEventArgs)
‘ ここでUIスレッド特有のダイアログを出したりログに落としたりする
MessageBox.Show($”UIスレッドエラー: {e.Exception.Message}”, “警告”, MessageBoxButtons.OK, MessageBoxIcon.Warning)
End Sub
End Class
—
4. コードの深い解説とエンジニアの知見
ここで、コードの裏側にある「VB.NET / .NETのオブジェクトライフサイクル」の重要なポイントを解説します。
1. `AddressOf` によるイベントフック
`AppDomain.CurrentDomain.UnhandledException` は、アプリケーションドメイン全体（アプリが生きている空間全体）の監視カメラのようなものです。ここに自分たちの作ったメソッドを `AddressOf` で結びつけることで、地の果てで起きたエラーでも監視網に引っ掛けることができます。
2. `e.ExceptionObject` の正体
飛んでくるオブジェクトは必ずしも `Exception` 型とは限りません（稀に非CLS準拠の例外オブジェクトが飛んできます）。そのため、慌ててキャストせず `TryCast(e.ExceptionObject, Exception)` を使って安全に型変換を行うのが、堅牢なコードを書くシニアの作法です。
3. 「死に際」の処理は慎重に
`UnhandledException` が発火した時点で、アプリの大部分は既に破損状態にあるか、終了寸前です。この中でさらに複雑なデータベースアクセスやWeb API呼び出しを行うと、例外の連鎖（例外の中での例外）を引き起こし、かえって処理がぐちゃぐちゃになります。
最後の防衛ラインで行うべきことは、「ローカルファイルへのテキスト書き出し」と「ユーザーへのメッセージ表示」という極めてプリミティブな処理だけに絞るのが鉄則です。
—
5. 陥りやすい罠と注意点
初心者のうちは、このコードを書いて満足してしまいがちですが、以下の罠に注意してください。
- 罠1：Visual Studioのデバッガー実行時は挙動が異なる
コードを書いてVisual Studioから「F5（デバッグ開始）」で実行しているときは、このグローバルイベントをすり抜けて、Visual Studioの「未処理の例外ダイアログ（黄色い画面）」が強制的に割り込んできます。
「正しく動いているかテストしたい！」というときは、デバッグなし（Ctrl + F5）で直接EXEを実行してテストしてください。これ、めちゃくちゃよくあるハマりポイントです！
- 罠2：エラーを隠蔽しすぎてバグに気づかなくなる
「アプリが落ちなくなったぞやったー！」と安心するのは良いですが、それはあくまで「延命措置」や「優美な終了」のためのものです。根本的なバグが直ったわけではありません。定期的に `fatal_error.log` をチェックする運用フローをセットで作りましょう。
—
まとめ
いかがでしたでしょうか？
Visual Basic (VB / VB.NET) の基本構文を覚えた次のステップとして、こうした「アプリのライフサイクルと例外の裏側」を理解することは、プロとしての大きな自信につながります。
- 予期せぬクラッシュは `AppDomain.CurrentDomain.UnhandledException` で網を張る。
- 死に際の処理はシンプルに（ファイル出力とメッセージのみ）。
- テストは必ず「デバッグなし実行」で行う。
ここをクリアすれば、あなたのVB.NETアプリは一気に「プロ仕様の堅牢性」を手に入れます。
明日からの開発現場で、ぜひこの最終防衛ラインを導入してみてください。あなたの書くコードの信頼性が、今日から劇的に変わりますよ！
