Microsoft FormsとSharePoint Listsの日付形式（M/D/Y・D/M/Y）をPower Automateで統一する方法

Microsoft Formsの回答日付が「8/13/2025」のようにM/D/Yで取得できる一方、SharePoint Listsは「13/8/2025」のD/M/Y表示になり、Power Automateで転記すると日付の入れ替わりや変換エラーが起きがちです。原因と、失敗しにくい統一方法を実務目線で整理します。

よくある症状：なぜ「8/13」が「13/8」になったり、エラーになったりするのか

Microsoft Formsの「日付」質問は、回答者がカレンダーから選ぶだけなので一見安心ですが、Power Automateで取得できる値が地域設定（ロケール）に依存した文字列になることがあります。たとえば、同じ2025年8月13日でも、環境によって次のように見え方・渡り方が変わります。

場面	例	起きやすいトラブル
Formsの回答（取得値）がM/D/Y	8/13/2025	SharePoint側でD/M/Yとして解釈され、8日13月のように解釈不能→エラー
Formsの回答（取得値）がD/M/Y	13/8/2025	Power AutomateやコネクタがM/D/Y前提で解釈し、月日が入れ替わる
月日がどちらも12以下	8/9/2025	8/9が8月9日なのか9月8日なのか判別できず、静かに誤登録することがある

特に厄介なのが「8/9/2025」のように月日が両方12以下のケースです。エラーにならず通ってしまうため、後から発覚しやすく、監査や集計の段階で痛手になります。

原因の全体像：Forms、SharePoint、Power Automateで“支配している設定”が違う

日付形式がバラつく根本原因は、同じMicrosoft 365内でも、日付の表示・文字列化に関わる設定が別々に存在する点です。まずは「どこで形式が決まっているのか」を分解すると整理しやすくなります。

要素	日付形式に影響する主な要因	現場で起きやすいこと	対策の方向性
Microsoft Forms	回答者のブラウザー／OS／Microsoft 365の地域設定に引っ張られることがある	同じフォームでも、回答者ごとにM/D/YとD/M/Yが混在	Forms側での固定は期待せず、下流で正規化
SharePoint（サイト／リスト）	サイトの地域設定（ロケール・タイムゾーン）	表示はD/M/Yでも、入力値が文字列だと解釈がズレる	サイト設定を統一し、表示の揺れを抑える
Power Automate	コネクタが期待するDateTime形式、式関数での変換	文字列がDateTimeとして解釈できずエラー、または誤解釈	ISO形式に変換して書き込む（最重要）

結論としては、「表示はSharePointの地域設定で揃え、保存値はPower Automateで安全な形式にして書き込む」のが、再現性が高くて運用コストが低い設計です。

最短で安定させる実務解：Power Automateで“書き込み前に正規化”する

「D/M/Yに統一したい」という要求は多いのですが、データ連携で本当に統一すべきは表示形式ではなく、解釈がブレない保存形式です。SharePointの「日付と時刻」列はDateTimeとして保持し、Power AutomateからはISO 8601系（yyyy-MM-dd または yyyy-MM-ddTHH:mm:ssZ）で渡すと事故が激減します。

まず押さえる：SharePointに“文字列のdd/MM/yyyy”を直接入れるのは危険

SharePointの列が「日付と時刻」型の場合、13/08/2025のような見た目用の文字列をそのまま入れると、環境によっては次のような問題が起こります。

日付として解釈できず、フローが失敗する
月日が入れ替わって保存される（8/9問題）
タイムゾーン変換が絡んで、日付が1日ずれる

そのため、SharePointのDateTime列に入れる値は、まず解釈が一意になる形式に正規化してから渡すのが鉄則です。

基本パターン：formatDateTime()で保存用（ISO）と表示用（D/M/Y）を分ける

Formsから取得した日付を、Power Automate内で2種類に整形します。

用途	推奨する保存先	形式	例
計算・フィルター・並び替えに使う“本体”	SharePointの「日付（DateTime）」列	yyyy-MM-dd（またはISO日時）	2025-08-13
人が見て迷わない“表示用”	SharePointの「テキスト」列（任意）	dd/MM/yyyy	13/08/2025

Power Automateの式（例）は次の通りです。実際には、Formsの該当フィールド名（DateFieldなど）に合わせて置き換えてください。

/* SharePointのDate列に渡す（保存用） */
formatDateTime(outputs('Get_response_details')?['body/DateField'], 'yyyy-MM-dd')

/* SharePointのテキスト列に保存する（表示用：D/M/Y） */
formatDateTime(outputs('Get_response_details')?['body/DateField'], 'dd/MM/yyyy')

