VBAは死なない、VBScriptは死ぬ、VB6は生き残る｜2026年版Visual Basicの本当の未来

「VBAは近いうちに廃止される」

「ExcelマクロはOffice Scriptsに置き換わる」

「古いVB6アプリはWindows 11では動かない」

「Python in ExcelがVBAの後継になる」

Visual Basicを取り巻く将来予測には、似ているようで異なる技術が混同された情報が少なくありません。

2026年現在、VBA、VB6、VB.NET、VBScriptは、同じVisual Basicという名前を持ちながら、Microsoftの方針上はまったく異なる方向へ進んでいます。

結論から言えば、次のとおりです。

VBAは死なない。

VBScriptは段階的にWindowsから消える。

VB6は開発環境が死んでも、実行環境はWindows 11で生き残る。

VB.NETは廃止されないが、新しい用途へは広げられない。

つまり、Visual Basic全体が終了するのではありません。

Visual Basicを何にでも使ってよい時代が終わり、用途ごとに技術が分割されているのです。

本記事では、Microsoftの公式方針と最新の開発状況を基に、次の内容を徹底的に整理します。

VBAに正式な廃止予定はあるのか
VB6アプリがWindows 11でも動く本当の理由
VB.NETが「死んでいないが成長もしない」と言われる理由
2027年前後から始まるVBScript無効化
新しいOutlookでVBAとCOMが使えない問題
Office ScriptsがVBAの完全後継ではない理由
Python in Excelが業務自動化を置き換えない理由
64bit Officeで古いVBAが壊れる本当の原因
VB6互換処理系twinBASICとRAD Basicの現在地
社内に存在するVBA・VB6・VBScript資産の調査方法
今後5年間の継続、改修、移行、再構築の判断基準

最初に整理：Visual Basicは一つの製品ではない

Visual Basicという名前で呼ばれる技術は、少なくとも次の四つに分かれます。

技術	主な用途	現在の立場
VBA	Excel、Access、Word、Outlookなどの自動化	Officeデスクトップ内で継続
VB6	Windowsデスクトップ業務アプリ	IDE終了、既存ランタイムは継続
VB.NET	.NET、Windows Forms、クラスライブラリ	安定・保守路線
VBScript	Windowsスクリプト、ログオン処理、管理作業	段階的廃止

この四つは、文法や名前が似ていても、実行環境、サポート方針、移行先が異なります。

VBScriptの廃止を根拠に「VBAも廃止される」と説明することはできません。

VB6 IDEのサポート終了を根拠に「VB6で作られたEXEが動かなくなる」とも言えません。

2026年時点の結論一覧

技術	廃止予定	今後の見通し	企業が今すること
Excel・Access VBA	公表なし	デスクトップ業務で継続	署名、台帳化、64bit対応
Outlook VBA	新Outlookでは非対応	Classic Outlook依存	Graph、Power Automate、Office.jsを検討
VB6 IDE	2008年サポート終了済み	公式開発環境としては終了	開発環境の隔離と移行準備
VB6ランタイム	Windowsライフサイクルに連動	Windows 11／Server 2025でもサポート	OCX、32bit、印刷、ODBCを調査
VB.NET	公表なし	新しいワークロードへ拡張しない	既存WinForms等を最新.NETへ移行
VBScript	正式に廃止予定	2027年前後から既定で無効	PowerShell等へ移行
Office Scripts	継続投資	Excelクラウド自動化を担当	定型Excel処理を選別して移行
Python in Excel	継続投資	分析・統計・可視化を担当	VBAではなく分析処理を移行
twinBASIC	開発中	VB6互換・64bit化の有力候補	非本番アプリで互換性検証
RAD Basic	開発中	VB6ソース互換環境を目指す	対応機能を確認して評価

VBAに正式な廃止予定はあるのか

2026年7月時点で、MicrosoftはVBA自体の廃止時期を公表していません。

MicrosoftのVB6サポート方針でも、VBAはVB6とは別の技術であり、Officeに含まれるため、VBAのサポートはOffice製品のサポート方針に従うと説明されています。

つまり、次のような説明は正確ではありません。

VBScriptが廃止される
    ↓
同じVisual BasicなのでVBAも廃止される

VBScriptとVBAは別の実行環境です。

