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