― テーブル ID・ファイルロック・JSON マッピング設計 ―
はじめに
本記事は、Power Automate のクラウドフローにおいて
Excel Online (Business) を業務用途で連携した際に直面した技術的な課題を整理したものです。
特に本記事では、
- Excel テーブル内部 ID の扱い
- SharePoint ファイルロックの実態
- Microsoft ベストプラクティス（GUI マッピング）の前提条件
- JSON マッピング設計への移行理由
といった点を、設計・構造の観点から解説します。
Excel Online (Business) は「UI より内部構造を理解すべき」
Excel Online (Business) のアクションは、UI 上は非常に分かりやすく設計されています。
- 「表に行を追加」
- 列名＝入力項目
- 動的コンテンツを選択するだけ
しかし、業務用途で利用すると次の前提条件が顕在化します。
- Excel テーブルは 内部 ID で管理されている
- 列構成・順序・型が完全一致している必要がある
- UI は内部構造を抽象化しているだけ
つまり、「見た目が同じ Excel」は 同一ではない という前提で設計する必要があります。
テンプレートコピーで壊れる Excel：テーブル ID 問題
Excel テンプレートを SharePoint に配置し、それをコピーして使う設計を採用していました。
しかし次の問題が発生しました。
- テーブル名は同じ
- 列構成も同じ
- それでも Power Automate から操作できなくなる
原因は、Excel テーブルの内部 ID がコピー時に変わることでした。
この ID は UI から確認できないため、
- 保存時エラー
- 実行時エラー
- 昨日まで動いていたものが突然壊れる
といった状態になります。
Excel 操作直後に失敗する理由：SharePoint ファイルロック
もう一つ問題になったのが、ファイルロックです。
- Excel Online (Business) で行追加
- その直後にファイル削除・移動・更新
- SharePoint 側でロックされてエラー
これは Excel 操作が SharePoint ファイルを一時的に占有する構造になっているためです。
重要なのは、
Power Automate 自身がロックの原因になり得る という点です。
設計上、
- 「処理が終わったらすぐ消す」
- 「すぐ次の処理に回す」
という前提は置かない方が安全です。
GUI マッピング方式の技術的な限界
Microsoft の公式ドキュメントでは、
Excel テーブルへの書き込みは GUI マッピング方式 が基本とされています。
しかし、実務では次の問題が顕在化しました。
- 変換ロジック（formatDateTime など）が UI に分散
- 列追加・変更のたびに GUI を全修正
- 差分・影響範囲が追いにくい
- テーブル ID 問題の影響を強く受ける
GUI 方式は「簡単な用途」には向きますが、
長期運用・仕様変更前提の業務用途では脆いと感じました。
JSON マッピング設計の具体例（技術視点）
そこで採用したのが、JSON で 1 行分のデータ構造を定義する設計です。
{
"輸送ID": "@{items('Apply_to_each')?['pps_transportationid']}",
"発送日": "@{formatDateTime(items('Apply_to_each')?['pps_shippingdate'],'yyyy/MM/dd')}",
"到着日": "@{formatDateTime(items('Apply_to_each')?['pps_arrivaldate'],'yyyy/MM/dd')}",
"発送元会社名": "@{items('Apply_to_each')?['pps_companyname']}",
"輸送ルート(SEA/AIR)": "@{items('Apply_to_each')?['pps_transportationroute@OData.Community.Display.V1.FormattedValue']}",
"元ファイル名": "@{items('Apply_to_each')?['pps_originalfilename']}",
"取込日時": "@{formatDateTime(addHours(items('Apply_to_each')?['createdon'],9),'yyyy/MM/dd HH:mm:ss')}"
}
この JSON は、「Excel に書き込まれる完成形データ」をそのまま表現しています。
技術的メリット①：ロジックの集約と可視性
- 取得元
- 変換ルール
- 日付フォーマット
- 表示値（FormattedValue）
が JSON 1 箇所に集約されます。
GUI のように、
- 各列を個別に開く
- 隠れた式を探す
必要がありません。
技術的メリット②：Excel 依存の低減
この設計では、
- データ構造はフロー側
- Excel は単なる出力先
という責務分離が明確になります。
結果として、
- テーブル ID 変更の影響を最小化
- テンプレート差し替えが容易
- Excel 側変更に耐性が出る
という効果がありました。
技術的メリット③：変更耐性・保守性の向上
列追加・変更時の修正は、
- JSON のキー／値を修正
- Excel 側の列名を合わせる
だけで済みます。
GUI 再設定が不要なため、
修正コストと事故率が大幅に下がりました。
ベストプラクティスを外れた理由（技術的判断）
Microsoft のベストプラクティスは、
- シンプル
- 学習コストが低い
- 小規模用途向け
という前提で最適化されています。
一方、今回の用途では
- 列数が多い
- 仕様変更が避けられない
- 長期運用が前提
であったため、
GUI の簡単さよりも、構造的な安定性を優先しました。
まとめ：JSON 設計は回避策ではなく設計戦略
Power Automate × Excel Online (Business) において、
- GUI マッピングは入口
- JSON マッピングは業務設計
という位置づけが適していると感じています。
Excel を「ロジックの一部」として扱わず、
「出力インターフェース」として割り切ることが、
安定したフロー設計につながりました。