快手、AI 開発プロセスの革新と組織変革を報告

快手技術 2026-08-06 18:21 北京

6 ヶ月、役割の再定義、協働の加速——快手 AI 生産力体系が完成する背景。

本稿は、快手が 2026 年上半期に「開発効率」から「AI 生産力体系」へと移行する過程を総括したものです。マクロな体系構築や方法論、思考プロセスから、ミクロな実践事例まで幅広く取り上げています。

2026 年 8 月、私たちはこの内容を正式に業界へ公開します。快手の実践がより多くの関係者に知れ渡り、交流と業界発展の一助となれば幸いです。また、2026 年後半には「AI 生産力」体系の導入をさらに深化させ、快手全体でより大きな生産性の変革をもたらすことを目指しています。

01. 振り返り：3 年間で 3 つのステップ、個人から組織へ AI で効率化への道筋を見出す

2026 年 2 月、『快手：万人規模組織における AI 開発パターンの飛躍』を発表しました。ここでは 2023 年から 2025 年までの歩みを振り返り、業界で初めて「AI による効率化の罠」を指摘しています。

それは、「AI 開発ツールの利用＝個人の生産性向上≠組織全体の生産性向上」という関係性です。

まず、快手の実践プロセスを簡単に振り返っておきましょう。

2025 年末までに、私たちは以下のような成果を収めました。

ベンチマークチームでの探索と実践を通じて、AI 開発パターンのアップグレードへの道筋を見出し、個人レベルから組織レベルへの効率化の壁を乗り越えることができました。これに基づき、「AI 開発パターンの実践フレームワーク」を発表しました（図参照）。さらに、2026 年には L2 レベルの要件が全体の 80% を占めることを目標に掲げ、一人あたりの要件交付数を大幅に引き上げることを目指しています。

また、この道のりで得た実践経験を共有し、より多くの企業の参考になればと考えています。

• 採用率 7.9% から 54% へ：快手のスマートコードレビューの 3 つの段階での進化
• 生成率 8% から 60% へ：快手のスマートテストケース生成システムの 4 つの段階での進化
• 採用率 3% から 80% へ：スマートユニットテスト生成の進化の道
• 検知率 15% から 55% へ：快手のスマートオンコールシステムの進化と導入実践
• AI コーディング製品の進化：補完から人間と機械の対等な協働へ
• スマート UI テストケース生成と実行の 4 つの段階での実践

当時の認識では、これは非常に素晴らしい成果でした。なぜなら、業界の多くの企業がまだ「AI によるコード生成率」に注目していたからです。2026 年 6 月になっても、大手企業の多くがようやく「個人の生産性向上 ≠ 組織全体の生産性向上」という認識に転じ始めたばかりでした。一方、私たちはすでに「チーム全体をいかに AI で効率化するか」というレベルで、検証済みの実践と進展を有していました。

このペースなら、2026 年は全面展開の年となるはずでした。しかし、第 1 四半期に入り、徐々に深く掘り下げていく中で、規模を拡大して複製することが予想以上に難しいことがわかりました。そこで私たちは本格的に原因を探りました。いったいどこに問題があるのか？

1. 問題：ベンチマークチームから全チームへ、難易度が上がる

AI による開発効率化の基盤（実践、測定、プラットフォーム）は整い、ベンチマークチームも成功を収めました。これまでの開発効率改善の普及パターンであれば、次の段階での難易度は低くなるはずです。しかし実際には、L2 レベル以上の需要が一つずつ増えるごとに、以前よりも遥かに多くの労力が必要であることがわかりました。さらにマクロな視点で見ると、L2+ の需要割合は、期待された通り 1 人あたりの需要交付数と比例していませんでした。

問題はどこにあるのでしょうか？マイクロレベルでの調査とマクロレベルでのデータ分析を通じて、この段階における真の課題である 3 つのボトルネックを特定しました。

① 人材：開発者の AI 活用能力が二極化している

2025 年 10 月以降、私たちは全社員を対象に、多くの実践演習、必修講座、AI 関連イベントを実施してきました。マクロな視点では生産性指標は大幅に向上しましたが、詳細を分析すると、明確な二極化が見られました。下の図のように、2025 年 12 月の AI コード生成率を観察した結果、30% の人員が AI コード生成率 40% を達成している一方で、依然として 32% の人員が 10% 未満にとどまっていました。

注：快手社内では「AI コード貢献率」と呼ばれています。分母はすべてのリリースされたコード行数、分子はそのうち AI によって生成されたコード行数です。

