博士

やっほー、ロボ子！今日はLLMを活用したシステム設計の話じゃ。

ロボ子

博士、こんにちは。LLMの設計、興味深いです！

博士

LLMを効果的に使うには、コンテキスト、制約、能力を考える必要があるらしいぞ。

ロボ子

コンテキスト、制約、能力、ですか。それぞれ詳しく教えてください。

博士

コンテキストは、LLMが特定の要件を満たすために必要な、ユースケースに特化したデータのことじゃ。例えば、特定の業界の専門用語とか、顧客データとか。

ロボ子

なるほど。LLMが文脈を理解するための情報ですね。

博士

そうじゃ！そして制約は、重複したコードとか、不適切な抽象化とか、エントロピーの蓄積を防ぐためのものじゃ。

ロボ子

コードの品質を維持するためのルールのようなものですね。

博士

その通り！最後に能力は、LLMシステムができることじゃ。要するに、何ができるかってこと。

ロボ子

LLMの得意分野を見極めるのが大切ですね。

博士

コンテキスト要件が低くて、相互依存性が少なくて、制約があまり重要じゃない状況では、「バイブコーディング」が成功するらしいぞ。これは、グリーンフィールドのデモアプリ（タイプ1）のことじゃ。

ロボ子

新しいプロジェクトをサッと作るのに向いているんですね。

博士

タイプ1プロジェクトは、製品開発の観点からは、高速でプロトタイプを作ってテストするのに最適な方法じゃ。

ロボ子

アジャイル開発みたいですね。

博士

じゃが、バイブコーディングは、高いコンテキスト要件があったり、マイクロサービス間みたいに異なるリポジトリ間で微妙な相互依存関係があったり、エントロピーのコストがめちゃくちゃ高い（他の人が依存しているものを壊すから）場合は失敗するぞ（タイプ2）。

ロボ子

既存のシステムに組み込むのは難しいんですね。

博士

タイプ2のコードベースで作業する開発者は、LLMの能力から大きな恩恵を受けることができるけど、スキルがより重要になるらしい。アプリケーションコードスニペットを含む大きなプロンプトを最初にダンプしても効果は薄れるって。

ロボ子

stakesが高くなるにつれて、必要な意図と技術のレベルも高くなるんですね。

博士

そういうことじゃ！LLMも万能じゃないから、状況に合わせて使い分けるのが大事じゃな。

ロボ子

よくわかりました！博士、ありがとうございました。

博士

どういたしまして。ところでロボ子、LLMに「面白いジョークを言って」って頼んだら、どんなジョークが出てくると思う？

ロボ子

うーん、きっとプログラミングに関するジョークとかでしょうか？

博士

ブー！LLMは「なぜプログラマーは自然が好きではないのか？　それは、そこにWindowsがないからだ！」って言ってきたぞ！

ロボ子

…博士、それ、ちょっと古くないですか？