# AIコーディングエージェントとノーコードの境界線

URL: https://trycompass.co/ja/journal/ai-coding-agent-vs-nocode-builder
Type: blog
Locale: ja
Published: 2026-07-03
Updated: 2026-07-03

---

> AIコーディングエージェントとノーコード型ビルダーは別物だ。何を任せ、何を任せてはいけないかを実例で見る。

グロースチームのチケットには今週も三件並ぶ。LPのAB変数テスト、頻繁に壊れるCRM連携、誰も作りたがらないダッシュボード。Cursor、Claude Code、GitHub CopilotのエージェントモードのようなAIコーディングエージェントなら、このうち二件は午後だけで動くコードに仕上がる。三件目が厄介なのは、キャンペーンが終わった後に何が起きるかにかかっているからだ。本稿は、AIコーディングエージェントが本来担うべき仕事の範囲と、ノーコード型のエージェントビルダーとの違い、両者を混同したときに起きる実害を整理する。

## AIコーディングエージェントとノーコード型ビルダーは別物

「AIコーディングエージェント」で検索すると、性質の異なる二つのカテゴリが同じ検索結果に混在して並ぶ。Cursor、Claude Code、GitHub Copilotのエージェントモード、Devinは実際のコードを書いて実行する。リポジトリを開き、テストを走らせ、変更をコミットする。Gumloop、Lindy、Metaflowはその代わりにワークフローを組む。ドラッグ&ドロップの画面の裏でAPI呼び出しを連結するだけで、リポジトリという概念自体が存在しない。

どちらもマーケティングやグロースチーム向けに「エンジニアを介さず自分で自動化を組める」と売り込まれる。だが、ソースコード管理に触れるのは片方だけであり、この違いが、何かが壊れたときに誰が直すのかを決めている。

ノーコード型のエージェントビルダーで組んだワークフローは、自社のサンドボックスの中で失敗する。壊れたステップ、再実行、ベンダーへのサポートチケット。一方、AIコーディングエージェントが書き、あなた自身がデプロイしたスクリプトは、置いた場所ならどこでも失敗しうる。スケジュール実行の関数、有料ツールが以前担っていたWebhook、2024年以降SSL証明書が更新されていない共有サーバー上のcronジョブ。Compassは、キャンペーンの配信ルートを、当直のエンジニアがデプロイを見る目線と同じ発想で組む。何が最初に壊れ、何がそれを受け止めるか。

グロースチームがワークフロービルダーではなくコーディングエージェントに頼る典型例が二つある。広告プラットフォームのネイティブなタグ付けが取りこぼすエッジケースを処理するUTMパーサー、あるいはBIチームへのチケットを待たずにデータウェアハウスからアトリビューション数値を直接引くSlackコマンド。どちらもビジネスロジックは5行程度で、その周りに認証まわりの定型コードが30行ほどついてくる。エージェントが得意で、人間が二度書きしたがらない領域そのものだ。

Wegicは両カテゴリの中間に位置する。チャットでページや小規模サイトの要件を伝えると、テンプレートに当てはめるのではなく実際のコードを書いて構築する。ターミナルを開かずにコーディングエージェントの成果物だけを得たいチームには、純粋なワークフロービルダーより近い選択肢になる。

![スタンディングデスクでコードエディタとキャンペーン分析画面を見るマーケティングオペレーション担当者](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/trycompass/2026-07/dde15a-inline1.webp)

## グロースチームが実際にコーディングエージェントへ振る仕事

この分野への移行を追ってきたチームに共通するパターンは三つ。BIツールがネイティブに接続しない二つのAPIを繋ぐ社内ダッシュボード、放っておけばアナリストの午後を丸ごと使うスポットのデータ抽出、プラットフォームの仕様変更で壊れたリダイレクトチェーン越しにトラッキングピクセルを発火させ続ける繋ぎ用スクリプト。

どれも「マーケティングスタック全部を作る」話ではない。範囲が区切られ、担当者が一人に定まり、壊れたときに大きな音を立てて壊れる。この最後の点は見た目以上に重要だ。アトリビューションスクリプトの静かな失敗は、スクリプトが存在しないより悪い。チームはすでに間違った数字をもとに意思決定を続けてしまう。

