製造業のAI活用事例

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

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

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

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

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

2,000行を超える商品データを熟練の担当者が手書きのマニュアルや経験で捌いており、辞めると情報が消えてしまう状態だった。

従来のシナリオ型チャットボットは作り込みと運用の手間が重く、担当者の負担も大きかった。

1. 新規事業の問い合わせ窓口にサイトを読んで回答するGeNを置いた
2. KARAKURI assistに工場の対策報告書をそのまま入れた
3. 決めた項目で箇条書きに整理するよう指示を出した
4. 整理された原因と対策をもとに担当者が詫び状に書き直した
5. 月1〜2回の壁打ち会で同じお題を入れ合い指示の書き方を共有した

技術者向けに書かれた報告書の読み解きと詫び状の作成が、30分から5〜10分で済むようになった。

問い合わせ件数の削減ではなく顧客体験を重視する方針で、少人数でも対応の質を保てる体制になった。

1日に数百件の問い合わせが届き多くの人手をかけていた。

担当者が幅広い質問を一人でさばけるまで3〜6か月かかっていた。

1. 過去の問い合わせ履歴から多い質問をFAQにまとめた
2. 代理店専用ポータルと同じページにFAQとChatAgentを並べる
3. 基本の質問はFAQに答えさせ細かい内容はChatAgentへ渡す
4. 認証とつないで会社名や連絡先が自動で入るようにした
5. チャット履歴や0件ヒット率を見てFAQを直し続ける

代理店の自己解決率は69%になり、海外在庫の確認などはほぼチャットに移った。

担当は1名のままで、手入れは週1回10分程度で済んでいる。

カタログや施工事例の画像と資料が複数のストレージやExcel台帳に散らばり、目的の素材を見つけるには全データを落として一つずつ目で確かめるしかなかった。

誰がどのファイルを編集できるかもはっきりせず、価格改定時の更新や制作会社とのやり取りにも時間がかかっていた。

1. カタログと施工事例の2つを対象に管理基盤を組んだ
2. 既存データを移し替えてSSOをつないだ
3. フォルダ構造と閲覧・編集の権限を設計した
4. 検索やプレビュー、タグ付けを現場に合わせて整えた
5. 読み取り専用の利用者を設けて誤編集を防いだ

販促を担う部署の約20名が毎日の仕事で使う状態になり、素材探しのために全データを落とす手順はなくなった。

同社はこの部署の仕事の重さを2名分ほど減らすことを目標に置いている（数値での効果測定は今も続けている）。

PLCのラダープログラムを検索して要約する社内サービスを作ったが、プロンプトインジェクションや内部情報の漏れといったAI特有の危険がどこにあるか分からなかった。

安全対策をどう検証すればよいかも手探りだった。

1. ソースコードと機能を調べリスク一覧を作る
2. 影響の大きさと起こりやすさの2軸で整理する
3. 攻撃の筋書きを書き疑似攻撃を実施する
4. 防御あり・なしで攻撃の成否を比べる
5. しきい値やポリシーを調整し報告会で共有する

不適切な出力や内部情報の露出など3種類の弱点が見つかり、そのうち2種類に対して高い検知性能を確認した。

通常利用での誤検知率は1.7%にとどまった。

攻撃の見逃し率は4.7%で評価にかかる時間も100ミリ秒以下となり、本番導入が決まった。

紙の図面や検査記録が社内にあふれ、書類を探すだけで現場が1〜2時間動き回ることもあった。

創業50年でも手順書は50件ほどで、多くの作業のやり方はベテランの頭の中だけにあった。

1. AIとの対話を1500時間以上重ねコーディングを学んだ
2. タブレットとSlackで内線電話や紙探しをなくした
3. Claude Codeで社内アプリをフルスクラッチで内製した
4. 生産実績や設備稼働などを同じデータベースにひも付けた
5. 手順書アプリでAIが100点満点で採点し改善案を出す

月400〜500時間程度の作業時間を減らし、価格改定資料の作成時間は90％短縮した。

