AI ネイティブ製品開発ワークフロー

​

ソリューションアーキテクチャ

企業が AI コーディングで直面する本当の難しさは、モデルがコードを書けないことではなく、一度の成功を再現することが難しい点にあります。要件は人によって何度もリレーされ、ターンを経るごとにコンテキストが漏れていきます。ビジネスの境界や過去の設計判断を理解しないエージェントは、特にレガシーコードベースにおいて、機能は「正しく」実装できてもシステム全体を壊してしまう傾向が顕著です。生成速度は向上しましたが、レビューとテストのキャパシティはそれに合わせて拡大していないため、欠陥は「合格」のラベルを付けたまま下流に流れていきます。これら3つの問題は、それぞれプロセス・ナレッジ・品質を指しています。そのいずれが欠けても、スケール化は不可能になります。

本ソリューションは、AI コーディングを開発のタイムラインに沿って再現可能なパイプラインとして体系化し、その上下にそれぞれ1つの横断的な支援レイヤーを配置しています。

• 4段階の SDLC パイプライン — 要件明確化、ソリューション設計、コード開発、検証が順番に展開されます。段階をスキップすることはできず、成果物は自動的に着地し、制御フローとデータフローは分離されています。すべての段階の出口には独立したゲートが設けられています。失敗した場合はその場でループバックするか人間にエスカレーションされるため、問題が次の段階に持ち込まれることはありません。不確実性が残っている間は、人間がループ内で修正しながら Qoder IDE 上で作業を続け、目標・境界・受け入れ基準が安定した時点で、タスクは Qoder に委譲されて非同期で実行されます。
• ナレッジ供給レイヤー — リポジトリナレッジとコードの事実がエージェントの認知基盤を形成します。ハード制約は決定論的に読み込まれ、ドメインナレッジはスコープルーティングとハイブリッドリコールによって検索され、その結果は事実と照合したうえで検証され、タスクコンテキストパッケージに絞り込まれます。量よりも精度が重要です。
• 品質と進化のレイヤー — 決定論的な問題はルールと Hooks が担当し、意味的な問題は評価基準を限定した独立レビューが担当します。実行と検査は分離され、リトライには上限が設けられ、エスカレーションパスが定義されています。実行時データは原因分析・介入・検証のためにフィードバックされ、すべての教訓をより早い段階の制約に変えます。

この3者の依存関係は以下の通りです。パイプラインがなければ、ガードレールを取り付ける場所がなく、ナレッジもどの段階で注入すべきか分かりません。ナレッジ供給がなければ、どれだけ整備されたプロセスも間違ったことを整然とやり遂げるだけです。可観測性とフィードバックがなければ、制約の密度は自然には増えません。企業での導入も同じ順序で進めるべきです。まず骨格を構築して成功した実行を再現可能にし、次にガードレールを厚くして高頻度のエラーを止め、最後にループを閉じてシステムがますますスムーズに動くようにします。

​

主要な優位性

​

優位性 01：デリバリーを再現可能にするステージゲート・トポロジー

デリバリーが通過しなければならない段階は明示的に定義されています。各段階の出口には独立したゲートがあり、成果物は構造化された形で着地し、エージェントはペイロードではなくパスを渡し、実行順序はエージェント自身ではなくシステムが保持します。これにより、人間が「情報の中継役」を担うことで生じていた損失 — コンテキストの伝達漏れ、途中での制約の失念、追跡できないプロセス — が解消されます。同じ要件であれば、別の人が実行しても、別の日に行っても、ぶれることはなくなります。

​

優位性 02：ヒューマンインザループと契約駆動の非同期という2つのモードを不確実性で使い分け

要件や影響範囲がまだ不明確な間は、人間が細かいステップごとに同期的に修正しながら、Qoder IDE 上で作業を続けます。目標・境界・受け入れ基準が安定した時点で、タスクは契約として記述され、Qoder に委譲されて非同期で実行されます。人間は重要なゲートでのみ介入します。これにより、2つの正反対の誤りを防ぎます。探索的な作業を長時間のエージェント自律実行に無理やり押し込むこと、そしてすでに明確に定義されたバッチ作業を人間の注意力という狭い帯域に縛り付けることです。

​

優位性 03：レガシーシステムを先に理解し、その後にインクリメントを設計する

