「VB6で動いている業務システムを、そろそろPythonに移行したい」
「でも、何から手を付ければいいか分からない」
社内SEとして30年、業務システムの開発・保守に携わってきた中で、こうしたご相談を本当によくいただきます。多くの場合、いきなりコード書き換えに飛びつくと、移行途中で予想外のトラブルに遭遇して工期が膨らみます。
この記事では、VB6/Access業務システムをPythonに移行する前に、必ず確認しておきたい5つのポイントをまとめました。発注を検討されている方、自社で着手しようとされている方、どちらの立場でも参考になる内容を意識して書いています。
---
1. VB6コードの「Variant型」と「暗黙の型変換」を棚卸しする
VB6最大の翻訳の難所が、Variant型と暗黙の型変換です。
VB6では、変数の型を厳密に宣言しなくても動作します。`Dim x` とだけ書けば、xはVariant型として扱われ、整数も文字列も日付も「とりあえず動く」状態でコードが書けてしまいます。Pythonの世界では、このタイプの曖昧さは型エラーやサイレントバグの温床になります。
特に注意すべきパターン：
- 数値文字列の自動変換：`"123" + 1` がVB6では `124` になる（Pythonでは型エラー）
- 日付の自動解釈：`#2026/4/29#` のような日付リテラル（Pythonでは別途パース処理が必要）
- NullとEmptyとNothingの区別：VB6には3種類の「空」概念があるが、Pythonでは基本Noneに集約される
移行前に「Dim文だけで型宣言されていないVariant変数」をリストアップしておくと、Python移植後のバグ調査が劇的に楽になります。これだけは事前にやっておく価値があります。
---
2. Accessデータベースのリンクテーブルとjet SQL方言の依存を洗い出す
Accessは便利なデータベースですが、VB6＋Accessの組み合わせには、Python＋PostgreSQL/SQLite/MySQLにそのまま置き換えられないAccess特有の依存が潜んでいます。
特に確認すべき項目は以下のとおりです。
- リンクテーブル：他のAccess MDB、Excel、テキストファイルへの「リンクテーブル」が設定されている場合、その実体パスと依存関係をすべて記録する必要があります
- Jet SQL方言：`IIf()`、`Switch()`、`Format()`、`Nz()` といったAccess固有の関数を使ったクエリは、PostgreSQLやMySQLに翻訳が必要です（`COALESCE`、`CASE WHEN` への置換が中心）
- クエリオブジェクト：Access内で保存されている「クエリ」は、Python側ではビューやストアドファンクションに移すか、SQLAlchemy等のORM経由でのクエリビルダーに移植する判断が必要
ここを棚卸しせずに移行に着手すると、「VB6コードは動いているのにDB側で結果が違う」という最も解決が面倒な問題に直面します。
---
3. GUIを「そのまま」Pythonに移植しようとしない
VB6のフォーム（Form）デザイナーで作られたGUIは、ボタン1つに数百行のコードがぶら下がっていることが珍しくありません。これをPythonでそのまま再現しようとすると、移行コストが膨れ上がる典型パターンです。
選択肢は大きく3つあります。
- PySimpleGUI / Tkinter で簡易再現：既存ユーザーの操作感を維持しつつ、最小コストで移行
- Webアプリ化（Flask / FastAPI + HTML）：将来的なクラウド対応を見据える場合の選択
- CUI（コマンドライン）化：定期実行のバッチ処理であれば、GUIを廃止する選択肢もあり
「現状のGUIで何ができるのか」「ユーザーが本当に使っている機能はどれか」を切り分けてから、移行先のUI形式を決めるのが正解です。全機能を移植する必要はないという前提で棚卸ししてください。
---
4. On Error Resume Next の例外処理パターンを翻訳する
VB6では `On Error Resume Next` で「エラーを無視して次の行を実行する」という書き方が広く使われています。これは一見便利ですが、実はバグを長年隠蔽してきた可能性のある、最も危険なコードパターンです。
Pythonへの移植時には、この `Resume Next` を機械的に `try-except: pass` に翻訳してはいけません。理由は以下のとおりです。
- VB6コード上でエラーが発生していたが、業務処理上は「たまたま正しい結果」になっていたケースがある
- そのコードをPythonに変換すると、初めてエラーが顕在化し、ユーザーが「Pythonにしたらバグった」と認識する
正しい移植手順は、「`On Error Resume Next` が使われている箇所をすべてリストアップ → そこで実際にどんなエラーが発生し得るかを洗い出し → 個別に対応する」という流れです。AIツールを活用すれば、このリストアップ作業は大幅に効率化できます。
---
5. Excel連携・OLEオートメーション部分は「最後に切り離して」評価する
VB6システムの多くは、Excelとのデータ連携に OLEオートメーション（`CreateObject("Excel.Application")` 等）を使っています。Python側では `openpyxl` や `pandas` で代替できますが、VB6時代のExcel連携にはいくつかの落とし穴があります。
- マクロ付きExcelファイル（.xls / .xlsm）の処理：openpyxlでは旧形式（.xls）が読めない、マクロは保持できない等の制約
- Excel側のフォーマット依存：セル位置決め打ちでデータを参照しているコードは、Excelテンプレートが変わると壊れる
- 印刷・帳票出力連携：VB6時代はExcel経由で印刷していたが、Pythonでは別の帳票ライブラリ（reportlab等）に移行する判断が必要
Excel連携部分は、コア業務ロジックよりも最後に切り離して評価することをおすすめします。コアロジックの移植が終わってから、Excel連携部だけを差し替える方が、影響範囲を限定できます。
---
まとめ：移行は「コード書き換え」ではなく「現状調査」から始まる
VB6/Access業務システムをPythonに移行する作業は、コードを書き換える以前に、既存システムの現状調査が成否の8割を決めます。
5つのポイントを再掲します。
1. Variant型と暗黙の型変換の棚卸し
2. Accessのリンクテーブル・Jet SQL方言の依存確認
3. GUIをそのまま移植しない（移行先UI形式の決定）
4. On Error Resume Next を機械的に変換しない
5. Excel連携・OLE部分は最後に切り離す
これらを事前にチェックリスト化してから移行プロジェクトを設計すると、工期見積もりの精度が上がり、移行途中の予想外のトラブルが大幅に減ります。
---
ご相談・お見積もりについて
私はココナラで、VB6/AccessをPythonに移行するサービスを提供しています。30年のエンジニア経験と、Claude Code等のAI開発ツールを組み合わせ、レガシーコードの解析・移植を高速・高品質に行います。
「うちのシステムも移行したいが、現状調査から相談したい」という方も歓迎します。コードの行数や使用環境をお聞かせいただければ、具体的なご提案をいたします。
最後までお読みいただきありがとうございました。
