AIエージェント導入の進め方：対象業務の選定から効果測定までの手順

AIエージェント導入の進め方は、ツールを比べる前に4つの段階を決めることである。対象業務と、エージェントが参照する「正となる記録」を1つ決める。人がいまその業務をこなしている成績を測る。権限と承認の初期値を決める。短い試行の後に、広げるか止めるかを判定する。この順番を飛ばしてツールを入れると、エージェントは動くが、うまくいっているのかどうかを誰も言えない状態になる。

「AIエージェント 導入」で検索すると、上位には「要件定義 → ユースケース選定 → ツール選定 → 構築・検証 → 本番運用」という手順の解説と、製品の比較記事が並ぶ。手順の骨格としては正しい。だが、要件定義の中身が「任せる業務と参照するデータの範囲を決める」で止まっていて、どの記録を正とするか、導入前に何を測っておくか、権限の初期値をどちらに倒すかまでは書かれていない。事業責任者が導入の進め方を決めるときに必要なのは、この3つである。本稿は、AIエージェントを実際に業務へ入れて運用している海外の現場の元記事を起点に、4つの段階で何を決めるかを整理する。

AIエージェント導入は何から始めるのか ― 対象業務と「正となる記録」の指定

最初に決めるのは、対象業務と、その業務でエージェントが参照する正となる記録である。ツール選びはその後でよい。

理由は、エージェントの失敗の多くが「古い記録を正しいと思い込む」形で起きるからだ。Everyは、Slackに常駐する全社共有のエージェント「Every Agent」を社内で使っている。入社1週目の記者Grant Harveyが、編集長から求められた資料の在り処をこのエージェントに尋ねると、1分もかからずに資料へのリンクを示し、9人の執筆者を挙げ、1人が直前に変更履歴を残さず記載を変えたことを警告し、公開前にWebページが公開状態になっているか確認するよう促した。ところが同じエージェントは、ある社員の8月の休暇申請を、数か月前に承認・記録済みだったにもかかわらず「承認待ち」と答えている。共有の管理表ではなく、古い記録を信じたためである。Harveyは、エージェントは間違っているときも確信の度合いが変わらないと書いている（AIコワーカーに何を任せるべきか、Every社の導入1週目が示す振り分けルール）。

ここから導入の最初の段階でやることは2つに絞れる。

1. 対象業務を1つ決める。 候補は、チームの文脈を探す手間が大きい業務である。Harveyが1週間で至った振り分けは、チームに関わること（先月共有された資料を探す、自分が入っていないスレッドを追う、共有の記録と事実を照らす）はエージェントに、1人で腰を据えて考える作業はClaudeのようなチャット型のAIに、誰かが責任を持つべき判断は人に、というものだった
2. その業務の正となる記録を1つ指定する。 休暇の承認状況なら共有の管理表、契約条件なら契約管理の台帳、と決める。記録が2つ以上あって新旧が混ざっている業務は、エージェントを入れる前に記録をそろえる。誤答が起きたときに、どの記録を直せばよいかが分からなくなるからである

Everyの社内には、エージェントが自分のバグを報告するチャンネルがあり、休暇申請の誤答もそこに上がった。誤りを拾う場所を最初から用意している点も、この段階で決めておくべきことに含まれる。

対象業務の選び方そのもの、つまり仕事の起点と記録が同じシステムにそろっている業務から選ぶという判定の仕方は、業務自動化を成り立たせる5つの要素と、最初の1業務の選び方で3つの問いに分けて扱っている。

導入前に何を測っておくのか ― 人の作業の基準線

2つ目の段階は、エージェントに試させる前に、人がいまその業務をどうこなしているかを測ることである。これを飛ばすと、試行の後に残るのは「便利になった気がする」という感想だけになる。

Microsoftは新しいCopilotの発表会で、顧客がエージェントをどう評価すべきかに多くの時間を割いた。CEOのSatya Nadellaは、その会社の人が実際にしている仕事にもとづくテスト、つまり「自分の会社に固有の評価（evals specific to your company）」を求めている。元記事の筆者で、Everyに寄稿したデータサイエンティストのRyan Sloanは、これについて次のように書いている。

“A general benchmark cannot tell an organization whether an agent improves one of its own processes.”

訳: 汎用のベンチマークでは、エージェントがその組織のある業務を改善するかどうかは分からない。（Ryan Sloan, Every, 2026-09-25）

では、その評価で何を比べるのか。MicrosoftでCopilotとエージェントを統括するCharles Lamannaは、Sloanの取材に対し、エージェントの評価で成功している顧客の共通点を3つ挙げている。その仕事を毎日担当している人自身に評価のテストを作らせる。失敗するテストを恐れず受け入れ、通ったらより難しいテストを書く。そして、エージェントに試させる前に、エラー率や契約書を出すまでにかかる時間といった人の現状の成果を測り、エージェントが超えるべき実際の基準線にする（AIエージェントを組織図に載せる時代、Copilot Autopilotが示すガバナンスの条件）。同氏によれば、Microsoftは社内で約16,000件の評価を運用している。

自分の組織に置き換えると、基準線として測るものは多くない。対象業務1件あたりの処理時間、差し戻しや誤りの件数、担当者が他部署に問い合わせた回数の3つ程度でよい。大事なのは、これを担当者の自己申告ではなく、チケットや承認ログのような記録から取ることである。導入後に同じ記録から同じ数字を取れば、比較が成り立つ。

基準線を誰がどの記録から出すかで、その数字が経営会議に耐えるかどうかが決まる。この切り分けは、自己申告の時短を経営会議に出さないKPIの設計で詳しく扱っている。

権限と承認の初期値はどう決めるのか

