基本情報 平成21年度 秋期 問50：テクノロジ系に関する問題

答えは c です。

組込みシステム（家電・車・産業機器に入っているコンピュータ）は、いったん製品にしたあとでも「バグ修正版を作ってね」「新しいOSに対応してね」と頼まれることがあります。

そのときに、最初に開発した環境（パソコン・ツール・コンパイラ）が動かないと、修正もできません。だから使う頻度に関係なく、定期的に動作確認していつでも使える状態に維持するのが正解。

👉 覚え方：開発環境は「いつ呼ばれても対応できる消防車」。普段使わなくても点検必須！

ほかの選択肢：a「最新に更新」だと逆に古い製品が再現できなくなる／b「もう使わない」は間違い／d「レンタル会社の責任」は無責任。

なぜこれが正解か

正解は c。組込みシステムは製品ライフサイクルが長く（10年以上のことも）、出荷後の不具合対応・機能追加・規格対応で何度も再ビルドが必要になる。そのため当時の開発環境（コンパイラ、SDK、シミュレータ、デバッガ、ターゲットボード）を保全し、使用頻度に関係なく定期的に動作確認することで、いつでも保守対応できる状態を維持すべき。

各選択肢の解説

• a「常に最新に更新」：最新化により当時のビルド結果と差異が出るリスクあり。バイナリ再現性を失う。
• b「製品化後は不要」：実態と乖離。バグ修正・派生開発で必ず必要になる。
• d「レンタル会社が永続保持」：レンタル契約の責任範囲外。発注側で保全すべき。

覚え方・ひっかけ注意

組込み開発は「保守期間=製品寿命+α」が原則。航空機・産業機器・自動車のECUは20年超の保守要求もある。「当時の環境を凍結保管」のスタンスが必須で、PCのOSバージョン・ライセンス管理・互換ハードウェアの保管まで計画する。

理論的背景

組込みシステムの開発環境維持は長期サポート（LTS）戦略の一部。要素は (1) クロスコンパイラ（ホストPCで動きターゲットCPU向けバイナリを生成、例：GCC arm-none-eabi）、(2) JTAG/SWDデバッガ（ICE: In-Circuit Emulator）、(3) ターゲットボード・実機、(4) テストハーネス、(5) OS・ライブラリのバージョン。再現性確保のためコンテナ化（Docker）、仮想マシン（VMware/VirtualBox）のスナップショット、ソースコード・ツールチェーン全体のバージョン管理（Git LFS）、SBOM（Software Bill of Materials）の整備が現代的手法。バイナリ再現性（Reproducible Builds）の取組みも進む。

実務での使われ方

自動車業界ではA-SPICE（Automotive SPICE）でツールの妥当性確認（Tool Confidence Level）が要求される。航空業界のDO-178C（DO-330でツール認証）、医療機器のIEC 62304でもツールチェーン管理が規制対象。汎用OS（Windows/Linux）の長期サポート版（Windows LTSC、Ubuntu LTS、Red Hat Enterprise Linux）を選定し、サポート期限を見越した移行計画が運用設計に組み込まれる。レガシーOS（Windows XP、CE等）でしか動かない開発環境を仮想化保存する事例も多い。

試験での位置づけ

FE科目Aで組込み開発・保守の常識問題として出る。エンベデッドシステムスペシャリストでは長期保守戦略、構成管理（CM: Configuration Management）、SBOM運用、サプライチェーンセキュリティ（ISO/SAE 21434：車載サイバーセキュリティ）が問われる。ITサービスマネージャでは保守契約・サポート期限・EOL管理が論述対象。

選択肢の発展補足

関連プラクティス：SBOM（製品に含まれるOSS・サードパーティコンポーネント一覧、米国大統領令EO 14028で連邦調達要件化）、VEX（Vulnerability Exploitability eXchange、脆弱性のexploit可能性を構造化表現）、SLSA（Supply-chain Levels for Software Artifacts、サプライチェーンセキュリティのレベル分類）、Sigstore（コード署名の民主化）。組込みシステムでは2025年からのCyber Resilience Act（EU CRA）対応で、設計から廃棄までのライフサイクル全体で脆弱性管理が法定義務化される動き。OTAアップデート（Over-The-Air、車載・IoT機器の遠隔ファーム更新）対応のため、開発環境にも署名鍵管理・PKI連携が組み込まれる。