社内でAIを使える・作れる人を育てたい2026年10月5日更新約22分で読めます（11,035文字）

AIエージェント内製と支援の分担｜外注との選び方と最小3人の体制

AIエージェントの内製で、工程ごとに社内の担当と外部の支援を分けている様子を表したイラスト

AIエージェントの内製は、全部を自社で作るか外注するかの二択ではなく、5つの工程のどこまでを社内に置くかで決まります。社内に残す必要が高いのは要件定義と評価、保守の3工程で、外に任せてよいのは設計のうち認証と権限に関わる部分と、実装のうち他システムとの接続です。動かすのは、対象を決めて指示を書く業務担当、優先順位と記録を持つとりまとめ役、権限と接続を見る技術面の担当の最小3人で、いずれも兼務で成り立ちます。

この記事の答え

AIエージェントの内製は工程で分け、要件定義・評価・保守を社内に置き、認証と他システムとの接続は外部の支援で補う

内製に進めるかの分かれ目は、対象業務の手順と例外を社内の人が自分の言葉で書けるか

業務担当・とりまとめ役・技術面の担当の3人を兼務で決め、足りない工程だけ外から補う

この記事で扱うのは、最初の1本を作るときの人と役の配り方です。基盤やデータのどの層まで自社で持つかの線引きと、内製化を進める順序は、全体を見渡してから決めると迷いが減ります。

1本目が動いたあと、同じ型を別の業務へ広げる段階では、使い回せる部分と作り直す部分の見極めが中心になります。体制の話が一段落してから読むと判断しやすくなります。

AIエージェントは内製と外注のどちらがよいか

どちらが一律によいということはありません。業務の変更が多く、判断の材料が社内にしかない業務ほど内製が合い、発生頻度が低い業務や専門性の高い接続は外注や既製ツールが合います。実際には、1本のAIエージェントの中で内製と外注を組み合わせる形がいちばん多くなります。

内製が向く業務と、外注や既製ツールが向く業務

業務の条件で分けると、どの進め方が合うかを判断しやすくなります。

業務の条件	向く進め方	理由
手順や判断の基準がよく変わる	内製	変更のたびに外へ依頼すると、待ち時間が積み重なる
例外の扱いを現場の人しか判断できない	内製（要件定義と評価を社内で持つ）	判断の材料が社外からは見えない
基幹システムへの書き込みや認証の設計が要る	内製しつつ、その部分だけ外部の支援を受ける	頻度が低く、社内に担当を置いても経験がたまらない
年に数回しか発生しない	既製ツール、または手作業のまま	作る手間と保守の負担に見合わない
社内に手順を書ける人がいない	業務の棚卸しから支援を受ける	対象を決める工程が抜けると、作っても使われない

表の3行目のように、内製を選んでも全部を社内で持つ必要はありません。技術面で手が止まりやすい部分だけを外部の支援で補い、決める工程を社内に残すのが、内製化を支援付きで進めるときの基本の形です。

内製か外注かを決める判断フロー

内製に進めるかは、対象業務の手順と例外を社内の人が自分の言葉で書けるかで決まります。エンジニアがいるかどうかは、その次の問いです。

手順と例外を社内で書けるかが、内製に進めるかの分かれ目です。

最初の問いで発生頻度を見るのは、使う回数が少ない業務では、作ったあとの保守の手間のほうが大きくなるためです。2つ目の問いで「いいえ」になった場合も、内製をあきらめる必要はありません。業務の棚卸しを支援してもらい、対象と例外を決める工程を社内で経験しておけば、2本目以降は自分たちで進められます。

AIエージェントを内製するメリット・デメリット

内製のメリットは、業務が変わったときに社内で直せることと、作る過程で知見が社内に残ることです。デメリットは、担当者に頼りきりになりやすいことと、最初の1本が動くまでに時間がかかることです。

