フィジカルAIと従来のロボット・PLC自動化は何が違うか：発注側の判断が変わる4点

「フィジカルAIは従来のロボットと何が違うのか」を調べると、仕組みや活用例の説明は数多く見つかります。ただ、工場長や新規事業の担当者が知りたいのは、仕組みの差そのものより、「発注するとき、何を確かめ、何を先に決めておく必要が変わるのか」ではないでしょうか。この記事は、あらかじめ教えた動きを繰り返す従来の自動化（ロボットのティーチング、PLCによる制御）と、フィジカルAIとを、発注側の判断が変わる4つの点（例外への強さの確かめ方、必要なデータ、保守のしかた、責任の置き場）で比べて整理したものです。

どちらが優れているかの結論は出しません。製品名・機種名の比較、性能や市場の数値も扱いません。対象の作業によっては、従来の自動化で足りる場合も十分にあります。フィジカルAIの定義や生成AIとの違い、技術の解説は、すでに多くの解説記事があるため、ここでは発注の判断に絞ります。

この記事での言葉の使い方

従来の自動化とは、この記事では、人が動作や条件をあらかじめ決めて教え（ティーチング）、あるいはプログラム（PLCのシーケンス制御など）に書き込み、そのとおりに機器を動かす方式を指します。フィジカルAIとは、この記事では、現場の状態をセンサーで捉え、動作の一部をAIの判断で決めて、機械が物理的な作業を行う仕組みを指します。

両者は二択とは限りません。既存の制御や設備の上に、AIによる認識や判断を足す構成もありえます。以下は一般的な傾向の整理であり、実際の差は、対象の作業と構成によって変わります。

先に押さえる違い：動きを「書く」か、一部を「学ばせる」か

従来の自動化では、動きの中身を人が書きます。仕様書とプログラムを読めば、何をするのかを説明でき、想定外の状況は、停止や人の介入で扱うのが基本です。

フィジカルAIでは、動きの一部が、データから学んだモデルによって決まります。そのため、仕様書だけでは、あらゆる状況での挙動を説明しきれないことがあります。説明できない分は、試験と記録で確かめる部分が増えます。

この違いが、発注側の判断を変えます。「何を作るか」を決める前に、「何をどう確かめるか」「何を誰が持つか」を決めておく必要が出てくるからです。

比較表：発注側の判断はどこで変わるか

観点	従来（ティーチング・PLC）	フィジカルAI	発注側の判断が変わる点
例外への強さ	想定した例外を事前に洗い出し、条件分岐や停止で扱う。想定外は止める前提で設計する	学習した範囲では、状況の違いに対応できる可能性がある。一方、学習や試験に含まれない状況での挙動は、事前に読み切れない	「その機能があるか」の確認から、「どの範囲の変動で試し、外れたときにどう振る舞うか」の確認へ
必要なデータ	動作の記述（教示した位置、プログラム）が中心。教える人の作業時間が要る	現場の状態・動作・結果の記録が、学習や調整の材料になりうる。取り方、権利、機密の取り決めが要る	データを誰がどう取り、誰のものとし、何を外に出さないかを、発注の前に決める
保守のしかた	変更箇所（教示位置、プログラム、部品）を特定して直す。影響の範囲を追いやすい	モデルの更新や、環境・対象物の変化で、挙動が変わりうる。更新のたびに再確認が要る	更新時に何を再確認し、誰が判断し、版をどう記録するかを、運用の中に組み込む
責任の置き場	動作が仕様で決まるため、不具合の原因を、設計・設置・運用のどこにあるか、仕様と照らして追いやすい	原因が、機体、モデル、学習データ、設置条件、現場の運用のどこにあるのか、切り分けが要る	切り分けの手順、記録、役割分担、止める・戻す判断者を、契約の前に文章にする

表の右端は、フィジカルAIが従来より優れている、という意味ではありません。確かめ方と決め方の重心が変わる、という意味です。

1点目　例外への強さ：「できる」ではなく、範囲と外れたときで確かめる

