LLMで記事・技術文書を作るときに品質を保つ実務ガイド

LLM原稿で最初に疑うべき点

LLMで生成した原稿は、文章として自然に読めるほど、誤りを見逃しやすくなります。

最初に疑うべきなのは、文体のぎこちなさではありません。優先して確認する必要があるのは、次の4点です。

1. 読者の質問に答えているか 2. 事実、数値、日付、固有名詞が正しいか 3. 引用や参考リンクが実在し、本文の主張を支えているか 4. 読者が誤った操作や判断をしない構成になっているか

OpenAIは、言語モデルが不確かな場合でも推測によって答えを作ることがあり、評価方法によっては「分からない」と答えるより推測する行動が促されると説明しています。

公式解説: https://openai.com/index/why-language-models-hallucinate/

そのため、LLM原稿を確認するときは、「文章として読めるか」より先に、「どの主張が外部確認を必要とするか」を切り分けます。

元のZenn記事では、Claude Codeで参照する文章規範の有無によって、同じ題材から生成される技術記事の表現がどう変わるかが比較されていました。文章規範は、冗長さ、強調表現、結論の反復、説明順序を整えるうえで役立ちます。

ただし、文章規範で改善できるのは、主に表現と構造です。

これらは別工程で人が確認する必要があります。

• 製品仕様が正しいか
• 料金が現在も同じか
• コマンドが実行できるか
• 引用元が主張を裏付けているか
• 法的、医療的、金融的な判断が妥当か

基本情報

本ガイドは、万能な自動化手法を提示するものではありません。

LLMは、構成案、下書き、言い換え、要約、表の作成、確認項目の抽出などに利用できます。ただし、公開責任は原稿を掲載する側にあります。

Google Searchも、生成AIの利用自体ではなく、読者にとって有用で信頼できる内容かどうかを重視すると説明しています。検索順位を操作する目的で、価値の低いページを大量生成する行為は、スパムポリシーの対象になり得ます。

Google公式ガイド: https://developers.google.com/search/docs/fundamentals/using-gen-ai-content

企画と検索意図を先に固定する

LLMへいきなり「詳しい記事を書いて」と依頼すると、情報量は多いものの、読者の質問に答えない原稿ができやすくなります。

生成前に固定するべきなのは、記事タイトルではなく、読者が読み終えた時点で判断できることです。

例えば、「Ollamaが起動しない」というテーマなら、読者の到達点は次のように具体化できます。

この到達点が決まれば、記事へ入れる情報と削る情報を判断できます。

• エラーの意味を理解する
• 最初に確認するコマンドを選ぶ
• 再起動、更新、再導入のどこまで必要か判断する
• データを消す操作を避ける
• 直らない場合に残す情報を把握する

企画と検索意図を先に固定する：企画段階で固定する項目

最低限、次の項目を生成前に決めます。

企画と検索意図を先に固定する：検索意図と記事構成を一致させる

検索者が障害解決を求めている場合、冒頭に長い背景説明を置くべきではありません。

最初に、確認する順番や結論を示し、その後に理由を説明します。

一方、「製品を導入するべきか」を調べている読者には、次の情報が必要です。

• 何ができるか
• 何ができないか
• 対応環境
• 料金
• データの扱い
• ライセンス
• 安定性
• 代替手段
• 見送る条件

事実・引用・固有名詞を確認する

LLM原稿の確認では、文章を最初から最後まで読むだけでは不十分です。

先に、外部確認が必要な記述を抽出します。

事実・引用・固有名詞を確認する：優先して確認する記述

次の項目は、原則として元資料を開いて確認します。

「よく知られている情報」に見える場合でも、変更される可能性がある項目は確認が必要です。

特に料金、API仕様、提供地域、モデル名、ベータ機能は、記事作成時点で正しくても短期間で変わる可能性があります。確認日を記載し、現在の公式ページへ読者を誘導します。

• 製品名、企業名、人物名
• バージョン番号
• 公開日、更新日、終了日
• 料金、無料枠、上限
• 対応OS、対応言語、対応モデル
• API、SDK、コマンド、設定項目
• ライセンス
• 利用条件
• セキュリティやデータ保存に関する説明
• 性能値、比較結果、導入実績
• 法律、規約、ポリシー
• 引用文
• 参考リンク

事実・引用・固有名詞を確認する：一次資料を優先する

情報源は、次の順で確認します。

1. 公式ドキュメント 2. 公式リポジトリ 3. 公式リリースノート 4. 公式ブログ、公式ヘルプ 5. 論文、規格、行政資料 6. 開発者本人や運営者本人の記事 7. 信頼できる第三者記事 8. 掲示板、SNS、まとめ記事

第三者記事は調査対象を見つける手掛かりに留め、製品仕様や料金は可能な限り公式情報で確定します。

事実・引用・固有名詞を確認する：引用はリンクの実在だけで判断しない

参考リンクが開けることと、本文の主張を裏付けていることは別です。

引用確認では、次の3点を確認します。

• リンク先が実在する
• 該当箇所に本文の主張が書かれている
• 文脈を変えずに要約している

事実・引用・固有名詞を確認する：固有名詞は文字単位で確認する

固有名詞の誤りは、記事全体の信頼性を大きく下げます。

次のような間違いが起こりやすいため、公式表記と照合します。

見出し、本文、表、コードブロック、リンク文言で表記が統一されているかも確認します。

• 大文字と小文字の違い
• ハイフンの有無
• 製品名と企業名の混同
• 旧名称と現名称の混在
• 類似サービス名との取り違え
• CLI名、パッケージ名、リポジトリ名の混同

長文を読める構造に直す

LLMは、同じ結論を表現を変えて繰り返すことがあります。

長文原稿では、文章を足すより、各セクションの役割を明確にして重複を削ることが重要です。

