資料DL 無料相談 →

AI駆動開発ガイド｜コード生成・テスト自動化・ツール選定と体制設計

  • 2026年3月11日
  • 最終更新: 2026年10月20日
ai-driven-dev
この記事の結論

AI駆動開発は、コード生成ツールを導入するだけでは成果につながりません。AIに下書きを任せ、人が設計・判断・レビューに集中できる仕組みをつくることが核心です。

ブログ目次


AI駆動開発は、コード生成ツールを導入するだけでは成果につながりません。AIに下書きを任せ、人が設計・判断・レビューに集中できる仕組みをつくることが核心です。

本記事は2026年8月時点の情報です。

「GitHub Copilotを入れてみたものの、補完が便利になった以上の変化がない」「非エンジニアがAIで作ったツールが、誰も中身を説明できないまま業務に組み込まれている」「テスト仕様をスプレッドシートで管理していて、コードの変更に追いつかない」——AI駆動開発に取り組み始めると、こうした壁に当たるケースがあります。

AI駆動開発とは、AIをソフトウェア開発のあらゆるフェーズに組み込み、コード生成・レビュー・テスト自動化・ドキュメント生成を加速させる開発手法です。エンジニアだけでなく、非エンジニアがAIでMVPを作るケースもあり、開発の民主化という観点でも注目されています。

この記事は、AI活用カテゴリ「AI駆動開発」のガイドページです。各記事は、StartLinkが実務経験をもとに執筆しています。 このカテゴリでは、実務で使える知識を体系的にまとめています。


この記事でわかること

AI駆動開発を自社の開発や業務改善に取り入れたいエンジニア・事業担当者に向けて、全体像と進め方を整理しています。AI駆動開発は「試してみた」段階を超え、現場の開発プロセスに定着しつつあるため、どのツールから始めるか、どのフローに組み込むかを判断する材料としてお使いください。

  • AI駆動開発と従来開発の違い — 工程ごとに何がAIに置き換わり、人の役割がどう変わるのかを比較表で整理します。
  • 主要ツールの特徴と選び方 — Claude Code・GitHub Copilot・Cursorなどを、補完型・AI統合IDE型・エージェント型の3タイプに分けて選定の判断軸を示します。
  • バイブコーディングと非エンジニアの開発 — 自然言語でアプリを作る手順と、非エンジニアが作ってよい範囲・避けたい範囲を解説します。
  • 品質を保つレビュー・テストの仕組み — AIコードレビューとテスト自動化を組み合わせ、チームで引き継げる形にする方法をまとめます。
  • CRM連携API開発とAIエージェント（MCP・A2A） — HubSpot APIを使った連携開発の進め方と、自律型AIに任せる範囲の決め方を紹介します。

AI駆動開発とは——従来開発との違い

AI駆動開発は、特定のツールの名前ではなく、開発工程の組み立て方を指す言葉です。コードを書く、テストを書く、ドキュメントを整えるといった作業の下書きをAIが担い、人は要件の整理と判断に時間を使います。まずは従来開発と比べて、何が入れ替わるのかを整理します。

工程ごとに何が置き換わるか

従来開発では、設計から実装、テスト、ドキュメントまでを人が手で進めるのが基本でした。AI駆動開発では、それぞれの工程でAIが最初の案を出し、人がそれを評価・修正する流れに変わります。

比較軸 AI駆動開発 従来開発
コード生成 AIが下書き・補完 手書きが基本
テスト作成 AIが自動生成 手動で記述
ドキュメント AIが自動生成 別途作成
必要スキル 設計・判断力 全工程の実装力
開発速度 工程や体制によって短縮できるケースがある 標準速度

この表で押さえておきたいのは「必要スキル」の行です。AIが下書きを担う範囲が広がるほど、人に求められるのは全工程を手で実装する力より、何を作るかを決め、AIの出力が要件を満たしているかを判断する力になります。「開発速度」の行は、どの工程にAIを入れるか、レビューの体制が整っているかによって結果が変わるため、本記事では数値で約束できるものではないと整理します。

