日々タスクに追われるエンジニアにとって、最新化の必要なパッケージがあるかどうか、ひとつひとつ確認するのは骨の折れる作業です😵‍💫 そんなエンジニアの救世主として、依存パッケージの更新を提案するサービスが存在します。 代表的なのは<a href="https://github.com/renovatebot/renovate" target="_blank" rel="noopener noreferrer">Renovate</a>と、今回紹介する<a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot" target="_blank" rel="noopener noreferrer">Dependabot</a>ですね。 エンジニアどうしの宗教戦争に発展するため、これら二つのサービスの比較は他の記事に委ねます...。 本記事ではDependabotの概要と導入・設定方法、一時停止の方法を解説します。 先日わたしはDependabotの停止設定をしたつもりだったのですが、実際にはできておらず、プルリクエストが生成されてしまいました。 その教訓を記事にしておきたいと思います。 <h2 id="h64891b528e">対象読者</h2><ul><li>Dependabot をこれから使うエンジニアさん</li><li>Dependabot をすでに運用中で、設定に関してお困りのエンジニアさん</li></ul> <h2 id="h5b0033b827">Dependabotとは</h2><a style="background-color:#ffffff" href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot" target="_blank" rel="noopener noreferrer">Dependabot</a>(ディペンダボット)は依存パッケージの更新を自動化する GitHub 公式ツールです。 npmだけでなく、Yarn, Maven, Gradle, Pipなどのパッケージ管理ツールにも対応しています。 Dependabotが自動的にパッケージのバージョンをチェック、更新が必要であればプルリクエストを作成してくれます。 開発者はプルリクをマージするだけでパッケージのアップデートが完了。この仕組みなら、忙しい開発者やわたしのような不器用さんでも、こまめにパッケージをアップデートできるというわけです🙆‍♀️ Dependabotをリポジトリに設定すると、GitHub Actions 上に"Dependabot Updates"という専用のワークフローが表示されるようになります。Dependabot は、このワークフローを通して 依存パッケージの自動更新やプルリクエストの生成を行っています。週1実行、自動マージなどの細かい設定は、リポジトリの <code>.github/dependabot.yml</code>（設定ファイル）で実装します。 他にも、ソースコードに含まれる依存パッケージに既知の脆弱性があった場合、GitHub のリポジトリ上で通知する"Dependabot Alert"という機能があります。 有効にすることで、SecurityタブにDependabotの項目が追加され、Dependabot alertsをまとめて確認することができるようになります。 詳細情報も確認できますし、重大度を10点満点中何点程度のなのか示してくれます。 アラートを検知すればメール等で通知してくれますし、Dependabot alertsに関する通知の受け取り方法もカスタマイズできます。 もちろんDependabotによる更新提案の一時停止も可能です。 依存パッケージの管理はDependabotにおまかせして、エンジニアは開発に集中できます。 <h2 id="hff981acc62">Dependabot の基本設定</h2>それではリポジトリでDependabotを有効にする設定をご紹介します。 Dependabotはどのリポジトリでも利用可能です。Githubアカウントも、無料のもので大丈夫です。 設定したいリポジトリで、Settingsタブを選択、"Code security"から"Dependabot"へ移動してください。 "Dependabot version updates"の"Enable”を押すことで、Dependabot によるバージョン更新機能が有効になります。 "Dependency graph"と"Dependabot alerts"も同時に有効にする旨がダイアログで案内されます。ダイアログに従い"Enable"を選択しましょう。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/0be04c0c1cd84a09b2d975da62ab54ef/image.png?w=472&amp;h=194" alt=""> すぐ下のDependabot security updatesも併せてEnableにしておくのがおすすめです。脆弱性検出と修正プルリクを作成してくれます。 わざわざversion updatesとは個別に設定できるようにしてあります。親切ですが、わたしと同様に英語苦手な方は要注意です⚠️ 続いてリポジトリに<code>.github/dependabot.yml</code>を作成します。Dependabot version updatesの横に"Configure"と表示されますので、ここから作成できます。 このワークフローファイルには以下の内容を記載します。<pre><code># To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.

version: 2
updates:
- package-ecosystem: "npm" # See documentation for possible values
&nbsp; directory: "/" # Location of package manifests
&nbsp; schedule:
&nbsp; &nbsp; interval: "weekly"</code></pre> これらはいずれも必須の設定項目です。 <code>package-ecosystem</code>で<code>npm</code> や <code>pip</code>、<code>maven</code> など、Dependabot でサポートされているパッケージ管理ツールを指定できます。 <code>"directory: "/"</code> と指定することで、リポジトリのルートディレクトリ（<code>/</code>）からパッケージ定義を探しに行きます。 <code>schedule.interval</code>はDependabotによるパッケージ更新チェックを定期実行頻度を設定します。<code>daily</code>、<code>weekly</code>、<code>monthly</code>が指定可能です。 平日の月曜日から金曜日まで毎日実行するには <code>daily</code>、週に一度（デフォルトは標準時の月曜）に実行するには <code>weekly</code>、<code>monthly</code>は毎月1日に実行します。 とくにスケジュール設定をしない場合（デフォルト）は Dependabot が実行タイミングを自動（ほぼランダム）で選択します。特定の時刻を設定したい場合は <code>time</code> と <code>timezone</code> を指定することで、Dependabotの実行時間を制御できます。<pre><code>version: 2
updates:
&nbsp; - package-ecosystem: "npm"
&nbsp; &nbsp; directory: "/"
&nbsp; &nbsp; schedule:
&nbsp; &nbsp; &nbsp; interval: "weekly"
&nbsp; &nbsp; &nbsp; time: "09:00"
&nbsp; &nbsp; &nbsp; timezone: "Asia/Tokyo"</code></pre> 月に2000本とかパッケージの更新が走ってしまう方は、さすがにGitHubアカウントの課金が必要するかも...？心配な方はプルリクエストの上限数<code>open-pull-requests-limit</code>を設定して調整しましょう。（参照: <a style="background-color:#ffffff" href="https://docs.github.com/ja/billing/managing-billing-for-your-products/managing-billing-for-github-actions/about-billing-for-github-actions" target="_blank" rel="noopener noreferrer">GitHub Actions の課金について - Github</a>）<pre><code>version: 2
updates:
- package-ecosystem: "npm"
&nbsp; directory: "/"
&nbsp; schedule:
&nbsp; &nbsp; interval: "weekly"
 open-pull-requests-limit: 5 # Dependabotが同時に作成するPull Requestの上限を5件に制限</code></pre> <h2 id="hc2eb0600b8">プルリク生成の流れ</h2><code>schedule.interval</code>で設定したスケジュールでDependabotが更新の必要なパッケージを判定。 更新対象があれば、Dependabot が自動で専用のブランチを作り、<code>package.json</code> や <code>package-lock.json</code>を更新したコミットを作成します。 作成したブランチで、リポジトリに対して新規のプルリクをオープンします。 Dependabot が生成したプルリクは通常のプルリクと同じ扱いです。（承認とマージに関しては、デフォルトブランチに設定されたルールに従います。） <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/4d733642127b4ef9b3f9f3bddb491181/image.png" alt=""> 問題なければ開発者が承認・マージを実施するだけで、パッケージの最新化は完了です🎉 ワークフローファイルで<code>open-pull-requests-limit</code> による制限を設定しており、すでにプルリクが上限に達している場合は、新しいプルリクを作らずにスキップ（待機）します。 既存のプルリクがマージもしくはクローズされるまで新しいプルリクは生成されません。 とくに確認が必要ない場合、自動でマージする設定にもできます。 このページに従ってワークフローファイルに追記してみてください。 <a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions#automatically-approving-a-pull-request" target="_blank" rel="noopener noreferrer">GitHub ActionsでのDependabotの自動化 - GitHub Docs</a> Renovateのデフォルトは自動マージだったような。お好みでどうぞ。 <h2 id="h20d2a21442">一時停止の方法</h2>リポジトリの依存パッケージの更新が多かったり、開発者が忙しく、対応しきれない期間もあるかもしれません。 完全にDependabotの設定を無効にしてもいいですし、Dependabotによる更新を一時停止しておくこともできます。 さきほど紹介した<code>open-pull-requests-limit</code>を0に設定すると、自動でプルリクを作成しないようにできます。<pre><code>version: 2
