mcpField
D
dmcheck

dmcheck

ローカル
github.com/chaoz23ゲーム・エンタメ01 週間前に更新

dmcheck について

dmcheck は、ゲームマスターやエージェント向けに、テーブルトーク RPG のログと任意のエンジンイベント記録を決定論的に判定するツールです。テーブル規約に基づき証拠付きの問題を示し、曖昧な証拠を確定的な非難にしません。

主な機能

  1. 01テーブル規約に沿ったログの評価
  2. 02規則の引用と証拠を添えた問題報告
  3. 03進行中の問題の発生・解決を監視
  4. 04ログとイベント記録の入力
  5. 05規約設定の検証
  6. 06構造化された判定と終了コードの出力

活用シーン

  1. 01未回答の質問をセッションログから確認
  2. 02未確認のダイス結果やターンを特定
  3. 03進行中のセッションで未解決の問題を監視
  4. 04無効または不完全な評価を人に回す

MCP 対応

README では、未公開の dmcheck-mcp 0.6.0 ソース候補を、`run` と `rules` ツールを備えた読み取り専用・バッチ専用の stdio MCP サーバーとして説明しています。インラインのログ、規約、イベント記録を受け付け、パス入力には明示的に許可されたディレクトリが必要です。

設定

ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。

mcp.json · 共通設定
{
"mcpServers": {
"chaoz23-dmcheck": {
"command": "uvx",
"args": [
"dmcheck"
]
}
}
}
起動コマンドuvx dmcheck

ローカルサーバーにはマシン上の実行環境(Node.js 18 以上など)が必要です。設定ファイルの場所はクライアントごとに異なります。

パッケージ
pypidmcheck0.5.1

ツール

2

掲載時のツール一覧 · 2 週間前に更新

パラメーター型必須説明
gmarrayいいえGM の作成者名(複数可)。charter.gm を上書きします
ledger_pathstringいいえ
charter_pathstringいいえ
transcript_pathstringはい

詳細

dmcheck

ライブテーブルトップセッションの決定論的な行為判定 — ゲーム進行のための CI。

セッションのトランスクリプト(任意でエンジンイベント台帳も)とテーブル憲章を渡すと、名指しの指摘を返します。たとえば、質問に回答されなかったプレイヤー、誰にも言及されなかったダイスロール、誰にも告げられずに始まったターン、チャンネルに漏れたネタバレ、5分間の沈黙などです。各指摘には、違反した憲章の規則と証拠が添えられます。

エージェントはこちらから → SKILL.md — 呼び出すタイミング、実例、MUST/MUST NOT。ファミリー共通の契約:FAMILY.md。

コールドブートの検証(2026-07-24): このリポジトリの URL だけを与えた新しいエージェントセッションは、2コマンドでインストールとセッションの判定を行い、ドキュメントに記載された3種類すべての終了コードの経路を検証し、誤認告発をしないという契約が守られることを確認しました(消費済みのロールに対しては指摘がありませんでした)。そこで得られた改善点は、0.1.1(--dice-bot、dmcheck charter)に反映されました。

設計上の契約: 誤認告発は許されないバグです。ソースで観測された証拠だけが確定的な指摘になります。従来の曖昧なケースは、無言で扱うか、severity: advisory、provenance: inferred、confidence: low と明示します。R8 によって確定扱いに格上げされることも、通知フックに送られることもありません。判定経路はモデルを使わず、決定論的です。同じトランスクリプトには、毎回同じ指摘が返されます。

判定付きセッションを30秒で始める

