AIによる会社紹介と、自社の説明をどう照合するか｜BASの情報設計案

名前を揃える仕事では、法人、店、サービス、人を一つにまとめないことが重要です。ここからはレイの視点で、架空の修理工房「継ぎ木」の情報設計を扱います。BASの提案として、運営法人と屋号、個別の修理メニュー、創業者の関係を分けて記録します。屋号の知名度が高くても、契約の相手や問い合わせ先まで同じ名称とは限らないためです。

Googleの組織向け構造化データの説明では、組織情報の記述がGoogleによる組織の識別を助け得るとされています。一方、対応する検索表示が必ず出るという保証はありません。これはGoogle検索の仕様説明であり、すべてのAIが同じ情報を使って同じ分類をするという証拠ではありません。

継ぎ木の主な仕事を「木製家具の修理」と定めるなら、販売、設計、出張相談は、実際の提供範囲に応じて補足します。検索されそうな業種を全部並べると、受付できない依頼まで呼び込みかねません。主な分野は顧客の用事に照らして選び、補助的な分野には条件を添えます。社内の組織図より、相手が何を頼める会社か分かる順序を優先します。

実務では、会社紹介、料金案内、問い合わせ画面の三か所を並べ、名称と役割の組を照合します。旧屋号を残す場合は現在の名称との関係を記し、創業者を現代表と取り違えないよう役職の時点も確認します。修正の担当を決めてから機械向けの記述を検討する順序なら、誤った会社像を整った形式で広める危険を抑えながら、公開情報の基礎を固められます。

誰に何を提供するかは、抽象的な価値と具体的な受付条件を対にして説明します。「思い出を守る」だけでは、修理できる材質も、送付で頼めるかも分かりません。継ぎ木なら、木製家具を使い続けたい人に、状態確認と修理案の相談を提供するという骨格を置き、写真だけでは確定できない事項や対応地域を別に示します。

対象顧客を決める時は、年齢や職業だけで切らず、どの場面で困っているかを具体化します。引っ越しを前に椅子を直したい人と、店舗の備品をまとめて点検したい人では、数量、納期、見積もりに必要な情報が違います。同じ修理という分類でも、相談の入口を分ければ、相手が自分の用事に合う案内へ進めるかを確かめられます。

記事やSNSは、同じ文章を転載する必要はありません。短い投稿では作業の一場面を見せ、詳しいページでは条件を説明する役割分担ができます。ただし投稿で「どんな家具でも」と書き、受付ページで対象を狭く限定すれば、読み手の期待はずれが生じます。媒体をまたいで揃えるのは文体ではなく、対象、提供内容、約束できる範囲という骨格です。

一週間の試行では、一つのメニューを選び、受付担当が最近受けた質問三つにページだけで答えられるかを確認します。答えが足りない箇所を直し、次の問い合わせで同じ迷いが残るかを見ます。件数が少ない場合は効果を数字で断定せず、質問内容の変化を記録します。AIへの見え方を論じる前に、人が相談の可否を判断できる説明になっているかを検証する手順です。

強みの言葉には、その内容を確かめる手掛かりをつなぎます。「修理が得意」という主張に作業写真を添えるなら、何を直した写真か、どの条件の事例かが分かる説明が必要です。継ぎ木が椅子のがたつきを扱った事例を持っていても、その写真だけで全種類の家具の安全や耐久性を証明したことにはなりません。根拠が支える範囲を狭く正確に置きます。

Proofは相手が主張を確かめるための材料、Unique Assetsは価値を生み続ける独自の蓄積として、本稿では区別します。例えば完成写真は公開する根拠になり、材質ごとの判断記録や職人同士の相談の仕組みは仕事を支える資産になり得ます。この区別はBASの整理案です。写真の数が多いことだけで独自性が高いとは判定しません。

独自資産を伝えるために、記録の中身を全部公開する必要もありません。相談から診断、合意、作業へ進む流れや、どんな観点で選択肢を説明するかを示せます。顧客の名前、私生活が写り込む写真、外へ出せない工程は公開対象から外して確認します。何を持っているかという存在の説明と、その秘密の中身を渡すことを分けると、伝える方法の選択肢が増えます。

公開する事例には、主張、対象、時点、確認者、元資料への社内の参照先を付けます。結果のよい事例だけで全体の成功率を言わないことも、運用上の約束にします。BASの支援設計では、会社紹介の形容詞を増やすより、各主張の横に確かめられる材料があるかを点検する方が先です。根拠が不足する主張は、資料を探すか、表現を狭めるかを選べるようにします。

企業情報をつなぐ時は、単語の一覧より関係の意味を重視します。継ぎ木という屋号を運営する法人、修理を担当する人、相談できるサービス、その作業を説明する記事を別々に持ち、どれがどれを説明するかを結びます。記事が増えるたびに会社紹介を作り直すのではなく、同じ対象へ戻れるようにするのが、ここで提案するKnowledge Layerの考え方です。

Schema.orgのOrganization定義には、組織の創設者を表すfounderなどの関係が用意されています。ただし、共通の語彙があることと、特定のAIサービスがその項目を採用することは別です。技術上の表現候補として参照し、BASが既に同形式を実装しているという説明や、記述すれば推薦されるという約束には使いません。

関係には、方向と根拠を持たせます。創業者が商品を紹介した記事は、その人が現在すべての修理を担当している証拠にはなりません。ロゴが写る写真も、その写真の撮影者や商品の権利者を示すとは限りません。人、象徴、制作物、実績のつながりを曖昧な「関連」で済ませず、運営する、提供する、説明する、確認する、といった言葉で書き分けます。

最初の試行は、会社一件、サービス一件、事例三件の関係図で十分です。参照先が切れた時に誰が直すかまで確認し、必要以上に細かな項目は増やしません。三件の事例から同じサービスへ戻れ、会社の説明と矛盾しないかを人が読んで試します。整理したい情報と公開範囲の相談には、BASで相談テーマを選ぶを入口にできます。