現場では、対象物の個体差、置き方のずれ、品種の切替、作業者ごとの手順の違いなど、例外が日常的に起きます。従来の自動化では、その例外を事前に洗い出して条件に書き込むか、扱えないものは人が対応する設計にします。

フィジカルAIの提案では、「柔軟に対応できます」という説明が出ることがあります。この言葉だけでは、判断の材料になりません。確かめたいのは次の点です。

• 現場で起きる例外の一覧を、発注側から開発側へ渡したか（起きやすいもの、起きると困るもの）
• 試験で変動を与えた範囲はどこまでで、その範囲を誰が決めたか
• うまくいかなかった試行は記録され、報告に載っているか
• 範囲の外に出たとき、止まるのか、人に戻すのか、気づかずに続けてしまうのか
• 人が戻したあと、元の状態へ復帰させる手間と手順は決まっているか

試験の条件の決め方はフィジカルAIのPoC支援の記事で、シミュレーション結果を受け取ったときの読み方はシミュレーション結果を実機で確かめる記事で、それぞれ扱っています。

2点目　必要なデータ：動作を書く作業から、現場の記録を揃える作業へ

従来の自動化で教えるのは、基本的に動作そのものです。フィジカルAIでは、現場で何が起き、どう動かし、どうなったかの記録が、学習や調整の材料になりえます。うまくいった記録だけでなく、滑った・外れた・やり直したといった記録も含まれます。

発注側が決めておくことは、次のとおりです。

• 取る対象の作業と場面（通常の場面だけでなく、例外や失敗、復帰の場面も含めるか）
• 取る人と取る場所（現場の作業者の負担、生産への影響）
• 取ったデータの帰属と、再利用できる範囲（開発側が他の案件に使えるのか）
• 外に出さないもの（技術やノウハウが読み取れる情報、顧客や個人に関わる情報）

WITHPROJECTSは、フィジカルAI事業化・FDE支援のページで、フィジカルAIの学習には、現場の「状態→行動→結果」の連続データが必要になると説明しています。 現場データの取り方は現場データ収集の記事で扱っています。

3点目　保守のしかた：直す対象が、プログラムからモデルと条件にも広がる

導入後の現場では、対象物の変更、照明や設備の配置の変更、品種の追加、部品の交換などが起きます。従来の自動化では、教示位置やプログラムを修正し、影響の範囲を追って確認します。

フィジカルAIでは、これに加えて、モデルの更新や、環境・対象物の変化による挙動の変化が論点になります。変更のたびに、導入時と同じ見方で再確認できるかが、運用の分かれ目です。発注の前に決めておくことは次のとおりです。

• 変更があったときに再確認する項目と、確認の見方（導入時の確認と同じ項目を使うか）
• 再確認と、モデル・条件の更新を誰が担うか（社内、開発側、設備側）
• モデルや条件の版の記録と、元に戻せる状態の保ち方
• 契約が終わったあとにも、自社で使い続けられるもの（記録、手順書、データ）

4点目　責任の置き場：「誰の責任か」の前に、原因を切り分ける手順を持つ

フィジカルAIで不具合が起きたとき、原因は、機体、モデル、学習データ、設置条件、現場の運用のどこにもありえます。原因が分からないまま、関係者が「自分の範囲ではない」と考える状態が、最も困ります。

そのため、契約や仕様の段階で、次を文章にしておきます。

• 切り分けに使う記録（動作の記録、映像、条件、設定の版）を、誰がどこに残すか
• 企業側、開発側、設備側のそれぞれの役割と、連絡の順番
• 止める・戻す・再開するの判断を、誰がするか
• 不具合のあとに、見直す対象を決める場（試験条件、データ、設定）

法的な責任の帰属や、安全に関する適否は、この記事では判断できません。個別の判断は、関係法令や規格を確認したうえで、現場の安全管理者、専門家、所管に相談してください。安全面の決め方はAIを載せたロボットの安全の記事で扱っています。

判断条件：どちらを軸に検討するか

