ここしばらく、ChatGPTからNextcloud上のファイルを安定して読ませる方法をいろいろ試してきました。
特に困っていたのが、巨大なCSVやNextcloud上のファイルをChatGPTから参照しようとしたときに発生する「Cache miss」です。
前の記事では、その対策としてWordPress側に読み取り専用のBridgeを作り、NextcloudのデータをChatGPTから扱えるようにする方法を試しました。
さらにその後、OpenDriveとNextcloudの両方を扱えるNEET Storage Bridgeへ発展させ、巨大CSVを全部ダウンロードせず、HTTP Rangeや日時Seekを使って必要な部分だけ取得する仕組みまで作りました。
これはこれでかなり便利です。
ただ、いろいろ試した結果、普段ChatGPTからNextcloud上のデータを読ませる用途については、もっとシンプルな方法にたどり着きました。
TinyFishを使う
結論から書くと、現在いちばん使いやすいと感じているのがTinyFish経由でNextcloudへアクセスする方法です。
イメージとしては非常に単純です。
ChatGPT ↓ TinyFish ↓ Nextcloud ↓ ファイル・CSV・各種データ
WordPressに専用Bridgeを作り、Gateway URLを発行して、そこからChatGPTに読ませる方法も機能します。
しかし通常のWeb取得では、URL自体が正常でもChatGPT側の取得経路でCache missになることがありました。
TinyFishを使うと、この部分を別のブラウザ経路で処理できるため、少なくとも私の環境ではNextcloud上のデータへかなり素直に到達できています。
ここに来るまでかなり遠回りした
振り返ると、かなりいろいろ試しました。
- Nextcloudの公開共有URL
- WordPress REST API
- Atto Nextcloud ChatGPT Bridge
- NEET Storage Bridge
- Direct Gateway URL
- HTTP Range
- Range Probe
- 日時Seek
- OpenDriveとの二重化
- ChatGPT Workからの直接参照
- TinyFish経由
最初からTinyFishを使っていれば早かった、という見方もできます。
ただ、実際には遠回りしたことで、それぞれの方法の得意分野がかなり分かりました。
TinyFishだけですべて置き換えるわけではない
ここは重要です。
TinyFishが便利だからといって、これまで作ったStorage Bridgeが不要になったわけではありません。
むしろ役割がはっきりしました。
普段のNextcloud参照
↓
TinyFish
巨大CSVを数KB～数MBだけ読む
↓
Storage Bridge / Range
巨大CSVの特定日時へ飛ぶ
↓
Seek Time
大量データをまとめて解析する
↓
ChatGPT Work
私が扱っている為替のティックCSVには、十数GBから数十GBあるファイルもあります。
こうしたファイルを毎回最初から最後まで読むのは非効率です。
たとえば「2020年3月1日前後のティックだけ欲しい」という場合には、Storage Bridgeで日時Seekして、その周辺だけRange取得する方法のほうが圧倒的に効率的です。
一方で、Nextcloudのフォルダを見たり、ファイルの内容を普通に確認したりする程度なら、TinyFishのほうがずっと楽です。
「AIから読めるWeb」を自作する必要が減った
以前は、ChatGPTから安定して読ませるために、WordPressを間に置いて「AIが読みやすいURL」を自分で作ろうとしていました。
Nextcloud ↓ WordPress Bridge ↓ AI向け固定URL ↓ ChatGPT
これは非常に面白い仕組みですし、今後も研究用途では残します。
ただ、TinyFishが使えるのであれば、日常的なファイル参照まで全部自前のGatewayへ通す必要はありません。
AI側に「Webブラウザ役」を持たせてしまえばいいからです。
Cache missとの戦いから少し解放された
今回いちばん大きかったのはこれです。
GatewayのURLを発行して、それをChatGPTへ渡しても、URLの中身そのものに問題がないのにCache missになることがありました。
サーバー側では正常にHTTP 200や206 Partial Contentを返していても、AI側のWeb取得経路では取得できない。
この状態になると、WordPressやNextcloudをいくら修正しても解決しません。
原因がデータ側ではなく、途中の取得経路にあるからです。
TinyFishという別経路を使えるようになったことで、ようやく
Nextcloudは正常 ↓ URLも正常 ↓ でもChatGPTの通常取得だけ失敗 という問題を回避しやすくなりました。
現在のマイベスト構成
2026年9月時点で、私の中では次の構成がいちばんしっくり来ています。
Range / Seek
- USDJPY.csv — 長期ティックデータ
- XAUUSD.csv — 金の長期ティックデータ
- AUDCAD.csv — 検証用CSV
- その他の巨大CSV — 複数銘柄を保管
TinyFishを普段使いの入口にする。
巨大データだけStorage Bridgeで狙い撃ちする。
大量解析が必要ならWorkを使う。
今のところ、この役割分担がかなり快適です。
TinyFishを普段使いの入口にする。
巨大データだけStorage Bridgeで狙い撃ちする。
大量解析が必要ならWorkを使う。
今のところ、この役割分担がかなり快適です。
自作Bridgeは失敗だったのか
全然そんなことはありません。
むしろ、Bridgeを作ったからこそ巨大CSVをRangeで読む方法や、16GBを超えるファイルの特定日時へほとんどデータを読まずにジャンプする方法まで作ることができました。
普通のファイル閲覧と巨大データ研究では、求められる仕組みが違います。
TinyFishは「人間がブラウザで見るようにAIにも見に行ってもらう」用途に強い。
Storage Bridgeは「巨大ファイルの何バイト目、何時何分の部分だけ欲しい」という機械的なアクセスに強い。
両方持っているほうが便利です。
結論
ChatGPTからNextcloudを読ませるために、かなり長いこと試行錯誤しました。
現在の結論はシンプルです。
普通にNextcloudを読ませるならTinyFish。
巨大CSVを部分的に読むならStorage Bridge。
大量解析するならWork。
何でも一つの仕組みで解決しようとせず、用途ごとに経路を分けるのが結果的にはいちばん安定しました。
特にCache missに悩んでいる場合、NextcloudやWordPress側を延々と修正する前に、TinyFishのような別の取得経路を試してみる価値はあります。
ここまでいろいろ作って、壊して、直して、ようやくたどり着いた現時点でのマイベストです。
