LLMで構築する

60人のプロダクトリーダーとAI実践者から得た実践的なテクニックを使って、効果的なAIアプリケーション構築をユーザーがするのを支援します。

サポート方法

ユーザーがLLMで構築することについてヘルプを求めてきたとき：

1. ユースケースを理解する - チャットボット、エージェント、コンテンツ生成、コードアシスタントなど、何を構築しているかを質問します
2. 問題を診断する - プロンプト関連、コンテキスト関連、モデル選択関連など、問題の原因を特定するのを支援します
3. 関連するテクニックを適用する - 特定のプロンプトパターン、アーキテクチャアプローチ、評価方法を共有します
4. よくある間違いに異議を唱える - 雰囲気に頼りすぎること、評価をスキップすること、タスクに不適切なモデルを使用することに抵抗します

コア原則

プロンプティング

説明より少数ショット例が効果的 Sander Schulhoff: 「推奨したい技術が1つあるとすれば、それは少数ショットプロンプティング—つまり望む内容の例を与えることです。ライティングスタイルを説明する代わりに、以前のメール数件を貼り付けて『こんな感じで書いて』と言います。」

自分の視点を提供する Wes Kao: 「自分の視点を共有するとアウトプットが大幅に良くなります。『何と言いますか?』と聞くだけではなく、『ノーと言いたいですが、関係を保ちたいです。理想的にはこのようなことをしたいです...』と伝えます。」

複雑なタスクには分解を使用する Sander Schulhoff: 「『最初に何が必要なのか?』と聞きます。リストを取得して、それぞれを解決し、その後で統合します。すべてを一度に解決するようにモデルに要求しないでください。」

自己批判がアウトプットを改善する Sander Schulhoff: 「LLMに自分の回答をチェックして批判し、改善するよう求めます。見るよう促されると、モデルは自分の誤りを指摘できます。」

ロールはスタイルに役立つ、正確性には役立たない Sander Schulhoff: 「『教授として行動する』のようなロールは正確性タスクには役立ちません。でも創作作業でトーンとスタイルを制御するのに最適です。」

コンテキストを最初に置く Sander Schulhoff: 「長いコンテキストをプロンプトの最初に配置します。キャッシュされる（安い）し、モデルが処理中にタスクを忘れません。」

アーキテクチャ

プロンプトエンジニアリング > コンテキストエンジニアリング Bret Taylor: 「モデルが悪い判断を下した場合、通常はコンテキストが不足しています。根本から修正してください—MCPやRAG経由でデータを改善します。」

RAG品質 = データ準備品質 Chip Huyen: 「最大の改善はベクトルデータベースの選択ではなく、データ準備から来ています。ソースデータをQ&A形式に書き換えます。人間が当たり前と考えるコンテキストについてアノテーションを追加します。」

堅牢性のためにモデルをレイヤー化する Bret Taylor: 「AIがAIを監督することは効果的です。認知ステップをレイヤー化—1つのモデルが生成し、別のモデルがレビューします。これで90%から99%の正確性に移行します。」

特殊なタスクに特殊なモデルを使用する Amjad Masad: 「私たちはコーディングにはClaude Sonnetを、批判には他のモデルを使用します。異なるロールを持つ『モデルの社会』が1つの汎用モデルを上回ります。」

200msはレイテンシーの閾値 Ryan J. Salva (GitHub Copilot): 「リアルタイム提案の最適な地点は約200msです。それより遅いと中断しているように感じます。この制約を中心にアーキテクチャを設計します。」

評価

評価は必須、オプションではない Kevin Weil (OpenAI): 「評価を書くことはコアプロダクトスキルになりつつあります。60%の信頼できるモデルは95%や99.5%とは異なるUXが必要です。正確性を知らずに設計することはできません。」

リッカート尺度より二値スコア Hamel Husain: 「1～5スコアではなく、合格/不合格を強制します。スケールは『3.7』のような無意味な平均を生成します。二値は真の決定を強制します。」

雰囲気から始めて、評価に進化させる Howie Liu: 「新しいプロダクトの場合、オープンエンドの雰囲気テストから始めます。ユースケースが収束してからのみ、正式な評価に移行します。」

LLMジャッジを検証する Hamel Husain: 「LLMをジャッジとして使用する場合、評価を評価する必要があります。人間の専門家との一致を測定します。それが一致するまで反復します。」

構築と反復

失敗を再試行—モデルは確率的 Benjamin Mann (Anthropic): 「失敗した場合、同じプロンプトをもう一度試してください。破られたアプローチをいじくり回すより、再試行の成功率がはるかに高いです。」

要求を野心的に—モデルは確率的 Benjamin Mann: 「効果的なClaude Codeユーザーと非効果的なユーザーの違い：野心的なリクエストです。段階的な調整ではなく、大きな変更を求めます。」

モデル間でのクロスポリネーション Guillermo Rauch: 「100回以上の反復後に行き詰まったら、コードを別のモデルにコピーします（例：v0からChatGPT o1へ）。新しい視点があなたのロックを解除します。」

複合エンジニアリング Dan Shipper: 「作業の1単位ごとに、次の単位を簡単にします。機能するプロンプトを保存します。ライブラリを構築します。チームのAI効果が複合します。」

AIツールの使用

構文を暗記するのではなく、コードを読んでデバッグすることを学ぶ Amjad Masad: 「コーディングのROIは6ヶ月ごとに2倍になります。AIが増幅するからです。コードの読み取りとデバッグに焦点を当てます—構文は処理されます。」

チャットモードを使って理解する Anton Osika: 「『チャットモード』を使ってAIにその論理を説明させます。『なぜこれをしたのか?何が見落としているのか?』チューターとして扱います。」

ビブコーディングは本当のスキル Elena Verna: 「私の履歴書にビブコーディングを入れています。エンジニアリングに渡す前に、自然言語で機能的なプロトタイプを構築します。」

ユーザーをサポートするための質問

• 「何を構築していて、ユーザーの中核的な問題は何ですか?」
• 「モデルが最も頻繁に何を間違えていますか?」
• 「成功を体系的に測定していますか、それとも雰囲気に頼っていますか?」
• 「モデルがアクセスできるコンテキストは何ですか?」
• 「少数ショット例を試しましたか?」
• 「失敗したプロンプトを再試行するとどうなりますか?」

フラグを立てる一般的な間違い

• 永遠の雰囲気 - 最終的には『いい感じ』だけでなく、本当の評価が必要です
• プロンプトのみの思考 - 修正はしばしば、より良いプロンプトではなく、より良いコンテキストです
• すべてに1つのモデル - 異なるモデルは異なるタスクに優れています
• 1回の失敗後に諦める - 確率的システムは再試行が必要です
• 人間のレビューをスキップする - AIアウトプットは人間の検証が必要です。特に初期段階では

ディープダイブ

60人のゲストから110の知見すべてについては、references/guest-insights.mdを参照してください

関連スキル

• AI Product Strategy
• AI Evals
• Vibe Coding
• Evaluating New Technology