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

1,600万人を超える利用者をねらう詐欺が巧妙になり、被害額は2022年にピークを迎えた。

モデルを1つ作るのに数週間かかり、対応が後手に回っていた。

1. AIの基盤を全社に入れた
2. 予測モデルと生成AIを組み合わせた
3. 数千のモデルで取引を即時に判定する
4. ノーコードで分析チーム以外も作れるようにした
5. 書類処理はOCRと自然言語処理を重ねた

不正は30%減り、詐欺による顧客の被害は2022年のピークから76%減った。

モデルの試作は数週間から2日になり、900人を超える分析担当が使えるようになった。

冷却と電力と工程の解析が別々の道具に分かれていて受け渡しに手間がかかっていた。

新しい市場に向けた仕組みを短い期間で形にする必要もあった。

1. OpenUSDで部品ごとに分けた作りにした
2. Omniverseとつなぐ部分の骨組みと最初のテスト用例をAIに作らせた
3. 描画で重い計算をしている箇所を洗い出しGPU側へ移した
4. 顧客の声をすぐ試作に起こして短い周期で確かめた
5. 人がコードの確認と自動テストで品質を保った

最初の打ち合わせから4週間で動く試作ができ6か月で端から端まで通したMVPを出した。

検証済みの部品データから画面を自動で組み立てるので準備は数日から数時間に縮んだ。

3年で10倍に伸びて取引の量が一気に増えた。

監視する道具が分かれていたため障害の原因を突き止めるのに時間がかかり先の読めない状態だった。

1. 指標とトレースとログとコードをDatadogに集めた
2. Bits AIが突き合わせて原因分析と振り返りを自動で作る
3. 出てきた直し方の案から数分で調べる方向を決める
4. セキュリティ障害の報告はBits Chatで作らせる
5. 既知の失敗を自動で回復させる仕組みも入れた

全体のMTTRが11時間から1時間未満になり約90%短くなった。

重大な障害の切り分けは最大80%短縮し稼働は安定して保てるようになった。

送電設備の設計や運用を書いた資料は社外のネットワークへ出せない決まりがある。

共用の計算機は順番待ちになり試したい検証がその都度削られていた。

1. 社内の端末だけで動く文書調査の仕組みを作った
2. 研究者が選んだ技術文書やログをモデルに読み込ませる
3. 中身のgpt-oss-120bを1台の端末の中に収めた
4. 気象予測はGenCastとFourCastNetで動かした
5. CorrDiffで25kmの格子を2〜3kmまで細かくする

50メンバーのアンサンブル予測はCPUだけのサーバーで推定10時間以上だったが150秒で出せるようになった。

文書との対話も1人なら毎秒35トークン、10人同時でも合計毎秒150トークンで返る。

分析はGoogle スプレッドシートとAIで書いたSQLの寄せ集めで、指標の定義が人ごとに違っていた。

会社が伸びて問い合わせが増え、1人のアナリストが作るのを全員が待つ状態になっていた。

1. 社内に散らばる指標の定義と決まりを1か所に集めた
2. 列の名前と意味の対応表を作った
3. テーブルのつなぎ方の指示文をエージェントに読ませた
4. SlackやClaudeから同じデータに質問できるようにした
5. 何度も出る質問を手順として作り足した

Hexで自分でデータを見る社員が全社の5%から75%に増えた。

利用者の44%はSlack経由で使い、エージェントとのやり取りは55,000件を超えた。

経営陣が見る数字も1つのダッシュボードにまとまった。

フランス・ベルギー・ドイツで7つのブランドを持ち、データが2002年のMicrosoft SQL ServerからGoogle BigQueryまでばらばらの基盤に散らばっていた。

売上や顧客といった基本の数字を全社で見ようとするだけで何週間もかかっていた。

1. 古い基盤を直さずSnowflake上に基盤を作り直した
2. 25年分の古いデータベースを6か月で1つに寄せた
3. 全ブランドが同じ数字を見られる状態にした
4. CoCoで作ったAIエージェントをSlackに置いた
5. ハッカソンで約70人に触らせ3案を製品化した

