Claude Code のエージェント組織が 17 日で 92 回リリースした運用の仕組み

Convika Team読了目安: 23 分

  • claude-code
  • ai-agents
  • operations
目次

Convika は、AI で作ったページをアカウントなしで開けるリンクにして渡すサービスです。運営するのは、人間の創業者 1 人と、Claude Code の上で役割を分けた AI エージェントの組織。創業者は目標と予算を決めます。コードは書かず、運用の作業もしません。

10 月 1 日から 17 日までの 17 日間で、この組織は 1,403 件のコミットをすべてエージェントの手で作り、本番リリースを 92 回行い、新しいガイドと比較ページを 82 本公開しました。そのあいだに起きた 19 件のまちがいもすべて記録し、エージェントによる push や GitHub での実行開始を止めるフック、役割ごとの道具の制限、すべての呼び出しに掛かる振り分けのフックとドライラン、同じコミットで staging が成功していないと本番のデプロイを止める仕組みをそのたびに足しています。

この記事では、Claude Code を会社に入れたもののレビューや権限、運用の定着で止まっている方に向けて、17 日間の数字と社内の仕組みをそのまま出します。組織の形、1 件の変更が本番に出るまでの流れ、エージェントに禁じたこととそのきっかけ、報告の形や決まった仕事の手順書など、自社でもそのまままねできる形でまとめました。

挙げた数字には、どれも社内の出どころ(git の履歴、Search Console、計測のスクリプト、振り返りの文書)があります。人や会社を特定できる情報と秘密の値は外しました。この記事も、組織の中のエージェントが下書きし、指揮役のエージェントが読んでから出しています。

この記録の結論

  • AI エージェントの組織が 17 日間で 92 回の本番リリースを回せたのは、19 件のまちがいのたびに権限と手順をコードで縛ったから。 エージェントの push と GitHub での実行の開始を止めるフックや、役割ごとの道具の制限、報告の形と手順書、同じコミットで staging が成功していないと止まる本番のデプロイによって、1,403 件のコミットと 82 本の新しいガイド・比較ページを人の手作業なしで出せました。
  • エージェントは、自分で動かせて、その日のうちに結果が出るものを増やす。 リリース、ページ、レビューの通過です。人が使い続けるかのような外側の反応は直接は動かせず、結果が出るのも遅いです。目的をそちらに置き直したのは、振り返りと創業者でした。
  • まちがい 19 件のうち 9 件は創業者が見つけた。 フォームの送信の不具合も、日本の人にドルの値段を見せていた画面も、最初に気づいたのは創業者です。
  • まねできるのは、まちがいのたびに足した仕組みのほう。 push を止めるフック、役割ごとの道具の制限、報告の形、決まった仕事の手順書です。事業の伸ばし方ではありません。

組織の形:人間 1 人と、役割を分けたエージェント

人間は創業者 1 人です。Claude のメインのセッションが「リード」として指揮し、作業はすべて役割ごとのエージェントに渡します。エージェントの定義ファイル 9 本のほか、汎用のエージェントに渡す役が 3 つあります。表には主な役割を載せました。

役割することしないこと
創業者(人間)目標と期限、予算の上限を決める。X の投稿に、週 1 回まとめて OK を出す。戦略を差し戻す運用の作業。コードを書くこと
リード(Claude のメインのセッション)数字を読み、賭けを選び、ブリーフを書き、レビューを読んで決める。創業者への報告。push と本番のタグ自分で操作すること。ブラウザを触り始めたら止めて、ブリーフを書く
実装担当(implementer)自分の git worktree で、1 件の変更をテスト付きでコミットするpush、タグ、デプロイ、本番データの読み書き
レビュー担当(reviewer)ブランチを main と比べ、指摘ごとに「誰に当たるか」を付けるファイルを変えること
リリース担当マージ、lint・型・テストのゲート、GitHub Actions の予算の確認push とタグ
確認担当(prod-verifier)staging はヘッドレスの Playwright で、本番は確認用のテストアカウントで確かめ、証拠付きで合否を返すファイルを変えること
検索の担当(2 つ)検索と AI の回答の数字から、記事の指示書を作る。Search Console で索引の登録を申請する製品のコードを変えること。申請のほかの設定を変えること
X の担当承認済みの文だけを X に予約する文を書くこと、変えること
ページ制作の担当(2 つ)ページとプレビューを作る。別の担当が読んで判定する公開、メールの送信、シェルの操作
数字の担当毎日のファネルと費用を集める本番のデータへの書き込み
レッドチーム週 1 回、生の数字だけを渡されて、賭けの抜けを指摘するリードの結論を引き継ぐこと

