Concord

Concord

ODI standards hub 向けに構築された、データ標準を共同で設計するためのプロトタイププラットフォームです。すべての標準は、論理的一貫性と FAIR を維持する厳密な OWL 2 オントロジーであり、最初の対話から公開リリースまでのライフサイクル全体を、各段階で AI の支援を受けながら非同期で進めます。

• 要件を3つの方法で収集します。 AI インタビュアーが構造化されたユースケースに沿って進行し、コンピテンシーに関する質問と回答例を尋ねます。Google Meet のトランスクリプトをアップロードすることも、他のゲストと同じようにメールで招待した共同ファシリテーターのボットをライブ通話に参加させ、必要に応じて Meet のチャットで明確化のための質問をさせることもできます。Claude Code や Codex などのコーディングエージェントは MCP 経由で接続し、オントロジーを読み取って、不足している概念や適合性の低い概念を報告します。
• 要件を変更に反映します。 ユースケースを統合し、構造化された編集内容と、各コンピテンシーに関する質問の SPARQL テストを含む変更リクエストを作成します。モデルが RDF を直接書き込むことはありません。用語を提案し、サーバーがそれらを検証済みの編集操作にコンパイルします。
• 用語を読んでいる場所で編集できます。 「閲覧」の各用語には、問題の報告の横に、ラベル、定義、コメント、別名、例、編集メモを編集するボタンがあります。編集内容は編集上の変更リクエスト（updateAnnotations 編集を1件）となり、他の変更と同様に分類、検証、承認されます。マージされるまで作業中のドラフトには反映されません。編集では元の値が記録されるため、同じフィールドへの別の変更が先にマージされた場合は上書きせず、編集者に差し戻されます。また、定義の言い換え時には意味が保たれているかを確認し、意味の変更はメジャー変更として審査されます。
• 会議なしでガバナンスを実施します。 すべての変更は、明示的なルール（OWL のバージョニング慣行と gist のセマンティックバージョニング方式に基づく）に従ってパッチ、マイナー、メジャーに分類され、検証（厳格なリンティング、sparq による OWL 2 DL 推論、FAIR チェック、コンピテンシーに関する質問）された後、オントロジーのガバナンスポリシーに基づいて審査されます。ポリシーは5種類のテンプレート（スチュワード主導、緩やかな合意、W3C ワーキンググループ、会員投票、ODI スチュワード制）から選択でき、承認数と役割、審査期間、定足数と基準を伴う投票、拒否権、ODI の特権、所有権と移転、自動化の範囲を調整できます。
• 適切にリリースします。 リリースのバージョンは、含まれる変更のうち最も高いレベルに合わせて引き上げられ、セマンティックバージョンが更新され、owl:versionIRI、owl:priorVersion、owl:backwardCompatibleWith または owl:incompatibleWith が付与されます。また、メジャーバージョンでは、すべての形式と SPARQL 移行スクリプトが含まれます。各オントロジーは Git リポジトリ（リリースごとにタグを作成）であり、設定されている場合はリリース時に GitHub にプッシュされます。
• 提案された変更を実際のアプリでテストします。 オントロジーを基盤に構築する人はアプリを接続できます。GitHub Action が、各未完了の変更リクエストによって生成されるオントロジーに対してアプリをテストし、結果を報告するため、変更によって何が壊れるかをすべて確認できます。オートパイロットが有効な場合、アプリがテストに合格すると、Concord はそのアプリの所有者に代わって承認または賛成票を投じるため、所有者の対応待ちで変更が滞ることはありません。
• 固有のアドレスで読みやすく表示します。 オントロジー IRI と各バージョン IRI は、W3C や Widoco の語彙ドキュメント形式の公開ページに解決されます。このページには、メタデータ、各用語のリファレンス項目（IRI のフラグメントをアンカーとして使用）、そのバージョンの基となったユースケースと要件、リリースノート、すべてのシリアライゼーションが含まれます。RDF クライアントは同じアドレスから、コンテントネゴシエーションまたは拡張子（/def/<slug>/<version>.ttl）を使って Turtle、JSON-LD、RDF/XML、N-Triples を取得できます。このページは各リリースにも index.html として書き込まれ、永続的な IRI 用の w3id.org リダイレクトルールも生成されます。
• データを検証します。 オントロジーの データを検証 ページに RDF を貼り付けるかアップロードするか、オントロジーまたはバージョンのアドレスに POST します（curl -X POST https://<site>/def/<slug>/<version> -H 'Content-Type: text/turtle' --data-binary @data.ttl）。データは、そのバージョンから導出された SHACL シェイプと、そのデータ内で定義されている用語に照らして検証されます。結果は JSON レポート、または Accept: text/turtle の場合は SHACL sh:ValidationReport（最初の1,000件の結果を列挙し、要約には全件数を表示）です。Turtle、JSON-LD、N-Triples、N-Quads、TriG、RDF/XML に対応し、最大5 MB（JSON-LD は2 MB）、または異なるトリプルが25,000件まで（IRI とリテラルは最大800万文字、IRI は最大4,096文字）を受け付けます。同時に2件まで、クライアントごとに毎分30リクエストまでです。SHACL プロファイル（Accept-Profile: <http://www.w3.org/ns/shacl#> または ?_profile=shacl）を指定すると、シェイプ自体も同じアドレスから取得できます。エージェントも MCP の validate_data ツールから同じ検証を利用できます。
• ブラウザーでクエリを実行します。 「クエリ」タブは、WebAssembly にコンパイルされた SPARQL エンジンの sparq にオントロジーを読み込み、SPARQL を実行したり、サーバーとの往復なしでインスタンスデータをオントロジーの SHACL シェイプに照らして検証したりできます。
• 読むだけでなく、視覚的に確認できます。 「閲覧」タブには、schema.org 形式のプロパティテーブルを備えたアクセシブルなクラスツリー、UML 形式のクラス図（属性、カーディナリティ付きの関係、サブクラス）、ネットワークグラフがあります。オントロジーの視覚化をご覧ください。
• 好みの形式で表示します。 Turtle、LinkML、JSON-LD、RDF/XML、N-Triples、Manchester 構文、SHACL シェイプに対応し、より読みやすい SHACL コンパクト構文（SHACLC）でも表示できます。
• すぐにコードで利用できます。 すべての SHACL シェイプは、ODI SHACL converter と @rdfjs/wrapper を使って生成された JavaScript クラスとしても提供されます。アプリからオントロジー独自のアドレスを指定してインポートする（import { VolunteeringDataset } from "https://…/def/volunteering/1.0.0.js"、または Accept: text/javascript）か、.d.ts から型を取得するか、npm install https://…/def/volunteering/1.0.0.tgz を実行できます。パッケージ名はすべてのバージョンとフォークで同じなので、アプリでフォークからリリース版に切り替える際に変更するのは URL だけです。
• ID とプライベートデータ。 Google または GitHub でサインインします。WebID と Solid ポッドが自動的に作成され、インタビュートランスクリプトなどの非公開データはポッドに保存され、構造化された公開部分のみが共有されます。
• アルファテストを標準搭載。 /alpha では、テスターが希望する役割を選び、その周囲にシミュレートされたワーキンググループを設定して、プラットフォームを順に試せます。また、/feedback では、音声に対応したフィードバックチャットを、ガイド付きと自由入力の経路で利用できます。