② プロセスと役割分担：需要に関与する開発者数が増えるほど、効率化の幅は小さくなる

効率化が顕著なケースとそうでないケースを詳細に分析した結果、需要に関与する人数が効率化の幅を決定することがわかりました。つまり、1 つの需要に関与する開発者の人数が多いほど、効率化の効果は小さくなります。調査結論の詳細は以下の図をご覧ください。

さらに深く掘り下げてみると、AI が開発やテストの速度を確かに向上させた一方で、新たな 3 つのボトルネックが浮き彫りになりました。これらを「AI を活用した要件交付における 3 つの摩擦」とまとめました。

人と人との間の摩擦

AI による効率化はまず局所的に起こります。開発者やテスターの作業時間は確かに短縮されましたが、実際に開発に費やす時間は 1 日のうち約 30% に過ぎず、それ以下の場合さえあります。残りの大半の時間は、要件のすり合わせ、協働コミュニケーション、タスク引き継ぎなどに割かれています。こうした協業コストは、開発効率の向上によって得られる利益をすぐに相殺してしまうのです。

人と開発プロセスとの間の摩擦

多くのチームでは依然として従来の開発フローと役割分担に基づいて要件対応を行っています。要件見積もりも従来通りの慣習に頼ったままです。異なる役割間での切り替えや待ち時間が存在し続けています。例えば、AI を活用して素早く開発を完了したフロントエンドエンジニアがいても、バックエンドの開発が終わっていなければ、そのエンジニアは他のタスクへ移り、バックエンドが完了するまで待機します。

人と AI との間の摩擦

AI を導入しても、すぐに人間が業務を AI に委ねられるわけではありません。AI が真に力を発揮するためには、人間側も多大な時間と労力を投入する必要があります。調査では、AI 活用能力が平均的な開発者が要件開発プロセスにおける効率の「ブラックホール」と化すことが判明しました。実際の現場では、以下の 4 つの典型的なケースが見られます。

• 人工による補完: AI と開発システムが完全に連携していない場合、開発者は両者の架け橋となり、情報を絶えず転送する必要があります。
• 文脈のすり合わせ: AI は業務背景を理解しておらず、要件の文脈を本能的に把握することもできません。そのため、開発者は文脈を整備・補足・伝達し、システム間の「運搬役」として機能させなければなりません。
• 検証と修正: AI は数分でコードを生成できますが、そのコードが正しく業務要件を満たしているかを検証するには、数時間乃至それ以上の時間を要することがあります。AI による生成と人間による検証の間には、明らかな速度の非対称性が存在します。
• 能力境界の判断: 開発者が AI の能力範囲について確固たる認識を持っていない場合、AI を過小評価すれば本来得られるはずの効率化を見逃し、過大評価すれば手戻りや繰り返しの修正を招くことになります。

以上のように、これら 3 つの摩擦が重なることで、「要件開発に関わる人数が増えるほど、効率化の効果が小さくなる」という普遍的な現象が生じています。

③ 事業特性と組織構造：AI 活用におけるベストプラクティスは存在するが、規模拡大は困難

AI による開発パラダイム転換において高い成果（交付効率や要件処理量の大幅向上）を収めているのは、主に「事業・製品・研究開発の閉じたループ型」チームです。つまり、事業担当、プロダクトマネージャー、開発者（フロントエンド、バックエンド）、テスターなどの役割がすべて 1 つの組織内に統合されているケースです。AI パラダイムの導入後、彼らは単に開発手法やツールが更新されるだけでなく、組織構造、プロセス、役割分担そのものも変化しています。さらに、一部のチームでは「事業」そのものの性質も変化しています。例えば、従来の SaaS プラットフォーム提供から、Agent を活用した AI サービス提供へとシフトするケースです。（この信号は特筆に値します。開発方法が変わるだけでなく、顧客に届けるもの自体も変わっているのです。この変化は後の章で再度登場し、L3 の理解の鍵となります）

一方、事業、製品、研究開発がそれぞれ独立したチームとして存在する「サイロ型」の組織構造では、期待通りの効率化効果を達成するのは非常に困難です。

帰結: 照明が届く場所では成果を上げていますが、私たちを阻んでいるのは、光が届かない組織と人なのです。

