Windows 11でOpenGD77 CPSからBaofeng DM‑1701のコードプラグを読み書きしようとすると、CPSがCOM 3を表示していても通信に失敗する――そんなときの原因の大半はUSB‑シリアル／DFUドライバーの不整合です。本記事では、チップセットの特定から適切なドライバーの導入、OpenGD77での動作確認、さらに再発防止までを一気通貫で解説します。企業PCでも自作機でも通用する、実践的で安全性に配慮した手順だけを厳選しました。
症状の整理（よくあるサイン）
次のような現象が複合的に起きている場合、Windows 11標準の汎用ドライバー（usbser.sys）や、互換性のない新しすぎる/古すぎるドライバーが当たっている可能性が高いです。
- OpenGD77 CPS上では「COM 3」などのポートが選べるのに、READ/WRITEがタイムアウトする。
- デバイス マネージャーのポート (COMとLPT)やユニバーサル シリアル バス コントローラーに「！」や「不明なデバイス」が残る。
- イベント ビューアー（システム）に次のログが出るが、結果的に使えない。
Driver Management has concluded the process to add Service Serial
for Device Instance ID ROOT\PORTS\0000 with the following status: 0.
この「status: 0」は“追加処理自体は成功”を示しますが、DM‑1701のプログラミングに必要なドライバー（VCP/DFU）が一致していないため、CPSから実際のデータ通信が始められない状態です。
なぜ起こるのか（根本原因）
- ケーブルのチップセットが不明…Prolific/FTDI/WCH/CP210xなど複数系統が存在。Windows 11は汎用ドライバーで“とりあえずCOM化”しますが、プログラミング時の厳密な通信条件を満たさないことがあります。
- PL‑2303の世代/互換問題…一部の旧PL‑2303や互換チップは、最新ドライバーで抑止される場合があり、レガシー版の導入が必要です。
- DFU（ブートローダ）用ドライバー未導入…OpenGD77の書き込み経路は、通常の仮想COM（VCP）とは別にDFU/WinUSBドライバーを必要とします。VCPだけ入れても完結しません。
- 電源管理・COM番号競合…USBセレクティブサスペンドや古いゴーストCOMが影響し、安定接続を妨げます。
作業前の準備（安全第一）
- Windowsに管理者権限でサインイン。
- 既存のコードプラグをバックアップ（CPSでREADできない場合は別途メモしておく）。
- ドライバーは信頼できる入手元から取得し、ハッシュ確認などで改ざんリスクを下げる。
- セキュリティソフトやSmartScreenがブロックする場合があるため、導入時のみ一時的にリアルタイム保護を停止し、完了後ただちに元に戻す。
ケーブルのチップセットを特定する
まずは“相手を知る”こと。USBシリアルケーブルの刻印やラベルに「Prolific」「FTDI」等の記載がないか確認します。表記がなければ、以下の方法で確定します。
- ケーブルを抜いた状態で、デバイス マネージャー → ポート (COMとLPT)を開く。
- ケーブルを挿して直後に増えたデバイスを右クリック → プロパティ → 詳細 → プロパティ: ハードウェアIDを選択。
USB\VID_xxxx&PID_xxxxのVID（ベンダID）とPIDを控える。
| 代表的なVID（例） | 想定ベンダー/チップ系統 | 備考 |
|---|---|---|
0403 | FTDI（FT232R/FT232H 等） | 公式VCPが安定。偽造対策の影響は比較的少ない。 |
067B | Prolific（PL‑2303系） | 旧版が必要な個体あり。互換/クローンで弾かれることがある。 |
1A86 | WCH（CH340/CH341） | ドライバー導入で安定するケースが多い。 |
10C4 | Silicon Labs（CP210x） | 公式VCPで安定。 |
コマンドで確認したい場合は、管理者のコマンド プロンプトで以下も有効です。
pnputil /enum-devices /class Ports
またはPowerShellで:
Get-PnpDevice -Class Ports | Format-Table -AutoSize
必要なドライバーを用意する（VCPとDFUの二本立て）
DM‑1701でOpenGD77を正しく扱うには、USB‑シリアル（VCP）系ドライバーとDFU（ブートローダ）系ドライバーの両方が実機に合っている必要があります。
USB‑シリアル（VCP）ドライバーの方針
- Prolific系（PL‑2303）：Windows 11で互換性報告のあるレガシー版を導入。新しすぎる版では通信開始前に切断されることがあります。
- FTDI系：公式のVCPドライバーを利用。署名付きで安定しやすい。
- WCH（CH340/CH341）、Silicon Labs（CP210x）：各社の公式VCPを導入。
DFUドライバーの方針
OpenGD77のブートローダ書き換えやファーム転送で必要。多くの環境ではWinUSBベースのDFUドライバー（OpenGD77関連で配布されることが多い）を導入します。VCPだけ入れてもDFUが未整備だとCPSの転送フェーズで失敗します。
重要：いずれもサードパーティーを含む場合があります。配布元の正当性・ハッシュ値・署名・検疫結果を必ず確認してから使用してください。
既存ドライバーの削除と手動インストール
Windows任せの自動更新で“合わないドライバー”が即座に戻されることを防ぎつつ、確実に正しいものを適用します。
クリーンアップ手順
- ケーブルを抜く。
- デバイス マネージャーを開き、表示 → 非表示のデバイスの表示を有効化。
ポート (COMとLPT)、USBコントローラー配下にある関連デバイスを右クリック → デバイスのアンインストールを選び、「このデバイスのドライバー ソフトウェアを削除する」にチェックを入れて実行。 - 管理者コマンド プロンプトで、残留ドライバーをドライバーストアから完全削除（存在すれば）。
pnputil /enum-drivers | findstr /i "prolific ftdi ch341 cp210"
:: 例）該当oemXX.infを確認し、以下で削除
pnputil /delete-driver oemXX.inf /uninstall /force
手動インストール手順（推奨順序）
- DFUドライバーの準備（解凍してフォルダーを用意）。
- VCPドライバーの準備（ベンダー別に解凍）。
- DM‑1701をプログラムモード（電源投入時に特定キー押下）で起動し、ケーブル接続。
- デバイス マネージャーで新規に現れたデバイスを右クリック → ドライバーの更新 → コンピューターを参照してドライバーを検索 → ディスク使用からDFUドライバーのフォルダーを指定してインストール。
- いったんケーブルを抜き差しし、通常起動状態のDM‑1701を接続。不明なデバイス/USB Serialを右クリック → ドライバーの更新 → コンピューターを参照で、今度はVCPドライバーのフォルダーを指定してインストール。
- デバイス マネージャーのポート (COMとLPT)に、ベンダー名付きのデバイス（例：Prolific USB‑to‑Serial Comm Port (COMx)、USB Serial Port (FTDI) (COMx)など）が現れ、「！」が消えていることを確認。
動作確認（OpenGD77 CPS）
- DM‑1701をプログラムモードで起動し、PCと接続。
- OpenGD77 CPSを起動し、COMポート選択で、いま認識されたポート（COM番号）を選ぶ。
- READを実行。数秒～十数秒でコードプラグが読み出せれば成功。
- ファームやブートローダ更新が必要な場合は、CPSの該当メニューで実施（この時点でDFUドライバーが活きているはず）。
うまくいかないときの分岐（チェックリスト）
| 現象 | 考えられる原因 | 対処 |
|---|---|---|
| ポートに「！」が残る | 署名不一致/互換性不一致/古い残骸 | 再起動後に再インストール。pnputilで残留ドライバー削除→手動適用。 |
| COM番号は見えるがCPSがタイムアウト | VCPは適用済みだがDFUが未設定 | ブートローダ状態でDFUドライバーを再適用。CPS側で再検出。 |
| 時々つながるが安定しない | USB電源管理/ケーブル品質/ハブ経由 | USBハブを介さず直挿し。短いケーブルに変更。 USBルートハブのプロパティ→電源管理で「電力の節約…」のチェックを外す。 |
| インストール直後に別ドライバーに置換される | Windows Updateの自動適用 | インストール設定を一時的にデバイス優先へ。必要ならグループポリシー/ローカル設定で制御。 |
| COM番号が二桁台でCPSが検出しない | アプリ側のスキャン範囲外/過去のゴーストCOMが大量に残存 | ポートのプロパティ→詳細設定→COMポート番号を低番に変更。隠しデバイスのCOMを整理。 |
| まったく認識しない | 偽造/不良チップの可能性 | FTDI純正チップ搭載ケーブルへ置き換えを検討。 |
COMポート番号の最適化（衝突回避）
- ポート (COMとLPT)で該当デバイスを右クリック → プロパティ → ポートの設定 → 詳細設定。
- COMポート番号で未使用の低い番号（例：COM3〜COM9）に変更。
- 変更後はCPSでポートを再選択。
古いゴーストCOMを掃除したい場合、管理者コマンド プロンプトで以下を実行してからデバイス マネージャーを開くと、非接続の過去デバイスを削除できます。
set devmgr_show_nonpresent_devices=1
start devmgmt.msc
USB電源管理・セキュリティの調整（導入中のみ）
- USBセレクティブサスペンドの無効化（暫定）：電源オプション→詳細設定→USB設定→「無効」に。導入後は「有効」に戻すこと。
- セキュリティソフトのリアルタイム保護：署名付きドライバーでも稀にブロックされるため、導入操作の間だけ無効化→完了後すぐ有効化。
実践レシピ（最短で直す手順まとめ）
- ケーブルのVID/PIDを確認し、チップセットを特定。
- 該当チップ用のVCPドライバーと、OpenGD77向けのDFUドライバーを用意。
- デバイス マネージャーで関連デバイスをアンインストール（ドライバー削除にチェック）し、
pnputilで残骸を除去。 - DM‑1701をプログラムモードにして接続 → DFUドライバーを手動適用。
- 通常起動で接続 → VCPドライバーを手動適用。
- OpenGD77 CPSで新しいCOMポートを選択し、READ実行。
よくある質問（FAQ）
Q. Windows 11標準の「USB Serial Device (COMx)」のままではダメ？
A. 通信仕様が合わず、CPSでREAD/WRITEが不安定または不可になる事例が多数あります。ベンダー提供のVCPに置き換えるのが安全です。
Q. DFUドライバーはいつ必要？
A. コードプラグのREAD/WRITEはVCP経路でも、ブートローダ更新やファーム転送ではDFU/WinUSBが必須です。両方用意しておくと手戻りがありません。
Q. Prolific系でどのバージョンを入れるべき？
A. 個体差があり断定はできませんが、Windows 11で動作報告のあるレガシー版が安定する傾向にあります。新しすぎる版で切断される場合はレガシーを試す価値があります。
Q. COMが二桁台でCPSが見つけません。
A. デバイスの詳細設定→COMポート番号で低番に変更してください。隠しデバイスの掃除も有効です。
Q. 会社PCでインストールが拒否されます。
A. デバイスのインストール制限やWDAC/Defender制御の可能性があります。IT部門の承認を得るのが確実です。
再発防止のポイント
- ドライバーのバックアップ：適用後に
pnputil /export-driverで保存しておくと復旧が速い。 - Windows Update直後の挙動確認：VCPが入れ替わっていないか、CPSでREADテストをする。
- 予備ケーブルの用意：信頼できるFTDI純正チップ搭載ケーブルを一本常備すると現場対応が楽になります。
トラブルの見極めフロー
- CPSでREAD失敗 → デバイス マネージャーでベンダー名つきのCOMが見えるか？
→ No：VCP未適用。VCPを手動適用。
→ Yes：DFU未適用の可能性。ブートローダ状態でDFU適用。 - それでも不安定 → USB直挿し・ケーブル交換・COM番号最適化・電源管理無効を順に試す。
- 依然不可 → PL‑2303互換/偽造疑い。FTDI純正ケーブルに変更。
実運用で役立つ小ワザ
- デバイス名の固定：複数のUSB‑シリアルがある環境では、同じ物理ポートに挿す運用を徹底し、COM番号の変動を抑える。
- 携行ドライバーセット：VCP/DFUのインストーラーとハッシュ値をまとめてUSBに入れておく（オフライン現場用）。
- ログの活用：CPSのログ出力（ある場合）とWindowsのイベント ビューアーを突き合わせ、切断のタイミングを特定すると原因箇所が見えます。
まとめ（要点再掲）
Windows 11標準の汎用USB‑シリアルは、Baofeng DM‑1701のプログラミングケーブルで“見えるけれど話せない”状況を引き起こしがちです。回復の近道は、
- ケーブルのチップセットを特定（VID/PIDで確認）
- 対応するVCPとOpenGD77用DFUの両方を手動導入
- COM番号最適化やUSB電源管理の見直しで安定化
- 不良/互換性に難のある個体はFTDI純正チップ搭載ケーブルへ置換
この一連の対処で、OpenGD77 CPSからのコードプラグ読み書きはほぼ確実に復旧します。ドライバーは“合っていれば速い、合っていなければ永遠に進まない”。まずは正体を突き止め、正しいドライバーを確実に当てる――それが最短ルートです。
付録：画面操作パス（日本語UIの目安）
- デバイス マネージャーの開き方：スタート → 右クリック → デバイス マネージャー
- ハードウェアIDの確認：対象デバイス → 右クリック → プロパティ → 詳細 → プロパティ: ハードウェアID
- ドライバーの手動適用：右クリック → ドライバーの更新 → コンピューターを参照して検索 → ディスク使用
- COM番号変更：プロパティ → ポートの設定 → 詳細設定 → COMポート番号
- USB電源管理：ユニバーサル シリアル バス コントローラー → USB ルート ハブ（複数あり）→ プロパティ → 電源管理
付録：コマンド スニペット集
ドライバー一覧から該当を検索
pnputil /enum-drivers | findstr /i "prolific ftdi ch34 cp210"
該当ドライバーを強制削除（例）
pnputil /delete-driver oemXX.inf /uninstall /force
現在のポートデバイス確認（PowerShell）
Get-PnpDevice -Class Ports | Sort-Object -Property Status -Descending | Format-Table -AutoSize
隠しデバイスの可視化
set devmgr_show_nonpresent_devices=1
start devmgmt.msc
付録：トラブル対応メモ（現場用）
- 導入時はUSBハブ/延長ケーブルを避ける（直結推奨）。
- 2つ以上のUSB‑シリアルが同時に接続されていると、CPSが別ポートを掴むことがあるので、一時的に外す。
- 企業管理PCではデバイス制御がかかる場合があるため、事前に承認申請を取る。
- READが通ってもWRITEで失敗する場合は、DFUドライバーが未適用/不完全の可能性が高い。
- Windows再起動後にドライバーが別物に置換される場合は、ローカルグループポリシーで自動ドライバー更新を一時停止し、安定後に戻す。
要約（一目で理解）
| やること | 目的 | ゴール指標 |
|---|---|---|
| VID/PIDでチップ判定 | 正しいVCP/DFUを選定 | ベンダー名付きCOMが出現 |
| 既存ドライバーの完全削除 | 不整合の再発防止 | pnputilで残留なし |
| DFU→VCPの順で手動適用 | OpenGD77の両経路を整備 | READ/WRITEとブートローダ更新が成功 |
| 電源管理・COM番号の最適化 | 安定接続と確実な検出 | 連続で失敗しない |
| 問題個体はFTDI純正へ更新 | 物理層の不確実性排除 | 再現性高く通信可能 |
この手順に沿えば、「ポートは見えるのに読めない/書けない」という悩みは解消します。あとは運用時にドライバー更新やCOM競合を招かないよう、同じUSBポートを使う・導入物を記録する・バックアップを取る――この3点を徹底すれば、Windows 11とDM‑1701の組み合わせは安定して“働く相棒”になります。
コメント