知識マップ: WinForms / WPFアプリのCI/CD実践 ── GitHub Actionsでビルドから署名・配布まで自動化する

記事「WinForms / WPFアプリのCI/CD実践 ── GitHub Actionsでビルドから署名・配布まで自動化する」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

WinForms/WPFデスクトップアプリのCI/CDは、まずwindows-latestランナーでのビルド+テストの自動化だけを入れることが実務の出発点で、次にv1.2.3のようなタグのpushでバージョンを注入するタグ駆動リリースを組み、成果物をGitHubリリースへ長期保管する。最大の壁はコード署名の自動化で、2023年6月以降は公的なOV証明書の秘密鍵がHSM保管必須になったため、日本では対象外のAzure Artifact Signingに頼れず、CAのクラウドHSMオプションか手元での署名工程が現実解になる。署名用シークレットは承認者付きのGitHub Actions Environmentに置かないと、書き込み権限を持つ人がワークフローを書き換えるだけで鍵を取り出せてしまう。配布形式ではxcopyが最も組み込みやすく、MSIXは署名が必須、ClickOnceはコマンドラインでの発行に癖がある。

flowchart LR
    accTitle: WinForms/WPFアプリのCI/CDパイプラインの知識マップ
    accDescr: GitHub Actionsを使ったWinForms・WPFデスクトップアプリのビルド・タグ駆動バージョン採番・コード署名・配布形式ごとの自動化がどう連鎖し、署名鍵の管理がどのリスクと結び付くかを示す図。
    desktop_app_cicd_pipeline["デスクトップアプリのCI/CDパイプライン"]
    github_actions["GitHub Actions"]
    windows_runner["Windowsランナー(windows-latest)"]
    windows_forms["Windows Forms"]
    wpf["WPF"]
    build_test_automation["ビルド+テストの自動化"]
    code_signing_cert["コード署名証明書"]
    tag_driven_versioning["タグ駆動リリース(バージョン採番)"]
    github_release["GitHubリリース"]
    hsm_key_storage["HSM/トークンでの秘密鍵保管"]
    azure_artifact_signing["Azure Artifact Signing"]
    github_actions_environment["GitHub Actions Environment(承認者付き環境)"]
    signing_key_exposure_risk["署名鍵の窃取リスク"]
    github_actions_secrets["GitHub Actionsのシークレット"]
    signtool["SignTool"]
    code_signing_timestamp["コード署名のタイムスタンプ"]
    msix["MSIX"]
    xcopy_distribution["xcopy配布(zip)"]
    clickonce["ClickOnce"]
    msi["MSI(Windows Installer)"]
    desktop_app_cicd_pipeline -.->|"利用する"| github_actions
    desktop_app_cicd_pipeline -.->|"前提とする"| windows_runner
    windows_forms -.->|"前提とする"| windows_runner
    wpf -.->|"前提とする"| windows_runner
    desktop_app_cicd_pipeline -->|"利用する"| build_test_automation
    build_test_automation -.->|"より先に行うべき"| code_signing_cert
    desktop_app_cicd_pipeline -->|"利用する"| tag_driven_versioning
    tag_driven_versioning -.->|"利用する"| github_release
    desktop_app_cicd_pipeline -.->|"前提とする"| code_signing_cert
    code_signing_cert -.->|"前提とする"| hsm_key_storage
    hsm_key_storage -.->|"両立しない"| windows_runner
    azure_artifact_signing -.->|"推奨される対応"| github_actions
    github_actions_environment -->|"軽減する"| signing_key_exposure_risk
    github_actions_secrets -.->|"原因になり得る"| signing_key_exposure_risk
    code_signing_cert -.->|"で構成できる"| github_actions_secrets
    signtool -->|"利用する"| code_signing_cert
    signtool -.->|"利用する"| code_signing_timestamp
    msix -->|"前提とする"| code_signing_cert
    xcopy_distribution -.->|"推奨される対応"| github_actions
    tag_driven_versioning -.->|"推奨される対応"| clickonce
    desktop_app_cicd_pipeline -.->|"利用する"| msi