ランタイム探索、静的スキャン、ビジネスナレッジを相互に照合し、結論は確定事項・不確定事項・要判断事項に明確に分けます。影響分析は呼び出し元、設定分岐、非同期ジョブ、データ互換性をカバーし、そこから壊してはならない回帰ベースラインを確定します。これにより、AI がインクリメントしか見ず、レガシーの制約を見落とし、「見えない」ことを「もはや不要」とみなしてしまう失敗モードに対処します。

​

優位性 04：実行と検査を分離したタスク契約とガードレール

ルールは変更してよい点とそうでない点を定義し、Skills は標準的な手順を記録し、Hooks は重要なアクションの前後で決定論的なチェックを発動します。検査エージェントは実行エージェントから分離されており、判定は「合格」「警告付き合格」「不合格」「人間へのエスカレーション」の4つの状態に収束します。これにより、「自分の答案を自分で採点する」という構造的なバイアスや、プロンプト内にしか存在せずコンテキストノイズの下で侵食されていく境界のドリフトを排除します。

​

優位性 05：正確なコンテキストを供給するナレッジエンジニアリング

ハード制約が最初に決定論的に読み込まれます。ドメインナレッジはスコープルーティングとハイブリッド検索によってリコールされ、依存関係や上流・下流の関係に沿って範囲内で拡張されたうえで、ステータス・バージョン・現在のコードの事実と照合して検証され、予算管理されたタスクコンテキストパッケージに絞り込まれます。これにより、ナレッジの不足と過剰が同時に発生するというパラドックスを解消します。長大なドキュメントの中で、実際に実装を決定づけるのはごく一部に過ぎないのです。

​

優位性 06：制約の密度を増やし続ける自己進化ループ

実行時データは、メトリクス・トレース・ログの3層で実行を再構築します。異常はプロセス・コンテキスト・役割の境界のいずれかに原因を帰属させ、人間の判断を経たうえで介入を実施し、前後比較によって、新たな誤検知を招くことなく問題が本当に収束したことを検証します。これにより、教訓が個人の記憶にとどまり、同じ落とし穴に繰り返しはまる問題に対処します。基準はただ一つ、特定のエラークラスの露出時点がより早い段階に移ったかどうかです。

​

ビジネスシナリオ

​

シナリオ 01：0→1 の新規プロジェクト開発 — まず意図を収束させ、それから生成を増幅する

まず曖昧な意図を明示的な契約に収束させ、その契約の下でエージェントに生成を並列で増幅させます。

• 顧客の課題：新規プロジェクトにはレガシーのしがらみがありませんが、セーフティネットもありません。ビジネス目標、ドメイン境界、インターフェース契約、非機能要件が曖昧なままの瞬間、エージェントは立ち止まって問いかけることはしません。もっともらしいデフォルトで空白を埋め、未確認の決定を高速でコードに固定してしまいます。生成コストがゼロに近づいたとき、最大の無駄は書くのが遅いことではなく、間違ったものを非常に速く作ってしまうことです。
• トリガー：新製品・新モジュール・新サービスをゼロから立ち上げる場合。対象は使い捨てのプロトタイプ、市場向け MVP、本番グレードのシステムのいずれでも構いません。
• プラットフォームとエージェントのアクション：要件明確化で目標とスコープ、ユーザーとコアシナリオ、ドメインモデルとビジネスルールを収束させ、続いて受け入れ基準と非機能要件を定める → ソリューション設計ではまず発散してから収束させ、プロダクト・体験・技術の境界を確定し、エンジニアリングの骨格を立ち上げる。技術スタック、ディレクトリ構造、テストフレームワーク、CI/CD は初日からエージェントフレンドリーに設計する → コード開発ではまず足場とエンジニアリングベースラインを敷き、共有契約が安定したら依存関係のトポロジーに沿って並列生成し、バッチコミットしながら小さなステップで実行する → 検証では品質ベースラインを確立すると同時に、システムが実際に動作することを証明する。エンジニアリングの厳密さは対象に応じて段階的に適用する。プロトタイプは軽量な契約の下、Qoder IDE で素早くイテレーションする。MVP は要件と設計の完全なインプットを必要とし、Qoder による並列生成を行う。本番グレードのシステムはさらに非機能・セキュリティのベースライン、完全な CI/CD、人間によるゲートを必要とする。
• 成果物：判断可能な受け入れ基準と非機能ベースライン、エンジニアリングの骨格と足場、契約の下で生成されたコードとテスト、Rules・Skills・テンプレート・リポジトリナレッジを含む再利用可能な AI ネイティブ開発アセット一式。
• 完了の定義：「エージェントが動くシステムを生成した」ことではなく、システムがビジネス目標を満たし、設計が確認済みであり、品質がエビデンスで裏付けられ、すべての重要な決定が人間によって行われ記録に残されていることです。
• 人間によるゲート：プロダクトが目標とスコープを承認する。開発とアーキテクチャがドメインモデル、共有契約、エンジニアリングの骨格を確認する。非機能・セキュリティのベースラインが承認される。リリース前に受け入れを行う。