実行

Node 22.13+ と pnpm 10 が必要です。Git が PATH に含まれている必要があります。

pnpm install
pnpm dev            # API on :8787, web app on :5173

http://localhost:5173/alpha を開きます。設定なしで完全にオフラインで動作します。AI の各ステップでは決定論的なフォールバックを使用し、非公開データはローカルディスクに保存され、デモアカウントでサインインします。

OWL 2 DL の推論（整合性、充足不能クラス、推論された階層）は、WebAssembly にコンパイルされた sparq で実行されます。サーバー（ワーカースレッド内）とブラウザー（Web Worker 内）の両方で同じコードを使用するため、追加のインストールは不要です。sparq は OWL 2 DL の大部分を判定します。オントロジーを判定できない場合や、ステップ予算を使い切った場合はその旨を伝え、判定できるまで検証は合格になりません。./toolkit/setup.sh がインストールするのは、コアテストのひとつで使用する LinkML のみです。

Claude を使用するには、ANTHROPIC_API_KEY を設定します（すべての設定については .env.example を参照してください）。デフォルトのモデルは claude-opus-5-5 です。

Docker

cp .env.example .env
docker compose up --build   # Concord on :8787, Community Solid Server on :3000

デプロイ（Vercel と Azure）

Web アプリは Vercel で配信されます。長時間稼働するサーバーが必要なすべての機能（API、サインイン、MCP エンドポイント、ライブ会議ストリーム、ガバナンスクロック、Solid サーバー）は、deploy/azure/deploy.sh で起動する小規模な Azure VM 1 台で実行され、Azure for Students の無料枠に収まります（代替として AWS 用のテンプレートも用意されています）。Vercel は /api、/auth、/mcp、/people、および MCP クライアント向けの OAuth エンドポイントをこの VM に転送するため、ユーザーに表示されるのは Vercel のリンクだけです。GitHub Actions がプッシュのたびにテストを実行してバックエンドイメージをビルドし、サーバーは 5 分以内に新しいイメージを取得します。手順については、docs/deploy.md を参照してください。

