モデルの要約性能を比較する2 - Gemini 3 Pro vs GPT-5.1 vs Grok 4.1 vs Claude Sonnet 4.5 -

概要

• Gemini 3 Pro
• GPT-5.1
• Grok 4.1
• Claude Sonnet 4.5

4モデルの要約性能を検証します。

ここで取り扱う"要約性能"とは「以下のプロンプトを用いて記事を要約した際に、私がどれくらい満足いく要約になるか」といった限定的かつ主観的なものになります。
あらかじめご了承ください。

要約に利用するドキュメントには、私が直近に書いたZennの記事を利用します。

現在は要約用にGitHub Copilot経由でClaude Sonnet 4.5を利用しています。
これを超える性能のものを探したいです。

利用するプロンプト

https://zenn.dev/beagle/articles/fd60745bc54de1
このURLの内容を要約して、ファイルに保存してください。
出力結果は以下のテンプレートに従ってください。

## 概要(どのようなことを記述しているか)
## 要点(文中の重要なポイント)
## 結論
## 特記事項(文中に記載されたユニークなポイント等)

びーぐるAI(手動)

まさかの人力…いや犬力です。

概要(どのようなことを記述しているか)

Agentic Codingの開発スタイルとして、仕様駆動開発(SDD)が以前にも増して注目を浴びている。
本記事では、SDD自体とその中核をなす"仕様"について、その特徴や考え方、デメリットなどを紹介している。

要点(文中の重要なポイント)

• SDDとは、まず仕様と呼ばれるドキュメントを作成し、その仕様に基づいてコーディングを行う手法
• Vibe Codingの様々な課題をクリアできる手法として注目されている
• 仕様とは、これから制作するものに関してWhat, Why, Howをまとめた一連のドキュメント
• SDDにおいて、仕様はSSoT
• 仕様はAgentic Codingに適応できるような様々な性質を持つ
• SDDを実践するためのツールが多数あり、Kiro・cc-sdd・Spec Kitなどが代表例

結論

SDDはAIコーディングエージェントを用いた開発において、仕様を中心に据えて確実な実装を行うための有力な手法である。反面、SDDにはいくつかのデメリットが有り、銀の弾丸ではない。
プロジェクトの特性に応じてどこまで取り入れるかを柔軟に判断する必要がある。

特記事項(文中に記載されたユニークなポイント等)

• 仕様駆動開発〜新たな開発手法の可能性と実践〜」では、昼開催にもかかわらず1300人を超える参加者が集まり、SDDの注目度の高さが伺い知れる
• SDDではコードはAIがプログラミング言語やフレームワークを利用して仕様を表現したものと言われる
• 広義の仕様と狭義の仕様があり、SDDの文脈では一連のドキュメント仕様とする「広義の仕様」と解釈する
• SDDでは仕様をSSoTとして育てていく感覚が重要

Gemini 3 Pro

Gemini(ブラウザ)

概要(どのようなことを記述しているか)

AIコーディングエージェントの普及に伴い注目を集めている「SDD（仕様駆動開発）」について、その定義、特徴、思想、および具体的なツールやメリット・デメリットを整理・解説している記事です。AIに設計や実装を一任する「Vibe Coding」の課題（品質や保守性の問題）を解決する手法としてSDDを位置づけ、その中核となる「仕様」のあり方について詳述しています。

要点(文中の重要なポイント)

• SDDの再注目の背景: 自然言語で要求のみを伝えAIに実装させる「Vibe Coding」は手軽だが、品質や保守性に課題がある。SDDはその解決策として期待されている。
• 仕様の定義と役割:
  • 仕様は「What(何を作るか)」「Why(なぜ作るか)」「How(制約)」をまとめたドキュメント群（仕様定義書、技術設計書、実装計画書など）。
  • 仕様は**SSoT（信頼できる唯一の情報源）**であり、すべての工程の中心となる。
• SDDにおける仕様の特徴:
  • 実行可能: AIが理解しコーディングを遂行できる構造化されたフォーマットであること。
  • 検証可能: テストコード生成などにより、実装が仕様に基づいているか客観的に確認できること。
  • 双方向同期性: 基本は「仕様→コード」の流れだが、コード修正時は仕様へ確実に反映させ、乖離を防ぐ必要がある。
• 主なツール: Kiro（AWSのAI IDE）、cc-sdd（CLIツール）、GitHub Spec Kitなどが紹介されている。
• 課題・デメリット: 仕様の作成・維持コストがかかる点や、LLMの能力に依存する点、オーバーエンジニアリングになるリスクなどがある。