上記の図と、前述した 3 つの主要な課題を踏まえて AI 開発パラダイムの進化案を見直すと、我々が以前設計したフレームワークには一つの誤解が含まれていたことがわかります。それは、「開発プロセスや役割分担は不変である」という前提に立っていたことです。その前提のもとで、AI を活用した効率化の実践、プラットフォームの構築、そして効果測定の枠組みを提供していました。

しかし現在、新たなボトルネックが、我々が以前カバーしきれなかった領域——すなわち開発組織を構成する「人」、プロセスと役割分担、そして組織構造そのもの——に現れています。

問題は、我々のフレームワークの盲点に潜んでいました。

ソフトウェア業界には一つの法則があります。すなわち、「業務の特徴がソフトウェアアーキテクチャと組織形態を決定し、それがさらに開発パラダイムを規定する。そしてその開発パラダイムが、開発プロセスや手法、エンジニアリングツールのあり方に影響を与える」というものです。

我々はこれまで AI 開発パラダイムの進化について研究を重ねてきましたが、この法則の「右側」——つまりツールやプロセスの最適化——で解決策を探していました。しかし、解決策を見つけた後で気づいたのは、より決定的なボトルネックが「左側」、すなわち組織そのものの構造にあるということです。

明らかに、今回の AI の台頭は、ビジネスと開発組織に与える影響の度合いにおいて過去とは全く異なります。我々は長い間、この課題について検討を続けてきましたが、確かな手掛かりは見つかりませんでした。しかし、60 年前の歴史を振り返った瞬間、道筋が見えてきました。

03. 鏡：銀行業は 60 年前にすでにその道を歩んでいる

私はあえて銀行業を「鏡」として選びました。なぜなら、我々が今日直面している課題と全く同じものが、60 年前の銀行業界でも既に完走済みだからです。

L0 → L1（1960 年代）：コンピュータ——機械による手作業の代替と内部効率化、しかし組織は不変

1960 年代半ば、米国の大手商業銀行数社がほぼ同時に決断を下しました。それは、IBM の大型メインフレームシステムに巨額の投資を行い、導入することです。

これにより、窓口担当者の目の前にあったのはもはや手書きの帳簿ではありませんでした。預金残高の確認は、分厚い冊子を開いて探す作業から、キーボードを数回叩くだけの行為へと変わりました。計算速度は 10 倍以上に向上したのです。

しかし、もしその当時、銀行支店の裏側にある事務室を訪ねたとしたら、そこには何も変化がないことに気づいたでしょう。支店長のオフィスも同様です。融資の承認プロセスは、依然として昔ながらのチェーン状のフローをたどっていました。申請書類は窓口担当から課長へ、次に副支店長へ、そして最終的に支店長が署名して完了します。一つの意思決定が下されるまで、最短でも 3 日、最長では 1 週間を要しました。

コンピュータの導入により「記帳」のスピードは劇的に向上しましたが、「業務承認」にかかる時間は、10 年前と全く同じでした。

すべての銀行が一斉にコンピュータを導入した結果、スタートラインが全体的に前倒しになっただけで、各社間の競争優位性の差は変わりませんでした。あの当時の機械は、本質的には「より高速なそろばん」に過ぎなかったのです。

L0 から L1 への移行は、生産性が向上しても組織が変わらなければ意味がありません。これは単に既存の業務を加速させるだけのことです。

L1 から L2（1970 年代）：ATM の登場——預金・出金の全工程が自動化され、機械が直接ユーザーと対峙するようになりました。しかし、この技術革新には組織の変革が伴わなければなりません。

それから十年後、ATM が現れました。ATM は人間に「より速く」させるための道具ではありません。それまで人間しかできなかった預金や出金を機械が担うようになったのです。つまり、同じ銀行でも、より少ない人員で同等のサービスを提供できるようになりました。窓口担当者は 10 人から 6 人に減らしつつ、提供できるサービスの量はむしろ増加したのです。

しかし、この技術の本質的な影響は単なる人員削減ではありません。重要なのは「組織が変化しなければならない」という点です。

• 支店の役割が変わりました：もはや「人が来る場所」ではなく、「ATM と窓口担当者が組み合わさったサービス拠点」へと変貌しました。
• サービス形態が変わりました：24 時間対応が可能になり、支店のシフト体制を見直す必要が生じました。
• 顧客との関係性が変わりました：顧客は必ずしも来店する必要がなくなり、アクセス手段が一つだけではありませんでした。
• チーム規模が変わりました：より少ない人数でより多くの業務をこなすため、役割分担のあり方自体を調整しなければなりませんでした。

