AI検索に拾われるFAQを、RAGと人の確認で育てる物語

朝の光が、灯台商会のサポート窓口に差し込んでいた。キーボードをたたく音と、コピー機の低い音が、まだ静かな部屋に重なっている。

Web担当の紬は、届いたばかりの問い合わせを開いた。画面には「返品の手続きはどうすればいいですか」とあったので、AI検索に同じ質問を入力した。返ってきた答えには、何年も前に書かれた「返品について」という短い案内が表示されていた。

「どうして、今のページを見つけてくれないのかな」

紬は自社サイトのFAQ一覧を開いた。そこには「料金」「登録」「返品」「配送」という言葉が、青いカードに一つずつ並んでいた。けれど、お客さまが口にする質問の形にはなっていない。

そのとき、隣の席から佐伯さんが椅子を寄せた。佐伯さんはサポート経験が長く、問い合わせの声を聞くと、画面の向こうで困っている人の様子まで思い浮かべる人だった。

「返品のページは、ちゃんとあるのにね」

「置いてあるだけでは、探す側には見つけにくいんだ。お客さまは『返品』と一語だけで聞くとは限らないからね」

佐伯さんは、先週の電話メモを開いた。そこには「届いた商品を返したい」「箱を開けたけれど返品できる？」「返品の送料は誰が払うの？」と、似ているようで少しずつ違う言葉が残っていた。

「検索する人は、会社の分類名ではなく、自分の困りごとをそのまま入力するんだよ。だからFAQも、『返品について』ではなく、『灯台商会の商品は、どのような条件で返品できますか？』のように書くと、質問と答えの関係が見えやすくなる」

紬は青いカードを一枚、机の上に置いた。カードの表に「返品」と書き、裏に「届いた商品を返品したいのですが、手続きはどうすればいいですか」と書き直した。すると、電話メモの声が、少し近くに聞こえた。

「『料金と納期と解約について教えてください』という質問は、どうするんですか？」

「一つの質問に、一つのテーマだね。料金、納期、解約に分ける。答えを探す人にも、AIにも、そのほうが迷いにくい」

紬はFAQの入力画面を三つに分けた。質問はお客さまが話した言葉に近づけ、回答は最初の一文で結論を伝える。その後ろに、条件、手順、確認日、詳しいページへのリンクを添える形にした。

佐伯さんは、Microsoft Copilot Studioの画面を開いた。そこには、DataverseやSharePointにある情報を、回答の材料として登録する場所があった。

「ここで使うRAGは、難しい名前だけれど、やっていることはシンプルだよ。まず質問に関係する資料を探す。次に、その資料をもとに答えを作る。だから、元の規定やマニュアルが古ければ、答えも古くなってしまう」

「AIが覚え直すのを待つのではなく、探しに行く資料を更新するんですね」

「そう。Power Pagesの公開FAQを対象にするのか、社内のSharePointまで対象にするのかも決める。社内だけの情報や、お客さまの個人情報が、公開ページの答えに混ざらないようにするためだよ」

紬は、公開FAQ、商品マニュアル、返品規定の三つを並べた。古い返品規定には赤い付箋を貼り、最新版の保存場所と更新日を確認した。FAQの回答には、社内規定に書かれた条件だけを使い、推測で補わないことにした。

「ページの見た目だけでなく、検索エンジンに意味を伝える方法もありますよね。FAQPageやJSON-LDは、入れたほうがいいですか？」

佐伯さんは、紬のノートに小さな四角を描いた。

「FAQPageは、ここが質問と回答のページだと伝える目印だね。JSON-LDは、その関係を機械が読める形で書く方法。ただし、構造化データだけを置けばよいわけではない。ページに見えている質問と回答と、同じ内容にすることが大切だよ」

紬は質問を見出しにした。回答を折りたたまず、ページ上で読めるようにした。JSON-LDの回答文も、画面に表示する文章と一字ずつ照らし合わせた。

昼前、二人はAI検索で確認する質問を紙に書いた。「灯台商会の商品は、どのような条件で返品できますか」「返品の手続きには何が必要ですか」「返品の送料はかかりますか」。社名を入れた質問だけでなく、「届いた商品を返したいときの方法」のような、困りごとから始まる質問も加えた。

