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

“室長”こと吉島良平（Microsoft MVP for Business Applications|Microsoft Regional Director）です。今日は東北地方から、このブログを書いています。

今朝、弊グループのCEOがシンガポールへと戻っていきました。この10日弱、日本のお客様やパートナー様を一緒に訪問する機会が多くありました。毎日オンラインで会話しているものの、久しぶりに腰を据えて同じ視点でマーケットと向き合う時間になり、個人的にも非常に充実した日々でした。

訪問先では、さまざまなテーマについて意見交換をさせていただきましたが、やはり中心にあったのはAIの話題です。生成AIやCopilotの活用が当たり前になりつつある中で、「どこまで業務をAIに任せるべきか」「人が関与すべき“判断”はどこに残るのか」「組織としてどう統制すべきか」といった問いは、現場の方々だけでなく、経営層とも自然に共有されるテーマになっていました。

そして、それらを整理していく中で、ひとつ共通して見えてきたことがあります。それは、AIは単に“効率を上げるツール”として使われる段階を、すでに越え始めているということです。

序章｜それは「効率化」の話ではない

少し視点をBusiness Centralに戻してみます。何故BCにするかというと、全体を俯瞰しやすいアプリだからです。

Dynamics 365 Business Central 2026 wave1でも、AIに関するさまざまな機能が追加されています。しかし、ここで少し立ち止まって全体を眺めてみると、どうにも違和感がある。これは「機能が増えた」という話ではない。もう少し深いレベルで、前提そのものが変わりつつある。その違和感の正体は、訪問先で議論していた内容とも重なります。これまで私たちは、当たり前のようにこう考えてきました。

この4〜6月、私は一貫して「Agentic」という言葉を、できるだけ“流行語”ではなく、設計原則としてどう業務に落とすかという視点で書いてきました。

• どこに人を置くのか
• どこまでを自律に任せ、どこで止めるのか
• そして、判断・実行・ログ・責任を、いかに壊れない形で組み込むか

言い換えれば、AIが業務に入っても、組織とシステムが破綻しないための前提条件を、ずっと整理していたのだと思います。そして今、その前提条件が、ようやく「思想」ではなく、業務の実体として見え始めました。

Business Centralに実装された

• Sales Order Agent
• Payables Agent
• Expense Agent

の3つは、単なる機能追加ではありません。これらは、AIが「支援」から「実行」へと一歩踏み出すときに、企業が必ず直面する問い、どこまで任せ、どこで人が介入し、誰が最終責任を持つのかを、机上ではなく、業務のど真ん中に持ち込んできた存在です。

本稿では、この3つのAgentを、便利さや機能の話としてではなく、これまで整理してきた設計原則が、業務プロセスとして実装されると何が起きるのかという視点で見ていきたいと思います。

第1章｜Sales Order Agent ― メール受注を「業務プロセス」に変える

Sales Order Agentを一言で表すなら、受注の入口（メール）を、Business Centralの取引プロセスへ接続するためのエージェントです。従来の受注業務が重い理由は、受注入力そのものよりも、その手前にある「読み解き」と「往復確認」にあります。顧客メールの意図を解釈し、顧客を特定し、品目を探し、在庫や納期を確認し、見積に落とし込み、PDF化して返信し、修正依頼があれば再び調整する。多くの現場では、この“入口の摩擦”こそがボトルネックになっていました。

Sales Order Agentが扱うのは、まさにここです。メールで届く依頼を起点に、見積（Quote）を組み立て、顧客との確認を挟みながら受注（Order）へ進める。ここで重要なのは、単なる自動入力ではなく、曖昧さや不足情報を前提とした「入口の仕事」に手を入れている点です。

1. 何ができるのか：人がやっていた“入口の作業”を肩代わりする

Sales Order Agentが狙っているのは、次のような一連の作業です。

