CodeCraft

---

開発の背景

Bedrock では、フィールド名を少し間違えて記憶しているだけで、出力が気づかないうちに動作しなくなります。 エラーメッセージも赤い下線もありません。パックをゲームに読み込むまで、すべて正常に見えます。

実例 — どちらの行もスキーマを通過しますが、片方は読み込まれません。

  "modules": [
-   { "type": "javascript", "entry": "scripts/main.js" }
+   { "type": "script", "language": "javascript", "entry": "scripts/main.js" }
  ]

上の行では、パックがビヘイビアーパックの一覧にまったく表示されませんでした。 エラーすら発生しませんでした。javascript 型は 1.16 より前のもので、スキーマには後方互換性のために残されていますが、@minecraft/server 2.x では読み込まれません。スキーマは「有効な型」と判定しますが、ゲームは「この型は読み込めません」と判断します。

この 1 行は実際のゲームで測定したものです（30-08-2026）。同様のケースがあと 7 種類あり、ContentLog の証拠とともに docs/VALIDATION-LIMITS.md に記載されています。

CodeCraft はこのギャップを埋めます。**値はバージョンを固定したデータから取得し、**出力は公式スキーマと実際の tsc の両方で検証されます。

9 つのツール

すべて読み取り専用です。サーバーは何も書き込まず、データをどこにも送信せず、ユーザーデータも保持しません。

ツール	返される内容	使用するタイミング
check_feasibility	Bedrock で実現できるかどうか。できない場合はその理由と代替手段	何かを生成する前
get_version_info	各所に指定すべきバージョン番号、モジュール、有効な format_version	ファイルの作成前
get_schema	必須フィールドと、そのノードにあるフィールドの一覧	ファイルの作成前
lookup_id	識別子が存在するか、型、ブロックステート	記憶を頼りにした識別子ごと
validate_json	JSON ポインターを含むスキーマエラー	生成したすべての JSON ファイル
validate_command	コマンド、引数の数、セレクター、ブロックステート	コマンドを渡す前
validate_script	行、列、TS コードを含む実際の tsc 診断	API 呼び出しごと
validate_python	構文、埋め込みコマンド、/connect エンベロープ	ゲーム外の自動化スクリプト
review_pack	すべてのファイルに加え、スキーマでは構造上確認できない項目	何かを渡す直前の最終ステップ

順番はアルファベット順ではなく、使用する順番です。tools/list もこの順序を維持します。

セットアップ

エンドポイント	https://codecraft-ashy-seven.vercel.app/mcp
使い方サイト	codecraft-ashy-seven.vercel.app — ホーム、セットアップ、ツール、制限の 4 ページ
トランスポート	ステートレスな Streamable HTTP、POST のみ
認証	なし — エンドポイントは読み取り専用で、非公開情報を返しません

Claude で Customize → Connectors を開きます（Settings ではありません。古いガイドではそちらを案内していますが、その画面にはカスタムコネクター欄がありません）。

1. Customize → Connectors → カスタムコネクターを追加
2. エンドポイントのアドレスを貼り付ける
3. 保存する

接続後、次の 3 点を確認してください。「動作した」という表示が 1 つあるだけでは不十分です。

• ツール数が 9 で、すべて揃っている
• クライアントで 「read only tools」 と分類されている — 独立した権限クラスです
• 独自のタイトル（例：「Can Bedrock do this」）が表示されている — ツールの表示名は英語です

詳細：docs/MCP.md

検証で見つけられることの限界

この表は宣伝ではなく、限界を示すものです。「検証に合格した」ことと「ゲーム内で動作する」ことは同じではありません。8 種類のエラーは検証をすり抜けてゲーム内で問題を起こし、そのすべてが実際のゲームで確認されています。

種類	スキーマで検出できるか	CodeCraft の動作
A · 識別子参照	いいえ。ただし解決可能です	checkIdentities が検出します
A′ · パス／サウンド参照	いいえ	checkReferences、checkSounds — 警告。ゲーム自体は何も通知しません
B · ファイル名 ↔ 識別子	構造上できません	checkFileNames が正しい名前を示します
C · テクスチャ／アセット参照	いいえ	checkAssets がバニラのアトラスと照合します
D · 有効だが意図と異なるもの	構造上できません	checkPatterns が既知のパターンを照合します
E · 読み込まれないマニフェスト	いいえ — 古い型がまだ一覧に残っています	checkManifest が正しい型を示します
F · Molang	いいえ — 文字列の中身は何も調べません	checkMolang。unknown-query はエラーで、ゲーム内で確認済みです
G · コンポーネント名	いいえ — どちらのスキーマソースでもすり抜けます	checkComponents。依然として警告です（下記参照）
H · バージョン依存の必須フィールド	構造上できません — 要件は format_version によって変わります	checkRecipes — エラー。レシピは読み込まれません

F と G はよく読んでください。 ゲームはどちらもまったく同じように拒否し、ブロック定義全体を破棄します。F はエラーに引き上げられましたが、G はそうなっていません。これは、コンポーネントのインデックスに126 個の名前が足りないことが実測されているためです。重大度を決めるのは「ゲーム内でどうなるか」だけでなく、「こちらの一覧がどれほど網羅的か」でもあります。これは別々の問いであり、どちらも測定なしには答えられません。

ツールは検出して報告しますが、書き込みはしません。エンドポイントは読み取り専用で、修正は呼び出し側の役目です。未解決の部分についても記録されています。 docs/VALIDATION-LIMITS.md

