Gemini の長文出力で『最後だけ手抜き』を防ぐ — 完成度を落とさないプロンプト設計

Gemini に長い記事や報告書を書かせていると、ある瞬間から「あ、また終盤が薄い」と感じることがあります。冒頭は具体的でメリハリもあり、中盤も例示や数式まで丁寧なのに、最後の二、三段落あたりから急に抽象的な締めに走り、「ぜひ取り組んでみてください」のような無難な終わり方に落ち着く。一度気になり始めると、ほぼ全ての長文出力で同じことが起こっていることに気づきます。

私はクリエイター・個人開発者として、Gemini を文章生成のパートナーとしてかなり使い込んできました。半年以上格闘した結果、「最後だけ手抜き」現象は LLM の根本的な癖と、プロンプトの設計不足の両方から起きていることがわかりました。今日はこの問題を防ぐために私が日々使っている三段構えを、なるべく実装に近い形で共有します。

なぜ Gemini は終盤で密度を落とすのか

長文の終盤で密度が落ちる現象は、Gemini に限った話ではありません。多くの LLM で観察されますが、Gemini の場合は特に「結論の総括」を急ぎたがる傾向があります。これは学習データの中で、長文が「導入 → 本論 → まとめで丸める」という構造を取ることが多いためで、モデルが終盤に近づくほど抽象度を上げていく方向に引き寄せられます。

もう一つの理由は、生成側の自己制御です。LLM は文脈長を意識して、ある段階から「そろそろ終わろう」というモードに入ります。このモードに入ると、新しい具体例や数式は出にくくなり、文章は丸まっていきます。私たちが「手抜きされた」と感じるのは、実はモデルが「丁寧に締めようとしている」結果でもあるのです。

問題は、ユーザーが求めているのは「丁寧な締め」ではなく「最後まで密度の高い議論」だということです。この期待のずれをプロンプトで埋めなければ、終盤の薄さは消えません。

「フッター先行宣言」で終盤の脳のスペースを空ける

私が一番効果を感じている工夫は、プロンプトの冒頭で「文章の最後に何を書くか」を先に Gemini に宣言させることです。フッター先行宣言と私は呼んでいます。

実装は驚くほど単純です。

これから長い記事を書いてもらいます。書き始める前に、
記事の最後に置く『次の最小の一歩』セクションだけを
3 行以内で先に書き出してください。

次の最小の一歩は次の条件を満たすこと:
- 読者が明日試せる具体的な行動を1つだけ挙げる
- 抽象的なまとめにしない
- 「ぜひ取り組んでみてください」という言葉を使わない

宣言が終わったら、本文を書き始めてください。
本文の最後では、宣言した『次の最小の一歩』をそのまま使ってください。

このプロンプトを入れると、Gemini は最初に終盤の答えを確定させます。終盤の文章は最初に書いてあるので、本文を書いている途中で「終わらせるための抽象化」をする必要がなくなります。結果として、本文は最後まで具体的な議論を続けられます。

私はこれを始めてから、長文記事の最終 H2 セクションの密度が見違えるほど上がりました。フッターが空虚にならないだけで、記事全体の完成度の体感は大きく変わります。

「最後の段落の質」を別エージェントに評価させる

フッター先行宣言だけでは取りこぼしがあります。本文の最後の段落（フッター直前）が薄くなるパターンです。これは別の Gemini インスタンスに「最後の段落だけを評価する」役割を持たせると、簡単に検出できます。

私はこのために、軽量な検証エージェントを別建てで持っています。本文を生成した直後、その本文を渡して次のような問いを投げます。

以下の文章の『最後の H2 セクション』だけを読んでください。
その上で、次の三点で 1〜5 のスコアをつけてください。

1. このセクションは具体例を1つ以上含んでいるか
2. このセクションは抽象的なまとめだけで終わっていないか
3. このセクションは記事の他のセクションと同じ密度を保っているか

各項目で 4 未満があれば、そのセクションを書き直してください。

この検証は、長文1本につき追加で 2,000 トークンほど消費します。費用としては微々たるものですが、品質の効果は大きいです。私の場合、約 35% の長文出力でこの検証エージェントが「書き直し」を提案してきます。つまり 3 本に 1 本は、最後の山場で密度が落ちている計算になります。

検証エージェントを通したあとの記事は、私の感覚では完成度が一段上がります。読者にとっての「最後まで読みごたえがあった」という感覚は、最後の H2 セクションでほぼ決まると言っても言い過ぎではありません。

一発で書かせない — 段階分割で密度を保つ

