2業務目が1業務目ほど速く進まないとき
最初の一業務を内製で動かしきると、次は速いはずだという見込みが立ちます。使う道具は決まっていて、承認の通し方も一度経験している。ところが実際に着手すると、要件を聞くところから始まり、判定の条件で揉め、接続先の権限でまた止まる。終わってみると1業務目と大きく変わらない日数がかかっていた、という進み方になりがちです。
原因は二つに分かれます。一つは、1業務目の成果物のうち、どこが業務に固有でどこが共通かを、作った本人以外が説明できない形になっていること。全体が「あの業務の仕組み」として一つの塊になっていると、2業務目では丸ごと作り直すか、丸ごと真似して当てはまらない部分に苦しむかのどちらかになります。
もう一つは、2業務目の対象が要望の強さで決まってしまうことです。どの業務から着手するかの基準は「生成AI内製化はどの業務から始めるか」で扱っていますが、2業務目には別の条件が加わります。1業務目で作った部分をどれだけ載せ替えられるか、という条件です。ここが合わない業務を選ぶと、2業務目は実質的にもう一度の1業務目になります。
1業務目の中身を、載せ替えるものと決め直すものに分ける
広げる前に、1業務目で出来上がったものを分解します。分ける軸は「業務が変わっても中身が変わらないか」の一点です。
| 1業務目で作ったもの | 2業務目での扱い | 決め直しが要る条件 |
|---|---|---|
| データの取り込み口(受け取り・読み取り・整形) | 載せ替える | 入ってくる形式や入手経路が変わるとき |
| 承認と差し戻しの入れ方 | 載せ替える | 承認者の数や順序が違うとき |
| 記録の残し方と精度の見方 | 載せ替える | 測る対象が業務で変わるとき(枠組みは残す) |
| 何を正しい出力とするかの判定基準 | 決め直す | 常に |
| 例外の出方と、止める条件 | 決め直す | 常に |
| つなぐ先のシステムと権限 | 業務による | 接続先が1業務目と違うとき |
| 手順書と担当者への説明 | 決め直す | 常に |
上の3行は、業務の内容と関係のない部分です。ファイルやメールで来たものを受け取って揃った形に直す、人が承認する画面を挟む、実行の履歴と結果を残す。この3つはどの業務でも同じ構造になるため、1業務目で作ったものを部品として切り出せば、2業務目は差し替えるだけで済みます。
下の4行は、業務そのものです。ここを1業務目から持ち込むと、動いているように見えて出力が業務の実態とずれます。判定の条件だけを入れ替えるつもりが、実は前提となる例外の出方が違っていた、という形で後から表面化します。
載せ替える部分を、2業務目の前に部品へ切り出す
1業務目が動いている状態では、この3つは業務の処理と混ざっていることがほとんどです。2業務目に入る前に、呼び出す側と中身を分けておきます。
データの取り込み口は、入ってきたものを決まった形に直すところまでを共通にします。形式ごとの読み取りは業務で変わりますが、受け取り方(共有フォルダを見る、メールの添付を拾う、システムから引き出す)と、読み取れなかったときに人へ渡す流れは変わりません。ここを共通にしておくと、2業務目では読み取りの部分だけを足すことになります。
承認と差し戻しの入れ方は、承認者が誰かを外から差し替えられる形にします。承認を挟む位置そのものは、出力が業務の外へ出る直前という点でどの業務でも共通です。どの工程を人が確定させるかの考え方は「AIエージェントにどこまで任せるか」にまとめています。
記録の残し方と精度の見方は、そろえる価値がいちばん大きい部分です。業務ごとに違う形で記録を残すと、2業務目以降は「うまくいっているのか」を業務ごとに別の方法で確かめることになり、点検の手間が業務の数だけ増えます。入力・出力・人が直したかどうか・処理にかかった時間の4つを同じ形で残しておけば、後から横に並べられます。合格ラインの決め方は「AIエージェントの精度をどう評価するか」で扱っています。
切り出しは、2業務目の着手と同時に進めないほうが進みます。同時にやると、業務の要件を詰めながら部品の設計も変えることになり、どちらの都合で変えたのかが分からなくなります。
決め直す部分は、1業務目の資料の形だけを借りる
判定の基準、例外の扱い、接続先は、業務ごとに中身が変わります。ただし、決めるときに埋める項目は同じです。1業務目で使った要件の記入欄をそのまま持ってきて、中身だけを空にして埋め直します。項目の立て方は「AIエージェントの要件定義」に例があります。
判定の基準は、2業務目で最も時間を使うところです。1業務目の経験があると「今回も同じくらいで決まる」と見込みがちですが、業務が違えば正解の決まり方も違います。過去の処理結果を何件か持ってきて、担当者が同じ判断に至るかを先に確かめます。担当者どうしで判断が割れる項目があれば、それは人が確定させる工程として残す候補です。
例外の扱いは、割合を先に数えます。1業務目で例外が少なかったからといって、2業務目も同じとは限りません。例外の多い業務で自動化の範囲を広く取ると、差し戻しが増えて元の作業より手間がかかることがあります。数え方と対象の決め方は「例外処理が多い業務をAIで自動化する」で扱っています。
つなぐ先のシステムと権限は、接続先が1業務目と同じかどうかで扱いが変わります。同じシステムでも、書き込む対象や必要な権限が違えば申請からやり直しになります。方式の選び分けと書き込みを許す範囲は「AIエージェントを基幹システム・SaaSにつなぐ」にまとめています。
広げる順番を、5つの問いで決める
候補が複数あるときは、要望の強さではなく載せ替えやすさで並べます。次の5つのうち、満たす数が多い業務から着手します。
| 問い | 満たすと何が起きるか | 満たさないときの扱い |
|---|---|---|
| 入ってくるデータの形は1業務目と近いか | 取り込み口をほぼそのまま使える | 読み取りを足す日数を見積もりへ加える |
| 正しい出力の条件を担当者が言葉にできるか | 判定の設計が短く済む | 過去の結果を並べて条件を作る工程を先に置く |
| 例外の割合を数えられるか | 任せる範囲を決められる | まず数えるところから始め、着手は後ろへ回す |
| つなぐ先は1業務目と同じか | 権限の申請と接続の設計を省ける | 接続の確認を着手前の作業として切り出す |
| 業務側に引き取る担当がいるか | 動かし始めた後に判断が止まらない | 担当が決まるまで着手しない |
最後の行だけは、満たすまで着手しない条件として扱います。ほかの4つは日数の増減で吸収できますが、業務側で判断を持つ人がいない状態では、判定の基準が決まらないまま設計が進み、出来上がった後に誰も使わない形になります。
満たす数が同じ業務が並んだ場合は、件数の多いほうを先にします。同じ仕組みでも処理する件数が多いほど、人が確認する手順の粗さが早く表に出ます。
誰が引き取るかを、着手の前に決める
2業務目からは、作る人と使う人が別の部署になります。ここで役割を分けずに進めると、1業務目を作った担当者が全部署分の判断を抱える形になり、業務の数が増えるほど動きが遅くなります。
置く役割は3つです。業務側で判定の基準を決める人は、2業務目の部署から出します。正しい出力が何かを答えられる人でなければ務まらないため、部署の中で実際にその作業をしている人が適任です。作る人は1業務目の担当者が続けますが、判定の中身は決めません。載せ替える部分の面倒を見る人を1人置き、取り込み口や記録の形を業務ごとに勝手に変えないようにします。
運用に入った後に誰が直すかも、着手の段階で決めておきます。出力のずれは業務側、接続先の変更は作った側、権限は情報システム側という分け方が動きやすく、これは「内製したAIエージェントの運用・保守」で詳しく扱っています。役割を置く部署と決裁の流れは「社内のAI推進体制をどう作るか」にまとめています。
何日かかるかを、1業務目の実測値から置く
2業務目の日数は、一般的な相場ではなく自社の1業務目から出します。そのために、1業務目の作業時間を工程ごとに記録しておきます。記録が残っていない場合は、担当者に工程ごとの幅(最短と最長)を聞いて埋めます。
置き方は次の順です。まず1業務目の工程別の実績を並べ、今回そのまま載せ替える工程を差し引きます。残った工程に、上の5つの問いで満たさなかった項目の分を足します。読み取りを足す、例外を数える、接続を確認する、といった作業がここに入ります。最後に、判定の基準を決める工程だけは幅を広めに取ります。ここは相手の業務の複雑さで変わり、着手前には読み切れないためです。
幅が大きすぎて稟議に出せない場合は、判定の基準を決める工程だけを先に短く区切って進め、その結果を見てから残りを置き直します。全体の見積もりを一度で確定させるより、決まらない部分を先に潰すほうが結果として早く済みます。投資対効果の出し方は「AI導入の効果測定」で扱っています。
広げるのを止める合図
3業務目以降に進むかどうかは、業務の数ではなく次の状態で判断します。載せ替える部分に業務ごとの分岐が増え始めたら、一度立ち止まる合図です。共通のはずの取り込み口に「この業務のときだけ」の条件が積み上がると、次の業務で触るたびに前の業務が止まるようになります。
もう一つは、人が手を入れる割合が業務をまたいで横ばいになったときです。1業務目で下がり、2業務目でも同じところで止まるなら、原因は個別の業務ではなく、任せる範囲の取り方にあります。範囲を狭めて確実に通る形へ戻したほうが、広げ続けるより定着します。内製で持つ範囲そのものの線引きは「生成AI・AIエージェントの内製化とは」で扱っています。
まとめ:2業務目へ広げるときの要点
- 1業務目の中身を、業務が変わっても変わらない部分(取り込み口、承認の入れ方、記録と精度の見方)と、業務ごとに決め直す部分(判定の基準、例外、接続先)に分ける
- 載せ替える部分は、2業務目に着手する前に部品として切り出す。要件を詰めながら同時に直さない
- 決め直す部分は中身を借りず、1業務目で使った記入項目の形だけを使う
- 広げる順番は要望の強さではなく、データの形・判定の言語化・例外の割合・接続先・引き取る担当の5つで決める
- 業務側に判断を持つ人がいない業務には着手しない。ほかの4つは日数で吸収できる
- 日数は相場ではなく1業務目の実測値から置き、判定の基準を決める工程だけ幅を広く取る
- 共通部分に業務ごとの分岐が増えたら、広げる前に整理し直す
Augueでは、AIエージェントの開発から、社内で2業務目・3業務目へ広げていくための共通部分の切り出しや体制づくりまでを支援しています。最初の一業務は動いたものの次の広げ方で迷っている方は、是非ご相談ください。
よくある質問
2業務目に外部の支援を入れるべきでしょうか。1業務目は支援を受けて作りました。
支援を受ける範囲を1業務目と同じにせず、社内で手が止まった箇所だけに絞るのが現実的です。全工程に併走してもらうと、2回目も同じ依存が残ります。判定の設計は社内で進め、接続や権限の設計だけレビューを受ける、といった形で切ると、次の3業務目で外せる部分が見えてきます。契約は業務単位ではなく、期間と対象工程で区切っておきます。
2業務目は1業務目と同じAIモデル・同じツールで揃えるべきですか。
特段の理由がなければ揃えます。違うものを使うと、ログの形式・費用の見方・不具合時の調べ方が業務ごとに分かれ、運用の手間が業務数に比例して増えます。揃えない判断が要るのは、扱うデータの持ち出し条件が違う場合や、処理する分量が桁違いに多い場合です。その場合も、記録の残し方と呼び出し口は共通にしておくと後から比べられます。
1業務目がまだ安定していない段階で、2業務目に着手してよいですか。
目安は、人が手を入れる割合が下がり続けているかどうかです。下がっていれば並行して構いませんが、横ばいのまま数か月続いているなら、原因が1業務目の作り方ではなく前提の置き方にある可能性があります。その状態で広げると同じ問題が2つになります。人手が要る箇所を洗い出してから着手を決めます。
2業務目にかかる費用は、1業務目より安くなりますか。
一律に何割安くなるとは言えません。使い回せる部分の割合が業務によって変わるためです。判断できる形にするには、1業務目の作業時間を工程ごとに記録しておき、2業務目で載せ替えられる工程を差し引いて見積もります。接続先が1業務目と同じかどうかで差が大きく出るため、そこを先に確認してから金額を置きます。
関連する記事
生成AI・AIエージェントの内製化とは|どこまで自社で持ち、どこを外注に残すか外注に残す範囲は、業務の発生頻度と仕様がどこにあるかで決まります。着手前に確かめる5点、基盤・実装・判定基準・運用の層ごとの線引き、持ち方の3つの型、併走を終える判断までを表で整理しました。
生成AI内製化はどの業務から始めるか|候補をその場で絞り込む判定表と、最初は外す業務の見分け方最初の一業務は、年間の手作業時間と、間違いに人が気づけるかの2つで決まります。候補をその場で並べて落とせる判定表、最初は外したほうがよい4つ、既存の業務システムを抱えた業務の扱いまで整理しました。
内製したAIエージェントの運用・保守|壊れたときに誰が直すかと、外部支援を外すタイミング内製したAIに起きる不具合を、指示の調整で済むもの、接続先の仕様変更、権限の問題に分けて一次対応者を決める方法から、月次点検の項目、精度低下への気づき方、外部支援を外す目安までを整理します。
社内のAI推進体制をどう作るか|専任と兼任の分かれ目、情シス・現場・経営の分担と決裁の流れAIを社内へ広げるときに、誰が旗を振り、誰が作り、誰が承認するかを決めるための記事です。専任を置く分かれ目、情報システム・現場・経営の分担、予算の出どころと決裁の流れ、推進担当の評価の付け方までを扱います。
AIエージェントを基幹システム・SaaSにつなぐ|連携方式の選び分けと、書き込みまで許す範囲の決め方社内の基幹システムやSaaSにAIエージェントをつなぐ方式を、APIで直接つなぐ形、ファイルや連携基盤を挟む形、画面操作を代行する形で比べます。読み取りから書き込みへ広げる順序と、承認・履歴の決め方も整理します。