$ pip install dmcheck          # stdlib only, no dependencies
$ dmcheck run session.jsonl --gm "Greta"
{
 "result_schema_version": "1.0",
 "status": "findings",
 "exit_code": 1,
 "mode": "closed",
 "messages": 9,
 "findings": [
  {"finding_id": "r2-…", "rule": "R2", "summary": "unconsumed-roll: a dice result got no correlated GM narration within threshold",
   "charter": "roll_ack_within_messages=4; correlation=explicit",
   "detail": "dice result from DiceBot received no correlated GM narration within 4 messages",
   "evidence": {"index": 6, "author": "DiceBot", "obligation_id": "roll-42"},
   "status": "open", "severity": "finding", "provenance": "observed", "confidence": "high",
   "charter_digest": "sha256:...", "effective_policy": {"roll_ack_within_messages": 4, "...": "..."}},
  ...
 ],
 "counts": {"R1": 1, "R2": 1, "R6": 1, "R7": 1, "R8": 1}
}

table-kit のバージョン管理された契約を出力するポートフォリオホストは、トランスクリプトを事前に投影する代わりに、 dmcheck run-events session-events.jsonl --gm "gm-dan" を使用できます。厳格なアダプターは、table.event/1.0 オブジェクトの JSON 配列または JSONL を受け付け、イベント ID と相関 ID を指摘の証拠に保持します。宣言されたアクションは、権威あるエンジン解決として扱われないため、合法なリアクションや割り込みが誤って告発されることはありません。転送上の欠落、不明なバージョンや型、互換性のあるストリームがゼロ件の場合は、型付きの incomplete ステータスを返して終了コード 2 になります。不正な v1 イベントは invalid を返して終了コード 2 になります。メッセージ内容が秘匿されている場合も不完全として扱われます。文章が存在しないことだけでは、行為上の義務が存在しないとは証明できないためです。この未リリースのアダプターは table-kit の PR #11 に固定されており、ホストによる証明を意味するものではありません。

ポートフォリオホストが共有の table.evaluation/1.0 エンベロープを必要とする場合は、run-events に --table-evaluation を追加してください。この投影には、決定論的な評価 ID、正確なイベント証拠参照、ルールごとおよび全体のカバレッジ、カーソル/入力ダイジェスト、公開ポリシーダイジェスト、ステータス/終了コードのマッピングが含まれます。常に self_attested です。dmcheck が自らの出力にホストの権限を与えることはできません。

トランスクリプトの形式:{ts, author, content} の UTF-8 JSONL、または Discord API 形式のメッセージ({timestamp, author: {username}, content})を含む JSON 配列です。時系列順でも逆時系列順でも構いません。投稿者と内容は文字列です。タイムスタンプを指定する場合は、有限かつ非負のエポック値、またはタイムゾーン付きの ISO-8601 文字列である必要があります。不正なタイムスタンプは、時間ベースのルールを暗黙に無効化するのではなく、エラーとして拒否されます。ソースアダプターは、変更不可能な id、audience、reply_to/correlation_id、roll_id フィールドを保持してください。これにより dmcheck は、どの質問、ロール、イベントに対する応答なのかを証明できます。後から投稿された通常の GM の雑談は、回答として扱われません。

ルールセット(有効なルールは7つ、互換性のための旧IDは1つ)

ルール発火条件由来
R1GM に明示的に向けられた質問に、しきい値時間内に対応する返答がなかったプレイヤーが DM に世界設定について質問したところ、別の プレイヤー が答えてしまった
R2実際のダイス結果に、しきい値時間内に対応する GM の描写がなかった「命中した?」――プレイヤーの攻撃ロールが成功したのに、誰も反応しなかった
R3エンジンイベントに、対応する GM の描写がなかったテーブルの誰も知らないうちに、状態エンジンが命中を処理した
R4ターンが始まったのに、GM が行動者の名前を呼ばなかった「彼女のターンじゃないの?」――プレイヤーからの質問であり、プレイヤーが1人多すぎます
R5廃止済み。発火しません行動者とターン所有者が異なるだけで、合法なリアクションや割り込みが誤って告発された
R6設定された非公開用語が GM のメッセージに含まれていた。通常の出力では不透明な ID のみを表示モジュールの秘密状態名が描写に漏れた
R7プレイヤーが待っている間、GM の沈黙がしきい値時間を超えた30秒なら考えているように見えますが、5分では不在に見えます
R8セッション終了時に、現在も未解決で、ソースから観測された R1~R3 の義務が残っていた。推定された旧式のアドバイザリは昇格されませんセッションは明確な状態で終わるべきです。それが次のセッションを可能にします

