pAIchart MCP Hub

pAIchart — 高レベル設計を入力すると、レビュー済みの低レベル設計が出力されます

— ソースを利用できます：セルフホスト、変更、再配布が可能です。ただし、第三者向けのホステッドサービスとしての提供はできません。

ネットワーク機器、Terraform、Kubernetes、オブザーバビリティスタック（Prometheus / Grafana / OpenTelemetry）を横断し、オープンな MCP ハブ上で利用できます。取得可能な任意の場所にある requirements.md と topology.json を pAIchart に渡すと、レビュー済みの低レベル設計が返されます。各デバイスの設定、正常に動作したことを証明する正確なコマンド、ロールバックが含まれます。チームはこれを冪等に、帯域外で適用します。pAIchart は変更の設計とレビューを行いますが、適用することはありません。

LLD の作成がボトルネックとなっており、pAIchart はこれを解消します。現在、LLD を作成するには、シニアエンジニアがすべての機器のライブ状態を読み取り、各ベンダーの言語で設定を書き、ドメインをまたぐ値を手作業で照合する必要があります。pAIchart は専門エージェントのグラフとしてこの作業を行い、3 段階でチェックして、承認できるレビュー済みの結果を一つにまとめて渡します。すべてのシステムをまたいで設定を作成するのではなく、一つのパッケージを承認するだけで済みます。

有向非巡回グラフ（DAG）がエージェントを調整します

他のソリューションが提供するのはタスクの DAG です。pAIchart が提供するのは、レビュー済み変更の DAG です。

各ノードは、エージェントが ライブ状態を収集 → 設計 → 作成 → レビュー を行うドメインパイプラインです。各エッジは、実行時まで存在しなかった値を引き渡します。エッジでつながっていないレッグは並行して実行され、依存関係のエッジがある場合は順序を強制し、実際に導出された値を次へ渡します。

                    ┌──▶ [firewall leg] ──┐
[network leg] ──────┼──▶ [cloud leg] ─────┼──▶ [integration review] ──▶ release gate
                    └──▶ [k8s leg] ───────┘
     derived range                              checks all legs against
     exists only after                          the one shared contract
     this leg runs

これがグラフとスクリプトの違いです。ネットワークレッグが導出したアドレス範囲を、クラウドレッグが正確に承認します。これは、クラウドレッグがネットワークレッグの作成した内容を読み取るためです。高レベル設計に事前定義された値はありません。

• コンテキストの連鎖と依存関係を備えた、並行または順序どおりに実行する複数のレッグ
• 現在は、ネットワーク機器、Terraform、Kubernetes、オブザーバビリティ設定（Prometheus / Grafana / OpenTelemetry）の4つのインフラストラクチャドメインに対応し、アーティファクトの合成にも対応しています。構成は拡張可能です。オブザーバビリティドメインは、エンジンを変更せず、設定作業（プロトコル、4つのロールテンプレート、読み取り専用サービス記述子）だけで追加されました
• グラフは作業とともに、単一の PIPELINE タスクで宣言されます。別途スケジューラーを運用する必要はありません
• 承認ゲートの解除は、AI クライアントまたはウェブ UI から、共通のコードパスを通じて行われます
• ライブ状態はデバイスから取得され、デバイスごとの MCP サーバーを通じて読み取り専用で収集されます

正しさを3つの階層で検証し、下位の違反を上位で覆せない仕組み

階層 1 — コードによる算術検証です。適切な場合、pAIchart は LLM レビュアーの確信度に頼るのではなく、コードを使って決定的な検証を行います。導出された各値には kind が付与され、エンジンはパッケージが再掲した値ではなく、収集したエビデンスに基づいて、その種別の算術検証を実行します。

• cidr — 導出された範囲は、宣言されたメンバーだけを正確にカバーしていますか？ 範囲が広すぎる（すでに割り当て済みのアドレスまで含めてしまう）場合と、狭すぎる（メンバーとして申告されたものが範囲外になる）場合を検出します。
• asn — AS 番号はプライベート範囲内にあり、収集した状態によって許可されていますか？ ここでは関係が意図的に逆転します。収集結果が許可リストです。設計で設定された AS 番号は、デバイスですでに稼働しているものか、目的で明示されているものでなければなりません。

