Power Automate×WordPressの自動投稿フローを2回の継続発注で改修した情シス代行事例｜既存ワークフローを活かす保守改修

制作内容

「Power Automateで組んだフローが、ある日意図通りに動かなくなった」現場の話

Microsoft Power AutomateとWordPressを組み合わせた自動投稿フローは、ノーコードで構築されているケースが多く、作った担当者が異動・退職した瞬間に保守できる人が社内からいなくなる という問題を抱えがちです。

今回ご紹介するのは、Webメディア運営のクライアントから、Power AutomateとWordPressをつなぐ自動投稿フローの改修を、2回にわたって継続発注いただいた事例 です。BENTEN Web Worksは、別ツールへのリプレースを提案するのではなく、「既存ワークフローを活かして、必要な動作だけ確実に直す」 という方針で対応しました。

クライアント概要

業種: Webメディア／コンテンツ運営
規模感: 中小規模
構成: Power Automate（クラウドフロー）→ WordPress REST API への自動投稿

ノーコードで組まれた既存フローを、現場の運用に合わせて少しずつ改修していくフェーズ にあるクライアントでした。

課題・依頼背景（Before）

動いていたフローの一部が、想定通り動かない: ノーコードの設定変更やAPI仕様変更が積み重なった結果、所々で挙動がずれていた
詳しい人がすぐ確保できない: ノーコードであっても、Power Automate × WordPress REST APIの組み合わせを把握している人材は社内に常駐していない
業務が回っているうちは止められない: 自動投稿が止まると、メディア運営側の手作業が増える
追加要望もある: 障害対応だけでなく、運用に合わせた小さな機能追加も並行して必要

「動いてはいるが、ところどころ気持ちよく動かない」という、保守に近い改修案件の典型でした。

提案・解決アプローチ（思考プロセスを見せる）

「いっそコード基盤に乗せ替えたほうが、長期的に楽になる」という選択肢は最初から検討対象でした。けれど、現場の運用がPower Automate前提で回っている以上、リプレースは事業のリズムを壊す という結論に至りました。

案A: GASやNode.jsへ全面リプレース

メリットは、コードベースで一元管理できること。デメリットは、現場の運用変更とセットになり、改修期間中の業務影響が読めない こと。今回は障害対応の温度感も含むため、リプレースを並走させると本筋が止まります。

案B: 既存のPower Automateフロー上で改修（採用）

採用したのは、いま動いているフローの構造を尊重し、ピンポイントで動作を直す アプローチです。

第1回: 想定通り動かないステップの原因特定と修正
第2回: 第1回の対応結果を踏まえた追加改修と運用調整

「いきなり大きく変えない」「運用の連続性を最優先する」を、案件全体の方針として明確化しました。

あえて採用しなかった選択肢

別RPAツールへの移行: 学習コストと既存資産の捨てコストの両方を抱えるため見送り
コード基盤への全面リプレース: メリットはあるが、いまのタイミングで運用を止める正当性がない
「ついでだから」全部直す式の提案: 障害対応と機能追加が混ざる時こそ、範囲を握って小さく直す

「やらないことを先に握る」のは、保守案件で一貫している判断軸です。

実装内容

Power Automate→WordPress REST API→公開記事の自動投稿フロー — 継続案件として、変更箇所を最小化しながら動き続ける改修

対応領域

既存Power Automateフローの読解: クラウドフロー側のステップを一通り確認し、想定挙動と実挙動の差を整理
動作不具合の原因特定: API仕様・認証・条件分岐のいずれに起因するかを切り分け
必要なステップだけ改修: 触る範囲を最小化し、影響面を抑える
運用側との調整: 「次に同じ事象が起きたら、どこを見ればいいか」を伝達

工夫した点

