そういえば、書く場所へは共有できなかった。Qiita・Zenn・note・Medium・アメブロへの共有ボタンを足しました

何を試験したか

最後のページでは、今回の変更をどう確かめ、どうやって読者の画面まで届けるかを見ていきます。共有欄は、すべての記事の下に並ぶ部品です。1つ壊れると、すべての記事で共有ができなくなります。足すことより、壊さずに届けることのほうに、手間をかけています。

試験は、層ごとに役割を分けています。ふるいを3段重ねて、段ごとに違う大きさの粒を落とすようなものです。

いちばん上の段、TypeScript の試験では、ブラウザがなくても動く部分を確かめます。3ページ目で見た composeDraft が、共有先ごとのひな形どおりに下書きを作ること、アメブロの URL が 3,500 文字を超えないこと。ユースケースが、クリップボードへの書き込みとタブを開く処理を、この順番で、待たずに呼ぶこと。書き込みが失敗しても、タブを開く処理が呼ばれること。本物のブラウザの代わりに、呼ばれた順番を記録するだけの代役を渡して確かめています。

2段目の Python の試験は、4ページ目で見た生成器の検査です。正しいカードが通り、http の URL や空の [params] で止まることを確かめます。3段目の PHP の試験は、WordPress のプラグインが、ページの HTML に共有先の URL を書き出していないことの確認です。このプラグインでは、共有の URL はすべてブラウザ側で組み立てる約束なので、サーバーの出力に qiita.com や zenn.dev の URL が紛れ込んでいないかを見ています。

そして最後に、ふるいの下の受け皿として、本物のブラウザ（Playwright）で、1440・390・320ピクセルの3つの幅に共有欄を描き、4ページ目の「はみ出さない」ことと、実際にボタンを押したときの順番と知らせを確かめました。

一方で、まだ確かめていないことも書いておきます。新しいタブへ焦点が移ったあとに、どれくらいの割合でクリップボードへの書き込みが断られるかは、確かめていません。ログインした Chrome で5つを押したときは断られませんでしたが、1回ずつの確認で、Safari はまだです。試験で使ったブラウザは、自動で動かすための環境で、読者のふだんのブラウザと同じ条件ではないからです。断られても投稿画面は開き、失敗の知らせが出る作りにはしてありますが、実際の割合は、公開してから見ていきます。

もう1つ、試験の途中で、今回の変更とは別の、以前からの不具合も見つかりました。open の共有先を小窓で開く設定のとき、小窓と新しいタブの2つが開いてしまう、というものです。窓を開けたかどうかの判定に使っていた値が、noopenerを付けると、いつも「開けなかった」になってしまうのが原因でした。今回の compose はこの値を使っていないので、影響はありません。範囲を広げずに、別の Issue（promari-toolkit#31）に記録して、あとで直すことにしました。

レイヤードと SOLID の目で、もう一度見直す

試験がすべて通ったあとで、もう1つ確かめたことがあります。今回の変更が、この部品の設計の約束を守っているかどうかです。この部品は、役割ごとに層を分けるレイヤードアーキテクチャと、ドメイン（決まりごと）を中心に置く DDD（ドメイン駆動設計）の考え方で作っています。さらに、本編の連載の第2章で読んできた SOLID の5つの原則も、設計の物差しにしています。試験が通ることと、設計の約束を守ることは、別のことです。そこで、変更したコードを、この物差しで1つずつ見直しました。

1つ目は、3ページ目の「ボタンとして描く」の節で見た、操作ごとの表の話です。最初の実装では、円い表示と既定の表示の2つのファイルに、「copy・native・compose ならボタン」という判断が、それぞれ書いてありました。どの操作をボタンで描くかは、操作の意味から決まるドメインの知識で、表示の層が持つものではありません。しかも同じ判断が2か所にあると、次に操作を足すとき、片方だけ直し忘れる危険があります。そこで、判断をドメイン層の表1つにまとめ、表示の層は値を読むだけにしました。表示の層が操作の種類を読んでいないことは、構造を調べる試験でも確かめています。

