Power Appsでメール送信する方法 SendEmailV2の書き方と添付ファイル・エラー対処を解説

申請フォームを作ったものの、送信ボタンを押したあとに担当者へ連絡が飛ばない。作業報告をアプリで受け付けても、結局は誰かが手動でメールを打ち直している。Power Appsを社内で使い始めると、ほぼ必ずこの「通知をどうするか」という課題に行き当たります。

Power Appsからのメール送信は、Office 365 Outlookコネクタを追加してボタンに数式を1行書くだけで動きます。ただし、複数宛先の渡し方、本文の改行、添付ファイルの形式、そして誰の名前で送られるのかといったところでつまずく人が多く、ここを知らないまま作ると後から作り直すことになります。

本記事では、2つの送信方法とその選び分けから、基本の実装手順、宛先や本文の作り込み、添付ファイル、送信元と権限、送れないときの切り分け方までを順番に整理します。読み終えたときに、自社の要件に合う実装方針を選べる状態を目指します。

確認したいポイント	結論	詳細
Power Appsでメール送信するには？	Outlookコネクタで送れる	Office 365 Outlookを追加し、ボタンのOnSelectでSendEmailV2を呼び出すのが基本形です。
使うべき関数はどちら？	SendEmailV2を使う	SendEmailは非推奨です。古い記事の数式をそのまま貼ると非推奨側を使ってしまうため注意します。
複数宛先やCCは指定できる？	区切り文字の文字列で渡す	宛先はセミコロン区切りの1つの文字列、CCやBCCは第4引数のレコードで指定します。
誰の名前で送信される？	ボタンを押した人の名義	送信元を変えるにはそのアドレスからの送信権限が必要です。システム名義ならフロー経由も検討します。

この記事でわかること

• Office 365 Outlookコネクタで送る方法と、Power Automateを経由する方法の使い分け
• SendEmailV2の構文と、CC・BCC・返信先・重要度を指定する書き方
• コンボボックスで選んだ複数の宛先を、正しい形式でまとめて渡す方法
• カメラ画像や添付コントロールのファイルをメールに添付する手順
• 送信元を変えたいときの制約と、送れないときに確認すべき箇所

▼ 社内アプリの内製化をどこまで進められるか整理したい方へ Power Platformや生成AIを使った業務効率化の進め方、支援内容、導入までの流れをまとめた資料をご用意しています。 検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

Power Appsからメールを送信する2つの方法

Power Appsでメールを送る手段は1つではありません。アプリから直接送る方法と、Power Automateのフローを呼び出して送る方法があり、それぞれ向いている場面が異なります。ここでは両者の違いと、選び分けの基準を整理します。

Office 365 Outlookコネクタで直接送る

最も手軽なのが、Office 365 Outlookコネクタをアプリに追加し、ボタンの数式から送信する方法です。データの追加からOffice 365 Outlookを選び、職場アカウントで接続するだけで使える状態になります。

この方法の利点は、実装が数分で終わることと、送信結果をアプリ側ですぐ受け取れることです。エラーが起きた場合もアプリ内で捕捉でき、ユーザーに即座にメッセージを返せます。

一方で、送信ロジックがアプリの数式の中に埋め込まれるため、内容が複雑になるほど保守しづらくなります。宛先の判定条件が増えたり、承認結果によって文面を変えたりする場合は、後述する方法を検討したほうが扱いやすくなります。

Power Automateのフローを呼び出して送る

もう1つが、Power Automateでメール送信のフローを作り、Power Appsから呼び出す方法です。送信処理をアプリの外に切り出せるため、条件分岐や承認プロセスを組み込みやすくなります。

フロー側では、承認依頼の送信、送信結果のログ記録、失敗時の再試行といった処理も組めます。同じフローを複数のアプリから呼び出せる点も、社内で横展開するうえでは効いてきます。

ただし、アプリとフローの2か所を管理することになり、どちらに何が書いてあるかを把握しておく必要があります。単純な通知だけであれば、わざわざ分ける必要はありません。

どちらを選ぶかの判断基準

判断の軸は3つです。1つ目は処理の複雑さで、宛先と文面が固定に近いならコネクタ直送、条件によって大きく変わるならフロー経由が向きます。

2つ目は再利用するかどうかです。複数のアプリや画面から同じ通知を出すなら、フローにまとめておくほうが変更時の修正箇所が1か所で済みます。3つ目は記録を残す必要があるかで、いつ誰に何を送ったかを台帳に残したいなら、フロー側で書き込む構成が自然です。

なお、両方を併用しても問題ありません。ユーザーへの即時通知はコネクタ直送、管理者への集計通知はフロー経由というように、役割で分ける設計もよく使われます。

