合同会社小村ソフト
日本語 English 한국어 繁體中文 العربية
相談する
メニュー

Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計

· · Power Automate, RPA, 業務自動化, デスクトップフロー, クラウドフロー, PowerShell, VBA, Excel, Office, 既存資産活用, 技術相談

「共有フォルダに溜まる CSV を毎朝 Excel にまとめて上長にメールする」「複数の業務システムから値を手作業でコピペして集計する」。こういう作業を Power Automate で自動化したい、という相談を最近よく受けます。

最初の小さなフローは、たいてい数十分で動くようになります。厄介なのはそこから先です。本番で動かし始めてしばらくすると、たまにエラーで止まるようになる。対象システムの画面レイアウトが少し変わっただけでフローが壊れる。パスワードの置き場所が決まらないまま、とりあえず入力変数に直書きしたままになっている。「動くフロー」はあるのに、いざというとき誰も直せない――こういう状態に陥っている案件を何度か見てきました。

Power Automate は学習コストが低く、ノーコード・ローコードで始められます。その手軽さゆえに、設計を後回しにしたまま本番運用に乗ってしまいやすいツールでもあります。この記事では、クラウドフローとデスクトップフローの違い、PowerShell や VBA との役割分担、エラー処理、UI 自動化を安定させる考え方、認証情報の扱い、ガバナンスと運用、そして Power Automate の範囲を超えるタイミングの見極め方まで、実務でつまずきやすい順に書いていきます。

1. まず結論

  • Power Automate には大きく クラウドフロー（コネクタ経由でクラウドサービスをつなぐ）と デスクトップフロー（Windows の画面操作やデスクトップアプリを自動化する RPA）の 2 系統があります。まずどちらが必要かを切り分けるのが最初の設計判断です。
  • 「PC 上の定型作業」を自動化したいだけなら、Power Automate Desktop より先に PowerShell が候補になる場面も多いです。画面のクリックや入力が必須でなければ、PowerShell のほうが保守しやすく、バージョン管理にも乗せやすいことがあります。
  • Power Automate を選ぶ価値が大きいのは、API 連携の少ない既存システムの画面を操作する必要がある場合、あるいは Microsoft 365 のコネクタ（Outlook、SharePoint、Teams など）で通知・承認フローを素早く作りたい場合です。
  • 本番運用に乗せるなら、エラー処理（On Block Error）、UI セレクターの安定化、認証情報の安全な管理、DLP ポリシーによるガバナンスの 4 点は最初から設計に組み込みます。後付けは事故のもとです。12
  • 無人実行（unattended）には、有人実行（attended）とは別のライセンス・前提条件が必要です。ライセンス設計を後回しにすると、検証環境では動いたのに本番で動かせない、という事態になります。34

2. Power Automateの全体像

Power Automate は単一の製品というより、複数の自動化手段をまとめたプラットフォームです。

Power Automateクラウドフローデスクトップフロー / RPAプロセスマイニングAI Builder自動化フローイベントトリガースケジュールフロー定期実行インスタントフロー手動・ボタン起動コネクタSharePoint / Outlook / Teams / SQL など有人実行ユーザーの目の前で実行無人実行サーバー/専用PCで実行UI自動化画面操作・既存アプリ連携
  • クラウドフローは、コネクタを介してクラウドサービス同士をつなぐ仕組みです。トリガーの種類によって、自動化フロー（イベント発生時）、スケジュールフロー（定期実行）、インスタントフロー（手動起動）に分かれます。
  • デスクトップフローは、Windows 上のアプリケーションや画面を直接操作する RPA（Robotic Process Automation）です。クラウドフローから呼び出すことも、単独で実行することもできます。5
  • デスクトップフローはさらに、人が画面の前にいる状態で実行する有人実行（attended）と、専用の PC やサーバー上で人の介在なしに実行する無人実行（unattended）に分かれます。4

無人実行の「専用マシン」とは、ロックされていなければよいという意味ではありません。Windows 10/11 では、接続に使うユーザーかどうかに関係なく、誰かのセッションがロック状態であっても残っていると無人実行は失敗します。Windows Server ではもう少し範囲が狭く、接続に使う同じユーザーのロックされたセッションが残っていると実行できません。保守作業や、別の管理者による RDP 接続のあとに「ロック」や「切断」で済ませてしまいがちですが、確実に全員「サインアウト」しておく必要があります。6