Bedrock には5種類の独立したバージョン番号があります

ここで混乱が最も大きな問題になっており、これがこのツールが存在する理由の半分です。

番号	例	使用箇所
マーケティング用番号	26.40	発表のみ。ファイルには一切記載されません
ゲーム／データバージョン	1.26.40.5	data/ フォルダー名、データインデックス
min_engine_version	[1, 26, 40]	manifest.json — 3要素の配列
@minecraft/server モジュールバージョン	2.9.0	manifest.json → dependencies
format_version	1.21.100、1.13.0、2	コンテンツファイル

format_version は独立した軸であり、ゲームバージョンとは関係ありません。 ファイル形式のスキーマバージョンです。ブロックは 1.21.100、フィーチャールールは 1.13.0、スポーンルールは 1.8.0、マニフェストは 2 です。ゲームバージョンが変わっても変化しません。

モジュールバージョンには、また別の落とし穴があります。ゲームバージョンはプレビュー版タグの中に埋め込まれています。

2.9.0                              stable module version (npm "latest")
2.11.0-beta.1.26.50-preview.27     module 2.11.0, game 1.26.50-preview.27

正しい値は思い出すのではなく、スキーマから読み取ります。まさにそのために get_schema と get_version_info があります。

アーキテクチャ

flowchart LR
    C["Claude<br/>you bring the model"] -->|MCP / HTTP| M["packages/mcp<br/>9 read-only tools"]
    M --> V["packages/validator<br/>ajv · tsc · commands · python"]
    V --> K["packages/knowledge<br/>lookup · version resolution"]
    K --> D[("data/<br/>indexes per version")]
    P["pipeline/<br/>daily cron"] -->|produces| D
    U["Mojang · Blockception<br/>npm · MicrosoftDocs"] -->|fetches| P

依存関係の向きは一方向です。mcp → validator → knowledge → data。逆方向にインポートするものはありません。

ビルド手順はありません。 Node が .ts ファイルを直接実行します。tsc は型チェックと、サブプロセスとしての validate_script にのみ使用されます。

データ

data/ はデータベースではありません。Git 内に置かれ、そこでバージョン管理されるインデックスの集合です。8 つのコレクターが、4 つの上流ソースからこれを生成します。

ソース	提供されるもの	ライセンス
Mojang/bedrock-samples	ブロック／アイテム／エンティティの識別子、コマンド文法、テクスチャアトラス	Minecraft EULA — 派生した事実のみ
Blockception/…json-schemas	検証で使用するスキーマ	BSD-3-Clause
npm @minecraft/*	スクリプトの型定義	MIT
MicrosoftDocs/minecraft-creator	リリースノート	CC-BY-4.0

スケジュール設定された GitHub Action がこれを更新し、鮮度チェックがデータの古さを報告します。cron は 05:00 UTC に設定されていますが、その時刻には実行されません。 2026-03-09 に測定した 5 回すべてのスケジュール実行は遅れて開始し、最短でも 4 時間 24 分、平均で約 5 時間遅れました。GitHub はスケジュールされたジョブをキューに入れ、負荷が高いときは開始を遅らせます。そのため、インデックスは最大で 1 日 + 約 5 時間 古くなる可能性があります。

上流の生データがリポジトリに入ることはありません。 インデックス化するのは派生した事実のみです。識別子が存在するか、フィールド名、バージョン番号などです。根拠と測定内容については、docs/SOURCES.md を参照してください。

不変条件

1. 検証レイヤーは LLM を呼び出しません。 このリポジトリのどのパッケージも LLM SDK に依存していません。これは単なる文章ではなく、測定によって確認されています。 packages/mcp/test/no-llm.test.ts
2. エンドポイントは読み取り専用です。 9 つすべてのツールに readOnlyHint が設定されています。
3. data/ は Git にあります。 データベースはありません。
4. 無料枠は制約ではなく、必須条件です。
5. 上流の生データがリポジトリに入ることはありません。

測定結果の記録方法

このリポジトリでは、「動作すること」と「測定されたこと」は別です。 主張は測定してから記載し、測定方法も日付とともにその隣に記します。測定結果が誤りだと判明しても削除せず、取り消し線を引き、その内容がどうなったかを記録します。

コード中の「測定済み（日付）」コメントは、そうした記録です。それぞれ、実際に一度発生した不具合を記録しています。

ドキュメント

以下のドキュメントはトルコ語で書かれており、開発者のノートです。製品のユーザー向け部分は英語です。ツール、サーバーの説明、すべての検出結果とエラーメッセージ、サイトが該当します。

CLAUDE.md	アーキテクチャ、不変条件、バージョンの軸
docs/MCP.md	エンドポイント、セットアップ、ツールの契約
docs/mcp-kullanim.md	実際の使用におけるツール、測定ログ
docs/site-icerik.md	使用方法を紹介するサイトのコンテンツと測定ログ
docs/SOURCES.md	データソースとそのライセンス
docs/VALIDATION-LIMITS.md	検証で検出できないもの
docs/COMMANDS.md	コマンドの検証とその範囲
docs/WEBSOCKET.md	WebSocket ブリッジとその測定内容

ライセンス

コードは Apache-2.0 です。このリポジトリには、3 つの個別のライセンスに基づくサードパーティコンテンツが含まれており、4 つ目のライセンスに基づくデータを生成します。どれがどれに該当するかは、THIRD-PARTY-NOTICES.md に記載されています。

---