AI開発会社の選び方完全ガイド｜7つのチェックポイント

「生成AI開発」を掲げる会社は、ここ数年で驚くほど増えました。しかし実態は、受託開発の看板をそのままに、AI案件だけ名前を変えて受けている会社も少なくありません。発注してから「思っていたのと違う」とならないために、契約前にどこを見るべきかを整理します。

実績は「AI」ではなく「自社と近い課題」で見る

「AI開発実績多数」という言葉だけでは、自社の課題に対応できるかは判断できません。チャットボット構築の実績しかない会社に、社内文書を横断検索するRAGシステムを頼んでも、勝手が異なりうまくいかないことがあります。確認すべきは実績の「量」ではなく、自社が実現したいことと技術的に近い案件をどれだけ手がけてきたかです。

商談の際は、類似案件の技術構成やつまずいたポイントを具体的に聞いてみましょう。抽象的な成功事例しか語れない場合、実際の手を動かしていない、あるいは別の技術者が担当していた可能性があります。

また、業種が近いかどうかも見落とされがちな観点です。同じ「文書検索AI」でも、製造業の技術文書と、医療機関のカルテのように専門用語や機密性の性質が異なる業界では、必要となる前処理や配慮が変わってきます。自社と近い業種での経験があるかも、あわせて確認しておくと安心です。

業種によって求められる要件は大きく異なる

製造業であれば、図面や仕様書に含まれる専門用語・型番を正確に読み取る精度が求められ、誤読が現場の安全に関わることもあります。金融業界では、監査対応を見据えたログの保持や、回答の根拠を追跡できる仕組みが重視されます。小売・EC業界では、繁忙期のアクセス集中に耐える設計や、顧客に直接見せる文面としての自然さが問われるなど、業種ごとに「何を優先して設計するか」が変わってきます。

こうした業種特有の要件は、実際にその業界のプロジェクトを経験していないと見落としがちです。商談の際は「弊社の業界特有の事情として〇〇があるが、対応した経験はあるか」と具体的に聞いてみることで、開発会社の理解度を測ることができます。

実績の「量」で選んでしまう失敗パターン

よくある失敗が、有名企業のロゴが並ぶ実績ページの見栄えだけで発注先を決めてしまうケースです。契約後に蓋を開けてみると、その会社の強みは実は別の技術領域にあり、担当した案件も企画段階の壁打ちに留まっていた、というようなことが起こります。ロゴの知名度と、自社が依頼したい内容への適合度は必ずしも比例しません。

開発体制と窓口の役割分担を確認する

AI開発は仕様が固まりにくく、進めながら要件が変わることが珍しくありません。そのため、誰が技術的な判断をし、誰が進捗を報告するのかという体制が曖昧だと、認識のズレが積み重なっていきます。営業担当と実際の開発者が別で、間に入る窓口の技術理解が浅いケースは特に注意が必要です。

契約前の段階で、プロジェクト期間中の定例ミーティングの頻度や、緊急時にどのルートで連絡が取れるかを確認しておくと、後々のコミュニケーションコストを抑えられます。

営業と開発が分業している会社への対処法

大手や中堅の開発会社では、営業担当と実装を担うエンジニアが別人であることが一般的です。それ自体は珍しくありませんが、技術的な質問をした際に営業担当が持ち帰って確認する場面が多いようであれば、実際のプロジェクト進行中も同様のタイムラグが発生する可能性があります。可能であれば初回の商談から技術担当者の同席を依頼し、その場で技術的なやり取りができるかを確認しておくとよいでしょう。

エスカレーションフローを事前に確認する

プロジェクトが順調に進んでいるときは体制の弱さが表面化しませんが、トラブルが起きたときに真価が問われます。担当者が対応しきれない問題が発生した場合、誰にエスカレーションされ、どれくらいの時間で一次回答が来るのか。この「有事の動き方」を契約前に確認しておくことで、実際に問題が起きたときの対応の速さをある程度予測できます。

見積もりの内訳と前提条件を確認する

AI開発の見積もりは、モデルの選定やデータの前処理にかかる工数が読みにくく、他の受託開発より変動要因が多いのが実情です。総額だけで比較するのではなく、どの作業にどれだけの工数を見込んでいるか、内訳を開示してくれるかどうかを見てください。

あわせて、見積もりが「どのデータ量・どの精度目標を前提にしているか」も確認しましょう。前提条件が曖昧なまま契約すると、想定外の追加費用が発生しやすくなります。

工程別内訳で特に見落とされやすい項目

要件定義や実装の工数は見積もりに明記されやすい一方、データの前処理（クレンジング、フォーマット統一、アノテーション）や、精度検証・チューニングの工数は軽視されがちです。この2つの工程は実際には最も時間がかかることが多く、ここが薄い見積もりほど後から工数超過が発生しやすい傾向にあります。

前提条件が崩れたときの対応を確認する

見積もり時点で伝えていたデータ量や品質が、実際に着手してみると想定と異なっていた、というのはAI開発ではよく起こります。この場合に、追加費用が即座に発生するのか、まずは影響範囲をすり合わせたうえで対応方針を協議するのか、進め方をあらかじめ確認しておくと、着手後のトラブルを減らせます。

データの取り扱いとセキュリティ方針

社内データや顧客情報をAIに扱わせる以上、データがどこに保存され、学習に利用されるのか、利用されないのかは契約前に必ず確認すべき項目です。特に生成AIのAPIを利用する場合、ベンダー側の学習利用ポリシーまで開発会社が把握しているかどうかで、説明の精度に差が出ます。

