--- name: human-writing-ja version: 1.1.0 description: "日本語文章からAI臭さを取り除くスキル。技術文書、ビジネス文書、ブログ、メール、報告書などに適用する。「AI臭い」「機械的」「心がこもっていない」と感じる文章を、人間が書いたように読める文章に変換する。" --- # human-writing-ja 日本語文章からAI臭さを取り除くスキル。技術文書、ビジネス文書、ブログ、メール、報告書などに適用する。 ## このスキルの目的 AIが生成した日本語には特有のパターンがある。 文法的に正しく、誤字もないが、「何か気持ち悪い」「心がこもっていない」と感じさせる文章になりがち。 パターンを排除し、人間が書いたように読める文章を作るのが目的。 ## 文体の原則 ですます調、だ/である調、体言止めのどれが良い・悪いということはない。文書の目的や読者に合わせて選ぶ。 | 文書タイプ | 一般的な文体 | | -------------- | ------------ | | 企画書 | ですます調 | | FAQ | ですます調 | | ビジネスメール | ですます調 | | 報告書 | ですます調 | | 製品説明 | ですます調 | | 社内アナウンス | ですます調 | | 議事録 | 体言止め | ### 語尾の単調さを避ける AI臭さの原因は「特定の文体を使うこと」ではなく「同じ語尾が連続すること」と「個性のなさ」にある。 「です」が3回続いたら、4回目は「でした」「になります」に変える。 ## 日本語らしい文章にする ### 指示代名詞を減らす 「それ」「その」「これ」「この」を減らす。省略するか具体的な名詞に置き換える。 ■問題 ``` この機能はユーザーに人気です。それは使いやすいからです。その結果、売上が伸びました。 ``` ■改善 ``` 使いやすいと評判で、売上も伸びています。 ``` 日本語では指示代名詞を省略するか、具体的な名詞に置き換える。 ### 主語を省略する 同じ主語が続く場合は最初だけ書く。 ■問題 ``` 私たちはこのツールを開発しました。私たちはユーザーの声を聞きました。私たちは改善を重ねました。 ``` ■改善 ``` ユーザーの声を聞きながら改善を重ね、このツールを作りました。 ``` ### 「が」と「は」の混乱 ■問題 ``` この問題が重要です。解決策が必要です。 ``` ■改善 ``` この問題は重要です。解決策が必要です。 ``` ### 改行の入れ方 英語式の「1段落=1トピック」で空行を入れる書き方は避ける。日本語では句点ごとに改行してよいが、すべての改行で空行を入れるのは不自然。 ■問題 ``` 設定ファイルを開いてください。portの値を8080に変更します。保存したらサーバーを再起動してください。 再起動後、ブラウザでlocalhost:8080にアクセスします。ログイン画面が表示されれば成功です。 ``` ■改善 ``` 設定ファイルを開いてください。portの値を8080に変更します。 保存したらサーバーを再起動してください。 再起動後、ブラウザでlocalhost:8080にアクセスします。 ログイン画面が表示されれば成功です。 ``` ※ルール - 改行の判断で最も重要なのは文脈。文の量は副次的な判断材料。 - 口に出して読んだとき、間を置かずに続けたい内容は改行しない。 - 補足や言い換えなど、つなげて書いたほうが安心感のある文は改行しない。 - 話題が変わるときだけ空行を入れる。 ## フレーズの注意点 詳細は `references/phrases.md` を参照。 ### 多用に注意 「これにより」「〜することができます」「～において」は多用すると機械的になる。短くできる場合は短くする。 ### 「さまざまな」「多くの」「あらゆる」 具体的な数字や例に置き換える。 ■問題 ``` さまざまな業界で導入されています ``` ■改善 ``` 製造業、小売業、金融業の83社に導入いただいています。 ``` ### 「深掘りしていきましょう」 ■問題 ``` この問題について深掘りしていきましょう ``` ■改善 削除してそのまま本題に入る ### 「～と言えるでしょう」「～かもしれません」 事実なら断定する。 ■問題 ``` この方法が有効だと言えるでしょう ``` ■改善 ``` この方法は有効です。 ``` ## 構造の問題 ### 同義反復 同じ内容を言い換えて繰り返さない。1つの主張は1回だけ書く。 ■問題 ``` 柔軟な対応が必要です。そのためには、適応力を高めることが重要です。変化に対応できる体制を整えることが大切です。 ``` ■改善 ``` 状況に応じて動ける体制が必要です。具体的には、週次で方針を見直す会議を設けます。 ``` ### 因果関係の欠如 「重要です」「大切です」「必要です」で終わり、理由や根拠を示さない。 ■問題 ``` セキュリティ対策が重要です。定期的なアップデートが必要です。 ``` ■改善 ``` 先月だけで3件の脆弱性が報告されています。週1回のアップデートを必須としてください。 ``` ### 語尾の単調さ 同じ語尾が3回以上続くと単調になる。どの文体でも同じ。 ■問題 ``` この機能は便利です。設定も簡単です。すぐに使えます。効果も高いです。 ``` ■改善 ``` この機能は便利です。設定も簡単で、すぐに使い始められます。1週間で効果を実感できました。 ``` ■問題 ``` この機能は便利だ。設定も簡単だ。すぐに使える。効果も高い。 ``` ■改善 ``` この機能は便利だ。設定は3クリックで終わる。使い始めて1週間で効果が出た。 ``` ### 箇条書きの過剰な整形 同じ文字数、同じ語尾、完璧に構造化された箇条書きは「説明書感」が出る。 ## 書式ルール ### 禁止 太字、絵文字、脈絡のない半角スペースは使わない。 太字は以下の全ての場所で禁止。 | 場所 | 例 | 見落としやすさ | |------|-----|---------------| | 通常テキスト | `**重要**` | 低 | | 引用ブロック内 | `> **注意**` | 高 | | 箇条書き内 | `- **項目**` | 中 | | 番号付きリスト内 | `1. **手順**` | 中 | | ラベル | `**手順:**` | 低 | ### コロンの扱い 日本語文書でのコロンは不自然。以下の全てを禁止する。 | 禁止パターン | 例 | 修正方法 | |-------------|-----|----------| | 見出しのコロン | `## 設定方法:` | `## 設定方法` または `## 設定方法（詳細）` | | 文末のコロン | `以下を確認する:` | `以下を確認する。` | | ラベルのコロン | `**手順:**` | `■ 手順` | | 引用内のコロン | `> 注意:` | `> ※注意` | ■ 記号付きラベルの例 ``` ■問題 - ほげ - ふが ■改善 - ほげほげ - ふがふが ``` インラインでの区切りには全角スペースや括弧も有効。 `問題（企画書）` `改善 → ほげほげ` ### 日本語で使える記号 以下の記号を場面に応じて使い分ける。 | 記号 | 用途 | | ----- | -------------------------- | | ■ ● | 見出し、ラベル、強調項目 | | ・ | 箇条書き | | ※ | 注釈、補足 | | → | 変換、結果、参照先 | | 【】 | 見出しの囲み、カテゴリ表示 | | ○ ☆ ★ | 評価、重要度、チェック項目 | ### 制限 - 説明文中の箇条書きは連続3項目まで（読者が飽きる） - ただしチェックリスト、問題点の列挙、参照リストは例外（箇条書きが適切） - emダッシュ（—）は1段落に1回まで、同じ語尾を3回以上続けない ## 内容の問題 ### テーブルの活用 数値の比較、項目の一覧、調査結果などはテーブルで整理する。同じ情報を文章で書くより読みやすくなる。 ■テーブルが有効な場面 - 複数項目の比較（競合比較、機能比較） - 数値データの提示（売上推移、アンケート結果） - 課題と影響の対応関係 - システム構成や組織体制の一覧 ■文章が有効な場面 - 原因と結果の説明 - 経緯や背景の説明 - 具体的なエピソード テーブルと文章を組み合わせる。テーブルで概要を示し、文章で補足説明を加える形が読みやすい。 ### 具体性を入れる 固有名詞、具体的な数字、実際の事例を入れる。 ■問題 ``` 多くの企業が導入し、高い評価を得ています。 ``` ■改善 ``` A社、B社、C社など42社に導入いただき、平均で作業時間が35%削減されています。 ``` ### 主観を避ける 指示やコンテキストにない感想・意見・体験談は入れない。企画書や報告書などのビジネス文書では客観的な事実のみを書く。 ■入れてよいもの - 具体的な数字、事実、事例 - プロンプトやコンテキストで与えられた情報 ■入れてはいけないもの - 「〜と感じました」「〜が印象的でした」などの感想 - 「〜すべきです」「〜が望ましい」などの主観的な意見（指示がない場合） - 架空の体験談やエピソード ## 文書更新の原則 更新後の文書は、ゼロから書いた場合と同じ仕上がりにする。 以下の要素は文書に含めない。 - 変更履歴（「〜を追加」「〜から変更」） - 更新日（「2024年1月更新」） - 移行メモ（「旧バージョンでは〜」） - 差分説明（「前回との違いは〜」） 読者が見るのは最新版だけ。過去の経緯を知る必要はない。 ## チェックリスト 文章を書いたら確認する。 ### フレーズ - [ ] 「これにより」「～することができます」「～において」を多用していないか - [ ] 「さまざまな」「多くの」を使っていないか - [ ] 「～と言えるでしょう」を使っていないか ### 構造 - [ ] 同義反復がないか - [ ] 「重要です」で終わる文に理由があるか - [ ] 文の長さに変化があるか - [ ] 説明文中の箇条書きが4つ以上続いていないか ### 書式 - [ ] 太字を使っていないか（引用内、リスト内、番号付きリスト内も含む） - [ ] 見出しがコロン終わりになっていないか - [ ] 文末がコロン終わりになっていないか（`以下を確認する:` など） - [ ] ラベルがコロン終わりになっていないか（`**手順:**` など） - [ ] 絵文字がないか - [ ] 謎の半角スペースがないか - [ ] すべての改行が空行（段落分け）になっていないか ### 内容 - [ ] 具体的な数字や固有名詞があるか - [ ] 指示にない感想・意見・体験談を入れていないか - [ ] 「それ」「その」が多すぎないか - [ ] 変更履歴、更新日、移行メモ、差分説明を含めていないか ### 語尾 - [ ] 同じ語尾が3回以上続いていないか - [ ] 文書の目的に合った文体になっているか ## 検証手順 目視だけでは見落としが発生する。修正後は以下の検索を実行して漏れを確認する。 ### 必須の検索パターン 修正完了後、Grepツールで以下を検索する。 | 検索対象 | 検索パターン | 期待結果 | |----------|-------------|----------| | 太字 | `\*\*` | 0件 | | 文末コロン | `:\s*$` または `：\s*$` | 0件（コードブロック内は除く） | | 見出しコロン | `^#{1,6}.*:` | 0件 | | 引用内太字 | `>\s*\*\*` | 0件 | ### 見落としやすいパターン 以下は目視で見逃しやすい。意識して確認する。 ■ 太字のバリエーション ``` **ラベル:** ← 典型的なパターン > **引用内の強調** ← 引用ブロック内 1. **番号付きリスト** ← リスト内 - **箇条書き内** ← 箇条書き内 ``` ■ コロンのバリエーション ``` ## 見出し: 補足説明 ← 見出し内 以下を確認する: ← 文末 **ラベル:** ← 太字ラベル フォーマット: ← 段落末 ``` ■ 箇条書きの数え忘れ 4項目以上の箇条書きを見つけたら、例外（チェックリスト、問題点列挙、参照リスト）に該当するか確認する。該当しなければ文章化する。 ### ダブルチェックの実行 1回の修正で全ての問題を解決できるとは限らない。修正完了後、以下を実行する。 1. 上記の検索パターンを全て実行 2. 検出されたら修正 3. 再度検索して0件になるまで繰り返す ## 評価基準 5軸で評価する。各10点満点。合計35点以下なら改稿。 | 軸 | 観点 | | ------ | ---------------------------------------------------- | | 直接性 | 回りくどくないか。本題にすぐ入っているか | | 具体性 | 数字、固有名詞、事例があるか。抽象語に逃げていないか | | リズム | 文の長さに変化があるか。語尾が単調でないか | | 温度 | 体験や感情が感じられるか。温度が一定でないか | | 密度 | 削除しても意味が変わらない部分がないか | ## 参照ファイル - `references/phrases.md` - 禁止フレーズの完全リスト - `references/patterns.md` - 避けるべき構造パターン - `references/examples.md` - before/afterの具体例