こんにちは、学びの探求者です。
普段はnoteで活動しています。
2025年のQiitaアドベントカレンダーでは、
「ノーコード／ローコードで、自分のコンテンツ基盤を自動化していく」
をテーマに、25日間の仕組みづくりを記録していきます。
ぜひ、応援してください。
昨日の Day6 では、複数URLをスクレイピング → LLM解析 → Google スプレッドシートへ追記のフル自動化パイプラインを組みました。
今日はこの中でも特に重要だった「イテレーションを使った API連携の基本パターン」を整理します。
今日の目的
Dify のイテレーションを使うときの「万能パターン」を理解すること。
このパターンは次のような処理にそのまま使えます。
・複数URLスクレイピング
・配列データを1件ずつAPIに送る
・文章の一括分類／翻訳／要約
・Notion / Slack / Google Sheets への連続書き込み
・データ加工のバッチ処理
イテレーションの本質とは？
イテレーションは一言でいうと、
「配列（Array）を “1件ずつの単体処理” に分解する装置」
です。
Day6 では、この仕組みを使ったことで、
・URLを1件ずつスクレイプ
・1件ずつLLMで構造化
・あとで全件まとめてスプレッドシートへ
という処理が可能になりました。
API連携の「基本パターン」
今回は Day6 の内容を抽象化して、
次のような “汎用パターン” に落とし込みました。
【基本構造】
1）配列データを作る（Code）
2）イテレーションで1件ずつ処理する
3）1件ずつスクレイプ／解析／API送信
4）全件終了後にまとめて整形（Code）
5）Sheets / Notion / Slack などにまとめて書き込み
これは自動化の世界でいう「ETL（抽出・変換・ロード）」そのものです。
1）配列データを作る（Codeノード）
テキストを改行で分割して配列化するだけで、イテレーションが使えるようになります。
例：
“URLやIDが複数行で渡されてくる想定”
文字列を改行で split → 空行除去 → List にするだけ。
これでイテレーションに渡せる「Array[String]」が完成します。
2）イテレーションで1件ずつ処理する
イテレーションノードは
・items（配列）の1つめ
・2つめ
・3つめ
…
という順番で “単体処理” に変換してくれます。
Day6 では、これにより
「URLを1件ずつスクレイプ → LLM解析」
が実現できました。
3）後段でまとめて整形する（Code）
Day6 で苦労したのはここでした。
・イテレーションの出力（object型）は Batch Update に渡せない
・LLM の出力（array型）もそのままだと JSON が壊れる
・range は動的に作らないと上書きされる
この3つの制約を攻略したことで、
「URLが何件あっても、スプレッドシートに“追記”できるワークフロー」
が完成しました。
この”中間変換（ETL）”の考え方がわかると、
Notion / Slack / DB 連携にもそのまま応用できます。
今日のまとめ
・イテレーションは「配列 → 単体処理」への変換装置
・単体処理の中ではスクレイプ、LLM、API送信など何でもできる
・全件終了後に整形＆まとめて書き込みが鉄板パターン
・Day6 のワークフローは、ETL のフル実装だった
・この理解があると、今後の自動化がどんどん簡単になる
明日以降はこのパターンを使って、さらに広い自動化に挑戦していきます。
読んでいただきありがとうございました。