月100記事でも落ちない！Xserverでデータベース最適化する方法

ワードプレス
2025.05.08

以前、月100記事ペースで更新していた時期がありました。

その時、データベースのメンテナンスを怠っていたため、サイトの表示速度がどんどん遅くなっていきました。

特に問題だったのが、自動保存とリビジョンの大量蓄積。

月100記事×10リビジョン×12ヶ月で、12,000件以上のゴミデータが溜まっていました。

データベースサイズが1.2GBに膨れ上がり、管理画面も重くなり、ページ表示も1.5秒以上かかる状態に。

初めて最適化を実行したところ、1.2GB→400MBに削減。

表示速度も劇的に改善しました。

現在は記事を厳選する方針に変えましたが、定期的なメンテナンスは継続しています。

この記事では、月100記事時代に学んだデータベース最適化の重要性を解説します。

  1. 1. はじめに｜「記事は増えるのに表示は遅くならない」サイトを作る
    1. 1-1 ブログが重くなる典型パターン
    2. 1-2 Xserver × WordPress の強みを活かす
    3. 1-3 ゴールと全体像
  2. 2. 基礎理解｜WordPress × Xserver のデータベース構造
    1. 2-1 MariaDB と InnoDB の特徴
    2. 2-2 主要テーブル早見表
    3. 2-3 よく詰まる３つの箇所
  3. 3. 現状把握｜遅延を数値化する３つの計測ツール
    1. 3-1 Query Monitor プラグイン
    2. 3-2 phpMyAdmin で EXPLAIN
    3. 3-3 Xserver リソースグラフ
  4. 4. 投稿数急増時に効く“３大メンテナンス”
    1. 4-1 投稿リビジョン削除
    2. 4-2 ゴミ箱・自動下書きの定期パージ
    3. 4-3 トランジェントのクリーンアップ
  5. 5. 必須プラグイン設定ガイド
    1. 5-1 WP-Optimize（定番の“掃除”オールインワン）
    2. 5-2 Advanced Database Cleaner（細かく選べる掃除屋）
    3. 5-3 競合させないコツ
  6. 6. Xserverサーバーパネルで出来る高速化４選
  7. 7. インデックス最適化｜クエリを最大10倍速くする実例
    1. 7-1 postmeta 肥大化を抑える
    2. 7-2 autoloaded options を洗う
    3. 7-3 安全に操作する３ステップ
  8. 8. Redis Object Cache 導入ステップ
    1. 8-1 サーバーパネル側の有効化
    2. 8-2 WordPress プラグイン設定
    3. 8-3 ベンチマーク確認
  9. 9. マルチサイト／複数 DB 分割の拡張プラン
    1. 9-1 サブドメインごと DB を分けるメリット
    2. 9-2 DB 接続プール（読み書き分離）のアイデア
  10. 10. 実践チューニング事例３選
  11. 11. 自動化｜月次・週次メンテバッチ
    1. 11-1 WP-CLI スクリプト例（週次）
    2. 11-2 Slack 通知（失敗検知）
  12. 12. トラブルシューティング（代表 5 パターン）
  13. 13. セキュリティと高速化を両立させるポイント
  14. 14. よくある質問
  15. 15. 用語集
  16. 16. まとめ｜増えても速いサイトを維持する３大原則
  17. 17. まとめ

1. はじめに｜「記事は増えるのに表示は遅くならない」サイトを作る

1-1 ブログが重くなる典型パターン

  • 投稿一覧が 1,000 本を超える
  • サムネイルや広告を呼ぶ postmeta が爆発的に増殖
  • wp-cron やバックアップ系プラグインが深夜に大量クエリ

結果──管理画面が 500 ms → 3 秒、フロントも TTFB（最初の応答） が 1 秒を超え、読者が離脱しやすくなります。

1-2 Xserver × WordPress の強みを活かす

Xserver はエンジン側で MariaDB + SSD RAID を採用しており、ライトユーザーなら無調整でも速いのが特徴です。ただし 月100記事ペース で書き足すと、デフォルト設定だけではいずれ限界が来ます。

本記事は「難しい SQL を覚えなくても、クリック操作とコピペで改善できる」ことを最優先に構成しています。

