Claude Code開発を支える私のツールチェイン — ターミナルからAIデザインまで
Claude Codeを日常的に使って開発していると、Claude Code単体ではなく周辺ツールの組み合わせが生産性を大きく左右することに気づく。ターミナルの選定、セッション管理、並列開発の仕組み、通知の設定——これらを丁寧に整えることで、AIとの協働はまるで別物になる。
この記事では、私が実際にClaude Code開発で使っているツールチェインを、ターミナル環境からAIデザインツールまで一気通貫で紹介する。
紹介するツール一覧:
- WezTerm(ターミナルエミュレーター)
- Tmux(ターミナルマルチプレクサ)
- GTR(Git Worktree Runner)
- Baton(自作セッション管理TUI)
- fzf + ghq(プロジェクト検索・管理)
- Claude Codeステータスライン / 通知フック
- Context7 / Notion MCP / claude-mem
- Aqua Voice(音声入力)
- Pencil(AIデザインツール)
ターミナル環境:WezTerm + Tmux
なぜWezTermを選んだのか
Claude Code CLIを使うなら、まずターミナルエミュレーターの選定が出発点になる。macOSで選択肢に挙がるのはiTerm2、Ghostty、WezTermあたりだろう。
私がWezTermを選んだ最大の理由はLuaで設定ファイルを記述できる点にある。単なるYAMLやTOMLの静的設定ではなく、プログラミング言語で動的にキーバインド・外観・イベントハンドリングを定義できる。Claude Codeの起動スクリプトをWezTermの設定ファイルに組み込んだり、セッション情報に応じてタブのタイトルを動的に変更したりといった柔軟なカスタマイズが可能である。
Ghosttyも高速なGPUレンダリングで注目されているが、カスタマイズの自由度という点ではWezTermに軍配が上がる。
Tmux導入の経緯
もともとWezTerm単体で開発していた。しかし、Claude Codeを日常的に使う中でTmuxを間に挟む構成に移行した。きっかけの一つは、Claude CodeのAgent Teams機能である。Agent TeamsにはTmuxセッション上でサブエージェントの会話内容をリアルタイム表示するオプションがあり、これを使いたかったことが導入のきっかけになった。
Tmuxは導入難易度が高いと敬遠されがちだが、Claude Code開発においてはその恩恵が非常に大きい。
WezTermとTmuxの役割分担
現在、WezTermとTmuxの責務は明確に分離している。
| レイヤー | 責務 |
|---|---|
| WezTerm | GUIレンダリング(フォント、カラースキーム、外観) |
| Tmux | セッション管理、タブ/ペイン分割、ペイン間移動 |
起動フローは以下の通りである。
- WezTermを起動
- WezTermの設定ファイルからTmuxのベースセッションを自動起動
- プロジェクトごとにTmuxセッションを作成
- 各セッション内でClaude Code CLIを起動
一つのセッション内に複数のClaude Codeが立ち上がっていることもあれば、Codex CLIやGemini CLIが同居しているケースもある。
並列開発のためのCLIツール群
Claude Codeを並列で稼働させると、複数のAIが同じファイルを編集しようとして競合が発生する。これを解決する手段として、Git Worktreeを採用している。
GTR(Git Worktree Runner)
Gitのworktreeコマンドは冗長で、追加・削除のたびに長いパスを指定する必要がある。この煩雑さを解消するために導入したのが、CodeRabbitが提供する**GTR(Git Worktree Runner)**である。
GTRを使えば、ワークツリーの作成・削除・一覧表示がシンプルなコマンドで完結する。実際の運用フローは以下の通りである。
- GTRで新しいワークツリーを作成(ブランチ名を指定)
- そのワークツリーのディレクトリに移動
- Claude Codeを起動して機能開発を開始
これにより、メインブランチを汚さずに複数の機能を並行して開発できる。
Baton — 自作のClaude Codeセッション管理TUI