観点	内製のメリット	内製のデメリット・注意点
業務の変更への対応	判定の基準や例外を、社内の判断ですぐ直せる	直す人が決まっていないと、誰も直さないまま残る
費用	外注費がかからず、直すたびの依頼費も出ない	社内の人の作業時間が増える。見えにくいが費用である
社内に残る知見	2本目以降を自分たちで作れるようになる	1人が抱えると、異動した時点で失われる
立ち上がりの速さ	対象業務を知っている人が作るので、仕様を伝える手間が無い	慣れるまでは、1本目が動くまでに外注より時間がかかりやすい
品質の安定	現場の例外を反映しやすい	作った本人の確認だけで済ませると、使う人の目で見た品質が抜ける

メリットが大きくなるのは業務の変更が多いとき

**内製のメリットは、作ったあとに何度直すかで大きく変わります。**手順や判断の基準が年に何度も変わる業務では、変更のたびに外へ依頼する往復がなくなるだけで、止まっている時間が短くなります。逆に、一度作れば数年は変えない業務では、この差はほとんど出ません。

費用を比べるときは、外注費と社内の作業時間を工程ごとに並べると、どこで差が出るかが分かります。

デメリットは体制の決め方で小さくできる

**担当者への依存と立ち上がりの遅さは、どちらも体制の決め方で小さくできます。**役を3人に分けて記録を一箇所に集めれば、1人が抜けても止まりません。1本目だけ外部の支援と並んで作れば、慣れるまでの時間も短くなります。以降の節では、この体制の組み方を工程と役割の両面から見ていきます。

AIエージェントの内製で社内に置く工程と、外に任せる工程

支援を受けながら内製する場合、工程ごとの主担当は次のように分かれます。1本のAIエージェントを作って使い続けるまでを、要件定義・設計・実装・評価・保守の5つに分けたものです。

5つの工程ごとの主担当

判断の材料が社内にしかない工程は社内に、頻度が低く専門性の高い部分は外に置きます。

工程	この工程で決めること	社内の主担当	外部の支援を受けることが多い部分
要件定義	対象業務の範囲と、対象外にする例外の扱い	その業務を日常的に回している人	対象業務の選び方や、他社での組み方の相談
設計	データの流れ、他システムとの接点、権限の範囲	情報システム部門、または技術面を引き受ける1名	認証・権限・ネットワークの構成、基盤の選定
実装	指示と処理の流れを組み、動く状態にする	業務担当（指示と処理の流れ）	他システムとの接続、例外処理の作り込み
評価	出力が業務で使える水準か	その業務を回している人と、最終確認をする人	判定の観点の作り方（初回のみ）
保守・運用	業務が変わったときの修正と、使われているかの確認	業務担当と、技術面を引き受ける1名	基盤の更新、外部サービスの仕様変更への追随

要件定義・評価・業務変更の反映は社内に置きます。
認証や基盤のように頻度が低く専門性の高い部分は、外部の支援で補います。

外部の支援を受けるときに社内で押さえる3点

要件定義に外部が入る場合も、決めるのは社内です。相談できるのは進め方や他社の事例で、対象範囲と例外の扱いは社内の判断になります。要件定義を外部の提案どおりに決めると、動いたあとで現場の例外が合わず、作り直しになります。

評価の行は抜けやすい部分です。作った本人が「動いた」と判断して終わりにすると、業務で使う人が別にいる場合に手戻りが出ます。判定する人を最初に決めておきます。

保守・運用は、外部の支援を受ける範囲を契約前に決めておきます。基盤の更新のように頻度が低いものは委託が合いますが、判定の基準の変更まで含めると、業務が変わるたびに依頼と待ち時間が発生します。

分担がこの位置で切れる理由

AIエージェントを社内で作るかどうかを、全部を自社で持つか全部を外に出すかの二択で考えると、判断が止まります。社内の人員構成を見て「エンジニアがいないから無理」で終わるか、逆に「ツールがあるからできる」と見積もって設計で行き詰まるかのどちらかになります。

