AIに任せる仕事をどう設計するか――n8nの事例から考える「監督と記録」

記事

IT・テクノロジー

SIN｜AI活用・業務設計

2026/09/26 23:42

導入：何を頼むかと、何ができるかを分ける

AIにお願いしたいのは、顧客への連絡メモを残すこと。

それなのに、顧客情報を丸ごと削除できる権限まで渡していたら……。

「いや、そこまで頼んでないｗ」と言いたくなりますよね。

これは実際の事故を紹介する話ではなく、AIに仕事を任せるときの筆者による例えです。ここで考えたいのは、次の問いです。

AIに何を頼むのか。そのAIに、何ができる状態を渡すのか。

この2つは、分けて設計できます。さらに、任せた後に何をしたかを確認できる仕組みまで含めて考えると、AIへの任せ方はより具体的になります。

AIに仕事を任せるとは、指示を書いて終わりにすることではありません。目的、道具、権限、記録、承認の仕組みを組み合わせて、任せる範囲と監督の方法を決めることです。

n8nの事例：決まった作業をAIの「道具」にする

【公式発表に基づく事実】n8nは2026年9月25日、「n8n Agents」を発表しました。

公式発表によると、目的、使用するAIモデル、利用する道具を設定して動かす仕組みで、既存のワークフローと組み合わせられます。ワークフローとは、あらかじめ決めた順番で処理を行う作業手順です。

【筆者の注目点】この仕組みで興味深いのは、決まった手順そのものを、AIに渡す道具にできる点です。

【公式発表に基づく事実】公式発表には、「顧客管理システムにメモを追加する」例が示されています。

メモ追加専用のワークフローを渡せば、AI自身に顧客管理システムの認証情報を持たせずに済むと説明されています。この道具を通じて行えるのは、設定されたメモ追加の操作に限られます。

参考：n8n公式発表「Introducing n8n Agents」 — 「Your workflows can be your agent’s tools」

ここで重要なのは、AIに「削除しないで」と頼むだけではなく、そもそも削除できる道具を渡さない設計にできることです。指示の内容と、実際に使える操作を別々に管理することで、任せる範囲を具体的に絞れます。

人に置き換えると、会社の鍵を全部渡して「この部屋だけ使ってね」とお願いするか、必要な部屋だけ開く鍵を渡すか、という違いに近そうです。

もちろん、これは仕組みを理解するための筆者による例えであり、公式発表に記載された説明そのものではありません。

【筆者の意見・考察】それでも、「AIには丁寧に指示を書けばいい」と考えていると、見落としやすい部分が見えてきます。

頼み方を工夫すると同時に、できる操作も絞る。

たとえば、問い合わせ対応の仕事なら、情報を調べる、返信案を書く、実際に送信する、という工程を分けて考えられます。

調べるところと下書きまでは任せたい。でも、送信は人が確認してからにしたい。

こうした希望を、お願いの文章だけでなく、道具と権限、承認の仕組みにも反映する。これは、筆者が考えるAIへの任せ方の一例です。

ただし、権限を絞れば、それだけで十分というわけではありません。AIが限られた道具を使って何をしたのか、どの情報をもとに判断したのか、後から確認できなければ、問題が起きたときに原因をたどれません。

そこで次に必要になるのが、監督と記録の設計です。

監督と記録：任せた後をどう確認するか

AIに仕事を任せて、自分は別のことをする。

そんな使い方が広がるのは楽しみです。でも、ずっと画面の前で見張っていたら、結局こちらも勤務中ですよねｗ

一方で、何をしたか全く分からないまま任せるのも困る。

人がつきっきりにならず、必要なところは確かめられる。

【筆者の意見】AIの能力と同じくらい、そんな仕組みにも注目したくなります。

ここでいう「任せる」は、AIを放置することではありません。あらかじめ権限を絞り、行動を記録し、重要な場面だけ人が確認できるようにすることです。

監督を測るという考え方

【公式資料に基づく事実】Anthropicは、社内のAIエージェントをどのように監督しているか、その測定方法を公開しています。

【確認日と資料の基準時点】筆者が資料を確認したのは2026年9月26日です。資料で示されている計測の基準時点は2026年8月です。したがって、この記事では確認日を発表日として扱っていません。

【公式資料に基づく事実】測定の軸は、主に次の3つです。

エージェントの行動のうち、どれくらいが監視を通るか。行動から確認まで、どれくらい時間がかかるか。どれくらいが停止・方向転換・追加確認の対象になるか。

【公式資料に基づく補足】ここでいう監督には、自動の監視が含まれます。人間が全操作を一つずつ読む、という意味ではありません。

