生成AI導入の効果測定KPI｜開発チーム向け指標一覧と計算式・集計コード

開発チームへの生成AI導入の効果は、「利用・速度・品質・費用・体感」の5層の指標を、導入前と同じ方法で測って比べることで判断します。 利用者数や生成行数だけを見ると「使われているか」までしか分からず、PR件数だけを見ると品質の変化を見落とします。層を分けて並べると、どこが良くなり、どこに負担が移ったかが読めます。

この記事では、指標の定義と計算式の一覧、git log と gh の出力から集計するPython、導入前後を比べるSQL、金額への換算、月次報告のひな形を、貼って使える形で載せます。

確認環境（確認日 2026年10月7日）：Ubuntu 24.04、Python 3.11.15、SQLite 3.45.1、git 2.43.0、GitHub CLI 2.45.0。スクリプトとSQLはこの環境で実行し、出力をそのまま載せています。入力は、gh pr list --json の出力と同じ形に作った架空のサンプルデータ（58件）と、ローカルに作ったGitリポジトリの git log です。金額・人数・時間もすべて架空の例です。

生成AI導入の効果測定KPI早見表

ツールの管理画面で取れる指標の定義

利用層の指標は、ツールごとに数え方が決まっています。同じ「受入率」でも対象が違うため、ツールをまたいで数字を比べず、同じツールの中で推移を見ます。

GitHub Copilot の利用状況メトリクス

GitHub Docs の「Copilot usage metrics」に載っている区分です（2026年10月7日閲覧）。

データは、集計が締まってから丸2日以内に利用できるようになると案内されています。

Claude Code の分析ダッシュボード

Claude Code Docs の「Track team usage with analytics」に載っている指標です（2026年10月7日閲覧）。

PRへの帰属については、次のように説明されています。

同じページは、これらの指標をDORAメトリクスやスプリントのベロシティなど、ほかの開発指標と合わせて使うことを勧めています。ツールが出す数字は「利用」の層で、速度と品質は自分たちのリポジトリから測ります。

git log と gh の出力からPR指標を集計する

入力データを取得する

GitHub CLI でマージ済みPRをJSONで取り出し、git log でコミットの一覧を取り出します。

gh pr list --state merged --limit 1000 \
  --json number,title,createdAt,mergedAt,additions,deletions,labels,reviews > prs.json

git log --pretty=format:'%H%x09%cI%x09%s' > gitlog.tsv

--json に指定できる項目名は、gh pr list --json を引数なしで実行すると一覧が表示されます（GitHub CLI 2.45.0 で createdAt・mergedAt・additions・deletions・labels・reviews が含まれることを確認）。--limit の既定値は30件のため、期間をまたいで集計するときは大きめの値を指定します。

この記事で使ったサンプルの prs.json は次の形です（スクリプトが読む項目だけにしています）。

[
  {
    "number": 158,
    "title": "機能158の変更",
    "createdAt": "2026-09-02T16:00:00Z",
    "mergedAt": "2026-09-05T16:00:00Z",
    "additions": 20,
    "deletions": 5,
    "labels": [],
    "reviews": [
      {"author": {"login": "reviewer1"}, "state": "CHANGES_REQUESTED", "submittedAt": "2026-09-03T16:00:00Z"},
      {"author": {"login": "reviewer1"}, "state": "APPROVED", "submittedAt": "2026-09-05T15:30:00Z"}
    ]
  },
  {
    "number": 157,
    "title": "機能157の変更",
    "createdAt": "2026-09-26T17:00:00Z",
    "mergedAt": "2026-09-26T20:00:00Z",
    "additions": 40,
    "deletions": 10,
    "labels": [{"name": "ai-assisted"}],
    "reviews": [
      {"author": {"login": "reviewer1"}, "state": "CHANGES_REQUESTED", "submittedAt": "2026-09-26T18:00:00Z"},
      {"author": {"login": "reviewer1"}, "state": "APPROVED", "submittedAt": "2026-09-26T19:30:00Z"}
    ]
  }
]

gitlog.tsv は、ハッシュ・コミット日時・件名のタブ区切りです。

0d2654a35d0045a536d7c364beb32a15dc65efd6    2026-09-30T16:00:00+00:00   Merge pull request #152 機能152の変更
b69bfa5ba8976cc3146116dc7065d1b33cf3db98    2026-09-30T12:00:00+00:00   Merge pull request #130 機能130の変更
7bce74d7e0f9f62f4b55bd722368473d23ed6066    2026-09-28T00:00:00+00:00   Merge pull request #147 機能147の変更

