朝、担当者が出社すると、夜間に動くはずだった日報の転記が止まっていた。原因を調べると、基幹システムの画面が更新されて、ボタンの名前と位置が少し変わっていた。

画面を操作する型のRPAを使っている会社には、覚えのある朝かもしれません。業務の手順は何も変わっていないのに、画面の部品の名前が変わっただけで、フローは要素が見つからないと言って止まります。直すのは人で、直すまでの間、転記は手作業に戻ります。

Power Automateは、この止まり方に対して、フローが自分で直して続ける仕組みを入れ始めました。2026年3月から順次展開された自己修復（プレビュー）です。

Microsoftの2026年リリースウェーブ1の概要は、デスクトップの自動化がAIエージェントと自己修復で賢く、強くなる、と書いています。

この記事は、自己修復がどう動くか、何を外部に渡すか、直した結果をどう扱うかを、2026年11月2日時点の公式資料で整理します。

そのうえで、RPAが自分で直す時代に、人が持ち続ける判断はどこかを書きます。読者は、Power Automateのデスクトップフローを運用している情報システムの担当者と、製造や食品の現場で日報や記録の転記を自動化している、またはこれからする業務部門のリーダーです。

ライセンスと費用の全体像はPower Automateライセンス2026。付属で足りる線と11月の変更に書きました。

結論を先に書きます。

  1. 自分で直す仕組みは3つあり、役目が違います。 実行中に要素が見つからないときにAIが代わりの要素を探して続ける自己修復（プレビュー）、デザイナーの中でデバッグしながら壊れたセレクターを直すAI支援のUI自動化修復（プレビュー）、そして以前からある実行時のCopilotによる修復で、最後の1つは非推奨の予定になりました
  2. 自己修復は実行時だけの仕組みで、直した結果を保存しません。 画面が変わったままのフローは、人が直すまで、実行のたびにAIが探し直すことになります。止まらないことと、直ったことは別です
  3. 動かす前に、管理者が4つの設定を入れます。 AnthropicをMicrosoftの下請け処理者として許可する、Power Platformで外部モデルを許可する、リージョンをまたぐデータの移動を許可する、Power AutomateのCopilotをオンにする。自己修復が画面のスクリーンショットを外部のモデルに渡す以上、ここは情シスの判断です
  4. 人が持つ判断は4つです。 どの操作で自己修復を許すか、直した結果を次回に残すか、修復の記録を誰が見るか、画面の何を外部のモデルに渡してよいか。エージェントフローとコンピューター操作にも、同じ形で人の判断を置く場所があります

自分で直す、には3つの意味がある

Power Automateで自分で直すと言うとき、2026年11月時点では3つの機能が混ざります。先に分けます。

機能 どこで動くか 何をするか 状態（2026年11月2日）
自己修復（Self-healing） 実行時。コンソールとクラウドからの有人・無人の実行 要素が見つからないときに、AIが代わりの要素を探して、その実行を続ける。保存しない プレビュー。Power Automate for desktop 2.66以上。追加費用なし
AI支援のUI自動化修復（AI-assisted UI automation repair） デザイナーの中。デバッグ実行 セレクターが合わなくなった要素を見つけ、人が要素を取り直すとAIが代わりのセレクターを提案する。提案を受け入れてフローを保存すると、以後の実行に反映される プレビュー。2.70で導入。ロードマップでは一般提供が2027年3月の予定
実行時の修復（Repair flow errors） 実行時。クラウドフローから開始した実行だけ。有人は通知ウィンドウ、無人はAutomation Centerの推奨 Copilotが要素を探し、人がその場で承認する。有人は今回だけか毎回かを選べ、無人は今回だけ プレビュー。米国リージョンのみ。2.73で名前に「非推奨の予定」が付いた

1つ目の自己修復は、2026年3月のバージョン2603（2.66）でプレビューとして入りました。2025年リリースウェーブ2の計画では、UIとウェブの自動化アクションの自己修復エージェント、という名前で、公開プレビューが2026年3月31日です。

リリースノートの言葉では、取り込んだ要素が実行時に見つからないときに、UIとブラウザーの自動化をより強くする、エラー処理の軽い予備の仕組みです。

2つ目のAI支援のUI自動化修復は、2026年7月のバージョン2607（2.70）でデザイナーに入りました。フローをエージェント支援のモードでデバッグし、取り込んだセレクターが対象の要素と合わなくなったことを検出し、人がその要素を取り直すと、AIが生成した代わりのセレクターを提案します。

