0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@y-morimatsu(Yuki Morimatsu)
in

AI駆動開発カンファレンス 2026夏 2日目 参加レポート — 「作れるか」から「信頼できるか」へ

0
Last updated at Posted at 2026-08-05

グラレコ

image.png

💡 この記事について
AI駆動開発カンファレンス 2026夏（2026/07/31、2日目）で筆者が聴講した5セッションを、個人の聴講メモをもとにまとめたレポートです。数値・引用・図解の内容はすべて講演スライドおよび登壇者の発言に基づいており、筆者による独自検証は行っていません。スライドに示された参照文献（Gartner、Veracode、METR、arXiv、DORA など）についても、原典の確認は行っていません。解釈や構成の責任は筆者にあります。講演スライドの撮影写真は掲載していません。

📌 2日目に聴いた5セッション

# セッション 登壇 時間
1 2億人の開発者と、エージェントの時代 ― GitHubが次に描くもの ― GitHub, Inc. Kyle Daigle 氏／GitHub Japan William Zhang 氏 11:00-11:50
2 Defense in Depth: How Replit Secures Every Layer of AI-Generated Software Replit, Inc. Kody Low 氏／Replitアンバサダー 佐藤 亮 氏 12:10-12:50
3 SIビジネス変革に向けたAI駆動開発のチャレンジ 富士通株式会社 岡元 大輔 氏 13:00-13:40
4 AI駆動開発は個人技からチーム戦へ: 組織でAIを使いこなすための実践設計 CodeRabbit, Inc. 中津川 篤司 氏 16:00-16:40
5 AI時代の強いチームの作り方 KDDIアジャイル開発センター株式会社 吉田 祐樹 氏 16:50-17:30

登壇企業の顔ぶれを見ると、プラットフォーム提供者（GitHub・Replit）、大規模SIer（富士通株式会社）、開発ツールベンダー（CodeRabbit）、受託開発の現場（KDDIアジャイル開発センター株式会社）と、立ち位置がきれいに分かれています。同じ「AI駆動開発」という言葉を、それぞれ違う場所から語る一日でした。

そして5つとも、扱っているテーマが重なりました。AIがコードを大量に生み出せるようになった後、それをどう信頼し、どう組織として持ち続けるかという話です。以下、セッションごとに見ていきます。

1️⃣ GitHub「2億人の開発者と、エージェントの時代」

Room CD のオープニングキーノートです。登壇は GitHub, Inc. の Kyle Daigle 氏と GitHub Japan の William Zhang 氏（@moulongzhang / AI GTM Lead）のお二人で、スライドを進行したのは Zhang 氏でした。カナダでソフトウェアエンジニアとしてキャリアを始め、現在は GitHub Copilot の APAC 地域展開を主導されている方です。

🎂 Copilot 5周年と、トラフィック4倍

2026/6/29 に GitHub Copilot が5周年を迎えたという話から始まりました。そこから、API トラフィックの伸びが提示されます。

Chat から Agent まで9ヶ月、Agent から Parallel Agents まで7ヶ月。この間にトラフィックは4倍になったそうです。刻みが短くなっていること自体が、話の伏線になっていました。

外部評価としては、Gartner「Magic Quadrant for Enterprise AI Coding Agents」（As of April 2026）で GitHub が Leaders 象限に入っています。同じ象限には Cursor / Anthropic / OpenAI。境界付近に Cognition / Amazon Web Services / Google / Alibaba Cloud、Visionaries に Tabnine、Niche Players に Atlassian / BytePlus / JetBrains という配置でした。

🕰️ 「副操縦士」から Agent へ

Copilot という名前が示すとおり、出発点は「副操縦士」でした。そこから4段階で性格が変わっています。

段階 機能 性格
① LLM によるコード補完 コード補完だけ
② Copilot Chat Ask Mode 言われたことに応答する
③ Copilot Chat Edit Mode 言われたことに応答する
④ GitHub Copilot Agent Mode 自律的に動く

①〜③は人が運転席にいる前提の機能で、④で前提が変わります。

📅 リリースのタイムライン

製品側とセキュリティ側、2本のタイムラインが提示されました。

製品リリース（2025年7月〜2026年6月）

時期 内容
JUL '25 CCA × VS Code「Start + track CCA sessions from VS Code」／MCP × VS Code「MCP support in VS Code GA」
AUG '25 MCP「MCP registry」／CLI「Public preview」／CCA「GA」
FEB '26 AGENTIC WORKFLOW「Technical preview」／CLI「GA」
APR '26 CCA「Research, plan, & code」
JUN '26 AGENTIC WORKFLOW「Public preview」／APP「GA」／APP「Technical preview」／CCA「Schedule & automate tasks」

セキュリティ関連（同期間）

時期 内容
JUL '25 CCR（Copilot Code Review）「Generally available in more surfaces + admin controls」
AUG '25 GHAS「Unbundling + packaging updates」
SEP '25 CCR「"Full picture" preview enhancements」
JAN '26 SECURITY「AI security detections surfaced in PRs」
MAR '26 AUTOFIX「Agentic security remediation service」
APR '26 CODE QUALITY「Launch (public preview)」
JUN '26 DEPENDABOT「Remediation / automation improvements」／SECRET SCANNING「Coverage + partner ecosystem expansion」／CODE SCANNING「Signal + workflow improvements」／CCR「Integrates MCP / Skills for richer validation actions」

2本を並べると、機能追加と検証機構の追加がほぼ同じテンポで進んでいるのが見えます。

💻 GitHub Copilot App と Code Quality

GitHub Copilot App（2026.06.18 GA）は、エージェント駆動型開発用のデスクトップアプリケーションです。

  • Choose your surface: IDE / CLI / Mobile / Desktop / Web のすべてに対応
  • Choose your model: Auto / Claude / GPT / Other models から選択
  • 画面構成は Home / Inbox / Workflows / Search、Sessions、Quick chats、そして接続リポジトリの最近更新された PR・Issue を並べる「Up next」

GitHub Code Quality（GA - JULY 20）は、こう説明されていました。

「GitHub Code Qualityは、開発者とエージェントが高品質なソフトウェアを構築・維持することを支援し、組織にはそれを証明するための可視性（監督機能）を提供します」

画面は組織横断の Code quality insights で、Maintainability × Reliability の2軸バブルチャート（Excellent / Good / Fair / Needs Improvement）にスコア分布を示し、リポジトリ別に Maintainability / Reliability / AI Findings を一覧化するものでした。「開発者とエージェントを支援する」と並べて書いてあるところが、この製品の位置づけを表しています。

🤖 Use Case 1: Migration ——「124 subagents. Up to 20 agents at once.」

ここから実例です。1つ目は大規模なマイグレーションでした。

