GitHub Spec KitをAIコーディングに入れる前に：Spec・Plan・Tasks・Implementの使いどころ

3行まとめ

このテーマをもう少し広げて見るなら、GitHub Agentic Workflowsを導入する前に：AI Engine・MCP・権限境界をGitHub Actionsで分ける と Codex subagentsをチームで使う前に：並列レビュー・権限・コストの境界線 も合わせて確認してください。Spec KitをCIやworkflowへ広げる前に、GitHub Actions側の権限境界を確認できます。

大きめの曖昧さに向く

要求、設計、作業分解、実装を段階ごとにレビューできます。

小さな修正では重い

数行の修正や緊急対応では、導入コストが作業速度を落とすことがあります。

権限と停止条件を先に決める

公式由来の導入元、拡張の信頼境界、人間レビューの条件を確認します。

Spec KitはAIを賢くする追加モデルではなく、実装前の合意を作るための道具です。

• GitHub Spec Kitは、AIにいきなり実装を頼むための魔法ではなく、要求、設計、作業分解、実装を段階ごとにレビューできる形へ分けるための道具です。
• 公式ドキュメントでは、中心の流れはSpec、Plan、Tasks、Implementです。Codex統合では.agents/skillsとAGENTS.mdが使われるため、既存のリポジトリ運用とぶつからないかを先に見ます。
• 2026年6月2日時点で最新リリースはv0.9.0でした。導入前は公式リポジトリ由来のインストール、拡張機能の信頼境界、人間レビューの停止条件を決めてから試すのが現実的です。

この記事でわかること

4フェーズの役割

Spec、Plan、Tasks、Implementが何を分けるためのものかを確認します。

agent連携

Codex、Claude Code、Copilotへ入れる前に置き場所と指示の重複を見ます。

信頼境界

公式パッケージ、コミュニティ拡張、社内テンプレートを分けて扱います。

停止条件

Implementへ進む前に、人間が止める条件を決めます。

パイロット評価

最小構成で試し、手戻りとレビューしやすさを見ます。

読む目的は、Spec Kitを入れるかどうかを作業規模とリスクで判断することです。

この記事では、GitHub Spec Kitを「AIコーディングを仕様駆動にする候補」として見るときの判断軸を整理します。対象読者は、Codex、Claude Code、GitHub Copilot、Gemini CLIなどをすでに試していて、Issueや口頭メモからの一発実装に不安を感じている開発者、リードエンジニア、小規模チームです。

Spec Kitは、中規模以上の機能追加や既存仕様との整合性が必要な作業に向きます。逆に、数行の修正、緊急障害対応、仕様より実験速度を優先する探索では、導入コストのほうが大きくなることがあります。

この記事で扱う主な問いは次の5つです。

• Spec、Plan、Tasks、Implementは何を分けるためのものか。
• CodexやClaude Code、Copilotに入れる前に、どこを見るべきか。
• 公式パッケージ、コミュニティ拡張、社内テンプレートの信頼境界をどう分けるか。
• Implementへ進む前に、人間が止める条件をどう決めるか。
• 最小構成のパイロットで、何を結果として見るべきか。

前提知識

1. 1要求

   何を作るか、誰のためか、対象外は何かを言語化します。

2. 2設計

   既存コード、制約、リスク、検証方法を見える化します。

3. 3作業分解

   レビューできる粒度へタスクを分けます。

4. 4実装

   合意済みの計画から外れたら戻る前提で進めます。

中心にあるのは、AIの出力ではなく人間が確認できる節目です。

Spec Kitは、GitHubのgithub/spec-kitリポジトリで公開されているSpec-Driven Development向けツールキットです。公式ドキュメントは、AI支援開発で仕様を中心に置き、Spec、Plan、Tasks、Implementのような中間成果物を作りながら進める考え方を説明しています。

Spec Kitは「AIエージェントを賢くする追加モデル」ではありません。AIが読む文脈を整理し、人間がレビューできる節目を増やす仕組みに近いです。性能比較の記事というより、ワークフロー設計の記事として読むほうが実務に合います。