人の役割は「書く」から「決めて確かめる」へ

AIに任せる作業と人が判断する作業を分けておくと、導入後に「どこまでAIに頼ってよいのか」で迷う場面が減ります。本記事では、次のように役割を分けることをおすすめします。

AIに任せやすい作業 人が判断する作業
定型的な実装の下書き 要件の定義と優先順位づけ
テストケースの洗い出し 何を「正しい動き」とみなすかの基準
既存コードの要約・説明 設計方針と技術選定
ドキュメントの下書き 本番環境への反映・リリースの判断
リファクタリング案の提示 顧客データや権限に関わる変更の承認

線引きに迷ったときは、「間違えたときにすぐ戻せるか」で判断するとわかりやすいです。手元で書き直せば済む作業はAIに任せ、戻すのに手間がかかる作業や社外・顧客に影響が出る作業は人が承認する、という基準を最初にチームで共有しておくと運用が安定します。

「ツールを入れたのに変わらない」原因

補完ツールを入れても成果が見えない場合、多くはツールではなく工程の側に原因があります。仕様が担当者の頭の中やスプレッドシートに散らばっていると、AIに渡せる情報が少なく、出力の質も上がりません。

次の3点を見直してみてください。仕様がリポジトリ内の文書として書かれているか、テストコードが存在するか、AIの出力を誰がレビューするか決まっているか。仕様が文書になっていなければ、まず仕様をコードと同じ場所に移すところから始めます。テストがなければ、次章以降で紹介するテスト生成から着手し、レビュー担当が決まっていなければ、ツールを広げる前に担当を決めておくのがおすすめです。


主要ツールの特徴と選び方（Claude Code・GitHub Copilot・Cursor）

AI駆動開発のツールは数が多く、名前だけを並べて比べると選びにくくなります。本記事では、AIが関わる範囲の広さで「補完型」「AI統合IDE型」「エージェント型」の3タイプに分けて整理します。

3つのタイプで整理する

補完型は、普段使っているエディタの中で、書きかけのコードの続きをAIが提案するタイプです。GitHub Copilotがこの使い方の代表で、日々の実装の手間を減らす用途に向いています。

AI統合IDE型は、エディタそのものにAIが組み込まれ、ファイルをまたぐ修正や質問を対話で進められるタイプです。Cursorがこのタイプにあたり、詳しくは「Cursor AIとは？」の記事で全機能を解説しています。

エージェント型は、指示を受けたAIが複数のファイルを読み、編集し、テストを実行して修正するところまでを一連で進めるタイプです。Claude Codeがこの使い方の代表です。WindsurfやReplit Agentを含めた比較は、ツール比較の記事にまとめています。

状況別の選定表

どのタイプが向くかは、「AIにどこまで任せたいか」と「誰が使うか」で決まります。

状況 向くタイプ 選ぶ理由
今のエディタのまま日々の実装を速くしたい 補完型（GitHub Copilotなど） 開発環境を変えずに導入できる
ファイルをまたぐ修正を対話で進めたい AI統合IDE型（Cursorなど） エディタ上で相談と修正を往復できる
実装からテスト実行・修正まで一連で任せたい エージェント型（Claude Codeなど） 複数の作業をまとめて依頼できる
コードを書かずに業務アプリを作りたい ノーコードAI（Dify・Zapierなど） 画面操作で連携や処理を組める

選定時に見る項目と判断の分かれ目

ツールの機能比較より先に、自社の前提条件を3つ洗い出しておくと選定が早く進みます。

