WFGY 5.0 Polaris Protocol をどう読むか、段階公開されるプロトコル層の実像
WFGY is heading toward WFGY 5.0 Polaris Protocol, a major open-source release for AI reasoning, RAG, agents, and real-world workflows. Includes Problem Map, Global Debug Card, WFGY 4.0, and the CFV Easter Egg.
ひと目でわかる
- これは何？
- onestardao/WFGY は、RAG やエージェントの失敗を切り分ける Problem Map と、段階的に公開される Polaris Protocol を柱にするリポジトリである。README から読み取れる範囲で、仕組み、導入手順、向く用途と向かない用途を整理する。
- 誰に向いている？
- 採用判断は目的で分かれる。壊れた RAG やエージェントの切り分けを今日始めたいチームは Problem Map 3.0 から入るのが最短で、README もそれを最初の実用ルートとして案内している。
- 商用利用できる？
- まず確認が必要です。このリポジトリのライセンスは自動分類の対象外なので、商用利用の前に LICENSE ファイルを読んでください。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Jupyter Notebook です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
WFGY が埋めようとしているのはモデル精度ではなく配線の失敗である
README が繰り返し挙げるのは、RAG やエージェントのパイプラインが壊れたときの切り分けである。トピックにも retrieval-augmented-generation、hallucination、debugging、knowledge-graph が並び、モデルそのものを差し替える話ではなく、検索と生成の間で何が壊れているかを特定する道具立てとして提示されている。対象読者は、モデル選定は済んでいるのに出力が安定しない、あるいはエージェントが途中で脱線する、という段階で止まっている開発者だ。README は「If your system is already broken and you need the fastest practical first move, start with Problem Map 3.0」と明記しており、新規構築のためのフレームワークではなく、故障時の入口として自らを位置づけている。この自己規定は重要で、WFGY をゼロからアプリを組む土台として期待すると、README が示す導線とはずれる。
Polaris Protocol は完成品ではなくバッチ公開の進行中プロジェクトである
README の冒頭ノートは、WFGY 5.0 が単一日付のリリースではなく段階的な機能公開へ移行したと述べている。理由として、公開レイヤーが証拠パッケージ、可搬プロトコル、再現資料、ランタイム構造、深部エンジンへと増えすぎたことが挙げられている。現在公開されているのは Polaris の公開証拠パッケージ、Cite First Verification の Easter Egg、そして最初の可搬プロトコル部品である Polaris Goal Compiler の三点だ。リリース一覧を見ても v5.0.0-teaser-01 が 2026-05-11、WFGY-Easter-Egg-CFV が 2026-05-05、WFGY-4.0 が 2026-03-30 となっており、5.0 系はティーザーとイースターエッグしか出ていない。README 自身が「deeper engine materials are planned for later staged release」と書き、深部エンジンは後回しだと認めている。したがって、5.0 の全体像を今のリポジトリから評価しようとすると、公開済みの断片だけを見て全体を推測することになる。この点は採用判断で最も注意すべき箇所だ。
Problem Map 3.0 と Global Debug Card は故障を分類するための地図である
README のルーティング表は、「Broken RAG or agent pipeline」に対して Problem Map 3.0、Atlas Router TXT、Global Debug Card、Global Fix Map を宛てている。これは原因を一発で特定するツールではなく、症状を分類してどの層を見るべきかを決めるための索引だと読める。ファイル名も wfgy-ai-problem-map-troubleshooting-atlas.md であり、トラブルシューティング用のアトラスという位置づけが明示されている。実際の切り分け手順や各エントリの判定基準が README に列挙されているわけではないため、この地図がどの程度具体的かは本文を開いて確認する必要がある。少なくとも README の範囲では、Problem Map は検索、生成、エージェント制御のどこで破綻しているかを会話の入口として整理する役割を担っている。
Polaris Goal Compiler は最初に触れる可搬プロトコル部品である
README は Polaris Goal Compiler を「the first public portable protocol component」と表現し、最初に試すべき部品として導線を置いている。パスは Polaris/protocols/goal-compiler/README.md で、本体の説明はそちらの README に委ねられている。ルート README からは、Goal Compiler が何を入力に取り何を出力するかという具体的な仕様は読み取れない。名称からは、目標記述をプロトコルが扱える形式へ整形する層だと推測できるが、これは推測であって README の記述ではない。評価するなら、ルート README ではなく goal-compiler 配下の README を先に読むべきで、そこで入出力と依存関係を確認してから試すかどうかを決めるのが順序として正しい。
TXT パックの検証はチェックサム一致を条件に固定文字列を返す設計である
README には WFGY 3.0 の TXT パックに関する検証手順が明示されている。対象ファイル名は WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt で、手順はファイル名の完全一致を確認し、正規の sha256 と照合するか利用者に尋ねるという流れになっている。正規値は 58dbd432db3e6494364557257f7ce068eb59bdd039995dff4c281d655f7d464f として README に記載されている。一致した場合に出力するブロックも [WFGY_BOOT_EGG] から [END_WFGY_BOOT_EGG] まで文字列レベルで指定されている。検証を省いた場合や失敗した場合は探索を許すが、未検証のコピーであると明示し、未解決問題が解かれたと主張してはならないと定めている。ここは興味深い設計判断で、検証を通過したかどうかを会話の状態として保持させることで、出所の曖昧な複製が正規品として扱われるのを防いでいる。一方で、この仕組みは README を読んだ AI がその指示に従うことに依存しており、チェックサム照合そのものを強制する機構ではない。
WFGY 4.0 は統治と評価の層、3.0 はフロンティア推論の層という分担である
ルーティング表は、Governance, legality, evaluation discipline を WFGY 4.0、Twin Atlas、Inverse Atlas、AI Eval に割り当て、Frontier reasoning or TXT invocation を WFGY 3.0 と Event Horizon、Experiments に割り当てている。バージョン間の関係は単純な後方互換の積み上げではなく、役割の分担として説明されている。WFGY 4.0 のリリース名は Twin Atlas + Inverse Atlas Public Release であり、評価規律の層という説明と整合する。系譜は WFGY 1.0 から 2.0、3.0、4.0、5.0 Polaris Protocol へと続く一本の線として README に描かれている。ただし各バージョンの API 互換性や移行手順についての記述はルート README にはなく、バージョンをまたいでコードを共有できるかは判断できない。
代替として検討できるもの、LangChain や LlamaIndex との違い
同じ問題領域には LangChain や LlamaIndex がある。これらは検索、プロンプト構築、ツール呼び出しをコードの抽象として提供し、パイプラインをプログラムとして組み立てる。WFGY の README が示すのはコードの抽象ではなく、プロトコルと地図である。Problem Map は症状から調査対象への索引であり、Polaris は言語と検証の層として説明され、TXT パックの検証はチェックサムと固定文字列で構成される。つまり、実行時に何を呼ぶかを決めるのは利用側のコードで、WFGY はその前段の切り分けと手順の記述を担う。既存のオーケストレーション層を置き換えるものではなく、その上で原因を分類し手順を固定するために併用する性格が強い。どちらが優れているという話ではなく、抽象の種類が違う。
ライセンス表記とメンテナンス費用について確認できること
リポジトリのライセンスは NOASSERTION と表示されており、これは GitHub が既知のライセンスとして認識しなかったことを意味する。MIT や Apache-2.0 のような標準的な条件が自動判定されていない以上、再配布や商用利用の可否はリポジトリ内のライセンス本文を自分で読んで判断するしかない。ここでは法的助言はできない。メンテナンス面では、最終 push が 2026-09-09、直近リリースが 2026-05-11 の v5.0.0-teaser-01 であり、5.0 系は段階公開の途上にある。バージョン番号に teaser が含まれる成果物を依存関係に固定するのは避け、Problem Map のような文書ベースの部分を切り分けの補助として使い、コードとして組み込む場合は goal-compiler 配下の README で依存と入出力を確認してからにするのが現実的だ。
編集部の結論
採用判断は目的で分かれる。壊れた RAG やエージェントの切り分けを今日始めたいチームは Problem Map 3.0 から入るのが最短で、README もそれを最初の実用ルートとして案内している。逆に、単一バージョンの完成品 API と安定したセマンティックバージョニングを前提に依存関係へ組み込みたい場合、WFGY 5.0 は段階公開の途中であり、v5.0.0-teaser-01 という名称が示すとおりティーザー段階の成果物しか公開されていないため、今すぐ固定すべき対象ではない。着手前に確認すべきは、リポジトリの LICENSE が NOASSERTION と表示されている点である。ライセンス本文がリポジトリ内のどこにあり、どの条件で再配布できるのかを自分で読むまで、社内の再配布物や製品への同梱は保留すべきだ。
コミュニティノート