以下の内容はhttps://techblog.zozo.com/entry/ai-driven-dev-with-claude-and-devinより取得しました。

Claude × Devinで実現するAI駆動開発ワークフロー

AI GitHub Actions CI/CD 自動化

Claude × Devinで実現するAI駆動開発ワークフロー

目次

はじめに

こんにちは、新規事業部 マネジメントポータルブロックの岡本です。

「PRを作ったけど、レビューまで時間がかかる」「忙しいときレビューが後回しになる」──この悩み、開発者なら誰もが経験したことがあるのではないでしょうか。

私たちのチームでは、ClaudeとDevinを組み合わせたAI駆動開発ワークフローを導入し、レビュー待ち時間ゼロ・CIエラーの自動修正・Issueからの即時の実装開始を実現しました。この記事では、その設計思想から実装詳細、導入効果までを解説します。

この記事の対象読者

  • GitHub Actionsを使ったCI/CDの経験がある方
  • AIコーディングアシスタント（Claude、Devinなど）に興味がある方
  • チーム開発の効率化を検討している開発リーダー・マネージャー

背景・課題

背景

私たちのチームはZOZOマッチ管理画面を少人数で運用しており、各メンバーがフロントエンド・バックエンド・LP作成と複数の領域を担当しています。そのため、コンテキストスイッチが頻繁に発生し、「PRを作成したが、レビュアーが別タスクに集中している」「CIエラーを修正しようとしたら、他の緊急対応が入った」といった状況が日常的に起きていました。

結果として、レビューやCI修正の待ち時間が発生しやすく、開発のリズムが途切れがちでした。そこで、「人間は創造的な作業に集中し、定型的な作業はAIに任せる」という方針のもと、Claude（レビュー・判断）とDevin（実装・修正）を組み合わせたワークフローを整備しました。

課題

従来の開発フローでは、次のような課題がありました。

課題 詳細
レビュー待ち時間 PR作成から人間のレビューまでに数時間〜1日かかることがあった
レビュー品質のばらつき レビュアーの経験や専門分野によって指摘内容に差があった
Issue着手の遅延 Issueが起票されてから実装開始まで時間がかかっていた
ライブラリ更新の負担 Renovateが作成する大量の依存関係の更新PRのレビュー・マージ作業が開発者の負担になっていた

これらの課題を解決するため、2つのGitHub Actionsワークフローを中心に自動化を構築しました。

AI駆動開発ワークフローの概要

AIサービスごとの役割

このワークフローでは、2つのAIサービスを組み合わせて活用しています。GitHub Actionsとの連携における実行方式の違いから、次のように役割を分けています。

  • Devin（実装・修正）：Issueの実装、CIエラー修正、レビュー指摘の修正を担当。非同期でセッションを開始し、修正完了まで一貫した作業が可能。ブランチ操作からコミット・プッシュまでを単一セッションで実行でき、修正完了後にPRが更新されてワークフローが再トリガーされる設計とも相性が良い
  • Claude Code（レビュー・判断）：PRのレビュー、分類判定、自動承認の判断を担当。同期的に結果を返すため、「自動承認 / 人間レビュー依頼 / Devin修正起動」の分岐処理を同一ワークフロー内で完結できる。構造化出力（JSONスキーマ）により、後続の処理時に扱いやすい形式でレビュー結果を取得できる

Devin Playbook

Playbookは、Devinに対する再利用可能な指示セットです。タスクの種類に応じた判断ロジック（セキュリティチェック、タスクサイズ判定など）、GitHub連携処理、エラーハンドリングが定義されており、一貫した品質でタスクを実行できます。

Playbookには、Slackからユーザーが起動するものと、GitHub Actionsワークフローが自動呼び出しするものの2種類があります。今回作成したワークフローでは、Devin APIを使用し、macro形式（macro IDとpayloadをJSONで渡す）でPlaybookを呼び出しています。

ユーザー起動のPlaybook（Slack → Devin）

Slackで@devinをメンションし、!で始まるコマンドを送信すると、対応するPlaybookが実行されます。

コマンド 用途 対象タスク
!ai_task 単一タスク実装 Small〜Medium（半日以内）
!ai_tasks タスク分割＆並列実装 Large（1日以上、複数コンポーネント）
!human_review 人間承認フロー セキュリティ関連、要確認タスク
!ai_task（単一タスク実装）

指定されたタスクを直接実装し、PRを作成します。

!ai_task playbookフロー

!ai_tasks（タスク分割＆並列実装）

複雑なタスクを分析し、最大5つのsub-issueに分割して並列実装します。

!ai_tasks playbookフロー

!human_review（人間承認フロー）

セキュリティ関連や重要な変更など、人間の確認が必要なタスク向けです。

!human_review playbookフロー

人間レビューが必要なケース
  • 認証・認可の変更
  • 個人情報（PII）の扱い
  • シークレット・APIキーの変更
  • ビジネスロジックの大幅な変更
  • 本番環境への影響が大きい変更