社内に置く3工程に共通すること

**要件定義・評価・保守に共通するのは、判断の材料が社内にしかないことです。**どの例外を対象から外すか、出力のどこまでを許容するか、業務がどう変わったかは、外から見えません。外へ出すと、そのつど社内へ確認する往復が発生します。

反対に設計と実装は、社内に置かなくても成り立ちます。設計のうち認証や権限に関わる部分、実装のうち他システムとの接続は専門性が高く、発生頻度も低いためです。ここを無理に社内で持つと、年に数回しか触らない領域の担当を抱えることになります。

エンジニアの手が要るのは2箇所だけ

非エンジニア中心で始める場合も、エンジニアの手が要るのは、設計のうち認証と権限に関わる部分と、実装のうち他システムとの接続の2箇所です。この2箇所に触れない範囲にとどめるなら、業務側だけで1本目を通せます。

つまり、社内だけで作れるかは人員構成ではなく、5つの工程のうちどこまでを社内に置くかで決まります。以降は、その配り方を担う人の側から見ていきます。

非エンジニアが担える範囲と、その境界

業務担当が持てる範囲は、実装を含めても思っているより広いです。

業務担当が持てる範囲

**指示を書く、処理を工程に分ける、例外を後から足す、出力の形を整えるところまでは、業務を知っている人のほうが速く進みます。**仕様を人へ伝える工程が要らないためです。

担当者がどこまでできるようになったかを段階で見たい場合は、到達段階に応じて任せる工程を変えると考えると整理しやすくなります。

技術面の担当が入る条件

境界は、扱う技術の難しさではなく、**他人のデータと権限に触るかどうかで引けます。**次に当てはまる場合は、技術面を引き受ける人が入ります。

認証情報やAPIキーを保管する必要がある
基幹システムや共有データベースへ書き込む
部門の外にあるデータを読む、または社外のサービスへ送る
実行の記録を、後から追える形で保管する必要がある
動かなくなったときに、業務が止まる範囲が自部門を超える

このうち最後の1つは技術の話ではありません。止まったときの影響範囲が広いものは、担当が1人だと復旧の見込みが立たないため、体制の側で見ます。

既存の業務システムを抱えたまま進める場合

すでに受発注や会計の業務システムが動いていて、その周辺をExcelで補っている状態から始めることがほとんどです。この場合に体制を左右するのは、AIエージェントが既存システムへどこまで触るかです。

既存システムへの触り方で変わる体制

触り方を3段階に分けると、社内に足す役と、外部の支援が要る範囲が変わります。

既存システムとの関わり方	体制に足す役	外部の支援が要るところ
人が渡す（画面から書き出したファイルを読ませ、結果も人が戻す）	足す役はない。業務担当の範囲で収まる	書き出す項目の決め方の相談のみ
読み取りだけつなぐ（参照権限で取得し、書き込みはしない）	技術面の担当。参照権限の申請と接続先の管理を持つ	接続の初回設定、認証情報の保管場所の設計
書き込みまで許す（既存システムの登録や更新まで行う）	情報システム部門の正式な関与。承認の経路と実行記録の保管を決める	権限とネットワークの構成、失敗したときの戻し方の設計

**1本目は、上の2段までにとどめると体制を増やさずに進められます。**人が渡す形は遠回りに見えますが、対象範囲と例外の洗い出しは同じようにでき、接続を後から足すこともできます。先に接続から入ると、権限の調整が終わるまで業務側の検討が止まります。

書き込みをどこまで許すかと、連携の方式の選び方は、接続を足す段階で決めれば足ります。

ベンダー保守やExcel運用がある場合

保守をベンダーへ委託しているシステムでは、接続してよいかの確認がベンダー側に回ります。**この待ち時間は社内の作業量としては見えないため、とりまとめ役が期間に織り込んでおきます。**確認の結果として接続が認められない場合もあるため、その時点で人が渡す形へ戻せるようにしておきます。

