人とAIが仕事を引き継ぐHACW　実行の先に残る協働の課題

AIが仕事を終えても、背景を説明し直す人がいる

営業担当者が、顧客調査と提案書の下書きをAIへ任せたとする。 翌日、顧客が費用より導入期間を重視していると分かり、別の担当者が提案を引き継ぐ。 完成した文章だけを渡せば、なぜその案を選んだのか、どの条件は未確認なのか、どこを直せばよいのかを、最初の担当者が説明し直すことになる。 これは協働の設計を考えるための想定例である。

エージェントが道具を使って調査できることと、次の人がその仕事を引き継げることは違う。 人は依頼を出して待つだけでなく、途中で目的を変え、成果物の一部を作り、異なる根拠を比較する。 その変更をAIや次の担当者へ伝える仕組みがなければ、自動実行が増えても説明と修正の負担は残る。

本稿は2026年8月12日までの製品発表と研究から、人とAIが同じ仕事を引き継ぐ環境を考える。 目的、担当、成果物の版、根拠、変更、人の判断を共有する設計仮説を、Human-Agent Collaboration Workspace（HACW）と呼ぶ。 確立した標準の紹介ではなく、どの機能をつなぎ、何を試す必要があるかを示す著者の提案である。

複数の道具をつなぐ実行は、既に製品へ入っている

OpenAIのWorkspace Agents発表は、組織で共有するエージェントが、許可された道具とデータを使い、必要な操作では承認を求める構成を説明した。 発表に掲載されたRipplingの顧客コメントでは、アカウント調査、Gongの通話要約、Slackへの案件概要の投稿を一つの仕事へつないでいる。 担当者が週に5〜6時間かけていた作業を自動化したという記述は、顧客の報告であり、独立した時間測定ではない。

この例が示すのは、回答を返すAIから、チームの手順を複数の道具で進めるAIへ、製品の対象が広がったことである。 一方、調査に使った前提を別の担当へ渡せるか、人が修正した理由を次の仕事へどう反映するかまでは、この時間の報告だけでは分からない。 実行の接続ができた後に、仕事の文脈を共有する設計を確かめる必要がある。

冒頭の提案書なら、顧客の新しい意向を伝えた後、費用比較の表だけを残すのか、導入工程を調べ直すのかが変わる。 既存の機能を一つの名称でまとめる前に、目的の変更が担当と成果物へ届くかを見る。 HACWの出発点は、さらに多くの操作を実行することより、この引継ぎを成立させることである。

人は最後の承認者だけではない

CLEOの初版論文は、人がエージェントへ任せる、方向を示す、同じ作業空間で並行して働く関係を調べている。 最初の探索研究は専門のデザイナー10人、改良したCLEOを使う二日間の研究も10人を対象とした。 これは協働の行動を観察する研究であり、全業務の生産性を比較した実験ではない。

最初の試作では、AIの作業が見えることで人が途中から直したくなる一方、AIが人の独立した作業と修正指示を区別できず、変更を戻すなどの衝突が生じた。 改良した設計は、人の操作が何を意味するかを解釈する点を重視する。 単に実行の説明を見せることと、人が同時に行った変更を扱うことは別の能力である。

提案書の想定例なら、人が顧客向けの冒頭文を直している間、AIには導入期間の資料を調べてほしいかもしれない。 冒頭文の変更を「全文を書き直せ」という指示と扱えば、人の作業が失われる。 誰がどの部分を担当し、その変更が他の作業へ影響するかを共有したい。

Magentic-UIの研究報告も、人とAIが計画を作り、作業に参加し、必要な操作を制御するための試作を提示している。 これらは、協働を最後の許可だけで捉えないための具体例になる。 ただし、研究用の画面と、複数部門で継続運用できる業務環境は同じ成熟度ではない。

途中で直せることの効果は、何を測ったかで読む

Pistaの初版論文は、表計算の変更を手順へ分け、式、対象範囲、後続への影響を示し、部分修正から別の実行案へ分岐できる仕組みを提案した。 人が完成後の表を点検するだけでなく、計算の前提を途中で問い直せる設計である。