ワークフロー自動呼び出しのPlaybook

次のPlaybookはGitHub Actionsワークフローから自動的に呼び出されます。ユーザーが直接実行することはありません。

Playbook 用途 呼び出し元
!fix_ci_failure CI失敗時の自動修正 ai-review-orchestrator.yml（CI失敗時）
!fix_review_comments レビュー指摘の自動修正 ai-review-orchestrator.yml（blockingの指摘があるとき）
!context_curation AIコンテキストの週次更新 devin-context-refresh.yml（毎週月曜09:00 JST）
!fix_ci_failure（CI失敗時の自動修正）

CI（Lint、Typecheck、Test）が失敗したPRを自動修正します。

  • GitHub ActionsのCIログを解析してエラーを特定
  • エラー種別に応じて修正（Lint → pnpm run lint:fix、Type → 型エラー修正、Test → テスト更新）
  • 修正をコミット・プッシュしてセッション終了
  • ビジネスロジックの変更が必要な場合は修正せず人間にエスカレーション
!fix_review_comments（レビュー指摘の自動修正）

Claude Reviewからの指摘（blocking: true）を自動修正します。

  • Blocker / Major の指摘を必須の修正対象として処理
  • 各指摘の suggestion に従って修正
  • 修正をコミット・プッシュしてセッション終了
  • 認証・認可に関わる変更は修正せず人間にエスカレーション
!context_curation（AIコンテキストの週次更新）

PRコメントから学習可能な知見を抽出し、AI関連ドキュメントを週次で自動更新します。

  • 直近7日間のPRコメント（Bot除外）を収集
  • コメントから有用な変更点、落とし穴、ルール例外、命名・設計ガイドラインを抽出
  • AGENTS.md、docs/ai-context/、docs/guidelines/、docs/review-perspectives/ を更新
  • 更新内容をPRとして作成（人間がレビュー・マージ）

使用技術

ワークフローは、次の技術・サービスを組み合わせて構成しています（ワークフロー上の使用順）。

技術・サービス 用途
Slack タスク起点のオペレーション（Devinへの指示）
GitHub Issues/PR/Labels 進行管理とトリガー
Devin API Issueの実装・CIエラー修正・レビュー指摘の修正
GitHub Actions ワークフロー実行（CI待機、ジョブ分岐、通知）
AWS Bedrock Claude実行基盤（セキュリティ要件対応）
Claude Code Action PRレビュー実行・分類判定・自動承認

機能一覧

機能 内容 主な効果
AI Task Implementation Slack/ラベル起点で Devinが実装しPRを作成 Issue着手の即時化
AI Review Orchestrator Claudeがレビューし、Devinが修正 レビュー待ちの解消と品質の均一化
CI自動修正 CI失敗時にDevinが修正を実行（最大3回） 手戻り削減
自動承認 AI_ONLYかつ指摘なしで自動承認 PR処理の高速化
週次メトリクス KPIを週次で自動計測しIssue化 効果測定の継続
ナレッジ更新 PRコメントからドキュメントを自動更新 レビュー品質の継続改善

アーキテクチャ

SlackからPR承認までの完全フロー

SlackからPR承認までの完全フロー

2つのワークフローの役割

ワークフロー トリガー 役割
AI Task Implementation Issueにai-task / ai-tasksラベル追加 DevinがIssueの実装を担当し、PRを作成
AI Review Orchestrator PRの作成・更新 Claudeがレビュー、Devinが修正、条件を満たせば自動承認

フロー別の使い分け

各Playbookの詳細なフローは「Devin Playbook」セクションを参照してください。

シナリオ Slack コマンド 処理フロー
単一タスク（直接の実装が可能） @devin !ai_task タスク説明 Devin → Issue + PR → 自動レビュー → 承認
複雑なタスク（分割が必要） @devin !ai_tasks タスク説明 Devin → 親 Issue + sub-issue → 並列実装 → 自動レビュー
要承認タスク @devin !human_review タスク説明 Devin → Issue 作成 → 人間承認 → 自動実装
Claudeに質問・修正依頼 @znm-claude-code 依頼内容 Claudeが対応（PR/Issueコメント）

実装

設定ファイル

ワークフローはGitHub Actionsの設定ファイルで定義しています。主要ファイルと役割は次のとおりです。

ファイル 役割
.github/workflows/ai-task-dispatcher.yml Issueラベル検知・条件判定のゲートウェイ（条件を満たす場合のみimplementationを起動）
.github/workflows/ai-task-implementation.yml DevinによるIssue実装（dispatcher から呼び出し）
.github/workflows/ai-review-orchestrator.yml PRレビュー・修正ループ・Renovate統合
.github/workflows/pr-perspective-router.yml Perspectiveラベルの再分類
.github/workflows/ai-renovate-review.yml Renovate PRの依存関係レビュー（orchestrator から呼び出し）
.github/workflows/ai-metrics-report.yml 週次メトリクス生成
.github/workflows/devin-context-refresh.yml コンテキスト更新