1つ目は、社内のコードやデータを外部のAIサービスに送ってよいかという情報の扱いルールです。ルールが決まっていない場合は、社外秘を含まない検証用のリポジトリで試し、その間にルールを決めます。2つ目は、開発者が使っているエディタ環境です。チームのエディタが揃っているなら補完型から、ばらばらならエディタに依存しにくいエージェント型から試すのも一つの方法です。3つ目は、AIの出力をレビューできる人がいるかどうかで、レビュー担当がいない段階では、AIに任せる範囲が広いエージェント型を本番の開発に使うのは控えたほうがよいと考えています。

なお、Copilot と Cursor のように役割の違うツールを併用する選択肢もあります。最初から複数を入れるより、1つのツールで「どの工程で効いたか」を記録し、足りない部分を別のタイプで補う順番をおすすめします。


バイブコーディングと非エンジニアによる開発

バイブコーディング（Vibe Coding）は、AIに自然言語で意図を伝え、動くものを見ながら方向を修正していく開発スタイルです。プログラミング経験がなくても業務ツールを形にできる一方で、作ったものを誰が保守するのかという課題も生まれます。ここでは、手順と使ってよい範囲を分けて整理します。

バイブコーディングの進め方

バイブコーディングでは、コードの書き方を指示するのではなく、「何を入力して、何が出てくればよいか」を言葉で伝えます。次の順番で進めると、途中で迷子になりにくくなります。

  1. 目的と入出力を文章で書く — 「誰が、何のデータを入れて、何が表示されればよいか」を数行で書きます。ここが書けたら次に進みます。
  2. 最小の機能だけ作らせて動かす — 画面1つ、処理1つなど、小さな単位で作らせます。実際に動いて、入出力が想定どおりなら次へ進みます。
  3. 気になる点を言葉で直す — 「この項目は必須にしてほしい」「エラー時はメッセージを出してほしい」のように、1回に1つずつ修正を依頼します。
  4. 動いた状態を保存する — 区切りごとにバージョン管理に記録しておくと、修正で壊れたときに前の状態へ戻れます。

手順4を飛ばすと、AIへの修正依頼を重ねるうちに元の動く状態がわからなくなるケースがあります。動いたら保存、を1つの区切りにしておくのがポイントになってきます。

非エンジニアが作ってよい範囲・避けたい範囲

スプレッドシートの手作業を減らすツールなど、非エンジニアがAIで作れる範囲は広がっています。ただし、どんな業務にも向くわけではありません。

作ってよい範囲の例 避けたい範囲の例
自分やチームの集計作業の自動化 顧客データを書き換える処理
社内向けの簡易な入力画面 決済や請求に関わる処理
試作品（MVP）としての検証用アプリ 複数部署が日常的に依存する基幹的な仕組み

判断の分かれ目は「止まったときに誰が困るか」です。困るのが作った本人だけなら、非エンジニアが作って運用して構いません。他部署や顧客が困るなら、エンジニアがレビューして引き継ぐ前提で作ります。引き継ぐときに迷わないよう、手順1で書いた目的と入出力の文章をツールと一緒に残しておくと、作った人が異動しても仕組みとして回り続けます。

ノーコードAIとの使い分け

DifyやZapierのようなノーコードAIは、既存のサービス同士をつないだり、AIの処理を画面操作で組み立てたりするのに向いています。バイブコーディングは、独自の画面やロジックを持つアプリを作りたいときに向いています。

使い分けに迷ったら、やりたい処理が「既存サービスの連携だけで完結するか」を見てください。完結するならノーコードAIで組み、独自の画面や複雑な判定ロジックが入るならバイブコーディングを選びます。ノーコードで始めて限界が見えた部分だけをコードに置き換える、という段階的な進め方も有効です。


AIコードレビューとテスト自動化で品質を保つ

AIが書くコードの量が増えるほど、品質をどう担保するかが課題になります。レビューとテストを人の注意力に頼るのではなく、AIと仕組みで支える形にしておくと、メンバーが入れ替わっても品質を保ちやすくなります。

AIに任せるレビュー観点と人が見る観点

