高まる「コードファースト」への期待、そこに落とし穴はないのか：AUTOSARを使いこなす（39）（3/3 ページ）

[櫻井剛，MONOist]

（3）動くコードによって、要件がその基となった要求を適切かつ効率的にかなえていることを、いち早く確認したい

　動くコードで、いち早く、要件がその基となった要求を適切かつ効率的にかなえていることの確認、つまり、「妥当性確認／validation」をやってしまいたい、ということになるかと思います。

　また、Automotive SPICEやISO 26262などで示された論理的な作業の流れの観点（図2）からすると、前項（2）で示したものに加え、以下のような弱点が見えてきます。

• 要件定義：そもそも、ステークホルダーからの要求を十分に集めることができているのか（要求だけではなく、ステークホルダーそのものも十分に集まっているのか）、要件化する際の選択肢が他にもあるのではないか（先の「さまざまな選択肢からの選択」をスキップしているので、ひょっとしたら、より効率のよい実現につながる要件の形を見落としているかもしれません……etc.）

（4）ソフトウェア開発者に、コード開発に専念させたい（コード開発以外の「やりたくないこと」をさせない）

　これまでに見てきたものとはちょっと切り口が変わります。

　ある意味ソフトウェア開発者のwell-beingの改善のために、コード開発に専念させたい／専念したい、という意図も見え隠れしています。

　ただ、仮にいきなりコードを書くのだとすると、以下の上位成果物なしで始まることになります。

• （場合によっては）プロジェクト憲章（競合解決の共通指針などを含む）、プロジェクト固有にテーラリングされたプロセスやルール
• ステークホルダー要求
• プロジェクト／システム要件
• アーキテクチャ設計（ブレークダウン戦略や、リソース／タイミング／安全／セキュリティ面などの各種アーキテクチャ分析を反映したもの）
• 単体ソフトウェアの詳細設計

　ただ、「ソフトウェア開発者に、コード開発に専念させたい」というのであれば、他で上記上位成果物を作ればよいと考えることもできます。

　しかしながら、順序入れ替えが生じますので、以下のような懸念はあります。

• 各種アーキテクチャ分析の一つとして安全に関する分析を行わなければ、高い確率でアーキテクチャ設計の見直しを後に行うことになるでしょうし、変更規模を最小限にしようとして、無理のある／筋の悪い設計変更が行われやすくなったりしないでしょうか？
• そもそも、プロセスアプローチによって「人的ミス」を抑制／検出する、ということが、果たして機能するのでしょうか？

（5）全てをコードの形で表現したい

　LLM（大規模言語モデル）ベースのAI（人工知能）によるコード生成は急速に利用が進んでいます。

　ただ、AIにそれをさせようとするのであれば学習データが必要になります。

　そのために、各種データをできるだけコード（というよりもテキストベースの表現）に置き換えようとする動きも出てきています。

　ぱっと見たところ、損なわれ得る具体的なものはまだ思い当たりませんでしたが、そもそもAI利活用に関する社会的受容性が確立されているとまでは言えない部分もあります^※3）。

　おそらくですが、「対価の評価」という点では、俳優や作家の世界で起きたのと同様の問題が、遅かれ早かれ起きるのではないかと考えています。

　また、たまたま執筆中にもニュースで取り上げられていましたが、AI利用に伴う電力消費（そして、気候への影響）が今後さらに問題になっていくとしたら、どの用途でAIを使ってよいのか（社会資源の割り当て問題）、あるいは、何らかの負担（税金？）なんて話にもなるかもしれませんね。

※3）余談ですが、2025年10月に自動車技術会のエシカルエンジニア開発委員会の委員に正式に就任しました（関連サイト：自動車技術会のエシカル・エンジニア開発講座）。

不安？　それならコントリビューションを！

　コードファーストアプローチに何を期待するのか、そして、それを実際にやってみようとしたらどのような懸念があるのか、徐々に見えてきたように思いますが、いかがでしょうか？

　何を得るためにどんな犠牲を負うのか、先に書きましたが、工学／開発は、競合解決を含む意思決定の連続です。そして、各所で行われる競合解決に一貫性がなかったら、インテグレーション時に新たな競合が生じる可能性がありますし、ひょっとしたら、社会への投入／実装／デプロイメントの後に社会受容性の面が問題になるかもしれません。結果は「手痛い手戻り」です。

　そして、コードファーストで生み出されたものを利用する際には、上記懸念が、全てではないにせよ、利用する側にも降りかかってきます。

　CAPIなどでの開発の成果を利用するということであれば、コードファーストという言葉の裏で、「どのような意図で」「どのように進められてきたのか（何が対処され、何が残るのか）」を把握しておかなければ、リスクがより大きくなってしまうことはお分かりだと思います。

　生み出されたコードや設計書、そしてそれらを生み出すプロセスなどには、それらが示されているとは限りません。

　不安をお持ちになりましたか？　それなら開発コミュニティーへのご参加（コントリビューション）をご検討ください。

　AUTOSARやその一部であるCAPIに限りません、オープンソースでも同様です。

　コミュニティーによって生み出させるものを利用する上で、コントリビューションすることを通じた「理解」は、リスク低減手段にもなるのです。

次回に続く

　次回は、R25-11の変更内容のご紹介になるかと思います。

　本当はまだまだたくさん書きたいことがございますが（例えば、「非競争領域」という言葉の弊害など）、AUTOSAR研修資料の大型アップデートなども進めている都合で時間が取りにくいため、またの機会とさせてください。

　なお、AUTOSAR Japan HubとしてUG-ET（User Group Education and Training）の日本ローカル活動を立ち上げることとしましたが、今のところ参加のお申し出は少数です。

　ご興味ある方は筆者の櫻井宛（メールアドレス：[e-mail]、＠は全角文字になっているので半角文字に変更してください）までご連絡ください。なお、参加者数次第では、成果物公表が難しくなる可能性もございます。

筆者プロフィール

櫻井 剛（さくらい つよし）イーソル株式会社 ビジネスマネジメント本部 Solution Architect & Safety/AUTOSAR Senior Expert／AUTOSAR日本事務局（Japan Hub）

自動車分野のECU開発やそのソフトウェアプラットフォーム開発／導入支援に20年以上従事。現在は、システム安全（機能安全、サイバーセキュリティ含む）とAUTOSARを柱とした現場支援活動や研修サービス提供が中心（導入から量産開発、プロセス改善、理論面まで幅広く）。標準化活動にも積極的に参加（JASPAR AUTOSAR標準化WG副主査、AUTOSAR文書執筆責任者の一人）。2024年よりAUTOSAR日本事務局（Japan Hub）も担当。