メインコンテンツへスキップ

賞金仕様

目的。 本文書は、MT Eval Arena における賞金プールの構造、閾値条件、請求プロセス、および規則を定義します。「機械翻訳が可能である」とはどのような状態を指すのかを測定可能な形で明確にし、賞金が支払われる条件を規定します。本文書はメトリクスの定義については SCORING_SPEC を、評価プロトコルについては BENCHMARK_SPEC を参照しており、それらの内容を重複して記載することはしません。

ステータス: 有効。創設者賞(§2.1)は資金が確保されており、現在受付中です。

最終更新日: 2026-06-04


1. 基本方針

1.1 賞金はブレークスルーに対して支払われる

賞金は、ある手法が定義された能力閾値を明確に達成した場合にのみ支払われます。参加賞、準優勝賞、慰労金などは一切ありません。誰も基準を超えなければ、誰にも支払われません。これは意図的な設計です。スポンサーは実際に機能する成果に対してのみ支払うことになります。

1.2 コミュニティによる検証は必須

自動メトリクスはあくまで代理指標です(SCORING_SPEC §1.1)。chrF++ および FST 受理率で高いスコアを出しながら、実際の話者には受け入れられない出力を生成する手法も存在します。すべての賞金請求にはコミュニティによる検証が必要です。バイリンガル話者が出力を実用的であると確認しなければなりません。これが人間による検証ゲートです(BENCHMARK_SPEC §7)。

1.3 所有権の移転は取引の一部

賞金を請求した手法は、所有権移転条項の対象となります(BENCHMARK_SPEC §8.3)。開発者は帰属表示権および出版権を保持します。ガバナンス組織は、その言語のために当該手法を使用・改変・配布・商業利用する権利を取得します。これはペナルティではなく、制度の目的そのものです。賞金は、言語コミュニティに帰属する技術の創出に資金を提供します。

1.4 不正対策

賞金の閾値はゴールドスタンダード評価(秘密テストセット、ガバナンス組織がサンドボックス内で実施)に対して定義されています。開発者はテストデータを一切参照できません。これはポリシーによる信頼に依存するものではなく、アーキテクチャ上の強制措置です。BENCHMARK_SPEC §8.2 を参照してください。

1.5 コーパスライセンス:非商用コーパスは賞金レーンから除外

手法の開発中に使用されるコーパスの中には、非商用ライセンスが付与されているものがあります。たとえば、EdTeKLA Cree Language Textbook コーパスは CC BY-NC-SA 4.0 です。これらのコーパスは研究・開発レーン専用です。

  1. 賞金ゴールドスタンダードコーパスには、NC ライセンスのコーパスコンテンツを含めてはなりません。 ゴールドスタンダードのテストセグメントは、コミュニティが委託したオリジナルです(コーパスパートナーシップ戦略を参照)。賞金のために人間が執筆したものであり、評価および商業展開のための権利が最初から確保されています。
  2. 賞金を請求する手法には、NC ライセンスのコーパスコンテンツを含めてはなりません(例:コーチングデータ、埋め込みサンプル、ルックアップテーブルなど)。移転される手法はガバナンス組織による商業展開を目的としており(BENCHMARK_SPEC §8.3、Method Submission Agreement §6)、NC ライセンスのコンテンツが含まれていると、その展開が妨げられます。
  3. 開発者は NC ライセンスのコーパスを開発および自己評価に自由に使用できます。それが開発レーンの目的です。制限が適用されるのは、提出物および展開物に対してであり、開発者の学習プロセスには適用されません。

1.6 依存関係クラスが賞金適格性を決定する

すべての賞金評価はサンドボックス内で行われ(§1.4)、賞金を獲得した手法はガバナンス組織に移転されます(§1.3)。この2つの事実は同じ制約を課します。手法が依存するすべてのものは、開発者がサンドボックスに含める権利を持ち、コミュニティに提供できるものでなければなりません。 すべての提出物は依存関係クラスを宣言します。クラスの定義は Method Interface 仕様 に、適格性の条件は Method Submission Agreement §2.6 に記載されており、適格性はクラスに従って決まります。

