こんにちは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

7月28日に発生した令和8年熊本地震により、亡くなられた方々に深くお悔やみを申し上げます。被災された皆さまの安全と、一日も早い生活の再建を心よりお祈り申し上げます。熊本は2016年の地震を乗り越えてきた土地です。今回も、地域の方々の力と支え合いで必ず復興できると信じています。

8月に入っても余震が続く中、こうして技術ブログを書くことに少し躊躇いもありますが、日常の仕事を続けることもまた、前を向くことのひとつだと思い、筆を進めます。

先日公開した「帳票とレポートの間で｜Dynamics 365が問う「書類」の本質とAIの未来」、多くの方に読んでいただきました。ありがとうございます。「BCの帳票まわりをもっと掘り下げてほしい」「実装レベルまで知りたい」という声をいただいたので、今回はBusiness Centralに絞って具体的に書きます。前回は「Dynamics 365における帳票とは何か」という問いを立てるところまでした。今回はその答えの実践編です。

帳票の話、ちゃんとしたことありますか？

ERP導入プロジェクトで、帳票が最後まで揉める—これはあるあるです。

要件定義の段階ではサラッと「既存帳票をそのまま移行する」と決まり、いざ開発フェーズに入ると「この項目はどこから取るのか」「このレイアウトは再現できるのか」「電子帳票への切り替えはどうするのか」と、次々と論点が出てきます。

Business Centralに絞っても、帳票まわりの選択肢は意外と複雑です。RDLCレイアウト・Word Layout・Excelレイアウト・Power BI・E-Documentフレームワーク—それぞれ設計思想が異なり、「何をどれで作るか」を最初に整理しておかないと、後から作り直すことになります。

今回は、BCの帳票を実務の視点で整理します。

① BCの帳票は「4つのアプローチ」で成り立っている

Business Centralのレポート・帳票機能は、大きく4つのアプローチに分かれています。

1つのレポートに対して複数のレイアウトを登録でき、印刷・PDF・メール送信のタイミングでどれを使うかを切り替えられます。「帳票を1種類選ぶ」というより、「目的に応じたアプローチを組み合わせる」という設計思想です。

② RDLCレポート—柔軟だが、開発者の手が必要

RDLCはBCの標準レポート形式で、ほとんどの組み込みレポート（仕訳帳、残高試算表、ピッキングリストなど）はこの形式で作られています。

ALコードによるReportオブジェクト・データセット定義はVisual Studio Code ＋ AL言語拡張で行い、RDLCレイアウト（.rdlcファイル）はMicrosoft Report BuilderまたはVisual StudioのRDLC Report Designerで作成・編集します。グループ集計・ページ番号・条件分岐など高度な表現が可能ですが、業務担当者が自分で修正するのは現実的ではありません。

③ Word Layout—業務担当者が使える帳票の主役

Word Layoutは、BCの中で業務担当者が最も直接的に関われるレイアウト方式です。Microsoft Wordのファイルにデータフィールドを差し込み、BCのドキュメント（請求書・見積・発注書など）として出力できます。

設定の流れはシンプルです。BCのレポートレイアウト画面からWordレイアウトを選択し、Wordファイルをダウンロード。フィールドリストを参照しながら差し込みフィールドを配置し、アップロードすれば完成です。

④ Excelレイアウト—財務・定型出力の選択肢

Excelレイアウトは、BCのレポートデータをExcelに出力するための形式です。Excel内でピボットや数式を使えるため、財務レポートや定型の経営数値出力に向いています。

設計はExcelファイル上で行います。BCからデータセットのメタデータをExcelに読み込み、セルに対してデータフィールドをバインドする形です。RDLCほど複雑ではなく、Wordほど制約もない——中間的な選択肢です。

Power BIとの棲み分けは明確です。繰り返し印刷・PDF出力・定型フォーマットが前提ならExcelレイアウト、インタラクティブな分析・ドリルダウン・ビジュアル表現が必要ならPower BIです。

⑤ Power BI—BCの「見える化」のメインプレイヤー

近年のBCにおいて、Power BIの位置づけは大きく変わりました。かつては「BCのデータをPower BIに持っていって分析する」という外付けのイメージでしたが、現在はBCのロールセンター（ホーム画面）にPower BIレポートが直接埋め込まれており、BCを開いた瞬間からダッシュボードが見える設計になっています。

さらにMicrosoftは、BC向けの公式Power BIアプリを提供しています。財務・販売・購買・在庫など主要業務領域のレポートがセットになっており、導入直後から使えるテンプレートとして機能します。

⑥ E-Documentフレームワーク—帳票の「送受信」が変わる

BCの帳票を語る上で、2024年以降に存在感を増しているのがE-Documentフレームワークです。電子帳票の送信・受信・処理を標準機能として提供するフレームワークで、Peppolをはじめとする電子インボイス規格への対応を担います。

