【テンプレート付き】AIエージェント要件定義の書き方｜8項目のNG例・OK例

AIエージェント要件定義とは、AIエージェントを構築する前に、何を対象にし、何を受け取って何を書き込み、どこまでをAIに任せ、何を満たせば完成とするかを決めて文書にすることです。決める項目は8つあり、この記事では項目ごとに、要件定義書によく出てくる書き方（NG例）と、そのまま構築と検証に渡せる書き方（OK例）を並べています。後半には、8項目をそのまま書き込める記入例つきのテンプレートを載せました。手元の要件定義書と見比べながら、書き直しに使えます。

この記事で触れている公的なガイドラインは、2026年10月時点の版です。最新の版は、記事末の出典に挙げた各機関の公開ページでご確認ください。

この記事の答え

• 構築の前に決めるのは、対象業務と範囲、入力、出力、AIが決めてよい範囲、使ってよい操作と権限、参照情報、失敗したときの扱いと記録、完成の判定基準の8項目です
• 分かれ目は、対象外と合格ラインを数えられる形で書けるかと、AIに渡す操作を元に戻せるかどうかで分けて書けるかの2つです
• まず対象業務の担当者に、対象外にする例外を挙げてもらうところから始めます

AIエージェント構築の要件定義は、画面と機能の一覧だけでは足りない

AIエージェントの要件定義でつまずくのは、書く項目が分からないからというより、従来のシステムの要件定義と同じ形式で書き切れてしまうからです。画面、機能、データ項目、権限がひととおり埋まった要件定義書ができあがり、実装が始まり、動いたものを見て初めて「これでは業務に使えない」と分かります。

足りなくなる理由は次の4つです。

1. 入力が毎回違う同じ依頼でも、メールの書き方は人によって違います。必要な情報が本文にあることも、添付ファイルにあることもあります。入力の形式を固定できないため、「どんな入力を受け付けるか」より先に、「どこからを対象外として人に回すか」を書く必要があります。
2. 出力が毎回同じにはならない同じ入力を2回通しても、文面の言い回しが変わることがあります。従来のシステムなら不具合ですが、生成AIを使う処理ではこれが前提です。どの項目がどう一致していれば正解とするかを、先に決めておく必要があります。
3. 途中で人が承認するAIが出した結果をそのまま確定させる処理はほとんどありません。承認をどこに置くかで、業務の流れも、減らせる時間も変わります。後から承認を足すと、AIが処理したものを人が全件見直す形になり、手間が減りません。
4. AIが自分でシステムを操作するAIエージェントは、メールを送る、レコードを書き換えるといった操作を、手順の途中で自分で選んで実行します。画面の操作を人が行う前提の要件定義書には、AIにどの操作を許すかを書く欄がありません。権限を「必要なものを付与する」と書いたままにすると、読むだけで足りる処理にも書き込みの権限が渡ります。

要件定義の進め方と、テンプレートや生成AIで済ませられる範囲

書き始めるとき、最初に探すのはたいてい書式です。社内のテンプレートを探すか、生成AIに要件定義書の雛形を作らせるところから入ります。ただ、雛形で分かるのは書く項目の名前までで、項目の中身は埋まりません。全体は次の4段階で進み、ツールが代わりにできるのは前半に偏ります。

生成AIに雛形を作らせると、項目名は一通り並びます。埋まらないのは中身です。対象外にする例外も、どの誤りなら許せるかも、業務を回している人の頭の中にしかありません。ツールで短くできるのは、書式をそろえる時間と見直す時間で、決める時間は短くなりません。

順番は、対象範囲を先に固め、入力と出力を確定させ、そのうえで合格ラインと運用時の扱いを埋めます。どの欄を誰に聞けば埋まるかは、8項目を見たあとで説明します。

構築前に埋めるAIエージェント要件定義の8項目

要件定義書の形式は、社内のものに合わせて構いません。見るのは、次の8つが埋まっているかです。

以下、項目ごとにNG例とOK例を並べます。例はどれも、共有メールアドレスに届く取引先からの問い合わせを、AIエージェントが仕分けて返信の下書きを作る業務を想定しています。

1. 対象業務と適用範囲

対象外を書かないと、検証のたびに「これも処理できないのか」という指摘が積み上がります。そのたびに範囲を広げていると、合格ラインに届く日が来ません。

