生成AI開発会社・導入支援会社の選び方｜PoCで終わらせない6つの判断軸と費用の決まり方

生成AIの支援会社を選ぶときに最初に決めるべきなのは、価格でも実績数でもなく「自社が詰まっている工程はどこか」です。試しに使ってみる段階で止まっているのか、業務に組み込む設計ができないのか、作ったものを使い続ける体制がないのか。詰まっている場所が違えば、頼むべき会社の類型も、結ぶべき契約の形も変わります。

この記事は、生成AIを一度は試した会社が、そこから本番運用まで進めるために「どの類型の支援会社に、何を求めて、どの契約形態で頼むか」を決めるためのものです。支援会社の実名比較はしません。費用についても、金額の相場ではなく決まり方のほうを扱います。

はじめにお断りしておくと、弊社は開発を担うベンダであり、後述する3類型では開発会社型に当たります。支援会社を横並びで評価して選ぶ立場ではないので、以下は開発を担う側から見た判断材料として読んでください。

先に要点を4つ挙げます。

1. 1支援会社は大きく3類型に分かれ、得意な工程がはっきり違います。自社が詰まっている工程に強い類型を選ぶのが出発点です。
2. 2生成AIを使う企業はすでに多数派ですが、効果の実感が高いのは成果物の形が決まった作業に寄っています。本番運用で差がつくのは、業務のどこに組み込むかの設計です。
3. 3支援会社に求める判断軸は6つに整理できます。どれを重く見るかは、自社がどの工程で詰まっているかによって変わります。
4. 4費用は「段階×契約形態×成果物」で決まります。検証と本番構築と運用は別の契約として見積もるのが基本です。

生成AI導入支援会社とは？3つの類型は何が違うのか#

生成AI導入支援会社とは、生成AIの活用方針づくりから業務への組み込み、運用の定着までを外部から支援する会社の総称です。ただし実態は一枚岩ではなく、もともとの出自によって得意な工程がはっきり分かれます。「生成AI開発会社」「生成AIコンサル」「AI導入支援」といった呼び方が混在しているのも、指しているものが違うからです。

大きく次の3類型に分かれます。

コンサル型は「どこに使うか」を決める工程に強い#

業務コンサルティングやDX支援を出自とする類型です。業務の棚卸し、ユースケースの洗い出し、費用対効果の試算、社内の合意形成といった、手を動かす前の工程に強みがあります。

• 得意な工程：業務の棚卸し、ユースケースの選定、投資判断の材料づくり、全社展開の計画
• 弱い工程：既存システムとの接続、データの整備、作ったものの運用
• 向く企業：どこから手を付けるかが決まっていない、あるいは社内で意見がまとまらない会社

注意したいのは、提案が出てきた後に「では作る人は誰か」という問題が必ず残る点です。実装を別の会社に出すなら、そこで要件の引き継ぎが発生します。

開発会社型は「業務に組み込む」工程に強い#

システム受託開発を出自とする類型です。既存の基幹システムや業務データと生成AIをつなぎ、実際に業務で回るものに仕上げる工程を担います。

• 得意な工程：既存システムとの連携、データの取り出しと整備、権限とログの設計、本番運用を前提とした実装
• 弱い工程：経営レベルの構想づくり、全社的な組織設計
• 向く企業：使いたい業務は見えているが、自社のデータやシステムとつなぐ手立てがない会社

注意したいのは、使いどころが決まっていない段階で発注すると、要件が固まらないまま実装に入ってしまう点です。どの業務に効かせるかの選定や社内の合意形成は、この類型の担当範囲から外れます。

ツールベンダー型は「早く使い始める」工程に強い#

自社の生成AI製品やSaaSを提供している類型です。導入までが速く、初期の負担が小さいのが利点です。

• 得意な工程：短期間での利用開始、標準的な使い方の定着支援、利用状況の可視化
• 弱い工程：自社固有の業務に合わせた作り込み、製品の想定を超える連携
• 向く企業：文書作成や議事録のように、標準機能でそのまま効果が出る業務から始めたい会社

