開発組織のAI活用レベルを可視化する「エンジニア版AI番付」の設計と運営
サイバーエージェントが開発組織の AI 成熟度を可視化するため、相撲の番付を模した評価軸「エンジニア版 AI 番付」を設計・運用し、技術的深さと組織的文化の両面から現状を分析した事例報告。
キーポイント
開発プロセスと組織文化の二軸評価
AI 活用の成熟度を「エンジニアリング品質・技術成熟度」と「推進体制・技術文化」の 2 つの軸で評価し、個人の工夫だけでなく組織としての再現性を重視している。
相撲番付による可視化と 7段階分類
幕下(個人活用)から横綱(AI 前提の開発)までの 7 段階で各組織の現在地を表現し、順位付けよりも「次の課題」の明確化を目的としている。
具体的な評価項目と自己申告プロセス
開発ワークフローへの統合度や役割分担など 14 の詳細な項目に基づき組織が自己申告・証左提出を行うことで、客観的な現状把握を可能にしている。
2028 年自動化目標に向けた共通言語
全社開発プロセスの完全自動化という長期目標に向けて、各組織が自らの立ち位置を認識し、具体的な改善策を議論するための共通基盤として機能している。
自己申告と証左による納得感の構築
運営側の一方向的な評価ではなく、組織自身が現状を言語化し根拠(証左)を示すプロセスを通じて、公平性と当事者意識を高めています。
AI活用を「個人の生産性」から「プロセス再設計」へ
単なるツールの導入ではなく、AIを前提とした開発フローの再構築や標準化が組織全体の開発力向上に不可欠であると指摘しています。
横展開における文脈の共有
成功事例をそのまま紹介するだけでなく、その取り組みが成立した背景や前提条件を整理し、他組織での再現性を高めることを目指します。
影響分析・編集コメントを表示
影響分析
この記事は、大規模開発組織における AI 導入の定量的・定性的評価モデルとして極めて参考になる実践例を示しています。単なるツールの導入状況ではなく、開発プロセスの変革と組織文化の醸成をどう測るかの具体的なフレームワークを提供しており、他社が自社の AI 成熟度を診断する際のベンチマークや設計指針として活用可能です。
編集コメント
AI ツールの導入状況だけでなく、開発プロセスの変革や組織文化の定着度をどう評価するかという、実務レベルで非常に示唆に富むフレームワークが提示されています。
サイバーエージェントでは、AI の活用を全社で推進する取り組みの一つとして、各組織の AI 活用レベルを相撲の番付になぞらえて可視化する「AI 番付」を実施しました。
本記事では、その中でも開発組織に特化した「エンジニア版 AI 番付」について、なぜ全社版とは別に設計したのか、どのような評価軸で 44 の開発組織の現在地を可視化したのか、そして実際に運営して見えてきたことを紹介します。
なぜ「エンジニア版」が必要だったのか
AI 活用を全社で推進するうえで、売上やコスト削減、事業 KPI(Key Performance Indicator:主要業績評価指標)への貢献といった観点は非常に重要です。一方で、開発組織における AI 活用の成熟度は、それだけでは捉えきれません。
たとえば、ある組織ではエンジニア個人が日々の実装で生成 AI を活用しているかもしれません。別の組織では、要件整理、設計、実装、レビュー、テスト、リリース準備といった開発プロセス全体に AI エージェントを組み込み、人間と AI の役割分担を整理しているかもしれません。
どちらも AI 活用ではありますが、組織として目指すべき状態や、次に取り組むべき課題は大きく異なります。
そこでエンジニア版 AI 番付では、単に「AI を使っているか」ではなく、以下のような問いを可視化することを重視しました。
- 開発プロセスのどこまで AI を組み込めているか
- AI は補助的なツールにとどまっているのか、自律的にタスクを進める存在になっているのか
- 人間と AI の役割分担は明確になっているか
- IDE(Integrated Development Environment:統合開発環境)、リポジトリ、CI(Continuous Integration:継続的インテグレーション)、チャット、ドキュメントなどの開発ワークフローに統合されているか
- 効果を測定し、改善するサイクルがあるか
- ツールやガイドラインが整備され、組織として安全に使える状態になっているか
- 個人の工夫が、チームや組織のナレッジとして共有されているか
- AI 活用の目標が、技術戦略や経営方針と接続されているか
サイバーエージェントでは、2028 年までに全社の開発プロセスを自動化することを掲げています。その実現に向けて、各開発組織が自分たちの現在地を把握し、次の一歩を具体化できる仕組みが必要でした。
エンジニア版 AI 番付は、そのための共通言語として設計しました。
評価設計:2 軸 14 項目
エンジニア版 AI 番付では、44 の開発組織を対象に、2 つの軸と 14 の評価項目で AI 活用の成熟度を確認しました。
1 つ目の軸は「エンジニアリング品質・技術成熟度」です。これは、AI を開発プロセスの中でどの程度深く使いこなせているかを見る軸です。
2 つ目の軸は「推進体制・技術文化」です。こちらは、AI 活用が個人の工夫に閉じず、組織として継続的に広がる状態になっているかを見る軸です。
評価軸
見ている観点
エンジニアリング品質・技術成熟度
AI の利用範囲、自動化の深さ、人間と AI の役割分担、開発ワークフローへの統合、成果、インシデント対応、AI 活用基盤
推進体制・技術文化
組織内の利用レベル、ツール環境とガイドライン、ナレッジ共有、推進体制、効果測定、全社への発信、目標・戦略との整合
この 2 軸に分けた理由は、技術的に高度な取り組みと、組織として再現性を持って広げる力の両方が必要だと考えたためです。
一部のエンジニアが非常に先進的な使い方をしていても、チームに共有されず、標準的な開発フローにも組み込まれていなければ、組織全体の成熟度としてはまだ伸びしろがあります。逆に、推進体制や勉強会は整っていても、実際の開発プロセスに AI が深く入っていなければ、技術的な成果にはつながりにくい。
そのため、エンジニア版 AI 番付では「AI でどこまで開発を変えられているか」と「それを組織として継続的に伸ばせるか」を同時に見る設計にしました。
7 段階の番付に落とし込む
評価結果は、相撲の番付になぞらえた 7 段階で表現しています。
番付
状態のイメージ
横綱
AI 前提の開発組織
大関
標準化、計測、発信が進んでいる状態
関脇
組織的な成功事例が確立されている状態
小結
自組織への落とし込みが包括的に進んでいる状態
前頭
自組織への落とし込みが部分的に始まっている状態
十両
組織として他の事例を真似始めている状態
幕下
個人単位の活用にとどまっている状態
番付形式にしたことで、単なる点数評価よりも直感的に現在地を共有しやすくなりました。
一方で、番付という表現は盛り上がりを生みやすい反面、評価だけが独り歩きするリスクもあります。そこで運営側では、「順位をつけること」ではなく「次に何を伸ばすべきかを明確にすること」を一貫して重視しました。
自己申告・証左・審議で納得感をつくる
エンジニア版 AI 番付では、対象組織に自分たちの AI 活用状況を自己申告してもらう形式を取りました。
imageAI 番付のスケジュール
自己申告にしたのは、単に運営側が外から評価するだけでは、各組織の当事者意識につながりにくいと考えたためです。自分たちで評価項目を読み込み、現在地を言語化し、根拠となる取り組みを整理する。そのプロセス自体が、AI 活用戦略を考える機会になります。
ただし、自己申告だけでは評価の公平性を担保できません。そこで、各組織には申告内容を裏付ける証左も提出してもらい、運営側で確認する流れを設けました。
証左の確認では、各組織の取り組みを一律に機械的に判定するのではなく、評価項目との対応関係を確認しながら、申告内容がどの程度裏付けられているかを見ています。
そのうえで、必要なケースについては審議会で確認し、最終的な番付を決定しました。
このプロセスで大事にしたのは、厳密さだけではありません。各組織が結果を受け取ったときに、「なぜこの評価なのか」「次に何を伸ばせばよいのか」が分かる状態にすることです。
AI 活用の成熟度は、単純なチェックリストだけでは測れません。技術的な深さ、組織の規模、プロダクトの性質、既存の開発プロセス、セキュリティ要件など、組織ごとに前提が異なります。
だからこそ、エンジニア版 AI 番付では、共通の評価軸を持ちながらも、証左と審議を通じて納得感をつくる運営を意識しました。
運営して見えたこと
第 1 回のエンジニア版 AI 番付を運営して、いくつかの傾向が見えてきました。
まず、多くの開発組織で、すでに AI 活用の試行錯誤が始まっていました。実装支援やレビュー支援だけでなく、要件整理、テスト、ドキュメント作成、問い合わせ対応、開発ナレッジの整理など、活用領域は広がっています。
一方で、個人や一部チームの工夫を、組織全体の標準的な開発プロセスにどう組み込むかは、多くの組織に共通するテーマでした。
AI ツールを使うこと自体は以前より身近になっています。しかし、開発組織として成果を出すには、次のような問いに向き合う必要があります。
- どの工程を AI に任せ、どこを人間が判断するのか
- AI が出した成果物をどのようにレビューし、品質を担保するのか
- AI 活用によってリードタイムや品質がどう変化したのか
- 成功した手順や判断基準、ワークフローを、どうチームの資産にするのか
- セキュリティや権限管理をどう標準化するのか
特に重要だと感じたのは、AI 活用を「個人の生産性向上」から「開発プロセスの再設計」へ進めていく視点です。
AI を使う人が増えるだけでは、組織の開発力が自動的に上がるわけではありません。既存の開発フローを前提に AI を足すのではなく、AI がいることを前提に、仕様の作り方、レビューの仕方、テストの設計、ナレッジ共有の方法を見直していく必要があります。
その意味で、エンジニア版 AI 番付は評価制度であると同時に、開発組織が AI 前提の働き方へ移行するための診断ツールでもあります。
横展開のために運営側が意識したこと
AI 活用のレベルを上げるには、上位の取り組みを単に紹介するだけでは不十分です。
ある組織でうまくいった方法が、別の組織にそのまま当てはまるとは限りません。プロダクトの性質、開発体制、利用しているツール、セキュリティ要件、チームの文化が違えば、導入の仕方も変わります。
そのため、運営側では「事例を共有する」だけでなく、「なぜその取り組みが成立したのか」「どの前提があれば真似できるのか」「まず小さく始めるなら何から着手すべきか」を整理することを意識していきたいと考えています。
番付という形式は、現在地を可視化するには強力です。しかし、本当に重要なのは、番付を見た後に各組織が次の行動に移れることです。
今後は、各組織へのフィードバックやナレッジ共有をさらに強化し、先進的な取り組みをより再現可能な形で横展開していきたいと考えています。
次回に向けて
第 2 回 AI 番付は、2026 年 10 月の発表を予定しています。
次回に向けては、先進的な取り組みのナレッジ共有や、各組織への伴走支援をさらに加速していきます。特に、AI エージェントを開発プロセスに組み込む取り組みや、効果測定の仕組み、チーム横断で使えるガイドライン整備などは、今後より重要になると考えています。
私たちが目指しているのは、AI を使うこと自体が目的になる状態ではありません。
AI が開発プロセスの中で自然に協働し、エンジニアがより本質的な課題設定やプロダクト価値の創出に向き合える状態をつくることです。
エンジニア版 AI 番付を通じて、各開発組織が自分たちの現在地を正しく把握し、半期ごとに一段ずつ AI 活用のフェーズを上げていけるよう、引き続き取り組んでいきます。
原文を表示
サイバーエージェントでは、AIの活用を全社で推進する取り組みの一つとして、各組織のAI活用レベルを相撲の番付になぞらえて可視化する「AI番付」を実施しました。
本記事では、その中でも開発組織に特化した「エンジニア版AI番付」について、なぜ全社版とは別に設計したのか、どのような評価軸で44の開発組織の現在地を可視化したのか、そして実際に運営して見えてきたことを紹介します。
なぜ「エンジニア版」が必要だったのか
AI活用を全社で推進するうえで、売上やコスト削減、事業KPIへの貢献といった観点は非常に重要です。一方で、開発組織におけるAI活用の成熟度は、それだけでは捉えきれません。
たとえば、ある組織ではエンジニア個人が日々の実装で生成AIを活用しているかもしれません。別の組織では、要件整理、設計、実装、レビュー、テスト、リリース準備といった開発プロセス全体にAIエージェントを組み込み、人間とAIの役割分担を整理しているかもしれません。
どちらもAI活用ではありますが、組織として目指すべき状態や、次に取り組むべき課題は大きく異なります。
そこでエンジニア版AI番付では、単に「AIを使っているか」ではなく、以下のような問いを可視化することを重視しました。
- 開発プロセスのどこまでAIを組み込めているか
- AIは補助的なツールにとどまっているのか、自律的にタスクを進める存在になっているのか
- 人間とAIの役割分担は明確になっているか
- IDE、リポジトリ、CI、チャット、ドキュメントなどの開発ワークフローに統合されているか
- 効果を測定し、改善するサイクルがあるか
- ツールやガイドラインが整備され、組織として安全に使える状態になっているか
- 個人の工夫が、チームや組織のナレッジとして共有されているか
- AI活用の目標が、技術戦略や経営方針と接続されているか
サイバーエージェントでは、2028年までに全社の開発プロセスを自動化することを掲げています。その実現に向けて、各開発組織が自分たちの現在地を把握し、次の一歩を具体化できる仕組みが必要でした。
エンジニア版AI番付は、そのための共通言語として設計しました。
評価設計: 2軸14項目
エンジニア版AI番付では、44の開発組織を対象に、2つの軸と14の評価項目でAI活用の成熟度を確認しました。
1つ目の軸は「エンジニアリング品質・技術成熟度」です。これは、AIを開発プロセスの中でどの程度深く使いこなせているかを見る軸です。
2つ目の軸は「推進体制・技術文化」です。こちらは、AI活用が個人の工夫に閉じず、組織として継続的に広がる状態になっているかを見る軸です。
この2軸に分けた理由は、技術的に高度な取り組みと、組織として再現性を持って広げる力の両方が必要だと考えたためです。
一部のエンジニアが非常に先進的な使い方をしていても、チームに共有されず、標準的な開発フローにも組み込まれていなければ、組織全体の成熟度としてはまだ伸びしろがあります。逆に、推進体制や勉強会は整っていても、実際の開発プロセスにAIが深く入っていなければ、技術的な成果にはつながりにくい。
そのため、エンジニア版AI番付では「AIでどこまで開発を変えられているか」と「それを組織として継続的に伸ばせるか」を同時に見る設計にしました。
7段階の番付に落とし込む
評価結果は、相撲の番付になぞらえた7段階で表現しています。
番付形式にしたことで、単なる点数評価よりも直感的に現在地を共有しやすくなりました。
一方で、番付という表現は盛り上がりを生みやすい反面、評価だけが独り歩きするリスクもあります。そこで運営側では、「順位をつけること」ではなく「次に何を伸ばすべきかを明確にすること」を一貫して重視しました。
自己申告・証左・審議で納得感をつくる
エンジニア版AI番付では、対象組織に自分たちのAI活用状況を自己申告してもらう形式を取りました。

