安全性とパフォーマンス

Cuerda-Feed-total は、大規模なニュースサイトでも安心してお使いいただけるよう、「安全性」と「パフォーマンス」の両立を設計の前提としています。 ここでは、WordPress プラグインとして守るべき基本的な安全性への配慮と、Web サーバー／データベースに過度な負荷をかけないための工夫について、ご説明します。

WordPress コーディング規約への準拠

本プラグインは、WordPress Coding Standards（WPCS）に沿った実装を行うことを開発上のルールとしています。 PHP_CodeSniffer による静的解析を日常的に行い、セキュリティ・命名規則・パフォーマンス・国際化に関するルール違反をできるかぎり削減する方針です。

• グローバル変数・関数名・クラス名には cuerda_ / Cuerda_ プレフィックスを付与し、他テーマ・他プラグインとの衝突を回避
• デバッグ用コード（var_dump や debug_backtrace() など）は、開発時点でのみ使用し、リリース版からは除去
• 翻訳関数（__(), _e() など）を通じた国際化対応と、テキストドメインの統一
• PHPCS／Plugin Check が指摘する項目を逐次見直し、可能な範囲で警告を解消

これらは、見た目には現れにくい部分ですが、「長く保守できるコードであること」「他者が安心して読み解けること」の土台として大切にしています。

基本的な安全対策

Cuerda-Feed-total は、WordPress プラグインとして求められる基本的な安全対策を、すべての機能で踏まえています。

• すべての PHP ファイル冒頭で if ( ! defined( 'ABSPATH' ) ) { exit; } による直接アクセス防止
• 管理画面からの入力値に対する、sanitize_text_field() などのサニタイズと、保存前後のバリデーション
• フォーム送信時の check_admin_referer()／wp_verify_nonce() による CSRF 対策
• 設定変更・ライセンス画面・配信制御画面などへのアクセス時に、ユーザー権限（manage_options 等）の確認
• 外部接続（ライセンス認証・FTP・HTTP リクエスト）は WordPress HTTP API を介した実装とし、タイムアウトやエラー時の挙動を定義
• Yahoo!ニュースの FTP 接続情報など機微な情報は、wp_options 内に暗号化なしで保持しない設計とし、公開側テンプレートには一切出力しない

ニュース配信という性質上、「誤配信しないこと」と同じくらい、「システムとして安全であること」が求められます。 本プラグインは、WordPress の標準的な安全対策を踏まえたうえで、その上に独自機能を積み重ねる構造をとっています。

データベース負荷を抑える設計

Cuerda-Feed-total は、WordPress の標準テーブル（主に posts／postmeta／options）のみを利用し、新たなテーブルを追加しません。 そのうえで、データベースに対する負荷を抑えるために、次のような方針を採用しています。

• フィード生成に使用するクエリは、基本的にインデックスが効く範囲（投稿タイプ・ステータス・公開日など）を軸とし、必要な件数だけを posts_per_page で明示
• 「この配信先には出さない」といった制御は、シンプルな postmeta 条件で実現し、複雑な正規表現やフルテキスト検索は避ける
• 高コストになりがちな除外条件（post__not_in など）は慎重に用い、やむを得ず使用する場合も対象件数を限定
• 設定値は wp_options に一元化し、必要に応じて get_option() の結果をオブジェクトキャッシュ経由で再利用
• ライセンス状態や外部サーバーから取得した制御情報は、Transients API 等を用いてキャッシュし、毎リクエストごとの再取得を避ける

これにより、フィード取得の頻度が高い環境でも、データベースへの負荷が急激に高まらないよう配慮しています。

Web サーバーへの負荷分散

フィードは、本質的に「同じ内容が繰り返し取得される」性格を持つため、Web サーバー側の負荷も無視できません。 Cuerda-Feed-total では、次のような工夫で Web サーバーへの負担を和らげています。

• フィードごとに出力件数の上限を明示的に設定し、1 リクエストで過剰な記事数を返さない
• 重い処理（FTP によるファイルアップロード、ログの整理など）は WP Cron を介し、通常のページ表示とは分離
• ライセンス認証や外部 HTTP リクエストは、タイムアウト・リトライ・キャッシュを組み合わせ、フィード取得そのものを止めない設計
• デバッグ情報の出力やログ送信は、オプションから無効化できるようにし、本番環境では最小限の処理に抑えられるよう配慮

ニュースポータル側のクローラーは、一定間隔でフィードを取得し続けます。 その前提のもとで、「1 回あたり何をどこまで処理するか」を細かく制御することで、突発的な負荷の山を作らないようにしています。

フィード生成ロジックとパフォーマンス

Cuerda-Feed-total のフィード生成は、「共通エンジン」と「配信先別設定レイヤ」の二層構造で行われます。 この構造自体も、パフォーマンスと保守性の両面を意識したものです。

• Query Builder で「出す／出さない」の判定を一か所に集約し、重複したクエリを避ける
• Channel Renderer／Item Renderer では、配信先共通の処理をまとめ、ISP ごとの差分は設定ファイル側に寄せることで条件分岐を簡素化
• 関連リンクや地域コードなど、やや重いロジックは、必要な配信先・必要な場面にのみ適用する
• デバッグログの収集も、ファイルではなくデータベース（wp_options など）を用いることで、I/O 負荷を抑えつつ振る舞いを記録

これらの工夫により、「配信先が増えるほど処理が複雑になる」構造ではなく、「共通部分を保ちながら、必要な差分だけを薄く重ねる」構造を維持しています。 結果として、コードの見通しと処理の軽さを両立させることを目指しています。

運用現場と共存するための設計

安全性とパフォーマンスは、どちらか一方だけを優先すればよいものではありません。 Cuerda-Feed-total は、WordPress のコーディング規約に沿った堅実な実装を土台としながら、 ニュース配信の現場で求められる「止まらないこと」「重くならないこと」を、日々の設計判断の中心に置いています。

媒体ごとに異なる配信仕様に対応しつつも、Web サーバーとデータベースに無理のない負荷で動き続けること。 そのための小さな工夫の積み重ねを、このプラグインの安全性とパフォーマンスに込めています。