株式会社TIMEWELLの濱本です。今日はテック関連のサービスご紹介です。
AIがコードを書くのが当たり前になった昨今、「個人の生産性を上げるツール」としてのAIはもう珍しくありません。ただ、大規模なプロジェクトでAIをどう活かすかとなると、まだ多くの開発者が手探りの状態ではないでしょうか。
そんな中、AIコーディングツール「Claude Code」が面白い方向に舵を切りました。一人のAIアシスタントに指示を出すツールから、複数のAIエージェントをチームとして動かすツールへの進化です。
2026年2月28日にリリースされたバージョン2.1.63 [^1] の目玉は、/simplifyと/batchという2つの新コマンド。便利機能が増えた、というレベルの話ではなく、開発のワークフローそのものが「一人」から「チーム」へ変わる転換点だと私は考えています。
Claude Codeを触ったことがない方でも理解できるように、基本から丁寧に解説していきます。
Claude Codeとは？
Claude Codeは、ターミナル上で対話しながら開発を進めるAIアシスタントです [^2]。エンジニアが日常的に使うあの黒い画面の中で動きます。
よくあるチャットボットとの違いは、Claude Codeが「エージェント」として能動的に動く点にあります。質問に答えてコード片を提示するだけではなく、実際にファイルを編集し、コマンドを実行し、Gitの操作まで自分でやってくれる [^3]。
たとえば「main.pyを開いて、helloという関数を追加して」と頼めば、本当にファイルを書き換えます。「テストを実行して結果を教えて」と言えば、テストコマンドを叩いて出力を見せてくれます。「新しいブランチを切って、今の変更をコミットして」も可能です。
これまでの開発は「どのファイルに情報があるか探す」「修正方法を考える」「コマンドを打つ」という思考とアクションの繰り返しでした。Claude Codeはこのプロセスを変えます。開発者は「何をしたいか」を伝えるだけでよくなり、定型作業から解放されて「何を作るべきか」という創造的な部分に集中できるようになります。
この「エージェント」という考え方がClaude Codeの最大の特徴であり、今回のアップデートでは、このエージェントが一人ではなくチームとして連携し始めました。ここが核心です。
開発の常識を覆す「エージェントチーム」という考え方
衝撃的な数字から始めます。Claude Codeの開発責任者であるBoris Cherny氏が、2025年12月にXで公開したデータです。
「過去30日間で259のプルリクエストをマージした。497コミット、4万行のコード追加、3.8万行の削除。その一行一行すべてが、Claude CodeとOpus 4.5によって書かれたものだ。」[^4]
30日で259PR。1日あたり約8.6個の機能追加や修正を完了させている計算になります。熟練エンジニアでも達成が難しい数字を、AIが書いたコードだけで叩き出しています。
興味深いのは、Boris氏のセットアップが「surprisingly vanilla（驚くほど普通）」だという点です。ターミナルで5インスタンス、ブラウザで5から10セッションを同時に走らせ、入力が必要なセッションにはシステム通知で飛ぶ。特別なハックは何もなく、規律あるワークフローの徹底がこの数字を生んでいるそうです。47日間中46日間アクティブセッションを維持し、最長セッションは約1日18時間。ここまで聞くと、もはや人間とAIの境界が曖昧になってきます。
2026年2月、Boris氏はポッドキャスト「Lenny's Podcast」でさらに踏み込んだ発言をしました。
「現時点では、コーディングはほぼ解決されたと言っていい。」[^5]
誤解されがちな発言ですが、「人間がコードを書く必要がなくなった」という意味ではありません。コードを「書く」行為自体はAIで大幅に自動化できるようになったので、開発者の役割は「何を作るか」を考え、AIに指示し、全体を監督するアーキテクトやプロダクトマネージャーに近づいていく、ということです。
実際、Anthropic社内ではエンジニアの生産性が一人あたり200%向上し、公開GitHub上の全コミットの4%がClaude Codeによるものだというデータも出ています [^5] [^6]。
この生産性を支えているのが、一人のスーパーエージェントに頼るのではなく、複数のエージェントを協調させる「エージェントチーム」の考え方です。複雑なタスクを小さなサブタスクに分割し、複数のAIに並列で処理させる。順番に作業するより圧倒的に速い。
そして、このアプローチを技術的に実現したのが git worktree のネイティブサポートでした [^7]。
革命の土台「git worktree」とは？
初めて聞く方のために解説します。
通常、Gitで別のブランチを見たくなったら、今の作業をコミットするかstashで退避し、ブランチを切り替え、用が済んだらまた戻る、という手順を踏みます。地味に面倒です。
git worktreeはこの問題を解決する仕組みで、一つのリポジトリから複数の作業ディレクトリを、それぞれ別のブランチに紐づけて同時に作成できます [^8]。
イメージしやすいたとえを出すと、一つの大きなキッチンの中に、中華専用の調理台、イタリアン専用の調理台、和食専用の調理台を同時に用意するようなものです。それぞれの調理台は独立していて、中華の鍋を振っている隣でパスタを茹でても干渉しない。ただし冷蔵庫や食材庫は共有しています。
開発に置き換えると、feature-authブランチの作業をworktree-Aディレクトリで進めながら、同時にbugfix-123ブランチの作業をworktree-Bディレクトリで進められる。物理的にディレクトリが分かれているので、ブランチの切り替えは不要です。
Claude Codeはこの仕組みを内部で活用し、複数のAIエージェントにそれぞれ独立した作業環境を与えています。互いの作業が衝突することなく、安全に並列作業できる。/batchコマンドはまさにこの基盤の上に成り立っています。
使い方はシンプルで、--worktreeフラグをつけて起動するだけです。
# "feature-auth" という名前のworktreeを作成して起動
claude --worktree feature-auth
プロジェクトルートの.claude/worktrees/feature-authにディレクトリが作られ、Claude Codeはその中で独立したセッションを開始します。メインの作業ディレクトリを汚さずに、新機能の開発や実験的な修正をAIに任せられるわけです [^7] [^8]。
この「作業空間の分離」という技術基盤があったからこそ、/simplifyや/batchが実現できました。
/simplify ― PR前の品質チェックを自動化する「AIレビューチーム」
コードレビューは品質を担保するために欠かせない工程ですが、正直なところ、楽しい作業ではありません。スタイルガイドの細かいチェック、もっと効率的な書き方がないかの検討、タイポの指摘。こうした本質的でない部分にレビュー時間が吸い取られていく経験は、多くの開発者に心当たりがあるはずです。
/simplifyは、この問題に正面から取り組む機能です [^9]。
/simplify は何をしてくれるのか？
コードに対して複数のAIエージェントを同時に起動し、3つの異なる観点から並列でチェックと改善を行います [^10]。
| チェック観点 | 内容 |
|---|---|
| コード品質 | 読みやすさ、保守しやすさ。変数名の適切さ、関数の複雑度など |
| コード効率 | パフォーマンス上の問題。不要なループ、不適切なデータ構造など |
| CLAUDE.md準拠 | プロジェクト固有のコーディング規約への適合 |
品質担当、パフォーマンス担当、規約担当の3人のレビュアーが一斉にコードを見てくれるようなものです。
実践的な使い方
使い方は拍子抜けするほど簡単です。コード変更の指示に「then run /simplify」と付け加えるだけ。
> hey claude, このAPIクライアントにタイムアウト処理を追加して。 then run /simplify
Claude Codeがまずタイムアウト処理を実装し、完了すると自動で/simplifyが走り、3つの観点からレビューが始まります。改善点が見つかればAIが自らコードを修正し、より洗練された状態に仕上げてくれます。
PRを出す直前の「最終防衛ライン」として使うのが個人的にはおすすめです。AIによるセルフレビューを挟むことで明らかな問題を事前に潰し、人間のレビュアーは設計やロジックの妥当性という、もっと頭を使うべき議論に集中できるようになります。
初心者向け解説: 3つのチェック観点をもう少し具体的に
コード品質とは、「将来の自分や他のメンバーが読んだ時に、すぐ理解できて安全に変更できるコード」のことです。/simplifyは、たとえばdataやtempのような曖昧な変数名をuser_listやcustomer_nameに変更する提案をしたり、何百行もある巨大な関数を小さく分割する提案をしたりします。if (status == 2)のような意味不明な数字（マジックナンバー）をconst STATUS_APPROVED = 2;と定数化する提案も行います。
コード効率とは、CPUやメモリを賢く使うコードかどうかです。ループの中で毎回同じ計算を繰り返しているような無駄を見つけてループの外に出したり、大量データの検索にリストを使っている箇所をハッシュマップに置き換える提案をしたりします。
CLAUDE.md準拠は少し説明が必要です。CLAUDE.mdはプロジェクトのルートに置く設定ファイルで、チーム独自のルールを書いておくとClaude Codeがそれを読んで従ってくれます [^11]。
# CLAUDE.md
## コーディング規約
- すべての公開関数には、必ずドキュメントコメントを記述すること。
- 1行の文字数は、80文字以内とすること。
- APIのエンドポイントを追加する際は、必ずOpenAPI仕様書も更新すること。
こう書いておけば、/simplify実行時にAIが「ドキュメントコメントが抜けています」「この行は80文字を超えています」「OpenAPI仕様書が更新されていません」と自動で指摘し、修正までしてくれます。チームの暗黙知をファイルに落とし込むだけで、AIが規約の番人になるわけです。
旧プラグイン版との違い
以前から/plugin install code-simplifierでインストールできる似た機能はありました。Boris氏がThreadsのリプライで「/simplifyはcode-simplifierと同じか」と聞かれ、「No, it's a bit more advanced（いや、もう少し高度だ）」と答えています [^10]。
旧プラグイン版は「コードの明確性、一貫性、保守性の改善」に特化した単一エージェント構成でした。新しい/simplifyは品質、効率、規約という異なる専門性を持つ複数のエージェントが並列で動く「チーム」構成です。単一構成からチームへの構造変化。これが「a bit more advanced」の中身です。
/batch ― 大規模なコード移行を自動化する「AI移行チーム」
/simplifyが個々のコード変更を磨く「レビューチーム」だとすれば、/batchはプロジェクト全体にまたがる大規模な変更を組織的に実行する「移行チーム」です。
古いライブラリから新しいライブラリへの移行。全ファイルへのTypeScript型定義の追加。社内規約変更に伴う全社的なコード修正。一つ一つの変更は単純でも、対象が数百、数千ファイルに及ぶと膨大な時間がかかります。手作業ではミスも出る。開発チームにとって、こうした作業は長年の悩みの種でした。
/batchは、この「多数のファイルに同じパターンの変更を適用する」タスクを、数十のAIエージェントを動員して自動化します [^10]。
/batch の内部で何が起きているのか
実行すると、以下の4つのフェーズが自律的に進行します [^12]。
| フェーズ | 内容 |
|---|---|
| 1. 計画 | メインエージェントがあなたと対話しながら移行計画を策定。対象ディレクトリ、変更内容、除外ファイルなどを確認 |
| 2. 並列実行 | 計画に基づきタスクを細分化し、数十のSubagentを起動。各Subagentに担当ファイル群を割り当て |
| 3. 完全分離 | 各Subagentがそれぞれ独立したgit worktree環境で作業。エージェント同士は干渉しない |
| 4. テストとPR | 各Subagentが自律的にテストを実行し、成功すればPRを自動作成。失敗すれば修正を試みるか、人間に助けを求める |
この一連の流れがすべて自動で、かつ並列に進みます。開発者は最初の計画を承認した後、次々と作成されるPRをレビューしてマージしていくだけ。数週間かかっていた移行作業が、数時間で終わる可能性すらあります。
具体的なユースケース
Boris氏が示した公式の使用例は、フロントエンドフレームワークをSolidからReactへ移行するケースです [^10]。
> /batch migrate src/ from Solid to React
このコマンド一つで、src/以下のすべてのファイルに対してSolidの記法をReactに書き換える作業をAIチームが実行します。
応用例としては、TypeScriptのstrictモード有効化も考えられます。tsconfig.jsonで"strict": trueを有効にすると大量の型エラーが発生しますが、/batchでファイルごとにSubagentに割り当てて並列修正させることができます。
> /batch add TypeScript strict types to src/
新しいLintルール導入時のエラー一括修正や、テストコードの並列追加にも使えるでしょう。
コンフリクトの扱い
並列作業と聞いて気になるのがコンフリクトです。ただ、/batchはgit worktreeによる物理的なファイル空間の分離を前提としているため、ほとんどのコンフリクトは構造的に発生しません。各Subagentの担当ファイル群は基本的に独立しているからです。
例外は、複数のSubagentが同じ共有ファイルを編集しようとしたケース。設定ファイルや共通ユーティリティなどがこれに該当します。その場合は、PRをマージする段階でメインエージェントか人間がコンフリクトを解決する必要が出てきます。
つまり/batchが最も威力を発揮するのは、「多数のファイルに同じパターンの変更を適用するが、ファイル間の依存が少ない」タスクです。
自分でbatch的ワークフローを組む方法
/batchの思想は自分の手でも応用できます。カスタムエージェントの定義ファイルのfrontmatterにisolation: worktreeを追加するだけで、そのエージェントがgit worktreeの分離環境で動くようになります [^7]。
# .claude/agents/test-runner.md
---
name: test-runner
model: haiku
isolation: worktree
---
あなたは優秀なテストエンジニアです。
指定されたファイルに対応するテストコードを記述し、実行してください。
こう設定すれば、「プロジェクト内のすべてのサービスファイルに対して、並列でテストコードを追加する」といった独自のbatchワークフローを設計できます。この柔軟性が、Claude Codeを単なるツールではなく開発者の創造性を拡張するプラットフォームにしていると感じます。
非git環境でも使える
日本のエンタープライズ環境では、SubversionやPerforceがまだ現役で動いているケースが少なくありません。worktree分離はgit専用に見えますが、実はMercurial、Perforce、SVNのユーザーでも恩恵を受けられます。WorktreeCreateとWorktreeRemoveというフックを定義すれば、gitなしでも分離環境を構築できる仕組みが用意されています。
レガシーなバージョン管理システムを使っているからといって、/batchの並列処理を諦める必要はないわけです。この配慮は、エンタープライズ向けの導入ハードルを下げる意味で地味に大きいと思います。
知っておくべき注意点とハマりポイント
強力な機能には、それなりの落とし穴がつきものです。事前に知っておけば回避できるものばかりなので、ここでまとめておきます。
コンテキストウィンドウの消費問題
Claude Codeが賢く動くための源泉は「コンテキスト」、つまりAIが一度に読み込める情報の量です。ユーザーの指示、現在のコード、関連ファイル、利用可能なツールの説明。これらすべてがコンテキストウィンドウという上限の中に収まる必要があります。
問題になるのが外部ツールとの連携です。Claude Codeが外部APIやサービスと連携するためのMCPサーバーを有効にすると、そのツールの使い方を説明する文章がコンテキストを圧迫します。ある開発者の報告では、13個のMCPサーバーを有効にしただけで、最初の指示を出す前に82,000トークン、コンテキストウィンドウの約41%が消費されていたそうです [^13]。
この状態で/batchを使い数十のSubagentを起動すると、AIが実際に思考に使える領域が極端に狭くなり、パフォーマンス低下や予期せぬエラーの原因になり得ます。
対策は2つ。まず、/batch実行時はタスクに不要なMCPサーバーを一時的に無効にすること。もう一つは、Anthropic社が導入した「Tool Search」機能の恩恵を受けること [^14]。ツール定義がコンテキストの10%を超えると、すべてのツール説明を読み込む代わりにAIが必要なツールを検索する仕組みに自動で切り替わります。ただし、サーバー数が多いほどオーバーヘッドは増える傾向にあるので、絞り込みは意識したほうがいいでしょう。
git worktreeの後片付け
/batchやclaude --worktreeが作成するworktreeは、セッション終了時にクリーンアップされます [^8]。挙動を理解しておくと安心です。
変更がなかった場合、worktreeとブランチは自動削除されます。変更やコミットがある場合は「保持するか削除するか」の確認が表示されます。「削除」を選ぶとコミットしていない変更はすべて失われるので注意してください。
worktreeはプロジェクトルートの.claude/worktrees/に作られるため、.gitignoreに追加しておかないとgit statusで未追跡ファイルとして大量に表示されます。以下の一行を追加しておくのがおすすめです。
.claude/worktrees/
セッション履歴の管理
worktreeを削除すると、その中で行われたClaude Codeのセッション履歴も一緒に消えます。「あの時AIとどんなやり取りをしたか」を後から振り返れなくなるので、複雑な修正や意思決定の過程が含まれるセッションは保持しておくか、別途記録しておくのが賢明です。
初期バグと回避策（修正済み）
余談ですが、worktreeサポートのリリース直後、--worktreeフラグを指定していないのにClaude Codeが勝手にworktreeを作成するバグが報告されました [^7]。Boris氏がすぐに修正し、一時的な回避策として/permissionsでEnterWorktreeをdenyリストに追加する方法も示しています。現在は修正済みですが、ツールが意図しない挙動を見せた時に/permissionsで権限設定を確認できる、という知識は覚えておいて損はないでしょう。
v2.1.63のその他の変更点
/simplifyと/batchの影に隠れがちですが、v2.1.63には地味ながら開発体験を確実に改善する変更が含まれています [^1]。
HTTPフックが追加され、シェルスクリプトを介さずにURLへ直接HTTP POSTを送れるようになりました。CI/CDパイプラインのトリガーやSlack通知との連携がスクリプト不要になります。
git worktree間でProject configsとauto memoryが共有されるようになったのも見逃せません。これは/batchの基盤技術そのもので、worktree間でCLAUDE.mdの設定が引き継がれるようになっています。各Subagentがプロジェクトの規約を正しく理解した状態で作業できるのは、この仕組みがあるからです。
ENABLE_CLAUDEAI_MCP_SERVERS=falseという環境変数も追加され、claude.ai経由のMCPサーバーをオプトアウトできるようになりました。前章で触れたコンテキストウィンドウの消費問題を考えると、不要なMCPサーバーを明示的に無効化できるこの機能は実用的です。
/modelコマンドも改善され、スラッシュコマンドメニューに現在アクティブなモデル名が表示されるようになりました。意図しないモデルで作業してしまうミスを防げます。
長時間セッションの安定性も向上しています。Gitルートディレクトリ検出やJSON解析、設定メニューなど基本的な部分のメモリリークが複数修正されました。一日中Claude Codeを起動し続けるようなヘビーユーザーには嬉しい改善です。
/clearコマンドの挙動も修正され、会話履歴をクリアした際にキャッシュされた古いSkillが残るバグが解消されました。クリーンな状態で新しいタスクを始められます。
まとめ: あなたの開発は、今日から「チーム戦」になる
/simplifyと/batchがもたらす変化は、単なる作業の自動化ではありません。開発者とAIの関係が「指示者と実行者」の一対一から、「マネージャーと専門家チーム」の一対多に変わる。ワークフローが「指示を出して待つ」から「計画を承認してチームが動く」に変わる。
正直なところ、すべてのタスクがAIに置き換わるとは思っていません。ただ、コードレビュー前の品質チェックや大規模な定型作業がAIチームに任せられるようになることで、私たち人間は本当に頭を使うべき仕事に集中できるようになります。これは大きい。
最後に、今日からできることを5つ挙げておきます。
claude updateでv2.1.63にアップデートする- 次のPRで
/simplifyを試す。コード変更の指示にthen run /simplifyと付け加えるだけ - 簡単な一括変更で
/batchの感触を掴む。フレームワーク移行でなくても、lint修正やコメント修正で十分 - チームの規約を
CLAUDE.mdにまとめる。/simplifyがCLAUDE.md準拠をチェックするので、書いておくだけで効果が倍増する isolation: worktreeでカスタムエージェントを作ってみる。自分のプロジェクト固有のbatchワークフローを設計する第一歩になる
一人の開発者が、AIエージェントチームを率いてプロダクトを生み出していく。そんな時代がもう始まっています。
TIMEWELLでは、こうした最新のAI開発ツールを実務でどう活用するかを体系的に学べる「WARP」プログラムを提供しています。Claude Codeのようなエージェント型ツールを使いこなし、チーム全体の開発生産性を引き上げたいとお考えの方は、まずはお気軽にご相談ください。
参考文献
[^1]: Claude Code v2.1.63 Release Notes. (2026, February 28). GitHub. https://github.com/anthropics/claude-code/releases/tag/v2.1.63
[^2]: Claude Code Docs. Claude Code. https://code.claude.com/docs/en
[^3]: Common workflows. Claude Code Docs. https://code.claude.com/docs/en/common-workflows
[^4]: Cherny, B. (2025, December). In the last 30 days, I've landed 259 PRs... X. https://x.com/bcherny/
[^5]: Cherny, B. (2026, February). The head of Claude Code on how AI is changing software development. Lenny's Podcast. https://www.lennysnewsletter.com/p/head-of-claude-code-on-how-ai-is-changing-software-development-boris-cherny
[^6]: Waydev. (2026, February). 8 Game-Changing Insights from Anthropic's Head of Claude Code, Boris Cherny. https://waydev.co/8-game-changing-insights-from-anthropic-claudecode-boris-cherny/
[^7]: Cherny, B. (2026, February 21). Introducing built-in git worktree support for Claude Code... Threads. https://www.threads.net/@boris_cherny/post/DVAAnexgRUj/
[^8]: Run parallel Claude Code sessions with Git worktrees. Claude Code Docs. https://code.claude.com/docs/en/common-workflows#run-parallel-claude-code-sessions-with-git-worktrees
[^9]: Njenga, J. (2026, February). How I'm Using Claude Code (New) /simplify and /batch (To x10 My Code Reviews). Medium. https://medium.com/@joe.njenga/how-im-using-claude-code-new-simplify-batch-to-x10-my-code-reviews-888780a6a42a
[^10]: Cherny, B. (2026, February 28). In the next version of Claude Code, we're introducing two new skills... Threads. https://www.threads.net/@boris_cherny/post/DVR-HzBkqRd/
[^11]: Store instructions and memories. Claude Code Docs. https://code.claude.com/docs/en/store-instructions-and-memories
[^12]: Dramatic_Squash_3502. (2026, February). What's new in CC 2.1.63 system prompts (+4,200 tokens). Reddit. https://www.reddit.com/r/ClaudeAI/comments/1rh7lk8/whats_new_in_cc_2163_system_prompts_4200_tokens/
[^13]: Reddit community discussion on MCP context window consumption. (2026, February). Reddit r/ClaudeAI.
[^14]: Extend Claude Code - Tool Search. Claude Code Docs. https://code.claude.com/docs/en/extend-claude-code