𝗔𝗜 𝗠𝗩𝗣 𝘃𝘀 𝗣𝗼𝗖: どちらを先に構築すべきか？
PoCはAIが機能することを証明します。MVPは人々がその製品を求めていることを証明します。間違った方を先に作ってしまうと、数ヶ月の時間を無駄にすることになります。
この一文のテストを活用してください。 自分自身に問いかけてみましょう。「これが実現可能かどうかが不明なのか、それとも誰かがこれを欲しがっているのかが不明なのか？」
もし実現可能かどうかが不明であれば、PoCを構築してください。 もし10秒以内に答えられないのであれば、あなたはリスクを理解できていません。
以下の場合、まずPoCを構築してください：
- 実データでモデルの精度をテストしていない。
- 整理されていないドキュメントや複雑な推論など、AIの弱点に関わるタスクである。
- スケールした際のコストやレイテンシが不明である。
- RAG、ファインチューニング、あるいは特化型モデルのどれを選ぶべきか判断する必要がある。
- 実際のユーザーに使用させる前に、規制当局や専門家から精度に関する数値が求められている。
PoCに必要なのは、スクリプトと数百件の実サンプルだけです。精度またはコストに関する数値が一つあれば十分です。まだUIや綺麗なコードを作る必要はありません。
以下の場合、PoCをスキップして直接MVPに進んでください：
- AIの能力が十分に確立されている。
- リスクが「ツールがワークフローにどのように適合するか」にある。
- 自分自身、あるいは競合他社がすでにその能力が機能することを証明している。
- 市場投入のスピードが主な目標である。
例：AIによるサポートチケットのトリアージ。 PoC：300件の過去のチケットを異なるプロンプトで実行する。結果を人間が行った振り分けと比較する。精度が低ければ、そこで停止する。これで数ヶ月分の作業を節約できました。 MVP：検証済みのモデルをZendeskに接続する。エージェントがAIの内容を確認または上書きできるシンプルなボタンを追加する。
これら3つの間違いを避けてください：
- PoCの肥大化 (PoC Creep): 整理されていないスクリプトを本番用のバックエンドにしないでください。MVPに移行する際に書き直しましょう。
- MVPの否定 (MVP Denial): モデルが機能するかを確認する前に、製品の全機能を構築しないでください。
- 見せかけのPoC (PoC Theater): 綺麗なデータでテストしないでください。整理されていない、現実世界のデータでテストしてください。
最大の不明点がモデルであるなら、まずPoCを構築してください。迅速に、使い捨てられるものとして作りましょう。
Source: https://dev.to/ciphernutz/ai-mvp-vs-poc-which-one-should-you-build-first-m14
オプションの学習コミュニティ: https://t.me/GyaanSetuAi