データ分析・ExcelのAI活用事例

コード量を54%減らせるとうたうプラグインの数字が、自分の環境でも同じように出るか分からなかった。

モデルごとの向き不向きも判断できなかった。

1. Express製55行のTODO APIに日本語4行のチケットを7本用意する
2. headlessのclaude -pにチケットを渡し実行する
3. --plugin-dirで足す条件と足さない条件を作る
4. Haiku・Sonnet・Opusの3モデルで合計42セルを回す
5. 差分を同じprettier設定で整形し直してから数え直す

削減率は9〜25%にとどまり、54%は再現しなかった。

コストが下がったのはOpusだけで、Haikuは1件テストを落とした。

自社ECと楽天やAmazonなど複数モールから届く問い合わせが多く、対応に時間の大半を取られていた。

品質向上やVOCの取り組みが後回しになり、CSチームの成長が止まりかけていた。

1. 問い合わせデータの分類を生成AIに任せた
2. タグ付けの条件を後から変えられるようにした
3. 全テキスト対応をAIが評価する仕組みを作った
4. 良い点と直す点を翌日までにメンバーへ返した
5. 人は分析とフィードバックに回した

手作業のタグ付けがなくなりオペレーターの負担が軽くなった。

月に1〜2回、数件だけだった品質チェックは毎日全ての対応を翌日までに評価できるようになり、3ヶ月後や半年後を見据えた計画を立てる余裕が生まれた。

配送状況や輸入可否、通関ルールなど一件ごとに事情が違う問い合わせが多く、決まった回答しか返せない従来のボットと社内の商品データを別々に更新する手間がかかっていた。

マニュアルは複雑で目的の記述にたどり着きにくく、担当者が自作した手順書に頼る属人化も進んでいた。

1. 管理者と現場担当5名ほどで2か月のトライアルを行った
2. 仮のデータを入れて応答の出方を確かめた
3. マニュアルやルールをナレッジとして登録した
4. 過去のエスカレーション事例をQ&Aの形に直して入れた
5. テンプレートや文例を100件以上集め精査して一部を登録した

チーム約20名が利用し、分散していたマニュアルやルールが集約されて調べる場所が定まり、判断のスピードが上がった。

頻発していたエスカレーションの一部は担当者が自分で解決できるようになり、回答への不安も和らいだ。

4年前に自分で作った日報の仕組みは数量や時間の欄は問題なかったが、自由記述の表記ゆれや誤字で過去の記録が検索に引っかからなかった。

トラブルの処置や次の直への申し送りといった大事な情報が、残っているのに使えない状態になっていた。

1. 日報のテキストをClaudeのAPIに渡し決めた形に構造化させる
2. 表記ゆれの名寄せと日付や単位の統一をさせる
3. 記入漏れや矛盾は品質の指摘として出させる
4. 未記入は計算で埋めずnullにするよう指示文で禁じる
5. 整えたデータを複数日まとめて渡し繰り返しやずれを探させる

OCRの崩れや全角半角の混在を含む架空の日報14枚で試したところ、外径が一方向に増えているのに公差の記載がない点や、トラブル欄に記載があるのに時間が0.0hになっている矛盾を出せた。

申し送りの懸念が扱われず同じ損失が再び起きていることも見つかり、費用は1枚の正規化が約10円、14枚の横断分析が約30円だった。

ユーザーが疑問を持ったときはガイドを自分で探すか問い合わせフォームで連絡するしかなく、利用者が増えるほど解決までに時間がかかっていた。

有人対応では夜間に答えられない問題もあった。

1. Web版とスマホアプリ版にAIチャットボットを入れた
2. よくある疑問へ自動で答える形にした
3. 週一度の新機能公開に合わせQ&Aを足し直す運用を続けた
4. 出品に関する質問だけを取り出して調べ回答を厚くした
5. トレンドアラートで急増をつかみ同日に回答を作って共有した

導入から2年でチャットボットの利用者数が12倍になり、ほぼ二人に一人のユーザーの疑問を解決できるようになった。

人では難しい24時間の対応がかなった。

スキャンした領収書のフォルダをそのままChatGPTに渡してチェックリストを作らせたところ、紙で受け取った領収書のスキャン画像まで電子取引データとして扱われていた。

フォルダに入っているものはすべて対象という前提でAIが判断していた。

