1. はじめに

Difyのワークフローで業務アプリを作っていると、実行結果をExcelで出力したくなる場面があります。

例えば、以下のようなケースです。

AIが作成した一覧表をExcelで出したい
工程表やWBSのような帳票を出力したい
社内業務で使える .xlsx ファイルを生成したい
ただしサードパーティープラグインは使えない
外部APIサーバも用意できない

今回、Dify v1.13.3のセルフホスト環境で、DifyだけでExcelファイルを生成できるのかを検証しました。

結論としては以下です。

やりたいこと	結果
DifyのCodeノードでExcelデータを生成する	できた
`.xlsx` ファイルの中身を作る	できた
Base64として出力する	できた
ローカルで `.xlsx` に復元して開く	できた
DifyのOutputノードでFile型として返す	できなかった
Dify上にダウンロードボタンを表示する	未達

つまり、

DifyだけでExcel生成はできるが、DifyのFile型として返すところに壁がある

という結果でした。

この記事では、そこに至るまでの検証過程をまとめます。

2. 検証環境

今回の環境は以下です。

項目	内容
Dify	v1.13.3
実行方式	Self-hosted / Docker Compose
Docker	Docker version 24.0.7
Docker Compose	v2.23.0
OS	macOS
Python	Dify Sandbox上のPython 3.14.3

DifyはDocker Composeで起動しています。

cd ~/dev/dify/docker
docker compose up -d

3. やりたかったこと

最終的には、以下のようなExcel帳票をDifyから出力したいと考えていました。

セル結合
背景色
罫線
列幅調整
ヘッダー装飾
工程表やWBS風の表

イメージとしては、業務システムでよくある以下のような帳票です。

カテゴリ | タスク | 担当 | 予定開始 | 予定終了 | 実績開始 | 実績終了 | 工数

このような帳票を、Difyワークフローの出力として .xlsx で返せないかを検証しました。

4. まずはopenpyxlを使えるか確認

Excel生成といえば、Pythonでは openpyxl がよく使われます。

そこで、まずDifyのCodeノードで openpyxl をimportできるか確認しました。

def main() -> dict:
    try:
        import openpyxl

        return {
            "ok": "true",
            "version": openpyxl.__version__
        }
    except Exception as e:
        return {
            "ok": "false",
            "error": str(e)
        }

最初は以下のエラーになりました。

No module named 'openpyxl'

Dify Sandboxには、デフォルトでは openpyxl が入っていないようです。

5. Dify Sandboxにopenpyxlを追加する

DifyのDocker環境では、sandbox用の依存関係を以下に追加できます。

cd ~/dev/dify/docker

volumes/sandbox/dependencies/python-requirements.txt に openpyxl を書き込みます。

printf "openpyxl\n" > volumes/sandbox/dependencies/python-requirements.txt

その後、sandboxを再起動します。

docker compose restart sandbox

ログを確認します。

docker compose logs sandbox --tail=200

以下のようなログが出れば成功です。

Successfully installed et-xmlfile-2.0.0 openpyxl-3.1.5

再度Codeノードで確認すると、以下の結果になりました。

{
  "ok": "true",
  "version": "3.1.5"
}

openpyxl のimportには成功しました。

6. openpyxlでExcelを生成してみる

次に、DifyのCodeノード上でExcelファイルをメモリ上に保存できるか確認しました。

def main() -> dict:
    from io import BytesIO
    from openpyxl import Workbook

    wb = Workbook()
    buffer = BytesIO()
    wb.save(buffer)

    return {
        "size": len(buffer.getvalue())
    }

しかし、ここで以下のエラーが出ました。

operation not permitted

7. sandboxコンテナ内で直接実行すると成功する

原因を切り分けるため、sandboxコンテナに直接入りました。

docker exec -it docker-sandbox-1 bash

Pythonを起動し、同じ処理を実行します。

from openpyxl import Workbook
from io import BytesIO

wb = Workbook()
buffer = BytesIO()
wb.save(buffer)

こちらは成功しました。

つまり、問題は openpyxl そのものではありません。

整理すると以下です。

