AI仕様駆動_ClaudeCode_API_goal自立型開発_法人研修

Udemy講座｜法人研修レベル AI仕様駆動開発 × Claude Code × Claude API /goal で「任せて、検証で締める」自立型開発 仕様（SPEC）→ 計画 → 実装 → 検証 → 自律ループ。公式ドキュメント（日本語・英語）に基づく90分カ リキュラム うさうさ研修工房 YUKIKO 情報確認日：2026年10月17日（ツールの仕様は更新されます。受講前に公式で再確認を）

学習ゴールと進め方（ 90分のスロープ） 概要 到達目標（受講後にできること） 1. 仕様（SPEC.md）を自己完結の形で書ける 2. 検証条件を設計し /goal に渡せる 3. Claude APIとAgent SDKの使い分けを説明できる 4. 無人実行のガバナンス（権限・レビュー）を設計できる 頂上 20分 上り坂 対象・前提 ・新人〜中堅エンジニア、PM/PMO、情シス ・ターミナル操作とGitの基本 ・Claude Code v2.1.139 以降（/goal の要件） ・法人利用：組織の利用規約・セキュリティ方針に従う 35分 助走 下山 25分 10分 小テスト（助走後） → 最終テスト（頂上後） 出典: うさうさ研修工房 坂道型学習設計（Vygotsky 1978 / Bjork & Bjork 2011 / Kapur 2008 を設計の拠り所とする） 2

Why｜なぜ「仕様駆動」と「検証」が要るのか 楽しい｜助走 課題① 止まる基準が曖昧 課題② 違う問題を解く 課題③ コンテキストは有限 公式：「Claude は、作業が完了した ように見えるときに停止します」 公式：直接コーディングに入ると「間 違った問題を解決するコード」になり 得る。 公式：「ほとんどのベストプラクティス は1つの制約に基づく」＝コンテキスト ウィンドウはすぐ満杯になり性能が落 ちる。 実行できるチェックがないと、人間が 検証ループになる。 探索と計画を実装から分離する。 仕様は外部ファイルに。 結論：仕様で「何を作るか」を固定し、検証で「終わり」を定義し、 /goal で「終わるまで回す」。 出典: Best practices for Claude Code (EN) code.claude.com/docs/en/best-practices ／ Claude Code のベストプラクティス（JA）code.claude.com/docs/ja/best-practices 3

What｜全体像：仕様 →計画→実装→検証→自律 楽しい｜助走 1 仕様 2 計画 3 実装 4 検証 5 自律 SPEC.md （インタビューで作 る） Plan Mode （変更前に調査） Claude Code （テストも書く） テスト／ビルド lint／レビュー /goal 条件成立まで反復 出口A：Claude Code CLI／デスクトップ 出口B：Claude API／Agent SDK 対話的な開発・1回限りのタスク。 /goal・Plan Mode・サブエージェント・hooks・Skills を日常 開発で使う。 自社アプリや CI/CD に組み込む。 Client SDK＝自分でツールループ、Agent SDK＝Claude Code と同じエージェントループをライブラリで利用。 出典: Best practices (EN/JA)、/goal (EN) code.claude.com/docs/en/goal・(JA) code.claude.com/docs/ja/goal、Agent SDK overview (EN/JA) 4

仕様駆動の 2流儀：Anthropic推奨とSpec Kit 楽しい｜助走 観点 Anthropic公式ベストプラクティス GitHub Spec Kit（第三者OSS） 仕様の作り方 Claudeに AskUserQuestion でインタビューさせ、SPEC.md に書 かせる Spec → Plan → Tasks → Implement の段階ごとに Markdown 成果物を作る 実装の始め方 新しいセッションで SPEC.md を読ませて実行（クリーンなコンテキ 各段階の成果物をAIコーディングエージェントに構造化コンテキ スト） ストとして渡す 良い仕様の条件 自己完結／関係ファイル・IFを明記／スコープ外を明記／E2E検 証で終える 「何を作るか」を先に定義し、段階的に具体化する 位置づけ Claude Code標準の作法（追加導入不要） ツールキット導入（specify init 等）が必要。対応エージェントは多 数 本講座は、追加ツール不要の「公式の作法」を軸に進めます。 Spec Kit は比較・発展として紹介。 出典: Best practices「Let Claude interview you」(EN) code.claude.com/docs/en/best-practices ／ GitHub Spec Kit github.github.com/spec-kit/（※サードパーティ製。Anthropic公 式ではない） 5

