ハクソク

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

Redis配列：長い開発プロセスの短編ストーリー

6日前原文(antirez.com)

概要

  • Redisに新しい Arrayデータ型 を追加する開発経緯
  • AI（主に GPT 5.x）を活用した設計・実装・テストのプロセス
  • 実装中に直面した課題と データ構造の進化
  • Markdownファイルや正規表現（ ARGREP）など新機能の追加
  • AIの利点と今後のRedisへの期待

Redis Arrayデータ型開発ストーリー

  • 2024年1月初旬より Redisの新しいArrayデータ型 の開発を開始

  • 実装は約4ヶ月間、 パートタイム的に作業 （実際はフルタイム週も多数）

  • 最初の1ヶ月は 仕様書の作成 に集中

    • 新データ型の意義、C構造体、スパース表現、リングバッファ用カーソルのセマンティクスなどを詳細に記述

  • 仕様書作成時は Opusとペア作業、その後 GPT 5.3 リリースで Codex を活用

  • 設計・実装の全工程で GPT 5.xシリーズ を主に利用

    • フィードバックや設計上の課題解決、妥協点の検討などAIと対話しながら進行

  • 2ヶ月目以降、 自動コーディング（オートコーディング） で実装開始

    • コードを常に レビューしつつ開発

  • 初期設計の 間接参照レベルが不十分 と判明

    • ARSET myarray 293842948324 foo のような操作で効率的なメモリ管理を目指し、 階層構造を再設計
      • ディレクトリ＋スライス（スパース/デンス）の2層構造を 超ディレクトリ＋デンスディレクトリ＋スライス 構造に進化
      • 各スライスは 4096要素 をデフォルトで保持
      • ARSCANやARPOP 操作の効率向上

  • コード全体を 行単位で精査

    • AIによる広範なテストに加え、 細かな非効率性や設計ミス を人間とAIで修正

  • 3ヶ月目には 多様なストレステスト を実施し、堅牢性と有用性を確認

  • 利用ケース検証中に MarkdownファイルをArrayに格納 する使い方を発見

    • これをきっかけに ARGREP （正規表現検索）機能を実装
      • 正規表現ライブラリは TRE を採用（安全性重視）
      • foo|bar|zap パターンの効率化やセキュリティ修正もAIと協力して実施

  • AIの最大の利点

    • 複雑で膨大な作業 の安全網として機能
    • 32ビットサポート の追加・テストなど、膨大なタスクもAIで効率化
    • 複雑なアルゴリズムのバグ検出 にも貢献

  • 膨大な仕様書 の作成が後の作業全体の鍵

    • sparsearray.c、t_array.cなどの 全行レビュー も仕様書が支え

  • ユースケース詳細は PRのコメント に記載（https://github.com/redis/redis/pull/15162）

  • Redisに 数値インデックスを持つデータ型 が加わる意義を強調

  • Array PRの受け入れと新たなユースケースの拡大 に期待

  • フィードバック歓迎 の姿勢

Redis新Array型の設計ポイント

  • 数値インデックス をセマンティクスに組み込む新データ型
  • スパース／デンス表現 のハイブリッド構造
  • データ量やアクセスパターンに応じて 内部構造を自動変形
    • メモリ効率と高速アクセスを両立
  • 4096要素単位のスライス 管理方式
  • ARSCANやARPOP など範囲操作の効率化

AI活用による開発効率と品質向上

  • 設計・実装・テスト・最適化 の各工程でAIを積極活用
  • 仕様書作成や設計議論 もAIとの対話で質向上
  • コード自動生成＋人間によるレビュー で効率化と品質担保
  • テストケース生成やバグ検出 もAIが支援
  • AIによる仮想労働力 で膨大な作業量をカバー

今後のRedisと新Array型への期待

  • 従来にないユースケース の開拓
    • ファイル管理やナレッジベース としての活用
    • 正規表現検索（ARGREP） による柔軟なデータ操作
  • コミュニティからのフィードバック を歓迎
  • Redisの進化 とユーザー体験の向上に貢献

Hackerたちの意見

現在の最先端AIに関する自分の経験とすごく似てる。人間の知性や創造性の代わりになるわけじゃなくて、めっちゃ役立つコラボレーターだね。

└

プロジェクトを開発する時、コードをあまり見ずに、コンセプトやアルゴリズム、アイデアを持ちながら質問したりヒントを出したり、特に製品をしっかり把握してる。けど、Redisにはまだそのスタイルは使ってないな。未来にそれが可能になると、今のサーバーソフトウェアの開発方法は終わると思う。プロジェクトやリポジトリはまだ残るだろうけど、機能や修正、経験の蓄積は価値があるからね。プログラマーの役割は、リーナスがカーネルのためにやってきたことに似てくると思う。今開発してるDeepSeek v4推論エンジンみたいなプロジェクトでは、もうそのスタイルでやってるよ。