1-3 ゴールと全体像

  • 平均 TTFB 1 秒未満 をキープ
  • スロークエリ 0 本 を目標に週次で自動監視
  • 手順は 「計測 → 掃除 → キャッシュ → 拡張」 の４段階
エックスサーバーに申し込む

2. 基礎理解｜WordPress × Xserver のデータベース構造

2-1 MariaDB と InnoDB の特徴

項目 概要 なぜ気にする？
MariaDB 10.x MySQL 互換。Xserver は最新 10 系 JSON 型や仮想列が使える
InnoDB デフォルトのストレージエンジン 行ロック＆自動リカバリーで安全
バッファプール よく使うデータをメモリに保持 アクセスが多いと不足→遅延

Xserver ではバッファサイズ調整は管理画面で不要。テーブル設計とクエリ数を減らす ことが実務的です。

2-2 主要テーブル早見表

テーブル 主な内容 ボトルネック要因
wp_posts 記事本文・タイトル 投稿数が直接増える
wp_postmeta カスタムフィールド 広告・プラグインが大量書き込み
wp_options サイト設定・キャッシュ オートロードで肥大
wp_comments コメント スパム爆撃で急肥大

注意：wp_ はプリフィックス例。実サイトに合わせて読み替えてください。

2-3 よく詰まる３つの箇所

  1. postmeta の全件走査
  2. autoload=’yes’ の options を毎リクエスト読込
  3. 同期 WP-Cron がアクセス時に発火 → ピーク帯で遅延

3. 現状把握｜遅延を数値化する３つの計測ツール

3-1 Query Monitor プラグイン

  1. インストール → 有効化
  2. 管理バーに 「Queries ×× ms」 が出現
  3. 遅い順に並べ「0.1 秒以上」「重複 10 回以上」を赤字で確認

チェックポイント

  • postmeta に LIKE 検索が出ていないか
  • SELECT *（全カラム取得）が頻発していないか

3-2 phpMyAdmin で EXPLAIN

  1. サーバーパネル → phpMyAdmin → 対象DB
  2. 「SQL」タブ → 遅いクエリを貼り EXPLAIN
  3. type 列が ALL（全件走査）ならインデックス未使用

3-3 Xserver リソースグラフ

  • インフォパネル → サーバー利用状況
  • DB CPU・IO Wait が 50 % を何度も超える日は要チューニング
  • グラフを CSV で保存し、最適化後に再計測するのが確実です

4. 投稿数急増時に効く“３大メンテナンス”

4-1 投稿リビジョン削除

WordPress は記事を更新するたびに リビジョン を無制限保存します。

  • wp_posts に 5,000 記事 → リビジョンで 30,000 行超もザラ
  • 解決：wp-config.php に１行追記
phpコピーする編集するdefine('WP_POST_REVISIONS', 5); // 最新5件だけ保持

既存の膨大なリビジョンは WP-CLI かプラグインで一括削除可。

bashコピーする編集するwp revisions clean --before-date=30days

4-2 ゴミ箱・自動下書きの定期パージ

  • wp_posts の post_status = 'trash' や auto-draft が残る
  • 30 日以上前を cron で削除
bashコピーする編集するwp post delete $(wp post list --post_status=trash --format=ids)

4-3 トランジェントのクリーンアップ

キャッシュ系プラグインが wp_options に transient を量産します。

  • Advanced Database Cleaner で「期限切れトランジェント」を選択 → 週1自動削除
  • オートロード肥大を防ぎ、メモリヒット率が向上

5. 必須プラグイン設定ガイド

ポイント：プラグインは「入れただけ」では速くなりません。正しいチェックボックスを ON にすることで、本領を発揮します。

5-1 WP-Optimize（定番の“掃除”オールインワン）

  1. インストール → 有効化
  2. 左メニュー ▶ WP-Optimize ▶ 「データベース」
  3. 下表どおりにチェックを入れて「最適化を実行」
項目（日本語表示） 目的 備考
リビジョンをクリーン 不要な履歴を削除 直近 5 件残したい場合はオフ
自動下書きをクリーン 下書きゴミ掃除 10 日に 1 回で十分
ゴミ箱を空に 投稿ゴミ箱を削除 30 日残す場合はオフ
未承認コメントをクリーン スパム溜まり防止 Akismet 併用なら月 1
一時オプションをクリーン トランジェント削除 必ず ON

