エンプロンプトゥ AIのシェイナ・レブン氏、CEO兼創設者 – インタビュー・シリーズ

シェイナ・レブン氏は、エンプロンプトゥ AIの創設者兼CEOであり、メジャーなテクノロジー企業での開発者向けプラットフォームやAI駆動型製品の構築における豊富な経験を持つベテランの製品リーダーです。エンプロンプトゥを2025年に立ち上げる前に、コードシー（CodeSee）を創設しました。コードシーは、開発チームが複雑なコードベースを視覚化し、理解するのを助けるAI駆動型開発者プラットフォームで、2024年にGitKrakenによって買収されました。彼のキャリアの初期には、Docker、Cloudflare、eBay、Googleなどの企業でシニア製品リーダーシップの役割を担い、Googleアシスタントの支払いAPIや、数十万人の学習者によって使用される開発者向け教育プログラムなどのイニシアチブに取り組みました。

エンプロンプトゥ AIは、企業がAIアプリケーションをより簡単に構築してデプロイできるように設計されたエンタープライズプラットフォームです。このプラットフォームは、アプリケーション開発、データ統合、ガバナンス、評価、メモリ、モデルオーケストレーションを1つの環境に統合し、企業が迅速なAI実験からエンタープライズ向けの制御と信頼性が必要なプロダクションレベルのシステムに移行できるようにします。

あなたは、Google (GOOGL ) 、eBay、Cloudflare、Dockerなどの企業で開発者向けプラットフォームを15年以上構築してきました。コードシーを創設し、後にGitKrakenによって買収され、現在はエンプロンプトゥ AIを率いています。こうした経験が、デモステージを超えてAIツールが失敗する理由についてあなたの視点をどのように形作ったのか。また、エンプロンプトゥを創設した際に解決しようとした具体的な問題は何でしたか。

開発者向けプラットフォームを構築することで学んだことの1つは、最も難しい問題はデモではありません。デモはいつも動作します。実際のテストは、数千の開発者がシステムを使用するとき、データが汚れているとき、統合が壊れているとき、そして実際のビジネスがそれに依存するときに何が起こるかです。

Google、Cloudflare、Docker、eBayでは、グローバルスケールで動作するプラットフォームに取り組みました。そのような環境では、信頼性、ガバナンス、観測可能性は後から追加される機能ではありません。アーキテクチャの一部です。

AIアプリケーションを構築し始めたとき、モデルはひどかったですが、改善され始めたときに、業界が以前のソフトウェアの波で見られた同じミスを繰り返していることに気づきました。開発ツールでは、忘れ去られた概念があります。ハローワールドに到達するまでにどれくらいの時間がかかるか。今日、ハローワールドの生成バージョンは、完全に動作するSaaSプロトタイプです。しかし、現在はSaaSアプリケーションのみをコード化するのではなく、完全なAIアプリケーションをコード化しています。AIを構築するAIは、プロダクションに配置するために他のシステムが必要です。

動作するAIアプリケーションまたは機能を迅速に生成できるのは、実際に役立つことですが、主なシステムはまだプロダクション環境に必要なインフラストラクチャを欠いています。構造化されたデータパイプライン、評価フレームワーク、ガバナンスコントロール、モニタリング、長期のコンテキスト管理などが見落とされましたが、エンプロンプトゥではそれらをすべて保ちながら、コード化の素晴らしい部分も維持しています。

私と私の共同創設者がエンプロンプトゥを創設したときに解決しようとした問題は、シンプルでした。AIアプリケーションを最初からプロダクションレディにできるようにする方法は何ですか。

ガバナンス、データの準備、評価、最適化を個別のツールまたは事後処理として扱うのではなく、プラットフォームに直接組み込みました。アイデアは、チームが迅速にAIアプリケーションを構築できるようにすることですが、エンタープライズソフトウェアシステムと同じ信頼性、品質、コントロールを期待することです。

あなたは、印象的なAIデモとプロダクションレディなシステムの間にあるギャップについて公言してきました。プロダクションレディな製品にしたいAIプロトタイプを構築しようとするチームが最も一般的に犯すアーキテクチャミスは何ですか。

チームが最も一般的に犯すミスは、モデルが製品であると考えることです。

初期のプロトタイプでは、モデルが最も目立つ仕事をします。モデルにプロンプトを与え、答えを生成し、答えが良さそうならシステムは動作するようです。那は、モデルを改善することが主な課題であるという幻想を生み出します。

しかし、プロダクションシステムでは、モデルはより大きなアーキテクチャの中で1つのコンポーネントにすぎません。