• 顧客メールを読み、依頼の意図（品目・数量・希望条件）を整理する
• 送信者を顧客として特定し、必要なら情報を補う
• 品目候補を探し、在庫や納期の見通しを確認する
• 見積を作成し、顧客に返すための文面を準備する
• 不足情報や選択肢があれば、追加確認を行い、見積を更新する
• 顧客が承認したら、受注へつなげる

こうして書くと「全部勝手にやってくれる」ように見えますが、実態はもう少し現実的です。Sales Order Agentは、自律的に進められるところは進める一方で、要所（対外送信・重要な判断・不足情報の補完など）では、人のレビューや入力を前提に設計されています。ここに、この機能を“業務として成立させるための思想”があります。

2. Wave 1で何が変わったのか：運用できる形に寄った

Sales Order Agentを「機能」として見ると、目玉は派手ではありません。しかしwave 1の観点で重要なのは、運用に耐える形（人が追える形）に寄せてきた点です。具体的には、エージェントが進めている案件が「どこまで進んでいるのか」「どこで人が介在すべきか」が、タスクとして整理され、担当者がレビューしながら前に進められるようになっています。AIが作った見積や返信案を“裏で勝手に送る”のではなく、現場の責任分界（誰がレビューし、誰が確定するか）を保ったまま自動化できるように設計されている。ここがwave 1の実務的な価値です。

3. どう動くのか：入口はメール、進捗はタスク

Sales Order Agentの特徴は、人が手で起動する処理ではなく、入口がメールであることです。顧客からの問い合わせや依頼がメールで届くと、エージェントはそれを起点に作業を開始し、案件ごとにタスクを作ります。そして担当者は、タスクを通じて進捗を追い、必要な場面でレビューや補完を行い、処理を前に進めます。この構造が意味しているのは、単なる自動化ではありません。受注の入口は往々にして“割り込み”で発生します。メールが来るたびにコンテキストが切り替わり、見落としが起き、返信遅れが生まれ、案件が放置される。Sales Order Agentは、その入口を「タスク化」することで、処理漏れと属人化を減らす方向へ寄せています。

4. 設定（セットアップ）の要点：導入の成否は「メールボックス×権限×責任設計」で決まる

Sales Order Agentは、オンにしたら自然に動くタイプの機能ではありません。導入では次の前提をきちんと押さえる必要があります。

4.1 どのメールボックスを監視するのか

まず決めるべきは「入口」です。顧客の見積依頼・注文依頼は、どのメールボックスで受けるのか。個人宛なのか、共有の問い合わせ窓口なのか。ここが曖昧なままだと、エージェントは設計できません。

4.2 共有メールボックスを使うなら、権限が実装の要件になる

共有メールボックス運用にする場合は、メールボックス権限（閲覧・送信代行）が成立していることが前提になります。実務では「設定はできたのに動かない」の多くがここに起因します。技術の問題ではなく、権限と運用の問題です。

4.3 Company単位での運用設計

Sales Order Agentは、個人の便利ツールというより、部門・チーム運用を想定した設計です。「誰がタスクを見るのか」「誰がレビューするのか」「誰が顧客に送信するのか」を、最初に決めておかないと、便利になる前に混乱します。

4.4 利用量（コスト）と継続運用

AIエージェントは“使えば使うほど価値が出る”一方で、利用量管理の観点も必要になります。まずは小さく始め、利用量と効果を見ながら拡大する。この導入順序が現実的です。

5. 実装・運用の留意点：技術より先に「仕事の線引き」を決める

Sales Order Agentを導入するとき、いちばん危ないのは「AIがやってくれるから楽になるはず」と運用を曖昧にすることです。むしろ逆で、エージェントを入れると “誰がどこで責任を持つか” が浮き彫りになります。

留意点①：レビューの責任は人に残る
エージェントが作ったものを、どの段階で誰がレビューし、どこで確定するのか。ここが曖昧だと、現場は不安になり、結果として「結局人が全部やる」に戻ります。レビュー点を固定することが、導入成功の鍵になります。