└

AIは、俺がずっと欲しかったプログラミングのアヒルだって言いたいな。

はっきり言っておくけど、これはRedisのオリジナルクリエイター、またはその一人だよ。彼は「普通の開発者」じゃないし、LLMを使って4ヶ月かかったんだ。これをもって、全ての開発者にClaudeやCodex、他のAIコーディングツールに完全に移行するよう命令するための承認印じゃないからね。スタートアップの普通のCEO、見てるよ。

└

経験豊富な開発者が上手く使うことで、コーディングエージェントがさらに専門知識を高めるというアイデアに対して、かなり強い支持を示してるね。

└

彼は「普通の開発者」じゃないし、LLMを使って4ヶ月かかったんだ。これを明確にするために、TFAから引用すると：> LLM以前でも、実装は4ヶ月でできることだったと思う。変わったのは、同じ期間でより多くのことができるようになったこと。最初のタイムフレームは4ヶ月だったけど、彼はその期間内でLLMを使ってもっと多くの作業をこなせるようになったんだ。

└

彼は「普通の開発者」じゃないし、LLMを使って4ヶ月かかったんだ。確かに普通じゃないけど、彼の仕事は明らかに平均的じゃないよ。普通の開発者の仕事っていうのは、配管作業とかCRUDだよね。

現在のやり方をシェアするね：まずAIに手伝ってもらって高レベルのデザインのmdドキュメントを作る。それから別のAIに、同じモデルか別のモデルで批評してもらって、バグやギャップ、抜けを指摘してもらう。いつも後から見れば明らかなことを見つけてくれるんだ。だから、その結果をまとめてもらって、最初のAIに貼り付けて意見を聞く。合意した変更を作って、重要そうな提案が出なくなるまでこの対抗的なラウンドロビンを続ける。最後にAIに計画を立ててもらう。それをまたいくつかのAIに対抗的に回して、最終的には計画がしっかりしたものになる。次にエンドツーエンドのテストケース計画とかもやって、システムの規模によって、初日や週、月の終わりにはコーディングの準備が整う。コードができたら、それを他のAIに仕様や計画と一緒に貼り付けて、バグや抜けを指摘してもらう。メインのAIが実装している間も、他のAIを使ってチェックし続けるんだ。もちろん、コードを読む必要もあるよ。AIは細かい部分を見逃すことがあるからね。

└

自分でコードを書くのと比べて、そのプロセスはどれくらい速い/遅いの？

└

AIについての議論は、全く新しい無監視の開発パラダイムを解放したって感じだけど、要するにGoogleが10年間コードを作ってきたのと同じことを言ってるだけだよね。AIの代わりに信頼度の異なる人間がいるってだけで。これは君をからかうためじゃなくて（僕のワークフローもほぼ同じだから）、新しいことは何もないって言いたいだけなんだ。AIは効果的なワークフローも効果が薄いワークフローも加速させる素晴らしいツールだよ。どれが効果的でどれが効果が薄いかを、もっと短い時間スケールで、リアルタイムで示してくれてるんだ！

└

この「仕様駆動開発」っていうのがAWS KiroのUSPだったんだよね：https://kiro.dev/docs/specs/ > もちろん、コードを読まなきゃいけないよ。AIが仕上げを見逃すことが多いからね。他のエージェントを使ってるって言ってたけど、別のエージェントが未完成な部分を磨くコードレビューって効果ある？同僚たちはそれを絶賛してるけど、私は人間のレビューなしではその価値に懐疑的なんだ。 > それから別のAIに聞いてみる。もしかしたら、合成-反合成-合成の方が応用コンピュータサイエンスには合ってるかもね… https://en.wikipedia.org/wiki/Dialectic#Criticisms

まとめてくれてありがとう。最近のシニア開発者がAIとどう関わっているかを見るのはいつも興味深いね。@antirez: プロジェクトの後半に、あまり関係のない機能のためにregex機能を導入するのはちょっと変な感じがするんだけど、その理由をもう少し説明してもらえる？ありがとう！

└

配列がテキストファイルにぴったりだと気づいてから、思いつく多くのユースケースは、ファイルをgrepする必要があるってことに制限されてたんだ。だから、ファイルのためのAROPの同等物は何だろう？ARGREPだ！それで、ユースケースに応じて最適なツールが使えるように、速くて正確なマッチングとregexpマッチングを両方追加することにしたんだ。多くのORで繋がれた文字列に対しては、最適化すればregexが速い方法になることを発見した。それからTREを少し専門化したよ。

