:slug
1 セグメントだけを受け取る名前付きパラメータ
`/blog/:slug` は `/blog/hello` に一致し、`slug=hello` を取り出します。`/blog/2026/hello` のようにスラッシュをまたぐ値には一致しません。
DOCUMENTATION
プロジェクト作成からサイト公開、ルーティング設定まで、200stack の使い方をまとめています。 初めて設定するときは上から順に、特定の機能だけ確認したいときは目次から移動してください。
QUICK START
最初はプロジェクトを作り、公開したいものに合わせてアプリを選びます。 その後の設定は dashboard 上で進められます。
dashboard にログインし、個人または組織のプロジェクトを作成します。
プロジェクトはアプリ、メンバー、請求、ドメインなどをまとめる単位です。個人で試す場合は個人プロジェクト、制作チームや顧客と共同で管理する場合は組織プロジェクトを使います。
あとから GitHub 連携や独自ドメインなどを追加できるため、最初は名前と用途が分かる状態にしておけば十分です。
デプロイ履歴、独自ドメイン、請求を dashboard で確認します。
公開後は、最新デプロイが成功しているか、期待したドメインで表示できるかを順番に確認します。
デプロイ履歴には成功、失敗、対象 commit などが残るため、公開状態の確認や切り戻し判断に使えます。
DEPLOY
静的サイトは GitHub App と連携して公開します。push を起点に 200stack が変更を受け取り、ビルドと配信更新を行います。
プロジェクトの Git 連携画面から GitHub App を追加し、200stack が参照できるリポジトリを選びます。
GitHub 側のインストール画面で、対象アカウントとリポジトリの範囲を選択します。後からリポジトリを追加したい場合は、GitHub 側の App 設定で構成を変更できます。
200stack には必要なリポジトリ権限だけを渡す運用にしてください。組織リポジトリを扱う場合は、GitHub 側の権限を持つメンバーが連携を行います。
対象ブランチに push すると、200stack が webhook を受け取り、ビルドと配信更新を開始します。
push 直後は、dashboard のデプロイ履歴で状態を確認します。ビルド中、成功、失敗などの状態が残るため、どの commit が公開されたかを後から追跡できます。
Webhook の URL や署名 secret は 200stack 側で管理します。利用者が手動で secret を公開ページやクライアントコードに置く必要はありません。
デプロイ履歴からステータスやログを確認し、必要に応じて過去のデプロイへ戻します。
失敗時はまずログを開き、依存関係のインストール、環境変数、ビルドコマンド、出力ディレクトリのどこで止まったかを確認します。
過去の安定版に戻したい場合は、直近で成功しているデプロイを基準にします。戻した後も、ドメイン表示と主要ページの確認を行ってください。
ROUTING
ルーティング機能では、公開中のサイトに対してリダイレクト、内部フォワード、404 フォールバックを設定できます。 URL 変更後の案内、SPA の直接アクセス対応、パス構造の整理に使います。
設定ファイルを用意する
ルーティング設定はリポジトリルート直下の `routing-config.jsonc` で管理します。
設定を編集する
`rules` にリダイレクトや内部フォワードを追加し、必要に応じて `notFound` を設定します。
push してデプロイする
設定ファイルを含む変更を push すると、デプロイ時にルーティング設定が反映されます。反映後は対象ドメインでリダイレクト、内部フォワード、存在しない HTML パスを確認します。
まず、実際に配置する設定ファイルの形を確認します。設定は JSONC 形式で記述します。 コメントと末尾カンマを使えますが、キーはダブルクォートで書きます。`$schema` を指定すると、対応エディタで入力補完や検証を使いやすくなります。
{
// エディタ補完と検証に使うスキーマです
"$schema": "https://www.200stack.com/schemas/routing-config.schema.json",
// ルーティング設定のバージョンです。現在は "1" 固定です
"version": "1",
// この設定を適用するホストを限定します
"scope": {
"hosts": ["example.com"]
},
// 上から順に評価され、最初に一致した 1 件だけが適用されます
"rules": [
{
// 古い記事 URL を新しい記事 URL へ恒久リダイレクトします
"id": "legacy-post",
"type": "redirect",
"source": "/blog/:year(\\d{4})/:slug",
"destination": "/posts/{year}/{slug}",
"status": 301
},
{
// 表示 URL は変えず、/docs 配下のファイルを返します
"id": "docs-forward",
"type": "forward",
"source": "/guide/:path*",
"destination": "/docs/{path}",
"query": "preserve"
},
{
// 外部サイトへ移動させる場合は https と許可ホストを明示します
"id": "status-page",
"type": "redirect",
"source": "/status",
"destination": "https://status.example.com/",
"status": 302,
"allowExternal": true,
"allowlistHosts": ["status.example.com"]
}
],
// SPA などで、存在しない HTML パスを /index.html に寄せます
"notFound": {
"destination": "/index.html",
"status": 200,
"htmlOnly": true
}
} 設定ファイルは、適用範囲、ルール一覧、404 時の扱いで構成されます。どの項目が必須で、どの項目が用途別に変わるかを確認できます。
type RoutingConfig = {
// 設定フォーマットのバージョンです。現在は "1" を指定します。
version: "1"
// 設定を適用するホストを限定したい場合に使います。
scope?: {
hosts?: string[]
}
// 上から順に評価されるルール一覧です。
// 最初に一致した 1 件だけが適用されます。
rules: RoutingRule[]
// どのルールにも一致しなかった HTML リクエストの扱いです。
notFound?: {
destination: string
status?: 200 | 404
htmlOnly?: boolean
}
}
type RoutingRule = RedirectRule | ForwardRule
type RedirectRule = {
// ルールを見分けるための ID です。
// 移行元や用途が分かる名前にします。
id: string
// redirect はブラウザの URL を変更します。
type: "redirect"
// どの URL に一致させるかを書きます。
// :name は名前付きパラメータで、name の部分は任意の名前にできます。
// :year(\\d{4}) は year という名前の値を 4 桁の数字に限定する例です。
source: string
// 遷移先です。source で付けた名前は {year} / {slug} のように埋め込めます。
destination: string
// 恒久移転は 301 / 308、一時移転は 302 / 307 を使います。
status?: 301 | 302 | 307 | 308
// path は既定です。regex では JavaScript RegExp に近い書き方を使います。
patternSyntax?: "path" | "regex" | "glob"
// クエリ文字列を引き継ぐ場合は preserve、捨てる場合は drop を指定します。
query?: "preserve" | "drop" | "replace" | QueryConfig
// 外部サイトへ redirect する場合だけ true にします。
allowExternal?: boolean
// 外部 redirect を許可するホストを明示します。
allowlistHosts?: string[]
}
type ForwardRule = {
// ルールを見分けるための ID です。
id: string
// forward は URL を変えずに、別の内部パスを返します。
type: "forward"
// どの URL に一致させるかを書きます。
source: string
// 同一サイト内の相対パスだけを指定できます。
destination: string
// path は既定です。regex では $1 / $2 の番号参照を使えます。
patternSyntax?: "path" | "regex" | "glob"
// クエリ文字列をどう扱うかを指定します。
query?: "preserve" | "drop" | "replace" | QueryConfig
}
type QueryConfig = {
mode?: "preserve" | "drop" | "merge" | "replace"
params?: Record<string, string>
encode?: "component" | "none"
} 既定の `patternSyntax` は `path` です。これは path-to-regexp 系でよく使われる `:name`、`:name*`、`:name(正規表現)` のようなパスパラメータ記法に寄せた 200stack のルールです。 実装ではこの記法を 200stack 側で解釈し、取り出した値を `destination` や `query.params` に展開します。
:slug
`/blog/:slug` は `/blog/hello` に一致し、`slug=hello` を取り出します。`/blog/2026/hello` のようにスラッシュをまたぐ値には一致しません。
:path*
`/guide/:path*` は `/guide/a/b/c` に一致し、`path=a/b/c` を取り出します。ドキュメント配下など、複数階層の URL をまとめて別パスへ移すときに使います。
:name(正規表現)
`:` の後ろは任意のパラメータ名です。`:year(\\d{4})` なら `year` という名前の値を 4 桁の数字に限定し、`:id(\\d+)` なら `id` を 1 桁以上の数字に限定します。`year` だけが特別に使えるわけではありません。
{path}
`source` で `:path*` として取り出した値は、`destination` 側で `{path}` として使えます。例: `/guide/intro/setup` を `/docs/intro/setup` に内部フォワードできます。
$1 / $2
`patternSyntax: "regex"` を使う場合は、JavaScript の `RegExp` に近い書き方になります。`source: "^/items/(\\d+)-(\\w+)$"` のように括弧で取った値は、`destination` で `$1`、`$2` として参照します。
{slug} 展開ではなく、括弧でキャプチャした順番に応じて $1、$2 のような番号参照を使います。
`priority` がある場合は数値が小さい順、同じ優先度では配列順に評価されます。最初に一致したルールだけが適用されます。
`/old/:slug` の `:slug` は `{slug}` として destination へ渡せます。正規表現ルールでは `$1`、`$2` のような番号参照も使えます。
既定では元のクエリを維持します。不要な場合は `drop`、固定値を足したい場合は `merge` を使います。
外部 URL へ飛ばす場合は `https://`、`allowExternal: true`、`allowlistHosts` が必要です。意図しないオープンリダイレクトを防ぐためです。
TROUBLESHOOTING
まず dashboard の状態表示とログを確認します。解決しない場合は、該当画面と確認済みの内容を添えてお問い合わせください。
GitHub App の連携状態、対象リポジトリ、対象ブランチ、最新 push の有無を確認します。
dashboard のデプロイログ、ビルドコマンド、依存関係、環境変数を確認します。
対象ホスト、source の書き方、priority、enabled、redirect / forward の違いを確認します。
本サイト(www.200stack.com)における200stackの計測状態をこのブラウザで確認し、いつでも停止または再開できます。
現在の状態
停止すると、このブラウザでは計測用識別子の保存および任意のサイト分析イベントの送信を停止します。設定は Cookie に保存されるため、ブラウザや端末を変えると別の設定になります。お客様の公開サイトでは、そのサイト上の案内をご確認ください。