起票前の問い合わせ
現場担当者が「この内容は修繕として受け付けられるか」を確認する場面があり、最初の相談対応だけでも時間がかかっていました。
東北地方の大手電力会社で、設備修繕の初動業務を対象にAI活用を検証。候補業務の選定から現状業務の整理、業務そのものの再設計、試作、既存の業務管理システムとの連携、現場トライアル、効果試算、次の導入計画まで一気通貫で担当しました。
※ 守秘義務に配慮し、企業名、内部システム名、具体的な判断基準、詳細な件数・金額は非公開・抽象化しています。削減効果は実績ではなく、検証時点の試算です。
現場から設備の修繕依頼が上がると、内容確認、修繕が必要かの判断、必要に応じた追加確認、結果の記録、承認へと処理が続きます。
一つひとつは難しく見えなくても、件数が積み重なると大きな業務負荷になります。さらに、判断には社内のルールだけでなく現場の経験も必要で、確認先や担当者が変わると処理時間にも差が出やすい状態でした。
このプロジェクトでは最初から「修繕業務をAI化する」と決め打ちせず、まず社内の複数部門からAIを使えそうな業務を数十件集め、効率化の大きさと実現しやすさの両面から優先順位を付けました。その結果、設備修繕の一次判断を優先して試す業務として選定しました。
現場の仕事は、AIが「修繕が必要」と答えれば完了するわけではありません。その前後の問い合わせや承認まで含めて考える必要がありました。
現場担当者が「この内容は修繕として受け付けられるか」を確認する場面があり、最初の相談対応だけでも時間がかかっていました。
依頼内容だけでなく、社内基準や設備情報などを踏まえて判断する必要があり、単純な文章生成では代替できませんでした。
すべてを自動処理せず、判断できない案件や確認が必要な案件を適切に人へ渡す導線も必要でした。
現状の業務フローを確認し、「AIが担当するところ」「人が最終確認するところ」「例外として戻すところ」を明確にしました。
社内から集めた多数の業務候補を、削減できる時間の大きさと、現実的に実装・運用できるかという観点で比較しました。
誰が、どの情報を確認し、どの条件で次へ進めるかをヒアリング。曖昧な箇所を確認しながら実際の仕事の流れを可視化しました。
問い合わせ対応、修繕要否の一次判断、承認に必要な情報整理という3つの支援機能に分け、人が確認すべき場面も残しました。
AIが回答して終わりではなく、既に使われている業務管理の仕組みに情報を渡し、利用者が確認して次の処理へ進める導線を作りました。
複数の現場担当者に短期間で繰り返し試してもらい、入力項目、説明の仕方、結果の見せ方、人への引き継ぎ方を改善しました。
現在業務の時間とAI導入後の想定を比較し、年間でどれだけ削減余地があるかを試算。本番化に向けた次の進め方まで整理しました。
検証では5名の利用者と1週間で4回のトライアルを行い、完成したものを最後に見せるのではなく、試すたびに改善しました。
利用者が本来知らなくてもよい項目や誤入力につながる項目を減らし、現場の役割に合った入力へ絞りました。
結果の順番や強調方法を調整し、利用者が最初に確認すべき情報がすぐ分かるよう改善しました。
AIだけで決めない案件では、どこへ相談すべきか、どう引き継ぐかまで業務の流れとして設計しました。
試作だけで終わらず、現場での利用を通じて実務適用の可能性を確認。本番導入に向けた次の段階へ進む判断につながりました。
対象業務を分解して現在の作業量とAIが支援できる割合を整理した結果、年間で数千時間規模の削減余地があると試算しました。これは導入後の実績値ではなく、次の投資判断に使うための期待効果です。
「何をAI化するか」を決める前段から、実際に動く仕組みを作り、次の導入計画を描くところまで担当しました。
対象業務の選定、現状業務の整理、業務再設計、AIの設計・実装、既存業務システムとの連携、現場トライアル、効果試算、次の導入計画まで担当しました。
AIの回答精度だけで評価しないことです。入力の負担、結果の分かりやすさ、例外時の引き継ぎ、既存業務とのつながりまで含めて「このまま仕事で使えるか」を現場と確認しました。
AIの回答が正しいかだけでは、本番導入できるかは判断できません。
実際の利用者が入力し、結果を確認し、必要に応じて人へ相談し、既存システムで次の処理を行う。その一連の流れが無理なく成立して初めて、業務で使える状態になります。
この案件では、候補業務の選定 → 業務の再設計 → 試作 → 現場トライアル → 効果試算 → 次の導入計画を一つの流れとして進めました。AI導入を「ツール導入」ではなく「仕事の変え方」として扱ったことが、本番化へつながったポイントです。
業務の種類は違っても、現場の判断や運用を理解したうえでAIの役割を決めています。