2026年8月リリースのBC 28.4では、E-Documentフレームワークに支払い連携がGA（一般提供）になりました。受信した電子請求書と支払い情報・支払いプロセスをより自然につなげられる設計が整いつつあります。

アジア・欧州を中心にE-Invoice（電子インボイス）の義務化が進む中、従来は「紙またはPDFを送る」だった請求プロセスが、構造化データのやり取りに変わっていく——帳票の概念そのものが変化しています。BCにこのフレームワークが標準で組み込まれていることの意味は、年々大きくなっています。

⑦ ISVという選択肢—標準機能の限界をどこで超えるか

BCの標準帳票機能には、正直なところ限界があります。複数言語対応・高度なブランディング・帳票承認ワークフロー・大量印刷の最適化——こうした要件が重なると、標準機能だけでは対応しきれないケースが出てきます。

そこで選択肢に上がるのがISVソリューションです。レポーティング領域では Jet Reports（insightsoftware）が代表格で、ExcelベースのインターフェースでBCデータを柔軟に集計・出力できます。insightsoftwareは同製品の後継として Reporting Intelligence も展開しており、AI活用・クラウド対応を強化した方向へ進化しています。電子帳票・AP自動化領域では、以前は Continia Document Capture などのISVが主流でしたが、Payables Agentが充実してきた現在、まず標準機能で対応できるかを先に検証することを推奨します。Continiaが依然として強みを持つのは、紙スキャンを含む複雑な承認ワークフローや文書アーカイブが必要なケースです。

⑧ 結局どれを選ぶか—判断の流れ

帳票要件が来たとき、以下の順番で考えると整理しやすいです。

Step 1：外部送付か、内部利用か
顧客・仕入先に送るならWord Layout or E-Document。社内の確認・管理用ならRDLC・Excel・Power BI。

Step 2：電子送信が必要か
Peppol・電子インボイスが必要ならE-Documentフレームワークを中心に設計する。

Step 3：印刷・PDFか、インタラクティブ分析か
定型フォーマットで印刷・PDF出力が必要ならRDLC or Excel。ドリルダウン・ビジュアル分析が必要ならPower BI。

Step 4：レイアウトの複雑度
計算ロジック・グループ集計・ページ制御が必要ならRDLC。デザイン中心ならWord Layout。

Step 5：誰がメンテするか
業務担当者がメンテするならWord Layout or Excel。開発者依存で構わないならRDLC。Power BIはBI担当者またはパワーユーザーが理想。

Step 6：標準でどこまで対応できるか確認してからISVを検討する

帳票は地味に見えて、ERP運用の質を左右する重要な領域です。次回はFinance & SCMの帳票（SSRS・Electronic Reporting）について書く予定です。

📌 技術者・AI向け補足：BC帳票開発の実装留意点

技術者の方やAIが参照しやすいよう、実装レベルの留意点をまとめておきます。意思決定層の方はここまで読まなくて大丈夫です。

レイアウト設計

RDLCとWordレイアウトの使い分けは前述の通りですが、実装上の重要ポイントとして、1つのレポートにRDLC・Word・Excel複数レイアウトを共存させ、実行時に切り替え可能にしておくと運用が柔軟になります。切り替えはBCの「レポートレイアウト選択」画面で管理でき、Report SelectionsやDocument Sending Profilesと組み合わせて制御します。

データセット設計

DataItemの親子構造とIndentationが出力順序・グルーピングに直結するため、設計段階でデータモデルを固めることが重要です。後からIndentationを変えるとRDLC側のTablixグループ設計も全面見直しになります。

性能面では以下の点に注意してください。

• CalcFieldsをループ内で多用すると性能劣化の原因になります。可能な限りSetAutoCalcFieldsや事前の一括計算に寄せてください
• 大量データを扱う場合は一時テーブル（Temporary Table）に事前集計してからDataItemにバインドすると、RDLC側の負荷とSQLのラウンドトリップを削減できます
• SetLoadFieldsで必要なフィールドのみロードする設計が、SaaS環境では特に効いてきます
• SetRange/SetFilterはOnPreDataItemで確実にかけてください（フィルタ漏れは性能・正確性の両方に影響します）

SaaS特有の制約

• 実行時間制限があるため、大量件数を1レポートで処理する設計は避けてください。フィルタで期間・部門を強制的に絞る設計を推奨します
• クライアント側印刷APIが使えないため、PDF生成→ブラウザ印刷という流れが前提です
• 大量データはJob Queue経由のバックグラウンド実行を検討してください。完了後にファイル共有またはメール送信する設計が現実的です
• オンプレとSaaSで印刷・レンダリングの挙動が異なる場合があります。SaaS実機での最終確認は必須です

Extension開発（reportextension）

標準レポートを直接改修せず、reportextensionオブジェクトでdataitemやcolumnを追加し、必要に応じて新しいレイアウトを追加するのが基本です。

