AIエージェント導入の成否は、モデルよりも「業務設計」で決まる
ファッション・アパレル業界6社、20名が参加した第一回ナレッジ共有会では、店舗業務支援AIエージェント「SMART」を起点に、現場での開発・導入事例が共有された。
紹介されたのは、単なるPoCのデモではない。週報作成の効率化、短期間でのWebアプリ開発、ベテランの経験に依存していた在庫消化業務のエージェント化など、実際の業務を変えることを目指した取り組みだ。
生成AIやAIエージェントの導入を検討するエンジニアにとって重要なのは、どのモデルを選んだかだけではない。現場の課題をどう選び、誰と作り、効果をどう測定し、運用に定着させるかという一連のプロセスに、再利用できる知見がある。
共有会で示された3つの実践例
週報作成を自動化し、15分を0分へ
店舗業務では、日々の活動内容を整理して週報にまとめる作業が発生する。共有会では、この週報作成について、従来15分かかっていた作業を0分にした事例が紹介された。
ここで注目すべきなのは、生成AIに文章を書かせたこと自体ではない。現場で発生する情報を、報告という業務成果物に変換する流れを対象にした点だ。
AIエージェント化を検討する際は、「文章を生成できるか」ではなく、次のように業務の前後関係を分解すると設計しやすい。
- どの情報を入力として扱うか
- 誰が、どのタイミングで利用するか
- どの形式の成果物が必要か
- 人による確認や修正をどこに残すか
- 作成時間や修正回数をどう測るか
IT未経験者が2週間でWebアプリ開発
別の事例では、IT未経験の店舗出身メンバーが、2週間でWebアプリ開発に取り組んだ。これは、現場担当者を単なる要望提供者として扱うのではなく、開発プロセスに参加させる可能性を示している。
現場をよく知る人が開発に関わると、要件定義の初期段階で業務上の例外や使われない機能を見つけやすい。一方で、短期間の開発では、完成度を高めることよりも、利用者が触れる最小限の機能を早く用意し、対話を通じて改善することが重要になる。
エンジニア側に求められるのは、すべてを代行することではない。次のような開発環境や進め方を整え、現場メンバーが判断できる状態を作ることだ。
- 業務用語とシステム用語を対応づける
- 小さな単位で動作を確認できるようにする
- 入力例と期待する出力例を用意する
- 失敗しても業務データに影響しない検証環境を分ける
- 変更内容と判断理由をチームで共有する
ベテラン依存の在庫消化業務をエージェント化
在庫消化業務では、過去の経験や商品知識を持つベテランの判断に依存しやすい。共有会では、このような業務をAIエージェント化する取り組みも紹介された。
この種のテーマでは、ベテランの判断をそのまま自動化しようとすると、暗黙知の抽出が難しくなる。まずは、判断に使っている情報と、判断後に実施する作業を切り分ける必要がある。
例えば、検討対象は次のように整理できる。
- 判断に利用する商品、在庫、販売実績などの情報
- 判断結果に至った理由
- 例外として人が介入する条件
- 提案を実行に移す前の承認手順
- 判断結果と実績を振り返る方法
AIエージェントは、最初から完全な自動実行を目指すよりも、候補の提示や情報整理から始める方が、業務への影響を抑えながら知見を蓄積しやすい。
エンジニアが押さえるべき、現場起点の開発サイクル
今回の事例から、AIエージェント導入を次のサイクルで進める考え方が見えてくる。
- 現場の作業を観察し、時間がかかる箇所と判断が難しい箇所を分ける
- 効果を測定できる小さな業務単位を選ぶ
- 現場担当者と入力、出力、例外条件を定義する
- 短期間で試作し、実際の利用者からフィードバックを得る
- 人の確認を残した状態で運用し、品質と効果を測る
- 成果と課題を共有し、別の業務や組織へ展開する
この流れでは、技術検証と業務検証を分けないことが重要だ。モデルの回答精度だけを評価しても、現場で使われなければ導入効果は生まれない。
Amazonのサービス群を使う場合の設計観点
共有会のテーマには、Amazon Bedrock、Amazon Bedrock AgentCore、Amazon Machine Learning、Amazon S3 Tables、Amazon Transcribe、Strands Agents、Kiroなどが挙げられている。これらは、生成AIの利用、エージェント開発、データ活用、音声情報の処理などを検討する際の選択肢となる。
ただし、サービス名を先に決めるのではなく、業務要件から構成を考えるべきだ。特に小売・店舗業務では、次の観点が設計の前提になる。
- 店舗や本部の誰が利用するのか
- 商品・在庫・販売情報をどの単位で参照するのか
- 店舗ごとの権限やデータ分離が必要か
- AIの提案を誰が承認するのか
- 誤った提案が発生した場合に業務を止めずに戻せるか
- 利用履歴や判断理由を後から追跡できるか
AIエージェントでは、推論の品質だけでなく、参照データの鮮度、ツール実行の権限、ログ、再実行時の挙動まで含めて設計する必要がある。
「作って終わり」を防ぐ効果測定
AI導入の効果は、削減時間だけでは評価しにくい。週報作成のように作業時間を直接測れるケースもあるが、在庫業務や接客支援では、業務品質や意思決定の速さも重要になる。
評価指標の例は次の通りだ。
- 作業にかかった時間
- 人による修正や差し戻しの回数
- 提案が利用された割合
- 人が介入した割合と介入理由
- 業務完了までのリードタイム
- 利用者が継続利用しているか
導入前の基準値を取らずに導入すると、改善の有無を判断できない。小さな業務から始め、利用状況と失敗例を記録することが、次の改善や他店舗への展開条件を見極める材料になる。
現場との協働が、AIエージェントの再現性を高める
今回のナレッジ共有会で最も実務的な示唆は、AIエージェントを個別部署の実験で終わらせず、複数社が経験を持ち寄る場を作ったことにある。現場課題の選び方、短期開発の進め方、ベテランの知識を扱う方法は、企業ごとに異なる一方で、共通化できる部分も多い。
エンジニアやDX推進担当者が取り組むべきなのは、最新技術を導入することだけではない。現場メンバーが課題を言語化し、試作品を使い、結果を振り返れる開発プロセスを組織に組み込むことだ。
SMARTの事例は、AIエージェント導入の価値が「何を作ったか」だけでなく、現場とともに学習しながら、業務に定着する仕組みを作れたかで決まることを示している。小さく始め、効果を測り、判断と責任の所在を明確にする。この原則は、ファッション・アパレルに限らず、店舗やバックオフィスの業務自動化にも応用できる。
出典： AWS公式ブログ