これを追加してくれてありがとう。配列やregexについてワクワクしてるし、LLMを使って自分の能力を伸ばす経験にもとても興味があるよ。私たちの中には、同じことを試みて静かに様々なプロジェクトに取り組んでいる人がたくさんいるんだ。「バイブコーディング」（とその反発）は、私たちの働き方を本当に表しているわけじゃないよね。

└

僕がエージェントを使った方法をバイブコーディングだとは全然思わないよ…僕は関与が深すぎて、すべてを検証・確認・レビューしてるから。

└

「バイブコーディング」の問題は、その言葉を作った著者が非常に特定の定義を与えたことなんだ（結局、彼の言葉だからね）：コードを見ずにソフトウェアを書くこと、ただ「バイブってる」だけ。で、すぐに元の意味を失って、ほぼ全てのAI支援コーディングに使われるようになったんだ。

これで提示されたユースケースのいくつかはZSETsで実現できたんじゃないかな？パフォーマンスの観点は理解できるけど、新しいAPIを使わなくても、密な値のためにZSETのストレージを選択的に最適化することで実現できたように思う（配列が選択的にスパース表現を使うのと同じように）。REコンポーネントは面白いけど、ここでのコメントにもあるように、配列データ構造とは直交しているように見える（つまり、他のものでも使えるってこと）。これをLuaスクリプトで実現する方がもっと理にかなってるんじゃないかな？もしLuaのパフォーマンスが問題なら、値の範囲を返すコマンドの上に構成可能にするようにOPを抽象化するのもありかも。これはこの分野の専門家であるAntirezへの敬意を込めて言ってるけど、この新しい機能セットのいくつかは、既存の機能を強化するんじゃなくて新しい機能を作り出す、LLM駆動の開発から生まれるような解決策に感じる。つまり、他の機能と組み合わせた方が効果的なのに、機能が複雑化してる気がする。

└

残念ながら、ソート済みセットは実際にはスペクトルの反対側にあるんだ。意味的には正しいけど、スキップリストと配列の組み合わせのせいで無駄が多い。さらに、基盤となる表現が配列でない場合、範囲クエリやリングバッファは本来の効率やコンパクトさを持たない。理論的には何でもできるけど、各APIができることをセグメント化することで、最適な実装を提供できるユースケースを活かせるんだ。

22,000行のコードをレビューするのは、たとえantirezからのものであっても、こんなに複雑な機能セットと最小限のPR説明だと悪夢みたいだね。Postgresのような大規模なオープンソースソフトウェアがメーリングリストで開発される理由が見えてくるよ。コミュニティで中間的な設計決定が話し合われて、異なる関連機能のための別々のパッチがあって、段階的にレビューされて、リリースの間隔が空いてるんだ。

└

PostgresとRedisは全然違うプロジェクトで、ストーリーや貢献、開発チームも全く異なる。ほぼ全ての主要なRedisの機能は、投稿者のソロ作業だよ。ちなみに、レビューする人たちはいいお金をもらってるし、設定もちゃんと理解してるよ。

└

コードは合計5000行、コメントも含めてね：スパース配列が2000行、t_arrayコマンドと上層実装が2000行、AOF/RDBコードが約500行。他の部分はテストやJSONコマンドの説明、"deps"の下にあるTREライブラリだよ。

サルヴァトーレは「自動プログラミング/コーディング」という言葉を広めたいみたいだね。(https://antirez.com/news/159)

└

同じことを説明するのに言葉を最小限に抑えようとしてる自分に気づくんだよね。時間が経つにつれて「その」操作をすることが増えてきたからかも。もしかしたら、用語を「オートコード」に短縮するのがいいかもしれないね。

└

https://en.wikipedia.org/wiki/Automatic_programming これはコンピュータサイエンスで認められた用語で、高い抽象レベルからの説明をもとにコードを自動生成するあらゆるメカニズムを指してるんだ。もちろん、LLMは非決定的で驚くほど広範囲にわたるから非常に珍しいけど、だからといってこの用語が適用できないわけじゃないよ。

antirez: 最終コードについてなんだけど、最終結果を一発で出す実験とかしたことある？GEPAを使ってそこに到達できるか気になるし、モデルをどうやってうまく誘導するか学べることがあるかもしれない。もしかしたら、モデル提供者がトレーニングデータを整理する必要があるって結論になるかもね！

誰か、ブログ記事で言及されてた仕様を手に入れる方法知ってる？リンクされたPRには見当たらないんだけど。