建設現場で生成AIを使うとき、多くの人が最初に思い浮かべるのは、大規模なクラウドAIです。現場日報を要約する、施工計画を作る、図面や仕様書を読み解く、メールを作成する、発注者向け資料をまとめる。こうした用途では、高性能な大規模言語モデル、つまりLLMが大きな力を発揮します。
しかし、現場でAIを本当に使おうとすると、クラウドAIだけでは足りない場面が出てきます。地下や山間部で通信が弱い。トンネルや高層階で電波が途切れる。現場カメラやIoTセンサーのデータを毎回クラウドへ送ると通信量が大きい。安全手順や機械トラブル対応は、数秒以内に返答してほしい。作業員の音声入力や現場ルール検索は、オフラインでも使いたい。こうした場面では、現場端末やエッジ機器で動く小型言語モデル、Small Language Modelが重要になります。
AI・IoT・ロボティクス統合に関する研究では、エッジ側のSmall Language Modelsとクラウド側のLarge Language Modelsを組み合わせ、現場での分散認知、自律判断、リアルタイム適応を支える方向性が示されています。つまり、これからの建設AIは「全部クラウドで考える」のではなく、「現場で即時に判断する小型AI」と「クラウドで深く考える大型AI」を使い分ける形へ進みます。
Microsoftも、PhiをSmall Language Modelsのファミリーとして位置づけ、クラウド接続なしでデバイス上にAIを実装するためのモデル群として説明しています。建設現場でも、このような小型モデルは、スマートフォン、タブレット、現場PC、エッジサーバー、ロボット、AIカメラに組み込まれる可能性があります。
Small Language Modelとは何か
Small Language Model、略してSLMは、大規模言語モデルよりも小さく、軽量で、特定用途に使いやすい言語AIです。一般的なLLMは非常に高性能ですが、計算資源、通信、コスト、遅延、データ管理の面で負担が大きくなります。一方、SLMは規模を抑えることで、スマートフォン、ノートPC、産業用エッジ端末、ロボット、IoTゲートウェイのような現場側の機器で動かしやすくなります。
ACL 2025の研究「Demystifying Small Language Models for Edge Deployment」では、SLMはスマートフォンやWeb of Thingsのようなリソース制約のあるデバイスへ展開するための有望な選択肢として整理されています。同研究では、公開されている60以上のSLMを調査し、エッジ展開での実用可能性と限界を分析しています。
| 項目 | 大規模クラウドLLM | Small Language Model at the Edge |
|---|---|---|
| 主な配置場所 | クラウド、データセンター | 現場端末、エッジサーバー、ロボット、IoTゲートウェイ |
| 強み | 高度な推論、長文処理、汎用性 | 低遅延、オフライン対応、省通信、現場密着 |
| 弱み | 通信依存、コスト、遅延、データ送信 | 複雑推論や広範な知識ではLLMに劣る |
| 向いている用途 | 設計レビュー、契約文書分析、複雑な計画立案 | 日報入力、現場ルール検索、安全手順確認 |
| 建設現場での役割 | 深い分析・資料作成・全社知識活用 | 現場即時支援・オフライン支援・一次対応 |
重要なのは、SLMがLLMを置き換えるわけではないことです。現場で素早く答えるSLMと、クラウドで複雑な分析を行うLLMを組み合わせることで、建設AIは実務で使いやすくなります。
なぜ建設現場では小型オンサイトAIが必要なのか
建設現場は、オフィスと違って通信環境が安定しているとは限りません。山間部、トンネル、地下、港湾、ダム、解体現場、高層階、仮設事務所では、通信が弱くなることがあります。さらに、粉じん、騒音、振動、雨、暑熱、夜間作業、移動作業など、AIを使う環境としては厳しい条件が多くあります。
クラウドAIだけに依存すると、通信が切れた瞬間にAI支援が止まります。安全手順を確認したいとき、機械トラブルの一次対応を知りたいとき、作業員が音声で日報を入力したいとき、毎回クラウドへ問い合わせる運用では遅すぎる場合があります。
| 現場の課題 | クラウドAIだけの場合 | SLM at the Edgeでの改善 |
| 通信が不安定 | AIが使えない・応答が遅れる | 端末上で最低限の回答を返せる |
| 安全確認が急ぎ | クラウド往復で遅延する | 現場端末で即時確認できる |
| データ量が多い | 音声・映像・センサー送信が重い | 現場側で前処理・要約して送信 |
| 機密情報がある | すべてクラウド送信に抵抗がある | ローカル処理で送信量を減らせる |
| 作業員が移動する | 常時接続が難しい | スマホ・タブレットで支援できる |
| 問い合わせが多い | 事務所や管理者に確認が集中 | SLMが一次回答し、必要時だけエスカレーション |
建設現場でSLMが重要になる理由は、AIを“現場に近づける”ためです。大型クラウドAIは強力ですが、現場作業員の手元で、すぐに、低コストで、通信に依存しすぎずに動くAIがなければ、現場DXは定着しにくくなります。
日報の音声入力は最初の有力用途になる
建設現場でSLMが最初に使われやすい用途の一つが、日報の音声入力です。作業員や現場監督が、作業終了後にスマートフォンへ話しかけるだけで、作業内容、人数、使用機械、資材、出来高、問題点、明日の予定が整理される。これは、SLMの実務価値が出やすい領域です。
従来の日報作成は、現場作業後に事務所へ戻って入力する、紙に書く、写真を整理する、協力会社から情報を集めるなど、手間がかかります。音声入力を使えば、現場で歩きながら記録できます。SLMが端末上で音声テキストを整形し、工種や工区、日付、人員、機械名を抽出し、日報の下書きを作成できます。
Microsoft Edgeの開発者向け発表では、オンデバイスの小型言語モデルやタスク特化モデル、音声認識APIの拡張が紹介されています。こうしたオンデバイスAIの流れは、建設現場の音声入力や現場端末AIにもつながります。
| 日報業務 | SLMでできること |
| 作業内容の記録 | 音声を作業日報形式に整える |
| 工種分類 | 土工、鉄筋、型枠、設備、内装などへ分類 |
| 工区整理 | 3階東工区、B1機械室などの場所情報を抽出 |
| 人員・機械記録 | 作業員数、重機名、稼働時間を抽出 |
| 異常・問題点 | 遅延、手戻り、安全指摘、資材不足を抽出 |
| 写真との紐づけ | その場で撮った写真に説明文を付ける |
| クラウド連携 | 通信回復後に施工管理システムへ同期 |
この用途では、SLMが現場で一次整理し、クラウドLLMが後から全体要約や週報作成を行う、という分担が現実的です。
現場ルール検索は“聞けば答える安全手帳”になる
建設現場では、安全ルール、作業手順書、KY活動、施工要領書、品質基準、メーカー説明書、社内マニュアル、発注者仕様など、多くの文書が存在します。しかし、現場で必要なときに、必要なページをすぐ探すのは簡単ではありません。
SLMを現場端末に入れておけば、作業員や職長が自然言語で質問できます。
- 「高所作業車を使う前の点検項目は?」
- 「この現場の火気作業ルールを教えて」
- 「熱中症警戒時の休憩ルールは?」
- 「この機械のエラーコードの一次対応は?」
- 「夜間作業で近隣対応が必要な作業は?」
- 「コンクリート打設前の確認項目を出して」
このような質問に対して、SLMが現場端末内に保存されたルールブックや作業手順書を検索し、短く答えます。複雑な判断が必要な場合は、クラウドLLMや管理者へエスカレーションします。
| 現場文書 | SLMでの使い方 |
| 安全ルール | 作業前確認、禁止事項、緊急時対応を検索 |
| 施工要領書 | 工種別の手順、品質基準を確認 |
| メーカー説明書 | 機械・工具のエラー対応、点検方法を確認 |
| 発注者仕様 | 検査基準、提出資料、施工条件を確認 |
| 社内マニュアル | 報告フロー、承認フロー、写真撮影ルールを確認 |
| 現場掲示情報 | 当日の危険作業、立入禁止、搬入予定を確認 |
この用途で重要なのは、AIに自由回答させすぎないことです。回答には、参照元の文書名、章、ページ、更新日を表示する必要があります。KPIとして「AI回答の根拠提示率」を管理する理由はここにあります。
安全手順確認は“クラウド待ち”にできない
安全に関わる確認は、応答速度が重要です。作業員が「この作業は今すぐ始めてよいか」「どの保護具が必要か」「機械を止めるべきか」を確認したいとき、クラウドへの通信待ちで数十秒かかるようでは使われません。
SLM at the Edgeでは、現場端末やエッジ機器に安全手順を持たせ、低遅延で確認できます。たとえば、AIカメラが危険エリア侵入を検知し、現場端末が「作業停止」「職長確認」「立入禁止解除後に再開」といった手順を即時表示する。搬送ロボットが障害物で停止した場合、端末が復旧手順を表示する。こうした使い方が考えられます。
| 安全確認の場面 | SLMの役割 |
| 危険作業前 | 必要な資格、保護具、立入制限を確認 |
| 緊急停止後 | 復旧前の確認項目を提示 |
| 火気作業 | 消火器、監視員、養生、許可条件を確認 |
| 高所作業 | 墜落防止、作業床、点検項目を確認 |
| 重機接近 | 誘導者、合図、立入禁止範囲を確認 |
| 夜間作業 | 照明、警備、近隣対応、連絡先を確認 |
安全用途では、SLMの回答は「参考情報」ではなく、現場の作業判断に影響します。そのため、現場ごとの最新ルール、責任者承認、回答ログ、エスカレーション設計が必要です。
機械トラブル対応では“一次切り分け”ができる
建設現場では、重機、発電機、測量機器、GNSS、LiDAR、ドローン、ロボット、カメラ、IoTセンサーなど、多くの機器が使われます。現場でトラブルが起きたとき、メーカーサポートや社内担当者に連絡する前に、まず原因を切り分けたい場面が多くあります。
SLMを現場端末に入れておけば、機器のマニュアル、エラーコード一覧、点検手順、過去のトラブル履歴をもとに、一次対応を案内できます。
| トラブル | SLMが支援できること |
| GNSSがFIXしない | アンテナ、衛星数、基地局、通信、遮蔽物の確認 |
| LiDARが起動しない | バッテリー、接続、ファームウェア、保存容量の確認 |
| ドローンが飛行できない | バッテリー、GPS、風速、飛行禁止区域の確認 |
| AIカメラが映らない | 電源、ネットワーク、カメラID、クラウド接続の確認 |
| 搬送ロボットが停止 | 障害物、地図、バッテリー、通信、非常停止の確認 |
| 重機テレマティクス異常 | センサー、通信、稼働ログ、エラーコードの確認 |
ここでのSLMは、最終的な修理判断をするのではなく、現場で確認すべき項目を整理する役割です。現場で解決できる軽微な問題はその場で解決し、重大な問題はメーカーや専門担当へエスカレーションします。
SLMとLLMは“現場とクラウドの分業”で使う
SLM at the Edgeの重要な考え方は、SLMとLLMの分業です。SLMは低遅延、オフライン、現場密着、定型タスクに強い。一方、LLMは複雑な推論、長文資料、複数文書の横断分析、戦略立案に強い。どちらか一方ではなく、役割を分けて使うべきです。
クラウドLLMとエッジSLMの協調に関するサーベイでは、クラウドLLMとエッジSLMが推論や学習で協力するパラダイムが整理され、タスク割当、タスク分割、ルーティング、リソースに応じたオフロードなどの戦略が示されています。
| 処理内容 | SLM at the Edge | Cloud LLM |
| 日報音声入力 | 現場で文字起こし・整形 | 週報・月報・全体分析 |
| 安全手順確認 | 現場ルールを即時検索 | 複雑なリスク評価・教育資料作成 |
| 機械トラブル | 一次切り分け・手順確認 | 過去履歴分析・メーカー資料横断 |
| 現場問い合わせ | 定型FAQ・ルール検索 | 契約・仕様・設計変更の複雑回答 |
| ロボット停止対応 | 復旧手順表示 | 停止履歴分析・改善提案 |
| 写真メモ | 現場で説明文生成 | 工事写真台帳・報告書作成 |
| オフライン時 | 最低限の支援を継続 | 通信回復後に同期・再分析 |
この分業により、現場ではAIがすぐ使え、クラウドではより高度な分析ができます。建設AIを現場に定着させるには、この二層構成が重要になります。
オフライン時のAI支援が現場価値になる
建設現場では、通信が必ずしも安定していません。地下、トンネル、山間部、港湾、災害復旧現場では、通信が途切れることがあります。クラウドAIだけに依存していると、通信断の瞬間にAI支援が止まります。
SLM at the Edgeなら、最低限の機能をオフラインで動かせます。現場ルール検索、機械マニュアル検索、日報メモ、写真説明文生成、安全手順確認、点検チェックリスト表示などは、ローカルに保存した文書とSLMで対応できます。
| オフライン時に使える機能 | 現場での価値 |
| 安全手順検索 | 通信断でも作業前確認ができる |
| 機械マニュアル検索 | トラブル時の一次対応ができる |
| 日報メモ作成 | 作業中に記録し、後で同期できる |
| 写真説明文生成 | 工事写真の整理を現場で進められる |
| 点検チェックリスト | トンネル・地下・山間部でも確認できる |
| 現場FAQ | 職長や管理者への問い合わせを減らせる |
オフライン対応率は、建設現場での重要KPIになります。AIが通信のある場所でしか使えないなら、現場の作業導線に合いません。
クラウド通信量を減らす
現場AIでは、通信量も大きな課題です。映像、音声、写真、点群、センサーデータをすべてクラウドへ送ると、通信コスト、処理コスト、遅延、セキュリティリスクが増えます。
SLM at the Edgeを使うと、現場側でデータを要約・分類・フィルタリングできます。たとえば、作業員の音声をその場で日報形式に整形し、クラウドへは完成したテキストだけを送る。現場FAQは端末内で回答し、クラウドにはログだけ送る。ロボットの停止ログも、端末側で原因候補を整理して送る。このように、送るべきデータ量を減らせます。
| データ | クラウド送信中心 | SLM at the Edge活用 |
| 音声 | 音声データを送信 | 端末で文字起こし・要約して送信 |
| 写真 | 全写真を送信 | 現場で分類・説明文付与後に送信 |
| FAQ | 毎回クラウド問い合わせ | 定型質問は端末内で回答 |
| 機械ログ | 生ログを大量送信 | 異常候補だけ抽出して送信 |
| 安全確認 | クラウド応答待ち | 現場ルールをローカル検索 |
| ロボットログ | すべてクラウド解析 | 現場側で一次分類し、重要ログを送信 |
クラウド通信量を削減できれば、通信が弱い現場でもAIを使いやすくなり、コスト管理もしやすくなります。
KPIは“AIを入れたか”ではなく“現場で使えたか”
SLM at the Edgeの導入効果は、モデルのパラメータ数やベンチマークスコアだけでは評価できません。建設現場では、実際に使えるかどうかをKPIで見る必要があります。
| KPI | 意味 | 改善アクション |
| 応答遅延 | 質問から回答までの時間 | 端末処理、モデル軽量化、キャッシュを活用 |
| オフライン対応率 | 通信なしで使える機能の割合 | 現場文書・マニュアルを端末内に保存 |
| クラウド通信量 | クラウドへ送るデータ量 | 現場側で要約・分類・フィルタリング |
| 現場問い合わせ削減 | 職長・管理者への定型質問が減った割合 | FAQ、手順書、安全ルールをSLM化 |
| AI回答の根拠提示率 | 回答に文書名・ページ・更新日を添えられた割合 | RAG、文書管理、参照元表示を整備 |
| 日報作成時間 | 日報入力・整理にかかる時間 | 音声入力、工種分類、写真紐づけを活用 |
| エスカレーション精度 | SLMがクラウドLLMや管理者へ回すべき質問を判定できた割合 | 質問分類と権限ルールを整備 |
特に重要なのは、AI回答の根拠提示率です。建設現場では、AIがそれらしい回答をするだけでは不十分です。「どの手順書のどの箇所に基づく回答か」を示せなければ、安全・品質・契約に関わる判断には使いにくくなります。
導入時に失敗しやすいポイント
SLM at the Edgeは有望ですが、導入すればすぐに現場AIが定着するわけではありません。失敗しやすいのは、小型モデルを端末に入れることだけを目的化し、現場業務やデータ整備を後回しにするケースです。
よくある失敗は次の通りです。
- 現場文書が古く、AIが古いルールを回答してしまう
- 回答の根拠が表示されず、現場が信用できない
- 端末内データとクラウド側データが同期されていない
- オフライン時に使える機能と使えない機能が明確でない
- 複雑な質問までSLMだけで回答しようとして誤回答が増える
- 安全・品質・契約に関わる回答の承認ルールがない
- 端末紛失時の情報漏えい対策が不十分
- 音声入力が騒音環境で使いにくい
- 現場作業員が使いやすいUIになっていない
特に重要なのは、SLMに任せる範囲を決めることです。定型的なルール検索、手順確認、日報整理、一次切り分けはSLMに向いています。一方、設計変更、契約判断、安全上の最終判断、重大トラブル対応は、人間やクラウドLLMへエスカレーションする設計が必要です。
現場実装のおすすめステップ
SLM at the Edgeを建設現場で導入する場合、最初から高度なAIエージェントを作る必要はありません。現場で頻度が高く、定型的で、オフライン価値がある用途から始めるのが現実的です。
| フェーズ | 実施内容 | 目的 |
| 初期導入 | 安全手順書、現場ルール、機械マニュアルを端末に入れる | 現場検索AIを作る |
| 音声入力 | 日報・写真メモ・点検記録を音声で入力 | 入力負担を減らす |
| 根拠表示 | 回答に文書名、ページ、更新日を表示 | 現場の信頼性を高める |
| オフライン設計 | 通信なしで使える機能を明確化 | 地下・山間部・トンネルで使えるようにする |
| クラウド連携 | 通信回復後にLLMで要約・分析 | 現場メモを正式記録へ変換 |
| エスカレーション | 複雑質問を管理者・クラウドLLMへ回す | 誤回答リスクを減らす |
| 全社展開 | 現場テンプレート、端末管理、更新ルールを標準化 | 複数現場で再利用する |
最初におすすめなのは、日報音声入力と安全手順検索です。この二つは現場利用頻度が高く、SLMの価値を体感しやすい用途です。その後、機械トラブル対応、点検記録、ロボット停止時の復旧手順へ広げると、現場AIとして定着しやすくなります。
セキュリティとデータ更新を忘れてはいけない
オンサイトAIは、クラウド送信を減らせる一方で、端末側に文書やデータを持つことになります。そのため、セキュリティとデータ更新が重要です。
| 管理項目 | 実務上のポイント |
| 端末認証 | 現場端末の利用者、権限、ログイン方法を管理 |
| データ暗号化 | 端末内の手順書、図面、マニュアルを保護 |
| 紛失対策 | リモートワイプ、利用停止、アクセス制御を設定 |
| 文書更新 | 最新ルールを端末へ同期し、古い文書を無効化 |
| 回答ログ | 誰が何を質問し、AIが何を回答したかを記録 |
| 権限管理 | 協力会社、元請、発注者で見られる情報を分ける |
| モデル更新 | 現場ごとの改善や不具合修正を反映 |
SLM at the Edgeは、オフラインで使えることが強みですが、古い情報をオフラインで回答し続けるリスクもあります。したがって、端末内データの更新日、同期状態、参照元表示を必ず設計する必要があります。
建設会社・AIベンダー・端末メーカーにとってのチャンス
SLM at the Edgeは、建設会社、AIベンダー、施工管理ソフト会社、端末メーカー、ロボット事業者、測量機器メーカーにとって新しい提案領域になります。
建設会社にとっては、現場問い合わせを減らし、日報作成を短縮し、通信が弱い現場でもAI支援を提供できます。AIベンダーにとっては、クラウドAIだけでなく、現場端末向けの軽量AI、現場文書検索、エスカレーション設計が提案できます。端末メーカーやロボット事業者にとっては、デバイスそのものに言語AIを組み込むことで、現場での使いやすさを高められます。
提供できるサービスとしては、次のようなものがあります。
- 建設現場向けSLMアシスタント
- 日報音声入力AI
- 安全手順・現場ルール検索AI
- 機械トラブル一次対応AI
- オフライン対応の現場FAQ端末
- SLMとクラウドLLMのハイブリッド設計
- 現場端末向けRAG構築
- AI回答の根拠提示・ログ管理
- ロボット停止時の復旧手順AI
- 協力会社向け多言語現場支援AI
特に、現場端末やロボットにSLMを組み込むと、「ただデータを取る機械」から「現場で会話できる機械」へ変わります。ロボットが停止した理由を説明する、測量機が設定ミスを教える、カメラがアラートの意味を説明する。このような現場AIのユーザー体験が重要になります。
まとめ:建設AIは“クラウドだけ”から“現場で動くAI”へ
建設現場でAIを使うには、大型クラウドAIだけでは不十分です。通信が不安定な場所、すぐに安全手順を確認したい場面、日報をその場で入力したい場面、機械トラブルを一次切り分けしたい場面では、現場端末やエッジ機器で動くSmall Language Modelが重要になります。
SLM at the Edgeは、低遅延、オフライン対応、クラウド通信量削減、現場問い合わせ削減に効果があります。一方で、複雑な判断や長文分析はクラウドLLMへ任せるべきです。これからの建設AIは、現場側のSLMとクラウド側のLLMを組み合わせたハイブリッド構成へ進んでいきます。
重要なKPIは、応答遅延、オフライン対応率、クラウド通信量、現場問い合わせ削減、AI回答の根拠提示率です。AIの性能をモデルサイズだけで評価するのではなく、現場で本当に使えたか、作業を止めずに支援できたかで評価する必要があります。
建設AIは“大規模クラウドAI”だけでは動きません。現場で使うSmall Language Modelは、日報、安全、機械トラブル、現場ルール検索、ロボット運用を支える、新しいオンサイトAI基盤になっていくはずです。





