はじめに

🟢 ずんだもん:
「きりたん、聞いてほしいのだ。ぼく、気づいてしまったのだ。」

🔴 きりたん:
「どうしたの、改まって。」

🟢 ずんだもん:
「この前、社内向けの業務フロー自動化システムを Azure Static Web Apps（SWA）+ Azure Functions + Microsoft Graph で作ったのだ（中身の詳細は今日は伏せるのだ）。作ってる最中は無我夢中だったのだけど、完成してしばらく運用してたら、じわじわ変な汗が出てきたのだ。

やばい。この構成、うちの定型業務ぜんぶ巻き取れるのでは？

って。」

🔴 きりたん:
「ふうん。で、たぶん続きがあるんでしょ。」

🟢 ずんだもん:
「うちだけじゃないのだ。SharePoint に Office ファイルを置いて管理して、Exchange Online でメールを送受信してる会社──つまり日本の大多数の企業──の定型業務は、理論上ぜんぶこれで巻き取れるのでは……？と思ってるのだ。ところどころ極論チックな断言をするけど、今日はそこは味として聞いてほしいのだ。」

🔴 きりたん:
「いいわよ。その『やばさ』の正体を、構成・費用・セキュリティ・落とし穴込みで検分していきましょ。」

この記事で紹介するもの

何が「やばい」のか（Graph + az が繋がった瞬間の破壊力）
設計概要（Entra ID という土台・最小ライセンス・人間のクラスチェンジ）
Excel 業務がサーバーサイドに引っ越す話（個人的ハイライト）
技術スタックと費用
セキュリティ（Easy Auth + Linked Backends + 条件付きアクセスで9割完成）
コツ2つ（サードパーティ SaaS を混ぜない／全部サーバーレス）
注意点（GUI 版 Windows Server から逃げられない領域）
運用の小ネタ（Durable Functions／Table Storage 台帳／仕様変更への耐性）

1. 何が「やばい」のか──Graph と az が繋がった瞬間

🟢 ずんだもん:
「この構成の何がやばいかというと、Functions のバックエンドから Microsoft Graph API と az コマンド（Azure CLI / ARM REST）の両方を叩けることなのだ。これはつまり──

Microsoft 系の業務は、ほぼ全て自動化できるポテンシャルがある

ってことなのだ。口だけだと胡散臭いから、具体例を出すのだ。多くの企業がやってるこの2つ。

📁 SharePoint に Office ファイルを置いて管理する
📧 Exchange Online でメールを送受信する

これ、どっちも API 側の入り口が完備されてるのだ。

やりたいこと	使う道具	補足
SharePoint のファイル・リスト・サイト操作	PnP PowerShell / Graph API（drive, site）	PnP は内部的に Graph / SharePoint REST を叩く定番モジュール
Exchange Online のメール送受信・メールボックス管理	ExchangeOnlineManagement モジュール / Graph API（sendMail 等）	EXO モジュールはマネージド ID 接続（`Connect-ExchangeOnline -ManagedIdentity`）にも対応
Entra ID のユーザー・グループ・ライセンス管理	Graph API	ユーザー棚卸し・入退社処理が全部コードになる
Azure リソースの操作	az CLI / ARM REST / Azure SDK	VM の起動停止からリソース払い出しまで

図にするとこうなのだ。

つまり、自動化の「お膳立て」は、全て Microsoft がすでにしてくれているのだ。API はある。認証基盤もある。SDK もモジュールもある。ドキュメントもある。あとは繋ぐだけなのだ。」

🔴 きりたん:
「そこまでお膳立てが済んでるなら、なんで世の中の業務は自動化されてないのかしらね。」

🟢 ずんだもん:
「これらを自動化のために組み上げる知見やスキルが、市場で希少だからなのだ。キッチンに食材がずらっと並んでるのに、誰も調理ロボットの設計ができず全員手作業で料理している状態なのだ。極論チックだけど、これが2026年現在の日本の業務フローの実情だと思ってるのだ。」

🔴 きりたん:
「例えはともかく、実情の方は否定しきれないわ。」

