日本語版が2年以内に作られたのは28.8%：Wikipediaのソフトウェア176件をPythonで追跡

#「日本語版がある項目だけ」を比べてはいけない

英語版Wikipediaにソフトウェアの記事ができてから、日本語版の記事ができるまで何日かかるのか。両方の記事が存在する項目を集め、作成日の差を取れば答えられそうに見える。

しかし、その方法では日本語版がまだない項目がすべて分析から消える。待ち時間が最も長い可能性のある項目を除いたうえで「平均は何か月」と計算することになる。

そこで、Wikidataで機械的に固定したソフトウェア関連 176件を対象にした。 英語版・日本語版Wikipediaの最古版を公式APIから取得し、日本語版を確認できなかった107件も右打ち切りとして残した。

#何を数えたか

調査対象を結果を見る前に次の条件で固定した。

1. Wikidataの instance of (P31) が、software、programming language、software library、software framework、operating systemのいずれかに直接一致する
2. inception (P571) または publication date (P577) に、2016年1月1日から2023年12月31日までの日付が少なくとも1つある
3. 英語版Wikipediaへのサイトリンクがある
4. 個別の技術名を手で選ばない

Wikidata Query Serviceの件数クエリと詳細クエリを別々に実行し、双方が176件で一致しなければ取得を失敗させる。各項目はタイトル文字列ではなくWikidata IDで英語版と日本語版を対応づけた。

次にMediaWiki Action APIへ rvdir=newer&rvlimit=1 を指定し、各ページの最古版を1タイトルずつ取得した。最初は複数タイトルをまとめて送ったが、APIがパラメータの組み合わせを拒否した。まだ版データを見ていない段階で、1タイトル1リクエストへ変更したこともプロトコルへ残している。

最終的な取得は247リクエスト。英語版の最古版が欠けた項目は0件、日本語版の最古版を確認できた項目は 69件だった。 残り107件を「失敗」やゼロ日ではなく、2026年7月15日の観測終了時点まで日本語版イベントを確認できなかった右打ち切りとして扱った。

#sitelinkなし107項目に、英語版359.6万pageview

「日本語版がない」を数えるだけでは、何から確かめるべきか分からない。そこで主解析を変えずに、各英語ページの2025年7月から2026年6月までのpageviewをWikimedia Analytics APIから追加取得した。これは公開後に加えた探索的な需要指標であり、事前に固定した仮説検定ではない。

日本語版へのsitelinkがない107項目の英語ページには、12か月で合計 3,596,182 pageviewがあった。 上位は次のとおりだった。

Unreal Engine 5はこの条件で 411,989 pageviewだった。 ただし、pageviewは all-agents のリクエスト数で、bot等を含み、日本語話者の需要を直接測っていない。また、sitelinkがないことは日本語情報が存在しないことと同義ではない。別名の記事や製品系列の記事へ内容が統合されている可能性もある。

ページ上部の探索表では、176項目をタイトル検索し、「sitelinkなし」「英語版の後に作成」「英語版以前から存在」で絞り込み、閲覧数または観測期間で並べ替えられる。欠落候補を長い一覧として置くのではなく、読者が関心と根拠を確認してから英語版、Wikidata、Wikipediaの翻訳機能へ進めるようにした。

#未作成を残すためのPython

各項目について、英語版の最古版を時刻ゼロとした。日本語版が後から作られていればその日数をイベント時刻とし、日本語版がなければ観測終了日までの日数を打ち切り時刻とする。

日本語版が英語版と同日または先に存在した12件は、負の日数を無理に平均せず「0日イベント」とした。主解析はKaplan–Meier推定量の 1 - S(t)、つまり時点 t までに日本語版記事が作られた推定割合である。

def km_curve(rows):
    times = sorted({row["durationDays"] for row in rows})
    survival = 1.0
    curve = []

    for time_days in times:
        at_risk = sum(r["durationDays"] >= time_days for r in rows)
        events = sum(r["event"] and r["durationDays"] == time_days for r in rows)
        censored = sum(not r["event"] and r["durationDays"] == time_days for r in rows)

        if events:
            survival *= 1 - events / at_risk
        curve.append({
            "timeDays": time_days,
            "atRisk": at_risk,
            "events": events,
            "censored": censored,
            "creationProbability": 1 - survival,
        })
    return curve

実際のコードではGreenwood分散とlog-log変換による95%信頼区間も計算する。外部パッケージには依存せず、Python 3.11以降の標準ライブラリだけで取得からSVG生成まで再実行できる。

#2年以内は28.8%

固定した5時点の推定値は次のとおりだった。

1年以内の推定割合は 23.1%だった。 30日時点ですでに13.1%ある一方、その後の増加は緩やかである。これは「2年を過ぎたら作られない」という意味ではない。2年より後のイベントもあり、観測終了時点でも追跡中の項目が残る。

Kaplan–Meier中央値は約4,134日で形式上は到達したが、その時点で追跡中なのは7件しかない。長い尾のわずかなイベントで大きく動くため、見出しには使わず、追跡人数が111件残る2年推定までを主要結果とした。

#OSとその他ソフトウェアで差が見えた

複数クラスを持つ項目は、プログラミング言語、フレームワーク、ライブラリ、OS、その他ソフトウェアの順で1カテゴリに割り当てた。

