Power Automate「先書き→上書き」パターン解説記事

Power Automateで自動化フローを組んでいると、必ずぶつかる壁があります。

外部APIが失敗した時、どう状態を残すか問題。

普通に組むと、処理が落ちた瞬間にすべて忘れてしまいます。

「どの記事まで処理した?」「どこで失敗した?」「次に何から再開すればいい?」

全部、分からなくなる。

知らんて。

この問題を解決するのが「先書き→上書き」パターンです。

社内SEの設計あるあるみたいな仕組みですが、Power Automateとめちゃくちゃ相性がいい。

この記事では、私が22記事のWordPressリライト処理で実際に使った設計を、社内SE視点でまとめます。

「先書き→上書き」パターンとは何か

1文で説明します。

「失敗状態を先に記録しておいて、成功した時だけ上書きする」設計です。

処理の流れは、こうなります。

• 処理対象を1件取得する
• ステータスを先に「失敗」に書き込む
• 本処理を実行する
• 成功した時だけ、ステータスを「成功」に上書き
• 失敗した時は、ステータスが「失敗」のまま残る

シンプルですが、これが超強い。

普通の設計だと「成功時に成功と書き込む」のが当たり前です。

でも、その「当たり前」が原因で、失敗時に状態が残らない問題が発生します。

逆転の発想です。

なぜこのパターンが必要になったか

背景の話をします。

私は、WordPressブログの記事リライトを自動化していました。

仕組みは単純です。

• SharePointリストから「待機中」の記事を取得
• WordPress REST APIで元記事を取得
• Claude APIでリライト
• WordPress REST APIで下書きとして保存
• SharePointリストのステータスを「完了」に更新

このフローを毎日朝3時に自動実行する設計です。

動き始めて数日、私は朝起きてSharePointを見るのが恐怖になりました。

処理が失敗していた場合、待機中のまま記事が残るのです。

「あれ?昨日の処理、走った?走ってない?」

Power Automateの実行履歴を1つずつ開いて、エラー内容を確認する作業。

毎朝これが続くと、もう体力が持ちません。

普通に脳が死ぬ。

普通の設計が持つ「失敗時に何も残らない」問題

従来の設計を、もう一度見直してみます。

普通のフロー設計だと、こうなっています。

[トリガー]
↓
[SharePoint:待機中を取得]
↓
[WordPress GET:元記事取得]
↓
[Claude API:リライト]
↓
[WordPress POST:下書き保存]
↓
[SharePoint:ステータスを「完了」に更新]

処理が全部成功すれば、ステータスが「完了」になります。

でも、途中で失敗すると、ステータスは「待機中」のまま。

Claude APIで失敗しても、WordPress POSTで失敗しても、SharePointに変化なし。

朝起きて確認しないと、何も分かりません。

失敗の証拠が、どこにも残らないんです。

もちろん、Power Automateの「並列分岐」や「エラー処理」を使えば、失敗時の処理を組み込めます。

でも、エラー処理を入れるとフローがどんどん複雑になります。

失敗パターンの数だけ、分岐を書く必要がある。

普通にめんどくさい。

「先書き→上書き」パターンの実装

この問題を解決するのが、「先書き→上書き」パターンです。

フローはこう変わります。

[トリガー]
↓
[SharePoint:待機中を取得]
↓
[SharePoint:ステータスを「失敗」に先書き] ←★追加
↓
[WordPress GET:元記事取得]
↓
[Claude API:リライト]
↓
[WordPress POST:下書き保存]
↓
[SharePoint:ステータスを「成功」に上書き]

変更点はたった1つ。

最初に「失敗」と書き込むステップを追加するだけです。

この1ステップが、フロー全体の挙動を劇的に変えます。

何が変わるのか

このパターンを採用すると、フロー実行後に3つの状態のいずれかが SharePoint に残ります。

• 「成功」:本処理まで全部通った
• 「失敗」:途中で落ちた
• 「待機中」:まだ処理が始まっていない