ポイントは、SharePointのDateTime列に入れるのは“表示用のdd/MM/yyyy文字列”ではなく、保存用のISO寄り文字列にすることです。D/M/Yの見た目に寄せたい場合は、後述の地域設定で表示を揃えるか、テキスト列を併設して対応します。

フロー手順：Forms → SharePoint Lists で日付を安全に転記する設計

ここでは、もっとも再現性が高い「正規化→書き込み」を前提に、実装の流れを具体化します。

フローの全体手順

トリガー：Microsoft Forms – 新しい応答が送信されたとき
アクション：応答の詳細を取得
アクション：作成（Compose）で日付を正規化（保存用ISO／表示用D/M）
アクション：SharePoint – アイテムの作成でListsに書き込み

作成（Compose）で正規化する例

おすすめは、まず「そのままの値」を保持し、次に「保存用」「表示用」を分けて作ることです。原因調査が必要になったときに、どこでズレたか追えるようになります。

Compose名（例）	式	目的
Date_Raw	`outputs('Get_response_details')?['body/DateField']`	Formsから来た元値を記録する
Date_ISO	`formatDateTime(outputs('Get_response_details')?['body/DateField'], 'yyyy-MM-dd')`	SharePoint Date列に安全に入れる
Date_DMY_Text	`formatDateTime(outputs('Get_response_details')?['body/DateField'], 'dd/MM/yyyy')`	人間が見る用のD/M/Y表記

このように分けておけば、SharePoint側はDate列で集計・並び替えができ、画面上はテキスト列でD/M/Yを強制できます（必要な場合のみ）。

ハマりどころ：Formsから来る値が“ISOではない”場合の対処

環境によっては、Formsから渡る値が 8/13/2025 のようなスラッシュ区切り文字列になり、formatDateTime() がうまく解釈できないことがあります。その場合は、文字列を分解してISO形式を組み立てる方法が現実的です。

スラッシュ区切りをISOへ変換する（M/D/Y前提）

M/D/Yが確定している（例：米国環境のみに限定、または現状がM/D/Yで固定されている）なら、次のように月・日・年を並べ替えてISOを作れます。

/* dateStr = '8/13/2025' を想定 */
concat(
  split(dateStr,'/')[2], '-',
  padLeft(split(dateStr,'/')[0], 2, '0'), '-',
  padLeft(split(dateStr,'/')[1], 2, '0')
)

作ったISO文字列を、必要に応じてformatDateTime()で整え直してSharePointへ渡します。

混在している場合：自動判定は“完全ではない”と割り切る

M/D/YとD/M/Yが混在すると、8/9/2025のように判別不能なケースが必ず発生します。ここで重要なのは、「自動判定で100%直す」は難しいという前提を持つことです。実務的には次のいずれかに寄せるのが安全です。

上流で混在を起こさない：回答者の地域設定を揃える／同一地域の利用者に限定する
上流をテキスト入力にする：yyyy-mm-ddのようにISO形式で入力させる（後述）
曖昧な値は例外扱い：月日が両方12以下のときはエラーとして差し戻す／確認フローに回す

例外扱いの設計は一見面倒ですが、後工程でデータの信頼性を担保でき、監査・集計の手戻りが減ります。

表示の統一：SharePointサイトの地域設定でD/M/Y表示に寄せる

SharePoint Listsの「表示」をD/M/Yに寄せたい場合は、最終的にはSharePointサイトの地域設定を揃えるのが王道です。これにより、同じDateTime列でも画面表示が安定しやすくなります。

地域設定で揃えるべき項目

ロケール（地域）：例）日本、英国など（D/M/Y系の表示にしたい場合は、D/M/Yの文化圏に合わせる）
タイムゾーン：例）(UTC+09:00) Osaka, Sapporo, Tokyo
日付の表示形式：サイトによって選択肢が出る場合は、目的の形式に近いものを選ぶ

注意点として、地域設定の変更はサイト全体に影響します。既存の運用や他リストにも影響するため、変更前に「どの画面で表示が変わるか」「自動化フローが影響を受けないか」を確認してから適用するのが安全です。

Forms側でできる“混在対策”：固定は難しいが、事故率は下げられる

Microsoft Formsの「日付」質問は、回答者の環境に依存しやすく、フォーム作成者が完全に表記を固定できないケースが多いです。ただし、運用の工夫で混在の確率を下げることはできます。

フォームの説明文で期待する形式を明示する

日付質問の説明（サブテキスト）に、次のような例を入れておくと、回答者が意識しやすくなります。

例：日付はカレンダーから選択してください（例：13/08/2025）
例：海外拠点からの回答は「日付がずれないか」送信前に確認してください

どうしても統一が必要なら「日付」ではなく「テキスト」にする選択肢

