AIエージェント開発会社の選び方｜PoCで止めず本番運用まで任せる7つの確認点とタイプ別比較
本記事は、AIエージェント開発を提供するスパイスファクトリー株式会社（以下、当社）が作成しています。当社も依頼先の候補の一社であるため、特定の企業を順位付けすることはせず、依頼先を「タイプ」に分けて、それぞれの特徴と向き・不向きを整理しました。当社がどのタイプに当たるかも明記しています（2026年10月時点の情報をもとに作成）。
業務を任せられるAIエージェントを外部の会社に開発してもらうとき、難しいのは、PoC（概念実証）で動いたものを、本番の業務で使い続けられるものにすることです。Gartnerは、エージェント型AIのプロジェクトの40%超が、コストの増大、ビジネス価値の不明確さ、リスク管理の不備を理由に、2027年末までに中止されると予測しています（2025年6月25日の発表（新しいタブで開きます）。実績ではなく予測です。2026年10月28日確認）。
本記事では、依頼先のタイプ別の比較と、PoCで止めないために依頼先へ確かめる7つの点を、「依頼先へ聞く質問」「答えの見分け方」「契約前に見本を確認したい成果物」とあわせて1ページにまとめます。費用の考え方と、よくある質問も載せています。
| 知りたいこと | この記事の結論 |
|---|---|
| 依頼先のタイプ | 本記事では、外部の依頼先を4タイプ（大手SIer・総合ITベンダー／AIエージェント製品・プラットフォームのベンダー／伴走型の開発会社／AIコンサルティング・PoC支援会社）に整理し、内製を加えた5つの選択肢で比べた。任せたい業務が製品の枠内で完結するか、自社固有のルールや複数システムの連携が要るか、本番運用を誰が担うかで選ぶ |
| PoCで止めないために確かめる点 | 任せる範囲の段階／PoCの合格基準／権限と承認／停止と復旧／本番運用（AgentOps）／移管と内製化／データと「やらない判断」の7つ。項目ごとに依頼先へ聞く質問を付けた |
| 答えの見分け方 | 質問への答えに、成果物の名前と見本があるか、誰が決めるかが明確か、数字や条件で決めるか |
| 費用の考え方 | 診断・PoC・本番構築の費用と、運用・AIモデル・クラウドの利用料という継続する費用を分けて比べる。利用料の課金方式と、各見積もりに含まれる範囲を確かめる |
| 最初の一歩 | 対象業務を1つに絞り、任せる範囲・合格基準・責任者を決める診断から始めると、PoCの後の判断がしやすい |
| 筆者（当社）の位置づけ | 当社スパイスファクトリーは③伴走型の開発会社。エージェント適合性アセスメント、他社や社内で作ったPoCの本番化診断、本番構築、運用・内製化移管を提供している。本記事で紹介する当社の実績は、自社プロダクトの対象部門での本番運用 |
本記事で使う言葉
| 言葉 | 本記事での意味 |
|---|---|
| AIエージェント | 大規模言語モデル（LLM）が指示の意図を解釈し、社内システムやAPIなどの道具（ツール）を呼び出して、業務の一部を実行する仕組み。本記事では、データの読み取り、下書きの作成、承認を経た登録や送信などを、業務に応じた段階で担うものを扱う |
| PoC（概念実証） | 本格的に開発する前に、対象業務で使えるかを小さく試して確かめる取り組み |
| 評価ケース（ゴールデンセット） | AIエージェントを評価するための入力と、期待する応答・操作・人の承認に回すかどうかなどの基準の組。業務の有識者と基準を合意しておき、PoCの合格判定や、本番に出す前の確認に使う |
| AgentOps（エージェントの運用） | AIエージェントを本番で動かし続けるための運用。品質とコストの監視、AIモデルやプロンプトの更新、障害時の停止と復旧、現場の声を受けた改善を含む |
| 内製化移管 | 外部の会社が作って運用してきたAIエージェントを、自社のチームが運用・改善できるように引き継ぐこと |
業務を任せられるAIエージェントを開発してくれる会社には、どんなタイプがある？
本記事では、比較しやすくするために、支援の特徴に着目して外部の依頼先を4つのタイプに分け、内製を加えた5つの選択肢を比べます。業界で決まった分類ではなく、本記事独自の整理です。支援の範囲はタイプの間で重なることがあるため、「どのタイプの強みを、どこまで持っているか」を見るための目安として使い、各社がどこまで担うかは個別に確かめてください。各タイプの「本番運用の担い方の例」も一例で、実際は会社や契約によって異なります。
①大手SIer・総合ITベンダー
- 主な支援内容：構想策定から開発、基幹システムとの連携、運用保守までを大規模な体制で担う。AIエージェントの基盤や業務別のソリューションを持つ会社もある
- 向いているケース：全社規模で展開したい場合。多数の基幹システムとの連携や、長期の運用保守を一社にまとめたい場合
- 本番運用の担い方の例：運用保守の契約として、依頼先が継続して担う
- 確認したい点：1つの業務から小さく始められるか、最小の発注範囲はどこからか。自社固有の業務ルールや承認フローをどこまで作り込めるか
②AIエージェント製品・プラットフォームのベンダー（その導入支援会社を含む）
- 主な支援内容：自社のAIエージェント製品や、業務アプリ・クラウドに組み込まれたエージェント機能を提供し、設定・導入・定着を支援する
- 向いているケース：任せたい業務が、すでに使っている製品のデータと権限の範囲で完結する場合。早く小さく試したい場合
- 本番運用の担い方の例：製品の管理画面・ログ・監視機能を使って自社の担当者が運用し、ベンダーのサポートが支える
- 確認したい点：任せたい業務が製品の枠内で収まるか。複数のシステムをまたぐ処理や、自社固有の承認フローを組めるか。データの保存場所と、利用料金の体系
③伴走型の開発会社
- 主な支援内容：業務の分解と設計から、開発、本番運用（AgentOps）、内製化移管までを受託で担う
- 向いているケース：自社固有の業務ルール・承認フロー・複数システムをまたぐ処理を作り込み、本番運用まで任せたい場合。他社や社内で作ったPoCを本番化したい場合
- 本番運用の担い方の例：依頼先が運用を引き受け、自社の体制が整ったら段階的に移管する
- 確認したい点：体制の規模と、大規模な基幹システムとの連携にどこまで対応できるか。運用の契約形態と、移管できる範囲
④AIコンサルティング・PoC支援会社
- 主な支援内容：AI活用の構想、対象業務の選定、投資判断、PoCの設計と評価、社内の推進体制づくりを支援する。発注者の立場で開発会社の選定を支援する会社もある
- 向いているケース：何から始めるか、どの業務に投資するかから相談したい場合。社内で推進体制をつくりたい場合
- 本番運用の担い方の例：運用は自社か実装を担う会社が持ち、コンサルティング会社は判断や体制づくりを支える
- 確認したい点：本番の実装と運用まで担えるか。担わない場合は、本番化の設計を自社で引き取るか、実装を担う会社と組むことになる
⑤内製（社内の開発チーム）
- 主な支援内容：クラウドのAI基盤や開発ツールを使い、自社のチームで設計・開発・運用する。必要に応じて外部の内製化支援を受ける
- 向いているケース：開発チームがあり、AIエージェントを継続して作り続ける計画がある場合
- 本番運用の担い方の例：自社のチームが運用し、必要に応じて外部の支援を受ける
- 確認したい点：評価ケースの作成、権限の設計、障害時の対応、AIモデルの更新を担える人を、社内で確保できるか
当社スパイスファクトリーは③のタイプです。任せたい業務が、すでに使っている業務アプリやクラウドの枠内で完結するなら②の製品が、全社規模で多数の基幹システムとの連携を一括で任せたいなら①が、第一候補になることもあります。
公開情報で依頼先のタイプを見分けるポイント
依頼先の候補が挙がったら、各社の公開ページで次の点を確認すると、どのタイプの強みを持っているかが見えてきます。
- 支援の範囲として、PoC・本番構築・運用・内製化移管のどこまでが書かれているか
- 運用（品質とコストの監視、AIモデルの更新、改善）のメニューや成果物の説明があるか
- 自社の製品が前提か、製品を問わないか。使えるAIモデルやクラウドを選べるか
- 実績の書き方。外部の顧客での本番運用か、PoCか、自社での運用かが書き分けられているか
- 費用の目安を公開しているか。公開している場合は、その前提条件
AIエージェントがPoCで止まるのはなぜ？依頼先選びで先に手を打てること
本記事では、PoCの後の本番化でつまずきやすい課題を、「品質・セキュリティ」「運用の継続」「責任・ガバナンス」「データ」の4つの「壁」に整理します。どの壁についても、必要な対応と担当者を、依頼先を選ぶ段階で確かめておくことができます。
品質・セキュリティ
- PoCの後に起きること：本番のデータでは数字を間違える。外部から来る文章に紛れた指示（プロンプトインジェクション）で想定外の動きをする。誤った操作のリスクを説明できず、稟議が通らない
- 依頼先に確かめる点：2. PoCの合格基準／3. 権限と承認
運用の継続
- PoCの後に起きること：新しいAIモデルへの切り替えやプロンプトの修正の後に、必要な品質を満たすかを確かめる手順がなく、更新の判断ができない。切り替えを避けて、古い構成のまま止まる
- 依頼先に確かめる点：5. 本番運用（AgentOps）／6. 移管と内製化
責任・ガバナンス
- PoCの後に起きること：何をAIに任せてよいか、誤作動のときに誰が止めるかが決まらず、情報システム部門や法務の承認が得られない
- 依頼先に確かめる点：1. 任せる範囲の段階／4. 停止と復旧
データ
- PoCの後に起きること：参照するデータの品質、アクセス権限、システムとの接続が整っておらず、本番の業務で使えない
- 依頼先に確かめる点：7. データと「やらない判断」
次章では、この4つの壁を、依頼先に確かめる7つの点と具体的な質問に落とし込みます。AIに任せる領域・コードで確実に制御する領域・人が判断し承認する領域の分け方は、当社の講演資料「なぜ、AIエージェントはPoCで止まるのか（新しいタブで開きます）」で解説しています。
PoCで止めないために、依頼先に確かめる7つの点
見積もりの金額や技術の説明だけで比べると、本番運用の前提が違う提案を並べて比べることになりがちです。次の7つを初回の打ち合わせで質問し、答えが具体的かどうかで見分けることをおすすめします。答えを聞くときは、次の3つを目安にしてください。
- 成果物の名前と見本があるか：「しっかり設計します」ではなく、何という文書や仕組みを、いつ納めるかが言えるか
- 誰が決めるかが明確か：依頼先が決めることと、自社の業務の担当者が決めることが分けられているか
- 数字や条件で決めるか：「良さそうなら次へ」ではなく、合格ラインや次の段階に進む条件が決まっているか
各項目の「契約前に見本を確認したい成果物」は、契約の前に、見本と記載する項目、作る担当、納める時期を確かめておきたいものです。対象業務に合わせた成果物は、契約で合意した作成範囲・担当・納品時期に従い、診断・設計・検証・運用などの各工程で作ります。
1. 任せる範囲を段階で決めているか（自律性の設計）
最初から全自動で実行させるのではなく、「読み取る→下書きする→人の承認を経て実行する→自律的に実行する」と段階を上げていく設計を提案できるかを確かめます。間違えたときのダメージ（金額・信用・法令・取り消せるか）は業務ごとに違い、どの段階から始めるかが決まらないと、PoCで何を評価するかも、どの権限を与えるかも決まりません。
- 依頼先へ聞く質問：「この業務は、どの段階から始めることを提案しますか。次の段階に進む条件は何ですか」
- 具体的な答えの例：業務を工程に分け、工程ごとに「コード（決まった処理）／AI／人」の担当を示した図を出す。次の段階に進む条件を、一定期間の評価結果や、承認での差し戻しの割合などで説明する
- 注意したい答え：「最初から全自動にできます」「AIが判断するので、工程を分ける必要はありません」
- 契約前に見本を確認したい成果物：工程ごとの役割分担の図、段階（自律性）の設計書
2. PoCの合格基準を、業務の評価ケースで決めるか（評価）
PoCを始める前に、合格ラインと、本番化を判断する日と判断する人を決めているかを確かめます。評価ケースには、通常のケースだけでなく、判断が分かれる境界・例外のケースと、実行してはいけない入力（攻撃ケース）を含めます。通常のケースだけで試すと、デモは成功しても本番での弱点が残ります。
- 依頼先へ聞く質問：「評価ケースは、誰が、何件、どんな内訳で作りますか。合格ラインと、本番化を判断する日と判断する人は、PoCの前に決めますか」
- 具体的な答えの例：業務の有識者と一緒に正解を合意した評価ケースを作り、それを受け入れの基準にする。Go（本番化）・条件付きGo・No-Go（見送り）の条件を、PoCの前に文書にする
- 注意したい答え：「まず触ってみて、良さそうなら本番に進みましょう」。精度の保証だけを約束し、評価の方法の説明がない（AIの出力は揺れることがあるため、保証の言葉より、評価の方法と合格ラインの合意が判断材料になる）
- 契約前に見本を確認したい成果物：PoCの計画書、評価ケース、評価レポート。あわせて、それぞれを作る範囲・担当・時期
PoCの計画書には、少なくとも次の項目が書かれているかを確かめてください。
- 対象の業務と工程、任せる段階
- 評価ケースの件数と内訳（通常・境界と例外・攻撃）
- 合格ライン（数値）と、その決め方
- 本番との違い（使うデータ、処理の件数、連携するシステム）
- 1件あたりのコスト（AIモデルの利用料など）の測り方
- 本番化を判断する日と、判断する人
- Go・条件付きGo・No-Goそれぞれの条件と、その後の進め方
- No-Goになったときに手元に残る成果物
Go・条件付きGo・No-Goの判定は、たとえば次のように決めておきます（本記事の例）。数値の基準と判定する人は、対象業務のリスクに応じて、PoCを始める前に合意してください。
| 判定 | 判断の条件と、その後の進め方の例 |
|---|---|
| Go | 業務の品質・コスト・権限と承認・停止と復旧について合意した条件を満たし、責任者が承認した範囲で本番化する |
| 条件付きGo | 条件を満たした業務・利用者・実行の権限に範囲を絞って本番化する。残る課題の担当者、対応の期限、再判定の日を決める |
| No-Go | 重要な条件を満たさない、または重大なリスクへの対策が整わないため、本番化を見送る。再検証するか、方式を変えるか、終了するかを決める |
3. 権限と承認を、どこで・何で効かせるか（権限・承認）
AIエージェントに与える権限を業務に必要な最小限にし、登録・送信・支払いなど取り消しにくい操作の前に、人の承認かコードによる検証を入れる設計かを確かめます。あわせて、数値の計算や権限の判定といった間違えてはいけない処理を、AIに任せるのか、コードに任せるのかも聞いておきます。
- 依頼先へ聞く質問：「AIエージェントは、どのシステムに、どの権限でアクセスしますか。確定する操作の前に、誰が何を確認しますか」「数値の計算や権限の判定は、AIとコードのどちらが行いますか」
- 具体的な答えの例：計算・権限の判定・確定する操作はコードに固定し、AIは意図の解釈や文章化を担う、と担当を分けて説明できる。メールや問い合わせ、Webページなど外部から来る文章に紛れた指示への対策として、入力をデータとして区切る、権限を絞る、出力を検証する、人が承認する、攻撃ケースで評価する、といった対策を重ねる考え方を説明できる
- 注意したい答え：「プロンプトで禁止しているので大丈夫です」だけで、仕組みでの対策の説明がない
- 契約前に見本を確認したい成果物：権限の一覧（どのツールに何を許すか）、承認の流れの設計
4. 止める人・止め方・戻し方が決まっているか（停止・復旧・監査）
誤作動に気づいたとき、誰が、どの手順で止め、どこまで元に戻すかを、本番の前に決めて実装しているかを確かめます。止める人と戻す人が決まっていないまま本番に出すと、事故が起きたときの対応が遅れます。情報システム部門や法務、監査への説明にも、この設計が要ります。
- 依頼先へ聞く質問：「動作を止める手段はありますか。止める人と、元に戻す人は誰ですか」「実行の記録（監査ログ）には何が残り、どれくらいの期間保存しますか」
- 具体的な答えの例：責任者・承認者・停止者・復旧者を表にした責任分界表と、停止と切り戻しの手順書を、本番の前に作る。同じ処理が二重に実行されないようにする仕組みや、誤って実行した処理を打ち消す手順を説明できる
- 注意したい答え：「止める必要が出たら、そのときに相談しましょう」
- 契約前に見本を確認したい成果物：責任分界表、AIのリスクを洗い出した台帳、停止・復旧の手順書、監査ログの仕様
5. 本番運用（AgentOps）を、誰が何を見て続けるか（運用）
リリースの後の品質とコストの監視、AIモデルの更新、現場の声を評価ケースに反映する改善を、誰が、どの契約で担うかを確かめます。あわせて、現場で使われ続けているか（利用の割合や、作業時間の変化）を誰が見るかも確かめます。AIモデルは新しい世代が短い間隔で出てきます。プロンプトやモデルを変えると、挙動が変わることがあります。変更の前後を評価ケースで比べ、業務上重要な変化がないかを確かめる手順が必要です。
- 依頼先へ聞く質問：「プロンプトやAIモデルを変えるとき、何を通してから本番に出しますか」「毎月、何を報告してもらえますか。AIモデルの利用料は、どう見える化し、上限をどう決めますか」「対象業務のうち何件で使われたか、承認や手直しを含めた作業時間がどう変わったかを、何で測りますか。現場からの改善の要望は、誰が受け取り、いつ反映しますか」
- 具体的な答えの例：プロンプト・モデル・設定を版として管理し、評価ケースに合格しない版は本番に出せない仕組みがある。品質とコストの月次の報告と、モデルを更新する手順（比較→評価→切り替えの提案→承認）を説明できる。利用の割合の数え方、承認や手直しを含めた作業時間、改善の担当と頻度を合意し、運用の報告に含める
- 注意したい答え：納品後は障害の対応だけで、品質の監視やAIモデルの更新の進め方が決まっていない
- 契約前に見本を確認したい成果物：運用の手順書、月次の品質・コストの報告書の見本、モデルを更新する手順
6. 移管と内製化ができる形で納品されるか（移管・内製化）
プロンプト、評価ケース、監査ログ、設定、運用の手順を、自社や別の会社が引き継げる形で受け取れるかを確かめます。特定のAIモデルやクラウドへの依存をどこまで抑えるか、移管できる範囲はどこまでかを、契約の前に合意しておきます。
- 依頼先へ聞く質問：「契約が終わったとき、何を、どんな形式で受け取れますか」「別のAIモデルや、自社のクラウド環境に移すことはできますか。その範囲はどこまでですか」「内製化するとき、どんな支援がありますか」
- 具体的な答えの例：移管の対象（コード、プロンプト、評価ケース、ログ、運用の手順）と形式、知的財産と再利用の扱い、自社のチームへの引き継ぎの進め方を説明できる。移管できる範囲は案件の要件に応じて合意する、と線を引いて説明する
- 注意したい答え：移管や他のAIモデルへの切り替えの範囲が、契約の前に説明されない
- 契約前に見本を確認したい成果物：移管の対象の一覧、知的財産と再利用の扱いを決めた契約の条項、内製化の計画
7. データの準備状況と「やらない判断」を説明できるか（データ・適合性）
参照するデータの品質・アクセス権限・APIの有無を確かめたうえで、「まずデータの整備が先」「既存の製品で足りる」「この工程はAIエージェントに向かない」と率直に言ってくれるかを確かめます。開発ありきで進むと、PoCの後に「本番のデータでは使えない」と分かることがあります。
- 依頼先へ聞く質問：「この業務は、AIエージェントに向いていますか。向かない部分はどこですか」「参照するデータが整っていない場合、どう進めますか」
- 具体的な答えの例：間違えたときのダメージと、曖昧さの度合い（自然言語の解釈や、決まった形でない入力を含むか）で向き・不向きを説明する。データの整備や、既存の製品の活用を先に提案することがある
- 注意したい答え：業務やデータを確かめる前に、開発を前提にした見積もりが進む
- 契約前に見本を確認したい成果物：データの準備状況の診断結果、工程ごとの向き・不向きの判定
7つの点の一覧（チェックリスト）
| 確かめる点 | 依頼先へ聞く質問（1つに絞るなら） | 契約前に見本を確認したい成果物 |
|---|---|---|
| 1. 任せる範囲の段階 | 依頼先へ聞く質問（1つに絞るなら）どの段階から始め、何を満たしたら次の段階に進みますか | 契約前に見本を確認したい成果物工程ごとの役割分担の図、段階の設計書 |
| 2. PoCの合格基準 | 依頼先へ聞く質問（1つに絞るなら）評価ケースの内訳と合格ライン、判断日と判断者を、PoCの前に決めますか | 契約前に見本を確認したい成果物PoCの計画書と評価ケースの見本 |
| 3. 権限と承認 | 依頼先へ聞く質問（1つに絞るなら）確定する操作の前に、誰が何を確認しますか。計算や権限の判定はAIとコードのどちらが行いますか | 契約前に見本を確認したい成果物権限の一覧、承認の流れの設計 |
| 4. 停止と復旧 | 依頼先へ聞く質問（1つに絞るなら）止める人と戻す人は誰で、どんな手順ですか | 契約前に見本を確認したい成果物責任分界表、停止・復旧の手順書、監査ログの仕様 |
| 5. 本番運用（AgentOps） | 依頼先へ聞く質問（1つに絞るなら）プロンプトやモデルを変えるとき、何を通してから本番に出しますか | 契約前に見本を確認したい成果物運用の手順書、月次報告の見本 |
| 6. 移管と内製化 | 依頼先へ聞く質問（1つに絞るなら）契約が終わったとき、何を、どんな形式で受け取れますか | 契約前に見本を確認したい成果物移管の対象の一覧、知的財産の扱いの条項 |
| 7. データと「やらない判断」 | 依頼先へ聞く質問（1つに絞るなら）この業務で、AIエージェントに向かない部分はどこですか | 契約前に見本を確認したい成果物データの診断結果、向き・不向きの判定 |
依頼する前に、社内で決めておきたいこと
次の項目が決まっていると、どのタイプの依頼先でも、初回の打ち合わせが具体的になります。すべてが決まっていなくても相談はできます。分からない項目は「分からない」と伝えることも大切です。
| 決めておきたいこと | 内容 | 何の判断に使うか |
|---|---|---|
| 対象の業務 | 内容どの業務の、どの工程を任せたいか。月の件数と、1件あたりにかかっている時間 | 何の判断に使うか効果の見積もりと、任せる段階の設計 |
| 間違えたときのダメージ | 内容金額、信用、法令への影響と、取り消せるかどうか | 何の判断に使うか承認を入れる工程と、どの段階から始めるか |
| データ | 内容参照するデータの場所、品質、アクセス権限、APIの有無 | 何の判断に使うかすぐに着手できるか、データの整備が先か |
| 責任者 | 内容業務の責任者、承認する人、止める人 | 何の判断に使うか責任分界と、本番化を判断する人 |
| 既存のPoC | 内容あれば、作った会社（他社・社内）と、止まっている理由 | 何の判断に使うかPoCを活かすか、作り直すか |
| 運用の担い手 | 内容本番の後、自社で運用するか、依頼先に任せるか、将来は内製化するか | 何の判断に使うか契約の組み立てと、移管の計画 |
| 社内の規程 | 内容個人情報や機密情報をAIモデルの提供会社に送れるか、データをどこに保存できるか | 何の判断に使うか使えるAIモデルとクラウドの選び方 |
| 判断の期限 | 内容誰が、いつまでに、何を判断したいか | 何の判断に使うか診断の範囲と、成果物の形 |
AIエージェント開発の費用はどう考える？段階別の比べ方
AIエージェント開発の費用は、対象の業務の数、連携するシステムの数、任せる段階、セキュリティの要件などによって大きく変わります。最初から全体の金額を出すのは難しいため、本記事では次のように段階を分け、前の段階の結果を見てから次の投資を判断する進め方をおすすめします。
| 段階 | 内容 | 費用を左右するもの |
|---|---|---|
| 1. 初回の相談 | 内容課題の整理、向き・不向きの見立て | 費用を左右するもの無料の相談窓口を設けている会社もある |
| 2. 診断（アセスメント） | 内容業務の分解、役割分担、データの準備状況の診断、評価ケースの初版、リスクの洗い出し、概算の費用対効果 | 費用を左右するもの対象の業務の数、連携するシステムの数、業務の有識者が参加できる頻度 |
| 3. PoC | 内容評価ケースによる検証、本番化の判断 | 費用を左右するもの評価ケースの数、本番に近いデータを使えるか |
| 4. 本番構築 | 内容AIエージェント本体、管理の仕組み（版の管理・評価・ログ）、既存システムとの連携、段階的な展開 | 費用を左右するもの連携するシステムの数、任せる段階（承認付きの実行より先に進むか）、セキュリティ審査 |
| 5. 運用（AgentOps） | 内容品質とコストの監視、AIモデルの更新、改善、内製化の支援 | 費用を左右するもの対象の業務の数、評価の頻度、変更の量 |
| 各段階：AIモデル・クラウドの利用料 | 内容PoC・本番構築・運用の各段階で、どの利用料が、どの条件で発生し、見積もりに含まれるかを確かめる | 費用を左右するもの課金の方式、契約のプラン、処理の件数と量、使うAIモデル、予算の上限 |
依頼先を比べるときは、初期の金額だけでなく、運用とAIモデルの利用料を含めた年間の費用で比べてください。あわせて、見積もりに含まれる作業と成果物をそろえること、段階ごとに継続するか見送るかを判断できる契約かどうかも確かめておくと安心です。
当社の費用の目安（価格レンジ）は、無料のホワイトペーパー（新しいタブで開きます）に掲載しています。
スパイスファクトリーのAIエージェント開発（③伴走型の開発会社）
当社は、「曖昧さはAIに。確実さはコードに。重要な操作は、人の承認に。」を設計の原則に、決定論×LLMのハイブリッド設計と評価駆動の運用で、監査できて、止められて、改善し続けられるAIエージェントを本番運用まで引き受ける「AIエージェント開発（新しいタブで開きます）」を提供しています。本記事の7つの点に、当社は次のように取り組んでいます。
- 決定論×LLMのハイブリッド設計：計算・権限の判定・確定する操作は決定論的なコードに固定し、意図の解釈と言語化だけをLLMに委ねます。数値の計算の経路からLLMを外し、ハルシネーション（AIがもっともらしい誤りを出力すること）による数字の誤りを構造的に締め出します。プロンプトインジェクションには、外部から来る文章をデータとして区切る、最小権限、出力の検証、人の承認、攻撃ケースの評価を重ねる多層防御で、影響を抑えます。
- 評価ケースに合格しない版は、本番に出さない：構築の初期に、通常・境界・攻撃のケースを含むゴールデンセットを、お客様の業務の有識者と共同で作り、受け入れの基準にします。プロンプト・モデル・設定は版として管理し、評価に合格しない版は公開できない仕組みを、担当者の注意力ではなくコードで強制します。
- 任せる範囲は段階で設計する：「読み取る→下書きする→承認付きで実行する→自律的に実行する」の段階で、どこから始め、何が確認できたら次へ進むかを設計します。完全自律で確定する操作まで任せる構成は、最初の段階では推奨していません。
- 監査できて、止められる：最小権限、すべての実行を残す監査ログ、いつでも止められる停止スイッチ（kill switch）を備えます。責任者・承認者・停止者・復旧者を定めた責任分界表と、OWASP Top 10 for LLM Applications や総務省・経済産業省の「AI事業者ガイドライン」等を参照したAIリスク台帳を納品します。
- 段階ごとに完結する4つのメニュー：「エージェント適合性アセスメント」「PoC本番化診断」「エージェント本番構築」「エージェント運用・内製化移管」の4つで、各段階の終わりに継続・撤退をご判断いただけます。PoC本番化診断は、他社が開発したPoCや社内で作ったPoCも持ち込めます。
- 移管できる形で管理する：プロンプト・評価ケース・監査ログは移管可能な形式で管理し、お客様のクラウド環境への展開や、内製化への移管まで見据えた構成にします。対応するモデル・クラウド・移管の範囲は、案件の要件に応じて個別に合意します。
自社での本番運用
当社は、全社で利用する自社開発の営業DX基盤の上で、営業データの分析Q&A、見込み顧客へのメールの下書き、名刺の読み取りなど、複数のAIエージェント・AI機能を対象部門で本番運用しています。数字はLLMに作らせずコードが集計する設計で運用しており、AIモデルの世代交代の際も、評価ケースによる確認を通して、業務を止めずに切り替えてきました。いずれも自社のプロダクトでの運用です。設計の考え方は、オピニオン記事「LLMに数字を作らせない（新しいタブで開きます）」「AIエージェントは「作って終わり」にできない（新しいタブで開きます）」で公開しています。
当社より他のタイプが向くケース
- 任せたい業務が、すでに使っている業務アプリやクラウドのデータと権限の範囲で完結する場合は、②の製品のエージェント機能が向いています。当社の診断でそう判断した場合は、その旨を率直にお伝えします
- 問い合わせへの回答が主な目的であれば、チャットボット製品も比較の対象になります。必要な機能、導入の作業、継続する費用をそろえて比べてください
- 全社規模で、多数の基幹システムとの連携と長期の運用保守を一社にまとめて任せたい場合は、①が第一候補になることもあります
参照するデータの整備が先に必要と判断した場合は、AIエージェントの開発を急がず、データの整備やAPI化を先に進める計画をご提案します。
当社への無料相談は、この業務はAIエージェントに向いているか、止まっているPoCは本番化できるかを見立てる30分の適合性スクリーニングです。AIエージェント開発の無料相談（新しいタブで開きます）からお申し込みください。設計の原則や業務の判定表、検討に使えるチェックリストは、ホワイトペーパー（新しいタブで開きます）にまとめています。
まとめ
業務を任せられるAIエージェントの依頼先を、本記事では外部の4タイプ（大手SIer・総合ITベンダー、AIエージェント製品・プラットフォームのベンダー、伴走型の開発会社、AIコンサルティング・PoC支援会社）と内製の、5つの選択肢に分けて整理しました。どのタイプが合うかは、任せたい業務が製品の枠内で完結するか、自社固有のルールや複数システムの連携が要るか、本番運用を誰が担うかで変わります。
PoCで止めないためには、依頼先を選ぶ段階で、任せる範囲の段階、PoCの合格基準、権限と承認、停止と復旧、本番運用（AgentOps）、移管と内製化、データと「やらない判断」の7つを確かめてください。答えに成果物の名前と見本があり、誰が決めるかが明確で、数字や条件で決める依頼先であれば、PoCの後の判断がしやすくなります。
当社では、「この業務はAIエージェントに向いているか」「止まっているPoCは本番化できるか」という段階からご相談をお受けしています。AIエージェント開発の無料相談（新しいタブで開きます）から、お気軽にお問い合わせください。
