AnchorSpecとは何か？AI協働開発で仕様迷子を防ぐ構造化プロトコル
What is AnchorSpec? A practical protocol for AI-assisted software development
基本情報
| 項目 | 内容 |
|---|---|
| 記事種別 | 編集部による実務解説 |
| 分類 | Developer |
| 情報元 | AIニュース話題度レーダー編集部 |
| 公開日 | 2026/06/30 |
| 確認日 | 2026/06/30 |
| 読む目的 | AnchorSpecは、AIにすべてを覚えさせるのではなく、意図・仕様・差分・変更要求・実装・検証を分けて管理するAI協働開発のためのプロトコルです。 |
先に押さえること
- AnchorSpecはプロンプト集ではなく、AI協働開発の状態管理プロトコルとして読む。
- Specに入れるのは合意済みの仕様だけ。違和感や未決事項はGapへ逃がす。
- Gapから直接Specを書き換えず、CRとして提案し、人間が確認してから反映する。
- Verifyは修正作業ではなく、仕様と実装の一致を検査して差分を記録する場所にする。
3行要約
- AnchorSpecは、長いAI開発で起きやすい文脈のズレや仕様の変質を、構造として見える場所に出すための考え方です。
- 中心は Intent、Gap、CR、Spec、Impl、Verify を分け、Specを合意済みの正本として扱うことです。
- 小規模な個人開発では、まず intent.md、spec.md、gap.md、verify.md の4ファイルから始めると運用しやすいです。
実務コメント
AIに正確な記憶を期待するより、判断軸と未決事項を外部Markdownに残す方が、長期の開発や複数AIの使い分けで効きやすいです。
AnchorSpecを一言でいうと
AnchorSpecは、AIと人間が同じ開発を長く進めるときに、意図、仕様、差分、変更要求、実装、検証を分けて管理するためのプロトコルです。
AIにすべての背景を覚えさせるのではなく、ズレが起きた場所を観測可能な構造として残し、合意済みの仕様へ戻す経路を作るところに価値があります。
なぜ今AnchorSpecが必要になるのか
AIコーディングは、小さな実装や修正では非常に速く進みます。一方で、会話が長くなるほど前提がずれたり、未レビューの判断が仕様のように扱われたりします。
この問題は、単にプロンプトを上手に書けば消えるものではありません。AIとの会話履歴だけに開発文脈を置くと、仕様の正本、未決事項、検証結果が混ざりやすいからです。
- Context Drift: セッションをまたぐうちに前提がずれる
- Specification Drift: 未承認の判断で仕様の意味が変わる
- Silent Spec Mutation: 明示していない仕様変更が実装に混ざる
- Shallow Verification: 動作確認だけで意図との一致を見ない
基本の流れ
AnchorSpecでは、開発の状態を次のように分けて扱います。これは作業順のメモではなく、責務を分けるための構造です。
Intent -> Gap -> CR -> Spec -> Impl -> Verify各レイヤーの役割
| レイヤー | 役割 | 混ぜないもの |
|---|---|---|
| Intent | なぜ作るか、何を優先するか、何をしないかを残す | 細かな実装案 |
| Spec | 合意済みの仕様をSource of Truthとして保持する | 未承認のアイデア |
| Gap | 曖昧さ、違和感、仕様の抜けを一時的に受け止める | 確定仕様 |
| CR | GapをSpecへ反映するための変更提案にする | 思いつきの直接反映 |
| Impl | Specに基づく実装として扱う | 仕様そのもの |
| Verify | 仕様と実装の一致を検査し、差分を記録する | 検証中の勝手な修正 |
最小構成で始めるなら4ファイル
最初から大きな管理体系にすると、運用の重さが勝ちます。小規模な個人開発や実験プロジェクトでは、まず4つのMarkdownだけで十分です。
anchorspec/
intent.md
spec.md
gap.md
verify.md- intent.md: 目的、判断軸、やらないことを書く
- spec.md: 現在合意済みの仕様だけを書く
- gap.md: 不明点、違和感、仕様の抜けを書く
- verify.md: 検査結果と見つかった差分を書く
通常の仕様書との違い
AnchorSpecは仕様書に似ていますが、仕様そのものを書くことだけが目的ではありません。仕様へ入る前の差分、変更提案、検証結果まで分けて扱う点が違います。
特に重要なのは、GapからSpecへ直接書き込まないことです。未決事項をSpecへ混ぜると、実装と検証の基準が濁ります。
OpenSpecやSpec Kitとの見分け方
AI時代の仕様駆動開発には複数の流れがあります。AnchorSpecという名前でも、Nia-Anoma版とanchorspec.com版は別物として見た方が安全です。
| 対象 | 見るべきポイント | この記事での扱い |
|---|---|---|
| Nia-Anoma版 AnchorSpec | AI協働開発における責務分離と状態遷移 | 主対象 |
| anchorspec.com版 | OpenSpecのtelemetry-free forkとしてのCLI寄りツール | 混同回避として紹介 |
| GitHub Spec Kit | 仕様駆動開発を進めるためのツールキット | 比較対象 |
向いているプロジェクト
- 長期間続く個人開発や業務ツール開発
- 複数のAIや複数セッションをまたぐ開発
- 要件が増え続けるWebアプリやSaaS
- 生成AIを使った記事制作、RAG基盤、社内ナレッジ運用
- 人間のレビューと承認ラインを残したい開発
向いていないケース
- 数十行で終わる使い捨てスクリプト
- 仕様変更がほぼない単純作業
- 人間がレビューしない完全自動実装
- AIの正しさを保証する仕組みだと期待している場合
実務で使うときの合図
AIとの作業中に、何度も同じ前提を説明している、以前決めたはずの方針が変わっている、検証のたびに別の場所が壊れる。このあたりが出始めたらAnchorSpecの出番です。
最初の一歩は、すべてを体系化することではありません。今のプロジェクトのIntentとSpecを短く書き、迷ったことをGapに逃がす。それだけでも、会話の勢いで仕様が壊れる確率は下げられます。