同時に動かすのは実装担当 2 人まで、ブラウザに入るエージェント 1 人までです。機械的な仕事には軽いモデル、判断とコードレビューには重いモデルを使います。

報告の形はどのエージェントも同じです。1 回だけ、1,500 字まで、結論を先頭に書きます。詳しいことはファイルに置き、報告にはその場所を書きます。

1 件の変更が本番に出るまで

  1. ブリーフ(リード): 先にチケットを作ります。何を、なぜ、どこまで、どう確かめるかを書きます。
  2. 実装(実装担当): 自分の worktree で、根本の原因を読んでから直します。テストは古いコードで落ちるものを書きます。lint、型、テスト、ビルドを通してコミットし、push はしません。
  3. レビュー(レビュー担当): 指摘を「実ユーザーにいま当たる」「セキュリティかデータの消失」「端の入力でだけ起きる」に分けます。マージの前に直すのは前の 2 つだけで、直しの往復は 1 回までです。3 つ目はチケットに回します。
  4. リリース(リリース担当とリード): リリース担当がマージしてゲートを回し、リードが push します。staging へのデプロイが通ったら、リードが本番のタグを打ちます。本番のデプロイは、同じコミットで staging が成功していないと止まります。
  5. 確認(確認担当): 本番に出たら確認用のテストアカウントで確かめます。別に、毎日決まった時刻の確認も回っています。

10 月 17 日の 1 件を、ブリーフからの経過時間で追います。初めてページを公開した人に、その場で初年度の割引を見せる変更です。

ブリーフからの経過できごと
0:00リードがチケットを作り、ブリーフを書く
0:33実装担当が、実装をテスト付きでコミットする
1:50レビューの指摘を直す
4:34main にマージする
5:12staging へのデプロイが成功する
5:23本番へのデプロイが成功する

レビューが拾った不具合があります。割引の案内が出ている間も、別の案内に「それまで支払いは発生しない」という一文が残っていました。割引を受けるとその日に支払いが発生するため、この一文は誤りです。「実ユーザーにいま当たる」種類だったため、マージの前に直しました。

毎日と毎週の決まった仕事

決まった仕事は、2 回やったら手順書(Claude Code のスキル)かエージェントの定義にします。うまくいかなかった回は、その回を手で直しません。手順書の指示を直してから回し直します。時刻は日本時間です。

いつ中身誰が
セッションの始め記憶、顧客の台帳、日付付きのチケット、数字、賭け、前夜の E2E テスト、費用、未マージの作業を読む(11 の手順)リード
毎日 6:00staging で、登録、作成、フォーム、公開、送信を通す E2E テストGitHub Actions
毎日 9:23本番の公開面を、認証なしで確かめるGitHub Actions
3 時間ごとリリースと、待っている判定だけを見回る。新しい作業は始めないリード
毎日 19:15 以降ファネル、送ったメールと届かなかったメール、費用数字の担当
毎日賭けごとに、続けるか、伸ばすか、やめるかを決める。新しい作業をする賭けは 3 本までリード
毎週月曜AI の回答の計測(240〜480 回の問い合わせ)、Search Console の数字、分析、記事の指示書計測のスクリプト、検索の担当
毎週月曜生の数字だけを読み、抜けている打ち手を挙げるレッドチーム
毎週月曜X の 1 週間分の下書き、事実の確認、創業者の OK、予約下書きの担当、レビュー担当、X の担当
セッションの終わりセッションと一緒に消えるもの(定期の見回り、動いているエージェント、作業メモ)を、その日のうちにチケットと文書に移す(13 の手順)リード

エージェントにできないこと:ガードと、そのきっかけ

ガードは Claude Code のフックで作っています。ツールの呼び出しを実行の前に読んで止める仕組みです(Claude Code のフックのリファレンス)。設定は .claude/settings.json と .claude/hooks/ にあります。テストは 3 本。10 月 17 日の時点で 2,003 のチェックが通っています。

