共有・保存・計測は、なぜ同じ責務にしないのか

三つの仕事を、中身から見る

ここからは3つの責務を1つずつ開けて、中身を確かめます。同じクリックから始まるのに、通信の形は3つとも違います。共有は渡したら終わりの一方通行、保存は返事を待つ往復、計測は送る前に同意を確かめる手順です。うまくいかなかったときに起きることも、それぞれ別です。

共有——渡したら終わりの、一方通行

共有の仕事は、渡すところまでです。記事のURLと文言から共有画面のURLを組み立てて、新しいタブで開く。そこから先、読者が実際に投稿したかどうかは、こちらからは分かりません。

実装の根拠：共有先・操作の判断（ShareActionPolicy）

「分からないなら、投稿完了まで追いかける作りにすればいいのに」と思われるかもしれません。ただ、それは各SNSの中の出来事で、こちらの管理の外です。管理の外を追いかける仕組みを足すほど、共有の責務はSNS各社の仕様に深く縛られていきます。この実装では、渡すまでを共有の仕事と割り切ることで、責務の輪郭を細く保っています。

共有先そのものは、次のようなTOMLのデータファイルで宣言されています。共有先1つにつき1ファイルです。責務の話として読むと「共有先の名前・行き先・渡す項目だけがあり、保存や計測の言葉が1つも出てこない」ことが見どころです。

# X（旧Twitter）のポスト画面。
key = 'x'
label = 'ポスト'
brand_color = '#000000'
action = 'open'
endpoint = 'https://twitter.com/intent/tweet'
icon = '<svg …>…</svg>'

[params]
url = 'url'
text = 'text'
hashtags = 'hashtagsCsv'
via = 'via'

保存——返事を待つ、往復

次は保存です。ハートを押したあとの流れを追ってみます。共有との違いは一目瞭然で、こちらは行って、返ってくる。押した事実をサーバーのAPIへ届け、記録された結果として新しい件数を受け取り、その数字で画面を描き直します。

画面の件数が「押した瞬間の想像」ではなく「サーバーが返した結果」から決まる、というのがこの往復の要点です。想像で数字を増やしてしまうと、通信が失敗した夜に、画面と記録がずれたまま朝を迎えます。さらに保存には、同じ人の同じ記事へのいいねを二重に数えないという一意性の決まりも付いてきます。失敗にどう備え、二重をどう防ぐか——この深掘りは連載の保存の章のお楽しみに取っておきますね。

計測——数える前に、確かめる

3つ目の計測は、他の2つと決定的に違う手順を1つ持っています。数える前に、数えてよいかを確かめる。読者が解析への同意をしていなければ、操作は数えず、GA4への通信そのものを行いません。

同意があるときも、送るのは操作の種類だけです。どの記事のURLか、本文に何が書いてあるかは送りません。この抑制は技術の制約ではなく、同意管理という約束ごとの実装です。共有や保存が「動くかどうか」の世界にいるのに対して、計測は「やってよいかどうか」の世界を背負っています。責務として切り離しておかないと、この約束の見直しのたびに、共有と保存のコードまで棚卸しする羽目になります。

分けた部品は、イベントで連絡を取り合う

3つに分けたとなると、今度は連絡の方法が要ります。共有部品が計測のコードを直接呼べば話は早いのですが、それではせっかく切った境目を、呼び出しの線がまたいでしまう。この実装が選んだ連絡手段が、ページ1でも顔を出したイベントです。

実装の根拠：共有イベントの発行（CustomEventShareActivityPublisher）

共有部品は「共有した」と放送するだけで、解析ツールの名前を知りません。放送を聞いた計測のつなぎ役が、同意を確かめ、送ってよい形に言い換えてから解析へ渡します。知らない相手とは縁が切れている、というのが依存の話の要点で、解析ツールを入れ替える日が来ても、共有部品には差分が出ません。