updates:
&nbsp; - package-ecosystem: "npm"
&nbsp; &nbsp; directory: "/"
 schedule:
 interval: "weekly"
 open-pull-requests-limit: 0</code></pre> 余談ですが、わたしがDependabotを一時停止した理由について。 ホスティングサービスでプルリクブランチを自動デプロイするように設定しており、課金が発生してしまいそうだったからです。 このブログ(trog)はNetlifyというホスティングサービスから公開しているのですが、プルリクを出すと自動でプルリクブランチがNetlifyにデプロイされ、Github上にデプロイ結果が表示されます。 またビルド成功した場合は、できあがったプレビューサイトのリンクを案内するようにしています。 このプレビューサイトはリンクを知っている人なら誰でもアクセス可能です。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/8ea1e22be6b747e08f5ae3fb50ea2351/image.jpg" alt=""> Dependabotとこの自動デプロイ機能のどちらも設定しているリポジトリの場合、毎週Dependabotがプルリクを生成するたび、自動デプロイが走ります。 そのため都度、Netlifyのビルド時間の無料使用枠を消費していきます。 無料枠に余裕のない月であれば、Dependabotを一時停止するか、Netlifyの自動デプロイを一時的に無効にしておくのがおすすめです。 Netlifyさんは優秀ですので、課金が発生しそうになると通知メールを出してくれます。 その様子は<a href="https://microayatron.com/netlify-billing" target="_blank" rel="noopener noreferrer">【微課金】Netlifyから請求がきた | trog</a> で紹介してますので、ご興味のある方はぜひご覧ください。（宣伝） <h2 id="hd496afb8ad">Dependabotを無効にする</h2>停止したいリポジトリの<code>.github/dependabot.yml</code> を削除してください。該当部分をコメントアウトしてもOKです。 実質的にはこれで停止できるのですが、あとから見返してもわかるように、Settingsタブを選択、Code securityからDependabotへ移動して、Dependabot配下の設定をすべて"Disable"にしておくのがおすすめです。 ...というのも、先日SettingsタブからDependabot配下の設定をすべて"Disable"にしたものの、実際にはDependabotは無効になっておらず、ワークフロー定義で Dependabot が呼ばれ、翌週月曜にはいつもどおりに更新が実行されていました。 .github/dependabot.yml をどうにかしないかぎり、プルリクが生成され続けるようです。 <h2 id="h9be0c3393d">おわりに</h2>Dependabotは、エンジニアの開発時間の確保に役立つ強力なツールです🦾 勝手に動いているのでわりと忘れがちなのですが、停止・再開を行う際は GitHub Actions のワークフローにも注意が必要になります。 また依存パッケージが多いリポジトリでは、Dependabotからの通知が頻繁に来ることになります。 プロジェクトを安全に保つためにも、不要なパッケージを削除するなど、依存パッケージを定期的に見直すきっかけになるかと思います。 セキュリティリスクやメンテナンスコストも減らせますので、パッケージを整理して、さらに開発効率を向上させていきましょう🙌 * * * ＜参照サイト＞<ul><li><a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot" target="_blank" rel="noopener noreferrer">Dependabot を使う - GitHub Docs</a></li><li><a href="https://docs.github.com/ja/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions" target="_blank" rel="noopener noreferrer">GitHub ActionsでのDependabotの自動化 - GitHub Docs</a></li><li><a href="https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates#example-disabling-version-updates-for-some-dependencies" target="_blank" rel="noopener noreferrer">Dependabot のバージョン アップデートの設定 - GitHub Docs</a></li><li><a href="https://japan.zdnet.com/article/35208255/" target="_blank" rel="noopener noreferrer">GitHub、「Dependabot」をアップデート--アップデートする依存関係のグループ化が可能に - ZDNET Japan</a></li></ul>

依存パッケージ更新を自動化するDependabotの導入から停止の落とし穴まで、実体験ベースで解説します。

【Github】Dependabotの設定と停止方法

