AI開発会社の実績・ポートフォリオを見極める方法
AI開発会社のウェブサイトには、たいてい「導入実績」や「事例紹介」のページがあります。しかし、そこに書かれた実績が、自社の求めるレベルの技術力を示しているとは限りません。実績の見方を少し変えるだけで、パートナー選びの精度は大きく変わります。
「事例数」より「関与の深さ」を確認する
事例紹介の数が多いことは、必ずしも技術力の高さを意味しません。企画段階のアドバイスだけで「導入実績」としてカウントしている会社もあれば、要件定義から実装・運用まで一気通貫で担当した会社もあります。商談の場で、紹介された事例に対して開発会社がどこまで関与したのかを具体的に聞くことが重要です。
特に複数の協力会社と組んで開発を行う体制の場合、実際に手を動かしたのが自社のエンジニアなのか、外部の協力会社なのかによっても、次の案件で得られる技術的な安心感は変わってきます。体制図まで見せてもらえると、より実態に近いイメージがつかめます。
実績ページの事例が「〇〇業界向けAIチャットボット導入」のように抽象化されたタイトルだけで終わっている場合も注意が必要です。具体的にどんな課題があり、どう解決したのかというプロセスまで書かれている事例は、それだけ深く関与し、成果を言語化できるだけの実感を持っているケースが多い傾向にあります。
「関与の深さ」を測る具体的な質問例
「この事例では、要件定義・設計・実装・テスト・運用のうち、どこからどこまでを担当しましたか」と工程を区切って質問すると、企画段階のコンサルティングのみだったのか、実装まで責任を持ったのかが明確になります。あわせて「その中で御社が主体的に判断した部分はどこですか」と聞くことで、クライアント指示のもとで動いただけなのか、専門的な提案をしながら進めたのかも見えてきます。
技術スタックが自社の要件と一致しているか
生成AIの開発といっても、RAGシステム、AIエージェント、ファインチューニングなど技術要素はさまざまです。ポートフォリオに載っている事例が、自社が実現したい技術と近いかを確認しましょう。チャットボット開発の実績しかない会社に、複数システムを横断して操作する自律型AIエージェントの構築を依頼するのは、技術的な相性が悪い可能性があります。
公開されている事例だけで判断が難しい場合は、類似技術を扱った経験について直接質問し、具体的な技術構成を説明してもらうと精度の高い判断ができます。
技術要素ごとに見るべきポイントの違い
RAGシステムであれば、検索精度を高めるためのチャンク分割やベクトル検索の設計思想を聞いてみると、実装経験の深さが分かります。AIエージェントであれば、複数のツールやシステムを連携させる際のエラーハンドリングや、意図しない操作を防ぐガードレールの設計について尋ねると、実運用を見据えた開発経験があるかを判断しやすくなります。ファインチューニングであれば、学習データの品質管理や、過学習を防ぐための検証方法についての知見が判断材料になります。
技術トレンドへの追随度も確認する
生成AIの分野は技術の入れ替わりが早く、数年前の実績で得た知見が現在も通用するとは限りません。ポートフォリオの事例がいつ頃のものかを確認し、直近の技術動向をどう取り入れているかを聞いてみることで、技術のアップデートに追随できている会社かどうかを見極める材料になります。
守秘義務で公開できない実績もあると理解する
優良なAI開発会社ほど、大企業や機密性の高いプロジェクトを手がけている場合、契約上の理由で事例を公開できないことがあります。公開実績が少ないからといって即座に不安視するのではなく、商談の中で「公開できないが類似の実績がある」と説明された場合は、差し支えない範囲で内容を確認してみるとよいでしょう。
業界名や規模感、扱ったデータの種類といった、守秘義務に触れない範囲の情報だけでも、実際にプロジェクトへ関わった担当者であれば具体的に語れるはずです。この段階でも回答が曖昧な場合は、公開可否とは別の理由で説明が難しい可能性も考慮したほうがよいでしょう。
非公開実績を確認する際の聞き方の工夫
「具体的な社名は結構ですので、業界と、どのような課題に対してどんな技術を使ったかだけ教えてください」というように、守秘義務に配慮した聞き方をすると、開発会社側も答えやすくなります。この聞き方に対しても具体的な回答が返ってこない場合は、公開の可否とは無関係に、詳細を語れるだけの実績や理解が実はないという可能性も視野に入れておくとよいでしょう。
第三者の評価・紹介元を確認する
自社サイトに掲載された事例は、当然ながら開発会社にとって都合の良い内容が選ばれています。可能であれば、既存クライアントからの紹介や、業界内での評判といった第三者の情報も参考にしましょう。特にAI開発企業ディレクトリのような比較サービスでは、複数社の実績を横並びで確認できるため、自社サイトだけでは見えない相対的な立ち位置を把握しやすくなります。
既存クライアントへのヒアリングが難しい場合でも、業界内の勉強会やセミナーでの登壇実績、技術ブログでの発信内容などから、その会社が実際にどの程度の技術的な深さで案件に取り組んでいるかを推測できることがあります。単一の情報源だけで判断せず、複数の角度から評判を確認する姿勢が有効です。
技術ブログ・登壇実績から分かること
実際に手を動かしているエンジニアが所属する会社ほど、技術的な失敗談や試行錯誤の過程を含んだ、具体性の高い記事や登壇内容を発信している傾向があります。逆に、一般論をなぞっただけの内容や、他社の記事と似通った表面的な発信しかない場合は、実務での深い知見がまだ蓄積されていない可能性も考慮したほうがよいでしょう。
実績確認で注意したい「危険信号」
実績を聞いた際に、抽象的な成功談しか語られない、具体的な技術構成の質問に答えられない、担当者が実際にそのプロジェクトに関わっていない、といった反応が見られる場合は注意が必要です。実績紹介は営業トークとして磨かれていることが多いため、技術的な深掘り質問への応答度合いを見ることが、実力を見極める近道になります。
特に注意したい3つのサイン
1つ目は、失敗談やうまくいかなかった点を一切語らないことです。実際のプロジェクトには大小の困難がつきものであり、成功談しか出てこない場合は誇張されている可能性があります。2つ目は、質問への回答に一貫性がなく、聞くたびに説明が変わることです。3つ目は、事例の技術内容が同業他社のマーケティング資料と酷似しており、実体験に基づかない一般論を実績として語っている疑いがあることです。
契約後に実績とのギャップに気づいた場合の対処法
実績を丁寧に確認したつもりでも、契約後に「聞いていた実績ほどの技術力ではなかった」と感じることは起こり得ます。この場合、感情的に不満を伝えるだけでは状況は改善しません。まずは具体的にどの部分が期待と異なっていたのかを整理し、プロジェクトマネージャーや上位の責任者を交えて話し合う場を設けることが有効です。
多くの場合、担当エンジニアの技術力そのものよりも、要件の伝え方や期待値のすり合わせ不足が原因になっていることもあります。認識のズレがどこから生じているのかを冷静に切り分けることで、契約を打ち切るべきか、体制を見直して継続すべきかの判断がしやすくなります。
体制変更を依頼する際の伝え方
「担当者を変えてほしい」と直接的に伝えるより、「〇〇の部分について、より知見のあるメンバーに入っていただくことは可能でしょうか」というように、具体的な課題とセットで伝えるほうが建設的な話し合いになりやすい傾向があります。開発会社側にとっても、抽象的なクレームより具体的な要望のほうが対応しやすいためです。
早期に見極めるための小さな発注
実績の見極めに不安が残る場合、いきなり大きな契約を結ぶのではなく、要件定義や簡易的なPoCなど、小さく区切った発注から始めるという方法もあります。小規模な発注であれば、実際の技術力やコミュニケーションの質を低リスクで見極めることができ、そのうえで本開発への発注可否を判断できます。
実績確認と自社の準備状況を照らし合わせる
どれだけ優れた実績を持つ開発会社であっても、自社側の準備が整っていなければ期待した成果は出ません。実績確認と並行して、自社がプロジェクトに割ける人員や、意思決定のスピード、社内データの整備状況についても客観的に振り返っておくと、開発会社選びの精度がより高まります。
特に、開発会社の実績が「クライアント側の協力体制が整っていたからこそ実現できた成果」である場合もあります。商談の際に「このプロジェクトでは、クライアント側にどのような協力を求めましたか」と聞いてみることで、自社が同程度の協力体制を用意できるかを事前に検討する材料になります。
実績を聞く際の質問リスト
商談の場で実績を深掘りする際は、以下のような質問が有効です。
- その事例で、要件定義から運用まで、どの工程を担当したか
- 使用した技術・モデルは何か、なぜそれを選んだか
- プロジェクトで最も苦労した点は何か
- 導入後にどのような効果が確認できたか
- 守秘義務で公開できない類似実績はあるか
- 実績の中で、途中で計画通りに進まなかった経験はあるか
