tryAGI/LangChain: C# で LangChain の抽象を再現するライブラリの実像
C# implementation of LangChain. We try to be as close to the original as possible in terms of abstractions, but are open to new entities.
ひと目でわかる
- これは何？
- Python 版 LangChain の抽象を C# に持ち込む MIT ライセンスの実装を、README とリポジトリ構成から読み解く。RAG のパイプラインを C# で書きたい開発者にとっての実用性と、判断を保留すべき点を整理する。
- 誰に向いている？
- 採用を検討すべきなのは、RAG のパイプラインを C# の型と LINQ 風の演算子で書き、OpenAI 以外のモデルも同じ抽象で扱いたいチームだ。逆に、Microsoft のエコシステムに閉じてよい、あるいは Semantic Kernel のプラグイン機構や Function Calling の統合をそのまま使いたい場合は、このライブラリを選ぶ理由は薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 4 日前です。
- 何の言語で書かれている？
- 主に C# です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Python 版の抽象を C# に持ち込む動機
このリポジトリが解こうとしているのは、LLM を使ったアプリケーションの構成要素を C# で組み立てる手段が限られているという問題だ。README は「C# implementation of LangChain」と自己紹介し、Python 版の抽象にできるだけ近づけると述べている。同時に、Semantic Kernel について「useful and we use it wherever possible」としつつ、「it does not cover every scenario and is closely tied to the Microsoft ecosystem」と指摘する。ここが設計の出発点になっている。Microsoft の枠組みでは扱いにくい場面、たとえば Microsoft 製品以外のモデルプロバイダやサードパーティのライブラリを組み合わせたい場合に、選択肢を広く残す方針だ。対象読者は、C# で RAG やプロンプト合成を書きたいが、Python 側の LangChain と同じ語彙で設計を考えたい開発者である。
DocumentLoader から vectorCollection までのデータの流れ
README のコード例は、このライブラリの処理の流れをそのまま示している。まず OpenAiProvider を Environment.GetEnvironmentVariable("OPENAI_API_KEY") から作り、チャット用の OpenAiLatestFastChatModel と埋め込み用の TextEmbeddingV3SmallModel を用意する。次に SqLiteVectorDatabase を vectors.db というデータソースで開き、AddDocumentsFromAsync<PdfPigPdfLoader> を呼ぶ。この呼び出しには埋め込みモデル、dimensions: 1536、DataSource.FromUrl(...)、collectionName: "harrypotter"、textSplitter: null を渡す。textSplitter を省略した場合の既定値は CharacterTextSplitter(ChunkSize = 4000, ChunkOverlap = 200) だと README に書かれている。PDF の取得、テキスト分割、埋め込み生成、SQLite への格納がこの 1 メソッドに集約されている点が、この API の性格をよく表している。dimensions を 1536 に固定する必要があるのは TextEmbeddingV3SmallModel の仕様であり、埋め込みモデルを差し替えるときはこの数値も見直すことになる。
類似文書の取得と 2 通りの回答生成
格納後は 2 つの書き方が提示されている。1 つ目は非同期メソッドを直接呼ぶ方法で、vectorCollection.GetSimilarDocuments(embeddingModel, question, amount: 5) で類似文書を取り、その AsString() をプロンプト文字列に埋め込んで llm.GenerateAsync に渡す。2 つ目が chain による合成で、Set("Who was drinking a unicorn blood?") に始まり、RetrieveSimilarDocuments、CombineDocuments(outputKey: "context")、Template(promptTemplate)、LLM(llm.UseConsoleForDebug()) をパイプ演算子でつなぐ。Set の既定キーは "text" で、chain.RunAsync("text") が最終結果を返す。回答例として README は「The cloaked figure.」を挙げ、llm.Usage と embeddingModel.Usage で使用量と価格を出力できるとしている。パイプで処理をつなぐこの記法は、Python 版の LCEL に近い発想を C# の演算子で表現したものだ。
Semantic Kernel との違いは抽象の縛り方にある
両者は同じ領域を狙うが、抽象の置き方が違う。Semantic Kernel は Microsoft のエコシステムを前提に、プラグインや関数呼び出しの統合を軸に据える。tryAGI/LangChain は README で「We aim to offer the broadest practical choice of implementations and are open to using third-party libraries where appropriate」と述べ、実装の選択肢の広さを優先する。たとえばベクトルストアは SqLiteVectorDatabase のように個別パッケージとして提供され、ドキュメントローダーも PdfPigPdfLoader のようなサードパーティ依存を許容する構成になっている。どちらが優れているという話ではなく、既存の .NET 資産と Microsoft のツールチェーンに寄せるか、Python 版 LangChain の語彙と周辺ライブラリの自由度を取るかという選択になる。
導入時に確認すべきパッケージとテストの所在
README のコード例には依存関係が明記されている。LangChain、LangChain.Databases.Sqlite、LangChain.DocumentLoaders.Pdf の 3 つだ。つまり SqLiteVectorDatabase や PdfPigPdfLoader を使うには本体だけでなく個別パッケージの追加が要る。実行コストの目安として、埋め込み生成と LLM 呼び出しを含む初回が 0,015 ドル、データベースが存在する状態での再実行が 0,0004 ドルという数字がコード例のコメントに添えられている。ただしこれは特定モデルと特定の PDF を前提にした一例であり、一般化はできない。ドキュメントの信頼性については README が正直で、「If the wiki contains outdated code, you can always take a look at the tests for this」として src/Meta/test/WikiTests.cs を挙げ、ほかに examples ディレクトリと src/tests/LangChain.IntegrationTests/ReadmeTests.cs を案内している。wiki が古くなる前提でテストが正とされている点は、評価の際に覚えておく価値がある。
向かない場面と保守体制の読み方
このライブラリが適切でないのは、安定した API の上に長期間据える基盤を求める場合だ。リポジトリの最新リリースは v0.15.0 で 2024-06-27、その前が v0.14.0 で 2024-05-03、v0.13.0 が 2024-03-06 と、0.x 系のまま短い間隔で版が上がっている。0.x は破壊的変更を許容する慣習があり、実際にその前提で読むべき版番号だ。保守体制についても README の Maintainer notes が率直で、「I'm unlikely to be able to make serious progress alone」と述べ、Pull Request は 24 時間以内の受理を目指すとし、コアチームへの参加者を募っている。活発さの裏返しとして、単独の維持者に依存しない体制がまだ整っていないことを示す記述だ。ライセンスは MIT で、README は「We do not plan to change the license in any foreseeable future for this project」とするが、同組織内の派生プロジェクトは別ライセンスになり得るとも書かれている。ここは法務判断ではなく、依存を決める前に自組織のポリシーと突き合わせるべき論点として扱いたい。
採用を決める前に読むファイル
判断の材料は README よりもリポジトリの中にある。まず src/tests/LangChain.IntegrationTests/ReadmeTests.cs を開き、README のコード例が実際にテストとして維持されているかを確認する。次に src/Meta/test/WikiTests.cs を見て、wiki のコードがどの程度追随しているかを測る。使う予定のモデルプロバイダやローダーが examples ディレクトリに現れていなければ、その組み合わせは未整備と考えたほうがよい。chain の記法を採用するなら、Set の既定キーが "text" であること、CombineDocuments の outputKey を "context" に揃える必要があることなど、キー名の取り決めがプロンプト側と密結合になる点も設計に影響する。テストが通る範囲を自分のユースケースに重ねてから、パッケージ参照を追加する順序が現実的だ。
編集部の結論
採用を検討すべきなのは、RAG のパイプラインを C# の型と LINQ 風の演算子で書き、OpenAI 以外のモデルも同じ抽象で扱いたいチームだ。逆に、Microsoft のエコシステムに閉じてよい、あるいは Semantic Kernel のプラグイン機構や Function Calling の統合をそのまま使いたい場合は、このライブラリを選ぶ理由は薄い。導入前に確認するのは 3 点。第一に、NuGet の LangChain パッケージで公開されているバージョンとリポジトリの main の差分。第二に、使う予定のモデルプロバイダとドキュメントローダーが src/tests/LangChain.IntegrationTests にテストとして存在するか。第三に、wiki のコードが src/Meta/test/WikiTests.cs と一致しているか。README 自身が wiki の陳腐化を認めている以上、ドキュメントではなくテストを基準に判断するのが妥当だ。
コミュニティノート