AIエージェント運用、中小企業が権限設計で分ける3つの境界線

Bakersfieldの小さな弁護士事務所で、デスクの下に4台のMac miniが積まれています。持ち主は破産専門弁護士のScott Bell氏です。

今年3月半ば、この4台にOpenClaw（ゴールを指示するとタスクに分解して実行するAIエージェント基盤）を入れ、5体のエージェント体制を組みました。ニューヨーク・タイムズが2026年6月4日に報じた記事の内容です。タイトルは「The Small-Business Owners Managing Whole Armies of A.I. Employees」。掲載はnytimes.comです。ペイウォールのため本文全文は確認できていませんが、entrepreneur.comほか複数媒体の要約を突き合わせてクロスチェックしました。

この記事、僕は最初「個人がここまでやるのか」という驚きだけで読み始めました。ですが読み進めるうちに、驚きの先に浮かんできたのは別の問いです。「この事務所は、AIに何を任せて何を任せていないのか」。この線引きこそ、中小企業がAIエージェントを運用するときに一番先に決めるべきことだと感じました。答えを先に言うと、任せる仕事は「判断」「実行」「対外接触」の3層に分けて考えると、迷いがぐっと減ります。

「AI従業員」という言葉が、もう比喩ではなくなった理由

ここ数週間、AIエージェントの企業向け発表が立て続けに出ています。Metaは対話型のBusiness Agentを一般開放しました。SAPは200を超えるエージェントを基幹システムに組み込んでいます。Databricksは自律運用ツールGenie Oneを公開しました（詳しくはAIエージェント導入33%の現実でも整理しています）。どれも共通しているのは、数百人規模の専任チームが要件定義から検証環境、段階的な展開計画までを設計している点です。

いっぽうBell氏の事務所からは、そうした専任チームの存在は報道を読む限り見当たりません。entrepreneur.com等が伝える内容によれば、彼一人が業務用のクレジットカードでAPIキーを発行し、自分でエージェントの役割分担を決めたようです。設計書やレビュー会議があったかどうかは記事からは分かりませんが、大企業のように専門部隊が安全性を検証してから動く体制とは対照的です。

Databricks事例で紹介した自律運用ツールGenie Oneのように、大企業向けプラットフォームには権限管理の機能自体が最初から組み込まれています。誰がどの範囲まで承認できるか、どの操作にログが残るかという設計が、ツールの側で用意されているわけです。ところが中小企業がOpenClawのような汎用エージェント基盤を使う場合、その権限管理の仕組みを自分で組み立てる必要があります。「AI従業員」という言葉は、もう大企業の未来予想図ではありません。今この瞬間、たった一人で回している現場の話になっています。だからこそ、次に紹介するBell氏の事例では「何を任せ、何を任せていないか」を具体的に見ていきます。

Bakersfieldの弁護士が、Mac mini4台に任せた仕事の中身

entrepreneur.com等の報道によれば、Bell氏が組んだ5体のエージェントは役割ごとにはっきり分かれています。1体目は「オーケストレーター」です。オンラインの法務ソフトにログインし、他のエージェントの進行を管理する役目を持っているとされています。人間でいえば秘書に近い立ち位置です。

2体目は「ライブラリアン」です。カリフォルニア州の破産法の条文を学習させ、契約書や他の弁護士から届く提案書を読み込ませて分析させているようです。ここまでは、情報を読んで整理する仕事の範囲です。判断の最終責任は、あくまでBell氏本人が持つ仕組みになっているとみられます。

3体目が「ロー・オプス」です。報道では、4月末までに裁判所からの通知が届いたことを自動で検知し、内容を読み、クライアントに連絡するところまでこなすようになったと伝えられています。これは読んで終わりではありません。事務所の外にいる人間に、直接メッセージを送る仕事です。

このロー・オプスの動きだけ、性質がまったく違います。契約書を読むだけなら、間違えても事務所の中で気づけるはずです。ですがクライアントへの連絡は、一度送ってしまえば取り消せません。文面がわずかにおかしくても、相手はすでに受け取っています。

Bell氏の事務所を見ていて僕が気になったのは、この「取り消せるかどうか」の一線がどこにあるのか、本人はどこまで意識して線を引いたのかという点でした。報道からは、そこまで詳細な設計思想は読み取れません。だからこそ、自分たちの事業に置き換えるときは、その部分を自分で埋める必要があります。