最初のテストでは、AIが古い案内を一文だけ拾った。紬は急いで直そうとしたが、佐伯さんは画面を止めた。

「まず、どのページを見て答えたのかを確認しよう。答えが正しいか、条件が抜けていないか、更新日は新しいか。人が見る工程を省かないことが、いちばん大事だからね」

二人はAIの回答、参照されたURL、確認した日時を記録した。回答の冒頭に結論があるか、質問が一つのテーマになっているかも、チェック欄に残した。間違いがあれば、FAQ本文と元資料を直し、もう一度同じ質問を試すことにした。

夕方、紬が「返品の手続きはどうすればいいですか」と入力すると、今度は更新したFAQが参照元として表示された。質問の下には、返品できる条件と手続きの入口が、短い答えで続いていた。

「やっと、探している人の言葉と、答えの場所がつながりました」

紬は新しいFAQカードを、古い「返品」というカードの隣に置いた。翌朝から、サポート窓口では問い合わせを受けるたびに、お客さまの言葉と確認した資料を記録することになった。小さなカードは、答えを置く棚ではなく、質問と人の確認を重ねて育てる棚になっていった。

灯台商会のサポート窓口で、AI検索が古い返品案内を返し、紬の確認作業が止まった。会員から届いた質問と、社内で決めた最新の案内が、画面の中で別々の答えになっていた。

午前八時四十分、窓口に差し込む光が、紬の机を細く照らしていた。紬はいつものようにAI検索へ質問を入力し、返ってきた文章を開いた。

「灯台商会の商品は、どのような条件で返品できますか」

画面に出たのは、「返品について」という見出しと、古い案内の短い抜粋だった。そこには、現在の社内規定と違う説明が残っていた。

「これは、前の案内だ……」

紬は息を止めた。サイトのFAQには新しい文章を載せたはずなのに、AI検索は別のページを見つけている。

そのとき、サポート窓口の電話が鳴った。担当者が受話器を置くと、困った顔で紬の席まで歩いてきた。

「お客さまが、メールでもらった案内と検索結果が違うと言っています。どちらを信じればいいのか、分からないそうです」

紬は急いでFAQの一覧を開いた。そこには「料金」「登録」「返品」といった短い見出しが並び、画面上では新しい回答も表示されていた。

しかし、質問の文はなかった。「返品について」の下に、説明が折りたたまれているだけだった。

「新しい内容を置いただけでは、探してもらえないのかな」

紬は、昨日書き直したカードを見つめた。そこには、「灯台商会の商品は、どのような条件で返品できますか？」と、顧客が口にしそうな形で書かれていた。

午前九時すぎ、社内のシステム担当の佐伯さんが窓口へ来た。紬は画面を回し、古い回答と新しいFAQを並べて見せた。

「佐伯さん、Power Pagesのページには新しい内容があります。なのに、AI検索では古い案内が出ます」

佐伯さんは、眼鏡の奥で画面をゆっくり見た。

「まず、ページに載っていることと、AIが探せる場所にあることは別なんだ。Microsoft Copilot Studioは、設定された検索対象から材料を探して、答えを作る。材料の棚に古い文書があれば、そちらを拾うこともあるよ」

「その棚が、DataverseやSharePointなんですね」

「そう。RAGという仕組みは、質問に近い情報を先に探す方法なんだ。魔法のように最新ページだけを選ぶわけではない」

二人はPower Pagesの設定画面を開いた。会員向けサポートページには新しいFAQが公開されていたが、Copilot Studioの検索対象には、古いSharePointのPDFも含まれていた。

Dataverseには新しい返品規定の記録があった。ただし、その行には公開前の状態を示す印が残り、検索に使う設定も確認が必要だった。

「新しい記録があるのに、古いPDFも同じ棚にあるんですね」

「うん。日付だけでは、正しい文書だと判断できない。公開状態、対象範囲、更新した人まで見ないといけない」