紙は月間約6000枚減り、手順書は1年足らずで290件集まった。

半導体需要の伸びで契約審査の依頼が月約90件まで増え、その約3割を占めるNDAに時間を取られていた。

社内の生成AIはリスクを挙げるだけで、修正履歴やコメントを入れたWordファイルまでは作れなかった。

1. 自社のひな形と過去の審査実績をまとめる
2. AIが判断する審査基準（プレイブック）を組み立てる
3. 相手方の契約書を読ませ自社ひな形との違いを比べさせる
4. 各条項の可否を判定させ修正案をWordの修正履歴で出力させる
5. 出てきたWordを確認し必要な箇所だけ直して審査に乗せる

英文NDAの確認から修正案作成までが約2時間から約10分になった。

和文英文を合わせたNDA審査の工数は従来の約5分の1に減り、空いた時間を取引基本契約など重い案件に回せるようになった。

新製品開発や設計審査、プロジェクト管理の規程が細則を除いても約3,000ページあり、必要な内容を自力で探すには知識と経験が必要だった。

社内の検索環境の整備が課題になっていた。

1. 社内カンパニーが規程を調べるポータルを用意した
2. 検索の仕組みをSharePointからRAG型サービスへ差し替えた
3. 社員は質問を入れ回答と規程一覧を同時に受け取る
4. 全社のCopilotとは役割を分け規程検索はCogmoを使う

導入から約一年たった今も月間平均約4,000回使われ続けている。

業務改善につながったと評価され、他のカンパニーや部門へも広がっている。

間接部門の工数の3分の2が事業を維持するための業務に消えており、新しい価値を生む時間が取れなかった。

日報や技術情報などの文書もたまる一方で使い切れていなかった。

1. 各部署からデジタルに強い社員を選び少人数で使い始めた
2. 会議の記録づくりとExcelマクロのコード作成に使った
3. AIが書いたコードを人が確認して直す流れに変えた
4. 標準テンプレートで始め個別要望はカスタムを作った
5. 半年後に経営層へ報告し対象データの範囲を広げた

会議の記録づくりは月78時間分、コードを書く仕事は月79時間分の手間が減った。

ダッシュボードで効果が数値で見えたことが経営層への説明材料となり、2025年3月から全社展開が始まった。

コロナ禍で出社できる人だけで仕事を回す必要が生じ、ベテランの経験に頼った進め方が続かなくなった。

個人への依存を減らし、誰がやっても同じ結果を出せる仕組みが求められていた。

1. AWS上でAmazon Bedrockを選び生成AI基盤を決めた
2. 公開のGenUを土台に自社向けAI画面を作った
3. 営業サポートは専門用語をClaudeに聞き表で資料化した
4. デザイン部門はTシャツ図案を画像生成し添削にも使った
5. EC担当はSQLエラーをAIに相談し社内エンジニアが指導した

デザイン部門を除く4部門で月あたり合計450時間の工数を減らした。

デザイナーは1案件あたり2時間短くなり、外注で1週間かかっていた図案も画像だけなら10秒で出せるようになった。

従来のIT点呼ではドライバーが数桁のIDを打ち込んでログインしていたため、打ち間違いが多く点呼が遅れていた。

アルコール測定を別人が代わりに受ける恐れもあった。

1. 点呼サービスの基盤をEC2とAuroraでクラウド上に作った
2. ログイン部分にAmazon Rekognitionを組み込んだ
3. ドライバーの顔で本人を判別しID入力をなくした
4. 高齢者でも扱える画面にし法令要件に合わせた
5. 不具合はクラウド側を直し遠隔でサポートした

2022年4月の遠隔点呼の解禁後、『e点呼PRO』の採用事業者が130社以上増え、売上も半年で2,000万円近く伸びた。

保守・サポートの対応が減り、コストは約5％下がった。

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

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

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

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

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

全従業員が生成AIを使える環境を整えても、実際に使う人が一部に偏り日常の業務に根づかなかった。

