物流・運輸のAI活用事例

予約の変更依頼がWhatsAppとLiveChatの会話の約8〜9%を占めていた。

それなのに客が自分で変更する手段がなく毎回オペレーターが対応していた。

1. Sprinklr AI+でWhatsAppに会話型の予約変更の仕組みを作った
2. 客がチャットで出発地・目的地・搭乗日・座席クラスを伝える形にした
3. AIが変更できる予約かを確かめ選べる案をその場で返す
4. 1件の変更で走る7〜8件のシステム連携を裏側で動かす
5. AIで完結しないときは有人のサポートへつなぐ

対象になる予約変更のうち約70%が人の手を借りずに終わった。

立ち上がりの使われ方が良かったのでLiveChatへも広げている。

出荷の手続きがメールや表計算や船会社のポータルに分かれていて同じ内容を人が何度も書き写していた。

運賃の市況が落ち込んで人員を75%減らしたため元のやり方では回らなくなった。

1. 出荷の定型作業を78のAIエージェントに振り分けた
2. エージェントが状況を読み取り手配や連絡まで進める
3. 人は12人を残し例外の対応と最終責任を持つ
4. メールや表計算やERPの書き写しもエージェントへ寄せた

12人の体制のまま出荷の実行が回るようになった。

人を増やさずに扱える仕事の量を伸ばせるようになった。

窓口ごとに仕組みが分かれていて、応対の質を見張るのが難しかった。

SNSだけ別のシステムで見ており、他の窓口へ広げるには費用と連携の手間がかかった。

1. 101あった問い合わせ窓口をZendeskに寄せる。
2. 1つの画面でやり取りを見られるようにする。
3. 簡単な用件はAIエージェントが自動で受け答えする。
4. 判断が要るものだけ人の担当者へ回す。
5. Copilotが過去のやり取りの要点を担当者へ渡す。

日々のやり取りの86%をAIが受け持つようになった。

第1段階で101の窓口をまとめ、238ライセンスを入れて月20万件の会話をさばいている。

乗客のほとんどが同じ内容の案内を受け取っていた。

顧客の情報がマーケティングとデジタル部門と窓口に散らばり、一人ひとりに合わせた案内を手作業で組むしかなかった。

1. 会員の属性と予約の傾向と履歴を一つの基盤へ集めた
2. 常に更新される一つのプロフィールにまとめた
3. AIが次に必要になりそうなことを予測する
4. 予測に沿ってメールとウェブとアプリの対応をつなぐ
5. 担当者は届ける相手の切り分けと流れの設計を受け持つ

狙いを絞った配信からの売上が40%増え、マーケティングの分析は60%速くなった。

個別の出し分けの量は大きく増え、顧客対応の中心となる業務の生産性も30%上がった。

駅の無人化が進んで対面案内が減り、忘れ物や切符の買い方の問い合わせがお客さまセンターに集まって放棄呼が出ていた。

2011年に作った公式サイトは情報を足し続けて分かりにくくなり、旧FAQシステムも操作と更新の手間が大きかった。

1. 公式サイトを作り直し別ドメインの観光情報をまとめた
2. FAQをAIが学習を助けるsmartFAQに入れ替えて公開した
3. 大量に来る決まった質問は定型回答のチャットボットで返す
4. ばらつく質問はサイトを探して答えるAIに任せた
5. 多言語ページにもAI回答を置きサイト修正で追従させた

リリースから約1ヶ月で放棄呼の割合が約2分の1に減り、FAQの稼働率は旧システムの数倍になった。

交通系ICカードやQR乗車券に関する電話はほとんど来なくなり、多言語FAQの個別更新も要らなくなった。

顧客が何を求めているかを知る手がかりが担当者の体感しかなく、数字で示せなかった。

急な出来事が起きても中身をすぐ把握できず、方針の判断が遅れていた。

1. Cresta Insightsで顧客の声をその場で読み取った
2. 担当チームが疑問から答えまで数分でたどり着ける形にした
3. 応対中はAgent Assistが要約や返答候補を出す
4. 簡単な手続きは自動化へ回し難しい相談に力を向けた
5. 得られた内容は商品やルールの見直しにも回した

