---
title: 産総研AITeC-Generative AI Study Group-第73回-20260526-SDDセッション-公開版
tags:  #ai-driven dev #spec kit #specify #plan #task #openai #anthropic #sier #enterprise #spec-driven development #ai 駆動開発 #github copilot #cursor #claude #claude code #codex #codex app #claude desktop #ai-dlc #agent skills #mcp #skills #plugin  
author: [Shotaro Suzuki](https://image.docswell.com/user/shosuz)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/2EVVNXPYEQ.jpg?width=480
description: AI 駆動開発の新しい構造 - Spec-Driven Development が示すこれからの設計思想 【産総研AITeC「Generative AI Study Group第73回」】 https://aitconsortium.doorkeeper.jp/events/197175
published: May 28, 26
canonical: https://image.docswell.com/s/shosuz/KVJ48P-2026-05-28-185437
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/2EVVNXPYEQ.jpg)

AI 駆動開発の新しい構造
Spec-Driven Development を⼀つの機能で最後まで追う
産総研 AITeC Generative AI Study Group 第73回


# Page. 2

![Page Image](https://bcdn.docswell.com/page/57GLKVPWEL.jpg)

鈴⽊ 章太郎
X (Twitter) : @shosuz
FPT ジャパン FPT データ& AI インテグレーション
エグゼクティブエバンジェリスト
独⽴⾏政法⼈ 国⽴印刷局
デジタル統括アドバイザー兼最⾼情報セキュリティアドバイザー
合同会社デベロッパーアドボケイト
代表社員チーフアドボケイト
Developer Advocate
略歴︓
AI 駆動開発勉強会主催。Microsoft エバンジェリスト時代(2003年)から、Dell、
Accenture、Elastic、VMware を経て現職まで、20年に渡り⼀貫して開発者向けに
最新技術を啓発。NVIDIA GPU クラウド技術訴求、 AI 駆動開発コンサルティングを
実施。AI 駆動開発コンソーシアム副座⻑。
政府の仕事は、内閣官房 IT 総合戦略室 政府 CIO 補佐官（併任︓法務省 CIO
補佐官、第4次 安倍改造内閣、 2019年4⽉〜）、 デジタル庁 PM（併任︓⾦融庁
デジタル統括アドバイザー、菅内閣、2021年9⽉〜）を経て2024年10⽉より現職を兼
務。
https://shotaro-evangelist.carrd.co /
https://www.docswell.com /user/shosuz
AI 駆動開発トレーニング、AI 駆動開発コンサルティング、技術顧問、技術マーケティング
⽀援、クラウドトレーニング、を提供する合同会社デベロッパーアドボケイトを2022年設⽴。
MCT (Microsoft 認定トレーナー) としてエディフィストラーニング社においてGH-300 コース
担当の他、多くの AI 開発系トレーニング講師を担当。
Google Cloud Partner All Certifications Engineer 2025 。


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4EQYN62QJP.jpg)

本⽇のアジェンダ ̶ 概念ではなく「動く流れ」で⾒る
現状の限界 → 仕様駆動の全体像 → 上流の⽣成 → 3 層統制 → Skills → 業界収束 → 現場適⽤
Ⅰ
AI 駆動開発の現状と限界
Ⅱ
仕様駆動の全体像 ̶ 題材を 1 つ通す
Ⅲ
上流︓仕様をどう⽣むか（逆質問 / ⽣成）
Ⅳ
統制の仕組み ̶ 3 層アーキテクチャ
Ⅴ
Why Skills ̶ 専⾨知識を装着する
Ⅵ
業界収束︓AWS / Microsoft / Anthropic
Ⅶ
現場適⽤とまとめ ̶ 組織への問い
汎⽤ EC の「商品検索機能」を題材に、上流から CI まで⼀連の流れを具体例でたどる


# Page. 4