最初のミスは、データをあとまわしに扱うことです。プロトタイプでは、チームは通常、小さなクリーンダータセットでテストします。システムが実際の運用データに接続すると、状況は急速に変化します。データは不完全、不一致、重複、または予期しない形式で到着します。構造化されたデータパイプラインが入力の正規化と検証を提供しない場合、システムはモデルがどれほど良いかに関係なく信頼性が低くなります。

2番目のミスは、評価フレームワークの欠如です。多くのチームは、AI機能を立ち上げる前に何が「良い」ものであるかを定義しません。開発中に手動で出力をスポットチェックするかもしれませんが、システムが稼働中である間に精度、ドリフト、エッジケースを継続的に測定する自動評価パイプラインを構築しません。ガードレールがない場合、エンジニアではなく顧客によって失敗が発見されることがよくあります。

3番目の問題は、ガバナンスとコントロールメカニズムの欠如です。AIシステムは確率的であるため、わずかに異なる条件下で異なるように振る舞う可能性があります。規制された環境または高リスク環境では、その予測不可能性を決定的なポリシー、承認ワークフロー、意思決定のやり方を記録する監査ログで制限する必要があります。

これは、プロダクションAIシステムがモデルだけではないということです。運用システムです。

今日、AIに成功している企業は、データパイプライン、評価、ガバナンス、モニタリングをコアインフラストラクチャとして扱う企業です。オプショナルな追加機能ではなく、必須の機能として扱っています。

多くのAIコーディングプラットフォームは、誰でもシンプルなプロンプトを使用してアプリケーションを構築できることを約束しています。なぜこれらのツールはデモではうまく機能するのに、企業がそれらを実際のプロダクション環境で展開しようとしたときに苦労するのでしょうか。

これらのプラットフォームはデモではうまく機能します。なぜなら、作成の瞬間だけに最適化されているからです。ライフサイクル全体ではありません。

しかし、AIを使用してランディングページを生成することと、AIを使用してAIアプリケーションを構築することには根本的な違いがあります。

ランディングページはほとんど静的なソフトウェアです。正しくレンダリングされれば、仕事はほとんど終了です。システムは確率的な決定を下したり、不断に変化するデータを取り込んだり、予測不可能なユーザーの行動に適応したりする必要がありません。

AIアプリケーションは完全に異なります。データパイプライン、モデル動作、評価フレームワーク、継続的なモニタリングに依存するダイナミックシステムです。アプリケーションはコンテキストを管理し、出力のドリフトを検知し、エッジケースを処理し、モデルが前に見たことがない状況に出会ったときに安全に動作する必要があります。

ほとんどのプロンプト駆動型コーディングツールは、これらのレイヤーに対処していません。なぜなら、迅速に何かを動作させるように設計されているからです。コードを生成し、可視的な結果を生み出すため、デモ環境には完璧です。しかし、プロダクションシステムでは、構造化されたデータ処理、ガバナンスコントロール、評価パイプライン、観測可能性、動作の安全な更新メカニズムなどの幅広い機能が必要です。

したがって、企業がこれらのシステムを実際の環境で展開しようとしたとき、ギャップは明らかになります。プロトタイプは動作しました。なぜなら、環境が制御されていたからです。プロダクションは汚いです。

エンプロンプトゥは、企業がすべてを最初から再構築するのではなく、既存のソフトウェアをAIネイティブシステムに変換することに重点を置いています。インフラストラクチャレベルおよび製品レベルでの変換とは何を意味しますか。

製品レベルでは、すべてのアプリケーションは完全に自己完結型であり、コンテナ化されています。フロントエンド、バックエンド、データベース、モデル、評価、ルール、すべてを含み、エンタープライズのニーズに応じて非常に柔軟です。

AIアプリには、いくつかのオプションがあります。

「ヘッドレス」なので、顧客がすでにフロントエンドを持っている場合、システムに接続してデータを返すことができます。

完全にコンテナ化されているため、エンプロンプトゥのインフラストラクチャまたは顧客のインフラストラクチャにデプロイできます。つまり、デフォルトでオンプレミスです。

または、最も便利なオプションとして、クラウドに直接生成してデプロイできます。

顧客が持っているコードはすべて、エンプロンプトゥのシステムに直接インポートできます。エージェント化されていない場合は、エージェント化します。たとえば、ラブアブル、リプレイ、ボルト、ベース44などの人気プラットフォームでアプリを構築しようとした顧客を何人か見たことがあります。ただし、多くの場合、うまく機能しません。顧客はすでにアプリケーションに多くの時間、エネルギー、クレジットを投資しています。したがって、それをインポートし、書き直し、AIを機能させるようにします。

