ProAgentStore

ProAgentStore プラットフォーム

サーバー上で動作するAIエージェントのマーケットプレイスです。クリエイターがエージェントのテンプレートを作成し、クライアントは登録して独自のデータ上で実行します。

ストア: https://proagentstore.online API: https://api.proagentstore.online MCP: https://mcp.proagentstore.online/mcp コンソール: https://proagentstore.online/console/ GitHub: https://github.com/ProAgentStore 無料ペア: https://freeagentstore.online

ここにあるもの

platform/
├── packages/sdk/     Internal TypeScript SDK for agents
├── packages/cli/     @proagentstore/cli — init, check, publish, MCP proxy, local runtime
├── packages/browser-runner/ ProAgentStore Playwright + terminal/coding runtime bundled into the CLI
├── workers/api/      Hono API worker (auth, agents, instances, coding, apply, keys, analytics)
├── workers/host/     Marketing site + console + widget
├── workers/mcp/      MCP server for Codex, Claude Code, Cursor, and VS Code
├── store/            Source HTML for all pages
├── skills/           Open Agent Skills source files
├── plugins/          Codex and Claude plugin wrappers
├── agents/           Tier-0 first-party agent sources kept in this repo
└── templates/        Agent scaffolding (worker, cron, api)

エージェントの種類

種類	テンプレート	機能
エージェント	worker	フル機能のAI：会話、メモリ、ナレッジベース、コアツール、Workers AI
ワーカー	cron	スケジュールされたタスク：日次ダイジェスト、監視、バッチ処理
ツール	api	ステートレスなエンドポイント：変換、生成、分析

クイックスタート

エージェントを使う

# Try any published agent — no sign-up needed
curl -X POST https://api.proagentstore.online/v1/public/agents/chatbot/try \
  -H "Content-Type: application/json" \
  -d '{"message":"Hello!"}'

エージェントを作る

npx @proagentstore/cli init my-agent --template worker
cd my-agent
pnpm install && pnpm dev
npx @proagentstore/cli publish

SDK

import { initPro } from '@proagentstore/sdk'

const agent = initPro({ agentId: 'your-id', token: 'your-token' })
const { response } = await agent.chat('Hello!')

ウィジェットを埋め込む

<script src="https://proagentstore.online/widget.js"
  data-agent="chatbot" data-theme="dark"></script>

MCP

codex mcp add proagentstore --url https://mcp.proagentstore.online/mcp
codex mcp list
# If the server shows "Not logged in":
codex mcp login proagentstore

claude mcp add --transport http proagentstore https://mcp.proagentstore.online/mcp
claude mcp list

npx mcp-remote https://mcp.proagentstore.online/mcp
npx @proagentstore/cli mcp

MCP には2つの実行モードがあります。

• chat_with_agent は公開トライアルエンドポイントを呼び出します。エージェントの検索やスモークテストに使用します。
• subscribe_agent はプライベートインスタンスを作成し、続いて chat_with_instance が、独自の状態やナレッジ、および呼び出し元が提供するAI認証情報を使ってそのインスタンスを実行します。

一般的なユーザーの実行例：

list_agents -> subscribe_agent -> my_instances -> add_instance_knowledge -> chat_with_instance

ユーザー所有のAI認証情報が不足している場合に想定される応答：

Add your Cloudflare Workers AI account ID and API token before running this agent.

これは、インスタンスの実行経路が機能しており、プラットフォームのAIアカウントへの課金を正しく拒否していることを意味します。ツール一覧、ライブテストの記録、OAuth のトラブルシューティングについては、MCP Instance Runtime を参照してください。

MCP を中心とした開発者向けインターフェースの全容は、以下に記載されています。

• https://proagentstore.online/docs/mcp/
• MCP
• server.json
• .mcp.json
• AGENTS.md

MCP の安全性はサーバー側で強制されます。OAuth は read、write、runtime、destructive スコープに対応しています。MCP_READ_ONLY=1 を設定すると読み取り専用モードになります。変更を行うツールは、適切な場合に dry_run に対応します。上書きや破壊的操作を行うツールには、正確な confirm 値が必要です。また、mcp_audit_log を使うと、最近の MCP による書き込み、実行、ドライラン、拒否、破壊的操作のイベントを確認できます。

