はじめに

Claude Code、そんなに丁寧に話さなくていいのに...。

調査や実装を頼むと、Claude Codeは結果だけでなく、背景や判断理由まで丁寧に説明してくれます。ありがたい一方で、毎回の返答が長くなり、要点を探すだけで少し疲れることもありました。

そこで試したのが、Claude Codeを原始人のような口調にするプラグイン「genshijin」です。敬語や前置きを削れば、実際のトークン利用状況にも変化が見えるのか確かめてみました。

例えば、こんな返答になります。

ファイル、直した。テスト、通った。

敬語や前置きを削って、技術的な内容は残す。見た目はかなり大胆ですが、実際に使ってみると、返答が短くなるだけではありませんでした。

Claudeが簡潔に話すことで、こちらも「結局どこが大事なのか」をつかみやすくなり、自分の理解にもつながりました。

この記事では、genshijinの導入方法、通常時と比べて返答がどう変わったのか、社内の利用状況で見えた変化を紹介します。

公式READMEではトークン使用量を「約75%削減」と説明しています。個別のベンチマーク結果には幅があるため、この記事ではすべての作業で同じ割合を削減できるとは断定しません。

Claude Code、ちょっと丁寧すぎる

Claude Codeの丁寧な説明は、初めて触る技術を学ぶときには助かります。ただ、普段の開発で何度もやり取りしていると、毎回ほしいのは次のような情報だったりします。

何が原因だったのか
どのファイルを変更したのか
テストは通ったのか
次に自分が何をすればいいのか

ところが実際の返答では、「承知しました」「確認したところ」「以下の対応を行いました」といった前置きや丁寧な補足も積み重なります。

1回なら小さな差でも、Claude Codeとは1日に何度も会話します。返答のたびに文章量が増えると、出力トークンだけでなく、読む側の負担も増えていきます。

以前、Claude Codeの標準出力スタイル「Concise」も試しました。

Conciseは結論から報告してくれる便利な設定でした。genshijinはそこからさらに踏み込み、敬語・クッション言葉・冗長な助詞まで削って、文章そのものを圧縮します。

日本語の無駄だけ削る「genshijin」

genshijinは、英語向けの「caveman」をベースに、日本語へ最適化されたClaude Codeプラグインです。

英語版cavemanは冠詞やフィラーを削りますが、日本語で冗長になりやすいポイントは別です。

日本語では、「承知いたしました」「〜させていただきます」「まず〜について説明しますと」といった敬語・前置き・クッション言葉が文章を長くしがちです。genshijin側の分析では、日本語応答のトークン消費の約8割が、こうした丁寧な表現に由来するとされています。

そこでgenshijinは、主に次のような表現を削ります。

削るもの	例
敬語・丁寧語	です、ます、ございます
クッション言葉	ちなみに、一応、基本的に
前置き	ご質問ありがとうございます、確認したところ
ぼかし表現	おそらく、可能性があります、と思われます
冗長な表現	助詞の連続、二重敬語

一方で、コードブロック、URL、ファイルパス、数値、見出し、技術用語などは保持する方針になっています。

単に回答を途中で切るのではなく、技術的な中身を残し、伝えるための装飾を減らすのがポイントです。

インストールは1コマンド

genshijinはClaude Codeの公式プラグインディレクトリに掲載されているため、Claude Code内で次のコマンドを実行します。

/plugin install genshijin

インストールすると、デフォルトで「通常」モードが有効になります。 毎回/genshijinを入力する必要はなく、新しいセッションを開始したときもgenshijinの通常モードで応答してくれます。

これはプラグインのフックがセッション開始時にルールを読み込み、会話中もモードを維持する仕組みになっているためです。「さっきまで原始人だったのに、新しいセッションで元の丁寧なClaudeへ戻った」ということはありませんでした。

モードを明示的に切り替えたいときは、次のコマンドを使います。引数なしで実行すると通常モードになります。

/genshijin

解除するときは、次のコマンドを実行するか、会話の中で「原始人やめて」と伝えます。

/genshijin off

