コーパスパートナーシップ戦略：大学言語学部との連携による評価コーパスの構築
目的。 本文書は、言語学部とのパートナーシップを通じて機械翻訳評価コーパスを構築するための完全なワークフローを提供します。学部に求める成果物、コーパスの要件、暗号化によるシーリングの方法、サンドボックス評価の仕組み、そして学部が得られるものについて説明します。本文書は、潜在的なアカデミックパートナーとの会議に持参することを想定しています。
対象読者。 活発な言語記録またはNLPプログラムを持つ大学の学部長、主任研究者、研究コーディネーター、および先住民言語プログラムのディレクター。
関連文書：
- 話者バリデーションプロトコル — 既存の翻訳をマークするバイリンガル話者への依頼（品質評価、リンターバリデーション、FSTレビュー）
- ベンチマーク仕様 — コーパス、実行カード、評価プロトコルの完全な技術仕様
- データ主権 — OCAP®、CARE、および所有権移転が重要な理由
最終更新：2026-06-07
1. このパートナーシップが生み出すもの
シールド評価コーパス：機械翻訳品質を測定するためのグラウンドトゥルースとなる、厳選された対訳テキストペア（ソース言語 → ターゲット言語）のセットです。手法はサンドボックス内でこのコーパスに対してテストされ、開発者がテストデータを参照することはありません。
このパートナーシップは3つの成果物を生み出します：
| 成果物 | 内容 | 管理者 |
|---|---|---|
| 開発コーパス | 手法開発用の公開対訳テキストペア（100件以上） | オープン公開（CC BY-NC-SA 4.0 または同等ライセンス） |
| ゴールドスタンダードテストセット | 公式評価用の非公開対訳テキストペア（50〜150件） | コミュニティガバナンス組織（暗号化シーリング済み） |
| 診断テストスイート | 特定の言語現象をテストする対照ペア（10〜50件） | オープン公開 |
開発コーパスにより、誰でも翻訳手法を構築できます。ゴールドスタンダードセットは、それらの手法が正直にテストされることを保証します。診断スイートは特定の失敗パターンを検出します（例：「このシステムはobviationを処理できるか？」）。
2. 学部が行うべきこと
フェーズ1：コーパス設計（2〜4週間、研究者の作業時間）
担当： 対象言語の専門知識を持つPIまたはポスドク。
-
ソース素材のドメインを選定する。 言語コミュニティが実際に翻訳を必要とする4〜6つの実世界ドメインを選択します。本システムのタクソノミーは16のドメインをサポートしています（ベンチマーク仕様 §2.7 参照）：
優先度 ドメイン 理由 🔴 高 edu— 教育教科書、カリキュラム — コミュニティの直接的なニーズ 🔴 高 gov— 行政バンド評議会文書、政策 — 日常的な実務ニーズ 🔴 高 medical— 医療クリニック受付フォーム、健康情報 — 安全上重要 🟡 中 conv— 会話日常会話 — 基本的な流暢さのベースラインを確立 🟡 中 legal— 法律権利文書、条約 — コミュニティにとって重要な意義 🟢 低 literary— 文学・文化物語、口承の歴史 — 文化的保存 -
コーパス設計文書を作成する。 以下を明記します：
- セグメントごとの目標サイズ（development、gold_standard、diagnostic）
- 難易度ティアの分布（以下の §3.3 参照）
- レジスターとドメインのカバレッジ
- ソース文の選定基準（合成テキスト不可、聖書テキストのみ不可）
- 話者リクルートメント計画
-
設計をレビューのために提出する。 コーパススキーマ（ベンチマーク仕様 §2）に対して検証し、1週間以内にフィードバックを返します。
フェーズ2：ソース文の作成（4〜8週間、話者の作業時間）
担当： バイリンガル話者と協力する研究コーディネーター。
-
計画したドメインと難易度ティアにわたってソース文を生成または選定する。 ソースとして使用できるもの：
- 既存の公開バイリンガル資料（教科書、行政文書）
- 特定の言語現象をカバーするために新たに引き出した文
- 実世界の文書から適用したもの（バンド評議会の議題、クリニックフォーム、教育資料）
-
各ソース文には以下が必要です：
- ドメインタグ（16コードのタクソノミーより）
- レジスタータグ（conversational、formal、technical、ceremonial、educational）
- コンテキストタグ（greeting、declaration、question、instruction、narrative、label、error）
- 推定難易度ティア（1〜5、§3.3 参照）
- 出典タグ（textbook、elicited、corpus、gold_standard）
-
各ソース文をターゲット言語に翻訳する。 バイリンガル話者が実施します。1エントリーに複数の参照訳があることは有益ですが、必須ではありません。
-
オプションとして、各参照訳に形態論的分析を追加する：
- インターリニアグロス（形態素ごとの分解）
- FSTタグ文字列（言語のFSTが存在する場合）
- 方言変異、曖昧性、または文化的文脈に関する翻訳者注記
フェーズ3：品質保証（2〜4週間）
担当： 対象言語の専門知識を持つ言語学者。
-
相互レビュー。 各翻訳は、元の翻訳を作成していない少なくとも1名の追加バイリンガル話者によってレビューされる必要があります。レビュアーは以下を確認します：
- 翻訳は正確か？
- 自然な表現か？
- 難易度評価は正しいか？
- 注記すべき許容可能な変異形はあるか？
-
スキーマバリデーターを実行する。 コーパスをエントリースキーマ（ベンチマーク仕様 §2.2）に対して検証するスクリプトを提供します。以下を確認します：
- 必須フィールドの存在
- ドメインコードの有効性
- 難易度ティアが整数1〜5であること
- IDの重複がないこと
- 文字エンコーディング（UTF-8 NFC正規化）
-
言語のFSTが存在する場合、 参照訳をFSTで処理します。参照訳のすべての単語がFST有効である必要があります。FST有効でない単語（借用語、新語、固有名詞）は許可リストに記録します。
フェーズ4：セグメント分割とシーリング（1週間、エンジニアリング作業）
担当： Champollionチーム（学部のレビューを伴う）。
-
層化分割。 決定論的ランダムサンプリング（シードを記録し、再現可能）を使用してコーパスをセグメントに分割します：
セグメント 目標サイズ アクセス developmentエントリーの60%（最低100件） 公開 gold_standardエントリーの30%（最低50件） 非公開、シーリング済み held_outエントリーの10%（最低10件） 非公開、シーリング済み、有効化まで未使用 分割は難易度ティアの分布を保持します（層化サンプリング）。これにより、各セグメントがティア全体にわたって比例的な代表性を持ちます。
-
gold_standardおよびheld_outセグメントの暗号化シーリング：
1. SHA-256 hash of each entry (source + reference + metadata)2. SHA-256 hash of the complete segment file3. Segment file encrypted with AES-256-GCM4. Encryption key split using Shamir Secret Sharing (2-of-3 threshold)5. Key shares distributed to:- Share 1: Community governance organization- Share 2: Academic department partner- Share 3: Champollion project (escrow)6. Hash manifest published to a public commit (proves the corpus existedat a specific time without revealing its contents) -
developmentセグメントは公開リポジトリにコミットされ、完全なライセンスとともに公開されます。
-
diagnosticセグメントも公開されます — 特定の言語現象をテストします（§3.4 参照）。
フェーズ5：統合とローンチ（1〜2週間、エンジニアリング作業）
-
ハーネス設定。 評価ハーネスに言語を追加します：
- 言語カードの作成または確認
- データセットレジストリへのコーパス登録
- LYSSメトリクスの設定（FSTが利用可能な場合はLYSS-fst、リンタールールが存在する場合はLYSS-eq）
- デフォルトスコアリングプロファイルの選択（FSTが利用可能な場合はプロファイルA、それ以外はプロファイルB）
-
ベースラインベンチマーク。 12モデルのスイープをdevelopmentセグメントに対して実行し、リーダーボードに初期スコアを登録します。
-
公開アナウンス。 言語がArenaリーダーボードに表示され、developmentセグメントのライブベンチマークが公開されます。学部はコーパスパートナーとしてクレジットされます。
3. コーパスの要件
3.1 フォーマット
すべてのコーパスファイルは、ベンチマーク仕様 §2.1〜§2.2 のスキーマに従ったJSONドキュメントです：
{
"dataset": {
"id": "crk-ualberta-v1",
"version": "1.0",
"language_pair": "EN→CRK",
"source_language": "en",
"target_language": "crk",
"created": "2026-09-15",
"license": "CC-BY-NC-SA-4.0",
"provenance": ["textbook", "elicited", "gold_standard"]
},
"entries": [
{
"id": 1,
"source": "I see the dog",
"reference": "niwâpamâw atim",
"segment": "development",
"difficulty": 2,
"provenance": "textbook",
"register": "conversational",
"context": "declaration",
"domain": "edu",
"morphological_analysis": "ni-wâpam-âw atim | 1sg-see.TA-3sg.DIR dog.AN",
"notes": "Animate noun (atim); direct form because speaker is proximate"
}
]
}
3.2 最小サイズ要件
| セグメント | 最小エントリー数 | 推奨 |
|---|---|---|
development | 100 | 200〜300 |
gold_standard | 50 | 100〜150 |
diagnostic | 10 | 30〜50 |
held_out | 10 | 20〜30 |
| 合計 | 170 | 350〜530 |
3.3 難易度分布
コーパスはすべての5つの難易度ティアにわたるエントリーを含む必要があり、ティア2〜4に重点を置きます：
| ティア | 説明 | 目標分布 |
|---|---|---|
| 1 — 基本語彙 | 単語、一般的な挨拶、数字 | 10〜15% |
| 2 — 単純な文 | SVO、現在時制 | 25〜30% |
| 3 — 中程度の複雑さ | 過去・未来時制、所有格、生物性 | 30〜35% |
| 4 — 複雑な形態論 | Obviation、受動態、接続法語順、関係節 | 15〜20% |
| 5 — 上級 | 複文、フォーマルレジスター、儀礼的表現、慣用表現 | 5〜10% |
3.4 診断テストスイート
diagnosticセグメントは、対照ペアを使用して特定の言語現象をテストします：正しい翻訳1つと、最小限の差異を持つ誤った翻訳1つです。システムのメトリクスが正しい翻訳をより高くスコアリングすれば、テストは合格です。
多合成語言語の場合、診断スイートは以下を対象とする必要があります：
| 現象 | 例（クリー語） | テスト内容 |
|---|---|---|
| 生物性一致 | atim（生物）vs. maskisin（非生物）— 異なる動詞形 | システムはどの名詞が生物かを認識しているか？ |
| Obviation | 近称 vs. 遠称の三人称 | 三人称の階層を追跡しているか？ |
| 逆形標示 | 直接形 vs. 逆形の動詞形 | 患者が作用者を上回る場合を処理できるか？ |
| 接続法/独立法 | 主節 vs. 従属節の動詞語順 | 正しい動詞パラダイムを使用しているか？ |
| 包括/除外 | 「私たち（あなたを含む）」vs.「私たち（あなたを除く）」 | 一人称複数形を区別しているか？ |
他の語族の場合、有能な翻訳と不十分な翻訳を区別する最も診断的な現象を3〜5つ特定してください。学部の言語学的専門知識がここで不可欠です — これらは専門家だけが書き方を知っているテストです。
3.5 避けるべきもの
| アンチパターン | 理由 |
|---|---|
| 聖書テキストのみ | 古風なレジスター、典礼的語彙、定型的な構造。OMT-1600は1,560言語をこの方法で評価しました — 私たちは意図的にこれを避けます。 |
| 合成評価ペア | LLM生成の参照訳は評価の目的を損ないます。参照訳は人間が作成したものでなければなりません。 |
| 単一レジスターのコーパス | すべてフォーマル、またはすべて会話的。実世界の翻訳は複数のレジスターにまたがります。 |
| 難易度1のみ | 単語と挨拶は翻訳をテストしません — 語彙検索をテストするだけです。 |
| 機械翻訳された参照訳 | Google翻訳の出力を「参照訳」として使用することは循環論法です。 |
| コンテキストタグのない文 | 診断分析のためにコミュニケーション機能を把握する必要があります。 |
4. 暗号化シーリングとサンドボックステスト
4.1 テストセットをシールする理由
従来のML ベンチマークはテストセットをオープンに公開します。一度公開されると、フロンティアLLMは最終的にそれらを（意図的に、またはウェブスクレイピングを通じて）学習データとして使用し、スコアの信頼性が低下します。先住民言語データについては、さらなる懸念があります：公開された言語データはコミュニティの同意なしに使用される可能性があります。
シーリングにより以下が保証されます：
- テストセットの完全性： 手法は一度も参照したことのないデータに過学習できません
- データ主権： コミュニティが自分たちのデータに対する評価を誰が行えるかを管理します
- 永続的な鮮度： テストセットが汚染されることはありません
4.2 サンドボックステストの仕組み
Developer workflow:
1. Developer builds a translation method using the PUBLIC development corpus
2. Developer tests locally against the development segment (unlimited, self-serve)
3. When ready, developer submits their complete method (code + config + coaching data)
4. Governance org installs the method in the evaluation sandbox
5. Sandbox runs the method against the SEALED gold-standard test set
6. Only scores are returned to the developer
7. Developer never sees the source sentences or reference translations
The sandbox:
- Runs on governance-controlled infrastructure
- Has selective network access (LLM APIs only, no exfiltration)
- Produces a tamper-proof run card (SHA-256 hash of all inputs and outputs)
- Logs all execution for audit purposes
- Can be inspected by the governance org at any time
4.3 鍵管理
シールドテストセットの暗号化鍵は、2-of-3閾値のShamir秘密分散を使用して分割されます：
| 鍵保有者 | 役割 | 失効権限 |
|---|---|---|
| コミュニティガバナンス組織 | 主要管理者 | 評価アクセスを単独で失効できる |
| アカデミック学部パートナー | 共同管理者 | 鍵の再構築に参加できる |
| Champollionプロジェクト | エスクロー | 単独ではデータにアクセス不可；他の当事者が利用不能になった場合の継続性を確保 |
3つのうち任意の2つのシェアで鍵を再構築できます。これは以下を意味します：
- コミュニティ + 学部は、Champollionなしでデータにアクセスできます
- コミュニティ + Champollionは、学部なしでデータにアクセスできます
- Champollion単独では、データに絶対にアクセスできません
4.4 ハッシュマニフェスト
コーパスがシールされると、ハッシュマニフェストが公開Gitコミットに公開されます：
{
"corpus_id": "crk-ualberta-v1",
"seal_date": "2026-09-15T00:00:00Z",
"segments": {
"development": {
"entry_count": 200,
"sha256": "a3f7c...",
"access": "public"
},
"gold_standard": {
"entry_count": 100,
"sha256": "b8d2e...",
"access": "sealed",
"key_scheme": "shamir-2-of-3"
},
"held_out": {
"entry_count": 20,
"sha256": "c9e4f...",
"access": "sealed",
"key_scheme": "shamir-2-of-3"
},
"diagnostic": {
"entry_count": 30,
"sha256": "d1a3b...",
"access": "public"
}
},
"total_entries": 350,
"manifest_sha256": "e2b5c..."
}
これにより以下が証明されます：
- コーパスが特定の日付に存在していたこと
- 既知のサイズと構造を持つこと
- シールドセグメントへのいかなる変更もハッシュチェーンを破壊すること
- コミュニティが自分たちのデータが改ざんされていないことを検証できること
5. 学部が得られるもの
5.1 研究インフラ
| 資産 | 説明 |
|---|---|
| 評価ハーネス | 対象言語向けの動作確認済み評価フレームワーク — ツール構築の数ヶ月を節約 |
| LYSSメトリクス | 対象言語向けに設定された言語固有の評価メトリクス（LYSS-fst、LYSS-eq、LYSS-sem）— FSTおよび辞書リソースが存在する場合 |
| リーダーボード | 対象言語ペアの最先端を示す公開ライブリーダーボード |
| ベースラインベンチマーク | 即座に公表可能なベースラインを提供する12モデルスイープ |
| 診断テストスイート | 特定の言語現象に対するターゲットテスト — 他の評価にも再利用可能 |
5.2 論文発表
コーパス構築と評価結果は複数の論文発表を支援します：
| 論文 | 発表先 | 学部の役割 |
|---|---|---|
| コーパス構築方法論 | LREC、ComputEL | 筆頭著者または共著者 |
| ベースライン評価結果 | ACL、EMNLP | 共著者 |
| LYSSメトリクスの検証 | WMT Metrics Shared Task | 共著者 |
| 診断テストスイートの設計 | SIGMORPHON、NAACL | 筆頭著者または共著者 |
| 言語固有のNLPリソース | 言語固有の発表先 | 筆頭著者 |
5.3 グラント申請における優位性
このパートナーシップはグラント申請書に具体的な成果物を提供します：
- 「[言語]MTのオープンソース評価インフラ」— 実証可能な成果物
- 「先住民言語データの暗号化データ主権」— 新規性があり、発表可能
- 「ライブリーダーボードを持つコミュニティ主導のベンチマーク」— 継続的なインパクト指標
- 「[言語]に対するOMT-1600 / Google Translateの独立評価」— タイムリーで注目度が高い
5.4 コミュニティへの影響
- 言語コミュニティは独立した評価能力を獲得します — あらゆるMTシステム（Google、Meta、またはカスタム）が自分たちの言語に対して実際に機能するかどうかを評価できます
- コミュニティは暗号化鍵の管理を通じてテストデータを管理します
- ベンチマークを通じて実証された手法はコミュニティに所有権が移転されます（ベンチマーク仕様 §8.3 参照）
- デプロイされた手法からの収益はコミュニティに還元されます（90/10の分配）
5.5 学部のコスト
| 項目 | 推定コスト | 負担者 |
|---|---|---|
| PI/ポスドクの時間（設計、監督） | 約40時間 | 学部（またはグラント資金） |
| 話者への報酬（翻訳） | $2,500〜$6,000 | グラント資金またはChampollion資金 |
| 話者への報酬（レビュー） | $500〜$1,500 | グラント資金またはChampollion資金 |
| 研究コーディネーターの時間 | 約20時間 | 学部 |
| エンジニアリング、インフラ、ハーネス | $0 | Champollionプロジェクト |
エンジニアリング、ハーネス設定、LYSSメトリクスのセットアップ、リーダーボード統合、および継続的なインフラはすべて学部への費用なしで提供します。学部の貢献は言語学的専門知識と話者へのアクセスです。
6. タイムライン
| フェーズ | 期間 | 主要マイルストーン |
|---|---|---|
| 1：コーパス設計 | 2〜4週間 | 設計文書の承認 |
| 2：ソース文 + 翻訳 | 4〜8週間 | 生コーパスの完成 |
| 3：品質保証 | 2〜4週間 | 相互レビュー、スキーマ検証完了 |
| 4：シーリング | 1週間 | ゴールドスタンダードのシーリング、ハッシュマニフェストの公開 |
| 5：統合 | 1〜2週間 | ベースラインとともにリーダーボードに言語が公開 |
| 合計 | 10〜19週間 | シールド評価を備えたライブリーダーボード |
7. 開始方法
-
お問い合わせ — [プロジェクトのメール/連絡先]。対象言語、利用可能なリソース、パートナーシップの詳細について話し合う30分間の通話をスケジュールします。
-
私たちが提供するもの：
- 本文書
- コーパススキーマとバリデーションツール
- 既存のCree（CRK）コーパスからの例
- コーパス設計テンプレートの草案
-
学部が提供するもの：
- 言語学的作業を主導するPIまたはポスドク
- バイリンガル話者へのアクセス（またはリクルートメント計画）
- 利用可能なリソースに関する情報（FST、辞書、既存コーパス）
- データガバナンスに関する機関の承認（OCAP®準拠または同等）
-
コーパスを共同設計する — ドメイン選定、難易度分布、診断テスト、タイムライン、予算。
-
作業開始。 毎週チェックインします。学部は言語学的決定について完全な自律性を持ちます；エンジニアリングはすべて私たちが担当します。
8. よくある質問
「すでに対訳コーパスがあります。使用できますか？」
はい — コーパスに明確な出典があり、人間が作成したものであり、ライセンスが評価での使用を許可している場合は可能です。スキーマへのフォーマット変換、不足しているメタデータの追加、統合をサポートします。既存のコーパスはタイムラインを大幅に短縮できます（フェーズ2をスキップするか、ギャップ補完作業に縮小できます）。
「言語のFSTがありません。」
問題ありません。LYSS-fst（形態論的有効性）はFSTを必要としますが、ハーネスはプロファイルBの重み（chrF++、BLEU、COMET、行動メトリクス）を使用してFSTなしでも動作します。関連言語のGiellaLT FSTが存在する場合、適用できる可能性があります。そうでない場合でも、コーパスは価値ある評価を可能にします — 形態論的有効性ゲートがないだけです。
「話者がラテン文字以外の文字を使用しています。」
完全にサポートされています。コーパススキーマはあらゆるUnicode文字を処理します。クリー語のSRO（標準ローマ字表記）と音節文字向けに設計しましたが、同じインフラがデーヴァナーガリー、アラビア文字、CJK、エチオピア文字、その他あらゆる書記体系でも動作します。
「方言の変異についてはどうですか？」
タグ付けしてください。コーパスエントリースキーマには方言情報のための notes フィールドがあります。複数の方言が含まれる場合は、それらを記録してください。リンターの等価クラス（LYSS-eq）は方言変異を等価として受け入れるように設定できます。診断テストスイートには方言固有の対照を含めることができます。
「コーパスの所有者は誰ですか？」
ガバナンス組織を通じた言語コミュニティです。学部は研究パートナーとしてクレジットされます。Champollionは運用継続性のためにエスクロー鍵シェアを保持しますが、シールドデータに単独でアクセスすることはできません。developmentセグメントは、コミュニティが指定したCreative Commonsライセンスの下で公開されます。
「中止したい場合はどうなりますか？」
コミュニティはいつでも暗号化鍵の再構築を拒否することで評価アクセスを失効させることができます。シールドデータが公開されることはありません。すでに公開されているdevelopmentセグメントは、そのライセンスの下で公開されたままになります。学部の研究成果（論文、発表）は、いかなる場合でも学部のものとして保持されます。
「ガバナンス組織がまだ存在しない場合はどうなりますか？」
ガバナンス組織なしでフェーズ1〜3（コーパス設計、作成、品質保証）を開始できます。シーリング（フェーズ4）には鍵管理者の特定が必要です。暫定的に、学部がChampollionプロジェクトとともに共同管理者として機能することができます。ただし、コミュニティガバナンス組織が設立された時点で管理権が移転されることを前提とします。
付録：タグ付けとコーパス構築
本文書はコーパス構築 — 評価のグラウンドトゥルースを形成する対訳テキストペアの作成 — を対象としています。タグ付け（形態論的アノテーション、インターリニアグロス、FSTタグ文字列）はコーパスを豊かにする別の作業ですが、基本的な評価には必須ではありません。
| 作業 | 必須？ | 有効にするもの |
|---|---|---|
| コーパス構築（本文書） | ✅ 必須 | 基本評価：chrF++、完全一致、COMET、行動メトリクス |
| FST カバレッジチェック | 🟡 オプション | LYSS-fst 形態論的有効性メトリクス |
| 形態論的アノテーション | 🟡 オプション | morphological_accuracy メトリクス（スコアリング仕様 §2.2） |
| リンター等価ルール | 🟡 オプション | LYSS-eq 等価一致メトリクス |
| セマンティックバリデータールール | 🟡 オプション | LYSS-sem セマンティック検証メトリクス |
| 話者品質評価 | 別作業 | メトリクス検証（話者バリデーションプロトコル参照） |
タグ付けと話者バリデーションは別の文書で説明されており、コーパス構築と並行して、またはその後に進めることができます。