使い方を学び合う場や続けて情報を届ける仕組みが足りなかった。

1. 全社共通の生成AI基盤「PX-AI」を用意した
2. Teams上に使い方や事例を持ち寄る場を作った
3. 動画やコラムなどの学習向けの中身を定期配信した
4. 反応を見て中身を作り直した
5. 隔日の確認と週次の定例で次の配信を決めた

「PX-AI」はグループ内で約8万人が使う基盤に育ち、使った人へのアンケートでは1人につき毎月約7.5時間が浮いたという回答が集まった。

全体では月間約29万時間の効率化につながり、コミュニティには延べ3.1万人が参加した。

ペーパーレス化でオフィス機器の事業環境が大きく変わり、それに頼らない新しい事業の柱が必要だった。

自社の画像技術をIoTやAIとつなぐ基盤を短い期間で立ち上げる必要もあった。

1. カメラとIoT機器のデータを現場端末のAIで処理する
2. 処理結果をクラウドにためて解析する仕組みにする
3. AI処理をコンテナに分けAmazon ECRで保存と配布を回す
4. デバイス管理と遠隔更新はACCESS Connectで行う
5. 2017年にPoCで基盤を作り2020年11月に公開した

介護や工場、マーケティングの現場で使われ始めた。

QOLシステムの管理サーバーの入れ替えは従来の30%〜40%の工数で済み、遠隔保守の機能で運用工数は60%〜70%削減できるようになった。

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

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

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

教師データが必要なBERTモデルでは読解の精度に限界があり、複合機のジャムを紙詰まりと解する業務特化の生成AIを作れなかった。

開発に必要な大量のGPUも2022年初頭は入手しにくかった。

1. GPT-3相当のOSSモデルを土台に選び開発環境をAWSに置いた
2. GPUインスタンスの上限緩和を申請し大量のGPUを確保した
3. Amazon SageMakerで分散学習の環境を組んだ
4. 学習データをS3からFSx for Lustreに関連付ける形へ変えた
5. 大量の日本語を追加学習させ専門家に随時相談した

2022年10月から3か月で独自のAIモデルを完成させ、日本語に強く高速で良質な文を作れるモデルになった。

社内にAIエンジニアリングのやり方が残り、自社で解決できる水準まで技術が上がった。

菓子の乾燥や炙りに使うチェーンコンベアが年に数回壊れ、生産ラインが止まっていた。

修理に3日かかる場合もあり、賞味期限のある商品を捨てることもあった。

1. 市販のマイクとマイコンボードでコンベアの音を定期的に録音する
2. 録音をAWSへ送りAmazon S3にためる
3. Amazon SageMakerで正常音を基準にした教師なし学習で異音を見つける
4. 異音検知時にAmazon SNSから担当者へメールを送る
5. 担当者が音を聞き現場で整備の要否を決める

2022年末に最初の検知モデルができ、2023年4月には全てのチェーンコンベアで異音検知ができるようになった。

放置すれば3日止まる損傷を稼働時間外の2時間の整備で直せた例があり、始業時と終業前の見回りも取りやめた。

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

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

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

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

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

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

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

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

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

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

治験計画の届出後に来る照会への回答づくりでは、似た質問や事例を人手で探して文章を組み立てるため時間がかかっていた。

全社で生成AIを使う土台も整っていなかった。

1. AWSの全社クラウド基盤にAmazon Bedrockを組み込む
2. 社員とAWS担当でスクラムチームを作り1週間ごとに計画とレビューを回す
3. 1画面で複数LLMを選べる形にし入力を再学習に使わない設定にする
4. 社内データをRAGでつなぎ照会回答の下書きをAIに作らせる
5. 担当者が中身を確かめて仕上げ週次リリースでひな形を増やす

2024年10月時点で全社員の約80%にあたる約6,000人が使うようになった。

照会対応の一例では約57%の業務削減につながった。

総務本部では毎月同じ定型作業を1件ずつ手で処理し月に何時間もかかっていた。