スケジュール
画面下部「自動最適化」→ 週1・深夜 2:30 を推奨。

5-2 Advanced Database Cleaner（細かく選べる掃除屋）

  1. 「設定 ▶ WPデータベースクリーン」
  2. タブ【オプション】 → autoload = yes かつ 「サイズ 500 KB 以上」を目視
  3. 不要キャッシュ（多くはプラグイン名が分かる）だけチェック →「Delete」

注意

  • 誤って削除するとプラグインが初期化されることがあるため、必ずバックアップ後に実行。

5-3 競合させないコツ

  • 「掃除系」は 1 つだけ に絞る
  • キャッシュ系（WP Rocket、LiteSpeed Cache 等）と掃除系を混在させる場合は、掃除のあとにキャッシュを全部削除しておくと不整合が出ません。

6. Xserverサーバーパネルで出来る高速化４選

手順 操作 効果 所要時間
① MySQL バージョン確認 サーバーパネル ▶ MySQL設定 最新10系は高速JSON関数対応 1 分
② PHP LSAPI+OPcache PHP Ver.切替 ▶ ハンドラ「LSAPI」& OPcache ON 動的処理をメモリに保持 2 分
③ Xアクセラレータ Ver.2 高速化 ▶ Xアクセラレータ[Ver.2] ページ全体をキャッシュ 1 分
④ wp-cron をサーバーcronへ crontab設定 ▶ */15 * * * * php /home/アカウント/public_html/wp-cron.php ピーク時DB負荷を回避 5 分

手順④の詳しい方法

  1. wp-config.php 最下部に phpコピーする編集するdefine('DISABLE_WP_CRON', true);
  2. サーバーパネル →「Cron設定」→15 分間隔で php /home/ユーザ名/ドメイン/wp-cron.php を登録

→ 投稿閲覧時に wp-cron が走らなくなるため、ピーク帯のCPUスパイクが激減します。

エックスサーバーに申し込む

7. インデックス最適化｜クエリを最大10倍速くする実例

7-1 postmeta 肥大化を抑える

a. 不要メタ削除

sqlコピーする編集するDELETE FROM wp_postmeta
WHERE meta_key IN ('_edit_lock','_edit_last')
  AND post_id IN (SELECT ID FROM wp_posts WHERE post_status = 'publish')
  AND meta_id < (SELECT MAX(meta_id)-10000 FROM wp_postmeta);
  • 編集ロック情報は古いものが無意味。

b. カスタムインデックス追加
phpMyAdmin ▶ SQL タブ

sqlコピーする編集するALTER TABLE wp_postmeta
ADD INDEX meta_key_val (meta_key(191),meta_value(191));

Elementor や広告系プラグインで meta_key='views' などを頻繁に検索する場合に 全件走査→数ミリ秒へ短縮 できます。

7-2 autoloaded options を洗う

  1. phpMyAdmin ▶ SQL
sqlコピーする編集するSELECT option_name, LENGTH(option_value) AS size_kb
FROM wp_options
WHERE autoload='yes'
ORDER BY size_kb DESC
LIMIT 20;
  1. 上位に 1 MB 超があれば、そのプラグイン設定でキャッシュ期間や保存量を減らす。
  2. どうしても不要なら
sqlコピーする編集するUPDATE wp_options SET autoload='no' WHERE option_name='不要オプション名';

7-3 安全に操作する３ステップ

  1. フルバックアップ（サーバーパネル「バックアップ」）
  2. phpMyAdmin 右上 ▶ 「エクスポート」で options と postmeta だけ別に保存
  3. SQL 実行後、サイトを 3 分ほど触り エラーが出ないか手動確認

8. Redis Object Cache 導入ステップ

ねらい：データベースへの同じ問い合わせを “毎回” 走らせず、結果をメモリに置いて一瞬で返す仕組みを足します。Xserver では無料で使えます。

8-1 サーバーパネル側の有効化

  1. サーバーパネル →「Redis」
  2. 「有効にする」をクリック → ポート番号（通常 6379）が表示されれば完了
  3. 5 分ほど待つと Redis プロセスが立ち上がります

8-2 WordPress プラグイン設定

  1. **「Redis Object Cache」**をインストール → 有効化
  2. 「設定 → Redis」
    • Status が Not Connected と出る → 「Enable Object Cache」ボタンをクリック
    • Connected: True / Status: Connected になれば OK
  3. 「Drop-in」欄が advanced-cache.php に変わっていることを確認

