自前実装 vs SaaS、あなたはどちらを選ぶ？Qiitaの「PUSH ONE」活用術と、SaaSが生み出す開発体験
Web Pushの実装、あなたのチームはどう判断していますか？「技術的には自分たちで作れる」そう感じているエンジニアは少なくないはずです。しかしQiitaのPMである清野さんは、調査を重ねた末にSaaSを選びました。その意思決定の裏側と、3年以上使い続けて見えてきた本質的な価値、PUSH ONE開発者の芋田さんとともに、エンジニア目線で語っていただきました。
目次
プロフィール
「自前実装 vs SaaS」Qiitaの意思決定
―― まず始めに、QiitaがWeb Pushを検討したきっかけを教えてください。
清野：検討しはじめた当時のQiitaでは、検索からの自然流入は多い一方で、1記事読んだら離脱してしまうケースが多く、再アプローチが難しいという課題を抱えていました。その課題を解決する方法を検討した結果、Web Pushでオプトインしてもらえれば継続的に接点を持つことができて、新しいリテンション施策になると考えたのがきっかけです。
もう1つの理由として、当時はユーザーへの連絡チャネルがメールしかなかったことも挙げられます。頻繁にメールを送るのはUXとしてあまり良くないですが、Web Pushであればよりカジュアルにユーザーと接点を持てるため、新しいチャネルとして検討しました。まずは小さく始める前提で、Web Pushの技術検証やサービスリサーチを行いました。
―― 自前で実装する方法もある中でSaaS、中でも「PUSH ONE」をなぜ選んだのでしょうか。
清野：Web Pushを行う上で、「（エンジニア以外の）ビジネスメンバーが運用に介在できる体験を作りたい」という大前提がありました。 自前で実装する場合、シンプルなAPIなら簡単に作れます。しかし「特定のユーザーに絞る」「属性で送り分ける」「配信頻度を制御する」などの設計をすると、途端にシステムが重厚になってしまいます。「内製する工数やコストをかけるより、SaaSでコスパよく運用した方が良い」と判断して複数サービスを比較しました。
その後、どのようなサービスがあるかを知るために検索をしたら「PUSH ONE」を見つけました。他のサービスも見てみましたが、検討したのはほぼ「PUSH ONE」だけですね。「PUSH ONE」は、Qiitaに合った料金体系だったため決めました。
他サービスでは「1配信あたり◯円」という従量課金が多かったです。ですがQiitaではコアユーザーのエンゲージメントを高めるために、いいね通知やトレンド通知を「高頻度かつ定常的」に送りたかったので、従量課金とは相性が良くないと思っていました。「PUSH ONE」はオプトイン登録者ベースの課金でしたので、Qiitaのビジネスモデルに合致していた点も大きかったです。
―― 導入にはどれくらいの時間かかりましたか？
清野：調査を含めても1ヵ月弱ほどで実装が完了したと記憶しています。中でも時間を要したのは動作検証ですが、検証さえ完了すれば、あとは定期実行するだけとスムーズでした。ツールを選定する際に気にしていたポイントは、先ほどの料金体系に加えて「システム連携（API）で自動送信できるか」もあったのですが、 全体への一斉通知だけであればタグを埋め込むだけで検証できたので非常にシンプルでした。特定ユーザーへのAPI連携も、既存の自社システムの大幅な改修は不要でしたね。APIキーを発行して、「PUSH ONE」のカスタムキーにユーザーを識別するハッシュ値を紐付けて、そのハッシュ値をもとにAPI経由で配信指示を出すだけで完了しました。
―― メールなど、他の配信手法と比べた際の使いやすさなどはいかがでしょうか。
清野：メルマガだと配信ツール側の仕様やスパムフィルターの兼ね合いなど、送る側が気を揉むポイントが結構多いんですよね。その一方で、Web Pushではブラウザやデバイス側の仕様がはっきり決まっているので、送る側としても安心感があります。使いやすさについてお話しすると、大型イベントの際にはビジネスサイドのメンバーがまとめて通知を設定することもあるのですが、「PUSH ONE」の管理画面はUIが分かりやすいこともあり、スムーズに設定が完了しているとのことです。この運用の手軽さも大きなメリットだと感じています。
QiitaにおけるPUSH ONEの活用
―― Qiitaでは、どのような場面で「PUSH ONE」を使っていますか？
清野：Qiitaにおけるユースケースは、大きく3つあります。1つめは「トレンド更新通知」です。これは、全ユーザーに毎日2回定常配信しています。2つめは「いいね通知」。記事を投稿した方でWeb Pushを有効にしている方に、誰かが記事に「いいね」をしたタイミングで送っています。3つめはイベントの集客・告知です。Qiitaはイベントをよく実施することもあり、Web Pushで案内を届けています。
―― 特に便利だと感じた機能を教えてください。
清野：一番良いと感じているのは、ビジネスサイドのメンバーでも簡単に通知を送れるUI・仕組みが整っている点です。 僕自身、過去にWeb Pushの仕組みを開発したことがあるのですが、裏側の仕組みは決してシンプルではないため、誰でも触れるUIを作ろうとするとかなり骨が折れます。「PUSH ONE」を使っている今では、何かしら配信をしたいと考えているビジネスサイドのメンバーが、エンジニアを通さずに直接管理画面で配信設定ができるようになりました。もし「PUSH ONE」がなければ、毎回エンジニアへの依頼が必要なので、お互い大変だったと思います。
もう1点、配信実績（インプレッション数やCTRなど）が可視化される点も大きいです。トレンド通知やいいね通知はCTRがすべてではなくエンゲージメント向上が目的ですが、イベントなどの集客目的の配信については、他チャネルと効果を比較する指標として非常に参考になります。
―― シグニティが「PUSH ONE」の設計や開発で、特に大切にしていることは何でしょうか？
芋田：一番大切にしているのは「簡単に使えること」です。また、単に通知を送る機能だけでなく、送った後も「継続的に運用ができる状態」を作れることも重視しています。 自前での構築も不可能ではないですが、実際に運用するとなると、ユーザー管理・セグメント管理・効果測定・ブラウザ間の仕様差分吸収など、泥臭くて面倒な開発がたくさん発生します。そのような煩雑な開発をエンジニアが意識せずに運用できるのが「PUSH ONE」の強みです。
また、充実したサポートも意識しています。お客さまがお困りのことがあれば、メールやお電話、チャットツールなど、様々な方法でご相談いただけます。もし導入を担当される方がエンジニア以外の場合でも、スムーズにご対応いただけるようにサンプルのスクリプトもご提供しています。大手新聞社やメディアへの導入実績が多数あることも、セキュリティや安定稼働において、信頼いただいている証拠と考えております。
―― メディアなどのWebサイトは仕様変更もされると思うのですが、その場合も運用はシンプルなのでしょうか？
芋田：はい、ブラウザやOSの仕様が変更されても「PUSH ONE」側で吸収して対応するので、運用される方々はWeb Pushのシステムを改修する必要がありません。 Web Pushの仕組みを自前で開発して維持しつづけるコストを考えれば、それらすべてを「PUSH ONE」に任せられるのは大きなメリットだと思います。エンジニアの方々には、自分たちのサービスのコア機能の開発にリソースを注ぎ込んでほしいという想いもあります。
導入後に見えてきた、変化
―― Qiitaで「PUSH ONE」を導入した後の変化を教えてください。
清野：メールなどと比較して「PUSH ONE」での通知はCTRが圧倒的に高いという実感があります。具体的な数値は伏せますが、定常的に同じユーザーへ送り続けているにも関わらずクリック率が大きく低下していないことは、ユーザーにとって「良い体験」として受け入れられている証拠だと思っています。当初狙っていたエンゲージメント向上とリピート流入の開拓は、しっかり実現できていますね。
またユーザーへの連絡チャネルがメールのみだったときは、メール配信の社内調整が大変でした。具体的には、同じユーザーへ送りすぎないようにする配慮から「どの内容のメールを、どのタイミングで送るか」の検討や、異なる内容で配信希望時期がバッティングした際のハンドリングなどで、調整に手間取っていました。選択肢にWeb Pushが増えたことで「この告知はメール、こちらのイベント告知はWeb Pushでカジュアルに」という切り分けができるようになりました。このように、ユーザーの不快にならないようなマーケティング施策の選択肢が増えたことは、社内的にも、ユーザー体験の向上としても、とても良かったです。
―― ビジネスへのインパクトは何かありましたか？
清野：ビジネスの集客チャネルとして重要なものになってきているなと思っています。元々はリテンション向上が主目的だったのですが、実際に導入してみると管理画面のUIが使いやすくてノンエンジニアでも直感的に配信設定できることが分かりました。また、Androidではリッチなクリエイティブ（画像）をインラインで出せる機能もあると知り、「イベントの集客チャネルにも使えるのでは」とアイデアが広がっていきました。 今ではWeb Push経由でイベントに申し込んでくれるユーザー数も結構います。
芋田：今お話しいただいたように、これまでにお客さまからいただいた相談も、ユーザーのリテンションやエンゲージメントを高めたいというプロダクト観点が多かったです。しかし実際に導入してみると、ビジネス面での様々な施策に使えることが分かってきて、今では重要な「集客チャネル」の一つとして活用してくださるケースが非常に増えています。
ブラウザ仕様変更という「波」と「PUSH ONE」の向き合い方
―― Chromeの通知自動抑制など、ブラウザの通知仕様は変化していますが、現場への影響はありますか？
清野：正直に言うと、ほぼ感じていないです。「PUSH ONE」側で仕様変更の裏側をすべて吸収して対応してくださっているので、僕らが触るAPIやインターフェースが変わらないからだと思います。iOSでWeb Pushが送れるようになったときも、「PUSH ONE」から「こういう設定・対応をすると良いですよ」とアナウンスをいただいていました。Qiita側が気づかないうちにトラブルが起きていたことは、皆無でしたね。
芋田：Web Pushが普及して10年ほど経ちますが、仕様はかなり変わってきています。最初は通知を出せば届いていたものが、ユーザーの許諾をしっかり取る流れになり、最近ではエンゲージメントが低いサイトの通知がブラウザ側で自動ブロックされる仕組みも入ってきました。
僕らはそうした変化を常にキャッチアップして、クライアント企業やエンドユーザーが意識せずとも最適な形で通知が届くようアップデートを続けています。最近はユーザー側の「通知疲れ」も感じるようになってきたので、今後はよりユーザーに配慮した通知設計が求められます。そのような流れに合わせて、「本当にその情報を欲している人だけに適切なタイミングで届ける仕組み（パーソナライズ機能）」の実装を進めているところです。
―― 2026年6月15日よりGoogleが「戻るボタンハイジャック」をスパムポリシー違反として、ペナルティを適用することになりました。ユーザーの離脱を引き止める強引な手法が排除される中で、Web Pushの役割はどう変わると思いますか？
芋田：Web Pushの位置づけは、より重要になってくると思っています。ブラウザ内でのユーザーの行動履歴から「このサイトに興味を持ってくれている」と判断できるユーザーに対して、適切なタイミングでWeb Pushを使って情報を届けるアプローチの価値は今後ますます高まるでしょう。Web Pushを活用すれば、メールアドレスなどの個人情報を収集しなくても、ユーザーへダイレクトに有益な情報を届けられます。強引に引き止めるのではなく、「関係性を深めるためのツール」として活用されていくと嬉しいですね。
清野：Web Pushは「ユーザーの自発的なブラウジングを邪魔しない形」で、後から適切なメッセージを届けられます。配信内容や頻度のガバナンスは必要ですが、パブリッシャー側が伝えたい情報をクリーンに届けられるチャネルとして、より重要な存在になっていくと思います。
これからのWeb Push──エンジニアに向けたメッセージ
―― エンジニアが今後注目すべき動向などはありますか？
芋田：Web Push APIの技術仕様自体はブラウザ側で明確に決まっているので、技術単体で今後何かが飛び抜けて大きく変わることは少ないかもしれません。だからこそエンジニアも「Web Pushという機能」として捉えるのではなく、サービスの「UX設計やユーザーエンゲージメントを高める動線」として捉えると良いかなと思っています。 「どのようにして心地よくオプトインしてもらうか」「どのような情報を届けるか」をサービスのブランディングと一体化させて設計していく視点が、今後は不可欠になっていくと考えています。
―― 導入を検討しているエンジニアへ、一言お願いします。
芋田：Web Pushの仕組みは「単に送る機能」だけでなく、サービスのブランディングやUXの一部です。自前で構築・運用維持するメンテナンスコストやリソースを消費するのであれば、そこは「PUSH ONE」に任せていただき、エンジニアの皆さんには「自社サービスのコア機能の開発」に全力を注いでほしいです。
清野：「PUSH ONE」はスモールスタートがしやすい料金体系（登録者ベースの課金）になっていることもあり、気になっている方や組織には、とりあえず試してみてほしいです。また通知結果の数値データも管理画面からしっかり可視化されるので、「導入したけど効果が分からなかった」となることはまずないと思います。 通知を「受け取る」ことはあっても、「配信を設計する」という経験は、モバイルアプリ開発者でもない限りなかなか得られない貴重な体験です。エンジニアとして経験値を広げる意味でも、まずは触ってみることをおすすめします。