こんばんは。皆さま、いかがお過ごしでしょうか?

“室長”こと吉島良平(Microsoft MVP for Business Applications　|　Microsoft Regional Director)です。

自分がこれまでやってきたスポーツの競技人口って、この50年でどう変わったんだろう。ふと気になって、野球・サッカー・ラグビー・アメフトの公式登録者数の推移を、自分なりに調べてグラフにしてみました。

野球は1976年頃の170万人から、2026年頃には101万人まで、40.6%減少。サッカーも1996年の96万人をピークに、直近は76万人まで落ち込んでいます。ラグビー、アメフトも同様の傾向です。

少子化の影響、と言ってしまえばそれまでですが、これを作りながらふと思ったのは、競技人口の減少は、そのまま将来の労働力人口の縮小を映す鏡でもある、ということです。経理・総務のような管理部門ほど、この先真っ先に人手不足の影響を受ける領域だと感じています。

Business Central × 経費管理

そんなことを考えていた矢先、Business Central 2026 release wave 1、28.3が7月1日にリリースされました。目玉はExpense Agentの多言語対応です。これまで英語(米国)限定だったExpense Agentが、ドイツ語・デンマーク語・フランス語・スペイン語でも使えるようになりました。他にも、Expense Agentでプロジェクトを直接紐づけられるようになったり、Payables Agentが50件まで無料で試せるトライアルモードがGAになったりと、地味に見逃せない更新が続いています。

この「Expense Agentの展開が進んでいる」というニュースを見ていて、ふと思い出したことがあります。2025年4月、国家公務員の旅費法が改正され、宿泊費が「定額支給」から「地域別上限付きの実費精算」に切り替わりました。東京なら19,000円、大阪なら13,000円、といった具合に、地域の実勢価格に応じた上限が設定されています。

この改正、国家公務員だけの話では終わらないだろうと見ています。今日は、この流れが中小企業の経費精算にどう影響し、Business CentralのExpense管理をどう変えていくのか、考えてみたいと思います。人口減少で経理の担い手が減っていく中、実費精算化という負担増を、どう技術で吸収していくのか、という視点も添えながら。

---

第1章　なぜ「実費精算」への移行が進むのか

国家公務員の旅費法は、民間企業の出張旅費規程にとって長年、事実上のモデルケースでした。財務省のルールが変われば、それに合わせて自社の規程を見直す企業が一定数出てくる、というのがこれまでの経験則です。

今回の改正の背景にあるのは、インバウンド需要の回復や物価上昇によるホテル代の高騰です。「定額支給だと、上限内で泊まれるホテルが交通の便の悪い場所にしかない」「上限を超えた分は自腹になる」という声は、実際に人事・総務の現場でもよく聞く相談です。

定額支給の楽さは、「相場と合わなくなった時に一気に破綻する」という弱さと表裏一体です。実費精算(上限付き)への切り替えは、まさにこの弱さへの対処であり、旅費法改正はそれを後押しする形になっています。

---

第2章　実費精算になると、領収書の重要性が一気に増す

定額支給の世界では、極端に言えば「出張した」という事実さえ確認できれば、決まった額を払うだけで済みました。領収書は「念のため」の位置づけで、あくまで補助的な証憑でした。

しかし実費精算(上限付き)になると、話は変わります。

• 実際にいくら払ったのか(領収書の金額)
• 上限内に収まっているか(地域別の上限額との突き合わせ)
• 上限を超えている場合、承認された例外か(申請・承認履歴)

これらすべてが、領収書という1枚の紙(あるいはPDF)を起点に判断されるようになります。つまり実費精算化とは、「領収書1枚1枚の重みが増す」ということと、ほぼ同義です。

そして、この変化は経理・総務にとって、地味に重い負担増になります。宿泊費だけで見ても、出張者ごとに、地域ごとに、上限額との突き合わせを人力でやるのは、正直かなりしんどい作業です。

---

第3章　実費精算への移行が、経理の負担とExpense Agentの価値を同時に押し上げる

まず、なぜ「実費精算化」がこれほど現実味を帯びているのか、データで確認しておきます。

東京商工リサーチの調査によると、上場ホテル運営13社(15ブランド)の2025年3月期の平均客室単価は16,679円で、前年同期比12.6%増。コロナ禍で最安値だった2021年同期の7,755円と比べると、実に114.5%増、2倍以上に跳ね上がっています。ビジネスホテル大手8ブランドに限定したデータでも、2021年同期の6,180円から2025年同期は13,930円と、125.5%の上昇です。

背景にあるのは、インバウンド需要の急増だけではありません。宿泊業界は正社員の人手不足割合が62.9%という深刻な状態にあり、人件費の上昇分がそのまま客室単価に転嫁されています。日本経済新聞も「企業が出張宿泊費の目安とする『1万円』では泊まれないホテルが増え、規定を見直す企業も出てきている」と報じています。

実費精算化が、経理の仕事を静かに難しくする

