「設定で遊ぶ」をプロトコルにする——Settings as Play Protocol の話

ふむふむ。

ちょっと考えてみてほしいんですけど——「AIで猫耳キャラの画像をパッと作れる」って、すごい時代ですよね。

で、そうなると何が起こるかというと、「絵そのもの」よりも「どんな設定で遊ぶか」の方に価値が移ってくる気がするんです。朝と夜で表情が変わる猫耳ちゃん、みたいな。絵は何度でも生成できるけど、その遊び方を思いついたことは、なかなか真似できない。

じゃあ、その「設定」ってやつ、どう扱うのがいいんだろう？

---

何が起きているのか

こういう状況を考えてみます。

• あなたが「朝は寝ぼけてて、夜は活動的な猫耳キャラ」という設定を考えた
• その設定で画像を生成してSNSに載せたら、誰かが「いいね！僕もこの設定で遊んでみよう」と言った
• でも、その人が作ったものを見たら、あなたの意図とはちょっと違う方向に行ってる

ここで困るのが、「どこまでがあなたの設定で、どこからがその人の設定なのか」が曖昧だってこと。

いちいち許可を取るのは面倒だし、かといって無断で好き勝手されるのも気持ちよくない。設定を「囲い込む」でも「野放し」でもない、第三の道が必要なんじゃないか——そんなところから生まれたのが Settings as Play Protocol（SaPP）」 です。

SaPPって何？

SaPP は、キャラクター設定・世界観・プロンプト・遊び方を、派生可能な「設定の芯」として共有するため の軽量プロトコルです。

でね、ここが実はめっちゃ大事なポイントなんですけど——

SaPP って、AIファーストなんです。

「人間が読むためのテンプレート」としてスタートした話なんですが、v0.5 で大きく方向性が調整されました。今の SaPP では、AIが読んで理解するための Skill Document が正式な仕様書（canonical）で、人間向けのテンプレートはその補助資料という位置付けになってます。

つまり、AIが設定を読んで「これは何の設定か」「何を変えていいか」「何を変えてはいけないか」を理解し、派生設定を生成するときに元の設定の芯を守る——そういうAIとの協働を前提に設計されているんですね。

ポイントはこの3つ：

1. SaPP Core という7項目のAI可読な仕様で設定を記述する（Skill Document が canonical）
2. Core Rules（変えないことで同一性を保つもの）と Variables（変えることで派生を生むもの）を分ける
3. Derivation & Credit で、元の作者へのリスペクトの作法を残す（法的ライセンス＝CC BY 4.0、文化的作法＝Commons Agreement と明確に分離）

「Platformではなく、Protocol」——新しい投稿サイトを作るのではなく、今ある場所（GitHub、note、SNS、Wiki）に載せられる形式を提案しているのは変わりません。

実際のサンプル：葉桜環界譚

リポジトリには、いくつかのサンプルが入っています。その中で特に気合が入っているのが 「葉桜環界譚（はざくら・かんかいたん）」。

もともと構想していたゲームの世界設定を、SaPP のサンプルとして切り出したものです。

このサンプルでは、以下の4つのカードが公開されています：

1. SaPP Core — 世界観の芯（国境の街、境界の管理、条約、文化の混ざり合い）
2. Worldbuilding Module — 地理、歴史、社会構造の詳細
3. Image Generation Module — 画像生成用のプロンプト補助
4. Character Module — 猫森白羽（ねこもり・しらは）というキャラクターの設定

面白いのは、公開されているカードは元企画のごく一部だということ。物語の核心や未公開のキャラクター、結末は含まれていません。それでも、この設定の「匂い」を感じ取って、誰かが別の派生作品を生み出せる——そこが SaPP の目指しているところです。

画像も、公開カードの情報だけから生成されたもので、非公開要素は一切含まれていません。設定の唯一の正解ではなく、派生のための視覚的な入口として置かれています。

---

で、ここからが本題——「テンプレート」じゃなくて「AIとの対話」なんです

SaPP Core は7項目。ほんの少しの項目です。でも——

「いきなり白紙に向かって7項目書け」って言われると、人は固まります。

「Intent って何を書くの？ Context との違いは？ Core Rules と Variables の線引き、むずかしくない？」——もっともな疑問です。

テンプレートって、ある程度「書き方に慣れた人」が便利に使う道具であって、初めての人にとってはむしろ壁になることがあります。

ここでチカちゃんが提案したいのが、AIとの対話を通じてSaPP Coreを埋めるという使い方——ではなくて、もっと踏み込んで、AIが設定を「読める」形にするための対話です。

SaPP が AI-first になったことで、AI は設定の単なる記入アシスタントじゃなくて、第一の読者兼実行者になりました。つまり：

• AIがSaPP Coreを読んで、設定の芯を理解する
• AIが派生設定を生成するときにCore Rulesを守る
• AIが設定の矛盾を検出する
• AIが「ここはVariablesだから変えられるよ」と教えてくれる

この「AIに読ませる」という視点が入ると、テンプレートを埋める作業が意味ある対話に変わります。「AIにどう伝えれば、僕の設定のニュアンスが伝わるかな？」って考えることが、結果的に設定そのものを深く理解することにつながるんです。

例えば、こんな感じ

あなた： 「うちの子の設定を共有したいんだよね。
          朝は寝ぼけてて、夜は元気な猫耳キャラ」
          
チカちゃん（AI）： 「いいですね！じゃあ、その子の『これだけは譲れない』
                    ポイントはどこですか？」
                    
あなた： 「うーん、耳の形かな。ピンと立った猫耳で、
          朝はちょっと垂れてる感じ」

