【Power Automate】添付ファイル名の文字化けが想定どおり進まない時の入力条件と処理順の見直し

Power Automateでメールの添付ファイルを自動保存するフローを組んだ際、ファイル名が「=?ISO-2022-JP?B?…」のような文字化けを起こして想定どおりに動かないケースは少なくありません。この問題は、メールヘッダーに使われるエンコーディングの扱いや、フロー内のアクション実行順に起因することがほとんどです。本記事では、添付ファイル名の文字化けが改善しない原因を具体的に切り分け、処理順を見直すための実務的な手順を解説します。

1. 文字化けの原因を特定する前に確認すべき基本条件

添付ファイル名の文字化けを解決するためには、まずPower Automateがメールから受け取るデータの構造を理解することが重要です。メールの添付ファイル名はMIMEヘッダー内でエンコードされており、Power Automateの「メールを取得(V2)」アクションはデフォルトである程度デコードしますが、完全ではありません。

1-1. メールヘッダーのエンコーディング形式

日本語メールでは、ヘッダー(SubjectやContent-Dispositionのfilename)がMIMEエンコード(Base64またはQuoted-Printable)されていることが一般的です。Power Automateの「メールを取得」アクションの出力で、添付ファイル名が「=?UTF-8?B?…?=」のように表示される場合、デコードが中途半端な状態です。この状態ではファイル名をそのまま保存すると文字化け名前で保存されます。

1-2. Power Automateのアクション設定の確認

「メールを取得」アクションの詳細設定に[MIMEヘッダーをデコード]のようなオプションはありませんが、代わりに添付ファイル名を取得する際に「添付ファイル名」フィールドのデータ型に注意する必要があります。多くの場合、この値はstring型として渡されますが、内部でデコードしきれないエンコード文字列がそのまま残ることがあります。また、ファイル名を扱う次のアクション(例えば「ファイルを作成」)でエンコーディング指定が可能かどうかも確認してください。

2. 想定どおり進まないケースの具体的原因

文字化けが発生する原因として、以下の3つが実務で頻出します。それぞれに適した対処法が異なります。

2-1. デコード不足:Base64エンコードのまま保存されている

最も多いパターンです。Power Automateが提供する添付ファイル名は、メールから取得した生のMIME文字列を軽く整形しただけで、完全にデコードされていません。例えばファイル名が「=?utf-8?B?44GT44KT44Gr44Gh44Gv?=.pdf」のような形式のままです。この場合、Power Automateの式で「decodeBase64」や「uriComponentToString」を使って変換する必要があります。ただし、単純なBase64デコードでは「=?…?=」という装飾部分が残るため、正規表現で除去する必要もあります。

2-2. エンコーディングの不一致(ISO-2022-JPとUTF-8)

社内メールサーバーがISO-2022-JP(JIS)を強制的に使用している場合、Power Automateのデフォルト動作(UTF-8前提)では正しく変換されません。「添付ファイル名」の値に「=?ISO-2022-JP?B?…?=」と表示された場合、一度Shift_JISやUTF-8に明示的に変換しないと文字化けします。Power Automateの式の中で「decodeBase64」だけでは不十分で、テキストエンコーディングを指定できるアクション(例:Azure Functionsでの変換、あるいは「テキストの変換」アクション)が必要になります。

2-3. 処理順の問題:デコード前にファイル保存を行っている

フロー内で、メールから取得した添付ファイル名をそのままファイル保存アクションの「名前」フィールドに入力している場合、文字化けが発生します。保存前にデコード・変換処理を実行していないことが原因です。また、ループ内で複数の添付ファイルを処理する場合、最初のファイルのみ正しくデコードされ後続が文字化けする、というケースもあります。これは変数のスコープや初期化のタイミングの問題です。

3. 処理順を見直すためのフロー設計のポイント

添付ファイル名を扱うフローでは、以下の順序で処理を組み立てると文字化けが起きにくくなります。

3-1. 推奨するアクションの順序

1. メールを取得(V2)でメールと添付ファイルを取得
2. [Apply to each]で添付ファイルをループさせる
3. ループ内で添付ファイル名を取得し、変数(String)に格納
4. その変数に対してMIMEデコードの式を適用(後述)
5. デコード後のファイル名をファイル作成アクションの「名前」に設定
6. ファイルのバイナリコンテンツは「添付ファイルコンテンツ」をそのまま渡す

3-2. ループ内でエンコーディングを固定する

ループ内で各添付ファイル名を処理する際、エンコーディングをUTF-8に統一します。Power Automateの式のみで完結させる場合、以下のようなパターンが考えられます。

まず、添付ファイル名から「=?…?=」部分を正規表現で抽出し、Base64部分をデコードした後、さらにバイト配列をUTF-8として解釈します。具体的には、次のような式を変数の更新アクションに使用します。

if(contains(outputs('メールを取得')?['body/attachments']?[0]?['name'], '=?'),
  decodeUriComponent(replace(replace(outputs('メールを取得')?['body/attachments']?[0]?['name'], '=?UTF-8?B?', ''), '?=', '')),
  outputs('メールを取得')?['body/attachments']?[0]?['name']
)

しかし、この式はUTF-8専用です。ISO-2022-JPなど他のエンコーディングに対応するには、より複雑な処理が必要になるため、Cloud Flowでは限界がある場合があります。その際は、後述する管理者確認と併せて、Azure Automation RunbookやHTTP要求を利用した外部サービスに変換を任せる方法も検討します。

