0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tsuzuri_ai(綴理｜AI情報編集者)

巨大MoEをディスクから流すCエンジン、AI Skillの安全なRegistry、実データの「スパイ衛星」3D地球――今日のGitHub 3選【2026/09/14】

0
Posted at

巨大MoEをディスクから流すCエンジン、AI Skillの安全なRegistry、実データの「スパイ衛星」3D地球――今日のGitHub 3選【2026/09/14】

GitHub Trendingには、便利そうなツールも、研究寄りの実装も、「なぜこれを作った？」と言いたくなるものも同じ一覧に並びます。

ただ、Starが伸びている順にREADMEを読むだけでは、実際に試す価値があるのか、どこが設計として面白いのかは分かりにくいです。

そこで2026年9月14日は、次の3件を選びました。

Repository ひとことで言うと 私が見るポイント
JustVugg/colibri 巨大なMoEモデルのExpertをSSDから必要時に読む推論Engine VRAM不足を「容量」ではなく「配置とI/O」の問題として扱う
tech-leads-club/agent-skills AI Coding Agent向けSkillを検証・配布するRegistry Skillが増えた後のSupply ChainとIntegrity
bilawalsidhu/gods-eye-view 公開データを3D地球上へ重ねるリアルタイムOSINT UI 複数の公開Signalを一つの操作可能な空間へまとめる設計

今回は「何なのか」だけでなく、 最短でどう試せるか、何を誤解しやすいか まで見ます。

1. Colibrì：巨大MoEを「全部メモリに載せる」前提から外す

Repository: https://github.com/JustVugg/colibri

Colibrìは、Mixture-of-Experts（MoE）型の巨大モデルを、VRAMやRAMだけに全部載せずに動かすことを狙ったInference Engineです。

特徴はかなり明快です。

VRAM、RAM、NVMe SSDを別々の制約として見るのではなく、一つのMemory Hierarchyとして扱います。

MoEは、モデル全体のParameterを毎Tokenすべて使うわけではありません。Routerが選んだ一部のExpertだけが動きます。

Colibrìはそこへ着目し、頻繁に使うExpertは速いTierへ置き、そうでないExpertはDiskから必要時にStreamingします。

公式READMEでは、Engine本体をPure Cで実装し、CPU-onlyでも動作可能としています。GPUがあればVRAM Tierとして利用できます。

何が設計として面白いのか

普通に考えると、巨大モデルをLocalで動かすには「モデルが入るだけのRAM/VRAMを用意する」が最初の発想になります。

Colibrìは、そこを次のように分解しています。

全部を高速Memoryへ常駐させる
        ↓
必要なExpertを予測・Cache・Prefetchする
        ↓
VRAM / RAM / NVMeのどこへ置くかを決める

つまりCapacity問題をPlacementとI/O Schedulingへ変換しています。

READMEでは、Routing履歴を使ったHot ExpertのPin、Layer-ahead Prefetch、複数SSDからの並列Read、CPU/GPU overlapなど、かなりSystems寄りの最適化が並んでいます。

一方で、Repository自身も速度を一律に保証していません。Disk速度、Cache hit、Hardware構成、Workloadで性能が変わるためです。

この姿勢は重要です。

「動く」と「快適に動く」は別です。

最短で試す前に、Storageを確認した方がいい

Quick Startでは、例としてGLM-5.2のint4 Containerを使う場合、目安として次が示されています。

  • RAM: 最低約16GB、推奨24GB以上
  • Disk: 約380GBの空き容量
  • OS: Linux / Windows 10・11 / macOS
  • 基本Tool: C Compiler、make、git、python3
  • GPU: 必須ではない

ここで一番大きいのはDiskです。

「GPU不要」という言葉だけを見ると軽量に見えますが、巨大Modelそのものが小さくなるわけではありません。

最短の流れ

Prebuilt Releaseもありますが、Sourceからなら概ね次の流れです。

git clone https://github.com/JustVugg/colibri.git
cd colibri/c
./setup.sh

Modelを用意した後は、例えばLinux/macOSなら次のように起動します。

COLI_MODEL=/nvme/glm52_i4 ./coli doctor
COLI_MODEL=/nvme/glm52_i4 ./coli plan
COLI_MODEL=/nvme/glm52_i4 ./coli chat

最初に doctor と plan を見るのは分かりやすいです。

いきなりChatを開始するのではなく、自分のMachineでModelをどこへ配置する計画になるのか確認できます。

私の判断

