{
  "title": "AIアプリケーションのための力技MVP",
  "excerpt": "AIアプリケーションにおける最小実行可能製品(MVP)の概念を探求し、ユーザーのニーズを効果的に理解し対応することで価値を提供することに焦点を当てます。",
  "content_html": "<p>最小実行可能製品(MVP)とは、初期顧客が使用できる最低限の機能を備えた製品のバージョンであり、その後の製品開発のためのフィードバックを提供できるものです。</p>\n\n<p>今日は、AIアプリケーションをリリースする際にそれがどのようなものかに焦点を当てたいと思います。そのためには、4つのことを理解するだけで十分です。</p>\n<ul>\n<li>80%とは実際に何を意味するのか?</li>\n<li>どのセグメントに優れたサービスを提供できるか?</li>\n<li>それを強化できるか?</li>\n<li>優れたサービスを提供できないセグメントについてユーザーを教育できるか?</li>\n</ul>\n\n<p>パレートの法則(80/20の法則としても知られる)は依然として適用されますが、あなたが考えるのとは異なる方法で適用されます。</p>\n\n<h3>MVPとは何か?</h3>\n<p>この概念を理解するために私がよく使う例えは次のとおりです:地点Aから地点Bへ移動するための何かが必要です。おそらくビジョンは車を持つことです。しかし、MVPは車輪やエンジンのないシャーシではありません。代わりに、スケートボードのようなものかもしれません。リリースして、製品にブレーキやステアリングが必要だと気づきます。そこでスクーターをリリースします。その後、スクーターにはより多くのレバレッジが必要だと分かり、より大きな車輪を追加して自転車になります。人間として適用できる力に制限されているため、モーターについて考え始め、原付、電動自転車、オートバイへと分岐できます。そしていつか、車をリリースします。</p>\n\n<h3>80/20の法則を考える</h3>\n<p>何かが80%完成している、または80%準備ができていると言うとき、それは通常、機械学習の意味です。この文脈では、各コンポーネントは決定論的であり、80%は10個の機能のうち8個が完成していることを意味します。残りの2つの機能が準備できたら、製品をリリースできます。しかし、80/20の法則に従いたい場合、80%の機能で製品をリリースし、残りの20%を後で追加できるかもしれません。ラジオやエアコンのない車のようなものです。しかし、80%の意味は大きく異なる可能性があり、この定義はAI駆動のアプリケーションには当てはまらないかもしれません。</p>\n\n<h4>要約統計の問題</h4>\n<img src=\"/assets/images/anscombes_quartet.png\" alt=\"Anscombe's quartet\" class=\"post-img\" width=\"1200\" height=\"873\" />\n<p>上の画像はアンスコムの四重奏の例です。これは、ほぼ同一の単純な記述統計を持ちながら、非常に異なる分布と外観を持つ4つのデータセットのセットです。これは、要約統計がなぜ誤解を招く可能性があるかを説明する古典的な例です。</p>\n\n<p>次の例を考えてみましょう:</p>\n\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>score</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>0.8</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>5</td>\n            <td>0.0</td>\n        </tr>\n        <tr>\n            <td>6</td>\n            <td>0.0</td>\n        </tr>\n    </tbody>\n</table>\n\n<p>平均スコアは0.58です。しかし、セグメント内のクエリを分析すると、大多数のクエリに非常に優れたサービスを提供していることがわかるかもしれません!</p>\n\n<blockquote>\n<p><strong>自分が苦手なことを認める</strong></p>\n<p>自分が苦手なことに正直であることは、ユーザーとの信頼を築く素晴らしい方法です。何かがうまく機能しないときを正確に識別し、自信を持ってそれを拒否できるなら、アプリケーションの制限についてユーザーを教育しながら、優れた製品をリリースする準備ができているかもしれません。</p>\n</blockquote>\n\n<p>システムの制限を理解し、要約統計を超えてシステムの特性を自信を持って理解できることは非常に重要です。これは、すべてのシステムが同じように作られているわけではないからです。確率的システムの動作は、前の例とは大きく異なる可能性があります。次のデータセットを考えてみましょう:</p>\n\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>Score</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>.59</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>.58</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>.59</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>.57</td>\n        </tr>\n    </tbody>\n</table>\n<p>このようなシステムも平均スコアは0.58ですが、リクエストのサブセットを拒否するのはそれほど簡単ではありません...</p>\n\n<h3>ノーと言うことを学ぶ</h3>\n<p>クエリの大部分がタイムラインクエリに関するRAGアプリケーションを考えてみましょう。検索エンジンがこの時間制約をサポートしていない場合、おそらく良好なパフォーマンスを発揮できないでしょう。</p>\n\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>Score</th>\n            <th>Query Type</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>0.9</td>\n            <td>text search</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>0.8</td>\n            <td>text search</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>0.9</td>\n            <td>news search</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>0.9</td>\n            <td>news search</td>\n        </tr>\n        <tr>\n            <td>5</td>\n            <td>0.0</td>\n            <td>timeline</td>\n        </tr>\n        <tr>\n            <td>6</td>\n            <td>0.0</td>\n            <td>timeline</td>\n        </tr>\n    </tbody>\n</table>\n\n<p>リリースを急いでいる場合、これらの質問がタイムラインの質問かどうかを検出する分類モデルを構築し、警告を表示するだけで済みます。アルゴリズムをより良くしようと常に努力する代わりに、ユーザーを教育し、製品の設計方法を変えることで彼らを教育できます。</p>\n\n<blockquote>\n<p><strong>セグメントの検出</strong></p>\n<p>これらのセグメントの検出は、さまざまな方法で実現できます。分類器を構築したり、言語モデルを使用して分類したりできます。さらに、埋め込みを使用したクラスタリングアルゴリズムを利用して共通グループを識別し、各グループ内の平均スコアを分析できる可能性があります。唯一の目的は、特定のサブグループ内の活動の理解を深めることができるセグメントを識別することです。</p>\n</blockquote>\n\n<p>最悪なことの1つは、ユーザーベースのより重要なセグメントを無視しながら、生産性をわずかに向上させるだけの機能の構築に数ヶ月を費やすことです。</p>\n\n<p>アプリケーションを再設計し、その制限を認識することで、拒否できるタスクの種類を識別することにより、特定の条件下でパフォーマンスを向上させる可能性があります。このセグメントデータを何らかのシステム内観測可能性に組み込むことができれば、どの程度の質問が拒否されているかを安全に監視し、カバレッジを最大化するために作業の優先順位を付けることができます。</p>\n\n<h3>実行する前に実際に何をしようとしているのかを把握する</h3>\n<p>スタートアップと仕事をしていて気づいた危険なことの1つは、AIがまったく機能すると考えがちなことです...その結果、正確に何を達成したいかをあまり考えずに、大規模な汎用アプリケーションを提供できるようにしたいと考えます。</p>\n\n<p>私の意見では、これらの企業のほとんどは、1つまたは2つの重要な領域に焦点を当て、ターゲットとする良いニッチを特定しようとすべきです。アプリが1つまたは2つのタスクが得意であれば、アプリケーションをテストしてすぐにフィードバックを得るために100人または200人のユーザーを見つけられないはずがありません。一方、アプリケーションが何も得意でない場合、記憶に残り、繰り返し使用されるものを提供することは困難です。バイラリティを得るかもしれませんが、すぐにユーザーの信頼を失い、解約を減らそうとする立場に陥ります。</p>\n\n<p>GPT-4を使用して予測を行う能力が前倒しされている場合、フィードバックまでの時間は非常に重要です。すぐにフィードバックを得られれば、すぐに反復できます。すぐに反復できれば、より良い製品を構築できます。</p>\n\n<h3>最終的な考え</h3>\n<p>AIアプリケーションのMVPは、80%の機能を備えた製品をリリースするほど単純ではありません。代わりに、優れたサービスを提供できるユーザーのセグメントを深く理解し、優れたサービスを提供できないセグメントについてユーザーを教育する能力が必要です。システムの制限を理解し、ニッチに絞り込むことで、記憶に残り、繰り返し使用されるものを提供する製品を構築できます。これにより、すぐにフィードバックを得て、すぐに反復でき、最終的には力技の領域を特定することで、より良い製品につながります。</p>",
  "source_hash": "sha256:628188f6afb27695d03e01274d59eb0b52134258149bbac07bab13c678413b93",
  "model": "claude-sonnet-4-5-20250929",
  "generated_at": "2026-01-15T20:08:39.493401+00:00"
}