​

シナリオ 02：レガシーのイテレーション — まず既存システムを理解し、その後にインクリメントを設計する

まずレガシーシステムとその回帰ベースラインについて追跡可能な理解を確立し、その後にインクリメントを管理された変更計画に落とし込みます。

• 顧客の課題：レガシーシステムの実態となるルールは、コードのブランチ、設定センター、メッセージコンシューマー、定時実行ジョブ、そして人の経験の中に散らばっています。インクリメントだけを見てそれらの制約を見落とすエージェントは、機能は「正しく」実装できてもシステム全体を壊してしまうことがあります。UI が廃止されていてもバックエンドのパスが停止したとは限らず、静的な参照がなくても本番環境では何も呼び出していないとは限りません。
• トリガー：レガシーモジュールへの追加や変更が必要になる場合。スコープは局所的な修正からモジュール間イテレーション、アーキテクチャのリファクタリングまで多岐にわたります。
• プラットフォームとエージェントのアクション：要件明確化では、インクリメントの目標と非目標を併せて明示し、ランタイム探索・静的スキャン・ビジネスナレッジを相互に照合する。結論は確定事項・不確定事項・要判断事項に分割する → 影響分析は呼び出し元・呼び出し先・設定分岐・非同期ジョブ・データ互換性をカバーし、壊してはならない回帰ベースラインを確定する → ソリューション設計では、モジュール・ファイル・クラス・コードアクションまで落とし込んだ影響マップを構築し、タスク分解・依存順序・編集境界・検証計画・ロールバックパスを含む契約を形成する → コード開発では変更を Worktree の実行環境に隔離し、上層タスクを開始する前に共有契約を安定させ、各バッチを「最小編集、ビルドとローカルテスト、差分レビュー、エビデンス取得、独立コミット」のループで回す。Hooks が重要なアクションの前後で決定論的なチェックを行う → 検証は段階的に拡張する。エンジニアリングの正しさ、機能の正しさ、システムの実行可能性、挙動の等価性までカバーし、高リスクのリファクタリングでは新旧の挙動も比較して非対象スコープが変わっていないことを確認する。
• 成果物：レガシーの認知ベースラインと階層化された影響リスト、変更契約と影響マップ、インクリメンタルなコードとテスト、機能受け入れとレガシー回帰の双方のエビデンス、更新されたリポジトリナレッジ・Rules・Skills・回帰ベースライン。
• 完了の定義：新機能が目標を満たし、かつ対象スコープ外の既存の挙動が壊された証拠がないこと — 両方が成立してはじめて変更は成功です。
• 人間によるゲート：プロダクトがビジネス目標・非目標・機能の廃止可否を確認する。不確定な機能はエージェントが単独で削除してはならない。開発とアーキテクチャがモジュール責務・共有契約・影響の大きいコードアクションを承認する。権限が拡大する場合、障害が繰り返される場合、禁止スコープに触れようとする場合は実行を停止してエスカレーションする。リリースは独立した回帰テストと受け入れが合格した後でのみ行う。

​

シナリオ 03：エンドツーエンドのエージェントデリバリー — 要件を入れればコードが出てくる

記述可能・検証可能・書き戻し可能な小ループの作業はまとめてエージェントに委ね、人間は重要なノードでのみ確認します。