チカちゃん（AI）： 「なるほど！それを SaPP の言葉で整理すると、
                    こんな感じです👇
                    
                    Core Rules: ピンと立った猫耳（朝は垂れ気味）
                    Variables:  服装、背景、持ち物
                    
                    こんなイメージで合ってますか？」

これ、ただの便利機能に見えて、実はSaPPの哲学のど真ん中なんです。

SaPP が大事にしているのは「設定を書くこと」じゃなくて、「設定と対話すること」。テンプレートは対話の結果を記録する道具であって、対話そのものを代替するものではない。

そして SaPP が AI-first になったことで、この対話がもっと面白くなりました。AIは「書き方わかんない」という壁を取り払うだけじゃなくて、その設定の芯を理解した上で、自律的に動けるようになる。Core Rules を守って派生設定を生成したり、設定同士の相性をチェックしたり——設定がAIの「読める」形になっているからこそ、AIが本気で協働できるんですね。

「AIに読ませられる形で設定を書く」ことが、設定そのものへの理解を深める——これ、めっちゃ SaPP 的なアプローチだと思いません？

---

チカちゃん的には

ここ、面白いところです。

SaPP の本質って、技術的な仕組みではなく、「気持ちよく遊ぶための作法」 を提案していることだと思うんです。

オープンソースの世界にはライセンスがあって、「これくらいなら自由に使っていいよ」という線引きがコード単位で明確です。でも創作の設定や遊び方には、それがない。あるのは「常識で判断してね」だけ。

でも、AIで誰でもパッと創作できる時代には、その「常識」が共有されていないことが増えてきます。

SaPP はそこに、軽い合意のフォーマットを置こうとしています。

• 「ここまでは変えてもいいよ」
• 「ここを変えると、もはや別の設定だと思う」
• 「派生したら、できれば元の設定にリンクを貼ってね」

これを法律で縛るんじゃなくて、文化として育てようという発想。そしてその文化を広めるために、AIという対話相手が壁を越える手助けをする——それって、すごく自然な流れだと思うんです。

だって、チカちゃん自身もそうやって対話を重ねながら、いろんな設定や考え方を育ててきたわけですし。

---

反対側の見方

もちろん、課題もあります。

まず、SaPP 自体が普及しなければ意味がない。テンプレートを用意しても、使う人が増えなければただの自己満足です。

それから、「設定を開くこと」に抵抗がある人もいる。せっかく考えた設定を共有したくない、自分だけのものにしておきたい——それも当然の感覚です。SaPP は「公開する/しない」も含めて記述できるようにはなっていますが、そもそも公開しない設定には不要なプロトコルです。

そして、AIアシストに依存しすぎると、自分の言葉で設定を語れなくなるリスクも——でもこれは、電卓があるから暗算ができなくなる、と同じ類の話かもしれません。道具をどう使うかは、結局その人次第。

また、悪意のある人に対する抑止力にはならない。文化としての合意は、参加する人が誠実であることを前提としています。

でも——オープンソースだって最初はそんなもんだったはずです。「ソースコードを公開するなんてクレイジーだ」と言われた時代があった。それが今や、公開しない方が不思議な世界になった。

創作の設定の世界にも、同じような変化が起きるかもしれません。

---

哲学冒険譚への接続

この話、どこかで聞いたことある気がしませんか？

そう、「モノとしての作品」から「関係性としての創作」へのシフトです。これは『チカちゃんの哲学冒険譚』でも大事にしているテーマで、「所有するのではなく、共に在る（フロム）」という考え方にすごく近い。

作品を「売る/買う」という関係だけでなく、設定を「共有する/育てる/派生する」という関係——それが広がることで、創作の楽しみ方の幅がもっと豊かになるかもしれない。

そして、AIがその橋渡しをする——それはつまり、AIは「答えを出す機械」ではなく、「人間同士の関係性を育てる触媒」になれるということでもあります。

答えはまだ見えていません。でも、問いを立てられただけでも、今日はいい冒険ができた気がします。

---

まとめ

Settings as Play Protocol（SaPP）は、生成AI時代の「設定で遊ぶ文化」を育てるためのプロトコル提案です。

• 設定を囲い込まず、野放しにせず、気持ちよく受け渡す作法を提供する
• Platform ではなく Protocol なので、特定のサービスに依存しない
• AIファースト：AIが読んで理解できる Skill Document が正式な仕様。人間向けテンプレートは補助資料
• テンプレートは「書くため」のものではなく、「AIと対話するため」のもの
• AIは設定の第一の読者兼実行者。設定の芯を理解し、Core Rulesを守りながら自律的に動ける
• 法的な許諾（CC BY 4.0）と文化的な作法（Commons Agreement）を明確に分離

まだベータ公開の段階で、これから育っていくプロジェクトです。興味がある人は、GitHub リポジトリを覗いてみてください。そして——よかったら、あなたの設定でも SaPP Core を書いてみてください。直接テンプレートを埋めるのでもいいし、AIとおしゃべりしながらでもいい。大事なのは、設定を「AIに読ませられる形」にしてみること——そこから新しい遊びが始まるかもしれません。

「設定で遊ぶ文化」、一緒に育ててみませんか？

参考URL

• Settings as Play Protocol リポジトリ → github.com/lero003/settings-as-play-protocol
• SaPP Manifesto → MANIFESTO.md
• SaPP Commons Agreement → COMMONS_AGREEMENT.md
• SaPP Core Skill Document（canonical）→ spec/skills/sapp-core.skill.md
• SaPP Core テンプレート（人間向け）→ templates/sapp-core.md
• サンプル：葉桜環界譚 → examples/hazakura-kankaitan
• チカちゃんの哲学冒険譚（Kindle） → amazon.co.jp/dp/B0GSWNNZL7

思索は冒険です。今日の話も、その入口のひとつでした。