提案はその場でテストでき、要素ごとに受け入れるか飛ばすかを選びます。受け入れたセレクターはUI要素の一覧に追加され、フローを保存すると次の実行から反映されます。

8月の2608では、選んだアクションから修復モードで実行を始める右クリックの項目、取り直しのときに要素の選択ウィンドウを出す改善、生成したセレクターにAI生成セレクターという名前を付ける改善、提案した修復はフローを保存するまで未保存の版に置かれるという説明が足されました。

Microsoft 365ロードマップのID 577869は、この機能を公開プレビュー2026年7月、一般提供2027年3月の予定と書いています。

3つ目は、2024年12月のバージョン2.51から入っていた実行時の修復です。対象は、クラウドフローから開始したデスクトップフローの実行に限られます。

有人の実行ではRepair with Copilotの通知ウィンドウが出て、Copilotが要素を探し、人が今回だけ適用するか、毎回に適用するかを選びます。

無人の実行はマネージド環境だけが対象で、Automation Centerの推奨に修復の依頼が届き、10分以内に人が対応します。

無人では今回だけの適用しかできず、新しいセレクターをフローに保存することはできません。この機能は米国リージョンだけで提供されていて、2026年10月のバージョン2610のリリースノートで、フローのプロパティの名前がRepair flow errors（非推奨の予定）に変わりました。これから設計するなら、1つ目と2つ目を前提にします。

自己修復はどう動くか

自己修復の公式ページ（2026年10月28日付）の説明を、順番どおりに書きます。

要素が見つからないときに、Power Automate for desktopが処理する順番。再試行、自己修復、変数の設定とサブフローの実行のルール、続行かエラーの順に進み、自己修復が成功すればそのまま続き、失敗すれば通常のエラー処理に戻る

きっかけは2種類のエラーです。 対応するUIまたはブラウザーの自動化アクションが、要素が見つからない（Element not found）か、ウィンドウが見つからない（Window not found）で失敗したときだけ働きます。

要素が見つからないは主画面と副画面の両方で、ウィンドウが見つからないは主画面にウィンドウがあるときだけ拾います。

順番が決まっています。 アクションごとのエラー処理は、再試行のポリシー、自己修復、変数の設定とサブフローの実行のルール、フローの続行かエラーを出す、の順に評価されます。自己修復は再試行の次です。再試行で見つかれば自己修復は動きません。

何を渡すか。 自己修復が呼ばれると、Power Automate for desktopは、見つからなかった要素のスクリーンショット、その親ウィンドウのタイトル、デスクトップ全体の画像を取り込みます。

それをもとに、意図されていた要素として最も可能性が高いものを特定し、セレクターを取り直します。公式ページは、GPT-4.1 miniとClaude Sonnet 4.5の2つの大規模言語モデルを組み合わせて使っている、と書いています。

成功すれば続き、失敗すれば戻ります。 修復に成功すればフローはそのまま続きます。失敗すれば、通常のエラー処理に戻ります。つまり自己修復は、再試行の次に挟まる予備の手で、エラー処理を置き換えるものではありません。

実行時だけの仕組みです。 コンソールからの実行と、クラウドからの有人・無人の実行に適用され、デザイナーからの実行では働きません。

そして、ここが大事なところですが、自己修復は直した結果を保存しません。 実行時に使ったAI生成のセレクターはログに残りますが、フローのUI要素は書き換わりません。

公式ページは、必要なフローの調整のために後で人が手を入れるまでの間、エラーの発生率を下げる、という言い方をしています。

画面が変わったままで同じエラーが出続けるフローは、人が直すまで、実行のたびにAIが探し直すことになります。

止まらないことと、直ったことは別です。

対象のアクションは限られます。 機能ページによると、ボタンをクリックする、チェックボックスを選ぶ、のように1つのUI要素とやり取りする特定のアクションだけが対象で、ウィンドウ内でUI要素をドラッグアンドドロップする、のように複数の要素を扱うアクションは対象外です。

ウィンドウや画面を扱うアクションについては、10月28日付の機能ページは対象外としていますが、8月のバージョン2608のリリースノートはウィンドウ操作のアクションにも対応した、と書いていて、資料の間で食い違いがあります。

ウィンドウ操作のアクションで使うなら、自社のバージョンとアクションごとに、実際に試して確かめてください。

