📦 自動投稿の仕組みを「自分専用」から設定1枚で別名義に渡せるパッケージにした話

フランチャイズが同じ品質で何千店舗に広がれるのは、仕組みをパッケージにして渡せるからです。

レシピも仕入れルートも接客マニュアルも、1セットにして届けることで、別の場所に同じお店が立ちます。

あなたは今こうなっていませんか？

・自動化の仕組みを作ったけど、気づいたら「自分専用」になっている・「設定を変えれば渡せる」と思いながら、実際には一度も試していない・何をどの順番で整理すれば「渡せる状態」になるのか、まだわかっていない

先に結論を言います。

外に出せる情報だけを集めた設定ファイルを1枚作り、そこを差し替えるだけで別の名義が動く状態にしました。

これが、パッケージv0.1の正体です。

この記事では、自分専用になっていた自動化を、洗い出し・洗浄・設定ファイル化で渡せる形にした手順と、別名義で動かして見つかった穴を書きます。

全自動3か月で見えた自分専用の壁

XとnoteのAI投稿を全自動で動かし始めてから、3か月が経ちます。

投稿の生成・スコアリング・スケジューリング・文体チェックまで、ほぼ毎日手を動かさない状態が続いています。

最初の1か月は、「本当に動いているのか」と毎日確認していました。

ログファイルを開いて、処理ファイルのタイムスタンプを確認して、ちゃんと動いていると安心してから寝ていました。

2か月目になると、触らなくても投稿が出ていくことに、じわじわと慣れてきました。

3か月目に入ったころ、ふと思いました。「これ、自分しか使えない仕組みだな」と。

コードに埋め込まれた口調と設定

コードの中には、わたし（Lily）の口調・プロフィール・発信ルールが直接埋め込まれています。

わかりやすく言うと「壁に直接ペンキを塗った状態」です。

壁紙だけ剥がして渡すことができない。壁ごと持っていかないと、意味がない構造でした。

友人に頼まれても渡せなかった

ある日、友人から「わたしも同じ仕組みがほしい」と言われました。

そのとき正直、「ちょっと待ってください」と言うしかありませんでした（笑）。

渡したくないわけじゃないんです。ただ、「渡せる状態」になっていなかったんです。

「渡せない仕組み」は、自分の中で完結しているだけで、資産とは言えません。

フランチャイズの本部が「うちだけで動かします」と言ったら、ビジネスにならないのと同じです。

「渡せない状態」を「渡せる資産」に変えるために、何をどの順番でやったか。今日はその話をします。

📕 AIエージェントと自動化の全工程をまとめた総集編


手順・コード・テンプレをそのまま渡しています 🤖【完全版】月商160万円の「寝てても回る仕組み」をゼロから30日で組む全工程｜2026年10月版・Claude Code×AIエージェント・特典40ファイル・毎月更新

洗い出しで見つけた17か所

最初にやったのは「洗い出し」です。

「ここを変えたら別の人として動く」という箇所を、すべてリストアップしました。

1ファイルずつ開いて探すやり方

コードファイルとプロンプトファイルを、1つずつ開いて確認しました。やり方はシンプルです。

ファイルを上から読んで、固有名詞・口調の指定・キャラクター設定が直接書いてある行を探す。

それだけです。

たとえば「Lilyとして投稿する」という一文があれば、それはハードコードされた固有設定です。

「フォロワーへの感謝を込めた、穏やかな口調で」という表現があれば、それも特定のキャラクターへの依存です。

固有名詞や口調を表すキーワードで、全ファイルを一括検索する方法も使いました。

ただし「名前だけ検索しても引っかからない書き方」が残ることもあります。

プロンプトファイルの中で、文脈として埋め込まれているケースがあるからです。

そのため横断検索と、1ファイルずつ目視する作業を組み合わせました。

予想を大きく超えた17か所

この作業だけで約1時間かかりました。出てきた数は、合計17か所でした。

「5か所くらいかな」と思っていたので、正直驚きました。

口調・キャラクター設定・発信テーマ・過去の投稿履歴。

禁止ワード・テンション設定・投稿時間帯・アカウント名。

こういった設定が、バラバラの複数ファイルに散らばっていました。

1か所にまとまっていると思い込んでいたのに、あちこちに散っていました。

