Visual Studio Code documentation update:Codeful Public Previewの依存関係更新と確認ポイント

2026年5月21日に公式リポジトリのDaily Repo Statusで言及された「Visual Studio Code documentation update: fix(vscode): Update dependencies to latest for codeful public preview」は、Visual Studio Code本体の一般ユーザー向けアップデートというより、Azure Logic Apps (Standard) のVS Code拡張機能/VS Code DesignerでCodeful Workflowsのパブリックプレビューを使う人向けの依存関係更新です。PR #9193は2026年5月20日にmainへマージされ、翌日のリポジトリ状況レポートでも「VS Code deps update for Codeful Public Preview」として扱われています。(GitHub)

結論から言うと、確認すべきポイントは3つです。Codeful Workflowsを使っているか、既存プロジェクトのlocal.settings.jsonに古い固定バージョンやプライベートフィード指定が残っていないか、VS Code拡張機能更新後に追加アクション・LSP・ローカル実行が期待どおり動くかです。通常のVS Code編集機能だけを使っている開発者や、Azure Logic AppsのCodeful Workflowsを使っていないチームへの影響は限定的と見てよいでしょう。

目次

Visual Studio Code documentation update: fix(vscode) の概要

今回の変更は、Azure/LogicAppsUXリポジトリのPR #9193「fix(vscode): Update dependencies to latest for codeful public preview」です。公式PR本文では、Commit Typeはfix、Risk LevelはLowとされ、目的はCodeful Workflowsに必要なSDKとLSP Serverを最新化することと説明されています。ユーザー影響としては、Codeful Workflowsで追加の対応アクションが見えるようになり、すべての顧客がアクセスできるようになる、とされています。(GitHub)

観点内容実務での見方
変更種別fix(vscode)新機能追加というより、パブリックプレビュー公開に向けた依存関係・設定の修正
対象VS Code上のAzure Logic Apps (Standard)/Codeful WorkflowsVS Code本体全体の仕様変更ではない
主な変更LSP ServerとWorkflows SDKの更新、Codefulプロジェクト設定の見直し補完、診断、対応アクション、ローカル実行の確認が重要
リスクPR上はLow依存関係更新なので、本番・標準テンプレートへ反映する前に検証環境で確認する

ここでいうLSP Serverは、VS Code上で補完、診断、定義ジャンプなどの言語機能を提供する仕組みに関係します。VS Code公式ドキュメントでも、Language Serverは補完やエラーチェック、定義ジャンプなどを支える拡張の一種として説明されています。([Visual Studio Code][2])

何が変わったのか

LSP ServerとWorkflows SDKが更新された

PR内のコミットでは、apps/vs-code-designer/src/assets/LSPServer/LSPServer.zipとMicrosoft.Azure.Workflows.Sdk.1.0.0-preview.1.nupkgが更新されています。つまり、Codeful Workflowsの開発体験を支える言語サーバーとSDKの依存関係が、パブリックプレビュー向けに新しい状態へ揃えられた変更です。(GitHub)

開発者にとっては、次のような箇所に影響が出る可能性があります。

  • Codeful Workflowの作成時に表示されるアクションや候補
  • エディター上の補完、診断、エラー表示
  • VS Code内でのワークフロー作成・編集・ローカル実行
  • 拡張機能に同梱されるSDK前提のビルド・検証フロー

ただし、PR本文では「変更はすべてパブリックプレビュー向けで、他機能への影響はない」とされています。Codeful Workflowsを使っていないチームは、緊急対応ではなく、拡張機能更新の一部として把握しておく程度で十分です。(GitHub)

Codefulプロジェクトの固定バージョン指定が外された

もう一つ重要なのが、Codefulプロジェクト作成時のlocal.settings.json関連の変更です。コミットremove pinned version from codefulでは、新規Codefulプロジェクト作成時に出力されていた次の2つの値が削除されています。(GitHub)

"AzureFunctionsJobHost__extensionBundle__version": "[1.160.24]"
"FUNCTIONS_EXTENSIONBUNDLE_SOURCE_URI": "https://cdnforlogicappsv2.blob.core.windows.net/la-sdk-private"

