AI駆動開発が向くプロジェクト・向かないプロジェクト ― 5軸で判定する適用基準

「うちのプロジェクトでAI駆動開発を試したいが、本当に効果が出るのか」 ― 経営会議で頻繁に出る問いだ。多くの組織が陥る失敗は、向き不向きを「業界全体」「会社全体」で判断してしまい、本来活用できる工程まで諦めてしまうこと。逆に、慎重に進めるべき領域でAIに過度な役割を与え、品質トラブルやコンプライアンス事故を起こすケースもある。AI駆動開発（AIDD）は万能ではないが、「使うか使わないか」の二択でもない。本稿では、プロジェクトの向き不向きを判定する5つの軸、向く・向かない典型例、そして向かないプロジェクトでも部分活用するための工夫を整理する。CTO・開発リーダー・PMが、新規プロジェクトの立ち上げ時に意思決定の指針として使えるガイドとして書いた。

要点：「向くか向かないか」は二択ではなく、プロジェクト内のどの工程に投入するかで判断する。仕様明確さ・テスト容易性・既存資産・ドメイン知識・失敗コストの5軸で判定し、工程単位で適用度を変える。

1. 適用判定の5軸 ― 向き不向きの見極めフレーム

AIDDの効果は、5軸で判定できる。仕様の明確さは、仕様が明文化できるか、それとも顧客対話の中でしか定まらないか。テスト容易性は、自動テストが可能か、UIや触感、業界判断が支配的か。既存資産は、コードベースとドキュメントが整備済みか、レガシーと暗黙知だけか。ドメイン知識は、一般的な業務領域か、業界特殊・規制業界の例外が多数か。失敗コストは、試行錯誤が許されるか、失敗が即賠償・法的責任に直結するか。5軸すべてが「向く側」のプロジェクトはAI主役で進められ、5軸すべてが「向かない側」のプロジェクトでも、工程単位の部分活用は可能だ。

💡 ポイント：5軸を1〜5点で採点し、合計15点以上なら主役起用、10〜14点なら部分活用、9点以下なら慎重判断、という運用をすると現場が回り始める。判断基準を明文化することが第一歩。

2. 向くプロジェクト典型例① ― Webアプリ・SaaS開発

WebアプリやSaaS開発は、AIDDが最も効果を発揮する典型領域だ。仕様を明文化しやすく、E2Eテストの自動化が可能で、似たパターンの実装が多い。CRUD操作、認証、データ表示、フォーム処理といった頻出機能はAIが得意で、人間は要件定義と品質保証に集中できる。スタートアップから中堅SaaS企業まで、AIDD導入で開発速度が2〜5倍になったという報告は珍しくない。経営層がAIDDの第一弾を試すなら、SaaS開発から始めるのが王道だ。

💡 ポイント：SaaS開発は「AIDDの教科書的フィット」。最初のパイロットとして選ぶと、組織内に成功事例が生まれ、他プロジェクトへの展開がスムーズになる。

3. 向くプロジェクト典型例② ― 業務システムのモダナイズ・社内ツール

既存業務システムのモダナイズ、社内ツールや管理画面開発も向き領域だ。既存仕様が文書化されている、段階的に置き換えやすい、効果測定がしやすいといった特徴がある。社内ツールは「完璧さより業務改善が目的」「ユーザーが社員でフィードバックしやすい」という性質も強く、AIDDで素早く作り直しが効く。データ分析や自動化スクリプトといった単発処理も、AIが得意な領域だ。これらの領域は、ROIが見えやすく、経営報告に乗せやすい。

📊 経営判断のコツ：社内ツールは「失敗しても顧客被害が出ない」ためAIDDのパイロットに最適。半年で5〜10本回せば、組織にAIDD運用ノウハウが蓄積される。

4. 向かないプロジェクト典型例 ― 命・金融・規制・レガシー

慎重に判断すべきプロジェクトもある。命に関わるシステム（医療機器・自動車制御・航空管制）は、最終的な責任をAIに委ねられない。金融取引のコア処理（高頻度取引・決済精算）は、監査要件と規制が厳しい。業界特殊・規制業界（製造現場の制御系・防衛・一部の医療データ処理）も、特殊性が高く部分適用が中心になる。暗黙知の塊のレガシー保守（30年もののCOBOL・ドキュメントゼロ）も、AIがコンテキストを取れない。顧客対話駆動の要件定義（共創型業務改革）も、要件が触ってみないと固まらないため主役には不向きだ。