8-3 ベンチマーク確認

  • Query Monitor ▶ 「Environment」→ Object Cache (Hits / Miss)
  • ヒット率が 70 % を超えると DB クエリ数が 1/3〜1/5 に減少
  • 1 週間ほど運用し、キャッシュが効き過ぎて更新が出ない場合は「設定 → Redis → Flush Cache」で手動クリア

9. マルチサイト／複数 DB 分割の拡張プラン

9-1 サブドメインごと DB を分けるメリット

分割しない 分割する
管理は楽だがテーブルが巨大化 テーブル数が抑えられスロークエリ減
バックアップが重い サイト単位でバックアップ・復元が迅速

実装例

  1. 新ドメイン news.example.com 用にサーバーパネルで MySQL を新規作成
  2. WordPress マルチサイトをサブドメイン型で構築
  3. wp-config.php に phpコピーする編集するdefine('MULTISITE', true); define('DB_NAME_NEWS','news_db');
  4. wp-blog-header.php で blog_id を判定し、$wpdb を動的に切り替える簡易スニペットを追加

9-2 DB 接続プール（読み書き分離）のアイデア

PV が月 300 万を超えたら 読み取り専用レプリカ を Xserver ビジネスプランで追加し、

  • 読み取り：レプリカ
  • 書き込み：プライマリ
    に分けるとピーク帯でも落ちにくくなります。実装は WordPress プラグイン HyperDB が手軽です。

10. 実践チューニング事例３選

サイト 規模 主施策 Before → After
技術ブログ 15,000 記事 リビジョンクリーン＋Redis TTFB 1.9 s → 0.6 s
ニュースサイト 100,000 記事 postmeta インデックス追加 P95 クエリ 420 ms → 140 ms
EC＋ブログ 商品 2,000 + 記事 5,000 wp-cron サーバー化 + Redis 注文ピーク CPU 80 % → 35 %

11. 自動化｜月次・週次メンテバッチ

11-1 WP-CLI スクリプト例（週次）

bashコピーする編集する#!/bin/bash
wp db optimize               # テーブル最適化
wp transient delete --all    # 期限切れトランジェント削除
wp revisions clean --days=30 # 30日超リビジョン削除

サーバーパネル → Cron 設定 → 毎週日曜 3:00 に登録。

11-2 Slack 通知（失敗検知）

bashコピーする編集するif ! /path/to/script.sh ; then
  curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"DB メンテナンス失敗！"}' \
  https://hooks.slack.com/services/XXX/YYY/ZZZ
fi

12. トラブルシューティング（代表 5 パターン）

症状 原因 対処
Error establishing DB connection wp-config のパスワード誤り／DB ダウン パネルでパス確認→ service mysqld restart
Deadlock found 同時更新競合 トランザクション範囲を短縮／プラグイン更新
超肥大した wp_options オートロード 1 MB 超 autoload=‘no’ へ変更、削除
Redis “MaxMemory reached” キャッシュに入り切らない パネルで容量拡張 or maxmemory-policy allkeys-lru
Too many connections クローラー集中 MySQL max_connections 増＋WAF で bot 制限

13. セキュリティと高速化を両立させるポイント

  1. 定期バックアップ は必須（DB のみ毎日＋フル週次）
  2. 二要素認証 で phpMyAdmin を保護
  3. 権限制御：開発者に SELECT のみ権限を分離
  4. WAF：SQL インジェクション遮断はパフォーマンス影響ほぼゼロ
  5. 最新 PHP + MariaDB へ随時アップグレード（脆弱性＆高速化を同時達成）

## 月100記事時代の失敗から学んだこと

大量更新していた時期、データベースのメンテナンスを完全に忘れていました。
結果として：
– サイトの表示速度が徐々に低下
– 検索順位も下がり始めた
– サーバー負荷も増加

この経験から、記事数が増えるほどデータベース最適化が重要だと痛感しました。

14. よくある質問