有効なルールは、人間と AI のプレイヤーが混在し、AI GM が進行するハイブリッド卓を Discord 上で運営した際、実際に発生し、その週のうちにルール化された失敗から生まれました。人間の GM にも同じように適用できます。自分のエクスポートしたゲームログに対して dmcheck を実行し、卓のトランスクリプトが何を示すか確認してください。

R5 は、古いチャーターやエージェント連携を壊さないよう、参照可能な状態だけを保っています。評価器はなく、デフォルトで有効にもなりません。行動者とターン所有者が異なるのは、リアクション、準備アクションのトリガー、機会攻撃、伝説的アクションや領地アクション、操作下のクリーチャー、環境内の行動者、その他のシステムの割り込みを表す場合があります。台帳から合法性が確定するわけではありません。明示的で権威ある判断に基づく代替ルールは、共有の PORT-002 イベント契約に委ねられています。dmcheck が評価するのは、結果として生じるコミュニケーション上の義務またはリカバリーの義務だけです。

ライブモード(0.2):審判が卓に同席します

dmcheck watch は、進行中のセッション(stdin JSONL またはテーリング対象のファイル)に対して同じエンジンを実行し、ライフサイクルイベントを出力します。観測された検出事項が証明可能になったとき、または旧式の推定がアドバイザリになったときに OPEN を出力します(しきい値時間が完全に経過した場合のみ。予測は行いません)。解消されたとき(エンジンイベントが最終的に描写されたとき)には RESOLVED を出力します。--notify-cmd は、ソースから観測された OPEN 検出事項ごとに独自のフックを実行します。推定されたアドバイザリはイベントストリームには表示されますが、フックは実行されません。dmcheck 自体がどこかに投稿することはありません。 セッション終了時には、クローズドモードでのチェックが実行されます。session_end.open と open_count が報告するのは、対応可能なソース観測済みの検出事項のみです。R8 の集約項目と推定されたアドバイザリは含まれません。 検出事項 ID は、変化する経過時間の詳細に左右されず一意に決まります。また、ファイルの追跡では、ローテーション、切り詰め、不完全な行、順序の欠落によってカバレッジが不完全になった場合、型付きのソース健全性イベントが出力されます。

$ your-chat-fetcher | dmcheck watch - --gm "Rob" --notify-cmd 'notify-dm.sh'
{"event": "open", "rule": "R2", "detail": "dice result from RollBot received no correlated GM narration", ...}
{"event": "resolved", "rule": "R3", ...}
{"event": "session_end", "status": "findings", "exit_code": 1, "open": ["R1"], "open_count": 1, ...}
$ dmcheck explain R2            # the rule, its charter knobs, and the table failure that earned it
$ dmcheck lint-charter my.json  # unknown keys / bad thresholds refuse loudly

ライブモードの意義は、ルールが捉えるすべての失敗は、起きたその瞬間ならリカバリーできたという点にあります。返答のない質問、古くなったロール、欠けた合図はいずれも、ほんの数秒の間に促しを入れれば、場の流れを保てました。事後チェックで分かるのは昨夜何がうまくいかなかったかです。watch は、プレイヤーがそれを感じる前に GM にそっと知らせます。

憲章はコードではなく設定です

