研究・データ分析の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で回し、字数チェックと作り直しを工程に入れることにした。

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

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

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

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

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

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

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

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

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

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

ESG評価に必要な非財務情報は企業ごとに様式の違うPDFに散らばっており、抽出作業に時間と手間がかかっていた。

社内チャットだけでは検索の質と効率に限界が残った。

1. 環境分野で対話する約70社の統合報告書3年分を対象に決める
2. 独自の評価観点から検索キーワードを決めてベクトル検索をかける
3. Claude 3 Opusが検索結果から関係する記述を選び要約を作る
4. 要約をファイルに出し社内チャットのカスタム機能から呼び出せるようにする
5. 要約にPDFの該当箇所へのリンクを付け元文書で確かめられるようにする

統合報告書の分析業務は3〜5倍に効率化され、現場の作業時間は従来の3分の1程度に短縮された。

キーワード検索では見落としがちな記述も意味で拾えるようになった。

生活消費の分野では食品の廃棄ロスや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億円以上の燃料費を減らせた。

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

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

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％以上一致した。

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

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

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

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

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

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

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

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

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

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

研究データや分析レポートが担当者のPCやオンプレミスサーバー、クラウドストレージに分かれて置かれ、組織で使いにくくなっていた。

長期の研究テーマの技術の引き継ぎや、人に付いたデータの持ち腐れが課題だった。

1. 研究本部に生成AIのナレッジ管理の仕組みSTiVを導入した
2. 保管先が分かれたままでも材料名やキーワードで横断検索できるようにした
3. SharePointとつなぎ既存のアクセス権限をそのまま引き継いだ
4. 検索する人の権限に応じた範囲だけを表示する形にした
5. 新人や中途社員は過去の履歴を自分で調べてから相談する流れにした

20年を超える研究・分析データを横断して探せるようになり、これまで1〜2時間かかっていた資料探しが数分になった。

5〜10年続く研究の引き継ぎや新しいテーマの立ち上げも速くなった。

第III相の試験は医薬品開発で最も金と手間がかかる段階で1回あたり1,900万ドル〜1億ドル超の負担になる。

パートナー企業や実施施設をまたぐ運営が複雑で進みが遅れやすかった。

1. 外部の支援先と組んで試験の進め方そのものを見直した
2. AIの分析結果と業務データを1つの画面にまとめた
3. 主要な指標と次にやることを追跡できる形で出す
4. 過去に分かったことも同じ場所へ貯めて共有する
5. 優先度の高い試験チームから使い始めた

優先度の高い30を超える試験チームで使われるようになった。

3か月でユニークユーザーは100名未満から900名近くまで増え全社の公式な基盤になった。

研究開発の現場では英語の読み書きに手間取り作業が遅れていた。

上司がドイツにいて研究方針の意図が正しく伝わらない心配もあった。

1. ブラウザ拡張を入れ選んだ文をショートカットで訳す
2. Wikiに日本語で書き相手には相手の設定言語で表示させる
3. 論文はまず日本語で下書きしてから英語に訳す
4. 訳した英文をDeepL Write Proにかけ直し方の候補を得る
5. 対応する箇所を画面で確かめながら意図通りに手を入れる

人手の有料校正が1ページあたり2〜3箇所を直すのに対し5〜6倍の修正提案が出た。

言語をまたいだやり取りが速く正確になった。

古代ギリシャ語の資料は人が書き写して読み解くしかなく傷んだ断片は手つかずのままだった。

読まれていないパピルスが世界中にたまりオーストリア国立図書館だけでも数万点を抱えていた。

1. Mistralと組み古代ギリシャ語向けのLLMを作った。
2. ギリシャ語文献6億語と碑文やパピルスで学習させた。
3. 欠けのある碑文や文書を渡して候補を出させた。
4. 意味のつながりをたどり関連する記述を探した。
5. 欧州内の基盤で動かし研究者が結果を確かめた。

以前は数年かかった解読と修復が数時間でできるようになった。

研究者は復元そのものより解釈と分析に時間を回せるようになった。

組織が大きくなるほど部門ごとに情報が分かれ、価値のある記録が大量の文書の中に埋もれてしまう恐れがあった。

時差をまたぐ開発では過去の対応履歴を探すだけで時間がかかっていた。