留意点②：例外処理の設計が価値を決める
現実の受注には例外が必ずあります。価格条件、代替品提案、分納、特殊な納期、取引条件、与信、配送制約。こうした例外はエージェントに丸投げできません。Sales Order Agentは、例外を“人に戻せる設計”を取ることで現実性を確保しています。だからこそ、導入側は「どの例外を人が引き取るか」を決めておく必要があります。

留意点③：段階導入がいちばん強い
最初からフル自動を狙うより、まずは「メール→見積の下書き→人がレビュー→送信」という形で運用を固め、次に「修正往復のパターン化」「承認後の受注化」へ進める方が、確実に成果が出ます。

6. 想定利用シーン：EC/EDIの外側にある“メール受注の現実”を取りに行く

Sales Order Agentが刺さるのは、ECやEDIが整備された世界ではなく、その外側です。

• 依頼がメールで来る
• 品目表記が揺れる
• 情報が足りない
• 追加確認が必要
• それでも迅速に返したい

この領域は、これまで人の経験と根性で支えられてきました。Sales Order Agentは、この“メール受注の現実”を、業務プロセスとして整理し直すための道具です。

7. 導入チェックリスト（最初に決めるべき5項目）

最後に、導入時に最低限決めるべき項目を、自分がテストした内容に基づき纏めておきます。

• 監視するメールボックス（入口）はどれか
• 共有メールボックスの場合、必要権限は整っているか
• タスクの担当者は誰か（一次対応／レビュー／確定）
• どのタイミングで人がレビューし、顧客送信を確定するか
• まずはどこまで任せるか（段階導入の第一段階を決める）

結論：Sales Order Agentは「入力の自動化」ではなく「入口の再設計」である

Sales Order Agentは、営業を置き換えるものではありません。置き換えようとしているのは、営業が抱えてきた“入口の事務作業”です。そして本質は、受注の入口を速くすることではなく、入口の曖昧さを前提にしたプロセスを、タスクとして扱える形に整えることにあります。受注の主語が、人からエージェントへ完全に移るわけではありません。しかし、最初に動き出すのがエージェントになり、人はレビューと判断に集中する―その構図が見え始めたこと自体が、大きな変化です。

第2章|Payables Agent ― 請求書処理を「例外対応」に変える

Payables Agentを一言で表すなら、仕入先請求書の処理を、入力中心の仕事から“例外中心の仕事”へ移行させるエージェントです。多くの企業で買掛金（AP）の現場が重い理由は、支払いそのものよりも、請求書を開いて内容を読み取り、転記し、突合し、仕訳を整え、承認に回し、差異があれば関係者へ確認し…という「事務処理の連鎖」にあります。

Payables Agentが狙っているのは、まさにこの部分です。請求書（多くはPDFなど）を起点に、必要な情報を読み取り、取引データへ落とし込み、可能な範囲で照合・分類を進め、人は“判断が必要なもの”に集中する。ここが本質です。

1. 何ができるのか：請求書処理の“読み取り〜下書き作成”を肩代わりする

Payables Agentが対象にする典型的な作業は、次のような流れです。

• 仕入先から届く請求書（PDF等）を受け取る
• 請求書の項目（仕入先、金額、日付、明細など）を読み取る
• 既存の発注・受領・過去取引と照合できるものは照合する
• 勘定科目や費目の当て先を整え、伝票（購入請求書等）を下書きとして作成する
• 人がレビューし、必要なら修正し、承認フローへ回す
• 差異・不明点は“例外”として人へ戻し、必要に応じて確認する

ここでの重要ポイントは、Payables Agentが「勝手に仕訳を確定して支払う」ことではありません。
下書きと判断材料を整え、人が最終判断できる形にすることです。だからこそ、導入の成否はAIの精度だけではなく、「どこでレビューし、誰が確定するか」という運用設計で決まります。