AIコードレビューは、すべてをAIに見せるのではなく、観点を分けると効果が出やすくなります。

観点 担当 進め方
命名・書式・重複コード AI 指摘をそのまま反映してよい
想定しうるエラー処理の漏れ AI＋人 AIが候補を挙げ、人が要否を決める
要件どおりに動くか 人 仕様書・テストと照らして判断する
権限・個人情報の扱い 人 変更があれば承認者を決めて確認する

AIの指摘は数が多くなりがちです。「書式系はAIの指摘をそのまま反映」「要件と権限は人が判断」と担当を決めておくと、レビューが指摘の確認作業だけで終わる状態を避けられます。

テストを先に用意する手順

テスト自動化では、実装より先に「期待する振る舞い」を決めておくと、AIの出力を評価しやすくなります。次の順で進めます。

  1. 期待する振る舞いを文章で列挙する — 正常系だけでなく、空の入力や想定外の値が来たときの動きも書きます。
  2. AIにテストコードへ変換させる — 文章のリストをもとにテストを生成させます。
  3. テストの意図を人が読む — 生成されたテストが、手順1の文章と1対1で対応しているかを見ます。対応していれば次へ進みます。
  4. 実装をAIに依頼する — テストが通るまで実装と修正を繰り返させます。
  5. 変更のたびにテストを自動実行する — リポジトリへの変更時にテストが走るよう設定しておきます。

テスト仕様をスプレッドシートで別管理していると、コードの変更に合わせて手で更新する手間が残り、いずれ内容がずれていきます。手順1の文章とテストコードをリポジトリで一緒に管理すれば、仕様とテストが同じ場所で更新されます。

チームのルールをファイルに残す

AIへの指示が担当者ごとにばらばらだと、出力の品質も人によってばらつきます。コーディング規約やテストの書き方など、毎回伝えるルールはファイルに書いてリポジトリに置いておくのがおすすめです。

例えばClaude Codeでは、プロジェクトのルートに置いた CLAUDE.md がプロジェクトのメモリとして読み込まれ、チームで共有できます（出典：Manage Claude's memory）。規約、使ってよいライブラリ、テストの実行方法などをここに書いておけば、新しく参加したメンバーも同じ前提でAIに依頼できます。レビューで同じ指摘が繰り返し出たら、その内容をこのファイルに追記していく運用にすると、指摘が仕組みとして蓄積されていきます。


CRM連携API開発にAIを活用する（HubSpot API）

AI駆動開発が業務への効果を出しやすい領域の一つが、CRMと他システムをつなぐAPI連携の開発です。API仕様の調査や定型的な実装はAIが得意とする作業で、人は「どのデータを、どの業務の流れでつなぐか」の設計に集中できます。

全体フローのどこをつなぐかを先に決める

連携開発で最初に決めたいのは、コードの書き方ではなく、顧客データの流れのどこをつなぐかです。

例えば、Webフォームや外部ツールで得た情報をコンタクトとして登録する連携、取引が受注になったタイミングで外部の請求・会計システムへ情報を渡す連携などが考えられます。どちらも、これまでスプレッドシートに書き出して手で転記していた作業を置き換えるものです。連携先ごとにデータが分散すると差分が起きやすいため、「どのデータの正をどのシステムに置くか」を先に決め、AIへの指示文にもその前提を書いておくと、実装の方向がぶれにくくなります。

認証と権限の設計

APIで連携する仕組みには、どのデータを読めて、どのデータを書き換えられるかという権限の設計が欠かせません。HubSpotのプライベートアプリでは、単一のHubSpotアカウントのデータにAPIでアクセスするためのアクセストークンが発行され、アプリに許可するスコープ（権限の範囲）を選んで設定できます（出典：Private apps）。

スコープは、連携の目的から逆算して決めます。外部へデータを渡すだけの連携なら読み取りのスコープだけを選び、HubSpot側のレコードを更新する連携なら、更新が必要なオブジェクトに限って書き込みを許可します。AIに実装を依頼するときも、選んだスコープを指示文に明記しておくと、権限外のAPIを呼ぶコードが生成された時点で気づけます。