2. 設計概要──Entra ID があるなら、もう土台はできている

2-1. 前提：あなたの会社はもう Entra ID にいる

🔴 きりたん:
「ここは私から。さっき挙げたような Microsoft インフラ系に頼ってる企業は、すでに Entra ID に移行してるはずなの。M365 を使ってる時点で、全社員のアイデンティティは Entra ID にある。

そして Entra ID は IdP（アイデンティティプロバイダー）として最強クラスよ。条件付きアクセス、MFA、デバイス管理連携──エンタープライズ認証に必要なものが一通り揃ってる。今日の話で大事なのは、それをそのまま自作 Web システムに SSO させられること。ログイン画面を作る必要すらないの。」

2-2. 必要なライセンスは最小でこれだけ

契約	役割
Entra ID P1	条件付きアクセス（後述のセキュリティの要）
Microsoft 365 Business Basic	SharePoint / Exchange Online / Teams 等のワークロード
Azure テナント（サブスクリプション）	SWA / Functions / ストレージ等の実行基盤

🔴 きりたん:
「最低限この3点があれば、理論上は定型業務の全てを自動化できる、というのが今日の見立てね。」

Business 系プランは 300 ユーザーまでです。それ以上の規模の会社は E3/E5 系プランに読み替えてください。話の骨格は変わりません。

2-3. 人間は「労働者」から「判断者」へクラスチェンジする

🟢 ずんだもん:
「定型業務が自動化されると何が起きるか。都度判断しなければいけない非定型業務に、人間の判断力を集中できるようになるのだ。

判断の要らない作業は機械に流れて、人間には判断だけが残る。つまりこのアーキテクチャは、人間を労働者から「判断者」にクラスチェンジさせるものなのだ。」

＊「LvUpですぜ　あんたも　せいちょうしたもんだ」

🟢 ずんだもん:
「そして、このクラスチェンジが一番はっきり見える現場が、みんな大好き Excel とメールなのだ。」

3. M365 アプリとの連携──Excel 業務がサーバーサイドに引っ越す日

🟢 ずんだもん:
「前の章で言ったとおり、PnP PowerShell や ExchangeOnlineManagement（EXO）、Power BI といったアプリ系も全て API が用意されてるから、SWA の GUI からデータを呼び出して操作できるのだ。イメージはこんな画面なのだ。

ここで思い出してほしいのが、従来の Excel 業務の姿なのだ。これまで Excel などのデータ処理は、デスクトップアプリ上で VBA マクロや Power Query、あるいはサードパーティ RPA などを使って、各エンドポイント──つまり各社員の PC──で処理することを強いられることが多かったのだ。

マクロが動かない PC が必ず出る（Office のバージョン差・セキュリティ設定差）
RPA のシナリオが画面変更で黙って壊れる
属人化した『あの人の Excel』が業務のクリティカルパスになる
全部の問い合わせが情シスに落ちてくる

サポート負担が大きくて、重いのだ。情シス経験者なら胃のあたりが痛くなってきたはずなのだ。」

🔴 きりたん:
「痛くなってきたから先に進めましょ。それが今回の構成だと、処理は全部 Functions（サーバーサイド）に集約されて、社員の手元に残るのはブラウザだけになる。

（AI の力を借りて）これら全てをサーバーサイドに移行できるっていうのは、長年社内インフラを見てきた身としては、正直産業革命レベルだと思ってるわ。蒸気機関の登場で家内制手工業が工場に集約されたのと同じ絵が、Excel マクロと RPA の世界で起きようとしてるの。」

🟢 ずんだもん:
「夢の話はここまでにして、ここからはこの絵を支える足元──スタック・費用・セキュリティ──を順に見ていくのだ。」

4. 技術スタックと費用

4-1. スタック全景

🟢 ずんだもん:
「ぼくのシステムの全体像はこうなのだ。