1. 全チームの作業をNotionのワークスペースに集める
2. 研究チームはチームスペースに実験の記録と進み具合を書く
3. GitHubやLinearとつなぎSlackやGoogle Driveとも連携する
4. 週次レポートのデータベースに使用状況と週ごとの指標を集める
5. 分からないことはNotion AIに尋ね過去の技術記録から背景ごと引き出す

以前は何時間もかかっていたデバッグがNotion AIに聞くだけで数分で終わるようになった。

週次レポートの準備は毎週1時間以上減り、重要な数字が関係者へすぐ届くようになった。

投資チームは案件ごとに数百ページのデューデリジェンス資料や財務報告や法務書類を読む必要があった。

社内の文書があちこちのシステムに散らばり、必要な情報を素早く取り出せなかった。

1. 外部の開発会社と組み社内向けの生成AI基盤を作った
2. 複数のモデルから選べる作りにした
3. フランス語の文書と要約はMistralのモデルに任せた
4. 利用者は文書を手で上げて自然な言葉で質問する
5. Web検索とチームで共有できる固定フォルダを付けた

1年で本番稼働に入り投資の現場で欠かせない道具になった。

週に500人超が使い、これまでに18,000件超の文書を処理して280,000件超の依頼が出された。

防衛の現場で扱うデータが増え、外部の供給に左右されずに自前で動かせる多言語LLMが要るようになった。

ただし大規模なMoEの学習を実際に回した経験が社内に無かった。

1. Forgeを使い多言語のMoEモデルをゼロから学習させた
2. 外部経由で集めた言語データを学習に入れた
3. 両社の技術者が同じ開発環境に入り試しては直した
4. MoEの組み方は提供元の技術者から直接教わった
5. 出来たモデルは自組織のサーバーだけで動かした

出来上がったモデルは東南アジアの言語の評価で同じ規模の中では高い成績を出し、想定していた業務の水準を満たした。

自分たちだけで学習を回せる力も社内に残り、次は現場の機器で動く小型モデルの開発に進んだ。

食品の製造で出る産業廃棄物や植物から抗老化の成分を探す共同研究で、対象となる部位や項目が幅広く、候補となる素材も多かった。

膨大な論文を人手で調べて仮説を立てるのに手間がかかっていた。

1. 福岡県の補助金を使い3カ月間KIBIT Amanogawaを試した
2. PubMedの3,500万報超の論文から関連の強い情報を拾い出した
3. 物質側と抗老化の狙い側の両方から探索を進めた
4. 最終目標を複数決め提示内容を研究者が確かめて候補を絞った

それぞれの目標に対応する候補物質を得られ、この結果が評価されて本格導入に進んだ。

今後は候補物質の精査と実証試験を進める。

要求分析や要件定義は専門知識と項目間のつじつま合わせが必要で負担が重く、担える人が限られていた。

汎用のAIも入力文しだいで出来が変わり、良し悪しを判断できる人が少なく使える場面が狭かった。

1. 研究開発部が上流工程AIエージェントを試験導入した
2. 指示文を書かず手元の資料を読み込ませる
3. 社内のひな形と作成ルールに沿った要求定義書の下書きが出る
4. 足りない情報をAIが補い目次間の整合をとって生成する
5. 下書きを担当者が確認しやり方をひな形に反映する

要求定義書づくりで大きく手間が減ることを試験導入で確かめ、本格的に使う流れになった。

今後は要件定義など他の領域にも広げる。

工程の変更が日常的に起きる建設現場では搬送ロボットの計画を人手で直す必要があり、待機時間が増えていた。

その制御の構想を発明としてどうまとめ、既存の施工支援技術との違いを示すかが決まらなかった。

1. 工程表や作業フロー、資材配置の資料をAIに読み込ませる
2. 課題と解決手段と技術的効果の三つの観点で発明要素を並べ直す
3. 建設ロボットや施工管理分野の先行技術を参照して検討する
4. AIが発明提案書の形にまとめる
5. 担当者が出願を見据えた技術の表現に整える

日次で最適な搬送計画を自動で作る方式という発明の中身が体系的にまとまった。

特許検討の初期工程の作業時間は最大約70%減った（社内検証）。

情報を盗むマルウェアXLoaderは何重にも暗号化されていて、解析は人の手作業に頼るしかなかった。

バイナリの解凍や関数の追跡に数日かかっていた。