すっかり寒くなりましたね⛄ 当方、現役のWebアプリケーションエンジニアですが、テック系記事を書くのは10か月ぶりです。 2025年はさすがにもっと投稿したい...。 <h2 id="h64891b528e">対象読者</h2><ul><li>Webプッシュ通知に興味を持っているすべての方</li><li>Firebase Cloud Messaging(FCM)の導入を検討されているすべての方</li><li>エンジニアでない方も大歓迎🤗</li></ul><h2 id="h9707d3a59a">概要</h2>この記事ではFirebaseコンソールからWebプッシュ通知を配信する様子を、デモンストレーションしていきます。 Googleが提供するFirebase Cloud Messaging(FCM)は、デバイス間でメッセージや通知を送受信するためのサービスです。iOS, Androidアプリ開発においてもよく使われてますし、もちろんWebプッシュ通知の配信もできちゃいます✌ Firebaseの「新しいキャンペーン」から送信したい内容を入力して、「送信」ボタンを押すことで、PWA（プログレッシブウェブアプリケーション）に、Webプッシュ通知が届く様子をご紹介します。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/bda9a57e13d94bf68dba2084c333607f/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88%202024-12-05%20165654.png" alt=""> <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/006fbe531b2c4c56a9f67ee43d67ef1a/image.jpg" alt=""> エンジニア向けに、Firebaseの設定と実装方法を記した記事は、別途用意する予定です。 厳密にはこの「新しいキャンペーン」画面は、Firebaseコンソールの"Notifications Composer"という名前なんですが、この記事では便宜上「Firebaseコンソール」と呼ばせてください。 （参照: <a href="https://firebase.google.com/docs/cloud-messaging/android/send-with-console?hl=ja" target="_blank" rel="noopener noreferrer">Firebase コンソールでメッセージを送信する&nbsp;|&nbsp;Firebase Cloud Messaging</a> , <a href="https://stackoverflow.com/questions/73173069/where-is-notification-composer-in-firebase-console" target="_blank" rel="noopener noreferrer">Where is Notification composer in Firebase Console? - Stack Overflow</a> ） <h2 id="hc5842cdd9b">Firebaseコンソールに通知内容を入力</h2>Firebaseの“Messaging”から「新しいキャンペーンを作成」を選択します。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/d96eee68efea4cb4801e709a22f7ac29/image.png" alt=""> 「通知の作成」画面が表示されるので、まずは通知内容を入力していきます。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/4b392ad9801b4d0c93e3a510b25dbea2/notification-compose-2024-12-05-17_16_08.png" alt=""> 「タイトル」「画像のURL」「テキスト」を指定できます。 画像そのものを添付することはできないので、どこかのサーバーにあげておく必要があります。(Gyazoとか) プレビューもこの画面で確認できますが、（とくに画像に関して）実機での表示と異なるので、注意が必要です。 これで通知内容の入力は完了したので「次へ」を押します。 配信対象のアプリケーションを選択します。 アプリケーションの作成方法や設定は別の記事で説明する予定です。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/1ecf91c918e348d184381a9230d7d045/image.png" alt=""> 配信スケジュールを設定します。 最後の「公開」ボタンを押したらすぐに配信したい場合は「現在」を、 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/c5d9822bba0445cfa138fbe2c3d9ccc6/image.png" alt=""> 特定の日時を予約しておきたい場合は「設定済み」から、希望の日時を入力します。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/37681028ee2a4b588af8bb8e21154201/image.png" alt=""> なんだか日本語に違和感があります、Google翻訳さんの仕業でしょうか。 あと一息がんばってほしいところです。 キーイベントはマーケターさんから指示があれば入れましょう。 アナリティクス（プッシュ通知の詳細な解析）に役立つ設定なんだと思います。（専門外） <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/597a0265a1ef413a8cf63bb29f134180/image.png" alt=""> その他のオプションですが、なにも入れなくても配信自体は可能です。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/0b8ac01f86b24641a71eae017cdc801c/image.png" alt=""> 専用の実装が必要になりますが、カスタムデータをメッセージとともに送信できます。 trogでは、この設定で決めた場所の記事に、プッシュ通知から直接アクセスできるようにしています。 つまり通知をクリックすると、アプリ内のその記事が開く、ということです。 これでFirebase コンソールから入力はすべて完了です。 「確認」を押すと、入力内容について問題なさそうか、確認ダイアログが表示されます。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/4671a196754b4ae4913a99e72aba22c8/image.png" alt=""> よければ「公開」を押します。 <h2 id="h71bd6a0b07">端末に通知が届く</h2>あらかじめPWA（プログレッシブウェブアプリケーション）をインストールしておいた端末に、プッシュ通知が届きます。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/cc054a48a6294f2fa24c9bac6bf8028f/IMG_2449.png" alt=""> わたしのiPhoneにPWA版trogをインストールしておきました。 iPhoneの通知画面を確認すると... <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/006fbe531b2c4c56a9f67ee43d67ef1a/image.jpg" alt=""> さきほど入力した通知が配信されています！ iPhoneではPWAアイコンが表示されます。（どうもAppleさんの都合なのか、指定方法が異なるのか、画像が表示されない模様。） PCではさきほどURLを入力した画像が、通知に表示されます。 正方形の画像だと下半分が切れてしまいました。 通常、通知配信時は16:9の画像を使っているのですが、それだとちゃんと表示できています。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/3a173176404846b5a3357cb17860a1c7/image.png" alt=""> Android OSでの表示は、後日ブラックフライデーセールで購入したAndroidを使って検証します🧪 今回はプッシュ通知を許可しているすべての端末に対して、この通知が届きました。 2のターゲットから、「アプリ」ではなく、「トピック」を指定することで、そのトピックを購読している端末のみに通知を送信することも可能です。 ただしそのための特別な実装と、Firebase の設定が必要になるので注意してください。 <h2 id="hecb6781aa2">Firebase コンソールで過去の通知を確認</h2>Firebase Cloud MessagingでのWebプッシュ通知配信方法としては他にも、<a style="background-color:#ffffff" href="https://firebase.google.com/docs/cloud-messaging/admin?hl=ja" target="_blank" rel="noopener noreferrer">Admin SDK</a>(ライブラリ Webアプリに実装、アプリの中から通知を送る)や<a style="background-color:#ffffff" href="https://firebase.google.com/docs/reference/fcm/rest?hl=ja" target="_blank" rel="noopener noreferrer">v1 HTTP プロトコル</a>(cURLコマンドやPOSTMAN経由でAPI実行)が用意されています。 細かい設定が可能なメッセージの送信方法ですが、これらはFirebaseコンソール経由の実装とはまた別に、込み入った実装が必要になります。 今回紹介したFirebaseコンソールの最大の魅力は、過去に配信したプッシュ通知の内容を振り返って確認できること、そしてどのくらいのユーザーにプッシュ通知を送信したか、モダンなUIから確認できる部分にあると考えています。 さきほど紹介したAdmin SDKやv1 HTTP プロトコル(API)で記録を残そうとすると、標準的な実装では厳しいです。 特別にログファイルに出力する実装を入れておくとか、送信結果（レスポンス）を毎回保存しておく運用にするなど、ひと手間かかります。 （もし良い方法があれば、お問い合わせフォームから教えてください！） Firebaseコンソール経由で配信した通知は、このように表示されます。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/f2197cef19b041dcab605fac48258004/IMG_2452.jpg" alt=""> 画像は、お恥ずかしながら、trogの記事更新メッセージとして実際に配信したものです。 結果として通知の送信数が確認できます。 「開いた数」も確認できそうですが、実装側の問題なのかうまく計測できてないですね。 （この頃はまだ一部の実装で古いライブラリを使ってました。） 決して、誰も開いてないわけではないです😭 少なくともこの18の送信数のうち数台はわたしのテスト端末で、わたしが開いてますので。 「複製」を押すと、この通知の入力内容を引き継いで、新しいキャンペーンの作成画面に行けます。 前の通知と統一した文章で配信できるので、Firebaseコンソールはかなり便利に利用しています✨ 注意点としては、過去にAdmin SDKやv1 HTTP プロトコル(API)経由で送信したWebプッシュ通知は、Firebaseコンソールからの確認・複製はできません。 当然と言えばそうなのですが、Firebaseコンソールを経由して送信した通知の記録のみを表示するページになっています。 <h2 id="h9be0c3393d">おわりに</h2>Admin SDKは通知テキストが固定のもの、決まりきっているものに向いているので、都度発生する「記事更新のお知らせ」のような通知には、単体では不向きです。（ただし各種CMSと連携のうえ自動プッシュ通知配信が技術的には可能なので、異論は認めます。） FCMを利用したWebプッシュ通知送信方法としては、v1 HTTP プロトコル(API)が主流で、多くの記事でAPI経由の実装方法が紹介されていますが、エンジニアによる配信が前提になるかと思います。 trogではここ１年ほど、Firebaseコンソールを利用してWebプッシュ通知を配信してきました。 FirebaseコンソールのUIであればエンジニア以外の方にも、通知を配信していただけないかなー、と淡い期待を抱いています。...しかしながら、現場レベルでは厳しいというご意見もいただきました。世知辛いぜ。 次回は具体的な実装方法の説明記事を投稿する予定です。 FirebaseコンソールからのWebプッシュ通知送信も、選択肢のひとつに入れてもらえるとうれしいです。 * * * （おまけ）trogのWebプッシュ通知登録してくれてる人、ありがとうございます！！！ 記事中の通知画像はステージング環境（本番環境とは別）のもので、「テストメッセージを送信」という、指定した端末のみに配信する機能を使用しています。（本番の通知が飛ばないよう、気を付けています。） 皆さまのおかげで、この記事を書くモチベが生まれています🙏 みんなもクリエイターへの前向きなリアクション、大事にしような！

Firebaseコンソール経由のWebプッシュ通知の様子をデモンストレーションします。

FirebaseコンソールからWebプッシュ通知を配信する（機能紹介編）

