AI 協働力: 100 万件の評価データが示す、 優秀なエンジニアを測る軸の変化

2026年8月21日に開催された Developers Summit 2026 KANSAI ( https://event.shoeisha.jp/devsumi/20260821/ ) のセッション資料です。

Transcript

1. Developers Summit 2026 KANSAI AI COLLABORATION AI 協働力: 100 万件の評価データが示す、 優秀なエンジニアを測る軸の変化 「AI を使えているか」を問う段階は、終わった 泉水 翔吾 株式会社ハイヤールー 取締役CTO 2026-08-21
2. NOT ANOTHER "AI CHANGES EVERYTHING " TALK 「AI で変わる」 → 「どう測るか」 "変わる" という話はありふれているので、 変わった後を "どう測るか" の話をします。
3. THE QUESTION 皆さんの組織は、 AI の "利用率" を測っていませんか？ 導入率、稼働率、トークン消費量…。
4. PRESENTER 泉水 翔吾 株式会社ハイヤールー 取締役CTO Shogo SENSUI サイバーエージェント メルカリ デジタル庁 ハウテレビジョン SIer での受託開発を経て、株式会社サイバーエージェントに入社。様々なプロダク ト開発の傍ら、立ち上げた横断組織で Web 技術の推進に従事。株式会社メルカリ に入社後は Web やアプリのフルリプレイスを牽引し、執行役員 VP としてメルペイ のエンジニアリング部門を管掌。 デジタル庁では行政のデジタル化に貢献し、株式会社ハウテレビジョンでは執行役 員プロダクト本部長として事業と組織の成長を主導。西日本旅客鉄道株式会社・三 井住友カード株式会社等の顧問として、事業や組織の幅広い課題解決を推進。 2025 年、株式会社ハイヤールーにジョイン。
5. 01 01 02 03 SECTION 01 · 測れていない 04 使っている。効いている気もする。 だが、測れていない。
6. THE ADOPTION 9 割が使い、8 割が効果を実感している 90% 回答者の 90% が業務で AI を使用 導入は、終わった。ここまでは既知の話。 80%+ うち 80% 以上が生産性の向上を実感 出典：DORA — State of AI-assisted Software Development (2025)
7. THE GAP しかし、組織の成果には現れない AI 導入が 25% 進むごとの、デリバリー指標の推定変化（DORA 2024） −1.5% +7.2% スループット 不安定性 デプロイの頻度は低下、変更のリードタイムは増加 変更の失敗率と障害復旧時間は増加 出典：DORA — Accelerate State of DevOps Report (2024) の推定値
8. PERCEPTION ≠ PERFORMANCE 実感は、指標にならない 個人の実感 「速くなった」↗ 8 割以上が生産性向上を実感。実感自体は、本物 ≠ 「個人が速くなること」と「組織が成果を出すこと」は、別の現象 組織の成果 スループット低下 ↘ デリバリーはむしろ不安定に。実感と成果が乖離している
9. TOKENMAXXING — DORA, JUNE 2026 利用量は、指標にならない “AこのI のトークン消費量を、社内リーダーボードで競わせる—— "tokenmaxxing" は、危険な罠である。 消費量を業績指標として扱う潮流に対する、DORA の警告。 測る物差しがないから、測れるものを測ってしまう。多くの組織がいま陥っているのは、この状態 出典：DORA — Finding balance in the era of tokenmaxxing (2026-06)
10. THE ADOPTION CURVE いまは「発散」から「最適化」への移行期 Phase 2 · Optimization Phase 1 · Divergence 発散期: とにかく使う 試す・広げる・量を増やす。新技術の受容期には、利用 量の拡大それ自体に意味がある。tokenmaxxing はこの フェーズの現象 → 最適化期: 価値あたりで使う トークンあたりにどれだけの価値を出すか。どこに使 い、どこに使わないか。問いが「量」から「質」へ移る 移行期に足りていないのは、質を測る物差し。だから利用率や消費量を測ってしまう
11. THE REAL QUESTION 「使っているか」 → 「どう使っているか」 差を生むのは、AI の出力のどこに手を入れ、なにを任せるかという判断の質。 「利用率を上げること」と「成果が出ること」は、同じではない。
12. 02 01 02 03 SECTION 02 · 何を測るのか 04 利用率でも利用量でもないなら、 何を測るのか
13. THE PROBLEM 従来の物差しでは、測れない 学歴・資格 "使い倒す質"とは、相関しな い。 コードの量 AI を使えば、誰でも増やせる。 「作って当てる」「AI を使い倒す」質は、履歴書に載らない アルゴリズム試験 "暗記"を測っても、協働は測れ ない。 職務経歴 過去の実績は、AI 時代の力を保 証しない。
14. PROCESS OVER OUTPUT 能力は、成果物ではなく"過程"に宿る 見えるもの — 成果物 差が出るもの — 過程 AI が書けば、誰のものでも似てくる。差が出ない。 AI の出力のどこに手を入れ、どこを任せたか。ここに質が表れ る。 完成したコード 重要なのは「測る対象を、成果物から過程へ」という点 どう問い、疑い、判断したか
15. THE CONVERGENCE ベンダー各社の主張は、一点に収束する Anthropic · AI Fluency — 4D Delegation — 人と AI の役割分担を決める Description — 目的を言語化し、AI を導く Discernment — 出力の妥当性を見抜く Diligence — 利用と結果に責任を持つ CoderPad · 5 Skills of the Future Developer Strategic Use — 明確な意図で AI を統制する Problem Framing — 課題を自力で分解する Critical Evaluation — 出力を疑い、修正する Problem Solving — AI を自然に統合し課題を解く 表現は違えど、同じ「AI を使った量ではなく、AI との協働の質」を指す 出典：Anthropic AI Fluency (2025) / CoderPad 5 Skills of the Future Developer (2026)
16. THREE AXES OF AI COLLABORATION AI 協働力 ＝ 統制・分解・検証 統制 明確な意図で、AI を操る。何を任せ、 何を任せないかを決める。 分解 課題を、自力で構造化する。AI に渡せ る形まで問題を刻む。 ベンダー各社の枠組みを一般化した、測るための 3 軸。以降の話はすべてこの軸 検証 出力を疑い、責任を持つ。どこに手を入 れるかを判断する。
17. OPERATIONALIZATION — 測定器への落とし込み 測るために、3 軸を5 領域に分解する 統制 分解 検証 → 実行の統制 ・ 環境構築 AI が動く条件を整え、作業の進行を握る。 → 意図の仕様化 意図を分解し、AI に渡せる仕様に落とす。 → 出力の品質保証 出力を疑い、どこに手を入れるかを判断する。 3 軸を貫く芯 → 共同推論 どれか 1 軸ではなく、3 軸を「考えながら」回す統合運用。AI と仮説 を往復させる。 3 軸は概念、5 領域はその測定器。次のセクションで、この 5 領域を実測する
18. THE CONSTANT 課題解決力は、普遍 コードを書く → 課題を、解決する 統制・分解・検証を貫く芯。AI はこの向き合い方を、良い意味で強制する
19. 03 01 02 03 04 SECTION 03 · AI 協働力の実測 AI 協働力を、 実測すると何が見えるか ここからは、他では見られない数字の話
20. DATA DEFINITIONS 今日の数字は 3 つ。それぞれ別のもの 300 社超 100 万件超 25,115 件 累計導入企業数。HireRoo を技術評価に使う企業の数。 累計評価データ件数。候補者が課題をどう解いたか、その"過程"の蓄積。 今回の分析対象。AI 協働力を Software Engineering Index (SEI) でスコア化した評価件数。以降の スコアはすべてこれが母数。 公開カンファレンスのため、3 つの数字の関係をここで明示しています。
21. THE NUMBERS — SOFTWARE ENG INEE RING INDEX 25,115 件の実測データ 25,115 58.3 5 領域 · 13 観点 評価件数 全体スコア（100 点満点） 測定の構造 AI 協働力をスコア化した評価の全件。基準 日 2026-07-29 の断面。 25,115 件の平均。ただし、平均は入口にす ぎない。 AI 協働のプロセスを 5 領域 13 観点に分解 して採点。 出典：HireRoo — Software Engineering Index / AI 協働力 (2026-07-29)
22. THE BREAKDOWN — 5 領域の実測ス コア 「使う」は高く、「考える」は低い 実行の統制 意図の仕様化 出力の品質保証 環境構築 共同推論 AI に指示する力は 68.5pt。AI と考える力は 45.5pt、その差 23pt 68.5 64.4 58.7 54.6 45.5 出所：HireRoo — Software Engineering Index / AI 協働力 (2026-07-29)
23. FINDING 01 平均の内側に、23 ポイントの段差 23 pt 最高 — 実行の統制 最低 — 共同推論 68.5 45.5 平均 58.3 の内側はフラットではない。「使う」系が高く、「考える」系が低 い凸凹。 出所：HireRoo — Software Engineering Index / AI 協働力 (2026-07-29)
24. FINDING 02 凸凹の底は、「AI と考える」力 共同推論 5 領域の最下位 45.5 25,115 件の断面で、最も低いのは 仮説を往復させ、AI と共に考える力。 一部の人の偏りではなく、 市場全体に共通する構図。 出所：HireRoo — Software Engineering Index / AI 協働力 (2026-07-29)
25. FINDING 03 「使う」は差がつかず、「考える」で差がつく AI を"使う"力 — 実行の統制 68.5 AI と"考える"力 — 共同推論 45.5 指示を出し、作業を進めさせる力は多くの候補者が高水準。も はや前提スキル。 仮説を往復させ、AI と共に考える力。スコアのばらつきが最大 ＝優秀層を分ける軸。 高水準に集中し、 差がつかない 優秀さを識別する軸は、「使う」から「考える」へ 最も低く、 最も個人差が出る
26. THE TIMELINE — 試験形式の推移 AI 利用前提の出題は 2024 年に現れ、いま 3 件に 1 件 32% 21% 13% 0% 2023 Q4 2% 2024 Q2 6% 2024 Q4 2025 Q2 従来のアルゴリズム試験で測っていた企業が、AI 協働型へ切り替えている 2025 Q4 2026 Q2 （四半期あたりの実施比率・2026-07-29 時点）
27. WHY IT MATTERS 採用市場は、社内の評価制度より先に動いている 今日の多くのセッション この 30 分 ツール、プロセス、組織——現場の変化の記録。 人を見極める投資が集中する入口が、先に動いた。 開発現場で、 どうなったか 採用市場という、 別の観測点からの記録 見極める側が動いた、ということは測る軸は、もう移り始めている
28. 04 01 02 03 04 SECTION 04 · 軸は、どこへ移ったか 優秀なエンジニアを測る軸は、 どこへ移ったか
29. THE SHIFT 価値が下がった技術力、価値が上がった技術力 相対的に価値が下がった — AI が代替する コードを速く書く力 記法・API の暗記 実装量そのもの 価値が上がった — AI が代替できない 課題を構造化する力 — 分解 意図を言語化し AI を導く力 — 統制 出力を疑い、責任を持つ力 — 検証 軸は「AI に指示してコードを書ける」から「AI と協働して解ける」へ移った
30. THREE TRAITS — 評価現場の所見 AI 協働力が高い人の、3 つの特徴 01 コードへのこだわりより、顧客の課題解決にこだわれる 02 AI に冗長な仕事を任せ、人にしか出せない価値に集中できる 03 「作って当てる」を、誰より速く回せる
31. THE LIMITS — 所見の限界 この所見で言えること、言えないこと 言えること 採用の評価現場で、 この 3 つの特徴が観測された まだ言えないこと 入社後の現場の成果と、 どこまで接続するか 試験環境での観測であり、現場成果との接続は別途検証が要 る。私たちの次の課題。
32. FOR INDIVIDUALS — 明日から鍛える 個人が明日から着手できること 統制 任せる範囲と、完了の条件を先に決 める AI は範囲を勝手に広げ、終わりを自分で判 断しない。境界と完了条件は、人が言葉で 渡す。 分解 依頼できる形になるまで、課題を刻 む AI は大きすぎる依頼も断らず、もっともら しい答えを返す。刻む単位を決めるのは人 の仕事。 検証 成果物は、壊れる条件から読む AI の出力はたいてい動くので、動作確認で は何も分からない。最も差が出る軸。
33. FOR ORGANIZATIONS 組織へ持ち帰る問い Q1 活躍している人の共通項は、統制・分解・検証のどこに現れているか？ Q2 自社の評価・登用の物差しは、「AI を使わせて測る」に追いついているか？ Q3 その質を、どう見極め、育てるか？
34. THE UNDERLYING SHIFT Learn to Ship から Ship to Learn へ これまで — Learn to Ship（Agile・Lean・Scrum） アイデア → 入念に仮説検証 → MVP → 開発 → PMF ／ 作る前にムダを潰しきる これから — Ship to Learn（Code is Cheap） 作る → 当てる → 学ぶ ↺ 最低限の検証で本物を届け、行動から学ぶ このサイクルを誰より速く回せる人を、統制・分解・検証で見極める。それが軸の変化の正体
35. ONE LAST THING その「質」は、測れる AI 協働力を含む、優秀なエンジニアを表す指標 Software Engineering Index を開発し、 300 社超・累計 100 万件の評価現場で、その可視化に取り組んでいます
36. Developers Summit 2026 KANSAI FIN. ご清聴、ありがとうございました 泉水 翔吾 株式会社ハイヤールー 取締役CTO Web: shogosensui.com X: @1000ch