これを行うことができるのは、独自のプロプライエタリ技術をいくつか持っているからです。たとえば、

• コンテキストを管理するためのアダプティブコンテキストエンジン
• 長時間実行されるコードアプリケーションを取り込むための無限メモリ
• データクリーンアップと合成ラベル付けが必要な場合にそれらを処理できるように、カスタムデータモデルとゴールデンデータパイプライン

あなたのプラットフォームは、コンテキスト、評価、ガバナンス、構造化データをAIシステムのコアコンポーネントとして強調しています。なぜこれらの要素がAI機能を製品に追加しようとするチームによって頻繁に見落とされるのでしょうか。

それは難しいからです。私の共同創設者であるショーン・ロビンソン博士が、私たちの研究ラボを率いています。彼は計算宇宙物理学者であり、私の狂気的なアイデアにインスパイアされたいくつかの技術を発明しました。また、顧客のニーズや市場の動向にもインスパイアされています。私たちが構築した多くのエージェントアプリケーションや、世界最大のテクノロジー企業での経験は、私たちが複雑な問題を他の人よりも優れて解決するのを助けています。

あなたは、コードを書いたことがない創業者と多く取り組んでいます。AIアプリケーションを構築する際に、非技術的な創業者が最も一般的に持つ2つの大きな誤解は何ですか。

私は2つの大きな誤解があると思います。

1つ目は、AIは魔法であるということです。AIは魔法ではありません。ただの良いエンジニアリングです。最終的には、プラットフォーム上で何ができるかについての限界に達します。

2つ目は、彼らが優れた技術的製品管理スキルを持っているということです。私は技術的製品管理のバックグラウンドを持っています。ビジョン、時には非常に大きなビジョンを、正しい技術仕様で、ちょうど何が欲しいのかを明確に伝えることができる、小さな配達可能なチャンクに翻訳するスキルは、実際には非常に難しいスキルです。それには時間がかかります。

たとえば、PDFをアップロードして後で参照できるように保存するアプリを構築しようとしているとします。那は、永続性という概念です。PDFはコードにエンコードされてデータベースに保存されます。

しかし、永続性が何であるかを知らなければ、データを永続化するように指定することはできません。技術用語は、自然言語とは異なる言語を話すようなものです。自然言語で書くことと技術言語で書くことには違いがあります。

多くのスタートアップは、AI製品を構築する解決策は、単にエンジニアをもっと雇うことであると考えています。なぜそのアプローチがよく失敗するのでしょうか。AI駆動型製品を構築する際に、創業者が何について考えるべきですか。

エンジニアをもっと雇うことは、時には正しい答えです。深く技術的な製品を構築している場合、またはモデル研究の最前線で働いている場合、優れたエンジニアチームは必要不可欠です。難しい問題を解決するには、良いエンジニアに代替はありません。

しかし、多くのスタートアップが犯すミスは、エンジニアをもっと雇うことがAI製品の課題を自動的に解決するということです。

実際、AI製品で最も難しい問題は、純粋に技術的な問題ではありません。システムの問題です。エンジニアはシステム的に考えるように教えられています。しかし、生成的開発は、決定論的開発とは異なります。多くの人がオブジェクト指向プログラミングから関数型プログラミングへの移行時にこの変化を経験しました。プログラミングは同じですが、異なりますか。考え方は異なりますか。はい、もちろん。

AIアプリケーションは、データ、製品設計、運用ワークフロー、モデル動作の交差点に位置しています。優れたエンジニアチームを雇用できますが、データパイプラインが信頼性が低い場合、評価基準が不明確な場合、またはシステムがガバナンスとモニタリングを欠く場合、製品は実際のユーザーに到達すると依然として苦労します。

別の問題は、多くのチームが、AIシステムがプロダクションでどのように動作するかを定義する前に、構築を開始することです。システムの評価方法、エッジケースの処理方法、意思決定の記録方法、モデルを安全に更新する方法などの質問は、後になってから来ることがよくあります。アーキテクチャを変更するのは、その時点では難しい場合があります。

創業者が本当に考えるべきことは、AIシステムの運用モデルです。

誰がデータパイプラインを所有していますか。

開発中だけでなく、継続的にモデルパフォーマンスをどのように測定しますか。

システムが見たことがない状況に出会ったときに何が起こりますか。

どのようにしてダウンストリームのワークフローを壊すことなく、動作を安全に更新しますか。