平均処理時間が15%改善し、顧客への応答時間は50%改善した。

急な出来事にもその場で気づいて対応を決められるようになった。

新しい路線や規則の変更が続き顧客が何に困っているかの把握が追いつかなかった。

担当者は複数のシステムを行き来して答えを探していた。

1. 顧客対応の窓口にCrestaを入れる
2. 全ての会話を聞き取らせて問い合わせの理由を分ける
3. 当日のうちに傾向を見られるようにした
4. 通話中は担当者の画面に必要な案内を出す
5. 採点の結果から誰にどんな指導をするか決める

問題の発生をその日のうちに見つけて解決できるようになった。

以前は原因の把握だけで数週間かかっていた。

客室乗務員と接客職に週300件を超える応募があり書類選考から電話面接・集団面接・対面面接まで人手で進めていた。

電話がつながらない応募者や集団面接の欠席が平均30%あり採用に何か月もかかっていた。

1. 電話での一次面接をやめた。
2. HireVueのOnDemand録画面接に置き換えた。
3. 応募者は都合のいい時間に設問へ答える。
4. 通過した人だけを最終選考に呼んだ。
5. 語学が要る職種は指定した言語で質問した。

採用にかかる期間が3か月から2〜3週間に縮んだ。

最終選考の欠席も減り招待した学生の90%が録画面接を最後まで受けている。

交通違反の通知書が紙で届き、243の自治体から287通りの様式が混ざっていた。

項目の場所も名前もばらばらで、打ち込みに毎月160時間かかっていた。

1. 287通りの様式から代表の32種類を選んだ
2. 通知書およそ1,000枚で学習データをそろえた
3. 文字を読んで様式を見分け必要な項目を取り出す
4. 読み取りの自信が低いものは人の確認へ回した
5. 直した内容を学習に戻して精度を上げる

読み取りの正しさは95%になり、手作業では見落としていた分も自動で拾えるようになった。

会社全体では年96,400時間の手作業が減り、自動化の案件は7件から59件に増えた。

繁忙期やイベントで人が一気に増えると保安検査の待ち時間が読めなくなった。

管理者は電話で各検査場の状況を聞くしかなく乗客にも待ち時間が伝わらなかった。

1. 既にある防犯カメラ500台の映像をZensorsへ流した
2. 検査場の列と待ち時間を常に数値で出させた
3. 1時間ごとの手集計をやめて画面の数字を自動で更新した
4. 数字を見て人の配置を変え乗客を空いた検査場へ誘導する
5. 解析はMetropolisやTensorRTでGPU側に寄せた

導入は2か月で終わり設備投資なしで運用が始まった。

20分を超える待ち時間が大きく減り設備投資は500万ドル超を節約できて運用費は年14万ドル下がった。

TOBU POINT IDで乗車や買い物のデータが集まり顧客の姿は見えてきたが、その情報を使った販促の精度を上げきれずにいた。

狙う顧客を決めるまでの検討にも時間がかかっていた。

1. 会員データと改札データ、購買データを共通IDでつなぐ
2. AIエージェントに渡し月別や曜日別、時間帯別の属性を設計させる
3. 購入金額のカテゴリ比率から志向や沿線利用のタグを付ける
4. キャンペーン反応確率の予測モデルで反応しそうな人を先に選ぶ
5. 既存のCDPやMAは残し判断する部分だけAIで足す

機械学習で1,000以上のタグが自動で作られ、鉄道と流通をまたいだ顧客像を描けるようになった。

反応が見込める顧客に優先して案内を届け、関係の薄い通知は減らせる見通しになった。

ストライキや欠航が起きると問い合わせが一度に増えて、窓口が追いつかなくなっていた。

1. Cognigyの自動応答エージェントを問い合わせの入り口に置いた
2. 量の多い決まった質問はエージェントがそのまま答えた
3. 予約の取り直しや払い戻しも会話の流れの中で終わらせた
4. ライブチャットとつなぎ込み入った内容は人へ渡した