レイヤ	採用	ひとこと
フロントエンド	Azure Static Web Apps（Standard プラン）	Standard なのは Easy Auth のカスタム認証と Linked Backends を使うため
バックエンド	Azure Functions	従量課金で寝てる間はタダ同然
ID	User Assigned Managed Identity（UAMI）	シークレットレスで Graph / Azure を叩く。漏れるキーがそもそも無い
API	Microsoft Graph、az CLI（ARM REST / Azure SDK）	ここが本丸
シークレット管理	Key Vault	UAMI で取りに行く。証明書やサードパーティ API キーの置き場
データ	Table Storage + Blob	後述。小規模ならこれで十分
監視	Application Insights	Functions と統合。失敗した自動化はここで気づく
CI/CD	GitHub Actions（社内完結したい場合：小さな Azure VM（Linux）+ Gitea）	SWA はリポジトリ連携で勝手にビルド・デプロイ。コードを社外に置けない事情があるなら Gitea で社内完結も可（Gitea Actions は GitHub Actions 互換）
上記でカバーできない領域	Azure VM + Server Core + Windows Admin Center + サービスプリンシパル	GUI 必須アプリ・オンプレ由来ワークロード用。注意点の章で後述
」

4-2. 費用感

🔴 きりたん:
「お金の話は私がまとめるね。Azure 側のランニングは驚くほど安く収まるの。2026年7月時点の目安で、為替・リージョンで変動するから、正確には公式料金表を見てね。

項目	月額目安
SWA Standard	約 $9/アプリ（1,400円前後）
Functions（従量課金）	無料枠（月100万実行）内に収まることが多い
Table Storage / Blob	数十円〜数百円
Key Vault	数十円（操作数課金）
Application Insights	小規模なら微額
（必要な場合のみ）VM B2s 級 + Server Core	数千円

ライセンス側（Entra ID P1 + M365 Business Basic）は1ユーザーあたり合計で月2,000円弱程度が目安。ただこれは自動化のためというより、既に払ってる会社が多いはずよ。つまり追加コストは実質 Azure 側の数千円だけ、ということも珍しくないの。稟議のハードルが低いのは正義ね。」

5. セキュリティ──Easy Auth + Linked Backends + 条件付きアクセスで9割完成

🔴 きりたん:
「Web アプリを作る上で一番厄介なのが、セキュリティ。URL を世界に発行するというのは、世界中からアクセスが行われるということよ。社内向けのつもりでも、インターネットに置いた瞬間からスキャンボットは平等にやってくるわ。」

🟢 ずんだもん:
「ここで効くのが SWA の Easy Auth なのだ。仕様の細かい罠は前に書いたこの記事にまとめてあるのだ。

守りは3段構えなのだ。

Easy Auth で、SWA フロントエンドに「同一テナントの Entra ID 認証」を必須化する。
未認証のアクセスはアプリに到達する前に認証ページへ飛ばされるのだ。この時点で『世界中の誰でも見られる URL』は『うちのテナントのアカウントを持つ人しか入れない URL』に変わって、セキュリティは既にかなり高いのだ。
バックエンドの Functions は Linked Backends で繋ぐ。
SWA が /api 経由で Functions にプロキシしてくれるから、Functions を直接公開せずに済んで、CORS 対策なども別途不要なのだ。認証済みユーザー情報もそのままバックエンドに流れてくるのだ。
条件付きアクセス（CA）で「特定デバイスからのみ」に絞る。
Entra ID P1 の出番なのだ。Entra 参加済みの会社デバイスのみ許可、といったポリシーを掛ければ、仮に資格情報が漏れても会社支給端末以外からは入れないのだ（Intune まで導入済みなら『準拠デバイスのみ』条件も使えるのだ）。

ここまでやれば、社内 Web アプリとしてのセキュリティ対策は9割完成してしまうのだ。」

🔴 きりたん:
「自前でセッション管理やログイン画面を書いた瞬間に発生する、無数の考慮事項がまるごと消える。『認証コードを1行も書いてないのに固い』っていうのが、この構成の気持ちよさね。」

6. コツ①：よくわからないサードパーティ SaaS を入れない

🟢 ずんだもん:
「このアーキテクチャを活かす上で重要なのが、Microsoft 以外のよくわからんサードパーティのサービスをごちゃごちゃ入れないことなのだ。例えば──

