ある個人開発のリポジトリで、GitHubのIssue／Pull Requestの通し番号が1000目前まで進んだ。
第一声はだいたいこうなる。
「もう1000回も開発したの？」
惜しい。だが、その数字をそのまま工数へ変換すると、GitHubに怒られる前に電卓が泣く。
GitHubではPull RequestはIssueの一種として扱われ、同じリポジトリ内でIssue番号とPull Request番号は重複しない。つまり「#1000目前」は、IssueとPull Requestを合わせた通し番号がそこまで進んだという意味であり、「1000本のPRを完遂した」という意味ではない。
それでも面白い問いは残る。
もし、この規模の変更・確認・修正・公開運用を、人間がAIなしで手作業中心に回したら、いくらかかるのか。そもそも採算は合うのか。
この問いは、AI時代の個人開発を考えるうえでかなり本質的だ。
1. まず、GitHubの番号は筋トレのレップ数ではない
GitHubの通し番号は「作業量メーター」ではない。
1件のPull Requestに2000行の変更を詰める人もいれば、CSSを1行直すだけで1件切る人もいる。Issueも混ざる。バグ報告、設計メモ、機能要望、検証タスクまで全部同じ番号空間へ入る。
したがって、
番号が1000近い → 人間1000人分
でもなければ、
番号が1000近い → 1000個の完成機能
でもない。
GitHubの番号は、体重計というより改札の通過番号に近い。
ただし、短期間に大量の小さな変更を積み上げているなら、それは別のことを示す。
設計、実装、検証、修正というループを何度も回した履歴がある。
人間の採算を考えるなら、見るべきなのは番号そのものではなく、各ループに何分かかったかである。
2. 人力コストは「1件が軽い」ほど見誤りやすい
2026年8月、フリーランス案件検索サービスの集計では、掲載されたフリーランスエンジニア案件の月額平均単価は78.9万円だった。
これは全開発者の給料ではないし、特定の人の時給でもない。案件市場に掲載された仕事の平均値である。
それでも、「同じ仕事を外へ頼んだらいくらになるか」を考える代替コストの物差しには使える。
月160時間で単純に割ると、約4930円／時になる。
ここで仮に、1000個の実質的な変更単位があったとする。これはGitHubの#1000とは別の仮想例だ。
| 1変更あたりの平均時間 | 合計時間 | 160時間/月換算 | 78.9万円/月での試算 |
|---|---|---|---|
| 15分 | 250時間 | 1.56人月 | 約123万円 |
| 30分 | 500時間 | 3.13人月 | 約247万円 |
| 45分 | 750時間 | 4.69人月 | 約370万円 |
| 1時間 | 1000時間 | 6.25人月 | 約493万円 |
| 2時間 | 2000時間 | 12.5人月 | 約986万円 |
| 3時間 | 3000時間 | 18.75人月 | 約1479万円 |
| 4時間 | 4000時間 | 25人月 | 約1973万円 |
15分で終わる細かい変更ばかりでも、1000回積めば250時間である。
「1個ずつは軽い」は、総額が軽いことを保証しない。
むしろ小さい仕事ほど、調査、ブランチ作成、レビュー、テスト、マージ、デプロイ確認といった固定の段取りが効いてくる。
人力で全部やると、名刺が「ライター／翻訳者／フロントエンド／バックエンド／QA／インフラ／編集長」で折り畳み式になり始める。
3. 「自分でやったから人件費0円」は、会計上はあり、経済上は別
個人サイトではよくある。
サーバー代は月1000円。 広告収入は月5000円。 だから月4000円の黒字。
現金だけを見ればその通りである。
しかし月に50時間使っているなら、別の見方も必要だ。
事業として比較したいなら、少なくとも次の二つを分ける。
現金利益 = 売上 − 実際に払った費用
労働込み利益 = 売上 − 実際に払った費用 − 自分の作業時間 × 代替時給
趣味なら、自分の時間を0円と置いても何も悪くない。ゲームを50時間やって「人件費で赤字」とは普通言わない。
問題は、その趣味収支をそのまま「事業として儲かっている」と呼ぶときだ。
楽しさ、学習、作品づくりには金額以外のリターンがある。
一方、商売として比較するなら、時間を消したふりはできない。
4. 広告モデルは、思った以上に「分母」が必要になる
広告サイトのざっくりした収益式は単純だ。
広告収益 = ページビュー ÷ 1000 × 実効RPM
RPMは1000ページビューあたりの実効収益で、媒体、国、端末、広告形式、季節、読者属性によって大きく変わる。
ここでは市場相場を断定せず、計算の形を見るためだけに仮のRPMを置く。
もし月78.9万円を広告だけで回収したいなら、
| 仮の実効RPM | 月78.9万円に必要なPV |
|---|---|
| 100円 | 約789万PV |
| 300円 | 約263万PV |
| 500円 | 約158万PV |
| 800円 | 約99万PV |
もちろん、実際の個人サイトが毎月78.9万円分の労働を投入するとは限らない。
この表が示すのは別のことだ。
人力を市場価格で評価すると、広告だけで回収するには相当な閲覧量が必要になる場合がある。
だから人力サイトは、広告だけでなく、アフィリエイト、商品販売、案件獲得、会員、寄付、ブランド価値、趣味価値などを合わせて成立していることも多い。
5. AIで変わるのは「記事を書く速度」だけではない
AIの価値を「文章を30秒で書ける」に限定すると、本質を外す。
個人でWebメディアを運営する場合、本当に重いのは周辺工程である。
- ネタを拾う
- 調べる
- 原稿を書く
- 事実確認する
- コードを直す
- テストする
- 多言語化する
- 公開する
- 本番を確認する
- 不具合を直す
- SNSやメルマガへ配る
- 数字を見て改善する
人力では、工程を増やすほど変動費が増える。
AIと自動化を組み合わせると、最初に仕組みを作るコストは上がる代わりに、2本目、10本目、100本目の追加コストを下げられる可能性がある。
これは「ライターが速くなった」というより、
個人が小さな編集部と開発チームの工程を、システムとして持てるようになる
という変化に近い。
作業者が消えるのではない。
人間の役割が、入力、判断、仕様、品質基準、例外処理へ寄っていく。
つまり、キーボードを叩く人から、工場の設計者兼編集長へ職種転換する。
6. ただし、AIは入れれば速くなる魔法のニトロではない
ここは面白いところで、研究結果は一直線ではない。
2023年に公開されたGitHub Copilotの統制実験では、指定されたJavaScriptのHTTPサーバー課題で、AIを使える群は対照群より55.8%速く完了した。
一方、2025年のMETRの無作為化比較試験では、自分が長年触ってきた成熟したOSSリポジトリで課題を解く熟練開発者16人が、当時のAIツールを使える条件で平均19%遅くなった。
さらにMETRは2026年2月、後続実験ではAIを使わない条件への参加を嫌う開発者が増え、並列エージェント利用者の作業時間測定も難しくなったため、現在のAI効果をきれいに推定できなくなったと説明している。遅かった2025年初頭より今は速くなっている可能性はあるが、数字を強く断定できるデータではない、という整理だ。
つまり結論は、
AIは常に55%速い でも、 AIは19%遅い でもない。
課題の種類、既存コードへの習熟、エージェントの使い方、レビュー負荷、並列化、テスト環境で大きく変わる。
AIは光速で正解も作るが、設計が悪ければ光速でバグも増やせる。
だから自分の運用では、自分の工程を測るしかない。
7. 手動サイトが負けるとは限らない
AIで大規模自動化したサイトが、必ず手動サイトより儲かるわけではない。
手動のほうが合理的なケースもある。
- 月に数本しか作らない
- 専門家本人の文章そのものが商品
- 1記事から高単価の商品や案件が売れる
- 翻訳や大量配信が不要
- 更新頻度が低い
- 本人が制作を趣味として楽しんでいる
- システムを作る初期費用のほうが高い
逆に自動化が効きやすいのは、
- 同じ工程を何度も繰り返す
- 多言語展開する
- 記事数が増える
- QA、公開、本番確認を毎回行う
- 配信先が増える
- 人間が毎回同じ確認をしている
ような運用だ。
要するに、固定費と変動費の勝負である。
AI工場は最初が高い。 人力工房は1個ずつ高い。
そして忘れてはいけない。
高性能な無人工場を完成させても、客が一人も来なければ、それは未来のメディアではなく最新鋭の巨大倉庫である。
8. 知り合いの「AIなし手動サイト」の採算を見るなら、聞く数字はこれ
相手を値踏みする必要はない。
仕組みを比較したいだけなら、次の数字があればかなり見える。
- 月の作業時間
- 月間PVまたはUU
- 月の売上と現金費用
- 記事数と月の新規公開本数
- 何言語で運営しているか
- 何年運営しているか、初期構築に何時間かかったか
そこから最低限、次を計算できる。
現金利益 = 売上 − 現金費用
オーナー実質時給 = 現金利益 ÷ オーナー作業時間
労働調整後利益 = 現金利益 − オーナー作業時間 × 比較したい時給
1記事あたり追加コスト = 追加の記事制作・翻訳・QA・公開・配信に必要な時間と費用
特に重要なのは最後である。
既に1000時間かけたことより、次の1本を出すのに何時間かかるかのほうが、今後の採算を決める。
9. AI個人開発で本当に強いのは「大量に作ったこと」ではなく、再現できること
AIを使って一晩で大量のファイルを作るだけなら、そこまで難しくない。
難しいのは、
- 同じ品質基準を次回も使える
- 失敗した場所だけやり直せる
- 二重投稿しない
- 現在の版を識別できる
- 公開後の実物を確認できる
- 途中で一部が止まっても他が進む
- 人間しか解決できない認証だけ人間へ返せる
- 何が起きたか後から追える
という状態を作ることだ。
この部分は、単なる生成量ではない。
運用資産である。
手動サイトでも、手順書、テンプレート、CMS、自動バックアップ、チェックリストが積み上がれば同じ方向へ進む。
AI時代の差は、その仕組みを一人でもかなり深く作り込めるようになった点にある。
10. 結論：1000という数字より、「次の1個はいくらか」が面白い
Issue／Pull Requestの通し番号が1000へ近づくのは、見た目としては派手である。
しかし、それ自体を生産性の点数にしてはいけない。
本当に見たい数字は、
人間の作業時間 1回の変更コスト 1記事の追加コスト 公開までの手戻り率 オーナー1時間あたりの出力 売上に対する労働込み利益
である。
人力で採算が合っているサイトは普通にあり得る。
AIを使っているのに採算が合わないサイトも普通にあり得る。
ただし、記事、翻訳、コード、QA、公開、監視、配信を全部人間が毎回手で回すモデルと、最初に仕組みを作って限界費用を落としていくモデルでは、記事数が増えたときの費用曲線がまるで違う。
「1000まで来た」が面白いのは、勲章だからではない。
その1000回近い試行錯誤のうち、どれだけが次回から人間の手を離れる仕組みに変わったか。
そこが、AI個人開発のいちばん経済的に面白い部分である。
