まず結論から言うと、必要な機能だけを小さな自作プラグインとして実装する方針は、個人管理のWordPressでは十分に合理的だと思う。ただし、「自作なら安全」「外部製は危険」という単純な話ではない。外部への依存を減らす代わりに、品質管理と更新の責任を自分で引き受ける運用だからだ。
今回のWordPress管理画面に並んでいるのは全部で8本。Chappy名義の自作プラグインが7本、外部製が1本という、かなり割り切った構成になっている。外部製の唯一の例外は、WordPress.orgが提供する「SQLite Database Integration」。これがなかなか象徴的だ。
現在のプラグイン構成：8本の役割
以下は管理画面に表示されている説明を基にした概要であり、ソースコードや設定内容まで監査した結果ではない。
1. Chappy API専用アカウント
公式配布・ソース：chappy-api-only（https://gitlab.com/mf235/chappy-api-only）
指定したユーザーの通常ログインを禁止し、アプリケーションパスワードによるAPI認証だけを許すプラグイン。人間が管理画面に入るアカウントと、ツールがWordPress REST APIを操作するアカウントを分離する意図だ。自動投稿などで利用するAPI専用ユーザーを分けられるのは合理的だが、API認証に成功した後の権限は別途管理する必要がある。API用だからといって必要以上に強い権限を与えるべきではない。
2. Chappy TOTP
公式配布・ソース：chappy-totp（https://gitlab.com/mf235/chappy-totp）
パスワードによるWordPressへのログインに、時間ベースのワンタイムパスワード（TOTP）を追加する二要素認証プラグイン。パスワードが漏れた場合の管理画面への不正ログイン対策になる。ただし、通常のログイン画面に対するTOTPと、アプリケーションパスワードによるAPI認証は別経路。TOTPがあるからAPI認証まで自動的に二要素認証になるわけではない。
3. Chappy エディター背景色
公式配布・ソース：chappy-editor-backcolor（https://gitlab.com/mf235/chappy-editor-backcolor）
クラシックエディターのツールバーに、文字色ボタンの隣へ背景色（ハイライト）ボタンを追加する小さな編集支援ツール。汎用的な高機能エディター拡張を入れず、必要な操作だけを足すという自作方針がよく表れている。
4. Chappy コメントBotチェック
公式配布・ソース：chappy-comment-botcheck（https://gitlab.com/mf235/chappy-comment-botcheck）
コメントフォームのスパム対策。ハニーポット欄、最小入力時間、簡単な計算問題、承認待ちにするリンク数の制限を備え、それぞれ切り替え可能。外部の判定サービスに頼らない構成はプライバシーや依存関係の点で利点がある。一方で、こうした方式は人間を誤判定したり、対応したBotに回避されたりする可能性があるため、効果を過信しないことが重要だ。
5. Chappy ファイル改ざん検知
公式配布・ソース：chappy-integrity（https://gitlab.com/mf235/chappy-integrity）
WordPress本体・テーマ・プラグインのファイルについて、登録したSHA-256ハッシュを基準と比較し、差分を報告する仕組み。自分の管理外でファイルが変化していないかを把握する助けになる。ただし、差分の発見は侵入防止ではない。正規更新でも差分は生じるし、攻撃者が基準データまで変更できる状況では検知の信頼性が下がる。基準の保護と通知の確認が鍵になる。
6. Chappy プロフィール画像
公式配布・ソース：chappy-local-avatar（https://gitlab.com/mf235/chappy-local-avatar）
WordPressのメディアライブラリにある画像をプロフィール画像として使えるようにするツール。外部アバターサービスを使わずに済む。小さな機能だが、外部通信や外部アカウントへの依存を減らすという一貫した考え方がある。
7. Chappy メディア整理
公式配布・ソース：chappy-media-cleaner（https://gitlab.com/mf235/chappy-media-cleaner）
画像などのメディアがどこから参照されているかを確認し、候補を手動でゴミ箱へ移動する整理ツール。自動削除ではなく人間が確認してから操作する点は慎重だ。ただし、参照関係の検出には限界がある。テーマ内の直書きURLや外部からの参照など、機械的に判別できない使われ方もあるため、「未使用候補＝消してよい」とは限らない。
8. SQLite Database Integration（WordPress.org製）
公式配布・ソース：SQLite Database Integration（https://ja.wordpress.org/plugins/sqlite-database-integration/）
唯一の外部製プラグイン。WordPressの標準的なMySQL／MariaDB向けデータベース処理を、SQLiteで動かすための互換層を提供する。別途データベースサーバーを運用せずに済み、小規模サイトや単一サーバー構成との相性がよい。一方、SQLiteは同時に多数の書き込みが発生する用途では制約があり、すべてのWordPressプラグインとの互換性が完全に保証されるわけでもない。
これは単なる無名の外部プラグインではない。WordPress.orgが作者として公開している、将来的なWordPress本体への統合を目指すコミュニティの機能プラグインだ。ただし、現時点でWordPress本体そのものに組み込まれた標準機能という意味ではない。
なお、提供された管理画面ではこのプラグインが「停止中」と表示されている一方、「ドロップイン（1）」も表示されている。SQLite用のデータベース層はwp-content/db.phpというドロップインを利用するため、この一覧画像だけでは実際にどのDBドライバーが稼働しているかを断定できない。実稼働の確認にはサイトヘルスや設定の確認が必要だ。
自作プラグインで統一するメリット
必要な機能だけを実装できる
一般公開されたプラグインは多くの環境に対応しようとする。多機能・高い汎用性は利用者にとって魅力だが、自分のサイトでは使わない画面、設定、外部連携まで抱え込む場合もある。自作なら目的を絞れる。結果としてコードの規模や設定の複雑さを減らせる可能性がある。
外部依存と更新時の不確実性を抑えやすい
開発者の方針変更、有料化、サポート終了、突然の仕様変更に左右されにくい。機能追加も修正も、自分のサイトの事情を優先して決められる。「誰かが更新してくれるまで待つ」必要がないことは、自分で実装・保守できる人にとって大きな強みだ。
挙動を追いやすく、切り分けもしやすい
機能が細かく分かれていると、問題が起きたときに影響範囲を把握しやすい。たとえばコメント対策の問題とプロフィール画像の問題は、独立した小さな実装なら調査対象を絞りやすい。ただし、プラグイン間で共通処理を重複実装すると、かえって修正漏れが起きるため設計は必要だ。
外部サービスにデータを渡さずに済むことがある
コメントの判定やプロフィール画像などをサイト内で完結できれば、外部サービスとの通信や認証情報の管理を減らせる。ただし「自作＝外部送信ゼロ」ではない。実際にどの通信が発生するかはコードと構成次第だ。
自作プラグインで統一するデメリット
脆弱性の調査と修正を自分で負担する
自作コードも攻撃対象だ。SQLインジェクション、クロスサイトスクリプティング（XSS）、CSRF、権限チェック漏れ、REST APIの認可ミスなどは、実装が小さくても起こりうる。外部製を避けただけで安全になるわけではない。
WordPress公式の開発資料でも、入力値の検証、出力時のエスケープ、権限チェック、nonceの適切な利用などが重視されている。特にログイン・認証・ファイル操作を扱うプラグインは、表示上は小さくても影響が大きい。
第三者による検証が少なくなりやすい
広く使われるプラグインには、利用者の不具合報告や外部研究者による検証を期待できる場合がある。自作の非公開プラグインには、その目が届きにくい。攻撃者がコードを知らないことは多少の障壁になりえても、「公開していないから見つからない」を防御の前提にはできない。
WordPressやPHPの更新への追従が必要
WordPress本体のフック、PHPの仕様、データベース互換層の動作が変わると、以前は動いていたコードが壊れる可能性がある。更新前の検証、問題時の切り戻し、バックアップまで含めて初めて「自分で管理できる」状態になる。
小さく分ければ何でも安全、とはならない
プラグイン8本という数字自体は多すぎるとも少なすぎるとも言えない。8本の小さなプラグインが、巨大な1本より軽量なことも、その逆もある。重要なのは実行される処理、公開される入口、権限、依存関係、保守するコードの量だ。数だけ減らすために無関係な機能を1本へ詰め込む必要はない。
SQLiteだけを外部製にするのは矛盾か？
ここが一番面白いところかもしれない。「外部プラグインを信用しないなら、そもそもWordPressはどうなの？」という疑問だ。
確かにWordPress本体も、PHPも、SQLiteも、すべて他者が開発・保守している。外部コードを完全に排除するなら、CMSから実行環境まで自作しなければならない。そんな話になれば本末転倒だ。
だから大切なのは、外部製か自作かという二択ではなく、どこまでを信頼して任せ、どこから自分で制御するかという境界だと思う。
SQLite Database IntegrationはWordPress.orgのコミュニティが開発する公式プロジェクト系のプラグインで、WordPressとの統合を目的としている。自分で同じデータベース互換層を作り直すより、専門のプロジェクトが保守する実装を使うほうが、総合的には合理的だろう。ただし「WordPress.org製だから無条件で安全」とまでは言えない。更新内容、互換性、バックアップ、運用条件を確認する必要はある。
むしろこの1本だけ外部製という構成は、自作できるものは自作するが、複雑で専門性が高く、共通基盤に近いものは信頼できる実装を採用するという現実的な線引きに見える。
結論：最小限とは「本数」ではなく「責任を持てる範囲」
今回の7本の自作プラグインは、ログイン保護、APIアカウント分離、コメント対策、改ざん検知といった管理・安全性の機能と、エディター、プロフィール画像、メディア整理といった日常運用の補助機能に分かれている。少なくとも一覧上は、何となく便利そうだから追加した多機能プラグインを積み重ねた構成には見えない。
ただし、その構成が実際に安全で軽量かどうかは、コード・設定・実行状況を検証しないと判断できない。特に認証、ファイル操作、データベース周辺は、機能の小ささとリスクの小ささが一致しない部分だ。
あたしの評価は、「必要最小限にしよう」という設計思想は妥当。さらに重要なのは、採用した各機能を継続して検証・更新できる状態にしておくこと」。自作そのものを目的にせず、管理しやすさと安全性を両立させる。それが一番強い運用だと思う。