年間およそ1600万件の会話をAIが受け持ち、多い日は37万5000件に達した。

人のオペレーターは難しい相談に回れるようになり、平均の応対時間も大きく下がった。

経路や運賃の問い合わせがコールセンターと営業所に集まり、職員が人手の要る相談に時間を使えなかった。

1. AIエージェントを問い合わせの入り口に置いた。
2. 経路の案内やよくある質問にはAIが答える。
3. 人の判断が要る用件だけ職員へ回す。
4. 窓口が閉まった時間や離れた場所からも聞ける形にした。
5. 切符の販売や忘れ物の受付まで広げる計画を立てた。

コールセンターと営業所の負担が目に見えて減り、自動で終わる割合が上がった。

答えの質を落とさないまま、利用者は場所や時間に縛られずに問い合わせられるようになった。

注文が急に増えてもサーバーを手で足すしかなく費用が膨らみ続けた。

サイトに来た人を顧客につなげる割合も上げたかった。

1. 社内のエンジニアがAmazon Personalizeを組み込む
2. 利用者の行動データからおすすめを出す仕組みを作る
3. 配送基盤をAmazon EKSでコンテナにまとめる
4. 注文が増えたときは自動で処理能力が増える形にする
5. 裏側のやり取りはAmazon MQ画像の配信はCloudFrontに任せる

おすすめの仕組みを入れて3か月で月間注文が20%増え、新しい訪問者が顧客になる割合は30%上がった。

インフラの費用は40%減った。

ドローンは完全自動で飛ぶため目視の届かない場所でも安全に降りられるか判断する必要があった。

通信がほとんど届かない地域も飛ぶので機体だけで判定できないと運べない。

1. 着陸地点の画像を何千枚もGround Truthでラベル付けする
2. そのデータで自社のモデルをSageMakerで学習させる
3. 出来たモデルをSageMaker Neoで機体に載る形に最適化する
4. 機体をAWS IoT Coreでつなぎ遠隔のパイロットとやり取りする
5. 飛行ログをAWS Lambdaが読み異常があれば離陸を止める

メルボルンの遠隔運用センターからパイロット1人が30機以上を同時に飛ばせるようになった。

通信のほとんど無い場所でも離着陸の前に地上の障害物を確かめられる。

マイナス22度の冷蔵冷凍倉庫での作業は人が集まりにくく、人手頼みのままでは事業が続かない恐れがあった。

倉庫内の物の位置を知るためにセンサーやRFIDを全部に付けるのは手間も費用も見合わなかった。

1. 食品防御用に設置済みの監視カメラ映像を活用対象にした
2. 画像・動画解析エンジンのAMY Insightを選んだ
3. Deep Learningでフォークリフトやカゴ車を追跡する仕組みを作った
4. Amazon EC2上にAWS Deep Learning AMIで土台を組んだ
5. 1対象物あたり最大3,000枚弱で学習させ5ヶ月かけて精度を確かめた

追跡成功率97%を達成し、これまで取れなかった位置と追跡のデータが手に入った。

5ヶ月のうちインフラの準備は約1週間で終わり、残りを学習とモデル調整に回せた。

少人数のマーケティング部で、業界の実情に合った記事を早く出し続けるのが難しかった。

検索やAIの検索結果で自社が出てこないことも心配だった。

1. 運送業界の用語をJasperに覚えさせる
2. Jasper IQで自社の言い回しを読み込ませる
3. 代理店の指示書を渡して長い記事の下書きを出す
4. 担当者が下書きの言い回しを整える
5. ブログやSNSやメールも同じやり方で作る

人を増やさずに出せる記事の本数が増え、公開までの時間も短くなった。

新しく入ったメンバーは3週間で使える記事を書けるようになり、ブログへの訪問も伸びた。

前のCRMはメールやカレンダーやLinkedInや電話とつながらず、データの整理に手間がかかっていた。

サイトや広告ともつながらないので、見込み客の登録はすべて手入力だった。