比較評価はExcelの経験がある16人による同一参加者内の試験で、12人は大学院生だった。 二つの表計算課題について、Pistaから協働用の機能を外し、変更後の要約を返す方式を比較対象にした。 指示の平均回数はPistaが2.19、比較対象が4.00で、論文は有意差を報告している。 この回数を、完成時間や実務の誤りが同じ割合で減ったという意味にはしない。

本稿がこの研究から受け取るのは、修正する手順を指せれば、仕事全体を説明し直さずに介入できる可能性である。 それでも、見やすい説明への信頼が増えることと、計算が正しいことは別に確かめる。 HACWでも、参加した感覚、目的を反映できたか、成果物の正確性を同じ点数へまとめたくない。

HACWは、同じ仕事を引き継ぐための共有記録を持つ

本稿の設計では、目的と未確定の条件、現在の担当、許可された操作、採用する成果物の版、使った根拠、検査結果、変更理由、未解決点を共有する。 過去の会話を全部保存することではなく、次の担当が現在の状態を理解し、必要な原資料へ戻れることを重視する。 一人が使う場合でも、翌日の自分とAIへ引き継ぐ問題は残る。

Copilot Pagesの発表は、生成された内容を保持し、人が編集、追記、共有する対象を示した。 こうした共有文書は成果物を渡す足場になる。 ただし、本文を共同編集できることから、仕事の担当、実行権限、判断の適用範囲まで共有できるとは推定しない。

CHAPの初版論文は、作業空間、参加者、タスク、成果物、追記型の証拠ログを持つプロトコルを提案し、仕様と参照実装を公開している。 担当変更や人の修正を、会話の中だけに残さず構造化した記録へする試みである。 従って、こうした形式が全く存在しないとは言えない。 提案があること、広く採用されていること、別の製品で実際に引継ぎができることは、区別して確認する必要がある。

共有記録が改ざんを検知できても、記録された判断が正しいことまでは保証しない。 同様に、参照先の権限が違えば、引継ぎ先は根拠を開けないかもしれない。 記録の形式と、その記録を使って仕事を続けられる条件を一緒に設計したい。

五つの役割を、五つのAIと同一視しない

共有記録を使う担当を、以下の五つの役割へ整理する。 これは本稿の分担案であり、必須の製品構成ではない。 同じ人が目的を決めて専門作業も行う場合や、既存プログラムが調整と検査を担う場合もある。

役割を分ける理由は、人数を増やすことではない。 顧客の目的を変えられる人と、資料を調べるAIと、公開や送付を許可する担当では、決められることが違う。 一つのAIへまとめても、この違いを記録と権限で保てるかを問う。

任せる範囲は、仕事の途中でも変わる

Anthropicのエージェント設計の解説は、決められた手順を進めるワークフローと、モデルが手順を選ぶエージェントを区別し、必要以上に複雑な方式を選ばないよう勧めている。 仕事の順番が安定しているなら、毎回AIが分解するより、既存の処理へ入力を渡す方が扱いやすい場合がある。

同社の複数エージェントによる調査システムでは、主担当が調査を分け、専門担当の結果を統合する。 一方、同じ文脈を全員で共有する必要がある仕事や、作業同士の依存が多い仕事は、この方式に合いにくいとも説明している。 独立して調べられる論点があることと、成果物を整合した一つの提案へ戻せることを分けて考えたい。

提案書の想定例では、競合製品の調査は別々に任せ、顧客が何を重視するかは担当者が話を聞き、導入工程は一緒に直すという分担が考えられる。 新しい条件が出れば、既に任せた調査を止めたり、完了した比較を再確認したりする。 任せる、共同で作る、人へ戻すという関係を、最初の依頼で固定しない。

ただし、短い定型作業にこの調整を毎回加えれば、引継ぎ記録の維持が仕事を増やす。 前例の少ない交渉では、過去の判断を再実行するより、人が理由を参考にする方がよい場合もある。 HACWの範囲は、仕事が継続し、途中変更や担当交代が実際に起こるところから試したい。

根拠がそろうことと、採用してよいことを分ける

Anthropicの評価の解説は、エージェントの実行記録と、環境に残った結果を区別し、課題に合わせて採点方法を選ぶ。 調査したと書いてあること、出典を提示したこと、実際に必要な情報を確認したことは同じではない。

