ghfind、GitHubへの辛口評を支える裏側にMiniCPM-V 4.7を投入——だが自社ドキュメントは、それで何が変わるかをめぐって食い違っている

ghfind.com の最下部までスクロールすると、以前はなかった小さな一行があります：モデルスポンサー、MiniCPM のマーク、そして modelbest.cn への外部リンクです。そのマークの背後にあるモデルは、OpenBMB が2026年10月12日に公開した視覚言語モデル MiniCPM-V 4.7 です。あらゆる GitHub アカウントに対して再現可能な0〜100の「価値と信頼」スコアを提供することを全体の売り文句とする製品にとって、モデルスポンサーは見た目だけの細部ではありません — それは、そのモデルが何に触れることを許されているのかという問題です。そして、ghfind 自身のドキュメントはこの問題に対して二つの異なる答えを示しています。このようなリリースの背後で文書化された AI の障害やエージェントのインシデントは、以下に収集されています：OrcaRouter AI Incident Archiveでは、各エントリに独自の情報源、深刻度、信頼度グレード、および異議ありフラグが付いています。

それが書く価値のある物語だ。なぜなら、表面的な版——「GitHubを酷評するサイトがモデルを切り替えた」——はプレスリリースにすぎない。その下にある版は、自社の数字が勘やノリではないと人々に納得させなければならないスコアリング製品が、同時に言語モデルを採用することについての話だ。

ページが実際に示していること、そして示していないこと

スポンサーシップ帯は、公開されている英語版ホームページに実際に存在し、目に見える形で表示されています。その隣には、他に2つのコントロールが並んでいます：独自のモデル / APIキーを使うオプション、およびここにあなたのロゴと記された空のロゴスロットです。つまり、ghfind が宣伝している構造は「当社のモデル、必須」ではなく、既定のスポンサーに加えて、自分のキーを持ち込める逃げ道を用意したものです。これは、ローストのたびにモデルのクレジットを消費する製品としては合理的な設計です。

この変更について繰り返し語られている3つの事柄は、このページには載っていません。第一に、ghfind はサイトのどこにもトラフィック数値を公開していないため、その1日あたりの訪問数を示すどんな数字も ghfind 以外のどこかから来たものです。第二に、「メインモデル」という表現は ghfind のものではありません。ページにはモデルスポンサーと書かれています。第三に、そして最も有用なのは、オープンソースリポジトリが依然としてまったく異なるデフォルトを同梱していることです。その.env.exampleは、roast LLM を StepFun の step-3.7-flash に対して設定しており、テキストがストリームされる前に主要プロバイダーが落ちたりレート制限をかけたりする場合に備えた D​eepSeek のフォールバックを備えています。ghfind をソースからセルフホストする人は、MiniCPM のエンドポイントではなく、その設定を得ることになります。

つまり正確な言い方は狭く、広い言い方よりも興味深い。ホスト版製品ではMiniCPMが名指しのモデルスポンサーである。オープンコードでは、それはデフォルトではない。これらは別の主張であり、読者が目にできるものによって裏付けられているのは最初のものだけだ。

モデルより、プロダクトが先

ghfindはNext.jsアプリケーションで、AGPL-3.0、GitHubで約260スター、本稿執筆の週を通じて継続的にプッシュされています。その中核はLLMではまったくありません。決定論的なTypeScriptエンジン——github-account-valueというオープンソースのPythonスキルから行単位で移植され、両実装を一致させるパリティテストで固定されています——が公開GitHubデータを読み取り、6つの重み付き次元にわたってスコアを算出します。アカウントの成熟度、オリジナルプロジェクトの品質、コントリビューションの品質、エコシステムへの影響、コミュニティへの影響力、活動の真正性です。そこから稼ぎ行為（farming）を示す10のレッドフラッグが減点され、その重みは偽装にコストがかかるシグナル——アカウントが所有していないリポジトリにマージされたプルリクエストなど——に寄せられ、スターやフォロワーのように金で買える安価なシグナルからは遠ざけられています。

その設計の要点は監査可能性にあります。同じGitHubアカウントと同じ収集日が与えられれば、その数値は誰にとっても毎回同じ数値になるはずです。だからこそスコアは、イシューキューのトリアージのような用途に使えるのです。ghfindも、投稿者のバンドで受信イシューにラベルを付けるGitHub Appを通じて、これを実現しています。

モデルが関与するのは下流工程です。確定した結果を、ローストの一文、タグのセット、文章化されたレポートに変換する部分です。そこはユーザーがスクリーンショットを撮って共有する部分であり、スポンサーシップが自然に結びつく部分でもあります。

注目に値する矛盾

ここが二つの文書の分かれ目です。

