Claude Codeをグロース責任者に、目標の連鎖と実験の規律で迷走を防ぐ

グロースチームはかつて、A/Bテストの設定やランディングページの変更をエンジニアに頼み、何週間も待つのが当たり前でした。Claude Codeのようにターミナルで動くコーディングエージェントが、その待ち時間の多くをなくしました。エンジニアリング上の適切な権限さえあれば、マーケターが機能を最初から最後まで作り、そのまま公開できます。新たな課題は焦点です。仕組みのないエージェントは脇道にそれ、一人で事業を営む創業者は売上ではなく技術的な寄り道に時間を費やしがちです。ElevenLabsの元グロース責任者で、同社の急成長を支えた人物が、Claude Codeを事業目標に向け続けるためのオープンソースの枠組み「Agentic Growth OS」を作りました。

ターミナルのエージェントにガードレールが必要な理由

Webのチャットアシスタントは、表面的な文章を出すにとどまりがちです。ターミナルで動くエージェントは、プロジェクトフォルダのファイルを読み、指標を取り込み、スクリプトを実行し、実際に公開される成果物を編集します。誰もが午前中だけでMVP（実用最小限の製品）を作れる今、大きなリスクはもはやコーディングの遅さではなく、誰も求めていないものを効率よく作ってしまうことです。

Agentic Growth OSはハーネス、つまりモデルを包む指示、ルール、ツール接続の集まりです。公開のGitHubリポジトリで提供され、Claude Codeのプラグインマーケットプレイスのコマンド2つでインストールでき、OpenAI CodexやOpenClawといった他のエージェントでも動きます。柱は四つあります。

• 目標のサイクル：あらゆる作業を年間と四半期の目標に結び付ける
• 実験の規律：テストの始め方、進め方、終え方を定める
• 専門エージェントの役割：チーフ・オブ・スタッフ、検索エンジン最適化（SEO）のアナリスト、製品要求仕様書（PRD）を書くプロダクトリード、反論を担うレビュー委員会など
• ツール接続：APIと、AIモデルが外部のツールやデータにアクセスするための標準であるModel Context Protocol（MCP）でつなぐ

年間ミッションから日次スタンドアップまでの目標の連鎖

それぞれの作業は上位の目標に照らして評価され、作業範囲が膨らむのを防ぎます。

この枠組みの作者は、日次のスタンドアップを最も価値が低いとみなしてよく省きますが、週次の振り返りは10～15週連続で続けてきました。週単位なら傾向が見えるだけのデータがたまるからです。一人で事業を営むなら、まず週次の振り返りから始めるのがよさそうです。

オンボーディングはgrowth setupコマンドから始まります。このコマンドはプロジェクトフォルダや、AsanaとGoogle Docsなどの情報源から既存の目標を探します。架空のプロダクトマーケターを想定したサンプルのワークスペースでは、2025年第2四半期の古いOKR、月次目標の欠落、14日間分析されないままの料金ページのテストを指摘しました。その後、5分ほどの簡易オンボーディングか、1～2時間のより詳しいセッションで不足分を埋めます。

▲ 年間ミッションから日々の作業へ

反論するセッションフック

プラグインは、Claude Codeが各セッションの開始時に読む指示ファイルCLAUDE.mdをカスタマイズします。続いて、決まったタイミングで自動的に動くスクリプトであるセッションフックが、起動のたびに要約を表示します。12月31日までに年間経常収益（ARR）£100万といった年間ミッション、リードから顧客への転換率を10%から20%に引き上げる四半期目標、コンバージョンのテストを常に10本動かすというルール、今週の優先事項、その日のやることリスト、放置されたテストが並びます。

するとClaudeは社内のグロース責任者のように振る舞います。その作業が10倍の成果を狙える賭けかどうかを問い、Astroフレームワークで3Dゲームを作り始めればミッションに引き戻します。タスク管理のTodoistとGitHubにつなぐと、Claudeはさらに踏み込みました。2、3回の振り返りの後、外部への働きかけのタスクが何週間も手つかずのまま残る一方で、コミット履歴にはグロース上の根拠のないリファクタリングが並んでいることに気づいたのです。エンジニアリングを装った先延ばしを見抜いたことになります。

実験にはベースラインと中止スイッチを

