AIエージェントの内製・外注|自社開発と外部サービス活用の判断基準

  • 2026年3月10日
  • 最終更新: 2026年10月11日
この記事の結論

AIエージェントの内製と外注は、開発方法だけでなく、業務上の判断と運用責任を誰が担うかで比較します。自社に残す判断を特定し、外部サービスに任せられる処理を工程ごとに確かめることが出発点です。

ブログ目次


AIエージェントの内製と外注は、開発方法だけでなく、業務上の判断と運用責任を誰が担うかで比較します。自社に残す判断を特定し、外部サービスに任せられる処理を工程ごとに確かめることが出発点です。

「自社でどこまで開発すべきかわからない」「外部サービスが自社業務に合うか不安がある」「内製後の運用を続けられるか判断できない」。こうした迷いには、対象業務を分解し、各工程の完了条件と責任者を決めてから比較する方法が有効です。

ここでいう内製は、業務設計、システム連携、評価、改善を自社が主体となって担う方法です。外注は、SaaSや開発ベンダーの製品・支援を利用する方法です。どちらを選んでも、出力を業務に採用する基準と、誤りが起きたときの対応は自社で明確にする必要があります。

対象業務を選ぶ段階では「AIエージェントで業務自動化」、既存の自動化手段との役割分担を考える際には「AIとRPAの違い・使い分け」も参照してください。


この記事でわかること

AIエージェントを自社開発するか、外部サービスを利用するか判断したいCTO・経営者に向けて、比較から運用開始までの確認事項を整理します。各節で、判断が分かれる条件と次へ進むために必要な確認を示します。

  • 内製と外注の違い — 構築、変更、データ管理、保守について担当と責任を割り当てる方法を確認できます。
  • 内製・外注の判断基準 — 業務の固有性、技術体制、データの扱い、導入準備、TCO(総所有コスト)を同じ条件で比較できます。
  • ハイブリッド型の設計方法 — 自社に残す判断と外部サービスに任せる処理を、工程単位で切り分けられます。
  • 導入後の運用方法 — 評価記録、差し戻し、変更承認、引き継ぎを定め、検証結果から拡大・修正・停止を判断できます。

AIエージェントの内製と外注を全体で比較する

最初に、対象業務の入力、期待する出力、承認者、例外を記録します。そのうえで「誰が作るか」に加え、「誰が誤りを発見し、直し、再評価するか」を比較します。担当を決められない工程があれば、導入範囲を広げる前に責任分界を整理します。

例えば、問い合わせへの回答案を作る業務なら、問い合わせの分類、参照情報の選択、回答案の作成、送信の承認を分けます。回答案の作成を外部サービスで試せても、参照情報の更新者や送信の承認者が決まらなければ、業務全体の運用方法は確定できません。

内製は業務知識を自社に蓄積できる体制が前提になる

内製では、対象業務のルール、参照データ、判断条件、システム連携を自社で設計します。出力の判断方法が製品や顧客体験に関わるなら、評価基準と改善の優先順位を自社で管理すべきかを検討します。

担当者だけが設計理由を知っている状態では、変更の妥当性を別の人が判断できません。プロンプト、データ項目、評価事例、変更履歴を残し、別の担当者が同じ基準で修正を判断できるかを確かめます。引き継げるなら内製範囲を検討し、難しければ対象を狭めるか運用支援を組み合わせます。

外注は業務への適合と変更方法を確かめて選ぶ

外注では、SaaSの標準機能やベンダーの開発資産を使って対象業務を検証します。社内問い合わせ、公開情報の整理、定型文の下書きなど、入力と出力を限定できる工程から試すと、標準機能で足りる部分が見えます。

選定時は、現在の動作だけでなく、業務ルールが変わったときの修正方法、費用条件、データの取り出し方を確認します。必要な変更を契約範囲で扱え、自社で結果を評価できるなら検証へ進みます。変更や移行の条件が不明確なら、契約前に確認するか、そのサービスに任せる範囲を限定します。

比較表は責任分界まで含めて読む

次の表は、内製と外注で確認する役割を整理したものです。各行に自社の担当者、外部の担当者、確認に使う資料を当てはめてください。実際の分担は製品、契約、構築内容によって決まります。