また、未実装の kind がある場合、プラットフォームはその旨を明示します。その値を機械的な検証の対象外として記録し、統合レビュアーにエスカレーションします。未検証の値を合格として扱うことはありません。この経路は VT-14 でエンドツーエンドに検証されています。レビュアーは対象外の値を特定し、その出所を追跡して、裏付けとなるデバイス設定がないことを確認し、2つの緑色の判定と自身の承認を覆してブロックしました。

階層 2 — 独立したレビュアーです。各レッグには、それぞれの契約に基づくレビュアーが付きます。さらに統合レビュアーが、共有契約に基づいてすべてのレッグを横断し、ドメイン固有のバリデーターを構成済みのセットに対して実行します（トポロジー全体を対象とする Batfish、terraform plan、kubeconform）。これらのバリデーターを利用するのであって、再実装するわけではありません。

階層 3 — リリースゲートです。決定的な AND 条件です。すべてのレッグが承認済み かつ 封じ込め違反がない かつ 未検証の値に妥当な理由が付いている かつ 統合レビュアーが承認済み かつ カバレッジが完全であることを求めます。確信度の数値は一切含まれません。

階層 1 の違反は、上位で誰が承認していてもリリースをブロックします。

失敗したラウンドも公開していることが、証明になります

このカテゴリのほとんどの製品は、デモを信頼するよう求めてきます。私たちは21件の検証ドキュメントを提供し、それぞれで実行前に期待される観測結果を示し、実際に何が起きたかを記録しています。

うまくいかなかった事例もご覧ください。VT-12 では、プログラムが認可範囲の拡大を含んだまま programReleasable: true と自己認定しました。5つの階層すべてがこれを通過したため、現在は最小性を文章ではなくコードで検証しています。

• バイト単位で同一の2つのレビュー実行が、同じ入力に対して45と92をスコアとして出しました。そのため、確信度はすべての階層で記録された事実として扱いを格下げし、リリースゲートは検証可能な事実だけで判断します。ゲートに確信度の数値は含まれません。
• 実行できなかったチェックは、合格ではなくブロックです。「検証できなかった」が「問題ない」に格上げされることはありません。
• あるレビュアーが構造上確認できない事柄を判断したため、正しい変更パッケージが3件却下されました。1件では「この比較を独立して再検証することはできません」と書きながら、結論を断定していました。説明を改善すると1つの経路は解消しましたが、次の経路で同じ種類の問題が再発したため、現在はエビデンスのある場所で比較を計算してレビュアーに渡します。一方、事実だけでは判断できないすべての事柄については、引き続きレビュアーが判断します（VT-21）。

→ 検証パック · すべての主張を機械記録にリンク · プロトコル · エージェント向けの契約。各実行はこれらの契約に照らして評価され、プラットフォームのシードと逐語的に公開され、バイト単位の一致が検証されています

5 つのドメイン、1 つのハーネス

• ネットワークプロビジョニング：「スイッチごとに Loopback0 を追加し、BGP にアドバタイズする」 → プロビジョニングチームが冪等に適用する、承認済みの変更パッケージです。記述子から読み取り専用デバイスサービスを自分でプロビジョニングし、実際の稼働状態を取得して、デバイスごとの設定、検証、ロールバックを設計・作成し、独立したレビュアーが承認します。→ 変更レポートの例
• Kubernetes / GitOps：「orders-api Deployment に HPA とリソースリクエスト／制限を追加する」 → ライブクラスタの状態を基にした宣言型の kustomize オーバーレイで、オフラインで検証します（kubeconform / kustomize build / OPA。kubectl diff は一切実行しません）。読み取り専用で、RBAC のスコープが設定されています。シークレットの名前は表示されますが、値がクラスタ外に出ることはありません。→ 例（獲得した NEEDS-REVISION を含みます。レビュアーが、検証できなかった内容の承認を拒否します） · 2 つ目の例（3 回の実行で PodDisruptionBudget を追加します。最初のパッケージのギャップ一覧が目標となり、レビュアーは可用性の計算を理由に最初の試行を拒否し、異なるフィールドを選択した修正版を承認しました）
• オブザーバビリティ設定：「256 MB のコンテナに合わせて、コレクターのメトリクスパイプラインの先頭に memory_limiter プロセッサーを追加する」 → ライブの Prometheus / Grafana / OpenTelemetry スタック向けの、ファイル全体を対象とする望ましい状態の設定です。コレクターのデプロイ済みファイルと Prometheus の稼働中の設定から読み取り専用で取得し、適用前に決定論的な検証を行い、適用後は存在確認に基づくチェックを実行し、取得したファイルをロールバックに使用します。→ 例（公開されたパッケージとして初めて適用も行い、その後に稼働中のシステムに表示された内容を示します。また、引用が本物かどうかを推測する代わりに、レビュアーがプラットフォームによってスタンプされたロールバックの来歴情報を確認した初めての例です）
• Terraform / クラウド IaC：「acme-app-logs バケットにバージョニングとパブリックアクセスブロックを追加する」→ スコープを限定した state pull（プロバイダーを起動せず、状態ロックも行いません）を基に、validate / plan / tflint / OPA の期待される事実とロールバックを含む、PR 用の HCL 変更パッケージを作成します。→ 例（多層防御を示します。シークレットのようなタグはマスキングされ、プロンプトインジェクションのタグは拒否されます）
• アーティファクト合成：ソース資料（git の履歴、実行ログ、POV の納品履歴、外部 MCP サービス）→ 取得 → 作成 → レビューを経て、公開可能な成果物にします。→ 例