導入判断で見るべきなのは、Spec Kitが作る成果物が既存のIssue、PR、AGENTS.md、レビュー手順と自然につながるかです。ツール単体で評価するより、チームの「いつ仕様へ戻るか」「いつ実装へ進むか」を決める材料として見ると、採用可否を判断しやすくなります。

まず「一発依頼の失敗」を分解する

1. 1一発依頼

   何を変更するかは見えても、制約、例外、完了条件が隠れやすくなります。

2. 2未決事項

   対象範囲、既存仕様、テスト、権限、リリース条件を確認します。

3. 3SpecからTasksへ分割

   要求、設計、作業単位を順番にレビューします。

4. 4Implement

   合意済みの範囲だけ実装し、仕様変更が出たら前工程へ戻します。

一発依頼が悪いのではなく、曖昧さが大きい作業では分割したほうが手戻りを減らせます。

AI codingで曖昧さが残りやすい場所

AIコーディングでよく起きる失敗は、AIのコード生成能力だけが原因ではありません。入力側に残っている曖昧さが、実装中に増幅されることが多いです。

たとえば、次のような依頼は短くて便利ですが、実装に必要な判断がほとんど隠れています。

管理画面の検索を使いやすくして。

この依頼には、少なくとも次の未決事項があります。

• どの画面を対象にするのか。
• 検索対象は名前、メール、ID、ステータスのどれか。
• 完全一致、部分一致、前方一致、表記ゆれ対応のどこまでを求めるか。
• パフォーマンス要件はあるか。
• 既存の検索ログや失敗例はあるか。
• 変更後にどのテストで合格とするか。

推測に任せるとずれる場所

CodexやClaude Codeにそのまま渡すと、AIは不足した条件を推測して進めます。小さなUI修正ならそれでも十分な場合がありますが、業務機能では「AIが推測した仕様」と「チームが合意している仕様」がずれる危険があります。

Spec Kitが狙う分割

Spec Kitが狙うのは、この曖昧さを実装前に分割することです。Specで要求とユーザーストーリーを整理し、Planで技術方針を決め、Tasksで作業単位に落とし、Implementで合意済みの内容を実装する。これはAI向けの作法であると同時に、人間のレビュー負荷を下げる作法でもあります。

Spec、Plan、Tasks、Implementの役割

項目	内容	見方
Spec		要求、ユーザーストーリー、受け入れ条件、対象外を明確にします。
Plan		技術選定、既存コードとの接続、変更範囲、リスクを確認します。
Tasks		順番、依存関係、検証方法のある実装単位へ落とします。
Implement		合意済みのSpec、Plan、Tasksから外れたら止めます。

コマンド名として覚えるより、レビュー可能な中間成果物として見るほうが実務に乗せやすくなります。

Spec Kitを導入する前に、各フェーズを「コマンド名」ではなく「レビュー可能な中間成果物」として見たほうが判断しやすくなります。

Specは要求の曖昧さを減らす場所

Specの役割は、何を作るかを言語化することです。ここでは、実装方式を急いで決めるよりも、要求、ユーザーストーリー、受け入れ条件、対象外を明確にします。

よいSpecは、AIにとっても人間にとっても読みやすい作業契約になります。

確認項目

• ユーザーが何を達成したいか。
• 成功条件は何か。
• 対象外は何か。
• 既存仕様や既存データとどう整合するか。
• 失敗時にどう見えるべきか。

特に業務システムでは、対象外の明記が効きます。「検索改善」と言いながら、並び替え、CSV export、権限、監査ログまでAIが触り始めると、レビュー対象が膨らみます。Specに対象外を書くことで、AIの実装範囲を狭くできます。

Planは設計と制約を見える化する場所

Planは、要求をどう実装するかを決める場所です。ここで見るべきなのは、AIが選んだ技術方針そのものだけではありません。制約、既存設計との整合、移行手順、テスト方針が見えているかです。

Planでは次を確認します。