2つ目は、窓を開く約束の分け方です。最初の実装では、小窓を開く既存の約束（ShareWindowGateway）に、新しいタブを開く口を1つ足していました。けれど、この2つは約束の中身が違います。小窓は「開けたかどうか」を返し、開けなければリンクの遷移へ戻せます。新しいタブはnoopenerで開くので、開けたかどうかが分かりません。性質の違う2つを1つの約束に入れると、小窓しか使わない試験の代役にまで、新しいタブの口を書かせることになります。これは、使わない機能への依存を求めないという、インターフェース分離の原則（ISP）に反します。そこで、新しいタブのための約束を別に分けました。

3つ目は、コピーする文の置き場所です。最初は、クリックで何をするかを判断するサービスに置いていましたが、そうすると手順の層が「compose なら文を作る」と操作の種類で分岐することになりました。共有 URL を組み立てる関数と同じく、共有先が自分の操作に合わせて答える形にすれば、呼ぶ側は分岐せずに済みます。そこで共有先の値オブジェクトへ移しました。

4つ目は、直さなかった点です。手順の層は、操作の種類で分岐（switch）しています。開放閉鎖の原則（OCP）の考え方では、種類を足すたびに分岐を書き足すのは避けたい形です。ただ、この部品では、操作の種類を増やすことを「別の判断として扱う」と ADR で決めていて、操作の種類は閉じた集合です。共有先のように自由に増えるものではありません。そこで、分岐をやめて小さなクラスに分ける（Strategy）のではなく、分岐のまま、書き漏れがあればコンパイルで止まる検査（never による網羅の確認）を足すことにしました。原則は、守ること自体が目的ではなく、変わるところと変わらないところに線を引くための道具です。変わらないと決めたところにまで抽象を挟むと、読む場所が増えるだけになります。

見直しの判断を、設計のコメントとしても残しておきます。試験が通ったあとで、設計の約束を守っているかを見直す。動くことと、よい形であることは、別々に確かめる必要があるのです。

配布物には、封蝋の指紋を付ける

試験が通ったら、次は配布です。promari.jp は、共有ボタンのプログラムを、自分のサーバーではなくCDNから読み込んでいます。そのとき、プログラムが途中で書き換えられていないことを確かめる仕組みとして、SRIを使っています。

SRI は、昔の手紙の封蝋のような仕組みです。配布するプログラムのファイルから、sha384 という方法で指紋（ハッシュ）を計算し、その指紋を、サイトの設定にも書いておきます。ブラウザは、CDN から届いたファイルの指紋を自分でも計算し、設定に書いてある指紋と比べます。1文字でも中身が違えば、指紋はまったく別の値になるので、ブラウザは読み込みません。CDN が乗っ取られても、途中で誰かが中身をすり替えても、書き換えられたプログラムが動くことはありません。

[cdn]
version = "4.2.2"
url = "https://cdn.jsdelivr.net/gh/tamito0201/promari-toolkit@promari-sns-share-v4.2.2/plugins/wordpress/promari-sns-share/dist/promari-sns-share.min.js"
integrity = "sha384-lHspYl3Ku6AAPhZUTPXFbhb6UgJpM1m488HXGrwoNt7NqiOFxBebwoerdN1y2+g/"

今回、設定の integrity を新しい版の指紋に書き換えました。実はこの指紋、一度書いたあとで、もう一度書き換えています。次の節で見る「層の見直し」でプログラムを直したので、配布物の中身が変わり、指紋も変わったからです。1文字でも変われば指紋が変わるという SRI の性質を、自分の手で確かめた形になりました。書き換えるとき、プラグインの PR が報告した値をそのまま写すのではなく、PR のブランチにある配布物のファイルから、手元で指紋を計算し直して、一致することを確かめています。指紋は、写し間違えても誰も気づかない値です。写すのではなく、元のファイルから計算し直して比べる。それが、指紋を扱うときのいちばん確かな方法だと思います。4.2.0 でも同じように、CDN から取得したファイルの指紋を手元で計算し、設定の値と一致することを確かめてから書き換えました。

