Jellyfishで測るAI開発の効果｜契約を続けるかの根拠

「コーディングAIの契約を全員分続けるべきか、使っていない人の分を切るべきか、毎回の更新のたびに決められない」「速くなったと言われるが、バグや手戻りが増えていないか心配だ」——開発組織を預かる責任者や、AIの予算を握る経営企画から、こうした声が聞かれます。更新の時期が来るたびに、利用回数の表を前に議論が割れる。多くの開発組織が同じ場所で足踏みしています。問題は道具の良し悪しではありません。本当は、契約を続ける根拠を、利用回数ではなく開発データに残った成果と品質で示す物差しがないことが詰まりの元です。この記事では、米国の Jellyfish の考え方を手がかりに、コーディングAIの効果を測って契約を決める方法と、そのとき個人の評価に使わない線を整理します。

Jellyfishは何を測る製品か

Jellyfish は、開発組織の働きを測る基盤です。公式は自らを、ソフトウェア開発の状況を把握する基盤であり、AIの効果を測る基盤でもあると説明しています（2026年10月時点）。もともとは、開発の時間が新しい機能と保守のどちらに使われているかといった、投資の配分を見せる製品として知られていました。そこに加わったのが、コーディングAIの効果を測る「AIインパクト」の機能です。

公式の製品ページによれば、AIインパクトは、AIを使った変更と使わなかった変更で、プルリクエストが完了するまでの時間や届ける速さを比べ、時間の配分がどう動いたか、支出に対してどれだけの成果が出たかを示します。対応するコーディングAIとして、GitHub Copilot、Cursor、Claude Code、Windsurf のほか、コードの指摘を行う道具や、Devin などの自律的に動くエージェントも挙げられています。道具ごとに並べて比べられる点が、各道具の管理画面との違いです。

もう1つの特徴は、開発者への意識の調査を組み合わせられることです。2025年11月の公式ブログでは、AIの使いやすさや生産性の実感を聞く調査を、開発データと並べて見られるようにしたと説明しています。つまり Jellyfish は、記録に残った変更の数字と、開発者の実感の両方を、同じ画面で見る道具だと考えると整理しやすくなります。

作っている会社と、国内でまだ知られていない理由

Jellyfish は、米国ボストンの会社です。2026年9月24日の公式の発表では、1,000社を超える会社が利用し、27万5千人を超える開発者、1億件を超えるプルリクエストを分析してきたとしています（提供元の発表による数字）。基盤は AWS の上で動いているとも書かれています。2026年10月時点で、製品の終了や名称の変更、他社への統合の告知は見当たりません。

日本でほとんど知られていない理由は、確かめられる範囲で3つあります。1つ目は、公式サイトも発表も英語だけで、日本語の案内が見当たらないことです。2つ目は、公式の料金ページによれば、料金は利用者の席の数と選ぶ機能の組み合わせで決まり、金額は公開されておらず、問い合わせが入り口になっていることです。3つ目は、対象が数百人規模の開発組織を持つ会社に寄っていることです。公式の発表に名前が出る利用企業も、米国の大きな会社が中心です。

国内では、コーディングAIの効果は、各道具の管理画面にある利用の数字か、開発者への聞き取りで確かめるのが普通でした。複数の道具をまたいで、開発データと突き合わせて測る、という棚そのものがまだ小さいのが実情でしょう。この記事は Jellyfish を勧めるものではなく、この種の道具が何を測り、何を測れないかを手がかりに、契約の判断の物差しを組み立てることを目的にしています。

2026年10月の発表で何が加わったか

2026年10月7日、Jellyfish は初めての「AIインパクト週間」に合わせて新しい機能群を発表しました。公式の発表は、機能を3つの問いに分けて並べています。1つ目は「自分たちはどこにいるか」で、開発の流れ全体で時間がどこに使われているかを見る機能や、AIの使い方で開発者を群に分けて追う機能、人と自律的なエージェントの働きを同じ指標で並べる機能などです。自然文で独自の指標を作れる機能や、対話の助手も含まれています。

2つ目は「変われているか」で、どのAIの技能や使い方がどのチームに広がっているかを追う機能と、エージェントとの働き方を見る行動の指標です。3つ目が「いくらの価値があるか」で、道具とモデルごとのトークンの使用量と支出、AIの支出を施策や成果物、計画の領域に紐づける機能、他社と比べた費用の目安、人件費と並べた研究開発費の総額、人数で割ったAIによる能力の変化が挙げられています。