生成AIへの関心はあったが何から手をつけるか決められずにいた。

1. エンジニアが現場で担当者と話し業務の流れを洗い出す
2. 文章作成や情報整理の作業を生成AIに任せる部分として切り出す
3. 既存の業務の流れに組み込む形で自動化を設計する
4. 最後の確認は人が行い品質を保つ
5. 運用マニュアルをそろえ担当者が自分で回せるようにする

複数の部署にまたがる計7テーマの自動化が動き出し、毎月繰り返していた作業の時間が減った。

担当者が自分で運用と改善を続けられる状態になり、他部署へ広げる土台もできた。

品質保証部門を支えるシステムを少人数で回しており、手を動かせるエンジニアが足りなかった。

担当者の契約終了で説明資料のないコードだけが残り、中身をつかむのが難しかった。

1. リポジトリ全体を読めるJiteraを導入する
2. 資料のない既存プログラムを丸ごと読ませて機能を説明させる
3. 出てきた説明をもとに仕様の下書きを作り担当者が確認して直す
4. 障害時はエラー内容と該当ソースコードを渡し原因を絞り込む
5. AIが挙げた原因候補を手掛かりに担当者がコードを確認して対処する

手作業で数時間かかっていた資料づくりが短い時間でたたき台まで進むようになった。

エラーの原因を探す手間が減り、復旧までの時間も短くなった。

営業担当1人が数十社を受け持ち、100を超える製品の詳細や操作方法を覚えるのに時間がかかっていた。

ベテランの製品知識や顧客情報が個人に偏り、若手の育成にも時間を要していた。

1. 数十点の製品情報や操作説明を1ROLLで動画にする
2. 生成AIが文字起こしと要約を自動で作る
3. チャプターとナレーションを担当者が確かめて整える
4. 部署ごとに散らばっていた動画を1ROLLに集約する
5. 視聴データをSalesforceへ自動で流し顧客ごとに記録する

導入から1年で、分散していた動画の管理と運用が効率化し、動画が事業部の共有資産になった。

顧客がどこに興味を持っているかをデータで把握できるようになり、課題解決型の提案に向けた土台ができた。

古い仕様書は要件の一部が省かれ判断の根拠が口頭のままで残っていた。

主語の省略や古い章立てもあり読み解くのに時間がかかっていた。

1. 古い仕様書をMicrosoft Copilotに渡し今の読み方に合う文章へ書き直す
2. GitHub Copilotで既存コードを読み取り仕様書の抜けを埋める
3. 1ファイルはMicrosoft Copilot、依存追跡はGitHub Copilot
4. 設計書のレジスタ定義や関数宣言を渡し#defineやヘッダ定義を出させる
5. 影響範囲の洗い出しや責任の切り分けは人が引き取る

新人教育にかかっていた工数の負担が下がり、コード読解の速さも上がった。

量は多いが判断の少ない宣言部分で工数を減らせた一方、網羅性と正確性と統合が必要な作業は人の担当として残った。

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

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

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

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

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

建物の改修需要が増え、従来の保守に加えて中小規模の建設工事にも対応するようになった。

現場担当者が確認する対象が製品仕様だけでなく建設業法や下請法、社内規定まで広がり、調べる手間が重くなっていた。

1. 取扱説明書やスペックシートをSTiVに登録した。
2. 業務標準や社内規定も入れてまとめて検索できるようにした。
3. 自席のパソコンや現場のタブレットから質問を投げる。
4. 回答と一緒に参照元の資料と該当箇所を返す。
5. まず約30名で3〜4ヶ月試し効果を確かめて広げた。

あいまいな記憶からでも目的の資料にたどり着けるようになり、情報検索にかかる時間が大きく減った。

試行後はメンテナンスサービス領域全体の約1,000名規模へ広げている。

国内4拠点と海外8拠点の間で多言語の資料を読み解く負担が重かった。

