Image: AI generated
how-make-questはクエストCLIを素手で建てる方法であり、reinsはその不変をフレームワークとして抜き出した。この記事はその系譜の次のマスだ — 同じ命題を一つのドメインに打ち込んだ道具、abloq(Agentic blog Quest)。
記事は出てくる、ただ信用できないだけ
エージェントにブログを任せてみた人は知っている。記事は出てくる。 テーマを投げるだけで資料を集め、段落を積み上げ、それらしい一本を出してくる。本当の問題は別のところにある — 信用できないこと。
エージェントは出典を捏造する。存在しないURLを脚注に打ち込み、タイトルと無関係なページを引用として添える。直してもいない記事のlastmodをこっそり上げて新鮮に見せる。ある記事を手直しせよと頼んだら、隣の記事のfront matterやレイアウトまで触る。だから結局、人が全部読み直すことになる。ところが人がすべての記事を一行ずつ検査するなら、そもそも任せた意味がない。 自動化が検査労働を新たに生み出したわけだ。
これはモデルを大きくすれば消えるものではない。自分の記事を自分で判定させておく限り、能力が上がっても判定の隙間をより上手く見つけるだけだ。
人が書くのは一枚だ — insight.yaml
abloqの答えは分業だ — 生成は確率的でいい、検証は決定論的でなければならない。 散文を建てる非決定労働はエージェントが担い、その産物の合否は機械が決める。
だから人が書くのはインサイト仕様一枚、insight.yamlだけだ。テーマ・観点・扱う主張(claims)を、機械が照合できる形で記す。
# insight.yaml — 人が書く全部
topic: "robots.txt — 30年の慣行が標準になるまで"
stance: "robots.txt はアクセス制御装置ではなくシグナルだ"
claims:
- id: rep-standardized-2022
text: "robots.txt 慣行は1994年に始まったが IETF 標準(RFC 9309)になったのは2022年だ"
requires_source: true
anchors: ["RFC 9309", "1994"]
ここに記されたclaimsが執筆ゲートの基準になる。仕様にない主張は記事の本論になれず、仕様にある主張は本文に対応しなければならない。 資料収集・執筆・推敲・翻訳・発行・更新はその先すべてエージェントの仕事だ。
blog.yaml — ブログ一つの全宣言
仕様が記事一本のSSOTなら、blog.yamlはブログ一つのSSOTだ。サイト・言語・セクション・記事の正規構造・GEO閾値・配備を一つのファイルに収める。
site: { baseURL: https://example.com, title: My Blog }
languages: [en, ko, ja] # 先頭項目 = 既定言語
sections: [tech, opinion]
structure:
order: [image, attribution, body, related, sources, changelog]
geo: { min_sources: 1, freshness_days: 90 }
ここからhugo.toml・robots.txt・llms.txt・sitemap(hreflang)・JSON-LD・ゲートルールのパラメータが全部派生する。blog.yamlが変わらない限り、どの記事もゲートを迂回できない — 制約は契約だ。 宣言を手でコピーしておいた設定ファイル同士が食い違うドリフトが、構造的に不可能になる。
FAILは意見ではなく事実だ
エージェントが記事を提出(submit)すると、ゲートが判定する。以下は実際の運行記録だ — エージェントが出典セクションを欠落させ、到達不能なURLを引用として添えたとき:
en/tech/robots-exclusion-protocol -> FAIL
- min-sources: content/en/tech/robots-exclusion-protocol.md:1
actual="sources section missing — geo.min_sources requires >= 1"
- citation-exists: content/en/tech/robots-exclusion-protocol.md:19
actual="https://www.robotstxt.org/orig.html is not reachable (HTTP 403)"
FAILは「ちょっと変だけど」のような意見ではない。位置(ファイル:行)と期待値が打ち込まれた事実(Fact)だ。 直すべきは推測ではなくその Fact 一つだ。エージェントはこのフィードバックで収束し、修正提出が全ルールを通過してはじめて機械がPASSをロックする。
ここでhow-make-questの逆説が再び作動する。モデルはおべっかを言う — 指示に素直に従う。意見にはおべっかが毒だが、事実にはおべっかが資産だ。 Factを返してやれば、おべっかするモデルほどそのFactを素直に受け入れて収束する。
ロックされたものは戻せない — ratchet
ゲートの核心は判定ではなく不可逆性だ。一度ロックされたPASSは後ろへ滑り落ちない。次のセッションのエージェントが同じ記事を台無しにしても、基準線の下へは降りられない。
だからエージェントは使い捨てでも進行は累積する。 コンテキストが飛び、モデルが変わり、セッションが切れても、ロックされたマスはロックされたまま残る。これがratchetだ — 通過した分だけロックし、ロックしたものは回帰を許さない。完了判定の権限を確率的なLLMではなく決定的な機械に置く理由でもある。自己検証が性能をほとんど上げられないことはすでに測定された事実であり、LLM-as-Judgeが構造的に不可能である以上、判定者はコードでなければならない。
五つのクエスト、それぞれゲートで閉じる
abloqは散文を触る非決定労働だけをクエストとして残す。検出・生成・測定・外部API呼び出しは決定的なコードが担い、エージェントは記事を書く五つの仕事だけをする。各クエストはゲートで閉じる。
| クエスト | トリガー | ゲート(核心) |
|---|---|---|
| writing | 人の insight.yaml | 仕様の各項目が本文に対応 · 引用の実在検証 · 出典 ≥ 閾値 |
| translation | 新規記事 + 本文の実変更 | 構造無損失(translation-parity) + 全言語 slug 一致 + ビルド0エラー |
| refresh | 鮮度スキャナのキュー | 本文の実変更を伴う · 空の lastmod 更新を遮断(honest-lastmod) |
| evidence | 主張-出典スキャナのキュー | 出典 ≥ 閾値 · 新規引用の実在 · キュー外の主張は一文字も不変 |
| cluster | クラスタスキャナのキュー | タグが taxonomy に存在 · 孤児タグ0 · 内部リンク ≥ 閾値 |
cheese防御は全クエスト共通だ。front matter保存、ゲート判定と保存庫反映のバイト一致、キューアイテムの範囲外ファイル変更の禁止。エージェントは外部APIを直接叩かない — アーカイブ・インデックスのような副作用はバックエンドの領収書で処理される。
測定が次の労働を指定する — GEOは運用だ
AIがあなたの記事を引用しているかは直接観測されない。abloqはプロキシ3層で測定する — クロール層(CloudFrontログのAIボットヒット、決定的)、インデックス層(GSC表示・クリックの推移、決定的)、引用層(標準クエリのセットを周期実行し、AI応答内の引用を趨勢として記録、非決定なのでゲート化しない)。
核心は測定がそこで終わらないことだ。測定結果は優先順位キューの重みとなり、次のクエストの入力を指定する。古い記事はrefreshキューへ、無出典の主張はevidenceキューへ、孤立した記事はclusterキューへ落ちる。測定が労働を指定するratchet — だからGEOは状態ではなく運用だ。 一度最適化して終わるスコアではなく、回り続けるループだ。引用を引き上げる要素(出典・統計・引用文)が可視性を有意に高めることは、生成エンジン最適化の研究が定量で示したところだ。
reinsの上で — 系譜
abloqのゲートは素地から始まらない。決定論的ゲートエンジンreinsの上に立つ。reinsがratchet・コマンド骨格(scan/next/submit)・集計・exportを供給し、abloqはブログドメインのゲート(構造・根拠・政策のルールセット)だけを実装する。
系譜は明白だ。how-make-questがクエストを素手で建てる原理を教え、reinsがその原理をフレームワークとして抜き出し、abloqがそのフレームワークをブログという一つのドメインに打ち込んだ。同じ一文が三度、異なる高度に着地する — 生成は確率的、検証は決定論的。
この記事もabloqがロックした
この記事はabloqのwritingクエストで書いた。上に示したinsight.yamlを種にシード(scan)し、執筆プロンプトを受け取って(next)本文を書き、提出(submit)してゲートを通過させた。出典セクションが閾値を超えるか、引用URLが実際に到達可能か、仕様のすべてのclaimが本文に対応するか — その判定を人の目ではなく機械が下した。
執筆エージェントは自分の記事をREVIEWできない。REVIEWは必ず別のコンテキストのレビュアーが作成し、review-recordルールがその隔離を決定的に検査する。おべっかする判定者を構造的に排除すること — この記事が自分自身を称賛できないように仕込んだ装置が、この記事が説明するまさにその原理だ。
約束が検証可能で、違反が定義されていて、強制されるとき、システムは収束する。ブログも例外ではない。
関連記事
- reins — Quest CLIからドメインだけを残し、ratchetはフレームワークへ — abloqのゲートが乗った決定論的ゲートエンジン。
- Quest CLIの作り方 — 完了を機械に判定させる原理(なぜ)と骨格(どうやって)。
- huma — エンドポイントを飛ばさないratchet — 同じratchetをAPIテストドメインに適用した事例。
- Ratchet Pattern — 通過した分だけロックして回帰を防ぐパターン。
- 「完了」は誰が定義するのか — 完了判定をcheese不可能な機械ゲートへ移すこと。
- GEO: AIにあなたの記事を引用させる — abloq可視性層の理論的土台。
一緒に読みたいもの(外部)
- abloq — GitHub リポジトリ — フレームワーク本体・ゲートルールセット・クエストパック(MIT)。
- reins — GitHub リポジトリ — abloqが乗ったゲートエンジン(MIT)。
- llms.txt 提案 — AIのためのサイトインデックス慣行。
出典
- Aggarwal, P. et al. (2024). “GEO: Generative Engine Optimization.” KDD 2024. arXiv:2311.09735 — 出典・統計・引用文の追加が生成エンジン内の可視性を定量で高めるという測定。abloq可視性運用の根拠。
- Stechly, K., Valmeekam, K., & Kambhampati, S. (2024). “On the Self-Verification Limitations of Large Language Models.” arXiv:2402.08115 — 自己検証は性能をほとんど上げられない → 完了判定権限を決定的機械に置くべき理由。
- Koster, M., Illyes, G., Zeller, H., & Sassman, L. (2022). “Robots Exclusion Protocol.” RFC 9309 — 30年の慣行がIETF標準になった事例(robots.txt例の出典)。
変更履歴
- 2026-06-11: 初版