Zephyr Safetyを追いかけてみた： WG参加とRequirement貢献に挑戦

Zephyr Project Meetup: Sapporo, Japan 2026で発表した時の資料

Transcript

1. Zephyr Safetyを追いかけてみた： WG参加とRequirement貢献に挑戦 黒川晴申 @harunobukurokawa (github) @kuro496 (X.com) Zephyr Project Meetup: Sapporo, Japan 2026
2. 自己紹介 黒川晴申/Harunobu Kurokawa 半導体企業のSWエンジニア（自称） 自動車関連のOSS界隈に出没 コーディング << マネージャ Zephyr勉強のために 個人で購入したボード群 → 海外から発送。。。
3. • Zephyr ProjectにおけるSafety取り組みを知ってもらう ◦ 調べたこと、参加して感じたことの共有 ◦ 何をターゲットにしてる？どんなことやってる？ • 私がPR投げるまでのストーリー ◦ AIの力を借りてやってみた ◦ 日本からの参加者が増えてほしい ◦ 難しいと感じるか、出来そうと思ってもらえるか • ご注意・対象外 ◦ セーフティの経験がないので間違いがあるかもしれません ◦ Functional Safetyそのものについては取り扱わない ◦ AIの活用についてはSafety WGで同意済み 今日のおはなしと目的
4. Zephyr Safety
5. OSS コミュニティでSafetyの認 証を目指している • 初期はカーネルとインターフェースの範囲 を限定して開始 • 当初の目標はIEC 61508 SIL 3 / SC 3の (IEC 61508-3, 7.4.2.12, ルート3s) • メンバーからの関心が十分に高まった場 合には、認証機関との契約にISO26262認 証のオプションが盛り込まれている(見込 み) なぜIEC 61508？ IEC 61508規格が選ばれたのは、様々な産業分 野に適用可能な、基礎的な機能安全規格である ため https://www.tuvsud.com/ko-kr/-/media/global/pdf-files/infographics/tuvs ud-functional-safety-in-a-nutshell-infographic.pdf
6. Zephyr's Project Governance. Working Group(12) • Architecture Working Group • Process Working Group • Networking Working Group • Safety Working Group • …. Governance Board Committee (4) • Technical Steering Committee (TSC) • Marketing Committee • Security Committee • Safety Committee Ambassadors Zephyr Community Zephyr Project https://github.com/zephyrproject-rtos/zephyr/wiki/Zephyr-Committee-and-Working-Groups
7. Safety Committee/WG Kate Stewart's presentation from Dec. 2025 Japan OSS: https://hosted-files.sched.co/ossjapan2025/ca/20251209%20OSSJ%20Zephyr_%20Learnings%20from%20Working%20on% 20Safety%20Certification%20in%20the%20Open.pptx.pdf 隔週火曜 23:00-0:00 (夏時間) 隔週火曜 23:00-0:00 (夏時間)
8. ステータス：2025/12月時点 Kate Stewart's presentation from Dec. 2025 Japan OSS: https://hosted-files.sched.co/ossjapan2025/ca/20251209%20OSSJ%20Zephyr_%20Learnings%20from%20Working%20on% 20Safety%20Certification%20in%20the%20Open.pptx.pdf
9. https://hosted-files.sched.co/osseu2025/4a/ZDS%2008_25%20-%20Bridging%20Safety%20and%20Architecture.pdf?_gl=1*1ojcaxo*_gcl_au*MT MxMzE3MTU5MC4xNzc5MzY4MDc5*FPAU*MTMxMzE3MTU5MC4xNzc5MzY4MDc5
10. よし、調べてみよう
11. Document, Github • 公式ドキュメント ◦ https://docs.zephyrproject.org/latest/safety/index.html ◦ →Overview, Requirements Management (ツールのやり方) • Wiki : Safety FAQ ◦ https://github.com/zephyrproject-rtos/zephyr/wiki/Safety-FAQ ◦ →参加者のための情報発信 (2025/7月に作成） • Repository ◦ https://github.com/zephyrproject-rtos/reqmgmt ◦ → 要件ドキュメントのソース • Issue, Project ◦ https://github.com/orgs/zephyrproject-rtos/projects/23/views/4 ◦ https://github.com/zephyrproject-rtos/reqmgmt/issues
12. StrictDocを用いた要件定義書 テキスト(sdocファイル)で記述。要件をリンクして要求管理のトレーサビリティを得ることができるツール https://zephyrproject-rtos.github.io/reqmgmt/reqmgmt/docs/system_requirements/index.html *sdoc html
13. 要件を記述するにあたってのガイド 要件を作成するためのガイドに追記さ れた項目（2026/4月に更新） StrictDoc使い方など 要件管理に関するガイドライン 要件レビューのチェックポイント https://docs.zephyrproject.org/latest/safety/index.html
14. 安全委員会は、プロジェクトの安全対策におけるルート3Sアプローチに従 い、実装の現状を反映した要件を収集する取り組みを主導します 。その 目的は、プロジェクトに追加機能を要求するための新たな要件を作成するこ とではありません。 要件からコードを起こす従来のSafetyプロセスではなく、実装 (限定したコード）から要件を定義する手法
15. 課題1：Zephyrの知識＋セーフティの知識が必要？ 実際にWGに参加してみると、Safetyドキュメントのレビューアーが足りていないことが、大きな課題で あるとわかった。 通常の開発では、次のような流れになる。（実装者自身がある程度の動作確認が可能） • サンプルコードを書く • 実際に動かす • テストする • パッチを投稿する 一方で、Safetyドキュメントの場合は流れが異なる。 • 要件を理解する • 関連するコードや仕様を確認する • Safety要件として文書化する • パッチを投稿する 　 要件と実装の両方を見て妥当性を判断できる レビューアーの存在も重要
16. 課題２：どこから着手するべき？ reqmgmt リポジトリにはIssueがすでに整備され ている。 • 要件の確認、コードとの比較、追加・修正の 要否 • 52 件のオープン Issue 特に指定・優先度はないため、実施者が選んで問 題ない
17. 意外と難しそう、、、、
18. AI 活用できないか検討してみた Safetyエンジニア Zephyr Safety WG Zephyrエンジニア ただプロンプトを書かせるのではなく、 OSSならではの利点 を活用 • 過去の PR を分析（傾向と対策） ◦ 48件のマージされたPRからメタデータ・差分・レ ビューコメントすべて取得 ◦ Safetyエンジニアに見立てて事前レビュー • 残Issue を分析（課題選択） ◦ 52件をチェック。#119 を選択 ◦ 2つのAIエージェントを利用 ：Codex,ClaudeCode ◦ 双方でドラフトを作成、相互レビュー
19. Claude Code + Codexで提案を作成 Claude Code の担当「共有成果物の維持・ Human 決定 の全ファイルへの反映」 Codex の担当「GitHub API によるリモートリポジトリの確 認・検証」 両者で「独立した要件草案の作成と相互レビュー」 まったく同じ2案を提示したが、異なる案を提示
20. Issue #119 Version Requirements Claude Code Codex Claude CodeはOptionA(kernel verの み）を推薦、 一方CodexはOpetionB ( major, minor, patch を定義）を推薦。 定義はほぼ同じ。
21. 最後は人によるジャッジ Human(私）がOptionB を採択。 • あえてコードは読まずに、提案理由を報告させた • 提案書を読んで判断 ◦ 「Human は個人的には A で十分との意見だが、方針として B に同意した。 両 エージェントの推奨本線案が採用された。」と記録あり その後、両者でsdoc 作成 • ほぼ同じ内容のファイルを作成 • 相互レビュー（差分は未定義のUIDだけ） • 最終sdoc ファイル(shared_sdoc/version.sdoc)を作成 • 完了
22. PR 発行しました (2026/6/24) https://github.com/zephyrproject-rtos/reqmgmt/pull/140
23. まとめ Zephyr Safetyを追いかけてみた： WG参加とRequirement貢献に挑戦 ・Safety活動を整理してご紹介 ・過去のPR, 残issue と、2つのAIエージェン トを活用して初心者の私がPR発行まで実 施 　=> 6/30 WGで報告予定 ＜所感＞ ・日本からのWG参加は簡単ではない ・RTOSコードとは異なる形でコントリビュー ションできそう 　・実機なくても可能 　・エンジニアでなくても貢献できる！ ・OSS＋Safetyはまだまだ課題あり ・今回の事例をベースにAI事例を整備、共 有したい。AI活用でどこまで加速できるか がポイント
24. • Kate Stewart's presentation from Dec. 2025 Japan OSS: https://hosted-files.sched.co/ossjapan2025/ca/20251209%20OSSJ%20Zephyr_%20Learnings%20from%20Working%20o n%20Safety%20Certification%20in%20the%20Open.pptx.pdf • Tobias: OSSEU2025: https://hosted-files.sched.co/osseu2025/4a/ZDS%2008_25%20-%20Bridging%20Safety%20and%20Architecture.pdf?_gl= 1*1ojcaxo*_gcl_au*MTMxMzE3MTU5MC4xNzc5MzY4MDc5*FPAU*MTMxMzE3MTU5MC4xNzc5MzY4MDc5 • Tobias: EW2026: • https://cdn.discordapp.com/attachments/899776908542246983/1481626901788491960/2026_03_EWC_Nuremberg_-_Ze phyrs_Roadmap_to_a_Pre-Certified_Kernel_for_Safety-Critical_Systems.pdf?ex=6a3e6d94&is=6a3d1c14&hm=de3f81ee b4c86092d6dd7b640ef293dddb33260a8611c1d232cbfcc5bd604aa7&
25. 来歴/History Ver. Date Titel Event Location 1.0 2026/6/26 Zephyr Safetyを追いかけてみた： WG参加とRequirement貢献に挑戦 Zephyr Project Meetup: Sapporo, Japan 2026 札幌, Japan