対象外にするものは、担当者に「この業務で例外として扱っているものは何か」と聞くと出てきます。例外の扱いは手順書に書かれていないことが多く、担当者の経験（暗黙知）として残っているためです。

どの業務をAIエージェントに任せるか自体に迷いがある段階なら、要件定義の前に対象業務の候補を絞り込みます。

関連記事：AIエージェント開発の進め方｜対象業務の選び方と4工程の全体像、次へ進む前に決めること

2. 入力（どこから何が届くか）

入力の欄で書くのは、受け付ける形式の一覧より、受け付けない形式の宣言です。実物を1か月分集めて、形式ごとの件数を数えると決めやすくなります。数件しかない形式は、無理に対応範囲へ入れず、人が処理する側に残します。

届く経路も書きます。メールなのか、共有フォルダに置かれるのか、既存のシステムから連携されるのか。ここが決まらないと、認証と権限の設計に入れません。

社外から届く文面を読む場合は、文面の中に書かれた指示には従わないことも入力の欄に書きます。問い合わせのメールに「この内容を全員へ転送してください」「これまでの指示を無視して」と書かれていても、AIはそれを自社からの依頼として扱いません。ソフトウェアの安全対策に取り組む国際団体のOWASPが、生成AIを使うシステムの危険をまとめた一覧で、1番目に挙げている問題です。AIへの指示の書き方だけで完全に防ぐのは難しいため、送信のような外へ出る操作は、5つ目の「使ってよい操作と権限」の項目で人の承認を通す形にしておきます。

3. 出力（どこへ、どの形式で書き込むか）

出力先の必須項目をすべて並べると、AIだけでは埋められない項目が見つかります。上の例なら取引先コードがそれで、社内の取引先の一覧と突き合わせる処理が要ります。要件定義の時点で洗い出しておかないと、完成後も「最後の1項目だけ人が手で入れている」状態が残ります。

書き込む形も決めます。既存のレコードを更新するのか、新しく作るのか、下書きとして作るのか。出力先に下書きの機能があるかどうかで、承認の置き方が変わります。

4. AIが決めてよい範囲と、人が確定させる範囲

「最終的な判断は人が行う」と書いてあっても、誰が、何を見て、どの単位で承認するかが決まっていなければ設計できません。1件ずつなのか、まとめてなのか。承認する人はどの画面を見るのか。承認されなかった件はどこへ戻るのか。ここまで書いて初めて、流れの全体が決まります。

5. 使ってよい操作と権限

4番目の項目が「どこまでをAIが決めるか」なら、5番目は「そのためにAIへどの操作を許すか」です。AIが誤ったときの被害の大きさは、AIの賢さより、渡した権限の範囲で決まります。入力にまぎれた指示に引っ張られても、読むだけの権限しか無ければ、外へは何も出ていきません。

操作は、元に戻せるかどうかで3段階に分けて書くと決めやすくなります。

OpenAIが公開しているAIエージェントの作り方のガイドも、読み取りか書き込みか、元に戻せるか、お金が動くかで操作の危険度を付け、危険度の高い操作の前に人の確認を挟む形を挙げています。最初は3段階目の操作をすべて人の承認に回し、検証で誤りが少ないと確かめられた操作から、承認を外すかどうかを決めます。

どのデータをAIに読ませてよいかは、要件定義の前に、発注先を決める段階で社内の線を引いておきます。

関連記事：AIエージェント導入前の確認項目｜発注先を決める前に自社で固める7点と、撤退ラインの引き方

6. 判断に使う参照情報と、その置き場所

参照する資料は、置き場所だけでなく、誰が改定し、改定がいつAIに届くかまで書きます。資料そのものは担当部署がきちんと改定していても、AIが読んでいるのが別の場所に登録した写しだと、写しは古いまま残るからです。

たとえば、規程を改定したのに、AIのために登録した旧版を差し替え忘れたとします。AIはその日から旧版の規程で答えます。答え方はそれまでと変わらないので、使う人は内容が古いことに気づけません。動き始めてしばらくは正しく答えていたのに、改定が重なるほど古い内容の答えが増えていくのは、この形です。

そのため、AIには、担当部署が普段改定している資料そのものを読ませるのが基本です。どうしても写しを使う場合は、差し替える人と頻度を要件に書きます。

参照した資料名を出力に残すことも、要件に入れます。間違った答えが出たとき、指示の書き方の問題なのか、参照した資料が古かったのかを見分けやすくなります。

