1. サイトの作者を検索したら、架空のちいかわキャラが爆誕した
ある小さなサイトが、AIを使って記事をどんどん増やしていた。漫画のキャラクターを性格でたとえたり、『ちいかわ』のハチワレについて考えたりする記事もあった。
そんなサイトの名前を別のAIに尋ねると、「『ちいかわ』に登場する『めんどうくさいハチワレ』のことですか？」という返答が出た。
誰だよそいつ。
サイトの運営キャラクターが、いつの間にか別作品の登場人物に転職させられている。履歴書も面接もなし。しかも採用したのはAIだ。
ここで確認できるのは、AIがその返答をしたという出来事だけ。実際にサイトの記事を読んで誤解したのか、名前から連想したのかは分からない。「めんどうくさいハチワレ」が公式に存在するという証拠もない。AIの自信満々な答えと、事実は別物である。
2. 裏では記事工場がコツコツ動いている
記事を作る。読みやすく直す。12言語へ展開する。検査する。公開する。検索や交流サイトへ届ける。止まったら原因を調べ、修正案を出して、もう一度確かめる。
作業報告は次第に長くなる。
AI担当A「公開処理を直しました」
AI担当B「検査を通しました」
AI担当C「別の停止原因を発見しました」
監督役「では修理担当を追加します」
読者「記事を読む前に進捗報告だけで一冊できそう」
笑えるが、重要なのは**「修正案を保存した」ことと「公開ページで正常に動いた」ことは違う**という点。記事工場は、量産機械であると同時に修理工場にもなる。
3. 「記事が1,900本？」まず数え方を分けよう
記事数には少なくとも五つの顔がある。
- 元記事：日本語などで独立して書かれた内容。
- 言語別ページ：同じ元記事を英語、韓国語、繁体字などで読めるようにしたもの。
- 作成済み・未公開：書き終えたが、検査や公開を待っているもの。
- 公開済み：実際に読者が開けるもの。
- サイト内の経路：記事以外の案内ページ、機能ページなども含む場合がある。
たとえば元記事1,000本を12言語でそれぞれ公開すれば、言語別ページは最大12,000件。「記事が1,900本らしい」という数字と、サイト全体のページ数は一致しない。
ある運営例では、GitHubに記録された経路の数が15,862件だった。しかしそれは「日本語記事15,862本」という意味ではない。どの数値も、日付・数える単位・公開状態を付けて初めて比較できる。数だけ足して「大勝利！」は、だいたい集計担当が泣く。
4. そしてGitHubが約2.46GBに育っていた
匿名化した事例のGitHub記録では、リポジトリの報告サイズが2,400,972KiB。換算すると約2.29GiB、十進表記で約2.46GBだった（2026年10月8日時点の記録）。
「記事って文字だけじゃないの？ なぜ？」と思うだろう。
GitHubには記事本文だけでなく、プログラム、翻訳データ、公開のための一覧、検査結果、画像や音声などの素材、過去の変更履歴も入り得る。ただし、この数字だけで何が何GBを占めたかは断定できない。原因別の内訳には別の調査が必要だ。また、GitHubが表示する報告サイズと手元のフォルダ容量は同じ測り方ではない。
記事「わたし、数KBです」
履歴「前のわたしも保存しておいたぞ」
翻訳「12人で来ました」
倉庫「聞いてない」
5. 結論：GitHub Freeは「リポジトリ全部で無料5GBまで」ではない
GitHubは通常のGitリポジトリについて、無料プラン共通の「合計○GBを超えたら即課金」という単純な枠を示していない。5GBは課金開始ラインではなく、強く推奨されるサイズの目安だ。
公式の説明は、1GB未満が理想、5GB未満を強く推奨。さらに別の公式資料では、Gitの履歴を圧縮して保存する部分のディスク上のサイズは10GBが推奨上限とされる。10GBも「無料で保存できる確約容量」ではない。
大きすぎたり更新が激しすぎたりして運営に負担をかける場合、GitHubから改善を求められることもある。つまり「無料で上限なし！無限倉庫だ！」は言いすぎである。無料の一律課金境界がないことと、無制限に快適に使えることは違う。
6. 本当の制限は、別々の引き出しに入っている
| 何を数える？ | GitHub Freeなどでの目安・制限 |
|---|---|
| 通常のリポジトリ全体 | 一律の無料合計GB枠はない。理想1GB未満、5GB未満を強く推奨 |
| Gitの保存履歴のディスク上のサイズ | 推奨上限10GB。自動課金ラインではない |
| 通常のファイル1個 | 50MiB超で警告、100MiB超は通常のGitでは拒否。ブラウザからの追加は25MiBまで |
| 1回の送信 | 2GiB相当の制限 |
| 大きなファイル専用のGit LFS | GitHub Freeは保存10GiBと転送10GiBの無料枠。通常のGitとは別勘定 |
| GitHub Actionsの実行成果物 | GitHub Freeに500MBの無料保存枠。実行時間は月2,000分が基本の無料枠 |
これらは同じ財布ではない。特にGit LFS、Actions、Packagesなどの超過時は、課金設定や予算によって停止・請求の挙動が異なる。「2.46GBだからActionsの500MBを超えて請求される」という計算は間違い。逆に、Git本体が5GB未満でも、別枠の使用量が上限へ達することはある。
7. なぜ記事工場は、記事数以上の速さで太るのか
Gitは「今あるファイル」だけでなく、「どう変わってきたか」も記録する。
1つの大きな一覧ファイルを毎時間書き換えれば、見た目は1ファイルのままでも、過去の版が履歴に積み上がる。記事を修正し、翻訳を再生成し、検査の記録を追加し、同じ成果物をまた保存する。これが続けば、容量の増え方は記事本数と比例しない。
ただしGitは内容を圧縮し、似た履歴を効率よく保管する仕組みも持つ。「1回書き換えたら必ず全容量が二倍になる」わけではない。何が本当に太らせているのかは、調べないと分からない。
公開用の生成データや大きな素材は、必要に応じてGitの外の保存場所へ。逆に、記事の元原稿やプログラムなど、変更の追跡に価値があるものはGitに残す。役割を分けるのが基本だ。
8. 先に壊れるのは「容量」より「作業の混雑」かもしれない
人数ならぬAIの作業が増えると、同じファイルへほぼ同時に書き込もうとして衝突する。修理が成功しても、別の修理が古い一覧を参照して止まる。記事は完成しているのに公開一覧が更新されず、公開が進まないこともある。
そのとき、原因をすべて「GitHubが満杯だから」と決めつけるのは早い。ファイル容量・更新頻度・同時書き込み・公開処理の不整合は別の問題だからだ。
確認する順番は、（1）最新の原稿があるか、（2）検査は通ったか、（3）公開先へ届いたか、（4）実際のページが新しい本文を表示したか。「修理しました！」という報告書に拍手するのは4番を見てからでいい。
9. 無料運用を長持ちさせる四つの手入れ
第一に、サイズと中身を測る。 GitHubの報告サイズだけで犯人を決めず、履歴や大きいファイルを確認する。公式が紹介する git-sizer も調査の補助になる。
第二に、毎回変わる巨大な記録を見直す。 大量の生成一覧、使い捨ての実行記録、公開済みの画像や音声を、すべてGitに重ねて置く必要があるか分ける。
第三に、同じ場所への更新を減らす。 無関係な変更で全データを作り直さず、衝突したら現在の内容を読み直す。処理が走ったことではなく、結果が届いたことを測る。
第四に、履歴をむやみに消さない。 普通にファイルを削除しても過去の履歴に残ることがある。履歴の書き換えは共同作業や参照先を壊し得るため、別の場所への保存と影響確認をしてから慎重に行う。
10. 記事数が増えるほど「誰が読んで何が残るか」が大事になる
元記事が何千本、翻訳ページが何万件あっても、それだけで読者が増えるとは限らない。検索結果で見つかるか、内容が正しいか、言語ごとに自然か、同じ話を薄く繰り返していないか。大事なのはここだ。
Googleの公式案内も、読者の役に立つ独自の内容を重視し、順位操作のために価値の乏しいページを大量に作ることを問題視している。AIで作ったから即アウトではなく、読者への価値がない量産が問題なのである。
では、ちいかわのハチワレになぞらえた記事を書いたサイトの運営キャラクターを、別のAIが「めんどうくさいハチワレ」と呼んだ事件は？
それは検索AIの推測を、公式設定だと信じてはいけない実例だ。同時に、読む人にとってはかなり面白い「AIが作者を二次創作した」話でもある。
記事工場「毎日、記事を増やします」
GitHub「履歴も増えます」
検査係「間違いを直します」
検索AI「新キャラも増やします」
全員「そこは増やすな。」
結論：GitHubの5GBは無料枠の壁ではない。けれど容量、公開、品質、AIの思い込みには、それぞれ別の点検が要る。記事工場の真の実績は、保存した件数ではなく、正しく読者に届いた記事で測ろう。