![Page Image](https://bcdn.docswell.com/page/KJ4WG4LY71.jpg)

AI 駆動開発の現状 ̶ プロンプトだけでは届かない領域
「いい感じに作って」が機能するのは⼩さい範囲だけ
✅ プロンプト駆動が効く領域
⚠ プロンプトだけでは破綻する領域
・⼩さい・閉じたタスク（関数⽣成・1 ファイル変更）
・⾔語・FW の⾃動補完
・短いリファクタリング
・テストコードの定型⽣成
・「探索的試⾏」のループ
・複数⼊⼒・複数制約・複数エッジケース
・API / スキーマ駆動の整合
・既存コードベースへの段階的変更
・セキュリティ・コンプライアンス制約
・組織独⾃規約・暗黙知の遵守
・再現性の要求（同じ仕様 → 同じ出⼒）
問題は AI の能⼒ではなく「何を作るか」の記述構造


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LE1YD4LN7G.jpg)

Spec-Driven Development とは
「コードを書く前に仕様を構造化する」̶ 仕様が実装を駆動する
① Spec
② Plan
③ Tasks
何を作るか
どう作るか
どこから着⼿
ユーザ視点の要件 /
受け⼊れ基準 / ビジネス要件
技術選定 / アーキテクチャ / 制約
実装可能タスクへの分解
Spec / Plan / Tasks の 3 段で「仕様 → 実装」が再現可能になる


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GEWGYXQMJ2.jpg)

本⽇の題材 ̶ 汎⽤ EC の「商品検索機能」を⼀本で追う
概念の羅列ではなく、1 つの機能が上流から CI まで流れる様⼦を最後まで具体例でたどる
🧵 ec-product-search
題材︓ec-product-search（商品検索機能） ̶ 顧客固有情報を含まない中⽴例
• 「キーワード・カテゴリ・価格帯で商品を検索し、⼀覧 → 詳細に遷移する」ありふれた機能。
• この種の機能はサンプルが世の中に豊富にあり、参考はいくらでも⾒つかる。
意図
AI 逆質問
requirements Constitution.
.txt
md
/speckit.
specify
Hooks
SKILL.md
CI ゲート
上流（何を作るか）─────────→ 統制（どう守るか）─────────→ 下流（壊れないことの保証）
💡 この後のスライドは、上のパイプラインの各ブロックを 1 枚ずつ具体例で取り上げる
抽象的な「Constitution.md とは」で終わらせず、ec-product-search の Constitution 抜粋・逆質問・
requirements.txt・hooks.json・SKILL.md・CI 設定を、具体的な記述例として載せる。
「枠だけで中⾝は別途」ではなく、中⾝まで具体例で⽰す


# Page. 7