汎用のつもりが専用に流れる理由

作っているときは「汎用的に設計している」という感覚があったんです。

でも実際には、無意識に自分専用の設定が増え続けていました。

「汎用と専用の境目は、意識して設計しないと自動的に専用方向に流れる」。

これが洗い出しで得た最初の気づきです。

自分の仕組みに固有のコンテキストが入っていることを、作っている最中には自覚しにくいんです。

「そういうもんだ」と思いながら設計が進んでしまうからです。

さらに言うと、この「染み込み」は仕組みが成熟するほど加速します。

使いながらチューニングするたびに、自分専用の設定が上書きされていくからです。

「渡せる資産にしたいなら、最初から設定ファイルを分離しておく」。これが3か月後の正直な反省です。

洗浄で渡せないものを取り除く

次にやったのが「洗浄」でした。パッケージに入れてはいけないものを取り除く作業です。

洗浄の判断基準はひとつです。「固有の体験・実績・本名が入っているか」。

入っていたら非公開にするか、構造だけ取り出す。入っていなければそのまま渡せます。

勝ちルールは構造だけ渡す

たとえば、実際に使っている「勝ちルール」のプレイブックがあります。

どんな投稿が伸びるか、どんな冒頭が刺さるかをまとめた、いわばわたしの体験データです。

これは有料で販売しているものなので、そのまま渡すわけにはいきません。

お金を払ってくださった方だけが読める情報です。

でも、構造だけは渡せます。

「何の観点で、何の順番で評価するか」という枠組みは、固有の情報が入っていないからです。

具体的に言うと、Lilyが「この型が効く」と知っている理由には体験がセットになっています。

でも「こういう型がある」という事実だけなら、体験抜きで渡せます。

「スープの味は秘密だけど、出汁を取る手順は教えられる」というイメージです。

そう整理したら、洗浄の判断がずいぶん楽になりました。

重みの初期値とフック型の扱い

「重みの初期値」も同じ話でした。

Lilyの文体に最適化した数値が入っているので、そのまま渡しても別キャラクターには合いません。

でも「どの観点に何の重みをかけるか」という考え方の骨組みは渡せます。

テナントが自分のキャラクターに合わせて調整できる形にすれば、問題ありません。

「テナント」という呼び方は、仕組みを整理する途中で自然にできた言葉です。

1つのシステムが複数のキャラクターを動かす場合、それぞれを「テナント」として管理すると頭の整理がしやすいんです。

「フック型」も同じでした。フック型というのは、投稿の冒頭1文に使う型のことです。

具体的な文面は抜いて、「どのカテゴリに何を入れるか」という器だけを残しました。

「問いかけ型」「体験談型」「数字型」という分類だけが残ります。

17か所中6か所を非公開に

「これも渡せない」「これも非公開」と取り除いていくうちに、スカスカになる感覚がありました。

「何も渡せないんじゃないか」と思った瞬間もありました……

でも最終的に、渡せる材料は十分に残りました。

核になるのは「構造」であって、「具体的な文面や数値」ではないと気づいたからです。

洗浄を終えてみると、17か所のうち渡せない・非公開と判断したのは6か所でした。

残り11か所は、構造として切り出すか、そのまま渡せる形になりました。

これが洗浄作業の約2時間で得た最大の気づきです。「構造は渡せる、体験は渡せない」ということです。

設定ファイル1枚にまとめる設計

洗い出した17か所の設定を、1枚の設定ファイルにまとめることにしました。形式はJSONを選びました。

YAMLではなくJSONを選んだ理由

JSONというのは、「名前：値」のペアを並べる形式です。

メモ帳に「好きな食べ物：ラーメン」と書くような感覚で、設定を書き並べられます。

YAMLという形式も候補にありましたが、インデントのズレがエラーになりやすいため採用しませんでした。

非エンジニアがテキストエディタで触ることを想定すると、JSONのほうが安心です。

キャラクター・ルール・スケジュール

設定ファイルの中身は、大きく3つのブロックに分けました。

1つ目が「キャラクターブロック」です。

口調・トーン・語尾の傾向・想定読者・テーマの優先順位などをここに書きます。

2つ目が「ルールブロック」です。

