Careersページをコードの外へ ― Hydrogen × Sanityで、更新を開発依頼から切り離す
この記事でわかること
- ヘッドレスCMS「Sanity」とは何か、当社が選んだ理由
- 1つのサイトの中で、ページごとに「誰がどこで直せるか」を分ける考え方
- 開発なしで変えられる範囲と、開発が必要になる範囲の線引き
- Oxygen（Hydrogenの実行環境）でSanityを動かすときにつまずいた箇所
Careersページの更新が、開発チームへの依頼になっていた
当社のコーポレートサイトは、Shopifyのヘッドレスコマース基盤であるHydrogenで構築しています。採用情報をまとめたCareersページも同じ仕組みの上にありました。ただし、このページだけは事情が違いました。載せている情報が、コードの中にあったのです。
2026年7月に手を入れるまで、Careersページを描いていたファイルは751行ありました。その大半が直書きです。募集職種の一覧も、応募要件も、待遇の箇条書きも、ページ冒頭に並ぶ写真の指定も、コードの中の文字列として存在していました。
「この一文を消したい」「新しいポジションを1つ増やしたい」。採用の現場では起こりうる変更です。ところが、そのたびに開発チームへ依頼し、コードを直し、レビューを通し、デプロイする手順が必要になります。文章としては数分で終わる修正に、この手続きがついてきます。
ヘッドレスコマースを検討する際によく挙がる「更新が大変になるのでは」という懸念は、まさにこの状態を指しています。当社は、自社サイトでこれを解消することにしました。
「誰がどこで直せるか」で、持ち場を分ける
採った方法は、更新の多い情報だけ、編集できる場所を別に用意するというものです。選んだのは、ヘッドレスCMSのSanityでした。
ヘッドレスCMSとしてのSanity
一般的なCMSは、原稿を保管する機能と、それをWebページとして組み立てる機能がひとつになっています。ヘッドレスCMSは後者を持ちません。原稿を構造化して保管し、外部から取り出せるようにすることに専念します。表示は、取り出した側（今回はHydrogen）の仕事です。
役割が分かれている分、同じ原稿をWebサイトにもアプリにも出せます。サイトのデザインを刷新しても、原稿はそのまま残ります。Sanityが自社を「コンテンツオペレーションのプラットフォーム」と呼んでいるのは、この位置づけによるものです。
数あるヘッドレスCMSのなかで、Sanityには次のような特徴があります。
- 保存する項目を自分たちで設計する。「Careersページには、見出しと本文と写真の一覧を持つ『ヒーロー』という部品がある」といった定義を、開発側がコードで書きます。決まった型に自社の情報を押し込めるのではなく、自社の情報に合わせて型のほうを作ります
- 編集画面が自社の持ち物になる。Sanityの編集画面は「Studio」と呼ばれ、自社で管理するアプリとして存在します。項目の並び順も、入力欄の説明文も、自分たちで調整できます
- 本文を構造化されたデータとして保存する。HTMLではなくPortable Textという形式を使います。公式サイトが「リッチテキスト、画像、コードブロック、そして自分で定義した任意の型」と説明しているとおり、テキスト以外の要素も、型を定義すれば扱えます
なぜSanityにしたか
今回の要件に対して、次の3点が決め手になりました。
- 日本語と英語を1つの原稿に同居させられる。項目の設計を自分たちでできるため、「各項目が日本語と英語の2つの入力欄を持つ」という形にできました
- プレビューを見ながら編集する手段が用意されている。Sanity公式のPresentation Toolを設定すると、編集画面の中にサイトが表示され、プレビュー上の対象箇所をクリックして、対応する入力欄で編集できます。ただしこれは設定なしで使えるものではなく、プレビュー先のURLと、URLと原稿を対応づける処理を書く必要があります
- Hydrogen向けの公式ツールキットがある。Sanityがhydrogen-sanityというパッケージを公開しており、データの取得からプレビューの仕組みまでをまとめて提供しています。連携そのものに必須というわけではありませんが、今回は後述する実行環境の問題を解くうえで有効でした
Shopifyだけで完結させる道もありました。Shopifyにもメタオブジェクトという仕組みがあり、商品以外の構造化データを持てます。実際、当社サイトの用語集はメタオブジェクトで管理しています。今回Careersまわりでそれを選ばなかったのは、Shopifyでは実現できないからではなく、今回求めた編集体験――セクションの並び順をドラッグで入れ替え、プレビューを見ながら直す――を、運用にかけられる工数の中で用意する手段として、Sanityのほうが近道だと判断したためです。同じ要件でも、体制や既存の資産が違えば別の答えになります。
3つの「直せる場所」
ここで一つ整理しておきます。当社のサイトは、どのページもHydrogenが表示しており、ShopifyのホスティングであるOxygenの上で動いています。その意味では、サイト全体がShopifyの上にあります。
違うのは、ページに載っている中身がどこに保存されていて、誰が直せるのかです。今の当社サイトは、この点で三つに分かれています。
重要なのは、すべてをCMSに寄せなかったことです。入稿が回っている領域はShopifyの管理画面のまま。会社紹介やサービス紹介は、更新の頻度が高くないのでコードの中に置いたまま。「よく変わる」かつ「編集する人がエンジニアではない」という条件が重なるCareersまわりだけを、新しい編集画面に出しました。移行範囲を欲張らないほうが、結果として早く本番に出せます。必要になれば、同じ方法であとから外に出せます。
渡したのは「文章」ではなく「ページの組み立て」
CMSを導入したのに使い勝手が変わらない、という失敗があります。文章の差し替えはできるようになったものの、「セクションを1つ増やしたい」「順番を入れ替えたい」となると、結局また開発依頼に戻ってしまうパターンです。
そこで今回は、Careersページをセクションの積み木として設計しました。冒頭のヒーロー、会社の価値観、社員の声、会社紹介資料、募集職種、応募要件や待遇、組織図。これらが独立した部品になっており、編集画面でドラッグして並び替えられます。追加も削除も、表示・非表示の切り替えもできます。
ただし、開発なしでできるのは、あらかじめ用意した種類のセクションを組み替える範囲までです。「これまでにない種類のセクションを作りたい」「セクション内のレイアウトを変えたい」という要望は、型の定義と描画処理の両方に手を入れることになるので、開発側の作業です。この線引きをどこに引くかが、この種の設計でいちばん考えどころです。
どのセクションをどの順番で置くかという情報自体を、CMS側が持っているという点がポイントです。サイト側は、届いた順番どおりに部品を描画します。
Sanityへの載せ替えで、Careersページのファイルは751行から64行になりました。ただしこれは「コードが12分の1になった」という話ではありません。画面を組み立てる処理は、新しく作った別のファイル（当初303行）に移っただけです。変更全体では15のファイルにまたがって732行が加わり、850行が消えており、コードの総量はほとんど変わっていません。保守の負担が減ったかどうかも、これとは別の話です。
変わったのは量ではなく、何がどこに書いてあるかです。求人票はコードから出て、編集画面に移りました。
もう一つ、日本語と英語の扱いも設計しました。当社のサイトは日英で公開していますが、言語ごとにページを2つ作ると、片方だけが更新されて内容がずれるおそれがあります。そこで、各項目が「日本語」と「英語」の2つの入力欄を持つ形にしました。1つの原稿を開けば両方の言語が見えるので、ずれに気づけます。あわせて、英語が空欄のときは日本語を表示する処理を今回実装しました。Sanityの標準動作ではなく、サイト側に書いた仕組みです。これにより、英訳が間に合っていなくても英語版ページが空にはなりません。
見た目を変えないまま、中身だけを入れ替える
既存ページのCMS化で懸念されるのが、デザインが変わってしまうことです。今回は「見た目は変更しない」を前提条件に置き、既存のスタイルとコンポーネントをそのまま再利用しました。新しく作ったのは、Sanityから受け取ったデータを既存の部品に渡す処理だけです。
この前提を置くと、プロジェクトの議論から「デザインが変わるかもしれない」という不安を切り離せます。検討すべき論点が、運用をどう変えるかという一点に絞られます。
Oxygenの実行環境でつまずいた話
実装で引っかかった箇所を一つ。同じ構成を検討される方の参考になればと思います。
HydrogenのホスティングであるOxygenは、一般的なNode.jsではなく、Workers系のランタイム（workerd）で動きます。ブラウザの環境に近いものの同じではない、独特の実行環境です。そのため、Node.js向けに書かれたライブラリがそのままでは動かないことがあります。
最初の検証では、Sanityのデータ取得ライブラリがこの環境で動かないと判断し、いったん見送りました。しかし実際には、素直に読み込むと内部で使われている依存ライブラリがうまくまとまらない、という問題でした。hydrogen-sanityに含まれるビルド設定を使うとこれが解決し、ビルドしてOxygen相当の環境で動かし、動作を確認できました。
外から見ると「動かない」と「入り口を間違えている」は区別がつきません。公式のツールキットがある場合は、まずそれを試す。遠回りに見えて、これが近道でした。
公開してからの運用
2026年7月12日、Careersページとインタビュー記事をSanityから配信する変更を本番に反映しました。プレビュー編集の仕組みも同じ日に入っています。
編集する人から見た画面は、次のようになっています。
- プレビューを表示しながら編集できる。直したい箇所をクリックすると、対応する入力欄が開きます
- 書きかけの内容は自動保存されますが、公開ボタンを押すまでサイトには出ません
- 編集履歴が残るため、契約プランの履歴保持期間内であれば以前の状態に戻せます（Sanityの履歴は、プランごとに定められた期間を過ぎると古いものから整理されます）
- 公開後、サイトに反映されるまでに2分ほど見ておいてください。これはSanity側の仕様ではなく、サイト側に設定したキャッシュの持ち時間によるものです
ここで意識したのは、何が自分で変えられて、何がそうでないかをはっきりさせることです。たとえば組織図の画像はサイト側に組み込まれているため、編集画面からは変更できません。こういった線引きを最初に共有しておくと、「変えられるはずなのに見つからない」という迷いがなくなります。
この構成が向いているケース
今回の構成は、次のような状況に当てはまります。
- ECはShopifyで動いているが、採用・事例・お知らせといったページの更新が開発依頼になっている
- 情報の鮮度が成果に直結するページがある（採用情報のページはその典型です）
- 日本語と英語など、複数言語を運用している
- デザインは変えたくないが、運用の仕方は変えたい
ヘッドレスコマースは更新が大変、という言われ方をします。しかし実際に大変になるのは、誰が何を更新できるのかを設計しなかったときです。ページを部品に分け、その並び順まで含めて編集する人に渡せば、ヘッドレスのまま運用の一部を手元に戻せます。どこまでを渡し、どこからを開発の仕事として残すか。その線引きこそが設計だと、自社のページで確かめました。
Hydrogenによるヘッドレスコマース構築、および今回のようなCMSを組み合わせた設計については、お気軽にご相談ください。