Azitでは昨年、AIサプライチェーン計画プラットフォーム「ForecastX」をリリースしました。今回のインタビューでは、CEO 吉兼が読者視点に立ち、CTO 十亀に質問を投げかけています。

ForecastXが今後どのようなプロダクトとして成長させていくのか、開発組織がどう進化していくのかを語っています。

ForecastXプレスリリース：https://azit.co.jp/news/kUdXzGqa

Excel依存の強い物流現場を、データドリブンな意思決定へ変革する

ー 今日はよろしくお願いします。最初に、昨年開始したForecastXについて、CTOの視点からご紹介をお願いします。
ForecastXは、在庫を抱える企業、製造・メーカー・卸・小売といった業界をターゲットにしています。まだスタートして半年ほどですが、非常に幅広い会社を通じて社会に影響を与えられるプロダクトになるとすでに感じています。
サービスをリリースして様々なエンタープライズ企業様と商談の機会をいただいていますが、実際にお話を聞いてみると、普段当たり前のように街で見かけるような商品を扱っている企業様でも、管理の実態はExcelであることも多く。IT業界にいると想像しにくいかもしれませんが、それだけ物流・サプライチェーン周りのDX・AXにはポテンシャルがあると感じています。
そこを改善することで、最終的には一消費者としての体験も変わってくるはずです。ForecastXでは、Excelで行われている業務を地道に改革することから始め、その先で、蓄積されたデータを活用し、サプライチェーンの意思決定を支援するAIエージェントに繋げ、次の時代のサービスを作れると考えています。

ー ForecastXの顧客企業にはどのような課題があり、我々はそれをどう解決しようとしているのか。現状の課題解決方法について教えてください。
まずはじめに取り組んでいるのは、全ての起点とも言える「需要予測」です。なぜここから始めるのか。それは、我々がこれまで取り組んできたAI配車プラットフォーム「DeliveryX」で取り組んできた配送や倉庫の在庫管理も、すべては「どこで、どんな商品が、どれだけ売れるのか」という予測の精度が全てのカギになっているからです。
これを行うため、まずはシンプルにすでにある販売実績データを読み込ませることから始めます。現在募集しているFDEのようなポジションのメンバーが、AIデータサイエンティストと連携しながら、従来人間がExcelで計算していたものをより精緻に、高精度に算出できるようにします。予測結果はプラットフォームの画面上で確認でき、ユーザーがレビューや調整を行えるところからスタートしています。

ー 予測モデルを作るのはデータサイエンティストで、ワークフローにカスタマイズしていくのがFDEという役割分担ですね。需要予測では具体的にどのようなことをしているのでしょうか。
手法は様々ですが、まず商品によって特性が異なることを理解する必要があります。例えばボールペンのように安定して売れるものもあれば、手袋のように季節によって大きく変動するものもありますよね。過去の販売実績から、1年を通じた変動や週単位の傾向、成長トレンドをモデルが学習・推定します。分野としては機械学習というより、時系列予測と呼ばれる数学に近い予測理論がベースになっています。

ー 具体的にどのようなアルゴリズムを使っているのでしょうか。
時系列予測のベースとしては、SARIMAモデルなどを用いて、季節性や週次変動を統計的に分析します。また、データの特性に応じた分析手法を検討する際には、生成AIと壁打ちをすることもあります。特性が判明すれば、それに応じてProphetのような既存ライブラリを使ったり、論文に基づいてPythonで独自に実装したりして、予測結果を出しています。

ー 機械学習や生成AIをさらに活用する余地はありますか？
現在はシンプルな時系列データ予測から始めていますが、展望はあります。まず、モデルが出した予測に対して人間が計画として完成させるための修正を加えた際、その修正履歴をデータとして蓄積し、生成AIに知識として利用させることで、予測モデルどう実際の計画に落とし込むかという部分の上段にある意思決定を自律的に改善していけると考えています。これはCTOとして非常に挑戦したい領域ですね。
機械学習についても、商品自体の特性だけでなく、SNSのトレンドや気象データといった複雑なマクロデータを加味することで、より精度の高い予測が可能になると考えています。ForecastXとしてどのような外部データを取り込めるかが強みになってくるので、積極的に取り組んでいきたいですね。

統計モデルから生成AIの活用まで。ForecastXが追求する『予測』の深層

ー ちょうど最近製薬会社の方と話していましたが、例えば高額な薬の場合、在庫ロスによる損失も大きいため、患者数の推移といったマクロデータは非常に重要だそうです。こうしたデータを複合的に影響させるのも手法の一つですね。少しテクニカルな話が先行しましたが、ForecastXを導入する企業が抱える課題や、達成しようとしているKPI、ビジネスインパクトといった上流の部分についても改めて伺えますか。
一番大きな課題は「在庫が残ってしまうこと」です。在庫はオペレーション上の負債であり、保管コストもかかります。食品など期限がある商品であれば廃棄ロスにも直結します。需要予測の精度が向上し、計画を最適化するだけで、数億円規模の影響を及ぼす企業が数多く存在します。長年現場がExcelで頑張ってきた領域ですが、AIの活用によるビジネスインパクトは非常に大きい課題であると、顧客の方々からも伺っています。