2. Wave 1で何が変わったのか：運用の現実に寄った“見える化”と“統制”

Payables AgentをWave 1の観点で語ると、焦点は派手な自動化ではなく、現場運用の成立条件を満たす方向へ寄った点にあります。
AIが作った下書きや提案が、業務の流れの中でレビューされ、承認プロセスへつながり、例外が見える形で戻ってくる。
さらに「エージェントがどこまで処理したのか」をチームで把握できることが、地味ですが効きます。買掛金は属人化しやすい領域なので、見える化ができない自動化はむしろリスクになりがちです。
Wave 1では、この“AIがやったことを人が追える”という前提が強く意識されており、単なる自動化ではなく、統制された運用へ寄せている点に価値があります。

3. どう動くのか：入口は請求書、進捗はタスク（そして人が止められる）

Payables Agentの理解で大事なのは、これが「対話で起動する便利機能」ではなく、トリガー（請求書受領）を起点に動き、タスクとして可視化され、人が介入できる設計だということです。
現場の感覚でいうと、

• 請求書が届く
• エージェントが下書きを作る
• 人が確認する
• 例外だけ人が対応する

この形に近づきます。そしてこの構造が意味するのは、単なる省力化ではありません。APは月末に処理が集中し、確認・差異対応・承認待ちで詰まりやすい。Payables Agentは、処理全体を前倒しし、例外を早く顕在化させる方向に寄せられます。結果として、月末の“詰まり”を減らす効果が期待できます。

4. セットアップ（設定）の要点：導入は「機能ON」より“運用設計”が先

Payables Agentも、オンにすれば自然に成果が出るものではありません。導入では次の前提を押さえる必要があります。

4.1 入口を決める（どの請求書が対象か）

請求書が入ってくる入口は複数あります。共有メール、部門別メール、請求書ポータル、紙のスキャンなど。Payables Agentを活かすには、「どの入口をまず対象にするか」を決める必要があります。最初から全社一括でやるより、対象を絞って始めるほうが成功率が高いです。

4.2 権限と責任の設計（誰がレビューし、誰が確定するか）

請求書処理は会社の統制そのものです。エージェントが下書きを作っても、確定と承認は人が持つ。「誰がレビューするのか」「承認フローはどうつなぐのか」を曖昧にすると、導入が止まります。

4.3 コストと利用量管理

AIエージェントは利用量に応じた消費・課金の考え方が絡みます。“試して終わり”にしないために、少量の対象から始め、利用量と効果を見ながら広げるのが現実的です。

5. 実装・運用の留意点：Payables Agentは「会計の自動化」ではなく「例外管理の自動化」

Payables Agentを入れると、業務がラクになる一方で、現場の仕事の形が変わります。ここを見誤ると失速します。

留意点①：精度より先に“例外の扱い”を決める
請求書処理は必ず例外が出ます。発注がない請求、金額差異、単価違い、分割請求、送料や諸経費、部門コード不足など。Payables Agentの価値は、これをゼロにすることではなく、例外を早く、明確に、人に返すことにあります。だから導入側は「どの例外を誰が引き取るか」を先に決める必要があります。

留意点②：レビューの設計が“監査対応”を左右する
AIが作った下書きが増えるほど、「どこで人が確定したか」が重要になります。レビューの観点（必ず見る項目）を決め、レビュー手順を固定化しないと、監査・内部統制の観点で不安が残ります。

留意点③：段階導入が最強（いきなり全自動を狙わない）
最初は、「請求書の読み取り→下書き作成→人がレビュー→承認」ここまでで十分です。次に、照合の範囲を広げたり、例外パターンを整備したりしていく。Payablesは“積み上げるほど効く”領域なので、小さく始めるのが賢いです。

6. 想定利用シーン：APの現場が詰まる会社ほど効く
Payables Agentが効きやすいのは、例えば次のような状況です。

