GitHubの公式ドキュメント更新「updating」を確認する際は、まず「GitHub自体の機能変更」ではなく、MicrosoftDocs/powerbi-docsリポジトリ上の公式ドキュメント更新として読むことが重要です。2026年4月30日のコミットでは、Power BIカスタムビジュアル関連ドキュメントのうち、Local Storage APIの対応環境とOn-object formatting APIのGitHubリソース案内が更新されています。開発者、クラウド管理者、ソリューションアーキテクトは、仕様確認だけでなく、既存ビジュアルの動作確認、管理ポリシー、開発時に参照するGitHubリポジトリの見直しまで行うべき更新です。(GitHub)
GitHubの公式ドキュメント更新「updating」で何が変わったか
今回の「updating」は、MicrosoftDocs/powerbi-docsに対する小規模なドキュメント更新です。コミット上では2ファイルが変更され、差分は4行追加・6行削除と大きくありません。ただし、内容はPower BIカスタムビジュアルの実装や運用判断に関わるため、単なる文言修正として見過ごさないほうがよい更新です。(GitHub)
変更対象は主に次の2つです。
| 変更対象 | 主な変更点 | 確認すべき読者 |
|---|---|---|
local-storage.md | Local Storage APIの対応環境に関する記述が更新 | Power BIカスタムビジュアル開発者、管理者 |
on-object-formatting-api.md | On-object formatting APIのGitHubリソースへのリンクが具体化 | 開発者、技術リード、アーキテクト |
特に注目すべき点は、Local Storage APIの対応環境に「Mobile」が追加され、従来の「Report ServerまたはMobileはサポートされない」という注記が削除されたことです。一方で、Report Serverが対応環境として明記されたわけではありません。したがって、「Mobile対応の可能性が公式ドキュメント上で示された」と捉えつつ、実装・展開前には自社環境で検証するのが安全です。(GitHub)
変更点の要約：影響が大きいのは2カ所
今回の更新で実務上確認すべきポイントは、次の2つに整理できます。
| 確認項目 | 更新前後の見方 | 実務での影響 |
|---|---|---|
| Local Storage APIの対応環境 | Web、Desktop、SaaS Embedに加えてMobileが記載 | モバイル利用を前提にしたPower BIカスタムビジュアルの検証対象が増える |
| On-object formatting APIのGitHubリソース | 「リンク提供予定」から実際のGitHubリポジトリへの参照に変更 | 型定義やユーティリティの参照先を公式リポジトリで確認しやすくなる |
この更新は、すぐに全環境で挙動が変わることを意味するものではありません。公式ドキュメント上の記述変更であるため、開発・運用側では「仕様として何が明示されたか」「自社環境でどう検証するか」「既存の設計判断を変える必要があるか」を分けて確認する必要があります。
Local Storage APIで確認すべき点
Power BIカスタムビジュアルのLocal Storage APIは、ブラウザーのローカルストレージにデータを保存するためのAPIです。Microsoft Learnでは、利用には顧客側のlocal storage admin switchが有効である必要があり、各ビジュアルタイプごとにストレージアクセスが分離されると説明されています。(Microsoft Learn)
今回の更新で、対応環境の一覧に「Mobile」が含まれるようになりました。現在のMicrosoft Learn上でも、Local Storage APIの対応環境としてWeb、Desktop、SaaS Embed、Mobileが記載されています。(Microsoft Learn)
Mobile対応を見たときの判断基準
Mobileが記載されたからといって、すぐに「すべてのモバイル利用で問題なく使える」と判断するのは危険です。Power BIのモバイル利用では、OS、アプリ版数、認証状態、組織の管理設定、ブラウザーや埋め込み環境との差異が影響します。
確認時は、次のように分けて考えると判断しやすくなります。
| 確認観点 | 確認内容 | 判断の目安 |
|---|---|---|
| 機能面 | get、set、remove、statusが期待どおり動くか | PC版と同じ前提で使わず、Mobile実機で確認する |
| 管理面 | tenant admin switchや組織ポリシーと矛盾しないか | 管理者設定で無効化される場合を想定する |
| データ面 | 保存するデータが組織ポリシーに適合しているか | 個人情報・機密情報は保存しない、または暗号化を検討する |
| UX面 | モバイルで保存値が反映されるタイミングに違和感がないか | 画面更新、再起動、再サインイン時の挙動を確認する |
特に、Local Storage APIは「ユーザーがサインインしている場合のみサポートされる」「PDFやpptxへのエクスポート時にはサポートされない」「データは最終変更から29日後にクリアされる」といった制限も記載されています。モバイル対応だけを見て採用を決めるのではなく、これらの制約を合わせて確認する必要があります。(Microsoft Learn)
開発者が見直すべき実装ポイント
Local Storage APIを使っているカスタムビジュアルでは、statusメソッドの確認を省略しないことが重要です。Microsoft Learnでも、get、set、removeを使う前にAPIの状態を確認することがベストプラクティスとして示されています。(Microsoft Learn)
実装では、次のようなケースを必ず想定します。
| 想定ケース | 起こり得る問題 | 実装上の対策 |
|---|---|---|
| 管理者がAPIを無効化している | 保存処理が失敗する | PrivilegeStatus.DisabledByAdminを検知して代替表示を出す |
| ビジュアル側で権限宣言がない | APIが使えない | capabilitiesのprivileges設定を確認する |
| 環境が未対応 | PCでは動くが別環境で失敗する | PrivilegeStatus.NotSupported時の分岐を用意する |
| 保存済みデータが取得できない | 初回表示や期限切れで値がない | 初期値を用意し、取得失敗をエラー扱いだけにしない |
たとえば、ユーザーが前回選んだ表示設定や簡易的なUI状態を保存する用途であれば、Local Storage APIは有効です。一方、業務上重要な設定値、監査対象データ、個人情報、レポートの正本となるデータを保存する用途には向きません。ローカルストレージは便利ですが、永続的な業務データベースではないと考えるべきです。
On-object formatting APIで確認すべき点
もう一つの変更は、On-object formatting APIの「GitHub resources」セクションです。更新前は「API公開後にリンクを提供する」という趣旨の記述でしたが、更新後はmicrosoft/powerbi-visuals-apiとmicrosoft/powerbi-visuals-utils-onobjectutilsへの具体的なGitHubリポジトリ参照が追加されています。(GitHub)
On-object formatting APIは、Power BIのビジュアル上で対象要素を直接選択し、書式設定を行いやすくするためのAPIです。Microsoft Learnではプレビューとして扱われており、対応するビジュアルではgetFormattingModel APIの実装が必要とされています。(Microsoft Learn)
GitHubリソースが明示された意味
GitHubリポジトリへの参照が明確になったことで、開発者は次の確認をしやすくなります。
| 確認対象 | 何を見るべきか | 目的 |
|---|---|---|
powerbi-visuals-api | 型定義、APIインターフェース、リリース情報 | 実装時に参照する仕様の確認 |
powerbi-visuals-utils-onobjectutils | HTMLSubSelectionHelperなどのユーティリティ | On-object formatting実装の簡略化 |
| Microsoft Learn本文 | 実装手順、制約、利用条件 | 公式ドキュメントとしての設計判断 |
特にHTMLSubSelectionHelperは、サブ選択のアウトライン作成や管理を支援するユーティリティとして説明されています。対象要素を直接選択して書式設定するUIでは、DOM上のどの要素をサブ選択可能にするか、どの属性を持たせるかが実装品質に直結します。(GitHub)
運用影響：管理者とアーキテクトが見るべきポイント
今回の更新は、開発者だけでなくクラウド管理者やソリューションアーキテクトにも関係します。理由は、Local Storage APIがユーザーの環境・管理設定・データ保存ポリシーに影響するためです。
管理者はローカル保存の扱いを確認する
Local Storage APIでは、保存されるデータが組織ポリシーに適合しているかを開発者が確認し、必要に応じてユーザーに通知したり暗号化したりする責任があると説明されています。(Microsoft Learn)
管理者は、次の観点で利用可否を判断するとよいでしょう。
| 観点 | チェック内容 |
|---|---|
| セキュリティ | 機密情報、個人情報、認証情報を保存していないか |
| ガバナンス | 組織のデータ保持・削除ポリシーと矛盾しないか |
| 監査 | 保存内容が監査対象になる場合、追跡できる設計になっているか |
| 利用環境 | Web、Desktop、SaaS Embed、Mobileで想定どおり動くか |
| 障害対応 | 保存データが失われても業務が止まらないか |
ローカルストレージに保存するデータは、基本的に「失われても再設定できる補助的な情報」に限定するのが安全です。たとえば、表示状態、UIの折りたたみ設定、前回選択した軽微なオプションなどです。反対に、レポートの計算結果、承認状態、業務判断に使う値は別の信頼できる保存先を使うべきです。
アーキテクトは「対応環境」と「実装保証」を分けて考える
公式ドキュメントに対応環境が追加されると、利用部門から「モバイルでも使えるはず」と期待されることがあります。しかし、アーキテクトは「ドキュメント上の対応」と「自社で保証する動作範囲」を分ける必要があります。
たとえば、設計書や運用手順には次のように書き分けると誤解を防げます。
| 記載項目 | 書き方の例 |
|---|---|
| 公式仕様 | Microsoft LearnではLocal Storage APIの対応環境にMobileが含まれている |
| 自社保証範囲 | 当社ではPower BI ServiceのWeb利用とPower BI Mobileの指定バージョンで検証する |
| 非保証範囲 | 未検証のOS、旧バージョンのアプリ、特殊なキオスク環境では保証しない |
| 障害時対応 | 保存値が取得できない場合は初期設定に戻す |
この分離がないと、公式ドキュメントの一文がそのままSLAのように扱われ、運用トラブルの原因になります。
移行準備としてやるべきこと
今回の更新を受けて、すでにPower BIカスタムビジュアルを開発・運用しているチームは、次の順番で確認すると効率的です。
| 手順 | 作業内容 | 担当 |
|---|---|---|
| 1 | 該当ビジュアルがLocal Storage APIを使っているか確認する | 開発者 |
| 2 | statusメソッドによる状態確認とエラーハンドリングを見直す | 開発者 |
| 3 | Mobile環境で保存・取得・削除の動作を実機検証する | 開発者、QA |
| 4 | 保存データの内容が組織ポリシーに適合するか確認する | 管理者、セキュリティ担当 |
| 5 | On-object formatting APIの参照先をGitHubリポジトリに更新する | 開発者、技術リード |
| 6 | 設計書、運用手順、利用者向け説明を更新する | アーキテクト、運用担当 |
ここで重要なのは、いきなり実装変更に入らないことです。今回のコミットはドキュメント更新であり、ライブラリやサービスの強制移行を示すものではありません。まずは影響範囲を特定し、検証結果に基づいて対応の優先順位を決めるべきです。
よくある誤解と注意点
GitHubそのものの仕様変更ではない
今回の更新はGitHub上のMicrosoftDocsリポジトリで行われた公式ドキュメント更新です。GitHub Actions、GitHub Enterprise、GitHub APIなどのGitHubサービス自体が変更されたわけではありません。
検索で「GitHub documentation update: updating」と見つけた場合でも、対象リポジトリと変更ファイルを確認し、どの製品・サービスのドキュメントなのかを切り分ける必要があります。
Mobileが書かれたからといって検証不要ではない
Mobileが対応環境に追加されていても、実際のユーザー体験は端末、アプリ、認証、管理設定に左右されます。特に企業利用では、条件付きアクセス、モバイルアプリ管理、端末制御などが絡むため、机上確認だけでリリース判断をしないほうが安全です。
GitHubリポジトリを見てもMicrosoft Learnの確認は省略しない
APIの型定義やユーティリティはGitHubで確認できますが、利用条件、制約、実装手順はMicrosoft Learn側にまとまっています。GitHubだけを見ると実装の細部は分かっても、公式ドキュメント上の制約を見落とす可能性があります。
開発時は、Microsoft Learnで仕様と制約を確認し、GitHubで型定義やユーティリティの実装・更新状況を見る、という役割分担で確認するのが現実的です。
開発チームで使える確認チェックリスト
今回の更新をチームで確認する場合は、次のチェックリストを使うと抜け漏れを減らせます。
| チェック項目 | 完了条件 |
|---|---|
| 変更された2ファイルを確認した | local-storage.mdとon-object-formatting-api.mdの差分を確認済み |
| Local Storage APIの利用有無を確認した | 対象ビジュアルでstorageServiceまたはstorageV2Serviceの利用を確認済み |
| Mobile環境の検証計画を作成した | 対象OS、アプリ、認証条件、テストケースを明記済み |
| 保存データの内容を棚卸しした | 機密情報や業務上重要なデータを保存していないことを確認済み |
| エラーハンドリングを確認した | API無効、未対応、取得失敗時の挙動を定義済み |
| GitHubリソースの参照先を更新した | APIリポジトリとon-object utilsリポジトリを開発ドキュメントに反映済み |
| 利用者向け説明を見直した | モバイル利用時の制約や保存データの扱いを説明済み |
まとめ：小さなドキュメント更新でも、仕様確認と運用判断は分けて進める
GitHubの公式ドキュメント更新「updating」は、差分だけを見ると小規模な更新です。しかし、Power BIカスタムビジュアルのLocal Storage APIにMobileが記載された点、On-object formatting APIのGitHubリソースが具体化された点は、開発・運用の確認対象として十分に意味があります。
まずは、対象のPower BIカスタムビジュアルがLocal Storage APIやOn-object formatting APIを使っているかを確認してください。次に、Mobile環境での実機検証、保存データのポリシー確認、GitHubリソース参照の更新を進めます。
今回のようなMicrosoftDocs系の更新は、リリースノートほど目立たない一方で、実装判断に影響する情報が含まれることがあります。公式コミット、Microsoft Learn、関連GitHubリポジトリをセットで確認し、自社の保証範囲と運用ルールに落とし込むことが、最も安全で実務的な対応です。
コメント