AIを使ったPRの目印は、ここでは自分たちで付ける ai-assisted ラベルとしています。Claude Code の貢献メトリクスを有効にしている場合は、自動で付く claude-code-assisted に読み替えてください。

集計スクリプト（Python）

導入日を境に、導入前と導入後の指標を並べます。標準ライブラリだけで動き、SQLで使うための prs.csv も出力します。

"""gh と git log の出力から、導入前後のPR指標を集計する。

入力の作り方:
  gh pr list --state merged --limit 1000 \
    --json number,title,createdAt,mergedAt,additions,deletions,labels,reviews > prs.json
  git log --pretty=format:'%H%x09%cI%x09%s' > gitlog.tsv

使い方:
  python3 pr_metrics.py prs.json gitlog.tsv 2026-08-01
"""
import csv
import json
import statistics
import sys
from datetime import datetime


def hours(start: str, end: str) -> float:
    fmt = "%Y-%m-%dT%H:%M:%SZ"
    return (datetime.strptime(end, fmt) - datetime.strptime(start, fmt)).total_seconds() / 3600


def main(pr_path: str, log_path: str, split: str) -> None:
    with open(pr_path, encoding="utf-8") as f:
        prs = json.load(f)

    rows = []
    for p in prs:
        rows.append({
            "number": p["number"],
            "created_at": p["createdAt"],
            "merged_at": p["mergedAt"],
            "lead_h": round(hours(p["createdAt"], p["mergedAt"]), 1),
            "lines": p["additions"] + p["deletions"],
            "ai_assisted": int(any(lb["name"] == "ai-assisted" for lb in p["labels"])),
            "changes_requested": int(any(r["state"] == "CHANGES_REQUESTED"
                                         for r in p["reviews"])),
        })

    # SQLで使えるようにCSVも出力する
    with open("prs.csv", "w", encoding="utf-8", newline="") as f:
        w = csv.DictWriter(f, fieldnames=list(rows[0]))
        w.writeheader()
        w.writerows(rows)

    # git log からマージコミットと Revert コミットを数える
    merges = {"導入前": 0, "導入後": 0}
    reverts = {"導入前": 0, "導入後": 0}
    with open(log_path, encoding="utf-8") as f:
        for line in f:
            _sha, date, subject = line.rstrip("\n").split("\t", 2)
            period = "導入前" if date[:10] < split else "導入後"
            if subject.startswith("Revert "):
                reverts[period] += 1
            elif subject.startswith("Merge pull request"):
                merges[period] += 1

    print("指標\t導入前\t導入後\t差")
    groups = {
        "導入前": [r for r in rows if r["merged_at"][:10] < split],
        "導入後": [r for r in rows if r["merged_at"][:10] >= split],
    }
    b, a = groups["導入前"], groups["導入後"]

    def line(name, fb, fa, unit="", nd=1):
        print(f"{name}\t{fb:.{nd}f}{unit}\t{fa:.{nd}f}{unit}\t{fa - fb:+.{nd}f}{unit}")

    line("マージしたPR数", len(b), len(a), "件", nd=0)
    line("リードタイム中央値", statistics.median(r["lead_h"] for r in b),
         statistics.median(r["lead_h"] for r in a), "h")
    line("リードタイム75%点", statistics.quantiles([r["lead_h"] for r in b], n=4)[2],
         statistics.quantiles([r["lead_h"] for r in a], n=4)[2], "h")
    line("差分行数の中央値", statistics.median(r["lines"] for r in b),
         statistics.median(r["lines"] for r in a), "行", nd=0)
    line("レビュー差し戻し率", 100 * sum(r["changes_requested"] for r in b) / len(b),
         100 * sum(r["changes_requested"] for r in a) / len(a), "%")
    line("取り消し率（Revert）", 100 * reverts["導入前"] / merges["導入前"],
         100 * reverts["導入後"] / merges["導入後"], "%")
    line("AI利用ラベルの割合", 100 * sum(r["ai_assisted"] for r in b) / len(b),
         100 * sum(r["ai_assisted"] for r in a) / len(a), "%")


if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2], sys.argv[3])