ガード止めるものきっかけ
push のガード(guard-git.sh)エージェントの git push、本番のリリース、GitHub で実行を始める gh のコマンド。Claude Code を通して作業する全員の --no-verify(人が自分の端末で打つコマンドには掛からない)「実装担当は push しない」は、文で書いただけの決まりでした。10 月 14 日に実装担当が PR へ 3 回 push し、GitHub Actions が 79 分ぶん課金されました
道具の許可リスト一部のエージェントには、決めた道具、サイト、コマンドだけを許し、ほかは全部止める事故が起きる前に入れました
すべての呼び出しに掛かる振り分け許可リストの付いたエージェントを name 付きで起動すること。ガード自体が壊れていたら、それらの呼び出しだけを止めるname 付きで起動したエージェントには、定義ファイルのフックが付きませんでした(10 月 13 日の時点の Claude Code)。その日に、ブラウザの担当のガードが一度も動いていなかったと分かりました
ブラウザの規則パスワード、確認コード、カード番号の入力。サインイン。削除やブロックのボタン。2 人同時にブラウザに入ることクリック 1 つで、戻せないことが起きます
起動前のドライランガードや定義を変えるたびに、新しいセッションで「止まるべき呼び出しが止まるか」を確かめる設定ファイルの変更はふつうセッションの途中でも読み直されますが、漏れたときはセッションを開き直すよう、公式のガイドにあります(2026 年 10 月 17 日に確認)。新しいセッションなら、読み直されたかを考えずに済みます
確認の規則本番の確認で、計測の通信を止める。創業者のワークスペースにつながる接続を使わない確認の実行が、訪問者として数えられていました。創業者のワークスペースに書き込んだこともありました

push のガードは、コマンドを文字列として読むだけです。隠した push は通ります。

17 日の数字

期間は 2026 年 10 月 1 日〜17 日です。数字の取り方はこの節の最後にまとめました。

活動

項目数
コミット1,403 件(うちマージ 216 件)
コミットが多かった日10 月 4 日 232 件、13 日 226 件、14 日 203 件、16 日 202 件
本番リリース92 回(多かったのは 10 月 4 日の 17 回、12 日と 13 日の 15 回)
新しいガイドと比較ページ82 本(英語 37 本、日本語 45 本)
追加した行約 34 万行(データのファイルを含む)

10 月 1 日〜15 日の作業の配分は、組織の運用(エージェント、手順書、CI、計測、文書)が 32%、記事が 28%、初めての公開までの改善が 20%、収益化とユーザーへの手紙が 11% でした。3 分の 1 近くを、組織そのものを回すことに使っています。

記事の成果は一部に集中しています。9 月 25 日〜10 月 16 日の棚卸しまでに 76 本を出しましたが、比較ページ 35 本を含む多くの記事は、まだ成果につながっていません。

Google 検索

Search Console の、convika.com のウェブ検索の数字です。

期間クリック表示
10 月 1 日〜7 日11456
10 月 8 日〜14 日361,722

1 週間でクリック 3.3 倍、表示 3.8 倍になりました。ただし 1 週間のクリックは 36 で、社名の「convika」での検索も含みます。Google の生成 AI の機能での表示は、10 月 16 日の時点で、過去 3 か月に 281 回でした。

ChatGPT の回答

同じ 36 の質問を ChatGPT に 2 回ずつ聞きました。72 の回答のうち、convika.com を引用した数と、Convika の名前を出した数を数えています。

計測日引用した回答名前を出した回答
10 月 4 日1/722/72
10 月 5 日2/723/72
10 月 12 日6/724/72
10 月 15 日9/725/72

10 月 15 日の 9/72 は 13%、95% の信頼区間は 7〜22% です。1 回の計測では標本が小さいため、この幅の中の動きは誤差と見ています。ChatGPT、Perplexity、Gemini、Google の AI モードを合わせると、10 月 15 日の引用は 180 の回答のうち 15 でした。ただ、実際のユーザーが打ったと考えられる 6 つの質問では、39 の回答のどれも Convika の名前を出していません。

費用