１年半ぶりに大学のスクーリングに参加した。 普段は通学課程の若者が溢れるキャンパスだが、灼熱降り注ぐ８月には、通信課程所属の老若男女がキャンパスを占有する。卒業要件充足には一定のスクーリング単位修得が必須となるためだ。 半期分の講義と科目試験をたった６日で強行突破、生徒のみならず講師までも極限に消耗させる恐ろしいスケジュールで進行する。 どうやら開催されるすべてとなる、３週間分のスクーリングに通う猛者も存在するらしい。（わたしはひそかに「全通」と呼んでいる。(*1)） 普段はプログラマとして働いているが、会社から早めの夏休み１週間分をもらうことにより、スクーリング参加が可能となった。６日間の連泊が可能なホテルも確保をして、重たい荷物とともに新幹線でキャンパスに向かった。 * * * 講義初日、教室には開始１分前に滑り込んだ。 「うちの大学のことならなんでも聞いてください」と言わんばかりの腕章を付けた職員の方に、教室の位置を教えてもらえて助かった。 前回参加したスクーリングでは50代以降が中心だったが、教室を見渡すと今回は同年代が多そうだ。 今回は午前・午後に分けて、計２科目を受講する。 午前は必修の英語だが、いわゆる「大学生といえばこれ！」として想像するような大講義室での授業とは異なる。 15人ほどの少人数に対して講師１人が付き、きめ細やかに指導してくださる。 この少人数では陰キャがいくら存在感を消そうとも不可能である。初日にして顔と名前が一致するレベルで当てられたし、授業態度は評価にガッツリ加算される。当然ながらサボる余裕などは与えられない。 偶然、席が近かった同年代の女の子とペアワークをした。 他の通信課程の生徒と比較すると属性が近いことから、親近感が湧いていた。 休み時間になった。 教室に知らない女の子が突入してきた。 ドーナツの袋を携えた彼女は、女の子の席の隣に座り、談笑を始める。 しばらくすると二人に話しかけられたので、わたしは会話の輪に入った。 どうやら二人はもともと友人らしい。朝食だよー、と言ってドーナツを食べながら教えてくれた。 初日の英語の講義がなんとか終わり、１時間の昼休憩になる。午後からわたしは大講義室に移動して別の授業を受けに行く。 ペアワーク相手の女の子にお昼ご飯の予定を聞くため声をかけようとしたのだが、「じゃ、お疲れさま～！」と言って彼女は教室を出て行った。 悲しい。 ぼっち大学生の爆誕である。 スクーリングで新しい友人ができることに期待して、10年以上変えてなかったLINEのプロフ画像を変更してきたのに。 いやでも、わたし陰キャだし。別にいいよ。 チーズ牛丼の大盛りでも頼んでこようかな。 せっかくなので学食に赴き、鮭丼と窓際のおひとり様席を確保。 灼熱地獄にもかかわらず、外のベンチで通学課程の男女混合集団が涼しい顔で談笑している。 元気だなー、と眺めながら優雅にランチを楽しんだ。 * * * ２日目の英語の講義が終わった。 キャンパスを一歩出ると飲食店が非常に充実している。ランチ候補を思案しつつ、教室を出るとペアワーク相手の女の子と遭遇した。 これからドーナツの女の子と他の友達と学食に行くようで、よかったらどう？と誘ってくれた。 めでたくぼっち卒業である。 学食でうどんを購入、席で待っていると「ここいいですか？」と声をかけられた。 すでに連絡がいっていたらしく、その子はドーナツの女の子の友達であった。 全員揃ったので食べ始めた。これまでの人生においてまるで縁のなかった、実に大学生らしい光景である。 大学生活の話題になった。 「仕事も忙しいし、このスクーリング終わったら休学しようかと思ってー」「えー、寂しいー」 ペアワーク相手の子がわたしに聞いてきた。 「え、いま何単位取った？」 正直ここまでの２日間でとくにわたしにメリットのある情報が得られたわけでもなく、信頼関係が築けたとも思っていない。 しかも世の中には、在籍期間のわりに単位が取れてないことを批難してくる人が存在する。 わたしは家族も職場も非常に理解ある人に恵まれているので「完全に趣味です」と宣言したうえで、超マイペース社会人大学生をさせてもらっている。 毎年が「もう１年遊べるドン！」の留年し放題コースを突き進むわたしは慎重に答えた。 「いや、全然取ってないです（笑）」 「じゃあ0ですか？w」 「あー、0ですね。」 そこまで言って、わたしは黙ってうどんをすする。 陰キャ側からATフィールドが展開されてしまっており、もう全然ダメな会話の典型例である。 彼女にとっては単なる話題の一つであったが、わたしは無神経な質問にいらついて、会話を続ける気力を失った。 別の方向から話題が提供される。 学食で合流した子は、ドーナツの女の子と以前の講義で仲良くなり、今回のスクーリングで再会したらしい。その子は嬉々として、以前の講義の様子を話し始める。 スクーリングに参加する通信課程の生徒は、ホールに貼り出された掲示板の情報を頼りに、各自の判断で各教室に散らばっていく。 今回初日のわたしが職員の方を捕まえて教室の位置を聞けたのは、かなりラッキーであった。 教室に学生証の認証装置は存在しない。 自分が講義を受けている教室が正しいかどうか、他人からは教えてもらえない。出席を取られる講義であれば、そのタイミングで気づくチャンスが訪れるが、確認する機会が意外と来ない。 その子いわく、以前の講義にも参加する教室を間違えてしまったおばさまがいたらしい。 おばさまは熱血漢の講師から激しい剣幕で怒られてしまう。彼女は半泣きで荷物を抱えて移動していくのだが、 「そのおばさんの荷物がとんでもなくボロボロだったんだよね～」と言ったタイミングでドッと爆笑が巻き起こった。 わたしはとても辛くなった。適当な理由をつけて即座にグループから離脱した。 通信課程というのは、さまざまな事情を抱えた人が覚悟を決め、日常生活の中からなんとか時間を捻出して大学生をしている。 ましてスクーリング参加のハードルは高い。地方勢であれば遠方から大量の荷物を持って移動し、慣れないホテル生活を強いられながら、連日キャンパスに通うことになる。 経済的な負担が重くのしかかるのは当然だ。 通信課程の生徒として参加している大半はまともな大人である。その大人たちからこの子たちと同じグループの人間だと判定されることは、一社会人として恥でしかない。 あいかわらず暑かったが、外の空気は清々しく、コンビニに向かう足どりは軽かった。 ひとりぼっちはこのうえなく愛おしかった。 * * * 翌日からはキャンパスの外でお昼ご飯を食べることに決めた。ランチの時間が楽しみになった。 幸いにも美味しいお店の情報を仕入れていたので、お店選びには困らなかった。 ただ全体的にお値段が張るのは難点だった。地方とは物価が異なるのだ。 「地方で稼いだお給料で、都会で外食し続けるなんて身の丈に合わないぞ！」とわたしの中の主婦が叫んだ。 しかしこれは慣れないおひとり様旅行に対するご褒美である。その声は無視して美味しいものを食べるのは、もはや確定事項だ。 講義最終日は試験を終えると解散となる。 地方からの遠征組はこの日が帰宅日。朝チェックアウトした後は、６泊分の荷物の預け先を確保する必要がある。 ペアワーク相手の女の子は「終電まで友達と遊ぶ予定でいっぱいにしちゃったから、荷物運ぶ時間ない〜！」と嘆いていた。 スクーリング期間中は毎日、あのグループで行動していたようだ。 ちなみに彼女はもとから非常に優秀なので、単位は余裕で取れそうな様子だった。 常に誰かの都合に合わせて行動するのは、ぼっちのわたしにはしんどくてたまらない。 通信課程独自の「半期分の授業を６日で片付ける」超過密スケジュールをこなすだけで精一杯であり、「大学生」と聞いて想像するような「豊かな人生経験」を積むのは別の機会で構わないと割り切って、このスクーリングに臨んだ。 一方で、実際に通学課程の生徒が使用しているキャンパスを使用できるのだから、仲間と大学生活を謳歌することは可能ではある。 大学の方針にも「異なる学部の生徒とも交流を深め、さらなる学びを追求していってほしい」と書かれていた。 ただこれはわたしがこの数年のあいだ通信課程に在籍していて感じたことなのだが、 わたしたちが現役の大学生とまったく同じ青春をいくら望んだとしても、所詮は「模倣」することしかできない。 社会的な立場の違いというのは大変恐ろしく、どこまでいっても大学生「ごっこ」になってしまう。 叶わぬ憧れを追いかけるよりも、同じ大学や同じ境遇にこだわらず、 現状を理解してくれる人とともに過ごす時間に、最近では価値を感じている。 大学生としては「ぼっち」だが、わたし自身は「ぼっち」ではないのだ。 社会人大学生というのは、孤独な長距離マラソンを強いられる。 実際のマラソンでは１秒でも早く走り抜けられる人が優秀な選手とされるのだろうが、社会人大学生には持久力の方が大切な気がしている。 走り続けるにあたり、沿道からの応援ほど心強いものはない。 今後も疲れたら休みつつ、マイペースに走り続けることにする。 * * * *1: 意味がわからない場合は「全通 ライブ」で検索してください。

１年半ぶりに大学のスクーリングに参加、通信課程とはいえ大学生活を体験できる貴重な機会でした。ただし人との距離の測り方は難しい。

アラサー女、ぼっち大学生を極める。