項目 内容
オーケストレーター GPT-5.6 Sol
サブエージェント GPT-5.6 Sol / Claude Haiku / Claude Opus / Claude Sonnet を混在させて割り当て
規模 124サブエージェント、同時最大 20エージェント
期間 0h〜56h のタイムライン
ピーク 約22h地点で PEAK 20 AGENTS、約33h地点で PR OPENED

並列サブエージェントのレーンは、LSP runtime workstream／Skills runtime workstream／Plugin runtime workstreams／Hooks runtime workstream／Extension host workstream／implement typed component discovery／extensions implementer／lsp gap integrator といった具合に、担当領域ごとに切られていました。

コストも開示されていました。Daily model spend（APR 13〜JUL 12、USD/DAY）のグラフで、MAY 15 以降がマイグレーション期間です。

  • それ以前は $1K未満/日 で推移
  • 移行中は $2K〜$3K/日 が常態化
  • 6月下旬にピークの 約$4.8K/日
  • 内訳は Claude Haiku / Claude Sonnet / Claude（Opus）/ GPT-5.* / Gemini

用途に応じて複数ベンダーのモデルを混ぜているのが特徴的でした。オーケストレーターに1つ、サブエージェントには役割に応じて別のものを、という使い分けです。

🏭 Use Case 2: Agent First Development ——「20人チーム、1000PRマージ/週」

2つ目は、GitHub 自身の開発チームの話でした。担当しているのは Copilot Cloud Agent の Runtime、Copilot Code Review の Runtime、GitHub Copilot CLI、GitHub Copilot SDK、GitHub Copilot App です。

まず、週次リリース数の変化が示されました。Claude Releases では週10前後で推移していたものが、Copilot Releases に切り替わってから週100前後まで急増したというグラフです。

ベンチマーク比較も併せて提示されました（いずれも sonnet-4.5）。

ベンチマーク Copilot CLI Claude Code
SWE Bench 352/500（70%） 358/500（71.6%）
Terminal Bench 48/95（50.3%） 48/95（50.5%）

スコアはほぼ同等です。それでもリリース数が10倍になったという並べ方は、差を生んでいるのはモデルやCLIの素の性能ではないという主張として受け取りました。

では何が差を生んだのか。リポジトリの中身が示されます。1リポジトリに70万行のコードがあり、その54%がテストでした。

区分 ファイル数 行数
Tests 1,479 398,180
Prod code 970 251,900
Benchmarks 257 33,037
Config/misc 75 20,860
Docs 62 11,010
Generated/types 6 10,118
Scripts/ops 61 8,530
CI/workflows 47 6,341
Total — 739,968 physical lines（644,996 non-empty）

テストが約54%、プロダクションコードが約34%という比率です。

PR Velocity Summary（2026/3/18-24）も出ていました。

指標 値
Total merged PRs 503（前週491、+2.4%）
Avg PRs/day 71.9
Weekday merges 458
Weekend merges 45（+18.4%）
ピーク 3/18 の 128件

開発ルールはシンプルに2つでした。

  1. テストの整備
  2. コードレビューの徹底

そのうえで、エージェント体験の向上として取り組んだことが5つ。

# 取り組み
1 テストの高速化
2 厳格なリンター
3 CIフィードバックループの改善
4 検証しやすい作業単位
5 決定論的なフォーマット

これらが実物の PR で示されたのが良かったところです。

打った手 内容
E2Eテストのキャッシュ PR #884「E2E test response caching」。CAPIレスポンスをスナップショットからリプレイする方式で、実行時間を 2分 → 25秒
E2Eのシャーディング PR #1615。runtime-test は Vitest の --shard で4分割し ~12m → ~3-4m、tools-test は macOS/Windows それぞれ3 shards＝計6並列
リポジトリの分割 PR #8107「Move /runtime to a separate repository.」。github/copilot-agent-runtime をサブモジュール参照に変更、300+ files changed、+748 / -232,942
リンターの全面適用 PR #35「Enable typechecked linting, grandfather all existing errors」で既存エラーを一旦許容し、#86 / #91 / #93 / #124 で @typescript-eslint の各ルール違反を段階的に解消

4つとも、エージェントのためというよりフィードバックループを速く・確実にするための投資です。テストが2分かかると、エージェントの試行回数がそのまま制限されます。25秒なら制限が緩みます。

学びとして挙げられたのは3点でした。

  1. アーキテクチャを綺麗に保つ規律の重要性
  2. 「複利式の技術的負債」の発生
  3. コードレビューとテスト自動化による改善

そしてこれからに向けての2点が、なかなか大胆でした。

  1. コードは以前ほど大切なものではなく、捨てたり書き直したりすることを恐れる必要がない
  2. 良いテストがセーフティネットとなる

コードの価値が下がった代わりに、テストの価値が上がったという整理です。テストが54%を占めるリポジトリの構成は、この考え方の裏返しになっています。

🏗️ 2章「今のGitHub」

プラットフォームの信頼性については、優先順位が明示されました。

取り組んだのは、キャパシティ確保（Azure移行・CPU増強・DB負荷軽減）／レジリエンス・分離・可視性／透明性の3方向です。現在は可用性が大幅に改善し、「現在の30x ワークロードを想定したプラットフォームへ」と説明されていました。透明性の実践としては GitHub availability report（April / May / June 2026）が提示されました。

ガバナンスとコスト管理については、それぞれ3つずつ。

領域 打ち手
ガバナンス Enterprise Managed Settings／Agent Session Streaming／Copilot Metrics
コスト管理 支出管理／Auto Mode／Agent効率

「『AIによる開発スピードか、統制の確保か』を選ぶ必要はなくなる」

そして、Copilot usage metrics impact Dashboard の GA（JULY 22, 2026）で示された数字が、この日いちばん引用されそうなデータでした。

Adoption cohorts（PR per user/month）

コホート 内容 PR/user/month
Passive users — 1.8
Phase 1 Code-first コード補完・IDE agent chat 5.9
Phase 2 Agent-first CCA・CLI・CCR のいずれか1つ 8.7
Phase 3 Multi-agent 2つ以上の coding agent 23.5

Adoption multiplier

指標 差
Code shipped engaged Copilot users は passive users の 3.3x（5.9 vs 1.8 PR/user/month）
Time to merge pull request 2.4x 速い（6.9分 vs 1.6時間）

Phase 2 の 8.7 から Phase 3 の 23.5 への跳ね方が、他の段差と比べて突出しています。1つのエージェントを使うことと、複数のエージェントを並行して使うことの間に段差がある、という読み方になります。

🧱 GitHub が目指す姿 — The Agent-Native Engineering System

エージェントに委ねたい仕事として、12個が列挙されました。