助走①｜基本の型：探索 → 計画 → 実装 → コミット 1 探索 2 計画 3 実装 楽しい｜助走 4 コミット Plan Mode で読むだけ。 変更しない。 変更ファイル・ フローを計画に。 計画に沿って実装。 テストを書いて実行。 説明的メッセージで コミット／PR。 Shift+Tab ／ claude --permission-mode plan Ctrl+G でエディタ編集 テスト失敗は修正まで /clear で次タスクへ 公式の目安：スコープが明確で修正が小さい（タイプミス・ログ追加・変数名変更）ときは計画を省略。「差分を 1文で説明でき るなら計画はスキップ」。計画が効くのは、方針が不確か／複数ファイルに及ぶ／不慣れなコードのとき。 出典: Best practices「Explore first, then plan, then code」(EN) code.claude.com/docs/en/best-practices ／ Permission modes code.claude.com/docs/en/permission-modes 6

助走②｜「常駐させる情報」の置き場所を使い分ける 楽しい｜助走 置き場所 役割 向いている内容 注意点（公式） CLAUDE.md 毎セッション読む常駐指示 Claudeが推測できないBashコマンド／コードス タイル差分／テスト手順 長すぎるとルールが埋もれ無視される。「消 すとミスが増えるか」で削る Skills（SKILL.md） オンデマンド知識・ワークフロー ドメイン知識、繰り返す手順（/fix-issue 等） ときどきしか要らない内容はこちら hooks 決定論的に必ず実行 編集後に lint、特定フォルダへの書込ブロック CLAUDE.mdは助言、hooksは保証 サブエージェント 別コンテキストで委譲 調査・レビューなど大量に読む作業 メイン会話を汚さない SPEC.md／PLAN.md 作業単位の仕様・計画 今回の機能の要件・受け入れ基準 新セッションで読ませて実行 出典: Best practices（CLAUDE.md／hooks／skills／subagents の各節）(EN) code.claude.com/docs/en/best-practices ／ (JA) code.claude.com/docs/ja/best-practices 7

助走③｜良い SPEC.md の書き方（公式の 4条件） 楽しい｜助走 自己完結 ファイルと IF スコープ外 E2E検証 新セッションで読んでも 文脈なしに理解できる 関係するファイル・ インターフェースを名指し 「やらないこと」を 明記する 機能が動くと証明する 最終確認ステップで終える インタビュー用プロンプト（公式例の要旨） I want to build [brief description]. Interview me in detail using the AskUserQuestion tool. Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered. Keep interviewing until we've covered everything, then write a complete spec to SPEC.md. 仕様ができたら新しいセッションで実行。クリーンなコンテキストで実装に集中でき、参照できる書面の仕様が残ります。 出典: Best practices「Let Claude interview you」(EN) code.claude.com/docs/en/best-practices ／ (JA) 同 /ja/best-practices（プロンプト例は公式記載を要約） 8

小テスト｜助走ゾーンの確認（ 4問） 確認テスト Q1 大きな機能の仕様づくりで、公式が勧める方法は？ A 自分で全部書く B Claudeにインタビューさせ SPEC.md に書かせる C 仕様なしで実装 Q2 「探索→計画」を、ファイルを変更せずに行うモードは？ A auto B Plan Mode C bypassPermissions Q3 CLAUDE.md に入れない方がよいものは？ A 推測できないBashコマンド B コードを読めば分かる内容 C テスト手順 Q4 CLAUDE.md が長すぎるとどうなる？ A 実行が速くなる B 重要ルールが埋もれて無視されやすい C 変化なし 出典: 解答は「解答と解説」スライド（p.20） 9

上り坂①｜検証を与える：停止をどこまで厳しく縛るか ① 1つのプロンプト ② /goal（セッション全体） ③ Stop hook（決定論的） ④ 第二の意見（レビュー） 苦しい｜上り坂 同じメッセージで「テストを実行して反復」と依頼。今日すぐ使える。 別の評価器が毎ターン後に条件を再確認。成立まで継続。 スクリプトでチェックし、合格までターン終了をブロック。 検証サブエージェントなど、新しいモデルが結果の反証を試みる。 公式の推奨：成功を「主張」させず、テスト出力・実行コマンドと結果・スクリーンショットなど「証拠」を見せさせる。 出典: Best practices「Give Claude a way to verify its work」(EN) code.claude.com/docs/en/best-practices ／ (JA) code.claude.com/docs/ja/best-practices 10