1. IDA Proから逆アセンブル結果や関数と文字列を書き出した
2. 書き出した内容をChatGPT（GPT-5）へ渡した
3. 暗号の方式とデータ構造を見分けさせスクリプトを作らせた
4. MCPでAIをデバッガにつなぎ鍵や復号後のデータを取り出した
5. 出た結果はアナリストが確かめ通信先などを読み解いた

数日かかっていたリバースエンジニアリングが数時間で終わるようになった。

100以上の関数を復号し、隠されていた64個のC2ドメインも見つけた。

Microsoft Copilotは入っていたが数万字の文書を扱う研究開発の要求に届かず、機密情報の扱いにも不安があった。

課題の見つけ方やプロンプトの作り方が社内に無く、広げ方が分からなかった。

1. 複数のLLMを安全に使える環境を選び社内データをRAGでつないだ
2. 3つの業務領域でチームを作り若手と中堅が困りごとを洗い出した
3. 提供元の伴走支援と定例会で課題特定からプロンプト作成まで進めた
4. 特許明細書は要点を入力し様式に沿った草案を出させ人が確かめた
5. 企画会議では各自がその場で第0案を作り議論を深めた

草案作成は従来数時間かかっていたものが最短5分になった。

個別のプロセスでは体感60%以上の時間削減、個人の生産性は平均20%向上し、利用者の約8割が業務の質が上がったと答えた。

毎週月曜の朝に経営会議で使う定例レポートを作っていた。

週明けの忙しい時間に手作業が重なり負担が大きかった。

1. BigQueryから必要な数字を集計する。
2. 集計した結果をGeminiへ渡す。
3. 視聴の傾向と過去の実績を比べた要約とコメントを書かせる。
4. 社員が押さえる見方をプロンプトへ落とし込んだ。
5. 出てきたレポートを経営層がそのまま読める形にそろえた。

担当者の手間が減り、レポートの中身も人によるばらつきが無くなった。

経験のある社員だけが書けていた気の利いたコメントもAIが出せるようになった。

言葉と画像でロボットへ指示する仕組みはプログラミングが要らない点で期待を集めた。

一方でAIに全部任せる形は信頼性と導入の重さが壁になっていた。

1. 仕組みを作業認識・身体認識・環境認識の3つに分けた
2. その3か所だけを目的を絞った生成AIに担わせた
3. 残りの処理は従来の制御に任せた
4. ロボットにピックアンドプレイスの動きを作らせた
5. 10種類以上のワークで精度と速さを測った

10種類以上のワークで精度と速度の両方が実用水準を満たすと確認できた。

モデルをChatGPT-5へ替えると処理速度と安定性がさらに上がる傾向も出た。

複数の事業部門を横断で支える数理技術研究所に、データやAIの使い方についての相談が次々と寄せられていた。

製品開発や生産の流れを効率よくする手立ても求められていた。

1. 2018年導入の統合分析基盤とAzure OpenAIを組み合わせた
2. 事業部門が日々使うExcelのチェックリストを題材にした
3. AIに項目ごとの情報を補わせ確認の手間を減らした
4. 導入から技術移転まで外部企業が伴走した
5. 社内で回せる状態を目指しリファレンスモデルを開発した

チェック業務の効率が大きく上がり、アンケートでは事業部門の社員の79％がAIを使った効果を感じたと答えた。

数理技術研究所はこの例を成功モデルとして他の事業部門にも広げる。

UFCは年40回を超える大会に向けて選手や試合のデータを人手で調べていた。

担当者の経験に頼るやり方は時間がかかり出せる分析の数も限られていた。

1. IBMと組みUFC Insights Engineという基盤を作った
2. watsonx Orchestrateを窓口にし普段の言葉で質問できるようにした
3. 質問の中身でtext-to-SQLとRAGの処理へ振り分けた
4. RAGはGraniteやLlamaで試合統計や経歴から答えを作った
5. 回答に説明と品質スコアを付け人が確かめて材料に仕上げた

インサイトを出すまでの時間が推定で40%減った。

出せるインサイトの数はほぼ3倍になった。

製剤研究で積み上げてきた過去のデータが十分に使われず、経験の浅い研究者が相談できる相手も限られていた。

一般的なRAGアプリでは欲しい情報にたどり着けない課題もあった。