注意したいのは、発表では「提供を開始した」と書かれている一方、機能ごとの提供の段階（一般提供か、早期提供か）は明記されていないことです。契約の前に、自社で使いたい機能がすでに使える状態か、追加の料金がかかる機能かを確かめてください。以下では、これらの機能を「契約を続けるかを決める」という1つの問いに引きつけて読んでいきます。

課題：契約を続けるかの判断が割れる

コーディングAIの契約の更新で判断が割れるのは、たいてい次の場面です。開発の責任者は「速くなった」と言い、経営企画は「費用に見合う根拠を出してほしい」と言い、現場の一部は「使っていない人の分は無駄だ」と言う。それぞれ正しいことを言っているのに、手元にある数字が利用回数と席の数だけなので、議論がかみ合いません。

さらに2026年は、判断の材料そのものが動いています。Jellyfish の発表で、トークンの使用量と支出を道具・モデルごとに追う機能が前面に出ているのは、席の定額だけでなく、使った量に応じて費用が増える契約が広がっているからです。席の数を数えれば費用が読めた時代から、使い方によって月ごとに費用が動く時代に変わりつつあります。

判断が割れたまま更新を迎えると、結論は「とりあえず全員分を続ける」か「一律に減らす」のどちらかになりがちです。どちらも、どのチームでどの道具が効いているかを見ていない点で同じです。AIツール全体の費用の棚卸しの手順は別の記事に譲り、ここでは開発組織のコーディングAIに絞って、割れる原因を3つに分けて見ていきます。

原因1：利用回数しか見ていない

最初の原因は、判断の材料が各道具の管理画面にある利用の数字だけになっていることです。何人が使ったか、提案がいくつ受け入れられたか、という数字は手に入りやすい一方、受け入れた提案がその後どうなったかは教えてくれません。提案を多く受け入れたのに、レビューで大きく手直しされた、という変更も同じ1回に数えられます。

Jellyfish の2026年10月の発表で、開発の流れ全体で時間がどこに使われているかを見る機能が先頭に置かれているのは、この点に関わります。公式は、この機能で「詰まっているのはコードを書く工程ではなく、レビューの工程ではないか」を確かめられると説明しています。書く速さが上がっても、レビューの待ちが伸びていれば、届く速さは変わらないからです。

利用回数の読み方そのものは、社内のAIの利用率を扱った別の記事に譲ります。ここで押さえたいのは、利用回数は契約を続ける根拠の入口の数字であって、結論の数字ではないということです。回数が多いことは「使われている」ことを示しますが、「効いている」ことは示しません。

原因2：成果と品質を同じ物差しで見ていない

2つ目の原因は、速さの数字と品質の数字を、別々の人が別々の場所で見ていることです。開発の責任者は、プルリクエストの数や完了までの時間が改善したと報告します。一方で、品質の担当は、不具合の件数や手戻りを別の表で追っています。2つを同じ期間・同じチームで並べないと、「速くなった代わりに壊れやすくなった」のかどうかが分かりません。

提供元の調査の数字も、この点に注意して読む必要があります。Jellyfish が2026年3月に公表した調査では、700社超・20万人の開発者・2,000万件のプルリクエストをもとに、AIの導入が上位4分の1の会社は、低い会社の2倍のプルリクエストを出していたとしています（提供元の調査による）。ただし、同じ発表には、不具合や差し戻しの数字は示されていません。数が増えたことと、品質が保たれたことは別に確かめる必要があります。

Jellyfish の製品ページは、速さと品質と処理量を前後で比べられると説明していますが、2026年10月時点の公開の資料では、品質を何で測るか（不具合の件数か、差し戻しか、手戻りか）の具体は確かめられませんでした。公式の対応先の一覧には、コードの品質を測る道具も含まれています。どの品質の指標を、どの道具から取り込めるかは、契約の前に確かめる項目です。

原因3：個人の比較になり、現場が嫌がる

3つ目の原因は、測れるようになった瞬間に、個人を比べる話にすり替わることです。公式の製品ページによれば、Jellyfish のAIインパクトは、AIの影響を個人・チーム・リポジトリ・コードの領域の単位まで掘り下げられると説明しています。道具としては、個人の単位の数字を見ることができるわけです。

