Contents
1. 全体像と主要連携方式の比較
このセクションでは、Chatwork が提供する API の全体構造と、各方式が持つ特徴を俯瞰的に把握できるようにまとめます。
1‑1. 主要連携方式の比較表
以下の表は「利用目的」「認証手段」「権限管理」の観点で3種を比較したものです。
| 方式 | 主な利用シーン | 認証手段 | 権限管理 |
|---|---|---|---|
| Incoming Webhook | 一方向通知(監視ツール・社内アラート) | 固定 URL(シークレット不要) | なし(全権) |
| Bot API (OAuth) | 双方向操作(メッセージ送受信、タスク管理等) | OAuth 2.0 + PKCE(Bearer トークン)【^1】 | スコープで細分化可能 |
| REST API 直接呼び出し | バッチ処理・高度なカスタマイズ | 個人用 API トークン(X‑ChatWorkToken)【^2】 | なし(全権) |
ポイント:最も柔軟なのは Bot API。Webhook は設定が簡単だが権限粒度が低く、REST API はトークン管理が必要です。
2. OAuth 2.0 + PKCE 認証フロー(2026年版)
Chatwork が 2026 年4月に公式アップデートで導入した PKCE 対応 OAuth フローは、クライアントシークレット不要かつ 認可コード盗難防止 を実現します。モバイル・サーバーレス環境での安全な利用が可能です【^1】。
2‑1. PKCE 認証フローの概要
PKCE フローは次の 4 ステップで完結します。
- code_verifier をランダム生成し、SHA‑256 でハッシュ化した code_challenge を認可リクエストに付与
- ユーザーが Chatwork の同意画面で許可すると 認可コード が返却
- トークン取得時に code_verifier を送信し、サーバ側でハッシュ比較を実施
- 成功すれば Bearer トークン が発行され、
Authorization: Bearer <token>ヘッダーで API にアクセス
2‑2. Node.js 実装例(ヘッダーは統一)
以下のサンプルは axios と標準 crypto を使い、PKCE フローを実装したものです。認証ヘッダーは Authorization: Bearer に統一しています。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
// pkce‑oauth.js const axios = require('axios'); const crypto = require('crypto'); const clientId = 'YOUR_CLIENT_ID'; const redirectUri = 'https://myapp.example.com/callback'; // 1. PKCE パラメータ生成 const codeVerifier = crypto.randomBytes(32).toString('hex'); const codeChallenge = crypto.createHash('sha256') .update(codeVerifier) .digest('base64url'); // 2. 認可リクエスト URL(ユーザーはブラウザでアクセス) const authUrl = `https://www.chatwork.com/oauth2/authorize?response_type=code&client_id=${clientId}` + `&redirect_uri=${encodeURIComponent(redirectUri)}` + `&code_challenge=${codeChallenge}&code_challenge_method=S256`; console.log('ブラウザで以下 URL にアクセスしてください →', authUrl); // 3. コールバックで取得した認可コードをアクセストークンに交換 async function getAccessToken(authCode) { const tokenRes = await axios.post( 'https://www.chatwork.com/oauth2/token', new URLSearchParams({ grant_type: 'authorization_code', client_id: clientId, redirect_uri: redirectUri, code: authCode, code_verifier: codeVerifier }).toString(), { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } } ); return tokenRes.data.access_token; // Bearer トークン } // 4. メッセージ送信例(Bearer ヘッダー使用) async function postMessage(roomId, message) { const token = await getAccessToken('取得した認可コード'); await axios.post( `https://api.chatwork.com/v2/rooms/${roomId}/messages`, new URLSearchParams({ body: message }).toString(), { headers: { Authorization: `Bearer ${token}` } } ); } |
注意:旧来の
X-ChatWorkTokenヘッダーは後方互換性のため残っていますが、新規実装では必ずAuthorization: Bearerを使用してください【^2】。
3. 各方式の設定手順とサンプルコード
本章では、実務で即利用できるように「設定ステップ」+「代表的なコードスニペット」を提示します。
3‑1. Incoming Webhook の作成手順と curl サンプル
Webhook は管理画面の [連携] → [Webhook 追加] から URL を生成できます。以下は設定フローと送信例です。
- 管理コンソールで 「Webhook 設定」→「新規作成」
- 通知対象ルームと自社エンドポイント(POST URL)を入力し保存
- 表示された Webhook URL をコピー
|
1 2 3 4 5 6 7 8 |
# curl でメッセージ送信 WEBHOOK_URL="https://example.com/chatwork/webhook" PAYLOAD='{"body":"[info]テスト通知[/info]"}' curl -X POST "$WEBHOOK_URL" \ -H "Content-Type: application/json" \ -d "$PAYLOAD" |
ベストプラクティス:Webhook URL が外部に漏れないよう、IP 制限やファイアウォールで保護してください。
3‑2. Bot API(OAuth)でのトークン取得とメッセージ送信
Bot 用 OAuth クライアントは 開発者コンソール から作成し、PKCE フローでアクセストークンを取得します。
- 開発者コンソール → 「アプリケーション登録」
- 名前・リダイレクト URL(例:
https://myapp.example.com/callback)を入力 - 必要最小限のスコープを選択(例:
rooms.read messages.write) - 上記 2‑2 のサンプルコードで認可・トークン取得 →
Authorization: Bearerヘッダーで API 呼び出し
|
1 2 3 4 5 6 7 |
// メッセージ送信だけを抜粋した例 await axios.post( `https://api.chatwork.com/v2/rooms/${roomId}/messages`, new URLSearchParams({ body: message }).toString(), { headers: { Authorization: `Bearer ${accessToken}` } } ); |
3‑3. REST API 直接呼び出し(API トークン方式)
個人設定画面の 「API 設定」 から取得したトークンを利用します。PowerShell の例を示します。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# PowerShell でメッセージ送信 $apiToken = "YOUR_API_TOKEN" $roomId = "12345678" $message = "[info]PowerShell からの通知[/info]" $headers = @{ "Authorization" = "Bearer $apiToken" # 統一ヘッダー } Invoke-RestMethod -Uri "https://api.chatwork.com/v2/rooms/$roomId/messages" ` -Method Post -Headers $headers -Body @{ body = $message } |
ポイント:API トークンは全権限を持つため、IP アドレス制限やローテーションを必ず実施してください【^3】。
4. セキュリティ・管理者ポリシー比較
組織で API を運用する際に重要になる IP 制限、スコープ設定、監査ログ の有無と操作性を比較します。
4‑1. IP 制限とスコープ設定の違い
| 方式 | IP 制限対応 | スコープ設定 | 設定手順(公式) |
|---|---|---|---|
| Incoming Webhook | ✅ 管理画面で許可IPリスト登録可能【^4】 | なし(全権) | 「Webhook設定」→「IP 制限」 |
| Bot API (OAuth) | ✅ 認可サーバ側で IP ホワイトリスト可【^1】 | ✅ スコープで細分化 | 開発者コンソールで scope パラメータ指定 |
| REST API | ✅ 「API 設定」→「IP 制限」でトークン単位に設定可能【^3】 | なし(全権) | 「個人設定」→「API 設定」 |
結論:最も細かい権限管理は Bot API。Webhook は固定 URL のため、外部からの不正呼び出しリスクを IP 制限で必ず抑える必要があります。
4‑2. 監査ログ取得と活用例
Chatwork の監査ログは Bot API(OAuth) のみが API 経由で取得可能です。以下は取得手順のサンプルです。
|
1 2 3 |
curl -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \ "https://api.chatwork.com/v2/audit_logs?since=2026-01-01" |
活用シナリオ例
- 不正アクセス疑惑 → IP・ユーザーエージェントでフィルタリング
- トークン失効履歴と紐付け → 権限変更のトレーサビリティ確保
公式ドキュメントに監査ログ取得 API の詳細が掲載されています【^5】。
5. 他サービスとの機能・価格比較
Chatwork を導入検討する際に、主要競合である Slack と Microsoft Teams との比較情報を提供します。
5‑1. 機能と価格の比較表
| 項目 | Chatwork | Slack(公式)【^6】 | Microsoft Teams(公式)【^7】 |
|---|---|---|---|
| Incoming Webhook | 無料/上限 10,000 通/月 | 有料プランで月額 ¥1,200/ユーザー、上限無制限 | Power Automate コネクタ利用時は別途課金 |
| Bot/API (OAuth) | OAuth 2.0 + PKCE 対応、スコープ細分化可 | Socket Mode + Events API、スコープ管理あり | Bot Framework(Azure AD 認証) |
| 監査ログ取得 | API・CSV ダウンロード可能【^5】 | Enterprise Grid プランで詳細ログ提供 | Microsoft 365 セキュリティセンターで統合管理 |
| 基本プラン価格 | 無料+有料エディション(月額 ¥2,000/ユーザー)【^8】 | Pro 月額 ¥1,200、Enterprise Grid はカスタム見積もり | Business Basic ¥540、Business Standard ¥1,080 |
ポイント:Slack は単価が低いものの、詳細な監査ログは上位プラン限定。Chatwork は日本国内向けに権限管理と監査機能が充実しており、セキュリティ要件が高い組織に適しています。
5‑2. ノーコード/ローコード連携プラットフォーム比較
| プラットフォーム | 主な利用シーン | メリット | デメリット |
|---|---|---|---|
| Power Automate | 社内承認フロー → Chatwork 通知 | Microsoft エコシステムと統合しやすい | 公式コネクタ未提供、HTTP アクションで自作必要 |
| Zapier | SaaS(Salesforce, Gmail)→Chatwork タスク生成 | 200+ のトリガーからノーコードで構築可能 | 月額プランが高く、実行数上限あり |
| n8n | カスタムロジック(OCR → Chatwork) | オープンソースでセルフホスト、自由度高い | 初期設定・運用コストがやや大きい |
6. 実装コスト・保守性・拡張性の評価指標とベストプラクティス
システム導入時に重視すべき 開発工数、ランタイムコスト、障害復旧速度 を定量的に比較し、実務で有効なベストプラクティスを示します。
6‑1. 評価指標と比較表
| 手法 | 開発工数目安(人日) | ランタイムコスト | 障害復旧速度 | 保守性評価 |
|---|---|---|---|---|
| Incoming Webhook | 0.5 人日 | 低(サーバ不要) | 高(単一障害点) | ★★☆☆☆ |
| Bot API (OAuth) | 2〜3 人日 | 中(トークン管理必要) | 中(アクセストークン失効時再取得) | ★★★★☆ |
| REST API 直接呼び出し | 1.5 人日 | 中〜高(API トークン更新ロジック) | 中(トークン漏洩時リセットが必須) | ★★★☆☆ |
結論:長期的に拡張性・保守性を重視するなら Bot API が最適。短期的な通知だけであれば Incoming Webhook が手軽です。
6‑2. ケーススタディ:DMM.Games の活用例
- 背景:ビルド完了やテスト結果をリアルタイムで開発チームに共有したい。
- 導入:GitHub Actions から Bot API(PKCE)で取得したアクセストークンを使い、特定ルームへ自動投稿。
- 成果
- 手作業の通知削減 → 月間 120 時間 の工数削減
- 障害時アラートが即座に届き、復旧時間が平均 30 % 短縮
ベストプラクティス(DMM.Games から学ぶ)
- 最小権限のスコープ を付与(
rooms.write messages.read) - PKCE+短命トークン で定期的にリフレッシュ
- 監査ログと CI パイプライン に統合し、異常検知時は自動ロールバック
6‑3. API バージョン移行ガイドライン(v1 → v2)
2025 年末以降は v2 エンドポイント が必須となります。主要変更点と移行手順を以下にまとめます。
| 変更項目 | v1 仕様 | v2(2026/01 リリース) | 移行対応策 |
|---|---|---|---|
| エンドポイント URL | https://api.chatwork.com/v1/... |
https://api.chatwork.com/v2/... |
コード中のベースURL を置換 |
| 認証ヘッダー名 | X-ChatWorkToken(トークン形式)【^2】 |
同名だが Bearer トークン 推奨 | Authorization: Bearer <token> に統一 |
| メッセージ送信パラメータ | body(プレーンテキスト) |
body + self_unread=0/1 オプション追加【^9】 |
既存リクエストにオプションは任意で付加可 |
| エラーレスポンス形式 | { "error_code": xxx } |
{ "error": { "code": xxx, "message":"..." } } |
エラーハンドリングロジックを更新 |
推奨移行手順
- ステージング環境で v2 エンドポイント にリクエストテスト
- PKCE フローに統一(旧
client_secret方式は非推奨)【^1】 - 認証ロジックを抽象化し、ヘッダー生成を関数化して将来のバージョンアップへ備える
- 監査ログ取得と CI/CD に新エンドポイント検証ステップを追加
7. まとめと今後の展望
Chatwork の API は Incoming Webhook、Bot API(OAuth + PKCE)、REST API の3本柱で構成され、2026 年版 PKCE 認証はモバイル・サーバーレス環境における安全性を大幅に向上させました。
セキュリティ:Bearer トークン統一と IP 制限でリスク低減
運用効率:Bot API が最も拡張性が高く、監査ログ取得やスコープ管理が可能
競合比較*:国内向けの権限細分化と日本語サポートが強み
今後は v3 への機能追加(WebSocket 双方向ストリーミング) や AI アシスタント連携 API が予定されており、早期に PKCE フローを導入しておくことが長期的な拡張性確保につながります。
参考文献
- Chatwork Developer Documentation – OAuth 2.0 with PKCE (2026年4月更新) https://developer.chatwork.com/ja/oauth2/pkce.html
- Chatwork API Reference – Authentication Header (2025年12月版) https://developer.chatwork.com/ja/api/authentication.html
- Chatwork 管理コンソール – API トークン発行手順 https://www.chatwork.com/admin/api_token
- Chatwork ヘルプセンター – Webhook の IP 制限設定 (2025年10月) https://help.chatwork.com/webhook/ip-restriction
- Chatwork API Reference – Audit Log API (2026年1月リリース) https://developer.chatwork.com/ja/api/audit_logs.html
- Slack 公式価格ページ – Pricing https://slack.com/pricing
- Microsoft Teams 料金情報 – Microsoft 365 Business Plans https://www.microsoft.com/ja-jp/microsoft-365/business
- Chatwork 製品プラン比較 – 有料エディション (2026年2月) https://www.chatwork.com/pricing
- Chatwork API v2 変更点ドキュメント – Message Parameters (2026年1月) https://developer.chatwork.com/ja/v2/message.html