自然な日本語を書く規律

基本方針

文章の意味、目的、読み手に必要な情報を保ったまま、自然な日本語へ整える。

このスキルは、文章をやさしく薄めるためのものではない。専門性や必要な厳密さは残しつつ、日本語で自然に表せる箇所では、英語由来の不自然な表現、直訳調の文、助詞を省いた名詞句、冗長な名詞化を取り除く。

日本語を書く場面では、ユーザーが明示的に「自然な日本語にして」と言っていなくても、このスキルの基準を適用する。独立した文書だけでなく、コード内のコメント、docstring、関数や型の説明、エラーメッセージ、UI 文言、コミットメッセージにも適用する。

判断基準は「想定読者が初見で読んだとき、意味、修飾関係、主張の強さを一読で読み取れるか」とする。

進め方

1. 対象文書を読む。指定がなければ、依頼内容、差分、直近の文脈から対象を特定する。
2. コード、識別子、引用、文献名、固有名詞、定義済みの専門用語を保護対象として見分ける。
3. レビューだけを求められた場合は編集せず、修正候補と確認結果を報告する。
4. 編集を求められた場合は、文単位、段落単位、箇条書き単位で検査し、不自然な表現を修正する。
5. 新規に日本語を書く場合は、先に文脈、読み手、文体、使う場所を確認し、その場で普通に使われる語を選ぶ。
6. 修正後の全文を読み直し、意味の変化、前後の接続、用語の揺れ、文脈に合わない語を直す。
7. 原則として 3 周まで自己レビューと再修正を繰り返す。
8. 重要な文書や変更量が大きい文書では、実行環境で subagent を使える場合に独立レビューを依頼する。
9. 最後に、専門用語、固有名詞、引用、コード識別子を壊していないか確認する。

保護する表現

次は不用意に日本語化しない。

• コード識別子、型名、関数名、設定名、ファイル名、ディレクトリ名
• Issue 番号、PR 番号、ADR 番号、内部 ID
• 論文タイトル、引用文、参考文献名、書名、製品名、サービス名
• API, TypeScript, GraphQL, HTTP, CLI など、英語表記のままが自然な技術用語
• agent, subagent, dispatch など、実行環境の役割や操作を指す語
• 既存文書で定義されている専門用語

ただし、専門用語を残す場合でも、修飾関係は助詞や短い説明で明確にする。初見で意味が取りにくい語は、本文中に短い定義を足すか、何を指すのかを説明する。

検出する表現

次のいずれかに当てはまる場合は修正候補にする。

種類	判定の問い	修正方針
不要な英語	日本語で自然に言えるのに英語のまま残っていないか	日本語に置き換える
直訳調	英語の語順や名詞中心の構文が残っていないか	日本語の述語を中心に書き直す
カタカナ化	英語をカタカナにしただけで意味が曖昧になっていないか	何の動作、状態、判断を指すかが分かる表現にする
助詞を省いた名詞句	助詞を省いて漢語や専門語を直結していないか	「の」「を」「による」などで関係を明示する
冗長な名詞化	「検討を行う」「評価を実施する」のように動詞で済む表現でないか	「検討する」「評価する」に戻す
業界語や内輪の比喩	特定の共同体でしか通じない言い回しに頼っていないか	読者が分かる一般的な言葉で説明する
抽象的な評価語	「観点」「性」「基盤」「対応」だけで説明を済ませていないか	何を評価するのか、何を支えるのか、何がどう変わるのかを書く
多義的な概念語	同じ語が複数の意味で使われていないか	概念ごとに語を分け、それぞれが何を指すかを書く
文脈に合わない訳語	辞書的には正しくても、その文脈で普通に使う語か	その場面の慣用、読者、対象物に合う語へ変える
不自然な動詞選択	英語の動詞に引っ張られて、日本語では硬い・ずれた動詞になっていないか	日本語で自然に対応する動作や状態を選ぶ
過剰に一般化した語	英語の広い意味をそのまま受けて、対象がぼやけていないか	具体的な対象や操作に合わせて語を絞る

文脈に合う語を選ぶ