AIと進める開発手順と戻り先

連携開発は、段階ごとに「次へ進む条件」を決めておくと、問題が起きたときにどこへ戻ればよいかが明確になります。

段階 AIの役割 人が見るポイント 次へ進む条件
要件整理 業務フローの文章から連携仕様の案を作る 対象オブジェクトとデータの正の置き場所 連携の起点・対象・頻度が決まっている
API仕様の調査 必要なエンドポイントとパラメータを整理する 公式ドキュメントとの食い違い 使うAPIとスコープが確定している
実装 コードとテストを生成する エラー時の動き・再実行時の重複 テストが通っている
検証用アカウントでの確認 ログの読み解きと修正案を出す 実データに近い条件での結果 想定どおりにレコードが作成・更新される
本番反映 手順書の下書きを作る 反映のタイミングと切り戻し方法 担当者が切り戻し手順を把握している

検証で想定外の結果が出たときは、実装に戻る前に「要件整理」の段階まで遡って、前提がずれていないかを見直すと遠回りを防げます。

AIがCRMデータを更新するときの考え方

開発したプログラムだけでなく、HubSpot上のAI機能であるBreezeでも、会話の指示でCRMのレコードを更新できます。次の画面は、Breezeが関連する取引をまとめて「お見送り」に更新した結果を表示したものです。

Breezeが関連取引4件を一括で「お見送り」更新した結果

CRM上の更新は、そのまま集計やレポートの数字に影響します。そのため、AIによる一括更新は、対象レコードの条件を人が確認してから実行する運用をおすすめします。対象が少なく条件が明確なものはAIに任せ、受注・失注の判定のように売上の数字に関わる項目は担当者が判断する、と分けておくとレポートの信頼性を保てます。


AIエージェント（MCP・A2A）を使った自律型開発

AIエージェントは、指示を受けてタスクを分解し、ツールを使いながら作業を進めるAIです。コーディング作業の一部を自律的なAIに委ねられるようになってきた一方で、任せる範囲の線引きがこれまで以上に重要になります。

MCPとA2Aの位置づけ

MCP（Model Context Protocol）は、AIアプリケーションに外部のデータやツールを接続する方法を標準化するオープンなプロトコルです（出典：Model Context Protocol: Introduction）。MCPを使うと、エージェントが社内のドキュメントや業務システムの情報を参照しながら作業できるようになります。

開発の現場では、まずMCPで「エージェントが参照できる情報源」を増やし、その後に複数エージェントの連携を検討する順番が進めやすいです。具体的な作り方は「AIエージェント開発入門」の記事で解説しています。

任せる範囲を段階で決める

エージェントに任せる範囲は、一度に広げず段階的に広げていくのがおすすめです。

段階 エージェントに任せること 人の関わり方
提案のみ 調査・設計案・修正案の作成 内容を読んで採否を決める
承認後に実行 ファイル編集・テスト実行 実行前に差分を確認して承認する
限定範囲で自動実行 検証環境での修正の繰り返し 結果のレポートを確認する

外部へのメール送信、本番環境への反映、顧客データの書き換えは、どの段階でも人の承認を挟む設計にしておくことをおすすめします。ただし、承認の手間が大きすぎると形だけの承認になりがちです。承認対象を「戻せない操作」に絞り、それ以外は結果の確認で済ませる形にすると、安全性と作業の速さを両立しやすくなります。

ガイドラインで振る舞いを言葉にする

エージェントの振る舞いは、指示文やガイドラインでどれだけ具体的に言葉にできるかで変わります。

次の画面は、Breezeカスタマーエージェントでトーンや応答方針を定めるガイドライン設定画面です。

Breezeカスタマーエージェント ガイドライン設定画面