Excelや共有フォルダで回している部分は、既存システムより先に着手しやすい対象です。権限がファイルの共有範囲で閉じており、技術面の担当が見る範囲も狭くなります。

3人で回すときの分担例

件数が多く手順が決まっている業務を1本内製する場合、最小の体制は3人です。専任である必要はなく、いずれも兼務で成り立ちます。

役割	何を持つか	置かないと何が起きるか
業務担当	対象範囲の決定、指示の作成と修正、出力の確認	例外が後から出てきて、作ったものが使われないまま残る
とりまとめ役	対象業務の優先順位、記録の管理、他部門への展開	部門ごとに似たものが個別に作られ、誰が何を持つか分からなくなる
技術面の担当	権限と接続、実行の記録、止まったときの一次対応	認証や接続でつまずいた時点で止まり、再開の判断ができない

1人が3役を兼ねる形は、最初の1本なら動きます。ただし、1人が3役を兼ねた状態は引き継げません。作った経緯も権限の所在もその人の中にしかないため、異動した時点で誰も触れなくなります。2本目に入る前に、少なくとも技術面の担当を別の人に移しておきます。

とりまとめ役は、部門をまたいで見る立場の人が向きます。役割の中身は、優先順位を決めることと、作ったものの記録を一箇所に集めることです。技術的な判断は含みません。

3人をどこから選ぶか

役を決めても、誰を当てるかで進み方が変わります。募集や採用から入る必要はなく、多くの場合は既にいる人の中から選べます。

役割ごとに社内で見るところ

選ぶときに見るのは、AIの知識ではなく次の点です。

役割	社内で見るところ	向かない人を当てたときに起きること
業務担当	その業務を自分で回していて、例外の扱いを判断した経験があるか	手順書どおりの説明しか出てこず、例外が後から次々に出る
とりまとめ役	複数部門の業務量を見ていて、優先順位の変更を通せる立場か	直す順番が決まらず、要望が届いた順に着手して滞る
技術面の担当	アカウントと権限の申請を扱った経験があるか。開発経験は問わない	権限でつまずいた時点で止まり、誰に聞けばよいか分からなくなる

業務担当は、その業務の経験年数より、例外を判断してきたかで選びます。件数を多く処理してきた人でも、判断は上長へ上げる運用だった場合、対象外にする条件を自分では決められません。

技術面の担当に開発経験を求めない

技術面の担当に開発経験を求めると、候補が情報システム部門の数名に絞られ、そこで体制が組めなくなります。この役が実際に扱うのは、権限の申請とキーの保管場所、止まったときに誰へ連絡するかの判断です。社内システムの利用申請を通した経験があれば足ります。

3人を1つの部門から集める必要もありません。とりまとめ役だけ部門をまたぐ立場の人に頼み、残る2人を対象業務の部門から出す形が組みやすくなります。ただし業務担当と技術面の担当が別の部門になる場合は、連絡の経路を先に決めておきます。決まっていないと、止まったときの連絡が上長経由になり、一次対応が翌日以降になります。

本数が増えたときの体制の広げ方

3人の兼務で足りるのは、持っているものが1本のうちです。

段階ごとに先に足りなくなるもの

**2本目、3本目と増えたときに最初に足りなくなるのは、技術面の担当ではなくとりまとめ役の時間です。**作る作業は分けられますが、どれを先に直すかの判断は1人に集まるためです。

段階	体制で先に足りなくなるもの	増やす前に決めておくこと
同じ部門で1本	技術面の担当が1人しかいない状態	その人が不在のとき、止まった連絡を誰が受けるか
同じ部門で数本	とりまとめ役の時間。直す順番の判断が滞る	直す順番の決め方と、月に充てる時間の上限
部門をまたぐ	対象業務を決める権限。部門ごとに要件が食い違う	対象を決める人と、権限の申請を通す窓口