• 顧客の課題：タスクの供給が人間の処理帯域を上回っています。ユーザーフィードバックや本番の障害は蓄積し続け、細かな要望のロングテールが開発の並行処理能力を食いつぶし、作業項目は人がオンラインでコンテキストを切り替えられる間しか進みません。こうしたバックログは人員を増やしてもスケールで解消できません。
• トリガー：不具合報告、体験フィードバック、低リスクの小ループ作業 — 設定変更、ルールの補完、互換性修正、ドキュメントやツール類の改善 — がキューに入り、安定した受付体制と、SOP として記録できる決定ルールが存在すること。
• プラットフォームとエージェントのアクション：作業項目は開発コラボレーションプラットフォームから同期され、人間がボード上でトリアージを行う → クレームされると、エージェントは明確化・計画・開発・テスト・コードレビューのサブタスクを自動的に起票する → コンテキストエンジニアリングが作業をエージェントに理解可能な形にパッケージ化し、チームの SOP は開発テンプレートとして実行可能なプロセス契約に固定化される → 各タスクは隔離された復旧可能なワークスペースで実行され、中断後も再開できる → 段階ごとのアウトプットとステータスは1つのタイムラインに書き戻され、受け入れ可能なエビデンスチェーンを形成する → 情報が不足した場合、スコープが変更された場合、高リスクの決定が現れた場合は、エージェントが人間の確認を求める。
• 成果物：サブタスクのタイムラインが付いたクレーム可能な作業項目、契約ベースの開発テンプレートと作業パッケージ、変更・テスト・レビューのエビデンスチェーンが付いたデリバリー成果。
• 完了の定義：「完了」は「受け入れ可能」ではありません。段階ごとのアウトプット、テストとレビューのエビデンスが完全であり作業項目に書き戻されていること、そして重要なノードでの人間の確認を経てはじめてデリバリーとしてカウントされます。
• 人間によるゲート：受付が安定しているか、ルールを SOP として記録できるか、人間の確認が必要なノードが存在するかといったトリアージと適否判断。スコープの変更と高リスクの決定。最終的な受け入れ。

​

参考プラクティス

​

プラクティス名

AMAP オートモーティブ事業部の AutoSDK：百万行規模の C++ レガシー SDK における AI ネイティブなフルチェーン・イテレーション

​

プラクティスの背景

• 顧客とビジネス：AutoSDK は AMAP のオートモーティブ事業部が提供する自動車業界向けの車載ナビゲーション SDK であり、20を超える Git リポジトリにわたり累計百万行のレガシー C++ コードを抱えています。多くの自動車メーカーが二次開発を通じてこれを構築に活用しており、すでに量産に投入済みです。
• 業界の制約：車載グレードのデリバリーでは、出荷するすべてのコード行が実環境での長期検証に耐えることが求められます。破壊的な変更はすべて、下流の数十の自動車メーカーに連鎖的に波及し、量産中の車両の生産ラインのペースや OTA 計画にまで影響しかねません。
• 従来のプロセス：AI コーディングは、人間の労力に支えられた「生成＋事後検査」のパターンに従っていました。スケールさせると、レビューが成果物に追いつかず、品質に個人差が生じていました。
• コア課題：弱点は単発実行の安定性であり、探索の道ずれ、生成の意図からの逸脱、アーキテクチャ違反、制約の見落としという4種の失敗として表面化していました。原因の所在は狭く集中していました。ビジネス用語の意味、モジュールの責務境界、過去の設計上のトレードオフといったドメインナレッジが、AI が扱える形に構造化されたことがなかったのです。インプットのノイズも極めて激しく、PRD は約20万のコンテキストを持ち込む一方、実際に実装を決定づけるルールは約1万に過ぎませんでした。
• パイロットのスコープ：AutoSDK の20を超えるビジネスコンポーネントリポジトリ。ナレッジの生産と消費の全チェーン、エンドツーエンドのパイプライン、品質ガードレール、自己進化ループをカバーします。

​

プラクティスのアプローチ

