2026年のWordPress制作で知っておきたいFSEと従来のテーマ開発の選び方
【動作確認済み環境】 ・WordPress：6.7.x ・PHP：8.2 ・確認日：2026年3月 ・テーマ：ブロックテーマ（FSE対応） / クラシックテーマ ※開発環境や今後のアップデートによって挙動が異なる場合があります。必ず検証環境でテストを行った上で実案件へ導入してください。 — 「新規のWeb制作案件、ブロックエディターを前提としたFSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの機能）で組むべきか、それとも作り慣れた従来のクラシックテーマで進めるべきか」 実務の現場で、このような選択に迷う場面が増えていないでしょうか。 ここ数年でブロックエディター周辺の機能は劇的な進化を遂げ、かつては「まだ実務での導入は難しい」と見送られていたFSEも、今や有力な選択肢となっています。しかし、クライアントの運用体制や保守の難易度を考慮すると、従来の実装方法が適しているケースも少なくありません。 本記事では、2026年現在の実務案件におけるリアルなトレンドを踏まえ、どちらの手法を選択すべきかの判断基準を、実装後のメンテナンス性やクライアントの運用コストの観点から整理してシェアします。 2026年のWeb制作案件におけるFSEとクラシックテーマの現状 制作効率と長期的な運用コストから考える最適な開発手法の選定基準 クライアントの要望に合わせてブロックエディターのカスタマイズ範囲を決める方法 後々のメンテナンスで困らないためのテーマ構造の設計思想 今後のWordPressアップデートを見据えた段階的な移行手順と実務での注意点
1. 2026年のWeb制作案件におけるFSEとクラシックテーマの現状
【動作確認済み環境】 ・WordPress：6.4.3 ・PHP：8.1.22 ・確認日：2024年4月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 実務の現場で「次の案件、クラシックテーマで作るか、それともFSE（フルサイト編集）でいくべきか」と頭を悩ませる機会が増えていませんか。ブロックエディターの進化に伴い、テーマ開発の選択肢が広がった一方で、選定基準に迷う場面も多くなりました。この記事では、実案件での経験をもとに、制作目的や運用体制に合わせた最適なテーマ開発の選び方をシェアします。 この記事でわかること ・現在のWeb制作におけるFSEとクラシックテーマの立ち位置 ・実務案件におけるそれぞれのメリット・デメリット ・案件の要件定義で迷ったときの具体的な判断基準 —
1. Web制作案件におけるFSEとクラシックテーマの現状
FSE（フルサイト編集：ブロックエディターを使ってサイト全体のレイアウトやヘッダー・フッターをノーコードで編集できる機能）の登場以降、WordPressの制作手法は大きな転換期を迎えています。かつて主流だった、PHPベースでテンプレートファイルを細かく制御する「クラシックテーマ」に対し、現在はブロックの組み合わせをベースとした「ブロックテーマ（FSE）」が公式に推進されています。 実務の現場における体感としては、すべての案件がFSEに移行したわけではありません。自由度の高いオリジナルデザインをカチッとコーディングしたい案件や、既存の複雑なプラグインと連携するシステム開発寄りの案件では、今でもクラシックテーマが強く支持されています。一方で、納品後にお客様自身でランディングページや新着情報のレイアウトを柔軟に変更したいという要望がある場合は、FSEの仕組みが大きな強みを発揮します。なぜこの使い分けが必要なのか
WordPressのアップデート方針は完全にブロックエディター中心に進んでいます。しかし、構築後の保守性やお客様のITリテラシーを考慮せずに最新技術であるFSEを導入すると、「納品後にレイアウトが崩れてしまった」「操作方法が難しくて更新できない」といったトラブルを招くことがあります。逆に、旧来のPHPによるガチガチのカスタマイズにこだわりすぎると、将来的なアップデートの恩恵を受けにくくなるリスクもあります。実案件での判断経緯（エピソード）
以前、コーポレートサイトの全面リニューアル案件を担当した際、当初は最新トレンドであるFSEでの構築を検討していました。しかし、クライアント企業の運用担当者様が「これまでのシンプルな入力欄（カスタムフィールド）での運用のほうが迷わない」と希望されたため、最終的にクラシックテーマにブロックエディターの一部機能を部分的に取り入れるアプローチを選択しました。この経験から、技術の先進性だけでなく「誰がどのように運用していくのか」を最優先に設計する重要性を再認識しました。向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | |——|—————-|——————| | FSE（フルサイト編集） | 納品後にお客様自身で直感的にデザイン変更やページの追加を頻繁に行いたい場合 | 完全に固定されたオリジナルのデザインレイアウトを厳密に維持したい場合 | | クラシックテーマ | カスタムフィールドを多用し、決まったフォーマットで入力作業を効率化したい場合 | HTMLやCSSの知識がない運用者が、ノーコードでレイアウトを変更したい場合 | — 将来的な保守性を考慮すると、ブロックエディターの機能を全く使わないという選択は難しくなっています。どちらか一方のみに固執するのではなく、プロジェクトの予算、納期、そして何よりも「お客様の運用のしやすさ」を基準に、最適な手段をフラットな視点で選ぶことが大切です。 Web制作やWordPressのカスタマイズ、運用保守についてお悩みのことがありましたら、どうぞお気軽にeBIZクリエイトまでご相談ください。地域に寄り添うデジタルパートナーとして、実務に基づいた最適な解決策を一緒に形にいたします。2. 制作効率と長期的な運用コストから考える最適な開発手法の選定基準
【動作確認済み環境】 ・WordPress：6.4.3 ・PHP：8.1.22 ・確認日：2024年2月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「新しいテーマを作る際、従来のクラシックテーマとフルサイト編集（FSE）のどちらで構築すべきか」というご相談をいただく機会が増えてきました。どちらの手法にも明確な強みと弱みがあり、プロジェクトの性質を見極めずに選択すると、後に運用の現場で苦慮することになります。今回は、実務における制作効率と、納品後の運用コストという2つの視点から、最適な開発手法を選ぶための具体的な基準をシェアします。
この記事でわかること
クラシックテーマとFSE（ブロックテーマ）の開発効率の違い 納品後のクライアント運用におけるコストとリスクの比較 自社案件で採用する際の実務的な意思決定基準 —制作時と運用時の「コストの重心」がどこにあるかを見極める
開発手法を選定するうえで最も重要な判断軸は、制作フェーズと運用フェーズのどちらにコストをかけるか、という「重心」の位置です。 “`text 【クラシックテーマ】 制作時：コーディングの自由度が高く、構築しやすい 運用時：微修正でもコーダーへの依頼が発生しやすい（運用コスト高） 【FSE（ブロックテーマ）】 制作時：ブロックの仕様に合わせた設計が必要（初期学習コスト高） 運用時：クライアント側でノーコード編集ができる範囲が広い（運用コスト低） “` クラシックテーマは、従来のHTML/CSS/PHPによる自由度の高いマークアップが可能です。制作者側にとっては「思った通りのデザインをスピーディーに形にできる」というメリットがあります。しかし、納品後に「ちょっとしたレイアウト変更やパーツの追加をしたい」という要望があった場合、都度テンプレートファイルの書き換えが必要になり、長期的な運用コストが膨らみやすい傾向があります。 一方、FSE（フルサイト編集：ブロックエディターを使ってサイト全体のレイアウトを編集できる機能）を用いたブロックテーマ開発では、ヘッダーやフッター、テンプレートの構造までブロック化します。開発時にはブロックの挙動を考慮したコーディングが求められるため、一定の学習コストがかかります。しかし、納品後はクライアント自身で直感的にページのレイアウト変更やパーツ追加を行えるため、運用の内製化が進みやすく、長期的な運用コストを抑えることが可能です。 —なぜこの選定基準が重要なのか（内部仕様の観点から）
従来のクラシックテーマは、PHPテンプレートをサーバーが処理してHTMLを出力する仕組みです。コードがサーバー側で厳密に管理されるため、クライアントが誤ってサイト全体のデザインを崩してしまうリスクは極めて低いという特徴があります。 対してFSEは、HTMLコメント形式のブロックマークアップ（ブロックの配置情報をHTMLファイル内に記述する仕組み）をデータベースと同期させながら処理します。これにより管理画面からの直感的な操作を実現していますが、自由度が高い反面、操作ミスによってレイアウトが崩れてしまうリスクもはらんでいます。 実務においては、この「自由度」と「崩れにくさ（安全設計）」のバランスをどのように取るかが、案件の成否を分けるポイントになります。 —実案件でのエピソードと失敗から学んだこと
実は、以前に社内用の簡易的なコーポレートサイトをFSEで構築した際、運用のしやすさを最優先してすべての領域をクライアント側で編集可能にしました。しかし納品後、担当者様が「余白の調整」や「カラーパレット以外の色の使用」を繰り返した結果、サイト全体のデザインの一貫性が失われてしまったという苦い経験があります。 この失敗を経て、FSEを採用する場合は、ただ自由に編集できるようにするのではなく、`theme.json`（テーマの設定やスタイルを制御する構成ファイル）を使用して、エディター側で使えるカラーパレットやフォントサイズ、使用可能なブロックをあらかじめ制限しておく設計が不可欠であると学びました。それ以来、制作時には「どこまで触らせて、どこをロックするか」の要件定義を確実に行うようにしています。 —やめておいた方がいいケースと注意点
「トレンドだから」という理由だけで、すべての案件にFSEを適用するのは推奨しません。 特に、完全にオリジナルの緻密なアニメーションや、1ピクセル単位で厳密にデザイン再現が求められるランディングページ（LP）などの構築において、無理にFSEを採用すると、ブロックの仕様に合わせるための調整作業（ブロックのカスタマイズや独自CSSのあて込み）に膨大な時間を取られます。その場合は、最初からクラシックテーマとしてPHPとCSSでしっかりとコーディングした方が、開発工数も抑えられ、動作の安定性も担保できます。 —向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | | :— | :— | :— | | FSE（ブロックテーマ） | ・納品後、クライアント側でページのレイアウト変更やコンテンツ追加を頻繁に行いたい場合・デザインシステムが整備されており、共通のコンポーネントを使い回す設計に適している場合 | ・1ピクセル単位の厳密なデザイン再現や、複雑な独自JavaScriptアニメーションを多用する場合
・クライアント側の編集ミスによるレイアウト崩れのリスクを極めてゼロに近づけたい場合 | | クラシックテーマ | ・独自仕様が多く、高度なPHPカスタマイズや外部APIとの柔軟な連携が必要な場合
・クライアントは「テキストと画像のみ」を差し替える、シンプルな運用を望んでいる場合 | ・納品後に「固定ページのレイアウトを自分たちで自由に変更したい」といった要望がある場合
・ブロックエディターの利便性をフルに活かした効率的なコンテンツ作成を行いたい場合 | —
保守性・将来性の考察
WordPress公式のロードマップを見る限り、開発の軸足がFSEやブロックエディター周辺の機能拡張にあることは間違いありません。コア（WordPress本体）のアップデートによる新機能の恩恵を最も受けやすいのはブロックテーマです。 しかし、クラシックテーマがすぐに使えなくなるわけではありません。世界中の数多くの既存サイトがクラシックテーマで稼働しているため、後方互換性は非常に長く維持されると考えられます。短期的な流行に流されることなく、「そのクライアントの運用体制において、本当にFSEが持続可能か」を冷静に見極める姿勢が、Web制作者として長期的な信頼を得るために最も大切です。 —まとめと選定の判断基準
どちらの開発手法を選ぶべきか迷った際は、以下のステップで整理してみてください。 1. デザインの性質を確認する：グリッドに沿った機能的なデザインか、それとも装飾性の高い複雑なデザインか 2. クライアントの運用体制を確認する：社内にWeb担当者がいて自らレイアウト変更を行いたいか、それともテキスト修正程度にとどめるか 3. 予算と開発期間を確認する：FSEの制限ブロックやスタイル設計に十分な検証時間を割けるか これらを明確にすることで、プロジェクトにとって最適な選択肢が自ずと見えてくるはずです。 eBIZクリエイト株式会社では、お客様のビジネスモデルや運用体制に合わせた最適なWordPressサイトの構築・カスタマイズをご提案しています。現在の開発手法にお悩みの方や、FSEの導入検討、安定した運用・保守について詳しく知りたい方は、お気軽に[eBIZクリエイト](https://ebiz-create.co.jp/contact/)までご相談ください。3. クライアントの要望に合わせてブロックエディターのカスタマイズ範囲を決める方法
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「クライアントが編集しやすいように管理画面を調整したけれど、納品後にレイアウトが崩れてしまった」という経験はありませんか。実案件では、更新の自由度とデザインの担保のバランスに悩む場面が多々あります。 この記事では、クライアントの要望に合わせてブロックエディターのカスタマイズ範囲を適切に制限・コントロールする方法を解説します。
この記事でわかること
・クライアントのスキルに応じたエディター制限の考え方 ・テーマ側で特定のブロックを非表示にする方法 ・ブロックエディターの機能制限（theme.json）の設定手順 ・実案件における運用トラブルを防ぐ具体的な基準自由度と保守性のバランスを最適化する
ブロックエディター（Gutenberg）は非常に柔軟ですが、自由度が高すぎると予期せぬレイアウト崩れの原因になります。実務では、納品後の運用体制やクライアントのWeb知識のレベルに合わせて、機能を制限することが不可欠です。 例えば、HTMLやCSSの知識がないクライアントにフルサイト編集（FSE）の権限をすべて渡してしまうと、文字の変更時に誤って全体のレイアウト構成（カラムや余白など）を削除してしまう恐れがあります。どこでコントロールするか：theme.jsonとフックの使い分け
ブロックエディターのカスタマイズ範囲を決めるには、主に2つのアプローチがあります。 1. theme.json（テーマの設定ファイル） カラーパレット、フォントサイズ、余白（マージン/パディング）などの選択肢をグローバルに制限します。 2. PHPによるフック（functions.php） 使用可能なブロックの種類をユーザー権限や投稿タイプごとに制限します。 以下は、特定の投稿タイプで「利用できるブロック」を限定するためのPHPコード例です。 “`php / 投稿タイプ「news」で利用可能なブロックを制限する @param array|bool $allowed_block_types 許可されたブロックの配列 @param WP_Block_Editor_Context $block_editor_context エディターのコンテキスト情報 @return array|bool / function my_custom_allowed_blocks( $allowed_block_types, $block_editor_context ) { // 対象とする投稿タイプが「news」の場合のみ制限をかける if ( ‘news’ === $block_editor_context->post->post_type ) { return array( ‘core/paragraph’, // 段落 ‘core/heading’, // 見出し ‘core/image’, // 画像 ‘core/list’, // リスト ); } return $allowed_block_types; } // action hook（アクションフック）ではなく、フィルターフックを使用してデータを加工 add_filter( ‘allowed_block_types_all’, ‘my_custom_allowed_blocks’, 10, 2 ); “` このコードをテーマの`functions.php`（テーマの機能を追加・カスタマイズするファイル）に記述することで、指定した投稿タイプでは特定のブロックしか選択できなくなり、運用の属人化を防ぐことができます。なぜ制限が必要なのか：内部仕様と長期運用の視点
ブロックエディターは、作成したコンテンツをHTMLコメント（例：“）の形式でデータベースに保存する仕様になっています。 自由度を制限せずに運用すると、意図しないインラインスタイル（文字ごとのサイズ変更や色の変更）が大量に埋め込まれ、数年後にデザインリニューアルを行う際に、過去記事のスタイルを一括で変更することが困難になります。データのクオリティと将来的な保守性を担保するために、あらかじめエディターの機能を絞り込んでおく設計が推奨されます。実案件における判断の経緯
以前、複数人で運用するメディアサイトの構築案件がありました。当初は「自由にデザインを変更したい」との要望から制限を設けずに納品しましたが、1ヶ月後にフォントサイズや背景色がバラバラになり、ブランドの統一感が損なわれる事態になりました。 この経験以降、私たちは事前にクライアントの運用担当者のITスキルをヒアリングし、デフォルトのカラーパレットを無効化（theme.jsonで`color.custom`を`false`にするなど）し、定義したブランドカラーのみを選択できるように設定するルールを導入しています。よくある間違い・ハマりポイント
プラグインを使ってブロック全体を非表示にする方法もありますが、バージョンアップ時にエディター側と競合し、一時的に編集画面が開かなくなるトラブルが起きることがあります。 外部ツールに頼りすぎず、WordPress本体の機能である`theme.json`やフックによる制御を選択する方が、表示の高速化やシステムの安定性においてメリットが大きいです。向いているケース・向いていないケースまとめ
| 項目 | 向いているケース | 向いていないケース | |——|—————-|——————| | エディターの制限 | 複数の担当者が更新する、ガイドラインに沿った運用を行いたい場合 | 1人の管理者が自由なレイアウトでランディングページを量産したい場合 | | 制限なし（フル機能）| クライアント自身がHTML/CSSの基礎知識を持ち、デザイン調整も自社で行う場合 | Webの専門知識がなく、文章と画像の差し替えのみを行う場合 |将来的な保守性の観点から
WordPressは今後もブロックエディターを中心に機能が強化されていきます。`theme.json`を用いた標準的な手法でカスタマイズを制限しておけば、将来のメジャーアップデートの際も影響を受けにくく、スムーズな保守運用が可能です。 — Webサイトの制作から保守・運用の設計まで、一貫したシステム構築でお悩みの際は、どうぞお気軽にeBIZクリエイトまでご相談ください。実績に基づく最適な設計をご提案いたします。4. 後々のメンテナンスで困らないためのテーマ構造の設計思想
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 「数年前に制作したサイトの修正を依頼されたが、コードが複雑すぎてどこに何が書いてあるか分からない」「軽微な文言変更なのに、想定以上の工数がかかってしまった」といった経験はありませんか。 保守フェーズに入ってから構造の不備に気づくケースは、実務において少なくありません。この記事では、将来の仕様変更やメンテナンス時に迷わないためのテーマ設計における判断軸を整理してご紹介します。 この記事でわかること ・メンテナンス性の高いテーマを構築するためのフォルダ・ファイル構成の基準がわかります。 ・FSE（フルサイト編集：ブロックエディターでサイト全体を編集できるWordPressの新機能）とクラシックテーマ（従来のPHPテンプレートを用いたテーマ）それぞれの保守における強みと弱点が理解できます。 ・実務案件における「テンプレートの共通化」と「カスタムブロックの設計」の具体的な落としどころがわかります。
保守性を左右する「コンポーネント化」の視点
WordPressのテーマ開発において、後から変更を加えやすい構造を作るためには、役割ごとにプログラムやデザインパーツを細分化する「コンポーネント化（部品化）」が欠かせません。 クラシックテーマ（従来のテーマ開発）では、パーツを共通化するために `get_template_part()` などのテンプレートタグを多用していましたが、分割しすぎるとファイル数が膨大になり、逆に構造の把握が難しくなる懸念がありました。一方でFSE（フルサイト編集）の場合は、パーツが「パターン」や「テンプレートパーツ」としてWordPressの管理画面上に登録されるため、視覚的に管理しやすくなります。 “`php “`なぜそのファイル構造にするのか：疎結合の重要性
プログラムの設計思想において「疎結合（それぞれの部品が互いに依存しすぎていない状態）」を保つことは、長期的なメンテナンスにおいて非常に重要です。 たとえば、特定のカスタム投稿タイプだけで使うスタイルシートやJavaScriptを、共通の `style.css` や `main.js` にすべて書き込んでしまうと、将来的にその機能が不要になった際の削除作業が困難になります。 “`php / どこに書くか：functions.php（テーマの機能を追加・カスタマイズするファイル） いつ動くか：スクリプトやスタイルを読み込むタイミング（wp_enqueue_scripts アクションフック） 特定のページでのみ必要なアセット（ファイル）を条件分岐で読み込むことで、余分な読み込みを防ぎ、変更時の影響範囲を絞り込みます。 / function my_theme_enqueue_conditional_scripts() { // お問い合わせページ（スラッグ：contact）の場合のみ専用のスタイルとスクリプトを読み込む if ( is_page( ‘contact’ ) ) { wp_enqueue_style( ‘my-contact-css’, get_theme_file_uri( ‘/assets/css/contact.css’ ), array(), ‘1.0.0’ ); wp_enqueue_script( ‘my-contact-js’, get_theme_file_uri( ‘/assets/js/contact.js’ ), array(), ‘1.0.0’, true ); } } add_action( ‘wp_enqueue_scripts’, ‘my_theme_enqueue_conditional_scripts’ ); “` このアプローチを採用することで、「お問い合わせフォームの挙動がおかしい」という不具合が発生した際に、調査すべきファイルが `contact.js` であることが一目でわかり、他のページに影響を与えることなく改修作業を進めることができます。実案件での検証と選択の基準
実務において、私たちはFSEの柔軟性と、従来のクラシックテーマによる制御の確実性を、案件の特性に応じて使い分けています。 以前、頻繁にコンテンツのレイアウト変更が発生するコーポレートサイトの案件がありました。当初は従来のカスタムフィールドを用いたガチガチの仕様で設計する予定でしたが、運用の手間を考慮して、主要なパーツをFSEの「パターン」として登録する方針に切り替えました。その結果、軽微なレイアウト変更はお客様自身で行えるようになり、運用の工数を削減できた経緯があります。 しかし、すべてをFSEで構築すれば良いというわけではありません。企業のブランディングに関わる、極めてミリ単位のデザイン再現性が求められるコーポレートサイトや、管理画面からの操作ミスによるレイアウト崩れを防ぎたいコーポレート案件では、現在も従来のテンプレートファイルによるレイアウト制限が有効な選択肢となります。各設計アプローチの向き・不向きのまとめ
| 項目 | 向いているケース | 向いていないケース | |—|—|—| | FSE（フルサイト編集）による設計 | 納品後にお客様側でページの追加や自由なレイアウト変更を頻繁に行いたい場合 | 厳格なデザインルールがあり、ユーザーの誤操作によるデザイン崩れを完全に防ぎたい場合 | | クラシックテーマによる個別テンプレート設計 | 管理画面からの編集領域を限定し、プログラムとしての堅牢性と再現性を最優先したい場合 | 制作後にページの構成要素や順序を頻繁に入れ替える必要がある場合 |将来的な保守性に配慮した選択
WordPressのアップデートに伴い、ブロックエディターの仕様は常に変化し続けています。FSEを採用する場合は、将来的なWordPressコアのアップデートによる影響を受けやすいため、できるだけ標準ブロックをベースにしたクリーンなマークアップを意識することが求められます。 一方、クラシックテーマであっても、完全にブロックエディターを排除するのではなく、テーマ側でブロック用のスタイルを用意するなど、最新仕様との共存を図る設計が、長期的な寿命を持つサイト制作につながります。 迷ったときは、制作するWebサイトの「公開後に誰がどのように更新していくか」という運用フローを明確にすることからスタートしてみてください。それにより、採用すべきテーマ構造の設計思想が自ずと見えてくるはずです。 — Webサイトの新規制作や、既存サイトのWordPress移行、複雑化したテーマの保守でお困りの際は、お気軽にeBIZクリエイト株式会社までご相談ください。丁寧なヒアリングのもと、お客様の運用環境に最適化した設計・構築をご提案いたします。5. 今後のWordPressアップデートを見据えた段階的な移行手順と実務での注意点
【動作確認済み環境】 ・WordPress：6.4 ・PHP：8.1 ・確認日：2024年11月 ※環境によって動作が異なる場合があります。必ず検証環境でお試しください。 実務でWordPressのサイト制作に携わっていると「既存のクラシックテーマで作られたサイトを、いつ、どのようにフルサイト編集に対応させていくべきか」という相談を受ける機会が増えてきました。完全に新しい構築方法へ移行するのは、開発リソースや運用の観点から容易ではありません。 この記事では、クラシックテーマ（従来のPHPベースのテーマ）からFSE（ブロックエディターでサイト全体を編集できるWordPressの機能）へ、安全かつ段階的に移行するための手順と、現場で直面しやすい注意点を共有します。 この記事でわかること ・既存のクラシックテーマを壊さずにFSEの要素を取り入れる手順 ・移行期におけるハイブリッドテーマ（両方の特徴を持つテーマ）の活用方法 ・実務でトラブルを防ぐための移行時のチェックポイント