/simplify｜Claude Codeのコードを簡潔にする機能

「Claude Codeに/simplifyというコマンドがあるらしいが、/code-reviewと何が違うのか分からない」「昔読んだ記事では/simplifyがバグを直してくれると書かれていたのに、今使ったらそんな動きをしない」——検索してこのコマンドにたどり着いた人の中には、こうした食い違いに戸惑っている人が少なくありません。

結論から言うと、/simplifyはバグを探さず、コードの重複・非効率・不必要な複雑さだけを見つけて、その場で直すコマンドです。バグを探すのは/code-reviewの仕事、と公式ドキュメントがはっきり役割を分けています。加えて、「昔の記事の説明と違う」と感じた方の直感は正しく、この名前は過去に一度、まったく別の意味で使われていたという経緯があります。

株式会社Fyveは中小企業のAI業務活用を支援しており、Claude Codeを日常の実務で使っています。この記事では、/simplifyが公式にどういう機能とされているかを整理したうえで、手元のClaude Code（v2.1.260・macOS）で実際に動かして確認できたこと——何を直し、何を意図的に直さなかったか——を、公式ドキュメントの記載とはっきり区別して書きます。

/simplifyとは——「きれいにするだけ」のコマンド

/simplifyは、Claude Codeに標準搭載されているバンドル済みスキルの1つです。公式の説明は次のとおりです。

コマンド：/simplify
Purpose（公式の説明・原文）：Review the changed code for reuse, simplification, efficiency, and altitude cleanups, then apply the fixes. Quality only — it does not hunt for bugs; use /code-review for that.
分類：Skill（バンドル済みスキル）

日本語にすると、「変更したコードを、再利用・簡潔化・効率・構造面の観点で見直し、修正を適用する。対象は品質だけで、バグは探さない。バグ探しは/code-reviewを使うこと」となります。ポイントは2つです。

対象は「品質」の4観点だけ——再利用（reuse）・簡潔化（simplification）・効率（efficiency）・構造面の整理（altitude）。バグや脆弱性はこの4つに含まれません
見つけたら、その場で修正を適用する——/code-reviewが指摘を報告するだけで、コードに反映するには--fixフラグが必要なのに対し、/simplifyは指摘イコール修正で、フラグなしでも直接ファイルを書き換えます（この点は後述の手元確認でも実際に確認できました）

reuse・simplification・efficiency・altitudeは、それぞれ何を指すか

公式の説明は4つの英単語を列挙しているだけで、個々の定義までは踏み込んでいません。一般的なコードレビューの文脈での使われ方と、後述する手元の実行結果を踏まえると、次のように読むのが妥当です。

reuse（再利用）：同じ処理があちこちに書かれている状態を、共通化・関数化する観点
simplification（簡潔化）：回りくどい書き方や、不要な条件分岐・中間変数を削る観点
efficiency（効率）：無駄な計算・重複した処理を減らす観点
altitude（構造面の整理）：個々の行ではなく、コード全体の設計や抽象化の水準（「高度」）を見る観点。手元の確認では、この観点を担当するとみられるエージェントが、コードの行単位の指摘だけでなく「これはテスト用のフィクスチャに見える」というコード全体の性質についての所感まで返していました

この4分類そのものの定義は公式ドキュメントに明記されているわけではなく、上記は一般的な用語の使われ方と、次章の実行結果から得られた観察を組み合わせた解釈です。断定的な定義としてではなく、目安として読んでください。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

手元で動かして確認したこと

公式の説明だけでは「品質だけを直す」の実際の線引きが分かりにくいため、手元のClaude Code（v2.1.260・macOS、2026年9月4日確認）で小さなサンプルコードを用意し、実際に/simplifyを動かしてみました。

用意したのは、次の3つの問題を含む短いPythonファイルです。