サンプルデータ（導入前：2026年6〜7月の24件、導入後：8〜9月の34件）での実行結果です。

python3 pr_metrics.py prs.json gitlog.tsv 2026-08-01

指標  導入前 導入後 差
マージしたPR数    24件 34件 +10件
リードタイム中央値   23.0h   29.0h   +6.0h
リードタイム75%点  50.0h   72.0h   +22.0h
差分行数の中央値    100行    112行    +12行
レビュー差し戻し率   20.8%   35.3%   +14.5%
取り消し率（Revert）   8.3%    14.7%   +6.4%
AI利用ラベルの割合  0.0%    58.8%   +58.8%

このサンプルは、PR数は24件から34件に増えた一方で、リードタイム中央値は6時間延び、差し戻し率と取り消し率も上がっている、という傾向になるように作ってあります。PR数だけを報告すると「42％増」という見出しになりますが、5つの指標を並べると「出す量は増えたが、レビューと手直しに負担が移っている」と読めます。

スカッシュマージやリベースマージを使っているリポジトリでは、マージコミットの件名が変わります。その場合は分母を prs.json のマージ済みPR数に置き換えてください。

導入前後を比べるSQL（SQLite）

スクリプトが出力した prs.csv を読み込み、期間別・月別に集計します。

-- prs.csv を読み込み、導入前後を比べる（SQLite）
.mode csv
.import prs.csv prs
.mode table

-- 1. 件数・平均・差し戻し率
SELECT CASE WHEN substr(merged_at, 1, 10) < '2026-08-01' THEN '1_導入前' ELSE '2_導入後' END AS period,
       COUNT(*)                                        AS prs,
       ROUND(AVG(lead_h), 1)                           AS avg_lead_h,
       ROUND(100.0 * SUM(changes_requested) / COUNT(*), 1) AS changes_req_pct,
       ROUND(100.0 * SUM(ai_assisted) / COUNT(*), 1)   AS ai_pct
FROM prs
GROUP BY period
ORDER BY period;

-- 2. リードタイムの中央値（件数が偶数なら中央2件の平均）
WITH ranked AS (
  SELECT CASE WHEN substr(merged_at, 1, 10) < '2026-08-01' THEN '1_導入前' ELSE '2_導入後' END AS period,
         CAST(lead_h AS REAL) AS lead_h,
         ROW_NUMBER() OVER (PARTITION BY CASE WHEN substr(merged_at, 1, 10) < '2026-08-01'
                                              THEN 1 ELSE 2 END
                            ORDER BY CAST(lead_h AS REAL)) AS rn,
         COUNT(*) OVER (PARTITION BY CASE WHEN substr(merged_at, 1, 10) < '2026-08-01'
                                          THEN 1 ELSE 2 END) AS cnt
  FROM prs
)
SELECT period, cnt AS prs, ROUND(AVG(lead_h), 1) AS median_lead_h
FROM ranked
WHERE rn IN ((cnt + 1) / 2, (cnt + 2) / 2)
GROUP BY period
ORDER BY period;

-- 3. 月ごとの推移（1か月だけの上下で判断しないため）
SELECT substr(merged_at, 1, 7)                          AS month,
       COUNT(*)                                         AS prs,
       ROUND(AVG(lead_h), 1)                            AS avg_lead_h,
       ROUND(100.0 * SUM(changes_requested) / COUNT(*), 1) AS changes_req_pct
FROM prs
GROUP BY month
ORDER BY month;

sqlite3 metrics.db < compare.sql

+--------+-----+------------+-----------------+--------+
| period | prs | avg_lead_h | changes_req_pct | ai_pct |
+--------+-----+------------+-----------------+--------+
| 1_導入前  | 24  | 31.2       | 20.8            | 0.0    |
| 2_導入後  | 34  | 37.9       | 35.3            | 58.8   |
+--------+-----+------------+-----------------+--------+
+--------+-----+---------------+
| period | prs | median_lead_h |
+--------+-----+---------------+
| 1_導入前  | 24  | 23.0          |
| 2_導入後  | 34  | 29.0          |
+--------+-----+---------------+
+---------+-----+------------+-----------------+
|  month  | prs | avg_lead_h | changes_req_pct |
+---------+-----+------------+-----------------+
| 2026-06 | 13  | 33.5       | 23.1            |
| 2026-07 | 11  | 28.4       | 18.2            |
| 2026-08 | 14  | 39.1       | 28.6            |
| 2026-09 | 20  | 37.0       | 40.0            |
+---------+-----+------------+-----------------+