AI Task Implementation：Issueから実装までの自動化

AI Task Dispatcher（ゲートウェイ）

ai-task-dispatcher.yml は、Issueのラベル追加を検知し、条件を満たす場合のみ実装ワークフローを起動するゲートウェイです。

AI Task Dispatcherの役割

Dispatcherを分離している理由は3つあります。

  • 条件判定の一元化：ラベル検知と条件チェックを単一ファイルに集約し、保守性を向上
  • 不要なワークフロー発火の防止：条件を満たさない場合は早期終了し、リソースを節約
  • 責務の分離：「いつ起動するか」（dispatcher）と「何をするか」（implementation）を明確に分離

実装ワークフローの動作

ai-taskまたはai-tasksラベルがIssueに追加されると、dispatcher経由でDevinが自動的に実装を開始します。トリガー条件は次のとおりです。

  • Issueのlabeledイベントで起動（dispatcherが検知）
  • ai-task / ai-tasksラベル付与時のみ対象
  • in-progressが付いていない場合だけ開始

起点は2パターンあります。

  • Playbook起動（Slackなど）：PlaybookがIssueを作成 → ai-task / ai-tasksを付与 → このワークフローが起動
  • 既存Issue起点：このワークフローがskip_issue_creation: trueを渡してPlaybookを実行（Issue作成はスキップ）

ラベルによる動作の分岐

ラベルに応じて対応するPlaybookが実行されます。各Playbookの詳細なフロー（セキュリティチェック、タスクサイズ判定、実装手順など）は「Devin Playbook」セクションを参照してください。

ラベル Playbook 動作
ai-task !ai_task 単一タスクとして実装
ai-tasks !ai_tasks タスク分割 → 並列実装

sub-issue作成にはgh sub-issue拡張が必要です（Playbook側 or Devinのリポジトリ初期設定で事前インストール）。

重複実行の防止の仕組み

同じIssueに対する重複実行を防ぐため、concurrency設定でIssue番号単位の同時実行を1つに制御し、進行中の実行があれば新しい実行でキャンセルします。

例えば、同じIssueに短時間でラベル追加が続いた場合、labeledイベントが複数回発火します。この二重起動を防止します。

キャンセル時のクリーンアップ

ワークフローがキャンセルされた場合、次のクリーンアップ処理を実行します。

  • キャンセル時にDevinセッションを停止
  • キャンセル時にin-progressラベルを削除して再実行可能にする
  • 失敗時もin-progressラベルを削除して再実行可能にする

AI Review Orchestrator：レビューから承認までの自動化

レビュー・ワークフローの動作

PRが作成・更新されると、ai-review-orchestrator.ymlが自動実行されます。このワークフローはPRの作成・更新をトリガーに発火し、PRの作成元は問いません。

  • AI Task Implementation経由のPR: DevinがPR作成 → このワークフローが発火
  • 手動作成されたPR: 開発者の直接PR作成 → このワークフローが発火

なお、ai-task-dispatcher.ymlとこのワークフローは独立しており、直接の呼び出し関係はありません。

統合レビュー・修正ループの詳細フロー

Claude + Devin統合レビュー・修正ループ

ジョブ構成と責務

ai-review-orchestrator.ymlは約1,500行の大規模ワークフローです。6つのフェーズに分かれています。

フェーズ ジョブ名 責務 依存関係
1 gate スキップ判定、PR情報取得、イテレーション管理 なし
2 perspective-router PR分類、perspective:* ラベル付与（初回のみ、Renovate以外） gate
3 wait-for-ci CI完了待機（最大20分、30秒間隔ポーリング） gate, perspective-router
4a devin-ci-fix CI失敗時のDevin自動修正 gate, wait-for-ci (CI失敗時)
4b-1 renovate-review Renovate PR専用のClaude依存関係レビュー（ai-renovate-review.yml呼び出し） gate, wait-for-ci (CI成功かつRenovate PR時)
4b-2 claude-review CI成功/未検出時のClaudeレビュー実行（Renovate以外） gate, wait-for-ci (CI成功/未検出時)
4c devin-review-fix レビュー指摘ありの場合のDevin自動修正 gate, claude-review (指摘あり時)
4d auto-approve AI_ONLY + 指摘なしの場合の自動承認 gate, claude-review or renovate-review
4e needs-human-review NEEDS_HUMAN + 指摘なしの場合の人間レビュー依頼 gate, claude-review or renovate-review
4f vrt Visual Regression Testingの実行 auto-approve or needs-human-review
5 max-iterations-reached イテレーション上限到達時の通知 gate
6 ci-timeout CI待機タイムアウト時の通知 gate, wait-for-ci

Phase 1: Gate（スキップ判定）

