監視作業とは。AIに任せる前と後に分かれる4つの仕事

コラム一覧へ戻る

監視作業とは何を指すか

監視作業（oversight work）は、AIや自動処理に作業を任せたときに、人の側へ残る確認と制御の仕事を指します。出てきたものを読んで直すことだけではなく、任せる前にやらせないことを決める作業や、着手前に段取りを合わせる作業も含みます。

この語の使い方は、2026年6月に arXiv で公開された調査に沿っています。Microsoft の研究者3人が、業務でAIエージェントを使っている開発者17人に、1人あたり平均1時間の聞き取りをしたものです。17人のうち16人が週に数回以上、そのうち12人が毎日エージェントを使っています¹。

この調査は、監視作業が事後の振り返りだけでなく、予防的で先回りの作業でもあると報告しています²。つまり監視は、成果物が出てきた時点から始まるものではありません。

監視作業は4つの形に分かれる

調査は、開発者がやっている監視作業を4つに分けています。

• 任せる前の制限。作業を渡す前に、動きを方向づけて制限する指示を与える。ある参加者は、消してほしくないものを消させないための禁止一覧を更新していると説明しています。
• 着手前の計画合わせ。何を目指すかをAIと人が一緒に決めて、認識を揃える。
• 実行中の観察。作業の様子を見て、必要なときに割り込む。
• 事後のレビュー。出てきたものを確かめ、直す。

4つのうち3つは、成果物を見る前に置ける作業です。監視作業を「出てきたものを読むこと」だと考えていると、この3つが運用の設計から抜け落ちます。

事後のレビューだけが、任せた量に比例して増える

同じ調査は、事後のレビューで起きる困りごとも挙げています。自分が書いたものではないので理解が表面的になる。AIに直させるたびに読み直しになる。出てくる量そのものが多い。

置き場所によって、監視作業の増え方が変わります。任せる前の制限は、一度決めれば以後の依頼すべてに適用されます。事後のレビューは依頼1件ごとに発生します。だから事後にだけ監視を置くと、依頼が増えた分そのまま読む時間が増えます。

読む時間が足りなくなった先で何が起きるかは、承認疲れの記事で扱っています。確認は中身を読まない押印に変わり、記録の上では同じ「確認済み」として残ります。

「うちはAIに開発をさせていないから関係ない」と思われるかもしれません。この調査の対象は開発者で、しかも17人のうち12人が同じ技術企業に所属しています³。任せていた作業も比較的小さく、実行中の観察をしなくても済む状況だったと著者自身が限界に書いています。ですから割合や強さを自社に持ち込むのではなく、監視作業が4つに分かれるという区分だけを借ります。成果物が見積書でも顧客への返信文でも、任せる前と後に人の手が要る点は同じです。

任せる前に置ける監視を、禁止と受入条件で書く

調査は、任せる前に置く2つの作業にも難しさがあると報告しています。設定の仕組みはあるのに、実際に制御できている感覚は薄い。指示をどこまで細かく書けばいいか分からない。自然言語で書くので、頼んだつもりの内容と実行された内容がずれる。

この3つを踏まえると、「丁寧にやってください」のような書き方は監視作業になりません。任せる前に書くのは、次の2つです。

• 禁止。やらせないことを名指しで書く。顧客へ送信しない、単価表を書き換えない、社外に公開しない、既存のファイルを消さない。
• 受入条件。満たしていたら完了と認める条件を書く。金額の根拠が案件の見積条件と一致している、宛先に担当者名が入っている、参照した資料の名前が本文に出ている。

この2つを書いた分だけ、事後に読む量が減ります。禁止に触れていないかと、受入条件を満たしているかだけを見れば済むからです。逆にどちらも書かずに任せると、確かめ方がその場の判断になり、結局は全文を読む作業に戻ります。

体裁が整っていることを、満たした証拠として扱わない

調査は、開発者が使っていた判断のくせも挙げています。そのうち2つは、開発以外の業務でもそのまま出ます。

1つは、テストが通ったことを中身の正しさの保証として扱うことです。もう1つは、自分が詳しくない領域ほどAIの出力を信じることです。