費用と提供範囲。 組織のプレミアムアカウントで追加費用なしに使えます。政府向けクラウドとソブリンクラウド（特定の国や地域の規制に合わせて分離されたクラウド）では使えません。

日本リージョンを含む一般の商用クラウドは、この対象外の区分には入りません。公式ページには、生成AIを使うので、意図しないUI要素を特定することがある、という一文があります。

動かす前に、管理者が入れる4つの設定

自己修復は、現場の担当者がアクションの設定で有効にするだけでは動きません。公式ページが挙げる管理者の設定は4つで、すべてが有効になっている必要があります。

すでに有効になっているものもあるので、1つずつ現在の状態を確かめます。

  1. Microsoft 365管理センターで、AnthropicをMicrosoftの下請け処理者として有効にする。 CopilotのSettingsにあるAI providers operating as Microsoft subprocessorsの項目です。公式ページの補足によると、商用クラウドのほとんどの顧客ではMicrosoftがデフォルトで有効にしていますが、EUとEFTA、英国は除きます。日本のテナントがどちらに入るかは、自社の管理センターの表示で確かめてください
  2. Power Platform管理センターで、外部モデルとしてAnthropicを環境または環境グループの単位で有効にする。 CopilotのSettingsのExternal modelsの項目です
  3. Power Platform管理センターの環境の設定で、リージョンをまたぐデータの移動を許可する。 Generative AI featuresの編集画面にあるMove data across regionsのチェックです。米国のクラウドリージョンでは表示されず、不要です。日本リージョンの環境では、ここを入れないと動きません
  4. Power Platform管理センターで、Copilot in Power AutomateをOnにする。 CopilotのSettingsのPower Automateの節です

そのうえで、Power Automate for desktopがバージョン2.66以上であること、そしてアクションごとにError handlingの設定でSelf-healing (Preview)をオンにすることが要ります。

対象のアクションには、デザイナーでアクションにマウスを乗せると自己修復が使えることを示す印が出ます。フロー全体で一括してオンにする設定はありません。アクションごとに人が決める設計になっています。

4つの管理者設定のうち、1から3はデータの行き先の話です。自己修復は、見つからなかった要素のスクリーンショットだけでなく、デスクトップ全体の画像を取り込みます。

その画面に顧客名や金額や個人の情報が映っていれば、それが外部のモデルに渡ります。

設定を入れる前に決めること

どの機械で、どの画面を映した状態で自己修復を動かすか。情シスが4つの設定を入れる前に、業務部門と決めておきます。

製造・食品の日報で考える

製造や食品の会社では、日報や記録の転記にデスクトップフローを使う場面があります。製造日報をExcelから基幹システムへ転記する仕事で考えます。

現場で紙に書いた製造日報を、事務の担当者がExcelに入力し、Excelの行を夜間にデスクトップフローが基幹システムの画面に転記する。

基幹システムは古く、APIもファイルの取り込み機能もないので、画面を操作するしかない。フローの中身は、ログイン、日付の入力、製品コードの選択、数量の入力、特記事項の貼り付け、確認ボタン、登録ボタン、の繰り返しです。

このフローは、基幹システムの更新で画面の部品の名前が変わると、転記先を見つけられずに止まることがあります。自己修復はここに効果があります。

製品コードの選択や数量の入力欄が見つからなくなっても、AIが画面を見て、それらしい欄を探して続けます。翌朝、転記は終わっていて、ログに自己修復の記録が残る。これが狙いどおりの形です。

ただ、すべてのアクションで自己修復をオンにするのが正しいかというと、当社はそう考えていません。この例なら、当社は次のように分けます。

  • オンにする候補: 日付の入力欄、製品コードの選択、数量の入力欄、特記事項の貼り付け先、画面の移動のボタン。間違った欄に入れても、登録前に気づけて、戻せる操作です
  • オフにする操作: 登録ボタン、削除ボタン、確定や送信のボタン。AIが意図しない要素を特定することがある、と公式ページが書いている以上、やり直しが利かない操作で代わりの要素を押させるのは避けます。ここが見つからなければ、アクションのエラー処理をエラーを出す設定（デフォルト）のままにして止め、人が見ます

オフにするのは修復だけで、登録ボタンが通常どおり見つかれば、登録はそのまま進みます。転記した内容を人が確認する手順は、自己修復とは別に設けます。

登録の前にフローを一時停止して人が見るか、翌朝に登録済みの内容を人が確かめるか、業務に合わせて決めます。翌朝の確認でよいのは、登録した後でも訂正できる業務に限ります。