明日はバレンタインデー。 わたしが小学生のときの話を一席。 * * * 掃除の時間に、女の子二人に話しかけられた。 「もうすぐバレンタインデーだよね。あの男の子のこと、好きなんでしょ？おうちにチョコ渡しに行ってみない？わたしたち、近くで応援してるからさ！」 わたしがあまりにも怪訝そうな顔をしたのだろう。もう一人が続けた。 「実はAちゃんもあの子のこと好きでさ、あの子の家まで行ってチョコ渡しに行こうって話になってて。あの子のこと好きなの知ってるのに、とろちゃんにだけこのこと黙ってるの、なんか変じゃん？だから一緒に渡しに行こうよ。」 「行かないなら、いますぐ大声でクラスのみんなにばらすよ？」 いまどきの小学生は駆け引きというか、交渉スキルもすごいんだなー、と。 なんなら脅迫までしてきた。 彼女たちにバレているということは、クラスに知れ渡るのも時間の問題だろう。 小学生の情報拡散力はすさまじい。まして恋愛沙汰となれば、うちの学年はやけに食いつきが良かった。 脅迫の件に関してはもはや恐れる必要などない。残念ながら、いずれバレる。 しかしまったくもって不要な情報を拡散されてしまった男の子はどう思うだろうか。 わたしが判断を誤ったばかりに今後数日間学年中……もっと悪いと学校中から好奇の視線にさらされるかもしれない。 残念ながら、わたしは小学生時代から陰キャコミュ障である。 相手のことはそっと好きでいたかったのだが、こうなってしまっては致し方ない。 脅しに屈するのは不本意だが、わたしは男の子の家にチョコを渡しに行くことに決めたのだった。 * * * あっという間に当日がやってきた。 すぐに下校して、母親にも手伝ってもらいながら用意したプレゼント用のチョコを手に持ち、話しかけてきた同級生に指定された待ち合わせ場所に向かった。 着いた頃には、ちょうどAちゃんが渡しているタイミングだった。 同級生二人は、携帯電話でその様子を撮影していた。 当時の携帯電話（いまで言うところのガラケー）というのは、現代のスマホとはスペックが雲泥の差であり、動画撮影など不可能である。 解像度のあまりよくない写真を数十枚も撮ると、もう容量がいっぱいになる。 シャッタースピードもまったく期待できないため、狙った一瞬を写真に収めるのは非常に難しかった。 この地域はそれほど都会ではないので、生徒の大半は携帯電話など持っておらず、所持している小学生は大変貴重であった。 ましてカメラ付きの携帯電話というのは機種代金が少し高額で、それを持っているだけで恵まれた環境にあるのだとわかった。 小学生がカメラ付き携帯電話を持っている場面に遭遇したことのないわたしにとっては、すべてが新鮮すぎた。 ゆえに目の前で何が起きているのか、よく理解できなかった。 一瞬Aちゃんがチョコを渡している場面の写真を見せてくれたが、携帯電話に焦点を合わせる前に、写真はわたしの視界から消えた。 二人があまりに興奮しすぎて跳ね回っているためである。 「あー！まじやばかったー！ じゃあ次はとろちゃんの番だね。がんばってね！」 わたしは男の子の家に向かった。 一本道にも関わらず、あまりに緊張して果てしなく遠く感じた。 いざ玄関を目の前にすると心が折れそうになったが、勢いでインターホンを押した。 どうせ撮影されるんだろうなと思い、同級生のいる方に目を向けると、ニヤニヤしながらこちらを見守っていた。 インターホン越しに男の子の声がして、すぐに玄関から男の子が出てきた。 なんて言って渡したのか、もはや記憶に残ってない。 手に持っていたチョコの入った袋を渡した。男の子は大人みたいな笑顔で受け取ってくれた。 わたしはすぐにその場をあとにした。 * * * 戻ると、同級生とAちゃんは携帯電話を覗き込んでいた。 わたしは緊張からの解放感でハイになっており、同級生たちに構わず勝手に感想を喋ろうとして、 すぐにやめた。 わたしも一緒になって、携帯電話を覗き込んだ。 「いやー、二回目だからいい写真が撮れた。送信、っと！」 送信される前の画面ははっきりと覚えている。 「番外編♡」というメッセージとともに、渡している瞬間のわたしの写真が添付されていた。 自分としては、慣れないイベントをよく乗り切った、と。 心の中は達成感でいっぱいだったのだ。 他人から見た現実は違った。 自分は「番外編」だった。 よく「自分の人生の主役は自分自身だ！」なんて熱く語っている人がいるが、あんなの大嘘つきだ。 だって目の前で「番外編」として、いままさに他人に紹介されようとしているのだから。 メールの宛先は同級生たちの親友である、隣のクラスの女の子だった。 （いま考えると、メールの宛先が「クラス全員」ではなかったのは本当に運がよかったと思う。） 思えば最初に誘われた時点からわたしは「番外編」だったじゃないか。 チョコレートを準備している最中に、舞い上がって勘違いしてしまったのだ。 同級生たちになにか話しかけられた気がしたが、なにも頭に入ってこなかったので適当な返事だけして、帰宅した。 * * * 数日間は、この黒歴史を完全に記憶から抹消したくて、憂鬱な日々が続いた。 誘ってきた同級生二人とは遭遇しないように過ごした。 しばらくするとこの日の出来事を本当に忘れてしまっていた。 いつもの小学校生活を送っていたある日。 男の子の妹から廊下で声をかけられた。 「ねえねえ。好きなキャラクターとかいる？」 彼女とはこれまで一言も会話をしたことはなかった。 一応わたしが先輩なので、まず挨拶とか。あと『ですます』ぐらいは付けて欲しかったなあ...、などとダサいことを考えつつ、 「え、あの、基本的にはあざらしが好きで、キャラクターで言うとしろたんか、あ、有名じゃないよね。じゃあSan-xから出てるまめゴマもすごく好きだよ。」 と陰キャ特有の早口で答えた。 彼女はなにも言わず、ニヤニヤしながらどこかに行ってしまった。 なんだか不思議なイベントが発生したな...と思い、Aちゃんに確認してみたところ、やはり男の子の妹に好きなものを聞かれたらしい。 バレンタインデーから丸一ヶ月後。 例の誘ってきた同級生二人から「授業が終わったらすぐに下校して、絶対に家で待機してるんだよ」と言われた。 しかたなく、言われたとおりに家で待機しているとインターホンが鳴った。 いつもは絶対に出るなとキツく言われているのだが、その時だけは母親からインターホンの受話器を取るように言われた。 玄関の扉を開けると、男の子が立っていた。 わたしが渡した小さなチョコより、二回りは大きいであろう紙袋を抱えて。 なにが起きているのかよくわからなかったが、 男の子からは一ヶ月前のチョコレートへの感謝の気持ちを伝えられた。 お礼を伝えて、わたしは家に戻った。 紙袋の中には、わたし一人では期限までに食べきれないほどのお菓子と、わたしの大好きなまめゴマグッズなど、素敵なものがぎっしり詰まっていた。 翌日、同級生とAちゃんにこの事を話した。 Aちゃん宅でも同様のイベントが発生したらしい。 「あの男の子のお母さん、こういうイベント大好きなんだよね！ いいねー！ホワイトデーってやつだよー、キャー！」と同級生は盛り上がっていた。 まさか男の子のお母様や妹さんまで巻き込んでしまうとは思っておらず、なんとも申し訳ない気持ちになった。 なんだか関係者一同から面白がられているだけのような気もして、ちょっとモヤモヤした。 でも素直にうれしかった。 15年以上経ったいまもこうして、一連の流れを覚えているのだから。 * * * 付き合うとか、振られたとか、そういったことはない。これで終わりである。 この話には読者の皆さんが期待するような（？）、恋愛マンガのような展開は存在しないのだ。 わたしが番外編なのであれば、やはりAちゃんが主役でハッピーエンドなのかとも考えたのだが、 小学生の行動や言動がすべて合理的だと捉えるのは誤りだろう。 だから、そのあと男の子とAちゃんがどうなったかは全く知らない。 男の子からは、わたしがSNSで結婚報告の投稿をしたときに、祝福のコメントをいただいた。 この記事はすぐさまネットの海に沈んでいくだろう。せいぜいネットのおまいらに「番外編で草」とか言われて引用されるのが関の山だ。 直接言われたわけでもない、他人のメッセージに添えられただけの一言をいまだに根に持ってブログに投稿するなんて、まったくもって善い行いではない。 そんなわたしだが、好きな人に思いを伝えようと行動する勇気を尊重したい。 最初は本意ではなかったとは言え、わたしはあの日に行動できてよかったと思っている。 バレンタインデーに頑張る人を、陰ながら全力で応援しています。

