AIエージェントで一人会社を動かす仕組み、全部見せます

ある日、自分が何もしていないのにXに投稿が飛んでいた。

おかしいな、と思って確認したら、Windows のタスクスケジューラが定刻に起動して、X APIを叩いていた。自分が設定したんだけど、本当に動いているとちょっと不思議な感じがした。

この記事では、今このサイトの裏で動いているAIエージェントの仕組みを、全部見せようと思う。

この記事でわかること：

一人会社をどんなAIエージェントで動かしているか
各エージェントがどうつながって動くか
何が完全自動で、何がまだ手動なのか

システムの全体像

まず大きな構造から。自動化の仕組みは大きく3つの場所で動いている。

[GitHub のサーバー]          ← インターネット上で24時間動く
  - manager-agent（毎朝9時）
  - 開発指示の自動実行
  - 記事のクロスポスト

[Vercel のサーバー]          ← サイト本体が動いている場所
  - Telegram からの指示受信
  - チャット機能

[自分のPC]                   ← PCが起動している時だけ動く
  - X投稿の自動実行（月水金）
  - プロジェクトの監視

正直に言うと、今の状態でPCを落とすとX投稿が止まる。 ここはまだ課題で、GitHub Actionsに移行しようとしているところだ。

6体のエージェント

この「一人会社」には6体のエージェントがいる。全員 .claude/agents/ というフォルダで定義されている。

manager-agent（プロジェクトマネージャー）

毎朝9時にGitHubのサーバーで自動起動する、いわば全体の統括役。

やっていること：

tasks/current.md を読んで今日のTODOを確認
X投稿のストックが少なければ marketing-agent に補充を頼む
GitHub Issues に積まれた依頼を確認して、必要なエージェントに投げる
Telegramで日次レポートを送る

最大30ターン（AIとの対話の往復回数）、予算は1回 $0.8 という制限をかけている。

editorial-agent（編集部長）

記事のリサーチから執筆まで担当する。

呼び出し方：Telegramで「記事 [トピック]」と送ると、Webhookが GitHub Issue を作り、manager-agent が翌朝検知して editorial-agent に委任する。

処理の流れ：

ウェブ検索で情報収集
既存記事と重複しないか確認
content/drafts/ に記事を書く
seo-checker と content-reviewer に評価を依頼
フィードバックを反映

marketing-agent（広報部長）

X投稿のストックを生成する。marketing/sns/YYYY-MM.md というファイルに投稿文を追記していく。実際の投稿は別のスクリプト（後述）が行う。

dev-agent（開発部長）

GitHubにIssueを作って instruction というラベルをつけると、GitHub Actionsが自動で起動してコードを実装する。

Issue作成 + label: instruction
    ↓
GitHub Actionsが自動起動
    ↓
dev-agentがコードを書いてコミット
    ↓
Issueにコメントを残してclose
    ↓
Telegram通知

content-reviewer / seo-checker

editorial-agent が記事を書いたあとに呼ばれる評価役。それぞれ読者目線の品質評価とSEO技術検証を担当する。直接指示することはほぼない。

自動化のトリガー

エージェントをどこから呼び出すか、というのが設計の肝になる。今は4つのルートがある。

1. 毎日定刻（GitHub Actions）

.github/workflows/run-manager.yml に以下を書くだけで、GitHubのサーバーが定刻に動かしてくれる。

on:
  schedule:
    - cron: '0 0 * * *'  # UTC 0時 = JST 9時

自分のPCが関係ない。GitHubが代わりにサーバーを起動して、スクリプトを実行して、終わったらサーバーを廃棄する。パブリックリポジトリなら無料。

2. GitHub Issueのラベル（GitHub Actions）

instruction ラベルを付けた瞬間にワークフローが動く。

on:
  issues:
    types: [labeled]

複雑度によって使うモデルとターン数を変えている。

複雑度タグ	ターン数	予算	用途
[complexity: simple]	6ターン	$0.08	テキスト修正・色変更など
（タグなし）	10ターン	$0.15	通常の実装
[complexity: complex]	15ターン	$0.25	大きな機能追加

3. Telegramからの指示

Vercelにデプロイされている /api/telegram-webhook がTelegramからのメッセージを受け取る。

「指示: ボタンの色を青に変えて」
    ↓
Webhookが GitHub Issue を作成
    ↓
GitHub Actions が自動起動
    ↓
実装完了 → Telegram に通知

PCを触らなくてもスマホから開発指示が出せる。理論上は外出先でも動く。

4. Windowsタスクスケジューラ（ローカル）

X投稿（月水金）とプロジェクト監視（毎日9時）はPCのタスクスケジューラで動いている。ここだけPCが必要で、GitHub Actionsへの移行を検討中だ。

実際のフロー：記事を1本書くまで

これらが組み合わさると、記事を公開するまでのフローはこうなる。

Telegram: 「記事 GitHub Actionsの仕組み」
    ↓
Webhook → GitHub Issue 作成
    ↓
manager-agent（翌朝9時）が Issue を検出
    ↓
editorial-agent が起動
  → ウェブ検索
  → 記事執筆
  → seo-checker / content-reviewer が評価
    ↓
content/drafts/ に下書きが生成される
    ↓
自分がレビューして content/blog/ に移動
    ↓
git push → crosspost.yml が自動起動
    ↓
Qiita / Zenn / Medium にクロスポスト

自分がやることは「Telegramに一行送る」「下書きをレビューする」「git push する」の3つだ。

何が自動で、何が手動か

正直に整理するとこうなる。

作業	自動化レベル
X投稿の実行（月水金）	ほぼ自動（PCが必要）
プロジェクト監視・異常検知	ほぼ自動（PCが必要）
開発指示の実行	完全自動（GitHub Actions）
記事のクロスポスト	完全自動（GitHub Actions）
記事の執筆	半自動（Telegramで起動、レビューは手動）
投稿文の生成	半自動（manager-agentが判断して委任）
最終確認・リリース判断	手動

「完全に自動化されている」というより、「自分が介在する回数を減らした」という感じが正確だと思ってます。

現時点の課題

システムを作ってみてわかった問題がいくつかある。

PCへの依存： X投稿と監視が Task Scheduler 依存なので、PCが落ちると止まる。GitHub Actionsに移行すれば解決する。

コスト： エージェントが動くたびにAnthropicのAPIコストが発生する。ある日一日で$5消費したことがあって、設計を見直しているところだ。高いモデル（Sonnet）が必要な処理と、安いモデル（Haiku）で十分な処理を分けると10分の1程度に抑えられる見込み。

状態の分散： 投稿履歴は marketing/sns/、開発タスクは tasks/current.md、記事は content/blog/、というように情報が散っている。エージェントが「今の状況」を正確に把握するためにいくつかのファイルを読む必要があり、ここで認識のズレが起きやすい。

まとめ

このシステムは「一人で全部やる」をやめるための設計だ。

エンジニアリング・記事・X運用を同時に回すためには、自分の代わりに動いてくれる仕組みが必要だった。AIエージェントとGitHub Actionsを組み合わせると、「定刻に自動で動く」「指示を受けて動く」「完了したら報告する」という仕組みが、コードを書かなくても作れる。

課題はまだ残っている。コスト、PCへの依存、状態管理の複雑さ。それでも、Telegramでスマホから指示を出して、翌朝には下書きができている——という体験は、一人でできることの範囲を確実に広げてくれている気がしてます。

完成形はまだ先だけど、この記事を書いている時点でここまでは動いている。