25年分の基盤の統合を6か月で終え、保守に15人分かかっていた体制が2人で回るようになった。

数字が出るまで何日も待っていたのが、ほぼその場で返ってくるようになった。

工場自動化やエネルギーなど部門ごとにデータが分かれていて、客の動きを横からつかめなかった。

表形式のデータをうまく使えないことが最大の悩みだった。

1. Serendieという基盤をSnowflake上に作った
2. 部門にまたがる業務データをつなげた
3. AIの使い道を要約から問題発見へ移した
4. 担当者が表データへ普通の言葉で尋ねる
5. 権限設定で部門をまたいでも安全に見せ合う

約15万人の社員が部門をまたいで客のデータを共有できるようになった。

市場ごとに一人ひとりへ向き合う商売の仕方を進められる土台ができた。

数千万人分のデータを抜き取りではなく全部使ってモデルを学習させたかった。

作ったモデルを実際に動いている仕組みへ載せる手立ても足りなかった。

1. 技術者の訪問なしで直せる不具合を見分けるモデルを作った
2. クラスの偏りを補う設定と間引きで多い側に寄らせない
3. 勾配ブースティング木で24時間先の人気を予測した
4. 利用者を似たまとまりに分けて伸びを出す
5. モデルをJavaに書き出すかウェブサービスとして本番に載せた

機械学習が分析の段階から実際の運用へ移った。

行かなくてよい技術者の訪問が減り、放送の24時間前に人気の出る番組を見通せるようになった。

自力で直す仕組みが問い合わせなしでエラーを解消している。

マネー・ローンダリング対策のデータ検証が表計算のマクロや特定の担当者の腕に頼る形になっていた。

異動や引き継ぎが難しく、現場で見つけた問題をすぐに直せなかった。

1. 研修で資格を取った社員を集めた
2. 半年のハッカソンで実際の業務課題を題材にした
3. 100万件規模のデータ結合をワークフローにした
4. 1か月分の処理を1日単位に分けて自動で回した
5. 現場がワークフローの運用と保守まで担った

4〜5時間かかっていた100万件規模のデータ結合が40〜50秒になった。

処理時間が短くなった分の人件費は年間約250万円の削減と見込んでいる。

AI向けの複雑なチップが増え、設計と製造のシミュレーションに膨大なCPUの計算時間がかかっていた。

マスク1組で3,000万時間以上のCPU計算が必要になることもあり、技術者は結果を待たされていた。

1. マスク合成ソフトのProteusをcuLithoと組み合わせる
2. 並列性の高い計算をCPUからGPUへ移す
3. 計算をNVIDIA B200 GPUの上で動かす
4. CUDA-Xのライブラリで既存のソルバーも速くする
5. 材料探索ではQuantumATKをcuESTで最適化する

露光計算のシミュレーションはCPUのモデルに比べて最大20倍速くなる見込みになった。

Applied Materialsの初期の結果では量子化学の計算が30倍速くなる可能性が出て、Northrop Grumman Microelectronics Centerでは開発が数週間から数時間に縮んだ。

繁忙期は10を超える市場で大量のキャンペーンを同時に動かし、数字をExcelにまとめてグラフや資料を作るのに何時間も何日もかかっていた。

配信前の変数やフッターや言語の確認も1件あたり1時間かかり、作業が詰まっていた。

1. 社内で使っていたClaudeからBrazeのMCPサーバーにつなぐ
2. APIの識別子でキャンペーンとCanvasのデータを呼び出す
3. 市場をまたいだ成績を集めてレポートまで作る
4. 毎週のメール到達の要約をSlackへ流す
5. 配信前のリンクを貼って変数や言語の間違いを一覧で返す

成績レポートを作る時間は2日から20分になり、99%減った。

配信前のキャンペーン確認は1件1時間から5分になり、人の目が見落としがちな細部も拾えるようになった。

分析の道具がMatomo・Adobe Analytics・Google Analyticsの3つに分かれ数字を見比べられなかった。

長年つぎ足してきた設定が複雑で中身を読み解きにくかった。

