# Preferred Inc. — Knowledge articles (full text) > Full body text of the knowledge articles published on https://www.pref.co.jp/knowledge, > followed by the full FAQ from https://www.pref.co.jp/faq. > Both are written in Japanese. Index and metadata: https://www.pref.co.jp/llms.txt --- # なぜ自社だけAI検索に出てこないのか——引用されないサイトに共通する5つの構造 URL: https://www.pref.co.jp/knowledge/ai-search-citation-gap Published: 2026-07-29 Updated: 2026-07-29 Author: 株式会社プリファード Tags: LLMO, GEO, AI検索, AIO, 構造化データ, ChatGPT 検索順位は悪くないのに、ChatGPTやPerplexityでは競合ばかり出てくる。AI検索に引用されないサイトに共通する5つの構造的な原因と、どこから手を付けるべきかを整理する。 ## 「検索順位は悪くないのに、AIには出てこない」 相談の入口として最近多いのが、この形だ。Googleで検索すれば1ページ目に出る。それなりにコンテンツもある。それなのに、ChatGPTやPerplexityで同じことを聞くと、競合の名前だけが並ぶ。担当者としては原因の見当がつかず、「AIのことだから仕方ない」で止まってしまう。 だが、実際に何社かのサイトを見比べていくと、引用されない側にはかなり似た構造上の理由が見つかる。ここでは、私たちが繰り返し目にしている5つを挙げる。 ## 1. 事実が文章の中に溶けている 料金、対応範囲、実績数、拠点、対応時間——AIが回答に使いたいのは、こうした「単体で切り出せる事実」だ。ところがサイト側では、それらが紹介文の中に埋め込まれていることが多い。「豊富な実績をもとに、幅広い業種のお客様をご支援しています」という一文からは、AIは何も取り出せない。人間の読者には伝わる文章でも、引用の単位としては使えない。 ### 切り出せる形にするとは 「対応業種：製造・小売・医療」「初回相談：無料」のように、項目と値が対応した形で置かれていれば、AIはそのまま引用できる。表・定義リスト・FAQといった形式が有効なのは、見た目の問題ではなく、事実が構造として取り出せるからだ。 ## 2. 「〇〇とは」に答えるページがない AI検索で聞かれるのは、まず定義や比較だ。「〇〇とは何か」「AとBの違いは」「相場はいくらか」。こうした問いに正面から答えるページを持っていない会社は、そもそも回答の候補に入らない。サービス紹介ページは「自社が何を売っているか」を語るが、「その領域が何なのか」は語っていないことが多い。この差は大きい。 ## 3. 情報の鮮度が判別できない いつ書かれ、いつ更新されたのかがページから読み取れないと、AIは慎重になる。特に価格・制度・技術仕様のように変わりうる情報では、日付の明示がないだけで採用されにくくなる。「2026年時点の情報です」という一行の有無が、引用の可否を分けることは珍しくない。 ## 4. 同じ話が複数ページに散っている サービスページ、事例ページ、ブログに、同じ説明が少しずつ違う言い回しで置かれている状態は珍しくない。人間なら「どれも同じことを言っている」と分かるが、機械から見ると、どれが正本か判断できない。結果として、どれも強く採用されない。テーマごとに「ここが本体」と言えるページを決め、他はそこへ集約する——この整理をしていない会社は非常に多い。 ## 5. 構造化データが入っていない、または実態と食い違っている JSON-LDによる構造化データは、AIに情報を渡すための最も直接的な手段だ。入っていないケースも多いが、より厄介なのは「入っているが、ページの内容と一致していない」ケースだ。CMS移行やリニューアルの際に古い記述が残り、実在しない情報を宣言し続けていることがある。誤った構造化データは、無いより信頼を損なう。 ## まず何から見るか 5つのうち、着手して効果が見えやすいのは1と2だ。新しくコンテンツを量産する前に、既に持っている情報を「取り出せる形」に置き直し、自社の領域について定義から答えるページを用意する。ここを飛ばして記事を増やしても、引用のされ方は大きくは変わらない。 自社サイトが今どの状態にあるかは、AI検索の無料診断で構造面をひと通り確認できる。判断材料として使ってみてほしい。 --- # AI検索を見据えてCMSを選ぶとき、発注側が確認すべき8項目 URL: https://www.pref.co.jp/knowledge/aio-ready-cms-checklist Published: 2026-07-29 Updated: 2026-07-29 Author: 株式会社プリファード Tags: microCMS, ヘッドレスCMS, CMS選定, AIO, LLMO, 構造化データ CMS選定に「AI検索に載る情報の持ち方ができるか」という軸が加わった。専門知識がなくてもベンダーにそのまま聞ける、発注側のための確認8項目を整理する。 ## CMS選定は「更新しやすさ」だけで決められなくなった これまでのCMS選定は、更新のしやすさ、権限管理、コスト、制作会社の対応可否あたりで決まっていた。そこにいま「AI検索に載る情報の持ち方ができるか」という軸が加わりつつある。これは機能一覧を眺めても判断しづらく、提案を受ける側が何を確認すればいいのか分かりにくい。 ここでは、発注側がベンダーに投げられる形で8項目を挙げる。専門知識がなくても、そのまま質問として使える粒度にしてある。 ## コンテンツの持ち方について ### 1. 項目を分けて持てるか 本文を1つの大きなリッチテキストとして持つのか、「定義」「対象」「料金」「よくある質問」のように項目を分けて持てるのか。後者でなければ、後から構造化データを組み立てられない。ヘッドレスCMSを選ぶ実質的な理由の大半はここにある。 ### 2. FAQ・比較表を型として持てるか AI検索で引用されやすい形式は、ある程度分かってきている。FAQ、定義、比較表がその代表だ。これらを「記事本文の中にHTMLで書く」のではなく、繰り返し項目として持てるか。持てれば、構造化データもページ表示も同じ元データから自動で作れる。 ### 3. 公開日と更新日を別々に持てるか 地味だが効く。初出と最終更新が分かれて記録・出力できるかを確認する。片方しか持てないCMSは、情報の鮮度を正しく伝えられない。 ## 公開まわりの自動化について ### 4. 公開をトリガーに外部処理を呼べるか（Webhook） 公開・更新の瞬間に外部の処理を走らせられるかどうかで、自動化の天井が決まる。構造化データの生成、品質チェック、通知、検索インデックスの更新——いずれもここが起点になる。 ### 5. APIで一括の読み書きができるか 数百件のコンテンツに後からメタデータを足す、といった作業が発生したときに、管理画面での手作業しか手段がないと詰む。APIから一括で読み書きできるかは、運用開始後にじわじわ効いてくる。 ## 出力側について ### 6. HTMLの構造をこちらで決められるか 見出しの階層、リスト、表がそのまま出るか。テーマやテンプレートに引きずられて意図しないマークアップになるCMSは、機械可読性の面で不利になる。 ### 7. 構造化データを自動で出せるか 「JSON-LDに対応していますか」と聞くと、たいてい「対応できます」と返ってくる。踏み込んで「入力した内容から自動生成されるのか、記事ごとに手で書くのか」まで確認したい。手書き運用は必ず抜けが出る。 ### 8. 表示速度を担保できる構成か クローラーに取得されなければ、内容以前の問題になる。静的生成・CDN配信を前提にできる構成かどうかを確認する。 ## チェックリストの使い方 8項目すべてを満たす必要はない。重要なのは、満たさない項目について「なぜ満たさなくてよいのか」を発注側が説明できる状態にすることだ。そこが曖昧なまま進むと、公開後に「後から構造化データを入れられない」と分かって作り直しになる。 なお、microCMSはこの8項目の多くを標準で満たせる。当社はmicroCMS公式パートナーとして、この観点でのスキーマ設計から対応している。 --- # llms.txt とは何か。入れるべきか、様子を見るべきか URL: https://www.pref.co.jp/knowledge/llms-txt-guide Published: 2026-07-29 Updated: 2026-07-29 Author: 株式会社プリファード Tags: llms.txt, LLMO, AIO, AI検索, GEO AI検索対策の提案書でよく見る llms.txt。公式仕様ではないこのファイルは何をするもので、効果は保証されているのか。入れる場合の注意点と、判断の目安を正直に整理する。 ## 「llms.txt を入れましょう」と提案されたら AI検索対策の提案書に llms.txt という項目が並ぶことが増えた。robots.txt に似た名前だが、役割は違う。そして重要なこととして、これは検索エンジンの公式仕様ではなく、有志から提案されたフォーマットだ。判断するには、この前提を押さえておく必要がある。 ## 何をするファイルなのか llms.txt は、サイトのルートに置くMarkdown形式のテキストファイルだ。「このサイトは何者で、重要なページはどこにあるか」を、AIが読みやすい形で一枚にまとめたものだと考えればよい。会社概要、提供しているもの、主要ページへのリンクを、装飾もスクリプトもない素のテキストで並べる。 通常のWebページは、ナビゲーション、バナー、スクリプトといった本題以外の要素を大量に含む。llms.txt は、そこから本題だけを抜き出して渡す「案内板」にあたる。 ## 効果は保証されているのか 正直に書くと、保証はない。主要なAI検索事業者が「llms.txt を読む」と公式に宣言している状況ではなく、現時点では「読まれるかもしれない」段階だ。導入すれば引用が増える、と説明する提案には慎重になったほうがいい。 それでも私たちが入れておく価値はあると考えているのは、コストと非対称性のためだ。作成にかかる手間は数時間で、リスクはほぼない。一方、将来的に参照されるようになったときに用意がなければ、その分だけ出遅れる。「効くと確信しているから入れる」のではなく、「安いので押さえておく」という位置づけが実態に近い。 ## 入れるなら気をつけたいこと ### 放置すると逆効果になる 最も多い失敗は、一度作って更新されなくなることだ。サービス構成が変わり、ページが増減しても llms.txt だけが昔のまま残る。実態と食い違った案内板は、無いよりも悪い。作るなら、サイト構成を変えたときに一緒に見直す運用まで決めておく。 ### 盛らない 提供していないものを書く、実績を誇張する——といったことをすると、他のページとの矛盾が生じる。AIは複数の情報源を突き合わせるため、矛盾は信頼性を下げる方向に働く。素直に事実を並べるのがよい。 ### 本体の情報設計の代わりにはならない llms.txt を置いたからといって、サイト本体の情報が取り出しにくいままなら、大きな変化は期待できない。あくまで補助だ。優先順位としては、本体のページで事実を構造化して持つことのほうがずっと高い。 ## 判断の目安 結論として、「入れておいてよいが、それ単体を施策として売られたら疑ってよい」というのが現実的な線だと考えている。数時間で終わる作業に対して大きな費用が提示されている場合や、効果が断定的に説明されている場合は、内訳を確認したほうがいい。 当社自身も、このサイトに llms.txt を置いて運用している。中身は /llms.txt でそのまま確認できるので、実物を見て判断材料にしてもらえればと思う。 --- # LLMOの成果は何で測るのか——AI検索の「引用」を追う現実的な方法 URL: https://www.pref.co.jp/knowledge/llmo-kpi-measurement Published: 2026-07-29 Updated: 2026-07-29 Author: 株式会社プリファード Tags: LLMO, AIO, AI検索, KPI, 効果測定, GA4 SEOの検索順位にあたる指標がLLMOにはない。それでも継続的に追える4つの指標と、社内で予算を通すための報告の組み立て方を、測れないことも含めて正直に整理する。 ## 「効果はどう測るんですか」で止まる AI検索対策の話は、たいていここで止まる。SEOには検索順位と流入数という共通言語があったが、LLMOにはそれがない。社内で予算を通す立場からすると、測れないものには判断のしようがない。 先に結論を書くと、SEOのような精密な計測は現時点ではできない。ただし「まったく分からない」わけでもない。粗いが継続的に追える指標はいくつかある。 ## 指標1：指名クエリでの言及有無（手動でよい） 最も基本的で、最初にやるべきことだ。自社の領域でよく聞かれるであろう質問を10〜20個決め、主要なAIサービスで月に一度実際に聞いてみる。自社が出てくるか、競合が何社出てくるか、どの文脈で言及されるかを記録する。 手作業だが、これが一番確実だ。回答は毎回揺れるので、1回の結果に一喜一憂せず、数ヶ月の傾向として見る。質問文はいつも同じにしておくこと。 ### 記録するのは「出た／出ない」だけではない どう説明されているかも重要だ。事実と違う説明をされている、古いサービス名で言及されている、といった発見は、そのまま次の打ち手になる。順位のような数字より、この定性的な記録のほうが実務では役に立つことが多い。 ## 指標2：AIサービスからの流入 ChatGPTやPerplexityの回答内のリンクから訪問があった場合、アクセス解析上は参照元として記録される。GA4であれば参照元ドメインでの絞り込みができる。 ただし数字は小さく出る。AI検索の性質上、ユーザーは回答を読んで満足し、リンクを踏まないことが多いためだ。「流入が少ない＝引用されていない」ではない点に注意がいる。これは補助的な指標として見る。 ## 指標3：クローラーのアクセス状況 各社のAIクローラーが自社サイトを取得しに来ているかは、サーバーログやCDNのログで確認できる。引用の前段として「そもそも読まれているか」を確かめる指標だ。 取得されていないなら、内容以前にアクセス性の問題がある。robots.txt での拒否設定、認証、極端に遅い応答などが原因になっていることがある。 ## 指標4：構造面のスコア 引用のされやすさは、構造化データの有無、見出し階層、FAQの整備状況といった「サイト側の状態」にかなり依存する。これらは自社の努力で完全にコントロールでき、月次で測れる。 成果指標（引用されたか）は相手次第で揺れるが、この構造指標は着実に積み上がる。予算を通す文脈では、こちらを主指標に置くほうが説明しやすい場合が多い。 ## 報告の組み立て方 実務としては、構造スコアを主指標、指名クエリでの言及状況を補助指標、流入を参考値、という組み立てが扱いやすい。「順位が何位上がった」に相当する単一の数字はまだ存在しないので、無理に作らないほうがいい。断定的な数値効果を約束する提案には、根拠を確認したほうがよい。 構造面の現状把握には無料の診断ツールを用意している。初回のベースライン取得に使ってもらえればと思う。 --- # microCMS × AI検索対策、どこまでやるといくらか——スコープの切り方 URL: https://www.pref.co.jp/knowledge/microcms-aio-cost-and-scope Published: 2026-07-29 Updated: 2026-07-29 Author: 株式会社プリファード Tags: microCMS, AIO, LLMO, 見積もり, 費用, プロジェクト設計 同じ「AI検索対策」でも、見積もりは月10万円から数百万円まで幅がある。作業を4つの層に分けて、自社がどこまで必要なのかを判断し、見積もりを比較できるようにするための整理。 ## 見積もりが比べられない AI検索対策の見積もりは、会社によって桁が違うことがある。同じ「LLMO対応」という言葉で、月10万円の運用支援もあれば、数百万円の構築案件もある。何が含まれているかが揃っていないので、金額だけを並べても比較にならない。 ここでは費用の話をする前に、作業を4つの層に分けて整理する。自社がどこまで必要なのかを判断できれば、見積もりは比較できるようになる。 ## 層1：現状把握と設計 今のサイトがAI検索から見てどういう状態にあるかを確認し、どこに手を入れるかを決める工程だ。構造化データの有無、情報の持ち方、競合がどう引用されているかを調べる。 ここだけを単独で発注することもできる。手を入れる前に社内の合意を取りたい場合や、既存の制作会社に作業を依頼する前提で方針だけ固めたい場合に向く。数週間程度の作業になることが多い。 ## 層2：情報の持ち方の作り直し（スキーマ設計） microCMS側のスキーマを、FAQ・定義・比較といった「引用されやすい単位」で持てるように組み直す層だ。ここが実質的な本体にあたる。 既存コンテンツの移し替えが伴うため、コンテンツ量が費用に直結する。数十件なのか数千件なのかで、必要な工数はまったく変わる。見積もりを比較するときは、対象件数の前提が揃っているかを必ず確認したい。 ## 層3：公開まわりの自動化 記事を公開したら構造化データ・メタデータ・OGP画像が自動で付く、という状態を作る層だ。Webhookを起点に処理をつなぐ。 一度作れば運用の手作業が減り続けるので、更新頻度が高いサイトほど回収が早い。逆に、年に数回しか更新しないサイトでは、手作業のままでも困らないことが多い。更新頻度が判断の分かれ目になる。 ## 層4：継続的な運用・計測 月次でAI検索での言及状況を確認し、コンテンツを追加・修正していく層だ。ここは1回で終わる作業ではないので、月額での契約になる。 注意したいのは、層2・層3を飛ばしてここだけ契約しても効きにくいことだ。土台が整っていない状態で運用支援だけを続けると、費用に対して変化が見えにくい。 ## どこから始めるべきか 更新頻度が高く、コンテンツ量が多いサイトなら、層2から入って層3まで通すのが素直だ。まだ判断がついていない段階なら、層1だけを切り出して現状を把握し、社内で議論する材料にするのが無駄がない。 全部を一度にやる必要はない。むしろ、いきなり大きく組むと効果が出たのかどうかも分からなくなる。当社では対象を絞った小さな範囲で試し、変化を見てから広げる進め方を勧めている。 ## 見積もりを比較するときの確認点 - 対象コンテンツの件数は前提として揃っているか - スキーマの作り直しが含まれるのか、既存のまま構造化データだけ足すのか - 自動化の対象がどこまでか（構造化データのみか、OGP・翻訳まで含むか） - 初期費用と月額の切り分けはどうなっているか - 効果について、断定的な保証をしていないか 金額の妥当性は、この5点が揃って初めて判断できる。具体的な費用感については、サイトの規模と更新頻度を伺えれば概算をお出しできる。相談・見積もりは無料なので、比較検討の材料として使ってもらえればと思う。 --- # 構造化データ（JSON-LD）を、発注する側が理解しておく最低限 URL: https://www.pref.co.jp/knowledge/structured-data-for-decision-makers Published: 2026-07-29 Updated: 2026-07-29 Author: 株式会社プリファード Tags: 構造化データ, JSON-LD, Schema.org, AIO, LLMO, microCMS 見積書に一行だけ入っている「構造化データ対応」。実装は制作側の仕事でよいが、発注側が押さえておくと会話が噛み合う3つの確認点と、よくある誤解を整理する。 ## 「入れておきました」で終わらせない 構造化データは、制作会社の見積書に一行だけ入っていて、詳細が分からないまま進むことの多い項目だ。技術的な話に見えるため発注側が踏み込みにくく、結果として「入っているはずだが、何がどう入っているかは知らない」状態になりやすい。 実装そのものは制作側の仕事でよい。ただ、発注側が最低限これだけ理解していれば会話が噛み合う、という範囲がある。ここではそこに絞って説明する。 ## 何をしているものか Webページは人間が読むためのものなので、機械から見ると「どれが会社名で、どれが料金で、どれが所在地か」が判別しづらい。構造化データは、そのページの内容を機械向けに整理し直して、ページの中に一緒に埋め込んでおく仕組みだ。JSON-LDというのは、その書き方の形式のひとつを指す。 人間が見る画面には現れない。ページの裏側に、機械向けの要約が添えられていると考えればよい。 ## なぜAI検索で効くのか AIが回答を作るとき、ページの文章を解釈するより、整理済みのデータをそのまま受け取るほうが確実だ。解釈のステップが減れば、誤読も減る。事実を正確に伝えたい情報——料金、営業時間、対応範囲、FAQの答え——ほど、構造化データで渡す価値が大きくなる。 ## 発注側が確認すべき3つのこと ### 1. どの種類を入れるのか 構造化データには種類がある。会社情報を伝えるもの、記事であることを伝えるもの、よくある質問を伝えるもの、パンくずを伝えるもの——用途ごとに使い分ける。「構造化データを入れます」とだけ書かれた見積もりには、どの種類を、どのページに入れるのかを確認したい。 ### 2. 自動で付くのか、手で書くのか これが最も重要な確認点だ。CMSに入力した内容から自動生成される設計なら、記事が増えても運用は変わらない。一方、記事ごとに手で書く設計だと、いずれ必ず抜けが出る。担当者が代わった時点で止まることも多い。 「今後コンテンツを追加していったとき、構造化データは自動で付きますか」——この一問で、設計の質はかなり分かる。 ### 3. 中身とページの内容が一致し続けるか 構造化データはページの内容と一致している必要がある。表示は変えたのに構造化データは古いまま、という食い違いは、リニューアルやCMS移行の際によく起きる。実態と違うことを宣言しているページは、無いより信頼を損なう。同じデータから表示と構造化データの両方を作る設計なら、この食い違いは原理的に起きない。 ## よくある誤解 「構造化データを入れれば検索順位が上がる」という説明を受けることがあるが、順位に直接効くものではない。効くのは、検索結果での見え方と、機械が内容を正確に理解できることだ。AI検索の文脈では後者が重要になる。順位向上を約束する説明には注意したほうがよい。 ## 手を入れる順番 すべてのページに一斉に入れる必要はない。会社情報・主要サービス・よくある質問——この3つから始めれば、AI検索で聞かれやすい質問の大半はカバーできる。当社ではmicroCMSのスキーマ設計の段階でここを織り込み、入力した内容からJSON-LDが自動で組み上がる形にしている。 --- # AI検索を前提にすると、コンテンツ運用の体制はどう変わるか URL: https://www.pref.co.jp/knowledge/content-ops-org-design Published: 2026-07-29 Updated: 2026-07-29 Author: 株式会社プリファード Tags: コンテンツ運用, 運用体制, microCMS, AIO, LLMO, オウンドメディア CMSを刷新して自動化も入れたのに運用が回らない。原因は技術ではなく分担にある。AI検索を前提にしたとき持ち主を決めておきたい4つの領域と、小さい組織での現実的な分け方を整理する。 ## ツールを入れても運用が回らない理由 CMSを刷新し、自動化の仕組みも入れた。それでもコンテンツ運用が回らない——という相談は少なくない。原因の多くは技術ではなく、誰が何を持つかが決まっていないことにある。AI検索を前提にすると、この分担の設計はこれまで以上に重要になる。 ## 変わること：書く仕事から、事実を管理する仕事へ 従来のコンテンツ運用の中心は「記事を書く」ことだった。AI検索を意識すると、そこに「自社に関する事実を、正確な形で維持する」という別の仕事が加わる。料金、対応範囲、実績、体制——こうした情報が、サイト全体で食い違いなく、最新の状態で保たれているか。 これは執筆スキルとは別の仕事だ。文章がうまい人が向いているとは限らず、むしろ社内の情報を横断的に把握している人のほうが適している。 ### この役割が誰にもないと何が起きるか 典型的なのは、サービス内容が変わったのに古いページが残り続けるケースだ。担当部署は自分たちのページを更新するが、他部署のページや過去の記事に同じ話が書かれていることには気づかない。結果として、サイト内で矛盾した説明が並ぶ。AIは複数のページを突き合わせるため、この矛盾は素直に効いてくる。 ## 持ち主を決めておきたい4つの領域 ### 1. 事実の正しさ 料金や対応範囲といった情報が、実態と一致しているか。事業側にしか判断できないため、マーケティング部門に丸投げできない。四半期に一度でよいので、事業責任者が確認する運びを作る。 ### 2. 情報の構造 何をどの型で持つか、新しいコンテンツをどこに置くか。ここが決まっていないと、記事が増えるほど散らかる。CMSのスキーマを理解している人が持つ必要があり、社内にいなければ制作会社側に置いてもよい。 ### 3. 公開前の品質チェック 表記の統一、法的な表現の確認、メタデータの設定漏れ。人手で全件見るのは早い段階で限界が来るので、機械で拾える部分は自動化し、人は指摘された箇所だけ見る形に寄せる。 ### 4. 効果の確認と次の打ち手 月次でAI検索での言及状況を見て、次に何を書くかを決める。ここが空席だと、コンテンツ制作が「思いついたものを書く」に戻ってしまう。 ## 小さい組織ではどうするか 4領域すべてに専任を置ける会社は多くない。現実的には、1と4を社内（事業を分かっている人）が持ち、2と3を外部に出す形が回りやすい。逆に、2と3を社内で持って1と4を外部に丸投げすると、事業の実態と発信内容がずれていく。 外部に出す範囲を決めるときの基準は「事業の判断が必要かどうか」だ。判断が要る部分は社内に残し、仕組みと手を動かす部分は外に出す。 ## 体制から先に決める ツールの選定より先に、この4領域の持ち主を決めておきたい。決まっていれば、必要な仕組みは自ずと絞れる。決まらないまま高機能なCMSを入れても、使われない機能が増えるだけになる。 当社ではmicroCMSの導入・運用支援の中で、この分担の整理から入ることが多い。仕組みの前に、誰が何を持つかを一緒に決めるところからで構わない。 --- # 人材開発支援助成金とは？2026年度のコース・助成率・申請の流れ完全ガイド URL: https://www.pref.co.jp/knowledge/jinzai-kaihatsu-subsidy-guide-2026 Published: 2026-07-19 Updated: 2026-08-06 Author: 株式会社プリファード Tags: 人材開発支援助成金, リスキリング, AI研修, DX研修, 助成金, eラーニング 中小企業なら研修経費の最大75%が助成される「人材開発支援助成金」。AI・DX研修で使える2コースの助成率・上限額・申請の流れと、不支給になる典型パターンを解説する。 ## 研修費用の最大75%を国が負担する制度 人材開発支援助成金は、厚生労働省が実施する、企業の人材育成を支援する助成金制度だ。事業主が従業員に職業訓練（OFF-JT）を実施した場合に、訓練経費と訓練期間中の賃金の一部が助成される。中小企業の場合、コースによっては経費の最大75%が助成されるため、1人あたり40万円のAI研修が実質10万円程度で受講できる計算になる。 「研修はやりたいが費用の承認が通らない」という企業にとって、これほど使い勝手のよい制度は他にない。にもかかわらず、制度の存在自体を知らない、あるいは「手続きが面倒そう」という理由で使われていないケースが非常に多い。 ## AI・DX研修で使える主な2コース ### 事業展開等リスキリング支援コース 新規事業の立ち上げやDX化に伴い、必要となる知識・技能を習得させるための訓練を対象とするコース。AI研修・DX研修との相性が最もよい。中小企業は経費助成率75%（大企業60%）、賃金助成は1人1時間あたり中小企業1,000円（大企業500円）。1人1訓練あたりの経費助成上限は、訓練時間10〜100時間未満で30万円（中小企業の場合）となっている。 注意すべきは期限だ。このコースは令和8年度末（2027年3月31日）で終了予定とされており、活用できるのは残りわずかの期間しかない。 ### 人への投資促進コース（高度デジタル人材訓練） DX推進を担う高度デジタル人材の育成訓練を対象とするコース。こちらも中小企業75%・大企業60%の経費助成率が適用される。賃金助成は中小企業960円/人時・大企業480円/人時。 ## 対象になるための基本条件 - 雇用保険の適用事業所であること - 受講対象者が雇用保険の被保険者であること - OFF-JT（業務命令に基づく職場外訓練）で、実訓練時間が10時間以上であること - 訓練開始の1ヶ月前までに、管轄労働局へ訓練実施計画届を提出すること - 訓練終了後2ヶ月以内に支給申請を行うこと ## eラーニングでも使えるのか 使える。ただし2026年度の改正で、eラーニング・通信制の訓練は「経費助成のみ」となり、賃金助成は対象外となった。また申請には受講管理システム（LMS）の受講ログの提出が必要になる。LMSログを発行できる研修事業者を選ぶことが、eラーニングで助成金を使う際の必須条件だ。 さらに2026年8月3日施行の改正で、eラーニングによる訓練（他の実施方法との組合せを含む）で助成を受けられる回数は、同一労働者につき一の年度で1回までに制限された（8月3日以降に提出された計画届から適用）。同じ年度に複数のeラーニング講座で助成を受けることはできなくなったため、年間の研修計画を立てる際は注意したい。 ## 申請の流れと典型的な失敗パターン 申請フローは「計画届の提出（訓練開始1ヶ月前まで）→ 訓練実施 → 支給申請（終了後2ヶ月以内）→ 審査・受給」という流れになる。不支給になる典型的なパターンは、計画届の提出遅れ、訓練時間の不足、出席記録や実施記録の不備の3つ。いずれも研修事業者側の書類サポートがあれば避けられるものだ。 なお、申請手続きの代行は社会保険労務士の独占業務であるため、研修会社が「代行します」と謳っている場合は注意したほうがよい。当社では訓練計画書・カリキュラム・実施記録・LMSログなど研修側で必要な書類はすべて用意し、手続き自体は事業主または提携社労士が行う形でサポートしている。 ## まずは対象になるかの診断から 助成金の適用可否は、企業規模・訓練内容・雇用状況によって変わる。当社では対象診断から実質負担額のシミュレーション、申請書類の作成サポートまで無料相談で対応している。制度の期限を考えると、検討はできるだけ早いほうがよい。 ※本記事の数値は2026年度時点の情報です。制度は年度ごとに改正されるため、最新の支給要領は厚生労働省の公式情報をご確認ください。受給を保証するものではありません。 --- # 【2026年改正】事業展開等リスキリング支援コースの変更点——期限は2027年3月末 URL: https://www.pref.co.jp/knowledge/reskilling-subsidy-2026-revision Published: 2026-07-19 Updated: 2026-08-06 Author: 株式会社プリファード Tags: 人材開発支援助成金, 事業展開等リスキリング支援コース, 2026年改正, リスキリング, AI研修, 助成金, eラーニング AI研修に最も使いやすい「事業展開等リスキリング支援コース」は2027年3月末で終了予定。2026年改正での新類型追加・eラーニングの扱いに加え、8月3日施行の「汎用的DX研修の対象外化」「eラーニング年度1回制限」まで最新のポイントを整理する。 ## 「使えるのは今年度が最後」になる可能性が高い AI・DX研修に最も使いやすい助成金である「人材開発支援助成金（事業展開等リスキリング支援コース）」は、令和8年度末——つまり2027年3月31日で終了予定だ。訓練開始の1ヶ月前までに計画届を提出する必要があることを考えると、実際に動ける期間はさらに短い。研修への助成金活用を検討している企業にとって、2026年度は事実上のラストチャンスとなる。 ## 2026年改正の主な変更点 ### 1. 新しい訓練類型の追加 従来の「事業展開に伴う訓練」「DX化・GX化に伴う訓練」に加え、「企業内の人事・人材育成に関する計画に基づく訓練」が新たに対象となった。おおむね3年以内の人事配置・育成計画を作成したうえで、従業員が「これから従事する予定の職務」に必要な知識・技能を習得する訓練も助成対象になる。 ただしこの新類型を使う場合は、訓練開始1ヶ月前までに「認定経営革新等支援機関」による計画内容の確認を受けることが要件となっている点に注意が必要だ。 ### 2. eラーニングの取り扱い変更 eラーニング・通信制の訓練は「経費助成のみ」となり、賃金助成の対象外となった。また、1人1訓練あたりの経費助成上限額も見直されている。eラーニングで申請する場合は、受講管理システム（LMS）による受講ログの提出が必要だ。 ### 3. 賃金助成の増額（2025年4月〜） 対面型訓練の賃金助成は、中小企業で1人1時間あたり1,000円（従来960円）、大企業で500円に増額されている。12時間の研修なら、受講者1人あたり1.2万円の賃金助成が経費助成とは別に受けられる計算だ。 ### 4. 【2026年8月3日施行】汎用的なDX研修の対象外化とeラーニング回数制限 2026年8月3日、本コースにさらに大きな改正が施行された（厚生労働省リーフレット LL080803開企01）。8月3日以降に提出された計画届から適用されるため、これから申請する企業はすべて対象となる。変更点は次の2つだ。 ① 汎用的な内容のDX化・GX化訓練が助成対象外に。職務に間接的に必要となる知識・技能の習得にとどまるものや、職業人として共通して必要な汎用的内容の訓練は対象外となった。厚労省が示す具体例では、「汎用的なプロンプトの作り方を学ぶ訓練」「DXの概念やデータ活用の考え方を学ぶ訓練」は対象外、一方で「生成AIを活用して商品提案書の構成案作成・文章生成を学ぶ営業担当者向けの訓練」のように受講者の具体的な業務に直結する訓練は引き続き対象とされている。あわせて、訓練内容に沿った受講者選定も求められる（例：CO₂排出量算定の研修を、算定業務を担当しない人事・営業の従業員が受講すると対象外）。 ② eラーニングは同一労働者につき年度1回まで。本コースの受講回数上限は年度3回だが、このうちeラーニングによる訓練（他の実施方法との組合せを含む）は年度1回までに制限された。 つまり「とりあえず全社員にAIリテラシー研修を」という汎用型の使い方はできなくなり、職種・職務に合わせたカリキュラム設計が助成の前提になった。なお、8月2日以前の契約・申込分には経過措置がある。 ## 改正後の助成内容まとめ（中小企業の場合） - 経費助成率：75%（大企業は60%） - 経費助成上限：訓練時間10〜100時間未満で30万円/人（100〜200時間未満40万円、200時間以上50万円） - 賃金助成：1,000円/人時（eラーニングは対象外） - 要件：OFF-JT・実訓練10時間以上、訓練開始1ヶ月前までの計画届 - 訓練内容：受講者の職務に直結する内容であること（汎用的なリテラシー研修は対象外・2026年8月3日〜） - eラーニング：同一労働者につき年度1回まで（2026年8月3日〜） ## いま何をすべきか 制度終了までのスケジュールから逆算すると、動き出しは早いほどよい。「どの研修が対象になるのか」「自社は条件を満たすのか」の診断は無料相談で対応しているので、まずは対象可否の確認から始めてほしい。当社のAI研修（生成AI活用・AI駆動開発・JAMStack・eラーニング）はいずれも助成金活用を前提とした設計で、訓練計画書の作成からLMSログの発行までサポートしている。 ※本記事の数値は2026年度時点の情報です。最新の支給要領は厚生労働省の公式情報をご確認ください。受給を保証するものではありません。 --- # CDNとキャッシュ設計：Webの速さは「作り方」より「配り方」で決まる URL: https://www.pref.co.jp/knowledge/cdn-and-caching Published: 2026-07-05 Updated: 2026-07-05 Author: 株式会社プリファード Tags: CDN, キャッシュ, パフォーマンス, Core Web Vitals JSや画像を削る前に、配信を見直すだけで速くなることは多い。CDNとキャッシュ（Cache-Control）の設計、動的サイトでの活かし方まで、体感速度を上げる「配り方」の基本を解説する。 ## コードを削るより、配信を見直すほうが速いことは多い 表示速度の相談を受けると、多くの人はまず「JavaScriptを削る」「画像を圧縮する」といったアプリ側の最適化を思い浮かべる。もちろん大事だが、私たちの経験では、配信（デリバリー）の設計を見直すほうが、少ない手間で大きく効くケースが少なくない。同じHTMLでも、どこから・どうやって届けるかで体感速度はまるで変わる。 ## CDNは「距離」と「混雑」を同時に解く CDN（コンテンツデリバリネットワーク）は、世界中に配置されたサーバーの中からユーザーに最も近い拠点でコンテンツを返す仕組みだ。効果は主に二つ。ひとつは物理的な距離を縮めて往復時間（レイテンシ）を減らすこと。もうひとつは、オリジンサーバー（本体）にアクセスを集中させず、混雑を肩代わりさせること。アクセスが増えても本体が落ちにくくなる、という耐障害性の側面も見逃せない。 ## キャッシュは「何を・どれくらい」持たせるかがすべて CDNを入れただけでは速くならない。鍵はキャッシュ設定だ。画像・CSS・JSといった変化しない静的アセットは長期間キャッシュし、ファイル名にハッシュを付けて更新時だけ別物として扱う（キャッシュバスティング）。一方、価格や在庫のように頻繁に変わる情報を長くキャッシュすると、古い内容が表示される事故になる。「めったに変わらないものは長く、変わるものは短く（あるいは持たせない）」——この切り分けを最初に決めておく。 ### Cache-Control を曖昧にしない キャッシュ事故の大半は、Cache-Control ヘッダーの設定が曖昧なまま本番に出たことが原因だ。「public / private」「max-age」「s-maxage」「stale-while-revalidate」——このあたりを、コンテンツの種類ごとに明示的に決める。なんとなくのデフォルト任せが一番危ない。 ## 動的なページこそ、キャッシュの工夫が効く 「うちは動的サイトだからキャッシュは無理」と諦める必要はない。ログイン後の個人向け画面はキャッシュできなくても、トップページや記事ページのような大多数に同じ内容を返す部分は、短時間でもエッジでキャッシュすれば効果は大きい。JAMStack や ISR（増分静的再生成）のように、動的な更新と静的な速さを両立させる作り方も一般的になっている。 ## まずは「何がキャッシュされていないか」を見る 改善の第一歩は計測だ。ブラウザの開発者ツールやCDNの管理画面で、各リソースがキャッシュに当たっているか（HIT / MISS）を確認する。MISSばかりの静的ファイルが見つかれば、そこが伸びしろだ。速さは気合いではなく設計で決まる。配り方を整えるだけで、コードに手を入れずとも一段速くなることは珍しくない。 --- # フィッシングと不正アクセス：中小企業が「今日から」できる最初の一手 URL: https://www.pref.co.jp/knowledge/phishing-account-takeover Published: 2026-07-05 Updated: 2026-07-05 Author: 株式会社プリファード Tags: フィッシング, 不正アクセス, MFA, 情報セキュリティ 狙われるのは大企業だけではない。侵入経路の多くはフィッシングとパスワード使い回しという「人」の隙だ。MFA・パスワードマネージャー・報告窓口という、今日から無料で始められる一手を解説する。 ## 狙われるのは「大企業だけ」ではない 「うちは小さいから狙われない」——情報セキュリティの相談で、いまだに聞く言葉だ。しかし攻撃側にとって、企業規模はあまり関係ない。むしろ対策が手薄な中小企業は、取引先の大企業へ侵入するための「踏み台」として狙われやすい。自社が被害者であると同時に、加害者（の入口）になってしまうリスクがある、という視点が抜け落ちていることが多い。 ## 入口の大半は、高度な技術ではなく「人」 ニュースになる派手なハッキングを想像しがちだが、実際の侵入経路で圧倒的に多いのは、フィッシングメールとパスワードの使い回しだ。取引先や配送業者、社内システムを装ったメールのリンクを踏み、本物そっくりの偽ログイン画面に認証情報を入力してしまう。あるいは、どこかで漏れたパスワードを他のサービスでも使っていて、芋づる式に破られる。技術ではなく、人の油断が入口になる。 ## 今日からできる、効果の大きい3つ ### 1. 多要素認証（MFA）を全アカウントで有効化する 最もコストが低く、最も効果が高い対策だ。パスワードが漏れても、スマホのワンタイムコードや認証アプリという二つ目の壁があれば、不正ログインの大半は防げる。メール・グループウェア・主要SaaSから順に、例外なく有効化する。「面倒だから一部だけ」が穴になる。 ### 2. パスワードマネージャーを配る 「複雑なパスワードを、使い回さずに」を人間の記憶力で実現するのは不可能だ。パスワードマネージャーを全社に配布し、サービスごとに強固でユニークなパスワードを自動生成・保管する運用に切り替える。使い回しをやめるだけで、被害の連鎖はほぼ断てる。 ### 3. 「怪しいメールの報告先」を決めておく 従業員教育というと堅苦しいが、まずは「おかしいと思ったメールを、気軽に相談・報告できる窓口」を一つ決めるだけでいい。踏んでしまった後に隠されるのが一番怖い。責めない文化と、すぐ止められる連絡経路。この二つがあるだけで、初動が大きく変わる。 ## 「破られる前提」で被害を小さくする どれだけ対策しても、侵入をゼロにはできない。だからこそ、破られたときに被害を最小化する設計も同時に考える。アクセス権限を必要最小限にする、重要データへの操作ログを残す、退職者のアカウントを当日中に停止する——こうした地味な運用が、いざというときの被害範囲を大きく左右する。派手な製品を買う前に、まずは無料でできる「入口を固める」ところから始めてほしい。 --- # Webサイトリニューアルで失敗しないための進め方——「作り直す」前にやるべきこと URL: https://www.pref.co.jp/knowledge/site-renewal-guide Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: サイトリニューアル, Web制作, 情報設計, リダイレクト, SEO デザインを新しくするだけのWebサイトリニューアルは、半年後にまた同じ悩みを生む。目的設定・現状分析・情報設計・安全な移行・公開後の改善という、成果につなげるための進め方を解説する。 ## 「そろそろ古いから作り直す」は、失敗の始まり Webサイトのリニューアル相談で最初に聞くのが「デザインが古くなったので作り直したい」という言葉だ。しかし、見た目を新しくしただけのリニューアルは、半年後にまた同じ悩みを生む。私たちがまず問うのは「そのサイトで、誰に、何をしてほしいのか」だ。問い合わせを増やしたいのか、採用の応募を増やしたいのか、既存顧客の解約を減らしたいのか。目的が曖昧なままデザインの話を始めると、関係者全員の「なんとなくの好み」の集合体ができあがり、成果につながらない。 ## ステップ1：現状分析で「壊してはいけないもの」を見極める リニューアルは、ゼロから作る新規制作とは違う。既存サイトには、すでに評価されているページや、検索から安定して人を集めているコンテンツがある。ここを分析せずに作り直すと、これまで積み上げた検索流入を一夜にして失うことがある。Google Search Console とアクセス解析で「どのページに、どこから、何人来ていて、何をして帰るのか」を洗い出す。流入の多いページ、コンバージョンに貢献しているページは、URLも含めて丁寧に引き継ぐ対象として最初にマークしておく。 ## ステップ2：情報設計はデザインより先に固める 私たちがリニューアルで最も時間をかけるのが情報設計（サイトマップと導線設計）だ。どんなにきれいなデザインでも、探している情報にたどり着けなければ意味がない。まず全ページを棚卸しし、「残す・統合する・捨てる・新設する」を仕分ける。次に、ユーザーがどの入口から入って、どのページを経由して、最終的にどのアクション（問い合わせ・資料請求・応募）に至るかを一本の線として描く。この骨格が決まって初めて、デザインの議論に意味が出てくる。 ## ステップ3：移行とリダイレクトを軽視しない リニューアルの技術的な山場は、URL構造の変更に伴う移行だ。ページのURLが変わるのに古いURLを放置すると、検索エンジンにもユーザーにも「404 Not Found」を返し、これまでの評価がリセットされてしまう。旧URLから新URLへ、1対1で301リダイレクト（恒久的な転送）を設定するのが原則だ。ページを統合して受け皿がなくなる場合は、最も関連性の高いページへ転送する。この地味な作業を怠ったために、公開直後にアクセスが半減する事故を、私たちは何度も見てきた。リダイレクトの対応表は、移行前に必ず作り込む。 ## ステップ4：公開はゴールではなくスタート リニューアルは公開して終わりではない。公開直後は、リダイレクトが正しく機能しているか、フォームの送信が届くか、表示速度が落ちていないかを集中的に監視する。そして数週間後、検索順位やコンバージョン率が「リニューアル前と比べてどう動いたか」を必ず振り返る。数字が下がっているなら、原因を特定して手を打つ。上がっているなら、何が効いたのかを言語化して次に活かす。サイトは公開してから育てるものだ。 ## リニューアルは「目的」から逆算する デザインの刷新は、あくまで手段のひとつにすぎない。目的の再定義、現状分析、情報設計、安全な移行、公開後の改善——この一連の流れを丁寧に踏むかどうかで、リニューアルが投資になるか浪費になるかが決まる。「古くなったから」ではなく「何を達成したいか」から始めてほしい。 --- # オウンドメディアを「続けられる資産」にする——BtoBコンテンツ戦略の設計図 URL: https://www.pref.co.jp/knowledge/owned-media-strategy Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: オウンドメディア, コンテンツマーケティング, SEO, E-E-A-T, BtoB 「ブログを始めたが3ヶ月で止まった」——BtoBオウンドメディアが挫折する原因は、目的と運用体制の欠如にある。KGI/KPI設計、編集計画、E-E-A-T、続く体制、SEOとAI検索の両立までを解説する。 ## 「記事を書けば問い合わせが来る」という幻想 オウンドメディアの相談で多いのが「ブログを始めたが3ヶ月で更新が止まった」というものだ。原因はほぼ共通していて、目的とゴールを決めないまま「とりあえず記事を書き始めた」ことにある。BtoBのオウンドメディアは、検討期間が長く、複数の関係者が意思決定に関わる商材だからこそ効く。すぐに売上につながらないからと途中でやめてしまえば、それまでの投資はすべて無駄になる。私たちはまず、始める前に「なぜやるのか」と「続ける体制があるか」を確認する。 ## KGIとKPIを分けて設計する オウンドメディアの最終目的（KGI）は、多くの場合「問い合わせ・商談の創出」だ。しかし、記事を公開してすぐに商談が生まれるわけではない。だからこそ、途中の進捗を測る中間指標（KPI）が要る。検索流入数、指名検索の伸び、資料ダウンロード数、メルマガ登録数——これらを段階的に追うことで、「まだ商談は出ていないが、確実に前進している」ことを社内に示せる。この中間指標がないと、成果が出る前に「効果がない」と判断されて打ち切られてしまう。 ## 編集計画は「顧客の疑問」から逆算する 何を書くかは、書き手の書きたいことではなく、顧客が検討プロセスで抱く疑問から決める。課題に気づいた段階、比較検討している段階、導入直前で稟議を通そうとしている段階——それぞれで知りたいことは違う。私たちは顧客の購買プロセスに沿ってテーマを並べ、各段階に必要なコンテンツを埋めていく。営業の現場でよく聞かれる質問は、そのまま良質な記事のネタになる。机上で企画するより、営業チームへのヒアリングのほうが当たる。 ## E-E-A-Tは小手先では作れない Googleがコンテンツの品質評価で重視するのが E-E-A-T（経験・専門性・権威性・信頼性）だ。BtoB領域では特に、実際に手を動かした人の一次情報が強い。私たちが記事を書くときは、必ず現場の実体験や具体的な数字、失敗談を盛り込む。誰でも書ける一般論の寄せ集めは、検索エンジンにもユーザーにも見透かされる。著者情報を明示し、専門家が監修し、根拠を示す。この積み重ねがE-E-A-Tであり、一朝一夕には作れないからこそ参入障壁になる。 ## 続く運用体制がなければ始めない オウンドメディアの成否は、才能ではなく継続で決まる。月に何本、誰が企画し、誰が書き、誰が編集し、誰が公開するのか。この役割分担と現実的なペースを決めずに始めると、必ず特定の一人に負担が集中して止まる。私たちは「月2本を1年続ける」ような、無理のない持続可能なペースを推奨する。外部ライターを使うにしても、企画と品質管理は社内に残す。ここを外注に丸投げすると、E-E-A-Tの核となる一次情報が薄まる。 ## SEOとAI検索の両方に備える 近年は、検索結果でAIが回答を生成し、ユーザーがサイトを訪れないまま答えを得るケースが増えている。だからといってSEOが無意味になったわけではない。AIが回答を組み立てる際の情報源として、信頼できる一次情報を持つサイトが引用される。つまり、E-E-A-Tの高い記事を作るという本質は変わらない。むしろ「浅い記事の量産」はますます通用しなくなる。質の高いコンテンツを続けて出すことが、従来の検索でもAI検索でも効く唯一の戦略だ。 --- # Web画像の最適化が、表示速度とSEOを同時に底上げする理由 URL: https://www.pref.co.jp/knowledge/image-optimization-guide Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: 画像最適化, WebP, Core Web Vitals, LCP, 表示速度 サイトが重い原因の大半は巨大な画像にある。WebP/AVIFなど次世代フォーマット、srcsetによるレスポンシブ画像、遅延読み込み、CDN配信まで——表示速度とLCP、そしてSEOを同時に底上げする画像最適化の勘所をまとめた。 ## サイトが重い原因の大半は「画像」だ 表示速度が遅いという相談を受けて中身を調べると、その原因の多くは巨大な画像ファイルにある。デザイナーが用意した高解像度の写真を、そのまま原寸で貼り付けている。スマホの小さな画面に、5000ピクセル・数メガバイトの画像を送りつけている——こうしたケースは驚くほど多い。画像はWebページの総容量の大部分を占めるため、ここを最適化するだけで、体感速度は劇的に変わる。私たちが速度改善で真っ先に手をつけるのが画像だ。 ## 次世代フォーマット WebP・AVIF に切り替える 長年使われてきたJPEGやPNGは、もはや最適な選択肢ではない。WebP は、同じ見た目の品質を保ったままJPEGより2〜3割ファイルサイズを小さくできる。さらに新しい AVIF は、条件によってはもっと圧縮が効く。主要なブラウザはこれらに対応済みだ。古いブラウザ向けには従来形式を用意しつつ、対応ブラウザには軽いフォーマットを配信する仕組み（picture要素での出し分け）を使えば、互換性を保ったまま容量を削減できる。まずは既存画像をWebPに変換するだけでも効果は大きい。 ## レスポンシブ画像で「必要なサイズだけ」届ける PCとスマホでは、必要な画像の大きさが違う。それなのに全端末に同じ大画像を送るのは無駄そのものだ。ここで使うのが srcset と sizes 属性だ。あらかじめ大・中・小の複数サイズを用意しておき、ブラウザが画面サイズや解像度に応じて最適な1枚を選んで読み込む。スマホユーザーには小さい画像を、Retinaディスプレイのユーザーには高精細な画像を届ける。ユーザーの通信量を減らし、表示を速くする、地味だが効果の大きい手法だ。 ## 遅延読み込みで初期表示を軽くする ページを開いた瞬間に、まだ画面に映っていない下のほうの画像まで一気に読み込む必要はない。遅延読み込み（lazy loading）は、ユーザーがスクロールして近づいてきた画像だけを順次読み込む仕組みだ。img要素に loading="lazy" を付けるだけで有効になる。これにより、最初に読み込むデータ量が減り、ページの初期表示が速くなる。ただし、画面の一番上に表示される主役級の画像には lazy を付けてはいけない。そこはむしろ最優先で読み込ませる。 ## CDNで「近くから速く」配信する 画像を軽くしても、遠いサーバーから届けていては速さに限界がある。CDN（コンテンツデリバリーネットワーク）は、世界中に分散したサーバーから、ユーザーに最も近い拠点で画像を配信する仕組みだ。加えて、多くのCDNは配信時に自動でWebP変換やリサイズを行う機能を持つ。元画像を1枚置いておけば、端末やブラウザに応じて最適化した画像を自動生成して届けてくれる。運用の手間を増やさずに最適化を効かせられるのが利点だ。 ## 画像最適化はLCP改善に直結する Googleがページ体験の指標とする Core Web Vitals のうち、LCP（最大コンテンツの描画時間）は、多くのページで「一番大きな画像がいつ表示されるか」で決まる。つまり、主役の画像を軽く・近くから・優先的に届けることが、LCPの改善にそのまま効く。表示速度は検索順位にも、離脱率にも、コンバージョン率にも影響する。画像最適化は、地味に見えて、ユーザー体験とSEOを同時に底上げする費用対効果の高い施策だ。まずは自社サイトの一番重い画像から手をつけてほしい。 --- # フロントエンド高速化の実践：計測なき最適化は、ただの当てずっぽうだ URL: https://www.pref.co.jp/knowledge/frontend-performance-tuning Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: フロントエンド, パフォーマンス, Core Web Vitals, 最適化 体感の遅さと実際のボトルネックは一致しない。JS/CSSの削減、コード分割、レンダリングブロックの解消、フォント最適化まで、計測から改善のループを回すフロントエンド高速化の実践をまとめた。 ## 「なんとなく重い」を、数字に変えるところから 「サイトが重い気がするので速くしてほしい」という相談を受けたとき、私たちがまず断るのは「いきなりコードをいじること」だ。体感の遅さと、実際のボトルネックは一致しないことが多い。画像が重いのか、JavaScriptの実行に時間がかかっているのか、それともサーバーの応答が遅いのか。まずはLighthouseやWebPageTest、Chrome DevToolsのPerformanceパネルで現状を数値化する。計測なき最適化は、当てずっぽうで薬を処方するようなものだ。 ## JavaScriptとCSSを「減らす」という発想 フロントエンド高速化で最も効果が大きいのは、多くの場合「送るコードそのものを減らす」ことだ。使っていないライブラリを削り、巨大なnpmパッケージを軽量な代替に置き換える。とくにアイコンフォントや日付処理ライブラリは、丸ごと読み込んで一部しか使っていないケースが目立つ。バンドルサイズを可視化するツールで内訳を確認し、上位の重量物から手を付けるのが定石だ。 ### コード分割で「今すぐ要らないもの」を後回しにする 初回表示に不要なコードまで一度に読み込ませる必要はない。ルート単位やコンポーネント単位で動的インポートを使い、必要になったタイミングで読み込む。モーダルやグラフ描画、リッチエディタのような重量級の機能は、ユーザーがその画面に来るまで読み込みを遅延させるだけで、初回の体感速度は大きく変わる。 ## レンダリングブロックを解消する ページの描画を止めてしまう要素を取り除くのも重要だ。headに置かれた同期的なscriptや、巨大なCSSは、それらが読み込まれるまで画面を真っ白にする。クリティカルなCSSだけを先に配信し、残りは非同期で読み込む。外部スクリプトにはasyncやdeferを適切に付け、サードパーティのタグが描画をブロックしていないかを疑う。 ## フォントとレイアウトシフトへの目配り Webフォントは表現力を高める一方で、読み込み中に文字が消えたり、後からガクッと表示が入れ替わったりする原因になる。font-displayの指定や必要な文字だけを含めるサブセット化で、この影響を抑えられる。あわせて、画像や広告枠にあらかじめ幅と高さを指定しておくことで、後から要素が押し出される「レイアウトシフト」を防ぐ。ユーザーがボタンを押そうとした瞬間に表示がずれる不快さは、数値以上に信頼を損なう。 ## 一度きりで終わらせず、改善のループを回す 高速化は一度やって終わりではない。機能を追加すれば、また少しずつ重くなっていく。私たちが推奨するのは、計測を仕組みに組み込むことだ。CIにパフォーマンス計測を組み込み、一定のスコアを下回ったら気づける状態を作る。「速い状態を維持する」ことこそが、本当の意味でのパフォーマンスチューニングだと考えている。 --- # INPという新指標：Core Web Vitalsで「操作の速さ」が問われる時代へ URL: https://www.pref.co.jp/knowledge/core-web-vitals-inp Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: Core Web Vitals, INP, パフォーマンス, UX FIDに代わりCore Web Vitalsの応答性指標となったINP。何を測るのか、ロングタスクの分割による対策、そしてラボ計測では見えない実測(RUM)の重要性まで、操作の速さが問われる時代の勘所を解説する。 ## FIDが引退し、INPが主役になった 2024年3月、Core Web Vitalsの応答性を測る指標が、FID（First Input Delay）からINP（Interaction to Next Paint）へと正式に置き換わった。この変更を「用語が変わっただけ」と軽く見ていると足元をすくわれる。FIDは「最初のクリックにどれだけ待たされたか」という、ページ読み込み直後の一瞬だけを見ていた。対してINPは、ページ滞在中に起きたすべての操作を対象に、応答の遅さを評価する。つまり、測る範囲が桁違いに広がったのだ。 ## INPは「反応が返ってくるまで」を測る INPが測るのは、ユーザーがクリックやタップ、キー入力をしてから、その結果として画面が次に描画されるまでの時間だ。ボタンを押したのに一瞬固まる、入力した文字がワンテンポ遅れて表示される——こうした「もっさり感」がそのままスコアに表れる。良好とされるのは200ミリ秒以下。500ミリ秒を超えると「不良」と判定される。見た目が綺麗でも、操作するたびに引っかかるサイトは、この指標で容赦なく減点される。 ## 犯人はたいてい「長いタスク」 INPが悪化する主因は、メインスレッドを長時間占有するJavaScriptの処理、いわゆる「ロングタスク」だ。ユーザーがボタンを押しても、ブラウザが重い処理にかかりきりだと、その処理が終わるまで反応を返せない。私たちがまず調べるのは、クリックをきっかけに走る処理の中に、重い計算や大量のDOM更新がまとめて詰め込まれていないかだ。 ### タスクを分割し、応答を先に返す 対策の基本は、重い処理を小さく分割することだ。一度に全部やろうとせず、処理を区切ってブラウザに制御を返す隙間を作る。まず画面の反応（ボタンの見た目の変化など）を先に描画し、時間のかかる処理は後回しにする。ユーザーは「押した手応え」さえあれば、多少の待ちは許容してくれる。無反応の数百ミリ秒こそが、最もストレスになる。 ## 実測（RUM）でしか見えない現実がある ここで強調したいのは、INPは実際のユーザー環境で計測してこそ意味がある、ということだ。開発者の高性能なマシンでは何の問題もなくても、数年前のスマートフォンを使う実ユーザーの手元では処理が詰まっている。こうした実態は、Chromeユーザーエクスペリエンスレポートや、RUM（Real User Monitoring）ツールで初めて見えてくる。ラボ環境の合格に安心せず、フィールドデータのINPを定点観測することが欠かせない。 ## 「速く見える」から「速く反応する」へ これまでのパフォーマンス改善は、いかに速く表示するかに重心があった。INPの登場は、その先の「操作にどれだけ機敏に応えるか」までが品質として問われる時代になったことを意味する。表示の速さとUXの快適さは別物だ。私たちは、この新しい物差しを、サイトの使い心地を根本から見直す良い機会だと捉えている。 --- # 見積もりは「予言」ではない：不確実性と向き合うシステム開発の値付け URL: https://www.pref.co.jp/knowledge/project-estimation-guide Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: 見積もり, プロジェクト管理, 要件定義, 受託開発 見積もりが当たらないのは腕の問題ではなく、まだ分からないことを無理に数字にしているからだ。不確実性コーン、概算と確定の使い分け、根拠あるバッファ、そして発注側と握るべき前提について解説する。 ## なぜ見積もりは、こんなにも当たらないのか 「この開発、いくらで、いつまでにできますか？」——プロジェクトの初期に必ず飛んでくるこの問いは、実は非常に答えにくい。まだ要件が固まっていない段階で、正確な金額と納期を約束しろと言われているに等しいからだ。見積もりが外れるのは、担当者の腕が悪いからではない。多くの場合、そもそも「まだ分からないこと」を無理に数字にしているからだ。ここを発注側と共有できるかどうかが、プロジェクトの明暗を分ける。 ## 「不確実性コーン」を前提に置く ソフトウェア開発には「不確実性コーン」という有名な考え方がある。プロジェクトの初期ほど見積もりの誤差は大きく、実際の幅は数倍にも及ぶ。要件定義や設計を経て情報が増えるにつれ、この幅は徐々に狭まり、精度が上がっていく。つまり、企画段階の見積もりと、要件確定後の見積もりは、まったく別物だ。私たちは、この段階の違いを明示しないまま一つの数字を独り歩きさせることを、最も危険な行為だと考えている。 ### 概算見積もりと確定見積もりを分ける だからこそ、見積もりは段階を分けて出す。初期段階では、あくまで予算感をつかむための「概算見積もり」であることを明言し、幅を持たせて提示する。要件が固まってから「確定見積もり」を出す。この二段構えを最初に合意しておくだけで、「最初に言った金額と違う」という不毛な衝突の多くは避けられる。 ## バッファは「サボり」ではなく「保険」だ 見積もりにバッファ（余裕）を積むと、発注側から「水増しでは」と疑われることがある。しかしバッファは、想定外のトラブルや仕様の解釈違いに備えるための保険だ。問題は、その中身が見えないことにある。私たちは、リスクの高い箇所（外部連携、未経験の技術、要件が曖昧な機能）を具体的に挙げ、なぜそこに余裕が必要なのかを説明するようにしている。根拠を示したバッファは、値引き交渉の対象ではなく、合意すべき前提になる。 ## 曖昧な要件は、正直に「曖昧」と言う 見積もりを難しくする最大の要因は、要件の曖昧さだ。「いい感じの管理画面」「よくある検索機能」といった言葉は、人によってイメージが何倍も違う。ここを分かったふりで数字にすると、後で必ず食い違う。私たちは、曖昧な部分を曖昧なまま見積もらず、「この機能はこう解釈して見積もった」という前提を書き添える。前提が違えば金額も変わる、という当たり前を可視化しておくのだ。 ## 発注側と「握るべき前提」を言葉にする 結局のところ、良い見積もりとは金額の正確さではなく、前提の共有度で決まる。何が含まれ、何が含まれないのか。どこまでが今回のスコープで、どこからが追加なのか。誰が何を用意する責任を持つのか。これらを発注側と明文化して握ることが、後々のトラブルを防ぐ何よりの防波堤になる。見積書は値段表ではなく、お互いの認識をすり合わせるためのコミュニケーションツールなのだ。 --- # テスト自動化はどこから始めるべきか：ピラミッドで考える費用対効果 URL: https://www.pref.co.jp/knowledge/test-automation-basics Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: テスト自動化, CI/CD, 品質保証, E2E テスト自動化は「全部やろう」とした瞬間に破綻する。テストピラミッドを設計図に、単体・結合・E2Eの使い分けと、何を自動化し何を手動で残すかの線引きをまとめた。 ## 「全部自動化しよう」が最初の失敗 開発が大きくなり、リリースのたびに手動テストで消耗し始めると、多くのチームが「テストを自動化したい」と言い出す。その意気込みは正しい。しかし、いきなり画面操作をすべてE2E（エンドツーエンド）で自動化しようとして、半年後に「メンテナンスが辛くて誰も回さなくなった」テスト群を量産してしまうケースを私たちは何度も見てきた。自動化は「何を自動化するか」より「何を自動化しないか」を決めることから始まる。 ## テストピラミッドという設計図 自動化の全体像を考えるとき、私たちが必ず持ち出すのが「テストピラミッド」だ。土台に数の多い単体テスト、中間に結合テスト、頂点に少数のE2Eテストを積む三層構造で、下にいくほど実行が速く安定し、上にいくほど遅く壊れやすい。ピラミッドが逆三角形（E2Eばかり）になると、テストは重く不安定になり、失敗しても原因がどこか分からなくなる。まずはこの重心を下に置く、という原則を共有しておきたい。 ### 単体テスト：土台を厚くする 関数やクラス単位でロジックを検証する単体テストは、ミリ秒単位で動き、壊れても原因が一目瞭然だ。金額計算、日付処理、バリデーション、分岐の多い業務ロジックなど「間違えると事故になる中身」をここで固める。自動化の投資はまずここに集中させるのが、最も費用対効果が高い。 ### 結合テスト：つなぎ目を守る APIとデータベース、外部サービスとの連携など、モジュール同士の「つなぎ目」を検証するのが結合テストだ。単体では気づけない、実際に配線したときのズレを拾う。E2Eほど重くないので、主要なAPIエンドポイントの正常系・異常系はこの層で押さえておきたい。 ### E2E：本当に大事な数本だけ E2Eは実際のブラウザ操作を再現するため価値が高い一方、遅く、UIの小さな変更で壊れる。だからこそ「これが動かなければ事業が止まる」という導線——ログイン、購入、問い合わせ送信など——に絞る。10本以内で始め、増やすのはよほどの理由があるときだけ、と決めておくと破綻しにくい。 ## 手動で残すべきものを見極める すべてを自動化する必要はない。見た目の微妙な崩れ、体験の心地よさ、めったに変わらない管理画面の隅——こうした領域は、人間が目で見たほうが速く確実だ。「変更頻度が高く、壊れると影響が大きく、判断が機械的」なものほど自動化に向く。逆に「めったに変わらず、人間の感性が要る」ものは手動で残す。この線引きを最初にチームで言語化しておくことが、無駄な自動化を防ぐ。 ## CIに組み込んで初めて資産になる どれだけ良いテストを書いても、手元でたまに実行するだけでは意味がない。プルリクエストのたびに自動で走り、失敗すればマージを止める——CI（継続的インテグレーション）に組み込んで初めて、テストは「壊れたことを教えてくれる仕組み」になる。単体・結合は毎回、重いE2Eは深夜バッチや本番リリース前のみ、と実行タイミングを分けるのが現実的だ。私たちは、小さな単体テストをCIに乗せる最初の一歩から着実に積み上げることをおすすめしている。 --- # 中小企業の情報漏洩対策：狙われるのは「人」と「設定」だ URL: https://www.pref.co.jp/knowledge/information-leak-prevention Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: 情報漏洩対策, 情報セキュリティ, アクセス管理, ISMS 情報漏洩の主因は高度な攻撃ではなく、人的ミスと設定不備だ。アクセス権の最小化、退職者対応、SaaSの共有設定、そして教育まで、中小企業が今日から着手できる対策を整理した。 ## 漏洩の主因は、ハッカーより身近にある 情報漏洩と聞くと、高度なサイバー攻撃を思い浮かべる人が多い。しかし中小企業で実際に起きている漏洩の大半は、もっと地味な原因だ。メールの誤送信、退職者のアカウントが放置されていた、クラウドサービスの共有設定が「全員に公開」のままだった——つまり人的ミスと設定不備である。派手な攻撃を心配する前に、私たちはまずこの足元の穴を塞ぐことを勧めている。高価なツールを買う必要はなく、運用の見直しだけで防げるものがほとんどだ。 ## アクセス権は「最小限」を原則にする 漏洩の被害を最も大きくするのは「必要のない人が、必要のない情報にアクセスできる状態」だ。全社員が全フォルダを見られる設定は、一見便利だが、一人のミスや一台の端末感染が全社の情報流出につながる。原則は「その業務に必要な人だけが、必要な範囲だけ触れる」こと。部署異動やプロジェクト終了のたびに権限を見直す運用をセットにして、初めて機能する。 ## 退職者対応を「当日中」の手順にする 意外に見落とされがちなのが退職者のアカウントだ。退職後もメールやクラウドにログインできる状態が数週間続いていた、という話は珍しくない。私たちは、退職日にアカウント停止・共有解除・端末回収をワンセットで行うチェックリストを用意することを勧めている。誰が何のサービスにアクセスできるかを日頃から一覧化しておかないと、退職時に「どこを止めればいいか」が分からなくなる。 ## SaaSの共有設定を定期的に棚卸しする クラウドストレージやチャットツールは便利だが、「リンクを知っている全員が閲覧可能」といった共有設定が積み重なると、意図せず社外に見えている資料が生まれる。四半期に一度でいいので、共有範囲が広すぎるファイルやフォルダを棚卸しする時間を取りたい。特に、外部と共有したまま案件が終わったリンクは、放置せず切ることを習慣化したい。 ## 教育と運用ルールが最後の防波堤になる 技術的な対策をどれだけ固めても、最後にファイルを送るのは人間だ。だからこそ、パスワードの使い回しをしない、公共Wi-Fiで機密情報を扱わない、不審なメールのリンクを開かない——といった基本を、年に一度でも全員で確認する場が効く。ISMS（情報セキュリティマネジメントの仕組み）の考え方も、突き詰めれば「ルールを決め、守り、見直し続ける」ことに尽きる。私たちは、身の丈に合った小さなルールから始め、運用として回し続けることを重視している。完璧な仕組みより、続く仕組みのほうが会社を守る。 --- # SaaSを導入する前に：担当者が確認すべきセキュリティチェックリスト URL: https://www.pref.co.jp/knowledge/saas-security-checklist Published: 2026-07-01 Updated: 2026-07-01 Author: 株式会社プリファード Tags: SaaS, セキュリティ, SSO, シャドーIT SaaS導入は「社外に情報を預ける」決断でもある。アカウント権限、SSO・MFA、データの保管と暗号化、監査ログ、退会時の扱い、そしてシャドーITまで、担当者が契約前に確認したい観点を一覧にした。 ## 便利さの裏で、情報は社外に出ていく 業務ツールをSaaS（クラウドサービス）で導入するのは、もはや当たり前になった。しかし契約ボタンを押した瞬間、自社の顧客データや業務情報が「社外のサーバー」に置かれることになる、という事実は意外と意識されない。私たちは新しいSaaSを検討するとき、機能や価格と同じ熱量で「セキュリティ面をどう確認するか」を一緒に見るようにしている。難しい監査は要らない。担当者レベルで確認できるポイントを押さえるだけで、多くのリスクは避けられる。 ## アカウントと権限：誰が何をできるか まず確認したいのは、利用者ごとに権限を分けられるか（管理者・一般など）だ。全員が管理者権限、という設計のツールは避けたい。加えて、退会・異動時にアカウントを個別に無効化できるか、招待や削除の操作ログが残るかも見ておく。人の出入りに追従できない権限管理は、そのまま漏洩リスクになる。 ## SSOとMFA：入口を固められるか アカウントを守る要は入口の認証だ。SSO（シングルサインオン）に対応していれば、全社の認証を一元管理でき、退職時に大元のアカウントを止めるだけで芋づる式に遮断できる。さらにMFA（多要素認証）が使えれば、パスワードが漏れても不正ログインを防ぎやすい。この二つに対応しているかは、業務の中核に使うSaaSを選ぶ際の重要な判断材料になる。 ## データの保管場所・暗号化・監査ログ 次に、データがどこの国のサーバーに保管され、通信と保存が暗号化されているかを確認したい。国内保管が要件になる業種もあるので、契約前に運営元へ問い合わせておくと安心だ。あわせて、いつ誰がどの操作をしたかを追える監査ログの有無も確認したい。何かあったときに「調べられる」状態かどうかで、事故後の対応の質が大きく変わる。 ## 退会時のデータの扱いを最初に決めておく 導入時に見落とされがちなのが「やめるとき」の話だ。解約したらデータはどう返却・削除されるのか、エクスポート手段はあるのか。ここを確認しないまま使い始めると、乗り換え時にデータを人質に取られたような状態になりかねない。導入は出口から考える、というのが私たちの基本姿勢だ。 ## シャドーITを放置しない 最後に、組織全体で気をつけたいのがシャドーIT——情報システム部門の把握しないまま、現場が勝手に契約・利用しているSaaSの存在だ。無料プランで顧客情報を扱っていた、といった事態は珍しくない。私たちは、利用中のSaaSを一覧化し、新規導入時には簡単なチェックを通す運用を勧めている。禁止で締め付けるのではなく、安全な選択肢を用意して申請しやすくすることが、結果的にシャドーITを減らす近道だ。 --- # LLMOとは何か。SEOの次に来る「AI検索最適化」を今から始める理由 URL: https://www.pref.co.jp/knowledge/what-is-llmo Published: 2026-05-27 Updated: 2026-05-27 Author: 株式会社プリファード Tags: LLMO, GEO, AI検索, SEO, ChatGPT, Perplexity ChatGPTやPerplexityで検索しても自社が出てこない。そんな課題に対応するLLMO（AI検索最適化）の基本概念と、今すぐ実践できる5つの施策を解説する。 ## 「ChatGPTに聞いたら競合他社が出てきた」 最近、こんな声を聞くようになった。「自社のサービスについてChatGPTやPerplexityで検索してみたら、競合他社ばかり紹介されて自社が一切出てこなかった」。これは偶然ではない。AI検索エンジンには、参照する情報源の選び方に明確なロジックがある。そのロジックを理解して対策することを、LLMO（Large Language Model Optimization）と呼ぶ。 ## SEOとLLMOは何が違うのか SEOはGoogleのクローラーに「このページは○○のキーワードで上位表示されるべきだ」と伝えるための最適化だ。一方LLMOは、ChatGPT・Claude・Perplexity・Google AI Overviewといった大規模言語モデルに「この企業・サービスは○○の文脈で信頼できる情報源だ」と認識させるための最適化だ。 最大の違いは、SEOが「クリックしてもらうこと」を目標にするのに対し、LLMOは「AIに引用・言及してもらうこと」を目標にする点だ。AI検索では、ユーザーはリンクをクリックせずに回答を得る。つまり、AIが回答を生成する際に自社の情報を参照してもらえなければ、存在しないも同然になる。 ## LLMが情報を参照する仕組み LLMが特定の企業・サービスを回答に含める際、主に以下の3つの情報源を参照している。 - 学習データ（プレトレーニング）：LLMが事前学習した膨大なテキストデータ。Webページ、Wikipedia、書籍、論文などが含まれる。 - RAG（検索拡張生成）：回答生成時にリアルタイムでWebを検索し、最新情報を取り込む仕組み。PerplexityやGoogle AI Overviewはこれを活用している。 - 構造化データ・メタデータ：Schema.orgの構造化データ、OGPタグ、サイトマップなど、機械が読みやすい形式の情報。 LLMOの施策は、これらの参照経路を意識して設計する。 ## 今すぐできるLLMO施策5選 ### 1. 「○○とは」コンテンツを充実させる AI検索は「○○とは何か」という定義・説明系のクエリに強く反応する。自社サービスや専門領域について、簡潔かつ権威ある説明文を用意する。Wikipedia的な記述スタイルが参照されやすい。 ### 2. FAQをSchema.orgで構造化する FAQPage スキーマを実装することで、AIが質問と回答のペアを直接取得しやすくなる。「よくある質問」ページを作るだけでなく、各サービスページにもFAQセクションを設けてスキーマを付与する。 ### 3. 引用されやすい「一次情報」を発信する 独自の調査データ、事例、ノウハウ記事はAIに引用されやすい。「他では読めない情報」を継続的に発信することで、LLMの学習データやRAGの参照対象になる確率が上がる。 ### 4. 権威あるサイトからの言及を増やす SEOにおけるバックリンクと同様、信頼性の高いサイト（業界メディア、パートナー企業のサイト等）から自社が言及されることは、LLMが自社を「信頼できる情報源」と判断する材料になる。microCMSの公式パートナーページへの掲載はその典型例だ。 ### 5. 企業情報をOrganizationスキーマで明示する Schema.orgのOrganizationタイプで、会社名・所在地・事業内容・専門領域（knowsAbout）・パートナーシップ（sameAs）を構造化データとして出力する。AIは構造化データを優先的に参照するため、自社の属性をAIに正確に伝えられる。 ## LLMOはSEOを置き換えるのか 結論から言えば、当面は「SEO + LLMO」の両輪で取り組む必要がある。Googleの検索シェアはまだ圧倒的だし、AI検索がすべての検索行動を置き換えるには時間がかかる。ただし、BtoBの意思決定者がAI検索を使うケースは急速に増えている。「競合他社はAI検索でも出てくるのに自社は出てこない」という状況が続けば、認知・信頼・問い合わせのすべてで差がつく。今から始めることで、先行者優位を取れる領域だ。 --- # コンテンツの「品質チェック」を手作業でやり続けるのは限界だ URL: https://www.pref.co.jp/knowledge/kirico-content-quality Published: 2026-05-27 Updated: 2026-05-27 Author: 株式会社プリファード Tags: Kirico, microCMS, コンテンツ品質, 景表法, 薬機法, SEO自動化 コンテンツの品質チェックを人手でやり続けることの限界と、AIによる自動化が解決できる3つの問題。microCMS連携のAIチェックエンジン「Kirico」の活用事例を交えて解説。 ## 「公開前に誰かが確認する」の限界 Webサイトのコンテンツ運用において、「公開前に担当者がチェックする」というフローは今も多くの企業で続いている。しかし、コンテンツの量が増え、更新頻度が上がり、多言語対応が求められるようになった現在、人手によるチェックはボトルネックになりつつある。見落とし、表記ゆれ、薬機法・景表法への抵触リスク——これらを人間が毎回完璧に防ぐことは、現実的に難しい。 ## 品質チェックで起きがちな3つの問題 ### 1. チェックの「属人化」 「このチェックはAさんしかできない」という状況は、Aさんが休んだり退職したりした瞬間に崩壊する。ルールが文書化されておらず、経験と勘に頼ったチェックは、再現性がなく、引き継ぎも困難だ。 ### 2. 法規制対応の見落とし 薬機法（旧薬事法）や景品表示法（景表法）への抵触は、担当者が意図していなくても起きる。「最大〇〇%効果」「業界No.1」といった表現は、根拠がなければ景表法違反になりうる。専門知識がない担当者が毎回チェックするのは、現実的に無理がある。 ### 3. SEO・OGPの設定漏れ 記事を公開したのにメタディスクリプションが空、OGP画像が設定されていないためSNSでシェアされても画像が表示されない——こういったケアレスミスは、チェックリストがあっても人間が確認する限り一定の確率で発生する。 ## AIによる自動品質チェックが解決すること これらの問題に対して、AIを活用したコンテンツ品質チェックの自動化が有効だ。microCMSのWebhookと連携したAIチェックエンジンを使えば、コンテンツが公開・更新されるたびに自動的に以下の項目を検査できる。 - 薬機法・景表法に抵触する可能性のある表現の検出 - SEOメタデータ（title・description・OGP）の設定確認 - 表記ゆれ・誤字脱字の検出 - ブランドガイドラインへの準拠チェック - 多言語コンテンツの整合性確認 問題が検出された場合は、Slackや担当者メールに通知が届く。人間は「問題があるコンテンツだけ」を確認すればよくなるため、チェック工数を大幅に削減できる。 ## microCMSとの連携で実現するコンテンツ品質の自動化 当社が開発したKiricoは、microCMSのWebhookと連携し、コンテンツの公開・更新をトリガーにAIによる品質チェックを自動実行するサービスだ。チェック結果はmicroCMSの管理画面内に表示されるため、担当者は普段の作業フローを変えることなく品質管理を強化できる。 コンテンツ運用の品質を上げたい、チェック工数を削減したい、法規制リスクを下げたい——そんな課題を持つ企業にとって、AIによる自動化は「いつかやること」ではなく「今すぐやること」になっている。 --- # 脱WordPress研修が「実質10万円」で受けられる理由——人材開発支援助成金の活用法 URL: https://www.pref.co.jp/knowledge/jamstack-training-subsidy Published: 2026-05-27 Updated: 2026-05-27 Author: 株式会社プリファード Tags: JAMStack, microCMS, 人材開発支援助成金, 脱WordPress, Next.js, 研修 最大75%の助成金を活用すれば、40万円のJAMStack研修が実質10万円で受けられる。人材開発支援助成金の仕組みと、脱WordPress研修への活用方法を解説する。 ## 「研修費用が高くて踏み出せない」という壁 Web制作会社やIT部門を持つ企業から「JAMStackやmicroCMSを学ばせたいが、研修費用が高くて社内で承認が取れない」という声をよく聞く。確かに、専門的な技術研修は1名あたり数十万円かかることも珍しくない。しかし、厚生労働省の「人材開発支援助成金」を活用すれば、研修費用の最大75%を国が負担してくれる制度がある。つまり、40万円の研修が実質10万円で受けられる計算になる。 ## 人材開発支援助成金とは 人材開発支援助成金は、厚生労働省が提供する助成金制度で、事業主が従業員に対して職業訓練（研修）を実施した場合に、訓練費用や訓練期間中の賃金の一部を助成するものだ。中小企業の場合、経費助成率は最大75%（大企業は60%）となっており、対象となる訓練の種類も幅広い。 ### 主な要件 - 雇用保険適用事業主であること - OFF-JT（職場外訓練）であること - 訓練開始の1ヶ月前までに労働局へ計画届を提出すること - 訓練修了後に支給申請を行うこと 事前の計画書提出が必要なため、研修開始の1ヶ月前には手続きを始める必要がある。 ## なぜ「脱WordPress研修」が助成金対象になるのか 人材開発支援助成金の対象となる訓練は、「業務に直接関連する専門的・技術的知識・技能の習得」であることが条件だ。JAMStack・microCMS・AI駆動開発の研修は、Web制作・システム開発に従事する従業員の業務スキル向上に直結するため、対象訓練として認定されやすい。 当社が提供するJAMStack研修（脱WordPress）は、助成金申請に必要な訓練計画書の作成サポートも含めてご支援している。「助成金の手続きが面倒で」という理由で研修を諦めることがないよう、申請フローも含めてワンストップで対応する。 ## 研修で学ぶ内容 当社のJAMStack研修では、以下の内容をハンズオン形式で学ぶ。 - microCMSの基本操作と設計——APIスキーマ設計、コンテンツモデリング、Webhook設定 - Next.js × microCMSの実装——SSG/ISRを使った高速サイト構築、動的ルーティング - AI駆動開発（Cursor/Claude Code）——AIを使った高速コーディング、プロンプト設計 - Vercelへのデプロイと運用——CI/CDパイプライン、プレビュー環境の活用 - WordPressからの移行戦略——既存サイトのヘッドレスCMS化、データ移行の考え方 ## 「承認が取れない」を解決する数字 研修費用の社内承認を取る際に使える数字を整理しておく。 - 研修費用：1名あたり40万円（税込） - 助成金（中小企業・経費助成75%の場合）：最大30万円 - 実質負担額：約10万円 - 研修後に見込むもの：WordPress 案件で繰り返し発生している作業（テーマ改修・プラグイン調整・表示崩れの修正）を減らす 社内提案では、削減率を先に置くより「いま何にどれだけ時間を使っているか」を数えてから出すほうが通りやすい。研修前に対象作業の件数と所要時間を記録しておくと、効果を後から検証できる。 ## まずは無料相談から 助成金の適用可否は企業の状況によって異なる。「うちは対象になるのか」「手続きはどうすればいいか」という疑問は、まず無料相談でご確認いただきたい。研修内容のカスタマイズ（自社のプロジェクトに合わせた事例を使ったハンズオンなど）にも対応している。 --- # microCMSをAI時代のコンテンツ基盤にするための3つのアーキテクチャ URL: https://www.pref.co.jp/knowledge/microcms-ai-content-ops Published: 2026-05-27 Updated: 2026-05-27 Author: 株式会社プリファード Tags: microCMS, AI, RAG, Webhook, ヘッドレスCMS, コンテンツ運用 microCMSをAI時代のコンテンツ基盤として活用するための3つのアーキテクチャ。AI生成・品質チェック自動化・RAG検索の具体的な設計パターンを解説する。 ## 「CMSにコンテンツを入れるだけ」の時代は終わった ヘッドレスCMSの普及により、コンテンツとフロントエンドの分離が進んだ。しかし多くの企業では、microCMSを「記事を入稿するツール」としてしか使えていない。AIと組み合わせることで、microCMSはコンテンツの生成・品質管理・配信・分析までをカバーする「コンテンツ運用基盤」に進化できる。本記事では、その具体的なアーキテクチャを3つ紹介する。 ## アーキテクチャ1：AI生成 × microCMS入稿の自動化 テーマやキーワードを入力すると、AIが記事の下書きを生成し、microCMSの下書きとして自動保存するパイプラインだ。担当者はAIが生成した下書きを確認・編集して公開するだけでよい。 このアーキテクチャの要点は「AIが書いたものをそのまま公開しない」という設計にある。AIの生成物は必ず人間のレビューを経る。これにより、品質を担保しながら制作工数を大幅に削減できる。SEOメタデータ（title・description）やOGP画像の生成も同時に行うことで、公開作業のほぼすべてを自動化できる。 ## アーキテクチャ2：Webhook × AIによる品質チェック自動化 microCMSのWebhook機能を使い、コンテンツの公開・更新をトリガーにAIによる品質チェックを自動実行する。チェック項目は企業ごとにカスタマイズ可能で、薬機法・景表法チェック、表記ゆれ検出、SEO品質スコアリングなどに対応できる。 問題が検出された場合はSlackや担当者メールに通知が届き、microCMSの管理画面でチェック結果を確認できる。これにより、「公開してから問題に気づく」というリスクを大幅に低減できる。 ## アーキテクチャ3：microCMS × RAGによる社内AI検索 microCMSに蓄積されたコンテンツ（製品情報、FAQ、マニュアル、事例など）をベクトルデータベースに同期し、社内向けのRAGチャットボットを構築するアーキテクチャだ。 従業員が「○○製品の仕様は？」「△△案件の対応事例は？」と質問すると、AIがmicroCMSのコンテンツを参照して回答する。コンテンツがmicroCMSで更新されると、ベクトルDBも自動同期されるため、常に最新情報に基づいた回答が得られる。 このアーキテクチャは、コールセンターの問い合わせ対応、営業担当者の情報検索、新入社員のオンボーディングなど、幅広い用途に応用できる。 ## 3つのアーキテクチャに共通する設計思想 いずれのアーキテクチャも、microCMSを「コンテンツのハブ」として位置づけている。AIはmicroCMSに対してコンテンツを入力し、microCMSからコンテンツを取得する。この設計により、AIの能力を最大限に活用しながら、コンテンツの管理・権限・バージョン管理はmicroCMSが担うという役割分担が明確になる。 microCMSのAPIファーストな設計は、こうしたAI連携に非常に適している。Webhookによるイベント駆動、REST/GraphQL APIによるコンテンツ取得、柔軟なコンテンツモデリング——これらの機能が、AIとの連携を容易にしている。 ## どこから始めるか 3つのアーキテクチャのうち、最も導入ハードルが低いのはアーキテクチャ2（Webhook × AI品質チェック）だ。既存のmicroCMS環境にWebhookを追加するだけで始められ、既存のコンテンツ運用フローを大きく変える必要がない。まずここから試してみることをおすすめする。 --- # WordPressからJAMStackへ移行した企業が「やってよかった」と言う理由 URL: https://www.pref.co.jp/knowledge/wordpress-to-jamstack-migration Published: 2026-05-27 Updated: 2026-05-27 Author: 株式会社プリファード Tags: WordPress, JAMStack, microCMS, Next.js, ヘッドレスCMS, サイトリニューアル WordPressからJAMStack（microCMS × Next.js）に移行した企業が「やってよかった」と言う4つの理由と、移行の現実的な課題を正直に解説する。 ## 「WordPressは使いやすい」という神話 WordPressは世界中のWebサイトの40%以上で使われている。「使いやすい」「プラグインが豊富」「制作会社が多い」——確かにその通りだ。しかし、企業のWebサイトを長年運用してきた担当者に話を聞くと、「使いやすい」の裏側にある問題が次々と出てくる。セキュリティの脆弱性、プラグインの競合、表示速度の遅さ、更新のたびに何かが壊れる恐怖——。これらはWordPressを使い続ける限り、永遠についてまわる問題だ。 ## JAMStackへの移行で何が変わるか JAMStack（JavaScript・API・Markup）は、フロントエンドとバックエンドを完全に分離したアーキテクチャだ。コンテンツ管理にはmicroCMSのようなヘッドレスCMSを使い、フロントエンドはNext.jsなどのフレームワークで構築する。ビルド時に静的ファイルを生成してCDNで配信するため、WordPressのような動的なサーバーサイド処理が不要になる。 移行した企業が口を揃えて言う「やってよかった」の理由を整理すると、以下の4点に集約される。 ### 1. 表示速度が劇的に改善する 静的ファイルをCDNから配信するため、サーバーの処理時間がなくなる。WordPressで3〜5秒かかっていたページの読み込みが、0.5秒以下になるケースも珍しくない。Core Web Vitalsのスコアが改善し、SEOにも好影響が出る。 ### 2. セキュリティリスクが大幅に下がる WordPressの脆弱性の多くは、PHPサーバーやデータベースへの攻撃、プラグインのセキュリティホールに起因する。JAMStackは動的なサーバーサイド処理がないため、これらの攻撃対象が存在しない。「WordPressのアップデートを怠ったらハッキングされた」という悪夢から解放される。 ### 3. 運用コストが下がる WordPressの運用には、サーバー費用、セキュリティ対策費用、プラグインのライセンス費用、定期的なメンテナンス費用がかかる。JAMStackはVercelやNetlifyのような無料〜低コストのホスティングサービスを使えるため、インフラコストを大幅に削減できる。 ### 4. 開発・更新のサイクルが速くなる コンテンツとコードが分離されているため、デザインの変更やコンテンツの更新が互いに影響しない。Gitベースのデプロイにより、変更履歴の管理も容易になる。AI を使った開発（Cursor / Claude Code）とも相性がよく、定型的な実装にかかる時間を減らしやすい。ただし削減幅は案件の性質によって大きく変わるので、事前に一律の数字を置かないほうがよい。 ## 移行の現実：何が大変か 良いことばかりではない。移行にあたって大変なことも正直に書いておく。 - 初期の学習コスト：WordPressのテーマ開発とは異なるスキルセットが必要になる。Next.jsやReactの知識が求められる。 - 既存コンテンツの移行：WordPressの記事データをmicroCMSに移行する作業が必要。記事数が多いほど工数がかかる。 - 一部機能の再実装：WordPressのプラグインで実現していた機能（フォーム、検索など）を別の方法で実装する必要がある。 これらの課題はあるが、移行後の運用コスト削減と品質向上を考えると、多くの企業にとって移行は「やって正解」の判断になっている。 ## 移行を検討するタイミング 以下のいずれかに当てはまるなら、移行を真剣に検討する価値がある。 - WordPressのアップデートやセキュリティ対応に疲弊している - サイトの表示速度が遅く、SEOや離脱率に影響が出ている - サイトリニューアルを検討している - コンテンツ運用をAIで効率化したい - 制作会社の内製化を進めたい まずは現状のWordPressサイトの課題を棚卸しし、JAMStack移行のROIを試算することから始めてみてほしい。 --- # BtoBマーケティングオートメーション導入の失敗パターンと回避策 URL: https://www.pref.co.jp/knowledge/b2b-marketing-automation Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: MA, マーケティングオートメーション, BtoB, リードナーチャリング MAツールを入れたのに「ただの一斉メール配信ツール」になっている。そんなBtoB企業が陥りがちな3つの失敗パターンと、導入前に整えるべきシナリオ設計の基本を解説する。 ## 「とりあえずMAを入れよう」で始まる悲劇 BtoBの営業課題をヒアリングしていると、「リードが足りないからMA（マーケティングオートメーション）を入れたい」という声によく出会う。しかし、MAはリードを「増やす」魔法の箱ではない。今あるリードを「育てる」ための仕組みだ。ここを勘違いしたまま高額なツールを契約し、結局月に1回の一斉メルマガ配信にしか使えていない企業は驚くほど多い。 MA導入が失敗するパターンは、だいたい決まっている。ツール選びの前に、自社の足元を見直すだけで防げる失敗ばかりだ。 ## 失敗パターン1：コンテンツがないのに箱だけ用意する MAの基本は「顧客の興味関心に合わせて、適切な情報を届ける」ことだ。しかし、届けるべき情報（ホワイトペーパー、事例記事、ウェビナー動画など）が手元にないままツールを導入してしまうケースが後を絶たない。シナリオを組もうにも、送るコンテンツがないのだから当然止まる。MAを入れる前に、まずは自社のノウハウを棚卸しして、最低でも3〜5本のキラーコンテンツを作っておく必要がある。 ## 失敗パターン2：営業部門との連携ルールが未定義 マーケティング部門がMAでスコアを計算し、「この顧客はホットだ！」と営業にパスしても、営業が動かない。これもよくある光景だ。理由は単純で、「スコアが高い＝今すぐ買いたい」とは限らないからだ。マーケと営業の間で「どういう状態の顧客なら営業がアプローチするのか（MQLの定義）」をすり合わせておかないと、MAはただの自己満足ツールで終わってしまう。 ## 失敗パターン3：最初から複雑なシナリオを組みすぎる 「資料Aをダウンロードして、3日後にメールBを開封し、価格ページを2回見たら…」といった複雑な分岐シナリオを最初から作ろうとするのも危険だ。運用が回らなくなるし、効果検証も難しくなる。最初は「資料請求した人に、3日後に事例記事を送る」くらいのシンプルな1本道から始める。手応えを掴んでから少しずつ分岐を足していくのが、結局は一番の近道だ。 ## ツールは後回し。まずは「誰に何を伝えるか」から MAツールは優秀だが、戦略までは考えてくれない。導入を検討しているなら、まずはホワイトボードに「自社の顧客が、認知から購買までにどんな情報を必要としているか」を書き出してみてほしい。それが描けないうちは、まだツールを入れるタイミングではない。 --- # Webアクセシビリティ対応は「思いやり」ではなく「品質」の問題だ URL: https://www.pref.co.jp/knowledge/web-accessibility-basics Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: アクセシビリティ, UI/UX, Web制作, HTML 2024年の障害者差別解消法改正を機に注目されるWebアクセシビリティ。特別な対応ではなく、当たり前の品質基準として取り組むための第一歩をまとめた。 ## 「うちのターゲットに障害者はいないから」という誤解 Webアクセシビリティの話をすると、いまだに「うちは健常者向けのサービスだから関係ない」という反応が返ってくることがある。これは大きな誤解だ。アクセシビリティは、視覚や聴覚に障害がある人だけのものではない。老眼で小さな文字が見えづらくなった高齢者、骨折してマウスが使えない人、屋外の強い日差しでスマホの画面が見えない人——つまり、あらゆる状況に置かれた「すべての人」のためのものだ。 ## アクセシビリティは「特別な対応」ではない 多くの人が、アクセシビリティ対応を「追加のオプション作業」だと捉えている。しかし本来、HTMLの仕様通りに正しくマークアップし、適切なコントラストを保ち、キーボードだけでも操作できるように作るのは、Webサイトとしての「当たり前の品質」だ。特別なことをするのではなく、基本に忠実に作る。それだけで、アクセシビリティの8割は担保できる。 ## 明日からできる3つの基本アクション ### 1. 画像に適切な代替テキスト（alt）を入れる 最も簡単で、最も効果的な対応だ。画像が表示されない環境や、音声読み上げソフトを使っているユーザーにとって、alt属性は命綱になる。「装飾目的の画像は空（alt=""）にする」「意味のある画像は内容を簡潔に説明する」。このルールを運用担当者全員で徹底するだけでいい。 ### 2. コントラスト比を見直す おしゃれさを優先するあまり、薄いグレーの背景に少し濃いグレーの文字を重ねていないだろうか。これは視認性が極めて悪い。WCAG（Web Content Accessibility Guidelines）が定めるコントラスト比の基準（通常テキストで4.5:1）を満たしているか、チェックツールを使って確認してみてほしい。 ### 3. マウスを使わずに操作してみる 一度、マウスやトラックパッドから手を離し、キーボードのTabキーとEnterキーだけで自社のサイトを操作してみてほしい。メニューは開けるか。フォームは送信できるか。現在どこにフォーカスが当たっているか視覚的にわかるか。このテストをやるだけで、自社サイトの課題が痛いほど見えてくるはずだ。 ## 法対応を言い訳に、品質を底上げする 2024年4月の障害者差別解消法改正により、事業者による合理的配慮の提供が義務化された。これを「面倒な法対応」と捉えるか、「サイトの品質を底上げするチャンス」と捉えるかで、数年後のブランド価値は大きく変わる。まずは自社サイトの現状を知ることから始めてみてほしい。 --- # アジャイル開発の理想と現実：なぜ「ただの計画なき開発」に陥るのか URL: https://www.pref.co.jp/knowledge/agile-development-reality Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: アジャイル, スクラム, プロジェクトマネジメント, システム開発 「アジャイルでやります」と言いながら、実態は仕様変更の言い訳に使われているだけのプロジェクトは多い。受託開発におけるアジャイルの現実と、破綻を防ぐための防波堤について。 ## 「アジャイルだから仕様は後で決めましょう」の罠 システム開発の現場で「今回はアジャイルで進めたい」という要望をもらうことが増えた。しかし、その言葉の裏にある期待を探っていくと、「要件定義をサボりたい」「開発途中でも無料で仕様変更し放題にしたい」という本音が透けて見えることが少なくない。断言するが、それはアジャイルではない。ただの「計画なき開発」だ。 ## 受託開発とアジャイルの相性の悪さ そもそも、予算と納期がガチガチに決まっている日本の一般的な受託開発契約と、アジャイル（特にスクラム）は相性が悪い。アジャイルは「スコープ（作るもの）を柔軟に変えながら、価値を最大化する」手法だが、発注側は「決まった予算内で、最初に思い描いたものを全部作ってほしい」と考えている。この前提のズレを放置したままスプリントを回し始めると、必ずどこかで破綻する。 ## 破綻を防ぐための3つの防波堤 ### 1. 「やらないこと」を明確にする アジャイルは仕様変更を受け入れるが、それは「無限に機能を追加できる」という意味ではない。新しい機能を入れるなら、代わりに何かを落とす（スコープから外す）必要がある。この「トレードオフの原則」を、プロジェクトのキックオフ段階で発注側と強く合意しておかなければならない。 ### 2. プロダクトオーナー（PO）の覚悟を問う アジャイルが機能するかどうかは、発注側のプロダクトオーナーの力量にかかっている。バックログの優先順位を即座に決断し、時には現場の要望を切り捨てる権限と覚悟があるか。POが「持ち帰って検討します」を連発するプロジェクトは、アジャイルのスピード感についていけず、確実に停滞する。 ### 3. 最初の数スプリントは「捨てる」覚悟で チームがアジャイルのやり方に慣れ、ベロシティ（開発速度）が安定するまでには、最低でも3〜4スプリントはかかる。最初のうちは見積もりも外れるし、予定通りに進まない。これを「失敗」と捉えず、「チームの現在地を測るための投資」として許容できるかどうかが問われる。 ## 手法ではなく、対話の質を変える アジャイルは銀の弾丸ではない。むしろ、関係者間のコミュニケーションコストはウォーターフォールよりも跳ね上がる。手法の導入にこだわる前に、「発注側と開発側が、ひとつのチームとして対話できる関係性を作れるか」を自問してみてほしい。それができないなら、従来通りのウォーターフォールで進めたほうが、お互いにとって幸せな結果になる。 --- # GA4への移行から1年。結局、私たちは何を見ればいいのか URL: https://www.pref.co.jp/knowledge/google-analytics-4-migration Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: GA4, Google Analytics, アクセス解析, Webマーケティング UAからGA4への強制移行から時間が経ったが、いまだに「見方がわからない」という声は多い。複雑なGA4の画面で、実務担当者が最低限チェックすべき3つの指標を整理した。 ## 「GA4、見づらくて開かなくなった」という現実 ユニバーサルアナリティクス（UA）からGA4への移行が完了してしばらく経つが、現場の戸惑いは消えていない。「直帰率が消えた」「セッションの定義が変わった」「メニューが少なすぎる」。結果として、以前は毎日アナリティクスを見ていた担当者が、月に1回レポートを出力する時しか開かなくなってしまった。これは非常にもったいない状況だ。 ## GA4は「探索」するためのツールになった UAは「用意されたレポートを見る」ツールだったが、GA4は「自分でデータを取り出して探索する」ツールに思想が変わっている。だから標準のレポート画面はシンプル（というよりスカスカ）なのだ。この思想の違いを受け入れないと、いつまでも「使いにくい」という不満から抜け出せない。 ## 実務担当者が最低限見るべき3つのポイント 複雑な設定や探索レポートを使いこなす前に、まずは標準レポートの中で「ここだけは定点観測する」というポイントを絞ることをおすすめする。 ### 1. ユーザー獲得の「参照元/メディア」 「どこから人が来ているか」は、Webマーケティングの基本中の基本だ。[レポート] > [集客] > [ユーザー獲得] の画面で、プライマリディメンションを「ユーザーの最初の参照元/メディア」に変更する。これで、自然検索（organic）、SNS、広告（cpc）など、どのチャネルが機能しているかが一目でわかる。 ### 2. エンゲージメント率（直帰率の代わり） UAで馴染み深かった「直帰率」の代わりに、GA4では「エンゲージメント率」を見る習慣をつけたい。これは「サイトに訪れて、意味のある行動（10秒以上滞在、2ページ以上閲覧、コンバージョンなど）をした人の割合」だ。直帰率の逆数に近いが、より実態に即した指標になっている。この数値が極端に低いページは、コンテンツとユーザーの期待がズレている証拠だ。 ### 3. ページとスクリーンの「表示回数」 [レポート] > [エンゲージメント] > [ページとスクリーン] で、どのページがよく見られているかを確認する。ここでのポイントは、単に表示回数を見るだけでなく、「ユーザーあたりのビュー」や「平均スクロール率」も併せて見ることだ。たくさん見られているのにすぐ離脱されているページがあれば、そこが改善の最優先ポイントになる。 ## データは「行動を変える」ために見る GA4の画面を眺めて「今月はPVが増えたね」で終わるなら、データを見る意味はない。「このページのエンゲージメント率が低いから、導入文を書き直そう」「この参照元からのCVが多いから、ここに広告予算を寄せよう」。データから次のアクションを決める。そのサイクルを回すためのツールとして、GA4と付き合っていきたい。 --- # デザインシステムは「作る」より「運用する」ほうが10倍難しい URL: https://www.pref.co.jp/knowledge/design-system-introduction Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: デザインシステム, UI/UX, Figma, フロントエンド UIの統一や開発効率化を目的にデザインシステムを導入する企業が増えているが、作って満足してしまい形骸化するケースが後を絶たない。失敗しないための運用設計の勘所。 ## 立派なガイドラインが「誰も見ないPDF」になる日 「開発のスピードを上げたい」「プロダクト間のUIのばらつきをなくしたい」。そんな目的でデザインシステム構築のプロジェクトが立ち上がる。数ヶ月かけてFigmaで美しいコンポーネント集を作り、詳細なルールをドキュメント化する。しかし半年後、そのデザインシステムは誰にも参照されず、現場ではまた独自のボタンやフォームが量産されている。なぜこんなことが起きるのか。 ## デザインシステムは「プロダクト」である 最大の原因は、デザインシステムを「一度作ったら終わりのガイドライン」だと勘違いしていることだ。デザインシステム自体が、社内のデザイナーやエンジニアをユーザーとする「ひとつのプロダクト」なのだ。プロダクトである以上、ユーザーのフィードバックを受けて継続的に改善し、アップデートし続けなければ、すぐに実態と乖離して使われなくなる。 ## 形骸化を防ぐための3つの運用ルール ### 1. 「例外」を許容するプロセスを作る どんなに完璧なコンポーネントを用意しても、実際のプロダクト開発では「どうしてもこの画面だけは特別なUIにしたい」という例外が必ず発生する。この時、「ルールだからダメ」と突っぱねると、現場はデザインシステムを無視して隠れて実装し始める。例外が発生した時の相談フローと、それをシステムに逆輸入してアップデートする仕組みを最初から設計しておくことが重要だ。 ### 2. 専任の管理チーム（または担当者）を置く 「みんなで少しずつメンテナンスしよう」という性善説は、忙しい現場では絶対に機能しない。誰の責任でもない仕事は、誰の仕事でもなくなるからだ。規模にもよるが、デザインシステムの保守・運用に責任を持つ専任の担当者、あるいは稼働の20%を割り当てられたコアメンバーを明確にアサインする必要がある。 ### 3. コードとデザインを同期させる Figma上のデザインと、実際のフロントエンドのコード（ReactやVueのコンポーネント）がズレ始めると、デザインシステムの崩壊が始まる。Storybookなどを活用し、「デザインデータと実装されたコードが常に一致している状態（Single Source of Truth）」を技術的に担保する仕組みが欠かせない。 ## 小さく始めて、育てていく 最初からGoogleやAppleのような壮大なデザインシステムを作ろうとする必要はない。まずはカラーパレットとタイポグラフィ、そしてよく使うボタンやフォームのコンポーネントだけを定義する。それを実際のプロジェクトで使いながら、足りないものを少しずつ足していく。その泥臭い反復作業の先にしか、本当に機能するデザインシステムは存在しない。 --- # ゼロトラストセキュリティ入門：「社内なら安全」という幻想の終わり URL: https://www.pref.co.jp/knowledge/zero-trust-security-basics Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: ゼロトラスト, セキュリティ, テレワーク, 情報漏洩対策 リモートワークの普及とクラウドサービスの活用で、従来の「境界型セキュリティ」は限界を迎えた。すべてのアクセスを疑う「ゼロトラスト」の基本的な考え方と、最初の一歩を解説する。 ## 「社内ネットワーク＝安全」という前提が崩れた これまでの企業のセキュリティ対策は、お城の防衛に似ていた。ファイアウォールやVPNという「高い城壁」を築き、その内側（社内ネットワーク）は安全、外側（インターネット）は危険と区別する。しかし、リモートワークが当たり前になり、業務でSaaS（クラウドサービス）を多用する今、守るべきデータは城壁の外に散らばっている。もはや「社内だから安全」という前提は通用しない。 ## ゼロトラスト＝「何も信頼しない」 そこで登場したのが「ゼロトラスト」という考え方だ。名前の通り、「ネットワークの内側だろうが外側だろうが、すべてのアクセスを信頼せず、毎回必ず検証する」というアプローチだ。社内の会議室からのアクセスであっても、カフェのWi-Fiからのアクセスであっても、同じように厳しくチェックする。 ## ゼロトラストを構成する3つの柱 ### 1. アイデンティティ（誰がアクセスしているか） IDとパスワードだけの認証は、もはや鍵をかけていないに等しい。多要素認証（MFA）を導入し、「本当にその本人がアクセスしているか」を確実に検証する。さらに、Azure ADやOktaなどのID管理基盤（IdP）を使って、すべてのアカウントを一元管理することが出発点になる。 ### 2. デバイス（どんな端末からアクセスしているか） 正しいユーザーであっても、マルウェアに感染した個人のスマホからアクセスされれば意味がない。会社が許可し、セキュリティ対策ソフト（EDRなど）が正しく動いている端末からのみアクセスを許可する仕組みが必要だ。MDM（モバイルデバイス管理）ツールを使って、端末の状態を常に監視する。 ### 3. 最小権限の原則（必要なものだけを見せる） 「一度ログインすれば、社内のすべてのシステムにアクセスできる」という状態は危険すぎる。営業担当者には顧客管理システムだけ、経理担当者には会計システムだけ、というように、業務に必要な最小限の権限だけを付与する。万が一アカウントが乗っ取られても、被害を局所化するための防波堤だ。 ## ツールを入れる前に、現状の棚卸しを 「ゼロトラスト対応のツールを導入すれば解決する」と考えるのは早計だ。ゼロトラストは製品名ではなく、考え方（アーキテクチャ）だからだ。まずは「自社の重要なデータはどこにあるのか」「誰が、どの端末で、どうやってアクセスしているのか」という現状を正確に把握すること。地味だが、この棚卸しなしにゼロトラストへの移行は始まらない。 --- # BtoB SaaSのプライシング戦略：安売りが首を絞める理由 URL: https://www.pref.co.jp/knowledge/b2b-saas-pricing-strategy Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: SaaS, プライシング, BtoB, ビジネスモデル 「まずは安くして導入社数を増やそう」という安易な価格設定が、SaaSビジネスの成長を阻害する。価値に見合ったプライシングの重要性と、価格改定のタイミングについて。 ## 「とりあえず月額5,000円で」の罠 新しいBtoB SaaSを立ち上げた際、多くの企業が陥る罠がある。「競合より安くすれば売れるだろう」「まずは導入社数を稼ぎたいから、月額5,000円くらいで始めよう」。この安易なプライシングが、後々自分たちの首を激しく絞めることになる。 BtoBビジネスにおいて、安さは必ずしも正義ではない。むしろ、安すぎる価格設定は「その程度の価値しかないツール」というシグナルを市場に送ってしまう。 ## 安売りが引き起こす3つの弊害 ### 1. サポートコストで赤字になる 月額5,000円のツールでも、月額10万円のツールでも、顧客から求められるサポートの質は大きく変わらない。むしろ、低価格帯の顧客のほうがITリテラシーが低く、手厚いオンボーディングを要求されるケースすらある。結果として、売上よりもサポートの人件費が上回り、売れば売るほど赤字が膨らむ構造に陥る。 ### 2. 決裁のハードルは「安さ」では下がらない BtoBの購買プロセスでは、月額5,000円でも稟議書は必要だ。「安いから現場の権限でサクッと導入できる」というのは幻想に近い。どうせ稟議を通す手間がかかるなら、企業は「安さ」よりも「確実に課題を解決してくれる信頼性」を選ぶ。中途半端な安さは、決裁の理由にはならないのだ。 ### 3. 開発投資に回す利益が出ない SaaSの命は継続的な機能アップデートだ。しかし、単価が低すぎると利益が出ず、優秀なエンジニアを採用することも、インフラを強化することもできない。結果としてプロダクトの進化が止まり、後発の競合にあっさりと追い抜かれてしまう。 ## 「価値」から逆算して価格を決める プライシングの基本は、コストの積み上げや競合の真似ではない。「このツールを使うことで、顧客はどれだけのコストを削減できるか（あるいは売上を増やせるか）」という「価値」から逆算することだ。例えば、月に10万円分の人件費を削減できるツールなら、月額3万円でも顧客にとっては十分にお釣りが来る投資になる。 ## 価格改定を恐れない 初期の価格設定が間違っていたと気づいたら、恐れずに価格改定（値上げ）に踏み切るべきだ。もちろん既存顧客からの反発はあるだろう。しかし、提供している価値に自信があるなら、適正な価格を提示して、それに納得してくれる顧客と深く長く付き合うほうが、ビジネスとしては圧倒的に健全だ。プライシングは一度決めたら変えられないものではない。プロダクトの成長に合わせて、価格も進化させていくものだ。 --- # 技術的負債との付き合い方：リファクタリングの稟議を通すには URL: https://www.pref.co.jp/knowledge/technical-debt-management Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: 技術的負債, リファクタリング, エンジニア組織, マネジメント 「コードが汚くて開発スピードが落ちているが、経営陣がリファクタリングの時間をくれない」。エンジニア組織が抱える永遠の課題に対する、ビジネス視点からのアプローチ。 ## 「動いているなら触るな」という経営陣の論理 長く運用されているシステムには、必ず「技術的負債」が溜まる。ツギハギだらけのコード、誰も全貌を把握していない謎のバッチ処理、古いバージョンのまま放置されたライブラリ。エンジニアは「このままでは開発スピードが落ちるからリファクタリングしたい」と訴えるが、経営陣やビジネス側からは「今動いているなら、新機能の開発を優先してくれ」と却下される。どこの開発現場でも見られる光景だ。 ## 技術的負債は「見えない借金」である 経営陣がリファクタリングに難色を示す理由はシンプルだ。「コードをきれいにしても、ユーザーから見える機能は何も増えないし、売上も上がらない」からだ。彼らにとって、リファクタリングは「エンジニアの自己満足」に見えている。この認識のズレを埋めない限り、永遠に時間はもらえない。 ## ビジネスの言葉で負債を翻訳する エンジニアがリファクタリングの稟議を通すには、「コードの美しさ」ではなく「ビジネスへの影響」を語る必要がある。技術的負債を、経営陣が理解できる「コスト」と「リスク」の言葉に翻訳するのだ。 ### 1. 機会損失のコストを提示する 「コードが汚い」と言うのではなく、「この機能を追加するのに、本来なら3日で終わるはずが、複雑なコードのせいで10日かかっている。つまり毎回7日分の人件費（約〇〇万円）を無駄にしている」と説明する。負債の利子を具体的な数字で示すのだ。 ### 2. セキュリティと障害のリスクを語る 「ライブラリが古い」と言うのではなく、「サポートが切れたライブラリを使い続けることで、脆弱性を突かれて顧客データが流出するリスクがある。万が一インシデントが起きれば、損害賠償とブランド毀損で〇〇億円の被害が出る可能性がある」と説明する。経営陣は「リスクの放置」には敏感だ。 ### 3. 採用と離職のコストを突きつける 「レガシーな技術スタックのままでは、優秀なエンジニアが採用できない。さらに、今のメンバーもモチベーションが下がり離職の引き金になる。エンジニア1人の採用コストは数百万円かかる」という事実を伝える。これも強力な説得材料になる。 ## 「20%ルール」を組織の文化にする 大規模なリファクタリングの時間をまとめて確保するのは難しい。現実的な解は、日々の開発スプリントの中に「負債返済の枠」を組み込むことだ。例えば「毎スプリントの稼働の20%は、新機能開発ではなくリファクタリングや環境改善に充てる」というルールを、開発チームとビジネス側で合意する。借金は、毎月少しずつコツコツと返していくしかないのだ。 --- # フルリモート組織のコミュニケーション不全をどう防ぐか URL: https://www.pref.co.jp/knowledge/remote-work-communication Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: リモートワーク, 組織開発, コミュニケーション, マネジメント 雑談が減り、業務連絡だけの冷たい関係になりがちなリモートワーク。ツールに頼るだけでなく、意図的に「余白」をデザインするための具体的な施策とマネジメントの心得。 ## 「業務は回っているが、何かがおかしい」 フルリモートワークを導入して数年。タスク管理ツールやチャットツールのおかげで、目先の業務は問題なく回っている。しかし、マネージャー層からは「メンバーのコンディションが見えにくい」「部署間の連携が減った」「新しいアイデアが生まれなくなった」という声が漏れ始めている。効率を極限まで追求した結果、組織から「余白」が消え去ってしまったのだ。 ## 雑談は「サボり」ではなく「潤滑油」だった オフィスに出社していた頃、私たちは無意識のうちに膨大な情報交換を行っていた。給湯室での立ち話、ランチの行き帰り、隣の席の会話の盗み聞き。こうした「目的のない雑談」が、実はメンバーの心理的安全性や、部署を超えた連携の潤滑油として機能していた。リモートワークでは、この雑談が意図的に設計しない限り発生しない。 ## 意図的に「余白」をデザインする3つの施策 ### 1. チェックイン／チェックアウトの習慣化 朝の始業時と夕方の終業時に、チームで短いミーティング（5〜10分）を行う。ここでは業務の進捗確認だけでなく、「今の気分」や「週末の出来事」など、仕事以外のパーソナルな話題を必ず一言交える。これだけで、テキストコミュニケーションの冷たさがかなり和らぐ。 ### 2. 「相談のハードル」を下げる仕組み リモートでは「ちょっといいですか？」と声をかけるハードルが高い。相手の状況が見えないため、チャットを送るのすら躊躇してしまう。これを解決するために、「毎日15:00〜15:30はZoomの特定のルームを開けっ放しにしておき、誰でも自由に入って相談していい時間（オフィスアワー）」を設けるなどの工夫が有効だ。 ### 3. テキストコミュニケーションの「温度感」を上げる テキストだけのやり取りは、どうしても冷たく、時に攻撃的に見えてしまう。絵文字やリアクションスタンプを積極的に使うことを、組織のカルチャーとして推奨する。「承知しました」というテキストより、「👍」のスタンプのほうが、心理的な距離は縮まる。リーダー層が率先して柔らかい表現を使うことが重要だ。 ## 「効率化」の罠に気づく リモートワークの最大のメリットは効率化だが、人間の感情や関係性まで効率化することはできない。一見無駄に思える雑談や余白の時間が、中長期的なチームのパフォーマンスを支えている。ツールを導入して終わりではなく、そのツールの上で「どう人間らしく振る舞うか」をデザインすることが、これからのマネジメントに求められている。 --- # BtoBコンテンツマーケティングで「読まれない記事」を量産しないために URL: https://www.pref.co.jp/knowledge/b2b-content-marketing-strategy Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: コンテンツマーケティング, BtoB, オウンドメディア, リード獲得 オウンドメディアを立ち上げたものの、PVも伸びずリードも獲得できない。BtoB企業が陥りがちなコンテンツ制作の罠と、本当に読者の課題に刺さる記事の作り方。 ## 「とりあえず週1本更新」という地獄 「リード獲得のためにオウンドメディアを始めよう」。そう意気込んで立ち上げたものの、半年後には「ネタがない」「誰も読んでいない」「問い合わせに繋がらない」という三重苦に陥るBtoB企業は多い。原因は明確だ。「誰の、どんな課題を解決するのか」という芯がないまま、SEOキーワードだけを見て「とりあえず週1本更新」というノルマをこなす作業になっているからだ。 ## BtoBコンテンツが読まれない3つの理由 ### 1. 「自社の言いたいこと」しか書いていない 製品の機能紹介や、社長のポエム、社内イベントの報告。これらは「自社が言いたいこと」であって、「顧客が知りたいこと」ではない。読者が求めているのは、自分たちの業務課題を解決するためのノウハウや他社の成功事例だ。主語を「私たち」から「読者」に変えない限り、記事は読まれない。 ### 2. ターゲットが広すぎる 「すべてのビジネスパーソンへ」といった広すぎるターゲット設定は、結果として誰にも刺さらない。「従業員50名規模の製造業で、初めてDX担当に任命されて何から手をつければいいか迷っている人」くらいまで、ペルソナを解像度高く絞り込む。ターゲットを絞るほど、記事の熱量は上がり、深く刺さるようになる。 ### 3. 現場の「生の声」が入っていない ネット上の情報を切り貼りしただけの「こたつ記事」は、すぐにAIや競合に埋もれてしまう。BtoBコンテンツの価値は、自社にしか語れない「現場の一次情報」にある。営業担当者が顧客からよく聞かれる悩み、カスタマーサポートに寄せられるクレーム、エンジニアが開発で苦労したポイント。これら社内に眠る一次情報こそが、最強のコンテンツの種になる。 ## 量より質。1本の「キラーコンテンツ」を作る 薄い記事を100本量産するより、読者の課題を深くえぐる1本の「キラーコンテンツ」を作るほうが、BtoBマーケティングでは圧倒的に価値がある。その1本が、検索上位を取り続け、SNSでシェアされ、営業資料としても使われる資産になる。 まずは更新頻度のノルマを捨てて、「この記事を読めば、顧客のあの悩みが完全に解決する」と胸を張って言える記事を、1ヶ月かけてでも作り込んでみてほしい。そこからすべてが始まる。 --- # UI/UXデザインへの投資対効果（ROI）をどう説明するか URL: https://www.pref.co.jp/knowledge/ui-ux-design-roi Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: UI/UX, デザイン, ROI, ビジネスモデル 「デザインを良くして、いくら儲かるの？」。経営陣からのこの問いに答えられず、デザイン予算を削られる現場は多い。UI/UXの価値をビジネスの数字に変換する考え方。 ## 「デザイン＝見た目のお化粧」という誤解 プロダクト開発において、UI/UXデザインの予算は真っ先に削られやすい。「機能要件は満たしているのだから、デザインは後回しでいい」「見た目をきれいにしても売上は変わらないだろう」。経営陣からこう言われ、反論できずに悔しい思いをしたデザイナーやプロダクトマネージャーは多いはずだ。 この悲劇は、デザインを「見た目のお化粧」だと捉えていることから生まれる。UI/UXデザインの本質は、ユーザーの課題解決をスムーズにし、ビジネスの成果（数字）を動かすことだ。 ## UI/UXの価値を「数字」に変換する デザインへの投資対効果（ROI）を説明するには、デザインの改善が「どのビジネス指標（KPI）に効くのか」を論理的に紐づける必要がある。代表的な3つの切り口を紹介する。 ### 1. コンバージョン率（CVR）の向上＝売上の増加 最もわかりやすい指標だ。入力フォームのUIを改善して離脱率を下げる。購入ボタンの配置やマイクロコピーを見直してクリック率を上げる。これらは直接的に売上の増加に直結する。「CVRが0.5%上がれば、年間で〇〇万円の売上増になる。そのためのデザイン投資です」と説明すれば、経営陣も納得しやすい。 ### 2. サポートコストの削減 BtoB SaaSや複雑な業務システムで特に有効な切り口だ。UIがわかりにくいため、ユーザーが迷い、カスタマーサポートへの問い合わせが殺到している状態。これを「迷わないUI」に改善することで、問い合わせ件数を減らす。「月間の問い合わせ対応にかかる人件費〇〇万円を削減するためのデザイン投資です」というロジックだ。 ### 3. 開発の手戻りコストの削減 要件定義やプロトタイプの段階でUXリサーチ（ユーザーテストなど）をしっかり行うことで、「作ってみたけど誰も使わなかった」「リリース後に致命的な使いにくさが発覚して作り直した」という悲劇を防ぐことができる。「エンジニア数名が数ヶ月かけて作り直すコスト（数百万〜数千万円）を未然に防ぐための、リサーチへの投資です」と語る。 ## デザイナーもビジネスの言葉を話す 「ユーザー体験を良くしたい」という情熱だけでは、予算は獲得できない。デザイナー自身が、自社のビジネスモデルを理解し、LTV（顧客生涯価値）やCAC（顧客獲得単価）、チャーンレート（解約率）といったビジネスの言葉を使って、デザインの価値を語れるようになる必要がある。デザインとビジネスの架け橋になれる人材こそが、今最も求められている。 --- # レガシーシステム刷新の「ビッグバン・リリース」はなぜ失敗するのか URL: https://www.pref.co.jp/knowledge/legacy-system-migration-strategy Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: レガシーシステム, システム移行, プロジェクト管理, DX 老朽化した基幹システムを数年かけて一気にリプレイスする「ビッグバン・リリース」。その多くが炎上し、頓挫する理由と、リスクを抑える段階的移行（ストラングラーパターン）の基本。 ## 「〇年〇月〇日、新システムへ一斉切り替え！」の恐怖 稼働から10年以上が経過し、スパゲッティ状態になった基幹システム。これを刷新する際、多くの企業が「数年かけて新しいシステムを裏で作り込み、ある日を境に一斉に切り替える」というアプローチをとる。いわゆる「ビッグバン・リリース」だ。 しかし、この手法の成功率は極めて低い。数年間の開発期間中にビジネス環境や要件は変わり、いざ切り替えてみると「旧システムでできていた業務ができない」「想定外のバグが頻発して業務が停止する」といった大炎上を引き起こす。最悪の場合、新システムを諦めて旧システムに戻す（ロールバックする）という悲惨な結末を迎える。 ## ビッグバン・リリースが失敗する3つの理由 ### 1. 「現行踏襲」という呪い リプレイスの要件定義で必ず出てくるのが「今のシステムと同じことができるようにしてほしい（現行踏襲）」という言葉だ。しかし、旧システムの仕様書は古く、実際の挙動はソースコード（あるいは担当者の頭の中）にしかない。この「隠れた仕様」をすべて洗い出し、新システムで完璧に再現することは不可能に近い。 ### 2. フィードバックループが長すぎる 数年間、ユーザー（現場の担当者）は新システムに触れることができない。開発の終盤、受け入れテスト（UAT）の段階になって初めて画面を見て、「これでは仕事にならない」とちゃぶ台返しが起きる。手戻りするには遅すぎるタイミングだ。 ### 3. 切り替え時のリスクが巨大すぎる すべての機能を一度に切り替えるため、どこか1箇所でも致命的なバグがあれば、システム全体、ひいては企業活動全体が停止してしまう。関係者のプレッシャーは尋常ではなく、リリース当日は徹夜のトラブル対応が常態化する。 ## 段階的移行（ストラングラーパターン）という現実解 この巨大なリスクを回避するための現実的なアプローチが、「ストラングラーパターン（Strangler Fig Pattern）」と呼ばれる段階的移行だ。 旧システムを活かしたまま、新システムを並行して立ち上げる。そして、「顧客検索」「在庫照会」といった独立しやすい小さな機能から順番に、新システムへと切り替えていく。ユーザーからのアクセスは、ルーターやAPIゲートウェイで旧システムと新システムに振り分ける。 ## 小さく切り替えて、小さく失敗する 段階的移行のメリットは、リスクを分散できることだ。1つの機能を切り替えて問題が起きても、影響範囲はその機能に限定されるし、すぐに旧システムに切り戻すことも容易だ。また、早い段階からユーザーに新システムを触ってもらうことで、フィードバックを開発に活かすことができる。 「一気に新しくしたい」という誘惑を抑え、数年かけて旧システムを少しずつ「絞め殺して（Strangler）」いく。地味で根気のいる作業だが、これが最も確実なレガシーシステム刷新の道だ。 --- # 表示速度改善は「画像の圧縮」だけでは終わらない：Core Web Vitalsの現実 URL: https://www.pref.co.jp/knowledge/web-performance-core-web-vitals Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: Core Web Vitals, パフォーマンスチューニング, SEO, フロントエンド 「サイトが重いから画像を軽くしよう」。それは正しいが、それだけではGoogleのCore Web Vitals指標は改善しない。LCP、INP、CLSの3つの指標が本当に意味するものと、技術的なアプローチ。 ## 「画像は軽くしたのに、PageSpeed Insightsの点数が上がらない」 Webサイトの表示速度改善の相談を受ける際、よく聞く言葉だ。確かに、重い画像をWebPなどの軽量フォーマットに変換し、適切にリサイズすることは基本中の基本だ。しかし、現代のWebパフォーマンス指標である「Core Web Vitals」は、単なる「ファイルの軽さ」だけを評価しているわけではない。 Googleは、ユーザーがページを開いてから操作できるようになるまでの「体験の質」を数値化しようとしている。画像を軽くしただけで満足していては、本質的な改善には届かない。 ## Core Web Vitalsの3つの指標を正しく理解する ### 1. LCP（Largest Contentful Paint）：最大の要素が描画されるまでの時間 ユーザーがページを開いたとき、ファーストビューの中で「一番大きな要素（メインビジュアルの画像や見出しテキスト）」が表示されるまでの時間だ。これが2.5秒以内であることが求められる。 対策の勘所： 画像の圧縮だけでなく、「ブラウザにいかに早くその画像を読み込ませるか」が鍵になる。を使ってメイン画像を優先的に読み込ませたり、サーバーの応答速度（TTFB）自体を改善（CDNの導入やキャッシュの活用）したりするアプローチが必要だ。 ### 2. INP（Interaction to Next Paint）：操作に対する反応の速さ 2024年3月からFIDに代わって導入された指標。ユーザーがボタンをクリックしたり、キーボードを入力したりした際、ブラウザが視覚的な反応（メニューが開く、色が変わるなど）を返すまでの遅延時間を測る。200ミリ秒以内が理想だ。 対策の勘所： 原因のほとんどは「重いJavaScriptの実行」にある。メインスレッドをブロックしている不要なJS（使っていないサードパーティのタグや重いアニメーションライブラリ）を削除・遅延読み込みさせることが最大の対策になる。 ### 3. CLS（Cumulative Layout Shift）：レイアウトのズレ ページを読んでいる途中で、遅れて読み込まれた画像や広告がガクッと割り込んできて、テキストが下に押し下げられる現象。誤クリックを誘発する最悪のユーザー体験だ。このズレの総量を0.1以下に抑える必要がある。 対策の勘所： 画像や広告枠、埋め込み要素（YouTubeなど）に対して、あらかじめHTMLやCSSでwidthとheight（またはアスペクト比）を指定し、表示領域を確保しておく。これだけでCLSの大部分は解決する。 ## パフォーマンス改善は「引き算」の技術 表示速度の低下は、多くの場合「足し算」の結果として起こる。マーケティングのための計測タグ、リッチに見せるためのアニメーション、便利なチャットウィジェット。これらを無自覚に足し続けた結果、サイトは重くなる。 パフォーマンス改善の本質は、画像の圧縮ではなく「不要なものを捨てる（引き算する）」決断にある。ビジネス要件とパフォーマンスのトレードオフを、チーム全体で議論できるかどうかが問われている。 --- # 「データドリブン」の罠：数字をこねくり回して意思決定が遅れる病 URL: https://www.pref.co.jp/knowledge/data-driven-marketing-pitfalls Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: データ分析, マーケティング, 意思決定, DX データは嘘をつかないが、データを扱う人間は簡単に道を間違える。分析のための分析に陥り、アクションが止まってしまう「データドリブン病」の症状と処方箋。 ## 「もっとデータを見てから決めましょう」という魔法の言葉 会議で行き詰まったとき、誰かが「もっと詳細なデータを出して、それを見てから判断しましょう」と言う。一見、論理的で正しい態度に見える。しかし、これが「データドリブン病」の初期症状だ。翌週、担当者が膨大なクロス集計データを持ってきたところで、結局「解釈が分かれる」「まだサンプル数が足りない」と言い出し、意思決定はさらに先送りされる。 データドリブンとは、データを使って「早く、正確に決断する」ための手法だ。データを見ることで決断が遅れているなら、それは本末転倒である。 ## データドリブン病の3つの症状 ### 1. 「分析のための分析」に陥る 目的（解きたい課題）が曖昧なまま、手元にあるデータをとりあえずこねくり回す。美しいダッシュボードや複雑なグラフを作ることに満足してしまい、「で、このデータから明日のアクションをどう変えるの？」という問いに誰も答えられない状態だ。 ### 2. 「完璧なデータ」を求めすぎる 「このデータは〇〇の条件がノイズになっているから信用できない」「システム間の連携が不完全で数字がズレている」。確かにデータクレンジングは重要だが、100%完璧なデータなどビジネスの現場には存在しない。80%の精度でも、方向性を決めるには十分なケースがほとんどだ。 ### 3. 直感や定性情報を軽視する 数字で証明できないものは価値がない、と切り捨てる極端な態度。顧客のちょっとした表情の変化や、営業担当者の「最近、競合の動きが変わった気がする」という肌感覚。こうした定性的な一次情報こそが、データ分析の「仮説」を作る重要な種になる。 ## 処方箋：データを見る前に「仮説」と「アクション」を決める この病を治す処方箋はシンプルだ。データを開く前に、必ず以下の2つをセットで決めるルールにする。 - 仮説を立てる： 「おそらく、〇〇という理由で離脱率が上がっているはずだ」 - アクションの閾値を決める： 「もしデータを見て、離脱率が〇〇%以上ならAの施策をやる。それ以下ならBの施策をやる」 この2つが決まっていれば、データを見た瞬間に自動的にアクションが決まる。ダッシュボードを眺めてウンウン唸る時間はゼロになる。 ## データは「決断の背中を押す」ためにある データは過去の事実を教えてくれるが、未来の正解を教えてくれるわけではない。最後は人間がリスクを取って「えいや」と決断するしかないのだ。データドリブンという言葉を、決断から逃げるための言い訳にしてはいけない。 --- # フリーランスエンジニアへの業務委託で失敗しないための契約とマネジメント URL: https://www.pref.co.jp/knowledge/freelance-engineer-contract-guide Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: 業務委託, フリーランス, プロジェクトマネジメント, システム開発 優秀なフリーランスエンジニアに依頼したはずが、期待した成果が出ずトラブルになる。準委任契約の性質を理解せず、社員と同じように扱ってしまう発注側の問題点と対策。 ## 「高い単価を払っているのに、全然動いてくれない」 IT人材不足の中、フリーランスエンジニアに業務委託で開発を手伝ってもらう企業が増えている。しかし、「月額〇〇万円も払っているのに、指示したことしかやらない」「期待していたスピード感がない」と不満を漏らす発注担当者は多い。 厳しい言い方になるが、そのトラブルの8割は発注側の「契約の理解不足」と「マネジメントの怠慢」に原因がある。フリーランスは「便利な外部社員」ではない。独立したプロフェッショナルな事業者だ。 ## 「準委任契約」の性質を正しく理解する フリーランスエンジニアとの契約の多くは「準委任契約（SES）」だ。これは「特定の業務を遂行すること」に対して報酬を払う契約であり、「完成物を納品すること（請負契約）」を約束するものではない。また、発注側に「指揮命令権」はない。つまり、「明日は〇時に出社して、このタスクを〇時までに終わらせて」といった細かい指示（偽装請負リスク）は本来できないのだ。 ## 失敗を防ぐための3つの鉄則 ### 1. 「期待値」を言語化してドキュメントに残す 「よしなにやってくれるだろう」という期待は必ず裏切られる。契約前に、「どの領域の設計から任せたいのか」「コードを書くだけでなく、レビューや若手のメンターも期待しているのか」「ミーティングの頻度はどれくらいか」を明確に言語化し、合意しておく必要がある。 ### 2. 必要な情報と権限を最初から渡す 優秀なエンジニアでも、仕様書がなく、ソースコードへのアクセス権限が一部しかなく、ビジネスの背景（なぜこの機能を作るのか）を知らされなければ、パフォーマンスを発揮しようがない。彼らを「外部の人間」として扱うのではなく、プロジェクトを成功させる「パートナー」として、必要な情報は透明性高く共有すべきだ。 ### 3. マイクロマネジメントを捨て、アウトプットで評価する 「今日は何時間働きましたか？」「今何をやっていますか？」と細かく監視するのは、お互いにとって不幸だ。彼らは時間ではなく、専門的なスキルを提供している。週次やスプリントごとのアウトプット（プルリクエストの質や量、課題解決への貢献度）ベースで評価し、コミュニケーションをとるスタイルに切り替える必要がある。 ## プロにはプロの接し方を フリーランスエンジニアは、複数の案件を渡り歩いてきた経験豊富なプロフェッショナルだ。彼らの知見を最大限に引き出せるかどうかは、発注側が「働きやすい環境」と「明確なゴール」を用意できるかどうかにかかっている。社員と同じように「管理」しようとする発想を捨てたとき、初めて彼らは強力な戦力になってくれる。 --- # GEO（生成AI検索最適化）とは？SEOとの違いと実践ガイド URL: https://www.pref.co.jp/knowledge/what-is-geo Published: 2026-04-01 Updated: 2026-04-01 Author: 株式会社プリファード Tags: GEO, SEO, AI検索, Google AI Overview, ChatGPT Google AI OverviewやChatGPT検索の普及で、従来のSEOだけでは検索流入を維持できない時代に。GEOの基本概念から具体的な対策手法まで、実務担当者向けにわかりやすく解説します。 ## GEOとは何か——検索の「答え方」が変わった 「しっかりSEO対策をしているのに、最近なぜか流入が減ってきた」。私たちのもとに届く相談で、ここ半年ほど目立って増えているのがこの悩みだ。原因の多くは、Google検索結果の上部に表示されるAI Overviewにある。ユーザーがリンクを踏まなくても、AIの回答だけで満足して去ってしまう。 GEO（Generative Engine Optimization）は、こうしたAI生成の回答に自社の情報を拾ってもらうための取り組みを指す。ChatGPTの検索機能やPerplexityも含め、「AIが参照元として選ぶ情報源」になれるかどうか。それが新しい勝負どころになっている。 ## SEOとGEOは何が違うのか SEOをやめてGEOに切り替える、という話ではない。両方やる。ただ、力の入れどころがかなりずれるので、違いを押さえておきたい。 比較項目SEOGEO 目的検索結果ページの上位に表示するAIの回答ソースとして採用される 主な対象GoogleのランキングアルゴリズムLLMの参照・引用ロジック 評価指標順位・CTR・オーガニック流入数AI回答での引用回数・ブランド言及数 コンテンツの特徴キーワード配置・内部リンク設計事実記述の明確さ・構造化データ・権威性 効果が出るまで数週間〜数ヶ月AIモデルの更新サイクルに依存 ざっくり言えば、SEOは「Googleのランキングを攻略する技術」、GEOは「AIに"この情報は信用できる"と認めさせる技術」だ。似ているようで、コンテンツの作り方がけっこう変わってくる。 ## なぜ今、GEOを無視できないのか 数字を見ると切迫感がわかる。Gartnerは2026年までにオーガニック検索トラフィックが25%減ると予測した。私たちが運用を支援しているサイトでも、「〇〇とは」「〇〇 やり方」系の記事は2025年後半からじわじわとクリック数が落ちている。AI Overviewの枠内で回答が完結してしまうからだ。 逆に言えば、AI Overviewの回答に自社名が引用されれば、従来の検索1位以上のインパクトがある。ユーザーの目に真っ先に触れるわけだから、認知と信頼を同時に獲得できる。この流れに乗れるかどうかで、年単位の集客力に差が開くだろう。 ## GEO対策——私たちが実際にやっている5つのこと ### 1. あいまいな表現を数字と固有名詞に置き換える AIは「多くの企業が採用」のようなぼんやりした記述をあまり引用しない。「国内SaaS企業の約45%がChatGPTを業務利用（MM総研、2025年10月調査）」のように、出典つきの具体的な記述のほうが拾われやすい。私たちのクライアントサイトで検証した限り、数字入りの段落は引用率がおよそ2倍になった。 ### 2. Schema.orgの構造化データを入れる FAQPage、HowTo、Articleといったスキーママークアップは、AIがページの中身を読み解く手がかりになる。実装自体は半日もあれば終わる程度の作業なので、まだ入れていないなら早めに手をつけたい。 ### 3. E-E-A-T——とくに「Experience」を見せる 著者プロフィール、会社の実績、案件で得た一次情報。こうした要素がSEOでも評価されてきたのは周知のとおりだけれど、GEOではさらに効いてくる。AIが「どの情報源を参照するか」を判断するとき、書き手の経験が読み取れるコンテンツを優先する傾向があるからだ。 ### 4. 見出しの直下に結論を置く AIは回答を組み立てるとき、要約しやすい短い段落を好む。だから「見出し→結論→詳細説明」の順で書くのが効く。ダラダラと前置きしてから結論にたどり着く構成だと、引用の候補から漏れやすい。 ### 5. 自社サイト以外でも情報を出す 業界メディアへの寄稿、プレスリリース配信、SNSでの発信。AIは複数のソースで同じ情報が語られているかどうかもチェックしている。一つのドメインに閉じず、「面」で情報を広げる意識が要る。 ## GEOの効果はどう測るか 正直に言うと、まだ確立された計測手法はない。ただ、以下の方法で間接的に追いかけることはできる。 - Google Search Consoleの「AI Overview」関連データをウォッチする - ChatGPTやPerplexityに自社名・サービス名を定期的に質問して、回答に含まれるかどうか記録する - ブランドキーワードの検索ボリューム推移を月次で確認する - Googleアナリティクスでオーガニック流入の変化をチャネル別に分解する 地味な作業だけれど、「AIに自社がどう映っているか」を把握する習慣は、早い段階で身につけておいて損がない。 ## GEOとSEOは地続きの話 GEOはSEOの否定ではない。良質なコンテンツを作り、構造を整え、信頼性を高める——その本質は変わっていない。変わったのは、読み手に「人間」だけでなく「AI」が加わったという一点だ。 まず手をつけるなら、既存記事の曖昧な表現を具体的な数字に直すところからだ。構造化データの追加も含め、大きな予算をかけずにできることはたくさんある。私たちも引き続き検証を重ねて、わかったことはここで共有していく。 --- # microCMSでJamstackサイトを構築する5つのメリットと導入手順 URL: https://www.pref.co.jp/knowledge/microcms-jamstack-guide Published: 2026-03-28 Updated: 2026-03-28 Author: 株式会社プリファード Tags: microCMS, Jamstack, Next.js, ヘッドレスCMS, Web制作 ヘッドレスCMS「microCMS」とNext.jsを組み合わせたJamstackサイト構築の利点を、実際のプロジェクト経験をもとに解説。表示速度・セキュリティ・運用面での具体的な効果をお伝えします。 ## Jamstackとは何か——WordPressとの根本的な違い 「WordPressのアップデート通知、また来てる……」。この画面を見るたびに憂鬱になる担当者は少なくないはずだ。プラグインの互換性を確認して、バックアップを取って、恐る恐る更新ボタンを押す。その一連の作業から解放してくれるのが、Jamstackという考え方になる。 Jamstack（JavaScript・API・Markup）は、あらかじめビルドした静的ファイルをCDN経由で配信するWebアーキテクチャだ。サーバーがリクエストのたびにHTMLを組み立てるWordPressとは構造がまるで違う。「静的サイト」と聞くと古臭い印象を受けるかもしれないが、コンテンツ管理はヘッドレスCMS、決済はStripe、認証はAuth0と、必要な機能をAPIで繋ぐ設計になっている。むしろ柔軟性は高い。 ## なぜmicroCMSなのか ヘッドレスCMSの選択肢はContentful、Strapi、Sanityなど豊富にある。それでも日本語サイトの運用には、やはりmicroCMSが合うと感じる場面が多い。 - 管理画面が完全に日本語——エンジニアでないスタッフが操作に迷わない。ここが地味に大きい - 国内サーバーでAPIが速い——海外CMSに比べてレイテンシが50〜100ms短く、ビルド時間にも効いてくる - 困ったときに日本語で質問できる——ドキュメントもサポートも日本語対応。英語ドキュメントを読み解く時間が省ける - Hobbyプラン（無料）から始められる——試してから課金を判断できるので、稟議のハードルが低い 私たちも案件でContentfulを使うことはあるけれど、「日本語コンテンツを日本のチームで回す」という条件が付くと、microCMSを推すケースがほとんどだ。管理画面の使いやすさだけで、運用定着率が体感で2倍は変わる。 ## 5つのメリット——数字で見る効果 ### 1. 表示速度が劇的に改善する 静的ファイルをCDNから返すので、サーバーの処理待ちがほぼゼロになる。私たちが昨年手がけた案件の一つでは、WordPressからJamstackに移行してLCP（Largest Contentful Paint）が3.2秒→0.8秒に縮まった。Core Web Vitalsのスコアが改善すれば、SEOにも好影響が出る。体感的にも「速いサイト」は訪問者の印象がまるで違う。 ### 2. セキュリティの心配がぐっと減る WordPressは世界中のサイトで使われている分、攻撃のターゲットにもなりやすい。Jamstackでは公開サーバーにCMSが存在しないため、SQLインジェクションやプラグインの脆弱性を突かれるリスクそのものが消える。「緊急セキュリティパッチ」に追われる週末ともお別れだ。 ### 3. ランニングコストが安い Vercelの無料プラン＋microCMSのHobbyプランなら、月額0円で運用を始められる。CDN配信なのでアクセスが急増してもサーバー増強は不要。テレビで紹介されてアクセスが跳ね上がっても落ちない——中小企業にとって、これは安心感が大きいだろう。 ### 4. コンテンツ更新がブログ感覚 microCMSの管理画面は、WordPressの投稿画面に慣れている人なら30分で使いこなせる。テキスト入力、画像アップ、リッチエディタ。必要な機能は揃っている。Webhookを設定しておけば、記事を公開した瞬間にサイトが自動で再ビルドされるので、「更新したのに反映されてない」という事故も起きにくい。 ### 5. フロントの技術を自由に選べる Next.js、Astro、Nuxt——どのフレームワークを使うかは開発チームの判断次第。CMSの制約でデザインを妥協する、あの歯がゆさがない。ブランドの世界観を100%表現できるのは、制作者としても嬉しいところだ。 ## 導入の流れ——4ステップ ### ステップ1：microCMSでAPI設計 アカウントを作ったら、まずコンテンツのデータ構造を決める。ブログ記事なら「タイトル」「本文」「カテゴリ」「公開日」あたりが基本フィールドだ。ここの設計を雑にすると後で苦労するので、「誰が・どんな頻度で・何を更新するか」を先に詰めておくといい。 ### ステップ2：Next.jsプロジェクトを立ち上げる 公式テンプレートをベースにプロジェクトを作り、microCMSのSDK（microcms-js-sdk）をインストール。環境変数にAPIキーとサービスIDをセットすれば、数行のコードでコンテンツを取得できるようになる。ここまでは慣れた開発者なら1時間もかからない。 ### ステップ3：ページテンプレートの実装 一覧ページと詳細ページを組む。SSG（Static Site Generation）で全ページを静的HTMLとして生成するのが基本。記事数が増えてきたらISR（Incremental Static Regeneration）を併用して、更新があったページだけ再生成する設計にすると、ビルド時間を抑えられる。 ### ステップ4：Vercelにデプロイ GitHubリポジトリとVercelを繋げば、pushのたびに自動デプロイが走る。microCMSのWebhookでコンテンツ更新→Vercelビルドをトリガーすれば、CMS更新からサイト反映まで完全自動化の完成だ。ここまでの一連の構築、早ければ1〜2日で終わる。 ## 向かないケースもある——正直な話 万能ではない。リアルタイム検索や複雑なユーザーインタラクション（ECサイトのカート機能など）が中心のサービスなら、別途APIの設計が必要になる。ページ数が数万規模に膨らむとビルド時間が問題になることもあり、ISRやOn-demand Revalidationの設計が欠かせない。 ただ、コーポレートサイト、メディアサイト、サービス紹介サイトあたりなら、Jamstackの恩恵をフルに受けられる。WordPress運用に疲弊している現場ほど、切り替えたときの快適さに驚く。「前のほうがよかった」と言われたことは、今のところ一度もない。 ## microCMS × Next.js × Vercel——この組み合わせの勘所 速度、セキュリティ、コスト。三拍子揃った構成だと思っている。とくに「WordPressの保守が負担」「表示速度をなんとかしたい」「セキュリティ事故が怖い」のどれかに当てはまるなら、検討してみる価値は十分にある。 --- # 中小企業のための生成AI導入ガイド｜失敗しない進め方 URL: https://www.pref.co.jp/knowledge/generative-ai-adoption-guide Published: 2026-03-25 Updated: 2026-03-25 Author: 株式会社プリファード Tags: 生成AI, ChatGPT, Claude, AI導入, 中小企業, DX 生成AIを業務に取り入れたいけれど、何から手をつければいいかわからない。そんな中小企業の経営者・担当者に向けて、導入の考え方から具体的なステップまでを整理しました。 ## 「うちにはまだ早い」——その判断、半年前なら正しかった 生成AIの話になると、「大企業がやることでしょ」「IT部門がないうちには関係ない」という反応が返ってくることがある。気持ちはわかる。ただ、状況は思った以上に動いている。帝国データバンクの調査（2025年10月）では、中小企業の約35%がすでに何らかの形で生成AIを業務に使っていた。3社に1社。もう「早い」とは言えない数字だ。 問題は「導入したけど結局使われなくなった」というケースが後を絶たないこと。私たちも相談を受ける中で、同じパターンを繰り返し見てきた。この記事では、従業員10〜100名くらいの企業を念頭に、失敗を避けながら生成AIを業務に根づかせる進め方を書いていく。 ## 中小企業の現場で、実際に効いている使い方 ChatGPTやClaudeにできることは山ほどあるが、中小企業の日常業務で「これは助かる」と声が上がりやすいのは、だいたい以下の5つに集まる。 - 文章の下書き——メール返信、提案書、報告書、SNS投稿の叩き台づくり - 情報の要約——会議の議事録を5行にまとめる、長い報告書から要点だけ抜く - リサーチの初動——競合の動向、市場の概況を短時間でざっと把握する - Excel・スクリプトの補助——関数を書いてもらう、簡単なデータ加工スクリプトを生成する - 問い合わせ対応の下準備——FAQ回答のドラフト、返信メールのテンプレート作成 共通しているのは、「仕事を丸ごと任せる」のではなく「手を動かす前の準備を肩代わりしてもらう」という使い方だ。この距離感を最初につかめるかどうかが、定着するかしないかの分かれ目になる。 ## うまくいかない企業に見える3つの共通点 ### 「とりあえず全員分、契約しておこう」 ChatGPT Plusを社員全員分いきなり契約する。よく聞く話だけれど、使い方のガイドラインも対象業務も決めないまま渡すと、2ヶ月後にはログインする人がほぼいなくなる。月額3,000円×人数分が消えるだけならまだしも、「やっぱりAIって使えないね」という空気が社内に広がるのが痛い。 ### 最初からRAGやチャットボット開発に突っ込む いきなり数百万円かけてカスタムシステムを作ろうとするケース。技術検証が足りないまま開発に入って、期待した精度が出ない——という現場を何度か見てきた。既存のAIサービスを手で触って「ここには効く、ここには効かない」を確認してから開発に進んでも遅くはない。 ### 「詳しそうな若手」に丸投げ たまたまAIに興味のある社員に全部任せてしまう。その人が異動したら知見がゼロに戻る。属人化を避けるには、最低でも2〜3人でチームを組み、試したプロンプトや手順をドキュメントに残しておくこと。地味だけれど、これをやるかやらないかで半年後の景色が変わる。 ## 私たちが勧める導入ステップ ### ステップ1：業務の棚卸しと対象選定（1〜2週間） 社内の主な業務を書き出して、「繰り返し発生する」「テキストが中心」「正解が一つに決まらない」タスクをピックアップする。この3条件に当てはまるものが、生成AIとの相性がいい。 ### ステップ2：2〜3人で小さく試す（2〜4週間） 選んだ業務で、少人数が実際にAIを使ってみる。この段階は無料プランで十分。肝心なのは「どこで役に立ったか」「どこでダメだったか」を毎日メモすること。感覚ではなく記録が、次の判断材料になる。 ### ステップ3：ルール作りとツール選定（1〜2週間） トライアルの結果を踏まえて、利用ルール——とくに機密情報の扱いと出力の確認フロー——を決める。ツールはChatGPT Team、Claude for Business、Microsoft Copilotあたりが選択肢になるが、自社のセキュリティポリシーとの整合を必ず確認してほしい。 ### ステップ4：社内に広げる（ここから継続） 効果があった使い方を社内Wikiやチャットツールに載せて共有する。月に1回、15分でいいから「最近こう使ってみた」を持ち寄る場を作る。これだけで、ツールが放置される確率はぐっと下がる。 ## コスト感——どれくらいかかるのか 導入段階主なコスト月額の目安 個人利用（お試し）ChatGPT Plus / Claude Pro約3,000円/人 チーム利用ChatGPT Team / Claude for Business3,000〜5,000円/人 カスタム開発API利用料＋開発費数万〜数十万円 いきなり大きな金額を動かす必要はない。月1〜2万円の範囲でスタートし、手応えが出てきたら枠を広げる。このペースが一番堅い。 ## セキュリティ——最低限ここだけは 生成AIの導入で経営層が最も気にするのが情報漏洩だ。以下の3点は、トライアル開始前に必ず詰めておきたい。 - 入力データの学習利用——ビジネス向けプランでは入力内容がモデルの学習に使われない設定が一般的だが、プランによって異なる。契約前に確認すること - 入力NGの情報を決める——顧客の個人情報、未公開の財務データ、契約の詳細。これらはAIに渡さない、とルールで明文化しておく - 出力のファクトチェック体制——AIの回答は「もっともらしいが間違っている」ことがある。社外に出す前に、人間が必ず裏を取る運用フローを組む ## 焦らなくていい。でも、止まっている場合でもない 完璧な準備なんて要らない。身近な業務でまず触ってみて、うまくいった方法を少しずつ横に広げる。それだけでいい。ただ、「そのうちやろう」と言っているうちに、同業他社はもう動き始めている。小さく、でも着実に。その一歩が、半年後の仕事のやり方を変える。 --- # ヘッドレスCMS比較2026：microCMS・WordPress・Contentful、どれを選ぶ？ URL: https://www.pref.co.jp/knowledge/headless-cms-comparison-2026 Published: 2026-03-20 Updated: 2026-03-20 Author: 株式会社プリファード Tags: ヘッドレスCMS, microCMS, WordPress, Contentful, CMS比較 国内外の主要ヘッドレスCMSを機能・コスト・運用のしやすさで比較。プロジェクトの規模や目的に応じた選び方の指針を、制作会社の視点でまとめました。 ## 「CMS、そろそろ変えたいんだけど……」という相談が増えている Web制作の打ち合わせで、ここ1年ほど決まって出てくる話題がある。「WordPressの運用がしんどい」「表示速度が遅いと言われた」「リニューアルを機にCMSを見直したい」。どれも切実な悩みだ。 ヘッドレスCMSは、コンテンツ管理とフロント表示を分離して、APIでつなぐ仕組み。テーマやテンプレートに縛られず、好きなフレームワークで自由にデザインできる。2024年以降、導入企業が急激に増えた。ただ、選択肢が増えた分だけ「結局どれがいいの？」という迷いも深くなっている。この記事では、私たちが案件で実際に触ってきた3つのCMSを、忖度なしで比べてみる。 ## 3サービスの顔ぶれ ### microCMS 日本生まれのヘッドレスCMS。管理画面が完全に日本語で、国内企業の導入実績が豊富だ。2024年のAPI v2リリースで、リレーション機能やメディア管理がぐっと使いやすくなった。 ### WordPress（ヘッドレス運用） 世界のWebサイトの約43%で稼働しているCMS。もともと一体型（モノリシック）だが、REST APIやWPGraphQLプラグインを入れればヘッドレスとしても動く。すでにWordPressで動いているサイトを段階的に移行したい場合、有力な選択肢になる。 ### Contentful ドイツ発、グローバル向けのヘッドレスCMS。多言語展開や大規模コンテンツ運用に強い。エンタープライズの導入事例が多い一方で、料金と英語UIのハードルは無視できない。 ## ガチ比較——機能・コスト・運用 比較項目microCMSWordPress（ヘッドレス）Contentful 管理画面の言語日本語日本語（プラグイン依存）英語（一部日本語化可） API形式RESTREST / GraphQLREST / GraphQL 無料プランの上限3 API、10,000リクエスト/月なし（自前ホスティング費用）1スペース、25,000レコード 月額料金（小規模）4,900円〜（Team）サーバー費 1,000〜5,000円$300〜（Team） 日本語サポートチャット・メールコミュニティ中心英語のみ（Enterprise応相談） セキュリティAPI経由のみ（攻撃面が狭い）プラグイン脆弱性のリスクありAPI経由のみ（攻撃面が狭い） 拡張性Webhook、カスタムフィールドプラグインで自由に拡張App Framework、Webhook 学習コスト低い（UIが直感的）中程度（ヘッドレス運用のノウハウ要）やや高い（英語ドキュメント中心） ## 規模感で選ぶなら——私たちの肌感覚 ### 50ページ以下の小規模サイト：microCMSが圧倒的に楽 コーポレートサイトやサービスサイトで、更新担当がエンジニアでないパターン。microCMSの管理画面は、説明なしで触り始められるくらい直感的だ。無料プランでも十分実用に耐えるし、初期投資を抑えたいならここからスタートするのが現実的だろう。私たちの案件でも、小規模サイトの8割はmicroCMSを採用している。 ### 50〜500ページの中規模サイト：microCMSかWordPressヘッドレス ブログやナレッジベースも併設するメディア混在型のサイト。コンテンツ量が増えてくると、WordPressのエディタの柔軟さが生きる場面もある。ただ、セキュリティ運用の手間まで含めたトータルコストで比べると、microCMSのTeamプランに軍配が上がるケースのほうが多い。WordPressを選ぶなら、プラグインの脆弱性対応を誰が担うか、事前に決めておくこと。 ### 500ページ超の大規模・多言語サイト：Contentfulの出番 海外拠点がある企業、10言語以上のローカライズが必要なグローバルサイト。Contentfulのロケール機能と権限管理の細かさは、この規模で真価を発揮する。ただし年間コストは数百万円単位。費用対効果を冷静に見極めないと、予算だけ消えて運用が回らない——という事態になりかねない。 ## 選定で見落とされがちな3つのこと ### 「触る人」が使えるかどうか 機能が豊富でも、毎日コンテンツを更新するスタッフが戸惑うようでは意味がない。CMS選定のプロセスには、「管理画面のデモを実際の運用担当者に触ってもらう」ステップを必ず入れてほしい。案件で何度も経験しているが、エンジニアの評価と運用担当の評価はしばしば食い違う。 ### 移行コストは見えにくい 既存サイトからの移行では、データ構造の変換やリダイレクト設定など、表に出にくい工数が発生する。WordPressからの移行は特に注意が要る。カスタムフィールドやプラグイン依存の機能をどう再現するかで、見積もりが倍近く変わることもある。事前の棚卸しは省かないでほしい。 ### ロックインのリスク ヘッドレスCMSはAPIでコンテンツを取得する仕組みだから、CMS自体の乗り換えは比較的やりやすい。ただし、画像のURL体系や独自のリッチテキスト形式に深く依存していると、移行時にけっこう手間がかかる。コンテンツ設計の段階でポータビリティを意識しておくと、将来の選択肢が広がる。 ## 結論：「何を一番大事にするか」で答えは変わる 3つのサービスに、絶対的な優劣はない。プロジェクトの条件次第で正解は変わる。判断に迷ったら、以下のシンプルな軸で考えてみてほしい。 - 日本語での運用のしやすさ → microCMS - 既存WordPressの資産を活かしたい → WordPressヘッドレス - グローバル展開・大規模コンテンツ → Contentful 決めきれないなら、microCMSの無料プランで1つAPIを作ってみるのが一番手っ取り早い。触ってみれば、自社に合うかどうかは体感でわかる。 --- # RAGシステムとは？仕組み・活用事例・導入ステップをわかりやすく解説 URL: https://www.pref.co.jp/knowledge/what-is-rag Published: 2026-03-15 Updated: 2026-03-15 Author: 株式会社プリファード Tags: RAG, LLM, ベクトルDB, ナレッジ検索, AI開発 社内ナレッジの検索や問い合わせ対応を劇的に改善するRAG（Retrieval-Augmented Generation）。その仕組みから導入の流れ、注意すべきポイントまで、技術者でなくても理解できるよう解説します。 ## 「ChatGPTに社内のこと聞いても、的外れな答えしか返ってこない」 社内でChatGPTやClaudeを使い始めた企業から、高い確率で出てくる不満がこれだ。当然の話で、LLMはインターネット上の公開情報をもとに学習しているから、自社の就業規則も製品マニュアルも過去の提案書も知らない。一般論は上手に語るけれど、「うちの会社のこと」には答えられない。 RAG（Retrieval-Augmented Generation）は、この弱点をピンポイントで補う技術だ。社内のドキュメントを検索して、関連する情報をLLMに渡してから回答を生成させる。いわば「カンペを渡してから答えてもらう」仕組みで、日本語では「検索拡張生成」と呼ばれることもある。 ## RAGの仕組み——3つのステップで動いている 技術的な細部は省いて、処理の流れだけ掴んでほしい。 - 下準備（インデックス作成）——社内ドキュメントをテキストに変換し、「ベクトル」という数値データにしてデータベースに格納する。最初に一度やれば、あとは新しい文書が追加されるたびに差分を更新するだけだ。 - 検索（Retrieval）——ユーザーの質問もベクトルに変換し、データベースの中から「意味的に近い」文書を引っ張ってくる。キーワード一致ではなく、意味の類似度で探すのがポイント。ここがRAGの「R」にあたる。 - 回答生成（Generation）——見つかった文書を「参考資料」としてLLMに渡し、それを踏まえて回答を作らせる。LLM自身の知識ではなく、渡された社内情報に基づいて答えるから、精度が段違いに上がる。 わかりやすく言えば、「地頭はいいけど社内事情を知らない中途入社の社員」に、必要な資料を手渡してから質問するようなもの。資料なしだと一般論で煙に巻かれるが、資料があれば的確に答えてくれる。 ## なぜ今、RAGが注目されているのか LLMをそのまま業務に使おうとすると、すぐに壁にぶつかる。 - ハルシネーション——知らないことでも、それらしい嘘をつく。業務で使うには危険すぎる - 情報が古い——学習データには期限がある。先月の社内通達なんて当然知らない - 社内データに触れない——非公開の情報にはアクセスする手段がそもそもない RAGは、モデル自体を再学習させることなく、外部データの参照だけでこれらの課題を和らげる。ファインチューニング（モデルの追加学習）という方法もあるが、コストが桁違いに高く、技術的にも重い。RAGのほうが圧倒的に取り回しやすいから、現場では最初の選択肢になっている。 ## どんな場面で使われているのか ### 社内ナレッジの検索 数千ページの社内マニュアルや規程集。従来はキーワードで検索して、ヒットしたPDFを開いて、該当箇所を自力で探していた。RAGを入れれば「出張精算の締め切りはいつ？」と聞くだけで、関連する規程から情報を抜き出して答えてくれる。私たちが支援した製造業のクライアントでは、総務部門への問い合わせが月間40%減った。総務の担当者が「午前中に余裕ができた」と喜んでいたのが印象的だった。 ### カスタマーサポートの一次対応 FAQと製品マニュアルをデータソースにしたRAGチャットボット。よくある質問には24時間即座に答えられるようになり、オペレーターは込み入った案件に集中できる。ただし注意点がある。100%の精度は出ない。「AIの回答で解決しなければ、すぐ人間につなぐ」導線を必ずセットで設計すること。ここを怠ると、ユーザーの不満がかえって増える。 ### 営業チームの資料探し 「A社に去年提案したクラウド移行の見積もり、どこにあったっけ？」。営業担当ならこの手の資料探しに毎週何十分も費やしているはずだ。過去の提案書や見積書をRAGのデータソースにしておけば、質問を投げるだけで数秒で答えが返る。提案の初動が速くなるのは、営業にとって地味にありがたい。 ## 導入の5ステップ ### ステップ1：「何に答えられるようにしたいか」を決める 最初に全社のドキュメントを対象にしようとすると、高確率でつまずく。1部門、できれば1つの業務に絞るところから始めるのが鉄則だ。「総務への問い合わせを減らしたい」「営業の資料検索を速くしたい」——目的が具体的なほど、成果が見えやすくなる。 ### ステップ2：データを整える PDF、Word、社内Wiki、Googleドライブ。フォーマットがバラバラなドキュメントをテキストとして抽出・整形する工程。正直、ここが一番泥臭い。でもデータの質がRAG全体の精度を左右するから、手を抜くと後でツケが回ってくる。古い文書や重複ファイルは、この段階で思い切って除外しておく。 ### ステップ3：ベクトルデータベースを構築する 整形したテキストを埋め込みモデル（Embedding Model）でベクトル化し、Pinecone、Weaviate、pgvectorなどのベクトルDBに格納する。ここで地味に効いてくるのがチャンクサイズ（テキストの分割単位）の設定だ。大きすぎるとノイズが増え、小さすぎると文脈が切れる。正解は案件ごとに違うので、何パターンか試して比較する作業が必要になる。 ### ステップ4：プロトタイプを作って精度を検証する LangChainやLlamaIndexを使えば、プロトタイプの構築自体は数日で終わる。想定される質問を50〜100件用意して、回答の正確さと関連性を評価する。期待した精度に届かなければ、チャンクサイズの調整やプロンプトの書き直しでチューニングしていく。この検証を飛ばして本番に出すと、ユーザーの信頼を最初に失う。 ### ステップ5：本番環境に載せて、運用を回す 精度が確認できたら、SlackやTeamsのボット、あるいは社内Webアプリとして展開する。ただし「リリースして終わり」ではない。新しいドキュメントの追加、ユーザーからのフィードバック反映、回答精度のモニタリング——運用フェーズの体制を事前に決めておくことが、成功と失敗を分ける。 ## 落とし穴——先に知っておいたほうがいいこと - 権限制御の設計を後回しにしない——「役員会議の議事録」を一般社員のRAGが引用してしまった、という事故は実際に起こりうる。誰がどの文書にアクセスできるか、初期段階で決めること - 「何でも答えてくれる」と思わせない——RAGはデータソースにない情報には答えられない。利用者に「できること・できないこと」を最初に伝えておくだけで、無用な失望を防げる - API利用料は従量課金——LLMのAPIコストは使った分だけかかる。利用が増えると月額数万〜数十万円になることもある。事前にシミュレーションしておかないと、経理から怒られる - データベースの鮮度を保つ仕組みが必須——社内文書が更新されたのにベクトルDBが古いままだと、過去の情報を自信満々に回答し続ける。自動更新の仕組みは最初から組み込んでおくべきだ ## RAGは「社内の知恵」に手が届くようにする技術 社内のどこかに答えがあるのに、見つけられない。聞ける人がいない。RAGはこの歯がゆさを解消するための、今もっとも現実的な手段だと思っている。全部のドキュメントをいきなりカバーしようとせず、効果が見えやすい1つの業務から試してみてほしい。小さく始めて、手応えが出てから広げる。そのほうが確実に根づく。 --- # DX推進の第一歩：業務可視化から始める改善プロセス URL: https://www.pref.co.jp/knowledge/dx-first-step Published: 2026-03-10 Updated: 2026-03-10 Author: 株式会社プリファード Tags: DX, 業務改善, 業務可視化, デジタルトランスフォーメーション DX推進の号令はかかるのに、何をすればいいかわからない。その迷路を打破するのが、楽しいツールではなく「業務の見える化」だ。実際の支援現場から考える進め方をまとめました。 ## 「DXやらなきゃ」で止まっている会社に足りないもの 経営会議で「DX推進」という言葉が出ない日はなくなった。けれど実態はどうか。号令はかかるものの、具体的に何をすればいいのか分からず、結局SaaSのカタログを眺めて終わり——私たちが相談を受ける企業の8割がこのパターンです。 原因はシンプルで、今の業務がどう回っているか誰も正確に把握していない。営業部が「30分で終わる」と言っている作業が、経理側では丸1日かかっていたりする。こうした現実を数字とフローで「見える化」しないまま、ツールだけ導入しても空振りに終わります。 ## なぜ業務可視化が先なのか ### どこに手を入れれば一番効くか、見えるようになる ある製造業のクライアントで、受注から出荷までの業務フローを図に起こしたことがあります。すると、月40時間以上が「Excelへの転記作業」に費やされていた。誰も気づいていなかった。フローを描いて初めて、「ここが一番のボトルネックだったのか」と合意が取れたのです。 ### 部門間の「見え方の違い」が解消される 部署が違えば、同じ業務でも見え方が変わります。営業にとっての「簡単な依頼」が、バックオフィスでは3日がかりの手作業だった。こんなギャップは珍しくない。可視化すると全員が同じ地図を見ながら話せるようになるので、「なんであの部署は遅いんだ」という不毛な摩擦が消えていきます。 ### ツール選びで的外れをしなくなる 「とりあえずRPAを入れたけど使われていない」「kintoneを契約したのに定着しなかった」。よく聞く話です。どちらも、解くべき課題を絞らないままツールに飛びついた結果でしょう。業務フローが手元にあれば、「この工程にはワークフローツール、こっちはExcel関数で十分」と判断できるようになります。 ## 業務可視化の進め方——4つのステップ ### ステップ1：スコープをぎゅっと絞る 全社一斉に手をつけると、確実に途中で止まります。「請求書の発行から入金確認まで」のように、始まりと終わりが明確なプロセスを1つだけ選んでください。私たちの経験では、最初の対象は「関係者が5人以内のプロセス」が進めやすいです。 ### ステップ2：ヒアリング＋シャドーイング 担当者に話を聞くだけでは、抜け漏れが出ます。口頭で説明されない「暗黙の手順」が必ずあるからです。可能なら実際の作業を横で見せてもらう。30分のシャドーイングで、インタビューだけでは絶対に出てこなかった手順が3つ4つ見つかります。 ### ステップ3：フロー図に落とし込む MiroやLucidchartが便利ですが、最初はホワイトボードと付箋でも構いません。ツールの見栄えより、関係者全員が「うん、この流れで合ってる」と言える状態にすることが肝心。1回で完成させようとせず、2〜3回のレビューを挟むと精度が上がります。 ### ステップ4：課題マッピングと優先順位 出来上がったフローに、「ここで手戻りが頻発」「この承認待ちで平均2日ロス」といった課題を書き込んでいきます。並べたら、「改善のインパクト」と「実現のしやすさ」の2軸で優先順位をつける。コストをかけずにすぐ直せるものから着手するのが鉄則です。 ## つまずきやすいポイント3つ - 完璧主義の罠——8割の精度で十分です。残り2割は改善を回しながら埋めればいい。可視化だけに3ヶ月かけた挙げ句、現場が飽きてしまったケースを何度か見ています。 - 現場が協力してくれない——「余計な仕事が増える」と思われるのは当然の反応です。「この作業、あなたの負担を減らすためにやっている」と目的を最初にはっきり伝えること。可視化で浮いた時間の具体例を見せると、空気が変わります。 - きれいなフロー図を作って満足——フロー図はゴールではなくスタート地点。壁に貼って終わりにしないでください。次のアクションを1つ、その場で決める習慣をつけるだけで、可視化の投資が回収され始めます。 ## 可視化した課題をDX施策に変換する 洗い出した課題は、3つに分けて考えると動きやすくなります。 - ツール不要で直せるもの——ルールの見直し、Excelテンプレの統一、承認フローの短縮など。案件によっては、ここだけで工数が2割減ることもある。 - 契約済みのSaaSで解決できるもの——Google WorkspaceやSlackの使っていない機能で対応できるケースは意外と多い。新しいツールを増やす前に、今あるものを使い倒す。 - 新規導入が必要なもの——ワークフローシステムやAIツールが必要な領域。ここは費用も時間もかかるので、カテゴリ1・2を進めながら予算確保を並行するのが現実的です。 私たちがDX支援に入る場合も、最初の1〜2週間で業務の棚卸しをします。すると「システム導入なしで片付く課題」が3割近く出てくる。この発見だけでも、可視化をやった甲斐があったと言ってくれるクライアントは少なくありません。 ## 小さく始めて、早く回す DXと聞くと億単位のシステム刷新を想像するかもしれないが、最初の一歩はもっと泥臭い作業だ。業務を書き出し、課題を見つけ、直せるところから直す。この地味なサイクルが、半年後には組織全体の動きを変えていく。 「うちにDXはまだ早い」と思っている会社こそ、業務フローの棚卸しから始めてみてほしい。見える景色が変わる。 --- # SEO対策の基本と2026年の最新トレンド｜押さえるべき7つのポイント URL: https://www.pref.co.jp/knowledge/seo-trends-2026 Published: 2026-03-05 Updated: 2026-03-05 Author: 株式会社プリファード Tags: SEO, テクニカルSEO, コンテンツSEO, E-E-A-T, Core Web Vitals 「SEOはもう終わった」という声も聞くが、実際にはそうではない。変わったのは地形で、歩き方を変えればまだ通用する。2026年の現場で実際に効いている7つのポイントを、率直にまとめました。 ## 「SEOはオワコン」という声に惑わされていないか SNSを眺めていると「SEOはもう終わった」「AI検索の時代だ」という意見が目に入る。正直、私たちもクライアントから「SEOってまだやる意味あるんですか？」と聞かれることが増えました。 結論から言えば、SEOは終わっていない。ただし、やり方を変えないと成果が出にくくなっているのは事実です。AI Overviewの表示拡大、ゼロクリック検索の増加、動画コンテンツの台頭——検索の「地形」が変わった。地形が変われば歩き方も変わる。2026年の現場で実際に効いている7つのポイントを、率直にまとめます。 ## E-E-A-Tの「Experience」が、想像以上に効いている Googleの品質評価ガイドラインで重視されるE-E-A-T（経験・専門性・権威性・信頼性）。この中で、2025年のコアアップデート以降に存在感を増したのが「Experience（経験）」の要素です。 私たちが運用しているクライアントサイトでも、「実際に製品を使ったレビュー」「社内で試した検証結果」を含む記事は順位が安定している。一方、ネット上の情報を再構成しただけの記事は、じわじわと順位を落としている印象が否めません。検索エンジンは「この人、本当にやったことがあるのか？」を見抜こうとしている。 ## AI Overview対策（GEO）は、もう「先進的」ではなく「必須」 Google検索の上部にAIが回答を表示するAI Overview。2026年現在、日本語クエリの約30〜40%で出現するようになりました。ここに自社コンテンツが引用されると、従来の1位表示に匹敵する——場合によってはそれ以上の露出が得られます。 引用されやすい記事にはパターンがあります。 - 見出しの直後に結論が端的に書かれている - 「約300社が導入」のように、数値や固有名詞を含む事実記述がある - FAQ形式の構造化データ（Schema.org）が実装されている - 著者情報・運営企業の情報が明記されている SEOの延長線上にある施策ばかりなので、新たに大きな予算を組む必要はありません。既存記事の書き方を少し変えるだけで、AI Overviewへの露出が増えたケースを私たちも複数確認しています。 ## Core Web Vitalsは「できて当然」の時代になった ページの表示速度やインタラクティブ性を測定するCore Web Vitals。2024〜2025年に多くのサイトが対応を進めた結果、「良好」スコアは差別化要因ではなくなった。ただし「不良」のままだと、はっきり順位に響きます。 とくにモバイルでのLCP（Largest Contentful Paint）2.5秒以内は最低ライン。画像の遅延読み込み、不要なJavaScriptの削減、CDNの活用あたりが未実施なら、コンテンツ施策より先にこちらを片付けたほうがいい。土台が揺らいでいる上にコンテンツを積んでも、効果は半減します。 ## コンテンツは「量」ではなく「他では読めないか」で勝負 生成AIのおかげで、一般的な情報をまとめた記事は誰でも量産できるようになった。当然、そうした記事の検索順位は下がっています。 2026年に上位を取っているのは、独自の調査データ、社内の検証結果、クライアント事例（許可を得た上での公開）など「ここでしか読めない情報」を含む記事です。私たちが支援している不動産系メディアでは、自社で収集した市場データを記事に組み込んだところ、3ヶ月で対象キーワードの平均順位が12位から4位に上がりました。独自性は、もはや差別化ではなく生存条件です。 ## 検索意図を「1ページで全部カバー」は逆効果 「CRM 比較」で検索する人の中には、初めてCRMを知った人も、すでにSalesforceとHubSpotの二択まで絞った人もいます。この両方を1記事で満足させようとすると、どちらにも刺さらない中途半端なページになりがちです。 検索意図ごとにページを分け、内部リンクで回遊させる設計のほうが、結果として個々のページ評価が上がる。「初心者向け概要ページ → 詳細比較ページ → 導入事例ページ」と段階を踏む構成は、ユーザー体験としても自然でしょう。 ## 動画SEOを「おまけ」扱いしていると差をつけられる Google検索結果に動画サムネイルが出る頻度が増えています。ハウツー系やレビュー系のクエリでは、テキスト記事より動画が上位に来ることも珍しくない。 動画SEOで押さえるべきポイントは3つ。 - VideoObjectの構造化データ——Googleが動画の中身を正しく認識できるようになる - テキスト記事と動画を同一ページに配置——テキストの文脈が動画の関連性を補強する - 文字起こしのページ内掲載——動画の内容がインデックスされ、テキスト検索にもヒットする 動画を撮る余裕がなければ、既存のスライド資料をナレーション付きで動画化するだけでも効果は出ます。ゼロから撮影する必要はありません。 ## ローカルSEOは「地味だけど裏切らない」施策 実店舗やエリア限定サービスの企業にとって、ローカルSEOの比重は年々増しています。Googleビジネスプロフィール（旧Googleマイビジネス）の情報を最新に保つのは基本中の基本。口コミへの返信、営業時間の正確な反映、サービスエリアの明示——地道な運用がローカルパックの表示順位に直結します。 月1回、15分もあれば確認できる作業です。にもかかわらず放置している競合は多い。つまり、やるだけで差がつく。 ## 2026年のSEO施策チェックリスト 施策カテゴリ具体的なアクション優先度 コンテンツ独自データ・一次情報を含む記事の拡充高 コンテンツ既存記事へのE-E-A-T要素（著者情報・実体験）追加高 テクニカルCore Web Vitals「良好」の維持確認中 テクニカル構造化データ（FAQ、HowTo、Article）の実装高 GEO対策見出し直下の結論記述・事実ベースの文章構成高 マルチメディア主要ページへの動画埋め込み＋VideoObjectマークアップ中 ローカルSEOGoogleビジネスプロフィールの月次メンテナンス該当企業は高 ## 王道を押さえた上で、新しい打ち手を足していく SEOは「これだけやれば上がる」という単純なゲームではなくなった。けれど、読者にとって価値のあるコンテンツを作り、技術的な基盤を整え、検索意図に丁寧に応える——この王道が揺らぐことはない。 その土台の上にAI Overview対策やマルチメディアSEOを重ねていく。一度に全部やろうとせず、チェックリストで優先度「高」のものから1つずつ手をつけていくのが、結局一番確実な進め方だ。 --- # AIチャットボットの導入判断から運用定着まで｜実際の現場から考える URL: https://www.pref.co.jp/knowledge/ai-chatbot-customer-support Published: 2026-02-28 Updated: 2026-02-28 Author: 株式会社プリファード Tags: AIチャットボット, カスタマーサポート, 業務効率化, 自動化 毎日同じ質問に答え続けるサポート業務。導入判断の基準から、実際に成果を出すための運用のコツまで、案件の実態を交えてまとめました。 ## 「その質問、今日だけで何回答えました？」 サポート担当者なら覚えがあるはずです。「営業時間は何時までですか？」「解約の手続きはどこからですか？」——同じ質問に、今日も同じ文面をコピペして返す。問い合わせ件数が増えれば残業で対応し、休日の問い合わせは月曜の朝まで放置するしかない。 AIチャットボットは、こうした繰り返し作業を引き受けてくれる。ただ、導入すれば勝手にうまく回るわけではありません。成果を出している会社と、入れたのに誰も使わなくなった会社。この差はどこにあるのか。案件で見てきた実感を交えながら書いていきます。 ## AIチャットボットが得意なこと、苦手なこと まず冷静に、向き不向きを整理しておきます。 ### 任せて大丈夫な領域 - 定型FAQ——営業時間、料金、手続き方法など、回答が決まっている質問。ここが一番効果を実感しやすい。 - 深夜・休日の一次対応——「24時間つながる」というだけで、顧客の安心感はかなり変わる。 - 多言語の問い合わせ——LLMベースなら英語・中国語程度は追加コストなしで対応できる。 - 問い合わせの振り分け——内容を判別して適切な担当部署に回す。人手でやると地味に時間を食う作業です。 ### 人間が出るべき領域 - 感情が絡むクレーム——怒っている相手にAIの定型文を返すと、火に油を注ぐことになりかねない。 - FAQにない質問——学習データの外にある内容は、AIが的外れな回答を返すリスクが高い。 - 契約変更や返金処理——本人確認や承認が必要な手続きは、人間の判断が欠かせない。 大事なのは、この境界線を導入前にはっきり決めておくこと。「AIで完結する問い合わせ」と「人間にパスする問い合わせ」の仕分けが曖昧なまま公開すると、顧客体験が中途半端になります。 ## チャットボットの3タイプ——自社に合うのはどれか タイプ仕組み向いているケース月額の目安 シナリオ型事前に設定した選択肢で会話を誘導FAQ50件以下、質問パターンが限られる1〜5万円 AI型（LLMベース）自然言語を理解し、回答を生成FAQが多い、質問の言い回しがバラバラ5〜20万円 ハイブリッド型シナリオ型とAI型の組み合わせ定型と柔軟対応の両方が必要10〜30万円 2026年時点ではLLMの精度向上とコスト低下が進み、AI型やハイブリッド型を選ぶ企業が増えています。ただ、月の問い合わせが100件に満たないなら、シナリオ型で十分というケースも多い。「とりあえず高機能なやつ」ではなく、自社の問い合わせ規模に合った選択を。 ## 成果を出すための5ステップ ### 1. まず問い合わせデータを眺める 過去3〜6ヶ月分の問い合わせ内容を集計してみてください。頻出する質問のトップ20を出すだけでいい。経験上、上位20%の質問が全体の60〜70%を占めていることが多い。この20%をチャットボットに任せるだけで、現場の負荷は目に見えて軽くなります。 ### 2. 「ここまではAI、ここからは人」を明文化する 「3回やり取りしても解決しなければ有人チャットに接続」「個人情報の確認が必要なら電話に切り替え」——こうしたルールを紙に書いて関係者に共有する。ここが曖昧だと、運用が始まってから毎回判断に迷うことになります。 ### 3. FAQデータを「質問と回答のペア」に整形する 既存のFAQページやマニュアルをそのまま食わせても、回答精度は上がりません。「Q: 解約はどうすればいいですか？ → A: マイページの契約管理から手続きできます」のように、1問1答の形に整形し直す。地味で手間のかかる作業ですが、ここを省くと回答がちぐはぐになり、ユーザーの信頼を失います。 ### 4. 社内テストで精度を80%以上に引き上げる 2〜4週間、社内メンバーに実際に使ってもらいます。想定外の質問パターンや誤回答を洗い出し、データを追加・修正していく。回答精度が80%を超えてから外部に公開するのが安全です。70%台で公開すると、「使えないチャットボット」という印象がついてしまい、後から挽回するのが難しい。 ### 5. 公開後こそ本番——週次で改善を回す 公開したら終わりではなく、ここからが勝負。週に1回、「解決できなかった問い合わせ」のログを確認し、FAQの追加やプロンプトの調整を行います。最初の3ヶ月は集中的にメンテナンスする体制を確保しておくこと。この期間を乗り越えると、チャットボットの精度が安定して手離れが良くなっていきます。 ## あるBtoB SaaS企業で起きたこと 私たちが支援したBtoB SaaS企業の例を紹介します。 - 導入前——月間問い合わせ約400件。サポート担当3名がフル稼働で、平均応答時間は4時間。 - 導入3ヶ月後——チャットボットが月250件を自動処理。有人対応は150件に減り、応答時間はAI即時＋有人2時間に短縮。 - 現場の変化——「パスワードリセットの方法」のような定型質問から解放された結果、担当者が複雑な案件にじっくり向き合えるようになった。顧客満足度スコアは8%改善。 数字だけ見ると順調ですが、最初の1ヶ月は回答ミスへの対応で逆に忙しくなったそうです。「導入直後は楽にならない」という覚悟は持っておいたほうがいいでしょう。 ## 導入前に決めておくべき3つのこと - 回答のチェック体制——AIは嘘をつく（ハルシネーション）。週次で回答ログを確認し、誤回答を修正する担当を決めておく。放置すると、間違った案内がそのまま顧客に届き続けるリスクがある。 - 有人への導線——「チャットボットで解決できない」と感じたユーザーが、すぐに人間と話せる仕組みを必ず残す。ここを塞ぐと不満が一気に噴き出します。 - データの取り扱い——チャットログには個人情報が含まれる可能性がある。保存先、保持期間、アクセス権限を事前に設計しておくこと。後から慌てて対応するのは、コストもリスクも大きい。 ## 「毎日来るあの質問」が、導入の起点になる AIチャットボットは万能ではない。けれど、繰り返しの問い合わせ対応に追われている現場にとっては、確かな味方になる。問い合わせデータを分析し、対応範囲を決め、データを整備し、回しながら磨いていく。この手順を踏んだ会社が、結局は一番うまくいっている。 まず、過去1ヶ月の問い合わせ一覧を眺めてみてほしい。「この質問、また来てる」と思うものがあれば、そこがチャットボット導入の入口だ。 --- # LPのCVRが上がらないときに見直すべきポイント URL: https://www.pref.co.jp/knowledge/lp-cvr-improvement Published: 2026-02-20 Updated: 2026-02-20 Author: 株式会社プリファード Tags: LP, ランディングページ, CVR, CRO, コンバージョン最適化 広告費を増やす前に、LPそのものに手を入れる。ファーストビュー、フォーム設計、ABテストの進め方まで、実際の改善事例を交えてまとめました。 ## 広告費だけ膨らんで、成果が追いついていない リスティング広告やSNS広告を回していると、CPA（顧客獲得単価）がじわじわ上がっていく感覚、ありませんか。入札単価の調整やターゲティングの見直しも手ですが、もっと手前に効くポイントがあります。LP（ランディングページ）そのものです。 CVR（コンバージョン率）が1%から2%に改善すれば、同じ流入数でCPAは半分。広告予算を1円も増やさず、成果だけ倍にできる。私たちがLP改善を「一番コスパの良い施策」と呼んでいるのは、この構造があるからです。 ## ファーストビューの3秒で勝負がつく LPに来たユーザーが「戻る」ボタンを押すまで、3〜5秒。この間に「あ、自分に関係あるページだ」と思わせられるかどうかが分かれ目です。どんなに良い情報を下に書いていても、スクロールされなければ存在しないのと同じ。 - キャッチコピーは「悩みの言語化」から——機能やスペックの説明は後でいい。「月末の請求処理、まだ手作業ですか？」のように、ターゲットの頭の中にある言葉をそのまま使う。 - ビジュアルは「使った後の世界」を見せる——製品の画面キャプチャより、サービスを導入した結果どう変わるかを想像させる絵のほうが反応が良い。あるクライアントでは、「作業画面のスクリーンショット」から「笑顔で定時退社するスタッフの写真」に変えただけでCTRが1.4倍になりました。 - CTAボタンはファーストビュー内に——すでに検討が進んでいるユーザーは、すぐ行動したい。スクロールしないとフォームにたどり着けない設計は、それだけで機会損失です。 ## PASONAの法則は「たたき台」にとどめる LP構成のフレームワークとしてよく名前が出るPASONAの法則。Problem → Affinity → Solution → Offer → Narrow down → Actionの順で組み立てる手法です。知っておいて損はないけれど、これを丸ごとなぞると、どのLPも金太郎飴みたいな構成になる。 私たちの現場感覚では、ターゲットが「どこで信頼を感じるか」「何があれば背中を押されるか」は商材ごとに違います。フレームワークで骨組みを作ったら、あとはABテストで自社なりの正解を探る。この試行錯誤を省略して「型通りのLP」を量産しても、成果は頭打ちになります。 ## 「他の人も使っている」は思った以上に効く 人は、他人の行動に影響を受ける。心理学では社会的証明と呼ばれる現象ですが、LPにおけるこの要素のインパクトは大きい。 - 導入実績の数字——「500社以上が導入」「累計利用者10万人突破」。数字は具体的であるほど刺さる。「多数の企業が」ではダメです。 - 顧客の声——実名・顔写真・社名入りがベスト。匿名の感想文と、実在する人物のコメントでは信頼度がまるで違う。ある案件でテスティモニアルを「匿名 → 実名＋顔写真」に変えたところ、CVRが0.3%上がりました。 - メディア掲載ロゴ——業界メディアや全国紙で紹介された実績があれば、ロゴを並べるだけで効果がある。「見たことあるメディアが取り上げている」という安心感は強い。 - 受賞歴・認証——ISO認証や業界賞、官公庁の採用実績も有効。とくにBtoB領域では、稟議を通す側の「裏付け」になります。 ## フォームは「引き算」でCVRが上がる 入力項目が1つ増えるたびにCVRは下がる。これは何十本ものLPを改善してきた実感でもあります。HubSpotの調査では、フォーム項目を11個から4個に減らしてCVRが120%向上したという結果が報告されています。 - 必須は「名前」「メール」「問い合わせ内容」の3つ——電話番号や会社規模はリード獲得後のヒアリングで聞けばいい。最初のハードルは低いほど良い。 - 入力の手間を減らす工夫——郵便番号から住所を自動入力、プルダウンの初期値設定、入力エラーのリアルタイム表示。地味だけど離脱率に直結する。 - ボタンの文言を変える——「送信」「Submit」ではなく、「無料で資料を受け取る」「30秒で完了」。行動した結果や手軽さを伝えるだけで、クリック率が変わります。 - EFOツールの導入——フォーム入力中の離脱ポイントを可視化できる。どの項目でユーザーが詰まっているか分かれば、打ち手が明確になる。 ## ABテスト——「社長の好み」で変えてはいけない LP改善で最も陥りやすい罠。それは、デザイナーや経営者の感性で変更を加えてしまうことです。「こっちの色のほうがいいと思う」——その直感が当たることもあるけれど、外れることも同じくらいある。CVR改善は主観ではなく、データで判断するものです。 ### テストの優先順位 - CTAボタンの文言・色・配置——影響度が一番大きい。ここから始める。 - キャッチコピー——ファーストビューの文言を変えるだけで離脱率が劇的に変わることがある。 - フォームの項目数——削るほどCVRが上がる傾向は明確。 - 社会的証明の配置場所——CTAの直前に置くか、ファーストビュー直下に置くかで効果が変わる。 - ページの長さ——短くすれば良いわけではない。商材の検討期間が長い場合、むしろ長尺LPのほうが効くこともある。 ツールはVWO、AB Tasty、Optimizelyなどが主流。月額数万円から始められるプランもあるので、テストを「たまにやるイベント」ではなく「常時回す仕組み」として社内に定着させたい。 ## モバイルは「対応」ではなく「主戦場」 BtoCなら流入の70〜80%がスマホ経由。BtoBでも40〜50%はモバイルからのアクセスです。PCで見た時に美しいLPでも、スマホで操作しにくければCVRは上がりません。 - ボタンは最低44px×44px。指で確実にタップできるサイズ。 - フォーム入力時にキーボードで画面が隠れないよう配慮する。 - 横スクロールが発生しないレイアウト。テーブルが横にはみ出すLPは意外と多い。 - 画像の容量を絞り、LCPを2.5秒以内に。スマホの回線速度は想像以上にバラつきます。 ## 0.5%の改善を、5回積み重ねる LPのCVR改善に一発逆転の魔法はない。ファーストビューを直し、フォームを削り、ABテストで検証する。1回の改善で上がるのはせいぜい0.3〜0.5%。でも、これを半年で4〜5回繰り返せば、合計で2〜3%のCVR改善になる。広告効率にすると2倍以上だ。 焦ってデザインを全面リニューアルするより、小さな改善を高速で回すほうが結局早い。データを見て、仮説を立てて、テストする。その繰り返しが、LPの成果を押し上げていく。 --- # ISMS認証を取ってわかったこと｜期間・コスト・取得後の実態 URL: https://www.pref.co.jp/knowledge/isms-certification-guide Published: 2026-02-15 Updated: 2026-02-15 Author: 株式会社プリファード Tags: ISMS, ISO27001, 情報セキュリティ, 認証取得 ISMS認証は取るべきか。取得までの期間・コスト・実際に起きた変化を、自社で認証を取得・運用している立場から率直に書きました。 ## 「セキュリティ大丈夫ですか？」にどう答えるか 取引先から「御社のセキュリティ体制を教えてください」と聞かれる場面、増えていませんか。セキュリティチェックシートが送られてきて、社内で回答を集めるだけで半日潰れる——そんな経験をしたことのある方も多いでしょう。 ISMS認証（ISO/IEC 27001）は、「うちの会社は情報セキュリティを組織的に管理しています」と第三者が証明してくれる制度です。個人の心がけではなく、仕組みで守っていることの裏付けになる。当社（プリファード）も取得・運用しているので、その実体験を交えながら書いていきます。 ## 取得して分かった4つのメリット ### 商談がスムーズに進む BtoB領域では、取引開始前にセキュリティ体制の確認を求められるケースが増えました。ISMS認証があると、チェックシートの大半が「認証取得済み」で済む。当社でも取得後、大手企業との契約手続きにかかる時間が明らかに短くなりました。営業担当が「以前は回答に3日かかっていたのが、半日で終わるようになった」と言っていたのが印象的です。 ### 見えていなかったリスクが見える 認証取得のプロセスでリスクアセスメント（リスクの洗い出しと評価）を行うと、想像以上に穴が見つかります。当社の場合、「退職者のクラウドサービスアカウントが数件残っていた」「私用端末からのアクセス制限が不十分だった」といった問題がこの過程で発覚しました。認証を取るかどうかに関わらず、この棚卸し自体に価値があります。 ### 入札・プロポーザルで武器になる 官公庁や自治体の案件、大手企業の調達では、ISMS認証の有無が評価項目に入っていることがあります。必須ではなくても加点対象なら、持っていないよりは持っているほうがいい。競合と僅差で並んだとき、この1点が効いてくる場面は意外とあるものです。 ### 社員のセキュリティ意識が変わる ISMS認証は取得後も年1回の内部監査と定期審査が続きます。正直、面倒です。でもこの繰り返しが、社員のセキュリティ意識を少しずつ底上げしてくれる。「ルールがあるから守る」ではなく「なぜこのルールが必要か分かっている」状態に近づいていく。当社でもフィッシングメールの誤クリック率が取得前に比べて下がりました。 ## 期間とコスト——正直なところ 企業規模やセキュリティの現状によって幅がありますが、目安を表にまとめます。 項目中小企業（〜50名）中堅企業（50〜300名） 準備期間4〜6ヶ月6〜10ヶ月 コンサル費用100〜250万円200〜500万円 審査費用（初回）50〜80万円80〜150万円 維持審査（年次）30〜50万円50〜100万円 「コンサルなしで自力で取れないか？」と考える方もいるでしょう。不可能ではありません。ただ、初めての取得では規格の解釈で迷う場面が多く、手戻りが発生しやすい。当社も初回はコンサルの力を借りました。結果として、自力で試行錯誤するより早く、安く済んだと感じています。 ## 準備の流れ——6つのフェーズ ### フェーズ1：まず「どこまで取るか」を決める（1〜2週間） 認証の適用範囲を定めます。全社を対象にするか、特定の部門や拠点に絞るか。コストと手間のバランスで判断しましょう。最初は顧客データを扱う部門だけに絞って取得し、あとから範囲を広げる企業も多いです。 ### フェーズ2：情報資産の棚卸しとリスク評価（1〜2ヶ月） 顧客データ、契約書、ソースコード、サーバー——組織が持っている情報資産をすべてリストアップし、「何が脅威か」「脆弱性はどこか」「漏れたらどれくらい影響があるか」を評価します。一番時間がかかるフェーズ。ここが認証の土台になるので、手を抜くと後で必ずツケが回ってきます。 ### フェーズ3：ポリシーと管理策を文書化する（1〜2ヶ月） リスク評価の結果をもとに、管理策（対策）を選定し、セキュリティポリシーや各種規程を作ります。ISO 27001の附属書Aには93項目の管理策がリストアップされていますが、全部を適用する必要はない。「この項目は自社に該当しないので適用しない」と判断理由を記録しておけば問題なしです。 ### フェーズ4：運用開始と社員教育（1〜2ヶ月） 作ったルールを実際に回し始め、全社員への教育を行います。e-ラーニングか集合研修が一般的。このフェーズで大事なのは「ルールが現場に合っているか」の確認です。現場から「このルール、業務が止まるんですけど」と声が上がったら、修正のチャンス。無理なルールを押し付けると、守られないだけでなく、ISMS自体への不信感が生まれてしまいます。 ### フェーズ5：内部監査（2〜3週間） ISMSが正しく運用されているか、社内で監査します。監査担当者は対象部門と利害関係のない人が務めるのが原則。社内リソースが足りなければ、外部の監査員に頼むのも手です。 ### フェーズ6：認証審査——本番は2段構え 認証機関による審査はステージ1（ドキュメントレビュー中心）とステージ2（現地審査）の2段階。ステージ2では、実際にルール通りに運用できているかを確認されます。不適合事項が出ても、是正措置を講じて再審査を受ければ大丈夫。「不適合＝不合格」ではないので、過度に恐れる必要はありません。 ## 取得後が本番——運用で気をつけていること 認証を取った後の運用について、当社が実感している注意点を3つ挙げます。 - PDCAを「儀式」にしない——年1回の内部監査と管理レビューは義務ですが、チェックリストを埋めるだけの作業になりがち。「この結果を受けて、来月何を変えるか」まで決めないと、PDCAは回っていないのと同じです。 - 規程と現実のズレを放置しない——リモートワークが増えた、新しいクラウドサービスを導入した。業務環境は日々変わります。半年前に書いた規程が今の運用と合わなくなっていることは珍しくない。四半期に1回、規程を見直す時間を取っています。 - インシデント対応フローを「使える状態」に保つ——「何が起きたら、誰に、どう報告するか」を明確にしておく。年に1回は机上訓練（インシデント発生のシミュレーション）をやると、フローの不備が見つかることがあります。備えていないと、いざという時に被害が広がる。 ## 認証を取ることはゴールではない ISMS認証の取得は、情報セキュリティの到達点ではない。取得の過程で作った仕組みを日々の業務に根づかせ、改善し続けること。それが本来の目的だ。 コストも手間もかかる。それは正直に言う。けれど、取引先の信頼を得たい、インシデントのリスクを下げたい、社員のセキュリティ意識を引き上げたい——そう考えている企業にとっては、十分に見合う投資だと当社は実感している。認証取得を検討しているなら、まずリスクアセスメントだけでも試してみてほしい。それだけでも、自社の現状が見えてくる。 --- # よくある質問（FAQ 全文） / FAQ — full text > Source page: https://www.pref.co.jp/faq ## ご相談・お見積もりについて ### 相談や見積もりに費用はかかりますか？ いいえ、初回のご相談・お見積もりは無料です。プロジェクトの内容をお伺いした上で、最適なご提案をさせていただきます。オンラインでのお打ち合わせも対応しておりますので、お問い合わせください。 ### 相談から契約までの流れを教えてください お問い合わせ → 初回ヒアリング（無料） → ご提案・お見積もり → ご契約 → 開発開始という流れになります。初回ヒアリングからお見積もりまで、通常1〜2週間程度です。 ### 見積もりはどのくらいで届きますか？ 初回ヒアリング後、通常1週間以内にお見積もりをご提出いたします。お急ぎの場合はご相談ください。 ### 小規模な案件でも対応してもらえますか？ はい、小規模な案件から大規模なプロジェクトまで案件ごとに対応しております。「ちょっとした修正」「1ページだけのLP制作」なども承っておりますので、ご相談ください。 ### 具体的な要件が固まっていなくても相談できますか？ もちろんです。「こんなことがしたいけど、どう進めたらいいかわからない」という段階からご相談いただけます。ヒアリングを通じて課題を整理し、ゴールと進め方をご一緒に考えます。 ### 他社との相見積もりでも大丈夫ですか？ はい、相見積もりも歓迎しております。単に金額だけでなく、提案内容や進め方の違いもぜひ比較していただければと思います。 ### オンラインでの打ち合わせに対応していますか？ はい、Google Meet・Zoom・Microsoft Teamsなど主要なオンラインツールに対応しております。全国どこからでもご相談いただけます。対面でのお打ち合わせも可能です。 ## 開発・制作について ### 開発期間はどのくらいですか？ プロジェクトの規模や要件によって異なります。一般的な目安として、LP制作は2〜4週間、コーポレートサイトは1〜2ヶ月、中規模システム開発は3〜6ヶ月程度です。詳細はヒアリング時にご説明いたします。 ### どのような技術を使っていますか？ フロントエンドはReact/Next.js/TypeScript、バックエンドはNode.js/Python/Go、インフラはAWS/GCP/Vercelなどを主に使用しています。プロジェクトの要件に応じて最適な技術を選定いたします。 ### 開発途中での仕様変更は可能ですか？ アジャイル開発を採用しているため、開発途中での仕様変更にも柔軟に対応いたします。ただし、大幅な変更の場合は追加費用や納期の見直しが必要になる場合があります。 ### 自社でメンテナンスできるような形で納品してもらえますか？ はい、可能です。CMSを導入したサイトや、ドキュメント・マニュアルを整備した形での納品など、お客様のご要望に応じて対応いたします。 ### 既存システムの改修やリプレイスも対応していますか？ はい、対応しております。既存システムの調査・分析から、段階的なリプレイス計画の策定、移行作業まで一貫してサポートいたします。 ### スマートフォンアプリの開発もできますか？ はい、iOS・Androidともに対応しています。React NativeやFlutterを使ったクロスプラットフォーム開発にも対応しており、コストを抑えながら両OSに対応したアプリを制作できます。 ### プロジェクトの進捗はどのように確認できますか？ Slack・Chatworkなどのチャットツールでの日常的なやり取りに加え、定期的な進捗報告会を設けています。タスク管理ツールで進行状況をリアルタイムにご確認いただけます。 ### API連携やシステム間のデータ連携は対応していますか？ はい、REST API・GraphQL・Webhookなど各種API連携に対応しております。既存の業務システム、SaaS、外部サービスとのデータ連携もご相談ください。 ## AI・生成AIについて ### AIを導入したいのですが、何から始めればよいですか？ まずは現在の業務課題をお聞かせください。どの業務にAIが活用できるかを分析し、費用対効果の高い導入プランをご提案いたします。初回相談は無料です。 ### ChatGPTやClaudeを業務で使いたいのですが 社内データを活用したカスタムAIチャットボットの開発や、SlackやTeamsとの連携、業務プロセスへの組み込みなど、様々な形でご支援可能です。セキュリティに配慮した形での導入も対応しております。 ### 社内のデータをAIに学習させることはできますか？ はい、RAG（Retrieval-Augmented Generation）という技術を使用して、社内ドキュメントやFAQをAIが参照できるようにすることが可能です。データは外部に送信せず、セキュアに管理できます。 ### AIの導入でどのくらいコスト削減できますか？ 正直に申し上げると、「何%削減できます」と事前にお約束はできません。業務によって差が大きく、当社として検証できる削減率の実測を持っていないためです。代わりに、導入前に「どの作業が何件あり、1件あたり何分かかっているか」を一緒に数えるところから始めます。そこが測れていれば、小さく試した段階で効果を判断できます（効果が見合わなければ、その業務には入れないという判断も含めてお伝えします）。 ### AI導入にはどのくらいの費用がかかりますか？ 料金ページの目安では、AIコンサルティング（業務分析・PoC支援）が30万円〜、AIチャットボット開発が100万円〜、AI業務自動化が200万円〜です。まずは小さく始めて効果を確認してから段階的に拡大するアプローチをおすすめしています。 ### 社内にAIの知識がなくても導入できますか？ はい、問題ありません。AIの選定から導入、運用トレーニングまで一貫してサポートいたします。専門的な知識がなくても使いこなせるよう、マニュアル整備や社内研修もお任せください。 ### AIが間違った回答をした場合のリスク管理はどうしていますか？ AIの出力には必ず人間によるレビュープロセスを設計に組み込みます。また、回答の確信度を表示する仕組みや、誤りを検知して修正するフィードバックループの構築もご支援しています。 ### 既存の業務システムとAIを連携させることはできますか？ はい、可能です。既存のCRM、ERP、グループウェアなどとAPI連携し、AIを組み込んだワークフローを構築できます。現在お使いのシステム環境をお聞かせいただければ、具体的なご提案が可能です。 ### データのプライバシーやセキュリティは大丈夫ですか？ ISMS認証を取得した当社の管理体制のもとで運用いたします。Azure OpenAI ServiceやAWS Bedrockなど、データが学習に使用されないエンタープライズ向けAIサービスの活用も可能です。 ### AIを使った議事録の自動作成やドキュメント生成は可能ですか？ はい、音声認識と生成AIを組み合わせた議事録の自動作成や、テンプレートに基づく報告書・提案書の生成に対応しています。効きやすいのは「件数が多く、手順は決まっているが、途中に判断や調べ物が挟まる業務」です。逆に、月に数件しか発生しない業務や、毎回やり方が変わる業務は、作っても使われないことが多いので正直にお伝えします。 ## 料金・お支払いについて ### 料金の支払い方法は？ 銀行振込（請求書払い）が基本となります。クレジットカード払いや分割払いについてはご相談ください。 ### 料金はいつ支払うのですか？ 基本的に、契約時に着手金として50%、納品・検収完了時に残り50%をお支払いいただく形となります。月額契約の場合は毎月末締め翌月末払いとなります。 ### 追加費用が発生することはありますか？ 当初の仕様から大幅な変更・追加がある場合は、追加費用が発生することがあります。その場合は事前にお見積もりをご提示し、ご承諾いただいてから作業を進めます。 ### 予算が限られているのですが相談できますか？ はい、ご予算に応じた提案も可能です。優先度の高い機能から段階的に開発するアプローチなど、柔軟にご対応いたします。 ### 月額の保守費用はどのくらいですか？ 対応範囲によって異なりますが、月額5万円〜が目安です。監視・軽微な修正・メールサポートを含むスタンダードと、24時間の自動監視とアラート通知や機能追加（月10時間まで）・緊急対応を含むPro（月額15万円〜）をご用意しています。詳しくは料金ページをご覧ください。 ### 助成金や補助金の利用は可能ですか？ IT導入補助金やものづくり補助金など、対象となる助成金制度がいくつかあります。申請のサポートも可能ですので、詳しくはご相談ください。 ## 納品・運用について ### 納品後のサポートはありますか？ はい、納品後も保守・運用サポートプランをご用意しております。軽微な修正対応、システム監視、機能追加など、継続的にサポートいたします。 ### サーバーやドメインの管理もお願いできますか？ はい、ホスティング・ドメイン管理も代行可能です。既にお持ちのサーバーやドメインをそのまま利用することも、新規に取得・設定することも可能です。 ### セキュリティ対策は大丈夫ですか？ 当社はISMS（ISO27001）認証を取得しており、情報セキュリティに配慮した開発・運用を行っております。SSL対応、脆弱性対策、定期的なセキュリティアップデートなど、適切なセキュリティ対策を実施いたします。 ### 他社で制作したサイトやシステムの保守もお願いできますか？ はい、可能な場合があります。まずは現状を調査させていただき、保守対応可能かどうかを判断いたします。調査は有料となる場合がありますが、保守契約いただける場合は調査費用を相殺いたします。 ### システム障害が発生した場合の対応体制はどうなっていますか？ 保守契約をいただいているお客様には、障害発生時の緊急連絡窓口を設けています。障害の切り分け・復旧対応を迅速に行い、原因分析と再発防止策までフォローいたします。 ### ソースコードや成果物の著作権はどうなりますか？ 原則として、納品後のソースコードや成果物の著作権はお客様に帰属します。契約書に明記いたしますので、安心してお任せください。 ## その他 ### 遠方でも依頼できますか？ はい、オンラインでのお打ち合わせを基本としておりますので、全国どこからでもご依頼いただけます。必要に応じて対面でのお打ち合わせも可能です。 ### NDA（秘密保持契約）は締結できますか？ はい、ご要望に応じてNDAを締結いたします。初回のご相談前に締結することも可能です。 ### どのような企業と取引実績がありますか？ 創業期のスタートアップから上場企業まで、幅広くお取引しています。出前館、ファンコミュニケーションズ、Paygent、NOLTYプランナーズ、プロシーズ、アイカサ、Lime、microCMS など、フードデリバリー・インターネット広告・決済・教育・シェアリング・CMSと業種は多岐にわたります。公開中のプロジェクトは実績ページに掲載しています。 ### 土日や夜間の対応は可能ですか？ 基本的な対応は平日9:00〜18:00となりますが、緊急時の対応やプロジェクトの状況に応じて柔軟に対応いたします。保守契約をいただいている場合は、24時間の自動監視とアラート通知で障害を検知し、緊急時のご連絡先をお伝えしています。 ### プリファードさんはどんな会社ですか？ 2022年設立、東京・新宿に本社を置くIT会社です。システム開発や生成AIの実装、Web制作などを手がけつつ、自社でカフェ（Slow Rush Coffee）や不動産も運営しています。「作る側」と「使う側」の両方に立つことが、翌日も使われる形を優先する理由です。 ### 採用は行っていますか？ はい、エンジニア・営業職・インターンを随時募集しています。詳しくは採用ページをご覧ください。カジュアル面談からでもどうぞ。 ## DXコンサルティングについて ### DXとは何ですか？なぜ必要なのでしょうか？ DX（デジタルトランスフォーメーション）とは、デジタル技術を活用してビジネスのあり方や業務プロセスを根本的に変革することです。競争力の維持、業務効率化、新たな顧客体験の創出のために、業種を問わず取り組みが求められています。 ### DXの進め方がわからないのですが、どこから始めればいいですか？ まずは現状の業務フローの可視化から始めます。どこにムダがあり、どの部分をデジタル化すれば効果が高いかを一緒に整理しましょう。段階的に進めるロードマップもご提案いたします。 ### 社内にIT人材がいませんが、DX推進は可能ですか？ はい、お客様の社内にIT担当がいなくても進められるよう、一緒に進めます。ツール選定から導入、運用トレーニングまで一貫してサポートいたしますので、ご安心ください。 ### DXコンサルティングの費用感を教えてください スポットでの業務診断は30万円〜、中長期の支援は月額20万円〜が目安です。お客様の課題の範囲や支援内容によって変動しますので、まずはヒアリングさせてください。 ### 業務改善だけでなく、新規事業の立ち上げ支援もできますか？ はい、対応しております。市場調査からビジネスモデルの設計、MVP開発、リリース後の改善まで一貫してご支援可能です。自社でカフェ・不動産事業を立ち上げた経験もありますので、リアルな知見をお伝えできます。 ### DXの成果はどのくらいで出ますか？ 小さな業務改善であれば1〜2ヶ月で効果を実感いただけるケースもあります。全社的な変革には半年〜1年程度のスパンで段階的に取り組むことが多いです。まずはクイックウィンを積み重ねることを重視しています。 ## Web制作・ECサイトについて ### コーポレートサイトのリニューアルを検討していますが、対応できますか？ はい、コーポレートサイトのリニューアルは得意分野の一つです。デザイン・設計から実装、SEO対策、公開後の運用まで一貫してお任せいただけます。 ### WordPressでの制作も対応していますか？ はい、WordPressでの制作・改修も対応しています。加えて、Next.jsとヘッドレスCMS（microCMS など）を組み合わせたJamstack構成もご提案可能です。当社はmicroCMSの公式パートナーで、自社サイトもNext.js＋microCMSで構築・運用しています。更新頻度や運用体制に合わせてどちらが向くかをお伝えします。 ### ECサイトを立ち上げたいのですが Shopifyを使った構築を中心に、カスタムEC開発にも対応しています。商品管理、決済、在庫連携、配送手配まで、EC運営に必要な機能をまとめてご支援できます。自社でEC事業を運営している経験も活かしてアドバイスいたします。 ### SEOに強いサイトを作ってもらえますか？ はい、SEOを考慮したサイト設計を標準で行っています。構造化データの実装、表示速度の最適化、適切なメタ情報の設定など、テクニカルSEOからコンテンツSEOまで包括的にサポートいたします。 ### 制作後のコンテンツ更新は自分たちでできますか？ はい、CMS（microCMS、WordPressなど）を導入することで、専門知識がなくてもブログやお知らせの更新が簡単に行えます。操作マニュアルの整備や初期トレーニングも含めてご提供いたします。 ### 多言語対応のサイトは制作できますか？ はい、日本語・英語の多言語サイトを制作しています。当社サイト自体も next-intl による日英対応で構築・運用しており、URL設計（/ja・/en）、hreflang、翻訳運用まで含めた設計をそのままご提案できます。 ## マーケティング支援について ### SEO対策だけでも依頼できますか？ はい、SEO対策のみのご依頼も承っております。サイトの技術的なSEO改善、キーワード分析、コンテンツ戦略の策定など、課題に応じたプランをご提案いたします。 ### 広告運用の代行はしていますか？ はい、Google広告・Yahoo!広告・SNS広告（Meta、X、LINE）の運用代行に対応しています。戦略設計から出稿、効果測定、改善レポートまで一貫してお任せいただけます。 ### SNS運用の支援はどのような内容ですか？ 投稿企画・コンテンツ制作・スケジュール管理・効果分析まで幅広くサポートいたします。Instagram、X（旧Twitter）、LINEなど、お客様のターゲットに合わせたプラットフォームをご提案します。 ### マーケティングの成果はどのように測定しますか？ Google Analyticsやサーチコンソール、広告管理ツールなどを活用し、アクセス数・コンバージョン率・費用対効果を定量的にレポートいたします。月次の振り返りミーティングで改善策もご提案します。 ### MEO対策（Googleマップ最適化）もお願いできますか？ はい、Googleビジネスプロフィールの最適化やクチコミ対策、ローカルSEO施策に対応しています。実店舗をお持ちの事業者様には特に効果的ですので、ご相談ください。 ## セキュリティ・ISMSについて ### ISMS認証を取得しているとのことですが、具体的にどのような管理体制ですか？ ISO27001に基づいた情報セキュリティマネジメントシステムを運用しています。社員教育、アクセス管理、データの暗号化、定期的な内部監査など、組織全体で情報資産を保護する体制を構築しています。 ### 機密情報を扱うプロジェクトでも安心して任せられますか？ はい、金融機関や医療関連のお客様ともお取引がございます。NDAの締結はもちろん、プロジェクトごとにアクセス権限の管理や、専用のセキュアな開発環境の構築も対応いたします。 ### 自社でISMS認証を取得したいのですが、支援してもらえますか？ はい、ISMS認証の取得支援サービスを提供しています。規程の策定、リスクアセスメント、社内教育、審査対応まで一貫してサポートいたします。自社で取得した経験を活かし、無理のないスケジュールで進めます。 ### 開発時のセキュリティ対策として具体的に何をしていますか？ セキュアコーディングの遵守、脆弱性診断ツールの導入、コードレビュー時のセキュリティチェック、SSL/TLS対応、定期的なパッチ適用などを標準で実施しています。OWASP Top 10への対策も網羅しています。 ### 個人情報の取り扱いについて教えてください 個人情報保護法およびISMS基準に基づき、厳格に管理しています。利用目的の明確化、必要最小限の取得、暗号化通信、アクセスログの管理など、お客様と利用者のデータを適切に保護いたします。 ## 研修・教育について ### AI駆動開発（FDE）研修とはどのような内容ですか？ AI（主にChatGPTやClaude）を活用してソフトウェア開発を加速させる手法を学ぶ実践型の研修です。プロンプトエンジニアリング、AIペアプログラミング、コードレビューへのAI活用など、現場ですぐ使えるスキルを身につけます。 ### 非エンジニア向けのIT研修もありますか？ はい、営業職や管理部門向けにITリテラシー研修やAIの基礎研修もご用意しています。「AIとは何か」「業務にどう活かせるか」を実例を交えてわかりやすくお伝えします。 ### eラーニングコンテンツの制作を依頼できますか？ はい、お客様の業務内容に合わせたオリジナルのeラーニングコンテンツを制作いたします。動画教材、インタラクティブ教材、テスト付きコースなど、学習効果の高いコンテンツを設計・開発します。 ### 研修はオンラインでも受講可能ですか？ はい、対面・オンラインどちらにも対応しています。録画配信やeラーニング化して、受講者が自分のペースで学べる形式にすることも可能です。 ### 社員のDXリテラシーを底上げしたいのですが DX人材育成プログラムをご用意しています。経営層向け・管理職向け・現場担当者向けなど、階層別にカリキュラムをカスタマイズできます。ワークショップ形式で自社の課題に取り組むことで、研修後すぐに実践に移せます。 ## AI検索（AIO・LLMO）について ### LLMO・AIOとは何ですか？SEOとどう違いますか？ LLMO（AIO）は、ChatGPT・Gemini・Claudeなどの生成AIやAI検索に、自社や商品を正しく認識してもらい、適切に紹介されるための取り組みです。検索順位を上げるSEOに対して、LLMOは「AIの回答のなかで候補として挙げてもらえるか」を扱います。成果につながりやすいのは、単に情報源として引用されることよりも、選択肢として推奨されることです。 ### ChatGPTやGeminiで自社がどう紹介されているか、確認できますか？ はい。実際に想定される質問（「〇〇に強い開発会社は？」「A社の評判は？」など）をAIに投げて、自社が候補に挙がるか・どう説明されているかを記録します。実態とズレた説明をされている場合は、その原因になっている自社サイトの表現を特定して直します。この確認はご相談の初回でも簡単に実施できます。 ### AI検索の効果はどうやって測るのですか？ AI検索の影響を単一の指標で完全に測ることはできません。そのため複数の指標を組み合わせて判断します。具体的には、お問い合わせフォームの認知経路アンケートで「AIの回答経由」の割合、社名・サービス名の指名検索数、想定プロンプトでの推奨率（候補に挙がる割合）、AIの説明が実態とどの程度一致しているか、などです。当社サイトのお問い合わせフォームでも実際にこの認知経路を伺っています。 ### AI検索対策は何から始めればよいですか？ まずは、お客様が疑問に思いそうなことを先回りしてサイト上で答えることです。想定質問を20〜30個書き出して回答を用意するだけでも十分な一歩目になります。次に、「専門性があります」のような曖昧な表現を、社数・年数・対応業種・対応範囲といった具体的な事実に書き換えます。AIは具体的に書かれていることしか正しく引用できません。 ### CMSやコンテンツの持ち方はAI検索に影響しますか？ 影響します。情報が項目ごとに構造化されていれば、AIが参照しやすく、社内でも同じ情報をAIの参照元（RAG）として再利用できます。当社はmicroCMSの公式パートナーとして、この構造設計から運用の自動化までを支援しています。逆に、古い情報が放置されているサイトは、検索エンジンの評価だけでなくAIの説明の正確さも落ちます。 ### llms.txt や構造化データ（JSON-LD）は必要ですか？ AIやクローラーがサイトの中身を機械的に読める状態にするための土台なので、用意しておく価値があります。当社サイトでも llms.txt とページごとの構造化データを公開しています。ただし、これらは「読み取りやすくする」ための整備であって、書かれている内容が具体的でなければ効果は出ません。中身の具体化と合わせて進めます。 ## 他社比較・ご発注前の不安について ### 他社と比べたときのプリファードの違いは何ですか？ 3つあります。1つ目は、設計から開発・運用までを同じチームで持つこと（工程ごとに担当会社が変わりません）。2つ目は、自社でもカフェ・不動産・EC・プロダクトを運営しているため、作る側と使う側の両方の視点で判断できること。3つ目は、生成AIの実装とコンテンツ運用（microCMS公式パートナー）を掛け合わせられることです。ISO/IEC 27001（ISMS）認証も取得済みです。 ### どのくらいの規模の会社が依頼していますか？ 創業期のスタートアップから上場企業まで、幅広くお取引しています。出前館、ファンコミュニケーションズ、Paygent、NOLTYプランナーズ、アイカサ、microCMS など、業種も規模もさまざまです。数十万円規模の小さな改修から、複数年にわたる開発・運用まで対応しています。「小さすぎて頼めない」「大きすぎて任せられない」のどちらも気にしていただく必要はありません。 ### 実際に手を動かすのは誰ですか？下請けに丸投げされませんか？ 当社のメンバーが設計から実装まで担当します。ご相談を受けた担当者がそのままプロジェクトに入るため、途中で認識が抜け落ちることがありません。専門領域によって外部の協力者に入ってもらう場合も、体制はご契約前に開示し、当社が責任を持って進行管理します。 ### まず小さく試してから判断できますか？ はい。生成AIや新しい仕組みの導入は、いきなり全社展開せず、対象業務を1つに絞って小さく試すことを推奨しています。効果が確認できたら範囲を広げ、見合わなければそこで止める判断ができます。この進め方自体もご相談の段階で一緒に設計します。 ### 相談した後に断っても大丈夫ですか？営業の連絡が続きませんか？ もちろん問題ありません。ご相談・お見積もりは無料で、その後に追いかけの営業連絡をすることはありません。他社との相見積もりも歓迎です。社内検討用に、進め方の選択肢や概算だけをお渡しするご利用も実際に多くあります。 ### 契約形態はどうなりますか？ 要件と成果物が固まっている開発は請負契約、要件を整理しながら継続的に進める支援・運用は準委任契約（月額）を基本としています。どちらが適しているかは、ヒアリング後にご提案時にお伝えします。NDA（秘密保持契約）は、ご相談の段階から締結可能です。 ### プロジェクトを途中で止めることはできますか？ できます。契約は工程ごとに区切ることを基本にしていて、次の工程に進むかはその都度ご判断いただけます。止める場合は、そこまでに完了した分のご精算と、作ったもの（コード・設計資料・アカウント）の引き渡しを行います。「一度始めたら最後まで払い続けないといけない」形にはしません。 ### 不具合が見つかった場合はどうなりますか？ 納品後の一定期間（契約で定めます。通常は3ヶ月）は、こちらの実装に起因する不具合を無償で修正します。仕様の変更やご要望の追加は別途お見積もりになりますが、どちらに当たるかで揉めないよう、受け入れ条件を着手前に文書で決めておきます。 ### 作業を外部に再委託することはありますか？ 設計と実装の主要部分は当社のメンバーが担当します。専門領域（意匠デザイン・特殊な技術領域など）で外部の協力者に入っていただく場合は、ご契約前に体制を開示し、同意をいただいてからにします。秘密保持は当社と同等の条件を再委託先にも課します。 ## 情シス代行・IT運用について ### 情シス代行（Preferred IT）はどんなサービスですか。 情シス専任を置いていない会社の情報システム部門を、月額で引き受けるサービスです。Google Workspace・Slack・GitHub などのアカウント管理と入退社対応、SaaS と生成AIの台帳づくり、セキュリティ設定の点検、IT問い合わせの窓口までを担当します。30〜300名の会社を想定しています。 ### 料金はいくらですか。 Standard が月20万円（〜30名）、Growth が月40万円（〜100名）、Enterprise が月80万円〜（100〜300名）です。いずれも税抜・最低契約期間6ヶ月で、初月にオンボーディング（棚卸しと初期整備）として50万円〜をいただきます（12ヶ月契約の場合は無償）。 ### 月5万円程度の情シス代行と比べて高いのはなぜですか。 弊社の標準単価は人日64,000円（時間単価8,000円）です。月5万円は約6時間分にあたり、30名規模の入退社対応・棚卸し・問い合わせ対応を賄える工数ではありません。安く受けて対応が滞るより、必要な工数を確保できる金額でお出ししています。月20万円は月3人日にあたります。 ### 情シスを1人採用するのと比べてどうですか。 正社員1人の採用は、社会保険料の会社負担などを含めて月50〜100万円程度かかり、採用に3〜6ヶ月を要します。Standard はその1/3〜1/5で、契約から2週間で稼働を開始します。ただし常駐はできないため、毎日社内に人がいる必要がある場合は採用のほうが適しています。 ### 生成AIの利用管理（AIガバナンス）もお願いできますか。 オプション（月15万円）で承ります。社内で使われている ChatGPT・Claude・Gemini・Copilot などの棚卸し、利用申請の受付、機密情報・個人情報の取り扱い可否の判定、規約変更の追跡を行います。 ### 既存の情シス担当者やベンダーがいても依頼できますか。 はい。Enterprise はむしろ情シス担当がいる会社向けです。既存ベンダーとの役割分担は契約前に整理し、重複する範囲があればその分を外した金額でお出しします。 ### 対応時間と対応スピードを教えてください。 平日10:00〜19:00です。問い合わせは原則として当日中、遅くとも翌営業日に一次回答します。24時間365日の監視が必要な場合は、対象システムを限定したうえで個別にお見積もりします。 ## 介護施設向けAIコミュニティ ### 生産性向上委員会は、どの介護サービスで義務になりますか。 2024年度の介護報酬改定で、施設系・短期入所系・居住系・多機能系のサービスに委員会の設置が求められ、経過措置は2027年3月31日までです。2027年4月からは設置が運営基準上の義務になります。訪問系・通所系は2026年10月時点で義務の対象外です。ご自身の事業所の扱いは、最新の通知と指定権者にご確認ください。 ### 加算は取れるようになりますか。 3か月に1回以上の委員会の開催は、生産性向上推進体制加算の要件の一つです。ただし加算（Ⅰ）・（Ⅱ）には機器の導入やデータの提出などの要件もあり、取得をお約束するものではありません。委員会の記録を、加算の実績報告に使える形で整えるところまでをお手伝いします。 ### 利用者さまの個人情報をAIに入力して大丈夫ですか。 氏名・住所・生年月日・病名は入力しない運用を前提にしています。テンプレートは「Aさん」「80代女性」のように置き換えて使う作りで、利用規程のひな形もお渡しします。使うAIは、入力内容が学習に使われない法人向けの設定に限ることをおすすめしています。 ### ケアプランもAIで作れますか。 AIが出すのは下書きまでです。ケアプランは介護支援専門員の、医療的な判断は看護職の業務なので、最終的な判断は必ず専門職が行う前提にしています。 ### 最低契約期間はありますか。 委員会は四半期ごとに回るため、スタンダード以上は6か月からのご契約をお願いしています。ライトは1か月単位で解約できます。 ### 研修の助成金と組み合わせられますか。 職員の方向けの研修は、人材開発支援助成金の対象になる形で別途ご提供できます。ただしコミュニティは研修とは別のご契約で、研修の特典として無償でお付けすることはしていません。研修費を実質的に値引きしたとみなされ、助成金の要件に触れるおそれがあるためです。 ### お試しはできますか。 2026年11月から、試行に参加いただける事業所を10か所募集し、3か月無償でお使いいただく予定です。ご関心があればお問い合わせください。 ## 社内専用AI環境 ### Microsoft Copilot や ChatGPT の法人プランとは何が違いますか。 法人プランは1人あたりの月額で契約するため、使う人と使わない人の差が費用に反映されません。また社内のCRMや独自システムにつなぐには、上位版や別のツールが必要になることが多くあります。社内専用AI環境は使った分だけの料金で、つなぐ先も御社に合わせて決められます。すでに法人プランをお使いの場合は、併用する前提で設計することもできます。 ### データは社外に出ませんか。 画面とログは御社の管理する環境に置きます。AIの回答を作るために質問内容はAIの提供会社へ送られますが、入力内容が学習に使われない法人向けの契約・設定でつなぎます。どのデータをどこまで扱ってよいかは、試行の前に社内ガイドラインと照らして決めます。 ### 費用はどのくらいかかりますか。 構築は、つなぐツールの数とセキュリティの要件で変わるため、個別にお見積もりします。10名ほどの試行から始める場合が多く、大きな初期投資にはなりません。利用料はAIの提供会社への従量課金で、御社から直接お支払いいただく形にもできます。 ### どのツールにつなげますか。 MCPの公式の接続が提供されているツール（CRM・グループウェア・タスク管理など）は、そのまま使えることが多いです。公式の接続が無くてもAPIが公開されていれば作ることができます。まずはご利用中のツールをお知らせください。 ### AIが勝手にデータを書き換えることはありませんか。 試行は読み取り専用の権限で行います。書き込みが必要になった場合も、操作できる範囲を絞った専用の権限を用意し、管理側で制限をかけます。 ### 社員が使えるようになるか不安です。 試行の間は週ごとに使い方を共有し、うまく使えている人のやり方を他の人に広げます。業務に合わせた研修を別途ご用意することもできます。 ## SCHOODA（学校食堂の事前注文） ### どの決済方法に対応していますか。 PayPayとクレジットカードに対応しています。カード番号は当社のサーバーでは受け取らず、決済代行会社の決済ページで入力していただく仕組みです。 ### 生徒はアプリをインストールする必要がありますか。 いいえ。スマートフォンのブラウザで使うWebアプリなので、アプリストアからのインストールは要りません。 ### アレルギーのある生徒への配慮はありますか。 メニューごとにアレルゲンを表示しています。生徒が自分のアレルギーを登録すると、該当するメニューに注意の表示が出て、一覧から外すこともできます。表示の元になるアレルゲン情報は、食堂側がメニューの登録時に入力します。 ### 注文を取り消すことはできますか。 決済の直後（30秒以内）であれば、生徒がその場で取り消せます。それ以降は生徒がキャンセルを申請し、食堂側が承認または却下します。承認すると返金と在庫の戻しが自動で行われます。 ### 食堂の運営会社への売上の精算はどうなりますか。 月ごとに、決済手数料を差し引いた振込明細を自動で作成します。精算のための集計を手作業で行う必要はありません。 ### 料金はいくらですか。 学校の規模や運用の形によって変わるため、個別にお見積もりします。お問い合わせフォームからご相談ください。 ### 複数の学校や食堂で使えますか。 はい。1つのシステムで複数の学校を運用できる構成で、学校ごとにURL・ロゴなどの表示・メニュー・営業時間を分けて設定できます。 ## FDE型の開発支援 ### FDEとSES（エンジニアの常駐・派遣）は何が違いますか。 SESは決まった作業を工数で引き受ける形です。FDEは「何を作るか」を決めるところから入り、作ったものが業務で使われているかまで見ます。契約は準委任が多いため形は似ていますが、受け持つ範囲が違います。なお準委任では御社から当社のエンジニアへ直接の作業指示はできないため、指示は当社の責任者を通す形にします。 ### 要件が決まっていなくても頼めますか。 はい。最初の2週間ほどで、解く課題・KPI・最初に検証することを一緒に決めます。要件が固まっていない段階のご相談が、FDEにいちばん向いています。 ### 契約形態はどう決めますか。 要件が動く継続開発は準委任（履行割合型）、PoCやMVPのように段階ごとにゴールを置けるものは準委任（成果完成型）、要件と成果物が固まったものは請負を基本にしています。途中で切り替えることもできます。どれが合うかは、課題整理のあとでご提案します。 ### 今の開発会社がいても頼めますか。 はい。既存の開発会社の置き換えを前提にはしていません。まず役割分担を整理し、当社は設計・検証・判断材料づくりなど足りない部分を受け持つ形からでも始められます。 ### 常駐してもらえますか。 オンラインでの参加を基本に、ヒアリングや定例など対面が要る場面では訪問します。常駐が必要な場合は、期間と頻度をうかがったうえで個別にご相談させてください。 ### 費用はどのくらいかかりますか。 最初の課題整理は30万円〜（2週間ほど）です。その後は、週に何日分入るかで月額をお見積もりします。PoCなど区切りのある段階は、成果に対してお支払いいただく形（成果完成型）にもできます。