午前九時四十五分、佐伯さんはMicrosoft Copilot Studioのテスト画面を開いた。紬が顧客と同じ質問を入力すると、しばらくして回答が表示された。

そこには、古いPDFの言葉が混ざっていた。画面の下に示された参照元も、現在のFAQではなく、数か月前に作られた案内だった。

「やっぱり、検索する場所が違っている」

紬の指が、マウスの上で小さく震えた。窓口では、次の問い合わせを待つ電話が静かに光っている。

佐伯さんは、すぐに古いPDFを消そうとはしなかった。返品の条件が変わった日や、過去の案内を必要とする会員がいないかを確認してから、検索対象から外す順番を考えた。

「消すのではなく、まず役割を分けよう。正しい現在の案内を検索できる棚に置いて、古い記録は履歴として残す。ただし、回答の材料には使わないようにするんだ」

そのあと、紬はFAQページのHTMLも確認した。画面に見える質問と回答とは別に、FAQPageやArticleのJSON-LDが埋め込まれていた。

返品手順の一部にはHowToの記述もあったが、構造化データの回答文には、画面上の新しい文章ではなく、前の説明が残っていた。見た目、検索対象、機械に渡す情報が、三つの方向を向いていた。

「JSON-LDがあれば、必ずAI検索に選ばれると思っていました」

「JSON-LDは、ページの中身を伝えやすくする手がかりだよ。でも、見えている本文と違う文章を書いたら、かえって確認が難しくなる。FAQPageを使うなら、質問と回答は画面の文章とそろえよう」

昼前、紬はサポート担当と返品担当を会議室に呼んだ。誰かを責める声は出なかったが、机の上に置かれた二つの案内を見比べる時間が長く続いた。

「公開ボタンを押す前に、答えを人が読めばよかったですね」

「そうだね。RAGが探しやすい質問にするだけでは足りない。正しい情報か、古い情報が混ざっていないか、最後は人が確かめる必要がある」

紬は新しい確認表を作った。質問は一つのテーマになっているか。回答の最初に結論があるか。参照元は今も有効か。Power Pagesの表示、DataverseとSharePointの検索対象、JSON-LDの文章は同じか。

午後、紬は「返品について」という見出しを、顧客の質問の形に直した。佐伯さんは古いPDFの扱いと検索設定を確認し、返品担当は回答の一文ずつに目を通した。

公開を知らせる小さな音が鳴ったあと、紬はもう一度、同じ質問を入力した。今度の回答には、最新の案内と確認済みの参照元が表示された。

窓口の電話がまた鳴った。紬は慌てずに受話器を取り、画面の回答と社内の規定を見比べながら、ゆっくり説明を始めた。

午後、紬は古い返品案内がAI検索に拾われた理由を探していた。画面には、顧客の質問と、現在のFAQではなく数年前のページをもとにした回答が並んでいる。FAQを直すだけでは終わらない気がして、紬は小さく息をついた。

その週、紬は佐伯さんに誘われて、地域のデジタル活用展示会へ出かけた。白い机の上には、業務の質問に答える仕組みを紹介する端末が置かれていた。そこで、Microsoftの支援をしている水野さんと出会った。

「返品の案内が、古いページに引っぱられてしまうんです。FAQは置いてあるのに、どうしてでしょうか」

水野さんは、紬の画面を見てから、紙に小さな箱を三つ描いた。ひとつ目には「探す」、ふたつ目には「答えを作る」、三つ目には「人が確かめる」と書いた。

「生成AI検索は、魔法のように全部を知っているわけではありません。まず、質問に合いそうな情報を探します。その情報を材料にして、自然な文章の答えを作るんです」

水野さんは、その流れをRAGと呼ぶと教えてくれた。難しそうな名前だが、意味は「検索してから答える仕組み」だった。AIそのものを毎回学び直すのではなく、DataverseやSharePoint、公開Webなど、設定された情報源から必要な部分を取り出す。

「だから、FAQがあることと、AI検索がそのFAQを見つけられることは別なんです。『返品について』だけでは、何を知りたいページなのかが少しぼんやりしています」