3つ目の段階は、エージェントに何を承認なしでやらせ、何を人の承認必須にするかの線を引くことである。ここで決めるのは個々の権限の一覧ではなく、線を引く基準と、迷ったときの初期値である。

Everyが全社共有のエージェントで採った基準は、操作ごとに「元に戻すのがどれだけ難しいか」を問うものだった。同社のプラットフォーム責任者Willie Williamsによれば、これはエンジニアのWill Gathrightが提案した問いで、元に戻しやすい操作なら、エージェントは妥当な判断で作業を進め、何を前提にしたかを報告する。削除や別チャンネルへの投稿のように取り消しにくい操作や会話の外に見える操作は、先に尋ねる。そのうえで、誰が何をしてよいかのルールはモデルが読む指示文ではなく、モデルの下にあるコードに置いた。

“The rules about who can do what live in code, underneath the model, rather than in the instructions the model reads.”

訳: 誰が何をしてよいかのルールは、モデルが読む指示文ではなく、モデルの下にあるコードに置かれている。（Willie Williams, Every, 2026-10-20）

ただし、ルールを固定すると、間違ったときも確実に間違う。Everyが7月に全スキルを新しい権限の仕組みに移したとき、24個のスキルがすべて個人専有になり、チームで作ったスキルを同僚が編集できなくなった。ある社員は元のレポートを編集できず、毎日の成長指標のレポートを一から作り直している。約1週間後、エンジニアのLee Knowltonが9個のスキルの公開範囲を手で広げ、公開チャンネルで作られたものは全員が編集できるように初期値を変えた（個人用AIエージェントを全社共有にすると何が壊れるのか──Everyが権限をコードに固定した理由）。

初期値の倒し方には、逆向きの選択肢もある。Everyのコンサルティングチームは常時稼働のエージェント「Claudie」を作ったとき、何ができるかを最も早く知るために、あえて広いアクセス権を与え、全体像が見えてからリスクが利益を上回る権限を外していった（AIエージェントの権限設計は最小権限から始めるべきか — 常時稼働エージェント「Claudie」の運用に学ぶ）。

この2つの例を並べると、導入の段階で事業責任者が決めることは次の3点になる。

• 線を引く基準: 「元に戻せるか」「会話の外に見えるか」のような、操作ごとに当てはめられる問いを1つ決める
• 初期値: 新しく作られたものや移行したものを、まず公開に寄せるか専有に寄せるか。広く始めて絞るか、狭く始めて広げるか
• 初期値を見直す期限と担当: Everyは約1週間で直した。誰が何日後に見直すかを、導入計画に書いておく

権限を後回しにしたまま本番データに接続すると何が起きるか、また導入後の運用がどこで分かれるかは、権限設計・定着率・個人差という導入後の3つの分岐点で扱っている。

試行の後、何を見て広げるか止めるのか

4つ目の段階は、短い試行の後に判定することである。判定の材料は2つある。2つ目の段階で測った基準線との比較と、試行期間中にエージェントが黙って失敗していなかったかの記録である。

後者は見落とされやすい。Everyのチームは、同社のガイドが「OpenAIがChatGPTに組み込んだ常時稼働の個人用エージェント」と説明する「Dots」が、古くなった記事要約や、まだ出していない機能に触れた告知メールといったアプリ間の食い違いを指摘した例を挙げる一方で、無言の失敗、不安定な接続、タスクの取りこぼしにも遭っている。同社のガイドは、受信箱の仕分けや日程調整を任せるときに「私の承認なしに何も送らないこと。私が直した点は次回のために覚えておくこと」という明示的な制約を付けるよう勧めている（OpenAIの常時稼働エージェント「Dots」はなぜ放置運用できないのか──Everyの現場知見）。試行期間中は、エージェントの報告を待つのではなく、人が進捗を見に行く担当と頻度を決めておく必要がある。

もう1つの材料は、実際に使われ続けたかどうかである。Everyが社員1人ずつに持たせていた個人用エージェント「Plus One」は、運用の手間が大きかったうえに、試した人の多くが使わなくなった。一方で、最も役に立ったのは他人のエージェントを借りる場面だった。当時の成長部門の責任者が自分のエージェントを分析ツールにつないだところ、ほかのメンバーもそのエージェントに質問するようになった。Everyはこの観察をもとに、個人用のエージェントをやめて全社で1体を共有する形に作り直している。試行の判定では、配った人数ではなく、誰が誰のエージェントを使っていたかを見ると、次に広げる先が分かる。

判定の結果は、次の3つのどれかに振る。

• 広げる: 基準線を上回り、無言の失敗が人の確認で拾えている。対象業務を隣の業務へ広げる
• 作り直す: 使われてはいるが、誤りの原因が記録や権限の側にある。1つ目か3つ目の段階に戻る
• 止める: 基準線を下回る、または使われていない。止めた理由を記録して、次の対象業務の選定に使う

使われなくなったツールを理由ごとに分けて、維持・再設計・保留・撤退の処遇を誰が決めるかは、使われなくなったAIツールを4択で判定する仕組みで詳しく扱っている。

まとめ: ツールを選ぶ前に、比べる物差しを用意する

AIエージェント導入の進め方を4段階に分けると、ツールの選定は1つ目と2つ目の段階の後に来る。正となる記録が決まっていなければ、どの製品を入れても古い記録を答える。人の作業の基準線がなければ、どの製品が良かったかを比べられない。

最初の対象業務について、次の3つを導入計画の1ページ目に書くところから始めるとよい。どの記録を正とし、誰がそれを保守するか。導入前の処理時間と誤りの件数を、誰がどの記録から出すか。承認なしで実行してよい操作の線をどこに引き、その初期値を何日後に誰が見直すか。この3つが書けていれば、ツールの比較は条件を当てはめる作業になる。