SendEmailとSendEmailV2の違い

コネクタ直送を選んだ場合、数式の候補にSendEmailとSendEmailV2の2つが表示されます。結論として、新規に作るなら必ずSendEmailV2を使ってください。SendEmailは非推奨となっており、今後の保守を考えると選ぶ理由がありません。

古い記事や公式ドキュメントの一部には、いまだにSendEmailを使った例が残っています。サンプルをそのまま貼り付けると非推奨のほうを使ってしまうことがあるので、関数名は必ず確認してください。

SendEmailV2は戻り値を持つため、送信結果を変数に受け取ることもできます。エラー処理を丁寧に作りたい場合にも、V2のほうが扱いやすくなっています。

コネクタを使った基本の送信手順

ここからは実装に入ります。コネクタの追加、入力欄の配置、ボタンへの数式設定、送信結果の通知という4ステップで、最小構成のメール送信機能が完成します。

コネクタをアプリに追加する

空のキャンバスアプリを作成したら、左側メニューの「データ」から「データの追加」を選び、検索欄にoutlookと入力します。表示されたOffice 365 Outlookを選び、職場アカウントでサインインすると接続が作成されます。

この接続は、作成した本人のアカウントに紐づきます。後でアプリを共有する際には、利用者それぞれが同じコネクタへの接続を持つ必要がある点を覚えておいてください。詳細は権限の章で扱います。

入力用のコントロールを配置する

画面にテキスト入力を3つ配置し、宛先、件名、本文にそれぞれ対応させます。コントロール名は既定のTextInput1のままにせず、txtTo、txtSubject、txtBodyのように役割が分かる名前へ変更しておきます。

名前を整えておくと、数式が読みやすくなるだけでなく、後から画面を修正する人が迷いません。コントロールが増えるほど効いてくるので、最初のうちから習慣にしておくことをおすすめします。

本文欄は、複数行モードに切り替えておきます。既定の1行のままだと改行が入力できず、実際の運用で使いものになりません。

ボタンのOnSelectに数式を設定する

送信ボタンを配置し、OnSelectプロパティに数式を書きます。SendEmailV2の基本構文は、第1引数に宛先、第2引数に件名、第3引数に本文という並びです。第4引数には、CCや添付ファイルなどの任意項目をレコード形式で渡します。

たとえば入力欄の値をそのまま送るなら、Office365Outlook.SendEmailV2(txtTo.Text, txtSubject.Text, txtBody.Text)と書けば動きます。プレビューで実行し、自分宛にテスト送信して届くことを確認してください。

公式の手順はMicrosoft Learn「Power Apps から Office 365 Outlook に接続する」にまとまっています。関数の全パラメーターを確認したい場合も、この系統のドキュメントが正確です。

送信結果をユーザーに伝える

数式を1行書いただけでは、ユーザーには送れたかどうかが分かりません。送信後にNotify関数でメッセージを表示するだけでも、体感は大きく変わります。成功時と失敗時でメッセージを分けておくと親切です。

エラーを捕捉したい場合は、IfError関数と組み合わせます。送信処理をIfErrorで囲み、失敗したときだけ警告メッセージを出す構成にしておけば、ユーザーが気づかないまま送信できていなかった、という事態を防げます。

あわせて、送信中はボタンを無効化する制御も入れておきます。連打による二重送信は、実運用に入ると必ず発生する問題です。変数で送信中フラグを持たせ、ボタンのDisplayModeを切り替える方法が簡単です。

▼ 社内アプリの設計から相談したい方へ どの業務をアプリ化すべきか、どこまで内製で作るかは、業務の実態によって答えが変わります。 現状をうかがったうえで、無理のない進め方をご提案します。 ＞ 相談予約はこちら

宛先・件名・本文を実務向けに作り込む

最小構成が動いたら、実務で使える形に整えていきます。複数宛先の渡し方、CCとBCC、宛先の選択方法、本文の書式の順に、つまずきやすいポイントを押さえます。

複数の宛先を指定する

宛先は1件だけでなく、複数まとめて指定できます。区切り文字でつないだ1つの文字列として渡すのが基本で、セミコロンで連結する形が一般的です。文字列として正しくつながっていれば、件数に制限はありません。

ギャラリーやコンボボックスで選択された複数の値をまとめるには、Concat関数を使います。選択項目のコレクションからメールアドレスの列を取り出し、区切り文字を指定して1つの文字列に結合する、という流れです。

ここで注意したいのが、区切り文字の前後に余計な空白が入るとエラーになる場合があることです。連結後の文字列をラベルに表示して目視確認しておくと、原因不明の送信失敗を避けられます。

