こんにちは。ウォンテッドリーでバックエンドエンジニアをしている小室 (@nekorush14) です。少人数のチームで AI を日々の開発に組み込む中で、各自が見つけた便利な使い方をどうチームの動き方に変えるかが課題になりました。今回は、個人の使い方を配るのではなく、人が方針を立て AI が自律的に回る開発ループをどう設計し、チーム開発に組み込むかをお話しします。

はじめに

少人数のチームで各自が AI を使い始めると、便利な指示やプロンプトはその人の手元にとどまりがちです。多くの場合、これは便利なプロンプトを共有すれば解決する問題として捉えられます。

この場面では、CLAUDE.md にルールを書き足す、定例で使い方を共有するといった対応を取ります。一方で、プロンプトを配っても揃うのは各自の AI の使い方までで、チームとしての開発の進め方そのものは変わりません。

設計すべきなのは個人の使い方ではなく、人が方針を立て AI が自律的に回る開発ループそのものだと考えています。本稿では、AWS が公開する AI-DLC Workflowを題材に、その開発ループをどう設計してチーム開発に組み込むかを、4〜5 人のチームでの実践として共有します。

人が方針を立て AI が自律的に回る開発ループを設計する

この設計の狙いは、個人のプロンプトを揃えることではありません。人が方針を立て、AI が自律的に実装を進め、人が要所で検証し、その判断が次の生成の前提として蓄積される循環を、開発ループとして設計することにあります。

AI を1回呼び出すとき、AI は与えられた文脈をもとに考え、必要な道具を呼び、結果を観測して応答を返します。個人の工夫で最適化できるのは、この1回の呼び出しまでです。設計すべきなのは、その呼び出しを人が方針で方向づけ、AI が自律的に繰り返し、人が要所で検証し、判断がどこに蓄積されるかを決める開発ループです。

AI-DLC で計画から実装までを回す

AI 駆動開発ライフサイクル (AI-DLC) は、人が要求とビジョンを方針として与え、AI がそれを作業計画に落とし込み、不明点を問いとして人に返し、人が検証してから AI が実装を自律的に進め、これを開発の各工程で反復する進め方です。最終的な意思決定は人が持ち、AI に判断を委ねきらないようにします。AI が不明点を問いとして返す部分は、AI が必要なときに問いを投げ、人がその場で答える対話として回します。

人が検証する位置を開発ループの中に具体的に置く例は、以下の通りです。

• インフラ構成は AI が雛形を作り、連携部分の細かい制約を人間が検証して補う
• AI が生成したコードは自動レビューを通した上で、人のレビューを経てからマージする
• 環境や共有資産を変える操作は、AI に任せきりにせず事前に合意してから進める

どこで人が検証し、どこから AI に任せるかを開発ループの中に明示しておくことが、生成の速度を保ちながら安全を確保する条件になります。

開発ループの重さを変更の規模に合わせる

AI-DLC には、踏むべき工程を変更の複雑さに合わせて増減させる適応性があります。小さな欠陥修正では多くの工程を飛ばし、新規の業務ロジックを含む変更では計画から検証まで一通り踏みます。重さを規模に合わせるのは運用上の妥協ではなく、方法論そのものの設計です。少人数のチームでは、この調整がないと小さな修正でも進行の段取りだけで時間が削られます。

開発ループの重さを調整するときに意識している観点は以下の通りです。

• 踏む工程の重さが、その変更の規模に見合っているか
• 要件のずれを早い段階で見つけられる進め方になっているか
• 工程を省いても、判断の経緯を後から追えるか

変更の規模に開発ループの重さを合わせられるほど、小さな修正の速度と大きな変更での検証の密度を、同じ開発ループの中で両立できます。

検証した判断を前提として共有しチーム開発に組み込む

知見は、それ単体では蓄積されません。AI-DLC が各工程の成果物を次工程の前提として持ち越すのと同じく、人が検証した判断もチームと AI が共有するコンテキストに織り込まれて初めて、次の生成の前提になります。判断を共有コンテキストに残すことで、設計した開発ループをチーム開発に組み込み、全員が同じ前提でループを回せるようになります。

指摘を再現可能なルールにして共有コンテキストにする

開発者からの指摘をその場の修正で終わらせず、再現性、一般性、新規性、検証可能性の 4 つの観点で判定し、満たすものだけを AGENTS.md のルールとして残します。テストの方針やレビューの観点のように特定の作業でだけ使う知見は、領域ごとに Agent Skills として切り出し、その作業に入った段階で読み込みます。

ルールとして残すかどうかを判定するときに意識している観点は、以下の通りです。

• その指摘が一度きりの例外ではなく、別の場面でも繰り返し起きるものか
• 特定のファイルや状況に閉じず、他のメンバーの作業にも当てはまるか
• すでにあるルールと重複せず、新しく加える意味があるか
• ルールが守られているかを、後からコードやレビューで判定できるか

個別の指摘に対応する作業は、知見を書き残す作業というより、AI が次に読む前提を更新する作業に近いものになります。一度ルールとして残せば、どの開発ツールでも同じ判断基準を共有した状態で開発を始められます。

技術選定の判断を AI フレンドリーの観点で ADR に残す

アーキテクチャや技術選定のように、複数の機能にまたがって影響する判断は ADR (Architecture Decision Record) に残します。ADR は判断の背景を後から辿るための文書ですが、少人数で AI と開発するチームでは、その背景を読む相手に AI も加わります。そこで技術選定の判断軸に、AI がコンテキストを扱いやすいかを入れています。

この判断軸は、保守性の定石とされる設計をあえて採らない選択につながることがあります。関心を分けるために層や抽象を厚くするほど、AI が処理の流れを追うために読むコンテキストは増え、1 つの変更で複数の箇所に手を入れる負担も生じるからです。

AI フレンドリーの観点を反映した具体例は、以下の通りです。

• 型情報がコードに埋め込まれる言語を選び、AI が型を別の場所まで追わずに周辺の文脈を把握できるようにする
• スキーマと実装の型が自動で一致する構成を選び、AI が二つの表現を手作業で同期せずに済むようにする
• 抽象の層を最初から常設せず、必要になったときだけ切り出して、AI が処理の流れを最後まで追えるようにする

棄却した選択肢となぜ採らなかったかまで残したときに初めて、ADR は AGENTS.md や Agent Skills と繋がり、AI の生成をチーム全体で一貫させる前提になります。理由が残っていないと、AI は層を増やす、ベンダー名でディレクトリを分けるといった一般的なパターンへ書き直し、同じ判断を何度も蒸し返すからです。

まとめ

今回は、少人数のチームで AI を開発に馴染ませるために、AWS の AI-DLC を題材に、人が方針を立て AI が自律的に回る開発ループの設計を紹介しました。今後はより開発ループを設計し、人が検証した判断を前提として AI をチーム開発に組み込むことがチーム開発をさらに加速させるために重要となります。