前回の記事では、Microsoft 365、Azure、Power Platform、Windows、Fabricなどで使えるCLIツールを紹介しました。
Microsoft関連のCLIは数が多く、最初からすべてを使いこなす必要はありません。
大事なのは、CLIを単なる「エンジニア向けの黒い画面」として見るのではなく、Microsoftサービスを自社で管理・活用するための実務ツールとして見ることです。
この記事では、紹介したCLIの中でも特に一般的におすすめしやすいものを中心に、何ができて、どう良いのかを整理します。
まずは「見える化」から始める
CLI活用の入口としておすすめなのは、自社のMicrosoft環境を見える化することです。
Microsoft 365を使っている企業では、Teams、SharePoint、Power Automate、ユーザー、グループ、メールボックス、ライセンスなどが少しずつ増えていきます。
最初は管理できていても、数年使ううちに、
- 使われていないTeamsが残る
- 所有者不明のSharePointサイトが増える
- 退職者が作ったPower Automateフローが残る
- 誰が管理者権限を持っているか分かりにくくなる
- 似たようなグループやチームが乱立する
といった状態になりがちです。
管理画面で1つずつ確認することもできますが、定期的に一覧化したい場合はCLIが向いています。
CLIを使うと、情報をまとめて取得し、CSVやJSONとして保存できます。そこからExcel、Power BI、Fabric、社内レポートへつなげることもできます。
最初から変更や削除を自動化する必要はありません。まずは、現在の状態を見える化する。これだけでも、Microsoft 365運用の質はかなり上がります。
CLI for Microsoft 365で自社テナントを棚卸しする
一般的なMicrosoft 365利用企業にまずおすすめしやすいのが、CLI for Microsoft 365です。
CLI for Microsoft 365は、Microsoft 365全体を横断的に確認しやすいツールです。公式ドキュメントでも、Microsoft 365テナントやSharePoint Frameworkプロジェクトを任意のプラットフォームから管理できるCLIとして説明されています。
特に向いているのは、自社テナントの棚卸しです。
たとえば、
- 社内にどのTeamsが存在するか
- どのSharePointサイトが存在するか
- どのPower Automateフローが存在するか
- 古いプロジェクトのリソースが残っていないか
- 所有者が不明なチームやサイトがないか
- 外部共有が広がりすぎていないか
といった確認に使えます。
これを月次で行えば、「なんとなくMicrosoft 365を使っている」状態から、「自社のMicrosoft 365環境を把握して運用している」状態に近づけます。
さらに、取得した情報をPower BIやFabricに流し込めば、Microsoft 365の利用状況ダッシュボードを作ることもできます。
これは単なるIT管理ではなく、DX推進にもつながります。どの部署がTeamsを活用しているのか。どの部署ではSharePointが放置されているのか。Power Automateが属人的に使われていないか。こうしたことを可視化できると、次にどこを支援すべきかが見えやすくなります。
Microsoft Graph PowerShellでユーザー・グループ・権限を整理する
Microsoft 365運用で避けて通れないのが、ユーザーとグループの管理です。
Microsoft Graph PowerShellは、Microsoft Graph APIをPowerShellから扱うためのSDKで、Entra IDのユーザー管理やグループ管理などに利用できます。
これを使うと、たとえば次のような確認がしやすくなります。
- 有効なユーザー一覧
- 無効化されていない退職者アカウント
- グループ一覧
- 管理者権限を持つユーザー
- ライセンス付与状況
- 部署ごとのアカウント状況
Microsoft 365の管理で怖いのは、「誰が何にアクセスできるか」が分からなくなることです。
とくに、TeamsやSharePointを長く使っている企業では、昔作ったグループや権限がそのまま残っていることがあります。
Graph PowerShellでユーザーやグループを定期的に確認できるようにしておくと、アカウント管理の精度が上がります。
さらに、CLI for Microsoft 365で取得したTeamsやSharePointの情報と、Microsoft Graph PowerShellで取得したユーザー・グループ情報を組み合わせると、より実用的な管理レポートを作れます。
たとえば、
- 退職者が所有者になっているTeams
- 管理者が1人しかいないSharePointサイト
- 所有者不明のグループ
- 外部共有が有効なサイトとその所有者
- 重要な業務フローを持つユーザー
といった情報を洗い出せます。
ここまでできると、CLIは単なる一覧取得ツールではなく、Microsoft 365ガバナンスの土台になります。
PnP PowerShellでSharePointを「AIが使える情報基盤」に近づける
Microsoft 365 Copilotや社内AIエージェントを活用したい企業にとって、SharePointの整理は非常に重要です。
AIの回答品質は、参照する社内情報の状態に大きく左右されます。
SharePoint上に、
- 古い資料
- 重複した資料
- ファイル名だけでは中身が分からない資料
- 権限が広すぎる資料
- どれが最新版か分からない資料
が大量にあると、人間も探しにくいですし、AIにとっても扱いにくい情報基盤になります。
そこで役立つのがPnP PowerShellです。
PnP PowerShellは、SharePoint Onlineを中心に、Microsoft Teams、Planner、Power Platform、Entra、Purviewなどにも対応するクロスプラットフォームのPowerShellモジュールです。
SharePointのサイト、リスト、ライブラリ、ページ、権限などを確認・管理できるため、社内情報の整理に使えます。
たとえば、
- 社内規程の置き場所を整理する
- 営業資料の保存場所を統一する
- 古いプロジェクトサイトを確認する
- ドキュメントライブラリの構成を見直す
- 権限が複雑になっている場所を洗い出す
- Copilotに参照させたい情報の格納場所を整える
といった使い方ができます。
Microsoft 365 Copilotを導入しても、SharePointに置かれた情報が整理されていなければ、期待した成果は出にくくなります。
逆に、SharePointを整理できている企業は、Copilotや社内AIエージェントの活用を進めやすくなります。
PnP PowerShellは、Copilot導入前の情報整理にも、導入後の運用改善にも使えるツールです。
Power Platform CLIで「作りっぱなし」を防ぐ
Power AppsやPower Automateは、現場主導の業務改善に向いています。
一方で、現場で自由に作れるからこそ、管理されないアプリやフローが増えやすいという問題もあります。
よくあるのは、
- 誰が作ったフローか分からない
- 個人アカウントに重要なフローが紐づいている
- 退職者が作ったフローが業務で動き続けている
- 開発環境と本番環境の区別がない
- 似たようなアプリが複数存在する
- 変更管理がされていない
といった状態です。
Power Platform CLIは、Power Apps、Power Automate、Dataverse、Power Pagesなどを管理するためのCLIです。環境ライフサイクル、認証、Dataverse環境、ソリューションパッケージなどに関する操作ができます。
特に重要なのは、Power Platformを「個人が作った便利ツール」から「組織として管理できる業務アプリ」に近づけられることです。
具体的には、
- アプリやフローをソリューションとして管理する
- 開発環境から本番環境へ移行する
- 変更履歴を管理する
- CI/CDに組み込む
- 重要な業務アプリを個人管理から組織管理へ移す
といった使い方ができます。
Power Platformは、現場のスピードと組織のガバナンスのバランスが重要です。Power Platform CLIを使うと、現場で生まれた改善を、組織として継続運用できる形に整えやすくなります。
Azure CLIとAzure FunctionsでMicrosoft 365の外側に自動化基盤を作る
Microsoft 365やPower Platformだけで多くの業務は自動化できます。
ただし、少し複雑な処理をしようとすると、Microsoft 365の中だけでは足りない場面も出てきます。
たとえば、
- Microsoft 365の利用状況を毎日集計する
- Graph APIから取得したデータを加工する
- SharePoint上のファイル情報を定期的にチェックする
- Power Automateから呼び出す独自APIを作る
- 社内システムとMicrosoft 365をつなぐ
- AIエージェントが呼び出す業務APIを用意する
といったケースです。
ここで役立つのがAzure CLIとAzure Functions Core Toolsです。
Azure CLIは、Azureリソースを管理するためのクロスプラットフォームCLIです。Azure Functions Core Toolsは、Azure Functionsをローカルで開発・テストし、Azureへデプロイするためのツールです。
この2つを使うと、Microsoft 365の外側に小さな自動化基盤を作れます。
たとえば、毎朝Microsoft 365の情報を取得して、異常があればTeamsへ通知する。Power Automateでは扱いにくい複雑なデータ加工をAzure Functionsに任せる。社内AIエージェントが呼び出す専用APIをAzure上に作る。
こうした構成が可能になります。
Power Automateは現場向けの定型自動化に強いですが、複雑なロジック、外部API連携、コード管理、テスト、デプロイまで考えると、Azure Functionsの方が向いている場面もあります。
つまり、
- 現場に近い定型自動化：Power Automate
- 少し複雑な処理：Azure Functions
- Azureリソース管理：Azure CLI
- Microsoft 365データ取得：Graph PowerShellやCLI for Microsoft 365
という形で組み合わせると、かなり実用的な業務自動化基盤になります。
Azure Developer CLIとBicepで社内アプリを再現可能にする
Azure上に社内アプリや業務APIを作る場合、最初はAzureポータルから手作業で作っても問題ありません。
しかし、運用が進むと次のような問題が出てきます。
- 開発環境と本番環境の構成が違う
- 誰がどの設定で作ったか分からない
- 同じ構成を別部署向けに再現できない
- 障害時に環境を作り直せない
- 手作業の設定漏れが起きる
こうした問題に対応するには、Azure環境をコードで管理する考え方が重要になります。
Azure Developer CLIは、Azureアプリのプロビジョニングやデプロイを高速化する開発者向けツールです。Bicepは、Azureリソースを宣言的に定義してデプロイするための言語です。
この2つを使うと、Azure上の社内アプリを再現可能な形で管理できます。
たとえば、
- 社内ポータル
- 問い合わせ対応API
- Microsoft 365連携アプリ
- 社内AIエージェント用API
- Power Automateから呼び出す業務API
- 部署別の小規模Webアプリ
などを、毎回同じ構成で展開しやすくなります。
これは受託開発会社やエンジニアだけに関係する話ではありません。社内DX担当者にとっても、「一度作った業務アプリを、別部署にも安全に展開できる」というのは大きな価値があります。
Azure Developer CLIとBicepを組み合わせると、Microsoft 365の周辺にある小さな業務システムを、属人的な手作業ではなく、再現可能な社内資産として管理しやすくなります。
Fabric CLIでMicrosoft 365・Power Platformのデータを分析基盤につなぐ
Microsoft 365やPower Platformを活用していると、社内にはさまざまなデータが蓄積されます。
たとえば、
- Teamsの利用状況
- SharePointサイトの利用状況
- Power Automateフローの一覧
- Power Appsの利用状況
- 部署ごとのアカウントやライセンス
- 業務アプリのデータ
- 問い合わせ件数や処理状況
です。
これらを個別に見るだけではなく、分析基盤に集約すると、より実用的な意思決定に使えます。
Fabric CLIは、Microsoft Fabricのワークスペース管理、パイプライン実行、データワークフロー自動化などをターミナルから行うためのCLIです。
たとえば、CLI for Microsoft 365やGraph PowerShellで取得したMicrosoft 365の棚卸し情報を、FabricやPower BIで分析することができます。
すると、
- 部署ごとのTeams活用状況
- SharePointサイトの増加傾向
- Power Automateの利用状況
- ライセンスの使われ方
- 放置されているリソース
- 改善支援が必要な部署
などを可視化できます。
これは単なるシステム管理ではなく、社内DXの進捗管理にもなります。Microsoft 365を「使っているかどうか」ではなく、「どのように使われているか」を見るために、Fabric CLIやPower BIを組み合わせる価値があります。
WinGetでWindows PCセットアップを標準化する
CLI活用というと、Microsoft 365やAzureの管理ばかりに目が行きがちですが、Windows PCのセットアップも重要です。
新入社員のPC、研修用PC、開発用PC、業務端末などを手作業でセットアップしている企業は多いです。
しかし、手作業だと、
- 入れ忘れが起きる
- 担当者によって環境が変わる
- セットアップに時間がかかる
- アプリの更新状況がバラバラになる
- 再セットアップ時に同じ環境を再現しにくい
という問題が起きます。
WinGetは、Windows上でアプリの検索、インストール、更新、削除、構成を行うためのコマンドラインツールです。
これを使うと、必要なアプリをまとめてインストールしたり、PC環境を標準化したりできます。
たとえば、
- Office関連アプリ
- ブラウザ
- Teams
- Visual Studio Code
- Git
- 社内標準ツール
- セキュリティ関連ツール
などを、決まった手順で導入しやすくなります。
特に、情シス担当者が少ない企業では、PCセットアップの属人化を減らせるだけでも効果があります。Microsoft 365活用の前提として、社員が使うPC環境を安定させることは重要です。
Microsoft 365 Agents Toolkit CLIとAgent 365 CLIで社内AIエージェント開発へ進む
ここからは少し上級者向けです。
Microsoft 365の中で使う社内アプリやAIエージェントを作りたい場合、Microsoft 365 Agents Toolkit CLIやAgent 365 CLIが関係してきます。
Microsoft 365 Agents Toolkit CLIは、Microsoft 365向けアプリをターミナルやCI/CDから作成、検証、デプロイするためのCLIです。
Agent 365 CLIは、Agent 365アプリケーションをAzureへデプロイ・管理するためのCLIです。
これらを使うと、単なる業務自動化を超えて、Microsoft 365の中で動く社内AIエージェントの開発に近づきます。
たとえば、
- Teamsから社内規程を検索するエージェント
- SharePoint上の営業資料をもとに提案準備を支援するエージェント
- Outlookやカレンダー情報をもとに会議準備を支援するエージェント
- Power AutomateやAzure Functionsを呼び出して業務処理を進めるエージェント
- 社内問い合わせを分類し、担当部署へつなぐエージェント
といったものが考えられます。
このとき重要なのは、いきなりAIエージェントを作ることではありません。
先に、
- Microsoft 365の情報が整理されている
- SharePointの権限が適切になっている
- Power Platformのフローが管理されている
- Azure上に安全なAPIがある
- ユーザーやグループの管理ができている
という状態を作ることです。
つまり、社内AIエージェントは単体で成立するものではなく、これまで紹介したCLI活用の延長線上にあります。
CLI for Microsoft 365でMicrosoft 365環境を把握する。Graph PowerShellでユーザーや権限を整理する。PnP PowerShellでSharePointを整える。Power Platform CLIで業務フローを管理する。Azure CLIやFunctionsでエージェントが呼び出す処理を作る。そのうえで、Microsoft 365 Agents Toolkit CLIやAgent 365 CLIを使ってエージェント化する。
この順番で考えると、AIエージェント開発はかなり現実的になります。
WinApp CLIとWinUI agent pluginで社内Windowsアプリ開発をAIエージェント化する
MicrosoftサービスのCLI活用は、管理や自動化だけに限りません。
Windows向けの業務アプリや社内ツールを開発している企業では、WinApp CLIやWinUI agent pluginを使うことで、Windowsネイティブアプリ開発にもAIエージェントを組み込みやすくなります。
たとえば、社内向けに次のようなアプリを作る場面を考えます。
- 現場で使う入力支援アプリ
- 社内データを確認するダッシュボードアプリ
- Microsoft 365や社内APIと連携するWindowsアプリ
- Power Platformでは作りにくいリッチな業務ツール
- 既存のWPFアプリをWinUI 3へ移行するプロジェクト
従来、このようなWindowsアプリ開発では、WinUI、Windows App SDK、XAML、MSIXパッケージング、署名、UIテスト、アクセシビリティ対応など、複数の知識が必要でした。
WinUI agent pluginは、こうした開発の流れをAIエージェントが扱いやすいように整理したものです。単にコードを書かせるだけではなく、プロジェクト作成、ビルド、実行、UIテスト、エラー修正、パッケージングまでの流れをエージェントが進めやすくなります。
ここで重要なのは、AIエージェントに「何となくWindowsアプリを作って」と頼むのではなく、Windowsアプリ開発に必要な知識やCLIツールを、エージェントが使える形で渡している点です。
これは、Microsoft 365運用CLIやAzure CLIの活用とも同じ考え方です。人間が管理画面で手作業するのではなく、CLIで再現可能な操作にする。そのうえで、AIエージェントがCLIやスキルを使って作業できるようにする。
この流れは、今後の業務アプリ開発でも重要になっていくはずです。
ツール同士を組み合わせると何がすごいのか
CLIの本当の価値は、単体で使うことだけではありません。複数のCLIを組み合わせると、管理画面では難しいことができるようになります。
たとえば、次のような組み合わせです。
Microsoft 365環境診断ダッシュボード
CLI for Microsoft 365でTeamsやSharePointサイトを取得する。Microsoft Graph PowerShellでユーザーやグループを取得する。Power Platform CLIでPower AppsやPower Automateの状況を確認する。Fabric CLIやPower BIで可視化する。
これにより、自社のMicrosoft 365環境を定期的に見える化できます。
退職者・異動者の影響調査
Microsoft Graph PowerShellで退職者・異動者アカウントを確認する。CLI for Microsoft 365で、その人が所有するTeamsやSharePointサイトを確認する。Power Platform CLIで、その人が作成・管理しているアプリやフローを確認する。Exchange Online PowerShellでメールボックスや配布リストを確認する。
これにより、退職や異動に伴う業務停止リスクを事前に確認できます。
Copilot導入前の情報整理
PnP PowerShellでSharePointサイトやドキュメントライブラリを棚卸しする。CLI for Microsoft 365でTeamsやSharePointの全体像を確認する。Microsoft Graph PowerShellで権限やグループを確認する。必要に応じてPurviewや管理センター側の設定も確認する。
これにより、Microsoft 365 Copilotを導入する前に、社内情報の状態を整えやすくなります。
社内AIエージェント基盤
CLI for Microsoft 365でMicrosoft 365のリソース構造を把握する。PnP PowerShellでSharePointナレッジを整理する。Azure CLIとAzure Functionsでエージェントが呼び出すAPIを作る。Power Platform CLIで業務フローと連携する。Microsoft 365 Agents Toolkit CLIやAgent 365 CLIでエージェントとして展開する。
この組み合わせにより、単なるチャットボットではなく、社内データや業務フローとつながったAIエージェントを構築しやすくなります。
CLI活用で大事なのは「自動化」よりも「運用を残す」こと
CLIというと、自動化のイメージが強いかもしれません。もちろん自動化は重要です。
ただ、それ以上に大事なのは、作業手順を残せることです。
管理画面での操作は、その場では簡単です。しかし、あとから振り返ると、誰がどの設定をどう変更したのか分かりにくいことがあります。
CLIで操作すれば、
- どんな情報を取得したか
- どの設定を変更したか
- どの手順で環境を作ったか
- どのスクリプトを使ったか
- いつ実行したか
を残しやすくなります。
これは、情シスやDX担当者にとって大きな価値です。属人的な作業を減らし、組織として再現可能な運用に近づけることができます。
注意点：強い権限を安易に渡さない
CLIは強力です。だからこそ、権限設計には注意が必要です。
最初から削除、権限変更、メール送信、本番リソース変更まで自動化すると、ミスの影響が大きくなります。
特に、AIエージェントやMCP ServerからCLIを呼び出す場合は注意が必要です。
最初は、
- 読み取り系から始める
- 削除系は手動確認を挟む
- 権限変更は人間がレビューする
- 管理者アカウントを常用しない
- Entra IDアプリ登録の権限を最小化する
- 実行ログを残す
- 本番環境の前に検証環境で試す
という考え方が安全です。
CLI活用の目的は、危険な自動化を増やすことではありません。安全に、再現可能に、管理しやすくすることです。
まとめ
Microsoftサービスを使う企業がCLIを活用するなら、まずは自社環境の見える化から始めるのがおすすめです。
そのうえで、
- CLI for Microsoft 365でMicrosoft 365全体を棚卸しする
- Microsoft Graph PowerShellでユーザー・グループ・権限を整理する
- PnP PowerShellでSharePointを整える
- Power Platform CLIでPower AppsやPower Automateを管理する
- Azure CLIとAzure Functionsで自動化基盤を作る
- Azure Developer CLIとBicepで社内アプリを再現可能にする
- Fabric CLIで利用状況を分析基盤につなぐ
- WinGetでWindows PC環境を標準化する
- Agents Toolkit CLIやAgent 365 CLIで社内AIエージェント開発へ進む
という流れで活用範囲を広げていくとよいです。
CLIはエンジニアだけのものではありません。Microsoft 365、Azure、Power Platformを本格的に活用する企業にとって、CLIは管理、可視化、自動化、AI活用の土台になります。
各CLIツールの概要は、前編「MicrosoftサービスのCLIツール18選：企業向け完全まとめ」でまとめています。