エージェントに委ねたい仕事
バグを修正し、テスト・レビューを経て出荷
フィーチャーフラグ配下で実装し、ロールアウト待ち
セキュリティ脆弱性を修正し、検証済み
ビルド失敗の原因を特定し、通る状態に復旧
デグレなしで依存関係を更新
顧客エスカレーションを製品の修正に反映
パフォーマンス課題を特定・最適化し、計測
プルリクエストをレビューしてマージ
意味のあるカバレッジでテストの空白を解消
インシデントを収束させ、恒久的な再発防止策を実施
コンプライアンス要件をコードとポリシーに実装
検証とロールバック安全性を備えた移行を完了

12個とも、末尾が「〜して出荷」「〜して検証済み」「〜して計測」のように、確認まで含んだ形で書かれているのが特徴です。「実装する」で終わっている項目が一つもありません。

それを支えるのが6つのレイヤーです。

総括スライドのタイトルは「The Agent-Native Engineering System」でした。

🔮 今後のリリース

最後に、予定されている変更が領域別に紹介されました。

領域 予定
メンテナーの保護（5件） Pull Request のアーカイブ（パブリックプレビュー）／非コラボレーターの同時オープンPR数の上限設定（GA）／PR数上限を免除するコントリビューター許可リスト（GA）／非コラボレーター向けのリポジトリ単位のオープンIssue上限／Issue作成をコラボレーターのみに制限
プルリクエストの刷新（3件） タブ横断パネルを備えた新しいPRヘッダー（パブリックプレビュー）／Pull Request スタック（パブリックプレビュー）／新しいPR概要ページ（パブリックプレビュー）
計画基盤としてのProjects（1件） IssueフィールドとProjectsでの複数選択タイプに対応
Issue体験のギャップ解消（3件） リポジトリIssueの保存済みビュー／重複Issueの自動検出（プライベートプレビュー）／Agent plan と issues の連携
GitHub Actions（3件） GitHub Actionsでのステップ並列実行（パブリックプレビュー）／複合アクションのステップ分割に対応（GA）／Actions UI のパフォーマンス改善

「メンテナーの保護」が5件と最も多いのが目を引きました。エージェントが PR や Issue を大量に作れるようになった結果、受け取る側を守る機能が必要になっている、という話として読めます。

締めは「Wall of Love」。UI改善などに対する開発者コミュニティからの反応を敷き詰めたスライドで、ThePrimeagen、Theo - t3.gg、Addy Osmani、Mitchell Hashimoto、Carol Willing、Steve Krouse といった名前が並んでいました。

2️⃣ Replit「Defense in Depth ─ 多層防御」

邦題は「多層防御 ─ Replit が全レイヤーで守る AI 生成ソフトウェアのセキュリティ」で、全25スライドの構成でした。登壇は Kody Low 氏（Field Engineering Lead, Replit, Inc.）と佐藤 亮 氏（Replit Japan Community Lead）です。

🎬 3部構成

40分が3つに分かれていました。

時間 内容 担当
12:10〜（約5分） イントロダクション：なぜいま「AIが作ったものを信頼できるか」が問われるのか 佐藤 氏
12:15〜（約20分） 本編・録画：Replitのセキュリティを全レイヤーで解説＋実機デモ。英語音声のため、再生しながら佐藤氏が日本語で同時解説 Kody Low 氏（録画）
12:35〜（約15分） 日本向けガバナンス編 + Q&A：日本の組織で必ず問われる内部統制の論点に絞って 佐藤 氏

録画を流しながら日本語で同時解説し、後半を日本固有の論点に充てるという構成でした。海外プロダクトの技術セッションとして、実用的なやり方だと思いました。

なお佐藤氏は、技術評論社から『Claude Code で学ぶ Agent Skills 入門 ── 手続き型知識を実装してAIエージェントをスペシャリストに変える!』『Vibe Coding で楽しく作る! Replit ではじめる本格Webアプリケーション開発』を出されており、Replit ハッカソン最優秀賞の受賞者でもあります。

🌍 Replit の規模 —— 作っている人の90%は開発者ではない

ミッションは「次の10億人のソフトウェアクリエイターのために。」です。

「数百万、いや数十億もの人々が、わずか数クリックで自分のアイデアを形にする未来は、とてもワクワクします。」
— Amjad Masad 氏（Replit CEO 兼 共同創業者）

数字 意味
90% Replitでつくる人々は開発者ではない。マーケター、PM、営業、運用チームが、ビジネスに必要なソフトウェアを自分でつくって公開している
6,000万+ つくる人々
4.6億+ 作成されたプロジェクト

Fortune 500 企業が、技術チームなしでスタートアップのような速さでリリースしている、という説明もありました。この「90%が非開発者」という前提が、後半のセキュリティの話の重みを決めています。

🔌 エンタープライズデータ連携

「ガバナンス適用済みのエンタープライズデータの上に本物のアプリをつくる。データは環境の外に出ません」

パートナー 仕組み
Databricks Replit でつくり、そのまま Databricks へデプロイ。Unity Catalog のガバナンスは最初から効いている。アプリは Databricks の認証・Unity Catalog ガバナンス・ネットワーク制御をそのまま継承。ユーザー単位のアクセス（各ユーザーは自分の権限が許可するデータのみを見る）。SQL不要で、必要なものを説明すれば Agent がクエリを書く。Databricks 2026「アプリ生成パートナー・オブ・ザ・イヤー」受賞
Microsoft Fabric Replit でデータアプリをつくり、Microsoft Fabric 内に公開。データはテナントの外に出ない。アプリは Fabric ポータル内に公開され、Microsoft ホスティング上で実行。ユーザーは Entra SSO でサインイン。Power BI セマンティックモデルを DAX で読み取り、設計上は読み取り専用。Microsoft Build 2026 の Satya Nadella 氏の基調講演で紹介

🧭 Replit とは

「クラウドで完結する、AIコーディングエージェント & プラットフォーム」と定義されていました（Describe it, and it is built, run, and shipped — entirely in the cloud.）。

「エディタでもホスティングでもなく、その全部が一つ。だから、全レイヤーをまとめて守れる。」

この一文が、セッションのタイトルにそのままつながります。守る範囲を広く取れるのは、プラットフォームが全部を持っているからだ、という論建てです。

🇯🇵 日本での導入

企業 内容
JSOL 2026年4月28日に「米Replit社と日本初の戦略的パートナーシップを締結 ～バイブコーディングの本格導入で企業の新サービス開発を迅速化、効率化～」を発表。リセラーとして国内で提供
SMBCグループ 三井住友フィナンシャルグループの自社メディア「DX-link」で導入事例を公開（2025年11月27日「シリコンバレーの技術で切り拓く開発革命。Replit社導入の舞台裏」）

「日本初の戦略的パートナーシップを締結。ほか大手複数社でも導入が進行しています」とのことでした。

❓ WHY NOW —— 問いは「作れるか」から「信頼できるか」へ

