エンジニアが「作る」から「売る」までをやる時代 —— Claude Codeで実現するAIエージェントのGTM
こんにちは。kubell でバックオフィス向け AI エージェントを開発している山本です。
こちらの記事は AI や BPaaS をテーマとした#kubellブログリレーの記事として執筆しています。
はじめに
私たちが現在開発しているプロダクトの一つに社労士事務所の「毎月のルーティン作業」を自動化する AI エージェントがあります。例えば、次のような業務です。
給与データの読み込み
労務管理ソフトへの入力
公的文書の OCR 処理
こうした業務は、毎月発生する定型作業です。
そして、 AI エージェントを作る側にも通常のルーティン作業があります。
それは例えば、
新しいクライアントへの対応
AI エージェントの不具合修正
提案資料の準備
などです。
AI で業務を自動化するプロダクトを作っているのに自分たちの業務は手作業のまま。
そこで私たちは、プロダクトを市場に届けるオペレーション自体を AI で最適化する取り組みを始めました。
今回は、その中から 3つの取り組みを紹介します。
1. 営業資料を AI が作る
エージェントの導入先が増えるに比例して、クライアントごとの提案資料も増えていきます。会社名や提案内容を差し替えた資料が必要になるためです。毎回 PowerPoint を開いて手作業で書き換えるのは面倒です。そこで Skills を作成しました。Skills とは、Claude Code に「特定の作業手順」を事前に教えておく仕組みです。
テンプレートの PowerPoint を読み取り、
会社名
プラン名
料金
などを自動で穴埋めする手順を定義しておきます。
エンジニアが営業資料を作ると聞くと少し不思議に思うかもしれません。従来、この領域は
インサイドセールス
カスタマーサクセス
など、複数の部門が分担していました。
しかし現在は、AI を介することで
提案資料の作成
顧客への提案
顧客体験の支援
までを少人数で完結できるようになりつつあります。
2. 新規クライアント対応を AI がパッケージから生成する
私たちのエージェントは、クライアントごとに少しずつ仕様が異なります。例えば、
給与データのフォーマット
労務管理ソフトの入力項目
などです。そのため、クライアントごとに専用のエージェントを作る必要があります。とはいえ、全体の約8割は共通処理です。共通部分はパッケージとしてまとめてあり、
データマッピング
Excel の読み取りルール
設定値
といったクライアント固有の部分だけを実装すれば動く構造になっています。
この「固有部分だけを実装する」作業を Skills にしました。
/generate-pay-sync-client acmeこのコマンドを実行すると、AI が共通パッケージの構造を読み取り、ボイラープレート（ひな形コード）を自動生成します。
設定ファイル
テストコード
デプロイ設定
など、すべてが揃った状態で出力されます。
生成されたコードには TODO コメントが付いていて、「ここをクライアント固有のマッピングに変えてください」と案内されます。
エンジニアは TODO を埋めるだけで、新しいクライアント向けエージェントが完成します。
従来は、
既存エージェントをコピー
ファイル名を書き換え
import 文を修正
といったツールを自作していました。それが今では、コマンド一つ＋ TODO の穴埋めだけで完了します。
3. エージェントの不具合を AI がブラウザを見て修正する
私たちのエージェントの一部は、Playwright を使ってブラウザ操作を行います。
労務管理ソフトの画面を開き、そこに直接データを自動入力します。
しかし、この「ブラウザ操作」は不安定になりがちです。
例えば、
ボタンの位置が変わる
ローディング中に処理が走る
といった理由でエラーが発生し、リトライが必要になることがあります。
従来の修正フローは次の通りでした。
エンジニアがエラーログを読む
該当する画面をエンジニアがブラウザで開いて確認する
エンジニアが HTML 構造を調べて、コードを修正する
動かして確認→ダメならやり直し
場合によっては数時間がかかる作業です。
そこで採用したのが Chrome DevTools MCP です。
ご存知の通り、MCP（Model Context Protocol）は AI に外部ツールを接続する仕組みです。
Chrome DevTools MCP を使うと、Claude Code が直接ブラウザの画面（DOM）を確認できます。
例えば、
スクリーンショットを撮る
HTML 要素をクリックする
フォームに値を入力する
といった操作を、AI が自分の判断で実行できます。
私たちは Dev Container の中で Claude Code を動かしています。
AI が直接 PC を操作すると、想定外の破壊的変更や影響が発生する可能性があります。そのため、AI が動く環境をコンテナ内に隔離し、影響範囲を限定した上で AI に自由に作業させる構成にしています。
一方、ブラウザはホスト PC（Mac）で動かしています。
Dev Container からホスト PC の Chrome に接続することで、AI が手元のブラウザを操作できるようにしています。
この仕組みにより、不具合修正のフローは次のように変わりました。
エンジニアが Claude Code にエラー内容を伝える
AI が自分でブラウザを開いて画面を確認する（ログイン認証は人が行う）
AI が HTML 構造を分析し、コードを修正する
修正後の動作確認も AI が行う
エンジニアは「ここに問題がありそう」と伝えるだけ。
あとは AI が自分の「目」（スクリーンショット）で確認しながら修正します。
AI に任せるための「仕込み」がエンジニアの仕事になる
ここまで紹介した取り組みに共通しているのは、AI が動ける仕組みを整えるというエンジニアの役割の変化です。
Skills で AI に作業手順を教える
パッケージ設計で AI が読み取れる構造を作る
MCP で AI にブラウザという「目」を与える
コードを書く時間よりも AI が正しく動くための仕組みを設計する時間のほうが長くなっています。
一度この「仕込み」ができてしまえば、同じ作業を人が繰り返す必要はありません。
エージェントが並列で
コーディング
既存 AI エージェントのリファクタリング
提案資料作成
を行う。
その横で人間は
クライアントとのミーティング、デモ
AI エージェントの設計
を行う。
エージェントが「作業」を進め、人間は「意思決定」と「対話」に集中する。
そんな働き方になってきました。
さらに今後は、エンジニアリングだけでなく GTM（Go-To-Market）と呼ばれる
メール送信
リード管理
商談
導入支援
顧客管理
といった実務オペレーションまでを少人数で回せるようになると考えています。
これからは、エンジニアが営業・マーケティング・開発の境界を埋めることができます。AI エージェントは説明では売れません。デモが必要です。なぜなら、実際に動く姿を見ないとイメージできないからです。
正直、最初は『営業資料をエンジニアがやるべきか？』という葛藤もありました。しかし、AI が 3秒で叩き台を作るのを見た瞬間、その境界線は無意味だと悟りました。
AI エージェントで社労士事務所の業務を自動化するプロダクトを作りながら、GTM プロセスそのものも AI で自動化する。
この入れ子構造がいまの開発の面白さだと感じています。
こうした AI エージェントの開発や仕組みづくりに取り組んでいる私たちのチームでは、ともに挑戦してくれる AI エンジニアを募集しています。興味を持っていただけた方は、ぜひ募集要項もチェックしてみてください。
