プロンプト改善を「1回の満点」で判断してはいけない ─ 10回回して分かったこと
Hiroba による自動要約
介護記録から情報を抽出するLLMプロンプトを、自作の評価ロジックで改善した事例。1回の実行で満点を取ったプロンプトも、10回繰り返すと不安定であることが判明。フィールドごとの重み付けと見逃し・過剰抽出の検出で、最終的に10回中10回の満点まで改善したプロセスと知見をまとめている。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 789 件あります。
関連する記事
同じタグの記事
「敵対的レビュアー」スキルパターンの活用でClaudeの弱点を克服
RedditReddit ユーザーが「敵対的レビュアー」プロンプトパターンを使用することで、Claude の出力品質に関する長年の課題を解決できたと報告。このスキルパターンは、Claude に対して批判的・厳密な視点から自らの回答を検証させることで、より堅牢で信頼性の高い結果を引き出すテクニック。
2026年のプロンプトエンジニアリング：「コンテキストエンジニアリング」への転換
Qiita推論モデルの進化と超ロングコンテキスト対応により、「どう聞くか」から「何を渡すか」へスキルの中心が移動。構造化データの設計、RAGの精度重視、情報配置の最適化といったコンテキスト設計が、production環境で勝つための必須スキルになったことを解説。
Claude との対話で設計する IT 作業手順書の構造化プロンプトフォーマット
ZennITインフラエンジニアが手順書を LLM に食わせやすい形で標準化するため、Claude と協働して XML と YAML を組み合わせた構造化フォーマットを設計。セクション境界の明示性・指示理解の精度向上・出力の自動化が Markdown 比で優れる一方、トークン消費は 1.3-1.5 倍増加。プロンプトキャッシュ活用と再質問削減でトータルコストは逆転する実装パターンを解説。
システムプロンプトの設計を本気で考える：形式選択・構造化・言語をAIと議論した結果
ZennMarkdown・XML・YAML・JSONなど複数の形式でシステムプロンプトを書く場合、混在は逆効果で単一形式の選択が推奨される。XMLはタグで境界が明示的で構造制御に優れ、Markdownは短くシンプルな場合に向く。セクション数や文字数を目安に形式を選定し、特に参照制御やインジェクション対策が必要な場合はXML構造化が有効。