4.2.2 では、指紋だけでなく URL の形も変わりました。プラグインを置くリポジトリ（promari-toolkit）の中で、WordPress 向けの部品が plugins/wordpress/ という分類のフォルダへ移ったため、URL の途中が plugins/promari-sns-share/ から plugins/wordpress/promari-sns-share/ になっています。タグを付けた時点のファイルは動かないので、4.2.1 までの版を指している URL は、今も同じ場所で開けます。2026年10月6日に、4.2.0 の URL が今も 200 を返すこと、4.2.2 の URL から取得したファイルの指紋が、リリースの記載とサイトの設定の値に一致することを、手元で計算して確かめました。

また 4.2.1 からは、リリースに、配布物の SHA-256 を並べた checksums.txt と、その署名（cosign）、配布物に同梱した部品の一覧（SBOM）も添えています。SRI が、読者のブラウザが読み込むたびに行う照合だとすれば、こちらは、配布物を取り込む人が手元で照合するための控えです。指紋を、届く場所ごとに用意しておく形になりました。

ちなみに、新しい5つのアイコンと CSS、compose の処理が加わったことで、配布物の大きさは 116.7KB から 125.0KB になりました（1KB＝1,000バイト）。圧縮して届けたときの大きさは 31.1KB から 34.7KB です。4.2.0 では、下書きのひな形とアメブロのカードの HTML が加わり、129.1KB（圧縮して 36.1KB）になりました。不具合を直した 4.2.2 は、129.6KB（圧縮して 36.3KB）です。

公開は、下の段から1段ずつ

配布の準備ができたら、いよいよ公開です。ここで大事なのが、公開の順番です。

上の CDN の URL を、もう一度よく見てください。URL の中に promari-sns-share-v4.2.2 という文字が入っています。これはプラグインのリポジトリに付けるタグの名前で、CDN は、このタグの付いた時点のファイルを配ります。つまり、タグを公開するまで、この URL にはファイルが無いのです。この記事を書き始めた2026年10月1日の朝、v4.1.0 のタグを公開する前にその版の URL を開くと、404（ファイルが無い）が返ってきました。

もし順番を間違えて、タグを公開する前にサイトの設定だけを本番へ出してしまったら、どうなるでしょうか。ブラウザは CDN からプログラムを読み込もうとして 404 を受け取り、共有ボタンの部品そのものが動きません。すべての記事の下から、共有欄が消えてしまいます。そこで、公開は次の4段の順に進めます。

プラグインの変更と、サイトの設定の変更を、別々の PR にしたのはこのためです。1つの PR にまとめると、「タグの公開を待ってからマージする」という順番を守りにくくなります。PR を分けて、サイトの設定の PR の説明に「タグの公開のあとでマージする」と書いておけば、誰がマージの判断をしても、順番を間違えにくくなります。

今回は、この4段を、2026年10月1日のうちに1段ずつ上りきりました。タグを公開したあとで CDN の URL が 200 を返すこと、届いたファイルの指紋が設定と一致することを確かめてから、サイトの設定を切り替えています。この記事の下の共有欄にも、Qiita・Zenn・note・Medium のボタンが並んでいます。アメブロは「その他」の中です。

4.2.0 でも、同じ4段を同じ順に上りました。プラグインの PR（promari-toolkit#32）をマージし、v4.2.0 のタグを公開して、CDN が 200 を返し指紋が一致することを確かめてから、サイトの設定の PR（programming-mariage-wp#181）で CDN の版と指紋を切り替えて、本番へ配備しています。

4.2.1 からは、2段目の作業がワークフローに変わりました。版を上げる変更をマージすると、リリースのワークフローが、試験・配布物の組み立て・署名から、タグとリリースの作成までを順に進めます。人が手で順番を守る段が1つ減ったわけですが、3段目の「タグの公開を待ってから、サイトの設定をマージする」は変わりません。4.2.2 も、2026年10月5日（日本時間）にリリースが出て、CDN が 200 を返し指紋が一致することを確かめてから、サイトの設定の PR（programming-mariage-wp#185）で版・URL・指紋を切り替えています。

版の番号を、4.1.0 にした理由

公開の順番の話が出たので、版の番号の決め方にもふれておきます。今回の新しい版は 4.0.0 から 4.1.0 にしました。この番号には意味があります。

