クレオ・コードで生産的に作業する方法

タノに入社してから約6週間が経過し、私のコミット履歴は次のようになっています。

コミット数は成果を測るには極端な指標ですが、最も目立つサインです。実際に作業方法が変わったことが、コミットカウントという副産物として現れています。

何が変わったのか？

手間仕事の自動化

入社当初は、プルリクエストを手動で全て行っていました。変更をステージングし、コミットメッセージを書き、PR の説明文を作成してプッシュし、GitHub 上に PR を作る――それが標準的なフローでした。最初はうまくいったものの、後になってこの作業が「グラントワーク（苦しい手間）」であることに気づきました。従来はそのままやっていたので疑問を抱かなかっただけです。

最初の大きな変化は、「実装者ではなく、実装を行うエージェントのマネージャーになる」という点でした。マネージャーはチームの手間仕事を自動化します。

そこで私が作った Claude Code スキル

/git-pr

は、以前にやっていた全ての操作を自動で実行しつつ、さらに上質に仕上げます。PR の説明文は差分全体を読み取り、変更点を適切に要約するため、より詳細になります。時間の節約だけではなく、精神的なオーバーヘッドが消えることが本当の利点です。以前は PR を作るたびに小さなコンテキストスイッチ（コードから説明へ移行）が必要でしたが、今では

/git-pr

と入力するだけで次のタスクへ進めます。

待ち時間の排除

変更をレビューするとき、以下の煩わしいループに陥っていました。

1. 変更をローカルでプレビュー
2. 現在作業中のコードを離れる
3. 開発サーバーを停止
4. 新しいブランチで再起動
5. 全てが正常に動くか確認

サーバーのビルドには約1分かかり、コンテキストスイッチ時に集中力を破綻させるほど長い時間でした。

そこでビルドエンジンを SWC に変更し、サーバー再起動時間を 1 秒未満に短縮しました。これで「流れ」を途切れることなく保てます。ファイルを保存するとすぐにサーバーが稼働し、プレビューを確認できる――これはぎこちない会話と自然なフローの違いです。

Claude に実際の挙動を見せる

それ以前は UI の変更をローカルでプレビューして目視でチェックし、それが期待通りか判断していました。これにより、すべての機能開発でボトルネックになっていたのです。

Chrome 拡張機能がクラッシュした後、Claude Code の「preview」機能を利用するようにしました。この機能はエージェントがプレビューを設定し、セッションデータを保持しながら UI が実際にどう見えるか確認できます。

ワークフローに組み込むと、変更は「エージェント自身が UI を検証した時点で完了」となります。つまり、検証作業を委譲できるようになり、最終レビューにのみ関与すればよく、エージェントは長時間自律的に作業しつつ、自分のミスも捕捉できます。この点が当時想像以上に重要でした。

すべてを並行化

高速なビルドと自動プレビューによって別の摩擦が明らかになりました。1 回に一つだけ作業することは快適ですが、他エージェントの PR をレビューするときは stash を使ったりブランチをチェックアウトしたり再ビルドやテストを行わなければならず、未コミットの変更が邪魔になりました。stash で退避し、戻ってきてから pop する手順も面倒でした。

アプリはフロントエンドとバックエンドそれぞれに専用ポートが必要です。ワークツリー間で環境変数を共有すると同じポートへバインドしようとして衝突します。
そこで「ワークツリーごとにユニークなポートレンジ」を割り当てる仕組みを構築しました。これにより、10 個のプレビューを同時実行できるようになりました。

結果として、2 つの並列ブランチで圧倒されていた状態から、5 つのワークツリーを同時に走らせることが可能になり、ワークフローは次のように変わります。複数のエージェントを別々のワークツリーで起動し、それぞれ異なる機能を構築します。UI が自分で検証できた時点で停止するので、レビューもスムーズになり設定や再ビルド、ポート競合といった面倒な作業は不要です。

重要なのはインフラ、AI ではない

私の役割は変わりました。以前は複雑な問題を解決し、完璧な UI を設計することに喜びを感じていましたが、その頻度は減り、むしろエージェントを効果的に動かすインフラ構築――10 人のチームマネージャーとしてではなく、一人開発者としてではなく―が楽しくなっています。良いマネージャーとは「自分の『チーム』が行った全ての仕事をクレジットできる」ことです。

これらは華やかな課題ではありません――配管作業のように見えます。しかし、配管こそがあなたがフロー状態にあるか環境と格闘しているかを決定します。

タノで私が行った最高レバレッジな仕事は、新機能を書いたことではなく、コミット数を少量から大量へ変えるインフラを作り上げたことです。

フローのサイクル

各段階で別々の摩擦が取り除かれました：

• /git-pr

  がフォーマッティングの摩擦を排除し、コード変更を見やすい PR に変換
• SWC が待ち時間の摩擦を解消し、変更から確認までの死線を短縮
• プレビューが検証作業の摩擦を減らし、即座に挙動を確認可能に
• ワークツリーシステムがコンテキストスイッチの摩擦を除去し、複数流れを衝突なく同時実行

一つの摩擦が消えると別の摩擦が浮き彫りになります。PR が楽になったらビルドに時間を取られていたことに気づき、ビルドが即座になると並列化できないことに気付く――制約理論の典型です。片方を修正するとシステムはすぐに次の課題を示します。

私の仕事の性質は変わりました。「コードを書いてくれるツールを使う」のではなく、タスクを起動し、エージェントがコードを書き、プレビューをチェックし、差分を読んでフィードバックやマージを行い、次のタスクへと連続する緊密なループに入ります。このフィードバックループは非常に短いため、注意力が漏れる余地はありません。

物事を作ること自体が別種の楽しさになりました――速さを上げるゲームです。どれだけ速くできるか？ ループが十分に緊密になると、エンジニアリングそのものが娯楽になります。