2026年5月19日にマージされた公式PRの要点は、Dynamics 365 Business Centralの展開・セキュリティ関連ドキュメントに残っていた古い「C/AL」表記を、現在の開発言語である「AL」に直すことです。これは脆弱性修正や製品仕様変更ではなく、ドキュメントの用語更新です。ただし、管理者や開発者が「C/AL向けの古い注意書き」と誤解して読み飛ばすと、マルチテナント環境のURL生成やサーバーファイルアクセス設定の確認漏れにつながります。(GitHub)
今回のDynamics 365ドキュメント更新で変わったこと
今回のDynamics 365 documentation updateでは、MicrosoftDocsのBusiness Central開発・IT Pro向けドキュメントにある2つの非移行系ドキュメントで、古いC/AL表記がALへ修正されました。PRは「Replace stale C/AL references with AL in deployment and security docs」として、2026年5月19日にマージされています。(GitHub)
| 対象ドキュメント | 修正内容 | 実務上の意味 |
|---|---|---|
Multitenant-Deployment-Architecture.md | 「C/AL code that constructs URLs」を「AL code that constructs URLs」へ変更 | マルチテナント構成でURLを組み立てるALコードは、テナント指定を含めて見直す対象であることが明確になった |
security-lock-down-server-communication.md | EnableALServerFileAccessの説明内に残っていた「C/AL file data type functions」を「AL file data type functions」へ変更 | サーバーファイルアクセスの制御対象が、現在のALファイル操作にも関係することが分かりやすくなった |
重要なのは、今回の更新が「C/ALからALへの移行手順」そのものではない点です。対象は現在のアーキテクチャガイダンスとセキュリティ設定の説明であり、現行のAL開発者・Business Central管理者が読む前提のドキュメントです。(GitHub)
これはセキュリティパッチではなく、セキュリティ文書の用語修正
今回の更新を「Dynamics 365の緊急セキュリティ更新」と捉えるのは正確ではありません。確認できる変更はMarkdownドキュメント内の表記修正であり、サーバー設定値、既定値、ALランタイム、認証方式が変更されたわけではありません。(GitHub)
一方で、セキュリティ運用上は軽視しない方がよい更新です。理由は、古い「C/AL」という語が残っていると、レビュー担当者が「これは旧Dynamics NAVや古い移行作業の話だ」と判断し、現行のAL拡張機能に関係する注意点を見落としやすいからです。
特に次の環境では、単なる表記修正で終わらせず、設定やコードの棚卸しまで行う価値があります。
| 環境・担当 | 確認すべきポイント | 優先度 |
|---|---|---|
| Business Centralのオンプレミス、またはパートナー管理環境 | EnableALServerFileAccessの現在値と、ALからサーバーファイルへアクセスする必要性 | 高 |
| マルチテナント構成 | ALコード、レポート内リンク、OData URLにテナント指定が含まれているか | 高 |
| AL拡張機能を開発しているチーム | 古いC/AL表記を理由に現行コードレビュー対象から外していないか | 中 |
| 社内手順書・設計書を管理するチーム | 非移行ドキュメントに残るC/AL表記をALへ更新するか | 中 |
| C/ALからALへの移行資料を保守しているチーム | 移行文脈のC/AL表記を誤って一括置換しないか | 中 |
なぜC/ALからALへの表記変更が重要なのか
Business Centralの拡張機能開発では、オブジェクトはALコードとして.alファイルに保存され、Visual Studio CodeとAL Language拡張機能を使って開発するのが現在の前提です。Microsoft Learnでも、Business Centralの拡張機能はAL開発環境で作成するものとして説明されています。(Microsoft Learn)
一方、C/ALは主に旧Dynamics NAVやBusiness Central 2019 Spring、つまりバージョン14以前の文脈で登場します。MicrosoftのTxt2Al変換ツールの説明でも、C/ALオブジェクトを.al形式へ変換する対象はDynamics NAVまたはBusiness Central Spring 2019、バージョン14のオブジェクトとして扱われています。さらに同ツールはBusiness Central 2022 release wave 2、バージョン21以降では利用できないとされています。(Microsoft Learn)
つまり、現在の展開・セキュリティドキュメントにC/ALと書かれていると、読者に誤ったシグナルを送ります。今回の修正は、その誤解を避けるための整合性改善です。
管理者が確認すべき設定：EnableALServerFileAccess
管理者が最も確認すべきなのは、EnableALServerFileAccessです。この設定は、ALのファイルデータ型関数がBusiness Central Serverコンピューター上のファイルへアクセスできるかを指定します。Microsoft Learnのサーバー設定一覧では、既定値は有効、動的更新は不可と説明されています。(Microsoft Learn)
この設定を確認する目的は、「有効だから危険」「無効にすべき」と単純に決めることではありません。AL拡張機能が帳票出力、一時ファイル、外部連携、データインポートなどでサーバー側ファイルを使っている場合、無計画に無効化すると業務処理が止まる可能性があります。
確認の進め方
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 現行値の確認 | Business Central Administration Shellで設定値を確認する | どのServer Instanceで有効かを一覧化する |
| 利用箇所の棚卸し | ALコード、外部連携、バッチ処理、帳票処理でサーバーファイルを使っているか確認する | 必要性が説明できない処理は見直し候補 |
| アクセス範囲の確認 | サービスアカウントがアクセスできるフォルダーを確認する | 不要な共有フォルダーや広すぎる権限を避ける |
| 検証環境でテスト | 設定変更時の影響を検証する | 本番でいきなり無効化しない |
| 変更手順の整備 | 変更、再起動、切り戻し、業務確認の手順を用意する | 障害時に元へ戻せる状態にする |
設定確認にはGet-NAVServerConfiguration、設定変更にはSet-NAVServerConfigurationを使えます。Set-NAVServerConfigurationはBusiness Central Serverインスタンスの設定を構成するcmdletで、値はインスタンスのCustomSettings.configに書き込まれます。(Microsoft Learn)
Get-NAVServerConfiguration -ServerInstance BC -KeyName EnableALServerFileAccess
Set-NAVServerConfiguration -ServerInstance BC -KeyName EnableALServerFileAccess -KeyValue false
Restart-NAVServerInstance -ServerInstance BC多くの構成変更はサーバーインスタンスの再起動後に反映されます。Restart-NAVServerInstanceはBusiness Central Serverインスタンスを停止して再起動するcmdletで、再起動時にはクライアント接続が切断されるため、業務時間外やメンテナンス枠で実施するのが安全です。(Microsoft Learn)
直接編集は避け、変更履歴を残す
Business Central Serverの設定はCustomSettings.configを直接編集することもできますが、Microsoft Learnでは、入力ミスがあるとサーバーインスタンスが起動しない可能性があるため、直接編集には注意が必要だと説明されています。各Server Instanceは独自のCustomSettings.configを持つため、複数インスタンス構成では「一部の環境だけ設定が違う」状態にも注意が必要です。(Microsoft Learn)
実務では、PowerShellで変更し、変更前後の値、実施者、日時、対象インスタンス、再起動結果を記録する方が監査しやすくなります。
バージョン27以降ではファイル操作の制限設定も合わせて確認する
サーバーファイルアクセスを見直す場合、EnableALServerFileAccessだけでなく、EnforceUserPathForAlFileOperationsも確認対象になります。Microsoft Learnでは、この設定はALファイル操作をサーバーのサービスアカウントのユーザーフォルダーに制限するセキュリティ機能として説明されており、バージョン27以降に適用される設定です。(Microsoft Learn)
実務上の判断は次のように考えると整理しやすくなります。
| 状況 | 推奨される見方 |
|---|---|
| ALがサーバーファイルを使っていない | EnableALServerFileAccessを有効にしておく必要があるか再検討する |
| ALが一時ファイルのみ使っている | アクセス先をサービスアカウントの限定されたフォルダーに寄せられるか確認する |
| 外部システム連携で共有フォルダーを使っている | 共有フォルダーのアクセス権、監査ログ、代替手段を確認する |
| 古いカスタマイズをAL化している | C/AL時代のファイル操作前提が残っていないかコードレビューする |
ここでの失敗パターンは、設定名だけを見て「AL向けだからオンにしておく」と判断することです。実際には、必要なAL処理だけにファイルアクセスを許可し、不要なアクセス経路を減らすことがセキュリティレビューの目的です。
開発者が確認すべきALコード：マルチテナントURL生成
もう一つの重要ポイントは、マルチテナント構成におけるURL生成です。Microsoft Learnのマルチテナント展開ドキュメントでは、マルチテナント環境のURLは対象テナントを指定する必要があり、URLを組み立てるALコードはテナントを含めるよう更新するか、GETURL関数を使ってURLを計算するよう説明されています。(Microsoft Learn)
見直すべき箇所は、Webサービス呼び出しだけではありません。次のような箇所も対象です。
- レポート内に埋め込んだBusiness Centralへのリンク
- 通知メールに差し込むURL
- 外部システムへ渡すOData、SOAP、APIのURL
- ALコード内で文字列連結しているURL
- テナントIDやホスト名を固定値で持っている設定ファイル
たとえば、単一テナント環境で動いていたURLをそのまま使うと、マルチテナント構成では別テナントを参照できない、認証後に意図しない画面へ遷移する、外部連携が失敗するといった問題が起きます。
URL生成コードのレビュー観点
| レビュー項目 | 確認内容 |
|---|---|
| テナント指定 | Tenantパラメーター、またはテナントごとのホスト名を使っているか |
| 固定URL | localhost、古いサーバー名、特定会社名をハードコードしていないか |
| レポート内リンク | レポート出力後に別テナントでも正しく開くか |
| 外部連携 | ODataやAPI URLにテナント条件が欠けていないか |
| テスト | 複数テナントで同じAL拡張機能を実行し、URLが正しく分岐するか |
マルチテナントでは、テナントIDをURLに含める方法と、テナントごとのホスト名を代替IDとして使う方法があります。Microsoft Learnでは、テナントホスト名を代替IDとして指定した場合、そのホスト名を使って同じWebサービスへアクセスできる例が示されています。(Microsoft Learn)
移行プロジェクトでは「C/AL」の一括置換に注意
今回の更新を受けて、社内ドキュメントやコードコメントのC/AL表記を見直すのは有効です。ただし、すべてのC/ALをALへ一括置換するのは危険です。
C/ALからALへの移行手順、Txt2Al、Dynamics NAV由来のオブジェクト、Business Central v14以前の説明では、C/ALという語が正しく使われている場合があります。MicrosoftのTxt2Al変換ツールの説明でも、C/ALオブジェクトを.al形式へ変換するという移行文脈でC/ALが使われています。(Microsoft Learn)
見直し時は、次のように分類すると誤置換を防げます。
| 表記がある場所 | 対応方針 |
|---|---|
| 現行の展開手順、運用手順、セキュリティ手順 | C/ALではなくALが適切か確認する |
| AL拡張機能の設計書・レビュー観点 | 原則としてALに統一する |
| C/ALからALへの移行手順 | C/AL表記を残すべき箇所が多い |
| 古いNAV資産の説明 | 対象バージョンを明記してC/ALを残す |
| 社内FAQ | 「旧C/AL」「現行AL」の違いを補足する |
管理者・開発者が今すぐ行うべきチェックリスト
今回のDynamics 365ドキュメント更新を受けて、まずは次の順番で確認すると無駄がありません。
| チェック項目 | 対象者 | 完了条件 |
|---|---|---|
| 公式PRの対象がドキュメント修正であることを共有する | 管理者、開発者、セキュリティ担当 | 緊急パッチと誤解されていない |
| マルチテナント構成の有無を確認する | 管理者 | 対象Server Instanceとテナント構成が分かる |
| ALコードでURLを組み立てている箇所を検索する | 開発者 | テナント指定の有無をレビューできる |
EnableALServerFileAccessの値を確認する | 管理者 | 必要性とリスクを説明できる |
| サーバーファイルアクセスを使うAL処理を棚卸しする | 開発者、運用担当 | 無効化時の影響を把握できる |
| 社内ドキュメントのC/AL表記を分類する | ドキュメント管理者 | 非移行文脈の古い表記を修正できる |
| 変更する場合は検証環境で試す | 管理者、開発者 | 本番変更前に影響を確認できる |
よくある誤解と失敗しやすいポイント
| 誤解・失敗 | 何が問題か | 正しい対応 |
|---|---|---|
| 「セキュリティ更新」と聞いてすぐ本番設定を変える | 今回は製品パッチではなくドキュメント修正 | まず影響範囲を確認する |
| C/ALと書かれているから現行環境には関係ないと判断する | 今回の修正対象は現行AL開発者向けの文書 | ALコードと設定を確認する |
EnableALServerFileAccessを無計画に無効化する | 既存のAL処理が停止する可能性がある | 利用箇所を棚卸しし、検証環境で確認する |
| マルチテナントURLを文字列連結で作り続ける | テナント指定漏れやホスト名変更に弱い | GETURL関数やテナントホスト名の利用を検討する |
| 社内資料のC/ALをすべてALに一括置換する | 移行資料ではC/AL表記が正しい場合がある | 移行文脈と現行運用文脈を分けて修正する |
次に取るべき行動
今回のDynamics 365 documentation updateは小さな表記修正ですが、現行のBusiness Central運用では見逃せないシグナルです。対応の優先順位は明確です。
まず、マルチテナント環境を運用している場合は、ALコードやレポート内リンクがテナントを正しく指定しているか確認します。次に、オンプレミスやパートナー管理環境でBusiness Central Serverを管理している場合は、EnableALServerFileAccessの値とALファイル操作の利用実態を棚卸しします。最後に、社内の運用手順書・設計書・レビュー観点に残っているC/AL表記を見直し、移行文脈と現行AL文脈を分けて整理します。
今回の更新で重要なのは、「C/ALという古い言葉をALへ置き換えた」こと自体ではありません。現行のAL開発とBusiness Central運用に関わる注意点を、古い用語のせいで見落とさないようにすることです。
コメント