中央値（23.0時間・29.0時間）はPythonの結果と一致しました。平均（31.2時間・37.9時間）は中央値より大きく、長くかかった少数のPRに引っ張られていることが分かります。リードタイムのように偏りのある値は、平均ではなく中央値と75％点で見ます。 確認環境の SQLite 3.45.1 では median() が使えなかったため、順位を振って中央の行を取り出す書き方にしています。

導入前後比較の設計

数字を集める前に、比べ方を決めておきます。

比べない指標、単独では判断に使わない指標も決めておきます。

個人別の数字は、評価のためではなく、うまく使えている人のやり方をチームで共有するための手がかりとして扱うと、測定そのものが前向きに受け止められます。

行数・PR件数だけで判断した報告を直した例

【直す前】
生成AIツール導入の効果（8〜9月）
・AIが生成したコード：42,000行
・マージしたPR：24件 → 34件（42％増）
・利用者アンケート：85％が「生産性が上がった」と回答
→ 生産性が大幅に向上。全社展開を提案します。

【直した後】
生成AIツール導入の効果（導入前 6〜7月／導入後 8〜9月、開発チームA・同一リポジトリ）

1. 利用
   利用者 18／20人（90％）。AI利用ラベルの付いたPRは 58.8％。

2. 速度
   マージしたPR：24件 → 34件（+10件）
   PRリードタイム中央値：23.0時間 → 29.0時間（+6.0時間）

3. 品質
   レビュー差し戻し率：20.8％ → 35.3％（+14.5ポイント）
   取り消し率：8.3％ → 14.7％（+6.4ポイント）

4. 体感
   アンケートでは 85％が「速くなった」と回答。実測のリードタイムとは方向が異なる。

5. 読み取り
   出すPRは増えたが、レビューでの差し戻しとマージまでの時間が増えている。
   作成が速くなった分、確認の負担がレビュー側に移っていると考えられる。

6. 次に確かめること
   ・PRの大きさに上限を設けた場合の差し戻し率（10月）
   ・テストの自動判定を追加した場合の取り消し率（10〜11月）
   全社展開の判断は、上の2点を見たうえで12月に行う。

直した後は、良い数字とそうでない数字の両方が並び、次に何をするかが書かれています。

体感と実測がずれる根拠と、判断基準

自己申告だけで効果を判断しない理由を、公開されている調査で確認します（いずれも2026年10月7日閲覧）。

METR の著者は、この結果が「多くの開発者でAIが速度を上げない」ことを示すものではないと明記しています。読み取れるのは、「速くなった」という感覚と、時計で測った結果は別のものとして扱う必要があるという点です。

体感を集めるアンケートのひな形です。実測と並べやすいよう、時間は数値で聞きます。

■ 生成AIツール利用アンケート（月次・5分）

Q1. この1か月、AIツールを使った日はどのくらいですか。
    ほぼ毎日 ／ 週に2〜3日 ／ 週に1日程度 ／ 月に数回 ／ 使っていない

Q2. AIツールによって、1週間あたり何時間くらい短くなった（または長くなった）と感じますか。
    （　　　）時間 短くなった ／ （　　　）時間 長くなった ／ 変わらない

Q3. 短くなったと感じる作業を選んでください（複数可）。
    調査・既存コードの理解 ／ 実装 ／ テスト作成 ／ レビュー ／ 文書作成 ／ その他（　　）

Q4. 時間が増えたと感じる作業を選んでください（複数可）。
    生成結果の確認 ／ 指示の書き直し ／ レビュー ／ 手直し ／ 特になし ／ その他（　　）

Q5. AIが生成したコードを、内容を理解したうえで取り込めていますか。
    いつも ／ たいてい ／ ときどき ／ あまり

Q6. 困っていること、チームで共有したい使い方があれば書いてください。
    （自由記述）

時間削減を金額に直す換算表

効果を金額で示すときは、減った時間だけでなく、増えた時間（レビュー・検証）と費用を同じ表に入れます。

削減時間は、アンケートの値ではなく、同じ種類の作業を導入前後で記録した値を使います。時間単価は社内で決められた換算単価を使ってください。