開発用のエージェントでも考え方は同じです。「丁寧語で書く」「社外向けの文章では敬語のルールを守る」「判断に迷ったら作業を止めて質問する」といった振る舞いを明文化しておくと、出力のばらつきが減ります。ガイドラインを書いたら数回の作業で試し、意図とずれた出力が出たら、その場面をガイドラインに追記する流れで育てていきます。


導入の進め方——スモールスタートと体制設計

AI駆動開発は、全社で一気に始めるより、効果が見えやすい小さなテーマから始めて段階的に広げるほうが定着しやすいと考えています。ここでは、段階の分け方、最初のテーマの選び方、PoC（概念実証）で止まらないための評価の仕方を整理します。

段階的な広げ方

本記事では、AI駆動開発の導入を次の4段階で整理します。

段階 主な取り組み 次へ進む目安
1. 個人で試す 補完型ツールで日々の実装を支援 どの作業で効いたかを言語化できている
2. チームで品質を支える AIレビュー・テスト生成・ルールファイルの整備 レビューの担当と観点が決まっている
3. 業務システムとつなぐ CRM連携などのAPI開発にAIを活用 権限設計と切り戻し手順が整っている
4. エージェントに一部を委ねる 承認付きで自律的な作業を任せる 承認対象と任せる範囲が文書になっている

段階を飛ばすと、品質を支える仕組みがないまま開発量だけが増え、手戻りが積み上がるケースがあります。各段階の「次へ進む目安」を満たしてから次へ進む、という順番を守るのがポイントになってきます。

最初のテーマの選び方

最初のテーマは、「失敗しても影響が小さい」「繰り返し発生している」「成果が目に見える」の3つを満たすものから選ぶのがおすすめです。例えば、毎月スプレッドシートで手作業している集計や、問い合わせ内容の転記作業などがこれにあたります。

候補が複数ある場合は、影響範囲が社内に閉じているものを優先します。顧客や他部署に影響するテーマは、段階2までの仕組みが整ってから取り組むと、トラブル時の戻し方まで含めて落ち着いて進められます。

PoC止まりを防ぐ評価と体制

AI駆動開発の取り組みが検証だけで終わってしまう原因の一つは、導入の可否だけを議論し、評価指標と運用体制を決めていないことです。始める前に、何をもって「効果があった」とするかを決めておきます。

指標は、開発の所要日数、レビューでの差し戻し回数、リリース後の手戻り件数など、自社で記録できるものから選びます。導入前の状態を記録しておかないと比較ができないため、テーマを決めた時点で現状の数字を残しておいてください。あわせて、AIのルールファイルを誰が更新するか、ツールの利用範囲を誰が判断するかを決めておくと、担当者が変わっても取り組みが続きます。どの指標を重視し、どこまでAIに任せるかは、開発の規模や体制によって変わるため、自社の開発フローに合わせて調整していくのが現実的です。


AI駆動開発カテゴリの記事一覧

このカテゴリでは、ここまで紹介した各テーマを個別の記事で詳しく解説しています。自社の状況に近いテーマから読み進めてください。

全体像・入門

ツールの使い方・比較

非エンジニア・ノーコード

品質・API連携・エージェント

上位カテゴリ

AI活用 — AI・エージェント・業務自動化 — AIのビジネス活用、AIエージェント運用、Claude Code実践、MCP連携、AI組織変革まで。

HubSpot - AI Studio トップ — StartLinkブログのトップページ


よくある質問

Q1. AI駆動開発は何から読み始めるべきですか？

立場によって入口を変えるのがおすすめです。開発に携わるエンジニアの方は「Claude Codeの使い方」や「GitHub Copilot活用法」から、プログラミング経験のない方は「非エンジニアでもAIで業務ツールが作れる」から読み始めると、すぐに手を動かせます。全体像を先に押さえたい方は「AI駆動開発とは？」で考え方を把握してから、個別のツール記事に進んでください。

