はじめに
こんにちは、株式会社ACES でテックリードをしている福澤 (@fuku_tech) です！
前回の記事では、AI駆動開発の4フェーズモデルを紹介し、「人間が運転席に座り続ける限り、AIの稼働時間は人間に縛られる」という構造的な課題を提示しました。
この構造を変えるにはAIに運転席を譲る必要がありますが、それには人間のマインドセットの転換も不可欠であり、一朝一夕に実現できるものではありません。AIが自律的に動くためには、まず人間とAIの役割分担を整理しておく必要があります。つまり、「何をAIに任せ、どう動かすか」を事前に決めておくことが求められるのです。
今回はその役割分担の設計の話です。鍵になるのは、開発プロセスを細かく分解して、AIが実行できる単位に落とし込むことです。「プロセスの細分化」と「スラッシュコマンドへのマッピング」という2つの軸で、私たちがPhase 2をどう組み立てたかを解説します。
Phase 2のリキャップ
Phase 2（Hybrid Co-Driving）は、人間が運転席に座り、AIに実行を任せる分業モデルです。「何をするか（What）」と「出力の品質判断（Review）」は人間が担い、「どうやるか（How）」はAIに任せます。
この分業を成り立たせるために導入したのが「スラッシュコマンド」です。人間がこれまで手作業でやっていた繰り返し作業をコマンドとして定義し、AIに実行させます。たとえば「ブランチを切る」「コードレビューをする」「PRを作る」といった作業を、 /branch-create /code-review /pr-create のようなコマンドに対応させます。
人間はコマンドを選んで実行し、出力をレビューして次のコマンドを選ぶ。この繰り返しでPhase 2の開発フローが回ります。
プロセスを分解して、スラッシュコマンドを割り当てる
なぜサブプロセス単位まで分解するのか
Phase 2の核心は、業務プロセスを細分化し、各サブプロセスにスラッシュコマンドを対応させることです。（以降、スラッシュコマンドは単に「コマンド」と呼称します。）
「要件定義して」「設計して」のような大きな粒度でAIに投げても、期待通りの精度は出にくいと感じています。曖昧な指示はAIの出力を不安定にし、人間のレビューコストをかえって増やしてしまいます。サブプロセス単位まで分解して初めて「ここは人間が判断すべき」「ここはAIに任せられる」という線引きが明確になります。
実際に開発プロセスを分解すると、次のようなイメージになります。
なお、この考え方は開発に閉じたものではなく、汎用的に利用できます。業務プロセスを理解する→細分化する→AIに任せる領域を選定する→コマンド化（エージェント化）するという流れは、マーケティングやCS、リサーチなど他の領域にも横展開できます。この点は、2026/03/25公開予定の#6「1チームの実践を、組織の力に変える」で改めて取り上げます。
設計原則: 単一責任とUNIX哲学
コマンドを設計するうえで最も重要な原則は、「1つのコマンドに1つの責務だけを持たせる」ことです。小さなコマンドを組み合わせて大きな作業を実現するという、UNIX哲学に通じるパイプライン的な発想で設計します。
この原則を守らないと何が起きるか。複数の責務を1つのコマンドに詰め込むと、Context Confusion（コンテキストの混乱）やContext Rot（コンテキストの劣化）が発生し、後半の工程がスキップされたり、仕様と異なるコードが生成されたりと、品質が不安定になります。しかもどの指示がボトルネックなのか特定も困難です。責務ごとにコマンドを分割することで、この問題は解消されます。サイバーエージェント社のテックブログ*1でも同様の知見が報告されています。
具体的な手順
コマンドを整備するための手順は、以下のように整理できます。
- 既存の開発フローを棚卸しし、定型的に発生する作業を特定する
- 各作業を「入力→処理→出力」の形に分解する
- AIに実行させるコマンドとして定義する
- コマンドの精度を左右するガイドラインやルールを整備する
特に4のガイドライン整備は見落とされがちですが、コマンドの出力品質を安定させるうえで欠かせません。コーディングルール、命名規則、アーキテクチャの方針といったドキュメントが、AIが正確に動くための前提条件になります。私たちが具体的に何を整備したかは、後述の「なぜワークしたか」セクションで詳しく解説します。
コマンドの実例
私たちACES Meet開発チームでは、一例として以下のようなコマンドを運用しています。
| コマンド | 責務 |
|---|---|
/branch-create |
実装内容に基づいて新規ブランチを自動作成 |
/api-build |
対話的にAPIを実装 |
/code-scan |
変更差分に対するクイックレビュー |
/code-review |
各レイヤーに対する詳細なセルフレビュー |
/code-refactor |
レビュー指摘に基づくクイックフィックス |
/commit |
意味のある変更単位でのコミット自動生成 |
/pr-create |
PRタイトル・説明の自動生成とプッシュ |
/pr-comment |
PR上のポイント箇所にセルフコメントを付与 |
これらを表の上から順に実行することで、ブランチ作成からPRコメントまでの一連の開発フローが回ります。各コマンドが単一責任を持っているため、問題が起きたときにどのステップが原因かすぐに特定できますし、特定のコマンドだけを差し替えたり改善したりすることも容易です。なお、/api-build や /commit のように、内部的に複数のコマンドをパイプしたオーケストレーションコマンドも混在しています。たとえば /commit は内部で /commit-stage と /commit-create がパイプされています。この発展形については次のセクションで説明します。
発展形: オーケストレーターコマンド
コマンドを使い込んでいくと、自然と「複数のコマンドを組み合わせた上位コマンド」が欲しくなります。たとえば、レビューからリファクタまでの反復ループを1つのコマンドにまとめるような発想です。
このオーケストレーターコマンドは、Phase 3への布石でもあります。Phase 2ではこの「組み合わせて回す」役割を人間が担っていますが、Phase 3では運転席自体をAIに譲ります。AIが自律的にプロセスを回し、人間は判断が必要な箇所にだけ介在する。そのために必要な探索ループ、判断停止の仕組み、ガードレールの設計思想を次回の記事にて解説します。
なぜワークしたか
すでにあった下地
Phase 2への移行がスムーズに進んだ背景には、もともとチームに備わっていた前提条件がありました。
開発プロセスが可視化・標準化されていたことで、全員が同一のフローで動けていたため、「どの作業を切り出してコマンド化するか」の議論が具体的に進められました。また、コーディングルールがすでに文書化されていたため、AIに渡すガイドラインの整備もゼロからではなく、既存資産をベースに拡張する形で進められました。
意図的に作った下地
一方で、AI駆動開発のために意図的に整備したものもあります。2025年12月の約1ヶ月間を準備期間とし、私が既存のプロセスを見直しながら以下の整備を進めました。2026年1月からチーム運用を開始し、現在も継続中です。
まず、ユビキタス言語の整備です。社内固有の概念や用語が一般的な意味と異なる場合、そのままプロンプトに入れてもAIが適切に解釈できないことがあります。プロダクト内の用語を整理し、AIが正確に理解できる状態を作りました。
次に、各種ガイドラインの整備です。コーディングルール、命名規則、アーキテクチャ方針、テスト方針といったドキュメントを、AIが参照できる形に整えました。これがコマンドの出力精度を左右する最も重要な要素です。ガイドラインが曖昧なままだと、チームで使ったときに出力の精度が安定しにくくなります。
なお、認証・認可やコアビジネスロジックといった人間が必ずレビューする領域の線引き（ガードレール）もガイドラインの一部として定めています。
これらのガイドラインをAIが必要なタイミングで参照できるよう、AGENTS.md と CLAUDE.md（プロジェクトルートに配置するAI向けの設定ファイル）で各ドキュメントの場所を示すようにしています。ポイントは、ファイルの中身を直接埋め込むのではなく、パスだけを記載している点です。たとえば、以下のようにドキュメントの場所を一覧で示しています。
## Quick Reference Refer to these resources proactively as needed during development. | What | Where | |------|-------| | **Product Overview** | `docs/guidelines/acesmeet-overview.md` | | **DB Design** | `docs/guidelines/db-design-guideline.md` | | **API Design** | `docs/guidelines/api-design-guideline.md` | | **Architecture** | `docs/guidelines/architecture-guideline.md` | | **Coding Style** | `docs/guidelines/coding-guideline.md` | | **Code Quality & Testing** | `docs/guidelines/code-quality-charter.md` | | **Error Handling Guideline** | `docs/guidelines/error-handling-guideline.md` | | **Ubiquitous Language** | `docs/glossary/ubiquitous-language.csv` |
こうすることで、AGENTS.md / CLAUDE.md 自体は目次のような役割に留まり、AIが必要なタイミングで必要なドキュメントだけを参照しにいく段階的開示の構造になります。セッション開始時にすべてをコンテキストに載せない設計にすることで、コンテキストの肥大化を防いでいます。
下地が成否を分ける
Phase 2の成否は、こうした「下地」で決まるというのが私たちの実感です。#1｜AI駆動開発の4フェーズと私たちの現在地でも述べたとおり、マインドセットの転換自体は小さいものの、チームとして再現性のある状態に持っていくには、この下地づくりが成否を分けます。人間がやっていることを言語化し、コマンドとして定義し、AIに実行させていく。やること自体はシンプルですが、下地の整備には相応の労力がかかります。私たちの場合、2025年12月の約1ヶ月を集中的な準備期間に充てました。ただ、下地を一気に整えたこととチームのモチベーションが高かったことで、その後の運用立ち上げは想像以上に速く、Phase 2からPhase 3の入口まで数ヶ月で到達できました。
一方で、ガイドラインが不十分なままチームで使い始めると、コマンドの出力精度は安定しにくくなります。Phase 2を機能させるうえで、下地の整備は欠かせないステップだと考えています。
Phase 2の限界
Phase 2の運用が回り始めると、別の課題が見えてきます。
毎回「コマンドを実行する→出力をレビューする→次のコマンドを選択する→実行する」という人間介在のループが発生します。各コマンドの実行自体はAIが担いますが、コマンド間の接続、つまり「今の出力は問題ないか」「次に何をすべきか」の判断は常に人間です。
人間が運転席に座り続ける限り、AIの稼働時間は人間の稼働時間に縛られる。これは#1で提示した構造問題そのものです。Phase 2はその問題を解消するものではなく、AIが動ける範囲を広げるための土台づくりでした。
次のステップは、「組み合わせて回す」役割自体をAIに委ねることです。AIが自律的にプロセスを回し、人間は判断が必要な箇所にだけ介在する。それがPhase 3の話です。
おわりに
Phase 2を始めるにあたって、まず試してみてほしいのは、自分のチームの開発フローを一度棚卸ししてみることです。「この作業は毎回同じ手順を踏んでいる」と気づいたら、それがコマンド化の候補です。小さく始めて、ガイドラインを育てながら広げていくのが現実的な進め方だと思います。
ただし、Phase 2を回していくと、「毎回人間がコマンドをつなぐループ」がボトルネックになることにも気づきます。次回の記事では、このループ自体をAIに委ねる「Pilot-Tower開発」の設計思想について解説します。
ACESでは現在、複数のエンジニアポジションで採用を行っています。本シリーズを読んでACESの開発に興味を持っていただけた方は、ぜひカジュアル面談でお話ししましょう！
ACESの採用情報はこちら↓
