Ship Watch:依存しているツールが X に投稿したら WhatsApp で通知

依存しているフレームワークがマイナーバージョンで破壊的変更を出荷することがあります。利用しているクラウドプロバイダーでリージョン障害が発生し、静かにエラーバジェットを食い潰していることもあります。あるいは、ある機能の土台にしていたライブラリが非推奨になり、6 か月のサンセット期限が設定されることもあります。こうしたケースのどれをとっても、最も早く知る手段は今でも X（Twitter）です。多くの場合、changelog やステータスページ、メーリングリストよりも早く分かります。メンテナーや DevRel チームが分かった瞬間に投稿する一方で、公式ドキュメントの更新はもっと遅いサイクルで行われるからです。

問題は「正しいアカウントをフォローするだけ」ではスケールしないことです。1 日中フィードをチェックしているわけではなく、エディタやターミナル、ミーティングの中にいます。次に X を開いた頃には、その発表はほかの何百もの投稿の下に埋もれてしまい、フィードのアルゴリズムはすでに別のものを見せようと決めています。WALLAWHATS は、本当に依存している少数のアカウントを、投稿された瞬間に届く WhatsApp アラートに変換します。自分から探しに行かなくても、シグナルの方から届きます。

ツール関連のニュースが今も X で最初に出る理由

ドキュメントサイトや changelog、ステータスページは「何が出荷されたか」の記録です。一方 X は、それを出荷した本人が最初にそう発言する場所です。PR がドキュメントのビルドにマージされる前、RSS フィードが更新される前、ときにはステータスページが「稼働中」から「一部機能低下」に変わる前に、です。フレームワークのメンテナーはリリース候補版（RC）の最中に破壊的変更の事前告知を投稿します。クラウドプロバイダーのステータスアカウントは、正式なポストモーテムのずっと前に、数分以内に障害の第一報を投稿します。DevRel チームはカンファレンスで非推奨化を予告し、その日のうちに X でフォローアップします。

これらはどれも非公開情報ではなく、すべて公開情報です。問題はアクセスできるかどうかではなく、タイミングでした。正しい瞬間に、正しいリストを、正しい時間帯に見ている必要があったのです。アカウントごとの WhatsApp アラートは、このタイミングの問題を解消します。フィードを監視するのではなく、投稿の方からあなたを見つけてくれます。

フォローする価値があるのは誰か

業界全体をフォローする必要はありません。見逃すと実際に時間やお金を失うことになる、ひと握りのアカウントだけをフォローすればよいのです。まずは次のカテゴリーから検討してみてください。

基盤にしているフレームワークやライブラリ。 メインの言語やフレームワーク、そしてプロダクトが機能しなくなる 2〜3 個の依存ライブラリの、メンテナーや公式アカウントです。破壊的変更の通知、RC の発表、セキュリティ勧告が最初に届く場所です。

クラウドおよびインフラのプロバイダー。 スタックが動いているクラウドプロバイダー、CDN、データベース、決済プロセッサーのステータスアカウントです。自分のコードの問題なのか相手側の問題なのか、ダッシュボードを見ながら悩んでいるまさにそのときに届く障害の投稿には、大きな価値があります。

ステータス専用アカウント。 一般的なプロバイダーアカウントとは別に、主要なインフラベンダーの多くは、障害と復旧だけを投稿する専用のステータスハンドルを運用しています。マーケティング用のフィードよりもはるかにシグナル対ノイズ比の高いアカウントです。

DevRel やプラットフォームのチーム。 開発者に「何が変わったか」を伝えることそのものが仕事の人たちです。リリースノートや移行ガイド、「これから来るもの」のスレッドを、一般に広まる何日も前に投稿します。

リストは短く、具体的に保ちましょう。自分のスタックに関係するひと握りのアカウントの方が、結局はフィードをスクロールする問題を再現してしまう広範な「テック Twitter」リストよりも優れています。

実際に捕まえたいもの

リリース。 メジャーバージョンの新登場、セキュリティパッチ、待ち望んでいた機能。出荷された瞬間を知っていれば、コワーカーから 3 週間遅れで聞くのではなく、自分のスケジュールでテストや移行を開始できます。

障害。 依存しているサービスが機能低下したとき、それを運用しているアカウントは、自動化されたステータスページが追いつく前、そして自分たちの監視がその先で何かおかしいと気づくよりも前に投稿するのが普通です。ここでの WhatsApp アラートは、「自分のコードのせいではない」ことを示す最初のサインになり得ます。