CC・BCC・返信先を指定する

第4引数のレコードに、CcやBccといった項目名で値を渡すことで、カーボンコピーやブラインドコピーを設定できます。宛先と同じく、複数指定は区切り文字でつないだ文字列です。

返信先を送信者と別のアドレスにしたい場合は、ReplyToを指定します。個人アカウントから送るけれども返信は部署の共有アドレスで受けたい、といった要件はこれで対応できます。

社外の複数宛先に一斉送信する場面では、BCCの使い分けが重要になります。宛先欄に全員を並べるとアドレスが相互に見えてしまうため、運用ルールとしてどちらに入れるかを決めておいてください。

社内ユーザーから宛先を選ばせる

アドレスを手入力させると、打ち間違いが必ず起きます。Office 365 Usersコネクタを追加し、コンボボックスから社内ユーザーを検索して選ばせる構成にすると、この問題はほぼ解消します。

コンボボックスのItemsにユーザー検索の関数を設定し、選択された項目からメールアドレスに相当する項目を取り出して宛先へ渡します。複数選択を許可しておけば、前述のConcatと組み合わせて一斉送信もできます。

部署単位で宛先を固定したい場合は、SharePointリストなどに宛先マスタを持たせる方法もあります。アプリの数式に直接アドレスを書き込むと、異動のたびに修正が必要になるため、外に出しておくほうが保守が楽です。

HTML本文と改行の扱い

Power Appsから送るメールは、既定でHTMLとして解釈されます。テキスト入力欄に改行を入れても、そのままでは本文で改行として反映されません。ここを知らずに「改行が消える」と悩むケースは非常に多く見られます。

対処は、改行コードをHTMLの改行タグへ置き換えることです。Substitute関数でChar(10)をbrタグに変換してから本文へ渡せば、意図したとおりに改行されます。箇条書きや強調表示をしたい場合も、HTMLタグをそのまま書き込めます。

定型文が長い場合は、リッチテキストエディターコントロールを使う方法もあります。編集結果をHtmlTextプロパティで取得して本文に渡せば、ユーザーが書式を整えたまま送信できます。

重要度を設定する

第4引数にImportanceを指定すると、メールの重要度を設定できます。指定できるのはLow、Normal、Highの3種類で、既定はNormalです。緊急の承認依頼など、埋もれさせたくない通知で活用できます。

ただし、すべての通知を高重要度にすると効果がなくなります。どの条件のときに高にするかを業務ルールとして決め、数式の中で条件分岐させる形にしておくのが現実的です。

添付ファイルを付けて送信する

報告書の写真や申請書のPDFを一緒に送りたい、という要件は頻繁に出てきます。添付ファイルは、決められた列を持つテーブル形式で渡すという点さえ押さえれば、実装は難しくありません。

Attachmentsに渡すテーブルの構造

第4引数のレコードにAttachmentsという項目を追加し、そこにテーブルを渡します。テーブルが持つべき列は、ファイル名を表すNameと、中身のバイナリを表すContentBytesの2つです。

複数のファイルを添付する場合は、このレコードをテーブルの中に並べます。ファイル名には拡張子まで含めて指定してください。拡張子がないと、受信側で正しく開けないことがあります。

既存のコレクションを添付に使う場合、列名が一致していないとエラーになります。RenameColumns関数で列名をNameとContentBytesに合わせてから渡すのが定石です。

カメラやペン入力の内容を添付する

現場で撮影した写真をそのまま送る構成は、Power Appsの強みが出る使い方です。カメラコントロールで撮影した画像をContentBytesに渡すだけで、添付ファイルとして送信できます。

ペン入力コントロールで書いたサインや手書きメモも、同じ要領で添付できます。点検報告や受領確認のように、現場で証跡を残したい業務と相性のよい構成です。

撮影した複数枚をまとめて送る場合は、コレクションに画像を貯めていき、最後にそのコレクションを添付テーブルとして渡します。ファイル名が重複しないよう、連番や日時を付ける処理を入れておいてください。

SharePointなどのファイルを添付する

SharePointに保存されている既存のファイルを添付したい場合は、ファイルの中身を取得する処理が必要になります。この用途では、Power Automateのフローを経由したほうが実装も保守も楽になるケースが多くなります。

フロー側でファイルコンテンツを取得し、そのままメールに添付して送信する構成であれば、アプリ側は必要な情報を渡すだけで済みます。アプリの数式が膨らむのを避けられる点もメリットです。

サイズと件数の注意点

