快手、6 つの工程チームが AI の実業務への導入を推進

快手技術 2026-08-13 18:22 北京

参加互动，赢取「快手 2026 中秋礼盒」！

序言：代码写快了，接下来呢？

在快手，AI 的探索并非局限于少数团队。从模型研发到平台建设，再到具体业务落地，众多工程师正致力于将 AI 转化为实际的工程能力，并在真实场景中验证其效果。

最先显现的变化是 AI Coding 带来的代码产出量显著提升。过去需要一名工程师耗时数天完成的代码，如今几十分钟即可生成。快手某团队的 AI 代码贡献率甚至达到了 63.1%。

虽然代码编写速度大幅提升，但从需求提出到产品上线的路径却并未缩短：分析、评审、开发、测试，每一个环节都不可或缺。产品经理需向研发团队解释需求，研发完成后需等待测试，若测试发现问题则需重新沟通。只要其中任一环节衔接不畅，之前节省下来的时间就会转化为下一环节的等待成本。

同期数据显示，团队整体交付效率仅提升了 12.8%。个人效率的提升，并未直接转化为组织层面的效率增长。

周路、袁首超、郭云龙、王东旭、李刚和吴淼所在的 6 支工程团队，开始重新审视 AI 与技术工作的关系：需求如何被精准理解？知识怎样高效调用？技术人员如何深入业务现场？不同角色间如何实现协作？AI 生成的代码又如何安全地进入生产环境？

在这 6 个团队中，AI 正沿着不同的路径融入真实业务：在研发流程中接力需求传递，在商家经营中化身“运营小二”，跟随工程师走进业务一线，参与反作弊平台建设，支撑小团队的全栈交付，并接受生产质量体系的严格检验。

AI 不再仅仅停留在个人电脑里辅助写代码，而是开始贯穿需求、协作、交付与生产，深入真实业务运转的全过程。

周路が率いる総合応用センターは、調達・法務・IT・行政など 200 以上の内部システムを統括しています。チームには要求事項が多く納期も迫っているため、「受注して納品する」典型的な体制です。

従来の開発プロセスでは、まず製品担当者が要件を整理し、レビューとスケジュール調整を経てから開発・テスト・リリースへと進みます。各工程は役割ごとに順次進行するため、一つでも認識がズレれば、その後の作業はすべて待たなければなりません。

以前は、製品・開発・テストの各チームがそれぞれ AI を活用して業務速度を上げていましたが、それぞれの AI が持つ情報は断片的で、文脈全体を把握できていませんでした。そのため、工程間の引き継ぎ時には、ドキュメントや会議、口頭での説明によって業務背景を改めて共有する必要がありました。

周路は、根本的な問題はプロセスにあると気づきました。現在のフローは人間同士の協働に最適化されており、Agent を想定した設計になっていないのです。

そこで彼は「Agent-First 産研コラボレーションプラットフォーム Agent Teammates」を構築しました。これにより、Agent がチームメンバーとして日常業務に参加し、要件の分解・企画書の作成・コード生成・テスト実行などを担うようになりました。

チームは Agent ワークフローを作成し、製品・開発・テストなどの役割を持つカスタム Agent を設定します。異なる Agent は同じプロジェクトやタスクを共有し、前工程での判断と進捗を引き継ぎます。例えば、製品 Agent が要件定義書を作成すれば、開発 Agent がそれを元にタスクを分解し、テスト Agent がさらにテストの視点を補完します。前工程で残された業務ロジックや設計判断は、そのまま後工程の入力データとして活用されます。

エンジニアは反復作業から解放され、要件の判断・方針決定・リスク管理といった高付加価値な業務に注力できるようになりました。以前は複数の役割が順次引き継ぐ必要があった作業も並行して進められるようになり、繰り返しのコミュニケーションや待ち時間が大幅に削減されました。

「知的財産権プール化」プロジェクトは、この新しい働き方の完全な実証事例です。

