AIエージェント導入は何から始めるか — PoC止まりにしないための業務選定と設計

AIエージェント——指示への応答ではなく、目標を与えると複数ステップの業務を自律的に遂行するAI——の導入が、2026年に入って本格化しています。一方で、Forresterの予測では2026年時点でエージェント機能を本格的に本番運用している企業は15%未満とされており、実態は「試している企業は多いが、業務として定着させた企業は少ない」段階です。

つまり、いま導入を検討している企業が学ぶべきは「どう作るか」より「なぜ85%はPoCで止まるのか」です。当社が開発・導入の現場で見てきた範囲では、止まる原因は技術ではなく、最初の業務選定と権限設計にあります。この記事はその2点を中心に、導入の手順を整理します。

最初の業務をどう選ぶか

エージェント導入の成否は、1つ目の業務選定でほぼ決まります。選定基準は次の4つです。

1. 手順が言語化できる業務であること。ベテランの暗黙知で回っている業務は、エージェント以前に手順の言語化という別プロジェクトが必要になります
2. 失敗のコストが低いこと。誤った結果が出ても、社内で気づいて直せる業務から始める。顧客に直接届く業務を1つ目に選ばない
3. 頻度が高いこと。月1回の業務を自動化しても検証が進みません。日次・週次で回る業務は、改善サイクルも同じ速度で回せます
4. 成果が数えられること。処理件数、処理時間、エラー率。数字で語れない業務は、後述する「継続判断」ができなくなります

典型的な合格例は、問い合わせメールの一次分類と回答案の下書き、定例レポートのデータ収集と初稿作成、社内ナレッジの検索・要約あたりです。逆に、経営判断を伴う業務や例外処理が本体のような業務は、最初の1つには不適です。

権限設計：エージェントに「どこまでやらせるか」

PoCが本番に進めない最大の理由がここです。デモでは全自動で動かせても、本番では「エージェントが勝手に顧客へメールを送る」ことを許容できる企業はほとんどありません。かといって全ステップに人の承認を挟むと、自動化の意味がなくなります。

実務的な設計は、業務のステップを「読む・書く・送る」に分解し、段階ごとに権限を分けることです。

導入初期は「送る」をすべて人が握り、エージェントの精度が実測で確認できた領域から段階的に自律範囲を広げる。この「権限の段階的な拡張」を最初から計画に含めておくと、PoCと本番の間の断絶がなくなります。PoCで全自動を見せてしまい、本番要件で承認フローを後付けする順序が、頓挫の典型パターンです。

評価の仕組みを先に作る

エージェントは同じ入力でも毎回同じ出力を返すとは限りません。この性質のため、「なんとなく良さそう」のまま運用に入ると、精度が下がったときに気づけません。

導入時に、評価用のテストケースを作ってください。過去の実データから代表的な入力を30〜50件選び、期待する出力を人が定義したものです。エージェントの設定やモデルを変更するたびにこのテストを流し、合格率を記録する。ソフトウェア開発のテストと同じ発想ですが、AI導入の現場ではこれが省略されがちで、省略した組織は数か月後に「最近精度が落ちた気がする」という感覚論に陥ります。

あわせて、本番運用では全処理のログ（入力・出力・人が修正したか）を残します。人の修正率は、自律範囲を広げてよいかの判断材料に直結する、最も重要な運用指標です。

コストの見積もり方

導入判断の材料として、コスト構造にも触れておきます。エージェントのコストは、構築の初期費用のほかに、動くたびにかかるAPI利用料（推論コスト）が発生します。見落とされやすいのは後者で、処理1件あたりのコストは扱う文書量とモデルの単価で決まり、業務の件数に比例して増えます。

PoCの段階で「1件あたりの推論コスト×月間処理件数」を実測し、削減される人件費と並べてください。この計算をすると、実は月100件程度の業務では自動化の経済合理性が薄い、といった判断が導入前にできます。逆に日次で数百件回る業務なら、多少精度が粗くても一次処理をエージェントに任せる価値が数字で示せます。感覚ではなく単価で語れることが、エージェント導入の稟議を通す一番の近道です。

「担当者が辞めたら止まる」を防ぐ

もう1つ、日本企業の導入現場で頻発する問題に触れておきます。エージェントの構築を1人の熱心な担当者が担い、その人の異動・退職とともにメンテナンス不能になるケースです。

エージェントはプロンプト・接続先システム・権限設定・評価データの集合体で、これらは業務の変化に合わせて更新され続ける必要があります。属人化を防ぐには、少なくとも「エージェントが何をしているかの業務仕様書」と「評価テストの実行手順」を、構築した本人以外が読める状態で残すことです。ここは従来のシステム開発のドキュメント規律がそのまま有効な領域で、AIだから特別ということはありません。

残り85%の企業には、先行事例の失敗から学べるという後発の利があります。技術選定の前に、業務選定・権限設計・評価の3点を紙の上で決める。派手さはありませんが、定着した導入は例外なくここを通っています。