同じ計算を3回繰り返し、2つを使わずに捨てている無駄な変数（x = a + b; y = a + b; z = a + b; return x）
1回しか使わない値に、わざわざ名前をつけているだけの中間変数
ユーザー入力をそのままos.system()に渡すコマンドインジェクション、および文字列連結でSQL文を組み立てるSQLインジェクション（比較のため意図的に混入した脆弱性）

この差分に対して引数なしで/simplifyを実行したところ、次のように動きました。

直したもの：無駄な変数の重複計算はreturn a + bに、1回しか使わない中間変数はその場でreturnする形に、それぞれ自動で書き換えられました。修正後、実際にpython3で実行して元と同じ出力になることまで確認されていました
直さなかったもの：コマンドインジェクションとSQLインジェクションの2箇所には、まったく手を加えませんでした。理由として返ってきた説明を要約すると、「正しい修正（シェルを介さない実行への置き換え、パラメータ化されたクエリへの置き換え）は、いずれも関数の返り値や振る舞いを変えることになる。これは品質の整理ではなく、/code-reviewが扱う領域だ」という趣旨でした

修正後の差分はgit diffで自分の目でも確認しました。書き換わっていたのは重複変数・中間変数の2箇所だけで、os.system()への文字列連結、SQL文の組み立て部分は1文字も変わっていませんでした。「品質だけを直し、振る舞いに関わる部分には触れない」という公式の説明が、実際のファイルの差分としてもそのとおりになっていたことになります。

書き換えの実例

直った箇所：x = a + b／y = a + b／z = a + b／return x の4行 → return a + b の1行に統合
直った箇所：query = "SELECT ... " + table + " ... " + user_id + "'" と書いてからreturn queryする2行 → 組み立てた文字列をそのままreturnする1行に統合
直らなかった箇所：SQL文を+で連結して組み立てている書き方そのもの、os.system("echo " + user_input)の文字列連結そのものは、1文字も変更されませんでした

2番目の例が分かりやすい境界線です。「1回しか使わない変数に名前をつけているだけ」という体裁上の無駄は直す一方、「文字列連結でSQL文を組み立てている」という設計そのものの危うさには、体裁を整える形では触れませんでした。見た目の行数や変数の数を減らすことと、安全な組み立て方に書き換えることは別の作業だと、この2行の扱いの違いから読み取れます。

興味深かったのは、この判断の根拠として複数の内部エージェントの存在が明示的に出てきた点です。重複変数の指摘は「4つのエージェント全員が指摘」、脆弱性を見送った判断には「altitude担当のエージェント」という言葉が使われていました。公式の説明にある「reuse・simplification・efficiency・altitude」の4観点は、単なる説明上の分類ではなく、実際に複数の視点で確認したうえで統合しているらしいことが、手元の実行結果から見て取れました（この内部構造の詳細は公式ドキュメントには記載がなく、あくまで今回の実行結果からの観察です）。

この結果から、/simplifyが「品質だけを直す」と説明されている境界線は、少なくとも今回試した範囲では、公式の説明どおりに機能していることが確認できました。ただしこれは1回の実行結果であり、すべてのケースで境界が常に同じように引かれることを保証するものではありません。

実行にかかる時間——バックグラウンドで動き、対話は止まらない

公式ドキュメントによると、/code-reviewは既定でバックグラウンドのサブエージェントとして動作し、レビューが終わるまで会話が止まることはありません（v2.1.218より前は会話の中で直接動いていました）。/simplify自体についてこの挙動を明記した記載は見当たりませんでしたが、手元の実行では、複数ターンにわたって処理が進み、完了すると修正内容の要約とともに結果が返ってくるという、よく似た体感でした。今回の小さなサンプルコードに対する実行だけでも10ターン分のやり取りを経ており、実際のコードベースではファイルの規模に応じてさらに時間がかかることが見込まれます。

自動適用される性質上、実行後は必ずgit diffで変更内容に目を通す習慣をつけることをおすすめします。今回の確認では意図どおりの変更だけでしたが、自動で書き換わったコードをそのままコミットする前に、変更範囲が想定どおりかを確認する一手間は省略しないほうが安全です。

