building-with-llms

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 を監督させるのは効果的です。認知的なステップを重ね、あるモデルが生成し、別のモデルがレビューします。これにより、精度を 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：「一つの作業をするたびに、次の作業を簡単にしましょう。うまくいったプロンプトを保存し、ライブラリを作りましょう。チームのAI活用力は積み重なるほど高まります。」

AI ツールを活用する

構文を暗記するのではなく、コードを読んでデバッグする方法を学ぶ Amjad Masad：「AIがコーディングの力を高めるため、コーディングの投資対効果は6か月ごとに2倍になります。コードを読むこととデバッグに注力しましょう。構文はAIが処理してくれます。」

チャットモードで理解を深める Anton Osika：「『チャットモード』を使って、AIにそのロジックを説明してもらいましょう。『なぜこうしたのですか？ 何を見落としていますか？』と尋ねてください。家庭教師のように活用しましょう。」

バイブコーディングは実際に役立つスキルです Elena Verna：「私はバイブコーディングを履歴書に書きました。エンジニアリングチームに引き継ぐ前に、自然言語で機能するプロトタイプを作りましょう。」

ユーザーへの質問

• 「何を作っていて、ユーザーの中心的な課題は何ですか？」
• 「モデルが最もよく間違えるのは何ですか？」
• 「成功を体系的に測定していますか。それとも感覚に頼っていますか？」
• 「モデルはどのようなコンテキストにアクセスできますか？」
• 「少数例のサンプルを試しましたか？」
• 「失敗したプロンプトを再試行すると、どうなりますか？」

注意すべきよくある間違い

• いつまでも感覚頼み - いずれは「なんとなく良さそう」だけでなく、実際の評価が必要です
• プロンプトだけに注目する - 多くの場合、解決策はプロンプトの改善ではなく、コンテキストの改善です
• 何にでも同じモデルを使う - モデルによって得意なタスクは異なります
• 一度失敗しただけで諦める - 確率的なシステムでは再試行が必要です
• 人間によるレビューを省く - AIの出力には人間による検証が必要です。特に初期段階では欠かせません

詳細

60人のゲストによる110の洞察すべてについては、references/guest-insights.mdをご覧ください。

関連スキル

• AIプロダクト戦略
• AI評価
• バイブコーディング
• 新技術の評価