前回の「ブログシステムの知られざる知識を解き明かす（一）」では、ブログの歴史、私のブログのストーリー、ブログの読者層について紹介しました。今回はその続きとして、ブログの基本機能の設計ポイントを説明します。
目次
記事が長くなるため、4回に分けて配信します。目次は以下の通りです。
- 「ブログ」の歴史
- 私のブログのストーリー
- ブログの読者とは？
- ブログ基本機能の設計ポイント
- 4.1 記事（Post）
- 4.2 コメント（Comment）
- 4.3 カテゴリー（Category）
- 4.4 タグ（Tag）
- 4.5 アーカイブ（Archive）
- 4.6 ページ（Page）
- 4.7 購読
- 4.8 バージョン管理
- 4.9 テーマとパーソナライズ
- 4.10 ユーザーと権限
- 4.11 プラグイン
- 4.12 画像と添付ファイルの処理
- 4.13 不適切な言葉のフィルタリングとコメント審査
- 4.14 静的化
- 4.15 通知システム
- ブログのプロトコルと標準
- 5.1 RSS
- 5.2 ATOM
- 5.3 OPML
- 5.4 APML
- 5.5 FOAF
- 5.6 BlogML
- 5.7 Open Search
- 5.8 Pingback
- 5.9 Trackback
- 5.10 MetaWeblog
- 5.11 RSD
- 5.12 リーダービュー
- ブログシステムを設計する際の知識ポイント
- 6.1 タイムゾーンは本当にすべてUTC？
- 6.2 HTMLかMarkdownか
- 6.3 MVCかSPAか
- 6.4 セキュリティ
- おわりに
01 記事（Post）
私たちは毎日、長短さまざまな3～5記事を読むかもしれません。記事はブログシステムの中核を成す機能であり、ブログの内容と質は非常に重要です。
では、記事というビジネスタイプにはどのような名前を付けるべきでしょうか。データベースのテーブル名やコードの変数名、型名には「article」を使うのでしょうか？ 学校では「article」と習った気がします。実はブログタイプの記事は正しくは「post」と表現します。英語の「post」と「article」の違いは、postは気ままに書く記事であり、articleは論文のように丹念に練り上げられ、多くの引用があり、学術誌に掲載される可能性のある記事を指します。そのため、ブログシステムを設計する際には、コードの命名に「article」を使うのは避けるべきです。具体的に言うと、postには不正確で口語的な表現が含まれても構いません。例えばこの記事自体がpostです。一方、articleは言葉遣いの規範が求められ、「さあ」「見てみましょう」といった表現さえ使えません。
記事には、タイトル、Slug、作成日時、公開日時、更新日時、要約、本文などの要素が必要です。また、所属カテゴリー、タグ、読了数、いいね数などの副次的な情報も含まれます。Slugはブログの特徴であり、これは記事のURLを指します。例えば、私の記事「Try the New Azure .NET SDK」のURLはhttps://edi.wang/post/2019/12/5/try-the-new-azure-net-sdkですが、try-the-new-azure-net-sdkがこの記事のSlugです。Slugは「人間が読める」ことが重視され、通常はブログタイトルに対応する英語表現をハイフンで区切ったものです。SlugはブログのSEOにも重要な役割を果たします。もしブログ記事でデータベースのIDや記事タイトルのHTMLエンコーディングなどをURLに使っているなら、Slugに変更しましょう。特に中国語の記事の場合、タイトルがURLエンコーディングされるとSEOやリンク共有にとって災難です。Slugは一度決めたらなるべく変更しないほうが良いですが、ほとんどのブログシステムはSlugの変更をサポートしています。ただし、検索エンジンに収録された記事のSlugを変更すると404になります。比較的完成度の高いブログシステム（WordPressなど）は、301リダイレクトを使って元のURLが変更されたことを検索エンジンに伝えることができます。
要約には2つの役割があります。1つは一覧表示で記事のプレビュー情報を表示するため、もう1つはSEOのためで、descriptionというmetaタグに配置することで、検索エンジンが収録内容を正確に特定できるようになります。中国語コンテンツの場合、出力されるHTMLソースがエンコードされているかどうかに注意が必要です。ASP.NET CoreのデフォルトエンコーディングはSEOに悪影響を及ぼします（私のブログシステムは英語圏のユーザーを対象としており、中国語サポートを考慮していないため、この問題は解決していません）。
要約は自動的に記事の最初の数百文字を取得することも、WeChat公式アカウントのように手動入力させることもできます。私のブログでは自動で記事の最初の400文字を取得しています。SEOの観点から、私の記事は通常、冒頭の段落が概要になるようにしており、ユーザーが検索エンジンのプレビューページで正確な内容を確認でき、ページ上の無関係なUI要素を見る必要がありません。
記事のステータスは通常、下書き、公開、ゴミ箱です。ユーザーは公開された記事のみを閲覧でき、管理者はバックエンドで記事のステータスを変更できます。
02 コメント（Comment）
コメントはブログにおける作者と読者の主なインタラクション手段です。一部のブログでは読者がログイン後にのみコメントできるようにしていますが、ゲストでもコメントできるものもあります（私のブログやWordPressなど）。ログインのメリットは、読者を識別でき、スパム広告コメントを効果的に防止できることです。しかしログインを求めるとユーザーにとって操作が一つ増え、面倒に感じたユーザーはコメントしなくなる可能性があります。
私のブログやWordPressはデフォルトで、管理者がバックエンドでコメントを承認するまで表示されない設計になっています。これもスパム広告や嫌がらせ情報、悪意のある扇動的な発言などを効果的に回避できます。メールアドレスを提供したユーザーに対しては、管理者がバックエンドでコメントに返信でき、ブログシステムからユーザーにメール通知を送信できます。
技術系ブログの場合、コメントでMarkdown形式を許可することも検討できます。これはプログラマーの間で特に人気のある記法であり、GitHubで広く使われています。
コメントにはCAPTCHAやその他の人間確認技術を採用し、ボットによる広告投稿を防止する必要があります。しかし経験上、CAPTCHAは100%スパムを防げるわけではありません。なぜなら、現代のスパムは実際に人間がチームで行うものだからです。専用の会社、チーム、WeChatグループなどが存在し、国外にあります。そのため、キーワードフィルタリングやサードパーティのフィルタリングインターフェースの購入を検討する必要があるかもしれません。
コメントには文字数制限も設けるべきです。そうしないと、「水増し」やスクロールフラッドを引き起こす可能性があります。
コメント機能を自前で実装したくない場合は、サードパーティのコメントサービスを統合することもできます。つまり、ブログシステム自体はコメント機能を持たず、外部JSを読み込んで記事ページにコメント領域を「注入」する方法です。通常、これには記事のURLが変わらないこと（WordPressではパーマリンクと呼ばれます）が必要です。
03 カテゴリー（Category）
フォルダを作るように、記事を内容に応じて分類することをカテゴリーと呼びます。記事をカテゴリー分けすると、読者が同じ種類の記事を素早く検索できるようになります。
例えば、.NET、PHP、JSの記事は「開発技術（Development）」というカテゴリーに属します。一方、技術ニュースやキャリア経験の共有などの記事は「仕事」カテゴリーに属します。カテゴリーの区分は完全にユーザーが制御します。カテゴリーは多対多にもできます。例えば、ASP.NET CoreでAngularアプリケーションを開発する方法を紹介する記事は、「.NET技術」と「フロントエンド開発」の両方のカテゴリーに属することができます。
カテゴリーにはタイトル、説明、ルート名が必要です。例えば、私のブログではMicrosoft Azureのカテゴリーのタイトルは「Microsoft Azure」、説明は「The Best Cloud」、ルート名は「azure」です。タイトルはSEOのためにタイトルバーにも表示する必要があります。説明はタイトルを補足するもので、ユーザーが確認しやすくします。ルート名を設計する理由については、次のタグの項を参照してください。
カテゴリーのもう一つの機能は、OPMLやRSS/Atom購読フィードを生成することです。これについては第5章「ブログプロトコル」で説明します。
04 タグ（Tag）
記事で言及されるトピックがタグです。カテゴリーと同様に、タグも多対多の関係です。タグは記事を検索するためのキーワードのようなもので、関連する内容の記事を素早く見つけることができます。
タグでは、同じ意味のタグが重複する場合を考慮する必要があります。例えば、「VS」と「Visual Studio」は同じ意味であり、「VSCode」「VSC」「Visual Studio Code」も同じ意味です。そのため、ユーザーがタグを選択する際には、スマートサジェストで既存のタグを推薦するのが良いでしょう。
ブログシステム設計者にとっては、タグのURLも考慮すべきです。URLにタグの内容そのものを使うと多くの問題が発生します。タグ名が「Excel」のような単語全体であれば問題は起こりません。URLは通常https://yourblog/tags/excelになります。しかし、タグ名が「.NET Core」「C#」「Robots.txt」だと面白いことになります。https://yourblog/tags/robots.txtは一体tags下のrobots.txtファイルをリクエストしているのか、タグをリクエストしているのか？ ブログシステム設計者としては、すべてのtagsが受け取るルートパラメータはタグであるとプログラムで制限できますが、SEOツールやスキャナーはそう認識しません。彼らは慣習によりファイルをリクエストしていると解釈します。
URLエンコーディングが必要なタグ内容の場合は、さらにURLの可読性が失われ、SEOに悪影響を及ぼします。現代の検索エンジンがURLエンコーディングを適切に処理できると思い込んではいけません。URLがきれいかどうかはSEOに大きな影響を与えます。特にタグが中国語の場合は、すべてエンコードされるとURLが非常に長くなり、SEOだけでなくブロガーがリンクを共有するのにも悪影響を及ぼします。そのため、私のブログシステムではタグのURLを処理するために、各タグに正規化名（normalized name）を設計しました。システムがタグの内容から自動生成し、例えば「.NET Core」は正規化により「dotnet-core」になり、生成されるURLはhttps://edi.wang/tags/list/dotnet-coreとなります。
ユーザーが犯しやすい間違いの一つは、タグを検索キーワードのように使うことです。例えば、Visual Studio Codeに関する記事を書いた場合、「VSCode」「VSC」「Visual Studio Code」というタグを同時に付けてしまうことがありますが、実際には一つのタグで十分です。同じ意味のタグを複数付けると、読者がすべての関連記事を完全に検索できなくなります。検索エンジンにとっても同様です。したがって、タグを適切に使うことは、ブログ設計者とユーザー双方が注力すべきポイントです。
タグクラウド（Tag Cloud）は、ブログで最も人気のあるタグを一覧表示する機能です。通常、対応する記事数が多いタグをより大きなフォントや目立つ色で表示します。タグクラウドはブロガーの個性を表す属性となり、ブロガーがどのトピックに熱中しているかが一目でわかります（例えばWindows Phone？0.0）。
05 アーカイブ（Archive）
時間（年、月、日）で整理されたブログ記事がアーカイブです。カテゴリーとの違いは、アーカイブは時間のみを基準に記事を分類することです。アーカイブのSEOは、記事、カテゴリー、タグほど重要ではありません。そのため、URLを年月で区切る以外に特別なこだわりはありません。
例えば、https://edi.wang/archive/2019/9は2019年9月の記事を表します。https://edi.wang/archive/2019は2019年のすべての記事を表します。アーカイブ機能は主に読者が時間で検索し、ブロガーがその時期に何をしていたかを確認するために使われます。このような機能を設計することで、読者のブロガーに対する興味を高めることができ、個人の対外的なイメージを表現する手段にもなります。
06 ページ（Page）
ページはブログのオプション機能の一つであり、実際にはCMSの機能に近いものです。一部のコンテンツは「About（このブログについて）」ページなど、記事として公開するのに適していません。このようなページは通常、公開時の時間と無関係で、内容も頻繁に更新され、レイアウトデザインも非常に自由で、単なるテキストではありません。
ページは通常、コメント、タグ、カテゴリーなどの属性は必要ありませんが、公開日時と編集日時は持つことができます。記事と同様に、ページもSlugに注意する必要があります。
私のブログシステムでは、ページでサイドバーを非表示にするかどうかを選択でき、ユーザーはページのHTMLとCSSコードを完全に記述し、ナビゲーションメニューにページを追加することもできます。WordPressのページ機能はさらに充実しており、CMSシステムに近いです。
07 購読（Subscription）
読者がブログを購読する主な方法は、Feed（RSS/ATOM）とNewsletterです。Feed方式は本質的に受動的な購読であり、クライアントソフトウェアがサーバーにリクエストを送信して新着記事がないか確認し、クライアントに表示されます。Newsletterは一般的にメール形式で購読ユーザーに積極的に送信されますが、これにはブログシステムにメール購読機能の実装と、管理者によるメールサービスの維持が必要です。購読は通常、直近の新着記事のみを配信します（例えば最初の10～20件）。毎回すべての記事を配信するとクライアントが爆発するためです。
購読は通常、カテゴリー別に提供でき、特定のカテゴリーにのみ興味がある読者向けです。一部のブログシステムは記事のコメントの購読フィードも提供し、読者が「ツッコミ大会」を観覧できるようにしています。
RSSとATOMの詳細については、5.1、5.2節をご参照ください。
08 バージョン管理
CMSに近いブログシステムでは、通常バージョン管理機能が提供され、ユーザーが記事やページの過去バージョンにロールバックできるようになっています。バージョン管理を設計する際には、前に戻すだけでなく、再度戻せるようにする必要があります。通常、ユーザーが既に書いた記事を編集するたびに新しいバージョンが作成され、これはgitでのファイルのコミットに似ています。ブログのバージョン管理もコードのバージョン管理に似ており、記事の完全な内容を過去バージョンとして保存するか、毎回差分情報（delta）のみを保存するかを選択できます。完全な内容を保存すると後で多くの時間と労力を費やす必要はありませんが、より多くのストレージ容量を消費します。差分のみを保存するとデータベーススペースは節約できますが、実装に多くの労力がかかります。
09 テーマとパーソナライズ
使いやすいブログシステムは通常テーマをサポートします。なぜなら、パーソナライズはブログ本来の特性の一つだからです。WordPressは大量のテーマライブラリを蓄積しており、自作テーマも可能です。しかし、私のブログはテーマカラーの変更のみ対応しており、改善の余地が大きくあります。
10 ユーザーと権限
ブログシステムは個人、チーム、ブログプラットフォームに分かれます。個人ブログシステムは通常シングルユーザー（私のブログなど）であり、権限や登録機能などを設計する必要はありません。マルチユーザーブログでは、ブログ管理者、審査担当者、執筆者、コメント管理者など、異なる役割と権限を実装する必要があります。シングルユーザーでもマルチユーザーでも、成熟したサードパーティのRBACソリューションを統合するのが最も効率的な選択かもしれません。ほとんどのサードパーティソリューションはSSOもサポートしており、例えば私のブログがサポートするAzure ADなどです。
11 プラグイン
プラグイン機能により、ブログコードを変更せずに必要に応じてブログの機能を拡張できます。WordPressやBlogEngineはプラグインをサポートしていますが、Moongladeはまだ対応していません。
12 画像と添付ファイルの処理
画像フォーマット
2020年現在、画像フォーマットは非常に自由で、一般的なブログではJPGが多く、プログラマーのブログではPNGが多いです（どちらもスクリーンショットのため）。WeChat公式アカウントのようにWEBP形式を採用することも可能であり、読者のデバイスが互換性があれば良いです。一般的にBMP形式はファイルサイズが大きくネットワーク転送が遅くなるため推奨しません。同様に、GIFもサイズ制限に注意する必要があります。
ブログシステムが画像を出力する際には、正しいMime Typeを使用してクライアント互換性を確保する必要があります。通常、静的ファイルを直接出力する場合はブログ作成者が手動でMime Typeを処理する必要はありませんが、独自の画像処理ロジックを持つブログ（私のMoongladeなど）では、画像本来のMime Typeを保持することに注意が必要です。
画像の透かし
アップロードされた画像に自動で透かしを入れると著作権保護に役立ちます。透かしの内容は通常ブログのURLやブロガーの名前です。透かしを追加する際には、画像のサイズに合わせて透かしの比率を調整し、画像内の重要な内容を隠さないようにして読みやすさを確保します。小さすぎる画像の場合は、透かしを省略することも検討できます。
また、ブログが発展過程で名称変更される可能性を考慮し、透かし追加時に元の画像をシステム内に保持しておき、後で透かし内容を更新できるようにすることをお勧めします。
具体的な方法は、私の記事「ASP.NET Coreでアップロードした画像に透かしを入れる」をご参照ください。
画像の保存
画像をどこに保存するかは検討すべき問題です。一般的には3つの場所があります：ファイルシステム、データベース、クラウド上のBlobストレージサービス。MoongladeはファイルシステムとAzure Blobストレージをサポートしています。それぞれに長所と短所があります。
ファイルシステムの利点は、静的ファイルを直接配信する速度が最も速いことです。しかし、画像ディレクトリがWebサイトのディレクトリ内にある場合、ディレクトリが読み取り専用ではなくなり、潜在的なセキュリティ問題を引き起こす可能性があります。例えば、初期のASPフォーラムシステムでは、拡張子を変更したWebシェルをアップロードすることが流行しました。2020年現在、Webサーバーに実行可能ファイルをアップロードすることはほぼ不可能ですが、依然としてリスクは存在します。たとえ家に007が警備員としていても、夜はドアに鍵をかける必要があるのと同じです。
データベースに画像を保存する方法はセキュリティが最も高く、ブログのデータが一か所に集まるため管理とバックアップが容易です。10年以上前には非常によく使われましたが、画像の読み書きはデータベースに負荷がかかり、さらにWebサイトから出力することで二重の負荷がかかるため、一般的には推奨しません。
一方、クラウド上のBlobストレージサービスは、現在の時代に最も適したソリューションです。画像をBlobに保存することで、サーバーのディレクトリを読み取り専用に保つだけでなく、クラウドのセキュリティ機能を利用して不正アクセスを制限し、CDNによる画像出力の高速化も実現できます。強いて欠点を挙げるとすれば、クラウドサービスには追加費用がかかることですが、お金がないのは自分の問題であり、クラウドの問題ではありません。
画像のホットリンク防止
Webサイト開発者としては、自分のサイトの画像が他のサイトに直接参照されるのを防ぎたいことがあります。これにより、データセンターでの莫大な帯域消費が発生する可能性があり、つまり他の人が私たちの画像を使用することで、私たちがその費用を支払うことになります。例えば、あなたのサイトがa.comで、http://a.com/facepalm.jpgという画像を持っているとします。b.comが自社サイトでimgタグを使ってあなたの画像を参照すると、ネットワークリクエストはあなたのデータセンターに届き、あなたのリソースを消費します。そのため、ブログはオプションでホットリンク防止機能を有効にすることができます。具体的な方法は、私の記事「ASP.NET / Core 画像ホットリンク防止」をご参照ください。
添付ファイル
プログラマーの技術ブログでは、読者にコードサンプルなどの添付ファイルを提供することがよくあります。添付ファイル機能の設計は画像保存の設計と非常に似ており、十分に可能です。しかし、技術ブログではコードサンプルなどの添付ファイルをGitHubなどの他のサイトにホスティングし、読者にダウンロードを提供することをお勧めします。
自分のブログで添付ファイルのダウンロードを実装することの欠点は以下の通りです。
大容量ファイル
Webサーバーやファイアウォール製品によってファイルサイズの制限は異なり、ブログをデプロイするユーザーがこれらの制限を管理できない可能性があります。そのため、大きな添付ファイルがダウンロードできなくなることがあります。
ドメインとIPブラックリスト
一部の企業や組織（特にセキュリティ基準の高いソフトウェア企業）では、ホワイトリストにないドメインからのファイルダウンロードをブロックします。ブラウザでそのドメインのページを正常に開くことはできても、ファイルのダウンロードができない場合があります（ファイアウォールはHTML/CSS/JSなどは許可するが、ZIP、EXEなどは許可しない）。プログラマーブログの読者はそのような企業にいる可能性があります。
CDNリソースの消費
添付ファイルが多く、サイズが大きく、画像保存と同様に添付ファイルシステムにCDNを適用している場合、CDNプロバイダーの課金モデルによっては、従量課金の場合、添付ファイルのダウンロードで財布が急速に痩せる可能性があります。
一方、GitHub、OneDriveなどのサードパーティのファイルダウンロードを利用する利点は以下の通りです。
- √ ファイルをブログ記事だけでなく、他の場所でも共有できます。
- √ これらのサードパーティサービスには独自のCDNがあり、自分の財布を心配する必要がありません。
- √ 多くのファイルホスティングサービスにはファイルの削除、復元、バージョン管理、権限などの完全な管理機能があります。これをブログシステム内に実装するには膨大な時間がかかります。
13 不適切な言葉のフィルタリングとコメント審査
ブログには敵意のある人や広告を投稿する人が現れることが避けられないため、通常は不適切な言葉のフィルタリングとコメント審査が必要です。審査なしでユーザーのコメントをそのまま記事の下に表示すると、ブロガーやサイト自体に悪影響を及ぼす可能性があります。例えば、政治的にセンシティブな発言や不適切な広告がバックエンド審査を経ずに直接表示され、あなたのブログが中国本土にデプロイされている場合、すぐに停止・是正を命じられ、プログラマーとして「入門から収監まで」の成就をアンロックする可能性があります。海外にデプロイしていても安全だと思ってはいけません。ヘイトスピーチのような内容はハッカーを引き寄せ、ブログに毒を盛り、あなたや読者を脅迫する可能性があります。
そのため、個人ブログには不適切な言葉のフィルタリングとコメント審査機能を有効にすることを強くお勧めします。WordPressと私のMoongladeブログシステムはどちらも不適切な言葉のフィルタリングとコメント審査をサポートしています。
14 静的化
初期のニュースシステム、ブログ、CMSでは、大量アクセス時の応答速度を向上させるために静的化技術が採用されていました。つまり、サーバーサイドでレンダリングされたページを実際のHTMLファイルとしてディスクに保存し、静的ファイルとして出力します。Webサーバーによる静的ファイルの出力は非常に効率的であり、変わらないコンテンツに対してはユーザーが後続アクセスしてもデータベースにヒットしないため、サーバーの負荷を大幅に軽減できます。2020年の現在、静的化は唯一のソリューションではなく、Redis Cacheを使用してデータベースへの頻繁なアクセスを減らすこともできます。個人ブログの場合、アクセス数が多くなければ、静的化やRedisを開発・保守コストをかけて実装する必要はありません。しかし、ブログプラットフォームを設計しているのであれば、静的化やRedisを使用したほうが良いでしょう。
15 通知システム
ブログは通常、メール形式で管理者やユーザーに通知を送信します。ただし、ブログがメールを使用して通知をプッシュしなければならないという規範や合意はなく、ブログシステム設計者が自由に決定できます。
通知には通常以下のものがあります。
- ブロガーへの通知：新着コメント、記事が他のブログに引用された場合（5.8、5.9章参照）。
- ユーザーへの通知：新着記事の公開（Newsletter購読）、コメントへの返信、コメントの承認または却下。
メール通知システムでは、スパムメールとユーザープライバシー保護の問題に注意する必要があります。
スパムメールがブロガー自身に送られるのは大きな問題ではありませんが、メールシステムがブロガーの許可なしに読者にメールを送信できるようになっていないかどうかに注意する必要があります。それが悪用されてスパムメールが送信され、サーバーがブラックリスト入りする可能性があります。一部のサーバープロバイダー、例えばMicrosoft Azureでは、メールに関するさらに厳しいルールがあり、一部のPaaSサービスにデプロイされたコードでSMTPエンドポイントを呼び出すと直接ブロックされることがあります。
ユーザープライバシー問題については、ユーザーがブログシステムにメールアドレスを提供する際に、そのメールアドレスがどのように使用されるかをユーザーに知らせる必要があります（プライバシーポリシーやページの見える場所に記載できます）。また、ユーザーがそのメールアドレスを通知プッシュに使用することを許可するかどうかのチェックボックスを設けることもできます。もう一つの問題はメールアドレスの露出です。これは通常、Newsletterの一括送信で発生します。すべてのユーザーのメールアドレスをToやCCに入れると、各ユーザーが他の全員のメールアドレスを知ることになり、相互に連絡を取ったり詐欺を行う可能性があります。そのため、NewsletterではBCCを使用するか、個別に送信し、購読解除を許可する必要があります。
Moongladeの通知システムはメール方式を採用していますが、設計は基本的なものです。完全な通知システムにはメッセージキューとイベント設計が必要であり、サードパーティサービスを利用する必要があります。例えば、AzureではStorage Queue + Function App + SendGridを使用することで、大量のメール送信時のトラブルを回避できます。
次回は主に【ブログプロトコルと標準】について紹介します。お楽しみに。