社規の新旧対照表づくりなど手作業のコピー＆ペーストも多く、社員が個人で生成AIを使い始めていて安全な環境も必要だった。

1. DX推進室の5名で議事録や翻訳やレポート作成を試した
2. セキュリティと管理画面の使いやすさで比べてツールを選んだ
3. 2023年10月に全社へ導入した
4. 業界レポートを要約させ情報源を必ず出力させた
5. 社内規程を読ませ条文つきで回答させ人が直した

業界レポートの読み込みと要約は1時間程度から約1分になった。

社内規程などの問い合わせ対応は体感で約80％減り、総務の担当者1人で一次対応を終えられる場面が増えた。

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

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

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

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

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

キャリア採用を担当者1人で書類選考から入社後のフォローまで担っており、年間約800件の書類に追われていた。

選考の判断は現場の要件定義書だけが頼りで、基準が一人の頭の中に閉じていた。

1. 募集ポジションを登録し評価項目ごとの重み付けを決めた
2. この設定の場で現場と選考基準をすり合わせた
3. 履歴書と職務経歴書をAIに読ませ一次評価を出す
4. 評価レポートを現場に共有し根拠を示して話し合う
5. 面接は自動文字起こしをAIが要約し良い点と気になる点を出す

年間800件を1人で見ていた書類選考の手間が大きく減った。

現場と同じ一次評価を見て話せるようになり、重視する点の認識がそろった。

面接中の議事録作成から解放され候補者との会話に集中できるようになった。

プラスチック成形品の検査で不良を見逃すトラブルが起きていた。

人の目に頼る検査のままでは従業員の負担も大きかった。

1. 機械学習を使った画像検査装置を自社で開発した
2. 製品をセットすると撮影と判定が動く仕組みにした
3. 良品と判定されたものだけを個数としてカウントする
4. 組み立て機構と検査の開始ボタンを連動させた
5. 判定結果を画像と日時つきで時系列に保存した

自社内で500万回を超える検査の実績があり、導入してからは品質トラブルが起きていない。

同じ悩みを持つ同業者への外販も始まり、今年に入って複数社が導入した。

米国の各販売拠点ではExcelを使い型番ごとに発注数を人が判断していて、4名合わせて週3.8時間かかっていた。

担当者の経験頼みで発注数がばらつき、拠点をまたいだ重複発注による在庫過多も起きていた。

1. ベアリングや精密機器の販売データをDeep Predictorに読み込ませる
2. 需要予測から発注推奨量の算出までを一つのサービスでまかなう
3. 型番を一つずつ調べる作業をやめ推奨量を見て発注を確定する
4. 基幹システムの入れ替えに合わせ全米の拠点に同じ仕組みを入れる
5. 提供元が現場の運用に並走する形で支援を受ける

米国全拠点の在庫発注作業は4名合計で週3.8時間から1.4時間になり、約63%減った。

年間では約124.8時間分が浮き、発注数のばらつきと拠点間の重複発注も解消した。

社会インフラ向けの制御システムは10年以上動き続け、トラブル対応の記録が大量にたまっていた。

過去の情報から答えを見つける作業はベテランの経験に頼りきりで、担当者によって速さも質もばらついていた。

1. 熟練者が過去事例を調べる言葉と順番を分析する
2. 言葉にしにくいやり方を手順として書き出す
3. 100件以上の業務ノウハウをAIエージェントに組み込む
4. プロンプトの手直しと調整を重ねる
5. 自社事業所で先に使い効果を確かめてから外販する

事例検索は1件あたり60分から5分になり、約9割減った。

対応レポートの作成は120分から15分、不具合の原因分析は16時間から3時間になり、それぞれ8割以上減った。

機密情報を守れる環境で生成AIを広げたかったが、先に試した他社サービスでは最新モデルが使えず機能が古くなる不安があった。

社員が個人向けサービスを勝手に業務で使うリスクも見えていた。

