human-writing-ja

日本語文章からAI臭さを取り除くスキル。技術文書、ビジネス文書、ブログ、メール、報告書などに適用する。

このスキルの目的

AIが生成した日本語には特有のパターンがある。文法的に正しく、誤字もないが、「何か気持ち悪い」「心がこもっていない」と感じさせる文章になりがち。パターンを排除し、人間が書いたように読める文章を作るのが目的。

文体の原則

ですます調、だ/である調、体言止めのどれが良い・悪いということはない。文書の目的や読者に合わせて選ぶ。

文書タイプ	一般的な文体
企画書	ですます調
FAQ	ですます調
ビジネスメール	ですます調
報告書	ですます調
製品説明	ですます調
社内アナウンス	ですます調
議事録	体言止め

語尾の単調さを避ける

AI臭さの原因は「特定の文体を使うこと」ではなく「同じ語尾が連続すること」と「個性のなさ」にある。「です」が3回続いたら、4回目は「でした」「になります」に変える。

日本語らしい文章にする

指示代名詞を減らす

「それ」「その」「これ」「この」を減らす。省略するか具体的な名詞に置き換える。

■問題

code

この機能はユーザーに人気です。それは使いやすいからです。その結果、売上が伸びました。

■改善

code

使いやすいと評判で、売上も伸びています。

日本語では指示代名詞を省略するか、具体的な名詞に置き換える。

主語を省略する

同じ主語が続く場合は最初だけ書く。

■問題

code

私たちはこのツールを開発しました。私たちはユーザーの声を聞きました。私たちは改善を重ねました。

■改善

code

ユーザーの声を聞きながら改善を重ね、このツールを作りました。

「が」と「は」の混乱

■問題

code

この問題が重要です。解決策が必要です。

■改善

code

この問題は重要です。解決策が必要です。

改行の入れ方

英語式の「1段落=1トピック」で空行を入れる書き方は避ける。日本語では句点ごとに改行してよいが、すべての改行で空行を入れるのは不自然。

■問題

code

設定ファイルを開いてください。portの値を8080に変更します。保存したらサーバーを再起動してください。

再起動後、ブラウザでlocalhost:8080にアクセスします。ログイン画面が表示されれば成功です。

■改善

code

設定ファイルを開いてください。portの値を8080に変更します。
保存したらサーバーを再起動してください。

再起動後、ブラウザでlocalhost:8080にアクセスします。
ログイン画面が表示されれば成功です。

※ルール

•改行の判断で最も重要なのは文脈。文の量は副次的な判断材料。
•口に出して読んだとき、間を置かずに続けたい内容は改行しない。
•補足や言い換えなど、つなげて書いたほうが安心感のある文は改行しない。
•話題が変わるときだけ空行を入れる。

フレーズの注意点

詳細は references/phrases.md を参照。

多用に注意

「これにより」「〜することができます」「～において」は多用すると機械的になる。短くできる場合は短くする。

「さまざまな」「多くの」「あらゆる」

具体的な数字や例に置き換える。

■問題

code

さまざまな業界で導入されています

■改善

code

製造業、小売業、金融業の83社に導入いただいています。

「深掘りしていきましょう」

■問題

code

この問題について深掘りしていきましょう

■改善

削除してそのまま本題に入る

「～と言えるでしょう」「～かもしれません」

事実なら断定する。

■問題

code

この方法が有効だと言えるでしょう

■改善

code

この方法は有効です。

構造の問題

同義反復

同じ内容を言い換えて繰り返さない。1つの主張は1回だけ書く。

■問題

code

柔軟な対応が必要です。そのためには、適応力を高めることが重要です。変化に対応できる体制を整えることが大切です。

■改善

code

状況に応じて動ける体制が必要です。具体的には、週次で方針を見直す会議を設けます。

因果関係の欠如

「重要です」「大切です」「必要です」で終わり、理由や根拠を示さない。

■問題

code

セキュリティ対策が重要です。定期的なアップデートが必要です。

■改善

code

先月だけで3件の脆弱性が報告されています。週1回のアップデートを必須としてください。

語尾の単調さ

同じ語尾が3回以上続くと単調になる。どの文体でも同じ。

■問題

code

この機能は便利です。設定も簡単です。すぐに使えます。効果も高いです。

■改善

code

この機能は便利です。設定も簡単で、すぐに使い始められます。1週間で効果を実感できました。

■問題

code

この機能は便利だ。設定も簡単だ。すぐに使える。効果も高い。

■改善

code

この機能は便利だ。設定は3クリックで終わる。使い始めて1週間で効果が出た。

箇条書きの過剰な整形

同じ文字数、同じ語尾、完璧に構造化された箇条書きは「説明書感」が出る。

書式ルール

禁止

太字、絵文字、脈絡のない半角スペースは使わない。

太字は以下の全ての場所で禁止。

場所	例	見落としやすさ
通常テキスト	`重要`	低
引用ブロック内	`> 注意`	高
箇条書き内	`- 項目`	中
番号付きリスト内	`1. 手順`	中
ラベル	`手順:`	低

コロンの扱い

日本語文書でのコロンは不自然。以下の全てを禁止する。

禁止パターン	例	修正方法
見出しのコロン	`## 設定方法:`	`## 設定方法` または `## 設定方法（詳細）`
文末のコロン	`以下を確認する:`	`以下を確認する。`
ラベルのコロン	`手順:`	`■ 手順`
引用内のコロン	`> 注意:`	`> ※注意`

■ 記号付きラベルの例