⚠️ 注意：「向かない」は「使うべきでない」ではなく「主役を任せられない」という意味。部分活用は十分可能で、全面禁止と決めつけると機会損失が大きい。

5. 工程単位の使い分け ― 全体ではなく工程で判定する

向き不向きはプロジェクト全体ではなく、工程ごとに判断する。要件ヒアリングや顧客対応はAIDD適用度が低く、人間中心。仕様文書化は中〜高で、AIで構造化を補助できる。アーキテクチャ設計は中で、壁打ち相手として有効。実装と単体テスト、ドキュメント生成は高でAIが主役を担える。E2Eテストは仕様が明確なら高、デプロイは中で一部自動化、障害対応は低〜中で補助役、顧客対応は低で人間中心 ― という使い分けが現実解だ。

💡 ポイント：工程別マッピング表を1枚作って配るだけで、「AIDDを使うか使わないか」の議論が「どの工程で使うか」の議論に変わる。これだけで意思決定の質が変わる。

6. 判定フローチャート ― 新規プロジェクト立ち上げ時の意思決定

新規プロジェクトの立ち上げ時に判定するフローを示す。第1段階「仕様を文書化できるか」 ― Yesなら実装の主役起用OK、Noなら要件定義はAIで構造化補助のみに限定。第2段階「自動テストが書けるか」 ― Yesなら品質保証もAI主導OK、Noなら実装の最終チェックは人間で。第3段階「失敗コストは」 ― 低いなら高速イテレーションで攻める、高いなら慎重設計＋人間レビュー多重化。3段階の意思決定フローを社内標準にすれば、PMが新規案件で迷わない。

⚠️ 注意：3段階フローは「YesNoの線引き」が曖昧になりやすい。各組織で判定基準を文書化（例：自動テストカバレッジ70%以上ならYes）しないと、判断者によってブレる。

7. 「向かない」プロジェクトでも使える4つの工夫

向かないプロジェクトでも、4つの工夫で部分活用できる。工夫1：ドキュメント整備に投入 ― レガシー保守でも、ドキュメント化はAIが得意で「読み解き支援」として使える。工夫2：補助ツールに限定 ― IDE補完だけ許可し、自律エージェントは禁止する。工夫3：開発環境内に閉じる ― 機密・規制データは触らせず、ローカルLLM＋限定ツールで安全に活用する。工夫4：テストデータ生成のみ ― 本番データに触れず、合成データの生成支援に限定する。これら4工夫を組み合わせると、規制業界や命に関わる領域でもAIDDの恩恵を一部享受できる。

💡 ポイント：「向かないから全面禁止」ではなく「向かない領域でもこの4工夫で活用」と方針を立てるだけで、組織のAIDD成熟度は確実に上がる。

8. 経営者・CTOが採用判断する6項目チェックリスト

新規プロジェクトでAIDDを採用するか判断する際の6項目チェックリストを示す。「仕様を明文化できる人材がいる」「自動テストの整備に投資できる」「規制要件をクリアできる」「失敗を許容できる予算・期間」「AIガバナンスが整備されている」「レビュー体制がある」 ― 5つ以上にチェックがつくなら主役起用、3〜4つなら部分活用、2つ以下なら慎重判断で別プロジェクトから始めるのが現実的だ。判定結果を経営会議に提示する際は、5軸スコアと6項目チェックの2点セットで報告すると説得力が増す。

📊 経営判断のコツ：6項目チェックの結果を案件レビュー会議で標準化すると、「なんとなくAIDDを使う／使わない」という属人判断がなくなり、組織の判断品質が安定する。

9. パイロット選びの戦略 ― 第一弾で何を選ぶか

組織として最初のAIDDパイロットを選ぶなら、5軸スコアが高く、失敗コストが低い社内ツール・管理画面・プロトタイプから始めるのが定石だ。第二弾はSaaSの新機能開発や業務システムのモダナイズに進み、第三弾でレガシー保守の部分活用に展開する。最初に難しい案件を選ぶと、現場が疲弊して「AIDDは効果がない」という早期結論が出てしまう。経営者は「最初の成功」を意図的に設計し、組織内にAIDDの体験者を増やしていく。半年で3〜5案件、1年で10案件のペースが現実的だ。