次の条件でワークフローをスキップします。

条件 判定方法 理由
Draft PR pull_request.draft == true 作業中のためレビュー不要
Bot作成PR（Devin・Renovate 以外） actorがbotかつDevin・Renovateでない 無限ループ防止
Fork PR pull_request.head.repo.fork == true シークレット/権限制約のためスキップ
skip-ai-reviewラベル ラベル存在チェック 明示的スキップ
Renovate PR actorがrenovate[bot] Renovate専用レビュー（renovate-review）へルーティング
ai-auto-approvedラベル ラベル存在チェック 既に承認済み

また、新しいpushがあった場合はAI関連ラベルを削除し、承認を取り消して再レビューします。ラベルの削除ルールはpush元によって異なります。

  • 人間のpush：ai-auto-approved / needs-human-review / perspective:*を削除して再分類
  • Botのpush：ai-auto-approved / needs-human-reviewのみ削除して分類は維持

Phase 2: Perspective Router（ハイブリッド分類方式）

PRの変更内容を分析し、適切なレビュー観点を決定します。キーワードベースの事前分類 + Claudeフォールバックのハイブリッド方式を採用しています。

分類フロー

Perspective Router

事前分類ルール
ラベル パスパターン キーワード
perspective:workflow .github/workflows/, .github/actions/, action.yml workflow, ci, cd, pipeline, jobs, steps, runs-on
perspective:security auth/, login/, session/ auth, token, secret, credential, password, encrypt, sanitize, xss, csrf, pii, vulnerability
perspective:quality *.test.*, *.spec.*, __tests__/, eslint, prettier, tsconfig test, spec, lint, format, accessibility, a11y, aria-, vitest, jest
perspective:dependency package.json, pnpm-lock.yaml, yarn.lock, package-lock.json dependency, package, version, upgrade, license
perspective:api /api/, openapi, swagger, schema, .dto. api, endpoint, schema, openapi, graphql, rest
perspective:perf （パスパターンなし） performance, optimize, cache, lazy, memo, bundle, split, prefetch
perspective:business domain/, business/ permission, role, billing, payment, validation, status, transition, rule
perspective:general 上記に該当しない場合のみ -

複数パターンにマッチした場合、該当ラベルがすべて付与されます。perspective:generalは他のラベルと併用されません。

Phase 3: CI完了待機

他のCIジョブ（型チェック、lint、テストなど）の完了を待機します。待機の仕組みは次のとおりです。

  • 自分自身のワークフローやVRTは待機対象から除外
  • 部分一致の除外パターンも併用して精度を上げる
  • 最大20分、30秒間隔でポーリング

CI Runが一定時間見つからない場合（約5分）はci_status=skippedとしてClaudeレビューへ進みます。success / neutral / skippedは成功扱いです。

CI完了を待つ理由
  • CIが失敗している状態でレビューしても意味がない
  • CI失敗 → Devin修正 → またCI失敗 → またレビュー... という無駄なループを防ぐ
  • CIが通った状態のコードに対してレビューすることで、品質の高いフィードバックが可能

Phase 4: Claude Review

Claude Code Actionを使用して、PRを包括的にレビューします。

Perspectiveラベルに基づくレビュー

Claude Reviewでは、Phase 2で付与されたperspective:*ラベルに応じて、対応するレビュー観点ドキュメントを動的に読み込みます。

ラベル 対応ファイル 主なレビュー観点
perspective:workflow docs/review-perspectives/workflow.md GitHub Actions/CI/CD の設計・セキュリティ
perspective:security docs/review-perspectives/security.md 認証・認可・入力検証・機密情報の管理
perspective:quality docs/review-perspectives/quality.md テスト・Lint・アクセシビリティ
perspective:dependency docs/review-perspectives/dependency.md 依存関係の追加・更新・削除
perspective:api docs/review-perspectives/api.md API設計・スキーマ・エラーハンドリング
perspective:perf docs/review-perspectives/perf.md パフォーマンス・キャッシュ・最適化
perspective:business docs/review-perspectives/business.md ビジネスロジック・権限・バリデーション
perspective:general docs/review-perspectives/general.md 汎用的なコード品質（他に該当しない場合）

