メーカー各社は今年、自社業務にAIを導入し、その成果を示すよう強いプレッシャーにさらされてきました。利益率が縮小しているため、投資は単一の変革予算としてではなく段階的に行われており、その各段階において、測定可能な成果が求められるようになっています。
成果にはばらつきが見られますが、それは技術そのものが期待外れだったからではありません。ソリューションの最初のバージョンを完成させるまでの時間は短縮されました。しかし、その検証や、チームが信頼するデータとの連携、さらには別の拠点での導入には、これまでと変わらない労力がかかります。つまり、問われるべき点は変わったのです。AIが何かを構築できるかどうかではなく、AIが構築したものを信頼し、監査し、複数の場所で運用できるようにするためには、どのような条件が満たされなければならないのか、ということです。
製造業務におけるAIの投資対効果（ROI）の実現
私たちが協力している業務部門のリーダーたちにとって、3つの課題が優先課題となっています。
ITが対応できる速度を上回るペースで、資本が新たな生産ラインに投入されています。そのため、そのラインを稼働させるためのシステムが整う前に、生産が開始されてしまうことがよくあります。
生産性は、すでに在籍しているチームから生み出されるものでなければなりません。人員増や、大規模なソフトウェア・ハードウェアの購入から生まれるものではありません。
ほとんどのメーカーは、何を変えるべきかすでに把握しています。しかし、測定可能なほど状況を改善することは別の問題であり、今年は、まさにその問題に対して資金が投入されることになります。
構築、運用、および拡張
運用責任者にとって、もはや問題は「AIが解決策を立案できるか」「データセットを読み取れるか」ということではありません。重要なのは、AIが生み出した成果物を信頼し、監査し、複数の拠点で運用できるようになるために、事前にどのような体制を整えておく必要があるかということです。
ソリューションを構築するということは、業務担当者が把握している知識を、実際に実行可能な形に変換することを意味します。具体的には、手順、ロジック、データ接続、そしてコンプライアンスを遵守するためのチェックなどです。この作業は、これまで常にプロセスを理解している人々に依存しており、彼らの1日の大半は、判断を下すことよりも、作業を組み立てることに費やされていました。AIは、その組み立て作業の大部分を代行し、判断を下す役割は従来通り残します。これにより、レビューを行う担当者を変えることなく、生産性を向上させることができました。
業務を遂行するということは、本来は異なる業務を行うために構築されたシステムに保存されているデータに基づいて行動することを意味します。スケジューリングシステムには計画された内容が、機械の制御装置には実際に稼働した内容が、紙の記録にはオペレーターが観察した内容が、そしてスプレッドシートにはそれに対して誰かが決定した内容がそれぞれ保存されています。これらのシステムは互いにデータを交換しないため、情報は作成された場所に留まったままとなり、誰かが何かを決定する前に、担当者が手作業で各記録を照合する必要があります。
その照合作業こそが、自動化では対応できない部分なのです。人間であれば、どちらの情報源を信頼すべきかを知っているため、不一致のある2つのシステムを照合することができます。しかし、エージェントにはそれができません。エージェントは、回答を拒否するか、あるいは間違っているにもかかわらず自信満々の回答を返してしまうかのどちらかになります。
スケーリングとは、ある拠点で実証済みの解決策をネットワークの他の拠点に展開することを指します。ある工場で有効性が確認された修正策は、他の工場には導入されないことが多く、その結果、同じ問題が5か所で5回も解決されてしまうことになります。また、各コピーがどこから来たのかという記録がないため、中央チームは、ある拠点で何かが稼働していることは確認できても、それが最新バージョンであるかどうかは確認できません。
なぜ関連する経験がAIの経験ではないのか
これら3つのうち、どれ一つとしてAI自体の問題ではありません。それぞれが、AIを取り巻く状況に関する問題です。つまり、誰が承認したのか、どのようなデータを読み込んだのか、そしてどのバージョンがどこで稼働しているのか、といった点です。
Tulip 医薬品、医療機器、防衛関連の製造など、ミスが重大な結果を招きかねない分野で10年以上にわたり実務に携わってきました。権限管理、承認プロセス、監査証跡は、管理対象となるエージェントが登場するはるか以前からプラットフォームに組み込まれていました。つまり、AIはチームの既存の監視体制と並行して導入されるのではなく、チームがすでに従っている監視体制の中に組み込まれる形となります。既存のシステム構成において、置き換えられるものは一切ありません。
構築：組み立てから評価まで
エンジニアや建設業者は、紙であれ、スプレッドシートであれ、そして最終的にはデジタルアプリケーションであれ、常に問題を最も効果的に解決できるツールを使ってきました。AIもまた、その役割を担う次のツールとなるのです。
ツールが何であれ、生き残ったプロセスは、自社の業務を最も深く理解していた人々によって設計されたものでした。ツールへのアクセスと業務知識との間のボトルネックを解消するため、私たちは「オーサリング・エージェント」を開発しました。このオーサリング・エージェントは、アプリケーションエディタ内で動作し、SOPや作業指示書など、業務部門がすでに管理している文書から実用的な解決策の草案を作成し、必要に応じてその草案を編集します。
変わるのは、専門家の1日の時間の使い道です。手順やロジック、データの関連付け、コンプライアンスチェックを手作業で組み立てるのではなく、プロセスを熟知している担当者が、ソリューションにどのような機能を持たせるべきかを決定します。草案がほぼ理想に近い状態になったら、彼らはリクエストを提出して処理能力が確保されるのを待つのではなく、自らフィールドを変更します。
ソリューションの開発が速くなればなるほど、その数は増え、あるソリューションに変更を加えただけで、両者が関連していることに誰も気づかないうちに、別のソリューションが機能しなくなる可能性があります。
プロジェクトでは、アプリを1つずつ個別に設計するのではなく、システム全体を設計します。単一のユースケースに対応するアプリ、データ構造、自動化機能、および接続は、それらを支える物理的な領域に紐付けられ、統合されます。これにより、ユースケース間の関係は推測されるのではなく、明確に示されます。変更は、それが属するシステム全体に対して評価することができます。また、一度有効性が確認されたソリューションは、次の現場で誰かが個別に再組み立てを行うようなパーツの集合ではなく、バージョン管理された単一のユニットとして展開されます。
1つのレコードで実行する
スケジューリングシステム、機械制御装置、紙の記録、およびスプレッドシートは、何らかの要因によってそれらが同一の基準に統一された場合にのみ、一つの記録となります。
Tulipの産業用コネクティビティ機能は、標準的な産業用プロトコルを介して、デバイスと業務システムをネイティブに連携させます。その後、それらの出力を共通の基準に統一するため、作業指示書、機械の状態、ロット、オペレーターの操作といった情報は、あらゆるアプリ、ダッシュボード、エージェントにおいて同一の定義で扱われます。これにより、注文記録、欠陥コード、作業ステーションの活動状況に基づいて、機械データを照会することが可能になります。これによって、チームは、事前のシステム統合を構築することなく、不良品と工程切り替え、あるいは欠陥とシフトや材料ロットとの相関関係を分析できるようになります。 高頻度の計測データは、現場を離れる前にエッジ側で集約されるため、分析に必要なデータのみが送信されます。
「Factory Playback」は、生産現場にすでに設置されているカメラを運用データソースとして扱います。映像は機械データや受注データと同じタイムラインに同期されるため、調査は記憶を頼りにするのではなく、記録に添付された動画から開始されます。また、ビジョン言語モデルが事前に設定されたルールとの照合ではなく、フレーム内の内容を解釈するため、アラートが設定されていなかった過去のイベントについても検索が可能です。 同じカメラを使用することで、新たなハードウェアを導入することなく、新たな疑問にも答えられます。例えば、作業台での個数カウント、ゾーン内での滞留時間、ステーションが稼働中かアイドル状態かといった情報です。
エージェントはその統合された記録に基づいて動作します。エージェントはそこから質問に答え、求められれば分析結果を提示し、指示を待つのではなく、スケジュールに従って動作します。組織は、エージェントが独自に実行できるアクション、承認が必要なアクション、および禁止されているアクションを定めます。プロセスを熟知している人々は、調整作業ではなく、意思決定に自らの経験を活かします。
制御を伴うスケーリング
ガバナンスには、可視性、管理、信頼という3つの役割があります。
OpsMotoは可視性を提供します。すべてのサイトやインスタンスにわたるデプロイ、アプリケーション、自動化、およびユーザーアクティビティを一元的に把握できるようにし、各ソリューションの変更履歴を記録します。中央のチームは、どのサイトでどのバージョンが実行されているか、またどこでバージョンが分岐したかを把握することができます。これ以外の方法でその全体像を把握しようとすると、各インスタンスに順番にログインする必要があります。
また、OpsMotoはコアプラットフォームのリリースサイクルとは独立して運用されます。つまり、OpsMotoを導入・更新しても、すでに検証済みのシステムが再検証の対象となることはありません。
Enterprise Libraryは管理機能を提供します。中央のチームが承認済みのソリューションを一度公開すれば、各拠点では、手動でインポートするためのファイルを受け取るのではなく、閲覧可能なカタログから最新バージョンをインストールします。一度検証された修正プログラムは、ネットワーク全体に反映されます。また、各拠点では、テンプレートとの関連性を失うことなく、インストールした内容を現地のプロセスに合わせて調整できるため、現地のニーズに合わせたカスタマイズによって、中央での可視性が損なわれることがなくなります。
信頼は単なる「製品」ではありません。それは、データの保管場所、その保護方法、そしてAIに許可される動作範囲など、その他のすべてが機能するための前提条件です。これらは、規制が整備され安全な環境において、運用がすでに依存している管理措置であり、AIのために別途策定された一連の規則ではありません。
ここでは、次のようなものをご覧いただけます。Operations Calling
現在、AIの導入で成果を上げているメーカー各社と2日間を共に過ごし、彼らがその成果を得るまでにどれほどのコストがかかったかを直接お聞きいただけます。すでにそのアイデアを試した経験のある方に提案を提示し、どこで問題が生じたのかを直接聞くことができます。
3つのエリアすべてで、デモフロアでは実際に体験していただけます。SOPに基づいてソリューションを構築し、接続された機械や映像データを活用して作業を行います。また、ソリューションを拠点間で移行させ、中央チームがどのような画面を確認しているかを確認することもできます。
各セッションは、いずれも同様の流れで進められます。具体的には、ロールアウトの真っ最中にあるチーム、ネットワークを統括する中央チーム、そして実際の生産現場でAIを稼働させるためのエンジニアリング作業について取り上げます。
Operations Calling 10月6日～7日はサマービルで、11月3日～4日はリヨンで開催されます。当イベントでは、その性能をご紹介いたします。実際にどのような成果が得られたかについては、会場にお集まりのメーカー各社がご説明いたします。ぜひ本日、チケットをお求めください！
実際に体験してみてくださいOperations Calling
Operations Calling では、すでにAIから成果を上げているメーカー各社にぜひご参加ください。SOPに基づいてソリューションを構築し、接続された機械データや映像データを活用し、拠点間でソリューションを移行させることができます。