【要約】生成AIデバッグアシスタント「aidbg」— 手順書を差し替えればどんな検証にも、設計か検証環境かを切り分ける [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
SoC検証の現場において、エンジニアは不具合の原因が設計（Design）にあるのか、検証環境（Verification-env）にあるのかを特定するために膨大な時間を費やしている。\n・不具合の切り分け作業が属人的であり、解析に多大な工数がかかる。\n・従来のツールでは判断ロジックをPythonコードで実装する必要があり、新しい検証ドメインへの適応が困難であった。\n・大規模な波形データやログをLLMに直接入力することは、トークン制限等の制約から困難である。
// Approach
開発者は、判断ロジックをコードから「手順書」へと分離する3層アーキテクチャを採用した。\n・toolbox: エージェントが事実を取得するための、read-onlyなプリミティブ（
aidbg query, blame等）を提供する。\n・profile: ペルソナやレポート様式、使用する手順書を定義し、主戦場を切り替える。\n・skills: Markdown形式で記述されたドメイン知識（手順書）により、LLMに調査手順と判断基準を指示する。\n・LLMは、提供された道具を用いて事実を集め、手順書に従って「設計か検証環境か」を推論する。// Result
開発者は、低性能なLLMであっても手順書を用いることで、複雑なデバッグタスクを遂行できることを実証した。\n・APBレジスタのread不一致において、手順書なしでは誤判定していた無料モデルが、手順書適用により設計と検証環境を正しく判別した。\n・「設計か検証環境か」の切り分けを、git blameを用いたコミット特定まで含めて自動化できる。\n・今後は、高水準なプリミティブの拡充や、外部手順書パックの配布を目指している。
Senior Engineer Insight
> 本アーキテクチャの白眉は、知能（LLM）と知識（Markdown）を分離した点にある。判断ロジックをコードではなく手順書に寄せた設計は、検証ドメインの変遷が激しい半導体業界において極めてスケーラブルだ。また、read-onlyなプリミティブに徹することで、検証環境の整合性を担保している点も実戦的である。低コストなモデルでも手順書で精度を底上げできる点は、運用コスト抑制の観点からも高く評価できる。