VBAは現在も、Excel、Access、Word、PowerPoint、Classic Outlookなどのデスクトップ版Officeで利用されています。

ただし、「廃止されない」と「今までと同じ運用でよい」は別問題です。

VBAを取り巻く環境は、次の方向へ変化しています。

インターネットから取得したマクロは既定でブロック
64bit版Officeへの対応が必要
新しいOutlookではVBAを利用できない
クラウド処理はOffice ScriptsやPower Automateへ分離
分析処理はPython in Excelへ分離
社内マクロにはデジタル署名と管理が求められる

VBAは消えるのではありません。

無管理で配布される野良マクロが使いにくくなり、管理された社内アプリとして残ると考える方が現実に近いでしょう。

インターネットから取得したVBAは既定でブロックされる

Microsoftは、VBAマクロがマルウェアやランサムウェアの侵入口として悪用されてきたことを理由に、インターネット由来のOfficeファイルに含まれるマクロを既定でブロックしています。

対象には、次のようなファイルが含まれます。

メールへ添付されたxlsm
Webサイトからダウンロードしたxlsm
TeamsやSharePointからローカルへ保存したファイル
インターネット扱いとなるネットワーク共有上のファイル
ダウンロードしたxlam、xltm、dotmなど

Windowsは、インターネット由来のファイルへMark of the Webと呼ばれる情報を付加します。

この情報が残っているファイルでは、以前のように黄色いバーから単純に「コンテンツの有効化」を選択できない場合があります。

今後の企業向けVBA運用

Microsoftのセキュリティベースラインでは、マクロを必要としない利用者ではマクロを無効化し、必要な利用者では信頼された発行元によってデジタル署名されたマクロだけを許可する構成が推奨されています。

従来の運用

担当者が.xlsmを作る
    ↓
メールで配布する
    ↓
利用者が警告を解除する
    ↓
誰が変更したか分からない


今後の運用

VBA資産を台帳登録する
    ↓
ソースコードを管理する
    ↓
社内証明書で署名する
    ↓
信頼された発行元を管理配布する
    ↓
変更時に再署名する

VBAの未来は、個人が自由に作るファイルから、企業が管理するコードへ移行していきます。

VB6は本当にWindows 11でも動くのか

VB6のIDEとVisual Studio 6.0 IDEは、2008年4月8日にサポートを終了しています。

Microsoftは、現在ではVB6アプリを作成・保守するための公式にサポートされた開発方法は存在しないとして、現代的な技術への置き換えを推奨しています。

ところが、VB6で作られた既存アプリケーションの実行環境は、現在もサポートされています。

Microsoftの公式サポート表では、VB6ランタイムと主要な拡張ランタイムファイルは、Windows 11とWindows Server 2025でもサポート対象です。

環境	VB6ランタイム	VB6 IDE
Windows 11	サポート	非サポート
Windows Server 2025	サポート	非サポート
64bit Windows	32bit WOW環境でサポート	非サポート
Server Core	非サポート	非サポート

ここにVB6の奇妙な状況があります。

開発環境
    → 18年以上前にサポート終了

既存アプリの実行環境
    → Windows 11でも公式サポート

Microsoftは、既存VB6アプリケーションがサポート対象のWindows上で「Just Work」、つまりそのまま動作することを目標にしています。

ただし、保守対象は重大な回帰や重要なセキュリティ問題に限られます。

VB6が動くことと、安全に保守できることは別問題

VB6ランタイムがWindows 11でサポートされていても、業務アプリ全体が安全に動く保証はありません。

実際に問題になるのは、VB6本体よりも周辺部品です。

古いActiveXコントロール
OCXファイル
古い帳票ライブラリ
32bit ODBCドライバー
古いAccessデータベース
DAO、RDO、ADO
Internet Explorer依存部品
古いプリンタードライバー
ハードウェア制御DLL
古い通信ライブラリ

Microsoftも、第三者製のOCXやActiveXコントロールはVB6サポート方針の対象外であり、各ベンダーへ確認する必要があると明記しています。

したがって、VB6アプリの将来性は、EXEが起動するかどうかだけでは判断できません。

VB6資産で優先的に調査するもの

プロジェクトファイル
.vbp

フォーム
.frm

標準モジュール
.bas

クラス
.cls