異なる特許プールにはそれぞれ独自のルールがあり、1 件の特許出願から登録まで数ヶ月かかることもあります。関連情報はメール・表計算ソフト・コミュニケーション記録などに散在しています。法務部門はこれらの情報を一元管理し、申請・資料・フィードバック・進捗をオンラインシステムで統括したいと考えていました。

異なる動画符号化規格は、それぞれ対応する特許プールが存在します。

従来の見積もりでは、このプロジェクトには 60 人日（約 2 ヶ月）が必要とされていました。

しかし今回は、製品担当者 1 名・エンジニア 1 名・そして Agent 6 体のみで臨みました。その結果、製品 Agent が 40 分ほどで第 1 版の PRD を作成し、他の Agent が続けて技術設計・タスク分解・初版の開発とテストを完了。プロジェクトはわずか 6 日でリリースされました。

Agent が実際にタスクを実行したのは 1 日未満であり、残りの時間はコードレビューと人手によるテストに充てられました。

この新しい働き方は、交付データにも明確に表れています。第 2 四半期、総合応用センターは 301 のタスクを完了し、1 人あたりの月間交付量は第 1 四半期の 3 倍に増加しました。

こうした変化は、チームの役割分担そのものを再定義するものとなりました。

Agent はもはや各工程に点在する単発ツールではなく、独立してタスクを請け負う仮想社員のような存在です。一連の産研プロセス全体を通じて、要件背景・プロジェクトルール・タスク進捗を継続的に理解し、同じ文脈の中で作業を進め、情報整理・工程間引き継ぎ・大量の反復業務などを担います。

エンジニアは固定された工程からの解放により、判断力や創造力がより求められる課題に集中できるようになりました。

現在、周路チームには厳密な意味でのフロントエンド・バックエンドの区分けはありません。全員が「Agent Manager」として、Agent の編成・方向性の判断・結果の管理を担い、それぞれの業務範囲が広がっています。

周路が真に成し遂げたのは、個人が持つ AI ツールをチーム全体で活用できるワークフローへと昇華させ、個人の生産性向上を組織全体の効率化に変換した点にあります。

快手电商には数百万の動売商家が存在し、その大半は中小企業です。

彼らは临沂の女装産地にある問屋の店主であったり、烟台のリンゴ産地の果樹農家であったり、あるいは初めてライブ配信販売に挑戦する個人事業主だったりします。

商品や店舗を持っていても、EC 業界への理解は浅く、経営上の課題に直面した際も、それが商品の問題なのか、コンテンツの問題なのか、それともライブ配信の質の問題なのかを特定するのが困難です。

「电商小二（プラットフォーム担当者）」は商家とプラットフォームをつなぐ架け橋です。彼らはプラットフォームの政策を説明し、キャンペーンを推奨するとともに、店舗データを分析して経営アドバイスを提供します。

しかし従来の対面や電話による指導では、1 回のやり取りに短くとも 10 分、長く数時間を要し、担当者が月間にカバーできる商家数はせいぜい 200〜300 社。人手を増やすだけでは数百万の商家をすべてサポートするのは不可能でした。

袁首超率いるチームは「灵顺（リンシュン）」プロジェクトを開始し、「小二」にデジタルな分身を持たせることで、従来の「商家に行動を促す」「意思決定を支援する」段階から、一歩進んで「代わりに実行する」フェーズへと進化させました。

プラットフォームがキャンペーンを実施する際、AI 搭載の「Agent 小二」は各商家の実情に合わせて参加条件や補助金、期待収益を解説。商家が参加を承諾すると、自動的に登録手続きまで完了します。

システムはさらに商品、トラフィック、コンテンツ、ライブ配信データを分析し、経営上の弱点を特定します。季節外れの品揃えであれば有望なカテゴリーを推奨し、クリック率が芳しくない場合は画像や訴求ポイントを調整し、コンテンツが不足していれば短视频（ショート動画）やライブ配信の強化を提案します。

