味の素が1万件超のレシピから開発、好みの献立を自動で作るAIサービスの裏側

出発点にあったのは、データが足りないという悩みではなく、その逆でした。長年の製品開発と研究開発で積み上げた栄養の知見、そして膨大なレシピデータがすでに手元にあり、それをどう顧客価値につなげるかが定まっていない状態だったと読み取れます。

課題を「データ活用の模索」という言い方で終わらせず、料理をする人が実際に困っている場面、つまり献立を組み立てる場面まで具体化できたかどうかが分かれ目だったのではないでしょうか。データ活用のプロジェクトが動き出さない理由は、技術力よりも「誰のどの瞬間の困りごとに当てるか」が決まっていないことにあります。レシピという素材は、一品単位で見れば検索や閲覧の対象にすぎませんが、複数を組み合わせる献立という単位に置き換えた途端、栄養バランスや好みという制約を扱う問題に変わります。この課題の置き換えそのものが、取り組みの土台になったと考えられます。

効いたのは、献立作成を「人が無意識に守っているルールまで含んだ条件充足の問題」として定義し直した点だと考えられます。単にレシピを複数並べるだけでは献立になりません。栄養バランスを取ることに加えて、品数がちょうどよいか、和洋中のジャンルがちぐはぐになっていないかといった、人が意識せず判断している要素を条件として扱う必要があります。ここを曖昧にしたまま作ると、栄養計算上は正しいのに食卓に並べると違和感のある組み合わせが出てきてしまう。守るべき条件を具体的に洗い出して設計に落とし込む工程が、実用に足る品質の分かれ目になったはずです。

第二に、条件の入り口を運動習慣や減塩ニーズ、嫌いな食材といった個人ごとの要望まで広げた設計です。汎用の献立をひとつ出すのではなく、条件を指定するとそれを満たす組み合わせが返る形にしたことで、同じエンジンが幅広い利用者の事情に対応できます。1万件を超えるレシピデータという母数の大きさは、条件を厳しくしても候補が枯れないという意味で、この設計を成り立たせる前提として機能していると見られます。

第三に、構想検討から初期開発、テストマーケティング、サービス化開発、そしてサービス提供までを一続きのプロセスとして進め、そこにLaboro.AI側が長期で伴走したという進め方です。試作を作って終わるのではなく、市場での反応を確かめる段階を明示的に挟んでから本格的なサービス化開発に入る組み立てになっており、技術検証と事業判断を切り分けずに並走させています。さらにエンジンを味の素以外のサービスとも連携できる形にし、提供者側が自社ユーザーに合わせて条件をあらかじめ指定できるようにした点も、ひとつの用途に閉じない資産として設計する考え方の表れでしょう。

開発された献立作成エンジンは、好きなメニューと栄養バランスを考慮した献立を提案する味の素のWebサービスに実際に使われており、構想段階の検討から実サービスでの提供まで到達しています。加えて、同社以外のサービスとも連携でき、提供者側が自社ユーザーに適した条件を事前に指定できる仕組みになっています。自社データを起点にした取り組みが、一度きりの試作ではなく外部にも開ける形の資産として残った点に意味があると考えられます。