非推奨化と破壊的変更。 これらにはサンセット日や移行期限といった、時計が付いてきます。6 週間の猶予期間の初日に知るか、3 週間目に知るかの違いは、落ち着いた移行になるか、慌てて対応することになるかの分かれ目です。

セットアップ方法

1. 無料アカウントを作成します。 wallawhats.com/signup から、クレジットカード不要で登録できます。
2. 依存している X アカウントを追加します。 ダッシュボードの購読フォームにハンドル名を（@ なしで）入力します。フレームワークの公式アカウント、クラウドプロバイダーのステータスハンドル、移行ノートを投稿する DevRel リードなどです。
3. WhatsApp 番号を確認します。 WALLAWHATS は、配信先が本当にあなたのものであることを確認するためにワンタイムコードを送信します。それが完了するまで何も配信されません。他人の WhatsApp があなたのアラートを受け取ることはなく、あなたが他人のアラートを受け取ることもありません。
4. これで完了です。 それらのアカウントの新しい投稿は、X 上で一般公開された瞬間から数秒以内に WhatsApp に届きます。

Free プランは、監視対象の X アカウント 2 件と月 3 件のアラートをカバーしています。1 つのフレームワークと 1 つのステータスアカウントを試すには十分です。有料プランではアカウント数と月間アラート数がそこから拡張されます。詳しくは料金ページをご覧ください。

API で購読を自動化する

チームのために購読を管理していたり、依存関係のリストを package.json や requirements.txt の実態と同期させたい場合、WALLAWHATS はすべてのプラン（Free を含み、API キー 1 個付き）で REST API を公開しています。

認証には x-api-key ヘッダーを使います（Authorization: Bearer ではありません）。

curl -X POST https://api.wallawhats.com/subscriptions \
  -H "x-api-key: your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{"xUsername": "vercel"}'

小さなスクリプトを使えば、購読リストを実際の依存関係グラフと突き合わせて正しく保つことができます。

const axios = require('axios');

const API_KEY = process.env.WALLAWHATS_API_KEY;
const BASE_URL = 'https://api.wallawhats.com';

async function listSubscriptions() {
  const { data } = await axios.get(`${BASE_URL}/subscriptions`, {
    headers: { 'x-api-key': API_KEY },
  });
  return data;
}

async function addSubscription(xUsername) {
  await axios.post(
    `${BASE_URL}/subscriptions`,
    { xUsername },
    { headers: { 'x-api-key': API_KEY } }
  );
  console.log(`Now watching @${xUsername}`);
}

async function removeSubscription(xUsername) {
  await axios.delete(`${BASE_URL}/subscriptions/${xUsername}`, {
    headers: { 'x-api-key': API_KEY },
  });
  console.log(`Stopped watching @${xUsername}`);
}

// Reconcile the watch list against a source-of-truth array of handles —
// e.g. one derived from your infra providers + primary framework.
async function reconcile(targetHandles) {
  const current = (await listSubscriptions()).map((s) => s.xUsername);

  for (const handle of targetHandles) {
    if (!current.includes(handle)) await addSubscription(handle);
  }
  for (const handle of current) {
    if (!targetHandles.includes(handle)) await removeSubscription(handle);
  }
}

reconcile(['vercel', 'awshealth', 'nextjs']);

GET /notifications を定期的に呼び出せば、簡易的な監査ログも手に入ります。チームが受け取ったすべてのアラートの配信状況を含むページネーション済みのログで、「非推奨通知を本当に誰かが見たか」を確認したいときに便利です。

障害の連続投稿でも 30 回通知されない仕組み

ステータスアカウントは一度だけ投稿するわけではありません。進行中の障害では、数分おきに更新を投稿します。調査中、監視中、解決、フォローアップといった具合です。そのすべてが別々の WhatsApp メッセージとしてスマホに届いてしまうと、まさにシグナルが最も必要なときにアラートがノイズになってしまいます。

WALLAWHATS はこれを、直近 60 分のローリングウィンドウにおけるユーザーごとの速度上限で解決しています。上限内の最初の投稿はすぐに届きます。それを超えた分はダイジェストにまとめられ、15 分ごとにアカウントごと 1 通のメッセージとしてまとめて配信されるので、速いペースで進む障害のスレッドが通知の洪水になることはありません。

障害が始まった瞬間の最初のアラートは、それでも必ず届きます。上限がかかるのは、個別に通知を受け取っても現実的に意味がないほどの速さでアカウントが投稿を続ける場合だけです。

具体的なシナリオ:破壊的変更が main に入る前に捕まえる

