Repository navigation
Config Files Reference
対象読者：管理者・上級者 目的：設定画面でユーザーが直接編集できる JSON設定・プロンプト設定の書式（スキーマ）と扱い方 を正確に示す。各設定が「何に効くか」は 上級設定リファレンス、処理の中身は 動作原理 を参照。
| 設定 | 形式 | 設定画面の場所 |
|---|---|---|
| 1. 言語プロファイルJSON | JSON | 上級者向け設定 > モデル設定 > 言語ラベル直下の折りたたみ |
| 2. API Compatibility Profile JSON | JSON | 接続設定 > API互換プロファイル（折りたたみ） |
| 3. Model Profile JSON | JSON | 同上 |
| 4. few-shot（手本例）のJSON | JSON | 上級者向け設定 > プロンプト / few-shot 上書き |
| 5. 追加指示・プロンプト上書き | プレーンテキスト | 同上 |
| 6. テキスト正規化ルールJSON | JSON | 上級者向け設定 > 字幕品質・修復 |
| 7. 共有用設定JSON | JSONファイル | 上級者向け設定 > 設定の共有 |
- いずれも設定画面のテキストエリアで編集し、アプリ内に保存されます。書式を壊したときの挙動は設定ごとに異なるので、各節の「不正なときの挙動」を確認してください（黙って既定値に戻るもの、エラーで止まるもの、スキップして要確認を出すものがある）。
- JSON内で正規表現を書くときは バックスラッシュを二重にエスケープします（例：
\d→"\\d"）。 - 大きく書き換える前に、現在の内容をコピーして退避しておくことを推奨します。検証済みの設定一式は 共有用設定JSON で書き出してチームに配布できます。
設定キー：languageProfileConfigJson
何に効くか：字幕／書きおこし各ロールの言語定義。AIプロンプトの言語名、日本語特化処理の分岐、文の完結・継続判定、スペル校正の対象判定に使われる（→ 言語構成（多言語対応））。
{
"subtitle": {
"label": "English",
"script": "latin",
"sentenceEndPattern": "[.!?]$",
"continuationEndPattern": "[,;:]$",
"fragmentStartPattern": "^[a-z]|^(This|That|It|These|Then|Also|Conversely|Especially|Using|In that case)\\b"
},
"transcript": {
"label": "Japanese",
"script": "japanese",
"sentenceEndPattern": "[。！？!?]$",
"continuationEndPattern": "[、,]$"
}
}上記は既定値そのものです。subtitle＝字幕（翻訳先）、transcript＝書きおこし（翻訳元）。
| フィールド | 必須 | 値 | 意味 |
|---|---|---|---|
label |
任意 | 文字列 | 言語名。設定画面の「字幕言語ラベル」「書き起こし言語ラベル」が入力されている場合はそちらが優先され、このJSONの label は上書きされる |
script |
任意 |
"latin" / "japanese" / "generic"
|
文字体系。japanese で日本語特化プロンプト・処理が有効になり、latin でスペル校正が可能になる。script は「どの言語か」というアイデンティティなので、ラベルが既知言語（English / Japanese 等）に一致する場合はラベルから自動導出され、このJSONの script は無視される（ラベルを切り替えれば script も追従する）。未知ラベルの言語（中国語など）のときだけ、このJSONの script が使われる。不明な値は generic 扱い |
translatedCharPattern |
任意 | 正規表現文字列 | 「この字種が十分に出力されていれば翻訳済み」と見なす文字クラス。未翻訳（ソース言語のまま）判定に使う。未指定なら script 既定（latin＝英字 / japanese＝かな・漢字）。generic な言語をラベル＋JSONだけで足すときの拡張点（中国語の例＝後述） |
sentenceEndPattern |
任意 | 正規表現文字列 | 「文が完結している」末尾の判定 |
continuationEndPattern |
任意 | 正規表現文字列 | 「文が途中で切れている」末尾の判定（未完結文の結合・文脈統合で使用） |
fragmentStartPattern |
任意 | 正規表現文字列 | 「前の文脈に依存する断片的な始まり」の判定 |
-
sentenceEndPattern/continuationEndPattern/fragmentStartPatternは JavaScript 構文・**大文字小文字を区別しない（iフラグ）で評価されます。translatedCharPatternは文字数カウント用にグローバル＋Unicode（guフラグ）**で評価されます。不正な正規表現は単に「マッチしない」扱いになります（エラーにはなりません）。 - 省略したフィールドは、ラベルが既知言語ならその言語の既定値、未知言語なら未設定（パターン無し）になります。
レジストリやコード変更は不要で、字幕言語ラベル＋言語プロファイルJSON だけで追加できます。ラベルが未知言語のときは script と作法をJSONで明示します。
{
"subtitle": {
"label": "中文",
"script": "generic",
"translatedCharPattern": "[\\u4e00-\\u9fff]",
"sentenceEndPattern": "[。！？]$",
"continuationEndPattern": "[、，]$"
},
"transcript": { "label": "English", "script": "latin" }
}-
translatedCharPattern（ここでは CJK 漢字レンジ）が出力に十分含まれていれば「翻訳済み」と判定され、英語のまま残った字幕は未翻訳としてリトライ対象になります。 - 書きおこし（音声認識）側の言語切替は別途必要です（→ 言語構成（多言語対応））。
JSON全体が壊れている場合、黙ってラベル由来の既定値（既知言語ならその言語、未知言語なら generic）にフォールバックします。エラー表示は出ないため、編集後は意図どおり効いているかを実行で確認してください。
📎 コード参照:
frontend/src/lib/pipeline/languageProfileConfig.tsのloadLanguageProfileConfig()・DEFAULT_LANGUAGE_PROFILE_CONFIG。
設定キー：apiCompatibilityProfileJson（プリセット apiCompatibilityProfilePreset を user にしたときだけ使われる）
何に効くか：接続先APIサーバーの「方言」の定義。トークン上限パラメータの名前、JSON出力の指定方法、各エンドポイントのパスなど（→ 動作原理 §8）。
通常は auto か組み込みプリセット（openai / lmstudio / ollama / gemini_openai_compatible）で足ります。User JSON を書くのは、組み込みに無い互換サーバーへ接続するときだけです。
{
"id": "user:api:my-server",
"label": "My OpenAI-compatible Server",
"profileVersion": "2026.06.10",
"requestDialect": {
"chat": {
"endpoint": "/chat/completions",
"tokenLimitParam": "max_tokens",
"responseFormat": "text"
},
"embeddings": { "endpoint": "/embeddings" },
"vision": {
"endpoint": "/chat/completions",
"supportsDataUrl": true,
"supportsRemoteUrl": false
}
}
}| フィールド | 必須 | 値 | 意味 |
|---|---|---|---|
requestDialect.chat.endpoint |
必須 | 文字列 | チャット補完のパス |
requestDialect.chat.tokenLimitParam |
必須 |
"max_tokens" / "max_completion_tokens"
|
出力トークン上限のパラメータ名（OpenAI本家は max_completion_tokens、互換サーバーの多くは max_tokens） |
requestDialect.chat.responseFormat |
必須 |
"json_object" / "json_schema" / "text" / "omit"
|
JSON出力を求める方法。text＝response_format を使わずプロンプトで指示、omit＝パラメータ自体を送らない |
requestDialect.embeddings.endpoint |
必須 | 文字列 | Embeddings のパス |
requestDialect.vision.endpoint / supportsDataUrl / supportsRemoteUrl
|
必須 | 文字列 / 真偽値 | 画像入力のパスと、data URL／リモートURL画像の対応有無 |
id / label / profileVersion
|
任意 | 文字列 | 識別用。省略時は自動補完 |
ゼロから書かず、設定画面の 「組み込みプロファイルをUser JSONへ複製」 で近いプリセットを複製してから差分だけ編集するのが安全です。JSON出力／読み込みボタンでファイルとして共有もできます。
プリセットが user で JSON が不正・必須欠落の場合、LLM呼び出し時にエラーになりパイプラインが失敗します（黙って動き続けることはありません）。
📎 コード参照:
frontend/src/lib/aiGateway/apiCompatibilityProfile.tsのnormalizeApiCompatibilityProfile()・BUILTIN_API_COMPATIBILITY_PROFILES。
設定キー：chatTextProfileJson / chatVisionProfileJson / embeddingProfileJson（能力別）
何に効くか：モデルごとのふるまいの定義。コンテキスト長、最大出力、推論（thinking）の有効化方法と思考出力の分離方法、サンプリング既定値（→ 動作原理 §8）。
ローカルLLM（Gemma・Qwen系など）で「思考タグが字幕本文に混入する」「出力が途中で切れる」類いの不具合が出たときに書きます。OpenAI / Gemini の公式APIでは通常不要です。
能力別JSON → プリセット（gemma / qwen / auto）→ モデル名からの自動推定、の順で最初に解決できたものが使われます。
{
"id": "gemma",
"label": "Gemma thinking-token compatible",
"contextLength": 128000,
"maxOutputTokens": 32768,
"supportsSystemRole": true,
"reasoning": {
"capability": "toggleable",
"enable": { "method": "system_token", "systemToken": "<|think|>" },
"output": { "style": "tag_delimited", "openTag": "<|channel>thought", "closeTag": "<channel|>" }
},
"sampling": {
"thinking": { "temperature": 1.0, "topP": 0.95, "topK": 64 },
"nonThinking": { "temperature": 1.0, "topP": 0.95, "topK": 64 }
}
}| フィールド | 必須 | 値 | 意味 |
|---|---|---|---|
contextLength |
必須 | 数値（1024以上） | モデルのコンテキスト長 |
maxOutputTokens |
必須 | 数値（256以上） | 1リクエストの最大出力 |
supportsSystemRole |
必須 | 真偽値 | system ロールのメッセージを受け付けるか |
reasoning.capability |
必須 |
"none" / "always_on" / "toggleable"
|
推論（thinking）が無い／常時／切替可能 |
reasoning.enable.method |
必須 |
"param" / "chat_template_kwarg" / "system_token" / "none"
|
推論の有効化方法。param＝APIパラメータ、chat_template_kwarg＝enable_thinking 等のテンプレート引数（key / onValue / offValue を併記）、system_token＝システムプロンプト先頭にトークン挿入（systemToken を併記） |
reasoning.output.style |
必須 |
"reasoning_content_field" / "tag_delimited"
|
思考の出力先。reasoning_content_field＝APIが思考を別フィールドで返す、tag_delimited＝本文にタグ混在（openTag / closeTag を併記すると自動除去される） |
sampling.thinking / sampling.nonThinking
|
任意 | オブジェクト | モード別サンプリング既定値（temperature / topP / topK / minP / presencePenalty / repetitionPenalty、すべて数値・任意） |
id / label
|
任意 | 文字列 | 識別用 |
必須フィールドが欠ける・値が選択肢外の場合、そのJSONは黙って無視され、次の解決手段（プリセット／自動推定）に進みます。「書いたのに効かない」ときはまず必須フィールドを疑ってください。
📎 コード参照:
frontend/src/lib/pipeline/modelProfile.tsのnormalizeModelProfile()・MODEL_PROFILE_PRESETS。
何に効くか：翻訳・書きおこし補正のプロンプトに添える「手本のやりとり」。訳調・補正方針をもっとも強く安定させる手段です。
入力セグメントと訳文を同数・同順で並べます（1件以上）。
{
"segments": ["機械学習とは何ですか。", "ディープラーニングについて説明します。"],
"translations": ["What is machine learning?", "I will explain deep learning."]
}-
segments/translationsはどちらも文字列の配列。件数が一致しない・空・文字列以外を含む場合は無効。
補正前テキストと補正後テキストを id で対応付けます。
{
"segments": [
{ "id": 1, "text": "えーっとヤコビ行列とはエヌ次元の変数エックスワンから..." }
],
"corrections": [
{ "id": 1, "text": "ヤコビ行列とは、N次元の変数$x_1$から..." }
]
}- 組み込みの手本（日本語→英語）は、書きおこしが日本語スクリプト以外の言語構成では自動的に使われません。非日英ペアで使う場合は、このJSONに対象言語の手本を与えてください（→ 言語構成）。
- 不正なJSONを入れた場合は黙って組み込みの手本にフォールバックします（日本語構成のとき。それ以外は手本なし）。
📎 コード参照: 翻訳側の検証は
frontend/src/lib/pipeline/translateEn.tsのresolveTranslationFewShot()、補正側はfrontend/src/lib/pipeline/correct.tsのresolveCorrectionFewShotMessages()。既定の手本はprompts.tsのDEFAULT_*_FEW_SHOT_JSON。
JSONではなくただのテキストです。2種類の効き方があり、危険度がまったく違います。
既定のシステムプロンプトの末尾に空行を挟んで追記されます。既定の制約（出力形式・件数一致など）はそのまま生きるので、訳調や方針の微調整はこちらで行ってください。
追加方針:
- 数式・変数名はLaTeX記法で整える（例: X1 -> $x_1$）
- 専門用語は略さない
空欄以外を入れると、字幕の短縮／展開のシステムプロンプトを丸ごと置き換えます。注意点：
- 既定プロンプトに含まれる行長・行数・出力形式などの制約文も消えるため、必要な制約は自分のプロンプトに全部書く必要があります。
-
{maxCharsPerLine}のようなプレースホルダ展開はありません。設定値（1行の最大文字数など）は自動では埋め込まれないので、具体的な数値を直接書きます（設定を変えたらプロンプトも自分で追従させる）。 - 書き出しの参考には既定プロンプトの実装を見るのが確実です。
追加指示・上書きとも、空欄なら既定プロンプトがそのまま使われます。「壊れる」ことはありませんが、上書きの内容が悪いと出力品質・形式が崩れます（形式崩れはコード側の検査が検出し、リトライ／要確認へ回ります）。
📎 コード参照:
frontend/src/lib/pipeline/prompts.tsのbuildCompressSystemPrompt()/buildExpandSystemPrompt()（既定文）とresolveCompressSystemPrompt()/resolveExpandSystemPrompt()（上書き判定）。
設定キー：textNormalizationRulesJson（textNormalizationEnabled がONのとき有効）
何に効くか：自動生成字幕の出力前と SRT 出力時に適用される置換ルール。スマート引用符の統一などの表記ゆれ修正（→ 動作原理 §5.2 / §6）。
{
"version": 1,
"rules": [
{ "enabled": true, "match": "’", "replacement": "'", "matchType": "literal" },
{ "enabled": true, "match": "“", "replacement": "\"", "matchType": "literal" },
{ "enabled": true, "match": "\\bcolour\\b", "replacement": "color", "matchType": "regex" }
]
}| フィールド | 必須 | 値 | 意味 |
|---|---|---|---|
version |
必須 | 1 |
スキーマバージョン（固定） |
rules[].match |
必須 | 文字列 | 置換対象。空文字は不可 |
rules[].matchType |
必須 |
"literal" / "regex"
|
文字列一致か正規表現か。正規表現は g + u フラグで全件置換される |
rules[].replacement |
任意 | 文字列 | 置換後（省略時は空文字＝削除） |
rules[].enabled |
任意 | 真偽値 | 省略時 true。一時的に無効化したいルールに使う |
ルールは配列の順に適用されます。設定画面では編集・プレビュー・インポート／エクスポートができます。
- 設定画面での保存時に検証され、エラー内容（何番目のルールがどう悪いか）が表示されます。
- 不正なままパイプラインが走った場合、正規化だけをスキップして処理は続行し、「要確認」が1件追加されて気づけるようになっています。
📎 コード参照:
frontend/src/lib/pipeline/textNormalization.tsのvalidateTextNormalizationRulesJson()・DEFAULT_TEXT_NORMALIZATION_CONFIG。
設定画面の「設定の共有」から書き出す設定一式の配布用ファイルです。本ページで説明した各JSON・プロンプト設定、モデル選択、品質閾値などをまとめて含み、翻訳者は「共有用JSONを読み込む」で一括適用できます。
- 含まれないもの：APIキー（OpenAI / Gemini）・Service Auth Token・HuggingFace Token・ワークログ保管場所。これらは受け取った各自が入力します。
- OpenAI互換 Base URL は、書き出し時に含めるかどうかを選択できます。
- 運用の推奨：管理者がこのページの設定を整備 → 短い動画で動作確認 → 共有用JSONを書き出して配布、の順。
- 各設定が何に効くか → 上級設定リファレンス
- 言語を変える手順の全体像 → 言語構成（多言語対応）
- 接続先・モデルの抽象化のしくみ → 動作原理 §8