見出し画像

人材はいる？技術は、会社に残っているのか？Python、組み込み経験、顧客現場から考えるフィジカルAI企業の条件

一般財団法人 木村潤 記念財団

「AIエンジニア100人在籍！」

企業の採用情報や事業紹介で、このような説明を見かけます。

100人という数字は、採用力や事業規模を知る手がかりになります。ただ、その100人がどの領域を担い、どの工程まで責任を持てるのかは分かりません。

AIモデルを開発できることと、センサーやモーターを含む実機を動かし、障害時に原因を切り分けられることは別の能力です。

反対に、組み込み技術者が多数いても、AI、データ、クラウド、顧客業務までを一つの事業として成立させられるとは限りません。

問題は、PythonとC++などのプログラミングスキルが優れているかではありません。

個人の技能を、別の人が次の案件でも再現できる会社の能力へ変えられているかです。

本稿の「100人」は、特定の企業を示す数字ではありません。
AI人材の人数を企業能力の説明に使うとき、何が見え、何が見えなくなるのかを考えるための思考実験です。

フィジカルAIを標榜する企業が担う仕事は、一般向けに次の六つへ整理できます。

見る・聞く。
考える。
動かす。
止める。
つなぐ。
続ける。

今回は、この六つを担う人材と、その経験を会社の能力へ変える条件を考えます。


「AIエンジニア」は、一つの職種ではない

「AIエンジニア」という言葉から、どのような仕事を想像するでしょうか。

データを分析する人かもしれません。
機械学習モデルを設計する人、画像認識や生成AIアプリケーションを開発する人、データ基盤やMLOpsを担う人もいます。
フィジカルAIに近づけば、エッジAI、シミュレーション、ロボット学習なども含まれてきます。

同じ肩書でも、担当している技術、扱うデータ、顧客との距離、責任を持つ工程は大きく異なります。

生成AIを利用した業務アプリケーションを作る仕事と、カメラ画像から対象物を認識する仕事は同じではありません。
学習用データを整備する仕事と、工場内の機械を一定の周期で制御する仕事も異なります。
それでも企業紹介では、複数の専門領域が「AIエンジニア」という一つの人数へまとめられることがあります。

人数を数えること自体が間違いなのではありません。

ただ、人数だけでは、会社がどの責任を引き受けられるのか分からないのです。

経済産業省が2025年に公表した報告書でも、職種名や資格だけで人材を捉えるのではなく、具体的なスキルを可視化し、採用、評価、育成へ活用する「スキルベース」の方向が示されています。

「AIエンジニア」という呼称には、データ、モデル、運用、エッジ、ロボット学習など、異なる専門領域が含まれます。

Pythonは、フィジカルAIでも重要である

フィジカルAIの話になると、ときどき「Pythonでは実機を動かせない」「これから必要なのはC++や組み込みだ」という二者択一が語られます。

しかし、この整理は正確ではありません。

Pythonは、フィジカルAIでも重要な役割を持っています。

Hugging Faceが公開するLeRobotは、PyTorchを使い、実世界のロボティクスを対象としたモデル、データセット、学習・評価用ツールを提供しています。公式資料では、ロボットの遠隔操作、実機データの収集、ポリシーの学習、評価までが扱われています。

Pythonは、学習データの処理、モデルの訓練と評価、画像やセンサー情報の解析、シミュレーション、実験、運用データの分析などで使われます。

学習済みモデルによる行動生成や、上位のタスク計画にも関わります。
つまり、PythonはフィジカルAIの外側にある言語ではありません。

AI、データ、学習、評価を支える中心的な道具の一つです。

ただし、Pythonが重要であることと、Pythonだけでロボットシステム全体を引き受けられることは別です。

一日に一度実行する集計処理と、決められた周期で機械を制御する処理では、要求される応答時間や遅延への許容度が異なります。

天晴氏はnoteの記事「Pythonと組込み開発」で、一日に一度の処理と、一定周期で繰り返す制御処理を対比しています。

重要なのは記事内の個別の処理時間ではなく、処理の目的と制約によって、選ぶべき言語や実行環境が変わるという考え方です。

また、リアルタイム性はプログラミング言語だけで決まりません。

OS、スケジューラー、メモリ管理、通信、実行環境、処理の分割を含むシステム全体で、必要な期限を満たせるかを設計します。

組み込み経験は、物理世界との接点になる

画面の中で完結するソフトウェアと、現実の機械を動かすソフトウェアには、共通する部分があります。

