こんにちは、Yuriです。
最近、普段使うエディターをZedへ乗り換えたり、AIエージェントとの開発の進め方を考えたりする中で、改めて自分の作業環境を見直してみました。
今回整理したかったのは、AIに何を任せ、自分はどこでコードを読み、どのタイミングで判断するのかということです。
Claude CodeとCodexを使うなら、それぞれの担当を決めたい。実装されたコードは、自分が読みやすいエディターで確認したい。ターミナルでも、今どのディレクトリとブランチにいるのかをすぐに把握したい。
こうした希望を整理して、AGI CockpitでAIの作業を管理し、Zedを自分がコードを読む・確認する場所として使う方針にしました。
この記事では、これから試していく開発の運用方針と、実際に設定したZedのターミナルについてまとめます。運用全体の効果はこれから確かめる段階ですが、まずは役割と作業場所を明確にするところから始めます。
AIと自分の担当を決める
今回の構成は、次の4つです。
| ツール | 今回の担当 |
|---|---|
| AGI Cockpit | AIエージェントへの依頼、タスクの切り替え、進捗確認 |
| Zed | 自分がコードや差分を読み、軽微な修正や動作確認をする場所 |
| Claude Code | 要件の整理、設計、実装後のレビュー |
| Codex | 設計に沿った実装、テスト、レビュー指摘の修正 |
この担当分けは、今回の自分の運用として決めたものです。それぞれのAIでできることを限定する意図はありません。
自分はTech Leadのような立場で、要件や設計の採否、変更範囲、最終的な品質を判断します。
たとえば設計の段階では、「今回の機能に対して複雑すぎないか」「既存の構成と合っているか」を確認する。実装後には、差分と動作を見て「依頼した内容になっているか」を確認する。AIのレビュー指摘についても、採用するかを自分で判断します。
AIへの依頼や進行管理はCockpitに集め、成果物を読む作業はZedに寄せる。この役割分担を、まずは試してみたいと考えています。
1つの機能を、同じ場所で順番に進める
複数のAIを使うときに、先に決めておきたかったのが作業場所です。
今回の基本ルールは、1機能につき1つのブランチ・1つの作業ディレクトリを使い、担当を順番に交代することにしました。
たとえば一覧画面に絞り込み機能を追加するなら、次の流れを想定しています。
- Claude Codeが既存コードを調べ、設計と受け入れ条件を整理する
- 自分が設計を読み、変更方針を確認する
- Codexが実装し、テストや必要な検証を行う
- 自分がZedで差分と動作を確認する
- Claude Codeが設計と実装を照合してレビューする
- Codexが採用した指摘を修正し、再度検証する
- 自分が最終確認し、コミットやPR、マージへ進める
この間、Claude CodeとCodexとZedは、同じ絶対パスのディレクトリを参照します。
機能: 一覧の絞り込み
ブランチ: feature/filter
作業場所: ~/work/project
Claude Code: 設計
↓ 自分が確認
Codex: 実装・テスト
↓ 自分が確認
Claude Code: レビュー
↓
Codex: 修正・再テスト
↓ 自分が最終確認
書き込みを行う担当は、常に1人または1エージェントにします。自分が少しだけ修正したい場合も、AIの編集が止まっている間に行う方針です。
レビュー工程では原則としてコードを変更せず、指摘を残して次の担当へ渡します。担当を交代するときは、前の処理が終わっていることと、現在のブランチ・未コミット差分を確認します。
worktreeは機能を分けたいときに使う
以前、Git worktreeでDocker開発しようとしてハマった話を書きました。そのときも、どのディレクトリのファイルを参照しているかが大事でした。
今回も、同じ機能を引き継ぐたびにAIごとのworktreeを作ると、作業場所の対応を管理する必要が増えます。まずは通常のcheckoutを使い、mainの作業場所と分けたい場合だけ、その機能用のworktreeを1つ用意する方針です。
同じ作業ディレクトリであれば、未コミットの変更も次の担当が読めます。節目のコミットは追跡のために残しつつ、AIへ担当を渡すたびにmergeやcherry-pickを挟む運用にはしません。
別の機能も同時に進めたくなったら、機能単位でworktreeを分ける。その場合も、1つの機能の中では同じ作業場所を共有します。
ファイルと一緒に、判断の経緯も引き継ぐ
同じファイルを読めても、前のAIとの会話まで自動的に伝わるわけではありません。
「どうしてこの設計にしたのか」「何を確認済みなのか」「どこがまだ終わっていないのか」は、別途伝える必要があります。
引き継ぎには、次の情報を残すことにしました。
- 目的と受け入れ条件
- 作業ディレクトリとブランチ
- 設計判断と変更対象
- 現在の差分や基準となるコミット
- 実行したテストと結果
- 未解決事項と次の担当への依頼
必要に応じて docs/feature-filter-handoff.md のようなメモにまとめ、次の担当に読むよう依頼します。
たとえば「実装できました」だけでは、次のレビューで何を基準にすればよいか分かりません。「空の検索結果を表示できること」「条件を解除すると全件に戻ること」といった受け入れ条件があれば、レビューの観点もそろえやすくなります。
最初は自分で工程を切り替え、引き継ぐ内容が安定してから自動化を検討したいと思っています。
Zedは、自分が読み続けられる環境にする
Zedで重視したいのは、コードを読む・追う・確かめる作業のしやすさです。
落ち着いたOne Dark系の配色を基準に、文字サイズやファイルツリー、検索、定義ジャンプ、Gitの差分表示を整える方針にしました。言語支援についても、普段触るVueなどのファイルで使い勝手を確認していきます。
ターミナルもZed内を起点にし、動作確認やGit操作を行います。そこで気になったのが、現在のパスやブランチをもっと見やすくしたいということでした。
最初の構成案ではプロンプトの候補にStarshipを挙げていましたが、実際に設定したのは zsh + Powerlevel10k + Nerd Font です。
ここからは、その設定で確認できた内容を残します。
ターミナルの状態表示と入力を2行に分ける
今回のターミナルは、次の構成です。
| 要素 | 役割 |
|---|---|
| Zed Terminal | 文字を表示し、入力を受け取る |
| zsh | コマンドを解釈・実行する |
| Powerlevel10k | パスやGit情報などのプロンプトを組み立てる |
| MesloLGS Nerd Font Mono | 文字とアイコンを描画する |
Powerlevel10kのウィザードでは、色付きのブロックで情報を分けるRainbowスタイルを選びました。
特に取り入れたかったのは、上段にパスやGit情報などの状態を表示し、下段にコマンドを入力する2行構成です。状態表示が横に長くなっても、入力を始める位置が分かりやすくなります。
主な選択は、次のとおりです。
| 項目 | 選択 |
|---|---|
| スタイル | Rainbow |
| 文字セット | Unicode |
| 時刻 | 24時間表記 |
| 区切り / 終端 | Angled / Sharp |
| 高さ | Two lines |
| 接続線 | Dotted、色はDark |
| 枠 | No frame |
| アイコン | Many icons |
| 補助語 | Concise |
ウィザードを開くコマンドは次のものです。
p10k configure
再設定する場合は、手動で調整した ~/.p10k.zsh の控えを残してから行います。
実行済みのプロンプトを短くするTransient Promptについては、過去の出力にもパスやブランチを残す方向で考えています。ただし、手元の記録では最終的な選択まで確認できないため、ここでは好みとして書いておきます。
アイコンが「?」になってしまった
設定でつまずいたのが、アイコンの表示でした。
Powerlineのdiamondは表示されるのに、Appleやフォルダ、ブランチ、時計のアイコンが「?」になってしまいました。
Nerd FontはHomebrewで追加していました。
brew install --cask font-meslo-lg-nerd-font
それでも表示されなかった原因は、Zedに指定していたフォント名と、macOSに登録されていたFamily名が一致していなかったことでした。
プロンプトを通さずにアイコンを表示する
切り分けでは、問題が起きているZedのターミナルで、次のコマンドを実行しました。
print -P '\uf179 \uf07c \uf126 \uf017'
Apple・フォルダ・ブランチ・時計の4つのアイコンを直接表示するテストです。
プロンプトの配置を介さずに文字を表示すると、プロンプト側の設定を調べる前に、そもそもその文字を描画できているか確認できます。
ここで学んだのが、diamondが表示されるだけでは、使いたいアイコンまで表示できるとは判断できないということでした。実際に表示できていない文字で確認する必要があります。
macOSに登録されている名前を調べる
フォント情報は、次のコマンドで確認しました。
system_profiler SPFontsDataType
今回の出力には、次の情報がありました。
Full Name: MesloLGS Nerd Font Mono Regular
Family: MesloLGS Nerd Font Mono
Valid: Yes
Enabled: Yes
フォントは存在し、有効になっていました。一方、Zed側では MesloLGS NF を指定していました。
そこで、Zedの settings.json にある既存の terminal 設定を、登録されたFamily名に合わせて更新しました。ベルの設定も含めると、次の形です。
{
"terminal": {
"font_family": "MesloLGS Nerd Font Mono"
}
}
保存後にZedを ⌘Q で完全終了し、再起動して新しいターミナルを開くと、アイコンが正常に表示されました。
このフォント名は今回の環境で確認できたものです。別の環境で設定する場合も、インストールしたフォントの登録情報を確認すると切り分けやすいと思います。
なお、途中で試した fc-list は、このMacでは command not found になりました。今回は追加でツールを導入せず、system_profiler で必要な情報を確認できました。
表示とプロンプトの設定を分けて考える
今回確認した ~/.p10k.zsh のアイコンモードは、次の値でした。
typeset -g POWERLEVEL9K_MODE=nerdfont-complete
これはPowerlevel10k側の設定で、Zedが使用するフォントの指定とは別です。
プロンプトの並びや装飾はPowerlevel10k、実際に描画するフォントはZed。この担当を分けて考えると、次に表示が崩れたときも確認する場所を絞れそうです。
必要になったものから追加していく
構成を考える中では、HermesやOrcaなども候補に挙がりました。ただ、今は自分で設計や差分を確認し、次の担当へ渡す運用から始めたいと考えています。
まずはCockpitとZedを使う方針に絞り、自動化をどこまで進めるかは、実際に引き継ぎを繰り返してから判断します。
ターミナルの補助ツールも同様です。Git操作を補いたくなったらlazygit、検索や移動に手間を感じたらfzfやzoxideなどを検討します。初期構成にすべてを入れる予定はありません。
今回、開発の進め方とターミナルの設定を一緒に見直してみて、どちらにも「今どこで、何をしているのか分かるようにしたい」という共通点があると感じました。
AIの作業では、担当・作業場所・引き継ぐ内容を明確にする。自分のターミナルでは、パスとブランチを見やすくする。
次は小さな1機能で、設計から実装、レビュー、修正までを一度通してみるつもりです。自分が判断しやすいか、引き継ぎに情報が足りているかを確かめながら、この環境を調整していきたいと思います。