1. 導入支援の会社と組み3つの分析ツールをAmplitude一本へ寄せた
2. 2,000以上のイベントを意味のまとまりでまとめ直した
3. 細かい違いはプロパティへ移した
4. プロダクトオーナーと開発者が最初からイベント設計に入った
5. ダッシュボードはAIに2〜3回指示して作り担当者が直す

ダッシュボードを作る時間が1時間から5分になり90%以上短くなった。

10以上のアプリとサイトをつなぎ移行は2か月で終わった。

社内のデータが別々の置き場に散らばり集計しにくかった。

担当者が1人しかおらず手術で抜けた間に作られたダッシュボードは中身の正しさも見られる範囲も管理できていなかった。

1. Salesforceのデータから大事なテーブルだけに絞った
2. 要る列だけを残し列ごとに平易な説明を書き足した
3. テーブルをワークブックにまとめMCPサーバー経由でClaudeにつないだ
4. 聞き方の型とデータのつながりを書いた専用skillを全員に入れた
5. 研修を開き相談用のSlackチャンネルも用意した

始めてから営業や事業側からの問い合わせが250%伸びた。

99.9%が答えを返し中央値63ミリ秒で結果が出るので誰でも数字を取りに行けるようになった。

込み入ったセキュリティの問いに答えるには長い問い合わせを何本も書いて一つずつ確かめる必要があった。

経営陣も誰かがダッシュボードや資料を用意するまで数字を待つしかなかった。

1. データレイクと分析をSnowflakeに寄せる
2. ベテランの技術者がCoCoに普通の言葉で問いを投げた
3. 複数システムの数字の突き合わせをCortex Agentsに任せる
4. 合わないところは指示を書き直して追い込んだ
5. 経営陣にCoWorkを配り自分でデータに聞ける形にする

1〜2週間かかっていたセキュリティの分析が数日で終わるようになった。

経営陣が自分でデータに問いを立てられるようになった。

研修の進行管理がExcelとMicrosoft ProjectとGoogle ドキュメントとNotepadに散っていた。

毎週月曜に1時間かけて日付と進捗を計画と突き合わせ、その後に催促の連絡を送っていた。

1. 4つのツールの中身をClickUpのワークスペース1つに移した
2. 設計は考えるモデルで進め作る段でモデルを切り替え数百件のタスクをまとめて直した
3. 終了予定日を開始予定日の21日後に保つ決まりを入れた
4. 期日が近いのに進捗が目標を割ったらAt Riskの印を付けて担当者に知らせた
5. 誤検知が出たAt Riskのしきい値だけ人が調整した

直近30日で人の作業16日分が減り、責任者は月曜を待たずにダッシュボードでその日の状況を見られるようになった。

数百件の一括更新も1日の午後で終わった。

ログと指標と通知が4つの別々の仕組みに散らばり、障害のたびに画面を行き来して原因をたどる必要があった。

監視の仕組み自体が監視対象と同じ基盤の上で動いていたため、障害が起きると状況が見えなくなる弱点もあった。

1. 4つに分かれていた監視をObserve by Snowflakeへ寄せた。
2. Kubernetesの各クラスタにエージェントを入れた。
3. 米国とEUで別テナントを用意し設定はTerraformで管理する。
4. 集めたテレメトリーを社内のAIエージェントにつないだ。
5. エンジニアはSlackで疑問を投げて答えを受け取る。

障害対応にかかる時間の中央値が約80%短くなった。

年10万ドル超のAWSの費用も要らなくなり、障害時に状況が見えなくなる弱点も消えた。

顧客企業はアプリごとに認証や権限の管理ツールへ手作業で登録する必要があり、見落としが生まれていた。

調べた環境では30%から60%超の識別情報が本来の管理の外に置かれていた。

1. 遠隔ログインができるアプリを自動で洗い出した。
2. アカウントと認証の流れと権限をまとめて集めた。
3. 集めたデータをSnowflakeへ取り込みdbtで整えた。
4. Dynamic Tablesで30分ごとに最新へ入れ替える。
5. 分析はデータにつないだLLMに任せ調査を自動で進めさせた。