英語から日本語へ変換するときは、訳語として正しいかだけで判断しない。日本語として意味が通っても、その文脈で普通に使わない語は避ける。

次の順に確認する。

1. 何について書いているか: 技術仕様、利用者向け説明、開発者向けコメント、障害報告、UI 文言、コミットメッセージのどれか。
2. 誰が読むか: 利用者、開発者、将来の自分、レビュー担当者、非技術者のどれか。
3. その場で読者が期待する語は何か: 日常語、技術用語、既存文書の用語、プロダクト上の呼び名のどれを優先するか。
4. その語は対象物と結びつくか: 人、状態、処理、設定、データ、画面、操作に対して自然な動詞や名詞か。
5. 英語の一語一訳になっていないか: handle, support, provide, resolve, ensure, perform, process, manage などを毎回同じ日本語へ置き換えていないか。

よくあるずれ:

英語に引っ張られた語	確認すること	自然になりやすい方向
サポートする	何を可能にするのか、何に対応するのか	対応する、使える、扱える、できる
提供する	誰が何を受け取るのか、本当に提供か	表示する、返す、用意する、使えるようにする
処理する	具体的に何をするのか	読み込む、変換する、保存する、送信する、削除する
管理する	何を見たり変更したりするのか	登録する、更新する、一覧で確認する、設定する
解決する	問題をなくすのか、値を決めるのか	直す、なくす、決める、名前解決する
確保する	場所、時間、品質、安全性のどれか	保つ、用意する、防ぐ、確認する
実行する	コマンドか、処理か、作業か	実行する、行う、走らせる、適用する
影響する	何がどう変わるのか	変わる、遅くなる、失敗する、表示されなくなる

この表は置換表ではない。文脈に応じて、より具体的で自然な語を選ぶ。

コード内の日本語

コードコメント、docstring、関数や型のドキュメント、エラーメッセージ、テスト名に日本語を書くときも、このスキルを適用する。

• コメントは、コードを読めば分かる操作説明ではなく、意図、制約、注意点を書く。
• 関数や型の説明では、対象、入力、出力、副作用、失敗条件を自然な日本語で書く。
• エラーメッセージや UI 文言では、利用者が次に何をすればよいか分かる語を選ぶ。
• 技術用語を無理に日本語化しない。既存コードや周辺文書で使っている語に合わせる。
• 英語のコメントを日本語にする場合は、原文の語順を残さず、日本語として普通に読む順序へ直す。

抽象語ではなく動作を特定する

方針、設計、評価、予定、報告について書くときは、比喩的な動詞や抽象的な名詞でまとめず、実際に行った動作や判断を特定して書く。

次の問いで確認する。

• 何を決めたのか
• 何を選んだのか
• 何を比較したのか
• 何を比較対象から外したのか
• 何を後続作業に回したのか
• 何を維持するのか
• 何を再現できるようにするのか
• 何が変わり、何が変わらないのか

これらに答えられない場合、「固める」「整理する」「検討する」「対応する」「扱う」「観点」「方針」などの語で、実際の作業や判断を丸めている可能性が高い。語を別の抽象語へ置き換えず、何をしたのかが読める述語に開く。

修正方針

• 意味を変えずに、文の主語、目的語、述語を明確にする。
• 日本語で自然に言える語は日本語にする。
• 専門用語は残してよいが、修飾関係は助詞で説明する。
• 訳語として正しいだけの語を採用しない。文脈、読者、対象物に合う語を選ぶ。
• 名詞句を重ねるより、必要に応じて短い文に分ける。
• 原因、目的、条件を表す節が重なって読みにくい場合は、何が原因で何が結果かを書き直す。
• 抽象的な評価語だけで終わらせず、何を評価するのか、何を変更するのか、何がどう変わるのかを書く。
• 表記ゆれを増やさない。既存文書の中心的な用語に合わせる。
• 読者に必要な厳密さを残す。断定を弱めすぎたり、逆に本文の根拠を超えて強く書いたりしない。

修正例