# 質問 わかりやすい回答
1 掃除系プラグインを複数入れてもいい？ 事故が増えるので 1 つに統一しましょう。重複実行で同じレコードを削除すると不整合が起きます。
2 Redis Object Cache と有料 Object Cache Pro の違いは？ 両者ともキャッシュですが、Pro は統計・圧縮・プリフェッチなど高機能。PV が月 500 万を超えたら検討で十分です。
3 インデックスを追加すると壊れませんか？ 追加は安全です。既存インデックスの削除や変更だけ慎重に。必ずバックアップ後に実行しましょう。
4 クラウド型データベースの方が速い？ 通信遅延があるため、Xserver 内蔵 DB の方が WordPress とは基本的に速くなります。
5 バックアップ容量が増えすぎます。工夫は？ ① 毎日：DBだけ差分　② 週 1：フルバックアップ　③ 古いアーカイブは自動削除、で容量を抑えます。
6 スロークエリログはどこで見られる？ サーバーパネル →「PHP・DB設定」▶「MySQLスロークエリ」のダウンロードボタンから取得できます。
7 PHP を最新版に変えると速くなる？ ほぼ毎回 5–10 % は速くなります。テーマ・プラグインの対応状況を確認してから切り替えましょう。
8 MariaDB 10 系を 10.x→10.y へ上げるときサイトは止まる？ Xserver はローリングアップデート方式で停止しません。ただし念のため深夜に実行し、直後に動作確認を。
9 postmeta を削除したらレイアウトが崩れた テーマやプラグインがそこから設定を読んでいる可能性大。削除する前にキー名を調査し、不要なものだけ消しましょう。
10 コメントスパムで wp_comments が膨らみます Akismet などで自動ブロックし、「30 日以上前のスパムは自動削除」設定を必ずONに。
11 autoload=’yes’ の上限は？ 合計 1 MB 程度が実務目安。2 MB を超え始めたら整理を検討してください。
12 投稿数は何件まで大丈夫？ チューニング済みなら 10 万件級でも問題ありません。鍵は postmeta とオプションの管理です。
13 wp-cron を止めたら予約投稿が失敗します サーバークロンで wp-cron.php を呼び出せば解決。記事公開予定の 1 分前には必ず実行されるよう5 分間隔が無難です。
14 WP Rocket と Xアクセラレータの相性は？ 基本両立しますが、双方で HTML キャッシュを有効にすると二重キャッシュになるのでどちらか片方に絞りましょう。
15 Elementor を使うと postmeta が急増する テンプレートや履歴をこまめに削除し、不要なリビジョンを制限してください。
16 ステージング環境でも最適化すべき？ はい。本番と同じ構造でテストしないと、本番公開時にパフォーマンス差が出ます。
17 リビジョンを完全に無効化したい define('WP_POST_REVISIONS', false); を wp-config に書くと 0 件になります。ただし誤操作復元ができなくなる点に注意。
18 DB 接続上限 max_connections は変更できる？ 共用サーバーでは不可。超える場合はプラグイン数削減か上位プランへ移行しましょう。
19 WAF を入れると遅くなる？ 通常は遅延 5 ms 程度。SQL インジェクション対策のメリットの方が大きいので有効化がおすすめです。
20 無料で DB の健康状態を見張るツールは？ Query Monitor（WPプラグイン）＋ Xserver リソースグラフの組み合わせが手軽です。
21 多言語プラグイン（WPML 等）は遅い？ 翻訳メタデータが postmeta に増えます。Redis キャッシュと定期掃除で十分カバー可能です。
22 サイト内検索プラグインを入れると重い 専用インデックスを作るプラグイン（SearchWP など）か Algolia 外部検索を推奨。
23 SSL 証明書が切れると DB 速度に影響？ 直接は無関係。ただしサイト全体が「安全でない」とみなされ離脱増→負荷減ともなります。
24 CDN キャッシュを全削除したら遅くなった エッジキャッシュが暖まるまでの一時的現象。心配ならオリジン側でも Xアクセラレータを有効に。
25 カスタム投稿ごとに専用テーブルを使える？ WordPress コアは未対応。プラグイン「WP Custom Tables」や Headless CMS 移行で実現可能です。

15. 用語集