評価基準

• 既存の設計やディレクトリ構成に沿っているか。
• DB変更、外部API、認証、権限、監査ログに影響があるか。
• 代替案と採用理由があるか。
• 小さく戻せる実装順になっているか。
• テストやレビューが実装後に追いつく粒度か。

AIが出すPlanは、きれいに見えても前提が抜けることがあります。たとえば、既存のfeature flag運用、監査ログの保存義務、ユーザー権限ごとの画面差分などは、リポジトリだけを読んでも十分に復元できない場合があります。Planの段階で人間がそれを補うと、実装後の手戻りが減ります。

Tasksはレビュー可能な作業単位へ落とす場所

Tasksは、Planを実行可能な単位に分ける場所です。ここで粒度が大きすぎると、AIは一度に多くのファイルを触り、レビューが難しくなります。小さすぎると、全体の整合性が見えなくなります。

Tasksでは粒度と責務を見ます。

注意点

• 1タスクで触る責務が明確か。
• テスト追加、実装、レビュー観点が分かれているか。
• 依存関係の順番が自然か。
• 途中で止めても中間成果物が残るか。
• 人間が担当すべき判断がAI実装タスクに混ざっていないか。

たとえば「検索改善を実装する」では大きすぎます。「検索対象フィールドを定義する」「API query schemaを更新する」「UIで検索条件を表示する」「既存検索ログから評価クエリを選ぶ」「回帰テストを追加する」のように分けると、AIの作業結果を確認しやすくなります。

Implementは合意済みの計画を実装する場所

Implementは、AIにもっとも作業を任せたくなるフェーズです。ただし、ここまでのSpec、Plan、Tasksが薄いと、結局は一発依頼と同じになります。

Implementへ進む前に、次の条件を満たしているか確認します。

確認項目

• 受け入れ条件がテストまたはレビュー項目に変換されている。
• 破壊的操作、DB変更、外部通信、secret参照の扱いが決まっている。
• 失敗したときに戻す単位が決まっている。
• AIが追加してよいファイル、触ってよいファイルが明確である。
• 変更後の報告形式が決まっている。

Implementでは、AIが「実装できるか」だけでなく、人間が「レビューできるか」を見ます。AIが一気に正しそうな差分を作っても、受け入れ条件とテストが薄ければ、導入判断としては弱い結果になります。

CodexやClaude、Copilotへ入れる前に見る連携ポイント

項目	内容	見方
Codex		`.agents/skills`と`AGENTS.md`の役割を、既存運用とぶつからないように確認します。
Claude Code		共通仕様とagent固有ルールを分け、重複した指示で判断が割れないようにします。
Copilot		Spec、Plan、TasksをPRに含めるか、レビュー対象にするかを決めます。
複数agent併用		実装担当、レビュー担当、外部ツール利用、仕様変更時の更新者を決めます。

どのagentを使う場合でも、Specの置き場所と実行権限を先に固定すると運用が崩れにくくなります。

Spec Kitは複数のAIコーディングエージェントとの連携をうたっています。公式ドキュメントでは、specify init時にintegrationを選ぶと、そのエージェント向けのコマンドファイル、文脈ルール、ディレクトリ構造をセットアップすると説明されています。

Codexでは.agents/skillsとAGENTS.mdを見る

公式のintegration一覧では、Codex CLIはcodexキーで扱われ、skills-based integrationとして.agents/skillsを使い、AGENTS.mdと組み合わせる形が示されています。

これは、Codexをすでにチームで使っている場合に重要です。既存のAGENTS.mdに、禁止操作、テスト手順、レビュー基準、MCP利用ルールを書いているチームでは、Spec Kitが追加する文脈と既存ルールが衝突しないかを見ます。

特に確認したい点は次のとおりです。

条件

• 既存のAGENTS.mdとSpec Kitが追加する指示の役割が分かれているか。
• Spec Kitのskillsを、全リポジトリに入れるのか、パイロットリポジトリだけに入れるのか。
• Implement系のタスクで、Codexのsandbox、approval、network設定をどう扱うか。
• Spec Kitの成果物をレビュー対象としてPRに含めるか。