ActiveX
.ocx
.dll

データベース
.mdb
.accdb

帳票
.rpt

設定
.ini
.reg

VB6ランタイムは現在も32bitのみ

VB6ランタイムは、2026年現在も32bitです。

64bit版Windowsでは、WOWと呼ばれる32bit互換環境上で動作します。VB6 IDEの64bit版は存在せず、32bit版IDEも64bit Windows上では公式サポートされません。

そのため、次の問題が残ります。

64bit DLLを直接呼び出せない
64bitアプリのプロセス内へロードできない
32bit ODBCドライバーが必要
4GBを超えるアドレス空間を利用できない
64bit Officeとの直接連携に制約がある
32bit ActiveX登録が必要

VB6アプリが現在動いていても、周辺システムが64bit専用になった時点で接続できなくなる可能性があります。

VB.NETは終了するのか

VB.NETについても、Microsoftは廃止を発表していません。

しかし、MicrosoftのVisual Basic言語戦略には、今後の位置付けが明確に記載されています。

Visual Basicは、単純で親しみやすく、安定した設計の言語として維持されます。.NETランタイムとコアライブラリの改善はVBにも反映されます。

一方、C#や.NETに新機能が追加され、その利用に新しい言語構文が必要な場合、VBでは新構文を積極的に追加せず、可能な範囲で利用側だけを対応する方針です。

さらに、Visual Basicを新しいワークロードへ拡張しないことも明記されています。今後の投資対象は、Windows Forms、ライブラリ、Visual Studio体験、C#との相互運用などの中核領域です。

この方針を簡単に表現すると、次のようになります。

VB.NETは廃止しない
    ↓
既存アプリを保守できる状態は維持する
    ↓
.NETのライブラリ改善は利用できる
    ↓
ただし新しい用途の中心にはしない
    ↓
新しい言語機能はC#ほど増やさない

VB.NETは死んでいません。

しかし、Microsoftがクラウド、AI、Web、モバイルなどの新規開発を託している中心言語でもありません。

VB.NETを継続しやすい用途

Windows Forms
既存の.NET Framework業務アプリ
社内向けWindowsツール
既存クラスライブラリ
C#との相互運用

新規開発では慎重に判断する用途

クラウドネイティブサービス
コンテナ中心のバックエンド
最新のASP.NET Core
AIエージェント
クロスプラットフォームUI
モバイルアプリ

.NET移行ツール自体もAIへ置き換わった

2026年には、Microsoftの.NET Upgrade Assistantが正式に非推奨となりました。

後継として案内されているのは、Visual Studioに組み込まれたGitHub Copilot modernization agentです。

このエージェントは、プロジェクトと依存関係を分析し、移行計画を作り、非推奨APIの置き換えやビルドエラーの修正を支援し、変更ごとにコミットを作成します。

ただし、対象を正しく理解する必要があります。

VB.NET Frameworkアプリ
    ↓
最新.NETへの移行支援対象


VB6アプリ
    ↓
そのまま自動変換するツールではない

VB6とVB.NETは、名前が似ていても別のアーキテクチャです。

VB6アプリをVB.NETへ移す場合は、フォーム、COM、データアクセス、エラー処理、文字列、配列、既定プロパティなどの差を確認する必要があります。

本当にWindowsから消えるのはVBScript

VBAには廃止予定が公表されていない一方、VBScriptには明確な段階的廃止計画があります。

Microsoftは2023年10月にVBScriptを非推奨とし、三段階でWindowsから削除する方針を発表しました。

Phase 1

Windows 11 version 24H2以降では、VBScriptはFeature on Demandとして提供され、初期段階ではインストール済みかつ有効な状態です。

Phase 2

Microsoftの計画では、2027年前後にVBScriptが既定で無効になります。

引き続き必要な環境では、オプション機能として手動で有効化する必要があります。

Phase 3

将来のWindowsでは、VBScriptのDLLを含む機能全体が削除されます。

この段階では、VBScriptへ依存したアプリケーションやスクリプトは動作しません。

2024年～
Feature on Demandとして標準搭載・有効
    ↓
2027年前後
既定で無効
    ↓
将来
Windowsから完全削除

Microsoftは、Windows自動化ではPowerShell、Web用途ではJavaScriptへの移行を推奨しています。

