AIエージェントの先にあるHACW。人の判断を次回の業務ルールへ変える

Signal

AIの成果物を採用するには、根拠、検査結果、人の判断を次に作業する人またはAIエージェントへ引き継ぐ必要がある

AIエージェントに調査、照合、資料作成を任せると、成果物はすぐ返ってくる。

しかし、その報告だけでは仕事は終わらない。

どの条件を満たしたのか、どの資料を使ったのか、どこで作業が止まったのか、そして何を人が決めるのかが分からなければ、成果物を業務へ移せないからだ。

AIアシスタントは質問に答え、AIエージェントはツールを使って仕事を実行する。

エージェンティックAIは複数の手順やエージェントを組み合わせ、作成基盤はそれらを設計し、統制基盤は権限や利用状況を管理する。

企業の仕事では、これらの実行の前後に目的の設定、条件の変更、成果物の統合、根拠の確認、承認が続く。

OpenAIのWorkspace Agentsは、組織が許可したデータと道具の範囲で長時間の仕事を進め、必要な操作では承認を求め、管理者には設定、更新、実行履歴を見せる。

MicrosoftとGoogleの評価機能は、最終回答だけでなく、タスク完了、道具の選択、入力値、道具の出力を正しく使ったかを個別に検査する。NISTのEvaluation Probesは、AIの主張を人が選んだ信頼済み文書と照合し、根拠との対応を機械可読な監査記録へ残す。

OpenAIが掲載した顧客コメントで、Ripplingは、営業向けWorkspace Agentがアカウント調査、Gong通話の要約、Slackへの案件概要投稿をつなぎ、担当者が週に5〜6時間かけていた作業を案件ごとに自動実行していると報告している。

これは、エージェントが会話を越えて複数の道具とチーム手順を扱う実装例である。一方、業務判断を将来のタスク契約や評価器へ昇格させる部分までを、この事例だけから確認することはできない。

これらの公開資料を重ねると、AIへ仕事を委ねた後も、誰が何を実行し、どの根拠で検査し、どの判断を人が引き受けたかを追える業務環境が必要になる。

Definition

目的、制約、担当、実行結果、根拠、検査結果、人の判断を人とAIが引き継ぐ業務環境を、本稿ではHACWと呼ぶ

この問題を解くには、依頼時の目的と禁止事項から、実行記録、根拠、検査結果、人の判断までを、業務担当者やAIエージェントが替わっても引き継げる環境が要る。

HACWは本稿が公開情報から導く作業仮説であり、Gartnerが公開面で詳細な標準仕様として確定した名称ではない。

Gartnerの2026年Digital Workplace Applications Hype Cycleの公開要約が確認できるのは、組み込みAIの統制と「human-agent work models」への準備である。

ここでいうワークスペースは、チャット画面や共有フォルダだけを指さない。

担当するAIエージェントが替わっても、業務が人へ戻っても、同じ目的、現在の業務担当者、許可された操作、完了済みと未完了の項目、根拠、検査結果を引き継げる共有記録を指す。

Microsoft Researchは、共同目標の理解、先回りしたタスク管理、共有された進捗追跡を協働の条件として挙げてきた。

Interaction、Process、Infrastructureの枠組みも、活動の構造を明示的かつ検査可能な対象にする。

これらの実装と研究を重ねると、HACWの条件は、業務過程を会話の裏側へ隠さず、担当、権限、進捗、検査結果、人の判断を成果物と同じ共有記録に残すことだと判断できる。

HACWは、この一連の記録を単一のエージェントの内部に隠さず、業務責任者、オーケストレーター、実行担当、評価担当が読める共有記録として管理する。

Operating Model

権限と判断基準が異なるため、業務責任者、オーケストレーター、特化型エージェント、評価プログラムに役割を分ける

目的と禁止事項を決める、作業を割り当てる、データを更新する、成果物を検査するという行為では、必要な権限と判断基準が異なる。

そのため、HACWでは、業務責任者が業務の条件を決め、オーケストレーターが担当を選び、専門AIや既存システムが実行する。