同時に、物理的な機械でなければ起きにくい問題もあります。

実機では、センサーのノイズ、電源投入の順序、通信断、温度上昇、メモリ不足、機体の個体差などが動作へ影響します。

机上では再現しなかった障害が、実機では発生することもあります。

更新の途中で通信が切れ、機器が正常に起動しなくなるかもしれません。

機械が動く以上、ソフトウェアの不具合が、画面上のエラーだけでは終わらない可能性もあります。

だからこそ、組み込みや制御の経験は、物理世界へ責任を広げようとする企業にとって重要な分岐になります。

ROS 2の公式資料は、リアルタイム処理について、単に平均速度が速いことではなく、必要な処理が定められた期限内に完了することが重要だと説明しています。ページフォールト、動的メモリ確保、期限のないブロッキングなど、処理時間の予測を難しくする要因にも注意が必要です。

ただし、ここでいう組み込み経験は、CやC++を書いたことがあるという意味ではありません。

組み込み経験といっても、マイコン上のファームウェア、RTOS、組み込みLinux、PLCを含む産業制御、エッジコンピューターでは、扱う制約も責任も異なります。

ハードウェアを含むシステムについて、どの制約を理解し、どの判断を行い、どの障害へ責任を持ったのか。

そこまで見て、初めて経験の中身が分かります。

「組み込み経験あり」の中身も、一つではない

企業の技術者紹介には、「組み込み開発経験10年」「車載開発の実績あり」「製造業向け案件多数」といった表現があります。

これらは重要な情報です。
しかし、年数や案件数だけでは、どの能力を持っているのかまでは分かりません。
同じ組み込み案件でも、担当範囲は異なります。

指定された機能だけを実装したのか。
ハードウェアやセンサーの選定から関わったのか。
全体の構造を設計したのか。
試験方法を決めたのか。
実機で発生した障害を解析したのか。
出荷後の保守や更新まで担当したのか。
安全、品質、顧客説明に責任を持ったのか。

組み込み経験を企業能力として見るなら、要件、ハードウェア選定、制御、統合、試験、安全、量産、保守、顧客説明、社内への知識蓄積といった範囲を確認する必要があります。

自動車、産業機械、医療機器、工作機械、ロボット、ドローンなど、要求水準の高い領域を経験していることは強みになります。

それでも、一部分を担当した経験と、製品やシステム全体の成立性に責任を持った経験は同じではありません。

案件数だけではなく、どの判断と失敗を引き受けたかを見る必要があります。

個人の経験と、会社の能力は同じではない

ある技術者が、顧客の工場で高度なロボット開発に携わったとします。
実機に触れ、センサーを調整し、障害を解析し、現場の作業者と改善を繰り返しました。
その経験は、その技術者にとって大きな財産です。

では、その技術者が所属する会社も、同じ能力を持ったと言えるでしょうか。

必ずしも、そうではありません。

案件で作成したソースコードや設計資料を、所属会社が別の案件で利用できるとは限りません。
成果物の権利や利用範囲は、契約、既存資産との関係、著作権の帰属、利用許諾などによって変わります。

学習データや障害ログが、顧客の設備や業務から生まれたものであれば、その取扱いにも制約があります。
試験設備が顧客の工場にしかなければ、所属会社で同じ検証を再現できないこともあります。
技術者本人には経験が残っても、会社に残るのは、職務経歴書の一行と「ロボット案件の実績」という営業上の表現だけになる場合があります。

ここで問われるのは、技術者の努力ではありません。

会社が、その経験を組織として再現できる状態へ変える仕組みを持っているかです。

別の人が同じ判断をできるか。
次の案件で応用できるか。
失敗の理由を説明できるか。
同じ誤りを避けられるか。
教育へ使えるか。
その人が退職した後も継続できるか。

会社の能力とは、複数の人が共有し、別の案件で再現し、検証し、継承できる状態です。

個人の技能を、会社の能力へ変える五つの条件

では、個人の経験を会社の能力へ変えるには、何が必要なのでしょうか。

ソースコードは重要です。
ただし、コードだけでは足りません。
コードがあっても、どの条件で使えるのか分からなければ再利用できません。
テスト方法がなければ、変更後の正しさを確認できません。
学習データの作り方が分からなければ、モデルを改善できません。
設計判断が記録されていなければ、なぜその構成になったのか分かりません。
権利が整理されていなければ、別の案件で使えるかどうかも判断できません。

必要な条件は、五つに分けて考えられます。

作る

