1. はじめに
前回作ったチャットボット型の競馬予想アプリに続いて、今回はワークフロー型の料理レシピ生成アプリを作ってみた。
「レシピ生成アプリ」の開発を通して、対話型AIにはない「システム開発」としての面白さと難しさを感じた。
本記事では、開発プロセスで直面した課題と、そこから得た「AIを仕組み化する」ための知見をまとめる。
2. 開発したアプリの概要
機能: ユーザーが入力した「食材」と「ターゲット（誰向けか）」に合わせて、最適なレシピを提案する。
使用モデル: Gemini 2.5 Flash
構成: 開始ノード（変数入力）→ LLMノード（レシピ生成）→ 終了ノード
3. 直面した最大の壁：contents are required エラー
開発中、最も苦戦したのがLLMノードへの変数の受け渡しだった。 プロンプト内に正しく {{#ingredients#}} などの変数を配置しているはずなのに、実行すると「中身が空である」とエラーを吐かれる。
判明した原因と解決策
モデルの癖: 特にGemini等の特定モデルでは、SYSTEMプロンプトではなくUSERプロンプトに変数を配置しないと認識されないケースがあることが分かった。
4. 「検索」や「チャット」と何が違うのか？
①再現性（プロンプトの固定）
チャットは聞き手に依存するが、Difyは「プロの料理家」という役割や出力形式を固定（カプセル化）するため、誰が使っても同じ品質が得られる。
②構造化と自動化
検索結果はバラバラだが、AIワークフローなら「特定の形式」で出力させることができ、それをさらにPythonなどのプログラムへ繋いで自動処理できる。
③拡張性
単なる回答で終わらず、「レシピをカレンダーに登録する」「材料をLINEに送る」といった外部連携への発展性がある。
5. エンジニアとしての学び
SYSTEMとUSERの使い分け: AIの「人格・ルール」はSYSTEMに、「動的なデータ」はUSERに配置するのが、Geminiのルールっぽい。
デバッグの思考: 「手順通りなのに動かない」時、モデルの仕様やUIの保存タイミングなど、システム全体を疑う視点が必要。
6. おわりに
今回はワークフロー型アプリを作ってみた。ブロック（ノード）は特定の機能・役割を持っており、それを繋げることでデータの流れのパイプラインを作る。視覚的に整理されており、直感的というか感覚的に構造を把握して設計できることが開発の敷居を下げているように感じた。開発中にテスト実行したとき、どこのブロックで問題が起きているかが一目でわかることも開発の敷居を下げていると感じた。
ワークフロー型アプリはLLMブロックとPythonブロックを繋げることでAIの生成結果を設計者が制御できることが大きなメリットであり、AIの柔軟性にプログラムの正確性という厳密なルールを追加することで再現性があり、安定した回答を得られるメリットがある。
また、各ブロックが独立しているため、あとからプロンプトの追加や修正、モデルの変更、前処理（Python）の追加が容易な点も大きなメリットだと感じた。
これはAI先生が教えてくれたが、どのブロックにどんなデータが入り、どう加工されて出ていったのかを「デバッグモード」で追えるため、ブラックボックス化しがちなAI開発において圧倒的にデバッグが楽になるというデータのトレーサビリティという点でも優れているらしい。
完成したワークフローはテンプレート化して再利用でき、また、ブロックも部品として再利用できるため、様々な開発を続けていくことでどんどん効率的でスピーディな開発ができる。
今回はかなり簡単な工程で料理レシピの生成アプリを作ってみたが、今後は、出力されたレシピの妥当性をPythonノードで検証する機能を実装したり、カロリー計算や食材の画像解析機能、言語翻訳機能、特定のレシピ本などを参照するナレッジ連携(RAG)、AmazonやLINEなどの外部サービスとの連携を加えてみようと思う。