こんにちは、株式会社ジーニー技術広報担当です！ GENIEE Tech Blogでは、日々の開発で得た技術的な知見や、生成AIの活用事例、プロダクト開発の裏側など、エンジニアによるさまざまな情報を発信しています。 今回は、直近1年間（2025年9月〜2026年9月）の閲覧データをもとに、特によく読まれた注目の記事を3本ピックアップしてご紹介します！ 「GENIEE Tech Blogを初めて読む」という方も、ぜひ気になる記事からチェックしてみてください。 Claude Code にAWSのコスト調査をさせたら数千万円分の改善ポイントが見つかった 記事を読む｜Claude Code に

本ブログは Umios 株式会社様 と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの辻 浩季（つじ ひろき）です。 食品製造業において、販売計画の策定は生産計画・在庫管理の根幹をなす業務です。しかし、膨大な商品数と拠点数を抱える企業では、この業務が担当者の経験と勘に依存し、多大な工数を要するケースが少なくありません。今回ご紹介するのは、Umios 株式会社様（旧マルハニチロ、2026年3月に社名を変更）が Amazon SageMaker JumpStart 上の時系列基盤モデル「Chronos-2」を活用し、販売計画の自動化を実現した事例で、年間約4,200時間の作業削減を見込んでいます。 はじめに Umios 株式会社様は、創業146年の歴史を持つ食品メーカーです。冷凍食品を中心に、業務用流通事業と市販用冷食事業を展開しています。同社では、全国の支社の営業担当者が毎月、事業・商品・倉庫ごとに翌月以降の販売計画を手作業で入力しており、 業務用流通事業部の全支社で年間約4,200時間 を要すると試算されています。加えて、販売計画管理システム「PPPlan」上の管理データは約470万セルに上り、人手による管理は限界を迎えていました。 プロジェクト体制 本プロジェクトは、Umios 株式会社様の業務用流通事業部・DX 推進部、Umiosテック株式会社、AWS の4社協業体制で推進されました。 業務用流通事業部は業務要件の定義と現場運用ルールの整備を担い、DX 推進部は佐藤様がプロジェクト全体のマネジメントと同事業部・支社との仕様調整を、浦本様が技術選定を、深澤様が AWS 構成設計を、大木様が営業現場との業務フロー再定義を主導しました。Umiosテック株式会社は予測基盤の実装と精度検証を担当し、AWS はソリューションアーキテクトとして、Chronos-2 の提案・精度検証の技術支援・アーキテクチャ策定支援を行いました。 Chronos-2 を選んだ理由 Umios株式会社様では当初、社内で全社展開している生成 AI チャット基盤「UmiChat」（Claude Sonnet 4 ベース）を用いて需要予測の PoC を開始していました。しかし、LLM によるワンショット予測には再現性やシステム組み込みの面で課題がありました。 そこで AWS から提案したのが、 Chronos-2 です。 fig1. Chronos-2とは 説明スライド Chronos-2 は Amazon Science が開発した時系列基盤モデルで、以下の特長があります。 事前学習済み : 膨大な時系列データで事前学習されており、個別のモデル構築が不要。導入初日から予測可能 API ワンコール : 推論は API 呼び出しのみで完結し、ビジネスロジックの開発に集中できる デプロイ容易 : Amazon SageMaker JumpStart から数クリックで実行環境を準備可能 UmiChatを用いて精度検証を行ったデータを用いて、Chronos-2との比較検証を実施したところ、Chronos-2 が UmiChat を上回る予測精度を示したことから、Umios株式会社様は Chronos-2 を用いた本格的な PoC の実施を決定しました。 fig2. Chronos-2とUmiChatでの予測結果の比較（※MNGPTはUmiChatの旧名称） ソリューション / アーキテクチャ 現行運用の課題発見 ── 予測の流れを整理して見えたこと Chronos-2 による AI 予測の導入設計を進めるにあたり、まず販売計画予測の大きな流れを整理しました。流れ自体は3ステップとシンプルです。 営業担当者が自身の得意先の販売増減情報を更新する 支社単位で計画策定担当者が商品・倉庫別に月の販売計画を策定する 事業部にて販売計画をもとに生産計画策定へ進む しかし、この業務フローを AI 自動化の観点で詳細に整理していく中で、 3つの構造的課題 が潜んでいることが明らかになりました。 課題①: 販売増減情報の入力が徹底されていない 支社ごとに管理方法がバラバラで、システムに入力する支社、独自 Excel で管理する支社、運用が停止している支社と大きく3パターンに分かれてしまっており、AI に入力するデータの前提が崩れている状態となっていました。 課題②: 入力精度が担当者の経験に依存  計画値は各担当者の長年の経験と勘にもとづいて入力されており、属人化していました。 課題③:「3ヶ月先を当てなければならない」構造 計画策定から生産計画への反映までのリードタイムにより、予測対象が2〜3ヶ月先となり、精度の確保が構造的に困難でした。 fig3. 現運用の課題洗い出し これらは AI 導入以前に解決すべき課題であり、逆に言えば AI を活用するために必ず整備しなければならない土台 でもありました。「AI で何ができるか」ではなく「理想の姿にどう AI が活用できるか」から逆算した結果、まずこの土台を整えることが最優先だと判断しました。 上記の課題に対し、AI 導入と並走して以下の打ち手を講じました。 「AI 導入以前に、現運用の整理とあるべき運用の定義が重要」── これが本プロジェクトの核心メッセージです。完璧なデータを待つのではなく、入力しやすい仕組みで前進し、AI が「使える」状態を先に作ることで、Chronos-2 の予測精度を最大限に引き出す土台を構築しました。 3つの打ち手による運用設計 発見した3つの構造的課題に対し、AI 導入と並走して以下の打ち手を講じました。完璧なデータを待つのではなく、入力しやすい仕組みで前進し、AI が「使える」状態を先に作ることで、Chronos-2 の予測精度を最大限に引き出す土台を構築する ── という方針です。 課題①「入力の非徹底」に対しては、簡易入力アプリによる運用徹底。 課題②「経験依存」に対しては、Chronos-2 による時系列予測で属人性を排除。 課題③「計画精度の構造的困難」に対しては、日次予測更新と BI による見える化。 以下、それぞれの打ち手を詳しく説明します。 fig4. AI自動化の前にすべきこと 打ち手①: 簡易入力アプリによる入力運用の徹底 上述の課題①に対し、簡易入力アプリを内製しました。得意先ごとの販売増減情報を、全国共通フォームで誰でも同じ形で入力できる受け皿を整備。毎月20日に締切連携する運用ルールを設け、データの欠損とばらつきを排除しました。「全国統一で動いているつもり」は幻想だった ── この気づきが、完璧なデータを待つのではなく入力しやすい仕組みで前進する、という判断につながりました。 打ち手②: Chronos-2 による経験依存の脱却 上述の課題②に対して、担当者の経験と勘に依存していた予測そのものを、時系列予測モデル Chronos-2 で置き換える施策をとりました。ここでの設計上のポイントは、 現行運用を変えないまま 属人性を排除した点にあります。 従来どおり支社の計画策定担当者が最終確定する運用フローは維持し、AI はあくまで「ロジカルなたたき台」を提供する位置づけとしました。Chronos-2 は確率予測（P10 / P50 / P90）を返すため、下振れ・中央・安全側の3点を提示し、担当者が10日間の確認期間で現場の目で点検・修正して最終確定します。AI に任せきりにせず、人が責任を持つ ── この役割分担を事業部と合意したことが、現場の受容につながりました。 打ち手③: 日次予測更新と BI による見える化 上述の課題③に対し、最新の予測値を 日次で更新 する仕組みを構築しました。締切直前の最新実績まで取り込むことで、2〜3ヶ月先の予測であっても精度を底上げできます。さらに、既存BI ツール上で予測値・計画値・実績値を並べて可視化し、予測値との乖離アラート機能を付与。リアルタイムで状況把握が可能になりました。 この仕組みは販売計画策定の効率化にとどまらず、事業部の生産計画と在庫調整にも波及します。日々更新される予測値を素早くキャッチし、在庫最適化につなげる ── 販売計画自動化の効果が、サプライチェーン全体へ広がる設計です。 AWS アーキテクチャ 既存の実績 DB・BI ツールには手を加えず、その外側に AI 予測を追加するシンプルな構成を採用しました。 推論基盤 : Amazon SageMaker JumpStart（Chronos-2 エンドポイント） バッチオーケストレーション : AWS Step Functions 定期実行 : Amazon EventBridge（日次スケジュール） データストア : Amazon S3（実績データ・予測結果） fig5. AWS アーキテクチャ図 既存資産を最大限活かしたサーバーレス構成により、運用負荷を最小化しています。 精度検証と試行錯誤 精度検証の設計思想 Chronos-2を採用するかの判断基準に予測精度を用いました。ただ、初めから完璧を求めるのではなくまずは事業部が販売計画として許容できる受容ラインである60-70%（商品別×倉庫別×販売課別の月次粒度）を超えていればChronos-2を採用すると判断し、その後、特徴量エンジニアリングを行い予測精度80-90%を目指すという計画を立てました。結果として、PoCで対象とした定番商品の年累計総計ベースで95%の予測精度が得られました。 特徴量エンジニアリングによる精度改善 PoC 初期、一部の季節性商品で予測精度が想定を下回る課題が発生しました。具体的には、毎年2-4月にピークが来る商品について、Chronos-2 がその周期的パターンを捉えきれていませんでした（WMAPE 62.57%）。 fig6. 商品B の過去の売り上げ履歴 この問題に対し、周期性を明示的に示す Month 列を特徴量として追加 するアプローチを適用したところ、WMAPE が 62.57% → 20% へと大幅に改善しました。 fig7. 特徴量にMonth列を加えた場合の予測結果（予測値はmean値をプロット） fig8. 過去データを1年増やした場合の予測結果（予測値はmean値をプロット） 試行錯誤から得た知見 精度改善の過程で、以下の知見が得られました。 (1) 実績データ ≠ 真の需要 販売実績データは「売れた量」であって「本当の需要」ではありません。たとえば処分販売（通常100 円の商品を在庫消化のため20円で販売するケース）はデータ上スパイクとして現れますが、これは在庫余剰の結果であり需要ではありません。このスパイクを学習データに含めたまま予測すると、将来もその異常値が繰り返されると誤認し、予測が大きく外れます。 対処として、処分販売データを学習対象から除外し「需要だけ」を学習対象にしました。何を入れ何を外すか ── このデータキュレーションの判断が精度を分けるポイントでした。 (2) 商品コード改廃の壁 食品業界特有の課題として、規格変更のたびに JAN コードが世代交代し、販売履歴が分断される問題がありました。たとえばある冷凍食品は2010年・2012年・2015年・2021年・2025年と5世代もコードが変わっています。コードが変わるたびに販売履歴がリセットされるため、周期性が読めなくなります。 現場では手作業で新旧コードを紐付け（グルーピング）して対処しましたが、抜本的にはマスターデータの整備が必要です。なお、現在展開中の商材にはこの問題に該当するケースがなく、顕在化していませんが、横展開時には避けて通れない課題です。学びは「AI 予測を始める前に、マスターの整備が精度を大きく左右する」ということでした。 (3) 予測に寄与する可能性のある特徴量のデータ入力の整備 上述の打ち手①の具体的な施策として、前述の簡易入力アプリ（内製）で受け皿を統一しました。全国共通フォームで同じ形式で入力でき、毎月20日に締切連携する運用ルールを設けることで、欠損とばらつきを排除。販売増減見込みを予測に寄与する特徴量として使える状態を整えました。統一による精度への効果はこれから検証する段階です。 (4) 季節性の捉え方 初期検証では1年分の販売データのみを使っていましたが、ピークの時期やパターンを捉えきれず誤差が大きくなりました。データ範囲を3年に拡張し、さらに「月（Month）」を特徴量として明示的に追加したところ、季節品の予測精度が大幅に改善。効果のあった調整から順に取り入れる、というアプローチで段階的に精度を上げていきました。 得られた成果 本取り組みにより、以下の成果が得られました。 営業担当者の月次計画入力作業を大幅に自動化: 全商品に展開すると 業務用流通事業部の全支社で年間4,200時間の作業削減見込み 定番品年累計総計ベースで95%の予測精度 : Chronos-2 + 特徴量エンジニアリングによる高精度予測を実現 日次予測更新による迅速な状況把握 : 予測値と計画の乖離をリアルタイムで可視化し、在庫最適化に寄与 今後の展望 Umios株式会社様では、自動化の次のステップとして AI に「説明」と「行動」まで任せることを目指しています。 予測結果の説明可能性向上 : 「Chronos-2 は予測の結果しか返さない」という現場の声に対し、Amazon Bedrock AgentCore を用いたエージェントの構築を予定しています。Chronos-2 による時系列予測の実行と、予測結果の自然言語による考察をチャット形式で実現し、既存のUmiChatに組み込み可能であることを実証しています。 アクションの自動化 : 予測値と計画の乖離が閾値を超えた場合のアラート・推奨アクションの自動提示することで、現場での判断をしやすくする仕組みを導入する予定です。 対象商品の拡大 : 現在の定番品から、スポット品・新商品への予測対象の拡大し、さらに人手の作業量を減らす計画をしています。 まとめ Umios株式会社様は、「予測モデルを作る」のではなく「使う」ことを選び、Amazon SageMaker JumpStart 上の Chronos-2 を中核とした販売計画 AI を構築しました。 本プロジェクトの成功の鍵は、 勝負どころは予測モデルではなく、データと運用にある という方針のもと、AI 導入以前に現場の運用課題を徹底的に洗い出し、業務プロセス改善と AI 導入を並走させたことにあります。 目指したのは、現場が回る運用。それを事業部、DX推進部、Umiosテック(株)、AWSの関係者全員で一緒に作れたことが、一番の成果です。 著者について 浦本 和司  様 Umios 株式会社 DX 推進部 DX 推進課 生成 AI・クラウドを活用した全社業務の AI 化を推進。プロジェクトの技術選定を担当。             大木 優子  様 Umios 株式会社 DX 推進部 営業デジタルマーケティング推進課 デジタルを活用した営業業務の効率化促進。現状業務の整理・デジタル導入後の業務フロー再定義によりスムーズな運用をサポート。             佐藤 勝利 様 Umios 株式会社 DX 推進部 DX 推進課 販売計画AIプロジェクトの実務PMを担当。事業部・支社との仕様調整と、プロジェクト全体のとりまとめを推進。             深澤 薫平 様 Umios 株式会社 DX 推進部 DX 推進課 クラウド基盤の設計・構築を担当。本プロジェクトでは AWS 構成設計を主導。             髙橋 伸幸 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 小売・消費財業界のお客様を担当しています。元SIerの経験を活かした幅広い支援を得意としています。             辻 浩季 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 製造業のお客様を担当する傍ら、機械学習・生成AI領域で幅広いお客様をご支援しています。特に時系列予測を得意としていますが、自分の未来を予測するのには苦労しています。

１．はじめに Geniee Carpetチームの木下です。量子コンピューティング技術のアドテクへの応用可能性を調べている中で、Axel Ciceri氏らによる論文 Enhanced Fill Probability Estimates in Institutional Algorithmic Bond Trading Using Statistical Learning Algorithms with Quantum Computers に興味を持ちました。 本論文は、金融市場における社債取引の約定確率（Fill Probability）の推定に、量子コンピュータで生成した特徴量