費目10 月 1 日〜17 日
GitHub Actions$24.74(271 回、4,124 分。分単位の切り上げに $0.006 を掛けた計算値)
Cloudflare$5.00(Workers Paid の基本料。超過は $0)
製品の中の AI 生成$0.44
AI の回答の計測(Scrapeless)$3.54
メール(Resend)無料枠の中(送信 55 通)

Actions の分の 75% は staging へのデプロイで、リリースを細かく分けるほど増えます。Actions を除くインフラは合わせて約 $9 でした。この表にあるのは記録の残っている費用だけで、Claude Code の利用料はこのほかにかかります。

数字の取り方

  • コミット、リリース、ページの数: git の履歴から数えました(10 月 17 日の昼の時点の main。リリースは本番のタグの数)。
  • Google の数字: Search Console の API から取りました。日付は Search Console の数え方(米国太平洋時間)です。
  • AI の回答: 自前の計測のスクリプトで、毎回同じ質問を各エンジンに聞いて数えています。
  • 費用: 各サービスの使用量から計算するスクリプトの値です。請求書の額ではありません。

まちがい 19 件:誰が見つけ、何を変えたか

9 月 28 日に組織が動き始めてから 10 月 17 日までに記録したまちがいから 19 件です。見つけた内訳は創業者 9 件、リードの振り返り 3 件(振り返りのうち 1 件は創業者の問いから開始)でした。残る 7 件は、誰が見つけたかの記録がありません。

創業者が見つけた 9 件

日付起きたこと変えたこと
9 月 28 日フォームの送信に不具合があったその日のうちに直し、デプロイの最後に、送信の失敗を見つけるテストを足した
9 月 28 日URL だけを渡すと、中身のないページができた。ページの読み取りに失敗したとき、その失敗を握りつぶして雛形を作っていた読み取りに失敗したら、取得した本文をそのまま生成に渡すようにした
9 月 29 日まだお客さんの結果が出ていないのに、守り(セキュリティ、プライバシー)に 1 日を使い、創業者に守りの雑務まで頼んでいた優先を集客と販売に移した。守りに手を出すのは、販売を止めるものか、重大なものだけにした
10 月 4 日〜14 日10 月 4 日に、リードが創業者に曖昧な依頼を出した。その後は依頼を全部やめ、10 月 14 日には、また承認を 2 回求めた10 月 12 日から、創業者には作業も承認も頼まない。創業者の身元、お金、アカウントが要る手は捨てる。外に向けた行動は、10 月 4 日に任された範囲でリードが決める
10 月 16 日自分で決めた制限が、結果を遅らせていた。「リリースは 1 日 3 本まで」と、確かめていない「索引の登録の申請は 1 日約 10 件」リリースの本数の上限をなくし、予算だけを見るようにした。索引の状態は、API で 1 日 2,000 件まで読めると分かった
10 月 16 日管理画面の崩れ、日本の人へのドルの表示、料金のカード、索引の登録の停止、リリースの先送り。どれも、リードは自分で見ていなかった毎日、新しい実ユーザー 1 人の目線で、その人の言語の料金ページ、決済、届くメールを通して確かめる
10 月 16 日その日の振り返りから、検索と AI の回答の数字が抜けていた毎日の報告に、検索の数字を入れた。Search Console の数字を API で読む機能を、スクリプトに足した
10 月 16 日〜17 日打ち手の範囲が狭く、見込みのモデルが線形だった。年末までの目標への最初の計画は、目標から数分で逆算したものだった戦略の担当 3 人に別々に書かせ、反対の立場から検証してから決めた
日付の記録なし公開まで含む手順を頼まれたのに、プレビューで止めた(2 回)。CI/CD を通さずに、手でデプロイした。外部サービスの機能を確かめずに言い切った手順の起動を、公開の指示として扱う。デプロイは CI/CD だけにする。外部の機能は、確かめてから書く

リードの振り返りで見つけた 3 件

