コンテンツにスキップ

ガイド — この Playbook はどう動くのか

最終更新: 2026-08 · owner: Youngjin · volatility: 低（プロセスページ — パイプライン変更時のみ更新） ← index へ

L0 TL;DR：このサイトはニュースアーカイブではなく、検証パイプラインです。新しく登場した技術・論文・発表がすぐ本文に載ることはありません — 自動スキャンが候補を集め、人が一次ソースで検証し、4 つのうち 2 つの関門（THE FILTER）を通過したものだけが本文に上がります。掲載された後も鮮度は自動監視され、4 言語で同期され、ビルドゲートを通過してはじめてデプロイされます。

全工程を一目で

graph TD
    A1["🤖 日次自動スキャン<br>(毎日 02:00 UTC — arXiv·ウェブ)"] --> R
    A2["💬 SA タレコミ<br>(昇格パイプライン)"] --> R
    A3[🔍 手動調査] --> R
    R["Radar キュー<br>すべて「未検証 [4]」ラベル — 顧客提案での使用禁止"] --> V["一次ソース検証<br>人 + 検証エージェント (公式発表·論文原文と照合)"]
    V --> F{"THE FILTER<br>ⓐ production 検証 ⓑ AWS マッピング ⓒ 実際の問い合わせ ⓓ GA"}
    F -- 2 つ以上充足 --> P["ピラー本文へ昇格<br>(owner が標準テンプレートで)"]
    F -- 未達 --> K["Radar に一行で維持<br>(昇格条件を明記)"]
    P --> AFTER[掲載された後も]
    AFTER --> M1["⏳ 鮮度の自動監視<br>(volatility 別に 1/3/6 か月を超過するとバッジ)"]
    AFTER --> M2["🌐 4 言語同期<br>(ko 原本 → ko_hash → en/zh/ja)"]
    AFTER --> M3["✅ strict ビルドゲート (アンカー·リンク検証)<br>→ GitHub Pages へ自動デプロイ"]

① どうやって作られたか

このプレイブックは、完結したスペック文書（マスタープロンプト）から生成されました。情報構造（5 つのピラー + 意思決定ツリー + Radar + メンテナンスルール）と包含基準がスペックに固定されており、各ページは敵対的検証（事実誤り·誇張を探す別個の検証ステップ）を経ています。実際にこの段階でバージョンの誤記·ライセンス誤りなどが捕捉されました — 「生成したから信じる」ではなく「生成したものも検証する」が原則です。

② 何が載り、何が弾かれるか

すべての項目は THE FILTER を通過しなければ本文に載りません：ⓐ production 検証 ⓑ AWS マッピング可能 ⓒ 実際の問い合わせ履歴 ⓓ GA（またはロードマップ）— 4 つのうち 2 つ以上。「新しく出た」「デモが印象的だ」は包含の理由になりません。掲載された項目には成熟度ラベル（🟢 GA / 🟡 Preview / 🔵 Research / ⚪ Hype）とソース等級（[1] 公式ドキュメント ~ [4] 未検証）が付きます — ラベルの読み方はホームにあります。

③ Radar と日次自動スキャン

フィルターをまだ通過していないものは Radar（キュー）に一行で存在します。毎日 02:00 UTC に自動スキャンが走り、最新の論文·ニュースを Radar の「最新スキャン流入」セクションに満たします（新規がない日は更新なし）。重要なのは、自動流入分はすべて未検証 [4] として隔離され、顧客提案に使ってはいけないという点です。自動化は候補をキューに載せるところまでしか行いません。

④ 検証と昇格 — 人の役目

流入項目の一次ソース確認（公式発表·論文原文·ライセンス照合）と昇格判断は人が行います。自動スキャンはもっともらしい誤り（例：存在しない製品世代名）を作りうるため、検証なしには昇格されません。一次ソース検証は owner が一人で行う必要はなく、複数人で分担できます — 参加者は昇格イシューと項目下部の 検証: フィールドに記録します。通過すれば owner が標準テンプレートで該当ピラーに編入し、Radar から除去します。全手順は昇格パイプラインを参照してください。

⑤ 鮮度の自動監視