添付ファイルにはサイズの上限があります。メール1通あたりの容量制限はメールサーバー側の設定に従うため、大きなファイルを扱う業務では注意が必要です。高解像度の写真を数枚添付するだけで上限に近づくこともあります。

容量が問題になる場合は、ファイル自体を送るのではなく、SharePointやOneDriveに保存したうえでリンクを本文に記載する方式へ切り替えます。受信側の容量も圧迫せず、後からの参照もしやすくなります。

▼ 「この要件はアプリで実現できるか」から相談できます 添付ファイルの扱い、承認フローとの連携、外部システムとのつなぎ込みなど、設計段階の判断からご相談いただけます。 ＞ 相談予約はこちら

送信元と権限まわりで押さえること

実装が動いても、「誰の名前で送られるのか」を把握していないと運用で問題になります。特に、アプリを他の社員へ共有する段階で表面化しやすい論点を整理します。

既定ではアプリを使った人の名前で送られる

Office 365 Outlookコネクタは、アプリを操作しているユーザー自身のアカウントで接続されます。そのため、送信者はアプリの作成者ではなく、ボタンを押した人になります。

この仕様を知らないと、「システムからの通知のつもりが、担当者個人の名前で届いてしまった」という状況が起きます。受信側にどう見えるかは、実装前に必ず確認しておいてください。

システム名義で送りたい場合は、次に説明する送信元の指定か、Power Automateのフロー経由でサービスアカウントから送る構成を検討します。

送信元を変えるには権限が必要

第4引数にFromを指定すれば、送信元アドレスを変更できます。ただし操作するユーザーに、そのアドレスから送信する権限が付与されている必要があります。権限がなければエラーになり、送信は失敗します。

権限の付与はExchange側の設定になるため、情報システム部門との調整が前提です。アプリを作り始める前に、送信元をどうするかを決めて権限申請しておくと、後戻りを防げます。

共有メールボックスから送る

部署の共有メールボックスから送りたいというニーズもよくあります。Office 365 Outlookコネクタでは、一部の操作でメールボックスアドレスを指定するパラメーターがサポートされています。

なお、アカウントに共有メールボックスへのアクセス権を付与しても、プラットフォーム側に反映されるまで時間がかかる場合があります。設定直後に動かないからといって実装を疑う前に、少し待ってから再確認してください。

アプリ共有時の接続とライセンス

アプリを他の社員に共有する場合、利用者それぞれが同じコネクタへの接続を作成する必要があります。初回起動時に接続の許可を求める画面が出るため、この手順を利用マニュアルに含めておくと問い合わせが減ります。

ライセンスについても事前確認が必要です。使用するコネクタの種類や、Dataverseを使うかどうかによって必要なライセンスが変わります。標準コネクタの範囲で収まるのか、プレミアムコネクタが必要なのかは、設計段階で確認しておいてください。

また、メール送信には1日あたりの上限が存在します。Microsoftのドキュメントでは、宛先やCC、BCCに複数の受信者がいても1通あたり1回の呼び出しとしてカウントされる旨が記載されています。大量送信を伴う用途では、上限に触れないかを事前に見積もってください。

▼ 権限やライセンスの整理からご相談いただけます 社内の運用ルールやセキュリティ方針を踏まえたうえで、現実的な構成をご提案します。 導入前の検討段階でも構いません。 ＞ 相談予約はこちら

メールが送れないときの確認手順

送信されない、エラーが出る、といった状況では、確認する順番を決めておくと原因にたどり着くのが早くなります。数式、接続、データ、そして環境側の制限という順で見ていきます。

数式のエラーと引数の型

最初に確認するのは、数式バーに赤い波線が出ていないかです。よくあるのは、第4引数のレコードの書き方の誤りと、テキストであるべき値に別の型を渡しているケースです。

コンボボックスの選択値をそのまま宛先に渡すと、文字列ではなくレコードのままになっていることがあります。メールアドレスに相当する項目を明示的に取り出しているかを確認してください。

添付ファイルの列名不一致も頻出です。NameとContentBytesという名前になっているか、コレクションの中身をデータ画面で確認すると早く特定できます。

接続の認証が切れている

一定期間が経過したり、パスワードが変更されたりすると、コネクタの接続が無効になって送信が失敗することがあります。数式に問題がないのに突然動かなくなった場合は、まずこれを疑ってください。

確認は、Power Appsの接続一覧から行います。該当の接続にエラー表示が出ていれば、再サインインして復旧させます。利用者側で発生している場合は、その人のアカウントで同じ操作をしてもらう必要があります。

宛先データ側の問題