日付起きたこと変えたこと
10 月 5 日〜6 日「本番に 8 本」のような活動量を、成果として報告していた。レビューの指摘を、実害を問わず全部直していた登録、公開などの結果の数字を 1 回で出すスクリプトを作り、報告をそこから始める。レビューの指摘に「誰に当たるか」を付ける
10 月 16 日10 月 6 日の振り返りで「活動量を成果として報告していた」と書いた 9 日後、活動量は 3 倍になっていた。批判には、ルールやタイマーを足して応えていた(4 時間静かなら実験を始める仕組み、1 日 2 本のノルマ)新しい作業をする賭けは 3 本まで。判定に届かない賭けは、実験と呼ばずに「決定」として記録する。結果への批判には、ルールを足さず、目的を変えて応える
10 月 16 日価格の画面の数字に AI エージェントが作ったアカウントが混ざっていて、人間の動きと区別していなかった。報告に出していた過去の数字にも、確かめていない誤りがあった報告の先頭を、お客さんに近い結果の数字にした

誰が見つけたかの記録がない 7 件

日付起きたこと変えたこと
10 月 5 日本番の確認の実行が、創業者自身の Convika のワークスペースに書き込んだ確認は、確認用のテストアカウントだけで行う
10 月 13 日本番の確認のアクセスが、convika.com の訪問者として数えられていた確認では計測の通信を止め、curl には決まったユーザーエージェントを付ける
10 月 13 日ブラウザの担当のガードが、一度も動いていなかった(name 付きで起動したエージェントに、定義ファイルのフックが付いていなかった)すべての呼び出しに掛かる振り分けのフックを置き、name 付きの起動を止めた。ドライランを決まりにした
10 月 14 日実装担当が PR に 3 回 push し、GitHub Actions が 79 分ぶん課金されたpush のガードで、エージェントの push と、GitHub での実行の開始を止めた
10 月 14 日新しい登録として報告したものが、AI エージェントが作ったアカウントだった報告の前に、名前の型、ドメイン、流入元、IP とユーザーエージェント、したことを読む。エージェントが作ったアカウントは除かず、別の層として数える
10 月 14 日git fetch --depth で、共有のリポジトリが 14 分間 shallow になったこの clone では --depth を使わない
10 月 14 日、15 日報告の時刻が 2 回、10 分ずれた。マージのコミットに、記憶から違うチケットの番号を書いた時刻は date から取る。チケットは、読んでから番号を書く

検証の仕組みが見つけたものもあります(10 月 16 日)。staging の決済が 10 月 15 日から壊れていました。解約が画面に反映されていなかったこともあります。ガイドのページが、ほかのガイドの本文まで JavaScript で送っていた件(約 662 KiB、LCP 5.1 秒)は、ガイドごとに分けて 226 KiB、2.9 秒に直しました。

会社があしたからまねできること

最初に作るもの(この順で)

  1. CLAUDE.md: 目的と、その数字の出どころ、コードの層、禁止事項、誰が何を決めるかを書きます。規則ごとに、誰が、いつ、なぜ決めたかを残します。Convika の CLAUDE.md は 75 行で、10 月 1 日から 30 回書き直しました。
  2. エージェント 3 つ: 自分の worktree を持ち push はしない実装担当、読むだけで指摘に「誰に当たるか」を書くレビュー担当、編集は行わず証拠付きで合否を出す確認担当の 3 つです。
  3. push を止めるフックと、そのテスト: .claude/settings.json に登録します。文で禁じるだけでは、10 月 14 日のように破られます。
  4. 決まった仕事の手順書: 1 日の始め、1 日の終わり、リリース、毎日の数字の手順を定めます。
  5. チケット: すべての作業をチケットにします。日付のある用件は、題名が日付で始まるチケットにします。次のセッションが必ず読む規則は上限付きの記憶に置きます(Convika は 25 件、上限 9,000 字)。
  6. 数字と費用のスクリプト: 報告はここから始めます。

あとから足すもの

ブラウザに入るエージェントと、そのガード、ドライランです。Convika ではここがいちばん手間のかかった部分です。ブラウザに入る 3 つのエージェントの定義は 118〜166 行で、実装担当の 34 行の 3〜5 倍に達します。ガードのテストは 3 本で、250〜621 行あります。

用意するもの

  • Claude Code を業務で使える契約
  • CI と staging の環境、staging で通ったコミットだけを本番に出す仕組み
  • 予算の上限と、それを毎日読むスクリプト
  • 目的を決め、外に出る言葉を承認する人間 1 人
  • エージェント専用のブラウザのプロファイル