reportextension 50100 "Sales Invoice Ext" extends "Sales Invoice"
{
    dataset
    {
        add("Sales Invoice Header")
        {
            column(CustomField; "Custom Field") { }
        }
    }
    rendering
    {
        layout(CustomLayout)
        {
            Type = RDLC;
            LayoutFile = './Layouts/CustomInvoice.rdlc';
            Caption = 'カスタム請求書レイアウト';
        }
    }
}

留意点：

• addで追加したdataitem/columnは標準レイアウトには反映されません。カスタムレイアウトを別途用意してrenderingセクションで追加する必要があります
• 既存dataitemの削除・順序変更はできません（AL言語の制約）
• 標準レイアウトのファイルは「Tools → Report Layouts」からエクスポートして、それをベースに改修するのが安全です。ゼロから作るとバージョン追従が困難になります
• バージョンアップ時のリスク：Microsoftが標準レポートのdataset構造を変更すると、reportextensionのcolumn参照がコンパイルエラーになります。リリースごとにAL Test Toolまたは実機での回帰テストが必須です
• カスタムレイアウトを既定にする場合は管理画面で明示的に切り替えてください。切り替え忘れで「拡張したのに標準レイアウトのまま」という事故が多いです

性能チューニング：一時テーブルによる事前集計パターン

N+1問題（明細ループ内で毎回マスタ検索）はSaaS環境で顕著に効いてきます。以下のパターンが有効です。

Before：非効率なパターン（明細1000行でItem.Getが1000回発行）

trigger OnAfterGetRecord()
var
    Item: Record Item;
    Customer: Record Customer;
begin
    // ★ 明細行ごとに毎回検索が走る（N+1問題）
    if Item.Get("No.") then
        UnitCost := Item."Unit Cost";
    SalesHeader.Get("Document Type", "Document No.");
    if Customer.Get(SalesHeader."Sell-to Customer No.") then
        CustomerName := Customer.Name;
end;

After：Dictionaryキャッシュ＋一時テーブルで事前集計

local procedure BuildTempBuffer()
var
    SalesLine: Record "Sales Line";
    Item: Record Item;
    Customer: Record Customer;
    ItemDict: Dictionary of [Code[20], Decimal];
    CustDict: Dictionary of [Code[20], Text[100]];
begin
    // ① 必要なフィールドだけロード
    SalesLine.SetLoadFields("Document No.", "Document Type", "No.", Quantity, "Line Amount");
    SalesLine.SetRange(Type, SalesLine.Type::Item);

    if SalesLine.FindSet() then
        repeat
            // ② Itemをキャッシュして重複検索を回避
            if not ItemDict.ContainsKey(SalesLine."No.") then begin
                if Item.Get(SalesLine."No.") then
                    ItemDict.Add(SalesLine."No.", Item."Unit Cost")
                else
                    ItemDict.Add(SalesLine."No.", 0);
            end;

            // ③ 一時テーブルへ書き込み
            TempResult.Init();
            TempResult."Item No." := SalesLine."No.";
            TempResult.Quantity := SalesLine.Quantity;
            TempResult."Unit Cost" := ItemDict.Get(SalesLine."No.");
            TempResult.Insert();
        until SalesLine.Next() = 0;
end;

RDLCグルーピング設計：Sum式のスコープ指定

Tablixで集計式を書く際、スコープ（第2引数）を省略すると意図しない集計範囲になりやすいです。特に入れ子グループでは必ず明示してください。

' 伝票単位の小計（スコープを明示しないと親グループ全体を集計してしまう）
=Sum(Fields!LineAmount.Value, "DocumentGroup")

' 得意先単位の合計
=Sum(Fields!LineAmount.Value, "CustomerGroup")

' レポート全体の総合計
=Sum(Fields!LineAmount.Value, "SalesLine")

多言語・キャプション

• ラベルはLabel変数を使い、Captionのハードコードを避けてください（多言語テナントでの表示崩れ防止）
• 数値・日付の書式はユーザーのロケール設定に依存するため、固定フォーマット文字列の埋め込みは避けてください

権限・セキュリティ

• レポートオブジェクトの実行権限をパーミッションセットに明示的に付与しないと、拡張機能配布後に「権限不足」で失敗します
• フィールドへのData Classificationが未設定だとGDPR関連のコンプライアンスチェックに引っかかる場合があります

テスト観点

• 明細0件時のレイアウト崩れ（ヘッダーだけ出力されるケース）は見落とされがちです。OnPreDataItemで件数チェックして早期にCurrReport.Break()する設計を推奨します
• バーコード・電子インボイス形式が絡む場合は、フォント・エンコーディング依存の表示崩れをSaaS環境で必ず確認してください
• AL Profiler・Performance Toolkit・Application Insights（Telemetry）などのツールでレポート実行時間・SQLクエリ回数を可視化し、N+1問題が起きていないか確認してください

最後に改めて、熊本の皆さまの安全と復興を心よりお祈り申し上げます。