小学生時代のあるバレンタインデーの出来事です。

番外編の女

RSS(Rich Site Summary)とは、Webサイトの更新情報をユーザーに対して通知できるフォーマットです。 Wikipediaによると、1999年の"RSS0.9"がRSSの起源とのことなので、25年ほど前から存在する技術ということですね。*1 「RSSリーダー」と呼ばれる専用ソフトウェアや、RSS対応のブラウザで通知の受け取りが可能です。 いまや「通知」機能といえば、スマホアプリのプッシュ通知が馴染み深いですが、現在でもFeedly, InoreaderなどのRSSリーダーが情報通のビジネスパーソンを中心に根強い指示を集めている印象です。 本記事ではそんな古の技術であるRSSを、【令和最新版】Webアプリ開発フレームワークのNext.jsに搭載する方法をご紹介します。 具体的にはこんな感じでサムネイル画像を付けて配信します。スクショはInoreaderの様子です。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/677c9ab7d8914177a6228ddc34af12f5/85B3E431-0A83-4B2F-B2C8-69EB3172F399.jpeg" alt=""> Gatsbyの記事と同じ画像じゃないかって？ そうですよ。trogがGatsbyで搭載した機能のマイグレーションというやつです。 （なんのことかわからない方のための関連ページ： <a href="https://microayatron.com/gatsby-feed" target="_blank" rel="noopener noreferrer">【Gatsby】RSSフィードをサムネイル画像付きで配信する - trog</a> ） それではNext.jsアプリケーションでもRSS配信していきましょう！ <h2 id="h31d727ccda">準備</h2><h3 id="hdbf98b940f">前提条件</h3><ul><li>Next.jsアプリケーションが構築済み</li><li>RSS 2.0準拠</li></ul> 弊ブログtrogではCMSとしてmicroCMSを採用しており、この記事もmicroCMSから記事を投稿しています。 基本的にはNext.jsで構築されたアプリケーション全般で使用できるように説明します。 実装解説の最後に、microCMSから取得した情報のRSSファイルを作成するコードをご紹介します。 <h3 id="h7fd6208c36">使用パッケージ</h3><ul><li>RSS - <a href="https://www.npmjs.com/package/rss" target="_blank" rel="noopener noreferrer">https://www.npmjs.com/package/rss</a></li><li>xmlbuilder2 - <a href="https://www.npmjs.com/package/xmlbuilder2" target="_blank" rel="noopener noreferrer">https://www.npmjs.com/package/xmlbuilder2</a></li></ul> xmlbuilderのほうが人気がある(らしい)ですが、最新版のxmlbuilder2のほうが使いやすくなっておりオススメです。 <h2 id="h30aa79f147">xmlbuilder2のメソッド</h2>今回は、xmlbuilder2のXML生成メソッドのうち、<code>.ele()</code>, <code>.txt()</code>, <code>.up()</code>を使用します。 <h3 id="hab6e255591">.ele()</h3><code>.ele(name, attributes, text)</code>メソッドでは、新しいXML要素を作成できます。<ul><li><code>name</code>：新しい要素の名前です。</li><li><code>attributes</code>（オプション）：新しい要素の属性を定義するオブジェクトです。</li><li><code>text</code>（オプション）：新しい要素のテキスト内容です。</li></ul>例えば、以下のコードは<code>&lt;item isPermaLink="false"&gt;Hello&lt;/item&gt;</code>というXML要素を作成します。<pre><code>doc.ele('item', { isPermaLink: "false" }, 'Hello');</code></pre><h3 id="h67e0e575df">.txt()</h3><code>.txt()</code>メソッドは、XML要素の中に直接テキストを挿入できます。 例えば、以下のコードは<code>&lt;title&gt;</code>要素にHelloというテキストノードを追加します。<pre><code>doc.ele('title').txt('Hello');</code></pre> これにより、<code>&lt;title&gt;Hello&lt;/title&gt;</code>というXMLが生成できます。 <h3 id="h3eac8b5da9">.up()</h3><code>.up()</code>メソッドは、いまある要素の親要素に移動します。これは、ネストされた要素を作成するときに便利です。 例えば、以下のコードは<code>&lt;channel&gt;</code>要素の中に<code>&lt;title&gt;</code>要素を作成します。<pre><code>doc.ele('channel').ele('title',&nbsp;{},&nbsp;'Hello').up();</code></pre>このコードは、<code>&lt;channel&gt;&lt;title&gt;Hello&lt;/title&gt;&lt;/channel&gt;</code>というXMLを生成します。 <code>.up()</code>メソッドを呼び出すことで、<code>&lt;title&gt;</code>要素の親である<code>&lt;channel&gt;</code>要素に戻ります。 これにより、<code>&lt;channel&gt;</code>要素の中に、さらに子要素を追加できます。 <h2 id="h0d0955a620">基本のRSS情報</h2><code>scripts/generate-rss.mjs</code>という名前でファイルを作成します。 普通の*.jsファイルでも問題ないです。*2 RSS情報の核となる部分はこんな構成です。(イメージ)<pre><code>&lt;item&gt;
 &lt;title&gt;記事のタイトル&lt;/title&gt;
 &lt;link&gt;記事のURL&lt;/link&gt;
 &lt;pubDate&gt;記事の公開日&lt;/pubDate&gt;
 &lt;description&gt;記事の要約&lt;/description&gt;
 &lt;guid isPermaLink="false"&gt;記事のパス&lt;/guid&gt;
 &lt;media:content url="サムネイル画像のURL" width="1920" height="1080" media="image"/&gt;
&lt;/item&gt;</code></pre> <code>title</code>から<code>description</code>までは載せたい情報をそのまま記載してください。 <code>guid</code>は、記事を一意に識別するために必要な情報です。 タイトルにしてしまうと変更する可能性があるので、記事のURLを指定しています。 <code>guid</code>は任意の値を指定できるものの、URLが入ることが前提のようです。*3 <code>isPermaLink</code> 属性を<code>false</code>に指定しておくと、<code>guid</code>がURL(フルパス)ではないことをRSSのルールに則って示せるようです。 ...が、サイトによって<code>guid</code>に指定している値がバラバラだったり、そのタグ名だけでは「URLのフルパスを指定する」というルールがわかりづらく、周知されていない様子です。 URLは<code>link</code>で解釈してもらうことにしています。（trogでは<code>guid</code>はお飾りになっています） 核となる<code>&lt;item&gt;</code>の中についてはこのように実装しました。<pre><code> articles.forEach((article) =&gt; {
 feed.ele('item')
 .ele('title').txt(article.title).up()
 .ele('link').txt(`https://microayatron.com/${article.slug}`).up()
 .ele('pubDate').txt(article.publishedDate).up()
 .ele('description').txt(article.metaDescription).up()
 .ele('guid', { isPermaLink: "false" }).txt(`https://microayatron.com/${article.slug}`).up()
 .ele('media:content', {
 url: article.image?.url,
 width: 1920,
 height: 1080,
 media: 'image',
 }).up();
 });</code></pre> <code>articles</code>はmicroCMSから取得した、記事情報のかたまりです。<code>feed</code>はヘッダー定義の紹介時に説明します。 <h2 id="h6b5736a504">画像情報</h2>Media RSS タグ( <code>&lt;media:content&gt;</code> )には画像のURL、画像の高さ・幅、メディアの種類を指定します。<pre><code>.ele('media:content', {
 url: article.image?.url,
 width: 1920,
 height: 1080,
 media: 'image',
}).up();</code></pre> メディアの種類は今回の場合<code>image</code>と指定してください。 これらの項目を「属性」として指定する必要があるため、オブジェクトにまとめて突っ込みます。 これだけだと”Namespace prefix media on content is not defined.”のエラーが表示されます。 Media RSS タグを使用するために、RSSのヘッダー部分に <code>xmlns:media="http://search.yahoo.com/mrss/"</code>を定義する必要があります。 ヘッダー定義はこのようにしました。<pre><code> const feed = create({ version: '1.0', encoding: 'UTF-8' })
 .ele('rss', {
 'xmlns:dc': 'http://purl.org/dc/elements/1.1/',
 'xmlns:content': 'http://purl.org/rss/1.0/modules/content/',
 'xmlns:atom': 'http://www.w3.org/2005/Atom',
 'version': '2.0',
 'xmlns:media': 'http://search.yahoo.com/mrss/'
 })
 .ele('channel')
 .ele('title').txt('trog').up()
 .ele('link').txt('https://microayatron.com/').up()
 .ele('description').txt('RSS feed for microayatron.com').up();</code></pre>feedという変数を定義して、その中にどんどん項目を突っ込んでいます。 ヘッダーなど外枠の生成が終わったら、さきほど説明した<code>item</code>の中身を生成します。 RSSファイルを生成するとこうなります。<pre><code>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0" xmlns:media="http://search.yahoo.com/mrss/"&gt;
 &lt;channel&gt;
 &lt;title&gt;trog&lt;/title&gt;
 &lt;link&gt;https://microayatron.com/&lt;/link&gt;
 &lt;item&gt;(先述の記事情報1)&lt;/item&gt;
 &lt;item&gt;(記事情報2)&lt;/item&gt;
 &lt;item&gt;(記事情報3)&lt;/item&gt;
 ...
 &lt;/channel&gt;
