Nao - データのためのCursor

• データ作業に特化したVS CodeベースのAIコードエディタで、BigQuery/Snowflake/Postgresに直接接続され、データスキーマに合わせたコードの自動生成と品質検査機能を提供
• 既存のLLMベースツールがデータスキーマを認識しないままSQLを自動補完する一方、naoはRAGベースのAIタブとエージェントツールにより、正確なSQL/Python/YAMLコードを生成
• SQLパイプラインの作成、実行、可視化を1つのインターフェースで実行可能
• Pythonパイプラインも同じ環境でサポートし、dbtワークフローにも対応
• コード変更前後の結果データの差分とデータ品質の問題をひと目で確認でき、テストなしで迅速にデプロイしたりミスを防いだりできる
• 主な用途
  • データパイプライン構築（SQL、dbtなど）に活用
  • 欠損/重複/外れ値の検出
  • 開発環境と本番環境のデータ比較
  • 事前定義済みテストの実行と要約
• dbt、BIツール、データウェアハウスと統合されており、データエンジニア、アナリスト、データサイエンティストのすべてに適したIDE環境を提供
• BigQuery、Snowflake、Postgresをサポートし、まもなくDatabricks、Iceberg、Redshiftにも対応予定
• Looker, Power BI, Metabase, Tableauとの統合も予定
• 現在はMac版のみ提供、Windows/Linux版も提供予定
• CursorおよびMCPsとの違い
  • Cursorはデータコンテキストを得るために複数のMCP呼び出しが必要だが、Naoは単一のRAGで常時利用可能
  • MCPsはCursor内で限定的にしか動作せず、UIの適応性も低い
  • Naoは事前パッケージ化されており、設定、拡張機能のインストール、認証、CI/CD構築が不要で、非専門家でも開発体験を向上できるのが強み

FAQ

• naoを使うべき人は？
  • SQL作成者、dbtアナリティクスエンジニア、データサイエンティスト、データエンジニアなど、あらゆるデータチームのメンバー
• Cursorとの違いは？
  • データスキーマ認識ベースのコード生成、自動データ品質検査、変更影響の予測など、データコンテキストに最適化されたIDE
• どの言語をサポートしていますか？
  • すべての言語をサポートするが、特にSQLに最適化
• dbtワークフローにはどう役立ちますか？
  • dbtモデル、ソース、ドキュメント、テスト、列単位のlineageを理解し、自動補完と可視化を提供
• データセキュリティは？
  • データはローカルでのみ処理され、LLMに送信される前にユーザーの許可を得る
  • コードやスキーマは保存されず、埋め込みのみを活用

[GN⁺]

Hacker Newsのコメント

• 多くのLLMベースのデータプロジェクトは柔軟で役に立つ一方、再現しづらく対話性にも欠けると指摘しており、Naoはこの概念をうまく実装しているという評価。私が作った**Buckaroo** はJupyterとPandas/Polars向けのデータテーブルUIで、最新のテーブル、ヒストグラム、要約統計を使ってすぐにデータを確認できる。昨日Buckarooにオートクリーニング機能をリリースし、データに対してヒューリスティックに適切なクリーン方法を選んで確定したコードを提供する。500ms以内という非常に高速なのが売りで、複数のクリーニング戦略を試して最適なものを選べる。単純な問題ならLLMを通す必要もない。オープンソースで拡張性も高い

  • 私も本当に似たものを開発中。まだBuckarooほど完成してはいないが、ノートブック内の埋め込みアプリはかなり有用だと思う

  • データプロファイリングを可視化できるビューがとても気に入っている。データ理解における重要な核だと思う

• 本当に素晴らしいアイデアだと思う。Tabモデルをどう学習させたのか気になる。Fill in the middle なのか edit history ベースなのか。昨日、誰かがこれに似たCursorのタブ自動補完に関するブログ記事を共有していて、興味深く読んだ

  • 私たちはFill in the middleモデル（MistralとQwenの自前トレーニングモデル）を使っている。そこにユーザーのデータコンテキストも入れる。カーソル位置に応じて適切なデータスキーマコンテキストを提供するため、自前のSQLパーサーを使っている

• 数週間使い続けてみて、ワークフローが実際に大きく改善されたと感じている。VSCodeと拡張機能の代わりに、すでに半分以上こちらを選ぶようになった。探索的データ分析のためのチャット、ワークシート、カラムリネージ追跡機能はdbt開発で本当にゲームチェンジャーだ。こうした機能は実際の自分の作業スタイルに合わせて緻密に設計されている感じがする。ClaireとChristopheはフィードバックへの反応も即座で、機能の追加や修正も速い。製品は正しい方向に素早く進化している

  • うれしい言葉をありがとう。そしてnaoの改善に協力してくれてありがとう

• とても魅力的だと感じる。YouTube動画を何度も見たが、フィードバックサイクルを短縮している様子が非常に印象的だった。本当にすごい

  • ありがとう。まさにこのフィードバックループ短縮が私たちの目標だ。データチームはソフトウェアエンジニアと比べてフィードバックループが長くなりがちなので、それを縮めてデータを開発フローにより近づけることを目指している

• これはraw SQLを使うときだけ動くのか気になる。私のプロジェクトではPostgres + TypeScriptでKyselyのようなquery builderを使ってクエリを書いているので、今すぐ使えるのか知りたい

  • 現時点ではTabはraw SQL（純粋なSQLファイルまたは文字列）で最もうまく動く。ただ、chat/agentを使えばKyselyを使っていることを伝え、ウェアハウスのコンテキストを渡すことである程度は扱える。Kyselyは初めて聞いたが、プロジェクト紹介GIFを見ると自動補完はかなり良さそうだ。タブ方式とは違うが興味深い

• 自分のデータ/プロンプトがモデルにどの程度送られるのか気になる。スキーマ程度なら問題ないが、ウェアハウスのデータはたいてい機密データだ。エンタープライズプランがあるはずなので、実際のコード以外のデータ/結果がサーバーへ送信されるのか、それともコードだけなのかを事前に知りたい

  • データ内容そのものは、ユーザーが明示的に許可しない限りモデルに送られない。サーバーにはコードベースとデータスキーマの埋め込みだけが保存される。データ内容にはユーザーのコンピュータ上でローカルからのみアクセスする。agentがクエリを実行するときは、ウェアハウスで実行したあと、その結果を読んでもよいか承認を求める。許可しなければLLMには送信されず、ローカルでプレビュー可能だ。エンタープライズ版を使えば、プロンプトとコンテキストは共有LLMエンドポイントを経由せず、別途保護することもできる

• データエンジニアリングやデータサイエンス向けのLLMベースのツールのリンクをおすすめしてほしい人はいる？

  • 私がそうしたLLMツールのリストリポジトリをまとめていて、もうすぐ完成する予定だ

• 搭載されている機能が気に入った。今後SQLiteのサポートも追加される予定はある？

  • もちろん。あまり難しくなく追加できそうだ。次のリリースではDuckDBも入る予定で、SQLiteも追加できる。SQLiteを使う理由はローカル開発のためなのか気になる

• 複数のテーブルにFK/PKがない状態で推移的な結合をするとき、どう処理するのか気になる。これに加えて、既存の非効率なクエリに対する利用分析/リライトもキラー機能になりそうだ

  • 結合については、各テーブルのスキーマと、リポジトリ/クエリ履歴上ですでに使われた結合方法をモデルに与えて関係の推論を助けている。利用分析も確かに開発ロードマップに入っており、各テーブルの実使用状況の計測のためにデータウェアハウスのログへアクセスする計画がある