禁止ワード・投稿の最大文字数・ハッシュタグの扱い・返信の判定基準などです。

3つ目が「スケジュールブロック」です。投稿時間帯・更新頻度・スコアリングの閾値などを管理します。

「口調：穏やか」「投稿時間帯：朝7時」「メインテーマ：AIと個人開発」。

こんなふうに書けば、プログラミングを知らない人でも内容が読めます。

この1枚を差し替えるだけで、仕組み全体が別の人格として動く。

それがパッケージv0.1の設計思想でした。

全項目にデフォルト値を書く

設計中に決めたルールがもうひとつあります。「全項目にデフォルト値を書く」ということです。

テナントが設定を書き忘れた項目があっても、仕組みが止まらないようにするためです。

たとえば「投稿テンション」を空欄にしても、デフォルト値の「中程度」が自動的に使われます。

初回セットアップで詰まる場面を減らすためです。「最低限動く状態を保証する」が設計の基本姿勢でした。

作業時間は合計約5時間

作業時間の内訳は、洗い出し約1時間・洗浄約2時間・設定ファイルの設計約1時間・動作確認約1時間です。

合計で約5時間かかりました。

「半日もかからないかな」と思っていたので、正直、想定の3倍でした（笑）。

でも一度やれば終わる作業なので、長く引きずるものではありませんでした。

別名義で動かして見えた穴と手応え

完成から4日後に、v0.1を使って別の名義を動かし始めました。

自分以外のキャラクターとして投稿を出すテストです。

設定入力はキャラの言語化だった

実際に動かす前に、設定ファイルへの入力作業がありました。

口調の説明・メインテーマ・投稿のテンション感・想定読者など、17か所すべてを埋めます。

これ自体に30分ほどかかりました。

「自分のキャラクターを言語化する」という作業は、意外と難しいんです。

「自分の口調はどんな感じか」と問われると、案外答えに詰まります。

設定を書く作業が、そのままキャラクターを言語化する機会にもなりました。

設定ファイルを書き換えて、起動する。理論上は「それだけ」のはずでした。

でも実走してみたら、穴が2か所ありました。起動直後に、想定外の挙動が出たんです。

過去の投稿履歴0件をエラーと誤判定

1か所目は「過去の投稿履歴」の扱いでした。

わたしの仕組みには「過去に書いた記事と重複しない」という判定が走っています。

新しいテナントには、当然ながら過去の履歴が0件です。

なのにシステムが「0件」を「空＝エラー」として扱ってしまいました。

技術的に言うと、履歴を参照する処理が「空のリスト」と「リストそのものが存在しない」を区別していませんでした。

新規テナントでは「リストは存在するけど中身が0件」という状態になります。

これを「リストがない＝未初期化エラー」と誤判定していたんです。

修正は1行の変更でしたが、自分だけのテストでは絶対に気づけなかった穴です。

「初回起動」という特殊な状態を、設計段階で想定し忘れていました。

コードに残った18個目のハードコード

2か所目は文体チェックの重みでした。

Lilyの文体に最適化したパラメータが、コードの中に直書きされたまま残っていました。

設定ファイルに移したと思っていたのに、コードにも同じ値が書き残されていたんです。

しかも変数名が設定ファイルの項目名と微妙に異なっていたため、横断検索をかけたときに引っかかりませんでした。

コードに直書きされた値が、設定ファイルの値を上書きする構造になっていました。

設定ファイルをどれだけ書き換えても、コード側の値が常に勝つ状態です。

これが別キャラクターの文章を「口調が違う」と弾いてしまった原因でした。

洗い出しで見落としていた、18個目のハードコードでした。

「全部洗い出した」と思っていたのに、まだ残っていました……この2か所を塞いで、v0.1はようやく安定稼働に入りました。

2つの名義が同時に動く感覚

v0.1が安定してから数日が経ちました。

別の名義が投稿を出し始め、仕組みが2つのキャラクターを同時に動かしている状態になりました。

最初は違和感がありました。「自分以外のキャラクターが動いている」という不思議な感覚です。

でも3日ほど経つと、それが普通になってきました。

1つの仕組みが2つのアカウントを動かしている様子を見て、「フランチャイズってこういう感覚なのか」と思いました。