時には、これらの問題を解決するには、エンジニアをもっと雇う必要があります。しかし、正しいインフラストラクチャを選択すること、強い製品の制約を定義すること、少人数のチームが信頼性を持って大規模に動作できるシステムを構築することも含まれる場合があります。

今日、AIに成功している企業は、必ずしも最も大きなエンジニアリングチームを持っているわけではありません。AIを、データの規律、評価、ガバナンス、継続的な改善が最初から組み込まれた、長期的なシステムとして扱う企業です。

あなたは、現在のAI開発者ツールのビジネスモデルは、耐久性のある製品を構築することと一致していないと主張しています。現在のAIツールエコシステムでは、企業を間違った方向に導いていると考えるインセンティブは何ですか。

現在の最大のインセンティブの不一致は、多くのAI開発者ツールが成長メトリックに最適化されていることです。製品の耐久性ではなく、誰でも何かを作成できる速度に重点が置かれていることです。

この分野の多くの企業は、ユーザーが何かを作成できる速度で評価されます。ツールが数分で動作するアプリ、機能、またはデモを生成できる場合、それはサインアップ、ソーシャルシェア、投資家の熱狂を促進します。製品の採用の観点から、それは意味があります。

しかし、これらのインセンティブは、作成の瞬間で止まります。

AIソフトウェアにおけるより難しい作業は、その時点を過ぎてから始まります。那は、信頼が構築される時です。品質が保証されます。ユーザーが悪い出力のAIの苛立ちを感じることなく、再び戻ってくることを望む時です。

別の問題は、多くのツールがコード生成に最適化されていることです。コードを迅速に生成することは役立ちますが、AI製品を構築するには、コードを生成すること以上のことが必要です。システムがコンテキストをどのように管理するか、意思決定をどのように評価するか、障害をどのように処理するか、動作を安全に更新する方法について定義する必要があります。

顧客がAIシステムを信頼性を持って稼働させるのを助ける企業は、迅速にAIシステムを構築できるのではなく、AIシステムを信頼性を持って稼働させるのを助ける企業は、エコシステムで持続可能な価値を生み出すでしょう。

エンプロンプトゥの顧客には、特化した製品、たとえばヘルスケアツールや持続可能性に焦点を当てたビジネスを構築している起業家がいます。彼らは従来のエンジニアリングチームを持っていません。アイデアを実際の動作するAI製品に変えることに成功した創業者に共通するパターンは何ですか。

私たちが見る最も興味深いパターンの1つは、成功する創業者は必ずしも最も技術的な人ではないということです。彼らは、解決しようとしている問題を非常に深く理解しています。

エンプロンプトゥを使用する多くの起業家は、ドメインの専門家です。彼らはヘルスケア、金融、持続可能性、またはその他の特化された業界から来ています。彼らが持っているのは、その環境にあるワークフロー、規制、意思決定に関する深い知識です。那は、AI製品を設計する際に非常に貴重なコンテキストです。なぜなら、それがシステムが実際に何をしなければならないかを定義するからです。

成功する創業者は、AIを、技術的な実験としてではなく、製品システムとしてアプローチします。彼らは、非常に具体的な質問から始めます。AIがユーザーにどのような決定を支援すべきか。どのようなデータソースにアクセスする必要があるか。どのような答えがそのドメインでは「正しい」ものであるか。システムが責任を持って動作するために、どのようなガードレールが必要か。

別のパターンは、構造を慎重に考えることです。成功したチームは、AIの出力は、コンテキストとデータの入力に依存することを迅速に認識します。彼らは、データパイプライン、知識源の組織化、評価基準を定義することに時間を投資します。彼らは、AIが人間の判断と最終的な決定を支援するように設計されたワークフローを構築します。那は、特にヘルスケアや金融などの分野では、システムをはるかに信頼性の高いものにします。

多くの場合、最大の変化は、マインドセットです。成功する創業者は、AIを、製品が動作するための新しい運用レイヤーとして考えています。AIを追加する機能として考えるのではなく、製品が動作する新しい方法として考えています。

AIシステムがコアビジネス運用にさらに統合されるにつれて、次世代のAIアプリケーションプラットフォームを定義する機能は何ですか。

私はこれは狂気と言ってもいいかもしれませんが、もしかしたら私は何か神に反することを言っているかもしれませんが、人々は自分のカスタムモデルをビブコードできるようになるでしょう。私たちの研究ラボが「エキスパート・ナノモデル」と呼んでいるものが、コストを制御するのに役立ちます。

素晴らしいインタビュー、詳しく知りたい読者はエンプロンプトゥ AIを訪問してください。