弱点は、製品の設計思想から外れる要求が出たときに行き止まりになることです。「この製品ではできません」で止まる範囲を、契約前に確かめておく必要があります。

なお、3類型は排他ではありません。構想はコンサル型、実装は開発会社型、日常利用はツールベンダーの製品という組み合わせは現実的です。重要なのは、どの工程を誰が持つかを曖昧にしないことです。

なぜ生成AIの取り組みはPoC（概念実証）で終わるのか#

生成AIを使う企業が少ないから本番運用に届かない、という段階はすでに過ぎています。ここでいうPoC（概念実証）とは、本格的に作り込む前に小さく試して効果を確かめる工程のことで、本記事では以降「検証」と呼びます。届かない理由は、効果が出やすい作業から先に埋まり、その先の「業務に組み込む」工程で設計が必要になるからです。

使っている企業は多数派になった#

総務省の令和8年版情報通信白書によると、自社の何らかの業務で生成AIを利用していると回答した割合は、日本で86.4%でした。前年度の調査では55.2%で、大幅な上昇です。なおこの集計は、生成AIの活用方針に関する設問で「わからない」と回答した対象を除いたものです（令和8年版情報通信白書 第Ⅰ部第2章｜総務省 図表Ⅰ-2-1-6・P.24）。

活用方針のほうも進んでいます。「積極的に活用する方針である」と「活用する領域を限定して利用する方針である」を合わせた割合は、日本で68.9%（前年度49.7%）でした（同 図表Ⅰ-2-1-1・P.21）。企業規模別に見ると、大企業で74.0%、中小企業で58.1%です（同 図表Ⅰ-2-1-2・P.21〜22）。中小企業でも半数を超えており、方針を決めていること自体は差別化の要素ではなくなりました。

効果の実感は「形の決まった作業」に寄っている#

同じ白書の業務類型別の集計を見ると、様子が変わります。活用していると回答した割合がもっとも高いのは「議事録・メール作成補助」で約7割、次が「営業・販売」で約6割、「社内ヘルプデスク」で約5割でした。そして導入効果を実感すると回答した割合は「議事録・メール作成補助」が約7割で、他の類型に比べて顕著に高いという結果です（同 図表Ⅰ-2-1-7・P.24〜25）。なお効果実感のほうは、その業務類型で活用していると回答した企業に限った集計なので、左の活用率とは母数が違います。

ここから読み取れるのは、成果物の形があらかじめ決まっている作業では効果が出やすいということです。議事録は入力が音声や発言録で、出力が決まった書式の文書です。何をもって「できた」とするかが最初から共有されています。

逆に、調達や製造・生産のように複数の部署とシステムをまたぐ業務は、そもそも何を入力として渡すのかを決めるところから設計が必要になります。この設計を誰がやるのかが決まっていないと、検証は成功したのに次に進まない、という状態になります。

白書の設問はここまでで、「PoCで止まっている企業が何割か」という数字はありません。ただ、自社で進める手順そのものは生成AI導入の進め方｜PoCで終わらせず本番運用に乗せる4ステップで整理しているので、支援会社に頼む範囲を決める前に一度目を通していただくと、どこを外に出すかの判断がしやすくなります。

支援会社に何を求めるべきか？6つの判断軸#

支援会社の評価は、実績数や導入企業のロゴではなく、次の6つの軸で見てください。それぞれについて「何を聞くか」と「どんな答えが危ないか」を決めておくと、提案を並べたときに比較できます。

このうち、データ・システム連携の実装力とセキュリティ・ガバナンスはこの章で掘り下げます。契約形態は次章の費用の話と一体なのでそちらで、業務理解とPoCから本番への設計は選定の進め方と失敗パターンの章で扱います。運用・定着は両方にまたがるので、費用の3段階と失敗パターンの双方に出てきます。

データ・システム連携の実装力がいちばん見落とされる#