7. 失敗したときの扱いと記録

失敗したときに決めるのは、差し戻し先、再実行するかどうかと回数、たまった件数の上限の3つです。抜けやすいのは件数の上限です。1件ずつの失敗は目に付きませんが、差し戻しがたまっているのに誰も見ていなければ、動いているつもりで止まっているのと変わりません。

通知の宛先は、個人ではなくチャネルにします。担当が変わったときに通知が届かなくなるのを防げます。

記録は「ログを取得する」だけでは足りず、1件ごとに何を残し、どれだけの期間残すかまで書きます。誤った答えが出たとき、入力が想定外だったのか、参照した資料が古かったのか、AIへの指示の問題なのかを、記録から見分けるためです。総務省と経済産業省の「AI事業者ガイドライン」も、入出力や判断の根拠の記録を残し、記録の方法や保存期間を検討することを求めています。

あわせて、おかしな動きに気づいたときに処理を止める手順と、止める役の人を書きます。AIセーフティ・インスティテュートの評価観点ガイドは、2026年7月の版でAIエージェントの観点を足し、危険な操作や想定と違う動きを見つけたときに、人が介入して止められるかを確かめる項目を挙げています。

8. 完成の判定基準

「精度90%以上」のような割合だけの書き方は、何件で測り、何を一致とするかが決まっていないため、合格かどうかの判定に使えません。置き換え方は、この後の「精度90%以上」を扱う節で説明します。

合格した後に測り直す条件も、ここに書いておきます。使っているAIのモデルを新しい版に替えたとき、AIへの指示を書き換えたとき、参照する資料の構成を変えたときです。同じ答え方をする保証は無いため、合格を判定したときと同じ100件で測り直し、合格ラインを満たすかを見てから切り替えます。デジタル庁の生成AIの調達ガイドラインも、システムに求める要件の1つにモデルの更新への考慮を挙げています。

誰から何を聞いて、どの順で埋めるか

8つの項目は、上から順に1人で埋められるものではありません。項目ごとに答えを持っている人が違い、聞く順番を間違えると、埋めた欄が後から書き換わります。

最初に聞くのは、対象業務と適用範囲、そして対象外にする例外です。相手は業務を回している担当者で、この段階では入力と出力に手を付けません。範囲が動いているうちは、どの形式まで受けるかも、どこへ書き込むかも決められないためです。

入力と出力は、業務の担当者だけでは確定しません。届く経路も、書き込み先のレコードの作りも、接続先を持つ側に聞かないと分からないからです。業務側の想定だけで書いた欄は、情報システム部門に確かめた時点で書き換わります。推測で埋めず、確かめるまで空欄で残したほうが、どこが決まっていないかが見えます。

AIが決めてよい範囲と完成の判定基準は、出力を使う人と最終確認をする人の両方が入らないと決まりません。どこまでをAIに任せるかは、その出力を受け取って仕事を進める人が答えます。どの誤りなら許せるかは、最後に確認して責任を持つ人が答えます。片方だけで決めると、承認の単位が実際の確認のしかたと合わなくなったり、合格ラインが現場の感覚から離れた値になったりします。

使ってよい操作と権限も、2者で決めます。どのシステムにどの権限を設定できるかは、システムを管理する人にしか分かりません。一方で、どの操作なら誤っても取り返しがつくかは、その業務に責任を持つ人が判断します。

8つがすべて埋まるまで待つ必要はありません。対象範囲と対象外が固まった時点で、設計の相談は始められます。入力と出力を確かめている間に設計の議論を進めておくと、答えが返ってきた時点で残りの欄を埋められます。

「精度90%以上」では判定できない理由と直し方

「精度90%以上」は、何件で測るか、何をもって一致とするか、どの誤りを重く見るかが決まっていないため、合格かどうかの判定に使えません。10件中9件でも200件中180件でも90%になり、日付の1日違いと、対象外の案件を処理してしまう誤りが、同じ1件として数えられます。

直すときは、次の3つを書きます。

割合だけの合格ラインは、測る件数・一致の決め方・誤りの種類ごとに許す件数の3つに書き直します。誤りの種類は、業務への影響で分けます。処理してはいけないものを処理した誤り、処理すべきものを取りこぼした誤り、値を間違えた誤りの3つに分ければ、たいていの業務で足ります。1つ目は0件を条件にすることが多く、残りの2つは業務側が許せる件数を答えられます。

