タグ: AI / Claude Code / Cursor / LOC / 生成AI
きっかけ
最近、とある経営者の方のインタビュー記事を見かけました。
「非エンジニアの自分が、2ヶ月でコードを10万行書いた」
最初に思ったのは、これだけです。
10万行って……短期間でそんなに一人で書けるの？
すごい量だな、と素直に驚きました。でも同時に、こんな疑問も湧いてきました。
そもそもLOCって何を数えてるんだ？
AIで開発してるとき、行数って一体どうやってカウントしてるの？
気になって、自分でも調べてみることにしました。この記事は、その調査の記録です。特定の誰かを批判する話ではなく、「AI時代に"行数"ってどう捉えればいいんだろう」という、多くの人が一度は思ったことのある疑問への自分なりの回答です。
私は獣医師で、本業はソフトウェアエンジニアではありません。ただ、AIを使って自分の業務用ツールを個人開発する中で、この疑問にぶつかりました。専門知識がなくても読めるように書きます。
LOCって、そもそも何ですか
LOC（Lines of Code）は、単純に言うと「コードの行数」です。
昔からソフトウェア開発の世界では、「このプロジェクトは何行あるか」で、なんとなくの規模感を掴む習慣があるそうです。1000行より10000行の方が、だいたいは大きくて複雑、というイメージ。行数から逆算して開発コストや納期を見積もる材料にも、長らく使われてきました。
昔はこうだった・・・らしい
ただし「LOCで規模を測る」というやり方には、昔から弱点がありました。プログラミング言語によって、同じ機能でも書ける行数が全然違うんです。同じ処理でも、言語Aだと100行、言語Bだと20行で書けたりする。
だから「行数だけで規模を比較するのは無理がある」という問題意識自体は、実はAIが登場するずっと前、1970年代からすでにあったものだったりします。LOCは、もともと「万能な物差し」ではなかったわけです。それでも、大まかな目安としては長らく使われ続けてきました。
そこにAIが出てきた
ここからが本題です。
Claude CodeやCursorのようなAIコーディングツールを使うと、こんなことが起きます。
- AIが一度にファイル全体を書き直す（人間みたいに1行ずつ追記するのではなく、ファイルをまるごと再生成することがある）
- うまくいかなかったら、また書き直す
- それを何度も繰り返しながら、少しずつ完成に近づけていく
つまり、最終的にできあがったコードと、その過程でAIが実際に生成した行の総量は、全然違う数字になります。
LOCだけ見ても分からない理由
冒頭の「10万行」に戻ります。もしこれが「AIが対話の中で生成した行数の累積」だとしたら、それは「完成したアプリの規模」とイコールではないかもしれません。
調べていくと、「LOC」と一口に言っても、実はいくつか種類があることが分かってきました（※以下の呼び方は業界で完全に標準化された用語ではなく、この記事では便宜上こう呼んでいます）。
| 呼び方 | 何を数えているか |
|---|---|
| Final LOC（最終行数） | 今、実際にリポジトリにあるファイルの行数。いわゆる「完成品の大きさ」 |
| Generated LOC（AI生成累積行数） | AIが対話の中で生成した行の合計。書き直した分・消した分も含まれる可能性がある |
| Diff LOC（差分行数） | Gitの履歴に残る「追加した行・消した行」の積み重ね |
| Token（トークン量） | AIとのやり取りで消費した量。課金額に直結する |
Final LOCが10万行なら、比較的大規模な成果物と言えることが多いでしょう。でもGenerated LOCが10万行だったら、それは「AIとの試行錯誤がそれだけ多かった」というだけで、完成品の大きさとは別の話になります。
これ、言われてみれば当たり前なんですが、ニュースやSNSで「◯万行書いた」という数字を見たとき、自分はこれまで無意識に前者だと思い込んで受け取っていた気がします。
自分でも数えてみた
言葉で説明されてもピンと来ないと思うので、自分が開発している獣医療用の薬用量計算ツール（VetCalc PRO）で、実際に測ってみました。
まず、今実際に使っているファイルの行数（Final LOCにあたるもの）。
find . -name "*.html" -o -name "*.py" -o -name "*.json" | xargs wc -l
結果：3,611行
次に、これまで保存してきた開発中のバージョンファイル（プロトタイプ、ボツ案、バックアップ諸々）を全部集計してみました。
find . -type f \( -name "*.html" -o -name "*.json" \) -print0 | xargs -0 wc -l
結果：約266万行（重複ファイルを含む）
さらに、中身が完全に同じファイルを重複排除してみると：
190万行になっちゃった（笑）
- 最終的に今使っているコード（Final LOC）：3,611行
- これまでの試行錯誤の総量（Generated LOCに近いもの）：約190万行
同じプロジェクトを指しているのに、切り取り方によって「3,611」にも「190万」にもなる。最初にこの数字を見たとき、「いやいや、190万行って何だよ」と一人でツッコミました。wc -lが壊れてるんじゃないかと本気で疑ったくらいです。
で、なんで？
理由は単純で、FinalとGeneratedは、そもそも別のものを数えているからです。
AIとの対話は、だいたいこんな感じで進みます。
生成 → 修正 → 生成 → 削除 → 生成 → 修正 → …（何十回、何百回と反復）
↓
最終的に残ったものだけが
Final LOC
試行錯誤の過程で生まれては消えていった分もぜんぶ「生成された行」としてカウントすれば、そりゃ最終成果物より圧倒的に大きな数字になります。477個のバージョンファイルを見返してみると、注射薬計算アプリだけでもv0からv51まで、CRI計算機もv0.1からv0.7まで、地道に積み重ねてきた記録が残っていました。全部足したら190万行だった、というだけの話です。
自分の数字だから信頼できて、他人の数字だから疑わしい、というわけではありません。「何をどう測ったか」を確認しない限り、どんな数字も鵜呑みにはできない。それが今回一番実感したポイントでした。
- 1文字だけ違う保存バージョン（
v20_1、v20_2…のような連番ファイル）は、それぞれ別ファイルとしてカウントされてしまっている - 開発とは直接関係ないファイルも一部紛れ込んでいた
自分が出した190万行という数字も、実は完璧な指標ではないんです。
結局、自分の結論はこれです
「◯万行」という数字だけでは、何も分からない。
まず、何を数えた数字なのか。そこを見ないと、比較のしようがない。
今回一番勉強になったのは、そこでした。
この記事を書いて思ったこと
AIコーディングでは、コードを書く速度は確かに大きく変わった。でも今回調べてみて感じたのは、「LOC」という言葉そのものも、以前とは少し意味が変わり始めているのではないか、ということだった。
「◯万行」と聞いたら、その前に一つだけ確認したい。その数字は、何を数えたLOCですか？
これからは、自分も「◯万行」という数字だけでは判断しないようにしようと思います。
※この記事では、公開情報と自分の検証結果をもとに、LOCという指標の解釈について整理しています。Claude Codeなど各ツールの「累積行数」の内部実装や算出方法については公開されていない部分もあり、一部は推測を含みます。誤りやより正確な情報があれば、ぜひコメントで教えてください。