結論

SDDは、AIコーディングエージェントを活用しつつ、持続可能で高品質な開発を行うための有効なアプローチである。ツールや手法は発展途上であるが、仕様をSSoTとして中心に据え、AIと協働して仕様とコードを洗練させていくプロセスが重要となる。

特記事項(文中に記載されたユニークなポイント等)

• 「仕様はガードレール」: AIが仕様に従うことで暴走を防ぎ、制御可能にするという観点。
• 広義と狭義の仕様: 一般的な「要件定義書」単体（狭義）と区別し、SDDでは作成された一連のドキュメント全体（広義）を「仕様」と定義し、それら全てをSSoTとみなす点。
• Vibe Codingとの対比: 直感的な「Vibe Coding」から、規律ある「SDD」への移行をAI時代の開発文化の進化として捉えている点。

GPT-5.1

ChatGPT(ブラウザ)
ChatGPT-5.1-thinking-じっくり思考

概要(どのようなことを記述しているか)

AIコーディングエージェント時代に注目されている「SDD（仕様駆動開発）」について、その概要・思想・メリット/デメリットを整理しつつ、SDDにおける「仕様」とは何かを掘り下げて解説した記事です。また、SDDを体現する具体的なツール（Kiro、cc-sdd、GitHub Spec Kitなど）も紹介しています。(Zenn)

要点(文中の重要なポイント)

• SDDとは何か

  • Spec-Driven Development（仕様駆動開発）の略。
  • まず仕様ドキュメントを作り、その仕様に基づいてAIコーディングエージェントがコードを書く開発手法。(Zenn)
  • Vibe Coding（要望だけ伝えてあとはAI任せ）に対する、品質・保守性・手戻り問題を解消するためのアプローチとして注目されている。

• SDDにおける「仕様」とは

  • What / Why / How（何を・なぜ・どんな制約で作るか）をまとめた一連のドキュメント群。(Zenn)
  • 「仕様定義書」「技術設計書」「実装計画書」など複数の文書の集合であり、SDDではこれ全体を仕様と呼ぶ（広義の仕様）。
  • 仕様はSSoT（Single Source of Truth：唯一の正しい情報源）として扱われ、AIも人間も常にこれを参照して開発を進める。

• 仕様に求められる性質

  • 実行可能：自然言語だが構造化されており、AIがそのままコーディングに使える状態。完全性・正確性・明確さが必要。(Zenn)
  • 検証可能：仕様からテストコードが生成でき、実装が仕様通りか客観的に確認できる。
  • 追跡可能・監査可能：Gitなどでバージョン管理し、誰が何をなぜ変更したか履歴を追える。(Zenn)
  • 仕様とコードの双方向同期：原則は「仕様→コード」だが、緊急対応でコードをいじった場合も必ず仕様側に反映し、乖離を防ぐ。

• SDDの思想・特徴

  • コードは「仕様をプログラミング言語で表現したもの」という位置付け。
  • 仕様はガードレールとしてAIの暴走を防ぎ、SSoTとしてチームの共通認識になる。
  • 仕様自体をイテレーション（反復改善）し、実装フィードバックを受けて磨いていくことが前提。(Zenn)
  • チーム開発において、Biz/Devなど異なるロール間のコミュニケーションギャップを埋える効果が期待される。

• 代表的なSDDツール

  • Kiro（AWS提供のAI IDE）

    • 対話形式で要求定義書・詳細設計書・タスクリストを作成し、そのままコーディングへ進める。
    • 平易なドキュメント・進捗把握のしやすさなどから、エンジニア以外にも扱いやすい。(Zenn)

  • cc-sdd

    • Claude CodeやCodex、Cursorなど既存ツール上でSDDを実践するためのツールキット。
    • Kiro的なワークフローを他ツールに持ち込む位置付け。

  • GitHub Spec Kit

    • Constitution / Spec / Plan / Tasks の4フェーズを持つ重厚なツールキット。
    • 複雑なソフトウェアや大規模開発でも対応できるよう設計されている。(Zenn)

