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

60日前原文(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プレイグラウンド：
- github.com/RecoLabs/gnata

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件のオープンイシューがあったよ。

└

それは、今後も元の機能と互換性を保つつもりなら重要だね。この場合、内部フィルタリングエンジンとして使われるから、目標は出てくるバグを修正して、時々この組織に必要な機能を追加することだと思う。

└

ここからは全部YOLOだね… 今日私たちが下している主要なAIの決定は、AGIが最終的に現れて混乱を片付けてくれる賭けのように感じる。

└

まず最初に気になるのは、このプロジェクトのテストスイートがどれくらい良いかってことだね。

└

フル翻訳には7時間と$400のトークンがかかったよ。四半期ごとにAIを使って差分を適用する方が、ずっと楽で安い。ソフトウェアエンジニアリングは完全に変わったね。

└

「最初に思い浮かぶ質問は、今これを管理してるのは誰かってことだね。たぶん、彼らの会社の別のAIエージェントだろうけど、間違いは起こさないだろうね。」

私にとっての重要なポイントは、GoでのリライトやAIの使用ではなく、彼らがこのアーキテクチャから始めたことだね。> 参照実装はJavaScriptだけど、私たちのパイプラインはGoにある。だから何年もjsonata-jsポッドをKubernetesで運用してきた - Node.jsプロセスが私たちのGoサービスをRPCで呼び出す。つまり、すべてのイベント（と式）をシリアライズして、ネットワーク越しに送信し、評価して、結果をシリアライズして、最後に戻さなきゃいけなかった。> これで年間約30万ドルのコストがかかっていて、顧客や検出ルールが増えるにつれてその数字は増え続けてた。ビジネスの核心に関わることなのに、年間30万ドルもかかるまで放置してたのが不思議でならない。これを完全にリライトするのに400ドルのClaudeトークンしかかからなかったっていうのも、さらに不思議だよ。400ドルのClaudeトークンで大きなコードベースをすぐに消し去ることができるから、全体を400ドルでリライトしたなら、そんなに大きなものじゃなかったはず。エンジニアが手作業で合理的な時間内に簡単に移行できる範囲内だったと思う。今、そのエンジニアたちはすべてのAI生成コードをレビューして理解し、改善しなきゃいけないから、それにも時間がかかるよね。どう考えればいいのか分からない。これらのブログ記事はエンジニアリングの専門知識を示すためのものだと思ってたけど、AIがシステムの重要な部分の代替を作ることを自慢するのは、設計が疑わしくて、年間フルタイムエンジニア1人分のコストがかかることに対して、他の多くの疑問を呼び起こすよね。

└

「もし$400のClaudeトークンで全体を書き直したなら、それほど大きなものじゃなかったはずだよ。元のは約1万行のJSと、テストハーネス用に数百行だ。$20/月のCodexサブスクリプションで一発でできるだろうし、日々の制限も使い切らないと思う。」

└

だいたい同意だけど、貢献度はFTEのアウトプットで評価する方が適切だと思う。今、1,000万ドルの機能を開発中で、その後もいくつか予定してるけど、300,000ドルの小さな無駄遣いに時間をかけるのはあんまり意味がないことが多い。実際にそれを直すために雇える状況になった時だけ、FTEのフルコストと比較する価値が出てくるけど、それも難しいよね。コアチームが本当に価値のある機能を作る時間が奪われちゃうし、大きなチームのオーバーヘッドで進捗が遅くなることもあるし。しかも、仮に雇えるとしても、もっと価値のある機能に取り組んでもらいたいよね。

└

そうそう、「コードが何をしてるか考えたら5,000倍速くなった」みたいな投稿だよね。

└

私の経験では、こういう移行は実際に書かれるコードの深さはそれほどでもないことが多い。影響を受けるすべての側面を正確に評価できるかどうかが重要なんだ。それがすべてマッピングできれば、移行はかなり簡単だよ。

└

これで年間約30万ドルのコストがかかってたし、顧客や検出ルールが増えるにつれてその数字は増えていった。 > ビジネスの核心に関わることなのに、年間30万ドルもかかるところまで放置してたのが不思議だ。これが、経営陣が絶対に聞くことのない核心的で真実のストーリーだね。

└

同じエンジニアたちが今やAI生成されたコードをレビューして理解し、それを改善する必要があるけど、それにも時間がかかるよね。彼らはやるの？なんでそう思うの？年間30万ドルかかってた時に誰も改善しようとしなかったのに、今安くなったからって誰が気にするの？

└

LLMやAIの本当の価値が、マイクロサービスと似てるのかなって思う。組織や文化の問題を解決するって意味で。この場合、AIが開発者に、組織が許可しなかった変更をさせたんだ。普通の書き直しだと、投資家に「私たちはAIに対応してる」「成長してる」「エージェント的だ」って信号を送れないから、ブロックされてたはず。でも、AIの書き直しなら。

└

「ビジネスの核心に関わることなのに、年間30万ドルもかかる状態になるまで放置してたのが信じられない。なんか汚いハックで動いてるものを作ったら、会社が成長して、誰もそれをちゃんと作り直そうとしなかった。私がいたところでは、会社が新しい頃に誰かが適当に組み合わせた劣悪（でも効果的！）なクエリのせいで、年間400万ドル以上もRedshiftに使ってたんだ。成長するにつれて、いろんなものがその上に作られてしまって、下の部分に手をつけるのが怖くなってた。」

└

「その通り。これは素晴らしい分析だね。私もこれが気になってた：> 最近まで、エージェントコードにはかなり懐疑的だった。でも2026年2月は、私のような頑固な開発者でも無視できない転換点だった。“2026年2月”って、あまりにも具体的すぎる。PRやマーケティングチームが書いたみたいだ。普通のプログラマーにとっては、投稿内のジャンプスケアみたいに感じる。」

└

「そう、それが懐疑的なキーポイントだね。実際のキーポイントは、大規模な移行を行う場合、非常に良い＆広範なテストスイートを持つことだ。移行中にClaudeが変更することは許されない。その場合、Claudeは非常に印象的で正確にコードベースを移行して、最小限の手助けで済む。テストスイートがなければ、Claudeは自由にやりたい放題になる。最近、大規模な移行プロジェクトをやったけど、テストスイートにもっと集中すべきだった。」

おめでとう！この著者は、サブ最適なマイクロサービスを見つけて、それをインラインコードに置き換えたんだ。これが良いエンジニアリングの基本だよ。これがマイクロサービスが危険な理由の一部でもある。悪いエンジニアリングっていうのは、すでに存在するものの代わりに自分で何かを作ることだよ。他のコメントでも指摘されてるけど、GoにはすでにJSONataの実装が2つあったんだから、$400でClaudeに何かを書き直させるより、既存のサポートされてるライブラリを使った方がいいじゃん。

└

「もし私が著者の立場だったら、まずこのJSONライブラリの他のGo実装をフォークして、AIを使って現代の基準に引き上げて、彼のテストをすべて通すようにしただろう。それでも、彼の仕事は素晴らしい - これがデータエンジニアリングの実際の姿だね。」

こんな馬鹿げた話をハッカーニュースで読むのは初めてじゃないよ。突然資金が入ってきて、どう管理すればいいかわからないスタートアップの症状みたいだね。私は過去12年間、収入だけで製品をゆっくりスケールさせてきたから、ちょっと視点が違うかもしれないけど、こんな些細なことで1%のレベルに達するような無駄遣いは絶対許せない。

コメントで言及されていた他の2つのGolang実装のうちの1つについての背景。数年前、Upworkの契約者にv1.5.3をGolangに移植してもらったんだけど、彼は素晴らしい仕事をしてくれた。ただ、完璧からは程遠くて、ほとんどのJSテストスイートを通過できなかった。最悪だったのは、悪い式でセグフォルトする再帰バグがいくつかあったこと。これが今は非推奨になっている実装で、https://github.com/blues/jsonata-go 2025年初めに、Claude CodeとCodexを使って、完全なテストを通過して安全な適合ポートを作った。AIにとっては決して簡単な作業ではなかったけど、JSONataの構文の多くはJSのルーツから来ているからね。それでも、素晴らしい経験だったし、こちらが2.0.6のAIポートで、実装間を行き来できるGolangエクササイズもあるよ。シームレスな移行を行って、BluesのNotehubで素晴らしく動いてる。これはJSONメッセージパイプラインで顧客が使うコアな変換機能として使われてるんだ。https://github.com/jsonata-go/jsonata

└

「JSONataのGitHubプロジェクトに、あなたの実装をドキュメントやREADMEに書いてプルリクエストを出すのはどう？OPのポートについても同じことが言えるよ。」

└

「私は、jsonata-goリポジトリで問題を見つけて、JavaScript版をサンドボックスで実行したくなかったので、JSONataのクリーンスレートポートを書くことにも関わった。20層のネストされたコンテキストと5000行の式でストレステストをかけるまでは比較的簡単だったけど、突然JS版にはないメモリー爆発が起きた。JSONataは言語に強く結びついている。振り返ると、仕様を少し変更してコードの修正をすればよかった。既存のJSONataを持ち込む顧客がいなかったから、違いに気づかれなかっただろう。」

Recoでは、私たちのデータパイプライン内のすべてのメッセージに対してJSONata式を評価するポリシーエンジンを持ってる。数十億のイベントと数千の異なる式がある。元のアーキテクチャの選択と価格は、脳動脈瘤を引き起こしそうだったけど、「AIで作る」という解決策もあまり考慮されていない。これは、quamina（aws/event-rulerの独立した後継で、quamina-rsの祖先）などの既存の高品質で高性能な生産グレードのソリューションにぴったりの候補に見える。近い将来、「私たちは馬鹿なことをしていて、それをAIで馬鹿なことをすることで解決しました」ということがたくさん起こるだろうね。:-|

└

でも、AIが作ったソリューションがちょっとマシになったなら、それでも勝ちじゃない？

ヘッドラインは確かに派手だけど、個人的にはAIが本当に解決したとは思えないな。技術の選択を修正しただけで、その恩恵を受けただけのように見える。既にゴーラン版のjsonataがあるから、理論的にはそれらのライブラリでも実現できたはず。既存のライブラリが十分じゃない理由や、新しいものを書く必要があった理由については何も書かれてないし。通常、この分野ではちゃんとした調査が必要だけど、この記事にはそれに関する言及がない。実際の効率を測るためには、gnataを既存のゴーランライブラリとベンチマークすべきだった。もしかしたら、AI実装の方がずっと遅いかもしれないし。ブログのベンチマークも変だよ。測定はアプリ内で行われてるけど、ライブラリ内の呼び出しを測るべきなんだよね（例えば、孤立したベンチマークでのJS版とゴー版を比較するみたいに）。だから、AIで書かれたバージョンの実際のパフォーマンスが分からないってこと？唯一の利点は、既存の悪い技術選択を修正したことだけで、観察された結果に基づくと、よりマシな技術選択に変わったってこと。で、それがクリックベイト的なマーケティングタイトルで飾られてる。今後、こういう投稿がもっと増えるんだろうな。

└

既にゴーラン版のjsonataがあるから、理論的にはそれらのライブラリでも実現できたはず。私が見つけた唯一のもの（jsonata-go）はJSONata 1.xのポートだけど、彼らが公開したgnataライブラリは2.xの構文に対応してるんだ。だからそういうことなんだろうね。

「内部で数字を共有したら、誰かがROIについて聞いてきた。先月のjsonata-jsの生産コストは約25Kドルだった - 今は0になった。その会話はかなり短く終わった。自分の経験から投影してるけど、実際の洞察なしに力を振るうことができる様子がすごく響いてくる。そして、ほとんど傲慢に「OK、全て素晴らしいけど、ROIは…？」って感じ。この記事は素晴らしいエンジニアリングを持つ会社から来ているようだから、このケースには当てはまらないかもしれない。でも、そのコメントから想像するトーンはやっぱり際立ってる。成熟したエンジニアリングだからこそ、ROIが重要なのは分かる。会社はそれを作るために存在してるし。ちっちゃなことから推測して、ボーイングの文化の変化を考えてる： https://news.ycombinator.com/item?id=25677848 簡単に言うと、良いエンジニアリングが信頼で育まれて、利益を生むことができないのはなぜ？」

└

「私の中では、この“観察”（そう呼んでいいなら）が、他のコメント者が持っていることを説明するか、少なくとも関連しているかもしれない：> 何を考えればいいのか分からない。これらのブログ記事はエンジニアリングの専門知識を示すべきなのに、疑わしい設計で年間フルタイムエンジニア一人分のコストがかかるシステムの重要な部分をAIに置き換えさせることを自慢するのは、他にたくさんの疑問を呼び起こす。」

ハクソク