もし商家にライブ配信販売の実績が乏しい場合でも、「直播辅助工具」を開き、商品情報と訴求点を入力するだけで、AI が即座に配信台本を生成。コメント欄での顧客質問にも自動で回答し、商品の魅力を伝えるインテリジェントなステッカーも作成して視聴者に直接提示できます。

技術チームはこれまでバラバラだったツールをつなぎ合わせ、「ルール解説」「経営診断」「具体的な実行」までを一貫したサービスチェーンとして構築しました。

ある男性アパレルの商家では、従来は月間 GMV の 90% 以上が検索型 EC（货架电商）から発生しており、短视频領域での貢献率は 2.7% に満たない状況でした。しかし短视频 AI 托管を導入した結果、短视频 による GMV は 73 元から 1.4 万元超へと急伸し、その占める割合は 66.7% 以上にまで拡大しました。

実験比較の結果、AI 托管を受けた商家の日均支払 GMV は対照群と比較して 15% 以上向上。この成功を受け、今後はすべての商家が AI 托管機能を利用できるようになります。

AI 機能を活用することで、快手电商のライブ配信ではリアルタイム字幕も実装され、聴覚に障害を持つ方々にもよりスムーズな购物体验を提供しています。

これらの商家にとって、AI が求められているのは壮大な技術革新ではありません。複雑なルールをその場で解説する、商品画像のどこを修正すべきか指し示す、あるいは初となる成約につながる短视频 を作成する手助けをする——そうした小さな支援こそが、現場では大きな意味を持つのです。

技術は複雑な経営判断や操作をプラットフォームに集約し、事業者が商品とコンテンツの質向上に集中できるようにします。同時に、優れた商品を明確に可視化し、必要な人へ正確に届けることを可能にします。

郭雲龍氏は快手のメインプラットフォーム技術部に所属し、運営チームの R&D 要件をサポートしています。

運営チームにはコンテンツ運営だけで 30 以上の垂直分野が存在します。各分野は似ている部分もありますが、完全に同じではなく、一つのソリューションですべてをカバーするのは困難です。また、トレンドに基づくイベントは時効性が強く、最も緊急性の高い「翌日までの納品」では、当日に要件が提出されれば翌日には必ず公開する必要があります。さらに、特定の垂直分野のみを対象とする要件も存在し、汎用性に欠けるため優先順位が低く設定されがちで、長期にわたって対応が遅れるケースがあります。

AI Coding が徐々に成熟するにつれ、郭氏はチーム内で「クロススタック納品」と「FDE（Frontline Deployment Engineer：最前線展開エンジニア）」のモデルを推進しました。

全栈交付能力を持つエンジニアが一人いれば、その人はパソコンを持って運営チームに直接赴き、要件待ちをするのではなく、業務がどのように進行しているかを直接観察します。

現場駐在のエンジニアが発見したのは、審査担当者が 4 時間かけて複数のシステムを行き来し、300 件以上のコンテンツを一つずつ「タグ付け」しているという実態でした。

そこで彼は即座に審査用ワークステーションを構築しました。分散していた情報を一つの画面に集約し、AI による事前審査機能、複数人での共同作業機能、進捗記録機能を追加したのです。

2 時間後には第一版のワークステーションが稼働し、同じ業務量でも一人あたりの所要時間は 1 時間に圧縮されました。

動画タグ付けワークステーションの例

もう一つの課題は、春節晚会やワールドカップのような大型イベント時に発生します。

運営チームは長時間のライブ配信から素早くハイライトを切り出し、公開する必要があります。ピーク時には 20 人以上が同時に作業を行うこともありますが、イベント終了後は需要が急激に消滅するため、従来の方法でプロジェクト化するのは困難です。

FDE エンジニアは編集プラットフォームと公開インターフェースを接続し、AI による自動スライス機能や画像合成機能を追加しました。その結果、以前なら 20 人日かかっていた作業が、現在は 2〜3 人日で完了できるようになりました。

FDE がもたらしたのは納品速度の向上だけではありません。エンジニアがこれまで蓄積してきた技術的知見を現場でより大きな価値として発揮させることにもつながっています。

