こんにちは、学びの探求者です。

普段はnoteで活動しています。

2025年のQiitaアドベントカレンダーでは、
「ノーコード／ローコードで、自分のコンテンツ基盤を自動化していく」
をテーマに、25日間の仕組みづくりを記録していきます。
ぜひ、応援してください。

昨日の Day6 では、複数URLをスクレイピング → LLM解析 → Google スプレッドシートへ追記のフル自動化パイプラインを組みました。

今日はこの中でも特に重要だった「イテレーションを使った API連携の基本パターン」を整理します。

今日の目的

Dify のイテレーションを使うときの「万能パターン」を理解すること。

このパターンは次のような処理にそのまま使えます。

・複数URLスクレイピング
・配列データを1件ずつAPIに送る
・文章の一括分類／翻訳／要約
・Notion / Slack / Google Sheets への連続書き込み
・データ加工のバッチ処理

イテレーションの本質とは？

イテレーションは一言でいうと、

「配列（Array）を “1件ずつの単体処理” に分解する装置」

です。

Day6 では、この仕組みを使ったことで、

・URLを1件ずつスクレイプ
・1件ずつLLMで構造化
・あとで全件まとめてスプレッドシートへ

という処理が可能になりました。

今回は Day6 の内容を抽象化して、
次のような “汎用パターン” に落とし込みました。

【基本構造】
1）配列データを作る（Code）
2）イテレーションで1件ずつ処理する
3）1件ずつスクレイプ／解析／API送信
4）全件終了後にまとめて整形（Code）
5）Sheets / Notion / Slack などにまとめて書き込み

これは自動化の世界でいう「ETL（抽出・変換・ロード）」そのものです。

テキストを改行で分割して配列化するだけで、イテレーションが使えるようになります。

例：
“URLやIDが複数行で渡されてくる想定”

文字列を改行で split → 空行除去 → List にするだけ。

これでイテレーションに渡せる「Array[String]」が完成します。

イテレーションノードは

・items（配列）の1つめ
・2つめ
・3つめ
…

という順番で “単体処理” に変換してくれます。

Day6 では、これにより

「URLを1件ずつスクレイプ → LLM解析」

が実現できました。

Day6 で苦労したのはここでした。

・イテレーションの出力（object型）は Batch Update に渡せない
・LLM の出力（array型）もそのままだと JSON が壊れる
・range は動的に作らないと上書きされる

この3つの制約を攻略したことで、

「URLが何件あっても、スプレッドシートに“追記”できるワークフロー」

が完成しました。

この”中間変換（ETL）”の考え方がわかると、
Notion / Slack / DB 連携にもそのまま応用できます。

・イテレーションは「配列 → 単体処理」への変換装置
・単体処理の中ではスクレイプ、LLM、API送信など何でもできる
・全件終了後に整形＆まとめて書き込みが鉄板パターン
・Day6 のワークフローは、ETL のフル実装だった
・この理解があると、今後の自動化がどんどん簡単になる

明日以降はこのパターンを使って、さらに広い自動化に挑戦していきます。
読んでいただきありがとうございました。