上り坂②｜ /goal の仕組み（正式名は単数形） /goal <条件> /goal /goal clear 目標を設定（すぐ1ターン目が開始） 現在／直近達成の目標を表示 目標を削除 （別名: stop off reset none cancel） 苦しい｜上り坂 押さえる事実（公式） 各ターン終了後の評価（小型・高速モデル） 未達 達成 不可能 Claude が理由を次ター ンの 指針として作業を継続 目標を自動クリア 達成を記録 条件は満たせないと判断 目標をクリア＋理由を記 録 ・セッションごとに目標は 1つ ・評価器は会話に出た内容だけで判断。コマンド 実行やファイル読取はしない ・実体はセッション内のプロンプト型 Stop hook の ラッパー ・要件：v2.1.139 以降／hooksが有効 （disableAllHooks 等では利用不可） ・非対話 -p でも実行可（claude -p "/goal …"） ・/clear で目標も削除 出典: /goal (EN) code.claude.com/docs/en/goal ／ (JA) code.claude.com/docs/ja/goal ／ Commands (EN) code.claude.com/docs/en/commands 11

上り坂③｜効く条件の書き方：測定可能・証明方法・制約 苦しい｜上り坂 ① 測定可能な終了状態 ② 述べられたチェック ③ 重要な制約 テスト結果／ビルド終了コード／ファ イル数／空のキュー 「npm test が 0 で終了」「git status がクリーン」など証明方法 「他のテストファイルは変更しない」な ど、途中で変えてはいけないもの × 弱い条件 ○ 強い条件 /goal いい感じに直して /goal 認証まわりをきれいに /goal test/auth の全テストが通り、lint がクリーン。 npm test が exit 0、他のテストファイルは変更しない。 or stop after 20 turns → 終わりを誰も証明できない。評価器が判断不能で、迷走・ 早期終了の原因に。 → 終了状態・証明・制約・上限が揃う。 出典: /goal「Write an effective condition」(EN) code.claude.com/docs/en/goal ／ (JA) code.claude.com/docs/ja/goal 12

上り坂④｜ /goal 運用：権限・無人実行・失敗時の挙動 苦しい｜上り坂 論点 公式の説明（要旨） 権限 /goal は権限モードを変えない。Manual では許可外のツール呼出しで確認が出る。無人で回すには auto mode と併用（auto は単一 ターン内の承認、/goal はターンごとの再開） /loop・Stop hook との違い /loop は時間間隔で再実行。Stop hook は設定ファイルに常駐し、スクリプト/プロンプトで判定。/goal はセッション限定のショートカット 修正が必要なエラー 認証失敗（自前管理時）・クレジット枯渇・自動圧縮で解消できないコンテキスト溢れ・利用不可モデル → 目標がクリアされる。直して再 設定 その他の失敗 過負荷・接続断は自動再試行（3回後に一時停止）。レート制限・使用量上限などは一時停止（v2.1.269以降の対話セッション） バックグラウンド作業 サブエージェント/バックグラウンドシェル実行中はそのターンの評価を保留。既定30分でチェックイン（v2.1.234以降） コスト 評価は小型高速モデルで課金（通常はメインターンに比べ無視できる）。状態表示でターン数・トークン消費を確認 出典: /goal (EN) code.claude.com/docs/en/goal ／ Permission modes (EN) code.claude.com/docs/en/permission-modes ／ (JA) /ja/goal・/ja/permission-modes 13

上り坂⑤｜ Claude API：何が用意されているか 苦しい｜上り坂 API エンドポイント 用途（公式の説明） Messages API POST /v1/messages Claudeとの会話・テキスト生成の中心 Message Batches POST /v1/messages/batches 大量リクエストを非同期処理（50%コスト削減） Token Counting POST /v1/messages/count_tokens 送信前にトークン数を数え、コストと上限を管理 Models GET /v1/models 利用可能なモデル一覧 Files POST /v1/files ファイルをアップロードして複数呼出しで再利用 Skills POST /v1/skills カスタムなエージェントSkillの作成・管理 認証・SDK：Authorization: Bearer ／ x-api-key（従来方式）＋ anthropic-version（必須）。SDK は Python・TypeScript・C#・Go・Java・PHP・Ruby ベータ：Agents／Sessions／Environments API（Claude Managed Agents）。Google Cloud・Amazon Bedrock・Microsoft Foundry 等でも 利用可 出典: API overview (EN) platform.claude.com/docs/en/api/overview ／ (JA) platform.claude.com/docs/ja/api/overview 14

