確認日：2026年10月10日。今回は、LLMの接続口、動画からの3D復元、設計図の作り方を扱います。用途が異なる3件を「試せるか」「設計を学べるか」で選びました。
| Repository | 何これ？ | 最短の入口 | 私の評価 |
|---|---|---|---|
| LiteLLM ↗ | 複数LLMを共通APIで呼ぶSDK／Gateway | Python SDK | ★★★★★ |
| LingBot-Map ↗ | 連続画像から3D形状とカメラ姿勢を推定 | 公開Demo | ★★★★☆ |
| diagram-design ↗ | Agentに編集可能な図解を作らせるSkill | Gallery／Skill | ★★★★☆ |
1. LiteLLM ↗：LLM接続を共通APIへ寄せる
結局何なのか。 複数のLLM提供元を同じ呼び出し形式で扱うPython SDKと、認証・利用量管理・ルーティングを集約するGatewayです。SDKをアプリへ組み込む方式と、複数アプリから中央Gatewayを使う方式を選べます。
技術的に面白いところ。 共通API化の価値は、モデル名を置き換えるだけではありません。提供元ごとに異なる認証、失敗時の再試行、費用記録を、呼び出すアプリの外側へ移せることです。ただし機能や返却形式まで完全互換になるわけではありません。
最短で試す。 Python環境なら、README掲載の uv add litellm からSDKを導入できます。まず一つの提供元で呼び出し、次に別の提供元へ切り替えて差分を確認します。中央Gatewayを試すなら公式Docker Quick Startが入口です。
導入判断を変える注意点。 LICENSEによると、原則MITですが enterprise/ 以下は別ライセンスです。GatewayはAPIキー、入力データ、利用ログが通る境界になります。認証・ログの保存先・外部への送信・予算上限を確認してから共有環境へ出してください。READMEの性能数値は開発元の計測として扱い、実環境で再測定するのが適切です。
私の判断。 実用枠。2社以上のモデルを使う、または複数アプリの費用と権限を管理したい場合に特に有力です。単一モデルの小さなスクリプトにはGatewayが過剰なこともあります。
2. LingBot-Map ↗：動画から連続的に3Dを復元する
結局何なのか。 動画や連続画像から、カメラの位置関係と3Dの幾何情報を推定する研究実装です。Geometric Context Transformerを使い、長い映像列を順に処理する設計を公開しています。
技術的に面白いところ。 1枚ごとの推定だけでは、長い移動で位置のずれが蓄積します。この実装は参照フレームや軌跡の文脈を持ち、逐次推定と長距離の整合性を同時に扱おうとしています。以下はREADMEの説明を簡略化した概念図で、実装の全内部構造を表すものではありません。
最短で試す。 まずREADMEのDemoとサンプル結果を確認します。自分で動かす場合はPython 3.10の環境を作り、推奨のPyTorch 2.8.0／CUDA 12.8、公開Checkpointを準備して python demo.py --model_path ... --image_folder example/courthouse を実行します。結果はローカルViewerで確認できます。
導入判断を変える注意点。 Apache-2.0。GPUとCUDAの組み合わせが重要で、長い映像では計算資源が必要です。READMEにはFlashInferを使わないSDPA経路やCPUへの一部退避策もあります。速度・精度の主張は開発元の評価であり、利用する動画やGPUで同じ結果になるとは限りません。
私の判断。 技術トレンド枠。映像を3Dへ変換する成果だけでなく、長時間の逐次処理で「過去の文脈をどこまで保持するか」を見ると面白いです。
3. diagram-design ↗：図の意味と見た目を分離する
結局何なのか。 Coding Agentへ図解を作らせるためのSkillとテンプレート集です。Architecture図、Sequence図、比較図などをHTML＋SVGで生成し、必要に応じてPNGへ出力できます。
技術的に面白いところ。 「どの情報をどう関係付けるか」という意味のパターンと、「どんなレイアウトにするか」という見た目の型を分けています。単に箱と矢印を描くのではなく、情報の種類に合わせて図の文法を選ぶ設計です。既存のMermaidやdraw.ioから描き直す入口もあります。
最短で試す。 まずREADMEのGalleryを開き、目的に近い図を一つ選びます。対応AgentへSkillを導入する場合は npx skills add cathrynlavery/diagram-design が選択肢です。細かな操作はCookbookにあります。
導入判断を変える注意点。 MIT。PNG書き出しにはPlaywrightとChromiumの準備が必要です。外部Skillの指示やスクリプトは導入前に確認し、生成したHTML・SVGも表示確認してください。ブランド情報をサイトから取り込む機能では、取得元と保存される設定も点検したいところです。
私の判断。 発想枠。見た目の美しさより、図の意味・表現形式・書き出しを分離した設計が参考になります。単純な関係ならMermaidの方が軽く、すべての図をこの仕組みに置き換える必要はありません。
3件を比べる
| Repository | 実用性 | 技術的な面白さ | 最短の入口 | 主な注意点 |
|---|---|---|---|---|
| LiteLLM | ★★★★★ | ★★★★☆ | Python SDK | APIキー・ログ・商用機能の区分 |
| LingBot-Map | ★★☆☆☆ | ★★★★★ | 公開Demo | GPU環境・再現性 |
| diagram-design | ★★★★☆ | ★★★★☆ | Gallery／Skill | 外部Skill・描画検証 |
今日1件だけ見るなら
LiteLLM です。複数のモデルを使う開発では、APIの呼び分けより「認証・費用・失敗処理をどの層で持つか」が運用上の課題になります。まずSDKで二つの提供元の違いを観察し、中央管理が必要になってからGatewayを採用する順番が無理のない判断です。