1. Azure OpenAI Serviceで社内研究データのRAGアプリを作った
2. 質問の意図を読み解き検索と回答づくりまで行うAIエージェントを組んだ
3. 研究データを守るためAI基盤を閉域網で構築した
4. 実務担当者に聞き取りし目指す状態のずれを埋めて実運用まで進めた

製剤研究部門全体での利用は月間100回に達し、使った研究者からの評価も高い。

今後は報告書づくりの支援やデータ分析への広がりが見込まれている。

海外の最新技術をつかむうえでドイツ語の論文が読みづらく、新しい分野の論文を1本読むだけでも時間と手間がかかっていた。

外部に翻訳を頼むと費用が高く、社内の承認申請と待ち時間も負担になっていた。

1. 英語論文で使っていた1paperにドイツ語対応を相談して導入した
2. 論文PDFをブラウザにドラッグ&ドロップし翻訳開始を押す
3. 日本語訳をWord形式で受け取る
4. スキャン画像や手書き紙面もそのまま読み取らせる
5. 出力Wordにメモを書き込み注釈欄で原文表現を確かめる

段落ごとに翻訳ツールへ貼り付ける作業がなくなり、アップロードだけで訳文が手に入るようになった。

外部発注の承認待ちも不要になり、社外からドイツ語資料を渡された場面でもその場で内容をつかめるようになった。

遺伝子解析が進んで研究データが膨らみ、ファイルサーバーの管理を任せていた外部の担当者が辞めて契約も続かなくなった。

調べ物や資料探しにも時間がかかっていた。

1. Google Workspaceへ移行した
2. 数TBの動画や解析データをドライブにまとめた
3. Gemini for Google Workspaceを導入した
4. アプリ版でなくサイドパネルから呼ぶ形にした
5. 論文を書きながら関連資料を探させた

調べ物や情報探しにかかる時間が大きく減った。

サイドパネルから使えるようになって作業の進み方もよくなった。

生成AIを安全に使える社内の環境が無かった。

VBAのプログラムは担当者しか直せず属人化していた。

1. 法人向けのChatSenseを全社に入れた
2. 研究開発でレシピの案出しと評価結果の分析に使っている
3. プレゼン資料のたたき台作りにも回した
4. 中身が分からないVBAのコードを読ませ直し方を出させた
5. 社内データを学習させるRAGを支援を受けて進めている

1時間かかっていたVBAの修正が3分で終わるようになった。

研究開発から資料作りまで幅広い業務で使われるようになった。

社外の道路会社や研究機関との会議が頻繁にあり、そのまとめ作業に長い時間を取られていた。

人数の多い会では録音を聴き直しても発言者を特定できず、何度も巻き戻していた。

1. Zoomで録音した音声をRimo Voiceに上げる
2. 上げると同時に話者分離をかける
3. 専門用語を辞書に登録して精度を保つ
4. チームフォルダで共有し各自が同時編集で直す
5. 体裁を整えてWordなどにまとめクライアントへ渡す

議事録づくりの時間が平均で約3分の1以下になった。

要点だけで足りる会議では10分の1や20分の1まで縮んだケースもあり、誰の発言か分からなくなることもなくなった。

顧客先に常駐してデータ分析を担う会社なので時間あたりの成果を上げたかった。

ただ生成AIを使える社員は一部にとどまり全社で使える状態になっていなかった。

1. 有志の社員7名でプロジェクトを組んだ
2. 入門マニュアルと事例集を作り社内に公開する
3. Gemini専用の相談チャットを開いた
4. 誰がどんな業務で使っているかを一覧にして共有する
5. 勉強会を定期的に開き全社総会で動かして見せた

2024年2月時点で164名中147名が業務で生成AIを使うようになり活用率は89.6%になった。

使い道はコード生成75件が最も多く、情報収集66件・アイディア出し29件・文章作成22件が続いた。

分析を自社設置のデータベースで動かしていて、データが増えるたびにディスクを足す必要があった。

大きな履歴データでの学習は遅く、案件が終わるまで数か月かかっていた。

1. 基盤をSnowflakeへ移した
2. Document AIとCortex Analystを経てCoCoを入れた
3. やりたいことを言葉でCoCoに伝えて作り方を組み立てた
4. 財務はStreamlitの画面で毎日のシナリオ試算を回す
5. 営業には夜のうちにAIがまとめた気づきをCRMへ届ける

数か月かかっていた分析が数週間で出せるようになった。

