「Power Automate」はここを押さえて 扱いやすいデータ形式と望ましい運用体制

Web APIを使って外部サービスなどと連携させる場合、まず考えるべきことは「どのデータ形式での受け渡しが最適か」だ。CSV、XML、JSONが代表的な形式だが、Power Automateで扱いやすいデータ形式はどれか。

[大川貴志，内田洋行ITソリューションズ]

　前回は「Microsoft Power Automate」でWeb APIを利用するためのHTTPアクション、カスタムコネクター、そしてオンプレミスの資産を利用するために必要なオンプレミスデータゲートウェイの使い方について説明しました。最終回となる今回はデータの取り扱い方法とPower Automateの運用、構成、体制づくりについて解説します。環境などによって最適な構成が異なる可能性があるため、あらかじめご了承ください。

著者プロフィール：大川貴志（内田洋行ITソリューションズ）

2011年、内田洋行ITソリューションズに入社。システム開発本部 ATD 技術推進課所属。「Microsoft Graph」を用いた社内システムの改善や、「Microsoft Azure」のPaaSを活用した各種ソリューションの設計、構築、開発を担当する。主な役割は、新技術の検証や新規サービスの開発、Azure導入のサポートなど。「Microsoft MVP Office Development」「Microsoft Certified Azure Developer Associate」「Certified ScrumMaster」「JDLA Deep Learning for GENERAL 2019#2」「MCSA: Web Applications」「MCSD: App Builder」を受賞。

CSV、XML、JSON、Power Automateで扱いやすいのは？

　Power Automateの中心はなんといってもデータです。代表的な3つのデータ形式「CSV」「XML」「JSON」について説明します。

　データ形式として定番の「CSV」は古くから活躍し、今ではCSV形式でデータを出力できるシステムは多数存在します。その後「XML」や「JSON」といったフォーマットが登場し、Web APIの通信で用いられるようになりました。この3つの中でPower Automateで一番取り扱いやすいデータ形式はJSONでしょう。次点でXML、そしてCSVの順です。

　CSVの難点はパターンの数です。ヘッダ情報の有無やダブルクォーテーションの有無、改行の取り扱い、エスケープの取り扱い、さらにCSVの国際標準規格の「RFC 4180」（※1）を満たしていないパターンもあり、一つの種類ならまだしも、複数パターンあるCSVの情報解析をPower Automateで組み立てるのはかなりしんどい作業です。

　複雑なCSV変換処理をする場合、下図のようにCSVを受け取りJSONで返す汎用（はんよう）的なWeb APIを使用するフローにした方がいいでしょう。CSVは比較的取り扱いにくいデータ形式と著者は考えます。

図　難しいCSV変換の場合に採りたい構成（出典：筆者作成の資料）

　次点でXMLですが、著者としてはXMLの構造解析で使用するXPathを利用するよりは、可能であれば式関数（※2）でJSONに変換をした方が良いと考えます。全てのケースでとは言い切れませんが、できればXMLのままで使用しない方がいいでしょう。「昔のWebアプリケーションだからXMLでのやりとりが必要」という状況などでなければ、積極的に使用しない方がいいと考えます。

　JSONについてはPower Automateで解析などJSON専用のアクションが用意されていることもあり、Power Automateでは取り扱いやすいデータ形式です。最近のサービスで提供されるWeb APIはJSONがベースで、第1候補としてJSONを利用すれば間違いないでしょう。データが来たら「まずJSONに変換してみる」と考えるのが有効です。

式関数とは

　式関数にどのようなものが存在するかを把握しておいて損はありません。フローで頑張って組み立てたものが実は式関数で簡単に実現できた、といったケースもよくあることです。

　「値比較のためにtoLowerを使用する」「データベースのchar型などの空白が含まれる固定長の型にtrimを使用する」「配列データからfirstやlastで先頭／末尾データを取り出す」などさまざまなことができるため、ドキュメントを見て何ができるか把握しておくことをお勧めします。

Power Automateでの構成づくりで押さえるべき点

　次はPower Automateの内部、周辺環境を含めた構成についてです。フローができたら終わりではありません。ビジネスが目まぐるしく変化するこの時代、今後を考えると機能の改善や追加がしやすい構成にしておくにこしたことはありません。Power Automateを運用しやすい構成はいったいどのようなものでしょうか。

　まずは、扱いやすいWeb APIを選ぶことです。Open API（Swagger）定義で機能やパラメータの情報が確認できるのは大きなメリットです。Power Automate以外でも、定義情報を利用するサービスが数多くあるため、他のサービスにも展開しやすいというメリットもあります。

　定義情報の確認のしやすさ以外にも、Web APIの動作を検証しやすい環境があることも重要です。特にPower Automateの場合はリクエストやレスポンスをサンプルに、構造を作成する機能があり、気軽にリクエストやレスポンスを確認できる環境が用意されていることはフロー開発において大きな手助けとなります。