上り坂⑥｜ツール使用ループ： APIで自作ツールを動かす

苦しい｜上り坂

1 送信

2 判断

3 実行

4 返却

5 回答

tools と messages
を含むリクエスト

stop_reason が
"tool_use"

自分のコードが
処理を実行

tool_result を
次リクエストに追加

Claude が結果を
使って最終回答

import anthropic
client = anthropic.Anthropic()
# ANTHROPIC_API_KEY を環境変数から読む
tools = [{"name": "get_test_status",
"description": "CIの最新テスト結果を返す",
"input_schema": {"type": "object", "properties": {"branch": {"type":
"string"}},
"required": ["branch"]}}]
msgs = [{"role": "user", "content": "mainのテスト状況は？"}]
r = client.messages.create(model="<model-id>", max_tokens=1024, tools=tools,
messages=msgs)
while r.stop_reason == "tool_use":
# tool_use ブロックを実行 → tool_result を user メッセージで返す（公式のループ）
...

設計のポイント

・description は「いつ呼ぶか」をClaude
が判断する材料
・input_schema は JSON Schema
・strict:true でスキーマ厳守
・tool_choice 既定は auto
・SDKの tool runner（ベータ）でループを
自動化可

出典: Tool use overview (EN) platform.claude.com/docs/en/agents-and-tools/tool-use/overview ／ (JA) platform.claude.com/docs/ja/agents-and-tools/tool-use/overview

15

上り坂⑦｜どれを選ぶ？ SDK・CLI・Managed Agents 苦しい｜上り坂 やりたいこと 選ぶもの 得られるもの（公式） ターミナルで対話開発・1回限りのタスク Claude Code CLI 日常の対話利用向けのターミナル。/goal 等もここ 自社アプリ内に Claude Code のエージェントを組み込 む Agent SDK（Python／TypeScript） 組込ツール・権限・セッション・hooks・サブエージェント ・MCP を自前プロセスで APIを直接呼ぶ（ツールループは自作） Client SDK API直結。tool runner（ベータ）でループ自動化も可 Anthropicがエージェントをホスト Managed Agents マネージドのサンドボックス＋セッション。長時間・非同期 向き 認証：サードパーティ製品で claude.ai ログインを提供するのは原則不可。 APIキー認証を使う（公式注記）。 出典: Agent SDK overview (EN) code.claude.com/docs/en/agent-sdk/overview ／ (JA) code.claude.com/docs/ja/agent-sdk/overview 16

頂上チャレンジ｜仕様 →/goal→敵対レビュー（ 20分） 1 仕様化（ 5分） Plan Mode で「CSV集計CLI」をインタビュー形式で SPEC.md に。受け入れ基準を 5つ、スコープ外を 明記。 2 条件設計（ 3分） 新セッションで条件を書く：終了状態・証明・制約・ 上限（or stop after 15 turns）。 3 自律実行（ 7分） /goal で実行。/goal（引数なし）でターン数・トークン ・直近の理由を確認。 4 敵対レビュー（ 3分） サブエージェントに SPEC.md と差分を照合させ、 要件未達とテスト漏れのみ報告させる。 5 振り返り（ 2分） 条件は十分だったか？ 証拠（テスト出力）で語れる か？ ここが本日唯一の山場。詰まっても正常。条件の穴こそ学びです。 頂上チャレンジ（ 1回だけ） /goal SPEC.md の受け入れ基準1〜5がすべて満たされ、 "pytest -q" が exit 0、"ruff check ." がクリーン。 tests/ 以外のテストは変更しない。 また、各ターンで未達の基準を報告し、 15ターンで停止して残課題を要約する。 評価基準（講師用） □ 受け入れ基準が測定可能か □ 証明方法が条件内にあるか □ 制約・上限があるか □ 完了を「証拠」で示せたか □ レビューで未達を1つ以上発見できたか 出典: Best practices（SPEC.md／/goal／adversarial review）(EN) code.claude.com/docs/en/best-practices ／ /goal (EN) code.claude.com/docs/en/goal 17

