なぜ、あなたのVB.NETアプリは環境移行で「爆発」するのか？——設定管理の極意
現場でよく見る光景がある。「本番環境で動かしたら接続文字列がテスト環境のままだった」「シークレットキーがソースコードにハードコーディングされていて、git公開時に冷や汗をかいた」。
これらは単なるミスではない。「設定管理の設計思想」が欠如していることによる、エンジニアとしての構造的な敗北だ。
Visual Basic (VB.NET) は強力だ。しかし、その手軽さゆえに「とりあえず動く」コードを書いてしまい、後で技術的負債として自らの首を絞める開発者が後を絶たない。今日は、App.configとMy.Settingsを「ただの保存場所」から「堅牢な環境抽象化レイヤー」へと昇華させるためのアーキテクチャを伝授する。
—
1. App.config vs My.Settings：適材適所の境界線
多くの開発者がこの二つを混同している。結論から言えば、役割は明確だ。
- App.config (機密性低・環境依存)：
- DB接続文字列、外部APIのURLなど、「デプロイ時に環境ごとに書き換えるべきもの」を置く。
- デプロイ後にテキストエディタで修正可能であるという特性を活かす。
- My.Settings (機密性中・ユーザー依存)：
- 画面の表示位置、最終使用ディレクトリ、ユーザーの好みなど、「アプリケーション実行中にユーザーが変更するもの」を置く。
- 実行ファイルと同じフォルダ（`user.config`）に保存されるため、環境依存設定をここに置くとビルド毎の管理が地獄と化す。
設計指針： 「ビルドするたびに値を書き換える必要があるならApp.configへ。アプリを使っていて勝手に保存されるべきならMy.Settingsへ。」これだけは心に刻んでほしい。
—
2. 実務で「事故らない」接続文字列の扱い
接続文字列をコード内に直書きするのは論外だ。かといって、`App.config`を直接 `ConfigurationManager` で叩くのも、型安全性の観点から好ましくない。
以下のパターンで、インターフェースを介した「設定の抽象化」を行うのがプロの流儀だ。
推奨コード：設定読み込みのラッパーパターン
Imports System.Configuration
”’
”’
Public NotInheritable Class AppSettings
‘ コンストラクタを隠蔽し、静的クラスとして運用
Private Sub New()
End Sub
”’
”’
Public Shared ReadOnly Property ConnectionString As String
Get
Dim connString = ConfigurationManager.ConnectionStrings(“MainDatabase”)
If connString Is Nothing Then
Throw New InvalidOperationException(“App.configに’MainDatabase’が定義されていません。”)
End If
Return connString.ConnectionString
End Get
End Property
End Class
なぜこれが必要か？
`ConfigurationManager`を直接あちこちで叩くと、設定キーのスペルミスが実行時エラーとして潜伏する。このラッパーを通すことで、設定の欠如をアプリ起動直後のプロパティ呼び出しで即座に検知（Fail-Fast）できる。
—
3. シークレット管理の「絶対ルール」
接続文字列にパスワードを含める場合、`App.config` をそのままgitに上げるのは自殺行為だ。
1. 機密情報の外部化： パスワードは `App.config` には書かず、環境変数や、アクセス権限を制限した外部ファイル（`secrets.json`等）から読み込む。
2. 暗号化： どうしても `App.config` に書く必要があるなら、[.NETの構成ファイルの暗号化機能](https://learn.microsoft.com/ja-jp/dotnet/framework/configure-apps/how-to-encrypt-configuration-sections-in-aspnet-configuration)（`aspnet_regiis`）を使い、バイナリレベルで保護する。
—
4. My.Settingsを「永続化」する際のリスク
My.Settingsの落とし穴は「ユーザー設定の保存タイミング」だ。デフォルトではアプリ終了時に自動保存されるが、「不意のクラッシュ」が発生すると保存されない。
重要な設定変更（例えば「保存ボタン」を押した時など）は、以下のように手動で明示的にFlushする癖をつけろ。
Public Sub SaveUserPreferences(theme As String)
‘ 値を更新
My.Settings.ThemeColor = theme
‘ 明示的な保存（これでクラッシュ時も安心）
Try
My.Settings.Save()
Catch ex As Exception
‘ ログ出力してユーザーに通知
Logger.Error(“設定の保存に失敗しました”, ex)
End Try
End Sub
—
結論：コードは「環境」に対して謙虚であれ
優れたエンジニアは、自分のコードが「どの環境で動くか」をコード自身が知る必要がないように設計する。
- ハードコーディングを廃し、
- 設定の読み込みを抽象化し、
- 環境依存要素を外側に追い出す。
今日紹介した設計を取り入れれば、開発環境から本番環境への移行は「設定ファイルを差し替えるだけ」の作業になる。リリース作業で夜中にトラブル対応をしたくなければ、今すぐあなたのプロジェクトの設定管理を見直してほしい。
それが、伝説の自動化エンジニアとしての最初の一歩だ。
