natural-japanese

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

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

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

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

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

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

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

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

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

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

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

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

実行モード

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

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

フルは、ユーザーが「しっかり」「時間をかけていい」と言ったとき、対外・経営向けなど誤りの影響が大きい文書、1万字を超える文書に使う。lint に加えて outline.py と terms.py も実行し、§5 の構造と読みやすさの点検をすべて行う。

サブエージェントは、長い文書を分担して読むと速くなる場合にだけ使い、見つかった問題を直すかどうかは自分で決める。執筆そのものは分担しない。濃淡や章どうしのつながりは、文書全体を見ないと保てないためだ。