プロトタイプ
読み: プロトタイプ
プロトタイプとはAI開発の試作工程
プロトタイプは、製品やサービスの試作版を指す。完成品を作り込む前に、核となるアイデアを形にして検証する工程である。ソフトウェア開発では画面のモックアップから動くデモアプリまで、粒度は様々。AI活用の文脈では、PoCと混同されやすいが、両者の目的は明確に異なる。
かんたんに言うと
建築でいう模型のようなもの。実際に建てる前に「この間取りで本当に住みやすいか」を確認するための試作品。壊して作り直す前提で作る。
技術検証のPoCとユーザビリティ検証のプロトタイプの境界線
PoCは「そもそもこの技術で実現可能か」を確認する。プロトタイプは「実現できると分かった上で、どう作れば使いやすいか」を検証する。順番としてはPoCが先、プロトタイプが後になる。
ところが実際のプロジェクトでは、この区別が曖昧なまま進むことが多い。「とりあえず動くものを見せてくれ」という依頼に応えているうちに、PoCなのかプロトタイプなのか誰にも分からない中間物が出来上がる。
区別が重要な理由は、評価基準が違うからである。PoCで問うのは「技術的に可能か」。プロトタイプで問うのは「ユーザーが使えるか」。この問いを混ぜると、どちらの検証も中途半端に終わる。
MVPとの関係と使い分け
MVP、Minimum Viable Productは「最小限の機能で市場に出せる製品」を意味する。プロトタイプは市場に出さない。社内のステークホルダーやテストユーザーに見せて、フィードバックを得るための道具である。
プロトタイプで方向性を固め、MVPで最初の顧客を獲得し、そこからプロダクトに育てていく。この流れはリーンスタートアップの基本型として広く知られている。
ただし、BtoBの業務システム開発ではMVPという概念がそのまま当てはまらないケースも多い。「最小限」で出した機能が業務に使えなければ、顧客の信頼を失うだけである。プロトタイプの段階で業務フローとの整合性を徹底的に詰めることが、BtoBでは特に重要になる。
AIによるプロトタイピングの加速
コード生成AIの登場で、プロトタイプの作成スピードは劇的に変わった。CursorのようなLLM統合エディタを使えば、画面設計からバックエンドのAPIまで、従来の数分の一の時間で動くものが組み上がる。
Figmaのプロトタイプ機能とAIを組み合わせれば、デザイナーがコードを書かずにインタラクティブなデモを作ることもできる。
とはいえ、速く作れることと正しく検証できることは別の話である。AIが生成したコードでサクッと動くプロトタイプを見せると、経営層が「もう完成じゃないか」と勘違いするリスクがある。プロトタイプはあくまで仮説検証の道具であり、本番品質とは別物であるという認識を関係者全員で共有しておく必要がある。
失敗しないプロトタイプの進め方
検証したい仮説を1つに絞ること。これに尽きる。
「UIの操作性を検証したい」と「データの精度を検証したい」を1つのプロトタイプに詰め込むと、どちらの問題でユーザーが困っているのか切り分けられなくなる。
検証項目を決めたら、そこに関係のない機能は一切作らない。ログイン画面も、管理画面も、エラーハンドリングも後回しでいい。
もうひとつ大事なのは、捨てる覚悟を持つこと。プロトタイプに時間をかけるほど「せっかく作ったから」という心理が働き、検証結果が微妙でも本開発に進めてしまう。最初から「これは捨てる前提の試作品」と宣言しておくことで、冷静な判断がしやすくなる。
当社の見解
技術の選定で最も避けるべきは「流行っているから」という理由で導入することだ。当社は複数のAIツール・フレームワークを実際に検証した上で、自社の用途に合うものだけを採用している。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。実装指示した人間側が実装したことも忘れて、気が付けば動いていない機能があった、ということも起きる。さらに、MCPやフックやルールを増やしすぎてAIが情報過多で機能しなくなった経験もある。どんなにルールや機能を付け足しても機能しなければ意味がない。足し算より引き算。1週間の検証期間が、3か月の手戻りを防ぐ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。