ここで「AIを使っていない人」や「AIを使っても速くならない人」を一覧にし始めると、測る意味が崩れます。開発者は、数字を良く見せるために、変更を細かく分けたり、提案を受け入れてから手で直したりするようになります。測られることが分かった数字は、測りたかったものを表さなくなるのです。2026年10月の発表には、AIの技能の広がりを見る機能や、エージェントとの働き方を見る行動の指標も含まれており、使い方次第で個人の評価にも転用できてしまいます。

公式の製品ページには、個人の評価にこの数字を使うべきかどうかについての記載は見当たりませんでした。つまり、個人の評価に使わない線は、道具ではなく自社が引くことになります。全社のAI活用の測定で個人を監視しない線については、Larridin を扱った別の記事でも触れています。ここでは開発組織に限って、次の節から対策を見ていきます。

原因ごとの対策を一覧にする

3つの原因には、それぞれ別の対策が要ります。どれか1つだけ手当てしても、残りの原因で判断が割れ続けます。原因と対策、そのときに道具に任せることと人が決めることを並べると、次のようになります。

原因	対策	道具に任せること	人が決めること
利用回数しか見ていない	チーム単位で、届くまでの時間と詰まる工程を見る	AIが関わった変更の検出、完了までの時間の集計、工程ごとの待ちの可視化	どの工程の数字を契約の判断に使うか
速さと品質を別々に見ている	速さの横に品質の指標を並べ、同じ期間・同じチームで比べる	速さと品質の数字を同じ表に並べる集計	品質を何で測るか、どこまでの悪化を許すか
試す期間と比べ方がない	試す期間・比べる相手・判断の日を先に決める	期間の前後とAIの有無での比較の集計	比べる相手の選び方、判断の基準と結論
個人の比較になる	個人の評価に使わない線を文書にし、見せる単位をチームに限る	閲覧の権限の設定、チーム単位の集計	誰が個人の単位を見てよいか、例外の承認

表の右端の列は、どれも数字では決まらないことです。どの数字で判断するか、どこまでの悪化を許すか、誰が何を見てよいかは、開発の責任者と経営企画、場合によっては人事が話し合って決めます。道具の働きは、決めた物差しの数字を速く正確にそろえることにとどまります。

対策1：チーム単位の物差しを先に決める

最初に決めるのは、契約の判断に使う数字の単位です。単位はチームにします。個人の単位の数字は、ばらつきが大きく、担当する仕事の種類によって大きく変わります。新しい機能を作る人と、古い仕組みの保守をする人では、AIの効き方がもともと違います。チームの単位なら、こうした違いがならされ、仕事の種類ごとの傾向として読めます。

数字は、届くまでの時間、レビューの待ち、時間の配分の3つから始めるのが分かりやすいでしょう。Jellyfish の製品ページでは、AIの導入で新しい機能の開発と保守の時間の配分がどう動いたかを見られると説明しています。速くなった時間が、新しい機能に回ったのか、手戻りの対応に消えたのかは、契約を続ける根拠として最も説得力のある数字の1つです。

物差しは、道具を入れる前に文書にしておきます。道具を入れてから数字を眺めて物差しを選ぶと、都合のよい数字だけを拾ってしまいます。「この3つの数字が、この期間でこう動いたら続ける」と先に書いておけば、更新の議論は数字の読み合いではなく、決めた基準に照らす作業になります。

対策2：速さの横に品質の指標を並べる

次に、速さの数字の横に、必ず品質の数字を並べます。品質の指標は、本番での不具合の件数、変更の差し戻しや取り消しの件数、リリース後の手直しの件数などから、自社がすでに記録しているものを選びます。新しく測り始める指標より、過去の分も記録が残っている指標のほうが、AIの導入の前後で比べられます。

並べ方は、同じ期間・同じチームです。四半期ごとに、チームごとに「届くまでの時間」と「不具合の件数」を横に並べ、どちらかだけが動いていないかを見ます。速さが上がって品質が保たれていれば、契約を続ける強い根拠になります。速さが上がって品質が下がっていれば、道具を止める前に、レビューの体制を見直すのが先です。