1. 営業とマーケとサービスの機能をHubSpotに寄せる
2. メールやカレンダーや電話やLinkedInをつないだ
3. AIの自動化で見込み客を担当者へ自動で振り分ける
4. 商談のメモを自動で取る外部アプリを入れた
5. サイトをContent Hubにつなぎ問い合わせを処理する

成約率が16%から20%に上がり、平均の商談期間は半分以下になった。

手作業が減って22%の余力が生まれ、問い合わせへの初動は1日から60分になった。

過去の遅れは後から確認できても、この先どうなるかを読むことができなかった。

自前で持っていた仕組みは保守に手を取られ、大きな問い合わせが一つ走るだけで処理が滞った。

1. 社内のデータベースをやめAWS上のSnowflakeへ移した
2. 移行に21か月かけうち6か月で基幹システムのデータ構造を作り直す
3. 各部署が自分でデータを取りに行けるデータメッシュの形に変えた
4. 依頼を一つのチームが順番にさばくやり方をやめる
5. 文章の質問をSQLに直し結果を図で返す仕組みを載せた

ラストワンマイルのレポートは12時間から1時間になり、丸1日かかっていた月次の締めも2時間で終わるようになった。

運用のコストは50%下がった。

サポートへの問い合わせが増え続け、利用者はオペレーターにつながるまで30〜40分待たされていた。

担当者は同時に3〜4件を抱えて定型文の返答しか返せず不満が広がっていた。

1. 複数のモデルを回答の正しさと話し方で比べてClaudeを選んだ
2. まずドライバー向けの登録手続きの案内に使う
3. 地域ごとの決まりと全体の方針を踏まえて案内させる
4. 次に乗客側へ広げ請求の食い違いや乗車中の出来事も扱わせた
5. 安全に関わる相談は要約を付けて人の担当者へ回す

解決までの時間が87%以上短くなり、判断の正しさも30%以上上がった。

数百万ドルの費用が浮き、その分を担当者の育成に回した。

企画書や社外へのメールは、その都度上司のアポを取って文面を見てもらっていた。

打ち合わせと確認のやり取りに時間を取られていた。

1. 上司から受けたテーマをCopilotのチャットへ入れる
2. 鉄道会社の中堅社員という立場を与える
3. 安全や無償や実施時期や宛先を条件として伝える
4. 企画案を5つ出させ5つ目は現実離れした案にする
5. 出た案を企画書にまとめメール文案も作り自分で直す

一から考えるより早く形になり1件あたり40分かかっていた作業が10分程度になった。

週に4時間ほど労働時間が減り、確認の習慣がついてミスも減った。

乗客のほとんどが同じような案内を受け取っていて、一人ひとりに合わせた連絡ができていなかった。

顧客の情報が部署ごとに散らばり、全体像もつかめなかった。

1. 属性と予約とマイレージと行動の記録を1つのデータ基盤に集めた。
2. 集めたデータを一人ぶんのプロフィールとして常に更新する。
3. 組み込みのAIが乗客を分け、次に必要なことを予測する。
4. 乗り継ぎの補償と座席のアップグレードと初めて乗る人への案内を出し分けた。
5. メールとWebとアプリと窓口に合わせて自動で届ける。

一人ひとりに合わせた案内の量は大きく増え、マーケティングの分析は60%速くなった。

対象を絞った配信からの売上は40%増え、顧客対応まわりの生産性も30%上がった。

事業が伸びてデータの求められる量が増え自社設置の基盤にサーバーとディスクを足し続けるのが続かなくなった。

部署ごとにデータが分かれていたためデータ担当への依頼が溜まり答えが出るまで時間がかかった。

1. 自社設置の基盤からSnowflakeのAI Data Cloudへ移した
2. データの持ち主を部署ごとに分けるデータメッシュの形にする
3. 整えたデータを製品としてInternal Marketplaceに載せた
4. 旅の前と最中と後の記録を突き合わせて見られるようにする
5. 結果をPower BIで見える形にして路線の計画へ回した

移行した時点で前の分析の仕組みより費用が最大30%下がり年間の利用者は40%以上増えた。