「触った範囲」「触らなかった範囲」を必ず明示: 改修後の挙動を運用側が把握しやすくする
テスト投稿を運用側のリズムで実施: 業務時間と本番投稿に影響しない時間帯で確認
追加改修の余地を残す設計: 第1回で「次にやるべき範囲」が見えたら、第2回で素直に着手

派手な技術ではなく、「動いている運用を壊さない」 ことだけを徹底しました。

成果

対象フローの不具合解消: 想定通りに動く状態に復旧
2回にわたる継続発注: 第1回の対応を踏まえて第2回を発注いただいた
運用側の安心感: 「同じ事象が起きてもまた相談できる」状態の構築

クライアントの声（趣旨は保ち、表現は脚色）：

必要な範囲を見極めたうえで、丁寧にご対応いただきました。最後まで安心してお取引でき、また次の改修もお願いしたいと感じています。

短いやり取りでも、「次もお願いしたい」と言っていただけたことが、この案件の最大の指標 です。地の文としても、スピードそのものではなく、確実性を重視した進行で安心感を積み上げる方針で臨みました。

私の働き様

β：検討プロセス（一人称で振り返り）

エピソード1：リプレースを提案しなかった理由（→ ビジネスに寄り添う／ちゃんと動く）

技術者としては、Power AutomateからGASやNode.jsへ移行を提案したくなる場面でした。けれど、現場の運用はPower Automate前提で回っており、いま乗り換えるメリットは「将来楽になるかもしれない」しかない。「将来の楽」のために「いまの業務」を止める提案はしない、という線をここで引きました。

エピソード2：触る範囲を最小化した理由（→ ちょうどいい／思考プロセス）

「いっそ全部見直しましょう」と言うのは簡単ですが、触った範囲だけ責任を持てる のが保守の現実です。範囲を広げるほど、副作用の可能性も広がります。「直すべき箇所だけを、確実に直す」 に徹しました。第2回の発注をいただいたのは、この範囲設定が信頼につながった結果だと考えています。

エピソード3：第1回で全部やり切らなかった理由（→ 思考プロセス／ビジネスに寄り添う）

第1回の調査で「次に直すべき範囲」も見えていましたが、その場で全部やろうとせず、いったん運用に戻して様子を見る選択 をしました。1回で完璧を目指すと、運用側のキャッチアップが追いつかない ことを、過去の保守案件で何度か経験しています。段階を分けるのは、運用側のためでもあり、自分のためでもあります。

α：コミュニケーション抜粋（自分の発言だけ）

クライアントとのやり取りから、価値観の軸が出ている自分の発言だけを抜粋します。

「まずは現状のフロー構造を尊重し、想定通り動いていない箇所だけを直す方針 で進めます。別ツールへの移行提案は、今回はあえてしません。」

「触ったステップと、触らなかったステップを後ほど整理して共有します。運用側が次にどこを見ればよいかが分かる状態 にして納品します。」

「次に直しておくと運用が楽になりそうな箇所も見えていますが、いったん今回の改修で運用に戻し、必要であれば次回以降に着手する 段階分けでお願いできればと思います。」

これらの判断軸は、ノーコード／RPAの保守案件で共通して持ち込んでいます。派手なリプレースより、ちゃんと動いて、ビジネスに寄り添えて、ちょうどいい。

学び・横展開

このPower Automate × WordPress 改修案件から整理できた、BENTEN Web Worksとして他案件にも応用している判断軸は3つです。

既存ツールの選定を尊重する: 「あとから来た人」がツール選定をひっくり返さない
触る範囲を最小化する: 副作用は範囲に比例する。直す箇所だけ、確実に直す
段階的に発注いただく前提で見積もる: 一気に全部より、必要に応じて続けて相談できる関係を作る

ノーコード／RPA／GAS／クラウドフロー連携で組まれた業務自動化の保守は、「作った人がいなくなった瞬間に止まる」リスクを常に抱えています。リプレースを急がず、まずは既存の上で動作を整える進め方が現実的です。

Others

その他の制作実績