評価項目 内製 外注
初期構築 人材確保と基盤設計から始める 既存製品やベンダーの基盤を利用する
カスタマイズ 自社の優先順位で変更しやすい 製品仕様や契約範囲の影響を受ける
データ管理 保存場所と処理方法を自社で設計する ベンダーの規約と管理方法を確認する
保守 監視、障害対応、改善を自社で担う 契約範囲に応じてベンダーが担う
知識の蓄積 設計と改善の知見を社内に残しやすい ベンダー側に判断の背景が残る場合がある
導入後の変更 自社の開発体制に左右される 標準機能と追加支援の範囲に左右される
主なリスク 開発の長期化と属人化 ベンダーロックインと仕様変更

次の表には、比較の際に見かける費用、期間、自由度などの表現を並べています。各セルは検証するための仮の条件であり、相場、標準的な所要期間、提供範囲、保証を示すものではありません。特に「月額利用料のみ」「完全に自由」「担保」といった記載は、そのまま選定根拠にできません。同じ業務範囲と運用条件を示したうえで、見積もり、仕様、契約に照らして確認してください。

評価項目 内製(自社開発) 外注(SaaS/ベンダー活用)
初期コスト 高い(人材採用・基盤構築) 低い(月額利用料のみ)
ランニングコスト 固定費中心(人件費) 変動費中心(利用量課金)
開発期間 長い(6ヶ月〜1年以上) 短い(1〜3ヶ月)
カスタマイズ性 非常に高い SaaS側の制約あり
技術的自由度 完全に自由 ベンダーの技術スタックに依存
データ管理 完全に自社管理 ベンダーのポリシーに依存
スケーラビリティ 自社で設計・構築が必要 ベンダー側で担保
保守・運用 自社対応(継続的な投資が必要) ベンダーが対応
競争優位性 差別化資産になりうる 競合も同じサービスを利用可能
リスク 開発失敗リスクが高い ベンダーロックインリスク

実際の比較では、まず両案の対象業務と完了条件をそろえます。次に、初期設定、連携、評価、監視、変更対応について、自社作業と契約に含まれる作業を分けます。最後に、データの保存先、障害時の対応者、変更の承認者を確認します。根拠を示せないセルは優劣の判定に使わず、確認事項として残します。


内製・外注を判断する主要な基準

判断の順序は、対象業務の固有性を確かめ、利用できるデータと運用体制で選択肢を絞り、残った案の導入準備とTCOを比べる流れです。

データを扱えない案や、必要な運用責任を引き受けられない案は、費用比較の前に対象から外すか構成を見直します。

競争優位性と業務の固有性

まず、AIエージェントの判断方法そのものが自社製品の価値や顧客体験に関わるかを確認します。関わる場合は、出力の良し悪しを決める基準と改善方法を自社で管理する必要があるか検討します。

社内問い合わせや定型的な情報整理なら、外部サービスの標準機能で完了条件を満たせるか試します。同じ業務の中に独自の判断と共通の処理が混在する場合は工程を分け、判断基準だけを自社で持つ案も比較します。切り分けた後は、各工程の入力と出力を受け渡せるか確認してから、分担を決めます。

技術人材とデータ機密性

内製案では、設計、連携、監視、セキュリティ、評価の担当者を割り当てます。異動時の引き継ぎと障害時の対応も含めて継続できるなら、内製を検討できます。特定の担当者に依存するなら、対象範囲を狭めるか外部支援を組み合わせます。

データは、入力、参照情報、会話履歴、出力結果に分けて確認します。外部環境へ渡せない情報が業務に不可欠なら、自社管理環境で処理する案を検討します。その情報を除いても目的を検証できるなら、外部サービスに渡す範囲を限定して試します。どの案でも、利用できるデータと権限を先に確定させます。

導入スピードとTCO

開始時期が判断材料になる場合は、外部サービスの標準機能で対象業務を試せるか確認します。ただし、データ整備、社内承認、評価の準備も開始までの作業に含めます。内製案も、機能が動く時点ではなく、評価と引き継ぎを終えて業務で使える時点で比較します。