概念間の関係(全21件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

デスクトップアプリのCI/CDパイプラインはGitHub Actionsを利用します。本記事はGitHub Actionsを前提に、WinForms/WPFデスクトップアプリのCI/CDパイプラインをビルド・テスト・署名・配布のステップとして組み立てる。同じパイプラインはAzure DevOpsやJenkins、GitLab CIなど別のランナーでも構成でき、GitHub Actionsが必須なわけではない。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
デスクトップアプリのCI/CDパイプラインはWindowsランナー(windows-latest)を前提とします。UIに依存するテストやWindows専用のパッケージング・署名など、実行を伴う手順を含む場合、WinForms/WPFデスクトップアプリのCI/CDパイプラインはGitHub Actionsのwindows-latestのようなWindowsランナーを前提とする。EnableWindowsTargetingでのビルドと環境非依存のテスト、xcopy形式の成果物だけならLinuxランナーでも通る。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Windows FormsはWindowsランナー(windows-latest)を前提とします。WinFormsプロジェクトはWindows専用TFMを対象とするが、EnableWindowsTargetingを有効にすればLinux上でもビルドできる。Windowsランナーが要るのは、UIに依存するdotnet testのように実行を伴う手順である。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
WPFはWindowsランナー(windows-latest)を前提とします。WPFプロジェクトも同様にWindows専用TFMを対象とするが、EnableWindowsTargetingを有効にすればLinux上でもビルドできる。Windowsランナーが要るのは実行を伴う手順である。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
デスクトップアプリのCI/CDパイプラインはビルド+テストの自動化を利用します。CI/CD導入の第一段階は、pushのたびにwindows-latestランナーでdotnet build/testが走り成果物を取り出せる、ビルド+テストの自動化である。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
ビルド+テストの自動化はコード署名証明書より先に行うべきです。署名・配布の自動化より先に、まずビルド+テストの自動化だけを入れるのが実務の順序であり、最初から全部を組もうとすると署名周りで止まりがちになる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
デスクトップアプリのCI/CDパイプラインはタグ駆動リリース(バージョン採番)を利用します。バージョン採番はv1.2.3のようなタグのpushをトリガーに、タグの値をMSBuildのVersionプロパティへ注入するタグ駆動リリースが実務の落としどころになる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
タグ駆動リリース(バージョン採番)はGitHubリリースを利用します。GitHub Actionsで組んだパイプラインでは、タグビルドの成果物はActionsアーティファクトの保持期限を避けるため、GitHubリリースへ添付して長期保管する。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
デスクトップアプリのCI/CDパイプラインはコード署名証明書を前提とします。Store外で配布するWindowsアプリにコード署名が実質必須であるため、配布物の完成を出口とするCI/CDパイプラインは公的なコード署名証明書を前提とする。ビルド+テストだけの最小段階では不要。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
コード署名証明書はHSM/トークンでの秘密鍵保管を前提とします。2023年6月以降にCA/Browser Forumの要件に基づき新規発行される公的なOV/EV証明書は、秘密鍵をHSMまたはハードウェアトークンで保管することが必須になった。社内CA発行や既存のPFX証明書はこの要件の対象外。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
HSM/トークンでの秘密鍵保管はWindowsランナー(windows-latest)と両立しません。USBトークン型のハードウェア保管はGitHubホステッドランナーに物理的に挿せないため、そのままではCIでの完全自動署名ができない。CAのクラウドHSMオプションを使えばこの制約を回避できる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
Azure Artifact SigningはGitHub Actionsに対する本記事の推奨です。Azure Artifact Signing(旧Trusted Signing)はGitHub Actions等との連携を前提に設計されたクラウド署名サービスだが、利用可能な地域が法人は米国・カナダ・EU・英国、個人は米国・カナダに限られ、日本の開発者は対象外である。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
GitHub Actions Environment(承認者付き環境)は署名鍵の窃取リスクを軽減します。署名用シークレットを承認者付きのGitHub Actions Environmentに置き、リリースワークフローだけが参照できるようにすることで、ワークフローを書き換えるだけで鍵を取り出されるリスクを軽減する。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
GitHub Actionsのシークレットは署名鍵の窃取リスクの原因になることがあります。署名鍵をリポジトリシークレットとして直接参照する構成のままだと、書き込み権限を持つ人がワークフローを書き換えてタグを1本pushするだけで鍵を取り出せてしまう。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
コード署名証明書はGitHub Actionsのシークレットで構成できます。GitHub ActionsでCI/CDパイプラインを組む場合、PFX形式の秘密鍵はBase64化してGitHub Actionsのシークレットに格納し、ジョブ内でファイルとして復元して使う。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
SignToolはコード署名証明書を利用します。signtoolはPFXファイルなどの秘密鍵と証明書を使って、実行ファイルやDLLにコード署名を行う。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
SignToolはコード署名のタイムスタンプを利用します。signtoolでの署名で/trオプションによりタイムスタンプサーバーを明示的に指定した場合、証明書の期限が切れた後も署名時点で有効だったことを検証できる状態を保てる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
MSIXはコード署名証明書を前提とします。Windowsは署名されていないMSIXパッケージのインストールを許可しないため、MSIX配布ではパッケージ署名が必須になる。 / 確度: 確立した関係 / 確認日: 2026-08-01 出典
xcopy配布(zip)はGitHub Actionsに対する本記事の推奨です。xcopy配布(zip)はdotnet publishの出力を圧縮するだけで完成するため、4つの配布形式のうちCI/CDへの組み込みが最も簡単である。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
タグ駆動リリース(バージョン採番)はClickOnceに対する本記事の推奨です。ClickOnceの更新判定はデプロイ側のApplicationVersion/ApplicationRevisionで行われ、コマンドラインでの発行(msbuild /target:publish)ではリビジョンが自動加算されないため、タグ駆動のバージョン注入で値を明示的に渡す設計が本記事の推奨である。IDEからの発行ではリビジョンが自動加算されるため不要で、他の採番方式でも代替できる。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
デスクトップアプリのCI/CDパイプラインはMSI(Windows Installer)を利用します。MSIはWiX等のツールをCIからコマンドラインで呼び出すことで自動化できる配布形式である。 / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

デスクトップアプリのCI/CDパイプライン: デプロイ先が客先・現場のPCであるWinForms/WPFデスクトップアプリを対象に、ビルド・テスト・バージョン採番・署名・配布物作成を自動化する仕組み。出口は本番反映ではなく署名済み配布物の完成である。
GitHub Actions: GitHubが提供する、リポジトリのイベントをトリガーにワークフローを実行するCI/CDサービス。
Windows Forms: デスクトップGUIアプリケーションを構築するための.NET/.NET FrameworkのUIフレームワーク。
WPF: XAMLでUIを宣言的に記述する、Windows専用のデスクトップUIフレームワーク。ベクターベースの描画とデータバインディングを特徴とする。
ビルド+テストの自動化: windows-latestランナーでのdotnet build/testの実行と、actions/upload-artifactによる成果物の保存だけを行う、CI/CD導入の最小構成。
タグ駆動リリース(バージョン採番): v1.2.3のようなタグのpushをトリガーにリリースビルドを起動し、MSBuildのVersionプロパティにタグから取った値を注入するバージョン採番の方式。
コード署名証明書: ソフトウェアの発行元を証明し、改ざんを検出するための証明書。
HSM/トークンでの秘密鍵保管: 2023年6月1日以降のCA/Browser Forum基準により、コード署名証明書の秘密鍵をFIPS 140-2レベル2相当以上のハードウェア(HSMやUSBトークン)で生成・保管することを義務付けたもの。
Azure Artifact Signing: Microsoftが提供するクラウド型のコード署名サービス(旧Trusted Signing)。物理USBトークンを使わずCI/CDに組み込め、本番配布のMSIX署名で推奨される選択肢に位置付けられるが、利用可能な地域は法人が米国・カナダ・EU・英国、個人が米国・カナダに限られ、日本の開発者は利用できない。
GitHub Actions Environment(承認者付き環境): 承認者やシークレットを紐づけられるGitHub Actionsのデプロイ環境の仕組み。署名鍵などの機微なシークレットを、特定のワークフロー・ジョブだけがアクセスできるように制限するために使う。
GitHub Actionsのシークレット: PFXファイルのBase64文字列やパスワードなど、機微な値をワークフローへ安全に渡すためのGitHub Actionsの仕組み。ログでは自動的にマスクされ、フォークからのプルリクエストには渡らない。
SignTool: コード署名とRFC 3161タイムスタンプの付与、および署名の検証を行うWindows SDK付属のコマンドラインツール。
MSIX: package identityを持つ、Windowsのモダンなアプリパッケージング形式。
xcopy配布(zip): dotnet publishの出力を圧縮するだけで完成する、最もCIへの組み込みが簡単な配布方式。自動更新は持たず手動展開が前提。

機械可読データ

JSON-LD / Turtle ── この記事の知識グラフ全体
概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。