【要約】Garmin Running Data Normalizerを支えたAI協働開発 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がOSS開発を行う際、単一のAIに全工程を委ねることで、品質低下や情報の乖離を招く問題に直面した。AIは文脈を保持する一方で、初期の誤った前提を後工程まで引きずる性質がある。また、AIが実装状況を過度に一般化し、未実装の機能を「実装済み」と誤認するリスクも存在する。
- ・AIによる初期前提や誤った表現の継続的な引きずり。
- ・実装状況の過度な一般化による、未実装機能の「実装済み」誤認。
- ・表面的な症状の修正に留まり、根本原因の特定が疎かになるリスク。
// Approach
開発者は、AIに全工程を任せるのではなく、工程ごとに役割を分担し、人間が最終判断を行う体制を構築した。AIの回答を鵜呑みにせず、リポジトリやテスト等の「正本」と照合するプロセスを導入している。これにより、AIの誤認を構造的に排除する。
- ・工程ごとにAIの役割を定義（ChatGPTで設計、Codexで実装、Claude等でレビュー）。
- ・AIの回答を、リポジトリ、公開契約、テスト、エビデンスへ厳格に照合する。
- ・利用者が仕様の採用や公開の可否を最終決定する「Authority」の設計。
- ・実装、レビュー、再検証のサイクルを回し、公開範囲を段階的に固める。
// Result
この協働体制により、Garminデータの正規化OSSにおいて、高い品質と信頼性を備えた成果物が得られた。AIの誤認を検知し、ドキュメントの不整合やOS依存の深いバグを解消することに成功した。
- ・実行基盤、データ設計、継続運用、品質管理における複数の成果物の獲得。
- ・ドキュメントとリリース実態の不整合解消および、Windows環境の根本的な不具合修正。
- ・AI協働の知見を体系化した「AI Collaboration Platform」への展開。
Senior Engineer Insight
> AIを「コード生成器」ではなく「工程ごとのエージェント」として扱う視点が極めて実践的だ。重要なのはAIの数ではなく、照合すべき「正本（Contract/Evidence）」の定義である。この設計が不十分だと、AIの誤認を検知できず、技術負債を加速させる。運用コストは増えるが、信頼性の高いOSS開発には不可欠なアプローチといえる。