dmcheck/default_charter.json は、パッケージに含まれる唯一の正式なデフォルトです。schema_version、charter_version、検証済みの SHA-256 charter_digest を保持しており、チェックアウト時も wheel 実行時も同じリソースを読み込みます。そのダイジェストはスキーマと憲章のバージョンの組み合わせに対してリリース単位で固定されているため、パッケージ化されたデフォルトを変更すると、バージョン移行を宣言するまで読み込みが拒否されます。キューの規約、無音時間の許容範囲、ダイスボット名、非公開用語リストなどは、いずれも上書きしてバージョン管理してください。非公開用語には、互換性のため文字列を使用することも、{id, value} オブジェクトを使用することもできます。ホストが発行する不透明な ID を推奨します。検出結果、監視フック、CLI、MCP の出力には、設定された値も照合した生の抜粋も含まれません。評価エンベロープ、lint-charter、検出結果 ID、ソースフィンガープリントなど、通常の出力先に出力されるすべてのダイジェストや相関ハッシュは、公開された、秘匿化済みのポリシー/証拠から生成されます。意図的に非公開の値を証明も確定もすることはありません。完全な正規化ダイジェストは、信頼された憲章ドキュメント内にのみ保持されます。リーグや組織プレイプログラムは、プレイヤーガイドを公開するのと同じように憲章を公開できます。dmcheck は、その憲章に照らして任意の卓を審判できます。

$ dmcheck run session.jsonl --charter our-table.json --ledger events.jsonl
$ dmcheck rules            # the rule set with definitions
$ dmcheck charter          # inspect effective public policy; hidden values are redacted
$ dmcheck run session.jsonl --gm "Rob" --dice-bot "RollBot"   # quick overrides, no file needed
$ dmcheck --schema         # machine-readable I/O contract
$ dmcheck --pipe           # batch: JSON requests on stdin, verdicts on stdout

直接 API を呼び出す場合は、apply_charter_overrides(load_charter(), gm=["Rob"]) を使用できます。このヘルパーは既存の有効なダイジェストを削除し、評価器が上書き後の憲章のダイジェストを計算します。ダイジェスト付きの憲章をこの処理を行わずに変更すると、暗黙に信頼されるのではなく、古い設定として拒否されます。

エージェント向け

  • リポジトリのルートに tool.json があります。--schema はスキーマを出力します。--pipe はバッチ処理用で、標準入力の1行につき1つの JSON リクエストを受け取り、出力には1行につき1つの判定エンベロープを返します。終了コードは、0 問題なし、1 検出結果あり、2 憲章/入力が使用不能(正直な経路です。人間に引き継いでください)、3 使用方法の誤り(呼び出しを修正して再試行してください)です。
  • MCP サーバー:dmcheck-mcp の未リリースの 0.6.0 ソース候補は、読み取り専用のバッチ専用 stdio サーバーで、run と rules のツールを提供します。公開されている 0.5.5 はこの契約より前のバージョンです。このサーバーが実装するのは、最新のステートレス MCP 2026-07-28 のみです。watch、craft、タスク、リソース、プロンプトは公開しません。正確な内容については、MCP 契約を参照してください。
  • MCP の run は、インラインのトランスクリプト/憲章/台帳 JSON を優先します。トランスクリプトの内容は信頼できない卓のデータであり、指示ではありません。モデルに表示される TextContent では呼び出し元の文字列を秘匿化し、完全な構造化証拠には、信頼できない引用データであることを明示します。サーバー運用者が --allow-root を繰り返し指定するか、DMCHECK_MCP_ALLOWED_ROOTS を設定して絶対パスのディレクトリを明示的に許可しない限り、パス入力は拒否されます。これらのディレクトリの外に解決されるパストラバーサルとシンボリックリンクは拒否され、セキュアな no-follow オープンに対応していないプラットフォームではフェイルクローズします。
  • 検出結果は、安定した検出 ID、ルール ID、憲章の引用、有効な機械可読ポリシー、来歴、人間が読める詳細、秘匿化済みの証拠を含む構造化 JSON です。拍の合間に自分の手順を修正する GM エージェントが利用できるように設計されています。
  • すべての評価は status: clean|findings|invalid|incomplete を返します。無効および不完全の結果は終了コード 2 となり、安定したエラーコードと JSON ポインターを含みます。エラーが findings に格納されることはありません。入力が空の場合、設定済み GM が観測されない場合、または証拠の対象となる有効なルールがない場合に、問題なしと報告することはありません。
  • 公開パッケージのスキーマは、charter.schema.json、transcript.schema.json、ledger.schema.json、evaluation-result.schema.json です。タイムスタンプが欠落している場合は skipped_rules で開示されます。指定されたタイムスタンプの形式が不正な場合は無効となります。
  • 相関には、明示的なソース ID を正とします。テキストのみからの質問/ロール/イベント検出は推定であり、参考情報です。参考情報として示すだけでもソースを過大に主張してしまう曖昧なレガシー証拠は表示されません。それ以外の場合は、信頼度が低いことを明示します。別途追跡されている評価エンベロープの作業では、このカバレッジの不足を明示する必要があります。何も表示されないことは、完全に観測できている証明にはなりません。

