AIと一緒にMicrosoftの道具箱をひっくり返してみた
――会員サイトを作ろうとして見えてきた、つながる仕組み
会員サイトの設計を先に考え、その実現に必要なMicrosoftの道具を一つずつ探してつないでいきました。
この記事の要点
Digital Supporters Clubの会員サイトを作るために、
まず設計書を書き、その設計を実現する道具をMicrosoftの製品群から探していきました。
そこで分かったのは、Microsoft 365にはたくさんの機能が揃っているだけではなく、
管理者側で認証や権限の仕組みを理解すると、それぞれをつなげて一つのサービスとして使える
ということでした。
そして今は、分からないことを一緒に調べ、設計し、試してくれる
ChatGPTやClaudeのような「技術に詳しい同僚AI」がいます。
プログラマーとして仕事をしてきたわけではない私でも、
AIと一緒に確認しながら、実際に仕組みをつないで動かすところまで体験できました。
この記事を貫く４つのポイント
- 最初に作ったのは、Microsoftの勉強計画ではなく会員サイトの設計書
- Microsoftの強さは「道具が多い」だけでなく「道具同士がつながる」こと
- 管理者側を理解すると、認証・権限・監査まで含めて一つの仕組みにできる
- AIと一緒なら、知らない技術も調べ、確認し、試しながら理解できる
１．最初に作ったのは、会員サイトの設計書だった
Digital Supporters Clubでは、
「AIと、一緒に。書いてみたいことを、形にしよう。」
という考え方で、小説、エッセイ、自分史、思い出、体験などを書いてみたい人が、
少しずつ自分の言葉を形にしていける場所を作ろうとしています。
今回の出発点は、
Microsoft 365を勉強することではありませんでした。
最初に考えたのは、
どんな会員サイトにしたいのか
ということです。
会員には、自分だけの原稿を書く場所がある。
書いたものを保存して、続きを書ける。
完成した作品は、ほかの会員に公開できる。
ほかの会員は作品を読めるけれど、
勝手に編集することはできない。
読んだ人は感想を残せる。
作品を取り下げても、元の原稿は残す。
届いた感想も大切に残す。
こうしたことを一つずつ設計書に書いていきました。
会員サイトの中心となる体験は、
書く
↓
保存する
↓
続きを書く
↓
公開する
↓
感想が届く
↓
また書く
という流れです。
つまり、
製品から考えたわけではありません。
先に「こうしたい」という設計があり、
そのあとで必要な道具を探した。
この順番でした。
設計ができたところで、
「さて、これを実現するには何を使えばいいのだろう」
と、Microsoftの道具箱をひっくり返してみました。
２．中心に置いたのはSharePointだった
最初に中心になったのはSharePointでした。
以前の私にとってSharePointは、
どちらかというと、
会社でファイルを共有する場所
という印象でした。
ところが、自分で管理者側から触ってみると、
ずいぶん違って見えました。
文書を保存できる。
フォルダを作れる。
履歴も残せる。
そして、
誰に見せるのか、
誰に編集させるのかを細かく決めることができます。
そこでDigital Supporters Clubでは、
SharePointの中に、
自分の作品を書く
本人専用
みんなの作品
会員向け公開
という二つの場所を分けて作ることにしました。
本人専用の場所は、
本人と管理者だけがアクセスできます。
公開側では、
作者は自分の作品を編集できる。
ほかの会員は読むことはできるけれど、
編集することはできない。
つまりSharePointを単なるファイル置き場としてではなく、
会員サイトの情報と権限の中心
として使うことにしました。
ここまで来ると、
次の疑問が出てきます。
入会申込はどうするのか。
会員をどう識別するのか。
承認はどうするのか。
感想はどこで受け取るのか。
管理作業が増えたらどうするのか。
そこで、Microsoftの道具箱をさらにひっくり返していきました。
３．道具箱から、これだけのものが出てきた
今回の会員サイトづくりで登場した主なMicrosoftのサービスを並べてみます。
自分でも、こうして一覧にすると驚きます。
| 製品・機能 |
今回の役割 |
| SharePoint Online |
会員サイトの中心。原稿、公開作品、アクセス権を管理する |
| Microsoft Teams |
お知らせや、作品への感想をやり取りする |
| Microsoft Forms |
入会申込を受け付ける |
| Power Automate |
Forms、承認、通知などの処理をつなぐ |
| Approvals |
管理者が入会を承認・却下する |
| Microsoft Entra ID |
会員やアプリの「身元」と「できること」を管理する |
| Microsoft Graph |
Microsoft 365の情報をプログラムから扱うための窓口 |
| SharePoint REST API |
SharePointをプログラムから操作するための窓口 |
| Microsoft Purview Audit |
Microsoft 365上で行われた操作の記録を確認する |
| Azure Functions |
DSC Builderのプログラムを動かす |
| Azure Key Vault |
証明書やAPIキーなどの秘密情報を保管する |
| Managed Identity |
Azureのサービス同士を、パスワードを直接渡さず認証する仕組み |
| Application Insights |
プログラムの実行結果やエラーを確認する |
| Sites.Selected |
アプリが操作できるSharePointサイトを限定する仕組み |
もちろん、
これらすべてがMicrosoft 365 Business Basicの料金だけに含まれているわけではありません。
Azure FunctionsやKey Vaultなど、
Azure側のサービスは別途従量課金です。
Purviewについても、
利用できる機能やログの保持期間などはライセンスによって異なります。
それでも、
会員サイトの中心となるSharePoint、Teams、Formsなどを、
比較的低価格なMicrosoft 365のプランから使い始めることができます。
2026年8月現在、
Teamsを含むMicrosoft 365 Business Basicは、
Microsoft公式サイトで年間契約の場合、
1ユーザーあたり月額1,049円相当、税別
と案内されています。
最近は、お昼を食べても1,000円を超えることが珍しくありません。
ランチ1回ほどの金額で、
これほど大きな道具箱を毎月使える。
これは、あらためて考えるとかなりすごいことだと思います。
Microsoft公式「Microsoft 365 Business Basic」
４．本当に驚いたのは「道具の数」ではなく「つながること」
ただ、今回いちばん驚いたのは、
Microsoftに製品がたくさんあることではありませんでした。
それらを、つなげて使えることです。
Digital Supporters Clubでは、
たとえばこんな流れになります。
Microsoft Forms
入会申込
↓
Power Automate / Approvals
管理者による承認
↓
Microsoft Entra ID
会員を識別
↓
SharePoint
書く・保存する・公開する
↓
Teams
感想を受け取る
↓
Azure Functions
管理作業を支援する
↓
Key Vault
秘密情報を守る
↓
Application Insights
処理結果を確認する
↓
Microsoft Purview Audit
利用の記録を見る
Purviewでは、
Microsoft 365上で行われた操作の記録を確認できます。
Digital Supporters Clubでは将来的に、
SharePointのページを見た、
ファイルを開いた、といった記録から、
「この会員が最後にDigital Supporters Clubを利用したのはいつか」
を確認することまで設計しています。
現在の試作では、
まずSharePointの読み取りと新規会員セットアップまでを作っています。
Purviewとの自動連携は、
その試作を評価してからの次の段階です。
それでも、
入会する
↓
本人を識別する
↓
書く
↓
保存する
↓
公開する
↓
感想を受け取る
↓
管理する
↓
何が起きたかを記録する
ここまでをMicrosoftのサービスで一本につなげられる。
これが、
道具箱をひっくり返してみて一番驚いたことでした。
５．管理者側に立って、初めて「つなげ方」が見えた
そして今回、
もう一つ大きな発見がありました。
それが、
Microsoft 365を管理者側から見たこと
です。
大きな組織や行政でMicrosoft 365を使っていると、
管理者の仕事は情報システム部門やベンダーが担当することが多いと思います。
一般の利用者には、
必要な機能だけが提供されます。
Teamsはこちら。
SharePointはこちら。
このフォルダを使ってください。
それは、安全に運用するためには当然のことです。
ただ、それだけを使っていると、
Microsoft 365という仕組みが、本来どこまでできるのか
は、なかなか見えてきません。
私自身もそうでした。
今回、自分で管理者側に入り、
- 外部の人をどう参加させるのか
- 誰にどの権限を与えるのか
- アプリからSharePointへどう接続するのか
- アプリにはどこまで操作を許すのか
- 何が行われたかをどこで監査するのか
と、一つずつ見ていきました。
そこで初めて分かったことがあります。
サービス同士をつなぐには、
機能を知っているだけでは足りない。
認証と権限を理解する必要がある。
FormsとPower Automateをつなぐ。
Entra IDとSharePointをつなぐ。
Azure FunctionsとMicrosoft 365をつなぐ。
Purviewで、その利用記録を見る。
こうした接続には必ず、
- 誰が接続しているのか
- 何をすることが許されているのか
- どこまでアクセスしてよいのか
という問題が出てきます。
ここを理解できるようになったことで、
Microsoftの各製品が、
ばらばらのアプリではなく、
一つのシステムを作るための部品
として見えるようになりました。
そして管理者権限についても、
印象が変わりました。
管理者権限は、
何でもできるようにするための権限ではありません。
必要な人に、必要な範囲だけ権限を与えるために使う。
今回のDSC Builderでも、
Microsoft 365全体を自由に操作できるようにはしていません。
Digital Supporters ClubのSharePointサイトだけに、
操作できる範囲を限定しました。
管理者側を知ることで、
「何ができるか」だけではなく、
「どこまでできるようにするか」を設計できる。
そして、それがサービス同士を安全につなぐことにつながります。
６．APIも、実際につないでみて分かった
サービス同士をつないでいく中で、
これまで少し遠い言葉だった「API」の意味も、
だんだん実感として分かるようになりました。
APIとは簡単に言えば、
プログラム同士が情報をやり取りするための窓口
です。
普段Webサービスを使っていると、
私たちが見るのは表側です。
ブラウザを開く。
ボタンを押す。
入力する。
保存する。
その裏側で、
プログラム同士がどう話しているのかを見る必要はありません。
今回、自分でDSC Builderを作って、
初めてAPIが実感として分かりました。
私がAIに、
「この会員のSharePointフォルダを準備して」
と頼む。
AIが専用APIへ依頼する。
Azure Functionsで動いているプログラムが、
SharePointのAPIへ依頼する。
SharePointが処理する。
そして結果が戻ってくる。
そこで、
「ああ、APIというのは、プログラム同士が話をするための窓口なんだ」
と腑に落ちました。
教科書で定義を読むより、
自分でつないで動かしてみる方がずっと分かりやすかったのです。
Azureについても同じでした。
プログラムを動かす
Azure Functions
秘密情報を守る
Key Vault
実行状況を見る
Application Insights
というように、
必要な機能をサービス単位で組み合わせました。
Azureを使っているのに、
あまり「サーバーを作っている」という感覚がありません。
これも実際に触ってみて初めて分かったことでした。
７．AIは、技術に詳しい同僚のようだった
ここまでできた背景には、
もちろんAIがあります。
私はプログラマーとして仕事をしてきたわけではありません。
今回も、
- API
- REST
- Entra ID
- 証明書認証
- Managed Identity
- Sites.Selected
と、知らない言葉が次々に出てきました。
以前なら、
そのたびにマニュアルを探していたと思います。
説明を読む。
分からない言葉が出てくる。
その言葉を検索する。
すると、また知らない言葉が出てくる。
どこかで、
「これは自分には難しい」
と思っていたかもしれません。
今は、ChatGPTやClaudeに、
- 「そもそもAPIって何？」
- 「なぜここに認証が必要なの？」
- 「この権限は広すぎない？」
- 「今の構成を初心者にも分かるように説明して」
と、その場で相談できます。
そして、
単に答えを教えてもらうだけではありません。
一緒に設計を考える
↓
設定する
↓
エラーの原因を考える
↓
公式資料を調べる
↓
実際に動かして確認する
↓
また修正する
今回の感覚に近いのは、
技術に詳しい同僚AIが隣にいて、一緒に作業している
というものでした。
もちろん、
AIの答えがいつも正しいとは限りません。
特に認証や権限、
Microsoftのサービス仕様のような重要な部分は、
Microsoftの公式資料を確認し、
最後は実際の環境で動作を確かめる必要があります。
今回も、
AIに聞く
↓
公式情報を確認する
↓
実際に試す
↓
結果を見る
ということを何度も繰り返しました。
AIに全部任せるのではなく、
詳しい同僚と一緒に考えながら、
自分自身も理解していく。
そんな使い方が、
確かに私には合っていました。
８．今回一番大きかったのは、管理者側を自分で触ったこと
今回の会員サイトは、
まだ開発の途中です。
でも、0次開発をやってみて、
自分の中ではMicrosoft 365の見え方がかなり変わりました。
以前なら、
SharePointはファイル置き場
Teamsは会議やチャット
Azureはエンジニアが使うもの
APIはプログラマーの世界
管理者画面は専門家やベンダーが触るもの
そんなふうに、
別々のものとして見えていました。
今回、先に会員サイトの設計書を書きました。
その設計を実現するために、
Microsoftの道具箱をひっくり返しました。
必要な道具を見つけました。
そして管理者側に入り、
認証や権限を理解しながら、
それぞれをつないでみました。
分からないところはAIと一緒に調べました。
公式資料でも確認しました。
そして実際に動かしました。
そこで一番強く感じたのは、
Microsoft 365は、
用意された機能を利用者として使うだけでは、
ほんの一部分しか見えない。
ということです。
もちろん、
組織で利用するときに管理者権限を誰にでも渡すべきだとは思いません。
強い権限だからこそ、
厳しく管理する必要があります。
ただ、自分で何かサービスを作ろうとするなら、
管理者側で何ができるのかを、
自分自身でも理解しておくことはとても大切だ。
と今回あらためて感じました。
管理者の部分をすべてベンダーに任せれば、
安全で楽な面もあります。
でも、それだけでは、
- このサービスと、このサービスはつなげられる
- ここまで権限を絞れる
- このログを使えば、こんな運用ができる
という発想そのものが出てこないことがあります。
今回、管理者権限を持ってMicrosoft 365の中を実際に見たことで、
たくさんの道具があることだけでなく、
その道具をどう安全につなげれば
一つのサービスになるのか
が、少しずつ分かってきました。
月1,000円ほどのMicrosoft 365の道具箱。
必要な分だけ使えるAzure。
そして、
分からないところを一緒に考えてくれる同僚AI。
これらも大きな助けでした。
でも、今回の経験から私が最後に残したいのは、
もっと単純なことです。
自分でサービスを作りたいなら、
管理者側を人任せにしすぎず、
一度は自分で触って、何ができるのかを知っておく。
そして、
強い権限だからこそ、
その意味を理解し、
必要な範囲に絞って使う。
そのことの大切さを、
Digital Supporters Clubの会員サイトづくりを通して、
あらためて実感しました。
千代田区土砂災害警戒区域
(6.81MB)
