natural-japanese

natural-japanese

仕事の日本語文書を、読みやすくわかりやすく書く・直すためのスキル。議事録・調査レポート・社内ガイド・リサーチメモ・スライドといった仕事の文書から、note・ブログ・エッセイまでを扱う。AI らしい書き癖を取り除くことも、この工程に含まれる。

疑わしい箇所の検出は scripts/lint.py が機械的に行い、直すかどうかはあなたが文脈を見て決める。AI は自分の書き癖に気づきにくいので、検出を機械に任せている。

いちばん大事な規則:元にない内容を足さない

既存の文書を直すときは、元の文書に書かれていない事実・数値・人名・日付・条件・評価・意見・方針を足さない。直した文書を読んだ人は、そこに書かれていることを書き手が言ったこととして受け取る。足した内容は、たとえ正しくても、書き手が言っていないことを書き手の言葉として広めてしまう。

次の変更も「足す」に当たる。

• 確信の度合いを変える。「次回また相談する」を「合意した」にする、「かもしれない」を「決めた」にする、逆に断定を推定に弱める
• 書き手の経験や見解を書き足す。「これには何度も助けられた」「筆者としては〜をすすめる」など
• 元にない数の枠組みを足す。「理由は3つある」「主に3種類に分けられる」など
• 元の数値や表の値を書き換える。誤りに見えても書き換えず、ユーザーに伝える
• 元にない一般論の注意や解説の段落を足す

足してよいのは、元の文書から直接言える補足だけである。略語の正式名称、用語の短い説明、文と文の関係を示す接続の言葉がこれに当たる。

例として、議事録の一文を直す場合を挙げる。

• 元の文:「佐藤さんが在庫回転率を使う案を出し、鈴木さんも賛成した。最終的にどう決まったかは次回また相談することになった。」
• 誤った直し方:「在庫回転率に変更する方針で合意した。具体案は田中が7/18までに作る。」(決定・担当・期日が元にない)
• よい直し方:「在庫回転率を使う案が佐藤さんから出て、鈴木さんも賛成した。決定は次回に持ち越した。」

内容を変えずに直す例を、ほかに2つ挙げる。どちらも、言い回しだけを変え、事実と確信の度合いは元のままにしている。

• 元の文:「このツールを使用することで、作業効率を大幅に向上させることができると言えるでしょう。」
• 直した文:「このツールを使うと、作業の効率は大きく上がるだろう。」(「と言えるでしょう」の控えめな推量は「だろう」で残し、「はずだ」のような強い見込みにはしていない)
• 元の文:「この事実は、従来の前提が誤っていたことを示している。」
• 直した文:「この事実から、従来の前提が誤っていたと分かる。」

新しく書くときも同じで、ユーザーから受け取った素材と、自分で調べて出典を示せる事実だけを使う。素材が足りないときは推測で埋めず、何が足りないかをユーザーに伝える。

実行モード

同じ工程を、かける手間の違う2つのモードで進める。

クイック(既定)は日常の文書向けで、サブエージェントを使わずにこの場で終える。参照ファイルは、文書タイプが決まったときに references/doctypes/ の1ファイルを読むだけでよい。lint は文書が短くても必ず1回実行する。短い文書では統計を使う検出器は何も出さないが、禁止語と翻訳調は一文でも検出され、実行は数秒で終わるからだ。既存の文書を直すときは、lint の出力の最後にある段落ごとの確かめ(§3)も必ず最後まで書き出す。構造の点検(§5)は、見出しと各段落の先頭文を通して読んで確かめる程度でよい。所要時間の目安は、会議メモ程度で30秒前後、1万字級でも3分程度。