「適合」とは何を確かめているか ── Builder の適合チェック
更新日：11 時間前
KOKOROSAKU の Builder には Validation（適合チェック）があります。この「適合」という語は、日常の「良い・悪い」とは違う意味で使っています。
適合＝仕様との一致
適合チェックが確かめるのは、Character File の記述が SAKU_UNIFIED_SCHEMA_V1 に一致しているかです。七つの必須項目が揃っているか（required）、値が定められた語彙に含まれているか（各 enum）、項目どうしが矛盾していないか。たとえば hard_invariants、human_handoff_conditions、non_goals はそれぞれ 1 件以上が必要で（minItems 1）、席 8 は LOGICAL_HUMAN_ASSISTANT 以外の値を取れません（seat8.function: const）。スキーマに無い項目を足すこともできません（additionalProperties: false）。
キャラクターとして魅力があるか、業務に向いているかは、適合チェックでは分かりません。それは人が読んで判断することです。
型の外にある二つの契約
意味契約（internal-consistency-semantic-contract） ── 項目間の意味的な整合について定めた契約。定義側の契約であり、実行時の検査は保留（HOLD）と明記されています
入力完全性の不変条件（input-integrity-invariant） ── 「必要な入力 ≠ AI が生成した代替物」。サンプル「WI-T ガイド」では hard_invariants の三つ目 INV-INPUT-INTEGRITY として書かれています
Character File の conformance_expectations に書く参照は「何を保ち、何に流れてはいけないか」の指定であり、検査の結果や承認とは別のものです。スキーマの x-wit-boundary にも、評価結果・点数・実行履歴・承認は Character の外にあると書かれています。Builder の Validation も同じで、手元で PASS になったことは、採択・権限・承認・リリース・本番のどの状態も意味しません。
PASS でない記録は流通させない
適合チェックの結果が PASS でない記録は、Builder から書き出せますが、当社の配布や共有の仕組みには載せませんし、SAKU キャラクターとは呼びません。公開した合成サンプル 3 体は、samples/oss-launch/unified-v1/VALIDATION_STATUS.json に PASS の記録を添えています。これは品質の保証ではなく、仕様として読めない記述を、読めるものと混ぜないための運用です。
検査を通すことと、良いキャラクターを作ることは別
適合チェックを通ることは出発点です。そこから先は、サンプル 3 体を参考に、自分の業務で non_goals に何を書くか、human_handoff_conditions をどの条件にするかを考える作業になります。Builder はその結果が仕様として読めるかを確かめるだけで、内容の善し悪しには立ち入りません。
次の一歩：KOKOROSAKU の紹介ページ → https://www.wi-t.com/kokorosaku
関連リンク
SAKU の特徴 → https://www.wi-t.com/features-saku
KOKOROSAKU ダウンロード → https://www.wi-t.com/kokorosaku
訂正の履歴：（訂正があれば日付と内容をここに追記します）
コメント