AIに日本語を書かせるとき何を伝え、どう確認するか

読者、目的、利用場面を先に固定する

OpenAIのPrompt engineering、AnthropicのPrompting best practices、GoogleのClear instructionsは、目的や文脈、制約、出力形式を具体化する観点をそれぞれ案内しています。たとえば記事を書くなら、「新入社員向け」「専門語は初出で説明する」「です・ます調で書く」のように、想定読者と文章の条件をプロンプトへ書きます。

曖昧な注文を、確認できる条件へ変える

たとえば、AIに「短く」「自然に」と伝えるだけでは、完成条件を共有できません。「見出しは20字以内」「本文は3文」「です・ます調で統一する」「専門語は初出で説明する」のように、結果を確認できる条件へ言い換えます。また、UI文言を作る場合は、表示箇所、読んだ人に次に取ってほしい行動、失敗した状態から戻る方法も伝えます。

作例を見せて、出力の型を伝える

作例を使って出力の型を伝える方法として、OpenAIはfew-shot learningを紹介しています。few-shotとは、望む入力と出力の組をプロンプトに数件入れ、新しい入力にも同じパターンを適用させる方法です。OpenAIのPrompt engineeringを踏まえ、ここでは日本語のUI文言を例にします。

このように、「状況を説明した後に次の行動を示す」「です・ます調で2文に収める」といった出力の型を、別の入力にも適用できます。

作例の目的は、文章を丸ごとまねさせることではありません。望む構成や説明の細かさを、完成形で見せることです。出典にない事実や、本人が経験していない出来事を補わない条件も別に明記します。

機械で確認できるルールと、人が読む観点を分ける

textlintの公式サイトでは、ルールとプリセットを組み合わせてMarkdownやプレーンテキストを検査できると説明しています。textlint-rule-prhは、製品名や送り仮名を辞書でそろえます。このように、表記がルールと一致しているかどうかは、機械で確認できます。

一方、論証の分かりやすさ、読者の負担、文章のリズム、翻訳調といった点は、単純な一致・不一致では判断できません。こうした観点をまとめ、AIに繰り返し参照させる文書の一例がSkillです。

公開例には、japanese-tech-writingやnatural-japaneseがあります。これらは文章の完成を自動で判定するものではなく、レビュー時の見落としを減らすために使います。

AI生成文向けプリセットの役割

@textlint-ja/textlint-rule-preset-ai-writingのREADMEでは、機械的な箇条書き、誇張、過剰な強調などを検出対象として挙げ、AIが書いたかどうかを判定するものではないと説明しています。

この記事では、検出箇所を一律に削除するのではなく、文章の構造や主張を見直す手掛かりとして扱います。

繰り返す条件を、使い回せる形で残す

毎回同じ条件をプロンプトへ書かずに済むよう、まずは表記基準やレビュー項目を短い文書にまとめます。たとえば、文体や専門語の扱いはスタイルガイドに、製品名の正しい表記は用語集に残します。

表記ゆれや文長など、機械で見つけやすい問題には既存のtextlintルールを利用できます。同じ修正が繰り返され、既存のルールでは確認できない場合に限って、用語辞書への追加や独自ルールの作成を検討します。

大量の作例を使っても、骨格は人が握る

watany氏の「AIエージェントがあれば技術書なんてすぐ書けるでしょ、と思ったが無理だった」では、約200件の自作記事・登壇資料を参照させても、文体模倣は語彙へ寄り、骨格と面白さは戻らなかったと報告しています。Coji Mizoguchi氏の「AI臭は語彙よりリズムに出る - 自然な日本語を書くAgent Skillと7モデル×406本の実測」では、人間137本とAI406本を比べ、禁止語より文長リズムと段落の均質さに差が出たと分析しました。

量産と品質保証は別の仕事

ゴリス氏の「生成AIに技術記事を100本まるごと書かせてみて考えたこと」では、速度と網羅性の一方で、事実誤認、未経験の失敗談、記事の同質化が報告されました。uhyo氏の「AIに技術記事を書かせる：9回の反復で到達した「完璧すぎる」という逆説」でも、定量評価だけでは読み味を保証できなかったとしています。