リポジトリのREADMEには、分離された2つのLLMパスが説明されています。まず事実判定役が上限±10のキャリブレーションを適用でき、次にライターが確定した結果をタグ、トップのロースト一文、レポートに変換します。ライターはスコアを変更できません。その文を二度読んでください。ライターは明示的に数値を動かすことを禁じられており、判定役は明示的に最大10ポイントまで動かすことが許されています——100点満点の尺度で言えば、それは全範囲の10分の1です。

サイト自身のllms.txtは、エージェントとマシン向けに書かれており、さらに強力なことを述べています：完全に決定論的なエンジン……同じ入力は常に同じスコアを生み出し、LLMがその数値に触れることはありません。

両方が同時に真であることはあり得ない。ジャッジパスがデフォルト経路に存在し、±10 の上限が実際に効いているなら、その場合スコアはモデル依存のキャリブレーションを除いて決定的である——あるいは、ジャッジはデフォルト経路になく、README は任意モードを説明している。争いがないのは、リポジトリ自身の記述がモデルによる数値への影響を限定的に想定している一方で、公開向けの機械可読な説明ではその影響が一切ないとされている点である。

これはむしろ重要度が増している。なぜなら、モデルのスポンサーが今やページ上に明記されているからだ。モデルがスコアを10点動かせるのであれば、どのモデルが審査を行っているのかは、ユーザーが尋ねる権利のある問いだ。誰かが不正をしているからではなく、再現性に関する主張の強さは、記録された最も弱い例外によって決まるからである。方法論ページを公開する製品は、読者に対して、2つの記述のどちらが現行なのかを決着させる一文を負っている。

テキスト製品に、なぜビジョンモデルなのか

GitHubスコアリングサイトにマルチモーダルモデルを選ぶのは奇妙に見えるが、モデルが実際に何を渡されているかを見ればそうでもない。MiniCPM-V 4.7はリポジトリを読むよう求められているのではなく、プロンプトを読むよう求められている。視覚言語モデルは、インターリーブ入力で学習されており、構造化出力の指示に従いやすい傾向があるため、またスクリーンショットも受け付けられる単一モデルは、ユーザーがプロフィールのキャプチャをサポートフローに貼り付けた瞬間に有用になるため、安価な汎用ジャッジとしてますます使われている。

コストの論理もある。35B-A3B バリアントは、256 エキスパートの混合構成でトークンあたり約 30 億パラメータを活性化し、1B バリアントはスマートフォン上で動かせるほど小さい密モデルだ。プロファイルスキャンのたびにローストパスが発火する製品にとって、安価に提供できるモデル — あるいは自分で動かせるモデル — は、ローストごとにフロンティア API を呼ぶのとは別の経済的命題になる。サイトが自分のキーを持ち込む方式を用意しているのも同じ理由だ。モデル費用はトラフィックに比例し、トラフィックこそスコアリングサイトが伸ばそうとしているものだからだ。

そうしたパイプラインを自分で構築する場合——決定論的なコアの上にモデルベースのナレーション層を載せる——運用上の問題は、いくつのプロバイダーのキーを保持したいかです。OrcaRouter は200以上のホスト型モデルを0%のマークアップで1つのOpenAI互換エンドポイントの背後に配置し、各プロバイダーの定価をそのまま適用し、プロバイダーが劣化した際には自動フェイルオーバーを行います。そのルーティングDSLは、1回の呼び出し内で安価な判定パスとより高価な執筆パスを異なるモデルに送れます。正直な制約が1つあります。MiniCPM-V 4.7は当社のカタログにないため、それが希望するモデルであればOpenBMB自身のプラットフォームで入手してください。ルーターは、スポンサー提供の単一エンドポイントだけが、あなたと空のローストボックスの間にある唯一のものという状況でも、フォールバック経路を温存しておく役割を担います。

今週時点で、MiniCPM-V 4.7 が実際に何なのか

モデル側にも同じ精密さが求められる。OpenBMBのリポジトリには、2026-10-12付の「MiniCPM-V 4.7 リリース」と読めるNewsエントリがあり、Hugging Faceのリポジトリはその直前の数日、1Bは10月6日、35B-A3Bは10月7日に作成されている。これは段階的な重みアップロードの様相だ。モデルカードはその後に続いた。2026-10-15の2件目のNewsエントリは、両サイズ向けのBF16およびGGUFのDSpark投機的デコーディングヘッドを告知した。

• サイズ — 35B-A3B スパース Mixture of Experts（総パラメータ数352.1億）、および15.5億パラメータの1Bデンス版

• ライセンス — 両方とも Apache 2.0、重みはダウンロード可能、ゲートなし

• コンテキスト — 両方のバリエーションで262,144トークン

• アーキテクチャ — 35Bでは256個のエキスパートを備え、トークンごとに8個がアクティブ。40層にわたる線形アテンション対フルアテンションの3:1パターン。ビジョンタワーは隠れ幅1152で、980ピクセルの入力タイルを使用。

