Excel×AI時代、見えない権限は統制できない

これは便利だ。

Microsoft が Excel の Copilot に「Skills」を追加した。DCF モデルの作成、四半期決算、月次レポート更新、予算対実績の差異分析。こうした財務・経理の繰り返し作業を、SKILL.md という手順書として定義し、Copilot に再現実行させられる。2026 年 6 月 25 日の公式ブログ "Copilot in Excel: Built for the era of Frontier Finance" で、finance skills、custom skills、そして OneDrive に SKILL.md を保存する仕組みが明記されている。

日本の経理にとって、これはかなり大きい。

なぜなら、日本の現場では Excel は単なる表計算ソフトではないからだ。実態としては、Excel が会計システムになっている会社が多い。

会計システムからデータを落とす。Excel で加工する。Excel でチェックする。Excel で差異を説明する。最後に、その結果を本来の会計システムに入力する。

極端に言えば、「Excel が実務上の会計システムで、それを正式な会計システムにコピーしている」と言っても過言ではない。

だから、Excel に AI の Skill が入る意味は大きい。毎月同じ形でレポートを更新する。勘定科目ごとの増減を説明する。予算と実績の差異を見つける。部署別・プロジェクト別に数字を並べ直す。これまで人が覚えていた手順を、Skill として残せる。属人化していた Excel 業務を、再現可能な手順にできる。

ここまでは、とても良い話だ。

OpenAI でも同じことができるのか

答えは「思想としてはできる。ただし、そのまま使えるわけではない」だ。

Microsoft Copilot in Excel の Skill は、Excel、OneDrive、Microsoft 365、Copilot が一体になっているから成立する。SKILL.md を置くと、Excel の Copilot がそれを読み、Excel 上の作業に使える。

一方、Azure OpenAI や OpenAI API で同じことをするなら、自分で設計しなければならない。手順書をどこに置くのか、いつ読み込むのか、どのデータにアクセスさせるのか、Excel・SAP・Power BI・DB とどう接続するのか、実行前に人間承認を入れるのか、結果をどこに記録するのか。ここを全部作る必要がある。

Claude や Codex でも Skill 的な仕組みは広がっている。AI に「毎回同じ業務手順を教える」のではなく、「手順そのものを部品化して、必要なときに AI が呼び出す」という流れは、今後の標準になっていく可能性が高い。

何が嬉しいのか ― SAP との組み合わせ

たとえば SAP から売掛金、買掛金、原価、WBS、プロジェクト、利益センターのデータをダウンロードする。Excel で加工する。差異を確認する。必要に応じて SAP に入力する。この一連の作業は、現場ではよくある。

しかし、実際にやると面倒なことが多い。

SAP からダウンロードした時点で、伝票のステータスが変わっているかもしれない。未消込だと思っていたものが、すでに消込済みになっているかもしれない。入力しようとした時点で、対象の WBS が閉じているかもしれない。一覧を落としただけでは判断できず、直前にリアルタイムで確認しないと危ないケースがある。

これは、使っていないとわからない不便だ。Excel 上で綺麗に集計できても、その数字が今も SAP 側で有効とは限らない。だから、AI が Excel を操作できるようになるだけでは足りない。設計が重要になる。

ダウンロードとアップロードを分ける

ダウンロードは比較的安全に見える。しかし、どのデータを取れるかは権限そのものだ。財務データ、人件費、利益率、取引先別の条件、プロジェクト別の採算。Excel に落とせるということは、AI が読めるということでもある。

さらに危ないのはアップロードだ。SAP に登録する。会計伝票を作る。原価率を変更する。WBS に紐づける。支払条件を変える。消込処理を走らせる。

ここまで AI に触らせるなら、Skill は単なる便利な手順書ではない。業務システムを動かす操作権限になる。Skill ひとつで業務を動かせてしまう。

本当に危ないのは「権限主体が見えなくなる」こと