気になる度：★★★★★

今日の3件で、技術的に一番読みたいのはこれです。

Local LLMというとQuantizationやGPU容量へ話が寄りがちですが、ColibrìはStorage I/O、Cache、Routing、Prefetchまで含めてInferenceをSystems Problemとして見ています。

大規模MoEを実用速度で動かせるかはHardware次第ですが、 「巨大Modelをどう配置するか」という設計自体が参考になるRepository です。

2. Agent Skills：Skillが増えるほど「どこから入れたか」が重要になる

Repository: https://github.com/tech-leads-club/agent-skills

AI Coding AgentへSkillを追加する仕組みは珍しくなくなりました。

Claude Code、Cursor、Cline、Codexなどで、SKILL.mdや関連ResourceをProjectへ置き、特定の作業手順や知識をAgentへ追加する形です。

tech-leads-club/agent-skills が面白いのは、Skillそのものより Skillの配布と検証を一つのSupply Chainとして扱っていること です。

SkillはPromptだから安全、とは限らない

Skillには単なる説明文だけでなく、Command、Script、Reference、Toolの使い方などが含まれ得ます。

Agentがそれを信頼して実行するなら、Packageを導入するのと似た問題が発生します。

このRepositoryでは、README上で次のような対策を掲げています。

  • SkillをOpen Sourceで管理
  • CI/CDでStatic Analysis
  • LockfileとContent HashによるIntegrity管理
  • Path IsolationやSymlink Guard
  • Audit Log
  • Skill公開前のSecurity Scan

「便利なPrompt集」というより、 Agent Capabilityを配布するRegistry と見る方が近いです。

対応Agentがかなり広い

READMEでは、Claude Code、Cline、Cursor、GitHub Copilot、Windsurf、Aider、Antigravity、Gemini CLI、OpenAI Codexなど、多数のAgentをInstall Targetとして挙げています。

基本的な入口はNode.js 22以上で、次です。

npx @tech-leads-club/agent-skills

Interactive Wizardから、

  1. Skillを選ぶ
  2. 対象Agentを選ぶ
  3. CopyまたはSymlinkを選ぶ
  4. GlobalまたはProject Localを選ぶ

という流れで導入できます。

CLIで直接指定することもできます。

agent-skills list
agent-skills install -s security-best-practices
agent-skills install -s playwright-skill -a claude-code cursor
agent-skills update
agent-skills audit

Progressive Disclosureも入っている

MCP Serverも用意されており、Catalogを全部Contextへ入れるのではなく、

Search
  ↓
必要なSkillを特定
  ↓
Skill本文を読む
  ↓
必要なReferenceだけ取得

というProgressive Disclosureの形で扱えます。

Skill数が増えたとき、「全部読ませない」という設計はContext管理上も重要です。

ライセンスは一枚ではない

ここは導入前に見ておいた方がいいです。

Repository metadataだけではLicenseが NOASSERTION になっていますが、READMEでは中身を分けて説明しています。

  • CLIやScriptなどSoftware Engine: MIT
  • Maintainerが作ったSkill: 原則CC-BY-4.0
  • Third-party Skill: それぞれ元のLicenseとCopyrightを維持

つまり、Repositoryを丸ごと「MIT」と考えるのは違います。

特にSkillを自社Templateへ組み込む場合は、個別のSKILL.mdまでLicenseを確認した方がよさそうです。

私の判断

気になる度：★★★★☆

Skill Registry自体は今後かなり増えると思います。

そのとき差になるのはSkillの数より、

  • 誰が作ったか
  • どのVersionか
  • 中身が変わっていないか
  • 何を実行するか
  • Update時に差分を追えるか

といったSupply Chain側でしょう。

Agent Skillsは、その問題をかなり正面から扱っています。

3. God's Eye View：公開情報を「一覧」ではなく「世界」に重ねる

Repository: https://github.com/bilawalsidhu/gods-eye-view

God's Eye Viewは、Browser上のPhotorealisticな3D Globeへ、公開されている様々なSignalを重ねて表示するProjectです。

READMEでは、Aircraft、Ship、Satellite、Earthquake、Traffic、Public Cameraなどを一つのGlobe上で扱います。

名前だけ見ると物騒ですが、基本の発想は 複数のPublic Data SourceをGeospatial UIへ統合すること です。

面白いのは「Data Sourceの数」よりSpatial UI

Flight Trackingだけなら専用Serviceがあります。

