更新操作でエラーが返ったのにFeaturedは反映済みだった――再実行前にReadbackした実例

結論――エラーが返った時点では、外部側の状態はまだ確定していない

外部サービスへの更新処理でエラーが返ると、「更新は失敗した」と考えて同じ操作をもう一度実行したくなります。

しかし今回のFeatured更新では、返答はエラーでも、Wix CMSの実データはすでに更新されていました。したがって、返答だけを見て次の変更操作へ進むと、不要な再実行や二重処理につながる可能性があります。

このKnowledgeでは、エラーの種類を一般化するのではなく、今回実際に起きた「エラー返却→Readback→更新済み確認」という一例から、再実行前の確認順序を整理します。

Featured更新の処理で「# could not be cloned.」が返った

KnowledgeトップのFeaturedをメンテナンスする処理では、複数のKnowledgeのFeaturedフラグと、Pillar側の代表記事情報を更新しました。

その処理結果として返ってきたのが、#<Promise> could not be cloned. というエラーです。

この文字列から分かるのは、処理のどこかで正常な結果を返せなかったことまでです。今回の記録だけでは、そのエラーがWix側の更新処理そのもの、レスポンス生成、ツール境界、その他のどこで発生したかまでは特定していません。

エラー直後にCreateやUpdateをやり直さず、現在値を読んだ

ここで同じ変更処理をすぐ再実行せず、Wix CMSからFeatured関連の現在値を再取得しました。

確認したのは、対象KnowledgeのFeaturedフラグと、Featuredに連動するPillar側の値です。

Readbackの結果、意図したFeatured構成はすでに反映されていました。つまり今回の事例では、ツールがエラーを返したことと、外部サービス側のMutationが失敗したことは一致していませんでした。

同じ処理を再度走らせると、変更対象は0件だった

状態確認後、同じFeatured更新ロジックを再度実行したところ、結果は changedKnowledge: []、changedPillars: [] でした。

これは、その時点ではKnowledge側にもPillar側にも追加変更が必要な差分が残っていなかったことを示します。

最初の処理がどの内部段階まで成功した後にエラーとなったのかは確定できません。しかし少なくとも、Readback時点で目的の更新は反映済みであり、再実行しても新しい変更は発生しませんでした。

「エラー＝失敗」と決めるより、「状態不明」として扱う

この事例から運用上使えるのは、エラーの意味を先回りして決めないことです。

更新処理の返答が正常なら、その返答を一つの確認材料にできます。一方、エラーやタイムアウトなどで処理結果が不明な場合は、まず外部サービス側の実状態を読む方へ切り替えます。

つまり、SUCCESS / FAILED の二択ですぐ判断するのではなく、UNKNOWN → READBACK → DONE / FAILED / NEXT と状態を分けます。

Create系の処理では、特に再実行を急がない

UpdateやPatchの再実行でも注意は必要ですが、新規Createでは同じ操作を繰り返すことで別IDのデータを増やす可能性があります。

AIにCMSへ書き込ませるとき、同じデータの重複作成をどう防ぐかでは、Create結果が不明な場合に既存データを検索し、作成済みならGetやUpdateへ切り替える方法を扱っています。

今回のFeatured更新はCreateではありませんが、「エラーを見てすぐ同じ変更操作を繰り返さない」という考え方は共通しています。

外部サービス操作では「返答」と「保存状態」を分けて見る

AIに外部サービスを操作させるとき「送信した・保存された・表示された」を分けて確認するでは、リクエスト送信、保存結果、Readback、公開表示を別の確認段階として扱っています。

今回の事例は、その中でも「操作結果の返答がエラーだったとき」に焦点を当てたものです。返答が正常でなくても、外部側の保存状態は別に確認できます。

そのため、重要なMutationの後は、エラー時だけでなく必要に応じてReadbackを完了条件へ含めます。

再実行前の基本フロー

