Claude Codeでグロース業務をPO1人で回せるようになった。考え方と気づき
こんにちは。クラシル株式会社 小川です。
ここ数週間、売上分析から施策立案、MAツールへの配信設定、効果検証まで、グロース業務をClaude Codeで自動化する取り組みをしています。
マルチエージェントを活用することで、もともと複数人で分担していた作業が、1人＋AIチームで回りつつあります。
まだ発展途上ですが、設計の考え方と気づきを整理してみます。
まずは全容です。
それぞれポイントを後述していきます。
まずやったこと：業務データの集約
AIチームの設計より先に、前提の話です。AIが意思決定に必要な情報にアクセスできる状態を作ることがとても重要です。
業務で使うデータって散らばっていて、売上の実績はDWH、コストや予算の計画はスプレッドシート、施策の実施状況はSlack、運用方針はNotion。人間はこれらを頭の中でつなげて判断していますが、AIにそれはできません。
なのでまず、これらをAIが扱える形に構造化してアクセス可能にしました。
DWHにはMCP経由でクエリを投げてデータを取得
スプレッドシートの計画値はスクリプトで取得
Slackの情報はSlack APIで収集・分類
Notionの運用方針はNotion API経由で取得
派手な話ではないですが、ここが整っていないとAIは何もできません。「分析して」と言っても、データにアクセスできなければ始まらないので。
意思決定に必要な情報が、一定の構造を持って、プログラムからアクセスできる。これがAIチームの最低条件だと思っています。
属人化を消す：ルールファイルとナレッジベース
データの次に整備したのは、判断基準と知見の明文化です。
ルールファイル
運用担当者の頭の中にあった知識を、全部マークダウンに書き出しました。KPIの定義と計算式、分析結果の品質判定基準（サンプルサイズ、分析期間、反証仮説の有無）、出力フォーマットのルール。
これがあると、誰がやっても同じ基準で分析できます。AIでも人間でも。
AIを導入したから属人化が解消されたのではなく、AIに仕事を任せるためにルールを明文化した結果、属人化が解消される形になります。
ナレッジベース
分析セッションのたびに、知見が自動で蓄積されます。
過去に発見した定量的なパターン（次回「これは既知か新規か」を判断する材料）
実施した施策と結果（同じ施策を二度提案しないため）
人間が「ここも見て」と指摘したポイント（次回以降、事前にカバーされる）
3つ目が特に効いていて、レビューで指摘するたびに蓄積されて、次の分析品質が上がる。同じ指摘を二度しなくていい。やるたび賢くなっていく実感があります。
設計の肝：agentとskillの分離
データとルールが揃った上で、AIチームをどう構成するか。ここが一番試行錯誤しました。
前提としてマルチエージェントを導入しています。
最初は、業務の手順をすべてエージェントの定義に書いていました。「売上分析エージェント」に分析手順もクエリもKPI定義も全部入れる構成。これがうまくいかなかった。
agentには汎用的な役割だけを定義し、skillで実際の業務コンテキストを渡すように変えたところ、一気に機能するようになりました。
agentは「職種」
agentは「この人は何ができるか」だけを定義したものです。業務の文脈は持たせません。
売上分析エージェントなら、収益構造を分析する、利益率やカテゴリの観点から見る、使うテーブルとクエリのテンプレート。
批評エージェントなら、他のエージェントの結論に反例を探す、因果と相関の混同を指摘する、自明な結論を弾く。判定はRobust / Conditional / Revise / Rejectの4段階。
MAツールオペレーターなら、施策案をMAツールのAPI仕様に変換する、セグメントIDのマッピングと配信設定の生成、API経由での設定作成。
どれも「どんな仕事をするか」は決まっていますが、「今日何をするか」は決まっていません。職種の定義であって、タスクの指示ではない。
skillは「業務フロー」
skillは今日の仕事の手順書です。Claude Codeのスラッシュコマンドとして登録しておいて、呼び出すと業務フローが起動します。
`/propose-campaign` というskillは、特定の配信枠の施策を提案するための手順書で、中身はこんな感じです。
ヒアリング：対象セグメント・配信期間・特記事項を確認
データ収集：コスト計画を取得、CVR等を算出、過去施策を確認（ここで複数のagentを並行スポーン）
施策の組み立て：対象外を除外、注力商材を優先、期待利益でランキング
批評：批評エージェントに案を叩かせる
整合性チェック：管理表と照合して不一致がないか確認
MAツールに配信設定：設定値を生成してAPI配信
記録：施策履歴とナレッジベースを更新
このskillが、汎用的なagentを「今日の仕事」にアサインしているわけです。
Team Leadがテーマに応じて必要なメンバーだけ招集して、各自が分析して、最後にTeam Leadが統合・品質チェックして結論を出す。人間のチームでやっていたことをそのまま落とし込んだだけです。
Team Lead（司令塔）
├── データ品質チェック担当
├── 施策履歴の収集担当
├── Slack情報の収集担当
├── 売上の定量分析担当
├── ユーザー行動の分析担当
├── 結果を批評する担当
└── 施策をMAツールで配信する担当なぜ分離するとうまくいくか
agentに業務手順を直接書くと、売上分析エージェントが特定の施策専用になって使い回せなくなるし、手順が増えるたびに定義が膨らんで役割がぼやけるし、順序がagent側に埋め込まれて別の使い方ができなくなる。
分離しておくと、同じ売上分析エージェントが施策提案でも効果分析でも使われる。同じ批評エージェントが提案時にも分析時にも呼ばれる。agentが汎用だからこそ、skillの組み合わせ次第で新しい業務フローをすぐ作れます。
実際、最初は「施策提案」と「効果分析」の2つのskillから始めましたが、今はかなり増えています。
agentの追加はほぼなくて、skillだけが増えた。この時点で、関心ごとの分離がうまく効いているなと思います。
人間の役割
仕組みを整えただけだと、一般的な施策しか出てきません。
「CVRを上げたい」とだけ言うと、「インセンティブを上げましょう」「対象セグメントを広げましょう」みたいな、誰でも思いつく提案が返ってくる。正しいけど、価値がない。
施策の質を決めているのは、目標と切り口をどう伝えるかです。
「CVRを上げたい」ではなく、こう渡す。
課題：1回CV経験ユーザーのリピート率が、1/3に落ちている
仮説：1回目は人気商材で転換するが、2回目に何をすべきか分からず離脱している
アプローチ：2回目に転換しやすい商材をデータで特定し、1回CV経験者に絞って訴求する
こう渡すと、「1回経験者のセグメントでリピート率が高い商材はどれか」をデータから探し始めて、「商材Aは1回目→2回目の転換率が他の3倍」みたいな発見が出てくる。
何を解決するかと、どう切り込むかを人間が決めて、仮説の検証と具体化をAIに委ねる。ここが曖昧だと、仕組みは動いているのにアウトプットが凡庸、というもったいないことになります。
どれだけデータを集めても、最終的に人の意思が入る判断はAIだけでは完結しません。
データ的にCVRは悪いが、「将来の投資のために必要」みたいな判断にはビジネスの文脈や肌感覚が要る。
なのでAIが完璧な答えを出すことは目指していなくて、AIが提案して人が調整しやすい業務フローにすることを心がけています。skillに人間の確認・修正ステップを入れているのはそのためです。
最大のボトルネック：MAツールの壁
ここまでスムーズに回っているように見えるかもしれませんが、一番苦労しているのはAIの性能でも設計でもなく、プロダクトへの反映です。
分析→施策立案まではAIの得意領域で、きれいに自動化できます。問題はその先で、提案された施策を実際にユーザーに届けるにはMAツールや管理画面で設定しなければいけない。
セグメントの作成、配信条件の設定、クリエイティブの登録、ABテストの設計。これらをAIから操作する必要があります。
僕の場合、MAツールのAPIで設定値を配信する仕組みを自前で作りました。動いてはいますが、全てを網羅することはできず、一部ブラウザの自動操作等で賄っています。
AIから検証サイクルを回しやすいインタフェースを自前で作るしかないと腹を括って、泥臭く1つずつ埋めています。
分析も立案もAIができる時代に、実行だけが手作業で詰まっている。ここが変われば改善サイクルの速度は桁で変わると思います。
さいごに
振り返ると、このプロジェクトで重要なポイントだったのは、
skill・agent・人間それぞれでの関心ごとの分離すること
だったかなと思います。
データ集約層：意思決定に必要な情報へのアクセス
ルールファイル：判断基準の明文化
ナレッジベース：蓄積された知見
agent：汎用的な職能
skill：業務フロー
人間：AIに渡す"問い"の質の担保
それぞれ独立しているから、再現性と拡張性が保たれる。新しい業務フローはskillだけ書けばいいし、ルールが変わればルールファイルだけ直せばいい。データソースが増えればアクセス層を足せばいい。
AIを「すごい分析者」ですが、その能力を活かすには"問い"を用意すること。
AIはルールに忠実で、疲れなくて、記憶を失わないランタイムです。そのランタイムの上に、関心ごとを分離した設計を載せることで、複数人で分担していた「分析→施策立案→配信→効果検証」のサイクルを1人で回せるようになりつつあります。
今後は、このプロジェクトを社内に配布して、
自分以外が触っても、再現性高く使えるにはどういう構成が良いか等を考えていきたいと思っています。