前回（第52話）、私たちはついに「DifyからGoogleスプレッドシートへデータを自動保存」することに成功しました。 あの感動、覚えていますか？
今回は、そのシステムをさらに進化させます。
皆さんは、こんな悩みありませんか？
- ブログ記事は「3,000文字で論理的に」書きたい。
- X（旧Twitter）は「140文字でエモく」書きたい。
これらをやるために、わざわざ**「ブログ用アプリ」と「X用アプリ」の2つを作って、スプレッドシートも2つ用意する……。** 正直、管理がめんどくさいですよね？
今日は、たった1つのアプリで、スイッチひとつで「真面目なブログ」と「陽気なSNS」を切り替え、**そのどちらの結果も、同じスプレッドシートに自動保存する「二刀流AI」**を作ります。
第31話で習った「条件分岐（IF/ELSE）」の実践編です！ ……と言いたいところですが、実はこの先に**「スプレッドシートに保存できない！？」というとんでもない落とし穴**が待っています。 今日はそこまでご案内します。
ステップ1：入り口に「スイッチ」と「テーマ」を作る
まずは、アプリの入り口である「開始（Start）」ブロックを設定します。 ここで必要なのは、**「①どのモードで書くか（スイッチ）」と「②何について書くか（テーマ）」**の2つです。
1. 「作成モード」スイッチを作る
まず、一番左にある**「開始」ブロックをクリックします。 右側の設定画面にある「入力フィールド」の「＋追加」から「セレクト（選択）」**を選びます。
- ラベル名：
作成モード - 変数キー：
mode（小文字の英語で入力） - オプション：
BlogSNS
- 必須： チェックを入れる
これでスイッチは完成ですが、これだけだと「何について書くか」を入力する場所がありません。
2. 「書きたいテーマ」欄を作る
もう一度**「＋追加」を押し、今度は「テキスト（段落）」**を選びます。
- ラベル名：
書きたいテーマ - 変数キー：
query（またはtopic） - 必須： チェックを入れる
これで、ユーザーは「キャンプ（テーマ）」について「ブログモード（モード）」で書いて！ と命令できるようになりました。準備完了です！
ステップ2：運命の分かれ道（IF/ELSE）
次に、選んだスイッチによって、AIの処理ルートを二手に分けます。 ここで登場するのが、おなじみ**「条件分岐（IF/ELSE）」**ブロックです。
- 開始ブロックの後ろにある「＋」を押して、**「条件分岐」**を追加します。
- 条件を次のように設定します。
- 変数： さっき作った
modeを選びます。 - 条件：
Blogと、である (equals)
これで、
- IF（真）の道：ブログを選んだ人が通るルート（上）
- ELSE（偽）の道：SNSを選んだ人が通るルート（下）
この2つに道が分かれました。線路のポイント切り替え完了です！
ステップ3：脳みそを2つ用意する
分かれた道の先に、それぞれ「専用のAI（LLM）」を配置します。 ここで重要なのは、**「AIに何を読ませるか」**です。
上の道（ブログ用）
- 上の分岐（IF）の先にLLMブロックを追加し、名前を「ブログライター」に変更します。
- コンテキスト：
開始>query（書きたいテーマ）を選択。 - SYSTEM（役割設定）：Plaintext
あなたはプロのSEOライターです。 ユーザーのテーマに基づき、読者の検索意図を満たす論理的な記事を3,000文字程度で執筆してください。 口調：丁寧語（です・ます） - USER（命令文）： ここが超重要です！ ここには**「書きたいテーマ」を入れます。 入力欄の
{x}を押し、開始>query** を選んで入れてください。 （※間違ってmodeを入れないように注意！ AIが「Blogについて書いて」と勘違いしてしまいます）
下の道（SNS用）
- 下の分岐（ELSE）の先にLLMブロックを追加し、名前を「SNSライター」に変更します。
- コンテキスト：
開始>queryを選択。 - SYSTEM（役割設定）：Plaintext
あなたは人気インフルエンサーです。 ユーザーのテーマについて、共感を呼ぶエモい投稿を作成してください。 文字数：140文字以内 絵文字：多めに使用 ハッシュタグ：3つ提案 - USER（命令文）： こちらも同様に、
開始>queryを入れます
これで、上の道を通れば「指定したテーマの長文」が、下の道を通れば「指定したテーマの短文」が生成されるようになりました。 完璧な「二重人格AI」の誕生です！
ステップ4：【緊急事態】出口がない！？
さあ、いよいよ最後の仕上げです。 この生成された文章を、前回作った**「スプレッドシート保存ブロック（HTTPリクエスト）」**に渡して保存しましょう。
……おや？ ここで深刻な問題が発生します。
試しに、「HTTPリクエスト」ブロック（または終了ブロック）を1つ置いてみてください。 そして、「保存するデータ（Body）」を選ぼうとしたとき、あなたは絶望するはずです。
- 選択肢A：上の「ブログライター」のテキストを選ぶ？
- 選択肢B：下の「SNSライター」のテキストを選ぶ？
もし「A（ブログ）」を選んで設定したとします。 すると、SNSモードで実行したとき（下の道を通ったとき）、Aの箱は空っぽなので、スプレッドシートには何も保存されません（エラーになります）。
逆も同じです。「B（SNS）」を選んだら、ブログモードの時に保存されません。
「道は2つあるのに、スプレッドシートへの入り口は1つしかない！！」
これでは保存ができません。 まさか、「ブログ用保存ブロック」と「SNS用保存ブロック」を2つ作りますか？ 今回は2つだから良いですが、もし分岐が10個になったら……設定を10回繰り返すことになります。想像しただけで地獄ですね。
次回予告：バラバラの道を束ねる「魔法」
どうしましょう。 せっかく「二刀流アプリ」を作ろうとしたのに、最後の最後で「合流」できずに詰んでしまいました。
実は、この問題はDifyを使っていると必ずぶつかる**「分岐の壁」です。 しかし、安心してください。Difyには、この状況を打破するための「専用ブロック」**が用意されています。
その名は……「変数集約器（Variable Aggregator）」！
名前はゴツイですが、機能は「バラバラになった道を、魔法のように一本に束ねる」という超・便利なものです。 これさえあれば、どんなに複雑に分岐しても、スプレッドシートへの入り口はいつもひとつ！
次回、この魔法のブロックを使って、迷子になったデータを華麗に救出し、スプレッドシートへの完全自動保存を実現します。 これであなたも「ワークフロー設計」のプロになれますよ。
【次回の予告】 第54話：【解決編】バラバラの道を束ねる魔法！「変数集約器」で二刀流アプリを完成させよ
これを使えばワークフローがシンプルになるのと
何が不具合があったときに修正が楽になると思います。是非お楽しみに！
コメント