NDA（秘密保持契約）の締結に慣れているか、社内のセキュリティ審査に対応した実績があるかも、規模の大きい企業ほど確認しておきたいポイントです。

生成AI API利用時に確認すべきポイント

Azure OpenAI ServiceやAWS Bedrockなど、エンタープライズ向けに提供されているAPIの多くは、入力データがモデルの学習に再利用されない設定を選べます。開発会社がこうしたオプトアウト設定の存在を理解し、標準で有効化してくれるかどうかは、データガバナンスに対する意識の高さを測る指標になります。逆に、この点への質問に答えられない場合は、セキュリティ面での知見が浅い可能性があります。

情報システム部門との連携が必要なケース

従業員数の多い企業や、個人情報・機密情報を扱う業種では、情報システム部門やセキュリティ担当が独自のチェックリストを持っていることが多くあります。開発会社がこうした社内審査プロセスに慣れているかどうかで、契約締結までのスピードや、必要書類のやり取りの円滑さが大きく変わってきます。

契約形態が自社の進め方と合っているか

AI開発の契約には、成果物を明確に定義する請負契約と、稼働ベースで進める準委任契約があります。要件が固まりきっていない段階でPoCから始めたい場合は準委任、仕様が明確で成果物が定義しやすい場合は請負が向いているなど、進め方によって適した形態が変わります。

契約形態の希望を伝えたときに、なぜその形態を提案するのか理由を説明できる会社は、契約リスクへの理解が深いと言えます。

準委任契約が向いているケース

「まずは自社の課題にAIが使えるか試したい」「途中で方向転換する可能性が高い」といった、探索的な進め方をしたい場合は準委任契約が向いています。成果物を厳密に定義しない代わりに、状況の変化に応じて柔軟にスコープを調整しやすいのが利点です。ただし、稼働時間に応じた費用が発生するため、着地点が見えないまま長期化すると総費用がかさむリスクもあります。

請負契約が向いているケース

実現したい機能や仕様がある程度固まっており、成果物の完成基準を明確に定義できる場合は請負契約が向いています。契約時点で総額が確定しやすい一方、開発途中の仕様変更には追加費用や契約変更の手続きが必要になることが一般的です。要件を固めるための事前の準委任フェーズと、実装を請負契約で進めるフェーズを分ける、という組み合わせ方も広く行われています。

納品後の保守・運用体制

AIは一度作って終わりではなく、実運用の中でモデルの精度が落ちたり、想定外の入力に対応できなかったりすることがあります。納品後の保守契約があるか、不具合対応のSLA（対応時間の目安）が決まっているかを確認しておくと、運用開始後のトラブルに備えられます。

内製化を見据えている場合は、引き継ぎドキュメントの整備や、社内エンジニアへの技術移管に対応してくれるかも合わせて聞いておくとよいでしょう。保守契約を結ばずに「作って終わり」の関係になってしまうと、運用開始後に不具合が起きたときの相談先がなくなり、結局別の会社に修正を依頼し直すことにもなりかねません。

SLAで確認しておきたい具体的な項目

SLAという言葉だけで安心せず、「障害の重大度をどう区分しているか」「重大度ごとの一次回答までの目安時間」「対応可能な曜日・時間帯」まで具体的に確認しましょう。平日日中のみの対応なのか、休日や夜間の緊急対応にも一定範囲で応じてもらえるのかは、自社のサービスが土日も稼働するかどうかによって重要度が変わります。

内製化を見据えた技術移管対応

将来的に社内でAIシステムを運用していきたい場合、開発会社に技術移管への協力姿勢があるかを確認しておくとよいでしょう。ソースコードやモデルの選定理由、チューニングの経緯といった「なぜこう作ったか」までドキュメント化してくれる会社は、内製化後の運用負荷を大きく下げてくれます。中には技術移管に消極的な会社もあるため、契約前の段階で意向を伝えておくことが望ましいです。

PoC段階と本開発段階でチェックの重みは変わる

ここまでの7つのポイントは、契約規模の大きい本開発だけでなく、小さく始めるPoC（概念実証）の発注時にも当てはめられますが、重視すべき度合いは段階によって異なります。PoC段階では技術力と課題理解の深さが特に重要になる一方、本開発フェーズに進むと、体制や保守運用、セキュリティ対応の実務力がより問われるようになります。

最初からすべての項目を完璧に満たす会社を探そうとすると選定が長期化してしまうため、PoCの段階では「技術的に信頼できるか」を軸に絞り込み、本開発への移行時に改めて体制やセキュリティ面を精査する、という段階的な進め方も現実的な選択肢です。

PoCから本開発への移行時に見直すべきこと

PoCがうまくいったからといって、同じ会社にそのまま本開発を任せるかどうかは、あらためて検討する価値があります。PoCは小規模なチームで技術検証に集中できますが、本開発では複数人体制でのプロジェクト管理能力や、セキュリティ審査への対応力といった、PoC段階では見えにくかった実務力が必要になるためです。

契約前に確認したい7つのチェックポイント（まとめ）

ここまでの内容を、契約前のチェックリストとして整理します。初回の商談やRFP作成の際に、ひとつずつ確認していくことをおすすめします。

• 自社の課題に近い実績があるか
• 開発体制と窓口の役割分担が明確か
• 見積もりの内訳と前提条件が開示されているか
• データの取り扱い・セキュリティ方針が明文化されているか
• 契約形態が自社の進め方に合っているか
• 納品後の保守・運用体制があるか
• 担当者とのコミュニケーションに違和感がないか