この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。MicrosoftのWin32、COM、Windows Runtime公式資料を確認し、PowerShellからの呼び方の違いを小さな例で比較できる形に整理しています。検証ステータス：📘 Microsoft公式仕様確認済み・Windows実機未確認
Windows APIは一枚岩ではありません。PowerShellから見ると、Win32はP/Invoke、COMはAutomation object、WinRTはWindows Runtime typeという異なる入口が見えます。
まず3つの入口を見る
Win32：Add-Type / P/Invoke
Add-Type @'
using System;
using System.Runtime.InteropServices;
public static class NativeDemo {
[DllImport("user32.dll")]
public static extern int GetSystemMetrics(int nIndex);
}
'@
"Win32 result = $([NativeDemo]::GetSystemMetrics(0))"
画面幅のpixel値が返れば、native DLLのfunctionを呼んでいます。
COM：ProgID
try {
$shell = New-Object -ComObject WScript.Shell
"COM type = $($shell.GetType().FullName)"
} finally {
if ($shell) { [void][Runtime.InteropServices.Marshal]::FinalReleaseComObject($shell) }
}
WinRT：Windows Runtime type
WinRTは型やAPIごとにPowerShellからの利用条件が異なります。ここでは無理に1行で「全部呼べる」とせず、MicrosoftのWindows Runtime資料から対象APIのsupport条件を確認してから個別TRYへ進みます。
ここを見る
flowchart TD P[PowerShell] --> W[Win32 / PInvoke] P --> C[COM / Automation] P --> R[WinRT / Runtime metadata] W --> OS[Windows native API] C --> APP[OfficeやAutomation component] R --> MOD[Modern Windows API]
同じWindows機能でも、呼び出し規約・型・lifetime・errorの見え方が違います。「新旧の優劣」ではなく、対象機能がどのAPI modelで公開されているかを見るのが先です。
1か所変えてみる
Win32例のGetSystemMetrics(0)をGetSystemMetrics(1)へ変えます。幅から高さへ値が変わり、整数定数がnative APIの意味を選んでいることが見えます。
仕事で使うなら
事務・情シスの自動化では、Excel操作ならCOM、Windowsの低レベル状態確認ならWin32、比較的新しいWindows機能ならWinRT候補、というように技術選定の地図として使えます。AIへコード生成を頼む際も「これはWin32/COM/WinRTのどれを使っている？」「64bit型や後始末は必要？」と確認すると、生成コードを二次レビューしやすくなります。
失敗・境界
Win32のpointer/handleは32/64bit差を無視しません。
COMはobject lifetimeとprocess残留を確認します。
WinRTはAPIごとのcontract、OS version、PowerShell/.NETからのprojectionを確認します。
Windows App SDK/WinUI 3をWinRTそのものと同一視しません。
