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

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

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

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

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

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

世界の工場に散らばるデータがそのままでは使えず汎用のモデルは製造現場の言葉や作業に合わなかった。

大きなモデルの学習にも時間がかかっていた。

1. LlamaやGemmaなどの公開モデルを自社環境へ取り込んだ
2. 工場のデータを足し視覚と音声と言語をDGX SuperPODで分散学習した
3. NeMoで製造や検査やロボットの作業に追加の学習を重ねた
4. モデルを用途ごとにGenesis PlatformとCityGPTに分けた
5. Mission Controlで資源を見ながら200超の拠点へ配った

120Bのモデルの学習が従来のH100の構成に比べて2.48倍速くなり1兆トークンを12日で処理できた。

生産計画にかける時間は25%減りエンジニアの作業は50%減った。

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

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

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万円の削減と見込んでいる。

分析の道具が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ミリ秒で結果が出るので誰でも数字を取りに行けるようになった。

参加者が増えるたびに7〜10件の細かいタスクを手で作り直していた。

日程や謝礼や遵守事項の管理もいくつもの試験で並行して回す必要があった。

1. 参加者の日程と遵守事項の管理をClickUpのワークスペースにまとめた
2. トリガーを引くとClickUpのAIが必要なタスクをまとめて作る形にした
3. 専用エージェントに追跡日や謝礼や確認の連絡を参加者ごとに引き継がせた
4. 担当を振る前にダッシュボードで仕事量を確認した

参加者ごとの準備を手で組み立てる必要がなくなり、研究そのものに回せる時間が増えた。

無駄な打ち合わせや個別面談も減った。

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

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

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

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

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

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ドルで同じ基盤を使っている。

Atropos Healthは毎月数百件の観察研究を出していて、結果のまとめと背景づけに医師が1件あたり約10分かけていた。

要約を作るLLMのツールは本番で動いていたが、数百件の規模でどれだけうまく書けているのか分からなかった。

1. 研究結果の要約をLLMのツールに下書きさせた
2. 下書きは医師が読んで直す形にした
3. 本番の出力をArize AXへ集めた
4. 何を知りたいかを問いの形で出した
5. 答えられる少数の指標だけで測り始めた

医師ごとの直しを眺めるしかなかった状態から、本番の要約の出来を数百件の規模で見られるようになった。

測る流れが社内で回り出し、絞り込む指標を決める段階へ進んだ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

広く浅く集める従来のやり方では、31言語ぶんの学習データに深さが足りなかった。

言語ごとに誤りの採点の基準もそろわず、改善の度合いを比べられなかった。

1. 31言語ごとに母語話者の専門家が質問と回答を作る
2. 分野をまたぐデータをそろえ話題の変化に備える
3. わざとモデルを詰まらせる入力を書き弱点を洗い出す
4. 出力の誤りをMQMという共通の枠組みで採点する
5. 日本語の敬語の判定など母語話者しかできない作業も任せた

顧客自身の評価でモデルが10〜30%良くなった。

納品物の受け入れ率は97%で、納期は100%守られた。

1.7兆ドルの資産を運用するため毎日大量の調査資料や市場データや規制文書を読み込む必要があった。

投資分析に耐える精度がありながら技術に詳しくない担当者でも扱えるAIが見つからず9,000社分のESG分析も負担になっていた。

1. 複数のLLMを人が採点する形で比べた
2. 拡張思考を使うClaude Sonnet 4.5を選んだ
3. 2週間の試験導入から始め役割ごとの研修を用意した
4. 50人をAIアンバサダーに育て使い方を社内で共有させた
5. 分析担当にClaude Codeを渡し小さな道具を作らせた

社内調査ではAIを使う業務で週の時間の20%以上が浮いた。

2か月で600人以上が日常的に使う状態になり運用や法令対応の部門でも文書作成が自動化された。

AIモデルの評価に使う文章を本物の人が書いたような質のまま大量に集める必要があった。