紬は、展示会でもらったカードの裏に、顧客の言葉を書き写した。「返品の手続きはどうすればいいですか」。その隣に、今の見出しを書いた。「返品について」。二つを並べると、質問と見出しの間に細い霧がかかっているように見えた。

「質問は、会社が言いたい言葉ではなく、お客さまが実際に入力する言葉に近づけます。たとえば、『灯台商会の商品は、どのような条件で返品できますか？』なら、返品条件を知りたい質問だと伝わりやすくなります」

「では、見出しを質問に変えれば解決しますか？」

「大事な一歩です。でも、それだけではありません。Power Pagesで公開されているか、検索の対象に入っているか、古いページが残っていないかも見ます。SharePointの資料なら、誰が読める設定なのかも確かめます」

水野さんは端末を操作し、同じ質問を二つの設定で試した。片方では新しいFAQが出た。もう片方では、検索対象に残った古い資料が先に見つかった。画面の答えは流ちょうだったが、返品の期限だけが昔のままだった。

紬の指が止まった。文章が自然でも、根拠が古ければ、お客さまを迷わせる。答えのうまさではなく、どの資料を見ているかまで確かめなくてはいけない。

「AIに下書きを作ってもらうのは便利です。ただし、そのまま公開はしません。担当者が、条件、日付、例外、問い合わせ先を確認してから出します。人の確認は、最後の飾りではなく、答えの一部です」

水野さんは、FAQを育てる流れを紙に並べた。問い合わせを集める。質問を一つのテーマに分ける。結論から回答を書く。更新日と根拠を添える。担当者が確認する。公開後に、AI検索で同じ質問を試す。

「『料金と納期と解約を教えてください』のような質問は、三つに分けます。ひとつの質問に、ひとつの答えです。そのほうが、RAGも人も、何を確認すればよいか迷いません」

紬は、FAQの本文を開いた。新しい見出しの下には、「返品できる条件は、商品到着後の状態と購入方法によって異なります」と結論を置き、その後に条件と手続きへのリンクを続ける。最後には、担当部署と更新日を入れることにした。

佐伯さんが、画面の端にあるコード欄を指した。そこにはFAQPageとJSON-LDの設定があった。紬は、これを入れればAI検索が必ず答えてくれるのかと思ったが、水野さんは首を横に振った。

「構造化データは、質問と回答の関係を機械に伝えるための案内札です。でも、検索の順位や掲載を約束する札ではありません。ページに見えている本文と同じ内容にして、公開範囲や検索対象も一緒に確認します」

帰りの電車で、紬は古いFAQの一覧を開いた。短い見出しの横に、顧客から届いた言葉を一つずつ並べた。どのページを残し、どれを更新し、誰が確認するかが、少しずつ見える地図になっていった。

翌朝、紬は最初のカードを佐伯さんの机に置いた。「灯台商会の商品は、どのような条件で返品できますか？」。その下には新しい回答と更新日がある。紬は不安を抱えたままだったが、今度は原因を探す道具を知っていた。

「まずは、この一枚からやってみます。AIに任せるのではなく、AIが探せる場所を整えて、人が確かめるところまで」

佐伯さんがうなずくと、朝の画面に新しい質問文が表示された。返品の案内は、短い見出しから、お客さまの声に近い一枚のFAQへ変わり始めていた。

紬はFAQの書き換えを、実際の管理画面で始めた。名詞だけの見出しを質問文に変え、Power PagesからCopilot Studioの検索で答えが選ばれるかを確かめる作業だった。けれど、最初の更新では質問と答えが食い違い、検索結果に古い案内が混ざった。

FAQの一覧には、「料金」「返品」「使い方」「登録」という短い言葉が並んでいた。紬には分かる言葉でも、画面の向こうの人が入力する疑問とは少し違う。しかも、「返品について」のカードには、似た内容の説明が二つ登録されていた。

「人間には意味が通じても、検索する人の疑問とは少し違うね」

佐伯さんは、紬の隣に椅子を寄せた。生成AI検索は、単語を拾うだけでなく、質問の意図や困りごとに近い情報を探すため、自然な疑問文のほうが答えの候補になりやすいと説明した。