1. ファイル名の先頭に電子か紙かの区分を手作業で書き込む
2. ChatGPTに電子_のファイルだけでチェックリストを作らせる
3. 出てきたリストの件数をフォルダ側の件数と照らす
4. タイムスタンプの付与期限など日付は自分で数え直す

区分を先に決めてから任せる順番に変えたことで、対象外の書類が紛れることはなくなった。

今回は38件が電子取引のデータ、残る12件は紙をスキャンしたもので対象外という分かれ方だった。

月次の報告でこの話を共有し、上司から制度対応の精度を評価された。

面接官3人が別々に付けたスコアをChatGPTにまとめさせたところ、合計点の順位が自分の感覚とずれ、一番良かったはずの候補者が2位になっていた。

点数の付け方が厳しい面接官と甘い面接官の差が、そのまま平均されていた。

1. 過去の選考記録から面接官ごとの平均点を算出する
2. 依頼文の冒頭にA3.1点B4.2点C3.6点と書き添える
3. 各面接官の平均からの離れ具合を先に計算させる
4. 偏差値に直して3人の評価を比べるよう指示を固定する
5. 出力された順位を元の単純合計と自分の目で照合する

基準となる平均を先に伝える流れにしてから、厳しさの違いを無視して足し合わせる間違いは起きなくなった。

偏差値に直すと候補者1人の位置が単純合計のときと入れ替わり、採点者ごとの偏りを会議の前に言葉で示せるようになったと人事部長から評価された。

モデル比較の記事は順位表の引き写しばかりで、自分の業務の文書を実際に通した記録が見当たらなかった。

出たばかりのモデルはとくに実例が乏しく、どちらを毎週の文書作成に使えばよいか判断できなかった。

1. 毎週作っている週報の起草を試験の題材にした
2. 記事別viewsや検索順位を含む1,341字の生データを入力にした
3. 本文500〜700字など5つの要件を決めた
4. 要件を機械で検査し数値照合とセクション数え上げを自動化した
5. 2モデルを各2回走らせコストを2層で並べた

4走とも生データにない数値は0件だったが、字数は768字から796字まで全走で上限を超えた。

実経路のコストはGemini直接APIが1走$0.0059〜$0.0088、CLI経由のSolが$0.036で、Geminiは503が続き3回目で成功した走もあった。

週報はGeminiの直接APIで回し、字数チェックと作り直しを工程に入れることにした。

アプリを作るには開発環境の用意やサンプルデータの準備が必要で、興味はあっても試すところまで進みにくかった。

1. 業務で使うSharePointリストのサイトを開く
2. 列構成とデータを分析しダッシュボードを作るよう文章で指示した
3. HTMLファイルをSharePointに保存しリンクを返すまで指示に含めた
4. 出来上がった画面をプレビューで開き動作を確かめた
5. チャットで追加のグラフや配置の修正を頼んだ

指示から1分ほどでHTMLのダッシュボードが出来上がり、件数や対応状況のカードと一覧表、絞り込みが使える形になった。

キーワード検索はファイルビューアー上で文字入力がうまくいかず、動作の確認は人がやる必要があった。

AI検索で自社サービスが紹介されているかを調べるため、複数の生成AIに担当者が手でプロンプトを打ち込み、回答をスプレッドシートにまとめていた。

工数が重いうえ、担当者ごとに回答が寄ってしまい客観的な数字が取りにくかった。

1. フロント向け2サービスの商材カテゴリーを軸にプロンプトを20個用意する
2. LLMリサーチでサービス名の出現割合とURL引用割合の2指標を測る
3. API経由で定期的に計測しレポートをワンクリックで出す
4. リスティング広告のデータを見て検索意図に近い言い回しへ直す
5. 人は数字を読んで次の打ち手を決める部分に回る

特定のプロンプトでのブランド露出率が導入前の水準と比べて130％になり、全リードに占めるAI起点リードの含有率は半年間で30％増えた。

集計の手間が減り、分析や打ち手を考える時間を増やせた。

ファンからの問い合わせ窓口がチャネルごとにばらばらで、応対の質にもムラがあった。

数字が手元に届くまでに12〜24時間以上かかることもあり、担当者は状況が見えないまま対応していた。

1. 電話とチャットとビデオの窓口をZoom CXに寄せた
2. 問い合わせを内容に合う担当者へ自動で振り分ける
3. 応対中にナレッジ記事をその場で出す形にした
4. 会話の熱量や感情のスコアで確認する通話を絞り込む
5. 見えた得意と弱点をもとに指導内容を決めた