計算と保存の増減は数か月かかった機器の増設なしにその場でできるようになった。

1件あたりの平均応対時間は9分で、1秒伸びるごとに年10万ドルの費用がかかっていた。

手順書はSharePointで頻繁に書き換わり、必要な記述をすぐ取り出せなかった。

1. SharePointにある手順書をKore.aiのSearch AIにつないだ。
2. 文書の形に合わせた抽出の仕組みを組んだ。
3. 質問に対して生成AIが文脈に沿った答えを返す。
4. 同じ問い合わせはキャッシュから返して運用費を抑えた。
5. 48人のオペレーターと51日の試験運用で確かめた。

オペレーターが調べる時間は30%減り平均応対時間は10%短くなった。

初回解決率は20%上がった。

営業担当が過去のメールを見ながら一から文章を作っており担当ごとに出来に差があった。

提案の内容を整理するところに時間がかかっていた。

1. 営業担当が顧客の情報と提案内容を箇条書きにする。
2. 箇条書きをChatGPTへ入れて提案メールの下書きを作らせる。
3. 物流会社の営業という立場を与え製造業の顧客へ提案させる。
4. 輸送費の削減効果と導入の利点を400字程度で説明させる。
5. 出てきた文へ自社の商品情報や条件を足し人が最終確認する。

1通あたり30〜40分かかっていたメールが10〜15分程度で仕上がるようになった。

営業担当1人あたり週に約3〜4時間の作業が減った。

同じ作業の繰り返しに社員の時間が取られていた。

顧客へ早く届けることの足かせになっていた。

1. 実際の作業時間を測り工程ごとの費用を出した
2. ルールが決まって量も多いメールとファイル処理を最初に選んだ
3. 13台のロボットを24時間動かす
4. 取り込みと法令に沿った区分けと支払い計算と書類の用意を任せた
5. 不安の声には勉強会で前後の違いを見せて答えた

6年の稼働で26,534時間分の手作業がなくなった。

980,000件を超える運転記録の精算をロボットが処理し、投資は5〜12か月で回収できた。

顧客から届くメールとチャットの記録がたまる一方で中身を調べていなかった。

何を求めているのか不満がどこにあるのかが見えず、遅延や欠航のときも後追いの対応しかできなかった。

1. データ基盤の中に目的別の小さい言語モデルを置いた。
2. たまっていた数百万件の文書をまとめて処理する。
3. ベクトルをベクトルストアに入れ検索とK-means法のまとまりづくりに使う。
4. 会話の内容を取引と運航の記録と突き合わせ1つの画面で見えるようにした。
5. 感情の分析で不満とその強さを拾い先に動く相手を決める。

遅延や欠航が起きたときに影響を受けた顧客ごとの復旧プランを出せるようになった。

売上の大きい顧客から先に対応する形になり、後追いの火消しから先回りの対応へ変わった。

不用品回収の料金は品目や数や場所や搬出のしやすさで変わるため、見積もりのたびに人が中身を確かめる必要があった。

返事が遅くなり件数を増やすには人を増やすしかなかった。

1. 問い合わせの入り口にKustomer Conciergeを置いた。
2. AIが見積もりの担当として顧客と会話する。
3. 品目や場所や搬出の条件など料金に要る情報を会話で集める。
4. 集めた内容に自社の料金のルールを当てて見積もりをその場で出す。
5. 条件から外れる依頼はやり取りと要約を付けて人へ回す。

CSATが約5%上がった。

受信したSMSの問い合わせは100%をAIが最初に受けるようになり、そのうち33%は人を介さず受注まで終わる。

路線と言語と連絡手段が増え、電話やチャットの記録が別々の仕組みに散らばっていた。

担当者は道具を行き来して客の状況をつなぎ合わせる必要があった。

1. 電話やメールやチャットの窓口をZendeskにまとめた
2. 問い合わせの内容ごとに担当部署へ自動で振り分ける
3. チャットにAIエージェントを置き、決まった質問に答えさせた
4. Copilotが出した返答の案を担当者が確かめてから送る
5. 応対の品質チェックもAIに任せ、直すところを拾えるようにした