「失敗」と「待機中」が、明確に区別されます。

朝、SharePointを開けば、状況が一発で分かる。

「待機中:8件」「失敗:2件」「成功:9件」みたいに、フィルタで瞬時に把握できます。

Power Automateの実行履歴を1つずつ開く必要がない。

「失敗」が残っている記事を見れば、どこで詰まったか即座に分かります。

後はそれを「待機中」に戻して、原因を調査して、再実行するだけ。

業務フロー的に、めちゃくちゃ楽になりました。

SharePointの選択肢設定

このパターンを実装するためには、SharePointのRewriteStatus列に、選択肢を追加しておく必要があります。

私が使っている選択肢は、こんな感じ。

• 待機中
• 処理中
• WAFテスト失敗
• WAFテスト済み
• リライト失敗
• リライト完了
• 要確認

WAFテストと本番リライトを分けて、それぞれに「失敗」と「成功」を用意しています。

Power Automateでの実装手順

具体的なフロー構成を書いておきます。

ステップ1:複数の項目の取得

SharePointの「複数の項目の取得」アクションで、待機中の記事を1件取得します。

• フィルタークエリ:RewriteStatus eq '待機中'
• 上から順に取得:1

ステップ2:項目の更新(先書き)

SharePointの「項目の更新」アクションを追加します。

• ID:ステップ1で取得した記事のID
• RewriteStatus:「WAFテスト失敗」

ここで、まだ何も処理していないのに「失敗」を書き込みます。

これがミソです。

ステップ3〜5:本処理

WordPress GET、Claude API、WordPress POST など、本来の処理を実行します。

ここで失敗すると、ステータスは「WAFテスト失敗」のまま残ります。

ステップ6:項目の更新(上書き)

もう一度、SharePointの「項目の更新」アクション。

• ID:同じ記事のID
• RewriteStatus:「WAFテスト済み」

本処理が全部成功した場合のみ、ここまで到達します。

ステータスが「WAFテスト失敗」から「WAFテスト済み」に上書きされる。

エラー処理が不要になる魔法

このパターンの一番の利点は、「エラー処理を書かなくていい」ことです。

通常のフローだと、失敗時の処理を書く必要があります。

• HTTP 1で失敗したら → エラーをログに残す
• HTTP 2で失敗したら → エラーをログに残す
• Claude API失敗 → リトライする

失敗パターンの数だけ、分岐とエラー処理ステップを書く。

でも、「先書き→上書き」パターンは違います。

失敗時は「何もしない」。

フローが落ちると、最後の「項目の更新(上書き)」が実行されない。

結果、ステータスは「失敗」のまま残る。

勝手にエラー記録が完成します。

これは、フロー設計が劇的にシンプルになる魔法です。

プログラミング設計から見た位置づけ

この「先書き→上書き」パターン、実は分散システム設計でよく使われる発想と同じです。

近いのは、こんな概念。

楽観的更新と悲観的更新

「楽観的(Optimistic)」と「悲観的(Pessimistic)」は、システム設計で対比される考え方です。

楽観的:「たぶん成功するだろう、失敗したら戻せばいい」

悲観的:「失敗する前提で、最初からロックしておく」

今回の「先書き→上書き」パターンは、悲観的設計の一種です。

「失敗する前提でステータスを先に書き込んでおく」考え方。

悲観論者の発想ですが、これが安心につながります。

冪等性の確保

冪等性(べきとうせい、idempotency)は、「何回実行しても同じ結果になる」性質。

このパターンは、ある意味で冪等性も担保します。

同じ記事を2回処理しても、最終状態は変わりません。

失敗中なら「失敗」のまま、成功なら「成功」のまま。

これも、自動化フローの安心感に直結します。

実測:22記事で81%のWAF通過率

このパターンを使って、22記事のWAFテストを実行した結果です。

22記事の処理結果(2026/05/16時点)
- WAFテスト済み(成功):9件 (41%)
- WAFテスト失敗:2件 (9%)
- 待機中(未処理):8件 (36%)
- 要確認(既存リライト試行):3件 (14%)