依存関係クラス賞金適格性条件
S — 自己完結型✅ 適格§2 の閾値条件以外の条件なし
O — オープン外部(例:提出時にミラーされた AGPL FST)✅ 適格アーティファクトが提出物にピン留めおよびベンダリングされていること。ライセンスがコミュニティへの移転を許可していること。コピーレフト条項が保持されていること(コミュニティはライセンスが全員に付与するのと同じ権利を受け取る)
A1 — 代替可能な LLM 推論⚠️ 条件付きモデルが宣言・ピン留めされており、代替可能であること(コミュニティがホストするオープンウェイトモデルで動作しなければならない)。評価はサンドボックス LLM ゲートウェイ経由でルーティングされること(🔲 計画中 — ゲートウェイが稼働するまで A1 手法はゴールドスタンダードスコアを生成できない)。移転にはモデル自体ではなく、完全なレシピ(プロンプト、コーチング、コード)が含まれること
A2 — 代替不可能な外部データ・サービス API❌ 現時点では不適格権利者がサンドボックスへの組み込みおよび移転の許可を付与するまで不適格。オープンリーダーボードでは「外部依存関係」フラグを表示した上で掲載可能
X — 権利のないバンドルコンテンツ❌ 永久に不適格すべてのレーンで受理不可

手法のクラスは、宣言された依存関係の中で最も制限の厳しいクラスとなります。いずれかのクラスの未宣言の依存関係は失格事由となります(§5)。


2. 現在の賞金プール

2.1 創設者賞 — EN→Plains Cree(nêhiyawêwin)

項目内容
賞金プール10,000 CAD
言語ペア英語 → Plains Cree(EN→CRK)
資金提供者Champollion プロジェクト創設者
ステータス受付中 — 提出を受け付けています
開始ゴールドスタンダードコーパスおよびガバナンス組織が整備された時点
有効期限なし。賞金は請求されるか明示的に撤回されるまで有効です。

閾値条件

手法が創設者賞を請求するには、以下のすべての条件を同時に満たす必要があります。

#条件メトリクス閾値根拠
1複合スコアcomposite(SCORING_SPEC §4)≥ 0.80Deployable(0.70)と Fluent(0.85)の間。形態論的妥当性だけでなく、すべてのメトリクス次元にわたって高い品質が求められます。
2FST 受理率fst_acceptance_rate(SCORING_SPEC §2.2)≥ 0.99(99%以上)出力単語のほぼすべてが、GiellaLT FST によって認識される形態論的に有効な形式でなければなりません。1% の許容範囲は、FST が正当にカバーしない可能性のあるエッジケース(固有名詞、新語、借用語)を考慮したものです。これは多合成語 MT における品質ゲートの核心です。FST が 1% を超える単語を拒否する場合、その手法は言語に存在しない形式を生成しています。この賞の目的は、言語を損なわないシステムを生み出すことです。
3chrF++chrf_plus_plus(SCORING_SPEC §2.1)≥ 55.0文字 n-gram の重複が 0〜100 スケールで 55 を超えなければなりません。形態論的妥当性だけでなく、参照訳との表層的な類似性を確保します。
4コミュニティ検証人間によるレビュー(BENCHMARK_SPEC §7)「acceptable」または「excellent」が 70% 以上出力の層別サンプル(難易度ティア 2〜5 にわたる 30 件以上)を、2 名以上のバイリンガル CRK 話者がレビューします。レビュー対象の 70% 以上が「acceptable」または「excellent」の評価を受けなければなりません。
5ゴールドスタンダード評価サンドボックス実行(BENCHMARK_SPEC §8.2)必須すべての自動メトリクスは、ガバナンス組織がサンドボックス環境で実行した gold_standard コーパスセグメントに対して計算されなければなりません。開発セットのスコアは無効です。
6再現性フィンガープリント照合(BENCHMARK_SPEC §3.8)±2%ガバナンス組織が手法を再実行し、提出されたランカードのスコアの ±2% 以内の結果を達成できなければなりません。

なぜ FST 99% 以上なのか? 多合成語言語における機械翻訳の中心的な問題はハルシネーションです。LLM はターゲット言語のように見えるが形態論的に無効な文字列を生成します。95% の有効な出力を生成する手法でも、5% は作り上げられた単語です。これはいかなる本番利用においても許容できないノイズです。99% 以上の閾値は、FST が認識しない固有名詞や正当な新語といったまれなエッジケースを許容しつつ、ハルシネーションをほぼゼロに抑えることを要求します。99% 以上の FST 受理率を達成できない手法は、問題を解決していません。

