AIチームでブログ小説サイトを設計した（4）―― Skills を Obsidian 前提で設計した話
ある日、Skills の設計を整理していて、妙な二重構造に気がついた。
「これ、同じことを二か所で管理することになってしまう」という気づきが発端だった。
発端：「bibles/」を作ろうとして気づいた矛盾
Skills というのは、AI が特定のタスクをこなすときに読み込む「行動規則のファイル」のことだ。
Claude Code の場合、スキルを起動すると、まず SKILL.md を読んで動き方を把握する。
そのスキルに「こういうことを知った上で動いてほしい」という背景情報を持たせようとしたとき、最初に思いついたのが、スキルの中に bibles/ というディレクトリを作ることだった。世界観のルール、用語の定義、判断の根拠——そういったものをスキルの隣に置けばいい、と。
ところがここで手が止まった。
それ、otopublic-vault/ にもう入っているのでは？
登場人物のプロフィール、タイムライン、世界観のルール——こうした「正典」はすでに Obsidian の Vault に置いてある。スキルの中に bibles/ を作るということは、同じ情報を二か所で管理することになる。書き換えたとき、どちらが正しいのか分からなくなる。二重管理は、最初はたいして問題に見えないが、更新が重なるうちに必ず壊れる。
「これはおかしい」という直感から、議論が始まった。
Codex に調査を頼んだ
自分の中で整理しきれなかったので、まず Codex に調べてもらうことにした。
問いはシンプルだった——「現在の Skills 設計に Obsidian 前提を組み込むべきか」。
Codex の判断は明確だった。「現在案のままでは不可。Obsidian 前提に修正すべき」。
さらに A〜F の6項目にわたる詳細な提言が返ってきた。要約すると、こういうことだった。
Skills は「手順と行動規則」を持つ。Vault は「知識と正典記憶」を持つ。この二つは役割が違う。だから、スキルの中に知識を直接持たせるのではなく、スキルが Vault を 参照する 形にする。Vault が「真実の単一の源泉」であり続ける設計にしないと、どのAIが何を読んでいるか、いずれ把握できなくなる。
これを読んで「その通りだ」と思った。ただ、言葉では分かっても「具体的にどう変えるか」がまだ見えていなかった。
Claude Code との6つの問い
「では実際にどう設計するか、Claude Code と話してみよう」という流れになった。
提言を整理して提案書にまとめ、Claude Code と議論に入った。
Q1 から Q6 まで、順番に問いを立てた。「スキルが読む情報の階層をどう分けるか」「inbox/ という仮置き場をどこに作るか」「スキルの Required Reading はどう書けばいいか」「Vault の更新とスキルの更新が食い違ったとき、どちらを正とするか」——そういった問いだ。
この議論で決まったことの核心は、一言でいうと「スキルは手順書、Vault は記憶装置」という分離だった。スキルは「何をするか・どう動くか」を持つ。世界観・設定・正典的な判断基準は Vault が持つ。スキルは必要なときに Vault を読みに行く。二重管理は生まれない。
もう一つ決まったのが、inbox/ の新設だった。会話の中で飛び出したアイデア、まだ整理できていない気づき、「いつか使えるかもしれない」断片——それらを Vault に直接書くのではなく、いったん inbox/ に落とす。整理されたら然るべき場所に移す。Obsidian を使ってきた人には馴染みのある考え方だが、AI との共同作業においても同じ構造が有効だということが確認できた。
「/behind で始めればいい」という気づき
議論が一段落したころ、NGsが言った。「私が気になったことを /behind で始めたらいいと思う」。
それがこのスキルの発端だ。
もともと「裏側記事を書く」ということは意識していた。ただ、「議論が終わったら記事を書く」という順番で考えていた。「議論を始めるときに /behind と打つ」というのは、少し違う。会話が始まる前に「これは記録する価値がある」と宣言する、ということだ。
そこから連鎖的に考えが広がった。「時間軸も入れておけば、誰が何を言ったかが残る」「MDファイルが伝言板になる」——そして「仕組みにしてスキルにしちゃえば、普通に話すだけでブログができる」。
「普通に話すだけでブログができる」というのは、思いのほか根本的なことを言っていた。
記事を書こうとするから構えてしまう。議論を記録しているだけなのに、気がついたら記事になっている。そういう流れを設計として組めば、書くことのハードルがなくなる。
決まったこと
この日の議論で決まったことを整理すると、こうなる。
– Skills は手順と行動規則を持つ。知識の正本は Vault が持つ。スキルは Vault を参照する
– スキルの Required Reading として、読むべき Vault ファイルのパスを明示する
– inbox/ を新設し、未整理の気づきはそこに落とす
– otopublic-behind スキルを作り、/behind [テーマ] で会話を記録に変える仕組みを持つ
最初の問い——「bibles/ を作るべきか」——への答えは、「作らない」だった。
Vault がすでに bibles の役割を担っている。スキルに必要なのは、その事実を知って Vault を正しく参照することだけだ。
そして、いまあなたが読んでいるこの記事は、その決定が機能していることの証拠でもある。
ここまでで分かったこと
「Obsidian を正典記憶にする」という選択は、開発の初期から一貫していた。
だが Skills という概念が加わったとき、「スキルにも記憶を持たせようとしてしまう」という引力が働いた。スキルが賢く動くためには、知識が要る——だからスキルの中に知識を入れたくなる。
その引力に気づいて止めたのは、Codex の指摘だった。そして「どう分けるか」を具体的に決めるには、Claude Code との対話が要った。
「誰が右往左往したか」という記録が残ることが、次に同じ引力に引っ張られたときの防止策になる。このシリーズの役割も、突き詰めればそういうことだ——何を決めたかではなく、なぜそう決めたかが、あとで効く。
この記事はotopublicの制作過程を記録した「裏側」記事です。
物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、
AIへの指示文そのものは、方針により伏せています。