AIエージェントがコードの大半を書くようになり、セキュリティチームの問いが変わったという話です。

「作れるか」はもう論点ではない。論点は「作られたものを本番に出せるか」。
その答えは、盲信ではなくアーキテクチャで出す ─ それが Defense in Depth。

出典は Replit 公式ブログ "Defense in Depth: How Replit Secures Every Layer of the Vibe Coding Stack"（2026年4月）です。

📊 THE DATA —— この2年で改善したものと、しなかったもの

このセッション、いや2日目全体で最も印象に残ったデータがここでした。

指標 値 この2年の変化
構文として正しいコードを生成できた割合 95%超 大きく改善した
セキュリティ試験に合格した割合 55% 2年前とほぼ同じ水準のまま動いていない

グラフ「Security Pass Rate vs LLM Release Date」では、Syntax Pass Rate が右肩上がりで1.0付近に張り付くのに対し、Security Pass Rate は0.5前後で横ばいのままでした。

「モデルは賢くなった。でも、安全にはなっていない。伸びなかった側を埋めるのは、仕組みの仕事。」

出典は Veracode "2026 Spring GenAI Code Security Update"（2026年3月・150以上のLLM／4言語80課題）で、横軸は各モデルのリリース日です。

モデルの進化が解決してくれない領域が明確に示されている、という点でこのグラフは強い主張になっています。あとで見る CodeRabbit のセッションでも、別の調査から同じ方向の数字が出てきます。

🙋 THREE QUESTIONS —— 現場で必ず問われる3つの問い

前提は「『作れる』を広げるほど、『統制できる』が導入の条件になる」でした。

問い 中身 答え方
危険なコードは？ AIが高速に書いたコードに、脆弱性は潜んでいないか 公開前にコード全体を自動レビュー／重大な脆弱性は公開をブロック
誰が使える？ 退職者や部外者が、まだアクセスできてしまわないか 全社共通IDでSSO、退職時に自動遮断／役割ごとに操作権限を制限
誰が作った？ いつ誰が何を変更したか、後から追えるか あらゆる操作を監査ログに記録／SIEM連携で異常をリアルタイム検知

前半（録画）で1つ目に、後半で2つ目・3つ目に答えるという構成でした。

🛡️ THE MAP —— Defense in Depth の6レイヤー

「どのレイヤーも『その上が破られる前提』で設計する」「1枚抜けても下がまだ残る」

録画は前半 約11分がアーキテクチャ、後半 約8分が実機デモという配分でした。

🤝 SHARED RESPONSIBILITY —— どこまでが Replit で、どこからが利用者か

「デフォルトで安全」を正しく理解するための境界線が示されました。

Replit が守る（プラットフォームが構造として担保する範囲） 利用者が担う（人が判断しなければならない範囲）
基盤の隔離（microVM・顧客ごとの GCP プロジェクト） アプリのビジネスロジックと権限設計
サプライチェーン（Package Firewall・Determinate Nix） 誰にどこまで公開するかの判断
シークレットの隔離（プロキシ方式でコードに触れさせない） スキャン結果のレビューと修正の適用
公開前スキャンの強制実行 組織のアクセス管理（SSO・RBAC）の運用

「『デフォルトで安全』は『何もしなくていい』ではない。仕組みは用意されている、判断だけを人が担う。」

利用者の90%が非開発者というプロダクトで、この線引きを明示するのは大事なことだと思いました。「自動で安全」と言い切ってしまうと、判断が必要な部分が誰にも見えなくなります。

🔐 GOVERNANCE 01 —— 誰が触れるかを、管理する

「退職した社員が、まだシステムに入れる」を防ぐための3点です。

仕組み 内容
SSO（SAML / OIDC） Okta・Microsoft Entra ID・Google など全社共通IDでログイン。会社のIDを停止すれば、Replitへのアクセスも同時に遮断される
SCIM（自動プロビジョニング） 入社・異動・退職に伴うアカウント作成と削除をIDプロバイダから自動同期。消し忘れという人為ミスを構造的になくす
RBAC（役割別アクセス制御） 閲覧・編集・デプロイの権限を組織横断で細かく設定。「作れる人」と「本番に出せる人」を分離できる

📋 GOVERNANCE 02 —— 誰が何をしたかを、記録する

仕組み 内容
Audit Logging（監査ログ） 組織内のあらゆる操作（ユーザー追加・プロジェクト削除・権限変更・デプロイなど）を記録。監査対応や事後調査の証跡になる
SIEM連携 既存のセキュリティ監視基盤へログを転送し、異常をリアルタイムに検知。「Replitだけ監視の外側」という状態を作らない

AIが書く量が増えるほど「誰が承認したか」の記録が効いてくる、という話で締められました。エージェントの作業もチェックポイントとして全て版管理されるそうです。

3️⃣ 富士通「SIビジネス変革に向けたAI駆動開発のチャレンジ」

登壇は岡元 大輔 氏（富士通株式会社 AI Innovation Center シニアマネージャー／Global Fujitsu Distinguished Engineer (Data&AI)）です。AI-Driven Software Development Platform のプロダクトマネジメントを担当されています。資料の扉には「AI-DRIVEN SDP // Code Never Sleeps_」のロゴが入っていました。

📎 このセッションは内容が濃かったため、別途、単独記事として詳しくまとめています。ここでは2日目レポートとしての要点に絞ります。

⚖️ 生成AI時代におけるSIerの構造的ジレンマ

話は「SIerがなぜこれを作るのか」から始まりました。不可逆な構造変化と、それでも直面する現実が対比されます。

不可逆な構造変化 一方で直面する現実
生産性の飛躍的向上により、価格競争が加速 ミッションクリティカル領域も変革の必要性が高まる一方で、一気に対応できず段階的変革が前提
生成AIの民主化により、顧客主導の内製化が進展 既存のシステム・データ・業務プロセスが存在し、新しい技術の適用には構造的な制約が伴う
単純な開発・改修は、差別化しづらい領域へ 契約形態・責任分界・ガバナンスなど、従来モデルとの整合が求められる
技術・ツール起点の競争はコモディティ化し、競争優位明確化が困難に AI活用の期待が高まる一方で、精度・セキュリティ・説明責任を含めた信頼性の確保が不可欠
価値提供は「開発」から「成果・運用」へシフト 成果指標や報酬モデルが未確立で、責任範囲・リスク分担を巡る契約上の合意形成に時間を要する
FDEやAgent型など、新たなプレイヤーが台頭 既存事業者は高度専門人材の確保・育成が追いつかず、人月ベースの商習習慣や調達プロセスも根強く残る

🏗️ AI-Driven SDP とは —— 3人月が4時間に

「AIエージェントが自律的に連携し、要件定義から設計・実装・結合テストまでの開発プロセスを一気通貫で実行するAIドリブン開発基盤」