ー 売上規模が数千億・数兆円の企業であれば、在庫ロスも数億から数十億単位になります。それほど大きな課題であれば、なぜこれまでのソリューションで解決が難しかったのか。ForecastXだからこそ解決できる理由を教えてください。
既存のSaaSは専門性が高く現場に定着しづらかったり、既存のオペレーションを大幅に変える必要があったりしました。そして、精度を上げる、つまり“当てる”ことがゴールであった一方で、ForecastXはそこに人間の意思が入り計画が改善されていく”決められる”ことに焦点を当てています。
また、SIerに依頼すると、個社のワークフローに合わせた大規模な開発が必要になり、数億円単位のコストと長い月日がかかってしまう場合があります。これまでの市場にはこの両極端な選択肢しかありませんでした。AzitがForecastXで提供するのは、マルチプロダクトSaaSとしての共通基盤を持ちつつ、各社ごとのカスタマイズを効率的に行う仕組みです。AI駆動開発でモデル構築やコード生成の生産性を大幅に上げているため、コスト面でも非常に有利に働いていると考えています。

ー サプライチェーンという止めることのできないワークフローの中で、自社のフローをSaaSに合わせて変えるのは難しいですよね。では、なぜ「マルチプロダクト」という戦略をとるのでしょうか。
単一の業務を置き換えるだけでは、余剰在庫の解消という本質的な課題解決には繋がりません。需要予測から在庫計画、生産や発注まで、一連のワークフローを一貫して「ForecastXシリーズ」として扱えることが重要です。
エンジニアにとってのチャレンジは、マルチプロダクト間でいかに大規模データをスムーズに連携させ、優れたユーザー体験を提供できるかという、データ基盤やインフラの構築にあります。データがこのプラットフォームに集約されることで、将来的にはAIエージェントが業務全体を俯瞰して自律的に改善提案を行うような、統合的なソリューションが実現できると考えています。

ー ForecastXは「サプライチェーンプランニング」の領域で、意思決定を支援するのが役割の一つです。データが分断されていると価値が半減してしまうので、意思決定にはデータ連携が必須ですよね。また、エンタープライズ企業ではAI導入の機運が高まっている一方、現場は今のワークフローを変えることを恐れている面もあります。自動運転に例えるなら、今は「走行データが何もない30年前の車」を運転しているような状態です。まずはDXによってデータを取得し、在庫削減という成果を出しつつ、徐々にAIの比率を上げて「完全自動運転」に近づけていく。そういったプロセスを支えるのがForecastXの役割だと言えます。

マルチプロダクト戦略とAI駆動開発がもたらす圧倒的生産性

ー これまでの話を実現していくテックチームの体制やミッション、エンジニアにとっての面白さについて教えてください。
まず「プラットフォーム開発チーム」ですが、多種多様なクライアントに向き合い、どの部分を共通化し、どの部分をカスタマイズ可能にするかを見極めます。個社ごとにワークフローが異なるため、カスタマイズはゼロにはなりませんが、その比率を下げていきながら顧客に価値を提供できるプラットフォームを開発することがミッションです。プラットフォーム開発だけでも、仕様検討の段階から非常に抽象度の高い思考が求められ、柔軟性のあるアーキテクチャを設計することはエンジニアとして大きな挑戦であると考えています。
一方で、個別開発を行う「カスタマーエンジニアリングチーム」は、各社のドメイン業務に深く向き合います。需要予測や在庫最適化アルゴリズムの結果が業務の中でどう位置づけられるのか、なぜその数値になったのかという説明性まで含めて機能設計を行うため、深い要件定義が求められます。

ー インフラサイドのチャレンジについても教えてください。
扱うデータは膨大で、何万、何十万という商品のレコードが日次や週次で更新されます。これを素早く分析・表示させるためのパフォーマンス設計はもちろん、大量のデータを扱う中でのシステムの可用性やバッチ処理の設計など、インフラ面での課題は山積みです。各プロダクト間でデータをスムーズに流すためのデータ基盤設計は、バックエンドやフロントエンドと連携して進める必要があり、非常にやりがいのある領域です。

ー 先日記事でも紹介した「FDE」のポジションについても伺えますか。
プロダクトデリバリー責任者（FDE）は、プラットフォームチームとは逆に、特定の顧客に深く入り込みます。顧客独自のワークフローを活かしつつ、どうForecastXを導入するかを設計する役割です。生成AIを活用してコード生成ができるようになった今、顧客と対話してニーズを把握して要件に落とすことができるPdMのようなバックグラウンドを持つ人が自らAPIを叩くコードを生成してデータを加工したり、逆に顧客に近いところで現場の課題を吸い上げ、プラットフォーム側にフィードバックしたり。上流の企画から実装、デリバリーまで責任を持つ、フルスタックなスキルが求められます。エンジニアのスキルを磨きつつ、顧客の課題解決を最前線で感じたい方にはぴったりだと感じています。

