AI Agentがコードベースで関数を探すとき、従来のアプローチはこうです：
Agentがリクエストを送信：「src/auth/login.pyを読んでください」→ 500行のファイル全体を受信 → Agent「違う、src/auth/handler.pyを読んで」→ さらに800行 → 5、6回繰り返して、ようやく必要な3行のコードに辿り着く。
5,000行のコードに対してトークンを支払い、実際に使ったのは3行。
これがSembleが解決しようとしている問題です。
Sembleのアプローチ
Sembleの名前は「semantic」（セマンティック）+「assemble」（組み立て）に由来。コアロジック：ファイル全体をAgentに渡すのではなく、まずセマンティックインデックスで関連コードスニペットを見つけ、Agentが実際に必要な部分だけを返す。
具体的にどうやるか？
ハイブリッド検索戦略。 純粋なセマンティックベクトル検索でも、純粋なキーワードマッチングでもない——両者の組み合わせ。まずキーワードで粗篩いし、その後セマンティック類似度で精密順位付け。こうすれば、正確なコードマッチを見逃すことなく、「この関数とあの関数の関係」といったセマンティックレベルの関連性も理解できる。
除外ファイルメカニズム。 .gitignoreと同様に、Sembleは.sembleignoreをサポートし、node_modules、vendor、distなどAgentがそもそも気にしないディレクトリを自動スキップ。
トークン消費の定量測定。 「トークンを節約する」と言うだけでなく、ベンチマークでデータを実行：異なるコードベース規模でのSembleとgrep+readのトークン消耗比較。858スターのプロジェクトがREADMEにベンチマークデータを公開しているということは、データは裏付けがあるということ。
なぜこれが重要か
98%がマーケティング数字だと思うかもしれません。しかしその背後にあるトレンドは本物です。
AIコーディングAgentの最大のコストボトルネックは推論速度ではなく、コンテキストウィンドウです。中規模のコードベースで、Agentが数ファイル読むだけで数万トークンを消費しかねません。GPT-4oの入力トークンは$2.50/百万、Claude Sonnetは$3/百万。複雑なマルチファイルタスクでは、コンテキスト読み取りだけで数ドル燃やします。
Agentが毎日数千回タスクを実行するとき、このコストは指数関数的。
Sembleが解決しているのはまさにこの「見えないコストの穴」です。
既存方案との比較
コード検索の領域はプレイヤーに溢れています：
- grep/ripgrep：速いが、マッチ行全体を返す、コンテキストが不正確
- Sourcegraph：エンタープライズ級、強力だが重い
- GitHub Code Search：プラットフォーム依存
- 各種ベクトルDB方案：純セマンティック検索、精度に問題
Sembleのポジショニングは明確：AI Agent向けに最適化された軽量コード検索。Sourcegraphの代替を目指すのではなく、ripgrepと速度を競うのでもない。唯一の目標：Agentが最低のトークンコストで必要なコードを見つけられるようにすること。
注目すべき点
このプロジェクトはまだ若い——76コミット、6件のissue、最新コミットは8時間前。ただし著者stephantulは活発な貢献者で、更新頻度が高い。
さらに注目すべきはbenchmarkディレクトリ：トークン消耗比較だけでなく、異なるコードベース規模でのパフォーマンステストも実施。この「データで語る」アプローチはオープンソースコミュニティでは珍しい。
##我的看法
Sembleはますます明確なトレンドを代表しています：AI Agentツールエコシステムは「使える」から「効率的に使える」へ進化している。
初期のAgentツールはタスクを完了できればよかった。今はみんな最適化している：より少ないトークン、より低いレイテンシ、より高い正確さ。Sembleはこの最適化の波の一つの典型例。
あなたのチームがAIコーディングAgentで大型コードベースを扱っているなら、Sembleを15分試す価値があります。節約できるトークンは、直感が示すよりもはるかに多いかもしれません。
主要ソース：
- MinishLab/semble on GitHub — 858 stars, 67 forks, 76 commits
- プロジェクトbenchmarksディレクトリ：トークン効率比較データ
- Show HN投稿：12 points, 12 comments