長文を読める構造に直す：基本情報の役割

基本情報は、記事の前提を短時間で確認するために置きます。

対象製品、対応環境、確認日、提供形態、公式URLなど、本文中に散らばると確認しにくい情報をまとめます。

長文を読める構造に直す：結論の役割

結論では、読者が最初に取るべき行動や、現時点で確定している判断を示します。

障害解決記事なら、確認する順番を短く示します。

比較記事なら、どの条件で候補が変わるかを示します。

ニュース記事なら、何が発表され、何が未発表なのかを分けます。

結論で背景説明を始めると、読者が必要な情報へ到達しにくくなります。

長文を読める構造に直す：本文の役割

本文では、結論の理由、確認手順、例外、注意点を説明します。

一つの段落に、手順、理由、例外、感想を混ぜないようにします。

技術手順では、コマンドを先に置くだけでなく、次の順番で説明すると確認しやすくなります。

1. 何を確認するコマンドか 2. 実行前の注意 3. コマンド 4. 期待される結果 5. 結果ごとの次の操作

実行結果が環境によって変わる場合は、正常例だけでなく、判断基準を説明します。

長文を読める構造に直す：参考資料の役割

参考リンクは、本文を書いたことの証明として並べるのではなく、読者が再確認できる導線として配置します。

重要な仕様や注意事項は、本文の近くにもリンクを置きます。記事末尾には利用した一次資料をまとめ、必要に応じて「料金確認」「API仕様」など用途を添えます。

公開直前に確認する最小項目

公開直前の確認は、文章校正、事実確認、動作確認、公開判断に分けます。

公開直前に確認する最小項目：1. 読者の質問に答えているか

冒頭、見出し、結論を読み、次を確認します。

タイトルが「復旧手順」なら、原因の一般論だけでは不十分です。タイトルが「導入ガイド」なら、機能紹介だけでなく、料金、条件、見送る基準が必要です。

• タイトルと本文が一致している
• 対象読者が明確になっている
• 読後に判断できることが示されている
• 本題と関係の薄い説明が長く続いていない
• 未確認情報を結論に使っていない

公開直前に確認する最小項目：2. 事実を確認したか

数値、日付、固有名詞、仕様、料金、リンクを抽出し、元資料と照合します。

確認できない内容は、次のいずれかで処理します。

• 削除する
• 「公式情報で確認できず」と明記する
• 紹介者の評価として分離する
• 仮説として明確に示す
• 公開を保留する

公開直前に確認する最小項目：3. 手順を実行できるか

コマンド、設定、コード例がある場合は、対象環境で確認します。

最低限、次を確認します。

実行確認できない場合は、「動作確認済み」と書かないでください。公式手順の紹介なのか、執筆者が試した手順なのかを分けます。

• コマンド名が正しい
• オプションが現行バージョンで使える
• 実行場所が説明されている
• 管理者権限の要否が分かる
• 削除や上書きの影響が説明されている
• 元に戻す方法がある
• 秘密情報が含まれていない

公開直前に確認する最小項目：4. 読みやすさを確認したか

最後に文章を整えます。

Microsoft Writing Style Guideは、技術情報を明確で簡潔に書き、読者が必要な操作を理解しやすい表現を使うことを重視しています。

公式ガイド: https://learn.microsoft.com/en-us/style-guide/welcome/

文章校正ツールやtextlintは表記揺れや括弧漏れの検出に使えますが、事実確認や安全性の判断はできません。

• 同じ結論を繰り返していない
• 一文が長すぎない
• 主語が途中で変わっていない
• 指示語が何を指すか分かる
• 箇条書きの粒度がそろっている
• 表が本文の重複になっていない
• 強調表現が多すぎない
• 「画期的」「必須」「完全」などの誇張に根拠がある

公開直前に確認する最小項目：5. 読者に渡せる状態か

最後に、公開するか差し戻すかを判断します。

次のどれかに該当する場合は、公開せず確認工程へ戻します。

• 結論を支える一次資料がない
• 製品名や対象が特定できない
• 料金や提供状況が古い可能性が高い
• コマンドの影響範囲が分からない
• 引用元を確認できない
• 読者が損失を受ける可能性がある
• 法的、医療的、金融的な判断を含む
• 個人情報や秘密情報が残っている
• 生成した架空の事例や実績が含まれている

人が判断すべき場面

特に、次の場面は人が判断します。

人が判断すべき場面：情報源が食い違う場合

公式ブログ、ヘルプ、料金ページ、管理画面で説明が異なることがあります。

この場合は、更新日、対象地域、対象プラン、対象バージョンを確認します。それでも判断できなければ、矛盾があることを記事内に明記し、断定を避けます。

人が判断すべき場面：安全性や損失に関係する場合

ファイル削除、データベース更新、課金設定、権限変更、セキュリティ設定などは、文章として正しく見えても影響が大きい操作です。

バックアップ、影響範囲、復旧方法が確認できない手順は掲載しません。

人が判断すべき場面：法律、医療、金融を扱う場合

LLMによる一般的な整理を、個別判断の代わりにしてはいけません。

法令、規制、診断、投資判断、税務処理などは、最新の一次資料と専門家による確認が必要です。記事では一般情報の範囲を明示します。

人が判断すべき場面：独自性や価値を判断する場合

公開品質を上げるために重要なのは、文章を人間らしく見せることではありません。

これらが編集者の役割です。

LLMは下書きの速度を上げますが、公開の可否を決めるものではありません。生成、検証、編集、公開を別工程として扱うことが、品質を保つ基本になります。

• 読者の質問を理解する
• 一次資料を選ぶ
• 重要な違いを見つける
• 未確認事項を残す
• 危険な操作を止める
• 公開する責任を持つ