候補と書いたのは、入力の操作でも、入れた時点で自動保存する画面や、AIが別のボタンを選んだときに影響が変わる操作があるからです。

間違った要素を操作したときの影響、入力時の自動保存の有無、登録前の確認方法まで見て、影響を抑えて戻せるアクションだけをオンにします。

食品製造の衛生記録と製造日報の記事で、温度と適否の値をAIに書かせない、と書いたのと同じ考え方です。転記の手は自動化し、記録の中身の確認は人が持ちます。

もう1つ、この例で人が持つのは、ログを見る当番です。自己修復が成功すると、フローは止まりません。止まらないので、画面が変わったことに誰も気づかないまま、実行のたびにAIが探し直す状態が続くことがあります。

公式ページには、Power Automateのポータルは今のところ実行のアクション単位のログに自己修復の詳細を出さず、デスクトップフローの実行のページに、その実行の自己修復の概要（成功した修復の最大3件まで）を出す、と書いています。

7月のバージョン2607からは、各実行で自己修復が有効だったかと成功した修復の数がポータルに出るようになり、8月の2608からは試行の総数も出ます。

機械にあるローカルのログを残すレジストリ設定を使えば、アクションのログにrepairWithAIInfoという項目が付き、修復を試みたか、成功したか失敗したか、実行時に使ったAI生成のセレクターが分かります。

この例で人が持つ2つの仕事

登録・削除・送信の操作は自己修復をオフにして、見つからなければ止めて人が見る。そして週に1回、自己修復が動いた実行を一覧して、画面が変わった箇所をデザイナーのAI支援の修復で直す。この当番か、それに代わる通知の仕組みを決めておかないと、自己修復は問題を隠す仕組みになりかねません。

エージェントフローとコンピューター操作は、別の答え

RPAが自分で直す、と聞いて思い浮かべるものには、もう1つの方向があります。決められた手順を直すのではなく、AIに画面を見せて、画面の状態に合わせて操作を選ばせる方向です。

Copilot Studioのコンピューター操作（computer use）がそれで、同じCopilot Studioの中にあるエージェントフローとは性格が違います。

Power Automateの自動化を、どこで作るかと誰が直すかの2軸で4つに位置づけた図。横軸はPower Automate for desktopで作るかCopilot Studioで作るか、縦軸は止まったら人が直すかAIが探して続けるか。従来のデスクトップフロー、自己修復つきのデスクトップフロー、人の承認を挟むエージェントフロー、コンピューター操作の4つ

エージェントフローは、ルールどおりに動きます。 Copilot Studioの公式ページ（2026年10月26日付）は、エージェントフローは決定的で、ルールに基づく経路でアクションを実行し、同じ入力は常に同じ出力を生む、と書いています。

決まっているのは条件と順序で、途中に組み込んだAIの文章生成の結果や、人の承認の結果まで毎回同じになるという意味ではありません。

アクションの種類には、文章の生成や文書の処理のようなAIの機能、承認の依頼や情報の提供を求める人の介在（Human in the loop）、ループと分岐のような組み込みの道具、コネクタがあります。

つまりエージェントフローは、手順は人が決め、途中にAIの一手と人の承認を置ける、Power Automateのクラウドフローに近い仕組みです。

止まったときに自分で直す機能は、この記事を書いている時点の公式ページには書かれていません。容量の面では、環境の前払いのCopilot Studio容量を使い切り、従量課金も設定していないと、新しい実行がブロックされ、実行中のものは完走します。

Microsoft 365 Copilotのライセンスを持つ利用者がエージェント経由で呼び出した実行と、デザイナーやテストチャットからのテスト実行は、このブロックの対象になりません。

スケジュールなど他のトリガーで動く実行は、ライセンスの有無にかかわらず対象です。エージェントフローの費用と、Copilot Studioで何が作れるかは、Copilot Studioで自動化。できること、費用、11月の予定に書きました。

人の承認を置く場所は、さらに増える予定です。Microsoft 365ロードマップのID 570672は、Work IQの人の介在として、エージェントとエージェントフローが続行の前に人の入力や承認のために一時停止できるようにする、という項目で、公開プレビュー2026年11月、一般提供2027年1月の予定です。

コンピューター操作は、AIが画面を見て決めます。 Copilot Studioのツールの1つで、Windowsのコンピューター上で、画面のボタンを選び、メニューを選び、欄に文字を入れて作業します。