業務に置き換えると、エラーなく処理が終わった、書式が整っている、それらしい文章になっている、という状態を、依頼を満たした証拠として数えることに当たります。書式は受入条件の一部でしかありません。自分が詳しくない分野の依頼ほど、何をもって満たしたと言えるのかを先に書いておく必要があります。書いていなければ、確かめられるのは体裁だけになります。

どの依頼に人の確認を挟み、どれは流してよいかの線引きは、Human-in-the-loop の記事で扱っています。この記事は、挟むと決めた確認を4つのどこに置くかの話です。

PATHWORK での扱い方

PATHWORK は、チャットで来た依頼をタスクに起こし、担当と状態と期限を1画面で追う道具です。監視作業の文脈では、タスクに目的と受入条件の欄がある点が対応します。任せる前に置ける監視は、依頼の文面ではなくこの欄に書けます。欄にあれば、依頼を出した人と受けた人が同じものを見て、後から確かめ直せます。

担当を移すときは、送付してから承諾または差し戻しを通ります。誰の手元でボールが止まっているかが状態として出るので、事後のレビューが特定の1人に溜まっていることも表に出ます。タスクの変更履歴も残るため、レビューでは成果物の全文ではなく、何が変わったかを見る形にできます。

ただし、欄を用意することと中身を書くことは別です。禁止と受入条件を空欄のまま任せれば、確かめ方は人の頭の中に戻り、出てきたものを全部読む運用に逆戻りします。

依頼の種類ごとに決めておく項目

• やらせないことを書き出したか。送信、公開、支出、既存データの書き換えのうち、どれを禁止にするか。
• 満たしていたら完了と認める条件を、依頼に書いたか。
• 途中で止める必要がある依頼か、終わってから見れば足りる依頼かを分けたか。
• 事後に見るのは成果物の全文か、変わった箇所か。
• 事後のレビューが特定の1人に集まっていないか。

まとめ

監視作業は、AIに任せたときに人の側へ残る確認と制御の仕事です。任せる前の制限、着手前の計画合わせ、実行中の観察、事後のレビューの4つに分かれます。事後のレビューだけが依頼の件数に比例して増えるので、そこにすべてを寄せると、任せた量がそのまま読む量になります。

ただし、根拠にした調査は開発者17人への聞き取りで、対象も所属も偏っています。区分は借りられますが、どの依頼にどれだけ手をかけるかは自社の依頼で決めることになります。

次の一手は、いまAIに任せている依頼を1つ選び、禁止と受入条件を書き出してみることです。書けない項目が出てきたら、その依頼はまだ事後のレビューを厚くしておく対象だと判断できます。

参考

本文中の番号をクリックすると、その数字の根拠にした原文にジャンプします。原文は改変せず、そのまま載せています。

1. Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu「Human oversight of agentic systems in practice」arXiv:2606.05391（2026年6月3日）

   Shipi Dhanorkar ... Affiliation: Microsoft, Redmond, USA, Samir Passi ... Affiliation: Microsoft, Redmond, USA and Mihaela Vorvoreanu Affiliation: Microsoft, Redmond, USA ... Interviews were scheduled for one hour, lasting 60 minutes on average, and conducted between July-August 2025. ... Sixteen of 17 participants used agents several times a week for professional work (12 daily).

   著者欄および 3.2 Data collection and analysis（本文の「Microsoft の研究者3人」「17人」「平均1時間」「16人が週に数回以上、12人が毎日」の根拠） 本文の該当箇所へ戻る
2. Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu「Human oversight of agentic systems in practice」arXiv:2606.05391（2026年6月3日）

   participants described doing such anticipatory "pre" work at times with explicit oversight intentions (e.g., preventing known mistakes or failures from occurring altogether).

   考察（本文の「予防的で先回りの作業でもある」の根拠） 本文の該当箇所へ戻る
3. Shipi Dhanorkar, Samir Passi, Mihaela Vorvoreanu「Human oversight of agentic systems in practice」arXiv:2606.05391（2026年6月3日）

   The 12 participants were on distinct teams across domains with no overlapping projects; they shared similarities (e.g., security requirements) but also exhibited differences (e.g., using different agents for tasks). The 5 participants from other organizations shared similar experiences.

   3.1 参加者（本文の「17人のうち12人が同じ技術企業に所属」の根拠。論文が明示した限界） 本文の該当箇所へ戻る