Power Queryを使っています、だけでは設計が伝わらない

LWP | Power Queryを使っています、だけでは設計が伝わらない

構造・仕掛け・要素技術から考えるデータアーキテクチャー

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

ストーリー

事例取材に来たワカサギさんのノートには、Power Query、スピル、VBAと技術名がずらり。ところがシャケもんから「誰が何を受け取るかは伝わりますか？」と聞かれ、ペンが止まります。アユさんも加わり、一つのExcelの例を読み解くことになりました。

本記事では、データの「構造」、データを取り扱う「仕掛け」、データを操作する「要素技術」を統合した全体設計を、データアーキテクチャーと呼びます。業務データ設計を考えるための本記事固有の整理であり、唯一の標準分類ではありません。

どの道具を使うかだけでは、工程のつながりや受け渡しの条件は分かりません。

図1｜技術の紹介から、設計の説明へ。

どのシートに置くかに加え、列の型やキー、参照先との関係も読み取ります。

図2｜構造には、物理的な配置と論理的な関係が含まれる。

同じ場所に表があっても、元データを直接加工するのか、保持して別に整えるのかで設計は変わります。

図3｜配置を決めることと、取り扱い方を決めることは別。

技術の一覧は不要ではありません。役割と結び付けると、選んだ理由を説明できます。

図4｜参照や接続を支える機能も、実装に使う要素として捉える。

入力を保持し、数式で整え、名前付き範囲を窓口として後続へ渡す設計モデルです。

図5｜一つの図にも、所在・取り決め・実現技術が重なっている。

PreparedInputという名前があっても、約束した列や状態を満たしているとは限りません。

図6｜窓口の名前と、受け渡す中身の保証を分ける。

綴りが似ていても、Data Schemaと本記事でいうData Schemeは別の言葉です。

図7｜三つの観点は、物を排他的に分類する箱ではない。

同じPower Queryを使う方式でも、入力の変化、再利用、確認の必要性によって選び方は変わります。

図8｜構造・仕掛け・要素技術を、目的に合わせて整合させる。

「何を使っていますか」に加えて、「データはどうなっていますか」「どう取り扱う約束ですか」を説明してみましょう。技術名を増やすことではなく、三つの観点が同じ目的につながっていることが大切です。

用語の対応は、Data Structure＝データの構造（構造）、Data Scheme＝データを取り扱う仕掛け（仕掛け）、Data Manipulation Technologies＝データを操作する技術（要素技術）です。FlowをSchemeの一部とする関係も、本記事の定義に基づきます。

受け渡し条件には、先頭行が見出しかどうか、列名・型、0件・欠損・エラーの扱い、対象期間・更新時点、整形とクエリ更新の順序を含めます。不適合を検出して停止する処理は別に設計・実装します。名前を付けるだけでは自動的に検査されません。

今回の接続例は設計モデルで、実ブックでの動作・性能・障害時の更新順序は検証していません。採用時は名前のスコープと参照式、見出しの扱い、取得結果、再計算と更新順序を実環境で確認してください。方式Bが常に優位だという主張でもありません。

著者元ネタ「データアーキテクチャーとは何か」（2026年9月14日整理、S2）を基に構成しました。三観点の定義と英日表記は同資料の著者による整理です。

Microsoft Learn「Excel.CurrentWorkbook」は、同関数がテーブル・名前付き範囲・動的配列を返すことの確認に使用しました。個別の接続モデルの実測根拠ではありません。

Microsoft Support「Dynamic array formulas and spilled array behavior」は、数式の複数結果が隣接セルへ展開される基本動作の確認に使用しました。公式資料の確認日は2026年9月23日です。