GitHubの集計で、最も使用される言語がPython・JavaScriptを抜いてTypeScriptになった（2025年8月時点、前年比66%増）。新規開発者の80%は登録から1週間以内にGitHub Copilotを使う。発注側にとっては「これから頼む開発にはAI生成コードが混ざる」という前提の話であり、納期短縮ではなく検収工数の設計が論点になる。
誰が、何を、いつ測ったのか
GitHubの公式ブログが、AIの普及によって開発者の言語選択とツール選択がどう変わったかを、同社の年次集計 Octoverse 2025 のデータをもとに整理した（出典：The GitHub Blog（GitHub）／著者 Andrea Griffiths（@AndreaGriffiths11）、2026年2月19日公開。数値の出所は Octoverse 2025。、2026-02-19、https://github.blog/ai-and-ml/generative-ai/how-ai-is-reshaping-developer-choice-and-octoverse-data-proves-it/）。
先に利害関係を明示する。この記事は GitHub 社自身による発表であり、同社は当該製品（GitHub Copilot）の提供者である。「新規開発者の80%が初週にCopilotを使う」も「AI支援で処理量が20〜30%増える」も、製品を売っている当事者が自社プラットフォームのデータを自社の判断で集計・公表したものだ。第三者の検証は経ていない。数字の方向性そのものを疑う必要はないが、どの数字を強調し、どの数字を出さないかの選択には提供者側の視点が入る、という前提で読む必要がある。
もう一点、時点のずれがある。記事の公開は2026年2月19日だが、数値の観測時点は Octoverse 2025（2025年8月時点）である。約半年のタイムラグがあり、「今この瞬間の状況」ではない。
数字ごとに母数が違う（ここを取り違えると引用事故になる）
この記事で最も注意が要るのは、提示された数字の母数がそれぞれ異なる点である。同じ記事の中に「GitHub全体」「AI生成プロジェクト内」「新規開発者」「公開リポジトリのみ」が混在している。まとめて「AIで開発が変わった」と読むと、事実と違う引用になる。
| 数字 | 内容 | 母数・対象 | 時期・条件 |
|---|---|---|---|
| 1位 | 最も使用される言語がTypeScriptに（Python・JavaScriptを抜く） | GitHub上の公開活動全体 | 2025年8月時点／Octoverse 2025 |
| 66%増 | TypeScriptの利用の伸び | GitHub上の公開活動全体 | 前年比（year-over-year）／Octoverse 2025 |
| 24%増 | JavaScriptの利用の伸び | GitHub上の公開活動全体 | 前年比（year-over-year）／Octoverse 2025 |
| 206%増 | シェルスクリプトの利用の伸び | AI生成プロジェクト内に限定 | Octoverse 2025 |
| 110万超 | LLM SDK（本文表記は「LLM SDKs」）を使用しているリポジトリ数 | 公開リポジトリのみ（非公開は不算入） | 2021年から2025年にかけての増加として提示された累積カウント |
| 80% | 最初の1週間でGitHub Copilotを使う割合 | GitHubの新規開発者（既存・全開発者ではない） | 登録後1週間以内 |
| 20〜30%増 | AI支援開発によるスループット（処理量）の増加 | 記載なし | n数・調査期間・測定方法・対象の記載なし。本文は「しばしば（often）」とのみ表現 |
表を作ってみると、単独で扱いにくい数字がはっきりする。
- 「シェルスクリプト206%増」は、GitHub全体でシェルスクリプトが3倍になったという意味ではない。母数はAI生成プロジェクトの内部に限定されている。AIに作らせたプロジェクトほど自動化スクリプトが同梱されやすい、という範囲の話だ。
- 「110万超のリポジトリ」は公開リポジトリのみの数である。企業の非公開開発は一件も含まれない。日本の中小企業が発注する業務システムはほぼ非公開なので、この数字は業務システム開発の実態を代表しない。
- 「80%が初週にCopilot」の分母は「GitHubの新規開発者」だ。既存開発者を含む全体の普及率ではない。新規登録者は学習目的・学生・AI経由で開発に入った層が相対的に多いと考えるのが自然で、既存の業務開発者に同じ比率を当てるのは分母の取り違えになる。
- 「スループット20〜30%増」に至っては、n数も調査期間も測定方法も比較条件も書かれていない。本文自身が「often」という言葉で幅を持たせている。検証可能な形で提示されていない以上、社内稟議の根拠数値としては使えない。
つまり、この記事の中で条件が明示され、そのまま引用に耐えるのは、実質的に言語シェアの3つ（TypeScript 1位・66%増、JavaScript 24%増）である。
なぜTypeScriptなのか——「AIが書きやすい」が選択理由になった
言語シェアの変動そのものは毎年起きる。今回それが読者にとって意味を持つのは、伸びた理由がAIと結びついているからだ。TypeScriptはJavaScriptに静的な型を足した言語である。型があるということは、コードの各所で「ここには何が入るか」が機械可読な形で宣言されているということだ。
これはAIにとって二重に効く。生成時には型が制約として働き、出鱈目な組み合わせを書きにくくなる。生成後には、型検査がAI出力の誤りを人間のレビュー前に機械的に弾ける。JavaScript（24%増）も伸びてはいるが、TypeScript（66%増）の伸びはその倍以上だ。同じエコシステムの中で、型のある側に選択が偏ったことになる。
ここで押さえておきたいのは、これが「AIが便利だから流行った」ではなく「AIに検査可能性を要求された結果、言語の選択が動いた」という順序だという点である。人間だけで書いていた頃は型注釈は書き手のコストだった。AIが大量に書くようになると、型は検査の資産になる。コストと資産の勘定が逆転した。
中小企業にとっての意味：これは調達基準の話である
自社サイトや業務ツールを外注・内製するとき、この記事は技術トレンドの読み物ではなく、調達基準の話として読める。論点は3つある。
1. 言語選択は保守コストと外注先の調達しやすさに直結する。 AIが書きやすい言語（型のあるTypeScript等）を選ぶかどうかは、その後何年もの保守で効いてくる。型検査が通らないコードが機械的に弾かれる体制なら、引き継いだ次のベンダーもAIを使って安全に触れる。逆に、型のない古い構成のまま積み上がったコードは、AIに読ませても直させても検証手段が乏しく、人手のレビューに全部戻ってくる。「この案件、どの言語で書きますか」は今や見積の一行ではなく、5年分の保守費の分岐点である。
2. これから発注する案件の大半にはAI生成コードが混ざる前提で見積・検収を組む。 新規開発者の80%が初週にCopilotを使うという数字は、分母の限定があるとはいえ、開発の入口が既にAI前提になっていることを示す。「御社はAIを使っていますか」と聞く段階ではない。聞くべきは「AI生成部分をどう検証していますか」「テストはどこまで書きますか」「レビュー体制はどうなっていますか」である。
3. 速く上がってくる分を、納期短縮ではなく検収工数に振り分ける。 ここが最も実務的な判断になる。GitHubの本文自身が、スループットが上がるほど設計のズレ（architectural drift）が速く溜まると書き、見た目が正しいAI出力を信用したくなるがテストを省くなと釘を刺している。製品提供者が自ら注意喚起している以上、これは無視できない。速度が上がったからといって納期をそのまま縮めると、溜まったズレの精算は運用開始後に来る。
- 見積依頼時：AI利用の有無ではなく、AI出力の検証方法を書かせる
- 契約時：テストコードの範囲と、それを納品物に含めるかを明記する
- 検収時：動作確認だけで通さず、テストが通ることと、テストが何を検査しているかを確認する
- 保守見積：初年度ではなく3年目・5年目の保守前提で言語・構成を評価する
この記事が答えていないこと
限界も書いておく。GitHubの本文は、AI生成コードのセキュリティリスク・技術的負債・保守負担についてほとんど論じていない。言及は「テストを省くな」「スループットが上がるほど設計のズレが速く溜まる」という定性的な注意にとどまり、実際にどれだけ脆弱性が増えたか、保守工数がどう変わったかのデータは提示されていない。生産性の側は数字で語り、コストの側は言葉で済ませている——製品提供者の発表として、この非対称は自然でもあり、読者が補って読むべき箇所でもある。
対象範囲の限界も繰り返しておく。すべてGitHubプラットフォーム上の公開活動の集計であり、企業規模・国・業種の区分がない。日本の中小企業がどんな言語で、どこまでAIを使って内製・外注しているかを示すデータではない。この記事から読み取れるのは世界の公開開発の潮流であって、自社の現状ではない。
TOEの読み筋
先に断っておくと、TOEではこの記事に基づく検証や移行は未実施である。Octoverse 2025 の数値をTOEの案件で再現したわけでも、TypeScript移行の効果を自社で測定したわけでもない。以下は数字から立てた仮説であり、実測の裏付けはない。
そのうえで、TOEはこの記事を「言語トレンドの報告」ではなく「発注仕様書の書き換え要求」として読んでいる。中小企業のWeb制作・AI開発案件で、これまで見積書に書かれてこなかった項目が2つある。ひとつはAI生成部分の検証方法、もうひとつはテストコードの納品可否である。どちらもAIが介在しない時代には、ベンダーの内部品質管理として任せておけた。AIが書く量が増えると、これは発注側が指定すべき仕様に格上げされる。
もうひとつの読み筋は、型のある構成を選ぶことが「将来AIに触らせやすくする」という投資だという点だ。今すぐAIに保守させる予定がなくても、3年後にそうする可能性が高いなら、検査可能な形で作っておく価値がある。逆に言えば、目先の開発費が安いという理由だけで検査手段の乏しい構成を選ぶと、AI時代の保守で不利を背負う。ここは実測がないので断定はしないが、少なくとも見積比較の際に「安い方の構成が何を検査できないか」を確認する価値はある。
そして最後に、この記事の数字をそのまま社内資料に貼らないことを勧める。母数が数字ごとに違い、「80%」も「206%」も条件を落とすと誤った印象を作る。使うなら、この記事の表と同じ形で条件を添えて出すべきだ。
まとめ
- GitHubの集計で、最も使用される言語がPython・JavaScriptを抜いてTypeScriptになった（2025年8月時点、GitHub上の公開活動全体、前年比66%増）。JavaScriptは同24%増で、型のある側に選択が偏った。
- この記事は GitHub 社自身による発表であり、同社は当該製品（GitHub Copilot）の提供者である。Copilot利用率や生産性向上を報じる立場に利害があり、第三者検証は経ていない。
- 数字ごとに母数が違う。「シェルスクリプト206%増」はAI生成プロジェクト内限定、「110万超のリポジトリ」は公開リポジトリのみ、「80%がCopilot利用」の分母はGitHubの新規開発者である。全体の普及率として引用すると分母の取り違えになる。
- 「スループット20〜30%増」はn数・調査期間・測定方法・比較条件の記載がなく、本文も「しばしば」とのみ表現している。稟議の根拠数値としては使えない。
- 中小企業にとっては調達基準の話として読める。AIが介在する前提で見積・検収を組み、速く上がってくる分をレビューとテストの工数に振り分ける判断が要る。TOEではこの記事に基づく検証・移行は未実施であり、上記は仮説である。
関連記事として、生産性向上の数字がどこまで検証に耐えるかを扱ったAI支援でベテラン開発者はむしろ遅くなった——RCTの結果を読む、および自社の判断基準を先に決める考え方をまとめたAIツールは何を基準に選ぶのかも参照してほしい。ベンダー依存の落とし穴についてはベンダーロックインで動けなくなった話にまとめている。