ー 続いて、AIデータサイエンティストはどうでしょうか。
整形されていない現場の知見や販促活動の記録など、顧客が持つ多様なデータをどう活用し、在庫削減に繋げるかという需要予測や供給予測といったモデル構築、在庫や生産の最適化アルゴリズムの開発がミッションになってきます。生成AIとタッグを組むことで、手法の選定からプロトタイプの実装までをスピーディーに行えるようになっていきます。新しいAIやツールをスピーディーに試しながら、データ特性の分析からAIと一緒に進めていくという、新しいスタイルを経験できると考えています。

ー AzitでのAIデータサイエンティストの業務は、顧客の商品特性を理解するプロセスそのものに価値がありますよね。大量のアルゴリズム開発を効率化するために、自社の業務自体をAI駆動にしていく試みも面白い。AIを駆使してデータサイエンスの生産性を極限まで高めることに興味がある方には嬉しい環境だと思います。

ドメインにディープダイブし、技術でビジネスを駆動するチームの在り方

ー 今後のプロダクトの成長サイクルについても教えてください。
今後は、半年ごとに新プロダクトを立ち上げるようなスピード感で、サプライチェーンマネジメントの各段階に対応したプロダクトを展開していく予定です。各プロジェクトをリードする人材が必要ですし、現場の声をプロダクトに反映させていくプロセス自体がこれからのAzitの大きな挑戦になります。

ー これからの時代、AIネイティブなプロダクトに携わるキャリアはますます重要になるはずです。ForecastXが進化していくと、社会にはどのような影響を与えられるのでしょうか。
プラットフォームに意思決定のログが蓄積されていくと、これまでExcelの外側で行われていた人間の判断をAIが学習できるようになります。今は人間がハンドルを握っていますが、将来的にはAIが大部分の業務を代行し、人間は最終的な承認を行うだけで済むようになります。ナレッジワークのあり方そのものを変え、世の中の業務効率を劇的に向上させることが我々の目指す姿です。

ー CTOとして、どのような開発組織にしていきたいと考えていますか。
これからの時代、AIがコーディングを代替していくからこそ、顧客の課題にディープダイブできる人の価値が高まります。私自身も商談に同席して生の声を聞くようにしていますが、エンジニアも積極的に現場を知り、物流・SCMの未来がどうあるべきかという意見を交わしながら、より良いプロダクトを磨き合えるチームにしていきたいですね。

ー ForecastXの開発では「Go」を採用していますが、背景について教えてください。
マルチプロダクト化を進めるにあたって、技術選定を改めて見直しました。モノレポ構成や複数のプロダクトが協調して動くAPIの構築において、Goの実績と特性が適していると判断しました。また、Ruby on RailsでDeliveryXを開発してきた経験から、事業ドメインの進化に合わせてデータベースとプログラムを柔軟に切り離して運用できるGoの構成が、長期的な小回りの良さに繋がると考えたのも理由の一つです。

ー Railsと比較して、Goの利点はどこにありますか。
Goは自分で書く分量が多い分、データとロジックを明示的に分離して設計する必要があります。初期の開発スピードはRailsが勝るかもしれませんが、顧客ごとに異なる要件を学んでテーブル設計を微調整していくようなフェーズでは、この分離が功を奏します。また、生成AIにコード生成をさせる際、構文の自由度が少ないGoの方が、一貫性のあるコードを出力しやすいという仮説もあります。

ー AI駆動開発の時代において、コードを書くことよりも「コードを読む・レビューする」ことの重要性が増しています。Goの読みやすさはそこでも活きそうですね。
そうですね。当然ですが、AIによってコードの「生産量」は劇的に増えています。1日1000行といったレベルではなく、大量に生成されるコードをいかに適切にレビューし、取り込んでいくかが生産性のボトルネックになります。初見でもロジックが追いやすいGoは、レビューコストの削減に大きく寄与すると感じています。

ー 今後開発チームとして、どのようなマインドの方に入社していただきたいですか。
特定の技術に固執するのではなく、顧客の課題に向き合うことや、社内での議論に前向きな方がいいなと思っています。

ー 最後に、今年の開発組織の抱負を聞かせてください。
マルチプロダクトを立ち上げ切り、意思決定レイヤーのAIエージェントにつなげていくことが、会社全体としての最大のチャレンジです。スタートアップとして日々の挑戦を楽しみながらも、この1年はこのミッションに対して信念を持ってやり切る。そこに全力で取り組める組織でありたいです。AIを使った開発で生産性を上げることにも、会社としても予算を投じて環境を整えていく覚悟です。

聞き手：吉兼周優　編集：坂井華子

採用情報

Azitでは、各エンジニア職種で採用を行っております。詳細は、以下のページをご覧ください。
https://herp.careers/v1/azitinc