ここで、どこまでの悪化を許すかは人が決めます。AIに「品質は許容の範囲か」と判断させてはいけません。不具合の重さは件数では表せず、顧客に影響した1件は、社内で気づいた10件より重いことがあります。AIが書いたコードの受け入れ基準や、人が読む範囲の決め方は、AIが主に書く開発の進め方を扱った別の記事に譲ります。

対策3：試す期間と比べ方を決める

3つ目は、試す期間と比べ方です。道具を入れた直後の数字は、慣れていないことによる遅れや、目新しさによる使いすぎで揺れます。前後で比べるなら、慣れるまでの期間を除いてから測る必要があります。比べ方は、導入の前と後、AIをよく使うチームとあまり使わないチーム、道具Aと道具Bの3通りがあり、どれを使うかで結論が変わります。

道具どうしを比べるときは、特に注意が要ります。チームごとに使う道具が違えば、道具の差なのか、チームの仕事の差なのかが分かりません。できれば、同じ種類の仕事をする2つのチームで、期間を決めて道具を入れ替えて比べる、といった設計にします。提供元の調査の数字は、自社の比べ方の代わりにはなりません。

対策4：個人の評価に使わない線を文書にする

4つ目は、個人の評価に使わない線を、道具を入れる前に文書にすることです。書くのは、数字を見る単位はチームまでとすること、個人の単位の数字を人事の評価や順位付けに使わないこと、個人の単位を見てよい人と目的を限ることの3点です。道具の側で個人の単位まで掘れる以上、口約束では守られません。

閲覧の権限も、この線に合わせます。Jellyfish のトラストセンターでは、同社の社員のアクセスについて最小権限と役割に基づく管理をうたっていますが、顧客の社内で誰が何を見られるかの細かな設定は、公開の資料では確かめられませんでした。個人の単位の画面を誰が開けるかを、契約の前に提供元に確かめ、開けるのは開発の責任者など最小限に限ります。

そして、開発者に先に説明します。何を測り、何に使い、何に使わないかを、導入の前に開発者全員に伝えます。測られていることを後から知った開発者は、数字を信じなくなり、意識の調査にも本音を書かなくなります。説明の場では、数字の目的が「道具の契約を決めること」であって「人を比べること」ではないと、経営の側から言葉にして伝えることが効きます。

費用の側：AIの支出を作業に紐づけて読む

契約の判断には、効果の数字と並んで費用の数字が要ります。Jellyfish の2026年10月の発表では、道具・モデルごとのトークンの使用量と支出を追う機能、提供元のAPIが報告する費用と利用の記録から求めた費用を突き合わせる機能、そして支出を施策や成果物に紐づける機能が挙げられています。席の定額と使った量の課金が混ざる今の契約では、こうした突き合わせがないと、何にいくら使ったかが見えません。

ただし、支出を作業に紐づけた数字は、そのまま「この施策のAIの費用は高すぎる」という結論にはなりません。難しい仕事ほど、AIに長く考えさせ、多くのトークンを使うのは自然なことです。支出の多さは、効果の数字と並べて初めて意味を持ちます。費用だけを見て道具を絞ると、最も効いていた使い方を止めることになりかねません。

Jellyfish 自体の費用は、公式の料金ページによれば、席の数と選ぶ機能の組み合わせで決まります。開発者が増えれば席の分が増え、機能を足せば機能の分が増えます。AIの費用を減らすための道具の費用が、減らせた分を上回らないか、という当たり前の確認も、契約の前にしておきます。

何が社外に出るか、誰の資格でつなぐか

この種の道具は、プルリクエストや課題の管理、コーディングAIの利用の記録といった、開発の中心にあるデータにつなぎます。公式の対応先の一覧には、課題の管理の道具として Jira などが挙げられています。つなぐときの資格は、個人の開発者のアカウントではなく、管理用の役割にひもづけ、読むだけの権限に絞るのが基本です。

社外に出るものとして確かめたいのは、コードの中身まで読むのか、変更の件数や時刻といった付随する情報だけなのか、という点です。Jellyfish のトラストセンターでは、基盤が AWS の上で動くこと、SOC 1 と SOC 2 の監査報告を毎年受けること、通信と保存の暗号化が説明されています（2026年10月時点）。一方、コードの中身を読むかどうか、顧客のデータをAIの学習に使うかどうか、データを置く地域は、公開の資料では確かめられませんでした。