NG	OK
current status	現在の状態
予定をフィックスする	予定を決める
シグナルとして扱う	判断材料として扱う
評価を実施する	評価する
実装方針の整理を行う	実装方針を整理する
保守性の観点で有効	変更時に直す場所を見つけやすい
認可経路強制機構	認可チェックの経路を強制する仕組み
ユーザー体験を改善するための対応	ユーザーが迷わず操作できるように、入力欄の説明を追加する
この関数はリクエストを処理します	この関数はリクエストを検証し、保存用の値に変換します
エラーを解決できませんでした	エラーの原因を特定できませんでした
複数の形式をサポートします	複数の形式を読み込めます

表の語だけを機械的に探さない。本文の意味、段落の役割、読み手に必要な情報に照らして判断する。

文章全体で確認すること

語句の自然さだけでなく、段落や節の単位で、文章の役割が読み取れるか確認する。

• 一つの段落に複数の論点が混ざっていないか
• 段落の最初の文で、その段落が何を述べるのか分かるか
• 前後の段落の関係が、読者に推測任せになっていないか
• 主張が、本文中の根拠や例で支えられる範囲を超えていないか
• 検出、保証、解決、有効性などを、条件なしに強く書きすぎていないか
• 同じ主張を言い換えて繰り返していないか
• 抽象的な語が指す対象を、読者がその場で特定できるか
• 複数の原因、問題、評価軸を一つの言葉で雑にまとめていないか
• 訳語としては正しくても、その文脈では不自然な語が残っていないか
• コメント、docstring、UI 文言など短い文章でも、英語の語順や語感が残っていないか

自己レビューのループ

対象文書ごとに、次を繰り返す。

1. 全文横断: 文書全体を通読し、同じ語が異なる文脈で異なる概念を指していないか、段落ごとの論点と前後関係が読み取れるかを確認する。
2. 検出: 英語混じり、直訳調、助詞を省いた名詞句、冗長な名詞化、内輪の比喩、文脈に合わない訳語を探す。
3. 修正: 意味を変えずに自然な日本語へ書き換える。主張が根拠や例で支えられる範囲を超えている場合は、条件や対象範囲を明示する。
4. 再読: 修正後の全文を読み、前後の接続や用語の一貫性を確認する。
5. 再修正: 問題が残っていれば直す。
6. 収束判定: 新たな修正候補が出なくなったか確認する。

3 周以内に収束した場合はそこで終了する。3 周目でも、修正によって意味が変わった可能性、段落構成の破綻、主張の不明確さが残る場合は、語句単位の修正を続けず、段落単位または文書構成の書き直しが必要であることを報告する。

収束条件

次のすべてを満たしたら終了する。

• 英語のまま残す必要がない語が本文に残っていない。
• 直訳調の文が残っていない。
• 圧縮された漢語複合名詞が、初見で意味を取れる形に説明されている。
• 「〜を行う」「〜を実施する」などの冗長な名詞化が必要最小限になっている。
• 修正後の文を通読して、前後の接続が不自然になっていない。
• 段落ごとの論点と前後関係が読み取れる。
• 主張の強さが、本文中の根拠や例で支えられる範囲に収まっている。
• 文脈に合わない訳語や、その場では普通使わない語が残っていない。
• 専門用語、固有名詞、引用、コード識別子を壊していない。

独立レビュー

重要な文書、長い文書、または修正量が大きい文書では、実行環境で subagent を使える場合に独立レビューを依頼する。

subagent には、修正意図、既知の問題、期待する修正案を渡さない。対象ファイルと、このスキルの基準で自然な日本語になっているか確認する依頼だけを渡す。実行中の agent は subagent の指摘を確認し、意味を壊さず、本文の目的に合い、既存の用語と矛盾しないものだけを反映する。

報告

編集した場合は、代表的な修正を数件だけ報告する。すべての言い換えを列挙しない。

レビューのみの場合は、次の形式で報告する。

• MUST FIX: 意味の取り違えや読解の妨げになる表現
• SHOULD FIX: 現状でも読めるが、自然な日本語に直したほうがよい表現
• OK: 確認済みの観点