過去には、インフラや社内プラットフォームの長期的な構築に携わってきたエンジニアにとって、自分が築いた技術力が実際にどこで使われ、ビジネスにどのような変化をもたらしたかを直感的に把握するのは困難でした。しかし、彼らが運営現場に足を踏み入れることで、これまで技術的な視野に入っていなかった多くの問題が、「捉えられ、解決可能な機会」として浮かび上がってきました。AI はさらに「機会の発見」から「結果の検証」までの距離を短縮しました。これにより、誰もがより広い空間で、自らが描いた理想を完全に実現できる環境が生まれています。

この変化は技術チームだけではありませんでした。

製品チームもまた、従来の役割分担を自ら打破し、製品とデザインの機能を融合させた「PDE（Product Design Engineer：製品設計エンジニア）」へと進化させました。PDE は FDE とともに業務現場に早期に参画し、ビジネスと共に試行錯誤し、共に判断を下し、解決策を探るパートナーとなりました。

AI がエンジニアの効率化を加速させる一方で、不正業者もそれを悪用して攻撃手段を進化させています。彼らの手口はより迅速かつ大規模になり、検知も困難になっています。プラットフォームと不正業者との攻防は新たな段階へと移行しました。

王東旭氏は快手の商業化技術部に所属し、広告コンテンツの安全性とトラフィックの不正対策を担当しています。彼のチームは、アプリケーションアルゴリズム、戦略開発、運用開発、データ研究開発という 4 つの技術領域にまたがっています。従来、チームは低コードプラットフォームを活用してリスクの洞察を行ってきました。

低コードプラットフォームは標準化されたコンポーネントを備えており、一般的なクエリや分析を効率的にカバーできます。しかし、リスクとの対抗が複雑化するにつれ、既存のコンポーネントでは対応しきれない複雑で非標準的な不正分析ニーズが増加しました。チームは毎週 2 回、継続的な調整と適応を余儀なくされていました。

Coding Agent の能力が成熟してきたことを踏まえ、王氏は商業化反作弊リスクインサイトプラットフォーム「Monika」の再構築を決断しました。

王氏はこの数年前に別の企業で同様の反作弊プラットフォームの構築に参加した経験があります。その際は、システムが完成するまでにチーム全体で 1 年以上を要しました。従来の開発・研究のイテレーション方式で推計すると、商業化領域の 30 以上の製品をカバーする Monika プラットフォームには約 300 人日の投入が必要と見積もられていました。しかし今回は、エンジニア 1 名と数名のアルゴリズムインターンが参加し、わずか 25 営業日でコア機能の構築を完了させました。

このスピードアップは Coding Agent だけによるものではありません。

開発の前段階で、反作弊アルゴリズムエンジニアはまず広告主、アカウント、デバイス、クリエイティブ、行動、資金といったリスクエンティティとその相互関係を整理し、「Entity-Relation」領域モデルを構築しました。その後、各リスクシナリオごとに「Spec（仕様）」ドキュメントを作成し、データソース、ページ表示方法、インタラクション方式、検証基準などを明記します。仕様が確定した後に Coding Agent がコード生成を開始し、異なるエンジニアが統一された「Harness」アーキテクチャに沿って並行して作業を進めることができます。

この手法は「SDD（仕様駆動開発）＋ TDD（テスト駆動開発）」と呼ばれています。これは、熟練エンジニアの頭脳にある業務経験を、AI が実行可能でチームが再利用可能なエンジニアリング構造や資産へと変換するものです。

Monika の運用開始後、リスク管理担当者は広告クリエイティブ ID を入力するだけで、動画作成からクリエイティブの組み合わせ、トラフィック配信、ユーザーの閲覧に至るまでの完全なプロセスを把握できます。以前は別々のシステムに散在していたアカウント、デバイス、行動の痕跡も自動的に関連付けられ、隠れた不正ネットワークの特定を支援します。

Monika プラットフォームの例示

