連載「AIがブン回る環境づくり！」第3部です。第2部で正典の置き場を決めたあと、ここではAIの速さを受け止める開発ワークフローを扱います。
私たちは、AIエージェントを開発体制に入れるほど、作業の分け方と完了条件が重要になると考えています。
AIエージェントは速く動けます。複数のタスクを同時に進めることもできます。しかし、作業領域が混ざり、責務境界が曖昧で、完了条件が人間の確認待ちになっていると、その速さは手戻りに変わります。
開発ワークフローは、AIの速さを安全に受け止めるレールです。横に分け、縦に薄くし、最後にゲートで確かめる。この3つを揃えると、AIの作業はレビュー可能な差分として扱いやすくなります。
第3部では、SSoTに置いた前提を実際の作業単位へ落とします。次の第4部では、このワークフローをAIが毎回たどれるように、Skills、Commands、役割分担を含むエージェントハーネスへ変換します。
横の分割で、未完成変更を混ぜない
横の分割とは、タスクごとに作業領域を分けることです。
Git worktreeは、一つのGitリポジトリから複数のworking treeを作り、複数ブランチを同時にチェックアウトできる仕組みです。AI駆動開発では、タスクAは作業領域A、タスクBは作業領域Bに閉じ込めるために使えます。
この分割で得られる効果は2つあります。1つ目は、未完成変更が統合用の場所に混ざりにくいことです。2つ目は、複数タスクを並列で進めても、衝突を局所化できることです。
ただし、作業領域を分けるだけでは足りません。Issueやタスク管理で、着手中、レビュー中、完了といった状態も必要です。状態がなければ、別々のAIエージェントが同じタスクを進めることがあります。
横の分割は、AIの速度を並列性に変える仕組みです。ここがないと、速度は作業衝突へ変わります。
縦の分割で、変更の影響範囲を薄くする
縦の分割とは、コードの責務を層で分けることです。
AIエージェントは近くの実装に引っ張られます。画面、API、DB、ビジネスルールが一つの場所で混ざっていると、AIは「どこに何を置くべきか」を推測し続けます。結果として、仕様変更と都合上の変更が混ざり、レビューの負荷が上がります。
責務境界があるコードでは、変更の置き場が決まります。ビジネスルールは内側、外部サービスとの接続はadapter、結線はcomposition、画面はpresentationのように、層名はチームごとに違っても構いません。大切なのは、依存方向と責務の置き場が説明できることです。
portとadapterの考え方も、AI駆動開発では実務的です。ユースケースがportに依存し、DBや外部APIがadapterに閉じていれば、テストを軽くできます。本物の外部サービスを動かさなくても、小さなstubでビジネスルールを確かめられます。
軽いテストがあるほど、AIの推測距離は短くなります。間違った実装を長く進める前に、早い段階で止められるからです。
検証で、完了条件を人間の記憶から外す
横と縦で作業を分けたら、最後は検証です。
AIエージェントが「できました」と言ったとき、何をもって完了とするのかを決めます。私たちは、品質ゲートを安い順に並べることを推奨しています。整形、lint、型チェック、依存境界チェック、API契約チェック、テスト、ビルド、ドキュメントリンクチェックのように、軽い確認から重い確認へ進めます。
順番を固定する理由は、失敗時の戻り先を明確にするためです。型チェックが落ちているなら、テストへ進む前に直します。lintが落ちているなら、ビルドへ進む前に直します。最初に失敗した場所で止め、直し、そのゲートから再実行します。
この流れはAIにも人間にも効きます。AIは何を実行し、どこで止まり、何を直せばよいか判断しやすくなります。人間は「テストは通したのか」と聞く代わりに、標準ゲートの結果を確認できます。
検証はAIを疑うためだけのものではありません。AIが自分で正しさを確かめるためのレールです。
UI変更は、見て確かめた証拠を残す
フロントエンドやUIを含む変更では、テキストのゲートだけでは不足します。
見た目、レスポンシブ、アクセシビリティ、操作性は、コードだけでは判断しにくい領域です。AIエージェントがUIを変更する場合は、スクリーンショット、主要viewportでの確認、アクセシビリティ検査を証拠として残すとレビューしやすくなります。
ここで重要なのは、完璧な自動化ではありません。人間のレビュー前に、AIが自分で画面を見た状態を作ることです。画面が崩れていないか、主要な操作ができるか、フォーカスが当たるか、明らかなアクセシビリティ違反がないか。最低限の証拠があるだけで、レビューの会話は具体的になります。
UI変更は、AIが得意に見えて崩れやすい領域です。「作った」ではなく「見て確かめた」までをワークフローに含めます。
導入チェックリスト
AIエージェント向けの開発ワークフローを整えるときは、次の観点から確認します。
- タスクごとに作業領域を分けられるか
- 統合用の場所を未完成変更から守れるか
- Issueやタスクに状態管理があるか
- コードの責務境界を説明できるか
- 依存方向をルールとして説明できるか
- ユースケースを軽いstubでテストできるか
- 完了前に通す品質ゲートの順番があるか
- UI変更でスクリーンショットやアクセシビリティ確認を残せるか
このチェックリストはAIのためだけではありません。人間の開発にも効きます。安全に並行で作業し、変更を局所化し、完了条件を揃えることは、開発チーム全体の基礎体力になります。
連載ナビ
- 第1部：AI駆動開発の全体像
- 第2部：SSoTとガバナンス
- 第3部：開発ワークフロー（この記事）
- 第4部：エージェントハーネス
- 第5部：ループエンジニアリング
関連サービス
- テクニカルディレクション: worktree運用、品質ゲート、レビュー観点、UI確認フローを含め、AI前提の開発ワークフロー設計を支援します。
- AI Agent開発: 実務で動くAI Agentを、外部ツール連携、権限、人間の確認ポイントまで含めて設計します。
