開発をもっとダイナミックに! dynamic workflowsの活用 / more dynamic developing with dynamic workflows

ClaudeCodeMeetupOsaka vol.3

Transcript

1. 開発をもっとダイナミックに! dynamic workflowsの活用 ClaudeCodeMeetupOsaka vol.3 / 2026-08-26
2. 自己紹介 名前: 太田拓也 経歴: SIer -> SaaS開発 -> クラスメソッド（2023/04〜） 業務: 小売流通業向けSaaSの開発 役割: プレイングマネージャー 備考: 今日のためにClaude Certified Architect Professionalを 取得しようと思ったが間に合わず 2
3. 今日お話しすること dynamic workflowsとは（スキルとの違い、使い分け） /team-review — 実運用しているレビューワークフロー 改善メタループ — 記録を資産にする faceted promptingで関心ごとを分離する 3
4. dynamic workflowsとは 動的ワークフローは、サブエージェントを大規模にオーケストレーションする JavaScript ス クリプトです。 https://code.claude.com/docs/ja/workflows 名前的にはclaude自身が大規模作業のために動的に生成するスクリプトを意図してそうだが、 実は任意のスクリプトを作成して呼び出すことができる。 export const meta = { name: 'audit-routes', description: 'Audit every route handler for missing auth checks', } const found = await agent('List every .ts file under src/routes/.', { schema: { type: 'object', required: ['files'], properties: { files: { type: 'array', items: { type: 'string' } } } }, }) const audits = await pipeline(found.files, file => agent(`Audit ${file} for missing authentication checks.`, { label: file }), ) return audits.filter(Boolean) https://code.claude.com/docs/ja/workflows#what-the-saved-script-looks-like 4
5. スキルとどう違うの？
6. スキル・ワークフローの違い スキル dynamic workflows 次に何をするか決めるのは Claude（指示に従う） スクリプト 中間結果の置き場 コンテキスト スクリプト変数 繰り返せるもの 指示 オーケストレーション自体 6
7. 使い分けの基準 7 判断軸 スキル dynamic workflows フローの複雑さ 単純〜煩雑 煩雑〜複雑 人間の介入 途中で採否を確認する 走り出したら最後まで コスト 作業次第 スキルに比べるとトークン消費が多くなりがち 小規模な手順は素直にスキルを使うほうが安価 途中で人間の判断が必要な処理はワークフローに不向き
8. /team-review 実運用しているレビューワークフロー。もっと信頼できるAIレビューへ
9. 組み込みの/code-review の課題感 ※日々変化しているため、今は改善されている項目もある。 このワークフローを作成しようと思った当時の課題感です 偽陽性 実際のファイルを読まずに推測で指摘する 組み込みスキルとしてのカスタマイズ性が低い CLAUDE.mdやREVIEW.md にすべて詰め込むのは無理がある 9
10. /team-review概要 10
11. ワークフローの特徴を活かした設計 エージェント呼び出しの調整 modelやeffortを細かく使い分けて 品質、コスト、レイテンシーのバランスを調整 プログラミングが向いている処理 指摘をファイルごとにグルーピングしてバッチ処理 同じファイルを複数エージェントで読み直さなくて良いため トークン節約になる 構造化出力 エージェントの出力をJSON Schema Validに強制できる エージェントが増えるとブレが出やすいので安定性に寄与 ※dynamic workflows特有の機能ではない 11
12. スクリプトで直接書ける強み グルーピングしたり、プロンプトで変数を展開したりする処理をスクリプトで直接書ける 可読性は正直良くないですが const batchByFile = new Map() for (const f of toVerify) { const key = f.file || '(no-file)' if (!batchByFile.has(key)) batchByFile.set(key, []) batchByFile.get(key).push(f) } const verifyBatches = [...batchByFile.values()].map((findings) => ({ findings, hasCritical: findings.some((f) => f.severity === 'critical'), })) function verifyPrompt(batch) { const file = batch.findings[0].file || '(ファイル不明)' return ( '次のコードレビュー指摘（同一ファイル ' + file + ' に対する ' + batch.findings.length + '件）が' + 'それぞれ偽陽性でないか検証してください。\n\n' + 'リポジトリ(worktree, 変更適用後): ' + workspace + '\n' + '差分ファイル（文脈が必要なら Read）: ' + diffPath + '\n' + (priorFindingsPath ? '過去レビューの検証結果ダイジェスト: ' + priorFindingsPath + '（同一の指摘が過去に refuted/confirmed 済みなら、その根拠が現在のコードでも成立するかを実コードで確認して判定に用いる。過去の判定を無検証で踏襲しない）\n' : '') + '蒸留済みの偽陽性抑制ルール: ' + workspace + '/.claude/rules/review*.md が存在すれば Read し、' + '「偽陽性抑制」セクションに合致する指摘は、その前提が実コードで成立していることを確認したうえで isReal=false の根拠にしてよい。\n' + '\n' + '指摘リスト(JSON。_verifyId が各指摘の識別子):\n```json\n' + JSON.stringify(batch.findings) + '\n```\n\n' + '各指摘を1件ずつ独立に実コードを根拠に判定し、指摘ごとに verdicts の1要素を返すこと' + '（verifyId には _verifyId をそのまま入れる。同一ファイルの指摘同士でも判定を引きずらない）。\n' + '不確実時の方針: 指摘の前提が実コードと食い違うと確認できた場合のみ isReal=false。' + '指摘が成立する場合、または確証が持てない場合は isReal=true とし、reasoning に不確実性を明記する（人間への報告のため取りこぼし防止を優先）。' ) } 12
13. 改善メタループ 指摘を次の実行が良くなるルールに変えて戻す仕組み
14. 記録 → 蒸留 → 適用 → 次の実行 記録: ワークフローのRecordフェーズ 蒸留: 溜まったログを分析し、ルール候補を出 す 適用: 候補の採否を人間が決め、ルールファイ ルに書く 14
15. 蒸留と適用 蒸留（ワークフロー） 溜まった指摘と検証結果を分析してルール候補を出す 長く使えるルールにするため、複数観点で多段推敲（ワークフロー向き） 候補の提示のみが責務、適用はしない 適用（スキル） 蒸留で生まれた候補を提示し、適用・却下・保留を人間が決める（ワークフローには不向き） 提案自体は概ね筋が通っているがそのまま適用するとチームへの影響が大きかったり、 より本質的な解決策のほうが良さそうに思えることが多いため、人間の判断を挟んでいる すぐ適用できるルールに変換する場というより、課題を深堀りするきっかけを得る場に近い 15
16. faceted promptingで関心ごとを分離する 得られた知見をどこに書くか
17. フィードバックの適用先 faceted promptingという考え方（AIプロンプトにおける関心の分離） 関心 答える問い 例 Persona 誰として判断するか？ 役割定義、専門性 Policy 何を守るか？ 禁止事項、品質基準、優先順位 Instruction 何をするか？ 目標、ステップ固有の手順 Knowledge 何を参照するか？ 前提知識、ドメイン資料、API仕様 Output Contract どう出すか？ 出力構造、レポートテンプレート 参考: https://nrslib.com/faceted-prompting/ 17
18. 私のfacet実装 Instruction/Output Contractはワークフロー の定義で持つ Persona/Policy/Knowledgeは faceted-promptingで管理 画面用、API用、共通観点など定義しており、 それぞれを組み合わせて カスタムエージェントとして生成 18
19. テンプレートにfacetを差し込む --name: xxx-admin-coder description: >xxx admin (Next.js/Material-UI/NextAuth) の管理画面実装担当 subagent。 useFetcher+BFF・Custom コンポーネント・usePageRole 権限制御等の xxx 固有規約に従い、詳細はリポジトリのコードを Read して実装する。 tools: Read, Grep, Glob, Bash, Write, Edit, WebFetch, Skill skills: - jest-test --{{facet:persona}} {{facet:policies}} # xxx ナレッジ {{facet:knowledges}} このテンプレートにfacetが埋め込まれたカスタムエージェントが生成される 19
20. 得られた知見を適切な関心事に適用していくことで再利用性を高める 20 例えば 繰り返される指摘事項 -> Policyを追加 別々のエージェントが同じような指摘ばかりを出す -> Personaを調整 実行時間が長過ぎる -> workflowの組み換え、effortの調整 一番効きそうな場所に適用する
21. まとめ dynamic workflowsは大規模なワークフローを確実に繰り返し実行させるための仕組み 記録することで次の改善に繋がる faceted promptingで関心を分離して適切な領域にフィードバックする ただ繰り返すのではなく、より ダイナミック に進化させていこう 21