管理者1人あたり1シフトで約2時間が浮き、確認できる通話は50%増えた。

振り分けと応答が速くなり、ファンの満足度も上向いた。

経営判断の前に財務やマーケの数字を手作業で集める必要があり、集計に時間を取られていた。

複数のAIを動かすと誤った数字が報告に混ざる心配もあった。

1. Claude Codeを核に9体の役をMarkdownのfrontmatterで定義した
2. CFOは会計API、CTOはリポジトリとCIと一次データの担当を分けた
3. CEOは各役の報告を統合するだけにして数字の創作を防いだ
4. 連携はinbox・today・archiveの3つのYAMLで秘書役が管理した
5. 月次決算の手順はSKILL.mdにまとめコマンドで呼び出せるようにした

CEO役が常にダッシュボードを更新するようになり、経営者の時間を集計から判断へ移せた。

ただし運用期間は短く、安定稼働と言えるかは今後の実績待ちだと本人は述べている。

口座数の増加で電話がつながりにくくなる場面があり、Webでの自己解決を促す取り組みを進めていた。

ただ担当の人数が少なく、目に見える課題への後追い対応で手一杯だった。

1. Webサイトの行動データをAIアシスタントに読ませる
2. 問い合わせが増えているページと回遊のしかたを見つけさせる
3. 購入手順で迷う仮説と打ち手の案までAIに作らせる
4. 案をほぼそのまま使いQ&A形式のサポートを設計して公開した
5. 担当チームへの聞き取りと内容のすり合わせに時間を使う

公開から約1週間で7件の問い合わせ削減を確認し、年間換算で約400件の削減が見込める結果になった。

取り組みを立てるまでの工数は2〜3営業日から1営業日に縮まった。

GA4や定型レポートでページビューなどの個別の数値は見えても、訪問者がどこから来てどのページを通り次に何をしたかという流れがつかめなかった。

そのためサイトの直し方が感覚頼りになっていた。

1. サイト分析にデタクルを導入する
2. GA4からBigQueryへ出したデータを期間やページで絞って取り出す
3. 取り出したデータを生成AIが読める形に整えて渡す
4. 流入元や経由ページ、端末別の行動差の切り口で結果を出す
5. 結果を対話で掘り下げて改善案にまとめる

集計値だけでは気づけなかった行動が見えるようになり、サイト改善の新しい仮説が出せるようになった。

レポートを報告して終わりでなく、データを根拠にボタンの大きさなど具体的な直し方をその場で話し合えるようになった。

出店する場所を決めるには商圏人口や競合店、道路や駐車場の条件など見るべき要素が多く、担当者の経験や外部の調査に頼る部分が大きかった。

建築費や土地代が上がる中で、投資の判断を外すリスクも増していた。

1. 自社POSデータで既存店を分析する
2. 商圏データと競合店データを重ねる
3. 人口・世帯データを加えて売上予測モデルを作る
4. 地図上で候補地を指し売上見込みを出す
5. 条件を変えた影響を比べ現地確認と合わせて判断する

2024年秋からの試験運用を経て本格運用に入り、検証した対象では予測誤差率が中央値で7%台まで下がった。

出店判断の客観性と再現性が上がり、担当者と経営層が同じ前提で議論しやすくなった。

Webからの申し込みごとに権限付与や案内メール送信を人が手で処理していた。

研修後のアンケートも回ごとの集計だけで、トレーナー個人の傾向や時間による変化を追えなかった。

1. Google WorkspaceとGeminiをつなぎ業務の流れを作り直した
2. 申込受付から権限付与と案内メール送信までを自動処理にした
3. アンケート集計を自動化し個人別や回数別のダッシュボードにまとめた
4. 人が目的を決めAIが処理し人が結果を見る流れで回している
5. うまく動かない工程は作り直し外部向けプログラムの原型にした

申込処理の手作業は100%なくなり、累計150件で合計37.5時間（1件あたり15分）分の作業が消えた。

Web診断の自動化では月100件稼働時に約50時間の削減を見込む。

リサーチや資料作成、データ加工など小さな手作業が全社に散らばり、個別のシステム化がしにくかった。

AIを入れても使い方が個人任せだと、成果が人ごとの慣れに左右されてしまう。