デモは法制度改正時のシステム改修の自動化でした。法令文書を入力として、要件定義 → 設計 → 実装（改修）→ 結合テスト をAIエージェントが実行します。成果は「システム改修は、人の作業からAIの作業へ」——3人月 → 4時間（約100倍の生産性）。

📜 技術的ブレイクスルー 01 —— 769ページの法令文書を読み解く

「令和6年度 診療報酬改定 個別改定項目」は 769ページ（出典：厚生労働省）あります。AIエージェントはこれを細則まで理解し、設計書と照合してシステムの修正箇所を特定し、外部仕様レベルの要件へ自動生成します。

実例として示されたのが「湿布薬」→「貼付剤」という用語変更でした。1つの用語変更が3箇所に波及します。

影響箇所 生成された要件
公開マスタ設定（チェック） マスタ内の「湿布薬」を全て「貼付剤」に変更。対象範囲を鎮痛・消炎目的での使用（麻薬・向精神薬、専ら皮膚疾患用を除外）に限定する定義ロジックへ修正。リフィル制限の判定対象も「限度が定められている貼付剤」へ変更し、「がんでの鎮痛目的」の場合を除外するロジックを追加
処方指示ツール（処方指示画面） 画面上の表記をすべて差し替え。リフィル処方の可否判定ロジックを「貼付剤」定義に則って改修
院外処方箋印刷 処方箋に出力される医薬品種別の表記を変更。リフィル回数やリフィル可否欄も新基準に合わせて記載仕様・印刷内容を見直す

除外条件まで含めて生成されているところが、単なる文字列置換ではないことを示していました。

🔍 技術的ブレイクスルー 02 —— Multi-layer Quality Control

AI出力の品質を「有識者レベル」に引き上げる仕組みとして、4つのレイヤーが説明されました。

レイヤー 内容 効果
自律設計レイヤ（ReActループ） 観察→思考→行動を反復し、検索・調査→設計具体化→次の参照先特定までを自走 要件定義・設計エージェントの判断精度を底上げ
ガーディアンレイヤ（メタ認知チェック） 品質基準（根拠・一貫性・明確さ）でAIの思考と結論を監査。不足・曖昧・矛盾があれば「やり直し」を指示 AIが陥りやすい「それっぽい回答」を正す
知識レイヤ（現場の作法を注入） 命名規則・例外運用・画面ID⇔コード対応など、現場の当たり前をガイド・ルールとして構造化し、検索インデックスと設計文脈に注入 会社固有のシステム開発作法をAIが再現可能にする
情報アクセスレイヤ【特許出願中】 大量ドキュメントや数百万のコードから、AIの思考に必要な部分のみを抽出し、要約・抜粋を行う 精度を落とさず大規模情報を扱えるようにする

エージェント構成は Multi Agents Orchestration（要件定義／設計／製造／テスト／環境配備の各エージェント＋中央の再修正オーケストレーター）で、テストエージェントからのフィードバックを受けて設計・製造へ差し戻す形です。設計思想は Role-Based Agent Design ——「AIエージェントは『万能化』ではなく、役割分担と制御によって、既存の現場に組み込める形に設計」でした。Human in the Loop も前提として組み込まれています。

🌱 AI-Ready Engineering —— 「仕込み」が精度を決める

このセッションの核心はここでした。

「AIが既存システムを正しく理解し、信頼性ある自動化を実行できるよう資産・知識・品質を整える工程。この『仕込み』の成熟度が自動化の精度を決める」

柱 内容
資産理解 Asset Understanding 既存システム資産の構造化と検索インデックス化／暗黙知の形式知化
開発ルール・設計構造の標準化 Engineering Conventions 命名規約・設計作法・テスト観点の整備／修正しやすい構造への再編
正解データの準備 Ground Truth 過去改修の正解データ化／AIの結果を正解データと比較・評価する仕組み
実行環境の整備 Execution Readiness 自動ビルド・自動テスト・自動配備の仕組み（CI/CD）／AIが出力した成果物をCI/CD基盤と連携

これと Fitting（正解データとAI改修結果のギャップを評価し、コンテキストやプロンプトをチューニング）が相互に循環します。

暗黙知の扱いも具体的でした。LLMが知っている一般常識は書かないほうが良く（矛盾が生じた時にLLMが混乱するため）、ソースコード構造もLLMがある程度自動で把握できます。それらから漏れるものが暗黙知であり、知識が無い状態で SDP を回して成功・失敗を分析し、AIが知らない知識を考察するサイクルで明らかにしていく、という引き算の定義です。

🔭 これからの姿

  • 自己進化マルチAIエージェント技術（2026年5月25日プレスリリース）: 実行 → 振り返り → 学習 → 検証 → 活用のサイクルを、マルチAIエージェントチームが自律的かつ継続的に回す。人によるフィードバックは「有効なものだけを取り込む」形で外から入る
  • Review Hub と AHD（AI Human Harmonized Data）: AIが先にレビュー → AIが判断材料を整理 → 人が最終判断 → 判断結果は AHD へフィードバックされて循環。「最終的な説明責任と承認責任は人に残る」
  • 3ステップの未来像: Step 01 AI-driven Development → Step 02 Modernization for AI → Step 03 Data Flywheel

展開ターゲットは「変化し続けるシステム」で、対象業種は金融／通信／小売／物流／製造と示されていました。

4️⃣ CodeRabbit「AI駆動開発は個人技からチーム戦へ」

登壇は CodeRabbit, Inc. の中津川 篤司 氏です。冒頭で「覚えてほしい3つ」が提示されました。

内容
🥕 レビューを基本とした Agentic Change Management
🩴 シート単位の定額・OSSは無料
⛵ キャラクターの名前は Hoppy

Agentic Change Management は、こう定義されていました。

「AIエージェントが大量に生成するソフトウェアの変更を、検証・優先順位付け・理解・承認・保守まで一貫して管理する仕組み」

📈 1. AI駆動開発の推移

エンジニアリングの変化として2つが挙げられました。

① シチズンデベロッパー（市民開発者）増

数字 出典
企業の63%が内製化、38%が市民開発に取り組み アプリケーション開発に関する調査 | IT Foresight
生成AI導入済み企業は 57.7% 野村総合研究所「IT活用実態調査（2025年）」
ローコード・ノーコードツールの導入が 51.0% 同上

② 自動化の追求（用語の変遷）

1日目にも「ハーネス」という言葉が何度も出てきましたが、こうして年表に置かれると、関心の移動が分かりやすくなります。プロンプト（何を言うか）→ エージェント（誰にやらせるか）→ コンテキスト（何を渡すか）→ ハーネス／ループ（どう回すか）という順です。

⚠️ 2. 最近のAI駆動開発の課題

ここは数字が大量に出てきました。すべてスライドで出典が示されていたものです。