「たとえば、お客さまが知りたいのは『返品』という言葉ではなく、『自分の商品を返品できるのか、どう手続きするのか』だよね」

紬は、問い合わせ履歴から実際の言い方を拾った。まず、画面の「返品について」を消し、次の一文を入力した。

変更前：「返品について」
変更後：「灯台商会の商品は、どのような条件で返品できますか？」

「『どうやって』『なぜ』『いつ』『いくら』『どの条件で』を使うと、知りたいことが見えやすくなるよ」

佐伯さんは、会員登録と料金のカードも並べた。紬は同じように、目的が一つにまとまる質問へ書き換えた。

「灯台商会の会員登録はどうやって行いますか？」

「法人向けサービスの料金はいくらですか？」

「一つの質問に、一つの答えを置くんだ。『料金と納期と解約について教えて』なら、三つのFAQに分ける。そうすると、質問と回答の関係がはっきりするからね」

紬は、質問文と回答欄を別々にした。質問はページのH2見出しに置き、回答はそのすぐ下に表示する。折りたたみの中に隠すのではなく、ページを開いた人にもそのまま読める形にした。

「FAQPageのQuestionとAnswerも、この一組に合わせるんだよね」

「そう。Question.nameには見出しと同じ質問を入れる。acceptedAnswer.textには、画面に見えている回答と同じ文を入れる。構造化データだけ別の答えにすると、機械にも人にも迷いが生まれるからね」

佐伯さんは、FAQ構造化データの考え方を説明したページを開いた。紬はFAQの構造化データに関する解説を確認しながら、質問と回答を一組ずつ表にした。表には、参照ページ、更新日、確認する担当者の欄も加えた。

ところが、紬が最初に保存した返品FAQをCopilot Studioで試すと、答えの末尾に「返品申請はメールで受け付けます」と表示された。現在のPower Pagesには、注文履歴から申請フォームを開く案内が載っている。

「質問文だけ新しくして、回答は古いままだったんだ」

紬は画面を見つめた。見出しを直しただけで安心していたが、RAGは質問に近い文章を探す仕組みであり、古い回答を自動で正しく直す仕組みではない。回答の根拠そのものを確かめる必要があった。

二人は、FAQの回答を現在の返品ページと一文ずつ照らし合わせた。結論を最初に置き、「返品申請は注文履歴のフォームから行います」と書き、その後に対象条件と注意点を続けた。最後にページの更新日を入れ、古いメール案内は削除した。

「この確認をしないまま、質問だけ増やすと危ないね」

「うん。生成AIは、見つけた文章を組み合わせて答える。だから、元のページが古ければ、きれいな質問でも古い答えを返してしまうんだ」

次に紬は、Copilot Studioのナレッジ設定を開いた。公開FAQの入ったDataverseを検索対象にし、社内向けの返品マニュアルが置かれたSharePointは、公開回答の対象から外した。社内マニュアルには担当者向けの例外処理が書かれていたため、誰でも読める回答の根拠に混ぜないよう、権限と公開範囲を確認した。

「検索範囲を広げれば、答えが増えるわけではないんだね」

「正しい場所から、読んでよい情報だけを探すことが大切だよ。RAGは、探す範囲があいまいだと、正しい文章でも使い方を間違えるからね」

紬は保存後、Copilot Studioで「灯台商会の商品は、どのような条件で返品できますか？」と入力した。最初の試行では、まだ古い回答が返った。Power Pagesの更新内容が検索側に反映されるまで待ち、もう一度同じ質問と、「返品を申し込むにはどうすればよいですか」という言い方を変えた質問で確認した。

今度は、注文履歴から申請フォームを開く手順が表示された。紬は回答のURLを開き、画面の文言と表示内容が一致することを確かめた。佐伯さんは、質問文、回答、参照URL、更新日、確認者をチェック表に記録し、公開前に二人で承認した。

料金FAQでは、さらに小さなつまずきがあった。質問は「法人向けサービスの料金はいくらですか？」なのに、回答の最初に機能紹介が長く続き、料金の説明が下に隠れていた。

