Power Automateの二重登録を防ぐ：検索チェックと一意制約を組み合わせる

まず考えたい問い

同じTeams投稿からSharePointに2件の行ができた。トリガーの再実行だけを疑う前に、「同じ入力を繰り返し処理したら、何件残るべきか」を決めましょう。ここでは追加処理を冪等にする設計を扱います。

対象は、この領域を実装・運用する技術者と、仕組みを学びたい方です。

設計の要点

同じ業務キーに対して保存される行は最大1件。登録前の検索は無駄な書込みを減らし、保存先の一意制約は競合時の最後の防波堤になります。

!図解：元投稿のキー → 一意制約で作成 → 再取得して照合

*図は処理と検証の関係を示す模式図です。実測値や性能比較ではありません。*

仕組みと判断の分かれ目

検索してから作る、だけでは足りない

実行AとBが同時に検索すれば、どちらにも「0件」が返り得ます。検索と作成が別の操作であることが原因です。時刻や件名ではなく、投稿IDとコンテナーIDなどから再現可能な業務キーを作ります。SharePointの一意列は大文字小文字を区別しないため、元IDの比較規則を壊さないエンコードも設計事項です。

競合と通信障害を別に扱う

キー検証→既存検索→作成の順に進みます。作成が失敗・タイムアウトしたら同じキーで再取得し、業務内容も一致した場合にだけ既存処理済みと判定します。認証失敗や入力エラーを「重複」として握りつぶしてはいけません。空のキーで本番の行を作らないことも停止条件にします。

コード・データで表すと

次は設計を読み解くための例です。疑似コードや概念表記を含み、環境へそのまま貼り付けるための完成コードではありません。

# 概念を示す疑似コード
key = encode_identity(container_id, source_id)
require_valid(key)
if find(key): return verify_existing(key)
try: create_with_unique_key(key, payload)
except WriteUncertain:
    return reconcile_or_hold(key, payload)

ここまで試してから、動いたと判断する

正常系の確認だけでなく、失敗時に残るデータ、外部への副作用、再実行の可否も記録します。確認した対象・版・日時を残すと、後から同じ条件で追試できます。

小さな演習

テスト用リストに一意列を作り、同じキーを2本の実行で同時に作成してみてください。両方の実行履歴と、最終的な行数をセットで説明できますか？

試験結果を「観測した事実」「そこからの判断」「まだ確かめていない条件」に分けて書いてみてください。実装を説明する力は、動く理由と止まる理由を言葉にすることで磨かれます。

適用範囲と確認事項

設計例です。自社環境での適用前に、権限・製品仕様・既存データへの影響を検証してください。 本記事は2026年10月時点の対応・設計検討を一般化した解説です。内部環境の識別子や実データは掲載していません。

参考資料

• 公式・技術資料 1
• 公式・技術資料 2