宛先の文字列に、全角スペースや余分な区切り文字が混ざっていると送信に失敗します。連結処理の結果をラベルに表示して、想定どおりの文字列になっているかを目視で確認するのが最も確実な切り分け方です。

退職者のアドレスが宛先マスタに残っている場合も、エラーの原因になります。マスタの棚卸しをいつ誰が行うのかを、運用ルールとして決めておいてください。

送信上限と迷惑メール判定

一斉送信の件数が多い場合、メールサーバー側の送信上限に達して止まることがあります。一定件数ごとに分割する、時間をずらして送るといった対処が必要になります。

送れているのに届かない場合は、受信側で迷惑メールとして分類されている可能性があります。件名や本文の書き方、外部ドメイン宛ての送信ポリシーを確認してください。社外向けの一斉送信は、そもそも専用のメール配信サービスを使うほうが適切なケースもあります。

実務での使いどころと運用の設計

技術的に送れることと、業務で使い続けられることは別です。どの場面で使うと効果が出るのか、そして作ったアプリをどう維持するのかを整理します。

申請・承認の通知に使う

最も効果が出やすいのが、申請が出されたことを承認者へ知らせる通知です。申請内容の要約と、アプリの該当画面へのリンクを本文に入れておくと、受け取った側がすぐ行動できます。

承認や差し戻しの結果を申請者へ返す通知もセットで用意します。片方向だけの通知は、結局「どうなったか」を口頭で確認する手間を生みます。

定型連絡をテンプレート化する

日報の提出依頼、期限のリマインド、点検結果の共有など、文面がほぼ決まっている連絡はテンプレート化に向いています。文面をSharePointリストなどに持たせ、アプリから読み込んで差し込む構成にしておくと、文言修正のたびにアプリを直す必要がなくなります。

ただし、自動化の前に業務手順そのものを見直すほうが効果が大きい場合もあります。そもそもその連絡が必要なのか、別の手段で代替できないかを一度検討してみてください。業務全体の整理の仕方は業務効率化アイデア55選の記事でもまとめています。

メール以外の通知手段も検討する

社内向けの連絡であれば、メールよりもTeamsへの通知のほうが速く届き、見落とされにくい場合があります。受け取る側が普段どこを見ているかを基準に選ぶのが本来の考え方です。

アプリ内での通知や、一覧画面での未処理件数の表示で足りることもあります。メール送信を実装する前に、「本当にメールでなければいけないのか」を一度問い直してみてください。

作った人に依存しない体制をつくる

内製したアプリで最も多い失敗は、作成者の異動とともに誰も触れなくなることです。総務省の令和7年版情報通信白書では、日本企業がデジタル化に関して認識している課題として「人材不足」が48.7%と最も高く、他国と比べても突出していることが示されています（出典：総務省「令和7年版 情報通信白書」各国企業のデジタル化の状況）。

この状況で外部への丸投げを続けると、社内にノウハウが残らず、小さな修正のたびに費用と時間がかかる構造になります。現実的なのは、最初の数本を伴走しながら一緒に作り、社内に作れる人を育てる進め方です。

命名規則を決める、どの業務のどの工程を代替しているかをメモに残す、部署内に最低2人は中身が分かる人を置く。この積み重ねだけでも、アプリが使われなくなるリスクはかなり下げられます。社内での育て方はAI研修の目的と選び方をまとめた記事も参考にしてください。

まとめ

Power Appsからのメール送信は、Office 365 Outlookコネクタを追加し、ボタンのOnSelectでSendEmailV2を呼び出すのが基本形です。非推奨のSendEmailではなく、必ずV2を使ってください。

複数宛先は区切り文字でつないだ文字列として渡し、CCやBCC、返信先、重要度は第4引数のレコードで指定します。本文はHTMLとして扱われるため、改行はタグへの置き換えが必要になります。添付ファイルは、NameとContentBytesの列を持つテーブルで渡します。

運用で見落とされやすいのが送信元です。既定ではボタンを押した人の名前で送られるため、システム名義にしたい場合は権限の付与か、Power Automate経由の構成を検討します。アプリ共有時には利用者ごとの接続作成が必要になる点も、事前に周知しておいてください。

そして、動くものを作ることと同じくらい、使い続けられる体制を整えることが重要です。通知手段の選び方、テンプレートの外出し、命名規則、そして社内に分かる人を増やすこと。この4点を最初から設計に含めておけば、内製化は一過性の取り組みで終わりません。

▼ 社内アプリの内製化を、定着する形で進めませんか 株式会社ネクストスケールでは、業務の棚卸しからアプリ・自動化の設計、社内への定着支援までを一貫してご支援しています。何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら