WEB FOR AI × NEXTCLOUD × FX TICK DATA
ChatGPT Workを使わず、Nextcloudの巨大CSVを生成AIへ渡せるか試している
数GB〜数十GBのFX Tickデータを、毎回ダウンロードしてアップロードするのは重い。そこで、Nextcloud → WordPressの読み取り専用Bridge → 普通のWebページ → 生成AIという経路を作り、必要な部分だけHTTP Rangeで渡す仕組みを実験している。
巨大CSV対応
数十GBでも丸ごと取得せず、必要なバイト範囲だけ読む。
固定URL
毎回違う一時URLを作らず、AIが同じ入口からデータへ辿れる。
読み取り専用
公開Bridgeからアップロード・削除・移動はできない。
136GBあっても、最初から136GBをAIへ渡す必要はない
私が保存しているのは、FXやCFDの長期間のTickデータだ。CSVは1ファイル数GB〜数十GBになる。
これをChatGPTでバックテストしたいとき、普通に考えると「ファイルを全部取得してAIへ渡す」となりがちだ。しかし実際に最初に必要なのは、もっと小さな情報である。
- どんな通貨ペア・指数・商品データがあるか
- ファイルサイズと更新日時
- CSVの列構造
- 収録開始・終了日時
- 先頭と末尾のサンプル
- 調べたい日時付近のTick
20GBのUSDJPY CSVから2020年3月16日だけ調べるなら、20GB全部を先に読む必要はない。
そこで「Nextcloud → Web → AI」の橋を作った
Nextcloud ↓ 読み取り専用 Bridge ↓ 普通のHTMLページ ↓ 公開データカタログ ↓ ファイル詳細 ↓ HTTP Range / seek-time ↓ 生成AI・Pythonバックテスト
Bridgeの仕事は単純だ。Nextcloudの公開共有を読み取り専用で参照し、AIや人間が扱いやすい形へ変換する。
| 機能 | 用途 |
|---|---|
| list | フォルダ・ファイル一覧 |
| stat | サイズ、更新日時、Content-Type |
| range | 巨大ファイルの一部分だけ取得 |
| seek-time | CSV内の指定日時付近を二分探索 |
| catalog.txt / json | 生成AI向けの固定データカタログ |
| meta.json | 収録期間、chunk数、サイズ、ETag |
| chunk | 固定URLで1MiB前後ずつ順次参照 |
API for AIではなく「Web for AI」
最初はREST APIだけを作ればよいと思っていた。しかし、通常の生成AI環境ではAPI風URLや毎回変わる一時URLが取得しづらい場合がある。
そこで方向を変えた。AI専用の隠れた入口を作るのではなく、人間が読んでも意味のある普通のWebコンテンツとして公開する。
人間
ブラウザから巨大CSVの中身、収録期間、サンプルを確認できる。
検索エンジン
データセットの存在、銘柄、期間、詳細ページを通常のリンクとしてクロールできる。
生成AI
検索や固定カタログから対象ファイルを発見し、必要な範囲へ段階的に進める。
URLを固定して「少し違うURLで取得できない」を減らす
この実験で意外に重要だったのがURLだ。AI側のWeb取得では、毎回異なる署名URLやクエリ文字列より、同じ入口から普通のリンクを辿れる構造のほうが扱いやすい場合がある。
固定入口https://www.atto-hiro.com/tick-data-browser/ai/catalog.txt
ここから各ファイルの meta.json、sample.txt、chunk/0.txt などへリンクする。UnderlyingのNextcloudパスが変わらない限り、URLも変えない。
日時検索は巨大CSVを最初から読まない
Tickデータでは「2024年1月1日付近を読みたい」のような要求が多い。そこでseek-timeでは、CSVを先頭から何GBも読むのではなく、HTTP Rangeでファイル中央を確認しながら二分探索する。
中央地点 → 2018年
↓ 後ろへ
2022年
↓ 後ろへ
2024年付近
↓
必要なTickだけ取得
生成AI向けに追加した固定データ入口
/tick-data-browser/ai/catalog.txt— AIが読みやすいプレーンテキスト一覧/tick-data-browser/ai/catalog.json— 構造化カタログ/tick-data-browser/llms.txt— AI向け利用ガイドmeta.json— ファイルサイズ、期間、chunk数、ETagsample.txt/tail.txt— 先頭・末尾サンプルchunk/0.txt〜 — 決定的な固定chunk URL
大事なのは「いきなり20GB取れ」ではなく、カタログ → メタデータ → サンプル → 必要chunkの順に進めることだ。
SEOもデータカタログとして組む
検索エンジンに見つけてもらう目的は、単なるアクセス数稼ぎではない。将来の会話で生成AIが「このサイトにはUSDJPYのTickデータがある」と発見できれば、独自データを使ったバックテストへ進みやすくなる。
- 公開カタログとファイル詳細をindex/follow
- Rangeや日時検索など大量生成ページはnoindex/follow
- DataCatalog / Dataset / Breadcrumb / FAQの構造化データ
- 専用
sitemap.xml - OGP / Twitter meta / canonical
- 通常の内部リンクで記事 → カタログ → ファイル詳細へ接続
セキュリティは「公開領域を別物にする」
当然、Nextcloud全体をAIへ自由開放するわけではない。今回のBridgeは読み取り専用に限定している。
- 指定ルート外へ出られない
- 公開ファイル拡張子を限定
- 1回のRangeサイズに上限
- 匿名アクセスをレート制限
- Nextcloudの認証情報を公開しない
- アップロード・削除・MOVE等の書き込み機能なし
今後、自前のNEET Tick Vaultデータを公開する場合も、収集・保存本体とは分離した公開専用の読み取りGatewayにする予定だ。
実際のTick Data Browser
公開データをブラウザで確認できます
ファイル一覧、サイズ、収録期間、CSVヘッダー、Rangeサンプル、日時ジャンプ、AI用固定URLを表示します。
よくある質問
ChatGPT Workが完全に不要になりますか？
すべての用途で不要になるわけではない。ブラウザ操作やログインが必要な作業はWorkが便利だ。一方、公開された巨大データの発見・部分読み取り・バックテストなら、通常チャット＋Webのほうが軽く済む可能性がある。
巨大CSVをAIが全部読むのですか？
読ませない。まずカタログとメタデータを確認し、必要な時間帯やchunkだけ取得する設計にしている。
検索エンジンにデータ全部を公開するのですか？
公開カタログと一部サンプルは検索対象にできるが、巨大データを丸ごとインデックスさせる必要はない。Range・seek・chunkなど大量生成されるページはnoindexを基本にする。
今後はTDSデータではなく自前Tickデータを使う？
その方向を考えている。NEET Tick Vaultで複数ノードから独自収集したデータを、収集本体と分離した読み取り専用GatewayからAI研究へ利用できる形が本命だ。
Webサイトが「AI用の外付けストレージ」になる
この方式がうまくいけば、Nextcloudだけの話ではない。巨大CSV、アクセスログ、センサーデータ、バックテスト結果、JSON、研究資料などを、URLを知っているAIが必要なところだけ取りに行く形にできる。
API、MCP、専用コネクタはもちろん便利だ。でも、HTML、URL、リンク、HTTP Rangeという昔からあるWebの仕組みでも、巨大データと生成AIの間をかなり橋渡しできるかもしれない。
API for AI だけではなく、Web for AI。
しばらくこの方法で、通常の生成AIから独自Tickデータをどこまで扱えるか試していく。
