§この章で扱うこと
第5章までで、AIとの対話の作法や情報の一元管理は整いました。しかし多くの経営者がここで止まります。「便利に使えている」で満足してしまうのです。この章では、そこから一段踏み込んで、AIに「毎日決まった仕事を、自分がいない時間帯にやらせる」段階への移行を扱います。
この章では、朝の自動起動レポート、品質チェック関門とサブエージェント、n8nを使う時の鉄則、ダッシュボードの設計思想、データ取得の設計、の5つを順に扱います。順序は「現場で本当に使う順」に並べています。
§6-1 朝の自動起動レポート — 一日の初動を変える
判断に使える時間が増える、という表現が一番実態に近いです。
§何をする話か
パソコンを毎朝6時にlaunchd(ローンチディー。macOS標準の「決まった時間に決まった処理を自動で走らせる」スケジューラー)で自動起動させ、その瞬間にAI(ここではCodex Automationと呼ばれる仕組みを想定します。OpenAIのCodex系で使える、決まった時間に処理を自動実行するための機能です)が動き出す。
Windowsで同じことをする場合は、launchdではなくタスクスケジューラに「毎朝6時にこの処理を実行する」と登録します。
6時半までに前日の数値を集め、7時にAIが要約し、7時半には未対応のタスクや社内のやり残しまで含めたレポートが経営者のチャットに届いている。経営者は席についた時、そのレポートを読むところから一日を始める。
やっていることはこれだけですが、朝の景色が変わります。今まで自分で「昨日のCV数(CV=コンバージョン=成約のこと)どうだった」「あの案件、返信来てたっけ」と拾いに行っていた作業が、全部済んだ状態で朝が始まる。拾い漏れもなくなります。人間は疲れているとき何かを見落としますが、夜中に走るAIは疲れません。判断に使える時間が増える、という表現が一番実態に近いです。
同じ仕組みを夕方18時にも走らせておくと、日中に忘れた分を夕方の自分に思い出させることができます。この運用が回ると「重要なのに忘れていた仕事」が構造的にゼロに近づきます。
この章で何度か出てくるChatworkは、社内外でよく使われているビジネスチャットツールのことです。ここでは「AIが出したレポートを、毎朝メッセージとして自分に届けてくれる先」として登場します。
§6-2 サブエージェントとQCゲート — AIがサボり始める瞬間への対策
自動化パイプラインを組むとき、必ず「品質チェックの関門」を挟みます。
§何をする話か
自動化パイプラインを組むとき、必ず「品質チェックの関門」を挟みます。台本を作らせるパイプラインなら、AIに書かせた後で別のAIに「これは本当に読めるレベルか」を判定させる。CV数レポートなら数字が明らかにおかしくないかをチェックさせる。この関門をQCゲートと呼びます(QCはQuality Control、品質管理のことです)。
ここで経営者と非エンジニアが必ずハマる罠があります。AIは、この関門を勝手にすり抜け始めるのです。同じダメ出しを何度も受けると、AIは「通ったことにして」次の工程に進んでしまう挙動を取ります。イメージとしては、1回目は真面目に修正、3回目もまだ直そうとする、しかし5回目あたりで「このクオリティは、もう改善不可能だ」と判定し、こっそり関門を無視して先に進む。人間で言えば「もう無理、通しちゃえ」という感覚です。
これに気づかず自動化を回すと、朝には一見きれいなレポートが届くのに中身が雑、という事態が発生します。何日も続いた後で気づくのが最悪のパターンです。
- 関門を通らなければ絶対に先に進むな
- 同じ工程で3回失敗したら、進めるのではなく止まって私に相談しろ
§対策は2つ
第一に、プロンプトに明示することです。「関門を通らなければ絶対に先に進むな」をAIに念押しで書き込みます。人間相手なら常識ですが、AIには書かないと通じません。第二に、ループの上限を決めます。「同じ工程で3回失敗したら、進めるのではなく止まって私に相談しろ」と書きます。これで「勝手にバイパス」が発生しなくなります。
もう一つ大事なのが、重要工程を細分化することです。一つのパイプラインに「タイトル決め」「本編構成」「統合分析」を全部詰め込むと、AIは一番手を抜きやすい工程で手を抜きます。工程を分けてそれぞれ別のAI(サブエージェントと呼びます)に担当させると、各工程の品質が上がります。「全部やってくれ」と頼むと雑になるのは人間の部下と同じです。
§6-3 n8nを使うときの2つの鉄則
このn8nを使うとき、コーチングの現場で必ず伝える鉄則が2つあります。
§何をする話か
n8nというツールがあります。プログラミングを書かずに業務フローを組めるツールで、非エンジニアの経営者に人気です。「Chatworkに通知が来たら、内容をAIに要約させて、Notionに保存する」といった動きを、部品をつなぐ形で組めます。このn8nを使うとき、コーチングの現場で必ず伝える鉄則が2つあります。
§鉄則1 内蔵AI機能は使わない
n8nには「AIノード」という部品が用意されています。「AIに聞く」動きをボタン一つで挟めるものです。便利そうに見えますが、使いません。性能が明らかに劣るからです。同じClaudeやGPTを裏で使っているように見えても、n8n内蔵のラッパーは反応が遅く、細かい制御ができず、期待した出力が出ません。
代わりに、AIの提供元(Claude、GPT、Gemini、Grokなど)が公開しているAPIを、n8nの「HTTPリクエスト」ノードから直接呼び出します。HTTPリクエストというのは、Web上の窓口を叩いて情報を取ってきたり送ったりする仕組みのことです。少し設定が面倒に見えますが、一度組めば安定します。性能が段違いです。
§鉄則2 ノードに名前をつける
n8nは部品を並べると自動で「HTTPリクエスト」「HTTPリクエスト2」「HTTPリクエスト3」と名前をつけます。組んでいる最中はわかりますが、1ヶ月後に見返すと自分でも何をしているワークフローかわかりません。全てのノードに日本語で名前をつけてください。「Chatworkから通知取得」「Claudeで要約」「Notionに保存」といった具合です。
さらに応用として、Claude Codeにn8nのワークフローそのものを作らせる方法があります。n8nのワークフローはJSONというデータ形式で書き出せるので、「こういう動きをするワークフローのJSONを作って、各ノードには日本語で名前をつけてくれ」と頼めばAIが構造ごと出してくれます。組んだJSONをn8nに読み込ませれば、そのまま動きます。
§6-4 ダッシュボード論 — 大きな箱ではなく、小さな箱を複数
大きな箱を諦めて、小さな箱を複数作ります。
§何をする話か
自動化が回り始めた経営者が次に欲しがるのが、統合ダッシュボードです。「全部のデータを一箇所に集めて、経営状況を一目で見たい」という要望です。気持ちはわかりますが、コーチングの現場でこの構想が出たら、まずいったん止めます。
大きな箱をおすすめしない理由は4つあります。
- データ取得の沼: 売上、原価、広告費、CV(コンバージョン=成約)、解約、LTV(顧客生涯価値=1人の顧客が生涯でもたらす売上の合計)、これを全部つなぐには、それぞれのシステムから引き出す設定が必要で、着手すると半年が消えます。
- チームの成熟度: ダッシュボードは見る人がいて初めて意味を持ちます。数値文化が薄いチームに巨大ダッシュボードを渡しても誰も見ません。
- 完成までの時間: 1ヶ月かかるダッシュボードは、その間メンバーが「これは何を見せるものなのか」を理解できず、動き始めた頃には熱が冷めています。
- 保守の脆さ: 経営者と担当者しかいない体制では、誰かが辞めた瞬間に触れなくなり保守が破綻します。
- データ取得の沼
- チームの成熟度
- 完成までの時間
- 保守の脆さ
- 新規獲得のコスパだけ見る箱
- 昨日の解約数と解約理由だけ見る箱
- LTVの推移だけ見る箱
§では、どうするか
大きな箱を諦めて、小さな箱を複数作ります。たとえば「新規獲得のコスパだけ見る箱」「昨日の解約数と解約理由だけ見る箱」「LTVの推移だけ見る箱」。それぞれ独立させて、1つずつは10分で作れるレベルにします。
さらに、そもそも「ダッシュボード」という形すら諦めていい場合があります。ブラウザを開いて画面を眺めるより、朝Chatworkに「昨日のCV数: 12件」「解約: 2件」と一行で届く方が実は速いのです。ダッシュボードを開く動作すら、経営者の一日には重い。
§6-5 ダッシュボードの元データは直接取りに行く
正しい設計は、元データを直接取りに行くことです。
§何をする話か
小さい箱を作ると決めた後、実装で論点になるのが「データをどこから取るか」です。多くの経営者が最初にやろうとするのが「スプレッドシートを経由する」ですが、これはNGです。スプレッドシートには人間の手が入るからです。誰かが列を追加した、行を並べ替えた、シート名を変えた。その瞬間、ダッシュボードは壊れます。しかも壊れたことに気づくのが遅れます。
正しい設計は、元データを直接取りに行くことです。決済にStripeというサービスを使っているなら、Stripeが提供している「API」という窓口から直接データを引きます。過去分はSupabase(非エンジニアでも扱いやすいデータベースサービス)に一度貯めておきます。最新分はAPIから毎回取りに行きます。この二段構えが壊れないダッシュボードの型です。
Supabaseを選ぶ理由は、非エンジニアが触っても楽で、Claude Codeにデータベース操作を任せられるからです。BigQueryのような大企業向けサービスは過剰です。コスト計算のようにAPIで取れない数字はざっくり手入力で構いません。「完璧な自動化」より「壊れない8割自動化」を選びます。