AGENTS.mdの書き方をまだ決めていない場合は、先に<a href="https://ai-dev.blog.mo-gmo.com/ai-coding-agent-prompt-injection-issues-docs-mcp-guardrails/">AIコーディングエージェントのprompt injection対策</a>や、Codex導入時の権限記事を読んで、AIに読ませる文脈と実行権限を分けるほうが安全です。

他agentでは「どこにSpecを置くか」を先に決める

Claude Code、Copilot、Gemini CLI、Cursorなどを併用しているチームでは、Spec Kitの成果物をどのエージェントが読むのかを先に決めます。複数agentで同じSpecを読むこと自体は便利ですが、それぞれの指示ファイル、コマンド、skills、rulesの置き場所が違います。

たとえば、CodexとClaude Codeを同じリポジトリで併用する場合、同じSpecを読ませても実行権限や承認の考え方は同じになりません。併用設計については、<a href="https://ai-dev.blog.mo-gmo.com/codex-claude-code-dual-agent-workflow-permissions-review-cost/">CodexとClaude Codeを同じリポジトリで併用する前に決めること</a>でも整理しています。

Spec Kitを入れる前に、次を決めておくと混乱が減ります。

• Spec、Plan、TasksをPRに含めるか。
• AIごとの指示ファイルを重複させるか、共通仕様と個別ルールに分けるか。
• 実装担当agentとレビュー担当agentを分けるか。
• どのagentが外部ツールやMCPを使ってよいか。
• Specが変わったとき、PlanとTasksを誰が更新するか。

拡張を使う前に信頼境界を分ける

1. 1公式由来

   `github/spec-kit`由来の導入元かを確認し、バージョンを固定します。

2. 2社内テンプレート

   チームのレビュー基準に合わせ、権限と更新責任を明確にします。

3. 3community extension

   source reviewを終えるまで、Read+Write権限で使わないようにします。

4. 4採用後の見直し

   権限、依存関係、更新履歴を定期的に確認します。

拡張は公式機能と同じ信頼度で扱わず、権限の強さに応じてレビューを増やします。

Spec Kitは、extensions、presets、workflowsなどで拡張できる設計です。ここは便利な一方で、権限設計の観点ではもっとも注意したい場所です。

maintained packagesはgithub/spec-kit由来に限定して見る

公式Installation Guideでは、公式に維持されているパッケージはgithub/spec-kit GitHubリポジトリ由来であり、同名のPyPI packageはこのプロジェクトと無関係である可能性があると説明されています。

導入時は、次のようにpinningを前提にします。

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.9.0
specify init my-project

一時的に試すだけなら、公式ドキュメントにあるようなuvx --from git+https://github.com/github/spec-kit.git ...の形もあります。ただし、チーム導入では「いつのバージョンで初期化したか」「誰が更新するか」「更新時に生成物が変わるか」を残したほうが安全です。

2026年6月2日にGitHub APIで確認した最新releaseはv0.9.0で、公開時刻は2026年6月1日15:36:13 UTCでした。公式ドキュメントの一部には最終更新日や例が残るため、導入時はrelease pageとInstallation Guideの両方を見るのがよいです。

community extensionsは採用前レビューが前提

公式ドキュメントは、community extensionsについて、各作者が独立して作成、保守しており、Spec Kit maintainersがextension codeをreview、audit、endorse、supportするわけではないと明記しています。

これは実務上かなり重要です。community extensionsには、Read-onlyのレポート系もあれば、Read+Writeでファイルを変更するものもあります。便利そうなextensionをいきなり実装agentに渡すと、社内ルールや既存のCI/CDを迂回する可能性があります。

採用前チェックは、最低限次の粒度で行います。

評価基準

