AI駆動開発のベストプラクティス6原則

AI駆動開発のベストプラクティスを探すと、たいていはツールの使い分けやプロンプトの書き方に行き着きます。ただ、同じツールを入れた組織のあいだで結果が割れる原因は、そこではありませんでした。この記事では、プロセスの側から6つの原則として整理し、インプットの整え方と削る順番の決め方まで具体化します。

同じツールを入れても結果が割れる理由

Google CloudのDORA 2025年レポートは、AIの主な役割を増幅器（amplifier）と位置づけ、組織がもともと持っている強みと弱みの両方を拡大すると報告しました。整った開発プロセスを持つ組織がAIを入れると出力が伸び、曖昧な仕様と不定形なレビューを抱えた組織が同じツールを入れると、曖昧さのほうが速く広がります。

同じ調査から派生したDORA AI Capabilities Modelは、AIの効果を増幅する要因として、明確なAI方針の共有、健全なデータ基盤、AIから参照できる社内データ、強いバージョン管理、小さいバッチでの作業、ユーザー中心の視点、質の高い社内プラットフォームの7つを挙げています。並べてみると、AIそのものの話が1つもありません。ベストプラクティスの探し先は、増幅される側にあります。

以下の6原則は、その増幅される側を先に整えるためのものです。手法の全体像から確認したい場合はAI駆動開発をご覧ください。

AI駆動開発のベストプラクティスを支える6つの原則

前半の3つは日々の実装で効き、後半の3つは案件を進めるときの判断基準になります。どれもツールの選定より前に決められることです。

原則1：AIへの指示と成果物を分けて置く

要件・既存コード・開発ルール・テンプレートといったインプットと、設計書ドラフト・実装・テストコードといったアウトプットを、置き場から分けます。AIへの指示はAGENTS.mdのような設定ファイルへ集約し、生成物と混ぜません。分けておくと、出力がずれたときに指示側を直せばよいのか生成をやり直すのかが、すぐ切り分けられます。

原則2：レビューを工程ごとに刻む

生成物をまとめて最後に確認するのではなく、工程の境目ごとに承認してから次へ進みます。判断基準と承認の流れ、責任者を事前に決めておくと、レビューのたびに前提の議論から始まることがなくなります。レビューの深さを段階で捉える整理はレビューの5段階レベルで扱っています。

原則3：既存の資産をインプットに回す

過去の設計テンプレート、計画書の標準、課題管理に残った議論といった秩序だった記録を、新しい案件のインプットへ回します。インプットの品質が成果物の品質を左右するため、資産の再利用は節約ではなく品質の施策として扱います。

原則4：AIに任せる範囲を先に決める

全タスクを一律に対象としません。定型・反復業務とドキュメント生成は効果が出やすく、要件定義や意思決定は人間が主体でAIは補完役にとどまります。無理にAI化しないことが品質を守るという判断を、着手前に共有しておきます。

原則5：効果を実現条件とセットで扱う

短縮率や削減率だけを社内へ共有すると、前提が抜けたまま期待値だけが上がります。gaipackが公開している数字にも、開発スピードの短縮にはインプット品質の水準が、コスト削減にはレビューと修正を人力で確保することが、それぞれ条件として付いています。数字を持ち出すときは条件を必ず添えて伝えます。

原則6：削る順番を先に合意する

予算と納期が動かせない案件では、何から削るかを着手前に決めておきます。順番を決めていないと、その場の力関係で削る先が変わり、品質の落ち方が読めなくなります。

インプット資料の整え方を3段階で決める

原則3と原則5は、どちらもインプットに戻ってきます。ただ「資料を整えましょう」では動かないので、整備の水準を3段階に分けます。いまの資料のままできることから始め、案件を進めながら上げていく想定です。

Goodの行が細かいのには理由があります。セル結合や画像化されたフロー図は、人には読めてもAIには読み取りにくく、そのまま渡すと出力の不確かさになって返ってくるためです。最初から全資料をBestに揃えようとせず、Goodの範囲で着手するほうが立ち上がりは速くなります。

要件定義プロセスの標準化をこの方向で進めた共通プラットフォーム開発の案件では、開発の手戻りを約 66% 削減しています。AIへ渡す文脈そのものの設計はコンテキストエンジニアリングで個別に扱っています。

削る順番を先に決めておく

原則6を運用に落とすと、トレードオフの優先順位をプロジェクト計画書へ書いておく、という作業になります。gaipackが既定として置いている並びは次のとおりです。

工程のショートカットが最初で納期の相談が最後、という並びに合意しておくと、切迫した場面でも判断がぶれません。案件の特性によって順番を入れ替えることはありますが、入れ替えたこと自体を計画書に残します。AIDDスキーム全体での位置づけはAIDDスキームのご紹介にまとめています。

AI駆動開発のベストプラクティスから外れる3つの進め方

相談を受ける案件で繰り返し見えるつまずきを3つ挙げます。どれもツールではなく、決める順番の問題として現れます。

つまずき1：ツール比較から入ってしまう

どのエージェントが優れているかを先に決めても、任せる範囲と受け取り方が定まっていなければ、出力の使い道が案件ごとにばらつきます。原則4の範囲の線引きと原則5の実現条件を先に置き、そのうえで必要な環境を足していきます。工程別の選び方はAI駆動開発で使われるツールで整理しています。

つまずき2：完了の定義を置かないまま走る

どこまでできたら次へ渡してよいかが決まっていないと、レビューのたびに基準の議論が起きます。要件定義であればモックと要件の承認、開発であれば結合テストの完了というように、工程ごとの完了条件を先に書いておきます。

つまずき3：出た数字を条件ごと切り出さない

削減率だけを引用して社内へ共有すると、実現条件が抜けたまま期待値だけが上がります。数字が再現しなかったときに原因を追えるよう、前提とセットで残します。

AI駆動開発のベストプラクティスに関するよくある質問

導入前の相談で受けることの多い質問をまとめました。

小さなチームでもベストプラクティスを守れますか

守れます。原則1の指示と成果物の分離と、原則4の任せる範囲の明示は、人数に関係なく初日から実行できます。人数が少ないほどレビューの担い手が限られるため、対象タスクを広げすぎないことが結果的に品質を守ります。

ツールを統一したほうがよいですか

統一そのものが目的にはなりません。指示の置き場と成果物の置き場が分かれていて、レビューの観点が決まっていれば、複数のツールが混在していても運用は成立します。先に決めるのはプロセスの側です。

ドキュメントを整える工数はどれくらい見ますか

案件によりますが、Goodの水準までなら既存資料の書式を直す範囲で収まることが多いです。MarkdownとMermaidへの移行は案件を進めながら段階的に行うほうが、着手は速くなります。

生成AIを入れれば生産性は上がりますか

上がるとは限りません。DORAの2025年レポートが示すとおり、AIは組織が持つ強みと弱みの両方を拡大します。プロセスとレビューが整っていない状態で導入すると曖昧さのほうが速く広がるため、まず増幅される側を整えるのが順番です。

まとめ

AI駆動開発のベストプラクティスは、指示と成果物を分ける、レビューを工程ごとに刻む、資産をインプットに回す、任せる範囲を先に決める、効果を実現条件とセットで扱う、削る順番を先に合意する、の6つに集約できます。いずれもツールの選定より前に決められることで、インプット整備の3段階とトレードオフの順番がその受け皿になります。

どの原則から着手できるかは、いまの資料と体制によって変わります。自社での進め方について、お気軽にご相談ください。