logo
Published on

Claude Code を活用した並列開発の取り組み

Authors

今更感もありますが、Claude Code の登場で開発タスクへの取り組み方が大きく変わったので、最近の取り組みをまとめておきます。

Claude Code はターミナルとの相性もよく、複数のタスクを互いに影響なく開発進めるというkともしやすくなったこともあり、最近は複数の実装タスクを並行して進めることが多いです。

開発環

ターミナルベースの環境を主軸に、以下のツールを組み合わせて使用しました。

- iTerm2 + tmux + neovim + Claude Code

- 補助的にVSCode

- git worktree / git hooksの活用

これまでエディタ（JetBrains/VSCodeなど）を主に使用していましたが、「複数タスクの並列進行」という目標を達成するためには、ターミナル上でタスクごとにプロセスを分離・管理する方が効率的だと判断し、現在は可能な限り iTerm2 + tmux で開発するようにしています。

何かコードを書きたい・修正したいような場合には Neovim を使っていて、大きなタスクなどの場合には VSCode を使用する、というようなやり方をとっています。

理想で言えば Neovim で完結させたいと思いつつ、 VSCode は拡張機能その他便利な部分も多いですし、単純に Neovim をそんなに使わなくなっていたこともあって整備が追いついていないのでタスクに応じて使い分けするようにしています。

git worktree 活用

これまで使用したことがなかったのですが、Claude Code を使うようになってからは git worktree を頻繁に使うようになりました。

並列で開発しているとどうしても相互に干渉してしまう問題があったり、全く別のタスクの場合にはブランチを分けたいという問題がありました。

Anthoropic の公式サイトでも推奨していますが、 git worktree を使って作業ツリーを分割することでその辺りの問題も解決するのでほぼ毎日使用するようになりました。

使用していない worktree の削除なども簡単にできるように git worktree のコマンドはいくつか alias に登録して簡単に扱えるようにしています。

カスタムコマンドで作業の自動化

コーディングツールとしても Claude Code の優秀さを感じますが、個人的にはカスタムコマンドが非常に有益に感じています。

本職ではリード的なポジションでコードレビューや新規開発時の設計、アーキテクチャ周りの設計などコーディング以外にもさまざまやらせてもらっています。

上記作業はドメイン知識なども必要なので自分の頭で考えることも多い一方で、抜け漏れの確認であったり技術的な部分の調査は AI に代替できる部分も結構多いと考えています。

そうした部分はカスタムコマンドを作成して、可能な限りライトに AI に処理させられるようにしていっています。

例えばレビューであれば考慮しておきたい事項やレビュー手順、レビュー結果の報告フォーマットを渡しておいて、実行するだけである程度のレビューを手元で終わらせるようにしています。

GitHub と連携させてレビューさせることもできますが、コード動かしながら・見ながらのレビューも多かったり、個人的に見ておきたい観点などもあるので手元でも動かすようにしています。

あとは自分が PR 作る時のディスクリプションを指定のフォーマットにしたがって作成させるものであったり、指定のファイルのユニットテスト書かせるもの、ライブラリのアップデート内容の調査用のものなど、数回使いそうなものであれば結構なんでも作っておくようにしてます。

これを作るのも Claude Code でやらせているので、このあたりはバンバンやっていますね。

やれることも結構柔軟で、ビジネスサイドの人もカスタムコマンド活用すれば結構効果期待できると思っているので、社内でテックよりの方に推進してみたいと思っています。

ボトルネックは「人」

大きめの機能開発を並列で動かしたり、コードレビューやライブラリのアップデートといった細かなタスクも並列に動かしてきましたが、「並列開発」というアプローチは非常に有効だと思います。

AIに作業を任せている間の待ち時間を別のタスクに充てることで、時間的なロスが大幅に削減されます。工数が単純にN倍になるわけではありませんが、「じっくり考えるべきタスク」と「AIに任せて進められるタスク」を同時に回すことで、開発全体のスピード感を飛躍的に高めることができそうです。

一方で、並列開発の可能性は感じつつ、**「自分がボトルネック」**になるという問題への対処が必要だと感じています。

実装は AI に任せられる部分が多くなっていますが、レビューや仕様周りで人が介入する必要がある部分はまだ多いです。

そこでタスクが滞留してスピードが低下してしまうとか、コンテキストスイッチの問題などで人間側がボトルネック化しています。

こうした作業も可能な限り手離れできるようにしていく必要はあるんでしょうが、まだまだ手探り中です。

今後の展望

  1. 「ボトルネック = 自分」の解消 タスクの消化スピードに自分自身のコンテキストスイッチが追いつかないという課題を解決することが急務です。特にレビュープロセスは依然として人手に頼る部分が大きいため、AIを活用したレビューの仕組み（例えば、コミットログを基にAIにレビュードキュメントを作成させるなど）を積極的に導入し、改善していく必要があります。

  2. エンジニアに求められる知識領域の拡大 AIに任せられる領域が増えるほど、エンジニア一人が担当する領域は拡大していきます。「AIがやってくれるから楽になる」のではなく、「AIのおかげで、より多くのことができるようになる」という認識を持つべきです。ソフトウェアエンジニアリングの普遍的な知識はもちろん、幅広い領域へのアンテナを張り、学び続ける姿勢がこれまで以上に重要になります。

  3. コンテナベースの開発手法の見直し 並列開発を進める中で、Dockerなどのコンテナ環境でポートが競合するといった問題も発生しました。git worktreeで切り替えたブランチごとに、スムーズに動作確認ができる環境の整備も今後の課題です。

  4. 体力の重要性 思考や判断といった人間が担うべき部分の重要性が増す中で、最終的には体力も重要な要素となります。AIが進化しても、資本である身体を維持し、高いパフォーマンスを発揮し続けるための自己管理が不可欠です。

まとめ

Claude Code の登場でコーディングエージェントはまた1つ壁を超えたような印象を持っています。

ただ今のスピードを考えると、2025年中にまだ驚くような進化がありそうな気はしますね。

間違いないこととして、ただコーディングするだけのソフトウェアエンジニアは必要なくなっていくと思います。

これからの AI の進化には可能な限り乗りつつ、今後のキャリアも見据えて自分がやりたいことがやれるように、いろいろと動き始めようなと考えています。

そうした取り組みの1つとして、細々でもブログの更新もやっていけるといいなーと思っています。

Discuss on Twitter • View on GitHub