効果を10割・7割・5割で見るスクリプト

"""時間の変化を金額に直し、効果を100%・70%・50%で見た場合を並べる。"""
USERS = 20              # 利用者数（人）
WEEKS = 46              # 年間の稼働週
RATE = 4_000            # 時間単価（円）社内の換算単価を使う
SAVED_H = 1.5           # 実測した削減時間（時間／人・週）
REVIEW_H = 0.4          # 増えたレビュー・検証の時間（時間／人・週）
LICENSE = 5_000         # ライセンス（円／人・月）
TOKEN = 60_000          # 従量課金の月額（円）
ADMIN_H = 4             # 集計・管理の時間（時間／月）
INITIAL = 600_000       # 初期費用（設定・ルール作成・説明会）

saved = USERS * WEEKS * SAVED_H * RATE
review = USERS * WEEKS * REVIEW_H * RATE
running = USERS * LICENSE * 12 + TOKEN * 12 + ADMIN_H * 12 * RATE

print(f"削減時間の金額換算   : {saved:>10,.0f} 円／年")
print(f"増えたレビューの金額 : {review:>10,.0f} 円／年")
print(f"年間運用費           : {running:>10,.0f} 円／年")
print(f"初期費用             : {INITIAL:>10,.0f} 円")
print()
print("効果の見込み\t年間効果\t年間の純額\t1年目の純額\t回収")
for ratio in (1.0, 0.7, 0.5):
    effect = saved * ratio - review          # 増えた時間は割り引かずに引く
    net = effect - running
    first = net - INITIAL
    payback = f"{INITIAL / net * 12:.1f}か月" if net > 0 else "回収に至らない"
    print(f"{ratio:.0%}\t{effect:,.0f}\t{net:,.0f}\t{first:,.0f}\t{payback}")

削減時間の金額換算   :  5,520,000 円／年
増えたレビューの金額 :  1,472,000 円／年
年間運用費           :  2,112,000 円／年
初期費用             :    600,000 円

効果の見込み  年間効果    年間の純額   1年目の純額  回収
100%    4,048,000   1,936,000   1,336,000   3.7か月
70% 2,392,000   280,000 -320,000    25.7か月
50% 1,288,000   -824,000    -1,424,000  回収に至らない

この例では、効果が見込みの7割だと年間の純額は28万円で、初期費用の回収に約26か月かかります。5割では運用費を下回ります。 増えたレビュー時間は見込みではなく実際に発生している時間のため、割り引かずにそのまま引いています。「削減時間」の測り方が結果を大きく左右することが分かります。

ROI・回収期間の計算表への記入例

投資判断の資料では、初期費用・年間運用費・年間効果を年ごとに並べる計算表がよく使われます。上の結果（効果7割の場合）を入れるとこうなります。

累計がプラスに転じるのは3年目です。AIツールは料金体系や性能の変化が速いため、評価期間は長く取りすぎず、半年〜1年ごとに実測値で表を更新する前提で示すと、判断する側が受け取りやすくなります。年間効果の行には「削減時間の金額 × 見込みの割合 − 増えたレビューの金額」を入れ、運用費と二重に引かないようにします。

経営向け月次報告のひな形

1ページに収まる形です。【 】を書き換えて使います。

# 生成AIツール 利用状況と効果（【2026年9月】）

対象：【開発チームA、20人、リポジトリ shop】　基準期間：【2026年6〜7月】

## 1. 今月の要点（3行）
- 【利用は定着（利用者90％）。マージしたPRは増加】
- 【レビュー差し戻し率が上昇。確認の負担がレビュー側に移っている】
- 【10月はPRの大きさの上限と自動判定の追加を試す】

## 2. 指標
| 層 | 指標 | 基準期間 | 今月 | 見方 |
|---|---|---|---|---|
| 利用 | 利用者の割合 | 【—】 | 【90％】 | 【定着】 |
| 利用 | AI利用PRの割合 | 【0％】 | 【58.8％】 | 【—】 |
| 速度 | マージしたPR数（月平均） | 【12件】 | 【17件】 | 【増加】 |
| 速度 | PRリードタイム中央値 | 【23.0時間】 | 【29.0時間】 | 【延びた】 |
| 品質 | レビュー差し戻し率 | 【20.8％】 | 【35.3％】 | 【上昇】 |
| 品質 | 取り消し率 | 【8.3％】 | 【14.7％】 | 【上昇】 |
| 体感 | 「速くなった」と回答 | 【—】 | 【85％】 | 【実測と方向が異なる】 |

