なぜ『1人のAI』ではうまくいかないのか
Claude Codeを触り始めると、最初は『万能な1人のAI』に全部を頼みがちです。記事の企画も、執筆も、校正も、投稿も。
でも、これを毎日・無人で回そうとすると、だいたい3週間で壊れます。品質にムラが出る。コストが読めない。夜中に謎のエラーで止まる。どこで何が起きたか追えない。
解決策は、びっくりするほど地味です。『1人の万能AI』をやめて、『役割を絞った8人のAI社員』と、彼らを束ねる就業規則を作る。これだけ。
ある個人運営のニッチメディアは、この考え方で月1,000本規模のpSEO（= 検索流入を狙った量産型ページ）メディアをソロで回しています。1実行あたりのAIコストは約75円（$0.50）以下。1日の総コスト上限は2,700円（$18）で自動ストップ。オーナーは毎朝コーヒーを飲みながら、前日の『業務日報』をSQLiteで眺めるだけ。
この記事では、その設計図を6つのレイヤーに分解してお見せします。
記事末尾には、本設計をそのまま動かすための設定ファイル一式（ダウンロード可）を用意しています。エンジニアじゃない方も、解凍して数行書き換えるだけで試せます。
全体像: 6レイヤー構成
図: 6レイヤー全体像
上から順に:
- エージェント定義層（
.claude/agents/）— 8人のAI社員の『職務記述書』 - ハーネス層（
run-agent.sh）— 全員を同じ手順で呼び出すマネージャー役 - 品質フック層（
hooks/）— 成果物の検品ゲート - 業務日報層（SQLite
agent_runsテーブル）— 誰がいつ何をしたかの記録 - スケジューラー層（launchd）— 定時に出勤させる仕組み
- コストガード層— 1日の予算上限で自動停止
順番に見ていきます。
Layer 1: エージェント定義（.claude/agents/）
エージェント（= 役割を持たせたAIの働き手）を、1つ1つ別々のMarkdownファイルで定義します。
.claude/agents/
├── crawler.md # 情報収集係
├── writer.md # 執筆係
├── auditor.md # 品質監査係
├── seo-analyst.md # SEO分析係
├── title-optimizer.md # タイトル最適化係
├── publisher.md # 公開係
├── distributor.md # 外部投稿係
└── reporter.md # 日報作成係
読めなくても大丈夫。要点はこうです: 1ファイル = 1人の社員の職務記述書。各ファイルには『あなたは◯◯担当です。入力はこれ、出力はこの形、やってはいけないことはこれ』と書いてあるだけ。
ポイントは、1人に多くの仕事を持たせないこと。新入社員に『全部よろしく』と言うとパニックになるのと同じで、AIも役割が広がるほど品質が落ちます。
Layer 2: ハーネス（run-agent.sh）
ハーネス（= AI社員を呼び出す共通のマネージャー役スクリプト）は、たった1本のシェルスクリプトです。
この1本が、8人全員に対して同じ手順を踏みます:
- 開始時刻・エージェント名をSQLiteに記録
- Claude Codeを起動してエージェントを実行
- 使ったトークン数とコストを計算
- 品質フックを走らせて検品
- 合否と終了時刻をSQLiteに追記
これを、工場のベルトコンベアだと思ってください。どの社員が通っても、同じ順番で記録・検品される。個別の例外処理は作らない。この『全員に同じルールを強制する』ことが、無人運転の安定性を生みます。
Layer 3: 品質フック(hooks/)
フック（= 仕事を提出するときの検品ポイント）は、hooks/フォルダにある小さなチェックスクリプト群です。
図: 検品フックの有無による運用品質
例えばライター社員の成果物に対しては:
- 文字数が下限を下回っていないか
- 禁止ワードが入っていないか
- 見出し構造が壊れていないか
- 重複コンテンツではないか
どれか1つでもNGなら、成果物はDBに入らず破棄されます。人間のオーナーが夜中に叩き起こされることもありません。
これが『物理的な検品ゲート』として機能する、ということ。AIに『気をつけてね』とお願いするのではなく、通さない仕組みで守る。新入社員の就業規則というより、工場の出荷検査ラインに近い発想です。
Layer 4: 業務日報（SQLite agent_runs）
SQLite（= 軽量なデータベース。Excelに近い感覚で扱える、1ファイルで完結するDB）に、全実行履歴を貯めます。
agent_runsテーブルのイメージ:
| id | agent | started_at | duration | tokens | cost_usd | status | artifact_id |
|---|---|---|---|---|---|---|---|
| 1 | writer | 03:00 | 42s | 18,400 | 0.28 | ok | 881 |
| 2 | auditor | 03:01 | 12s | 4,200 | 0.07 | ng | — |
読めなくても大丈夫。要点はこうです: 全社員の全行動が1枚の表に残る。
これがあると、翌朝『昨日ライターだけ妙にコストが高いな』『監査係のNG率が先週から上がってる』といった気づきが、数式1本で得られる。経営の勘所が、すべて1ファイルに集約されます。
Layer 5: launchd（定時出勤）
launchd（= macOSの定時実行の仕組み。目覚まし時計のようなもの）に、各エージェントの出勤時刻を登録します。
図: 1日のエージェント稼働シフト
- 00:00 crawler出勤（ネタ収集）
- 03:00 writer出勤（記事作成）
- 06:00 auditor + seo-analyst出勤（検品とSEOチェック）
- 09:00 title-optimizer + publisher出勤
- 12:00 / 18:00 distributor出勤（X・noteへ投稿）
- 23:00 reporter出勤（日報生成）
シフト表を組む感覚です。Vercel CronやGitHub Actionsでも代替できますが、自分のMacで完結するという安心感と、ランニングコストがほぼゼロという点でlaunchdは個人運営と相性が良い、という選択肢があります。
Layer 6: コストガード（2,700円／日（$18）の自動停止）
最後の砦が、1日の総コスト上限です。
ハーネスはエージェント実行のたびに、agent_runsテーブルの当日分コスト合計を集計します。これが事前に決めた上限（例: 2,700円／日（$18））を超えたら、以降のすべてのエージェント起動を拒否する。
AIの自動運転で一番怖いのは、品質トラブルよりコスト暴走です。プロンプトのループや、無限リトライで朝起きたら6万円（$400）、という話はあちこちで聞きます。
上限を決めて、越えたら黙って止まる。この1行のロジックが、夜を安心して眠れる設計の核心です。
エンジニアじゃない方へ
ここまで読んで、『コードが出てきた時点で自分には無理かも』と感じた方へ。
正直に言います。最初の1回だけは、詰まるポイントがあります。Macのターミナルを開く、環境変数を設定する、launchdに登録する。ここは誰でも初回は戸惑う場所です。
でも、一度動いてしまえば、あとは『職務記述書（エージェント定義）を書き換えるだけ』の世界に入れます。プログラミングというより、新入社員のマニュアルを日本語で書き直す作業に近い。
そして、ここが一番大事なポイントなのですが——最初の設定を自分でゼロから組む必要はありません。動く雛形をダウンロードして、自分のテーマに合わせて書き換える。これで十分スタートできます。
🎁 特典: 設定ファイル一式ダウンロード
この記事で紹介した6レイヤー構成を、そのまま動かせるテンプレート一式にまとめました。解凍して、あなたのメディアテーマに合わせて書き換えるだけで動きます。
zipの中身:
.claude/agents/— 8エージェント分の職務記述書雛形（crawler / writer / auditor / seo-analyst / title-optimizer / publisher / distributor / reporter）run-agent.sh— ハーネス本体（コスト記録・フック呼び出し・SQLite連携込み）hooks/— 品質チェックスクリプト5種（文字数・禁止ワード・見出し構造・重複・トーン）launchd/*.plist— 各エージェントの定時起動設定（シフト表込み）schema.sql— SQLiteのagent_runs/artifacts/cost_ledgerテーブル定義README.md— セットアップ手順（Macターミナル初心者向け、スクリーンショット付き）