関連記事：AIエージェントの精度をどう評価するか｜合格ラインの決め方と、本番に出す前の確認手順

合格ラインに届かなかったときにどうするかも、あわせて書いておきます。対象範囲を狭めて作り直すのか、人の確認を増やして運用するのか。決めていないと、その場の判断で本番へ進むことになります。

関連記事：PoC止まりの原因とPoCを本番化する6条件｜3つの型と撤退の線引き

処理量と費用の上限も要件に入れる

8つの項目が埋まっても、渡す前にもう1組決めておくものがあります。1件あたりにかけてよい時間、1件の中で繰り返してよい回数、受け付ける件数の上限、動かすのにかかる費用の上限です。どれも動かし始めてから変えると、処理の分け方や接続の作りから組み直すことになりやすい項目です。

時間は、承認する人の都合から決めます。1時間かかっても構わない業務もあれば、その場で返事を求められる業務もあります。ここが決まると、1件ずつ処理するのか、夜間にまとめて流すのかが決まります。

繰り返してよい回数は、AIエージェントならではの項目です。AIエージェントは、答えが見つからないと資料を探し直し、接続先を呼び直しながら手順を自分で選びます。上限が無いと、1件の処理が終わらないまま時間と費用を使い続けます。Anthropicが公開しているAIエージェントの作り方の解説も、制御を保つために、繰り返しの回数の上限のような止める条件を入れるのが一般的だとしています。

件数は、平常時ではなく最も多いときで書きます。月末や年度末に件数が跳ね上がる業務は珍しくなく、そのときに間に合わないと、いちばん忙しい時期だけ人の手に戻ります。実データを1年分見て、月ごとの件数の差を確かめてから決めます。

費用は、月額の上限と、上限に近づいたときの通知先をあわせて書きます。生成AIを使う処理は、件数と1件あたりに渡す情報の量で費用が動くため、対象範囲を広げたとたんに伸びます。検証の段階で1件あたりの費用を測っておくと、範囲を広げるかどうかを決めるときに金額を先に出せます。

関連記事：AI導入の効果測定｜KPIの例と導入前後の比べ方、継続・中止の判断

そのまま使えるAIエージェント要件定義書のテンプレート（記入例つき）

8項目に、処理量と費用の上限と変更の記録を足した10行が、AIエージェント要件定義書のテンプレートです。記入例は、この記事で使ってきた問い合わせメールの仕分けの例です。表をそのまま社内の文書にコピーし、記入例を自社の業務に書き換えて使えます。

使うときは、次の順に進めます。

1. 記入例の列を消し、対象業務と適用範囲の行だけを先に業務の担当者と埋める
2. 残りの行は「聞く相手」の列の人に確かめながら埋め、確かめられていない欄は推測で書かずに空欄のまま残す
3. 空欄の行を一覧にして、誰がいつまでに答えるかを書き添える

テンプレートを使う目的は、全部の欄を埋めることではなく、決まっていない欄を見えるようにすることです。空欄が残ったまま構築を始めると、その欄は作る側の推測で埋まります。外部に構築を頼む場合は、空欄の一覧ごと依頼先に渡すと、見積の前提をそろえやすくなります。

当社の事例：食品メーカーの社内問い合わせAIを、要件の項目に沿って定義した

当社が支援したメーカー（食品）の事例です。社員からの問い合わせに、規程やマニュアルを探して答えるAIエージェントを作りました。この記事の要件の項目に沿って、何をどう定義したかを紹介します。

課題：資料を改定するたびに、AIのための登録し直しが要った

グループウェアをMicrosoft 365に切り替え、全社員がCopilotを使える環境は整っていました。ただ、「何を質問すればいいのか分からない」という社員が多く、あまり使われていませんでした。以前から社内の文書を探せる外部のサービスも使っていましたが、規程の改定や通知のたびに文書を手で登録し直す必要があり、登録し直すのを忘れて古い内容が残ることがありました。

要件の項目に沿って定義したこと

いちばん効いたのは参照情報の決め方です。AIのために文書を別の場所へ登録するのをやめ、担当部署がいつも載せている場所をそのまま読む形にしました。

進め方は小さく始める形にしました。お客様側の専任の担当者1名と当社のエンジニアで、週1回の定例とチャットで直しながら進め、予定より早く開発を終えています。

