ファーストインプレッションとインターフェース
getnao.io のサイトを訪れると、その明確なキャッチコピー「コンテキストエンジニアリングのために作られた分析エージェント」にすぐに惹かれました。ランディングページにはターミナルベースのワークフローが示されており、デベロッパーファーストのアプローチが新鮮に感じられます。シンプルな npm install -g nao で CLI をインストールした後、nao init を実行すると、ターミナル内にファイルシステムの構造が表示されました。データベース、ドキュメント、クエリ、リポジトリ、セマンティクス用のディレクトリが含まれています。ダッシュボード（コマンドラインそのもの）には、エージェントのコンテキストがツリー表示されます。無駄に肥大化した GUI はなく、データエンジニアや分析エンジニアを対象としたツールとして理にかなっています。デフォルトの LLM は Claude Sonnet 4.5 ですが、独自の API キーを使用することもできます。nao chat で起動するチャット UI は、ミニマルながら機能的なインターフェースを提供します。そこで「月ごとのユニークユーザー数を表示して」と質問すると、エージェントが事前に定義したコンテキストを探索する様子が確認できました。応答時間は約10秒と妥当で、生成された SQL も正確でした。
Nao の仕組み：コンテキストエンジニアリング
Nao は、多くの分析特化型 LLM エージェントが直面する特定の課題を解決します。それは信頼性の低いコンテキストです。Nao は、スキーマのダンプや生のドキュメントを LLM に渡すのではなく、コンテキストを構造化されたファイルシステムとして扱います。テーブルのカラム、プロファイリングのサマリー、ビジネス定義、サンプルクエリ、さらにはルールに至るまで、すべての要素を nao-agent ディレクトリ内のマークダウンファイルまたはテンプレートとして定義します。nao_config.yaml ファイルがすべてを統括します。データベース接続（BigQuery、Snowflake など）、リポジトリ参照（dbt、Looker）、そして Notion ページなどの外部ソースです。nao sync を実行すると、エージェントがこれらのソースからライブメタデータを取得し、コンテキストフォルダに書き込みます。これは、ドキュメントサイトを単にベクトル化するよりもはるかに細かい制御が可能です。さらに、ユニットテストを作成することもできます。質問から期待される SQL を作成し、nao test を実行して回答率、トークン数、時間を測定します。私のテストでは、11の質問に対して81.8%の合格率を示しました。これは信頼性を示す具体的な指標です。このツールの核となる仮説は、エージェントの信頼性はコンテキストの質に正比例するというものであり、ファイルシステムによる抽象化によって、そのコンテキストを明示的にし、バージョン管理可能にしています。
技術的な機能と価格
内部では、Nao はユーザー自身の API キー（例：Claude Sonnet 4.5、GPT-4）を介して任意の LLM を使用します。accessors フィールドを通じて、主要なデータベース（BigQuery、Snowflake、Postgres）用のコネクタをサポートしています。オプションには、カラム、説明、プレビュー、プロファイリングが含まれます。リポジトリ（dbt、Looker）や外部ドキュメント（Notion）も第一級の対象です。プロジェクト全体は100%オープンソースであり、GitHub の nao-labs 組織でホストされています。価格はウェブサイトに公開されていませんが、このモデルは bring-your-own-key とセルフホスティングを推奨しており、つまりユーザー自身の LLM プロバイダーへのトークン消費のみを支払うことになります。ホスティング版を希望する方向けに、サイトには「独自の LLM キーでチャットをデプロイ」と記載されており、管理されたティアが存在することを示唆していますが、価格の詳細は提供されていません。LangChain の分析アシスタントや RAG ベースのツールなどの代替手段と比較して、明示的でファイルシステム形式のコンテキストエンジニアリングに焦点を当てた Nao のアプローチはユニークです。エージェントが参照する内容を細かく制御でき、テストハーネスによって反復的な改善が可能です。すでに構造化されたデータドキュメント（dbt ドキュメント、Looker の探索）を持ち、コンテキストパイプラインを再発明することなく信頼性の高い自然言語クエリインターフェースを構築したいチームに最適です。ローコードでビジュアルなアプローチを好む開発者にとっては、CLI と YAML 設定が重すぎると感じるかもしれません。
推奨事項と制限事項
Nao の強みは、オープンソースであること、コンテキストをファイルシステムとして扱うパラダイム、そして組み込みの信頼性テストです。私は、これが分析エージェントを信頼できるものにするための、これまで見た中で最も実用的なアプローチの一つだと心から思います。ただし、実際の制限もあります。このツールは、すでに相当なデータインフラ（dbt プロジェクト、データウェアハウス、そしてコンテキストファイルを管理する意欲のあるチーム）があることを前提としています。非開発者にとってのオンボーディングは急勾配です。コンテキストソースの設定やテスト管理のためのグラフィカルインターフェースはありません。さらに、エージェントのパフォーマンスはコンテキストファイルの品質に大きく依存します。不適切に書かれた説明や欠落したプロファイリングデータは、精度を低下させます。概念実証のため、私は手動でいくつかのマークダウンファイルを作成する必要がありました。また、現在のツールにはライブチャット分析やユーザーフィードバックループの組み込みサポートがありません（ただし、モニタリングタブにはチャット履歴が表示されます）。全体として、コマンドラインに慣れており、透明性とテスト可能性を備えた分析エージェントを求めているデータチームには Nao をお勧めします。ビジュアルエディタを備えたプラグアンドプレイのソリューションが必要な場合は、別の選択肢を検討してください。https://getnao.io で Nao を実際に試してみてください。
コメント