Monika は、チームが蓄積してきた過去の事例や判断ロジックを大規模モデルの Agent に委譲し、反作弊アシスタントとして異常を自ら発見・分析する役割も担っています。これにより、リスクを発見する効率が 50% 向上しました。

リスク管理チームにとって、業務効率化の向上は表面的な成果に過ぎません。リスク関係をより迅速に把握し、ブラック・グレー産業の組織をより包括的に検出することは、攻撃が拡散する前に発見・遮断できる件数が増えることを意味します。これにより、正当な広告主やユーザーへの影響を防ぎ、プラットフォームの生態系を健全に保つことができます。

AI はまた、リスク管理の専門能力を実装するまでの期間を短縮しています。

あるアルゴリズムエンジニアは、DeepFake 検出アルゴリズムを独自に開発しただけでなく、一連の検出プラットフォームを構築し、100 人以上が参加する深偽（ディープフェイク）検出コンテストも主催しました。かつてこれらは、アルゴリズム、フロントエンド、バックエンドが密接に連携するチーム単位でのプロジェクトでした。AI は個人の能力範囲を広げ、異なる技術職種の間の境界を曖昧にしています。

AI を巧みに活用するエンジニアは、かつてチームワークによってしか得られなかった能力を獲得し、個人の創造性をより広範なビジネス現場へと拡張しています。

「能力をプラットフォーム化し、複雑さを基盤層に隠す」——これは依然として技術エンジニアの役割です。

李剛氏は、クイックショウ（快手）の国際化成長およびライブ配信技術チームの責任者として、Push 通知（プッシュメッセージング）の分野で AI Native の実験を進めています。

海外事業からの需要が次々と押し寄せますが、クライアント側、サーバー側、アルゴリズム、テストそれぞれにスケジュールの割り当てがあり、ボトルネックが生じていました。AI Coding は個人のコーディング速度を向上させましたが、役割間での要求事項の受け渡しに伴う待ち時間を解消したわけではありません。

李剛氏は突破口として「フルスタックによる納品」に目を向けました。一人のエンジニアが複数の工程を担当すれば、協業が必要な人数が減り、自然と処理スピードが向上します。

本格的な転換期を迎えた際、チームは高い学習コストに直面しました。

クライアント側のエンジニアがサーバー側の業務を引き継ぐには、Java サービスやインターフェース設計、リリースフローを新たに習得する必要があります。さらに困難なのは心理的なハードルです。新しい技術スタックに不慣れで、コードがオンライン上の問題を引き起こした場合、誰が責任を負うのかという不安です。

李剛氏はこれに対処するため、ペア制度を導入しました。クライアントとサーバーの両方で能力が高いメンバーを二人一組とし、実際のタスクを通じて互いに指導し合いながら進めます。

最初の二ヶ月間は、転換したメンバーのコードに安定性の問題が生じても、メンターが責任を負います。二ヶ月経過後は、本人が責任を負うようになります。簡単な要件は一人のフルスタックエンジニアが完結させますが、複雑でリスクの高いタスクについては依然として複数人での協業を維持します。

しかし、単にエンジニアがより多くの技術を習得しただけでは、全体の処理時間を短縮するには不十分です。たとえ一人がクライアントとサーバーの両方のコードを変更できても、データ分析、要件整理、テスト、効果評価といった工程には依然として待機時間がかかります。

そこで李剛氏は、要件の全プロセスをカバーする一連のエージェント（Agent）も同時に構築しました。

「クライアント端末での Push 通知のホバー表示時間の制御」という事例では、一人のフルスタックエンジニアが、この一連のプロセス用エージェントを活用して独自に解決しました。

製品担当者は当初、経験則に基づき「Push がスマホ画面に表示される時間が長すぎると、ユーザーのクリック率に影響するのではないか」と考えていました。かつては、この仮説をまずデータアナリスト（DA）に依頼してデータを抽出させ、その後エンジニアがコードを検査し、数回のやり取りを経てようやく要件として確定するという流れでした。

Push 样式示例

