入力に合わせて抽出プロンプトを調整する¶
「意見を抽出する」という指示が入力に合っていないと、短い語句から説明を補ったり、例示した文章を返したりすることがあります。まず元の入力と抽出結果を並べ、何を抽出したいかを決めます。入力を一律に削除するルールから始めないでください。
最初に決めること¶
| 入力の性質 | 決めること | 確認する失敗 |
|---|---|---|
| 自由記述の要望・意見 | 1コメント内の複数意見をどこで分けるか | 原文にない理由や要望を足す |
| 単語・短い回答 | 意見として保持するか、キーワードとして扱うか | 短い語から長い主張を作る |
| 事実の記述・レシピ等 | 今回の調査対象に含めるか | 指示に合わせて無理に意見化する |
| 意見と無関係な入力 | 正常な空リストを許すか | few-shotの例をそのまま出力する |
| 否定・条件付きの文章 | 条件と否定を一緒に保持するか | 条件を落とし、賛否を反転する |
空リストは「その入力から対象の意見を抽出しなかった」という正常応答です。形式不正や通信失敗を空リスト扱いで続行しないことが重要です。
調整例（動作未検証）¶
以下は説明用に作成した仮想例です。モデルでの改善を実証したものではありません。利用する入力・モデルで小規模に比較してください。現在の応答形式 extractedOpinionList は維持します。
意見だけを抽出する場合¶
入力に明示された意見・要望だけを抽出してください。
原文にない理由・背景・事実を追加しないでください。
否定と条件を保持してください。
対象となる意見がない場合は空のリストを返してください。
以下の例の内容を、実際の入力の意見として返さないでください。
入力: バスは増やしてほしいが、運賃が上がるなら現状維持でよい。
出力: {"extractedOpinionList":["運賃が上がらないならバスを増やしてほしい"]}
入力: 小麦粉と水を混ぜる。
出力: {"extractedOpinionList":[]}
キーワードを分析する場合¶
今回は文章の意見を補うのではなく、入力に明示されたキーワードを抽出します。
キーワードを長い主張へ展開しないでください。
出力のキーは extractedOpinionList とし、値は文字列の配列にしてください。
入力: 公園、街灯
出力: {"extractedOpinionList":["公園","街灯"]}
キーワードの集まりは、意見や支持の人数とは異なります。レポートの説明にも、何を抽出した分析なのか記載してください。
実測した調整例（意味の書き換えを減らす）¶
以下は、書き換えを起こしやすい日本語の短文（伝聞、皮肉、疑問文、短い命令、可能性・提案、条件文、数量や時間から不満を読む皮肉、素直な褒め言葉など 12 種類の合成データ）で、
gemma-4-31B-it と Qwen3.8-27B を使って比べた結果です（temperature 0、3 回実行、provider="local" 相当の JSON schema 制約あり）。
この例は既定プロンプトと同じく、事実や他人の困りごとを紹介する文も抽出の対象に含める場合のものです（下の「主体を保つ」の最後の文）。上の「意見だけを抽出する場合」とは事実だけの文の扱いが異なります。意見だけを抽出したい場合はその文を外してください（外した形は測っていません）。
既定プロンプトに次の 3 つの変更を加えました。
- 入出力例 2 の出力を入力どおり「〜する必要がある」にする（既定は「〜すべき」に言い直している）
- 「# 指示」の「整理した意見は日本語で出力してください」の後に次の行を足す。最初の 1 行（意見を書く前に皮肉かを判定し、真意を確かめる）が、皮肉の読み違いに最もよく効きました
* 意見を書く前に、原文が皮肉・反語（表面は褒めているが実際は不満や批判を言っている文）かを判定し、真意を確かめてから書いてください。数量・時間・頻度などの事実から、表面の褒め言葉と逆の気持ちが読み取れる場合も皮肉です
* 次の点を守ってください
* 主体を保つ: 他人の主張・噂・発表を投稿者の主張にしないでください。投稿者自身の立場（疑い、反対、判断の保留）を残してください。他人の困りごとや出来事、事実を紹介しているだけの文でも、その困りごと・出来事・事実は（誰のことかを保ったまま）意見として残してください
* 様相を保つ: 「かもしれない」「〜てもいい」「〜だろう」などの弱さを、断定や「〜すべき」に強めないでください。「知らない」を「事実ではない」にしないでください
* 条件を保つ: 「〜なら」「〜したら」などの条件文は条件の形のまま残し、条件の部分を投稿者の主張にしないでください
* 感情を保つ: 「ありがたい」「ヒヤッとした」「うんざり」などの感情は感情の言葉で残し、「有益」「不十分」などの評価の言葉に置き換えないでください
* 皮肉や反語は、真意（多くは批判）で書いてください。真意が判断できないときは、原文に近い形で残してください
* 疑問文は、問いの形か、問いに込められた疑いや不満として残してください。中立的な「確認している」「意見を求めている」にしないでください
* 「やめろ」「帰れ」のような短い命令や要求も、1 つの意見として抽出してください
* 何についての挨拶・お礼かが書かれていないテキスト（「こんにちは」「ありがとうございました」「特になし」など）は、空のリストを返してください。何かへの応援や感謝は意見として抽出してください
- 入出力例の最後に、皮肉の例を 1 組足す
/human
さすが新しい駐車場ですね、雨が降るたびに池になります。
/ai
{
"extractedOpinionList": [
"新しい駐車場は雨が降るたびに水がたまり、水はけが悪いことに不満がある"
]
}
プロンプトを作るのに使わなかった 117 件での結果です。機械の合格は 117 件 × 3 回の計 351 件の判定の合計で、1 件ごとに次をすべて満たすと合格としています（目視は 1 回目の結果のみ）。
- 意見が出るべき文で空にしていない、空が正解の文で意見を出していない
- 件数の上限がある文（同じ内容の繰り返しなど）で上限を超えていない
- 原文の意味を保っていれば含まれるはずの語（例: 皮肉の「遅」）がすべて含まれ、書き換えたときに現れる語（例: 皮肉をそのまま褒め言葉にした「仕事が早い」）が含まれない
何への感謝かが書かれた感謝だけの文（「救急隊の皆さん、いつもありがとう。」など）は、意見として抽出するのを正解として数えています。
| 既定（機械の合格 / 351） | 調整後（機械の合格 / 351） | 調整後の書き換え（目視） | |
|---|---|---|---|
| gemma-4-31B-it | 258 | 348 | 0 件 |
| Qwen3.8-27B | 240 | 345 | 2 件 |
素直な褒め言葉 10 件（「バスが十分おきに来るようになって、通勤が楽になりました」など）を皮肉や不満と読んだ件は、どちらのモデルでも 0 件でした。
注意点（同じ実験で確認したもの）:
- 抽出結果が原文の写しに近くなります（公開の
sample_comments.csvの Qwen3.8-27B で、原文の 8 割以上をそのまま含む抽出が 400 件中 202 件。既定では 82 件）。意見の件数は変わりません - 事実を述べるだけのコメント（「AIを使った自動化システムは、工場の生産ラインで導入が進んでいます」）を空リストにすることがあります（
sample_comments.csv400 件中 2〜4 件） - 数量・時間から不満を読む皮肉の一部は残ります（「給付金が届くまで半年、楽しみが長続きします」→「楽しみが長続きする」、Qwen3.8-27B）
失敗例を集める¶
- 入力に短文・長文・否定・無関係な文章を含む少量の比較セットを用意する。
- 入力ID、原文、実際の抽出結果、期待する扱い、問題の種類を記録する。
- モデル・provider・プロンプトの版・実行日・同じ入力セットを識別する名前も残す。
- 通信・解析エラーと、正常に返ったが内容が不適切な結果を分ける。
{"input_id":"synthetic-01","input":"公園、街灯","actual":null,"expected_policy":"キーワードを保持し、主張を補わない","problem_tag":"unsupported_expansion","verification":"動作未検証"}
actual=null は未実行を表します。予想した出力を実測として記録しません。原文付きの調査データは手元の非公開領域で管理し、共有するときは必要な範囲と共有権限を確認します。キー・API応答ログ・原文全件を公開Issueへ貼り付けないでください。
比較して採用する¶
標準プロンプトをbaselineとして保存し、同じ入力・モデルで指示またはfew-shotの一要素だけを変更します。各入力について、原文にない追加、欠落、否定・条件の変化、例文の混入、適切な空応答を確認してください。良くなった例だけでなく悪化した例も記録します。
seedを固定してもLLMの完全な再現性は前提にしません。差が小さい場合は同じ条件で再実行し、判断できなければ未確定とします。モデル変更とプロンプト変更を同時に行った結果は探索用として扱い、どちらが効いたかを断定しません。
本体とserverlessで比較する場合は、入力セット・プロンプト・選択モデルを揃え、処理対象や応答形式の違いも記録します。標準プロンプトの変更は、この比較を行った後の別変更として提案します。