相談を受けるときは、まず「これはクラウドサービス同士をつなぐ話なのか、それとも画面を操作する話なのか」を切り分けるところから始めます。それだけでだいぶ見通しが良くなります。

3. クラウドフロー・デスクトップフロー・PowerShell・VBAの使い分け

同じ「自動化」でも、得意な領域はかなり違います。

観点 クラウドフロー デスクトップフロー PowerShell VBA
実行環境 Microsoft のクラウド Windows PC / サーバー Windows PC / サーバー Office アプリ内
得意な処理 SaaS 間連携、通知、承認 画面操作、レガシーアプリ連携 ファイル操作、バッチ処理、API 呼び出し Office アプリ内の操作・帳票作成
トリガー イベント、スケジュール、手動 クラウドフローから呼び出し、スケジュール タスクスケジューラ、手動 Office アプリのイベント、手動
ロジックの複雑さ 中（コネクタとコネクタを組み合わせる） 中〜低（UI操作が中心） 高（プログラミング言語として柔軟） 高（Office内に閉じる前提で柔軟）
エラー処理 フロー単位の実行履歴で確認 On Block Error、リトライ設定 try/catch、終了コード On Error Resume Next 等（弱め）
ソース管理 エクスポート（zip）で擬似的に可能 エクスポート（zip）で擬似的に可能 Git でテキスト管理しやすい ブック内蔵で管理しにくい
向くケース 承認フロー、通知、SaaS連携、Microsoft 365まわりの業務フロー API のない既存システムの画面操作、レガシーアプリ連携 大量データ処理、定期バッチ、サーバー実行、テストしやすい処理 Excel/Access内で完結する個人〜小規模チームの作業

実務でよくある誤解は、「自動化したい＝とりあえず Power Automate」と考えてしまうことです。すでに API が用意されているシステムを Power Automate Desktop で UI 操作するのは、本来であれば PowerShell や .NET から API を直接叩いたほうが安定する場面です。逆に、API のない古い業務システムや Win32 アプリの画面を操作する必要があるなら、デスクトップフローの UI 自動化が現実的な選択肢になります。

補足: Excel や VBA の制約、置き換えの考え方については、別記事「VBA とは何か - 制約、将来性、置き換えるべき場面と現実的な移行パターン」でも整理しています。Microsoft 365 上の業務フローを Office Scripts と Power Automate で組み合わせるパターンにも触れています。7

4. ライセンスを理解する

Power Automate のライセンスは、ユーザー単位のライセンスと、フロー単位（プロセス）のライセンスに大きく分かれます。3

ライセンスの考え方 主な用途 備考
Microsoft 365 に含まれる権利 標準コネクタを使ったクラウドフロー プレミアムコネクタやカスタムコネクタは対象外のことが多い
Power Automate Premium（ユーザー単位） プレミアムコネクタ、デスクトップフローの作成・有人実行、AI Builder などフル機能 クラウドとデスクトップ自動化をフルに使う前提のライセンス
Power Automate Process（クラウドフロー・標準マシン単位） 無人実行、フローやマシンそのものへのライセンス付与 ユーザーではなく「フロー」や「マシン」にライセンスを紐づける考え方。有人実行だけのライセンスでは無人実行はできない。クラウドフローに Process ライセンスを割り当てられるのは、そのフローがソリューションに含まれている場合だけで、検証段階でよく使う個人用の「マイフロー」のままでは割り当てられない
Power Automate Hosted Process（ホストマシン・ホストマシングループ単位） 物理マシンを管理せずに無人実行する 現時点では Microsoft がホストするマシン・マシングループ向けのライセンスで、標準マシンやクラウドフローに Process ライセンスの代わりとしてそのまま割り当てる動きはまだ一般提供されていない

ここでややこしいのは、ライセンスの考え方が「誰が作ったか」ではなく「どう実行されるか」で決まる点です。自動化フローやスケジュールフローはフロー所有者のライセンスコンテキストで動き、ボタン起動のインスタントフローは呼び出したユーザーのライセンスコンテキストで動きます。無人実行を前提に設計するなら、検証段階でライセンス要件を確認しておかないと、本番移行の直前で詰まります。なお、以前あった「無人実行アドオン（Unattended RPA add-on）」は現在レガシー扱いで、Power Automate Process ライセンスに置き換えられています。既存の無人実行アドオンは Process ライセンスと同等の扱いに引き上げられていますが、新規に割り当てる場合は Process ライセンスを使います。384

