人間が疲れないように AI を使うための3つのTips

みなさんこんにちは、最近 ChatGPT を自分の専属トレーニングコーチとして活用し始めました。よしざわです。

AI が開発環境を一新してから数ヶ月、みなさんも AI をガンガン活用して開発を進めていることと思います。私も普段、タスク整理から issue の概要調査、コードベース研究や実装、レビューなど様々なケースで AI を活用しています。

一方 AI は優秀ですが、あまりにも優秀なために頑張っていついていこうとすると人間の脳が疲れすぎてしまう欠点もあると考えています。
そこで今回は、私が AI を使うときに利用している、人間が疲れないように AI を使うための3つの Tips をご紹介したいと思います。

wtp で git worktree を活用する

AIを最大限活用するためには、メインの作業の裏で並行してAIを活用することが特に重要です。

PRのレビュー、別issueの対応プラン検討、リファクタリングプランの検討、プロジェクトの分析など様々あり、これらをメイン作業と並列して行うために git worktree を用いることは有名だと思います。

git worktreeの課題

しかし試してみると分かりますが、git worktreeは管理が面倒です。作業毎にディレクトリを移動したり、envファイルのコピー、開発サーバーの起動、パッケージインストールなど、細かい作業が伴います。

難しいわけではないけど面倒な作業というものは作業へ向かう心にダメージを与え、見えない疲労が少しずつ蓄積してしまいます。

wtpで解決する

そこで、wtpというgit worktreeの管理ツールがとても便利です。

wtpはgit worktreeの作成、削除、確認などの利用がとても簡単になるCLIツールです。あらかじめ設定ファイルにgit worktree作成時のコマンドを設定しておくことで、worktreeの作成、作業ディレクトリの移動、worktreeの削除までをシームレスに行えるようになります。

例えば作業中、差し込みでレビュータスクが降ってきた場合、wtp add -b [branch-name]コマンドで簡単に初期設定が完了したworktreeを作成できます。さらにwtp cd [branch-name]コマンドで対象のディレクトリに移動できます。

レビューの終了後は wtp remove [branch-name]で役割を終えたworktreeを削除できます。

詳しい使い方については作者様のブログ記事を参考にしてください。

Claude Codeとの連携

さらに claude skills にあらかじめ wtp コマンドの詳細情報を置いておくことで、 claude に https://github.com/xxx/xxxx/pull/1 をレビューしたいので、 git worktree を用意して欲しい のように指示を出す事で、claude が自動で branch 名を検索し、さらに簡単に git worktree を利用することができるようになります。

以下に私がプロジェクトに配置している claude skill ファイルを共有します。この skill を利用することで、 claude と対話的にシンプルに git worktree を管理することが可能になります。

.claude/skills/worktree-manager/SKILL.md

---
name: worktree-manager
description: git worktree を wtp コマンドで対話的に操作する。worktree の作成、削除、移動、一覧表示に対応。「worktree 作りたい」「ブランチ切り替えたい」「worktree 消したい」などの操作をサポート。
---

# wtp - Git Worktree Manager

wtp コマンドを使って git worktree を対話的に操作するスキル。

## 基本ワークフロー

1. `wtp list` で現在の worktree 一覧を取得
2. AskUserQuestion で操作を選択（作成/削除/移動）
3. 選択に応じてコマンドを実行

## wtp list の出力形式

```
PATH BRANCH                    STATUS  HEAD
---- ------                    ------  ----
@*   develp                    managed 75a8b18c
     feature/auth              managed abc1234d
     fix/bug-123               managed def5678e
```

- `@*`: メイン worktree（現在地）
- `@`: メイン worktree
- その他: 追加された worktree

## 操作別ワークフロー

### 作成 (add)

1. AskUserQuestion でブランチの種類を確認:
   - 新規ブランチを作成
   - 既存のリモートブランチから作成
2. ブランチ名を聞く
3. コマンド実行:

   ```bash
   # 新規ブランチ
   wtp add -b <branch-name>

   # 既存ブランチ
   wtp add <branch-name>
   ```

### 削除 (remove)