セキュリティ／品質ガバナンス需要

数字 出典
全テストケースの 45%に脆弱性が含まれる。新モデルを利用しても改善されず GenAI and Code Security: What You Need to Know
AIが利用する外部ライブラリの 49%に既知脆弱性。昨今のサプライチェーン攻撃に繋がる問題 State Of Dependency Management 2025 | Application Security
AIは人の 1.7倍、深刻な問題を含むPRを作成 State of the AI vs. Human Code Generation Report

ROI（生産性が本当に向上しているのか）

数字 出典
AI利用で24%高速化すると予測していたが、実際は 19%低下していた METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」
Copilot導入でバグ数が41%増加。PRサイクルタイムは変化なし Does GenAI Improve Software Developer Productivity?
コア開発者のレビュー負荷 6.5%増により、チームの開発生産性が低下 arXiv:2510.10165

生成されるコードの品質のばらつき

  1. 学習元データの問題 —— OSS、コミュニティで公開されるコードは品質が不安定
  2. 組織のコンテキスト、セキュリティ水準の不足（The Most Common Security Vulnerabilities in AI-Generated Code | Endor Labs）
  3. AIは単純で反復的なコードに強い反面、複雑な設計・依存関係に弱い（arXiv:2508.21634「Human-Written vs. AI-Generated Code」）

AI活用スキルのバラツキ

  1. 適切なコンテキストを与えられているか否か
  2. 個人のMCPサーバー、スキルの設定に依存
  3. 学習元データの問題

結論：知見を個人に閉じるのではなく、チームで共有する

コードレビューがボトルネックに

数字 出典
AI生成コード増で、レビューがボトルネック arXiv:2605.17548「Rethinking Code Review in the Age of AI: A Vision for Agentic Code Review」
コードレビュー担当の約9割が、AI生成コードの普及で「レビュアー負担増」を実感 AI生成コードのレビュアー負担に関する調査
レビューの待ち時間や対応時間が長引き、バグの発生率は54%増加 AI Impact on Engineering Productivity: 2026 Report Data

そして、開発チーム体制の構造問題です。PM／シニアエンジニア／エンジニアのピラミッドに対して「エンジニア >> レビュー担当」という不等号が引かれていました。

エンジニアの人数は増やせても、レビューできる人の数はすぐには増えません。しかも AI が生成量を増やすのはピラミッドの下側なので、上側の負荷だけが上がるという構図です。

📐 3. 開発生産性とは —— 5つの観点

速度／品質／レビュー／フロー／体験の5観点が、五角形で提示されました（参照として dora.dev/guides/dora-metrics/、docs.gitlab.com の Value Stream Analytics、queue.acm.org/detail.cfm?id=3454124 などが挙げられていました）。

観点 指標
速度（ボトルネック把握に利用） 1. リードタイム 2. PRマージ時間 3. デプロイ頻度
フロー（実装より待機・調整・割り込みに時間を奪われていないか） 1. 作業中時間／待ち時間 2. 会議時間 3. ブロック時間 4. コンテキストスイッチ回数
体験（満足度・効率・フローは重要な観点） 1. 開発者満足度 2. 集中時間 3. 認知負荷 4. アンケート

※ 残る「品質」「レビュー」の2観点については、筆者のメモに個別指標を書き取れていません。上の表は5観点のうち3つ分です。

「フロー」に待ち時間・会議時間・ブロック時間・コンテキストスイッチ回数が並んでいるのが実務的でした。AIが実装を速くしても、この4つが変わらなければ全体は速くなりません。

🏛️ 4. 開発"組織"でAIを活用するための設計 —— 4つの柱

前段として、開発者ごとにAIツール・MCP・スキル・接続先（Notionなど）の構成がバラバラで、同じチームでも使えるコンテキストが違うという図が提示されました。

補足として、①には「個人設定もあるが、管理者設定があるとベスト」、③には「品質ゲートは個人ではなく、組織で設ける」という言葉が添えられていました。

④の「人間が理解できないものは直せない」は、この日いちばん短くて強い一文だったと思います。

🐰 5. CodeRabbit での AI 利用例

CodeRabbit, Inc. 自体は、従業員270名程度（うちエンジニアが100名ほど）、ほぼリモートワーク（US、ベンガルールにオフィス）、日本支社なし、「トークンマキシングな企業」とのことでした。

LLMルーティング

  1. OpenAI / Anthropic / NVIDIA Nemotron などを利用
  2. 用途（要約、調査、レビューなど）に応じてモデルを選択
  3. 高いから・最新だから優秀とは限らない

3点目を裏付けるデータとして、自社ブログの Opus 5 評価結果が提示されました。

指標 プロダクション基準（ベースライン） Opus 5 x-high
既知の問題の検出率 61.1% 55.2%（減少）
アクション可能な精度 35.2% 39.3%（向上）
ニットピック数 23件 92件（約4倍）
フルストリーム精度 32.8% 28.6%（低下）

「ニットピックの長い尾が精度の優位性をひっくり返す」

モデル比較の散布図（横軸：より多くの既知の問題を検出／縦軸：よりクリーンで実用的な指摘群）も出ていました。

モデル 検出率 精度 特徴
GPT-5.6 Sol 69.7% 31.6% 再現率寄り・クリーンアップ系が多い
Production baseline 61.1% 35.2% 細かい指摘23件、全体精度32.8%
Opus 4.8 約61% 33.8% バランス型レビュー・エージェント的な強み
Opus 5 x-high 55.2% 39.3% 精度重視の実用的な指摘。細かい指摘92件、全体ストリームはノイズ多めで全体精度28.6%
GPT-5.6 Terra 52.5% 35.7% 出力量は少なめ・143コメント
Sonnet 5 約50-51% 38-40% 細かい指摘が多い

⚠️ このデータには「参考比較のみ。評価間で EP セット、審査者、プロンプト、ベースライン、パイプラインのバージョンが変更されている」という但し書きが付いていました。モデル同士を同一条件で比べた結果ではない点に注意が必要です。

それでも、レビューという特定用途では「最新・最上位のモデルを入れれば良くなる」とは限らない、という実例として説得力がありました。指摘の量が増えると、正しい指摘の価値が埋もれるという話です。

利用シーン3つ

場面 内容
チャット（Slack） CodeRabbit という Slack エージェント。Datadog / Sentry / Salesforce / Google Drive と接続。Slackで対話したり、Pylonに送られてきた問い合わせを元に調査、Issue作成、PR作成まで行う
Issue（GitHub） Issueを基に実装計画を作成（CodeRabbit Plan）。現在のコードベース、過去のIssue、ドキュメントなどを参照して計画を作成。誰でもコメントし、実装計画を改善できる
レビュー（CodeRabbit） PRレビュー、CLIやVS Code機能拡張でローカルレビュー

