はじめに
Claude Code や Codex みたいな AI コーディングエージェントを使っていると、コードを書くこと自体はどんどん楽になってきました。一方で、少し時間が経ったコードを見返したときに「これ、なんで作ったんだっけ」「どの要求と関係してる？」「どのテストで守られてるんだっけ」がパッと出てこない場面も増えています。
自分で手を動かしていたときは、書いた記憶と一緒に「なぜ」も残っていましたが、AI に任せる量が増えると、その「なぜ」が抜け落ちやすい。この課題を考えるうえで、自動車業界の開発プロセスが参考になりそうです。
この記事は、AI 時代の課題を「コードを作ること」よりも「成果物同士の関係性を把握すること」と捉え、自動車業界の ASPICE や最近の AI Agent の流れと重ねて整理するメモです。
全体像
この記事で扱うのは、AI がコード、テスト、設計書を生成できるようになるほど、要求・設計・実装・テストのつながりが重要になる、という話です。自動車業界では以前からこの関係性を強く管理してきました。Web や業務システムの開発でも、AI に正しい文脈を渡すための基盤として、似た考え方の価値が上がっていくと考えています。
何に困っているのか
AI がコードもテストも設計書も生成するようになると、成果物の量はどんどん増えます。増えること自体はいいのですが、それぞれが「なぜこの機能を作ったのか」「どの要求から生成されたのか」「どのテストで保証されているのか」という関係性を保ったまま増えてくれるとは限りません。
そのため、AI 時代の課題は
生成された成果物同士の関係性を把握すること
だと考えています。
自動車業界はなぜそこまで管理するのか
自動車業界では、ソフトウェアの不具合が事故やリコールに直結します。なので「動くソフトウェアができました」だけでは足りず、要求・設計・実装・テストがどうつながっているかを追跡できることが求められます。
要求
↕
設計
↕
実装
↕
テスト
要求が変わったときに、どの設計へ影響し、どのコードを直し、どのテストを見直す必要があるのかをたどれないと、安全性や品質を保てない。この考え方を支えているのが Automotive SPICE（ASPICE）です。
ASPICE は「自動車ソフト開発のプロセス成熟度を評価するフレームワーク」として知られていますが、現場で効いているのは成熟度の点数そのものよりも、
要求からテストまでの成果物の関係性を維持すること
の方だと理解しています。実際、トレーサビリティは自動車ソフトウェア開発の重要な活動で、多くの規格や開発プロセスの基盤になっているそうです。 (arXiv)
AI は ASPICE を不要にしていない
自動車ソフト品質に AI Agent を使う議論では、要求分析、テスト生成、トレーサビリティ管理などが対象になっています。 (LinkedIn)
AI が扱っているのは、ASPICE が以前から対象にしてきた要求、設計、実装、テストといった成果物です。
要求
↓
設計
↓
実装
↓
テスト
要求から設計、実装、テストへ進む流れ自体は変わらない。変わるのは、その成果物を人間だけでなく AI も生成するようになる、という点です。
品質の中心はトレーサビリティ
Walid Negm 氏の「Reinventing Automotive Software Quality with AI Agents」という記事では、自動車ソフト品質の基盤として最初に End-to-end Traceability が挙げられていました。記事の中では、Traceability Agent、Requirements Analysis Agent、Test Generation Agent といった役割も提案されています。 (LinkedIn)
ここで注目されているのは、
コードを生成する AI
だけじゃなくて、
要求と設計、設計とテスト、テストとリリースを結びつける AI
の方だと捉えました。
AI が実装を速くすればするほど、このコードはどの要求から生まれたのか、このテストは何を保証しているのか、この変更はどこに影響するのかを把握する重要性はむしろ上がる。冒頭の自分の困りごとと、そのまま重なります。
最近の研究でも、要求分析・設計・テスト生成・トレーサビリティ管理を複数の AI エージェントでやろうという動きがあって、共通の知識グラフで成果物同士の関係性を維持するのが大事だ、と指摘されているようです。 (arXiv)
これは自動車業界だけの話じゃなさそう
同じ流れは Web 業界でも見え始めています。Atlassian は「Teamwork Graph」を、チーム、作業、アプリをつなぐデータ層として位置づけ、その上で Rovo の検索、チャット、Agent を展開しています。 (Atlassian)
業界は違っても、課題の形はよく似ています。
AI が優秀になるほど、
Intent
↓
Requirement
↓
AI
↓
Code
という流れの上流にある情報が効いてくる。最近の AI エージェント開発の話でも、単純なチケット駆動ではなく、仕様やアーキテクチャ、システム全体の文脈を明示することの重要性が語られています。 (LinkedIn)
AI 時代に価値が上がりそうなもの
AI はコード生成が得意です。ただ、なぜその機能が存在するのか、どの要求を満たしているのか、どのテストで保証されているのかを継続的に維持するのは、相変わらず人間、あるいはそれを束ねる仕組みの仕事として残りそうです。
これまで監査や品質保証のための仕組みとして扱われてきた
- 要求管理
- トレーサビリティ
- アーキテクチャ
- 変更管理
が、AI エージェントに正しいコンテキストを与えるための基盤に変わりつつあるのだと思います。
まだ自信がないところ
ただ正直、Webと言われる業界で、どこまでトレーサビリティを意識すべきかは未知数ですし、ASPICE の重さをそのまま持ち込むのはやりすぎだと思います。「知識グラフで関係性を維持」も、言うのは簡単ですが運用は別問題です。
なので、この記事は「自動車業界のやり方をそのまま真似しよう」ではなく、「考え方の先行事例として見ると学びがある」くらいのスタンスがよいかなと思ってます。
おわりに
AI によってコード生成はどんどん楽になります。ただ、成果物が増えれば増えるほど、それがなぜ存在するのか、何とつながっているのか、何を変更すると影響を受けるのかを把握する必要が出てきます。これは AI が速くなるほど重要になります。
自動車業界は、この課題と以前から向き合ってきた業界です。ASPICE は、AI が大量の成果物を生み出す時代に、
成果物同士の関係性をどう維持し、どう活用するか
を考えるための先行事例として見られると思います。
変化の速いAIコーディング開発で、これらをどれくらい重要視すべきか、似たことを考えている人や実務での違う見方があれば、ぜひコメントなどで教えてください。