ハクソク

世界を動かす技術を、日本語で。

AIを使って1日でJSONataを再構築し、年間50万ドルを節約しました

2026年3月27日原文(reco.ai)

概要

  • CloudflareのAIによるNext.js再実装事例を参考に、Reco社がJSONata互換エンジン「gnata」をGoで開発。
  • 7時間・$400のコストで1,778テストケースをパス、パフォーマンスを大幅改善。
  • 年間$500Kのコスト削減、レイテンシー・リソース問題も解決。
  • AIによるコード生成とレビューの実践事例。
  • gnata導入とバッチ処理最適化による運用改善。

Cloudflare事例から着想を得たAI活用法

  • CloudflareはAIとエンジニア1名でNext.js APIをVite上に再実装、$1,100のトークンコストで完了。
  • 既存のNext.js仕様とテストスイートをAIに与え、全テストパスまで自動実装を繰り返す手法。
  • Reco社も同様の課題（JSON変換パイプライン）を抱えていたため、同アプローチを採用。

JSONata運用上の課題

  • Reco社ではポリシーエンジンが膨大なJSONata式をデータパイプライン上で評価。
  • JSONataはJavaScript実装のみで、Goサービスとの間はKubernetes上のNode.js RPC経由で通信。
  • イベントごとにシリアライズ・ネットワーク転送・評価・再シリアライズが発生、年間約$300Kの計算コストに加え、レイテンシー増大。
  • シンプルなフィールド参照でもRPC往復のオーバーヘッドが顕著。
  • 過去に式最適化・キャッシュ・V8組み込みなど試行したが根本解決には至らず。

gnata構築プロセス

  • 週末にAIを活用し、開発を「ウェーブ」単位で計画。
  • 公式jsonata-jsテストスイートをGoに移植し、全テストパスまで実装を進行。
  • 7時間で13,000行のGoコード・1,778テストケース合格、トークンコスト$400。
  • 月間$25Kかかっていたjsonata-js運用がgnata導入で0に。

gnataのアーキテクチャと高速化

  • 二段階評価アーキテクチャを採用。
    • コンパイル時に式を解析・分類。
    • シンプルな式（フィールド参照や21種の組み込み関数）は生JSONバイトに直接適用、ヒープ割り当てゼロ。
    • 複雑な式は必要な部分のみパース・評価。
  • ストリーミング層（StreamEvaluator）で複数式を1回のスキャンで評価、キャッシュとロックフリー設計。
  • キャッシュ容量は設定可能、古いエントリは自動削除。
  • 正式テスト1,778件＋本番統合テスト2,107件で正確性を担保。
  • 単純な式はRPC廃止で1,000倍高速化、複雑な式でも25-90倍高速化。

導入・検証・本番化

  • 初日でgnataライブラリ完成、PR提出。
  • 2-6日目はコードレビュー・QA・プリプロダクションのシャドウモードで実運用式と比較検証。
  • 7日目、3日連続で差異ゼロを確認しgnataを本番に昇格。
  • jsonata-jsのバグもgnata導入で発見・修正。

AIコードレビュー体制の進化

  • gnataはAI生成コードをAIエージェントがレビューする初の大規模PR事例。
  • エージェントは本質的な並行性バグから表面的な指摘まで幅広く検出。
  • この経験がAIコードレビュー体制の改善に寄与。

バッチ処理最適化による追加コスト削減

  • gnata導入でRPCコスト$300K削減後、ルールエンジンのバッチ処理最適化にも着手。
    • 以前はJSONataの制約で大量のgoroutine・高メモリ消費・CPU競合が発生。
    • gnataはバッチ処理制約がないため、シンプルかつ高効率な実装に刷新。
    • リクエストコアレッシング・短命キャッシュ・グループ化クエリなどを導入。
  • 結果、月額$18K（年間約$200K）追加削減、合計$500K/年のコストダウン。

AI主導の開発と今後の展望

  • AIによる完全自動コードが本番運用に適するか議論は続くが、gnataは有効事例となった。
  • Andrej Karpathyの指摘通り、トップ層では技術力がAI活用のレバレッジをさらに高める時代に突入。
  • 2026年は「サージカルリファクタリング」の年になると予想。