TCOには初期費用、利用料、人件費、連携開発、監視、評価、教育、障害対応、切り替え費用を含めます。同じ業務範囲と比較期間を設定し、処理量や変更頻度が変わる場面も確認します。品質と運用の条件を満たす案に絞ってから費用を比べます。


開発費だけでなくTCOで比較する

見積もりを比べる前に、運用開始後のデータ更新、回答評価、業務変更への対応、利用者教育を洗い出します。費用が発生する場面と担当部門をそろえると、見積もりの外にある社内作業を確認できます。

初期費用と継続費用を分ける

次の表を使い、各項目について「見積もりに含まれるか」「社内で誰が作業するか」「終了時に何が必要か」を確認します。内製案と外注案で対象範囲が異なる場合は、先に要件をそろえます。

費用区分 内製で発生する項目 外注で発生する項目
導入時 要件定義、基盤構築、連携開発、テスト 初期設定、導入支援、データ移行
運用時 人件費、監視、評価、保守、再学習や調整 利用料、追加支援、利用量に応じた費用
変更時 改修、再テスト、社内調整 オプション追加、個別開発、契約変更
終了時 システム停止、データ整理 データ出力、移行、契約終了対応

外注案では社内担当者による回答の確認・修正を、内製案では開発担当者に加えて業務部門による評価を、それぞれTCOに含めます。担当者・作業内容・所要時間を確認できない費用は推測せず、未確定として残します。回答の確認・修正が必要な範囲も不明な場合は、TCOによる比較結果も確定できません。

業務量の増加と変更頻度を分けて考える

処理量が増える場合と、業務ルールが変わる場合を別々に想定します。外部サービスでは、処理量の増加や設定変更が契約・支援範囲にどう影響するか確認します。内製では、改修と再評価を担当できるか確認します。

現在の業務に加え、対象を広げる場面とルールを変更する場面を両案で比較します。例えば対象部署を広げるなら、参照情報と承認者が変わるかを確認します。判断ルールを変えるなら、設定または開発の担当者と再評価の方法を確認します。必要な作業を説明できる範囲だけ導入対象にし、見込みが立たない工程は限定して検証します。

撤退と切り替えの費用も先に見積もる

導入時点で、利用を縮小・停止する条件と、データを引き継ぐ方法を決めます。外注では、会話履歴、設定、ナレッジ、連携データをどの形式で取得できるか確認します。取得できない要素がある場合は業務継続への影響を見て、任せる範囲を決めます。

内製では、担当者や利用基盤が変わっても引き継げるよう、構成図、データ項目、評価手順を残します。効果と費用を同じ業務単位で整理する際は、AI投資のROI算出方法も参照してください。


ハイブリッド型で内製と外注を組み合わせる

業務を工程に分けると、判断基準やデータ設計は自社で担い、共通基盤や周辺処理には外部サービスを使う案を検討できます。分担を決める際は、工程の境目でデータを誰が渡し、結果を誰が確認し、障害時に誰が止めるかまで定めます。

コア業務は内製し、周辺業務は外注する

顧客へ提供する価値や自社独自の判断に関わる部分を内製し、議事録の整理、公開情報の要約、定型的な問い合わせ対応などには外部サービスを使う設計です。ただし、同じ「問い合わせ対応」でも契約や個別事情に関わる判断が含まれるなら、工程を分けて扱います。

例えば、情報収集と下書きはAIが支援し、顧客への提案内容と送信判断は人間が担います。各工程について、誤りを発見する人、差し戻し先、再確認の方法を決められたら、分担案の検証へ進みます。

基盤は外部サービス、業務設計は自社で担う

SaaSやクラウドAIプラットフォームを基盤として利用し、対象業務、参照情報、回答ルール、評価基準を自社で設計する方法です。必要な設定を自社で変更できるか、変更履歴と評価結果を確認できるかを選定時に試します。

最初は参照情報と出力形式を絞り、誤りが起きた箇所を記録します。参照データ、業務ルール、設定のどこに原因があるかを分けて修正します。修正後に同じ事例で結果を確かめ、別の担当者も同じ手順で評価できるようになったら、対象範囲の拡大を検討します。