ビルドパイプラインが依存しているフレームワークが、設定フォーマットに文書化された破壊的変更を含むリリース候補版を出荷したとします。メンテナーは RC が出た当日に X で投稿しますが、移行ガイドはまだ公開されておらず、changelog のエントリがマージされるのはあと 1〜2 日先です。

そのアカウントを購読していれば、投稿が公開された数秒後には WhatsApp にアラートが届きます。2 行の要約を読み、調べる価値があると判断し、スマホからリンク先のスレッドを開きます。その日の午後、チームメイトが RC をフィーチャーブランチに取り込む頃には、すでに設定変更が来ることを知っていて、後になって謎のビルド失敗をデバッグする代わりに、レビューの段階で指摘できます。タイムラインを更新し続ける必要は一切ありません。アラートがその「監視」を代わりにやってくれます。

同じパターンは障害でも逆方向に働きます。クラウドのステータスアカウントが「エラー率の上昇を調査中」と投稿する一方で、自分たちの監視はまだ正常なしきい値の範囲内、ということがあります。その数分のリードタイムがあれば、自分たちのアラームが鳴る前に、依存しているサービスのチェックを始めるのに十分なことが多いのです。

バックアップチャネルとしてのメール、そして視覚的な記録

WhatsApp は最速の経路ですが、Free を含むすべてのプランはメールへの配信にも対応しており、チャネルは排他的ではありません。両方を有効にすれば、どの購読からのアラートも、確認済みのすべての配信先に一斉に届きます。あるハンドルは WhatsApp へ、別のハンドルはメールへ、といったアカウントごとのルーティングはありません。チャネルごとのグローバルな ON/OFF だけなので、ひと握りのインフラアカウントを監視するときのセットアップがシンプルなままです。

メールのアラートには、WhatsApp にはない要素が 1 つあります。投稿そのものをレンダリングしたスナップショットが、メッセージにインラインで含まれることです。このスナップショットはダッシュボード上の 30 日間検索可能なギャラリーにも残るので、メンテナーが発表後に投稿を編集したり削除したりした場合(速く動く障害対応の周辺では、思っている以上によく起きます)でも、アラートが届いた時点のバージョンをそのまま確認できます。数日後に「ステータスアカウントが 14:32 に正確に何と言っていたか」を参照する必要がある人にとって、X 自体の編集・削除履歴に頼らずに済むのは便利です。

チームが実際に見たものを監査する

一人の開発者にとって、アラートは読まれたか読まれなかったかのどちらかです。しかしチームにとって、「誰かが非推奨通知を見たか」は現実的な問いであり、それにまさに答えてくれるのが GET /notifications です。チャネルごとの全アラートのページネーション済みログで、ステータスは queued、sent、delivered、read(WhatsApp のみ、受信者が既読通知を有効にしている場合に限る)、failed のいずれかです。

curl "https://api.wallawhats.com/notifications?from=1758412800000&to=1758499200000" \
  -H "x-api-key: your_api_key_here"

これを定期的に取得すれば、あるリリースや障害についてチームが実際にいつ通知を受けたか、そしてそのメッセージが実際に配信されたかどうかの、簡易的な記録が手に入ります。誰かが投稿を見た「はず」という推測よりも、監査記録に近いものです。

これが代替しないもの

WALLAWHATS は監視ツールやステータスページの代替品ではなく、サービスを運用している当事者の発言をより速く聞くための手段です。既存のアラート体制(PagerDuty、稼働監視、ログベースのアラーム)を置き換えるのではなく補完するものです。ステータスアカウントからの WhatsApp アラートは、自分たちのスタックに関する確定した障害報告としてではなく、調べる価値のある早期シグナルとして扱ってください。また、公開されている X API を通じて動作しているため、そのアカウントが公に投稿した内容しか見えません。非公開の情報やログインの背後にある情報は一切見えません。

さらに自動化を進めたい場合は、X Alerts API ガイドでエンドポイントの全体像を確認できます。ステータスページ以外にもイベントの多いアカウントが気になる場合は、Avoiding Alert Stormsでダイジェストのバッチ処理の仕組みをより深く解説しています。競合他社や投資家など複数の相手から「シグナルが多すぎて注意が追いつかない」という似た課題を抱えている創業者には、X Monitoring for Startup Foundersも参考になるはずです。

重要な投稿をもう二度と見逃さないために。 無料アカウントを作成 — WhatsApp 番号 1 件、リアルタイムアラート、クレジットカード不要です。