• SDDのデメリット・懸念点

  • 仕様の作成・変更・維持にコストがかかる
    → 小さなPoC・短命プロトタイプだと割に合わない。
  • 仕様の品質に強く依存する
    → 仕様が曖昧なまま進めると、手戻りが大きくなる点は従来と変わらない。
  • 学習コストが高い
    → 特にSpec Kitは重厚で習熟が必要、Vibe Codingに比べて初心者にはハードルが高い。
  • コードファースト文化からの転換が難しい
    → 「まず仕様を書く」という文化的な変化が求められ、慣れるまでストレスになりうる。
  • モデル・ツールへの依存
    → モデルの能力や挙動変更、ツールのメンテ状況にワークフローが左右される。
  • オーバーエンジニアリングのリスク
    → 高性能モデル×堅牢な仕様で、必要以上にリッチで重い実装になりがち。(Zenn)

結論

• SDDは、AIコーディングエージェントを前提とした開発において、仕様をSSoTとして中心に据え、確実でトレーサブルな実装を行うための強力な手法である。(Zenn)
• しかし、銀の弾丸ではなく、仕様の作成・更新コスト、学習コスト、モデル/ツール依存、オーバーエンジニアリングなど無視できないデメリットも多い。
• 中長期で保守されるプロダクトや、品質・変更履歴・共通認識が重視される領域では大きな効果を発揮しうる一方、短期PoCや要件が激しく変わるプロダクトには過剰になりかねない。
• 重要なのは、プロジェクトの特性に応じてSDDをどこまで取り入れるかを柔軟に判断することであり、AIコーディングの進化に伴ってSDD自体の位置づけも変わり得る、というスタンスで捉えるべきと締めくくられています。(Zenn)

特記事項(文中に記載されたユニークなポイント等)

• 「仕様」は単一のドキュメントではなく、仕様定義書＋技術設計書＋実装計画書などの“束”をまとめてSSoTとみなすという広義の定義が強調されている。(Zenn)

• 仕様に対して、

  • 実行可能（AIがコード生成に直接使える）
  • 検証可能（テスト生成と整合性チェックができる）
  • 追跡・監査可能（バージョン管理で誰が何を変えたか分かる）
  • ガードレール（AIの暴走を防ぐ）
  • イテレーション可能（実装からのフィードバックで継続改善）
    といったかなり理想志向な要件セットを提示している点が特徴的。(Zenn)

• GitHub Spec Kitの「Constitution（最高法規）」という概念など、仕様体系を“法体系”のように扱うメタファーが紹介されている。

• 「モデルの進化によっては、将来的にSDDそのものが不要になったり、別の形に置き換わる可能性もある」という、手法自体の賞味期限も視野に入れた慎重なスタンスが明示されている。(Zenn)

Grok 4.1

Grok(ブラウザ)
Grok 4.1 thinking

概要(どのようなことを記述しているか)

この記事は、AIコーディングエージェントの普及を背景に注目されている「仕様駆動開発（SDD: Spec-Driven Development）」の手法と、その中心となる「仕様」について、定義・背景・ワークフロー・特徴・ツール・デメリットを体系的に整理・解説したものです。Vibe Coding（感覚的なAIコーディング）の課題を解決するアプローチとしてSDDを位置づけ、実践的な理解を促す内容となっています。

要点(文中の重要なポイント)

• SDDは、詳細な仕様ドキュメントを作成し、それをSingle Source of Truth（SSoT）としてAIにコード生成を指示する開発手法
• 仕様には「What（何を作るか）」「Why（なぜ作るか）」「How（制約）」が含まれ、要件定義書・技術設計書・実装計画書などで構成される
• 基本ワークフロー：仕様作成 → AIによるコード生成 → 検証 → 仕様・コードの双方向同期を繰り返す
• 仕様の必須特性：実行可能、検証可能、追跡可能、ガードレールとしての役割、イテレーション可能
• 主なツール例：
  • Kiro（AWS提供、初心者向け）
  • cc-sdd（国産、Claude Code/Cursor対応）
  • GitHub Spec Kit（重厚な4フェーズ構成）
• デメリット：仕様作成・維持コストが高い、仕様品質への強い依存、学習コスト、モデル依存、オーバーエンジニアリングのリスク

結論

SDDはAI時代における確実性の高い開発手法として有効だが、銀の弾丸ではなく、プロジェクトの規模・保守期間・要件変更頻度に応じて柔軟に取り入れるべきである。小規模PoCでは過剰になる可能性があり、中長期的に保守が必要な案件で特に威力を発揮する。AIモデルの進化により将来的にSDD自体が不要になる可能性もあるため、状況に応じた選択が重要である。

特記事項(文中に記載されたユニークなポイント等)