　例えば、前回のサンプルで使用した「Money Forward」の例では、試用環境の作成やWeb API仕様の確認のために、サポートに問い合わせる必要はありません。Swaggerのページが公開されているため、ツールなどを使うことなくWeb APIの試打が可能で、Power Automateのフロー作成に集中できることも大きなメリットです。Web API同士の連携が重要な要素になるこれからの時代には、気軽に仕様を確認し、試せるオープンな環境が準備されているかどうかがWeb APIの選定基準において重要な要素となりそうです。

データを直接取り扱うことの是非

　Power Automateは、オンプレミスデータゲートウェイを使用することでオンプレミスのWeb API以外にもデータベースに直接アクセスできます。データの登録もデータベースのInsertやUpdateのクエリで実現できるのですが、情シスや開発者からすると、そうしたデータベースの直接操作は「ちょっと待った」となります。それは、システムの整合性を保つためのデータ検査やトランザクション管理が必要であるためです。

　データ内部に存在するIDなどの項目チェックや、入ってはいけないところにマイナス値が入っていないか、複数テーブルを更新する時に何かあった場合ロールバックされるか、失敗した場合にはリトライでき、そのデータがどこかに格納される処理となっているかなど、ビジネスロジックの観点から見ると、気になる点は多くあります。

　重要なデータほどシステムにのっとったったルールに基づいて登録されることが求められます。しかし「難しいデータはPower Automateで取り扱わない」という考えがいいとは言い切れず、そうしたデータほど壊れず、ミスが発生しにくい連携が求められるため、人の手が介在しないようPower Automateによる連携が求められます。

Power Automateは「頑張りすぎない方がいい」

　では「ビジネスロジックにのっとったフローをPower Automateで作ればいいのか」と言うと、そうでもありません。次の3つの側面で課題があるからです。

• 難易度
• 拡張性
• 保守性

　ここからは、この3つの課題点について詳細を説明します。

難易度の問題

　ビジネスの根幹に近いシステムほどデータ登録に必要な前提条件が多くなります。マスター登録程度であれば存在チェックなどの簡易チェックで済むかもしれませんが、お金の管理になるとそうはいきません。

　金額の整合性や仕訳内部で使用されるデータの妥当性、トランザクションの管理、失敗時のリトライ制御、エラー時のロギング、データのロックなどさまざまな条件をクリアする必要があります。しかし、これらはPower Automateのフローだけでは網羅できない可能性があり、できたとしてもフローが複雑なため重厚長大な構成になるでしょう。こうした状態に陥った場合、次の拡張性の問題に発展します。

拡張性の問題

　前回はMoney Forwardの経費仕訳の自動化を例に挙げましたが、当然会社の仕訳は経費だけではありません。原価や売り上げなどを外部サービスを使用してWeb APIで仕訳データを取り出す場合、経費同様に仕訳データの自動連携も必要です。

　この処理を既存の仕訳連携フローと一緒にすると、処理に影響が出ないように考える必要があり、新しくフローを作るにしても、重厚長大なフローができ上がることになります。どちらにせよ複雑なフローに対して手を入れる必要があり、似たような機能であっても展開が困難になってしまいます。このような構成になった場合、次の保守性の問題に発展します。

保守性の問題

　機能を追加する場合にどういうことが考えられるでしょうか。特定のサービス専用の処理だけならまだしも、共通処理の場合、複数のフローに対して同じ変更を加える必要があります。また、同一のフローで構築したとしても影響が出ないように気を付ける必要もあります。そしてフローが複雑になったとき、誰が見てもすぐに分かるようにしておかなければならないという問題もあります。

　Power AutomateではフローがUIで表示されて流れを把握しやすいのですが、分岐が多く、複数箇所でのデータの取得や、データ同士のマージなどが発生する場合、最終的なデータ形が想像しにくくなります。それによって、後任などの他者に引き継ぐことが難しい構成ができ上ってしまうのです。

　これら3つの問題によって、「怖いから触らない」「何かあった時だけ対処する」というようなレガシーシステムで抱えたジレンマをPower Automateでも抱えることになります。手を入れると壊れる可能性もあるので “石橋をたたいて渡る”開発しかできなくなります。ビジネスに求められる要件が変わり、新たなサービスが次々と生まれる現代のシステム事情からするとあまり望ましくない構成です。気軽に構成を変更しやすいPower Automateでは、なるべく“頑張らない”、シンプルで分かりやすい構成を維持することが重要だと筆者は考えます。

機能の再利用と汎用化から考えるPower Automateの“おいしい”利用法

　こうした問題があるため、複雑な処理はPower Automateで頑張るのではなく、Web APIで集約して実装し、それをPower Automateでうまく利用する方がいいでしょう。