この考え方から見えてくるのは、監督を「人がすべてを見張ること」と捉えなくてもよい、という点です。危険度に応じて自動で確認し、必要な場合だけ人へ戻す。そうした仕組みを設計できれば、監督と効率を両立しやすくなります。

参考：Anthropic公式資料 — 「(2) Measuring oversight of AI agents」

AIが変わっても、仕事の記録をつなぐ

【公式資料に基づく事実】同じ資料には、モデルが変更されてもエージェントの識別と記録を維持する設計や、別のエージェントから受け取った情報を、確かめるべき主張として扱う設計が説明されています。

【筆者の要約・解釈】つまり、「別のAIが言ったから正しい」と、そのまま扱うわけではない設計です。

【筆者の考察】AI同士で仕事を分担するなら、回答を受け渡すだけでなく、誰が、どの道具を使い、どの情報を根拠に処理したのかをたどれることも役立ちそうです。

これは、権限を絞る考え方ともつながっています。AIが使える道具を限定し、その利用履歴を残せば、処理の範囲と経緯を確認しやすくなります。逆に、広い権限を持つAIが記録を残さずに動けば、問題が起きたときに、どこで何が起きたのか分かりにくくなります。

【公式資料の適用範囲に関する注記】これは同社の社内プラットフォームについての報告です。普段使うClaudeに、そのまま同じ機能があるという説明ではありません。また、監視する範囲が広いことと、問題をすべて検出できることは別です。

参考：同資料のAppendix「Oversight of agents」

任せた後をめぐる報道から考える

【報道に基づく事実】Reutersは2026年9月25日、OpenAIのエージェントによってChatGPT利用者の画像53件が流出したと、OpenAIが説明した旨を報じました。

【筆者の確認範囲】今回確認したのは、Investing.comに配信されたReutersの記事本文です。この件の詳細を裏づけるOpenAI公式本文は、今回の確認では取得できていません。画像の種類や投稿時期、原因、被害の全容についても、ここでは断定しません。

参考：Reuters報道（Investing.com配信）

【事実関係の整理】Anthropicの設計と、この報道は別の会社・別の出来事です。一方の仕組みが他方の問題を解決した、という関係ではありません。

【筆者の考察】ただ、AIに仕事を任せるとき、出力された答えだけでなく、途中で行った操作、使った権限、残された記録にも目を向ける必要はありそうです。

この観点では、事故を防ぐために権限を絞ることと、事故や異常を検知するために記録を残すことは、別々の対策ではありません。できることを限定し、何をしたかを記録し、危険な操作を止められるようにする。これらを組み合わせて初めて、任せた後の監督が機能します。

実践原則：AIに任せる範囲を設計する

AIができることが増えると、つい「もっと任せよう」と考えたくなります。

そこで一度、「その仕事に必要な道具はどれ？」と考えてみる。

全部入りの道具箱を渡す前に、必要なものを選ぶ。そのうえで、どの操作に権限を与え、どの場面で人の承認を求めるかを決める。さらに、使った道具、入出力、判断の経緯をどこまで記録するかも決める。

そうすると、任せたい仕事だけでなく、任せた後に確認すべきポイントもはっきりしそうです。

AIに仕事を任せるときは、次の4つを最初に設計します。

目的を絞る。 AIに何をさせるのか、任せる範囲を明確にする。道具と権限を絞る。必要な操作だけを渡し、できることを増やしすぎない。記録を残す。使った道具、入出力、判断の経緯を、後から追えるようにする。重要な場面で止める。送信や削除などの操作には、人の承認や追加確認を求める。

具体例：問い合わせ対応フローに落とし込む

以下は筆者による運用例です。n8nやAnthropicの必須仕様を示すものではありません。記録する情報は業務に必要な範囲に絞り、閲覧権限と保存期間を定めます。AIの自己申告の確信度だけで承認の要否を決めない設計も必要です。

この4原則を、顧客からの問い合わせ対応に当てはめてみます。

たとえば、問い合わせフォームに届いた内容をAIが確認し、社内の顧客管理システムや製品マニュアルを参照して、返信案を作る業務です。

1. 目的：AIに任せる仕事を定義する

まず、AIの目的を「問い合わせ内容を分類し、社内情報をもとに返信案を作成すること」と定義します。

ここで、目的に含める処理と含めない処理を分けます。

問い合わせ本文を読み、カテゴリや緊急度を付ける。顧客番号をもとに、契約状況や過去の対応履歴を参照する。製品マニュアルやFAQを検索する。返信案を作成する。判断に必要な情報が不足している場合は、追加確認事項を示す。

一方で、次の処理は目的の範囲外とします。