検証	結果
sandboxコンテナ内で直接 `wb.save(buffer)`	成功
Dify Codeノード上で `wb.save(buffer)`	失敗
エラー	operation not permitted

このことから、Dify Codeノード実行時の制限により、openpyxlの保存処理がブロックされていると考えました。

8. zipfileは使えるのか確認する

.xlsx は実体としてはZIP形式です。

そこで、Dify Codeノード上で zipfile が使えるか確認しました。

def main() -> dict:
    from io import BytesIO
    import zipfile

    buffer = BytesIO()

    with zipfile.ZipFile(buffer, "w", compression=zipfile.ZIP_DEFLATED) as z:
        z.writestr("test.txt", "hello")

    return {
        "size": len(buffer.getvalue())
    }

結果は成功でした。

つまり、

openpyxlの保存処理は失敗する
zipfileでZIPを作ることはできる

という状態です。

9. xlsxの中身を自作する方針に切り替える

.xlsx はざっくり言うと、以下のようなXMLファイル群をZIPにまとめたものです。

dify_excel_test.xlsx
├── [Content_Types].xml
├── _rels/
│   └── .rels
└── xl/
    ├── workbook.xml
    ├── styles.xml
    ├── _rels/
    │   └── workbook.xml.rels
    └── worksheets/
        └── sheet1.xml

そのため、

XMLを文字列で作る
↓
zipfileで固める
↓
Base64化する
↓
Difyの出力に返す

という方針に切り替えました。

10. 最小構成のxlsxを作成する

以下は、Dify Codeノード上で .xlsx を生成し、Base64として返す最小サンプルです。

出力変数は以下のように設定します。

変数名	型
filename	string
size	number
base64_xlsx	string
error	string

コードは以下です。