gnataの導入方法とリソース

  • 導入例：
    • go get github.com/recolabs/gnata
    • expr, _ := gnata.Compile("user.role = \"admin\" and user.loginCount > 100")
    • json := []byte("{ \"user\": { \"email\": \"admin@example.com\", \"role\": \"admin\", \"loginCount\": 247 } }")
    • result, _ := expr.EvalBytes(ctx, json)
    • fmt.Println(result) // true
  • ドキュメント・ストリーミングAPI・WASMプレイグラウンド：

Hackerたちの意見

これで年間約30万ドルのコストがかかっていて、顧客や検出ルールが増えるにつれてその数字は増え続けてた。もしかしたら時代遅れなのかもしれないけど、JSONオブジェクトで動くカスタムラムダ関数にこのレベルのコストがかかるなんて理解できないよ。

└

これってサティアじゃないの？ まさか、これに関しては時代遅れじゃないよね。エンジニアが「クラウドに年間30万ドルかかるのは、1.5人のDevOpsエンジニアが社内ソリューションを管理するのと同じ」って主張するかもしれないけど、ただのJSONパースに対して？？？

└

最初はAWSラムダ関数だと思ったけど、もし非常に高い同時接続数のために過剰にプロビジョニングされてるなら、月2.5万ドルは可能性の範囲内かもしれない。でも、投稿はただのRPCコールについて話してるだけで、K8sポッドでDockerイメージを動かしてるのに、年間30万ドルを節約するためには、コンピューティングコストは年間1億ドルを超えてるはず。もしそれが何十億人のユーザーの日々のイベントのGoogle規模で、最も貧弱で非効率的な処理エンジンを使って、キャッシング層もゼロで、非常に悪く書かれたルールを使ってるなら、可能性はあるかもしれないけど。なんか、読者の注意を引くためのSEO記事みたいに感じる。

└

ここがコストの原因だよ。 >「リファレンス実装はJavaScriptだけど、私たちのパイプラインはGoなんだ。だから何年も、Kubernetes上でjsonata-jsのポッドを動かしてきた。Node.jsのプロセスで、私たちのGoサービスがRPC経由で呼び出してるんだ。つまり、イベント（と式）ごとに、シリアライズしてネットワーク越しに送信して、評価して、結果をシリアライズして、最後に返すってことをしなきゃいけなかった。でも、どちらにしても、月に$25,000の話だよ。全然信じられない額じゃない。」

└

記事には、同時に最大200ポッドを運用していたって書いてあったよ。ざっくり計算してみると、200ポッドで年間$300,000だと、1時間あたり約$0.17になる。これはEC2のc5.xlargeのオンデマンド料金とぴったり同じだね。4つのvCPUがあるから、ピーク時には約800のvCPUで、$0.0425/CPU-時間だ。いくつか質問があるんだけど、* ピークキャパシティに基づいてコスト削減を見積もったのか、24時間365日運用してるかのように？ * コストを抑えるためにオートスケーリングを使ったのか？ * マルチCPUハードウェアでシングルスレッドアプリ（Nodeベース）を動かして無駄にキャパシティを浪費してたのか？（私の予想は違うけど、何が起こるかわからないからね）

ドキュメントには、すでに他に2つのGo実装があるって書いてあるけど、なんでそのうちの1つを使わないの？ https://docs.jsonata.org/overview.html

└

彼のプロンプトには「Goで実装する」って書いてあって、「すでにGoの実装があるか確認する」っていうのはなかったんだ。彼らはjsonを解析するためにKubernetesクラスターを運用してたから、驚くことじゃないね。

└

そうじゃなかったら、こんな意味のない記事を書いてAIのハイプに貢献することもなかっただろうね。

└

そのリポジトリの最後のコミットは5年前と7年前だね。

└

それらは1.xの構文に対応してるけど、gnataは2.xに対応してる。あと、リポジトリは長い間新しいコミットがないね。

└

書き直しが起こるのは、誰も他人の中途半端なゴミをデバッグしたくないからで、「Xを使えばいい」ってのは、その癖や欠点を引き継ぐことになることが多い。

アプローチはCloudflareのvinextリライトと同じで、公式のjsonata-jsテストスイートをGoに移植して、すべてのテストが通るまで評価器を実装するってことだ。最初に思ったのは、今これを誰が管理するの？ オープンソースプロジェクトに依存してたんだよね。今や君の翻訳版（フォーク？）は13,000行のGoコードを維持する必要がある。どうやって更新を保つつもり？ メンテナンスは考慮されてるの？ JSONataやその解決する問題については何も知らないけど、リポジトリを見たら15件のPRと150件のオープンイシューがあったよ。

Hacker Newsで議論の続きを見る