Windows デスクトップアプリを日本法人が安全に配布する — コード署名・SmartScreen の現実（2026 年版）

Windows 向けにデスクトップアプリを配ろうとすると、最後に必ず一つの壁にぶつかります。署名のないインストーラを実行すると、Windows は青い Microsoft Defender SmartScreen の警告画面を出し、「発行元不明のアプリ」としてユーザーの手を一度止めます。アンチウイルスが実行ファイルを隔離してしまうこともある。せっかく作ったアプリが、配布の最後の一歩で信頼されないわけです。

この壁を日本法人が最短で越えるための実務手順を、2026 年 6 月時点の前提でまとめます。対象は、カーネルドライバを含まない一般的なユーザーモードのデスクトップアプリで、不特定または広範な Windows ユーザーへ配布する、というよくあるケースです。先に結論を出してから、その結論に至る判断材料（証明書の種類・最近のルール変更・落とし穴）を順に解いていきます。

結論 — 現実解は二つに絞れる

この問題の答えは、実務上ほぼ二つの構成に収束します。どちらを選ぶかは「自社サイトからの配布が必須か」「Microsoft Store 掲載が許容されるか」でほぼ決まります。

Microsoft 自身も配布パスの選択ガイドで、広く配布するなら Store を推奨し、Store 外配布では SmartScreen の評判を別途積み上げる必要があると明示しています。つまり「初回からの警告ゼロ」を最優先するなら Store MSIX、「既存のビルド運用に最も載せやすいこと」を最優先するなら署名済みインストーラの自社配布、という二択です。

ここで一つ、強調しておくべき前提があります。EV 証明書を買えば SmartScreen を即座に黙らせられる、という以前の常識は 2026 年時点ではもう成り立ちません。次節で理由を説明します。

なぜ「署名すれば警告ゼロ」にならないのか

かつて、EV（Extended Validation）コード署名証明書には「署名した瞬間から SmartScreen が肯定的に評価する」という特典がありました。多くのガイドが「一般配布には EV を買え」と書いていたのは、この即時バイパス効果が理由です。

ところがこの挙動は 2024 年に消滅しました。Microsoft の公式ドキュメントは、EV 証明書はもはや SmartScreen をバイパスしないこと、SmartScreen 回避だけのために EV のプレミアムを払う合理性はもうないことを明記しています。現在は EV・OV を問わず、Store 外配布の新しいバイナリは file hash reputation（ファイルハッシュの評判）と publisher reputation（発行元の評判）を、時間と実際のダウンロード実績で積み上げる必要があります。

この変化が意味するのは、署名は必要条件ではあっても十分条件ではない、ということです。署名のないバイナリは公開配布に不向きですが、署名したからといって初回の警告が消えるわけではない。SmartScreen の評判は、同一の発行元で署名し続け、クリーンなダウンロード実績を重ねるなかで初めて蓄積されていきます。

したがって EV と OV の実務的な差は、今や次の点に集約されます。

• EV は Windows のカーネルモードドライバ署名に必須。一般的なユーザーモードアプリには関係しない
• EV は発行元名が「検証済み発行元」として表示される。ブランディング上の価値はあるが、警告を消す効果はない
• EV は審査が厳格で発行が遅く、費用も高い

ドライバ署名や厳格な調達・監査要件がない限り、2026 年時点では OV（標準コード署名）で十分です。SmartScreen の効果が同じなら、安く・早く出せる OV のほうが費用対効果で勝ります。

落とし穴 — Azure Trusted Signing は日本法人が使えない

コード署名のコストを調べると、必ず目に留まるのが Microsoft 自身のクラウド署名サービス Azure Trusted Signing（現在は Azure Artifact Signing へ改称済み、旧称 Trusted Signing）です。月額 9.99 USD という破格の安さで、FIPS 140-2 Level 3 の HSM、毎日発行される短命証明書、GitHub Actions 統合まで揃っており、技術的には文句のない選択肢に見えます。

しかしここに最大の落とし穴があります。Microsoft Learn の公式 FAQ は、Public Trust 証明書の対象を「米国・カナダ・EU・英国の組織、および米国・カナダの個人開発者」と明記しており、日本はこのリストに入っていません。つまり日本法人は Azure Trusted Signing を利用できません。安価なクラウド署名という近道が日本企業には塞がれているため、本記事の推奨からは外します。

この事実が、日本法人の選択肢を決定づけます。安価なクラウド署名が使えない以上、従来型 CA が発行する OV/EV 証明書を取得するのが、当面は唯一の現実解になります。なお Microsoft は対象地域の拡大を表明しているため、導入前には最新の対象国リストを必ず確認してください。日本が追加されたら、月 9.99 USD のこのサービスへ全面移行を検討する価値があります。

