Chatで考え、Workは確定操作だけにする――30商品から300商品へ変わった役割分担

最初は、Workの中で「考える」と「操作する」を両方やっていた

商品説明HTMLの改修では、当初はブラウザを操作するWork側へ多くの工程を持たせていました。

調査、公式情報の確認、商品理解、文章制作、HTML制作、対象商品の選別を行い、その後にitem Robotで商品を検索し、入力・保存まで進める設計です。

一つのAIが最初から最後まで担当するため、見た目には分かりやすい構成です。

一方、海辺の部屋の実運用では、Workの使用量が大きく、本人申告では「Work 100％で30商品」という状態になりました。

そこで、Chatを「考える場所」、Workを「動かす場所」に分けた

設計変更後は、役割を二層に分けました。

• Chat：調査、公式確認、商品理解、文章制作、HTML制作、対象商品の選別
• Work：商品番号検索、商品を開く、完成済みHTMLを貼る、Yahoo側へコピーする、保存・更新

つまり、Workがブラウザを開いた時点では「何を書くか」「どの商品を触るか」をできるだけ決め終えた状態にします。

ここでいう「Workに考えさせない」は、推論機能を止めるという意味ではありません。ブラウザ操作の途中で新しい判断を必要とする工程を減らし、確定済みの入力へ寄せるという運用上の表現です。

分業した理由は、Workの利用量を必要な操作へ配分するためだった

どの工程をChatへ移すかを考えるには、分業の目的も残しておく必要があります。可児波起は、この運用を紹介するブログの原稿に対し、「なぜ、僕がworkだけで、完了させなかったのかが弱い」と訂正しました。Workを使い続けるとクレジットが速く減り、追加購入で大量処理を続けると高くつくと感じたため、Chatでできる工程を切り出し、最後の実作業だけWorkへ残した、と本人は説明しています。

ここで確認したのは、本人が説明した設計変更の理由です。単に画面操作を速くするためでも、Workが調査や文章作成をできないためでもありません。限られた利用枠をどの工程へ使うか、という判断でした。各工程の実消費や同条件での費用差を今回測定したわけではありません。

自分の仕事へ応用するなら、工程ごとに「必要な成果物」「画面操作が必要か」「判断が確定しているか」「消費した利用量」を分けて記録します。分業できたことと費用がどれだけ減ったかは別に確認します。サービスの料金体系は変わり得るため、本人の当時の選択を、すべてのChat操作が無料という一般的な保証にはしません。

Workへ渡すものを「READY INPUT」にする

ブラウザAIへ渡す直前の成果物は、まだ考える必要がある下書きではなく、そのまま実行できる確定入力にします。

たとえば、対象の商品管理番号、完成済みHTML、入力する欄、Yahooへコピーする対象、保存までの順序、例外条件、完了条件を先に決めます。

ブラウザ上では「検索する」「開く」「貼る」「コピーする」「更新する」に近い仕事だけが残ります。

考える工程と操作工程を分けることで、判断のやり直しとブラウザ操作が同じ場所で絡むのを避けやすくなりました。

本人実測では、30商品／100％から300商品／30％へ変わった

可児 波起は、最初の設計について「Work 100％使用で30商品」、設計を変えた後について「300商品を処理してWork使用量30％」と報告しています。

同じプロジェクト内では、商品名変更や画像登録を200商品まとめて処理できたこと、従来は手作業で1時間約10商品だったことも本人から共有されています。

ただし、これらを「役割分担によって処理効率が何倍になった」と単純計算することはしません。

Work使用量の内部ログ、各商品に必要だった操作数、対象商品の難易度、同じ条件での比較試験は今回のEvidenceでは確認できていないためです。

重要だったのは、Work自体を高速化したことではない

今回変えたのは、Workのモデル性能やブラウザ速度ではありません。

どの工程を、どの実行環境へ置くかです。

調査や文章制作のように、画面を操作しなくても進められる仕事をChat側へ戻し、ブラウザが必要な工程だけをWorkへ残しました。

この結果から少なくとも言えるのは、ブラウザAIの利用量を考えるとき、単純に「一つのAIへ全部任せる」以外の設計が実務上成立したことです。

OpenAI公式でも、ChatとWorkは役割の違う利用形態として案内されている

OpenAI公式の「ChatGPT Work and Codex」では、Chatは質問・検索・ブレインストーミングなどの会話的な支援、Workは調査・分析や文書・表・レポートなどの完成作業を行う利用形態として案内されています。

また、WorkのクラウドブラウザはWebページを読み、ボタンを押し、フォームへ入力し、対応サイト上で一連の操作を実行できます。

一方、OpenAI公式が「Chatで全部考え、Workには確定操作だけを渡す」と推奨しているわけではありません。

この役割分担は、筆者が支援するEC事業の商品更新を大量処理する中で、海辺の部屋が実際に変更した独自の工程設計です。

ブラウザAIへ渡す前の確認順

1. ブラウザを開かなくても終えられる調査・判断・文章制作を先に終える
2. 対象IDや商品管理番号を確定する
3. 入力値を完成形にする
4. 操作順、例外条件、停止条件、完了条件を決める
5. 最初の1件で操作経路を確認する
6. 問題がなければ同じ確定作業をまとめて展開する

ブラウザを操作できるAIへ、すべての仕事を集める必要はありません。

どこで考え、どこで動かすかを分けること自体が、AIワークフローの設計になります。

実務との接続：AIに考える工程と実行工程を分けて業務へ組み込む設計は、海辺の部屋のAI・戦略設計にまとめています。

このKnowledgeの関連知識

操作結果を確認する： 思考と確定操作を分けた後、送信・保存・読み戻し・表示確認を別状態として記録する。

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

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

Knowledgeトップを見る