実費精算(上限付き)になると、領収書の金額が正しいか、出張先の地域別上限額と照らして超過していないか、超過している場合は承認された例外か、という突き合わせが、出張のたびに、地域ごとに発生します。件数が多い企業ほど、この負担は無視できないレベルになります。

だからこそ、Expense Agentのような機能の価値が上がる

Expense Agentは、領収書から店舗名・日付・金額を自動抽出し、カテゴリ分類・明細化を行った上で経費レポートを生成します。地域別のExpense Locationsと組み合わせれば、「この領収書は東京出張のものだから上限19,000円と照合する」という判断も、理論上は自動化の対象になります。

つまり、実費精算化というトレンドが経理の負担を増やす一方で、その負担を吸収する道具として、Expense Agentのような機能の必要性そのものが高まっている、という構造です。

構造化データは、電帳法とどう繋がるのか

Expense Agentが領収書から抽出する日付・金額・取引先といった情報は、単に便利なだけでなく、電子帳簿保存法(電帳法)への対応を考えるうえでも意味を持ちます。

2024年1月から、電帳法により、電子データで受け取った領収書は紙に印刷して保存することが認められず、電子データのまま、「真実性の確保」(改ざん防止)と「可視性の確保」(日付・取引先・金額での検索)という要件を満たして保存することが義務付けられています。

これがBC内部でどう処理されるのか、図で整理してみます。

Expense Reportを記帳すると、実は3つのエントリが同時に生成されます。G/L Entryは複式簿記の記録そのもので、試算表・財務諸表に反映されます。Employee Ledger Entryは、Vendor Ledger Entryと同じ発想で、「会社が従業員にいくら払うべきか」という残高を管理し、Payment Journalで払戻処理をすると消込(Apply)されます。見落としがちですが、このPayment Journal自体もまた、別のG/L Entry(現金・預金の減少)を生成します。Expense Ledger Entryは消込の対象にはならず、部門・プロジェクト・製品セグメント(BC/FO/CRMなど)といったディメンションごとに、経費を集計・分析するための土台になります。

この構造、電帳法対応を考えるうえでも重要な意味を持ちます。領収書という「証憑」から始まり、Expenseという「経費明細」を経て、Expense Ledger Entryという「検索可能な構造化データ」にたどり着く、というのがこの図の右側の流れです。電帳法が求める可視性の要件は、まさにこの最後の段階で満たされるべきものです。

では、日本でいつ使えるのか

正直なところ、はっきりした時期は分かりません。Expense Agentは28.1で英語(米国)限定のPublic Previewとして登場し、28.3(2026年7月)でドイツ語・デンマーク語・フランス語・スペイン語に展開されました。この2ヶ月弱で4言語が追加されたペースを見る限り、今後も言語展開は続くと予想されますが、日本語がいつ加わるかについて、公式なアナウンスは今のところ見当たりません。

おまけ:実費精算だからこそ見えてくる、面白い論点

ひとつは、移動時間や移動距離をお客様に請求する契約形態を持つ企業の存在です。コンサルティングやSIerの業界では、遠方の現場への移動時間そのものをチャージ対象にしているケースがあります。この場合、経費精算は単なる「払い戻し」ではなく、「顧客への請求根拠」にもなるため、精度と証跡の重要性がさらに一段上がります。

もうひとつは、海外出張がある場合の通貨の話です。国内出張の宿泊費は円建てですが、同じ出張で海外拠点にも立ち寄る場合、1枚の経費レポートの中に円建てと外貨建ての明細が混在することになります。これについては、章を改めて詳しく見ていきます。

---

第4章　多通貨対応の裏側と、為替タイミングが生む差損益

Expense Agentの仕組みを調べてみると、思った以上にきちんと設計されていることが分かりました。

Expense Agentは、領収書をアップロードすると、店舗名・日付・金額とあわせて通貨そのものを領収書の内容から自動検出します。日当(per diem)については、公式ドキュメントに明記があり、外貨建てで支払われる日当は、設定された為替レートを使ってローカル通貨に自動変換されます。個別の経費明細についても、財務データや記帳ロジックはすべてBC内部で処理される以上、通貨換算はBC標準の為替レートテーブルの仕組みに乗ることになります。

これが実際に機能するのは、Expense Agentがすでに独・丁・仏・西という、ユーロ圏・デンマーククローネ圏・スイスフラン圏を含む複数通貨圏に展開されているからこそだと思います。

通貨換算のタイミングがずれると、何が起きるか

多通貨案件で実務上よく起きるのが、「従業員への立替精算」と「お客様への再請求」で為替レートがずれることによる差額です。