アーキテクチャ

現在のシステムマップ、実行時の境界、データ所有権のルール、リスク評価、リファクタリングのロードマップは、Architecture に記載されています。

ブラウザーランタイム（pags up）

ブラウザー操作とコーディングに対応したエージェントは、制御プレーンの頭脳として PAGS を、手としてローカルの ProAgentStore ブラウザーランタイム（runtimePlane: "pags"、Playwright とターミナル／コーディング機能を備え、CLI にバンドル）を使用します。公開パッケージは1つ、コマンドは1つです。モノレポもトンネルバイナリも必要ありません。

PAGS control plane / MCP / Workflows
  -> task, auth, approval, audit, the LLM brain
ProAgentStore browser runtime (pags up)
  -> Playwright, local files, real browser profile, terminal/coding engines
Real browser / real repo
  -> job boards, uploads, receipts, coding sessions

npm i -g @proagentstore/cli
pags login
pags up            # one runner for every active runtime-capable instance

SSH 経由またはヘッドレスマシンでサインインする方法（#1157）。 pags login --device を実行すると、リンクと短いコード（BCDF-GHJK）が表示されます。スマートフォン、または ProAgentStore にサインイン済みの任意のデバイスでリンクを開き、ページにこのマシンが表示されていることを確認して承認すると、数秒以内にマシンがサインインします。SSH セッション（OS は問いません）およびディスプレイのない Linux では自動的にこの方法が選択されます。ブラウザーを強制するには pags login --browser を使用します。pags up の実行中はサインイン状態が維持されます。セッションの過去7日間にサインイン状態を更新し、更新できない場合は pags up のウィンドウにその旨を表示します。また、SSH 経由で pags login --device を実行できる時間が残っている間に、list_runner_nodes がそのマシンについて警告します。

マシンごとのインストールは一度だけです。 CLI 0.4.63 以降、npm がインストールする pags は小さなブートストラップスタブです（#862）。pags up を実行するたびに npm から最新の @proagentstore/cli を取得し、新しいリリースがあれば ~/.config/proagentstore/cli/<version>/ にダウンロードして実行します。そのため、マシンがどれだけ古いバージョンのままでも、あるいは runner_update を一度も使ったことがなくても、再び npm i -g を実行する必要はありません。runner_update（#859）は、pags up の実行を継続したまま、同じキャッシュをリモートから更新します。0.4.62 以前のマシンでは、最後に一度 npm i -g @proagentstore/cli を実行するとスタブを取得できます（0.4.62 の場合は runner_update でも取得できます）。PAGS_NO_SELF_UPDATE=1 を設定すると更新確認が無効になります。ソースチェックアウトが自動更新されることはありません。 リモート更新では、ランナーだけでなくすべてが再起動します（#860）。 runner_update がリリースをインストールすると、pags up は同じフラグで自身を再起動します。スーパーバイザーも含まれ、すべてのエージェントが再接続します（以前の pags up はランナーだけを再起動し、runner_update の回答には supervisor 内でその旨が記されています）。pags up を使わずに起動したランナーも、再起動する仕組みがあればリモートで更新できます。

• launchd / systemd — PAGS_SERVICE=1 と再起動時の失敗時再起動を設定し、pags runner connect <any-instance-id> --watch-instances を実行します（launchd の KeepAlive → SuccessfulExit: false、systemd の Restart=on-failure）。更新後、ランナーは終了コード 75 で終了し、サービスマネージャーが新しいリリースで起動します。保存済みの pags login セッションを使ってサインインします。
• その他（tmux スクリプト、nohup）— 起動するシェルコマンドを PAGS_RESTART_COMMAND に設定します。ランナーは終了時に、そのコマンドをデタッチして実行します。

どちらも設定されていない場合、runner_update は再起動できないランナーを停止しないよう、更新を拒否します。いずれの場合も、コーディングエンジンがターンの途中なら、まず終了を待ちます。