なぜ複合スコア 0.80 なのか? これは Deployable(0.70)と Fluent(0.85)の間に位置します。FST 受理率 99% 以上で複合スコア 0.80 の手法は、ほぼすべての単語が実在する Cree の単語であり、かつ表層・構造・意味の各次元にわたって全体的な翻訳品質が高い出力を生成します。コミュニティ検証ゲート(条件 #4)により、これが単なるメトリクスの操作でないことが保証されます。話者が出力を実際に使用できることを確認しなければなりません。

この閾値が実際に意味すること

複合スコア ≥ 0.80、FST ≥ 0.99、chrF++ ≥ 55 の場合、バイリンガル話者は通常次のような出力を目にします。

  • ほぼすべての出力単語が実在する Cree の単語(FST が 99% 以上を検証 — ハルシネーションされた形式はほぼゼロ)
  • 主要な文法カテゴリ(人称、数、時制)がほとんどのエントリで正確
  • 語順が概ね自然
  • 意味が確実に保持されている
  • 残存するエラーは実際の言語上のエラー(誤った活用、不正確な obviation、アニマシーの不一致)であり、作り上げられた単語ではない
  • 流暢な話者が出力を高品質な下書きとして使用し、ゼロから翻訳するよりも大幅に速く修正できる

これは言語を損なわないシステムです。完璧ではないかもしれませんが、生成するすべての単語は実在する単語です。それが多合成語言語の機械翻訳において敬意ある最低基準です。


3. 賞金請求プロセス

3.1 提出

  1. 開発者は完全で実行可能な手法をガバナンス組織に提出します。

    • すべてのソースコード
    • すべての依存関係(コーチングデータ、辞書、FST 設定、プロンプト)
    • インストールおよび実行手順
    • 手法のアプローチを説明する README
    • おおよそのスコアを示す開発セットのランカード(事前スクリーニング用)
  2. 開発者は参加規約に署名します。規約には以下が含まれます。

    • 所有権移転条項(BENCHMARK_SPEC §8.3)
    • 評価データでの学習を行っていない旨の宣言
    • 再現性のコミットメント

3.2 評価

  1. ガバナンス組織は、サンドボックスハーネス内で gold_standard コーパスに対して手法をインストールおよび実行します
  2. 自動メトリクスが計算されます(複合スコア、FST、chrF++ など)
  3. 自動閾値が満たされた場合(条件 1〜3)、ガバナンス組織はコミュニティレビューに進みます
  4. 自動閾値が満たされなかった場合、開発者はスコアとフィードバックを受け取ります。コミュニティレビューは実施されません。

3.3 コミュニティレビュー

  1. 出力の層別サンプル(30 件以上、難易度ティア 2〜5 を網羅)がバイリンガル話者に提示されます
  2. 各エントリを最低 2 名の独立したレビュアーが評価します
  3. 評価スケール:reject / gist / acceptable / excellent
  4. 両レビュアーから 70% 以上のエントリが「acceptable」または「excellent」を受けた場合、コミュニティ検証は合格となります

3.4 支払い

  1. 6 つの条件がすべて満たされます
  2. ガバナンス組織が結果を確認します
  3. 確認から 30 日以内に賞金が支払われます
  4. 手法の所有権が BENCHMARK_SPEC §8.3 に従って移転されます
  5. 結果は「Community Validated」検証ティアとともにリーダーボードに公開されます

3.5 複数回の提出

  • 同一の開発者・チームは複数回提出できます
  • 各提出は独立して評価されます
  • 手法が改善されて再提出された場合、最新のランカードのみが有効です
  • 賞金はすべての閾値を最初にクリアした手法に授与されます。分割はされません。

3.6 チームによる提出

  • チームおよびエルダーと若者のペアも適格です
  • チーム内の賞金配分はチームの責任です
  • すべてのチームメンバーが参加規約に署名しなければなりません
  • リーダーボードの帰属表示にはすべてのチームメンバーが記載されます

4. 今後の賞金プール

創設者賞はその出発点です。追加の賞金プールはスポンサーによって資金提供されます。新しい賞金プールはそれぞれ §2 の新しいサブセクションとして文書化され、以下の項目が含まれます。

  • 賞金額と通貨
  • 言語ペア
  • スポンサーの帰属表示
  • 閾値条件(創設者賞と異なる場合があります)
  • 有効期限(ある場合)
  • 特別条件(ある場合)

4.1 スポンサー賞金テンプレート

スポンサーは任意の金額で賞金プールに資金を提供できます。推奨ティアは以下のとおりです。

ティア金額推奨閾値
Seed$5,000〜$15,000Deployable(複合スコア ≥ 0.70)+ コミュニティ検証
Breakthrough$25,000〜$50,000Fluent(複合スコア ≥ 0.85)+ コミュニティ検証
Grand Prize$100,000 以上Fluent + 複数レジスタのカバレッジ + デプロイメント統合

スポンサーは以下の賞も資金提供できます。

  • 改善バウンティ — 現在の最高スコアから chrF++ が 5 ポイント向上するごとに固定額を支払う
  • レジスター賞 — 特定のレジスター(フォーマル、儀礼的、教育的)に対する個別の賞
  • スピード賞 — コスト調整済みスコアの最高値(SCORING_SPEC §6.3)

4.2 賞金プールのエスクロー

すべての賞金は、閾値条件が満たされるまでエスクロー(プロジェクトまたは指定された受託者が管理)に保管されます。賞金が請求されずに有効期限を迎えた場合、資金はスポンサーに返還されるか、スポンサーの裁量で新しい賞金プールに充当されます。


5. 失格

以下の場合、提出物は失格となります。

  1. 評価データでの学習。 手法が gold_standard または held_out コーパスのエントリにさらされていた場合。(サンドボックス実行によりアーキテクチャ上防止されていますが、汚染の証拠が発見された場合、結果は無効となります。)
  2. 再現不可能。 ガバナンス組織がスコアを ±2% 以内で再現できない場合。
  3. 未宣言または不適格な依存関係。 手法が依存関係マニフェストで宣言した範囲を超えて外部サービスへのランタイムアクセスを必要とする場合、または実質的な依存関係クラスが A2 または X である場合(§1.6)。評価ゲートウェイ経由でルーティングされた宣言済み Class A1 LLM 推論は許可されます。その他のランタイムネットワーク依存関係、およびいずれかのクラスの未宣言の依存関係は失格事由となります。
  4. 参加規約への未署名。 すべてのチームメンバーが所有権移転に同意しなければなりません。
  5. 不正行為の検出。 翻訳品質ではなくメトリクスに最適化された出力(コミュニティレビューおよび/または BENCHMARK_SPEC §9.3 に基づく不正対策チェックにより検出)。

6. 他の仕様との関係

本文書参照先内容
§2 閾値条件SCORING_SPEC §4(複合スコア)、§2.1〜2.2(メトリクス)、§5(ティア)メトリクスの定義とスケール
§2 コミュニティ検証BENCHMARK_SPEC §7人間によるレビュープロトコル
§3 サンドボックス実行BENCHMARK_SPEC §8.2主権メカニズム
§3 所有権移転BENCHMARK_SPEC §8.3IP 移転条件
§1.6 依存関係クラスMethod Interface 仕様; Method Submission Agreement §2.6; BENCHMARK_SPEC §8.6クラス定義、適格性条件、サンドボックスネットワークポリシー
§4 コスト調整済み賞SCORING_SPEC §6.3コスト調整済み計算式

7. コードと仕様の同期

7.1 正規ソース

本文書(arena/website/docs/specifications/prize-spec.md)は以下の正規ソースです。

  • 賞金プールの定義(§2)
  • 閾値条件(§2.x)
  • 請求プロセス(§3)
  • 失格規則(§5)

7.2 実装要件

賞金プールが有効化された場合:

  1. リーダーボード UI は有効な賞金とその閾値条件を表示しなければなりません
  2. 自動閾値を満たすランカード(条件 1〜3)はコミュニティレビューのためにフラグを立てなければなりません
  3. ランカードスキーマの quality_tier フィールドはすでにティア(「deployable」、「fluent」)を記録しています
  4. ハーネスへのコード変更は不要です。賞金仕様は既存のスコアリングの上に重ねるポリシーレイヤーです

賞金の構造は所有権移転条項と整合していなければなりません。受賞者は賞金を請求できますが、手法が Deployable ティアに達した場合、その手法はガバナンス組織の所有物となります。これは意図的な設計です。賞金は言語コミュニティに帰属する技術の創出に資金を提供します。