ライブシステムへ安全に接続する — MCP ハブ

収穫ステップはハブの呼び出しです。同じ仕組みは誰でも利用できます。サービスを登録し、機能で検出し、オーケストレーションできます。ユーザーごとの ID を使い、共有 API キーは不要です。

• ユーザーごとの認証：すべての外部呼び出しは、OAuth（GitHub / Microsoft）を介して あなた として実行されます。プラットフォームで共有するアカウントはありません。
• サービスが独自に検証できるトークン：ハブは呼び出しごとに有効期間の短いトークンを発行し、JWKS エンドポイントで公開鍵を公開します。JWKS に対応したサービスは署名を独自に検証するため、URL 内の静的 API キーは pAIchart が発行する ID に置き換わり、秘密情報が共有されることはありません。署名鍵は 90 日ごとにローテーションされます。
• サービスごとにスコープを設定：発行される各トークンにはサービスごとのオーディエンス（RFC 8707）が含まれるため、あるサービスから漏えいしたトークンが別のサービスでリプレイされることはありません。
• 信頼レベル：6 段階のモデルでトークン転送を制御します（INTERNAL → TRUSTED → OWNER → TEAM_MEMBER → SCOPED → ANONYMOUS）。
• エージェント向けの固定ツールセット：実行ループは常に、6 つの安定したツールを呼び出します。新しく登録したサービスはサービス呼び出しを通じてすべてのエージェントから利用でき、新たなツールスキーマやプロンプトの変更、再デプロイは不要です。
• オープンなレジストリ：あらゆる MCP サービスを 1 つのコマンドで登録でき、デフォルトでは非公開になります。検出は名前ではなく機能を基準に行い、ワークフローではサービスを順次、並列、または条件付きで連携できます。

管理、可観測性、アクセス

• DAG の定義や任意のエージェントのシステムプロンプトを Web アプリから変更できます。データベースに保存され、再起動や再デプロイなしで反映されます。
• 完全なフォレンジック：各実行のメタデータと成果物を GUI で確認できます。各エージェントが何を見て何を生成したか、どのチェックが実行されたか、ゲートが保留になった理由を確認できます。
• マルチユーザー：RBAC と個人用 API キーに対応しています。
• エージェントごとのモデル選択：ドロップダウンから現在の Claude ファミリーを選択できます。

作業の整理 — POV → フェーズ → タスク

多くのエージェントフレームワークでは、オーケストレーショングラフはコードであり、実行中にしか存在しません。pAIchart では、DAG のすべてのノードが タスク です。ステータス、依存関係、成果物、履歴を持つ永続的なレコードであり、チームがすでに使っている同じデリバリープランに含まれます。プログラムやパイプラインも、型付きタスクにすぎません。そのため、グラフは再起動後も維持され、各エージェントの作業は閲覧可能な作業項目となり、承認ゲートもタスクの遷移として扱われます。これは、人間がタスクを完了するときと同じもので、共通のコードパスを通じて処理されます。

そのため、別個のスケジューラーを運用する必要がなく、フォレンジックも標準で利用できます。ワークフローエンジンそのものが デリバリープラン なのです。「自分の POV のうち、リスクがあるのはどれですか？」 と尋ねれば、UI を使わずに回答が得られます。

はじめに

pAIchart は、Claude コネクターまたは ChatGPT アプリとして設定できるホスト型 MCP ハブです。インストールは不要です。AI クライアントをエンドポイントに接続して認証し、目的を伝えてください。

