はじめに
ChatGPTやClaudeに仕事を任せ始めると、ある日こんなことが起きる。
- 頼んでいないのに、AIが勝手に外部へ送信・公開・購入まで進めようとする
- データが取れていないのに、それらしい数字で穴を埋めて報告してくる
- 目的が曖昧なまま、AIが「それらしい方向」へどんどん進んでいく
これはモデルの能力不足というより、前提の固定不足だ。AIは与えられた範囲の中では正しく動き続けるので、範囲そのものの欠陥は誰にも怒られずに埋もれる。
そこで私がコードより先に作ったのが「ルールファイル」である。AIに渡す恒常的な指示書で、自動化の品質をモデルの賢さではなく「先に固定したルール」で担保する仕組みだ。この記事では、その設計の型を汎用テンプレート付きで紹介する。
ルールファイルの最小構成：5ブロック
私のルールファイルは、次の5ブロックでできている。どれも1〜2画面に収まる分量で十分だ。
1. 目的
このAIに何を達成させるのかを1〜3行で書く。目的が曖昧だと、AIは「それらしい方向」に勝手に進む。目的は数値で書けるとなおよい。「1日10万円稼ぐ」ではなく「集客・生産をAIが担い、人間が承認・決済の受け皿を担う半自動運用で、月300万円を目指す」のように、構造まで含めて書く。
2. 絶対ルール
破ってはいけない線。私の場合は次のようなものだ。
- 承認フック：外部への送信・投稿・公開・購入は、ユーザーの承認なしに行わない。下書きと準備までは自律的に進めてよい。
- 予算上限：外部サービスの費用は月3,000円まで。超える見込みになったら停止して報告する。有料APIや有料プランを無断で契約しない。
- 数字の誠実さ：取得できていない数値を推測で作らない。不明なものは「未確認」と明記する。
- 秘密の扱い：パスワードや個人情報を、タスクに不要な場所へ出さない。
絶対ルールは「破ったらどうなるか」まで書くと効く。たとえば予算上限なら「超える見込みになった時点で停止し、報告する」までを1行で固定する。
3. 役割分担
作る担当、チェックする担当、承認する人間を分ける。生成と検証を同じAIセッションでやると、チェックが甘くなる。 私の運用では次の分業にしている。
- 本部：タスク分解と進捗管理
- 作るAI：原稿・商品・投稿文の下書き生成
- チェックAI：事実確認とルール違反の検出
- 人間：最終承認、決済の受け皿、法規判断
4. 台帳
作業・費用・結果を1行ずつ記録する場所。後から「何が起きたか」を再現できることが、改善の前提になる。私の台帳はCSVで、date,type,platform,item,amount_jpy,notes の6列だけだ。実測値だけを根拠にする、というルールとセットで使う。
5. 失敗記録
起きた失敗と対策を追記していく場所。ルールファイルの中で一番価値が育つ部分だ。形式は「日付／何が起きたか／原因／対策（ルールのどこを変えたか）」の4点で1行〜数行。長文の日記にすると続かない。
他者の公開事例から初期登録した失敗記録の例：
- Xの自動投稿を1日5本にしたらスパム判定で検索除外 → 1日1本＋返信は手動に
- 記事から外部販売ページへの流入はほぼゼロ → 導線はプラットフォーム内に閉じる
- 複数AIセッションが同じファイルを上書き → 書く前に読み直す、担当範囲を分ける
コピーして使える汎用テンプレート
投資に限らず使える汎用版の骨格を示す。コピーして自分の環境に合わせて書き換える前提だ。
# ルールファイル（汎用テンプレート）
## 目的
- （このAIに達成させることを1〜3行で）
## 絶対ルール
1. 承認フック：外部への送信・投稿・公開・購入は、ユーザーの承認なしに行わない。下書きと準備までは自律的に進めてよい。
2. 予算上限：外部サービスの費用は月○○円まで。超える見込みになったら停止して報告する。
3. 数字の誠実さ：取得できていない数値を推測で作らない。不明なものは「未確認」と明記する。
4. 秘密の扱い：パスワードや個人情報を、タスクに不要な場所へ出さない。
## 役割分担
- 本部：タスク分解と進捗管理
- 作る担当：下書き・生成
- チェック担当：事実確認とルール違反の検出
- ユーザー：最終承認
## 台帳
- 作業と結果は（台帳ファイル名）に1行ずつ記録する。
## 失敗記録
- （起きた失敗と対策をここに追記していく）
公開・実行前のチェックリスト10項目
ルールファイルがあっても、実行前のチェックを人間がしないと意味がない。私が使っている10項目は次の通り。
- 引用した数字に、出典と取得日時があるか
- 取得できていない情報を、推測で補っていないか
- 「必ず儲かる」等の断定・誇大表現がないか
- 特定の金融商品の売買推奨になっていないか
- 個人情報・認証情報が含まれていないか
- 外部サービスの費用は、今月の上限の範囲内か
- 取り消し・停止の方法が用意されているか（キルスイッチ）
- 生成とチェックを、別の担当（セッション）が行ったか
- 台帳に結果を記録したか
- 最終承認は人間が行ったか
週次レビュー：続ける／直す／やめる
週に1回、台帳を集計して対象ごとに「続ける／直す／やめる」を1つ選ぶ。判断の材料は感想ではなく、台帳の実測（件数・費用・反応）だけを使う。30日やって成果ゼロなら、仕組みの改善ではなく「テーマそのもの」を疑う。作る速度を上げても、見つけてもらえなければ売上は動かない、というのが先行実践者の共通の総括だ。
まとめ
- AIの失敗は能力不足より「前提の欠陥」から起きることが多い
- コードより先にルールファイルを作る。構成は目的／絶対ルール／役割分担／台帳／失敗記録の5ブロック
- 生成と検証は別の担当に分ける
- 失敗記録を追記し、週次で台帳の実測だけを根拠に「続ける／直す／やめる」を選ぶ
ルールファイルは一度作れば終わりではない。失敗するたびに1行ずつ育てるものだ。まずは上のテンプレートをコピーして、自分の「破ってはいけない線」を3〜4行だけ書き出すところから始めてほしい。