Claude Codeを複数並列で動かしていると、「どのセッションが今どういう状態なのか」を把握するのが難しくなる。承認待ちなのか、実行中なのか、待機中なのか——セッションが増えるほど管理しきれなくなる。
この課題を解決するためにいくつかの既存ツールを試した。Claude Squad、Claude Tmux、CC Managerなど、OSSのセッション管理ツールは複数存在する。しかし、自分のワークフローにフィットするものが見つからなかったため、BatonというTUIツールを自作した。
Batonの特徴は以下の通りである。
- Tmux依存: Tmux上のペイン単位でClaude Codeセッションを管理する
- ステータス取得: 各ペイン内のClaude Codeの状態(承認待ち/実行中/待機中)をリアルタイムで取得
- TUI表示: ステータスごとに色分けして一覧表示
Batonの画面から「今このセッションが承認待ちだ」と判断したら、そのセッションに移動して内容を確認し、承認または否認を行う。これにより、並列開発中のClaude Codeを一元管理できるようになった。
batonはGitHubで公開している。
fzf + ghq — プロジェクトの爆速切り替え
プロジェクト間の移動にいちいちcdコマンドやTmuxコマンドを打つのは非効率である。ここで活躍するのがfzf(ファジーファインダー)とghq(リポジトリ管理ツール)の組み合わせである。
ghqは、git cloneしたリポジトリを一元管理するツールである。ghq getでクローンすると、~/ghq/github.com/{user}/{repo}/のような統一的なディレクトリ構造に配置される。全リポジトリが一箇所に集約されるため、検索性が格段に上がる。
fzfは、あいまい検索で候補を絞り込むインタラクティブなフィルタである。単体でも強力だが、ghqと組み合わせることで真価を発揮する。
私はTmuxのキーバインドに以下の2つのショートカットを設定している。
| キーバインド | 動作 |
|---|---|
prefix + f |
ghq配下のリポジトリをfzfで検索し、新規Tmuxセッションを作成 |
prefix + s |
既存のTmuxセッション一覧をfzfで表示し、選択したセッションに切り替え |
これにより、プロジェクトの新規立ち上げも切り替えもキーバインド一発で完了する。
Claude Codeのカスタマイズ
ステータスライン