絶対にD/M/Y（またはISO）で揃えたい場合、Formsの質問タイプを「日付」ではなく「テキスト」にして、入力形式を固定する方法があります。

質問タイプ	メリット	デメリット	向いているケース
日付	カレンダー入力で誤入力が少ない	地域設定で表記が揺れやすい	単一地域の利用者が中心、表示の揺れが許容できる
テキスト（ISO指定）	形式を厳格に統一できる（例：2025-08-13）	入力ミスが増える可能性、検証が必要	多地域・多言語で混在しやすい、データ品質を最優先したい

テキスト運用にする場合は、Power Automate側で「yyyy-mm-ddのパターンになっているか」をチェックし、合わない場合は差し戻す（または担当者へ通知する）設計にしておくと、データ品質が保てます。

日付が1日ずれる問題：タイムゾーンと“日付だけ”の扱いに注意

形式が合っていても、SharePointの列が「日付と時刻」になっていると、タイムゾーン変換の結果として日付が前後することがあります。たとえば、UTCで深夜の値を保存し、表示側でJSTに変換されると、表示日が変わることがあります。

ズレを避ける設計のコツ

本当に「日付だけ」なら、SharePoint側の列を日付のみにする
時刻も必要なら、Power AutomateでconvertTimeZone()を使って保存前に基準を統一する
運用ルールとして「入力は現地日付」「保存はUTC」「表示はサイトのタイムゾーン」など、基準を明文化する

日付の集計や締め処理が絡む業務（経費・勤怠・申請）では、1日ズレが致命傷になりがちです。形式の統一と合わせて、タイムゾーンの前提も合わせておくと安心です。

おすすめの列設計：迷ったら“Date列＋表示用テキスト列”の二段構え

「保存はDateTimeとして正しく」「表示はD/M/Yで統一したい」という要件が強い場合、SharePoint Listsの列を次のように設計すると、運用の柔軟性が上がります。

列名（例）	型	入れる値	使いどころ
RequestDate	日付（DateTime）	2025-08-13	フィルター、並び替え、集計、Power BI連携
RequestDateText	1行テキスト	13/08/2025	画面表示、メール本文、帳票の見た目
RequestDateRaw	1行テキスト（任意）	8/13/2025	障害調査、後追い検証（元値保存）

この二段構えの利点は、後から地域設定が変わっても、集計用のDate列は一貫して扱える点です。表示は状況に応じて、サイト設定・列書式・テキスト列のいずれでも調整できます。

トラブルシューティング：エラー・誤登録を最短で切り分ける

症状	原因の候補	まずやること	再発防止
フローが失敗し「日付が無効」系のエラー	SharePoint列がDateTimeなのに、dd/MM/yyyy文字列を渡している	Date列にはISO形式（yyyy-MM-dd）で渡す	表示用はテキスト列に分離、サイト地域設定で表示を統一
8/9が9/8として登録される	M/D/YとD/M/Yが混在し、曖昧な値が誤解釈	元値（Raw）を確認し、どの形式で来ているか把握	上流で混在させない／曖昧値は例外処理にする
日付が1日ズレる	タイムゾーン変換、DateTime列の扱い	列が「日付のみ」か確認、保存値に時刻が付いていないか確認	日付のみ運用にする／保存・表示のタイムゾーン基準を統一
同じフォームなのに人によって形式が違う	回答者のブラウザー／OS／Microsoft 365の地域設定の違い	回答者の環境差を前提に、Power Automateで正規化	利用者ガイドで環境を揃える、またはテキスト入力へ切替

運用チェックリスト：D/M/Yに“見せたい”ときに守るべき優先順位

最優先：保存値は曖昧さゼロにする（SharePoint Date列にはISO形式で渡す）
次点：表示はSharePointの地域設定で揃える（サイト全体の方針として統一）
要件が強ければ：表示用テキスト列を併設（画面や通知文で迷わせない）
混在が止まらないなら：上流設計を見直す（テキスト入力＋検証、または利用者環境を統制）

まとめ：D/M/Yに統一する最短ルートは「表示」と「保存」を分けること

Microsoft FormsとSharePoint Listsの間で日付形式が食い違う問題は、「どちらか一方の設定を直せば終わり」になりにくいのが特徴です。現場で安定させるには、

Power Automateで書き込み前に日付を正規化し、SharePointのDate列にはISO形式で渡す
D/M/Yの見た目は、SharePointの地域設定で揃える（必要ならテキスト列も併用）
混在や曖昧日付が発生する場合は、例外処理や上流の入力設計でデータ品質を守る

この方針で設計すると、日付の誤登録や変換エラーが大幅に減り、Listsの集計や後工程の分析もスムーズになります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。