• extensionのsource repositoryを確認する。
• Read-onlyかRead+Writeかを確認する。
• 追加されるcommandが何を変更するかを見る。
• 外部通信、GitHub issue同期、PR作成、CI操作の有無を見る。
• 社内で許可されたAI agent、MCP、token、secretに触る可能性を確認する。
• pilotではread-only extensionから始める。

これはMCP導入と似ています。外部ツールをAIに渡すときは、Tools、Resources、Promptsの便利さだけでなく、どの権限で、どの情報に触れるかを分けて見る必要があります。MCPの基本概念は<a href="https://ai-dev.blog.mo-gmo.com/mcp-tools-resources-prompts-permission-design/">MCPとは何か：Tools・Resources・Promptsと権限設計</a>で整理しています。

権限設計はSpec Kit導入と同時に決める

項目	内容	見方
DB migration		rollback方針がない場合はPlanへ戻します。
認証・課金・監査ログ		利用者、権限、記録に影響する変更は人間レビューを必須にします。
secret・外部API		token、API key、外部API writeの扱いが曖昧なら実装しません。
受け入れ条件		テストやレビューで確認できない場合はSpecへ戻します。
Tasksの粒度		差分レビューが難しい大きさなら、作業単位を分け直します。

権限設計はSpec Kitの外側にある安全策です。Implementの前に止める条件として残します。

Spec Kit自体は仕様駆動の枠組みですが、AI agentで実装する以上、権限設計と切り離せません。Spec、Plan、Tasksが整っていても、Implementの実行権限が広すぎれば、失敗時の被害は大きくなります。

Implementへ進む前に止める条件

Spec Kitのパイロットでは、Implementへ進む前に人間が止める条件を決めます。

たとえば次の条件では、AIにそのまま実装させず、Planへ戻すほうが安全です。

停止条件

• DB migrationが必要だがrollback方針がない。
• 認証、認可、課金、監査ログに影響する。
• 外部API tokenやsecretの扱いが曖昧である。
• 受け入れ条件がテストに落ちていない。
• 既存仕様との矛盾が見つかった。
• Tasksが大きすぎて、差分レビューが難しい。
• community extensionがRead+Writeで動くが、source reviewが終わっていない。

この停止条件を先に決めると、AIに「続けて」と言うべき場面と、「Planを修正して」と言うべき場面を分けられます。

AGENTS.mdに残すべきこと

Codexで使うなら、Spec Kit用の運用ルールをAGENTS.mdに短く残すと安定します。長い思想を書くより、AIが実行時に迷う部分を具体化します。

# Spec Kit workflow rules

- Start implementation only after Spec, Plan, and Tasks are reviewed.
- Treat `.specify/` artifacts as reviewable project context.
- Do not run Implement tasks that require DB migration, external API writes, or secret access without human approval.
- When requirements conflict, update Spec first, then Plan and Tasks.
- Report changed files, tests run, skipped tests, and remaining risks.

この程度でも、「仕様へ戻る」「承認が必要な作業を止める」「報告形式を固定する」という効果があります。AGENTS.mdを万能の安全装置と見なすのは危険ですが、作業契約としては有効です。

結果：Spec Kitは「大きめの曖昧さ」を扱うときに効く

複数領域にまたがる新機能

画面、API、DB、権限をまたぐ要求はSpec Kitの効果が出やすくなります。

レビュー可能な中間成果物がほしい

AIに実装を任せる前に、Spec、Plan、Tasksを確認できます。

複数agentを使い分ける

Codex、Claude Code、Copilotなどで共通仕様を読み回せます。

小さな明確修正

typo修正や単純なテスト修正では、Issueに条件を書く程度で足りる場合があります。

Spec Kitは万能な標準手順ではなく、曖昧さが大きい作業へ選んで使うほうが現実的です。

向くケース

今回、公式ドキュメントとrelease情報を確認した結果、Spec Kitは次のような場面で導入価値が出やすいと判断しました。

上振れ条件

• 新機能の要求が複数の画面、API、DB、権限にまたがる。
• AIに実装を任せたいが、レビュー可能な中間成果物がほしい。
• Codex、Claude Code、Copilotなど複数agentを使い分けたい。
• 仕様変更、Plan変更、Tasks変更の履歴を残したい。
• team onboardingで「AIにどう頼むか」を標準化したい。