デモでは Discord 上で @CodeRabbit please start an /automation that will post the latest changes from the changelog here weekly on Monday's 9am PST と依頼し、週次changelog投稿の automation 案（Title / Task / Playbook / Standing approval）を提示させて「Create automation」で確定する流れが実演されました。

CodeRabbit Plan のメリットは4つです。

  1. 普段使っているツール（GitHub / GitLab / Linear など）で動く
  2. 皆の見える場所（Issue）で利用
  3. 接続するサービス（Context）は管理者が設定
  4. 後で参照、振り返りができる

4つの柱の②「全員の見られる場所でAIを利用」が、そのまま製品設計に落ちています。

レビューの2つの側面

レビューにはレビュイー（プログラマー＝レビューを受ける人）とレビュアー（シニアエンジニア＝レビューをする人）の2つの側面があり、CodeRabbit は次のように対応します。

# 対応
1 よくあるミス、問題は事前に解決 —— 40+のLinter/SAST、Webクエリーで最新情報を収集
2 人が見るようにレビュー —— Issue、ドキュメント、過去のコメントでコンテキストを補足
3 人がPRを理解するのに必要な情報を提示 —— 概要、変更ファイルグループ、シーケンス図、Change Stack

結果として「レビュアーの工数を半分に」。

ROI の可視化

ダッシュボードは4面で構成されていました。

面 内容
時間（Time Metrics） Time to Merge の Average 2.76 days / Median 1.87 hour / P75 9.89 hour / P90 14.7 hour、Weekly Review-Ready → Merge Time の推移
品質（Quality Metrics） Acceptance Rate by Severity は Minor 78.1% / Critical 100% / Major 86.9% / Trivial 37.5%、Review Comment Count by Severity（Posted vs Accepted）
ナレッジベース（Knowledge Base） Path-based Instructions Usage は PR Coverage 76.2% / Times Applied 483、Learnings Created 48（New 10）、Learnings Usage は PR Coverage 33.3% / Times Applied 130
マージ前チェック（Pre-merge Checks） Custom Pre-merge Checks Configured 4、Pre-Merge Check Runs は Built-in 236 / Custom 38、週次のPass/Fail/Inconclusive推移

Acceptance Rate が Severity 別に出ていて、Critical 100% に対して Trivial 37.5% という差があるのが実態を表しています。重要な指摘は受け入れられ、細かい指摘は半分以上流される、という数字です。これは先ほどの「ニットピックの長い尾」の話と地続きです。

まとめ

メッセージ
🥕 AI利用は個人技からチーム設計へ
🩴 開発生産性向上の鍵はレビュー
⛵ キャラクターの名前は Hoppy
🐰 でチームのAI開発生産性を高めよう！

5️⃣ KDDIアジャイル開発センター株式会社「AI時代の強いチームの作り方」

2日目最後のセッションです。登壇は吉田 祐樹 氏（KDDIアジャイル開発センター株式会社 Principal Engineer）。15年以上アジャイル開発の現場にいて、全体のAI駆動開発推進リードを務められています。

📎 このセッションも内容が濃かったため、別途、単独記事として詳しくまとめています。ここでは要点に絞ります。

😵 「最近みんなの心すり減ってません？」

セッションはこの問いかけから始まりました。AI利用の最前線である部署でも、みんないっぱいいっぱいだそうです。

役割 起きていること
ソフトウェアエンジニア 「コードは増えた。確認が終わらない」
スクラムマスター 「記録は増えた。対話が減った」
プロダクトオーナー 「案は増えた。決められない」

3つとも前半が「増えた」で、後半が「詰まった」になっています。

🧪 「AIの力でチームを縮小出来る」、そうとも限らない

多くの開発会社が「6人 → 2人」を検討しています。その後押しになる事例として、Anthropic 主催のハッカソンで非エンジニアが優勝した話が紹介されました（優勝はカリフォルニア州の弁護士マイク・ブラウン氏。ソフトウェアのリリース経験はなく、コードを一行も書かず、読まずに Claude Code でアプリを作成。3位に心臓専門医、別の受賞者に道路技術者）。

そのうえで、思考実験が置かれます。「AIを最大限上手く活用出来た時、人の数を1/3にすることが出来ると仮定します」。理論的には、6名がめっちゃ有能なら短期的には恐らく出来る。しかし——「そのチーム、サステナブル（持続可能）ですか？」

# 問題 中身
1 休み・退職に弱すぎる 2人チームは1人欠けた瞬間に回らない。AIを使える人に判断や文脈が寄るほど、単なる人数以上にリスクが大きい
2 シニアが抜けられない構造になる 効率化したつもりが、結果的にはシニア依存を濃縮しているだけになる可能性がある
3 次の担い手が育たない シニア2人がAIで高速に片づけるほど、若手やミドルが横で学ぶ機会が減る。成果物は作れても、強いチームを再生産できない

対案はこうでした。

パターン 完成品 コメント
AI利用なし 6人 ×1 これまで
AI多用 6人 × AI ×3 🎯 「今日はこっち」
AI多用 2人 × AI ×1 「世界はこっち」

⚖️ 弱いチームは速く壊れ、強いチームは速く学ぶ

「AI時代、弱いチームは速く壊れ、強いチームは速く学ぶ」（※DORA Research: 2025 を参照）

弱いチーム 強いチーム
曖昧な仕様／形式的レビュー／弱いテスト／知見が閉じる 小さく試す／レビューで学ぶ／テストで守る／失敗を共有
→ ひび割れた成果物が流れ続ける → 健全な成果物が流れ続ける

中央に置かれていたのは「AIはチームを増幅する」でした。結論は「AIを活かす鍵 ＝ 強いチームづくり」です。

🛠️ AI-DLC と、設計8：実装2

KAG では AI-DLC をスクラムの上に乗せて運用しています。AI-DLC には方法論の原典である White Paper（3フェーズ・10原則）と、現行実装の Workflows 2.0（5フェーズ・32ステージ・14エージェント・Specification 9原則）の2系統があり、両方を参考にアレンジして実践しているそうです。

そして、かけている時間の比率が「設計8：実装2」。

「以前までは『実装してみないとわからない』だったものがAI駆動になって設計フェーズで議論出来るようになった、且つAIのお陰で実装にかける工数を圧縮できたこともあり設計に重きを置けるようになった」

運用は、ボルトゴールを決める → AIがメンバーカードを配る形でモブを編成（3名/2名/3名。「ジュニア・兼務は3人モブ」「3回連続で同じ人と組まない」「ボルト中は固定」）→ 3モブで並列モブワーク → ボルト振り返り、というサイクルです。

🚀 フィーチャーモブ

結論は「AI時代のフィーチャーチーム ＝ フィーチャーモブ」でした。顧客価値をE2Eで完結する、動的に編成された2〜3名体制のモブです。

