A&A INSIGHTS
AIサービスの有料PoCで何を約束するか：デモと検収条件を分ける
デモは動くのに、有料の検証で何を約束するかが決まらない。AIサービスの有料PoCでは、検証する案件を買い手が選び、AIが人へ渡すべき案件も合格に含め、確認する人と時間を先に書きます。LovableとAnthropicの一次資料から、提案書に載せる十行を示します。
Read in English
この記事の要点
デモを見せた次に有料の検証を提案する段階で、顧客のデータでどの状態を納品完了とするかが決まっていないと、検証の最後に合否が決まりません。この記事の主張は、有料PoCで約束するのは成功したデモの再演ではなく、顧客が選んだ入力で顧客自身が判定できる成果物を受け渡すことだというものです。Anthropicの評価解説にある、実際の失敗から課題を引くこと、起きるべき場合と起きるべきでない場合の両方を試すこと、すべての採点を通る基準解を作ること、二人の専門家が独立に同じ合否に至るかを問うことを、受託の提案書の欄に読み替えます。Lovableの事例ページが述べる、利用者が自分でコードを読めないという前提も同じ方向を指しています。産業用機械の保守会社という架空の例で、有料PoC合意書の十行を埋めます。出典の記述、A&Aの解釈、架空の仮想例は区別しています。
有料PoCで約束するのは、動いたデモの再演ではない
A&Aの考え方
「では、有料で試してみましょう」と言われた段階の提案書に、機能の一覧と期間と金額しか書いていないことがあります。この状態で検証を終えると、最後に残る問いは「で、これは成功だったのか」です。答えが双方の感想の交換になり、追加作業が無償で積み上がり、本契約の判断も先送りになります。有料の検証で約束するものは、動いたデモをもう一度再現することではありません。顧客が選んだ入力に対して、顧客が自分の手段で合否を判定できる成果物を受け渡すことです。デモと有料PoCを分ける線は、機能の多さでも期間の長さでもなく、入力を誰が選ぶかにあります。
出典に基づく事実
Anthropicが公開するLovableの事例ページは、同社が新しいClaudeのリリースごとに、最初から走らせているものと同じ評価をかけ、システムが行き詰まって、壊れたアプリや利用者が依頼したものとは違うアプリを作ってしまう頻度を測っていると説明しています。同ページでは、共同創業者兼CEOのAnton Osikaと、プロダクトを率いるAlexandre Pesantの発言が引かれています。ページに公開日の表示はありません。
出典に基づく事実
同じページは、その関門が意味を持つ理由を、Lovableの利用者は多くの場合コードを自分で読めないため、出力が動くことを信頼している状態にあるからだと述べています。
A&Aの考え方
A&Aがこの記述から受託事業へ持ち込むのは、評価の頻度ではなく前提のほうです。買い手は成果物の中身を直接読めないことが多い。受託でも事情は同じで、AIが作った文書やデータの妥当性を、買い手がその場で判断できるとは限りません。だとすれば、有料PoCの合否は成果物の巧拙ではなく、買い手がすでに持っている手段でそれを判定できるかどうかで書くことになります。判定できない約束は、検証が終わっても検証になりません。
A&Aの考え方
反対の立場もあります。初回の有料検証は取引関係を作ることが目的で、条件を細かく書くほど相手の心理的な負担が上がり、失注する。まず小さく受けて信頼を作るべきだ、という考え方です。これは実際に成り立つ場面があり、最後の節で扱います。ここで言いたいのは条件を増やせということではなく、書く条件を機能から判定へ移すことです。欄の数は増えません。
検証に使う案件を、どちらが選ぶか
A&Aの考え方
デモの入力は売り手が選びます。うまく動く例を選ぶのは当然で、それ自体は悪いことではありません。問題は、有料になった瞬間にも同じ性質の入力を使い続けてしまうことです。売り手が選んだ十件が全部通っても、買い手の手元には「自分の案件ではどうなるのか」という最初の問いが残ったままになります。
出典に基づく事実
Anthropicのエンジニアリング記事「Demystifying evals for AI agents」（2026年1月9日公開、著者はMikaela Grace、Jeremy Hadfield、Rodrigo Olivares、Jiri De Jonghe）は、評価用のデータ集合を集める最初の段で、多くのチームが数百件の課題が必要だと考えて着手を遅らせると述べ、実際には実際の失敗から引いた20件から50件の単純な課題が良い出発点になると書いています。
出典に基づく事実
同記事は次の段で、すでに手で確認している内容から始めるよう勧めています。開発中に各リリースの前に確かめている挙動と、利用者がよく試す作業から始める。すでに本番で動いているなら、バグ追跡と問い合わせの待ち行列を見る。利用者から報告された失敗を試験項目に変えることで、その集合が実際の使われ方を反映するようになる、という説明です。
A&Aの考え方
A&Aがここから取り出すのは件数ではなく、案件の出どころです。「実際の失敗」「バグ追跡」「問い合わせの待ち行列」は、いずれも作った側の想定ではなく、使われた側に残った記録です。有料PoCに置き換えると、検証する案件の選定を買い手に渡すことになります。頼み方は具体的にします。「うまくいっている案件をください」ではなく、「過去半年で、差し戻しややり直しが起きた案件を出してください」と聞く。選定を相手に渡すと、こちらの見込みが外れる確率は上がります。上がった分が、そのまま買い手の判断材料になります。
A&Aの考え方
20件から50件という数はそのまま持ち込めません。出典は製品のエージェント評価について書かれたもので、単一の顧客の検証では同種の案件が六件しか取り出せないこともあります。件数を目標にすると、数を満たすために性質の違う案件を混ぜることになり、合否の意味が薄れます。提案書に書くのは件数の多さではなく、「この十件は買い手側が選んだ」という一行です。
仮想例
仮想例です。産業用機械の保守を請け負う会社に、現場の作業員がスマートフォンで送る作業報告（写真と短い文）から、顧客提出用の作業報告書のドラフトを作る仕組みを提案するとします。デモでは、代表が自分で選んだ、写真が鮮明な三件を使いました。有料PoCでは、この会社の工事部長に「過去半年で、顧客に出す前に書き直しが発生した報告書を十件出してください」と頼みます。出てきた十件には、写真が暗くて型番が読めないもの、作業員の記述が前回の報告と食い違うもの、見積の範囲外の作業が書かれているものが含まれていました。この十件が検証の対象になります。以上は説明のための架空の設定です。
| 決めること | 見せるデモ | 有料の検証 |
|---|---|---|
| 案件を選ぶ人 | 売り手が、うまく動く例を選ぶ | 買い手が、自社の記録から選ぶ |
| 案件の出どころ | 手元で試して通ったもの | 差し戻し・やり直しが起きた実例 |
| AIがやらない案件 | 見せない | 合格の一種として先に並べる |
| 合否を決める人 | 商談の場の空気 | 買い手側の担当者一人が既存の手順で判定 |
| 判定に使う材料 | 画面の実演 | 受け渡した成果物そのもの |
| 確認にかかる時間 | 数十分の商談に含まれる | 買い手の工数として明細に書く |
| 途中でモデルを変えたとき | 気付かれない | 同じ案件集合で再確認し、負担を先に決める |
| 終わったあとの判断 | 「良さそうですね」 | 続ける条件とやめる条件が書いてある |
「AIがやらない」案件を、合格の側に置く
出典に基づく事実
同記事は、均衡した問題集合を作る段で、ある挙動が起きるべき場合と、起きるべきでない場合の両方を試すよう述べています。片側だけの評価は片側だけの最適化を生むという説明で、例として、検索すべきときに検索するかだけを試すと、ほとんどあらゆることについて検索してしまうエージェントになりかねないと挙げています。
A&Aの考え方
受託の有料PoCにこれを移すと、「AIが処理せず、理由を付けて人へ渡すべき案件」を、合格の一種として先に並べることになります。提案書で最も抜けやすいのがこの欄です。抜けたまま検証を走らせると、人へ渡った案件は自動的に失敗として数えられます。買い手の読み方は「結局人がやるなら意味がない」になり、実際には設計どおりに動いた案件が、失注の理由に変わります。
A&Aの考え方
先に書いてあれば、同じ結果が合格になります。書き方は「この種類の案件では、AIが本文を書かず、確認事項の一覧として担当者へ返すのが正しい動作です」という形です。加えて、返すときに何が付いていれば合格かを決めます。どの項目が確認できなかったか、どの入力が足りなかったか。この二つが読み取れる形で返っていれば合格。黙って空欄で出てきたら不合格。こうすると、人へ渡す動作にも合否がつきます。
仮想例
先の架空の例で言えば、十件のうち、写真が暗くて型番が読めない二件と、前回の報告と食い違う一件は、ドラフトを書かずに返すのが正解の案件です。合否の条件は、読めなかった項目が「型番（写真から判読不可）」のように具体的に挙がっていること、そして作業員に聞き直すべき点が一文で書かれていること。残りの七件は、工事部長が手を入れずにそのまま顧客へ出せることを合格とします。七件と三件という割り振りは説明のための仮の数で、実際は選ばれた案件の中身で決まります。
値付けの前に、一件だけ自分で完成させる
出典に基づく事実
同記事は、課題ごとに基準となる解を作ることが有用だと述べています。すべての採点を通る既知の正しい出力を用意しておくことで、その課題が解けることが示され、採点の仕組みが正しく設定されていることも確認できる、という説明です。
A&Aの考え方
A&Aがこれを提案の手順に移すと、値付けの前に、買い手が選んだ十件のうち一件を、こちらが自分で完成させて見せることになります。目的は二つあります。一つは、その業務が本当に解けることの確認。もう一つは、検収の文言が実際に使えるかの確認です。一件を仕上げてみると、書いたはずの合格条件が判定に使えないことがよく分かります。「読みやすい報告書」では判定できず、「型番と作業時間が記載され、写真の枚数が本文の作業項目と対応している」まで下りないと、相手は合否を言えません。
出典に基づく事実
同記事はさらに、良い課題とは、二人の領域専門家が独立に同じ合否の判定に至るものだと述べています。その専門家自身がその課題を解けるか、解けないなら課題を練り直す必要があるとし、課題の記述の曖昧さは指標の上の雑音になると説明しています。
A&Aの考え方
この一文は、提案書の自己点検にそのまま使えます。買い手の会社の二人、たとえば工事部長と品質保証の担当者が、同じ成果物を見て別の合否を言うなら、その検収条件はまだ書けていません。出典は評価指標に乗る雑音の話ですが、受託ではそれが請求書の上に乗ります。判定が割れた案件は、たいてい無償の再作業になります。提案の前に、条件の文を相手の二人に読ませて「これで判定できますか」と聞くだけで、書き直すべき箇所が分かります。
A&Aの考え方
この一件は無償の時間です。見合うかどうかは条件付きです。対象の業務が定型で、同種の案件が月に複数回発生し、検証の先に継続の余地がある場合には見合います。年に数回しか起きない業務や、検証の金額が一件の作業原価を下回る場合は、完成例まで作ると赤字が確定します。その場合は、完成例を作る代わりに、過去に買い手自身が作った成果物を一件もらい、それを合格の見本として条件文に添える方法があります。こちらの工数は増えず、判定の基準は具体になります。
確認する人と、確認にかかる時間を明細に載せる
A&Aの考え方
合格条件が書けたら、次は誰がいつ判定するかです。三つを提案書に書きます。確認する人を役職で一人。確認の方法は、その人がすでに使っている手順。そして確認にかかる時間の見込み。三つ目を書かない検証は、よく止まります。
出典に基づく事実
同記事は、評価における成果を、その試行の終わりにおける環境の最終状態だと定義しています。航空券を予約するエージェントが、やり取りの末尾で「ご予約が完了しました」と述べたとしても、成果は予約が環境のSQLデータベースに存在するかどうかである、という説明です。
A&Aの考え方
A&Aがここから有料PoCの合意に持ち込むのは、確認を成果物の後段の状態で書くという点です。「ドラフトが生成された」ではなく「工事部長が手を入れずに顧客へ送れた」を合格にする。完了の確認手順そのものをどう設計するかは別の論点で、実装側の扱いは「AIが「完了」と言ったあと、業務の成果をどう確かめるか」で扱っています。ここで決めるのは、その確認を誰の時間で行い、その時間を合意の中でどう扱うかです。
A&Aの考え方
買い手側に確認の時間がないと、検証はAIの性能とは無関係の理由で止まります。提案の段階で「この十件を確認するのに、どなたが何時間使えますか」と聞いてください。時間が取れないという答えなら、件数を減らします。十件を五件にして期間を延ばすほうが、十件のまま判定されずに終わるより結果が残ります。ここを聞かずに出した見積もりは、相手の工数をこちらが勝手に予算へ入れた状態です。
仮想例
架空の例に戻ると、確認する人は工事部長。方法は、顧客提出前に部長が報告書を読んで署名するという既存の手順そのまま。時間は一件十五分として十件で二時間半。この二時間半を提案書の期間欄に明記し、二週間のうちどの日に取るかまで決めておきます。部長が現場に出ている週に十件をまとめて渡すと、確認が翌週へ流れ、検証の結論が出ないまま期間が終わります。数字はいずれも説明のための仮の値です。
有料PoC合意書の一枚
A&Aの考え方
ここまでを一枚にします。十行です。対象業務。案件の選定者と件数。通るべき例。人へ渡すべき例とその合格条件。基準となる完成例。確認する人。確認の方法。確認にかかる時間。モデルや手順を変えたときの再確認の扱い。検証のあとに続ける条件と、やめる条件。この十行が埋まらないうちは、有料にしないという判断ができます。埋まらない理由はたいてい、対象業務がまだ一つに絞れていないことです。
仮想例
架空の例で埋めると、次のようになります。対象業務は、現場から届いた作業報告から顧客提出用の報告書ドラフトを作ること。案件は工事部長が過去半年の書き直し案件から十件を選定。通るべき例は七件で、手を入れずに顧客へ送れること。人へ渡すべき例は三件で、読めなかった項目名と聞き直すべき点が書かれていること。完成例は選定された十件のうち一件を提案前に当方が作成し、部長が受入可否を回答。確認は工事部長が既存の署名手順で行い、一件十五分、合計二時間半、期間は二週間。モデルや手順を変えた場合は同じ十件で再確認し、検証期間中の再確認は当方の負担。続ける条件は、七件のうち六件以上が手直しなしで通り、かつ三件が正しく返ること。やめる条件は、通らなかった案件の理由が三種類以上に散ること。件数と時間はすべて説明のための仮の値です。
A&Aの考え方
最後の二行、続ける条件とやめる条件は、相手のためだけにあるのではありません。やめる条件が書いてあると、こちらも撤退できます。「六件通れば続ける」と書いた紙があれば、四件しか通らなかったときに無償の追加開発へ流れ込まずに、原因を持ち帰って設計をやり直す、という選択が取れます。やめる条件のない検証は、売り手にとって期限のない保証になります。
途中でモデルや手順を変えたら、誰が再確認するか
出典に基づく事実
Lovableのページでは、プロダクトを率いるPesantが、各モデルの更新を追ってきたと述べ、その理由をどのモデルも前のものより良いからだと説明しています。同ページは、Claude Sonnet 3.5が初めてエージェントを機能させたモデルであり、Claude Opus 4.5が長期にわたる作業の信頼性における次の大きな段差となって新しい種類のプロジェクトを可能にした、というPesantの発言も載せています。一方でAnthropicの評価解説は、評価は待つほど作りにくくなると述べ、初期は製品の要件が自然に試験項目になるが、待ちすぎると稼働中のシステムから成功基準を逆算することになると説明しています。
A&Aの考え方
受託でも同じことが起きます。検証の途中で、あるいは本契約に入ってから、使うモデルを上げ、プロンプトを書き換え、前処理を足します。そのたびに、前は通っていた案件が通らなくなる可能性があります。ここで検証の資産が効きます。買い手が選び、合否を書いた十件は、そのまま回帰確認の集合になります。検証が終わった時点でこれを捨てると、次の変更のたびに合否の基準を作り直すことになります。出典の言うとおり、後から作るほうが難しくなります。
A&Aの考え方
決めるのは負担の所在です。選べる形は三つあります。一つ、こちらの負担で、変更時に必ず同じ十件を再確認する。保守の月額に含める形です。二つ、買い手の負担で、変更のたびに確認の時間をもらう。買い手側の工数が発生するので、あらかじめ合意が必要です。三つ、期間中はモデルと手順を固定し、変更は次の契約に回す。どれが良いかは対象業務の変化の速さで決まりますが、書いていない場合の実態は「こちらが無償で全部やる」になります。一行で済むので、提案書に入れておきます。
この設計が向かない場面と、次の一歩
A&Aの考え方
向かない場面から書きます。買い手の予算がまだ確定しておらず、社内の稟議に必要なのは「これは技術的に可能である」という証拠だけ、という段階があります。ここにこの十行を持ち込むと、商談は止まります。相手がまだ判断できないことを判断させようとしているからです。この段階で速いのは、無償の短いデモと、対象範囲を書いた一枚です。有料の検証は、予算が付いて、社内の担当者が決まってからのほうが機能します。順番を間違えると、丁寧な提案が失注の理由になります。
A&Aの考え方
数字の限界も書いておきます。20件から50件という出典の目安は製品のエージェント評価についてのもので、単一の顧客の検証に転用できる数ではありません。同種の案件が六件しか出てこなければ六件で始めます。完成例を一件作る手順も、検証の金額が作業原価を下回る場合には成り立ちません。検収条件の法的な効力、相手の購入意思、本契約への移行率は、いずれも一次資料が保証するものではなく、この記事が示しているのはA&Aの設計案です。
出典に基づく事実
Lovableのページには、公開から12か月で年間換算収益2億ドルに達し、現在は4億ドルであること、プラットフォーム上で5000万件を超えるプロジェクトが作られ、1日あたり20万件を超えること、そこで作られたアプリが月に6億回を超える訪問を集めていることが記載されています。大企業の利用としてUber、HubSpot、Zendeskの名前が挙げられています。
A&Aの考え方
これらはベンダーが自ら公表した数値で、母数、期間、定義、比較の条件は示されていません。独立した検証でもありません。日本の一人あるいは数人の会社が同じ業務を引き受けたときの見込みとして使えるものではないので、この記事では数値ではなく、評価の設計の考え方だけを取り出しています。もう一つ重要な違いがあります。Lovableは数千万件のプロジェクトを抱える製品で、難しい案件で外した分を全体の中で吸収できます。一顧客の有料の検証にその緩衝はありません。十件のうち三件外すと、三割ではなく「うまくいかなかった」と受け取られます。両方の出典は製品の評価設計について書かれたもので、受託契約の条項への読み替えはA&Aの仮説です。
A&Aの考え方
次の一歩です。そもそも何を最初の商品として売るかが決まっていないなら、「AI受託の最初の商品を決める：一人で売れる業務単位の切り出し方」を先に読んでください。完了の確認そのものを実装としてどう作るかは「AIが「完了」と言ったあと、業務の成果をどう確かめるか」に分けてあります。顧客獲得から継続までの流れの中でこの検証がどこに入るのかは「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」で確認できます。問い合わせを受けてから見積もりを出すまでの受付を整える段階なら「問い合わせから見積もりまでをAIでつなぐ：小さな受託会社の不足情報の整理」が近いです。対象業務が一つに定まり、十行が埋まる状態まで来ているなら、その範囲のままスコープを切って開発に進められます。
有料の検証の提案書に機能と期間と金額だけを書くと、終わったときに合否を決める人がいません。検証する案件は買い手に選ばせ、AIが書かずに人へ渡すべき案件も合格の一種として先に並べ、値付けの前に一件だけ自分で完成させてみる。確認する人を役職で一人指名し、その人が使う時間を明細に書く。モデルや手順を変えたときの再確認を誰が負担するかまで書けば、十行で足ります。ただし相手の予算がまだ付いていない段階では、この十行はまだ早い。無償の短いデモと、範囲を書いた一枚を先に渡してください。
出典・編集情報
記事の調査で確認した一次資料です。資料の公開・更新時期と、調査時の確認日を分けて記載しています。
- Lovable Claude Platform (API) case study
Anthropic · n.d. (no date shown on page)
確認日 2026-09-23 - Demystifying evals for AI agents
Anthropic · 2026-01-09
確認日 2026-09-23
AIを活用した記事制作
調査・執筆・翻訳・編集上の確認にAIを活用しています。資料に基づく事実、A&Aの考え方、仮想例は、それぞれ本文に明記しています。
編集上の確認日: 2026-09-23