メール返信AIを作った。 書類レビューAIを作った。 SNS投稿AIを作った。
便利だった。1つ1つは確かに時間を短縮した。
でも、気づいたら自分がその間を全部つないでいた。
メールAIの出力をコピーし、書類AIに貼り、 その結果をSNSAIに渡す。 AIは動いている。しかし自分は動き続けている。
これは自動化ではない。 自分がグルー（接着剤）になっているだけだ。
スキル（単体AI）とシステム（連携AI）は別物だ。
英語圏のNick Spisakは20万impの投稿で 「30個の単体スキルを作ってから気づいた。 足りないのはスキルではなくシステムだった」と言っている。
OpenClawのcronジョブは最初からシステム設計になっている。 1つのタスクが終わると、その出力が次のタスクの入力になる。
共有コンテキストファイル——全AIが同じ文脈を参照する。 アウトプット→インプット連鎖——前工程の出力が次工程の入力になる。 スケジュール自動化——cronで時間通りに回る。
この3つのパターンで、グルー問題は解決する。
ツールを揃えることと、システムを設計すること。 その違いを理解しないまま進むと、 AIが増えるほど自分の仕事が増える逆説に陥る。
- グルー問題：単体AIを揃えると、経営者自身が接着剤になり工数が増える
- システム設計の3原則：共有コンテキスト、アウトプット→インプット連鎖、スケジュール自動化
- 役割の転換：AIで「レビュアー」になるか「グルー」になるかは設計の問題
- 判断構造の移行：ツールの数ではなく、連携の質が生産性を決める
OpenClawのAIチーム——5人が連携して動く設計
OpenClawには5人のAI役員がいる。 Sonia（CGO）、太郎（CDO）、花子（CQO）、Dave（CRO）、Janet（CBO）。
これは5つの単体AIではない。 5人が1つのシステムとして動いている。
Soniaが日次レポートを生成する。 太郎がそのレポートを元にデータ分析を行う。 花子が品質チェックを走らせる。 Daveが外部向けのアウトプットを整える。 Janetが予算と工数の管理を行う。
前工程の出力が、次工程の入力になる。 誰かが止まっても、他の4人は動き続ける。
cronジョブが時間通りに回し、 共有コンテキストファイルが全員の認識を揃える。
私がやるのは「承認」と「方向修正」だけだ。 グルーは不要になった。
日次→週次→月次——自動で積み上がるレポート連鎖
最もわかりやすいシステム連携の例はレポートだ。
毎朝、日次レポートが自動生成される。 その日の完了タスク、進行中の案件、数値の変動。
金曜日になると、週次レポートが生成される。 月〜金の日次レポートを自動集約し、 週の成果と課題を整理する。
月末には月次レポートが出る。 4週分の週次レポートから、月の傾向を抽出する。
私は日次レポートを毎朝読む。 週次レポートを金曜に確認する。 月次レポートで方針を決める。
この連鎖を手動でやっていたら、 レポート作成だけで週に5時間はかかる。 今はゼロだ。
1つのタスクが次のタスクに文脈を引き継ぐ。 これがシステム設計の基本形だ。
単体AIをシステムに変える3ステップ
- 自分が毎日3ステップ以上手作業でつないでいるワークフローを1つ探す
- 各ステップの「入力（何を受け取るか）」と「出力（何を渡すか）」を書き出す
- ステップ間の繋ぎをAIに任せる設計を1つ書く——最初は2ステップの連携から始める
- 1週間運用し、手動介入が発生したポイントを記録する
- 介入ポイントを自動化し、グルー作業をゼロに近づける
ツールを集める時代は終わった。
30個のAIスキルを持っていても、 自分がグルーなら、AIが増えるほど忙しくなる。
必要なのはシステムとして動かす設計だ。 共有コンテキスト。連鎖する出力。自動化されたスケジュール。
ツールの数ではなく、連携の質。 それが経営の生産性を決める時代が来た。
▼ 続きはXで実況中 [@5dmgmt](https://x.com/5dmgmt)
▼ 全工程の記録はnoteで [→ noteで読む](https://note.com/5dmgmt/n/n700a9b0a817c)