
AIのボトルネックがもはやモデルではなくなるとき:ペルセウス・ヤンによるオープンソースエコシステム構築の実践と考察
TechFlow厳選深潮セレクト

AIのボトルネックがもはやモデルではなくなるとき:ペルセウス・ヤンによるオープンソースエコシステム構築の実践と考察
モデルは今後もさらに強力になっていくが、「エージェントが現実世界とどのように相互作用すべきか」を誰が定義するのか、「ドメイン知識をどのような形式でエンコード・配信すべきか」を誰が決定するのか——こうした問いへの答えは、モデルから自然に湧き出てくるものではない。
著者:劉軍
2026年、AI業界において一つのコンセンサスが形成されつつある。すなわち、「モデルの能力はもはやボトルネックではない」という認識である。真の差異はモデルの外側、つまりドメイン知識のエンコーディング、エージェントと現実世界とのインタフェース、そしてツールチェーンの成熟度に存在する。このギャップは、オープンソースコミュニティによって埋められつつあり、その速度は誰もが予想を超えるほど速い。OpenClawは72時間以内にGitHubスターを6万個獲得し、3か月後には35万個を突破した。Claude CodeのSkillエコシステムは、半年間で50件から334件以上へと急成長した。Hermes Agentはさらに先進的で、エージェントが再利用可能なスキルを自律的に構築できるようにしている。Vela Partnersのデータによると、過去90日間で「個人向けAIアシスタント」と「Agentic Skillプラグイン」の2つのカテゴリーが合計で新たに24.4万個のスターを獲得した。これはまさに「Skillの大爆発」である。
ペルセウス・ヤンの活動は、この爆発の中心に位置している。コネル大学で数学およびコンピューターサイエンスを専攻し、Forbes Business Councilメンバー、THINC Fellowship受賞者でもある彼は、過去数年にわたりGitHub上で10以上のAI関連オープンソースプロジェクトに関与・メンテナンスしており、その分野はエージェントのスキル拡張、スマートフォン端末レベルの操作、AIエンジン最適化ツールチェーン、GEOデータ分析エージェント、コンテンツ自動化ワークフロー、決済プロトコル基盤など多岐にわたる。彼の特徴は、卓越したエンジニアリング力と同時に、極めて鋭いプロダクト感覚を兼ね備えている点にある。単にコードを書くだけでなく、ユーザーのニーズから出発して「ツールとはこうあるべきだ」と定義し、それをエンドツーエンドで実装・展開まで推進することができる。
以下は、こうした活動を通じて彼が導き出したいくつかの核心的な判断である。
第一の判断:Skillシステムは、AIエージェント時代において最も過小評価されているインフラストラクチャである
Anthropicは2025年末にAgent Skillsをオープンスタンダードとして公開した。これを受け、OpenAIのCodex CLIも同様のSKILL.mdフォーマットを採用した。OpenClawのClawHub登録センターにはすでに1万3,000件を超えるコミュニティによるSkill貢献が集積されており、Claude Codeエコシステムも急速に追随している。Skillの意義は単に「エージェントにプラグインを追加すること」にとどまらない。本質的には、プログラミングができない人でもAIプログラミングに参加できる手段なのである。例えば、オペレーション担当者が自然言語でSKILL.mdを記述するだけで、エージェントは新しいワークフローを習得できる。これはパラダイムシフトである——AIの真の威力はモデルのパラメーター数ではなく、モデルに注入されたドメイン知識の質によって決まる。そしてSkillは、その知識注入の権限をエンジニアからすべての人々へと拡張するものである。
しかしペルセウスは、ある課題を観察している。現在のSkillのほとんどはエンジニアリング領域(コードレビュー、フロントエンド設計、DevOps、テストなど)に集中しており、非エンジニアリング領域の専門知識は、体系的にSkillとしてエンコードされていない。つまり、Skillエコシステムのカバレッジは、本来あるべき境界に遠く及んでいないのである。
この観察が、彼のGTM(Go-to-Market)ツールチェーン分野における一連のオープンソース活動を牽引した。その中でも代表的なのが「GTM Engineer Skills」であり、これはClaude CodeおよびCodex向けにAIエンジンの検出可能性(discoverability)に関する完全なワークフローをカバーするスキルセットで、現在GitHubで600以上のスターを獲得している。このツールセットは、従来SEO専門家、コンテンツ戦略家、フロントエンド開発者の協業が必要だった作業を、1人で実行可能な自動化フローにエンコードしている——ウェブサイトのAI検出可能性監査、コンテンツ構造の最適化、キーワード調査、データ可視化の機械解釈可能レイヤーの構築などである。監査ツールは単に提案を出力するのではなく、フロントエンドフレームワークを自動検出し、そのままPull Requestとして提出可能な修正コードを生成する。同一の方向性で、彼は補完的なGEO分析ツールも構築した。これはChatGPT、Claude、Gemini、Perplexityに対して並列的にクエリを送信し、ブランドの言及率、感情分析、市場シェア、競合ポジショニングを分析し、対話型HTMLレポートおよび構造化データを出力する。
実際の効果は、このツールセットのプロダクト価値を如実に示している。Articuler AIやAxis Roboticsなどの企業は、GTM Engineer Skillsを用いて、調査からResource Center構築までの全工程を数時間で完了させた。一方、従来の手法では、この作業には数十時間に及ぶ跨部署協業が必要であった。この生産性の差は、モデル能力によって実現されたものではなく、ペルセウスがGTMワークフローを深く理解し、それをプロダクト化して分解した結果である——曖昧な「AI検出可能性の向上」という要件を、エージェントが段階的に実行可能な標準化されたプロセスに分解し、各ステージに明確な入力・出力・品質検証を設定したのだ。このツールチェーンは現在、十数社のスタートアップおよび複数のフォーチュン500企業で採用されており、オープンソースツールは入口であり、商用製品は規模拡大の延長線上にある。両者は共通の技術コアを共有している。
このプロジェクト自体には価値があるが、ペルセウスはそれよりも重要な命題が検証されたと考えている:Skillシステムの能力範囲は、エンジニアリング領域にとどまらない。製品戦略、Go-to-Market、ビジネス分析など、構造化して記述可能なあらゆる専門知識は、エージェントの能力としてエンコード可能である。
第二の判断:AIエージェントの操作範囲は、ブラウザおよびAPIに留まってはならない
2026年のエージェントに関する議論は、ブラウザエージェントおよびAPI統合が主導している。LangGraph、CrewAI、Google ADKは、活気あるマルチエージェント編成エコシステムを構成している。しかしペルセウスは、構造的な盲点に気づいている。すなわち、世界中のデジタル活動の大多数は、ソーシャル、決済、ゲーム、通信といったスマートフォンネイティブアプリケーション上で行われており、これらには公開APIがなく、ブラウザ相当のインターフェースもない。既存のフレームワークでは、WeChat、TikTok、WhatsApp、Alipayなどの操作は不可能である。スマートフォンは世界で最も支配的なコンピューティングインタフェースであるにもかかわらず、スマートフォンネイティブエージェントのインフラストラクチャは事実上ゼロである。
ペルセウスの問いかけはこうだ。「なぜ誰もがAIにブラウザ操作を教えることに集中しているのに、スマホ操作を真剣に教える人はいないのか?」ブラウザエージェントの繁栄は、Webが本質的に自動化に親和的であることに起因している——DOMがあり、APIがあり、Playwrightのような成熟したツールチェーンがある。しかしスマートフォンはまったく異なる世界である。ネイティブアプリはブラックボックスであり、構造化されたUI記述は存在せず、操作は人間のタッチやスワイプを模倣する形でのみ可能となる。この問題の難しさは、LLMが「ボタンを押すべきか否か」を理解することではなく、実行層全体のインフラストラクチャをゼロから構築することにある——デバイス接続管理、画面状態の解析、複数エージェント間のデバイス排他制御、センシティブ操作のセキュリティ境界線の設定などである。
この判断が、OpenPocketの誕生を促した。これはADBを用いてLLM駆動のエージェントがAndroid端末を自律的に操作できるようにするオープンソースフレームワークであり、現在10名前後のコントリビューターと500回以上のコミットを有している。実際にユーザーがこれをどのように使っているかが、その価値を雄弁に物語っている:SNSアカウントの自動管理、IMでのメッセージ返信代行、スマホ上の支払い・請求処理、さらにはモバイルゲームの自動プレイなどである。典型的なユースケースは次の通り:ユーザーが自然言語でエージェントに「毎朝8時にSlackを開いてチェックインしてください」と指示すると、エージェントは隔離されたセッション内でこのタスクを永続的に実行し、日々の手動操作をバックグラウンドでの自動化に変える。
ペルセウスは、このプロジェクトにおいて、自身が重要だと考えるいくつかのプロダクトおよびアーキテクチャ上の選択を行った。第一に、エージェントは実行中に新たなSkillを自動生成できる。未知の操作フローに遭遇した場合、学習した手順を再利用可能なSKILL.mdとして保存し、次回からは直接呼び出せるようになる。つまり、エージェントは固定された能力を持つツールではなく、使い込むほどに強くなるシステムなのである。第二に、すべてのセンシティブ操作は、エージェント自身が安全かどうかを判断するのではなく、必ず人間の承認を経なければならない。彼の見解では、自律型エージェントが最も危険なのは「間違ったことをすること」ではなく、「自信を持って間違ったことをし、しかもそれが正解だと信じ込んでいること」である。第三に、各エージェントは完全に隔離されており、独立したデバイス、設定、セッション状態にバインドされる。これにより、複数のエージェントを同時に実行しても相互干渉しない。もしエージェントの機能拡張がTypeScriptエンジニアのみに限定されるなら、そのエコシステムは永遠に成長しない。そのため、OpenPocketもClaude Codeと同様に、SKILL.mdを能力拡張の標準フォーマットとして採用している。
このシステム全体は29種類以上のLLM設定に対応し、エージェント用スマートフォンとユーザーの個人用スマートフォンは完全に隔離されており、すべてのデータはローカルに保持される。OWASPが「ツールの悪用」をAgentic AIのトップ10リスクに指定し、EUのAI法(AI Act)の高リスク義務が2026年に施行される中で、このようなローカルファーストかつヒューマン・イン・ザ・ループの設計は保守的ではなく、エージェントが現実の現場に導入されるための前提条件なのである。
第三の判断:オープンソースの価値はコードそのものではなく、インフラストラクチャ層における標準の定義にある
ペルセウスにとって、オープンソースとは単に「コードをGitHubにアップロードすること」ではない。彼は繰り返し次のように述べている:「2026年のAIオープンソースエコシステムは、標準がまだ固定されていないウィンドウ期にあり、今コミュニティが採用するアーキテクチャパターンおよびインタフェース仕様は、今後数年にわたり業界全体のデフォルトインフラストラクチャとなるだろう。このウィンドウ期において、既存ソリューションの最適化よりも、新しいエコシステムのニッチを定義することがはるかに重要である」。
具体的には、彼のSkillプロジェクトは技術的に意味のある成果を挙げた:SKILL.mdというフォーマットが、単なるエンジニアリングツールのコンテナではなく、十分に汎用的なドメイン知識エンコーディング標準であることを実証したのである。同一のSKILL.mdがClaude Code、OpenAI Codex CLI、OpenClawのいずれでも読み込み・実行可能になると、それは事実上、AIエージェントエコシステムにおける「移植可能な能力ユニット」となった。ペルセウスは、エンジニアリング以外の領域であるGo-to-Marketの完全なワークフローをこのフォーマットに詰め込み、監査からコード修正に至るエンドツーエンドの自動化を実現した。これは、Skill標準の汎用性に対する重みのある検証である。
また、彼のスマートフォンエージェントプロジェクトは、エージェント実行層におけるアーキテクチャ上の空白を埋めた。既存のエージェントフレームワークは、ツール呼び出しのレベルで構造化されたインタフェース(APIまたはDOM)に依存している。一方、OpenPocketは、構造化インタフェースが一切存在しない環境下で操作を完遂しなければならず、純粋に画面のピクセル解析とタッチイベントの注入に頼らざるを得ない。これは、プロジェクトが根本からエージェントの「知覚-意思決定-実行」ループを再設計することを余儀なくされたことを意味する——デバイス状態のリアルタイム解析、複数エージェント間のデバイス排他プロトコル、操作失敗時の自動復旧機構などである。これらは既存エージェントフレームワークへの単なるアダプテーションではなく、「APIなし環境における自律的操作」という課題に対して独自に進化したアーキテクチャソリューションである。
二つのプロジェクトのエンジニアリング設計について、もう少し詳しく説明しよう。OpenPocketはManager、Gateway、Agent Runtimeの3層分離アーキテクチャを採用しており、各層は独立して進化可能であり、コミュニティのコントリビューターは自身が得意とする層にだけ注力すればよい。GTM Engineer Skillsの各Skill内部では、段階化パイプライン設計が採用されており、前の段階の出力が次の段階の入力となり、中間には必須の品質検証ゲートが設けられている。ワークフローは任意の段階で中断・再開可能であり、エラーは特定の段階に正確に特定できる。これらのアーキテクチャ上の選択は、すべて同じ目的のために行われている:オープンソースプロジェクトを、実際のユーザーが本番環境で信頼できるようにすることである。
プロダクト視点から見ても、二つのプロジェクトには共通点がある。ペルセウスは設計段階で常に「誰が使うか」「どう拡張するか」をアーキテクチャ決定の最優先事項に据えている。GTM Engineer Skillsのターゲットユーザーはエンジニアではなく成長チームであるため、各Skillには明確な入出力契約と組み込み品質検証が備わっており、非技術者でもエージェントが何をしているかを理解できるようになっている。OpenPocketのSKILL.md拡張メカニズム、自然言語による定期タスク設定、Telegram/Discord/WhatsApp/CLIなど多様なチャネルへの対応も、非エンジニアユーザーの利用ハードルを下げるために設計されている。彼の考えでは、オープンソースインフラストラクチャプロジェクトがエンジニアのみにしか使われないのであれば、その成長上限はエンジニアコミュニティの規模に限定される。真にレバレッジの効く設計とは、エージェントの能力範囲をあらゆる分野の実務者たちが共同で拡張できるようにすることである。
このようなスタイルは、彼の複数のプロジェクトに貫かれている。既存フレームワークの上にアプリケーション層を開発するのではなく、エージェントエコシステムのインフラストラクチャ層において欠落しているコンポーネントを特定し、それを自ら創り出すのである。
より広い展望
2026年のオープンソースAIエコシステムは、2010年代初頭のクラウドネイティブエコシステムと似た局面を迎えている。すなわち、インフラストラクチャ層の標準とツールが定義されつつあり、これらの定義が今後数年にわたり業界全体の発展経路を規定していく段階である。このウィンドウ期において、コミュニティが採用した各Skillフォーマット、検証された各エージェントアーキテクチャパターン、埋められた各エコシステムの空白は、AIの次のインタフェース層を形作る一翼を担っている。
ペルセウス・ヤンが行っていることはシンプルである。エンジニアリング力とプロダクト思考を駆使し、AI時代の技術最前線におけるパラダイムを探求することである。モデルは今後も強化され続けるだろう。しかし、「エージェントが現実世界とどのようにインタラクトすべきか」「ドメイン知識をどのような形式でエンコード・配布すべきか」といった問いへの答えは、モデルの中から自然に湧いて出てくるものではない。それらは、実際にモノづくりを行う人々が、一歩一歩試行錯誤しながら見つけ出していくしかないのだ。
TechFlow公式コミュニティへようこそ
Telegram購読グループ:https://t.me/TechFlowDaily
Twitter公式アカウント:https://x.com/TechFlowPost
Twitter英語アカウント:https://x.com/BlockFlow_News