def main() -> dict:
    import base64
    import traceback
    from io import BytesIO
    import zipfile

    try:
        content_types = '''<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
  <Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>
  <Default Extension="xml" ContentType="application/xml"/>
  <Override PartName="/xl/workbook.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml"/>
  <Override PartName="/xl/worksheets/sheet1.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/>
  <Override PartName="/xl/styles.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.styles+xml"/>
</Types>'''

        rels = '''<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="xl/workbook.xml"/>
</Relationships>'''

        workbook = '''<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workbook xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"
 xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">
  <sheets>
    <sheet name="検証" sheetId="1" r:id="rId1"/>
  </sheets>
</workbook>'''

        workbook_rels = '''<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
  <Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet" Target="worksheets/sheet1.xml"/>
  <Relationship Id="rId2" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/styles" Target="styles.xml"/>
</Relationships>'''

        styles = '''<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<styleSheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
  <fonts count="2">
    <font><sz val="11"/><name val="Calibri"/></font>
    <font><b/><sz val="16"/><color rgb="FFFFFFFF"/><name val="Calibri"/></font>
  </fonts>
  <fills count="3">
    <fill><patternFill patternType="none"/></fill>
    <fill><patternFill patternType="gray125"/></fill>
    <fill><patternFill patternType="solid"><fgColor rgb="FF2F9E52"/><bgColor indexed="64"/></patternFill></fill>
  </fills>
  <borders count="2">
    <border><left/><right/><top/><bottom/><diagonal/></border>
    <border>
      <left style="thin"><color rgb="FF666666"/></left>
      <right style="thin"><color rgb="FF666666"/></right>
      <top style="thin"><color rgb="FF666666"/></top>
      <bottom style="thin"><color rgb="FF666666"/></bottom>
      <diagonal/>
    </border>
  </borders>
  <cellStyleXfs count="1">
    <xf numFmtId="0" fontId="0" fillId="0" borderId="0"/>
  </cellStyleXfs>
  <cellXfs count="3">
    <xf numFmtId="0" fontId="0" fillId="0" borderId="0"/>
    <xf numFmtId="0" fontId="1" fillId="2" borderId="1" applyFont="1" applyFill="1" applyBorder="1" applyAlignment="1">
      <alignment horizontal="center" vertical="center"/>
    </xf>
    <xf numFmtId="0" fontId="0" fillId="0" borderId="1" applyBorder="1"/>
  </cellXfs>
</styleSheet>'''

        sheet = '''<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"
 xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">
  <sheetViews>
    <sheetView workbookViewId="0" showGridLines="0"/>
  </sheetViews>
  <cols>
    <col min="1" max="1" width="16" customWidth="1"/>
    <col min="2" max="2" width="28" customWidth="1"/>
    <col min="3" max="5" width="14" customWidth="1"/>
  </cols>
  <sheetData>
    <row r="1" ht="28" customHeight="1">
      <c r="A1" t="inlineStr" s="1"><is><t>Dify Excel出力検証</t></is></c>
    </row>
    <row r="2">
      <c r="A2" t="inlineStr" s="2"><is><t>カテゴリ</t></is></c>
      <c r="B2" t="inlineStr" s="2"><is><t>タスク</t></is></c>
      <c r="C2" t="inlineStr" s="2"><is><t>担当</t></is></c>
      <c r="D2" t="inlineStr" s="2"><is><t>開始日</t></is></c>
      <c r="E2" t="inlineStr" s="2"><is><t>終了日</t></is></c>
    </row>
    <row r="3">
      <c r="A3" t="inlineStr" s="2"><is><t>基本設計</t></is></c>
      <c r="B3" t="inlineStr" s="2"><is><t>要件確認</t></is></c>
      <c r="C3" t="inlineStr" s="2"><is><t>担当者A</t></is></c>
      <c r="D3" t="inlineStr" s="2"><is><t>2026/06/13</t></is></c>
      <c r="E3" t="inlineStr" s="2"><is><t>2026/06/14</t></is></c>
    </row>
  </sheetData>
  <mergeCells count="1">
    <mergeCell ref="A1:E1"/>
  </mergeCells>
  <pageMargins left="0.7" right="0.7" top="0.75" bottom="0.75" header="0.3" footer="0.3"/>
</worksheet>'''

        buffer = BytesIO()

        with zipfile.ZipFile(buffer, "w", compression=zipfile.ZIP_DEFLATED) as z:
            z.writestr("[Content_Types].xml", content_types)
            z.writestr("_rels/.rels", rels)
            z.writestr("xl/workbook.xml", workbook)
            z.writestr("xl/_rels/workbook.xml.rels", workbook_rels)
            z.writestr("xl/styles.xml", styles)
            z.writestr("xl/worksheets/sheet1.xml", sheet)

        xlsx_bytes = buffer.getvalue()
        encoded = base64.b64encode(xlsx_bytes).decode("utf-8")

        return {
            "filename": "dify_excel_test.xlsx",
            "size": len(xlsx_bytes),
            "base64_xlsx": encoded,
            "error": ""
        }

    except Exception:
        return {
            "filename": "",
            "size": 0,
            "base64_xlsx": "",
            "error": traceback.format_exc()
        }

11. 出力されたBase64をxlsxに復元する

Codeノードの実行結果として、以下のようなJSONが返りました。

{
  "filename": "dify_excel_test.xlsx",
  "size": 2633,
  "base64_xlsx": "UEsDB..."
}

base64_xlsx の値をコピーして、Macのターミナルで以下を実行します。

pbpaste | base64 -D > dify_excel_test.xlsx

開きます。

open dify_excel_test.xlsx

MacにExcelをインストールしていなくても、Quick Lookで確認できました。

セル結合、背景色、罫線、列幅が反映された .xlsx として開けました。

12. ここまでで分かったこと

この時点で、以下は確認できました。

Dify Codeノード
↓
XML生成
↓
zipfileでxlsx化
↓
Base64出力
↓
ローカルで復元
↓
Excelとして表示

つまり、DifyだけでExcelファイルの中身を生成することは可能です。

13. ではOutputノードでFile型として返せるのか？

ここからが一番気になっていたポイントです。

理想は以下です。

Codeノード
↓
Excel生成
↓
Outputノード
↓
file型
↓
ダウンロードボタン表示

まず、Outputノードで base64_xlsx を file 型として返せるか試しました。

結果はNGでした。

base64_xlsx はあくまで string 型なので、Outputノード上でそのまま file 型にはできませんでした。