掲載された項目も古くなります。ページごとに変動性（volatility）等級があり — 高 1 か月 / 中 3 か月 / 低 6 か月 — 更新なしに基準を超えると、デプロイ時にそのページ（4 言語すべて）に「⏳ 要レビュー」バッジが自動注入されます。毎日再デプロイが走るので、プッシュがなくてもバッジは最新状態を維持します。バッジが見えたら、そのページは再レビュー待ちという意味です。

⑥ 4 言語同期

韓国語が原本で、英語·中国語·日本語は派生物です。各翻訳ファイルは翻訳時点の原本の指紋（ko_hash）を記録しているため、原本が変わればどの翻訳が遅れているかを自動検知します（CI1 警告）。用語は共用用語集で 4 言語にわたり一貫して維持されます。言語切り替えはページ右上のドロップダウンです。

⑦ デプロイパイプライン

main にプッシュされると、CI が鮮度チェック·翻訳同期チェックを走らせ、strict ビルド（壊れたリンクやアンカーが一つでもあれば失敗）を通過した場合にのみ GitHub Pages へデプロイします。つまり、いま見ているすべてのページはこのゲートを通過した状態です。

⑧ レビュー実務ガイド（owner · 検証担当）

ページ owner や検証担当に指定されたら、以下がレビューのすべてです。必要なのはリポジトリへのアクセス権 + このページ 10 分だけです。

いつ — システムが教えてくれます。 ライブページ上部に 「⏳ 要レビュー」バッジが表示されたら、そのページの番です（揮発性別 1/3/6 か月の基準超過時に自動付与）。先回りして見るには、リポジトリで python3 scripts/check_staleness.py --check の 1 行で全ページの現況が出ます。

どこで — リポジトリの韓国語原本。 GitHub リポジトリを clone し、docs/<ページ>.md（ko）をレビューします。ライブサイトは確認用で、編集は常にリポジトリで行います。

どうやって — 5 ステップ：

  1. 事実照合 — 各項目名に付いた公式ソースへのリンク（全数接続検証済み）を開き、バージョン・ライセンス・GA 状態がまだ正しいかを一次ソースで確認します。
  2. 揮発性ブロックの更新 — 折りたたみの <details> ブロックは、その中のバージョン・価格・リージョン数値だけ触れば済むよう設計されています。本文（安定層）は原理なのでほとんど変わりません。
  3. メタデータの更新 — レビューを終えたら updated: を現在の年月にします。これがバッジを消す唯一の正当な方法です（脚注・表記整理などの非コンテンツ作業では上げません）。
  4. 4 言語の同期 — ko を直したら en/zh/ja に同じ変更を反映し ko_hash を更新します（手順はリポジトリの CLAUDE.md、用語は i18n/glossary.md）。
  5. ゲート通過後にプッシュ — python3 scripts/check_translation_sync.py（非同期 0）と mkdocs build --strict（exit 0）を通過してからコミットします。main へプッシュ → 自動デプロイ。

言語別に分担する場合 — owner はページごとに 1 名（ko 原本基準）で、言語分担者は項目の 検証: フィールドに記録される検証担当です。覚えるルールは 1 つだけ：翻訳ファイルを直接直さず、常に ko 原本から。ko が変わると同期チェックが遅れた翻訳を教えてくれるので、言語レビュアーはそのファイルだけ用語集に沿って更新すれば済みます。

役割別ガイド

私は… こう使えばよい
ただ読む人 ホームの FAQ Top 20 またはピラーから入る。ラベル（🟢🟡🔵⚪）とソース等級（[1]~[4]）さえ分かれば、信頼度をすぐに読み取れます
項目をタレコミしたい人 昇格パイプラインへタレコミ。THE FILTER 4 つのうちいくつを充足するかも併記すると早いです
owner 日次自動流入のレビュー → 一次検証 → 昇格/維持の判断。メンテナンスルール全体を参照

  1. CI（Continuous Integration） — コミット・プッシュのたびに検査とビルドを自動実行するパイプラインです。このリポジトリでは鮮度チェック・翻訳同期チェック・strict ビルドが CI で走り、すべて通過してはじめてデプロイされます。 ↩