今回は、製品チームが課題を「万事通 Agent」に丸投げしました。Agent は自ら関連するデータテーブルやコード、過去の資料を探し出し、SQL を自動生成してデータクエリを実行。さらに、異なる種類の Push 通知についても分析を行いました。

その結果、クライアント側でローカルトリガーされた Push のうち、80.6% が固定で 10 秒間表示される状態にあることが判明しました。また、発生源が特定できない Push においては、この割合はさらに 94.3% に達していました。

調査を続けたところ、Agent は根本原因にたどり着きました。従来の設定では、一部の Push のみ制御可能であり、クライアント側でトリガーされる通知には適用されず、システムデフォルトの 10 秒表示がそのまま使われていたのです。その結果、多くの Push が 10 秒という単一の値に固定され、シナリオに応じた柔軟な調整ができなくなっていました。

この分析を基に、万事通は包括的な PRD（製品要件定義）を作成しました。そこでは統一パラメータの追加と優先順位の明確化が提案され、A/B テストの実装も設計されています。その後、Myflicker が PRD を引き継ぎ、企画立案からコード生成、自己検証までを完了。テスト用の Agent は PRD とコード変更に基づいてテストケースを自動生成・実行しました。

この全栈（フルスタック）実験の真価は、単に少ない人員で多くの要件を満たせるようになったことだけではありません。人と Agent の役割分担を再構築した点にあります。

これまで製品マネージャー、クライアント開発者、サーバーサイドエンジニアといった職種ごとの壁によって分断されていた業務が、今では一人の人間によって継続的に推進できるようになりました。これにより協業コストが低下し、個人の生産性向上が組織全体の効率化へと直結するようになりました。

エンジニアも、特定の工程をこなすだけの存在から、要件理解から製品化、結果検証に至るまでの一連のプロセスを担う立場へと進化しました。

商品、取引、決済。これらは快手（クイショウ）の生活サービスを支える 3 つのコアプロセスです。吴淼（ウーミャオ）率いるチームはこれらのシステムの開発と運用を担当しており、ある一箇所の改修が複数のリポジトリや上流・下流のサービスに波及するリスクを常に抱えています。

2026 年初め、同チームにおける AI によるコード生成率は 31.67% に達していましたが、実際に完全なデリバリーフローに入ったのは 4% もないほどでした。

AI がタスクを受け取るたびに、まるで初めてプロジェクトに足を踏み入れたかのような状態です。システムが過去にどのような改修を遂げてきたか、チームが安定性のためにどのような制約を設けているかを理解していないのです。初期の実践では、AI が知識ベースから誤ったインターフェースを見つけ、その結果として生成されたコードもまた方向を誤ってしまいました。

この課題に対処するため、吴淼のチームは「Harness」というエンジニアリングフレームワークを構築しました。これにより AI に対して明確な作業パスが提示されます：要件分析、設計立案、テストケース生成、コーディング、自己検証、コードレビュー、デプロイ検証。各工程には入力と出力、そして通過基準が明確に定義されており、前段階の基準を満たさなければ次の工程へ進めません。

このフレームワークはまず「知識の問題」を解決します。チームはコードを技術的な事実の源泉と位置づけ、リポジトリから直接インターフェース、依存関係、ビジネスロジックを抽出して AI が参照可能なプロジェクト知識として構築しました。コードがマージされると、新たな情報も自動的に蓄積・更新されます。

システムはまた「夢のメカニズム」を通じて、定期的に知識を抽出・審査・修正・評価し、コードの変化に合わせて知識も更新されるようにしています。

テスト資産もコーディングの前段階で準備されます。AI がまだコードを書き始める前には、すでにテストケースやグレーゾーン（カナリ）リリースの要件、例外処理、ロールバック基準が設計に組み込まれています。コード生成後には、比較的に独立した工程で審査と検証が行われます。パイプラインを通過できなければタスクは戻され、AI は品質の閾値を越えずして本番環境へ進むことはできません。