VBScript廃止で影響を受けるもの

調査対象は、拡張子が.vbsのファイルだけではありません。

ログオンスクリプト
スタートアップスクリプト
タスクスケジューラ
cscript.exeを呼ぶバッチ
wscript.exeを呼ぶアプリ
WSFファイル
HTAアプリ
インストーラーのカスタムアクション
VBScriptを内部利用する古い業務アプリ
VBScriptのCOMコンポーネントを利用するVBA

特にExcelやAccessのVBAでは、正規表現のために次のコードが利用されていることがあります。

Set re = CreateObject("VBScript.RegExp")

これはVBA言語の正規表現機能ではありません。

Windows上のVBScript関連COMコンポーネントを外部から呼び出しています。

将来、VBScriptのDLLがWindowsから削除された場合、この形式のコードも影響を受ける可能性が高いため、早めに棚卸しすべきです。これはMicrosoftのVBScript完全削除方針から導ける技術的な推論です。

社内のVBScript依存をPowerShellで検索する

次のPowerShellは、指定したフォルダからVBScript関連のファイルと文字列を検索します。

$Root = "C:\CompanyFiles"
$Output = "C:\Temp\vbscript_inventory.csv"

$Patterns = @(
    'VBScript\.RegExp',
    'CreateObject\s*\(\s*"VBScript',
    'CreateObject\s*\(\s*"WScript',
    'WScript\.Shell',
    'WScript\.Network',
    'cscript\.exe',
    'wscript\.exe',
    '\.vbs\b',
    '\.wsf\b'
)

$Extensions = @(
    "*.vbs",
    "*.wsf",
    "*.hta",
    "*.bat",
    "*.cmd",
    "*.ps1",
    "*.bas",
    "*.cls",
    "*.frm",
    "*.txt",
    "*.ini",
    "*.xml",
    "*.config"
)