1. 2024年6月に約30名で他社サービスを試した
2. 2025年1月にexaBase 生成AIへ切り替え本格運用した
3. 1万文字超の特許文献から特定技術の記述を抜き出させた
4. 出願の権利範囲や応答戦略の相談相手に使った
5. 報告資料はコードプレビュー機能で下書きを作った

知財部門では直近1カ月で1人あたり120時間を超える業務時間の削減になった。

全体でもユーザー100人合計で月1600時間の削減が出ている。

外国籍の社員が増えて社内のやり取りが英語中心になり資料を日英両方で用意する必要が出てきた。

無料の翻訳ソフトは専門用語の精度が低くPowerPointのファイルも扱えなかった。

1. 部門ごとにばらばらだった契約を全社の法人契約にまとめた
2. 会議資料はまず日本語で作りファイルごとDeepLに読ませて英語版を出す
3. 英語だけのPowerPointが届いたときも丸ごと訳して中身をつかんだ
4. 上司へのメールも書いた文をその場で英語に変えて送る
5. 専門用語が正しく訳せるかを選定の基準にした

翻訳にかかる時間が60％以上減った。

2〜3日かかっていた英語のスライド作成が1日で終わり導入から半年で社内の利用者が倍になった。

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

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

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

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

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

仕入先への発注をFAXで行っており、社員が毎日FAX機まで移動して1件ずつ送る作業が続いていた。

この手作業だけで月に約80時間かかっていた。

1. プログラミング未経験の社員が生成AIに相談しながら自分で組んだ
2. GoogleスプレッドシートとGASをつなぎ入力から自動送信まで処理させた
3. 最大11段階のまとめ送信に対応させ700〜800行のコードにした
4. 行き詰まった3回はゼロから組み直し4度目で完成させた
5. 約2ヶ月の開発を外部の支援を受けながら進めた

月間約80時間の作業がなくなり、稼働後は約50日間で1,600件を処理してエラーは0件だった。

受注管理や多段階承認など60〜70ファイルの追加開発にも広がり、若手社員もAIを使い始めた。

長年ためてきた紙の資料が大量にあり複数のシステムに情報が散らばっていて探しにくかった。

品質保証や薬事の仕事はベテランの記憶頼みになりがちだった。

1. 信頼性保証部にナレッジ管理システムSTiVを導入した
2. 過去の品質イベント記録と外部レギュレーション情報を一か所に集めた
3. 手書き文書をOCRで読ませその場でテキスト化する
4. テキストからそのまま報告書の素案を作らせる
5. 逸脱報告書をもとになぜなぜ分析の素案づくりも試す

手書き文書の読み取りと素案作成にかかる時間が半分になり、業務時間を50％減らせた。

紙と電子が混ざった状態でもまとめて情報を引き出せるようになった。

工場と倉庫が多く在庫の今の状態がすぐ見えなかった。

これまでのやり方では需要の読みが外れやすく担当者が手作業で数量を直し続けていた。

1. 需要予測と在庫最適化の2つを18か月かけて入れた
2. 3つの基幹システムにまたがる10のデータソースを1画面にまとめた
3. AIが出した需要予測を安全在庫の目安と補充の発注案に変える
4. 計画担当と生産スケジュール担当と管理者の3種類の画面を作った

手持ち在庫が25%減り手作業での注文投入は55%減った。

サービスレベルは3%上がり需要予測の精度も6%良くなった。

世界の採用チームが面接の日程調整と組み直しに毎月8,000時間を超える時間を取られていた。

候補者への電話や伝言で手が埋まり、採用の中身を考える時間が残らなかった。

1. 採用担当が応募者管理システムで手続きを始める
2. AIエージェントが候補者へ面接の候補時間をテキストで送る
3. 担当者のカレンダーと同期して空き時間を最新に保つ
4. 候補者が時間を選ぶと仮予約を入れて担当者へ知らせた
5. 日程変更のテキストを受け取り数分で組み直す

日程調整に使っていた8,000時間はゼロになり年間300万ドル超を削減した。

ネットプロモータースコアは5ポイント以上上がった。