まず考え方の整理から。これは教科書的な「為替差損益」と言い切るには少し注意が必要です。古典的な為替差損益は、外貨建ての債権・債務を保有し続けて、その評価替えや決済時のレート差から生じるものです。しかし今回のケースは、「従業員への立替精算(コスト計上)」と「お客様への再請求(収益計上)」がそれぞれ別々の取引として、それぞれの時点のレートで確定しているものです。つまり原則としてはプロジェクト採算の一部(マージンの増減)であり、教科書的な為替差損益とは性質が異なります。ただし実務上は、この差額を意図的に為替差損益(または為替影響額)として切り出して可視化する、という方針を取る会社もあります。

BCのDimension機能を使って、部門コード・プロジェクトコード・製品セグメントコードを付与すると、こんな仕訳例になります。

ケース1:円安方向に振れて、差益になるパターン

① 従業員への立替精算(Expense Agentで処理、7/15の為替レート 1USD=156円で計上)

借方	金額	貸方	金額	部門	PJコード/名称	Segment
旅費交通費	78,000			Consul A	PJ-2026-0157｜北米自動車部品G社 BC導入	BC
		未払費用(従業員精算)	78,000	Consul A	PJ-2026-0157｜北米自動車部品G社 BC導入	BC

② お客様への再請求(顧客請求書発行日7/25の為替レート 1USD=158円で計上)

借方	金額	貸方	金額	部門	PJコード/名称	Segment
売掛金	79,000			Consul A	PJ-2026-0157｜北米自動車部品G社 BC導入	BC
		立替金収入(再請求収益)	78,000	Consul A	PJ-2026-0157｜北米自動車部品G社 BC導入	BC
		為替差益(営業外収益)	1,000	Consul A	PJ-2026-0157｜北米自動車部品G社 BC導入	BC

ケース2:円高方向に振れて、差損になるパターン

同じプロジェクトで、今度は逆に、立替時より請求時の方が円高に振れたとします。

① 従業員への立替精算(7/15の為替レート 1USD=156円で計上、内容はケース1と同じ)

② お客様への再請求(顧客請求書発行日7/25の為替レート 1USD=154円で計上)

借方	金額	貸方	金額	部門	PJコード/名称	Segment
売掛金	77,000			Consul A	PJ-2026-0157｜北米自動車部品G社 BC導入	BC
為替差損(営業外費用)	1,000			Consul A	PJ-2026-0157｜北米自動車部品G社 BC導入	BC
		立替金収入(再請求収益)	78,000	Consul A	PJ-2026-0157｜北米自動車部品G社 BC導入	BC

実費精算×多通貨案件は、儲かる時もあれば損する時もある、為替タイミング次第の運ゲー要素がある、というのがリアルな実務の姿です。Consul A・Consul Bのように複数コンサル部門がある場合、部門×Segment(BC/FO/CRM)で差損益を集計すれば、「どの部門・どの製品ラインの海外案件で、為替タイミングによる影響が大きいか」を分析できるようになります。

---

第5章　BCでは、具体的にどう設定するのか

実際の設定は、次のような要素の組み合わせになります。

• Expense Locations: 国・地域、あるいは都市単位で宿泊費の上限額を定義するための項目です。「東京」「大阪」といった単位でロケーションを作成し、地域別の日当・宿泊費レートを設定できます
• Expense Rules: カテゴリ×ロケーション×有効期間の組み合わせで、金額の上限などの条件を設定できます。最も具体的に一致するルールが自動適用される仕組みです
• Per diem計算: ロケーションごとに設定した日当額をもとに、フルデイ/パーシャルデイの計算式で自動算出されます

つまり、「東京は上限19,000円、大阪は13,000円」というような地域別ルールを、そのままExpense LocationsとExpense Rulesの組み合わせで再現できる、ということです。

ただし、Expense Rulesには限界があります

Expense Rulesが判定できるのは、あくまで金額ベースの条件です。「出張は原則エコノミークラス、ただしフライト時間6時間以上はビジネスクラス可」といった、自然言語の社内規定を直接判定する機能(Policies)は、現時点ではまだリリースされていません。

Copilot Studioで、この隙間を埋める

ここで使えるのが、Copilot Studioのカスタムエージェントです。BCへの接続方法には、標準アクションを使うコネクタ方式と、BCの標準APIを一括で公開するMCPサーバー方式があります。加えて、Copilot Studioのエージェントには、SharePoint上のドキュメントをナレッジソースとして追加できる機能があります。

この2つを組み合わせると、次のようなシナリオが組めます。

BCのExpense Rulesは、宿泊日数そのものを条件にする機能は見当たりません。同一出張の複数日分のレポートをまとめて取得し、こうした複数日・役職といった追加条件を踏まえた判断を、Copilot Studio側で補うイメージです。

これは、BCのExpense Rulesという「金額ベースの機械的な判定」と、Copilot Studioという「自然言語の社内規定・役職や日数といった追加条件を踏まえた判断」を組み合わせることで、まだ存在しない「Policies」機能を、今すぐ部分的に代替する構成です。あくまでエージェントは判断材料を提示するだけで、最終的な承認判断は人間(承認者)が行う、という建付けにするのが誠実だと思います。

---