📮 メールの送信前チェック SaaS
🌳 組織図 SaaS

こういうのをサードパーティのアドオン的に許可して入れたりすると、地獄を見るのだ。」

🔴 きりたん:
「『SaaS の死』なんて言うつもりはないの。ただ、こういうものの多くは究極的には今回のアーキテクチャで自分たちで作れてしまうのよ。送信前チェックは Graph のメールフローに数十行のロジックを挟めば済むかもしれないし、組織図は Entra ID にマスターデータが既にある。」

🟢 ずんだもん:
「そして、これがそれを伝えたい図なのだ。

API を公開している会社なら検討の価値はある。しかし、API すらないブラックボックスのような SaaS を「単発の目的で」入れるのだけはおすすめしない。

🟢 ずんだもん:
「そういう SaaS を一つ入れるだけで、今回のアーキテクチャは崩壊する危険があるのだ。自動化パイプラインの真ん中に『人間が GUI をポチポチしないとデータが出てこない箱』が挟まるからなのだ。このあたりの力学は、前にこの記事でも書いたのだ。

まとめると、今日の記事の趣旨はこうなのだ。

SWA + Functions の構成は、理論上すべての Microsoft 系業務インフラを内包できて、さらに AI の力を借りれば、サードパーティ拡張 SaaS が担っていた部分でさえ内製できてしまうポテンシャルがある。」

7. コツ②：全てをサーバーレス構成にすべき

🟢 ずんだもん:
「もう一つのコツは単純で、全てをサーバーレスにすべきなのだ。

Windows Server を立てると、毎月の Windows Update──更新の確認、再起動の段取り、たまに来る更新失敗の対応──がもれなくついてくるのだ。どれも事業を前に進める仕事じゃなくて、サーバーを持っていること自体の維持作業なのだ。

SWA と Functions にはパッチ当ての概念がないのだ。この差は運用年数が経つほど効いてくるのだ。」

8. 注意点：一部は GUI 版 Windows Server から逃げられない

🟢 ずんだもん:
「正直な話もしておくのだ。スタックの章で『カバーできないやつは Azure VM + Server Core』と書いたのだけど、一部は GUI 版の Windows Server でしか操作できないものがあるのだ。代表例はこの2つ。

🔗 Entra Connect（オンプレ AD とのディレクトリ同期）
🌐 Global Secure Access のコネクタ類

こういう GUI 前提のアプリは、旧来どおり RDP で管理しないといけなくて、無意味な工数が増えるのだ。Microsoft 自身が『GUI 使ってね』という前提で作ってるものだから、ここは不可避なのだ。

ただし救いはあって、数はそれほど多くないのだ。

大半のサーバー役割は Server Core + Run Command（az vm run-command invoke）で、RDP を開かずに VM を直接操作できるのだ。Active Directory ですらこれで RDP レス管理、モダンな Web 管理にすることが理論上可能なのだ。AD 管理コマンドレットを Run Command 越しに流して、日常運用は Windows Admin Center のブラウザ画面で見る、という形なのだ。」

🔴 きりたん:
「『GUI 必須の少数派だけ隔離して RDP、それ以外は全部コード』。島は小さく、大陸は広く、が落としどころね。」

9. 運用の小ネタ集

9-1. バッチ処理は Durable Functions

🟢 ずんだもん:
「長時間かかる処理・多段の承認フロー・リトライ制御には Durable Functions が用意されてるのだ。実行状態を GUI で見られるようにしておく（Durable Functions Monitor など）と、運用者が『今どこまで進んでるの？』をブラウザで確認できていい感じなのだ。

リトライや多段の待ち合わせを自分で書かずに済むのは、内製アプリの保守性に直結するのだ。」

9-2. DB は Table Storage + Blob で意外と足りる

🔴 きりたん:
「DB は業務内容次第で本当にピンキリだけど、100名以下のユーザーなら Table Storage + Blob（クール/コールド層へのバックアップ）で十分なことが多いわ。

