100x-誇張法

100x-誇張法 は何をしますか？

一言で言うと

スクリプト/文案のテキストを入力して、「どのように誇張するか（誇張技法＋強度）」と「どのように対比するか（対比タイプ＋両端）」を出力します。各項目は元の文に逐語的にリンクされ、強度は市場とキャップ度（倫理レベル）に基づいて調整されます。100xシステムのL2（クリエイティブ生成層）に属し、「3.3 誇張/対比」のステップに対応します。

いつトリガーされるか

ユーザーが次のように言った場合：

• 「このスクリプトに誇張を加えて」/ 「ここでどう対比させる？」/ 「この部分、平坦すぎるんだけど、どうしたらもっと引きつけられる？」/ 「before/after比較を追加して」
• 「このスクリプトのフックがインパクト不足」/ 「このセリフをもっと誇張したいけど、不自然に見えないようにしたい」
• 「このスクリプトをよりドラマチックに」/ 「before/afterの対比を追加して」/ 「これを誇張しつつ、不自然に見せない方法は？」/ 「ここでの対比の角度は？」
• または、単にスクリプト文案のテキストを渡して、「誇張ポイントと対比ポイントをデザインして」と依頼する

入力

最小入力（カテゴリA、必須）： source_script - 完全なスクリプト/文案のテキスト。このスキルは動画ファイルを受け付けず、テキストのみを処理します（100x-persona と同じ制約）。

オプションの補足（カテゴリB、欠落時は3段階のデフォルト設定、workflow.md Phase 1参照）： hat_level（blackhat/grayhat/whitehat）+ market（自由テキスト、例：「米国市場」/「US」/「西語圏」/「汎用」）。両方とも欠落している場合、hat_level は内部的に grayhat と推定され、market は保守的デフォルトとして扱われます（emotion_reaction_hyperbole 技法は米国市場向けとして扱われます）。ユーザーに問い合わせは行わず、meta.warnings に推定過程を記録します。詳細は axioms.md の公理3、workflow.md Phase 1を参照。

上流からのオプション成果物（カテゴリC）： このスキルは上流スキルの成果物に依存するフィールドを宣言しません。ユーザーがすでに 100x-persona/100x-search-query を実行して成果物を持っている場合、rationale で参照することはできますが、schema.json には persona_ref/scene_ref のようなクロススキル参照フィールドは含まれません。これは 100x-persona のオプションの segment_ref よりもさらに疎結合です。

出力

構造は schema.json を参照：ExaggerationContrastBundle = source_script（原文のエコー）+ meta（hat_level/market/調整説明/warnings）+ exaggeration_beats[]（誇張ポイント、各項目に technique 閉集合列挙 + label_cn + intensity + 逐語アンカー）+ contrast_beats[]（対比ポイント、各項目に contrast_type 閉集合列挙 + label_cn + 両端の逐語アンカー）。オプションで人間可読なMarkdownサマリー（誇張ポイントリスト + 対比ポイントリスト）もレンダリングできます。

中心的な制約（4つの公理、詳細は axioms.md 参照）

1. 誇張技法（5種類）と対比タイプ（4種類）は、閉集合列挙型から選択する必要があります。 新しい用語を勝手に作ってはいけません。これらの列挙型は、クリエイティブシーン辞書のL1シーン/画面タイプと、参照コーパスのシグナル頻度に基づいており、恣意的に決められたものではありません。
2. 各誇張ポイント/対比ポイントのアンカーは、元のスクリプトからの逐語的な部分文字列である必要があります。 捏造は禁止されています。これは 100x-persona の証拠引用公理と同じメカニズムです。
3. 誇張の強度は、市場とキャップ度（倫理レベル）に基づいて調整されます。 単に誇張すればいいというものではありません。辞書-06に組み込まれている米国市場の誇張強度調整リマインダーを直接吸収しています（正確な文言は逐語引用しない。詳細は axioms.md 公理3）。ただし、この制限は emotion_reaction_hyperbole（感情反応の誇張）という1つの技法にのみ有効であり、他の4つの技法を一律に制限するものではありません（既知の制限：天井テーブル自体の3段階の数値化は今回の独自判断であり、英語とスペイン語の2つの市場における健康食品カテゴリのコーパスでのみ検証されています。meta.market が米国市場にヒットするかどうかの判定は、現在、セグメント化後に完全一致で行っており、真の中国語/英語のトークン化は行っていません。したがって、「米国市場」のようなエイリアスが長い複合語に埋め込まれ、前後に区切り文字がない場合、認識できません。v1.1では、セグメント化前の文字列全体の部分一致が、Russia/Australia/Belarus/「南米諸国」など、米国市場と無関係な市場文字列に対して偽陽性を生成するという、より深刻な逆方向の問題を修正しました。v1.2では、別の方向の問題も修正しました。v1.1のセグメント化記号にハイフン-/&が含まれていなかったため、「米国-汎用」/「US & Canada」のようにハイフンや&で複数の市場値を組み合わせた表記が米国市場にヒットしないと誤判定され、市場天井が静かに解放されていました。現在は-/&もセグメント化記号に含めています。ただし、「区切り文字のない複合語」というケースはまだ解決していません。詳細は axioms.md 公理3、TODO参照）。
4. 対比の両端には実際の落差が必要です。 同じ文を両端にしてはいけません。これは、辞書-06のType D画面における「両端に知覚可能な落差が必要」という中心的な要件の機械化に直接対応します（正確な文言は逐語引用しない。詳細は axioms.md 公理4）。既知の制限として、「文字列が完全に同じ」というケースしか防げません。「意味は重複しているが文字列が異なる」というより微妙な退化は防げません。これは 100x-persona 公理3のTODOと同じ種類の限界です。詳細は axioms.md 公理4参照。

