Claudeを飼い慣らす環境づくり

【AI駆動開発】AI自走環境構築・運用スペシャル #1 でのLT登壇資料です。

https://aid.connpass.com/event/388525/

Transcript

1. Claudeを飼い慣らす環境づくり 2026/04/09 / ピーディーシー株式会社 蔵品絢介
2. 自己紹介 プロフィール ニックネーム：くらっち 新卒4年目（25歳） ピーディーシー株式会社 システム開発部 アプリケーションエンジニア JAWS-UG 東京支部 運営 ↓ お猿さんアイコンが目印！ X アカウントはこちら！↑ 業務内容 社内業務用 Web アプリケーション開発 （Ruby on Rails） 生成 AI R&D（主に Amazon Bedrock AgentCore） 弊社デジタルサイネージソリューションプロ ダクト開発チームのQA業務 2
3. 今日話すこと 01 Skills とは？ 02 2種類のスキル（ワークフロー型 vs 単発型） 03 仕様駆動開発スキルとハーネス設計 04 Hooks でガードレールを設ける 05 ワークフローを効率的 & 速く回す工夫 06 まとめ 3
4. Skills とは？
5. Skills とは？ ★ 私たちがよく実行することを簡単に呼び出す ための仕組み SKILL.md に 指示 や ナレッジ などを記載 スラッシュコマンド（ /skill-name ）で呼び出せる → 毎回の文章入力が不要 必要なときだけ読み込まれる → 毎セッションのコンテキストを圧迫しない ├── .claude │ └── skills │ └── sample-skill-name │ ├── format │ │ └── format.xlsx │ ├── scripts │ │ └── generate_report.py └── └── SKILL.md 今回はSkillのスコープについては触れません 5
6. Skillsには大きく分類して 2種類あると考えています。 （個人の感想）
7. 2種類のSkills ワークフロー型 複数ステップ を段階的に実行 タスクの流れが決まっている 場合や ステップを踏んだ方が質が高くなる 場合 に向いている 例: 仕様駆動開発スキル, スライド生成スキル 単発型 1つのタスク をスポット的に実行 ナレッジ検索・APIの実行・ドキュメント の更新などの1つのタスクに向いている 例: Backlog API実行スキル 私のベストプラクティス 「ワークフロー型スキルを軸に、各ステップに単発型スキルを入れる」 7
8. 開発をより効率的に進めるためのSkill
9. 仕様駆動開発スキル（ワークフロー型） No ステップ 成果物 内容 1 Issue取得 - Backlogの課題から人間の要件を取得 2 要件定義 requirement.md Issueから生成。ユーザ承認後に次へ 3 基本設計 basic-design.md requirement.md から生成。ユーザ承認後に次へ 4 詳細設計 detail-design.md basic-design.md から生成。ユーザ承認後に次へ 5 タスク分解 task.md コーディングエージェントが実装できる粒度に分解 6 実装 - コーディングエージェントが実装 7 レビュー - AIによる1次レビュー/人間による2次レビュー 要件定義 基本設計 詳細設計 タスク分解 実装 9
10. 仕様駆動開発スキル — 設計思想 ユーザの暗黙知を成果物として明文化することで、エージェントとユーザの認識の乖離を減らす ワークフロー型スキルの実行者は メインエージェント 各ステップのスキルの実行者は サブエージェント 各ステップ内では NG行動のみを厳密に指定 し、 サブエージェントが自律的に判断してスキルを実行 エージェントに対するハーネスはしっかりと定義しておく！ 10
11. ハーネスエンジニアリングの考え方
12. ハーネスエンジニアリングって何？ AIエージェントが自律的に質の高い成果物を生成できるように、 人間が周辺環境やルール、ガードレール（ハーネス）を設計・整備する手法。 前述した ワークフロー は、ガッチガチのハーネス であると私は考えます。 ハーネスの定義方法はさまざまです。 CLAUDE.md ← ルールの定義 rules ← ルールの定義 Skills Hooks ← 絶対に超えてはいけない一線をブロック 12
13. 一般的なハーネスとワークフローの違い 道路に例えると多分わかりやすいです。 一般的なハーネス 道路交通法の制定 「やっていいこと」 「やってはいけないこと」をルール化する ガードレールの設置 「やってはいけないこと」をHooksで指定して、やらかした場合に止める ワークフロー（ガッチガチのハーネス） 目的地までの ナビゲーションの設定 目的地までの経路を設定してその通りに動かす 13
14. Hooksでリスクを制御
15. 絶対的なハーネス: Hooks の活用 CLAUDE.md や rules は advisory（助言）、Hooks は deterministic（決定的）。 つまり、Hooksは自律的にではなく、絶対に実行されるツール である。 例1：誤プッシュ防止 git push 前に確認を強制 git push origin master を実行しようとし た際にブロック 例2：ファイル保護 変更したらダメなファイルを変更しようとし た際にブロック 例3：APIキーの保護 echo $XXXXX_API_KEY などのコマンド実行を禁止 .env , ~/.zshrc を参照するのを禁止 15
16. ワークフローを効率的 & 速く回したい！
17. ワークフローを効率的 & 速く回したい！ ワークフロー実行1回の時間が長いと次のIssueの対応ができなくなる コンテキストを圧迫してエージェントの精度を落としたくない 17
18. 工夫1: 単発スキルには context: fork context: fork を指定することによって、スキルをサブエージェントのコンテキストで起動できま す。 これにより、不要な情報がメインエージェントのコンテキストに入らないため、コンテキストが汚れ ることを防げます。 単発型Skillで指定する ✓ レスポンスに不要なデータが含まれている可 能性がある以下のようなスキルは特に！ API実行スキル ナレッジ検索スキル ワークフロー型Skillでは指定しない 各ステップでユーザの承認を得ることができ なくなる ユーザの承認が不要な場合など、指定して OKなケースもある 18
19. 工夫2: MCPサーバは極力使わない MCPサーバはコンテキスト効率が悪い MCPサーバの場合、毎回のリクエスト時に全ての情報が流れ込んできます。 一方で、Skillsの場合、毎回のリクエスト時は name と description のみの読み込みだけに留まり ます。 プロンプトキャッシュ効率が悪い MCPサーバにツールが追加された場合、キャッシュされたツールの情報と実際のツールの情報が異 なる場合がある。これだとキャッシュのロードミスになるため、ツール情報取得の再計算が行わ れ、処理コストの増加と遅延が生じてしまう 19
20. MCPサーバは極力使わない理由（補足） 1. チーム内への共有が簡単 MCPサーバの場合、各メンバーが自分でセットアップする必要がある Skillsの場合、Plugin Marketplace を使えば最初にインストールするだけで使えるようになる 2. カスタムしやすい MCPサーバは決まり切った処理は可能だが、Skillsは処理を必要に応じてカスタム可能 決して、MCPサーバを使うのが悪いわけではなく、APIで情報を取得できないものは、 MCPサーバに頼りましょう。 例: AWS IaC MCP Server, Microsoft Learn MCP Server など 20
21. まとめ 1. Skills はナレッジ・ワークフローをコード化し、毎回の入力を省略する仕組み 2. ワークフロー型 で流れを制御、単発型 で各タスクを独立させる 3. ハーネス は「NG行動のみ指定」— エージェントの自律性を損なわない 4. Hooks は絶対的なガードレール — 助言的な役割の CLAUDE.md と役割を分担 5. context: fork で単発スキルの不要なデータをメインコンテキストから隔離 6. Skills 優先 で MCP サーバの起動オーバーヘッドを削減 Claudeを「飼い慣らす環境」= 自律性を保ちながらリスクを制御できる環境 21
22. ご清聴ありがとうございました