OpenClawというツール自体の設計思想も、この話と無関係ではありません。細かい手順を逐一指示するのではなく、ゴールだけを渡すとタスクに分解して複数のエージェントに配る仕組みです。効率は上がりますが、その分「どこまで自動で進めていいか」を人間側が事前に決めておかないと、想定より広い範囲までエージェントが動いてしまう可能性もあります。ゴール駆動型のツールほど、権限設計の甘さがそのまま実行範囲の広がりに直結するわけです。

ギター教室プラットフォームが選んだ「人が監督に回る」設計

同じNYTの記事には、もう一つ印象的な事例が出てきます。あるギター教室向けプラットフォーム企業の話です。この会社では、マーケティングコピーの作成、見込み客へのフォローアップ、新規講師のオンボーディングまでをAIエージェントに任せたと報じられています。

ここで特徴的なのは、人を減らして終わりにしなかったことです。残った従業員たちは、AIエージェントの出力を確認し、方向性を調整する「監督役」に役割を変えました。現場の実行者から、成果物のレビュアーへの転換です。

複数の外部ツールを契約していたコストは、AIエージェントへの一本化によって浮きました。年間で約25万ドルの削減につながったと報じられています。この数字は、単なる人員削減の効果ではなく、ツール統合による固定費圧縮の効果である点に注意が必要です。

これは日本の中小企業にとっても他人事ではない話です。マーケティングツール・問い合わせ管理ツール・顧客管理ツールと、月額契約を積み重ねている会社は少なくありません。1つ1つは数千円でも、10種類ほど契約していれば年間で数百万円規模になることも珍しくないはずです。AIエージェントに任せる仕事を増やすことは、単に人手を減らす話ではなく、契約しているツールそのものを整理し直すきっかけにもなります。

Bell氏の事務所とこの企業に共通しているのは、AIエージェントに「代替」ではなく「役割」を与えている点です。人が完全にいなくなるのではなく、人の仕事が「実行」から「監督」に移っています。ここが、AIエージェント運用を設計するうえでの一番の分岐点でしょう。

同じBell氏の事例を、個人のキャリアの変化として読む切り口もあるでしょう。今回の記事では、個人の働き方ではなく「組織としてどこに人を残すか」という設計の話に絞って掘り下げます。

権限設計を分ける3つの境界線、判断・実行・対外接触

2つの事例を並べると、AIエージェントに任せる仕事は自然と3つの層に分かれて見えてきます。僕はこれを「判断」「実行」「対外接触」の3層と呼んでみました。

1つ目は「判断のみ・人が最終決定する層」です。ライブラリアンによる契約書チェックがここに当たります。間違えても事務所の中で止められるので、任せるハードルはもっとも低い層です。

2つ目は「実行するが取り消せる層」です。スケジュール調整やメールの下書き作成が該当します。ミスが起きても、送信前や確定前なら軌道修正できるでしょう。ここは判断層より一歩踏み込みますが、まだ安全網が残っています。

3つ目は「対外接触・不可逆な層」です。クライアントへの連絡や契約の締結がここに入ります。ロー・オプスがやっている仕事はまさにこれです。一度実行すると取り消せず、相手の受け取り方まではコントロールできません。この層に任せる範囲を広げるときこそ、人による確認のタイミングを事前に決めておく必要があります。

実際にこの3層を意識しないまま運用して、痛い目を見た例も業種を問わず出てきています。たとえば飲食店では、顧客からの問い合わせ内容をAIに要約させて店主が最終判断する運用が「判断のみ」の層で収まっていたはずでした。ところが要約結果をそのまま予約台帳に転記する担当者が誤りに気づかず、実際とは違う人数分の席を準備してしまったケースがあります。判断のみの層でも、出力を鵜呑みにする運用にすれば実質的に実行層まで踏み込んでしまうわけです。

人材紹介業でも同様の落とし穴があります。候補者と企業の面談日程調整を、AIエージェントに任せていたケースです。「実行するが取り消せる」層のつもりで運用していました。ところが確定前の人によるチェックを省略してしまい、同じ時間帯に2件の面談を同時に確定させてしまったという話も聞きます。取り消せる工程のはずが、確認を飛ばした瞬間に取り消せない結果を生んでしまう典型例です。