コーディングエージェントを接続する

Concord の任意のサイトで /connect を開くと、インストールボタンが表示されます。URL 以外に必要なものはありません。

claude mcp add --transport http concord https://standards-concord.vercel.app/mcp   # Claude Code, then /mcp → Authenticate
codex mcp add concord --url https://standards-concord.vercel.app/mcp && codex mcp login concord

Claude（Web、デスクトップ、モバイル、および Claude アカウントでサインインした Claude Code）では、Add to Claude ボタンをクリックすると、入力済みのカスタムコネクターのダイアログが開きます。ChatGPT も同様に、OAuth を使用するカスタム MCP サーバーとして接続します（ページに手順が記載されています）。最初の接続時にブラウザーが開き、ユーザーが Concord にサインインして「許可」をクリックします。MCP エンドポイントは MCP 認可仕様（PKCE を用いた OAuth 2.1、保護されたリソースのメタデータ、動的クライアント登録、クライアント ID メタデータドキュメント）を実装しているため、トークンをコピーする必要はありません。CI などのヘッドレスエージェントには、個人用トークン（同じ Connect an agent ページの、接続済みエージェント一覧の下にあります）を引き続き使用できます。

このリポジトリは Claude Code（/plugin marketplace add standards-concord/standards-concord）および Codex（codex plugin marketplace add standards-concord/standards-concord）向けのプラグインマーケットプレイスでもあり、server.json は MCP Registry のエントリーです。Concord のドメインを変更するときは、 node scripts/public-url.mjs https://<new-origin> を実行してマージしてください。これにより、すべての掲載情報が更新され、レジストリーのエントリーが再公開されます。サイト自体を変更する必要はありません。サイトが表示するすべての URL と OAuth エンドポイントは、配信元のアドレスから導出されます（バックエンドが転送されたアドレスを信頼するように、Vercel とバックエンドの両方で CONCORD_PROXY_SECRET を設定してください。docs/deploy.md を参照してください）。インストール済みのプラグインは更新時に新しいドメインへ移行し、エージェントは新しいアドレスで再度サインインします。そのため、しばらくは古いアドレスも使える状態にしておいてください。掲載情報の詳細と提出先については、docs/mcp-listings.md を参照してください。

開発用フォーク

標準にまだない用語が必要ですか？ フォークを作成して用語を追加し、変更のレビュー中も開発を続けられます。フォークはオントロジーの独自のプレリリース版です。

• https://<host>/def/<ontology>/forks/<fork> で解決されます（コンテンツネゴシエーションに対応しており、クライアントが HTML を要求しない場合は Turtle を返します。または拡張子で指定できます：.ttl、.jsonld、.owl、.nt、.omn、.linkml.yaml、.shacl.ttl）。そのため、アプリケーションから直接インポートできます。常にフォークの最新リビジョンを配信し、CORS はオープンです。
• 新しい用語も標準の名前空間を使うため（フォーク固有の IRI ではなく、vol:VolunteeringActivity を使用します）、フォークに基づいて作成したデータは、その用語が標準に取り込まれた後も有効です。メインのオントロジーに戻すには、インポート URL を変更します。
• プレリリースとして記録されます。owl:versionIRI はフォークの URL、owl:versionInfo は 1.0.0-fork.volunteer-hours.2 のような値、owl:priorVersion は派生元のリリースを示します。
• フォークを提案すると、そのすべての編集を含む変更リクエストが 1 件作成され、オントロジーの通常のガバナンスプロセスを経ます。さらに編集を加えた後に再提案すると、そのリクエストが更新されます。
• 各フォークは、オントロジーのリポジトリにある forks/<fork> という Git ブランチです。main に影響することはありません。フォークへの変更（クローズを含む）はすべて、compare-and-swap でブランチを更新し、バージョンに対するアトミックな条件付き書き込みでフォークの記録を保存します。保存に失敗した場合、コミットは取り消されます。
• 変更が取り込まれたかどうかは、内容に基づいて 3 つの方法で判定されます。フォークが変更した各用語について、Concord はフォークのベース、フォーク、作業ドラフト、最新リリースの内容を比較します（dcterms:created などの来歴情報は無視します）。上流の用語がフォークと完全に一致する場合にのみ、その用語はマージ済みまたはリリース済みと見なされます。そのため、レビュー中に用語の名前や説明文が変更されても、移行が誤って開始されることはありません。
• 同期すると、フォークを最新のドラフトに移し、まだ取り込まれていない編集だけを再適用します。フォークも変更している用語を上流が変更した場合（直接変更した場合、またはフォークでの削除が上流で追加された用語に及ぶ場合など）、あるいは結果に矛盾が生じる場合は、何も変更されず、競合が一覧表示されます。上流のバージョンを採用するには、フォークの変更を破棄してから同期し、必要に応じて再度変更します。
• フォークの編集は HermiT で整合性が検証されます。CONCORD_REQUIRE_REASONER が有効な場合（NODE_ENV=production のときはデフォルトで有効）、推論器を実行できないフォークの変更は、構造だけを検証して続行するのではなく、拒否されます。
• 移行計画は、同じ拡張子を使って /def/<ontology>/<version>（または /def/<ontology>/draft）を参照します。バージョン IRI は、RDF を要求しないクライアントには HTML ページを返します。そのため、Accept ヘッダーなしで取得するコードは .ttl URL に切り替える必要があります。計画にもその旨が記載されます。