![Page Image](https://bcdn.docswell.com/page/47ZLX6WMJ3.jpg)

【公開版では割愛】
このページ:「Constitution.md の記述例」
実装の詳細（具体的な設定・コード例）は公開版では削除しています。


# Page. 8

![Page Image](https://bcdn.docswell.com/page/YJ6W42G5JV.jpg)

上流② INCEPTION ルールの台本がどう動くか
「AI が逆質問する」のは魔法ではなく、Constitution.md に書いた台本の実⾏
🧵 ec-product-search
1
2
3
4
5
要求を受ける
台本を読む
逆質問する
下書く
確定する
「商品検索を追加」
Constitution の
INCEPTION 節を
参照
5 項目＋変種
テンプレを順に質
問
回答から
requirements
ドラフト⽣成
⼈間が確認 →
spec へ
AI の「賢さ」に依存せず、組織が決めた観点を台本として毎回必ず通す


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GJ5MQ2VGJ4.jpg)

上流③ AI 逆質問でドラフトを⽣成する
「requirements を誰が書くか」̶ ⼈間が⼀から書く → AI が抜けを逆質問して下書く
① 開発者の⼊⼒（数分）
「商品検索機能を追加したい。
キーワードとカテゴリで絞れて、
⼀覧から詳細に⾶べれば良い」
🧵 ec-product-search
② AI が逆質問（Constitution の台本に沿って）
③ ⼈間が確定
・検索条件は︖（キーワード / カテゴリ / 価格帯
/ 在庫有無）
・ページング⽅式は︖（offset / cursor）/ 1
ページ件数
・並び順は︖（関連度 / 価格 / 新着）デフォルト
は︖
AI の下書きを Tech
Lead / PO が確認・補正
し、requirements.txt と
して確定
→ PR。
・認可︓未ログインでも検索可能か︖
・性能要件︓応答 95%ile は何 ms 以内か︖
・抜けを AI が拾う
・判断は⼈間が握る
・毎回同じ観点で漏れない
・既存の商品テーブル schema・索引は︖
意図⼀⾔ → AI が抜けを質問 → ⼈間が確定。要件定義の⼯数を圧縮しつつ観点漏れを防ぐ


# Page. 10

![Page Image](https://bcdn.docswell.com/page/LE3WVKDPE5.jpg)

【公開版では割愛】
このページ:「requirements.txt（TOML マニフェスト）」
実装の詳細（具体的な設定・コード例）は公開版では削除しています。


# Page. 11

![Page Image](https://bcdn.docswell.com/page/8EDK83P37G.jpg)

上流⑤ /speckit.specify で 4 ファイルを⼀括⽣成
Spec Kit（GitHub OSS）の 1 コマンド。Input → Run → Output の 3 段がはっきり分かれている
🧵 ec-product-search
$ /speckit.specify ec-product-search
✓ specs/ec-product-search/spec.md
← 何を（要件・受⼊基準）
✓ specs/ec-product-search/plan.md
← どう（API 設計・schema）
✓ specs/ec-product-search/tasks.md
← 着⼿単位に分解
✓ specs/ec-product-search/requirements.txt ← ⽣成マニフェスト (TOML)
spec.md
plan.md
tasks.md
requirements.txt
何を作るか
どう作るか
着⼿単位
⽣成マニフェスト
受⼊基準 /
ユーザストーリー /
エッジケース
REST 設計 /
products 索引 /
cursor ページング
API・Repo・テストに
タスク分解
再⽣成・制約・変種を
TOML で固定
1 コマンドで仕様⼀式が版管理対象になる ̶ 「仕様 = コードと同じ管理物」へ


# Page. 12

![Page Image](https://bcdn.docswell.com/page/V7PK84NPJ8.jpg)

統制① Constitution.md を⽀える 3 層 ̶ 常時 / 専⾨ / 強制
3 ツール共通の標準パターン ̶ 同じ API で「思想 → 実装」が動く
①常時 (Always-On)
②専⾨ (On-Demand)
③強制 (Enforcement)
全 turn で auto-load される
基盤層
Progressive Disclosure
̶ メタデータのみ常時、本体は
invoke 時
Hooks API ̶ AI を信⽤せず
機械的に enforce
主な内容
・命名規則 / ファイル構造
・⾔語・FW 選定
・INCEPTION ルール
・組織共通の規範
主な内容
・SDD ステップを skill 化
・組織のコーディング規約
・専⾨領域 (security / a11y)
・業界固有のベストプラクティス
主な内容
・編集前 hook︓危険操作 block
・編集後 hook︓
linter / validator
・intent 検出 → context 注⼊
・CI の前段で違反を絶つ
💡 context を軽量に保つ
💡 規約が増えても context
肥⼤化しない
💡 AI の柔軟性 × 機械的統制
の両⽴
「常時で⼟台 / 専⾨で拡張 / 強制で統制」̶ 3 層分業で軽量・拡張・統制を両⽴


# Page. 13

![Page Image](https://bcdn.docswell.com/page/2JVVNXKVJQ.jpg)

統制② 3 ツール共通の標準パターン ̶ Copilot / Codex / Claude Code
異なるベンダーが同じ API 名（PreToolUse / PostToolUse / SKILL.md）に収束
常時 (Auto-Load)
専⾨ (Skills)
強制 (Hooks)
GitHub Copilot
copilot-instructions.md
.github/prompts/*.prompt.md
.github/hooks/hooks.json
Codex
AGENTS.md
~/.codex/skills/
(SKILL.md)
~/.codex/hooks.json
Claude Code
CLAUDE.md
.claude/skills/
(SKILL.md)
.claude/settings.json
💡 Hooks のイベント名は 3 ツールで共通: PreToolUse / PostToolUse / userPromptSubmitted / ...
ベンダー固有の⽅⾔ではなく、業界収束した「共通標準」として扱える


# Page. 14

![Page Image](https://bcdn.docswell.com/page/5EGLKVQ1JL.jpg)

【公開版では割愛】
このページ:「Hooks（hooks.json）の設定例」
実装の詳細（具体的な設定・コード例）は公開版では削除しています。


# Page. 15

![Page Image](https://bcdn.docswell.com/page/4JQYN6KN7P.jpg)

Why Skills ̶ IQ300 の Mahesh より、Barry の専⾨知識
「確定申告は経験豊富な税理⼠に頼みたい」̶ AI に IQ ではなく組織の専⾨性を装着する
Mahesh ─ IQ300 の数学者
Barry ─ 経験豊富な専⾨家
・天才的な知能
・毎回ゼロから解釈
・経験から得たドメイン知識
・⼀貫した実⾏
・専⾨知識を持たない
・あなたの組織の知識を吸収しない
vs
・時間が経っても学習しない
・組織の⼿順を熟知
・新しい分野でも前提を持つ
・即戦⼒
💡 現在の AI エージェントは Mahesh に近い
→ Skills（SKILL.md 形式）で「Barry の専⾨知識」を装着する。
組織の⼿順・規約・暗黙知を蓄積し、必要時のみ AI が読み込む。
出典︓Anthropic Skills チーム講演（Barry / Mahesh、2026 年 5 ⽉）


# Page. 16

![Page Image](https://bcdn.docswell.com/page/K74WG4P3E1.jpg)

Skills の 3 種類 ̶ Enterprise Skills が組織の競争⼒になる
モデルは誰でも同じ。差がつくのは「組織の知識をどれだけ AI に装着できたか」
Foundational
Third-Party
Enterprise ★
作る⼈
作る⼈
作る⼈
中⾝
中⾝
中⾝
具体例
具体例
ベンダー公式
外部ベンダー / OSS
AI ベンダー（Anthropic 等）公式
汎⽤・分野⾮依存の能⼒
特定ツール・サービスの操作⼿順
・Office ⽂書 / PDF の操作
・科学計算・データ可視化
御社の関与
外部の専⾨ベンダー・OSS
既製をそのまま使う（⾃作しない）
・Notion / Figma 連携
・各種 SaaS の API 操作
御社の関与
必要なものを選んで追加する
⾃社独⾃ ̶ 本命
御社⾃⾝（DRI・Skill 作成者）
組織固有の規約・⼿順・暗黙知
（外には存在しない知識）
具体例
・命名 / レビュー規約
・社内ライブラリの作法
・過去障害からの禁則
・業務ドメインのルール
御社の関与
⾃分で書いて継続的に育てる
★ なぜ Enterprise が本命か ̶ モデルでは差がつかない、組織知識で差がつく
AI モデルは誰もが同じものを使える。優位はモデルの賢さではなく、組織独⾃の知識を SKILL.md として AI にどれだけ装着できたかで決まる。書く⼈・レビュー
する⼈・保守する⼈を決め、3〜6 ヶ⽉ごとに⾒直して育てる。
Anthropic は 5 週間で⾦融・ライフサイエンス向け Skill パックを展開 ̶ 業界垂直化の速さ


# Page. 17

![Page Image](https://bcdn.docswell.com/page/LJ1YD49ZEG.jpg)

【公開版では割愛】
このページ:「SKILL.md の記述例」
実装の詳細（具体的な設定・コード例）は公開版では削除しています。


# Page. 18

![Page Image](https://bcdn.docswell.com/page/GJWGYXQ672.jpg)

Skills が開く「アプリケーション層」 ̶ コンピュータ史と同型の構造
Anthropic 由来のアナロジー︓CPU / OS / App の構造が AI に再現される
AI モデル (Claude / GPT / Gemini)
巨⼤な投資、単体では何もできない
エージェントランタイム
リソース管理、Skills の動的 load
Skills (SKILL.md 形式)
誰でも作れる、ドメイン知識のパッケージ ★
= プロセッサー (CPU)
= オペレーティング システム
= アプリケーション
💡 CPU / OS を作るのは数社、App は数百万⼈が作る ̶ Skills も同じ広がり⽅をする
→ AI 時代の「アプリケーション開発者」= ドメインエキスパート + プロンプト設計者
AI のアプリケーション層が、初めて⾮ベンダーに開放された


# Page. 19

![Page Image](https://bcdn.docswell.com/page/4EZLX6WR73.jpg)

業界収束 ̶ AWS・Microsoft・Anthropic が異なる経路で同じ結論に
「思想 + 仕様 + 共通 API」という枠組みは、ベンダー⽅⾔ではない
AWS
Microsoft
Anthropic
AI-DLC（aidlc-workflows）
Spec Kit を公式推奨
Agent Skills を提唱
・6 ツール対応の公式リポジトリ
・「Moving Beyond Prompts」
・SKILL.md = 共通仕様
・Constitution + Plan + Tasks 構造
・Microsoft Learn にトレーニング
・Progressive Disclosure
・1 ⾏設定で各ツール統合
・Copilot CLI で hooks 標準装備
・Enterprise Skills で組織知識配布
3 社が独⾃経路で同じパターンに収束 ̶ これは流⾏ではなく業界構造の変化


# Page. 20

![Page Image](https://bcdn.docswell.com/page/Y76W42G17V.jpg)

Anthropic の 5 週間 ̶ Skills + MCP で業界垂直展開
汎⽤エージェントに「業界知識パック」を渡せば、特化エージェントが即完成する
📅 Skills 発表からの 5 週間
Skills + 業界特化 MCP セット の配布で、Anthropic ⾃⾝が 2 つの業界向けサービスをローンチ
⾦融サービス向け
ライフサイエンス向け
業界データ MCP + ⾦融専⾨ Skills
EHR / バイオインフォマティクス Skills
⽰唆
・汎⽤ AI モデルは「OS のような共通基盤」
・業界知識パック（MCP + Skills）が「業界対応アプリ」
・業界 SIer / コンサルの差別化軸が「Skill ポートフォリオの厚み」になる可能性
「業界対応はモデルではなく Skill で決まる」時代が始まっている


# Page. 21

![Page Image](https://bcdn.docswell.com/page/G75MQ2VL74.jpg)

現場適⽤① 既存 IDE / AI ツールと Spec Kit の関係
「Spec Kit は新しいツール」ではなく、既存ツールに思想を導⼊する仕組み
🛠 既存ツール（変えない）
✨ Spec Kit が⾜すもの（思想層）
・GitHub Copilot / Codex / Claude Code の
継続利⽤
・既存リポジトリ・CI・PR フローはそのまま
・IDE 操作も従来通り
・学習コストはほぼゼロ
・Constitution.md（SSOT）
・/specify /plan /tasks の 3 段階
・AI 逆質問による要件ドラフト⽣成
・Skills + Hooks の 3 層構造
・Brownfield 適⽤パターン
ツール乗換ではなく「思想の上乗せ」 ̶ 既存資産を活かしたまま導⼊できる


# Page. 22

![Page Image](https://bcdn.docswell.com/page/9J29P433ER.jpg)

現場適⽤② Brownfield（既存システム）への適⽤
既存コードベースに後付けで SDD を導⼊する段階的アプローチ
Phase 1
Template 導⼊
Phase 2
SoT 定義 & Spec 化
Phase 3
差分 Spec 開発
Goal
CI / Review 完全統合
Spec Kit 初期化 +
Constitution.md 整備
重要機能から順次 Spec 化
改修は Spec ファースト
ガードレール運⽤、コード変更
には Spec 変更必須
💡 鉄則︓コード変更 PR には対応する Spec 変更が必須
→ CI で機械的に強制すれば「Spec とコードの乖離」を構造的に防げる
→ 全機能を⼀度に Spec 化する必要なし ̶ 改修が⼊る箇所から段階的に切替
Greenfield だけでなく Brownfield にも適⽤可能 ̶ 既存資産を捨てなくて良い


# Page. 23

![Page Image](https://bcdn.docswell.com/page/DEY45M18JM.jpg)

【公開版では割愛】
このページ:「品質ガードレール / CI の実装⼿段」
実装の詳細（具体的な設定・コード例）は公開版では削除しています。


# Page. 24

![Page Image](https://bcdn.docswell.com/page/VJNYNW2978.jpg)

現場適⽤④ 段階的な導⼊ ̶ 即⽇ / 中期 / ⻑期
重い変⾰ではなく、軽量から始めて検証しながら段階的に拡張
即⽇
1〜3 ヶ⽉
3〜6 ヶ⽉
30 ⾏の追加で開始
Spec ファースト切替
CI / ガードレール統合
・Constitution.md に 30 ⾏追記
・各ツールの設定に 1 ⾏参照
・現場の流儀はほぼ無変更
・改修が⼊る箇所から段階適⽤
・Skills を 1 つずつ整備
・プロンプトパターン蓄積
・constraints の CI 強制
・Hooks による編集時チェック
・Skills 全社展開
💡 既存投資を活かす ̶ Copilot / Codex / 既存リポジトリはそのまま継続
💡 ベンダーロックインなし ̶ 3 ツール共通標準なので、将来他ツールが台頭しても対応可
💡 可逆的 ̶ 軽量から始めて、効果を確認してから次に進む
「重い変⾰プロジェクト」ではなく「⽇々の改善の延⻑」として導⼊可能


# Page. 25

![Page Image](https://bcdn.docswell.com/page/YE9PRX13J3.jpg)

SDD の今後 ̶ 4 つの発展軸
軽量導⼊から始めて、必要に応じて段階的に拡張できる
Adaptive Depth
Extensions
規模に応じた深度調整
⾃社規約の上乗せ
Minimal / Standard / Comprehensive で過剰品質
を回避
Constitution.md に追記し、全社ガバナンスを AI に伝播
Feature サブディレクトリ
導⼊の選択肢
複数チーム並⾏開発
軽量 / フル を併存
workflow/ を機能単位に分割、並⾏開発に対応
Constitution.md ベース / AI-DLC フル の段階拡張
「重い AI-DLC vs 軽い Constitution.md」ではなく「段階的に進化」する選択肢


# Page. 26

![Page Image](https://bcdn.docswell.com/page/GE8DW24LED.jpg)

組織が考えるべき 3 つの問い
SDD を導⼊する際、組織が向き合う本質的な意思決定
Q1
Q2
Q3
暗黙知をどう資産化するか︖
属⼈化したノウハウを SKILL.md として体系化できる仕組みが組織にあるか。Skill を書く⼈・レビューする⼈・保守
する⼈を誰にするか。
ツール多様性をどう統制するか︖
Copilot / Codex / Claude / Gemini ... が並⾛する現実で、Constitution.md のような SSOT を運⽤で
きる組織体制があるか。
「仕様 = 契約」の⽂化に切替えられるか︖
コード変更には Spec 変更が必須、というガードレールを⽂化として定着できるか。レビュアー・PM の役割が再定義
される。
技術ではなく組織 ̶ SDD 導⼊は組織変⾰プロジェクトでもある


# Page. 27

![Page Image](https://bcdn.docswell.com/page/LELMN26Q7R.jpg)

まとめ ̶ 3 つのキーメッセージ
本⽇のセッションを 3 ⾏に圧縮するなら
1
2
3
AI 駆動開発は「プロンプト → 仕様」へ
プロンプト依存の限界が明確になり、Spec-Driven Development が業界収束しつつある。
これは流⾏ではなく構造変化。
「思想層」を SSOT として管理する
Constitution.md を中⼼に、3 層（常時 / 専⾨ / 強制）で AI ツールを統制する設計が成⽴した。
ベンダー⽅⾔ではなく業界共通標準。
Skills が組織の競争⼒になる
AI モデルではなく、組織独⾃の知識を SKILL.md として配布できるかが差別化軸。
「Barry の専⾨性」を AI に装着する戦略。
「ツール選定」ではなく「思想と仕組み」を設計する時代に⼊った


# Page. 28

![Page Image](https://bcdn.docswell.com/page/4JMYX8GKJW.jpg)

参考資料 / 出典 ̶ 本セッションで参照した主な資料
本セッションで参照した公式ドキュメント・記事の⼀覧
公式ツールキット
GitHub Spec Kit
AWS 公式
awslabs/aidlc-workflows (AI-Driven Lifecycle)
Microsoft 公式
Moving Beyond Prompts: Spec-Driven Development (2026/5)
Anthropic 講演
Skills チーム講演 (Barry / Mahesh, 2026/5)
実装ドキュメント
Claude Code Hooks / Codex CLI Hooks リファレンス
github.com/github/spec-kit
github.com/awslabs/aidlc-workflows
techcommunity.microsoft.com / Microsoft Learn
Anthropic 公式 / 国内まとめ記事
code.claude.com / developers.openai.com
いずれも公式の⼀次資料 ̶ 詳細は各リンクを参照