1つのアプリの脆弱性を調べる時間が約4時間から42分になった。

分析は80%速くなり、100万を超える利用者の識別情報を扱えるようになった。

ブラジルで1億人を超える顧客を抱え大型の広告や協賛を続けているが、SNSの反応には料金や故障の不満が多く混ざる。

従来の反応数や engagement の数字では、伝えたい内容が本当に届いたのか分からなかった。

1. Social Listeningでキャンペーンの投稿を集めた
2. AIで独自の指標を作り広告への反応と問い合わせを切り分けた
3. Comment Adherence Rateで適合するコメントの割合を出した
4. 評価の良し悪しを自動で判定し悪い評判の芽を早めに見つけた
5. 大きな催しではリアルタイムの画面を見て出演者や投稿の形を入れ替えた

A Vida Convida のキャンペーンでは Comment Adherence Rate が91.9%になり、これまでの平均の約35%を大きく上回った。

同じ企画の動画シリーズは好意的な評価が97%に達し、第2シーズンを作る判断につながった。

顧客が求めるレポートが細かくなるほど、ダッシュボードの設定と検証に何時間もかかっていた。

数千万行の取引データを数百の列で扱うため、手作業の組み立てと確認が重かった。

1. Workbooks as Codeでワークブックをコードとして読み書きする
2. 画面で一つずつ設定する作り方をやめた
3. レポートの構想やモックをAIに渡し下書きを作らせる
4. できた下書きを見ながら手を入れて仕上げる
5. 空いた時間は要件の詰めと使いやすさの確認に回した

最初の下書きが約4時間から10〜15分でできるようになり、約94%の短縮になった。

その後の作り直しも速くなった。

買い手がChatGPTやGeminiに「控除管理のソフトはどれがよいか」と聞いて候補を絞るようになり、そこで名前が挙がらないと商談にすら近づけなくなった。

Semrushでは検索順位は見えても、答えを返すAIの中で自社がどう扱われているかは分からなかった。

1. HubSpotのAEOを入れて質問ごとの表示有無を並べて見る
2. 出てこない質問のまとまりを担当者が見比べる
3. 価値の高いものから記事の題材を割り振る
4. 競合の回答で引かれている出どころも題材に足す
5. Breeze Assistantに言葉で伝えレポートを作らせる

書く題材を勘で決めるのをやめ、検索のされ方で裏が取れたものから順に手を付けられるようになった。

レポートも軸や集計の設定を組む作業が無くなり、指示文を1つ渡すだけで済むようになった。

BIツールで自社のAIモデルを見張っていたため、精度の崩れに気づくまで1〜2日かかっていた。

重い計算がBIサーバーの半分以上を占め、担当チームは新しいモデルを作る時間を取れず、不調を業務部門に先に見つけられることもあった。

1. 監視の仕組みを作るか買うかを比べて選んだ
2. PythonのSDKでモデルを出す側のAPIにつないだ
3. しきい値を自分で決めた自動の見張りを置いた
4. 学習時と検証時と本番の数字を並べて比べた
5. 守るべき属性で結果が偏っていないか確認した

投資の回収は2か月未満で、初年度のROIは500%超と見ている。

社内で監視の仕組みを作らずに済んだぶん初年度で2〜3人分の工数が浮き、年あたり数百時間のチーム時間も空いた。

生物医学やロボットや言語の研究で必要な学習の規模が、一つの研究室で持てる計算機の限界を超えていた。

公開クラウドで足すと費用がかかりすぎて、何度も条件を変えて試す進め方が成り立たなかった。

1. 12の学部が共用で使えるAI基盤をDGX SuperPODの上に作った
2. 計算ノードをInfiniBandでつなぎ学外と学内を光ファイバーで直結した
3. 保管はVAST Dataにして読み出し250GB/s超でGPUへ送る
4. 運用はNVIDIA Mission Controlでまとめて見る形にした
5. 従来型の計算はSlurm・AI向けはRun:aiへ振り分けた

ロボットの研究では3B超のパラメータの視覚言語行動モデルを学習できるようになり、前の環境より12倍速くなった。