一方で、Spec Kitを入れればAIコーディングが自動で安全になるわけではありません。Spec Kitは構造を作りますが、仕様の妥当性、実装権限、外部ツール、secret管理、レビュー責任はチーム側に残ります。

パイロットで見る結果

パイロットの結果として見るべきなのは、「AIが一回で実装できたか」だけではありません。むしろ次のほうが重要です。

評価基準

• Specの段階で曖昧な要求が見つかったか。
• Planの段階でリスクが見えるようになったか。
• Tasksがレビュー可能な粒度になったか。
• Implement後の差分が受け入れ条件に対応しているか。
• 仕様変更時に、どの成果物を更新すべきか分かったか。

この5点が改善するなら、Spec KitはチームのAI開発ワークフローに入れる価値があります。逆に、成果物が増えただけでレビューや判断が楽にならないなら、いったん軽量なIssue templateやAGENTS.md運用へ戻すほうがよいです。

失敗点とハマりどころ

すべてをSpec化する

小さな修正まで通すと、速度より手順の重さが目立ちます。

Planを読まずに実装する

設計制約とリスクを確認しないままImplementへ進むと、レビュー点が消えます。

community extensionを公式扱いする

導入元、source、権限を見ずに使うと信頼境界が曖昧になります。

非対話環境の前提を見落とす

approval、network、sandbox、外部ツールの扱いを先に確認します。

失敗の多くはSpec Kitそのものではなく、レビュー節目と権限の決め忘れから起きます。

すべてをSpec化しようとする

一番ありがちな失敗は、すべての作業をSpec Kitに通そうとすることです。数行のtypo修正、単純なdependency bump、明確なテスト修正までSpec、Plan、Tasksに分けると、作業速度が落ちます。

Spec Kitは、曖昧さが大きい作業に使うほうが自然です。小さな修正では、Issueに受け入れ条件とテストコマンドを書く程度で十分な場合があります。

PlanをレビューせずにImplementへ進む

Spec Kitを使っていても、Planを読まずにImplementへ進むと、一発依頼とあまり変わりません。特にAIが「もっともらしい技術選定」を書いていると、人間は読み飛ばしがちです。

Planでは、採用案よりも「何を捨てたか」「どの制約を見落としていないか」を見ます。既存の監査ログ、権限、運用手順、テスト基盤と衝突していないかを確認します。

community extensionを公式機能のように扱う

community extensionsは便利ですが、公式に監査済みの拡張として扱うべきではありません。特にRead+Write extensionや外部サービス連携を含むものは、MCP serverやGitHub Actionsと同じように、source review、権限確認、実行ログ確認が必要です。

非対話環境のデフォルトを見落とす

公式READMEでは、非対話セッションやpiped runでは、specify initがGitHub Copilotをdefault integrationとして扱う説明があります。CIや自動化で初期化する場合、意図したagentを使うなら--integration codexのように明示するほうが安全です。

specify init . --integration codex

Codex向けにskillsを使う場合は、公式READMEの例にあるようにintegration optionsも確認します。

specify init . --integration codex --integration-options="--skills"

実務で使うなら

1. 1日目

   対象Issueを選び、Specに変換します。まだ実装しません。

2. 2日目

   Planで変更範囲、リスク、検証方法を確認します。

3. 3日目

   Tasksをレビューできる粒度へ分けます。

4. 4〜5日目

   Implementを進め、受け入れ条件と差分を照合します。

5. 振り返り

   曖昧さの発見、レビューしやすさ、手戻り、運用コストを評価します。

最初の評価軸は、生成速度ではなくレビュー可能性と手戻りの減少です。

最小構成で試すなら、いきなり全社標準にせず、1件の中規模Issueで試します。対象は、少なくとも2つ以上のファイルにまたがり、受け入れ条件があり、テストで結果を確認できるものが向いています。

