- 現場のスタッフは、すでにスマートフォンを手にしています。それなのに多くのシステムは、あとで机に戻ってデータを入力させます。
- よいアシスタントは片手で使え、写真を撮れば内容を理解し、話しかければ記録してくれて、電波がなくても使えます。
- 効果として測れるのは、仕事が現場で完了すること、戻ってから書類を作り直さなくて済むこと、データが以前より正確になることです。
従来のWebサイトやアプリの限界
現場の技術者は、片手しか空いておらず、手袋をはめ、炎天下に立ち、電波も途切れがちです。ところが会社が使わせているのは、机に座って使う人向けに作られた、10項目もある長いフォームです。結局、技術者は紙にメモを取り、夕方に戻ってから入力することになります。
従来の現場アプリは、融通の利かないチェックリストです。スタッフはどのメニューを開けばよいかを覚えていなければならず、作業しにくい状況で長い文章を打つことになります。結果として、データの入力が遅れたり、抜けが出たりします。
現場向けのソフトウェアは、事務所のフォームをスマートフォンの画面に縮めたものから始まることがよくあります。実際のユーザーは炎天下に立ち、手袋をはめ、騒がしい場所や電波の届かない場所にいます。仕方なく紙にメモを取り、写真を撮っておき、夕方に戻ってから入力します。データは遅れて届き、記憶からこぼれ落ちる情報も出て、システムは助けにならない負担と見られるようになります。
AIモバイル現場アシスタント（AI Mobile Field Assistant）は、実際の作業状況から設計する必要があります。正しいマニュアルを開く、表示板や書類を読み取る、音声の指示を受ける、次の手順を案内する、作業中に証拠を記録する、といった手伝いができます。ただし、技術者が安全から目を離したり、社内の専門家がまだ確認していない案内を信じ込んだりするようにしてはいけません。
| 従来の形 | 新しい世代のAIプロダクト |
|---|---|
| マニュアルを表示し、フォームを受け付け、写真はあとでアップロードする | 画像と音声を理解し、いま進めている作業から状況を読み取り、対話しながら点検手順を案内し、スタッフの確認を経て構造化された記録を作る |
現場アプリのシステム連携は、オンラインの時間もオフラインの時間も想定しておく必要があります。アプリは作業パック（Work Pack）と証拠を端末に安全に保存し、AIの処理の一部はユーザーの手元で行い、準備が整ったらAPIで同期します。データが食い違ったときは、その内容を示して人に判断してもらいます。
ビジネスに使える新しい機能
実際に使える現場アシスタントは、仕事の現実から出発します。写真を撮れば何が写っているかをシステムが理解し、短く話せば正しい欄に記録され、電波がなくても作業を続けられて、電波が戻ったところでシステムに送られます。
プロジェクトの形
アプリは、マニュアルと賢い作業記録帳を1台にまとめたものです。ユーザーが設備（Asset）を選ぶかコードをスキャンすると、システムが履歴、チェックリスト、関連書類を前もって読み込みます。作業中は大きなボタン、音声、写真、短い手順で操作でき、通信が使えないときでも、誰がいつ何をしたかが記録されます。
具体的な機能
機能としては、オフライン用の作業パック、音声メモ、OCR（文字の読み取り）、画像への書き込み、誘導型の点検、部品の検索、専門家による遠隔支援、安全確認、報告書の自動作成、同期状況の表示などが考えられます。AIに確信がないときは、写真を追加で求めるか、専門家を呼ぶべきです。手元のデータで裏づけられる以上に自信のある答えを出してはいけません。
現場に合った技術
音声認識、OCR、キャッシュしたデータの検索といった処理の一部はオンデバイス（端末内）で行い、応答を速くし、プライバシーを守ります。最新のデータが必要な処理は、通信できるときにクラウドへ送ります。アプリには、データの競合の解決、暗号化した保存、バックグラウンドでの同期、端末の権限管理が必要で、会社の端末を管理するMDMとつなぐこともあります。
現場の人にとっての効果
技術者は報告書づくりの時間が減り、いちいち電話で聞かなくても必要な知識にたどり着け、専門家には最初から証拠をそろえて送れます。上司は止まっている仕事や異常に早く気づけます。会社にとっては、熟練者の説明や写真から暗黙知を集め、マニュアルの改善に使えることも利点です。ただし、AIが現場の技能の代わりになるとまでは言いません。
- 表示板、バーコード、書類、現場の状態を読み取るカメラアシスタント
- 手がふさがっていても使え、リアルタイムで質問を重ねられる音声中心の操作
- すべてのデータをサーバーに送らずに、一部の作業を手伝うオンデバイスAI
- 作業内容を保存し、電波が戻ったら同期するオフラインファースト
架空のケース
具体的な利用場面
建物の点検担当者が設備を撮影すると、アプリがコードを読み取り、履歴を呼び出し、状態について音声で質問して、点検記録を下書きします。リスクのある箇所はエンジニアに回し、安全かどうかの判断をAIに任せることはしません。
架空のケースで、もう少し詳しく見てみます。電波の弱い建物で、技術者がエアコンの点検に入ります。設備をスキャンすると、アプリはダウンロードしておいた履歴とチェックリストを開きます。技術者は読み取った数値を音声で記録し、異常のある箇所を撮影します。ある数値が顧客企業の技術部門が定めた範囲を外れていることをシステムが警告し、専門家に確認を依頼する手順を追加します。
オンラインに戻ると、アプリは証拠を同期し、作業指示書（Work Order）を更新して、報告書の下書きを作ります。技術者はそれを確認・修正してから送ります。データの一部が事務所側の修正とぶつかった場合、システムは黙って上書きせず、違いを示してどちらを残すか選ばせます。こうすれば二度手間が減り、しかも現場の担当者の判断する権限は削られません。
3つの文脈の確認（Three-context Check）
案内を出す前に、人（Person）、場所（Place）、作業（Task）、つまり誰がどこで何の作業をしているのかをシステムに確認させます。
このうち1つでも取り違えると、正しいマニュアルが間違った案内に変わりかねません。
範囲、リスク、効果の測り方
開発チーム向け · 技術指標
実際に使う端末、照明、騒音、手袋、言語、ネットワークの条件でテストし、どのデータを端末にどれだけの期間保存してよいかも決めます。指標にはFirst-time Completion、Report Delay、Missing Evidence、Expert Call、Safety Stopを入れます。速さを、安全性や証拠の質より高く評価してはいけません。
同意の取り方、データの保存期間、バッテリー消費と応答の遅れ、端末の機種ごとの対応状況、モデルが使えないときの手動モードを設計しておく必要があります。
開発チーム向け · 技術指標
追跡すべき指標：Time-to-Record、Data Completeness、Offline Success、Expert Escalation、Unsafe Advice
- Discover：実際の業務を追い、通常のケースと例外の実例を集めます。
- Assist：人が主導権を持ったまま、AIに下書きや提案をさせます。
- Act：テストセットに合格してから、ツールを1つずつ使えるようにします。
- Scale：監視、フォールバック、コスト管理、責任者がそろってから範囲を広げます。
アプリのせいでユーザーが作業から目を離してしまう、同期の途中で証拠が消える、リスクのある箇所で案内があいまいになる、といったことが起きたら、試験導入を止めます。報告書の速さより、安全と記録の完全さが先です。
BUSINESS & PRODUCT READINESS
現場のAIは、Webサイトを縮めず、現場の実情から設計する
機能を考える前に、作業環境を調べます。ユーザーの手は空いているか、明るさや騒音はどうか、手袋や保護具（PPE）を着けているか、電波はどのくらいの時間途切れるか、何秒以内に応答が必要か。音声、カメラ、大きなボタン、オンデバイス処理、オフラインのキューのどれを使うべきかを決めるのは、画面の見た目よりこうした条件です。
開発チーム向け · 技術的な詳細
Device Matrix、Permission、Data Retention、Sync Conflict、Manual Checklistを用意します。AIには記録の作成や手順の検索を手伝わせ、安全に関わる案内にはルールと専門家を使います。Battery/Latency Budgetを決め、いちばん厳しいシフトと場所でテストします。
端末と作業環境の対応表（Device and Environment Matrix）を作り、手が空いているか、明るさは足りるか、どれくらいの時間オンラインでいられるか、どんな本人確認が必要かといった状況ごとに分けます。そのうえで、場面に合った操作方法を選びます。音声が向く場面もあれば、ボタン1つで済ませるべき場面、画面を使わせるべきでない場面もあります。
マニュアルとしきい値には、導入企業の技術、安全、専門家のいずれかのチームから責任者を置きます。システムにはバージョンと更新日を表示し、手動モードをいつでも使えるようにしておきます。試験導入は、マニュアルがはっきりしていてリスクを管理でき、実際の現場からフィードバックをくれる少人数のユーザーがいる仕事から始めます。
手がふさがるのはどの作業か
端末の外に出してはいけないデータはどれか
どれくらいの時間オフラインで使えるか
専門家の確認が必要な案内はどれか
現場の状況と実際の端末の制約に合わせた現場アシスタントを作る
DNA Makerは現場に足を運ぶか、スタッフや専門家に現場インタビュー（Context Interview）を行い、作業中の姿勢、道具、電波の状況、禁止事項を把握します。そのうえで、人（Person）、場所（Place）、作業（Task）の3つの文脈をまとめたThree-context Mapを作ります。業務固有の知識を確認するのはお客様で、私たちはそれをスマートフォンに合った操作とデータの流れに組み立てます。
クリックで操作できる試作版や、カメラ・音声を使う試作版を作り、バックエンドの完成を待たずに、最初から実際の端末でテストします。こうすると、ボタン、音声、照明、通信、確認手順の問題が、アーキテクチャが固まる前に見つかります。
DNA Makerは機能を選ぶ前に、場所と端末ごとにユーザーの利用の流れ（User Journey）を細かく描きます。明るさ、騒音、ボタンの大きさ、片手での操作、オフライン時の流れを試すプロトタイプを作り、そのうえで、速さ、プライバシー、データの新しさのバランスが取れるよう、オンデバイスとクラウドの役割分担を設計します。
仕組みとしては、ネイティブのモバイルアプリ、オフライン同期、OCRと音声入力、AI現場アシスタント、作業指示システムとの連携、専門家用の画面が考えられ、ユーザーの邪魔にならない形で利用状況の計測（テレメトリー）も組み込みます。技術者が毎回マニュアルを開き、写真を撮り、報告書を書き直している仕事があれば、その流れを試験導入の対象にして、実際に使えることを確かめてから機能を増やせます。
DNA Makerは、ネイティブまたはクロスプラットフォームのモバイルアプリ、オンデバイスとクラウドのAI、オフラインでの保存と同期、バーコードとOCR、音声、バックエンド、システム連携を開発でき、クラッシュ、遅延、モデルの監視も組み込めます。
1つの作業の中で、スタッフがスマートフォンを持ったまま、マニュアル、カメラ、紙を行き来しているなら、その作業についてご相談ください。現場の負担を増やさずに、時間とデータの完全さを測れる試験導入を設計します。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
ここに挙げる用語は、オンデバイス処理、オフライン、複数の形式の入力から応答時間まで、現場向けソフトウェアならではの違いを説明しています。実際の環境が会議室とは違うとき、システムがどう動き続け、どうデータを復旧するのかを尋ねるときに使ってください。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| On-device AI | AIの処理を端末の中で行うこと。速さやプライバシーが求められる作業、オフラインでの作業に向くが、モデルの大きさ、バッテリー、機種ごとの性能を考慮する必要がある | 音声をクラウドに送らずに、メモを要約する | どの機種に対応していますか？ |
| Offline-first | インターネットがなくても動くように設計すること。最初から、通信なしでデータを作成・修正できるようにアプリを設計し、同期の状況と、双方のデータが食い違ったときの扱い方を示す | 点検結果を記録しておき、あとで同期する | 同期のときにデータが食い違ったら、どう解決しますか？ |
| Multimodal Prompt | 複数の形式の情報をまとめてモデルに渡し、判断させること。画像、音声、テキストのそれぞれが何のためのものか、証拠が読み取りにくいときにどうするかを指示に書き、モデルに推測させないようにする | 設備の写真に、音声での質問を添える | どの形式が必要で、同意は得られていますか？ |
| App Intent | システムが自然な言葉で呼び出せる、アプリの機能。外部のアプリやシステムが決められた処理を呼び出す入口になるので、入力、権限、期待する結果をはっきり定めておく必要がある | 次の点検作業を開くよう指示する | どの操作を呼び出せるようにすべきですか？ |
| Latency | 指示してから応答が返るまでの待ち時間。データの検索、APIの呼び出し、同期のどれもがユーザーの待ち時間を増やすので、モデルの応答時間に限らず、利用の流れ全体で測る必要がある | 音声での案内が、現場で使えるほど速く返ってくる | 何秒を超えると使いものにならなくなりますか？ |
関連資料（原典）：https://developer.apple.com/documentation/foundationmodels/