この記事の途中に、以下の記事の引用を含んでいます。
Side Project of a Side Project
Side Projectは“悩み”から生まれる――「サイドプロジェクトのサイドプロジェクト」とは
今回ご紹介する記事「Side Project of a Side Project」は、AIエンジニアリンググループの著者が、自身の実務体験や個人的な問題意識から生まれた検索パイプライン開発の経緯を語る技術エッセイです。
2025年までの約9ヶ月間、著者はRAG（Retrieval-Augmented Generation）システムの実践を通じて、金融調査書類の検索・抽出技術に関わっていました。
記事は「検索パイプライン全体を自分でコントロールする必要性」と、その道中で生まれた“Python製Solrクライアント「Taiyo」”の開発・価値について論じています。
“The main lesson I learnt from this experience is that you have to solve retrieval first before you solve RAG. To achieve a desired user experience, you need to own (or at least be able to contribute to) the entire pipeline from indexing to retrieval to reranking to generation, rather than simply adding a generation step on top of an existing search system.”
これは、「RAGを実用的なプロダクトに昇華するには、最初から最後まで一気通貫で検索パイプラインを“自分のもの”にする必要がある」とする主張です。
この考えは、誰かが用意した既存システムに、生成AI部分だけを雑に載せてもうまくいかない、という点で現場感覚に即しています。
“なぜ検索パイプライン全体が重要なのか？”——本質に切り込む着眼点
検索やRAGの導入では「生成」や「検索速度」ばかりが注目されがちですが、著者は「インデクシング」から「リランキング」「ユーザー体験」まで全工程の制御が重要だと述べています。
ここで重要なのは、業務要件ごとに必要な構成要素（たとえばドキュメントの頻繁な追加、検索速度の要求度、キーとなる語彙の分布等）を明らかにし、それに応じて最適化することです。
記事ではこうした設計判断の例として、「インデクス対象がPDF中心で、更新頻度も低い UK企業の書類検索」という実際のユースケースを紹介しています。
“In Companies House, the documents are almost always indexed as PDFs and the frequency of document updates is generally low, say, no more than one document per day per company.”
この状況下では、「重いPDF構造化処理」や「メタデータ抽出」に許される余裕が生まれるため、オフラインで手の込んだ前処理や先進的なモデル（VLMなど）の採用も現実的です。
既存ツールや既成概念を鵜呑みにせず、プロジェクト特有の条件に合わせてパイプライン設計を見直すべきだ、という洞察が際立ちます。
“なぜSolr？ そしてPythonクライアント自作の決断”——開発者の痛みとエコシステム論
著者は数あるエンタープライズ向け検索サーバ（Elasticsearch, OpenSearch, Meilisearch, Apache Solr）のなかから、堅実な性能と成熟度を評価してSolrを選んでいます（ちなみにMeilisearchはRust製、それ以外はLucene系Java製）。
しかし決定的な課題は「開発者が快適に使えるPythonクライアントがない」ことでした。特に公式扱いされている「pysolr」に対して、以下のような問題意識を示しています。
“pysolr does not support async operations at all, making concurrent queries inefficient compared to libraries that leverage Python’s async features. Indexing documents is also less ergonomic, and there is no built-in type safety, which can lead to runtime errors and make integration with typed codebases more challenging. … pysolr exposes Solr’s query syntax directly. Parameters like q, fl, and qf are somewhat terse abbreviations for a new user, and the relationship between query parameters and query parsers is not clearly documented or enforced by the client.”
すなわち
– Pythonらしいasync対応が皆無で並列処理が不得意
– 型安全性がないため、動的言語での運用が不安
– クエリのパラメータ体系が直感的でなく、理解しづらい
といった「使うほどに開発者のコストが高まる」状態だったわけです。
この“開発体験（DX）の悪さ”が技術選択の最大ボトルネックであり、それがプロダクト全体の価値を下げてしまう経験は、実に多くの現場で共有されています。
“自分が欲しいものは何か？”——「Taiyo」開発と価値創出の本質
この「Solrクライアント不満」は、結果として著者に「自分でよりよいPythonクライアントを書く」というサイドプロジェクトを生み出させました。
「Taiyo」は以下を特徴とします。
– モダンなPythonでフルasync対応
– 型安全性（Pydanticモデル等）を徹底
– クエリビルダー/パーサーとしてIDE補完・公式ドキュメントと連携
– メソッドチェーンとコンフィグオブジェクト両対応の柔軟なインターフェース
たとえば従来のpysolrでは下記のような素朴な書き方でした。
python
from pysolr import Solr
solr = Solr ('http://localhost:8983/solr/company_documents', timeout = 10)
params = {
'defType': 'edismax',
'q': 'preference shares',
'qf': 'summary^2.0 content^1.0',
'group': 'true',
'group.field': 'company_name',
'group.limit': 3,
'group.ngroups': 'true'
}
results = solr.search(**params)
（この例では結果がすべてuntyped dictで返されるため、事後検証も煩雑です。）
「Taiyo」では、例えば下記のようにIDE補完つきで型安全なクエリビルドや、メソッドチェーンが可能です。
“`python
from taiyo.params import GroupParamsConfig
from taiyo.parsers import ExtendedDisMaxQueryParser
parser = ExtendedDisMaxQueryParser(
query = “preference shares”,
query_fields = {“summary”: 2.0, “content”: 1.0},
configs = [GroupParamsConfig(by = “company_name”, limit = 3, ngroups = True)]
)
“`
そして、Pydanticモデルを利用することで、サーチ結果もすぐ型付き（CompanyDocumentクラス）で処理できます。
また、非同期I/Oを活かしたバルクインデクシングも可能です。
“`python
import asyncio
from taiyo import AsyncSolrClient, SolrDocument
class CompanyDocument(SolrDocument):
… # フィールド定義略
async def ingest(docs: list[CompanyDocument]):
async with AsyncSolrClient(“http://localhost:8983/solr”) as client:
client.set_collection(“company_documents”)
… # バッチ分割しasyncで並列コミット
docs = …
asyncio.run(ingest(docs))
“`
こうした実装は、もう一歩深くパイプラインの“隙間”を自分自身で埋めたい実践者にとって極めて意義ある選択肢となります。
サイドプロジェクトの意義を“プライベート”から“オープン”へ拡張する視点
記事の末尾で著者は、「Make something people want（人が欲しがるものを作ろう）」という有名なYCのモットーに触れつつ、まずは“自分が強く欲しいもの”を作ることこそが副業プロジェクトの本質的動機だと述べています。
この志向には非常に大きな意味があると私は考えます。
というのも、
– 最初は小さな不満・痛みゆえの自作ツール
– だがその先に同じ悩みを抱える他者の存在
– 個人OSSやプロダクトとして徐々にコミュニティへ波及した例
が、オープンソース界隈や現代ITプロダクトには溢れているからです。
Pythonのpandas、Jupyterだって、もとはアカデミックな「自分たちが楽をしたい」思いから。
それが“Make something people want”となって広がっていきました。
本記事の著者も、「たとえ世の誰も使わなくても、自分のプロジェクトが次に進むならそれでいい」と書きます。
裏を返せば、強い“私的欲求＝困りごと”は、しばしば社会的問題意識の源泉になるのです。
結論：「本当に欲しかったもの」は“現場感”の中から生まれる
この記事が我々に教えてくれるのは、単なる技術選定やライブラリ制作の話ではありません。
真に現場の課題と向き合う人間が、必要だからこそ“パイプラインの全工程を握る”決断をし、“今の時代に必要な新しい開発体験”を自作してしまうエネルギーそのものです。
生成AIや検索基盤が進化するなかで、その表層の「技術トレンド」だけを追うのでなく、プロジェクト固有の条件・現場ゆえの課題を深掘りし、場合によってはローレイヤーまで自前でツールを作り出す勇気。
そしてそのプロセス自体が、思わぬ形で“他者の悩み”を解決するOSSやコミュニティへ派生しうること。
業務・副業の垣根を越え、「自分が一番欲しいもの」という動機を大切にする姿勢は、検索やAIに限らず、現代エンジニアリングの核心だと強く感じました。
＊
日々の業務や副業で感じる「ちょっとした不便・イライラ」こそが、次のイノベーションのスタート地点かもしれません。
あなたは、本当に“自分が欲しいもの”をつくっていますか？
categories:[technology]
コメント