こんにちは！家長です。 今日はAI開発における気をつけたいなと思うことについての話をしようと思っています。
設計書はきちんと残っていたのに、数ヶ月後に「これは今動いているのか」が自分で分からなくなったシステムがありまして、社内でマルチエージェント基盤として設計した 仕組みの顛末と、そこから引き出した「作る順番」の話になります。
何を作ろうとしたか
2026年4月、自分利用向けにマルチエージェントのオーケストレーション基盤を設計しました。構成は次のとおりです。
- cc-spawn — Claude Code のヘッドレスセッションをプログラムから起動する
- tmux — セッションを永続化し、名前付きで並列管理する
- Notion — タスクDB。何を誰にやらせるかのキュー
- Hooks 一式 — セッションのライフサイクル全イベントを捕捉する
- DynamoDB + Slack — PreToolUse で危険操作を止め、Slack ボタンで承認する
タスクを Notion に積むとエージェントが順に起動して処理し、危険な操作にぶつかったら Slack にボタンが飛んできて、押すと処理が再開する。並列で自律的に開発が進む基盤です。
何が起きたか
数ヶ月後、自分で「この機能 ってきちんと今動いているんだっけ」が分からなくなりました。
改めて確認すると、実態は次の状態でした。
- 設計とスクリプトは完成していたが、実運用には載っていない
- 一部（worktree の並列運用、Slack 通知 Hook など）だけを切り出して使っていた
- どこかに置いたまま忘れていた
先に動き出していたのは、営業自動化パイプラインの仕組みです。そちらは「提案を送らないと売上にならない」という痛みが明確だったので、初期開発時点では、設計から実装、運用まで一気に通りました。このオーケストレーション基盤 は痛みが曖昧なまま、設計だけが精緻になっていたのです。
失敗の構造を4つに分解する
一度に全部を作る設計だった
起動・タスク管理・承認・通知・コスト追跡を1つの体系として設計しました。結果として「一部だけ動かす」ができない構造になりました。動かすには全部を立ち上げる必要があり、そのハードルを越える日が来ませんでした。
動かす動機となる痛みが薄かった
「並列で自律開発が回ると効率が上がる」は正しいのですが、明日困ることはない機能になります。一方で「送った提案が誤送信だったら事故になる」は明日起こったらめちゃくちゃ困ります。痛みの緊急度が実装の優先度を決めると考えています。 設計がととのっているかどうかまでは決めてくれません。
稼働の可視化がなかった
動いているかどうかを自分が知る手段がなかったので、動いていないことにも気づけませんでした。ダッシュボードでも Slack 通知でもよいのですが、稼働の証拠が出てこない仕組みは、静かに止まります。
展開コストが高かった
worktree ごとに設定ファイルをコピーする方式で設計していました。worktree を切るたびに手作業が発生するので、忙しい日には設定なしで起動します。それが常態になれば、仕組みは実質存在しません。
全部捨てずに、効用の高い部分だけ移植した
作り直しではなく、部分抽出を選びました。
移植したのは、通知とコスト追跡の Hooks です。しかも worktree ごとではなく ~/.claude/settings.json（ユーザーレベル）に置いて、全セッションに効かせました。Claude Code の設定は hooks のような配列フィールドがレイヤー間でマージされるため、既存のプロジェクト設定を壊さずに敷けます。
承認ゲートは、スクリプトは入れておいて既定で無効にしておきました。誤検知で作業が止まると、仕組みごと外されるから想定外が起こらなくなる状況（のはず）です
結果として、マルチエージェント基盤という体系のうち生き残ったのは1割程度です。ただしその1割は毎日動いています。動いていない9割よりも価値があるかなと自分では考えています
tmux は Warp の代わりではない
蛇足のようで、実は重要だったなと自分的には考えている話です。ターミナルは Warp を使っているので「tmux は要らないのでは」と思っていました。しかしよく考えたら用途が違いますね。
- プロセスの永続化 — ターミナルを閉じてもセッションが生き続ける
- SSH で再アタッチ — 外出先から作業中のセッションに入り直せる
- プログラムからのセッション生成 — cc-spawn のような自動起動はこれがないと成立しない
- 名前付きの並列管理 — セッションに意味のある名前を付けて管理できる
- pane capture — 外部から画面内容を取得して監視できる
対話的に使うなら Warp が快適です。tmux は「自動化されたセッションの器」として必要になります。両方使う、が正解でした。
教訓: 作る順番を逆にする
同じものを作り直すなら、この順番にします。
- 観測 — セッションの開始・終了・ツール使用をログと通知に出す。Hooks だけで完結する
- 通知 — 完了と異常が手元に飛んでくる状態を作る
- 承認 — 危険操作を止める。まずは検知のみ、その次に停止
- 起動の自動化 — ここでようやく tmux とタスクDBを繋ぐ
- オーケストレーション — 複数エージェントの協調はここ
オーケストレーターから作ると、動いているかどうかも分からないまま複雑さだけが増えます。逆に1と2は数時間で入り、その日から効きます。
「エージェント基盤の最初の機能は、自分が稼働を確認できること」がとても重要でした。
オーケストレーターから作ると、動いているかどうかも分からないまま複雑さだけが増えます。逆に1と2は数時間で入り、その日から有効性を確認ができるので、このAI自動化の時代において、とても大事だなと考えています。