• 月末に請求書処理が集中し、支払確定が詰まりやすい
• 請求書の形式がバラバラで、手入力が多い
• 発注・受領との突合に時間がかかる
• 担当者の経験に依存しており、属人化している
• 少人数でAPを回しており、例外処理に追われている

こうした環境では、入力作業を減らすだけでなく、例外を早期に見える化し、担当者が判断に集中できること自体が価値になります。

7. 導入チェックリスト（最初に決めるべき5項目）

最後に、Payables Agentを入れる前に最低限決めるべきことを自分がテストした内容に基づき纏めておきます。

• 対象にする請求書の入口はどれか（共有メール等、まず絞る）
• レビュー担当者は誰か（部門・拠点・会社単位の責任者）
• どのタイミングで確定するか（承認フローとの接続点）
• 例外の扱い（差異・不足情報・発注なし請求などを誰が引き取るか）
• 利用量と運用（まずは小さく始め、効果と負荷を見て拡大する）

結論：Payables Agentは「入力の自動化」ではなく「例外に集中するための再設計」

Payables Agentは、経理担当者を置き換えるものではありません。置き換えるのは、経理担当者が抱えてきた“読む・転記する・下書きを整える”という作業です。本質は、請求書処理を速くすることだけではなく、人が判断すべきところだけが残るように、業務全体を組み替えることにあります。

買掛金業務は、最終的に会社の信用とキャッシュに直結します。だからこそ、AIは“勝手にやる”のではなく、“人が決められる形に整える”方向に進む。Payables Agentは、その方向性を最も分かりやすく示している存在だと思います。

第3章｜Expense Agent ― 経費精算を「入力」から「証憑中心のワークフロー」へ戻す

Expense Agentを一言で表すなら、経費精算を“入力作業”から解放し、証憑（レシート／領収書）とポリシー（規程）を中心に再設計するエージェントです。多くの会社で経費精算が重い理由は、金額そのものではなく、申請者・承認者・経理がそれぞれ別の視点で同じ情報を何度も扱うことにあります。

• 申請者は、レシートを見ながら項目を入力し、用途を書き、勘定や部門を悩み、添付を整える
• 承認者は、妥当性や規程違反がないかを見つつ、判断材料が足りなければ差し戻す
• 経理は、会計処理の観点で、税区分・勘定・証憑の整合性を確認し、必要なら修正・問い合わせをする

この“同じ情報を、違う責任で、何回も触る”構造が、経費精算の摩擦の正体です。Expense Agentが狙っているのは、ここを「人の頑張り」で回すのではなく、証憑を起点に必要情報を整え、判断と承認だけを人に残すという形です。

1. 何ができるのか：レシート起点で“申請を完成形に近づける”

Expense Agentが肩代わりしようとしているのは、経費精算の中でも特に手間が大きい部分です。

• レシートや領収書から、日付・金額・支払先などの情報を拾う
• 経費の種別や用途の候補を整える（人が迷いがちなところを減らす）
• 申請書（経費精算の下書き）を作り、添付を揃え、承認に回せる形にする
• 承認プロセスの中で、申請者・承認者が確認すべきポイントを明確にする

ここでの重要ポイントは、Expense Agentが「経費を勝手に計上する」ことではありません。申請者の入力負担を減らしつつ、承認者と経理が判断できる材料を最初から揃えることです。つまり、最終的な責任を人に残したまま、前段の“整形”を機械に寄せる設計です。

2. Wave 1で何が変わったのか：経費精算を「エージェント前提」で見直し始めた

Wave 1の文脈でExpense Agentを捉えると、ポイントは「経費精算の便利機能が増えた」ではなく、経費精算をエージェントで回す前提のパーツが揃い始めたことです。経費精算は、営業や買掛金ほど“取引の中心”に見えない一方で、企業規模が大きくなるほど確実に詰まる領域です。だからこそ、Wave 1でここに手が入った意味は大きい。