ハブでは、フォークは Changes → Forks にあります。MCP では、create_fork、edit_fork、propose_fork、check_forks、sync_fork、discard_fork_changes、list_forks、get_fork、close_fork を使います。エージェントには、各開発セッションの開始時に check_forks を呼び出すよう指示されます。これにより、フォークを使い続けるか、同期するか、競合を解決するか、ドラフトまたはリリースに切り替えるかが、置き換えるインポート URL とともに示されます。

提案された変更に対してアプリをテストする

任意のオントロジーで Changes → App checks からアプリを接続し、Concord app check action を CI に追加します。結果は各変更リクエストに表示され、アプリのテストに合格すると、autopilot があなたに代わって承認または投票できます。

オプションサービス

機能	設定
Google / GitHub でサインイン	GOOGLE_CLIENT_ID/SECRET、GITHUB_CLIENT_ID/SECRET
プライベートデータ用のSolidポッド	SOLID_SERVER_URL（Community Solid Server v7+）
Google Meetのライブボット	RECALL_API_KEY（Recall.ai）。Google Meet Media APIはまだクローズドプレビューです。MEET_BOT_EMAILとMEET_BOT_ICS_URLを追加すると、ボットのアドレスを通話（または定期的なシリーズ）に招待することで、ボットが参加します：docs/meet-bot.md。
GitHubへのリリース公開	GITHUB_PUBLISH_TOKENを設定し、オントロジーにリポジトリを指定します
オプトイン方式の公開フィードバック要約をGitHubのIssueとして投稿	FEEDBACK_GITHUB_TOKEN（Issue：読み取りと書き込み）。docs/feedback-issues.mdを参照してください
Firefoxでの音声入力	STT_PROVIDER=openai、OPENAI_API_KEY

構成

packages/core     OWL engine: parsing, edit operations, diff, change classification, versioning,
                  lint, FAIR checks, reasoners, competency-question tests, LinkML/Manchester/SHACL
packages/shared   Domain types and the HTTP API contract
apps/server       Express API, MCP endpoint, governance engine, AI prompts, Solid, meeting bot
apps/web          React app
toolkit           Python virtualenv with LinkML, used by tests
docs              Research, the alpha walkthrough script and questions for ODI colleagues

テスト

pnpm test            # unit and API tests
pnpm test:e2e        # browser tests (Playwright): the alpha walkthrough and every page
pnpm test:e2e:live   # read-only smoke tests against the deployed site (LIVE_URL)

ブラウザテストでは、独自のAPIサーバー（使い捨てのデータディレクトリを使用し、ポート8797で起動）とウェブアプリ（ポート5183で起動）を起動するため、実行中のpnpm devには影響しません。開発サーバーの代わりに本番ビルドをテストするには、E2E_MODE=previewを設定してください。先にpnpm --filter @concord/web buildを実行します。CIではプッシュのたびに両方のモードを実行し、Vercelへの本番デプロイのたびにライブテストを実行します。新しい仕様はe2e/<feature>.spec.tsとして追加し、e2e/fixtures.tsのtestを使用してください。このtestは、ページのコンソールにエラーが記録されたり、ページがクラッシュしたりするテストを失敗させます。

すべての機能にPlaywrightテストがあり、すべてのバグ修正には、そのバグを再現するPlaywrightテストが付属するため、再発を防げます。docs/e2e-coverage.mdでは、各ページ、ロール、フローを、それをカバーする仕様に対応付けています。詳細はCLAUDE.mdを参照してください。

ドキュメント

• アルファ版のウォークスルー
• ナレーション付きウォークスルー動画：pnpm walkthroughを実行すると、編集可能なスクリプトから動画を録画します
• ODIの同僚への質問
• 調査：オントロジーの実践、要件、バージョニング、ガバナンス、オントロジーの視覚的な表示、技術的な選択肢、ODIプレイブック