「結論を最初の一、二文で言い切ろう。判断したい人が、答えを探し続けなくてすむようにね」

紬は回答の冒頭に料金の案内を置き、条件や問い合わせ先を後ろに移した。宣伝の言葉を減らし、判断に必要な事実と参照ページを残した。

最後に、紬はFAQPageのJSON-LDを確認した。画面に見えている質問と回答、構造化データのQuestionとAnswerを見比べ、少しでも違う表現があればそろえた。

公開ボタンを押す前に、紬はチェック表の最後の欄へ「人が確認済み」と記した。翌朝、サポート窓口に届いた返品の質問には、現在の手順を示すページが案内された。紬は古いカードを消した一覧を眺め、今度は答えの根拠まで確かめてから、次のFAQを開いた。

会議室では、紬と佐伯さんがFAQの棚卸しを始めた。佐伯さんは白いホワイトボードを前に立ち、古いカードを横へよけて、三つの大きな枠を描いた。

「まずは、質問です。お客さまが実際に入力する言葉を書きます」

一つ目の枠には、自然な質問が入った。たとえば「会員登録はどうやって行いますか？」だ。佐伯さんは、「登録方法」のような短い言葉ではなく、誰かが窓口で尋ねる声を思い浮かべるように話した。

「FAQを検索用の言葉にするのではなく、実際に人が尋ねる言葉にするんですね」

「そうです。生成AI検索は、言葉が同じかどうかだけでなく、質問の意図も見ようとします。だから、一つの質問には一つのテーマを置きます」

紬は、古いカードの「料金と納期と解約について教えてください」という文を見つけた。佐伯さんは、そのカードを三枚に分けた。「料金はいくらですか」「商品が届くまでどのくらいかかりますか」「解約するにはどうすればいいですか」と、質問を一つずつ書き直した。

二つ目の枠には、答えの形を置いた。佐伯さんは、最初の一文を太い線で囲んだ。

「答えは結論からです。次に、誰が対象か、どの製品やプランか、どんな条件か、期限はあるか、何を操作するかを書きます。必要な情報だけを、短く続けます」

紬は「返品できます」とだけ書かれていた古い回答を消した。新しい欄には、「灯台商会の商品は、公式ページに記載された返品条件を満たす場合に手続きできます」と置き、その下に対象商品、確認する期限、手続きの入口、問い合わせ先を並べる場所を作った。条件が料金や返品に関わるときは、「場合によります」と止めず、適用条件と確認先まで回答に含める設計だった。

三つ目の枠には、根拠ページの欄を置いた。回答の横に公式ページのURLを結びつけ、AI検索の答えから元の情報へ戻れるようにする。URLは公開時に実際のページを確認してから記載する、と佐伯さんは赤い鉛筆で書き添えた。

「根拠がないところを、AIに補わせないためです。FAQは、サイト本文と同じ内容にします」

紬はうなずいた。Microsoft Copilot StudioがDataverseやSharePointの情報を探して答えるときも、先に登録された情報が古ければ、古い答えに戻ってしまう。RAGとは、質問に合わせて情報を検索してから答えを作る仕組みであり、検索する元のページを人が確かめておく必要がある。

佐伯さんは、会員登録のカードを三つの枠の中央に置いた。質問は「会員登録はどうやって行いますか？」とし、回答の冒頭には、商品を購入する人が注文履歴の確認などのために登録する手続きだと記す。ただし、実際の対象や目的は公開ページと照合し、推測で足さないことにした。

手順は、番号付きにする。各項目には、短いステップ名、操作の説明、実際の画面や設定箇所の画像を添える形にした。

1. 登録ページを開く。公式ページにある画面名と入口を、そのまま記載する。
2. 必要事項を入力する。入力する項目と注意点を、一つか二つの文で説明する。
3. 内容を確認して送信する。完了後に表示される案内を、実際の画面と照合して書く。

「画像も、飾りではなく案内の一部ですね」

「はい。どの画面で何をするかが見えると、手順が途中で切れません。公開前に、画面の変更も人が確かめます」