公式ページ（2026年10月20日付）は、AIで動くので画面の変化に適応し、ボタンや画面が変わってもフローを壊さずに動き続ける、と書いています。

自己修復が決められた手順の穴を埋めるのに対して、コンピューター操作は、自然言語の指示と画面の状態をもとに、AIが具体的な操作を選びます。

人が詳しい手順を指示に書くこともできますが、画面のどこを押すかを決めるのはAIです。その代わり、同じ入力で同じ出力が返る保証はありません。

費用は1ステップ5 Copilot Credits、プレミアムのモデルなら15で、モデルはOpenAIのComputer-Using AgentとGPT-6 Sol、AnthropicのClaude Sonnet 4.5が一般提供、Claude Sonnet 4.6とOpus 4.6が実験段階です。

コンピューター操作にも、人の判断を置く場所があります。人の監督（Human supervision）の設定で、エージェントが確認や追加の情報を必要としたときに、Outlookのメールで指定した人に確認を送ります。

受け取れる人には制約があり、確認の依頼を受け取り詳細なログを見られるのはツールを作った人で、利用者の資格情報で動かす設定では、接続を設定した人が指定の確認者に含まれている必要があります。

業務の担当者に届ける設計にするなら、使う資格情報と受け取りの条件を先に確かめます。ただし公式ページは、この確認は確率的なAIモデルの挙動で起きるので、人が止めてほしい場面で必ず起きるとは限らず、不要な場面で起きることもある、人の確認を安全装置や保証として当てにしないでほしい、と明記しています。

さらに、監督を切っても完全に自律にはならず、確認が要るときに送り先がなければ実行は失敗する、とも書いています。

コンピューター操作を使う機械は専用にし、アカウントの権限を最小にし、開いてよいサイトとアプリを許可リストで絞るのが、公式が勧める守り方です。

4つを並べると、こうなります。従来のデスクトップフローは、ルールどおりに動き、止まったら人が直す。自己修復つきのデスクトップフローは、ルールどおりに動き、見つからない要素はAIが探して続け、保存は人がする。

エージェントフローは、ルールどおりに動き、途中に人の承認とAIの一手を置ける。コンピューター操作は、AIが画面を見て決め、確認が要るときに人に聞く。

どれが良いかではなく、仕事の性質で選びます。毎晩同じ手順で基幹に転記する仕事は、ルールどおりに動く側に置き、自己修復で止まりにくくするのが、2026年11月時点では妥当だと当社は考えています。

人が持つ判断は4つ

ここまでを、人が持ち続ける判断として4つにまとめます。

RPAが自分で直す時代に人が持つ4つの判断。どの操作で自己修復を許すか、直した結果を次回に残すか、修復の記録を誰が見るか、画面の何を外部のモデルに渡してよいか

1. どの操作で、自己修復を許すか。 自己修復はアクションごとにオンにします。間違った要素を操作しても影響を抑えて戻せる入力と画面の移動はオンに、登録・削除・送信のようなやり直しが利かない操作はオフにする。

この表を、フローを作る人ではなく、業務の責任を持つ人と一緒に決めます。何がやり直せて、何がやり直せないかは、業務を知っている人にしか分からないからです。

2. 直した結果を、次回に残すか。 自己修復は保存しません。残すには、デザイナーで人が要素を取り直すか、AI支援の修復の提案を受け入れて、フローを保存します。

画面の変更が恒久的なら残し、一時的な表示の乱れなら残さない。この判断も人のものです。残さないまま放置すると、同じエラーが出るたびにAIが探し直し、探し損ねた実行は通常のエラー処理に戻ります。

3. 修復の記録を、誰が見るか。 止まらなくなった分、気づく仕組みが要ります。デスクトップフローの実行のページの自己修復の概要と、ローカルのログのrepairWithAIInfoを、誰が、どの頻度で見るかを決めます。見る人がいない自己修復は、画面の変更を隠します。

4. 画面の何を、外部のモデルに渡してよいか。 自己修復はデスクトップ全体の画像を取り込みます。4つの管理者設定を入れるのは情シスですが、その画面に何が映るかを決めるのは業務部門です。

顧客情報が映る画面で動かすフローと、社内の集計表だけが映るフローで、同じ判断にはなりません。無人の実行に使う機械の画面に、関係のないウィンドウを開いたままにしない、という運用も、この判断に含まれます。