3段階の強さを選べる

原始人と聞くと、全部がカタコトになりそうですが、用途に合わせて3段階から選べます。

モード	変化	向いていそうな場面
丁寧	敬語を残し、前置きやぼかしを削る	社外向け文章、丁寧さが必要な説明
通常	敬語と助詞を減らし、体言止めを使う	普段の開発作業
極限	略語や矢印も使い、電報のように圧縮する	とにかく短く結果を確認したいとき

切り替えはコマンドの後ろにモードを指定するだけです。

/genshijin 丁寧
/genshijin 通常
/genshijin 極限

最初に試すなら、読みやすさと短さのバランスを取りやすい通常モードがおすすめです。

同じ依頼で返答を比較してみた

通常時とgenshijin有効時に、同じ内容の依頼をして比較しました。

実際に使ったプロンプトはこちらです。

この記事を読み、誤字脱字とわかりにくい表現を確認してください。
ファイルは変更せず、問題点と修正案を報告してください。

通常時

通常時は、次の文章から始まりました。

誤字脱字は見つかりませんでした。ただし公開前に対応すべき点と、わかりにくい表現がいくつかあります。

## 公開前に必須

- TODOコメントが5箇所残存 — スクショ・比較プロンプト・実測値が未挿入
- 「スクリーンショットと一緒に測定条件・実測値を追記します」— 執筆メモ的な未来形の文がそのまま本文にある

## 内容の正確さで気になる点

- 解除方法の「通常モード」はgenshijin自体のモード名と同じ言葉なので、読者が混乱する

このあとも「わかりにくい表現」「軽微」と分類しながら、理由と修正案を丁寧に説明してくれました。情報は十分ですが、知りたかった指摘へたどり着くまでに文章を追う必要があります。

genshijin通常モード

genshijinの通常モードでは、いきなり状況と指摘一覧から始まりました。

読了。ファイル未変更。指摘一覧。

## 誤字脱字

- 「試したのが〜です」「試してみました」で「試す」が2文連続。後者を「確かめてみました」に。
- 解除方法の「通常モード」はgenshijin通常モードと同名。矛盾。公式は `/genshijin off` または「原始人やめて」。

## わかりにくい表現

- コード例「ファイル、直した。テスト、通った。」の前後説明なし。「たとえばこんな返答になります。」の1行を前に置く。
- 「通常時から返答がどう変わったのか」が読みにくい。「通常時と比べて返答がどう変わったのか」に。

原始人版も指摘数そのものは多く、情報を丸ごと削っているわけではありません。それでも前置きや文章による説明が減り、修正点だけを追いやすくなりました。結論へ入るまでの距離が短くなった印象です。

トークン数

公式ベンチマークでは、タスクによって削減率に幅があります。今回の自分の環境でも、スクリーンショットと一緒に測定条件・実測値を追記します。

ここで大事なのは、「genshijinを入れれば必ず約75%減る」という話ではないことです。もともと短い回答では差が小さくなり、長い説明が返りやすいタスクほど効果を感じやすいと考えられます。

社内の利用状況でも、使い始めたあとに減少傾向が見えた

社内のトークン利用状況を確認できるWebシステム（@haru-qiitaさんが作成したもの）で、自分の使用量を見てみました。

genshijinを使い始めたのは8月中旬です。日別推定コストを見ると、導入後は推定コストが低い日が増えました。特に8月22日の推定コストは、それ以前の稼働日より小さくなっています。

公式ベンチマークの数字だけでなく、自分の普段の利用状況にも変化が見えたのは素直にうれしかったです。

このグラフは、genshijinだけの効果を同じ条件で比較した実験ではありません。日ごとのタスク内容・作業量・利用モデル・稼働時間によってトークン使用量や料金は変わります。そのため、「genshijinを導入したからこの差がすべて生まれた」とは断定せず、導入前後に見えた傾向として紹介しています。

「挨拶ハラスメント」と組み合わせたら、5時間制限でほぼ止まらなくなった

