こんにちは、東北ずん子です。
今日は最近よく話題になる「ノーコード／ローコードと、上手に長く付き合う方法」について、PowerApps と Logic Apps を全社展開してちょっと困っている ずんだもん と一緒に、
-
ローコードはどんなときに「負債」になりやすいのか
-
PowerApps / Logic Apps を使うときに気をつけたいポイント
-
実際に改善した事例から学べること
-
既存資産から「卒業」するための現実的なロードマップ
を、情シス・社内インフラ屋の目線でお話していきますね。
はじめに ─ ローコードが「悪」というわけではない
 |
 |
🟩ずんだもん：ずん子〜、聞いてほしいのだ。うちの会社、3年前に「DXだ! 市民開発だ!」って PowerApps と Power Automate と Logic Apps を全社開放したのだ。最初はすごく便利だったのだ。
🟦ずん子：うん、わかるわ。実際 Power Platform って、現場の困りごとをすごい速さで解決できる、本当に強力なツールよね。
🟩ずんだもん：そうなのだ! でも最近、誰が作ったかわからないアプリが少しずつ増えてきて、コストもじわじわ上がってきて……ちょっと心配になってきたのだ。
🟦ずん子：そういう声、最近よく聞くわね。ローコード自体が悪いというわけじゃなくて、「長く付き合うときの注意点」を最初から知っておくと、もっと幸せに使えるんじゃないかなって話なの。
🟩ずんだもん：ふむふむ。
🟦ずん子：今日は、巷の論考と実際の改善事例をベースに、次の流れで一緒に考えていきましょう。
-
ローコードは「開発速度を前借りする仕組み」と理解する
-
PowerApps を長く使うときに気をつけたいこと
-
Logic Apps の特性を踏まえた使い分け
-
実例：99% コスト削減を実現した移行事例
-
その他のツールも、共通する考え方で整理できる
-
AI 時代における、ローコード資産の扱いにくさ
-
既存資産からの「卒業」ロードマップ
1. ローコードは「開発速度を前借りする仕組み」
|
|
🟩ずんだもん：ローコードってメリットいっぱいあるはずなのだ。早い、現場が作れる、IT 部門の負担が減る。なんで悩む人がいるのだ?
🟦ずん子：それね。すごく大事な質問。よくある論点をまとめると、こういうイメージなの。
💡 ローコードは「初期スピード」と「将来の柔軟性」を交換している ─ つまり、速度を前借りしている
🟩ずんだもん：前借り……?
🟦ずん子：そう。最初の数ヶ月はとっても順調なのよ。要件定義からデプロイまで爆速。これは紛れもなくローコードの素晴らしい価値ね。でも、運用が長くなると、特性に応じた配慮がないと、少しずつ不便さが顔を出してくることがあるの。
論点を整理すると、だいたい5つに集約されるわ。
| # | 気をつけたいポイント | 一言で |
|---|---|---|
| 1 | プラットフォーム依存 | 移行先の選択肢が限られる |
| 2 | 属人化しやすさ | コードレビューや差分管理の文化を作りにくい |
| 3 | 機能の上限 | 「あと一歩」のところで詰まることがある |
| 4 | 統制の後手化 | 誰が何を作っているか追いかけるのが大変 |
| 5 | ライセンス構造 | 規模が大きくなると単価モデルが効いてくる |
🧠 「コードを書かない技術」というより、「将来の柔軟性を前借りする技術」と考えると、付き合い方が見えてくる
これ、覚えておくと判断軸になるわよ。
2. PowerApps と長く付き合うために知っておきたいこと
|
|
🟩ずんだもん：PowerApps は Microsoft 365 についてきて便利だから、ついどんどん作っちゃうのだ。
🟦ずん子：うんとね、PowerApps 自体はとても優秀なツールなのよ。市民開発による社内の小さな業務改善には本当に向いてるの。気をつけたいのは、「便利だから」って統制なしに広げていくと、後から整理が大変になること、かしらね。
2-1. ありがちな道のり ─ 第 1 週 から 3 年目 まで
🟩ずんだもん：具体的にはどんな感じになっていくのだ?
🟦ずん子：これは私が「あるあるの道のり」だと感じているお話なんだけど、聞いてみてくれる?
🌸 1週目
部署のちょっとした申請フォームを PowerApps で作ってみる。爆速で完成して、みんな大喜び。「これ、もっと早くやればよかった!」
🌱 2か月目
「うちの部署にも欲しい」と横展開のリクエストが来る。少し手直ししてコピーで対応。これも数日で完了。
🤔 6か月目
「あの申請フォームに承認フローも足してほしい」と言われる。画面裏の Power Fx の式が少しずつ膨らんでくる。最初に作った人が「あれ、自分でもどこに何を書いたっけ……」と感じ始める。
😅 1年目
連携先の SharePoint リストのカラムが増えてきて、Delegation 警告が出始める。「件数が増えると合計値がずれる」という声もちらほら。
😰 2年目
最初に作った担当者が異動。「ちょっと修正したいんですが、誰が触れますか?」 ─ 部署内では誰も触れない状況に。
🆘 3年目
「作り直したいんですが、仕様書がなくて……」と情シスに相談が来る。Power Fx 全解読から始める大規模リフォームへ。
🟩ずんだもん：……うちの会社、ちょうど 2 年目あたりなのだ。
🟦ずん子：実はこの道のり、PowerApps が悪いから起きるんじゃなくて、「ローコードの特性を踏まえた運用設計」をしないと自然と起きてしまう ものなの。だから、最初に知っておくこと、そして「Year 2 になる前に手を打つ」ことが大事なのよ。
2-2. ライセンスの境界線を意識する
🟦ずん子：PowerApps は最初、M365 同梱の権限で動くのよ。ただし、プレミアムコネクタを使い始めると、別のライセンスが必要になることがあるの。
| 項目 | 知っておくと安心 |
|---|---|
| 標準コネクタ | M365 同梱で利用できる |
| プレミアムコネクタ（SQL/Dataverse など） | 追加ライセンスが必要なケースあり |
| Dataverse | 容量に応じた課金がある |
| プラン改定 | 定期的にチェックしておきたい |
🟩ずんだもん：あ……うちのアプリ、Dataverse 使ってるのだ。
🟦ずん子：そうしたら、ライセンス構造を一度棚卸ししてみると安心ね。「気づいたら請求が増えていた」を防げるわ。
2-3. ALM（ライフサイクル管理）の考え方
🟩ずんだもん：ALM ってなんなのだ?
🟦ずん子：Application Lifecycle Management。コードレビューや Git での管理、テスト、本番デプロイといった開発の一連の作法のことね。
PowerApps は Solution や Pipelines で改善が進んでいて、最近は ALM の選択肢もずいぶん増えているの。ただ、Canvas App はファイル構造の特性上、
-
差分レビューが少し工夫を要する
-
マージ作業が手間取ることがある
-
ついつい本番で直接修正してしまいがち
といった面は今もあるわね。だから、チームで使うときはルールを決めておく のがポイント。
2-4. ID とコネクションの管理 ─ ここは特に大事
🟦ずん子：情シス・社内インフラ屋として、ここは少し丁寧にお話したいの。Power Platform って、接続情報（コネクション）が個人アカウントに紐づいて作成されることが多いのよね。
🟩ずんだもん：うん、自分のアカウントでサクッと作ったのだ。
🟦ずん子：それで動いているうちは問題ないのだけど、作った人が異動や退職をしたときに、そのフローが連鎖的に止まってしまうことがあるの。これは Power Platform に限った話じゃなくて、SaaS 連携ツール全般に共通する課題ね。
-
業務クリティカルなフローは、できるだけサービスアカウントや Managed Identityを使う
-
Entra ID の条件付きアクセス、PIM、Managed Identity といった統制とつながる形で運用する
-
CoE Starter Kit や DLP ポリシーで、最低限の見える化をしておく
🟩ずんだもん：……うちが先月止まったの、まさにそれなのだ。退職した人のアカウントでフローが動いてて、無効化したらいくつか巻き添えになったのだ。
🟦ずん子：あらら、それは大変だったわね。でもこれ、事前に知っていれば対策できる話なのよ。
2-5. Delegation（委任）という概念
🟦ずん子：あと地味だけど、知っておくと事故が減るのが Delegation の話ね。Canvas App は、データソースに対するクエリの一部をクライアント側で処理することがあるの。
🟩ずんだもん：それの何が問題なのだ?
🟦ずん子：データ件数が一定数（標準で500件など）を超えると、集計対象が一部しか取れず、**「気づかないうちに数字がずれる」**ことがあるの。これはバグじゃなくて Power Apps の仕様だから、知っているかどうかが分かれ目ね。
💡 動いているように見えて、実は数字が一部しか集計されていない ─ これに最初から気づけるかが大事
公式ドキュメントにもしっかり書いてあるので、市民開発を始めるチームには最初に共有しておくのがおすすめよ。
3. Logic Apps の特性と上手な使い分け
|
|
🟩ずんだもん：Logic Apps は IT 部門が使うやつだから、PowerApps よりは安全なのだ?
🟦ずん子：Logic Apps は、SaaS 連携やイベント駆動の処理を組むのにとっても便利なサービスね。ただ、プランや使い方によって "得意なこと" が大きく違うので、そこを知っておくと幸せになれるわ。
3-1. 「小さなフロー」と「ハブ化したフロー」は別物
🟦ずん子：Logic Apps を使い始めるときは、たいてい「ちょっとした連携」なのよ。それが時間とともに、**気づくとシステム間連携の中枢（ハブ）**になっていることがあるの。この2つは、同じツールを使っていても性格が全然違うわ。
| 観点 | 小さなフロー 🌱 | ハブ化したフロー 🏢 |
|---|---|---|
| 役割 | 単一システムのお手伝い | システム間連携の中枢 |
| 条件分岐 | シンプルな if 程度 | 分岐だらけで複雑化 |
| 影響範囲 | 把握しやすい | 説明が難しくなる |
| トラブル対応 | UI から追える | 追跡に時間がかかる |
| コスト | 許容範囲 | 想定以上に膨らむことがある |
🟩ずんだもん：「小さく始めて、いつの間にかハブになってる」ってやつなのだ……。
🟦ずん子：そうね。ハブになりかけているフローを早めに見つけて、別の技術に逃がす判断をする。これが大事なポイントよ。後で実例が出てくるわ。
3-2. Consumption と Standard ─ 性格が違う2つのプラン
| 項目 | Consumption | Standard |
|---|---|---|
| 課金モデル | 実行数ベース | App Service Plan ベース |
| ローカル開発 | △ | ✅ VS Code で可能 |
| ソース管理 | ARM/Terraform で対応 | コードファースト寄り |
| VNet 統合 | ILE が必要 | ネイティブ対応 |
| 向いている用途 | 軽量・単発のフロー | 本番運用・複雑な処理 |
🟦ずん子：Consumption は気軽に試せる素晴らしいプランなのだけど、本番運用や複雑な処理を長く動かすなら、Standard を視野に入れると後々ラクになることが多いわね。
3-3. デザイナーの良さと、コードベース運用の両立
🟦ずん子：Logic Apps デザイナーって、視覚的にフローを組み立てられて、本当に直感的なのよ。プロトタイピングや小規模な自動化には最適ね。
一方で、複雑度が上がってくると、
-
式言語（
@{...}）の表現が増える -
For each / Until のネストが深くなる
-
Git で差分を取ったときに変更点が読みにくい
といった面が出てくることもあるわ。だから、「規模が大きくなりそうなフローは、最初から VS Code 拡張＋ソース管理で運用する」 のがおすすめね。
3-4. 認証とシークレットの推奨形
🟦ずん子：ここは Logic Apps が大きく改善されている領域でもあって、最近は Managed Identity と Key Vault 連携がしっかり使えるようになっているの。
| 項目 | おすすめ ✅ | 避けたい構成 |
|---|---|---|
| 認証 | Managed Identity | API Key の直書き |
| シークレット | Key Vault 参照 | パラメータに平文 |
| コネクション | MI ベース | 個人アカウント API Connection |
🟩ずんだもん：新規で作るなら、最初から MI 前提で設計するといいのだ?
🟦ずん子：そうそう。後から書き換える手間がぐっと減るわよ。
4. 実例：Logic Apps から Azure Functions Flex Consumption への移行
|
|
🟩ずんだもん：実際にローコードから移行して、うまくいった例ってあるのだ?
🟦ずん子：あるある、すごく参考になる事例があるのよ。Qiita で公開されている 「Logic Apps → Azure Functions 移行で99%コスト削減した話」 という記事ね。これは「ローコードを全否定する話」ではなく、「適材適所で使い分けるとここまで効果が出る」 という素晴らしい実例なの。
4-1. どんな課題があったか
ストレージアカウント管理処理を Logic Apps のコネクタで構築していたところ、
-
コネクタ呼び出しのたびに Table Storage へトランザクションが発生
-
1日に数万回のトランザクションが積み重なる
-
月次コストが想定以上に膨らんでいた
-
平均処理時間が約90分と長め
-
メモリエラーが頻発
-
環境ごとに5つもワークフローが必要だった
という状況だったそうよ。これは決して Logic Apps が悪いんじゃなくて、「ループが多くトランザクションが膨大になる処理」が、コネクタベースのアーキテクチャと相性が良くなかった ということね。
🟩ずんだもん：あ! まさにさっきの「ハブ化したフロー」のパターンなのだ!
🟦ずん子：そうそう。ローコードの設計思想と、処理の性質がミスマッチしている状態だったのね。
4-2. どう改善したか
新しい構成はこんな感じ。
| コンポーネント | 役割 | コスト比率 |
|---|---|---|
| Azure Functions（Flex Consumption） | メインの処理エンジン（PowerShell） | 約45% |
| Durable Functions | 複雑な処理フローのオーケストレーション | 上記に含む |
| Logic Apps | Function をキックする軽量ワークフロー | 約15% |
| Storage Account | Function 用の専用ストレージ | 約40% |
ポイントは、Logic Apps を完全に捨てたわけではなく、「キック役」として残していること。これ、すごく大事な設計判断だと思うの。
💡 Logic Apps を「全部やる係」から「キックするだけ係」に役割を絞る ─ ローコードの良いところはそのまま活かせる
4-3. 効果
| 指標 | Before | After |
|---|---|---|
| 月額コスト | 100% | 約1%（99%以上削減） |
| 処理時間 | 90分 | 40分（55%短縮） |
| メモリエラー | 頻発 | 解消 |
| ワークフロー数 | 環境ごとに5つ | 統合により大幅削減 |
🟩ずんだもん：すごいのだ……! 99% って、桁が違うのだ!
🟦ずん子：ね。これが面白いのは、「Logic Apps を使うべきか、Functions を使うべきか」 ではなくて、「処理の性質に合わせて使い分ける」 という発想なのよ。
4-4. 移行も決して楽ではなかった ─ 大事な学び
🟦ずん子：ただし、元記事で著者の方が丁寧に書いてくださっているけれど、移行も決して楽ではなかったそうなの。
-
VNet 統合や Private Endpoint の設計変更が必要だった
-
Durable Functions の学習コストが想定より高かった
-
Flex Consumption はまだ情報が少なく検証に時間が必要
-
ChatGPT-4 や Gemini 2.5 が、Flex Consumption と通常の Functions を混同してハルシネーションを起こすことが多い（2025年10月時点）
-
提案から構築まで数ヶ月を要した
🟩ずんだもん：AI に聞いても正確な情報が返ってこないのだ?
🟦ずん子：そうなのよ。これは新しいプランによくある話で、LLM の学習データが追いついていないの。だから、新しいサービスを使うときは公式ドキュメントを必ず一次情報として参照する習慣が大事ね。
そして何より、「ローコードで作ったものを後からプロコードに移行する」のは、思ったよりコストがかかる、というのがここでの大事な学びね。逆に言えば、最初から「将来こういう移行があるかも」と見越して設計しておけば、移行コストはぐっと下げられるということでもあるわ。
💡 ローコードとプロコードは「敵対関係」ではなく「補完関係」。処理の性質に応じて使い分けるのが、いちばん幸せな付き合い方
これがこの事例の本質的なメッセージだと、私は読み取ったわ。
5. その他のツールも、同じ視点で整理できる
|
|
🟩ずんだもん：他のローコードツールも、同じような視点で見ればいいのだ?
🟦ずん子：そうね。各ツールに個性はあるけれど、「気をつけたいポイント」のパターンは共通していることが多いわ。早見表にしてみたわね。
| ツール | 主な用途 | 知っておくと安心なポイント |
|---|---|---|
| Power Automate (Cloud Flow) | 業務自動化 | 個人アカウント紐付きフローの整理 |
| Power Automate Desktop (RPA) | UI 操作自動化 | UI 変更への耐性、テスト戦略 |
| kintone | 業務台帳 | プラグインや JS カスタマイズの管理ルール |
| Salesforce / Lightning Flow | CRM 拡張 | Apex とフローの役割分担、ガバナ制約 |
| ServiceNow | ITSM | 強力だが移行コストは大きい |
| Zapier / Make | SaaS 連携 | 業務利用時の契約・運用ルール |
| Bubble | Web アプリ | スケール時の単価モデル確認 |
| Adalo / Glide / FlutterFlow | モバイルアプリ | プラットフォームのロードマップ把握 |
| Retool | 社内ツール | コードと GUI の境界線、レビュー方法 |
| Notion / Airtable as DB | データ管理 | API 制限、データモデル設計 |
| AppSheet | 業務アプリ | Google エコシステムとの連携前提 |
🟦ずん子：どのツールも、正しく使えば素晴らしい価値を発揮するのよ。大事なのは、「このツールが得意なこと、苦手なこと」を知って、用途に合わせて選ぶことね。
6. AI 時代の新しい論点 ─ 「資産がコードであること」の価値
|
|
🟩ずんだもん：最近は AI にコードを読ませてレビューしてもらうのが普通になってきたのだ。それならローコードも AI に読んでもらえばいいのでは?
🟦ずん子：それがね、資産の形によって AI から見た扱いやすさがけっこう違うのよ。整理するとこんな感じ。
| 資産の形態 | AI から見た扱いやすさ |
|---|---|
| テキストコード（Git 管理） | ◎ 差分・静的解析・自動リファクタリングがやりやすい |
| 設定 JSON ＋ GUI（Logic Apps など） | △ 構造の解読に手間がかかる |
| 完全に閉じたプラットフォーム | × そもそも外から読みにくい |
🟩ずんだもん：プロコードは AI 時代の追い風を受けやすいけど、ローコードはちょっと不利なポジションなのだ……。
🟦ずん子：そう。だからこれからは、
💡 「ローコード or プロコード」の二択ではなく、「AI 支援つきのプロコード」も含めた三択で考える時代
になりつつあるのよ。ローコードがなくなるわけじゃなくて、選択肢が増えるイメージね。以前は「現場がコードを書けない」というのがローコードの大きな存在意義だったけれど、Claude や GitHub Copilot みたいな AI 支援が普及してきた今、その前提が少しずつ変わってきているの。
7. 「既存資産からの移行」ロードマップ
|
|
🟩ずんだもん：すでに PowerApps と Logic Apps が大量にある会社は、どこから手をつければいいのだ?
🟦ずん子：いきなり全部捨てる必要はないのよ。段階的に整理していく のが現実的ね。私はこんな4フェーズで考えるのがおすすめだと思っているわ。
Phase 0：現状把握 ─ まず「何があるか」を知る
| やること | 目的 |
|---|---|
| テナント全体でアプリ・フローを棚卸し | 全体像を知る |
| 変更頻度と業務影響度をマッピング | 優先度を決める材料にする |
| 個人アカウント紐付きフローを洗い出し | リスクの可視化 |
🟦ずん子：CoE Starter Kit を入れると、この棚卸しがぐっと楽になるわよ。
Phase 1：「壊すのが怖い」状態の緩和
| やること | 目的 |
|---|---|
| ログ出力・監視・アラートの整備 | 「動いてるか分からない」を解消 |
| バックアップとエクスポート手順の確立 | 「壊したら戻せない」を解消 |
| ドキュメント整備（特に設計意図） | 引き継ぎ可能な状態にする |
🟦ずん子：このフェーズは何も移行しないけど、すごく大事よ。「いつ手を入れても大丈夫な状態」を作るの。
Phase 2：周辺ロジックから順にコード化
| やること | 目的 |
|---|---|
| 重い処理を Azure Functions 等に切り出す | コスト・性能を改善する |
| Logic Apps はトリガー・キック役に絞る | ローコードの良さを残す |
| 共通ロジックを再利用可能な形に整理 | 属人化を解消 |
🟦ずん子：さっきの Functions 移行事例は、まさにこの Phase 2 の話ね。いきなり全部捨てるんじゃなくて、「重いところから順に逃がす」 のがコツよ。
Phase 3：コアドメインの本格移行
| やること | 目的 |
|---|---|
| 基幹データを API＋DB 構成へ段階移行 | プラットフォーム依存からの脱却 |
| 業務クリティカルなフローはプロコード化 | 長期保守性の確保 |
| ローコードは試作・部門内ツールに集約 | 「適材適所」の状態に |
🟩ずんだもん：Phase 0 から順番にやっていけば、いきなり大改修しなくていいのだ。
🟦ずん子：そう。「明日から CoE Starter Kit を入れて棚卸しを始める」だけでも、Phase 0 はスタートできるのよ。決して手遅れじゃないの。
おまけ：新規で作るときの5つのセルフチェック
🟦ずん子：これから新しくローコードで何か作るときは、こんなセルフチェックをしてみるといいわ。
-
想定寿命は何年? ─ 3年以上なら設計をしっかりめに
-
誰のアカウントで動かす? ─ できるだけ個人紐付けを避ける
-
ループや大量データ処理は含まれる? ─ 含まれるなら別技術を検討
-
業務クリティカル? ─ Yes ならプロコードも視野に
-
「移行ルート」は描ける? ─ データのエクスポート経路を確認
8. まとめ：ローコードは「上手に付き合えば最強の味方」
|
|
最後に、今日のお話をまとめておきましょうね。
-
ローコードは「開発速度を前借りする仕組み」と理解する
- 初期スピードと将来の柔軟性のトレードオフを意識する -
PowerApps は素晴らしいツール、ただし長期運用には設計が大事
- Year 2 になる前に、ALM・ID・Delegation を点検する -
Logic Apps は「ハブ化」のサインに早めに気づく
- 重くなってきたら別技術に逃がす判断を -
実例：Functions 移行で 99% コスト削減も実現
- ローコードとプロコードはハイブリッドで使うのが幸せ -
AI 時代は「コードであること」の価値が上がっている
- 三択（ローコード / プロコード / AI 支援つきプロコード）で考える -
既存資産は Phase 0 から段階的に整理する
- まず棚卸し、次に緩和、それから移行
🟩ずんだもん：トータルすると、「ローコードを敵にしない、でも盲信もしない」ってことなのだ?
🟦ずん子：そうね。速度が必要な場面では本当に強力な武器だし、長期運用するなら最初から設計をしっかりする。この両方をバランスよく考えれば、ローコードは怖くないわ。むしろ最高の味方になってくれるはずよ。
🌟 **「ノーコード／ローコード＝永続システムの最終形」ではなく、「コードに引き継ぐための仮設足場」**くらいに考えておくと、ちょうどいい距離感で付き合える
-
✅ 試作・小規模はどんどんローコードで
-
✅ 業務クリティカルなものは設計と統制を意識する
-
✅ 個人アカウント紐付きは早めに整理する
-
✅ 重い処理は適材適所で別技術に任せる
-
✅ 「卒業ルート」を最初から用意する
-
✅ 既存資産は Phase 0 の棚卸しから始める
おまけ：ずんだもち冷蔵庫事件
|
|
🟩ずんだもん：ずん子、ありがとうなのだ! ボクも明日から、Phase 0 の棚卸しを始めるのだ!
🟦ずん子：うんうん、その意気よ。……ところでずんだもん、なんでさっきからずっと口の周りが緑色なの?
🟦ずん子：……それから、なんで冷蔵庫の扉が開けっぱなしなの?
ず：……き、気のせいなのだ。
🟦ずん子：今朝めたんが「お夕飯のあとにみんなで食べようね」って買ってきたずんだもち、8個入りのパックだったわよね?
ず：……た、たぶんそうだったのだ。
🟦ずん子：今、冷蔵庫を見たら、空のパックだけがあったんだけど。
ず：……そ、それはきっと、ずんだもち妖精さんが食べたのだ!?
🟦ずん子：ふーん。じゃあ、その妖精さんは、ずんだもんと同じあんこを口の周りにつけてたのかしらね?
ず：……ぐぬぬ。😭
ボクのおなか、棚卸し対象外であってほしかったのだ……。😭
🟦ずん子：ふふ。じゃあ一緒にめたんに正直にお話して、次のお買い物のときに新しいの買ってもらいましょうね。
参考リンク
※本記事は筆者の運用経験と公開情報を元にした個人的見解です。各製品の仕様はアップデートにより変わる可能性があるため、導入前には最新の公式ドキュメントを必ず確認してください。
また、PowerApps や Logic Apps はいずれも市民開発の門戸を開く素晴らしいサービスであり、本記事は特定の製品を否定する意図はまったくありません。
利用キャラクター
-
ずんだもん：VOICEVOX:ずんだもん
-
東北ずん子：東北ずん子・ずんだもんプロジェクト
本記事で使用しているキャラクター画像の著作権は、それぞれの権利者に帰属します。
非商用目的での利用に基づき掲載しています。