AIエージェントは社内だけで作れるか｜最小3人の内訳と、支援を受ける場合の分担

AIエージェントは、認証と権限の設計、他システムとの接続という2箇所に触れない範囲であれば社内だけで作れます。最小の体制は業務担当、とりまとめ役、技術面の受け皿の3人で、いずれも兼務で成立します。工程ごとの主担当、非エンジニアが担える境界、導入支援を受ける場合の分担、引き継ぎまでを順に扱います。

内製の範囲を工程で分ける

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

工程で分けると、判断できる単位になります。AIエージェントを1本作って使い続けるまでには、次の5つがあります。

要件定義 … 対象業務の範囲と、対象外にする例外の扱いを決める
設計 … データの流れ、他システムとの接点、権限の範囲を決める
実装 … 指示と処理の流れを組み、動く状態にする
評価 … 出力が業務で使える水準かを判定する
保守・運用 … 業務が変わったときに直し、使われているかを見る

このうち社内に置く必要が高いのは1・4・5です。3つに共通するのは、判断の材料が社内にしかないことです。どの例外を対象から外すか、出力のどこまでを許容するか、業務がどう変わったかは、外から見えません。外へ出すと、そのつど社内へ確認する往復が発生します。

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

非エンジニア中心で始める場合、最小の体制は3人です。対象を決めて指示を書く業務担当、優先順位と記録を持つとりまとめ役、権限と接続を見る技術面の受け皿で、いずれも兼務で成立します。エンジニアの手が要るのは、設計のうち認証と権限に関わる部分と、実装のうち他システムとの接続の2箇所です。この2箇所に触れない範囲にとどめるなら、業務側だけで1本目を通せます。

この記事で扱うのは、AIエージェントを1本作って使い続けるまでの体制と分担です。工程ごとの主担当、3人の役割、導入支援に任せる範囲、引き継ぎまでを順に見ます。基盤やデータのどの層まで自社で持つかという線引きと、内製化を進める順序は生成AI・AIエージェントの内製化とはにまとめています。自社で持つ範囲をまだ決めていない段階なら、そちらを先に読むと判断の材料が揃います。

工程ごとの主担当と、外部の支援が要る部分

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

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

社内で決めた内容をどの欄にどう落とすかは AIエージェントの要件定義の書き方にまとめています。対象外の宣言と合格ラインが書けているかを、外部へ渡す前の確認に使えます。

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

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

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

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

業務担当が持てる範囲は、実装を含めても思っているより広いです。指示を書く、処理を工程に分ける、例外を後から足す、出力の形を整えるところまでは、業務を知っている人の方が速く進みます。仕様を人へ伝える工程が要らないためです。

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

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

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

対象者がどこまで到達しているかの判定を段階に分けたい場合は、非エンジニアがAIを作れるようになるまでの4段階が使えます。ここでは、その到達段階に応じて任せる工程を変える、と考えると整理しやすくなります。

3人で回すときの分担例

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

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

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

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

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

3人の兼務で足りるのは、持っているものが1本のうちです。2本目3本目と増えたときに最初に足りなくなるのは、技術面の受け皿ではなくとりまとめ役の時間です。作る作業は分散できますが、どれを先に直すかの判断は1人に集まるためです。

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

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

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

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

導入支援を入れるときの、社内側の座り方

支援を受けて1本目を作る場合でも、3つの役は先に社内で決めておきます。支援側は工程を代われますが、役は代われません。対象範囲を決める人と出力を判定する人が社内で決まっていないと、支援期間中は動いても、抜けた時点で誰も判断できなくなります。

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

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

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

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

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

支援そのものをどの提供形態から選ぶか（伴走型か開発代行か研修か）は AI内製化支援サービスの選び方で扱っています。ここでは、どの形態を選んだ場合でも社内側に置く役と判定を扱っています。

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

内製したものは、公開した時点が完成ではありません。動かなくなる原因はいくつかの型に収まります。型ごとに、最初に見る場所と一次対応者を決めておくと、止まっている時間が短くなります。

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

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

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

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

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

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

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

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

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

使われているかを見る

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

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

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

4つ目を投資判断につなげる場合は、金額に換算する手順が別に必要です。換算の考え方は AI導入の効果測定と投資判断にまとめています。

自社の人員で踏み出せるかの見分け方

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

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

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

1が足りない … 業務の棚卸しから支援を受ける。対象業務を決める工程が最も影響が大きい
2が足りない … 設計のうち権限と接続の部分だけを委託する。実装は社内で持てる
3が足りない … 評価の観点を作る部分だけ初回に入ってもらい、2本目以降は社内で回す

3つのいずれも満たさず、対象業務も年に数回しか発生しない場合は、内製ではなく既製ツールで足りることがあります。自作と既製の選び分けは AIエージェントは自作か既製ツールかで扱っています。

まとめ：工程ごとに担当を決めて内製に入る

内製するかどうかは、全部か外注かの二択ではなく工程で決める。要件定義・評価・保守は社内に置く必要が高く、設計と実装のうち認証や接続に関わる部分は外部の支援が合う
非エンジニアが担える境界は、技術の難しさではなく他人のデータと権限に触るかどうかで引く。認証情報の保管、基幹システムへの書き込み、部門外のデータの扱いが線になる
最小の体制は業務担当、とりまとめ役、技術面の受け皿の3人。兼務でよいが、1人が3役を兼ねた状態は引き継げない
本数が増えたときに先に足りなくなるのは、とりまとめ役の時間。部門をまたぐ段では、対象業務を決める権限を先に置く
導入支援を受ける場合も3つの役は社内で先に決め、窓口を1人にする。支援を入れる範囲は期間ではなく工程で切り、並走の段階から社内の担当が手を動かす
動かなくなったときは、入力の変化・判断基準の変化・接続側の変化・指示の不足に切り分ける。前提として実行の記録が残っている必要がある
引き継ぎで残すのは動かし方ではなく、対象範囲を決めた理由・指示の意図・判定の基準・権限の所在。後任が1回通せたかで完了を判定する
月1回、実行件数・人が直した回数・使っている人数・対象業務の時間を見る。使う人が1人だけの状態は、その人が抜けると止まる
3つの判定条件のうち欠けているものだけを外部で補う。すべて欠けていて発生頻度も低い業務なら、既製ツールで足りる場合がある

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

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

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

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

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

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

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

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

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

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

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

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