以下の画面は、StartLinkサポートAIのガイドラインでトーンや応答スタイルを設定し、右側でウェブチャットの回答と回答ソースをプレビューしている状態です。外部サービスを評価するときは、表現に加えて、回答の根拠を確認する方法と人間へ引き継ぐ条件も確認します。

StartLinkサポートAIのガイドライン設定とテストプレビュー

外部サービスで検証し、必要な部分だけ内製へ移す

外部サービスで対象業務を試し、標準機能では扱いにくい独自の判断や、自社で継続して改善したい部分を特定してから内製範囲を決めます。移行前には、内製で解決したい問題と、新たに引き受ける運用責任を明確にします。

検証時から入力、出力、修正理由、評価結果を共通形式で記録すると、移行する工程の要件を整理できます。記録を取得できない場合は、代わりに何を保存できるか確認してから切り替えを判断します。AIエージェント導入ロードマップも参照し、検証と本番運用の条件を分けて計画してください。


外注先と外部サービスを選ぶ

比較には、各候補へ同じ業務シナリオを提示します。デモの回答に加え、データの取り扱い、誤回答への対応、契約終了時の移行を確認します。「AIの利用・開発に関する契約チェックリスト」(経済産業省)も参照し、実際に適用される条件は候補ごとの契約書と見積もりで確認してください。

技術と業務理解を同じシナリオで評価する

各候補に、実際の業務で発生する入力、期待する出力、判断できない例を提示します。参照するデータ、判断できないときの返答、人間へ引き継ぐ時点を確認します。評価者と合格条件を自社で決めておくと、デモの印象だけに左右されず比較できます。

過去の実績とは別に、自社の例外条件への対応を評価します。誤りの分類、修正担当、再評価の手順を説明できるなら運用方法の比較へ進みます。説明が曖昧なら対象業務を狭め、同じシナリオで再確認します。

セキュリティとデータの取り扱いを確認する

入力データの保存、学習への利用、アクセス権限、ログ、削除、再委託先、障害時の連絡方法を確認します。設定で保存を制限できる場合も、利用者が誤って情報を入力した際の対応を運用ルールに含めます。

機密データを外部へ渡せない場合は、該当データを除いて検証できる工程に絞るか、自社管理環境で処理する案を検討します。業務に不可欠なデータの扱いが許容できないなら、その候補での導入は進めません。

サポート範囲と価格条件を具体化する

次の表の各項目について候補から回答を得て、契約書や見積もりと照合します。通常時と障害時で担当が変わる工程は、連絡先と対応範囲を分けて確認します。

確認項目 比較する内容 判断の分かれ目
初期設定 要件整理、データ投入、連携設定の担当 社内で補えない工程が支援範囲に含まれるか
運用支援 問い合わせ、調整、障害対応 業務時間内に必要な対応を受けられるか
追加費用 利用量、連携、個別開発、サポート 利用拡大時の費用を予算化できるか
データ移行 出力形式、取得対象、終了後の扱い 他サービスや内製環境へ移せるか
改善方法 評価結果の共有、修正担当、反映手順 自社が改善理由を把握できるか

契約前に、誤回答、連携停止、担当者変更、契約終了の場面を想定し、誰が何を行うか確認します。責任分界を説明できれば検証へ進み、曖昧な工程が残れば条件を確認します。AI vs 業務委託の比較も使い、AIサービスと人的な業務委託の担当範囲を整理してください。


内製を選んだ場合の開発ロードマップ

内製では、対象業務を絞って評価し、各段階の完了条件を満たしてから範囲を広げます。

機能が動くことに加え、判断できない入力を止められるか、誤りの原因を調べられるか、別の担当者へ引き継げるかを確認します。

基盤構築では対象業務と評価方法を決める

最初に、入力、参照情報、出力、人間へ引き継ぐ条件を定義します。その要件に沿ってLLMプロバイダー、開発フレームワーク、API連携方法を比較し、対象を絞ったプロトタイプを作ります。

代表的な入力と判断できない入力の両方で結果を評価します。失敗時に処理を止められ、修正すべき箇所を特定できたら、業務固有のデータ整備へ進みます。AIエージェント開発入門では、設計時に検討する要素を詳しく解説しています。