注意したいのは、Process / Hosted Process ライセンスだけではユーザーライセンスの代わりにならないことです。マシンへの Process ライセンス割り当て（無人実行に必要)には、そのマシンが Power Automate Premium ライセンスを持つユーザーによって登録済みであることが前提になります。また、クラウドフローから有人実行・無人実行のデスクトップフローを呼び出す場合も、実行に使う接続のユーザーが Premium ライセンス(またはデスクトップフロー権利を含む他のライセンス)を持っている必要があります。Process 容量を確保しただけで運用に必要なユーザーライセンスを見落とすと、機能テストの段階で詰まります。3

5. 実践設計 ── 共有フォルダのCSVを集計してExcel報告書を作り、メールする

具体例として、よくある「日次レポート作成」を題材にします。

やりたいこと

  1. 共有フォルダにある当日分の CSV を集める
  2. 内容を集計して Excel の報告書テンプレートに書き込む
  3. 報告書を所定のフォルダへ保存する
  4. 関係者へメールで通知する
  5. 失敗したら担当者に通知し、原因をログに残す
なしありエラー発生スケジュール起動 06:30On Block Error: 集計処理List files in folder当日分CSVを取得対象ファイルあり?対象なしを記録して終了Read from CSV file1ファイルずつループ値を集計・変数に加算Launch Excelテンプレートを開くWrite to Excel worksheet集計結果を書き込みExcelを保存して閉じるSend an email担当者へ報告書を送信実行結果をログファイルに追記正常終了エラーハンドラExcelが開いたままなら閉じるエラー内容をログに記録管理者へ失敗通知メール異常終了として記録

主なアクションと役割は次の通りです。

アクション 役割 設計のポイント
List files in folder 対象 CSV の一覧取得 ファイル名のパターン、当日分の絞り込み条件を明確にする
Read from CSV file / Read from Excel worksheet データの読み込み ヘッダー行の有無、文字コード（UTF-8 など）を確認する
Set variable / Increment variable 集計値の保持 変数名にデータ型を意識した接頭辞をつけると読みやすい（例: txtPath、numTotal、dtToday、lstFiles）
Launch Excel / Use Excel Excel テンプレートの操作 インスタンスの起動と終了を必ずペアで管理する（終了し忘れると EXCEL.EXE が残る）。このフローは無人実行が前提なので、RPA アカウントに Microsoft 365 Apps for enterprise（unattended）ライセンスがあるかも確認する。これがないと Office が機能制限モードで動き、対話実行時と挙動が変わることがある9
Write to Excel worksheet 集計結果の書き込み セル番地のハードコードを避け、名前付き範囲や見出し検索で位置を特定する
Send an email (V2) / Outlook 関連アクション 結果の通知 添付ファイルはパスをそのまま渡せない。事前に Convert file to binary data アクションでバイナリ化し、Attachments の Name には報告書のファイル名を、ContentBytes にはそのバイナリ変数を設定する10。宛先や件名のテンプレート化も分離する
Write text to file (Append) 実行ログの記録 実行日時、処理件数、結果（成功/失敗）を1行ずつ追記する

フロー全体を 1 つの巨大なアクション列にせず、「ファイル取得」「集計」「Excel書き込み」「通知」「ログ記録」のようにサブフローへ分割しておくと、後からの修正や単体での再実行がしやすくなります。クラウドフロー側でスケジュール起動し、実際の処理は呼び出し先のデスクトップフローに任せる構成も、運用上は扱いやすい形です。5

6. エラー処理を設計する

Power Automate Desktop には、ブロック単位でエラー処理をまとめて設定できる On Block Error アクションがあります。個々のアクションごとに「エラー時の動作」を設定する代わりに、ブロックに含まれる全アクションへ共通のエラー処理を適用できます。1