1週間パイロットの進め方

1日目は、対象Issueを選び、Specに変換します。この時点では実装しません。仕様の曖昧さ、対象外、受け入れ条件を人間がレビューします。

2日目は、Planを作り、技術方針、影響範囲、テスト方針を確認します。DB、認証、外部API、secretが絡む場合は、この段階で停止条件を追加します。

3日目は、Tasksをレビューします。タスクが大きすぎる場合は分割し、AIに任せるタスクと人間が判断するタスクを分けます。

4日目は、Implementを限定権限で実行します。Codexならworkspaceとapprovalを狭くし、外部通信や破壊的操作を必要とする作業は手動承認にします。

5日目は、差分、テスト、失敗ログ、Specとのズレをレビューします。成功したかどうかだけでなく、Spec Kitを使ったことで何が見えるようになったかを記録します。

評価スコアカード

パイロット後は、次のような簡単なスコアカードで導入可否を決めます。

観点	見ること	継続条件
仕様の明確化	Specで曖昧さが減ったか	実装前に未決事項が見つかった
設計レビュー	Planで制約が見えたか	人間が判断すべき点を分離できた
作業分解	Tasksがレビュー可能か	1タスクの責務が明確になった
実装品質	Implement差分が受け入れ条件に対応したか	テストと説明が対応している
安全性	権限、secret、外部通信を止められたか	承認なしの危険操作がなかった
運用負荷	成果物が増えすぎていないか	レビュー時間が許容範囲だった

この表で「仕様は明確になったが運用負荷が重い」と分かった場合は、全機能に適用せず、中規模以上の機能追加だけに絞るのがよいです。

チーム導入の小さなルール

チームで使うなら、最初は次の3つだけをルールにします。

• Spec Kitは中規模以上の機能追加、仕様変更、複数agent併用時に使う。
• Implement前に、Spec、Plan、Tasksの人間レビューを必須にする。
• community extensionsはread-onlyから始め、Read+Writeはsource review後に許可する。

このくらいなら、既存のIssue運用やPRレビューを大きく壊さずに試せます。

記事更新や検証メモを継続して追いたい場合は、<a href="https://ai-dev.blog.mo-gmo.com/newsletter/">AI Dev Lab Japanのニュースレター</a>でも、AIコーディング導入やMCP権限設計の更新を扱います。本文の判断材料を読み終えた後の補助として使ってください。

セキュリティ・コスト注意

項目	内容	見方
本体の導入元		公式リポジトリ由来か、バージョンを固定しているかを確認します。
agent integration		追加される指示ファイルやskillsが既存運用と衝突しないかを見ます。
community extensions		source、権限、更新履歴を確認してから採用します。
Implement権限		repo write、shell、network、secret、外部APIの範囲を分けます。
レビュー時間		Spec、Plan、Tasksを読む時間も導入コストとして見積もります。

セキュリティに関わる判断は勝敗ではなく、権限の強さとレビュー済みかどうかで分けます。

コストは料金以外にも出る

Spec Kit導入で増えるコストは、料金だけではありません。主なコストは、成果物を読む時間、レビューの節目を守る時間、拡張機能を評価する時間です。

権限と情報の境界を分ける

セキュリティ面では、次を必ず分けます。

確認項目

• Spec Kit本体の導入元。
• agent integrationが作る指示ファイルやskills。
• community extensionsのsourceと権限。
• Implement時のAI agent実行権限。
• GitHub token、API key、secretへのアクセス。
• MCP serverや外部ツールを使う範囲。

特に、Read+Write extension、GitHub issue同期、PR作成、CI操作、外部API連携を含む拡張は、AIコーディングエージェント本体と同じくらい慎重に扱います。導入初週は、secretを含むリポジトリ、本番DBに接続する環境、顧客データを扱う管理画面では試さないほうが安全です。

また、Spec Kitで生成されるMarkdown成果物には、業務要件、未公開仕様、社内システム名、セキュリティ上の制約が入りやすくなります。AI agentに外部送信される文脈、GitHub上での公開範囲、社外委託先との共有範囲を確認してください。