業務特化ではデータと例外を整備する

対象業務の知識ベースを整備し、必要な社内システム連携を開発します。正常な処理に加え、情報不足、矛盾したデータ、権限不足、判断対象外の入力を用意し、どの場面で処理を止めるか決めます。

誤りが出たら、参照データの不足、業務ルールの曖昧さ、出力後の確認手順を分けて調べます。修正理由を記録でき、同じ事例を使って修正後の結果を評価できるようになったら、本番運用の担当と監視方法を決めます。

本番運用では監視と改善を仕組みにする

本番環境では、出力内容、処理失敗、人間への引き継ぎ、利用停止、データ更新の状況を確認します。改善依頼には、入力、実際の出力、期待する出力、修正理由を同じ形式で記録します。

変更前後に同じ評価事例を確認し、重要な誤りが増えていないことを確かめてから反映します。運用担当、障害時の連絡先、変更の承認者が決まり、別の担当者も記録を使って評価できるようになったら、対象業務の拡大を検討します。


CRMとAIを一気通貫の業務フローに置く

CRMを使う業務では、AIの出力が次の担当者の行動につながるか確認します。コンタクト、取引、顧客、請求へ続く流れのうち、どの情報を参照し、どこに結果を記録し、誰が承認するかを工程ごとに設計します。記録するだけで終わる場合は、次の行動と完了条件を先に決めます。

スプレッドシートと手作業の分断を先に洗い出す

会社名や案件情報をどこで入力、確認、承認、更新しているか、業務の順に整理します。複数の場所に同じ情報がある場合は、更新担当者と基準となる参照先を決めます。

AIが参照する情報と、更新候補を作ってよい項目が定まったら、情報整理、記録候補の作成、承認後の反映を工程ごとに検討します。基準となるデータを決められない場合は、接続範囲を広げる前に管理方法を整理します。

AIと人間の役割を業務段階ごとに分ける

次の表を起点に、自社の承認権限と例外処理を当てはめます。AIが候補を作る工程でも、採用する人と差し戻す条件を決めます。

業務段階 AIに任せる処理 人間が判断する内容
情報受付 内容の整理、分類、要約 対応の優先順位と例外判断
商談準備 公開情報の整理、下書き 提案方針と顧客への伝え方
取引管理 記録候補の作成、更新候補の提示 金額、進行判断、重要な変更
顧客対応 ナレッジを参照した回答案 苦情、契約、個別事情への対応
請求連携 必要情報の整理、処理候補の提示 請求内容の承認と例外処理

顧客への連絡では、人間が背景と表現を確認します。自動実行する工程を検討する場合は、対象処理、停止条件、差し戻し方法を定義し、記録から誤りと影響範囲を確認できる状態にします。

項目を絞り、次の行動へつなげる

AIエージェントが扱う項目は、次の担当者の行動、レポート、ワークフローのいずれかに使うものから選びます。項目ごとに意味、更新担当、参照する場面を記載し、重複を整理します。

分類結果を記録するなら、誰が確認し、どの条件で取引や顧客対応へつなぐかを定義します。次の業務が正しく進んだか評価できるようになってから、扱う項目を増やします。


自社の判断を段階的に固める

内製か外注かは、対象業務を選び、同じ評価項目で試した結果から判断します。比較前に完了条件を決め、検証後には拡大、修正、停止のどれへ進むかを確認します。

対象業務を絞り、現状を記録する

候補業務は、入力と期待する出力を説明でき、人間が結果を評価できるものから選びます。現在の作業手順、担当者、利用データ、例外、完了条件を記録し、比較の基準にします。

範囲が広い場合は、受付、分類、下書き、承認、記録のように工程を分けます。承認を人間に残して情報整理から試せるなら、その工程を最初の対象にします。入力や完了条件を定義できない場合は、業務手順の整理を先に進めます。

内製案と外注案を同じ条件で比較する

両案に同じ入力データ、例外事例、評価項目を使います。回答品質に加え、修正作業、データ更新、障害対応、利用者教育、終了時の移行を比較します。

