Claude Codeのcode-simplifierプラグインで直近の変更を整理する

code-simplifierは、Anthropicの公式マーケットプレイスに載っているプラグインです。中身はサブエージェント1つで、直近に書いた・触ったコードを、挙動を変えずに読みやすく整える役を担います。

入れるのは1コマンド、呼ぶのは@メンションか一言の依頼だけです。ただしREADMEが無く、仕様はエージェント定義の本文にしか書かれていません。ここでは定義を読み、何を約束し、何を約束していないかを切り分けます。

code-simplifierプラグインには何が入っているか

プラグインのディレクトリにあるのは3つだけです。

• .claude-plugin/plugin.json(メタ情報)
• agents/(エージェント定義のcode-simplifier.md)
• LICENSE

スキル、スラッシュコマンド、hooksは同梱されていません。入れて増えるのはサブエージェント1つです。plugin.jsonのversionは1.0.0、作者は「Anthropic」で、マーケットプレイスのカテゴリはproductivityです。

エージェント定義のフロントマターは次の3項目です。

toolsの指定が無いので、サブエージェントが使えるツールは制限されず、メインの会話から引き継がれます。ファイルを読むだけでなく、編集もできる前提の作りです。

定義が約束する範囲

システムプロンプトの核は「何をするか」より「何をしないか」にあります。定義を読むと、方針は5本に分かれます。

1. 機能を保つ。何をするかは変えず、どう実現するかだけを変える。出力や振る舞いは元のままにする
2. プロジェクトの規約に従う。CLAUDE.mdの標準を使うとあり、例としてESモジュールのimport整列、functionキーワードの優先、トップレベル関数の戻り値型の明示、ReactのProps型の明示、try/catchを避けるエラー処理が挙がっている
3. 明快さを上げる。ネストや冗長なコードの削減、命名の改善、自明なコメントの削除。ネストした三項演算子は避け、switchかif/elseの連鎖にする
4. 簡潔さを追いすぎない。「行数が減ること」を優先して、読みにくい1行詰めや、役に立つ抽象化の除去をしない
5. 範囲を絞る。現在のセッションで触れたコードだけを対象にし、広い範囲は明示された場合に限る

最後の一文は、実質的な使い方の指示でもあります。定義では「コードを書いた直後に、明示の依頼なしで自律的に整える」とも書かれています。ただし、プラグインを入れるだけで編集のたびに自動で走ると読み取れる記述はありません。確実に走らせたいときは、次の節の方法で自分から呼びます。

2番目の規約の例は、TypeScript・Reactのプロジェクトを念頭に置いた書き方です。PythonやGoのリポジトリでは、そのまま当てはまりません。この点は後の運用の節で扱います。

導入は/plugin installの1コマンド

公式マーケットプレイスclaude-plugins-officialは、対話セッションを初めて起動したときにClaude Code側が追加します。そのためマーケットプレイスの登録は不要です。

/plugin install code-simplifier@claude-plugins-official

セッション内でこのコマンドを打つと、すぐには入らず、/pluginパネルがこのプラグインの詳細で開きます。内容を確認し、スコープを選んで進めます。反映には/reload-pluginsが要ります。パネルを閉じると、保留中の変更について自動で再読み込みが走ります。

選べるスコープは3つで、違いは「誰に効くか」と「どの設定ファイルに記録されるか」です。

整理役は個人の好みで使うことが多いので、まず試すならlocalかuserが無難です。projectを選んでコミットしても、共同作業者のマシンにプラグインが自動で入るわけではありません。各自がclaude plugin install code-simplifier@claude-plugins-official --scope projectを一度実行します。同じプラグインを複数のスコープで設定した場合は、local、project、userの順で優先されます。

スクリプトや新しいマシンでは、シェルから入れる形もあります。

claude plugin marketplace add anthropics/claude-plugins-official
claude plugin install code-simplifier@claude-plugins-official

マシンで対話セッションを一度も開いていない場合、公式マーケットプレイスは未登録です。その場合は1行目のmarketplace addが先に要ります。

呼び出し方は3通り

サブエージェントを明示して使う方法は、Claude Code共通です。code-simplifierでも同じ型で動きます。プラグイン由来のエージェントは、プラグイン名で名前空間が付きます。規則に従えば、code-simplifierプラグインのcode-simplifierエージェントは、code-simplifier:code-simplifierの形で表示されます。

メンションの場合も、サブエージェントに渡るタスク文を書くのはClaudeです。メンションが決めるのは「どのエージェントか」で、プロンプトの中身ではありません。そのため、範囲は自分の依頼文で縛ります。

@agent-code-simplifier:code-simplifier
src/billing/ 配下で今日変更したファイルだけを整理して。
公開関数のシグネチャは変えない。終わったらテストを実行して結果を報告して。