14. File型っぽいObjectを返してみる

次に、Codeノードから以下のようなObjectを返しました。

return {
    "excel_file": {
        "type": "file",
        "filename": "dify_excel_test.xlsx",
        "mime_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
        "base64": encoded
    }
}

Output Variablesは以下です。

excel_file: object

結果は以下でした。

{
  "excel_file": null
}

DifyはこのObjectをFile型としては解釈してくれませんでした。

15. DifyのFile型の実体を確認する

次に、ユーザー入力ノードでファイルをアップロードし、Dify内部でFile型がどう見えているのか確認しました。

GUI上で確認できたプロパティは以下です。

type
size
name
url
extension
mime_type
related_id

特に重要なのは url です。

Codeノードに filesample.url を渡すと、以下のような値が取得できました。

/files/{id}/file-preview?timestamp=...&nonce=...&sign=...

つまり、DifyのFile型は単なるBase64文字列ではなく、

Dify内部ストレージに保存されたファイル
+
related_id
+
署名付きpreview URL

として管理されているようです。

16. 最終結果

今回の検証結果をまとめます。

検証項目	結果	備考
openpyxl import	○	依存追加後に成功
Workbook生成	○	Codeノード上で成功
BytesIO生成	○	Codeノード上で成功
openpyxlの `wb.save()`	×	operation not permitted
sandbox内で直接 `wb.save()`	○	コンテナ内では成功
zipfile利用	○	ZIP作成成功
XML直書きによるxlsx生成	○	正常に生成
Base64出力	○	Codeノードから出力可能
ローカルでxlsx復元	○	Quick Lookで確認
Outputノードでfile化	×	string → file変換不可
File風Objectの返却	×	nullになった

17. 結論

今回の検証で、以下のことが分かりました。

DifyだけでExcel生成はできる

openpyxl の保存処理はCodeノード上では失敗しましたが、zipfile とXML直書きを使うことで .xlsx を生成できました。

つまり、

Dify CodeノードだけでExcelファイルの中身を作る

ことは可能です。

DifyのFile型として返すのは難しい

一方で、生成したBase64をOutputノードで file 型に変換することはできませんでした。

また、File型っぽいObjectを返してもDifyには認識されず、null になりました。

DifyのFile型は、内部ストレージに保存されたファイルと署名付きURLで管理されているようです。

そのため、

Base64文字列
↓
Dify File型

という変換は、標準ノードだけでは難しそうです。

18. 今回の到達点

現時点で実現できたのはここまでです。

Dify
↓
Codeノード
↓
xlsx生成
↓
Base64出力
↓
ローカルで復元

一方で、未達なのはここです。

Dify
↓
Codeノード
↓
xlsx生成
↓
Dify File型
↓
ダウンロードボタン表示

19. 今後試したいこと

今回の検証では、DifyのCodeノードだけで .xlsx の中身を生成し、Base64文字列として出力できることまでは確認できました。

一方で、まだ実用化に向けて確認したい論点が残っています。

特に重要なのは以下の2点です。

1. 生成したExcelをDifyのFile型として返せるか
2. Base64文字列として返す場合、どの程度のサイズまで実用に耐えるか

19.1 Dify内部APIを使ってFile型として返せるか

現時点では、Codeノードで生成したBase64文字列を、Outputノードで直接 file 型に変換することはできませんでした。

また、Codeノードから以下のようなFile型風のObjectを返しても、DifyにはFileとして認識されませんでした。

return {
    "excel_file": {
        "type": "file",
        "filename": "dify_excel_test.xlsx",
        "mime_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet",
        "base64": encoded
    }
}

結果は以下のように null になりました。

{
  "excel_file": null
}

このことから、DifyのFile型は単なるJSONやBase64ではなく、Dify内部のファイルストレージに登録されたファイルを related_id や署名付きURLで参照していると考えられます。

そのため、今後は以下の流れを検証したいです。

Codeノード
↓
Excel生成
↓
DifyのUpload File APIへアップロード
↓
file_id取得
↓
HTTP Requestノードでpreview/download APIを呼び出す
↓
HTTP Requestノードのfiles変数として受け取る
↓
Outputノードでfileとして返す