その結果を業務別の評価器が検査し、自動判定できない点だけを人へ戻す。人が理由と適用条件を記録した判断は、次回も人に尋ねる条件と、人に尋ねず進められる条件を更新する。

人間の曖昧な依頼を受け取る入口には、目的の確認、タスク分解、担当選択、進捗管理、結果統合を担うオーケストレーターが必要になる。

OpenAIは、管理役が会話の主導権を保ちながら専門エージェントを道具として呼び出す方式と、専門エージェントへ会話自体を引き渡す方式を区別している。

Microsoftも、中央の担当が全体責任を保つagent-as-toolsと、担当自体が移るhandoffを分けている。

ただし、意図を解釈する汎用性と、何でも直接実行できる権限は同じではない。

オーケストレーターが専門エージェントと同じデータ更新権限を持てば、業務別の手順と監査を迂回できるためだ。

原則として、オーケストレーターは仕事を定義し、許可された担当へ配り、各担当の進捗、成果物、検査結果、未解決点を統合する。

高い権限を伴う実行は、明確な業務契約を持つ特化型エージェントか、決定的なシステムへ限定する。

次の六段階は直線的に一度だけ進むとは限らず、検査結果や人の判断によって前の段階へ戻る。

Validation and Human Review

成果物を業務別に検査し、自動判定できない事項と、組織がAIに実行権限を与えていない操作だけを人へ示す

監査には、どの業務にも共通する記録と、業務ごとに異なる合格条件がある。

MicrosoftとGoogleの評価機能は、最終回答だけでなく、タスク完了、指示遵守、道具の選択、入力値、出力の利用、期待された実行経路を別々に評価する。

これは汎用エージェント全体を一つの点数で監査する方向ではない。

特定のタスクが定めた契約をテストする方向である。

NISTのEvaluation Probesも、まずAIの主張が人間によって管理された信頼済み文書に支えられているかを、引用ごとに検査する。

ただし、「出典がある」「回答が出典と整合する」「出典自体が現実に正しい」「業務で採用してよい」は、別々に判定しなければならない。

根拠は「未検証」「出典と整合」「独立確認済み」「システム検証済み」「人間承認済み」「対立中」「期限切れ」のように段階管理する方が、二値の正誤より実務に近い。

AIにすべてを説明させても、人がその速度と量を処理できなければ、承認待ちとレビュー疲れが新しいボトルネックになる。

Gartnerは高い自律性のエージェントについて、人が個々の判断ではなく、例外、監査ログ、集約結果を見る運用を示している。

2026年の初期研究も、AI成果物の継続的な確認と大量の提案が、人の認知負荷と見えにくいコストになり得ると報告している。

そのため、HACWは全量の実行記録を機械可読な形で保存しながら、人には前回の確認から変わった項目だけを示す。

人はエージェントの全操作を常時監視せず、前回の確認から変わった項目、検査に落ちた項目、人に残した判断、組織が実行権限を留保した操作を確認する。

人へ出す判断依頼には、現在の目的、新たに完了または失敗した項目、重要な操作、自動検証の結果、未確認事項、判断しなかった場合の影響、求める決定を含める。

詳細なトレースは調査時に開ければよく、常時読ませるものではない。

高リスク操作の明示承認は、エージェントが判断できないからではなく、組織が実行権限を人に留保する統制である。

Decision Memory

人の判断は記録しただけでは自動実行に使わず、適用条件を検証できた場合だけ次回の業務ルールへ変える

Step 06で得た判断は、その場の承認で終わらせない。理由と適用条件を共有記録へ記録し、再利用できるものはStep 01のタスク契約かStep 05の評価器へ戻す。

OpenAI Agents SDKの手動承認は、機密性の高いツール呼び出しの直前で実行を止め、人が許可か拒否を返す。プログラムで判定できる条件なら、承認コールバックによって停止せず続行することもできる。

どちらも実行中の操作を許可する仕組みであり、人が下した業務判断を、別の将来タスクにも適用できるルールへ変える仕組みとは限らない。

判断理由と適用条件が次のタスク契約、評価器、権限ポリシーへ戻らなければ、同じ条件でも次回また人を呼ぶ。