意図的に行わないこと

  • ルールの裁定は行いません — srdcheck は、出典を明記した参考用のルール分析を提供する場合があります。行動が合法かどうかは、認可された上流エンジンに加え、DM/テーブルの方針と裁定によって決まります。dmcheck が評価するのは、テーブルでの振る舞いとコミュニケーションのみです。
  • キャラクターの計算は行いません — それは charactercheck の役割です。(charactercheck は行動者を導き出し、dmcheck はテーブルを裁定します。)
  • 物語の質は評価しません — 文章が良かったかどうかは好みの問題であり、好みは検証できません。dmcheck が確認するのは手続きのみです。
  • モデル呼び出しもスコアもありません — ルールごとに決定論的な指摘を行い、総合的な「DM 評価」は決して行いません。

クレジット

ルールセットは、人間と AI が協働するハイブリッドなテーブルの実際のセッションから抽出されました。native-gaming-harness の Router+Detector パターンも独立して同じアイデアにたどり着いており、これが重要な要素であることを示す証拠だと考えています。dmcheck はゲームシステムに依存せず、どのパブリッシャーとも提携していません。

mcp-name: io.github.chaoz23/dmcheck

新しいテーブルのセットアップ(v0.3)

dmcheck init charter.json --gm YOUR-NAME

スターターチャーター(バージョン管理され、適用日が設定され、構成上 lint に合格するもの)を書き出し、セッションゼロのチェックリスト S1–S8 を表示します。これには S3c も含まれます。シートの説明責任についてはセッションゼロで口頭で宣言し、その後、清算時のクイズは非公開で採点します。テーブルを裁定するレフェリーが、そのテーブルの規約も提示します。

座席ごとの合図ポリシー(R4、強化済み)。 Discord の allowBots="mentions" のようなメンション必須のトランスポートを使うエージェント席には、本文中の名前による合図が届きません。次のように宣言します。

"seats": {"Shalia": {"cue_requires_mention": true, "mention": "<@1493...>"}}

これにより R4 は、文字列どおりのメンションが含まれる場合に限り、合図として数えます。発端は実際のセッションです。「Shalia — you're up」と投稿され、合図のように見えたものの、配信できないことが確認されたため、R4 は合図として扱いませんでした。同じことは二度と起こしません。

台帳の形式(宣言済み標準)。 dmcheck の台帳は JSONL 形式です。 {ts, type: turn|act|event, id, actor, text} — エンジンのイベントごとに 1 行です。GM のナレーションには対応する correlation_id が付与されます。エンジンのイベントごとに 1 行が書き込まれます。 調査時点(2026-07-26)では軽量な OSS セッション台帳が存在しなかったため、この形式をスタック共通の相互運用標準としています。エンジンはログをこの形式に取り込み、run、watch、清算処理はすべてこの形式を利用します。actor と turn は調整のためのコンテキストにすぎません。両者の不一致が、不正な行動や振る舞いの違反の証拠になることはありません。

証拠の基準(v0.4)

素朴なルールがどこで誤ったか、保留データでの検証、否定的な結果を含む、完全な調整の経緯は docs/CALIBRATION.md に記載しています。

