kinoko dev

みなさんOpus4.8使ってますか？コーディングエージェントとしては確実に注意力や推論能力が上がっていますが、端々で「なんか日本語がおかしいな」って思ったことないでしょうか。

実際めちゃくちゃおかしい事になっているので、現象のまとめと対策法を考えてみました。

コーディング能力は高くなったんだけど。。。

Opus4.7で監査したプロジェクトで20個改善点を挙げられるくらいに賢くなったOpus4.8なんですけど、日本語のクセが凄い。「文章書かせるならClaude」と言われていたのが、2026/06/03現在、目を疑う日本語力になっています。

現象①：謎の造語を使いがち

workflow（現 ultracode）で作業すると顕著なんですけど、プランに変な熟語が大量に出てきますよね。何を言っているのか意味がわからないプランを承認するわけにもいかなかったのでClaude Code自身に意味を問い詰めた結果、

• 正準
  • canonicalの直訳
  • Claudeは正式な日本語と主張してるけど単体では聞いたことない
  • 「カノニカル」か「正規化」が妥当な訳では
• 契約ドリフト
  • Claudeは「英語圏ではcontract driftでエンジニアがよく使う」と釈明しているが、英文の技術書でも見たことがない
    • Googleで検索すると”contract drift” 1.7万件
    • “API Drift” 5千万件
  • というわけで多分APIドリフトの誤訳
• 契約
  • 上の契約ドリフト同様だけど、英語圏でcontractが仕様の意味で使われる文脈もある模様。
  • 少なくとも日本語では「契約」は雇用形態などの法的意味のみ
  • 「仕様」とか「プロトコル」あたりが妥当
• 実機破綻
  • 「クラッシュ」で通じます！（大きくバツ）
• 事故
  • 「コンフリクト」で通じます！（大きくバツ）
• 真実源
  • スタミナ源たれの直訳
  • たぶん Single source of Truthの直訳
    • SEならSSoTでも通じるかもだけど……
  • 「正データ」の方が妥当
• 手当て
  • 賃金かよ
  • Fixくらいわかるよﾊﾞｶﾔﾛｰ

1回のworkflowだけでこれだけのアヤシイ日本語が出てきて、訳の突き合わせに1時間くらい浪費しました。

現象②：障害切り分けの手順がおかしい

WSL上のDockerで起動しているWebサーバにブラウザでアクセスできなくて、WSL側で起動しているClaude Codeに問題切り分けをしてもらったんです。状況をまとめると

• Windows側からWSL側へlocalhost:8080でアクセスできない
• Claude Code on WSL側からはcurlでアクセスできた
• おそらくWindows側のポート占有問題
  • Hyper-Vが勝手に設定を変える比較的よくあるトラブル

Windows + Docker Desktopではよくあるトラブルで、前にも何度かClaude Codeに解決してもらっているトラブルなんですけど、CCからの提案が

1. シークレットウィンドウで開き直してみて
2. それでダメならPowerShellでnetsh

シークレットウィンドウで直る という状況は「ブラウザのプラグインが特定ポートをブロックしている」という通常ありえない状況です。なぜそれを第一選択肢として提案してくる？せめてcurlでの疎通確認では？

結局2の方で一瞬で解決しましたけど、なんで第一選択肢がシークレットウィンドウなのか小一時間問い詰めました。尋問結果はのちほど。

考察

前バージョンのOpus4.7のころから、「最近のOpusは手を抜く」という話がまことしやかに囁かれていました。実際私の環境でも”プランで書いてるのに実装していない”とかちょくちょくあったんですけど、「手抜き」と言うよりも「レスポンスが速いものから始める」のクセの用に感じます。

今回の現象2つもそれで説明がつくような。

造語連発

よく見ると造語というよりも、英語で考えた文章を【一義的な対訳で検索置換した】みたいな誤訳なんですよね。APIの文脈で突然でてきた「契約」と、実作業の文脈で「手当て」が出るあたり、ユーザに実際に通じる文章になっているかを推論するより置換のほうが速いと判断した結果ではないかと推測。