1. 社員と業務委託の計59名に実行環境をそろえてClaude Codeを配る
2. 2026年7月から8月に全部門向け研修を行う
3. うまくいったやり方をスキルという手順書にして共有基盤へ登録する
4. 配色や書体やロゴの規定をAIが読める形に直す
5. 登録されたスキルをレビューして部門をまたいで共有する

2026年8月末までに45名の手で、手順書が743件、業務ごとのAIエージェントが127体たまった。

研修後の社内調査では、エンジニア以外の回答者のうち53％が毎日のように使っており、その中の69％が同じ成果物を作る時間は半分以下になったと答えた。

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

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

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

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

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

AI関連の商材を扱う会社でありながら、社内での使用実績が乏しく提案の裏付けに欠けていた。

資料作成や数値のまとめ、書類のつき合わせに人手と時間がかかっていた。

1. 全社員にClaude Enterpriseの利用環境を用意した
2. 管理部門が資料作成と数値集計を任せた
3. 規程と書類のつき合わせをAIに任せた
4. 営業部門が提案資料の書式そろえと文章の練り直しに使った
5. 出力は人が中身を確かめる運用をルールにした

回答者の7割がほぼ毎日使い、管理部門では一人あたり1日約1.5時間、月約30時間を減らした。

書類を横断して確かめる作業では90%を超える削減率の例も出て、2026年7月時点で単月18%の作業時間削減を確かめた。

顧客の氏名や年収など個人情報を日々扱うため、どこまでAIに入力してよいか判断がつかず社内での利用が広がらなかった。

社内に複数のAIツールが混在し、ルールも定まっていなかった。

1. 企業向けのGemini Enterpriseに利用環境をまとめる
2. 権限管理と入力してよい情報の基準を社内規程で決める
3. 週1回の勉強会を全8回開き基礎からGASまで扱う
4. 非エンジニア社員が自部署の作業でアプリを作る
5. 前後で同じ設問の社内アンケートを取り変化を確かめる

AIを定常業務のプロセスに組み込む社員は57.8%から82.3%になり、API連携や定型処理の自動化を自分で実装した社員も21.2%まで増えた。

開発事業部では物件データの集計が約2時間から15分に短くなった。

SEOの提案では競合サイトや流入キーワード、検索ボリュームを調べて提案の材料にまとめるまでに時間がかかっていた。

受注前の商談では、調べる深さと手間のつり合いが取れなかった。

1. Ahrefs連携の対話型AIに競合サイトとキーワードを指定して調査を指示する
2. やり取りの中で数値を呼び出し競合と自社サイトの流入キーワード差を確かめる
3. 検索ボリュームや競合性と事業との関わりから優先キーワードを絞る
4. 事業領域全体の検索需要を見て市場規模をつかむ
5. 用途ごとの基本の指示文を社内で共有し出力のばらつきを抑える

商談の前でも競合と検索市場を調べて仮説を用意できるようになり、その結果は受注後の案件にも引き継がれた。

1人が担当できる案件数が増え、経験の浅いメンバーでも一定水準の分析ができるようになって上長のレビュー回数も減った。

生成AIに悩みを相談してZaPASSを知ったという顧客が増えていた。

だがGA4の流入データや担当者の手作業の検索では、どんな質問でどう紹介され競合とどう比べられているのかまでつかめなかった。

1. 狙いたい顧客像と検討の流れに沿ったプロンプトを設計する
2. 主なプロンプトごとにメンション率や引用状況と競合との差を計測する
3. AIが返す回答文を読んで紹介のされ方を確かめる
4. 改善レポートを基に記事のリライトやalt属性の修正を人が進める
5. AI検索に出ていないテーマは新しい記事を作り一次情報を発信する

AI検索での見え方が数値と回答文の両方でつかめるようになり、既存のSEO記事約100本のリライトなど次に直す場所が決まった。

今後はメンション率と回答内容の変わり方を追っていく。

支援先の訪問診療クリニックは17店舗あり、録音はあっても全部の応対を聞いて集計するのは難しかった。

月ごとに数店舗へ絞って見ていたため、グループ全体の品質までは手が回らなかった。

1. MiiTel Phoneで通話を録音し音声データをためる。
2. MiiTel Synapseへ渡すプロンプトを先に作り込んだ。
3. 確認が必要な応対だけを自動で拾い表の形で書き出す。
4. 出てきた表をもとに社内へ報告した。
5. 各クリニックへ直し方を伝えている。