• SDDの定義はまだ学術的に統一されておらず、人・ツールによって「仕様」の範囲（広義 vs 狭義）が異なる点に注意を促している
• 仕様とコードの「双方向同期」を厳格に守ること（コードを直接修正した場合も必ず仕様に反映する）を強調
• 2025年11月時点でFindy主催のSDDイベントに1300人以上が参加するなど、国内での注目度が極めて高い
• 著者は過去に同テーマの記事を公開しており、近日中の改訂を予告
• 複数の実践ツール（Kiro、cc-sdd、GitHub Spec Kitなど）が既に存在し、選択肢が豊富である点

Sonnet 4.5

ブラウザ(Claude)
Claude Sonnet 4.5

概要(どのようなことを記述しているか)

SDD(仕様駆動開発/Spec-Driven Development)について、AIコーディングエージェントを活用した現代的な開発手法として再度整理し解説している記事です。SDDの定義、仕様の概念、ワークフロー、特徴、実践ツール、そしてメリット・デメリットまで包括的に説明しています。

要点(文中の重要なポイント)

• SDDの背景: Vibe Codingの課題(品質・保守性の問題、手戻りの発生)を解決する手法として注目されている
• 仕様の位置づけ: 仕様はSSoT(Single Source of Truth=唯一の正しい情報源)であり、すべての工程の中心となる
• 仕様の要件: 実行可能・検証可能・追跡可能・監査可能である必要がある
• 仕様の品質: 仕様の品質が制作物の品質に直結するため、詳細に練り上げることが重要
• 代表的ツール: Kiro(AWS)、cc-sdd、GitHub Spec Kitなどがあり、それぞれ特徴が異なる
• 主なデメリット: 仕様作成・維持コスト、学習コスト、モデル能力への依存、オーバーエンジニアリングのリスク

結論

SDDは決して銀の弾丸ではなく、プロジェクトの特性に応じて適用を判断すべき開発手法である。中長期で保守されるプロダクトや品質・変更履歴の追跡が重要なプロジェクトでは大きな効果を発揮するが、要件が頻繁に変わるプロダクトや短期PoC開発では重厚すぎてコストが割に合わない場合もある。AIコーディングは進化の道半ばであり、SDDを含めた様々な開発手法を柔軟に観察・模索していくことが重要である。

特記事項(文中に記載されたユニークなポイント等)

• 仕様とコードの双方向同期性: 従来はコードがSSoTになりがちだったが、SDDでは仕様→コードの主従関係を固定化し、コードの直接変更があった場合は必ず仕様に反映させる
• 仕様はガードレール: AIコーディングエージェントが仕様に従う限り暴走は起こりにくく、仕様が間接的にAIを制御する役割を果たす
• 広義と狭義の仕様: 一般的なソフトウェア工学では単体のドキュメントを指すが、SDDでは作成された一連のドキュメント全体を指す
• オーバーエンジニアリングのリスク: 高性能モデルに堅牢な仕様を与えることで、過剰な実装が行われメンテナンス性低下やコスト増大につながる可能性
• 将来の展望: モデルの進化によってSDD自体が不要になる、または別の形に置き換えられる可能性も示唆されている

ここまでの結論

評価は
Grok 4.1 > Sonnet 4.5 >= Gemini 3 Pro > びーぐるAI(手動) >>> GPT-5.1
となります。

上位3モデルは合格ラインである手動要約を超えてきました。

Grok 4.1はとても優秀で、内容を網羅しながら記事に対する筆者の感情の度合いを読み切っているかのような要約で、驚きました。
Sonnet 4.5もバランスが取れていて悪くない要約です。特記事項に選んだ項目がちょっと変な感じもして、その差でGrokに後塵を拝したと思います。
Gemini 3 Proの要約としてのわかりやすさは一番良いですが、仕様の特徴が中途半端にピックアップされているのがちょっと謎です。要約＝端的にまとめる、を重視するスタイルで、自分の記事でなければGeminiがトップになっても不思議ではないです。手動要約とも内容は近いですし。

ということで、Sonnet 4.5を基本路線にしながら、うまく要約ができていないなと思ったらGrokやGeminiを代打に使えるような状態で、記事のまとめが大変捗りそうです。
次回は他のプラットフォームから利用したときの違いも調べてみます。

GitHub Copilot + Gemini 3 Pro(Preview)

概要(どのようなことを記述しているか)

