AIの進歩とPower Automateについて考えてみた
みなさん、こんにちは。
今日は私の思考の垂れ流し記事です。
私が以前投稿したPower Automate（クラウド）の文字列関数の紹介記事ですが、先月多くの方に閲覧いただいたと社内から報告をもらいました。
ここ最近はAIの進歩が目覚ましく、AIを使うことで、何の前知識もない人でもコードを書くことができるようになりました。かくいう私もその一人です。
そんな時代ですので、誰でも始められる・操作が簡単であるというPower Automateの強みは薄れつつあるのかなと常々考えていました。
しかし、文字列関数の紹介という、どちらかというと初学者向けの記事が多数の方に閲覧いただいているということは、まだまだPower AutomateおよびPower Platform製品の需要は高いようです。
ということで、どうしてPower Automateは未だに利用率が高いのかを今日は考えてみます。
AI（コード）とPower Automateの比較
まずは比較表を作成してみました（まずはと言いつつほぼこれが全てですが）。優位な方に○をつけています。
※あくまで二つで比較したもので、他サービスと比較したものではありません。どちらも初学者目線での評価です。
| AI（コード） | Power Automate | |
| パッと見の始めやすさ | 〇 | |
| 利用準備 | 〇 | |
| 習得難易度 | 〇 | |
| 作業時間 | 〇 | |
| 拡張性 | 〇 | |
| 共有 | 〇 | |
| 組織利用 | 〇 |
一つ一つ見ていきたいと思います。以降の説明では、特別説明がなければ、AIによるコード作成・利用のことをAIと呼称します。
パッと見の始めやすさ
取っつきやすさと言い換えてもらってもいいのですが、これは圧倒的にPower Automateだと思います。
Power Automateではアクションを一つ一つ設定していきますが、アクションはコネクタ別にアイコンが設定されており、アクション名も初期値が自動で設定されます。このことから始めたばかりの人でもだいたいは何をしているのかが一目で分かるようになっています。
一方でAIというか明確にコードなのですが、こちらは取っつきにくいことこの上ありません。コードを書けない人がいきなりテキストの羅列、それも日本語ではないものを見ても、理解できる情報はなにもないでしょう。まず理解しようという気持ちにならないのではないでしょうか。
パッと見の評価からは少し離れますが、分かっている人には、せっかくAIを利用するのだからコードの解説もAIにしてもらえばいい、と言われそうです。全くもってその通りではあるのですが、その場合も結局はAIの説明テキストを大量に読まなければいけないことに変わりはありません。初期学習のコストが大きすぎるわけです。
利用準備
利用準備の観点でもPower AutomateはAIより優位であると言えます。
コードを書く以上、Google Colabなどを除き、環境構築は必須です。対して、Power AutomateではPower Automateポータルにアクセスするだけです。サブスクでWord・Excelが使用できるM365ライセンスは必要ですが、まだ買い切りライセンスを利用しているという組織は少ないのではないかと思います。
分かっていれば環境構築は難しいものではありませんが、初学者にとっては一つの壁になると思います。
習得難易度
これもAutomateが優位かと思います。
Automateでは必要な設定を一つ一つポチポチ設定していきます。間違いがあればエラー原因も教えてくれますし、設定値についても多くは一目で分かるようになっています。異なるアクションでも基本の設定は同じである場合が多いです。これらのことから習得難易度は低いと言えるでしょう。また、一つ一つ理解した上で作業しなければならないことも、学習という面では優位に働くはずです。
AIは仮に自分が理解していなくても、全てAIが作業してくれます。その作業内容をAIから説明してもらうことはできますが、それを聞いて理解できるかどうかは別問題です。AIによる作業では、作れても自分自身は何も分かっていない、が発生しがちです。
作業時間
多くの場合、これはAIが優位でしょう。これは習得難易度の話と関連しています。
Automateは一つ一つ設定するのに対して、AIはプロンプトを与えれば一瞬でコードを作成してしまいます。AIは単純なものであればすぐに動くものができてしまいますし、エラー処理なんかもAIと相談して進めれば作るのは早いでしょう。
拡張性
Automateでは多くの動作を実行する場合、Microsoftが用意したアクションを利用します。よってアクションの仕様やアクションそのものが用意されていないことで、実現できない処理が多々あります。
AIでは環境構築こそ必要なものの、コード言語も、無数にあるモジュールのインポートも全て自由です。また、一度書いたコードを呼び出したり、コピーして別のファイルで使用するといったことも容易です。
保守の面で考えてみても、Automateには子フローという仕組みがありますが、複数のフローから呼び出すには設計が難しく、再利用が困難である場合が多いです。自分のコードをモジュール化して管理できるAIと比較して、Automateは拡張性で劣っていると言えるでしょう。
共有
ここでの「共有」は作成した仕組みを複数のユーザーで使用することとします。
私は、これはAutomateの方が優位であると思います。
Automateでは、例えば共有のSharePointサイトをトリガーとするフローを作成することで、複数ユーザーでフローを利用することができます。
一方、AIの場合は、コードファイルを各ユーザーに共有し、環境構築を行ってもらう、もしくはAzure Functionsのようなサービスを別途利用する必要があります。
後者の課題は以下の通りです。
- 別サービスの利用に伴う学習コスト・費用
- 利用サービスに合わせたプロジェクトの再構成
- 利用サービスをキックするための仕組みづくり
3の課題をクリアするためにAutomateが利用されることもあります。
組織利用
これは主に権限の問題です。
AutomateはサービスそのものがM365アカウントと紐づいており、Microsoftのサービスと接続する場合は基本的には編集者の権限がそのまま適用されます。要はアカウントにSharePointサイトなどの権限が振られていれば、割り振られた権限の範囲でAutomate内でそのサイトを操作することができますし、権限の問題を深く考える必要はありません。
一方、AIで各サービスのAPIを利用するような場合は、認証を別途行う必要があります。例えばSharePointから値を取得する場合、コード作成以外にも以下3つの作業が必要です。
- Entra管理センターでアプリケーションを作成
- アプリケーションに権限付与
- クライアントシークレットの発行
また、これらの作業には管理者権限が必須です。Azure Functionsで考えると、Azure Functionsリソースを操作するために、サブスクリプションに対しての権限も必要です。
ということで
結論：Power Automateの需要はまだまだありそう！
さいごに
改めて考えてみると、AI時代においても、Power Automateの需要があるのは当然かという結論に至りました。なんならコードのトリガー要因として使用されるため、AIによってAutomateの需要が増したとも言えそうです。
Power Automateを利用する目的の一つが内製化だと思います。そういった目的では、AIに任せきりにする、は目的が設定された背景の課題の解決策にはならないはずです。安全に利用できる環境を整えてあげないとAIそのものがリスクの塊なので、こういった場合の組織利用はなかなか難しいところがあると思います。
もちろん、安全に利用できる環境を整えたうえで、任せきりにするのではなく、AIの生成物の判断はユーザーが行う、のであればAIは非常に有用です。安全に利用という面では、Microsoft製品を利用しているのであれば、拡張性も鑑みてAzure OpenAIの利用が組織的には一番だと思います。
それでは今回は以上になります。ここまで閲覧いただきありがとうございました！