ストレージの従量課金は月数十円レベルから、Functions 側には毎月の無料枠もあるから、コスパは抜群。RDB が本当に必要になったときに初めて SQL Database なりを検討すればいいの。台帳を毎晩 Blob に凍らせておいて、壊れたらそこから戻す。素朴だけど、この規模ならこれで戦えるわ。」

9-3. 避けられないのは Microsoft の仕様変更──ただし

🟢 ずんだもん:
「サーバーレスにしたとしても避けられないのが、Microsoft 自身の仕様変更なのだ。API の廃止予告、認証方式の移行、モジュールの世代交代──M365 界隈に住む以上、これだけは付き合い続けるしかないのだ。」

🔴 きりたん:
「とはいえ現時点では、SWA + Functions は Azure の中でもインフラ中のインフラで、Azure 内の SaaS 的なサービス群と違って、突然大幅に機能変更されることは考えにくい立ち位置よ。

それにサーバーレスだから、基盤側はこちらがインフラを意識しないままローリングリリースされて、バージョンアップへの移行コストも（ランタイム指定の更新程度で）ほぼゼロ。強いて言えば、フロントを React や Astro で構築する場合に、それらのメジャーバージョンアップ対応が定期的に必要になるくらいね。」

まとめ〜「うちの業務も巻き取れるのでは？」

🔴 きりたん:
「今日の話を整理するとこうね。

🧩 お膳立ては全部済んでいる。 Graph・az・PnP・EXO──Microsoft 系業務の自動化 API は既に完備されている。足りないのは組み上げる知見だけ。
🏗️ 土台は既に持っている。 M365 を使う会社は Entra ID という最強クラスの IdP を既に運用しており、Entra ID P1 + M365 Business Basic + Azure テナントがあれば理論上、定型業務は全て自動化できる。
🔐 セキュリティは Easy Auth + Linked Backends + 条件付きアクセスで9割完成。
💡 ブラックボックス SaaS を混ぜない。全部サーバーレスにする。 この2つを守るだけでアーキテクチャの寿命が大きく延びる。
🧑‍⚖️ 人間は労働者から「判断者」へ。 定型は機械へ、判断は人間へ。

」

🟢 ずんだもん:
「『やばい、うちの業務も巻き取れるのでは？』と思ったそこのあなた──たぶん、巻き取れるのだ。そしてこの記事を読んで『わけわからん』ではなくそう思ったのであれば、」

＊「LvUpですぜ　あんたも　せいちょうしたもんだ」

🔴 きりたん:
「言いたいだけやんｗ」

上島珈琲にて

🟢 ずんだもん:
「それにしても、自分で作っておいて自分で戦慄したのは初めてだったのだ。Functions と Graph が繋がった瞬間、目の前に巨大な自動化の平野が広がった感じだったのだ。」

🔴 きりたん:
「その平野、お膳立ては済んでるのに、まだほとんど誰も耕してないのよね。」

🟢 ずんだもん:
「だから今日は『こんな平野があるのだ！』っていう地図を配った回なのだ。」

🔴 きりたん:
「MSはすでに素晴らしいものを用意してくれてるわよ、ってことね。」

🟢 ずんだもん:
「今日は地図を配った特別な日だから、フラペチーノにケーキも追加するのだ！🍰」

🔴 きりたん:
「はい、台帳に記録。今月の『特別な日』、これで17回目ね。毎晩 Blob にスナップショット取ってあるから。」

🟢 ずんだもん:
「じゅ...17...その台帳、消してほしいのだ！！😳」

🔴 きりたん:
「残念、コールド層に凍結済み。取り出しには時間がかかるけど、証拠は絶対に消えないわよ。サーバーレスだからねｗ」

🟢 ずんだもん:
「バックアップ設計が優秀すぎて泣けるのだ……。😭」

利用キャラクター

ずんだもん：VOICEVOX:ずんだもん
東北きりたん：VOICEVOX:東北きりたん

本記事で使用しているキャラクター画像の著作権は、それぞれの権利者に帰属します。
非商用目的での利用に基づき掲載しています。

リンク