応対を確認して集計する手間が10分の1になった。

人が聞ける範囲に頼らず、改善が要る事案を拾えるようになった。

NASDAQへ上場してSOXの対象になり、経理の処理に厳しい統制が求められた。

残高の照合はExcelで回しており拠点ごとに3〜4日かかっていた。

1. 人事と経理をWorkdayへ集約しデータと監査の記録をそろえた
2. 残高の照合をWorksheetsとLive Reportsでの突き合わせに置き換える
3. Workday Contract Intelligenceを契約書の確認に入れた
4. 契約書を社内ルールと突き合わせ注意が要る箇所に印を付けさせる
5. 汎用のAIエージェントにレポートと請求書の添付を見比べさせた

Excelでやっていた残高照合は元データを直せばレポートを更新するだけで終わるようになった。

AIエージェントは経理が手でやっていた請求書の突き合わせを自分で画面を動かしてこなした。

設計図面から構造物の名称や寸法を目で読み取り手計算でまとめる数量拾いは5〜6人のベテランに集中し、1案件あたり2〜15時間かかっていた。

図面を読む暗黙知が文書化しづらく、若手が入り込めないうえ見積書の提出が遅れて受注を逃すこともあった。

1. AIコンサル会社と組み現場の進め方を聞き取り専用アプリを共同で作った
2. 設計図面のPDFを読み込ませ構造物と寸法と数量を拾い出させた
3. 車止め8個などの一覧表をExcelで書き出した
4. 抽出箇所を図面上に色付けして表示し確認を早めた
5. AIの出力は下書きとし最後は技術者が目で確かめた

数量拾いは最大12時間から約10分になり、見積もり全体の工数も最大15時間から約4時間に減った。

専門知識のない社員でも一覧表を作れるようになり、ベテラン任せだった業務を若手や未経験者にも広げられた。

市販後の医薬品の安全性情報を管理する仕事で、学術論文から医薬品名や有害事象名を抜き出す作業をすべて人がやっていた。

担当者によって作業の速さや査読の結果に差が出ることが困りごとだった。

1. AWS LambdaとDynamoDBでサーバーレスAPI基盤ANKOUを作った
2. 学習の場にAmazon SageMakerを選び機械学習を載せた
3. 文献検索と医薬用語検索の推測変換をさせている
4. 論文から医薬品名と有害事象名の記載箇所の抽出を機械に任せた
5. 因果関係や重さの判断は人が確かめる形にした

サーバー費用はEC2と比べて約1/10まで下がり、運用保守の費用も約1/3になる見込みになった。

インフラを用意するまでの時間も1週間程度からゼロに縮まり、担当者が改善に時間を回せるようになった。

プルリクエストのレビューに開発者の時間が取られていた。

小規模なデータ分析に合うサービスも無く、汎用のAIアプリでは機能が足りず特化型は高価だった。

1. OSSのPR-AgentにBedrock経由のClaudeをつなぐ
2. プルリクエストの一次レビューをAIに任せる
3. 狙った出力が出るまでプロンプトを調整しGitHub Wikiで管理する
4. Amazon BedrockとAWS Lambdaでサーバーレスの簡易基盤を組む
5. 参照データとシステムプロンプトを先に渡し要約や検索に使う

Xのフォロワー分析の案件で工数を50％程度削減した。

10分ほどかかっていたプルリクエストのタイトルと説明文の作成が瞬時に終わるようになり、レビューの精度も上がった。

養鶏は人手不足が進み、ブロイラーの体重や状態を人が測って記録する負担が大きかった。

環境データだけでは生育の結果と結びつけた分析ができなかった。

1. 鶏舎の天井にWebカメラを付け約50日間撮り続ける
2. 撮った画像を解析し1羽あたりの体重を推定する
3. 推定体重をクラウドアプリに自動で記録する
4. 死鳥数と温湿度や飲水量を合わせてグラフとレポートを自動で作る
5. 推論モデルはGPU搭載のAmazon EC2 G4で作った

導入した生産者が推定体重と実際の出荷体重を比べたところ、計測誤差は3%以下だった。

デプロイの自動化とあわせ、2週間ごとに新機能を出せる体制になった。