Q2. 非エンジニアがAIで作ったツールを業務で使っても大丈夫ですか？

止まったときに困るのが作った本人やチーム内に限られるツールであれば、業務で使って問題ないと考えています。顧客データの書き換えや請求に関わる処理、他部署が日常的に依存する仕組みは、エンジニアのレビューを経てから運用に乗せるのがおすすめです。どちらの場合も、目的と入出力を書いた文章をツールと一緒に残しておくと、作った人が不在でも引き継げます。

Q3. AIが生成したコードの品質はどう担保すればよいですか？

実装より先に期待する振る舞いを文章で書き、それをテストコードに変換してから実装をAIに依頼する進め方が有効です。レビューは、書式や重複といった観点をAIに任せ、要件どおりに動くかや権限の扱いは人が判断する、と分担を決めておきます。繰り返し出る指摘は CLAUDE.md のようなルールファイルに追記し、チーム全体の前提として蓄積していきます。

Q4. HubSpotとの連携開発では、AIをどこまで使えますか？

API仕様の調査、定型的な実装、テストコードの作成、エラーログの読み解きなどは、AIに任せやすい作業です。一方で、どのデータの正をどのシステムに置くか、プライベートアプリにどのスコープを許可するか、本番反映をいつ行うかは人が決める領域です。要件整理から本番反映までの段階ごとに次へ進む条件を決めておくと、AIを使いながらも手戻りを抑えられます。

Q5. 関連カテゴリもあわせて読むべきですか？

AI駆動開発の取り組みを組織に広げる段階では、「AI経営・戦略」「AI実務活用」「AI組織変革」もあわせて読むと、開発以外の隣接テーマまで整理できます。カテゴリをまたいで読むことで、導入・運用・組織展開のつながりを把握しやすくなります。


まとめ

  • AI駆動開発の価値は、AIに下書きを任せて人が設計・判断・レビューに集中できる環境をつくることにあり、コード生成はそのための手段です。
  • ツールは補完型（GitHub Copilotなど）・AI統合IDE型（Cursorなど）・エージェント型（Claude Codeなど）の3タイプで整理し、AIに任せたい範囲とレビュー体制に合わせて選びます。
  • バイブコーディングやノーコードAIで非エンジニアも業務ツールを作れるようになりましたが、「止まったときに誰が困るか」で作ってよい範囲を分けます。
  • 品質は、テストを先に用意する手順と、チームのルールをファイルに残す仕組みで支えます。
  • HubSpotとのAPI連携では、コンタクトから取引、顧客、請求までのどこをつなぐかと権限の範囲を先に決め、AIエージェントには承認付きで段階的に作業を委ねます。

まずは、社内に閉じた小さな業務改善テーマを1つ選ぶところから始めてみてください。次の3ステップで進めると、検証で終わらずに次の段階へつなげられます。

  1. スプレッドシートの手作業など、繰り返し発生している作業を1つ選び、現在の所要時間や手戻りの状況を記録する
  2. 補完型またはエージェント型のツールを1つ選び、期待する振る舞いを文章で書いてから、テストと実装をAIに依頼する
  3. 結果を記録した指標と比べ、レビューで繰り返し出た指摘をルールファイルに追記してから、チームへの展開を検討する

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。


あわせて読みたい

記事の内容を、そのまま実務に落とし込みたい方向け

HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。

サービス概要を見る 無料で相談する

次に読む

Claude Codeのfast mode（/fast）｜対応モデル・料金・使いどころの判断基準

Claude Code agent viewの使い方｜全セッションを1画面で管理

Claude Codeの/goalコマンド｜完了条件でAIを自律実行させる方法

記事の内容を、そのまま実務に落とし込みたい方向け

無料で相談する 資料をダウンロード

株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。

関連キーワード:
AI 生成AI

サービス資料を無料DL

著者情報

7-1

今枝 / Imaeda

株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。