こんにちは、建設AIエンジニアの内田沙織です。
普段はヘルメットを被って建設現場を歩き回り、点群データやセンサー情報と格闘していますが、今日はオフィスのデスクで、あるいは会議室で「どうすればAIを業務に活かせるのか」と頭を抱えている皆さんに、少し違った角度からのお話をさせてください。
「AI導入を進めろと言われたけれど、社内にエンジニアがいない」
「外注すると数百万円の見積もりが出てきて、検証（PoC）すら始められない」
こんな悩み、よく耳にします。私のいる建設業界でも全く同じです。現場のことは現場が一番知っているのに、それをシステム化しようとすると、途端に「技術の壁」と「コストの壁」が立ちはだかるんですよね。
でも、諦めるのはまだ早いです。実は今、Pythonなどのプログラミングコードを一切書かずに、クリック操作だけで本格的なAIモデルを作れる時代になっています。それが、マイクロソフトが提供するクラウドサービス「Azure Machine Learning（Azure ML）」です。
「クラウド？ Azure？ 難しそうだし、設定を間違えて高額請求が来たら怖い」
そう思うのも無理はありません。でも大丈夫。今日は、エンジニアではない「現場のプロ」である皆さんが、安全に、そして安価に、自分たちの手でAI活用への第一歩を踏み出すためのロードマップをお渡しします。データの準備からモデル作成、そして現場での活用まで、一緒に見ていきましょう。
なぜ今、「現場主導」のノーコードAI開発が安全な選択肢なのか
AI開発というと、優秀なデータサイエンティストやAIエンジニアに「丸投げ」するのが正解だと思っていませんか？ 実は、初期の検証段階においては、それが失敗の元になることが多々あります。
エンジニアへの丸投げが失敗する「コミュニケーションコスト」の罠
外部のエンジニアや社内のIT部門は、AIの技術には詳しいですが、皆さんの「業務」については素人です。
例えば、「来月の受注数を予測したい」というオーダーを出したとしましょう。エンジニアは渡されたデータを元に、数学的に最も誤差が少ないモデルを作ります。しかし、現場からすれば「誤差が少なくても、この特定の顧客の予測を外されると困る」とか、「季節変動を考慮していない数値は使えない」といった、データには現れにくい暗黙知があるはずです。
このギャップを埋めるための打ち合わせや修正に、膨大な時間とコストがかかります。これを「コミュニケーションコスト」と呼びますが、PoC（概念実証）の段階でここで消耗してしまうプロジェクトが本当に多いのです。
だからこそ、業務を知り尽くしている皆さんが、ノーコードツールを使って「まずは自分で作ってみる」ことに大きな価値があります。肌感覚と合うかどうかの初期判断は、現場の人間にしかできません。
Azure Machine Learningが提供する「市民データサイエンティスト」へのガードレール
「素人がAIなんて作って大丈夫？」という不安もあるでしょう。そこでAzure Machine Learning（Azure ML）のようなプラットフォームの出番です。
Azure MLには「自動機械学習（AutoML）」という機能があり、データの性質に合わせて最適なアルゴリズムを選び、パラメータ調整まで支援してくれます。人間がやると数週間かかる試行錯誤を、AIが短時間で実行してくれるイメージです。
ただし、AIプラットフォームの最新動向には注意が必要です。
技術の進化は非常に速く、ツールの機能統廃合も頻繁に行われています。例えば、データ分析基盤として人気のDatabricksでは、Runtime 18.0において従来のAutoML機能が廃止されるといった変更がありました。一方で、Microsoft Fabricではコード優先の新しいAutoML機能が登場するなど、選択肢は常に変化しています。
こうした変化の中で、現場担当者が安心して開発を続けるには、以下の点が重要になります：
- 公式情報の確認: 利用するツールの機能が現在もサポートされているか、最新のドキュメント（Azure MLやMicrosoft Fabricの公式サイト）で確認する習慣をつけること。
- セキュリティとガバナンス: 個人のPCでフリーソフトを使うのではなく、Azureのようなエンタープライズレベルのセキュリティ（暗号化やアクセス制御）が標準装備された環境を選ぶこと。これにより、会社の重要なデータを扱う上でも情シス部門を説得しやすくなります。
Azure MLは、こうしたガバナンスと利便性のバランスが取れており、現場主導の開発における強力な「ガードレール」となってくれます。
本記事で作成するモデルのゴール設定：精度100%ではなく「判断の補助」
これからAI作りを始めますが、一つだけ約束してください。「精度100%を目指さない」ことです。
AIは魔法の杖ではありません。特にビジネスデータにはノイズ（不規則な変動）が多く、100%当たる予測なんて不可能です。目指すべきは、「人間が勘と経験でやっていた判断を、データで裏付けする」こと、あるいは「明らかな見落としを防ぐ」ことです。
「70%くらいの確率で当たるなら、参考情報として使えるよね」
これくらいの軽い気持ちでスタートするのが、現場主導AIを成功させる秘訣です。
事前準備：Azure ML Studioの「怖くない」歩き方
さて、ここから実践編です。まずはAzureのポータルサイトに入り、作業環境を作ります。
ここで一番心配なのは「クラウド破産（予期せぬ高額請求）」ですよね。私も昔、GPUインスタンスを消し忘れて青ざめた経験があります。だからこそ、最初に「お財布の紐」をしっかり締める設定から始めましょう。
必要なアカウントと権限設定のチェックリスト
まず、会社のAzureアカウントが必要です。もしなければ、無料試用版のアカウントを作成しましょう。ここで必要な権限は「共同作成者（Contributor）」レベル以上が望ましいですが、リソースグループという単位で権限をもらえれば十分です。情シス部門に依頼する場合は、「Azure Machine LearningでPoCをしたいので、予算上限を設定したリソースグループを一つ払い出してほしい」と伝えるとスムーズです。
コストへの不安を解消する：予算アラートの設定手順
作業を始める前に、必ず「予算アラート（Cost Management）」を設定します。
- Azureポータルで「コストの管理と請求」を検索。
- 「予算」メニューから「追加」をクリック。
- 例えば「月額5,000円」と設定し、その50%（2,500円）や80%（4,000円）に達したらメールが飛ぶように設定します。
これをしておけば、知らぬ間に課金される恐怖から解放されます。今回のPoCレベルなら、計算リソースを適切に管理すれば数千円、うまくやれば無料枠内で収まることもあります。
Azure Machine Learning Studioの基本画面と用語の「翻訳」
リソースグループ内に「Azure Machine Learning ワークスペース」を作成し、「スタジオの起動」をクリックすると、専用の管理画面が開きます。専門用語が並んでいますが、怖がる必要はありません。現場用語に翻訳してみましょう。
- コンピューティング（Compute）: パソコン本体です。計算処理をするサーバーのこと。最初は「コンピューティングインスタンス」を一つ作ります。スペックは一番安い「Standard_DS11_v2」あたりで十分です。重要なのは「自動シャットダウン」をオンにすること。これで切り忘れを防げます。
- データ（Data）: 書類棚です。ここにExcelやCSVファイルをアップロードします。
- 実験（Experiments）: 試行錯誤の履歴です。「〇月〇日のテスト」みたいな記録がここに残ります。
- モデル（Models）: 完成したAIの頭脳です。これを保存して使います。
この4つさえ分かっていれば、あとは迷子になりません。
Step 1 データ準備：使い慣れたExcelデータを「AIの燃料」に変える
AI開発で最も時間がかかり、かつ重要なのがこの「データ準備」です。料理で言えば下ごしらえ。腐った食材（汚いデータ）を使えば、どんな一流シェフ（高性能AI）でも美味しい料理は作れません。
AIが学習しやすい「綺麗なデータ」の3つの条件
普段使っているExcelファイル、そのままではAIに使えないことが多いんです。以下の3点をチェックしてください。
- 1行1レコードの原則: セルの結合は禁止です。1行につき1件のデータ（例：1つの受注、1人の顧客）が入っている状態にします。
- ヘッダーは1行のみ: 表の上に「2024年度 売上管理表」みたいなタイトル行が入っていませんか？ AIには邪魔なだけなので削除し、1行目を項目名（日付、商品名、金額など）にします。
- 数値と文字の混在NG: 金額の列に「¥1,000」と「見積中」が混ざっていませんか？ 数値なら数値だけ、文字なら文字だけに統一します。
データセットのアップロードとプロファイル確認機能
データをCSV形式で保存したら、Azure ML Studioの「データ」メニューからアップロードします。ここで「表形式（Tabular）」を選んでください。
アップロードが完了すると、Azureが自動的にデータを読み込み、「プロファイル」というタブでデータの中身を可視化してくれます。これがすごく便利なんです。
各列のヒストグラム（分布図）が表示され、「この列には空欄（欠損値）が何%あるか」「異常に大きい数値が入っていないか」が一目でわかります。
欠損値やエラーをAzure上で確認・修正する方法
もしプロファイル画面で「欠損値が多い」と判明したら、Excelに戻って修正します。例えば、空欄を「0」で埋めるのか、それとも平均値を入れるのか、あるいはその行ごと削除するのか。これは業務知識がある皆さんにしか判断できないことです。
「この項目の空欄は、未入力ではなく『該当なし』という意味だから、別のカテゴリとして扱おう」
こうした判断こそが、現場主導AIの強みになります。エンジニアだと、機械的に「0」で埋めてしまって、予測がおかしくなることがよくあるんですよ。
Step 2 自動機械学習（AutoML）：クリックだけで「最強のモデル」を探し出す
データが整ったら、いよいよAIモデルの作成です。ここで使うのが「自動機械学習（AutoML）」。現場のエンジニアにとって、まさに魔法のようなツールです。
昨今のAI業界では、Databricksの最新ランタイムのように一部でAutoML機能が見直され、コード記述を前提とした開発へ回帰する動きも見られます。しかし、Azure Machine Learningにおいては、ノーコードで利用できるAutoML機能が引き続き強化されており、私たちのような現場担当者にとっての強力な武器であり続けています。
「自動機械学習」は何を自動化してくれるのか
通常、AIを作るには「どのアルゴリズムを使うか（決定木？ ニューラルネットワーク？）」、「ハイパーパラメータ（設定値）をどうするか」などを延々と試行錯誤する必要があります。AutoMLは、これを全部やってくれます。
さらにAzure Machine LearningのAutoMLは、モデルが「なぜその予測をしたのか」を説明する機能や、探索プロセスの可視化もサポートしています。これにより、「中身がブラックボックスで現場導入が怖い」という懸念も解消しやすくなっています。
皆さんがやるのは、「どのデータを使って」「何を予測したいか」を指定するだけです。
予測タスク（分類・回帰・時系列）の正しい選び方
AutoMLの設定ウィザードを進めると、タスクの種類を選ぶ画面が出てきます。建設現場の課題解決において、ここだけは間違えないようにしましょう。
- 分類（Classification）: 「AかBか（あるいはCか）」を当てるタスクです。
- 例：この入札案件は「成約」するか「失注」するか。
- 例：トンネル切羽の画像から岩盤等級を判定する。
- 回帰（Regression）: 「数値」を当てるタスクです。
- 例：工事完了までの「残日数」を予測する。
- 例：来月の資材コスト（金額）を予測する。
- 時系列予測（Time-series forecasting）: 時間の流れに沿った将来の数値を当てるタスクです。
- 例：来週の現場ごとの必要作業員数。
- 例：過去のデータに基づいた重機の稼働率推移。
自分のやりたいことがどれに当てはまるかを選びます。
実験の実行とコーヒーブレイク：計算資源にお任せする時間
次に「ターゲット列（予測したい項目）」を選びます。例えば「成約フラグ」や「売上金額」の列です。
そして最後に「制限設定」を行います。ここもコスト管理のポイントです。「実験のタイムアウト時間」を例えば「1時間」や「3時間」に設定しましょう。これをしておけば、計算が延々と続いてクラウド利用料が膨らむのを防げます。
設定が終わったら「終了」をクリック。あとはAzureのクラウド上のコンピューターが、数十種類のアルゴリズムを総当たりで試してくれます。人間が手作業でやれば数週間かかる作業です。
最近では、Microsoft Fabricなどの新しい分析基盤でもAutoML機能（コード優先プレビューなど）が登場し、選択肢は広がっていますが、まずはAzure Machine LearningのGUIベースの操作で感覚を掴むのが一番の近道です。
皆さんはここでコーヒーでも飲んで、現場の巡回や他の業務を進めていてください。結果が出るまで待つだけです。
Step 3 評価と判断：AIの「成績表」を正しく読み解く
実験が終わると、Azure Machine Learning（Azure ML）は「これが一番成績が良かったモデルです」とランキング形式で結果を返してくれます。しかし、1位のモデルをそのまま採用してよいかというと、そう単純ではありません。
最近では、Databricksなどの一部データ基盤でAutoML機能の提供形態が見直されたり、Microsoft Fabricのようにコード優先（Code-First）のAutoML機能が登場したりと、「AI任せにせず、人間が中身を理解・制御すること」の重要性が業界全体で再認識されています。Azure MLのAutoMLは依然として強力ですが、出力された結果を鵜呑みにせず、私たち人間が厳しくチェックする必要があります。
「正解率」だけで判断してはいけない理由
よく「正解率（Accuracy）95%！」といった数字を見て安心してしまうことがありますが、これには大きな罠があります。
例えば、建設現場の安全管理で「不安全行動」を検知するAIを作るとします。100シーン中99シーンが安全で、1シーンだけ危険な場面があったとしましょう。このとき、AIが何も考えずに「全部安全です」と答え続けたとしても、正解率は99%になります。しかし、たった1回の危険を見逃すAIは、現場では0点の評価となります。
ビジネスにおいては、「見逃し」が致命的なのか、それとも「誤検知（空振り）」がコスト増につながるのかによって、見るべき指標が全く異なります。
混同行列（Confusion Matrix）の見方とビジネスインパクト
そこで見るべきなのが「混同行列（Confusion Matrix）」という図表です。Azure MLのAutoML結果画面にある「メトリック（Metrics）」タブで確認できます。
- 真陽性（True Positive）: AIが「危険」と予測し、実際に危険だった。（お手柄！事故を未然に防げた）
- 偽陽性（False Positive）: AIが「危険」と予測したが、実際は安全だった。（空振り。確認の手間は増えるが、安全サイドには倒せる）
- 偽陰性（False Negative）: AIが「安全」と予測したが、実際は危険だった。（見逃し。建設現場ではこれが最も恐ろしい事態）
現場の感覚として、「多少の空振り（偽陽性）があってもいいから、事故の予兆（偽陰性）だけは絶対に見逃したくない」のであれば、再現率（Recall）を重視したモデルを選びます。逆に、無駄なアラートで現場監督を疲弊させたくない場合は、適合率（Precision）とのバランスを考慮する必要があります。
「説明可能性」機能でAIの判断根拠を確認する
もう一つ、現場への導入で不可欠なのが「なぜそう予測したのか」という理由付けです。Azure MLには「説明（Explanations）」機能（責任あるAIダッシュボードの一部として提供されることもあります）が備わっています。
これを確認すると、「この工期遅延予測には『降水量』が一番影響している」「『特定の重機』が稼働するとリスクスコアが上がる」といった、AIが注目した特徴量の重要度が可視化されます。
「なるほど、確かに雨続きだと地盤が緩むから、AIもそこをリスク要因として見ているんだな」
こういった納得感（腹落ち）がないと、熟練の職人さんや現場監督はAIを信頼してくれません。ブラックボックス化を防ぎ、人間とAIが協調するためにも、この機能は必ずチェックしましょう。
Step 4 デプロイと活用：ExcelやPower BIで予測結果を使う
納得のいくモデルができたら、いよいよ実戦配備（デプロイ）です。といっても、難しいアプリ開発は不要です。
ワンクリックでのエンドポイント作成（デプロイ）
選んだモデルの詳細画面から「デプロイ」→「リアルタイムエンドポイント」を選びます。これで、インターネット経由でデータを投げると予測結果を返してくれる「API」という窓口が作られます。
※注意：エンドポイントを立ち上げっぱなしにすると課金され続けます。PoC段階では、使う時だけ立ち上げるか、あるいは「バッチエンドポイント（まとめて処理）」を使うのがお財布に優しいです。
エンジニアがいなくてもできるExcelからのAPI呼び出し
実はExcelには、Web上のデータを取得する機能があります。これを使えば、Excelのセルに入力したデータをAzureに送り、予測結果を隣のセルに返す…なんてことも可能です（少しマクロやPower Queryの知識が必要ですが、ネット上のサンプルコードで十分対応できます）。
Power BIと連携して予測結果をダッシュボード化する
もっと簡単なのがPower BIとの連携です。Power BIにはAzure MLと接続する機能が標準で備わっています。
データを読み込む際に「AI Insights」という機能を使うと、作成したモデルを選んで適用できます。これで、「来月の売上予測」を含んだレポートが自動的に出来上がります。
経営会議でこのレポートを見せながら、「AIによる予測ではこうなっています」と説明できれば、説得力は段違いですよね。
よくあるトラブルと「転ばぬ先の杖」
ここまで来れば、立派な「市民データサイエンティスト」です。最後に、建設現場の安全管理と同じように、AI開発において初心者が陥りやすい「落とし穴」と、その対策（KY活動：危険予知）をお伝えします。
「精度が出ない」ときに疑うべきポイント
「AutoMLを使っても、全然当たらない…」
そんな時は、アルゴリズムではなくデータを疑ってください。必要な情報が足りていないことがほとんどです。
例えば、工事の進捗遅れを予測するのに「天候」のデータが入っていなかったり、資材の搬入遅延情報が抜けていたりしませんか？ AIは与えられたデータ以外のことは知りようがありません。「現場監督ならこう判断するはず」という要素がデータに含まれているか、もう一度見直しましょう。
データ更新とツールの進化への対応
一度作ったモデルも、時間が経てば古くなります。これを「モデルのドリフト（陳腐化）」と呼びます。建設現場でも、新しい工法や重機が導入されれば、過去の作業データは参考にならなくなりますよね。
「3ヶ月に1回は最新データで再学習させる」といった運用ルールを最初に決めておくことが重要です。Azure Machine Learningなら、この再学習プロセスも効率化できます。
また、AIプラットフォーム自体の変化にも注意が必要です。
AI技術の進化は非常に速く、ツールの機能も頻繁に更新されます。
- 機能の統廃合: 一部のデータ分析プラットフォーム（例：Databricksの一部のランタイムなど）では、AutoML機能の提供形態が見直されるケースも報告されています。
- 新しい選択肢: Microsoft Fabricのように、より統合されたデータ分析基盤が登場し、コード優先のAutoML機能などが提供され始めています。
「一度覚えたら終わり」ではなく、Azure MLの公式情報や新機能（Microsoft Fabricとの連携など）を定期的にチェックし、現場の技術と同様にアップデートしていく姿勢が大切です。
本格導入に向けてエンジニアに引き継ぐタイミング
今回の手法は、あくまで「検証（PoC）」や「部門内での活用」向けです。
もしこのAIが全社の基幹システムに組み込まれることになったり、お客様向けのサービスとして提供することになったりしたら、その時はプロのエンジニアにバトンタッチしましょう。
「Azure MLでこういうモデルを作り、こういう特徴量が効くことまでは検証済みです」
そう言って引き継げば、エンジニアも大喜びです。仕様が明確なので開発もスムーズに進み、結果として開発コストも大幅に下がります。
まとめ：まずは「小さく」始めてみよう
いかがでしたか？ 難しそうに見えるAzure Machine Learningも、一つずつ紐解けば、普段の工程管理や安全管理の延長線上で使えるツールだと感じていただけたのではないでしょうか。
- コスト管理を最初に行う（予算アラート設定）
- データを綺麗にする（1行1レコードの徹底）
- AutoMLにモデル探しを任せる
- ビジネス視点で評価し、説明可能性を確認する
このステップを踏めば、Pythonが書けなくても、外注費をかけなくても、自分たちの手でAIの可能性を検証できます。失敗しても、かかるのは数千円のクラウド利用料と、皆さんの少しの時間だけ。でも、そこで得られる知見はプライスレスです。
まずは身近なExcelデータを使って、小さなモデルを一つ作ってみてください。「自社のデータで本当にできるか不安」という場合は、Microsoftが提供する公式のラーニングパス（Microsoft Learn）や、コミュニティが開催する勉強会などを活用して情報を集めるのも良いでしょう。
一人で悩んで画面とにらめっこするより、同じ課題を持つ仲間や専門家の知見に触れることで、解決の糸口が見つかるはずです。現場を変えるのは、AIというツールではなく、それを使いこなそうとする皆さんの熱意と創意工夫ですから。
皆さんのご安全と、AI活用の成功を心から応援しています！
コメント