Power Automate(パワーオートメイト)は、Outlook・Teams・SharePoint のような Microsoft のサービス同士なら、用意されたコネクタを並べるだけでつながります。困るのは、会社の仕事が Microsoft の外にもあるときです。ホームページの問い合わせフォーム、協力会社との受発注サービス、クラウド会計、LINE公式アカウント。コネクタが無い、あっても欲しい操作が無い、という場面で使うのが HTTP アクションとカスタムコネクタです。この記事では、社員15名の「サンプル工務店」を例に、外の API を呼ぶ手順、外からフローを動かす手順、カスタムコネクタを作る場面、APIキーの置き場所、そして Premium を買わずにつなぐ代わりの手までを書きます。クラウドフローを1本以上作ったことがある前提です。
この記事の内容
先に決めること
1. どちら向きにつなぐか
外とつなぐ形は2つしかありません。Power Automate から外のサービスを呼ぶ「外へ」と、外のサービスから Power Automate を動かす「外から」です。サンプル工務店では、発注リストで「発注確定」にした行を受発注サービス(order.example)に送るのが「外へ」、ホームページ(sample-koumuten.example)のフォームが送信されたら SharePoint の問い合わせ台帳に入れるのが「外から」です。外へは HTTP アクション、外からは「HTTP 要求を受信した場合」トリガーを使います。
2. Premium を誰に付けるか
HTTP アクションとカスタムコネクタは Premium の扱いで、Microsoft 365 Business Standard に付いてくる Power Automate では使えません(2026年10月時点)。「HTTP 要求を受信した場合」トリガーは、公式のドキュメントにライセンスの記載がなく、Premium の表示が付くことが多いので、使う前にデザイナーの表示とライセンスを確かめます。フローを作って持つ人に「Power Automate Premium」(1ユーザーごとのライセンス)を付けるか、そのフローに「Power Automate Process」(1フローごとのライセンス)を付けます。サンプル工務店では、外とつなぐフローは事務Bがまとめて持つことにして、事務B1人に Power Automate Premium を付けました。誰が持つかを先に決めておかないと、作った人だけが Premium を持っていて、その人が異動したらフローが止まる、ということになります。
3. 相手の API の認証方式を確かめる
外の API は、たいてい「APIキー(トークン)をヘッダーに付ける」「ユーザー名とパスワード」「OAuth 2.0」のどれかで本人確認をします。相手のサービスの開発者向けページで、URL・メソッド・必要なヘッダー・本文の形・返ってくる形を先に控えておきます。ここが分からないまま組み始めると、401 の原因が自分の設定なのか相手の仕様なのか切り分けられません。
4. 公式のコネクタが無いか先に探す
HTTP アクションで何でも呼べますが、公式のコネクタがあればそちらが楽です。接続の画面でサインインするだけで済み、トークンの期限切れもコネクタが面倒を見ます。次の表で、よく聞かれるサービスのコネクタの有無を先に確かめてください。
外のサービスとコネクタの有無
コネクタのリファレンスで確かめた内容です(2026年10月時点)。区分が「標準」なら Microsoft 365 のライセンスで使え、「Premium」なら Power Automate Premium などが要ります。
| サービス | コネクタ | 区分 | 補足 |
|---|---|---|---|
| Slack | 「Slack」(Microsoft 提供) | 標準 | メッセージの投稿などが標準の範囲でできる |
| Gmail | 「Gmail」(Microsoft 提供) | 標準 | 個人の Gmail アカウント(@gmail.com)は組み合わせられるサービスが限られる |
| kintone | 「kintone」(サイボウズ提供) | Premium | プレビュー。足りない操作は HTTP アクションで kintone の REST API を呼ぶ |
| Salesforce | 「Salesforce」(Microsoft 提供) | Premium | コネクタの中に「HTTP 要求を送信する」があり、REST API を直接呼べる |
| LINE | 「LINEメッセージ (インディペンデントパブリッシャー)」 | Premium | 個人の開発者が公開したプレビュー。操作は「ユーザーにメッセージを送信する」の1つだけ |
| クラウド会計・受発注サービスなど | 多くは無い | ー | 相手が API を公開していれば HTTP アクションかカスタムコネクタでつなぐ |
| n8n | 無い | ー | n8n の Webhook と HTTP アクション、または SharePoint 経由でつなぐ |
LINE のコネクタは Microsoft でも LINE 社でもない個人が公開したもので、接続ごとに60秒100回までの制限があります。業務で長く使うなら、LINE の Messaging API を HTTP アクションで呼ぶほうが、仕様の変化に自分で追いつけます。