結果：登録作業がなくなり、資料の直すべき点も見えるようになった

AIのための文書の登録作業がなくなり、常に最新の情報で答えられるようになりました。社内の問い合わせを社員が自分で解決できるようになり、「まずAIに聞く」という使い方が広がり始めています。利用の記録から、質問の多い内容や分かりにくい資料も見えるようになり、担当部署へ資料の改善を伝えています。

自社で要件定義書を書くなら、まず参照情報の欄に「この資料は誰が改定するか」を1行足すところから始めてみてください。

設計レビューで見る順序

要件定義書が一通り埋まったら、構築に入る前に、失敗したときの戻り先、権限、対象外の宣言、運用の担当者の4つをこの順にレビューします。抜けやすく、後から直すと手戻りの大きいものから並べた順です。

抜けやすい4つの欄

1. 失敗したときの戻り先最も抜けやすい項目です。うまく流れたときの経路は誰でも書きますが、止まった件がどこへ行くかは書かれないまま実装に入りがちです。差し戻し先、通知の宛先、たまった件数の上限がすべて書かれているかを見ます。
2. 権限使ってよい操作と権限の欄が、システムごとに分けて書かれているかを見ます。読むだけで足りる処理に書き込みの権限を渡していないか、元に戻せない操作の前に人の承認が入っているかを確かめます。ここが曖昧なまま作ると、必要以上の権限で動く仕組みになります。
3. 対象外の宣言対象にするものは書かれていても、対象にしないものが書かれていない要件定義書は多くあります。対象外の欄が空なら、範囲が決まっていないのと同じです。
4. 運用の担当者作った後に誰が直すかです。参照する資料を改定する人、差し戻された件を処理する人、答えの正しさが落ちたときにAIへの指示を直す人。この3つの役割に名前が入っているかを見ます。埋まらない場合は、体制を考えるところへ戻ります。

既製ツールを入れる場合と、外部に構築を頼む場合

レビューで見る4つは、外部に頼む場合も自社で作る場合も同じです。既製のツールを入れる場合は、要件定義書がそのままツールを比べる観点になります。受け付ける入力の形式、書き込める出力先、承認の置き方、細かく分けて渡せる権限の範囲がツールごとに違うためです。

構築を外部に頼む場合は、4つまで埋めた要件定義書が、そのまま依頼先へ渡す資料になります。要件が固まらないまま複数の会社から見積を取ると、各社が別々の前提で見積もるため、金額を並べても比べられません。

関連記事：AIエージェント開発会社の選び方｜提案と見積で確かめる7項目と、契約前に決めておくこと

まとめ：AIエージェント要件定義は、NG例をOK例に書き直すところから

構築に入る前のAIエージェント要件定義では、次の点を押さえます。

• 従来のシステムの要件定義に、入力が毎回違うこと、出力が一定にならないこと、人の承認、AIが自分でシステムを操作することの4点が加わる。画面と機能の一覧では埋まらない
• テンプレートや生成AIで短くできるのは書式をそろえる時間と見直す時間で、範囲と合格ラインを決める時間は短くならない
• 埋める項目は、対象業務と適用範囲、入力、出力、AIが決めてよい範囲、使ってよい操作と権限、参照情報とその置き場所、失敗したときの扱いと記録、完成の判定基準の8つ
• 対象外を名前で書く。書かないと検証中に範囲が広がり、合格ラインに届かない
• 操作は「読むだけ」「書き込む」「元に戻せない・外へ出る」に分け、3段階目は人の承認を通す
• 参照する資料は、誰が改定し、改定がどうAIに届くかまで書く
• 記録は、1件ごとに残すものと保存期間まで書き、処理を止める役の人を決める
• 「精度90%以上」は、測る件数・一致の決め方・誤りの種類ごとに許す件数の3つに書き直し、モデルや指示を変えたら同じ件で測り直す
• 1件あたりの時間、繰り返しの回数、件数の上限、費用の上限は、8項目の外側で先に決める
• テンプレートは、決まっていない欄を見えるようにするために使う
• レビューは、失敗時の戻り先、権限、対象外の宣言、運用の担当者の順に見る

Augueでは、業務の手順を書き出すところから、要件の確定、AIエージェントの開発、現場で使い続けるための研修までを支援しており、お手元の要件定義書に足りない項目を洗い出す段階からお手伝いできます。要件をどこまで詰めてから作り始めるか迷っている段階でも構いませんので、ご興味がある方は是非ご相談ください。