　仕訳の例で考えると、汎用的な仕訳データを要求するWeb APIを用意し、Power Automateでは各サービスから返却されたJSONデータをWeb APIで要求する汎用的な仕訳データに加工するといった最低限の機能に収める下図のような構成が理想的だと考えます。

図　fig2-理想的な構造（出典：筆者作成の資料）

　新しくサービスを利用するとしても、専用の重厚な連携フローを作成するのではなく、自分たちが扱えるデータ形に変換して、準備したWeb APIに渡すだけで容易に連携の拡張が可能になります。

　社内で利用するシステムは全て他社のSaaS（Software as a Service）で賄っているといった場合はその限りではありませんが、複雑なロジックはそうした処理が得意なツールに任せた方が良いと考えます。

　開発者は自動テストで手間をかけずにビジネスロジックを検査する、Power Automateの作成者はシステム間連携に必要な環境構築に専念する、といったことが可能になります。複数のサービスを統括する人（情シス相当者）と、システムの整合性を保つ人（開発相当者）ではフローとシステムに対する関心領域が異なるため、それぞれの担当領域に集中できるようにするのが望ましい状態だと言えます。

処理の共通化に「Logic Apps」を試してみる

　とはいえ、いきなりユーザー部門の人が開発者とやりとりするのは難しく、取りあえず処理の共通化だけでもしたい、という場合は「Microsoft Azure」の「Azure Logic Apps」を試してみることをお勧めします。

図　Logic Appsについて（出典：筆者作成の資料）

　上図の通り、Power Automateと似たようなイメージでフローを構成でき、Power Automateとの連携も容易です。まずはここから手を付けてみるといいかもしれません。ただし、Power AutomateとLogic Appsは似ているとはいっても別物です。Microsoftのドキュメントでは「ITのプロや開発者向けの製品」とされており、使用できる機能も異なるため、Power Automateとの違いをしっかりと把握する必要があります。

　Logic Appsで複雑なフローの実装が多くなる場合、フロー担当者の責務が増えるばかりで、開発者の中にはビジネスロジックはコードで管理して自動テストを書くなどして安定動作するようにコントロールしたいと思う人もいます。徐々に開発者と連係する領域を増やしながら運用することをお勧めします。

Power Automate運用にはどのような体制が望ましいか

　Power Automateを運用するにはシステムを取り巻く人や組織の体制も重要です。開発、運用しやすい体制とはどのようなものでしょうか。

　今までの解説から、Web APIの連携が重要なことがご理解いただけたと思います。開発者とユーザー部門が連係することが必要だとお話しましたが、連携する統合システムにもWeb APIが必要であり、場合によってはWeb APIでデータを補正する作業があることを考えると、開発者と共同で改善することがより良い運用フローの鍵になると考えます。

　統合システムを社内で開発する場合、「このWeb APIのパラメータを増やしてほしい」「この機能をPower Automateで実現すると複雑化しそうだからWeb APIでどうにかできないか」といった要求が発生することが考えられます。その場合、その都度ユーザー部門の担当者と開発者とで相談し、改善するサイクルにすることが望ましいです。

　Power Automateを用いた開発はトライ&エラーの繰り返しになるパターンが多く、このサイクルの回転が早ければ早いほど効果が上がります。ただし、社内から提供されるWeb APIや連携されるシステムの内部仕様について把握できていなければ正しく連携できないため、外部の力を借りずに社内で対応可能な箇所は、相談、開発、テストをスムーズに実行できる体制づくりも重要でしょう。

図　開発と共同作業するサイクル（出典：筆者作成の資料）

　経済産業省が発行した「DXレポート2」（※3）にも、デジタルトランスフォーメーション（DX）を推進する体制の整備という点で、内製化が重要なキーワードとなっています。

　同レポートの追補資料である「DXレポート2.1」（※4）では、デジタル産業において価値を中心としたつながりが重要となり、既存のITベンダー産業におけるユーザー企業とベンダー企業の関係が大きく変化すると予想されています。それは社内のデジタル化も同様であると考えます。協力会社と共働したり、SIerに委託したりする場合、リソースや契約内容などに縛られていざというときに動きにくくなり、システムの情報全体を把握している人が社内に一人もいないといった状況になり得るためです。ビジネスのスピードが早くなり、就労人口が減少していく中で、開発の構成と体制づくりは、対顧客であっても対社内であっても重要な要素になるはずです。

　3回にわたってPower AutomateとWeb APIを用いたシステム連携についてお話しましたが、いかがでしたでしょうか。APIエコノミーの必要性やそれに必要な構成について、連載を通してご理解いただけたのではと思います。Power Automateは既存のシステムを壊さずに連携することも可能ですが、Web APIによって既存の機能にできるだけ影響を与えずに社内のビジネスフローを改善できるツールだと考えています。本連載が皆さまのビジネスの一助になれたら幸いです。

（※1）RFC 4180

（※2）Microsoft Docs:式関数のリファレンス

（※3）DXレポート2

（※4）DXレポート2.1