人間が SAP にログインして操作するとき、操作主体は人だ。誰が、どの会社コードで、どの伝票を、どの範囲まで動かしたかが見える。見えるから、権限を分けられる。見えるから、承認できる。見えるから、監査できる。

Excel×AI になると、ここが変わる。

人は Excel を開き、Skill を走らせる。しかし、裏で SAP を叩くのは AI だ。このとき、AI がどの権限で入り、どの操作を実行したのかが、人から見えにくくなる。

問題は「共通アカウントにしてしまうこと」ではない。それは結果にすぎない。

本当の問題は、権限主体が見えなくなることだ。

誰が、どの Skill を使い、どのバージョンの手順で、どの権限として SAP に何を書いたのか。これが観測できないまま、AI 経由の操作だけが増えていく。

見えないものは統制できない。

そして、見えない権限は、結果としてひとつに均されていく。誰も「共通アカウントにしよう」と決めていなくても、利用者から見えない場所で、同じ権限、同じ経路、同じ実行主体に収斂していく。それが危ない。

そしてもう一つ。Skill は自然言語で書かれる。プログラムのように見えないから、レビューが甘くなる。だが実態は AI への操作指示だ。「この条件なら登録する」「エラーが出たら別の方法を試す」――こうした一文が業務ロジックそのものになる。出力は一見正常に見えても、相手勘定が一つすり替わっているだけで、誤った仕訳が静かに本番へ流れる。構文エラーは出ない。だから気づきにくい。

2026 年 5 月の論文 "Under the Hood of SKILL.md: Semantic Supply-chain Attacks on AI Agent Skill Registry"（Shoumik Saha, Kazem Faghih, Soheil Feizi）は、SKILL.md を単なる説明書ではなく、AI エージェントがどのスキルを発見し、選び、信頼し、読み込むかに影響する operational text だと指摘している。手順書は、もはや受動的なドキュメントではない。

守りの第一歩は「可視化」

だから守りの第一歩は、AI を止めることではない。権限を分けることですら、まだ一歩目ではない。

まず、権限主体を可視化することだ。

どのユーザーが、どの Skill を、どのバージョンで実行したのか。その Skill は、どのデータを読み、どの API を呼び、SAP に何を書いたのか。SAP 側には、誰の権限として記録されたのか。人間の承認は、どの時点で入ったのか。

少なくとも、次は残さなければならない。

可視化が先。統制はその後だ。見えなければ、権限を分けることもできない。見えなければ、承認も監査もできない。見えなければ、事故が起きたあとに原因を追えない。

主戦場はサーバから移る

これまでのセキュリティは、サーバ、会計システム、DB、API の側で考えていた。これからは、そこに Excel、OneDrive、Skill、Copilot、AI エージェントが加わる。守る場所が増える。権限の入口が増える。操作の主体が曖昧になる。

そして、権限主体の統制をいちばん厳格にやってきたのが SAP の世界だ。会社コード、伝票タイプ、ロール、承認、変更履歴でガチガチに縛る。そこに Excel×AI が横から入ると、画面上は便利でも、裏側で「誰が操作したのか」ではなく「AI が処理した」になりかねない。

Excel に AI が入る。Skill で業務手順を覚えさせられる。これは間違いなく便利だ。だが本当に重要なのは「便利になった」ではない。Excel が AI の実行環境になり、Skill が業務手順になり、その Skill が会計システムや SAP への入口になることだ。

AI が、誰の権限で動いているのか。そこを見えるようにしない限り、業務 AI は統制できない。

---

参考：Microsoft, "Copilot in Excel: Built for the era of Frontier Finance"（2026/6/25）／ S. Saha, K. Faghih, S. Feizi, "Under the Hood of SKILL.md: Semantic Supply-chain Attacks on AI Agent Skill Registry"（2026/5/12）。なお大規模実証として "Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale"（2026/1）は、収集した skills の分析で約 4 分の 1 に脆弱性を確認したと報告している。