効果 中身
意思決定がスムーズ 自モブで決めてから全体に投げかけて合意。"No"と言う人がいなければ合意
開発のリードタイムが極小 開発ブランチは main 直Push（PR利用なし＝レビュー待ち時間ゼロ）。デプロイは環境ブランチで、本番のみ承認制
1人のエースに頼らない ＆ 誰が休んでも進む 常に複数人で意思決定する習慣。目指すのは「全員が1人で全部やれるようになる」

最後は「AIがコードを書く時代、求められるのは『判断力』と『守備範囲の広さ』」という話で、コヴィー『7つの習慣』の「省略できる段階は一つもない」という一節が引かれて締めくくられました。

🔍 2日目を通して見えたもの

5セッションを並べると、いくつか共通する線が見えてきました。

① 問いが「作れるか」から「信頼できるか」へ移った

Replit がこれを正面から言語化していましたが（"Can AI build this?" → "Can I trust what AI builds?"）、実は5セッションとも同じ場所を話しています。

セッション どこに現れたか
GitHub Quality & Security / Enterprise Trust をレイヤーに含む「The Agent-Native Engineering System」。「委ねたい仕事」12個がすべて確認まで含む書き方
Replit Defense in Depth の6レイヤーと責任共有モデル
富士通株式会社 Multi-layer Quality Control、Review Hub、「説明責任と承認責任は人に残る」
CodeRabbit Agentic Change Management（検証・優先順位付け・理解・承認・保守まで一貫して管理）
KDDIアジャイル開発センター株式会社 「速く作れる ＝ 安心安全だといつから錯覚していた？」と8つの問い

作る速度の話は、もうどのセッションでも主役ではありませんでした。

② 伸びたものと、伸びなかったもの

Replit の Veracode 引用と、CodeRabbit の引用が、独立した調査でありながら同じ方向を指していました。

出所 数字
Replit（Veracode 2026 Spring） 構文の正しさ 95%超（大きく改善）／セキュリティ試験の合格率 55%（2年間ほぼ横ばい）
CodeRabbit（GenAI and Code Security） 全テストケースの 45%に脆弱性。新モデルを利用しても改善されず

「55%が合格」と「45%に脆弱性」は裏表の関係にあり、しかも両方とも「新しいモデルにしても改善しない」と付いています。

Replit の言葉を借りれば、伸びなかった側を埋めるのは仕組みの仕事です。

③ ボトルネックはレビューに移った

CodeRabbit がここを主題にしていましたが、他のセッションも同じ場所に手を入れていました。

セッション レビューまわりの打ち手
GitHub 開発ルールは「1. テストの整備 2. コードレビューの徹底」の2つだけ。テスト54%のリポジトリ、E2E 2分→25秒、CCR の継続強化
Replit 公開前スキャンの強制実行（LAYER 2）。ただしスキャン結果のレビューと修正の適用は利用者側の責任
富士通株式会社 Review Hub —— AIが先にレビューし、判断材料を整理し、人が最終判断する
CodeRabbit 「レビュアーの工数を半分に」。約9割のレビュー担当が負担増を実感
KDDIアジャイル開発センター株式会社 PR を使わず main 直Push。モブで常時レビューしているから成立する

面白いのは、KDDIアジャイル開発センター株式会社 だけ逆方向に見えることです。PR という非同期のレビュー機構をなくしています。ただしこれは、モブワークでその場に常に複数人がいる前提とセットです。レビューを減らしたのではなく、レビューの置き場所を変えた形になります。

④ 個人技からチーム設計へ

CodeRabbit の「知見を個人に閉じるのではなく、チームで共有する」と、KAG の「フィーチャーモブ」は、違う言葉で同じことを言っています。

  • CodeRabbit: 開発者ごとにAIツール・MCP・スキル・接続先がバラバラで、同じチームでも使えるコンテキストが違う → 管理者設定と組織の品質ゲートへ
  • KAG: AIを使える人に判断と文脈が寄る → モブの編成をAIに配らせ、3回連続で同じ人と組ませない

どちらも、AIの使い方が上手い人が生む「濃縮」を、構造で薄めようとしています。

⑤ 数字の温度差

いちばん考えさせられたのが、同じ日に出てきた数字の向きが真逆だったことです。

出所 数字
GitHub 20人チームで 1000PRマージ/週、Multi-agent コホートは 23.5 PR/user/month（Passive は 1.8）
CodeRabbit（METR） AI利用で24%高速化すると予測していたが、実際は 19%低下
CodeRabbit（Does GenAI Improve...） Copilot導入でバグ数が41%増加、PRサイクルタイムは変化なし

どちらも本当なのだと思います。GitHub の側には、テストが54%を占めるリポジトリ、2分を25秒にしたE2E、全面適用したリンター、明示的な作業単位の設計がありました。同じツールを入れても、受け皿の有無で結果が逆向きになるということかもしれません。

この構図は、富士通の「AI-Ready Engineering ——『仕込み』の成熟度が自動化の精度を決める」と、そのまま同じことを言っています。GitHub が PR で見せた4つの打ち手（テストキャッシュ、シャーディング、リポジトリ分割、リンター全面適用）は、AI-Ready Engineering の実例そのものです。

📝 まとめ

2日目の5セッションを一言ずつにすると、こうなります。

# セッション 一言
1 GitHub エージェントが働ける場所を、6レイヤーの「システム」として作り直している
2 Replit 「デフォルトで安全」を、6レイヤーの多層防御と責任共有モデルで具体化する
3 富士通 一気通貫の自律実行より、その手前の「仕込み」が精度を決める
4 CodeRabbit ボトルネックはレビューに移った。個人技ではなく組織の設計で解く
5 KDDIアジャイル開発センター株式会社 弱いチームは速く壊れ、強いチームは速く学ぶ。人を減らさずに成果を増やす

1日目にもガバナンスやレビューの話は出ていましたが（そもそも1セッションが丸ごとガバナンスの話でした）、2日目は5セッションとも「作った後どうするか」に重心が寄っていました。検証、承認、記録、権限、そして誰がそれを持ち続けるのか。登壇企業の立ち位置がこれだけ違うのに、手を入れている場所が揃っていたのが印象的です。

そして、どのセッションも「AIを入れれば速くなる」という言い方をしていませんでした。GitHub は週1000PRの裏側にテスト54%のリポジトリを置いて説明し、Replit は「デフォルトで安全は、何もしなくていいではない」と線を引き、富士通は「仕込みの成熟度が精度を決める」と言い、CodeRabbit は19%低下という数字を自分から出し、KAG は「そのチーム、サステナブルですか？」と問い返しました。

速く作れることは前提になり、そのうえで何を用意しているかが問われている。2日間を通して、そういう一日でした。

🔗 参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?