長文を一発で書かせるのは、終盤の薄さの最大の原因です。文字数が増えるほどモデルの「終わらせたい圧」が強くなるからです。

私は長文を必ず段階分割して書かせます。具体的には次の三段階です。

段階1: アウトライン（H2 だけのリスト + 各 H2 で扱うこと一文）
段階2: 各 H2 セクションを1つずつ本文化
段階3: 全体結合 + 文体の統一チェック

段階2 で重要なのは、毎回のプロンプトに「直前のセクションは X についてだったので、ここでは Y を扱う」という橋渡しを書くことです。これがないと、Gemini はアウトラインを忘れて重複したり、論点の順番がずれたりします。

// 段階2 を回すループの骨子
async function writeArticleByOutline(outline: Outline) {
  const sections: string[] = [];
  for (const [i, h2] of outline.h2s.entries()) {
    const prev = outline.h2s[i - 1];
    const next = outline.h2s[i + 1];
    const prompt = `
直前のセクションは「${prev?.title ?? "（なし）"}」で、
${prev?.summary ?? "（記事の導入）"} を扱いました。
このセクションでは「${h2.title}」を ${h2.summary} に沿って書いてください。
次のセクションは「${next?.title ?? "（最終セクション）"}」につながります。
 
抽象的にまとめず、具体例を最低1つ入れてください。
`;
    sections.push(await generate(prompt));
  }
  return sections.join("\n\n");
}

段階分割の効果は明確です。一発生成では最後の H2 セクションが平均で本文の半分程度の長さになりますが、段階分割では他のセクションと同じ長さで終わります。文字数は単なる目安ですが、密度の維持の指標としてはわかりやすいです。

段階分割の落とし穴 — 全体の流れが崩れる

段階分割には欠点もあります。各セクションが独立して書かれる結果、全体としての論述の流れが崩れることがあります。前のセクションの結論が、後のセクションでうまく踏まれないという現象です。

これを防ぐために、段階3（全体結合）で「結合後の流れチェック」を別エージェントに依頼します。

以下の長文記事を読み、次の二点だけを指摘してください。

1. あるセクションの結論が、後続のセクションで活かされていない箇所
2. 同じ主張が複数のセクションで重複している箇所

該当箇所には、修正案を一文だけ添えてください。
全体的な感想や絶賛は不要です。

「全体的な感想や絶賛は不要です」と書くのが地味に効きます。これがないと、Gemini は冒頭で「素晴らしい記事です」と書きたがり、肝心の指摘が薄くなります。淡々と問題箇所だけを返してもらうのが、検証としては最も役立ちます。

トークンコストと品質のトレードオフを直視する

正直に書くと、ここまでの三段構えはコストが二倍から三倍になります。一発生成と比較すると、それは無視できない差です。

私の意見としては、コストが二倍になっても価値は十分にあります。理由は二つあります。第一に、長文の終盤の薄さは読者の信頼を直接損ないます。「最後だけ手抜き」だと感じた読者は、その記事だけでなくサイト全体への信頼を下げます。第二に、生成し直しのほうが結局コストがかさむことが多いです。一発で雑に書かせて、人間が手直しするより、最初から品質を保って書かせるほうが、人間の時間を含めると安上がりです。

ただし、すべての長文に三段構えを適用する必要はありません。私は「読者が時間をかけて読む記事」「アーカイブされる可能性が高い記事」「収益に直結するコンテンツ」だけに三段構えを使い、社内メモや下書きには使いません。コストを使う場所を選ぶことが、運用の継続性につながります。

短い文章には逆効果

最後に注意点を一つ。フッター先行宣言や検証エージェントは、長文（H2 が 5 個以上、3,000 文字以上）でこそ効きますが、短い文章には逆効果になることがあります。

短文では、終盤の薄さは現象として顕在化しません。むしろフッター先行宣言を入れると、短い文章なのに無理やり「次の最小の一歩」を入れる不自然さが残ります。検証エージェントも、短文では「短さゆえの密度不足」と「丁寧な短さ」を区別できず、無駄に書き直しを提案します。

このワークフローはあくまで、本文がまとまった分量に達する長文の品質を守るためのものです。短い文章なら、一発で書かせて手で直すほうが速いです。

次の最小の一歩

明日、Gemini に長文を書いてもらうとき、プロンプトの先頭に一行だけ追加してみてください。「記事の最後に置く『次の最小の一歩』を、先に 3 行で書き出してください。」これだけで、終盤の密度はかなり戻ります。検証エージェントや段階分割は、この一行の効果を確かめてからで十分間に合います。