• 申請の入口（証憑）
• 申請の形（下書き）
• 承認の流れ（判断ポイント）
• 人が介在する設計（差し戻し・修正）

こうした“運用の現実”を、機能というよりワークフローとして揃えにきている。この方向性自体が、Wave 1で語られてきた「AIは前に出るのではなく、業務が破綻しない形で埋め込まれる」という流れと一致します。

3. どう動くのか：入口は証憑、ゴールは「承認できる申請」

Expense Agentの理解で大事なのは、経費精算が“入力フォーム”ではなく、証憑を中心とした意思決定プロセスだという前提に戻っている点です。運用の感覚としては、次の流れに近いです。

• 申請者が証憑を用意する（撮影・添付・転送など、入口は複数あり得る）
• エージェントが情報を読み取り、申請の下書きを作る
• 申請者が不足情報だけ補い、提出する
• 承認者が、判断に必要な情報が揃った状態で承認する
• 経理が、例外だけを拾って対応する（必要なら差し戻し）

ここで重要なのは、エージェントの価値が「1→2」で終わらないことです。“承認できる申請”まで近づけるほど、承認者と経理の負担が減ります。つまりExpense Agentは、申請者の手間削減だけでなく、承認と経理処理の詰まりを減らす設計になっています。

4. セットアップ（設定）の要点：経費は「規程」と「例外」がすべて

経費精算の難しさは、企業ごとに規程が違うことです。だからExpense Agentの導入は、機能をオンにするより先に、次を押さえる必要があります。

4.1 経費規程（ポリシー）の解釈ポイントを決める

交通費、交際費、宿泊費、日当、立替、税区分、上限、添付要否。経費は例外だらけです。エージェントに期待しすぎると失敗します。最初に決めるべきは「エージェントが整える範囲」と「人が判断する範囲」です。

4.2 承認フローの責任設計

経費の承認は、単なるワークフローではなく、会社の統制です。誰が承認し、どの段階で差し戻し、どの段階で経理が介入するのか。ここが曖昧だと、エージェントが作る下書きが増えるほど混乱します。

4.3 勘定・部門・税の“最低限のルール”

入力負担を減らすほど、逆に「何を基準に分類するか」が重要になります。完全自動を狙うより、まずは“迷う項目”を減らす（選択肢の設計、候補提示の設計）から始めるのが現実的です。

5. 実装・運用の留意点：Expense Agentは「精算の自動化」ではなく「差し戻しの削減」

Expense Agent導入で一番大きい価値は、申請者の手間よりも、実は差し戻しの削減に出ます。差し戻しは、申請者・承認者・経理の全員の時間を奪い、月末に詰まりを作ります。

留意点①：最初から“完璧な分類”を狙わない
経費分類や税区分を100%正しく、を狙うと詰みます。現実的には、下書きの完成度を上げ、誤りや不足を早期に見える化するほうが運用効果が出ます。

留意点②：承認者が見るべきポイントを固定する
AIが生成した下書きが増えるほど、承認者は「何を見れば良いか」が分からないと不安になります。見るべき項目（用途、金額、相手先、規程、添付）を決め、チェックの型を作ることが重要です。

留意点③：経理の役割は“全件チェック”から“例外監督”へ
Expense Agentの思想は、経理が全件を手で直す世界ではなく、例外を拾って統制する世界です。導入時には、経理側の役割定義を変えないと、「結局経理が全部やる」に戻りがちです。

6. 想定利用シーン：社員数が増えるほど、確実に効いてくる

Expense Agentが効きやすいのは、例えば次のような状況です。

• 経費精算の件数が多く、月末に承認が詰まる
• 差し戻しが多く、申請者・承認者・経理の負担が増えている
• 営業やフィールド部隊が多く、証憑の取り回しが課題になっている
• 拠点が増え、経費ルールの統一と遵守が難しくなっている
• 監査・内部統制の観点で、証憑と申請の整合性を強化したい