提案書なら、資料に記述があるか、その資料が最新か、顧客の条件に適用できるか、相手に約束してよいかを別々に見る。 出典と整合する文章でも、導入期間が特定の構成に限られるなら、別の構成へそのまま使えない。 計算や形式はプログラムで検査できても、条件の不足や価値の優先順位は人が判断する場合がある。

操作の許可も別の確認である。 AWSのAgentCore Policyの2025年12月発表は、Gatewayを通る道具の呼出しを規則に照らす仕組みを説明した。 これは実行条件を制御する例であり、提案の内容が顧客に適切かを判定する評価器そのものではない。

人へ戻すときは、成果物だけでなく、何を確認済みで、どの条件が不足し、何を決めてほしいかを渡す。 AIが判断に迷った場合と、組織が人へ留保している操作も区別する。 それによって、担当者は調査不足を補うのか、目的を選ぶのか、操作を許可するのかを理解できる。

今回の承認を、次回の許可へ変えるには検査が要る

共有する判断記録の使い方を、請求書の想定例で考える。 担当者が、契約に一致する月額料金について、契約番号、期間、金額、登録済みの支払先を確認して承認したとする。 翌月の請求が同じ取引先から届いても、前回だけの例外や変更があり得る。 過去の承認を見つけることは、新しい操作の許可を得ることではない。

再利用するなら、契約が有効、金額が契約額と一致、請求期間が未処理、支払先が不変という条件を、責任者がルールの候補へする。 参照した契約の版、適用期限、許可する操作も記録する。 文章が似ていることではなく、対象データが条件を満たすかを確かめる。

• 通常例に加え、金額超過、支払先変更、二重請求を試験し、自動許可から除く。
• 契約を取得できない、期間を読めない場合は、推測せず人の確認へ戻す。
• 責任者が試験と範囲を確認した版だけを有効にし、契約変更や誤りで失効させられるようにする。

照合に合格しても、送金に別の承認を求める組織なら、その許可は省略しない。 また、試験に含めなかった例外まで正しく扱えるとは限らない。 判断の再利用はHACWの一つの機能だが、人の判断を全て自動実行へ変えることを目的にしない。

次の仕事へ残すのは、採用した判断とその条件である

Reflexionは、試行のフィードバックから文章の振り返りを作り、後の試行へ渡す方式を評価した。 経験を再利用する研究上の例にはなるが、業務の操作権限を与える根拠とは異なる。 過去の記録は関連する候補を探すために使い、現在の指示と許可の確認を置き換えない。

冒頭の提案書なら、顧客が導入期間を重視した理由、採用した案、残った調査、次の担当が決める事項を残す。 費用を重視した古い方針を検索で取り出しても、翌日の訂正が優先されるようにする。 提案本文、判断記録、将来の自動実行ルールは、用途と更新する責任者が違う。

この記録を使う人が、元の資料へ戻り、変更した箇所と影響する結論を確かめられることを目指す。 記録量が増えるほどよいとは言えない。 保持する情報、訂正する担当、不要になった記録を消す条件を決め、全会話を読まないと引き継げない状態を避けたい。

人が説明し直す時間まで含めて試す

HACWの効果は、エージェントの実行回数だけでは測れない。 同じ仕事を、従来の会話とファイルの受渡し、必要な共有記録を持つ構成で比べる。 途中の条件変更と担当交代を課題へ入れ、説明し直した回数、古い版を使った件数、条件の欠落、修正に要した人の時間を記録する。 これは本稿の評価案であり、HACW全体の実測結果ではない。

確認依頼が減っても、記録の作成やルールの維持にそれ以上の時間を使うなら利点は小さい。 全操作を表示しても、人が重要な変更を見つけられなければ、安心感だけが増える恐れがある。 前回の確認から変わった条件、根拠の対立、未検査の事項を示し、必要なときには原記録へ戻れる構成を試したい。

結論として、人とAIの協働環境には、任せた仕事を途中から理解し、直し、別の担当へ渡せることを求める。 HACWは、その条件を目的、成果物、担当、根拠、判断の共有として整理する仮説である。 翌日に提案書を受け取った人が、昨日の会話を最初から説明してもらわず、変わった顧客の条件を踏まえて仕事を続けられる。 その状態を、実際の仕事で確かめていきたい。