非エンジニアを「最強のコンテンツ発信者」に変える。GitLab Static Site Editor 徹底攻略ガイド
「エンジニアがCMS代わりになって、Markdownを修正する」。これほど生産性を阻害する無駄なタスクはない。技術者は本来、コードを書き、アーキテクチャを磨くべきだ。
GitLabの Static Site Editor (SSE) は、単なるWYSIWYGエディタではない。Gitの冪等性を守りつつ、非エンジニアに「編集権限」という武器を与えるための強力なインターフェースだ。今回は、ただ導入するだけでなく、「開発チームのドキュメント更新負荷をゼロにし、デプロイサイクルを高速化する」ための実践的実装術を伝授する。
—
1. なぜ「Static Site Editor」なのか：思想的背景
GitLab SSEの真価は、「Gitの履歴管理」と「非エンジニアの直感的な編集」を、マージリクエスト（MR）という安全装置を介して両立させる点にある。
- エンジニアのメリット: 修正依頼のチケットを起票し、手動でコピペしてコミットする作業からの解放。
- 非エンジニアのメリット: CLI不要、Markdown知識不要。ブラウザだけで「いつものワープロ感覚」で公開できる。
—
2. 実装の要諦：`.gitlab/static-site-editor.yml` のベストプラクティス
SSEを動かすために最も重要なのは、`gl-conf.yaml` (または `static-site-editor.yml`) の設定だ。ここを適当にやるとMRが乱立し、CIが破綻する。
以下に、大規模プロジェクトでも破綻しない推奨構成を提示する。
.gitlab/static-site-editor.yml
編集可能なディレクトリを限定し、編集時の挙動を制御する
content_editors:
- name: “Marketing Blog”
directory: “content/posts” # 編集範囲を限定
# テンプレートを強制し、構造を破壊させない
template: “.gitlab/templates/post-template.md”
# 自動作成されるブランチ命名規則を統一し、CIのフィルタリングを容易にする
branch_prefix: “sse/content-update”
【現場の知見】YAML設定の鉄則
- ディレクトリの粒度: サイト全体を指定せず、必ず `content/` など特定のフォルダ配下に絞ること。ルートを指定すると構成ファイルまで誤編集されるリスクがある。
- テンプレートの活用: `template` 設定を必ず入れること。非エンジニアが書きやすい「決まったヘッダー（Front Matter）」を自動挿入させるのが、管理コストを下げる唯一の道だ。
—
3. ワークフローを加速させるCI/CDパイプライン
SSEで作成されたMRは、自動的に「レビュー待ち」の状態になる。ここでCIパイプラインに 「プレビュー環境の自動構築」 を組み込むのがプロの流儀だ。
.gitlab-ci.yml
SSE経由のMRのみ、特別なプレビュー環境をデプロイする
preview:
stage: deploy
script:
- bundle exec jekyll build # 静的サイト生成
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_COMMIT_REF_SLUG.pages.dev/
on_stop: stop_preview
rules:
# SSE経由のブランチのみ対象にする
- if: $CI_COMMIT_REF =~ /^sse\//
when: always
ここが肝: `review/$CI_COMMIT_REF_SLUG` で動的にプレビュー環境を作成せよ。非エンジニアは「公開ボタン」を押す前に、実際の表示をURLで確認できる。これが安心感を生み、手戻りを激減させる。
—
4. チームの生産性を底上げする「隠し技」
① GitLabの神ショートカット（社内周知必須）
エンジニアも非エンジニアも、これを知っているだけで作業効率が1.5倍になる。
- `g` + `i` : 自分の担当するIssueへ即座に移動（SSEで作成されたMRの確認に必須）
- `w` : マージリクエストの変更点(Changes)を表示。プレビューURLがどこにあるか探す時間を短縮。
② 絶対入れるべき神プラグイン
- Grammarly (ブラウザ拡張): 非エンジニアが記事を書く際、GitLabエディタ上で直接文章校正をさせる。誤字脱字による「差し戻し」の回数が劇的に減る。
③ 承認フローの自動化
`CODEOWNERS` ファイルを駆使し、SSEからのMRは自動的に「広報担当者」と「リードエンジニア」の両方にレビュー依頼が飛ぶよう設定せよ。
.gitlab/CODEOWNERS
/content/posts/ @marketing-team @tech-lead
—
5. テックリードからの提言
SSE導入の本質は「ツールの導入」ではなく、「コンテンツ発信の民主化」だ。
非エンジニアが書いたMarkdownが、そのままプロダクションへ流れる。その過程でエンジニアが関与するのは「MRの承認ボタン」を押すことだけ。もし「GitLabの使い方を教えるのが面倒」と感じたら、それはシステムがまだ十分に抽象化されていない証拠だ。
「非エンジニアが最も触りやすい構成」を追求し、CI/CDパイプラインという鉄壁のガードレールを敷く。これが、我々DevOpsエンジニアが目指すべき「真の自動化」である。
さあ、今日から「エンジニアによるCMS運用」という名の負債を返済しよう。GitLab PagesとSSEがあれば、技術力はもっと創造的なことに使えるはずだ。