経費精算は地味ですが、規模が大きくなるほど必ずボトルネックになります。だからこそ、ここにエージェントが入る意義は大きいです。

7. 導入チェックリスト（最初に決めるべき5項目）

Expense Agent導入の前に、最低限これだけは決めておくべき項目を自分がテストした内容に基づき纏めておきます。

• 証憑の入口はどれか（撮影・添付・転送など、現場の最短動線を優先する）
• 申請者が補うべき項目は何か（“全部入力”をやめ、必要最小限にする）
• 承認者が見るべき観点は何か（規程・用途・妥当性のチェックポイントを固定する）
• 経理が介入する条件は何か（例外条件を定義し、全件チェックから脱却する）
• まずどの部門・どの費目から始めるか（段階導入の第一段階を決める）

結論：Expense Agentは「申請を楽にする」だけでなく「統制を崩さずに速くする」

Expense Agentは、申請者の入力を減らすための機能に見えがちです。しかし本質は、経費精算を

• 証憑中心に戻し
• 判断点を明確にし
• 承認と統制を崩さず
• 例外に集中できるように組み替える

という、業務設計の変化にあります。経費精算は、会社が大きくなるほど確実に詰まる領域です。だからこそ、ここがエージェントで再設計され始めたことは、単なる効率化以上の意味を持ちます。

纏め｜3つのAgentに共通する「実装された前提の変化」

Sales Order・Payables・Expense

業務領域は異なりますが、3つのAgentには共通した構造があります。

入口は非構造であり、AIが下書きを作り、人が判断し、その過程が業務として残る。

メール、請求書、レシート。

これまで人が読み、整え、つないできた領域に、同じ骨格が入り始めています。

ただし、それは「自動化の延長」ではありません。

むしろ逆で、曖昧さや不足、例外があることを前提にしたまま、それでも業務として成立させる形に寄せてきている。

非構造をなくすのではなく、非構造のまま扱う。

この転換の中で起きているのは、機能の進化ではなく、前提の置き換えです。

AIが何をするのかではなく、人がどこに残るのか。

どこまでを任せ、どこで止めるのか。

その境界が、「なんとなく」ではなく、業務の中で定義され始めています。

ここまで書いてきて、少し既視感があります。

この数か月、ブログで整理してきたのは、

• どこに人を置くのか
• どこまでを自律に任せ、どこで止めるのか
• そして、判断・実行・ログ・責任をどう壊さずに組み込むのか

という、いわば「業務が壊れないための設計条件」でした。

Human-in-the-Loop、境界、SSOT、ログ、監査。

データが揃わなければAIは破綻するし、

境界が曖昧であれば組織も破綻する。

だからこそ、

• マスターデータを揃える
• CRMとERPを繋ぐ
• ノックフォワードを起こさない
• ログを残し、責任を追えるようにする

といった、かなり「地味な話」を繰り返してきたのだと思います。

そして今回見えてきたのは、それらが“前提として正しかった”ということではなく、それらを満たさないと、そもそもエージェントが業務に入れないという現実でした。

訪問先で繰り返し話題に上がっていた問いも、まさにそこにあります。

• どこまで業務をAIに任せるのか
• 人が関与すべき判断はどこに残るのか
• そして、それをどう組織として担保するのか

Business Central 2026 ｗave 1は、この問いに対して“機能”ではなく、“業務の形”で答え始めています。

そしておそらく、私たちはこれからも同じ問いを考え続けることになります。それは新しい問題ではなく、これまで暗黙に扱ってきた境界を、改めて設計し直す段階に入った、ということなのかもしれません。

追伸：本日山形県にて参戦してきました。

「プロのお仕事とは、こういうものだ」

この一言に尽きる、本当に素晴らしいライブでした。

以上、室長でした。