法人でAIコーディング導入、AGENTS.md、MCP、Spec Kitのようなワークフローをまとめて整える場合は、記事末尾の<a href="https://ai-dev.blog.mo-gmo.com/contact/">お問い合わせ</a>から相談できます。まずは1リポジトリ、1機能、1週間のパイロット単位で設計するのが現実的です。

FAQ

Codex専用ですか？

いいえ。複数のAI coding agent integrationが説明されています。

community extensionsは使えますか？

使う前にsource、権限、更新履歴を確認し、Read+Writeは慎重に扱います。

いつSpecへ戻りますか？

要求変更、受け入れ条件の不足、既存仕様との矛盾が出たときです。

Issue templateだけで十分ですか？

小さく明確な修正なら、Issueの条件とテストだけで足りる場合があります。

v0.9.0を全社展開できますか？

まず小さなパイロットで、レビュー節目と権限設計が回るかを確認します。

FAQは導入を急がせるためではなく、作業規模に合う使い方を選ぶための確認です。

Spec KitはCodex専用ですか？

いいえ。公式ドキュメントでは、Copilot、Gemini、Codex、Windsurf、Claudeなど複数のAI coding agent integrationが説明されています。Codex専用ではありません。ただし、agentごとに指示ファイル、skills、commandsの置き場所が違うため、チームで併用する場合はSpecの置き場所と実行権限を決める必要があります。

community extensionsは使ってよいですか？

使えますが、公式に監査済みと見なすべきではありません。公式ドキュメントは、community extensionsについて、maintainersがcodeをreview、audit、endorse、supportするわけではないと説明しています。最初はRead-only extensionから試し、Read+Write extensionはsource reviewと権限確認をしてから使うのが安全です。

いつSpecへ戻るべきですか？

Implement中に、仕様の矛盾、受け入れ条件の不足、対象外の変更、DBや認証への影響が見つかったら、Specへ戻ります。Planだけを直すのではなく、要求自体が変わっていないかを確認します。

既存Issue templateだけで十分な場合はありますか？

あります。小さなbugfixや明確な修正では、Issue templateに受け入れ条件、禁止操作、テストコマンドを書くほうが軽いです。Spec Kitは、要求、設計、作業分解を分ける価値がある作業に絞るほうが使いやすいです。

latest releaseを今すぐ全社展開してよいですか？

全社展開より、1リポジトリでpinningして試すのがよいです。2026年6月9日にGitHub APIと公式Docsを確認した時点でlatest releaseはv0.9.5です。短期間でworkflowやextensionまわりの更新が続いているため、導入時はrelease note、Installation Guide、既存のagent設定を一緒に確認してください。

---

次に読むなら

参照した主な情報源

• GitHub Spec Kit Documentation: https://github.github.io/spec-kit/
• Installation Guide: https://github.github.io/spec-kit/installation.html
• Core Commands: https://github.github.io/spec-kit/reference/core.html
• Supported AI Coding Agent Integrations: https://github.github.io/spec-kit/reference/integrations.html
• Extensions Reference: https://github.github.io/spec-kit/reference/extensions.html
• Community Extensions: https://github.github.io/spec-kit/community/extensions.html
• GitHub repository: https://github.com/github/spec-kit
• Release v0.9.5: https://github.com/github/spec-kit/releases/tag/v0.9.5

更新履歴

1. 2026年6月2日

   初版作成。公式ドキュメント、公式リポジトリ、最新リリース情報を確認しました。

Spec Kitのリリースや導入手順は変わる可能性があるため、公開前に公式情報を確認します。

• 2026年6月2日: 初版作成。GitHub公式ドキュメント、公式リポジトリ、GitHub latest release API、git ls-remoteで確認。手元の確認環境はmacOS上のGit 2.41.0、Python 3.14.5、uv 0.11.12。Spec Kit本体のインストール実行は行わず、導入判断に必要な一次情報の確認に留めた。