AIの出力を「使える仕事」に変える：Percolation Inversion Compiler v0.5.0

AIエージェントは、文章、コード、調査メモ、実行計画、テスト報告、他のエージェントへのメッセージなどを高速に作れるようになっています。

しかし、本当に難しいのは「AIが何かを書けるか」ではありません。

難しいのは、その出力を次の仕事に使ってよいのか、他のエージェントへ渡してよいのか、完了した成果として扱ってよいのかを判断することです。

Percolation Inversion Compiler は、この問題に取り組むためのOSSです。

一言でいえば、これは AIの出力をそのまま信じるのではなく、証拠・未解決点・次に確認すべきことを整理して、再利用しやすい形に変える道具 です。

AIの出力は「完成品」ではなく「候補」

AIエージェントは、とても自然に次のようなことを言います。

「修正は完了しました」

「テストは通っています」

「この情報源は主張を支持しています」

「この作業は次に使えます」

しかし、AIがそう言っただけでは、それは証拠ではありません。

本当に必要なのは、ファイル、ハッシュ、テスト結果、検証ログ、実行履歴、出典、署名、依存関係など、後から確認できる記録です。

Percolation Inversion Compiler は、AIの出力をまず「候補」として扱います。

いきなり完成品として扱うのではなく、

何を主張しているのか。

何が確認済みなのか。

何がまだ未確認なのか。

次に何を検証すべきなのか。

どこまでなら再利用してよいのか。

これらを機械が読めるJSONレポートとして整理します。

つまり、このOSSはAIに新しい答えを書かせる道具というより、AIが出した答えを「検品」する道具です。

たとえるなら、AI成果物の検問所

このOSSは、工場の検品ラインや空港の検問所に近いです。

荷物が来たときに、いきなり安全な荷物として通すのではなく、ラベル、持ち主、内容物、危険物の有無、必要書類、通過先を確認します。

問題がなければ通す。

一部だけ使えるなら、条件付きで通す。

書類が足りなければ、足りないものを明示する。

危険なら隔離する。

Percolation Inversion Compiler も同じです。

AIの出力が来たとき、それをすぐに「正しい」「完了した」とは見なしません。まず候補として受け取り、証拠や制約を確認し、どこまで使えるかを判定します。

ここで重要なのは、失敗したものを単に捨てるだけではないという点です。

未完成でも、次の作業に役立つものはあります。だから、このOSSは「完全に正しいか、完全に無価値か」という二択ではなく、「ここまでは使えるが、ここは未確認」という状態を残します。

「通った」と「終わった」は違う

このプロジェクトの重要な思想は、通ったことと終わったことを分ける ことです。

あるチェックに通ったからといって、その作業全体が完了したとは限りません。

たとえば、AIがコード修正を提案したとします。

形式としては正しい。

ファイル構成も問題ない。

簡単なチェックも通った。

しかし、まだ実際のテストは走っていない。レビューもされていない。外部環境での動作も確認していない。

この場合、「候補としては受け入れられる」が、「完了したとは言えない」という状態になります。

Percolation Inversion Compiler は、この違いを明示します。

これはAIエージェント運用では重要です。多くの問題は、明らかな失敗ではなく、まだ未確認のものを完了済みとして扱ってしまうことから起きます。

残っている問題を消さない

このOSSで特に直感的に重要なのが、残っている問題を記録する仕組みです。

未確認の証拠。

不足しているテスト。

確認できていない出典。

まだ実行されていない検証。

署名や身元確認の不足。

実行できるか分からない経路。

古くなった情報。

こうしたものを、成功メッセージの陰に隠しません。

「この作業は次に使える。ただし、これとこれが未確認である」

という形で残します。

この未解決点の記録は、AIワークフローにおける負債管理のようなものです。

負債があること自体が悪いのではありません。悪いのは、負債が見えなくなることです。

Percolation Inversion Compiler は、AI作業の負債を見える場所に残します。

なぜ「Percolation Inversion Compiler」なのか

名前は難しく見えますが、直感的には次のように理解できます。

Percolation は、役に立つ作業がネットワークの中を流れていくことです。

あるAIが作った作業が、別のAIに渡され、テストに渡され、レポートに渡され、次の開発工程に渡される。そのように、有用な成果が徐々に浸透していくイメージです。

ただし、何でも流せばよいわけではありません。証拠や制約を持たない作業が広がると、ネットワーク全体が汚染されます。

Inversion は、詰まりを逆向きに見ることです。

「どれだけ作業ができたか」だけを見るのではなく、「何が足りないせいで、この作業はまだ使い切れないのか」を見ます。

Compiler は、曖昧な材料を構造化することです。

自然言語の説明、ファイル、ログ、メッセージ、候補パケットなどを、機械が読める形に変えます。

