このブログは記事の下に著者名を出していません。テンプレートの中に「藤原 雅也」という文字列が1つあるだけで、どの記事も同じ。1人で書いているので、これで足りています。

足りなくなるのは、複数人で書くサイトを納品したときです。「記事に書いた人を出したい」と言われて、記事のフィールドに author というテキスト項目を1つ足す——この判断が半年後に効いてきます。ヘッドレスCMSは著者を文字列でなく独立したレコードで持つ仕組みを最初から持っていることが多く、EmDash ではそれが byline（クレジット）にあたります。

「書いた人」と「ログインしている人」は別もの

著者をテキスト項目で持つ場合とbylineレコードで持つ場合の比較表

byline は記事フィールドではなく、独立したレコードです（テーブルも _emdash_bylines で別）。ログイン用のユーザーアカウントとは切り離されていて、次の2種類を作れます。

  • CMSユーザーに紐づけた byline — 社内の書き手。アカウントと1対1で結ぶ
  • ゲスト byline — 外部ライター、寄稿者、監修者。ログインアカウントは要らない

記事側が持つのはクレジットの並びです。1件目が主著者（primary）になり、クレジットごとに役割ラベル（執筆／監修／撮影）を付けられます。連名の記事でも、誰が何をしたかが構造で残るわけです。

挙動でひとつ知っておきたいのが、クレジットが1件も付いていない記事の扱い。このときだけ、EmDash は記事の作成者アカウントに紐づく byline へフォールバックします。そのクレジットには source: "inferred"（推測）が付き、編集者が明示的に付けたものには "explicit" が付く。テンプレート側で本当に指定された著者か、ログインユーザーから拾っただけかを見分けられます。

逆に、主著者が指定済みなのに、その言語で byline が解決できないときは、推測で埋め戻さず著者なしで描きます。多言語サイトで翻訳漏れの著者が別人にすり替わる事故を防ぐ作りです。

byline レコードの作成・更新・削除には Editor 以上の権限が要ります。記事を書くだけの人に著者マスタを増やさせない、という線引き。権限の段の話は管理画面をどこまで渡すかに書きました。

テキスト項目で持つと、後から効いてくる

明示クレジット、主著者の指定、クレジットゼロの順に著者が決まる流れ図

「とりあえず文字列でいいのでは」で進めた場合に起きることを3つ。

  • 表記ゆれ。「山田太郎」「山田 太郎」「山田」が混ざる。人手で入れる以上、必ず混ざります
  • 著者ページが作れない。文字列は記事の中の文字でしかないので、「この人が書いた記事一覧」をデータベース側で引けない。あとから欲しくなった時点で、全記事を触るはめになる
  • そもそも使えない名前がある。byline bylines terms author_id などはフィールドのスラッグとして予約済みで、作ろうとすると弾かれます。実行時に自動で埋まる値をユーザー定義フィールドが上書きしないための措置です

プロフィールに項目を足したいときは、記事側ではなく byline 側に足します。使える型は文字列・長文・URL・真偽値・選択肢の5つ。ここにも予約スラッグがあって、display_name bio website_url user_id is_guest に加えて reorder も使えません。管理APIの並べ替えルートとURLが衝突するためで、フィールド設計の考え方そのものは更新しても崩れないフィールド設計と同じです。

構造化データの author は「名前」でなく「たどれる場所」

著者を出すなら、画面の表示だけでなく Article / BlogPosting の構造化データにも出します。Google の公式ドキュメントが挙げている要点はこのあたり。

  • author.name には名前だけを入れる。肩書き、媒体名、「posted by」のような語を混ぜない
  • url（または sameAs）で、その著者を一意に特定できるページを指す。プロフィールページやSNSのアカウントページ
  • 人は Person、組織は Organization。Thing のような曖昧な型にしない
  • 複数著者は1人ずつ別の author に分ける。1つの文字列に連名で詰めない
  • ページ上で著者として見せている人は、マークアップにも出す（表示とマークアップを一致させる）

自分のサイトを見てみると、できていませんでした。記事ページの BlogPosting は author が {"@type":"Person","name":"藤原 雅也"} だけ。同じページのもう1つの JSON-LD には @id 付きの Person（mainEntityOfPage が /about）を定義しているのに、記事の author はそこにつながっていない。機械から見れば、同姓同名の別人かもしれない Person が2つ並んでいる状態です。

1人運用なので順位に響く類の話ではありませんが、直すなら記事の author に url（または @id）を足して /about のプロフィールへ寄せる、が筋。構造化データ全体の組み方は構造化データ・OGPでSEOを強くするにまとめています。

渡す前に決めておく3つ

著者設計で渡す前に押さえる4点をまとめたカード図
  1. 誰の名前を出すか。制作会社が運用するオウンドメディアだと、担当者個人を出すか会社名にするかで、その後の運用が変わります。個人名を出すなら、url で指すプロフィールページまで含めて1セットで用意する
  2. 人が入れ替わったらどうするか。byline がアカウントと別レコードなのは、ここで効きます。退職してログインを止めても、記事のクレジットは残る。「アカウントを消したら過去記事の著者が消えた」にならない設計です
  3. 削除したときに何が起きるか。byline を削除すると、その言語の変種が最後の1件だったときにかぎり、全記事のクレジット行が一緒に消え、主著者の指定も外れます。翻訳変種が残っていれば記事側のクレジットはそのまま。1人分消したつもりで過去記事の著者表示が全部消える、を避けるなら、削除より表示から外す運用のほうが安全です

著者情報は、あとから足すと全記事を触ることになる部類の設計です。公開前の、記事がまだ数本のうちに決めておくと安く済みます。

ヘッドレスCMSの構築や、既存サイトの構造化データの整理でお困りでしたら、お問い合わせからご相談ください。実装の一部だけでも承ります。

本記事は2026年9月時点の情報です。