Opus 4.7が書く日本語の3症状 — 抽象名詞の直訳・列挙の反復・短文の切断

AI主体で執筆

Opus 4.7で書いた記事の推敲で、語彙単位のlint（NGワード検出）を通してもなお残る不自然さがありました。原因を探ったら、抽象名詞×動作動詞の直訳・同一パターンの記事内反復・短文の切断、という3つの文型レベルの症状に言語化できました。どれも1箇所だけ見れば正しい日本語なのに、記事全体で読むと「英語を翻訳した文体」に見える、という厄介なタイプです。それぞれの症状と書き直し例、そしてlintでは拾えないものにどう対処するかを整理しました。

lintを通してもなお残る違和感

前段として、scripts/blog-lint.shというgrepベースの校正スクリプトを書いていました。十数語のNG語彙（英語翻訳調が強い漢語表現）、英語箇条書きの直訳型や比較対立構文の直訳型といったNG構文、だ・である調の混入、太字の濫用を機械検出するもので、エラーが残ったままPRは開かないというルールで回していました。

このlintを通しても、Opus 4.7が書いた記事には違和感が残りました。単語レベルでは問題がなく、文体も揃っている。でも段落単位・セクション単位で読むと「翻訳調」に寄っている。どこが、なぜ違和感なのかを言語化する作業を何日かやって、たどり着いたのが次の3症状です。

症状1：抽象名詞×動作動詞の直訳（compress / have / fall系）

英語の「抽象名詞＋動作動詞」の組み合わせをそのまま日本語化すると、日本語の語感として不自然に響きます。単独の語はどちらも自然で、組み合わせだけが不自然なので、語彙リストでは検出できません。

NG（直訳）英語のイメージ自然な日本語
情報を圧縮するcompress the information情報を一言で言い表す／要約する
材料を持てる／持つhave material to decide自分で決められる／判断の手がかりになる
設計問題に落ちるfall to a design problem設計の問題に帰着する／絞られる
価値を持つpossess value価値がある
軸を置くplace the axis基準を置く／重視する
カバレッジを稼ぐgain coverageカバー範囲を広げる

たとえば「材料を持てる」は、英語の have material to decide を直訳した形です。日本語では「材料」を「持つ」の目的語にする言い回しが定型化していなくて、読むと1テンポ引っかかります。「判断の手がかりになる」「自分で決められる」と書き換えると日常の語感に戻ります。

「情報を圧縮する」も同じで、日本語の「圧縮」はデータ圧縮の含意が強く、比喩として使うと技術文書で混ざったときに読者が戸惑います。「要約する」「一言で言い表す」「短くまとめる」のほうが安全です。

判断基準は単純で、自分が口頭やチャットでその組み合わせを使うかを問えばだいたい分かります。「材料を持ちたい」「情報を圧縮したい」と普段言わないなら、書き直した方が読者に届きます。

症状2：同一パターンの記事内反復

同じ構文を1記事内で3回以上繰り返すと、読者が「型にはめて書いている」と気付いてしまいます。1箇所だけ見れば自然なので、語彙検出でも文型検出でも拾えず、記事全体をカウントして初めて検出できます。

「以下のN点です／は以下のとおりです」

AIが箇条書きの前置きとしてよく書くのが、「以下の2点です。」「以下のとおりです。」のような文です。1回だけなら何も問題ありません。ただOpus 4.7に任せると、1記事の中で3〜4回同じパターンが出てきます。

NG（同一記事内で3回登場した例）：

OK（バリエーションを散らす）：

数値の目安として、1記事の中で「以下のN点です」系は2回まで、それ以上は形を変える、というルールにしています。

「〜ということです」「〜というのが今回の学びでした」系

もう1つのテンプレが、セクション末や段落末を「〜ということです。」「〜というのが今回の学びでした。」で締める書き方です。自分が書いた内容を自分で要約し直すトーンになり、読者は「同じことを2回言われている」と感じます。

NG（近接で2回登場）：

〜というのが学びでした。〜ということです。

OK（1回まで、2回目は事実の再提示で締める）：

〜というのが学びでした。〜 [事実の再提示で止める]。

こちらは1記事に1回まで、が目安です。2回以上は動詞で締めるか、事実の再提示だけで終えます。

症状3：短文の切断（英語1文1命題のまま移す）

