Upgrade to Pro — share decks privately, control downloads, hide ads and more …

変更を操る Agent Coding

変更を操る Agent Coding

[Vibe Code Insight! 〜AIコーディングLT大会〜](https://atware.connpass.com/event/374231/) にて発表させていただきます。

Avatar for Fumitaka Yokoyama

Fumitaka Yokoyama

January 28, 2026
Tweet

More Decks by Fumitaka Yokoyama

Other Decks in Programming

Transcript

  1. 私たちが直⾯した課題 無制御下の Agent AI は圧倒的な量の Output をするが、 • コードの悪品質 ◦

    設計⼀貫性の⽋如や密結合なコードが混⼊する • 達成条件を満たせない ◦ バグ、動作しない • レビュー負荷 ◦ 差分量が膨⼤、可読性が低い • 負債の⾼速⽣産 ◦ 既存のレガシーコードをAIが横展開
  2. 私たちが直⾯した課題 その結果、 • 怒りのロールバック • コード⽣成には Chat AI や 補完型

    AI のみ使⽤ ◦ Agent は書き捨てのコードでだけで使う • 機能仕様と伴に詳細設計の指⽰も与えなければならない ◦ ちょっとした変更に対して⼤変な準備量 • コストが⾼くて Agent 育成作業を後回しに • レビュー負荷が⾼くスループットが上がらない
  3. 解決へのアプローチ 🧩 • 変更の質を⾼める ◦ Output ではなく Outcome を出させる ◦

    効率ではなく効果 ◦ Vibe Coding ではなく、Agentic Coding • 変更を確かめさせる ◦ AIに⾃⼰検証‧⾃⼰修正をさせる • 変更を分ける ◦ タスクの粒度を⼩さくして品質を⾼める ◦ 変更のトレース‧修正を容易にする
  4. 解決へのアプローチ 🧩 • 変更の質を⾼める ◦ Planning ◦ 理想状態の定義 ◦ Context

    Engineering ◦ 仕様駆動開発 (Spec-driven development) ◦ Context Rot の回避 ◦ TDD
  5. 解決へのアプローチ 🧩 • 変更を確かめさせる ◦ Test を叩かせる ◦ Debug させる

    ◦ Agentic Workflow ▪ 評価関数を与えて実⾏させる ▪ ⾃律的に変更と評価をループ ◦ TDD
  6. Claude Code “Skill” • Agent Skills • Claude Code の能⼒を拡張するパッケージ

    ◦ Skill が必要になった時に呼び出せて、指⽰を与えれて、 スクリプト実⾏などもできる ◦ Claude が⾃動で使⽤、またはユーザーが指⽰ • 特徴: 3つのタイプの Skill コンテンツ ◦ Metadata, Instructions, Resources and code ◦ 段階的な情報開⽰ (Progressive Disclosure) • skill-creator ◦ anthropics/skills
  7. .claude/ └── skills/ ├── code_reviewer/ │ ├── SKILL.md # スキルの定義(メタデータ、指示)

    │ ├── review_template.md # テンプレート │ └── diff_analyzer.py # 差分を解析するための実行用スクリプト │ └── api_tester/ ├── SKILL.md ├── request_body.j2 └── run_test.sh Claude Code “Skill”
  8. 「変更を分ける」の具体的な⽅策 📦 • Skill tidy ◦ Refactoring‧構造変更のみを切り分けて⾏う • Skill commit

    ◦ 変更のトレース‧修正を容易にする • Skill autopilot ◦ 品質を保ちながら Agent に⾃⾛させる ✈
  9. Skill tidy - Concept • 「振る舞い」を変えない構造変更のみを実施 ◦ 『Tidy First? 』

    • Test First による安全確保 ◦ まずテストの充⾜状況を調査 ◦ 不⾜があれば先にテストを実装する • 振る舞いの変更がないことを機械的に検査しながら、 コードの整頓を⾏う
  10. Skill commit - Concept • 変更のトレース‧修正を容易にする ◦ 分割したタスクの checkpoint を残させる

    ▪ → 結局⼈間にして欲しい commit と同じ ▪ Conventional Commits • Workflow の中で commit を使わせる • 変更をレビューする ◦ diff ではなく log を読む ◦ rebase で簡単に修正できるのがベスト
  11. Skill autopilot - Concept • 全ての変更を「構造的変更(Structural Change)」と「機能的変更(Functional Change)」 に分け、混ぜない •

    必要であれば Parallel Change(Expand and Contract) ◦ 拡張、移⾏、縮⼩でインターフェースへの下位互換性のない変更を安全に実装 • Workflow ◦ 1. 分析とテストの充⾜ (Test-First) ▪ 要求仕様を分析し、変更箇所の既存テストを確認。 ▪ リファクタリングを安全に⾏うため、不⾜しているテストを先に拡充する。 ◦ 2. 構造的変更 (Structural Change): ▪ 機能変更を容易にするためのリファクタ、型定義、空のAPI等を作成。 ▪ 既存の振る舞いは⼀切変えない。 ◦ 3. 機能的変更 (Functional Change / Logic): ▪ 機能要件を満たすロジックを実装。 ◦ 4. 最終検証 ▪ 全テストの成功を確認し、要件の達成を証明する。 • レビュー効率を最⼤化するステップを⾃ら設計し、細かく変更を commit させる
  12. Skill autopilot (抜粋) --- name: autopilot description: | Autonomous development

    workflow engine that enforces strict separation of structural and functional changes for maximum review efficiency. Use when the user requests implementation of new features, bug fixes, performance improvements, or refactoring. Triggers on requests like "implement [feature]", "fix [bug]", "optimize [performance]", "add [functionality]", or when the user provides specifications via file or description. Also triggers when user explicitly invokes "/autopilot". --- ~/.claude/skills/autopilot/SKILL.md
  13. Skill autopilot (抜粋) ## 4-Phase Workflow ### Phase 1: Analysis

    and Test Foundation (Test-First) **Objective:** Understand requirements and ensure safe refactoring through adequate test coverage. **Actions:** 1. Analyze the requirement specification (from user message or provided file) 2. Identify the code areas that will be modified 3. Read existing tests for those areas 4. Identify missing test coverage (edge cases, error paths, integration points) 5. If tests are insufficient, add tests to cover existing behavior BEFORE any changes **Test Execution:** Run tests after adding new test coverage - Command: project-specific test command (e.g. `npm test`, `./gradlew test`) - Must pass before proceeding **Commit:** Use `/commit` skill for test additions ~/.claude/skills/autopilot/SKILL.md
  14. Skill autopilot (抜粋) ### Phase 3: Functional Change (Logic Implementation)

    **Objective:** Implement the actual behavioral changes using Test-Driven Development. **TDD Cycle:** Use `/tdd` skill to iterate through the Red-Green-Refactor process for each small unit of logic. **IMPORTANT:** Create a separate commit after completing EACH TDD cycle (each Red-Green-Refactor cycle). Do NOT batch multiple behaviors into one commit. **What happens in this phase:** - Implement new business logic - Add new features - Fix bugs - Connect new structures to actual functionality - Modify algorithms and data transformations - Add validation and error handling **Test Execution:** Run tests after each TDD cycle - New tests should pass - All existing tests must still pass ~/.claude/skills/autopilot/SKILL.md
  15. Skill autopilot (抜粋) ### Phase 4: Final Verification **Objective:** Confirm

    all requirements are met and the system is stable. **Actions:** 1. Run complete test suite 2. Verify all tests pass 3. Confirm all requirements from Phase 1 are satisfied 4. Check for any edge cases or error scenarios **Test Execution:** Full test suite including: - Unit tests - Integration tests - E2E test (if applicable) **Commit:** Usually not needed unless final adjustments are required **Output:** Fully implemented, tested, and verified feature/fix ~/.claude/skills/autopilot/SKILL.md
  16. 評価 👍 • “Tidy First” は設計思想の伝達率が⾼い ◦ AI は周囲のコード (コンテキスト)

    に強く引きずられるので ◦ 設計思想をたっぷり与えただけの機能変更よりも、 品質の向上が期待できると思ふ • トレーサビリティは天と地の差 • ⼀般論に基づくリファクタではなく、 機能変更を前提とした既存構造の拡張ができる • 変更を分割するアプローチは有効
  17. 評価 👎 • ドキュメントがまだまだ荒い • 複雑な構造変更は詳細な仕様を与えてあげないとうまくいかない • 設計思想をきちんと与えられるようなドキュメント育成が必要 • autopilot

    するために⾝につけてほしい Skill がたくさんある • token ⾜りねえ 💸 ◦ ボリュームの多いタスクをやらせると、Plan で結構くらう ◦ Context 節約のための戦略が必要 ◦ もしくは token を気にしなくて良い環境が必要 (上司 🥺)
  18. まとめ: 「分ける」の重要性 • 重要概念 “段階的開⽰” ◦ Skill は 3-layer で

    Context 節約をしつつパワーが出せる ◦ 分けることはAIの世界でも重要 • Agent 育成 も同じ ◦ 最初は⼩さいタスクから始めて精度を⾼める ▪ ⼩さいタスク単位で Skill を作っていく ◦ autopilot は最終的に Skill の集合になりそう
  19. まとめ: 「分ける」の重要性 • Human Developer も同じ ◦ AIにやって欲しいと思って指⽰していることは、 チームメンバー (⼈間)

    にもやって欲しいこと ◦ AI時代の量的な加速により、⼈間が⽣む問題が構造 はそのままで膨れた ◦ TDD、構造変更の分離、読める commit