実施 2022.10 ・ 更新 2026.08.13
需要量の算出が1~2時間から20~30秒に、バルブメーカーのデータ基盤刷新
企業規模:1,000人以上
※イメージ画像です

取り組み概要
やさしく事例解説
プロジェクト解析
実施・導入企業
こんな方へおすすめのAI解説です
- 分析結果が出るまで何時間も待つ
- 項目を足すたびにベンダー依頼
- クラウドが増えて運用が回らない
どのようなAIの取り組み?
クラウド上に自社のデータ分析基盤を構築し、部品表からの需要量算出を1~2時間から20~30秒へ短縮した取り組み
業種
バルブ・流体制御機器の製造(製造業)
取り組み領域
データ活用基盤/情報システム
使ったAI
BigQuery(クラウド上のデータ分析基盤)
主な成果
部品表からの需要量算出が1~2時間から20~30秒に短縮
総合バルブメーカーの株式会社キッツは、データ活用基盤 K-DAP(KITZ Data Analytics Platform)を Google Cloud 上に構築しました。2015年から使ってきたデータウェアハウス製品は構造化データしか扱えず、項目の追加や画面の変更のたびに開発ベンダーへ依頼する必要がありました。2020年に検討を開始し、複数のクラウドサービスを調査したうえで約半年のトライアルを経て Google Cloud を選定。設計から構築までは京セラコミュニケーションシステム(KCCS)が支援し、2022年10月から本格利用が始まっています。基幹システムなどのデータを取り込んで BigQuery に蓄積する構成により、部品表から需要量を算出する処理は1~2時間から20~30秒に短縮されました。あわせて2027年の SAP ECC サポート終了に備え、SAP S/4HANA の移行基盤にも Google Cloud を採用しています。
出典:株式会社キッツ の導入事例 | Google Cloud 発行元:Google Cloud
やさしく事例解説
何に困って、AIを入れたのか
2015年に導入されたデータウェアハウス製品は、扱えるのが構造化データだけで、受注や発注、実績といった会計につながるデータを分析に載せきれない状態にありました。さらにデータの収集や加工の中身が見えず、項目をひとつ追加するにも開発ベンダーへの依頼が必要。大量のデータを扱おうとすると、BIツール側の制約で処理が止まってしまうこともありました。
ここで効いていたのは、処理が遅いという表面的な事象よりも、分析の仕様を自分たちの手で変えられないという構造のほうだったと考えられます。依頼して待っている間にも市場や受注の前提は動きますから、できあがった時点ですでに別のものが必要になっている。現場から出てくる「こんな切り口で見たい」という問いが、形になる前に賞味期限を迎えてしまう状況です。つまり、一回あたりの処理時間の問題というより、問いを立て直せる回数が絞られていたことが本質だったのではないでしょうか。
どうやって、うまくいったのか
約半年をかけて複数のクラウドを実際に動かして比べ、評価の軸を3点に絞り込んだ選び方が、この取り組みの起点になっています。挙げられたのは、クエリの内容に応じて柔軟かつ迅速に処理能力を伸ばせること、提供元自身の社内利用を含めて10年以上の運用実績があること、そしてコストを抑えて小さく始められること。将来の拡張余地と初期の身軽さという、通常なら相反しがちな条件を同時に満たす前提で候補を評価した点に、この選定の性格が表れています。
データを一段階ずつ整えて置き直す設計も、実運用を支える柱になっています。基幹システムや各種データベース、手元のファイルまで含めた業務データを、Compute Engine 上のETLツールで Cloud Storage のデータレイクへ集め、そこで加工したうえで分析用の標準化データとして BigQuery に蓄積し、さらに用途ごとの目的別データへと分類していく。この標準化された中間の層があることで、新しい問いが出てくるたびに元データの取り込みからやり直す必要がなくなります。
パートナーの置き方と、到達点の描き方も見逃せません。設計から構築までは、メーカーである京セラのデジタル変革を支えた経験を持つ KCCS が伴走し、やりたいことを踏まえた構成を一緒に組み立てる形をとりました。そのうえで、データの収集と取り込みを当面はシステム部門とパワーユーザーが担い、将来は分析の担当者自身が集めて加工して可視化する、という段階的な移行像を先に置いています。外注か内製かを二者択一にせず、移行の途中経過そのものを設計に織り込んだ進め方です。
具体的に、どんな成果が出たのか
改善・向上したこと
推進したこと
この事例で出た成果
旧分析システムでは部品表から需要量を算出する処理に1~2時間かかっていましたが、BigQuery を採用した K-DAP では同じ処理が20~30秒で完了するようになりました。操作の負担が下がったことで分析改善の内製化も進み、1年で200以上のテーブルが新たに作成され、現場から寄せられる分析の要望にも迅速に応えられる状態になっています。一方、複数のクラウドを集約することによる年間数億円のコスト削減は、現時点では期待される効果として示されている段階です。
うちでも使える?
応用が利きやすいのは、基幹システムに受注・在庫・実績といったデータがすでに溜まっていて、それを見る切り口の追加や変更が絶えず発生している組織です。生データと分析用の標準化データを分け、その先に用途別の層を置くという構成自体は、規模や業種に依存しにくい考え方といえます。分析の変更依頼が外部への発注として積み上がっているなら、検討する価値は小さくないでしょう。
逆に難しいのは、分析したい情報が紙の帳票や個々人のExcelに散らばっていて、そもそも自動で吸い上げられる元データが定まっていない場合です。基盤を先に用意しても流し込むものがなく、投資が空回りします。この事例では、当面のデータ収集と取り込みをシステム部門とパワーユーザーが担う体制が前提になっていた点も見落とせません。情シスが一人二人の兼務という環境では、基盤より先に受け皿づくりが要ります。
まずは、直近半年で外部に出した分析や帳票の変更依頼を並べ、そのうち何件が「項目を足す」「見る切り口を変える」だけの依頼だったかを数えてみてはどうでしょうか。その比率の高さが、道具ではなく構造を変えるべきかどうかの目安になります。
この事例は2022年10月時点の情報です。AI分野は変化が速いため、現在は同様の取り組みをより短い期間・少ない負担で実現できる場合があります。
プロジェクト解析
プロジェクト内容
AI導入・支援形態
AIツール・サービスの提供形態
導入部門・データ活用
導入部門:全社共通・汎用業務
活用したデータ:数値・Excel・ログ
採用したAI技術・ツール
採用したAI技術:AIモデル・構築手法
AIモデル・ツール
連携ツール
連携したシステム・外部サービス
プロジェクト実施・導入企業
株式会社キッツ
掲載企業の方へ:本記事は公開情報をもとに作成しています。内容の修正・削除、または貴社確認のうえでの公式掲載をご希望の場合はこちらからご連絡ください。
