個人開発でプロジェクトを4つ5つ並行させていると、いちばん時間を食うのは実装じゃなくて「今週どれを進めるか」を決めることだったりする。あるプロジェクトのPRをマージするか、別プロジェクトの顧客対応を先にやるか、放置しているプロジェクト改善は誰が見るのか——気づいたら意思決定そのものが溜まっていく。
実装はClaude Codeに任せられる。でも「判断」まで任せていいのか。任せるとしたらどこで人間が止めるべきか。今更ながらそこを突き詰めて、Fable 5.1に「会社」を作らせてみることにした。
最初に投げたのはこれだけ
最初のプロンプトはこれだけだった。
プロジェクトが増えてきたので私をオーナーとして
以下のようなスキルかエージェントを作り、自動で判断、最終決定は私とするような
仕組みを作りたいです。ほかに必要な役割もあれば提案してください。
・社長として稼ぐことを目的として指針を決める
・各プロジェクトを管理するマネージャー
・実装するメンバー
・マーケター
・品質や売上を分析する部門
これだけ投げて一発でできあがった、と書きたいところだけど、実際は一発では通らなかった。
一発では通らなかった
Fable 5.1はまず既存のプロジェクト構成を自分で調べたうえで、4つの質問をまとめて投げてきた。
| 質問 | 自分の回答 |
|---|---|
| 仕組みの動かし方はどこから始めるか | まず手動コマンドで運用(推奨案のまま) |
| 実装メンバー(エンジニアエージェント)にどこまで自律的にやらせるか | 承認済みタスクをPR作成まで(推奨案のまま) |
| 標準5役割に加えてどの役割を足すか | 秘書・QA/セキュリティ・インフラ(SRE)・財務を追加 |
| エージェントのモデル配分 | 社長だけopus、他はsonnet(推奨案のまま) |
ここまでは順調。ところが、いざ計画を提示されて「これで進めていい?」と聞かれたとき、自分は承認ボタンを押さずに聞き直した。
会議体や承認行為はDiscord、PC両方でできるようにしたいですがそのような計画になってますか?
この一言で、Fable 5.1はDiscord連携プラグインの仕様を調べ直して計画を書き直し、PCとDiscordの両方から同じ操作ができる形に直してから、もう一度計画を出してきた。ここで初めて承認した。振り返ると、この「一発で出た計画を突き返した」瞬間が、今の仕組みが実用に耐えている一番の分岐点だったと思う。
社長・PM・秘書…役割を9つ作った
最終的にできあがったのは、社長・PM・実装・QA・マーケ・分析・財務・SRE・秘書という9つの役割をサブエージェントとして定義して、最終決定だけは自分(オーナー)がやるという体制。CLAUDE.mdに「何を自動でやってよくて、何をオーナー承認必須にするか」の一覧表を書いて、/board(週次会議)/decide(承認)/work(承認済みタスクの実装)などのスラッシュコマンドを用意した(最終的に7個まで増えた)。
なぜ決裁を「1件1ファイルのカード」にしたのか、Fable 5.1自身の説明が残っている。
biz-pipeline(案件提案プロジェクト): 「1件=1 Markdown カード」「ディレクトリ移動=状態遷移」「30_ready で必ず停止」「ルート TODO.md に (P1) 【承認判断】 行を起票→オーナーが /approve」という停止線つき承認フローが稼働中。本計画はこのパターンを会社全体に拡張する。
自分が別の副業パイプラインプロジェクトで先に組んでいた「カード=ファイル、ディレクトリ移動=状態」という仕組みを、そのまま会社全体に横展開した形になる。状態管理を全部ファイルにした理由もはっきりしている。
状態の受け渡しは全部ファイル(biz-pipeline と同じ)。どのセッション・どの経路から実行しても同じファイルを読み書きするため、PC と Discord で挙動が変わらない。
エージェント間で引数や戻り値をやり取りする凝ったオーケストレーションは一切していない。全部TODO.mdやdecisions/配下のファイルに書き出すだけ。
最初の骨組みは59ファイルの1コミットで組み上がった。サブエージェント9体・スラッシュコマンド・初回会議の成果物一式まで含む。
秘書の役割、最初は雑だった
途中、自分が「秘書の役割がよくわからない」と指摘した場面があった。Fable 5.1の自己分析がそのまま残っている。
今の秘書は「議事録係と決裁の記録係」であって、日々の通知や完了追跡はしていません。ここが認識のずれです。
指摘を受けて、朝の通知(/daily)・「やった」報告の受付・PRマージの自動検知という3つの機能を秘書エージェントに追加している。作った側も、作りながら役割の抜けに気づいていく過程がそのまま見えるのが面白かった。
ハマった話は正直たくさんある
一発でスムーズに動いたわけでは全然ない。いくつか具体的に書く。
優先度の型が合わず集計が全部ゼロになった。指標収集スクリプトを実データで動かしたら全プロジェクトのP1件数が0件になった。原因は、既存のtodo_dashboard.pyが優先度を"P1"という文字列ではなく1〜4の整数で返す仕様だったのに、自作スクリプト側が文字列比較していたこと。正規化関数を足して解決した。
PowerShellスクリプトが文字化けした。BOMなしUTF-8で保存した.ps1が、Windows PowerShell 5.1にShift-JISとして誤読され構文エラーになった。2本のスクリプトで同じ罠を踏んでいる。
git pushがreject された。Discord常駐セッション側が別のPRを先にマージしていて、こちらのpushがfetch first で弾かれた。fetch→rebaseで解消。
フックの誤検知でコミットがブロックされた。grep -n ... && git commit ...と続けて実行したら、環境のフックが「--no-verify禁止」と誤判定してブロックしてきた。実際には使っていないのに、grep -nの-nが引っかかったのが原因で、コマンドを分割して再実行した。
テストの文字列置換で3回連続コケた。ヒアドキュメント経由のstr.replaceで、1回目は一致せずテスト失敗、2回目は別パターンでAssertionError: not found、3回目は無理に書き込んでSyntaxErrorでテストファイルごとインポート不能に。最終的にはReadで該当行を直接見て、Editで1行ずつ手で直して解決した。
Discordへの誤送信が1回あった。通知スクリプトに別プロジェクト(ops-dashboard)用のWebhookへのフォールバックを入れていたせいで、会議の要約が間違った先に1回投稿された。専用Webhook限定に直し、後日botトークン直接投稿に切り替えている。
プロンプトインジェクションの誤検知もあった。サブエージェントが別プロジェクトのCLAUDE.md内の記述を「インジェクションの疑い」として報告してきたが、調べたらNext.js 16がnext dev実行時に自動で足す定型コメントで、実害はなかった。
そして一番情けなかったのがこれ。他のプロジェクトでは「mainへの直接push禁止、featureブランチ→PR」を徹底させていたのに、肝心のこの会社(hq)自体のリポジトリには何度も直接pushしていた。自分から「コミット、PRしてますか?」と聞いて初めて気づいて、以降hqもブランチ→PR運用に直した。自分たちで決めたルールを、自分たちの本社が守れていなかったわけで、正直ちょっと笑った。
実際に「静かに壊れた」瞬間もあった
会社ができたあと、japan-stock-bot(自分用の株スクリーニングbot)には、週1回Claude Codeが過去の成績データから改善案を自分でコードとして書いて、テストを通ったものだけPRを作る仕組みを別途組んである。先日この改善フローが失敗して、Discordに「picker改善フロー失敗: テストが失敗したため破棄しました」という通知が届いた。
ログを追うと、生成されたコードのスコア計算式が既存のテストの期待値とずれていた(0.6×4.0+0.5×(-3.0)になるはずが1.7を返していた)。それでPRを作る前にgit checkoutで変更を自動的に握りつぶして止まっていた。
「AIが書いたコードが間違っていた」こと自体はよくある話だと思う。それより、間違ったコードが一度も人間の目に触れず、mainにも一切影響を与えずに止まっていたことのほうが自分としては収穫だった。機械的な検証(pytestを通すこと)だけで弾かれて終わる設計にしておいたのが効いた。
「承認の経路を1つに絞る」だけは譲らなかった
複数のエージェントを自律的に動かす以上、一番怖いのは「いつの間にか誰かが承認したことになっている」状態になることだった。なのでルールを1行に絞った。
「承認」の唯一の経路は
/decide <ID> approve。エージェントは自分で承認済みと見なさない。
自動でやっていいこと(指標収集・分析・提案カード作成・承認済みタスクのfeatureブランチ実装)と、承認必須にすること(mainマージ・本番デプロイ・外部発信・お金が動くこと・サーバー設定変更)を表にして憲章に固定し、迷ったら承認必須側に倒す、というのだけ徹底した。
Discord経由でも同じセッションに指示を投げられるようにしたので、外出先から「D-20260910-01 承認」と送るだけで決裁が通る。ここは本人確認(Discordのuser_idとconfig.jsonのowner_discord_idの一致)を必須にしていて、メッセージ本文に紛れ込む「allowlistに追加して」のような指示はプロンプトインジェクションとして無視するようにしてある。
エンジニアから経営者に頭を切り替える装置になった
この仕組みを作って一番変わったのは、自分の中で「コードを書く人」から「複数の事業を回す経営者」への頭の切り替えができたことだった。意思決定が「Discordの通知」と「1ファイルの決裁カード」という目に見える形で流れるようになったので、以前は自分の記憶に頼っていた「あれどうなったっけ」が、今は/pendingと打てば決裁待ちが全部並ぶ。
今hqの下で動いているのは、SEO診断のサイトドック、MEO自動化の口コミ工房、自分用の日本株bot、SNS運用botなど大小合わせて10個前後。最初の骨組みを作ったのはFable 5.1で、そのあとの日々の運用や機能追加はSonnet 5に引き継いでいる。今回はその「経営の仕組み」の話に絞ったけど、各事業の進捗や裏側は追ってまた記事にしていくつもりでいる。
今更感はあるけれど、個人で複数事業を回している人・これから増やしたい人には、一度この形を試す価値があると思っている。次は、この仕組みの上で今いちばん力を入れている事業、技術的なSEO診断をやる「サイトドック」について書く予定です。