AI時代の フィードバックサイクル設計 AI の速度を殺さない開発フローの作り方
184 Views
May 27, 26
スライド概要
Qiita Conference 2026
Developer
関連スライド
各ページのテキスト
CircleCI スポンサーセッション | 2026年5月27日 AI時代の フィードバックサイクル設計 AI の速度を殺さない開発フローの作り方 岡本 秀高 ( @hidetaka_dev ) Senior Field Engineer #QiitaConference 1
自己紹介 Hidetaka Okamoto (岡本秀高 ) ● CircleCI Senior Field Engineer ● 年間100本ペースで記事を書く人 ● CircleCIJapan ( Qiita )にて4月は平日毎日更新 https://qiita.com/CircleCIJapan 2
CircleCI について AI 速度でコードを検証する、世界トップクラスの CI/CD プ ラットフォーム 10K 200万 9,000万 300+ 顧客企業 ユーザー（開発者） 従業員数（全世界） 月間ビルド数 3
AI駆動開発における ソフトウェア企業の課題 4
AI駆動開発における ソフトウェア企業の課題 AIに書かせたコードの多くが 本番環境にデプロイされていない 5
State of Software Delivery Report 2026 デリバリーのパイプラインから、分析 出典: CircleCI State of Software Delivery Report 2026 https://circleci.com/resources/2026-state-of-software-delivery/ 6
State of Software Delivery Report 2026 世界的にコードの⽣成量は増加 +59% 前年⽐ / 全プロジェクト平均 過去7年で ⾒たことのない規模の変化が 開発の現場で発⽣している 出典: CircleCI State of Software Delivery Report 2026 https://circleci.com/resources/2026-state-of-software-delivery/ 7
Validation Gapの発生 ただし多くのコードがデリバリーされていない ブランチ別 中央値チームのスループット変化 メインブランチでの成功率 8
成功した企業との格差がより拡⼤する 上位5%チームのWF実行量 中央値チームの WF 実行量 97%+ +4% 下位25%チームの WF 実行量 前年比 大幅な生産性向上を実現 0% 生成したものをどれだけリリースできているかが、 AI導入効果の差を生み出す 9
AIが介在する前 コード生成（手元の開発）とリリースまでのWFは均衡していた Inner Loop Debug Outer Loop Plan 変更 (Change) Release Build Deploy Test フィードバック (Feedback) Validate Code 10
After AI コード生成だけが加速し、ループが詰まり出した Inner Loop Debug Outer Loop Plan 変更が大量に流れ込む Release Build Deploy Test フィードバックは追いつかない Validate Code 11
開発におけるボトルネックが、後ろの工程にシフトした コーディング レビュー テスト デプロイ リリース 10x 12
開発におけるボトルネックが、後ろの工程にシフトした コーディング 10x レビュー テスト デプロイ リリース ⚠ ⚠ ⚠ ⚠ 1x 1x 1x 1x 13
LLMと20分作業して、 CIの実行に 2時間かかるなら、それは機能しない。 フィードバックループの各段階は、 同じオーダー（桁）の時間で揃っていなければならない。 — Liz Fong-Jones Honeycomb Technical Fellow) 14
AI の速度に追従できる フィードバックの形が必要 15
フィードバックを 4 つの観点で再設計する 速度 AI と同じオーダー（桁）の時間で返るか 粒度 適切な粒度とタイミングで検証を実施できているか 形式 人間・エージェント、どちらでも実行できる形か 記憶 揮発する文脈・暗黙知が、リポジトリやCI に外在化されているか
loop.circleci.com CircleCI Research（Loop Lab）による AI駆動開発の実験 17
実験1 デバッグ‧修正は ⼀⼈でやるか、みんなでやるか https://loop.circleci.com/one-agentvs-a-team-what-benchmark-data-sa ys-about-multi-agent-debugging 18
実験1: デバッグ・修正は一人でやるか、みんなでやるか バグの修正方法をソロ vs チームで比較検証 52個のバグを仕込んだ ECアプリで検証 セキュリティ・性能・コード品質・ロジックの 4カテゴリ。 同じClaude Opus 4.6を、ソロと「専門特化チーム」で比較。 重み付けスコア (Security ×3.0, Logic ×2.5, ...) で評価。 19
実験1: デバッグ・修正は一人でやるか、みんなでやるか バグの修正方法をソロ vs チームで比較検証 52個のバグを仕込んだ ECアプリで検証 セキュリティ・性能・コード品質・ロジックの 4カテゴリ。 同じClaude Opus 4.6を、ソロと「専門特化チーム」で比較。 重み付けスコア (Security ×3.0, Logic ×2.5, ...) で評価。 チーム構成で改善量が +75% 性能・ロジックなど、文脈を横断する バグでチームが圧勝。 同じモデル × 同じコードベース × 同じ重み。 違いは「並列に走らせて分担させたか」だけ。 20
実験1: デバッグ・修正は一人でやるか、みんなでやるか 複数のバグ修正は、分割・並列して修正する • • バグの数だけコンテキストが肥⼤化する ○ エラーの再現 ○ ログやコードの調査 Context Rot が発⽣しやすくなる ○ 抜け漏れやハルシネーション Subagentあるいは チケットシステムなどを使い、 １つの問題に集中させる Solo Agent 🤖 1 Agent Security Performance Logic Quality vs Team Agents 🤖 Security 🤖 Performance 🤖 Logic 🤖 Quality 21
実験2 AI の「チェックOK」は 信⽤に値するか？ https://loop.circleci.com/we-let-an-ai -agent-say-i-passed-was-it-actuallygood 22
実験2: AI の「チェックOK」は信用に値するか？ AI も「自分の環境では動作する」と主張する • ⾃律的なコーディングエージェントを利⽤ ○ RalphループをベースにCI対応した 研究⽤の独⾃OSS ○ CIのFBも待って取得できる ○ • https://github.com/CircleCI-Research/ralph-ci 同じゲームアプリ開発を指⽰ CI チェックの有無だけを変更 23
実験2: AI の「チェックOK」は信用に値するか？ AI も「自分の環境では動作する」と主張する • ⾃律的なコーディングエージェントを利⽤ ○ RalphループをベースにCI対応した 研究⽤の独⾃OSS ○ CIのFBも待って取得できる ○ • CI チェックを 必須化 100% CIが成功 CI チェックを スキップ 20％ しかCIを パスできなかった https://github.com/CircleCI-Research/ralph-ci 同じゲームアプリ開発を指⽰ CI チェックの有無だけを変更 24
実験2: AI の「チェックOK」は信用に値するか？ AI も「自分の環境では動作する」と主張する • ⾃律的なコーディングエージェントを利⽤ ○ RalphループをベースにCI対応した 研究⽤の独⾃OSS ○ CIのFBも待って取得できる ○ • CI チェックを 必須化 100% CIが成功 CI チェックを スキップ 20％ しかCIを パスできなかった https://github.com/CircleCI-Research/ralph-ci 同じゲームアプリ開発を指⽰ CI チェックの有無だけを変更 Code is cheap. Green CI is priceless. コードの生産者による「自己申告」ではなく、CIによる検証で完了を定義すべき 25
実験2: AI の「チェックOK」は信用に値するか？ Learn: エージェントの作業中にできる限りの FBを出す コーディング中 Push - PR作成まで Review / マージまで Inner Loopでのフィードバック レビュー前の最終チェック Outer Loopでの検証 Type Check CI や実環境ベースのビルド Staging / Branch Deploy Lint より広範囲なテスト E2E / Smoke Unit Test Whyの明文化 セキュリティスキャン 26
実験2: AI の「チェックOK」は信用に値するか？ Learn: エージェントの作業中にできる限りの FBを出す コーディング中 Push - PR作成まで Review / マージまで Inner Loopでのフィードバック レビュー前の最終チェック Outer Loopでの検証 Type Check CI や実環境ベースのビルド Staging / Branch Deploy Lint より広範囲なテスト E2E / Smoke Unit Test Whyの明文化 セキュリティスキャン 早く手に入る検証 / FB はコード生成の近くで行う 27
Chunk Sidecar PREVIEW Inner Loop（ローカル環境）にて、CIの検証を実施する mirrors CI な環境 <60秒 でフィードバック 主要コーディング AI に対応 $ brew install CircleCI-Public/circleci/chunk 28
Smarter Testing Beta テスト結果を継続分析し、必要なテストのみを選別‧実⾏する最適化機能 影響のないテストの⾃動スキップ コードの変更差分を瞬時に解析し、 関係のないテストを排除してCI時間を⼤幅に削減 並列実⾏の動的最適化 選別されたテストを複数ジョブへ⾃動分割し、 コンテナの計算リソースを無駄なく活⽤ 次回の⾼速化に向けた⾃動学習 実⾏後のカバレッジを継続分析し、 次回の選別精度を⾼める影響度データを⾃動更新 29
実験3 オンボーディングを Wiki でやるか、スキルにするか https://loop.circleci.com/team-onbo arding-buddy-claude-code-skills-vsthe-wiki-maze 30
Wikiの迷路を、実行可能な Skillに置き換える チーム配属時のオンボーディングを Claude CodeのPluginとして配布 Agent Skills + MCPで 「実際に読んで」検証を行う team-name/ ├── plugin.json └── skills/ ├── onboarding/SKILL.md ← 入口 ├── access/SKILL.md ← MCP実検証 31
Wikiの迷路を、実行可能な Skillに置き換える チーム配属時のオンボーディングを Claude CodeのPluginとして配布 Agent Skills + MCPで 「実際に読んで」検証を行う Wiki: ⾃分で探索して発⾒し、解釈が必要 古い⼿順書を12個読み、13個⽬を⾒逃し、 3⼈にDMして相談。 セットアップ時の１⾏のtypoで半⽇が消える team-name/ Skill + MCP が伴⾛しながらチェック ├── plugin.json └── skills/ ├── onboarding/SKILL.md ← 入口 ├── access/SKILL.md ← MCP実検証 設置の抜け漏れがないかなどをその場で相談。 エージェントが設定を検証し、 フィードバックをリアルタイムに実施 32
情報を増やすのではなく、 学びのルートを整備する "Onboarding is not an information problem. It is a routing problem." オンボーディングは情報の問題ではない。 正しい順序で動かすための、設計の問題だ 暗黙知は Skill で外在化。 情報を増やすのではなく、必要な時に検証が走るルートを与える。 33
Chunk CLI + Claude Code PREVIEW 明⽂化されていないコードレビューの基準を、過去の PR ベースで明⽂化する $ brew install CircleCI-Public/circleci/chunk $ chunk build-prompt \ --org myorg --repos api,backend --top 5 Step 1/3 Discovering Top Reviewers [1/1] web-ui-consolidated ✓ Details written to .chunk/context/review-prompt-details.json ✓ PR rankings written to .chunk/context/review-prompt-details-pr-rankings.c sv Step 2/3 Analyzing Review Patterns Sending 194 comments (~97387 tokens) ✓ Analysis written to .chunk/context/review-prompt-analysis.md Step 3/3 Generating PR Review Prompt ✓ Prompt written to .chunk/context/review-prompt.md ⏺ Review Summary Files reviewed: 4 Issues identified: 2 Findings 1. Component name suffix swapped between CI and deploy configs .circleci/config.yml:45 and .circleci/deploy.yml:33 | Critical The two changes swap the -artifact suffix between the files in opposite directions: config.yml drops the -artifact suffix from the component name, 34
AI 時代に必要なフィードバックの 4 形式 速度 AI と同じオーダー（桁）で返らないとフィードバックは機能しない 粒度 1つのジョブに詰めず、 Inner / Push / Review に目的を分ける 形式 人間しか読めない手順を、エージェントが実行できる形式に置き換える 記憶 揮発する文脈・暗黙知を、リポジトリ・ CI・MCP に外在化する → 実験2 / Chunk Sidecar が Inner Loop で <60秒 の検証を提供 → 実験2 / Smarter Testing で変更影響だけを検証 → 実験3 / SKILL.md・MCP・Chunk CLI build-prompt → 実験1 (Context Rot) と 実験3 (Skill での暗黙知外在化 ) 35
自社の開発フローを検証する 4 つの問い 速度 AI が書いてから CI フィードバックが返るまで、何分かかっているか 粒度 変更影響に絞って検証する仕組みがあるか 形式 新人・エージェントが最初に読む手順は、実行可能な形式か 記憶 過去の失敗パターンや暗黙知が、リポジトリや CI に外在化されているか 36
Thank you. Q & A / Feedback Welcome 岡本 秀高 / CircleCI合同会社 loop.circleci.com / circleci.com 37