Logic Apps

月1回ではなく月2回 Power Automate のフローを動かす方法 この記事の内容 Power Automate の繰り返しトリガーは「毎月第〇日」のような細かい指定ができないため、別のアプローチが必要です 毎日実行するスケジュールを組み、「今日が何日か」を条件判断することで月2回実行を実現できます UTC の現在時刻を日本標準時に変換してから日付を取得することが重要なポイントです dayOfMonth() 関数を使うと、タイムスタンプから「日」の部分だけを抽出できます 条件分岐を組み合わせることで、指定した日だけチームズにメッセージを投稿するフローが完成します 背景：月2回の定期実行は繰り返しトリガーだけでは難しい Power Automate の Teams アプリ内でフローを作成する際、スケジュールトリガーとして「繰り返し」を選択できます。この繰り返しトリガーでは、実行間隔を「分・時間・日・週・月」などの単位で指定できます。 しかし、「毎月10日と末日」のように月2回の特定日を直接指定することはできません。そのため、別のアプローチを取る必要があります。 解決策の考え方 月2回実行したい場合の方法はいくつかありますが、シンプルな方法として次の2つが考えられます。 方法1：同じフローを2つ作る 1つ目のフローを「10日にスタートして、1か月に1回実行」に設定 2つ目のフローを「末日にスタートして、1か月に1回実行」に設定 この方法は構成がシンプルで、条件分岐を書く必要がありません。 方法2：毎日実行して条件で振り分ける（本記事で詳しく解説） 毎日実行するフローを1つ作成し、「今日が対象の日付かどうか」を条件で判断する 本記事では方法2を詳しく解説します。 フローの作成手順 1. トリガーの設定 Teams アプリ内の Power Automate から新しいフローを「一から作成」します。トリガーには「組み込み」の「繰り返し」を選択します。 間隔：1 頻度：日 開始時刻：任意の日付・時刻（例：午前10時） タイムゾーン：(UTC+09:00) 大阪、札幌、東京 タイムゾーンは日本時間に合わせておくと管理しやすくなります。 2. 現在の日本時間を取得する 繰り返しトリガーの直後に、現在時刻を日本標準時に変換するアクションを追加します。 アクション：タイムゾーンの変換 基準時刻：utcNow()（現在のUTC時刻） 変換元のタイムゾーン：(UTC) 協定世界時 変換先のタイムゾーン：(UTC+09:00) 大阪、札幌、東京 Power Automate の utcNow() は UTC で時刻を返すため、そのまま使うと日本時間と最大9時間ずれが生じます。必ずタイムゾーン変換を行ってから日付を取得してください。 変換を省略すると、日付が変わる前後の時間帯で意図しない動作になる可能性があります。 3. 日付の「日」部分を取得する タイムゾーン変換後の時刻から、「何日か」だけを取り出します。ここでは dayOfMonth() 関数を使います。 アクション：データ操作 > 作成 入力欄に以下の式を入力します。 ...

この記事の内容 Power Automate / Logic Apps で時間のかかる処理を非同期実行に切り替える方法を紹介します 同期実行の問題点（長い待ち時間・タイムアウト）を実例で確認します わずか1クリックの設定変更で非同期レスポンスを実現できることを解説します 非同期実行時のレスポンス構造（HTTPステータス・Locationヘッダー）を説明します ポーリングによる実行状況の確認方法を紹介します 同期実行の問題点 Power Automate や Logic Apps で HTTP の要求を受信するトリガーを使ったフローを作成する場合、デフォルトでは同期実行となります。つまり、フローの処理がすべて完了してから呼び出し元にレスポンスが返されます。 今回の例では、GETリクエストを受け取ったら1分間待機し、その後「1分間待ってから最後まで実行されました」というメッセージを返すシンプルなフローを使います。 このフローを実際にブラウザや Postman（Web ブラウザ版）から呼び出すと、次のような問題が発生します。 ブラウザ: リクエストを送信してから1分間、ぐるぐると応答待ちになります Postman（Web版）: 30秒以上レスポンスが返ってこなかった場合、タイムアウトエラーになります 実際のユースケースでは、この「1分待ち」の部分が重たいバックエンド処理に相当します。ユーザーを長時間待たせるのは良いユーザー体験とは言えません。また、クライアント側のタイムアウト設定によっては、処理が正常に完了していても「失敗」として扱われてしまいます。 非同期実行への切り替え方 Power Automate / Logic Apps には、この問題を解決するための設定が用意されています。設定変更はわずか1ステップです。 手順: HTTP 要求受信トリガーの設定を開きます 「応答の設定」から 「非同期応答（Asynchronous Response）」 を有効にします たったこれだけで、フローが非同期実行モードに切り替わります。コードの変更やフローの構造変更は一切不要です。 非同期実行時のレスポンス構造 非同期応答を有効にした状態で同じURLにGETリクエストを送ると、動作が大きく変わります。 即時レスポンス リクエストを送信すると、処理の完了を待たずにすぐにレスポンスが返ってきます。このレスポンスの内容は以下のようなものです。 ステータスコード: 202 Accepted（受け付けました、という意味） ボディ: {"status": "Running"} など、現在実行中であることを示す情報 Locationヘッダー: 実行結果を確認するための URL Locationヘッダーの役割 非同期レスポンスのポイントは Locationヘッダー にあります。このヘッダーには、実行結果を取得するための専用 URL が含まれています。 L o c a t i o n : h t t p s : / / p r o d - x x . j a p a n e a s t . l o g i c . a z u r e . c o m / w o r k f l o w s / . . . / r u n s / x x x . . . / a c t i o n s / . . . この URL は実行ごとに異なるものが発行されます。同じフローを複数回呼び出した場合、それぞれ異なる Location URL が返されます。 ...