6軸のうち、提案段階で最も軽く扱われやすいのがデータ・システム連携です。検証の段階では担当者が手でCSVを書き出して渡せば動いてしまうため、連携の難しさが議題に上がりません。

本番運用にすると話が変わります。毎日決まった時刻にデータを取り出す、取り出せなかったときに気づく、項目が増えたときに追随する、といった仕組みが必要になります。ここを「別途お見積り」にしたままだと、検証が終わった時点で費用と期間の見通しが立たない状態に戻ります。

提案を受けるときは、既存システムの名前を挙げて「どこからどうやってデータを取るつもりか」を具体的に聞いてください。答えが出てこない場合、その支援会社は、これから入っていく先のシステム構成をまだ見ていません。

個人情報を扱う業務では「学習に使わない」の確認まで求める#

セキュリティの軸では、社内ガイドラインの有無だけでなく、支援会社が具体的な確認をしているかまで見ます。

個人情報保護委員会は令和5年に生成AIサービスの利用について注意喚起を出しており、個人情報取扱事業者に向けた注意点として、あらかじめ本人の同意を得ることなく個人データを含むプロンプトを入力し、そのデータが応答結果の出力以外の目的で取り扱われる場合には個人情報保護法の規定に違反する可能性があると指摘しています。そのうえで、そうしたプロンプト入力を行う場合には、生成AIサービスを提供する事業者が当該個人データを機械学習に利用しないこと等を十分に確認することを求めています（生成AIサービスの利用に関する注意喚起等について（令和5年6月2日）｜個人情報保護委員会）。

つまり、顧客情報や従業員情報を扱う業務に生成AIを入れるなら、使うサービスの規約まで確認する作業が必ず発生します。この確認を誰がやるのかを決めておいてください。支援会社に任せる場合は、確認した結果を文書で受け取る形にしておくと、社内の説明にも使えます。

事業者としての取り組み方を整理する際の共通の土台としては、AI事業者ガイドライン（第1.2版）があります（AI事業者ガイドライン（第1.2版）｜総務省・経済産業省）。支援会社がこのガイドラインを参照して説明できるかどうかは、ガバナンス面の成熟度を測る手がかりになります。

どの軸を重く見るか#

6軸は同じ重みではありません。自社が詰まっている工程に対応する軸を重く見てください。目安は次の3つです。

軸ごとに3段階（十分・要確認・不足）で付け、「不足」がある軸について代替案を用意するところまでを1回の検討で終えると、社内の合意が取りやすくなります。

生成AI導入支援の費用はどう決まるのか#

費用は段階と契約形態と成果物の組み合わせで決まります。生成AIだから特別な決まり方をするわけではなく、工数と責任の持ち方で決まるという点は通常のシステム開発と同じです。まず、検証・本番構築・運用の3段階を分けて見積もることを基本にしてください。

段階ごとの作業・契約形態・成果物の対応を、次の表に整理しました。

段階で契約形態を分ける理由#

検証の段階は、何が作れるかを確かめる工程です。完成物をあらかじめ定義できないため、成果物の完成を約束する請負契約には向きません。準委任で期間と体制を決め、判断基準への到達度を評価する形が実情に合います。

本番構築は、作るものが決まっているので請負にできます。ただし要件が固まりきらない部分を残したまま請負にすると、変更のたびに追加契約が必要になります。連携先が多い場合は、要件定義までを準委任、実装から請負に切り替える分け方が現実的です。

運用・定着の段階は、監視や障害対応といった決まった範囲を保守契約で受け、プロンプトや設定の改善のように作業量が読めない部分を準委任で受ける、という二本立てにすると分担が明確になります。改善まで含めて保守に押し込むと、どこまでやってもらえるのかが契約書から読み取れなくなります。

契約形態そのものの違いは、生成AIに限らずシステム開発全般で論点になります。費用の決まり方と見積もりの読み方はシステム開発費用の相場｜費用の決まり方と見積もりの見方で扱っているので、見積書を並べて比べる段階になったら参照してください。

何が費用を押し上げるのか#

