自動化したい業務はあるのに、作れない
Power Automateを開いたことがある人なら、あの画面の圧を知っているはずです。トリガーを選び、アクションを追加し、動的なコンテンツを差し込み、条件分岐を組む。やりたいことは1行で言えるのに、それを画面上で組み立てる方法がわからない。
Copilotは、この最初の壁を下げます。日本語で「こういうときに、こうしてほしい」と書くと、トリガーとアクションを備えたフローの下書きが出てきます。ゼロから組む作業が、出てきたものを直す作業に変わります。
ただし、そのまま業務に投入できるものが出てくるわけではありません。この記事では、入門編としてCopilotでできることと最初のフローの作り方を扱い、レベルアップ編として例外処理の組み込み方、運用設計、そして日本で使う際に確認すべき設定を扱います。
本文の内容は2026年8月7日にMicrosoft Learnで確認したものです。
【入門】Power AutomateのCopilotでできること
Microsoft Learnによれば、クラウドフローのCopilotは次のことができます(Copilot で最初のクラウド フローを作成する)。
- 意図を理解し、指定したシナリオからフローを作る
- 接続を自動的に設定する。できるだけ早く動く状態にする
- 必要なパラメーターをフロー内に適用する
- 変更の依頼に応答する。アクションの更新や置き換えなど
- フローと製品に関する質問に答える。「このフローは何をしますか」と聞けば概要が返り、「ライセンスにアクセスするにはどうすればよいですか」といった製品の質問にも答える
- フローの説明文を提案する
4番目と5番目は見落とされがちですが、実務で効きます。特に、引き継いだフローが何をしているのかを聞ける機能は価値があります。前任者が作ったまま誰も触れなくなったフローは、Excelのブックと同じくらいよくある問題だからです。
なお、Copilotが使えるのはクラウドフローだけではありません。プロセスマイニング、デスクトップフロー、オートメーションセンターにもそれぞれCopilotがあります(Power Automate の Copilot)。ただしデスクトップフロー側の機能には、プレビュー段階のものが多く含まれます。
【入門】始める前に知っておくべき制約
制約1: 英語に最適化されている
Microsoftは公式ドキュメントで、Copilotは開発中の新しい技術であり、英語での使用に最適化されていて他の言語でのサポートは限定的であること、そのため一部が英語で表示される場合があることを明記しています。
別のFAQでは、クラウドフローのCopilotのモデルについて英語のみと記載されています。日本語で通ることもありますが、動作が保証されているとは考えないでください。うまく解釈されないときは英語で書き直すと通ることがあります。
社内で教えるときは、この事実を先に伝えてください。日本語でうまくいかなかったことを、自分の書き方のせいだと思い込む人が出ます。
制約2: リージョンとテナント設定が絡む
Copilotの有効化の条件は、リージョンによって異なります。公式ドキュメントは、GPUがあるリージョン（英国、オーストラリア、米国、インド）ではCopilotが既定でオンになり、無効化はテナントレベルでのみ、管理者がサポートに連絡してPowerShellスクリプトを使って行うと説明しています。
日本はこのGPUのあるリージョンの一覧に含まれていません。公式の地域対応表では、日本のPower Platform環境から使う場合、処理は米国で行われ得ると説明されています。
一般提供の機能自体は既定で有効ですが、環境によっては地域をまたぐデータ移動への同意が必要です。この同意は、Power Platform管理センターで環境を選んで設定する環境単位の設定です。テナント全体で一括して決まるものではありません。
そして、この設定を外してもCopilotが一律に全部無効になるわけではありません。機能ごとに挙動が違うので、自社の環境で何が使えているかを実際に確認してください。
つまり、日本のテナントでPower AutomateのCopilotを使うことは、データが地理的にどう扱われるかという設定と結びついています。これは情報システム部門とコンプライアンス担当が把握しておくべき事項です。使う前に、自社のテナントで今どうなっているかを確認してください。
なお、この機能はAzure OpenAI Serviceによって提供されています。
【入門】最初のフローを作る
手順の前に、前提を2つ確認してください。
1. ライセンス。スタンドアロンのPower Automateライセンス、対象のMicrosoft 365に付帯するライセンス、またはPower AppsやDynamicsのライセンスのいずれかが必要です。サインインできれば使える、ではありません。
2. アカウントの種類。個人のMicrosoftアカウントでは利用できません。組織IDを持つ職場または学校のアカウントが必要です。
そのうえで、手順は次のとおりです。
- 職場または学校のアカウントでPower Automateにサインインする
- 左のナビゲーションでホームが選択されていることを確認する
- Copilotで自動化を作成するフィールドに、動かしたい内容を自然言語で書く
- 生成を選ぶ
- Copilotが、トリガーと1つ以上のアクションを含むフローの構造を生成する
- 問題なければ保持して続行するを選ぶ。変更したい場合は詳細を追加して再生成させる
- 接続が正しく構成されているか確認する。緑のチェックが付いていれば正常、赤い感嘆符が付いていれば設定が必要
- フローの作成を選ぶ
- デザイナーが開き、右側にCopilotペインが表示される。ここで設定を仕上げ、質問し、編集する
- 保存する
- テストする
7番と11番を飛ばす人が非常に多いのですが、ここが本番です。接続の赤い感嘆符を無視すると動きません。そしてテストせずに本番の業務に載せるのは、単純に危険です。
【入門】効くプロンプトの型
Microsoftの公式ドキュメントが示しているコツは明快です。
型: 「Xが発生した場合、Yをする」の形で書く
これがトリガーとアクションの構造にそのまま対応するため、Copilotが解釈しやすくなります。
できるだけ具体的に書く。公式が挙げている対比が分かりやすいので引用します。
よくない例: 電子メールを処理する
よい例: メールが届いたとき、Teamsの総合チャンネルに、件名「Contoso」で投稿する
可能ならコネクタ名を書く。Outlook、Teams、Formsなど、使ってほしいサービスを名指しします。
プロンプトを調整して繰り返す。1回で決まらないことを前提に、表現を変えて試します。
中小企業でよく効く例を挙げておきます。
- 「Microsoft Formsに問い合わせフォームの回答が入ったら、営業部のTeamsチャネルに投稿して、SharePointのリストに行を追加する」
- 「経費申請のExcelファイルがSharePointの指定フォルダーに追加されたら、上長にTeamsで承認依頼を送る」
- 「毎週金曜17時に、その週に更新されたSharePointのドキュメント一覧をメールで送る」
3つに共通しているのは、いつ・何が起きて・どこに・何をするかがすべて書かれていることです。この4点が埋まっていれば、たいてい形になります。
【レベルアップ】ユースケース集
「自動化したい業務はある」と言う人に何を自動化したいか聞くと、たいてい言葉に詰まります。具体例が頭に無いからです。よくある形を並べます。
| やること | きっかけ | 効くところ |
|---|---|---|
| 申請の受付と承認 | フォーム送信 | 誰の所で止まっているかが見える |
| フォーム回答の振り分け | フォーム送信 | 内容ごとに担当へ自動で回る |
| 定期レポートの配信 | 毎週・毎月の時刻 | 作る人の予定に左右されない |
| 期限リマインド | 一覧の日付が近づく | 契約更新、資格更新、点検日の抜けを防ぐ |
| メール添付の保存 | 特定の差出人からのメール | 請求書や納品書を手で保存しなくなる |
| 問い合わせの一次振り分け | 共有メールボックス受信 | 誰が見るかの往復が消える |
| 在庫・数値のしきい値通知 | 一覧の更新 | 気づいたときには遅い、を防ぐ |
| 会議前の資料リマインド | 予定表の開始前 | 準備物の抜けを減らす |
| 退職・異動時の棚卸し通知 | 人事の一覧の更新 | 権限の消し忘れを減らす |
いくつか、頼み方まで書きます。
期限リマインドを作る
いちばん費用対効果が高い型です。人は期限を忘れますが、フローは忘れません。
「SharePointリストの契約一覧を毎日朝9時に確認し、更新期限が30日以内で、ステータスが更新済みでない項目があれば、担当者列の人にTeamsで通知するフローを作成してください」
30日以内、という条件を数字で書くのが要点です。近づいたら、では組めません。
メール添付を自動で保存する
「特定の差出人から件名に請求書を含むメールが届いたら、添付ファイルをSharePointの請求書フォルダーに保存し、ファイル名を『受信日_差出人名_元のファイル名』に変えるフローを作成してください」
ファイル名の規則まで指定してください。ここを決めずに作ると、後で探せない山ができます。
問い合わせの一次振り分け
「共有メールボックスにメールが届いたら、本文に含まれるキーワードで、見積、技術、請求の3つに分類し、それぞれの担当チャネルにTeamsで転送するフローを作成してください。どれにも当てはまらない場合は、未分類チャネルに転送してください」
どれにも当てはまらない場合の行き先を必ず指定してください。これが無いと、分類できないメールが黙って消えます。
【レベルアップ】例外処理はAIで足せるのか
結論から書きます。足せます。ただし、何が例外かを挙げるのは人の仕事です。
Copilotは、頼めば例外処理の構成を作れます。スコープで囲んで失敗時の分岐を作る、再試行の設定を入れる、失敗時に通知を送る。構造を作るのは得意です。
一方で、あなたの業務でどんな例外が起きるかは知りません。だから、こう頼んでも足りません。
「このフローに例外処理を足してください」
返ってくるのは一般的な失敗時の通知くらいです。効かせるには、起きうる例外を人が挙げて渡します。
考えられる例外の型
業務の自動化で実際に起きるものを並べます。この一覧を見ながら、自分の業務に当てはまるものを選んでください。
| 例外の型 | 具体例 | よくある結末 |
|---|---|---|
| データが空 | 添付なしのメール、未入力の必須項目 | フローが途中で止まる |
| 想定外の値 | 日付欄に文字列、全角の数字、想定にない選択肢 | 変換に失敗して止まる |
| 重複 | 同じ申請が二重送信される | 同じ処理が2回走る |
| 接続の失効 | パスワード変更、権限変更、アカウント無効化 | ある日突然すべて止まる |
| 権限不足 | 保存先フォルダーの権限が変わった | 保存だけ失敗して気づかない |
| 相手が不在 | 承認者が退職・長期休暇 | 承認待ちのまま滞留する |
| 上限超過 | 1日の実行回数、添付サイズ、API制限 | 月末だけ止まる |
| 順序の入れ違い | 後続の処理が先に走る | データが不整合になる |
| 部分的な失敗 | 10件中3件だけ失敗 | 成功扱いで通知されない |
下3つが、実務でいちばん厄介です。止まってくれれば気づきますが、これらは成功したように見えて結果が壊れます。
挙げたうえで、こう頼む
「このフローに例外処理を足してください。想定する例外は次の4つです。
- 添付ファイルが無いメールが届いた場合は、処理をスキップして未処理チャネルに通知する
- 保存先フォルダーへの書き込みに失敗した場合は、3回まで再試行し、それでも失敗したら管理者に通知する
- 同じ申請番号がすでに一覧にある場合は、追加せず重複として通知する
- 承認者が5営業日応答しない場合は、上長に転送する それぞれ、失敗したことが分かる通知を必ず含めてください」
例外ごとに、どうするかまで書くのが要点です。検知するだけで何もしないと、結局気づきません。
「止める」か「進める」かを決めておく
例外に当たったとき、フローを止めるのか、その1件だけ飛ばして続けるのか。これは業務ごとに違うので、AIには決められません。
- 止める: お金が動く、外部に送る、取り消しが難しい処理
- 飛ばして続ける: 大量件数の一括処理で、1件の失敗が他に影響しないもの
飛ばす場合は、飛ばした件を必ず記録に残してください。後から手で処理するためです。記録が無いと、飛ばされたことに誰も気づきません。
【レベルアップ】生成されたフローに、例外処理を足す
Copilotが作るのは、うまくいく場合のフローです。実務で必要なのは、うまくいかない場合の処理です。ここは人が設計します。
生成後に足すべきものは、だいたい決まっています。
- 条件分岐: 金額が一定額を超えたら別の承認者に回す、といった分岐
- 承認ステップ: 自動で処理を完了させず、人の承認を挟む
- 失敗時の通知: フローが落ちたときに、担当者に知らせる
- 繰り返し処理: 複数件をまとめて扱う場合のループ
- 重複実行の防止: 同じデータを二重に処理しない仕組み
このうち、失敗時の通知を入れていないフローが本当に多いです。自動化は動いている限り誰も見ません。だからこそ、止まったときに気づける仕組みがないと、止まったことに何週間も気づかないという事故が起きます。フローを作ったら、必ず失敗時の通知先を決めてください。
Copilotペインを開いた状態でデザイナーにいるなら、これらの追加も会話で頼めます。「このフローに、金額が10万円を超える場合は部長に承認を求める分岐を追加して」といった依頼です。
【レベルアップ】誰が持つフローなのかを決める
技術的には動いても、運用で壊れる自動化があります。原因はほぼ例外なく、所有者が決まっていないことです。
作った人が異動する、退職する、部署が変わる。そのときフローは、誰のものでもないまま動き続けます。接続に使っているアカウントが無効になった瞬間に止まり、誰も直せない。
設計の段階で、次の3つを決めてください。
- 所有者: このフローに責任を持つのは誰か。個人アカウントではなく、共有アカウントやサービスアカウントで動かすべきかを検討する
- 使っているコネクタと権限: どのサービスに、どの権限でつながっているか。棚卸しできる形で記録する
- 止め方: 誰が、どうやって止められるか。緊急時に止められない自動化は作らない
3番目は特に重要です。誤ったメールを大量に送るフローが動き始めたとき、止められる人が社内にいるかどうか。これは技術の問題ではなく体制の問題です。
【レベルアップ】エラー検知もAIで作れるのか
作れます。ただし、何を異常とみなすかの条件は人が決めます。ここもAIには決められません。
検知は3層に分けて考えてください。層が下るほど、作るのが難しく、そして重要になります。
| 層 | 何を見るか | 気づける事故 |
|---|---|---|
| フローが動いたか | 失敗、タイムアウト、停止 | フローが止まった |
| データが正しいか | 件数、値の範囲、必須項目 | 動いたが中身が壊れている |
| 業務の結果が合っているか | 前月比、突合の差、滞留件数 | 動いて中身も正しいが、業務としておかしい |
1層目は、標準通知だけでは足りない
Power Automateには、実行の失敗を知らせる標準の通知があります。ただし、これに頼り切るのは危険です。
標準の通知は、修正可能と判定された既知の障害が対象で、同じフローについては一定期間（28日）通知が抑制されます。宛先もフローの所有者と共同所有者です。一般的なアクションの失敗を、その都度取りこぼさずに拾う仕組みではありません。
だから、失敗を確実に拾いたいなら、フローの中に失敗時の分岐を作ってください。実行後の構成（Configure run after）で失敗時に走るアクションを置き、そこから通知を送ります。
そのうえで、通知先を個人メールにしないでください。休んだ日に気づけません。共有メールボックスかTeamsのチャネルに飛ばします。標準通知の宛先は所有者なので、この飛ばし先の設計は自分で作る必要があります。
2層目からがAIの出番
「動いたけれど中身がおかしい」を検知するフローは、別に作ります。
「毎日18時に、本日追加された申請一覧を確認するフローを作成してください。次のいずれかに当てはまる行があれば、管理チャネルに一覧で通知してください。
- 金額欄が空、または0
- 申請日が未来の日付
- 担当者欄が空
- 同じ申請番号が2件以上ある 該当が無い日は、通知を送らないでください」
該当が無い日は通知しない、を入れてください。毎日「異常なし」が届くと、人は見なくなります。異常のときだけ届くから気づけます。
3層目は、件数の突合が現実的
業務としておかしいかどうかは、機械には判断が難しい。ただし、件数を突き合わせるだけでかなり拾えます。
- 受け付けた件数と、処理された件数が合っているか
- 昨日と比べて件数が極端に増減していないか
- 一定日数を超えて滞留している件数
「毎週月曜9時に、先週の申請受付件数と承認完了件数を数え、差が10件以上ある場合と、7日以上滞留している申請がある場合に、管理チャネルへ通知するフローを作成してください」
しきい値の数字は、最初は適当で構いません。運用しながら調整します。通知が多すぎれば上げる、少なすぎれば下げる。最初から正しい数字を決めようとして、いつまでも作らないほうが損です。
検知フロー自体が止まったら
これが盲点です。監視するフローが止まっていても、誰も気づきません。異常が無いのか、監視が死んでいるのかを区別できないからです。
対策は単純で、週に1回だけ「監視は動いています」という通知を送ることです。毎日だと読まれませんが、週1なら気づきます。届かない週があれば、監視が止まっています。
【レベルアップ】個人で作るか、組織で管理するか
ここが分かれ道です。同じフローでも、誰の持ち物にするかで寿命が変わります。
個人で作る場合
自分の作業を自分で楽にする範囲なら、個人で作って構いません。むしろ、そこから始めるべきです。
向いているのは、自分だけが困っていて、止まっても自分しか困らないもの。メールの仕分け、自分宛のリマインド、個人的な集計。
限界もはっきりしています。その人が異動・退職したら止まります。そして、止まったことに周りが気づきません。他の人が業務で頼り始めた瞬間に、個人のフローは組織のリスクになります。
見極めの目安は、自分以外の誰かがその結果を当てにし始めたかどうかです。当てにされ始めたら、組織の持ち物に移す時期です。
組織で管理する場合の最小構成
いきなり厳密な統制を敷くと、誰も作らなくなります。最初はこの5つで足ります。
| 決めること | 最低限のやり方 |
|---|---|
| 置き場所 | 個人環境ではなく、共有の環境に置く |
| 所有者 | 個人ではなく、複数人がアクセスできる形にする |
| 名前 | 「業務名_きっかけ_担当部署」で揃える |
| 一覧 | 何のフローがあるかの一覧を1か所に置く |
| 棚卸し | 半年に1回、動いているか・まだ必要かを見る |
3番目の命名が、地味にいちばん効きます。「テストフロー」「フロー1」「コピー_の_コピー」が並ぶと、誰も触れなくなります。
所有者については前の節にも書きましたが、共有の資格情報で1つの有料ライセンスを複数人が使う形にすると、ライセンス違反になり得ます。人の形をしたサービスアカウントを使う場合も、そのアカウントに適切なライセンスが要ります。ここは情報システム部門と一緒に決めてください。
野良フローの見つけ方
管理を始めると、すでに誰かが作ったフローが社内に散らばっていることに気づきます。悪いことではありません。困りごとがあった証拠です。
見つけ方は、管理センターで環境ごとのフロー一覧を見るのが基本です。そのうえで、現場に聞くのがいちばん早い。「自動で通知が来る仕組み、誰か作ってませんか」と聞くと出てきます。
見つけたら、止めさせないでください。止めると、その業務が手作業に戻るか、もっと見えない場所で作られます。一覧に載せて、所有者を決めて、動き続けられるようにするのが目的です。
権限とデータの持ち出し
組織で広げるなら、ここは避けて通れません。
- 接続先の制限: 業務データを外部サービスへ送るコネクタを、どこまで許可するか。Power Platform側でポリシーとして設定できます
- 環境の分離: 試す場所と、本番で動かす場所を分ける
- 見えてよい範囲: フローが読み書きできる範囲は、作った人の権限ではなく、そのアクションが使っている接続のIDの権限で決まります。作成者の接続を使う構成もあれば、実行する人自身の接続を使う構成もあります。共有フォルダーの権限が緩いと、フロー経由で広がります
3つ目が見落とされます。フローそのものより、各アクションがどの接続を使っているかを見てください。誰が作ったかではありません。
【レベルアップ】Microsoft 365 Copilotとの違いを整理する
混同されやすいので整理しておきます。
| 入口 | 何をするもの |
|---|---|
| Power AutomateのCopilot | Power Automateの中で、フローそのものを作る・直す・説明する |
| Microsoft 365 Copilot | Word、Excel、Teamsなどの中で作業を助ける。フローをプラグインとして使う機能はプレビュー段階 |
| Copilot Studio | エージェントを自作する開発ツール。エージェントフローという別の仕組みを持つ |
業務を自動化したいならPower AutomateのCopilot、文書や会議を効率化したいならMicrosoft 365 Copilot、というのが基本の分かれ方です。同じCopilotという名前でも、契約も画面も別だと考えてください。
Teamsの会議で決まったタスクを自動処理につなげたい、といった横断的な使い方は魅力的ですが、そこは設計が要ります。まずは片方ずつ確実に使えるようにするほうが、結果的に早く進みます。会議側の話はTeamsでCopilotを使う方法にまとめました。
【レベルアップ】自動化に向く業務の見分け方
作れるかどうかより、やるべきかどうかで詰まります。次の4つを見てください。
| 観点 | 向いている | 向いていない |
|---|---|---|
| 手順 | 毎回同じ | 都度判断が入る |
| 頻度 | 週に何度も | 年に数回 |
| 入力 | 形が決まっている | 人によって書き方が違う |
| 失敗したとき | 気づける、やり直せる | 気づかないまま進む |
4番目がいちばん軽視されます。失敗に気づけない自動化は、手作業より危険です。月末に気づいたら1か月分の処理が抜けていた、という形になります。
そして、向いていない業務を自動化する前にやることは、業務のほうを直すことです。人によって書き方が違う入力を自動化しようとすると、例外処理だらけのフローになって誰も保守できません。入力の形を先に揃えるほうが、結局速い。
【レベルアップ】実例: 申請の受付から通知までを1本作る
1本通します。以下は説明のための設定です。
やりたいこと: 社内フォームに備品購入の申請が入ったら、内容を一覧に記録し、承認者に通知する。
最初の指示
「フォームに新しい回答が送信されたら、その内容をSharePointのリストに追加し、申請内容を含むメッセージを承認者にTeamsで送るフローを作成してください」
動詞と対象を具体的に書くのが要点です。何かあったら通知して、では組めません。
出てきたものを見て、足りないものを足す
生成された直後のフローは、うまくいく場合しか想定していません。ここに足します。
- 失敗したときの通知。フローが止まったことに誰も気づかない状態を作らない
- 重複の扱い。同じ申請が二重に来たらどうするか
- 金額による分岐。一定額を超えたら承認者を変える、など
- 添付ファイルの扱い。あるとき、ないときで止まらないか
確認する
テストは3種類やってください。正常なデータ、想定外のデータ、空のデータ。空のデータで止まるフローは実務で必ず止まります。
【レベルアップ】動かなくなったときに見る場所
自動化は、作った直後より半年後に問題が起きます。見る順番を決めておきます。
- 実行履歴を見る。どのステップで止まったかが出ます。まずここ
- 接続の期限を確認する。アカウントのパスワード変更や権限変更で、接続が切れます。これがいちばん多い原因です
- 参照先が変わっていないか確認する。フォルダー名の変更、リストの列名の変更、フォームの設問追加
- 仕様変更を疑う。コネクタ側の変更で動きが変わることがあります
2番と3番は、自動化と無関係な作業が原因で起きます。誰かがフォルダー名を整理しただけで止まる。だから次の節が要ります。
【レベルアップ】止め方と引き継ぎを先に決める
自動化でいちばん多い事故は、作った人が異動して、誰も中身を知らないフローが動き続けることです。
作る前に4つ決めてください。
1. 持ち主。個人アカウントで作ると、退職時に止まります。重要なフローは、共有の環境で持つか、サービスプリンシパルを所有者にする設計にしてください。
ただし、これは置き換えるだけでは済みません。接続の共有、ライセンスを持たない利用者の扱い、Processライセンスや従量課金の選択がついてきます。共有の資格情報で1つの有料ライセンスを複数人が使う形にすると、ライセンス違反になり得ます。人の形をしたサービスアカウントを使う場合も、そのアカウントに適切なライセンスが要ります。ここは情報システム部門と一緒に決めてください。
2. 止め方。誰がどう止めるのか。緊急時に止められない自動化は、事故の被害を広げます。
3. 通知先。失敗したとき、誰に飛ぶのか。個人宛にすると、その人が休んだ日に気づけません。
4. 何をしているかの記録。フロー名だけでは分かりません。何のために、どの業務のどこを、いつから自動化したかを1枚に書いて、フローとは別の場所に置いてください。
この4つは、フローを作る時間より短く済みます。そして、作った後には誰もやりません。
よくある失敗と対処
| 症状 | よくある原因 | 対処 |
|---|---|---|
| フローが生成されない | 指示が曖昧 | いつ、何が起きたら、何をするかを具体的に書く |
| 想定外のデータで止まる | 正常系しかテストしていない | 正常・想定外・空の3種類でテストする |
| 半年後に止まった | 接続の期限切れ | 実行履歴を見て、接続を再認証する |
| 参照先が見つからない | フォルダー名や列名が変わった | 参照先を変える作業を、業務側の手順に含める |
| 誰も中身を知らない | 個人アカウントで作った | 共有環境で持ち、記録を別途1枚残す |
| 失敗に気づかない | 失敗時の通知が無い | 失敗時の通知を、複数人が見る場所へ飛ばす |
下3つは、作るときではなく決めるときの問題です。
【レベルアップ】最初の3本に何を選ぶか
自動化を始めるとき、いちばん大きい失敗は難しいものから手をつけることです。承認経路が複雑な基幹業務を最初に選ぶと、例外処理だらけになって完成しません。そして「うちには向かなかった」で終わります。
最初の3本は、この基準で選んでください。
1本目: 通知だけのもの。データを書き換えないので、失敗しても被害がありません。期限リマインドが最適です。作る側が仕組みに慣れるための1本と割り切ってください。
2本目: 記録するだけのもの。メール添付の保存、フォーム回答の一覧への転記。追加はするが、既存のものを書き換えない。元に戻せる範囲にとどめるのが条件です。
3本目: 振り分けか集計。ここで初めて条件分岐が入ります。1本目と2本目で仕組みが分かっているので、分岐の設計に集中できます。
この順で作ると、3本目までに例外処理の勘所がつかめます。逆に1本目を複雑なものにすると、何が原因で動かないのか切り分けられません。
【レベルアップ】作る前に、1枚書く
フローを作る前に、紙1枚に書いておくことがあります。作るより短い時間で終わり、後の手戻りをいちばん減らします。
| 項目 | 書くこと |
|---|---|
| 目的 | この自動化で、誰の何が楽になるか |
| きっかけ | 何が起きたら動くか（時刻、受信、更新） |
| やること | 順番に箇条書きで |
| 例外 | 起きうるものと、そのときどうするか |
| 通知先 | 成功時と失敗時。それぞれ誰に |
| 持ち主 | 誰の環境で、誰が引き取れるか |
| 止め方 | 誰がどう止めるか |
| やめる条件 | 何が起きたら、この自動化自体をやめるか |
最後の項目を書いている会社をほとんど見ません。自動化は増える一方で、減りません。使われなくなった通知が飛び続け、誰も読まないまま残ります。
やめる条件の例を挙げると、「対象業務が月5件を下回ったら手作業に戻す」「通知に3か月間誰も反応しなかったら止める」。先に書いておくと、やめる判断が個人の勇気に依存しなくなります。
この1枚は、そのままCopilotへの指示の下敷きにもなります。目的、きっかけ、やること、例外を書いてあれば、それを貼るだけでかなり具体的な指示になります。書く手間は二重になりません。
【レベルアップ】社内ツールを作る前に、まずPower Automateで足りないか見る
AIに指示して社内ツールを作る、いわゆるバイブコーディングが広がっています。動くものが数時間でできるので、実際よくできます。
そのうえで、Microsoft 365を契約していてPower Automateが使えるなら、まずこちらで足りないかを見てください。作れるかどうかではなく、作った後に誰が持つかで差が出ます。
作った後に必要になるもの
新しく内製したツールは、動いた瞬間から次のものが必要になります。
| 必要になるもの | 内製ツール | Power Automate |
|---|---|---|
| 置き場所 | サーバーやホスティングを用意する | 不要。契約の中にある |
| ログイン | 認証を自分で実装する | 会社のアカウントをそのまま使う |
| 誰が見てよいか | 権限の仕組みを作る | 既存の権限がそのまま効く |
| 秘密情報の保管 | 保管場所と受け渡しを設計する | 接続として管理される |
| 実行の記録 | ログの仕組みを作る | 実行履歴が標準で残る |
| 動かなくなったとき | 作った人が直す | 実行履歴から追える |
| 作った人が辞めたら | 引き取れる人がいない | 所有者を移せる（条件あり） |
下2行がすべてです。内製ツールは、作るのは速いが、保守できる人が1人しかいない状態から始まります。その1人が異動した瞬間、誰も触れないものが業務の中で動き続けることになります。
Power Automateなら、少なくとも実行履歴を見れば何が起きたか分かります。引き継ぎについては条件があって、所有者をその場で変更できるのはソリューションに含まれるクラウドフローです。ソリューションに入れていないフローは、まずソリューションへ追加するか、書き出して取り込み直すなどの手順が要ります。
だから、最初からソリューションの中で作るのを勧めます。後から移すより、はるかに楽です。これは機能の優劣ではなく、管理の受け皿が最初から用意されているかどうかの差です。
それでもPower Automateが向かない領域
次のものは、無理に寄せないほうがよい。
- 画面が要るもの。入力フォームを超える操作性が必要なら、別の手段のほうが速い
- 複雑な計算やロジック。条件分岐が10を超えたあたりから、フローは読めなくなります
- 大量データの処理。件数が多いと実行時間と回数の上限に当たります
- 社外の人が使うもの。認証の前提が社内アカウントなので、相性が悪い
- 応答速度が要るもの。即座の反応が求められる用途には向きません
条件分岐が増えてきたら、それは自動化ではなく業務ルールが複雑すぎるサインでもあります。ツールを変える前に、業務のほうを単純にできないか見てください。
判断の順番
迷ったら、この順で見てください。
- 既製の機能で足りないか。Microsoft 365の標準機能、使っているSaaSの設定。作る前に探す
- Power Automateで足りないか。定型の受け渡し、通知、記録なら、たいてい足ります
- それでも無理なら内製を検討する。このとき、保守できる人が2人以上いるかを先に確認する
1番で止まる案件が、実際にはかなりあります。すでにある機能を知らずに作り始めるのが、いちばんもったいない。
一元化すべきなのは、手段ではなく把握
最後にひとつ、視点を変えます。
一元化の本当の目的は、全部を同じツールで作ることではありません。社内で何が自動で動いているかを、把握できる状態にすることです。
バイブコーディングで作ったツールも、Power Automateのフローも、野良化すれば同じ問題を起こします。誰が作ったか分からない、止め方が分からない、止まったことに気づかない。
だから、手段を統一できなくても、一覧だけは1つにしてください。何が、どこで、誰の持ち物で動いているか。この一覧があれば、手段が混在していても管理できます。逆に、全部Power Automateに寄せても、一覧が無ければ同じことが起きます。
Power Automateを勧める理由は、この一覧を作る手間が小さいからです。管理センターから環境ごとに見えるので、把握の出発点として使いやすい。そこに内製ツールの分を手で足していけば、全体像になります。
KOIYALの見解: 自動化の難所は、作ることではなく決めること
業務改善の支援をしていて痛感するのは、自動化がうまくいかない理由のほとんどが技術ではないということです。
業務のルールが決まっていない。承認が必要なのはいくらからか、例外はどう扱うか、誰が最終判断するのか。これらが曖昧なまま自動化しようとすると、フローが組めません。逆に言えば、Copilotに指示を書こうとすると、ルールが決まっていないことが可視化されます。「Xが発生した場合、Yをする」が書けないなら、それは業務が定義されていないということです。
だから当社では、Power Automateの研修を業務整理の場として設計しています。フローの作り方を教える時間より、いま何が起きたら何をしているのかを言語化する時間のほうが長い。Copilotが下書きを作ってくれるようになった今、人がやるべき仕事は明確にそちらへ移りました。
もうひとつ。自動化は小さく始めてください。いきなり基幹業務を自動化しようとすると、決めることが多すぎて止まります。週に1回、5分の作業。この規模から始めた会社のほうが、結果的に遠くまで行きます。
次の一歩
自社で繰り返している作業を1つ選び、「Xが発生した場合、Yをする」の形で1行に書いてみてください。書けたらCopilotに渡す。書けないなら、まずそこを決めるところが本当の課題です。
Excelを起点にした業務をCopilotで整理する話はExcelでCopilotを使う方法で扱っています。
出典・確認日
本文の仕様は、以下の一次情報を2026年8月7日に確認して書いています。
- Microsoft Learn「Copilot で最初のクラウド フローを作成する」（できること・手順・プロンプトの型・英語最適化の注意）: https://learn.microsoft.com/ja-jp/power-automate/create-cloud-flow-using-copilot
- Microsoft Learn「Power Automate の Copilot」（Copilotの提供範囲・リージョン別の有効化条件）: https://learn.microsoft.com/ja-jp/power-automate/copilot-overview
リージョンごとの提供条件は変わる可能性があります。導入前に必ず自社テナントの設定を確認してください。当社では半年ごとに記載内容を再確認しています。