15言語とアラビア語の複数の方言に対応しつつ個人情報の混入を絶対に避ける条件もあり量と質の両立ができずにいた。

1. AIの下書きを人が直す流れと人だけの流れを用意した
2. 品質が届かないときは人だけの流れへ切り替えた
3. 話題や人物像や口調を回ごとに機械的に振り分けた
4. 複数の段階の検品を通し確認の記録を1件ずつ残した
5. 書き手ごとに廃棄率や質のぶれを数字で追った

15言語で週2万件のデータを届けられるようになり2週間の立ち上げのあと制作の周期が30%短くなった。

個人情報の流出は1件も起きなかった。

似たようなデータモデルが別々に作られ、どれを信じていいか分からない状態だった。

品質の問題の対応にシニアディレクターが毎週最大1日を取られていた。

1. dbt Cloud上でプロジェクトを新しく作り直した
2. 追いかける指標を先に決めテーブルとDAGを組んだ
3. モデルの説明文はdbt Copilotに下書きさせた
4. 人が中身を確かめて整えた
5. 本番リリースを毎週金曜に固定しレビューとテストを通した

プルリクエストのレビューが30分から5分になり、ドキュメントの網羅率99%を保てるようになった。

以前は週に1件以上あったデータの問題も起きなくなり、チームはパイプラインの守りでなく分析そのものに時間を使えている。

音声モデル用のデータを5言語ぶん一気に増やしたかったが、一般のクラウドソーシングでは話者の質や方言がぶれた。

合成音声が学習データに紛れ込む心配もあった。

1. 5言語それぞれでバイリンガルの話者を選んだ
2. 声の質と演じ分けを確かめて話者を決める
3. 言語ごとに使う方言を1つに固定した
4. 自社の音声チェックツールでAIの声や複製された声を外す
5. 人による確認を20%に抑え残りはツールの判定に任せた

5言語で1,000時間を超える音声データがそろい99%が採用された。

合成音声は学習データに入る前に取り除かれ、EC企業はLILTの声のうち6つを製品向けに契約した。

22言語にわたる高度な推論やマルチモーダル理解の評価が必要だった。

不特定多数に振り分ける従来のやり方では深さと安定性が足りなかった。

1. 評価を割り振りでなく設計の仕事として組み立てた
2. 各言語のテストを2,000超のモジュールで用意した
3. 90%を超えた人だけ本番の作業に入れるようにした
4. 基準合わせの会を続けて判断のズレを詰めた
5. 全作業の20〜25%を抜き取って人が確認した

基準合わせ後の一致率は95%になり除外率は3%未満に収まった。

最も難しいマルチモーダル理解の課題では参加した業者の中で1位になった。

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

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

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

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

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

それまでの予測分析ソフトでは必要なアルゴリズムが足りず、規制で求められる管理や書類も用意できなかった。

モデルを一通り作り直すのに4〜5年かかる状態だった。

1. クレジットスコアの予測モデルをDataRobotで作る形に切り替えた
2. 数億件の記録と数千列のデータをそのまま取り込む
3. 欠損や外れ値はDataRobot側で見つけて処理させる
4. 数百のモデルを比べて勝ち残ったものを本番に回す
5. 規制向け書類の半分を自動で作り人が中身を確かめる

信用へのアクセスが8%広がり、新しい融資は数百万ドル規模になった。

1年で18本のモデルを出し、以前なら4〜5年かかる量をこなした。

人を増やさずにAIの成果を広げる必要があった。

データサイエンティストが少なく不正検知のモデルは1本あたり4〜5日かかっていた。

1. DataRobotをAWS経由で入れて1〜2日で動く状態にした
2. AWS Bedrockの基盤モデルと組み合わせて予測と生成を実行する
3. データ分析の経験が無い社員も画面上で学習を試せるようにした
4. 本番に出したあとは精度のずれをDataRobot上で監視する
5. 金融の規制に合わせて偏りを抑える機能も利用した