担当者1人あたりの処理力が60%上がり、1件あたりの費用は40%下がった。

チャットの70%は担当者が入らずに終わり、やり取りの100%をAIが品質の面から見ている。

取引先のチェーンへ送るレポートは数が多いだけで相手が中身を掘れなかった。

何を知りたいのかを毎回こちらで探り当てる手間もかかっていた。

1. 表計算のやり取りをやめて取引先ごとに触れる画面を開いた。
2. 物流と安全書類と販売内訳と苦情と天気を1画面にまとめた。
3. 仕入れの請求書を全件突き合わせて単価の差を1行ずつ見る。
4. 苦情の件数を販売量で割り問題のある地域を探す。
5. 異常のときだけ通知が飛ぶ形にして通知の所だけ動く。

取引先の請求書は全件を突き合わせられるようになり費用の削減につながった。

レポートにかかっていた人手は4〜5人分に相当する分が浮いて契約交渉や物流の設計ができる人を雇えるようになった。

翻訳は別のサイトやアプリを使い関数は毎回ネットで調べていた。

レポートの書き方や返し方の迷いは人に聞くか自分で解決するしかなかった。

1. 海外支店からの英語メールをCopilotへ入れる。
2. 和訳と要約を頼む。
3. Excelはやりたいことを文章で伝え使う関数を聞く。
4. 問い合わせの返し方も質問して案を出させる。
5. 出た提案から選び自分で見直してから使う。

1件あたり15分かかっていた作業が5分になり週1時間が浮いた。

誤字や伝え漏れも減った。

物流の受発注はいまもFAXで届く帳票が多く、担当者が中身を読んで配車管理システムへ手で打ち込んでいた。

荷主ごとに書式がばらばらで、従来のOCRでは読み取り位置を毎回決める手間もかかっていた。

1. 発注帳票の画像をAIデータコンバーターに読み込ませる
2. 積み地や降ろし地の項目をAIが自分で見つけて割り当てる
3. 数量や日程も拾いCSVに整えて出力する
4. 丸印とV印だけの独自表記も日付として扱う
5. 帳票にない情報はマスタや固定値で補い人がCSVを確認する

運送手配マッチングサービスの社内業務で試したところ、1日あたり約75分かかっていた入力が15分で終わり、作業時間が8割減った。

効果が確かめられたため2026年6月から外部への販売を始める。

オンプレで動かしていた他社のSIEMは障害が多くログの保存と検索に手間がかかっていた。

ライセンスと設備の費用も重く4万人の配達員が持つハンディスキャナのデータは量が多すぎて取り込めなかった。

1. クラウド移行の方針に合わせてElastic Securityを選んだ
2. Elasticのサポート担当と組んで既存のSIEMから移行した
3. Elastic Common Schemaで出どころの違うログをそろえる
4. 警報が出たらTimelineに条件をドラッグして関係する出来事を並べる
5. AIと機械学習の機能で決まった処理を自動で回す

前に使っていたオンプレの仕組みに比べて費用は50%下がった。

4万台のエンドポイントと配達員のスキャナのデータも取り込めるようになり見えていなかった部分まで監視できるようになった。

駅は人の流れが読めず地下の構造も複雑で、設備の状態をまとめてつかむのが難しかった。

初期のデジタルツインはデータの質と再現の精度が足りず細かい分析には使えなかった。

1. 駅の建物と設備をAkilaの基盤に3Dで再現した
2. 数千台のカメラとセンサーのデータをMetropolisで取り込む
3. Omniverseで空気の流れや人の動きを計算して改修後の姿を試す
4. 漏水や電気の使いすぎのような異常をAIが早めに知らせる
5. 知らせを受けた担当者がその場で手を打つ

設備が止まる時間と問題への対応時間はどちらも50%減り、電力の消費は20%下がった。

予防のための点検は100%が期限内に終わり、担当者の手間は週2時間減った。