• ハブ：https://paichart.app/mcp
• 接続先：Claude Desktop（GitHub OAuth）または ChatGPT（Microsoft OAuth）— あるいはウェブアプリを使用
• 最初に伝えること：「paichart の使い方を教えて」 — または list_prompts() を実行すると、すべてのガイド付きワークフローを確認できます
• プライバシー：PRIVACY-DEMO.md — デモアカウントに保存される内容、利用できる機能、30 日後の自動削除について

プログラム（DAG）を実行するには、取得可能な場所にある 2 つのファイルを指定します（GitHub リポジトリも使用できます）。

ファイル	内容
requirements.md	HLD — 目的と制約を文章で記述します
topology.json	対象範囲内のデバイス／ターゲットと、それらの接続方法

次に、AI クライアントで「HOWTO-use-pov-program」プロンプトを読み込むよう依頼するか、GUI でタスクを 1 つ作成すると、グラフが実行されます。 GUI の共有 pov で多数の例を確認するか、「自分の pov を一覧表示して詳細を見せて」と依頼してください。 まずは小さく始めることもできます。

• HOWTO-use-pipeline-harness プロンプトを使い、その後「各スイッチに Loopback0 を用意して BGP で広告して」と依頼する — 1 つのパイプライン、1 つのドメインで、レビュー済みパッケージが返されます
• 「自分の POV でリスクがあるものは？」 — デリバリー分析に基づき、直接回答します
• 「サービスを検出して」 — 機能別にレジストリを参照します

自分で実行する

新規の Ubuntu 24.04 マシンまたは VM に完全インストールする手順 — docs/SELF-HOST-RUN-SHEET.md。 すべてのコマンドを順番に記載しており、前提知識は不要です。PostgreSQL 16 と Node 20 のインストール、データベースの作成、アプリの クローン、設定、シードデータの投入、起動、初回ログイン、管理者アカウントの作成、Claude Code のインストールとハブへの接続、 さらに（任意で）独自ネットワーク上のサービスの登録までを網羅しています。所要時間は約 40 分で、その大半は npm ci です。

Node 20、PostgreSQL 16 と空のデータベースがすでにある場合は、簡易手順を参照してください。

git clone https://github.com/paichart/paichart && cd paichart && npm ci
cp .env.example .env               # set DATABASE_URL, APP_BASE_URL and ADMIN_EMAIL; then:
npm run --silent jwt:keys >> .env  # RS256 signing keys (--silent keeps npm's banner out of .env)
npm run db:seed                    # schema, grants, first SUPER_ADMIN (password printed once), protocols, hub prompts
npm run dev                        # web app  → http://localhost:3000
npm run mcp:http:dev               # MCP hub  → http://localhost:8080/mcp

• docs/RUNNING.md — 各手順の内容：2 プロセス構成、ロール、APP_BASE_URL、本番環境に関する注意事項
• docs/VERIFYING-SELF-HOST.md — インストール環境が独自の ID を所有していることを確認します。すべてのトークンと OAuth ドキュメントが独自の APP_BASE_URL から生成され、他者の発行元のトークンは拒否されます
• docs/OAUTH-SETUP.md — 独自の GitHub／Google／Microsoft アプリを登録します（任意。パスワードログインは登録なしで利用できます）
• CONTRIBUTING.md · SECURITY.md

このプラットフォームは Elastic License 2.0 のもとでソースを公開しています。使用、変更、セルフホスト（自組織内での商用利用を含む）、再配布が可能です。ただし、第三者にホスト型またはマネージドサービスとして提供することはできません。このリポジトリには、プロトコルと検証パックに加えて、ソース一式（ウェブアプリ + MCP サーバー）が含まれています。paichart.app のホスト型サービスも、同じコードを実行しています。サーバー管理ツール（モニター、デプロイ、バックアップ）は意図的にリポジトリに含めていません。

内部の仕組み

You (Claude Desktop / ChatGPT / web app)
  → authenticate to the pAIchart Hub
  → one PIPELINE task, its title declaring the graph, pointing at your HLD
      │
      ├─▶ Program Architect designs the DAG + the interface contract every leg must honour
      │
      ├─▶ ⏸  PLAN GATE — a human releases it (AI client or GUI, one common code path)
      │
      ├─▶ legs execute: parallel where no edge joins them, sequenced where one does
      │     each leg:  harvest (read-only, via per-device MCP) → design → author → review
      │     each edge:  carries a real derived value forward, not an assumption
      │
      ├─▶ Tier 1 arithmetic in code · Tier 2 integration review over the composed set
      │
      └─▶ release gate — a deterministic AND, no confidence number
              ↓
    a reviewed LLD change package, in your AI client and the web GUI
    your team applies it — idempotently, out of band, with the rollback