Agentic Codingの文脈で注目されるSDD（仕様駆動開発）について、その定義、ワークフロー、特徴、メリット・デメリット、および関連ツール（Kiro, cc-sdd, GitHub Spec Kit）について解説している。Vibe Codingの課題に対する解決策としてのSDDの位置づけや、仕様をSSoTとする思想について詳述している。

要点(文中の重要なポイント)

• SDDの定義: 仕様（Spec）をSSoT（Single Source of Truth）とし、AIコーディングエージェントが仕様に基づいてコードを生成する手法。
• Vibe Codingとの対比: 自然言語のみで実装を一任するVibe Codingの課題（品質、保守性、手戻り）を解決する手段として期待されている。
• 仕様の要件:
  • 実行可能: AIが理解できる構造化されたフォーマットであること。
  • 検証可能: 仕様からテストコードを生成し、実装の準拠性を確認できること。
  • 追跡可能・監査可能: Git等でバージョン管理され、変更履歴が追えること。
• 仕様とコードの関係: 仕様からコードを生成する主従関係を原則とし、双方向同期を保つ。仕様はAIの暴走を防ぐガードレールとしても機能する。
• 代表的なツール:
  • Kiro: AWS提供のAI IDE。対話形式でドキュメント作成が可能。
  • cc-sdd: Claude CodeやCodexなどでSDDを実践するためのツールキット。
  • GitHub Spec Kit: GitHub提供。重厚な仕様作成が可能で、複雑な開発に対応。
• デメリット: 仕様作成・維持のコスト、学習コスト、オーバーエンジニアリングのリスク、コードファースト文化からの転換の難しさなど。

結論

SDDは中長期的な保守や品質が求められるプロジェクトや、共通認識の維持が重要なプロジェクトで有効である。しかし、銀の弾丸ではなく、PoCなどの短期開発ではコストが割に合わない場合もあるため、プロジェクトの特性に応じて柔軟に取り入れるべきである。

特記事項(文中に記載されたユニークなポイント等)

• 2025年11月時点での情報であり、AIモデルの進化によりSDD自体が不要になる、あるいは別の形に置き換えられる可能性も示唆されている。
• 著者は「cc-sdd」の開発者であるGota氏のツールや、AWSのKiro、GitHub Spec Kitなどを比較紹介している。

GitHub Copilot + Sonnet 4.5

概要(どのようなことを記述しているか)

AIコーディングエージェントを用いた開発手法であるSDD(Spec-Driven Development、仕様駆動開発)について、その定義、仕様の概念、ワークフロー、特徴、実践ツール、デメリットを総合的に解説した記事。SSDの基本概念から実践的な側面まで網羅し、AI時代の新しい開発手法としてのSDDの可能性と課題を明確にしている。

要点(文中の重要なポイント)

SDDの定義

• 仕様と呼ばれるドキュメントを作成し、その仕様に基づいてコーディングを行う開発手法
• AIコーディングエージェントの登場により改めて注目されている
• Vibe Codingの課題(品質や保守性の問題、手戻りの発生)をクリアできる可能性がある手法

仕様とは

• What(何を作るか) / Why(なぜ作るか) / How(どのような制約で作るか)をまとめた一連のドキュメント
• 代表的な構成例: 「仕様定義書」+「技術設計書」+「実装計画書」
• SDDにおいて仕様はSSoT(Single Source of Truth、唯一の正しい情報源)である

SDDの特徴や思想

1. 仕様は実行可能: 構造化されたフォーマットで記述し、AIが理解できるように作成
2. 仕様は検証可能: 明確に定義され、仕様とコードの準拠性を客観的に確認できる
3. 仕様の品質は制作物の品質に直結: 仕様の質を高めることがコードの質向上に繋がる
4. 仕様は追跡可能・監査可能: Git等でバージョン管理され、更新履歴を記録
5. 仕様とコードの双方向同期性: 仕様→コードの主従関係を固定化し、仕様の更新からコード再生成を行う
6. 仕様はガードレール: AIの暴走を防ぐ制御機能
7. 仕様はイテレーション可能: 実装からのフィードバックを受けて継続的に改善
8. チーム開発での有効性: 異なる役割を持つメンバー間の共通認識となる

SDDを体現する代表的ツール