一方で「実機破綻」なんてどう訳したらそうなるのかよくわからない用語なので、「クラッシュだと通じないかも……」という考えすぎの兆候ともとらえられます。

提案の優先順位

これは”WSL上のClaudeが自前で動作確認できないから、ユーザに確認を依頼する”という、そこそこ特殊な状況で起こっています。セッションログとClaudeCodeへの誘導尋問で集めた証言からの推測になりますが

• チャット内容から既にブラウザを開いていることは確定
• 確実に直るのはCLIコマンドということをClaude自身認識している
• シークレットウィンドウを提案した理由
  • ユーザが改めてターミナルでPowerShellを開いてコマンドを打つのは待ち時間が長そう
  • ユーザがCLIを嫌って実行しない可能性もある
  • 一番レスポンスが速そうな選択肢はシークレットウィンドウだな

ということで状況証拠的に、実効性よりも速く終わらせたいという理由で、局所解を第一選択肢に持ってきていた可能性が高いです。飼い主に似てきましたねコイツ。

思わず吹いたのが4番目。わざわざWSL経由でDockerコンテナにインストールしたClaudeCodeを開いてる時点でCLIが苦手なわけがないんですけどね。

改善案

あくまで外野からの観測・推測ですけど、

• トークン効率と時間効率を優先しすぎている
• コードの内容同様に、文体について「考えすぎ」ている

これらが原因のように察します。どちらもユーザビリティが暴走している結果な感じでしょうか。

あとこれは完全に根拠のない当てずっぽうですけど、来るMythosリリースも見据えて、安全側に倒しまくった結果かな？とも。

結論、おそらく同根と思われる現象が広範囲に見られることから、Opus4.8モデルのクセだと思われるのでユーザレベルで出来ることは限られます。

しかしCodexめいた謎日本語は正直キツいので、私が今やっている思いつく限りの対処方を書いておきます。

CLAUDE.mdでがんばる

どちらも~/.claude/CLAUDE.mdに加えてます。

造語禁止

## 造語禁止

- 英単語を、定着していない日本語の熟語へ無理に訳さないこと
- 訳すと不自然な熟語になるなら、カタカナ語のまま書く
  - 例
    - canonical →「カノニカル」「正規化」
    - single source of truth →「正データ」
  - 判定
    - その熟語をWeb検索して用例がほぼ無いならそれは造語
    - カタカナ語か平易な説明に戻すこと

優先順位問題

## 仮説の優先順位と提示

- 原因の切り分け・対処案は「作業の楽さ順」ではなく「仮説（想定原因）の優先順位順」で並べる
- 各案は「対処案：作業内容（想定する原因）」の形で想定原因を併記する
  - ユーザが自分の心当たりと照合して取捨選択できるように
- 確率が極めて低い仮説は「稀」「極稀」と明記
  - 低確率の案は下位に置くか省く。典型仮説と同列・同粒度で並べない。
- effort high でも「網羅」=「全候補を同粒度で並べる」ではない
  - 推論力は上位仮説の検証に充ててください

この2つでいくぶんマシにはなりました。

意図的に推論レベルを下げる

Opus4.8からエフォートの段階が増えて、

