2026年9月21日時点で、今日見ておきたいGitHub Repositoryを3件だけ選びました。今回は「AIへ渡す文書を整える」「小さな端末でAIを動かす」「複数サービスを実アプリへ束ねる」の3方向です。
| Repository | 何これ？ | 最短の入口 | 私の評価 |
|---|---|---|---|
| Docling ↗ | PDFやOffice文書を構造付きでAI向けに変換 | pip install docling |
★★★★★ |
| Needle ↗ | 8〜29MB級でtool calling・抽出・embeddingを行う端末AI | pip install cactus-needle |
★★★★★ |
| OpenStock ↗ | 株価・Watchlist・AlertをまとめたOSS株式ダッシュボード | Docker / Next.js | ★★★★☆ |
1. Docling ↗：生成AIの前段で「文書の構造」を失わない
結局何なのか
Doclingは、PDF、DOCX、PPTX、XLSX、HTML、画像、音声、EPUB、メールなどを解析し、MarkdownやHTML、lossless JSONなどへ変換する文書処理Toolkitです。
単なる「PDFから文字を抜くLibrary」ではありません。ページLayout、Reading Order、表、Code、数式、画像分類などを読み取り、共通の DoclingDocument 表現へ揃えるのが中心です。生成AIへ入れる前に、文書をただの長い文字列へ潰さず、後段が扱える構造へ変換します。
技術的に面白いところ
RAGではVector DBやLLMが目立ちますが、その前段で表・見出し・読み順を壊せば、後段が高性能でも元に戻せません。Doclingは「文書理解」を独立した境界に置き、複数Formatを一つのDocument Modelへ正規化します。
さらにLocal実行やair-gapped環境を想定し、OCR、VLM、MCP Server、API Serverまで同じEco-systemで用意しています。Parser単体で終わらず、Agentへ渡す入口まで伸びているのが現在のDoclingを見るポイントです。
最短で試す
Python 3.10以降が現在の前提です。
pip install docling
docling https://arxiv.org/pdf/2206.01062
これだけで構造化されたMarkdownを出力できます。Pythonからは DocumentConverter を使えます。
注意点
CodebaseはMITですが、利用する個別ModelにはそれぞれのLicenseがあります。Docling本体のLicenseだけを見て、VLMやOCR Modelまで同条件だと決めない方が安全です。
また「多形式を読める」と「どんな複雑文書でも正確に読める」は別です。表、数式、Scan品質、Layoutによって抽出品質は変わるため、実際の業務文書をSampleにして評価する必要があります。Repositoryは2024年から続き、2026年9月20日にも更新されており、3件の中では成熟度が高い部類です。
私の判断
今日の実用枠です。
生成AI活用ではModel選定より前に「入力をどう壊さず渡すか」が効く場面が多い。PDF・Office文書をRAGやAgentへ入れているなら、独自Parserを増やす前に一度見る価値があります。
2. Needle ↗：大きなChat Modelではなく、小さな「行動モデル」を端末へ置く
結局何なのか
NeedleはMobile、Wearable、Robot、Smart Home、車載、Microcontrollerなどを狙った小型Foundation Modelです。現在のNeedle 3は、8〜29MB級のBinaryでtool calling、structured extraction、text embeddingを扱います。
重要なのはChatbotを小さくしたものではないことです。一般会話能力を広く持つ代わりに、Appが公開したFunctionを選ぶ、Schemaに沿って情報を抜く、Local検索用Vectorを返す、といった狭い仕事へ寄せています。
技術的に面白いところ
Needle 3は2〜20 Layerの各DepthをDeploy可能にするLaddered Architectureを採り、製品やDeviceに合わせてCapacityを落とせる設計です。SchemaからCompileしたByte-level Grammarで出力を制約し、Confidence Headも持ちます。
ここで面白いのは「何でも答えるModelを端末へ押し込む」のではなく、Agent Systemのうち Routing・Extraction・Action Selectionだけを小型Modelへ切り出す 発想です。Cloud LLMを完全に置き換えなくても、頻繁な小判断をLocalへ戻す余地があります。
最短で試す
Pythonなら入口は短いです。
pip install cactus-needle
Python FunctionへDecoratorを付け、Needle(tools=[...]) に渡せます。Platform別のPrebuilt Engineも用意され、needle build でWeightsと組み合わせられます。
注意点
LicenseはApache-2.0です。一方、README掲載BenchmarkはProject自身による評価なので、導入時は自分のTool Schema・言語・曖昧な依頼で再評価すべきです。
BinaryではTelemetryが既定でONで、READMEでは NEEDLE_TELEMETRY=0 と DO_NOT_TRACK=1 で無効化できるとしています。またLocal fine-tuningは4-bitで可能ですが、公開されている2-bit Post-training / Quantizationの一部はCactus PlatformとProprietary Datasetを使います。「完全にOSSだけで同じTraining Pipelineを再現できる」とは見ない方がよいです。
Repositoryは2026年2月作成で、2026年9月19日にも更新されています。勢いはありますが、Doclingほど長期の運用実績があるProjectではありません。
私の判断
今日の技術トレンド枠で、今日1件だけ見るならNeedleです。
Agentが増えるほど、すべての判断を巨大Modelへ送る設計はLatency・Cost・Privacyの面で重くなります。Needleが面白いのは「小型LLM」そのものより、Agentの仕事を分解して、小さな専門Modelで十分な境界を探している点です。
3. OpenStock ↗：株価アプリを題材に「外部サービス統合」の現実を見る
結局何なのか
OpenStockは、株価検索、Watchlist、Company情報、Chart、Market Overview、Alert、Personalized EmailなどをまとめたOpen-sourceの株式Dashboardです。
Next.js 15 / React 19を中心に、MongoDB、Better Auth、Finnhub、TradingView、Inngest、Nodemailerを組み合わせています。OptionalでGemini等を使ったPersonalized Messageも扱います。
技術的に面白いところ
派手な新Algorithmより、一つの実用Web Appへ複数の外部責務をどう束ねるかを見るRepositoryです。
AuthenticationとUser DataはMongoDB、Market DataはFinnhub、ChartはTradingView、非同期WorkflowはInngest、EmailはNodemailerへ分けています。OSSを読む目的としては「株アプリを使う」だけでなく、API依存の多いNext.js ApplicationのReference Implementationとして眺める方が面白いです。
最短で試す
Node.js 20+とMongoDB、Finnhub API Keyが主な前提です。Docker ComposeでMongoDBとAppを立ち上げる経路もあります。
git clone https://github.com/Open-Dev-Society/OpenStock.git
cd OpenStock
pnpm install
pnpm dev
ただしClone直後に完全動作するDemoではなく、.env へ各Serviceの設定が必要です。
注意点
LicenseはAGPL-3.0です。READMEでも、改変・再配布・Web ServiceとしてDeployする場合を含めSource公開義務を明記しています。SaaSの雛形として流用するなら、最初にLicense適合を確認すべきです。
またOpenStock自身はBrokerageではなく、Market DataはProviderや設定により遅延し得ます。FinnhubのFree Tierで始められても、Real-time Dataは有料条件になる場合があります。さらにMongoDB、Market Data、Email、Workflowなど外部依存が多いため、Self-hostedだから即「無料・Local完結」という構成ではありません。
Repositoryは2025年9月作成で、2026年9月19日にも更新されています。
私の判断
今日の変わり種／発想枠です。
新しいAI Frameworkではありません。ただ、実際のProductはModel単体では成立せず、Auth・DB・Data Provider・Async Job・UIを接続して初めて使えます。AI Repositoryばかり追っている日に、こういう「統合の現実」が見えるCodebaseを1件混ぜる価値があります。
3件を比べる
| Repository | 実用性 | 技術的な面白さ | 最短の入口 | 主な注意点 |
|---|---|---|---|---|
| Docling ↗ | ★★★★★ | ★★★★☆ | pip install docling |
個別Model License・文書ごとの抽出品質 |
| Needle ↗ | ★★★★☆ | ★★★★★ | pip install cactus-needle |
自己Benchmark・Telemetry・一部Training経路 |
| OpenStock ↗ | ★★★★☆ | ★★★★☆ | Docker / Next.js | AGPL・外部API・Market Data条件 |
今日1件だけ見るなら
Needleを選びます。
理由は8〜29MBという数字そのものではありません。Agent Architectureを「大きなModelを1個置く」から、仕事の性質に応じてModel Sizeと実行場所を変える方向へ考え直せるからです。
Doclingはすでに実務投入を検討しやすい成熟した道具です。OpenStockはFull-stack統合の教材として面白い。一方Needleは、今後のAppやAgentで「この判断、本当にCloudの巨大Modelが必要か？」という設計質問を持ち帰らせてくれます。