HTTP アクションで外の API を呼ぶ
サンプル工務店の「発注」リストで、事務Bが状態を「発注確定」にしたら、受発注サービスの API に発注を登録し、返ってきた発注番号をリストに書き戻すフローを作ります。受発注サービスの API は次の形とします(説明のための架空の API です)。
POST https://api.order.example/v1/orders
Authorization: Bearer xxxxxxxx
Content-Type: application/json
{"supplier_code": "K-012", "title": "〇〇様邸 浴室 ユニットバス", "amount": 680000, "due_date": "2026-11-20"}
成功すると状態コード 201 と、{"order_id": "PO-2026-0153", "status": "accepted"} のような JSON が返ってきます。
手順
- 「マイ フロー」→「新しいフロー」→「自動化したクラウド フロー」を選び、トリガーに SharePoint の「アイテムが作成または変更されたとき」を選ぶ
- トリガーの「サイト アドレス」に「工事案件」サイト、「リスト名」に「発注」を選ぶ
- トリガーの「設定」タブの「トリガー条件」に、状態が「発注確定」で発注番号が空のときだけ動く条件を入れる(下の式)
- 「+」→「アクションの追加」で「HTTP」と検索し、組み込みの「HTTP」を選ぶ
- 「URI」に
https://api.order.example/v1/orders、「メソッド」にPOSTを入れる - 「ヘッダー」に
Content-Typeとapplication/json、AuthorizationとBearer xxxxxxxxを入れる(トークンの置き場所は後の節で直す) - 「本文」に下の JSON を入れ、値の部分は動的コンテンツから選ぶ
- 保存して、発注リストで1行を「発注確定」にしてテストする
トリガー条件の式は次のとおりです。列の内部名はリストの設定で確かめます。
@and(equals(triggerOutputs()?['body/Status/Value'], '発注確定'), empty(triggerOutputs()?['body/OrderNo']))
本文は、動的コンテンツを差し込むと次の形になります。金額は文字列ではなく数値で送るので、引用符で囲みません。
{
"supplier_code": "@{triggerOutputs()?['body/SupplierCode']}",
"title": "@{triggerOutputs()?['body/Title']}",
"amount": @{triggerOutputs()?['body/Amount']},
"due_date": "@{formatDateTime(triggerOutputs()?['body/DueDate'], 'yyyy-MM-dd')}"
}

認証の種類
ヘッダーに直接トークンを書く以外に、HTTP アクションの「高度なパラメーター」にある「認証」で、「なし」以外の方式を選べます。公式のドキュメントに載っている方式は次のとおりです。画面での日本語の名前は、選ぶときに確かめます。
| 方式 | 使う場面 |
|---|---|
| 基本認証 | ユーザー名とパスワードで本人確認する API |
| クライアント証明書 | 証明書ファイル(PFX)で本人確認する API |
| Active Directory OAuth | Microsoft Entra ID に登録したアプリで、Microsoft Graph などを呼ぶとき |
| 未加工 | Authorization ヘッダーに入れる値をそのまま指定したいとき |
| マネージド ID | Azure のリソースを、資格情報を持たずに呼ぶとき |
「なし」のままヘッダーにトークンを自分で書く形でも、多くの API は呼べます。
返ってきた JSON を読む
HTTP アクションの出力は、そのままでは中身の項目が動的コンテンツに出てきません。「JSON の解析」で形を教えると、order_id のような項目を選べるようになります。
- HTTP アクションの下に「データ操作」の「JSON の解析」を追加する
- 「コンテンツ」に HTTP アクションの「本文」を選ぶ
- テストで一度動かし、実行履歴の HTTP アクションの出力から本文の JSON をコピーする
- 「JSON の解析」の「サンプルから生成」に貼り付けて「完了」を選ぶ
- SharePoint の「項目を更新する」を追加し、「発注番号」に「JSON の解析」の
order_idを入れる

