「とりあえず要約して」と「目的を伝えて要約して」で、AIの出力はどれだけ変わるか"

同じ架空の障害報告書を、簡潔な「要約して」と、読み手・目的・構造・分量を盛り込んだ「上司への一次報告用」の2種類のプロンプトで、Claude Sonnet 5、GPT-5.6 Luna、Gemini 3.5 Flash-Liteに投げ比べた検証記事だ。各条件は2回ずつ実行されている。著者は、目的明示プロンプトは「目的明示だけ」の効果を切り出したものではなく、実務でありがちなプロンプト設計全体の効果だと断っている。

結論から言えば、目的を書くと出力は確かに変わる。結論が先に来て、専門用語が消え、社内報告らしい形になる。ここは狙い通りだ。しかし面白いのは、変わったことの中身である。Claude Sonnet 5は両方の実行で、原文の「DB接続プールの枯渇」を別の言い方に作り替えていた。平易にしたつもりが、原因の中身がすり替わっているわけだ。読み手を安心させる言葉が事実の芯をずらすのは、業務で一番怖い失敗である。1回目の実行では影響人数が組織数に変わる誤りも出た。一方でGPT-5.6 Lunaは原因を一段抽象化しつつも、原文にない別の原因を作ることはなかった。Gemini 3.5 Flash-Liteも「結論:」と明示して結論ファーストを徹底したが、原因の説明は抽象化されていた。分かりやすく言い換える力と、事実を守る力は別物で、モデルによってその釣り合いが違うということだ。

中小企業の実務に効く一言は、「分かりやすくして」と頼むなら、数字・固有名詞・原因の語を原文と突き合わせる一手間を必ず入れる、ということだ。目的を書くこと自体は有効だが、目的を書いた途端に要約が正しいと錯覚しやすくなる。社内報告やお客様向けの文書にAIの要約を使うなら、「原因」「数字」「対応期限」の3点だけは元の資料と並べて確認する。読みやすさはAIに任せ、正確さのチェックは人間が担う。この役割分担を最初から決めておくのが現実的だ。