自社専用のAIエージェントを作りませんか？

作るか既製品を使うか、費用の目安から相談できます。使うほど育ち、成果が続くAIエージェントの開発をご支援します。開発の進め方と事例はサービス資料でご覧いただけます。

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

よくある質問

要件定義にはどれくらいの期間をかけるべきですか？

一律の日数は出せません。長さを決めるのは業務の複雑さではなく、手順が文書になっているかと、接続先のシステムの担当者が捕まるかの2つです。手順が担当者の頭の中にある場合は、書き出す作業がそのまま期間になります。見積もる前に、対象業務の手順書が今どこまであるかを数えてください。

要件定義書は業務の担当者と情報システム部門のどちらが書きますか？

対象範囲と合格ラインは業務を回している人でないと書けず、接続先と権限は情報システム部門でないと書けません。どちらか一方が全部を書こうとすると、片方が推測になります。業務側が原稿を書き、接続と権限の欄だけ情報システム部門が埋める形にすると、埋まらずに残った欄がそのまま確認すべき論点になります。

先に要件を固めるべきか、動かしてから書くべきか、どちらですか？

入力・出力・権限の3つは先に決め、指示の書き方や参照情報の持たせ方は動かしながら詰める形が現実的です。前者は決めないと接続先も承認経路も設計できません。後者は実際の入力を通さないと判断できないため、机上で詰めても作り直しになります。

既製ツールを導入する場合も要件定義は必要ですか？

必要です。項目は変わりません。作る場合は仕様になり、買う場合はツールを比べる観点になります。とくに出力先の形式と権限の範囲は、ツール側の仕様で決まってしまうことがあるため、先に自社の要件として書いておくと、合わないツールを早い段階で外せます。

要件が後から変わったときはどう扱いますか？

変更そのものは避けられないので、記録の残し方を決めておきます。変えた項目、変えた理由、合格ラインへの影響の3つを残すと、次に精度を測ったときに数字が動いた原因を追えます。記録が無いまま項目だけ書き換えると、以前の検証結果と比べられなくなります。

社内に決まった要件定義書の書式がある場合はどうしますか？

社内の書式を使い、足りない欄だけを足せば十分です。従来の書式は画面・機能・データ項目の欄はそろっていても、対象外にする例外、使ってよい操作、誤りの種類ごとの合格ライン、記録の保存期間の欄が無いことが多くあります。足した欄が空のまま残れば、それがAIエージェントならではの決めていない点です。書式を一から作り直すと社内の審査の流れに乗らなくなるため、書式は変えずに欄を足す形のほうが通りやすくなります。

関連する記事

AIエージェント開発の進め方｜対象業務の選び方と4工程の全体像、次へ進む前に決めることAIエージェント開発を検証で終わらせないための進め方です。対象業務の選び方、4つの工程で次へ進む前に決めること、本番に乗せる判断、運用開始後に続く作業までを、順にたどれる形で整理しました。AIエージェント開発会社の選び方｜提案と見積で確かめる7項目と、契約前に決めておくことAIエージェント開発の委託先を決める前に、届いた提案書と見積で確かめる7項目をまとめました。業務の切り出し方、接続する権限、評価の合格ライン、保守の単価、契約形態、引き継ぎ資料、打ち切り条件を、質問の仕方まで扱います。PoC止まりの原因とPoCを本番化する6条件｜3つの型と撤退の線引きPoC止まりの原因を見分け、PoCを本番化するか撤退するかを判断できます。生成AIのPoCが止まる3つの型を早見表にし、本番化の前に埋める6条件をチェックリストにしました。費用と期間の見積り方も扱います。AIエージェントは既製ツールか自作か｜選び分けと、途中で切り替える見極め既製ツールで始めるか自作かを、費用・運用の手間・社内に残るものの3点で比べます。例外が設定に落ちない、処理の途中で社内システムにつなぐ、権限と記録の要件が厳しい、の3つが出たら自作へ切り替える見極め方も示します。AIエージェント内製と支援の分担｜外注との選び方と最小3人の体制AIエージェントを内製するとき、外注とどちらがよいかは5つの工程のどこを社内に置くかで決まります。内製のメリット・デメリット、要件定義と評価と保守を社内に残す分担、最小3人の体制をまとめました。