「今日変更したファイルだけ」のように書くと、定義の「直近の変更に絞る」と整合します。範囲を広げたいときは、広げると明示します。定義も、広い範囲は明示された場合にだけ見ると書いています。

/simplifyとの違いと使い分け

Claude Codeには、似た名前のコマンド/simplifyがあります。役割は近いものの、仕組みが違います。

/simplifyの詳しい守備範囲はClaude Code /simplifyコマンドにあります。それぞれの使いどころを分けるなら、次の見立てになります。

• 4観点をまんべんなく見せたい、PR直前に流したい: /simplify
• 規約を教えたうえで、今のセッションの変更を整えさせたい: code-simplifier
• 整理をいつも同じ人格に任せたい、--agentで専用セッションにしたい: code-simplifier

同じ変更に両方を流す場合は、役割を分けると重なりません。まずcode-simplifierで、今のセッションの変更を自分の規約に沿って整えさせます。そのあとPRの前に/simplifyを流し、再利用できる既存ヘルパーの見落としや効率の観点を別の目で拾わせます。前者は規約を教えて整える作業、後者は4観点の点検です。

どちらもバグ探しの道具ではありません。code-simplifierの定義は「機能を変えない」を最上位に置きますが、正しさの検証をする仕組みは含まれていません。バグの検知は別のレビューに任せます。

運用で効かせるための3点

規約はCLAUDE.mdに書いておく

定義の「プロジェクト標準」の例はTypeScript寄りです。自分のリポジトリの規約と食い違いそうなときは、CLAUDE.mdに明記して食い違いの余地を減らします。次は書き方の一例です。

## コード整理の方針
- Pythonは型ヒントを必須とし、`dataclass`を優先する
- 例外の握りつぶしは禁止。整理時も try/except は残す
- 公開APIのシグネチャとログ出力の文言は整理で変えない

定義はCLAUDE.mdの標準に従うと述べています。ただし、定義内の例とCLAUDE.mdが食い違ったときの優先順位は書かれていません。食い違う項目は、はっきり書いておくのが無難です。

「挙動が変わっていない」はテストで確かめる

「機能を保つ」はプロンプト上の約束です。コード上の保証ではありません。整理を頼むときは、テストの実行までを同じ依頼に含めます。上の例の「終わったらテストを実行して」はそのためです。差分はdiffパネルやgit diffで目視し、意図しない変更が混ざっていないかを見ます。

整理を頼む前に、手元の変更をいったんコミットしておくと、結果が気に入らないときに戻せます。

git add -A && git commit -m "wip: 整理前"
# 整理を依頼したあと、差分を確認する
git diff
# 気に入らなければ、整理前の状態に戻す
git restore .

git restore .は作業ツリーの未コミットの変更をすべて捨てます。整理前のコミットを挟んでおけば、捨てられるのは整理の結果だけです。

モデルとコストは定義が決めている

フロントマターのmodel: opusは、サブエージェントのモデルとして効きます。解決順は次のとおりです。

1. 呼び出しごとのmodelパラメータ
2. 定義のフロントマター
3. CLAUDE_CODE_SUBAGENT_MODEL環境変数
4. メインの会話のモデル

メインの会話がSonnetでも、環境変数だけではopus指定は動きません。全サブエージェントを1つのモデルに揃えたい場合はCLAUDE_CODE_SUBAGENT_MODEL_FORCEを使い、これがオンの間は定義のmodel欄が無視されます。モデルの配分設計はサブエージェントのモデル配分設計にまとめています。整理作業は変更の量に比例してトークンを使うので、範囲を絞る依頼文はコストの面でも効きます。

プラグイン由来のサブエージェントに付く制約

プラグインのサブエージェントは、セキュリティ上の理由でhooks、mcpServers、permissionModeの3つのフロントマター項目が無視されます。code-simplifierの定義はこの3項目を使っていないので、影響しません。

たとえば「整理後に必ずリンターを走らせる」を、このエージェントのhooksで固定することはできません。やるならプロジェクト側のsettings.jsonにhooksを置くか、エージェントのファイルを.claude/agents/にコピーして手元で改造します。サブエージェントの起動と終了を拾うhooksはSubagentStart/SubagentStop hookの記事で扱っています。

コピーして改造した場合は、同じnameのエージェントが複数存在することになります。スコープの優先順は、プロジェクトの.claude/agents/がプラグインのagents/より上です。手元の改造版が優先されます。

まとめ

code-simplifierは、整理の作法を1枚のプロンプトに畳んだ小さなプラグインです。自動で走ると決めつけず、@メンションか依頼文で呼んで、範囲とテストを自分で指定する使い方が、定義の言う「直近に絞る」と噛み合います。

規約の例がTypeScript寄りである点、「挙動を変えない」がテストでしか確かめられない点は、導入前に知っておく価値があります。CLAUDE.mdに規約を書き、テストの実行を依頼に含める。この2点を押さえれば、他の言語でも使える形になります。