法人導入｜無人で回すときのガバナンス設計 苦しい｜上り坂 モード 確認なしで実行されるもの 法人利用での目安（公式の用途） default（Manual） 読み取りのみ 機密作業・最初の導入 plan 読み取りのみ 変更前の調査・計画 acceptEdits 読み取り＋ファイル編集等 レビューしながら反復 auto 分類器の審査つきで実行 長時間タスク。安全の保証ではない dontAsk 事前承認済みツールのみ ロックダウンしたCI・スクリプト bypassPermissions すべて 隔離コンテナ／VMのみ 多層防御 独立レビュー 証拠と責任 allow/deny ルール＋サンドボックス ＋hooks（決定論） 別コンテキストのサブエージェント ／/code-review 証拠で確認。最終判断と責任は人 出典: Permission modes (EN) code.claude.com/docs/en/permission-modes ／ (JA) /ja/permission-modes ／ Best practices (EN/JA) 18

最終テスト｜頂上チャレンジ後の確認（ 6問） 確認テスト Q1 目標設定の正しい構文は？ A /goals <条件> B /goal <条件> C /target <条件> Q2 /goal の評価器は何をする？ A テストを自分で実行 B 会話に出た内容から条件の成否を判定 C ファイルを直接読む Q3 効く条件の3要素を挙げよ（記述式） Q4 /goal の実行を一定回数で止めるには？（記述式） Q5 クライアントツール使用で、アプリ側がやることは？ A tool_use を実行し tool_result を返す B 何もしない C Anthropicが自動実行 Q6 /goal を無人で回すとき、権限プロンプトを減らすために併用するのは？ A bypassPermissions 必須 B auto mode C 併用不可 出典: 解答は「解答と解説」スライド（p.20） 19

解答と解説 確認テスト 小テスト（助走） 最終テスト（頂上後） Q1 B：インタビュー→SPEC.md→新セッションで実行。 Q1 B：単数形 /goal。 Q2 B：評価器はツールを呼ばず、会話に出た内容のみ判 断。 Q3：測定可能な終了状態／述べられたチェック／重要な制 約。 Q4：条件に「or stop after 20 turns」のような句を入れる。 Q5 A：tool_use→自分で実行→tool_result を返す。 Q6 B：goalは権限モードを変えない。auto mode と併用。 Q2 B：Plan Mode は読み取り中心で変更しない。 Q3 B：コードから分かる内容は入れない（含める／除 外表）。 Q4 B：長すぎるとルールがノイズに埋もれ、無視され る。 出典: best-practices／goal／tool-use／permission-modes の公式ページ（p.22参照） 20

下山｜振り返りと、明日からの 3アクション 楽しい｜下山・振り返り アクション 1：今日 アクション 2：今週 アクション 3：今月 次の小さなタスクで「テストを実行して 反復」を依頼し、証拠（出力）を出させ る CLAUDE.md を見直し、「消すとミス が増えるか」で削る。SPEC.md のひ な形を作る 小さな実タスクで /goal を auto mode と併用し、ターン数・トークンを 記録してチームに共有 振り返りの問い ・今日、いちばん「できた」と感じた瞬間は？ ・あなたの現場で、完了を「証拠」で示せない作業は何ですか？ 出典: 本講座の学習設計：うさうさ研修工房坂道型学習設計 21

参考：公式サイト（日本語／英語） 概要 テーマ 日本語 English /goal code.claude.com/docs/ja/goal code.claude.com/docs/en/goal コマンド一覧 code.claude.com/docs/ja/commands code.claude.com/docs/en/commands ベストプラクティス code.claude.com/docs/ja/best-practices code.claude.com/docs/en/best-practices 権限モード code.claude.com/docs/ja/permission-modes code.claude.com/docs/en/permission-modes Agent SDK code.claude.com/docs/ja/agent-sdk/overview code.claude.com/docs/en/agent-sdk/overview Claude API 概要 platform.claude.com/docs/ja/api/overview platform.claude.com/docs/en/api/overview ツール使用 platform.claude.com/docs/ja/agents-and-tools/tool-use/overview platform.claude.com/docs/en/agents-and-tools/tool-use/overvi ew Spec Kit（第三者） ― github.github.com/spec-kit/ 学習設計の拠り所：Vygotsky (1978)／Bjork & Bjork (2011)／Kapur (2008)／Roediger & Karpicke (2006) 出典: 確認日：2026年10月17日。ドキュメントは更新されるため、受講前に最新版で再確認してください。 22