/code-reviewとの違い——同じdiffを見ても役割が違う

/simplifyと/code-reviewは、どちらも「今の変更（diff）」を対象にする点は共通していますが、見ているものと動き方がはっきり違います。

	/simplify	/code-review
探すもの	重複・非効率・構造の整理（品質のみ）	正しさのバグ＋品質の整理の両方
脆弱性・セキュリティ	対象外（見つけても直さず/code-review行きと明言）	対象に含む
修正の適用	既定で自動適用	`--fix`を付けたときだけ適用
エフォートレベル指定	公式ドキュメントに記載なし（未確認）	low〜max、ultraを指定可能
対象範囲の指定	今回の確認では引数なしのみ試行	PR番号・ブランチ・パスを指定可能
PRへの投稿	公式ドキュメントに記載なし	`--comment`でインラインコメント投稿可

「バグや脆弱性が心配なときは/simplifyでは不十分」というのが実務上の要点です。/simplifyが指摘・修正するのはあくまで品質面で、セキュリティやロジックの誤りを扱うのは/code-reviewの役目です。今回の手元確認でも、/simplifyは脆弱性を検知していながら、それを「自分の仕事ではない」として明確に見送っていました。/code-review自体の使い方・エフォートレベル・PR連携については、こちらにまとめています。

Claude Code/code-review｜Claude Codeのコードレビュー

なお、脆弱性そのものを重点的に確認したい場合は、/code-reviewとは別に、脆弱性チェックに特化した/security-reviewというコマンドも標準搭載されています。/simplifyとは対象がまったく異なる機能なので、あわせてこちらも参考にしてください。

Claude Code/security-review｜Claude Codeのセキュリティレビュー機能

名前にまつわる歴史的な注意——古い情報に惑わされないために

「昔の記事では/simplifyの説明が違った」と感じた方の直感は正しく、公式ドキュメントにはっきりと経緯が書かれています。

公式の記載を要約すると、v2.1.147より前のバージョンでは、今の/code-reviewにあたる機能が「/simplify」という名前で提供されており、当時は既定で修正を適用する仕様だったとされています。その後、この機能は/code-reviewという名前に変わり、代わりに現在の「品質の整理だけを行う、別のクリーンアップ専用コマンド」が新たに/simplifyという名前を引き継ぎました。公式ドキュメントは「もし/simplifyをバグ探しの用途でスクリプトに組み込んでいたなら、/code-review --fixに切り替えてください」と明記しています。

つまり、同じ「/simplify」という名前が指すものが、バージョンの境目で入れ替わっています。古いブログ記事や社内の手順書に「/simplifyでバグを直す」という記述が残っている場合、それは名前が入れ替わる前の情報である可能性が高いです。自動化スクリプトなどで/simplifyを使っている場合は、今の挙動（品質の整理のみ・バグは扱わない）を前提に、想定と食い違っていないか一度確認することをおすすめします。

実務でどう使うか

プルリクエストを出す前の「仕上げ」として使う——重複コードや無駄な変数を、自分で1つずつ見つけて直す手間を省けます
バグ・脆弱性の心配があるときは/code-reviewを別に走らせる——/simplifyだけで「レビューが済んだ」と扱わないようにします
自動適用される前提で、事前にコミットしておく——/simplifyは既定でファイルを書き換えるため、直前の状態に戻せるよう、実行前に一度コミットしておくと安心です
古い情報（v2.1.147より前の説明）を見つけたら、バージョンを疑う——「/simplifyがバグを直した」という記述は、名前が入れ替わる前の話である可能性が高いです
CIや自動化スクリプトに組み込む前に、まず手元で試す——今回確認できたのは引数なしで実行した1パターンのみです。対象範囲を絞る引数の有無や、大規模な差分での挙動は確認していないため、本番の自動化に組み込む前に、対象のリポジトリで一度試してから判断することをおすすめします

Claude Codeには、この他にも追加インストールなしで使えるバンドル済みスキルが複数あります。全体像は以下にまとめています。