• 量子化 — GGUF、bitsandbytes、AWQ、GPTQ、FP8、int4 ビルドを BF16 重みと併せて公開

• サービング — SGLang、vLLM、llama.cpp、Ollama がサポート対象として記載されており、Ollama にはファーストパーティのエントリがあります

• ベンダーの主張 — iPhone 17 Pro Maxで約3 GBのメモリを使用して毎秒13トークン以上、そしてLookahead Expert Schedulingによるオンデバイスでの5倍の高速化

• 配布状況 — 35B-A3Bリポジトリでは月間約{{1}}95,000ダウンロード{{/1}}、1Bでは{{2}}46,000{{/2}}、いいねは約{{3}}1,079{{/3}}件と{{4}}398件{{/4}}

そのリストにあるものはすべて、モデルカードと設定ファイルから確認できる。まだ利用できないのは独立した評価だ。本稿執筆時点では、Artificial AnalysisのモデルカタログにMiniCPM-V 4.7のどちらのバリアントの項目もない。したがって、毎秒13トークンという数値、5倍の高速化、そして35B-A3Bが「Qwen3.6 35B-A3Bよりも短い推論時間でより高い総合スコアを達成する」という主張は、すべてベンダーによる報告であり、再現されていない。これは公開から8日しか経っていないモデルとしては普通のことだ。そして、スポンサー枠の配置をモデル品質に関するシグナルではなく、ghfindのコスト構造に関するシグナルとして扱うべき理由でもある。

まだ誰も検証できない部分

これでこの物語の二つの半分が再びつながる。ghfindの信頼性は、再現可能だと同社が主張するある数値に依存している。MiniCPM-V 4.7の信頼性は、ベンダーが1週間前に公表したベンチマークに依存している。このスポンサーシップは、モデルが審査者としてどう振る舞うかについて公表された証拠を何も伴わずに両者を結びつけている——人間の評価者との一致率も、モデルバージョン間のドリフト測定も、スポンサーを入れ替えたら誰かのスコアが変わるかどうかの記述もない。

それらはどれも、公開するのは安上がりだが、後で問い合わせを受けると高くつく類のものだ。それに決着をつける具体的な測定は再スコアリングテストだ。固定したアカウントのサンプルを用意し、ジャッジパスを有効にした場合と無効にした場合でパイプラインを実行し、差分の分布を報告する。もしゼロ付近に集中するなら、±10は誰も触れない安全柵であり、「LLMは数値に一切触れない」という文言は実質的に正しい。もしばらつくなら、キャリブレーションは実際に効いており、方法論ページにその旨を明記する必要がある。

それまでのところ、正直な読み方はこうだ。ghfindは、数値と文章の分離が異例なほど明確な、よくできた決定論的スコアラーであり、今では名前を明示したモデルスポンサーがいるが、そのパイプラインにおける役割は自らのファイル間で一貫性なく文書化されている。MiniCPM-V 4.7は、8日前にモデルカードとDSparkのフォローアップを伴って登場した、実在し、Apacheライセンスで、メモリフットプリントが本当に小さいマルチモーダルリリースであり、独立したベンチマークはない。これらの事実はどちらもスキャンダルではない。どちらも、ホームページではなくリポジトリを読んで初めて気づく類のことであり、他人の仕事を採点する製品にとっては、読者にできる最低限のことだ。

自分のスコアを具体的に確認する方法

サイトにプロフィールがあるなら、テストすべきは決定論的な経路です。ghfind は認証もモデル呼び出しも不要なスコアエンドポイントを公開しており、基盤となるスコアリングスキルはオープンソースなので、API から得られる数値とサイトから得られる数値は一致するはずです。一致しない場合、その差は収集タイミング（サイトは1日キャッシュします）かキャリブレーションパスのどちらかであり、繰り返し実行しても差が安定しているかどうかを確認することで区別できます。

同様のツールを作る人にとって、ghfindから得られるアーキテクチャ上の教訓は、モデルに関するニュースよりも価値がある。数値はコードに置き、散文はモデルに置き、両者の境界を読者が検査できるほど明確にせよ。失敗モードはLLMを使うことではない。失敗モードは、境界を2か所で文書化し、その2つの説明をずれさせることだ。

次に注視すべきことは限られている。ghfind には公開チェンジログと、ほぼ毎日プッシュされているリポジトリがあるため、±10 のキャリブレーションと「no LLM」という方針を整合させる方法論の注記はすぐに目に留まるだろう。モデル側では、MiniCPM-V 4.7 の最初の独立系ベンチマーク、あるいは大量処理時に1回のローストあたりいくらかかるかについての最初の報告が、スポンサーシップを議論に変える数字になる。どちらもまだ存在しない。どちらもあと1本の公表で現れる。