兼務のまま何本まで持てるかに、一律の目安はありません。件数の多さより、例外がどれくらいの頻度で出るかで変わります。判断材料になるのは、直す作業に月どれくらいかかっているかを担当者に記録してもらうことです。業務時間に収まらなくなった時点が、役を分ける合図になります。

部門をまたぐときは決める権限を先に置く

部門をまたぐ段では、技術ではなく決定権が先に問題になります。他部門の業務を対象にするとき、範囲を決めるのはその部門の業務担当です。とりまとめ役が代わりに決めると、動いたあとで現場の例外が合わず作り直しになります。増やすのは役の数ではなく、業務担当の人数です。

専任を置く判断は、この段まで待って構いません。1本目の時点で専任を作ると、対象業務が決まる前に人だけが空くことになります。

AIエージェントの導入支援で内製化するときの、社内側の役割

支援を受けて1本目を作る場合でも、3つの役は先に社内で決めておきます。

支援を受ける前に社内で決めること

支援する側は工程を代われますが、役は代われません。対象範囲を決める人と出力を判定する人が社内で決まっていないと、支援期間中は動いても、支援が終わった時点で誰も判断できなくなります。

**窓口は1人にします。**部門ごとに個別へ依頼すると、決めたことが支援側でしかそろわず、社内に記録が残りません。窓口はとりまとめ役が持ち、決めた内容と理由を社内側で保管します。

支援の範囲は期間ではなく工程で区切る

**支援を入れる範囲は、期間ではなく工程で区切ります。**段階ごとに、社内が手を動かす範囲と、次へ進めてよいかの判定は次のように置けます。

順番	段階	社内が手を動かす範囲	次へ進めてよいかの判定
1	支援と並走して1本目を作る	対象範囲と例外の決定、指示の作成、出力の確認	例外を1件足す修正を社内だけでできたか
2	2本目を社内主体で作る	上記に加え、出力の形と確認の入れ方の設計	支援へ聞かずに最後まで通せたか
3	支援が終わった後	業務変更の反映、止まったときの原因探し、権限とキーの管理	止まったときの一次対応者が決まっているか

1段目で社内が手を動かさないと、成果物は残ってもスキルは残りません。支援側が作って納品する形にすると、動くものは早く手に入りますが、業務が変わった時点で再び依頼が必要になります。並走の間に社内の担当が触っておくかどうかで、支援が終わった後に直せるかが決まります。

引き渡し前にアカウントとキーを社内へ移す

判定の列は、資料を受け取ったかではなく作業ができたかで書いています。**手順書があっても、権限が支援側のアカウントに紐づいたままだと社内では動かせません。**引き渡し前に、アカウントとキーの管理者を社内へ移しておきます。

支援の提供形態（伴走型か開発代行か研修か）によって、社内に残るものは変わります。どの形態を選んだ場合でも、社内に置く役と判定は同じです。

動かなくなったときの直し方

内製したものは、公開した時点が完成ではありません。動かなくなる原因はいくつかの型に収まります。

症状ごとに最初に見る場所

型ごとに最初に見る場所と一次対応者を決めておくと、止まっている時間が短くなります。

症状	最初に見る場所	一次対応者
特定の入力だけ結果が崩れる	入力の形が変わっていないか（項目名、レイアウト、桁）	業務担当
全体の判定がずれ始めた	社内の判断基準が変わっていないか、参照する資料が更新されたか	業務担当
途中で止まる、エラーになる	接続先の権限、キーの有効期限、外部サービスの変更	技術面の担当
出力が安定しない	指示の書き方、例外の扱い、渡している情報の不足	業務担当
誰も気づかないまま結果が使われていた	確認の工程が飛ばされていないか	とりまとめ役