[On Block Error] 集計処理ブロック
  ├─ List files in folder
  ├─ Read from CSV file（ループ）
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[エラーハンドラ]
  ├─ Get last error アクションでエラー内容(名前・発生場所・該当アクション・詳細メッセージ)を変数として取得
  ├─ Excel のインスタンスが開いたままなら閉じる(失敗時こそ後片付けを省略しない)
  ├─ Write text to file（Append）でログへ記録
  ├─ Send an email（V2）で管理者へ通知
  └─ 「ブロックの最後から再開」または「フロー実行を停止」を選択

ここで押さえておきたいことがいくつかあります。

  • 個別アクションのエラー処理は、ブロック単位のエラー処理より優先されるため、特定のアクションだけ挙動を変えたい場合は個別設定、それ以外は On Block Error にまとめる、という役割分担にします。1
  • 「Retry action if an error occurs」を使うと、一時的なエラー（ネットワーク遅延やファイルロックなど）に対して、指定回数・間隔で自動リトライできます。すべてのエラーをリトライ対象にすると無駄に時間がかかるため、リトライすべきエラーとリトライすべきでないエラー（データ不整合など）を分けて考えます。1
  • エラーハンドラの中で直前のエラー内容を参照したい場合は、Get last error アクションを明示的に置きます。これは、発生したエラーの名前・場所・該当アクション・所属サブフロー・詳細・メッセージという6つのプロパティを持つ変数を返すアクションで、暗黙の変数として自動的に用意されているわけではありません。同じエラー値を後で誤って再利用しないよう、取得後は「Clear error」オプションでクリアしておくと安全です。1
  • ログは「成功/失敗」だけでなく、処理件数、対象ファイル名、エラーメッセージまで残すようにします。後から「なぜ止まったか」を調べる手がかりはログにしかありません。
  • ブロックの後処理として、「ブロックの最後から再開する」か「フロー実行を停止する」かを明示的に選びます。Excel のインスタンスを開いたまま停止すると、次回実行時にプロセスが残ったままになる、といった事故につながるため、エラー時こそ後片付け（インスタンスのクローズ）を意識します。11

PowerShell の try/catch/finally に慣れている場合、On Block Error の「ブロック」は try、エラーハンドラは catch、後片付けの処理列は finally に近いイメージで捉えると設計しやすくなります。

7. UI自動化を安定させる

デスクトップフローが不安定になる最大の原因は、多くの場合「UI要素の特定方法（セレクター）」にあります。

  • 既定では、UI要素ピッカーが画面の要素を セレクター（属性の組み合わせ）として記録します。アプリのバージョンアップや表示内容の変化に弱い属性（連番のインデックスや動的なIDなど）が含まれていると、見た目が同じでもフローが壊れます。12
  • 値が変化する属性は Equals ではなく Contains や正規表現に変更し、前のアクションの結果に依存する値は変数化することで、より動的で壊れにくいセレクターになります。12
  • 複数のセレクターを設定しておくと、最初のセレクターが失敗した場合に次のセレクターへ自動的にフォールバックします。重要な操作には予備のセレクターを用意しておくと安定性が上がります。12
  • セレクターが壊れた場合は、Repair selector 機能で自動的に修復候補を生成できます。手動で1から作り直す前に、まず試す価値があります。12
  • 画面遷移やアプリの起動には時間差があります。固定の Wait だけに頼らず、「ウィンドウを待機する」「UI要素が見つかるまで待機する」といった条件待機のアクションを組み合わせ、UI要素が見つからない場合の自動リトライも合わせて設定します。13
  • どうしても安定しない自動化対象（仮想化された画面、頻繁にレイアウトが変わる画面など）については、UI操作に固執せず、API・ファイル連携・データベースアクセスなど、より安定した連携方法がないかを先に確認します。

UI 自動化を最初に動かすこと自体は難しくありません。半年後も壊れずに動いているかどうかは、ほぼセレクターの作り方だけで決まります。

8. 認証情報を安全に扱う