コード署名証明書を選ぶ

OV と EV、そしてハードウェア鍵保管の必須化

証明書を選ぶ前に、もう一つ押さえておくべきルール変更があります。CA/Browser Forum の Code Signing Baseline Requirements により、2023 年 6 月以降は OV・EV を問わず、秘密鍵を FIPS 140-2 Level 2 または Common Criteria EAL 4+ 相当以上のハードウェア（HSM・USB トークン・クラウド HSM）で生成・保管することが必須になりました。鍵はエクスポート不可でなければなりません。

この変更には実務上の大きな含意があります。秘密鍵を .pfx ファイルにエクスポートして CI に置く、という従来の自動署名方式が使えなくなったのです。GlobalSign の公式案内も、証明書を直接 FIPS 準拠デバイスにインストールする必要があり、.pfx 形式でのダウンロードはできなくなったと明記しています。「OV は安くてソフトウェア鍵で手軽」という以前のメリットは、これで消えました。OV も EV も、ハードウェア保管が前提です。

日本法人にとっての CA 比較

日本法人にとって最も扱いやすい候補は GMO グローバルサインです。日本語の公式申請ガイドが整っており、円建ての価格と最短発行日数が公開され、英文法人名の扱いも日本法人向けに案内されています。国内法人として円建て・後払い・適格請求書での調達がしやすい点は、経理処理まで含めた実務で効いてきます。

CI/CD での完全自動化を最優先するなら、トークンの物理挿入が要らないクラウド HSM 署名が向きます。SSL.com の eSigner はフルクラウドで HSM の自前用意が不要、DigiCert KeyLocker は FIPS 140-2 Level 3 で高ボリューム署名に対応します。一方、月のビルド回数が少なく手元署名で足りるなら、GMO グローバルサインの標準トークン型が最も安く、最も簡単です。

なお証明書の有効期間は短縮傾向にあります。CA/Browser Forum の Ballot CSC-31 により、2026 年 3 月 1 日からコード署名証明書の最大有効期間が約 460 日（約 15 か月、従来の 39 か月から短縮）に制限されました。更新サイクルが従来より短くなる前提で運用計画を立ててください。

申請前に固めておくべき書類

GMO グローバルサインの新規申請ガイドは、英文組織名について国税庁の法人番号公表サイトに登録された英語表記・登記簿の英文字商号・定款・印鑑証明書などで確認できると明記しています。つまり、申請前に英文商号の整合性を固めておくことが、最短発行のボトルネックを避ける鍵です。法務局は登記事項証明書・印鑑証明書のオンライン請求に対応しているので、急ぐなら事前にオンライン請求しておきます。

標準コード署名なら最短手順のタイムラインは概ね次のようになります。EV は審査が厳格な分だけ後ろにずれます。

gantt
    title 最短の自己配布ルート
    dateFormat  YYYY-MM-DD
    axisFormat  %m/%d

    section 事前準備
    英文法人名・法人番号の確認        :a1, 2026-07-01, 1d
    登記事項証明書等の手配            :a2, 2026-07-01, 2d

    section 標準コード署名
    標準証明書を申請                  :b1, after a1, 1d
    CA 審査                          :b2, after b1, 3d
    トークン受領・ドライバ設定        :b3, after b2, 1d
    署名テスト                        :b4, after b3, 1d
    インストーラのビルド・署名        :b5, after b4, 1d
    配布サイト公開                    :b6, after b5, 1d
    SmartScreen 評判の蓄積            :b7, after b6, 14d

    section EV コード署名
    EV を申請                        :c1, after a1, 1d
    申請書類を提出                    :c2, after c1, 1d
    EV 審査                          :c3, after c2, 7d
    トークン受領・設定                :c4, after c3, 1d
    インストーラのビルド・署名        :c5, after c4, 1d
    配布サイト公開                    :c6, after c5, 1d
    SmartScreen 評判の蓄積            :c7, after c6, 14d

SmartScreen の評判蓄積は日数固定ではなく、利用実績に依存します。タイムラインの最後の 14 日は目安にすぎません。

SignTool で署名する

Windows の公式署名ツールは SignTool（Windows SDK 同梱）です。新しい SDK では /fd・/td の指定が事実上必須で、SHA256 が推奨されます。そして RFC 3161 準拠のタイムスタンプ（/tr・/td）は強く推奨されます。タイムスタンプを付けておくと、証明書が失効・期限切れになった後も署名検証が継続でき、インストールが受理され続けます。必ず有効化してください。

トークンに格納された証明書を Windows の My ストアから選択して署名する例です。THUMBPRINT は証明書の SHA-1 サムプリントに置き換えます。