同じ「生成AIの導入」でも、次の要素があると工数は増えます。見積もりの差を読むときは、この違いが織り込まれているかを確認してください。

• 連携する既存システムの数。1つ増えるごとに、接続の実装とテストが増えます
• データの状態。表記が揺れている、マスタがない、部署ごとに別の台帳がある場合は整備の工数が乗ります
• 求める精度と、誤った出力が出たときの扱い。人の確認を挟む設計にするか、自動で確定させるかで検証の量が変わります
• 対象ユーザー数と権限の細かさ。部署ごとに見せる範囲を変えるなら、権限設計とテストが増えます
• 監査やログの要件。誰がいつ何を入力したかを残す必要があるかどうか

逆に、費用を抑えたいときに削ってよいのは対象業務の幅です。工程の数を減らすのではなく、対象業務を1つに絞って全工程をやり切るほうが、本番運用まで到達しやすいというのが弊社の経験です。

選定はどう進めるか？よくある失敗パターン#

進め方そのものは、通常のベンダー選定と大きく変わりません。効くのは、比較の前に自社の判断基準を文書にしておくことです。

進め方の3ステップ#

• 対象業務を1つに絞り、成功の基準を先に決める — 「議事録の作成時間を短縮する」ではなく、「どの会議の議事録を、誰が、どこまで手直しした状態で使えれば成功か」まで書きます。この基準が、後の検証の合否判定になります
• 同じ資料で複数社に提案を求める — 口頭での説明だけで比較すると、提案の前提が会社ごとに変わってしまいます。現在の業務の流れ、対象システム、扱うデータの種類、判断基準を1つの資料にまとめて渡します
• 6軸で採点し、不足のある軸の代替案まで決める — 6つの判断軸の表をそのまま採点表として使います。すべてを満たす1社が見つからないことは普通なので、足りない軸を誰が埋めるかを決めます

選定の一般的な進め方と発注前の確認項目は失敗しないシステム開発会社の選び方｜5つの判断軸と発注前チェックリストにまとめています。生成AI固有の軸は本記事の6軸で補ってください。

避けたい3つの失敗パターン#

• ツールの導入で終わる — 全社にアカウントを配ったが、業務の手順書が変わっていない状態です。利用率は上がっても、業務の工数は減りません。アカウント配布と同時に、どの作業の手順をどう変えるかを決める必要があります
• 検証の成功条件を決めていない — 「精度が高かったので本番に進む」という判断は、後から覆ります。何%なら合格かではなく、「人が手直しする範囲がこの程度なら現場が受け入れる」という業務側の基準を先に決めてください
• 運用を担う人を決めていない — 動き始めた後、出力の質が落ちたときに気づく人がいないと、静かに使われなくなります。改善を誰の業務とするか、支援会社の契約に含めるかを、構築の見積もりと同時に決めます

たとえば、卸売業で受注メールの内容を基幹システムへ登録する作業を対象にする場合を考えます。検証では担当者が書き出したメールのテキストを使えば動きます。しかし本番では、メールサーバーからの取り込み、取引先ごとの表記の違いの吸収、登録に失敗したときの通知、担当者が修正した内容の記録までが必要になります。このうちどこまでを支援会社に任せ、どこから自社の運用で受けるかを決めておかないと、検証の後で作業が止まります。

開発会社型として、弊社は何をするのか#

弊社は開発を担う側であり、上の3類型では開発会社型に当たります。支援会社を横並びで評価して選ぶ立場ではないので、ここでは弊社が引き受ける工程をそのまま書きます。

株式会社TryWithがAIソリューション開発でお引き受けするのは、主に次の工程です。

• 対象業務の切り出しと、検証の判断基準づくり
• 既存の基幹システム・業務データとの連携の設計と実装
• 権限、ログ、データの取り扱い範囲の設計
• 本番運用を前提とした実装と、受け入れテストの支援
• 運用開始後の改善と、社内で運用できる状態への引き継ぎ