動的コンテンツを使わずに式で取り出すこともできます。アクション名に空白があるときは _ に置き換えます。
body('JSON_の解析')?['order_id']
outputs('HTTP')?['statusCode']
失敗したときの扱い
相手の API が 400 や 500 を返すと、HTTP アクションは「失敗」になり、後ろのアクションは動きません。401 はトークンの期限切れか書き間違い、404 は URL の誤り、429 は呼びすぎです。429 や一時的な 500 番台は、アクションの「設定」タブの再試行ポリシーで自動的にやり直されます(Microsoft 365 のライセンスと同じ「低」のパフォーマンス プロファイルでは既定2回、Premium では回数が増えます)。失敗をTeamsに知らせる作り方は、エラー処理の記事のスコープの作り方がそのまま使えます。
なお、外への1回の呼び出しは120秒で打ち切られます。相手の処理に時間がかかる API は、相手が「受け付けた」とすぐ返して後から結果を取りに行く形(202 を返して状態を確かめる URL を教える形)になっているか、開発者向けページで確かめます。
「HTTP 要求を受信した場合」で外からフローを動かす
今度は逆向きです。ホームページの問い合わせフォームが送信されたら、フォームの仕組み(またはn8n)がフローの URL に JSON を送り、フローが問い合わせ台帳に1行追加して、Teams の「営業」チームに知らせます。
手順
- 「マイ フロー」→「新しいフロー」→「インスタント クラウド フロー」→「スキップ」でデザイナーを開く
- トリガーの追加で「要求」と検索し、組み込みの「HTTP 要求を受信した場合」を選ぶ
- 「フローをトリガーできるのは誰ですか?」で、呼べる人を選ぶ(下の表)
- 「要求本文の JSON スキーマ」の「サンプルのペイロードを使用してスキーマを生成する」を選び、フォームが送る JSON の見本を貼る
- SharePoint の「項目を作成する」で問い合わせ台帳に1行追加する
- Teams の「チャットまたはチャネルでメッセージを投稿する」で、「次のように投稿する」を「Flow ボット」、「投稿」を「チャネル」にして「営業」チームに知らせる
- 「要求」の「応答」を追加し、「状態コード」に
200、「本文」に{"result": "ok"}を入れる - 保存すると、トリガーに「HTTP URL」が表示されるのでコピーする
フォームが送る JSON の見本と、そこから作られるスキーマは次のとおりです。
{
"type": "object",
"properties": {
"name": {"type": "string"},
"tel": {"type": "string"},
"email": {"type": "string"},
"message": {"type": "string"}
},
"required": ["name", "message"]
}

