はじめに
本記事はGlobal Azure 2025 「Azureのコスト集計システムの開発について」で紹介されたアーキテクチャにおいて、ローコード開発を主軸にシステム構築した際の課題と苦悩を記載します。
我々のチームの技術スタックは一般的なWebアプリ/APIサーバーの構築を担当するバックエンド/インフラエンジニアに相当します。そのため、なにかシステムを構築するとなったときは真っ先にWebアプリを作ろうという思考になります。エンジニア脳でローコードツールを触るとどうなるかという一例になります。
アーキテクチャ
紹介されているアーキテクチャ図を改めて載せておきます。
本記事では、ローコード開発ついて焦点を置くためGithub Actionsによる課金費用の収集機構やDBによるストアドプロシージャー集計については記載しません。
ローコード開発での期待
以下は私がローコード開発によるシステム構築に抱いていた期待です
- 作業工数の削減
- 短い期間でシステム開発が可能
- SharePoint等のMicrosoftサービスへ簡単に接続が可能
- 認証周りを実装しなくて済む
前提
我々の会社では、Microsoft 365 E3を全社員が保持していることやMicrosoft Entra IDによるアクセス管理を多用しています。本アーキテクチャはその前提を最大限活かすようなアーキテクチャを組んでいます。
- Microsoft 365 E3を全社員が保持
- Logic AppsとPower Automateでプレミアムコネクタが使えない
- Power Platformの従量課金プランを使用
- 全社員がMicrosoft Entra IDに登録されている
- SharePointはMicrosoft Entra IDによるアクセス権限を付与することが可能
- エンジニアはVisual Studio subscriptions with GitHub Enterpriseを保持している
- GitHubによるコード管理やCI/CDツールを使用
ローコードツール
各種ローコードツールでの使用用途はざっくり以下の通りです。
- Azure Logic Apps
- SharePoint Online上に配置されたファイルを読み取り、SharePoint ListsもしくはAzure SQL Serverへデータを格納する
- SharePoint Online上に配置されたファイルもしくはSharePoint Listsの各行へ適切なアクセス権限を付与する
- Azure SQL Serverからデータを読み取り、Excelファイルへ出力する
- Power Apps + Power Automate
- 利用者が費用を適切なお財布に計上するためのルールを、セルフサービスで設定可能な画面を提供
- ↑についてはルールをSharePoint Listsで管理しており、Microsoft ListsやMicrosoft Formsで代用が可能です。我々は情報のフィルターやバリデーションを適用するために画面を作っています
- 利用者が費用を適切なお財布に計上するためのルールを、セルフサービスで設定可能な画面を提供
Azure Logic AppsやPower AutomateはSharePointへのコネクタが豊富揃っているため、かなり強力です。Azure Logic AppsとPower Automateはデザイナー画面がかなり似ています。ただ、標準コネクタやARMによるIaC化が可能という点で基本的にLogic Appsを使用しています。一方でPower AppsはPower Automateへのみ標準コネクタを保持しているため、セルフサービスな画面づくりにおいてはPower Automateを使用しています。
ローコード開発で直面した課題
本説では、ローコード開発でシステム構築を実施し挙がった課題について記載していきます。
制御構造や文字列操作がつらい
以下はPowerShellで記載した簡単なfor文とif文の組み合わせです。
$list = @("fa", "ga")
foreach ($item in $list) {
Write-Host "Processing item: $item"
if ($item -eq "fa") {
Write-Host "Item is fa"
}
}
PowerShellのコードをLogic AppsやPowerAutomateで表現すると以下になります。
制御式が増えるとデザイナー画面での可読性が落ちるため、それを避けて構築することをおすすめします。また、For Eachの制約として並列実行が既定でtrue、ループ内では変数宣言ができないといったことがあります。プログラムコードでの実装に慣れている方にとってはなんとももどかしい気持ちになります。
ローコードに寄り添った処理構造で構築することを心がけましょう。
複雑なビジネスロジックの表現の限界
Azure Logic Apps/PowerAutomateは予め提供されている部品(アクション)を組み合わせて構築していきます。そのため、こちらがやりたいことを全て実装することは場合によっては不可能です。アクションはないものはないです。 諦めましょう。。。
我々が限界を感じたのは以下のようなケースです。
SharePoint Listsの各行/ファイルに対してEntraグループにアクセス権限付与
我々の会社では部署/プロジェクトごとにEntraグループを作ることが多く、アクセス制御に用います。一方で、SharePoint コネクタには「アイテムまたはフォルダーへのアクセスを許可」というアクションがあるが、ユーザー単位でのアクセス権限付与にしか対応していません。Entraグループに対してアクセス権限を付与するためには、「HTTP リクエストを SharePoint に送信します」でREST APIを直接実行する必要があります。詳細は別途記事にしているので、EntraグループにSharePoint リストのアイテムへのアクセス権限をPower Automateで付与するをご確認ください。
- 問題
- やりたいことを簡単に実現するアクションがない → SharePoint REST APIのアクションを巧みに使い解決
このようなREST APIのアクションがある場合は、まだマシな例です。頑張ればなんとかなります。
Excel 操作の制限とパフォーマンス問題
本システムにおいて、Excelは部署/プロジェクトがどのぐらいの費用を使ったのかという費用明細に使用します。
ただ、Excel操作関連のアクションは自由度が少なく「オフィススクリプトを実行する」か、「テーブルに対して追加/削除」しかできないです。そのため、複雑なことをしようとするとオフィススクリプトでの実行になります。しかしながら、オフィススクリプトはAPI制限が厳しいため、多用ができません。また、今回はプロジェクトのごとの費用明細をExcelファイルとして書き出すので、たくさんファイルを作ります。したがって、たくさんのテーブルに対して並列実行するとAPI制限により429エラーが発生します。それを回避するために、並列実行数を調節するなどの工夫が必要です。一方で、Excelのアクションは実行速度が非常に遅いです。おそらく、データを1行追加するアクションごとにコネクションを貼りなおしているのではないかと考えています。実行速度はまだ許容範囲のため、対策はしていません。
- 問題
- API制限が厳しい → 並列実行数を抑えることでエラー数を軽減
- 実行速度が遅い → 全体の実行時間はまだ許容範囲のため、対策はしていない
- 用意されているアクションが少ない
- オフィススクリプトを実行
- テーブルへ行を追加/削除
正直API制限周りはお手上げ感があります。
SharePoint Online上の費用明細(Excelファイル)をzip化してBlobストレージに保存
フォルダに入った費用明細をアーカイブするために、Blobストレージに保存しようとしましたが、Logic Appsでは不可能でした。
- 問題
- SharePoint Online上のフォルダをzip化するアクションが存在しない。REST APIでも不可能。
- Azure Logic Appsでストレージを用意するには従量課金プラン以外を選択する必要がある
これを実現するには、Azure Functions等の外部サービスを組み合わせるしかありません。APIサーバーを作るとその分運用作業が増大するため、今回は断念しました。
節の初めに記載した通り、アクションがないものはないので、妥協点を見出すしかありません。
バージョン管理やCI/CDの課題
ローコード開発でのシステム構築で最も大きな課題だったのはDevOps環境の構築です。そもそもDevOps環境を構築することが可能なのかという点から調査/検証を進めました。
Azure Logic Apps
Azure Logic AppsについてはBicep/ARMによるIaC化は可能です。一方で、Azure Logic Appsでの開発はAzure Portal上のデザイナー上でロジックを構築するため、az cliから取得できるARMテンプレートをIaCに用います。ただ、取得できるARMはAPI接続やパラメータがかなり煩雑になっており、そのままIaCとして使用できるようなコードではありません。Azure Logic AppsのDevOps環境の構築方法については調査しても目ぼしい事例は見つかりませんでした。
我々のチームでは、取得したARMテンプレートを元に、環境ごとに異なるAPI接続やパラメータを渡してデプロイできるようにIaCを再構成するスクリプトを自作しました。以下の図は自作スクリプトを実行し再構成したIaCの一部になります。この自作したスクリプトについてチームメンバーがOSSとして公開するかもしれません。このスクリプトにより、開発者はAzure Portalのデザイナー画面でLogic Appsを構築することに専念できます。
Power Apps + Power Automate
Power AppsやPower Automateは総称してMicrosoft Power Platformと呼ばれます。Microsoft Power Platform には アプリケーション ライフサイクル管理 (ALM)というDevOpsを実現するための機構が用意されています。一方で、ALMはマネージド環境を前提としています。我々は今回従量課金プランを使用するため、マネージド環境を使用することができません。そのため、GitHubによるバージョン管理を使用することができません。また、Power Platformの組み込みのデプロイ機構を使用することができないため、GitHub Actionsによるデプロイ機構で実現しました。詳細については別途記事にしているので「Microsoft Power Platform の ALM を Github Actions で実現する」をご確認ください。
まとめ
本説について、文章が長すぎて読みづらい部分があるため箇条書きでまとめました
- Azure Logic Apps
- GitHubによるバージョン管理
- Bicep/ARMによるIaC化
- Azure Portalのデザイナー画面で構築したLogic AppsのリソースをIaC化するスクリプトを自作。
→ デザイナー画面でLogic Appsを構築することに専念できる。
- Azure Portalのデザイナー画面で構築したLogic AppsのリソースをIaC化するスクリプトを自作。
- Bicep/ARMによるIaC化
- CI/CD
- GitHub Actionsによるデプロイ機構
- GitHubによるバージョン管理
- Power Apps + Power Automate
- GitHubによるバージョン管理
- ライセンスによりマネージド環境が使えないため、断念
- CI/CD
- GitHub Actions で Microsoft Power Platform を使用したアプリケーション ライフサイクル管理 (ALM)を導入
- GitHubによるバージョン管理
ローコード開発が素晴らしい点
前節まででローコード開発に対して不満要素を多々上げましたが、素晴らしい点もあります。
- SharePointやMicrosoft Graphに接続するためのユーザーの認証情報を半永久的に保持
- 実行時にAPI接続を使用すると、トークンの期限がリフレッシュされます。そのため、半永久的に認証情報を使用することができます
- このメリットがローコード開発でシステム構築した理由の8,9割ほど占めています
- 運用作業が最小限になる
- APIサーバーを自前で用意するとライブラリ更新等の作業が毎週発生しますが、ローコードツールは気にしなくて良いです。アクションの非推奨等があるため、全く気にしなくて良いというわけではありませんが、APIサーバーのライブラリ更新に比べれば運用作業はかなり少なくなります
- Copilot in PowerPlatformが便利
- PowerPlatformの画面とCopilotが統合されているため、シームレスに聞くことができます。一方で、Copilotによるロジックの自動作成はまだまだ不安を感じるような提案なので今回は使っていません
- 動くものをすぐに作れる
- ローコードツールの特徴とも言えますが、運用することを考えなければ非常に短期間で構築可能です
まとめ
ローコード開発でシステム構築をしましたが、DevOps環境構築でがっつりコードを書いていたので全然ローコードではありませんでした。「とりあえず動くものを作る」という点においては、作業工数がかなり少なく構築できます。ただ、運用を見据えたDevOps環境を構築すると、もはやローコードの領域ではありません。また、Azure Logic Appsでの開発ではSharePoint REST APIを実行しJSON解析をしているので、エンジニアの知識は多少必要になります。
一方で、我々の会社ではSharePointといったMicrosoftサービスを様々な業務で多用しており、今回のコスト集計システム以外でもかなり流用できると考えています。同様にSharePoint等を利用している会社さんは覚えておくと業務効率化や今回ようなシステムの構築が可能になります。
余談
開発時期（2025年3月）では Logic Apps や Power Platform の Copilot はまだ不安定でした。一方で、最近はGitHub CopilotのエージェントモードやGitHub Copilot Coding Agentが登場しており、Copilotを用いたプログラムコードでの開発の方が利用者にとってはローコード開発なのではないかと思い始めています。API接続のメリットが大きいためローコードツールを使っていましたが、認証周りまで全部Copilotに書かせるならプログラムコードでシステム開発も良いかもしれないです。