外部への呼び出しはすべて共有プラットフォームアカウントではなく、ユーザー本人として実行されます。これはエージェントの下層で強制されるため、プロンプトインジェクションを受けたエージェントであっても、依頼したユーザーの権限を超えることはできません。

ライブサービス

Hub のオープンレジストリです。デバイスサービスは異なります。記述子から実行ごとにプロビジョニングされ、実行後に破棄されるため、pAIchart がデバイスの認証情報を保存することはありません。記述子の仕様はオープンです。仕様＋JSON Schema＋本番環境で検証済みの4つの例 をご覧ください。ご自身の機器向けに記述子を作成し、実行前に検証できます。

サービス	機能	ユーザーごとの認証
Snowflake	データウェアハウスのクエリ	✅ 外部 OAuth
EIA	米国のエネルギーデータ分析	サービスアカウント
Weather	リアルタイムの気象情報	サービスアカウント
EODHD	金融市場データ	サービスアカウント
Alpha Vantage	金融データ — 113 個のツール	サービスアカウント
Browser Automation	ウェブスクレイピング、スクリーンショット、PDF	サービスアカウント
Notifications	メール、Slack、ウェブフック	サービスアカウント
Token Validator	JWT/JWKS 統合と信頼レベルのデバッグ	✅ ユーザーごとの JWT

基本登録からグレード A のツールスキーマ、アクセス制御、信頼レベルまでの手順については、HOWTO-register-service（list_prompts()）を実行してください。

1つのコマンドで独自のサービスを登録できます。

registry(action: "register", {
  name: "my-service",
  description: "What your service does",
  endpoint: "https://my-service.com/mcp",
  category: "data-services"
})

学ぶ

• 検証パック — 20 件のドキュメントがあり、それぞれ実行前に期待される観測結果を示します。失敗したラウンドも含まれます。
• プロトコル — パックが実行を照合する、エージェント向けの正確な契約です。プラットフォームのシードとバイト単位で一致することを確認したうえで、原文のまま公開しています。意思決定ログに記載されたすべてのバージョンスタンプを、こちらで読みやすいテキストとして確認できます。
• 未解決の疑問 — 研究者向けです。興味深いと考えている知見が3つ（3段階のレビュー層が、信頼度が上昇中の段階で不具合を承認した事例）、結論を出すだけの能力がない仮説が1つあり、ラボ実行データも共有します。
• ケーススタディ — 同じ実際のネットワーク→クラウドプログラムを取り上げた3つの手順解説です。機械による検証（信頼できますか）、承認はしますが、作成はしません（何が得られるか）、マルチドメインプログラムの内部（どのように構築されるか — DAG、レビュー層、拡張可能な範囲）。
• MCP ツールの卓越性 — 外部ドキュメントなしで AI クライアントが呼び出せる MCP ツールの構築に関する全12章のシリーズです。pAIchart 自身の本番監査からまとめています。tutorials/README.md
• @paichart/containment-checks — Tier-1 の算術処理をそのまま MIT ライブラリとして切り出し、インシデント用フィクスチャのテストスイートを付属させています。LLM が導出したインフラ値（cidr、asn — kind による拡張が可能）を機械的に検査します。未実装の検査は合格ではなく、機械的な検査の対象外として報告されます。

リンク

• Hub（こちらに接続）：paichart.app/mcp
• JWKS：https://paichart.app/api/auth/jwks
• 検証：verification/
• ドキュメント：AI クライアント内の MCP リソース、または list_prompts()
• ソースとセルフホスティング：このリポジトリ — docs/RUNNING.md

クレジット

デバイス情報の収集には、MIT ライセンスのもと、改変した形で使用している @sydasif 作の nornir-napalm-mcp を活用しています。

キーワード

mcp mcp-hub mcp-server model-context-protocol dag directed-acyclic-graph multi-agent-orchestration low-level-design hld-to-lld change-synthesis intent-driven human-gated network-automation network-provisioning napalm nornir batfish kubernetes gitops terraform infrastructure-as-code multi-domain-automation verification deterministic-gate autonomous-agents change-management delivery-management pov service-discovery external-oauth jwks rfc8707 per-user-authentication workflow-orchestration claude-desktop chatgpt snowflake