🍳

AI時代のプロダクトは「固定された成果物」ではなく「可能性の束」になる !? - Cookflowを作った

に公開

作ったもの

Cookflow という料理支援アプリを作りました。
Cookflowの入力画面

https://github.com/geeknees/Cookflow

材料、制約、気分、スキル、使える道具を入力すると、その場でレシピ候補を出してくれます。調理を始めたあとも、困ったことがあれば質問できます。

ただのレシピ検索アプリではありません。

既にあるレシピを探すのではなく、その人の状況に合わせて、料理の進め方そのものを組み立て直していく。Cookflow ではそこを試しています。

背景にある考え

今回作りたかったのは、次の考えを小さく試すためのアプリです。

AIにより、プロダクトは固定された成果物ではなく、ユーザーと共創され続ける動的な可能性の束になる。

https://www.oreilly.com/radar/conviction-collapse-and-the-end-of-software-as-we-know-it/

これまでのプロダクトは、多くの場合「作り手が完成形を決め、ユーザーがそれを使う」ものでした。

レシピアプリなら、あらかじめ登録されたレシピがあり、ユーザーはそこから検索します。でもAIが入ると、プロダクトの性質を変えることができます。

ユーザーの入力、状況、制約、好み、その場の判断によって、返ってくる体験が変わる。プロダクトは固定された画面や機能の集まりというより、ユーザーごとに開かれる可能性の束に近づいていきます。

Cookflowでは、それを料理という身近な領域で試しました。

なぜ料理なのか

料理は、思った以上に「その場で調整する」、プロセス的な行為です。

  • 冷蔵庫にある材料が毎回違う
  • 使える道具が違う
  • 時間がない日もある
  • 気分によって食べたいものが変わる
  • 調理中に焦げる、味が薄い、材料が足りない、といったズレが起きる

料理は、最初から最後まで固定レシピどおりに進むとは限りません。その場でササッと作りたいだけなのに、レシピを調べて、材料が足りないことに気づいて、買い物に行く。これはかなり億劫です。

むしろ現実の料理は、手元にある材料や時間に合わせて、その場で判断し続ける作業です。だからAIと相性がよさそうだと思いました。

主な機能

MVPとして、以下を実装しました。

  • 材料、人数、時間、気分、スキル、道具、避けたい材料、メモを入力
  • AIがレシピ候補を3件生成
  • 候補ごとに概要、時間、難易度、使う材料、足りない材料を表示
  • レシピ詳細で材料、手順、代替案、コツ、注意点を表示
  • 調理中に質問できるチャット
  • 作ったあとに評価とメモを保存
  • 過去に生成・調理した履歴を表示

Cookflowのレシピ調理中画面

意識したのは、「生成して終わり」にしないことです。

料理は、作り始めてからズレが出ます。焦げそう、味が薄い、材料が足りない、手順を少し変えたい。そういう場面に対応したかったので、調理中に質問できる Cooking Session を用意しました。

技術構成

技術スタックはシンプルです。

  • Ruby on Rails
  • Hotwire / Rails views
  • SQLite(ローカルMVP)
  • OpenAI Ruby SDK
  • OpenAI Responses API
  • Structured Outputs
  • AIレスポンスはJSONとして検証して保存

AI連携は service object に閉じ込めています。

レシピ生成は AiRecipeGenerator、調理中の相談は AiCookingAdvisor が担当します。

開発・本番では OpenAI provider を使い、テストでは mock provider を使う構成にしました。

AiRecipeGenerator.new.generate(recipe_request)

OpenAIの出力は、そのまま保存しません。必ずJSONとしてパースし、必要な項目がそろっているか確認してから保存します。

肉・魚・卵が含まれる場合は、食品安全の注意を必ず含めるようにしています。料理アプリとして、ここは雑にしたくありませんでした。

作ってみて感じたこと

AIアプリを作るとき、「AIで何かを生成する」だけだと、従来のフォームアプリに生成ボタンを足しただけになりがちです。

今回意識したのは、AIを「一回だけ答えを出す装置」としてではなく、ユーザーと一緒にプロセスを進める相手として扱うことでした。

レシピも、完成済みのコンテンツではありません。

  • 最初の材料入力
  • 候補生成
  • 選択
  • 調理中の相談
  • 完了後の評価
  • 履歴

この流れの中で、少しずつユーザーに合わせて意味を持っていきます。

この構造は、料理以外にも使えそうです。

たとえば、学習、旅行計画、業務手順、文章作成、健康管理。どれも、固定コンテンツを渡すより「状況に応じて変化するプロセス」として設計したほうが自然な場面があります。

まとめ

Cookflowは小さなMVPですが、試したかったテーマはそれなりに大きいものでした。

AIによって、プロダクトは完成品を提供するものから、ユーザーと一緒に変化し続けるものへ変わっていく。

その変化を、料理という日常的な体験で実装してみました。

まだ粗い部分はあります。ただ、AI-firstなプロダクト設計を考えるための実験としては、十分に得るものがありました。このアプリをすぐサービスとして成立させるというより、まずはコンセプトの実装例として見ています。

AI時代のプロダクトは「固定された成果物」ではなく「可能性の束」になる。皆さんはどう思いますか。

Discussion