事前に登録したベースライン、明確な成功指標、決まった測定期間がなければ、テストは始めません。A/Bテストではサンプルサイズに見合う検出力も確認します。どのテストもきちんと結論を出して共有の記録に残し、学びを積み上げます。記録がなければ、作者の最初のスタートアップで起きたように、新しく入った人がすでに失敗したテストを提案しかねません。各実験は次のテンプレートに沿います。

中止基準があれば止めどきが前もって決まるため、ファネルの成果が落ちているのにテストをだらだら続けることはありません。ランディングページの離脱ポップアップのテストを頼むと、エージェントはまずテンプレートとプレイブックを確認し、続いて不足しているベースラインのコンバージョン率、週間トラフィック、テストが支える目標を尋ねます。ベースラインは手で写すのではなく、PostHog、Mixpanel、Amplitudeなどの分析ツールから直接取り込むべきです。また、ツールが手軽になったからといって、トラフィックの少ないページや重要でないページでテストを回してよい理由にはなりません。

エージェントに計画を批判させる

この枠組みのPRDスキルは、「なぜ」を繰り返し問う根本原因分析の手法であるトヨタの5 Whysを取り入れ、機能を提案する人に向けます。検索流入を狙ったランディングページを提案すると、エージェントはキーワードの検索ボリュームを調べて主要な指標を動かせるかを確かめ、数字が乏しければ作らないよう説得することもよくあります。承認されたPRDには作業ごとのチェックボックスが付くため、モデルが一度に保持できるテキストの量であるコンテキストウィンドウがリセットされても、セッションが落ちても、エージェントは続きから再開できます。

コードを公開する前、決済の仕組みを変える前、戦略文書を確定する前に、作者はmulti-agent-refineというスキルを実行します。メインのエージェントが立ち上げる補助役のサブエージェントを3～10体動かし、同じ文書を技術的な正しさ、見落とした考慮事項、エンジニアリングの簡潔さ、運用上の実現可能性といった異なる観点から読ませます。特に役立つのは「何が欠けているか」を問う批判役です。書き手は、自分が明言していない前提になかなか気づけないからです。基準の異なる批判役を並べれば、一つのエージェントが自分の成果物を見直すよりはるかに多くの問題を見つけられる、というのがこの考え方です。

成長OKRの文書にこのスキルを実行したところ、測定可能性、実現可能性、戦略との整合、抜け漏れを担う4体の批判役が、次のような問題を指摘しました。

• 第3四半期の目標と食い違う第2四半期の振り返りデータ
• 測定期限が決まっていない、トライアルから有料への転換目標
• 888人のセルフサーブ利用者から算出したまま、トライアルから有料への転換率3.12%に合わせて更新されていないアクティベーションのベースライン

メインのエージェントは指摘をP0、P1、P2に分類し、四半期を正式に締めるか、ベースラインを引き直すか、文書を修正するかを尋ねました。コストには注意が必要です。作者はOpusのサブエージェントを一度に20体起動してすぐに利用上限に達したことがあり、こうしたレビューにはSonnetのような高速で安価なモデルを勧めています。

▲ マルチエージェントによる計画の批判的検証

エージェントが操作できるツールをつなぐ

ツールは、しっかりしたコマンドラインインターフェース（CLI）か、ドキュメントの整ったAPIを持つサービスに絞ります。そうすればエージェントは人が手で報告した数字に頼らず、データを直接読み書きできます。

SEOについては、作者はインストール数が20万6000回を超える公開のSEO監査スキルを手直しして使い、キーワードデータはAhrefsやSemrushのようなサブスクリプション型のツールではなく、1回の問い合わせが数セントで済むDataForSEOのAPIから取得します。/seo-auditコマンドは見出しタグ、robots.txt、サイトマップ、リンク構造を確認し、Google LighthouseのCLIを実行してページ速度を測ります。ページ速度は検索順位とコンバージョンの両方に影響します。有料記事の多いあるニュースレターのサイトでは、記事の43%が検索エンジンから読めず、448本にメタディスクリプションがなく、130本のタイトルが65文字を超えていることがわかりました。かつては代理店を2～3週間待ち、さらに開発者の手を何週間も要した作業を、今ではリポジトリのエージェントが数時間で修正からテストまで終えます。