1. Kiro: AWS提供のAI IDE、カジュアルで扱いやすく、SDDを広く知らしめるきっかけとなった
2. cc-sdd: Gotaさん開発のツールキット、主要なCLIツールやAI IDEに対応
3. GitHub Spec Kit: GitHub提供、4フェーズ(最高法規/仕様定義書/技術設計書/タスクリスト)で重厚な仕様作成が可能
4. その他: OpenSpec、Spec Workflow MCP など

SDDのデメリット

1. 仕様作成・変更・維持・改善のコストがかかる: 小規模プロトタイプやPoCでは割に合わないケースも
2. 仕様の品質に強く依存する: 仕様が曖昧なままでは手戻りが大きくなる
3. 学習コストがかかる: 特にSpec Kitは難解で初学者にはハードルが高い
4. コードファースト文化からの転換が難しい: 文化的な転換が求められる
5. モデルの能力に依存する: AIモデルやツールチェーンに依存し、挙動変更のリスクがある
6. オーバーエンジニアリングになる: 高性能モデルが過剰な実装を行う可能性

結論

• SDDはAIコーディングエージェントを用いた開発において、仕様を中心に据えて確実な実装を行うための有力な手法
• しかし銀の弾丸ではなく、仕様コスト、学習コスト、モデル依存、オーバーエンジニアリングなどのデメリットも存在
• 中長期で保守されるプロダクトや品質・変更履歴の追跡が重要な領域では大きな効果を発揮
• 要件が頻繁に変わるプロダクトや短期PoCではコストが割に合わない場合も
• プロジェクトの特性に応じてどこまで取り入れるかを柔軟に判断することが重要
• モデルの進化によってSDD自体が不要になる、あるいは別の形に置き換えられる可能性もある

特記事項(文中に記載されたユニークなポイント等)

• Findy様主催のイベント「仕様駆動開発〜新たな開発手法の可能性と実践〜」には1300人超が参加し、SDDへの関心の高さが示された
• SDDは現時点で学術的に統一された用語や定義が存在していない
• 広義の仕様と狭義の仕様の違い: 一般的には要件定義書のような単体ドキュメントを指すが、SDDでは仕様作成フェーズで作られた一連のドキュメント全体を指す
• 熟練の開発者はツールを使わず、直接LLMやAIコーディングエージェントを使用してSDDを実践することもある
• 現状のGPT-5.1-Codexなどの高性能モデルは、Vibe Coding気味に使っても必要以上にリッチな実装になりがち
• 記事公開日: 2025年11月19日、更新日: 2025年11月20日(誤字脱字・表現修正)

GitHub Copilot + OpenRouter + Grok 4.1 Fast

概要(どのようなことを記述しているか)

SDD(仕様駆動開発)の定義、仕様の役割と特徴、ワークフロー、関連ツール、デメリットを整理・解説。AIコーディングエージェントの文脈で注目される手法として、Vibe Codingとの違いを強調し、実践的な視点を提供。

要点(文中の重要なポイント)

• SDDとは仕様ドキュメントを作成し、AIコーディングエージェントがそれに基づいてコード生成する手法。Vibe Codingの課題解決を目指す。
• 仕様とはWhat/Why/Howをまとめたドキュメント群(仕様定義書、技術設計書、実装計画書等)。SSoT(Single Source of Truth)として機能。
• 特徴: 仕様は実行可能・検証可能・追跡可能・双方向同期・ガードレール・イテレーション可能。チーム開発に有効。
• ツール: Kiro(対話形式でドキュメント作成)、cc-sdd(CLIツール対応)、GitHub Spec Kit(重厚な仕様対応)。
• デメリット: 仕様作成コスト高、品質依存、学習コスト、コードファースト文化転換難、モデル依存、オーバーエンジニアリング。

結論

SDDは中長期保守プロダクトに有効だが、銀の弾丸ではなくプロジェクト特性に応じて柔軟活用。AI進化で手法が変わる可能性あり。

特記事項(文中に記載されたユニークなポイント等)

• 広義の仕様(ドキュメント群)と狭義の仕様(単一ドキュメント)の区別。
• 仕様とコードの双方向同期を原則としつつ、現実的な直接コード修正時の反映を強調。
• 作者自身がGitHub Spec Kitの記事執筆者で、近日改訂予定。
• イベント「仕様駆動開発〜新たな開発手法の可能性と実践〜」で1300人超参加の人気。

結論(GitHub Copilotを経由する場合)

GitHub Copilotのプレミアムリクエストを消化して要約を作成するならGemini 3 Proは良さそう。
一旦ここまでで〆
また何かアイデアがあったら試してみます。