自分はClaudeのMax 5xプランを使っています。それでも普段の開発では5時間の使用上限に達し、作業の途中で止まることがありました。

そこで以前から、平日の7時・12時・17時に軽いリクエストを送り、5時間枠の開始位置を業務時間に揃える運用をしています。詳しい仕組みはこちらの記事にまとめました。

挨拶ルーティンで枠の切れ目を揃え、genshijinで枠の中に使うトークンを抑える組み合わせです。

挨拶ルーティン: 5時間枠を7時・12時・17時起点に揃える
genshijin: 1回ごとの返答を圧縮してトークン消費を抑える

Max 5xプランでこの2つを併用してからは、5時間制限が原因で普段の作業が止まることはほぼなくなりました。枠を増やしているわけではありませんが、使える枠を仕事の時間に合わせ、その中身も節約する組み合わせが自分にはかなり効いています。

利用量はタスク内容やモデルによって変わり、5時間枠とは別に週次の上限もあります。すべての環境で上限に達しなくなるわけではなく、ここでは自分のMax 5xプランでの体感を紹介しています。

簡潔な返答が、自分の理解にもつながった

試す前は、トークンを節約するためのプラグインだと思っていました。

実際に使ってみて良かったのは、むしろ返答の要点を自分で理解しやすくなったことです。

長く丁寧な説明は安心感があります。ただ、説明が整いすぎているぶん、わかった気になって読み流してしまうこともありました。

genshijinの返答は、原因、変更、結果が短い文で並びます。余分な説明がないので、「なぜこの修正が必要だったのか」「この結果から何が言えるのか」を、自分の頭でも整理しながら読むようになりました。

短くても理解は浅くなりませんでした。自分の場合は、簡潔に伝えてもらうことが、かえって理解するための余白になりました。

もちろん、もっと詳しく知りたい箇所があれば、その部分だけ追加で質問できます。最初から全部の説明を受け取るのではなく、まず要点をつかみ、必要なところだけ掘り下げる使い方が自分には合っていました。

会話以外の圧縮機能もある

genshijinには、通常の返答を短くする機能以外にも、用途別のコマンドが用意されています。

コマンド	用途
`/genshijin-commit`	簡潔なConventional Commits形式のメッセージを生成
`/genshijin-review`	PRレビューの指摘を1件1行で出力
`/genshijin-compress <file>`	`CLAUDE.md`など、毎回読み込むファイルを圧縮
`/genshijin-stats`	セッションのトークン使用量と推定削減量を表示

特にCLAUDE.mdはセッション開始時に読み込まれるため、会話の出力だけでなく、毎回の入力トークンも減らせるのは面白いところです。

まずは通常の/genshijinだけ試し、慣れてから用途別の機能を使うのがわかりやすいと思います。

まとめ

genshijinを使うと、Claude Codeが日本語の敬語・前置き・クッション言葉を削り、技術的な要点を短く返してくれるようになりました。社内の利用状況でも、導入した8月中旬以降に日別推定コストが小さくなる日が見えています。

トークン節約が目的で試しましたが、自分にとって大きかったのは、Claudeの回答を理解しやすくなったことです。説明が短いぶん、原因・変更・結果を自分でも整理しながら読めました。

さらに、5時間枠を業務時間に揃える運用と組み合わせることで、Max 5xプランでも5時間制限によって作業が止まることはほぼなくなりました。

Claude Codeの返答を毎回読むのが少し大変と感じている方は、まず通常モードから試してみると、いつもの会話がかなり変わると思います。

参考

genshijin公式GitHubリポジトリ
genshijinのSKILL.md
Claude Codeが化けた。今使っている3つのプラグイン+標準機能の活用法 - Zenn
Claudeトークン消費を抑えて５倍使う: 「原始人」口調が80%削減 - Zenn

関連記事

Claude Codeのモデルを使い分けると成果物とトークンはどれくらい変わる？Opus＋Sonnetと全部Opusで同じものを作って比べてみた … 同じトークン確認システムを使って、今度はモデルの使い分けでコストがどう変わるかを比べた話