&lt;/rss&gt;</code></pre> <h2 id="he4d8f1eca6">RSS生成</h2><h3 id="h922edff87b">実装</h3>配信用のRSS情報を記載した<code>rss.xml</code>を生成します。 具体的な生成場所は、<code>/public/feed/rss.xml</code>としています。 こうすることでRSS配信URLを、<code>https://hogehoge.com/feed/rss.xml</code>とすることができます。 実装のまとめとして、microCMSを採用している場合の<code>generate-rss.mjs</code>を載せておきます。<pre><code>import { createClient } from 'microcms-js-sdk';
import fs from 'fs';
import path from 'path';
import { create } from 'xmlbuilder2';

const filePath = path.resolve('public/feed/rss.xml');

// ディレクトリが存在するか確認、存在しない場合は作成する
const dir = path.dirname(filePath);
if (!fs.existsSync(dir)){
 fs.mkdirSync(dir, { recursive: true });
}


// ファイルが存在するか確認、存在しない場合は作成する
if (!fs.existsSync(filePath)) {
 fs.writeFileSync(filePath, '', 'utf8');
}


const client = createClient({
 serviceDomain: process.env.MICROCMS_SERVICE_DOMAIN, 
 apiKey: process.env.MICROCMS_API_KEY, 
});


const generateRssFeed = async () =&gt; {
 try {
 // microCMSから記事を取得する
 const response = await client.getList({
 endpoint: 'blog', // 環境に合わせて変更してください
 queries: { limit: 100, orders: '-publishedDate' } // 公開日時が新しい順
 });

 const articles = response.contents || [];

 // フィードの作成
 const feed = create({ version: '1.0', encoding: 'UTF-8' })
 .ele('rss', {
 'xmlns:dc': 'http://purl.org/dc/elements/1.1/',
 'xmlns:content': 'http://purl.org/rss/1.0/modules/content/',
 'xmlns:atom': 'http://www.w3.org/2005/Atom',
 'version': '2.0',
 'xmlns:media': 'http://search.yahoo.com/mrss/'
 })
 .ele('channel')
 .ele('title').txt('trog').up()
 .ele('link').txt('https://microayatron.com/').up()
 .ele('description').txt('RSS feed for microayatron.com').up();


 // フィードに記事を追加する
 articles.forEach((article) =&gt; {
 feed.ele('item')
 .ele('title').txt(article.title).up()
 .ele('link').txt(`https://microayatron.com/${article.slug}`).up()
 .ele('pubDate').txt(article.publishedDate).up()
 .ele('description').txt(article.metaDescription).up()
 .ele('guid', { isPermaLink: "false" }).txt(`https://microayatron.com/${article.slug}`).up()
 .ele('media:content', {
 url: article.image?.url,
 width: 1920,
 height: 1080,
 media: 'image',
 }).up();
 });


 return feed.end({ prettyPrint: true });
 } catch (error) {
 console.error('Error fetching data from MicroCMS:', error);
 throw error;
 }
};

const generateAndSaveRssFeed = async () =&gt; {
 let rssFeed = await generateRssFeed();

 if (rssFeed) {
 fs.writeFileSync(filePath, rssFeed);
 console.log('RSS feed generated and saved.');
 }
};

generateAndSaveRssFeed();</code></pre> <h3 id="ha72acf6b59">RSSファイル生成の流れ</h3>trogではビルド時にRSSファイルを生成するように設定しています。 trogの記事が更新されるまでの流れを簡単にご説明すると... <ol><li>microCMSから[公開]ボタンを押して記事を公開</li><li>Webhookで接続されたNetlify(ホスティングサービス)で公開されたことを検知</li><li>microCMSから最新の情報を取得のうえ、Netlifyがtrogをビルド実行</li><li>公開用のページ(HTMLファイル)が生成される</li></ol> ということで、trogでは自動でサーバーに最新記事がアップロードされる仕組みにしてあります。 （設定すればちゃんと動くようにmicroCMSがあらかじめ用意してくれてるだけ） 先述の<code>generate-rss.mjs</code>の実装の中で、microCMSから最新記事を取得するようにしました。 ビルド時に<code>generate-rss.mjs</code>を実行することにより、RSS情報に自動で更新した記事が追加される...という流れにしていきます。 * * * それではRSS生成のトリガーとなる部分を実装していきます。 <code>next.config.js</code>に<code>child_process</code>モジュールを使用して、<code>scripts/generate-rss.mjs</code>スクリプトを同期的に実行するよう設定します。<pre><code>const { execSync } = require('child_process');