承認済みの利用が始まるまでの待ちは数週間から数時間になり、4万件を超える文書を学部横断で解析する仕事は1.5年分の計算が3日で終わった。

1日の実験の本数は14倍に増え、200の研究グループの950人が1GPU時間あたり約1ドルで同じ基盤を使っている。

店舗や銀行・携帯の事業まで抱える広いシステムから1日60〜80TBのログが出ていて、本当に危ない兆候を見つけられなかった。

過去の攻撃の記録も無く、手がかりになる正解データが足りなかった。

1. Azure上のDatabricksで1日80TBを取り込む仕組みを作った
2. ふだんの振る舞いから外れた動きを見つける形にした
3. エージェントの判定を別のLLMが採点して確かめる
4. 新しいログを足す手順を自動の手順書にまとめた
5. 分析担当はGenieに英語で質問して説明を受け取る

1日50TBを超えるログが、対応すべき異常5件未満まで絞られるようになった。

調査にかかる時間も短くなり、仕組みは本番で動いている。

病原菌と植物のタンパク質の組み合わせは数え切れないほど多く、どれが実際にぶつかり合うのかを追い切れなかった。

質量分析のデータも増え続けて、クラスタリングと分子ネットワークづくりが詰まっていた。

1. 病原菌のタンパク質の配列から感染に関わる特徴を持つものに絞る
2. 絞った組み合わせをBioNeMo Boltz-2 NIMへ渡す
3. 構造と結合の強さを予測させて相互作用の地図を作る
4. 予測はH200のGPUで回して他のモデルと精度を比べた
5. 質量分析データのクラスタリングをRAPIDS cuMLで行った

BioNeMo Boltz-2 NIMはオープンソースのモデルより4.15倍速く、数年かかっていた相互作用の地図づくりが数週間で終わるようになった。

質量分析のクラスタリングは80〜100倍まで速くなり、解析を流す頻度が四半期ごとから毎月に増えた。

13か国にまたがる提案書づくりとキャンペーンの報告に手間がかかっていた。

金額を扱う作業では間違いも起きていた。

1. BigQueryとGemini Enterpriseを組み合わせた。
2. 113個を超えるAIエージェントを自社で作った。
3. 用途ごとにエージェントを分ける。
4. 提案書づくり・報告・金額の処理を別々に担当させた。
5. 各チームは合うエージェントを呼び出して進める。

提案書を作る速さが5倍になり、キャンペーンの報告にかかる時間は80%減った。

金額の間違いの割合も0.01%未満になった。

AIサーバーのラック1台は数千点の部品でできていて、炭素量を出すには材料のレベルまで5〜6層たどる必要があった。

1万件超の排出係数から最も近い1件を選ぶ作業は1製品あたり150時間を超え、算定全体の90%超を占めていた。

1. AIと人で分担する算定の流れを作った
2. 多階層の部品表を物質のレベルまでAIにたどらせる
3. 1行ごとに分類させて材料の申告内容を整えさせた
4. 部品の種類に合う計算方法を当てはめて排出係数を割り当てる
5. 結果と例外は担当者が確認して品質を保つ

排出係数の割り当てにかかる時間は手作業に比べて90%超減り、1製品3,000点超の部品を数秒で処理できるようになった。

半年で数十製品分の算定に広がり、約25,000点の部品を扱った。

分析で見つけた相手を広告の配信先へ回す作業が手作業のままだった。

表を書き出して並べ直し部署をまたいで調整する間に配信が遅れた。

1. Fivetranで170超のシステムからBigQueryへデータを集める
2. 計測モデルと独自の項目を当てて用語をそろえる
3. そろえたデータをAgent Calが読む文脈の層へ流す
4. マーケターが普段の言葉で聞いてリストを作る
5. リストをActivationsでLinkedInやGoogle Adsへ送る

ターゲットを配信に回す速さが2倍になり、4時間かかっていたキャンペーン用のリストが25分未満で作れるようになった。

自前で作らずに済んだ分で年間40万ドル相当のエンジニアの手が空き、ロードマップは最大12か月分前倒しできた。

