つい最近まで、AI のデモさえあれば十分でした。投資家は熱心に耳を傾け、顧客は興奮し、誰もがその一端を手に入れようとしていました。

その時代は、終わりました。

熱狂は、もっと泥臭い課題に変わりました。AI を本番環境で動かし続けるための、地道な作業です。先日開催したラウンドテーブル「Architect It Once or Rebuild It Twice」では、この課題をリアルタイムで経験している AI ネイティブスタートアップの CEO 3 名、AnySoft の Alex Noe 氏、Euphonic AI の Asa Whillock 氏、TheNoah.ai の Akash Sureka 氏を招き、CData のフィールド CTO である Rahul Pahuja も加わりました。議論は率直かつ具体的で、時に思わず身につまされるものでした。

彼らの言葉を、そのままお届けします。

成功したこと、そして今ならこうするということ

ここにいる創業者は全員、実際の顧客に向けて AI 機能をリリースしてきました。そして全員が、「もしやり直せるなら変えたい」と思う点を持っています。

Alex Noe 氏（AnySoft）は、統合については最初から正しく取り組んでいたと語りました。開発するすべてのアプリで共有される単一のデータベースを構築し、その背後には世界最高水準の統合技術を備えていました。では、今なら変えたいと思う点は？ 分析機能です。「ユーザーに何が起きているのか、どこをクリックしているのかを正確に把握できていませんでした。」開発スピードを優先すると、計測（インスツルメンテーション）は後回しになりがちです。でも、それは間違いでした。

Asa Whillock 氏（Euphonic AI）は、統合こそが「もっと早く取り組むべきだった」最大の後悔だと指摘しました。早い段階で統合に投資しましたが、それでもまだ早すぎることはありませんでした。「大規模な統合に踏み込む？ そこには無数の落とし穴があります。それこそが、すべてを前進させるための最大の壁です。」

Akash Sureka 氏（TheNoah.ai）は、データレイヤーを正しく構築することの重要性について、明確にこう語りました。「AI の世界において、システム・オブ・レコードとは、あらゆるデータのことです。それが今後の発展における最も基礎的なレイヤーであり、成否を分ける鍵となるのです。」

データ統合の問題は、見た目以上に深刻です

3 つのプラットフォームはいずれも、顧客データへの依存度が高いです。そして 3 社とも、同じことを口にします。「見た目よりずっと、ぐちゃぐちゃだ」と。

Asa は、単一の顧客環境内で 5 から 15 もの Go-to-Market スタックを横断して作業した経験について語り、「それらのうち一つとして互いに整合していなかった」と述べました。そしてすぐにこう付け加えました。問題は、実はデータエンジニアリングではありません。重要なのは、それらのシステムに接続し、より難しい問いを投げかけることです。「ここで真の基準となるべきものは何だったのか？ 本来あるべきプロセスは何だったのか？」

これが、データのコンテキストをこれほど難しく、そしてこれほど重要にしている理由です。Asa はこう言い切ります。「モデルは簡単な部分です。でも、コンテキストがなければ、モデルは実際には何もわかっていない。」最先端のモデルは能力を備えています。しかし、ほとんどのデプロイ環境において、モデルに欠けているのは、なぜデータがそのような姿をしているのかという理解です。これこそが、本番環境での AI 機能の障壁となっています。

接続機能は、自社で一から作らなくていい

社内で接続機能を構築しようとしたことがあるかと尋ねると、答えは「短期間試したが、二度とやらない」というものでした。

Asa はこう語りました。「API は山ほどある、AI ならすぐに把握してデータに接続できるはずだ、何が問題なのか。そういう認識があります。でも、それは真実からかけ離れています。」たとえドキュメントが充実している API であっても、未記載のコンポーネントや、パフォーマンスのセマンティクスの不一致、そしてセマンティックレイヤーに到達する前に積み重なるバリエーションが存在します。ちなみに、そのセマンティックレイヤーはアカウントごとに独自のものです。彼のアドバイスはこうです。「自分たちが得意なことに集中できるツールがあるのに、なぜわざわざ車輪を再発明するんですか？」

接続できるだけでは不十分。精度が求められます

接続できれば、AI 機能は動き出します。しかし、人間がループに入らず出力を確認しない自律的なワークフローへと移行するにつれ、精度が真の課題になってきます。ステップ 1 での誤りは、ステップ 2、3、4 へと雪だるま式に膨らんでいきます。

CData のフィールド CTO である Rahul Pahuja は、4 つのエンタープライズシステムと 378 回の標準化されたテスト実行において、5 社の MCP プロバイダーを評価した調査結果を解説しました。CData の精度は、2 位のプロバイダーよりも 25 ポイント以上高い結果でした。その理由は、相対データロジック、マルチフィルタークエリ、セマンティックインテリジェンス、書き込み操作の 4 点に集約されました。いずれの場合も、問題はモデルそのものではなく、接続レイヤーがモデルに渡したデータにありました。

Asa はビジネス上の意義をこう語りました。「20 年間、分析部門のリーダーをやってきました。同じ質問を 2〜3 回して、毎回違う答えが返ってくるシステムを求めた顧客が何社あったか、わかりますか？ ゼロです。そんなシステムを信頼したい顧客なんて、一社もいません。精度が命なんです。」

彼らが目指すもの

Akash は今後 6 ヶ月間、2 つのことに注力します。大規模なデータセットと、データの関連性です。データセットが数千万件規模に拡大すると、コンテキストウィンドウ、メモリ層、レイテンシなど、すべてが変わります。そして、企業や部署ごとに異なるデータの関連性こそが、他のすべてを機能させる真の鍵となります。「ビジネス上の関係性とデータの関連性を理解すること。それが中心的な柱です。」

Asa は視野を広げます。彼が「結合組織を張り巡らせる」と呼ぶビジョンです。つまり、「細胞同士がまだうまく話せていないアメーバのような段階」から、エンタープライズを次のステージへと引き上げること。今築かれている基盤こそが、その進化を支える土台となります。

Alex は、アプリケーションの未来をこう見ています。ハイパーパーソナライズされ、その場で組み立てられ、エージェントが作業の多くを自律的に処理する世界。目標は、正確な時期を予測することではなく、一歩ずつ着実に進み、今日この瞬間から顧客をその未来へと導くことです。

一つのアドバイス

最後に、矢継ぎ早に質問を投げかけました。初期段階で下した、成果につながった決断は何か。もっと早く始めるべきだったことは何か。

Alex：会社を立ち上げたその日から、コンプライアンス認証の取得を始めること。「とてつもない成果をもたらしました。」AnySoft は現在、競合他社の中で最も多くの認証を取得し、最もコンプライアンスに準拠したプラットフォームとなっています。その取り組みは、創業初日から始まっていました。

Akash：まずは統合。次にガバナンス。どちらも創業当初から着手すべきです。

Asa のアドバイスは、スピード重視で事業を構築するすべての創業者に届けたいものです。「AI にコーディングを任せる部分と、自分たちがきちんとサポートしスケールさせる部分。それぞれ別の計画を持つべきです。6 ヶ月前に Claude に組み立てさせたものを、今になってサポートしようとしているような状況には陥りたくないでしょう。」

これは、AI を使った開発を否定しているわけではありません。基盤のどの部分を、バイブコーディングのスプリントに任せるか、ちゃんと考えるべきだという話です。

最初から正しく作りましょう。さもないと、二度作り直すことになります。

詳しく知りたい方は、こちらのラウンドテーブルディスカッションのフル動画をご覧ください。

※本記事は CData US ブログ Lessons from AI Startup CEOs Scaling in Production の翻訳です。