表の上4行で原因を探すには、実行の記録が残っている必要があります。いつ、どの入力で、どう出力したかが残っていないと、再現できないため原因にたどり着けません。記録の保管は設計の段階で入れます。後から足すのは手間がかかります。

最後の行は、直す以前の問題です。出力を人が確認する工程を挟んでいたつもりでも、件数が増えると省かれていきます。定期的に、確認が実際に行われているかを見ます。

直さずに畳む判断

**業務そのものが無くなった、対象件数が減って手作業で足りるようになった場合は、畳むほうが合理的です。**動かないものを残しておくと、次に見た人が使ってよいか判断できません。

担当者が異動したときの引き継ぎ

引き継ぎで残すのは、動かし方ではありません。動かし方は触れば分かります。追えなくなるのは、決めた理由です。

引き継ぎで残す4つのこと

残すのは、後任が自分では復元できない「決めた理由」と「権限の所在」です。

残すもの	残さないと起きること
対象範囲と、対象外にした条件	なぜその例外を外したのか分からず、後任が範囲を広げて精度を落とす
指示の意図と、過去に直した経緯	同じ失敗を繰り返す
判定の基準	どこまでを許容とするか、最終確認を誰がするかがぶれる
アカウント・権限・キーの所在	失効したときに誰も再発行できない

引き継ぎが済んだかの判定

引き継ぎが済んだかどうかは、文書を渡したかではなく、**後任が1回通せたかで判定します。**対象業務が月に1回しか発生しないなら、判定できるまで1か月かかります。異動の内示から着任までの期間しか見ないと、判定前に前任者がいなくなります。

前任者が作ったものを後任が触りたがらない場合、引き継ぎ資料の不足より、直してよい範囲が決まっていないことが原因のことが多いです。どこまでを後任の判断で変えてよいかを、引き継ぎの時点で決めておきます。

使われているかを見る

内製の場合、作ったあとに誰も見ない状態になりやすいです。外注なら報告のタイミングがありますが、社内で作ったものには報告の義務がありません。月1回、次の4つを見る程度で足ります。

実行された件数（想定より少なければ、使われていない）
人が直した回数（多ければ、出力の水準が業務に合っていない）
使っている人数（1人だけなら、その人が抜けたときに止まる）
対象業務にかかっている時間（作る前と比べて変わったか）

このうち3つ目は体制の話です。**作った本人しか使っていないものは、内製の成果としては数えにくくなります。**他の人が使い始めると想定外の入力が入り、そこで初めて足りない部分が出ます。

4つ目を投資の判断につなげる場合は、かかっている時間を金額に換算する手順が別に必要です。

自社の人員でAIエージェントを内製できるかの見分け方

いまの人員構成で内製に入れるかは、次の3つで判断できます。

対象業務の手順と例外を、自分の言葉で書ける人がいるか
アカウントと権限について、社内で判断できる人がいるか（専任でなくてよい）
出力が業務で使える水準かを判定する人を決められるか

**3つとも満たすなら、支援なしで1本目に入れます。**満たさない項目があっても、内製そのものをあきらめる必要はありません。足りない工程だけを外から補う形にします。

足りない項目	外から補う範囲	社内で持ち続ける範囲
手順と例外を書ける人	業務の棚卸しの支援	対象業務を決める判断
権限を判断できる人	設計のうち権限と接続の部分	実装と評価
水準を判定する人	評価の観点づくり（初回だけ）	2本目以降の評価

3つのいずれも満たさず、対象業務も年に数回しか発生しない場合は、内製ではなく既製ツールで足りることがあります。

まとめ：AIエージェントの内製は工程ごとに担当を決めて始める