製品ごとの炭素排出量を出すには、何万行もの部品表を人が1件ずつ調べる必要があった。

仕入れ先の資料は形式がばらばらで抜けも多く、評価が終わる頃には製品が発売済みということも起きていた。

1. 部品表やPDF・CAD図面・仕入れ先のメールを取り込んだ
2. 製品と供給網をつないだ炭素のグラフに作り直す
3. 部品表の各行を約100種類の分類へ振り分けた
4. 1万件を超える排出係数から近いものを選ぶ
5. 3つの処理をNVIDIA Nemotron 3 Ultraへ載せ替えた

仕入れ先データの読み取りは84.0%から87.7%へ、部品の分類は80.0%から83.5%へ上がった。

コストは0.20倍と0.49倍になり応答の速さも前のモデルと同じか速くなった。

返済の連絡の時期や伝え方を一人ずつ変える機械学習モデルを増やしたかったが、少人数の体制では信頼性を保てなかった。

データがサービスごとに分かれ、作り方も人によってばらばらだった。

1. データの加工からモデルの実行までをSnowflakeの中に集めた
2. コードはPythonで1か所にまとめた
3. モデルごとにフォルダを作り設定ファイルに処理の流れと時間を書く
4. よく使う特徴量をFeature Storeに一度だけ定義する
5. 本番へ出せるのは自動のパイプラインだけにした

新しいモデルの立ち上げは数週間かかっていたが数日で本番に届くようになった。

10を超えるモデルが毎日動き、全米の数百万人に向けた提案を出している。

広く送るメールは地域やサービス別に分けるだけで、相手ごとの中身になっていなかった。

誰がいつ反応しやすいかも分からず送る時間はばらばらだった。

1. Oracle Marketingを入れキャンペーンの計画を1か所にまとめた
2. AIに行動と反応の傾向を読ませ送信時刻を決める
3. 送りすぎている相手はfatigue分析で見つけ対象から外す
4. アカウント情報から反応の見込みと関心を点数にした
5. 地域で切る分け方から関心で切る分け方へ変えた

メールの開封率とクリック率が上がった。

宛先を手で用意する作業が減り、その分を別の仕事に回せるようになった。

財務と人事のシステムが別々で、増え続けるデータをその場で分析できなかった。

報告のたびに集計と突き合わせを手でやっていた。

1. 財務や人事の処理をOracle Fusion Cloudにまとめた
2. そこへFusion Agentic Applicationsを重ねた
3. データはOCI上のAutonomous AI Lakehouseに集約する
4. 他のクラウドのデータもつなぎほぼリアルタイムに複製する
5. 売上や在庫や原価はAnalytics Cloudで見る

手作業の報告と突き合わせが30%減り、数日かかっていた分析が数秒で出るようになった。

700%を超える成長の間も管理を保ち、5,000人を超えるピーク時の採用と入社手続きをさばけるようになった。

社員が知りたいことを聞くたびに専用のダッシュボードを作る必要があった。

技術の分からない人はデータへ自分でたどり着けなかった。

1. Claudeを複数の専門エージェントの司令塔に据えた
2. 社員の質問からClaudeが動かすエージェントを決める
3. 計算と商品マスタと地域マスタを別々のエージェントに任せた
4. Claudeが各エージェントの結果をまとめ答えと図にする
5. 利用者の権限を確かめながら社内データ基盤へ問い合わせる

会話で聞ける分析の正答率が90%から99%へ上がった。

社内のAI基盤は1日15,000人・月44,000人が使い月250万件のメッセージが行き来している。

食事・運動・睡眠・活動量のデータが別々の仕組みに散らばっていた。

利用者はフィルターや一覧画面から自分で探すしかなく、トレーナーも手作業の分析に時間を取られていた。

1. 整理した健康データをベクトルデータベースへ入れる
2. 意味の近さでデータを探せる状態にする
3. 利用者が普通の言葉で聞いた内容をQuery Agentが受け取る
4. 必要なデータを選んで取り出し読みやすい返事にまとめる
5. 決めた基準を超えたときに助言が自動で出るようにした

利用者は従来の画面よりも会話で3倍多くやり取りするようになった。

