AI Nativeな開発への移行で見えてきたのは、AIに任せる範囲を広げるだけでは、開発全体の生産性は上がらないということでした。
要件や設計が曖昧なままAIに渡せば、出力の質は上がりません。一方で、AIによるアウトプットが増えれば、人がレビューすべき量が増え、今度はレビューがボトルネックになります。
そこでBALLASでは、AIに何を任せるかだけでなく、人がどの判断を持ち続けるのかを定義し、開発プロセスそのものを設計し直しています。
| 課題 | 何が起きていたか | どう対処しているか |
|---|---|---|
| 出力の質が上がらない | 要件も設計も曖昧なままAIへ渡していました。AIの精度ではなく、私たちの指示の解像度に原因がありました。 | 要件定義・設計などの上流を人が担います。AIは調査と草案の作成を主に担当します。 |
| レビューが追いつかない | 質が上がっても、レビューする量は莫大になりました。すべてを人がレビューすると、そこで開発が滞ります。 | 変更のリスクを数値化し、リスクの高い変更に人のレビューのリソースを集約します。 |
起票からリリースまでの開発を5つの工程に分け、**各工程でAIが担う作業と、人が持つ判断を明確にしています。**その共通基盤となるのが、コンテキストの整備と、変更リスクに応じてAIの自律度を変えるガードレールです。
AIの提案と人の判断との差分を蓄積し、次の提案精度と自律度を高めるフィードバックループを開発プロセスに組み込んでいます。
起票からリリースまでの5工程と、人が持つ5つの判断。
すべての変更を一律にAIへ任せるのではなく、変更のリスクと機械検証のしやすさに応じて、AIに任せる範囲を変えています。
実装に着手する前に、AI自身が5つの観点から変更内容を評価します。
| # | 観点 | 何を確認しているか |
|---|---|---|
| Q1 | 規模 | 変更が小さく収まるか |
| Q2 | リスク領域 | 認証・権限・DBマイグレーションなど、高リスク領域に触れないか |
| Q3 | 仕様の一意性 | 受け入れ基準と解の形が明確に定まるか |
| Q4 | 参照パターン | 類似実装があり、新しい設計判断を必要としないか |
| Q5 | 機械検証性 | テスト・lint・型チェックなどで結果を判定できるか |
一定以上のスコアであればAIに任せ、低ければ人が実装します。各観点は0か1かではなく濃淡を持って評価し、実際の運用結果をもとに閾値を調整しています。
あわせて、判定によらない強制ルールを3つ定めています。