Visual Studio 拡張機能を作っている開発者にとって、2026年6月29日に公開された「Automating your Visual Studio extension builds with GitHub Actions」の要点は、VSIX のビルド、バージョン更新、テスト配布、Marketplace 公開を GitHub Actions で標準化しやすくなったことです。Visual Studio 本体の破壊的変更というより、拡張機能のリリース作業を自動化するための実践的なワークフロー紹介と捉えるのが正確です。公式ブログでは、vsix-version-stamp、publish-vsixgallery、publish-marketplace の3つの再利用可能な GitHub Actions を組み合わせ、VSIX の作成から公開までを自動化する構成が示されています。(Microsoft for Developers)
特に確認すべきなのは、Visual Studio Marketplace へ公開するための PAT、GitHub Secrets、vs-publish.json、VSIX マニフェストのバージョン管理です。すでに Azure DevOps や手作業で公開しているチームは、すぐに移行が必須というわけではありません。ただし、Azure DevOps のグローバル PAT は 2026年12月1日に廃止予定とされているため、Marketplace 公開に広範な PAT を使っている場合は、認証方式と権限設計を早めに棚卸しする必要があります。(Microsoft for Developers)
Visual Studio の「Automating your Visual Studio extension builds with GitHub Actions」とは
今回の公式情報は、Visual Studio 拡張機能の開発者向けに、GitHub Actions を使った VSIX ビルドと公開の自動化パターンを紹介するものです。
対象になるのは、主に次のようなチームです。
- Visual Studio 拡張機能を VSIX 形式で配布している開発者
- Visual Studio Marketplace に拡張機能を公開しているチーム
- CI ビルドをテスターや社内ユーザーへ素早く配布したいチーム
- 手作業でバージョン更新、ビルド、アップロードを行っている保守担当者
- Azure DevOps から GitHub Actions への移行を検討している管理者
ポイントは、Visual Studio IDE の使い方が変わるというより、拡張機能のリリース工程を GitHub Actions 側で再現性高く管理できるようにすることです。
公式ブログで紹介されている基本的な流れは、次の4段階です。
| 工程 | 目的 | 主な確認ポイント |
|---|---|---|
| バージョン更新 | VSIX のバージョンをビルド時に更新する | .vsixmanifest とコード側のバージョン不一致を防ぐ |
| ビルド | MSBuild で VSIX を生成する | windows-latest、Release 構成、対象ソリューションを確認 |
| VSIX Gallery へ公開 | CI ビルドや検証版を共有する | テスター向け配布か、社内ギャラリーかを決める |
| Visual Studio Marketplace へ公開 | 安定版を公式公開する | PAT、GitHub Secrets、vs-publish.json を管理する |
更新ポイントは3つの GitHub Actions にある
公式ブログで中心に置かれているのは、次の3つのアクションです。いずれも単独で使うことも、組み合わせて使うこともできます。(Microsoft for Developers)
| アクション | 役割 | 向いている用途 |
|---|---|---|
madskristensen/vsix-version-stamp@v2 | VSIX のバージョン番号をビルド時に更新 | 手動でマニフェストを書き換えているリポジトリ |
madskristensen/publish-vsixgallery@v1 | VSIX Gallery へ公開 | CI ビルド、検証版、社内テスト配布 |
madskristensen/publish-marketplace@v2 | Visual Studio Marketplace へ公開 | 安定版、正式リリース、自動公開 |
vsix-version-stamp はバージョンずれを防ぐ
Visual Studio 拡張機能では、.vsixmanifest のバージョンと、コード内で参照するバージョン情報がずれることがあります。小さな拡張機能なら手作業でも対応できますが、リリース回数が増えると、同じバージョン番号で上書きしようとして失敗したり、テスターに配った VSIX がどのビルドか分からなくなったりします。
vsix-version-stamp は、source.extension.vsixmanifest と source.extension.cs などのファイルに対して、ビルド時にバージョンを反映するためのアクションです。GitHub の実行番号を使ってバージョンの一部を更新できるため、CI ごとに識別しやすい VSIX を作れます。リポジトリの README でも、manifest-file と vsix-token-source-file を指定して使う例が示されています。(GitHub)
実務では、次のようなチームに向いています。
| 状況 | 導入メリット |
|---|---|
リリース前に毎回 .vsixmanifest を手で変更している | 更新漏れを防げる |
| CI ビルドをテスターに配っている | どのビルドか追跡しやすい |
| Marketplace 公開時にバージョン重複エラーが起きる | ビルド番号を使った運用に整理できる |
| 複数の拡張機能を保守している | リポジトリごとの手順差を減らせる |
publish-vsixgallery は検証版の配布に向いている
publish-vsixgallery は、Visual Studio 向け VSIX を Open VSIX Gallery に公開するためのアクションです。これは VS Code 拡張機能向けではなく、Visual Studio IDE の拡張機能向けである点に注意が必要です。リポジトリの説明では、Linux と Windows の両方のランナーで動作し、curl と bash を使うとされています。(GitHub)
このアクションの使いどころは、正式リリース前の検証版配布です。
たとえば、次のような場面で役立ちます。
| 活用シーン | 具体例 |
|---|---|
| バグ修正版を先に確認してもらう | Marketplace へ出す前に、報告者へ VSIX を渡して動作確認する |
| 社内ユーザーに先行配布する | 業務用 Visual Studio 拡張機能を限定ユーザーに試してもらう |
| Pull Request の変更を試す | main にマージする前に、CI ビルドをギャラリー経由で共有する |
| 自前ギャラリーを使う | gallery-url を指定して社内ホストの VSIX Gallery に公開する |
注意したいのは、VSIX Gallery は正式な Marketplace 公開の代替というより、軽量な検証用チャネルとして使うのが自然だという点です。安定版は Visual Studio Marketplace、検証版は VSIX Gallery という切り分けにすると、利用者にも説明しやすくなります。
publish-marketplace は正式リリースの自動化に使う
publish-marketplace は、Visual Studio Marketplace へ VSIX を公開するためのアクションです。リポジトリの説明では、Windows ランナーが必要で、毎回 NuGet から最新の Microsoft.VSSDK.BuildTools を取得して VsixPublisher.exe を使う構成とされています。(GitHub)
Marketplace 公開では、次の3点が重要です。
| 項目 | 内容 |
|---|---|
extension-file | 公開する .vsix ファイル |
publish-manifest-file | Marketplace 用メタデータを持つ vs-publish.json |
personal-access-code | Marketplace 公開権限を持つ PAT。GitHub Secrets に保存する |
Microsoft Learn でも、Visual Studio 拡張機能を Marketplace に公開するコマンドラインツールとして VsixPublisher.exe が説明されており、公開時には VSIX、publish manifest、PAT が関係します。(Microsoft Learn)
基本ワークフローの考え方
公式ブログでは、main ブランチへの push と pull request を契機に、Restore、バージョン更新、Build、VSIX Gallery 公開、Marketplace 公開を行う例が示されています。(Microsoft for Developers)
実務でそのまま使う場合は、Marketplace 公開まで毎回走らせるのではなく、次のように段階を分けるのが安全です。
| タイミング | 実行する処理 | 理由 |
|---|---|---|
| Pull Request | Restore、Build、必要ならテスト | 破壊的変更を早く検知する |
| main への push | Build、VSIX Gallery 公開 | 検証版を共有しやすくする |
| タグ作成または GitHub Release | Marketplace 公開 | 意図しない正式公開を防ぐ |
手動実行 workflow_dispatch | 緊急修正版の公開 | 管理者が明示的に公開できる |
最低限の構成例は、次のような形です。
name: Build
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: windows-latest
env:
Configuration: Release
VsixManifestPath: src\source.extension.vsixmanifest
VsixSourcePath: src\source.extension.cs
steps:
- uses: actions/checkout@v6
- name: Setup MSBuild
uses: microsoft/setup-msbuild@v3
- name: Restore
run: msbuild /t:Restore
- name: Version stamp
uses: madskristensen/vsix-version-stamp@v2
with:
manifest-file: ${{ env.VsixManifestPath }}
vsix-token-source-file: ${{ env.VsixSourcePath }}
- name: Build
run: msbuild /p:Configuration=${{ env.Configuration }}ここまでで、バージョン更新とビルドの自動化ができます。検証版の配布や Marketplace 公開は、チームの運用に合わせて追加します。
影響範囲：誰が対応すべきか
今回の内容は、Visual Studio を利用する一般ユーザー全員に影響するものではありません。主な対象は、Visual Studio 拡張機能を開発・配布しているチームです。
| 立場 | 影響 | 対応の優先度 |
|---|---|---|
| Visual Studio 拡張機能の開発者 | VSIX のビルドと公開を自動化できる | 高 |
| OSS メンテナー | リリース手順を GitHub Actions に集約しやすい | 高 |
| 企業内ツール開発者 | 社内検証版と正式版の配布経路を分けやすい | 中〜高 |
| Visual Studio 利用者 | 拡張機能の更新が安定しやすくなる | 低 |
| IT 管理者・セキュリティ担当 | PAT、Secrets、Marketplace 公開権限の管理が必要 | 高 |
| Azure DevOps パイプライン利用者 | GitHub Actions へ移すかどうかの判断材料になる | 中 |
特に管理者は、「自動化できるか」だけでなく、「誰が Marketplace に公開できるのか」「PAT がどこに保存されているのか」「退職者や異動者のトークンに依存していないか」を確認する必要があります。
設定変更で確認すべきファイルとシークレット
GitHub Actions で Visual Studio 拡張機能のビルドと公開を行う場合、最低限確認するファイルは次の通りです。
| 種類 | 例 | 確認内容 |
|---|---|---|
| GitHub Actions ワークフロー | .github/workflows/build.yml | トリガー、ランナー、公開条件 |
| VSIX マニフェスト | source.extension.vsixmanifest | ID、バージョン、対象 Visual Studio |
| バージョン同期用ファイル | source.extension.cs | バージョンの参照先 |
| Marketplace 公開マニフェスト | vs-publish.json | publisher、categories、overview、private 設定 |
| README / overview | overview.md | Marketplace に表示する説明文 |
| GitHub Secrets | VS_MARKETPLACE_TOKEN など | PAT の保存先と権限 |
vs-publish.json は、Marketplace 側に必要なメタデータを持つ重要なファイルです。Microsoft Learn の例でも、カテゴリ、publisher、overview、private、Q&A、リポジトリ情報などが publish manifest に含まれます。(Microsoft Learn)
Marketplace 公開用 PAT の扱いに注意する
Marketplace 公開を自動化する場合、PAT を YAML に直接書いてはいけません。必ず GitHub Secrets に保存し、ワークフローから参照します。
例として、公式ブログでは次のような参照が示されています。(Microsoft for Developers)
personal-access-code: ${{ secrets.VS_MARKETPLACE_TOKEN }}一方で、publish-marketplace のリポジトリでは、PAT を VS_PUBLISHER_ACCESS_TOKEN という名前の Secret として保存する例も示されています。実務では、名前そのものよりも、リポジトリ内で一貫していること、権限が過剰でないこと、棚卸しできることが重要です。(GitHub)
移行期限はあるのか
今回の Visual Studio Blog の記事自体は、GitHub Actions への移行を強制する告知ではありません。そのため、「この日までに GitHub Actions 化しないと Visual Studio 拡張機能が使えなくなる」という種類の期限は示されていません。
ただし、関連して確認すべき期限があります。Azure DevOps Services のグローバル PAT は、2026年12月1日に既存トークンも含めて廃止され、以後は動作しない予定とされています。対象は Azure DevOps Services であり、Azure DevOps Server のグローバル PAT には変更がないと説明されています。(Microsoft for Developers)
このため、次のようなチームは注意が必要です。
| 現在の運用 | 確認すべきこと |
|---|---|
| Azure DevOps のグローバル PAT で Marketplace 公開している | 2026年12月1日以降も公開処理が動くか確認する |
| GitHub Actions から Azure DevOps 由来の PAT を使っている | Secret の発行元、スコープ、有効期限を確認する |
| 個人アカウントの PAT に依存している | 組織管理の発行・更新ルールへ移す |
| 複数 Marketplace publisher を1つの PAT で扱っている | publisher ごとの権限分離を検討する |
| 手動公開だけで棚卸ししていない | 使われている PAT と所有者を一覧化する |
重要なのは、GitHub Actions 化そのものに期限があるわけではない一方で、公開認証に使うトークンの寿命や仕様変更はリリース業務に直結するという点です。
管理者が確認すべきチェックリスト
Visual Studio 拡張機能の公開を GitHub Actions へ寄せる場合、管理者は次の観点で確認すると抜け漏れを減らせます。
| 確認項目 | 見るべきポイント | 失敗しやすい例 |
|---|---|---|
| 公開権限 | Marketplace publisher に誰がアクセスできるか | 退職者の PAT で公開している |
| Secret 管理 | GitHub Secrets に保存されているか | YAML に PAT を直書きしている |
| トリガー | いつ Marketplace 公開されるか | main への push だけで正式公開される |
| バージョン管理 | ビルドごとに一意なバージョンになるか | 同じ VSIX バージョンを再公開して失敗する |
| 配布経路 | 検証版と正式版を分けているか | テスト版を Marketplace に出してしまう |
| 監査 | 誰がワークフローを変更できるか | ブランチ保護なしで公開処理を変更できる |
| ロールバック | 問題時に前バージョンへ戻せるか | VSIX アーティファクトを保存していない |
| 多国籍対応 | Marketplace 説明文やサポート導線が適切か | 英語圏ユーザー向けの案内が不足する |
グローバル向けに公開している拡張機能では、特に説明文、サポート先、既知の制限、対象 Visual Studio バージョンを明確にしておくことが大切です。CI/CD だけを整えても、Marketplace 上の情報が古いと、ユーザーの問い合わせや低評価につながります。
おすすめの移行パターン
既存の運用をいきなり全自動化するより、段階的に進める方が安全です。
| 段階 | 実施内容 | 判断基準 |
|---|---|---|
| 第1段階 | GitHub Actions で Restore と Build だけ実行 | PR ごとに VSIX がビルドできることを確認 |
| 第2段階 | vsix-version-stamp を追加 | バージョン重複や手動更新漏れをなくす |
| 第3段階 | VSIX を artifact として保存 | 問題発生時にビルド成果物を追跡できる |
| 第4段階 | VSIX Gallery へ検証版を公開 | テスターに配布する運用がある場合に導入 |
| 第5段階 | Marketplace 公開を手動トリガーで追加 | 管理者が明示的にリリースできる状態にする |
| 第6段階 | タグや GitHub Release と連動 | リリースルールが固まってから自動化する |
最初から Marketplace 公開まで自動化すると、誤公開のリスクが高くなります。特に企業内で使う拡張機能や、顧客向けの拡張機能では、Build と Gallery 配布で十分に検証してから Marketplace 公開を有効化するのが現実的です。
実務で使いやすい公開条件の例
Marketplace 公開は、次のいずれかの条件に絞ると運用しやすくなります。
| 公開条件 | 向いているチーム |
|---|---|
workflow_dispatch の手動実行 | 少人数チーム、公開頻度が低い拡張機能 |
v* タグ作成時のみ公開 | セマンティックバージョニングで運用しているチーム |
| GitHub Release 作成時に公開 | リリースノートと Marketplace 公開をそろえたいチーム |
commit message に [release] が含まれる場合 | 簡易的に公開制御したい OSS プロジェクト |
| protected branch のみ公開 | 承認フローを重視する企業開発 |
公開事故を防ぐなら、main への push だけで Marketplace 公開しない構成がおすすめです。たとえば、Build は常時実行、VSIX Gallery は main で公開、Marketplace は手動またはタグで公開、という分離が扱いやすいです。
よくある失敗と対策
VSIX Gallery と Marketplace の役割を混同する
VSIX Gallery は、検証版や一時配布に向いています。Marketplace は、正式リリースの配布先です。
両方に同じタイミングで同じ説明のまま公開すると、利用者がどちらを使えばよいか迷います。Gallery 側は「preview」「CI build」「test build」など、安定版ではないことが分かる表現にしておくと安全です。
PAT の権限を広く取りすぎる
公開用 PAT は、強い権限を持つ認証情報です。GitHub Secrets に保存していても、ワークフローを編集できるユーザーが多すぎるとリスクが残ります。
対策として、次の運用を検討します。
- 公開用ワークフローを protected branch で管理する
- Marketplace 公開は手動承認付きにする
- PAT の有効期限と所有者を台帳化する
- 個人ではなく組織として管理できる発行ルールを決める
- 使っていない PAT を定期的に無効化する
vs-publish.json の情報が古い
Marketplace の説明、カテゴリ、リポジトリ URL、overview ファイルが古いままだと、公開は成功してもユーザー体験が悪くなります。
特にグローバル向けに公開する場合は、英語の README、サポート窓口、ライセンス、対応 Visual Studio バージョンを見直してください。日本語圏向けの拡張機能でも、Marketplace では英語ユーザーが目にする可能性があります。
バージョン番号の設計が曖昧
CI ビルド、検証版、正式版のバージョンルールが曖昧だと、問い合わせ対応や不具合調査が難しくなります。
おすすめは、正式版は 1.4.0 のように人が管理し、CI ビルドではビルド番号を含める運用です。たとえば、1.4.123 のように GitHub Actions の run number を使うと、どのワークフロー実行から生成された VSIX か追跡しやすくなります。
導入前に決めておきたい運用ルール
GitHub Actions の YAML を追加する前に、次のルールを決めておくと後戻りが少なくなります。
| 決めること | 推奨される考え方 |
|---|---|
| Marketplace 公開者 | 個人任せにせず、組織で管理する |
| 公開タイミング | 手動、タグ、Release のいずれかに限定する |
| 検証版の配布先 | VSIX Gallery、社内ギャラリー、artifact のどれを使うか決める |
| バージョン規則 | 正式版と CI ビルドの採番ルールを分ける |
| Secret の更新頻度 | 有効期限と更新担当者を明確にする |
| 失敗時の対応 | 再実行、公開停止、前バージョン配布の手順を用意する |
自動化は、作業を減らすだけでなく、属人化を減らすための仕組みです。ビルド担当者だけが知っている手順を GitHub Actions に移し、レビュー可能な形にすることが最大の価値です。
まず取るべき次のアクション
Visual Studio 拡張機能を保守しているなら、最初にやるべきことは「現在の公開手順の棚卸し」です。
次の順番で確認すると、実務に落とし込みやすくなります。
| 順番 | アクション |
|---|---|
| 1 | VSIX のビルドがローカルだけに依存していないか確認する |
| 2 | .vsixmanifest とコード側のバージョン管理方法を確認する |
| 3 | Marketplace 公開に使っている PAT の所有者、権限、有効期限を確認する |
| 4 | GitHub Actions で Build のみを追加する |
| 5 | 必要に応じて vsix-version-stamp を追加する |
| 6 | テスト配布が必要なら publish-vsixgallery を追加する |
| 7 | Marketplace 公開は手動トリガーまたはタグ連動で追加する |
| 8 | 2026年12月1日のグローバル PAT 廃止予定に備え、依存しているトークンを確認する |
今回の更新は、Visual Studio 拡張機能の公開プロセスを見直す良いタイミングです。すぐに全自動化する必要はありません。まずは Build とバージョン更新を CI に移し、次に検証版配布、最後に Marketplace 公開を自動化する流れが現実的です。特に管理者は、PAT と GitHub Secrets の管理、公開条件、監査ログ、退職者アカウントへの依存を重点的に確認してください。
コメント