AGENTS

DEV Agent

設計評価方針の生成と Block 図コンポーネント影響分析。自動車 ECU 変更向けの自動設計評価です。

中核的な課題

1. 設計評価方針が上級エンジニアに高度に依存：変更点、歴史的設計事例、設計方針、方法、評価方法、懸念点を同時に理解する必要があります。
2. 歴史的事例のマッチングがキーワード依存で召回漏れしやすい：新旧の変更では表現が異なる場合があり、同義語のマッチングが困難です。
3. 4 種類の方針内容の番号対応関係を保証することが困難：設計方針 → 設計方法 → 評価方法 → 懸念点 は番号による対応が必要であり、人手ではミスマッチが生じやすいです。
4. 多言語と自動車専門用語の理解偏差：変更記述には中国語、日本語、英語、略語、コードが混在する可能性があります。
5. Block 図影響分析がシステムアーキテクチャ知識に依存：ダッシュボードのデュアルチップアーキテクチャでは、影響判断は機能モジュール内の処理ユニットに及びます。
6. Drawio XML の人手修正はエラーが生じやすい：各コンポーネントは 1 つの mxCell に対応しており、人手では cell_id の特定と style の更新が必要です。

ソリューションと技術実装パス

1. 変更点の受け取りと言語統一処理：必須入力は changing_point であり、非中国語入力は知識検索用に中国語に変換し、出力はユーザーの元の言語を維持します。
2. 歴史的知識から関連設計を検索：knowledge.json から最も関連性の高い 3 件の設計参照を取得します。パスは キーワード抽出 → Neo4j CONTAINS/BM25 → Top-3 で、n-gram マッチングにフォールバックします。
3. 構造化された設計評価方針の生成：自動車電子設計専門家プロンプトを使用し、設計方針、懸念点、設計方法、評価方法、ナレッジベース参照項目の 5 部分を固定して含め、4 種類の内容を番号で一対一に対応付けます。
4. システムアーキテクチャ知識の読み取りとコンポーネント位置特定：knowledge.md と基礎 .drawio を読み取り、コンポーネントごとに影響範囲を判断し、 modified / affected / new / deleted / reset の変更タイプを識別します。
5. Block 図のスクリプト化更新：changes.json を生成し、apply_styles.py が基礎ファイルをコピーし、スタイルを更新するか新規コンポーネントを挿入して保存します。
6. 変更タイプによるコンポーネントの統一マーキング：modified（赤枠）、affected（青枠）、new（黄色太枠）、deleted（灰色透明破線）、reset（デフォルトに戻す）。

特長

• 設計評価方針と Block 図が同じビジネスチェーンで生成：1 つの入力から Markdown 方針ファイルと注釈付き Drawio ファイルを同時に取得できます。
• 歴史的知識ドリブン：knowledge.json の歴史的設計記録を背景として使用します。
• 細粒度コンポーネント分類：モジュールだけでなく、Drawio 内の具体的な処理ユニットにまで踏み込んで確認します。
• 多言語交付ルールの明確化：中国語、英語、日本語のテンプレート構造を一貫させます。

商業的価値

• 設計評価方針は変更点 1 件あたり約 0.5～3 日、Block 図変更分析は 1 回あたり約 0.5～3 日かかりますが、自動化後は分単位での処理が期待され、直接的な人件費が 80%+ 削減されます。
• knowledge.json / knowledge.md が上級アーキテクトの経験を検索可能な資産として蓄積します。
• 統一された番号対応関係と固定のコンポーネント分類により、人手による編集ミスを減らします。
• apply_styles.py が XML を自動修正し、人手による編集誤差を低減します。

---