実践 レッスン 4 / 7

効果的なプロンプティング

人々はフレームワークを学ぶのに何週間も費やすのに、 AI とのコミュニケーションを学ぶ時間はゼロ。 そして結果が悪いとモデルを責める。

「出力がダメなら、入力がダメだった。これは避けられない。」

本当に効果があること

  • 具体的に:「認証を作って」は曖昧。「セッションベースの認証を bcrypt で、 PostgreSQL セッションストレージ、HTTP-only Cookie」は具体的。
  • やらないことを伝える:「シンプルに。頼んでない抽象化を追加しないで。 DI フレームワークなし。」
  • なぜかのコンテキストを与える:「これは毎リクエストで実行される」は アプローチを完全に変える。コンテキストが実装を形作る。

Claude は過剰設計しがち。これを予測しましょう。 シンプルなものが欲しいときは「シンプルな実装」や 「不要な抽象化なし」と明示的に言ってください。

公式

良いプロンプトはパターンに従います:

  1. 具体的は曖昧に勝つ
  2. 制約はオープンエンドに勝つ
  3. は説明に勝つ

Claude に欲しいものの例を見せられるなら、 言葉で説明するより10倍の価値があります。

モデル選択

Sonnet

速くて安い。道筋が明確なときの実行に良い。 明確に定義されたタスクの実装に使用。

Opus

遅くて高い。複雑な推論と計画に良い。 アーキテクチャ決定と難しい問題のデバッグに使用。

ワークフローのコツ:Opus で計画し、Sonnet で実装する。 Shift+Tab でモデルを切り替えられます。

重要なポイント

  • 悪い入力 = 悪い出力。例外なし。
  • 具体的に、制約を加え、例を見せる
  • やらないことを伝える(過剰設計しがち)
  • 計画は Opus、実装は Sonnet