業務自動化でもっとも事故が起きやすいのが、認証情報（パスワード、APIキー、接続文字列など）の扱いです。

  • パスワードや接続情報を、フローの入力変数にそのまま値として書き込むのは避けます。Get credential アクションを使うと、Azure Key Vault や CyberArk を裏側のシークレットボキャブラリとした「Power Automate の資格情報」から認証情報を安全に取得でき、取得した値は機密情報としてマークされ、フローの実行ログにも残りません。1415
  • Azure Key Vault をシークレットの保管場所として使う場合、Power Automate 側で Key Vault への接続情報を1か所にまとめて管理できるため、認証情報をフローごとに分散させずに済みます。15
  • 無人実行用のアカウントは、利用範囲を必要最小限にした専用アカウントを用意し、人が日常使うアカウントと兼用しないようにします。アカウントが持つ権限が広いほど、フローの不具合や設定ミスが及ぼす影響範囲も広がります。
  • 「動かすために一時的に」と平文でパスワードを入力変数に書いたまま検証を進めると、そのまま本番に残ってしまいがちです。検証段階から Get credential アクションを使う癖をつけておくほうが安全です。

9. ガバナンスと運用

個人やチーム単位で作ったフローが増えてくると、次は組織としての統制が必要になります。

  • データ損失防止（DLP）ポリシーは、フローやアプリで使えるコネクタを「業務データ専用」「業務データ利用不可」「ブロック」などに分類し、業務データ用コネクタと業務データ利用不可のコネクタを同じフロー内で組み合わせられないようにする仕組みです。組織のデータが意図せず外部サービスへ流出することを防ぐ、最初に整備すべきガバナンスです。16
  • デスクトップフローのアクションも同じ DLP ポリシーの枠組みで分類・ブロックできますが、これは既定では有効になっていません。Power Platform 管理センターのテナント設定で「Show desktop flow actions in DLP policies」を一度オンにする必要があり、この設定は後から元に戻せません。有効化したあとも、ポリシーで明示的に分類したモジュール・アクションだけが制御対象になるため、「DLP ポリシーを作った＝デスクトップフロー全体が統制下にある」とは限らない点に注意します。2
  • 無人実行用のマシンは、マシングループとしてまとめて管理し、どのフローがどのマシンで実行されるかを明確にしておきます。
  • 実行履歴は Power Automate の管理画面・実行履歴から確認できます。失敗時のアラート（Teams通知やメール通知）を、フロー自身の処理として組み込んでおくと、誰かが手動で確認しに行かなくても異常に気づけます。
  • 社内ネットワーク内のデータベースやファイル共有など、クラウドから直接アクセスできないオンプレミスのリソースをクラウドフローから扱いたい場合は、オンプレミスデータゲートウェイを使います。ゲートウェイはクラウド側からの受信ポート開放を必要とせず、送信方向の接続だけで安全にデータを橋渡しします。17
  • 検証用と本番用で環境を分け、デスクトップフローや接続情報を環境ごとに切り分けておくと、検証中の変更が本番フローに影響することを防げます。

10. Power Automateの限界とエスカレーション基準

Power Automate は強力ですが、万能ではありません。次のような状況では、PowerShell や .NET アプリへの切り替えを検討します。

状況 判断 理由
数十万行規模のデータ処理が必要 PowerShell やバッチ処理アプリへ デスクトップフローのループ処理は大量データには向かない
複雑な業務ロジックがあり、自動テストを書きたい .NET アプリへ フロー自体の単体テストは難しく、ロジックが複雑になるほど検証コストが上がる
高頻度・低レイテンシでの常駐処理が必要 Windows サービス / Generic Host + BackgroundService へ フローの起動・実行コストはリアルタイム処理には不向き
操作対象のシステムに API が用意されている API を直接呼ぶ実装へ UI 操作よりも API 連携のほうが安定し、保守コストも下がる
操作対象画面のレイアウトが頻繁に変わる UI 自動化を避け、代替手段を検討 セレクターの保守コストが運用コストを上回る
ソースコードでの厳密な変更履歴・レビューが必須 Git 管理できる PowerShell / .NET へ フローのエクスポート（zip）は擬似的なバックアップにはなるが、コードレビューには向かない

「Power Automate で作ったものが育って複雑になりすぎた」と感じたときは、無理にフローを拡張し続けるより、コア処理を .NET や PowerShell に切り出し、Power Automate はトリガーと通知に専念させる構成へ寄せたほうが、結果的に保守しやすくなることが多いです。PowerShell によるログ調査・アーカイブ自動化の実例は、別記事「PowerShellスクリプト応用 ── ログ調査・アーカイブ・レポート化を安全に自動化する」でも紹介しています。

11. まとめ