⚠️ 注意：パイロット第一弾で難しい案件を選ぶと、現場が疲弊し「AIDDは効果がない」という早期結論が出てしまう。最初は意図的に「成功しやすい案件」を選ぶ。

10. 経営層が押さえる適用判断の論点

経営層が押さえるべき論点は3つ。第1に、適用判断を「全社・業界全体」ではなく「プロジェクト×工程」の2次元で行うこと。第2に、5軸スコアと6項目チェックを社内標準として運用し、案件レビューに組み込むこと。第3に、向かない領域でも4つの部分活用工夫を周知し、全面禁止という極端を避けること。これら3点を整えると、AIDDの組織全体の活用度が均質になり、特定プロジェクトだけが突出して進むという偏りもなくなる。経営層がこの判断軸を持っているかどうかが、AIDD投資のROIを大きく左右する。

📊 経営判断のコツ：判断基準の社内標準化は「派手ではないが効く」投資。標準化により判断品質が安定し、社内政治によるAIDD案件の偏りも解消される。

まとめ

AIDDの向き不向きは、プロジェクト全体ではなく、5軸（仕様明確さ・テスト容易性・既存資産・ドメイン知識・失敗コスト）と工程単位の2次元で判定する。Webアプリ・SaaS・社内ツール・モダナイズは主役起用が向き、命・金融コア・規制業界・暗黙知レガシーは慎重判断領域だが、4工夫（ドキュメント整備・補助ツール限定・環境隔離・合成データ）で部分活用は可能だ。経営層は5軸スコアと6項目チェックを社内標準として運用し、段階的なパイロット設計で組織の活用度を均質に上げてほしい。

AIDD適用判定チェックリスト

• [ ] 5軸（仕様・テスト・既存資産・ドメイン・失敗コスト）でプロジェクトを採点した
• [ ] 工程別のAIDD適用度マップを作成した
• [ ] 6項目の採用判断チェックリストを社内標準化した
• [ ] 向かない領域での4つの部分活用工夫を周知している
• [ ] パイロット第一弾は「成功しやすい案件」を意図的に選んだ
• [ ] 失敗コストの高い領域には人間レビューを多重化している
• [ ] 規制要件・コンプライアンスを満たす設計になっている
• [ ] AIガバナンス（利用ポリシー・権限設計・知財ルール）が整っている
• [ ] 案件レビュー会議でAIDD適用判定が標準議題になっている
• [ ] 経営会議にAIDD適用状況を定期報告している

IT COMPASSのAI駆動開発支援

IT COMPASS では、CTO経験者が外部CTO・技術顧問として、プロジェクトごとのAIDD適用判断を伴走支援しています。

支援できること

• 🎯 AIDD適用判定：5軸スコア・6項目チェック・工程別マッピングによるプロジェクトアセスメント
• 🛠 ツール選定とパイロット設計：Claude Code / Cursor / GitHub Copilot 等の評価・PoC設計
• 🛡 ガバナンス・セキュリティ整備：AI利用ポリシー、権限設計、知財・契約ルール
• 👥 開発組織の再設計：AIエージェントを前提としたチーム編成・役割定義・評価制度
• 📈 経営会議への定例参加：取締役会・経営会向けのKPI設計と進捗レポート

こんな方におすすめ

• 新規プロジェクトでAI駆動開発を採用するか判断したい経営者・PMの方
• 規制業界・レガシー保守でも部分活用したいCTO・開発リーダーの方
• 複数プロジェクトを抱え、優先順位を整理したい経営企画の方

お問い合わせ

スポット相談（1回／契約不要・最短当日）から、月額契約での継続伴走まで、フェーズに応じて柔軟に対応します。
👉 IT COMPASS お問い合わせフォーム
経営と技術の両面から、御社のAI駆動開発を一緒に設計しましょう。

監修者

西脇　靖紘（lanitech合同会社 代表取締役CEO 兼 CTO）

「テクノロジーで人と社会をつなぐ」をミッションに、企業のDX推進・AI導入支援から、デジタル教育・地域共創まで幅広く活動。エンジニアとしての現場経験と経営視点を活かし、外部CTO・AIコンサルティングなどを通じて企業のデジタル変革を支援している。著書はオライリー・ジャパンから複数刊行。

 
lanitech合同会社 webサイト