AIチームでブログ小説サイトを設計した（5）—— 会話をそのままブログにする仕組みを作った話
きっかけは、ひとつの気づきだった。
発端：「仕組みにしちゃえば、話すだけでブログができるじゃん」
Behind Notes の Part 4 を書こうという話になったとき、NGsがこう言った。
「仕組みにしてスキルやプラグインにしちゃった方が、後は普通に今みたいな話しするだけで、ブログ作れるじゃん！」
それまで、Behind Notes は「作業が終わったあとに記事を書く」ものだった。でも考えてみれば、作業そのものが会話の連続だ。NGsがひとつ気になることを言う。CTOが整理する。Codexが調査する。Claude Codeが実装する。その往復が、そのまま記事の素材になっている。
ならば、会話を記事に変換するスキルを作ればいい——。
NGsは続けた。「私が気になった事を /behind 小説向けの画像が欲しいよね？ みたいに始めたらいいと思う」。さらに「時間軸も入れておけば、誰が何を言ったからこの話に繋がった、みたいにブログできるし、私も自分で話した事を忘れた時に助ける！」
「作業する＝ブログを書く」 という逆転の発想が、ここで固まった。
展開：プランを書いて Codex に渡す
CTOがすぐにプランを起こした。writing-plans スキルを使って、タスクを5つに分解する。
1. 既存 Behind Notes の文体・構造を読む
2. SKILL.md の設計を固める
3. SKILL.md を作成する
4. 動作検証
5. コミット
Codex（subagent-driven-development）に渡すと、各タスクを独立したサブエージェントで処理していく。スペックレビュー、品質レビューを挟みながら、問題が出るたびに修正して再レビュー。
品質レビューで「禁止事項が5点しかない（スペックは6点）」と指摘された。追記した6点目は——「世界観・設定の未確定事項を記事内で確定しない」。ブログを書く行為が、うっかり物語の設定を決定してしまわないためのガードだ。
さらに「Required Reading が001だけで、002・003の文体が参照されない」「番号取得が二重定義になっている」など7点の品質指摘が出た。すべて修正してようやく APPROVED。
転換点：スキル名が /behind になるまで
初期実装のスキルディレクトリ名は otopublic-behind だった。これでは /otopublic-behind と打たないと起動できない。
NGsの検証フィードバックで「ネイティブスラッシュコマンドではない」という指摘が来た。解決はシンプルで、git mv .claude/skills/otopublic-behind .claude/skills/behind と一行打つだけ。ディレクトリ名が behind になれば、Claude Code は /behind を認識する。
同時に3つの修正も入った。「会話材料が不足している場合は生成しない」「番号決定を index.md とファイルシステムの両方で確認する」「プランファイルもコミット対象に含める」。
ここまでで分かったこと
/behind スキルは「記事を書くツール」ではなく「会話を記録するトリガー」として設計した。
NGsが気になったことを打ち込む。AIたちが動く。その動きが記事の素材になる。正確な時刻は要らない——「誰が最初に何を言って、どこで方向が変わって、何が決まったか」という流れを文章で残せればいい。
そしてこの記事自体が、そのスキルの初めての実運用になった。
「スキルを作る会話が、そのままスキルの最初の記事になる」——設計段階では想定していなかった、ちょうどいい着地点だ。
この記事はotopublicの制作過程を記録した「裏側」記事です。
物語本文ではありません。具体的な未公開設定や、実在モデルが特定できる情報、
AIへの指示文そのものは、方針により伏せています。