小売・店舗ビジネス向けのシステム開発や基幹システムの受託開発を手がけてきた関係で、生成AIを単体で導入するのではなく、既存の受発注・在庫・顧客データとつないで業務に載せる形での支援が中心です。構想段階から全社の計画づくりまでを担うコンサルティングが主目的の場合は、その工程に強い会社と組み合わせていただくのが合理的です。

まとめ#

生成AIの支援会社選びは、会社の優劣を比べる作業ではなく、自社が詰まっている工程を特定してから、その工程に強い類型を選ぶ作業です。コンサル型は使いどころを決める工程、開発会社型は業務に組み込む工程、ツールベンダー型は早く使い始める工程に強みがあります。

白書の数字が示しているのは、生成AIを使うこと自体はもう多数派になり、効果が出ているのは成果物の形が決まった作業に寄っているということです。ここから先の論点は、複数の部署とシステムをまたぐ業務にどう組み込むかという設計に移ります。6つの判断軸のうちどれを重く見るかは、自社がどの工程で詰まっているかによって変わります。使いどころが決まっていないなら業務理解、決まったが動かせないならデータ・システム連携の実装力、動いたが広がらないなら運用・定着です。

費用は段階と契約形態と成果物で決まります。検証は準委任、本番構築は請負または準委任、運用は準委任や保守として、3つを分けて見積もる。この分け方にしておけば、検証の結果を見てから本番の規模を決められるので、判断を後戻りさせずに進められます。

よくある質問（FAQ）#

Q. コンサル型と開発会社型の両方に頼む必要はありますか？

A. 必ずではありません。使いどころが自社で決まっていて、業務に組み込む工程だけが課題なら、開発会社型に絞って問題ありません。逆に、どの業務から手を付けるかで社内の意見が割れている場合は、構想の工程を外から支えてもらう価値があります。両方に頼む場合は、コンサル型の成果物が実装側にそのまま渡せる粒度になっているかを、契約前に確認してください。要件が言葉だけで実装の判断材料が足りないと、引き継ぎでやり直しが発生します。

Q. 検証（PoC）だけを頼むことはできますか？

A. できます。ただし、検証の段階で「本番にするなら何が必要になるか」まで整理してもらう契約にしてください。検証だけを切り離すと、動いたという結果は残っても、本番に必要な連携や運用の見通しが残りません。検証の成果物に、本番構築で必要になる作業と前提条件の洗い出しを含めておくと、次の見積もりを別の会社に依頼する場合でも使えます。

Q. 費用はいくらぐらいかかりますか？

A. 金額は対象業務と連携するシステムの数で大きく変わるため、一律の相場としてお伝えできる数字はありません。決まり方としては、検証・本番構築・運用の3段階それぞれで、工数と契約形態（準委任か請負か）と成果物の組み合わせで決まります。見積もりを比較する際は、連携する既存システムの数、データ整備の範囲、権限とログの要件、運用の担当範囲が織り込まれているかを確認してください。この4点が書かれていない見積もりは、後から増えます。

Q. 社内にエンジニアがいなくても本番運用まで到達できますか？

A. 到達できます。ただし、システムを触る人がいなくても、出力の質を判断して改善を依頼する人は必要です。この役割は現場の業務を知っている人が担うのが適しており、エンジニアである必要はありません。監視や障害対応は支援会社の運用契約に含める形で分担できます。契約時に、改善の依頼をどの窓口にどの頻度で出すのかまで決めておくと、運用開始後に止まりません。

生成AIを本番運用に乗せる設計について相談する#

株式会社TryWithは、AIソリューション開発とシステム受託開発を通じて、生成AIを既存の基幹システムや業務データとつないで本番運用に乗せる工程をご支援しています。対象業務の切り出しと検証の判断基準づくりから、連携の実装、権限とログの設計、運用の引き継ぎまで、開発を担う立場でお引き受けします。サービスの詳細はAIソリューション開発のページをご覧ください。

どの業務から始めるか、既存システムとどうつなぐかという論点の整理は、30分のオンライン相談からご一緒できます。

お問い合わせはこちら