AIエージェントの内製は、全部か外注かの二択ではなく工程で決める。要件定義・評価・保守は社内に置き、認証や他システムとの接続は外部の支援が合う
内製と外注のどちらがよいかは業務の条件で決まる。変更が多く例外を現場しか判断できない業務は内製、年に数回の業務は既製ツールが合う
内製のメリットは社内で直せることと知見が残ること、デメリットは担当者への依存と立ち上がりの遅さ。どちらも体制の決め方で小さくできる
非エンジニアが担える境界は、技術の難しさではなく他人のデータと権限に触るかどうかで引く
既存の業務システムがある場合、1本目は人が渡す形か読み取りだけつなぐ形にとどめる
最小の体制は業務担当、とりまとめ役、技術面の担当の3人。兼務でよいが、1人が3役を兼ねた状態は引き継げない
3人は既にいる人の中から選べる。技術面の担当に開発経験は求めない
本数が増えたときに先に足りなくなるのは、とりまとめ役の時間。部門をまたぐ段では、対象業務を決める権限を先に置く
導入支援を受ける場合も3つの役は社内で先に決め、窓口を1人にする。支援の範囲は期間ではなく工程で区切る
動かなくなったときに原因を探せるよう、実行の記録を設計の段階から残す
引き継ぎで残すのは決めた理由と権限の所在。後任が1回通せたかで完了を判定する

Augueでは、非エンジニアの方がご自身の業務を任せるAIエージェントを作れるようになるまでの伴走支援と、権限や接続のように社内で持ちにくい工程の設計支援を行っております。どの工程を社内に残し、どこだけ支援を受けるかの整理から進められますので、ご興味がある方は是非ご相談ください。

社内でAIを使いこなせる人を育てませんか？

研修だけで終わらせず、現場の業務で使い続けられる体制づくりまで伴走します。研修の内容と進め方は、サービス資料で紹介しています。

資料をダウンロードする無料相談に申し込む

よくある質問

社内にエンジニアが1人もいない場合でも、AIエージェントの内製はできますか？

扱う範囲を絞れば成立します。条件は、社内のデータを外へ出さずに済む構成にとどめ、他システムへの書き込みを含めないことです。この範囲なら権限やネットワークの設計が要らないため、業務側だけで組めます。逆に基幹システムへの反映や認証情報の管理が必要になった時点で、技術面を引き受ける人が社内に必要になります。委託先の保守契約でその部分だけを補う形でも構いません。

既製のAIツールを導入する場合でも、同じ体制が必要ですか？

要件定義と評価と保守は同じように必要です。既製ツールで省けるのは設計と実装で、どの業務に当てるか、出力が使える水準かをどう判定するか、業務が変わったときに設定を直すかは社内に残ります。導入したツールが使われないまま止まる原因は、この3工程の担当が決まっていないことが多いです。自作と既製の選び分けそのものは別の論点になります。

保守を外部へ委託する場合、どの範囲までにすべきですか？

発生頻度が低く、社内の業務知識を必要としない部分に限ります。基盤の更新、認証やネットワークの構成変更、外部サービスの仕様変更への追随が該当します。判定の基準や対象範囲の変更まで委託すると、業務が変わるたびに依頼と待ち時間が発生し、内製にした利点が消えます。委託する範囲は契約前に工程で線を引いておきます。

作ったAIエージェントが増えてきたら、どう管理すればよいですか？

3本を超えたあたりから一覧が必要になります。持つ項目は、対象業務、担当者、最終更新日、参照しているデータと接続先です。増えて困るのは本数ではなく、誰が持っているか分からないものが出てくることです。一覧に載っていないものは、担当者が異動した時点で誰も触れなくなります。棚卸しは半年に1回で足りることが多いです。

情報システム部門の負荷はどれくらい増えますか？

一律の数字は出せません。増える量は、社内のアカウント管理がすでに手順化されているか、外部サービスの利用申請に既存の枠組みがあるかで大きく変わります。判断材料にできるのは、最初の1本を作る過程で情報システム側に発生した作業を記録しておくことです。権限の付与、接続の確認、実行記録の保管のどこに時間がかかったかが分かれば、2本目以降の見込みが立ちます。