このプラグインの版の番号は、「大きな変更.機能の追加.修正」の3つの数字でできています。いちばん左の数字が上がるのは、これまでの使い方が通らなくなる変更（互換性を壊す変更）をしたときです。真ん中の数字が上がるのは、これまでの使い方はそのまま通るうえで、新しい機能を足したとき。いちばん右の数字は、不具合の修正だけのときです。

今回の変更は、共有先と compose という動きを足しましたが、これまでの設定ファイルは1文字も直さずに通ります。3ページ目で見たとおり、知らせの文言に既定値を持たせたのも、そのためでした。だから、真ん中の数字を上げて、4.1.0 です。版の番号を見ただけで、「新しい版に上げても、今の設定は壊れない」と分かるようにしています。

## 4.1.0

### Added

- Destinations for writing about the article: `note`, `qiita`, `zenn`, `medium`, and `ameba`
  (Ameba Blog). Logos come from simple-icons 16.33.0 (CC0 1.0). None is enabled in the example
  configuration; add them to `share.destinations` or `share.secondary`.

変更の記録（CHANGELOG）には、足したものと変えたものを、版ごとに英語で書いています。上の抜粋の最後の文は、「設定例では、新しい共有先はどれも有効にしていないので、使うなら share.destinations か share.secondary に足してください」という意味です。プラグインは新しい共有先を用意するだけで、並べるかどうかは使う人が決める。4ページ目で見た「動きはプラグイン、並べ方はサイト」という分け方が、ここにも表れています。

4.2.0 も、同じ考え方で真ん中の数字を上げました。下書きのひな形は、カードに書かなければ使われない任意の項目で、これまでの設定ファイルはそのまま通ります。ただし、コピーの知らせの既定の文言は、Medium が URL だけをコピーするようになったのに合わせて、「記事のリンクをコピーしました。投稿画面に貼り付けてください」に変えました。知らせの文言を設定に書いていないサイトでは、表示される文が変わります。この違いは、変更の記録（CHANGELOG）の 4.2.0 の欄に書いています。

そのあとの 4.2.1 と 4.2.2 は、右の数字だけを上げました。4.2.1 は作り方と出し方（リリースの仕組み）だけを変え、部品の動きは 4.2.0 と同じです。4.2.2 は不具合の修正で、正しい設定での表示は変わりません。直したのは、4ページ目で見た知らない共有先の名前のほか、config 属性で、既定の設定に無い共有先（たとえばはてなブックマーク）のボタンの色や名前を上書きすると、その上書きが捨てられていたことです。

もう1つ、サーバー側の直しもあります。WordPress のプラグインは、記事以外のページ（一覧など）で共有する URL を組み立てるとき、リクエストに付いてくる Host という項目（どのドメインあてのリクエストか）を使っていました。Host は送る側が自由に書けるので、偽の Host でページを開かれ、その結果がページのキャッシュに残ると、ほかの読者の共有リンクに偽のドメインが入るおそれがありました。4.2.2 からは、WordPress に設定されたサイトの URL（home_url()）とリクエストのパスから組み立てます。送る側が書き換えられる値を、こちらが配る URL の材料にしない、という直しです。

そして、公開の順番についての判断も残しておきます。プラグインとサイトの設定は、別々の PR にして、順番に出す。変更を小さく分けるのは、レビューしやすくするためだけでなく、出す順番を守りやすくするためでもあります。

押された回数は、行き先ごとに数える

最後に、新しいボタンがどれくらい使われるかを、どう数えるかです。

共有ボタンが押されると、部品は「どの共有先が、どの場所で押されたか」を知らせる合図（promari-sns-share というイベント）を出します。合図には、共有先の名前（destination）と、共有欄の置き場所（placement）が入っています。サイトの計測のコード（analytics.js）がこの合図を受け取り、GA4へ share というイベントとして送ります。GA4 では、method という項目に共有先の名前が入るので、qiita・zenn・note・medium・ameba ごとに、押された回数を数えられます。

今回、この計測のコードは変えていません。計測のコードは、共有先の名前が「英小文字で始まる、決まった形の文字」であるかだけを確かめていて、名前の一覧を持っていないからです。名前の一覧を持たないから、共有先が増えても直さなくてよい。2ページ目で見た URL を組み立てる関数と同じ考え方が、計測の側にもありました。