佐伯さんは、構造化データの欄にFAQPageと書いた。JSON-LDは、ページの意味を検索システムに伝える書き方だという。FAQではFAQPageを優先し、手順が中心ならHowTo、背景を説明する記事ならArticleを使う方針にした。

「ただし、構造化データは補助です。ページに見えていない答えを、JSON-LDだけに入れてはいけません」

佐伯さんは、表示されている本文と構造化データの回答文を一致させることを確認した。FAQ構造化データの考え方は、FAQ構造化データの解説にも整理されている。質問と回答を独立させる設計は、FAQ設計の解説で示される考え方とも重なっていた。

以前の一覧には、「料金」「登録」「返品」という札だけが並んでいた。今は、質問、結論から始まる回答、確認できる根拠ページが、白い線でつながっている。紬がカードを並べ直すたび、会議室の空気から迷いが少しずつ消えていった。

「これなら、AIが答えを作る前に、私たちが何を根拠にするか確認できます」

窓の外では、午後の光がホワイトボードを照らしていた。白い設計図には、検索されるための言葉ではなく、困った人の質問と、確かめられた答えが残っていた。

紬は、新しい質問文とFAQPageのJSON-LDを設定した。ところが検索画面で試すと、答えには別のページが表示され、作ったFAQの引用URLは見つからなかった。

編集画面には、自然な質問が大きく表示されていた。

「灯台商会の商品は、どのような条件で返品できますか？」

その下には、結論から始まる回答が続いている。紬は同じ文章をHTML本文に置き、ページの<head>には、質問と回答の関係を伝えるJSON-LDを貼った。

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "灯台商会の商品は、どのような条件で返品できますか？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "返品をご希望の場合は、公式の返品手順をご確認のうえ、お問い合わせください。"
    }
  }]
}

「Questionが質問で、acceptedAnswerが、その質問への答えなんですね」

「そうだよ。機械が見ても、どの答えがどの質問につながるか分かる形だね。ただし、これだけで検索に必ず拾われるわけではないんだ」

紬が「返品の手続きはどうすればいいですか」と検索すると、画面には古い案内ページが出た。新しいFAQの文章は見当たらず、引用欄にも、作成したページのURLはなかった。

佐伯さんはPower Pagesの設定画面を開いた。検索対象になっているDataverseのテーブルを確認し、次に列の一覧をゆっくり見ていった。

「FAQの質問と回答が入っている列は、検索対象になっているかな。ページ自体が対象外なら、どれほど丁寧に書いても見つからないよ」

紬が確認すると、公開Web向けに保存したつもりの回答は、Dataverseの内部確認用の列に入っていた。公開ページに表示される列は空白だった。FAQ編集画面では答えが見えていたため、紬は気づかなかった。

「ここだったんですね。見えている画面と、検索される場所が違っていました」

二人はまず、FAQ本文が実際の公開ページに表示されるかを確かめた。次に、ページ上のQuestionとAnswerが、JSON-LDのnameとtextに一字ずつ対応しているかを見た。構文の誤りや、FAQPage、Question、acceptedAnswerなどの必須項目も確認した。

さらに、Power Pagesで対象になっているページ、Dataverseのテーブル、質問と回答の列を調べた。添付ファイルやSharePointに置いた根拠資料については、検索する利用者が読める権限になっているかも確かめた。

「公開情報と会員向け情報は、同じ箱に入れないほうが安心ですね」

「うん。生成AI検索が見られる情報は、その人のサイト権限と同じでなくてはいけない。会員だけの案内を、誰にでも答えてはいけないからね」

紬は公開用の列へ回答を移し、公式の返品ページへのリンクを根拠として加えた。二人は公開利用者と会員利用者、それぞれの権限で検索を試した。どちらの画面にも、見てよい情報だけが表示されることを確認した。

しばらくして、検索結果に新しいFAQが現れた。回答のそばには、灯台商会の公式ページを指す引用URLも表示されている。

「質問を直すだけでは、道しるべにならなかったんですね」

紬は画面のURLを確認し、更新記録に日付と確認者の名前を書いた。窓の外では、港の灯りがひとつずつ点き始めていた。