Claude Codeの入力欄の下にはステータスラインと呼ばれる領域があり、シェルスクリプトでカスタマイズできる。Claude CodeがJSON形式で情報を返してくるため、その内容をパースして表示する仕組みである。
私が表示している情報は以下の通りである。
| 項目 | 目的 |
|---|---|
| プロジェクト名 | 今どのプロジェクトで作業しているか |
| ブランチ名 | 現在のGitブランチ |
| プロセスID | サブエージェント監視でセッションを特定するため |
| 使用モデル | 現在のセッションで使われているモデル |
| 使用状況(%) | 5時間制限に対する現在の消費率 |
特に使用状況の表示は重要である。Claude Codeには5時間制限や週間制限があるため、「あとどれくらい使えるか」を常に把握しておきたい。
この使用状況は、v2.80以前は非公式の内部APIを叩いて取得する必要があった。利用規約への抵触が懸念される方法だったが、v2.80で公式にJSONとして提供されるようになった。現在は堂々と公式の手段でステータスラインに表示できる。
通知フック
Claude Codeが「タスク完了」「承認待ち」「エラー発生」といった状態変化を起こしたとき、OSの通知を飛ばす仕組みをフックで構築している。
ポイントは通知音の分類である。
| 状態 | 通知音 |
|---|---|
| 承認待ち | 専用の音A |
| タスク完了 | 専用の音B |
| エラー/失敗 | 専用の音C |
音を聞くだけでClaude Codeの状態がわかるため、並列で複数のセッションを動かしているときでも、すぐに適切なセッションに反応できる。
MCP・プラグイン
MCPの運用方針:グローバルに設定しない
MCPは便利だが、グローバルに設定すると毎セッションでそのMCPのコンテキストが消費され、コンテキストウィンドウを圧迫する。コンテキストウィンドウはClaude Codeの生命線であるため、何でもかんでもMCPを追加するのではなく、プロジェクトごとに必要なMCPだけを設定する方針で運用している。
Context7 — 最新ドキュメント参照
Context7は、フレームワークやライブラリの最新ドキュメントをClaude Codeに提供するMCPサーバーである。
例えば「Next.jsの最新のApp Routerの書き方で実装して」と指示すると、Context7が最新のドキュメントを参照した上で、トレーニングデータのカットオフに依存しない正確な実装を行ってくれる。フレームワークの更新が速い領域では特に重宝する。
Notion MCP
私はNotionでナレッジやタスクを管理しているため、Notion MCPは頻繁に使う。Claude Codeから直接Notionのページを読み書きできるため、「Notionのタスクボードを更新して」といった指示がシームレスに通る。
claude-mem — セッションを超えた記憶
Claude Codeは基本的に1セッション1記憶である。セッションを閉じれば、それまでのやり取りは失われる。公式のAuto Memory機能で簡単なメモは残せるようになったが、詳細な会話の文脈までは保持されない。
claude-memはこの課題を解決するプラグインである。会話の内容や設計判断をSQLiteに保存し、別のセッションから過去の情報を検索・参照できるようにする。「先週あの機能をどう設計したか」を遡れるのは、継続的な開発において非常に有用である。
音声入力とAIデザイン
Aqua Voice — 音声でClaude Codeと対話する
AIとのやり取りで最もボトルネックになるのは、人間側の入力速度である。この記事の下書きもそうだが、私はClaude Codeへの指示をAqua Voiceで音声入力している。
要件定義、実装方針の説明、ブログの下書き——すべてを声で話し、Claude Codeに処理させる。手で打つよりも圧倒的に速く、思考を途切れさせずにAIに伝達できる。
Pencil — AIと一緒にデザインを作る
非デザイナーにとって、UIデザインは大きなハードルである。Pencilはこの課題に対する現時点での有力な回答の一つである。
Pencilを起動するとMCPサーバーが立ち上がり、Claude Codeと連携できるようになる。Claude Codeに「ログイン画面をデザインして」と指示すると、Pencil上にデザインが自動生成される。さらに、そのデザインをもとにClaude Codeで実際のページを実装させることもできる。
Pencilの強みは以下の3点である。
- MCP連携: Claude Codeから直接デザインを操作できる
- 手動編集: Figmaのように手動で微調整も可能
- Git管理: 生成されるファイルをGitで管理できる
AIに任せきりではなく、気になる箇所は手で直せる。この「AIと人間の協働」の塩梅が丁度良い。
今後注目しているツール:Google Stitch
Googleが提供するAIデザインツールStitchも注目している。調査した限りでは、デザインの精度や表現力はPencilよりStitchの方が優れている印象を受けた。
今後の運用フローとしては、Stitchで大まかなデザインを決め、Pencilに取り込んで微調整するという二段構えのワークフローを試していきたい。
まとめ
私のClaude Code開発環境のツールチェイン全体像を整理する。
[WezTerm] ← GUIレンダリング
└─ [Tmux] ← セッション管理
├─ [Claude Code] ← AI対話
│ ├─ ステータスライン(使用状況/モデル/PID)
│ ├─ 通知フック(音で状態判別)
│ ├─ MCP: Context7 / Notion MCP
│ └─ プラグイン: claude-mem
├─ [Codex CLI / Gemini CLI]
└─ [Baton] ← セッション一元管理TUI
[GTR] ← Git Worktree管理(並列開発)
[fzf + ghq] ← プロジェクト検索・切り替え
[Aqua Voice] ← 音声入力
[Pencil] ← AIデザイン(MCP連携)
各ツールは単体でも便利だが、組み合わせることで相乗効果が生まれる。WezTerm + Tmuxでセッション基盤を固め、GTR + Batonで並列開発を管理し、fzf + ghqで移動を高速化する。Claude Code側はステータスラインと通知フックで状態を可視化し、MCPとプラグインで能力を拡張する。そして、入力はAqua Voiceで高速化し、デザインはPencilに任せる。
Claude Codeの真価は、こうした周辺ツールとの組み合わせで発揮される。気になるツールがあれば、ぜひ試してみてほしい。
Comments