134 時間のプロによるプレイを基に調整しました。そこでは素朴なルールが大きく誤作動し、R1 は 1 エピソードで 85 回発火しましたが、有効な指摘は 0 件でした。R7 は空白時間を 115 件検出しましたが、そのうち実際の問題は約 5 件でした。

  • R1 は明示的な対象者と相関の証拠を優先します。明示された公開向け/プレイヤー向けの対象者が GM の義務として扱われることはありません。また、後から追加された無関係な GM のテキストによって、型付き質問が解決済みになることもありません。従来のテキストヒューリスティック(GM の名前が記載されている、ルール関連の語彙がある、または隣接している)は推論に基づく参考情報であり、テーブルが待機中であることも引き続き必要です。設定項目:question_requires_gm_address。
  • R7 は譲られた発言権を対象外とします。プレイヤーが話している間、GM が発言を控えるのは技量であり、不在ではありません。設定項目:dead_air_requires_quiet_table、thresholds.quiet_table_max_messages(デフォルト 3)。
  • R4 の座席には aliases が追加されます。プロのセッションでは、キャラクター名による作中の合図が約 10:1 で使われるため、レフェリーはキャラクター名を合図として認識する必要があります。

明確に述べておく変更点が 1 つあります。推論/テキストのみの R1 は、別のプレイヤーが GM に代わって回答した場合に発火しなくなりました。活発なテーブルでは、そのやり取りは、誤った告発が続出した原因の雑談とテキスト上で区別できず、D1 は沈黙を選ぶためです。明示的な対象者と不変の義務 ID がある場合は、無関係なプレイヤーの活動や、同時進行中の別の質問によって抑制されることはありません。

アテンションレーン(v0.5)

dmcheck craft session-beats.json --scene SOCIAL --pc Teodor --pc Shalia

統計、1つのアテンションシグナル、カテゴリ別の欠陥です。スコアではありません。 レートはプロ向けの基準(134時間、DM 2人)に照らして算出します。attentionは、 シーンの重みを反映する単一のシグナルで、解決したら次に進みます。5つのダイヤルを 備えたダッシュボードのせいで、作者自身が確認していない指標が生じたためです。 カテゴリ別の検出機能は、レートでは構造上捉えられないものを検出します。プレイヤーの キャラクターを代わりに演じる、推論ツリーを公開する、裁定を先送りする、プレイヤーの 代わりにロールする、といった問題です。これらはすべて、実際のセカンドエージェント テストで発見されました。あくまで助言のみです。レポートを提示し、判断はDMが行います。 シーンの要求に応じて、オーバーライドが行われることを前提としています。

seat_quiet(v0.5.2)

watch --craft --pc <name>は、シーンが進行する中で、プレイヤー席がN回のGMビートに わたって沈黙した場合にも、seat_quietの助言を出力します(設定項目: seat_quiet_gm_beats、デフォルトは3)。きっかけは、人間のプレイヤーが離席し、 エージェントの席がそのプレイヤー不在のままシーンをクライマックスまで進めたことです。 この助言では、状況を確認し、取り消せない進行を保留することを提案します。助言によって 進行が妨げられることはありません。誰かがいなくなっても中断しないことが、バーチャル テーブルの長所だからです。

ルールチェック(v0.5.4)

craftは、セッションごとにプロトコルの機械検証可能なルールを実行するようになりました (テスト可能性の規約:ルールには反証条件を明記する必要があります)。 1a 戦闘開始から5ビート以内にイニシアチブ順を提示する · 1b ターンを進める ビートの95%以上でPCを指定する · 11a 戦闘中、ダメージが発生したビートの中央値を 20語未満にする(テンポよく進める際は数値を中心に記述します) · 11b キルには、 戦闘ビートの中央値の3倍以上の演出を加える(語彙によるキル検出。検出結果はレビュー 項目であることを明示します)。 すべて助言のみで、スコアは存在しません。

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。