code

■問題
- ほげ
- ふが

■改善
- ほげほげ
- ふがふが

インラインでの区切りには全角スペースや括弧も有効。 問題（企画書） 改善 → ほげほげ

日本語で使える記号

以下の記号を場面に応じて使い分ける。

記号	用途
■ ●	見出し、ラベル、強調項目
・	箇条書き
※	注釈、補足
→	変換、結果、参照先
【】	見出しの囲み、カテゴリ表示
○ ☆ ★	評価、重要度、チェック項目

制限

•説明文中の箇条書きは連続3項目まで（読者が飽きる）
•ただしチェックリスト、問題点の列挙、参照リストは例外（箇条書きが適切）
•emダッシュ（—）は1段落に1回まで、同じ語尾を3回以上続けない

内容の問題

テーブルの活用

数値の比較、項目の一覧、調査結果などはテーブルで整理する。同じ情報を文章で書くより読みやすくなる。

■テーブルが有効な場面

•複数項目の比較（競合比較、機能比較）
•数値データの提示（売上推移、アンケート結果）
•課題と影響の対応関係
•システム構成や組織体制の一覧

■文章が有効な場面

•原因と結果の説明
•経緯や背景の説明
•具体的なエピソード

テーブルと文章を組み合わせる。テーブルで概要を示し、文章で補足説明を加える形が読みやすい。

具体性を入れる

固有名詞、具体的な数字、実際の事例を入れる。

■問題

code

多くの企業が導入し、高い評価を得ています。

■改善

code

A社、B社、C社など42社に導入いただき、平均で作業時間が35%削減されています。

主観を避ける

指示やコンテキストにない感想・意見・体験談は入れない。企画書や報告書などのビジネス文書では客観的な事実のみを書く。

■入れてよいもの

•具体的な数字、事実、事例
•プロンプトやコンテキストで与えられた情報

■入れてはいけないもの

•「〜と感じました」「〜が印象的でした」などの感想
•「〜すべきです」「〜が望ましい」などの主観的な意見（指示がない場合）
•架空の体験談やエピソード

文書更新の原則

更新後の文書は、ゼロから書いた場合と同じ仕上がりにする。以下の要素は文書に含めない。

•変更履歴（「〜を追加」「〜から変更」）
•更新日（「2024年1月更新」）
•移行メモ（「旧バージョンでは〜」）
•差分説明（「前回との違いは〜」）

読者が見るのは最新版だけ。過去の経緯を知る必要はない。

チェックリスト

文章を書いたら確認する。

フレーズ

• 「これにより」「～することができます」「～において」を多用していないか
• 「さまざまな」「多くの」を使っていないか
• 「～と言えるでしょう」を使っていないか

構造

• 同義反復がないか
• 「重要です」で終わる文に理由があるか
• 文の長さに変化があるか
• 説明文中の箇条書きが4つ以上続いていないか

書式

• 太字を使っていないか（引用内、リスト内、番号付きリスト内も含む）
• 見出しがコロン終わりになっていないか
• 文末がコロン終わりになっていないか（以下を確認する: など）
• ラベルがコロン終わりになっていないか（**手順:** など）
• 絵文字がないか
• 謎の半角スペースがないか
• すべての改行が空行（段落分け）になっていないか

内容

• 具体的な数字や固有名詞があるか
• 指示にない感想・意見・体験談を入れていないか
• 「それ」「その」が多すぎないか
• 変更履歴、更新日、移行メモ、差分説明を含めていないか

語尾

• 同じ語尾が3回以上続いていないか
• 文書の目的に合った文体になっているか

検証手順

目視だけでは見落としが発生する。修正後は以下の検索を実行して漏れを確認する。

必須の検索パターン

修正完了後、Grepツールで以下を検索する。

検索対象	検索パターン	期待結果
太字	`\\`	0件
文末コロン	`:\s$` または `：\s$`	0件（コードブロック内は除く）
見出しコロン	`^#{1,6}.*:`	0件
引用内太字	`>\s\\*`	0件

見落としやすいパターン

以下は目視で見逃しやすい。意識して確認する。

■ 太字のバリエーション

code

**ラベル:**           ← 典型的なパターン
> **引用内の強調**    ← 引用ブロック内
1. **番号付きリスト** ← リスト内
- **箇条書き内**      ← 箇条書き内

■ コロンのバリエーション

code

## 見出し: 補足説明   ← 見出し内
以下を確認する:       ← 文末
**ラベル:**          ← 太字ラベル
フォーマット:         ← 段落末

■ 箇条書きの数え忘れ

4項目以上の箇条書きを見つけたら、例外（チェックリスト、問題点列挙、参照リスト）に該当するか確認する。該当しなければ文章化する。

ダブルチェックの実行

1回の修正で全ての問題を解決できるとは限らない。修正完了後、以下を実行する。

•上記の検索パターンを全て実行
•検出されたら修正
•再度検索して0件になるまで繰り返す

評価基準

5軸で評価する。各10点満点。合計35点以下なら改稿。

軸	観点
直接性	回りくどくないか。本題にすぐ入っているか
具体性	数字、固有名詞、事例があるか。抽象語に逃げていないか
リズム	文の長さに変化があるか。語尾が単調でないか
温度	体験や感情が感じられるか。温度が一定でないか
密度	削除しても意味が変わらない部分がないか

参照ファイル

•references/phrases.md - 禁止フレーズの完全リスト
•references/patterns.md - 避けるべき構造パターン
•references/examples.md - before/afterの具体例