# 10年使える計算プラットフォームの選び方 ― IDEMIA の Kyle Larson 氏に聞く

- 番組: [The AI in Business Podcast](https://ai-curator.jp/podcasts/shows/cmv3z5c32001o5o100ot70lmn)（Daniel Faggella）
- 元のタイトル: How to Choose a Compute Platform Your Products Won't Outgrow - with Kyle Larson of IDEMIA
- 配信日: 2026年11月12日
- 長さ: 20分
- 要約作成日: 2026年11月12日
- トピック: [#ハードウェアとソフトウェアの統合](https://ai-curator.jp/topics/%E3%83%8F%E3%83%BC%E3%83%89%E3%82%A6%E3%82%A7%E3%82%A2%E3%81%A8%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%81%AE%E7%B5%B1%E5%90%88) [#エッジコンピューティング](https://ai-curator.jp/topics/%E3%82%A8%E3%83%83%E3%82%B8%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0) [#シミュレーション](https://ai-curator.jp/topics/%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3) [#デジタルツイン](https://ai-curator.jp/topics/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%84%E3%82%A4%E3%83%B3) [#開発者ツール](https://ai-curator.jp/topics/%E9%96%8B%E7%99%BA%E8%80%85%E3%83%84%E3%83%BC%E3%83%AB) [#計算プラットフォーム選定](https://ai-curator.jp/topics/%E8%A8%88%E7%AE%97%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E9%81%B8%E5%AE%9A)
- URL: https://ai-curator.jp/podcasts/cmwd7sh9t00006x122zbk5399

## 要約

IDEMIA の VP（AI Enablement and Cloud Services）Kyle Larson 氏が、ハードウェアとソフトウェアを別々のトラックで作る時代は終わったと語る回。両者は顧客に届く「ひとつの製品」として計画すべきだとし、エッジとクラウドの切り分け、シミュレーションや開発ツールの先行整備、10年単位のチップ選定の考え方を、自身の経験を交えて説明している。

## ポイント

- Larson 氏は、ハードとソフトが完全に分断された時代は終わったと述べ、両者を顧客に届く一つの製品として見るべきだとしている。
- 処理をエッジで行うかクラウドで行うかは、信頼性とレイテンシ（遅延）が主な判断軸で、すべてをエッジに載せる必要はないという。
- AI でソフト開発が速くなっても、顧客が価値を得るのは機器の設置や運用準備まで含めて届いた時点であり、ソフト完成は一つのマイルストーンにすぎないと指摘した。
- 物理試作を待たずに済むよう、デバッグ、自動テスト、API 複製、デジタルツインなどの開発ツールを整えるべきで、シミュレーションは不完全でも実施する価値があると述べた。
- 長期のチップ選定は、できれば避けるのが第一で、避けられない場合はツール、スキル、サプライヤーの支援とロードマップまで含めたエコシステムで評価すべきだとしている。

## 章立て

- [02:06] **ハードとソフトの分断は終わった** — 車両や機械でソフトとAIが増え、両チームは継続的なパートナーであるべきだと説明。顧客に届く一つの製品として捉える重要性を語る。
- [04:07] **チームの対立と顧客への影響** — ソフト側は効率や性能、ハード側はコスト効率を最適化し、メモリや計算資源が不足するなど対立が起き、そのしわ寄せが顧客に及ぶと述べる。
- [05:05] **エッジとクラウドの切り分け** — 信頼性とレイテンシの観点から、即応が必要な処理はエッジで行い、それ以外は効率的な場所で処理すべきだと説明。
- [06:26] **ソフトの速度とハード・展開の現実** — AIでソフト開発は加速するが、DMVへの機器導入の例のように、顧客への展開は機器や運用準備に依存すると語る。
- [08:30] **シミュレーションと開発ツール** — デジタルツインやデバイスファームなどで事前に検証する価値を議論。モバイル運転免許証の例で、テストにより多くの不具合を事前に拾えると述べる。
- [11:51] **初日から必要なものと10年の選定** — 双方向のロードマップの可視化とツールが必要。長期のチップ選定では、エコシステムとサプライヤーの将来像を評価すべきだと語る。
- [18:18] **まとめと最後の提言** — ハードとソフトの速度は揃わないため、単一のロードマップ、早期フィードバック、共有された責任でつなぐのがリーダーの役割だと締めくくる。

## 解説記事

IDEMIA で AI Enablement and Cloud Services を率いる Kyle Larson 氏が、The AI in Business Podcast に出演し、ハードウェアとソフトウェアの開発をどう結び付けるべきかを語った。車両、工場機械、コネクテッドデバイスでソフトウェアと AI の比重が高まる中、ハードが別チーム・別スケジュールで作られる体制の問題点と、長期の計算プラットフォーム選定の考え方が主題である。

#### 「ひとつの製品」として届ける

Larson 氏は、ハードとソフトが完全に分断されていた時代はもう終わったとの認識を示す。同じチームが両方を担う必要も、同じ開発スケジュールに揃える必要もないが、顧客に届くのは一つの製品なので、両者を一体として見るべきだという。AWS で自動車や製造業の業界向け事業を手掛けた経験から、コネクテッドカー、自動運転、スマートファクトリーのようなエンドツーエンドの用途では、物理環境を抜きにソフトの議論はできなかったと述べている。

両チームが最後まで噛み合わないと、しわ寄せは顧客に行くと同氏は言う。ソフト側は実環境やハードを十分考慮せずに効率や性能を最適化しがちで、ハード側は自らの効率を優先するあまり、ソフトに必要なメモリや計算資源、環境要因への対応が足りなくなることがある。両者が個別に最適化すると互いに衝突するという見方だ。

#### エッジかクラウドか

処理をどこで行うかの判断軸として、Larson 氏は信頼性とレイテンシ（遅延）を挙げる。クラウドも信頼できるが、端末上で動かすほうが確実であり、わずかな遅延も許されない処理はエッジ（端末側）で動かす必要がある。自動運転で通信が途切れたらどうなるか、という例が示された。一方で、すべてをエッジに載せる必要はなく、遅延や接続性が本当に重要な部分と、他で効率的に処理できる部分を切り分けるべきだとしている。

#### ソフトが速くなっても、顧客への到達は別問題

AI によりソフトの新機能は数日で作れるようになったが、新しいチップの設計・製造には今も数年かかる。Larson 氏は、ソフト開発の完了は顧客への提供プロセス全体の一つのマイルストーンにすぎないと強調する。IDEMIA は米国の多くの州と取引があり、AI でソフト開発の速度が上がったことは疑いないが、州の DMV（運転免許関連の窓口）では、カメラ、プリンター、PC といった機器を現場に導入し、ソフトを統合し、数年にわたり支援できる運用体制まで整えて初めてサービスが成立するという。

#### 物理試作の前に検証する

だからこそ開発者ツールは「二級市民」であってはならないと同氏は述べる。デバッグ、自動テスト、小規模プロトタイプ、API の複製、さらに実機データをもとに工場などの物理環境を再現するデジタルツインがその例である。最終的な試験は展開時に行われ、シミュレーションは完全にはなり得ないが、まったくテストしないよりはるかに良いと主張した。

具体例として、州向けのモバイル運転免許証を挙げる。ソフトは標準的なプラットフォーム上で比較的単純だが、iPhone 17 か Samsung かなど端末ごとに挙動が変わる。AWS Device Farm のようなサービスで仮想的にテストすれば多くの制約を事前に発見でき、実機に載せた段階で残る不具合は2割ほどになる、という例え話だった。

開発初日に必要なものとして、同氏は双方向の可視性を挙げる。ソフト開発者はサプライヤーや社内のハードのロードマップを把握し、ハードチームは今後2〜3年にソフトが何を必要とするかを理解する。加えて、実機に近い検証環境と、本番環境からのリアルタイムのフィードバックが重要だとしている。

#### 10年のチップ選定をどうするか

10年単位のプラットフォームを選ぶ場面について、Larson 氏の第一の答えは「可能なら避ける」である。オンデマンドサービスなど短期で入れ替えられる手段があるなら、そちらが望ましい。7〜8年先のソフトの姿は予測しにくいためだ。避けられない場合は、プロダクトへの長期コミットとして扱い、どれだけ進化の余地を確保するかを事業に即して見積もる。AI 対応のアクセス制御システムのように、ハードは頻繁に交換したくないが、顔認識などの AI は進化し続ける、という緊張関係がある。ハードが進化のボトルネックになってはならないという。

評価の手順としては、製品に必要な能力から逆算し、本番を想定した負荷や障害で試し、開発ツール、ソフトの機能、エンジニアのスキル、サプライヤーの支援まで含めて判断する。ハード単体ではなく、周辺のエコシステムが成否を左右するという。さらにサプライヤーには、信頼性に加え、ロードマップへのアクセスと将来の支援への確信が必要だと述べた。

#### まとめ

本エピソードの要点は、速度の違うハードとソフトを、単一のロードマップ、早期のフィードバック、共有された責任でつなぐのがリーダーの役割だという点にある。日本の製造業や自動車産業のように、ハードとソフトの開発文化が異なる組織にとって、仮想環境での先行検証や、スペック表ではなくエコシステムとサプライヤーの将来像で判断する視点は参考になるだろう。なお内容は Larson 氏個人の見解であり、IDEMIA の公式見解ではない旨が番組冒頭で断られている。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: The AI in Business Podcast「How to Choose a Compute Platform Your Products Won't Outgrow - with Kyle Larson of IDEMIA」