1. `wtp list` を実行して worktree 一覧を取得
2. 出力から BRANCH 列を抽出（`@*` のメインは除外）
3. AskUserQuestion で削除対象を選択肢として提示:
   ```
   例: feature/auth, fix/bug-123 などを選択肢に
   ```
4. AskUserQuestion でブランチも一緒に削除するか確認
5. コマンド実行:

   ```bash
   # worktree のみ削除
   wtp remove <branch-name>

   # worktree とブランチを削除
   wtp remove <branch-name> --with-branch
   ```

## コマンドリファレンス

| 操作          | コマンド                            | 説明                      |
| ------------- | ----------------------------------- | ------------------------- |
| 一覧          | `wtp list`                          | 全 worktree を表示        |
| 作成(新規)    | `wtp add -b <branch>`               | 新規ブランチで作成        |
| 作成(既存)    | `wtp add <branch>`                  | 既存ブランチで作成        |
| 削除          | `wtp remove <branch>`               | worktree を削除           |
| 削除+ブランチ | `wtp remove <branch> --with-branch` | worktree とブランチを削除 |

git worktree ごとにウィンドウを分ける

worktree を分けてうまく並列作業を行う話をしましたが、せっかく worktree を分けても、同じウィンドウ内でディレクトリを行き来していては、頭の中のコンテキストスイッチが頻繁に発生します。「今どのブランチにいるんだっけ？」「さっきどこまでやったっけ？」という確認作業が増え、認知コストが高くなってしまいます。

そこで、worktree ごとに物理的にウィンドウを分けることをおすすめします。
ウィンドウを物理的に分けることで、以下のようなメリットがあります。

• 視覚的な分離
  • ウィンドウを切り替えるだけで、作業内容も頭も切り替わる
• 状態の保持
  • 各ウィンドウがそれぞれの作業状態を保持してくれる
• 迷わない
  • 「このウィンドウは○○の作業用」と一目でわかる

同じウィンドウ内で cd を繰り返すのと、別ウィンドウに切り替えるのでは、心理的な負担がまったく違います。ウィンドウという物理的な境界があることで、作業の切り替えがスムーズになります。

実践のポイント

ターミナルアプリのタブやウィンドウ機能を活用することで、作業ごとにウィンドウを開き、それぞれで wtp cd [branch-name] してから Claude Code を起動することができます。

メインの開発、レビュー、調査など、それぞれが独立したウィンドウになっていれば、割り込みタスクが来ても元の作業にすぐ戻れます。

アスキーアート 図でプロジェクト概要を把握する

さらに AI 活用でも特にインパクトがある用途として、私は情報の整理が挙げられると考えています。例えばプロジェクト全体の構成についてだったり、とある機能の構成について、ロジックの処理順など、何がどうなって今の仕様になっているのか、従来であればきちんとコードを読み進めて解読する必要がありましたが、今は AI に頼めば一発で簡単にまとめてくれます。

そんな時に特に重宝するのが、アスキーアート図です。

アスキーアートとは文字や記号によって絵や図、キャラクターなどを表現する手法のことで、 AI はこちらが明示的に指示をすることなく利用することもありますが、レビューや issue の解読、コードリーディングなどさまざまなケースで明示的にアスキーアートを利用するように指示をすると、まずおおまかな概要を理解し、そこから深掘りしたい部分だけさらに詳細を尋ねるという使い方ができるようになります。

下の画像は今回のブログの構成についてアスキーアートで解説してもらった図になります。ところどころ壊れてしまってはいますが、十分理解できるレベルです。

これにより、自分が今本当に必要な情報だけに最小限の時間と労力でアクセスすることができるようになります。

まとめ

今後プロジェクトの中で成果を向上させるためには、 AI をどれだけ無理なく最大限活用できるかという観点が重要になります。

私は今回共有させていただいた Tips を身につけることで、自分が疲れずに AI を利用して成果を出すワークフローが手に馴染んできたと感じています。
ぜこの記事を読んでいただいた皆さんも、今回共有させていただいた Tips を試したり、改善したり、全く別のアプローチを研究してみてください。

その結果、自分が疲れにくく、それでいて最大限 AI を活用できる自分なりのワークフローが見つかrればうれしく思います。

Gaji-Labo フロントエンドエンジニア向けご案内資料