AIに外部サービスを操作させるとき「送信した・保存された・表示された」を分けて確認する

「送った」と「保存された」は同じではない

AIが外部サービスへデータを書き込むとき、最初に起きるのはリクエスト送信です。

たとえばタイトル、本文、SEO設定、画像、カテゴリーをまとめてAPIへ送信したとしても、その時点で確認できるのは「その内容を送った」という事実です。

保存結果として返ってきたレスポンスに、どの項目が含まれているかは別です。さらに、あとからGETで読み戻した値、Editorや公開ページで見える状態も別の確認段階です。

確認段階を4つに分ける

• REQUEST：何を送信したか
• RESPONSE：作成・更新結果として何が返ったか
• READ BACK：保存された値を後から読み戻したか
• VISIBLE：Editor、プレビュー、公開ページなどで実際の表示を確認したか

全部の作業で4段階すべてが必要という意味ではありません。重要なのは、どこまで確認したのかを混ぜないことです。

Mutationの成功は、編集上の完成とは別

APIのCreateやUpdateが成功してIDが返っても、記事の読み心地、画像の見え方、余白、最終URLまで確認できたとは限りません。

外部サービスを操作するAIでは、技術的な書き込み成功と、編集上の完成を同じ「完了」にまとめない方が安全です。

海辺の部屋では、データ作成、保存確認、公開確認、ブランド判断を別工程として扱うようにしています。

返却結果にない項目は、確認済みと扱わない

1回のMutationレスポンスには、送信した全項目が返らない場合があります。

その場合、「送った」ことは確認できますが、「返却で保存値を確認した」とは言えません。

重要な設定を確実に検証したいときは、対象IDを使って読み戻すか、必要なら画面で確認します。

Wix BlogでもCreate・Get・Publishは別操作

Wix Blogでは、新規下書き作成、下書き取得、公開はそれぞれ別のAPIです。

Create Draft Postは下書きを作り、Get Draft Postは指定IDの下書きを取得し、Publish Draft Postはその下書きを公開します。

この構造自体が、「作った」「保存内容を確認した」「公開した」が別の状態であることを分かりやすく示しています。

AIの完了報告には、確認レベルを含める

「完了しました」だけでは、何が終わったのか分かりません。

そこで、完了報告を「作成成功」「返却値確認」「読み戻し確認」「表示確認」「公開確認」のように分けます。

これなら、次の担当や別スレッドへ引き継ぐときも、どこから再開すればよいか分かります。

「確認できなかったこと」も残す

確認できなかった項目は失敗ではありません。

「本文は送信済みだが読み戻していない」「SEO設定は送信済みだが返却では未確認」「最終URLは未確認」のように残しておけば、次工程で必要な検証が明確になります。

AI運用では、曖昧な空白を「たぶんできている」で埋めるより、未確認のまま保存する方が安全です。

人間に戻すのは、操作ではなく最終判断

読み戻しやデータ監査はAI側でも実行できます。

人間に残したいのは、ブランドに合うか、公開してよいか、例外を許可するかといった判断です。

確認工程を細かく分けることは、人間の作業を増やすためではなく、AIが自分で検証できる範囲を広げるための設計でもあります。

このKnowledgeの関連知識

外部操作の具体例： 送信・保存・表示の確認状態を分ける考え方を、ChatGPTからWixを操作する実務へ適用する。

ChatGPTからWixサイトをどこまで直接運用できるか

現在地： AI WORKFLOW → 思考・実行・確認の分離

Knowledgeトップを見る