今年も残すところ、あとわずかとなりました。
平素より当サイトをご覧いただき、また多くのご縁・ご相談をいただき、誠にありがとうございます。
本年もたくさんの方に支えていただき、心より感謝申し上げます。
誠に勝手ながら、下記の期間を年末年始休業とさせていただきます。
2025年12月27日（土）～ 2026年1月4日（日）
※2026年1月5日（月）より通常営業いたします。
休業期間中にいただいたお問い合わせにつきましては、
営業再開後、順次対応させていただきますので、あらかじめご了承ください。
来年も、より良いサービス・ご提案ができるよう努めてまいります。
どうぞ良い年末年始をお過ごしください。
今後ともよろしくお願いいたします。
「ホームページ制作を依頼したいけれど、
制作会社に頼むべきか、フリーランスに頼むべきか迷っている。」
お客様との話の中で、こんなことを言われたことがありました。
私自身、フリーランスのウェブ制作者なのですが、
中小企業・個人事業主にとっては“フリーランス”が最適な選択肢なのではと思います。
その理由は、単に「安いから」ではなく、
制作前〜制作後のすべてが一貫してスムーズになるためです。
「制作会社とフリーランスの違い」
「フリーランスを選ぶメリット」
について解説します。
いまやビジネスにおいてウェブに情報を掲載することは当然であり、また単にホームページがあればそれで良いというわけでもなく、
こうした「実用的なホームページ」が必要とされます。
しかし、制作会社に依頼すると、50〜150万円前後の費用がかかるのが一般的で、小規模事業には負担が大きくなりがちです。
中小規模ビジネスにおいて「長く使える実用的なホームページ」が求められますが、これは我々フリーランスの得意領域そのものです。
フリーランスは中間マージンがないため、制作会社の半額〜2/3程度の費用で同等以上の品質になることが多いです。
情報を取り扱う上でスピードは重要なファクターです。
制作会社では保守担当が別部署のことも多くあり、「作る人」と「直す人」が違うため、対応が遅くなりがちです。
フリーランスなら、制作者がそのまま運用改善も担当するため、意図を理解した上で的確な修正ができる点が大きな強みです。
専門領域を明確に語れる制作者は、信頼できます。
制作の姿勢、設計思想、トラブルシューティングなどを継続して発信している制作者は、長期的なパートナーになりやすいです。
技術的なことを直接、制作者本人と相談できるのは大きな価値です。
| 項目 | 制作会社 | フリーランス |
|---|---|---|
| デザイン | ◎ | ◎ |
| コーディング | ◎ | ◎ |
| SEO内部対策 | △（担当者次第） | ◎（制作者が直接対応） |
| 中間マージン | あり | なし |
| 価格 | 高い（50万～150万） | 適正・柔軟（15万～60万） |
| スピード | 遅い | 早い |
| 保守対応 | 担当者が変わる | 制作者本人が対応 |
| 小規模案件 | 苦手 | 得意 |
フリーランスはこうしたニーズにもっともフィットします。
ホームページ、ウェブ制作は一朝一夕ではありません。
制作会社に頼るより、長期的なパートナーとしてフリーランスを選ぶことは、より成果につながりやすいと考えています。
Web 制作では、もう「pxだけで完結する世界」ではなくなりました。
スマホ・タブレット・PC・大型モニター…。
多様な画面サイズへ、一つのデザインを “伸縮する” 形で最適化する必要があります。
そのとき役に立つのが px → vw → rem の三層設計 です。
を、フロントエンド／WordPressに対応できる形で解説します。
かつて Web サイトは「幅 960px の世界」で成立していました。
しかし現在は 最小幅 360px、最大 2000px 以上まで広がっています。
px には次の弱点があります。
これを解決するのが 相対単位（vw / rem）です。
vw（viewport width）は「画面幅 100% を 100vw とする相対単位」です。
たとえば
画面幅 1000px → 1vw = 10px
画面幅 390px → 1vw = 3.9px
つまり
vw を使えば、画面サイズに“比例”するブロックが簡単に作れる。
特に近年のWeb デザイン（余白を大きく取り、可変させるスタイル）はvwを使うことで デザインの再現度が圧倒的に上がります。
remはhtml の font-size を基準にスケールする単位です。
一般的に
html { font-size: 62.5%; }
→ 1rem = 10px
とするケースが多いですが、最近はユーザーアクセシビリティの観点からhtmlには％を指定しないという潮流もあります。
つまり、vw（大きく動く）／rem（細かく調整）の住み分けが肝です。
実務的な設計パターンを示します。
html {
font-size: 16px; /* 1rem = 16px 基準 */
}
アクセシビリティを重視。
h1 {
font-size: clamp(2rem, 6vw, 5rem);
}
p {
font-size: 1rem;
line-height: 1.8;
}
.section {
padding: 10vw 0;
}
.button {
font-size: 0.875rem;
padding: 0.6rem 1.2rem;
}
px は「絶妙な固定」を作るための道具です。
こういうケースではpxを使ったほうが調整がしやすいなど手段としてのpx使用に全く問題はありません。
px → vw → rem は、
という、現代 Webに求められる4条件をすべて満たした設計です。
固定幅の概念に縛られず、“デザインがそのままスケールする” Webを作るなら、この三層設計は避けて通れません。
この記事では、
をまとめて紹介します。
Webデザインやコーディングで使用する「色」を、直感的に・高速に選べるカラー選定アプリです。
「色を探す → コードをコピペ → デザインに反映」という流れがとてもスムーズになります。
制作には、最新のフロントエンド環境を活用しています。
ルーティング・環境構築・ビルドのしやすさから Next.js を採用。
Pages Routerで構成し、静的生成（SSG）により高速レスポンスを実現しています。
スタイル定義は Tailwind CSS。
余計なCSSファイルを持たず、必要なユーティリティだけを使い切れるため、
というメリットがあります。
ビルド後は Netlify にデプロイ。
が最適だったため、この構成にしています。
用途に応じて複数のタブを用意しています。
CSSで利用できる標準の色名一覧を表示。
クリックするとカラーコードを即コピーできます。
古いブラウザ対応を意識した「ウェブセーフカラー」を網羅。
16進数ベースで安全に使える色を探したいときに便利。
デザインで使いやすい「淡い系の色」を集めたパレット。
トーンを揃えたい制作時に重宝します。
Tailwind CSSのカラースケールを即コピーできる専用タブ。
などのクラス名がクリック一つでコピーできます。
選択した色をもとに、
をアルゴリズムで生成してプレビュー。
デザインの方向性をすぐ試せます。
市販の色見本サイトは多数ありますが、以下のような不満がありました。
「毎日の制作で使うなら、自分が本当に欲しいものがほしい」と考え、必要な機能だけを集約した “自分専用ツール” を作った のが始まりです。
Color Picker APPは UI や解説を 100%英字で統一しているため、国内だけでなく海外ユーザーにも自然と利用いただいています。
特に Netlify のグローバルCDN を利用したホスティングにより、海外からのアクセスも高速・快適で、多言語化していないにも関わらず世界中のデザイナーや開発者が訪れるツールになっています。
開発中の機能も含め、以下を予定しています。
独自ドメインで運用していますが、個人の便利ツールというジャンルなので本来は別にドメインにこだわる必要はありません。
それでも、「色ツールの専門サイト」としての独立性を出すためにあえて独自ドメインで公開しています。
Color Picker APP は、「自分が心から使いやすい色ツールを作りたい」という一点から生まれたアプリです。
という、Web制作に必要な要素をすべて詰め込んだツールになっています。
デザイナー・コーダーだけでなく、色にこだわりたいすべての方に使っていただけたら嬉しいです。
Webサイトのセキュリティは、「脆弱性のあるコードを直す」だけでは十分ではありません。
近年は CMS・外部サービス・通信経路・サーバー設定・フォーム・JavaScript…
あらゆるレイヤーで攻撃が発生します。
特にWordPressを中心としたCMSサイトでは、サイト制作＝セキュリティ設計の戦略と言っても過言ではありません。
HTMLサイト・WordPressサイトに共通する“堅牢性を確保するための設計思想” を、制作者の視点で解説します。
「WordPressじゃないから安全」というのは誤解です。
静的HTMLサイトでも攻撃は普通に発生します。
HTMLだから安全というわけでもなく、「攻撃対象になる情報が少ないだけ」にすぎません。
そのため、静的サイトでも
などの最低限の防御策が必要です。
WordPress は世界シェアが高いため攻撃が多いですが、実際には正しく運用すれば非常に安全です。
問題はプラグインでもコアでもなく、
という運用の問題がほとんどです。
特にXML-RPCとREST APIの著者情報取得は、ブルートフォース・情報漏洩の定番ルートなので注意が必要です。
セキュリティは後付けではなく “設計の一部” として組み込むべきです。
その際には次の3つのレイヤーを意識します。
サイト内部のセキュリティ。
特に PHP8 では古いコードが脆弱性の温床となることも多く、テーマの品質が堅牢性を左右します。
サーバーや通信の堅牢性。
サーバー側の設定は、ホスティング事業者の品質に密接に依存します。
私の推しのサーバーサービス【エックスサーバー】が評価される理由は、このレイヤーの設定が水準以上である点が大きいです。
最後に重要なのは人間です。
特に多い問題は「ノーメンテの放置状況が続き、いつの間にか破られている」という状況。
これを防ぐには、運用の設計が不可欠です。
堅牢性は、次のように複数レイヤーで守る構造（Defense in Depth）が必要です。
どれか1つが破られても他で守れるようにする。
これが「多層防御」という考え方です。
テーマにプラグインが大量に入っており、管理者がテーマもコードも一切理解していない状態。
サポートが終了していて、最新の環境(PHP8)に適合しない。
WordPressではいつ事故が起きても不思議ではない運用。
万一、顧客への損害があった場合に深刻なダメージを受けます。
セキュリティは“設定”ではなく“設計”です。
すべてが揃って初めて、堅牢なWebサイトになります。
制作者の役割は、サイトを作るだけでなく、正しく運用できる環境を設計することです。
これからのWebは、高速で、安全で、構造化されていることが求められます。
SMILEWORKSでは、今後も堅牢性に配慮したサイト構築を実施していきます。
2024年にChatGPTをはじめとしたAIブラウザが登場し、ユーザーが「検索結果を読む」のではなく、AIがWebから情報を収集して“答えを生成する”時代へと大きくシフトしました。
この変化により、従来のSEOだけでなくAIO（AI Optimization：AI最適化）が重要になっています。
ChatGPT のようなAIブラウザは、URLを入力するとページをクロールして次の情報を収集します。
つまり、
「視覚的にどう見えるか」より「構造的にどう整理されているか」を重視しているのです。
これは検索エンジンと同様ですが、AIはより“意味”の認識に比重大きく置いています。
次のようなページは、ChatGPTに正しく理解されません。
たとえば <h2> を単なるデザイン目的で使用していると、AIはそれを「セクションの区切り」と認識してしまい、本文の意味を誤解することがあります。
AIにとってもっとも重要なのは、ページがどのような“意味構造”を持っているか です。
具体的には次の3つがAIOの中心になります。
AIは見出しを“要点の区切り”として理解します。
適切な例：
<h1>サービス紹介</h1>
<h2>Web制作</h2>
<h3>WordPress構築</h3>
<h3>保守・運用</h3>
<h2>アプリ開発</h2>
階層がきれい＝AIが正しく要約できる
ChatGPTはページ冒頭を重視して要約を作ります。
冒頭に主題が書かれていない文章は、
最初の200〜300文字は「この記事は何を説明するのか？」が明確であるべきです。
ChatGPTは schema.org の情報を高確率で読み取っています。
特に次のスキーマはAIとの相性が良いです。
| 種類 | 効果 |
|---|---|
| LocalBusiness | 会社情報・連絡先をAIが理解 |
| Article / BlogPosting | 記事の主題・著者・公開日を伝える |
| FAQPage | 質問と回答のセットを認識 |
Schema を入れることで、
AIが「誰が書いた記事なのか」「何について書かれているか」を誤解せずに理解できます。
AIは信頼性を非常に重視します。
E-E-A-T評価（経験・専門性・権威性・信頼性）を理解するために、
などを読み取ります。
これらがSchemaによって明示されていると、AIはその情報を“信頼できる出典”として扱うようになります。
デザイン目的の h2/h3 の乱用はNG。
200文字以内で要点があるとAIは誤読しにくい。
LocalBusiness + Article が最優先。
AIブラウザ、Slack、SNSプレビューすべてに効く。
階層構造の理解に有利。
画像の内容をAIに伝えるための基本。
AIブラウザはこれから確実に主流となり、
「検索→クリック→読む」という従来の行動は大きく変化します。
その中で、
AIに正しく理解される＝AIに選ばれる
という新しい評価軸が生まれました。
AIO（AI Optimization）は、SEOの延長ではなく、AI時代に必要な“新しいWeb構造の考え方”そのものです。
ChatGPTは特に、
を強く参照します。
これらを整備することで、WebサイトはAIブラウザでも正しく理解され、ユーザーに価値ある情報として届けられるようになります。
SMILEWORKSでは、まさにこの考え方に基づき、サイト全体のスキーマ導入やmeta構造の最適化を行っています。
AIOはこれからのWeb制作の必須要素です。
Webサイト制作では、デザイン・導線・スピードと同じくらい重要なのが「HTMLタグの正しい使い方」です。
Google検索はサイトの構造を「HTMLタグの意味」を手がかりに理解しています。
つまり、タグを正しく書くことそのものがSEO施策になります。
GoogleはHTMLタグから以下を読み取っています。
つまり、「タグの使い方＝SEOの土台」 です。
Googleは「文書構造」を理解するためにhタグを読むため、次のような階層が理想です：
h1（ページ全体の主題）
├ h2（大テーマ）
│ ├ h3（詳細テーマ）
│ └ h3
└ h2
SEOでは意味的構造が大切。見た目はCSSで。
検索エンジンに「ここが重要」と伝える強調タグ。
文章中のキーワード強調に有効。
語句の「ニュアンス的強調」
SEO効果はほぼなし。
Googleは画像の内容を alt で判断します。
重要ポイント：
画像検索SEOにも影響します。
検索結果のタイトル下に掲載される説明文欄。SEO効果は無いがCTR（クリック率）改善に直結。
Googleは次のようなタグを理解しています：
| タグ | 意味・役割 | 使うべき場面（実務例） | SEO観点のポイント |
|---|---|---|---|
| <header> | ページまたはセクションの冒頭部分 |
・全ページ共通のヘッダー（ロゴ・ナビ） ・記事の冒頭（タイトル・概要） |
・文書構造を整理する役割 ・ロゴ画像に h1 を入れないよう注意 |
| <main> | ページの主要コンテンツ領域 |
・ブログ記事本文 ・サービス紹介ページの本文 |
・1ページに1つだけ使用 ・サイドバーなどは含めない |
| <footer> | ページやセクションの締め部分 |
・コピーライト ・関連記事リンク ・共通フッターナビ |
・ページ全体の締めにも、 セクション内の締めにも使用できる |
| <nav> | 主要ナビゲーション |
・グローバルナビ ・パンくずリスト ・ページ内目次 |
・リンクの「まとまり」に使用 ・単体リンクを nav で囲まないこと |
| <article> | 独立して成立するコンテンツ |
・ブログ記事 ・ニュース投稿 ・レビュー1件分 |
・単体で完結する情報のまとまりに使う ・複数の article が並んでもOK |
| <section> | 意味のあるコンテンツの区切り |
・h2 で分けるコンテンツブロック ・サービスの特徴セクション |
・見出し（hタグ）とセットで使うのが基本 |
| <aside> | 本文とは独立した補助コンテンツ |
・サイドバー ・関連記事 ・補足コラム |
・本文（main）の外に置くと構造が明確になる |
| <figure> <figcaption> |
画像・図表とその説明文 |
・図表の説明 ・画像ギャラリー ・コードスニペットのキャプション |
・画像の意味が明確になりSEO的にプラス ・alt と figcaption の相乗効果が高い |
リンク文字列に使いがちな「こちら」「詳しく」よりも、リンク先の内容を表すキーワード文字列が理想。「こちら」「詳しく」ではGoogleは意味を読み取れない。
WordPressなら Yoast / RankMath / Breadcrumb NavXT などで自動生成できます。
主に以下を利用：
ウェブページが表示されるブラウザの可視領域設定
特に画像の width / height 指定が重要。
文章よりも先に「正しいHTMLタグ設計」ができているかがSEOの出発点です。
SMILEWORKSでは、単に見た目を整えるだけではなく、HTMLタグの意味に沿ったマークアップを重視しています。
これらを制作の標準として運用し、「Googleに正しく評価されるコード」と「利用者にとって読みやすくアクセスしやすいサイト」の両立を常に意識しています。
地味に見える部分こそ、長期的なSEOと品質に直結します。
こうした技術的な基礎を丁寧に積み上げることで、検索に強く、安心して運用できるWebサイトづくりを心がけています。
古いPHPバージョンはすでにサポートが終了しており、不正アクセスなどのリスクが高くなります。
サーバー会社もPHP8を標準に移行しているため、安全にサイトを運営するならアップデートは必須です。
PHP8は旧バージョンと比べて 処理速度が大きく向上しています。
そのため、
といったメリットがあります。
WordPressは今後、PHP8以上の環境を前提としてアップデートされていきます。
古いPHPのままだと、
など、トラブルが起こる可能性が高くなります。
特に、
これらを使っている場合は要注意です。
PHP8にすると一部の機能が動かなくなるケースがあります。
お問い合わせフォームや、独自に作り込まれた機能などは、PHPのバージョン変更で動作が変わる場合があります。
とくに、
などは相性の問題が起きることがあります。
アップデート前のテストが重要になります。
以下は、SMILEWORKSが実際にクライアントサイトで行っている安全なPHPバージョンアップ手順です。
「自分でやるのは不安…」という方は、参考にしてください。
本番サイトを直接アップデートするのは大変危険です。
まずはテスト用サイト（ステージング環境）を作成し、そこで事前検証します。
この時点で画面真っ白になるサイトも多く、PHP8適合のハードルが上がっています。
PHP8対応が進んでいるため、まずはWordPress全体を最新状態にします。
以下を重点的にチェックします。
不具合があれば、テーマやプラグインの更新・修正を行います。
テスト環境で問題がないことを確認したら、同じ手順で本番サイトのPHPを8系へ切り替えます。
作業は深夜〜早朝に実行し、作業前には必ずバックアップを取ります。
本番環境に切り替えたあと、再度ページを全て巡回し、正常に表示されているか確認します。
必要に応じて細かな修正も行います。
PHP8へのアップデートは、ただ新しくするのではなく、
ために欠かせない作業です。
しかし、テーマやプラグインの相性によって突然エラーが出る可能性もあるため、専門家のサポートを受けると安心です。
SMILEWORKSでは、
などを総合的にチェックし、安全にPHP8へ移行できるか無料で診断しています。
近年、ウェブ制作の世界で「Schema.org（スキーマ・ドット・オルグ）」という言葉をよく耳にするようになりました。
SEOの文脈で紹介されることも多いですが、実際の役割はそれだけにとどまりません。
AIブラウザの登場や、検索エンジンの高度な意味解析など、Webの評価軸が“意味構造”へと移行している今こそ、Schema.orgの重要性は増しています。
HTMLは人間が読むための言語であり、検索エンジンやAIにとっては「これは画像」「これは見出し」という見た目の区分しかわかりません。
しかし、同じ <h1>夏のセール開催！</h1> というテキストでも、
機械にとっては曖昧です。
そこで登場するのが Schema.org。
Google・Microsoft・Yahoo! などが共同で作った、Webページの“意味”を機械に正確に伝えるための辞書・ルールセットです。
ページに構造化データ（JSON-LDなど）を埋め込むことで、「これは企業情報」「これはブログ記事」「これはFAQ」といった意味が正確に伝わるようになります。
Schemaの導入には、次のような具体的メリットがあります。
星評価、FAQ展開、価格、日付などが検索結果で強調され、CTRが上がります。
AIは文章の意味構造を解析しますが、Schemaがあると「何についての記事なのか」を正確に理解できます。
これはAIによる引用精度＝AIO（AI Optimization）の重要ポイントです。
著者情報、会社情報、事業内容がSchemaで明示されることで、“誰がその情報を発信しているのか”が伝わり、信頼性が向上します。
スマートスピーカーなどはSchemaを強く参照しています。意味が明確なサイトほど回答候補に選ばれやすくなります。
Schemaには非常に多くの種類がありますが、ウェブ制作でよく使うのは以下です。
| 用途 | @type | 意味 |
|---|---|---|
| 企業情報 | Organization / LocalBusiness | 企業のプロフィールを明示 |
| 記事 | Article / BlogPosting | 記事タイトル・著者・日付 |
| 商品 | Product | ECの商品情報 |
| FAQ | FAQPage | よくある質問 |
| イベント | Event | 開催日時・場所 |
| レビュー | Review / AggregateRating | 評価・スコア |
当サイトでは現在 LocalBusiness と BlogPosting を導入済みで、AI／SEOの両方へ最適化された構造になっています。
従来のSEOは、
といったテキスト中心の評価が主軸でした。
しかし今は、
AIがページ内容を要約し、意味を解釈し、ユーザーに代わって情報提供する時代です。
つまり、
人に見せるだけでなく、AIに“理解させる”必要がある。
Schema.orgは、AIや検索エンジンにページの意図を正しく伝える唯一の公式な方法です。
Schemaは「入れたら終わり」ではありません。
導入後は、以下のツールでのチェックが必須です。
特に、
などがあるとSearch Console が検知してくれます。
Schemaの定期健康診断として活用できます。
Schema自体を計測することはできませんが、検索流入の増加や、CTR改善を効果指標として検証可能。
特にリッチリザルトが効くと、同じ順位でもクリック率が大幅に上がるため、GA4の「ランディングページ × 流入経路」で変化を追うと効果が見えます。
記事URLをAIに貼り付けて、
を確認すると、AI向け最適化（AIO）のチューニングができます。
Schema.orgは単なるSEOテクニックではありません。検索エンジンとAIに“正しく理解される”ための基盤技術です。
すべてが Schema と “意味構造” を軸に進化しています。
ウェブサイトはこれから、「見やすい」だけでなく “意味が伝わる” ことが求められる時代です。
SMILEWORKSではサイト全体のスキーマ導入を行い、AI時代の情報伝達に対応した“戦略的なサイト設計”を実現しています。
近年、ChatGPTの進化系として注目を集めているのが「GPT-Atlas」です。
これは従来のブラウザに代わる、AIが直接ウェブを“理解しながら”表示する新しいブラウジング体験を提供するものです。
この流れは、単なる一製品の登場にとどまらず、「ウェブの見られ方」そのものが変わる転換点になるかもしれません。
これまで私たちは、Googleなどの検索エンジンを通して情報を探し、いくつものページを比較しながら目的の答えを見つけてきました。
しかしAIブラウザの登場により、「探す」ではなく「尋ねる」スタイルへと変わりつつあります。
たとえばユーザーが「補助金でウェブサイトを作るには？」と尋ねると、AIは複数サイトを自動的に読み取り、要約し、関連法令や申請ページのリンクまでまとめて提示します。
ユーザーは検索結果をクリックして回る必要がなく、AIが“調べてくれるブラウザ”が実現します。
OpenAIの「GPT-Atlas」はその象徴的存在ですが、動きは他社にも広がっています。
Microsoftはすでに「Edge」にCopilotを組み込み、ページ要約や文書生成が可能。
Googleも「Chrome」にGemini（旧Bard）の統合を進めており、検索結果ページ自体がAIによる要約に置き換わりつつあります。
AppleもSafariにおいて、プライバシー重視のAI補助を導入すると噂されています。
今後、「AI機能を持たないブラウザ」のほうが珍しくなるでしょう。
ユーザー体験の主役は、もはや“ブラウザ”ではなく“AIアシスタント”へと移行しつつあります。
AIブラウザの普及により、私たち制作者が意識すべき“閲覧者”は人間だけではなくなりました。
AIは、ページ全体のテキスト構造やHTMLタグ、メタ情報、構造化データを解析し、「このページは何を伝えているか」を機械的に判断します。
つまり、美しいデザインや動的なアニメーションよりも、情報の意味づけ（セマンティクス）が重視される時代です。
見た目よりも「AIが理解できる設計」であることが、今後の評価に直結します。
AIブラウザ時代に備えて、制作者が注意しておくべき項目を整理します。
記事、FAQ、レビューなどの構造化データを正しく設定することで、AIが内容を誤解せずに理解できます。
検索エンジンだけでなく、AIブラウザにとっても“正確な情報の目印”になります。
AIは文章全体を読むのではなく、要約モデルによって主要部分を抽出します。
リード文やh2見出しに、記事の要点を含めておくことで、要約の精度が上がります。
AIが誤読しやすい表現は避け、文脈を省略しない書き方を意識します。
特にサービス紹介文などでは、具体的な名詞と動詞を使いましょう。
AIが信頼性を評価する基準として、執筆者・運営元情報の明示が重要になります。
E-E-A-T（Experience, Expertise, Authoritativeness, Trustworthiness）の観点です。
これまでのSEO（Search Engine Optimization）は、AIブラウザ時代にはAIO（AI Optimization）へ進化します。
つまり、「検索で上位に出す」よりも「AIの回答で正確に引用される」ことを目指す考え方です。
AIブラウザが普及するこれからの時代、ウェブサイトは「人に見せる」ものから「AIにも理解される」ものへと進化します。
AIはユーザーに代わってページを要約し、情報を整理し、信頼性を判断します。
ウェブ制作者は、見た目の美しさだけでなく、情報の意味構造・信頼性・整合性までを設計対象とする必要があります。言い換えれば、「AIが読んで誤解しないサイト」こそ、これからの「良いサイト」です。
そして私たち制作者は、そのAIが拾い上げる文脈の作り手として、今後ますます重要な役割を担うことになるでしょう。