execSync('node scripts/generate-rss.mjs', { stdio: 'inherit' });</code></pre> <code>package.json</code>の<code>script</code>部分に、<code>generate-rss</code>コマンドを記載します。<pre><code>"scripts": {
&nbsp; &nbsp; "build": "node build.js &amp;&amp; next build",
&nbsp; &nbsp; "generate-rss": "node scripts/generate-rss.mjs"
&nbsp; },</code></pre> これでビルド時に<code>/public/feed</code>に<code>rss.xml</code>が生成されるようになります。 採用しているパッケージやツールに合わせて、お好みで変更してください。 <h2 id="h63ad3943f9">テスト</h2>正しく生成されているかどうか確認していきます。 まずは開発環境でさきほど定義した<code>npm run build</code>を実行したのちに、<code>next start</code>を実行します。 <code>http://localhost:3000/public/feed/rss.xml</code>にアクセスして、RSS情報が確認できれば成功です。 ここで<ul><li>生成されたRSS情報のヘッダー情報に<code>xmlns:media="http://search.yahoo.com/mrss/"</code>が含まれていること</li><li>各記事情報の中に<code>&lt;media:content&gt;</code>が含まれていること</li></ul>の２点を確認してください。 Chromeで確認する場合は、こんな感じのカラフルな画面になっているかもしれません。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/ed28fa0913a1484189e1519ee140e291/nexr-rss-1.png" alt=""> xmlとして誤りがある場合はエラーが表示されます。 <img src="https://images.microcms-assets.io/assets/a9ffe7eb96404d7c80dc093859029792/c0cc89c3ebc24d7c8f0b7ebcae6916d7/nexr-rss-2.png" alt=""> よかったらデバッグの参考にしてください。 <h3 id="h9e9cceb515">RSSリーダーから確認(デプロイ後)</h3>アプリケーションを本番環境にデプロイすれば、Feedly, InoreaderなどのRSSリーダーから確認できます。 各RSSリーダーが、ブログから配信されたRSS情報を解釈して、わかりやすいUIに落とし込んでいます。 お好きなRSSリーダーから、本番環境の配信先URL(例: <code>https://hogehoge.com/feed/rss.xml</code>)を試しに購読して、確認してみてください。 <h2 id="h9be0c3393d">おわりに</h2>最近では分散型SNSがユーザーアカウントごとの投稿をRSSを配信しているようです。 それまでRSSを使ったことのなかった世代でも、MiskeyやマストドンなどでRSSに触れる機会が増えることになります。 ご自身のブログでもRSS配信機能を実装すれば、分散型SNSからRSSの存在を知った新参の情報通からのアクセスが期待できるようになるかもしれませんね。 「レターパックで現金送れ」はすべて詐欺です。*4 皆さまくれぐれもお気をつけください。 * * * 1: <a href="https://ja.wikipedia.org/wiki/RSS#:~:text=%E6%9C%80%E5%88%9D%E3%81%AERSS%E3%81%A7%E3%81%82%E3%82%8B,%E7%AD%96%E5%AE%9A%E3%81%97%E3%81%9F%E3%82%82%E3%81%AE%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82" target="_blank" rel="noopener noreferrer">https://ja.wikipedia.org/wiki/RSS#:~:text=%E6%9C%80%E5%88%9D%E3%81%AERSS%E3%81%A7%E3%81%82%E3%82%8B,%E7%AD%96%E5%AE%9A%E3%81%97%E3%81%9F%E3%82%82%E3%81%AE%E3%81%A7%E3%81%82%E3%82%8B%E3%80%82</a> - RSS - Wikipedia 2: 仕事ではTypeScriptで開発していますが、trogはTypeScript化をサボっており、いまだにJavaScriptのままです。でもimportは書き慣れたECMAScriptを使いたいため、*.mjsを採用しました。 ちなみにtrogを構成するファイル群の中でmjsはここだけです。ただただ整備をサボっています。 *3: <a href="https://www.rssboard.org/rss-draft-1#element-channel-item-guid" target="_blank" rel="noopener noreferrer">https://www.rssboard.org/rss-draft-1#element-channel-item-guid</a> - RSS 2.0 Specification <a href="https://validator.w3.org/feed/docs/error/InvalidPermalink.html" target="_blank" rel="noopener noreferrer">https://validator.w3.org/feed/docs/error/InvalidPermalink.html</a> "guid must be a full URL, unless isPermaLink attribute is false" - &nbsp;Feed Validation Service <a href="https://support.google.com/feedburner/answer/79014?hl=ja" target="_blank" rel="noopener noreferrer">https://support.google.com/feedburner/answer/79014?hl=ja</a> 「フィード コンテンツの記事のリンクが機能しないのはなぜですか？」 - FeedBurner ヘルプ *4: <a href="https://dic.pixiv.net/a/%E3%83%AC%E3%82%BF%E3%83%BC%E3%83%91%E3%83%83%E3%82%AF%E3%81%A7%E7%8F%BE%E9%87%91%E9%80%81%E3%82%8C" target="_blank" rel="noopener noreferrer">https://dic.pixiv.net/a/%E3%83%AC%E3%82%BF%E3%83%BC%E3%83%91%E3%83%83%E3%82%AF%E3%81%A7%E7%8F%BE%E9%87%91%E9%80%81%E3%82%8C</a> - レターパックで現金送れ (れたーぱっくでげんきんおくれ)とは【ピクシブ百科事典】

Next.jsで作成したアプリにMedia RSS タグ( <media:content> )タグを設定のうえ、サムネイル画像の情報込みでRSS配信する方法をご紹介します。

【Next.js】RSSフィードをサムネイル画像付きで配信する

あけましておめでとうございます。 2024年は大変な災害からの幕開けとなりました。一刻も早い復興をお祈り申し上げます。 今後はどうか素敵なニュースで溢れる一年になりますように🙏<h3 id="hcf83e1357e"> </h3><h2 id="h9707d3a59a">概要</h2>管理人の近況報告と、今後の更新予定のお知らせです。 <h2 id="hbf3b167600">Q. 昨年8月以降の更新がなかったけど何してた？</h2>A. このブログの実装に費やしてました。RSSの復活と、Push通知機能の改修です。 <h3 id="he53912881b">RSS</h3>Gatsby版trogではGatsbyプラグインでRSSを実装していましたが、いまご覧いただいているNext.js版trog用には、改めてRSS機能を実装し直す必要がありました。 Next.js版trogリリース後、RSS関連ページは「お探しのページは見つかりませんでした」と表示するのみで、RSSが使用不可能であることは非常にわかりづらい状態でした。申し訳ありませんでした。 昨年12月にGatsby版trogと変わりなく、正常に使えるように実装しました。引き続きRSS配信をお楽しみください。 また今回実装した、Next.jsでRSSを画像付きで配信する方法について、記事にまとめる予定です。気長にお待ちください🙋‍♀️ <h3 id="hb258e4b797">Push通知（延期）</h3>現在のtrogは、わたしが任意のタイミングでFirebase Cloud Message(FCM)のコンソール画面から、通知を配信しています。 通知にはタイトル・説明文・画像(一部端末のみ)を表示しており、通知をクリックするとtrogトップベージに遷移します。 昨年12月からクリックで任意のページに遷移できるように改修していたのですが、納得のいく仕上がりにならず、本機能のリリース延期を決定しました...。 next-pwaっていうパッケージを使用して、Service Worker<s>の実装をサボって</s>の動作をお任せしていたんですが、 このパッケージ、数年更新されてないんですよ。 有志による更新が行われている <a href="https://www.npmjs.com/package/@ducanh2912/next-pwa" target="_blank" rel="noopener noreferrer">https://www.npmjs.com/package/@ducanh2912/next-pwa</a> ←これを使うのが良さそうではあるんですが... プログラムから送信コマンドの実行ではなく「FCMコンソールから配信」したいし、 「クリック時に任意のページに遷移」したいし、 iPhoneでも任意のページに遷移するように... とかあれこれ実装していたところ、 正常な通知と、クリック時の遷移先情報を持たないオバケ通知が、同時に配信されるようになってしまいました... これはService Workerのお勉強をもう少しちゃんとしてから、パッケージに頼りきらず、必要な部分を自力で実装した方が良さそう...という判断から、なくなく延期した次第です。 FCMを用いたPush通知実装時のデバッグ方法など、たくさん知見が得られましたので、いくつかに分けて記事にしたいなとは考えています。 <h2 id="h9be0c3393d">おわりに</h2>PWA、いいのになあ。 ソフトウェアアプリケーションを作ろうと思うと、PCであればWindows・Mac・Linux向け、スマホであればiPhone・Android向けにそれぞれアプリを開発する必要があるわけですが、 PWAを採用すればWebサイトを実装するだけで、全端末でネイティブアプリケーションと同様に動かせるんですけどね... 「App Storeからアプリをダウンロードする」っていう操作はもう広く浸透しているのに、 Safariを開いて「ホーム画面に追加」は全然操作してもらえないらしいですね。 わたしには面倒くささの差がわからないんですが、なにが違うんですかね。 それとFCMがWeb Push通知向けの送信JSONと受信JSONオブジェクトを正確にドキュメントに残してくれればなあ。 散々漁ったけど想定した動作にならなくて、コンソールから確認したところ、 全然見たことないオブジェクトが返ってきて憤慨しました🗯️ Firebaseバージョンの違いとかあるのかもですが、それも全部ドキュメントに残してくれー。 これじゃ需要が発生しても、Web Push通知開発者の人口が増えないんだよ！ 頼むからPWAもっと普及してくれ！ えー、わたしは今日も元気に生存してます。 次回の記事の更新までどうか気長にお待ちください。 寒い日が続きますがお体に気をつけてお過ごしください。 * * * ※タイトルは邦ロックファン向け釣りタイトルであり、自己満です。本記事との関連は一切ありません。 ▲THE NOVEMBERS「最近あなたの暮らしはどう」▲ - Youtube <a href="https://www.youtube.com/watch?v=i_u0DgvYu2I" target="_blank" rel="noopener noreferrer">https://www.youtube.com/watch?v=i_u0DgvYu2I</a>

管理人の近況報告です。年始めから悲しいニュースが飛び込んできていますが、2024年がどうか素敵な一年になりますように。