評価軸 内製案で確認すること 外注案で確認すること
業務適合 独自ルールを実装できるか 標準設定で要件を満たせるか
継続運用 担当者と引き継ぎ方法があるか 支援範囲と責任分界が明確か
データ 自社で管理できるか 保存、利用、出力条件を許容できるか
変更対応 改修と再評価を続けられるか 設定変更や個別開発が可能か
費用 体制維持まで予算化できるか 利用拡大と移行まで予算化できるか

独自要件を満たすため継続的な変更が必要で、担当体制も確保できるなら内製を検討します。標準機能で完了条件を満たし、契約上の責任分界が明確なら外注を検討します。工程ごとに条件が分かれる場合は、判断ルールと基盤の担当を分けた案を作ります。

検証結果から拡大、修正、停止を決める

検証後は、完了条件を満たしたか、人間が何を修正したか、例外時に処理を止められたか、運用担当者が改善を続けられるかを確認します。結果は内製案と外注案で同じ形式にまとめます。

完了条件を満たし、運用担当も決まった場合は、同じ業務の対象範囲を広げます。出力は使えるものの確認負荷が大きい場合は、項目や連携を減らして再評価します。重要な誤りを制御できない場合はその工程での利用を止め、AIに任せる範囲を情報整理まで戻します。


よくある質問

AIエージェントは内製と外注のどちらから始めるべきですか?

対象業務の入力と完了条件を決め、継続的な開発体制と外部サービスで扱えるデータを確認します。標準機能で検証でき、開発体制を確保できないなら、範囲を絞って外部サービスを試します。独自の判断が必要で、評価と改善を担う体制があるなら、その部分の内製を検討します。

外注の場合、ベンダーロックインをどう抑えますか?

入力データ、出力、ナレッジ、設定、履歴をどの形式で取得できるか、契約前に確認します。取得できない要素が業務継続に関わるなら、その要素を自社側で管理するか、別のサービスを比較します。切り替え手順と担当者を決められたら検証へ進みます。

中小企業でも内製を選べますか?

企業規模だけでは決まりません。AIエージェントが製品やサービスの独自性に関わり、設計、評価、改善を続ける担当者を確保できるなら、対象を絞った内製を検討できます。体制を維持できない工程は外部サービスとの分担を考えます。中小企業のAI業務効率化ガイドも参考にしてください。

AIエージェントの自動実行はどこまで任せるべきですか?

情報整理、分類、下書きなど、人間が結果を確認できる工程から検証します。顧客への送信、重要な取引の更新、請求に関わる判断では、承認者と差し戻し条件を明確にします。誤りの種類と影響範囲を記録でき、停止手順も機能することを確かめてから、自動実行する工程を検討します。

内製から外注、外注から内製へ切り替えられますか?

データ、設定、評価方法、業務知識を移せるかによって、必要な作業が変わります。外注から内製へ移す場合は、取得できる設定と判断の背景を確認します。内製から外注へ移す場合は、独自に開発した部分を外部サービスの標準機能で扱えるか試します。移せない要素の影響と対応方法を決めてから切り替えます。


まとめ

AIエージェントの内製と外注は、業務の固有性、技術体制、データの扱い、導入準備、TCOを同じ対象業務で比較して判断します。独自の判断を担う工程と共通化できる処理を分けると、内製、外注、ハイブリッド型それぞれの担当範囲を具体化できます。

CRMを使う業務では、AIが参照する情報、作る結果、人間が承認する場面を業務の流れに沿ってつなげます。記録した結果が次の担当者の行動に使われるかも確認してください。

判断材料は次の順序でそろえます。

  • 現在の作業、利用データ、例外、完了条件を書き出します。
  • 内製案、外注案、ハイブリッド案を同じ入力と評価項目で比較します。
  • 検証結果と運用体制を確認し、拡大、修正、停止の条件に沿って次の工程を決めます。

企業様によって最適な形は異なります。CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。


あわせて読みたい

AIエージェントの内製・外注を検討する際は、次の記事で外部サービスの選定項目、投資判断、業務委託との分担、開発時の設計を確認できます。

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

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

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


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

関連キーワード:

サービス資料を無料DL

著者情報

7-1

今枝 / Imaeda

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