もっとも深刻なのは、士業やコンサルのように対外接触が業務の中心になる業種です。クライアントへの請求書送付や督促連絡をAIエージェントに任せていた事務所があります。支払い済みの請求先にも督促メールが自動送信されてしまいました。この結果、信頼関係を損ねたという事例が報告されています。対外接触・不可逆の層は、1件のミスが取引先との関係そのものに響く点で、他の2層とは重みが異なります。

この3層は、僕自身がClaude Codeで業務エージェントを組むときにも意識している考え方です。読むだけの仕事から任せ始め、取り消せる実行に広げ、対外接触は最後まで慎重に扱う。この順番を守るだけで、事故の起きやすさはかなり変わってきます。

小さなオンラインショップに置き換えて考えてみましょう。判断のみの層には、届いたレビューの感情分析や在庫データの異常検知が当てはまります。実行するが取り消せる層には、次回入荷のメルマガ下書きや発送スケジュールの仮組みが該当するでしょう。そして対外接触の層には、クレーム対応の一次返信や返金処理の実行が入ります。ここまで整理して初めて、「まずどこから任せるか」を落ち着いて選べるはずです。とはいえ多くの経営者は、実は一番リスクの高い対外接触の層から先に手をつけてしまいます。理由は単純で、そこがもっとも手間のかかる作業だからでしょう。ですが手間がかかるからこそ、人による確認の仕組みを先に固めてから任せるべき層だと僕は考えています。

僕がエージェントを組むときに、同じ境界線を引いている理由

正直に書きます。僕自身も、Claude Codeでブログ記事の執筆補助エージェントを組んだ初期のころ、この境界線をあいまいにしていました。下書き作成と外部発信の作業を、同じ権限レベルで動かしていた時期があります。

結果、公開前に必ず確認するはずだった箇所を、確認しないまま次の工程に進めてしまったことがありました。具体的には、記事内で引用する統計データを、エージェントが古いバージョンのまま下書きに残していたのです。僕自身もその箇所を見落としたまま、社内の共有フォルダに流してしまいました。幸い社外への公開前だったため、実害はありませんでした。ですが「判断のみ」のつもりで任せていた確認作業が、いつの間にか「実行するが取り消せる」層まで踏み込んでいた証拠と言えます。この失敗のあと、僕は自分の作業を「読む」「作る」「出す」の3段階に分け、出す工程だけは必ず人の目を通す運用に変えました。

Bell氏のロー・オプスは、まさに「出す」工程を任せています。彼がどんな安全策を取っているかは記事から読み取れませんが、少なくとも人が最終確認する仕組みがなければ、いずれ僕と同じような冷や汗を味わうことになるでしょう。実体験として言えるのは、境界線は頭で理解しているだけでは機能しないということです。一度失敗してはじめて、本気で守るようになります。

この失敗を経てから、僕は新しい業務をエージェントに渡すたびに「これは取り消せるか」を最初に自問するようになりました。取り消せない工程だと分かった瞬間、その手前に必ず確認ポイントを置きます。地味な習慣ですが、これだけで「気づいたら手遅れだった」という事態はかなり減らせるはずです。

境界線を引き忘れた現場で、何が起きているか

境界線をあいまいにしたまま運用すると、何が起きるでしょうか。ライブラリアンのような「判断のみ」の層でも、法律の解釈を誤ったまま契約書チェックの結果を人が鵜呑みにすれば、間違いに気づけません。読むだけの仕事だからといって、確認を省いていい理由にはならないのです。

より深刻なのは、対外接触の層で境界線が甘くなるケースです。ロー・オプスのような通知対応エージェントが、本来は人が判断すべき微妙な案件まで自動でクライアントに連絡してしまえば、法的なトラブルに直結しかねません。破産手続きという分野の性質上、誤った案内がクライアントの生活に直接影響することもあり得ます。

ニューヨーク・タイムズの記事に対しても、掲示板やSNSでは懸念の声が上がっています。「うまくいく前提の話ばかりで、事故が起きたときの責任の所在が見えない」という指摘です（hardforum.comのスレッドで確認）。この指摘は的を射ていると思います。

