AI時代のキョウソウ戦略

SWEST28基調講演のスライドです。
https://swest.toppers.jp/phx/event

Transcript

1. SWEST28 基調講演 AI時代のキョウソウ戦略 ～ソフトウェア・ディファインドがもたらす価値創造の進化とは～ 株式会社 東芝 総合研究所 デジタルイノベーション技術センター 小林 良岳 © 2026 Toshiba Corporation
2. 本日のTakeaway • 上物の価値は下回りが決める。だから土台は仲間と創る • 社外はオープンソース、社内はインナーソース、 協調領域も競争領域も加速！ • AIがさらに活動を加速するが大切なのは人！ © 2026 Toshiba © 2026 ToshibaCorporation Corporation 2
3. 本日のTakeaway • 頼り頼られる仲間を大切に！ © 2026 Toshiba © 2026 ToshibaCorporation Corporation 3
4. Think OPEN © 2026 Toshiba Corporation 4
5. 自己紹介 ⚫ 名 前 ： 小林 良岳 （こばやし よしたけ） ⚫ 所 属 ： 株式会社 東芝 総合研究所 デジタルイノベーション技術センター 副センター長 / シニアフェロー ⚫ 略 歴 ： • EDS Australia • 電気通信大学 • 東芝 〔システムアドミニストレータ〕 〔助教〕 〔～今に至る〕 ⚫ 専 門： • オペレーティングシステム（OS） • オープンソースソフトウェア（OSS） ©© 2026 Toshiba Corporation 2026 Toshiba Corporation 5
6. 自己紹介 ⚫ 社外活動 ： Linux®/OSS関係の活動多め • TOPPERS Project 理事 (2010-) • CE Linux Forum Architecture Group Member (2010-) • Core Embedded Linux Project SC Chair (2015-) • Civil Infrastructure Platform Project TSC Chair (2016-) • Open Invention Network Technical Advisory Council (2019-) • インナーソース Commons Foundation Member (2025-) • The Linux Foundation Board Member (2026-) • Embedded Linux Conference Program Committee (2014-) • Open Source Summit Japan Program Committee (2024-) • 電子情報通信学会 常任査読委員 (2008-) • OpenChain Project Board Member (2018-2020) Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries. ©© 2026 Toshiba Corporation 2026 Toshiba Corporation 6
7. 製品適用 ： 技術適用から製品化まで関わった最初の製品 （2010年） OSSを用いて作った自動改札機としては国内初！ © 2026 Toshiba Corporation 7
8. 製品適用：関わった製品例（直接的・間接的） 郵便区分機 産業用 コントローラ 放送システム 発電制御 コントローラ エレベーター 群管理システム マルチファンクション プリンター 気象レーダ … 他たくさん （70以上） なぜこれだけ多くの製品に関われたの？ © 2026 Toshiba Corporation 8
9. 小林の仕事の中心（OS/OSS = 共通ソフトウェア） 共通利用されるソフトウェアの研究開発を担当することで多事業に貢献 ユーザー ソ フ ト ウ ェ ア 構 成 私（小林）が関わっているのはこの部分 アプリケーション ミドルウェア・ユーティリティ・ ライブラリ オペレーティングシステム （OS） 企業価値となる部分 機能・サービスの価値実現に 必要な必須機能 ハードウェア © 2026 Toshiba Corporation 9
10. Contents 00 自己紹介：関わってきた製品と、共通ソフトウェア 01 導入：AIが迫る変革 02 目的地：ソフトウェア・ディファインド 03 よりどころ：価値を作る3つの領域 04 進み方：Collaboration 05 結論：価値創造のサイクル © 2026 Toshiba Corporation 10
11. 1. Introduction AIが迫る「作り方」と「組織」の変革 © 2026 Toshiba Corporation 11
12. AIが変えるのは「作り方」だけではない 「書く時間」より、「レビューし、判断する時間」が主役に AI生成コードの デバッグは時間がかかる 45.2% 動くコードと欲しいコードの ギャップは人が埋める （改善に向かってはいるが・・・） PRレビュー 時間の増加 コードベースの 複雑性 +91% +40% 自分が書いていないコードは理解 に時間がかかる 作れる量が増えるほど、 「何を作らないか」の重みが増す Ref: Stack Overflow Developer Survey 2025 (AI section, n≈49,000) Faros AI, AI Engineering Impact Report 2025 (10,000+ devs, 1,255 teams) He et al., arXiv:2511.04427 (CMU, 807 repos／複雑性は40%超) 傍証: DORA 2024・2025, GitClear 2025 12
13. 組込みでは、素朴なAI適用は効きにくい 規格・セキュリティ認証など、その説明責任がついて回る 制約が強い領域 ⚫ リアルタイム性、限られたリソース、止まらないこと ⚫ コーディング規約、ニッチなハードウェア 世に出ているコードが少なく、AIの得意分野から外れる 学習データが 少ない世界 ⚫ 10年〜数十年、そのコードを誰が保守するのか 「作り方」と「組織」をどう変えるかが問われる © 2026 Toshiba Corporation 13
14. 今日の発表の地図：目的地・よりどころ・進み方 AIが、そのすべてを貫く縦糸になったとき、人はどのように振る舞うか？ AIは縦糸。今日の本論は横糸であるOSSとインナーソース 目的地 よりどころ 進み方 ソフトウェア・ディファインド 価値を作る3つの領域 Collaboration ⚫出荷後も価値を作り続ける状態 ⚫領域ごとに、打つ手を変える ⚫外はOSS、内はインナーソース © 2026 Toshiba Corporation 14
15. 「キョウソウ」には、3つのタイプがある 同じような言葉でも、向き合い方はちがう 競争 協調 共創 Competition Collaboration Co-Creation 差で勝つ領域。閉じて磨く。 前提を合わせる。共通は共に。 価値を共に生む。開いて増やす。 競争・協調・共創 ― この3つを行き来する © 2026 Toshiba Corporation 15
16. 2. Destination ソフトウェア・ディファインドによって変わるもの変わらないもの 今は前提の確認 ― 競争・協調・共創のどれにも共通する「目的地」 © 2026 Toshiba Corporation 16
17. ソフトウェア・ディファインドとは何か ソフトの柔軟性と、ハードの信頼性を配分し直すコンセプト 実現したい価値や目的に対して、ソフトの柔軟性と、ハードの信頼性という特性を ソフトウェアの実装を通して最大限に生かす 何を目指すのか ⚫ そのために機能分担を見直し、将来に備える もとはネットワークをどう適切に接続するかという文脈で広まった 新しい概念ではない ソフトがハードを管理するようになり、改めて注目される 車載（SDV）から、産業機器、家電、インフラ、医療機器まで波及 広がる領域 © 2026 Toshiba Corporation 17
18. なぜソフトウェア・ディファインドなのか？ 市場・制度・技術、3つの圧力が同時にかかっている 市場からの圧力 制度からの圧力 技術からの圧力 製品の差は、ハード性能ではなく、 ソフトの体験で決まりはじめた CRA（サイバーレジリエンス法） が、出荷後の更新責任を求める クラウドとAIが、機能を素早く更 新・追加し続けられるようにした ⚫ 買った後も良くなり続けること が、選ばれる条件になった ⚫ 長期のセキュリティ対応が、 売るための前提条件になる ⚫ 出荷後の機能修正・向上が、 例外ではなく前提になる © 2026 Toshiba Corporation 18
19. 社会インフラに実際に起きていること CPS(*)の常態化 VPP（バーチャルパワープラント：仮想発電所） • クラウド側(Cyber)と機器側(Physical)の 機能が連携 • 機器のもつデータをクラウド側処理 • 機器制御の一部をクラウドで実行 機器側機能の特化 • 即時性の高い厳密なタイミング制御 • 機器の信頼性や安全性確保 • セキュアな環境の維持 Ref: Toshiba Clip | ハードとソフトを、デジタルでつなぐ 〜サステナビリティの課題解決へ、東芝の挑戦 外部とコミュニケーションしながら社会全体での最適化を目指している (*) Cyber Physical System © 2026 Toshiba Corporation 19
20. 出荷はゴールではなく、スタートになる 「作って終わり」から「動かし続けて価値を伸ばす」へ Before 出荷時が品質のピーク After 出荷後に価値が増えていく 仕様凍結 → 作り込み → 出荷 → 現状維持 モノ売りから、コト売りへ ⚫ 以後は保守中心で、価値は増えない ⚫ 継続的な機能追加とアップデート （OTA前提の設計） ⚫ 稼働データを次の価値に還元するサイクル ⚫ このサイクルをAIが加速して、はじめて現実的 に回りはじめる © 2026 Toshiba Corporation 20
21. つまり「価値のつくり方を再定義する」ということ どこを固め、どこを伸ばすかを、設計で決め直す 設計で決めるべきこと 製品のどこは厳密さ・信頼性・高品質を重視するのか どの部分に柔軟性を持たせ、ソフトで価値を生み出すのか 価値につながるデータを、どう収集するのか 身近な例 テスラ：出荷後の更新で、新機能も航続距離などの性能も伸びる Apple Watch：心電図アプリが心房細動を検知し、改良され続ける © 2026 Toshiba Corporation 21
22. 作り続けるには、組織のほうが先に変わる必要がある 「どこを自前で持つか」を決め直し、戦略と組織の両方を見直す必要がある 出荷後も価値を伸ばすなら ひとつの事業部では抱えきれない 製品を出し終えても、チームは 解散できない セキュリティ、長期保守、認証対応は、 どの製品にも等しくのしかかる ⚫ 10年、20年、同じ土台を更新し続ける 体制が要る ⚫ 同じ下回りを、それぞれが別々に抱える ほどの余力はもうない © 2026 Toshiba Corporation 22
23. 難所：コト売りになるほど、モノへの要求は厳しくなる ソフトウェア・ディファインドは、モノを軽くする話ではない 上モノが主役になるなら、組込みソフトは軽くなるのではないか よくある誤解 ⚫ 実際は逆。信頼できる下回りやハードがあってこそ、上モノが価値を生む 土台に突きつけられる要求は、むしろ厳しくなる 土台への要求 ⚫ ミリ秒単位のリアルタイム性と、止まらない高信頼性 ⚫ SLTS（超長期サポート）10年、20年という保守責任 ⚫ CRA（サイバーレジリエンス法）が求めるサイバーレジリエンス © 2026 Toshiba Corporation 23
24. 3. Framework 価値を作る3つの領域とその戦略 今は地図づくり ― 競争・協調・共創を、3つの領域として切り分ける © 2026 Toshiba Corporation 24
25. 領域ごとに、打つ手は変わる Unique Innovation 企業が顧客に提供する価値 Delivery Support for the Innovation 価値提供に必須の技術 Commodity Platform 枯れた共通基盤 自社の強みを、ここに注ぎ込む 市場で勝ち抜く上で直接効く、絶対領域 社外のOSSで、仲間と創る 差異化には効かないが、勝ち抜くには必須。ここが下回り 発展させる要素も多数ある領域 作らない。既にあるものを使う 技術が枯れていて、購入すれば間に合う ソフトウェア・ディファインドへ向かうほど、真ん中の層が重くなる。 上物を更新し続けるには、下回りが10年20年動き続けなければならない Ref: How to Contribute to the Linux Kernel, and Why it Makes Economic Sense (James Bottomley, Novell; LinuxCon Japan 2009) © 2026 Toshiba Corporation 26
26. 価値を作る3つの領域と、動き続ける境界線 これまで Unique Innovation 企業が顧客に提供する価値 Delivery Support for the Innovation 価値提供に必須の技術 ソフトウェア・ディファインド ＋ AI の時代 Unique Innovation 企業が顧客に提供する価値 ↑ 境界線が上へ動く Delivery Support for the Innovation 価値提供に必須の技術 Commodity Platform Commodity Platform 枯れた共通基盤 枯れた共通基盤 かつて作り込んでいた領域の共通化が進むと、守るべき絶対領域は薄くなり、 支える下回りが厚くなる © 2026 Toshiba Corporation 27
27. 難所：線引きこそ、最難関 何が非競争で、何が競争かの決断が難しい 判断の物差し Q1 Q2 Q3 顧客が価値を感じて いる部分か 自社の差別化に直結 しているか 他社や外部で 代替できてしまうものか 協調領域 競争領域 共通課題は、分かち合う ハード制御技術・ドメイン知見・安全設計 共通課題は分かち合い、独自の付加価値でエッジを効かせる © 2026 Toshiba Corporation 28
28. 立ちはだかる2つの壁 ― 内部硬直性と外部硬直性 組織の縦割りと自前主義。この2つの硬直性を打破する鍵が、オープンな開発 内部硬直性 ― 組織が縦割りで動く 事業部ごとに縦割りで動くため、似 たものを重複して作り続けてしまう 外部硬直性 ― 自前主義で社外連携が進まない 社外の力を取り込めず、変化のス ピードに追いつけなくなる ⚫ 似た基盤ソフトを、事業部ごとに別々に開発・ 保守している ⚫ 基盤ソフトを自社だけで維持するコストが、年々 積み上がる ⚫ セキュリティ、更新、認証対応といった横断的な 課題が、誰の仕事でもない ⚫ 製品が高機能化するなか、全てを自社開発し ていては変化に追いつけない © 2026 Toshiba Corporation 29
29. 4. Collaboration 外と中とで異なる戦略 今は「協調」 ― 共通課題は、外の仲間と一緒に（OSS） © 2026 Toshiba Corporation 31
30. 本章のポイント：外はOSS、内はインナーソース 外は世界と共通の土台を支え、内はOSSの作法で縦割りを溶かす 外部＝OSSで、非競争領域を世界と作る 競合とも手を組み、共通の土台を 一緒に支える ⚫ 産業用途の超長期保守を、競合と共に支える ⚫ それを製品基盤として取り込む 内部＝インナーソースで、縦割りを溶かす 社外のやり方を、そのまま社内の開発 に持ち込む ⚫ OSSの作法（公開・レビュー・貢献）を社内に 持ち込む © 2026 Toshiba Corporation 32
31. OSSの強み 誰でも自由に使える 公開されて、進化し続ける 関わる人が多いほど、直っていく 誰でも自由に使え、変更できる 工夫点を公開して受け入れら れれば、どんどん進化する 多くの開発者が関わり続けるか ら、不具合が見つかり修正され る 閉じた開発のままでは、この速度には追いつけない © 2026 Toshiba Corporation 34
32. 4-1. 黒歴史からの学び オープンであるということの本質 © 2026 Toshiba Corporation 35
33. 東芝のOSS貢献の始まり： CE Linux Forum 最初のきっかけは、パナソニック（当時、松下電器）とソニーが手を組んで、情報家電 向けのLinux開発を進めるフォーラムを作ったのが始まり（2003年） 参加メンバの例 https://www.celinuxforum.org/ Appointed Member (ステアリング会議での議決権あり) IBM LG 日立 Motorola シャープ NOKIA Philips 松下 Samsung SONY NEC HP 東芝 ARM Associated Member (ステアリング会議での発言権あり) ST TI THOMSON Intel Sanyo JVC 三菱 CAC KENWOOD LINEO TimSys Montavista Phoenix Softier Support Member (活動参加のみ) © 2026 Toshiba Corporation 36
34. CELPの活動当初の技術課題 • 組込み機器でLinuxを用いるために解決すべき技術課題 • System size • Boot time • Power management • Realtime • Security • 手段 • Linuxの標準機能に取り込む • 課題を提案して仲間を集めて活動に繋ぐ • Wikiを立ち上げ技術情報を積極的に公開 © 2026 Toshiba Corporation 37
35. CELF/CEWG/CELP20年の歴史 設立 The Linux Foundationと合流＆改名 改名 PJ終了 2003/07 2011/01 2017/06 2023/07 OSSコミュニティへのコントリビューション 技術活動 Open Project (2008〜2018) CELF Specification V1.0 (2004/05) Elinux wiki (2006/12〜) Japan Technical Jamboree (2004/10〜) イベント 参画 Episode II Embedded Linux Conference (2005/01〜) 東芝参画（2003/7〜） 小林 参画 AG / SCメンバ (2003/07〜） SC運営 (2014〜) 残務整理 © 2026 Toshiba Corporation 38
36. CELF黒歴史 (私のバイブル) • 2004/05： CELF Embedded Linux Specification を出版 https://lkml.org/lkml/2004/5/17/149 「あのねえ、こんな仕様書を書けば誰か がタダで実装してくれると思っている の？ だとしたらトンデモない間違いだ よ。こんなのが書けるんだったらもう何 かコードを書いているんでしょ。それを 先ずコミュニティーに持って来なよ！仕 様書なんてどうでも良いから」 Ref: A Special Talk, 上田理, Sony, 2012 © 2026 Toshiba Corporation 39
37. 一方で弊社のCELF参画中の黒歴史： OSSの作者に利用許可を求めた NTP（時刻同期のためのソフトウェア）の作者からの返信（2009年6月） From: "Poul-Henning Kamp“ Subject: Re: Confirmation: your copyright about NTP To: “******@toshiba.co.jp" Citat: Dear NTP Project Members. We are considering using your program "NTP" in our products. Before going any further, however, we would like to confirm the following so that we are sure to fully respect your rights. You are of the copyrights in the program. You have distributed the program under the attached license that permits us to use and redistribute the program with or without modification provided that any conditions stated in the license are met. If you would please send me a return email confirming the above, that would be most appreciated. And thank you very much for taking the time to create such a useful program. Thank you in advance for your kindness. Let me get this straight: You, a major worldwide megacorp which employs thousands of laywers, have downloaded the NTP reference implementation on the internet, containing a license for you to use it, with only certain trivial restrictions. But you do not trust the contents of the license file to be legally binding, thus you send emails to addresses which you have never been in contact with before, to people you have no way of authenticating, asking them, if the content of the file is correct. You then expect that the return mail you may or may not get, will cover your ass in whatever legal proceedings you foresee you might expose yourself to, as a result of you using the NTP reference implementation. Let the record show that somebody is not getting their money worth of competent legal assistance. You could have done what every major IT company has done until now, companies like Sun, IBM, Cisco, who trust the license file and happily uses the NTP reference implementation without any legal worries. But instead of actually researching this point, you sent this pointless email instead. No, I (see below) will neither confirm nor deny my participation or the license status of the code I may, or may not, have written for the NTP reference implementation. If you want such assurance from me, you will have to send me a registered letter, my address can be found in any danish phone book or on the Internet, containing the questions you want answered, and a suitable token of appreciation, to make it worth my time to answer them. Proof of a sensible monetary donation to the NTP project would work, as long as I do not need to ask my lawyer to answer your questions. Until such time, I will place you in legal jeopardy with respect to your use of the NTP reference implementation, with my statement above, and my signature below; sign: Somebody who may or may not be, Poul-Henning Kamp Who may or may not have written parts of the NTP reference implemenation, which may or may not be covered by the license restrictions you quoted. 「ちょっと確認させてよ、ライセンスって知っ てる？あなたたちのような弁護士何人も抱 えている会社が何言っているの？IBMも Ciscoも理解して使ってるよ。」 Ref: http://www.version2.dk/blog/i-am-not-nice-man-11355 © 2026 Toshiba Corporation 40
38. CELF＆弊社の黒歴史から学んだこと • コントリビューションあってこそ、 コミュニティは活性化する コミュニティ 活動 協業開発 （共創） • コミュニティを尊重する • 何かを得るには自ら動く • 早めに聞いて、早くフィードバックをもらう 技術公開 技術獲得 （課題の共有） 製品適用 理想は言えども（当時の）日本の技術者は外に出ていかない問題 © 2026 Toshiba Corporation 41
39. 海外のカンファレンスでの発表（2010年～2020年） OSSプロジェクト 年2～3回は何かしらの発表をした！ 実装も公開した！ 社会インフラ 信頼性・性能 1.Evaluation of Data Reliability on Linux File Systems (ELC 2010, Apr. 2010) 2.Linux Kernel Acceleration for Long-term Testing (ELC-E, Oct. 2010) 3.Moving Forward: Overcoming Compatibility Issues (ELC, Apr. 2011) 4.Automated Regression Test Environment For Multiple Kernels (LinuxCon EU, Oct. 2011) 5.Ineffective and effective way to find out latency bottlenecks by Ftrace (ELC, Feb. 2012) 6.Improvement of Scheduling Granularity for Deadline Scheduler (ELC-E, Oct. 2012) 7.Deadline Miss Detection with SCHED_DEADLINE (ELC, Feb. 2013) 8.An Essential Relationship between Real-time and Resource Partitioning (ELC-E Oct 2013) 9.Expectation of LTSI Testing (LTSI Workshop, Oct 2013) 10.Using RT Preempt patch with LTSI kernel (ELC 2014, Apr. 2014) 11.Collaboration with LTSI Testing (LTSI Workshop, Apr 2014) 12.Using Embedded Linux for Infrastructure Systems (ELCE 2014, Oct 2014) 13.Poky meets Debian: Understanding How to Make an Embedded Linux by Using an Existing Distribution's Source Code (ELC, Apr 2015) 14.BoFs: Applying Linux to the Social Infrastructure (ELC, Apr 2015) 15.Applying Linux to the Civil Infrastructure Systems (LinuxCon Japan, Jul 2015) 16.CE Workgroup Shared Embedded Linux Distribution Project (ELC-E, Oct 2015) 17.Introducing the Civil Infrastructure Platform (ELC, Apr 2016) 18.The Latest Status of the CE Workgroup Shared Embedded Linux Distribution Project (ELC, Apr 2016) 19.Introducing the Civil Infrastructure Platform (LCJ, Jun2016) 20.Time is ready for the Civil Infrastructure Platform (ELC-E, Oct 2016) 21.Civil Infrastructure Platform: Industrial Grade SLTS Kernel and Base-layer Development (Open Source Summit Japan 2017) 22.Debian on Civil Infrastructure System (DebConf2017, August 2017) 23.Civil Infrastructure Platform: Industrial Grade Open Source Base-Layer Development (ELCE and OSS EU 2017, Oct. 2017) 24.Civil Infrastructure Platform: Industrial Grade SLTS Kernel and Base-layer Development (Open Source Summit Japan 2018, Jun 2018) 25.Civilization runs on Debian (DebConf 2018, July 2018) 26.Civil Infrastructure Platform: Two Year Experience of Industrial Grade Open Source Base-Layer Development (Open Source Summit Europe 2018, October 2018) 27.How to Make Smart Cities Stay Smart with Open Source Projects (Smart City Event 2019, January 31, 2019) 28.Open Source Projects to Live Long and Prosper: Linux for Smart Infrastructure and Industry (Open Source Summit Europe 2019, October 29, 2019) 29.State of CIP Project (CIP mini-summit Europe 2019, October 2019) 30.CIP Installed: Sustainable Software Stacks in Long-living Products (Open Source Summit North America, June 29, 2020) 31.State of Civil Infrastructure Platform (CIP mini-summit Europe 2020, October 2020) 32.The InnerSource Learning Path (InnerSource Commons APAC 2020 Virtual Summit, December 2020) 2026Toshiba Toshiba Corporation ©©2026 Corporation 42 42
40. 参考：Core Embedded Linux Project紹介資料より引用 CELPの活動 （イベント：Japan Technical Jamboree） HOP STEP JUMP Jamboree ELC US/EUR Community Core Embedded Linux Project • 日本の組込み開発者の持つアイディアや問題意識を コミュニティーに届けるきっかけ作り • 2004/10 から 毎年約4回のペースで開催 • 開催回数は 80回 (2023/5) • 企業・大学等から開発者が結集 • ベテランはもとより初心者も参加 • Linuxコミュニティーに はばたいた技術や開発者多数 © 2026 Toshiba Corporation 43
41. 参考：Core Embedded Linux Project紹介資料より引用 CELPの活動 （イベント：Embedded Linux Conference） HOP STEP JUMP Jamboree ELC US/EUR Community Core Embedded Linux Project • 組込みLinuxに焦点を絞った開発者会議 • 春に米国、秋に欧州で開催 • 毎回500人を超える参加者 • 50を超える技術セッション • Technical Showcaseでデモを展示 © 2026 Toshiba Corporation 44
42. CELPの活動スコアカード (技術開発) ~2014年まで • 組込み機器でLinuxを用いるために解決すべき技術課題 • System size - done • Boot time - done • Power management - done • Realtime – in progress → done (2024年11月) • Security – in progress • 手段 • Linuxの標準機能に取り込む • 課題を提案して仲間を集めて活動に繋ぐ • Wikiを立ち上げ技術情報を積極的に公開 © 2026 Toshiba Corporation 45
43. 個人的CELP活動まとめ • 課題はそれなりにあった・・・・ • CELPが関わった技術は多くの製品に搭載 • CELPとしても個人としてもOSSコミュニティと繋がり を構築 • 意識せずとも頼れる背後霊ネットワーク • （何人かは守護霊になってくれたのだろうか・・・） オープンに活動したからこそできた頼り頼られる人脈が宝 © 2026 Toshiba Corporation 46
44. 4-2. オープンな活動からの出会い 社会課題の解決に向けたオープン戦略 © 2026 Toshiba Corporation 47
45. Linuxは既に社会インフラの一部として欠かせない存在 交通 エネルギー 他 産業機器 運行管理 発電所監視制御 ビル管理 産業オートメーション 車両制御 タービン制御(I/O) 放送 CNC 自動改札機 タービン制御 ヘルスケア 産業ネットワーク 48 Ref: Civil Infrastructure Platform-State of Industrial Grade Linux, Yoshitake Kobayashi, Open Source Summit Europe 2025
46. 事例：発電所向けコントローラ Linux®/OSSが発電所のような社会を支えるシステムで利用されている 発電機向け コントロールモジュール DCSコントローラ ・ボイラーの制御 ・プラント全体のモニタリング ・タービンの起動と停止 自社製 μITRON 発電機信号のI/Oと高速制御 100ミリ秒以上で制御。 タービン向け コントロールモジュール ・バルブ制御 ・周波数検出 ・速度検出 I/O コントロールモジュール 発電所の監視と制御に使用する DI/DO/AI/AOとその制御 5～30ミリ秒で制御。 Ref: Power Plants run on Linux CIP, CIP mini-Summit 2019 © 2026 Toshiba Corporation 49
47. 理想と現実のギャップの整理 目指したい姿 ⚫ IoTを社会インフラシステム にも適用する 解決すべき課題 産業レベル 品質 • 信頼性 • 機能安全 • リアルタイム性 ⚫ 製品品質と寿命を 確実なものにする 持続可能性 ⚫ 何万台ものつながった システムのセキュリティを保つ セキュリティ • 長期製品ライフサイクル • 互換性維持 • 標準化対応 • セキュリティ、脆弱性管理 • ファームウェア更新 • リグレッションリスク最小化 2026 Toshiba Toshiba Corporation ©©2026 Corporation 50 50
48. 課題をオープンにしたら、同じ提案が別のところから出ていた！ • CEWG内で開始した社会インフラ向けLinux PJ (2014/9) • Siemens から Open Industry Platform の提案 (2014/12) 2015/2 F2Fで打合せ © 2026 Toshiba Corporation 51
49. 2016年4月 Civil Infrastructure Platform (CIP) 始動！ Platinum Members Gold Members Silver Members 52 Ref: Members – Civil Infrastructure Platform 2026 Toshiba Corporation © 2026©Toshiba Corporation 52
50. 課題解決に向けた姿：CIPが目指す “Open Source Base Layer (OSBL)” ⚫ 社会インフラのような高い信頼性や長期保守が求められる製品向けの共通OSS集 ⚫ Linuxディストリビューションや関連するOSSと共に利用 企業独自のミドルウェア、 アプリケーション 追加のパッケージ （数百個） 典型的なLinux ディストリビューション の範囲 CIPコアパッケージ （数十個） OSBL CIPカーネル （10年超の長期保証、LTSカーネルベース） © 2026 Toshiba Corporation 53
51. 価値を作る3つの領域とCIP OSBL 企業独自のミドルウェア、 アプリケーション Unique Innovation 追加のパッケージ Delivery Support for the Innovation （数百個） (企業が顧客に提供する価値) (価値提供に必須の技術) CIPコアパッケージ （数十個） Commodity Platform CIPカーネル （10年超の長期保証、LTSカーネルベース） Ref: How to Contribute to the Linux Kernel, and Why it Makes Economic Sense (James Bottomley, Novell; LinuxCon Japan 2009) © 2026 Toshiba Corporation 54
52. 最低10年のメンテナンスマイルストーン 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 4.4 4.19 LTS 5.10 Maintained by the stable team 6.1 6.12 4.4 CIP SLTS 4.19 5.10 6.1 6.12 Maintained by CIP Self-maintenance Upstream First Self-maintenance Upstream First Upstream First Upstream First Self-maintenance Self-maintenance Self-maintenance We are here © 2026 Toshiba Corporation 55
53. CIPを企業に適用する レイヤー構造を持つインダストリアル製品向けLinuxディストリビューションを CIPのOSBLを用いて作成 ディストリビューション 追加のパッケージ 事業／製品レベル （数百〜数千） 部門レベル CIPコアパッケージ （数十〜数百） CIPカーネル コーポレートレベル ドメイン独自の 拡張 ドメイン独自の 拡張 … ファームウェア更新 セキュリティ強化 コンテナランタイム … カーネル、基本パッケージ、SDK、 ビルドチェーン、品質保証 （10年超の長期保証、 LTSカーネルベース） 個々の製品に対する、ライセンス確認、セキュリティ問題チェック、ソフトウェア保守、アプリケーション対応・テストなどで 最大70%もの工数削減が可能 © 2026 Toshiba Corporation 56
54. 数字で見るCIPの活動 CONTRIBUTIONS CVE CHECKS SLTS RELEASES REFERENCE HW TEAM 1000+/month 2000+ fixes 582 releases 11 boards 5 Key Developers LTS Patch reviews Counts only for 6.1.y-cip in 2024 August 2026 v4.4(114, rt62) v4.19(135,rt49) v5.10(76, rt26) v6.1(59, rt31) v6.12(30) 4 architectures Jan Kiszka Pavel Machek Nobuhiro Iwamatsu Ulrich Hecht Masami Ichikawa X86_64 Armhf Arm64 Risc V (and more contributors.) © 2026 Toshiba Corporation 57
55. EU Cyber Resilience Act に向けたCIPの取り組み LF Research発行のレポートにも載っています！ Reference: Mirko Boehm, Hilary Carter, and Cailean Osborne, “Pathways to Cybersecurity Best Practices in Open Source: How the Civil Infrastructure Platform, Yocto Project, and Zephyr Project are Closing the Gap to Meeting the Requirements of the Cyber Resilience Act,” foreword by Miriam Seyffarth, The Linux Foundation, March 2025. https://www.linuxfoundation.org/research/cra-compliance-best-practices CIP が EU CRA に向けたベストプラクティスの一つとして紹介 © 2026 Toshiba Corporation 58
56. CIP Open Source Base Layer の現在 企業独自のミドルウェア、 アプリケーション 追加のパッケージ 安全な アップデート の仕組み （数百個） CIPコアパッケージ （数十個） CIPカーネル （10年超の長期保証、LTSカーネルベース） 最低10年 長期保守の プラットフォーム セキュアな 開発への 適合 検証された 環境 当初目的を達成しつつ、プロジェクトの長期持続性確保にむけて活動継続 © 2026 Toshiba Corporation 59
57. オープンにしたからこそ生まれた「思わぬ出会い」 外部硬直性を打破すると、思わぬ出会いが生まれる 閉じたまま進めていたら、どうなっていたか オープンにしたから起きたこと 自社のなかだけで、答えを探し 続けることになる 同じ方向を向く相手と、外でつ ながれるようになる ⚫ 同じ課題を、別々の場所で二重に解き続けて いた ⚫ 同じ志を持つ仲間が見つかり、一緒に立ち上げ る相手になった ⚫ 相手がいることにさえ、気づかないままだった ⚫ 1社では届かない規模と期間の活動が、成立し た © 2026 Toshiba Corporation 60
58. 4-3. 今こそ社内もオープン化 今だからこそ始めるインナーソース 今は「共創」 ― 社内に開き、競争領域まで一緒に速くする（インナーソース） © 2026 Toshiba Corporation 62
59. 「共通課題」はどこまで広げられるか（OSSとインナーソースの守備範囲） Unique Innovation Unique Innovation (企業が顧客に提供する価値) OSSが主に対象とする領域 Delivery Support for the the Innovation innovation インナーソースが対象とする領域 (価値提供に必須の技術) Commodity Platform Commodity Platform (導入するだけでOK) Ref: How to Contribute to the Linux Kernel, and Why it Makes Economic Sense (James Bottomley, Novell; LinuxCon Japan 2009) 会社内なら外に出せない「共通課題」も解決できる！ © 2026 Toshiba Corporation 63
60. こんな経験はありませんか？ • 一緒にやってるプロジェクトで他チームを待っていたら遅れた ・・・ • バグを見つけて、通知したのに何時まで経っても直ってこない ・・・ • 似たような機能を作ってしまい、両方メンテナンスしないといけない ・・・ © 2026 Toshiba Corporation 65
61. こんな経験はありませんか？ ケース 同じ会社にある二つのチームが、別々のソフトウェア部品を提供する時、 片方のチームのソフトウェアが、もう一方のチームのソフトウェアに依存する状況 表示データ 提供API （未実装） チーム 例：表示用データを取得するAPIに依存するサービス 提供 データ表示 サービス ソフトの機能を使いたい！ 利用 チーム 直ぐには提供出来ない！ チームごとに事情は異なる ・機能の優先度 ・開発スケジュール など リクエストが届かない ケースはどうするか？ © 2026 Toshiba Corporation 66
62. こんな時、あなたならどうしますか？ １. 「静観」：黙っている メリット 作業を最小限に することができる デメリット ・要求された機能がいつまでたっても提供されない。 ２. 「回避」：勝手にやる メリット 要求機能が足りない部分を ローカルに変更・機能追加 して補える デメリット ・成果は同じ機能を必要としている他の利用者に提供されない ・本来の役割範疇でないコードを長期的にメンテナンスしなければならない ・会社全体として、同じ課題に対する重複したプロジェクトとコードを取得してしまう ３. 「圧力」：上層部を通してやらせる メリット 必要な機能が手に入る (かもしれない) デメリット ・圧力という開発に関係のない作業に注力しなければならない。 ・何度も使えるものでもなく発展しない。 ・チーム間や個人間の信頼を損なう。 © 2026 Toshiba Corporation 67
63. インナーソース なら、まとめて解決できます！ インナーソース で全ての欠点を解決して効果を得よう！ • エンジニア同士が新しいさまざまな技術やバラエティに 富んだ人々と一緒に仕事をする事ができる DevEx(*)向上 • 共通の課題に対する解決方法を再利用することで、 組織に高い価値を生み出すことに集中できる 開発効率向上 コスト削減 ・・・ でも、そもそも インナーソース って？ (*) Developer Experience © 2026 Toshiba Corporation 68
64. インナーソース とは？ • インナーソース は、企業内のソフトウェア開発にオープンソースの実践と ベストプラクティスと原則を適用したものです。 • インナーソース ソフトウェアは、会社としてはプロプライエタリなものとなりますが、 内部にはオープンで、誰もが利用したり貢献したりできるようになります。 Open all artifacts! つまり ・・・ Welcome visitors! ・・・ を企業内で実践することです。 Dirk Riehle, Inner Source (Software Development), InnerSource Summit 2018 © 2026 Toshiba Corporation 69
65. 野望：こんな世界を会社の中（日本中の企業の至るところ）に作りたい！ 今まで 目指す姿 サイロごとに閉じている 何をしているか自部門以外のことは知らない サイロを取り払い、コラボレーションが各所で発生！ © 2026 Toshiba Corporation 70
66. どのように インナーソース は機能するのか？ ケース Aチームが提供するソフトウェアをBチームが利用する場合 ホスト 機能を使いたい！ ゲスト チーム 期限内に実装して Bチームにリリースすることはできない・・・ チーム A 提供 「コントリビューション」をします！ レビューして 取り込む 利用 B 欲しい機能を 実装して送る 依頼して待つ関係から、一緒に作る関係へ © 2026 Toshiba Corporation 71
67. インナーソース の効果とは？ 開発の利点 チーム A 〔ホスト〕 チーム B 〔ゲスト〕 ・ニーズが確定している機能を受け取れるので、 良いプロダクトを作るための支援 となる 必要な機能 が手に入る ・スケーラブルな戦略ができるようになる 品質向上 ・必要とする時と場所に エンジニアリングの時間を 有機的に投入することが可能 OK! ・全ての利用者との間で優先順位の 調整を行うことができる 長期メンテナンスの負担をせず、 必要な時に機能要求を手に入れられる 必要な機能 が手に入る 要求X 要求Y 要求Z 戦力倍増する リソース配分を最適化できる 機能X 機能Y 機能Z 会社 余力ができ、他へ注力できる © 2026 Toshiba Corporation 72
68. インナーソースとは？結局何がよくなる？何をよくしたい？ インナーソース ＝ オープンソース開発の「方法(考え方)」を企業組織に適用する取り組み インナーソース実践 経営的な成果の例（Outcome） コードの再利用 開発コスト削減・リードタイム短縮 オープンなレビュー文化 品質・セキュリティ向上 ナレッジの共有 組織学習の促進・人材育成・リードタイム短縮・品質向上・・・ サイロの打破 横断的協業 × 部門連携強化 インナーソースは単なる「ソースコードの共有」に留まらず、 「知」の共有という「考え方」を用いて開発や組織によりよい「成果」をもたらすことが目的 © 2026 Toshiba Corporation 73
69. 実際のインナーソースはどのように機能する？ 課題の共有が 最初のステップ オープンな場 実装(コード、ドキュメント) 課題解決のアイデア 賛同者 （有識者） 課題 提案者 賛同者 （開発者やユーザー） © 2026 Toshiba Corporation 74
70. インナーソース ケーススタディ © 2026 Toshiba Corporation 75
71. ケース#1:全社向け共通Linuxディストリビューション プライベート環境 Linuxディストリビューション 開発部門A 開発部B 開発部門C Linux This 開発チーム © 2026 Toshiba Corporation 76
72. ケース#1:全社向け共通Linuxディストリビューション プライベート環境 複製 Linuxディストリビューション 開発部門A 開発部B 開発部門C Linux This 開発チーム © 2026 Toshiba Corporation 77
73. ケース#1:全社向け共通Linuxディストリビューション オープン環境 Linuxディストリビューション 設定 開発部門A 開発部B 開発部門C Linux This 開発チーム © 2026 Toshiba Corporation 78
74. ケース#1:全社向け共通Linuxディストリビューション オープン環境 請負業者A Linuxディストリビューション 開発部門A 開発部B 開発部門C Linux This 開発チーム 請負業者C プロダクトチーム © 2026 Toshiba Corporation 79
75. ケース#1:全社向け共通Linuxディストリビューション オープン環境 開発部門D Linuxディストリビューション 請負業者A 開発部門A OSSコミュニティ 開発部B 開発部門C Linux This 開発チーム 請負業者C プロダクトチーム © 2026 Toshiba Corporation 80
76. ケース#1:全社向け共通Linuxディストリビューション インナーソースの原則は標準化と再利用を加速させました 背景 ⚫ 複数の事業部門がLinuxを必要とした → Linux適用における共通の課題もあった アプローチ ⚫ 全社オープンでアセットをリリース ⚫ 改善提案は、メールやプルリクエスト、イシューを通して受け付け 結果 ⚫ 社内標準化したことで開発効率が向上 ⚫ 外部パートナーと連携して開発する際にもバグ報告を受け付けたことで品質向上 ⚫ 再利用性が向上し、複数の事業部で適用コストが削減 ⚫ 社内から上流のOSSコミュニティへ容易に貢献が可能 © 2026 Toshiba Corporation 81
77. ケース#2:技術中計の策定 オープン環境 企業 SNS Teams / OneDrive (どなたでも参加可能) プロダクトオーナー マーケティング レビュー/ 承認 コメント 共有/コメント/修正/返信 コメント/要件/提案 マネージャー/メンバー 他の部署から。 レビュアー 監督 リーダー メンバー © 2026 Toshiba Corporation 82
78. ケース#2:技術中計の策定 (背景と影響) 計画は立場を超えて本来必要とする人に届いてこそ価値を持つ 背景 ⚫ 共通技術部門は複数事業の利益となる技術を開発 ⚫ 技術中計の策定において文書と意思決定プロセスの両方を会社全体に公開 ⚫ 「誰でもコメントできる環境」を作り、透明性を確保 ポジティブな影響 ⚫ 事業部門からの多様なフィードバック取得に成功 ⚫ 異なる視点が入ることで優先順位や盲点が明らかになった ⚫ 自部門の活動の可視性を高めたことで、潜在的な協力者を生み出した ⚫ オープンな議論の文化を築くことに興味を持ってくれるメンバーが現れた © 2026 Toshiba Corporation 83
79. ケース#2:技術中計の策定 (失敗と教訓) 閉ざされた部屋で議論した結果の回答は不信感を生み、議論も進歩も生まない 失敗 ⚫ 最初のコメントへの反応は遅く(1週間以上も何の対応がないことも) ⚫ コメントをくれた人に見えないところで結論を出してから回答 ⚫ 既存の立場を擁護する方向に偏りがちで、新しい代替案の提案が不足 学んだこと ⚫ フィードバックには何かしら即対応 ⚫ （中で長く議論するより）議論の過程を見える化することの重要性を改めて認識 ⚫ コミュニティ視点から対話のための空間をデザインすることの重要性 © 2026 Toshiba Corporation 84
80. ケース#3:技術カタログ オープン環境 テックカタログ ソースリポジトリ テックカタログ ポータル レビュー &マージ 展開 プルリクエスト 信頼されるコミット 作成とプルリクエスト フィードバック ユーザー メンバー/寄稿者 プロダクトオーナー © 2026 Toshiba Corporation 85
81. ケース#3:技術カタログ 静的文書から生きた知識に 概要 ⚫ 社内共有用の技術カタログをMarkdownベースの文書で作成 ⚫ ブラウザからアクセス可能;プルリクエストを通じて提出された改善提案 役割の明確化 ⚫ プロダクトオーナー: カタログ全体の監督 ⚫ トラステッドコミッター: PRをレビューし、一貫性を確保する ⚫ コントリビューター: コンテンツや修正を作成してPRを通して提出 ⚫ 低摩擦での改善:「何か問題があればPRで直す」と、参加を促します 結果 ⚫ 編集履歴の透明化 → 編集の理由が判断できる ⚫ 気づいた人が自分で直す → 更新のボトルネックを回避 ⚫ オペレーションの単純化による活動継続性の確保 © 2026 Toshiba Corporation 86
82. ケース#4:Marpテンプレート (社内展示でコミュニティ構築) Markdownで 記載した スライドの内容 企業向けスライド スタイルテンプレート 参考:https://marp.app/ © 2026 Toshiba Corporation 88
83. ケース#4:Marpテンプレート (社内展示でコミュニティ構築) 「痛みを取り除く」というシンプルな解決策は広まりやすい 概要 ⚫ OSSのMarpを採用 → シンプルなテキストスライド作成を加速させたいという要求を解決 ⚫ 企業フォーマットに合わせたテンプレートを作成して公開 スケールへのアプローチ ⚫ ユーザー募集や改善提案の収集に向けたポスター ⚫ 初期段階:多くのフィードバック→後期段階:安定した使用継続 結果 ⚫ 企業形式のマークダウンベースのスライドが簡単に作成できるようになった ⚫ フィードバックによりテンプレートの品質が大幅に向上 ⚫ 長期的にはメンテナンスが少なくなっているが、ユーザーにとっては高い持続的価値をもたらす © 2026 Toshiba Corporation 89
84. 企業におけるインナーソースの推進 どのように実現するか？ © 2026 Toshiba Corporation 90
85. インナーソースを始めたモチベーション 内向きなモチベーション 外向きなモチベーション 似たようなことをするなら 一緒に解決したい！ 日本の企業文化を 変えたい！ 興味 危機感 社会と組織を変革する 日本も会社も元気にする！ © 2026 Toshiba Corporation 91
86. 再掲：こんな世界を会社の中（日本中の企業の至るところ）に作りたい！ 今まで 目指す姿 サイロごとに閉じている 何をしているか自部門以外のことは知らない サイロを取り払い、コラボレーションが各所で発生！ © 2026 Toshiba Corporation 92
87. インナーソース Way Playbook 小さく始めて、透明性を保ち、貢献を可能にし、共に支えながら成長する ステップ 何をすべきか なぜ重要なのか 1. 「誰のためか」を定義する 対象のユーザーやチームを明確にする 誰が得をするかが分かれば、共有すべ きものが明確になる 2. 小さく、でもオープンに始める 1つの資産と2チーム（または個人）から始め、 他の人も使えるようにする 安全に試せて、参加しやすく、抵抗が 小さい 3. 透明にする ソース、議論、決定、経緯などの「知」を すべて見える化する 透明性が信頼と再利用を生む 4. 貢献ルールを決める （POとTCのSLAも） IssueやPRの出し方と応答時間 （例：48時間以内）を決める 応答が信頼できて初めて貢献は続く 5. 役割の明確化 プロダクトオーナー、Trusted Committerなど の役割を割り当てる 「オープンだが無管理」を防ぐ 6. 指標を測り共有する PR数、採用、統合までの時間、貢献者の広が りを追う 成果が見えれば、支援も予算も付きや すい 7. 支援を得てスケールさせる 成果と予算を確保し、正式な後ろ盾を得る 拡大には熱意だけでなく仕組みが要る © 2026 Toshiba Corporation 93
88. 個人やチームで始める、小さな一歩 まず、この3つから STEP 1 目的を定めて小さく開始 自分たちのリポジトリを、まず社内に開く。いき なり全社制度にしなくても大丈夫。 STEP 2 STEP 3 入口を用意する 一度、越えてみる READMEと貢献の手順を書く。ゲスト が迷わないように。 隣のチームの困りごとに、一度だけ手を 出してみる。 続けるために必要なこと 貢献が評価される仕組み オーナーを、決めておく 評価されない貢献は、続かない。 誰が対応しているかがが曖昧だと、必ず止まる。 技術だけでなく、文化と仕組みの最低限を「小さく」決めておく © 2026 Toshiba Corporation 94
89. 組織で始める際に備えておきたい3つの武器 解決する課題 (場としての) システム Github、 GitLabなど (実践可能な) ルール 「やってもOK」を 明示する マインド ここが難所！ 人 © 2026 Toshiba Corporation 95
91. © 2026 Toshiba Corporation 97
92. そして暗躍 ① InnerSource Learning Pathを 全て翻訳！（Upstream first!） ② CodeZineに記事執筆 ③ InnerSource Commons Japan Meetupで発表 引用元：https://innersourcecommons.org/ja/learn/learning-path/ https://codezine.jp/article/detail/14809 https://innersourcecommons.connpass.com/event/271207/ © 2026 Toshiba Corporation 98
93. （武装する）インナーソースを広める武器一覧 仲間と 翻訳 発表 仲間と 翻訳 翻訳・執筆 Ref: InnerSource Commons: エンジニアの組織内コラボレーションを加速する - イベント一覧 https://innersourcecommons.org/ © 2026 Toshiba Corporation 99
94. （武装する）インナーソースを広める武器一覧 仲間と 翻訳 発表 ここがたりない！ 仲間と 翻訳 翻訳・執筆 © 2026 Toshiba Corporation 100
95. （武装する）集まって考えた・・・ © 2026 Toshiba Corporation 101
96. （武装した）みんなで歌を作った Ref: KDDIアジャイル開発センター 共創未来インナーソースマン feat. InnerSource Commonsコミュニティ - YouTube © 2026 Toshiba Corporation 102
97. インナーソースを広める武器一覧 © 2026 Toshiba Corporation 103
98. ニフティ株式会社のインナーソース活動開始に（いつのまにか）貢献 引用：https://engineering.nifty.co.jp/blog/31556 © 2026 Toshiba Corporation 104
99. ニフティ株式会社のインナーソース活動開始に（いつのまにか）貢献 良いことだけでなく、うまくいかない 事もノウハウとして 公開してくれた 引用：https://engineering.nifty.co.jp/blog/31556 © 2026 Toshiba Corporation 105
100. 三菱電機株式会社のインナーソース開始とOSPO＆ISPO設立に貢献 とってもポジティブな フィードバックがもらえた！ Ref: https://www.linkedin.com/posts/oidate_im-excited-to-announce-that-im-taking-on-ugcPost-7312669076802215937-7Njz © 2026 Toshiba Corporation 106
101. 外堀から埋めていく・・・ © 2026 Toshiba Corporation © 2026 Toshiba Corporation 107 107
102. 4-4. AI時代のインナーソース AIが人と知をつなぐ 今も「共創」 ― AIが、開いた土台の上の共創を加速する © 2026 Toshiba Corporation 108
103. AI時代のインナーソース ―「ソース」の定義が広がる これからの「ソース」 ドキュメント化されたすべて、つまり「知」 これまでの「ソース」 ソースコード ADR：設計 判断の記録 プロンプト・ スキル定義 なぜ、この設計に したのか AIへの指示 そのもの 議事録・議論 のログ 決まるまでの文脈 … その他 諸々 ADR: Architecture Decision Record AIは、コードだけでなくこの「知」を食べて動く © 2026 Toshiba Corporation 109
104. 人間中心から、AIネイティブへ ― 価値転換マトリックス 観点 これまで（人間中心） これから（AIネイティブ） 主役となる資産 ソースコード ADR、プロンプト、規約、意図など すべてのドキュメント・知 人間の役割 ロジックを書く 生成物を検証、審判し、指示をする 知の扱い 局所的・属人的な蓄積 AIがアクセスできる透明な資産 発見の方法 人間が検索して探す AIが文脈に合わせて届ける インナーソースの価値は、AI時代にむしろ上がる © 2026 Toshiba Corporation 110
105. AIはデータの断片化を嫌う ― サイロが生産性を殺す AIが力を出す前提は、コード・設計判断・議論ログなどの「知」が途切れず繋がっていること 縦割りのサイロは、AIにとってもコンテキストの断絶になる つながっていないことで生まれる類似成果による負債 保守 障害対応 AIコスト 分断されたままではAIも力を出せず、高い生産性が技術的負債を生むリスクに © 2026 Toshiba Corporation 111
106. ガバナンスのジレンマ ― 閉じるか、開くか アクセス権限を絞り情報を閉ざせば、AIの生産性は死ぬ。 かといって全開放はできない ― だから「峻別」する。 真の秘匿情報 組織の知恵 個人情報・絶対的機密 社外秘だが、社内には公開できるもの ▼ ▼ 厳格に保護する デフォルト・社内オープン 厳格な保護範囲を抑えつつ、AIが学べる面積を最大化する © 2026 Toshiba Corporation 112
107. 「背中を見て覚えろ」からの卒業 これまで 探しに行く これから _ AIが、文脈に合わせて届けてくれる 日常の活動から自然に知恵を抽出し、誰でも使える形式知に変換する 今日から取り組めること 再利用ファースト 意図を伝えて残す 審美眼を磨く AIに生成させる前に、 社内の共有資産を当たる たとえばADRを残すことを、 開発プロセスに組み込む 目利きAIを育てるコミュニティを、 組織横断で 暗黙知を、人もAIも使える形式知へ © 2026 Toshiba Corporation 113
108. AIが、境界を越えるときの摩擦を下げる 越境のコストは、いつも「文脈が分からないこと」だった 読み解きを代行する 越境が速くなる ただし、前提がある 他部署のコードや設計判断を、 AIが橋渡しする 部門横断のコード検索・レ ビュー・オンボーディングが加速 文脈が途切れているとAIも力 を出せない 共有すべき資産は、コードから「意図」へ⇒すなわち「知」 AI時代においてインナーソースは知を循環させるインフラとなる © 2026 Toshiba Corporation 114
109. 難所：オープンにすれば済む、わけではない ① オープンには、責任が付いてくる ② 失敗するのは技術ではなく、文化 供給網の責任 サプライチェーンセキュリティ 過剰な「社外秘」 知もAIも、閉じ込めてしまう 出所の管理 SBOM、ライセンスと出所の追跡 オーナーシップ 引き取り手が曖昧だと止まる 規制との関係 CRAとは、裏表の関係にある インセンティブ 評価されない貢献は続かない ここは私自身、何度も失敗してきた・・・ 環境やルールがあっても人が付いてこないとAIも人も動けなくなる © 2026 Toshiba Corporation 115
110. オープン化が進むとAIがコラボレーションを加速する！ オープンな場 課題の共有が 最初のステップ 知＝実装(コード)や文書などの成果物 課題解決のアイデア 賛同者 （有識者） 課題 提案者 AIが人と課題と 実装をつなぐ 賛同者 （開発者やユーザー） ハーネス大事！ © 2026 Toshiba Corporation 116
111. 5. Conclusion AI時代のキョウソウ戦略 © 2026 Toshiba Corporation 117
112. AI時代の価値創造サイクル ― 開いた土台の上で回る 変わらないのは3つの領域。 変わるのは「開き方」。 ひらく OSS・インナーソース（知） 「ソース」とは、知そのもの。 出会う 創る 他部門・社外の知と Delivery Supportは、社外 のOSSで仲間と創る。 Unique Innovation 競争領域も、社内に開いてこそ 加速する。 肝は、人と人。 コラボレーションとコントリビューションが、この循環を回す。 AIが、ひらく・出会う・創るの3つすべてを加速する © 2026 Toshiba Corporation 118
113. 3～5年後、組込み開発の現場はこうなっている（いてほしい！） 「開いた土台」が当たり前になった日常。 変わるのは道具より作法。 過程の公開 AI検証 インナーソース 設計判断が標準成果物 「なぜそう決めたか」がコードと一 緒にレビューされる レビューの主役が交代 人は意図と前提の 妥当性を見る 社内公開リポジトリが増加 部門を越えたPR・Issueが 日常化 残す・任せる・開く。 この3つが習慣になった現場が、いちばん速い。 判断を残し、検証を任せ、リポジトリを開く現場が標準になる © 2026 Toshiba Corporation 119
114. もうひとつのキョウソウ AIがどれだけ速くなっても、価値を生むのは人と人が寄り添うこと 01 02 03 隣に、手を伸ばす 知を、置いておく 感謝を、返す 隣のチームの困りごとに、 手を伸ばす 自分が持っている「知」を、 誰もが探せる場所に置く 誰かの一歩に、 レビューと感謝を返す すなわち 「今日添う」 AI時代だからこそ仲間を大切に！ © 2026 Toshiba Corporation 120
115. Think OPEN 121 © 2026 Toshiba Corporation 121 © 2026 Toshiba Corporation
116. Questions? © 2026 Toshiba Corporation 122 © 2026 Toshiba Corporation
117. © 2026 Toshiba Corporation
118. © 2026 Toshiba Corporation
119. © 2026 Toshiba Corporation 125