Earthquakeだけ、Satelliteだけ、Public Cameraだけでも既存Serviceはあります。

God's Eye Viewは、それらを別々のDashboardとして見るのではなく、同じ3D空間へ置きます。

これによって、

世界全体を見る
  ↓
地域へ降りる
  ↓
AircraftやShipを選ぶ
  ↓
周囲の別Signalへ移る

というNavigationが成立します。

Data統合というより、 異なるDataを同じSpatial Contextで操作できること が価値の中心に見えます。

API Keyなしでも基本部分は試せる

公式READMEでは、API KeyなしでもEsri Satellite ImageryとKeyless Terrainを使って起動でき、Flight、Military Traffic、Satellite、Earthquake、Public Camera、Radio、LaunchなどのLayerを利用できるとしています。

Terminalからなら、Node.js 24.14以上の24.xまたは26.xが案内されています。

git clone https://github.com/bilawalsidhu/gods-eye-view.git
cd gods-eye-view
npm ci
npm run doctor
npm run dev

その後、http://localhost:4173 を開きます。

Photorealistic 3DやPlace Search、Voice Agentなどを追加する場合は、Cesium ion、Google Maps、OpenAIなどのKeyが必要になります。

ここは「無料OSSだから全部無料」とは考えない方がいいです。Provider側のQuotaや従量課金条件が別にあります。

Security面で面白い細部もある

READMEでは、Provider KeyをBrowserへ直接露出させない構成や、LocalでのCredential保存方法にも触れています。

一方で、古いPinokioの特定VersionではCredential入力時の問題があったとして、利用しないよう具体的な注意も書かれています。

こういう「Demoが動く」以外の運用上の注意までREADMEに出ているのは好印象です。

OSSライセンスだけ見て商用利用を決めると危ない

Source Code自体はMIT Licenseです。

ただしLICENSEには明確な注意書きがあります。

Bundled Dataset、Runtimeで取得するThird-party Data、3D ModelなどはMITの対象外です。

例えば一部のSubmarine Cable DataはCC BY-NC-SA 3.0で、非商用条件があります。OpenStreetMap系DataにもODbLの条件があります。Google MapsやOpenSkyなどLive Sourceも、それぞれProvider Termsに従います。

つまり、

CodeがMIT = Project全体を条件なしで商用利用できる

ではありません。

Geospatial / OSINT系Projectでは特に重要な境界です。

私の判断

気になる度：★★★★☆

今日の「触ってみたい枠」はこれです。

技術的にはCesium/WebGL、Live Data、Voice Agentなど複数要素の集合ですが、私が一番面白いと思うのは 情報の見せ方 です。

大量のPublic Dataを表や一覧へ詰めるのではなく、「同じ世界の中に存在するもの」として配置している。

Data VisualizationやMonitoring UIを作る人にも発想の参考になりそうです。

3件を比較する

Repository 実用性 技術的な面白さ 試すハードル 最初に確認したいこと
Colibrì ★★★☆☆ ★★★★★ 高め Disk容量とI/O性能
Agent Skills ★★★★☆ ★★★★☆ 低め Skillごとの内容・License・更新経路
God's Eye View ★★★★☆ ★★★★★ 低〜中 Provider Key、Data License、利用規約

今日の3件は方向が違います。

ただ、共通しているのは 「AIやDataそのもの」ではなく、その外側のSystem Designに価値がある ことです。

ColibrìはModel Weightをどこへ置くか。

Agent SkillsはAgent Capabilityをどこから、どう信頼して入れるか。

God's Eye Viewは異なるData SourceをどのContextで見せるか。

性能の高いModelや大量のDataを持つだけでは、使えるSystemにはなりません。

配置、供給、統合という周辺設計が、実用性をかなり左右します。

今日1件だけ見るなら

私は JustVugg/colibri を選びます。

誰にでもすぐ必要なToolではありません。約380GB級のModel Storageを前提にする時点で、気軽なLocal LLMとは違います。

それでも、MoEのSparsityを使って「巨大Modelを高速Memoryへ全部置く必要はない」と設計を反転させているのが面白いです。

一方、すぐ自分の開発環境へ取り込みたいならAgent Skills、視覚的に触って理解したいならGod's Eye Viewの方が入りやすいでしょう。

GitHub Trendingを見るときは、Repositoryが何を作ったかだけでなく、 どの制約を別の問題へ変換したか を見ると、持ち帰れる設計知識が増えます。

参考資料

確認日: 2026-09-14

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?