つまり、Percolation Inversion Compiler は、AIの作業が安全に流れるために、詰まりを見つけ、証拠を整理し、再利用可能な形へ変換する道具です。

Python版は本体、TypeScript版はNode.js向けの実装

このOSSには、主に二つのリポジトリがあります。

Python版の percolation-inversion-compiler は、中心となる実装です。

CLI、SDK、ランタイム、検証、パケット処理、ボトルネック診断、フェーズ計画、ID確認、外部入力の取り込みなど、より広い機能を持っています。

Python環境でAIエージェントの出力を検査したい場合、まず見るべきなのはこちらです。

TypeScript版の percolation-inversion-compiler-ts は、Node.jsやJavaScript、TypeScriptのエージェント環境で使うための実装です。

Pythonを実行環境に入れなくても、ローカルでAI出力をチェックし、JSONレポートを作り、スキーマを検証し、パケットやワークフローの状態を扱えます。

Webサービス、npmパッケージ、Node.jsベースのエージェント、TypeScript製の開発ツールに組み込みやすいのはこちらです。

両者は役割が違います。

Python版は、理論と実装の中心に近い広いランタイムです。

TypeScript版は、その公開JSONの意味や安全な扱い方をNode.js環境へ持ち込むための実用的な移植です。

共通言語はJSONです。

つまり、Pythonで作ったレポートをTypeScript側で読んだり、TypeScript側のエージェントが同じ意味のチェック結果を扱ったりしやすい設計になっています。

何に使えるのか

このOSSが役立つ場面は、AIの出力をそのまま次工程に流したくない場面です。

たとえば、AIコーディングエージェントが修正案を出したとき。

研究支援AIが出典つきの要約を出したとき。

複数のエージェントが分担して作業しているとき。

CIでAI生成物を読み取り専用で点検したいとき。

あるエージェントの作業結果を、別のエージェントが再利用する前に確認したいとき。

長いワークフローの中で、どこが詰まっているのかを知りたいとき。

こうした状況で、Percolation Inversion Compiler は、出力を「信じる」か「捨てる」かではなく、より細かく扱います。

ここまでは使える。

ここはまだ候補である。

この証拠が足りない。

この経路はまだ実行可能とは言えない。

次はこの検証を行うべきである。

このように、AI作業を段階的に前へ進めるための状態管理を行います。

これはASIを証明する道具ではない

このプロジェクトでは、ASI-proxy という言葉が使われます。

ただし、これは「本物のASIができたことを証明する」という意味ではありません。

むしろ、複数のAIエージェントが、検証済みの作業を交換し、未解決点を残し、ボトルネックを解消しながら、より高い集団的な作業能力に近づいていく状態を、プロトコル上で扱うための考え方です。

重要なのは、過大な主張をしないことです。

このOSSは、物理世界の結果、法的判断、政策判断、医学的判断、外部世界の真理、実際のASIの成立を証明しません。

また、勝手にシェルを実行したり、リポジトリを書き換えたり、ネットワークへアクセスしたり、モデルの重みを変更したりする権限を与えるものでもありません。

あくまで、AIエージェントの出力を安全に点検し、証拠と未解決点を分け、次に確認すべき作業を整理するための基盤です。

なぜ重要なのか

AIエージェントが増えるほど、問題は「生成能力」だけではなくなります。

むしろ重要になるのは、生成されたものをどう流通させるかです。

多くのエージェントが多くの出力を作ると、有用なものも増えますが、未確認のもの、古いもの、危険なもの、証拠の弱いものも増えます。

もし、それらが区別されずにネットワーク内を流れれば、誤った前提が次の作業に混ざります。

一度混ざった誤りは、後から追跡しにくくなります。

Percolation Inversion Compiler は、この問題に対して、流通前の検査、証拠の保持、未解決点の明示、ボトルネックの発見という形で応答します。

AIが作ったものを速く流すだけでなく、何を持って流しているのかを明らかにする。

それが、このOSSの本質です。

まとめ

Percolation Inversion Compiler は、AIエージェントの出力を「そのまま信じる」のではなく、「確認可能な仕事」として扱うためのOSSです。

出力を候補として受け取り、証拠を確認し、未解決点を残し、次に必要な検証を示し、再利用できる範囲を明確にします。

Python版は、より広い機能を持つ中心実装です。

TypeScript版は、Node.jsやJavaScript、TypeScript環境で同じ考え方を使うための実装です。

この二つのリポジトリは、AIエージェント時代における重要な原則を示しています。

AIの作業は、流暢に書かれているから使えるのではありません。

証拠、制約、未解決点、依存関係が見える形で残っているから、次の仕事に安全に渡せるのです。

Repositories

https://github.com/kadubon/percolation-inversion-compiler

https://github.com/kadubon/percolation-inversion-compiler-ts