PostHogは、作者がグロースチームに最初につなぐよう勧めるツールです。無料枠が手厚く、MCP、API、CLIがそろっているからです。作者が使うダッシュボード、グラフ、実験は、ページ上部のバナーを1列と2列のレイアウトで比べるテストも含め、すべてClaude CodeがAPI経由で作りました。計測をきれいに保つため、三つの安全策を設けています。

• リポジトリへのアクセス。 グロースマーケターは少なくともGitHubの読み取り権限を求めるべきです。そうすれば、イベントがいつ記録されるのかをSlackでエンジニアに尋ねなくても、エージェントが確認できます。
• CIによる関門。 GitHub Actionsの継続的インテグレーション（CI）のチェックが、PostHogの計測イベントを含まない新しいコードのプルリクエストのマージを止めます。
• イベントの文書化。 外部の代理店がイベント名に説明がないせいでデータを読み違えた後、Claude Codeとマルチエージェントのレビューで、350件を超えるイベント定義に約2時間で注釈を付けました。かつてはシニアのプロダクトマネージャーが何週間もかけていた作業です。

運転席には人を

作者の判断では、人が関わらずに事業のために稼ぐエージェントという話の大半は、Xのようなソーシャルメディアで広まる幻想です。監督のないエージェントは、AIモデルが処理し課金の単位にもなるテキストの単位であるトークンを価値の低いループで消費したり、浅い要約を返したりしがちです。作者は人を運転席に置き、範囲を絞った1～2時間の調査やコーディングの作業をエージェントに任せます。定期実行のルーチンはすでに役立っています。たとえば日曜の夜にサイトを検査し、パフォーマンスが落ちていれば警告メールを送るジョブです。

コードには別の目が必要です。Claude Codeはテストがあっても誤った結論を自信たっぷりに述べ、気づきにくいバグを紛れ込ませることがあります。そこで作者は、プルリクエストを確認するAIコードレビューツールのCubicと、エラーをその場で知らせるSentryを組み合わせています。作者は、エージェントのネットワークが夜通し実験を回して検証する姿を次のフロンティアとみていますが、24時間体制で安定して動かす方法はまだ詰めている段階だと認めています。作者の見方では、エージェントが実行を担うようになるにつれ、グロースマーケターの仕事は、エージェントを正しい実験に向けられるだけ顧客を深く理解することへと移っていきます。

エージェント自身に指示を書き直させる

作者によれば最大の失敗は、エージェントに自らの指示を改善させないことです。対処法は、最近のセッションとAnthropicの最新ドキュメントを踏まえてシステム指示をどう改善できるかをClaudeに尋ね、CLAUDE.mdを書き直させることです。ある採用関連のスタートアップは、自社のエージェントに自分のシステムプロンプトを批評させ、10段階の改善チェックリストを得ました。Agentic Growth OSにも、過去のセッションを見直して新しいスキルを提案し、古くなった指示を削る週次のルーチンがあります。これは汎用人工知能という意味での自己改善ではなく、フィードバックによるプロンプトの調整です。そして、クラウドのチャットと違って自らの設定を編集できる、Claude CodeやCoworkのようなファイルベースのツールがあってこそ成り立ちます。

小さなチームが今週できること

教訓は、Claude Codeにより多くの仕事を与えることよりも、構造を与えることにあるようです。応えるべき目標、締めくくるべき実験、そして公開前に計画を試す批判役です。方向を決めるのは人で、エージェントは範囲の決まった実行と確認を担います。

1. 年間ミッション、四半期OKR、進行中の実験を、CLAUDE.mdとそれが読み込むファイルに書き込みます。
2. 1時間の週次振り返りを行い、口述したメモをStripeやPostHogの数字と照らし合わせます。
3. ベースライン、期間、交絡要因、中止基準を備えた実験テンプレートを使い、すべての結果を記録します。
4. 分析ツールとCRMをAPIやMCPでつなぎ、ベースラインをエージェント自身に取り込ませます。
5. 大きな計画は「何が欠けているか」を問う批判役を含むサブエージェントのレビューにかけ、軽いモデルで回します。
6. エージェントには1～2時間の作業を任せ、そのコードをAIレビューツールとエラー追跡で裏付けます。