---
title: Claude Code Monitorとは｜ログ監視をリアルタイム自動検知
description: Claude Code Monitorは、シェルコマンドのstdout出力をイベントとして受け取り、条件に合致した行が出た瞬間だけClaudeが反応する監視機能です。沈黙中はトークンを消費しない設計で、ログ監視・CI/CD失敗検知・デプロイ後ヘルスチェックへの活用法と運用設計を解説します。
image: https://start-link.jp/hubfs/blog/screenshots/generated/kv_claude-code-monitor-tool.jpg
---

[![StartLink](https://start-link.jp/hs-fs/hubfs/logo/%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink")](https://start-link.jp)

- [会社情報About](https://start-link.jp/about)
- [サービスService](https://start-link.jp/service)
- [プロダクトProducts](https://start-link.jp/sync)
- [YoutubeYoutube](https://start-link.jp/about/sns)
- [ブログBlog](https://start-link.jp/hubspot-ai)
- [導入事例Case studies](https://start-link.jp/case)
- [採用情報Recruit](https://start-link.jp/recruit)

[資料DL](https://start-link.jp/download/service) [無料相談 →](https://start-link.jp/contact)

[会社情報](https://start-link.jp/about) [サービス](https://start-link.jp/service) [プロダクト](https://start-link.jp/sync) [Youtube](https://start-link.jp/about/sns) [ブログ](https://start-link.jp/hubspot-ai) [導入事例](https://start-link.jp/case) [採用情報](https://start-link.jp/recruit)

[資料ダウンロード](https://start-link.jp/download/service) [無料相談 →](https://start-link.jp/contact)

- [トップ](https://start-link.jp)
- [会社情報](https://start-link.jp/about)
- [サービス](https://start-link.jp/service)
- [Youtube](https://start-link.jp/about/sns)
- [ブログ](https://start-link.jp/hubspot-ai)
- [Contact](https://start-link.jp/contact)
- [個人情報保護方針](https://start-link.jp/privacy-policy)
- [個人情報取り扱い規定](https://start-link.jp/personal-information-processing-agreement)

[ホーム](https://start-link.jp) › [ブログ](https://start-link.jp/hubspot-ai) ›[AI活用](https://start-link.jp/hubspot-ai/ai) ›[Claude Code実践](https://start-link.jp/hubspot-ai/ai/claude-code-practice) ›Claude Code Monitorとは｜ログ監視をリアルタイム自動検知

# Claude Code Monitorとは｜ログ監視をリアルタイム自動検知

- 2026年4月11日
- 最終更新: 2026年10月4日

[AI](https://start-link.jp/hubspot-ai/tag/ai) [生成AI](https://start-link.jp/hubspot-ai/tag/生成ai)

![](https://start-link.jp/hubfs/blog/screenshots/generated/kv_claude-code-monitor-tool.jpg)

この記事の結論

Claude CodeのMonitorツールを使えば、サーバーログやCI/CDの出力をリアルタイムに監視し、異常が起きた瞬間だけClaudeが反応する仕組みを作れます。人の目視に頼らず、仕組みで監視する発想が、DevOps・SREの監視運用を変える一手です。

ブログ目次

もっと見る ▼

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

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

[サービス概要を見る](https://start-link.jp/service/hubspot-ai) [無料で相談する](https://start-link.jp/contact)

**Claude CodeのMonitorツールを使えば、サーバーログやCI/CDの出力をリアルタイムに監視し、異常が起きた瞬間だけClaudeが反応する仕組みを作れます。人の目視に頼らず、仕組みで監視する発想が、DevOps・SREの監視運用を変える一手です。**

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

「本番のログをターミナルに張り付いて目視で追いかけている」「CI/CDが落ちても気づくのはSlack通知が来てから」——DevOpsやSREの現場では、こうした「待ち」の作業に時間が割かれています。

Monitorツールとは、シェルコマンドのstdout出力をイベントストリームとして受け取り、指定した条件に合致した行が出力された瞬間にClaudeが反応する、Claude Codeのイベント駆動型監視機能です（本記事の内容はv2.1.98時点の仕様に基づきます）。コマンドが沈黙している間はトークンを消費しない設計のため、定期的にチェックを回し続けるポーリング型監視とは構造が異なり、リアルタイムに近い反応速度で異常を検知できます。この記事では、「検知・分析・判断の分離」という軸で、その仕組みと実務での活用パターンを整理します。

## この記事でわかること

Monitorツールの基本的な仕組みから、ログ監視・CI/CD・デプロイ後のヘルスチェックまで、現場で使える活用パターンと運用設計を整理します。読み進めることで、自社の監視業務のどこからMonitorツールを導入すべきかが見えてきます。

- **Monitorツールの仕組みと構文** — シェルコマンドを起動し、stdoutの各行をnotificationとしてClaudeに送る仕組みと基本構文を解説します
- **ポーリング型監視との違い** — `/loop`やsleepループとの構造上の違いを比較表で整理し、使い分けの目安を示します
- **ログ監視・CI/CD・デプロイ後ヘルスチェックの実践パターン** — Kubernetes・Docker・GitHub Actions・ヘルスエンドポイントなど、具体的なコマンド例で紹介します
- **HubSpot連携開発での活用** — WebhookデバッグやCRMイベント監視など、HubSpotと組み合わせた開発現場での使いどころを解説します
- **「検知・分析・判断の分離」で組み立てる監視運用** — トークン効率を保つ運用設計の考え方に加え、Monitorが向かない場面も率直に共有します

**対象読者**: DevOps・SRE・開発リーダーの方に向けて書いています。最後まで読むと、自社のどの監視業務からMonitorツールを試すべきかを判断し、最初の一歩を踏み出せるようになります。

## Monitorツールとは

Monitorツールは、Claude Codeのツール群に含まれるイベント駆動型の監視機能です。「コマンドを裏で回し続け、出力があった瞬間だけClaudeに伝える」という役割を担います。まずは仕組みと反応の流れ、基本構文の順に押さえていきます。

### イベント駆動型の仕組み

Monitorツールは、指定したシェルコマンドをバックグラウンドで起動し、そのstdout（標準出力）の各行を「notification（通知）」としてClaudeのメインセッションに送ります。コマンドが出力を生成しない間、つまり監視対象に異常がない間は、Claudeへ送る情報自体が発生しないためトークンを消費しません。出力が発生した瞬間にだけClaudeが反応し、分析や対応の提案を始めます。

これは「人がターミナルに張り付いて目視で監視する」という運用を、仕組みで置き換える発想です。エンジニアの注意力に依存する監視は、疲労や他業務との兼務によってどうしても見落としが発生しやすくなります。検知を仕組みに任せる体制にしておけば、担当者が変わっても同じ精度で監視を継続でき、新人が加わったときにも監視のやり方を引き継ぎやすくなります。個人の力量ではなく仕組みで解決する、という考え方がここでも生きてきます。

### 通知が届いてからClaudeが動く流れ

notificationが発生してからClaudeが反応するまでの流れは、次のように整理できます。

1. 監視対象のコマンドがstdoutに1行を出力します
2. その行がnotificationとしてメインセッションに届きます
3. Claudeが行の内容を読み取り、エラーの種類や緊急度を推定します
4. 原因分析や対応案の提示など、あらかじめ指示していた役割を実行します

つまりMonitorは「検知のトリガー」を担う部品であり、検知後に何をするかはセッション側の指示次第という設計です。ここで「検知・分析・判断」を分けて考えると、検知と分析はAIに任せ、本番環境への操作判断は人が持つという役割分担を組み立てやすくなります。この「検知・分析・判断の分離」は、本記事全体を通した運用設計の軸であり、後述するロールバック判断の場面で特に重要になります。

### 基本的なコマンド構文

Monitorツールの構文はシンプルで、監視したいコマンドをそのまま指定します。

```
# Monitorツールの基本的な使い方
# kubectl logsをバックグラウンドで監視し、errorを含む行が出たらClaudeに通知
Monitor: kubectl logs -f deployment/api-server | grep error
```

このように、既存のログコマンドやCLIツールをパイプでつなぐだけで監視を開始できます。ただし、フィルタなしで大量出力されるコマンドをそのまま監視すると、notificationが大量に発生してトークン消費がかさむため、後述するフィルタリング設計が重要になります。

## ポーリング型監視との違い

Monitorツールの特徴を理解するには、従来のポーリング型監視との構造上の違いを押さえるのが近道です。監視方式の違いは、トークン消費という運用コストと異常への初動速度に関わるため、方式の選択そのものが運用設計の論点になります。ここでは`/loop`やsleepループとの比較を整理し、どちらを選ぶべきかの判断材料を示します。

### /loopやsleepループとの比較

従来のポーリング型監視（`/loop`やsleepを使った定期チェック）は、何も起きていなくても一定間隔でコマンドを実行し、そのたびにトークンを消費する構造でした。Monitorツールはこの構造そのものを変える設計になっています。

| 項目 | Monitorツール | /loopコマンド | sleep + Bashループ |
| --- | --- | --- | --- |
| 動作方式 | イベント駆動型 | ポーリング型 | ポーリング型 |
| トークン消費 | 沈黙中は発生しない | 実行間隔ごとに発生 | 実行間隔ごとに発生 |
| 反応速度 | 出力と同時（リアルタイムに近い） | 間隔分の遅延が生じる | 間隔分の遅延が生じる |
| メインセッション | ブロックしない | ブロックする | ブロックする |
| 適したユースケース | ログ監視・ストリーム処理 | 定期チェック・状態確認 | 単発の待機処理 |

イベント駆動とポーリングは、それぞれ得意な場面が異なる関係にあります。「ストリーム出力の各行に即座に反応したい」場面はMonitor、「一定間隔で状態を確認したい」場面は`/loop`が向いています。この表はあくまで構造上の違いの整理なので、優劣ではなく用途に合わせて使い分ける前提で読んでください。

### メインセッションをブロックしない構造

Monitorツールのもう一つの強みは、監視を開始した後もClaudeに別の作業を指示できる点です。ログ監視を裏で走らせながら、コードレビューやドキュメント作成を並行して進められます。この「監視と並行作業を両立できる」構造は、少人数でDevOps・SRE業務を回すチームほど価値が大きくなります。

## サーバーログのリアルタイム監視

サーバーログの監視は、Monitorツールの効果を実感しやすい領域の一つです。ログから異常をどれだけ速やかに検知できるかは、サービスの信頼性と障害対応の初動に直結する、運用品質上の論点でもあります。ここではKubernetes・Docker・Nginxの3つの環境での監視パターンを紹介します。いずれも「エラー行だけを抽出してClaudeに渡す」という設計思想は共通しています。

### Kubernetesクラスタのエラー検知

本番環境のKubernetesクラスタで稼働するPodのログを監視し、エラーが発生した瞬間にClaudeが原因分析を行うパターンです。

```
# Kubernetesのapi-serverデプロイメントのログを監視
Monitor: kubectl logs -f deployment/api-server --all-containers | grep -i "error\|exception\|fatal"
```

このコマンドを実行すると、`kubectl logs -f`がPodのログをストリーミングし、`grep`がエラー関連のキーワードを含む行だけをフィルタリングし、通過した行がClaudeにnotificationとして送信され、Claudeがエラーの内容を分析して原因の推定や対応策を提示する、という流れが自動的に動きます。手動でログを監視する場合、エンジニアはターミナルに張り付いてスクロールし続ける必要がありますが、Monitorツールを使えばその時間を他の作業に充てられます。

### Dockerコンテナのログ監視

Kubernetes以外のDocker環境でも同様のパターンが使えます。

```
# 特定のDockerコンテナのログを監視
Monitor: docker logs -f my-app-container 2>&1 | grep -E "ERROR|WARN|panic"
```

`2>&1`でstderrもstdoutに合流させることで、エラー出力の取りこぼしを減らせます。コンテナ名を変えれば複数コンテナの監視にも流用できるため、自社の構成に合わせて調整してください。

### Nginxアクセスログの異常検知

Webサーバーのアクセスログから5xxエラーを検知し、サーバー側の問題を即座に把握するパターンです。

```
# Nginxアクセスログから5xxエラーをリアルタイム検知
Monitor: tail -f /var/log/nginx/access.log | grep -E '" (5[0-9]{2}) '
```

5xxエラーが発生するたびにClaudeが通知を受け取り、エラーの傾向やリクエストパターンを分析します。障害の兆候を早期に発見できるため、ダウンタイムの短縮につながります。ただし、grep条件の設計次第で検知精度が変わるため、自社のログ形式やエラーコードの出方に合わせてパターンを調整することが重要です。汎用的な条件をそのまま流用するのではなく、自社のシステム構成にフィットしたフィルタ設計が欠かせません。

## CI/CDパイプラインの自動監視

CI/CDの現場では、「ビルドが落ちたことに気づくのが遅れる」という課題がよく起きます。失敗への気づきの速さはリリース品質と開発チームの生産性に響くため、属人化しない検知の仕組みが求められます。Monitorツールをビルドログの監視に使うことで、失敗の検知から原因分析までを自動化できます。

### ビルド失敗の自動検知と修正提案

GitHub Actionsのワークフロー実行をMonitorツールで監視し、失敗した場合にClaudeが原因を分析するパターンです。

```
# GitHub Actionsのワークフロー実行を監視
Monitor: gh run watch --exit-status 2>&1
```

`gh run watch`はワークフローの進行状況をストリーミング出力します。ビルドが失敗すると、その出力がClaudeに通知され、失敗したステップの特定、エラーメッセージの解析、過去の類似エラーとの比較、修正コードの提案といった分析が自動的に行われます。ただし、修正コードの提案はあくまで叩き台であり、本番へのマージ判断は開発者が行うべき領域です。

### テスト結果のリアルタイム追跡

大規模なテストスイートの実行を監視し、失敗するテストが出たら即座に把握するパターンです。

```
# Jestテストの実行をリアルタイム監視（失敗のみフィルタ）
Monitor: npx jest --watch 2>&1 | grep -E "FAIL|Error"
```

テストが失敗するたびにClaudeが通知を受け取り、失敗したテストの内容と修正方針を提示します。テスト駆動開発のサイクルを、AIが裏方でサポートする形です。

## デプロイ後のヘルスチェックとロールバック判断

デプロイ直後は、システムが正常に稼働しているかを確認する「待ち」の時間が発生しやすい局面です。ここでの確認を仕組み化できるかどうかは、障害時の影響範囲を抑える運用品質に関わります。この待ち時間をMonitorツールに任せることで、エンジニアは他の作業に集中できます。

### ヘルスエンドポイントの連続監視

デプロイ直後のサービスが正常に稼働しているかを、ヘルスチェックエンドポイントで確認し続けるパターンです。

```
# ヘルスチェックを5秒間隔で実行し、異常時のみClaudeに通知
Monitor: while true; do STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health); if [ "$STATUS" != "200" ]; then echo "HEALTH CHECK FAILED: HTTP $STATUS at $(date)"; fi; sleep 5; done
```

HTTP 200以外のレスポンスが返った瞬間にClaudeが通知を受け取ります。通知が来ない間はトークンを消費しない設計のため、長時間のヘルスチェック監視も効率的に運用できます。なお、例の5秒という間隔は固定値ではなく、サービスの重要度や許容される検知遅延に合わせて調整する値です。

### ロールバック判断を支える情報整理

Monitorの出力をもとに、Claudeが「ロールバックすべきかどうか」の判断材料を整理するパターンも有効です。デプロイ後にエラー率が急増した場合、Claudeはエラーの発生頻度と増加傾向、影響を受けているエンドポイント、直前のデプロイで変更されたファイル、ロールバック手順のドラフトといった情報をまとめて提示します。

ここで意識しておきたいのは、Claudeが行うのはあくまで「情報整理と提案」までという役割分担です。役割を表に整理すると次のようになります。

| 工程 | 担い手 | 内容 |
| --- | --- | --- |
| 検知 | AI（Monitor） | 異常行の出力をnotificationとして受け取る |
| 分析 | AI（Claude） | エラーの傾向・影響範囲・原因候補を整理する |
| 提案 | AI（Claude） | ロールバック手順のドラフトを提示する |
| 実行判断 | 人 | 本番操作の可否を確認して実行する |

ロールバックの実行という本番環境への操作は影響が大きいため、担当者が内容を確認したうえで実行することをおすすめします。検知と分析はAI、実行判断は人、という線引きを事前に決めておくと、運用に迷いが生じません。

## HubSpot運用におけるMonitorツールの活用

Monitorツールは、サーバーやCI/CDだけでなく、HubSpotと連携した開発・運用のデバッグにも活用できます。HubSpotをCRMの中核として、コンタクト獲得から取引、顧客対応、請求までの業務フローを一気通貫で回している場合、WorkflowやWebhookはその血流にあたる部分です。Monitorツールは、その裏側の開発・運用を支える位置づけとして捉えると全体像が整理しやすくなります。ここでは2つの実践パターンを紹介します。

### Webhook受信のローカルデバッグ

HubSpotのWebhookをローカル環境でデバッグする際にも、Monitorツールは役立ちます。ngrokやcloudflaredのトンネルログを監視し、Webhook受信の成否をリアルタイムで確認できます。

```
# ngrokのリクエストログを監視
Monitor: curl -s http://localhost:4040/api/requests/http | jq -r '.requests[] | "\(.request.method) \(.request.url) -> \(.response.status_code)"'
```

HubSpotからのWebhookリクエストが到着するたびにClaudeが通知を受け取り、リクエストボディの構造やレスポンスコードを分析します。特にHubSpotのWorkflow Webhook（カスタムコードアクション）のデバッグでは、ペイロードの構造を即座に確認できるため、開発効率が上がります。

### HubSpot CRMイベントの監視

HubSpotのAPIを定期的に叩いてCRMイベントの変化を検知するパターンです。

```
# HubSpotの最近の取引更新を監視（30秒間隔で差分検知）
Monitor: while true; do curl -s "https://api.hubapi.com/crm/v3/objects/deals/search" \
  -H "Authorization: Bearer $HUBSPOT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"filterGroups":[{"filters":[{"propertyName":"hs_lastmodifieddate","operator":"GTE","value":"'$(date -d '1 minute ago' +%s000)'"}]}],"limit":5}' \
  | jq -r '.results[] | "Deal: \(.properties.dealname) | Stage: \(.properties.dealstage)"'; \
  sleep 30; done
```

取引のステージ変更やプロパティ更新をリアルタイムで把握できるため、CRM運用のデバッグや動作確認がスムーズになります。なお、例の30秒間隔や取得件数は一例であり、監視したいイベントの頻度やAPIの呼び出し制限に合わせて調整してください。取引データを一元管理するHubSpotのCRMと、開発側の監視の仕組みをつなげておくと、フロントの営業活動とバックエンドの開発状況を横断的に確認できる体制に近づきます。

Monitorツールでイベントを検知した後の対応を、AIエージェントによるCRM操作までつなげる設計も、一気通貫のフローを考えるうえでの選択肢の一つです。

上の画面は、StartLinkのWebサイト上でAIエージェントが音声・テキストを使い、会社・コンタクト・取引の作成やCRMデータの検索を行う例です。

以下の画面は、AIエージェントがWebサイト上で音声・テキストによりCRMデータを作成・検索する例です。

![AIエージェントがWebサイト上で音声・テキストによりCRMデータを作成・検索する例](https://start-link.jp/hubfs/blog/screenshots/library/agent_chat_website.png)

上の画面は、HubSpotのAI機能「Breeze」が関連取引4件を一括で「お見送り」に更新し、その結果が集計・レポートに反映される例です。

以下の画面は、Breezeが関連取引4件を一括で「お見送り」更新した結果です。

![Breezeが関連取引4件を一括で「お見送り」更新した結果](https://start-link.jp/hubfs/blog/screenshots/library/breeze_record_update2.png)

Monitorで検知したイベントを起点に、こうしたレコードの更新まで一連の流れとして設計しておくと、監視から記録、集計までが一気通貫でつながります。ただし、実際にCRMレコードを更新する処理は業務への影響が大きいため、自動化の範囲をどこまで広げるかは運用ルールと合わせて決めることをおすすめします。

## 「検知・分析・判断の分離」で組み立てる監視運用

Monitorツールを効果的に使うには、個別のコマンドを覚えるだけでなく、「検知・分析・判断の分離」を軸に開発ライフサイクル全体へ位置づける設計思想が重要です。属人化しない監視の仕組みは、組織の運用品質を底上げする経営上の論点でもあります。開発、CI/CDでのビルド検証、デプロイ、本番監視、障害対応、そして開発へのフィードバックという一連の流れを、Monitorツールを軸に横断的につなげて捉えることをおすすめします。個別の監視を場当たり的に追加するのではなく、一気通貫の運用フローとして設計することで、監視の効果が高まります。

### 複数Monitorの同時実行と使い分け

Monitorツールはメインセッションをブロックしないため、複数の監視を同時に走らせることが可能です。

```
# パターン1: アプリケーションログ監視
Monitor: tail -f /var/log/app/application.log | grep -i error

# パターン2: システムリソース監視（CPU使用率が90%超で通知）
Monitor: while true; do CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d. -f1); if [ "$CPU" -gt 90 ]; then echo "HIGH CPU: ${CPU}%"; fi; sleep 10; done

# パターン3: ディスク使用率監視
Monitor: while true; do DISK=$(df -h / | tail -1 | awk '{print $5}' | tr -d '%'); if [ "$DISK" -gt 85 ]; then echo "DISK WARNING: ${DISK}%"; fi; sleep 60; done
```

3つの監視が裏で動きながら、メインセッションではコードレビューやドキュメント作成を進められます。なお、例の90%・85%という閾値やチェック間隔は固定の仕様値ではなく、自社の環境やアラート基準に合わせて調整する値です。

ただし、監視対象を増やしすぎると、複数のnotificationが同時に到着した際にClaudeの処理が輻輳し、レスポンスが遅くなることがあります。同時実行数に公式な上限値はありませんが、実運用での目安として3〜5件程度に絞り、本当にリアルタイム検知が必要な項目だけをMonitorに割り当てることをおすすめします。

Monitorには、`run_in_background`パラメータ付きのBashツールという似た選択肢もあります。両者の使い分けは以下の通りです。

| 場面 | 推奨ツール | 理由 |
| --- | --- | --- |
| ログの継続的な監視 | Monitor | ストリーム型で各行にリアルタイム反応 |
| ビルド完了の待機 | run\_in\_background | 完了時に1回通知を受ければ十分 |
| テスト結果の追跡 | Monitor | 失敗行ごとに即座に対応したい |
| ファイルのダウンロード待ち | run\_in\_background | 完了まで待つだけでストリームは不要 |

「各行の出力に意味がある」場合はMonitor、「最終結果だけ知りたい」場合はrun\_in\_backgroundを選ぶのが基本方針です。目的に合わないツール選択はトークンの無駄遣いにつながるため、ここを意識するだけで効率が変わります。

### フィルタリングと出力頻度の設計

Monitorツールはstdoutの各行がnotificationになるため、フィルタなしで大量出力されるコマンドを監視するとトークン消費が膨らみます。

```
# 悪い例: 全ログ行がnotificationになる
Monitor: kubectl logs -f deployment/api-server

# 良い例: エラー行のみがnotificationになる
Monitor: kubectl logs -f deployment/api-server | grep -i "error\|exception"
```

`grep`や`awk`でフィルタリングしてからClaudeに送ることで、トークン消費を必要な分だけに抑えられます。自社が扱うログの重要度をどこで区切るかは、企業様によって最適な形は異なります。汎用的な条件をそのまま使うのではなく、自社の運用に合わせて閾値やキーワードを調整することが結構ミソになってきます。

高頻度で出力されるログの場合、`--line-buffered`オプションでバッファリングを制御することも有効です。

```
# grep --line-bufferedでリアルタイム出力を確保しつつフィルタリング
Monitor: tail -f /var/log/syslog | grep --line-buffered "CRITICAL\|ALERT"
```

### Monitorツールが向かないケース

Monitorツールは万能ではなく、向かないケースもあります。代表例と代替手段を整理すると次の通りです。

| 向かないケース | 向いている手段 |
| --- | --- |
| 一度きりのバッチ処理の完了を待つだけ | run\_in\_backgroundで完了通知を受け取る |
| SSH接続が不安定な環境でのリモート監視 | サーバー側での常駐監視や従来のポーリング |
| 通知が常時発生する高頻度ログ | フィルタを強化するか、ファイル出力と定期確認の併用 |

少数精鋭のチームでDevOps・SRE業務を回す場合、Monitorツールのようなイベント駆動型の自動化は価値が大きいと考えています。人手でカバーしきれない監視領域をAIに任せることで、エンジニアは本質的な設計や改善作業に集中できます。まずは開発環境の限定的なログ監視から試し、運用に慣れてきたら本番環境や複数系統の監視へ段階的に広げていくアプローチをおすすめします。仕組みを万能視せず、場面に応じて使い分ける姿勢が実務では重要です。

## よくある質問

### Q1. Monitorツールは何件まで同時に実行できますか？

Monitorツールの同時実行数に公式な上限値はありません。実運用での目安としては3〜5件程度に抑えることをおすすめします。監視対象が多すぎると、同時に複数のnotificationが到着した際にClaudeの処理が輻輳し、レスポンスが遅くなる可能性があります。監視項目を厳選し、本当にリアルタイム検知が必要なものだけをMonitorに割り当てるのが効果的です。

### Q2. Monitorツールと/loopコマンドはどちらを使うべきですか？

「ストリーム出力の各行に即座に反応したい」場合はMonitor、「定期的に状態をチェックしたい」場合は`/loop`を選ぶのが基本の目安です。例えば、サーバーログのエラー検知はMonitorが適しており、デプロイのステータスを数分おきに確認するような場合は`/loop`の方が向いています。両者は排他的ではなく、用途に応じて組み合わせて使えます。

### Q3. Monitorで監視しているコマンドが終了した場合はどうなりますか？

監視対象のコマンドが終了（プロセスが停止）すると、Monitorも自動的に終了します。コマンドの終了ステータスがClaudeに通知されるため、異常終了の場合はClaudeがその原因を分析できます。長時間の監視が必要な場合は、コマンド自体が終了しないよう`tail -f`や`kubectl logs -f`のようなストリーミングコマンドを使うことが目安になります。

### Q4. Monitorツールはリモートサーバーのログも監視できますか？

はい、SSHトンネル経由でリモートサーバーのログを監視できます。`Monitor: ssh user@remote-server 'tail -f /var/log/app.log | grep error'`のように、SSHコマンドをMonitorの対象として指定します。ただし、SSH接続が切断されるとMonitorも停止するため、安定したネットワーク環境が前提になる点は押さえておいてください。

### Q5. トークン消費が想定以上に大きくなった場合はどうすればよいですか？

まず`grep`や`awk`によるフィルタリングを強化することをおすすめします。出力頻度が高いログの場合、フィルタ条件を絞ることでnotification数を削減できます。それでもトークン消費が気になる場合は、Monitorの代わりに`run_in_background`でログをファイルに書き出し、定期的に`/loop`で差分を確認するハイブリッド方式も検討する価値があります。

## まとめ

Claude Code Monitorツールは、stdout出力をイベントとして受け取り、条件に合致した瞬間だけClaudeが反応するイベント駆動型の監視機能です。コマンドが沈黙している間はトークンを消費しない設計のため、定期的にチェックを回すポーリング型監視とは構造が異なり、リアルタイムに近い反応速度を実現します。サーバーログのエラー検知、CI/CDパイプラインの失敗監視、デプロイ後のヘルスチェックなど、「待ち」が発生する運用業務との相性が良い機能です。

運用の前提として、本記事の軸である「検知・分析・判断の分離」、つまり検知と分析はAIに任せ、本番操作の判断は人が持つという役割分担を決めておくこと、そして個別の監視を場当たり的に増やすのではなく一気通貫の運用フローとして設計することが、安定して使い続けるためのポイントになってきます。

「検知・分析・判断の分離」を意識しながら、まずは開発環境の1つのログ監視から始めることをおすすめします。次のようなステップで進めると、無理なく運用に組み込めます。

1. 開発環境で、既存のログコマンドに`grep`でフィルタを付けてMonitorを試します
2. 通知の頻度やトークン消費を確認し、フィルタ条件を自社のログ形式に合わせて調整します
3. 運用に慣れてきたら、CI/CDやデプロイ後のヘルスチェックなど、他の監視対象へ段階的に広げます

CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。

## あわせて読みたい

- [Claude Codeの/loopコマンド｜定期実行でデプロイ監視・ステータスチェックを自動化する](https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-code-loop-monitoring) — Monitorとの使い分けの基準となるポーリング型監視の詳細解説
- [Claude Codeで複数AIエージェントを並列実行する方法｜tmux・Agent Teams・ファイル連携の実践](https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-code-parallel-agents) — 複数のMonitorを並列で走らせるマルチエージェント構成の実践
- [Claude Code × HubSpot連携｜CRM操作・レポート・ワークフローを自動化する方法](https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-code-hubspot-automation) — HubSpot Webhook監視の前提知識となるCRM自動化の全体像

## あわせて読みたいAI実践ガイド

### [Setup Claude Coworkの使い方と初期設定 導入直後にやるべき設定、CLAUDE.md、スキル設計、運用の型をまとめています。](https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-cowork-setup-guide)

### [Team Claude Codeでチーム開発を効率化する方法 レビュー、権限管理、共有ルールまで踏み込んだ実践的なチーム利用ガイドです。](https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-code-team-development)

### [MCP Claude Code × MCP連携ガイド 社内システムとつなぎ、実業務でAIエージェントを動かす方法を整理しています。](https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-code-mcp-integration)

### [Service HubSpot × 生成AIの支援サービス 導入設計から内製化、ワークフロー自動化までの支援内容を確認できます。](https://start-link.jp/service/hubspot-ai)

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

###### 関連キーワード:

[AI](https://start-link.jp/hubspot-ai/tag/ai) [生成AI](https://start-link.jp/hubspot-ai/tag/生成ai)

## サービス資料を無料DL

## 著者情報

![7-1](https://start-link.jp/hubfs/7-1.jpg)

### 今枝 拓海 / Takumi Imaeda

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

[StartLink](https://start-link.jp/)

### Service

- [会社情報](https://start-link.jp/about)
- [サービス](https://start-link.jp/service)
- [プロダクト](https://start-link.jp/sync)
- [採用情報](https://start-link.jp/recruit)
- [コンサルタントの方へ](https://start-link.jp/consultant-platform)

### Contact

- [問い合わせ](https://start-link.jp/contact)
- [資料ダウンロード](https://start-link.jp/download/service)
- [個人情報保護方針](https://start-link.jp/privacy-policy)
- [個人情報取り扱い規定](https://start-link.jp/personal-information-processing-agreement)

(c) 2026 All Rights Reserved.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person"
  },
  "datePublished" : "2026-04-11T04:31:23.000Z",
  "headline" : "Claude Code Monitorとは｜ログ監視をリアルタイム自動検知",
  "image" : [ "https://start-link.jp/hubfs/blog/screenshots/generated/kv_claude-code-monitor-tool.jpg" ],
  "mainEntityOfPage" : {
    "@id" : "https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-code-monitor-tool",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://start-link.jp/hubfs/Start%20Link%20(1500%20x%20600%20px)%20(5)-1.png"
    },
    "name" : "株式会社StartLink"
  }
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "FAQPage",
  "mainEntity" : [ {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "Monitorツールの同時実行数に公式な上限値はありません。実運用での目安としては3〜5件程度に抑えることをおすすめします。監視対象が多すぎると、同時に複数のnotificationが到着した際にClaudeの処理が輻輳し、レスポンスが遅くなる可能性があります。監視項目を厳選し、本当にリアルタイム検知が必要なものだけをMonitorに割り当てるのが効果的です。"
    },
    "name" : "Monitorツールは何件まで同時に実行できますか？"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "「ストリーム出力の各行に即座に反応したい」場合はMonitor、「定期的に状態をチェックしたい」場合は/loopを選ぶのが基本の目安です。例えば、サーバーログのエラー検知はMonitorが適しており、デプロイのステータスを数分おきに確認するような場合は/loopの方が向いています。両者は排他的ではなく、用途に応じて組み合わせて使えます。"
    },
    "name" : "Monitorツールと/loopコマンドはどちらを使うべきですか？"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "監視対象のコマンドが終了（プロセスが停止）すると、Monitorも自動的に終了します。コマンドの終了ステータスがClaudeに通知されるため、異常終了の場合はClaudeがその原因を分析できます。長時間の監視が必要な場合は、コマンド自体が終了しないようtail -fやkubectl logs -fのようなストリーミングコマンドを使うことが目安になります。"
    },
    "name" : "Monitorで監視しているコマンドが終了した場合はどうなりますか？"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "はい、SSHトンネル経由でリモートサーバーのログを監視できます。Monitor: ssh user@remote-server 'tail -f /var/log/app.log | grep error'のように、SSHコマンドをMonitorの対象として指定します。ただし、SSH接続が切断されるとMonitorも停止するため、安定したネットワーク環境が前提になる点は押さえておいてください。"
    },
    "name" : "Monitorツールはリモートサーバーのログも監視できますか？"
  }, {
    "@type" : "Question",
    "acceptedAnswer" : {
      "@type" : "Answer",
      "text" : "まずgrepやawkによるフィルタリングを強化することをおすすめします。出力頻度が高いログの場合、フィルタ条件を絞ることでnotification数を削減できます。それでもトークン消費が気になる場合は、Monitorの代わりにrun_in_backgroundでログをファイルに書き出し、定期的に/loopで差分を確認するハイブリッド方式も検討する価値があります。"
    },
    "name" : "トークン消費が想定以上に大きくなった場合はどうすればよいですか？"
  } ]
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-code-monitor-tool#article",
  "@type" : "BlogPosting",
  "author" : {
    "@id" : "https://start-link.jp/#founder"
  },
  "dateModified" : "2026-10-04T05:42:08+09:00",
  "datePublished" : "2026-04-11T04:31:23+09:00",
  "headline" : "Claude Code Monitorとは｜ログ監視をリアルタイム自動検知",
  "image" : "https://start-link.jp/hubfs/blog/screenshots/generated/kv_claude-code-monitor-tool.jpg",
  "isPartOf" : {
    "@id" : "https://start-link.jp/#website"
  },
  "mainEntityOfPage" : {
    "@id" : "https://start-link.jp/hubspot-ai/ai/claude-code-practice/claude-code-monitor-tool",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "speakable" : {
    "@type" : "SpeakableSpecification",
    "cssSelector" : [ ".blog-section h2", ".blog-section p:first-of-type", ".blog-section blockquote" ]
  }
}
```

```json
{
  "@context" : "https://schema.org",
  "@type" : "BreadcrumbList",
  "itemListElement" : [ {
    "@type" : "ListItem",
    "item" : "https://start-link.jp",
    "name" : "ホーム",
    "position" : 1
  }, {
    "@type" : "ListItem",
    "item" : "https://start-link.jp/hubspot-ai",
    "name" : "ブログ",
    "position" : 2
  }, {
    "@type" : "ListItem",
    "item" : "https://start-link.jp/hubspot-ai/ai",
    "name" : "AI活用",
    "position" : 3
  }, {
    "@type" : "ListItem",
    "item" : "https://start-link.jp/hubspot-ai/ai/claude-code-practice",
    "name" : "Claude Code実践",
    "position" : 4
  }, {
    "@type" : "ListItem",
    "name" : "Claude Code Monitorとは｜ログ監視をリアルタイム自動検知",
    "position" : 5
  } ]
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#organization",
  "@type" : "Organization",
  "address" : {
    "@type" : "PostalAddress",
    "addressCountry" : "JP",
    "addressLocality" : "中央区",
    "addressRegion" : "東京都",
    "postalCode" : "104-0061",
    "streetAddress" : "銀座1丁目12番4号 N&E BLD.6F"
  },
  "alternateName" : "StartLink Inc.",
  "award" : [ "HubSpot Gold Solutions Partner（HubSpotゴールドパートナー、2026年4月認定）" ],
  "contactPoint" : [ {
    "@type" : "ContactPoint",
    "availableLanguage" : [ "ja" ],
    "contactType" : "customer support",
    "url" : "https://start-link.jp/contact"
  }, {
    "@type" : "ContactPoint",
    "availableLanguage" : [ "ja", "en" ],
    "contactType" : "sales",
    "url" : "https://start-link.jp/contact"
  } ],
  "description" : "「生成AI × HubSpot」をコンセプトに掲げるHubSpotゴールドパートナー（Gold Solutions Partner、2026年4月認定）。HubSpotマーケットプレイスに自社アプリ（Sync for freee / Notion / Money Forward / Chatwork）を公開するアプリ開発企業であり、HubSpot/Salesforce知見と生成AI活用を組み合わせたCRM構築・移行・最適化・AIエージェント/PoC支援まで一貫して提供する。",
  "founder" : {
    "@id" : "https://start-link.jp/#founder",
    "@type" : "Person",
    "jobTitle" : "代表取締役",
    "name" : "今枝 拓海",
    "sameAs" : [ "https://x.com/ImaedaTakumii", "https://www.linkedin.com/in/takumi-imaeda/", "https://www.facebook.com/takumiIma" ]
  },
  "foundingDate" : "2024-09-04",
  "hasCredential" : {
    "@type" : "EducationalOccupationalCredential",
    "credentialCategory" : "certification",
    "name" : "HubSpot Gold Solutions Partner",
    "recognizedBy" : {
      "@type" : "Organization",
      "name" : "HubSpot, Inc.",
      "url" : "https://www.hubspot.com/"
    }
  },
  "image" : [ "https://start-link.jp/hubfs/startlink-ai-agent.jpg", "https://start-link.jp/hubfs/startlink-aiorg.jpg" ],
  "knowsAbout" : [ "HubSpot CRM", "HubSpot Implementation", "HubSpot導入支援", "CRM構築", "AI活用", "HubSpot連携アプリ開発", "Salesforce to HubSpot Migration", "Generative AI Integration", "AI Agent Development", "Revenue Operations", "Marketing Automation", "freee Integration", "Notion Integration", "Money Forward Integration" ],
  "legalName" : "株式会社StartLink",
  "logo" : "https://start-link.jp/hubfs/startlink-logo.png",
  "mainEntityOfPage" : "https://start-link.jp/",
  "memberOf" : {
    "@type" : "ProgramMembership",
    "hostingOrganization" : {
      "@type" : "Organization",
      "name" : "HubSpot, Inc.",
      "url" : "https://www.hubspot.com/"
    },
    "membershipNumber" : "Gold Tier",
    "programName" : "HubSpot Solutions Partner Program"
  },
  "name" : "株式会社StartLink",
  "sameAs" : [ "https://www.youtube.com/@startlink-hubspot", "https://x.com/ImaedaTakumii", "https://www.linkedin.com/in/takumi-imaeda/", "https://www.linkedin.com/company/108100307/", "https://www.facebook.com/takumiIma", "https://www.facebook.com/profile.php?id=61566874764985", "https://prtimes.jp/main/html/searchrlp/company_id/149669", "https://app.hubspot.com/ecosystem/46046172/marketplace/solutions/startlink" ],
  "taxID" : "8010001248134",
  "url" : "https://start-link.jp/"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#website",
  "@type" : "WebSite",
  "inLanguage" : "ja",
  "name" : "株式会社StartLink",
  "publisher" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "url" : "https://start-link.jp/"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#service-hubspot",
  "@type" : "Service",
  "areaServed" : "JP",
  "category" : [ "CRM導入", "HubSpot" ],
  "description" : "150社以上の実績を持つHubSpotゴールドパートナーが、業務フローに合わせた設計から構築・本番稼働まで一貫支援。",
  "name" : "HubSpot導入・構築支援",
  "provider" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "serviceType" : "HubSpot導入・構築支援",
  "url" : "https://start-link.jp/service/hubspot"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#service-hubspot-ai",
  "@type" : "Service",
  "areaServed" : "JP",
  "category" : [ "CRM最適化", "AI活用" ],
  "description" : "HubSpotを軸に業務要件に沿った設計改善と生成AI連携活用を包括支援。",
  "name" : "HubSpot 生成AIコンサルティング",
  "provider" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "serviceType" : "HubSpot 生成AIコンサルティング",
  "url" : "https://start-link.jp/service/hubspot-ai"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#service-hubspot-training",
  "@type" : "Service",
  "areaServed" : "JP",
  "category" : [ "研修", "HubSpot" ],
  "description" : "HubSpotの概念・基本操作からAI活用ノウハウまで、社内浸透のための研修を提供。",
  "name" : "HubSpot研修・レクチャー支援",
  "provider" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "serviceType" : "HubSpot研修・内製化支援",
  "url" : "https://start-link.jp/service/hubspot-ai/training"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#service-sf2hs-replace",
  "@type" : "Service",
  "areaServed" : "JP",
  "category" : [ "CRM移行", "データ移行" ],
  "description" : "Salesforce/HubSpot双方の思想とデータモデルを理解した移行設計とHubSpot側CRM開発を実行。",
  "name" : "SalesforceからHubSpotへのリプレイス支援",
  "provider" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "serviceType" : "SalesforceからHubSpotへのリプレイス支援",
  "url" : "https://start-link.jp/service/salesforce-hubspot-replace"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#service-claude-code-bi",
  "@type" : "Service",
  "areaServed" : "JP",
  "category" : [ "AI活用", "経営管理" ],
  "description" : "複数システムのデータを統合し、毎朝のAIブリーフィングなど経営の意思決定を加速する仕組みを構築。",
  "name" : "Claude Codeによる経営データ活用支援",
  "provider" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "serviceType" : "AI経営管理支援",
  "url" : "https://start-link.jp/service/claude-code/business-intelligence"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#service-claude-code-content",
  "@type" : "Service",
  "areaServed" : "JP",
  "category" : [ "コンテンツマーケティング", "AI活用" ],
  "description" : "キーワード戦略からSEO記事制作、CMS公開まで、AIを活用したコンテンツマーケティングを自動化。",
  "name" : "Claude Codeによるコンテンツマーケティング支援",
  "provider" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "serviceType" : "AIコンテンツ制作支援",
  "url" : "https://start-link.jp/service/claude-code/content-marketing"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#product-sync-freee",
  "@type" : "SoftwareApplication",
  "applicationCategory" : "BusinessApplication",
  "author" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "description" : "HubSpotとfreee会計・freee請求書をシームレスに連携。取引先の同期から請求書作成まで、バックオフィスの業務を自動化するHubSpotマーケットプレイスアプリ。",
  "featureList" : [ "freee取引先をHubSpotに自動同期", "HubSpotからfreee見積書・請求書を作成", "取引データをfreee会計に自動登録", "月次請求・更新処理に対応", "商品項目・品目・部門・タグ情報の連携" ],
  "installUrl" : "https://ecosystem.hubspot.com/marketplace/apps/sync-for-freee-bystartlink",
  "name" : "Sync for freee",
  "offers" : [ {
    "@type" : "Offer",
    "description" : "請求月5件・見積月20件まで",
    "name" : "Free",
    "price" : "0",
    "priceCurrency" : "JPY"
  }, {
    "@type" : "Offer",
    "billingIncrement" : "P1M",
    "description" : "請求月50件・見積月100件まで",
    "name" : "Professional",
    "price" : "4000",
    "priceCurrency" : "JPY"
  }, {
    "@type" : "Offer",
    "billingIncrement" : "P1M",
    "description" : "無制限",
    "name" : "Enterprise",
    "price" : "10000",
    "priceCurrency" : "JPY"
  } ],
  "operatingSystem" : "Web",
  "softwareHelp" : {
    "@type" : "WebPage",
    "url" : "https://start-link.jp/sync/freee/manual"
  },
  "url" : "https://start-link.jp/sync/freee"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#product-sync-notion",
  "@type" : "SoftwareApplication",
  "applicationCategory" : "BusinessApplication",
  "author" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "description" : "HubSpotのCRMレコードとNotionのページ・データベースを接続。HubSpotの画面から離れずにNotionのすべてにアクセスできるHubSpotマーケットプレイスアプリ。",
  "featureList" : [ "CRMカードからNotionページの作成・閲覧・編集", "NotionデータベースをCRMタブにテーブル表示", "4つのワークフローアクションで自動化", "コンタクト・会社・取引・チケット・サービス・プロジェクト対応" ],
  "installUrl" : "https://ecosystem.hubspot.com/marketplace/listing/sync-for-notion-bystartlink",
  "name" : "Sync for Notion",
  "offers" : [ {
    "@type" : "Offer",
    "description" : "ページ・DB合計50件まで",
    "name" : "Free",
    "price" : "0",
    "priceCurrency" : "JPY"
  }, {
    "@type" : "Offer",
    "billingIncrement" : "P1M",
    "description" : "無制限",
    "name" : "Professional",
    "price" : "6000",
    "priceCurrency" : "JPY"
  } ],
  "operatingSystem" : "Web",
  "url" : "https://start-link.jp/sync/notion"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#product-sync-moneyforward",
  "@type" : "SoftwareApplication",
  "applicationCategory" : "BusinessApplication",
  "author" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "description" : "HubSpotとマネーフォワード クラウドを連携。取引情報から見積書・請求書を自動作成し、取引先・品目の同期や継続請求に対応するHubSpot連携アプリ。",
  "featureList" : [ "取引（Deal）から見積書・請求書を自動作成", "会社情報とマネーフォワード取引先の同期", "商品項目・品目マスタの連携", "月次・固定回数の継続請求に対応（Professionalプラン以上）", "合算請求（Enterpriseプラン限定）", "前受請求（一括請求・月次計上）（Enterpriseプラン限定）", "原価登録（MF会計への仕訳登録）で案件別の原価・粗利を可視化（Enterpriseプラン限定）", "取引レコードにCRMカードで連携ステータスを表示" ],
  "installUrl" : "https://ecosystem.hubspot.com/ja/marketplace/listing/sync-for-moneyforward-bystartlink",
  "name" : "Sync for Money Forward",
  "offers" : [ {
    "@type" : "Offer",
    "description" : "請求月5件・見積月20件まで",
    "name" : "Free",
    "price" : "0",
    "priceCurrency" : "JPY"
  }, {
    "@type" : "Offer",
    "billingIncrement" : "P1M",
    "description" : "請求月50件・見積月100件まで",
    "name" : "Professional",
    "price" : "4000",
    "priceCurrency" : "JPY"
  }, {
    "@type" : "Offer",
    "billingIncrement" : "P1M",
    "description" : "無制限",
    "name" : "Enterprise",
    "price" : "10000",
    "priceCurrency" : "JPY"
  } ],
  "operatingSystem" : "Web",
  "url" : "https://start-link.jp/sync/moneyforward"
}
```

```json
{
  "@context" : "https://schema.org",
  "@id" : "https://start-link.jp/#product-sync-chatwork",
  "@type" : "SoftwareApplication",
  "applicationCategory" : "BusinessApplication",
  "author" : {
    "@id" : "https://start-link.jp/#organization"
  },
  "description" : "HubSpotとChatworkを連携。ワークフローからChatworkのルームへ通知を送り、CRMカード上で最新のやり取りの確認と返信ができ、紐付けたルームの新着メッセージをHubSpotのノートとして自動で記録するHubSpot連携アプリ。",
  "featureList" : [ "ワークフローアクション「Chatworkに通知」（取引・会社・コンタクト・チケット対応）", "送信先ルームIDとメッセージ本文にHubSpotのプロパティを差し込み", "取引・会社・コンタクトとChatworkルームの紐付け（全プラン無制限）", "CRMカードにルームの最新100件のメッセージを表示（Professionalプラン以上）", "CRMカードからChatworkへメッセージを送信（Professionalプラン以上）", "紐付けたルームの新着メッセージをHubSpotのノートへ自動記録（Enterpriseプラン限定）", "引用や装飾を、HubSpotのノートでも読みやすい見た目のまま記録", "OAuth接続とAPIトークン接続（SAML/SSO環境向け）に対応" ],
  "installUrl" : "https://ecosystem.hubspot.com/marketplace/listing/sync-for-chatwork-bystartlink",
  "name" : "Sync for Chatwork",
  "offers" : [ {
    "@type" : "Offer",
    "description" : "通知 月10件まで・ルーム紐付け無制限",
    "name" : "Free",
    "price" : "0",
    "priceCurrency" : "JPY"
  }, {
    "@type" : "Offer",
    "billingIncrement" : "P1M",
    "description" : "通知無制限・CRMカードで最新100件の表示とメッセージ送信",
    "name" : "Professional",
    "price" : "3000",
    "priceCurrency" : "JPY"
  }, {
    "@type" : "Offer",
    "billingIncrement" : "P1M",
    "description" : "Professionalの全機能＋メッセージ同期（30分ごと）",
    "name" : "Enterprise",
    "price" : "10000",
    "priceCurrency" : "JPY"
  } ],
  "operatingSystem" : "Web",
  "url" : "https://start-link.jp/sync/chatwork"
}
```