Power Automate で Microsoft Graph REST API の JSON レスポンスを扱いやすくする この記事の内容 Power Automate の「JSON の解析」アクションを使って Graph API のレスポンスを構造化する方法を解説します サンプル JSON からスキーマを自動生成する手順を紹介します 単一オブジェクトと複数オブジェクトそれぞれのパース手順を説明します スキーマの自動生成時に発生しやすい null 関連エラーとその対処法を紹介します パース後のデータをフロー内で自由に活用できるようにするところまで解説します はじめに この記事は、Power Automate で Microsoft Graph REST API を呼び出す方法を解説した前回の続きです。前回は HTTP アクションを使って Graph API のエンドポイントを叩き、JSON 形式のレスポンスを受け取るところまで行いました。今回はその結果を Power Automate のフロー内で扱いやすい形にする、つまり JSON のパース（解析） を行う方法を解説します。 JSON の解析アクションを追加する Graph API から返ってくるレスポンスは JSON 形式です。そのままでは後続のアクションで個々のプロパティを取り出しにくいため、Power Automate の組み込みアクション「JSON の解析」を使います。 手順は以下のとおりです。 HTTP アクションのあとに新しいステップを追加します 「データ操作」 の中から 「JSON の解析」 を選択します 「コンテンツ」に前のステップ（HTTP アクション）の 「本文（応答の内容）」 を指定します スキーマをサンプルから自動生成する 「JSON の解析」アクションでは、解析対象の JSON がどのような構造をしているかをスキーマとして指定する必要があります。スキーマを手書きするのは難しいため、「サンプルから生成」 機能を使うのが簡単です。 ...

Power Automate で Microsoft Graph API を実行する方法 ─ Azure AD 認証も簡単！ この記事の内容 Microsoft Graph API の概要と「単一エンドポイント」というコンセプトを解説します Graph Explorer を使って API を手軽に試す方法を紹介します Power Automate の「HTTP with Azure AD」コネクタを使うと Azure AD 認証を省略できます Graph Explorer の設定値を Power Automate にそのまま貼り付けるだけで API 呼び出しが完成します グループ作成などの POST リクエストや、入力パラメーターの変数化まで実践的な手順を紹介します Microsoft Graph API とは Microsoft Graph API は、Microsoft 365・Windows・Enterprise Mobility + Security などのサービスに対して、単一のエンドポイントからアクセスできる API です。メール・カレンダー・OneDrive・Excel・ユーザー・グループなど、Microsoft 365 のほぼすべての機能を 1 つの入り口から操作できます。 エンドポイントは以下の 1 つだけです。 h t t p s : / / g r a p h . m i c r o s o f t . c o m 「API を叩けばなんでもできる」と聞いても、開発者でない方には難しく感じるかもしれません。しかし Power Automate を使えば、プログラミングの知識がなくても Graph API を簡単に呼び出せます。 ...