モデル1本の作成が5日から4時間未満になった。

12時間の集中対応で不正な注文を止めるモデルを仕上げ翌日には本番で悪質な注文だけを遮断した。

新薬を患者へ届けるまでに研究者は生物や化学や画像や臨床の膨大なデータを読み解く必要があった。

拠点も分野も分かれていて、一つの研究で分かったことが別の研究へ回りにくかった。

1. 計算基盤にNVIDIA DGX SuperPODを入れる
2. 用途に合わせて計算資源を研究者へ振り分ける
3. NVIDIA MONAIで臨床試験のCTとMRIを整える
4. CT画像の80%〜90%を隠して復元させ学習する
5. 作ったモデルを公開データで追加学習させる

AIを使った標的探しで研究者の手作業が数週間分減った。

画像モデルは病変やがんの検出で人と同じ精度に届き、筋肉量や脂肪や骨密度まで数値で出せるようになった。

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

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

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コマに選手の半分ほどしか映らないことも多い。

1. 家庭で見るのと同じ中継映像をAIに読ませる
2. 選手とボールと出来事を画像認識で拾い出す
3. 映っていない選手の位置を過去データから推定する
4. 超解像や再識別を生中継のまま動かす
5. イベントと位置と記録を重ねて問いに答える

70を超えるリーグの映像を構造化されたデータに変えられるようになった。

処理は40ミリ秒未満を目標に動き、モデルが一度に読む範囲は約3分から90分以上へ広がった。

IoT機器から毎時150万件を超えるデータが届く一方、古いBIツールでは読み解くのに時間がかかっていた。

少人数のデータチームが都度の集計依頼に追われ、その対応に9万ドル超の費用がかかっていた。

1. BigQueryなどの実データにThoughtSpotを直結する
2. 集計のたびに新しいダッシュボードを作らない形にする
3. 担当者が知りたいことを普段の言葉で打ち込む
4. AIが質問の意図をくみ取って答えを返す
5. 図表はLiveboardで組み立てる

欲しい答えにたどり着くまでの時間が88%短くなり、データを整える時間も75%減った。

年間の対応コストは7万ドル超下がり、ある顧客からの照会は5時間から1.5時間で答えられるようになった。

低軌道の衛星は動きが速く、顧客はひっきりなしに別の衛星へ引き継がれる。

1日700億件にのぼる計測データを抱えながら、通信が途切れる場所を前もってつかむ手立てがなかった。

1. 衛星の計測データをSnowflakeへ集めた
2. SalesforceやSAPのデータも同じ場所に置いた
3. Cortex AIと機械学習で途切れる場所を予測する
4. 予測が出た顧客を早めに別の衛星へ切り替える
5. 問い合わせの文面を感情の分析にかけて不満を拾う

障害を先に見つけて顧客の経路を切り替えられるようになり、通信が止まる時間を抑えられるようになった。

コストは40%下がり演算は20〜100%速くなった。

顧客の情報が社内であちこちに分かれていて、誰が解約しそうか見えなかった。

手を打つ前に契約が切れてしまう状態だった。

1. 顧客の属性と取引の記録を1か所へ集める基盤を作った。
2. 取り込みの流れ11本に300超の品質チェックを通す。
3. SageMakerで2か月以内の解約確率を顧客ごとに出す。
4. 結果をマーケティング担当が読めるレポートにする。
5. 担当者が上位2割から案内を送る相手を決める。

解約予測の精度は90%超になり、契約で決めた基準の4.6倍のリフトが出た。

案内を送ったグループは送らなかったグループより顧客が残った。

AIに作らせたスライドは見た目が自分のいつもの形と違い後から手直ししにくかった。

XML直編集や画像生成やHTML生成も試したが崩れたり自分の手で直せなかった。