• イベントの入り方：要件がパイプラインに入ると、専任の役割が順に引き継ぎます。メインラインへのマージはナレッジの増分更新をトリガーし、ゲートでの却下や可観測性メトリクスの劣化は改善ループをトリガーします。
• 制御レイヤーのルーティング：ナレッジはまず層にマッピングされます。コードの事実・用語・プロセスから、ビジネスドメインナレッジ、そして制約とプリファレンスへと及びます。事実レイヤーは Qoder のナレッジエンジンがまとめて抽出し、経験に基づく判断はシニアエンジニアが Skills と AGENTS.md に記述します。能力アセットは汎用・ドメイン・プロセスの3層で分離し、オーケストレーション時に許可リストを一度だけ固定することで、開発役割が検証用の能力にアクセスできないようにします。
• エージェントの実行方法：プロセスは、意図認識、オーケストレーション計画、コード調査、ドメイン設計、実装、自動検証などの段階に分割され、それぞれを専任のエージェントが担当します。すべての実行エージェントには独立した検査役が対となり、レベルごとにエスカレーションします — 第2レベルのスクリプトによる捕捉、構造検証、そして詳細なドメインチェック。コンテキストはカテゴリ別に統制されます。常駐、必要時のリトリーブ、役割内の隔離、または段階成果物としての定着。エージェントはペイロードではなくパスを渡します。決定論的な問題は、書き込みが着地する前に Hooks が検証・書き換えを行い、意味的な問題は独立したレビューエージェントが採点します。
• 成果の書き戻し方法：ナレッジは計画・生産・チューニングの後にナレッジベースに書き込まれ、同じナレッジが人間と AI の双方に、別々のバージョンに分岐することなく提供されます。実行データはメトリクス・トレース・ログとして定着します。検査の判定と却下の記録はループに入り、ルール・Skills・プロセス最適化のインプットとなります。
• 障害のフィードバック方法：すべてのバッドケースは「特定・修正・リグレッション」の固定された3ステップで処理します。リグレッションは人間がテキストを理解できるかに依存しません。元のタスクに戻って AI の挙動が是正されたかを検証し、是正されていなければ手戻りとなります。ゲートのリトライは2ラウンドを上限とし、その後は人間に引き継ぎます。
• 人間の決定ポイント：ナレッジ生産のブループリントは人間がレビュー・修正します。基調となる2つのステップ — 設計と実装 — では機械検査に加えて人間の確認を付加します。改善提案はシステムが生成し、人間のレビューが判断します。却下時は理由を記録し、同じ提案の繰り返しを防ぎます。

​

プラクティスのフロー

​

プラクティスの成果

• デリバリーの品質と効率：欠陥の流出は約73%削減、コード採用率は84%、計測対象の API 規約準拠率は80%。明確に定義され制約が成熟した要件について、エンドツーエンドのデリバリーサイクルは月次から週次イテレーションへと移行しました。
• ナレッジシステムによる直接的な効果：ナレッジシステムの導入後、厳格な単発実行の成功率は37.3%から61.5%に上昇し、タスクあたりの平均会話ターン数は3.49から2.53に低下しました。同時期の対照比較において、ナレッジが実際にリコールされたかどうかでグループ分けしたところ、リコール群は相互作用チェーンを平均約39%短縮しており、複雑なタスクや大規模コードベースで効果が最も顕著でした。
• プロセスとコストの最適化：調査段階が並列インスタンスをサポートした後、平均所要時間は約50%短縮し、プロセス全体の所要時間は1.5時間から1時間未満に低下しました。メインエージェントの平均コンテキスト使用率は70%から50%に低下しました。4つの検査ゲートは現在、通過・却下のデータを継続的に生成しており、通過率は50ポイント向上しています。
• 検証済みのループ：生産・チューニング・更新・消費のナレッジループにより、同種の錯誤が二度と発生しなくなります。ゲートの却下記録は、原因分析・介入・検証を経て、デフォルトで保持されるプロセス制約に変わります。
• まだカバーされていない範囲：事後の統合は3つの防御線の中で最も未成熟であり、フィードバックを実効的なルールに変える作業はまだ主に人間の判断に依存しています。ビジネスロジックのレビューは発展途上です。複数著者によるナレッジ編集には、成熟したレビュー・段階的ロールアウト・ロールバックがまだ欠けており、暫定的な運用として各モジュールのナレッジを単一のオーナーに集約しています。

​

推奨製品構成

本ソリューションのデリバリーに必要な製品のみを記載しています。リポジトリナレッジと検索、Rules と Skills、Hooks、Worktree による隔離実行、MCP 拡張は、以下の製品に組み込まれています。