毎日Claude Codeを開いて仕事をしている、あなたに向けた話です。1人で受託をしている人、数人のチームでサービスを作っている人。そういう小さな現場ほど、この数字は効きます。
海外の開発者が、Claude Codeの「変更のお知らせ一覧」をぜんぶ数えました。2025年4月2日の0.2.21から、2026年9月3日の2.1.260まで。385バージョン、5,132項目です。そして中身をグラフにしたら、はっきりした変化が見えました。
「新しく増やしました」が減って、「直しました」が増えていたんです。しかも更新の回数はほぼ同じなのに、1回あたりの中身は13倍。この記事では、その数字が何を意味するのか、そしてあなたが自分の仕事で同じ見方をどう使えるのかを、順番に噛みくだいていきます。
発端は、たった1行の「diffパネル追加」だった
分析したのは、Alejandro ARさんという方です。検索サービスの会社Bonsaiのブログに、2026年9月4日、2分で読める短い記事として公開されました。
きっかけは、変更のお知らせに載っていた1行でした。
会話の横（フルスクリーン表示のとき）に開く差分パネルを追加。Claudeが編集していく様子に合わせて、まだ保存確定していない変更を表示する。
/diffで切り替えできる。
ここで出てくる「差分パネル」＝かんたんに言うと、どこが書き換わったかを色付きで見せてくれる画面のことです。「まだ保存確定していない変更」というのは、作業はしたけどまだ正式に記録していない状態のこと。たとえるなら、原稿に赤ペンを入れた直後で、まだ清書していない状態です。
Alejandroさんはこの1行を見にいったついでに、ページをずっと下までスクロールしました。そして、量と日付の多さに驚いて「これ、グラフにしたい」と思ってしまった。だから全部やった、と書いています。
やり方はシンプルです。5,132個の項目を、先頭に来ている動詞（言葉）で仕分けしただけ。「added（追加した）」「fixed（直した）」「improved（良くした）」、それ以外は「Other（その他）」。それだけで、開発チームの様子がくっきり浮かび上がりました。
なぜこれが貴重かというと、Claude Codeは中身のプログラムが公開されていないからです。外から見える手がかりは、この変更のお知らせしかありません。つまりこのグラフは、閉じたドアの隙間から中をのぞく、数少ない方法なんです。
「増やす」から「直す」へ、中身がひっくり返った
いちばん面白いのが、項目の中身の割合です。
2025年7月の時点では、「added（追加した）」で始まる項目が41%もありました。10行あれば4行が「新しく増やしました」だったわけです。
ところが2026年の半ばには、その割合が6〜10%まで下がっています。代わりに増えたのが「fixed（直した）」で、2026年2月以降は一度も56%を下回っていません。
たとえるなら、家づくりです。
最初は部屋を増やす時期。リビングを広げ、屋根裏を作り、ベランダを付ける。楽しいし、見た目もどんどん変わる。
でもある時期から、работа の中心が変わります。雨漏りを直す。ドアの立て付けを調整する。床のきしみを消す。見た目は変わらないのに、住み心地は毎日よくなっていく。
Claude Codeは、いま完全にこの「直す時期」に入っているということです。
ここで大事なのは、これは悪いニュースじゃないということ。新機能が減ったのは、伸びしろが尽きたからとは限りません。むしろ「毎日の仕事道具として、壊れないことのほうが大事になった」と読むほうが自然です。
一歩踏み込んだ話をします。中級者のあなたに効く部分です。
道具が「追加中心」のときと「修正中心」のときでは、あなた側の付き合い方も変えたほうが得です。追加中心の時期は、新機能を試す時間を取る価値が大きい。毎週のように、できることが増えていくからです。
一方、修正中心の時期にやるべきなのは、自分の作業の型を固めることです。よく使う指示文を保存しておく。プロジェクトごとのルールを書いたファイル（CLAUDE.mdなど）を整える。同じ手順を毎回きちんと再現できるようにする。土台が安定している時期は、その上に自分の仕組みを積むのがいちばん効率がいい。
落とし穴も1つ。「fixedが多い＝不具合だらけ」と読むのは早合点です。修正が多いのは、それだけ多くの人が使っていて、細かい報告が届いているからとも読めます。数字は「何が多いか」しか教えてくれません。理由は別に考える必要があります。
リリースの回数は同じ。なのに中身は13倍
もうひとつの数字が、さらに驚きです。
- 2025年4月：56項目 / 27バージョン
- 2026年8月：735項目 / 28バージョン
バージョンの数は27回と28回。ほぼ同じです。なのに中身の項目数は56個から735個。13倍になっています。
割り算してみましょう。1バージョンあたりの項目数は、約2件から約26件へ。1回の更新に詰め込まれている量が、まるごと変わったということです。
出している日にちも調べられています。18か月のうち、258日でリリースが行われました。18か月はだいたい540日くらいなので、ほぼ2日に1回のペースです。
そして休みの取り方。日曜のリリースはたった6日。土曜は27日ありました。つまり、日曜はほぼ休み、土曜はときどき出している、という平日中心のリズムです。
ここが地味にすごいところです。「毎日ムチャクチャに働いて量を出した」わけではない。リズムは崩さず、1回の中身だけが13倍になったんです。
Alejandroさん自身も、記事の中で「自分がずっと見てしまうのはこの一貫性の部分だ」と書いています。回数もペースもほとんど動かないのに、中に入る量だけが増えていく。この形が珍しいということです。
なぜこうなるのか：Claude CodeはClaude Codeで作られている
記事の中に、答えのヒントになる一文があります。
Claude Codeは、Claude Code自身を使って開発されている、という事実です。これは公開されている話です。
その上でAlejandroさんは、こう見立てています。「だから、この量のかなりの部分はAIの分身（＝かんたんに言うと、人の代わりに手を動かすAI）がやった作業で、人間はボタンを押しているのだろう」と。
ここは大事なので分けて書きます。
- 事実：Claude CodeはClaude Codeで作られている。回数は横ばいで中身は13倍。
- 見立て：だからAIが手を動かし、人が確認して出している──これは著者個人の推測です。中身が公開されていない以上、外から確かめるすべはありません。著者本人も「外からは確認できない」と正直に書いています。
でも、この見立てが正しいかどうかは、実はそこまで重要ではありません。大事なのは、「回数を増やさずに中身だけを厚くする」という働き方が、実際に18か月続いているという事実のほうです。
これ、あなたの仕事にもそのまま当てはまります。
多くの人は忙しくなると「回数」を増やそうとします。投稿の本数、面談の件数、納品の数。でもここで起きているのは逆です。回数は固定したまま、1回の中身を濃くしていく。休む日はちゃんと休む。ペースは崩さない。
AIを使う目的が「もっとたくさん回す」ではなく「同じ回数で中身を濃くする」に変わると、働き方の設計そのものが変わります。
日本のあなたが真似るなら：自分の仕事に「変更ログ」をつける
ここからが本題です。この分析、そっくり真似できます。しかもプログラムの知識はいりません。
やることは3つだけ。
ステップ1：やったことを1行ずつ書き出す
日報でもSlackの投稿でも、コミットの履歴でもかまいません。1週間ぶんで十分です。1行1件、短く。
ステップ2：先頭の言葉を3つにそろえる
「追加した」「直した」「良くした」の3つだけ。どれにも入らないものは「その他」。Alejandroさんがやったのと同じやり方です。
ステップ3：数えて割合を見る
追加が多いなら、あなたはいま「広げる時期」。修正が多いなら「固める時期」。どちらが良い悪いではなく、いまどっちにいるかを自覚できているかが大事です。
自覚がないと、こういうズレが起きます。会社は新規顧客を増やしてほしいのに、あなたの1週間は9割が既存の手直しだった。数字を出すまで、誰も気づけません。
コピペで使える診断プロンプト
あなたは仕事の進み方を分析する編集者です。以下は私の直近1週間の作業記録です。専門用語を使わず、中学生にも分かる言葉で答えてください。 ［ここに1行ずつ、やったことを貼る］ 次の手順で分析してください。 (1) 各行を「追加した（新しく作った）」「直した（不具合や間違いを修正した）」「良くした（既にあるものを改善した）」「その他」の4つに分類し、件数と割合を表にする。 (2) 割合から、私がいま「広げる時期」と「固める時期」のどちらにいるかを1文で判定する。 (3) 次の4項目を0〜10点で採点し、点数の理由を各1行で書く。 A 新しいことに手を出せている度合い B 過去の問題を放置していない度合い C 作業ペースの安定度（曜日の偏りがないか） D 1件あたりの中身の濃さ (4) 最後に、来週やるべきことを3つ、優先順位をつけて提案する。 推測で数字を作らないでください。記録に書かれていないことは「記録からは判断できません」と書いてください。
点数が低かったときの打ち手（1行ずつ）
- A（新しいことに手を出せていない）が低い → 来週の予定に「試すだけの30分」を1コマ先に入れる。空いたらやる、では永遠に来ません。
- B（過去の問題を放置している）が低い → 未対応リストの上から3件だけを、期限つきで今週の予定に移す。全部やろうとすると1件も終わりません。
- C（ペースが不安定）が低い → 作業日を週4日に固定し、残りは意図的に空ける。日曜6日しか動いていないClaude Codeチームと同じ考え方です。
- D（1件あたりが薄い）が低い → 件数の目標を下げ、1件にかける時間を1.5倍にする。回数ではなく中身で勝負する形に切り替えます。
業種別の穴埋め例1：ECの在庫発注
［ここに1行ずつ］の部分を、こう埋めます。
「新商品を3点追加した」「Aの在庫切れを直した」「発注のタイミング表を良くした」「セール用のページを追加した」──こんな調子で1週間ぶん。
このとき「追加した」ばかりで「直した」がゼロなら要注意です。商品を増やす一方で、欠品や誤発注の見直しに手が回っていない可能性があります。
業種別の穴埋め例2：問い合わせの一次対応
「よくある質問の返信文を3本追加した」「送料の案内が古かったので直した」「返信テンプレの言い回しを良くした」「対応漏れの見落としを直した」など。
ここで「直した」ばかりが続くなら、同じ場所で何度もつまずいているサインです。個別対応をやめて、質問そのものが来ない形（案内文の改善）に投資する合図になります。
中級者向け：グラフを信じすぎないための3つの注意点
Alejandroさん自身が、記事の最後で正直に注意書きを残しています。ここが、この分析をいちばん信頼できるものにしている部分です。あなたが自分でデータを取るときも、同じ罠にはまります。
注意点1：2025年4月2日の17リリースは、実際の作業日ではない
この日だけ、1日に17回のリリースが記録されています。でもこれは、変更のお知らせページを最初に作ったときに、過去ぶんをまとめて流し込んだだけ。実際に17回出したわけではありません。
あなたのデータでも同じことが起きます。ツールを導入した初日、データを移した日。そういう日は必ず不自然に跳ねます。先に除外するか、最低でも注記をつけてください。
注意点2：「その他」はカテゴリではない
Alejandroさんははっきり書いています。「Otherはカテゴリじゃない。added / fixed / improved で始まらない項目に対して、私の分類器が諦めただけだ」と。
これ、めちゃくちゃ誠実です。「その他が◯%」という数字は、分類の失敗率であって、実態を表す数字ではありません。あなたが自分の作業を分けるときも、「その他」が多いなら「私の分け方が粗い」と読むべきで、「雑多な仕事が多い」と読むのは間違いです。
彼はさらに、「その他が人間の手書き部分だったら面白いんだけど、外からは確認できない」と書いています。面白い仮説を思いついても、確かめられないなら確かめられないと書く。この姿勢が、数字を扱う仕事のお手本です。
注意点3：分け方そのものが粗い
5,132項目を、先頭の動詞だけで分類しています。これはとても大ざっぱなやり方です。「小さなバグ修正」も「重大な不具合の修正」も、同じ「fixed」1件として数えられます。
だから「修正が56%」という数字は、重さを無視した件数の話です。件数と重さは別もの。あなたの1週間の記録でも、「5分で終わった修正」と「丸一日かかった修正」を同じ1件で数えていることを、忘れないでください。
それでも、この分析には価値があります。粗くても、18か月ぶんを同じ物差しで測り続けているからです。物差しがそろっていれば、変化の向きは正しく見えます。完璧なデータを待つより、粗くてもそろった物差しで測り始めるほうが、ずっと実用的です。
※本記事は2026年9月時点の情報です。数字はAlejandro AR氏が公開チェンジログを集計した個人分析にもとづき、開発体制に関する解釈は同氏の見立てです。
まとめ：今日・1週間・1か月でやること
Claude Codeの18か月は、こう要約できます。回数は変えず、中身を13倍にして、日曜は休んだ。 そして仕事の中身は「増やす」から「直す」へ移った。
あなたがここから持ち帰れるものを、時間軸で並べます。
今日（15分）
Claude Codeで /diff を打って、差分パネルを開いてみてください。フルスクリーン表示にすると、会話の横に、まだ確定していない変更が出ます。この記事のきっかけになった、まさにその機能です。使ってみて初めて、「なぜこれが追加されたか」が腹に落ちます。
1週間（30分×1回）
自分の直近1週間の作業を、1行ずつ書き出してください。そして上のプロンプトに貼って診断する。追加・修正・改善の割合が出たら、それが今のあなたの立ち位置です。会社やクライアントが求めている方向とズレていないか、その場で確認してください。
1か月（毎週15分）
同じ診断を毎週まわして、割合の変化を並べてください。4回たまれば、それはもうあなた専用の「変更ログ」です。Alejandroさんが385バージョンでやったことを、あなたは4週間ぶんでやることになります。
大事なのは、同じ物差しで測り続けること。粗くていい。完璧でなくていい。18か月続けば、あなたの働き方も、外から見て分かる形になります。