1. python-pptxで表や見出しを作る関数群を用意する
2. 色と罫線とフォントと余白を関数の中に固定する
3. スキルに承認済みデザインと書き上書きを禁じる
4. スライド1枚をスクリプト1本にしgitで管理する
5. 値の範囲を外れたらエラーで止める形にする

ふだん手作業で作っていたものとよく似たスライドが自動で出てくるようになり、同僚が手作りと見分けられないほどになった。

出力はPowerPointの部品そのままなので文字の直しや表の組み替えも普段の操作で終わる。

2社の合併でシステムもKPIも2通りに分かれ、数字を見るたびにデータ担当へ頼む状態だった。

データ担当者は個別の集計依頼に追われていた。

1. Domoに全社のデータを集めて1か所で見られるようにした
2. Domo.AIで社内向けのチャットボットを作った
3. 普通の言葉で質問できる形にする
4. AIが元データに触れない作りにして情報を守る
5. よく聞かれる質問を集計し定番の画面を用意する

経理は毎月の請求書を全部見ていたが、想定コストとの差だけを見ればよくなり確認は約10%に減った。

月次決算も月あたり2〜3日ほど短くなった。

研究室の計算資源はワークステーション7台だけで、精度の高いモデルを大きく回せなかった。

そのため狙える創薬のターゲットは年に1つか2つに限られていた。

1. 稼働の前にSlurm用のジョブ設定を書いておく。
2. AIのコーディング支援に実機の設定と突き合わせて確かめさせる。
3. 使えるようになって15分で動作確認を終えた。
4. 760基近いGPUで共折りたたみモデルを動かし化合物を絞り込む。
5. 利用の割り振りはSlurmと11段階の優先度の仕組みで調整する。

1週間で22,000件を超える候補が見つかり、それまでの取り組みを全部合わせた約120件を上回った。

検証で本当に結合すると分かる割合は1〜10%から80〜90%に上がり、1つのプロジェクトでクラウド借用に比べ推定100万ドルを節約した。

顧客・マーケティング・取引のデータが別々の場所に散らばり集計の中身もそろっていなかった。

どの広告が予約につながったのか分からず投資の判断ができなかった。

1. 各ツールのデータをSnowflakeへ自動で取り込む
2. dbtで共通の定義にそろえ検証まで回す
3. 顧客モデルをGoogle AdsやHubSpotへ流す
4. レポートと分析はTableauとHexで見る
5. 客層と接点ごとに予算の配分を組み替える

広告費の配分を見直して前年よりROASが100%以上伸びた。

データ基盤まわりの作業は週およそ200時間分が浮き合併したGetmyboatのデータも6週間でつながった。

ゴリラなど野生の生き物の研究は論文ごとにばらばらで、保護の現場や政策で使える形にまとまらなかった。

人の手で読み解くには時間も専門家の数も足りなかった。

1. 数百本の学術論文と観察の記録を集める。
2. Amazon Bedrockの上に処理の流れを組む。
3. Claude 3.5 Sonnetに論文を読ませて好みを抜き出す。
4. 抜き出した内容を種類ごとに分ける。
5. 保護の専門家が見直して外れたものを落とす。

専門家と同じくらい正確に好みを読み取れて、しかも分析の速さは110倍になった。

ゴリラの顔の見分けは93%の精度になった。

数十テラバイトのデータを学習させる基盤モデルを作るのに、自前の設備では費用が高すぎた。

維持に20人が必要で、GPUの入れ替えや増設も毎年発生する見込みだった。

1. 学習の土台をAmazon SageMakerへ移す。
2. 数十テラバイトの文章と画像を読み込ませる。
3. 学習の途中でパラメータの数を増やせるようにした。
4. 置き場をAmazon FSx for Lustreにして読み書きを速くする。
5. 複数のモデルと後ろの工程を同時に走らせる。

基盤モデルEXAONEのエンジンを1年で作り上げた。

作るための費用は35%下がり、データを整える速さは60%上がった。