AIエージェントの急進化と開発現場に起きている変化
セッションの冒頭、株式会社本田技術研究所 SDV研究開発センター デジタルエンジン開発室 AI開発ブロック マネージャーの田中英之氏が登壇し、エンジニアを取り巻く環境の急激な変化について言及した。
2022年11月に登場したChatGPTは、わずか5日間で100万ユーザーを獲得し、今や毎週9億人が利用する巨大インフラへと成長した。しかし当時の使い方は、困りごとに対して人間がAIと対話する補助的な範囲にとどまっていた。その後、2023年から2024年にかけてCopilotをはじめとする支援ツールへと拡張し、2025年以降はClaude Codeや各種AIエージェントのように、指示を与えれば自律的に調査や実装、テストまで遂行する「AIに任せる」時代へと突入している。
田中氏は「もはや採用面接などで『何行のプログラムを書いたのか』を聞く時代ではなくなった。プログラムの自動生成が当たり前になる中で、コードを書く手作業そのものの価値は変化し、生成されたアウトプットを正しくチェックして安全性を監視する仕組みや人の存在が不可欠になっている」と、開発現場の変化を振り返る。
ツールが進化し、自律的なエージェントが複雑なタスクをこなすようになる一方で、ガバナンスや安全性の問題も顕在化している。便利さが増すほど、人間が管理すべき境界は外側へと拡張していく。田中氏は、これからのエンジニアには進化するAIを正しく評価し、時には監視・抑制できるだけの専門性と視点が求められていると語った。
自動車は「究極のフィジカルAI」──スピード競争の裏にある落とし穴
なぜ今、大手自動車メーカーであるHondaがこれほどまでにAI駆動開発に傾注しているのか。田中氏は「自動車こそが究極のフィジカルAIだからだ」と説明する。
現代の自動車は、多数のカメラやミリ波レーダー、超音波センサーといった知覚系デバイスと、ハンドル、アクセル、ブレーキといった制御系アクチュエーターを備えた巨大な精密機械である。画面上のテキストや画像を扱う「静的なAI」の時代を経て、認知AI、生成AI、AIエージェントが統合され、現実世界を物理的に動かす「フィジカルAI」の領域において、自動車はその最大の主戦場となっている。年間約1億台、市場規模にして約450兆円におよぶ巨大な自動車市場は、AI技術のビジネス化と投資回収においてきわめて重要なターゲットだ。
特に中国市場をはじめとするグローバルな自動車開発の現場では、国を挙げた支援を背景にAI機能の進化・実装・公開サイクルが驚異的なスピードで回っている。国内製造業も「このスピード感に追いつかなければ生き残れない」という強い危機感とプレッシャーの中に置かれており、生成AIとAIエージェントを組み合わせた開発速度の引き上げは避けて通れない命題となっている。
しかし、自動車開発において「作るスピード」だけを追求することには重大な危険が潜む。田中氏は、車載アシスタント機能に関する検証実験での失敗例を明かした。
田中氏は「通常の質問に対してAIは9割以上の確率で正しく有用な回答を出す。しかし、残り数％の確率で発生するハルシネーションや安全上の誤りを見抜き、確実にガードレールをかけるためには、ドメイン知識を持った人間のエンジニアによる評価と判断が不可欠だ。AIの活用により試作やコード生成は圧倒的に早くなったが、安全性の判断、責任ある仕様決定、リリース可否の改善方針づくりといった『人間が判断する仕事』はむしろ密度が増している。スピードが上がった結果、エンジニアの仕事量は減るどころか増えているのが現実だ」と指摘する。
車載ソフト開発を阻む「巨大複雑化」の現実
続いて、株式会社本田技術研究所 SDV研究開発センタースマートキャビン開発室 開発改革ブロック スタッフエンジニアの齋藤優介氏が登壇した。カーナビやメーター、オーディオなどの車載情報機器システムであるIVI（In-Vehicle Infotainment）の開発現場において、AI駆動開発をどのように組織・プロセスへ組み込んでいるかを語った。
HondaのIVIソフトウェアは、Googleが提供するAAOS（Android Automotive OS：車載向けに統合・拡張されたAndroid OS）をベースに構築されている。これはスマートフォンのAndroidと同一のコードベースに車載向けの各種拡張を加えたものであり、その上層にHonda独自のアプリケーションやインターフェースを載せて製品化している。
IVIソフトウェアの特徴は、巨大かつ極めて複雑な開発体制にある。IVI単体のコード規模だけで数百万行におよび、土台となるAOSP（Android Open Source Project）全体を含めるとさらに数桁大きい世界となる。この膨大なソースコードを単一の企業で開発することは不可能だ。そのためGoogle、SoC（System on a Chip：主要機能を1チップに集約した半導体）ベンダー、ハイパーバイザー（仮想化ソフトウェア）ベンダー、Tier1サプライヤー、ソフトウェアベンダーなど、複数社が領域を重複させながら複雑に連携して開発を担当している。
このような巨大な組み込みソフトウェア開発において、「AIツールを導入すれば開発全体が手放しで速くなるのか」という疑問に対し、齋藤氏は「個別作業そのものは確かに速くなるが、それだけでは車載開発の全体速度向上にはつながらない」と断言する。その理由は、車載開発特有の厳格な品質保証構造にあるからだ。
車載ソフトウェアでは、単に「動くコードがある」というだけでは製品として車両に搭載できない。複数社で品質を担保し、どのようなプロセスで正しく作られたかを第三者に客観的に示すため、「Automotive SPICE」に基づくプロセス審査をクリアすることが必須条件となる。
システム要求分析から基本設計、詳細設計、実装へ至り、単体検証、結合テスト、システムテストへと上がっていく「V字モデル」の開発プロセスを厳格に順守し、各工程で生成される仕様書、設計書、テスト結果といった中間成果物同士が正しくリンクしていること（工程間トレーサビリティ）を証明しなければならない。
AIツールの個別導入が直面した「3つの壁」
開発プロセス全体を加速させるべく、HondaのIVI開発現場でもV字モデルの各工程に対して個別にAIツールの適用が試みられた。しかし、従来の開発手法やドキュメント構造のままAIを導入した結果、3つの大きな構造的課題（壁）に直面することとなった。齋藤氏はその壁を次のように分析する。
第一に「トレーサビリティの壁」である。AIを活用することで特定の関数やモジュールのソースコード自体は瞬時に作成できるようになった。しかし、そのコードがどの要求仕様に対応し、どのテストケースで検証されるべきかという「工程間の紐付け」作業は、依然として人間の手作業として残されてしまった。
第二に「同期更新の壁」である。仕様変更や不具合修正が発生した際、コードを書き換えるだけでなく、上位の要求仕様書から詳細設計書、テスト仕様書に至るまで、関連する複数工程の中間成果物を整合性を保ったまま更新しなければならない。この複数成果物の同期作業も人手に頼っていたため、コード生成のスピードにドキュメント追従が追いつかないという問題が発生した。
第三に「データ可読性の壁」である。従来の仕様書や設計書は、人間が読むことを前提として作成されていた。そのため、Excelの複雑なレイアウトやConfluenceの自由記述ページなど形式が統一されておらず、さらにHonda内部とサプライヤー企業の間で分散して保管されていた。結果として、AIにコンテキストを参照させようとしても、全体を横断的に読み込ませることができない構造になっていた。
齋藤氏は「リンクの自動付与、中間成果物の自動同期、探しやすいデータ土台の構築。これら3つを根本から解決しない限り、いくら個別の工程に優秀なAIツールを投入しても、開発全体を加速させることは不可能だ」と語った。
開発プロセスは変えず担い手を変える「AI-Native」構想
構造的課題を打破するためにHondaが提示した解が、開発組織のあり方を根本から再定義する「AI-Native」構想である。
「AI-Native」の最大のポイントは、自動車業界で長年培われてきたAutomotive SPICEやV字モデルといった開発プロセスのフレームワークや成果物の定義そのものは変えないという点にある。車載品質を守るための厳格な枠組みは維持したまま、成果物を「誰が作るのか」という担い手を人間からAIへと全面的に入れ替えるのだ。
この構想を実現するため、まず基盤として全工程の成果物やマスターデータを一元的に集約するナレッジ基盤「SSoT（Single Source of Truth：信頼できる唯一の情報源）」を構築する。各工程における仕様書や設計書、テストケースの作成といった作業はすべてAIエージェントが担当し、SSoTを参照しながら自律的に成果物を生成してアップロードする。
では、人間のエンジニアはどのような役割を担うのか。人間は自らドキュメントやコードを書く手作業から解放され、AIが生成した成果物が妥当であるかを検証し、工程ごとのPassingを判断する「承認ゲート（Gatekeeper）」の役割に専念する。人間が承認ゲートを通過させると、そのシグナルを受けて次工程のAIエージェントが自動的に起動し、V字モデル全体が一本の統合されたパイプラインとして自律的に流れていく仕組みだ。
組織におけるAI活用フェーズの進展について、齋藤氏は次の3段階で整理している。
- AI-Assisted（現在の多くの現場）：人間が主たる作業者であり、AIを利便性の高い「道具」として部分的に利用している状態。
- AI-Native（Hondaが現在目指す姿）：AIが各種成果物の作成を主体的に行い、人間は成果物の妥当性を評価・承認するゲート役に回る状態。
- AI-Managed（将来的な理想像）：人間の関与を最小限に抑え、AIがパイプライン全体を一貫して自律制御・運用する状態。
さらに齋藤氏は「便利ツールとして各個人に自由にAIを使わせるスタイルでは、活用レベルの個人差が生まれ、組織全体の開発能力向上には結びつかない。誰もが必ず通る開発プロセスやCI/CDの仕組みの中に、最初からAIを不可分な構成要素として組み込むことが極めて重要だ」と力説した。
仕様書のAI可読化が生んだ成果
HondaのIVI開発現場では、この「AI-Native」構想に向けた具体的施策がすでに着々と進行している。齋藤氏は、先述した「3つの壁」に対応する施策の現在地と具体的な成果を明かした。
まず「データの壁」に対する施策として進行しているのが「仕様書のAI可読化（AI-Readable化）」である。従来ExcelやWordなどで作成されていた膨大な仕様書や設計書を、Markdown、YAML、Mermaidといった、AIが容易に構造を理解・編集できるフォーマットへと変換し、SSoTマスターデータとして再構築している。
このAI可読化された仕様データを活用することで、すでに現場では以下のAIエージェントが稼働し、劇的な工数削減を実現している。
- 仕様書QAエージェント：SSoTに集約された最新仕様をAIが探索し、他部署からの仕様問い合わせに対して根拠となるドキュメント名や該当箇所を明示した上で即座に回答する。ハルシネーションの発生を抑えつつ、問い合わせ対応時間を大幅に縮小させた。
- 不具合解析エージェント：市場やテストで発生した不具合ログを解析する際、AIがSSoT内の関連仕様書を自律的に参照・照合することで、原因箇所の特定精度が飛躍的に向上。解析時間を大幅に削減することに成功した。
次に「トレーサビリティおよび同期の壁」に対する施策として推進されているのが「ナレッジへのCI品質ゲートの構築」である。
ソースコードのビルドテストと同様に、ドキュメントや設計成果物に対してもCIパイプラインによる自動検査メカニズムを導入した。AIが作成した仕様書やテストケースに対し、要求IDとの紐付け漏れ、用語の表記揺れ、形式的な矛盾といった誤りをCIゲートが機械的にチェックして弾く。これにより、人間がレビュー時に誤字脱字や形式チェックに時間を奪われることがなくなり、「この仕様は車載プロダクトとして本当に妥当か」「設計思想に無理はないか」という高度な本質的判断だけに集中できる環境が整いつつある。
一方で、現状の課題として齋藤氏は「ドキュメント化されていない暗黙知のSSoT化」と「V字全体を全自動で貫くパイプラインの構築」の2点を挙げる。ベテランエンジニアの頭の中にしかないノウハウや過去のトラブル対応履歴をいかにAIとの対話を通じてテキスト化し、SSoTに取り込んでいくか。商用開発の現場において、個別の工程で成果を上げているAIエージェントをいかに一貫したパイプラインとしてつなぎ合わせるかが次なる挑戦となる。
オープンソースのSDVリファレンスプラットフォーム「SoDeV」のRPi4/5移植事例
セッションの後半では、株式会社本田技術研究所 SDV研究開発センター SDV開発改革室 開発推進イニシアティブ＆アーキテクトブロック チーフアーキテクトの日下部雄一氏が登壇した。国際的なオープンソースソフトウェアコミュニティの最前線において、生成AIをどのようにフル活用しているか、具体的な定量データとともに発表した。
日下部氏は、車載Linuxの標準化団体であるAutomotive Grade Linuxにおいて、Linux Foundation傘下の主要OSSプロジェクトを統合したSDV向けリファレンスプラットフォーム「SoDeV（Software Defined Vehicle Reference Platform）」の開発を、パナソニック オートモーティブシステムズやトヨタ自動車らとともに主導している。
SoDeVは、ハードウェアの制約からソフトウェア開発を切り離し、クラウドや異なるSoC環境上で同一の車載ソフトウェアスタックを動作させるための共通基盤であり、ソースコードはGitHub上で完全公開されている。
今回、日下部氏が取り組んだのは、Renesasの車載用SoC「R-Car V4H」向けに構築されていたSoDeVのソフトウェアスタック全体を、シングルボードコンピューターとして汎用的に入手可能な「Raspberry Pi 4/5（RPi4/5）」へと全面移植するプロジェクトだ。
この移植作業は、単なるWebアプリケーションの移植とは比較にならないほど難易度が高い。Type-1ハイパーバイザーであるXenの移植、Zephyr RTOS（リアルタイムOS）による制御ドメインの構築、VirtIO（仮想化環境における標準I/Oインターフェース）を介したGPUグラフィックス共有、AndroidおよびAGL Linuxの仮想マシン上での同時動作、ブートローダーの調整など、組み込みソフトウェアの最深部におよぶ極めて広範な技術領域を網羅する必要があるためだ。日下部氏は、この極めて難度の高い移植プロジェクトを生成AIを全面的に活用して遂行した。
AI活用で工数最大7倍削減の裏側と現場で判明したリアルな課題
生成AIを組み込み開発の最深部に投入した結果、どのような成果が得られたのか。日下部氏は、実測値に基づく定量的成果を具体的に明かした。
従来の手作業でこの移植を行う場合、ハイパーバイザー、組み込みLinux、Android／AAOS、GPU、グラフィックスという5つの異なる専門領域を持つ熟練エンジニア4〜5名によるチームを組み、約4か月〜6か月（中央値で約190人日、範囲にして約150人日〜245人日）の期間を要する規模のタスクであった。
しかし、熟練エンジニアである日下部氏1名が生成AIを高度なパートナーとして並行稼働させることで、わずか6週間（約30人日〜40人日）の期間で移植を完了させた。追跡したタスク約200件をほぼすべて完了させ、本人によるコミット数86本、XenおよびZephyrのパッチ群90本、技術文書28本を作成した。工数および開発期間ともに、従来比で約4倍〜7倍という劇的な削減と生産性向上を達成したのである。
日下部氏は「手作業ならコードの探索や読解に数時間を要する調査タスクを、AIエージェントを3体並列で走らせることで数分で完了できた。特にドキュメント28本の起草や、C言語のパッチ作成において圧倒的な威力を発揮した」と振り返る。
しかし、日下部氏はこの劇的な成果を提示しつつも「AIを過大評価してはならない」として、現場で直面したリアルな課題と注意点を率直に共有した。
第一に「レビュー負荷の爆発と人間の責任帰属」である。LinuxカーネルなどのOSSコミュニティでは、AIが作成したコードであってもDCO（Developer Certificate of Origin）による署名は人間が行う必要があり、バグや脆弱性に対する最終責任は投稿した人間に帰属する。AIは大量のパッチやドキュメントを極めて高速に出力するが、不適切な設定によるブートループなどの誤診断も発生するため、人間がその全件を精査・レビューする負担は重い。
第二に「厳格なガバナンスとコンフィグレーションの必要性」である。権限を与えたAIエージェントに指示ルールを正しく与えずに自由に操作させると、ビルド環境のディレクトリやマウントポイントを短時間で乱雑に汚染してしまう。どこまでの操作を許可し、何を禁止するかという「ガードレールの設定」を慎重に組み上げる必要がある。
第三に「人間の高度なドメイン知識との合算効果」である。日下部氏は「今回の成果はAI単体が生み出したものではない。私自身が長年培ってきた仮想化やカーネルに関する専門知識、既存の参照コード資産、そしてAIの高速な探索・提案能力が掛け合わさった合算効果だ。専門知識のない人がAIツールだけを使っても、このような複雑な移植を完遂することは現在のAI性能では不可能だ」と強調した。
AI時代におけるエンジニアの3つの役割
セッションの締めくくりとして「これからのAI時代にエンジニアと組織が取り組むべき3つの行動指針」が整理された。
第一に「道具として配る」アプローチから「AIが動ける構造を作る」アプローチへの転換である。単に個人のエンジニアにAIツールを配り、個々の作業効率化に依存する手法には限界がある。組織としてのボトルネックを解消するためには、仕様や設計成果物をAI可読な形式でSSoTに集約し、CIによる品質ゲートと自動承認パイプラインを整えること、すなわち「AIが自律的に動ける開発基盤を設計・構築すること」こそがエンジニアの最優先タスクとなる。
第二に「コードを書く手」から「妥当性と安全性を評価・判断する目」への軸足のシフトである。AIによってコード生成や試作のスピードがどれほど加速しようとも、提示されたアウトプットが製品として安全か、ハルシネーションによるリスクがないかを最終判断できるのは、ドメイン知識を持った人間のエンジニアだけだ。エンジニアは「コードを書く作業者」から「評価・判断・安全保証の責任者」へと自らの役割を認識変更しなければならない。
第三に、人間とAIの協働におけるガバナンスとルールの厳格化である。OSSコミュニティにおける著作権・責任の明確化や、AIエージェントに対するファイル操作権限の制限など、AIをチームの「信頼できる構成員」として安全に組み込むためのガバナンス設計を怠ってはならない。ルールなきAI導入は、環境の乱濁やセキュリティリスクの増大を招く。
AIがコードを「速く作れる」ようになった時代だからこそ、システム全体のアーキテクチャを描き、安全と品質を守り、AIが走るための構造をデザインする「人間エンジニアの仕事」の価値は、これまで以上に高まっている。
本田技研工業株式会社からのお知らせ
本田技研工業では、エンジニアの仲間を募集しています。開発環境やカルチャー、現在募集中のポジションなど、詳しくは採用情報ページをご覧ください。