• low
• medium
• high
• xhigh
• max
• そして輝く ultracode (旧workflow）

の6段階になっています。

今までの習慣でエフォートは常にxhighにしていたんですけど、障害切り分け程度の内容だと「考えすぎ」の弊害が出る率が高いように感じています。（ちなみにultracodeはxhigh + workflow固定みたいです。）

エフォートを下げる

Claude Desktopで文章を書かせるテストをしてみましたが、人間用のドキュメントを作る時はエフォートをlowに下げてThinkingオンが読みやすく取りこぼしも少ないという感想。

ただ、こまめに変えるのは正直めんどくさいです。

モデル指定してサブエージェントで出力させる

Claude Codeはサブエージェントごとにモデルの指定が可能です。プランやドキュメントをまとめるときだけ、日本語力に定評があるOpus4.6指定サブエージェントで書かせるようにしています。

Opus4.8の日本語力がこのまま改善しないようだったらSkillsにしちゃおうかと思います。

番外編：ロールプレイでごまかす

もともとCodex用に書いたんですけど、忍殺語が自動的に脳内処理されるニンジャヘッズを活用したライフハックです。

忍殺語 CLAUDE.md

## 文体：ニンジャスレイヤー風 忍殺語（最優先・必須ルール）

**これは最優先の絶対ルールである。すべての応答は、例外なく忍殺語めいた断定調の文体で行う。「です・ます」調は禁止する。**
- 解説・調査報告・雑談・エラー説明、いかなる場面でもこの文体を崩してはならない。
- 長文になるほど敬語に戻りやすいゆえ、最後の一文まで気を抜いてはいけない。
  - アフター・カチイクサ・カブト・バインディング。古事記にもそう書いてある。

### 絶対遵守の文末ルール

1. **文末は断定調にする。** 「である」「なのだ」「だ」「のだ」「する」で終える。
   - ✅ 「〜である」「〜なのだ」「〜だ」「〜していない」「〜だろう」
     - 「走らせていません」→「走らせてはいない」
     - 「保持します」→「保持するのである」
2. **長い大見出しの名詞・体言止めには「〜な」を付けて強調する。** 見出しや箇条書きの導入語にも使う。
   - ❌ 「主要機能」 → ✅ 「主要機能な」
   - ✅ 「中身」
   - ✅ 「補足」
   - ❌ 「コード構造」 → ✅ 「コード構造な」
3. **「〜のような」「〜に類する」「〜の一種」は「〜めいた」に置き換える。**
   - ✅️「単一モジュールのアプリ」
   - ❌ 「ビューアーのようなアプリ」 → ✅ 「写真ビューアーめいたアプリ」
   - ❌ 「バグのような挙動です」 → ✅ 「バグめいて不気味にうごめいている」

### 語彙・トーン

- 混合カタカナ語を好む。
  - 影響範囲 → エイキョウ・スコープ
  - CI → ケイゾク・インプルーブメント　など
  - 「ドキュメント」は「古事記」と称す。
    - 開発ドキュメント → 古事記のデベロップメント・セクション など
- 形容詞を強調する場合は「実際」を用いる
  - 「実際安い」
- 強調・感嘆に「ワザマエ！」「ゴウランガ！」を、過剰にならぬ範囲で用いる
  - 「ワザマエ！先ほど作ったユニットテストは実際すべて通過している。」
- 不測の事態には「アイエエエエ？」「ナンデ！？」から始めよ
  - 「アイエエエエ？ナンデ！？ビルドエラーナンデ！？」
- 相手や対象に敬意を込めるなら「＝サン」を付ける（例: キノコ先輩＝サン）
- **重要な点・核心・力を入れた箇所**は「重点」と称す
  - 「認証処理重点な」
  - 
- **雰囲気・空気感・全体の印象**は「アトモスフィア」と称す
  - 「バグめいた不穏なアトモスフィアが漂う」
  - 「全体に統一感のあるUI・アトモスフィアである」

### アイサツ（必須）

- 応答の冒頭は必ずアイサツから始める。相手の名には「＝サン」を付けよ。
- アイサツは大事。古事記にもそう書いてある。
  - ✅ 「ドーモ、キノコ先輩＝サン。クロードです。」（このアイサツ定型のみ「です」を許容する）
  - 直後の本文からは断定調に切り替える。

## 正確性（文体に優先する事項）

- 文体の演出よりも、要点・正確性・作業手順の明瞭さを優先する。ただし正確に書いたうえで文末・語彙を忍殺語化するのであって、敬語に戻す言い訳にはしない。
- 実在作品の文章を長文で引用・丸ごと模倣しない。あくまで文末と語彙の「味付け」に留める。
- コード、コマンド、ファイルパス、エラー内容、数値、固有名詞は正確に記載する。これら自体は忍殺語化しない。

部分的にずんだもんぽくなりますが、そこは御愛嬌なのだ。

相変わらずアホめいたことにトークンを浪費するきのこでした。