この流れに対するガートナー社の見立ては率直だ。[2026年末までに技術プロダクトとサービスの80%が従来のIT部門以外の人材によって作られる](https://www.bluerock.io/post/rise-of-the-citizen-developer)という。これはAIエージェントに限定したマーケティング統計ではなく、誰がソフトウェアを書く時代なのかという構造的な予測だ。グロースマーケターがClaude CodeにWebhookの修正をプロンプトで頼む時点で、すでにこの数字の内側にいる。

「アトリビューションモデルを作ってほしい」という、タスクではなく職務記述書のような依頼は避ける。AIコーディングエージェントは二つのテーブルを結合するスクリプトを書ける。だが、アトリビューションの方法論そのものを決める役目は負わせるべきではない。

もう一つ、規模は小さいがチームが探索を始めると必ず出てくるパターンがある。従量課金のノーコード自動化基盤が、いつの間にかマーテックの予算で最も高い項目になっていたとき、脆いZapierの連鎖を1本のスクリプトに書き換える動きだ。コーディングエージェントはオーケストレーションのロジックそのものを置き換えるのではなく、5つの条件分岐を回すためのベンダー手数料を置き換えるだけだ。

## 被害範囲(ブラスト・レディウス)が現実になる場所

「とにかくプロンプトで頼めばいい」というアドバイスが飛ばしがちな部分がここだ。リスクの本体はコーディングエージェントそのものではない。そのエージェントが触れる対象こそがリスクになる。

広告プラットフォームの読み取り専用APIからキャンペーン費用を読むだけのスクリプトは、賭け金が低い。最悪でも、役員会前に誰かがダブルチェックするレポート内の数字が一つ間違う程度だ。一方、CRMに書き込む、APIキーをローテーションする、メール配信基盤へセグメントを直接プッシュするスクリプトは、まったく別物だ。エージェントがフィールド名を勘違いしたり、レート制限を見落としたりすれば、その間違いは翌朝営業チームが電話をかけている本番データにそのまま着地する。

真っ先に見落とされるのが認証情報だ。自分のスクリプトをテストするためにCRMのAPIキーを必要とするエージェントは、そのキーを平気でコミットされる設定ファイルに貼り付けたり、プロジェクトより長生きするチャットログに残したりする。エージェントが不正に振る舞っているわけではない。頼まれた通りに動いているだけだ。ガードレールは、セキュリティレビューで見つかった後ではなく、最初のテスト実行の前に、そのキーをどこに置くかを人間が決めることでしか成立しない。

導入データも、この実害がどこで起きているかを裏付ける。マーケティングとSDR・アウトバウンド部門では[AIエージェントの導入率が約41%に達し、投資回収の中央値は3.4か月と計測対象の全職種で最速](https://www.digitalapplied.com/blog/ai-agent-adoption-2026-enterprise-data-points)で、マーケティングオペレーション担当者はスクリプト稼働後に週あたり約5.4時間を浮かせていると報告する。投資回収の速さはビジネスケースとして好材料だ。だが、ローンチ週にスクリプトが静かに止まったとき誰が対応するのかは、この数字には何も書いていない。

対策は誰も読まないポリシー文書ではない。AIコーディングエージェントが書いたスクリプトが読み取り専用フィード以外の何かに触れる前に、三つの問いに一言ずつ答えられるかどうかだ。キャンペーン終了後の担当者は誰か、どこで動くか(「自分のノートPC」は不可)、火曜の深夜2時に止まったら何が起きるか。この三つに一言で答えられないなら、答えが出るまでスクリプトはサンドボックスに留めておく。

顧客データ、稼働中のキャンペーン予算、後からコンプライアンス審査が入りそうな対象にスクリプトが触れるなら、この15分の追加設定はかけるだけの価値がある。レポートを出したら捨てる一回きりの抽出であれば、この手順は省いていい。

![手描きのワークフロー図が書かれたノートの隣でキーボードを打つ手のクローズアップ](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/trycompass/2026-07/39e4a6-inline2.webp)

## みんなが引用する「市民開発者」統計と、そこで抜け落ちているもの

ガートナーの80%という数字は、「AIがコーディングを民主化する」系の記事でお決まりのように引用されるが、その数字を使えるものにする注記が抜け落ちていることが多い。この数字は社内ツール、プロトタイプ、部門レベルのユーティリティを対象にしている。同じ期限までに本番のマーケティングインフラの80%が非エンジニアによって保守される、という意味ではない。

「グロースマーケターがAIコーディングエージェントで動くスクリプトを一本仕上げた」ことと、「そのスクリプトが会社が依存するインフラになった」ことの間には、実際には大きな溝がある。前者は今日もどこかで、日常的に起きている。後者に必要なものは昔から変わらない。バージョン管理、担当者、ロールバックの手段だ。エージェントがコードを書くことは、この要件をなくすのではなく、要件が問われるタイミングを前倒しするだけだ。壊れた後ではなく、動き出す前に。

市民開発者の数字は、「誰が何かを出荷できるようになったか」の描写として扱うべきで、「何を無人で走らせてよいか」の判定材料としては扱わない方がいい。

## 「とにかくダッシュボードを作らせろ」というアドバイスは飛ばす

「マーケティングでAIコーディングエージェントを使う方法」系の記事の多くは、最初の題材として社内ツール一式、つまりキャンペーン司令塔やレポート統合ダッシュボードから始めることを勧める。それは最初の一手としては間違っている。

実際に成果を出すチームは、もっと小さく始める。入力が一つ、出力が一つ、コードを毎日は書かなくても読める人がレビューする、そんなスクリプト一本から。ダッシュボードは10本のスクリプトがUIをまとった姿にすぎない。10本を繋いでインフラと呼ぶ前に、まず1本目を丁寧に仕上げる。

コーディングの話に入る前に、チームが議事録とフォローアップタスクの山に埋もれているなら、それは別の、もっと小さな問題であり、先に解決する価値がある。AI議事録エージェントなら、キャンペーンのコードに一切触れずにその問題を片付けられる。

## オーケストレーション済みのキャンペーンスタックにどう組み込むか

AIコーディングエージェントは関数を書く。オーケストレーション層は、その関数がいつ動くか、何が引き金になるか、メール・広告・CRMを横断して次に何が起きるかを決める。この二つを混同すると、誰にも配線されないまま優れたスクリプトがリポジトリに眠り、本来組み込まれるはずだったキャンペーンから一度も呼ばれないという結末になる。

Compassの立ち位置ははっきりしている。オーケストレーションは、リアルタイムのシグナルをもとにキャンペーンをチャネル横断でルーティングする層であって、そのチャネルが動かすコードを書く層ではない。両者は競合ではなく補完関係にある。コーディングエージェントが書いた、停滞したメールシーケンスを検知するスクリプトは、その日のうちに配信先を広告へ切り替える仕組みが下流にあって初めて役に立つ。次のスプリントではなく、その日に。

ローンチのコマース側を回すチームにとって、このルーティングの発想はマーケティングツールの外側にも及ぶ。独自の自動化層を持つストア基盤にも、エージェントが書くどんなスクリプトにも問うのと同じ質問を投げる必要がある。ローンチの最中に同期が失敗したとき、例外処理の担当者は誰か。

![ガラス張りの会議室でホワイトボードのラフなワークフロー図を囲む小規模なグロースチーム](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/trycompass/2026-07/4af113-inline3.webp)

## 今四半期、実際に何を任せるか

AIコーディングエージェントがグロースチームのスタックに席を得るのは、範囲が区切られ、担当者が明確で、壊れたときに大きな音を立てるタスクに対してだ。UTMパーサー、ウェアハウスからの抽出、Webhookの修正。アトリビューションの方法論を書く役目や、初日から本番のCRMデータに対して無人で動く役目には、まだ席がない。

誰かの午後を本当に浮かせる、いちばん小さなスクリプトから始める。壊れた後ではなく、出荷する前に担当者の名前を決める。より大きなキャンペーンの意思決定は、コーディングエージェントがたまたま最初に触れた場所ではなく、それを判断するために作られた層に通す。

四半期を終えたとき、この体制がうまく機能しているかを教えてくれる指標は三つ。無人稼働を続けているスクリプトの本数、そのうち人間が気づく前に静かに失敗した回数、気づいてから修理にかかった時間。三つ目の数字が縮み続けているなら、コーディングエージェントはスタックの中に自分の場所を勝ち取ったということだ。一つ目の数字が担当者を割り当てられる速度より早く増え続けているなら、それは効率化ではなく保守負債を積み上げている。針路は、その三つの数字が示す。

## FAQ

### AIコーディングエージェントとノーコードのワークフロービルダーは何が違うのか？

AIコーディングエージェントはリポジトリを開き実際のコードを書いて実行するのに対し、ノーコードのビルダーはドラッグ&ドロップの画面上でAPI呼び出しを連結するだけで、コードもリポジトリも存在しない。壊れたときに誰が直すかという責任の所在が根本的に異なる。

### マーケティングチームがAIコーディングエージェントに任せるべき仕事は何か？

UTMパーサーやデータウェアハウスからの直接抽出、壊れたトラッキングピクセルの修正など、範囲が区切られ担当者が一人に定まり、失敗したときに大きな音を立てるタスクが向いている。アトリビューションの方法論の決定など、判断そのものを委ねる仕事には向かない。

### ガートナーの「技術プロダクトの80%が非IT人材によって作られる」という予測は、マーケティングインフラにも当てはまるのか？

この予測は社内ツールやプロトタイプ、部門レベルのユーティリティを対象にしたもので、本番のマーケティングインフラの保守が非エンジニアに移るという意味ではない。混同して引用されることが多い点に注意が必要だ。

### AIコーディングエージェントが書いたスクリプトに、CRMの認証情報を持たせても安全か？

エージェント自体が不正を働くわけではないが、テスト用にAPIキーをコミットされる設定ファイルやチャットログに残してしまうリスクがある。キーをどこに置くかは、最初のテスト実行の前に人間が決めておく必要がある。

### コーディングエージェントとオーケストレーション層はどう役割分担するのか？

コーディングエージェントは個々の関数やスクリプトを書き、オーケストレーション層はそれをいつ・何をきっかけに動かし、メールや広告、CRMを横断して次に何を起こすかを決める。前者がコードを書き、後者がルーティングを判断する。

### 最初のAIコーディングエージェント活用プロジェクトとして何を選ぶべきか？

社内ダッシュボード一式のような大きな題材から始めるのは避ける。入力と出力が一つずつ明確な、小さなスクリプト一本を最初のレビュー対象に選ぶのが実際に成果へつながるやり方だ。