OS群は 56.8%、 その他ソフトウェア群は 16.3%だった。 ただし、これはOSだから日本語記事が早く作られるという因果効果ではない。OSにはバージョン別項目が多く、発売時の報道量、既存シリーズ、編集者層などが違う。フレームワーク、言語、ライブラリは標本が小さく、信頼区間も非常に広い。

この比較から言えるのは、全体値だけでは大きな構成差が隠れるということまでである。カテゴリ差の理由を検証するには、閲覧数、出典数、製品系列、記事作成者数などを事前に定義した別研究が必要になる。

#5つの反証でどこまで動いたか

WikidataとWikipediaの対応には、リダイレクト、複数クラス、同一ページへ解決される複数項目がある。そこで主解析と同じ2年推定を条件違いで再計算した。

同じ英語ページへ解決された重複3行を落としても 29.3%だった。 リダイレクト除外後も29.0%で、主結果の28.8%から大きくは動かない。

最も変化したのは、英語版と同日以前に日本語版が存在した12件を除いた場合の23.6%である。これは「英語版から日本語版へ」という時間順を厳密に見たい場合の保守的な値として併記すべきだろう。主解析で0日イベントを残したのは、結果を良く見せるためではなく、事前に固定したコホートから都合よく項目を落とさないためである。

#限界：この分析が示さないこと

この結果を「海外技術が日本へ届くのに2年以上かかる」と読むことはできない。

• 記事作成時差である: 技術の利用、認知、採用、翻訳、検索需要は測っていない
• 標本はWikidata依存: 直接P31と日付属性が整備された項目に限られ、欠損は無作為とは限らない
• 日付条件は広い: P571/P577を複数持つ項目は、期間内の値が1つあれば入る。最初の発売年だけを表さない
• 現在のサイトリンクから構築: 過去に削除・統合・改名された記事の履歴を完全には復元しない
• 最古版は内容品質を示さない: 一行のスタブと充実した技術解説を区別していない
• カテゴリは粗い: Wikidataの直接クラスを優先順位で一意化しており、製品系列や用途を調整していない
• 小標本がある: フレームワーク6件、ライブラリ5件などのカテゴリ値は探索的である
• 独立性は完全ではない: 同じシリーズや解決後ページを共有する項目がある。重複除外感度分析はしたが、製品系列クラスタまでは扱っていない
• pageviewは補助指標: all-agents のため自動アクセスを含み、日本語圏の検索需要、記事作成価値、翻訳の優先度を直接表さない
• sitelinkなしは情報なしではない: 日本語版では別名・上位概念・製品系列の記事に内容が含まれる場合がある。探索表は翻訳候補の確定リストではなく、確認を始める入口である

また、多言語Wikipediaの知識格差そのものは新しい研究テーマではない。記事推薦、言語間差、知識格差可視化には先行研究がある。本分析の差分は、EN/JAのソフトウェア関連コホートを固定し、未作成を右打ち切りとして残し、取得スナップショットと計算を丸ごと再現できるようにした点に限られる。「誰も調べていない」とは主張しない。

#再現方法

記事の数値はSHA-256で固定したデータに対応する。最新状態を再取得すると、日本語版の新規作成やリダイレクト変更により結果が変わり得る。

cd ops/articles/wikipedia-tech-diffusion-lag-en-vs-ja
python3 evidence/fetch.py
python3 evidence/fetch_pageviews.py
python3 evidence/analyze.py
shasum -a 256 evidence/data/*.jsonl.gz evidence/results.json figures/*.svg

fetch.py は件数クエリと詳細クエリの不一致、英語最古版の欠損、150件未満のコホートで停止する。fetch_pageviews.py はWikimedia Analytics APIの期間境界とタイトル表記の差を検証し、176項目すべての系列が揃わなければ停止する。analyze.py は両入力のハッシュを確認してから、results.json、探索用JSON、コホートCSV、Kaplan–Meier表、カテゴリ表、3枚のSVGを生成する。

記事中の主要数値は <!-- evidence:... --> で示したclaim IDを通じて results.json と結びつく。ビルド時には、データ、取得メタデータ、結果、図のハッシュと記事中の値を照合し、1つでも不一致なら公開対象から外す。

#実務で持ち帰れること

この調査から得られる実務上の教訓は、Wikipediaの順位表より分析設計にある。

1. まだ起きていない結果を削除しない。解約、障害復旧、Issue解決、翻訳完了などでも同じ打ち切り問題が起きる
2. 平均を出す前に観測窓を描く。完了例だけの平均は、長期未完了を隠しやすい
3. 長期中央値の残存数を見る。推定値が計算できても、数件だけで決まるなら主結果にしない
4. IDで結び、リダイレクトを監査する。タイトル文字列の一致だけでは、改名や曖昧さ回避で静かに壊れる
5. 失敗した取得設計も残す。APIエラー後の条件変更が結果を見てからの選択ではないと確認できる

公開データ分析で信頼を作るのは、派手な数字ではない。欠けた観測をどう扱い、どこまでなら言えるかを、読者がコードと固定データで追える状態にすることだ。

#参考・データ出典

• MediaWiki Revisions API
• Wikidata Query Service
• Wikidata linked data access
• Wikimedia Analytics API: Page metrics
• Content Translationの候補機能
• Growing Wikipedia Across Languages via Recommendation
• Considerations for Multilingual Wikipedia Research
• WikiGap: Promoting Epistemic Equity by Surfacing Knowledge Gaps
• 分析結果 JSON
• 分析コード
• 取得コード
• pageview取得コード
• 探索用データ
• 固定データスナップショット
• 全176件のコホート表