# 用語 かみくだき説明
1 TTFB ブラウザが最初の 1 バイトを受け取るまでの時間。サーバー応答速度を示す。
2 MariaDB MySQL 互換のデータベース。Xserver が採用。
3 InnoDB WordPress デフォルトのテーブル形式。安全で速い。
4 Buffer Pool MariaDB が頻繁に使うデータをメモリにためる場所。
5 Query Monitor 遅い SQL や PHP エラーを可視化する WP プラグイン。
6 スロークエリ 実行に長時間かかった SQL。0.5 秒超が目安。
7 Redis データをメモリに保存する高速キャッシュ用 DB。
8 Object Cache SQL の結果をオブジェクトとしてキャッシュする仕組み。
9 Flush キャッシュを全部空にして最新状態に戻す操作。
10 wp-cron WordPress 内蔵のスケジュールタスク機能。
11 Cron サーバーが指定時刻にスクリプトを自動実行する仕組み。
12 Revision（リビジョン） 記事の過去保存履歴。
13 wp_posts 記事本文や固定ページを格納するテーブル。
14 wp_postmeta 記事ごとの追加情報（カスタムフィールド）を格納。
15 wp_options サイト全体の設定やキャッシュを保存。
16 autoload WordPress 起動時に「必ず読み込む」オプション。
17 Index（インデックス） データを素早く探すための見出し。
18 EXPLAIN SQL の実行計画を表示するコマンド。
19 P95 / P99 全リクエスト中 95 % / 99 % が収まる時間。遅い方を把握する指標。
20 IO Wait ディスク読み書き待ち時間。高いとサーバーが詰まる。
21 OPcache PHP の結果をバイトコードでメモリ保存し再利用。
22 LSAPI LiteSpeed が作った高速 PHP ハンドラ。
23 Xアクセラレータ Xserver 独自のページキャッシュ&高速化機能。
24 Brotli gzip より高圧縮なテキスト用圧縮方式。
25 gzip 古くからある圧縮方式。互換性が高い。
26 JSON型 MariaDB で JSON データを高速格納できる型。
27 TTL（Time To Live） キャッシュや DNS レコードの有効期間。
28 wp-cli WP をコマンドライン操作できるツール。
29 HyperDB WordPress 用のマルチ DB / 読み書き分離プラグイン。
30 Primary / Replica 書き込み用メイン DB / 読み取り専用コピー。
31 Deadlock 複数トランザクションが互いを待ち合い停止する状態。
32 wp_transient 一時キャッシュを wp_options に保存したレコード。
33 Cache Hit 既にキャッシュにデータがあり即時返せた状態。
34 Cache Miss キャッシュになく DB へ取りに行った状態。
35 LRU（Least Recently Used） キャッシュが満杯時に「最近使っていない物」から捨てる方式。
36 wp_comments コメント本文やステータスを保存するテーブル。
37 post_status 投稿の状態（publish / draft / trash など）。
38 LIKE 検索 部分一致検索。インデックスが効きにくく遅い。
39 TTL Policy allkeys-lru Redis が容量不足時に古いキーを自動削除する設定。
40 MySQLDump MySQL/MariaDB のバックアップを作るコマンド。
41 Service Restart サービスを再起動し設定を読み直す操作。
42 EXPLAIN FORMAT=JSON 実行計画を JSON 形式で詳細表示する。
43 Warm Cache あらかじめキャッシュをヒットさせて応答を速くしておくこと。
44 スローログローテーション 大きくなったスロークエリログを分割保存し、ディスク圧迫を防ぐ。
45 Headless CMS WP の表示をやめ、API だけ利用するサイト構造。大量記事でも速い。

16. まとめ｜増えても速いサイトを維持する３大原則

  1. 計測 → 掃除 → キャッシュ の順で取り組む
  2. DB に手を入れる前に Xserver 標準機能 を最大活用
  3. 自動化（WP-CLI + cron）で “放置でも速い” 仕組み を作る

これだけで 月100記事ペースでも TTFB 1 秒未満 を現実にできます。

17. まとめ

記事が増えるたびに WordPress が重くなり、読者が離脱していませんか？

速度低下を放置すると SEO も収益も右肩下がり。最悪の場合「接続エラー」でまったく表示されなくなります。

当サイトでは Xserver 専用データベース診断 を無料で実施。TTFB・スロークエリ・オプション肥大をレポート化し、最適化手順までご提案します。

先着 15 サイト限定、6 月 30 日申込分まで。

下のボタンから 60 秒で申し込み、速いブログで読者と売上を伸ばしましょう！

エックスサーバーに申し込む