ただし、数えられるのは「ボタンが押された」ところまでです。押したあと、読者が本当に Qiita で記事を書いたか、書いた記事を公開したかは、こちらからは分かりません。compose なら、コピーに成功したかどうかまでは部品が知っていますが、その先はサービスの中の出来事です。押された回数を、書かれた記事の数と取り違えないように、数字を読むときは気をつけたいと思います。

公開したあとに、確かめること

階段を上りきって、本番に新しいボタンが並んだら、それで終わりではありません。公開したあとに確かめることを、順番に並べておきます。

とくに大事なのは、4行目の実機での確認です。1ページ目でお話ししたように、compose で開く投稿画面の URL は、サービスが公式に用意した入口ではありません。今日は開けても、サービスの作り替えで、明日には 404 になるかもしれません。Zenn の articles/new が、まさにそうだったように。

そこで ADR-0003 には、この判断を見直す条件を書いておきました。

ADR-0004 にも、アメブロの投稿画面が entry_title と entry_text を読まなくなった、ログインした読者から 400 の報告が出た、Qiita・Zenn・Medium のカードの書き方が変わった、という見直す条件を書いています。どれも、こちらからは予告を受け取れない変化です。

見直す条件を先に書いておくと、「いつ直すべきか」を迷わずに済みます。決めたことと一緒に、決め直すきっかけも残しておく。ADR を書くときに、いちばん役に立つ欄だと思っています。

まとめ

今回は、「そういえば、書く場所へは共有できなかった」という小さな気づきから、Qiita・Zenn・note・Medium・アメブロの5つを共有先として足した話をしました。最後に、読者の手元で何が変わるのかを、3コマの漫画にしてみました。

記事を読んで、「これは紹介したい」と思う。共有欄の Zenn のボタンを押す。開いた投稿画面に貼り付けて、書き始める。これまでは、2コマ目と3コマ目のあいだに、「URL をコピーして、Zenn を開いて、新しい記事の画面を探す」という手間が挟まっていました。読み終えた気持ちが冷める前に、書く画面まで1回で連れて行く。今回足したのは、その近道です。

振り返ると、今回の変更でいちばん時間を使ったのは、コードを書くことではなく、「無い」を確かめることでした。5つのサービスに入口があるかを1つずつ開いて確かめ、無いと分かったものには、無いなりの動きを考えました。Zenn の新しい記事の画面の URL が 404 だったように、確かめてみなければ分からないことは、思っていたより多くありました。

そしてもう1つ、「共有先を1つ足すとき、1ファイル足すだけで済む」という、以前に決めた作りが、今回ちゃんと効いたことも嬉しい発見でした。note はカード1枚で足り、compose の共有先も、動きを1つ足したあとは、それぞれカード1枚です。4.2.0 で「貼るとカードになる」書き方を足したときも、共有先ごとの違いはカードに書き、コードには共有先の名前を1つも書いていません。計測のコードも、URL を組み立てる関数も、共有先の名前を知らないから、直さずに済みました。設計の判断は、それが本当に効いたかどうかを、こうして後から確かめられるのが面白いところです。

この記事の下の共有欄に、新しいボタンが並んだら、ぜひ使ってみてください。Qiita や Zenn で「この記事を読んで試してみた」と書いていただけたら、とても嬉しいです。気づいた点や、「このサービスへの共有も欲しい」というご意見も、コメントでお待ちしています。

共有ボタンの部品の成り立ちは、本編のiframe から、丸型の共有ボタンと「いいね」へ。Promari SNS Share を公開しました。で、共有先をデータのカードで持つ理由は連載の2.2「OCP――共有先を一つ足したときの差分を追う」で、ブラウザの機能を約束の向こうへ置く作りは2.5「DIP――ブラウザの機能を、ポートの向こうへ置く」で詳しく読めます。連載の全体は、本編5ページ目の連載の目次からどうぞ。

プロマリでは、Webサイトの制作に加えて、共有や計測のような「裏側のしくみ」の設計・導入、それらを運用できる人材の育成に取り組んでいます。自社のサイトの共有ボタンや計測を見直したい方も、お気軽にご相談ください。

Web制作・計測・人材育成のご相談はこちら ↗