一方で、Codeful Workflowを有効にするための設定や、Workflows用の拡張機能バンドルIDは残っています。差分上は、Codefulの場合にWORKFLOW_CODEFUL_ENABLEDとMicrosoft.Azure.Functions.ExtensionBundle.Workflowsを使う流れ自体は維持されています。(GitHub)

実務上の意味は、新しく作成されるCodefulプロジェクトでは、特定の古いバンドルバージョンやプライベートなバンドル取得先に固定されにくくなるということです。既存プロジェクトのlocal.settings.jsonが自動で書き換わるとは読み取れないため、既にCodeful Workflowsを使っている場合は手元の設定ファイルを確認する必要があります。

追加アクションが見えるようになる可能性がある

PR本文のImpact of Changeでは、ユーザーはCodeful Workflowsで追加のサポートアクションを確認でき、すべての顧客がアクセスできるようになると説明されています。(GitHub)

このため、更新後の検証では「拡張機能が起動するか」だけでは不十分です。実際にCodeful Workflowを開き、アクション一覧、補完、作成済みワークフローの読み込み、ローカル実行まで確認しましょう。

影響を受ける人・受けにくい人

対象者影響度確認すべきこと
Codeful Workflowsを試している開発者高追加アクション、LSP補完、ローカル実行、既存設定の互換性
Azure Logic Apps (Standard) のVS Code拡張機能を管理する管理者中〜高拡張機能の更新方針、プロキシ、社内テンプレート、展開タイミング
CI/CDやDev Containerを管理する担当者中SDK・VSIX・ローカル設定ファイルの差分、再現性の確保
通常のVisual Workflowだけを使うLogic Appsユーザー低直接影響は限定的。拡張機能更新後の基本動作確認で十分
VS Codeを一般的なコードエディターとして使うだけのユーザーほぼなし今回のPR単体では対応不要

注意したいのは、PRのRisk LevelがLowでも、依存関係更新は開発体験に差分を生みやすい点です。特にプレビュー機能を評価中のチームでは、「表示されるアクションが増えた」「以前の固定バージョン前提の手順が変わった」「プロキシ環境でバンドル取得に失敗した」といった小さな差分が、検証時間を増やすことがあります。

管理者・開発者が確認すべき設定

VS Code拡張機能の自動更新とProject Runtime

Microsoft Learnでは、Azure Logic Apps (Standard) 拡張機能について、VS Codeの拡張機能自動更新を有効にして最新更新を取得できるようにすること、またAzure Logic Apps Standard: Project Runtimeがバージョン4に設定されていることを確認する手順が案内されています。(Microsoft Learn)

管理者は、次の観点で確認してください。

確認項目推奨アクション
拡張機能の更新方法個人環境は自動更新、企業管理環境は段階展開を推奨
Project RuntimeAzure Logic Apps (Standard) の設定でRuntime 4になっているか確認
依存関係Azure Functions Core Tools、.NET SDK、Node.jsが拡張機能の想定どおり導入されているか確認
ネットワーク拡張機能やバンドル取得がプロキシ、SSLインスペクション、許可リストでブロックされないか確認

Azure Logic Apps (Standard) 拡張機能は、VS Code上でロジックアプリを作成、デバッグ、管理、Azureへデプロイするための拡張機能です。Visual Studio Marketplaceでも、Visual Studio CodeからLogic Appsを作成・デバッグ・管理・デプロイできる拡張機能として説明されています。([Visual Studio Marketplace][6])

local.settings.jsonの古い固定値

既存のCodefulプロジェクトでは、次の値が残っていないか確認します。

"AzureFunctionsJobHost__extensionBundle__version": "[1.160.24]"
"FUNCTIONS_EXTENSIONBUNDLE_SOURCE_URI": "https://cdnforlogicappsv2.blob.core.windows.net/la-sdk-private"

残っている場合、すぐ削除するのではなく、まず「なぜ固定されているのか」を確認してください。過去の不具合回避、社内テンプレート、検証用の手作業、特定バージョンへの意図的な固定など、理由がある可能性があります。

判断基準は次のとおりです。

状況判断
新しいCodeful Public Previewの動作を検証したい検証ブランチで固定値を外し、最新の挙動を確認
本番相当の環境で再現性を重視しているすぐ反映せず、ステージングで比較してからテンプレートを更新
プライベートフィード前提の古い手順を使っている公開プレビュー向けの新しい取得経路で問題ないか、ネットワークと監査観点を確認
設定の由来が不明削除前にコミット履歴、社内手順書、CIテンプレートを確認