自己申告にしたのは、単に運営側が外から評価するだけでは、各組織の当事者意識につながりにくいと考えたためです。自分たちで評価項目を読み込み、現在地を言語化し、根拠となる取り組みを整理する。そのプロセス自体が、AI活用戦略を考える機会になります。
ただし、自己申告だけでは評価の公平性を担保できません。そこで、各組織には申告内容を裏付ける証左も提出してもらい、運営側で確認する流れを設けました。
証左の確認では、各組織の取り組みを一律に機械的に判定するのではなく、評価項目との対応関係を確認しながら、申告内容がどの程度裏付けられているかを見ています。
そのうえで、必要なケースについては審議会で確認し、最終的な番付を決定しました。
このプロセスで大事にしたのは、厳密さだけではありません。各組織が結果を受け取ったときに、「なぜこの評価なのか」「次に何を伸ばせばよいのか」が分かる状態にすることです。
AI活用の成熟度は、単純なチェックリストだけでは測れません。技術的な深さ、組織の規模、プロダクトの性質、既存の開発プロセス、セキュリティ要件など、組織ごとに前提が異なります。
だからこそ、エンジニア版AI番付では、共通の評価軸を持ちながらも、証左と審議を通じて納得感をつくる運営を意識しました。
運営して見えたこと
第1回のエンジニア版AI番付を運営して、いくつかの傾向が見えてきました。
まず、多くの開発組織で、すでにAI活用の試行錯誤が始まっていました。実装支援やレビュー支援だけでなく、要件整理、テスト、ドキュメント作成、問い合わせ対応、開発ナレッジの整理など、活用領域は広がっています。
一方で、個人や一部チームの工夫を、組織全体の標準的な開発プロセスにどう組み込むかは、多くの組織に共通するテーマでした。
AIツールを使うこと自体は以前より身近になっています。しかし、開発組織として成果を出すには、次のような問いに向き合う必要があります。
- どの工程をAIに任せ、どこを人間が判断するのか
- AIが出した成果物をどのようにレビューし、品質を担保するのか
- AI活用によってリードタイムや品質がどう変化したのか
- 成功した手順や判断基準、ワークフローを、どうチームの資産にするのか
- セキュリティや権限管理をどう標準化するのか
特に重要だと感じたのは、AI活用を「個人の生産性向上」から「開発プロセスの再設計」へ進めていく視点です。
AIを使う人が増えるだけでは、組織の開発力が自動的に上がるわけではありません。既存の開発フローを前提にAIを足すのではなく、AIがいることを前提に、仕様の作り方、レビューの仕方、テストの設計、ナレッジ共有の方法を見直していく必要があります。
その意味で、エンジニア版AI番付は評価制度であると同時に、開発組織がAI前提の働き方へ移行するための診断ツールでもあります。
横展開のために運営側が意識したこと
AI活用のレベルを上げるには、上位の取り組みを単に紹介するだけでは不十分です。
ある組織でうまくいった方法が、別の組織にそのまま当てはまるとは限りません。プロダクトの性質、開発体制、利用しているツール、セキュリティ要件、チームの文化が違えば、導入の仕方も変わります。
そのため、運営側では「事例を共有する」だけでなく、「なぜその取り組みが成立したのか」「どの前提があれば真似できるのか」「まず小さく始めるなら何から着手すべきか」を整理することを意識していきたいと考えています。
番付という形式は、現在地を可視化するには強力です。しかし、本当に重要なのは、番付を見た後に各組織が次の行動に移れることです。
今後は、各組織へのフィードバックやナレッジ共有をさらに強化し、先進的な取り組みをより再現可能な形で横展開していきたいと考えています。
次回に向けて
第2回AI番付は、2026年10月の発表を予定しています。
次回に向けては、先進的な取り組みのナレッジ共有や、各組織への伴走支援をさらに加速していきます。特に、AIエージェントを開発プロセスに組み込む取り組みや、効果測定の仕組み、チーム横断で使えるガイドライン整備などは、今後より重要になると考えています。
私たちが目指しているのは、AIを使うこと自体が目的になる状態ではありません。
AIが開発プロセスの中で自然に協働し、エンジニアがより本質的な課題設定やプロダクト価値の創出に向き合える状態をつくることです。
エンジニア版AI番付を通じて、各開発組織が自分たちの現在地を正しく把握し、半期ごとに一段ずつAI活用のフェーズを上げていけるよう、引き続き取り組んでいきます。
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み