---
title: RevOps（レベニューオペレーション）とHubSpot｜Anguilact（アンギラクト）
description: RevOpsとは何か、HubSpotとどう関係するのかを解説。海外の実務家の発信とSmartHRなど日本企業の公開事例をもとに、部門連携、データ設計、HubSpotでの実践方法を紹介します。
image: https://anguilact.co.jp/hubfs/revops-thumbnail.webp
---

[本文へ移動](https://anguilact.co.jp/articles/revops-and-hubspot#main-content)

[![アンギラクト — Anguilact](https://anguilact.co.jp/hubfs/Imported%20sitepage%20images/anguilact-preinc-jp-en-white.svg)](https://anguilact.co.jp/)

メニュー

- [ホーム](https://anguilact.co.jp/)
- [読み物（コラム）](https://anguilact.co.jp/articles)
- [会社案内](https://anguilact.co.jp/about)

[お問い合わせ](https://anguilact.co.jp/contact)

サイト内を検索

[HubSpot活用](https://anguilact.co.jp/articles/tag/hubspot%E6%B4%BB%E7%94%A8) / [HubSpot CRM](https://anguilact.co.jp/articles/tag/hubspot-crm)

# RevOps（レベニューオペレーション）とHubSpot

[西岡草実（にしおかそうま）](https://anguilact.co.jp/articles/author/soma-nishioka) 2026.10.5

RevOpsとは何か、HubSpotとどう関係するのかを解説。海外の実務家の発信とSmartHRなど日本企業の公開事例をもとに、部門連携、データ設計、HubSpotでの実践方法を紹介します。

旧記事の公開日：2025.02.22 ／ 更新：2026.10.05

マーケティングは問い合わせを増やしている。営業も商談を進めている。それでも、対応の遅れや受注後の引き継ぎ漏れが起き、売上や顧客の継続につながらない。こうした部門の境目にある問題を、会社全体で解いていくための考え方が**RevOps（Revenue Operations／レベニューオペレーション）**です。

HubSpotは、その取り組みを顧客データ、業務フロー、レポートへ落とし込むために使えるプラットフォームです。この記事では、海外のRevOps実務家によるLinkedInでの発信、日本企業の公開事例、公式資料を手がかりに、RevOpsの役割とHubSpotでの実践方法を整理します。

## RevOpsとは何か

**RevOpsは、マーケティング・営業・カスタマーサクセスなど、収益に関わる部門の業務、データ、システムをつなぎ、継続して改善する役割・取り組みです。**顧客の獲得から受注、導入、継続利用までを見渡し、各部門が共通のルールと情報を使って動ける状態をつくります。

![各部門が顧客獲得から継続を担い、RevOpsが部門間の定義・責任・指標をそろえ、HubSpotで記録・通知・確認を実行する。](https://anguilact.co.jp/hubfs/anguilact/articles/revops-explainers-20261005/01-overview.svg)

各部門が顧客獲得から継続を担い、RevOpsが部門間の定義・責任・指標をそろえ、HubSpotで記録・通知・確認を実行する。

たとえば「営業へ渡せる見込み客の条件は何か」「受注時に導入担当へ何を渡すか」「更新が危うい顧客を誰が把握するか」を決め、実際の運用に定着させます。レポートを作る場合も、数値を並べるだけでなく、どの問題を優先して改善するかという意思決定につなげます。

HubSpot自身も、社内のRevOpsを、マーケティング・営業・カスタマーサクセス・パートナーと協力し、戦略、分析、自動化、実行支援を通じて成長と顧客体験を支える役割として説明しています。これは一社の組織例ですが、RevOpsの仕事が複数部門にまたがることを理解しやすい例です（[HubSpot：Operations & Data](https://www.hubspot.com/careers/operations)）。

### Sales OpsやCRM管理との違い

担当範囲は会社ごとに異なりますが、この記事では次のように整理します。

| 役割 | 主に見る範囲 |
| --- | --- |
| Sales Ops | 営業活動を支える案件管理、営業プロセス、予測や運用ルール。 |
| CRM管理者 | CRMのデータ、権限、画面、連携、自動化などの設定と運用。 |
| RevOps | 顧客獲得から受注後までを横断し、部門間の引き継ぎ、共通指標、業務とデータの整合を改善する。 |

一人が複数の役割を兼ねることもあります。大切なのは部署名を変えることよりも、部門をまたぐ問題について、誰が関係者を集めて判断し、改善を進めるかを明確にすることです。

## なぜRevOpsが必要になるのか

部門ごとの成果が、そのまま会社全体の成果になるとは限りません。問い合わせ件数を増やしても営業が対応できなければ機会を失います。受注しても、営業が約束した内容が導入担当へ伝わらなければ、顧客は同じ説明を繰り返すことになります。

ここで必要なのは、「どの部門が悪いか」を決めることではなく、顧客が次の段階へ進むときの条件と責任をそろえることです。RevOpsは、たとえば次のような問題を横断して扱います。

- マーケティングと営業で、有望な見込み客や商談の定義が異なる。
- 問い合わせの対応担当者や対応期限が決まっていない。
- 受注した案件の契約範囲・顧客の期待・開始日が導入担当へ伝わらない。
- 顧客の利用状況や不満が、更新提案をする担当者に届かない。
- 同じ「売上」という言葉でも、受注金額・請求額・会計上の売上を混ぜて集計している。

継続課金型の事業では、受注後に顧客が価値を感じ、継続・追加利用するところまでが成長に関わります。Winning by Designの**Bowtie（ボウタイ）モデル**は、獲得だけでなく維持・拡大までを一続きで捉える枠組みです。受注後の業務も含めて設計する視点として参考になります（[Winning by Design：Revenue Architecture](https://winningbydesign.com/revenue-architecture/)）。

ただし、SaaSの指標や組織をそのまま自社へ移す必要はありません。受託事業なら納品や追加受注、保守契約なら更新など、自社の顧客との関係に合わせて見る範囲を決めます。

## 海外のRevOps実務家の発信から学べること

LinkedInにはRevOpsについてさまざまな意見があります。ここでは、業界全体の統一見解としてではなく、実務を考えるうえで参考になる三つの視点を紹介します。

![依頼の多さには影響からの優先付け、データの不整合には定義と更新責任、繰り返す漏れには手順と例外の設計で対応する。](https://anguilact.co.jp/hubfs/anguilact/articles/revops-explainers-20261005/02-perspectives.svg)

依頼の多さには影響からの優先付け、データの不整合には定義と更新責任、繰り返す漏れには手順と例外の設計で対応する。

### 収益への影響から、改善の優先順位を決める

Jen Bergren氏は、RevOpsAF 2025でのSandy Robinson氏の講演を紹介する投稿で、CRMへの不満やレポートの要望に加え、営業と導入担当の情報断絶が語られたことを伝えています。そこで示されているのは、寄せられた依頼を順番に処理するだけでなく、収益への影響が大きい問題から取り組む視点です（[Jen Bergren氏のLinkedIn投稿](https://www.linkedin.com/posts/jenbergren_revopsaf-revops-activity-7331030294428385280-nSuv)）。

自社で応用するなら、「どの画面を直すか」の前に、「顧客のどの段階で、どんな機会損失が起きているか」を確認します。現場の不満は調査の出発点になりますが、解決策まで決まっているとは限りません。

### 入力の徹底とあわせて、データの持ち方を見直す

RevOps Co-opは、自ら開催したCRMデータに関するウェビナーの紹介で、入力必須項目を増やすだけでは解決しない問題や、顧客を中心にしたデータモデルの重要性を取り上げています（[RevOps Co-opのLinkedIn投稿](https://www.linkedin.com/posts/revopscoop_revops-revenueoperations-activity-7397676441443713024-m4iL)）。

これは「現場は入力しなくてよい」という意味ではありません。どの情報を、誰が、いつ更新するのか。同じ会社や案件が重複していないか。別のシステムと値が食い違ったとき、どちらを正とするのか。入力を求める側にも、こうした設計が必要です。

### 日々の修正を、問題が繰り返されない運用につなげる

GTMnowは、EverstageのSiva Rajamani氏の見解を紹介する投稿で、RevOpsが日々のCRMやワークフローの修正に追われる状態から、業務の仕組みそのものを設計する役割へ移る重要性を論じています（[GTMnowのLinkedIn投稿](https://www.linkedin.com/posts/gtmnow_revenue-operations-was-always-supposed-to-activity-7475563487566647296-cQCE)）。

たとえば、引き継ぎ漏れのたびに担当者へ連絡するだけでなく、受け渡す情報、確認担当者、例外時の対応を決める。そのうえでCRMに組み込み、実際に漏れが減ったかを確かめる。この記事では、このような改善の積み重ねとしてRevOpsを捉えています。

## 日本ではどのような取り組みがあるのか

日本にも、営業・マーケティングのデータ活用や、部門をまたぐ業務の改善を公開している企業があります。ここでは担当者の発信と公式導入事例から、具体的な仕事を見てみます。記載した時期の取り組みであり、2026年10月時点の各社の運用を直接確認したものではありません。

### SmartHR：顧客に合う導入事例を、営業が選べる仕組みにする

SmartHRでRevOpsを担当する和田慶氏は、2025年10月21日の記事で、同社で構築・運用した事例活用の仕組みを紹介しています。業種・従業員規模・地域から顧客と導入事例の近さを評価し、CRM上で推奨事例を確認できるようにするものです（[和田慶氏：B2B営業組織における『事例の戦術的利用法』](https://note.com/kewpie_wada/n/na218e77b30e2)）。

本記事で注目するのは、マーケティングが制作した事例を、営業が提案に使うところまでつなげている点です。新しい資料を増やすだけでなく、既存の顧客情報と組み合わせ、誰が使っても選びやすい状態をつくる。これもRevOpsの具体的な仕事として捉えられます。この発信はHubSpotの導入事例として紹介するものではありません。

### マネーフォワード：業務を決める人と、CRMを設定する人が一緒に改善する

マネーフォワードの荒井喬碩氏は、2024年12月14日のBizOpsの振り返りで、課金仕様の整理、Salesforceの改修、販売・受注の運用変更を、プロダクト・企画推進・CRM管理・販売受注サポートの関係者で進めた経緯を紹介しています（[荒井喬碩氏：マネーフォワードのBizOps 立ち上げと組織拡大の軌跡](https://note.com/mfw_arai/n/nc15c2cf29e41)）。

同社がBizOpsとして説明する取り組みですが、部門をまたぐ業務設計とシステム変更を一緒に進める点は、RevOpsを考えるうえでも参考になります。HubSpotを使う会社に置き換えるなら、管理者へ項目追加を依頼する前に、営業や受注後の担当者と業務の条件を整理する、という応用が考えられます。

### イベントレジスト：HubSpotで営業と顧客サポートの情報をつなぐ

HubSpotが公開するイベントレジストの導入事例では、2020年に始まった営業・ヘルプセンターの見直しを通じて、Marketing Hub・Sales Hub・Service Hubに顧客情報を集約した取り組みが紹介されています。開催予定のイベントを取引で管理し、有料アカウントは別のチケットパイプラインで管理して、期限前の継続案内につなげています（[HubSpot公式：イベントレジスト導入事例](https://www.hubspot.jp/case-studies/eventregist-new)）。

これは過去の導入事例です。同社がRevOpsという組織名を採用していることを示すものではありませんが、営業とサポートが共通の顧客情報を使い、継続利用まで見渡す実践例として参考になります。チケットの使い方をそのまままねるのではなく、自社では何を一件として管理するかを考える材料にできます。

三つの例に共通して参考になるのは、CRMの操作だけで完結せず、情報を使う場面や、部門間の受け渡しまで設計している点です。日本の企業でも、「営業企画」「業務企画」「BizOps」「CRM管理」といった既存の役割から、こうした横断的な改善を始められます。

## RevOpsとHubSpotはどう関係するのか

**RevOpsで業務とデータのルールを決め、HubSpotでそのルールを実行・記録・確認できるようにする。**この関係で考えると、HubSpotを何のために設定するのかが明確になります。

HubSpotはRevOpsを実践するための選択肢の一つです。CRMを導入しただけで部門間の合意ができたり、すべての情報が正しく集約されたりするわけではありません。顧客へ提供する価値、部門の責任、判断基準は、関係者が決める必要があります。

### 顧客と案件の情報を関連付ける

HubSpotでは、コンタクト、会社、取引、チケットなどのレコードを関連付けられます。たとえば、ある会社の担当者、進行中の案件、問い合わせ対応をつなげて確認できます（[公式：レコードの関連付け](https://knowledge.hubspot.com/records/associate-records)）。

RevOpsの観点では、その前に「一つの会社として扱う単位」「一つの取引が表す範囲」「受注後の対応をどこで管理するか」を決めます。共通の画面に情報があることに加えて、情報の意味がそろっていることが重要です。

### 顧客の段階と引き継ぎ条件をそろえる

ライフサイクルステージは、見込み客から顧客になるまでの関係を管理するために使えます。ただし、MQL（マーケティングが営業へ渡せると判断した見込み客）やSQL（営業が有望と判断した見込み客）の具体的な条件は、自社の営業方法に合わせて合意する必要があります。

顧客との関係を表すライフサイクルステージと、個別案件の進捗を表す取引ステージは、分けて設計します。各段階に入った日付なども分析できますが、最新の滞在時間・累積滞在時間のプロパティーにはProfessionalまたはEnterpriseの契約が必要です（[公式：ライフサイクルステージの使用](https://knowledge.hubspot.com/records/use-lifecycle-stages)）。

### 決まったルールをワークフローへ落とし込む

HubSpotのワークフローは、条件に合うレコードに対して処理を実行する仕組みです。契約している製品・プランに応じて、タスク作成や通知などを組み合わせられます。本格的なワークフロー機能は対象製品のProfessionalまたはEnterpriseが必要で、使える対象やアクションにも違いがあります（[公式：ワークフローの作成](https://knowledge.hubspot.com/workflows/create-workflows)）。

自動化する前には、通常の流れに加えて、担当者不在、情報不足、差し戻しといった例外を決めておきます。誰が対応するかが曖昧なまま通知だけを増やしても、引き継ぎの問題は残ります。

### 部門をまたいだ流れを測り、改善へつなげる

見る数字も、問い合わせ件数や受注金額だけでなく、その間と受注後を含めて考えます。たとえば、営業への引き渡しから初回対応までの時間、商談化率、受注から導入開始までの期間などです。どれを測るかは、解きたい問題から選びます。

HubSpotのカスタマージャーニーレポートを使う場合は対象HubのEnterprise契約が必要です。コンタクトはMarketing HubまたはService Hub、取引はSales Hub、チケットはService Hubが対象になります。高度な分析機能を前提にせず、今の契約で確認できる情報から始めることもできます（[公式：ジャーニーアナリティクスによるレポート作成](https://knowledge.hubspot.com/reports/create-a-journey-report)）。

## 具体例：営業から導入担当への引き継ぎを改善する

ここからは、考え方を説明するための仮の例です。実在する顧客企業の事例や成果ではありません。

![営業が受注後に必要情報を記録し、導入担当が確認する。不足があれば営業へ差し戻し、情報がそろったら引き継ぎ完了とする。](https://anguilact.co.jp/hubfs/anguilact/articles/revops-explainers-20261005/03-handoff.svg)

営業が受注後に必要情報を記録し、導入担当が確認する。不足があれば営業へ差し戻し、情報がそろったら引き継ぎ完了とする。

営業が受注した後、導入担当が契約内容や顧客の期待を聞き直しているとします。HubSpotに取引レコードはあるものの、担当者によって記録の場所が違い、導入開始が遅れています。

### まず、部門間で受け渡す条件を決める

営業と導入担当で、最低限必要な情報を決めます。たとえば、契約範囲、導入の目的、顧客側の責任者、合意した開始日、営業時点で残っている確認事項です。あわせて、誰が引き継ぎを受け取るか、不足があれば誰へ戻すかを決めます。

### 次に、HubSpotで同じ手順を使えるようにする

決めた情報を取引のプロパティーや関連レコードへ整理し、受注後に担当者が確認できるようにします。必要な契約・機能があれば、受注をきっかけに確認タスクを作るなどの自動化を検討します。業務の管理単位に合わせ、導入状況を取引とは別のレコードで管理する設計も考えられます。

このとき、営業上の「受注」と、導入側の「引き継ぎ完了」を同じ意味にしないことがポイントです。受注していても情報が不足する案件を、別の状態として把握できるようにします。

### 運用してから、改善したかを確認する

受注から引き継ぎ完了までの時間や、情報不足による差し戻しを確認します。タスクが作成された件数だけでなく、導入担当が業務を始められたか、顧客への案内が滞っていないかを見ます。

この例でRevOpsが担うのは、必要な情報と責任の合意、記録方法の設計、運用結果の確認です。HubSpotは、その合意を日々の業務へ組み込む役割を果たします。

## RevOpsとHubSpot管理者の役割分担

![RevOpsは現場責任者と業務条件を合意し、管理者はそれをデータ・権限・自動化へ反映する。運用結果を共同で確認する。](https://anguilact.co.jp/hubfs/anguilact/articles/revops-explainers-20261005/04-roles.svg)

RevOpsは現場責任者と業務条件を合意し、管理者はそれをデータ・権限・自動化へ反映する。運用結果を共同で確認する。

HubSpot Admin（管理者）は、データ、権限、画面、連携、自動化などの設定・運用を担います。RevOpsの改善を実際のシステムへ落とし込むうえで、重要な役割です（[HubSpotの管理者向け機能](https://www.hubspot.jp/admin-tools)）。

一方で、「営業へ引き渡す条件」「導入担当の対応範囲」「どの改善を優先するか」は、管理者だけでは決められません。営業・マーケティング・顧客支援の責任者や経営側が関わり、業務として合意する必要があります。

小さな組織では専任のRevOps部門をつくらず、兼務で始めても構いません。まず一つの部門間の問題を選び、判断する人、設定する人、現場で使う人を明確にするところから始めます。

## 自社で始めるなら、最初に何をするか

1. **顧客の流れを描く。** 問い合わせから受注後まで、顧客が次へ進む条件と担当者を書き出します。
2. **部門の境目で起きる問題を一つ選ぶ。** 対応漏れ、情報不足、開始遅延などから、顧客や収益への影響を見て選びます。
3. **言葉と責任をそろえる。** 商談・受注・引き継ぎ完了の定義、情報の更新担当、例外時の連絡先を決めます。
4. **HubSpotへ反映する。** 管理するレコード、プロパティー、関連付け、必要なタスクや通知を設計します。
5. **結果を見て見直す。** 現場の使いづらさと、選んだ問題が改善したかの両方を確認します。

この順序は、海外の発信と公式資料をもとにした本記事の実務上の提案です。全社の仕組みを一度に作り直すのではなく、一つの流れで合意と記録をそろえ、効果を確かめながら広げると取り組みやすくなります。

AIや自動化を取り入れる場合も、入力データの意味、判断してよい範囲、人が確認する場面を先に決めます。新しい機能を増やしたことよりも、顧客対応や部門間の連携が改善したかを基準にします。

## RevOpsをさらに学ぶには

体系的に学びたい方には、HubSpotアカデミーの[Revenue Operations認定コース](https://academy.hubspot.com/courses/revenue-operations)が参考になります。RevOpsの基礎、部門間の合意、システム管理、組織づくり、改善の進め方などを扱っています。

また、[Implementing a Revenue Operations Strategy](https://academy.hubspot.com/lessons/implementing-a-revenue-operations-strategy)では、顧客の流れを表すデータモデルやCRM、指標を実務へつなげる考え方を学べます。リンク先は英語の講座ページです。受講時には、講座内で選べる言語や字幕を確認してください。

![以前HubSpotアカデミーでRevOps認定講座を修了した際の画面](https://anguilact.co.jp/hubfs/blog-migration-20261002/5f596b09753a24dfb3a98926.webp)

以前受講した際の画面です。現在の資格の有効性や講座構成を示すものではありません。

私自身、フライホイールやシステム管理、戦略の評価・改善についてのレッスンが印象に残っています。自社の部門間でどこに手間や行き違いがあるかを考えながら学ぶと、日々のHubSpot運用にも結び付けやすくなります。

RevOpsは、顧客との関係が続く流れを、部門をまたいで整えていく取り組みです。HubSpotを活用するときも、先に解決したい業務の問題を明確にすることで、必要な設定や改善の優先順位が見えてきます。

## 参考資料

内容・機能条件の確認日：2026年10月5日。LinkedIn投稿は各発信者の見解として参照しています。自社での適用方法や記事内の仮の例は、本記事の整理・提案です。

- [Jen Bergren：RevOpsAF 2025の講演紹介（LinkedIn）](https://www.linkedin.com/posts/jenbergren_revopsaf-revops-activity-7331030294428385280-nSuv)
- [RevOps Co-op：CRMデータ構造に関する議論（LinkedIn）](https://www.linkedin.com/posts/revopscoop_revops-revenueoperations-activity-7397676441443713024-m4iL)
- [GTMnow：RevOpsの戦略的な役割（LinkedIn）](https://www.linkedin.com/posts/gtmnow_revenue-operations-was-always-supposed-to-activity-7475563487566647296-cQCE)
- [和田慶：SmartHRにおける事例活用の仕組み（2025年10月21日）](https://note.com/kewpie_wada/n/na218e77b30e2)
- [荒井喬碩：マネーフォワードのBizOpsの振り返り（2024年12月14日）](https://note.com/mfw_arai/n/nc15c2cf29e41)
- [HubSpot：イベントレジスト導入事例（2020年開始の取り組み）](https://www.hubspot.jp/case-studies/eventregist-new)
- [Winning by Design：Revenue Architecture](https://winningbydesign.com/revenue-architecture/)
- [HubSpot：Operations & Data](https://www.hubspot.com/careers/operations)
- [HubSpot Academy：Revenue Operations認定コース](https://academy.hubspot.com/courses/revenue-operations)
- [HubSpot Academy：Implementing a Revenue Operations Strategy](https://academy.hubspot.com/lessons/implementing-a-revenue-operations-strategy)

[ページの先頭へ戻る](https://anguilact.co.jp/articles/revops-and-hubspot#ag-article-top)

ニュースレター

## お役立ち情報を受け取る

読み物

## 関連記事

### [![HubSpotの標準プロパティを使うべき理由。コンタクト・会社・取引の重要項目を解説](https://anguilact.co.jp/hubfs/hubspot-standard-properties-thumbnail.webp) HubSpotの標準プロパティを使うべき理由。コンタクト・会社・取引の重要項目を解説 西岡草実（にしおかそうま）Oct 5, 2026, 5:54:20 PM 旧記事の公開日：2026.07.24／情報確認日：2026.10.05 HubSpotを使い始めると、自社の管理方法に合わせてプロパティーを追加したくなる場面が多くあります。 たとえば、標準の「金額」があるのに「案件金額」を作る。標準の「クローズ日」があるのに「受注予定日」を作る。標準の「取引担当者」があるのに「営業担当者」を作る。入力する人にとっては分かり…](https://anguilact.co.jp/articles/hubspot-default-properties-guide)

### [![](https://anguilact.co.jp/hubfs/anguilact-hubspot-file-url-settings-thumbnail.png) HubSpotに格納されたファイルのリンク変更 西岡草実（にしおかそうま）Oct 5, 2026, 7:20:30 PM 旧記事の公開日：2025.02.08](https://anguilact.co.jp/articles/hubspot-file-link-change)

![](https://anguilact.co.jp/hs-fs/hubfs/anguilact/site-images/adobe-stock/adobe-1061584176-full-1600.jpg?width=1600&height=1066&name=adobe-1061584176-full-1600.jpg)

お問い合わせ

## お気軽にご相談ください

[お問い合わせ](https://anguilact.co.jp/contact)

![アンギラクト — Anguilact](https://anguilact.co.jp/hubfs/Imported%20sitepage%20images/anguilact-preinc-jp-en.svg)

香川県高松市を拠点に、全国の企業の仕組みづくりを支援します。

© Anguilact

## 会社について

- [会社について](https://anguilact.co.jp/about)
- [利用規約](https://anguilact.co.jp/terms)
- [個人情報の取り扱い](https://anguilact.co.jp/privacy)

## お問い合わせ

- [お問い合わせ](https://anguilact.co.jp/contact)

動きを止める

Cookie設定を変更

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "西岡草実（にしおかそうま）",
    "url" : "https://anguilact.co.jp/articles/author/soma-nishioka"
  },
  "dateModified" : "2026-10-05T10:09:39.967Z",
  "datePublished" : "2026-10-05T07:43:52.000Z",
  "headline" : "RevOps（レベニューオペレーション）とHubSpot｜Anguilact（アンギラクト）",
  "image" : [ "https://anguilact.co.jp/hubfs/revops-thumbnail.webp" ],
  "mainEntityOfPage" : {
    "@id" : "https://anguilact.co.jp/articles/revops-and-hubspot",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://anguilact.co.jp/hubfs/anguilact-e4-jp-en.svg"
    },
    "name" : "アンギラクト株式会社"
  }
}
```