先日、Salesforceが”Headless 360”を導入したというニュースを目にしました。ユーザーがブラウザで伝票登録しなくなる日がいつか来るのでしょうか。ゼロにはならないと思いますし、すぐでもないと思いますが、確実に減っていくのだと思います。2年前にAI Tour Tokyoに参加した時、「生成AIはUIの革命だ」と思ったのですが、こんなに早くUIの価値が減るとは思いませんでした。
ということで、”Headless SaaS”という時代の流れに乗るためにBusiness CentralのMCPサーバーを使って受注伝票の登録にトライします。前々回、前回立てたMCPサーバーはRead Only権限しか付与していなかったので伝票登録はできない仕組みになっていました。今回は更新権限を付与して受注登録用のMCPサーバーを新規作成します。作り方の手順は前々回と変わらないので、設定のポイントだけ説明します。
こちらが受注登録用に新規作成したMCPサーバーです。Available Toolsに”APIV2 – Sales Orders”と”APIV2 – Sales Order Lines”が追加されています。前者が受注のヘッダーで後者が明細です。右側のチェックボックスを見てほしいのですが、”Allow Create”、”Allow Modigy”がOnになっています。また、ヘッダー部の右下”Unblock Edit Tools”がOnになっています。
MCPサーバーを新規登録したらエージェントも新規登録します。
先ほど新規作成したMCPサーバーをAgentに紐づけます。
Teamsから受注を登録してみます。どうせできることはわかっているので、”実用に耐えるか？”の観点で業務や営業さんの実際の行動を想定して、わざとあいまいな点を残して登録してみます。例えば得意先名は”Alpine Ski House”ではなく”Alpine Ski”と表現し、Agentが理解できるか試しています。また、「前に頼んだアレが欲しいんだけど」という問いかけにして品番や品名を指定せずに問いかけています。「前に注文いただいた品目を調べる」はまじめにやれば絶対にわかるけど、手が取られて時間を食う地味に面倒くさい作業です。が、、Agentに聞くと過去伝票を参照して一発で候補を挙げてくれます。しかも利用可能在庫までつけてくれて親切です。品目を特定して”明後日が納期”というこれまた若干あいまいな表現で受注伝票登録を依頼しました。結果、何ともアッサリと受注伝票が登録できました。
あっさりと出来すぎて心配になったのでBusiness Centralを直接見に行きました。確かに登録されていました。（素晴らしい！もう今回のブログに書くことがなくなってしまった？！）
いや、新規登録ができたら次は変更ですよね、ということで顧客からの追加注文を受注伝票に追加するよう依頼してみました。が、、、結果はよろしくありません。更新の競合を回避するために”If-Machを教えろ”と言ってくるのは営業さんには絶対理解してもらえないし、システム屋的にもブラウザで二人同時に入力するときもあるでしょ…と思うところです。「”if-match”とか分からん！」で押し通そうとしましたが駄目でした。しまいにはAgentが回答を諦めて、人間様にエスカレーションしようとした挙句にエスカレーション先が設定されていない、と行き詰りました。（この辺はAgentの設計で何とかなるはずで、自分がちゃんと設計していないだけです。）
何度聞いても埒が明かないのですが、試しに変更点を段階的にわけて一つずつ依頼してみるとうまく処理してくれました。
ということで割とあっさりと受注伝票登録も変更もできてしまいました。すごい時代になりました。自分のブログでBCの記事なのにBCの画面がこんなに少ない投稿は珍しいです（笑）
余談ですが、、10年ほど前にNAVを導入していた際、「SAPもそうだけど、洋モノERPってボタンがやたらと多いでしょ。和製パッケージとかスクラッチシステム使ってた人は、まずそこで拒否反応がでるんだよね。どのボタン押したらいいの？？ってなる。」というような話をされたことを思い出しました。その当時は、入力担当者のロールごとに不要なボタンを非表示にするくらいしか解決策が思いつかなかったのですが、そもそも画面見なくて済むようになる時代が来るとは思わなかったです。
”Headless ERP”という単語を初めて聞いたのは半年前で、その時は正直ピンとこなかったのですが、ああなるほどコレか…と実感を持って理解できました。まあ、Amazonでしたっけ、すべての機能にAPIでアクセスできるようにしていた、というような話を聞くと、見える人には見えていた未来なのかもしれません。
そしてHeadless化が浸透すると、ユーザー単位ライセンスの課金モデルの見直しが進むでしょう。もともとユーザー単位ライセンス課金モデルというのは買う側が予算コントロールしやすいのと、ベンダーが請求しやすいという妥協点で成立していたモデルだと思っているので、理屈で考えれば何らかの実績ベース従量請求モデルになっていくのだろうと思います。それがトランザクション数なのか、CPU負荷なのか、電力消費量なのかはわかりませんが。（システム基本料金＋ユーザー単位ライセンス＋実績ベース従量請求のハイブリッドかな。その割合が各社の戦略になると予想。）
Headlessやライセンスの話はさておき、MCPサーバーでBCの更新がいろいろとできそうで楽しいです。皆さんも試してみてください。