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

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

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つを最初に設計します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ほかの業務にも応用する

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

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

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

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

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

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

ずっと見張り続ける負担を減らすには、AIを放置するのではなく、任せた後の仕組みを設計する必要があります。

権限を絞ることは出発点です。その先に、監督の対象、記録の内容、確認のタイミング、承認が必要な操作を設計する。そうすることで、人はすべての動きを見るのではなく、重要な場面に集中できます。

AIへの指示を考えるときは、渡す道具と権限、そして残す記録も一緒に考える。

AIに何をさせるかだけでなく、何をさせないか、何を記録し、どこで人が確認するかまで決める。

この考え方があれば、「権限を絞る」ことはゴールではなく、監督と記録を設計するための入口になります。

AIを安心して任せられるかどうかは、AIの能力だけで決まるものではありません。どの道具を渡し、どこまで許可し、何を記録し、どの場面で人が介入するのか。その仕組みを設計できるかどうかが重要です。

AI時代の新しい仕事は、AIの能力を競うことだけでなく、任せ方そのものを設計することなのかもしれません。

2026年10月1日追記：警告が出ても、実行後では止められていない

Salt Labsは2026年10月1日、AIエージェント「Manus」を対象にしたセキュリティ研究を公表しました。研究者が用意した悪意あるメールをManusに読ませると、メール本文に隠された命令をエージェントが実行し、エージェント環境内でコード実行とリバースシェルの確立に成功したと報告しています。そこから、接続済みサービスに関係する認証情報やトークンを確認できたとしています。

攻撃成立までに必要だった操作は、悪意あるメールが受信箱へ届くことと、利用者がManusへ「メールを確認して」と依頼することの2点でした。パスワード窃取、リンクのクリック、その後の利用者操作は不要だったという説明です。

特に重要なのは、Manusが危険をまったく検知できなかったわけではない点です。最初の露骨な命令は検知しましたが、難読化した命令は解読・実行され、警告が出たのはコードがすでに動いた後でした。つまり、検知はしたが、外部作用の前には止められなかったということです。

Salt Labsは、問題は修正され、その後は再現できなかったと説明しています。ただし、今回直接確認できたのはSalt Security自身の研究発表です。ManusまたはMetaによる公開技術報告、独立研究者による再現、MORI環境での実行検証は確認できていません。

MORIの複数AI運用へ置き換えると、「怪しい命令を見つける」だけでなく、読み取りとコード実行・送信・認証情報利用を別権限にし、警告を外部作用の直前に同期的に止める必要があります。Evidenceも「検知した件数」ではなく、「危険な作用の前に止めた件数」で見るべきです。

追記のまとめ：エージェント安全性は、警告を出せたかではなく、危険な作用が起きる前に権限を止められたかで測る。

出典：Salt Security / Salt Labs発表（2026年10月1日）

https://www.prnewswire.com/news-releases/salt-labs-research-a-single-email-could-hijack-an-ai-agent-and-reach-a-users-connected-accounts-302895317.html

---

#AIエージェント #n8n #生成AI #業務効率化 #AI活用