host.jsonのextensionBundle設定

Azure Functionsの拡張機能バンドルでは、host.jsonでバージョン範囲を指定すると、許容範囲内の最大バージョンが選択される仕組みが説明されています。また、可能な場合は最新のバンドルバージョンを使うこと、アップグレード後はローカルでアプリを確認することも推奨されています。(Microsoft Learn)

今回のPRはlocal.settings.json側の固定値削除が中心ですが、既存プロジェクトではhost.json側のバンドル指定も合わせて確認しておくと安全です。特に、社内テンプレートで古いバージョン範囲や固定値を使っている場合、Codeful Workflowsの追加アクションが見えない、ローカル実行時の依存関係がずれる、といった原因になります。

更新後の検証手順

まず検証環境で新規Codefulプロジェクトを作る

最初に、既存プロジェクトを触らず、検証用のワークスペースで新しいCodefulプロジェクトを作成します。目的は、更新後の拡張機能がどの設定ファイルを生成するかを確認することです。

手順確認すること
VS CodeとAzure Logic Apps (Standard) 拡張機能を更新拡張機能が正常に読み込まれるか
新規Codefulプロジェクトを作成local.settings.jsonに古い固定値が出ないか
ワークフローを作成追加アクションが表示されるか
エディターでコードを編集補完、診断、エラー表示が機能するか
ローカル実行func host startまたはF5相当で起動できるか

PRのテスト計画では、VSIXを手動ビルドしてテストし、最新SDKが反映され、アクションが利用できることを確認したとされています。(GitHub) 自社環境では、同じ観点を自分たちのプロキシ、OS、VS Code設定、拡張機能管理ポリシーの下で再確認することが重要です。

既存プロジェクトは差分を取ってから変更する

既存のCodeful Workflowプロジェクトでは、いきなり設定を削除しないでください。次の順番で進めると失敗しにくくなります。

  1. 現在のlocal.settings.json、host.json、.vscode配下、CIテンプレートをバックアップする
  2. 検証ブランチを作成する
  3. 古い固定値の有無を確認する
  4. 固定値を外した場合と残した場合で、ローカル起動・アクション表示・デプロイを比較する
  5. 差分が問題なければ、社内テンプレートや手順書を更新する

local.settings.jsonには接続文字列や開発者固有の値が含まれる場合があります。共有リポジトリにコミットしている場合は、古い固定値だけでなく、不要なシークレットが混入していないかも同時に見直してください。

追加アクションが表示されない場合はキャッシュも確認する

Microsoft Learnでは、古いバージョンのMicrosoft.Azure.Functions.ExtensionBundle.Workflowsを使っていると、以前に作成したロジックアプリで新しいトリガーやアクションがデザイナーピッカーに表示されないことがあると説明されています。その場合、古い拡張機能バンドルや関連NuGetパッケージのバージョンフォルダーを削除し、VS Codeで再度開く手順が案内されています。(Microsoft Learn)

更新後に「PRでは追加アクションが見えるはずなのに表示されない」という場合は、次を確認してください。

症状確認ポイント
アクション一覧が古い旧バンドルのキャッシュ、古いhost.json、固定されたlocal.settings.json
LSP補完が効かないVS CodeのOutputでAzure Logic Apps (Standard)ログを確認
ローカル実行が失敗するAzure Functions Core Tools、Node.js、.NET SDK、ネットワーク取得エラーを確認
一部メンバーだけ再現する個人環境の拡張機能バージョン、キャッシュ、プロキシ設定を比較
CIだけ失敗するCIイメージに同梱されたVSIX、SDK、テンプレートの古さを確認

展開時の注意点

「Low risk」をそのまま本番判断にしない

PR上はLow riskですが、依存関係更新は見た目以上に影響範囲を持つことがあります。特にLSP ServerやSDKは、ユーザーインターフェースの大きな変更がなくても、補完候補、エラー検出、対応アクション、ビルド時の挙動に影響します。

社内展開では、次のように段階を分けるのが現実的です。