トラックのリースや貸し出しに合う既製のソフトが無く、ソフト開発の80%を自前で作っていた。

業務側から来る求めは増え続け、品質を保ったまま早く出すのが難しかった。

1. 3つの自社開発プロジェクトでGitHub Copilotを試す
2. 進め方の道筋と測る指標を先に決める
3. 社内と海外の開発者へ使い方の研修をした
4. 組織の変え方として現場に利点を伝える
5. 良い反応が出たので開発部門の全体へ広げた

3つのプロジェクトで生産性が10〜12%上がり、予定より早く出せたものもあった。

生成AIの機能が増えてからは若手が一人で進められるようになり、上位の開発者は設計に時間を使えるようになった。

現場の担当者が自分でデータを見られず、簡単な確認でもデータチームへ依頼を出していた。

回答まで数日かかり、聞くのをあきらめる質問も多かった。

1. Looker から ThoughtSpot へ乗り換えた
2. ThoughtSpot を BigQuery のデータへつないだ
3. 現場の担当者が検索窓に普通の言葉で質問する
4. 出た答えから掘り下げる質問をその場で続ける
5. データチームは指標の意味を現場へ説明する役に回った

社内の90%が使うようになり、財務・製品・営業の各チームが自分でデータを見ている。

専任のアナリストは置かずダッシュボードの保守もやめた。

フリート支援チームは他のサポートと手順が違うため、GuruのAI検索に別チームの情報が混ざって出ていた。

答えを探すのに時間がかかり、そもそも調べなくなる人もいた。

1. フリート支援だけを担当するエージェントを1つ作った
2. プロンプトに事業の仕組みを書いて渡した
3. 参照元をフリート関連の内容だけに限る
4. 親しみやすい口調にして対応の仕方も教える役にした
5. Slackに組み込みプロンプトの版を記録して戻せるようにする

標準の手順に当てはまらない変わった質問にも速く正確な答えが返るようになり、時間の節約につながった。

Slackに良い答えが出るのを見てチームの信頼が育ち、エージェントへ聞く人が増えた。

サイトとアプリを自社で作る形に切り替えたが中の状態が見えず、不具合に気づくのは客に影響が出た後だった。

外部のSaaSが多く全体をまとめて見張る手段がなかった。

1. 97項目の要件で試して満たしたDatadogを選んだ
2. APMで主要なサービスを見える形にして目標値と画面を作る
3. RUMで実際の利用者の動きを確かめ公開前にエラーをメールで拾う
4. 予約と搭乗手続きの流れを定期的に試して失敗したら知らせる
5. 障害のときは見立てを添えた調査で原因を切り分ける

原因の切り分けが速くなり、客に影響が出る前に直せるようになった。

いまは社内の100人以上が毎日Datadogを見て主要なサービスの状態を追っている。

車を貸す前の本人確認が手作業で、窓口に長い列ができていた。

確認のやり方もばらつき、書き写しの間違いが起きやすかった。

1. パスポートとEmirates IDと運転免許証を読み込む
2. OCI Document Understandingに記載内容を取り出させる
3. 取り出した内容を突き合わせておかしな点をAIで見つける
4. 既存システムとOracle Integration Cloudでつなぐ
5. アプリをOCI Kubernetes Engineで動かす

お客ごとの書類確認にかかる時間は数分から5秒未満になった。

人を増やさずに窓口でさばける数が増え、確認の正確さも上がった。

実績のデータはSQLサーバーやメインフレームなど社内の古い仕組みに散らばっていた。

レポートの道具は1〜2拠点と1か月分しか扱えず長く動かすと落ちた。

1. Azure上のSnowflakeにデータを集めた
2. 拠点ごとに分かれていた指標を1か所にまとめた
3. Cortex AIを呼び出し現場の実績データをモデルへ渡した
4. モデルに数字の傾向を探させ短い要点で出させた
5. アナリストはTableauで必要なレポートを組み立てる

新しい要約モデルは15日で作れた。

全社5年分のデータを使ったレポートは15分で出せるようになり、管理者は安全や定着につながる要点を受け取れる。