レビュー実行時の読み込みフローは次のとおりです。

  1. PRからperspective:*ラベル一覧を取得
  2. 対応するdocs/review-perspectives/*.mdを読み込み
  3. 取得内容をプロンプトに差し込みレビュー実行

たとえば、セキュリティ関連のPRにはsecurity.mdの観点が、API関連のPRにはapi.mdの観点が適用されるといった具合です。

レビュープロンプトの構造

レビュープロンプトは次のルールで構成されます。

  • Bedrock経由でClaudeを実行
  • Perspective指定と重大度定義をプロンプトに含める
  • Blocker/Majorをblocking: trueとして扱う
分類判定ルール
判定 条件 自動承認
AI_ONLY テストコード、型定義、明確なバグ修正、リファクタリング 可能
NEEDS_HUMAN ドキュメント、スタイル、設定ファイル、セキュリティ関連 不可
自動承認の対象外となる変更タイプ

次の変更は必ず人間のレビューが必要です（NEEDS_HUMANと判定）。

  • ドキュメント更新：README.md, *.mdファイル、docs/配下の変更
  • スタイル調整：CSS, Tailwindクラス、デザイン・レイアウト変更
  • 設定ファイル変更：tsconfig, eslint, prettier, vite.config等
指摘の重大度とblockingフラグ（Conventional Comments準拠）
重大度 blocking 意味 修正要否
[Blocker] true 必ず修正が必要 必須
[Major] true 強く推奨される修正 必須
[Minor] false 推奨される改善 任意
[Nit] false 微細な指摘（スタイル等） 任意
[Question] false 仕様・意図の確認質問 回答必須（修正不要）
[Praise] false 良いコードへの称賛 対応不要

blocking: trueの指摘が1件以上あると、Devin自動修正が実行されます。

PR説明文の自動生成・更新

Claude Reviewでは、レビュー結果と同時にPR説明文を自動生成・更新する機能があります。

関連 Issue の自動取得

PR本文からclosing keywords（Closes #123, Fixes #456など）を自動的に抽出し、関連Issueを特定します。抽出されたIssue番号はレビュープロンプトに含まれ、Claudeが変更の意図を理解する際のコンテキストとして活用されます。

PRタイトル・説明文の自動生成

ClaudeはPR内の全てのコミットと変更ファイルを分析し、次の手順でタイトルと説明文を自動生成します。

  1. PR内の全コミット一覧を取得（最大50件）
  2. 全ての変更ファイルを分析
  3. PR全体を代表するタイトルを日本語で生成（Conventional Commits形式）
  4. .github/PULL_REQUEST_TEMPLATE.mdに沿って説明文を生成
タイトル生成ルール
  • 形式： {prefix}: {変更内容の要約}（例：feat: ユーザー認証機能の追加）
  • prefix：feat / fix / docs / refactor / chore / testから変更種別に応じて選択
  • 50文字以内で簡潔に日本語で記載
  • 複数の変更がある場合は、主要な変更を代表するタイトルに

生成されたタイトルと説明文は、レビュー完了後に自動的にPRへ反映されます（それぞれ生成された場合のみ更新）。PR作成者がタイトルや説明文を適切に書けなかった場合でも、Claudeが内容を自動生成してくれます。最新のコミットだけでなくPRに含まれる全てのコミットを考慮するため、複数回のpushがあっても正確な内容が生成されます。

Phase 5: Devin自動修正

Claudeのレビューで指摘があった場合、またはCIが失敗した場合、Devinが自動修正します。

Devin修正の種類
ジョブ名 用途 参照 Playbook
devin-ci-fix CI失敗の修正（CIログを解析して自動修正） fix-ci-failure.devin.md
devin-review-fix レビュー指摘の修正（Claudeの指摘に基づいて自動修正） fix-review-comments.devin.md

Devinへの修正指示は次の手順で行います。blocking: trueの指摘だけを抽出し、抽出結果をmacro payloadに組み込んでDevinに送信します。

修正ループの詳細

ループカウントの管理

イテレーションはCI修正 + レビュー修正の合計回数でカウントします。

Push種別 カウント動作 理由
人間がPR作成 0からスタート 新規PR
Devinがpush カウント継続 自動修正ループ中
人間が修正push 0にリセット 人間の修正後は新規扱い

上限（3回）に達した後でも、人間が修正してpushすればカウントがリセットされ、レビューが再開されます。

Perspectiveラベルの更新ルール
Push種別 Perspective Router ラベル動作
人間がPR作成 ✅ 実行 新規ラベル付与
Devinがpush ❌ スキップ 既存ラベル維持
人間が修正push ✅ 実行 既存ラベル削除 → 再分類
ループ終了条件
  1. 正常終了：CI成功 + レビュー指摘なし → 自動承認
  2. 上限到達：iteration_count >= MAX_ITERATIONS → 人間レビュー依頼
  3. タイムアウト：CI待機が20分超過 → 人間への確認依頼

自動承認の条件

次のすべてを満たした場合のみ自動承認されます。

  1. CI成功
  2. Claudeレビュー完了
  3. 分類がAI_ONLY
  4. blockingな指摘がない
  5. HEAD SHAが変更されていない（レース条件対策）

データ連携方式

Claude → Devinのデータ渡し

Claudeのレビュー結果をDevinに渡す方式は、ジョブ出力による直接連携を採用しています。

データフロー

構造化出力スキーマ

Claudeに--json-schemaオプションでレビュー結果の構造を指定し、次の項目を必須にしています。

  • classification（AI_ONLY / NEEDS_HUMAN）
  • Blocker/Major/Minorの件数フラグとカウント
  • fix_instructions（修正指示文）
  • issues（指摘一覧：severity / blocking / file / messageなど）

技術的なポイント

1. concurrencyによる並行実行の制御

  • 同一PRに対して1つのワークフローのみ実行（groupで制御）
  • cancel-in-progress: trueのため、Devinが修正をpushした場合：
    1. 新しいワークフローが開始される
    2. 古いワークフローは自動的にキャンセルされる
    3. Devinセッションはtrapハンドラーにより自動停止される
    4. 新しいワークフローはCI完了を待機してからレビュー

2. Devinセッションの自動停止

ワークフローがキャンセルされた際、実行中のDevinセッションを確実に停止するため、二重のセーフティネットを実装しています。

trapハンドラー（即時対応）

Devin API呼び出し中にシグナル（SIGINT/SIGTERM）を受信した場合、trapハンドラーが即座にセッションを停止します。SIGINT/SIGTERMを受けると即座にcleanupを実行し、/tmp/devin_resp.jsonからsession_idを取得して10秒以内にセッションを終了します。

if: cancelled()バックアップステップ

API呼び出しが完了してからキャンセルされた場合に備えて、専用のクリーンアップステップを用意しています。outputsまたは/tmp/devin_resp.jsonからsession_idを取得してセッションを停止します。

GitHub Actionsのキャンセルシーケンス

GitHub Actionsはキャンセル時に次の順序でシグナルを送信します。

  1. SIGINT送信 → 7.5秒待機
  2. SIGTERM送信 → 2.5秒待機
  3. 強制終了

trapハンドラーは最初のSIGINTでcleanupを実行するため、最大10秒の猶予内でDevinセッションを停止できます。

3. AWS BedrockによるClaude呼び出し

セキュリティ要件を満たすため、Claude APIではなくAWS Bedrock経由でClaudeを呼び出しています。AWS認証情報を設定し、Claude Code Actionのuse_bedrockを有効化しています。

設定項目 値
リージョン us-east-1
IAMロール <your-bedrock-access-role>
モデル（レビュー） Claude（Bedrock Application Inference Profile）
モデル（分類） Claude Haiku（anthropic.claude-3-haiku-20240307-v1:0）

4. マクロ形式によるプロンプト管理

Devinへの指示は、macro IDとpayloadをJSONとして渡すマクロ形式で標準化しています。Playbookのmacro IDと一対一で対応しており、一貫性のある指示が可能です。

5. HEAD SHAの検証

レース条件を防ぐため、承認前にHEAD SHAが変更されていないことを確認しています。実行開始時のHEAD SHAと現在のSHAを比較し、一致しない場合は自動承認をスキップします。

使い方

AI Task Implementationの使い方（Slack → Issue → 実装）

SlackからDevinにタスクを依頼すると、Issue作成から実装、PR作成までを自動で行います。各Playbookの詳細なフローは「Devin Playbook」セクションを参照してください。

起動方法

方法 手順 動作
Slackから（推奨） @devin !ai_taskタスク説明 DevinがIssue作成 → ai-task ラベル付与 → ai-task-dispatcher.yml発火 → 実装開始
Slackから（複雑なタスク） @devin !ai_tasksタスク説明 Devinが親Issue作成 → sub-issueに分割 → 並列実装
GitHub Issueから Issue にai-task / ai-tasksラベルを付与 ai-task-dispatcher.yml発火 → 実装開始

注意点

  • in-progressラベルがあるIssueはスキップされます（実装中のため）
  • セキュリティ関連を検出した場合、!human_reviewへの切り替えを案内してセッション終了
  • タスクサイズが合わない場合、適切なPlaybookへの切り替えを案内してセッション終了

AI Review Orchestratorの使い方（PR → レビュー → 承認）

PRが作成・更新されると、ai-review-orchestrator.ymlが自動起動し、Claudeがレビューします。

自動レビューの流れ

  1. CI完了待機（最大20分）
  2. Perspective分類（初回のみ、変更内容に応じてラベル付与）
  3. Claudeレビュー（Perspectiveに基づく観点でレビュー）
  4. 結果に応じた分岐：
    • 指摘あり → Devin自動修正（最大3回）
    • AI_ONLY + 指摘なし → 自動承認
    • NEEDS_HUMAN → 人間レビュー依頼

Claudeへの質問・修正依頼

PRやIssueに対してClaudeに質問や修正依頼をしたい場合は、@znm-claude-codeをメンションしてコメントします。

操作手順まとめ

  1. 入口を選ぶ。@devin !ai_task（単一タスク）/@devin !ai_tasks（分割タスク）/@devin !human_review（人間の承認が前提）。Slackを使わない場合はIssueにラベルを付与する
  2. DevinがIssue/PRを作成し、ai-review-orchestrator.ymlが自動起動する
  3. CI完了後にClaudeがレビューし、指摘があればDevinが修正する（最大3回）
  4. AI_ONLYかつ指摘なしなら自動承認、NEEDS_HUMANは人間レビューへ。Claudeへの質問や修正依頼は@znm-claude-codeを利用する

運用上の例外（skip-ai-review / renovateなど）は「運用上の注意点」を参照してください。

導入効果

定量的な効果

指標 導入前 導入後
PR作成からレビュー開始まで 平均4時間 即時
CIエラー修正時間 平均30分/回 自動
単純なIssueの実装開始 平均1日 即時
RenovatePRの処理 手動確認・マージ 依存関係レビュー後に自動承認

定性的な効果

  1. 開発者が集中する時間の確保

    • 定型的なエラー修正から解放され、創造的な作業に集中できるようになった

  2. レビュー品質の均一化

    • Perspectiveに基づくレビューで、一貫した品質のレビューが実現した
    • レビュアーの経験や専門分野に依存しない指摘が可能になった

  3. 心理的安全性の向上

    • AIが最初にレビューすることで、人間のレビューでの「些細な指摘」が減った
    • レビュアーは本質的な議論へ集中できるようになった

  4. ナレッジの蓄積

    • レビュー観点ドキュメント（docs/review-perspectives/）が知識ベースとして機能
    • 新しいメンバーのオンボーディングにも活用できる

  5. ライブラリ更新の自動化

    • Renovateが作成する依存関係の更新PRをClaudeがレビュー
    • AI_ONLYかつ指摘なしなら自動承認
    • セキュリティパッチの迅速な適用に貢献

Renovate PRの自動レビュー・承認

Renovateが作成した依存関係の更新PRは、専用ワークフロー（ai-renovate-review.yml）で自動処理されます。

Renovate PRの自動レビュー・承認フロー

自動承認の条件

  • patch / minorの安全な更新のみ
  • 破壊的変更なし
  • Blocker / Major指摘が0件

AI開発の効果測定（週次レポート）

ai-metrics-report.yml により、AI駆動開発の効果を週次で自動計測し、GitHub Issueとして報告します。

計測される KPI

指標 目標 説明
AI_ONLYレビュー通過率 60％以上 AIのみで承認可能と判定されたPRの割合
自動承認率 - 実際に自動承認されたPRの割合
Devinの修正成功率 70％以上 Devinが修正を試みたPRのうち、マージに至った割合
イテレーション上限到達率 10％以下 修正ループが上限（3回）に達したPRの割合
平均イテレーション回数 1.5回以下 PRあたりの平均の修正回数
CI失敗率 20％以下 CI失敗が発生したPRの割合

レポート例

## AI 開発効果測定 週次レポート

**集計期間**: 2025-12-15 ~ 2025-12-22
**対象 PR 数**: 25 件

### 📊 主要指標（KPI）

| 指標 | 実績 | 目標 | 状態 |
|------|------|------|------|
| AI_ONLY レビュー通過率 | 72.0% | 60% 以上 | ✅ |
| 自動承認率 | 68.0% | - | - |
| Devin 自動修正成功率 | 85.7% | 70% 以上 | ✅ |
| イテレーション上限到達率 | 4.0% | 10% 以下 | ✅ |
| 平均イテレーション回数 | 1.2 回 | 1.5 回以下 | ✅ |
| CI 失敗率 | 16.0% | 20% 以下 | ✅ |

🎉 すべての主要指標が目標を達成しています！

このレポートは毎週月曜10:00 JSTに自動生成され、ai-metricsラベル付きのIssueとして作成されます。

AIコンテキストの自動育成

devin-context-refresh.ymlにより、PRコメントからのフィードバックを元にAIコンテキストドキュメントを週次で自動更新します。

動作フロー

AIコンテキストの自動育成

更新対象ファイル

カテゴリ ファイル
ルート AGENTS.md
docs/ai-context/ coding-standards.md, context.md, data-model.md, design-template.md, glossary.md, implementation-patterns.md, metrics.md, pr_review_classification.md, pr_review_comment_rules.md, role.md, task-assignment.md
docs/guidelines/ architecture.md, environment-variables.md, error-handling.md, naming-conventions.md, validation.md
docs/review-perspectives/ api.md, business.md, dependency.md, general.md, perf.md, quality.md, security.md, workflow.md
ドキュメントの階層構造

AIエージェントがコンテキストを読み込む際、次の階層構造で参照が行われます。

ドキュメントの階層構造

  • CLAUDE.md：Claude Codeが最初に読み込むファイル。@AGENTS.mdでメインガイドを参照
  • AGENTS.md：AIエージェント向けメインガイド。最重要ルール（3-5個）と各ドキュメントへのパス参照を記載（300行未満を推奨）
  • docs/：詳細情報は各サブディレクトリに委譲し、AGENTS.mdからパス参照のみ記載

この構造によってコンテキストの段階的読み込みが可能になり、トークン消費を抑えつつ必要な情報にアクセスできます。

各ディレクトリの役割
ディレクトリ 役割 使用タイミング
CLAUDE.md Claude Codeのエントリーポイント。@AGENTS.mdでAGENTS.mdを参照 Claude Code起動時に自動読み込み
AGENTS.md AIエージェント向けメインガイド。最重要ルール（3-5個）と各ドキュメントへの参照を記載 Devinがセッション開始時に読み込む
docs/ai-context/ コーディング規約、実装パターン、用語集、データモデルなどのコンテキスト情報 Playbook内で参照先として指定。週次更新でPRコメントから学んだ知見を蓄積
docs/guidelines/ アーキテクチャ設計、エラーハンドリング、バリデーションなどの詳細な技術ガイドライン Playbook内で参照先として指定。週次更新で継続的に改善
docs/review-perspectives/ perspective:* ラベルに対応したレビュー観点ドキュメント Claude ReviewがPRのPerspectiveに応じて動的に読み込み（詳細）

PRレビューで蓄積されたナレッジが自動的にドキュメントに反映されるため、Claudeのレビュー品質も継続的に向上していきます。

残っている課題

  • AIでも対応が難しいドメイン固有の判断があり、最終的に人間の合意が必要になるケースが残る
  • ワークフローが複雑になり、運用ルールの理解・周知コストが発生している
  • AIによる正しい指摘でも、チームの合意形成に時間を要する場合がある

運用上の注意点

スキップラベルの活用

特定のPRでAIレビューをスキップしたい場合は、次のラベルを使用します。

  • skip-ai-review: AIレビューを完全にスキップ
  • renovate: Renovate PR（専用ワークフローで処理）

人間のレビューが必要なケース

次の変更はNEEDS_HUMANと判定され、必ず人間のレビューが必要です。

  • セキュリティ関連の変更
  • ドキュメント・READMEの更新
  • 設定ファイルの変更
  • スタイル・デザインの変更

ワークフロー別ラベル操作

ワークフロー 付与するラベル 削除するラベル
ai-task-dispatcher.yml -（条件判定のみ、ラベル操作なし） -
ai-task-implementation.yml in-progress in-progress（失敗時/キャンセル時）
ai-review-orchestrator.yml ci-failed, ai-iteration-{N}, ai-auto-approved, needs-human-review ci-failed, ai-auto-approved, needs-human-review, perspective:*, ai-iteration-{N}
pr-perspective-router.yml perspective:* perspective:*（再分類時）
ai-renovate-review.yml perspective:dependency, renovate -
ai-metrics-report.yml ai-metrics, automated（Issueに付与） -

トラブルシューティング

問題 対処法
Devinセッションが開始しない DEVIN_API_KEYの設定を確認
Claudeレビューが実行されない AWS IAMロールの権限を確認
イテレーション上限に達した 手動で修正し、ai-iteration-*ラベルを削除
CIタイムアウト CIの実行時間を確認、CI_WAIT_MINUTESの調整を検討

まとめ

この記事では、Claude（レビュー・判断）× Devin（実装・修正）の役割分担によるAI駆動開発ワークフローについて解説しました。

実現した効果

指標 Before After
PRレビュー待ち時間 平均4時間 即時（Claudeが自動レビュー）
レビュー指摘の修正 手動対応 Devinが自動修正
CIエラー修正 手動対応 Devinが自動修正（最大3回リトライ）
Issue実装開始 平均1日 Slackから即時着手
Renovate PR 手動確認・マージ Claudeが依存関係レビューし、AI_ONLYかつ指摘なしなら自動承認
効果測定 なし 週次レポートでKPIを自動計測
ナレッジ育成 なし PRコメントからドキュメントを週次で自動更新

重要なポイント

  1. 役割分担：Claudeはレビュー（判断）、Devinは実装（作業）という明確な役割分担
  2. 人間との協調：AIはあくまでサポートであり、最終判断は人間が行う設計
  3. 段階的な自動化：すべてを自動化するのではなく、信頼性の高い部分から自動化
  4. 透明性：すべての判断理由がPRコメントとして記録される
  5. セーフティネット：イテレーション上限、キャンセル時のクリーンアップ、HEAD SHA検証

今後の展望

  • レビュー観点の自動学習
  • MCP連携強化
    • Confluenceドキュメント読み込み
    • Figma MCPからデザイン取得 → 実装まで一気通貫
  • Jiraチケット起点の連携追加（Slackと同様のフローで起動）
  • 人間レビューコメント時の対応方針の定義（優先度・担当・再レビュー）
  • CodeRabbitとの併用検討
  • Slack通知の拡充（開始/完了/要人間対応などを分かりやすく通知）

最後に

ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com

参考リンク



以上の内容はhttps://techblog.zozo.com/entry/ai-driven-dev-with-claude-and-devinより取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14