顧客情報を削除する。契約内容を変更する。返金や値引きを確定する。顧客へ自動で送信する。問い合わせと無関係な社内データを検索する。

目的をここまで具体化すると、「返信案を作るAI」と「顧客対応を完了させるAI」は別物だと分かります。

2. 権限：必要な操作だけを許可する

次に、AIが使える道具と権限を分けて設定します。

たとえば、次のような専用ワークフローを用意します。

問い合わせ本文を取得する。顧客番号に一致する基本情報と過去の対応履歴を読み取る。承認済みのFAQや製品マニュアルを検索する。返信案を下書きとして保存する。担当者へ確認依頼を送る。

このとき、AIには顧客管理システム全体の管理者権限を渡しません。顧客情報の削除、編集、エクスポート、権限変更などの操作は、道具の一覧から外します。

また、参照できる情報も必要最小限にします。たとえば、問い合わせ対応に不要な給与情報や社内評価、別部署の顧客メモまで検索できるようにする必要はありません。

3. 記録：後から経緯を追えるようにする

AIが返信案を作ったら、結果だけでなく、処理の経緯も記録します。

最低限、次の項目を残します。

問い合わせを受け付けた日時と識別番号。使用したAIモデルやエージェントの識別情報。参照した顧客情報の項目。検索したFAQやマニュアルの文書IDと版。AIが作成した返信案。AIが付けたカテゴリ、緊急度、確信度。実行したワークフローと処理結果。エラーや、情報不足として人へ戻した理由。その後に誰が修正・承認・送信したか。

記録は、AIの判断を無条件に正しいと証明するものではありません。ただ、問題が起きたときに「どの情報を見て、どの処理を行い、どこで人が判断したか」を確認する手がかりになります。

4. 承認：送信や例外処理で人に戻す

最後に、どの操作で人の承認を必要とするかを決めます。

通常の問い合わせであっても、AIが作った返信案をそのまま送信するのではなく、担当者が確認してから送信する運用にします。

特に、次のような場合は必ず人の承認を求めます。

返金、値引き、契約変更が関係する。個人情報や機密情報を含む。法的な主張、謝罪、補償に関係する。顧客からの苦情や事故報告である。AIの確信度が設定した基準を下回る。参照した情報同士に矛盾がある。返信先や添付ファイルに誤りの可能性がある。顧客への送信、社内外への共有、データ更新を伴う。

承認画面には、返信案だけでなく、参照した情報、判断理由、変更履歴、注意すべき点を表示します。担当者は「承認」「修正して送信」「差し戻し」「担当部署へ転送」などを選べるようにします。

問い合わせ対応の一連の流れ

実際の流れをまとめると、次のようになります。

問い合わせを受け付け、受付番号を発行する。AIが問い合わせ内容を分類し、緊急度と必要な担当部署を判定する。許可されたワークフローを通じて、必要最小限の顧客情報と社内資料を参照する。AIが返信案と判断理由を作成する。参照情報、使用した道具、処理結果を記録する。通常案件は担当者が確認し、必要に応じて修正する。返金、契約変更、個人情報、苦情などを含む案件は、追加の承認者へ回す。承認後に担当者が送信する。送信結果と最終版の返信内容を記録する。エラー、差し戻し、修正の多かった案件を定期的に確認し、ワークフローや権限を見直す。

この流れなら、AIは調査と下書きに集中できます。一方で、送信や重要な判断は人が担い、AIが何を根拠に動いたかも後から確認できます。

ここで大切なのは、4原則を別々に扱わないことです。

目的が曖昧だと、必要以上の権限を渡しやすくなる。権限を絞っても、記録がなければ何をしたか分からない。記録があっても、承認の基準がなければ危険な操作を止められない。承認を求めても、目的や権限が広すぎれば、人が確認する量が増えすぎる。

目的、権限、記録、承認を一つの業務フローとして設計することで、AIに任せる範囲と、人が確認する範囲を具体的に分けられます。

ほかの業務にも応用する

同じ考え方は、問い合わせ対応以外にも使えます。

たとえば、経費精算なら、AIには領収書の読み取り、勘定科目の候補提示、申請内容の不備確認までを任せ、支払い確定は承認後に行います。

資料作成なら、AIには指定されたフォルダ内の資料検索と下書き作成を任せ、外部送信や公開は人の承認が必要です。

採用業務なら、AIには応募書類の整理や面接質問の候補作成を任せても、合否の決定や候補者への連絡は、定めた基準と人の確認を経て行います。

どの業務でも、最初に次の4点を決めます。

AIの目的は何か。AIに許可する操作は何か。どの情報と判断過程を記録するか。どの操作や条件で人の承認に戻すか。

結論：任せ方そのものを設計する