デモは動きました。担当者の質問にエージェントが答え、社内の資料も引いてきて、役員も「これはいい」と言いました。
それから半年、本番稼働の話は進んでいません。止まっている理由を聞くと、たいてい「精度が足りないわけではないのだが」という前置きから始まります。 誰も反対していないのに前に進まない状態は、技術の問題ではなく、決まっていない項目が残っている状態です。
ここでは、デモの技術検証はできたものの、本番運用の条件が決まらず止まっている場面を想定します。精度不足、データ品質、予算など別の原因もあるため、以下の4項目だけで全案件を説明するものではありません。
精度の議論に入る前に止まる
規制の厳しい業界の企業がAIエージェントを導入するとき、必ず突き当たる選択があります。自社で構築するか、製品を導入するか、という分岐です。gihyo.jp の連載では、この判断の手前で社内のツールが断片化していく構造が指摘されています。
部門ごとに別々のツールが入り、それぞれが別の権限体系と別の履歴を持つ。この状態でエージェントを載せると、「どのデータを見せるか」の議論が部門の数だけ発生します。PoC が1部門で成功しても、2部門目で同じ議論を最初からやり直すことになります。
つまり、PoC で検証されているのは「エージェントが答えられるか」であって、「組織で運用できるか」ではありません。この2つを混同したまま発注すると、動くデモに費用を払って、そこで終わります。
発注前に決める4つのこと
要件定義の段階で埋めておくと、本番化の判断が具体的にできる項目が4つあります。
1. 「完了した」を何で測るか
エージェント自身の自己申告を成功率にしないでください。タスクを最後まで実行したかどうかと、実行の過程で余計なことをしなかったかどうかは別の指標です。
見積書の作成を任せたエージェントが、書類を作りきったうえで顧客に誤送信していた場合、タスクとしては完了しています。測るべきは「完了率」ではなく「副作用なしの完了率」です。
この定義は発注側が決めるものです。何をもって業務上の成功とするかは、実際にその業務を回している側にしか書けません。
2. どこまで自動で実行させ、どこで人が承認するか
エージェントに与える権限は、読むだけか、下書きまでか、実行までか、で分かれます。この線を引かないまま作ると、あとから権限を絞る改修が必要になり、それは作り直しに近い規模になります。
線を引くときの基準は、失敗したときに元に戻せるかどうかです。下書きの生成はやり直せます。メールの送信、在庫の引き当て、外部への支払いは戻せません。戻せない操作の手前に人の承認を置く、という形が出発点になります。
なお、エージェントに実行環境を与える場合、その環境がどこまでネットワークに出られるかも同時に決める必要があります。実行環境の分離と権限委譲の設計は、後付けが難しい部分です。
3. 評価に使うデータを誰が用意するか
ここが最も抜けやすい項目です。
エージェントが正しく動いているかを継続的に確認するには、想定される問い合わせや作業のパターンと、それに対する期待される結果の組が要ります。InfoQ で紹介されている実践例では、合成した利用者像を使って複数ターンの対話を模擬し、CI/CD のパイプラインに評価を組み込む方法が取られています。
この評価データは、開発側が想像で作ると業務の実態から外れます。過去の問い合わせ履歴や作業ログから、発注側が代表的なケースを出すのが最短です。 見積もりに「評価データの作成」という行がなく、発注側にも依頼が来ていない場合、その評価はどこかで省略されます。
4. 止めたときに業務が戻せるか
エージェントを止める判断は必ず来ます。精度の問題ではなく、外部サービスの障害や、料金体系の変更が理由になることもあります。
止めたときに、その業務を人手で回す手順が残っているか。エージェント導入と同時に既存の手順書を捨てると、止められなくなります。 止められない仕組みは、条件が悪くなっても使い続けるしかありません。
見積もりを読むときに探す行
上の4項目は、そのまま見積書の確認項目になります。
| 決めること | 見積書で探す行 |
|---|---|
| 完了の定義 | 受け入れ基準・テスト項目の記載 |
| 権限の境界 | 承認フロー・実行権限の設計 |
| 評価データ | 評価セットの作成、または発注側の作業として明記 |
| 切り戻し | 運用手順書・既存手順の維持 |
これらの行がなく、機能の一覧と工数だけが並んでいる見積もりは、PoC の見積もりであって本番システムの見積もりではありません。 どちらを頼んでいるのかを、発注側が明示する必要があります。
段階を分けて発注するのは合理的な進め方です。ただしその場合、1段階目の成果物に「2段階目の判断に必要な材料」が含まれているかを確認してください。デモだけが残ると、次の判断ができません。要件の書き方そのものについては、システム開発の依頼内容をどうまとめるかが参考になります。
つまずきやすいところ
PoC の成功条件を決めずに始めない。 「まずやってみましょう」で始めた検証は、終わったときに成功か失敗かを判定できません。判定できないので、次に進む判断も止める判断もできず、そのまま止まります。
運用のコストを初期費用と別に見積もる。 利用量に応じた費用、評価の更新、モデルやツールの入れ替え対応は、稼働してから発生し続けます。運用時のコストが想定を超える構造は、AI を組み込んだシステム全般に共通します。
部門横断の話を後回しにしない。 1部門で完結する範囲に絞って始めるのは正しい進め方ですが、2部門目で権限の議論が発生することは最初から分かっています。1部門目のうちに、権限の考え方だけは全社の形で決めておいてください。
次にやること
いま検討しているエージェントについて、「これができたら本番に進める」という条件を1文で書いてください。書けない場合、それがいま止まっている理由です。
書けたら、その条件を誰が測るのか、何のデータで測るのかを付け足してください。この3点が揃うと、本番化に向けた検証の担当と範囲を具体化できます。
業務要件からの範囲の切り分け、承認と自動実行の境界の設計、評価の仕組みを含めた開発については、グリームハブの開発・AI・自動化のご相談で承っています。業務の内容と現在の運用体制によって進め方が変わるため、範囲は個別にお見積りします。お問い合わせからご相談ください。