次は、あくまで傾向です。個別の作業で変わるため、最終的な判断は、対象の作業と現場の条件を見て行います。

従来の自動化で足りる可能性を、まず検討したい状態：

• 対象物の形と置き場所が揃っていて、手順を固定できる
• 起きる例外が少なく、事前に書き出せる
• 既存の設備や制御の上で、同種の動きがすでに実現している

フィジカルAIの検討に進む意味が出やすい状態：

• 対象物のばらつきや置き方の違いが大きく、手順を文章で書き切れない
• 人が目や手の感触で判断している工程があり、その判断を条件として書き出せない
• 例外への対応を従来の方式で書き足し続けていて、追いつかなくなっている

どちらの場合も、慎重に進めたい状態：

• 失敗が人の危険に直結する作業である
• 現場の例外を、発注側が一覧にできていない
• データを取れない、または外に出せない
• 更新後の再確認を担う人が、社内にも委託先にも決まっていない

発注前の進め方（手順）

ステップ1：対象の作業を決め、現場で起きる例外の一覧を作る。

ステップ2：従来の自動化で扱える例外と、扱いにくい例外を分ける。扱いにくい理由も書く。

ステップ3：上の4つの点について、「誰が、何を、どの記録で」確かめるかを文章にする。

ステップ4：既存設備との取り合いを含めて、従来の自動化、フィジカルAI、組み合わせの構成を並べて検討する。

ステップ5：提案や見積を、次の表の観点で読み、足りない説明は書面で追加してもらう。

ステップ6：試験（PoC）の範囲と、結果を見て判断する人を決めてから、着手する。

提案・見積で確認すること

確認する点	十分な答えの例	注意したい答え
例外の扱い	試験で変動を与えた範囲、うまくいかなかった試行、範囲外のときの動きが示される	「柔軟に対応できます」とだけ述べ、範囲が示されない
データ	取る対象・場面、取る人、帰属、再利用の範囲、外に出さない情報が書かれている	データの扱いは「導入後に決める」
保守	変更時の再確認の項目、担当、版の記録、契約後に残るものが示される	更新の扱いが、運用に入ってからの相談になっている
責任の分け方	切り分けに使う記録、役割分担、止める・戻す判断者が示される	「AIの判断なので原因は特定できない」
従来方式との比較	従来の自動化で足りる部分を認め、組み合わせも含めて比べている	フィジカルAIだけが前提の提案になっている

失敗しやすいパターン

• 「柔軟に対応できる」という説明を、例外への強さの確認だと受け取る
• 試験の条件を開発側だけで決め、現場の例外が入らない
• データの帰属や、外に出さない情報を決めないまま、データを取り始める
• 導入時の確認だけを行い、更新後の再確認を誰も担わない
• 不具合の原因を切り分ける記録が残らず、関係者の間で責任の置き場が曖昧になる
• 従来の自動化で足りる工程まで、フィジカルAIの対象にしてしまう

発注前に、自社で整理しておくこと

• 対象の作業と、そこで起きる例外の一覧（頻度と、起きたときの影響）
• 例外のうち、いまの設備や手順で扱えているもの、扱えていないもの
• 取れるデータと、外に出せないデータ
• 導入後に変更が起きやすいもの（品種、対象物、配置、照明）
• 不具合のときに止める・戻す判断をする人

WITHPROJECTSの考え方

WITHPROJECTSは、フィジカルAIを、AIを載せる案件ではなく、身体・AI・データ・現場・研究・事業をつないで設計する事業設計の案件と位置づけています。 同じページでは、実証で終わるPoCは設計が間違っているとの立場も示しています。

関連する解説として、試験の前に決める条件はフィジカルAIのPoC支援、対象にする作業の見きわめ方はフィジカルAIの工場自動化、支援の全体像はフィジカルAI事業化・FDE支援のページにあります。

次の一歩

フィジカルAIと従来の自動化のどちらが向くかを、例外・データ・保守・責任の整理から検討したい方は、個別相談の予約へお進みください。（個別相談会（30分）の予約ページへ移動します）