## 3. 費用
| 項目 | 今月 | 累計 |
|---|---|---|
| ライセンス | 【100,000円】 | 【200,000円】 |
| 従量課金 | 【60,000円】 | 【115,000円】 |
| 合計 | 【160,000円】 | 【315,000円】 |

## 4. 金額換算（年換算・見込み）
| 効果の見込み | 年間効果 | 年間の純額 |
|---|---|---|
| 10割 | 【4,048,000円】 | 【1,936,000円】 |
| 7割 | 【2,392,000円】 | 【280,000円】 |
| 5割 | 【1,288,000円】 | 【−824,000円】 |

## 5. 分かったこと・まだ分からないこと
- 分かったこと：【PRの作成は速くなった。差し戻しは増えた】
- まだ分からないこと：【差し戻しの増加が一時的なものか。障害件数への影響】

## 6. 来月の取り組みと判断事項
- 取り組み：【PRの差分行数に上限を設定／テストの自動判定を追加】
- 判断をお願いしたいこと：【なし（展開範囲の判断は12月に提案）】

## 7. 測定方法（変更があれば記載）
- PR指標：GitHubのマージ済みPRを月初に取得し、同じスクリプトで集計
- 利用指標：ツールの管理画面の値
- 同時に起きた変化：【9月に2名が加入】

よくある質問

Q. 最初に測るべき指標は、どれですか？ A. 導入前の値が後から取れるものを優先します。PRリードタイム、差し戻し率、取り消し率はGitHubとGitの履歴から過去にさかのぼって計算できます。利用者数や受入率は導入後にしか存在しないため、導入前の基準が要る速度・品質の指標から先に定義を決めます。

Q. 導入前のデータを取っていませんでした。どうすればよいですか？ A. PRとコミットの履歴が残っていれば、この記事のスクリプトで導入前の期間を集計できます。作業時間の記録のように履歴が無いものは、これから「AIを使わない同種の作業」と「使う作業」を並べて記録し、基準を作ります。

Q. 受入率が低いのは、良くない状態ですか？ A. 低いこと自体は判断材料になりません。提案をよく読んで選んでいる結果かもしれず、高い場合も、受け入れた後の手直しは数字に表れません。受入率は推移を見る指標として使い、差し戻し率や取り消し率と並べて読みます。

Q. どのくらいの期間で効果を判断できますか？ A. 基準期間と同じ長さ（2〜3か月）を導入後にも取り、最初の2〜4週間は慣れの期間として分けて見るのが目安です。月ごとの推移を並べ、1か月だけの上下で結論を出さないようにします。

まとめ

• 指標は「利用・速度・品質・費用・体感」の5層で並べる。1つの層だけで結論を出さない
• PRリードタイムは平均ではなく中央値と75％点で見る。サンプルでは平均31.2時間に対し中央値は23.0時間だった
• PR件数と行数は単独で使わない。差し戻し率と取り消し率を必ず並べる
• ツールの管理画面の数字は「利用」の層。数え方はツールごとに違うため、同じツールの推移で読む
• 体感と実測は別の行に書く。METRの試験では、19％長くかかっていた開発者が20％短縮したと感じていた
• 金額換算では、増えたレビュー時間と費用を引き、効果7割・5割の場合も示す
• 比べ方（基準期間・対象・定義）を先に文書にすると、後から数字を説明できる

参考・出典

いずれも2026年10月7日に閲覧しました。

• GitHub Docs「GitHub Copilot usage metrics」 https://docs.github.com/en/copilot/concepts/copilot-usage-metrics/copilot-metrics
• Claude Code Docs「Track team usage with analytics」 https://code.claude.com/docs/en/analytics
• GitHub CLI マニュアル「gh pr list」 https://cli.github.com/manual/gh_pr_list
• METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」（2025年7月10日） https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• DORA「State of AI-assisted Software Development 2025」 https://dora.dev/research/2025/dora-report/
• Google Cloud Blog「Announcing the 2025 DORA Report」（2025年9月23日） https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
• @IT（GitKraken の調査の紹介記事） https://atmarkit.itmedia.co.jp/ait/articles/2609/23/news011.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。