---
title: HubSpotライフサイクルステージの設計・設定・運用ガイド。MQL→SQLの遷移設計と計測｜Anguilact（アンギラクト）
description: HubSpotのライフサイクルステージを正しく設計・設定・運用する方法を解説。遷移条件の定義からウォーターフォールWF、SLA設定、計測まで実務ノウハウを網羅します。
image: https://anguilact.co.jp/hubfs/anguilact-hubspot-lifecycle-stages-thumbnail.png
---

[本文へ移動](https://anguilact.co.jp/articles/hubspot-lifecyclestages#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)

# HubSpotライフサイクルステージの設計・設定・運用ガイド。MQL→SQLの遷移設計と計測

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

HubSpotのライフサイクルステージを正しく設計・設定・運用する方法を解説。遷移条件の定義からウォーターフォールWF、SLA設定、計測まで実務ノウハウを網羅します。

旧記事の公開日：2025.02.16

更新：2025.12.27

ライフサイクルステージ（**Lifecycle Stages、略称LCS**）は、コンタクトや会社が購買プロセスのどの段階にいるかを示すプロパティーです。正しく設計すれば、マーケティングからセールス、カスタマーサクセスまでのデータ連携とパイプライン予測の精度が劇的に変わります。

この記事では、ライフサイクルステージの定義・設定・運用までを実務目線で解説します。

**注意**

この記事で解説するMQL/SQLの設計は、すべての企業に必要なわけではありません。目安として、以下のどれかに当てはまるなら分け始める価値があるラインです。

- **月の新規リードが100〜200件を超えてきた**  
  全件を人力で精査するのがつらくなり、「どれを優先で追うか」のルールが欲しくなるタイミング
- **リード対応に関わる人が2〜3人以上いる**  
  マーケがリードを集め、営業（orインサイドセールス）が追うというハンドオフが発生し、「ある程度温まったリードだけ渡したい」というニーズが出てくる
- **マーケ経由のリードがどれだけ売上に繋がったかを測りたい**  
  「MQL→SQL→商談→受注」の転換率を見て、広告やコンテンツ投資の効果を評価したくなった段階

逆に、月の新規リードが数十件レベルで、対応者もほぼ一人（社長 or 営業1名）で全部見ている状況なら、MQL/SQLを分けずに「リード→商談→顧客」の3ステージで十分なことが多いです（実際、私のHubSpot環境ではそうしています）。大事なのは数よりも「リードを集める人と商談する人が分かれているかどうか」という運用の現実で判断することです。

## ライフサイクルステージとは

ライフサイクルステージは、見込み客が自社を知ってから顧客になり、さらには推奨者になるまでの旅路を段階的に分類したものです。HubSpotではデフォルトで以下のステージが用意されています（[公式ナレッジベース: ライフサイクルステージの使用](https://knowledge.hubspot.com/contacts/use-lifecycle-stages)）。

| ステージ | 意味 | 誰が判断するか |
| --- | --- | --- |
| 登録読者（Subscriber） | メールの受信に同意したが、それ以上のアクションが少ない段階 | 自動 |
| リード（Lead） | 基本情報（名前、メール等）を提供し、見込み客として認識された段階 | 自動（フォーム送信等） |
| MQL（Marketing Qualified Lead） | マーケティングチームが「営業に渡して良い」と判断した見込み客。スコアリングや行動データに基づく | マーケティング（自動化） |
| SQL（Sales Qualified Lead） | 営業チームが実際に接触し「見込みあり」と確認した見込み客 | 営業（手動 or 半自動） |
| 商談（Opportunity） | 取引レコードに紐づき、具体的な商談が進行中の段階 | 営業（手動） |
| 顧客（Customer） | 成約に至った段階 | 自動（取引クローズ） |

ポイントは「**MQLはマーケティングが判断し、SQLは営業が判断する**」という役割分担です。Lars Helgeson著『[CRM for Dummies](https://www.wiley.com/en-us/CRM+For+Dummies-p-9781119368984)』（Wiley, 2017）では、MQLを「チャネルを通じて興味を示し、自ら購入の適格性を選択した（self-selected）リード」、SQLを「営業担当者との会話を経て、見込みありと確認されたリード」と定義しています。この区別が曖昧だと、後述する遷移条件やレポートの設計が全て崩れてしまいます。

## ライフサイクルステージの重要性と設計原則

ライフサイクルステージはHubSpotのCRMにおいて、非常に重要な役割を持っています。各ステージにどれくらい分布しているのか、次のステージに進むのにどれくらい時間がかかっているのかなど。

過去、私が担当していた企業様（BtoB）ではMarketing HubとSales Hubの両方を利用してリード獲得から顧客になるまでのアクションを管理、その成果をレポートで計測していました。

営業としてアクションを行うのは商談に近い **QL（Qualified Lead）** に絞り、その前の人にはシナリオメール・週次メールでアプローチを行う。ライフサイクルステージのカスタマイズによって、手当たり次第ではなくセグメントを切って効率的にアプローチができるようになりました。

![ライフサイクルステージによるマーケティングとセールスのアプローチの切り分けを示す図](https://anguilact.co.jp/hubfs/blog-migration-20261002/e0a71bf0d1df08808fb22692.webp)

### マクロとミクロを混同しない

ライフサイクルステージの設計で最初に理解しておくべきなのが、**マクロ（バイヤージャーニーの大枠）とミクロ（日々の営業活動）の分離**です。

ライフサイクルステージはあくまで「この人は今、購買プロセスのどこにいるか」を示すマクロな指標です。「電話をかけた」「ミーティングを設定した」といったミクロな営業活動の進捗は、HubSpotの**リードオブジェクト**や**リードステータス**で管理します。

この区別をつけずにライフサイクルステージに細かい営業活動を組み込もうとすると、ファネルレポートが汚れて使い物にならなくなります。

![ライフサイクルステージ（マクロ）とリードオブジェクト・リードステータス（ミクロ）の役割の違いを示す図](https://anguilact.co.jp/hubfs/blog-migration-20261002/d4e9d05a8d4360779c78637b.webp)

「ライフサイクルステージ」と「リードオブジェクトのステージ」、「リードステータス」の概念の違いに関する記事「[HubSpot SalesHubの「リードの管理」で見込み顧客に対する活動を見直す- 混乱しないための概念理解](https://anguilact.co.jp/articles/hubspot-saleshub-how-to-use-sales-leads#%E6%B7%B7%E4%B9%B1%E3%81%97%E3%81%AA%E3%81%84%E3%81%9F%E3%82%81%E3%81%AE%E6%A6%82%E5%BF%B5%E7%90%86%E8%A7%A3)」を書いています。もしよければご覧ください。

### 定義を決める際の注意点

組織としてHubSpot（のライフサイクルステージ）を活用していくと決めた場合、営業、マーケティング、カスタマーサポートの関係者全員の意見が入っているかは考慮すべきでしょう。

定義の基準は、主観的な判断ではなく**測定可能なデータポイント**に基づくことが大切です。「営業担当者が興味を持っていると感じた」ではなく、「HubSpotスコアが100pt以上に到達した」「デモ依頼フォームを送信した」のように、誰が見ても同じ判断ができる条件にすることで、データの整合性が保たれます。

例えば、以下はマーケチームが独断で定義を決めた場合に起こりうるセールスチームとの軋轢の例です。

- **SQLの質が低下し、セールスの負担が増加**  
   MQLからSQLへの基準が緩く、適切に絞り込まれていないリードがセールスチームに渡され、その結果、セールスが不適格なリードに時間を費やすことになり、商談の成功率が下がる。
- **マーケティングとセールスの間で不満が生じる**  
   マーケティング側は「MQLを十分に送っているのに成果が出ない」と考え、セールス側は「質の悪いリードばかり来る」と感じる。チーム間の信頼関係が損なわれ、連携がうまくいかなくなる。
- **データの不一致によるパフォーマンス分析の困難化**  
   ライフサイクルステージの定義がセールスの実態と乖離しているため、適切なKPI分析ができない。例えば、SQLが多く創出されているのに商談化率が極端に低い場合、どこに課題があるのか判断しづらくなる。

一度こじれると立て直しにはかなりの時間と労力がかかります。なので最初から全員を巻き込んで決めるのが、結局は近道です。

## ライフサイクルステージの遷移条件

以下の表は、HubSpotでライフサイクルステージの遷移条件の例です。トリガー条件は、次のステージに移動するために必要な要素となります。

| ライフサイクルステージ遷移 | トリガー条件（例） | 測定可能な基準（WFトリガー例） |
| --- | --- | --- |
| 登録読者→リード | 基本情報（姓、名、会社名、Eメール）の取得 自社の顧客層にマッチするか | TOFUコンテンツフォームの送信 マーケティングOpsによるCSVインポート |
| リード→MQL | 製品関連コンテンツの閲覧・ウェビナーへの参加 導入事例やお役立ちコンテンツなどのフォーム入力 高意図フォーム（デモ依頼・見積もり依頼・問い合わせ）の送信 | HubSpotスコアが閾値（例: 100pt）到達 高意図フォームの送信 |
| MQL→SQL | 営業がMQLを確認し、有効なリードと認定 初回の電話・メールで接触し、見込みありと判断 | リードオブジェクトのステータスが「承認済み」に変更 営業担当者による初回アクティビティ（メール/電話/ミーティング）のログ |
| SQL→商談 | BANT基準（予算・決裁権・ニーズ・時期）の充足 具体的な提案・見積もりフェーズへの移行 | 取引レコードの作成＋パイプラインステージへの移動 |
| 顧客 | 成約 | 取引が「クローズド（成立）」に移動 |

ライフサイクルステージは基本、登録読者〜顧客までの一本線のように書かれることが多いですが、実際の運用では、商談で不成立だった相手が時間が経って改めてアプローチしたら契約に至ることもあります。これは再活性化（リアクティベーション・掘り起こし）と呼ばれています。

### ステージを戻したくなった時の運用

商談が不成立になった時や、MQLからSQLへの昇格に失敗した時、ライフサイクルステージを前のステージに戻したくなる気持ちは分かります。ただし、これはお勧めしません。

そもそもHubSpotのライフサイクルステージは前進のみを前提に設計されています。前のステージに戻すには一度値をクリアする必要がありますが、その瞬間に「Became an Opportunity Date（商談化日）」等のタイムスタンプが消えます。つまり、ファネルレポートやステージ滞在時間の分析データが壊れてしまうのです。

**推奨は「ステージは維持して、現在の状態は別のプロパティで管理する」方法です。**

- ライフサイクルステージは到達した段階のまま残す（履歴として保持）
- 「今追っているか」「失敗した理由」はカスタムプロパティ（例：qualification\_status = 対応中 / 保留 / NG）や取引のステージで表現する
- 再アプローチの判断も、これらのプロパティを基にワークフローやリストで管理する

これがまさに前述した「マクロとミクロの分離」の実践例です。マクロなライフサイクルステージは履歴として保持しつつ、ミクロな営業活動の状態はカスタムプロパティや取引で管理するわけです。

#### 失注理由で担当者を分ける

もう一つ重要なのが、失注理由によって「誰が担当するか」を分けることです。

| 失注理由 | 担当 | アクション |
| --- | --- | --- |
| タイミングが合わなかった | 営業が継続 | 90日後のフォローアップタスクを自動作成 |
| 予算不足・競合に負けた | マーケティングに返送 | コンタクトオーナーをクリア → ナーチャリングリストに追加 |

この分岐を自動化するには、取引を失注に移動する際に**失注理由を必須入力にする**のがポイントです。自由入力ではなくドロップダウン形式にしておけば、ワークフローのトリガーとして使えます。

#### 商談前の脱落も同じ原則

この「戻さない」原則は、失注だけでなく、MQLやSQLの段階で脱落したケースにも当てはまります。

| 脱落パターン | ライフサイクルステージ | 状態の管理方法 |
| --- | --- | --- |
| MQL→SQLに至らなかった（架電NG・ターゲット外） | MQLのまま維持 | カスタムプロパティ（例：qualification\_status）で「NG」「保留」等を管理 |
| SQL→商談に至らなかった（日程NG・予算消滅） | SQLのまま維持 | カスタムプロパティで「一旦停止」「クローズ」等を管理 |
| 商談→失注 | 商談のまま維持 | 取引ステージ「失注」＋失注理由を記録 |

共通する原則は、**ライフサイクルステージは「どこまで到達したか」の最高到達点として残す**ということです。「失敗した」「今は追っていない」という現在の状態は、カスタムプロパティや取引など別の軸で表現します。

なお、1人のコンタクトに対して別プロダクト・別キャンペーンで並行して追客するような運用が出てきた場合は、HubSpotのリードオブジェクトの導入を検討してください。リードオブジェクトを使えば、コンタクト単位ではなく「追客の単位」ごとに独立したサイクルを回せるようになります。

### ワークフローでレポートを守る

ライフサイクルステージの運用で意外と見落としがちなのが、**ステージをスキップするとファネルレポートが壊れる**という問題です。

例えば、初めてサイトに来た人がいきなりデモ依頼フォームを送信した場合を考えてみてください。本来は「登録読者→リード→MQL→SQL」と段階を踏むところを、一気に「SQL」に飛んでしまう。するとHubSpotのファネルレポートでは、このコンタクトは「リード」も「MQL」も通過していないことになり、各ステージのコンバージョン率が正しく計算されなくなります。

これを防ぐためにワークフローでシステム上は全ステージを通過した記録が残るように設定することができます。

![HubSpotのウォーターフォールワークフローの設定画面。リード・MQL・SQLの各ステージを順次設定するアクションが並んでいる](https://anguilact.co.jp/hubfs/blog-migration-20261002/4bd6d875edd3885cd1db4f24.webp)

見た目は一瞬ですが、ファネルレポート・ステージ滞在期間のレポートが正確に機能するようになります。ファネルレポートの数値がおかしいと思ったら、まずこのウォーターフォール設計ができているか確認してみてください。

ワークフローの設計について詳しくは、こちらの記事「 [HubSpotワークフローの設計・設定ガイド](https://anguilact.co.jp/articles/hubspot-workflow-guide)」でも解説しています。

## ライフサイクルステージの設定

定義が決まれば、あとはワークフローで自動化設定をして、計測環境を整えるだけです。

### ワークフローを使うときは初期設定はOFFにする

微妙という言葉以外にあまりいいものが浮かばなかったのですが、初期の設定は実際微妙だと個人的には思ってます（変更は設定＞データ管理＞オブジェクト＞コンタクト＞ライフサイクルステージから。[公式: ライフサイクルステージの自動設定と同期](https://knowledge.hubspot.com/object-settings/manage-how-lifecycle-stages-sync-between-objects)）。

**初期状態の設定（ステージは変更可能）**

- コンタクト or 会社が作られた＝リード
- 取引が作成された＝商談
- 取引が成立した＝顧客

この設定しかないので、リード〜MQL・SQL間のステージ滞在時間などが分からない。どれくらいリードから取引作成までかかっているのか、何がダメで詰まっているのか等が判断しづらいです。

なので「ライフサイクルステージを使うぞ！」となったら、基本的に初期設定は全てOFFにしてワークフローを使った自動化を行います（ワークフローの利用可能なプランはPro以上から）。デフォルトの自動化とカスタムワークフローが同時に動くと競合が起き、予測不能なデータの上書きが発生するためです。

### その他の設定ポイント

- **担当者レベルの手動編集を制限する**  
   担当者各自が各人の判断で更新してしまうと、データの整合性が取れなくなります。Enterpriseプランではプロパティーごとにアクセス権限を編集できますが、そのためにEnterpriseを契約することはないと思うので、触らないように工夫する必要があります。
- **一度全てのコンタクトのステージを初期化する**  
   ライフサイクルステージを変える時は、レポーティングで差異が出ないよう、初期化してから定義したステージに移動させてください。初期化の際は、全てのステージを順に踏ませてファネルレポートの遷移を綺麗に残します（前述のウォーターフォールWF）。
- **ステージ名は自社に合わせてカスタマイズする**  
   ライフサイクルステージの名称は初期設定から自由に変えて問題ありません。関係者全員で話し合い、自社に合ったそれぞれのステージ名を決めたほうが納得感が生まれるはずです。

### 隠しフォームフィールドでルーティングを効率化

フォームの裏側に`Conversion_Type`などの非表示フィールドを設定しておくと、ワークフローのトリガーがフォーム名の変更で壊れるリスクを回避できます。

「最近のコンバージョンが〜を含む」というトリガーは脆いので、可能であれば隠しフィールドの値でルーティングする方が安全です。

フォームの設定について詳しくは、こちらの記事「[HubSpotフォームの設定・活用ガイド](https://anguilact.co.jp/articles/hubspot-form-guide)」もご覧ください。

### ワークフローはシンプルに保つ

特定のステージになったら、内部通知を送る・タスクを作成するといったアクションを設定することも今後あるでしょう。

ワークフローはシンプルであった方が良いと思っているので、そういった時にはライフサイクルステージのワークフローにアクションを追加せず、別で内部通知用（シナリオメール用）のアクションを用意するのがお勧めです。

## ライフサイクルステージの計測

ライフサイクルステージの成果を計測する際に見る指標は主に以下の3つです。

- **各ステージの件数**
- **ステージ間の移行率**
- **ステージ移動にかかった時間（滞在時間）**

![ファネルレポートの表示画面](https://anguilact.co.jp/hubfs/blog-migration-20261002/5f281445e8d5ce12576a6898.webp)

[ファネルレポート](https://knowledge.hubspot.com/reports/create-new-custom-funnel-reports)がHubSpotでは用意されていますが、利用することで各ステージにどれくらいの件数が存在しているのかがわかります。

### ステージ滞在時間の計算プロパティ

HubSpotは、すべてのライフサイクルステージに対して以下の[計算プロパティを自動生成](https://knowledge.hubspot.com/properties/stage-calculated-properties)しています。

| プロパティ | 内容 |
| --- | --- |
| `Date entered [stage]` | そのステージに入った日時 |
| `Date exited [stage]` | そのステージから出た日時 |
| `Latest time in [stage]` | 直近の滞在時間（秒単位） |
| `Cumulative time in [stage]` | 累積滞在時間（秒単位） |

これらを使ってカスタムレポートを組めば、平均セールスサイクルの長さや、どのステージで勢いを失っているかをデータに基づいて把握できます。

### 監視すべきレポート

ダッシュボードには以下のようなレポートを入れておくと、異常値やデータ品質の問題を早期に発見できます。

| レポート | 目的 |
| --- | --- |
| LCS分布ファネル | MQLが膨れすぎていないか等のボトルネック特定 |
| 孤児コンタクト（会社未紐付け） | 会社レコードに紐づいていないコンタクトのデータ品質チェック |
| スキップされたステージ | 「商談移行日あり」だが「SQL移行日なし」のコンタクト → WF設定不備の検知 |
| ステージ滞在時間 | セールスサイクル分析。どこで詰まっているかの可視化 |

### レポートは作って終わりじゃない

一度ダッシュボード・レポートを作成したらそこで終わり...ではありません。

過去、商談が進んでいるのにSQLに残っているコンタクトがあった際に原因を調査すると、ステージ「商談」のトリガー条件がHubSpotのミーティングリンクで予約が完了でしたが、そのコンタクトにはHubSpotのミーティングリンクを使わず商談を進めていた、みたいなことがありました。

ステージ移行の前提条件と実際のオペレーションがちゃんと実行されているかを確認、その後レポートの数値が正しいものか、定期的に確認する必要があります。

## 執筆後記：時代はダブルファネル？

ライフサイクルステージはリードから顧客になるにつれて段々対象となるコンタクトの数が少なくなることからファネル型を形成します。レポートでもファネル型が標準で用意されています。

しかし、実際の企業活動では顧客の数はどんどん減っていくのではなく、増えていくはずです。サブスクリプションサービスでは、契約後どれくらい長く契約し続けてくれるかが大事です。

そういった意味では、ライフサイクルステージの顧客は終点ではなく、新たな逆ファネルへの入り口なのかもしれません。

もしHubSpotの使い方や運用についてお悩みがあればぜひお気軽にご相談ください。

## 執筆者

![西岡草実（にしおかそうま）のプロフィール写真](https://anguilact.co.jp/hs-fs/hubfs/anguilact/site-images/profiles/nishioka-profile-landscape-1200.jpg?width=112&height=112&name=nishioka-profile-landscape-1200.jpg)

### 西岡草実（にしおかそうま）

香川県坂出市生まれ。デジタルマーケティングの支援会社にてコンテンツディレクターとして自然検索流入（SEO）を考慮したテーマの設計や、検索ニーズを踏まえたコンテンツ制作・効果分析に従事。その後、HubSpotコンサルタントとしてHubSpotの導入と運用支援を担当し、企業のインバウンドマーケティングの定着に努める。

[X](https://x.com/240k_s) [LinkedIn](https://www.linkedin.com/in/soma-nishioka/)

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

ニュースレター

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

読み物

## 関連記事

### [![HubSpotプロパティの種類・設定・管理方法を徹底解説](https://anguilact.co.jp/hubfs/anguilact-hubspot-property-guide-thumbnail.png) HubSpotプロパティの種類・設定・管理方法を徹底解説 西岡草実（にしおかそうま）Oct 6, 2026, 4:14:32 AM 旧記事の公開日：2025.03.09](https://anguilact.co.jp/articles/hubspot-properties-guide)

### [![HubSpotの再設計。見直すべきサインと進め方](https://anguilact.co.jp/hubfs/anguilact-hubspot-redesign-thumbnail.png) HubSpotの再設計。見直すべきサインと進め方 西岡草実（にしおかそうま）Oct 6, 2026, 4:14:28 AM 旧記事の公開日：2025.02.08](https://anguilact.co.jp/articles/hubspot-reconfiguration-steps-checklist)

### [![HubSpotワークフローの作り方。設定手順・トリガー・活用例を解説](https://anguilact.co.jp/hubfs/anguilact-hubspot-workflow-guide-thumbnail.png) HubSpotワークフローの作り方。設定手順・トリガー・活用例を解説 西岡草実（にしおかそうま）Oct 6, 2026, 4:12:14 AM 旧記事の公開日：2025.12.12](https://anguilact.co.jp/articles/hubspot-workflow-guide)

![](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-05T19:14:23.128Z",
  "datePublished" : "2026-10-05T19:14:23.000Z",
  "headline" : "HubSpotライフサイクルステージの設計・設定・運用ガイド。MQL→SQLの遷移設計と計測｜Anguilact（アンギラクト）",
  "image" : [ "https://anguilact.co.jp/hubfs/anguilact-hubspot-lifecycle-stages-thumbnail.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://anguilact.co.jp/articles/hubspot-lifecyclestages",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://anguilact.co.jp/hubfs/anguilact-e4-jp-en.svg"
    },
    "name" : "アンギラクト株式会社"
  }
}
```