4つに共通するのは、フローを作る人だけでは決められない、という点です。自己修復はPower Automateの設定画面でオンにできますが、どこでオンにするかは業務の判断で、ログを見る当番は組織の判断で、何を外部に渡すかは会社の判断です。

RPAが自分で直す時代に人が持つ判断は、技術の判断ではなく、この3つの層の判断です。

注意点

プレビューです。 自己修復もAI支援の修復もプレビューで、公式ページは仕様が変わりうると書いています。本番の無人実行で使うなら、まず自己修復をオンにしたアクションを数個に絞り、ログに何が残るかを見てから広げてください。

英語に最適化されています。 Power AutomateのCopilot系の機能について、公式ページには、英語に最適化され、他の言語への対応は限定的で、一部が英語で表示されることがある、と書かれているものがあります。

自己修復とAI支援の修復の言語の条件は、それぞれの機能のページで確かめてください。この記事のUIの名前は英語の公式ページの表記です。

自己修復は、単一の要素を扱うアクションだけです。 複数の要素を扱うアクションでは動きません。対象のエラーも、対応するアクションで起きるElement not foundとWindow not foundだけで、接続の期限切れのようにそれ以外のエラーで止まったフローには、自己修復は関係ありません。止まる原因の内訳を先に見てください。

古い実行時の修復に設計を依存させないでください。 Repair flow errorsは米国リージョンだけで提供され、2.73で非推奨の予定の表示が付きました。

日本の環境では最初から対象外ですが、海外の資料や過去の記事で見かけた手順をそのまま持ち込まないように注意が要ります。

Microsoftの計画の出し方が変わりました。 2026年リリースウェーブ1の計画のページは、2026年10月にアーカイブされ、更新されなくなりました。

今後の予定は、AI at Workのロードマップで項目のIDを追います。この記事で書いたID 577869とID 570672の予定は、Microsoftの表記で、遅れることがあります。

KOIYALの見解

自己修復は、人が直すまでの時間を稼ぐ仕組みです。当社はそう捉えています。止まらない夜が増えることは現場にとって大きな前進ですが、直ったわけではない。

画面が変わったという事実は残り、誰かがデザイナーで直すまで、同じエラーが出るたびにAIが探し直します。この仕組みを、直す人を減らすために入れるのか、直す人が落ち着いて直せる時間を作るために入れるのか。当社は後者だと考えています。

当社が気にしているのは、自己修復をオンにしたフローが社内に増えたときに、オンにする操作とオフにする操作の判断が、フローを作った人の頭の中にしか無い状態です。

作った人が異動すると、なぜこのボタンだけオフなのかを誰も説明できなくなります。だから当社は、FDE型支援で入る会社には、フローの一覧に、アクションごとに自己修復をオンにした理由とオフにした理由を1行ずつ書く欄を足すことを勧めます。

やり直せるからオン、登録だからオフ、という短い理由で十分です。この表があれば、2本目のフローを自社の担当者が作るとき、同じ判断を自分でできます。

自社でできるようになること

インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）の観点で言えば、自社でできるようになってほしいのは、フローを作ることより、この判断の表を自社で持ち、直す当番を自社で回すことです。

フローの作り方は道具が変わるたびに変わりますが、どの操作ならAIに任せてよいかの判断の仕方は、道具が変わっても残ります。自己修復の導入は、その判断を会社として決め直す機会になります。

次の行動

  1. 止まった原因の内訳を出す。 直近3か月に止まったデスクトップフローの実行を一覧し、要素が見つからないが原因だったものを数えます。ここが多いフローが、自己修復の候補です
  2. 候補のフローで、アクションを2つに分ける。 間違った要素を操作しても影響を抑えて戻せる入力と移動、やり直しが利かない登録・削除・送信。前者だけ自己修復をオンにし、理由を1行ずつ書きます。入力時に自動保存する画面は、前者に入れません
  3. 情シスと4つの設定とログの当番を決める。 下請け処理者、外部モデル、リージョンをまたぐデータの移動、Copilot in Power Automateの4つを入れる前に、そのフローが動く機械の画面に何が映るかを確かめ、自己修復の記録を週に1回見る人を決めます

2のアクションの分け方を、自社のフローで一緒にやりたい会社は、FDE型支援の初回の打ち合わせで、いま動いているデスクトップフローの一覧をもとに進めます。

お問い合わせの本文に、フローの本数と、要素が見つからないで止まった回数を書いていただければ、初回の前に当社で、オンにする操作とオフにする操作の表の叩き台を作ります。

参考