-
-
スピーカー 2
じゃあ早速なんですが、まずはコンテンツをどう作るかという最初の入り口から行きたいんですけど。
そうですね。まずはCMSの選定からですね。
スピーカー 2
はい。ソースを見ると極端に違う2つのアプローチが紹介されているじゃないですか。
1つはもう誰もが知っているノーションですね。
スピーカー 1
ええ。そしてもう1つはエンタープライズ向けの強力なCMSであるコンテントフルですね。
スピーカー 2
この2つの比較、すごく極端だなと思ったんですが。
スピーカー 1
いやでもこの2つのツールの比較って、現代のチームが陥りやすい目的と予算のミスマッチを完璧に表しているんですよ。
スピーカー 2
なるほど。ミスマッチですか。
スピーカー 1
はい。多くの企業が自分たちのプロジェクトの本当のサイズ感を未解しないまま、
なんとなくでツールを選定してしまっている現状があるんです。
スピーカー 2
ああ、わかります。ノーションってなんか手軽なDIYのテントみたいなものですよね。
スピーカー 1
まさにテントですね。濃厚度で直感的にパパッと作れて、
無料プロンでもデフォルトのドメインでそのまま公開できちゃうじゃないですか。
スピーカー 2
非常に手軽で便利ですよね。バリュードメインなどで独自ドメインを使いたい場合でも月額10ドルの追加料金で済みますし、
そうそう。ただソースによればSEOの細かな設定とか、ビジュアルを完全にカスタマイズしたいってなると明確な限界があるんですよね。
おっしゃる通りです。内部向けのナレッジベースとか、とりあえずスピード重視で作るランディングページであれば、そのテントで十分天風はしのげるんですよ。
うんうん。まずはテントで十分だと。
スピーカー 1
でも例えば複数言語での本格的なグローバル展開をするとか、複雑なデータベースと連携したオーウンドメディアを構築しようとした瞬間、
テントの骨組みは崩壊してしまうんです。
それそうですよね。テントに重い荷物は詰めないですから。
スピーカー 1
そこで多くの企業が、より堅牢な巨大な工業用倉庫、つまりコンテンツフルのような本格的なヘッドレスCMSへの移行を検討し始めるわけです。
スピーカー 2
なるほど。その工業用倉庫についてなんですが、ソースの価格表を読んで、僕ちょっと目を疑ったんですよ。
スピーカー 1
ああ、あの価格設定ですね。驚きますよね。
スピーカー 2
いや、本当に。無料枠は10ユーザーで月に10万回のAPIコールまでって書いてあるじゃないですか。ここまではまあ親切に見えるんです。
スピーカー 1
数字だけ見ると余裕がありそうに見えますよね。
ですよね。でもアクセスが伸びてAPIの制限を少しでも超えちゃった瞬間に、いきなり年間最低で約3600ドル、日本円で約50万円のがけから突き落とされるって、いくらなんでも直談すぎませんか?
スピーカー 1
実はですね、単にがけから落ちるというより、KRの概念そのものが変わってしまうんです。
スピーカー 2
概念が変わるというと?
コンテンツフルの無料プランは、超価が一切許されないハードリミットとして設計されているんです。
スピーカー 2
ハードリミット、つまり1回でも超えたらアウトってことですか?
スピーカー 1
その通りです。よくあるクラウドサービスみたいに使った分だけ数百円とか数千円が重量課金されるといったグラデーションがないんです。
スピーカー 2
うわあ、それは厳しいですね。
スピーカー 1
強制的にエンタープライズ一歩手前のライトプランへ引き上げられてしまうんですよ。
スピーカー 2
でも月に10万回のAPIコールって、パッと聞くと個人のブログとか中規模のサイトならすごく余裕があるように感じちゃうんですけど。
スピーカー 1
そこが最大の罠なんですよ。
スピーカー 2
罠ですか?
スピーカー 1
はい。APIコールをですね、レストランのウェイターが厨房に料理を取りに行く回数だと想像してみてください。
スピーカー 2
ウェイターの往復の回数ですか?
例えば1ページを表示するのにタイトル、本文、著者情報、画像3枚を別々にリクエストする設計になっていたとしますよね。
スピーカー 2
はいはい。それぞれ別に問いに行くと。
スピーカー 1
そうするとこれだけでたった1人の訪問者が1ページ見ただけで6回のAPIコールが発生するんです。
スピーカー 2
えっと、なるほど。ということは1万人がその記事を見たらあっという間に6万回消費されるってことですか?
スピーカー 1
そういう計算になりますよね。
スピーカー 2
うわぁ、もし記事がバズったりしたら数時間で無料枠の10万回なんて吹き飛んじゃうじゃないですか?
スピーカー 1
そうなんです。しかもですね、実際はもっとシビアでして。
スピーカー 2
まだあるんですか?
スピーカー 1
開発者がサイトをテスト環境で構築したり、更新したりする際の通信もカウントされるんですよ。
スピーカー 2
えぇ、本番のアクセスだけじゃないんだ。
スピーカー 1
さらに恐ろしいのは、ソースにある、そういうコストは低下の40%から60%増しになるという事実です。
スピーカー 2
ちょっと待ってください。50万円払って終わりじゃないんですか?どういうことですか?
スピーカー 1
基本の3500ドルに加えてですね、APIのさらなる超過料金とか、テスト環境と本番環境を分けるための追加スペース費用がかかるんです。
なるほど。オプション料金みたいなものがどんどん乗っかってくると。
ええ。そして何より、その複雑なシステムを維持するための開発者の人件費が重くのしかかってくるんですよ。
スピーカー 2
人件費かぁ。あぁ、そこは見落としがちですね。
スピーカー 1
有名だからとか、大企業も使っているからという理由で導入したものの、高度な権限管理などのエンタープライズ機能は全く使っていない企業が本当に多いんです。
スピーカー 2
それってもったいないですよね。
スピーカー 1
そんな状態で、本来必要なコストの2倍から5倍を払い続けているプロジェクトはもう山のようにあります。
いやぁ、倉庫の分厚いセキュリティ扉とか、巨大な空調設備に高いお金を払っているのに、中に入っているのは段ボール数個だけみたいな状態ですよね。
スピーカー 1
まさにその例えの通りです。無駄が多すぎるんですよね。
スピーカー 2
じゃあ、テントだと心細ないけど、巨大倉庫はオーバースペックだっていう場合、どういう選択肢があるんですか?ソースにはいくつか大体案が挙げられていましたが。
スピーカー 1
そうですね。プロジェクトの性質に合わせて頑丈なログハウスを建てるイメージのツールを選ぶのが良いですね。
スピーカー 2
ログハウス、いいですね。具体的には。
スピーカー 1
例えば、開発者が指導するチームなら、ユーザーあたり月なく15ドルから始められて柔軟性が非常に高いサニティというツールが推奨されています。
サニティですね。なるほど。
スピーカー 1
一方で、マーケティングチームが画面を見ながら直感的に編集したいという要件が強いなら、ストーリーブロックが良いでしょうね。
スピーカー 2
チームの誰がメインで使うかによって変わってくるわけだ。
スピーカー 1
また、自社でサーバーを管理できる技術力があるチームなら、オープンソースのペイロードCMSなどをセルフホストして無料で運用するという点もあります。
スピーカー 2
なるほどな。自分たちが持っている荷物の量と、誰がそれを出し入れするのかを冷静に見極めないと、初期段階で資金がショートするってことですね。
スピーカー 1
その通りです。ツール選びは組織の自己分析から始まるんですよ。
よし、じゃあこれでコストの掛けを避けて適切なCMSを選べたとしましょう。でも次に待っているのは、作ったものをどこに置くかという問題ですよね。
スピーカー 1
はい、ここからがまた重要ですね。
スピーカー 2
ここにもホスティングという名の恐ろしい重量課金の罠が存在していると。
スピーカー 1
CMSが建物の構造だとしたら、ホスティングは土地の契約に当たりますからね。
スピーカー 2
料金体系なんですよ。
スピーカー 1
ああ、ネトリファイですね。
フォーム機能なんかがすごく優秀で使いやすいらしいんですが、本番デプロイ、つまりサイトを更新して世に出す作業の1回につき15クレジットを消費するというルールがあるんですよね。
スピーカー 1
はい、ビルド時間に基づくクレジット消費ですね。
スピーカー 2
月に150回デプロイすると2,250クレジットじゃないですか。ソースを見ると安いプランの枠って1,000から3,000クレジットくらいだから、一瞬で枠が消滅しますよね。
スピーカー 1
そうなんです。彼らはそれを罰金とは呼びませんけど、実質的にはチームの働き方に対する課金システムとして機能してしまっているんですよ。
スピーカー 2
働き方への課金ですか。
スピーカー 1
クラウドの裏側では、あなたがデプロイボタンを押すたびに仮想のコンピューターが立ち上がって、コードを組み立て直すという処理が走っているんです。
スピーカー 2
まあ機械が動いているわけですからね。
スピーカー 1
プラットフォーム側からすれば、そのコンピューターを動かす時間、コンピュート時間にコストがかかっているわけなんですよ。
スピーカー 2
いや、理屈はわかるんですけど、例えば僕みたいな心配症が、記事の誤字を見つけて、1日に5回修正してアップロードし直したら、その都度クレジットが削られるわけですよね。
えー、容赦なく削られます。
スピーカー 2
これって、モダンな開発現場で推奨されている、こまめに保存して更新するというアジャイルな文化と完全に矛盾しませんか。
スピーカー 1
そうなんですよ。
スピーカー 2
完璧主義で細かく直す人ほど損をするっていうか。
スピーカー 1
非常に鋭い指摘です。現代のウェブ運営においてホスティング選びは、単にどこに置くかのスペック比較ではないんです。
スピーカー 2
じゃあ何なんですか。
スピーカー 1
修正を頻繁に行うチームが、ネットリファイのような重量課金を選ぶと、月末の請求書を見て青ざめることになります。
スピーカー 2
そりゃ青ざめますよ。更新頻度が高いなら、デプロイ回数で課金されるサービスは避けるべきなんだ。
スピーカー 1
その通りです。
スピーカー 2
レディットで待機幅が無セレゲンでただ同然だって絶賛されているクラウドフレアページズはどうですか。これなら安心ですよね。
スピーカー 1
確かに静的なファイル。つまり誰が見ても同じ内容が表示されるページを配信するだけなら、クラウドフレアは最強クラスの選択肢ですね。
スピーカー 2
だけならってことは何か裏があるんですか。
スピーカー 1
ええ、そこには技術的な落とし穴があるんです。例えばNext.jsのようなフレームワークを使って、ユーザーごとに中身を変えるSSRやオンデマンドでページを再生成するISRを行おうとすると。
スピーカー 2
するとどうなるんですか。
スピーカー 1
途端に複雑な制約にぶつかってしまうんです。
スピーカー 2
つまり土地はただ同然で提供してくれるけど、この土地には決まった形のプレハブ小屋しか建てちゃダメですよってことですか。
スピーカー 1
まさにその通りです。
スピーカー 2
複雑な注文住宅を建てるなら裏技を使って自分で配管工事してくださいねって言われてるようなものか。
スピーカー 1
その例えは非常に的確ですね。もしあなたのサイトがバックエンドで複雑なデータベース処理を行ったり、ユーザーのログイン状態によって細かく表示を変えたりする必要があれば無理に無料のパスに押し込もうとすると、かえって開発者の人件費が高くついてしまうんです。
スピーカー 2
無理やり合わせようとして余計な手間がかかるわけですね。
スピーカー 1
ええ。それならばレンダーやレイルウェイのように月額の固定費で運用できるサービスを選んだほうが良いんです。
スピーカー 2
固定費なら安心ですね。
スピーカー 1
インフラの予測可能性が高まりますし、結果的に精神的にもお財布にも優しい運用が可能になりますからね。
スピーカー 2
よし。これでCMSのコストの崖を避け、デプロイの罰金も回避して、安全にサイトを構築、そしてホスティングできました。完璧な戦略です。
スピーカー 1
インフラ面はこれでバッチリですね。
スピーカー 2
でもちょっと待ってください。ブルースクレイジャパンのレポートを読むと、こんなに苦労して安くサイトを作っても、2026年の今はそもそも誰もアクセスしてくれない危険性があるってことですよね。
スピーカー 1
そこがインフラ問題からマーケティング問題へのシームレスな移行ポイントなんですよ。
スピーカー 2
マーケティングですか?
スピーカー 1
はい。AIオーバービューズなどの普及によって、ユーザーの検索行動は根底から変わってしまいましたからね。
スピーカー 2
ああ、検索結果のページだけでAIが回答をまとめてしまうから、ユーザーがわざわざリンクをクリックしてサイトに訪れないってやつですね。
ええ、いわゆるゼロクリック検索が当たり前になっています。
スピーカー 2
リスナーのあなたも、最近Googleで何か調べたとき、一番上のAIの回答だけ読んで画面を閉じた経験、絶対にあるはずですよね。
スピーカー 1
ほとんどの人が経験していると思います。
スピーカー 2
でもさ、僕らが一生懸命コンテンツを作っても、検索画面でAIがそれを要約して答えを出しちゃうなら、僕らはただAIにただ働きで餌を与えているだけじゃないの?って思っちゃうんですが。
多くのコンテンツ製作者が、今その恐怖と無力感を抱いていますよね。
スピーカー 2
やってられないですよ。
スピーカー 1
しかし、そこは少し視点を変える必要があるんです。
AIが検索結果で要約してユーザーを満足させられるのは、実は浅い一般的な情報だけなんですよ。
スピーカー 2
浅い情報ですか?
スピーカー 1
ええ。事実の並べとか、辞書的な定義、あとは一般的な手順ですね。これらはもうAIに明け渡してしまえばいいんです。
スピーカー 2
明け渡す。じゃあ、僕らは一体何を書けばいいんですか?
スピーカー 1
AIには絶対に生成できないもの、つまりGoogleのEATの中で最も重要視されているエクスピリエンス、経験です。
スピーカー 2
経験。
スピーカー 1
はい。AIは膨大なデータを学習して、おすすめのCMSトップファイブという比較表を出力することは簡単にできますよね。
スピーカー 2
はい。すごく得意ですよね。
しかし、実際にこのCMSを1年間運用してみて、開発チームとマーケティームの間でどんな衝突が起きたかとか。
ああ、生々しいですね。
スピーカー 1
カスタマーサポートの実際の返答スピードはどうだったか、というような生々しい人間の体験や一時情報はAIには絶対に生み出せないんです。
スピーカー 2
ああ、なるほど。例えば、新しいカメラを買おうとして検索したとき、AIは画素数とか重さのスペックは完璧に教えてくれればいいですか?
スピーカー 1
スペックの比較はお手のものです。
スピーカー 2
でも、氷点下の雪山で手袋をしたままシャッターを切ったとき、このグリップがどれだけ手に馴染むかみたいな話は、実際に山に登った人間にしか語れないですよね。
スピーカー 1
まさにそれです。ユーザーはAIのスペック表を見た後、その先のリアルな検証結果を知りたくて、初めてリンクをクリックするんです。
そうか。深掘りしたいときはやっぱり人間の意見が聞きたいんだ。
スピーカー 1
著者が誰でどんな現場の透明性を持って書いているか、それがAI時代における唯一の読む理由になるんですよ。
スピーカー 2
なるほどなあ。
スピーカー 1
だからこそ従来のSEOは今やGO、つまり生成AI最適化へと進化しなければならないんです。
GO、AIに最適化するってことですか?人間の生々しい体験を書くのに何か矛盾してませんか?
スピーカー 1
ええ、そこが面白いパラドックスなんですよ。人間の深い体験を語るにしても、その情報をAIという情報の案内人に正しく認識してもらわなければ、結局ユーザーには届かないんです。
スピーカー 2
ああ、案内人をスルーしちゃダメなんだ。
スピーカー 1
はい。AIに引用されやすいように、結論ファーストで書き、過剰書きや明確な見出しを使って、論理的な構造を持たせることが必須になります。
スピーカー 2
つまり構造は機械のためにきまめてロジカルにしておくけど。
スピーカー 1
ええ、中身は人間にしか書けない泥臭いインサイトを詰め込む。これが2026年の勝ち筋なんですよ。
スピーカー 2
なるほど。指標のシフトについてもソースで指摘されていましたよね。ただ、検索順位が何位かという単一の指標ではなくて。
スピーカー 1
はい。単一のキーワードの順位はもはや意味が薄れています。
スピーカー 2
検索結果全体での露出シェアを表す。SOV、シェアオブボイスとか。さらにはそのコンテンツが顧客障害価値LTVとか、顧客獲得単価のCACにどう貢献したかっていう事業に直結するKPIを見なきゃいけないと。
スピーカー 1
その通りです。検索の位置を取ればトラフィックが保証される時代は終わりました。
質の高い一時情報を作り、AIにも人間にも信頼される構造を作ることは、単なるハックではなく、ふくりで積み上がる事業の資産への投資なんですよ。
スピーカー 2
よし。泥臭い一時情報をロジカルに構造化して、AI時代にも対応したGEO戦略で見事トラフィックを獲得したとしましょう。
スピーカー 1
これでアクセスも集まりましたね。
スピーカー 2
はい。でも最後のソースにとても重要な事が書かれています。
せっかくやってきたユーザーがそもそもサイトを物理的に使えないとしたら。
スピーカー 1
と、そこが最後の関問ですね。
スピーカー 2
実は日本でもこれが単なるモラルの話ではなく、法律に関わる問題になっているんですよね。
スピーカー 1
はい。クロスマーケティングの資料にある通り、日本では2024年8月に改正障害者差別解消法が施行されました。
2024年4月ですね。
スピーカー 1
ええ。これにより民間事業者にも合理的配慮の提供が義務化されました。
そしてこれは物理的な店舗の断算をなくすといったことだけでなく、デジタル空間、つまりウェブサイトも明確に対象となっているんです。
スピーカー 2
ウェブサイトも対象なんだ。
スピーカー 1
ウェブアクセシビリティの向上がかつてないほど強く求められている状況なんですよ。
スピーカー 2
デジタル空間のバリアフリーですね。具体的にはどういう対応が求められるんですか?
使ったのために文字と背景のコントラストをしっかり確保すること。
スピーカー 2
なるほど。見やすくするわけですね。
スピーカー 1
あとはマウスを使えない方のためにキーボードだけでサイト内を移動できるようにしたり、音声読み上げソフト、スクリーンリーダーを使っている方のために画像に何が写っているのかを伝える適切な代替テキストを設定するといったことです。
スピーカー 2
ああ、アルト属性ってやつですね。
スピーカー 1
ええ、その通りです。
スピーカー 2
これって物理的なお店にスロープをつけるのと全く同じですね。
スロープがあれば車椅子の人だけじゃなく、ベビーカーを引く親とか重い荷物を台車で運ぶ配達員にとっても便利になるじゃないですか。
スピーカー 1
まさにユニバーサルデザインの考え方ですね。
スピーカー 2
リスナーのあなたもスマホの画面が暗くて見えにくい時とか、電車の中で音を出せずに動画を見る時に間違いなくこのアクセシビリティの恩恵を受けているはずですよね。
スピーカー 1
おっしゃる通りです。障害者のための特別な対応と捉えるのではなく、あらゆる人がどんな環境でも快適に情報を受け取れるためのデザインなんですよ。
スピーカー 2
なるほど、これやってないと罰則とかあるんですか。
スピーカー 1
現時点で即座に高額な罰金が課せられるわけではありませんが、放置すれば行政指導や最悪の場合は民事訴訟のリスクがあります。
訴訟のリスクまであるんですね。
スピーカー 1
何より特定のユーザーを排除しているという事実は企業のブランド価値を大きく削くなってしまいますからね。
スピーカー 2
法的リスクやブランド維持のためというのはもちろんなんですが、ソースを読んでいて僕が一番ハッとしたのは、アクセシビリティ対応がビジネス上の武器になるって部分なんですよ。
これひょっとして?
スピーカー 1
お、気づかれましたか?
スピーカー 2
ええ。
スピーカー 1
アクセシビリティに対応するために、サイトのHTML構造をシンプルで論理的なものにする。
画像にアルトタグで正確な説明を入れる。見出しの順番を正しく守る。
これって先ほど話したある対策と技術的なアプローチが全く同じなんです。
スピーカー 2
やっぱり、さっき話したGEO、つまり生成AIや検索エンジンのクローラーに対する最適化と完全に一致しているっていうことですよね?
スピーカー 1
その通りです。
視覚障害者のための音声読み上げソフトが読み取りやすいと判断するサイトは、Googleのクローラーや情報を収集するAIのボットにとっても極めて読み取りやすいサイトなんですよ。
スピーカー 2
うわあ、すごい。
社会的責任を果たすためにアクセシビリティを高めることが、結果的にAIからの評価を上げ、SEOやGEOの効果の増大に直結し、より多くのユーザーを獲得することにつながるんです。
スピーカー 2
いやあ、すべてがつながりましたね。結局のところ、ウェブ運営ってバラバラのタスクじゃないんだ。