superpowers でまわるCDK

Transcript

1. JAWS-UG鹿児島 夏の風物詩：AWS×AI まわるLT大会 superpowers でまわるCDK 2026/8/28 株式会社クエイル 代表取締役 池田 武尚
2. SECTION 01 / 06 SPEAKER 🙋 自己紹介 名前 所属 出身 池田 武尚（イケダ タケヒサ） 株式会社クエイル 代表取締役 鹿児島県南さつま市 これまでの道のり 01 02 03 04 金融系システム（COBOLer） 医療系システム（Windowsアプリケーション ＆ FLASHアプリケーション） Webサイト制作 クエイル
3. SECTION 01 / 06 🙋 自己紹介 AWS認定・アワード FOUNDATIONAL（2）・ASSOCIATE（5） Cloud AI Practitioner Practitioner Solutions Architect Developer SysOps Data Engineer Administrator Machine Learning Engineer PROFESSIONAL（2）・SPECIALTY（3）・アワード（3） Solutions Architect DevOps Engineer Advanced Networking Security Machine Learning All Japan AWS Japan AWS Certifications Top Engineer Top Engineer Engineer 2026 2026 2025
4. SECTION 02 / 06 導入 🧰 そもそも superpowers とは？ Claude Code 発の「スキル」集。AIに“作業のやり方”を教え込む手順書をパッケージ化したものです。 2025年10月ローンチ。現在は v6.3.0（2026-08-12リリース） まで進んでおり、稼働期間は約10ヶ月です。 GitHubスター数27万超（2026年8月時点）。しかも急成長中：出典記事（2026年2月時点）では「4万超」だったのが、約半年で約7倍に伸びて います。Claude Codeマーケットプレイスでの導入数はPlaywrightを上回るという記事もあります（出典（2026年2月の過去記事））。
5. SECTION 02 / 06 🧰 そもそも SUPERPOWERS とは？ 主要なハーネス／SDD・スキル系との比較 スター数は 2026-08-28 時点の実測値です。「初リリース」はリポジトリ作成月です。 プロジェクト 種別 obra/superpowers affaan-m/ECC Claude Code スキル集（SDD×Loop） エージェント・ハーネス最適化のスキル集 multica-ai/andrej-karpathy-skills Karpathy氏の見解由来の CLAUDE.md 一枚もの anomalyco/opencode オープンソースのコーディングエージェント（ハーネス） anthropics/skills github/spec-kit Anthropic公式の Agent Skills 集 SDD（仕様駆動）ツールキット 旧 everything-claude-code 旧 sst/opencode ★スター 初リリース 243,800 2025年10月 2026年1月 208,300 2026年1月 278,800 最終更新 2026-04 202,000 172,200 131,900 2025年4月 2025年9月 2025年8月
6. SECTION 02 / 06 🧰 そもそも SUPERPOWERS とは？ 主要なハーネス／SDD・スキル系との比較（続き） プロジェクト 種別 ★スター 初リリース Fission-AI/OpenSpec SDD（仕様駆動）フレームワーク 66,500 2025年8月 gotalab/cc-sdd Kiro互換（要件→設計→タスク）SDDハーネス 3,600 2025年7月 最終更新 2026-05 後発（2025年10月）ながら、このカテゴリで最多です。Anthropic公式の anthropics/skills より上で、「スキルとして後付けできる」導入の 手軽さと方法論の完成度が効いていると見られます。 📉 は 2026-04、 cc-sdd は 2026-05 から更新が止まっています。このカテゴリは伸びる／止まるの差が激しく、選ぶときはス ター数より最終更新日を見た方がよいという話でもあります。 andrej-karpathy-skills
7. SECTION 02 / 06 🧰 そもそも SUPERPOWERS とは？ 作者と思想 作者は Jesse Vincent（ハンドル名 obra）。Perl製チケット管理システム Request Tracker の作者としても知られるベテランOSS開発者です。 superpowers のコンセプトは「AIに“ベテランエンジニアのメンター”をつけて、プロのソフトウェア開発プロセスを強制的に踏ませる」と いうものです。 「AIに多くコードを書かせることではなく、プロのエンジニアのように考え・働かせることが鍵」として、TDD・体系的デバッグ・構造化 された計画立案といった数十年分の開発方法論をスキルとしてエンコードした、と説明されています。 いちばんのポイントは、いきなりコードを書かせないことです。人間の開発と同じく「設計 → 計画 → 実装 → レビュー」の型をAIに踏ませます。 ステップ スキル やること ① 設計 brainstorming 何を作るか・要件を対話で詰め、設計メモを書く ② 計画 writing-plans 実装手順をチェックボックスのタスクに分解する ③ 実装 executing-plans 計画に沿って1タスクずつ実装・検証する
8. SECTION 02 / 06 🧰 そもそも SUPERPOWERS とは？ 作者と思想（続き） 🔑 要は：AIの一番の弱点は「いきなり書き始めて迷子になること」です。superpowers は “先に設計と計画を書かせる” ことで、それを防ぐ仕組 みです。
9. SECTION 02 / 06 🧰 そもそも SUPERPOWERS とは？ 対応プラットフォーム Claude Code／Codex（CLI・App）／Cursor／OpenCode／GitHub Copilot CLI／Gemini CLI／Devin CLI／Grok Build CLI／Kimi Code／ Antigravity／Factory Droid／Pi（13種、2026年8月時点のREADME） ※ インストール手順は各ハーネスで少し異なります（複数使う場合はそれぞれに入れます）。
10. SECTION 03 / 06 方法論 🔁 superpowers の正体（SDD × Loop） superpowers は、有名な2つの開発規律をまとめて一体で実装したハーネス（＝AIを御する手綱・実行基盤）と整理できます。 SDD（仕様駆動開発）：「仕様が一番の成果物、コードはそこから派生するもの」と捉えます。“雰囲気で書く（vibe coding）”への反省から生 まれました。 Loop Engineering：「ゴール定義 → 実行 → チェック → 差し戻し → 停止」という終わりのある反復ループを設計します。 両者は競合ではなく補完の関係です：「仕様の受け入れ基準が、そのままループの停止条件になる」。 📖 参考：SDDとLoop Engineeringの関係 ― superpowersは両者を統合したハーネスだった（Qiita） ⚠️ 補足：「SDD」「Loop Engineering」という呼び方自体は、obra/superpowers 本体のリポジトリ内には出てきません（GitHub code search で確認： ／ Loop Engineering は0件）。つまりこの整理は参考リンクのQiita記事による外部からの分析的な命名であり、superpowers公式が名 乗っている用語ではありません。 推察される理由：superpowers 自体は「SDD」「Loop」のような抽象的な方法論名を掲げず、 brainstorming ／ writing-plans ／ test-driven-development といった具体的で呼び出し可能なスキル名だけで語る設計思想です。理論にラベルを貼るより、動く仕組み（スキルの強 制フロー）そのものを成果物にするという一貫した実利主義が背景にあると考えられます。 spec-driven
11. SECTION 03 / 06 🔁 SUPERPOWERS の正体（SDD × LOOP） 実際の全工程（7段階） （仕様を承認）→ using-git-worktrees → writing-plans （タスク分解）→ subagent-driven-development → test-driven-development → requesting-code-review → finishing-a-development-branch （マージ判定） brainstorming キモは 「提案ではなく必須（Mandatory workflows）」 であることです。逸脱を構造的に難しくしてあります。 ① 承認前の実装禁止 ② 次工程スキルの強制呼び出し ③ 検証なしに「完了」と言わせない 🧪 テストについて：コードを書く場面（機能実装・バグ修正）では テスト先行が必須で、検証を通すまで“完了”にできません。一方、ドキュメント・設 定・調査などテスト不要な作業は対象外です（人が明示すれば省略も可）。「コードを書くときは基本サボれない」というのが実態です。
12. SECTION 03 / 06 🔁 SUPERPOWERS の正体（SDD × LOOP） ブランチ／worktree も工程に組み込まれている 🌿 上のフローの2番目 と最後の finishing-a-development-branch の通り、superpowers は「設計承認後に新しいブランチ＋ 隔離した作業スペース（worktree）を切る → 作業 → 最後にマージ判定」までを標準工程に持っています。ブランチ運用は人が別途がんばるものでは なく、スキルの一部として自動的に踏まれます。 ブランチ＝コミット履歴上の“作業ライン”（論理的なポインタ）。「どの変更の流れか」を指します。 worktree＝1つのリポジトリから複数の作業フォルダを同時に開ける機能（物理的な作業場所）。フォルダごと隔離されるので、複数エージェントを 別ブランチで並行に走らせても衝突しません（その代わりフォルダは増えます）。 つまり ブランチ＝「どの履歴か」／ worktree＝「どこで作業するか」。superpowers は両者をセットで使います。 using-git-worktrees 🔑 要は：「良いプロンプトを書く」より、「仕様＋ループ＋検証ゲートという実行基盤（ハーネス）を設計する」方が、AIを長時間まともに自走さ せる鍵です。superpowers はその基盤そのものです。
13. SECTION 04 / 06 🎚️ タスクに応じたモデルの使い分け コスト最適化 superpowers には、タスクの重さに応じてAIモデルを自動で切り替える仕組みがあります。機械的な作業は安くて速い軽量モデル（Haiku）、判 断が要る作業は標準（Sonnet）、アーキテクチャ級の判断は最高性能（Opus）——というふうに、1タスクごとに“ちょうどいいモデル”を割り 当てます。 この仕組みが完成したのは v6.0.0（2026年6月）です。 2段階で入りました： ① 思想として登場（v5.x／2026年春）： subagent-driven-development の方針として「タスクの重さでモデルのティア （Haiku/Sonnet/Opus）を使い分けるべき」と明記されました。ただし強制ではなく、モデル名を省略すると親セッションの高価なモデルを そのまま引き継ぐ問題がありました。 ② 自動化・強制化（v6.0.0／2026年6月）：「すべてのディスパッチでモデルを明示する（Every dispatch states its model）」 を仕様化しま した。テンプレート側でモデル/ティアの指定を必須にしました。→ 機械的タスクでは親がどれだけ高価でも、サブエージェントが強制的に軽 量モデルへ切り替わります。
14. SECTION 04 / 06 🎚️ タ ス ク に 応 じ た モ デ ル の 使 い 分 け 🎚️ タスクに応じたモデルの使い分け（続き） 🎯 この自動切り替えは「サブエージェントへの委譲時」だけの話です。 で orchestrator がタスクをサブエージェントに 投げる、そのディスパッチ単位でモデルが振り分けられます。今チャットしている親セッション自体のモデル（人間が選んでいるモデル）は自動では変 わりません——親がOpusのままでも、委譲されたタスクだけがHaiku/Sonnet/Opusに振り分けられる、という範囲です。 subagent-driven-development
15. SECTION 04 / 06 🎚️ タ ス ク に 応 じ た モ デ ル の 使 い 分 け 振り分けの実例 あるプランでの想定です。「タスクの複雑さに応じて最小限のモデルを使う」という方針です。 タスク 複雑さ 想定モデル Task 1（スキーマ＋マイグレーション、判断要） 統合・判断 Sonnet Task 2（レジストリ、単純な定数定義） Task 3（POST /api/events、複数ファイル＋バリデーション判断） 機械的 統合 Haiku等の軽量モデル Sonnet Task 4（表示系4箇所へwhere句追加、機械的） 機械的 軽量モデル Task 5（複数ファイルにまたがる親チェック追加、判断要） 統合 Sonnet Task 6（update_eventへの1フィールド追加、機械的） Task 7（UIコンポーネント改修、判断要） 機械的 統合 軽量モデル Sonnet タスクレビュー（各タスク後） 差分規模に応じて 軽量〜標準
16. SECTION 04 / 06 🎚️ タ ス ク に 応 じ た モ デ ル の 使 い 分 け 振り分けの実例（続き） タスク 複雑さ 想定モデル 最終ブランチ全体レビュー アーキテクチャ判断 最も高性能なモデル 🔑 要は：「全部いちばん賢いモデルで回す」のは遅くて高くつきます。重い判断だけ高性能モデル、機械作業は安いモデルに自動で振り分けるこ とで、品質を落とさずコストとスピードを最適化できます。
17. SECTION 05 / 06 実践 📦 インストールと使い方 インストールは「ユーザー（マシン）単位」で一度だけです。superpowers は Claude Code のプラグインなので、プロジェクトごとに入れる必 要はなく、一度入れれば全プロジェクトで使えます。 インストールも Claude Code の中で完結します（ターミナルで別途何か入れる必要はなく、スラッシュコマンドを1つ打つだけ）。Anthropic の 公式プラグインマーケットプレイスに載っています： /plugin install superpowers@claude-plugins-official 作者の superpowers-marketplace 経由なら /plugin marketplace add obra/superpowers-marketplace → /plugin install superpowers@superpowers-marketplace の2コマンドです。
18. SECTION 05 / 06 📦 インストールと使い方 📦 インストールと使い方（続き） スキル本体は Claude Code のプラグインキャッシュ （ ~/.claude/plugins/cache/superpowers-marketplace/superpowers/<version>/skills/ ）に自動で展開され、セッション開始時に自動 アップデートされます。バージョンごとのフォルダで並存します。 チームで使うときも「各自が自分のマシンに一度入れる」だけです。プロジェクト側に設定を持たせる必要はありません。 コマンドを正確に覚えていなくても、「superpowersをインストールして」と日本語で頼めば、Claude Code が上のコマンドを実行して入れ てくれます（結局のところ Claude に指示するだけです）。
19. SECTION 05 / 06 📦 インストールと使い方 使い始め（ブレストの起点） と打てば、その場でブレスト（設計対話）スキルが起動します。 コマンドを覚えていなくても、日本語で「superpowersでブレストしたい」「これブレストして」と話しかけるだけでスキルが自動的に発火し ます（ using-superpowers の仕組みが「該当しそうなら必ずスキルを起動する」ようになっているため）。 スキルがちゃんと動くと、こういう表示が出ます（＝スキルが読み込まれた合図です。文言はバージョンで多少変わります）： /superpowers:brainstorming ⏺ Skill(superpowers:brainstorming) ⎿ Launching skill: superpowers:brainstorming そこから brainstorming → writing-plans → 実装 の型に自動的に乗っていきます。
20. SECTION 06 / 06 AWS ☁️ AWS CDK を AI に書かせる JAWS-UGなので、AWSの話もします。実際に動かしているプロダクトのインフラはすべて AWS CDK（TypeScript）で書いていて、その大半を Claude Code ＋ superpowers に書かせています。そこで分かってきたことを共有します。
21. SECTION 06 / 06 ☁️ A W S C D K を A I に 書 か せ る ① 構成：10スタックに割る スタック 担当範囲 SecretsStack Secrets Manager SecurityStack WAF（us-east-1） DsqlStack Aurora DSQL S3Stack CognitoStack S3 ＋ CloudFront 配信 認証（User Pool） ObservabilityStack CloudWatch Logs／Bedrock invocation log SesStack SES（メール送信） BedrockStack Bedrock Guardrails IamStack 実行ロール・権限
22. SECTION 06 / 06 ☁️ A W S C D K を A I に 書 か せ る ① 構成：10スタックに割る（続き） スタック 担当範囲 AmplifyStack Next.js ホスティング 主リージョンは ap-northeast-1 、WAFだけ us-east-1 に置く必要があるので crossRegionReferences: true でクロスリージョン参照して います。 🧩 なぜ細かく割るとAI駆動開発と相性が良いか：1スタック＝1ファイル＝1タスクに落ちます。 のタスク分解にそのまま乗り、 subagent-driven-development で1スタックずつサブエージェントに投げられます。差分が小さいのでレビューも通しやすくなります。 逆に巨大な1スタックにすると、AIが毎回ファイル全体を読み書きすることになり、トークンも事故率も上がります。 writing-plans
23. SECTION 06 / 06 ☁️ A W S C D K を A I に 書 か せ る ② AIに実AWSを触らせるためのガードレール ここが本題です。AIエージェントに cdk deploy を打たせるということは、本番インフラを変更できる手を渡すということです。このプロジェク トでは、まず3段構えで進めてみました。これが最適解というわけではなく、「とりあえず引いてみた境界」です。 IAM を IP 制限してみた デプロイ用のIAMに、許可ネットワーク以外からは全APIを explicit deny するポリシーを付けて進めてみました。AIが暴走しても、許可外からは 何も通りません。今回は、いちばん手早く引ける境界としてIP制限を選んだ、という位置づけです。
24. SECTION 06 / 06 ☁️ A W S C D K を A I に 書 か せ る ② AIに実AWSを触らせるためのガードレール（続き） プリフライトを必須にする ← ここに罠がある （AWS の whoami ）は IP制限を素通りします。権限が要らないAPIで、IAMで明示的に Deny しても成功する仕様の ためです。つまり「認証確認」だけは成功するのに、実APIは全部Denyされます。 AIはこれで確実に迷子になります。「認証は通っているのに AccessDenied」という状態から、権限まわりを延々と調べ始めて時間とトークン を溶かします。 そこで 非stsの実API（ cloudformation list-stacks ）で疎通判定するスクリプトを用意し、CDK操作の前に必ず通します。FAILなら中断し ます。 sts:GetCallerIdentity そのルールをAIに読ませる 上の内容を .claude/rules/cdk-operations.md に書いて、AIが毎回読むようにしています。「AIがハマるポイントを、先回りしてルールとして 書いておく」のが効きます。人間の新人向けオンボーディング資料とまったく同じ発想です。
25. SECTION 06 / 06 ☁️ A W S C D K を A I に 書 か せ る ③ 誤爆を「型」で止める CDKアプリのエントリで、環境指定が無ければ その場で throw して即死させています。AIが環境を指定し忘れたまま本番に流し込む事故が、デ プロイ以前に止まります。 const envContext = app.node.tryGetContext('env'); if (envContext !== 'staging' && envContext !== 'production') { throw new Error( 'Context "env" must be "staging" or "production". ' + 'Pass with --context env=staging' ); } アカウントIDも同様に必須化しています。「AIに気をつけてもらう」のではなく、間違えたら動かないようにするという考え方です。
26. SECTION 06 / 06 ☁️ A W S C D K を A I に 書 か せ る ④ CDK は出力が大きい＝トークンを食う / cdk diff の出力は CloudFormation テンプレート丸ごとで、平気で数十KBになります。出力が大きい操作はトークンを食うとい う問題が、ここでも直撃します。 cdk synth は対象スタックを絞って叩きます synth の結果はファイルに落としてから必要な部分だけ読ませます cdk diff 🔑 要は：AIにインフラを書かせるときは、「賢いAIを選ぶ」より 「事故っても被害が出ない境界を先に作る」 方が効きます。IAMのIP制限・プリフ ライト・contextの必須化は、どれもAIのためというより人間の事故も同時に防いでいます。
27. SUMMARY 📝 まとめ superpowers は「型」を強制する仕組みです。いきなり書かせず、設計 → 計画 → 実装 → レビューを必ず踏ませます。プロンプトを工夫する より効きます。 モデルは1タスクずつ選びます。機械作業は軽量モデル、重い判断だけ高性能モデル。品質を落とさずコストと速度が変わります。 CDKは細かく割るとAIとの相性が良くなります。1スタック＝1ファイル＝1タスクに落ちるので、計画のタスク分解とサブエージェント委譲に そのまま乗ります。 AIに実AWSを触らせるなら、境界を先に作ります。今回は IAM の IP 制限、プリフライトの必須化、context の必須化で試しました。「気をつけ てもらう」のではなく、間違えたら動かないようにします。 AIがハマる所は、先回りしてルールに書きます。 .claude/rules/ は人間の新人向けオンボーディング資料と同じです。一度書けば毎回効き ます。 💭 やってみた感想：最初は「AIに任せるなら、とにかく賢いモデルを」と思っていたのですが、実際に効いたのは先にガードレールを作っておく ことでした。superpowers も CDK まわりも、結局やっていることは同じだった、というのが正直な感想です。
28. THANK YOU FOR YOUR ATTENTION 🙇 ご清聴ありがとうございました