コード、モデル、回路、設計、共通部品などを作ることです。
一回の案件で完成させるだけでなく、別の条件でも応用できる構造にできるかが問われます。

確かめる

テスト、評価指標、シミュレーション、実機試験などを通じて、正しく動くかを確認することです。
作れることと、成立性を証明できることは異なります。

学ぶ

データ、障害記録、失敗事例、評価結果、設計変更の履歴を、次の改善へつなげることです。
同じ失敗を繰り返さない仕組みも含まれます。

続ける

保守手順、レビュー、教育、引き継ぎ、複数人で対応する体制を作ることです。
特定の人がいなければ動かない状態から、組織として続けられる状態へ変えます。

使える状態にする

知的財産、利用許諾、データ利用権、OSSライセンス、顧客との再利用条件などを整理することです。
技術的に再利用できても、契約上使えなければ、会社の能力として展開できません。

この五つがそろって初めて、経験は一回限りの案件から、次の仕事でも使える会社の能力に近づきます。

フィジカルAIでは、ソフトウェアだけでなく、実機、試験設備、センサーデータ、現場の障害記録まで関係します。
そのため、「何を持っているか」だけではなく、何を使い、学び、再利用できるのかまで確認する必要があります。

個人の経験は、作る、確かめる、学ぶ、続ける、使える状態にするという工程を経て、会社の再現可能な能力へ近づきます。

顧客現場で得た経験を、会社の能力へ変える

ここまでの説明だけを読むと、顧客の現場で働く事業では、会社に何も残らないように見えるかもしれません。
しかし、それも単純化です。

顧客の現場へ長く関わるからこそ得られる知識があります。

実際の業務がどこで止まるのか。
現場がどの例外に困っているのか。
設備の仕様書には書かれていない癖は何か。
安全や品質について、顧客が何を重視しているのか。
システムを導入しても使われなくなる理由は何か。

こうした知識は、短期間の外部調査だけでは得にくいものです。
顧客との長期的な信頼関係や、業界固有の言葉を理解していることも、企業の価値になり得ます。

下記の記事では、AI時代のSIerの役割を、コードの納品だけでなく、判断品質、責任設計、業務設計、継続運用へ広げて考えています。

フィジカルAIでは、この視点を物理世界へ拡張する必要があります。

業務を知っているだけでなく、実機の制約、安全、保守までを、誰とどのように引き受けるかが問われるからです。

ここで、「SES」と「客先常駐」を同じ意味で使わないよう注意が必要です。

本稿では「SES」を、顧客へ技術者の役務を提供する事業の一般的な呼称として使います。

実際の契約には、請負、準委任、労働者派遣などがあり、完成責任、業務遂行上の責任、指揮命令関係はそれぞれ異なります。
客先常駐は働く場所の問題であり、契約形態そのものではありません。
請負として扱われるためには、受託側が自ら労働者を管理し、業務を独立して処理するなどの要件があります。契約書の名称にかかわらず、実際の指揮命令関係や業務実態が判断材料になります。
また、顧客の現場で得たものを、無断で自社へ移してよいわけではありません。

ソースコード、設計資料、データ、ノウハウ、知的財産の帰属や利用条件は、契約によって異なります。

IPAのモデル契約は、情報システム開発におけるユーザー企業とITベンダーの役割や責任、契約関係を透明化するために公開されています。

2026年6月には、公正取引委員会、中小企業庁、特許庁が、知的財産権だけでなく、ノウハウやデータも対象に含む取引指針と契約書ひな形を公表しました。

会社に能力を残すというのは、顧客の機密情報を持ち出すことではありません。

顧客固有の情報を除き、機密を含まない設計原則へ抽象化する。
契約で認められた範囲を共通化する。
汎用的なレビュー観点やテスト方法へ変換する。
同じ顧客との継続案件で、複数人へ引き継ぐ。
案件を通じて得た業界理解を、提案、要件定義、品質管理へ反映する。

問題は、顧客の現場で働くことではありません。
そこで得た経験を、権利を守りながら組織の能力へ変換する仕組みがあるかです。

組み込み能力がない会社にも、四つの道がある

すべてのAI企業が、組み込み、制御、機械、製造までを自社で抱える必要はありません。
不足している能力を把握したうえで、少なくとも四つの道を選べます。

ソフトウェア・運用層へ集中する

AIモデル、データ基盤、MLOps、業務システム、監視、ガバナンスなど、自社が強い領域に集中する道です。
ロボット本体を作らなくても、フィジカルAIの価値の一部を担えます。