将来数千万から数億台規模のカメラ映像をすべてクラウドで処理するのは難しく、通信とクラウドの負荷が膨らむ懸念があった。

少人数の組織で早く軽く立ち上げられる基盤も必要だった。

1. 画像認識IoTサービスの土台にAWSのクラウドを選んだ
2. IPカメラ側に画像処理機能を載せ認識結果だけをクラウドへ送った
3. エッジの土台にAWS IoT Greengrassを使い機能を入れ替え可能にした
4. 外部開発者向けにAPIを公開しSDKも配った
5. エッジ最適化のAmazon SageMaker Neoの組み込みを検証中

映像そのものを送らないため負荷が抑えられ、個人情報がクラウドに残らない形になった。

トライアルカンパニーのスマートストアでは対応カメラ100台が人の動きをとらえ、消費行動の分析に使われている。

生活消費の分野では食品の廃棄ロスやCO2排出、人手不足といった課題が重なっていた。

グループ各社のデータは会計中心にとどまり、バリューチェーン全体で使える形になっていなかった。

1. AWS上にグループ横断のデータ基盤を作る
2. 各社データと外部データをS3のデータレイクにためる
3. Glue・Athena・EMRで並列処理し分析用に加工する
4. 加工データから機械学習モデルを作り定型処理に載せる
5. 食品サプライチェーンの発注量計算を自動で出す

発注業務の工数が50%減り、在庫は10～30%減った。

インフラをそろえるまでの待ち時間もおよそ10分の1になった。

発電所のデータ連係の仕組みはメーカーが構内に置くもので、保守やデータの扱いがメーカー主導になっていた。

設備の不具合は警報が鳴ってからの対応になり、計画外の停止を避けにくかった。

1. 各発電所の生データをAWSのIoT基盤へ送る
2. プラントごとのサイトにデータを振り分ける
3. 機械学習の予測値と実測値の差で異常の兆しを知らせる
4. ボイラーやタービンの効率を測り原因と対処案を示す
5. 過去の運転データから最適な操作パラメータを出す

予兆検知の仕組みで計画外停止時間を20％以上減らした。

性能管理と運転最適化で効率が上がり、対象ユニットで年間1億円以上の燃料費を減らせた。

営業や設計といった業務ごとにシステムが分かれ、建設プロジェクトのデータが業務単位で閉じていた。

施工管理の人員予測も支店ごとにExcelで行われ、基準がそろっていなかった。

1. 全社データを集める基盤をAWS上に構築した
2. S3やRDS、AWS Glueでデータを集めて貯めた
3. 過去の施工実績を教師データにSageMakerで予測モデルを作った
4. 工事概要を入れると必要人員が出る形にしBIで可視化した
5. 基盤同士のつなぎ込みとセキュリティ対策を作り込んだ

2021年11月に運用を始め、2022年11月までに約25のアプリケーションを出した。

人員予測は統一した基準で算出できるようになり、2023年度中に百以上のアプリケーション開発を目指す。

金属の破断面を顕微鏡で見て壊れた原因を見分けるには高い専門性が要り、それができる人が足りなくなっていた。

熟練者の判断のしかたを残す方法も課題だった。

1. 会員から集めた破断面の画像を用意する
2. オンプレミスのGPU環境で学習済みモデルを作る
3. モデルをAWSに置きSageMakerで推論だけ動かす
4. AWS WAFと負荷分散で公開時の安全と処理量に備える
5. 最終的な原因判断は会員側の担当者が行う

自前の環境では1分程度かかっていた推論が30秒程度で返るようになった。

企業十数社や公共団体、大学を含む20以上の会員が推論サービスを使っている。

車両開発で集まるデータの分析はデータサイエンスチームに頼るしかなく、事業部門が自分で調べられなかった。

オンプレミスではデータ量やリソースの制限もあり、開発が進めにくかった。

1. 開発用のデータとツールを一画面で使えるAWS統合環境を作った
2. 車両データの取得から可視化までをマイクロサービスに分けた
3. その構成をテンプレート化して別の実験にも使えるようにした
4. 話し言葉で分析を頼めるAIデータアシスタントをAPIで作った
5. Q&AボットのRAG精度を自動採点し専門家が評価リストを整える

事業部門が行う探索的データ分析は従来比で3〜5倍速くなり、PoC期間は約80％短縮できた。

RAG評価の時間とコストは手動と比べ90％減り、判定は専門家と90％以上一致した。

