/simplify（シンプリファイ）

Claude Codeで実装が一段落して、PRを出す前に「もう少し整えてから出したい」と思っている個人開発者・個人事業主向け

Claude Code でひと通り実装が終わって、いざ PR を出そうとしたとき。コードを眺めてると「同じ処理が2か所にコピペされてる」「使ってない変数宣言が残ってる」みたいな小さい引っかかりが出てくるものです。1人開発だと、ここを自分で1か所ずつ直すのが地味にしんどい。

/simplify は、その「PR 出す前のひと整え」を3並列の review agent に任せて、見つけた問題を実際に書き換えまで自動でやってもらうコマンドです。Claude Code に同梱されている bundled skill（クロード公式が初期搭載しているスキル枠）の1つで、特別なセットアップなしに使えます。

ここがポイント。

噛み砕くと

会社で言うと「コードレビュー会議の前に、後輩3人にざっと目を通してもらって、明らかにヤバいところは勝手に直しといて」と頼む感じに近いです。3人がそれぞれ別の観点（重複コード／品質／効率）で読んで、最後にまとめて修正が入ります。

同じ「PR 出す前のコマンド」でも、/diff は「変更箇所を見せるだけ」、/review は「気付きを言うだけ」で、どれもファイルには触りません。/simplify だけが書き換えまで踏み込みます。

大事な前提：これは「見るだけ」ではなく「書き換える」コマンド

このコマンドを叩くと、Claude が直近変更されたファイルを実際に書き換えます。/review や /security-review と同じ感覚で「とりあえず確認のために叩いてみるか」とやると、戻ったらコードがそこそこ変わっていて戸惑うことになります。

安全に試したいなら、叩く前に git commit か git stash でいったん状態を保存してから走らせるのが鉄則です。万が一気に入らない書き換えがあっても、git diff で違いを見て元に戻せます。

「副業で週末に作った LP」を例に、実際の手順を見る

週末に副業で LP（ランディングページ、商品紹介の1ページもの）を一気に書いた状況を想定します。HTML / CSS / JavaScript を勢いで実装して、月曜の朝に PR を出したい。でも自分のコードを冷静に見ると、コピペした痕跡や宣言したまま使ってない変数がちらほら残ってる。そういう場面です。

ステップ1: まず変更内容を自分の目で確認する

いきなり /simplify を叩く前に /diff で「自分が何を書いたか」を一覧で確認します。これは見るだけのコマンドなので、ファイルは1ミリも変わりません。

> /diff

HTML 200行、CSS 150行、JS 80行が変わってるのが見える、みたいな全体像が掴めます。

ステップ2: いったん commit しておく（保険）

書き換えが入る前の状態を保険として残します。気に入らなければここに戻ればいい。

$ git add .
$ git commit -m "WIP: LP draft before /simplify"

ステップ3: /simplify を叩く

ここで本体を起動します。コマンドの後ろには何も書き足さなくていいです。

> /simplify

Claude Code が裏で3つの review agent を spawn（同時に立ち上げる動作）して、それぞれが直近変更ファイルを並行で読み始めます。1人目は「重複コード」、2人目は「品質」、3人目は「効率」みたいなイメージで観点が分かれてます。

ステップ4: 集約と書き換えが走る

3人分の指摘が出揃ったら、Claude 本体がそれをまとめて、実際にファイルへ修正を当てます。ここで初心者がやりがちな勘違いがある。「指摘リストを見せてくれるだけ」と思って眺めていると、もう書き換わってる、みたいな順番です。

例えばこういう修正が入ります。

• JS で「フォーム送信処理」が contact-form と signup-form の2か所にほぼ同じ形でコピペされていた → 共通関数に抽出
• CSS で .btn-primary の色定義が3か所に散らばっていた → 1か所に統合
• HTML で使ってない data-tracking-id 属性が残っていた → 削除

ステップ5: 自分の目で diff を見る

書き換え後にもう一度 git diff を叩いて、何が変わったか自分で確認します。納得いかない修正があれば、その部分だけ元に戻せます。

$ git diff

ステップ6: 観点を絞りたいときは focus を添える

もし「今回はメモリ効率だけ重点的に見てほしい」みたいに方向性を傾けたいときは、コマンドの後ろにその旨を書き足せます。

> /simplify focus on memory efficiency