組み込み・制御企業と提携する

自社で不足する実機、制御、安全、製造の能力を、専門企業と組み合わせます。
重要なのは提携発表ではなく、責任分界、共同試験、顧客対応、障害時の連絡系統を具体化することです。

採用・育成で補強する

経験者を採用し、既存のAI・データ人材とチームを作る方法です。
ただし、一人の専門家を採用しただけで、会社能力を得たと考えることはできません。
実機、予算、案件、仲間、意思決定権がなければ、その人の経験を生かせないまま終わる可能性があります。

M&Aで能力を取得する

人材、顧客、設備、知識を一体で取得する方法です。
ただし、買収先の売上や人数だけでは、どの能力が買収後も残るかは分かりません。
M&Aの判断と技術デューデリジェンスについては、連載の後半で詳しく扱います。

四つの道に共通するのは、すべてを内製する必要はないということです。
どの領域を自社の責任として持ち、どこを他社へ委ねるのか。
その境界を決めること自体が、企業の戦略になります。

フィジカルAIへ進む方法は、全面内製だけではありません。集中、提携、採用・育成、M&Aのどれを選ぶかは、自社が持つ責任の範囲によって変わります。

組み込み経験だけでも、事業は完成しない

ここまで、組み込み経験の重要性を見てきました。

しかし、組み込み技術者が多い会社なら、そのままフィジカルAI事業を成立させられるわけではありません。

組み込み企業にも、補うべき能力があります。
AIモデルやロボット学習。
データ基盤とクラウド。
ソフトウェアの製品化。
顧客業務の再設計。
利用者が無理なく使える体験。
保守を継続収益へ変える仕組み。
海外展開。
技術発信と採用。

IPAの2022年度調査では、回答企業が挙げた事業課題として、人材の確保・強化、収益性の向上、製品・サービス・技術の確保・強化が上位に並びました。

現在の人材需給を直接示す最新統計ではありませんが、組み込み企業側にも、人材と事業化の課題があることを示す資料です。

ロボット企業の採用情報を見ても、必要とされているのはAI研究者だけでも、組み込み技術者だけでもありません。

1Xの現在の採用ページには、AI、シミュレーション、フリート運用、ハードウェア、ロボット安全、製造、品質、フィールド信頼性、組み込みファームウェア、OS、クラウド、セキュリティなどにまたがる職種が掲載されています。求人は、その企業がすでにすべての能力を保有している証明ではありませんが、事業に必要と考えている領域を知る手がかりにはなります。

組み込み経験は、スタート地点を変えます。

しかし、それだけで到達点が決まるわけではありません。

分かれ道は、Pythonか組み込みかではない

人材が多い会社は、フィジカルAI企業になれるのでしょうか。

答えは、人数だけでは分かりません。

Pythonは、モデル、データ、学習、評価、シミュレーション、実機での行動生成などに関わる重要な技術です。

組み込み経験は、時間、電力、通信、センサー、実機障害といった、物理世界の制約を理解するうえで重要です。

どちらか一方を選べばよいのではありません。

異なる専門性をつなぎ、一つの顧客課題に対して、誰がどこまで責任を持つかを設計する必要があります。

そして、もう一つ重要なのは、その経験が会社の能力へ変わっていることです。

その人が辞めても続けられるか。
次の案件でも応用できるか。
別の顧客でも再現できるか。
失敗から学べるか。
使ってよいコードやデータが明確か。

人材の数を見るなら、その先まで見なければなりません。

人材がいる会社と、能力を持つ会社は同じではないからです。

ただし、すべての企業がフィジカルAI企業になる必要もありません。

実機制御へ進まず、データ、クラウド、運用、業務設計へ集中する選択もあります。

重要なのは、流行している技術を自社の看板へ加えることではありません。

自社が引き受ける責任と、他社に委ねる責任を決めることです。

連載第1回では、フィジカルAI企業に求められる見えない責任を、1Xの家庭用ヒューマノイドNEOから考えました。

次回は、能力を持つ会社が、実際にロボットを本番環境で安全に止め、状態を把握し、更新し、復旧させるには何が必要なのかを考えてみます。

連載一覧

関連マガジン

情報源・参考URL

一次資料・公式資料

note内の関連・参考記事

いいなと思ったら応援しよう！

一般財団法人 木村潤 記念財団 よろしければサポートお願いします！ いただいたサポートは本財団としての活動費に使わせていただきます！

この記事が参加している募集

#

仕事について話そう

18万件