AmapチームはQoder Knowledge Engineで100万行を超えるコードのドメイン知識を検索可能な資産に変え、タスクの厳格なone-shot成功率を37.3%から61.5%へ高めました。
AutoSDKはAmapが自動車業界向けに提供する車載SDKで、100万行を超えるコードと20以上のGitリポジトリで構成されます。Qoder Knowledge Engineで業務知識の「生成—改善—更新—利用」体系を構築した結果、同種の誤りを繰り返さず、タスクの厳格なone-shot成功率は37.3%から61.5%へ向上しました。AI Codingの能力上限を決めるのは、モデル自体ではなくドメイン知識です。KoCo-Benchでも、一般的なプログラミングのPass@1は90%を超える一方、ドメインコード生成は8.9%にとどまります。Agent方式でドメイン知識検索を加えると34.2%、最高分野では62.5%へ達しました（arXiv:2601.13240v3）。 Amap AutoSDKチームの実践も、この判断を裏付けています。要件理解、設計、コード生成、自己テストまでを接続し、AI Codingをエンジニアリングとして運用しています。しかし、one-shotの安定性には課題がありました。失敗は、探索の逸脱、生成結果のずれ、アーキテクチャ違反、制約の見落としの4種類へ集中します。原因は、業務用語の意味、モジュール責任の境界、過去の設計判断といったドメイン知識が、AIの利用可能な形に構造化されていないことです。知識の断絶こそ、安定性を妨げる本当のボトルネックでした。 そこで、コードと人の経験に眠る知識を、AIが認識、利用、進化できるエンジニアリング資産へ変えることを目標にしました。Qoder Knowledge Engineを基盤に、コード生成時に知識を蓄積し、AI Coding時に利用し、実践検証を通じて改善する、継続的な価値向上の循環を構築します。一度作って古くなる静的文書ではありません。
1｜階層と境界
循環を動かすには、まず知識の地図が必要です。何層に分け、どこへ置き、この記事でどこまで扱うかを定めます。
AutoSDKのドメイン知識は、最下層のコード事実から最上層の制約と選好まで連続しています。抽象度に応じて4層へ分け、DIKWの認知階層へ対応させました。
2｜知識のライフサイクル
知識は最初の生成から継続的な価値向上まで、事前介入による初回生成、コールドスタートから安定運用までの改善、高価値知識の特定と蓄積、継続更新というライフサイクルをたどります。
2.1 初回生成：事前介入と調整
境界を定めずにKnowledge Engineを動かすと、業務構造ではなくコード構造で知識を分割し、粒度が粗く、境界が曖昧で、重複するカードを大量に作ります。このずれを蓄積した後の修正は、作り直すより高くつきます。AIが誤読した点を一つずつ直す必要があるからです。
Qoderの /knowledge-plan コマンドで、AIが最初にリポジトリ全体をスキャンし、生成計画の草案を作ります。その後、人が業務境界の整合、曖昧さと重複の排除、観点の追加を行い、最終的な知識内容ではなく、方向と観点を示すAI向けの生成設計図へ変えます。
2.2 改善と修訂：初回調整からbad caseの循環へ
最初からすべてを正しくするには、あらゆる可能性の予測が必要で、高コストかつ脆弱です。複雑なシステムでは、予想外の境界条件一つで崩れます。
Qoderの /knowledge コマンドを用い、特定、整理、書き込みの3段階で改善します。改善対象を見つけて対応カードへ原因を結び付け、AIがコード事実と上下流関係を収集し、構造化された草案へ整理した後、ナレッジベースへ書き込みます。
2.3 何を蓄積するか：高価値知識の基準
すべての知識を最初から列挙することはできません。Agentが同じ方向で何度も誤って初めて、そこに落とし穴があると分かります。判断基準は一つです。その知識がなければ、Agentが高い確率で誤る、または探索コストが高くなるか。コードから容易に読み取れ、探索コストも低い情報は、別のカードへ重複して書きません。
実践から、コードだけでは信頼できる答えを得にくい4種類へ収束しました。
- 複雑な業務の全景：処理全体が複数ファイルに分散します。知識がなければ探索範囲とコストが大きく変動し、あれば正確な経路へすばやく収束します。
- コード内の隠れた落とし穴：似たコードほどAgentは混同します。「正しく見えて実は誤り」の経路を事前に示すガードレールになります。
- 業務用語の区別：慣習的な用語はコードに明示的な定義がなく、検索しても似て非なる答えが並びます。知識化すると、人が修正せずとも初回から正しく理解できます。
- リポジトリ横断の経路：AutoSDKの車線レベル地図のように複数Gitリポジトリへまたがるデータ経路です。スレッド切り替えやメッセージ送信で呼び出しが途切れる箇所は特に探索が困難です。カードは単一リポジトリに属しながら横断情報を記述し、リポジトリ単位の体系を守りつつ暗黙の接続を補います。
2.4 継続更新：Hookによる自動更新
コードは毎日変わるため、Knowledge Engineの更新をSkillへまとめ、コードプラットフォームのWebHookで開発フローへ接続しました。mainへマージするとAgentが起動し、Diffを取得してQoderCLIが知識を差分更新し、結果を開発者へ通知します。コード変更イベントが知識更新を駆動し、マージと同時に更新します。通常は無人で動き、異常時だけ介入します。
2.5 協働方式と進化
同じモジュールの知識を複数人が同時に変更しないことが、改善と自動更新の前提です。
現在、Qoder Knowledge Engineのクラウド更新は上書き方式で、複数人編集では後の変更が前の変更を上書きします。レビュー、段階公開、ロールバックはまだありません。そのため各モジュールの知識を1人のOwnerへ集約し、並行作業の効率と引き換えに一貫性を保っています。今後、共同編集とバージョン管理が強化されれば、効率と一貫性を両立できます。
3｜知識の利用
3.1 一つの情報源、複数の出口
AutoSDKには4種類の利用者がいます。AI Agentは構造化検索、開発者は文書検索、非開発者はコードを読まずに業務を照会し、外部チームは既存プラットフォームを通じて連携します。それぞれ別版を作りたくなりますが、分岐後のずれと矛盾は保守コスト以上に致命的です。
3.2 ネストされたリポジトリの検索
AutoSDKには、メインプロジェクト内にコンポーネントリポジトリを含む構成が多数あります。メインリポジトリを開いても、コンポーネント知識は子リポジトリにあります。検索範囲がワークスペースで止まれば、知識生成への投資が無駄になります。
実際に、Agentがメインリポジトリだけを検索して概要しか得られず、重要ロジックのある子リポジトリを見つけられないことがありました。開発者がワークスペースを切り替え、AI Codingの流れが退化しました。Qoderのネスト検索は、親リポジトリから子リポジトリの知識を検索するかを設定でき、知識到達範囲をワークスペースではなくリポジトリ構造へ結び付けます。
3.3 AI Codingフローでの知識利用
AutoSDKは全体としてplan-act方式です。計画段階で誤ると、その後はすべて手戻りになります。SearchMemoryが知識カードを索引化し、工程ごとに目的を変えて検索します。
- 要件理解：PRDのAPI名、プロトコル名、機能概念、用語を使って知識を検索し、適合度を評価します。高適合なら候補コンポーネントへ入れてAGENTS.mdと照合し、低適合または未検出なら無視して、用語誤読による誤った割り当てを防ぎます。
- 探索：探索テーマと対象コンポーネントからモジュール構造、コーディングパターン、技術制約を検索してからコードを調べます。重要な新しいシンボルを見つけるたびに、責任と上下流関係を検索します。未検出でも探索は止めず、検出すれば検索範囲を大きく縮めます。
- 設計：「二つの情報源を統合し、調査を主、知識を従とする」原則を守ります。ドメイン用語、重要関数、過去の設計方針から背景と進化方向を検索し、未検出なら回数上限を設けて語を変えます。その後コード調査を行い、知識と現場コードを照合して設計のずれを防ぎます。
4｜効果測定
事例では知識がbad caseをどう修正するか、データでは導入前後の実測効果を評価しました。
4.1 事例：知識がbad caseをどう修正するか
事例1：複雑な業務全景の見落とし
事例2：類似構造体の意味的な混同
isHighlight を車線ハイライトのスイッチと誤解しました。人が何度もヘッダーファイルを示す必要がありました。
知識の介入：用語の区別により、StyleAとStyleBは独立し再利用禁止、isHighlight は周辺車両レベルで車線とは無関係、と一度で理解して改修しました。
根本的な示唆：「名称が似ている = 意味が同じ」ではありません。類似オブジェクトと異なる概念を明示し、混同型bad caseを根元で防ぎます。
4.2 データ：投入と実測効果
コスト：初回生成は1リポジトリ平均2時間で計画と設計図を確認し、20以上の業務コンポーネントリポジトリを週単位でカバーしました。日常保守はbad case単位で、分析、修訂、回帰検証を時間単位で閉じます。
主要指標：strict adjusted one-shot rateです。分母は一定期間にコード変更を伴ったタスク、分子は1回のqueryで完了し、コードの80%が30分以内にロールバックまたは変更されなかったタスクです。AIが業務全体と詳細を理解し、一度で正しく完了できるかを測ります。
導入後、120以上の実業務タスクを実行し、難易度と要件種類を幅広く含めました。導入前後の段階比較と、同期間に実際に知識を検索したかどうかの対照比較を行いました。
段階比較：知識体系の導入前後
導入後、厳格なone-shot率は37.3%から61.5%へ上昇し、1タスクあたりの平均対話回数は3.49から2.53へ低下しました。初回成功率だけでなく、反復コストも下がっています。
対照比較：同期間に知識検索があった場合となかった場合
時間傾向やタスク構成の影響を分離するため、同期間内で知識検索の有無に分けました。検索ありのグループでは、対話経路が平均39%短縮し、暗黙のコンテキストを多く必要とする複雑なタスクと大規模プロジェクトで特に顕著でした。
5｜「使える」から「安心して使える」へ
Amap AutoSDKは、Qoder Knowledge Engineで知識の生成、改善、更新、利用をエンジニアリング化しました。厳格なone-shot率は37.3%から61.5%へ、平均対話回数は約30%減少し、検索ありの対話経路は39%短縮しました。
/knowledge-plan で事前に境界をそろえ、曖昧さと重複を除いてから大量生成し、/knowledge で実践中の問題を改善します。SearchMemoryは要件理解、探索、設計で知識カードを正確に検索します。ネストされたリポジトリと、一つの情報源から複数の出口（RepoWiki／KnowledgeCard／QMind）を扱えるため、人とAIが同じ知識を利用し、版のずれを防ぎます。
ドメイン知識のエンジニアリング化で重要なのは、文書の量ではなく、同じ種類の誤りを二度と起こさないことです。それができれば、AI Codingは「使える」から「安心して使える」へ移ります。