4. 実践的な修正手順(Outlookメール→OneDrive保存フローの例)

ここでは、定型のOutlookメールから添付ファイルをOneDriveに保存するフローを例に、具体的な修正手順を3つのステップで説明します。

4-1. メールを取得アクションの設定

トリガーは「新しいメールが届いたとき」など適切なものを選択し、取得するメールのフォルダーと件名フィルターを設定します。特に[添付ファイルを含める]を「はい」にするのを忘れないでください。

4-2. 添付ファイル名をデコードする変数の追加

[Apply to each]の前に、[変数を初期化する]アクションを追加し、名前を「EncodedName」、種類を「String」、初期値を空文字に設定します。ループ内では、現在の添付ファイル名をこの変数に代入し、次のデコード式で更新します。

デコード式(一例):

if(contains(items('Apply_to_each')?['name'], '=?'),
  replace(
    replace(
      items('Apply_to_each')?['name'],
      '=?UTF-8?B?', ''
    ),
    '?=', ''
  ),
  items('Apply_to_each')?['name']
)

ただし、実際にはこのreplaceだけではエンコード文字列の削除しか行っていません。Base64をデコードするには、さらに式を追加する必要があります。完全なデコードは次のステップで行います。

4-3. ファイル作成アクションでのファイル名設定

OneDriveの「ファイルを作成」アクションで、ファイル名フィールドに先ほど更新した変数「EncodedName」を設定します。ただし、この段階ではまだ文字化けしている可能性があるため、必要に応じてURIエンコード/デコード関数(uriComponentToString)を組み合わせると安定します。

以下に、実際の展開例を示す比較表を用意しました。

処理内容	アクション例	結果
生の添付ファイル名をそのまま保存	[ファイルを作成] 名前 = items(‘Apply_to_each’)?[‘name’]	「=?utf-8?B?44GT44KT44Gr44Gh44Gv?=.pdf」のようなファイル名で保存
Base64デコードのみ実行	名前 = decodeBase64( items(‘Apply_to_each’)?[‘name’] )	デコードに失敗、または文字化けした日本語
replaceとuriComponentToStringを併用	名前 = uriComponentToString( replace( items(‘Apply_to_each’)?[‘name’],’=?UTF-8?B?’,” ) )	正しい日本語ファイル名になる(UTF-8の場合のみ)
エンコーディングをUTF-8で明示	名前 = concat(‘UTF-8_’, uriComponentToString( … ))	UTF-8に固定されるが、サーバーがISO-2022-JPの場合は依然文字化け

5. 失敗パターンと管理者に確認すべき事項

自力で修正しても解決しない場合、組織のメール環境やPower Platformの制限に原因がある可能性があります。以下の2点を管理者に伝えて確認してください。

5-1. メールサーバー側の文字コード設定

メールサーバーが送信するメールのヘッダーエンコーディングとして「iso-2022-jp」を強制している場合、Power Automateの標準関数では正しくデコードできません。これはメールクライアント(Outlookなど)では自動変換されるため気づきにくいですが、Power Automateのような自動処理では差異が顕著になります。管理者にメールサーバーの設定(Exchange Onlineの場合はコネクタ設定、オンプレミスの場合は送信コネクタ)を確認してもらい、可能であればUTF-8での送信を許可するよう調整が必要です。

5-2. Power Platformのデータ型制限

Power Automateの式の中で、エンコーディング変換を自由に行えるアクションは限られています。例えば「テキストの変換」アクション(プレミアム)があれば、ソースエンコーディングを指定して変換できますが、標準コネクタでは使用できません。もし組織でプレミアムライセンスを保持している場合は、その利用を検討します。また、Azure Automation Runbookやカスタムコネクタを利用した高度な変換は、IT部門の協力が必要です。

6. よくある質問(FAQ)

以下に、実務でよく寄せられる質問とその答えをまとめます。

Q1: 添付ファイル名が「アウトライン」のように一部だけ文字化けします。なぜですか?
A1: ファイル名に半角と全角が混在している場合、エンコードの境界で問題が発生することがあります。式の正規表現パターンが不完全な可能性があるので、テキストの先頭と末尾のみの置換ではなく、全体的なuriComponentToStringを試してください。

Q2: フローを手動実行すると正常に動くのに、自動実行では文字化けします。
A2: トリガーの種類によってメールの取得方法が異なる場合があります。例えば「新しいメールが届いたとき」トリガーと「メールを取得」アクションでは、添付ファイルのエンコーディング処理が若干異なることがあります。トリガーを「定期的なスケジュール」+「メールを取得」に変更してみてください。

Q3: 管理者に「メールサーバーはUTF-8対応です」と言われましたが、依然として文字化けします。他に何を確認すればいいですか?
A3: その場合、フロー内で使用しているアクションのデータ型を確認してください。添付ファイル名を一度binary型に変換してからstringに戻すと、内部エンコーディングが変化することがあります。また、Power Automateのバージョンや地域設定も影響する可能性があります。

7. まとめ

Power Automateにおける添付ファイル名の文字化けは、メールヘッダーのエンコーディングとフロー内の処理順に起因します。最初にメール取得アクションの出力を確認し、MIMEエンコードが残っている場合は明示的なデコード処理を追加してください。また、エンコーディングがISO-2022-JPの場合、Power Automateの標準関数だけでは変換が困難なため、管理者と連携してサーバー設定の変更またはプレミアムアクションの導入を検討する必要があります。