■ 1. 発表者・Red Hat 会社概要
- 発表者: Red Hat K.K. シニアスペシャリストソリューションアーキテクト 小野佑大（元通信キャリア、SDN/NFV技術戦略経験、2021年よりRed Hat OpenShiftプリセールス担当）
- Red Hat の定義: 100万以上のOSSコミュニティへの貢献で培った技術と開発プロセスのノウハウで、顧客の「ソフトウェア変革」を支援する「OS（リソース抽象化）」の会社
- 製品ポートフォリオ:
- OS: RHEL（企業向けLinux OS）
- Middleware: JBoss（JavaアプリのOS）
- Cloud: OpenShift（マルチクラウドのOS）
- Automation: Ansible（ITインフラ運用のOS）
- AI: vLLM（AI推論のOS）
- 実績:
- ITサーバLinux市場シェア約80%
- 主要通信キャリアの約80%が採用
- 製造業など専用機のSDX化に対応（車、PLC/DCS、保護リレー等）
- 強み: 「柔軟性を確保」する仕組みとプロセスの「標準化」
- ビジネスアジリティの向上: ハードウェアとソフトウェアを分離する仕組み、速さと品質を両立するCI/CDのプロセス
- 属人的な対応の解消: 様々な機器の運用方法を共通化する仕組み、異種混在環境をサイロ化させない運用プロセス
- Red Hat の価値:
- 産業現場対応の製品強化: 軽量化や導入方法の多様化、HW連携による性能の最適化、オフライン環境へのインストール、世界のリーダー企業との実績
- セキュリティとライフサイクル: アップストリームファーストの開発ポリシー、OSSと異なる製品としてのライフサイクル管理、日本における大規模・堅牢なサポート体制、NIST/FIPS・IEC・ISO26262等の産業認証取得
- 標準化への貢献: margo、Open Process Automation Forum、vPAC alliance、Open Manufacturing Platform
■ 2. ソフトウェア定義型生産ラインの世界観
- コンセプト: オープンソース技術とグローバルのベストプラクティスを実践し、OTとITを融合する「ソフトウェア変革」を実現
- 構成要素:
- Edge Computing Platform: 産業設備と連携する機能を迅速に配備できる基盤
- Edge Data Bus: 機能間を疎結合に繋げる基盤
- OT Gateway: 産業設備とアプリを連携する基盤
- Edge App Store: 様々な機能をOSSとして生産ラインで安全に活用
- 実現できること:
- 産業設備と連携する機能を迅速に配備できる
- 工場の成功ノウハウを組織の中で迅速に広められる
■ 3. ものづくりの市場動向と課題
- 市場環境の変化: 初期要件から変化しないモノづくりから、要件変更へ柔軟に対応できるモノづくりへのシフト
- 市場環境が激化する3要因:
- スピード競争の激化: 海外は数ヶ月で生産準備完了
- 顧客ニーズの多様化: 多品種少量生産・品番追加への対応
- 開発の属人化: 開発が特定の人材やメーカーに依存
- 迅速な対応が難しい構造的要因（「ハードウェア中心」の思想が現場の「俊敏性」を奪っている）:
- 機能追加 = 専用の箱を増設: 機能ごとに専用ハードが必要で、変更のたびに配線・設置・調整が発生
- ベンダーロックイン: 特定メーカー依存の構成が代替手段や新技術の導入を阻む
- 保守・更新の稼働負荷: 現地作業が前提のため、遠隔対応も迅速なアップデートも困難
- ソフトウェアファースト戦略（対比）:
- ハードウェア中心: ソフトがハードの仕様に大きく依存し、ハードとソフトの更新サイクルが同じ（導入後は固定）
- ソフトウェア中心: OSがハードとソフトを分離し、柔軟に新たなソフトを追加・更新（導入後も成長）
■ 4. グローバルの業界トレンド
- FA製品のビジネスモデルの変化:
- IoT Gatewayを汎用機化して「ソフトウェア戦略」へ転換
- SaaSと接続したApp Store経由でアプリを提供（例: 予知保全アプリ（月額）、電力監視アプリ（従量課金））
- Virtual PLC:
- IoT GatewayのプラットフォームでPLCを「再配布可能なアプリ（コンテナ）」として提供
- 従来のPLC: 専用ハード（CPU + 物理的な機能拡張モジュール）
- Virtual PLC: Marketplaceから機能拡張を「アプリ」として追加・管理可能
- プラットフォームの標準化 - Margo:
- Linux Foundation配下のプロジェクト
- 産業用組み込み製品メーカーが主導（Rockwell / SIEMENS / Schneider / ABB 等）
- 解決課題: 「産業エッジ」の相互運用性の欠如（ベンダー毎のサイロ化、非差別化技術の乱立によるイノベーション阻害）
- 成果物: 標準仕様・参照実装・認定テストツール（「非競争領域」の車輪の再発明を防ぐ）
- Industrial DevOps:
- LLMやVirtual PLCの登場、Margo等の標準化を背景に、ITのDevOpsの原則を生産設備へ応用するエコシステムが活発化
- 活発化している要素: IDE as a Service、バージョニング、Vibe Codingや仮想試運転、Virtual PLCのライフサイクル管理の自動化、セキュアなリモートアクセス、バックアップ自動化
■ 5. Industrial DevOps の詳細と開発プロセス
- Industrial DevOps の3フェーズ:
- Code（仕様確定→テストケース確定→実装）: AI Agentによる設計・開発支援、Gitによるバージョン管理
- Build（テスト→再配布可能なバイナリ構築）: Build・Test・CVE scan・Sign・SBOMなど品質・セキュリティチェックのガードレール
- Deploy（カタログ公開→UI操作→展開）: Margo準拠のEdge App StoreからGUI操作で展開
- AS IS の開発プロセス（現状の課題）:
- 現地で動く実機ができるまで、ソフトウェアの妥当性を確認できない（ビッグバン統合）
- 設計起因の不具合が現地デバッグ段階に集中し、差し戻しが発生
- TO BE の開発プロセス（目指す姿）:
- テストや検証のタイミングを上流へ寄せ、後工程のリスクを減らす（Shift Left）
- ソフトウェアとハードウェアの開発プロセスを分離
- 成果物を単一リポジトリで版管理（Single Source of Truth）
- 稼働実績・不具合をモデルや標準ライブラリへフィードバックする継続的改善サイクル
- CIとCDの責務分離:
- CI（開発チームの役割）: 実装→テスト→CVE検査→成果物作成までのデプロイ可能な成果物を作成するプロセス
- CD（運用チームの役割）: 成果物の内容確認→デプロイによる安定運用を維持するプロセス
- 責務を分離し、チーム内の役割を明確化した上で各々の責務に集中できるプロセスを整備
- CIをAIに任せるためのガードレール設計:
- AIが「確実・安全」に「決められた順序」で「自律的に」仕事を進められる環境を構築
- パイプライン構成: 仕様策定→テストコード→アプリ実装→品質ゲート→静的解析→単体テスト→結合テスト→CVE検査→SBOM→署名→リリースゲート→展開
- AIの暴走や破綻を防ぐためのガードレール設計が重要
■ 6. Industrial DevOps 導入の壁と対策
- 3つの壁（これまでの成功体験やリスク回避の考え方に起因）:
- 壁1: 責任と権限の壁: 外部ベンダ依存や重い承認フローで、チーム自身が「変更判断」を行えないプロセス
- 壁2: 品質保証の壁: 失敗が許されず、「人が入念に一発本番のテストをする」人依存のやり方が前提のプロセス
- 壁3: 正当化の壁: 万が一のライン停止・事故リスクが大きすぎて「触らないことが最善」という組織の考え方
- 重要な認識:
- CI/CDの導入は自動化ツールの導入とは異なる
- 求められる品質へスピーディに対応する「働き方のアップデート」が必要
- 技術で解決できないものは「プロセス」で対応
- 各壁への対応策（仕組みとプロセスの両輪）:
- 壁1 責任と権限の壁:
- 仕組み: コンテナで作業リスクを軽減（変更影響の範囲を局所化、切り戻し手順の簡素化）
- プロセス: 作業承認プロセスの軽量化、ベンダ協業でコンテナ納品
- 壁2 品質保証の壁:
- 仕組み: GitOpsで段階保証（開発→ステージング→本番、高度なデプロイ戦略）
- プロセス: テスト→昇格プロセス、Git Mergeでリリース承認
- 壁3 正当化の壁:
- 仕組み: プラットフォームの段階刷新（Re-Platform、既存との疎結合な連携）
- プロセス: 既存影響のない領域から組織定着→段階的な拡大
- 目標: 仕組みとプロセスを回す「標準の土台」を育てていく
■ 7. 段階的なプラットフォーム移行戦略と PoC パッケージ
- 3段階の移行ロードマップ:
- 第1段階（既存と疎結合に連携）: 既存と分離された環境で新たなプロセスを「確立」（IoT/AI・CI/CDプラットフォームをData Busで既存システムと連携）
- 第2段階（既存の一部へ適用）: 既存の一部（MES・SCADA等）を移行し、新たなプロセスを「拡大」
- 第3段階（制御領域へ適用）: PLCを移行し、新たなプロセスが「浸透」（制御領域全体のソフトウェア定義化）
- PoCパッケージの構成:
- Initial Advisory（リスクなく開始し、課題とゴールを明確化）:
- STEP1: ミニチュア工場ワークショップ（2時間+懇親会）: 海外ベストプラクティスの紹介と実機体験を通じて最初の一歩目を整理
- STEP2: ディスカバリワークショップ（3〜4時間 × 4〜6回）: 業務プロセス分析を支援し、PoCの評価項目やKPIを策定
- Professional Services（Red Hat及びパートナーとの体制の下でPoCで価値を体感）:
- STEP3: ハンズオン（半日）: 最低限知っておきたい技術に触れ、そのメリットを体験
- STEP4: MVPの実装（3ヶ月〜）: Red Hat推奨環境でプロト実装し、本番の課題（要件）を整理