Sage X3移行で出る「ODBC Driver 18 / SSL Provider 証明書チェーンが信頼されない」エラーの原因と対処法（sqlcmd／SQL Server 2025環境）

Sage X3 v12p38でフォルダインポート（SVG import）を長時間かけて完走した直後、最後の _adxmiglive3seq.bat 実行フェーズで sqlcmd が落ち、「The certificate chain was issued by an authority that is not trusted」で構成が中断される——この症状は、SQL自体の障害というより“クライアント側ツールの暗号化既定値変更”で起きることが多いです。特に Microsoft ODBC Driver 18 系を経由する sqlcmd では、証明書検証が絡む接続が標準になり、自己署名証明書や社内CA未配布の環境で一気に表面化します。 Microsoft Learn+1

Sage X3移行で出る「ODBC Driver 18 / SSL Provider 証明書チェーンが信頼されない」エラーの原因と対処法（sqlcmd／SQL Server 2025環境）

何が起きているか（ログの読み解き）

提示ログは、テーブルロード自体は 1195/1195 完了した後、バッチ生成→送信→起動の段階で失敗しています。

Launching _adxmiglive3seq.bat ... の直後に Sqlcmd: Error: Microsoft ODBC Driver 18... SSL Provider... not trusted
続いて Client unable to establish connection
さらに The process cannot access the file because it is being used by another process.

つまり「X3のデータ移行が壊れた」というより、バッチ内で呼ばれた sqlcmd がSQLへ接続できず終了し、後段でファイルロック系の副作用メッセージも出ている、という構図です。

根本原因：ODBC Driver 18 の“暗号化が既定でON”問題

MicrosoftのODBC Driver 18（および新しめの関連ツール）は、接続暗号化の既定値が Encrypt=Yes に変わりました。暗号化するだけでなく、サーバー証明書の検証が絡むため、サーバーが自己署名証明書だったり、証明書チェーンのルートCAがクライアント側（Sage X3 アプリ／管理コンソールを動かす側）で信頼されていないと、今回のエラーになります。 Microsoft Learn+2Microsoft Learn+2

ポイントはここです。

SQL Serverのインストールやライセンス形態そのものが原因とは限らない
むしろ、環境に入った sqlcmd が ODBC Driver 18 を使う系統に変わったことで、今まで見えていなかった証明書問題が顕在化しやすい curatedsql.com+1

「Standard 2025（VL）では問題が出なかった」という差は、入っているクライアントツール／ドライバーの世代差（ODBC 17相当 vs 18相当、あるいは sqlcmd の挙動差）で説明できるケースが多いです。 Microsoft Learn+1

まず復旧させる“短期回避策”（検証環境向け）

本番では後述の正攻法がおすすめですが、評価・検証の移行を進めるための回避策を先にまとめます。

1) sqlcmd に「証明書検証を緩める」オプションを付ける

sqlcmd は暗号化・証明書検証の扱いを切り替えるオプションがあります。mssql-tools側の説明でも、ODBC Driver 18 の変更に伴い sqlcmd が証明書検証を行う前提になったこと、必要に応じて Optional encryption に落とすことが案内されています。 Microsoft Learn+1

-No：暗号化を「Optional」にする（環境によってはこれで通る）
-C：証明書チェックを“通す”方向の指定（自己署名などでの回避に使われることが多い）

Sage X3 が生成する _adxmiglive3seq.bat の中で sqlcmd を呼んでいるなら、その呼び出し行に -No や -C を付与できるかが最短ルートです（ただし、生成バッチなので再生成で戻る点に注意）。

2) 接続文字列側で TrustServerCertificate を使う（呼び出し方式による）

もし sqlcmd ではなくODBC接続文字列を組み立てる方式（DSN/接続パラメータ）をどこかで持っているなら、TrustServerCertificate=yes が典型的な回避策です。Microsoft側でも、自己署名証明書などの場合の選択肢として示されています。 Microsoft Learn+1

3) どうしても急ぐなら「ODBC Driver 17 を使う」

Microsoftのトラブルシュートでも、アップグレード後の回避として ODBC Driver 17 を使う案が明示されています。 Microsoft Learn+1
Sage X3や周辺ツールがどのドライバーを拾うか（PATHやODBC設定、同梱コンポーネント）次第ですが、評価環境で“先に移行を通す”目的なら現実的です。

正攻法：SQL Server側に“信頼される証明書”を配置する

恒久対応は、SQL Serverが提示するサーバー証明書を クライアントが信頼できるチェーンにすることです。要は次のどちらか。

公的CA／社内CAで発行したサーバー証明書をSQL Serverに割り当てる
自己署名なら、その自己署名証明書（または発行元CA）をクライアント側の信頼済みに入れる

Microsoftの説明でも「証明書チェーンを検証できないこと」が原因であり、解決策として 信頼される証明書に変える／自己署名を信頼ストアに追加することが挙げられています。 Microsoft Learn+2Microsoft Learn+2

実務的には、社内AD CSがあるならそこでサーバー証明書を発行し、Sage X3アプリサーバー（またはコンソール実行ホスト）へ ルートCA証明書を配布するのが一番スムーズです。

併発している「ファイルを別プロセスが使用中」への対応

末尾の
The process cannot access the file because it is being used by another process.
は、SSLエラーで落ちた後にバッチやログが中途半端に残ったり、リアルタイムスキャン（ウイルス対策）がバッチ／生成物を掴んで発生することがあります。対処の優先順位はこうです。

同じインポート／コンソール処理を並列で走らせない（タスクスケジューラや再実行の二重起動を潰す）
c:\Sage\X3V12\folders\<folder>\SVG\ 配下をスキャン除外（検証環境でも効果が大きい）
失敗した _adxmiglive3seq.bat や関連プロセス（cmd/sqlcmd）が残っていないか確認してから再実行

ただし、ここは“主因”というより SSLで止まった結果として出やすい副作用なので、まず証明書問題を解決する方が再発率を下げられます。

まとめ：評価版の罠ではなく「暗号化既定値変更」への追随が本質

今回の症状は、Sage X3移行の最終局面で sqlcmd が ODBC Driver 18 由来の暗号化・証明書検証に引っかかって止まっている可能性が高いです。 Microsoft Learn+2Microsoft Learn+2

早く通す：sqlcmd に -No / -C、または TrustServerCertificate の回避（検証向け）
きちんと直す：SQL Serverへ信頼される証明書を割り当て、クライアントへCAを配布

この順で手当てすると、移行の手戻りを最小化できます。