構造が共通で、設定だけが異なる。表に出てくる顔だけが違う。

それが「渡せる資産」ということなんだと、動かしてみて初めて実感できました。

共通部分の改善が全名義に届く

もうひとつ気づいたのは、テナントが増えるほど「共通部分の改善がすべてに届く」ということです。

バグを1か所直したら、すべての名義でその修正が効きます。

投稿のロジックを改善したら、すべての名義に反映されます。

「1回の改善が複数の名義に波及する」という構造は、自分専用の仕組みでは得られないメリットです。

作業全体で得た3つの気づき

この作業全体を通じて、気づいたことが3つあります。

専用設定は意識しないと増え続ける

1つ目は「専用設定は、意識しないと増え続ける」ということです。

作っているときは「汎用のつもり」でも、自分の名前・文体・ルールが染み込んでいきます。

作り終えてから「渡そう」と思って初めて、染み込み具合が見えてきます。わたしの場合は17か所でした。

使い込むほど専用化が進むので、渡すつもりがあるなら早い段階から分離しておくべきでした。

構造は渡せる、体験は渡せない

2つ目は「構造は渡せる、体験は渡せない」ということです。

プレイブックの中で実際に機能した文面は、非公開にするしかありませんでした。

でも「なぜそれが機能するのか」という構造は渡せます。洗浄作業の半分は、この分離をする判断でした。

この判断に迷ったときは「自分がいなくても成立するか」という問いに変換すると、速く決められます。

体験談は自分がいないと成立しません。でも構造は、自分がいなくても成立します。

初回テナントが穴を教えてくれる

3つ目は「初回テナントは必ず穴を教えてくれる」ということです。

自分だけでの検証には、必ず死角があります。

別の名義が動いた初日に出た2か所のエラーは、自分では見つけられませんでした。

「渡してみること」が最良のテストです。

完璧に整ってから渡そうとすると、発見が遅れます。

「v0.1」というバージョン番号をつけたのは、「完璧でなくていい、まず渡す」という気持ちを自分に許可するためでもありました。

仕組みの詳細は、有料記事の「Claude Code自律環境の仕組み」にまとめています。 設定ファイルの全項目・洗浄の判断基準・重みの初期値の考え方まで書きました。

気になる方は、フッターのリンクから覗いてみてください。

あなたの仕組みを渡せる形にするには

難しい技術は必要ありません。

まず固有設定の場所を洗い出す

まず「ここに自分の名前・設定・ルールが直接書いてある場所はどこか」を探すだけです。

それをリストにする。それだけで、作業の全体像が見えてきます。

体験と構造に分けて判断する

洗い出しさえできれば、あとは「渡せるもの」と「渡せないもの」に分けるだけです。

判断基準はシンプルで「固有の体験・数値・名前が入っているか」です。

入っていたら、構造だけ取り出す。入っていなければ、そのまま渡せます。

この判断を繰り返すだけで、設定ファイルの中身が少しずつ埋まっていきます。特別な技術知識は不要です。

「自分の仕組みに何が入っているか」を読んで分類する作業は、誰にでもできます。

完璧を待たずv0.1で渡す

一点だけ注意があります。「完璧に整ってから渡す」を目標にすると、永遠に渡せません。

穴は渡してみて初めて見つかります。「v0.1」と名付けて渡すくらいがちょうどいいです。

資産と依存の違いと次の一歩

わたしはこの整理をするまで「自動化の仕組みを持っている」と思っていました。

でも本当は「自分しか動かせないプログラムを持っている」だけでした。

この2つはまったく違います。前者は資産で、後者は自分への依存です。

次はv0.2で設定をUI化する

次にやりたいのは「設定ファイルのUI化」です。

JSONを直接触るのは、非エンジニアにはまだハードルが高い状態です。

設定項目を対話形式で埋められる画面があれば、もっと広く渡せます。これがv0.2の目標です。

渡せて初めて完成と言える

「渡せる状態にして初めて、本当の意味で完成と言える」そう思いながら、次のバージョンに向けて少しずつ動いています。

📕 この記事の内容を、実装まで全部まとめた有料記事があります 手順・コード・テンプレをそのまま渡しています AIで「寝てても回る仕組み」をゼロから30日で組む全手順