Azure Key Vault 概要とマネージドIDの解説 この記事の内容 Azure Key Vaultはキー・シークレット・証明書を一元管理するためのサービスです 複数のアプリケーションやサービスが増えたとき、個別管理の課題（更新漏れ・トラブル）を解消できます Logic Appsを使ったKey Vaultへのアクセスデモを通じて、基本操作を確認します Key Vaultへのアクセス方法として、ユーザーID・サービスプリンシパル・マネージドIDの3パターンがあります マネージドIDを使うことで、アプリケーション内に認証情報を埋め込まずにKey Vaultへアクセスできます Azure Key Vaultとは Azure Key Vaultは、キー・シークレット・証明書を集中管理するためのサービスです。 皆さんもパスワードや証明書、接続文字列などを個別に利用されていることと思います。個別に使うだけであれば問題ないのですが、複数のアプリケーションやサービスにまたがって管理しようとすると、Key Vaultが非常に役立ちます。 なぜ一元管理が必要なのか 個別管理の問題点 たとえば、SQLデータベースの接続文字列やパスワードをアプリケーションのコード内に直接埋め込むことは技術的には可能です。アプリケーションが1つのうちはシンプルで動作します。 しかし、アプリケーションやサービスが増えていくと、認証情報の管理ポイントが各所に分散してしまいます。 特に問題になるのが更新・ローテーションのタイミングです。鍵が漏洩した場合や証明書の有効期限が近づいた場合には、使用しているすべての箇所で更新が必要になります。更新し忘れた箇所が1つでもあると、そこでエラーが発生してしまいます。証明書の更新ミスによってパブリッククラウドのサービスが停止するという事例も実際に起きています。 一元管理のメリット Key Vaultを間に挟むことで、この問題を解決できます。 Key Vault内で一箇所更新すれば、それを参照しているすべてのアプリケーションに自動的に反映されます 複雑な構成になってもシンプルさを保てます 「間に1クッション挟む」というのはKey Vaultに限った話ではありません。一見すると無駄に見えますが、規模が大きくなったときにシンプルさを維持するための仕組みとして、さまざまな場面で使われているパターンです。 Key Vaultの利用パターン アプリケーションからのシークレット取得 最も典型的な利用例は、アプリケーションがパスワードや接続情報をKey Vaultから取得するパターンです。アプリケーションのコードに直接認証情報を書くのではなく、Key Vaultから取得するように実装します。 ディスク暗号化への応用 仮想マシンのディスクを独自のキーで暗号化したい場合にも、Key Vaultが使われます。ディスク暗号化セットを作成してKey Vaultと組み合わせることで、仮想マシンのディスク暗号化を一括管理できます。 Key Vaultの作成手順 Azureポータルからキー コンテナーを作成します。 基本設定 項目 内容 リソースグループ 任意のグループを指定 地域 例：東日本 価格レベル 標準 または Premium 価格レベルについて：Premiumを選択するとHSM（ハードウェア セキュリティ モジュール）を使ったキー管理が利用できます。通常は標準で問題ありません。 アクセス制御の設定 Key Vaultのアクセス制御には2つの方式があります。 アクセスポリシー：Key Vault独自のアクセス制御。取得・一覧・更新・作成などの操作を個別に細かく設定できます Azureロールベースのアクセス制御（RBAC）：通常のAzure RBACと同じ仕組みで管理します これから新しく構成するのであれば、Azure RBACを選択することをおすすめします。 ...

Logic Apps で Event Hub からイベントを受け取るときにハマったことメモ この記事の内容 Logic Apps と Event Hub を組み合わせた構成でハマったポイントをまとめています JSON 解析時に使用するフィールド名（コンテント vs ボディ）の違いによるトラブル Base64 エンコードされたコンテンツの扱いについての注意点 JSON スキーマを正しく生成するための実践的な手順 Logic Apps デザイナーの挙動が不安定なケースについての記録 作ったものの概要 今回作成した Logic Apps は以下のような構成です。 Event Hub からイベントを受け取る 受け取ったデータが JSON 形式なので JSON を解析する データの元は Twitter のツイートで、Azure Cognitive Services を使って感情分析を行う 感情が肯定的・否定的かどうかを判定して、条件に応じてメールを送信する シンプルな構成ではありますが、いくつかハマりポイントがありました。 ハマりポイント①：JSON 解析で使うフィールドが「コンテント」でないといけない Event Hub から受け取ったイベントの本文を参照しようとしたとき、「本文」や「ボディ（Body）」といった項目を選んだところ、うまく動作しませんでした。 正しくは 「コンテント（Content）」 を選択する必要があります。 日本語と英語でフィールド名が混在していたり、参照していた英語のドキュメントでは “Body” と記載されていたりと、どの項目を選べばよいか混乱しやすい部分です。同じ意味に見えても動作が変わるため、注意が必要です。 ハマりポイント②：コンテンツが Base64 エンコードされて届く場合がある 実行後の出力を確認したところ、コンテントのデータが Base64 エンコードされた文字列 として届いていることがありました。 「デコードが必要なのかな？」と悩みましたが、調べたところ 暗黙的にデコードが行われる ことが仕様として記載されていました。実際、再確認した時点では Base64 のままではなくデコード済みの状態で返ってきていたため、自分でデコード処理を追加する必要はありませんでした。 ただし、このあたりの動作は状況によって変わることがあり、挙動が安定しない場面もありました。 ハマりポイント③：JSON スキーマの生成は「実データ」で行う JSON の解析アクションでは、スキーマを用意する必要があります。Logic Apps には「サンプルのペイロードを使用してスキーマを生成」する機能があります。 ...