国内のモバイル広告枠は1億以上あり、どの枠にいくらで出すかを人の経験や勘で調整するのは限界だった。

最適化ツールを使っても人手に頼る部分が多く、規模の小さい広告主ほど負担が重かった。

1. アプリ事業者向けの全自動入札プラットフォームを作った
2. 広告枠ごとの入札価格の予測と広告選択を機械学習に任せた
3. リアルタイム入札の中核はメモリ上で動かし速度を確保した
4. 大量のログをAmazon S3にためて分析基盤とつないだ
5. EC2は処理の性質に合わせて種類を選び分けた

国内の全トラフィックを対象に秒間20万〜30万、月間3,000億〜4,000億のインプレッションを処理し、25万QPS/秒の処理ができるようになった。

3名で始めた小さな組織でも予算の範囲内で運用が続いている。

扱う電子書籍が60万冊以上あり、ジャンルや読者層ごとのタグ付けを手作業で続けるのが難しくなっていた。

分析に使う道具が担当者任せで、同じ対象を調べても結果が食い違い、共同作業もノウハウの再利用もできなかった。

1. 書誌情報やメタ情報からタグ付けする分析基盤をSageMakerに一本化した
2. 自社のAWS環境内に安全な練習場所を用意した
3. デジタルマーケティング部のほぼ全員が半日のハンズオンに参加した
4. RedshiftやS3からデータを取り加工と学習を同じ場所で進めた
5. 分析結果をBIツールで図にして指摘をもとに分類を人が直した

工程ごとに別の道具へ渡す手間がなくなり、ある担当者が作ったノートブックのモデルに別の担当者が自分の環境から入って一緒に作業できるようになった。

各自が分析環境を用意する必要も消え、既存のJupyter Notebook向けライブラリを引き継げたことで初期費用も抑えられた。

保険の提案は担当者のカンや経験に頼る部分が大きく、営業の生産性が上がらなかった。

代理店ごとに顧客データを生かしきれていなかった。

1. 契約内容や事故情報、家族構成の変化などのデータをAWS上の分析基盤に集めた
2. 大規模分析基盤と汎用分析基盤の2つで機械学習を回した
3. 顧客ニーズの変化を予測させた
4. 業務システム画面にAIロボットを常駐させ行動や情報をプッシュ通知した
5. AIの保険プランは動画で説明し最終提案は担当者が判断した

2020年2月の稼働から1年弱の2020年11月末時点で利用率は約70%になった。

開発期間は1年半で済み、すべて自社設備で作った場合に見込まれた3年の半分に収まった。

運転支援向けの画像認識モデルを社内のGPUクラスタで開発しており、認識対象が増えるほどエンジニア同士でGPUの取り合いになる恐れがあった。

サーバーやファイルシステムの面倒も自分たちで見ており、モデル作りに時間を割けなかった。

1. 次世代の学習基盤としてAmazon SageMakerを選んだ
2. コスト比較と3日間の集中討議と約2ヶ月の検証を行った
3. 学習データをS3にまとめ必要分をFSx for Lustreへ移した
4. 前処理から学習と評価までStep Functionsでつないだ
5. 学習の記録をパイプラインで取得しDocumentDBに残した

データエンジニアのデータ管理の手間は従来比55%まで、MLエンジニアの繰り返し作業は66%まで減った。

学習ジョブを並列にしたことで、3日かかっていた学習が3時間で終わるようになった。

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

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

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

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

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

業務用の冷蔵冷凍庫の故障は顧客からの連絡で知ることがほとんどで、夏に依頼が集中して作業員の確保が難しかった。

大型設備では被害額が1,000万円に達することもあり、早い対応が求められていた。

1. 顧客先の設備にセンサーを付け冷媒圧力と温度を一定間隔で取り込む
2. AWS IoT Coreを入口にS3へデータをためる
3. ためたデータをAmazon SageMakerに学習させ故障の予兆をつかむ
4. 異常検知時は作業者のスマホに通知し準備してから現場へ向かう
5. 故障箇所の候補を3程度まで絞ることを目標にする

現地に行かないと分からなかった設備の状況をリアルタイムで見られるようになり、故障前の修理対応ができるようになった。

1990年代に数百万円かけた遠隔監視システムの置き換えでは10分の1以下のコストになり、学習期間も通常約2ヶ月のところ2週間程度で済んだ。