フェーズ対象合格基準
事前検証管理者・代表開発者新規Codefulプロジェクト作成、追加アクション表示、ローカル実行が成功
小規模展開Codeful Workflows利用チーム既存プロジェクトで差分確認、開発フローが止まらない
標準化社内テンプレート・手順書古い固定値やプライベートフィード前提の記述を整理
全体展開関連開発者問い合わせ先、既知の回避策、戻し方を共有

パブリックプレビューであることを前提に運用する

今回の変更はCodeful Public Preview向けです。パブリックプレビューは評価・検証の価値が高い一方、正式提供済み機能と同じ安定性や変更管理を期待しすぎない方が安全です。

特に、業務ワークフローをCodeful Workflowsで本格運用する前には、次の点を確認してください。

  • 追加アクションが自社シナリオで正しく動くか
  • 既存のVisual WorkflowやJSON定義との使い分けを決めているか
  • CI/CDで再現可能なビルド手順になっているか
  • 拡張機能やSDKの更新タイミングを誰が管理するか
  • 問題発生時に旧設定へ戻す手順があるか

プレビュー機能を評価する場合は、「便利だからすぐ標準化する」よりも、「低リスクな業務シナリオで使い、得られた差分を手順書化する」進め方が向いています。

よくある疑問

Visual Studio Code本体の更新ですか?

厳密には、VS Code本体そのものの一般機能更新ではありません。対象はAzure Logic Apps (Standard) のVS Code拡張機能/VS Code Designer側で、特にCodeful Workflowsのパブリックプレビューに関係する依存関係更新です。PRもAzure/LogicAppsUXリポジトリで管理されています。(GitHub)

既存プロジェクトは自動で安全な設定になりますか?

PRの差分から読み取れるのは、新規Codefulプロジェクト作成時やローカル設定スキーマのデフォルトから固定値が外されたことです。既存のlocal.settings.jsonが自動で修正されるとは考えない方が安全です。既存プロジェクトでは手元の設定ファイルを確認してください。(GitHub)

古い固定バージョンは必ず削除すべきですか?

必ずではありません。固定している理由がある場合は、検証なしに削除すると別の問題を招く可能性があります。ただし、Codeful Public Previewの最新挙動を確認したい場合や、追加アクションが表示されない場合は、検証ブランチで固定値を外して動作比較する価値があります。

どこまでテストすれば十分ですか?

最低限、次の4つは確認してください。

テスト合格基準
新規Codefulプロジェクト作成古い固定値が生成されず、プロジェクトが作成できる
アクション表示期待するCodeful対応アクションが見える
LSP動作補完、診断、エラー表示が明らかに壊れていない
ローカル実行・デプロイ前検証func host startやF5相当の起動、ステージングでの実行が成功する

本番に近い用途で使うなら、ステージング環境へのデプロイ、実行履歴、Application Insightsやログでの確認まで行うのが望ましいです。

今すぐ取るべき行動

Codeful Workflowsを使っている、または評価予定があるチームは、まずVS Code拡張機能を検証環境で更新し、新規Codefulプロジェクトの生成結果を確認してください。そのうえで、既存プロジェクトのlocal.settings.jsonに古い固定バージョンやプライベートフィード指定が残っていないかを棚卸しします。

Codeful Workflowsを使っていないチームは、今回の変更を緊急対応として扱う必要はありません。ただし、Azure Logic Apps (Standard) 拡張機能を組織で管理している場合は、今後のプレビュー機能や依存関係更新に備えて、拡張機能の更新ポリシー、プロキシ許可、検証用ワークスペースを整えておくと安全です。

今回の「Visual Studio Code documentation update: fix(vscode): Update dependencies to latest for codeful public preview」は、派手なUI変更ではありません。しかし、Codeful Workflowsを実務で試すチームにとっては、SDK、LSP、拡張機能バンドル設定の前提が変わる重要な更新です。次にやるべきことは、自社のCodeful利用有無を確認し、使っている場合は設定差分とローカル実行を検証することです。

[2]: https://code.visualstudio.com/api/language-extensions/language-server-extension-guide “Language Server Extension Guide | Visual Studio Code Extension
API”
[6]: https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurelogicapps “
Azure Logic Apps (Standard) – Visual Studio Marketplace
“

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次