1. 更新操作を実行する。
2. 正常な返答があれば対象ID・変更内容を保持する。
3. エラーやタイムアウトで結果が不明なら、同じMutationをすぐ再実行しない。
4. Get / Query / CMS Readbackで現在値を取得する。
5. 目的の変更が反映済みならDONEとする。
6. 反映されていなければ、エラー原因と操作の冪等性・重複リスクを確認してから次の処理を選ぶ。

この順序にすると、エラーそのものではなく、外部サービスに実際に保存されている状態を次の判断材料にできます。

一括更新が途中で止まったら、記事のIDごとに再開を判断する

複数の記事をまとめて直す場合は、「エラーが出たか」だけでなく、「どの記事に、どの変更が残っているか」を調べる必要があります。全件を最初からやり直すと、すでに追加した著者紹介を重ねて入れるおそれがあるためです。

可児波起が「海辺の部屋」のブログへ著者紹介と人物ページへのリンクを入れた過去の会話には、一括更新の途中でタイムアウトし、その後、公開228本と未公開1本を合わせた229本の固定IDで再照合した、というChatGPTの報告があります。直前の設計では、古い長文紹介のある記事は置換、署名だけの記事も置換、紹介のない記事だけ追加とし、未公開の1本は公開しない条件でした。

この報告から整理できるのは、再開時に次の対応表を用意する方法です。これは今回提案する確認手順であり、229本の復旧結果を新しく実測したものではありません。

1. 対象を固定する。処理前に記事IDと公開・未公開の状態を控えます。件数だけでなく、どの記事を処理する予定だったかを残します。
2. 記事ごとの完成形を決める。著者紹介を置換するのか追加するのか、完成後に何個あるべきか、リンク先と公開状態を記録します。
3. 止まったら同じIDを読み戻す。完了報告ではなく、本文内の紹介・リンク・公開状態を完成形と比べます。
4. 反映済み・未反映・確認できない記事を分ける。反映済みは変更せず、未反映だけ再開します。確認できない記事は成功にも失敗にも含めません。
5. 最後に元のID一覧と照合する。合計件数が合うだけでなく、対象の欠落、紹介の重複、未公開記事の意図しない公開がないかを確認します。

当時の会話本文には「全229本で未反映0本」とありますが、各IDの実データ、紹介の個数、処理前後の公開状態を示す記録までは今回取得していません。そのため、ここでは当時の復旧成功を独立に証明したとは扱いません。元のFeatured事例で確認した読み戻しと、この一括更新の報告は、確認できた範囲が異なります。

引き継ぎが必要な長い処理では、成果物だけでなく作業状態を渡す方法と組み合わせ、未反映のIDと次に行う操作を残せます。

確認できたことと、確認できていないこと

確認できたこと：Featured更新処理の結果として「#<Promise> could not be cloned.」が返ったこと。その直後のReadbackで意図したFeatured変更が反映済みだったこと。同じ更新ロジックを再実行した際に changedKnowledge: []、changedPillars: [] となったこと。

確認できていないこと：エラーが発生した正確な内部位置、同じエラーが常に更新後に起きるか、他のAPI・CMS・サービスでも同じ挙動になるか。

したがって本Knowledgeは、「APIエラーなら更新は成功している」と主張するものではありません。エラー時は更新成否を返答だけで決めず、再実行前に外部側の現在状態を確認するという運用を、この一事例から整理したものです。

このKnowledgeの関連知識

再実行前の状態確認で重複操作を防ぐ：AIにCMSへ書き込ませるとき、同じデータの重複作成をどう防ぐか。エラー時にReadbackして現在状態を確定する方法と、Create結果不明時に既存データを検索して重複作成を防ぐ方法を補完関係として接続する。

エラー時のReadbackを外部サービス確認全体へ広げる：AIに外部サービスを操作させるとき「送信した・保存された・表示された」を分けて確認する。Featured更新でエラー返却と保存状態が一致しなかった具体例から、送信・保存・Readback・表示を分ける一般的な確認設計へ広げる。