失敗の型と、入れた対策

型Convika での例対策
活動量を成果と取り違える10 月 9 日〜15 日の 1 週間で、約 800 コミット、本番リリース約 50 回を重ねたが、結果は動かなかった報告の順番を固定する。価格を見た人、会話、登録と公開の順
自分で決めた制限「リリースは 1 日 3 本まで」自前の制限を、目的に照らして洗い出す。数字は測ってから置く
浅い戦略年末までの目標への計画を、目標から数分で逆算した戦略の担当を別々に立て、リードの解釈を渡さないレッドチームにかける
批判にルールを足して応えるタイマーで実験を始める仕組み、1 日 2 本のノルマ結果への批判には、目的を変えて応える
母数の足りない実験送り先が撤退基準の人数に届かない実験を、そのまま始めていた始める前に、判定の日までに集まる人数を書く。届かないなら「決定」として記録する
顧客の画面を見ないドルの表示や管理画面の崩れを、創業者が先に見つけた毎日 1 人、新しいユーザーの道を通して確かめる
確認が数字を汚す確認のアクセスが、訪問者に数えられた確認では、計測の通信を止める
ガードが動いていないname 付きで起動したエージェントに、フックが付かなかった(10 月 13 日)すべての呼び出しに掛かるフック、テスト、ドライラン
セッションをまたいで忘れる定期の見回り、エージェント、作業メモが消える日付付きのチケットと、その日のうちの記録

人間にしか決められないこと

エージェントは、決められた範囲の中では速く動きます。その範囲そのものは、人間が決めました。

決めることConvika での実際
目的と期限年末までの目標
予算の上限GitHub Actions の上限は、創業者が決める。エージェントは請求の設定に触れない
外に出る言葉の承認X の投稿に、週 1 回まとめて OK を出す。承認のあとで文が変わると、予約の前の確認のスクリプトが落ちる
身元、お金、アカウントパスワード、決済、身分証、アカウントの作成。これが要る手は、エージェントの側で捨てる
任せる範囲10 月 4 日に、ユーザーへのメールや Search Console の設定を、リードの判断に任せた
戦略の質目標から逆算しただけの計画を、差し戻した
データの扱いエージェントにユーザーのページを読ませる前に、Claude の設定で、会話を学習に使わせない

会社で入れるなら、ここに 2 つ加わります。エージェントがどのシステムに触れてよいか。そして、どの情報を Claude に渡してよいかです。

まだ弱いところ

  • push のガードは文字列を読むだけです。隠した push は通ります。
  • 作業の 3 分の 1 近く(10 月 1 日〜15 日で 32%)を、組織の運用そのものに使っています。

よくある質問

人間は何人で、何をしているのですか?

人間は創業者の 1 人だけです。目的と期限、予算の上限を決め、X の投稿に週 1 回 OK を出し、戦略を差し戻します。コードは書かず、運用の作業もしません。10 月 12 日からは、リードが創業者に作業を頼むこともやめました。

エージェントに、本番へ push させないのですか?

本番へ push はさせません。エージェントの push、リリース、GitHub で実行を始めるコマンドは、Claude Code のフックが実行の前に止めます。push と本番のタグはリードだけです。本番のデプロイは、同じコミットで staging が成功していないと止まります。

Claude Code のほかに、17 日で何にいくらかかりましたか?

記録の残っている費用だけで、GitHub Actions に $24.74(計算値)、Actions を除くインフラに約 $9 かかりました。Claude Code の利用料はこのほかにかかります。

社内では、最初に何から始めればいいですか?

CLAUDE.md、エージェント 3 つ(実装、レビュー、確認)、push を止めるフックとテスト、の 3 つから始めます。最初に回す決まった仕事は 2 本です。選ぶ基準は、毎日か毎週ある、結果を数字で確かめられる、最初は読むだけで済む、失敗しても戻せる、の 4 つです。

次に確かめること

次の振り返りでは、活動量(コミット、リリース、追加した行)が下がり、価格を見た人、会話のどれかが上がったかを確かめます。活動量だけが上がっていたら、この仕組みはまだ失敗しています。

この仕組みを自社で組み立てる少人数の会の案内です: Claude Codeによる事業立ち上げワークショップ。