5 月時点でのチームの AI コード生成率は 31.67% から 84.46% に向上し、AI が関与した L2 以上の要件の割合も 3.23% から 90.91% へと大幅に伸びました。

より重要な変化は、チームが AI の不確実性をどう捉えるかという点で起きています。ウーミャオ（Wu Miao）によれば、半年前まではモデルの幻覚現象を根本的に解決することは不可能だと考え、できることは緩和策に限られていました。

Harness による工程体系の変化は、幻覚が完全に消滅することではありません。重要なのは、それを検証可能で遮断でき、かつロールバック可能なプロセスに組み込むことです。知識は継続して更新され、テストは早期に介入し、独立した工程が検証を担当します。失敗したタスクは自動的に戻され、本番環境へ展開された後もグレーゾーンリリースや機能低下（デグレード）、ロールバックの仕組みが残っています。

モデルが間違いを犯す可能性は依然としてありますが、もたらされる不可控なリスクは、本番環境で許容できる水準まで抑え込まれました。ウーミャオはこの変化を「制約による信頼の飛躍」と呼びます。

この信頼は、「AI は常に正しい」という仮定の上に成り立っているわけではありません。それはエラーを即座に発見し、リスクの拡大を防ぎ、結果を制御できる工程システムによって支えられています。AI コーディングが越えたのは、単なるコード生成率の壁だけではありません。「使える状態」から「安定して使える状態」へと至る壁です。

こうした工程上のガードレールがあることで、多くのエンジニアが同じルールのもとで AI を活用できるようになり、チームが蓄積した経験も継続的に再利用されます。

AI コーディングはもはや個人の効率化ツールに留まらず、共同利用され、持続的に進化していく工程能力へと発展しつつあります。

「結び：より大きな工程への挑戦」

6 つの物語を振り返り、快手チームが AI 工程実践に対して示す答えも次第にはっきりとしてきました。

AI はより包括的な業務プロセスへ進出しています。製品・開発・テスト間の協働に参加し、中小事業者への経営支援を提供し、エンジニアと共に現場の運営に入り込み、リスク管理や海外展開、ライフサービスといった複雑なシステムにも入り込み、実業務による検証に耐えています。

これらの実践がもたらす変化は必ずしも壮大なものではありません。

それは、ある事業者が最初の成約につながるショートビデオを作成するのを助けることかもしれません。あるいは、運営担当者が数時間の単純作業から解放されること、小規模チームがより多くの要件を受け持つことができるようになること、生成されたコードが十分に検証され、本番環境へ安全に導入されることかもしれません。こうした具体的な成果こそが、技術が実業務に深く根付く重みとなっています。

6 チームの実践は、快手が AI 工程領域で歩む探索の道筋も浮かび上がらせています。真の問題から出発し、人間と AI の協働プロセスを再設計し、断片的な知識や経験、品質基準をシステムに組み込み、有効な実践を繰り返すことで再利用可能な工程能力へと昇華させるのです。

最初に戻りましょう。「コードが速くなった後、次に何をするか？」

グオ・ユンロン（Guo Yunlong）は、ジョブズが有名にした「売糖水」の問いを思い出させます。慣れ親しんだ枠組みの中に留まり、他人から与えられたタスクをこなすのか、それとも本物で、ある意味荒々しい環境へと足を踏み入れ、自らツールを構築してより広範な問題を解決するのか。

6 チームは一致して後者を選びました。AI を開発プロセスや事業者の経営、業務現場、そして生産システムへ持ち込み、具体的な実践を通じて、エンジニアが何を実現できるのかを改めて理解しています。

エンジニアは毎日世界を変える方法を考える必要はありません。むしろ、自らの居場所（格子）から一歩踏み出し、直面する現実の課題に向き合い、技術を使って具体的な事柄を少しでも前に進めることを選ぶことができます。

現在、快手で進行中の AI 実践において、これこそが最も魅力的な参加理由と言えるでしょう。

【過去の注目記事】

快手 AI 開発パラダイムの転換：効率化から組織の変革へ

WeChat で開く