$Results = foreach ($File in Get-ChildItem `
    -Path $Root `
    -Recurse `
    -File `
    -Include $Extensions `
    -ErrorAction SilentlyContinue) {

    foreach ($Pattern in $Patterns) {
        $Matches = Select-String `
            -Path $File.FullName `
            -Pattern $Pattern `
            -AllMatches `
            -ErrorAction SilentlyContinue

        foreach ($Match in $Matches) {
            [PSCustomObject]@{
                File       = $File.FullName
                Extension  = $File.Extension
                Pattern    = $Pattern
                LineNumber = $Match.LineNumber
                Line       = $Match.Line.Trim()
                Modified   = $File.LastWriteTime
            }
        }
    }
}

$Results |
    Sort-Object File, LineNumber |
    Export-Csv `
        -Path $Output `
        -NoTypeInformation `
        -Encoding UTF8

Write-Host "出力完了: $Output"

Excelファイル内のVBAコードは、通常のファイル検索では直接読めません。

マクロをエクスポートするか、VBAプロジェクト解析ツールを利用して、.bas、.cls、.frmとして調査する必要があります。

新しいOutlookではVBAが使えない

ExcelやAccessのVBAよりも、将来の影響が明確なのがOutlookです。

Microsoftは、新しいOutlook for WindowsではVBAとマクロをサポートしないと明記しています。

代替手段として案内されているのは、Power Automate、Microsoft Graph API、Office.jsです。

また、新しいOutlookではCOMアドインもサポートされません。

COM／VSTOアドインを利用している場合、Webアドインへの移行が必要です。

影響を受ける代表的な処理

受信メールの添付ファイルを自動保存
件名や送信者による自動処理
メール受信イベントで基幹システムへ登録
Excel VBAからOutlook.Applicationを操作
Accessから定型メールを送信
Outlook終了時や起動時の処理
独自COMアドイン
VSTOアドイン
MAPIを利用したデスクトップ連携

Classic Outlookは、既存インストールについて少なくとも2029年まで利用可能とされています。

ただし、「2029年まで何もしなくてよい」という意味ではありません。

Outlook VBAやCOMへ依存する業務は、Classic Outlookを延命しながら、段階的に移行する必要があります。

現在の処理	主な移行候補
メール受信時の自動処理	Power Automate、Graph Webhook
添付ファイル保存	Power Automate、Graph API
Outlook画面へのボタン追加	Office.js Webアドイン
メール送信	Microsoft Graph、Power Automate
社内システムとの連携	Graph API＋Web API

Office ScriptsはVBAの完全後継ではない

Microsoftは、VBAマクロをデスクトップ向け、Office Scriptsを安全なクロスプラットフォーム・クラウド向けと説明しています。

両者は競合する部分もありますが、設計目的が違います。

項目	VBA	Office Scripts
主な実行場所	Officeデスクトップ	Excel Web、Windows、Mac
対応Office	Excel、Word、Access、Outlook等	Excelのみ
言語	Visual Basic for Applications	TypeScript
PC上のファイル操作	可能	不可
COM／OLE	可能	不可
Excelイベント	対応	非対応
Power Automate	直接コネクタなし	対応
無人実行	苦手	Power Automateから可能
端末へのアクセス権	Excelと同等	ブック中心に制限

Office Scriptsは、次の処理に適しています。

Excel表の定型整形
テーブル作成
数式の入力
不要行の削除
集計シートの生成
Power Automateからの定期実行
複数利用者でのスクリプト共有

一方、次のVBAは簡単には移行できません。

Worksheet_Changeイベント
UserForm中心の入力システム
Windows API
ローカルフォルダの一括処理
Accessとの連携
Outlook COM操作
ActiveXコントロール
外部DLL呼び出し

Office ScriptsではExcelレベルのイベントをサポートせず、手動実行またはPower Automateからの呼び出しで動作します。

Office ScriptsはVBAの後継ではなく、VBAが担当していた仕事の一部分をクラウドへ移すための技術です。

Python in ExcelもVBAの後継ではない

Python in Excelでは、Excelセル内からPythonを実行し、pandas、NumPy、Matplotlibなどを利用したデータ分析ができます。

しかし、Pythonコードは利用者のPC上ではなく、Microsoft Cloud上のHypervisorで分離されたコンテナ内で実行されます。

Pythonコードには、次の制限があります。

利用者のPCへアクセスできない
デバイスへアクセスできない
利用者アカウントへアクセスできない
ネットワークへアクセスできない
ユーザートークンへアクセスできない
参照されたセルやPower Queryデータだけを利用する

コンテナ内部では一時的なファイル操作やシェル処理が可能な場合がありますが、利用者のローカルPCを操作するものではなく、コンテナはセッション後に破棄されます。

Python in Excelが得意な処理

統計分析
回帰分析
外れ値検出
データクレンジング
高度なグラフ
時系列分析
機械学習

VBAの代わりにならない処理

指定フォルダ内のExcelを順番に開く
PDFをローカルへ保存する
Outlookからメールを送信する
Windowsアプリを操作する
基幹システムへキー入力する
プリンターを切り替える
Windows APIを呼び出す

また、Python in ExcelはiPad、iPhone、Android版Excelでは利用できません。対応していない端末ではブックを表示できますが、Pythonセルの再計算時にエラーになります。

Python in ExcelはVBAの自動化機能を置き換えるものではなく、Excel内の分析能力を拡張するものです。

64bit OfficeでVBAが壊れる本当の原因

古いVBA資産では、Windows APIを呼び出すDeclare文が利用されています。

64bit版Officeでは、すべてのDeclare文にPtrSafeが必要です。

ただし、Microsoftは、単にPtrSafeを追加するだけでは64bit対応にならないと明記しています。

古い32bit用コード

Declare Function GetActiveWindow _
    Lib "user32" () As Long

間違った修正

Declare PtrSafe Function GetActiveWindow _
    Lib "user32" () As Long

このコードはPtrSafeを付けていますが、戻り値は32bitのLongのままです。

64bitポインターが32bitへ切り詰められ、誤動作やクラッシュの原因になります。

正しい修正

Declare PtrSafe Function GetActiveWindow _
    Lib "user32" () As LongPtr

Microsoftは、ポインターとハンドルにはLongPtr、64bit整数にはLongLongを利用するよう案内しています。

32bit／64bit共通コード

#If VBA7 Then

    Private Declare PtrSafe Function GetActiveWindow _
        Lib "user32" () As LongPtr

#Else

    Private Declare Function GetActiveWindow _
        Lib "user32" () As Long

#End If

さらに、Declare文だけでなく、次も確認する必要があります。

戻り値を受け取る変数
ユーザー定義型
ハンドルを格納する配列
CopyMemory等のAPI
コールバック関数
ウィンドウプロシージャ
32bit専用ActiveX

VBA・VB6資産を自動で棚卸しする

最初に、社内ファイルサーバーから関連ファイルを抽出します。

$Root = "\\fileserver\share"
$Output = "C:\Temp\visual_basic_assets.csv"

$TargetExtensions = @(
    ".xlsm",
    ".xlam",
    ".xltm",
    ".docm",
    ".dotm",
    ".pptm",
    ".potm",
    ".accdb",
    ".accde",
    ".mdb",
    ".mde",
    ".vbp",
    ".frm",
    ".bas",
    ".cls",
    ".ctl",
    ".pag",
    ".vbs",
    ".wsf",
    ".hta",
    ".ocx",
    ".dll",
    ".rpt"
)

Get-ChildItem `
    -Path $Root `
    -Recurse `
    -File `
    -ErrorAction SilentlyContinue |
Where-Object {
    $TargetExtensions -contains
        $_.Extension.ToLower()
} |
Select-Object `
    FullName,
    Extension,
    Length,
    CreationTime,
    LastWriteTime,
    @{
        Name = "SizeMB"
        Expression = {
            [Math]::Round(
                $_.Length / 1MB,
                2
            )
        }
    } |
Export-Csv `
    -Path $Output `
    -NoTypeInformation `
    -Encoding UTF8

Write-Host "資産一覧を出力しました: $Output"

次にコード上の危険依存を検索する

$Root = "C:\ExportedVBSource"
$Output = "C:\Temp\vb_dependency_scan.csv"

$Patterns = @{
    "VBScript" =
        'VBScript\.|wscript\.exe|cscript\.exe'

    "OutlookCOM" =
        'Outlook\.Application|Outlook\.MailItem'

    "WindowsAPI" =
        '^\s*(Private\s+|Public\s+)?Declare'

    "PtrSafe" =
        '\bPtrSafe\b'

    "PointerLong" =
        'As\s+Long\b'

    "ActiveX" =
        'CreateObject|GetObject'

    "Shell" =
        '\bShell\s*\(|WScript\.Shell'

    "FileSystem" =
        'FileSystemObject|Scripting\.FileSystemObject'

    "DAO" =
        '\bDAO\.|CurrentDb|OpenDatabase'

    "ADO" =
        '\bADODB\.|ConnectionString'

    "Access" =
        'Access\.Application'

    "Excel" =
        'Excel\.Application'
}

$Files = Get-ChildItem `
    -Path $Root `
    -Recurse `
    -File `
    -Include *.bas,*.cls,*.frm,*.ctl,*.vbs `
    -ErrorAction SilentlyContinue

$Results = foreach ($File in $Files) {
    foreach ($Category in $Patterns.Keys) {
        $Matches = Select-String `
            -Path $File.FullName `
            -Pattern $Patterns[$Category] `
            -AllMatches `
            -ErrorAction SilentlyContinue

        foreach ($Match in $Matches) {
            [PSCustomObject]@{
                Category   = $Category
                File       = $File.FullName
                LineNumber = $Match.LineNumber
                Line       = $Match.Line.Trim()
            }
        }
    }
}

$Results |
    Sort-Object Category, File, LineNumber |
    Export-Csv `
        -Path $Output `
        -NoTypeInformation `
        -Encoding UTF8

Write-Host "依存関係調査を出力しました: $Output"

VB6互換を目指すtwinBASICという選択肢

日本語圏ではまだ情報が少ないものの、VB6とVBAに高い互換性を持つ新しい言語・開発環境としてtwinBASICが開発されています。

twinBASICは、既存のVB6プロジェクトを開き、同じコードベースから32bitと64bitのWindowsアプリを生成することを目指しています。

公式サイトでは、ネイティブ64bitコンパイル、Unicode、COM、現代的なIDE、ジェネリクス、オーバーロード、インターフェース、パッケージシステムなどが案内されています。

2026年のロードマップ

2026年4月17日更新の公式ロードマップでは、Version 1のRelease Candidateを2026年11月16日、正式版を2026年12月14日に公開する暫定計画が示されています。

日程は暫定で変更される可能性があります。

2027年には、Linux、Mac、Androidなどのクロスプラットフォーム対応も計画されていますが、これも将来計画であり、現時点の完成機能として評価すべきではありません。

twinBASICが注目される理由

VB6／VBAに近い文法
既存VB6プロジェクトを開ける
32bit／64bitネイティブコンパイル
COM DLLや標準DLLを作成可能
Unicode対応
現代的なデバッガー
既存コードを残しながら拡張できる

さらにtwinBASICには、古いMSCOMCTL.OCXへの依存を減らすため、Win32の標準コントロールを利用した互換パッケージも用意されています。

注意点

twinBASICは、2026年7月時点ではまだ正式なVersion 1へ到達していません。

公式FAQでも、ベータ後期であり、未実装または完全互換ではない機能が残っていると説明されています。

したがって、いきなり基幹システムを本番移行するのではなく、次の順番で評価します。

小規模な社内ツールを読み込む
コンパイルエラーを記録する
画面と帳票を比較する
32bit版を作る
64bit版を作る
OCX、DLL、DB接続を確認する
実データを使わず受入試験を行う

RAD Basicという別のVB6互換環境

RAD Basicも、VB6の.vbp、.frm、.bas、.clsを変換せずに開き、ネイティブWindowsアプリを生成することを目標としたプロジェクトです。

生成したEXEはVB6ランタイムや.NETランタイムを必要としないネイティブ実行ファイルを目指しています。

ただし、開発環境自体は.NETを利用します。

現在の制限

公式の互換表では、現時点で主に対応しているプロジェクト種別はStandard EXEです。

ActiveX DLL、ActiveX EXE、OCXについては今後の対応とされています。

そのため、RAD Basicも「今すぐ全VB6システムを移せる完全互換製品」ではありません。

項目	twinBASIC	RAD Basic
VB6互換目標	あり	あり
64bit	対応	対応を提供
COM開発	比較的強い	一部開発中
ActiveX DLL／OCX	対応範囲が広い	互換表では今後対応を含む
現在の状態	ベータ後期	ベータ・開発中
評価方法	実プロジェクトで検証	互換表を確認して検証

どの技術へ移行すべきか

VBAやVB6を一律にC#へ書き換える必要はありません。

用途ごとに移行先を選びます。

現在の資産	推奨方針
Excel内で完結する小規模VBA	署名して継続、またはOffice Scripts
Excelのイベント・UserForm中心	VBA継続またはWebアプリ化
Power Automateで無人実行したいExcel処理	Office Scripts
Excelの統計・分析処理	Python in Excel
Outlook VBA	Power Automate、Graph API、Office.js
Access VBA	短期継続、DBと画面の段階分離
VBScript管理処理	PowerShell
小規模VB6ツール	twinBASIC検証または.NET再構築
大規模VB6基幹システム	API化、段階分離、業務単位で再構築
VB.NET WinForms	最新.NETへ移行して継続

VBAを継続してよい条件

Officeデスクトップでのみ利用する
処理がExcelやAccess内で完結する
担当者と責任者が明確
ソースコードを保管している
32bit／64bitの両方で試験している
デジタル署名を利用している
バックアップがある
利用端末とOfficeバージョンを管理している
外部システム依存が少ない

移行を急ぐべき条件

Outlook VBAへ依存している
VBScriptを利用している
担当者しか仕様を知らない
ソースコードがない
VB6 IDEでしか修正できない
古いOCXへ依存している
32bit Officeでしか動かない
Internet Explorerへ依存している
Windows APIを大量に呼んでいる
メール添付でマクロを配布している
デジタル署名がない
基幹業務なのにテスト環境がない

2026年から2030年までの現実的な計画

2026年：全資産を発見する

xlsm、xlam、accdb、mdb、vbp、vbsを検索
利用者、担当者、業務名を登録
VBScript依存を検索
Outlook VBAとCOMアドインを抽出
32bit専用部品を確認

2027年：VBScriptとOutlook依存を優先移行

VBScriptをPowerShellへ移行
新しいOutlookで動かない処理を分類
Power AutomateとGraph APIの試験
VBScript.RegExp依存を置き換え

2028年：VBAを管理対象へ変える

社内コード署名証明書を導入
信頼された発行元を配布
マクロ台帳を整備
64bit Office試験を完了
利用されていないマクロを廃止

2029年：Classic Outlook依存を解消する

Outlook VBAを原則廃止
COMアドインをWebアドインへ移行
メール連携をGraph APIへ統一
Classic Outlook専用業務を残さない

2030年：VB6の残存領域を限定する

保守可能なアプリだけを隔離運用
twinBASIC等の互換環境を評価
基幹処理をAPI化
DBと画面を分離
新規機能をVB6へ追加しない

よくある誤解

VBAは2027年に終了する

終了する予定が示されているのはVBScriptです。

VBA自体の廃止時期は公表されていません。

VB6はWindows 11で非対応

VB6 IDEは非サポートですが、VB6ランタイムはWindows 11でサポートされています。

VB.NETも廃止される

廃止ではありません。

安定した設計を維持し、Windows Formsやライブラリ等を中心に継続します。ただし、新しいワークロードへ拡張しない方針です。

Office Scriptsへ移せば全VBAを廃止できる

Office ScriptsはExcelクラウド自動化向けです。

イベント、UserForm、COM、ローカルファイル、Access、Outlookなどを利用するVBAは、そのまま移行できません。

Python in Excelで業務自動化できる

Python in Excelはクラウド上の隔離コンテナで動作し、利用者のPCやネットワークへアクセスできません。主用途は分析です。

PtrSafeを追加すれば64bit対応は完了する

不十分です。

ポインターやハンドルはLongPtrへ、64bit整数はLongLongへ変更する必要があります。

twinBASICなら無条件で全VB6アプリを移行できる

twinBASICは有力ですが、現時点ではベータであり、プロジェクト固有の互換性検証が必要です。

最終結論

Visual Basicは、一斉に終了するわけではありません。

それぞれの技術は、次のように異なる未来へ進んでいます。

VBA
  → Officeデスクトップ内で残る
  → 署名・管理・64bit対応が必要


VB6
  → IDEは終了済み
  → 既存EXEはWindows 11でも動く
  → 32bitとOCX依存が将来の障害


VB.NET
  → 廃止されない
  → 安定・保守路線
  → 新規ワークロードの中心にはならない


VBScript
  → 2027年前後に既定無効
  → 将来のWindowsから完全削除


Outlook VBA
  → Classic Outlookでは利用可能
  → 新しいOutlookでは利用不可


Office Scripts
  → Excelのクラウド自動化を担当


Python in Excel
  → データ分析を担当


twinBASIC・RAD Basic
  → VB6資産を残しながら近代化する新しい可能性

企業が今すぐVBAとVB6を全廃する必要はありません。

しかし、「今動いているから、今後も動く」と考えて放置するのは危険です。

最初にすべきことは、書き換えではありません。

どこに、何があり、誰が使い、何へ依存しているかを把握することです。

そのうえで、資産を次の五つに分類します。

そのまま継続する
管理と署名を追加する
64bit対応へ改修する
Office Scripts、PowerShell、Graph等へ移行する
別システムとして再構築する

VBAは死にません。

VB6も、すぐには消えません。

しかし、Visual Basic資産を、担当者の記憶と古いPCだけで維持する時代は終わります。

Visual Basicの未来を決めるのは、言語の寿命ではなく、企業が資産を管理し、依存関係を把握し、段階的に移行できるかどうかです。

公式・参考資料

Microsoft：Visual Basic 6.0 Support Statement
Microsoft：Visual Basic言語戦略
Microsoft：VBScript廃止ロードマップ
Microsoft：Office ScriptsとVBAの違い
Microsoft：新しいOutlookのVBA代替策
Microsoft：COMアドインからWebアドインへの移行
Microsoft：Python in Excelのセキュリティ
Microsoft：64bit VBAの対応方法
Microsoft：GitHub Copilot modernization agent
twinBASIC公式ロードマップ
twinBASIC公式ドキュメント
RAD Basic公式互換表

本記事は2026年7月28日時点で公開されている公式情報を基にしています。twinBASICおよびRAD Basicは開発中のため、ロードマップ、対応機能、ライセンス、リリース日は今後変更される可能性があります。本番システムへ採用する前に、必ず最新情報と実プロジェクトでの互換性を確認してください。