同じ条件の請求書が翌月にも届いたとき、従来のAIアシスタントでは、担当者が前回の回答と承認結果を探し、新しい作業へ持ち込む。

HACWでは、前回の判断理由、金額や取引先などの適用条件、例外、有効期限を共有記録から照合する。承認済みルールに一致すれば自動処理し、一致しなければ過去判断を参考資料として人へ戻す。

この違いはエージェントの賢さではなく、前回の仕事で得た判断が、将来の別タスクを人に確認せず進められる条件へ変換されるかどうかにある。

新しいタスクが過去の判断と意味的に似ているだけでは、自動実行しない。

金額、取引先、機密性、適用規程、取り消し可能性、有効期限を照合し、承認済みルールに一致した場合だけ進める。

類似するだけなら過去判断を参考資料として人へ提示し、情報が足りなければ追加調査か再評価へ戻す。

ReflexionとExpeLは、反省や経験を記憶し、後の試行で取り出すことでエージェントの判断を改善できることを示した。

OpenAIのAgent memoryも、過去の作業から抽出した教訓や人の修正を将来の実行へ持ち越す一方、記憶は古くなり得るため、現在の環境を優先するよう求めている。

AWSのAgentCore Policyは、実行条件をエージェントの記憶ではなく、検証可能な決定的ポリシーとして外部で評価する。

これらを組み合わせると、記憶は判断候補の検索に使い、自動実行は検証済みルールで制御するという境界が導ける。

Three Modes

手順の明確さ、失敗の影響、操作を取り消せるかに応じて、AIへ任せる作業と人が決める事項を変える

HACWは一つの自動化方式ではない。

手順と判断が明確な仕事、手順が柔軟で判断も必要な仕事、アイデアや交渉のように人の判断が中心になる仕事では、同じ共有記録とルール更新を使っても、自動実行する作業と人へ戻す判断が変わる。

この分類には、失敗時の影響と不可逆性も重ねる。

手順が明確な送金でも高額なら承認が要り、手順が柔軟な社内ブレインストーミングでも低リスクなら自律性を高められる。

HACWの役割は常に人を減らすことではなく、業務ごとに責任の分担を選べるようにすることにある。

以下は公開済みの導入事例ではなく、この三分類を具体的な業務へ当てはめた想定シナリオである。各例は、業務によって自動検査と人の判断の分担がどう変わるかを示す。

What Is Missing

オーケストレーション、承認、評価、権限管理は各社製品にあるが、目的、根拠、検査結果、人の判断を製品間で引き継ぐ共通形式はまだない

OpenAI、Microsoft、Google、Anthropicは、オーケストレーション、専門エージェント、セッション、承認、評価、トレース、権限管理をそれぞれ実装している。

研究面では、CHAPが作業空間（workspace）、参加者、タスク、成果物、追記型の証拠ログを最小構成として提案し、CLEOとPistaは人が実行途中で観察、指示、共同作業、停止できる画面を検証している。

しかし、これらは一つの成熟した標準や製品カテゴリとして統合済みとは言えない。

企業導入で不足するのは、依頼時の目的、実行結果、検査結果、業務責任者の判断を、これらの機能の間で引き継ぐ共通契約である。

業務ごとのタスク契約と評価器、エージェントの能力、所有者、権限を示す登録簿、成果物と根拠に付ける共通ラベル、オーケストレーターが適切な担当を選んだかの評価、証跡を別製品へ持ち運ぶ形式、人のレビュー時間を上限付きで管理する指標が必要になる。

判断記録には適用範囲、例外、有効期限、責任者を持たせ、業務ルールへ昇格するときはテスト、版管理、承認、取り消し方法を備える必要がある。

成果を測る指標も、エージェントの実行回数では足りない。

検証済み成果物一件あたりの総コスト、人のレビュー時間、エスカレーション率、判断待ち時間、差し戻し率、自動承認後の誤り発見率、監査キューの滞留量を、成果物の正確性、完全性、目的適合性と分けて追う必要がある。

Conclusion

AIエージェントの次に問われるのは、人の確認を必要な判断だけに絞り、検証済みの判断を次回の同種作業へ反映できるかである