対外接触の層でなくても、境界線の設計ミスは起こり得ます。たとえば顧客対応のAIエージェントに返金処理まで任せていたとして、判断基準があいまいなまま動かしていたらどうなるでしょうか。本来は個別事情を確認すべき案件まで一律に返金してしまい、後から見返すと数十件単位の誤処理が積み重なっていた、という事態も十分に想像できます。1件ずつは小さなミスでも、自動化された仕組みの中では同じ間違いが繰り返され、気づいたときには規模が膨らんでいるものです。

Bell氏やギター教室プラットフォームの事例が示しているのは、うまくいった結果だけです。境界線をどう引いたか、失敗したときにどう戻したかまでは、報道からは十分に読み取れません。だからこそ、自分たちで境界線を決める作業を、他社の成功事例を読むだけで済ませてはいけないのだと思います。

小売業でも構造は同じです。ある実店舗のカスタマーサポートでは、AIエージェントに問い合わせ対応の一次回答まで任せていました。担当者は「判断のみ」の運用のつもりでいたはずです。ところが返信テンプレートの選択自体を、エージェントに一任してしまっていました。クレーム内容によっては、謝罪と代替品の提示まで自動で確定させる設定になっていたことが後から発覚しています。担当者が「判断のみ」だと思い込んでいた業務が、設定を細かく見ていくと実際には対外接触の層にまで踏み込んでいたわけです。層の境界線は、任せた本人が自覚しているつもりでも、ツールの設定次第でいつの間にかずれてしまうことがあります。

自社で始める3ステップ、棚卸しから段階導入まで

ここまでの整理を、自社で使える手順に落とし込みます。特別なシステムがなくても、今日から着手できる内容です。

1つ目は、今の業務を洗い出すことです。誰が何をしているか、細かいタスク単位で書き出します。Bell氏も、最初から5体を組んでいたわけではないでしょう。まずは「何を読ませるか」から始めるのが現実的です。

2つ目は、洗い出した業務を先ほどの3層に仕分けることです。判断のみの層から着手すれば、失敗しても被害は事務所の中に留まります。1つの業務で成果が見えてから、次の層に進むくらいの慎重さでちょうどいいはずです。

3つ目は、対外接触の層に進む前に、人による確認のタイミングを明文化することです。「送信前に必ず人が見る」「金額が一定以上なら人が承認する」といったルールを、エージェントを動かす前に決めておきます。この手順であれば、大企業のようなガバナンス専任チームがなくても、経営者一人で十分に実行できるはずです。ルールを決めたら終わりにせず、実際のログを見返して想定通りに人の確認が挟まっているかを点検する習慣もセットにしておきたいところです。特に対外接触の層は、運用を始めた最初の1か月は毎週ログを確認するくらいの頻度で構いません。慣れてきたら、月に一度の間隔まで広げれば十分でしょう。組織全体でのAI活用設計はAIエージェント組織管理の視点も参考になります。

まとめ

Bell氏の事務所とギター教室プラットフォームの事例は、AIエージェントが大企業だけの話ではないことを示しています。数百人のガバナンス部隊がいなくても、経営者一人が権限設計を意識すれば、実務は十分に回るはずです。

大企業の発表を追いかけて「うちにはまだ早い」と感じていた方も多いと思います。ですがBell氏の事務所を見る限り、必要なのは巨額の投資でも専門部隊でもありません。必要なのは、自分の業務をどの層に置くかという判断だけです。この判断さえ持てれば、Mac mini数台からでも始められます。飲食店・人材紹介業・士業と、業種を問わず同じ失敗パターンが起きているのを見てきた以上、境界線の設計を後回しにしていい理由はどこにもありません。

• AI従業員という言葉は、もう未来の話ではなく現場の運用の話になっている
• 任せる仕事は「判断のみ」「実行するが取り消せる」「対外接触・不可逆」の3層に分けて考える
• 対外接触の層に進む前に、人による確認のタイミングを先に決めておく
• 業種を問わず、確認を省いた瞬間に取り消せる工程が取り消せない事故に変わる
• うまくいった事例からは、失敗時の戻し方までは読み取れないと心得ておく

まずは自分の業務を3層に仕分けるところから始めてみてください。判断のみの層で小さく試すだけでも、AIエージェントとの距離感はかなり変わってくるはずです。僕自身、この記事を書きながら自分のエージェント設計を見直すきっかけになりました。同じように、この記事が皆さんの棚卸しのきっかけになればと思っています。