もしこの流れが成功すれば、

Difyのみ
プラグインなし
外部APIなし
Excel生成
ダウンロード可能なFile出力

まで到達できます。

ただし、この検証は少し複雑です。

実際に途中まで試したところ、sandboxコンテナから api:5001 には到達できる一方で、Codeノード内から api の名前解決を行うと timeout や signal: killed が発生しました。

sandboxコンテナ内では以下は成功しました。

api:5001 -> TCP OK
http://api:5001/health -> 200

しかし、Codeノード内ではDNS解決や内部HTTP通信に制限がある可能性があります。

このため、今後検証する場合は、以下の観点で切り分ける必要があります。

1. CodeノードからDify APIへHTTPアクセスできるか
2. apiサービス名ではなくIP直指定なら到達できるか
3. APIキー付きで /files/upload を呼び出せるか
4. アップロードしたファイルを /files/{file_id}/preview で取得できるか
5. HTTP Requestノードがそのレスポンスをfile変数として認識するか

この検証は、Excel生成そのものではなく、Dify内部のFile管理機構に生成済みExcelを登録できるかを確認するものです。

成功すればかなり大きいですが、Codeノードのネットワーク制限やSSRF対策に引っかかる可能性があるため、追加検証が必要です。

19.2 Base64文字列として返せるサイズ上限を確認する

もう1つ確認したいのが、Base64文字列のサイズ上限です。

今回の検証では、Codeノードで .xlsx を生成し、それをBase64文字列として返すことができました。

しかし、DifyのCodeノードには出力文字列の上限があります。

そのため、Excelが大きくなりすぎると、以下のような問題が起きる可能性があります。

Codeノードの出力上限に引っかかる
実行結果が途中で切れる
ワークフローが失敗する
Outputノードに渡せない
画面表示が重くなる

Base64は、元のバイナリデータよりもサイズが約1.33倍に増えます。

例えば、.xlsx ファイル本体が60KBの場合、Base64文字列はおおよそ80KBになります。

xlsx本体: 約60KB
↓
Base64文字列: 約80KB

そのため、Difyの文字列出力上限が80,000文字前後だとすると、実用上の安全圏は以下のように考えられます。

base64_length <= 70,000
→ 安全圏

70,000 < base64_length <= 80,000
→ 危険圏

base64_length > 80,000
→ 失敗する可能性が高い

ただし、ExcelファイルはZIP圧縮されるため、単純に「行数が多いほど大きい」とは限りません。

例えば、同じ文字列が大量に入っているExcelは圧縮が効きやすく、意外と小さくなります。

一方で、セルごとに異なる文字列が入っている場合は圧縮が効きにくく、ファイルサイズが大きくなりやすいです。

そのため、以下の観点で検証したいです。

行数を増やした場合、base64_lengthがどの程度増えるか
列数を増やした場合、base64_lengthがどの程度増えるか
セルごとの文字列が同一の場合と異なる場合でどの程度差が出るか
装飾あり・なしでどの程度差が出るか

19.3 Base64サイズ上限の検証手順

この検証では、いきなり巨大なBase64文字列を返すのではなく、まずはBase64本体を返さず、サイズだけを計測します。

理由は、大きすぎるBase64文字列をいきなり返すと、Codeノード自体が失敗する可能性があるためです。

検証は以下の2段階で行います。

Step 1:
Excelを生成し、xlsx本体サイズとBase64文字列長だけを返す

Step 2:
限界付近のケースだけ、実際にBase64本体を返して成功・失敗を確認する

Step 1: Base64本体を返さずサイズだけ測る

CodeノードのOutput Variablesは以下にします。

変数名	型
result	string

Codeノードでは、複数パターンのExcelを生成し、それぞれのサイズを表形式で返します。

検証観点は以下です。

項目	意味
rows	データ行数
cols	列数
text_len	1セルあたりの文字数
unique_text	セルごとに異なる文字列にするか
styled	罫線や背景色などの装飾を付けるか
xlsx_bytes	生成されたxlsx本体のバイト数
base64_length	Base64化後の文字数
判定	安全圏・危険圏・NG予想