しかし、すべての銀行がこの機会を捉えたわけではありません。その中で、組織の適応を徹底したのがシティグループ（Citibank）です。彼らは単に ATM を導入して人員を削減しただけではありません。ATM を顧客接点として再定義し、支店の運営方法自体を根本から設計し直しました。24 時間稼働する ATM ネットワークを全市に展開し、支店の役割を「唯一の入口」から「サービス選択肢の一つ」へと転換させ、業務フローも再構築したのです。

1977 年のニューヨーク大雪の際、多くの銀行支店が閉鎖を余儀なくされた中、シティグループの ATM は通常通り稼働し続けました。その結果、大量の預金者が当週中に預金を行うことになりました。1977 年から 1981 年にかけて、シティグループのニューヨークにおける個人預金市場シェアは 4% から 13% に拡大し、約 3 倍の伸びを記録しました。

一方、人員削減のみを行って組織変革を怠った地域貯蓄銀行では、市場シェアがじわじわと削られ続けました。その結果、多くの行が 1980 年代に合併や倒産へと追い込まれました。

L1 から L2 への移行における核心は、AI や機械がより多くの業務を担い、より少ない人数でより多くの成果を出すようになる点です。しかし、組織が変化しなければ L1 のまま止まってしまいます。適応の度合いが、最終的な効率化の規模を決定します。

なお、この段階において銀行が提供する業務の本質は変わっていません。依然として預金・出金・融資が中心ですが、サービスチャネルが増え、組織効率が向上したという点に留意してください。

L2 → L3（1990 年代〜2010 年代）：ネットバンキングとモバイル決済——システムが自律的に処理し、事業形態と組織が同時に根本から再構築される

1990 年代にネットバンキングが登場した際、真に変化を遂げた銀行は「ATM をより良くする」ことではなく、「銀行と顧客の関係性そのもの」を再定義しました。

例えば、出張先で少額の融資を申請したい顧客が、ノートパソコンから申請書を提出します。すると約 30 秒後にはシステムから審査結果が返ってきます。かつては店舗に足を運び書類を提出し、2〜4 週間待たねばなりませんでした。

なぜ 30 秒で結果が出るのか。それは、従来人間しか行えなかった「審査」という業務を、システムが自律的に遂行するようになったからです。

• 審査ルールはコード化され、リスク管理のノウハウはモデルとなりました。かつて「情報の中継点」だった審査担当者は、「書類をチェックする人」から「ルールを設計する人」へと役割を変えました。

• 支店長という存在も、地域ごとの意思決定中枢から「地域のサービスマネージャー」へと変容しました。これは能力不足によるものではなく、情報が彼らを介して中継される必要がなくなったからです。システムが以前支店長が行っていた業務を担うようになったのです。

顧客、窓口担当者、審査員、リスク管理部門、運営チームなど、すべての関係者が同じデジタル・チェーン上で動作するようになりました。中間層が排除され、初めてスピードが実現したのです。

しかし、ネットバンキングがどれだけ優秀であっても、銀行は依然として「人が行く場所」という認識でした。2010 年代に入り、スマートフォンが登場して銀行の姿は劇的に変貌しました。決済は買い物の中に組み込まれ、資産運用はスマホを操作する行為に溶け込み、融資は消費の瞬間に埋め込まれました。銀行はもはや「人が行く場所」ではなく、「至る所に存在する能力」となったのです。

組織構造も同様に変化しました。地域ごとの分工から、シナリオやユーザー・ジャーニー（顧客体験）に基づいた設計へと移行したのです。「コンピュータで業務効率を上げている」という言葉はもう使われなくなりました。なぜなら、コンピュータはすでに水や電気のようなインフラストラクチャーであり、単なる効率化ツールではなくなったからです。

ネットバンキングとモバイル決済には一貫性があります。核心となるロジックは同じです。「システム（AI）が自律的に業務を遂行する」ことで、事業形態そのものが変化し、役割が再定義され、組織の再構築が必要となるのです。

L2 から L3 への移行には、本質的な違いがあります。L2 では組織形態は変わりますが、事業の本質は変わりません。一方、L3 では事業形態と組織形態の両方が同時に変化し、互いに牽引し合いながら螺旋状に上昇していきます。事業形態が変わったからこそ組織の再構築が必要となり、逆に組織が再構築されたからこそ、新しい事業形態が実現するのです。

銀行に限らず、私たちにも同じ法則が当てはまります。L1 でツールが変化し、L2 で組織が変化し、L3 では事業と組織が同時に変化するのです。