トレーナーの分析時間は60%減り、指導そのものに時間を回せるようになった。

規制の厳しい金融の現場で、複数の言語の文章を正しく素早く作る必要があった。

外部の代理店に頼る部分も大きく、費用がかさんでいた。

1. 複数のAIを試して比べClaude for Workを選んだ
2. 12月から4月まで段階を分けて広げる
3. 研修は管理職から先に受けてもらう
4. マーケは各言語の文章作成と翻訳に使う
5. アナリストはSQL作成と決まったデータ処理を自動化する

一部の使い方で生産性が100%上がり、分析チームは週70時間を浮かせた。

投資は3か月かからずに回収できた。

顧客ごとにデータを別のクラウド環境で持つ決まりにしていた。

取り込みのたびにエンジニアが専用のスクリプトを書く必要があり手間が大きかった。

1. 顧客ごとにDatabricksのワークスペースを用意する
2. Fivetranの接続とdbtのプロジェクトも顧客ごとに作る
3. 決められた担当者だけが触れるようにする
4. クリックや閲覧のデータを取り込みdbtのSQLで変換を定義する
5. 整えたデータを機械学習へ流し広告費の配分を予測する

1件のデータ連携は100〜150時間から10時間になり、夜通しで最大20時間かかっていた処理も4〜5時間で終わるようになった。

切り分けにかかる時間は全体の50%から20%未満へ下がり、受けられる顧客は30%増えた。

Shopifyで売上データを深く見るにはShopifyQLを覚える必要があった。

店を始めたばかりの人ほどそこで止まり数字をもとにした判断へ進めなかった。

1. 商売の相談役になるSidekickをClaudeで組み立てる
2. 管理画面から話しかけられるようにする
3. 話し言葉の質問をShopifyQLのクエリへ置き換える
4. 1回のやりとりで複数のツールを順番にも並列にも呼び出す
5. Claude Sonnet 4.5をGoogle Cloud上で動かす

以前は技術の知識が要った分析が会話だけでできるようになった。

新しく始めた事業者が最初の売上に届くまでが数週間から数日へ縮まった。

たまったデータから答えを出すにはSQLの知識と手間が要った。

依頼がデータ部門に積み上がり現場は分析結果を何日も待たされていた。

1. 複数のモデルを比べてClaudeを選ぶ
2. ClaudeをCortex Analystに組み込んだ
3. 普通の言葉の質問をClaudeがSQLに書き換える
4. Claudeをセキュリティ境界の中で動かした
5. SQLやPythonやREST APIから呼び出す

社内の基準で測ると複雑なtext-to-SQLで90%を超える精度が出た。

10,000社を超える企業が自然言語でデータを引けるようになった。

ほぼ1日おきに新機能を出す開発の速さが持ち味だが コードとテストの往復や障害時の情報集めに手間がかかっていた。

1. Claude Codeをターミナルから呼び出しテストとつないだ
2. コード作成とテスト修正の繰り返しを自動で回す
3. コードベース全体の説明書きも自動で作らせた
4. 1つのコードベースで複数セッションを同時に走らせる
5. DatadogやSentryとつなぎ障害の情報を集めた

30日で100万行を超えるAI提案のコードを取り込み 開発者のおよそ50%が毎週使うようになった。

障害の初動調査にかかる時間は最大80%減ると見込まれている。

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

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

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

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

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

何百ものモデルを別々の仕組みで動かしていて、部門ごとの分断が進み無駄なコストがかかっていた。

新しいモデルを一つ出すまでに3週間かかっていた。

1. 古いAIの仕組みをDataRobotへ寄せた
2. 予測のAIと生成AIを一つの基盤でまとめて扱う
3. 用意されたアルゴリズムから候補を選び精度を比べる
4. APIでAWS BedrockのTitanやClaude 3とつないだ
5. 説明が付く形のモデルにして委員会が可否を判断する

新しいモデルを出すまでの期間が3週間から平均21時間になり、開発の時間は82%減った。

計算の力は8〜10倍になり、多くのモデルで80%を超える精度が出せるようになった。