これらは、契約の前に提供元に書面で確かめる項目です。同社のトラストセンターでは、監査の報告書やデータの流れの図を求めに応じて出すとしています。社内の決まりで、ソースコードや開発のデータを海外の事業者に預けるのに情シスやセキュリティの担当の確認が要るなら、その手続きを先に通します。社員のPCで動くエージェントそのものの統制は、別の記事で扱います。

契約を見直す前に揃える数字

ここまでの対策を、更新の判断の前にそろえる数字として並べ直します。道具を入れていなくても、自社の開発データと各道具の管理画面から、多くは手作業でそろえられます。道具を入れるかどうかは、この一覧を手作業でそろえるのが重すぎると分かってから判断しても遅くありません。

• 判断の日と、決める問い（全員分を続けるか・どれに絞るか）が1つに決まっている
• チーム単位で見る速さの数字（届くまでの時間・レビューの待ち）を、導入の前の期間も含めてそろえた
• 速さの横に並べる品質の数字（本番の不具合・差し戻し・手直し）を、同じ期間・同じチームでそろえた
• 時間の配分（新しい機能か、保守か）が、導入の前後でどう動いたかを確かめた
• 道具ごとの費用を、席の定額と使った量の課金に分けて、月ごとにそろえた
• 比べる相手（前後・チームどうし・道具どうし）と、慣れるまでの期間を除いた測る期間を決めた
• 許せる品質の悪化の幅を、測り始める前に文書にした
• 個人の評価に使わない線と、個人の単位を見てよい人を文書にし、開発者に説明した

8つのうち、最後の2つは数字ではありません。しかし、この2つが欠けていると、残りの6つの数字は、議論の中で都合よく読み替えられてしまいます。数字をそろえる前に、読み方の決まりをそろえておく。それが、契約を続けるかの根拠を、誰が見ても同じ結論になる形にするいちばんの近道です。

道具に任せる工程と、人が決める工程

最後に、道具と人の分担を整理します。道具に任せてよいのは、AIが関わった変更の検出、速さ・品質・費用の数字の集計、傾向の要約までです。2026年10月の発表にある対話の助手のように、AIに数字の傾向を説明させる使い方も、下調べとしては役に立ちます。ただし、AIの要約には、どのチームの、どの期間の、どの数字をもとにしたかを必ず添えさせます。

人が決めるのは、どの数字で判断するか、品質の悪化をどこまで許すか、契約を続ける・絞る・止めるの結論、そして個人を比べないことです。AIに「この道具は続けるべきか」と判断させてはいけません。契約の判断には、数字に表れない事情、たとえば特定の仕事でしか使えない道具の価値や、乗り換えの手間が入るからです。

• 個人の単位の数字で「AIを使っていない人」の一覧を作り、評価や面談に使う
• 利用回数や提案の受け入れの数だけで、契約を続けるかを決める
• 速さの数字だけを報告し、同じ期間の不具合や差し戻しの数字を並べない
• 提供元の調査の数字を、自社の効果の根拠としてそのまま経営に出す
• AIの対話の助手に契約の結論を出させ、根拠の数字を人が確かめない

まとめ

Jellyfish は、開発データからコーディングAIが関わった変更を見つけ、効果と費用を測る基盤で、2026年10月にはAIの支出と作業の紐付けや、開発の流れ全体の分析などを発表しました。契約の判断が割れる原因は、利用回数しか見ない、速さと品質を別々に見る、個人の比較になる、の3つです。チーム単位の物差しと品質の指標を先に決め、試す期間と比べ方をそろえ、個人の評価に使わない線を文書にする。変更の検出と集計は道具に任せ、契約の判断と品質の評価は人が持つ。この順番で、次の更新の根拠を組み立ててください。

• 製品の機能・データの扱い・料金の仕組みは、Jellyfish の公式ニュースルーム（2026年3月17日・9月24日・10月7日）、公式の製品ページ、トラストセンター、料金ページ、公式ブログを2026年10月20日に確かめた範囲に基づきます。機能ごとの提供の段階は公開の資料に明記されていないため、利用前に提供元に確かめてください
• 文中の利用社数・分析した件数・調査の結果は、提供元の発表・調査による数字です。自社の効果は、自社の開発データで確かめてください
• 開発者の働きに関わる数字の扱いは、社内の人事の決まりや労務の取り決めに関わることがあります。運用は人事・法務の担当者と確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。