まず銀行業界を見てみましょう。

同じ論理を AI 開発のあり方の変化に当てはめてみると、以下のようになります。

この 2 つの表を並べて見ると、明確な法則が見えてきます。

L0 から L1 へ：技術は進化しますが、組織や役割、ビジネスモデルには変化がありません。より優れたツールを使っても、組織が速くなるわけではありません。

L1 から L2 へ：ワークフローと人の役割、そして組織の形態に一部の変化が生じます。しかし、ビジネスそのものの形は変わりません。銀行では依然として預金・出金・融資が行われ、私たちが提供しているのはソフトウェアの機能です。L2 の鍵となるのは「組織が技術変化に合わせて変容すること」であり、その変化の度合いが効率向上の幅を決定します。

L2 から L3 へ：これは次元の異なる話です。組織形態の変化だけでなく、ビジネスモデル自体も変わります。銀行は「行く場所」から「至る所に存在する能力」へと変貌します。この変化が起きると、プロセスや組織、役割といった他のすべての要素が、強制的に再構築を迫られます。

L3 は L2 の延長ではありません。根本的な問いが変わったのです。

これらの歴史を振り返れば、私たちが直面している課題も自ずと見えてきます。

L2 段階では、組織はどのように変えるべきか？

L3 段階では、ビジネスと組織の両方が変化する中で、どのような図景が描かれるのか？

これこそが、2026 年に私たちが答えを見つけなければならない真の課題です。

体系の進化：「開発効率」の先にあるのは「AI 生産性」の始まり

問いが変われば、道も新たに開く必要があります。「いかに開発組織を加速させるか」ではなく、「いかに AI でビジネスと組織を再構築するか」という視点に立つのです。

そこで、新しい問いに基づき、再び道筋を推論しました。

再推論：旧来のアプローチは開発部門からは進まなかった。新アプローチは全社員から始まる

開発部門の視点では、道筋はこうなります。「AI × ツール」→「AI × 開発者」→「開発組織の変革」。しかしこのルートには限界があり、開発部門だけで全体の流れを動かすことはできません。

一方、組織全体の視点では、道筋は以下のようになります。「AI × ツール」→「AI × 全社員」→「AI × チーム」→「AI × 組織」。

ここで重要なのは、第 2 ステップです。そこでは「AI × 開発者」ではなく、「AI × 全社員」という転換が起きます。全員を AI 化して初めて、この連鎖は真に再構築されます——これが L2 です。そして、ビジネスそのものの AI 化が可能になるのは、L3 の段階からです。

この一歩の変化こそが、根本的な問いそのものを変えたのです。

「いかに開発を速くするか」ではなく、組織の一人ひとりとチームに AI 能力を継続的に供給し、より大きな変革を促すことこそが問われています。

これは技術的な課題ではありません。供給の課題です。例えて言えば、従来の人力アウトソーシングは、人の能力を商品化して必要なチームへ按需（必要に応じて）供給し、コスト削減と柔軟性の向上を図るものです。AI も同じことをしています。ただし、供給するのは人力ではなく AI 能力です。AI 能力を商品化し、各役割やチーム、組織全体に按需で供給するのです。

したがって、私たちが取り組むべき課題は「開発効率」から「AI パフォーマンス（AI Productivity）」へとシフトする必要があります。これは AI 能力を中核的な供給源とし、組織内のすべての人員とチームを対象に、個人の生産性向上、チームの協働効率、そして業務納品の品質を体系的に高めることを目指すものです。

単なる名称の変更ではありません。目標も、供給側も変わりました。これに伴い、アプローチや製品形態、さらには組織構造そのものの再構築が不可欠となります。

道は険しく長い：業界全体で誰も成功できない三つの壁

課題の定義が変わり、道筋が明確になったからといって、それが容易になるわけではありません。大手企業も多数存在し、高知能な組織も数多くあるのに、なぜ現時点で真に成功した事例が生まれていないのでしょうか？

それは「やりたくない」からではありません。各段階にはそれぞれ異なる壁（鴻溝）が存在しているからです。

三つの段階、三つの壁。それぞれに異なる乗り越え方があるにもかかわらず、なぜ突破できないのか？私たちが業界の交流を通じて把握した現状は以下の通りです。

L0 → L1：ツールの壁

大手企業内部では AI 製品が「百団大戦」状態にあります。各 AI 製品が社内競争を繰り広げ、機能や運用でユーザー数を争っているため、合力を生むことが困難です。これにより、以下の三つの問題が生じます。