期待する出力イメージは以下です。

| rows | cols | text_len | unique_text | styled | xlsx_bytes | base64_length | 判定 |
|---:|---:|---:|:---:|:---:|---:|---:|:---|
| 10 | 8 | 30 | false | false | 3200 | 4268 | OK予想 |
| 100 | 8 | 30 | true | true | 18000 | 24000 | OK予想 |
| 500 | 8 | 30 | true | true | 56000 | 74668 | 危険 |
| 1000 | 8 | 30 | true | true | 110000 | 146668 | NG予想 |

この段階では、Base64本体は返しません。

返すのは、あくまで base64_length だけです。

これにより、どの条件で出力上限に近づくかを安全に確認できます。

Step 2: 限界付近だけBase64本体を返す

Step 1の結果を見て、base64_length が70,000〜80,000付近になる条件を選びます。

例えば以下のようなケースです。

rows=500
cols=8
text_len=30
unique_text=True
styled=True
base64_length=75,000前後

その条件だけを対象にして、実際に base64_xlsx を返します。

CodeノードのOutput Variablesは以下にします。

変数名	型
filename	string
size	number
base64_len	number
base64_xlsx	string
error	string

成功すれば、Difyの出力としてBase64文字列を受け取れます。

失敗すれば、その条件はDifyの出力上限を超えている可能性があります。

Step 3: 検証結果を表にまとめる

最終的には以下のような表にまとめます。

rows	cols	text_len	unique_text	styled	base64_length	実行結果
200	8	30	true	true	35,200	成功
500	8	30	true	true	72,800	成功
600	8	30	true	true	83,500	失敗

この表が作れれば、DifyでBase64形式のExcel出力を行う場合の実用目安が分かります。

19.4 この検証で分かること

この検証で分かるのは、以下です。

Dify Codeノードで安全に返せるBase64文字列の上限
実用的なExcel行数の目安
装飾がファイルサイズに与える影響
セル文字列のばらつきがファイルサイズに与える影響
Base64出力方式が実務で使えるか

特に重要なのは、行数ではなくBase64文字列長で判断することです。

ExcelはZIP圧縮されるため、同じ行数でも中身によってファイルサイズが大きく変わります。

そのため、実務で使う場合は、

何行まで大丈夫か

ではなく、

生成後のbase64_lengthが何文字か

で判断する方が安全です。

19.5 この検証の意義

DifyのFile型として直接返せない場合でも、Base64文字列として出力し、呼び出し元で .xlsx に復元する運用は考えられます。

例えば、以下のような使い方です。

Dify APIを呼び出す
↓
レスポンスでbase64_xlsxを受け取る
↓
呼び出し元アプリやスクリプトでbase64をデコード
↓
.xlsxとして保存

この方式を採用する場合、Base64文字列がDifyの出力上限に収まることが前提になります。

そのため、このサイズ上限検証は、Base64方式を実務利用できるか判断するうえで重要です。

19.6 今後の検証優先度

今後の検証優先度としては、以下の順番がよいと考えています。

優先度1:
Base64文字列のサイズ上限を確認する

優先度2:
実際の業務帳票に近い列数・行数でサイズを確認する

優先度3:
Dify内部API経由でFile型として返せるか確認する

File型として返す検証は、Codeノードのネットワーク制限やDify内部APIの認証が絡むため、やや複雑です。

一方で、Base64文字列のサイズ上限検証は、Codeノード内だけで完結できます。

そのため、まずはBase64出力方式がどの程度使えるのかを確認するのが現実的です。

20. おわりに

最初は、

DifyだけでExcel出力は無理なのでは？

と思っていました。

しかし検証してみると、少なくともExcelファイルの生成自体はできました。

正確には、

DifyだけでExcel生成はできる。
ただし、DifyのFile型として返すには別の壁がある。

という結論です。

Difyで業務アプリを作る場合、Excel出力はかなり需要があると思います。

同じようにDifyで帳票出力に挑戦している方の参考になれば嬉しいです。