進め方の全体像
AIエージェントの開発は、動くものを見せるところまでは短期間で到達します。届かなくなるのはその先で、検証したものが本番に乗らないまま終わる案件が少なくありません。原因は精度不足よりも、決める順序が入れ替わっていることが多いです。承認の経路や止める条件を決めないまま実装から入ると、動いたものを使い続けられません。
工程は4つに分かれ、そのあとに本番へ乗せるかどうかの判定が入ります。どの工程にも、作るものより先に決めておくことがあります。決めないまま次へ進むと、後の工程から前の工程へ戻ることになります。
工程ごとに、次へ進む前に決めること
図の1の手前に、そもそもどの業務を対象にするかの選定があります。ここを飛ばして始めた検証は、実装よりも手順を決める作業に時間がかかり、期間内に形になりません。
| 工程 | 次へ進む前に決めること | 決めずに進んだときに起きること |
|---|---|---|
| 0. 対象業務の選定 | 手順が決まっているか、判断が入るか、月あたりの件数 | 手順を決める作業で期間を使い切り、検証が形にならない |
| 1. 業務の整理と要件の確定 | 扱う範囲と対象外のケース、入力と出力の形、承認経路、合格ライン | 実装の途中で「この場合はどうするか」が出て、範囲が動き続ける |
| 2. エージェント本体の実装 | 固定の処理として書く範囲と、モデルに任せる範囲 | 想定と違う動きをしたときに原因を追えない |
| 3. 既存システムとの接続 | 認証の方式、データの形式と頻度、書き込みの権限、テスト環境の有無 | 他の工程が終わっても接続の調整待ちで止まる |
| 4. 検証と調整 | 誤りの種類ごとの許容度、例外を人へ回す経路、止まったときの通知 | 正解率だけを見て、そのまま通ってしまう誤りを見落とす |
| 本番運用 | 人が承認する箇所、精度を見る間隔、直し続ける担当 | 業務の変化に追従できず、数か月で使われなくなる |
0から2までは社内の判断で決められますが、3の接続条件と4の合格ラインは、接続先を管理している部署や業務側の承認が要ります。日程を引くときはこの2つの確認を先に始めておくと、実装が終わったのに本番へ進めない状態を避けられます。すでに止まっている検証の切り分けは 生成AIのPoCが進まない で扱っています。
対象業務をどう選ぶか
最初の1本は、業務の名前ではなく性質で選びます。見るのは、手順が決まっているか、判断が入るか、件数がどれくらいあるかの3点です。
| 業務の性質 | エージェント化の向き | 着手前にやること |
|---|---|---|
| 手順が決まっていて、月あたりの件数が多い | 向く | 例外がどの割合で出るかを数える |
| 判断は入るが、判断基準が文書になっている | 一次処理までなら向く | 人が最終判断を持つ箇所を決める |
| 判断基準が担当者ごとに違う | 基準を揃えるまで待つ | 過去の処理結果を集めて基準を言葉にする |
| 件数が少なく、その都度の交渉で決まる | 向かない | 対象から外す |
件数の多い業務を先に選ぶのは、削減できる量が大きいからだけではありません。件数が多いほど検証に使える事例が集まり、合格かどうかを数字で判定できます。月に数件しかない業務は、本番へ進めてよいかを決める材料が足りません。
手順が決まっていて件数が多い業務には、書式がばらつく書類の読み取りや、メールから必要な項目を抜き出して管理表へ反映する処理があります。個別の設計は 発行元ごとに書式が違う請求書をAIで取り込む と 受発注業務をAIで自動化する にまとめています。
判断が入る業務でも、判断基準が文書になっていれば一次処理までは任せられます。この場合は結果をそのまま確定させず、人が最終判断を持つ形にします。どこまでを任せてどこから人が持つかの線引きは 契約書レビューをAIで と 書類選考をAIで自動化する で扱っています。
社内の資料を参照して答える業務は、その資料が検索できる形で残っているかが前提になります。残っていない場合は、資料を集める作業が開発の前に入ります。構成の例は 社内問い合わせ対応をAIで自動化する を参照してください。
各工程で何をするか
1. 業務の整理と要件の確定
決めるのは、扱う範囲と扱わない範囲、入力と出力の形、承認経路、そして合格ラインです。出てくるものは、手順を書き下したものと、対象外にするケースの一覧になります。
ここで例外をすべて拾おうとすると終わりません。発生件数の多い順にケースを並べ、上位のいくつで全体の何割を占めるかを見て、そこまでを対象にします。残りは人へ回す経路を作っておけば足ります。
書き出したものを、要件定義書のどの欄にどう書けば実装へ渡せるかは AIエージェントの要件定義の書き方 に項目ごとの記入例があります。この記事では、この工程を飛ばさないことだけ押さえておけば足ります。
2. エージェント本体の実装
処理をどう分けるか、指示と参照情報をどう渡すか、どこまでを固定の処理として書き、どこをモデルに任せるかを決めます。
規則で書ける判定は規則で書きます。モデルへ渡す範囲を絞るほど結果が安定し、想定と違う動きをしたときに原因を追えます。社内のデータを参照させる方法は RAGとファインチューニングの違い、書類の読み取り方式は AI-OCRと生成AIの違い で比較しています。既製のツールで足りる範囲を作らないための判断は AIエージェントは自作か既製ツールか にあります。
3. 既存システムとの接続
確認するのは、認証の方式、取得できるデータの形式と頻度、書き込みの権限、そしてテスト環境があるかです。
先に押さえておくのは、接続先を管理している部署と、テスト用のデータを触れるかどうかです。ここが遅れると他の工程が進んでいても止まります。外部から呼び出す口が用意されていないシステムでは、画面の操作で代替するか、ファイルの受け渡しにするかを決めます。どちらも動きますが、後者のほうが壊れにくく、反映までの間隔は長くなります。
4. 検証と調整
実際のデータで通し、合格ラインに届くかを見ます。見るのは正解率だけではありません。間違え方を分けます。
人が見ればすぐ分かる間違いと、そのまま通ってしまう間違いでは、必要な対策が違います。前者は人の確認で拾えますが、後者は確認をすり抜けます。後者が出る箇所には、値の突き合わせや上限のチェックのように、機械で止める仕組みを入れます。例外の扱いと、止まったときの通知もこの工程で入れます。
検証から本番へ進めるための条件
検証に入る前に、次を決めておきます。
本番に乗せる基準を先に置く。 精度が何割なら合格か、何が起きたら止めるか。基準がないと、検証結果を見ても判断できません。合格ラインの置き方と、誤りの種類ごとの許容度の決め方は AIエージェントの精度をどう評価するか にまとめています。
人が承認する箇所を決める。 AIが作ったものをそのまま外に出す箇所と、人が確認する箇所を分けます。対外文書や金額を扱う処理は、人の承認を残すほうが安全です。
失敗したときの動きを決める。 エラーで止めるのか、人に回すのか。止まったことに気づく仕組みも必要です。動いているつもりで止まっている状態が、いちばん厄介です。
運用の担当を決める。 業務が変われば直し続けます。誰が直すのかが決まっていないと、数か月で使われなくなります。
費用がどの工程に乗るか
見積の中身は、工程と同じ4つに分かれます。金額を比べる前に、どの区分がどこまで含まれているかを見ます。
| 見積の区分 | 主な作業 | 見るところ |
|---|---|---|
| 1. 業務の整理と要件の確定 | 手順の言語化、対象範囲の確定、承認経路の決定 | ここが薄い見積は、着手後に増える |
| 2. エージェント本体の実装 | 処理の実装、指示と参照情報の設計 | 流用できる資産があるかで期間が変わる |
| 3. 既存システムとの接続 | 認証、データ形式の変換、権限の設計 | 調査の工数が入っているか |
| 4. 運用に乗せる検証と調整 | 基準の判定、例外処理、止まったときの通知 | 検証で終わらせない条件が入っているか |
実務では2よりも1と3に時間がかかります。業務の手順が言葉になっていないと実装できず、既存システム側の制約は着手後に出てくるためです。見積を比べるときは、1と3をどこまで含んだ金額かを確認したほうが実態に近づきます。
期間を短くする方法は、実装量を減らすことです。実績のあるコンポーネントを組み込み、その企業に固有の部分だけを個別に作る形にすると、ゼロから書くより早く、共通部分の不具合も持ち込みにくくなります。委託先を選ぶときは、流用できる資産を持っているかを見ておくとよいでしょう。
開発費とは別に、モデルの実行費用、動いているかを見る監視と障害対応、業務が変わったときの修正が運用開始後に続きます。実行費用は処理する件数と1件あたりに渡す情報量で決まるため、検証の段階で1件あたりを実測しておくと、対象範囲を広げたときの金額を事前に確認できます。金額を動かす要素、初期と月額の内訳、契約後に増えやすい項目は AIエージェント開発の費用の決まり方 に分けてあります。
社内のナレッジをどう引き継ぐか
エージェントの精度は、モデルの性能よりも、その会社の情報をどれだけ渡せているかで決まります。判断の根拠が社内にしかない業務では特にそうです。
やることは2つあります。散らばっている資料を検索できる形に集めること。そして、使いながら判断の履歴を蓄積して、次の判断に効かせることです。後者を最初から設計に入れておくと、使うほど精度が上がる状態になります。逆に入れていないと、いつまでも同じ間違いを繰り返します。
暗黙知の扱いは、ドキュメントを整備してから開発する、という順序にこだわらないほうが進みます。実際に動かしてみて、間違えた箇所を見ながら足すほうが早いです。
機密情報を扱う場合
データを外部に出せない要件がある場合、構成で対応します。閉じたネットワーク内に構築する、通信経路を限定する、ログに機微な情報を残さない、といった設計です。
クラウドはGCP、AWS、Azureのいずれでも構築できます。選定基準は、すでに使っている基盤に寄せることです。新しい基盤を増やすと、運用と権限管理の負担が増えます。
権限の設計も先に決めます。読み取りだけで足りる処理に書き込み権限を渡さない、長期の鍵を発行せずに済む方式を選ぶ、といった判断です。動かしてから直すのは手間がかかります。
本番に乗せた後に続く作業
本番へ移した時点で終わりにはなりません。続くのは次の4つです。
- 精度の推移を見る。同じ処理でも、入ってくるデータが変われば結果は変わります
- 人が直した箇所を記録する。直した内容が次の判断に効く形にしておきます
- 業務や接続先の仕様が変わったときに直す
- 使われているかを見る。使われなくなった機能は外し、対象を絞ります
決めておくのは、見る間隔と担当です。月次で数字を確認する、四半期で対象範囲を見直す、といった間隔を運用開始のときに決めておくと、放置されにくくなります。担当が決まっていない状態で「気づいた人が直す」にすると、数か月で誰も見なくなります。
外部に任せるか、社内で作るか
判断の軸は、その業務の仕様が社内にしかないかどうかです。仕様が現場にしかなく、作った後も直し続ける業務は、社内で作れるようにしたほうが早くなります。基盤の構築、既存システムとの複雑な接続、セキュリティ要件の厳しい構成は、頻度が低く専門性が要るため外部に任せる価値があります。基盤と難所を外部が作り、日々の改善は社内が回す形も取れます。
工程ごとに費用がどこへ出るかは AI開発は外注か内製か、社内で回せるようにする順序は AI内製化の進め方、委託先の提案と見積で確かめる項目は AIエージェント開発会社の選び方 にまとめています。全社の業務プロセスから組み替える場合は 企業のAIネイティブ化の進め方 を参照してください。
依頼前に用意しておくもの
- 対象業務の手順（粗くてかまいません）
- 扱うデータの種類と、外に出せない範囲
- 既存システムの一覧と、接続できる形式
- 誰が承認するか
- 運用を担当する人
これが揃っていると、要件確定にかかる期間が縮みます。揃っていなくても、整理そのものを委託先と進める形は取れます。
まとめ：本番運用まで届かせる6つの要点
- 最初の1本は業務の名前ではなく性質で選ぶ。手順が決まっていて件数が多いものから始める
- 工程ごとに、次へ進む前に決めることを埋める。決めずに進むと後の工程から戻ることになる
- 接続の条件と合格ラインは他部署の確認が入る。日程の前半で始めておく
- 例外は全部拾わない。件数の多い順に対象を切り、残りは人へ回す経路を作る
- 見積は実装費だけを見ない。要件確定と既存システムとの接続に時間がかかる
- 判断の履歴を残す設計と権限の扱いは、動かしてから直すのではなく先に決める
Augueでは、AIエージェントの開発やAI駆動のWEBアプリケーションの開発まで幅広く開発実績がございます。実績のあるコンポーネントを組み合わせることでよりスピーディな立ち上げが可能ですので、ご興味がある方は是非ご相談ください。
関連する記事
費用の決まり方は AIエージェント開発の費用の決まり方、要件の書き方は AIエージェントの要件定義の書き方、社内で作れるようにする進め方は AI内製化の進め方 を参照してください。
よくある質問
検証で終わらせないために、最初に決めることは何ですか？
本番に乗せる基準と止める条件、人が承認する箇所、失敗したときの動き、運用を直す担当の4つです。この4つが決まっていない検証は、動くものが出てきても判断材料になりません。とくに止まったことに気づく仕組みが無い構成は、動いているつもりで止まります。
全体でどれくらいの期間を見ておけばよいですか？
一律の期間は出せません。決まるのは対象業務の分岐の数、つなぐシステムの数、そして検証用データを用意できる時期です。日程を引くときは、接続先の管理部署への確認と、合格ラインの合意という他部署が絡む2つを先に始めます。この2つが遅れると、実装が終わっていても本番へ進めません。
見積を比べるとき、どこを確認すればよいですか？
業務の整理と要件の確定、既存システムとの接続を、どこまで含んだ金額かを確認します。実務ではエージェント本体の実装よりこの2つに時間がかかります。実装費だけが安い見積は、後から要件確定と接続の追加が乗ることがあります。
開発を委託する場合、社内からは誰を出せばよいですか？
対象業務を実際に処理している担当者、接続先のシステムを管理している人、そして範囲と合格ラインを決められる責任者の3者です。専任である必要はありませんが、業務の担当者が打ち合わせに出られないと手順の確認が伝聞になり、要件の確定が長引きます。
機密情報を扱う場合、クラウドはどれを選べばよいですか？
すでに使っている基盤に寄せます。GCP、AWS、Azureのいずれでも構築できるため、選定の基準は運用と権限管理の負担です。新しい基盤を増やすと、その分だけ管理する対象が増えます。読み取りだけで足りる処理に書き込み権限を渡さない、といった権限の設計も先に決めます。
社内のドキュメントを整備してから開発すべきですか？
その順序にはこだわらないほうが進みます。実際に動かしてみて、間違えた箇所を見ながら足すほうが早いです。ただし、使いながら判断の履歴を蓄積して次の判断に効かせる設計は、最初から入れておきます。後から足す形にすると、同じ間違いを繰り返したままになります。