pags up は標準のランナーです。1つのプロセスで、capabilities.runtime が null ではないすべてのアクティブなインスタンスに対応します。 クラウドのみのチャット／RAG／コネクターエージェント（runtime: null）は対象外です。ローカルランナーを必要としないためです。

インスタンスへの参加状況は起動時のスナップショットではなく、常に最新の状態です。pags up は --watch-instances（CLI ≥ 0.4.30）を渡すため、ランナーは20秒ごとに /v1/instances/my/instances を再読み込みし、新たに対象となったエージェントに接続します。対象外になったエージェントは切断されます。再起動は不要です。ランナーの起動中にコーディングエージェントをサブスクライブするだけで、そのまま利用できます。（プッシュではなくポーリングです。新しいインスタンスにはプッシュ先のソケットがないためです。プッシュ方式は #83 で追跡しています。）スコープを指定した pags up --instance <id> は意図的に監視を行いません。対象となるのはそのエージェントだけです。

トランスポートにはWebSocket リレーを使用します。ランナーはインスタンスとノードの組み合わせごとに用意された RelayDO へアウトバウンド接続します。cloudflared、公開サーバー、インバウンドポートは不要です。Cloud → callRunner() → RelayDO → WebSocket → ランナー、という経路です。現在の CLI には --tunnel フラグもトンネルへのフォールバックもありません。ランナーはハンドシェイク用に有効期限の短いインスタンス限定のリレートークンを発行します。30日間有効なアカウント JWT が WebSocket URL に含まれることはありません。

• Coder は同じインスタンスに対して、複数のマシンを同時に実行できます。各コーディングセッションは、そのセッションを所有するランナーノードに固定されます。異なるリポジトリを別々のマシンで同時に実行できます。
• pags up --force — 古いローカル接続のデバッグ時に、現在のリレーソケットを置き換えます
• pags up --instance <id> — 1つのエージェントに固定します（デバッグ用）
• pags up --headless — ヘッドレスモード

求人応募には、サポート対象のブラウザ経由の方法が2つあります。JOB_APPLY ワークフロー（以下）と、Scout → Tailor → Runner パイプラインです。Coder エージェントは、セッションに割り当てられたランナーノード上で、選択したエンジン（Claude Code、Codex、Gemini CLI、Grok、またはローカルコマンド）を実行します。Claude は永続的な構造化セッションを使用し、その他のエンジンは単発のターンを実行します。

従来の求人応募エージェント（JOB_APPLY、サポート対象）

「従来の」は古さを示すもので、サポート終了を意味しません。Cloudflare の JobApplyWorkflow が制御する pags up のブラウザ機能は、Scout → Tailor → Runner パイプラインと並ぶ、サポート対象のブラウザ経由の求人応募方法です（#1062）。POST /v1/instances/{id}/apply、チャットの submit_job_application ツール、または MCP の apply_to_job から開始できます。開始するには、Job Application Assistant インスタンス、稼働中のランナー、登録済みの履歴書が必要です。各インスタンスで同時に実行できる応募は1件で、候補者情報にはプロフィールの値のみが使用されます。また、実行ごとに支出プールと実行記録が作成され、停止することもできます。もう1つの方法であるパイプラインでは、リードを選別し、応募資料を調整したうえで、レビューを依頼するか、設定済みの提出ポリシーに従って Application Runner に入力させます。

スキルとプラグイン

ProAgentStore は、プラットフォームごとのプラグインマーケットプレイスを通じてスキルを公開しており、ユーザーは Codex と Claude Code の両方から見つけることができます。

Codex：

codex plugin marketplace add ProAgentStore/platform

Claude Code：

/plugin marketplace add ProAgentStore/platform
/plugin install proagentstore@proagentstore
/reload-plugins

公開時の構成、マーケットプレイスのファイル、Codex と Claude の両方へのリリースチェックリストについては、スキルの公開をご覧ください。

公開されている検索ページ：

• https://proagentstore.online/skills/
• https://proagentstore.online/skills/proagentstore-mcp-operator/
• https://proagentstore.online/llms.txt
• https://proagentstore.online/llms-full.txt
• https://proagentstore.online/skills.json