Power Automate は、最初の一歩までは驚くほど簡単です。ただ、その手軽さは裏を返すと「設計を端折ってもいったん動いてしまう」ということでもあります。本番に出したフローを長く保守できるかどうかは、最初にどれだけ地味な判断を済ませておけるかでほぼ決まります。

クラウドフローとデスクトップフローのどちらを使うか、PowerShell や .NET に任せたほうがよい処理はどれか。この切り分けを最初にやっておくと、後からの手戻りはかなり減ります。エラー処理、UI セレクター、認証情報、ライセンス、DLP ポリシーは、いずれも「動いてから直す」より「最初から組み込む」ほうが圧倒的に安く済みます。そして、フローが育って複雑になってきたときに、無理に拡張せず .NET や PowerShell へ処理を逃がす判断ができるかどうかも、長く使い続けられるかを左右します。

「とりあえず動くフロー」と「安心して任せられるフロー」の間には、これだけの設計の差があります。既存の業務システムや Excel / VBA 資産が絡む自動化ほど、最初の設計判断が後々の保守コストを大きく左右します。

関連記事

関連する相談領域

合同会社小村ソフトでは、既存の Excel / VBA / Windows 業務資産を残しながら段階的に自動化・モダナイズする相談や、Power Automate を含む自動化基盤の設計レビューを扱っています。

参考リンク

  1. Microsoft Learn, Handle errors in desktop flows. On Block Error によるブロック単位のエラー処理、個別アクションとの優先順位、リトライ設定について。 ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, Data loss prevention (DLP) policies. デスクトップフローに対する DLP ポリシーの適用、業務/非業務分類とブロックの仕組みについて。 ↩ ↩2

  3. Microsoft Learn, Types of Power Automate licenses. ユーザー単位・フロー単位ライセンスの種類と、自動化フロー/インスタントフローでのライセンスコンテキストについて。 ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Attended and unattended scenarios for process automation. 有人実行と無人実行の違い、それぞれに必要なライセンスや実行形態について。 ↩ ↩2 ↩3

  5. Microsoft Learn, Trigger desktop flows from cloud flows. クラウドフローからデスクトップフローを呼び出す構成について。 ↩ ↩2

  6. Microsoft Learn, Run unattended desktop flows. Windows 10/11 では誰かのセッションがロック状態でも残っていると無人実行が失敗すること、Windows Server では接続ユーザー本人のロックされたセッションが対象になること、ロック・切断ではなくサインアウトが必要なことについて。 ↩

  7. Microsoft Learn, Run Office Scripts with Power Automate. Office Scripts と Power Automate を組み合わせた自動化、および必要ライセンスについて。 ↩

  8. Microsoft Learn, Deep dive on specific licenses. Power Automate Premium、Process、Hosted Process ライセンスの詳細について。 ↩

  9. Microsoft Learn, Overview of the unattended robotic process automation with Microsoft 365 Apps for enterprise. Microsoft 365 Apps for enterprise（unattended）ライセンスがない場合、無人実行で使う Office アプリが機能制限モードで動作することについて。 ↩

  10. Microsoft Learn, Office 365 Outlook actions reference. Send an email (V2) で添付ファイルを送る際は Convert file to binary data でバイナリ化し、Name / ContentBytes として渡す必要があることについて。 ↩

  11. Microsoft Learn, Employ robust error handling. エラー処理を設計する際のガイドライン。 ↩

  12. Microsoft Learn, Build a custom selector. セレクターを動的にする方法、複数セレクターによるフォールバック、Repair selector について。 ↩ ↩2 ↩3 ↩4

  13. Microsoft Learn, Automate using UI elements. UI要素の指定方法と、待機・リトライの考え方について。 ↩

  14. Microsoft Learn, Secure your data. Get credential アクションによる認証情報の安全な取得と、実行ログへの非出力について。 ↩

  15. Microsoft Learn, Create an Azure Key Vault credential. Azure Key Vault をシークレットの保管場所として使う設定について。 ↩ ↩2

  16. Microsoft Learn, Data policies. コネクタの分類（業務データ専用/業務データ利用不可/ブロック）によるガバナンスの考え方について。 ↩

  17. Microsoft Learn, On-premises data gateway. オンプレミスデータとクラウドサービスを安全に橋渡しする仕組みについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る