• 問題 1：社内の AI インフラが分断されており、一見すると何でも揃っているように見えますが、実際には雑多で純粋さに欠け、博打に偏って専門性が不足しています。そのため、深みのある技術や製品課題に焦点を当てることが難しく、会社レベルのスキルや知識といった AI アセットを蓄積することができません。
• 問題 2：それぞれの異なる役割において「いかに AI を活用して効率化するか」を検討する原動力が欠如しており、ましてや社統一的な AI 活用ベストプラクティスの提供など到底不可能です。
• 問題 3：AI 製品のコスト（トークン量）はユーザー数に比例するため、内部利用が増えればコストも膨らみます。しかし、内部ユーザーに対する効率化の価値が明確でないため、そのコストを各事業ラインへ按分することが困難です。結果として、各 AI 製品が自走するコスト「負債」として残ってしまいます。

L1 → L2：組織の壁

仮に社内ツールが統一されたとしても、次に立ちはだかるのが組織的な課題です。ここには二つの問題があります。

• 問題 1：AI インフラチームと事業・プロダクト開発チームの関係性における最大の難所はトークンコストです。AI インフラチームはより多くの事業ラインや人員に利用を促し、コストを按分したいと考えています。一方、事業ラインの視点では「同じ予算なら業界最高のツールを使い、ユーザー満足度と効率を最大化すべきだ」という判断は極めて合理的です。しかし、このように行動すれば、会社全体の AI インフラとアセットの統一プロセスが阻害されてしまいます。
• 問題 2：事業・プロダクト開発チームの組織構造そのものの問題です。大手企業では一般的に垂直型のサイロ（煙突型）組織であり、製品、運営、フロントエンド、バックエンドごとに上位リーダーが担当しています。これらのチーム間の部門壁を打破し、協働して新たなモデルを探求し、再編成された協業プロセスを確立しようとすれば、利益配分の見直しを迫られるため、極めて強力な組織能力と管理の決断力が求められます。

L2 → L3：事業の壁

組織の壁を克服した後に初めて、「いかに事業を AI 化するか」が本格的に課題として浮上します。これは大手企業にとってさらに困難な登竜門です。

各壁には全く異なる解決策が必要です。まさにこのことが、なぜ「開発効率」という枠組みを超えて課題の定義そのものを変えなければならないのかを示しています。これらの問題はすべて、「開発効率」の範囲内では解決できない領域にあるからです。

したがって、これらの三つの溝を真に越えるには、単にツールを改良するだけでは不十分です。必要なのは、課題設定から体系全体に至るまでの全面的な再構築です。これが快手の「AI 生産力」体系が誕生した背景にあります。

解決策：快手「AI 生産力」体系による三つの溝への五段階アプローチ

快手はこの三つの溝をどのように越えるのでしょうか？新課題と新経路の下で具体化された、快手の「AI 生産力」体系の全体像を見てみましょう。

五段階の道筋：AI 能力がツールから組織へ浸透する全景図

道筋は目標であり、戦術は手段です。この五段階を真に推進するためには、並行して三つの主要な軸を進めていきます。

実行戦略：組織変革 × AI インフラ × 制度進化の三本柱

05、L2 から L3 への新領域探索：溝を越え、「開発効率の向上」から「組織の飛躍へ」（2026 年上期）

体系設計は整いました。次は、全社的な組織を巻き込んで前進する方法です。AI パラダイムシフトにおいては研究開発部門が最も先行しているため、今回は L3 レベルにおける研究開発部門の新たな実践に焦点を当ててご紹介します。

全社の主要技術責任者による集中議論と意思決定の結果、「主航道」と「快速路」の二重軌道戦略を採用しました。

• 主航道：各事業ラインは引き続き AI 開発パラダイムの大規模な移行を進め、L2+ の要件比率を 80% に達させることを目指します。これは下限を引き上げる取り組みです。

• 快速路：30 以上の「AI プレミアムチーム」を選抜し、社内異なる事業やタイプのチームを網羅します。規模は 10 人から 100 人のチームまで様々で、境界線を取り払って AI 組織進化の上限を探求します。これは二つの問いへの回答を探るためのものです：L2 の上限はどこにあるのか？そして L3 の姿とは何かです（これらのチームは L2 から L3 へ移行することも、あるいは L1 から直接 L3 へ飛躍することも可能です）。