カタログのエージェント

カタログの実際の保存場所

正式なカタログは D1 の agents テーブルであり、GET /v1/agents を通じて読み取ります。 このリポジトリ内にカタログのミラーはありません。このリポジトリ内のファイルは、カタログの1つの行のソースであるか、カタログにはまったく含まれないかのいずれかです。この2つは別物であり、その混同を防ぐことがこのセクションの目的です。

ソース	内容	正式性
D1 の agents テーブル	公開済みのすべてのエージェント、その機能、設定スキーマ、パイプライン。	正式な情報源です。 GET /v1/agents または MCP の list_agents ツールを使って読み取ります。
workers/api/migrations/*seed*.sql	新しいデータベースで、ファーストパーティエージェントをそのテーブルに登録する方法です。冪等な INSERT OR IGNORE を使います。	シード対象のエージェントについては正式な情報源です。シードを編集しても、すでにシード済みの行は変更されません。その場合は、後続の UPDATE マイグレーションが必要です。
agents/<slug>/agent.json	プラットフォーム自体がビルドまたはインポートするコードを持つ、Tier-0 エージェントのマニフェストです。	ソースにすぎません。カタログの行は作成されません。
store/registry.json	廃止されています。以下をご覧ください。	なし。

そのため、リポジトリ内にファイルがなくてもエージェントがカタログに登録されている場合や、ここにフォルダーがあっても独立したカタログの行がない場合があります。どちらも正常です。

Tier-0 エージェント — このリポジトリにソースがある唯一のエージェント

agents/ にあるのは正確に3つです。これは CI で scripts/check-agents-allowlist.mjs によって強制されています。

フォルダー	Tier-0 である理由
agents/coder	agents/coder/web はコンソールにインポートされる pnpm ワークスペースのメンバーです。
agents/job-application-assistant	応募エージェントのマニフェストです。（src/ の Worker はレガシーで、デプロイされていません。このフォルダーの README をご覧ください。）
agents/repo-chat	Repo Chat エージェントのリファレンスソースです。

それ以外はすべて、ProAgentStore 配下の独立した組織リポジトリで、~/dev/stores/pags/agents/<slug>/ にローカルクローンします。ここに4つ目のフォルダーを追加すると、意図的に CI が失敗します（epic #50）。このモノレポには以前、ビルドもデプロイもされない古いベンダーコピーが10個蓄積されていました。

現在公開されているもの

13 個のエージェントが公開されています。それぞれの作成元ごとに分類しています。

マイグレーションでシード — 新しいデータベースで再現可能です。

スラッグ	名前	シード	リポジトリ内のソース
coder	Coder	0021	agents/coder
repo-chat	Repo Chat	0032	agents/repo-chat
site-builder	小規模事業者向けウェブサイトビルダー	0057	なし — 完全に宣言的（lib/pipelines/*.json）
coder-repo	Repo Coder	0063	なし — 宣言的な機能
coder-lead	Coder Lead	0063	なし — 宣言的な機能
local-repo-chat	Local Repo Chat	0066	なし — 宣言的な機能
tmux-operator	tmux Operator	0072	なし — 宣言的な機能
job-application-assistant	Job Application Assistant（JOB_APPLY）	0185、0189、0233	agents/job-application-assistant

オペレーターが API／コンソールから作成 — D1 の行としてのみ存在するため、新しいデータベースには含まれません。これは設計ではなく、既知の差異として扱ってください。

スラッグ	名前	備考
language-buddy	Language Buddy	マイグレーション 0041 は、存在する場合に settingsSchema を設定します。エージェント自体は作成しません。
doc-chat	Doc Chat
small-business-website-lead-finder	Small Business Website Lead Finder	単独の組織リポジトリで、pags/agents/ にクローンされています。
lead-outreach-tj6qrr	Lead Outreach Assistant	リード獲得チェーンの中継リンクです。
facebook-friend-confirmer	Facebook Friends	ブラウザーランタイムエージェントです。

3 つのエージェントで構成されるリード獲得チェーンは、small-business-website-lead-finder → lead-outreach-tj6qrr → site-builder です。コードではなく agent_connections で接続されています。

公開には制限があります。PUT /v1/agents/:id と POST /v1/batch/bulk-visibility は、スモークテスト用フィクスチャの公開をどちらも拒否します（#65、#64）。これにより、監査で削除された 16 個のフィクスチャとスキャフォールドシードがカタログに再び蓄積されるのを防いでいます。

store/registry.json は意図的に空です

これは静的なエージェント詳細ページ生成ツール store/build-details.js の入力です。どちらも何にも接続されていません。build-details.js は package.json のスクリプトに登録されておらず、CI ワークフローから呼び出されてもいません。エージェント詳細ページは、GET /v1/public/agents/:id を使って /agents/:slug/ で動的に配信されます。誰かが実行しても使われていない生成ツールがクラッシュしないよう、このファイルは空のスタブとして残されています。これは公開用の発見手段ではありません。公開情報の確認には、GET /v1/agents、store/llms.txt、または store/skills.json を使用してください。

このリストから削除されたエージェント

以前のバージョンの README には、site-monitor、lead-qualifier、content-pipeline、competitor-intel、support-escalator、data-analyst、meeting-notes、seo-auditor、invoice-parser、email-drafter の 10 個のエージェントが記載されていました。これらは agents/ 内に同梱されていたシードのコピーで、プラットフォームの main のコミット f9980a8 で削除されました。いずれも現在、シードマイグレーションも公開カタログの行もありません。ここに再追加しないでください。

そのうち 1 つはエージェントではなく、検索キーとして残っています。シードマイグレーションでは、SELECT owner_id FROM agents WHERE slug = 'data-analyst' AND owner_id LIKE 'google:%' を使ってオペレーターアカウントを特定します。これは本番データベースでオペレーターのユーザー ID を検索する方法で、見つからない場合は 'system' にフォールバックします。data-analyst がカタログのエージェントであることを意味するものではありません。

その他の機能

• アシスタントのチャットとCoder Co-pilotでの双方向音声（共通の useVoice フック） — ディクテーション（ブラウザーでリアルタイムに文字起こし）または Whisper（キーのプロキシ経由で利用する OpenAI の、最も高精度な音声認識）を選択できます。ブラウザーまたは OpenAI の音声合成では、音声と速度を選択できます。チャット · タップして話す · ハンズフリーを切り替える単一のセグメント式コントロール（ミュートはハンズフリーのサブコントロールで、モバイルではアイコンのみ表示）、音声での**「repeat」コマンド、各音声メッセージの保存済み録音（R2）をスピーカーボタンから再生する、ターンごとの再生機能を備えています。また、ライブディクテーションと送信された文字起こしを比較し、文字起こしから失われた単語数を数える聞き取った内容を表示**切り替えも利用できます。適応型 VAD と、一時停止・感度・言語の設定、iOS のジェスチャー処理にも対応しています。
• Knowledge のMarkdown ドキュメントをネイティブにサポート — 作成、閲覧、編集ができます。エージェントはアシスタントを介してドキュメントを読み取り、更新します。
• 可観測性 — ブラウザーとサーバーのエラーは永続ログ（client:voice*、keys-proxy、job-apply、…）に記録され、MCP の list_errors で確認できます。agent_events と MCP の agent_trace による、実行ごとの統合タイムラインも利用できます。
• エージェント設定可能な作業ボード — インスタンスごとにボードは1つです。列はエージェントごとに宣言され（capabilities.boardColumns）、ジョブごとにカードが1枚作成されます。移動、再試行、試行回数に対応しています。MCP の instance_board から操作します。（従来の2ボード／「ランタイムボード」設計に代わるものです。）

開発

テスト — 1つのプールではなく、2つのプロジェクト

pnpm test ですべてのテストを実行します。内部では vitest.config.ts により、次の2つに分かれています。

プロジェクト	内容	実行方法
unit	約3100件のテスト。純粋関数とモック化した I/O	並列フォークプール
integration	packages/browser-runner/** — CDP 経由のテストごとの実 Chrome、バインドされたソケット、起動した tmux ペイン、本物の git clone	unit の後に、ファイルを1つずつ単独で実行

integration の10件のテストは、ほかの約3100件を合わせたものより実行に時間がかかります。また、ローカルで不安定になるのを目にするのは、このテストだけです。そのため、原因を正確に把握しておく価値があります。

pnpm test               # both, integration last and alone
pnpm test:unit          # the fast ~3100 — what you want in a tight loop
pnpm test:integration   # the real-browser / real-socket set

**これらのテストは、テスト対象のコードではなく、CPU の空き状況に左右されます。**競合状態やポートの衝突、ファイル間でのブラウザーの残留はありません。これまでに確認された失敗はすべて、マシンが静かなときなら必ず成功するコードで発生した Test timed out in Nms です。計測では、同じブラウザーテストの実行時間は単独で11.4秒、テストスイート内で20.6秒、別のテストスイートを並行実行した状態で39.3秒でした。また、マシンが完全に飽和したときに失敗したのは、rate-limit.test.ts、publish.test.ts、storage-tools.test.ts の実行でした。ブラウザーもソケットも使わない、純粋な単体テストが3件です。ブラウザーテストが先に実行できなくなるのは、最も負荷が高いからであり、ブラウザーテストだからではありません。

そのため、テストが不安定になった場合は、アサーションを緩めずに、ほかに何が実行されているかを確認してください。CI には影響がなく、これまで影響したこともありません。専用ランナー上でテストスイートだけを実行するため、常に成功します。この分割は、共有開発マシンのために設けられています。主な目的は、実際の I/O を使うテストに対し、vitest のデフォルトの5秒ではなく、実際の I/O に見合うタイムアウトを確保することです。

ブラウザーを起動するテスト、または待ち受けソケットをバインドするテストを追加する場合は、packages/browser-runner/ の下に配置してください。そうすれば、そのタイムアウトが適用されます。それ以外の場所に配置すると、scripts/check-test-isolation.mjs により CI が失敗します。

孤立した Chrome。 テストランナーが SIGKILL で強制終了されると、Playwright のクリーンアップ処理は実行されません。そのため、中断された実行の後にはブラウザー全体が残ります。このリポジトリの開発マシンで確認した例では、稼働中のブラウザープロファイルが174個あり、最古のものは26時間前のもので、プロセス数は約1000、ロードアベレージは190でした。これらは見えないところに残って後続の実行を遅くします。そのことが、「不安定」に感じられるタイミングがランダムに思える主な原因です。ローカルのテストが理由もなく遅いと感じた場合は、次を実行してください。 ps ax | grep -c playwright_chromiumdev_profile

ドキュメントの成果物 — ソースと生成物の違い

成果物	状態	更新方法
platform-docs/*.md	ソース	直接編集し、zensical.toml の nav にページを追加します
store/docs/**	生成物、コミット対象外	pnpm docs:build を実行します。手作業で編集したり、git add したりしないでください
store/openapi.yaml	ソース	ルートを追加または変更するときに編集します
store/llms.txt、store/llms-full.txt	ソース	手作業で編集します。エージェントが最初に読むファイルです
workers/mcp/README.md のツール表	ソース	ツールを登録するたびに行を追加します
workers/mcp/src/tool-count.ts	件数の信頼できる情報源	ツールを追加または削除するときに値を更新します

store/docs は、workers/host/src/pages.ts と同じ意味でビルド出力です。ci.yml と deploy-host.yml はどちらも、これを読み取る前に pnpm docs:build を実行するため、コミット済みのコピーは古いものにしかなりません。実際、そうなっていました。新しいチェックアウトでは、pnpm test:e2e または node workers/host/build.js の前に、一度 pnpm docs:build を実行してください。どちらも /docs/* を読み取ります。

ドリフトのチェック

このリポジトリで、ほかの何にも検証されないのは文章だけです。そのため、気づかないうちに古くなり、エージェントに誤ったことを教えてしまいます。次の2つのコマンドで、実際に問題を起こした種類のドリフト（#209、#210）を検出できます。

pnpm docs:drift        # nav ↔ pages, MCP tool table + count, removed commands, docs links,
                       # and (delegated) the route/spec check below
pnpm openapi:coverage  # every Hono route is documented or explicitly excluded, and every
                       # documented path resolves to a real handler

どちらも CI で実行されます。失敗すると、対象のファイルと想定していた件数が表示されます。ドキュメントを修正するか、説明対象のコードを修正してください。チェック対象を変更せずに、チェックを無効化してはいけません。意図的にドキュメント化していないルートは、理由を添えて scripts/openapi-coverage.mjs の EXCLUSIONS 配列に追加します。

ルートを追加するときは、store/openapi.yaml を更新します（または除外項目を追加します）。 MCP ツールを追加するときは、workers/mcp/README.md に行を追加し、workers/mcp/src/tool-count.ts の値を更新します。index.test.ts は、実際の登録処理でその定数を検証します。また、/health と3つのドキュメントでその値を引用しています。 ドキュメントページを追加するときは、zensical.toml の nav に追加します。

品質スキャン（VCQA）

pnpm vcqa              # the canonical score: pinned CLI, --skip-tests, repo root

この1行に含まれる2つの要素は、どちらも重要です。

最初に SDK をビルドします。これは pnpm typecheck と同じ理由です。コンソールとエージェント UI は、ビルド済みの dist にある @proagentstore/sdk をインポートするため、ビルドしていないチェックアウトでは、tsc が3つのパッケージ全体で「Cannot find module '@proagentstore/sdk/client'」と報告します。VCQA の types チェックは tsc を呼び出し、その結果を 0/100 と評価します。ここで実測したところ、ソースを変更せずに pnpm --filter @proagentstore/sdk build だけを実行すると、types は 0 から 100 に、総合スコアは 65 から 71 に上がりました。これは #288 で「typecheck fails」と報告された問題そのものです。コードの不具合ではなく、dist が未ビルドだったのです。この接頭辞を付けないと、新しいチェックアウトのたびに、この誤報をコマンド自体が発生させてしまいます。

--skip-tests は意図的な指定であり、引用するスコアはこの指定に基づいています。これを指定しない場合、VCQA の testing チェックはテストスイート自体を実行します。このリポジトリでは、すでに約35種類のほかのチェックを実行しているスキャン内で、integration プロジェクト（CDP 経由の実際の Chrome、バインドされたソケット、実際の git clone）まで実行することになります。テストの実行には pnpm test を使います。このコマンドは、それ以外のすべてを測定します。2人がスコアを比較するときに同じスキャナーを比較できるよう、CLI のバージョンはスクリプトで固定されています。

スキャン対象を決めるファイルは3つあり、互いに置き換えることはできません。

ファイル	適用先	ほかのファイルに統合できない理由
.vcqa.json	VCQA 独自のファイルウォーカー	インプロセスのランナーが読み取る ignore パターンです
.gitleaks.toml	secrets チェック	gitleaks はサブプロセスです。.vcqa.json の内容は渡されません
biome.json	lint チェックと pnpm lint	Biome は、無視リストが適用される前に独自の設定を解決します

この分割こそが要点であり、明らかな1ファイルへの修正ではうまくいかない理由です。エージェントのワークツリーが稼働しているマシンで、2026-08-06 にリポジトリのルートで測定しました。

• pnpm lint は騒がしかったのではなく、動いていませんでした。 Biome は、読み込んだルート設定の下にネストした ルート 設定を見つけると起動を拒否します。.claude/worktrees/<agent>/ には、このリポジトリの biome.json のコピーが含まれています。Biome は「Found a nested root configuration」と表示して終了コード 1 で終了し、何も lint しませんでした。files.includes に !.claude を追加して修正しました。しかも、この書き方でなければなりません。隣接するエントリーはすべて !**/x ですが、worktree（.claude/ の下にあります）の中で作業しているときに !**/.claude を指定すると、祖先 に一致するため、チェックアウト全体が自身から除外されます。その結果、「Checked 0 files」と表示され、終了コード 0 になります。何も読み込まずに成功を報告する lint は、クラッシュするより悪質です。!.claude は設定ルートを基準に解決されます。リポジトリのルートから891ファイル、worktree 内から807ファイルが対象になることを確認しました。
• gitleaks で462件検出され、そのうち451件（97.6％）は .claude/worktrees/** が原因でした。同じ3ファイルがエージェントセッションごとに再報告され、338 MB を25.4秒でスキャンしていました。重複がほぼすべての原因となり、レポートの中で secrets は25/100と最も低いチェック結果でした。.gitleaks.toml を追加すると、検出数は11件、スキャン対象は17.5 MB、所要時間は1.7秒になりました。この11件は実際のソース内にある実際のパスであり、意図的にそのまま表示しています。

Lint はゲートであり、すべてのツリーが対象になりました（#326）。 pnpm lint を実行できるようにしても、すべてのルールは推奨扱いのままでした。どのワークフローにも含まれていなかったため、誰にもリグレッションとして知らされることなく、300件の指摘が蓄積していました。ci.yml では pnpm exec biome check --error-on-warnings packages workers store agents/coder を実行し、すべての対象でエラー0件かつ警告0件を確認しています。対象ツリーでこれまでに見つかった指摘はすべて警告だったため、警告を無視するゲートでは何も保護できません。そのため --error-on-warnings を指定しています。また、npx ではなく pnpm exec を使うことで、固定バージョンの Biome を実行し、上流で新しいルールが追加されても、ここでコミットしない限り、グリーンの main が赤に変わることはありません。

このステップは、すでに件数がゼロの場所でのみゲートを有効にできるため、当初は packages と workers/mcp のみを対象としていました。残りは2026-08-07に追加しました。workers/api に残っていた最後の指摘は useOptionalChain が1件で、はるかに大きく見えた any の負債は、すべて *.test.ts にある184件でした。このリポジトリの tsconfig ではこれらが除外されていたため、型チェックも一度も実行されていませんでした。現在、workers は api、host、mcp を対象としています。そのため、新しい worker はバックログを知らされずに蓄積するのではなく、最初のコミットからゲートの対象になります。新しいツリーは指摘ゼロで追加するか、専用のステップとともに追加してください。早まって対象を広げ、continue-on-error に頼ってはいけません。それでは、このステップから効力を取り除いたのと同じです。

意図的に引き続き対象に含めているもの。 agents/coder と agents/job-application-assistant は Tier-0 です。pnpm ワークスペースのメンバーであり、CI で型チェックとビルドを行うため、スキャン対象にしています。以前これらの隣にあった機能しないベンダー提供のシードコピーは、2026-08-01（f9980a8）に削除されました。scripts/check-agents-allowlist.mjs によってそれらは対象外になっており、除外すべき古いファイルは agents/ の下に残っていません。現在 agents/** を無視すると、出荷対象のコードが隠れるだけです。追加された場合は scripts/check-qa-config.mjs が CI を失敗させます。

無視パターンを追加する前に、VCQA は glob エンジンではない点に注意してください。認識するのは prefix/**、*suffix、単純なパスプレフィックスだけです。それ以外は認識しません。**/dist/** は正しく見えても何にも一致せず、エラーも出さずに失敗します。VCQA はすでに、ディレクトリ名が dist（node_modules、.claude、coverage なども同様）であれば、深さを問わず除外します。そのため、思いつきがちなパターンのほとんどはすでにカバーされています。ガードは、決して機能しないパターンを拒否します。

FreeStore エコシステムの一部

ストア	URL	製品
FreeAppStore	freeappstore.online	PWA アプリ
FreeGameStore	freegamestore.online	ブラウザーゲーム
FreeWebStore	freewebstore.online	AI 構築サイト
FreeAgentStore	freeagentstore.online	ブラウザーベースの AI ツール
ProAppStore	proappstore.online	有料アプリ
ProAgentStore	proagentstore.online	サーバー AI エージェント

ライセンス

MIT