これは「メモリ効率以外を完全に無視する」という強い切り替えではなく、「3人の review agent の判断軸をそっちに寄せる」くらいの効き方です。重複コードの指摘が消えるわけではない。

つまり /simplify は何をしてくれるのか

• やってくれる: 直近変更したファイルを3並列でレビュー → 重複コード・冗長な記述・効率の悪い書き方を発見 → 実際にファイルへ修正を当てる、までを一気通貫
• やってくれない: アーキテクチャの作り直し、新機能の追加、テストコードの自動生成、ライブラリ更新。あくまで「直近の変更を整える」までの範囲
• 意味が薄い場面: 直前に何も変更していないクリーンな状態で叩いても何も起きません。git の変更履歴に最近の動きがあって初めて働くコマンドです

使いどころ3シナリオ（具体題材で再現）

シナリオ1: 副業 LP の PR を月曜朝に出す前

週末に勢いで HTML / CSS / JS を書いた後、月曜の朝にレビュー依頼を出す直前。自分1人だと見落とす「同じセクションのコピペ」「使ってない CSS クラス」が3並列レビューで拾われます。私のように1人で副業コードを書いてる人にとっては、第二の目として使えるのが大きい。

シナリオ2: 家計簿アプリの機能追加を終えたタイミング

個人開発の家計簿アプリに「月別グラフ表示」機能を足し終わったとき。グラフ描画ロジックを chart.js 周りに書いたあと、同じデータ整形処理が「月別」「年別」「カテゴリ別」の3画面でコピペされてたりします。/simplify を叩くと、そういう重複を共通関数に切り出してくれる。

シナリオ3: GitHub から拾ってきた OSS に小さい修正を入れた後

GitHub から OSS（オープンソースソフトウェア）を持ってきて、自分用に1〜2機能だけ足したい場面。元コードのスタイルに合わせたいけど、自分が書き足した部分だけ浮いてしまいがちです。/simplify を直近変更ファイルに当てれば、書き足し部分が周囲のコードスタイルに馴染むよう整えてくれます。

初心者が踏みやすい落とし穴

• 「見るだけ」と勘違いして叩くとファイルが書き換わる。/review /security-review /diff はファイルに触らないので同じ感覚で叩くと事故ります。事前に git commit か git stash しておくのが安全
• 「最近変更したファイル」の判定は git の変更履歴ベースっぽい。公式ドキュメントに細かい定義は書かれてませんが、recently changed files という表現から、git で追跡されている working tree や staged の変更を見ていると推測できます。git 管理外のファイルが対象になるかは公式に明示なし
• 3並列で動くので消費が単発より多い。review agent を3つ spawn する設計なので、1回叩くと内部的にはレビュー3回分くらいの処理が走ります。Max プランの5時間ウィンドウや API のレート制限を気にする人は、雑に連打しないほうが無難
• focus は「絞り込み」ではなく「優先度の傾け」。/simplify focus on memory efficiency と書いても、メモリ効率以外を完全無視するわけじゃない。3並列レビューの観点が少しそっちに寄る、くらいの効き方です
• PR 前に3兄弟を全部連打しないこと。/simplify /review /security-review を毎回連打すると指摘が重複します。公式 docs の Workflow セクションに沿うなら「/diff で確認 → /simplify で整える → /review で第三者目線 → /security-review で安全確認」の順で、必要なものだけ使うのが効率的

書き方

/simplify
/simplify focus on memory efficiency

やってみるとこうなる

入力

> /simplify

出力例

Claude Codeが裏で3つのreview agentを並行で立ち上げ、直近変更されたファイルを別観点（重複コード／品質／効率）で読みます。指摘が出揃ったら本体がまとめて、実際のファイルに修正を当てます。

例: フォーム送信処理がcontact-formとsignup-formの2か所にコピペされていれば共通関数に抽出、CSSの.btn-primary色定義が3か所に散らばっていれば1か所に統合、使われていないHTML属性は削除、といった書き換えが入ります。

書き換え後は `git diff` で何が変わったかを自分の目で確認できます。納得いかない修正は元に戻せるので、走らせる前に `git commit` か `git stash` しておくのが安全です。

関連項目

• /diff（ディフ）
• /review（準備中）
• /security-review（セキュリティレビュー）
• /batch（バッチ）
• /agents（エージェンツ）

公式ドキュメント

https://code.claude.com/docs/en/commands