「快速路」は 2026 年上期に必ず開拓しなければならない新道であり、その実践プロセスを重点的に共有します。

実践前：四つのチームタイプと四つのアプローチ

これらのチームにはそれぞれ特徴があり、一律の手法で探索を進めることはできません。単一のルートに固執すれば上限を見逃し、無秩序な探索では半年かけて方向を誤るリスクがあります。幸いにも評価の結果、各チームがどの道を選ぶかを決定づける二つの制約要因があることが分かりました：

まず重要なのは「チームのタイプ」です。この2つのタイプでは、実践において明確な違いが生じます。

次に重要なのが「納品タイプの違い」です。事業特性やシステムの複雑さが異なるため、AI 化が可能な要件の程度にも大きな差があります。この点でも大きく2つに分類されます。

そこで、「チームタイプ」を X 軸に、「納品タイプ」を Y 軸にとり、全研发团队を4つの象限に分類しました（下図参照）。各象限のチームは、この2つの要因によって制約されるため、目指すべき目標や実践方法は異なります。それぞれの象限で「上限」を探ることで、あまりにも過激すぎたり保守的になりすぎたりするのを防ぎます。

では、このフレームワークにおける実践①〜⑥とは何を指すのでしょうか。実は、これら4つの主要な実践間には相互に変換可能な関係があることがわかったからです。

理論的な枠組みは整いました。ここからは本番の検証、つまり半年間の実戦です。

実践を経て得られた洞察から導き出した法則——それが「開発組織の AI 進化論」です。

半年間にわたる実践と検証を経て、全社内のあらゆるタイプの研发团队に適用可能な、開発組織の AI 化への完全なパスを確立しました。その全体像は以下の通りです。

同時に、実践の現場では4つのチーム間に差異がある一方で、非常に明確な共通点と進化の傾向が見られることが分かりました。

AI ネイティブな組織の変化を、以下の 3 つの事例を通じてより明確に理解していただこう。

注：L3 の事例には機密業務情報が含まれるため、ここでは非敏感なチームの事例を掲載します。各チームの実践プロセスは概ね同様であるため、より詳細な内容をご理解いただけるよう、このアプローチを採用しています。

事例 1：事業化担当チームにおける L2 から L3 への交付モデルの変革

事業化におけるリスク管理は、典型的な高対抗ビジネスです。「企画・運用・研究開発・計算資源・データ分析」など多様な役割の連携が必要で、プロセスも複雑に絡み合っています。黒市場組織が AI を活用して攻撃手段を高度化する中、従来の交付モデルの問題点は単なる「効率の低さ」ではなく、「対抗スピードについていけなくなっている」という根本的な課題へと変化しました。

そこでチームは L2 から L3 への移行を選択し、以下の 3 つのステップで転換を図りました。

1. 価値連鎖の整理
2. SaaS ツールプラットフォームを CLI（コマンドラインインターフェース）化し、さらに Skill（スキル/機能モジュール）化すること
3. AI 知識ベースの構築

これにより統一された入口が形成され、変革後の開発プロセスは「要件の入力と成果物のレビュー」に集約されます。要件理解からコード生成、デプロイ、自己テスト、ステータス遷移に至るまで、すべてを AI が自動で駆動します。その結果、リスク事象に対する迅速な対応が可能となりました。以下に、このチームの AI による開発パラダイムシフトの詳細を示します。

準備段階：チーム能力の AI 化への転換

ステップ 1：チームの中核プロセスを整理する

ステップ 2：関連システムの CLI 化

ステップ 3：コアプロセスをスキル化

ステップ 4：チームの AI 知識基盤を構築する

適用フェーズ：AI が深く関与する納品プロセス

商業化・リスク管理チームの要件納品では、crc-dev-flow というスキルを統一入口として機能させます。これにより、要件理解からコード生成、デプロイ、自己テスト、ステータス遷移に至るまでの一連の流れがシームレスに接続されます。開発者が注力すべきは「要件の入力」と「成果物のレビュー」の 2 点のみです。残りの工程はすべて AI が自動で処理します。

ここでは L2 と L3 の開発プロセスを比較し、開発者の視点からどのような変化が起きたかを見てみましょう。

L2 フェーズ：人間と AI の協働モデル

全社的に KATE プラットフォームへ集約。基本は「人が主体で AI が補助役」という体制で、要件の全体フローを繋ぎます。

L3 フェーズ：人間と AI の協働モデル

