100x-persona は何をしますか？
一言で言えば
入力されたスクリプト/コピーのプレーンテキストに対して、「誰が話すか」（人物）+「どこで話すか」（シーン、独立したエンティティであり、人物の付属フィールドではない）の両方を出力し、さらにそれらとスクリプトの原文とのバインディングを行います。三者とも原文を文字単位で参照できます。100x 体系の L2 クリエイティブ生成層に属し、「3.1 人物×シーン」のステップに対応します。
いつトリガーされるか
ユーザーが以下のように言った場合：
- 「このスクリプトにキャラクターを設定して」 / 「このスクリプトは誰が話すのが適切か」 / 「このキャラクターはどう決めるか」
- 「このシーンはどう設定するか」 / 「この広告はどんなシーンで撮るのが適切か」 / 「このスクリプトはどこで撮影するのが適切か」
- 「who should deliver this script」 / 「what persona fits this product」
- 「what setting fits this ad」 / 「where should this be filmed」
- または、単にスクリプトのテキストが与えられて、「キャラクターとシーンを割り当てて」 / 「assign a character and setting」 と要求された場合
入力
最小入力（カテゴリ A、必須）： source_script —— 完全なスクリプト/コピーのプレーンテキスト。このスキルは ビデオファイルを受け付けず、テキストのみを扱います。
上流からのオプション出力（カテゴリ C、欠けている場合は静かにスキップ、ブロックせず、ユーザーに他のスキルを先に実行するよう要求することは決してありません）：
100x-segment が生成する segments[]（存在する場合、pairings[].segment_ref に値を戻せます。欠けている場合はフィールド全体を省略し、script_span_quote で独立して位置を特定します）。
出力
schema.json に構造が定義されています：PersonaSceneBundle = source_script（原文エコーバック、証拠確認用）+ personas（人物マップ、独立したエンティティ）+ scenes（シーンマップ、独立したエンティティであり、personas と同階層、人物の文字列フィールドではない）+ pairings（人物×シーン×スクリプト原文のバインディングテーブル）+ meta。オプションで人間が読める Markdown サマリー（人物リスト / シーンリスト / pairing 対照表）を再レンダリングできます。
核となる制約（4つの公理、詳細は axioms.md 参照）
- シーンは独立したエンティティであり、ID で参照される。人物の埋め込みフィールドではない ——
personas/scenesは同階層の二つのマップであり、pairings[]内のpersona_ref/scene_refは対応するマップに実際に存在しなければならない（参照整合性）。 - 人物の権威/オーディエンスの根拠は、原文の逐語的な部分文字列でなければならず、捏造は禁止 ——
authority_evidence_quote/audience_pain_quote/script_span_quoteはすべてsource_script内で文字通り見つけられなければならない。既知の限界（隠れた欠陥ではない）：逐語的な部分文字列は「その文が原文に存在する」ことしか証明できず、「その文が人物フィールド内で意味的に逆方向に使用されていない」ことは証明できない。例えば、自己懷疑的な文（「もし私を信じないなら」）を権威のアンカーとして逆方向に使用することも、有効な部分文字列である。現在のメカニズムには、閉じたセットの自己懷疑フレーズ検出（ヒットした場合は人による開示を要求、axioms.mdの公理2を参照）が含まれているが、皮肉/引用-論駁フレームワークの類の反転はまだ検出できない。これが文字列マッチングの限界であり、詳細はaxioms.mdの公理2「メカニズムの限界と緩和策」の段落を参照。 - シーンは具体的なマイクロ座標まで特定されなければならず、一般的な場所を書いてはならない —— 閉じたセットの汎用語リストで拒否 + 少なくとも2つの具体的な小道具。
- 人物とシーンに孤児はゼロ。作成されたら少なくとも一つの pairing によって参照されなければならない —— 「マトリックスが完全に見えるように」と山積みにしてはいけない。
3フェーズのプロセス
詳細は workflow.md を参照：フェーズ1 人物の逆推論（スクリプト内の Authority/Pain シグナルをスキャンし、証拠文を文字通り抽出）→ フェーズ2 シーンのモデリング（各シーン手がかりに対して独立したエンティティを作成 + 人物/スクリプト原文とのバインディング + 孤児ゼロの自己チェック）→ フェーズ3 出力（JSON をアセンブルし、公理1-4をすべてパス）。
独立呼び出しの保証
カテゴリ A（source_script）が欠けている場合 → 固定的な拒否トークンで入力を促す。代わりに推測したり、ビデオファイルを代替として受け付けたりしない。カテゴリ C（上流の 100x-segment 出力）が欠けている場合 → 静かにスキップし、ユーザーに他のスキルを先に実行するよう要求することは決してない。
禁止語
「してほしい」/「望む」/「かもしれない」/「おそらく」/「可能性がある」/「たぶん」/「しましょう」；AI カスタマーサポート的な言い回し（as an AI / I'd be happy to / feel free to）；スクリプト原文にない資格/認証/証拠/効果データを捏造しない；どの顧客のカテゴリ辞書もハードコードしない；micro_coordinate には閉じたセットの汎用語を使用しない（axioms.md の公理3を参照：「どこか」/「適当な」/「ある場所」/「TBD」/「somewhere」/「anywhere」など）。
ルーティング（推奨、強い依存ではない）
- 既にセグメントに分割されたスクリプトがあり、全体ではなくセグメントごとに人物/シーンを割り当てたい場合 → セグメント化スキル（既に構築されている場合、
segment_refに値を戻せる） - 人物/シーンの説明を AI ビデオ生成プロンプトに変換したい場合 → プロンプトアセンブルスキル（既に構築されている場合）
- 最初に検索キーワードを見つけて参照画像を探してから人物/シーンを決めたい場合 → 検索キーワードスキル（既に構築されている場合）
- エントリーポイントに戻ってトリアージをやり直したい場合 → 100x システムのメインエントリ（既に構築されている場合）
上記はすべて「出力後に必要に応じて推奨」するものであり、事前の依存関係ではありません。対応するスキルがまだ構築されていなくても、このスキルが独立して動作することに影響はありません。
工場出荷時自己テスト
node scripts/validate.js --selftest を実行して検証します。schema.json で宣言された構造レベルの制約（required/additionalProperties/enum/pattern/minItems など）は、scripts/validate.js 内の ajv（実際の JSON Schema draft-07 バリデーター、package.json で宣言された devDependency、最初に npm install してから実行）によって実際に実行され、手書きのフィールド列挙ではありません。公理1（参照整合性）、公理2（証拠部分文字列）、公理4（孤児ゼロ）は、3つのクラスの複数オブジェクト/複数フィールド集約ルールであり、バニラの JSON Schema では構造的に表現できません。これら3つは scripts/validate.js 内の手書きコードによって補われます。さらに、checkAuthorityHedgeRisk（公理2の部分的な緩和、閉じたセットの自己懷疑フレーズにヒットした場合は meta.warnings での開示を要求、そうでなければ FAIL）が含まれています——このチェックは緩和策に過ぎず、完全な修正ではありません。皮肉/引用-論駁フレームワーククラスの証拠文の意味的反転はまだ検出できません。--selftest の第10項目は、この境界を証明するために、正直に「現時点ではパスする」実際の回帰テストケースを残しています。
npm install # 初回使用時に ajv をインストール
node scripts/validate.js <bundle.json> [bundle2.json ...] # 出力を検証
node scripts/validate.js --selftest # 組み込み回帰テストを実行
出典
このスキルは、判断基準スタイルのリファレンスとフィールド構造仕様に基づいて独立して構築されました。個々の判断基準の出典、フィールド設計の出典、設計上の決定については、sources.md を参照してください。