WAF通過成功率:9/(9+2) = 81%

「WAFテスト失敗」が2件残ったので、その記事だけ重点的にWAFログを確認します。

失敗状態が SharePoint に明確に残っているから、原因調査の入口がすぐ分かる。

SharePointの画面で「WAFテスト失敗」でフィルタかけるだけ。

これだけのことで、運用負荷が激減しました。

4時間ずらしスケジュールとの組み合わせ

もう1つ、このパターンの強みがあります。

「自動スケジュール実行」と相性が抜群にいい。

私のフローは、Power Automateの繰り返しトリガーで、4時間ごとに1記事ずつ処理するように設定しています。

• 0時:1記事処理
• 4時:1記事処理
• 8時:1記事処理
• 12時:1記事処理
• 16時:1記事処理
• 20時:1記事処理

1日6記事、22記事完走に約4日。

WAFのレート制限を避けるため、連続実行は避けました。

4時間あれば、WAFの警戒モードも落ち着きます。

そして、「先書き→上書き」パターンのおかげで、私が寝ている間に処理が進んで、朝起きたらSharePointに結果が並んでいる状態。

「成功」と「失敗」が明確に区別されている。

これは、社内SE的に最高の運用です。

他の処理にも応用できる

この「先書き→上書き」パターンは、ブログ自動化以外にも応用できます。

例えば、こういうケース。

• 営業データの自動取込:ステータスを「取込失敗」に先書き → 取込成功時に「取込完了」に上書き
• 請求書PDFの自動処理:ステータスを「処理失敗」に先書き → 処理成功時に「処理完了」に上書き
• 外部APIとの連携処理:ステータスを「API失敗」に先書き → 取得成功時に「API成功」に上書き

外部依存があって、失敗の可能性がある処理なら、ほぼ全部このパターンが使えます。

社内SEとして、何かしらの自動化フローを組む時、これは抑えておいて損のないパターンです。

注意点

このパターンを使う時の注意点をいくつか。

SharePointの更新コスト

項目の更新が2回発生するので、SharePointの操作量は単純に2倍になります。

大規模なリストや、Power Automateの呼び出し回数上限がある場合は、注意が必要。

個人ブログ規模なら、ほぼ気にしなくていいレベルです。

「処理中」中断のリスク

「先書き」と「本処理開始」の間で何か起きると、状態がおかしくなる可能性があります。

ただ、Power Automateの場合、ステップ間の処理は基本的に即時実行されるので、この間で止まる可能性は低いです。

選択肢の整理

「失敗」状態が複数のフローで使われる場合は、フロー名や処理種別を含めた選択肢にしておくと、後で見たときに分かりやすいです。

例えば「WAFテスト失敗」と「リライト失敗」のように、フローごとに区別する。

これは私が実際にやっている分け方です。

まとめ:シンプルな発想転換が運用を救う

「先書き→上書き」パターン、技術的には超シンプルです。

項目の更新を1ステップ追加するだけ。

でも、この1ステップで運用が劇的に楽になります。

• 失敗の証拠が確実に残る
• エラー処理のコードが不要
• 自動スケジュール実行と相性抜群
• 朝起きた時に状況が一発で分かる
• 失敗時の調査が圧倒的に楽

「成功したら成功を書く」のではなく、「先に失敗を書いて、成功時に上書きする」。

たったこれだけの発想転換。

でも、Power Automateで自動化フローを組む人は、絶対に覚えておいた方がいい。

__

このパターンを使うと、外部APIと連携する自動化が、めちゃくちゃ安定します。

私のWordPressブログのリライト自動化システムも、これで運用が安定しました。

その全体像は、別記事で書いています。

ConoHa WAFの誤検知問題と、それをこのパターンでどう乗り越えたかも書きました。

失敗を恐れない設計、というよりも、失敗を最初から受け入れる設計。

悲観論者の社内SE、向いてるかもしれません。

知らんて。