財務や営業やカスタマーサービスの担当者は、データ部門を通さず自分でデータに触れるようになった。

需要計画の担当者が過去の実績だけで統計予測を作り、その後は自分の経験で手直ししていた。

市場ごとにやり方がばらばらで精度も低かった。

1. 需要計画のアプリを大きい3市場から入れた。
2. 対象は450以上のSKUでワクチン売上の約50%を占める。
3. 社内データレイクの情報と外部データをつないだ。
4. SKUと市場と販売チャネルの単位で予測を出す形にした。
5. 最初の6か月でこの設定を終わらせた。

ベースラインの統計予測に比べて予測精度が20%上がった。

数十人の専門家が手で調整した予測より4%高く、3市場で年間$20 millionの在庫削減につながる見込みになった。

チームごとにデータの持ち方がばらばらで、会社全体の様子をそろって見ることが難しかった。

数十億件のイベントから生まれる大量のデータを扱う基盤も足りなかった。

1. 製品のログや財務のデータをSnowflakeへ集めた
2. dbtで整形してLookerでダッシュボードにする
3. Cortex AIで技術者以外も自然言語で尋ねられる
4. 重要なデータは毎朝9時までにそろう運用にした
5. AI機能の使われ方を同じ基盤で追い製品チームと直す

社員の7割以上がSnowflake上で作ったデータの仕組みを使うようになった。

2ペタバイトのデータを処理しながら社内向けに最大99%の稼働を保っている。

従来は作り置きのレポートやダッシュボードに頼っていて、想定外の問いにはExcelでの集計や分析担当の順番待ちが必要だった。

現場は新しい問いの答えをすぐ得られず判断が遅れていた。

1. 社内の財務やフリートや価格のデータをまとめた。
2. そのデータでBIエージェントを作る。
3. 質問の処理をCortex Analystが担う。
4. 既存のアクセス権を引き継いで見てよいデータだけ渡す。
5. 評価用データの作成と自動テストをSnowflake CoCoに任せた。

BIエージェントには月に数千件の質問が集まり、1,600以上の拠点や営業や財務の社員が日々使っている。

開発作業の多くは数日から数分に短くなった。

古い仕組みと増え続けるデータで分析が追いつかなかった。

世界中の拠点に置く補修部品をどれだけ持てばいいのかも分からず在庫の担当者が困っていた。

1. 社内基盤の中核にDatabricksを置きデータを1か所へまとめた
2. 同じ作業環境で大きなデータを触れるようにした
3. 全拠点と全部品で1万回を超えるシミュレーションを回した
4. BIツールから大規模データへ直接問い合わせる形にした
5. 購買の履歴から一人ひとりに合う特典を出す仕組みも作った

在庫予測モデルの実行が数日から数時間になり在庫の持ち方が良くなって年間の費用も減った。

250人以上のアナリストと800人の現場のデータ担当者がデータを自分で扱えるようになった。

作りたい仕組みの依頼が全部エンジニア部門に集まり、時差のある各地のチームの要望は翌営業日まで待ちになっていた。

アナリストのレポート作成にも毎回数時間かかっていた。

1. n8nを自社のサーバーで動かした
2. 社内の分析エンジンや外部APIや複数のLLMをつないだ
3. 定期処理とフォームやチャットの画面とLLMエージェントの三つに使う
4. モデルの呼び出しは全部n8nを通し切り替えられるようにした
5. 作った機能を部品として公開し他チームが組み合わせて使えるようにした

アナリストのレポート作成にかかる時間は大きく縮まり年間で2,000時間以上が空いた。

ワークフローの実行は473,000回を超え、POCの立ち上げも数か月かかっていたものが即日になった。

薬が効かない細菌が増え、毎年多くの死亡に関わっている。

土や植物から新しい分子を探す従来のやり方は時間がかかり、試行錯誤に頼っていた。

1. DNAを情報として扱い、分子を選び出す問題に置き換える
2. チームの考えをChatGPTに入れ、候補を絞るアルゴリズム案を出させる
3. Codexでパターン発見や図にする処理のプログラムを書く
4. 最後は研究者が候補分子を見極め、実験につなげる

新しい抗菌薬の分子を数年かけずに数時間で見つけられるようになった。

ChatGPTはチームの共有の頭脳のような存在になり、計算を扱わなかった研究者も自分でアルゴリズムを書けるようになった。