動くかどうかは、パソコンのターミナルから curl で送って確かめられます。URL はトリガーに表示されたものをそのまま貼ります。
curl -X POST "https://xxxxxxxx/workflows/xxxxxxxx/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=xxxxxxxx" \
-H "Content-Type: application/json" \
-d '{"name":"山田 太郎","tel":"090-0000-0000","email":"taro@example.com","message":"浴室のリフォームを相談したい"}'
「フローをトリガーできるのは誰ですか?」の選択肢
| 選択肢 | 動かせる人 | 向いている相手 |
|---|---|---|
| 任意のユーザー | URL を知っている人なら誰でも(追加の認証が無い、以前からのレガシーの設定) | ホームページのフォーム、n8n など社外の仕組み |
| 自分のテナント内のすべてのユーザー | 同じ Microsoft 365 の人が取ったトークンを付けた要求だけ | 社内のプログラムや、Entra ID でトークンを取れる仕組み |
| テナント内の特定のユーザー | 「許可されたユーザー」に入れた人(サービス プリンシパルも可)だけ | 決まったアプリだけに動かさせたいとき |
テナントに絞る2つを選ぶと、呼ぶ側は Microsoft Entra ID で取ったトークン(対象が https://service.flow.microsoft.com/ のもの)を Authorization ヘッダーに付ける必要があります。ホームページのフォームからそのまま送ることはできないので、社外の仕組みから呼ぶなら「任意のユーザー」を選ぶことになります。
「任意のユーザー」の URL には、末尾に sig= で始まる署名が付いています。これが合言葉の代わりで、URL が漏れれば誰でもフローを動かせます。URL をメールやチャットに貼らない、ホームページの HTML に直接書かずサーバー側の設定に置く、受け取った値は「項目を作成する」の前に長さや形を確かめる、の3つを守ります。漏れたときは SAS キーを作り直すと sig= の値が変わり、古い URL は使えなくなります。ただし作り直しの手順は、ブラウザの開発者ツールで要求を組み立てる形で、画面のボタンはありません。

応答は2分以内に返す
外から呼ぶ側は、フローの返事を最長120秒まで待ちます。問い合わせ台帳への追加のように時間のかからない処理は「応答」を最後に置けば済みます。時間のかかる処理は「応答」を先頭近くに置いて先に返事を返し、そのあとで重い処理を続けます。
カスタムコネクタを作る
HTTP アクションは1つのフローの中だけの設定です。同じ API を複数のフローから何度も呼ぶなら、カスタムコネクタにまとめると、URL や認証を1か所で持てて、フローの中では公式コネクタと同じようにアクションを選ぶだけになります。サンプル工務店では、受発注サービスへの「発注を登録」「発注の状態を取得」「発注を取り消す」を3本のフローで使うようになった時点で、カスタムコネクタに切り替えました。カスタムコネクタも Premium の扱いです。
作り方は2通りあります。相手が OpenAPI(Swagger)の定義ファイルを公開していればそれを読み込み、無ければ空白の状態から操作を書きます。ここでは定義ファイルが無い場合の手順を書きます。
- 左のメニューの「ソリューション」で、外とつなぐフローを入れるソリューションを開く
- 「新規」→「自動化」→「カスタム コネクタ」を選ぶ
- 「空白から作成」を選び、コネクタの名前を付ける(定義ファイルがある場合は、取り込むための選択肢を選ぶ)
- 「全般」でホスト(
api.order.example)とベース URL(/v1)を入れる - 「セキュリティ」で認証の種類を選ぶ(受発注サービスなら「API キー」、パラメーター名
Authorization、場所はヘッダー) - 「定義」で「新しいアクション」を選び、「要求」の「サンプルからインポート」に URL・メソッド・本文の見本を貼る
- 「応答」の「既定の応答を追加する」に返事の見本を貼る
- 「コネクタの作成」を選んで保存する
- 「テスト」で「新しい接続」を作り、APIキーを入れて操作を試す

| タブ | 決めること |
|---|---|
| 全般 | アイコン、説明、ホスト、ベース URL |
| セキュリティ | 認証なし・基本認証・API キー・OAuth 2.0 のどれか |
| 定義 | アクション(とトリガー)ごとの URL・メソッド・入力・出力 |
| コード | 送る前・受けた後に値を加工したいときの C# のコード(任意) |
| テスト | 接続を作って実際に呼び、返事を確かめる |
できたコネクタは、フローの「アクションの追加」で「カスタム」から選べます。APIキーはコネクタの接続に保存され、フローの中には出てきません。
APIキーとトークンの置き場所
HTTP アクションのヘッダーにトークンをそのまま書くと、フローを共有した人、フローをエクスポートしたファイルを受け取った人、実行履歴を見られる人の全員にトークンが見えます。置き場所は次の順で考えます。
| 置き場所 | 見える範囲 | 向いている場面 |
|---|---|---|
| フローに直書き | 編集者・実行履歴を見る人・エクスポート先 | 使わない |
| 直書き+「安全な入力」「安全な出力」をオン | 編集者には見える。実行履歴では隠れる | とりあえずの対策 |
| カスタムコネクタの接続 | 接続を作った人だけ | 同じ API を何本ものフローで使う |
| 環境変数(テキスト) | 環境変数を編集できる人 | URL や設定値を本番と試験で切り替える |
| 環境変数(シークレット)+ Azure Key Vault | Key Vault の権限を持つ人だけ | トークンを社内の決まりで管理する会社 |
「安全な入力」「安全な出力」は、アクションの「設定」タブにあります。オンにすると、実行履歴でそのアクションの入力や出力が隠れます。HTTP アクションの両方と、トークンを扱う前後のアクションに付けておきます。

環境変数は、ソリューションの中で「新規」→「その他」→「環境変数」から作り、フローの中では動的コンテンツから選びます。値を変えれば、フローを1本ずつ開かずに全部の参照先が変わります。トークンの値そのものを Microsoft の外の金庫に置きたい会社は、Azure Key Vault にシークレットとして保存し、種類が「シークレット」の環境変数からそれを指します。シークレットの環境変数は動的コンテンツの一覧には出てきません。フローの中では Microsoft Dataverse コネクタの「バインドされていないアクションを実行する」で RetrieveEnvironmentVariableSecretValue を選び、環境変数の表示名ではなく一意の名前を指定して値を取り出します。値を取り出したアクションには「安全な出力」、その値を使う HTTP アクションには「安全な入力」と「安全な出力」を付けます。Azure の契約と Key Vault の権限設定が要るので、社員15名の会社なら、まずカスタムコネクタの接続に置く形で十分です。
Premium なしでつなぐ代わりの手
外とつなぐフローが1本か2本で、Premium を買うほどではない場合の手です。
メール経由
外のサービスがメールを送れるなら、メールを受け口にします。サンプル工務店のホームページの問い合わせフォームは、もともと info@sample-koumuten.example にメールを送る作りです。Office 365 Outlook の「共有メールボックスに新しいメールが届いたとき (V2)」は標準のトリガーなので、件名で問い合わせだけを拾い、本文から式で名前や電話番号を取り出して問い合わせ台帳に入れられます。フォームの本文を「お名前:〇〇」のように1行1項目の決まった形にしておくのが条件です。逆向きも同じで、外のサービスがメールの受信を受け口にしているなら、「メールを送信する (V2)」で送れば届きます。
n8n 経由
n8n は、Webhook で受ける、外の API を呼ぶ、という部分が得意です。外とのやり取りは n8n に任せ、結果を SharePoint リストに書き込めば、Power Automate 側は標準の SharePoint のトリガーで続きを動かせます。n8n の「Microsoft SharePoint」ノードには、リストの項目の作成・更新・取得があります。
- ホームページのフォームの送信先を n8n の Webhook にする
- n8n の「Microsoft SharePoint」ノードで、問い合わせ台帳に項目を作成する
- Power Automate は SharePoint の「アイテムが作成されたとき」で動き、Teams に知らせる
外へ送るときは逆にして、Power Automate は SharePoint の発注リストの状態を変えるだけにし、n8n が定期的にリストを読んで受発注サービスの API に送ります。
標準のコネクタで済む相手は標準で
Slack と Gmail は標準のコネクタがあるので、Premium は要りません。HTTP アクションに手を出す前に、上の表のとおりコネクタを探します。
応用:kintone にレコードを登録する
kintone を併用している会社なら、kintone の公式コネクタ(Premium・プレビュー)で足りない操作を、HTTP アクションで REST API を呼んで補えます。レコードを1件登録する API は次の形です。APIトークンは kintone のアプリの設定で発行します。
POST https://xxxxxxxx.cybozu.com/k/v1/record.json
X-Cybozu-API-Token: xxxxxxxx
Content-Type: application/json
{"app": 12, "record": {"顧客名": {"value": "山田 太郎"}, "問い合わせ内容": {"value": "浴室のリフォームを相談したい"}}}
record の中はフィールドコードごとに {"value": ...} の形で書きます。成功すると {"id": "100", "revision": "1"} のようにレコード番号が返るので、「JSON の解析」で id を取り出して問い合わせ台帳に書き戻せば、どちらから見ても同じ問い合わせを追えます。
できないことと、その代わり
| できないこと | 代わりの手 |
|---|---|
| Microsoft 365 のライセンスだけで HTTP アクションを使う | Power Automate Premium か Process を付ける。メール経由・n8n 経由にする |
| 「HTTP 要求を受信した場合」の URL を自分で決める | URL は Power Automate が決める。変わったときに直す場所を1か所にする(n8n の設定など) |
| 2分を超える処理の結果を同じ要求で返す | 先に「応答」を返し、結果はメールや Teams で知らせる |
| 画面のボタンで SAS キーを作り直す | 開発者ツールでの手順を使うか、フローをコピーして新しい URL に切り替える |
| 社外の仕組みから、Entra ID のトークン無しでテナント限定のトリガーを呼ぶ | 「任意のユーザー」にして、受け取った値の検証を厚くする |
よく詰まるところ
| 症状 | 原因 | 直し方 |
|---|---|---|
| HTTP アクションが検索に出ない | Premium のライセンスが無い、または DLP ポリシーで止められている | ライセンスを確かめる。管理者に DLP の設定を確かめてもらう |
| 401 が返る | トークンの書き間違い、Bearer の後の空白抜け、期限切れ | 実行履歴で送ったヘッダーを確かめる。トークンを発行し直す |
| 400 が返る | 本文の JSON の形が違う。数値を引用符で囲んだ、日付の形式が違う | 実行履歴の入力を相手の見本と並べて比べる |
| 415 が返る | Content-Type が無い、または違う | ヘッダーに Content-Type: application/json を入れる |
| 「JSON の解析」で失敗する | 返事に null の項目があり、スキーマで型を1つに決めている | スキーマのその項目を "type": ["string", "null"] にする |
| 外から呼んでもフローが動かない | URL が古い。2025年11月30日に古い形式の URL は止まった | フローの詳細ページかトリガーで今の URL を確かめ、呼ぶ側を直す |
| 呼ぶ側が URL を保存できない | 新しい URL が255文字を超え、呼ぶ側の欄に入らない | 呼ぶ側の欄の長さを変える。無理なら n8n などを間に置く |
| 呼ぶ側に 401 が返る | 「フローをトリガーできるのは誰ですか?」がテナント限定になっている | 社外から呼ぶなら「任意のユーザー」にする |
| 呼ぶ側がタイムアウトになる | 「応答」まで120秒を超えている | 「応答」を前に置き、重い処理は後ろに回す |
| 同じ問い合わせが2行できる | 呼ぶ側が返事を待てずに送り直した | 「応答」を早く返す。追加の前に同じメールアドレスと日時の行を探す |
| 発注が二重に登録される | トリガー条件が無く、発注番号を書き戻した変更でまたフローが動いた | 「発注番号が空のときだけ」のトリガー条件を入れる |
| 429 が返り遅くなる | ループの中で相手の API を呼びすぎ | 件数を絞る。「延期」を入れる。相手の回数制限を確かめる |
次にやること
外とつなぐ形ができたら、費用と組み合わせを決めます。
- Premium をどこまで買うか決めるなら「Power Automateの料金とライセンス:Microsoft 365に含まれる範囲とPremiumが要る場面」
- 本文の JSON や返事の値を式で整えるなら「Power Automateの式と変数:日付・文字列・配列をよく使う関数で扱う」
- 外とのつなぎを他のフローとどう組み合わせるか見るなら「Power Automateの活用事例:小さな会社でよく作るフロー15本と組み合わせ方」
- 外のサービスが中心の仕事で、Power Automate でやるべきか迷うなら「Power AutomateとRPA・n8n・Zapierの比較:どれを選ぶか」