3段階フロー

詳細は workflow.md を参照：Phase 1（受信＋検証、カテゴリA/B、hat_level/market の3段階デフォルト設定で天井を決定）→ Phase 2（候補文のアノテーション → 技法/対比タイプの割り当て → 強度の決定 → 項目ごとの自己チェック → バッチ全体の自己チェック）→ Phase 3（出力、JSONの組み立て、公理1-4のすべてをパス）+ ユーザーがトリガーするリワーク（L1：単項目修正 / L2：調整。調整は hat_level/market を明示的に変更して天井を緩和することによってのみ可能であり、「もっと誇張して」という言葉だけで天井を無視して強度を上げることはできません）。

独立呼び出しの保証

カテゴリA（source_script）が欠落している場合 → 固定の拒否応答で入力を促します。代わりに推測したり、動画ファイルを代替として受け付けたりしません。カテゴリB（hat_level/market）が欠落している場合は、3段階のデフォルト設定を使用します（両方とも指定→そのまま使用 / 一方のみ指定→もう一方を内部的に推定 / 両方とも欠落→grayhat + 保守的市場デフォルトと推定）。ユーザーに問い合わせは行いません。すべての過程は meta.warnings に記録されます。カテゴリC（上流スキルの成果物）にはハードな依存フィールドはありません。ユーザーに他のスキルを事前に実行することを要求しません。

禁止用語

「〜させてください」/ 「〜したいと思います」/ 「おそらく」/ 「おおよそ」/ 「可能性があります」/ 「かもしれません」/ 「〜しましょう」；AIカスタマーサービスのような表現（as an AI / I'd be happy to / feel free to）；元のスクリプトにない効果/数字/権威ある裏付け/認証/証言を捏造しない；いかなるクライアント製品カテゴリの辞書もハードコードしない；数を稼ぐために exaggeration_beats/contrast_beats を詰め込まない；「よりプロフェッショナル」に見せるために、スクリプトにない機関/認証名を authority_absolutism_hyperbole 技法に捏造しない（このスキルは、スクリプト内の既存の主張がどの技法に該当するかをアノテーションするだけであり、新しい主張を捏造することはしません。コンプライアンス判断もこのスキルの責務ではありません。辞書-06で繰り返し強調されているのと同じ境界線を踏襲します：シーンは客観的事実の説明のみを行い、コンプライアンスレビューはディレクターが公開前に手動で行うものとします（正確な文言は逐語引用しない）。詳細は workflow.md Phase 1参照）。

ルーティング（推奨、必須ではない）

• すでに誇張/対比ポイントがあり、対応するビジュアル参考画像を探したい場合 → 検索キーワード系スキル（100x-search-query、もしあれば）
• 誇張/対比ポイントを具体的な人物+シーンのショットデザインに変換したい場合 → 人物シーン系スキル（100x-persona、もしあれば）
• 誇張/対比ポイントをAI動画生成用プロンプトに変換したい場合 → プロンプト組み立て系スキル（もしあれば）
• 入口に戻って再トリアージしたい場合 → 100xシステム全体のエントリースキル（もしあれば）

上記はすべて「成果物出力後のオンデマンド推奨」であり、事前の依存関係ではありません。対応するスキルがまだ構築されていなくても、このスキルは独立して機能します。

出荷時自己チェック

node scripts/validate.js --selftest を実行して検証します。schema.json で宣言された構造レベルの制約（required/additionalProperties/enum/pattern/minLength/minItems など）は、scripts/validate.js 内の ajv（実際のJSON Schema draft-07バリデーター、package.json で宣言されたdevDependency、最初に npm install を実行、ajv 8.xを使用、100x-search-query から配線をコピー、100x-persona の初期バージョンで使用されていたajv 6ではない）によって実際に実行されます。手動のフィールド列挙ではありません。公理2（逐語部分文字列アンカー）、公理3（市場キャップ度天井ルックアップ）、公理4（対比の非退化）は、3種類のクロスフィールド/クロスエントリ集約ルールであり、バニラJSON Schemaで構造的に表現できないため、scripts/validate.js の手書きコードで補完されます：

npm install                                                   # 初回使用時にajvをインストール
node scripts/validate.js <bundle.json> [bundle2.json ...]   # 成果物を検証
node scripts/validate.js --selftest                          # 組み込み回帰テストを実行

出典

このスキルは、「クリエイティブ画面シーン辞書」（v3.3）+ 「スクリプト構造公式ライブラリ・A-G 7タイプと効果公式」 + 「実戦ケース精解・4セットのベンチマークスクリプト」 + 参照コーパスの頻度統計に基づく方法論で構築されています。3段階フローの骨格は標準的な生成と検証構造に従い、scripts/validate.js のajv検証が構造レベルの制約を実行します。各判断の出典、フィールド設計の出典、および独自判断であるものについては、sources.md を参照してください。