This is the full developer documentation for Manako # Manako ドキュメント > オールインワン監視ダッシュボード SaaS のドキュメント HTTP 監視 Web サイトやAPIエンドポイントの死活監視を設定できます。レスポンスタイム、ステータスコード、キーワードチェックに対応。 TCP / Ping 監視 サーバーのポート接続とホストへの到達性を確認します。 通知 Email や Slack でインシデント通知を受け取れます。モニターごと、またはチーム全体で通知先を設定可能。 ステータスページ サービスの稼働状況を公開するステータスページを作成できます。 # はじめに > Manako のアカウント作成から最初のモニター設定までのガイド Manako を使い始めるための手順を説明します。 ## クイックスタート [Section titled “クイックスタート”](#クイックスタート) 1. **アカウントを作成する** [Manako](https://app.manako.dev) にアクセスし、以下のいずれかの方法でサインアップします。 * **Google アカウント**: 「Google で続ける」をクリック * **GitHub アカウント**: 「GitHub で続ける」をクリック * **メールアドレス**: メールアドレスとパスワードを入力 Google / GitHub でサインアップした場合、メール確認は自動的に完了します。 2. **メールアドレスを確認する** メール/パスワードでサインアップした場合、確認メールが届きます。メール内のリンクをクリックしてアドレスを確認してください。確認が完了するまで、モニターや通知チャンネルの作成が制限されます。確認メールが届かない場合は、ダッシュボードから再送できます。 3. **最初のモニターを作成する** ダッシュボードの「モニター追加」から、監視したい URL を入力します。 * **監視タイプ**: HTTP、TCP、Ping から選択 * **監視間隔**: 確認する頻度を設定(Free プランは最短 300 秒) * **名前**: わかりやすい名前をつけます 4. **通知先を設定する** 「通知チャンネル」からメールアドレスや Slack Webhook URL を登録します。モニターごと、またはチーム全体のデフォルト通知先として設定できます。 5. **監視開始** モニターを有効にすると、設定した間隔で自動的に監視が開始されます。異常を検知するとインシデントが作成され、設定した通知先にアラートが送信されます。 ## 次のステップ [Section titled “次のステップ”](#次のステップ) * [モニターの詳細設定](/guides/monitors/) - HTTP/TCP/Ping モニターの設定オプション * [通知設定](/guides/notifications/) - 通知チャンネルの設定方法 * [ステータスページ](/guides/status-pages/) - 公開ステータスページの作成 * [API キー](/developers/api-keys/) - Public API の利用方法 # お知らせ > Manako に関するお知らせの一覧です。 [](/announcements/feed.xml) [📡 RSS フィード](/announcements/feed.xml) すべて リリース メンテナンス お知らせ 2026-08-15 お知らせ ### [ドキュメントを全面拡充しました](/announcements/2026-08-15-documentation-expansion/) ガイド、リファレンス、開発者向けドキュメントを再編・拡充しました。 2026-04-06 リリース ### [Manako 正式リリースのお知らせ](/announcements/2026-04-06-service-launch/) Manako の正式リリースについてお知らせします。 ← 前へ 次へ → # Manako 正式リリースのお知らせ > Manako の正式リリースについてお知らせします。 Manako は本日、正式リリースを迎えました。 Manako は、個人開発者が Web サービスの稼働状況を 1 つの日本語ダッシュボードで見守るための監視 SaaS です。HTTP / TCP / Ping の3種類をまとめて監視できます。 ## なぜ Manako を作ったのか [Section titled “なぜ Manako を作ったのか”](#なぜ-manako-を作ったのか) 監視のために複数のダッシュボードを行き来し、設定や請求を別々に管理していました。「個人開発に必要な監視を、日本語の 1 つのダッシュボードにまとめたい」というシンプルな思いから Manako は生まれました。 LINE 通知や MCP Server など、現場で実際に使われている連絡手段や AI ワークフローへのフィット感を重視しています。 ## 主な機能 [Section titled “主な機能”](#主な機能) * **3 種類のモニタリング**: HTTP、TCP、Ping * **6 チャンネル通知**: Email、Slack、Discord、LINE、Webhook、GitHub * **公開ステータスページ**: ワンクリックで作成 * **MCP Server / CLI**: Claude Code などの AI コーディングアシスタントやターミナルから、ブラウザを開かずに監視を操作 * **メンテナンス窓 / サービスグループ**: 計画的なメンテナンスを事前登録してインシデント抑止、関連モニターをサービス単位でまとめて把握 ## 料金プラン [Section titled “料金プラン”](#料金プラン) | プラン | 月額 | 年契約 | モニター数 | 最短間隔 | | ---- | -- | ------------- | ----- | ---- | | Free | $0 | – | 3 | 5 分 | | Pro | $5 | $50 (2 ヶ月分割引) | 20 | 3 分 | すべてのプランで3種類のモニターをご利用いただけます。Free プランはクレジットカード不要で、Email / Slack / Discord / Webhook 通知に対応しています。 ## ご利用開始 [Section titled “ご利用開始”](#ご利用開始) 1. [サインアップ](https://app.manako.dev/signup) でアカウントを作成 2. [クイックスタートガイド](/guides/getting-started/) に沿って最初のモニターを設定 3. 通知チャンネルを接続して監視を開始 CLI 派の方は `npm install -g manako` で CLI をインストールし、`manako login` から始められます。Claude Code をお使いの場合は MCP Server を組み込むと、AI に監視作成や障害確認を任せられます。 ## フィードバックをお待ちしています [Section titled “フィードバックをお待ちしています”](#フィードバックをお待ちしています) Manako は小さなチームで運営しています。ご要望や不具合のご報告は [お問い合わせ](https://manako.dev/#contact) よりお寄せください。皆さまの声を反映しながら、これからも改善を続けます。 # ドキュメントを全面拡充しました > ガイド、リファレンス、開発者向けドキュメントを再編・拡充しました。 Manako の機能を探しやすく、設定時の疑問を解決しやすくするため、ドキュメントを段階的に再編・拡充しました。 ## 主な変更 [Section titled “主な変更”](#主な変更) * **情報設計の再編**: タスクベースの「ガイド」、値や挙動を確認する「リファレンス」、API・CLI・MCP・SDK などの「開発者向け」を役割ごとに整理しました。 * **リファレンスの新設**: 機能一覧、プランと制限値、主要画面の入力項目、監視・通知・データ保持・レート制限の挙動を日本語と英語で確認できます。 * **利用ガイドの追加**: インシデント対応、チーム管理、料金プランと請求、アカウントとセキュリティの手順を追加しました。 * **通知ガイドの深化**: Email、Slack、Discord、LINE、Webhook、GitHub の準備、Manako での入力項目、トラブルシューティングを詳しくしました。 ## 目的から探す [Section titled “目的から探す”](#目的から探す) * 初めて利用する場合は[クイックスタート](/guides/getting-started/)をご覧ください。 * 通知先を追加する場合は[通知チャンネル](/guides/notifications/)から利用するサービスを選んでください。 * プランごとの上限は[プランと制限値](/reference/plans-limits/)で確認できます。 * API や CLI から操作する場合は「開発者向け」セクションをご覧ください。 今後も既存ガイドの内容を継続的に見直し、実際の画面と挙動に沿って更新します。 # API キー > API キーの作成と Public API の利用方法 Public API を利用するには API キーが必要です。 ## API キーの作成 [Section titled “API キーの作成”](#api-キーの作成) 1. ダッシュボードの「API Keys」メニューを開きます 2. キーの名前を入力し、スコープを選択して「Create API Key」をクリック 3. 表示されたキーをコピーして安全な場所に保存します ### スコープ [Section titled “スコープ”](#スコープ) | スコープ | 権限 | | ----- | ---------------------------- | | read | モニター・インシデント・ステータスページの一覧と詳細取得 | | write | モニターの作成・更新・削除、インシデントの確認 | 注意 API キーは作成時に一度だけ表示されます。安全な場所に保存してください。 ## API キーの形式 [Section titled “API キーの形式”](#api-キーの形式) API キーは `mk_` プレフィクスに続く 64 文字の 16 進数文字列です。 ```plaintext mk_a1b2c3d4e5f6... ``` ## 認証方法 [Section titled “認証方法”](#認証方法) API リクエストの `Authorization` ヘッダーに Bearer トークンとして設定します。 ```bash curl -H "Authorization: Bearer mk_your_api_key_here" \ https://api.manako.dev/api/v1/monitors ``` ## Public API エンドポイント [Section titled “Public API エンドポイント”](#public-api-エンドポイント) Public API(`/api/v1/*`)では以下の操作が可能です: **read スコープ:** * モニター一覧の取得・詳細取得 * インシデント一覧の取得 * ステータスページ一覧の取得 * 課金・サブスクリプション情報の取得 **write スコープ:** * モニターの作成・更新・削除 * モニターの手動チェック実行 * インシデントの作成・更新・解決・削除(手動インシデント) * インシデントの確認(acknowledge) 詳細は [API リファレンス](/api/) を参照してください。 ## キーの管理 [Section titled “キーの管理”](#キーの管理) * API キーはいつでも無効化(削除)できます * キーの無効化は即座に反映されます * 1 チームあたりの API キー作成数には上限があります # Claude Code Plugin > Claude Code から Manako を操作する Plugin のインストールと使い方 Claude Code Plugin を使うと、Claude Code のスキルとして Manako の監視操作を自然言語で実行できます。 ヒント MCP Server を直接使う方法もあります。詳しくは [MCP Server ガイド](/developers/mcp-server) を参照してください。Plugin は MCP Server の機能に加えて、CLI 連携やスキルによるガイド付き操作を提供します。 ## インストール [Section titled “インストール”](#インストール) * /plugin コマンド(推奨) Claude Code で以下のコマンドを実行します: 1. **マーケットプレイスを追加** ```plaintext /plugin marketplace add elchika-inc/manako-dev ``` 2. **Plugin をインストール** ```plaintext /plugin install manako@manako-dev ``` インストールスコープを選択できます: * **User** (デフォルト) — 全プロジェクトで利用 * **Project** — チームで共有 (`.claude/settings.json` に記録) * **Local** — このリポジトリのみ 3. **Plugin を読み込み** ```plaintext /reload-plugins ``` * 手動インストール 1. **リポジトリをクローン** ```bash git clone https://github.com/elchika-inc/manako-dev.git ``` 2. **Claude Code の設定に Plugin を追加** `.claude/settings.json` の `enabledPlugins` にパスを追加します: ```json { "enabledPlugins": [ "/path/to/manako-dev/claude-code-plugin" ] } ``` 3. **Claude Code を再起動** Plugin が読み込まれ、スキルと MCP Server が利用可能になります。 ## セットアップ [Section titled “セットアップ”](#セットアップ) Plugin インストール後、Claude Code で「manako をセットアップして」と依頼すると、`setup` スキルがガイドします。 ### 認証方法 [Section titled “認証方法”](#認証方法) * CLI 認証(推奨) Manako CLI がインストール済みの場合、最も簡単な方法です: ```bash manako login --api-key mk_your_api_key_here ``` API Key は [ダッシュボード](https://app.manako.dev) の Settings > API Keys で発行できます。 * MCP セッション認証 CLI がなくても、Plugin に同梱の MCP Server 設定で自動接続されます。 Claude Code に「Manako にログインして」と依頼すると、メールアドレスとパスワードでセッション認証が行われます。セッションは **24 時間** 有効です。 * MCP API Key 認証 環境変数で API Key を設定する方法です: ```bash export MANAKO_API_KEY=mk_your_api_key_here ``` ## ツール優先順位 [Section titled “ツール優先順位”](#ツール優先順位) Plugin のスキルは、利用可能なツールを以下の優先順位で自動選択します: 1. **CLI** (`manako` コマンド) - ローカルにインストール済みの場合 2. **MCP** (Manako MCP Server) - Plugin 同梱の `.mcp.json` で自動設定 3. **API** (`curl` 直接呼び出し) - フォールバック ## 利用可能なスキル [Section titled “利用可能なスキル”](#利用可能なスキル) monitor-status モニターの状態確認・即座チェック 「モニターの状態を確認して」「稼働状況を見せて」 create-monitor モニターの新規作成 (3 タイプ対応) 「example.com を監視して」「TCP ポート 443 の監視を追加して」 list-incidents インシデント一覧・フィルタ 「進行中のインシデントはある?」「障害一覧を見せて」 acknowledge-incident インシデントの確認済みマーク 「インシデントを確認済みにして」 ### monitor-status [Section titled “monitor-status”](#monitor-status) モニターの状態を確認します。 ```plaintext 「モニターの状態を確認して」 「モニター一覧を見せて」 「XXX モニターの詳細を教えて」 「XXX モニターを即座にチェックして」 ``` ### create-monitor [Section titled “create-monitor”](#create-monitor) 新しいモニターを作成します。3 種類のモニタータイプに対応しています。 ```plaintext 「https://example.com の HTTP 監視を作成して」 「example.com:443 の TCP 監視を作成して」 「example.com の Ping 監視を作成して」 ``` 対応タイプ: HTTP, TCP, Ping ### list-incidents [Section titled “list-incidents”](#list-incidents) インシデント一覧を確認します。ステータスでフィルタリング可能です。 ```plaintext 「インシデント一覧を見せて」 「進行中のインシデントはある?」 「解決済みインシデントを見せて」 ``` ### acknowledge-incident [Section titled “acknowledge-incident”](#acknowledge-incident) インシデントを確認済みにマークします。 ```plaintext 「インシデント XXX を確認済みにして」 「進行中のインシデントを ack して」 ``` ノート acknowledge はインシデントを解決するものではありません。モニターが復旧を検出すると、自動的に resolved に移行します。 ## MCP Server との違い [Section titled “MCP Server との違い”](#mcp-server-との違い) | 機能 | MCP Server | Claude Code Plugin | | -------- | ---------- | ------------------ | | MCP ツール | ✅ | ✅ (同梱) | | CLI 連携 | - | ✅ (優先使用) | | スキルガイド | - | ✅ (自然言語操作) | | セットアップ支援 | - | ✅ (setup スキル) | MCP Server は Claude Desktop など他の AI エージェントでも使えますが、Claude Code Plugin は Claude Code 専用で、CLI 連携やスキルによるガイド付き操作を追加で提供します。 # CLI > Manako CLI のインストールと使い方 コマンドラインから Manako の監視を管理できます。 * [npm パッケージ](https://www.npmjs.com/package/manako) ## インストール [Section titled “インストール”](#インストール) ```bash npm install -g manako ``` ## ログイン [Section titled “ログイン”](#ログイン) * ブラウザ認証 (推奨) ```bash manako login ``` ブラウザが自動で開き、ダッシュボードで認証コードを承認すると API キーが自動発行されます。 SSH などブラウザを開けない環境では、表示された URL とコードを手動でブラウザに入力してください。 * API キー直接指定 ```bash manako login --api-key mk_your_api_key_here ``` ダッシュボードで発行した API キーを直接設定できます。 認証情報は `~/.manako.json` に保存されます(パーミッション 600)。 ## コマンド一覧 [Section titled “コマンド一覧”](#コマンド一覧) ### ステータス確認 [Section titled “ステータス確認”](#ステータス確認) ```bash manako status ``` 全モニターの現在の状態をアイコン付きで表示します。 ### モニター管理 [Section titled “モニター管理”](#モニター管理) ```bash # 一覧(JSON) manako monitors list # 詳細 manako monitors get # 追加(HTTP) manako monitors add https://example.com # 追加(サービスを指定して作成) manako monitors add https://example.com --service # 追加(他のタイプ) manako monitors add example.com -t ping manako monitors add db.example.com:5432 -t tcp # 更新 manako monitors update --name "新しい名前" manako monitors update --interval 600 manako monitors update --pause manako monitors update --resume # 手動チェック実行 manako monitors check # 削除 manako monitors rm ``` ### モニタータイプ別の追加例 [Section titled “モニタータイプ別の追加例”](#モニタータイプ別の追加例) | タイプ | コマンド例 | | ---- | ------------------------------------------------ | | HTTP | `manako monitors add https://example.com` | | TCP | `manako monitors add db.example.com:5432 -t tcp` | | Ping | `manako monitors add example.com -t ping` | カスタム設定が必要な場合は `--config` オプションで JSON を指定できます: ```bash manako monitors add https://example.com -c '{"url":"https://example.com","method":"POST","expectedStatus":201,"timeoutMs":5000}' ``` ### インシデント管理 [Section titled “インシデント管理”](#インシデント管理) ```bash # 一覧 manako incidents list # ステータスでフィルタ manako incidents list -s ongoing # 確認済みにする manako incidents ack # 手動インシデント作成 manako incidents create --title "決済サービス障害" --cause "プロバイダ障害" # インシデント更新 manako incidents update --title "新しいタイトル" --cause "追加情報" # インシデント解決 manako incidents resolve --cause "原因特定・修正完了" # 手動インシデント削除 manako incidents delete ``` ### サービス（ステータスページ） [Section titled “サービス（ステータスページ）”](#サービスステータスページ) ```bash # 一覧 manako services list # 作成（slug 省略時は名前から自動生成） manako services add "My Service" manako services add "My Service" --slug my-service -d "説明文" # 更新 manako services update --name "新しい名前" manako services update --slug new-slug manako services update --public # ステータスページを公開 manako services update --private # 非公開に戻す # 削除（モニターはデフォルトサービスへ移動） manako services rm # モニター統計リセット manako services stats-reset manako services stats-reset --before 2024-01-01 ``` ### 通知チャンネル [Section titled “通知チャンネル”](#通知チャンネル) ```bash # テスト通知送信 manako notification-channels test ``` チャンネルの設定が正しいか確認するため、テスト通知を送信します。 ### ログアウト [Section titled “ログアウト”](#ログアウト) ```bash manako logout ``` ローカルの認証情報を削除します。 ## オプション [Section titled “オプション”](#オプション) | オプション | 説明 | | -------------------------- | --------------------------------------------- | | `--api-url ` | API の接続先 URL(デフォルト: `https://api.manako.dev`) | | `-n, --name ` | モニター名(add/update) | | `-t, --type ` | モニタータイプ(add) | | `-i, --interval ` | チェック間隔(60-86400秒、add/update) | | `-c, --config ` | タイプ別設定の JSON(add) | | `-s, --status ` | ステータスフィルタ(incidents list) | # MCP Server > AI エージェントから Manako を操作する MCP Server の使い方 MCP (Model Context Protocol) Server を使うと、Claude Desktop や Claude Code などの AI エージェントから Manako の監視を直接操作できます。 ## セットアップ [Section titled “セットアップ”](#セットアップ) ### Claude Code [Section titled “Claude Code”](#claude-code) プロジェクトの `.mcp.json` に以下を追加します: ```json { "mcpServers": { "manako": { "type": "http", "url": "https://mcp.manako.dev/mcp" } } } ``` Claude Code を再起動すると、Manako のツールが利用可能になります。 ### Claude Desktop [Section titled “Claude Desktop”](#claude-desktop) 設定ファイル(`claude_desktop_config.json`)に同様の設定を追加します。 ## 認証 [Section titled “認証”](#認証) MCP Server には 2 つの認証方法があります。 * ブラウザ認証(推奨) API キーの事前設定は不要です。Claude に「Manako にログインして」と依頼すると、`auth` ツールがブラウザ認証用の URL とコードを返します。ブラウザでコードを承認すると、`auth_status` ツールでセッションが確立されます。 セッションは **24 時間** 有効です。期限が切れた場合は再度ログインしてください。 * API キー認証 環境変数で API キーを設定する方法です: ```json { "mcpServers": { "manako": { "type": "http", "url": "https://mcp.manako.dev/mcp", "headers": { "Authorization": "Bearer ${MANAKO_API_KEY}" } } } } ``` ```bash export MANAKO_API_KEY=mk_your_api_key_here ``` ## 利用可能なツール [Section titled “利用可能なツール”](#利用可能なツール) ### auth [Section titled “auth”](#auth) ブラウザ認証を開始します。認証 URL とコードが返されるので、ブラウザで承認してください。 ```plaintext auth() ``` ### auth\_status [Section titled “auth\_status”](#auth_status) ブラウザ認証の承認状態を確認します。承認済みの場合、セッションが自動的に確立されます。 ```plaintext auth_status(deviceCode) ``` ### monitors [Section titled “monitors”](#monitors) モニターの管理を行います。 | アクション | 説明 | 必須パラメータ | | -------- | ------- | ------------------------- | | `list` | 全モニター一覧 | - | | `get` | モニター詳細 | `id` | | `create` | モニター作成 | `name`, `url` or `config` | | `update` | モニター更新 | `id` | | `delete` | モニター削除 | `id` | #### 作成時のパラメータ [Section titled “作成時のパラメータ”](#作成時のパラメータ) | パラメータ | 説明 | | ----------------- | -------------------------- | | `name` | モニター名 | | `type` | タイプ(http, tcp, ping) | | `url` | URL(HTTP タイプのショートカット) | | `config` | タイプ別の設定オブジェクト | | `serviceId` | 紐付けるサービス ID（省略時はデフォルトサービス） | | `intervalSeconds` | チェック間隔(300-86400秒) | #### 更新時のパラメータ [Section titled “更新時のパラメータ”](#更新時のパラメータ) | パラメータ | 説明 | | ----------------- | ---------- | | `id` | モニター ID | | `name` | 新しい名前 | | `isActive` | 有効/無効の切り替え | | `intervalSeconds` | 新しいチェック間隔 | ### incidents [Section titled “incidents”](#incidents) インシデントの管理を行います。 | アクション | 説明 | 必須パラメータ | | ------------- | ---------- | ------------------------- | | `list` | インシデント一覧 | - | | `acknowledge` | 確認済みにする | `id` | | `create` | 手動インシデント作成 | `title` | | `update` | インシデント更新 | `id` + `title` or `cause` | | `resolve` | インシデント解決 | `id` | | `delete` | 手動インシデント削除 | `id` | `list` では `status` パラメータで絞り込みが可能です(`ongoing`, `resolved`, `acknowledged`)。 `create` は `cause`(説明)をオプションで指定できます。`resolve` 時にも `cause` で解決メモを追加できます。 ### services [Section titled “services”](#services) サービス（ステータスページ）の管理を行います。 | アクション | 説明 | 必須パラメータ | | ------------- | ---------------------------------------------------- | -------------- | | `list` | 全サービス一覧 | - | | `create` | サービス作成（slug 省略時は name から自動生成） | `name` | | `update` | サービス更新（`name` / `slug` / `description` / `isPublic`） | `id` + 変更フィールド | | `delete` | サービス削除（モニターはデフォルトサービスへ移動） | `id` | | `stats-reset` | モニター統計リセット | `id` | ### notification-channels [Section titled “notification-channels”](#notification-channels) 通知チャンネルのテストを行います。 | アクション | 説明 | 必須パラメータ | | ------ | ------- | ------- | | `test` | テスト通知送信 | `id` | ### audit-logs [Section titled “audit-logs”](#audit-logs) 監査ログの閲覧を行います(有料プランのみ)。 | アクション | 説明 | 必須パラメータ | | ------ | ------ | ------- | | `list` | 監査ログ一覧 | - | `actionFilter`, `resourceType`, `userId`, `from`, `to`, `limit` でフィルタリング可能です。 ### 共通オプション [Section titled “共通オプション”](#共通オプション) 全ツールで `verbose: true` を指定すると、API レスポンスの完全な JSON データを取得できます。 ## 使用例 [Section titled “使用例”](#使用例) AI エージェントに以下のように依頼できます: * 「Manako にログインして」 * 「モニターの一覧を見せて」 * 「example.com の HTTP モニターを作成して」 * 「進行中のインシデントはある?」 * 「モニター XXX を一時停止して」 ヒント `verbose: true` を使うと、AI エージェントがより詳細な情報をもとに回答できます。 # アカウントとセキュリティ > パスワード・ソーシャルログイン連携・メールアドレス変更・重要操作の再認証・アカウント削除 アカウントの保護と管理に関するガイドです。二要素認証（MFA）の設定は [MFA ガイド](/guides/mfa/)を参照してください。 ## パスワードの変更・設定 [Section titled “パスワードの変更・設定”](#パスワードの変更設定) 「設定 → セキュリティ」で変更できます。パスワードは **8 文字以上**（最大 128 文字）で、英字と数字を含める必要があります。 Google / GitHub で登録した場合はパスワードが未設定です。「パスワード設定」からパスワードを追加すると、メール + パスワードでもログインできるようになります。 ## ソーシャルログイン連携（Google / GitHub） [Section titled “ソーシャルログイン連携（Google / GitHub）”](#ソーシャルログイン連携google--github) 「設定 → セキュリティ」の「接続済みアカウント」で連携を確認し、既存の連携を解除できます。新しい連携の追加は準備中です。 * 同じメールアドレスの既存アカウントがあれば、初回の OAuth ログイン時に自動で連携されます * **解除できない場合**: パスワード未設定で連携が 1 件しかないときは、ログイン手段を失わないよう解除できません。先にパスワードを設定してください ## メールアドレスの変更 [Section titled “メールアドレスの変更”](#メールアドレスの変更) 「設定 → アカウント」から変更します。本人確認として**パスワード**、またはパスワードを持たない場合は**メールで届く 6 桁の確認コード**を使います。新しいアドレスに届く確認メールのリンクを開くと変更が確定します。 ## 重要操作の再認証 [Section titled “重要操作の再認証”](#重要操作の再認証) API キーの作成・削除、アカウント削除、MFA の無効化といった影響の大きい操作では、パスワード等による**再認証**が求められます。確認は 15 分間有効です。 ## CLI / MCP のデバイス認証 [Section titled “CLI / MCP のデバイス認証”](#cli--mcp-のデバイス認証) [CLI](/developers/cli/) や [MCP Server](/developers/mcp-server/) からログインすると、ブラウザで認証コードの承認を求められます。承認すると外部ツール用の API キーが自動発行されます。 注意 認証コードは**自分で開始したログインのものだけ**を承認してください。第三者から送られたコードを承認すると、あなたのチームのデータへのアクセス権を渡してしまいます。 ## データエクスポート [Section titled “データエクスポート”](#データエクスポート) 「設定 → アカウント」からアカウントデータを JSON 形式でダウンロードできます（有料プラン・チームオーナーのみ）。 ## アカウントの削除 [Section titled “アカウントの削除”](#アカウントの削除) 「設定 → アカウント」の危険ゾーンから削除できます。 * 削除前に、重要操作の再認証（15 分間有効）が必要です * 削除を確定すると**削除予約**の状態になり、**30 日後にすべてのデータが完全に削除**されます * 猶予期間中に取り消したい場合は[お問い合わせ](/reference/screens/)からサポートに連絡してください # 監査ログ > 監査ログの確認とフィルタリング 監査ログはチーム内の全操作を記録し、いつ・誰が・何をしたかを追跡できる機能です。 ノート 監査ログは有料プランの機能です。無料プランではアクセスできません。 ## アクセス方法 [Section titled “アクセス方法”](#アクセス方法) ダッシュボードの **Settings > Audit Logs** から確認できます。 ## 記録されるイベント [Section titled “記録されるイベント”](#記録されるイベント) | カテゴリ | イベント | | ------- | ----------------- | | 認証 | サインアップ、ログイン、ログアウト | | モニター | 作成、更新、削除 | | インシデント | 作成、更新、確認、解決、削除 | | API キー | 作成、削除 | | 通知チャンネル | 作成、更新、削除 | | サービス | 作成、更新、削除 | | アカウント | 削除リクエスト | ## フィルタリング [Section titled “フィルタリング”](#フィルタリング) ダッシュボードではカテゴリドロップダウンでフィルタリングできます: * **All** — 全イベント * **Auth** — 認証系イベント * **Monitor** — モニター操作 * **Incident** — インシデント操作 * **API Key** — API キー操作 * **Notification** — 通知チャンネル操作 * **Service** — サービス操作 * **Account** — アカウント操作 ## API アクセス [Section titled “API アクセス”](#api-アクセス) Public API からも監査ログを取得できます: ```bash curl -H "Authorization: Bearer mk_your_api_key" \ "https://api.manako.dev/api/v1/audit-logs" ``` ### フィルタパラメータ [Section titled “フィルタパラメータ”](#フィルタパラメータ) | パラメータ | 説明 | | -------------- | --------------------------- | | `action` | アクション名 (末尾 `.` でプレフィックスマッチ) | | `resourceType` | リソース種別 | | `userId` | 操作者 ID | | `from` | 開始日時 (ISO 8601) | | `to` | 終了日時 (ISO 8601) | | `cursor` | ページネーションカーソル | | `limit` | 件数 (1-100, デフォルト 50) | ## データ保持 [Section titled “データ保持”](#データ保持) | プラン | 保持期間 | | ---- | ----------------- | | Free | 閲覧不可 (有料プランで閲覧可能) | | Pro | 90 日 | ## CLI [Section titled “CLI”](#cli) ```bash manako audit-logs list manako audit-logs list --action "monitor." --limit 20 ``` ## MCP [Section titled “MCP”](#mcp) Claude Code などの AI エージェントから MCP ツール経由でアクセスできます: ```json { "action": "list", "actionFilter": "monitor." } ``` # 料金プランと請求 > プランの選び方、アップグレード・ダウングレードの手順、支払いと請求書の管理 Manako のプランは Free / Pro の 2 種類です。全プランで HTTP / TCP / Ping の3種類のモニタータイプが使えます。 ## プランの概要 [Section titled “プランの概要”](#プランの概要) | | Free | Pro | | -------- | ---- | ------------- | | 料金 | $0 | $5/月（年払い $50） | | モニター数 | 3 | 20 | | 最短チェック間隔 | 5 分 | 3 分 | | データ保持 | 7 日 | 90 日 | | 通知チャネル種別 | 4 種 | 全 6 種 | | 監査ログ | – | ✓ | 年払いは 2 ヶ月分お得です。全項目の一覧は[プランと制限値](/reference/plans-limits/)を参照してください。 ## アップグレードする [Section titled “アップグレードする”](#アップグレードする) 1. 「設定 → 請求」を開く 2. 課金間隔（月払い / 年払い）を選ぶ 3. 目的のプランの「アップグレード」を押す 4. 決済ページでカード情報を入力して完了 アップグレードは**即時反映**されます。制限の緩和（モニター数・チェック間隔・通知チャネル）はすぐに使えます。 ## ダウングレードする [Section titled “ダウングレードする”](#ダウングレードする) 「設定 → 請求」から下位プランの「ダウングレード」を選びます。 注意 ダウングレード時の注意: - **データ保持期間が短くなる**と、次回の日次削除で新しい保持期間より古い通知履歴・解決済みインシデントが削除されます。復元はできません * モニター数などが新プランの上限を超えている場合は、事前に整理が必要です - Free で使えない通知チャネル（LINE / GitHub）は動作しなくなります ## 支払い方法・請求書の管理 [Section titled “支払い方法・請求書の管理”](#支払い方法請求書の管理) 「設定 → 請求」の「サブスクリプションを管理」から支払い管理画面（Stripe）を開けます。 * カード情報の変更 * 請求書・領収書のダウンロード * サブスクリプションの解約（解約後は次回更新日まで現プランが有効） ## 支払いに失敗したときは [Section titled “支払いに失敗したときは”](#支払いに失敗したときは) カードの期限切れ等で支払いに失敗した場合は、「サブスクリプションを管理」から支払い方法を更新してください。問題が解決しない場合は[お問い合わせ](/reference/screens/)からご連絡ください。 # インシデント対応 > インシデントの自動検知から確認・解決までの流れと、手動インシデントの使い方 モニターが障害を検知すると「インシデント」が作成されます。このガイドでは、インシデントの流れと対応方法を説明します。 ## インシデントのライフサイクル [Section titled “インシデントのライフサイクル”](#インシデントのライフサイクル) 1. **検知**: モニターのチェックが連続 5 回失敗すると、インシデントが自動作成され、[通知チャネル](/guides/notifications/)に通知が届きます（1 回の失敗では通知されません） 2. **対応開始（任意）**: 「対応開始」を押すとステータスが「確認済み」になり、チーム内に対応中であることを示せます 3. **解決**: モニターが復旧すると、インシデントは**自動的に解決済み**になり、復旧通知が届きます。「解決する」で手動解決も可能です 手動解決後もモニターが `down` のままなら、連続ダウン回数をゼロから数え直し、さらに 5 回連続で失敗した時点で新しいインシデントを作成して通知します。 判定条件の正確な仕様は[監視ライフサイクル](/reference/behavior/monitoring/)を参照してください。 ## インシデントを確認する [Section titled “インシデントを確認する”](#インシデントを確認する) サービス詳細画面（サービスカードをクリック）の「インシデント」タブに、そのサービスのインシデントが表示されます。 | ステータス | 意味 | | ------ | ------ | | 進行中（赤） | 障害が継続中 | | 確認済み | 誰かが対応中 | | 解決済み | 復旧済み | ノート 解決済みインシデントはプランの保持期間を過ぎると自動削除されます。進行中・確認済みのものは削除されません（[データ保持](/reference/behavior/data-retention/)参照）。 ## 手動インシデント [Section titled “手動インシデント”](#手動インシデント) モニターの自動検知とは別に、任意のインシデントを記録できます。ユーザー報告起点の障害や、監視対象外のコンポーネントの障害をステータスページに反映したい場合に使います。 1. サービス詳細の「インシデント」タブで「インシデントを作成」 2. タイトル等を入力して登録（「手動」バッジが付きます） 3. 対応が終わったら「解決する」 手動インシデントは手動で解決するまで残ります。また、手動インシデントのみ削除できます。 ## 警告インシデント（degraded） [Section titled “警告インシデント（degraded）”](#警告インシデントdegraded) チェックが失敗ではなく「判定できない」状態になった場合、通常の障害とは区別された**警告インシデント**（重大度 `warning`）が作成されます。現行の HTTP / TCP / Ping 監視は up / down のみを返すため、この状態は発生しません。 ## 通知が来ないときは [Section titled “通知が来ないときは”](#通知が来ないときは) * モニターに個別の通知チャネルを紐付けている場合、チーム全体のチャネルには通知されません（[通知の挙動](/reference/behavior/notifications/)参照） * 短時間にダウンと復旧を繰り返すと、フラップ抑制により通知が一時停止されます（インシデント自体は記録されています） * メンテナンスウィンドウ中はインシデント判定自体が停止します * 通知チャネルが「未確認」（メール）や無効になっていないか[連携設定](/reference/screens/settings/)を確認してください # セキュリティ設定 > OAuth ソーシャルログインと二要素認証 (MFA) でアカウントを保護する ## ソーシャルログイン (OAuth) [Section titled “ソーシャルログイン (OAuth)”](#ソーシャルログイン-oauth) Google または GitHub アカウントを使ってログインできます。 ### OAuth アカウントを接続する [Section titled “OAuth アカウントを接続する”](#oauth-アカウントを接続する) 既存のメール/パスワードアカウントに Google や GitHub を後から接続できます。 1. **セキュリティ設定を開く** ダッシュボード右上のユーザーメニューから「セキュリティ」を選択します。 2. **接続済みアカウントを確認する** 「接続済みアカウント」セクションに、現在接続されているプロバイダーが表示されます。 3. **新しいプロバイダーを接続する** 未接続のプロバイダーの「接続」ボタンをクリックし、認証を完了します。 ### OAuth アカウントの解除 [Section titled “OAuth アカウントの解除”](#oauth-アカウントの解除) 接続済みのプロバイダーを解除できます。ただし、以下の場合は解除できません。 * パスワード未設定で、接続済みプロバイダーが 1 つのみの場合 注意 全ての OAuth 接続を解除する場合は、先にパスワードを設定してください。ログイン手段がなくなることを防ぎます。 ## 二要素認証 (MFA) [Section titled “二要素認証 (MFA)”](#二要素認証-mfa) 二要素認証(MFA)を有効にすると、ログイン時にパスワードに加えて認証アプリのコードが必要になります。アカウントの不正アクセスを防ぐために、MFA の有効化を推奨します。 ## MFA を有効にする [Section titled “MFA を有効にする”](#mfa-を有効にする) 1. **セキュリティ設定を開く** ダッシュボード右上のユーザーメニューから「セキュリティ」を選択します。 2. **MFA を有効にする** 「MFA を有効にする」ボタンをクリックし、現在のパスワードを入力します。 3. **QR コードをスキャンする** 表示された QR コードを認証アプリ(Google Authenticator、Authy、1Password など)でスキャンします。手動入力用のシークレットコードも表示されます。 4. **確認コードを入力する** 認証アプリに表示されている 6 桁のコードを入力して、設定を完了します。 5. **リカバリーコードを保存する** 10 個のリカバリーコードが表示されます。認証アプリにアクセスできなくなった場合に使用するため、安全な場所に保存してください。この画面を閉じるとコードは二度と表示されません。 注意 リカバリーコードは各コード 1 回のみ使用可能です。全て使い切った場合は、セキュリティ設定からリカバリーコードを再生成してください。 ## MFA でのログイン [Section titled “MFA でのログイン”](#mfa-でのログイン) MFA を有効にすると、ログイン時にパスワード入力後、6 桁の認証コードの入力が求められます。認証アプリに表示されているコードを入力してください。 認証アプリにアクセスできない場合は、「リカバリーコードを使う」リンクから保存済みのリカバリーコードでログインできます。 ## MFA の管理 [Section titled “MFA の管理”](#mfa-の管理) ### リカバリーコードの再生成 [Section titled “リカバリーコードの再生成”](#リカバリーコードの再生成) セキュリティ設定から「リカバリーコードを再生成」を選択すると、新しいコードが発行されます。既存のコードは全て無効になります。 ### MFA を無効にする [Section titled “MFA を無効にする”](#mfa-を無効にする) セキュリティ設定から「MFA を無効にする」を選択し、パスワードを入力して確認します。 # モニター設定 > モニターの種類と設定方法 Manako では HTTP / TCP / Ping モニターを利用して、Web サイト、API、サーバーへの到達性を監視できます。 ## モニタータイプ [Section titled “モニタータイプ”](#モニタータイプ) [HTTP モニター ](/guides/monitors/http-monitors/)Web サイトや API にリクエストを送信し、レスポンスを確認。 [Ping モニター ](/guides/monitors/ping-monitors/)ホストへの TCP 到達性を監視 [TCP モニター ](/guides/monitors/tcp-monitors/)サーバーのポートへの接続を監視。 ## インシデント判定 [Section titled “インシデント判定”](#インシデント判定) モニターが連続して 5 回ダウンを検知すると、インシデントが作成されます。復旧を検知すると自動的にインシデントがクローズされます。 ヒント インシデント発生時に通知を受け取るには、[通知チャンネル](/guides/notifications/)を設定してください。 ## モニターの編集 [Section titled “モニターの編集”](#モニターの編集) 作成済みのモニターは、ダッシュボードから設定を変更できます。 1. ダッシュボードのモニター一覧で「Edit」をクリック、またはモニター詳細画面の「Edit」ボタンをクリック 2. 名前、設定項目、監視間隔を変更して「Update Monitor」をクリック ノート モニターの種類(HTTP、TCP など)は作成後に変更できません。種類を変更する場合は、新しいモニターを作成してください。 ## 監視間隔 [Section titled “監視間隔”](#監視間隔) | プラン | 最短間隔 | | ---- | ---------- | | Free | 300 秒(5 分) | | Pro | 180 秒(3 分) | # HTTP モニター > Web サイトや API エンドポイントの死活監視 Web サイトや API エンドポイントに定期的に HTTP リクエストを送信し、レスポンスのステータスコードやボディを確認します。 ## 使いどころ [Section titled “使いどころ”](#使いどころ) HTTP モニターは、単にサーバーへ接続できるかではなく、**アプリケーションが期待どおりの HTTP 応答を返すか**を確認したい場合に向いています。 * Web サイトや公開 API のステータスコードを確認する * ステータスコードが 200 のまま表示内容だけ変わる障害をキーワードで検知する * GET、HEAD、またはリクエストボディを必要としない POST エンドポイントを確認する ポートが開いていることだけを確認するなら [TCP モニター](./tcp-monitors/)、ホストへの到達性を確認するなら [Ping モニター](./ping-monitors/)を使います。 ## 設定手順 [Section titled “設定手順”](#設定手順) 1. サービス詳細から「新規モニター」を開き、タイプに **HTTP** を選択します。 2. URL にはリダイレクト前ではなく、実際に監視したい最終 URL を指定します。HTTP モニターはリダイレクトを追跡しません。 3. メソッドを選びます。通常は GET、ボディを取得せず応答だけを確認する場合は HEAD を選びます。POST を選んでもリクエストボディは送信されないため、空の POST を受け付けるエンドポイントに限って使用します。 4. 期待ステータスには、正常時に返るコードを 1 つ指定します。複数コードの許容範囲ではなく、指定値との完全一致で判定されます。 5. 必要に応じてキーワードと含有条件を設定します。HEAD ではレスポンスボディを確認できないため、キーワードチェックと組み合わせないでください。 6. 通常時の最大応答時間を考慮してタイムアウトを決め、プランの最短間隔以上のチェック間隔を選んで作成します。 画面上の入力項目、許容範囲、既定値は[モニター画面リファレンス](/reference/screens/monitors/)を参照してください。 ## HTTP メソッド [Section titled “HTTP メソッド”](#http-メソッド) | メソッド | 用途 | | ---- | ------------------------------------------ | | GET | 一般的な Web ページや API のチェック(デフォルト) | | HEAD | ボディ不要でステータスだけ確認したい場合。転送量を抑えられる | | POST | 空の POST を受け付けるエンドポイントのチェック。リクエストボディは送信されない | ## キーワードチェック [Section titled “キーワードチェック”](#キーワードチェック) レスポンスボディに特定の文字列が含まれる必要があるか、反対に含まれてはならないかを検証できます。ステータスコードが正常でも、ページ内容が条件と異なる場合は `down` になります。 例えば、メンテナンスページに切り替わった際にステータスコードは 200 のままでも、本来のコンテンツが表示されていないことを検知できます。 ## カスタムヘッダー [Section titled “カスタムヘッダー”](#カスタムヘッダー) カスタムヘッダーは Public API、CLI の `--config`、または MCP の `config` オブジェクトから指定できます。現在のダッシュボード画面にはカスタムヘッダーの入力欄はありません。ヘッダー名は英数字とハイフンのみ使用可能で、値に改行は使用できません。 以下のヘッダーはセキュリティ上の理由で設定できません: * `Host` * `Authorization` * `Cookie` / `Set-Cookie` * `Transfer-Encoding` * `Content-Length` ## 判定の仕組み [Section titled “判定の仕組み”](#判定の仕組み) リクエストは設定したタイムアウトで `AbortController` により打ち切られます。次のいずれかに該当すると `down` になります。 * 300 番台のリダイレクトが返る（期待ステータスに同じコードを指定していても追跡せず `down`） * レスポンスのステータスコードが期待値と異なる * レスポンスがタイムアウト時間内に返らない * レスポンスボディが設定したキーワードの含有条件を満たさない * 接続エラー(DNS 解決失敗、接続拒否など) `down` がいつインシデントになるかは[監視ライフサイクル](/reference/behavior/monitoring/)を参照してください。 ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) | 症状 | 確認すること | | -------------------------- | -------------------------------------------------------------------------- | | 301 / 302 で `down` になる | `Location` が指す最終 URL を監視対象に設定する | | HEAD とキーワードの組み合わせで失敗する | ボディを確認する場合は GET に変更する | | 期待ステータスが合わない | 認証前後やメンテナンス時ではなく、正常時に実際に返る 1 コードを指定する | | `Request timed out` と表示される | 通常時の応答時間を確認し、必要ならタイムアウトを最大 30 秒まで延ばす。長時間処理ではなく軽量なヘルスエンドポイントを監視する | | URL が登録できない | `http://` または `https://` のパブリック URL を指定する。localhost、プライベート IP、内部ホストは使用できない | | 認証必須の URL を監視できない | `Authorization` や `Cookie` は設定できないため、機密情報を要求しない専用ヘルスエンドポイントを用意する | | POST 先が入力不足を返す | HTTP モニターはリクエストボディを送らない。空の POST を受け付けない場合は監視用エンドポイントを分ける | ノート プライベート IP アドレスや localhost へのリクエストは SSRF 対策のためブロックされます。 # Ping モニター > ホストへの TCP 到達性を監視 ホストへの TCP 接続による到達性チェックを行います。サーバーやネットワーク機器が応答しているかの確認に使用します。 ## 使いどころ [Section titled “使いどころ”](#使いどころ) Ping モニターは、ホストの代表ポートに TCP 接続し、**ホストへ到達できるかを簡単に確認する**用途に向いています。名前に Ping とありますが、ICMP Echo は送信しません。既定では TCP ポート 443 に接続します。 * Web サーバーなど、443 番ポートを公開しているホストの到達性を確認する * HTTP ステータスやレスポンスボディを評価せず、接続可否だけを監視する * 代表ポートを 1 つ選び、ホスト単位の疎通として扱う 監視対象が ICMP だけに応答する機器には向きません。HTTP 応答の正しさを確認するなら [HTTP モニター](./http-monitors/)、特定サービスのポートを明示して運用するなら [TCP モニター](./tcp-monitors/)を使います。 ## 設定手順 [Section titled “設定手順”](#設定手順) 1. サービス詳細から「新規モニター」を開き、タイプに **Ping** を選択します。 2. ホスト名にはスキームやパスを付けず、外部から名前解決できるパブリックなホストを指定します。 3. ポートは、ホストが通常時に必ず受け付ける TCP ポートを選びます。省略時は 443 です。 4. 通常の接続時間を考慮してタイムアウトを決め、プランの最短間隔以上のチェック間隔を選んで作成します。 画面上の入力項目、許容範囲、既定値は[モニター画面リファレンス](/reference/screens/monitors/)を参照してください。 ヒント ポートを指定しない場合、デフォルトで TCP 443 に接続します。HTTPS のステータスコードや証明書は検証しません。 ## TCP モニターとの違い [Section titled “TCP モニターとの違い”](#tcp-モニターとの違い) | | Ping モニター | TCP モニター | | ---- | ------------------ | ---------------------------------------- | | 用途 | 代表ポートによるホスト到達性確認 | 特定サービスポートの死活監視 | | ポート | オプション(デフォルト 443) | 必須 | | 接続方法 | 指定ポートへの raw TCP 接続 | 443 / 8443 は HTTPS HEAD、それ以外は raw TCP 接続 | | 判定内容 | TCP 接続の成否 | TCP または HTTPS 接続の成否。サービス固有の応答内容は見ない | ## 判定の仕組み [Section titled “判定の仕組み”](#判定の仕組み) * DNS 解決後、設定したポートへ raw TCP 接続します。 * 接続が開けば `up`、接続拒否、DNS 解決失敗、またはタイムアウトなら `down` です。 * ICMP、HTTP ステータス、TLS 証明書、アプリケーションの応答内容は確認しません。 `down` がいつインシデントになるかは[監視ライフサイクル](/reference/behavior/monitoring/)を参照してください。 ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) | 症状 | 確認すること | | -------------------------- | ------------------------------------------------ | | ICMP ping は通るのに `down` になる | Ping モニターは ICMP ではない。設定した TCP ポートが外部から開いているか確認する | | 既定設定で `down` になる | 対象が TCP 443 を受け付けるか確認し、必要なら常時開いている別ポートを指定する | | 接続拒否になる | ポート番号とサービスのリッスン状態を確認する | | タイムアウトする | DNS、外部向けファイアウォール、経路を確認し、必要ならタイムアウトを延ばす | | `up` だが Web サイトはエラーを返す | Ping は接続可否しか確認しない。HTTP モニターを併用する | | ホスト名が登録できない | localhost、プライベート IP、内部ホストではなくパブリックなホスト名を指定する | ノート プライベート IP アドレスや localhost への接続は SSRF 対策のためブロックされます。 # TCP モニター > サーバーのポートへの TCP 接続を監視 サーバーの特定ポートへの TCP 接続を監視します。データベースやメールサーバーなど、HTTP 以外のサービスの死活監視に使用します。 ## 使いどころ [Section titled “使いどころ”](#使いどころ) TCP モニターは、データベース、メール、SSH などの**特定ポートが外部から接続可能か**を確認したい場合に向いています。TCP 接続が成立した時点で正常とみなし、サービス固有のコマンド、認証、応答内容までは確認しません。 * HTTP 以外のサービスのリッスン状態を確認する * ファイアウォールや公開ポートの到達性を確認する * HTTP 応答コードではなく、ポート接続の成否だけを監視する Web アプリケーションの応答内容を確認するなら [HTTP モニター](./http-monitors/)、ポートを省略してホストの代表的な到達性を確認するなら [Ping モニター](./ping-monitors/)を使います。 ## 設定手順 [Section titled “設定手順”](#設定手順) 1. サービス詳細から「新規モニター」を開き、タイプに **TCP** を選択します。 2. ホスト名にはスキームやパスを付けず、外部から名前解決できるパブリックなホストを指定します。 3. 実際にサービスが待ち受けるポートを指定します。代表例は SSH の 22、SMTP の 25 / 587、PostgreSQL の 5432、MySQL の 3306、Redis の 6379 です。 4. 起動直後など通常時の接続遅延を考慮してタイムアウトを決めます。短すぎる値は一時的な遅延を障害と判定し、長すぎる値は検知を遅らせます。 5. プランの最短間隔以上のチェック間隔を選び、作成します。 画面上の入力項目、許容範囲、既定値は[モニター画面リファレンス](/reference/screens/monitors/)を参照してください。 ## 判定の仕組み [Section titled “判定の仕組み”](#判定の仕組み) * ポート 443 と 8443 は HTTPS の HEAD リクエストで到達性を確認します。4xx / 5xx を含め、HTTP 応答が返ればポートは `up` です。 * それ以外のポートは raw TCP 接続を行い、接続が開けば `up` です。 * 接続拒否、DNS 解決失敗、または設定時間内に接続できない場合は `down` です。 * アプリケーションプロトコルの内容や認証結果は検証しません。 `down` がいつインシデントになるかは[監視ライフサイクル](/reference/behavior/monitoring/)を参照してください。 ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) | 症状 | 確認すること | | ----------------------------- | ------------------------------------------------------------- | | `Connection timed out` と表示される | ポート番号、外部向けファイアウォール、サービスのリッスン状態を確認し、必要ならタイムアウトを延ばす | | 接続拒否になる | 指定ポートでプロセスが待ち受けているか、ホスト名が正しいサーバーを指しているか確認する | | 443 / 8443 上の非 HTTP サービスが失敗する | この 2 ポートは HTTPS HEAD で確認する。非 HTTP の TLS サービスには別のポートを使う構成を検討する | | 4xx / 5xx でも `up` になる | TCP モニターはポート到達性だけを確認する。HTTP ステータスを判定する場合は HTTP モニターへ切り替える | | ポートは `up` だがサービス操作に失敗する | TCP 接続後の認証やクエリは検証しない。サービス固有のヘルスエンドポイントなどを別途監視する | | ホスト名が登録できない | localhost、プライベート IP、内部ホストではなくパブリックなホスト名を指定する | ノート プライベート IP アドレスや localhost への接続は SSRF 対策のためブロックされます。 # 通知設定 > 通知の仕組みと設定方法 モニターがインシデントを検知、または復旧した際に通知を受け取れます。 Manako は Email、Slack、Discord、LINE、Webhook、GitHub の6種類の通知チャンネルに対応しています。いずれも同じ仕組みで動作し、同じ画面から設定できます。 ## 通知の仕組み [Section titled “通知の仕組み”](#通知の仕組み) モニターが連続して 5 回ダウンを検知するとインシデントが作成され、設定された通知チャンネルにアラートが送信されます。復旧を検知すると自動的にインシデントがクローズされ、復旧通知が送信されます。 ## 通知イベント [Section titled “通知イベント”](#通知イベント) | イベント | 発火条件 | | -------- | --------------------------------- | | インシデント発生 | モニターが連続 5 回ダウンを検知し、インシデントが作成されたとき | | インシデント復旧 | ダウン中のモニターが正常に戻り、インシデントがクローズされたとき | ## 対応チャンネル [Section titled “対応チャンネル”](#対応チャンネル) [Email ](/guides/notifications/email-notifications/)メールアドレスを入力するだけ。シンプルな通知に。 [Slack ](/guides/notifications/slack-notifications/)Incoming Webhook でチャンネルに通知。 [Discord ](/guides/notifications/discord-notifications/)Webhook で Embed メッセージを送信。 [LINE ](/guides/notifications/line-notifications/)Messaging API でプッシュ通知。 [Webhook ](/guides/notifications/webhook-notifications/)任意の HTTPS エンドポイントに JSON を送信。 [GitHub Issues ](/guides/notifications/github-notifications/)インシデント時に Issue を自動作成・クローズ。 ## プラン別制限 [Section titled “プラン別制限”](#プラン別制限) ### 利用可能チャンネル [Section titled “利用可能チャンネル”](#利用可能チャンネル) | プラン | 利用可能チャンネル | | ---- | ------------------------------------ | | Free | Email, Slack, Discord, Webhook (4 種) | | Pro | 全 6 種 (上記 + LINE, GitHub) | ### チャンネル数上限 [Section titled “チャンネル数上限”](#チャンネル数上限) | プラン | 最大チャンネル数 | | ---- | -------- | | Free | 5 | | Pro | 15 | ## 通知先の割り当て [Section titled “通知先の割り当て”](#通知先の割り当て) 通知先は 2 つのレベルで設定できます: * **モニター単位**: 特定のモニターにチャンネルを紐づけ(優先) * **チーム全体**: デフォルトの通知先として設定(フォールバック) モニターに個別のチャンネルが設定されている場合はそちらが優先されます。設定がない場合はチーム全体のデフォルト通知先が使用されます。 ヒント 重要なモニターには専用の通知チャンネルを設定し、それ以外はチーム全体のデフォルトに任せるのがおすすめです。 ## テスト通知 [Section titled “テスト通知”](#テスト通知) 通知チャンネルの設定が正しいか確認するために、テスト通知を送信できます。 ダッシュボードの「通知チャンネル」一覧で、各チャンネルの **Test** ボタンをクリックすると、テスト通知が即座に送信されます。送信に成功すれば設定は正しく動作しています。 ノート テスト通知は 60 秒に 1 回まで送信できます。GitHub チャンネルでは、テスト通知として Issue を作成せず、接続の疎通確認のみを行います。 ## フラップガード [Section titled “フラップガード”](#フラップガード) 短時間にダウンと復旧を繰り返す(フラッピング)場合、通知が大量に送信されるのを防ぐためにフラップガードが自動的に有効になります。 | 項目 | 値 | | ----- | ----------------------------------- | | ウィンドウ | 10 分 | | 閾値 | 3 回 | | 動作 | 10 分以内に 3 回を超える状態変化が発生すると、通知を一時的に抑制 | | 解除 | ウィンドウ(10 分)の経過後に自動解除 | ノート フラップガードは通知の抑制のみを行います。モニターの監視やインシデントの記録には影響しません。KV の障害時にはフラップガードが自動的にバイパスされ、通知の送信が優先されます。 ## リトライ [Section titled “リトライ”](#リトライ) すべての通知チャンネルへの送信が失敗した場合、Cloudflare Queues のリトライ機能により自動的に再送が試みられます。一部のチャンネルが成功している場合はリトライされません。 ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) ### 通知が届かない [Section titled “通知が届かない”](#通知が届かない) 1. **テスト通知を試す**: チャンネルの **Test** ボタンでテスト通知を送信し、設定が正しいか確認してください 2. **通知チャンネルが有効か確認**: ダッシュボードの「通知チャンネル」一覧でチャンネルが表示されているか確認してください 3. **モニターに紐づいているか確認**: モニター単位の通知を使っている場合、対象モニターにチャンネルが紐づいているか確認してください。紐づけがない場合はチーム全体のデフォルト通知先が使われます 4. **フラップガードを確認**: 短時間に状態変化が多い場合、フラップガードにより通知が抑制されている可能性があります ### Webhook の署名検証エラー [Section titled “Webhook の署名検証エラー”](#webhook-の署名検証エラー) Webhook の署名が合わない場合は、[Webhook 通知](/guides/notifications/webhook-notifications/) の署名検証セクションを参照してください。 # Discord 通知 > Discord Webhook を使った通知の設定方法 Discord の Webhook を使って、モニターのインシデント通知を Discord チャンネルに Embed メッセージとして送信できます。 ## 事前準備: Discord Webhook の作成 [Section titled “事前準備: Discord Webhook の作成”](#事前準備-discord-webhook-の作成) 1. **サーバーの連携設定を開く** 対象サーバーの設定から「連携サービス」>「ウェブフック」を開きます。この操作には Webhook を管理する権限が必要です。 2. **Webhook を作成** 「Webhook を作成」を選択します。 3. **送信先を指定** 通知を投稿するチャンネルと、わかりやすい名前（例: Manako）を指定します。 4. **Webhook URL をコピーする** 作成したウェブフックの「ウェブフック URL をコピー」をクリックします。 ノート Webhook URL は `https://discord.com/api/webhooks/` または `https://discordapp.com/api/webhooks/` で始まる必要があります。 ## Manako での設定 [Section titled “Manako での設定”](#manako-での設定) 1. ダッシュボードで「設定」>「連携」を開き、**Discord** の「設定」を選択 2. **名前**に識別しやすい名前を入力 3. **Discord Webhook URL** にコピーした URL を貼り付け 4. 「追加」を選択 ノート Discord は Free / Pro の全プランで利用できます。Webhook URL は送信権限を含むため、秘密情報として管理してください。 ## 通知メッセージの見え方 [Section titled “通知メッセージの見え方”](#通知メッセージの見え方) Discord には Embed メッセージとして送信され、イベントの種類に応じて色分けされます。 ### インシデント発生時 [Section titled “インシデント発生時”](#インシデント発生時) | 項目 | 内容 | | ----- | --------------------------------------------- | | 色 | 赤 (`#ef4444`) | | タイトル | Monitor Down | | 説明 | **{モニター名}** is down | | フィールド | Monitor: {モニター名}, URL: {監視対象URL}, Incident ID | ### インシデント復旧時 [Section titled “インシデント復旧時”](#インシデント復旧時) | 項目 | 内容 | | ----- | ----------------------------- | | 色 | 緑 (`#22c55e`) | | タイトル | Monitor Recovered | | 説明 | **{モニター名}** is back up | | フィールド | Monitor: {モニター名}, Incident ID | メンテナンス開始・終了も Embed として送信され、開始時には対象モニターと終了予定時刻が含まれます。 ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) * **設定時に URL エラーになる**: HTTPS の `discord.com` または `discordapp.com` で、パスが `/api/webhooks/` から始まる URL だけを受け付けます。 * **送信されない**: Discord 側で Webhook が削除・再生成されていないか、Webhook が対象チャンネルへ投稿できるか確認してください。 * **テストは届くが通常通知が届かない**: モニターに個別の通知先が関連付けられている場合、有効な関連付けだけが使われます。関連付けがすべて無効でもチーム全体へはフォールバックしません。 * **短時間の通知が途中から届かない**: 同じモニターで 10 分以内に 3 回を超える状態変化があると、フラップ抑制により後続通知が抑制されます。 * **重複して見える**: 同じインシデント・チャンネル・イベント種別の送信済み記録は再送をスキップします。発生と復旧は別イベントで、失敗または処理中の記録は再試行されます。 設定一覧の「Test」は実際に Discord へ Embed を送信し、成功後は 60 秒のクールダウンがあります。個別チャンネルの失敗は他チャンネルの処理を止めません。 フラップ抑制とインシデント単位の送信済み判定はインシデント通知に適用されます。メンテナンス通知はこれらを使わず、有効かつ確認済みのチームチャンネルへ送信されます。 # Email 通知 > メールでの通知設定方法 メールアドレスを登録するだけで、インシデントの発生・復旧時にメール通知を受け取れます。 ## 外部サービス側の準備 [Section titled “外部サービス側の準備”](#外部サービス側の準備) 外部サービスの API キーは不要です。通知を受け取れるメールアドレスを用意し、`notifications@manako.dev` からの確認メールと通知メールを受信できるようにしてください。 ## Manako での設定 [Section titled “Manako での設定”](#manako-での設定) 1. ダッシュボードで「設定」>「連携」を開き、**Email** の「設定」を選択 2. **名前**に識別しやすい名前、**宛先 (メールアドレス)** に通知先を入力 3. 「追加」を選択 4. 届いた確認メールのリンクを 24 時間以内に開く 未確認の Email チャンネルは通常通知の送信先になりません。確認メールが届かなかった場合は、Email の設定一覧にある再送操作を使用してください。 ノート Email は Free / Pro の全プランで利用できます。通知チャンネル数の上限は Free 5、Pro 15 です。 ## 送信元 [Section titled “送信元”](#送信元) 通知メールは以下のアドレスから送信されます: ```plaintext Manako ``` ヒント 通知メールが迷惑メールフォルダに振り分けられる場合は、`notifications@manako.dev` を連絡先やアドレス帳に追加してください。 ## メールの形式 [Section titled “メールの形式”](#メールの形式) ### インシデント発生時 [Section titled “インシデント発生時”](#インシデント発生時) * **件名**: `[Manako] {モニター名} is DOWN` * **本文**: モニター名、インシデント ID、監視対象 URL ### インシデント復旧時 [Section titled “インシデント復旧時”](#インシデント復旧時) * **件名**: `[Manako] {モニター名} is back UP` * **本文**: モニター名、インシデント ID メンテナンス開始・終了時にも、対象モニターと終了予定時刻（開始時）が記載されたメールが送信されます。 ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) * **確認メールや通知が届かない**: 迷惑メールフォルダと受信許可設定を確認します。チャンネルが「未確認」の場合は確認メールを再送してください。 * **テストは届くが通常通知が届かない**: モニターに個別の通知先が関連付けられている場合、関連付けられた有効かつ確認済みのチャンネルだけが使われます。関連付けがあるのにすべて無効でも、チーム全体のチャンネルへはフォールバックしません。 * **短時間の発生・復旧が途中から届かない**: 同じモニターで 10 分以内に 3 回を超える状態変化があると、フラップ抑制により後続通知が抑制されます。 * **重複して見える**: `incident.created` と `incident.resolved` は別イベントです。同じインシデント・同じチャンネル・同じイベント種別で送信済みの記録がある再試行はスキップされ、DB の UNIQUE 制約も重複記録を防ぎます。失敗または処理中の記録は再試行対象です。 設定一覧の「Test」は実際のテストメールを送信します。成功後は同じチャンネルで 60 秒のクールダウンがあります。あるチャンネルの送信失敗は他チャンネルの送信を止めませんが、すべての送信先が失敗した場合は Queue の再試行対象になります。 フラップ抑制とインシデント単位の送信済み判定はインシデント通知に適用されます。メンテナンス通知はこれらを使わず、有効かつ確認済みのチームチャンネルへ送信されます。 # GitHub Issues 通知 > インシデント発生時に GitHub Issue を自動作成する設定方法 インシデント発生時に GitHub Issue を自動作成し、復旧時にコメント追加 + クローズできます。 ## 事前準備: Personal Access Token の取得 [Section titled “事前準備: Personal Access Token の取得”](#事前準備-personal-access-token-の取得) 1. **GitHub にログイン** [GitHub](https://github.com) にログインします。 2. **Fine-grained Personal Access Token を作成** Settings > Developer settings > Personal access tokens > Fine-grained tokens から「Generate new token」をクリックします。 3. **権限を設定** * Repository access: Issue を作成したいリポジトリを選択 * Permissions > Repository permissions > Issues: **Read and write** Token を作成するユーザー自身にも対象リポジトリへのアクセス権が必要です。Organization のポリシーで承認が必要な場合は、利用可能になるまで承認を完了します。 4. **トークンをコピー** `github_pat_` で始まるトークンをコピーします。 注意 Token はパスワードと同様に扱ってください。Fine-grained PAT は対象リポジトリと Issues の書き込み権限だけに絞れます。 ## Manako での設定 [Section titled “Manako での設定”](#manako-での設定) 1. ダッシュボードで「設定」>「連携」を開き、**GitHub** の「設定」を選択 2. **名前**に識別しやすい名前を入力 3. 以下を入力: * **Token**: Personal Access Token * **Owner**: リポジトリオーナー (ユーザー名 or 組織名) * **Repo**: リポジトリ名 * **Labels** (任意): Issue に付与するラベル (例: `incident`, `manako`) 4. 「追加」を選択 ノート GitHub は Pro プランで利用できます。Free プランでは作成できません。Labels は最大10件、各50文字までです。 ## 動作 [Section titled “動作”](#動作) | Manako イベント | GitHub アクション | | ----------- | ------------------------ | | インシデント発生 | Issue 作成 (タイトル、詳細情報、ラベル) | | インシデント復旧 | Issue にコメント追加 + クローズ | | メンテナンス開始・終了 | 何もしない | ### Issue ↔ インシデントのマッピング [Section titled “Issue ↔ インシデントのマッピング”](#issue--インシデントのマッピング) Manako はインシデントごとに作成した Issue 番号を記憶し、復旧時に自動でクローズします。 ノート 複数の GitHub チャンネル(異なるリポジトリ)を設定した場合、それぞれのリポジトリに Issue が作成され、個別にクローズされます。 作成した Issue 番号はチャンネル単位で 90 日間保持されます。復旧時は解決コメントの追加を試みた後、Issue を `completed` としてクローズします。コメント追加だけに失敗してもクローズ処理は継続します。 ### Issue の例 [Section titled “Issue の例”](#issue-の例) **インシデント発生時:** ```markdown ## Incident Details - **Monitor**: API Health - **Monitor ID**: 01JABC... - **URL**: https://example.com/health - **Incident ID**: 01JXYZ... - **Detected at**: 2026-03-26T12:00:00Z --- _Auto-created by Manako monitoring_ ``` ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) * **Test が失敗する**: Test は Issue を作らず、Token で `Owner/Repository` を取得できるかだけを確認します。Token の対象リポジトリ、期限、Organization の承認、ユーザー自身のアクセス権を確認してください。 * **通常通知で Issue が作られない**: Issues が無効なリポジトリでは作成 API が失敗します。Labels を指定した場合は、Token のユーザーがそれらを付与できることも確認してください。 * **復旧しても Issue が閉じない**: 作成時の Issue 番号マッピングを保存できなかった、90 日の保持期間を過ぎた、または復旧時にマッピングが見つからない場合は自動クローズされません。 * **メンテナンス通知がない**: GitHub 連携はメンテナンス開始・終了を処理しません。 * **テストは通るが通常通知が届かない**: モニター個別の通知先関連付けを確認します。関連付けがすべて無効でもチーム全体へはフォールバックしません。 * **短時間の通知が途中から届かない**: 同じモニターで 10 分以内に 3 回を超える状態変化があるとフラップ抑制が働きます。 * **重複して見える**: 同じインシデント・チャンネル・イベント種別で送信済みなら再試行はスキップされます。失敗または処理中の送信は再試行されます。 Test の成功後は 60 秒のクールダウンがあります。1つの GitHub チャンネルの失敗は他チャンネルの送信を止めません。 # LINE通知 > LINE Messaging APIを使った通知の設定方法 LINE Messaging API を使って、モニターのインシデント通知を LINE に送信できます。 ノート LINE 通知は Pro プランで利用可能です。Free プランでは作成できません。 ## 事前準備 [Section titled “事前準備”](#事前準備) 1. **LINE 公式アカウントと Messaging API チャネルを用意** [LINE 公式ドキュメント](https://developers.line.biz/en/docs/messaging-api/getting-started/)に従い、LINE 公式アカウントで Messaging API を有効にします。Manako は Messaging API チャネルの認証情報を必要とします。 2. **Channel Access Token を発行** Messaging API チャネルで有効な Channel Access Token を発行し、安全に保存します。Manako の **Channel Access Token** に入力する値です。 3. **送信先 ID を取得** ユーザー、グループ、ルームから届く Webhook イベントの `source.userId`、`source.groupId`、`source.roomId` のいずれかを取得します。Manako の **送信先ID** に入力する値です。 4. **Bot と送信先の関係を確認** ユーザー宛てでは LINE 公式アカウントを友だち追加し、グループまたはルーム宛てでは Bot を対象の会話へ参加させます。 ノート LINE の Push API は **Bot と友だちになっているユーザーにのみ** メッセージを送信できます。友だち追加していない場合、通知は失敗します。 ## 送信先IDの取得 [Section titled “送信先IDの取得”](#送信先idの取得) | 送信先 | ID形式 | 取得方法 | | ---- | ------------ | ------------------------------ | | ユーザー | `U` + 32桁hex | Webhook イベントの `source.userId` | | グループ | `C` + 32桁hex | Webhook イベントの `source.groupId` | | ルーム | `R` + 32桁hex | Webhook イベントの `source.roomId` | ## Manakoでの設定 [Section titled “Manakoでの設定”](#manakoでの設定) 1. ダッシュボードで「設定」>「連携」を開き、**LINE** の「設定」を選択 2. **名前**に識別しやすい名前を入力 3. **Channel Access Token** と **送信先ID** を入力 4. 「追加」を選択 設定後、モニターがインシデントを検知または復旧した際に LINE メッセージが送信されます。 ## 通知メッセージの見え方 [Section titled “通知メッセージの見え方”](#通知メッセージの見え方) 通常通知は LINE Flex Message として送信され、状態ごとにヘッダーの色が変わります。設定一覧のテスト通知だけはテキストメッセージです。 ### インシデント発生時 [Section titled “インシデント発生時”](#インシデント発生時) | セクション | 内容 | | ----- | ------------------------------------- | | ヘッダー | `🔴 ダウン検知`（warning の場合は `⚠️ 警告`） | | 本文 | モニター名、監視対象 URL（ある場合）、`ID: {インシデントID}` | | フッター | Manako | ### インシデント復旧時 [Section titled “インシデント復旧時”](#インシデント復旧時) | セクション | 内容 | | ----- | ------------------------------- | | ヘッダー | `🟢 復旧`（手動インシデントの場合は `🟢 解決済み`） | | 本文 | モニター名、`ID: {インシデントID}` | | フッター | Manako | ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) * **設定時に送信先 ID エラーになる**: `U`、`C`、`R` のいずれかに 32 桁の16進数が続く形式だけを受け付けます。表示名や LINE ID は使用できません。 * **API エラーまたは未着になる**: Token が失効・取り消しされていないか、ユーザーが友だち追加済みか、Bot が対象グループ/ルームに参加しているかを確認します。ブロックされたユーザーなどでは LINE API が成功しても受信されない場合があります。 * **テストは届くが通常通知が届かない**: モニターに通知先の関連付けがある場合、有効な関連付けだけが使われ、すべて無効でもチーム全体へはフォールバックしません。 * **短時間の通知が途中から届かない**: 同じモニターで 10 分以内に 3 回を超える状態変化があるとフラップ抑制が働きます。 * **重複して見える**: 同じインシデント・チャンネル・イベント種別で送信済みなら再試行はスキップされます。発生と復旧は別イベントで、失敗または処理中の送信は再試行されます。 「Test」は実際に LINE へテキストを送信し、成功後は 60 秒のクールダウンがあります。個別チャンネルの失敗は他チャンネルの送信を止めません。 フラップ抑制とインシデント単位の送信済み判定はインシデント通知に適用されます。メンテナンス通知はこれらを使わず、有効かつ確認済みのチームチャンネルへ送信されます。 # Slack 通知 > Slack Incoming Webhook を使った通知の設定方法 Slack の Incoming Webhook を使って、モニターのインシデント通知を Slack チャンネルに送信できます。 ## 事前準備: Slack Incoming Webhook の作成 [Section titled “事前準備: Slack Incoming Webhook の作成”](#事前準備-slack-incoming-webhook-の作成) 1. **Slack App を作成する** [Slack API: Applications](https://api.slack.com/apps) にアクセスし、「Create New App」から「From scratch」を選択します。App Name と通知を送りたいワークスペースを指定します。 2. **Incoming Webhooks を有効にする** 作成した App の設定ページで「Incoming Webhooks」を開き、トグルを ON にします。 3. **Webhook URL を発行する** 「Add New Webhook to Workspace」をクリックし、通知を送信したいチャンネルを選択して「許可する」をクリックします。 4. **Webhook URL をコピーする** `https://hooks.slack.com/services/T.../B.../xxx` の形式の URL が表示されるのでコピーします。 ノート Webhook URL は `https://hooks.slack.com/` で始まる必要があります。それ以外の URL は設定時にエラーになります。 ## Manako での設定 [Section titled “Manako での設定”](#manako-での設定) 1. ダッシュボードで「設定」>「連携」を開き、**Slack** の「設定」を選択 2. **名前**に識別しやすい名前を入力 3. **Slack Webhook URL** にコピーした Incoming Webhook URL を貼り付け 4. 「追加」を選択 ノート Slack は Free / Pro の全プランで利用できます。Webhook URL は送信権限を持つ秘密情報として扱い、公開リポジトリやチャットへ貼り付けないでください。 ## 通知メッセージの見え方 [Section titled “通知メッセージの見え方”](#通知メッセージの見え方) Slack はテキスト形式のメッセージとして送信されます。絵文字は Slack のエイリアス形式(`:red_circle:` 等)で送信され、Slack 上でレンダリングされます。 ### インシデント発生時 [Section titled “インシデント発生時”](#インシデント発生時) ```plaintext :red_circle: *{モニター名}* is DOWN Incident: {インシデントID} URL: {監視対象URL} ``` ### インシデント復旧時 [Section titled “インシデント復旧時”](#インシデント復旧時) ```plaintext :large_green_circle: *{モニター名}* is back UP Incident: {インシデントID} ``` メンテナンス開始・終了時には、対象モニターの一覧と、開始通知では終了予定時刻も送信されます。 ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) * **設定時に URL エラーになる**: Manako が受け付けるのは HTTPS の `https://hooks.slack.com/` で始まる URL だけです。GovSlack など別ホストの Webhook URL には対応していません。 * **送信先が違う、または届かない**: Incoming Webhook は発行時に選んだ会話に紐付きます。Slack 側で App のアクセスや Webhook が無効化されていないか確認してください。 * **テストは届くが通常通知が届かない**: モニターに通知先の関連付けがある場合、関連付けられた有効なチャンネルだけが使われます。関連付けがすべて無効でもチーム全体のチャンネルへはフォールバックしません。 * **短時間の通知が途中から届かない**: 同じモニターで 10 分以内に 3 回を超える状態変化があると、フラップ抑制により後続通知が抑制されます。 * **重複して見える**: 発生と復旧は別イベントです。同じインシデント・チャンネル・イベント種別で送信済みなら再試行はスキップされ、失敗または処理中の送信だけが再試行されます。 設定一覧の「Test」は実際に Slack へテストメッセージを送信し、成功後は 60 秒のクールダウンがあります。1つのチャンネルの失敗は他チャンネルの送信を止めません。 フラップ抑制とインシデント単位の送信済み判定はインシデント通知に適用されます。メンテナンス通知はこれらを使わず、有効かつ確認済みのチームチャンネルへ送信されます。 # Webhook 通知 > 汎用 Webhook による通知の設定と連携方法 汎用 Webhook を使って、任意の HTTPS エンドポイントにインシデント通知を JSON 形式で送信できます。自社のシステムや自動化ツールとの連携に便利です。 ## 要件 [Section titled “要件”](#要件) * **HTTPS 必須**: HTTP(非暗号化)の URL は使用できません * **パブリックエンドポイント**: プライベートネットワークの URL はブロックされます * **署名検証用シークレット**: 1 文字以上の任意の文字列 注意 以下のホストへの送信はセキュリティ上ブロックされます: `localhost`, `127.x.x.x`, `0.0.0.0`, `::1`, `169.254.169.254`, `metadata.google.internal`, プライベート IP アドレス(10.x.x.x, 172.16-31.x.x, 192.168.x.x) ## 外部サービス側の準備 [Section titled “外部サービス側の準備”](#外部サービス側の準備) 1. インターネットから到達できる HTTPS エンドポイントを用意し、`POST` の JSON ボディを受け取れるようにする 2. Manako と受信側だけが共有する署名検証用シークレットを生成する 3. 受信時に raw リクエストボディと `X-Manako-Signature` を使って HMAC-SHA256 署名を検証する 4. 正常に受理したときは 2xx を返す。3xx リダイレクトは追従されません ## Manako での設定 [Section titled “Manako での設定”](#manako-での設定) 1. ダッシュボードで「設定」>「連携」を開き、**Webhook** の「設定」を選択 2. **名前**に識別しやすい名前を入力 3. **Webhook URL (HTTPS)** に受信先 URL を入力 4. **Secret** に受信側と共有するシークレットを入力 5. 「追加」を選択 ノート Webhook は Free / Pro の全プランで利用できます。 ## ペイロード [Section titled “ペイロード”](#ペイロード) 通知は `POST` リクエストとして送信されます。`Content-Type` は `application/json` です。 ### 共通フィールド [Section titled “共通フィールド”](#共通フィールド) すべてのイベントに含まれるフィールド: | フィールド | 型 | 説明 | | ----------- | ------ | ------------------- | | `event` | string | イベント種別 | | `teamId` | string | チーム ID | | `timestamp` | string | ISO 8601 形式のタイムスタンプ | `monitorName`、`monitorId`、`incidentId` はインシデントイベントに含まれます。メンテナンスイベントは代わりに `monitorIds` と `monitorNames` を含みます。 ### イベント別追加フィールド [Section titled “イベント別追加フィールド”](#イベント別追加フィールド) | イベント | フィールド | 型 | 説明 | | ---------------------------------------- | ------------------------------------------------ | ------------------- | --------------------------------- | | `incident.created` | `monitorUrl` | string | 監視対象の URL | | `incident.created` | `severity` | string | 重大度(`"critical"` または `"warning"`) | | `incident.created` / `incident.resolved` | `title` | string \| undefined | 手動インシデントのタイトル(自動インシデントでは省略) | | `maintenance.started` | `monitorIds`, `monitorNames`, `maintenanceUntil` | string\[] / string | 対象モニターと終了予定時刻 | | `maintenance.ended` | `monitorIds`, `monitorNames` | string\[] | 対象モニター | ### ペイロード例 [Section titled “ペイロード例”](#ペイロード例) * インシデント発生 ```json { "event": "incident.created", "monitorName": "API Server", "monitorId": "01JWAB1234567890ABCDEF", "teamId": "01JWAB0987654321FEDCBA", "incidentId": "01JWABINCIDENT12345678", "monitorUrl": "https://api.example.com/health", "severity": "critical", "timestamp": "2025-01-15T10:30:00.000Z" } ``` * インシデント復旧 ```json { "event": "incident.resolved", "monitorName": "API Server", "monitorId": "01JWAB1234567890ABCDEF", "teamId": "01JWAB0987654321FEDCBA", "incidentId": "01JWABINCIDENT12345678", "timestamp": "2025-01-15T10:45:00.000Z" } ``` ## 署名検証 [Section titled “署名検証”](#署名検証) 通知リクエストには `X-Manako-Signature` ヘッダーが付与されます。リクエストボディの HMAC-SHA256 署名をシークレットで検証することで、リクエストが Manako から送信されたものであることを確認できます。 署名のフォーマットは `sha256=\{hex_digest\}` です。 ### 検証コード例 [Section titled “検証コード例”](#検証コード例) * Node.js ```javascript import crypto from "node:crypto"; function verifySignature(body, secret, signature) { const expected = "sha256=" + crypto.createHmac("sha256", secret).update(body).digest("hex"); return crypto.timingSafeEqual( Buffer.from(expected), Buffer.from(signature), ); } // Express の例 app.post("/webhook", express.text({ type: "application/json" }), (req, res) => { const signature = req.headers["x-manako-signature"]; if (!verifySignature(req.body, process.env.WEBHOOK_SECRET, signature)) { return res.status(401).send("Invalid signature"); } const payload = JSON.parse(req.body); console.log(`Event: ${payload.event}, Monitor: ${payload.monitorName}`); res.status(200).send("OK"); }); ``` * Python ```python import hashlib import hmac import os def verify_signature(body: bytes, secret: str, signature: str) -> bool: expected = "sha256=" + hmac.new( secret.encode(), body, hashlib.sha256 ).hexdigest() return hmac.compare_digest(expected, signature) # Flask の例 @app.route("/webhook", methods=["POST"]) def webhook(): signature = request.headers.get("X-Manako-Signature", "") if not verify_signature( request.get_data(), os.environ["WEBHOOK_SECRET"], signature ): return "Invalid signature", 401 payload = request.get_json() print(f"Event: {payload['event']}, Monitor: {payload['monitorName']}") return "OK", 200 ``` 注意 署名検証には必ずタイミングセーフな比較関数(`crypto.timingSafeEqual` や `hmac.compare_digest`)を使用してください。通常の文字列比較(`===` や `==`)はタイミング攻撃に対して脆弱です。 ## トラブルシューティング [Section titled “トラブルシューティング”](#トラブルシューティング) * **設定時に URL エラーになる**: HTTPS で公開され、DNS 解決後もプライベート/予約済みアドレスに到達しない URL が必要です。 * **受信側がリダイレクトする**: Manako は `redirect: "manual"` で送信するため、最終受信 URL を直接設定してください。 * **署名が一致しない**: JSON を再シリアライズせず、受信した raw body に対して `sha256={hex}` を計算します。Manako に保存した Secret と同じ値を使ってください。 * **テストは届くが通常通知が届かない**: テストの `event` は `test` です。通常通知ではモニター個別の通知先関連付けも確認してください。関連付けがすべて無効でもチーム全体へはフォールバックしません。 * **短時間の通知が途中から届かない**: 同じモニターで 10 分以内に 3 回を超える状態変化があるとフラップ抑制が働きます。 * **重複して見える**: 同じインシデント・チャンネル・イベント種別の送信済み再試行はスキップされ、DB の UNIQUE 制約も重複記録を防ぎます。失敗または処理中の記録は再試行されます。 「Test」は実際に `event: "test"` の署名付きリクエストを送り、成功後は 60 秒のクールダウンがあります。1つの Webhook の失敗は他チャンネルの送信を止めません。 フラップ抑制とインシデント単位の送信済み判定はインシデント通知に適用されます。メンテナンス通知はこれらを使わず、有効かつ確認済みのチームチャンネルへ送信されます。 # ステータスページ > 公開ステータスページの作成と管理 サービスの稼働状況をユーザーに公開するステータスページを作成できます。 ## ステータスページの作成 [Section titled “ステータスページの作成”](#ステータスページの作成) ダッシュボードの「ステータスページ」メニューから新しいページを作成します。 ### 基本設定 [Section titled “基本設定”](#基本設定) | 項目 | 説明 | | ---- | ------------------------------------- | | ページ名 | ステータスページのタイトル | | スラッグ | URL パス(例: `my-service`)。小文字英数字とハイフンのみ | | 説明 | サービスの概要説明 | | 公開設定 | 公開 / 非公開の切り替え | ### モニターの紐づけ [Section titled “モニターの紐づけ”](#モニターの紐づけ) ステータスページに表示するモニターを選択します。複数のモニターをグループ化して表示できます。 ## 公開 URL [Section titled “公開 URL”](#公開-url) ステータスページは以下の URL で公開されます: ```plaintext https://status.manako.dev/{slug} ``` ## 表示内容 [Section titled “表示内容”](#表示内容) ステータスページには以下の情報が表示されます: * 各モニターの現在のステータス(稼働中 / 障害中 / 劣化 / 不明) * 「劣化」: 現行の HTTP / TCP / Ping 監視は up / down のみを返すため、この状態は発生しません * **アップタイム履歴バー**(過去 90 日間の日別稼働状況) * アクティブなインシデント(そのステータスページに紐付けられた進行中・確認済みのインシデントのみ表示) * **自動インシデント**: モニターがステータスページに登録されている場合、そのモニターで検知されたインシデントが自動的に表示されます * **手動インシデント**: 作成時に表示先のステータスページを選択します(1つ以上必須) ### アップタイム履歴バー [Section titled “アップタイム履歴バー”](#アップタイム履歴バー) 各モニターの下に、過去 90 日間の稼働状況がカラーバーで表示されます。 | 色 | 意味 | | --- | ------------------- | | 緑 | 100% 稼働 | | 薄緑 | 99% 以上稼働(軽微な問題あり) | | 黄 | 95% 以上稼働(パフォーマンス劣化) | | 赤 | 95% 未満(重大な障害) | | グレー | データなし | バーの右端に 90 日間の総合アップタイム率(%)が表示されます。 ノート アップタイム履歴データは日次で集計されます。新規作成直後のモニターはデータが蓄積されるまでグレーバーが表示されます。 ## ステータスバッジ [Section titled “ステータスバッジ”](#ステータスバッジ) README や外部サイトに埋め込める SVG ステータスバッジを提供しています。認証不要で、60 秒間キャッシュされます。 ### ページ全体のバッジ [Section titled “ページ全体のバッジ”](#ページ全体のバッジ) ステータスページに紐づく全モニターの集約ステータスを表示します。 ```plaintext https://status.manako.dev/{slug}/badge.svg ``` 表示されるステータス: | ステータス | 条件 | | -------------- | ------------------------------------------------------------------------ | | operational | 全モニターが稼働中 | | partial outage | 一部のモニターが障害中 | | degraded | 一部のモニターが劣化(障害なし)。現行の HTTP / TCP / Ping 監視は up / down のみを返すため、この状態は発生しません | | unknown | モニター未登録またはステータス不明 | ### 個別モニターのバッジ [Section titled “個別モニターのバッジ”](#個別モニターのバッジ) 特定のモニターのステータスを表示します。ラベルにはモニター名が使用されます。 ```plaintext https://status.manako.dev/{slug}/monitors/{monitorId}/badge.svg ``` ### クエリパラメータ [Section titled “クエリパラメータ”](#クエリパラメータ) バッジの見た目をカスタマイズできます。 | パラメータ | 説明 | デフォルト | | ------------ | ------------------------ | ------------ | | `label` | 左側のラベルテキスト | ページ名またはモニター名 | | `style` | `flat` または `flat-square` | `flat` | | `color` | 右側の背景色(hex、`#` なし) | ステータスに応じた色 | | `labelColor` | 左側の背景色(hex、`#` なし) | `555` | 例: ```plaintext https://status.manako.dev/my-service/badge.svg?label=My+Service&style=flat-square ``` ### 埋め込み例 [Section titled “埋め込み例”](#埋め込み例) **Markdown**: ```markdown  ``` **HTML**: ```html ``` # Cookie ポリシー > Manako がサイトで使用する Cookie と類似技術、および同意管理の方法について説明します。 最終更新日: 2026-07-13 ## 1. Cookie とは [Section titled “1. Cookie とは”](#1-cookie-とは) Cookie は、Web サイトがあなたのブラウザに保存する小さなテキストデータです。Manako では、サービスの提供および改善のために Cookie および類似技術(localStorage など)を使用しています。 ## 2. 使用している Cookie [Section titled “2. 使用している Cookie”](#2-使用している-cookie) Manako では、以下の 2 カテゴリの Cookie / ブラウザストレージを使用します。 ### 2.1 必須 Cookie (常に有効) [Section titled “2.1 必須 Cookie (常に有効)”](#21-必須-cookie-常に有効) サイトの基本機能に必要な Cookie です。無効にするとサービスを正常に利用できません。 | 名前 | 目的 | 有効期限 | 属性 | | ------------------------------- | ---------------------------------- | ------ | ------------------------------ | | `mk_at` | 認証済みセッションの維持(アクセストークン) | 15 分 | HttpOnly, Secure, SameSite=Lax | | `mk_rt` | アクセストークンの自動更新(リフレッシュトークン) | 7 日 | HttpOnly, Secure, SameSite=Lax | | `mk_sudo` | 機密操作(API キー管理・MFA 解除等)実行前の再認証状態の保持 | 15 分 | HttpOnly, Secure, SameSite=Lax | | `manako-ui-lang` (localStorage) | 言語設定の保持 | 無期限 | - | | `manako-theme` (localStorage) | ダーク/ライトテーマの保持 | 無期限 | - | | Cloudflare Turnstile トークン | ボット対策(セキュリティ) | セッション中 | - | `mk_at` / `mk_rt` / `mk_sudo` は Domain 属性を指定しない host-only Cookie で、`api.manako.dev` からのみ送信されます。HttpOnly 属性により JavaScript から読み取ることはできず、ダッシュボード(SPA)は認証情報を localStorage 等には保存しません。 ### 2.2 分析 Cookie (ユーザー選択) [Section titled “2.2 分析 Cookie (ユーザー選択)”](#22-分析-cookie-ユーザー選択) アクセス解析のために使用します。ユーザー同意を得てから有効化されます。 | 名前 | 目的 | 送信先 | 有効期限 | | -------------- | ---------------------------- | ----------- | --------- | | `_ga`, `_ga_*` | Google Analytics 4 によるアクセス解析 | Google (米国) | 2 年 | | GTM 関連 Cookie | Google Tag Manager コンテナ管理 | Google (米国) | セッション〜2 年 | ## 3. 同意管理 [Section titled “3. 同意管理”](#3-同意管理) 初回アクセス時に Cookie 同意バナーを表示します。以下の選択肢があります。 * **同意する**: 分析 Cookie を含むすべての Cookie を有効化 * **拒否する**: 必須 Cookie のみ使用(GA4 は発火しません) * **設定**: カテゴリごとに個別選択 同意内容は 180 日間記憶されます。期限経過後、再度バナーを表示します。 ## 4. 同意の撤回 [Section titled “4. 同意の撤回”](#4-同意の撤回) いつでも以下の方法で同意を撤回できます。 * ブラウザの localStorage から `manako-cookie-consent` キーを削除し、ページを再読み込み ## 5. 第三者への送信 [Section titled “5. 第三者への送信”](#5-第三者への送信) 分析 Cookie に同意した場合、以下の情報が Google LLC に送信される可能性があります。 * アクセス URL、リファラー、ブラウザ情報、画面解像度 * 匿名化された IP アドレス * Manako 上でのクリックイベント(`signup_complete` 等) 詳細は [Google のプライバシーポリシー](https://policies.google.com/privacy) をご覧ください。 ## 6. GDPR / 改正電気通信事業法への対応 [Section titled “6. GDPR / 改正電気通信事業法への対応”](#6-gdpr--改正電気通信事業法への対応) * **GDPR (EU/EEA)**: 分析 Cookie は明示的同意前に発火しません (GTM Consent Mode v2) * **改正電気通信事業法 (日本)**: 外部送信規律に基づき、送信先と目的を本ページで通知しています ## 7. お問い合わせ [Section titled “7. お問い合わせ”](#7-お問い合わせ) Cookie および個人情報の取り扱いについてのお問い合わせは、[プライバシーポリシー](/legal/privacy/) に記載の窓口までご連絡ください。 # データ処理契約 (DPA) > Manako のデータ処理に関する契約条件 最終更新日: 2026年3月31日 本データ処理契約(以下「本 DPA」)は、Manako(以下「データ処理者」)のサービス利用に関して、お客様(以下「データ管理者」)との間のデータ処理に関する条件を定めるものです。本 DPA は[利用規約](/legal/terms/)の付属文書として、サービスの利用開始をもって自動的に適用されます。 個別の DPA 署名が必要な場合は、 までお問い合わせください。 ## 1. 定義 [Section titled “1. 定義”](#1-定義) * **データ管理者(Controller)**: 本サービスを利用するお客様。個人データの処理目的および手段を決定する主体 * **データ処理者(Processor)**: Manako 運営者。データ管理者に代わって個人データを処理する主体 * **個人データ(Personal Data)**: GDPR 第4条に定義される、識別された又は識別可能な自然人に関するあらゆる情報 * **処理(Processing)**: GDPR 第4条に定義される、個人データに対して行われるあらゆる操作 * **サブプロセッサー(Sub-processor)**: データ処理者が処理の一部を委託する第三者 ## 2. 処理の範囲と目的 [Section titled “2. 処理の範囲と目的”](#2-処理の範囲と目的) ### 処理するデータの種類 [Section titled “処理するデータの種類”](#処理するデータの種類) | データ種類 | 処理目的 | | -------- | ---------------------------------- | | メールアドレス | アカウント認証、通知送信 | | ユーザー名 | サービス内の表示名 | | チーム名 | テナント識別 | | 監視対象 URL | 監視サービスの提供 | | IP アドレス | セキュリティログ、レート制限 | | パスワード | 認証(PBKDF2-SHA-512 でハッシュ化。平文は保持しない) | ### 処理目的 [Section titled “処理目的”](#処理目的) * **サービス提供**: 監視、通知、ステータスページの運用 * **アカウント管理**: 認証、認可、チーム管理 * **セキュリティ**: 監査ログ、不正アクセス防止、レート制限 ## 3. データ処理者の義務 [Section titled “3. データ処理者の義務”](#3-データ処理者の義務) データ処理者は以下の義務を負います: 1. データ管理者の文書による指示に基づいてのみ個人データを処理します 2. 処理に従事するすべての者に秘密保持義務を課します 3. GDPR 第32条に基づく適切なセキュリティ対策を実施します 4. サブプロセッサーの利用に関して事前に通知します 5. データ管理者がデータ主体の権利行使に対応するために必要な協力を行います 6. データ保護影響評価(DPIA、第35-36条)および監督当局への事前協議が必要な場合に協力します 7. 契約終了時にデータの返却または削除を行います ## 4. セキュリティ対策 [Section titled “4. セキュリティ対策”](#4-セキュリティ対策) データ処理者は以下のセキュリティ対策を実施しています。詳細は[セキュリティページ](/legal/security/)をご参照ください。 | 対策 | 内容 | | ------- | -------------------------------------------- | | 保存時暗号化 | AES-256-GCM(D1, R2, KV すべて自動暗号化) | | 通信時暗号化 | TLS 1.3(全通信) | | パスワード保護 | PBKDF2-SHA-512 + ランダムソルト(100,000 回イテレーション) | | テナント分離 | すべてのデータベースクエリに team\_id による分離を強制 | | アクセス制御 | ロールベース(owner / member / viewer) | | レート制限 | 認証 10req/min、ダッシュボード 60req/min、API 60req/min | | インフラ認証 | SOC 2 Type II、ISO 27001、ISO 27701、PCI DSS | ## 5. サブプロセッサー [Section titled “5. サブプロセッサー”](#5-サブプロセッサー) データ処理者は以下のサブプロセッサーを利用しています: | サブプロセッサー | 処理内容 | データ所在地 | 目的 | | ---------------- | --------------------------- | -------------- | ---------------------- | | Cloudflare, Inc. | インフラ基盤(Workers, D1, KV, R2) | グローバルエッジネットワーク | サービスホスティング、データ保存 | | Resend, Inc. | メール送信 API | US | トランザクショナルメール(通知、メール検証) | | Stripe, Inc. | 決済処理 | US / EU | サブスクリプション管理、請求処理 | サブプロセッサーの追加または変更を行う場合、本ページにて事前に更新します。重要な変更についてはメールでも通知します。 ## 6. データ保持と削除 [Section titled “6. データ保持と削除”](#6-データ保持と削除) | データ種類 | 保持期間 | | ------------------------------ | ---------------------------------------------- | | 監視結果(Free プラン) | 7日間(自動削除) | | 監視結果(Pro プラン) | 90日間(自動削除) | | 監視パフォーマンスデータ(Analytics Engine) | 最大90日間(Cloudflare により自動削除。削除 API 非提供のため即時削除不可) | | アカウントデータ | アカウント存続中 | | アカウント削除後 | 30日以内に完全削除(※ Analytics Engine データを除く。下記参照) | | 監査ログ(Free プラン) | 保持期間の上限なし(画面・API からは参照不可) | | 監査ログ(Pro プラン) | 90日間 | Free プランの監査ログは、画面・API から参照できません。ログ自体は記録され、Pro プランへの変更時点から表示可能期間内の過去分を遡って参照できるよう、保持期間の上限を設けず保持されます。アカウントの完全削除時には、他の個人情報と同じ削除手順の対象になります。 ### Analytics Engine データに関する技術的制約 [Section titled “Analytics Engine データに関する技術的制約”](#analytics-engine-データに関する技術的制約) Cloudflare Analytics Engine は削除 API を提供していないため、アカウント削除時に当該データの即時削除はできません。ただし、以下の保護措置を講じています: * **自動期限切れ**: Analytics Engine のデータは Cloudflare の仕様により最大 90 日間で自動的に削除されます * **アクセス分離**: アカウント削除後、チーム ID によるアクセス分離により、当該データへの API アクセスは一切できません * **データの性質**: Analytics Engine に保存されるデータは監視パフォーマンスデータ(応答時間、ステータスコード等)であり、直接的な個人識別情報は含みません データの削除方法については[プライバシーポリシー](/legal/privacy/)をご参照ください。 ## 7. データ主体の権利 [Section titled “7. データ主体の権利”](#7-データ主体の権利) データ処理者は、データ管理者がデータ主体の以下の権利に対応するために必要な技術的手段を提供します: * **アクセス権(第15条)**: データエクスポート機能(JSON形式) * **訂正権(第16条)**: 設定画面からの情報編集 * **削除権(第17条)**: アカウント削除機能(30日間の猶予期間付き) * **データポータビリティ権(第20条)**: JSON形式でのデータエクスポート * **処理の制限権(第18条)**: サポートへのお問い合わせにて対応 ## 8. データ侵害通知 [Section titled “8. データ侵害通知”](#8-データ侵害通知) 1. データ処理者は、個人データの侵害を認識した場合、不当な遅延なく、原則として **72時間以内** にデータ管理者に通知します 2. 通知には以下を含みます: * 侵害の性質と影響を受けるデータ主体の概数 * 侵害の結果として生じうる影響 * 侵害に対処するために講じた、または講じる予定の措置 3. データ管理者が監督当局への報告義務(第33条)およびデータ主体への通知義務(第34条)を果たすために必要な協力を行います ## 9. 国際データ移転 [Section titled “9. 国際データ移転”](#9-国際データ移転) * Cloudflare のグローバルエッジネットワークでデータを処理するため、EU/EEA 域外へのデータ移転が発生する場合があります * EU Standard Contractual Clauses(SCCs)に基づく適切な保護措置を講じています * 各サブプロセッサーは独自の DPA および SCCs を提供しており、適切なデータ保護レベルを確保しています ## 10. 契約終了時の措置 [Section titled “10. 契約終了時の措置”](#10-契約終了時の措置) 契約終了時(アカウント削除時)、データ処理者は以下を行います: 1. **データの返却**: データエクスポート機能(JSON形式)によりデータ管理者がデータを取得可能 2. **データの削除**: アカウント削除リクエストから30日以内にすべての個人データを完全削除。ただし、Cloudflare Analytics Engine に保存された監視パフォーマンスデータは、技術的制約(削除 API 非提供)により即時削除できず、最大 90 日間で自動期限切れにより削除されます 3. **削除の証明**: 削除完了の確認が必要な場合は、 までお問い合わせください ## 11. 監査権 [Section titled “11. 監査権”](#11-監査権) 1. データ管理者(またはデータ管理者が委任した第三者監査人)は、本 DPA の遵守状況を監査する権利を有します 2. 監査の方法: * **リモートアンケート**: 年1回まで、書面による質問への回答 * **第三者認証レポート**: SOC 2 Type II 等の第三者認証レポートの提供をもって監査に代えることができます(認証取得時) 3. 監査に係る費用はデータ管理者の負担とします 4. データ処理者は、データ保護影響評価(DPIA、第35条)が必要な場合、データ管理者に合理的な範囲で協力します ## 12. 準拠法・管轄 [Section titled “12. 準拠法・管轄”](#12-準拠法管轄) 本 DPA は、[利用規約](/legal/terms/)に定める準拠法および管轄に従います。 # プライバシーポリシー > Manako におけるお客様の個人情報の取り扱いについて 最終更新日: 2026年4月10日 Manako(以下「本サービス」)は、お客様のプライバシーを尊重し、個人情報の保護に努めます。本ポリシーでは、本サービスにおける個人情報の取り扱いについて説明します。 ## 1. 収集する情報 [Section titled “1. 収集する情報”](#1-収集する情報) ### アカウント情報 [Section titled “アカウント情報”](#アカウント情報) * メールアドレス * パスワード(PBKDF2-SHA-512 でハッシュ化して保存。平文では保持しません) * チーム名・組織名 ### サービス利用情報 [Section titled “サービス利用情報”](#サービス利用情報) * 監視対象として登録された URL・ホスト名 * 監視設定(チェック間隔、通知先等) * 監視結果(応答時間、ステータスコード、エラー情報) * 通知設定(Slack Webhook URL、メールアドレス、Webhook URL) * インシデント履歴 * ステータスページの設定と公開情報 ### 技術情報 [Section titled “技術情報”](#技術情報) * IP アドレス(アクセスログ) * ブラウザ情報(User-Agent) * API 利用ログ(タイムスタンプ、リクエストパス) ### 決済情報 [Section titled “決済情報”](#決済情報) クレジットカード情報は Stripe, Inc. が直接処理し、本サービスのサーバーには保存されません。 ## 2. 利用目的 [Section titled “2. 利用目的”](#2-利用目的) 収集した情報は、以下の目的で利用します。 * サービスの提供・運営・改善 * 監視結果の記録と通知の送信(Email、Slack、Webhook) * アカウント認証とセキュリティの確保 * お問い合わせへの対応 * サービスに関する重要な通知の送信 * 利用料金の請求と決済処理 * 利用状況の分析・統計(個人を特定しない形で) * 不正利用の検知と防止 ## 3. 第三者提供 [Section titled “3. 第三者提供”](#3-第三者提供) 以下のサービスに対して、サービス提供に必要な範囲で情報を提供します。それ以外の第三者への提供は、お客様の同意がある場合または法令に基づく場合を除き行いません。 | サービス | 目的 | 提供される情報 | | ---------------- | -------- | ------------ | | Cloudflare, Inc. | インフラ・CDN | 全サービスデータ | | Resend, Inc. | メール送信 | 送信先メールアドレス | | Stripe, Inc. | 決済処理 | メールアドレス、決済情報 | ## 4. データの保存 [Section titled “4. データの保存”](#4-データの保存) ### 保存場所 [Section titled “保存場所”](#保存場所) お客様のデータは、Cloudflare, Inc. のグローバルインフラストラクチャ上で保管・処理されます。Cloudflare は SOC 2 Type II / ISO 27001 認証済みです。 ### 暗号化 [Section titled “暗号化”](#暗号化) * **保存時(At Rest)**: AES-256-GCM 暗号化(D1, R2, KV すべて自動暗号化) * **通信時(In Transit)**: TLS 1.3 * **パスワード**: PBKDF2-SHA-512 + ランダムソルト(100,000 回イテレーション) ## 5. データの保持期間 [Section titled “5. データの保持期間”](#5-データの保持期間) | データ | 保持期間 | | ------------------------------ | ---------------------------- | | アカウント情報 | アカウント削除まで | | 監視結果データ(Free プラン) | 7 日間 | | 監視結果データ(Pro プラン) | 90 日間 | | 監視パフォーマンスデータ(Analytics Engine) | 最大 90 日間(Cloudflare により自動削除) | | 監査ログ(Free プラン) | 保持期間の上限なし(画面・API からは参照不可) | | 監査ログ(Pro プラン) | 90 日間 | | アクセスログ | 最大 90 日間 | Free プランの監査ログは、画面・API から参照できません。ログ自体は記録され、Pro プランへの変更時点から表示可能期間内の過去分を遡って参照できるよう、保持期間の上限を設けず保持されます。アカウントの完全削除時には、他の個人情報と同じ削除手順の対象になります。 アカウント削除後、個人情報は 30 日以内に完全に削除されます。ただし、Cloudflare Analytics Engine に保存された監視パフォーマンスデータ(応答時間、ステータスコード等)は、Cloudflare 側の技術的制約により即時削除ができないため、最大 90 日間保持された後に自動的に削除されます。なお、アカウント削除後はチーム ID によるアクセス分離により、当該データへの API アクセスは一切できません。法令で保持が義務付けられているデータはこの限りではありません。 ## 6. Cookie・類似技術 [Section titled “6. Cookie・類似技術”](#6-cookie類似技術) 本サービスでは以下の技術を使用します。 * **セッション管理**: HttpOnly Cookie(`mk_at` / `mk_rt` / `mk_sudo`)と、リフレッシュトークンを保存する KV * **localStorage**: 言語・テーマ・Cookie 同意設定(`manako-cookie-consent`)。認証情報は保存しません 分析目的で Google Analytics 4 (GA4) を Google Tag Manager 経由で使用しています。分析 Cookie はユーザー同意後のみ有効化されます (GTM Consent Mode v2)。詳細は [Cookie ポリシー](/legal/cookies/) をご覧ください。 ## 7. お客様の権利 [Section titled “7. お客様の権利”](#7-お客様の権利) お客様は以下の権利を有します。 * **アクセス権**: ご自身の個人情報へのアクセス * **訂正権**: 不正確な情報の訂正 * **削除権**: アカウントおよび関連データの削除 * **データポータビリティ**: データのエクスポート(API 経由) * **マーケティング拒否**: マーケティング目的での利用を拒否する権利 権利の行使は、アカウント設定画面または へのご連絡にて承ります。 ## 8. 子供のプライバシー [Section titled “8. 子供のプライバシー”](#8-子供のプライバシー) 本サービスは 16 歳未満の方を対象としていません。16 歳未満の方の個人情報を意図的に収集することはありません。 ## 9. 個人情報保護法への対応 [Section titled “9. 個人情報保護法への対応”](#9-個人情報保護法への対応) 本サービスは、日本の個人情報の保護に関する法律(2022 年改正)に準拠して運営されます。 ## 10. ポリシーの変更 [Section titled “10. ポリシーの変更”](#10-ポリシーの変更) 本ポリシーは、法令の改正やサービスの変更に伴い更新されることがあります。重要な変更がある場合は、登録されたメールアドレスにて通知します。 ## 11. お問い合わせ [Section titled “11. お問い合わせ”](#11-お問い合わせ) プライバシーに関するお問い合わせは下記までご連絡ください。 * **メール**: # セキュリティ > Manako のセキュリティへの取り組み 最終更新日: 2026年7月13日 Manako は、お客様のデータの安全性を最優先に考えています。 ## インフラストラクチャ [Section titled “インフラストラクチャ”](#インフラストラクチャ) Manako は Cloudflare のグローバルインフラストラクチャ上で稼働しています。サーバーレス(Cloudflare Workers)で稼働するため、OS やミドルウェアの管理が不要で攻撃面を最小化しています。 | 認証 | 対象 | | ------------- | -------------------------- | | SOC 2 Type II | Workers, D1, KV, R2, Pages | | ISO 27001 | 情報セキュリティマネジメント | | ISO 27701 | GDPR 準拠プライバシー管理 | | PCI DSS | Workers, KV | ## データ保護 [Section titled “データ保護”](#データ保護) ### 暗号化 [Section titled “暗号化”](#暗号化) | 対象 | 方式 | | --------------- | ----------------------------------------------------------------------- | | 保存時(At Rest) | AES-256-GCM(D1, R2, KV すべて自動暗号化) | | 通信時(In Transit) | TLS 1.3(全 Worker 間通信含む) | | パスワード | PBKDF2-SHA-512 + ランダムソルト 16 バイト(100,000 回イテレーション、鍵長 256 ビット、タイミングセーフ比較) | ### 認証・セッション管理 [Section titled “認証・セッション管理”](#認証セッション管理) * **JWT(HS256)**: アクセストークン有効期限 15 分、リフレッシュトークン 7 日間 * **httpOnly Cookie 認証**: アクセストークン・リフレッシュトークンは httpOnly Cookie(`Secure`, `SameSite=Lax`)としてブラウザに渡され、JavaScript からは読み取れません。ダッシュボード(SPA)は認証トークンを localStorage 等の JavaScript から読み取り可能な領域には保存しません * **リフレッシュトークンローテーション**: 使用時に旧トークンを即時無効化し、新トークンを発行 * **リフレッシュトークン保存**: Cookie の値そのものは Cloudflare KV に TTL 付きで保存・管理し、有効期限後に自動削除 * **CSRF 対策**: Cookie 経由の認証リクエストは Origin ヘッダーを検証し、許可されたオリジン以外からの状態変更リクエストを拒否(`SameSite=Lax` によるクロスサイト送信制限と併用) * **API Key**: `mk_` プレフィックス + 64 文字 HEX。SHA-256 ハッシュで保存。プレフィックス 11 文字のみ DB に記録 ### テナント分離 [Section titled “テナント分離”](#テナント分離) * すべてのデータベースクエリに `team_id` スコープを強制適用 * API Key はチーム単位で発行・管理 * 異なるチームのデータへのアクセスは不可能 ## アプリケーションセキュリティ [Section titled “アプリケーションセキュリティ”](#アプリケーションセキュリティ) ### 入力検証 [Section titled “入力検証”](#入力検証) * 全 API エンドポイントで Zod スキーマバリデーション * SSRF 防止: プライベート IP(`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`)、localhost、クラウドメタデータエンドポイント(`169.254.169.254`, `metadata.google.internal`)をブロック * HTTP ヘッダーインジェクション防止 * XSS エスケーピング(ステータスページ SSR) ### ブラウザ側の防御(セキュリティヘッダー) [Section titled “ブラウザ側の防御(セキュリティヘッダー)”](#ブラウザ側の防御セキュリティヘッダー) ダッシュボードと管理画面には以下のヘッダーを適用しています。 | ヘッダー | 値 | | --------------------------------- | --------------------------------------------------------------------------------------- | | Content-Security-Policy | `script-src` に `'unsafe-inline'` / `'unsafe-eval'` を含めない。インラインスクリプトは SHA-256 ハッシュで個別に許可 | | X-Frame-Options / frame-ancestors | クリックジャッキング防止(埋め込み全面禁止) | | X-Content-Type-Options | `nosniff` | | Referrer-Policy | `strict-origin-when-cross-origin` | | Strict-Transport-Security | `max-age=63072000; includeSubDomains; preload` | CSP は `object-src 'none'` / `base-uri 'self'` / `form-action 'self'` も指定し、万一 XSS が成立した場合の悪用経路を制限します。 ### レート制限 [Section titled “レート制限”](#レート制限) | エンドポイント | リクエスト数 | ウィンドウ | キー | | ------------------------------------ | ----------------------- | ----- | ---------- | | 認証(`/auth/*`) | 30 回 | 60 秒 | IP アドレス | | ダッシュボード(`/dashboard/*`) | 600 回 | 60 秒 | ユーザー ID | | Public API(`/api/v1/*`) — IP 単位 | 300 回 | 60 秒 | IP アドレス | | Public API(`/api/v1/*`) — API Key 単位 | プラン別(Free 60 / Pro 180) | 60 秒 | API Key ID | ### Webhook セキュリティ [Section titled “Webhook セキュリティ”](#webhook-セキュリティ) * HMAC-SHA256 によるペイロード署名検証 * プライベート IP・localhost へのWebhook送信を禁止(SSRF 防止) ### 通知のフラップガード [Section titled “通知のフラップガード”](#通知のフラップガード) 短時間で頻繁なステータス変化(フラッピング)が発生した場合、通知を自動的に抑制します。 * **閾値**: 10 分以内に 3 回以上のステータス変化で通知を抑制 * **インシデント判定**: 5 回連続のダウンで初めてインシデントを作成 ## 監視対象のセキュリティ [Section titled “監視対象のセキュリティ”](#監視対象のセキュリティ) * HTTP 監視時のリダイレクトは追従しません(SSRF 防止) * HTTP 監視リクエストには識別可能な User-Agent(`Manako/1.0 (Uptime Monitor; +https://manako.dev)`)を付与 * お客様が権限を持つサービスのみの監視を[利用規約](/legal/terms/)で義務付け ## セキュリティプラクティス [Section titled “セキュリティプラクティス”](#セキュリティプラクティス) * 定期的なコードレビュー * 依存パッケージの定期更新 * 最小権限の原則に基づくアクセス制御 ## インシデント対応 [Section titled “インシデント対応”](#インシデント対応) セキュリティインシデントが発生した場合: 1. 影響範囲の特定と封じ込めを迅速に実施します 2. 影響を受けたお客様には 72 時間以内に通知します 3. インシデントの詳細と対策を公開します ## 脆弱性の報告 [Section titled “脆弱性の報告”](#脆弱性の報告) セキュリティに関する問題を発見された場合は、下記までご連絡ください。責任ある開示を行っていただいた方には、感謝の意を表します。 * **メール**: # 利用規約 > Manako のサービス利用条件 最終更新日: 2026年3月25日 本利用規約(以下「本規約」)は、Manako(以下「本サービス」)の利用に関する条件を定めるものです。本サービスを利用することにより、本規約に同意したものとみなされます。 ## 第1条(定義) [Section titled “第1条(定義)”](#第1条定義) * 「ユーザー」: 本サービスに登録した個人または法人 * 「チーム」: ユーザーが属する組織単位 * 「モニター」: 監視対象として登録された URL、ホスト名等 ## 第2条(サービス内容) [Section titled “第2条(サービス内容)”](#第2条サービス内容) 本サービスは以下の機能を提供します。 * HTTP/HTTPS 死活監視 * TCP / Ping 到達性監視 * インシデント検知・通知(Email、Slack、Webhook) * 公開ステータスページ * REST API / MCP Server / CLI ## 第3条(アカウント) [Section titled “第3条(アカウント)”](#第3条アカウント) 1. アカウント登録には有効なメールアドレスが必要です 2. パスワードの管理はユーザーの責任とします 3. 1 人のユーザーが複数の無料アカウントを作成することは禁止されています 4. アカウントの不正利用を発見した場合、速やかに当社に通知してください ## 第4条(料金・プラン) [Section titled “第4条(料金・プラン)”](#第4条料金プラン) 1. Free プラン: 無料(モニター最大 5 件、チェック間隔 5 分以上) 2. 有料プラン: サービスサイトの料金ページに掲載された価格に基づきます 3. 決済は Stripe を通じて処理されます。クレジットカード情報は本サービスのサーバーには保存されません 4. 有料プランは月額課金または年額課金です。課金日は契約開始日を基準とします 5. プランのダウングレードまたは解約は、次回課金日の前日まで行えます 6. 返金は、法令に定められた場合を除き、原則として行いません ## 第5条(禁止事項) [Section titled “第5条(禁止事項)”](#第5条禁止事項) 以下の行為を禁止します。 1. 本サービスを利用した第三者のネットワークへの不正アクセス 2. 内部ネットワークやプライベート IP アドレスへの SSRF(Server-Side Request Forgery)の試行 3. 他のユーザーのデータへの不正アクセス 4. サービスの過負荷を意図的に引き起こす行為、API レート制限の意図的な回避 5. 自身の権限のないシステムやサービスの監視 6. 本サービスを利用した違法行為 7. 自動化されたスクレイピング(API 利用は除く) 8. API Key の第三者への譲渡・販売 9. 本サービスのリバースエンジニアリング、逆コンパイル、逆アセンブル ## 第6条(知的財産権) [Section titled “第6条(知的財産権)”](#第6条知的財産権) 本サービスに関するすべての知的財産権(ソフトウェア、デザイン、ロゴ、ドキュメント等)は当社に帰属します。ユーザーが本サービスに登録したデータの権利はユーザーに帰属します。 ## 第7条(サービスの停止・中断) [Section titled “第7条(サービスの停止・中断)”](#第7条サービスの停止中断) 1. 当社は、以下の場合にサービスを一時停止することがあります: * システムの保守・更新 * 天災・停電等の不可抗力 * Cloudflare のインフラ障害 2. 計画的なメンテナンスは事前に通知します ## 第8条(免責事項) [Section titled “第8条(免責事項)”](#第8条免責事項) 1. 本サービスは「現状有姿」で提供されます 2. 当社は、監視の正確性・完全性を保証するものではありません 3. 通知の遅延・未達について、当社は責任を負いません 4. 本サービスの利用により生じた損害(監視漏れ、通知の遅延、データの消失等)について、法令で許容される最大限の範囲で責任を負いません ## 第9条(責任の制限) [Section titled “第9条(責任の制限)”](#第9条責任の制限) 当社の故意または重過失による場合を除き、賠償責任は直接損害に限り、ユーザーが過去 12 ヶ月間に本サービスに支払った利用料金の総額を上限とします。 ## 第10条(データの取り扱い) [Section titled “第10条(データの取り扱い)”](#第10条データの取り扱い) 1. ユーザーのデータは[プライバシーポリシー](/legal/privacy/)に従い取り扱います 2. アカウント削除時、関連するデータは 30 日以内に削除されます 3. 法令に基づく保存義務がある場合はこの限りではありません ## 第11条(解約) [Section titled “第11条(解約)”](#第11条解約) 1. ユーザーは、いつでもアカウントを削除し、サービスの利用を終了できます 2. 本規約に違反した場合、当社は事前の通知なくアカウントを停止または削除できます ## 第12条(反社会的勢力の排除) [Section titled “第12条(反社会的勢力の排除)”](#第12条反社会的勢力の排除) ユーザーは、反社会的勢力に該当しないことを表明し、保証します。 ## 第13条(規約の変更) [Section titled “第13条(規約の変更)”](#第13条規約の変更) 1. 当社は、本規約を変更することがあります 2. 重要な変更は 30 日前までに通知します 3. 変更後も利用を継続した場合、変更に同意したものとみなします ## 第14条(準拠法・管轄) [Section titled “第14条(準拠法・管轄)”](#第14条準拠法管轄) 1. 本規約の準拠法は日本法とします 2. 紛争が生じた場合、東京地方裁判所を第一審の専属的合意管轄裁判所とします ## 特定商取引法に基づく表記 [Section titled “特定商取引法に基づく表記”](#特定商取引法に基づく表記) | 項目 | 内容 | | -------- | ------------------------------------ | | 販売事業者 | Manako | | 運営責任者 | お問い合わせ時に開示 | | 所在地 | お問い合わせ時に開示 | | 連絡先 | | | 販売価格 | サービスサイトの料金ページに記載 | | 支払方法 | クレジットカード(Stripe 経由) | | 支払時期 | 契約開始時、以降は毎月の契約更新日 | | サービス提供時期 | 申込完了後、即時 | | 返品・キャンセル | デジタルサービスの性質上、返金は原則不可。解約は次回課金日の前日まで可能 | ## お問い合わせ [Section titled “お問い合わせ”](#お問い合わせ) 本規約に関するお問い合わせは下記までご連絡ください。 * **メール**: # データ保持と削除 > プラン別のデータ保持期間と、自動削除の対象・タイミング 監視データがいつまで保持され、いつ削除されるかの仕様です。 ## 保持期間 [Section titled “保持期間”](#保持期間) | プラン | 監視データ保持 | 監査ログ | | ---- | ------- | ------- | | Free | 7 日 | 閲覧不可 | | Pro | 90 日 | 過去 90 日 | ## 自動削除の対象 [Section titled “自動削除の対象”](#自動削除の対象) 保持期間を過ぎた次のデータは、**毎日 03:00 UTC**（日本時間 12:00）に自動削除されます。 * 通知の送信履歴 * **解決済み**のインシデント ノート 対応中 (ongoing)・確認済み (acknowledged) のインシデントは保持期間に関わらず削除されません。削除されるのは解決済みのインシデントのみです。 * 有効期限を過ぎた API キーも同じタイミングで削除されます ## 監査ログの扱い [Section titled “監査ログの扱い”](#監査ログの扱い) * Free プランでは監査ログを**閲覧できません**が、操作の記録自体は保持されています。Pro 以上へのアップグレード後は、アップグレード前の操作も保持期間の範囲で遡って閲覧できます * Pro では保持期間（90 日）を過ぎた監査ログが削除されます ## プランのダウングレード [Section titled “プランのダウングレード”](#プランのダウングレード) 保持期間の短いプランに変更した場合、次回の自動削除タイミングで新しい保持期間より古いデータが削除されます。削除されたデータは復元できないため、ダウングレードは保持期間の違いを確認のうえ行ってください。 # 監視ライフサイクル > チェック間隔の決まり方、モニターステータス、インシデントの自動作成・自動解決の仕様 モニターのチェックがどう実行され、いつインシデントになり、いつ解決されるかの正確な仕様です。 ## チェック実行間隔 [Section titled “チェック実行間隔”](#チェック実行間隔) チェックは 1 分ごとの周期で、実行タイミングが来たモニターに対して行われます。実際のチェック間隔は次のルールで決まります。 実際の間隔は、モニターに設定した間隔とプランの最短間隔のうち**長い方**です。 | プラン | 最短チェック間隔 | | ---- | -------- | | Free | 5 分 | | Pro | 3 分 | 一時停止中のモニターはチェックされません。 ## モニターステータス [Section titled “モニターステータス”](#モニターステータス) | ステータス | 意味 | | ---------- | ---------------------------------------------------------------------------------------- | | `up` | 正常。チェック条件をすべて満たしている | | `down` | 異常。期待ステータスコード不一致・タイムアウト・キーワード条件違反など | | `degraded` | 判定不能・機能低下。チェック基盤側の問題で正否を判定できない状態。現行の HTTP / TCP / Ping 監視は up / down のみを返すため、この状態は発生しません | | `paused` | 一時停止中 | | `unknown` | 未チェックなどの不明状態 | ノート HTTP モニターはリダイレクト応答を追跡しません。期待ステータスコードと異なるリダイレクトが返った場合は `down` と判定されます。 ## インシデントの自動作成 [Section titled “インシデントの自動作成”](#インシデントの自動作成) 誤検知を防ぐため、1 回の失敗では通知されません。 1. チェックが `down` になるたびに連続ダウン回数を数えます 2. **連続 5 回** `down` になった時点でインシデント（対応中 / ongoing）を自動作成します 3. 作成と同時にインシデント発生通知（重大度: critical）を送信します 4. すでに未解決のインシデントがある間は、新しいインシデントを重複作成しません ### 新規モニターの猶予期間 [Section titled “新規モニターの猶予期間”](#新規モニターの猶予期間) 作成直後のモニターは、**最初に 1 回 `up` になるまで**インシデント判定が保留されます（設定ミスによる誤報を防ぐため）。ただし、一度も `up` にならないまま連続 5 回 `down` になった場合は、猶予を打ち切ってインシデントを作成します。 ## 復旧とインシデントの自動解決 [Section titled “復旧とインシデントの自動解決”](#復旧とインシデントの自動解決) * チェックが `up` に戻ると、連続ダウン回数はリセットされ、未解決のインシデント（対応中・確認済み）は自動的に**解決済み (resolved)** になります * 解決と同時に復旧通知を送信します * インシデントの「確認済み (acknowledged)」は対応中であることを示すステータスで、復旧時には確認済みのインシデントも自動解決されます * 手動解決では連続ダウン回数をリセットします。モニターが `down` のままなら、さらに 5 回連続で失敗した時点で新しいインシデントを作成して通知します ## メンテナンスウィンドウ [Section titled “メンテナンスウィンドウ”](#メンテナンスウィンドウ) モニター単位またはサービス単位でメンテナンス期間を設定できます。 * 期間中はインシデント判定が完全に停止し、連続ダウン回数もリセットされます * 自動解除を有効にすると終了時刻で自動的に解除され、無効の場合は手動で解除するまで続きます # 通知の挙動 > 通知イベントの種類、送信先チャネルの決まり方、フラップ抑制、重複送信防止の仕様 通知がいつ・どこに・何回送られるかの正確な仕様です。チャネル別の設定方法は[通知ガイド](/guides/notifications/)を参照してください。 ## 通知イベントの種類 [Section titled “通知イベントの種類”](#通知イベントの種類) | イベント | タイミング | 重大度 | | ------------- | ------------------- | -------- | | インシデント発生 | 連続 5 回ダウンでインシデント確定時 | critical | | インシデント解決 | モニター復旧による自動解決時 | – | | メンテナンス開始 / 終了 | メンテナンスウィンドウの開始・終了時 | – | ## 送信先チャネルの決まり方 [Section titled “送信先チャネルの決まり方”](#送信先チャネルの決まり方) 1. モニターに**個別の通知チャネルが 1 つでも紐付いている場合**、その中の有効かつ検証済みのチャネルだけに送信します（チーム全体のチャネルには送信されません） 2. 個別チャネルが 1 つもない場合、**チーム全体**の有効かつ検証済みのチャネルに送信します 3. 送信できるチャネルが 0 件の場合、通知は送信されません 注意 モニターに個別チャネルを 1 つでも設定すると、チーム全体のチャネルへのフォールバックは行われなくなります。個別設定は「このモニターだけ特定の宛先に送りたい」場合に使ってください。 ## フラップ抑制（バタつき防止） [Section titled “フラップ抑制（バタつき防止）”](#フラップ抑制バタつき防止) モニターがダウンと復旧を短時間に繰り返す（フラッピング）場合、通知の洪水を防ぐため抑制が働きます。 * **直近 10 分以内**に同じモニターの通知イベントが **3 回を超える**と、4 回目以降の通知は送信されません * カウントは 10 分経過で自動的にリセットされます * 抑制されている間もインシデント自体は記録されます（ダッシュボードでは確認できます) * メンテナンス開始・終了の通知はフラップ抑制の対象外です ## 重複送信の防止 [Section titled “重複送信の防止”](#重複送信の防止) 同じインシデント・同じチャネル・同じイベント種別の組み合わせは **1 回しか送信されません**。配信基盤の再試行が発生しても、同じ通知が二重に届くことはありません。 ## 一部チャネルの送信失敗 [Section titled “一部チャネルの送信失敗”](#一部チャネルの送信失敗) 複数チャネルへの送信で一部が失敗しても、残りのチャネルへの送信は継続されます。1 つでも成功すれば通知は完了扱いとなり、すべてのチャネルが失敗した場合のみ配信が再試行されます。 # レート制限 > Public API のレート制限の仕様 Manako の各エンドポイントに適用されるレート制限の仕様です。 ## Public API（`/api/v1/*`） [Section titled “Public API（/api/v1/\*）”](#public-apiapiv1) 2 段階の制限があり、どちらかを超えると HTTP 429 が返ります。 | 制限の単位 | 上限 | | ------------ | ----------------------------- | | 送信元 IP アドレス | 300 リクエスト / 分 | | API キー（プラン別） | Free: 60 / Pro: 180 リクエスト / 分 | ### 上限を超えた場合 [Section titled “上限を超えた場合”](#上限を超えた場合) * ステータスコード **429** とエラーコード `RATE_LIMITED` が返ります * レスポンスの `Retry-After` ヘッダーに、再試行までの待機秒数が入ります ```json { "error": { "code": "RATE_LIMITED", "message": "Rate limit exceeded", "status": 429 } } ``` ノート 制限は近似的なカウント方式のため、ごく短時間のバーストでは設定値をわずかに超えて受理されることがあります。上限値ちょうどに依存した設計は避けてください。 ### クライアント実装のガイドライン [Section titled “クライアント実装のガイドライン”](#クライアント実装のガイドライン) * 429 を受け取ったら `Retry-After` 秒待ってから再試行してください # 機能一覧 > Manako が提供する監視・通知・連携機能の全体像とプラン対応表 Manako の全機能を一覧で確認できます。各機能の使い方は対応するガイド、数値の上限は[プランと制限値](/reference/plans-limits/)を参照してください。 ## モニタータイプ（3 種） [Section titled “モニタータイプ（3 種）”](#モニタータイプ3-種) すべてのモニタータイプが**全プランで利用可能**です。プランによる差は監視数と最短チェック間隔のみです。 | タイプ | 監視対象 | 主な用途 | ガイド | | ---- | ------------- | ---------------------- | -------------------------------------------- | | HTTP | Web サイト / API | ステータスコード・キーワード・応答時間の確認 | [HTTP モニター](/guides/monitors/http-monitors/) | | TCP | ホストのポート | DB・メールサーバー等の死活監視 | [TCP モニター](/guides/monitors/tcp-monitors/) | | Ping | ホスト | ネットワーク到達性の確認 | [Ping モニター](/guides/monitors/ping-monitors/) | ## 通知チャネル（6 種） [Section titled “通知チャネル（6 種）”](#通知チャネル6-種) | チャネル | Free | Pro | ガイド | | ------- | :--: | :-: | ---------------------------------------------------------- | | メール | ✓ | ✓ | [メール通知](/guides/notifications/email-notifications/) | | Slack | ✓ | ✓ | [Slack 通知](/guides/notifications/slack-notifications/) | | Discord | ✓ | ✓ | [Discord 通知](/guides/notifications/discord-notifications/) | | Webhook | ✓ | ✓ | [Webhook 通知](/guides/notifications/webhook-notifications/) | | LINE | – | ✓ | [LINE 通知](/guides/notifications/line-notifications/) | | GitHub | – | ✓ | [GitHub 通知](/guides/notifications/github-notifications/) | 通知の発火条件・抑制ルールは[通知の挙動仕様](/reference/behavior/notifications/)を参照してください。 ## ダッシュボード・運用機能 [Section titled “ダッシュボード・運用機能”](#ダッシュボード運用機能) | 機能 | 概要 | プラン | | ----------- | --------------------------- | ------------- | | サービスグループ | モニターをサービス単位でグルーピングして管理 | 全プラン（数はプラン制限） | | インシデント管理 | 自動検知・確認（acknowledge）・自動解決 | 全プラン | | ステータスページ | 稼働状況の公開ページ | 全プラン | | メンテナンスウィンドウ | 計画メンテ中のインシデント判定・通知の抑制 | 全プラン | | 監査ログ | チーム内の操作履歴の閲覧 | Pro 以上 | | 多要素認証（MFA） | TOTP によるログイン保護・リカバリーコード | 全プラン | | ソーシャルログイン | Google / GitHub アカウントでのログイン | 全プラン | | 多言語 UI | 日本語 / 英語 | 全プラン | ## 開発者向け機能 [Section titled “開発者向け機能”](#開発者向け機能) | 機能 | 概要 | ドキュメント | | ------------------ | ------------------------ | ----------------------------------------------------- | | Public API | REST API（API キー認証） | [API リファレンス](/api/) | | API キー管理 | 発行・失効・有効期限設定 | [API キー](/developers/api-keys/) | | CLI | ターミナルからのモニター・インシデント操作 | [CLI](/developers/cli/) | | MCP Server | AI エージェント（Claude 等）からの操作 | [MCP Server](/developers/mcp-server/) | | Claude Code Plugin | Claude Code 向けスキル集 | [Claude Code Plugin](/developers/claude-code-plugin/) | ヒント API・CLI・MCP Server はすべて同じ Public API を基盤としているため、どのインターフェースからでも同じ操作ができます。 # プランと制限値 > Free / Pro 各プランの上限値・保持期間・レート制限の一覧 Manako の各プランに適用される制限値の一覧です。料金は[料金ページ](https://manako.dev/#pricing)を参照してください。 ## 制限値一覧 [Section titled “制限値一覧”](#制限値一覧) | 制限 | Free | Pro | | --------- | ------------------------------- | ------------------------ | | モニター数 | 3 | 20 | | 最短チェック間隔 | 5 分 | 3 分 | | データ保持期間 | 7 日 | 90 日 | | 監査ログ閲覧 | 不可 | 過去 90 日 | | サービスグループ数 | 1 | 5 | | 通知チャネル数 | 5 | 15 | | API キー数 | 5 | 10 | | API レート制限 | 60 req/分 | 180 req/分 | | 監視タイプ | HTTP / TCP / Ping | HTTP / TCP / Ping | | 通知チャネル種別 | メール / Slack / Discord / Webhook | Free の4種 + LINE / GitHub | ## 各制限の補足 [Section titled “各制限の補足”](#各制限の補足) ### 最短チェック間隔 [Section titled “最短チェック間隔”](#最短チェック間隔) モニターに設定したチェック間隔がプランの最短間隔より短い場合、実際のチェックはプランの最短間隔に切り上げられます。 ### データ保持期間 [Section titled “データ保持期間”](#データ保持期間) 保持期間を過ぎた以下のデータは毎日自動削除されます（削除タイミングは 03:00 UTC）。 * 通知の送信履歴 * 解決済みインシデント（対応中・確認済みのインシデントは削除されません） 詳細は[データ保持の挙動仕様](/reference/behavior/data-retention/)を参照してください。 ### 監査ログ閲覧 [Section titled “監査ログ閲覧”](#監査ログ閲覧) Free プランでは監査ログを閲覧できませんが、操作の記録自体は行われています。Pro にアップグレードすると、記録済みの過去ログも保持期間の範囲で閲覧できます。 ### API レート制限 [Section titled “API レート制限”](#api-レート制限) Public API（`/api/v1/*`）に適用されます。上限を超えると HTTP 429 が返ります。詳細は[レート制限の挙動仕様](/reference/behavior/rate-limits/)を参照してください。 ノート 過去に提供していた旧プランをご利用の場合、現行の Pro プラン相当の制限が適用されます。 ## プラン変更 [Section titled “プラン変更”](#プラン変更) プランの変更・支払い方法の管理は、ダッシュボードの「設定 → 請求」から行えます。アップグレードは即時反映されます。 # 画面リファレンス > ダッシュボードの全画面と対応リファレンスページの一覧 ダッシュボード（app.manako.dev）の全画面を機能グループごとに解説しています。 ## 画面とページの対応 [Section titled “画面とページの対応”](#画面とページの対応) | 画面 | URL | リファレンス | | -------------------------------------------- | ---------------------------------------------------- | -------------------------------------- | | ログイン / 新規登録 | `/login` `/signup` | [認証画面](/reference/screens/auth/) | | パスワード再設定 / メール確認 | `/forgot-password` `/reset-password` `/verify-email` | [認証画面](/reference/screens/auth/) | | 二段階認証 / デバイス認証 | `/mfa-challenge` `/auth/device` | [認証画面](/reference/screens/auth/) | | サービス一覧・作成・詳細・編集 | `/services` ほか | [サービス画面](/reference/screens/services/) | | モニター作成・詳細・編集 | `/services/:id/monitors/*` | [モニター画面](/reference/screens/monitors/) | | 設定（連携 / API キー / アカウント / セキュリティ / 監査ログ / 請求） | `/settings/*` | [設定画面](/reference/screens/settings/) | | お問い合わせ | `/contact` | このページ（下記） | ## お問い合わせ（`/contact`） [Section titled “お問い合わせ（/contact）”](#お問い合わせcontact) ログイン後に利用できるサポート窓口です。 | 項目 | 必須 | 備考 | | ----------- | -- | ---------------------------------------------- | | カテゴリ | ✓ | 一般的な質問 / 機能リクエスト / 不具合報告 / 料金・プラン / その他 | | メッセージ | ✓ | 最大 5000 文字 | | スクリーンショット添付 | – | 画像（PNG / JPEG / GIF / WebP）を最大 3 ファイル・各 5MB まで | 送信すると確認メールが届きます。 # 認証画面 > ログイン・新規登録・パスワード再設定・MFA・デバイス認証の各画面の項目と挙動 ログイン前後の認証にかかわる画面のリファレンスです。 ノート パスワードの共通ルール: **8〜128 文字で、英字と数字を 1 文字以上ずつ**含める必要があります。ログイン・新規登録画面には不正アクセス対策の CAPTCHA が表示されることがあります。 ## ログイン（`/login`） [Section titled “ログイン（/login）”](#ログインlogin) | 項目 | 型 | 必須 | 備考 | | ------- | ----- | -- | -- | | メールアドレス | メール | ✓ | | | パスワード | パスワード | ✓ | | * **Google / GitHub で続ける**: ソーシャルログイン。利用可能なプロバイダのみ表示されます * **ログイン**: 成功するとダッシュボードへ移動します。MFA を有効にしている場合は後述の二段階認証画面へ進みます 主なエラー: | メッセージ | 原因 | | ----------------------------------- | ---------------------- | | メールアドレスまたはパスワードが正しくありません | 認証情報の誤り | | ログイン試行回数が上限に達しました。しばらくしてからお試しください | 連続失敗によるロック | | アカウントは削除予約中です。キャンセルはサポートにお問い合わせください | 削除手続き中のアカウント | | パスワードのリセットが必要です | 管理側でリセットが必要と判断されたアカウント | ## 新規登録（`/signup`） [Section titled “新規登録（/signup）”](#新規登録signup) | 項目 | 型 | 必須 | 備考 | | -------- | -------- | -- | ----------------- | | 名前 | テキスト | – | 入力する場合は 1〜100 文字 | | メールアドレス | メール | ✓ | | | パスワード | パスワード | ✓ | 8〜128 文字・英字と数字を含む | | 利用規約への同意 | チェックボックス | ✓ | 未チェックの間は登録ボタンが無効 | 登録に成功するとそのままダッシュボードへ移動します。Google / GitHub での登録も可能です。 ## パスワードを忘れた方（`/forgot-password`） [Section titled “パスワードを忘れた方（/forgot-password）”](#パスワードを忘れた方forgot-password) メールアドレスを入力して「リセットリンクを送信」を押すと、リセット用リンクがメールで届きます。セキュリティ上、**入力したアドレスのアカウント有無にかかわらず同じ完了メッセージ**が表示されます。メールが届かない場合は迷惑メールフォルダを確認してください。 ## パスワードリセット（`/reset-password`） [Section titled “パスワードリセット（/reset-password）”](#パスワードリセットreset-password) メール内のリンクから開く画面です。新しいパスワード（8〜128 文字）を 2 回入力して設定します。2 つの入力が一致しない場合は「パスワードが一致しません。」と表示されます。リンクが無効または期限切れの場合はエラー画面になり、「パスワードを忘れた方」から再度リクエストできます。 ## メールアドレス確認（`/verify-email`） [Section titled “メールアドレス確認（/verify-email）”](#メールアドレス確認verify-email) 確認メール内のリンクから開くと自動で検証が実行されます。成功・失敗いずれの場合も結果が表示され、ダッシュボードへ戻れます。リンクが期限切れの場合は失敗となります。 ## 二段階認証（`/mfa-challenge`） [Section titled “二段階認証（/mfa-challenge）”](#二段階認証mfa-challenge) MFA 有効ユーザーのログイン時に表示されます。 * **認証アプリのコード**: 6 桁の数字。6 桁入力すると自動で送信されます * **リカバリーコード**: 認証アプリが使えない場合の代替。「リカバリーコードを使用」で切り替えます * セッションが期限切れになると「MFAトークンが期限切れです。再度ログインしてください。」と表示され、ログイン画面へ戻ります ## デバイス認証（`/auth/device`） [Section titled “デバイス認証（/auth/device）”](#デバイス認証authdevice) CLI や MCP Server のログイン時に表示されたコードを承認し、API キーを発行する画面です。ログインしていない場合は先にログイン画面へ移動します。 | 項目 | 型 | 必須 | 備考 | | -------- | -------- | -- | ----------------------------- | | 認証コード | テキスト | ✓ | `XXXX-XXXX` 形式。入力すると自動で整形されます | | 本人確認チェック | チェックボックス | ✓ | 自分で開始したログインのコードであることの確認 | 注意 コードを承認すると、外部ツールがアカウントのデータにアクセスできる API キーが発行されます。**自分で開始したログインのコード以外は絶対に承認しないでください。** 主なエラー: | メッセージ | 原因 | | ----------------- | --------------------------- | | 試行回数の上限に達しました | 誤入力の繰り返し。CLI で再ログインが必要 | | API Keyの上限に達しています | プランの API キー上限。不要なキーを削除して再試行 | | コードが見つかりません | 入力誤り | | コードが無効または期限切れです | コードの有効期限切れ | ## OAuth コールバック（`/auth/oauth/callback`） [Section titled “OAuth コールバック（/auth/oauth/callback）”](#oauth-コールバックauthoauthcallback) Google / GitHub 認証後に自動で処理される中間画面です。初回利用時は利用規約への同意が求められます。エラー時は理由（認証キャンセル・セッション期限切れ・検証済みメールアドレスが必要・別ユーザーに接続済み など）が表示され、ログイン画面へ戻れます。 # モニター画面 > モニター作成・編集フォームの全設定項目（3タイプ別）とモニター詳細画面 モニターの作成・編集フォームと詳細画面のリファレンスです。設定値の許容範囲はサーバー側でも検証されます。 ## 作成・編集フォーム（`/services/:id/monitors/new` ほか） [Section titled “作成・編集フォーム（/services/:id/monitors/new ほか）”](#作成編集フォームservicesidmonitorsnew-ほか) ### 共通項目 [Section titled “共通項目”](#共通項目) | 項目 | 必須 | 備考 | | ------ | -- | ------------------------------------------------------------------------- | | タイプ | ✓ | HTTP / TCP / Ping。**作成後は変更不可** | | 表示名 | – | 空欄の場合は設定内容から自動生成（例: `example.com /path`） | | チェック間隔 | ✓ | 3分 / 5分 / 10分 / 30分 / 1時間。**プランの最短間隔より短い選択肢は選べません**（Free: 5分〜 / Pro: 3分〜） | ### HTTP [Section titled “HTTP”](#http) | 項目 | 必須 | 範囲・既定値 | | ----------- | -- | ----------------------------------- | | URL | ✓ | `http(s)://` のパブリック URL（最大 2048 文字） | | メソッド | – | GET / HEAD / POST（既定 GET） | | 期待するステータス | – | 100〜599(既定 200) | | キーワード | – | レスポンスボディに対する文字列チェック | | キーワードの含有条件 | – | 「含まれている必要がある」（既定）または含まれていたら異常 | | タイムアウト (ms) | – | 1000〜30000（既定 10000） | ノート HTTP モニターはリダイレクトを追跡しません。また、カスタムヘッダーを付ける場合、`Host` `Authorization` `Cookie` などの予約ヘッダー名は使用できません。 ### TCP [Section titled “TCP”](#tcp) | 項目 | 必須 | 範囲・既定値 | | ----------- | -- | -------------------- | | ホスト名 | ✓ | パブリックなホスト名 | | ポート | ✓ | 1〜65535 | | タイムアウト (ms) | – | 1000〜30000（既定 10000） | ### Ping [Section titled “Ping”](#ping) | 項目 | 必須 | 範囲・既定値 | | ----------- | -- | ------------------------------ | | ホスト名 | ✓ | パブリックなホスト名 | | ポート | – | 1〜65535（既定 443）。TCP 接続による到達性確認 | | タイムアウト (ms) | – | 1000〜30000（既定 10000） | ## モニター詳細（`/services/:id/monitors/:mid`） [Section titled “モニター詳細（/services/:id/monitors/:mid）”](#モニター詳細servicesidmonitorsmid) ### ステータスバッジ [Section titled “ステータスバッジ”](#ステータスバッジ) | バッジ | 意味 | | ------------- | ---------------------------------------------------------------------- | | 稼働中（緑） | 正常 | | 停止（赤） | ダウン検知中 | | 低下（黄） | 判定不能（degraded）。現行の HTTP / TCP / Ping 監視は up / down のみを返すため、この状態は発生しません | | 一時停止（灰） | チェック停止中 | | 待機中 / 初期化中（青） | 初回チェック待ち | | メンテナンス中（青） | メンテナンスウィンドウ有効中 | ### 操作 [Section titled “操作”](#操作) * **今すぐチェック**: 即時チェックを実行し結果をインライン表示。短時間の連続実行はできません（超過時は 5 分のクールダウン案内が表示されます） * **メンテナンス開始 / 終了** * **統計データをリセット**: 稼働率表示のリセット。「全期間」または「指定日より前」を選択。**取り消せません** * **編集**: 編集フォームへ（削除はサービス詳細のモニター一覧から） ### タイプ別の表示 [Section titled “タイプ別の表示”](#タイプ別の表示) * **HTTP / TCP / Ping**: 直近 50 件の応答時間グラフ、平均応答時間、稼働率。応答時間がベースラインから大きく外れると「応答時間異常」バッジが表示されます ### 通知チャンネルの紐付け [Section titled “通知チャンネルの紐付け”](#通知チャンネルの紐付け) モニター個別の通知先を設定できます。**1 つも紐付けない場合はチーム全体のチャンネルに通知**され、1 つでも紐付けるとそのチャンネルだけに通知されます（[通知の挙動](/reference/behavior/notifications/)参照）。 # サービス画面 > サービス一覧・作成・詳細・編集画面の表示項目と操作 モニターをグルーピングする「サービス」に関する画面のリファレンスです。作成できるサービス数は[プランにより異なります](/reference/plans-limits/)。 ## サービス一覧（`/services`） [Section titled “サービス一覧（/services）”](#サービス一覧services) ログイン後のホーム画面です。チームの全サービスがカードで表示されます。 ### 通知セットアップバナー [Section titled “通知セットアップバナー”](#通知セットアップバナー) 通知チャネルが 1 件も設定されていない場合、一覧の上部に「通知連携が未設定です」というバナーが表示されます。「設定する」から[連携画面](/reference/screens/settings/#%E9%80%A3%E6%90%BAsettingsintegrations)へ移動できます。✕ で閉じると同じブラウザでは再表示されません。 ### カードの表示内容 [Section titled “カードの表示内容”](#カードの表示内容) | 表示 | 意味 | | --------------------------- | --------------------- | | ステータスドット（緑） | 正常稼働中 | | ステータスドット（赤） | 対応中のインシデントあり | | ステータスドット（青） | メンテナンス中 | | ステータスドット（グレー） | モニターが 0 件 | | 「デフォルト」バッジ | 初期作成されたサービス（削除不可） | | 「メンテナンス中」バッジ | メンテナンスウィンドウ有効中 | | `{n}`個のモニター / `{n}`件のインシデント | 所属モニター数・未解決インシデント数 | | 公開スラッグリンク | ステータスページ公開中の場合の公開 URL | ### 操作 [Section titled “操作”](#操作) * **新規**: サービス作成画面へ * **メンテナンス開始 / 終了**（レンチ）: メンテナンスウィンドウの設定・解除。終了時は確認ダイアログが表示されます * **設定**（鉛筆）: サービス編集画面へ * **削除**（ゴミ箱）: 確認ダイアログの後に削除。**所属していたモニターとインシデントはデフォルトサービスに移動**します。デフォルトサービス自体は削除できません ### メンテナンス設定ダイアログ [Section titled “メンテナンス設定ダイアログ”](#メンテナンス設定ダイアログ) | 項目 | 必須 | 備考 | | ------------ | -- | ---------------------------- | | 終了日時 | ✓ | 初期値は 1 時間後。自動解除の場合は最大 7 日後まで | | 終了時刻に自動で解除する | – | 初期値オン。オフの場合は手動で解除するまで継続 | ## 新規サービス作成（`/services/new`） [Section titled “新規サービス作成（/services/new）”](#新規サービス作成servicesnew) | 項目 | 型 | 必須 | 備考 | | ----- | ------- | -- | ---------------------------------- | | サービス名 | テキスト | ✓ | 例: 本番環境。入力に応じてスラッグが自動生成されます | | スラッグ | テキスト | ✓ | 小文字英数字とハイフンのみ。ステータスページの URL に使われます | | 説明 | テキストエリア | – | | 作成に成功するとサービス詳細へ移動します。 ## サービス詳細（`/services/:id`） [Section titled “サービス詳細（/services/:id）”](#サービス詳細servicesid) 「モニター」「インシデント」「公開設定」の 3 タブ構成です。メンテナンス中は上部に「このサービスは `{日時}` までメンテナンス中です」と表示されます。 ### モニタータブ [Section titled “モニタータブ”](#モニタータブ) * 所属モニターの一覧。各行にステータスバッジ・名前・タイプ・チェック間隔を表示 * **新規**: モニター作成画面へ * 各行の編集・削除（削除は確認ダイアログあり） * チェックボックスで複数選択し、**メンテナンスの一括開始・終了**が可能 ### インシデントタブ [Section titled “インシデントタブ”](#インシデントタブ) * インシデントの一覧（タイトル・開始 / 解決日時・ステータスバッジ） * **インシデントを作成**: 手動インシデントの登録（手動分には「手動」バッジが付きます） * **対応開始**: ステータスを「確認済み (acknowledged)」に変更 * **解決する**: ステータスを「解決済み (resolved)」に変更 * 削除できるのは手動で作成したインシデントのみです ### 公開設定タブ [Section titled “公開設定タブ”](#公開設定タブ) * **ステータスページを公開する**: トグル切り替えで即時保存。公開 URL とバッジ埋め込み方法が表示されます ## サービス編集（`/services/:id/edit`） [Section titled “サービス編集（/services/:id/edit）”](#サービス編集servicesidedit) サービス名・スラッグ・説明の 3 項目を変更できます。編集では名前を変えてもスラッグは自動変更されません（公開 URL を守るため）。公開設定は詳細画面の公開設定タブで操作します。 注意 スラッグを変更すると公開中のステータスページの URL が変わります。外部に共有済みの場合は注意してください。 # 設定画面 > 連携・API キー・アカウント・セキュリティ・監査ログ・請求の各設定画面の項目と挙動 「設定」配下の 6 画面のリファレンスです。 ノート **本人確認（再認証）が必要な操作**: API キーの作成・削除、アカウント削除、MFA の無効化では、パスワード等による再認証が求められます。確認は 15 分間有効で、5 回失敗すると 15 分間ロックされます。なお MFA のリカバリーコード再生成は、この仕組みとは別に操作のたびにパスワード入力が必要です。 ## 連携（`/settings/integrations`） [Section titled “連携（/settings/integrations）”](#連携settingsintegrations) 通知チャネル 6 種の接続を管理します。Free プランで使えるのは**メール / Slack / Discord / Webhook** の 4 種、LINE / GitHub は Pro で利用できます。画面上部のヘッダーにある「連携」リンクからも直接開けます。 ### チャネル別の設定項目 [Section titled “チャネル別の設定項目”](#チャネル別の設定項目) すべてのチャネルで「名前」（必須）を付けます。それに加えて: | チャネル | 設定項目 | | ------- | -------------------------------------------------------- | | メール | 宛先メールアドレス。追加後に**確認メールの承認が必要**（未確認の間は「未確認」表示・再送可能） | | Slack | Incoming Webhook URL | | Discord | Webhook URL | | Webhook | 送信先 URL（HTTPS）・Secret（署名検証用） | | LINE | Channel Access Token・送信先 ID | | GitHub | Personal Access Token・Owner・Repository・Labels（任意、カンマ区切り） | ### 操作 [Section titled “操作”](#操作) * **テスト送信**: 設定済みチャネルへテスト通知を送信して疎通確認 * **削除**: 確認ダイアログの後に削除 * **編集**: 名前を変更できます。接続設定も変更する場合は「**接続設定を再入力する**」にチェックを入れ、すべての項目を再入力します（セキュリティ上、保存済みの設定値は表示されません）。メールの宛先を変更した場合は再度確認メールの承認が必要です ## API キー（`/settings/api-keys`） [Section titled “API キー（/settings/api-keys）”](#api-キーsettingsapi-keys) Public API・CLI・MCP Server で使う API キーを管理します。上限数は[プランによります](/reference/plans-limits/)。 ### 作成フォーム [Section titled “作成フォーム”](#作成フォーム) | 項目 | 必須 | 備考 | | ---- | -- | --------------------------------- | | 名前 | ✓ | 例: CLI Access | | スコープ | ✓ | read（既定）/ write。最低 1 つ | | 種類 | – | 永続 / 期限付き（1 時間〜90 日のプリセットまたは日時指定） | 注意 作成直後に表示されるキー本体は**その場でしか確認できません**。必ずコピーして安全に保管してください。 ### 一覧と削除 [Section titled “一覧と削除”](#一覧と削除) * 一覧には名前・キーの先頭部分・種類バッジ（永続 / 期限付き / セッション）・スコープ・有効期限・最終使用日時が表示されます。「セッション」はデバイス認証（CLI / MCP ログイン）で自動発行されたキーです * 削除時は誤操作防止のため**キー名の完全一致入力**が必要です。削除するとそのキーを使う連携は即座に動作しなくなります ## アカウント（`/settings/account`） [Section titled “アカウント（/settings/account）”](#アカウントsettingsaccount) * **メールアドレス変更**: 新しいアドレスを入力し、パスワード（またはメールで届く 6 桁の確認コード。パスワードを持たない OAuth ユーザー向け）で確認。新アドレスに届く確認メールで確定します * **名前変更**: インライン編集 * **データエクスポート**: アカウントデータを JSON でダウンロード（**有料プラン限定・チームオーナーのみ**） * **アカウント削除**: 重要操作の再認証（15 分間有効）後に削除予約されます。**30 日後にすべてのデータが完全に削除**され、それまではサポート経由でキャンセル可能です ## セキュリティ（`/settings/security`） [Section titled “セキュリティ（/settings/security）”](#セキュリティsettingssecurity) * **パスワード変更**: 現在のパスワード + 新しいパスワード（8 文字以上）。OAuth 登録でパスワード未設定の場合は「パスワード設定」になります * **二要素認証（MFA）**: * 有効化: パスワード確認 → 認証アプリで QR コードをスキャン → 6 桁コードで確認 → **リカバリーコードを保存**（ダウンロード / コピー可。再表示されません） * 無効化・リカバリーコード再生成: パスワード確認つき * **接続済みアカウント**: Google / GitHub の既存連携を表示・解除。新しい連携の追加は準備中です。パスワード未設定で連携が 1 件しかない場合は、ログイン手段を失わないよう**解除できません**（先にパスワードを設定してください） ## 監査ログ（`/settings/audit-logs`） [Section titled “監査ログ（/settings/audit-logs）”](#監査ログsettingsaudit-logs) チーム内の操作履歴（時刻・ユーザー・アクション・対象リソース・IP アドレス）を閲覧できます。**Pro プラン以上**で利用可能です。カテゴリで絞り込み、スクロールで過去分を順次読み込みます。 ## 請求・プラン（`/settings/billing`） [Section titled “請求・プラン（/settings/billing）”](#請求プランsettingsbilling) * **現在のサブスクリプション**: プラン名・課金間隔・ステータス・次回更新日。「サブスクリプションを管理」から支払い方法の変更・解約ができます（Stripe の管理画面が開きます） * **プラン変更**: 月払い / 年払い（年払いは 2 ヶ月分お得）を選び、アップグレード / ダウングレード。決済ページを経由して即時反映されます * **請求書・領収書**: 有料プランでは管理画面から確認できます 各プランの上限値は[プランと制限値](/reference/plans-limits/)を参照してください。