連載「AIがブン回る環境づくり！」第1部です。AIエージェントを速く動かす前に、チームの作業場をどう設計するかを全5回で整理します。
この第1部では、AI駆動開発を「モデル選び」ではなく「作業場づくり」から捉え、第5部までの道筋を先に置きます。
Codexのようなコーディングエージェントは、コードを読み、変更し、テストし、レビューに近い作業まで進められます。一方で、チーム固有の設計判断、品質基準、禁止事項、完了条件は最初から知りません。そこを毎回の会話で補うと、AI活用は説明した人の記憶と直前の文脈に依存します。
AIを開発体制に組み込むなら、問いは「どう指示すれば速く書けるか」だけでは足りません。「文脈ゼロで入ってくる優秀な新人が、初日から迷わず動ける作業場になっているか」を先に見る必要があります。
この連載で扱う5つの話
連載「AIがブン回る環境づくり！」は、AIを単発の便利ツールではなく、チームの開発基盤に組み込むための道筋です。
- 第1部では、AI駆動開発に必要な全体像を置きます。SSoT、開発ワークフロー、エージェントハーネス、ループエンジニアリングが直列につながると、AIの速さを再現可能な成果へ変えやすくなります。
- 第2部では、AIが迷わないSSoTとガバナンスを扱います。正典の置き場、入口、守る強さ、権限設計を分けて考えます。
- 第3部では、AIの速さを受け止める開発ワークフローを扱います。worktree、責務境界、品質ゲートで、並列作業をレビュー可能な差分にします。
- 第4部では、SSoTとワークフローをAIが実行できるエージェントハーネスへ変えます。Skills、Commands、役割分担、自走ループをつなげます。
- 第5部では、センシングとループエンジニアリングを扱います。エラー、要望、利用データ、ワークフローイベントを拾い、期待値との差を閉じ続ける構造を見ます。
AIの速さは、土台がないと手戻りを増やす
AIエージェントが速く動けるほど、間違った前提で進む距離も伸びます。
たとえば、設計方針がチャットの中にだけある状態を考えます。1回目の作業では、人間が丁寧に説明すれば動きます。しかし別のタスクでは同じ説明が必要になり、説明を省くと、AIは近くのコード例や一般論から推測します。推測が方針と合っていれば進みますが、外れていればレビューで戻ります。
このとき起きているのは、AIの能力不足だけではありません。判断に必要な文脈が、作業可能な形で置かれていないことが問題です。人間の新人でも、オンボーディング資料、レビュー基準、完了条件がなければ手戻りは増えます。
成果を増やすには、摩擦をレビューの最後に集めないことが重要です。作業前のルール、作業中の構造、作業後の品質ゲートへ摩擦を分散させると、AIの速さは手戻りではなくスループットへ変わります。
3本柱は、直列につながってはじめて効く
AI駆動開発の作業場は、3本柱と改善ループで考えると整理しやすくなります。
1つ目はSSoTです。設計方針、作業手順、品質ゲート、禁止事項について「正はここ」と言える場所を決めます。AIに毎回説明するのではなく、作業場の側に前提を置くための土台です。
2つ目は開発ワークフローです。タスクごとに作業領域を分け、コードの責務を分け、完了前に通すゲートを決めます。AIエージェントが複数タスクを進めても、未完成変更が混ざらず、レビュー可能な差分として扱えるようにします。
3つ目はエージェントハーネスです。SSoTとワークフローを、AIが実行できる手順へ翻訳します。タスク開始、調査、計画、実装、検証、レビュー、PR作成までを、再利用できる流れにします。
この3本柱の上に、センシングとループが乗ります。エラー、バグチケット、顧客要望、性能劣化、利用データを拾い、現状と期待値の差として整理します。そのギャップをハーネスに渡すことで、AIは単発依頼を待つだけでなく、改善サイクルの中で動けるようになります。
最初に決めるのは、5つで十分
最初から大きな開発基盤を作る必要はありません。まずは、AIが迷いやすい入口を5つに絞って決めます。
1つ目は、AIエージェント向けの入口です。ここを読めば作業できる、という薄い索引を置きます。入口には詳細を詰め込まず、SSoTへの導線を置きます。
2つ目は、品質ゲートの順番です。整形、lint、型チェック、テスト、ビルドのように、安い確認から重い確認へ進めます。順番が決まっていれば、失敗時の戻り先も決まります。
3つ目は、作業領域の分け方です。タスクごとにブランチやworktreeを分け、統合用の場所を未完成変更から守ります。
4つ目は、止まる条件です。テストが落ちている、型が通らない、設計境界を越えている、秘密情報に触れそうになっている。こうした条件を、人間が後で気づくものではなく、作業中に止まるものにします。
5つ目は、ギャップの入口です。エラー報告、バグチケット、顧客要望、性能アラートを、期待値、現状、証拠、受け入れ条件へそろえます。AIは「何を直すか」だけでなく「何が満たされれば完了か」を扱いやすくなります。
Chabitは、AIを使う手前の構造から整える
AI駆動開発は、うまいプロンプトを個人が持つだけでは続きません。チームで再現するには、正しい情報の置き場、作業の分け方、検証の順番、改善ループを構造として持つ必要があります。
Chabitのテクニカルディレクションでは、CodexやClaude Codeの導入そのものよりも、開発に必要なドメイン知識、設計判断、レビュー観点をチームの共有資産にすることを重視します。AIエージェントを「便利な個人ツール」ではなく、開発体制の一部として扱えるようにするためです。
第2部からは、この全体像を一つずつ分解します。まずは、AIエージェントが最初に迷う「どこを正とするか」から見ていきます。
連載ナビ
- 第1部：AI駆動開発の全体像（この記事）
- 第2部：SSoTとガバナンス
- 第3部：開発ワークフロー
- 第4部：エージェントハーネス
- 第5部：ループエンジニアリング
関連サービス
- テクニカルディレクション: コーディングエージェントを個人利用からチームの開発体制へ移すため、知識体系、運用ルール、品質ゲートの設計を支援します。
- AI Agent開発: 業務データ、判断基準、外部ツール連携を整理し、実務で動くAI Agentの設計と実装を支援します。