# 主要バイナリに署名
signtool sign `
  /sha1 THUMBPRINT `
  /s My `
  /fd SHA256 `
  /tr http://timestamp.digicert.com `
  /td SHA256 `
  .\dist\MyApp.exe
 
# インストーラに署名
signtool sign `
  /sha1 THUMBPRINT `
  /s My `
  /fd SHA256 `
  /tr http://timestamp.digicert.com `
  /td SHA256 `
  ".\dist\MyApp Setup 1.0.0.exe"
 
# 署名を確認
signtool verify /v ".\dist\MyApp Setup 1.0.0.exe"

最終インストーラは必ず署名し、実務上は同梱する主要な .exe・.dll も署名しておくのが無難です。Microsoft Store の提出要件でも、インストーラと PE ファイルを信頼できる CA 連鎖で署名することが求められており、Store 外配布でもこの水準に合わせておくと検証・誤検知対応・顧客説明のすべてで有利になります。

実行ファイルのメタデータ（CompanyName・ProductName・FileDescription・FileVersion）も必ず埋めてください。後述するアンチウイルスベンダーの誤検知審査で、これらの情報の有無が確認対象になります。

CI/CD でのクラウド HSM 署名

ハードウェア鍵保管が必須になった今、GitHub Actions のようなクラウド CI で自動署名するには、クラウド HSM 署名サービスを使います。各サービスの CLI（SSL.com の CodeSignTool、DigiCert KeyLocker の CLI など）をビルドパイプラインから呼び出し、HSM 上の鍵で署名する形です。クラウド CI で署名する際のハマりどころを挙げておきます。

• PFX 方式が使えない: ハードウェア鍵保管必須化により、秘密鍵を CI に置く従来方式は不可。クラウド HSM 署名で回避する
• EV トークンの物理挿入: USB トークン型 EV はサーバへの物理挿入が必要でクラウド CI に向かない。クラウド HSM 署名なら回避できる
• 署名漏れ: 配布物に含まれる実行ファイルやインストーラのうち、署名対象を取りこぼすと検証や評判蓄積でつまずく。署名対象を明示的にリスト化しておく

インストーラ形式と配布チャネルを決める

インストーラ形式

一般配布の EXE インストーラ、企業配布の MSI、Store・サンドボックス向けの MSIX が主な選択肢です。署名・配布の観点で整理すると次のようになります。

配布チャネル

自社サイトからの直接配布以外にも、補助的なチャネルがあります。目的に応じて組み合わせます。

警告を確実にゼロにしたいなら、自社サイト配布と並行して Microsoft Store（MSIX）にも登録するのが最も強い手です。Microsoft が自動的に再署名し、SmartScreen 警告も出ず、ホスティング・配信・自動更新まで無料で担ってくれます。ストア審査と MSIX 化の手間はかかりますが、一般消費者向けで初回警告のクレームが多いなら、Store をメインチャネルに格上げする価値があります。

企業内配布には注意が要ります。一般的な EXE インストーラは per-user 構成になりがちで、Intune のシステムコンテキスト配布には per-machine が必要です。Microsoft の推奨は、per-machine の MSI（ALLUSERS=1）を生成して .intunewin 化することです。なお法人顧客は WSUS・Intune・SCCM のロールアウトでバージョンを固定したいため、独立した自動更新機能をむしろ嫌うことが多い点も覚えておきます。

継続的に更新するプロダクトなら、更新バイナリも本体と同じ証明書で署名し、配布前に署名検証まで確認してください。更新の仕組みは配布形式に依存します（MSIX なら App Installer や Store、自社配布なら独自の更新機構）。更新経路は新しいバイナリを継続的にユーザーへ届ける経路なので、ここが未署名だと評判の積み上げが途切れます。

SmartScreen 評判を育て、誤検知に備える

評判を育てる運用

自社配布では「証明書を買えば終わり」ではなく「評判を育てる運用」が必要です。SmartScreen の評判を早く・確実に蓄積するための原則は次のとおりです。

• 毎リリース必ず同一の発行元 ID で署名する。未署名や発行元の変更は評判をゼロから積み直すことになる
• 署名後にファイルを改変しない。署名が壊れて評判が無効になる
• 不要なバンドル・広告同梱・ホームページ変更系の挙動を入れない。PUA（望ましくない可能性のあるアプリ）判定の主因になる
• 配布先 URL を HTTPS の公式ドメインに統一し、頻繁に変えない。第三者ダウンロードサイトや怪しい広告ネットワークを経由しない
• 証明書を頻繁に変えない。評判は証明書サムプリント単位で蓄積され、更新で評判が引き継がれない問題がある

クリーンな Windows 10/11 の VM で、ブラウザのダウンロードから実際にインストールし、SmartScreen の挙動を記録してください。SmartScreen はインターネット由来のダウンロードと実行で評価されるため、社内共有フォルダからの実行確認だけでは不十分です。

誤検知に備える

広く使われているデスクトップアプリでも、過去に Microsoft Defender で誤検知された実績があります。2022 年 9 月 4 日には、Microsoft が配信した Defender のシグネチャ更新が Chrome・Edge・Discord などを一斉に誤検知し、修正版シグネチャで解消した事例がありました。誤検知はいつでも起こり得る前提で、提出窓口を整えておきます。

主要ベンダーの誤検知提出窓口は次のとおりです。提出時には共通して、デジタル署名・VERSIONINFO・配布元 URL・製品説明・検知名・ハッシュ・使用しているインストーラ技術などを求められます。

誤検知時の標準フローは、再現 → 検知ソースの切り分け（AV・EDR・PUA・SmartScreen のどれか）→ 提出 → 再スキャン → 必要に応じた一時除外 → 定義更新の確認 → 再配布です。Microsoft は開発者 FAQ で、既知リストや誤検知防止の事前登録プログラムは受け入れないと明記する一方、信頼されたルート機関の証明書で一貫して署名することは研究チームが発行元を識別しやすくなると説明しています。つまり、独自ホワイトリスト申請に頼るのではなく、継続的な正規署名と適切なサンプル提出が基本線になります。

なお、単に評判が未確立（uncommon）なだけの場合は誤検知ではないため、提出フォームの対象外です。この場合は評判の蓄積を待つしかありません。

実行チェックリスト

最後に、日本法人が最短で自己配布を始めるためのチェックリストをまとめます。Store へ出す場合も、前半の整備作業はほぼそのまま有効です。

申請前:

• 英文法人名を確定し、国税庁の法人番号公表サイトの英語表記と整合させた
• 必要なら登記事項証明書・印鑑証明書をオンライン請求した
• カーネルドライバを含まないことを確認し、EV が本当に必要か見直した
• 調達先を GMO グローバルサイン第一候補とし、DigiCert・Sectigo・SSL.com eSigner と比較した

ビルド前:

• CompanyName・ProductName・FileDescription・FileVersion を埋めた
• インストーラ形式を決めた（一般配布は EXE/MSIX、企業配布は MSI）
• 余計なバンドルや広告コンポーネントを入れていない
• 配布先 URL を HTTPS の公式ドメインに統一した

リリース前:

• 主要 .exe・.dll・最終インストーラに署名した
• RFC 3161 タイムスタンプを付けた
• signtool verify で署名を確認した
• クリーンな Windows 10/11 VM でブラウザダウンロードから検証し、SmartScreen の挙動を記録した
• 誤検知に備えて SHA256・検知画面・配布 URL を保管した

配布後:

• ダウンロード数とインストール成功率を追っている
• SmartScreen/AV 警告の報告窓口を用意した
• Defender・Avast・ESET・Symantec の提出先テンプレートを整備した

まとめ

日本法人が今すぐ Store 外で安全に配布を始める最短手順を一文でまとめると、こうなります。GMO グローバルサインの標準コード署名証明書を取得し、署名済みインストーラを作り、SignTool で SHA256 + RFC 3161 タイムスタンプ署名して、公式 HTTPS サイトから配布し、初回の誤検知は各ベンダーへ即提出する。もし Store 掲載が可能なら、それより強い解は MSIX で Microsoft Store に出すことです。

2026 年の現実として押さえるべきは三点です。Azure Trusted Signing の安さは魅力的だが日本法人は対象外。EV を買っても SmartScreen の即時バイパスはもう手に入らない。そして署名は評判を育てる運用の出発点であって、終点ではない。この三点を踏まえれば、証明書選定から運用までの判断を、迷わず最短経路でつなげられます。

以上、Windows デスクトップアプリを日本法人が安全に配布する手順を、現場からお送りしました。

参考情報

• Microsoft: 配布パスの選択
• Microsoft: コード署名のオプション
• Microsoft: SmartScreen の評判ベースの保護
• Microsoft: SignTool
• Microsoft: 開発者向け FAQ（誤検知・SmartScreen）
• Microsoft: WDSI ファイル提出フォーム
• Microsoft: Azure Trusted Signing
• Microsoft: Windows パッケージマネージャー（winget）
• Microsoft Intune
• CA/Browser Forum: Code Signing Working Group
• GMO グローバルサイン: コードサイニング証明書
• DigiCert: コード署名証明書の比較
• DigiCert: KeyLocker
• Sectigo: Code Signing
• SSL.com: eSigner
• 国税庁: 法人番号公表サイト
• 法務局: 登記事項証明書等のオンライン請求