全社的に MyFlicker プラットフォームへ集約。「AI が主体となり」要件全体のフローを完結させます。AI がプロセスを推進し、他の開発ツールや知識基盤を活用します。KATE を含むあらゆる開発ツールは CLI 化され、スキルから呼び出される形になります。人間は各工程で最終的な検証（バリデーション）を行います。

注 1：快手 AI 効率化プラットフォームの進化ロードマップ

Kwaipilot（コーディング支援） → CodeFlicker + KATE（AI エンジニア） → MyFlicker（AI 全能ワークパートナー）

注 2：上記 2 つの動画では、機密性の高いコードリポジトリは使用していません。要件納品の全体フローを明確に示すため、具体的な業務コードやアドレスは含まれていないデモ環境を使用しています。

事例 2：企業向けアプリケーションチームにおける「業務」と「組織」の同時変革

企業向けアプリケーション部門（内部行政サービス：会議室管理・シャトルバス管理等）は、従来は 50 名以上の伝統的な機能別組織でした。しかし、業務拡大に伴い製品開発のスケジューリングに過度に依存せざるを得ず、対応が遅く、協働コストも高くなるという課題を抱えていました。

この変革では、2 つの再構築を並行して進めました。

業務形態の変容：

従来の SaaS Web アプリおよびミニプログラムから、スキル（Skill）を介した汎用 AI エージェントへの移行。これにより、ビジネス担当者が自らスキルを開発し、要件に直接対応できるようになりました。

組織形態の再構築：従来の「製品・フロントエンド・バックエンド・テスト」の 4 つの機能別から、「FDE（Frontend Developer）+ PDE（Product Designer/Engineer）+ 全栈エンジニア」による AI-Native な三角構造へと転換。チーム規模は 50 人以上から約 20 人に縮小され、開発コストと協業コストが大幅に削減されました。

このチームにおける AI 開発パラダイムの転換プロセスを以下に解説します。

ビジネスの進化

組織の進化

開発モードの進化

準備段階：チーム能力の AI 化

従来の開発経験（ナレッジ、スキルなど）がエージェント（Agent）に蓄積・統合されました。

応用段階：人間とエージェントの協働による納品

事例 3：千人規模の組織はどのように変化したか？

快手（クァイショウ）の主技術部では、千人規模の開発チームにおける AI 開発パラダイムの転換を実践しました。そこでの核心課題は「AI による個人の生産性向上が、そのまま組織全体の効率化につながるわけではない」という矛盾への直面です。

これに対し、「情報・プロセス・組織」の 3 つの層を再構築するフレームワークを提案。さらに、ライブ配信のギフト機能という具体的なケーススタディを通じて、組織の AI 変革の効果と収益を検証しました。その結果、エージェント（Agent）を活用したエンドツーエンドの納品体制により、ギフトの新規リリースサイクルを従来の 20 日からわずか 4 日に短縮することに成功しています。

主技術部はこの変革について包括的な振り返りを行っており、フレームワークの詳細やデータ、プロセスの裏付けとなる情報はすべてそこに記載されています。ここでは重複を避けるため割愛しますが、興味のある方は原文『AI Native へ：技術チームのパラダイム転換と組織進化』をご覧ください。

段階的な進捗：効率指標の急上昇の背景にある変化

最終的な結果として、快手全体の開発効率指標は以下の通り改善しました。1 人あたりの要件交付数が 10% 増加し、平均交付サイクルは 11% 以上短縮されました。

しかし、それ以上に価値があるのは、プロセス自体の変化をデータから読み取れる以下の指標の変動です。

プロセス指標：L2+ 要件の割合が 13.23% から 64.87% に増加。約 4 倍の成長を遂げました。

検証指標として、人員効率の観点から 2025 年に注目した「AI コード生成率」を再確認します。

この数値は気づけば倍増し、30% から 60% を超える水準へと推移しました。

AI コード生成率が 40% を超えるメンバーの割合は、2025 年 Q4 の 30% から 47%、そして 77% と継続的に増加しており、この傾向は今後も続くと見られます。

これらの数字の背景には、単にツールが使いやすくなったという事実はありません。むしろ、納品モデルや役割分担、組織形態、さらにはビジネスモデルそのものが再構築されているのです。

開発組織の変化は全体像の一部に過ぎません。非技術チームと AI インフラストラクチャの変容については、またの機会にお伝えします。

開発組織の変化は全体像の一部であり、同時に変化しているのは以下の 2 つの領域です。

• 非技術チーム：製品、運営、分析など