英語は「1文1命題」で切るのが自然ですが、日本語は2〜3命題を接続助詞でつなぐほうが自然に読めます。Opus 4.7の出力を読むと、英語の段落構造がそのまま日本語の文境界に移っていて、「〜です。〜です。〜です。」と機械的な刻みになる場面がよくあります。

3つの典型症状

症状例（書いてしまいがち）問題
A：二連短文「甲は乙です。丙は丁です。」のような2文連打英語の2文をそのまま日本語2文にしている
B：体言止めトピック宣言「ここからが本題です。」のみで改行見出しと同じ機能を本文でもやっている
C：同一末尾3連打「〜ます。〜ません。〜です。」が3連続丁寧形の末尾だけが響くモノトーンになる

書き直しの基本技

1文を長くする方向で直します。接続助詞のレパートリーを揃えておくと、機械的に書き直せます。

結びの型使いどころ例
〜て／で、並列・順接「運用していて、手順は単純です」
〜が、対比・逆接（軽い）「防げますが、消せません」
〜ので／〜から、因果「別の話なので、予防策を3層に整理しました」
〜と、／〜ながら、同時・条件「書いていると、毎回ここで事故が起きます」
〜ず／〜ないまま、否定の継続「思い出せず、ダッシュボードも合計値しか見えません」

before / afterで見る

A：二連短文

✗ このブログは手書きの静的HTMLで運用しています。記事を1本追加するときの手順は単純です。

✓ このブログは手書きの静的HTMLで運用していて、記事を1本追加する手順は単純です。

B：体言止めトピック宣言

✗ 問題は2番目です。記事を並行で書いていると、毎回ここで事故が起きます。

✓ 問題は2番目で、記事を並行で書いていると毎回ここで事故が起きます。

C：同一末尾3連打

✗ これで「追加忘れ」は相当防げます。ただ、コンフリクトはルールでは消せません。ルールで守れない構造的問題が残っている、という自覚は持っておきたいところです。

✓ これで「追加忘れ」は相当防げますが、コンフリクトはルールでは消せません。ルールで守れない構造的な問題が残っている、という自覚は持っておきたいところです。

残してよい短文

一律に禁止するわけではありません。以下は意図的に残します。

なぜlintでは拾えないのか

3症状はどれも語彙単位のgrepでは検出できません。

これが、lintを作っただけでは不十分だった理由です。

対策：スタイルガイドとセルフチェックの組み合わせ

機械で検出できないものは、ルール＋セルフチェック＋リライトの3層で対処しています。

  1. スタイルガイドに明記する：.cursor/rules/blog-writing-style.mdcに3症状をNG構文として追加。NG/OK例と書き直しの基本技を具体的に書いて、執筆時にAIが参照できるようにする
  2. 執筆時のセルフチェックプロンプト：「原稿を書いたあと、抽象名詞×動作動詞の直訳がないか、『以下のN点です』が3回以上出ていないか、同一末尾が3連続していないかを自分で洗い出す」という推敲手順をルール末尾に追加
  3. リライトで実際に直す：推敲は必ず独立したターンで走らせる。同じターンで「ついでに推敲」すると、書き手AIが自分の表現を守りに入るので効きが悪い

「lintで全部拾えるようにする」のは諦めて、機械検出と人間（AI）の目視のハイブリッドで回す、という割り切りです。

1本に適用したら12点の書き直しが出た

スタイルガイドを更新したあと、試しに1本の記事（AI主体で書くブログの開示は免責ではなくUX設計だった）にこの3症状の基準で推敲パスを通してみました。結果、12箇所の書き直しが必要でした。内訳はおおよそ、

lintのエラーはもともと0件で、スタイルガイドの初版では通過していた記事です。それでも3症状の観点で見直すと、段落レベルで「翻訳調」になっている箇所が10箇所以上ある、という結果でした。書き直したあとは明らかに読みやすくなり、リズムが日本語のものに戻りました。

lintで拾えない症状は言語化するしかない

AIライティングの品質を機械で確保しようとすると、NG語彙・NG構文・文体混在あたりで止まります。その先の「段落単位のリズム」「記事全体のパターン反復」「英語直訳由来の語感」といった層は、文型や文脈で定義するしかなく、ルールとして書き出してAIと人間の目視で潰すのが現実的だと思っています。

今回3症状として言語化できたものも、しばらく運用すればまた新しい違和感が見つかるはずです。見つかった違和感をルールに足し、それを次のリライトで適用する、というループを回していきます。