Jump to content

ウィキメディア財団年次計画/2025-2026/製品&技術 OKR類

Add links
From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 80% complete.
Outdated translations are marked like this.
Other languages:
ウィキメディア財団年次計画 2025-2026年度

新年度を見据えて

ウィキメディア財団は世界が変化する中でも、私たちの使命 – ウィキメディアのプロジェクト群発信の有用な情報はインターネット上で無償で利用できるようにして維持すること – を複数の世代にわたる努力にしたいと強い信念を持ち続けています。つまり、私たちは今後も数世代にわたって無償の知識を利用できるようにしたいのです。

インターネットは急速に変化し続けています。新しい世代はソーシャル・ビデオや AI 体験を通じて情報を得ており、古い世代に比べるとウィキペディアを知っている人は減っています。それに伴い、サイトを訪れる人数や編集する人数も減っています。その他方で、インターネット上のプラットフォームはそれぞれが提供する AI や検索機能の基盤としてウィキメディアのコンテンツに依存しています。こうした動向は大きな課題ではあるものの、私たちが協力して作り出す信頼できて無償の知識はなぜそこまで重要かを明らかにしてもいるのです。世界はこれまで以上に、信頼できて人間が査読した知識の源を必要としており、ウィキメディアのプロジェクト群はそれを提供できるとこれからも示していきます。

私たちはこれらの課題に対処しようと、今後1年をかけてウィキメディアのコンテンツを持続的に活用する道筋を築いてウィキメディアのコンテンツをオンラインのソーシャル空間に持ち込み、そこで時間を費やす新しい世代に提供する予定です。私たち自身のサイトを改善し、読者が何度も訪れたくなり、それぞれにとって意味のある方法で深く関わり、貢献したくなるようにします。それに加えて新しい技術を迅速に試す能力に投資し、開発のペースは世界の変化のペースと足並みを調整できるようにします。

インフラの目標とは、このプラットフォームとユーザーエクスペリエンス（UE）がこれらの課題へいかに対応させるか、そして、この運動の参加者の大多数にどのようにリーチするかです。単なるプロジェクトの一覧としてではなく一連の方向性の提示すなわち、ボランティアの成長促進、ボランティアが信頼できる百科事典にふさわしいコンテンツを構築できるようにすること、私たちの使命への資金提供、私たちのサービスを進化させて変化するインターネットを形作ることにあります。これら4つの戦略的柱の詳細をご参照ください。

ボランティアの習熟を後押しする

ボランティアのコミュニティはウィキメディアのプロジェクト群の成功を支える唯一の原動力であり、健全であり成長を保つことが不可欠です。しかし、この1年にわたって、プロジェクトの新規編集者とリピーターの数が減少し続けるのを目の当たりにしてきました。既存のボランティアのニーズをより深く理解し、より効果的に対応するため、財団はコミュニティ要望リストを年1回のアンケートから常時利用可能な受付プロセスへと刷新し、利用者のニーズとプロジェクトのアイデアを財団の複数のチームの業務に反映できるようにしました。私たちは要望を「重点分野」に分類し、そのうち3つの重点分野を年間計画の主要な成果に統合しました。また財団チームはコミュニティの皆さんとウィキ内外で年間を通じて数多くの対話を行っており、その補完のため試験的に製品・技術アドバイザリー・カウンシル（Product and Technology Advisory Council）を立ち上げました。さらにまた新しい世代をプロジェクトに取り込むべき機会も把握しており、若い世代がオンラインで積極的に参加する外部のソーシャル・スペースでは、共通の関心事でつながるのに例えばモバイル対応の簡便な方法が用意されているのです。

新年度はモバイルファーストの拡大、新しい編集方法（「構造化タスク」）、そして新しい貢献者が建設的なモバイル編集を容易に行えるインテリジェントなワークフロー（「編集チェック」）の追加を通し、新しい世代にとって貢献をより簡単で魅力的にすることでボランティアの成長を促進します。既存のボランティアにはもっと関与を深めて活動を続けられるようにおすすめの活動とタスクを提供し、ウィキ上の活動を容易に整理できるように、それらを中央ハブに表示します。私たちはボランティアの活動支援に AI を慎重に活用し、常に人間との連携と透明性を最優先します。新人ボランティアと経験豊富なボランティア双方がサイト上でお互いにつながったり協力し合うには – ヒントは成功したキャンペーンやウィキプロジェクトから探して – 複数の場所を作り、同じ志をいだいた編集者を見つけたり、自分の興味に関係のあるコンテンツを改善できるようにする計画です（こちらの要望リストの重点分野と一致）。

百科事典に信頼できるコンテンツを提供

AIが生成した素材がインターネット上に増えるにつれ、世界はますます信頼できる百科事典型のコンテンツを必要としています。私たちは新しいコンテンツの作成と共に、既存のコンテンツの信頼性維持にもボランティアの能力向上を希求しており、そうして信頼できるコンテンツを新たなニーズや好みを有する新世代の読者に届けたいと望んでいます。

コンテンツを新規作成するボランティアを支援するには、既存のガイド付きツールとワークフロー（コンテンツ翻訳ツールなど）を基盤として構築し、どんなコミュニティも規模の大小にかかわらず重要なコンテンツを範疇（はん中）に収めるようにします。既存のコンテンツの信頼性を確保するには、経験豊富なボランティアがますます増え続ける作業をもっと整理できるように、これらの人たちが使うツールを拡張して – 効率よく記事を更新し無益な編集を差し戻せるように – どのタスクに優先的に取り組むか探せるようにします（こちらの要望リストの重点分野と一致）。

さらに、役務を預かりコンテンツ保護を進める皆さんの支援として、（IP アドレス以外にも）悪意のある編集者を識別する新しいシグナルを表面化させて、利用者ブロックの際に善意の編集者が巻き込まれる率を最小限に抑える方法を実現します。

百科事典のコンテンツを新しい世代に届けるようと、私たちが構築する機能では新しいタイプの読者にとって理解が楽で興味をひかれる情報が見つかりやすく、読みながら積極的に参加できるようにします。これらの変更の目的はウィキペディアの新しい読者がますます熱心に閲覧するように励まし、その一部には寄付者になってもらうようお勧めすることにあります（こちらの要望リストの重点分野と一致）。

信頼できるコンテンツの提供とは、インターネット全体がウィキメディアのコンテンツを利用する「サービスとしての知識」というモデルに賛同することでもあります。私たちのインフラは同モデルでは、私たちのウェブサイトが貴重なリソースとなるのはサイト訪問者に限定されず、検索企業や AI 企業も同様であり、これらの企業は私たちのコンテンツに自動的にアクセスし、自社製品への基本的な入力と出力に使っています。私たちのインフラに持続不可能なほどの負荷をかけてくる使い方はますます増えており、こういう種類の企業は、その一部にすぎません。昨年、この傾向の修正が私たちにとってより緊急になったのは、スクレイパー・ツールとボットが寄せるリクエスト量が目立って増大したからです。開発者も再利用者も使える持続可能な経路を確立して知識のコンテンツへのアクセスを確保し、人間がボットよりも優先されるようにしなければなりません。

〈無償〉の未来に資金を用意

私たちの活動が持続可能であると保証する上で、製品技術部門は重要な役割を果たしています。来年度は募金チームと緊密に連携し、より明確でやりがいのある体験を寄付者に提供します。私たちのサイトとモバイル版アプリは、ウィキペディアに対して寄付という形で読者が感謝の気持ちを表す機会を設けて、寄付者が認められたと感じる新しい方法を築き、寄付者が世間に認められているという感覚を引き出し、寄付を毎年続けてくれるように図らいます。

変わり続けるインターネットに形を与える

世界中のすべての人に無償の知識を届けるには、その人がいる場所で、それぞれの学習に役立つ体験を提供しなければなりません。それ以前の世代に比べると、18-24歳人口ではウィキペディアの認知度と使用率が低くなっています。この世代の学びとやり取りは、主に短編動画プラットフォームや、オンラインの信頼できるパーソナリティ、ソーシャル・ゲーム体験、さらにますます増える AI アプリケーションに大きく依拠しています。今年、前述の視聴者が時間を費やすオンラインの場所でウィキペディアを利用できるようにして、ウィキペディアは人間が作成し信頼できる知識の源であると知ってもらうようにします。私たちは人気の動画プラットフォームで存在感を高めて、ウィキペディアのコンテンツを広めること、そういう空間でコミュニティを形成する予定です。さらにアイデアを模索してウィキペディアの知識をゲームやソーシャル・プラットフォームにもたらすことを目指します。

インフラストラクチャ内は、Wikiエクスペリエンス、シグナルとデータサービス、そして将来のオーディエンスという3つの作業ポートフォリオ（「バケット」と呼んでいます）に分かれています。これらのバケットは昨年、一昨年と同じです。

総合的に考えると、この計画はインターネットの歴史における重要な瞬間に適合し、無償の知識コンテンツは今後ともあらゆる世代からアクセスできて、あらゆる世代が形作っていくものであり、それを確実にするのは私たち自身であると信じています。この計画の構造と内容は、私たちの目標と主要な成果に詳細に示してありますので、より広範なコミュニティから質問やアイデアをお聞きできるのを楽しみにしています。

ウィキメディアのボランティアと製品のため私たちの価値観に根差してインフラを改善し持続

「財団はプロジェクトから得られる有用な情報をインターネット上で永久に無料で公開します。」

製品と技術チームはウィキメディア・プロジェクトを支えるインフラの構築、改善、維持については年間を通し恒久的な優先事項として取り組んでいます。ウィキメディア・プロジェクトのホスティング、オープンソースソフトウェアとデザインシステムの開発、そしてデータ製品とAIモデルのインフラの維持・改善に投資しています。

私たちの重要な業務の一部は大規模で人気のあるウェブサイトの開発とホスティングという基礎的な部分に注力させています。ウィキメディア・プロジェクトはデータセンターでホスティングしています。データセンターでは自社で購入・設置・保守するサーバーとハードウェアを用いており、高速ネットワークを介して相互に接続されています。必要に応じて容量を監視し、必要に応じ追加するとともに、老朽化し​​た機器は更新します。例えば、今年はバージニア州アッシュバーンとテキサス州キャロルトンのデータセンターで容量を拡張し、ハードウェアを更新する予定です。

私たちはオープンソースソフトウェア（最も有名なのは MediaWiki）を設計・開発しています。また多くの既存のサードパーティ製オープンソースアプリケーション、ライブラリ、フレームワークも使用・展開しています。私たちのソフトウェアに存在する重要なバグは優先的に処理され、修正されます。オープンソースソフトウェアの維持にはオープンソースソフトウェア開発、サイト信頼性エンジニアリング（SRE）、製品管理、プログラム管理、設計などの専門知識を持つ人々の高度なスキルが必要です。スタッフはソフトウェアとシステムが最新の状態であり、常に変化する環境に適応できるよう努めています。これにはセキュリティ修正の恩恵を受け続け、新しいサードパーティ製ソフトウェアと連携できるようにコードを最新化することも含まれます。たとえばMediaWikiはPHPで記述されており、昨年PHP7.4から8.1に移行しました。この移行にはサイトやサービスをホストするコードとインフラストラクチャの両方の変更が必要でした。今年はその取り組みを基に8.1 へのアップグレードで得た教訓と開発されたツールを使用し8.3 に移行します。アップデートにより閲覧者にとってはシステムの速度が向上し、スタッフやボランティアにとっては使いやすくなり、すべての人にとってより安全になります。また言語アップデートに伴うセキュリティ、パフォーマンス、サポートの改善により、将来の開発時間も短縮されます。

私たちのプロジェクトとコンテンツが現在そして将来にわたってインターネット上で利用可能であり続けるよう、私たちのチームはサイトとサービスの高可用性の確保に多大な労力を費やしています。この取り組みの一つとして、壊滅的または悪意のあるイベントからの災害復旧に重点を置いています。例えば、重要なデータのバックアップを確保し、そこから復旧できるようにしています。同様に、年に2回データセンター間でサイトを自動的に切り替える能力をテストし、問題が見つかった場合は修正しています。この取り組みのもう一つの側面は、私たちが受信するトラフィックの種類と量の進化する傾向を特定し適応することに重点を置いています。例えば、自動スクレイパーがかつてないほど増加していることから、私たちはサイトとサービスが人間のユーザーにとってアクセス可能であり続けることを保証するための作業を優先し、インフラストラクチャの責任ある使用に関する規範を確立するための体系的なアプローチを採用しています。

すべての作業が事前に計画されているわけではありません。サイトの停止、セキュリティ・レポートやセキュリティ事案（incident）、プロジェクトへの大規模な破壊行為など、予期せぬ事態や事案にも対応しています。世界中のパフォーマンスとアクセス障害（インターネット接続の問題や検閲ブロックなど）を監視し、異常を発見した場合は調査を行っています。こうした予期せぬ事態や問題が繰り返し発生する場合、担当者は短期的なフォローアップ・プロジェクトを優先し、さらなる悪影響を軽減または完全に防止することを目指します。こうした取り組みはパフォーマンスの最適化、ボトルネックとなっている領域のアーキテクチャの再設計、容量増強などを組み合わせて、例えば、ウィキメディアのプロジェクトが大きなニュース（著名人の死など）による世界的なトラフィックの急増に耐えるには不可欠でした。同様に、最近、トラフィック管理のツールとシステムの使いやすさを改善したことで、変化する状況に迅速かつ効果的に対応できるようになりました。こうした適応型の作業は往々にして短期決戦型であり、大半の場合は当財団にとって新たに発生する出来事に対応しプロジェクトとコンテンツが利用可能であり続けるよう保証する能力として不可欠でもあるのです。

製品部門および技術部門の目標

ここに示した目標群は草稿の段階であり皆さんのコメントと協議を受け付けています。

  • ここでいう目標（Objectives）とは高次の方向性を意味します。
  • ここで言う"主な成果" （KRs＝Key Results）とはそれぞれの目標を追跡する計測可能な方法のことです。
  • それぞれの主な成果（KR）には下敷きになる「仮説」があり、対応する KR 達成を目指して財団が取り組む具体的な企画を述べています。洞察を得たらそれぞれのプロジェクトもしくは担当チームのページとともに、この文書でも随時、更新するつもりです。
  • wishlist item というアイコンは、コミュニティ要望リストに基づき、財団が優先する作業に付けています。

ウィキ体験（WE）

投稿者の体験（WE1）

  • 目標：ボランティアの皆さんが魅力的な機会に出会い、その影響を理解したから投稿が増えること。 協議する
    • コンテキスト：（訳註：文脈に関する）この目標は、次の3つの柱で新しい貢献者戦略を実現する基盤となります。

1) ボランティアが自身のオンウィキ活動を一元的に管理できる方法を提供すること、 2) より小規模で個別のタスクを提供してより明確にすることで、ボランティアが潜在能力を発揮できるようにすること、 3) 貢献をより有意義なものにすること。 2025/26予算年度にはボランティアがオンウィキ活動を一元的に管理できるように、まず介入を経験豊富な編集者と仲裁者（Moderator）に焦点を当てて基本的なインフラ提供に取り掛かります。その後の数年にはすべての役務を預かる貢献者に介入を追加し、り多くの問題領域を網羅していく予定です。 さらに、編集チェックと構造化タスク（Edit Check／Structured Tasks）への投資を続けて、AIのスケーラブルな活用に関して基盤を構築していき、編集プロセス中のガイダンスとして、またボランティアの皆さんを魅力的な機会へ導く手段として活用します。 そして最後になりますが、ボランティアの皆さんにとって体験の有意義さが増えるよう、皆さんが及ぼす影響の見える化をもっと進めるため投資します。

      • 要望リストの項目 主な成果 WE1.1：実験で測定したように累積の編集数100件未満の編集者がウェブ版モバイル表示で建設的な編集を公開する割合 [i] を4%増加 [ii]（Q2＝第2四半期末時点）。
        • i. 「建設的な編集」 = 言語版にかかわらず公開後48時間以内に差し戻しを受けないウィキペディアのメイン名前空間の編集
        • ii. T389403#10960480
        • 新人（に近い）ボランティアの人は、編集を始める初期に苦労します。特にモバイル機器の利用者は、画面の大きさが限られていて、注意散漫になりがちなために苦労しています。
        • 建設的な編集につきものの状況や忍耐力、試行錯誤に疲れ果てる人もいます。また、魅力的な機会にまだ出会っていなくて挑戦できないままの人もいます。
        • WE 1.1 では以下の課題を扱います。
          • おすすめ編集を表出する
          • 編集中に実行できそうなガイドを提供
          • タスクに特化した編集のワークフローを築くこと
        • これらの取り組みの核にはスケーラブルな方法として進行中の編集や既存のコンテンツをどのように改善できるかを検出するニーズがあります。この能力を高めようと、私たちは機械学習の実験を続け、AI が編集者の役割や経験値の幅に対応しどのように役に立つか、学んでいきます。
        • KR 判定法の提案：管理下実験を通じて導入し評価した介入の比率をプラットフォーム単位で計測し、目安は今年初めに設定した建設的な編集目標値を達成したおよび/または超えたかどうかとします。解釈は phab:T379285#10782051 をご参照ください。
          • 注記：WE 1.1 は2025年6月30日時点で、対照群を用いる実験を2回、実施しました。
  • 要望リストの項目 主な成果 WE1.2：第4四半期（Q4）末までに、各ウィキにおける共同作業の件数を前年比 55% 増やします。
    • 投稿者は他者と協力する機会がなかなか見つからず、特に関心のあるトピックやタスクに関して苦労することがよくあります。そのせいで新規参加者はウィキ類で孤独を感じ、経験豊富な編集者には燃え尽き症候群のリスクがあります。さらに、共同作業の影響は不明確な場合が多く、ウィキ類で共同作業に参加したりまとめたり、手助けしたい人は今後、減ってしまうかもしれません。
    • 共同作業の価値を次のように明確にしようとしています。
      1. ウィキにおいて新しい方法を作成し、共同活動による影響を共有する
      2. 共同作業に関してウィキメディア運動全体からデータを抽出する作業を開始すること
      3. 共同投稿を追跡する基盤インフラを確立して、将来的にはそれら投稿を認識したり報いることができるよう、革新的な新しい方法を提供すること
    • 共同作業はキャンペーンイベント拡張機能（CampaignEvents）のイベント登録を介して、新しく作成された活動を測定します。その目標は、この KR 完了までに拡張機能ツールのユーザーを増やすことと、共同作業の影響を明らかにする新しい方法を増やすことです。これにより既存のインフラと、それぞれのウィキにおいて誰かの作業を認めて報いる他の方法（影響モジュールや感謝ボタンなど）と連携できます。
    • 要望リストの焦点エリア：コミュニティ要望リスト/焦点エリア/投稿者同士の連携
  • 要望リストの項目 主な成果 WE1.3：第3四半期末までに投稿者の 10% にホームページを提供し、新しいモデレータ（仲裁者）による2週連続の訪問を目指します。
    • 私たちはもっと良い仕事をして、ボランティアの皆さんが貢献できる機会をさらに表面化できると信じています。長期的には、編集者が自身の作業を整理し、新しい機会を見つけ、その影響を理解するのに役立つのはホームページであると確信しています。2025/26会計年度の目標として、経験豊富な編集者に新しい機会を示し、それが欠けたままではおそらく出会うことのない、仲裁タスクを引き受けてもらいます。
      • この理論の検証のため、第一に 初心者がアクセスできるのと同様のホームページに、経験豊富な編集者がどれくらい関与するか把握します。
      • それに続き、特定の仲裁活動（詳細は未定）をその種の仲裁に不慣れな貢献者に提示し、その目標は（新しいKRの下で）バックログ削減と経験豊富な編集者の負担軽減に設定します。
      • ホームページのコンセプトが成功した場合は、コミュニティのニーズに応じて、そのページをモジュール化する予定です。そのモジュールとは、編集者が自分の影響力を理解しやすくする機能などを含めることもできます。
    • 方法論に関する注記：
      • 私たちの監修はどんな姿か定義する仮説を得るはずで、WE1.3.1.の一部に組み込んであります。
      • Research:Develop a working definition for moderation activity and moderators※を起点とする定義は「仲裁者」（Moderators）が守るべきものですが、フォローアップ作業によって定量的な定義の絞り込みが必要です（"※"＝仮題：研究：仲裁活動と仲裁者の実用的な定義を開発）。
      • 第2週は、各利用者が最初にいつ訪問したか、タイミングに関連付けて定義します。この場合、指定期間内にホームページにアクセスした新人仲裁者のうち、その後の再訪が（7日〜14日後までに）1回以上だった全員を確認します。
    • 要望リストの焦点エリア：コミュニティ要望リスト/焦点エリア/タスクの優先順位
  • 要望リストの項目 主な成果 WE1.4：ウォッチリストおよび／または「最近の変更」を開いた個別の訪問者で、特定の編集をクリックして閲覧する人の百分率（%）を改善します。
    • 私たちは編集回数合計100件超の編集者を支援するため、その人たち自身の関心につながる編集作業をさらに効率よく見つけて取りかかれるように目指しています。タスクの優先順位付けの重点領域を探求し（Task Prioritization Focus Area）、この領域における要望の実現と、これら領域の改善方法についてボランティアの皆さんからさらにフィードバックを求めていきます。分類の「仕事を見つける」にまとめた各ページの効率を高めるなら、「クリックスルー率」という指示指標で成功を定義させ向上させると成功が測定できるはず。
  • 主な成果 WE1.5：第4四半期末までに、ダッシュボードを作成して月間の活動中仲裁者指標を運用化、貢献者戦略で概説された目標達成に向け進捗状況の追跡に必要な優先度の高い（右記の）指標7件[1]を定義します。
    [1]。継続した編集者、活動の建設的な促進（アクティベーション）、建設的な編集、アカウント登録、新規利用者の定着、活動中編集者の把握は在籍年数別と、同、経験レベル別。
    • 投稿者体験の戦略（contributor experience strategy）では「ボランティアの発展（volunteer growth）を支える」ため努力する期間を3-5年と想定し、また新規も既存も参加者の「定着率と活動を伸ばす」ため次の主な活動領域3つに注力します：
    1. ボランティアの人たちにおすすめがどう届くか、タスクや興味を自分でどう管理するか、ウィキ類でその時点に発生していることを知ったり、自身が及ぼす影響を理解する方法を簡素化
    2. もっと明確になるよう、適切な構造化タスクを提供し、ボランティアがそれぞれの潜在能力を発揮できるように割り当てワークフローを最適化して支援し、それには特にモバイルウェブ体験に重点を置きボランティアに提供する構造化ガイダンスと反復タスク自動化に投資を継続
    3. 貢献が有意義なものになるように、ボランティアの人にそれぞれが及ぼしたインパクトを示すほか、人脈づくりの道筋や肯定的なフィードバックに基づく環境整備に投資すること
    • その後、この変化理論を追跡する広範な指標ネットワークは測定戦略プロジェクトが策定しました。

その結果、成功の主要な指標（「コア指標」）は編集者の定着数として、より限定的な指標として建設的な活性化や寄稿者の復帰の意志ほか、より広範な「下流」指標つまり活動を続ける編集者やコンテンツの質の高さなどは、補完的であるべきという結論に至りました。これら指標をきちんと運用してダッシュボードで見える化し、戦略の実現に向けた進捗状況を追跡できるようにする必要があります。

  • 主な成果 WE1.6：第3四半期末までにウォッチリスト利用者は巡回や編集の成果をフィードバックの定性測定で把握し、それら作業の整理がもっと容易に、実施も効率がよくなります。
    • Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.

重要な知識（WE2）

  • 目標：重要な知識（vital knowledge）は、さまざまな言語やトピックを横断してわかりやすく説明してもっと多く提供すること。 協議する
    • 目標の文脈：この目標はコンテンツ自体の拡張を促すものであり、それを受けて投稿者は特定のトピックや言語に対する関心を深め、読者はわかりやすく説明してある重要な知識を求める需要を満たされます。重要な知識（vital knowledge）とはトピックの幅広さと深さを提供するという特定の記事一式であり、ウィキペディアの各言語プロジェクトが実用的であるために欠かせません。これらを定義するのはコミュニティであり、そのために注目度や関連性、読者数の予測、記事間のつながりを参照します。
    • 私たちは社会技術的なアプローチを採用し、機能やツール、交流プロセスの有効性を高めます。影響力の大きなおすすめタスク、メディア検索、コンテンツ翻訳など製品機能をベースに構築するだけにとどまらず、より小規模な言語版ウィキペディアの導入支援（オンボーディング）と開発も促します。

支援対象のウィキメディアの主催者は、ウィキ・プロジェクト類やキャンペーン類などの共同作業を設定してコンテンツの共通目標に取り組んでもらうために、寄稿者の募集から研修の実施や活動支援まで実施します（四半期単位で活動している主催者は少なくとも 300 名と推定）。また情報源となる素材への障壁を取り除くため、最も関連性の高い出版社と関係を構築します（現状では世界トップの購読性データベース 100 社超と提携を維持）。

    • 私たちの介入が重要な知識（vital knowledge）にプラスの影響を与えると保証するには、コミュニティ優先のコンテンツについてその増加とそれらの質の両方を測定し、注目する要素は改版率、出典（citations）と画像の件数などとします。
      • 主な成果 WE2.1：第2四半期末（Q2）までに投稿者支援の仲裁を3回試行し、当該のウィキペディアにおける重要なコンテンツの状態改善を評価します。
        • この KR では編集メカニズムが含んでいるコンテンツ格差を明らかにし、例えばウィキペディアで画像を探したり、コンテンツの翻訳、新しい記事を書き下ろすときにガイドを参照できるなどがあります。また小規模な言語コミュニティでは社会技術の介入を応用して、コンテンツ作成活動を支えるテストをします。成功の測定はそれぞれの仮説ごとに行います。
      • 主な成果 WE2.2：第4四半期末までに必要なプラットフォーム機能を構築し、 抽象ウィキペディア（Abstract Wikipedia）の理想に大規模な対応が可能とする検証に備えます。成功であると判定するには、ウィキデータを採用し自然言語生成によって豊富なコンテンツが多言語百科事典に出力されていて、それらはウィキメディアのコミュニティが制御している点、広範な実装でもパフォーマンスを発揮する点をシステムに示すことです。
        • ウィキデータを利用するとウィキペディアのコンテンツを基本的な平文で出力できるようになったので、次の段階では、抽象ウィキペディアを大規模にサポートできるプラットフォーム機能の構築を継続します。当該のプラットフォームはコミュニティが制御でき、大規模環境でもパフォーマンスを維持し、多言語の豊かなコンテンツに対応する必要があります。これは0から1へと進む私たちにとっては、マイルストーン代わりのKRとなります。
      • 主な成果 WE2.3：第4四半期末までに、新規コミュニティ構築の初期形式を展開して抽象的な記事類の作成に備え、さらにコンテンツ・ウィキへの統合をプロトタイプ化すること。
        • この KR により来年、プラットフォームとして抽象ウィキ（Abstract wiki）の可能性をテストすることになりました。新しいスタンドアロンのウィキは要約記事（abstract article）のライブラリを関数ウィキ（Wikifunctions）上に構築してホストし、将来的に要約記事をウィキペディアに統合するために必要なプラットフォーム機能を提供します。
      • 主な成果 WE2.4：第2四半期末までに2025-26予算年度の指標と目標を含め、WMFとWMDEの合意を得てウィキデータの重要なユースケースに対応する技術インフラの改善に関する成功を定義します。
        • WMFウィキデータ・プラットフォーム（WDP＝WMF Wikidata Platform）チームは2025年8月設立、製品リードと技術リードがそれぞれ1枚ずつ配置されました。WMFとWMDE（ウィキメディア・ドイツ協会）の技術オーナーならびに製品オーナーはそれぞれ長年を費やした開発プログラムに新しく追加されたこの目標には、ユースケースや依存関係および主要な成功基準の調整を通じて、所有権移行という私たちの意図を反映しています。このKRにより、当会計年度（2026年5月）の残期をとおして問題領域の相互理解に関する基盤を構築します。
      • 主な成果 WE2.5：第4四半期末までに、当財団バックエンド置換は Blazegraph と並行して実施、選択された利用者の切り替えを支援できるようになります。担当チームはこのKR（主な成果）において述べる「移行準備完了」（migration ready）の定義とは、2026-2027予算年度の第1四半期の移行についてパイロット段階に対応可能とします。
        • 成功基準をWE2.4の一部として定義した進捗を踏まえ、私たちは現在、実行モードに移行しました。今後、2期の四半期にわたり、Blazegraphカットオーバーをめぐるすべての変数を移行計画で概説してパイロット試験の開始に何が不可欠か特定、新しいRDFデータベースに実装してパイロット版のペルソナを超え、移行日程表をすべての要件に定義します。私たちの作業は本計画に示された要件に従い、現在以降、WDQSの新しいバックエンドのリリース目標日まで（2026年7月を想定）実施します。

消費者の体験（WE3）

  • 目標：さまざまな世代の読者がウィキペディアに参加して長いあいだ続けると、読者維持率と寄付活動が目に見える形で増加します。 協議する
    • 目標の文脈：この目標が焦点を当てるものごととは、新しい読者の維持は革新的なコンテンツ形式を用いること、コアな読者の維持には慣れ親しんだ読書体験の強化、また長期の持続可能性を確実にするには読者とのつながりを深めたり寄付の多様化を介することです。コン​​テンツを見つけやすくするため、AI 要約や個人化したラビット・ホール（personalized rabbit holes）などの新しい実験的な機能を使った取り組みを継続します。さらにまた、リーディング・ファネル（※）のより深い部分で読書体験の質を維持し向上する取り組みや、読んだ／読みたい記事一覧など編集以外の参加によって、読むという行動のキュレーションを探求することも含まれます。この取り組みは寄付者を対象にする場合、引き続き収益源の多様化の重点をプラットフォームの内部からとします。（"※"＝訳注：Reading Funnel、マーケティング用語、見込み客の行動をモデル化して商品やサービス購入までを段階分け）
      • 要望リストの項目 主な成果 WE3.1：第2四半期末（Q2）までにA/B テストでプラットフォーム単位で単一の拡張機能単位で測定し、非ログイン読者の定着率増加を実証
        • この KR の焦点は、コンテンツ閲覧や学びの最適化を最大化する体験に投資を続けることと、多くの場合に新しい技術と形式の採用を援用して - 既存のコンテンツを魅力的に示す新しい方法に重点を置きます。今年度は新機能の実験を続けながら、実験の成功例をウィキ類やプラットフォーム全体に拡張することにも焦点を当てたいと考えています。当 KR の作業範囲は、Web サイトはモバイル版とデスクトップ版に、アプリは iOS版と Android 版の両方にそれぞれまたがり、コンテンツ発見（閲覧エントリ・ポイントとおすすめ機能）と、適応可能な学びの形式に重点を置きます（記事のまとめや、コンテンツのリミックスに機械支援を援用）。
        • 要望リストの焦点エリア： 新しい消費者体験
      • 主な成果WE3.2：第2四半期末（Q2）までに、寄付者とつながりを育み深めて摩擦を軽減する製品介入を通じて、バナーやメール以外の方法による寄付数をプラットフォーム単位で前年比 5% 増やします。
        • このKRで引き続き模索する件とは複数のエントリーポイントを新設して、読者を寄付者に転換するきっかけ作りと、読者にとってはその他のチャンスを得たり寄付もできるようになりウィキとのつながりを深めてもらうこと、具体的には読者を維持する方策として個人に寄り添ったコンテンツの提供もしていこうとしています。

当KRでは募金チームと協働し、エントリーポイントの新規導入と、アプリとウェブに既存のエントリーポイントの反復改善に重点を置きます。

      • 主な成果 WE3.3：第2四半期末までに、A/Bテストを使いプラットフォーム単位で単一の拡張機能ごとに測定し、ログイン読者の定着率の実質的な大幅増を実証する
        • この KR ではゴールを現在の読者がこれからも読者をやめないことと設定し、既存の読者にも経験豊富な読者にもさらに向上した読書と学習体験をもたらして、それぞれの人がサイトとのつながりを深めたり、より多くのことを学んでもらうことが要点であり、その上で、その人たちが寄付や編集の道に進めるようにこちら側で準備を整えてオープンさを確実に保つことを目指します。ここで注力する作業とは、Web とアプリの読書体験の改善（読みやすさ、ナビゲーションと発見の改善）、さらにキュレーションとパーソナル化を構築して反復改善することにあります（読書リスト、個人に特化したおすすめ、利用歴と記事履歴その他）。
      • 主な成果 WE3.4：第4四半期末までに、現状のキャッシュ・サイトの展開に従い現在のサービス品質とセキュリティ標準を満たす小規模キャッシュ・サイト展開（PoP）に関してそれを阻害すると判明した要因を全て除去します。
        • この KR ではWeb サイトのパフォーマンスを向上させると読者側のレイテンシーを削減できるという概念の証明に焦点を当て、キャッシュのインフラ簡素化、サイト展開プロセスのキャッシュ改善を実現したい、そのためにはベースライン展開時間を現行の平均およそ1年から最高で四半期に短縮することが必要だと考えられます。ここで焦点となるのは簡素化を完了させて固有の PoC を展開し、セキュリティ評価を実施すること、さらに公開クラウドでエッジ・キャッシュの導入をさらに展開するかどうか決定する手順のまとめ作りになります。レイテンシー低減はページ閲覧を増やすと実証済みだし、地理的にもっと多様な読者基盤をもたらす可能性があります。
      • 主な成果 WE3.5: 第4四半期末までに、寄付者の識別を改善し同意したログイン済みのすべての閲覧者を寄付者のステータスで識別しパーソナライズされたエクスペリエンスを提供できるようにします。
        • 寄付者識別戦略を導入し、同意を得たログイン済みのすべての閲覧者を寄付者ステータスで識別できるようにすることで、よりパーソナライズされた惹きつける体験を実現します。寄付者識別の取り組みは第4四半期まで優先的に実施し、将来的に効果的なパーソナライゼーションとアクティベーションの取り組みを支援します。
      • 主な成果 WE3.6：関係者およびコミュニティと協力して明確な目標と基準指標を定め、ウィキペディアの読者・消費者体験に関する戦略をプラットフォーム横断型で策定し、第4四半期末までに最終決定、公開、周知することで2030年までの活動の指針とします。
        • 消費者戦略に関する作業は、コミュニティおよび内部対象の戦略の構築と伝達に注力し同時にコミュニティと協働で続けて、消費者対象のコア指標、それぞれのベースラインの定義と確立に重点を置きます。
      • 主な成果 WE3.7：第3四半期末までに製品介入を通じて、プラットフォームごとにバナー以外またはメールによる寄付件数を前年比（YoY）10%増を達成するため、寄付者とのつながりを深めたり、寄付者の受ける違和感を減らします。
        • This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
      • 主な成果 WE3.8：第4四半期末までに（ウェブおよびアプリなど）プラットフォームごとに機能に適したガードレールを監視しながら1回以上の実験を展開し、テスト環境における保持率の改善または実質の閲覧者をとらえた指標を示します。
        • This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
      • 主な成果 WE3.9：第4四半期末までに、（ウェブおよびアプリなど）プラットフォームごとに少なくとも1回以上の実験を展開し、機能に適したガードレールを監視しながら、保持率改善を示すか、テスト環境において非ログイン状態のカジュアルな閲覧者をとらえた指標を示します。
        • In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
      • 主な成果 WE3.10：第四半期末までに（ウェブおよびアプリなど）プラットフォームごとに非ログインのまま利用するカジュアルな閲覧者の保持率をめぐり1件以上の実験をして、実質的に有意な向上を示すか、もしくはコントロール群に関する別の指標との対照分析をします（保持期間の指標はウェブは21日間の、アプリは14日間と定義）。
        • We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

安全性と情報保護（WE4）

  • 目標：私たちのシステムは利用者のアカウントならびにプライベートな情報の保護をおのずからより良く保護し、拡張権限をあずかり、いじめ行為の防止と対応にあたる編集者と利用者には、より多くの経路を提供します。 協議する
  • 主な成果 WE4.1：すべてのウィキに第2四半期末（Q2）までに、簡単に見つけられ文脈に沿った事案通報システムとして、それぞれのコミュニティで使われていて享受されるものを導入します。
    • 利用者の安全と幸福の確保は、私たちのプラットフォームの基本的な責任です。多くの法域では、ウィキメディアのようなオンラインのプラットフォームでは嫌がらせやネットいじめを発生させるなどの有害なコンテンツを監視し、対策を講じるよう義務付ける規制があります。これらの問題に対処しないままだと、プラットフォームは法的責任や規制上の制裁を受ける可能性があります。
    • 私たちは、利用者が簡単に見つけて直感的に報告できるメカニズムを通じて、危害の差し迫った脅威を報告できるようにし、そのような事案（incident）の把握と必要に応じた迅速な対応に結びつけたいと考えます。これはプラットフォームに貢献する利用者に安心してもらうための第一歩です。私たちはこれを実現しようと、今まさにウィキ類に事案報告システムを展開しているところです。
  • 主な成果 WE4.2：不正使用防止ツールの精度と効果を高めるため、第2四半期末（Q2）までに改善点を2件展開します。
    • コミュニティと私たちは、ウィキにおける不正行為や悪意のある活動をより適切に検知し防止しなければなりません。その対策としてプラットフォームで利用可能なシグナルの件数を増やし質を高め、拡張権限を預かる利用者が利用できるツールに統合して、疑わしい活動に自動制限をかけても安全な箇所を特定する見込みです。
    • また同時に、ウィキペディアその他のプロジェクトでアクセス性を向上させる機会も見出しています。例えば、あるプロジェクトではウィキでよく目にする自己管理型の（利用者がパズルを解くまでログインできない）CAPTCHAから、利用者にほとんど質問しないリスク・スコアリング・サービスに置き換える予定で、このサービスでは暗黙のうちに疑わしさの度合いをアカウントにタグ付けし、それを利用して機能停止できるようにしてあり、その状態は高い権限を持つモデレータに可視化して作業を補佐できるようにします。
    • 一般に、ウィキメディアのプロジェクト群は悪質な行為者による不正使用の軽減は、IP アドレスのブロックに大きく依存しています。これは不正使用を阻止する上でますます効力をなくし、善意の利用者に悪影響を及ぼし IP アドレスおよびその範囲のブロックの影響を及ぼしています。この KR では既存の機能を改善し、不正使用者をもっと正確かつ効果的にブロックできるよう新しいツールの提供と、IP アドレスおよび IP アドレス範囲のブロックに起因する巻き込まれ被害の軽減を目指しています。
    • 私たちの有効性の評価に向けて、不正使用対策に携わるボランティアの皆さんから定性的なフィードバックと、定量的な指標として IP ブロックを展開した割合、IP 評価とブラウザ・シグナルに基づく軽減策の採用の状態、ブロックされた利用者を助けるため人手で対処する割合などを確認します。
    • この KR 関連の作業には、ソックパペットや追放回避の検出精度の改善と不正を減らすこと、巻き込まれ被害かもしれない事例に関する情報の表示、ボット検出の強化、不正行為対策ボランティアに表示するシグナル類、不正行為対策ツールのインターフェース効率化、不正行為関連の指標の改善、疑わしいアカウントの活動を洗い出してチェックユーザに提供し調査を依頼する案が含まれます。
  • 主な成果 WE4.3：SRE の人的介入を必要とする大規模攻撃の数を 50% 減少させます。（前予算年度比）
    • インターネット環境の進化は、大規模なボットネットの台頭や攻撃の頻繁化などにより、従来の方法は大規模な不正行為を制限しようとしても時代遅れになりました。このような攻撃を受け、リクエストがインフラに殺到してサイトが利用できなくなったり、大規模な破壊行為に対抗するコミュニティの能力が圧倒されたりするかもしれません。また高い権限を預かる編集者や技術コミュニティに過度の負担がかかってしまいます。
    • このような攻撃を自動的に検出し、耐久して軽減または阻止する能力は、早急に向上させる必要があります。
    • 今年は、私たちに対して定期的に攻撃をかけてくる IP アドレスとネットワークの検出を自動化し、有害な実体が私たちのシステムに継続的に加える負荷の軽減に重点を置きます。
  • 主な成果 WE4.4: 第2四半期末（Q2）までに、仮アカウント（Temporary Accounts）をプロジェクト群100%に導入し、アカウント未登録編集者について個人を特定できる情報の開示は利用者の0.1%未満に低減します。
    • 仮アカウントの目的は、未登録編集者の個人特定情報（IP アドレス）を一般の閲覧から保護し開示（アクセス）は巡回に必要な人に限定する事で、個人情報保護を向上させて安全性を高めることにあります。このプロジェクトは利用者の安全性を大幅に向上させるだけにとどまらず、さまざまな規制要件の準拠においても重要です。
  • 主な成果 WE4.5：信頼と安全のために生成 AI の影響を評価して公開し、第3四半期末（Q3）までにウィキメディアのプロジェクト類において機会の活用と脅威防止を目指し、製品介入について決定します。
    • AI、特に生成 AI の利用は、インターネット全体で急速に増加しています。AI の普及につれ、信頼と安全に関する機会と脅威が生まれます。例えばコンテンツの作成は容易かつ安価になっても、適正化はますます困難になりました。同様に、調査研究は、はるかに少ない労力で実施できるようになったものの、AI による誤情報（hallucination）の特定はますます困難になりました。
    • このプロジェクトではウィキメディアのエコシステムにおける信頼性と安全性の側面に対する AI の影響を評価し、ML/AI の人権影響評価を基盤することを目的とします。これには以下が含まれます。
      • 拡張権利を預かる利用者との協議。
      • 生成 AI による不正使用の事例と潜在的な軽減策を特定すること。
      • 拡張権限を預かる利用者の負担を軽減するため、ML の機会を特定すること。
      • 最大の影響を与えようとするなら、何に重点を置くべきか理解する実験を実行。
  • 主な成果 WE4.6：第4四半期末までに、利用者がセキュリティまたはプライバシーに配慮した操作の実行を認める権限の100%を技術的に強制し、2要素認証を有効にしたアカウント限定で実行できるようにします。
    • ウィキ上の利用者アカウント、特に機密性の高い権限を預かる利用者のセキュリティを強化する必要があります。重点的に取り組むべき点は、機密性の高い操作を実行できる人は2要素認証（2FA）を有効にした利用者限定にすることです。権限の適用に関して、拡張性がもっと高いシステムを構築し、監査や手動による 2FA 適用を不要にします。またプラットフォーム上で 2FA の有効化を求める権限の範囲を拡大します。
    • この一環として WMF と利用者がもっと厳格な2要素認証（2FA）の対応を容易に行えるように、認証および復旧システムを改善する予定です。2要素認証の一般提供をプラットフォーム全域で拡大して、利用者なら誰でも必要に応じて 2FA を有効にでき、なおかつ機密性の高い権限の付与に先立って確実に有効化できるようにします。またアカウント復旧およびサポートシステム運用の負荷軽減にも注力し、アカウント・ログインに関連するリセットおよび復旧プロセスの効率化を進めます。さらに 2FA 実装の使いやすさを向上させるため利用者に提供する選択肢を増やして、アカウントのセキュリティ確保と、誤ってロックアウトされる事例を防ぐ予定です。

インフラの責任ある利用（WE5）

  • 目標：開発者と再利用者は、厳選された経路で知識のコンテンツにアクセスし、インフラの持続可能性とコンテンツの責任ある再利用を保証します。 協議する
    • 目標の文脈：この目標の重点は、コンテンツの責任ある再利用に道筋を確立することにあります。
    • ウィキメディアはウェブ上にあり、人間が査読してきた最大の知識コレクションをホストしています。これにより私たちの知識インフラは人間ばかりかデータの自動化消費者にとっても、貴重な目的地になりました。私たちのコンテンツは検索エンジンやソーシャル・メディアのプラットフォーム、e コマースに受け渡され、AI の台頭以来​​、大規模な機械学習モデルのトレーニングに使われています。消費者はデータを取得しようとページをスクレイピングしたり API を使ったり、コンテンツをダウンロードしたりします – 通常は帰属を表示しないまま。利用者の認証をしないトラフィックの世界ではユーザーを一人ずつ確実に識別しようとしても不可能なため、私たちのインフラの責任ある使い方ができるようにするのも、責任を負うように強制するにも能力を大幅に制限されてしまいます。

コミュニティが今後も有効であるようにしながら、コンテンツの自動消費にしきい値を設けるにはどうすればよいでしょうか？ どうすればユーザーがサポートを受けられ推奨されるチャンネルに誘導できるでしょうか？ 責任あるコンテンツの再利用を奨励するには、どのようなガイダンスが求められるのか？ 一貫性のある開発者体験を推し進めながら、どうすればボランティア開発者や職員や再利用者のニーズを満たす製品を構築できるのか？ これらの疑問のすべてが目新しいわけではなくても、これらに緊急に対処しなければならない事態は飛躍的に高まっています。つまりリクエスト数は2024年以降、劇的に増えており、その増加のほとんどはクレイピング・ボットによるもので AI を活用したワークフローや製品のトレーニングデータ収集が目的です。インフラには持続可能でない負荷がかかっており、人間が知識にアクセスしようとしてもできない危機が迫っています。健全なバランスを再構築するには今すぐ行動を起こす必要があり、ウィキメディアのプロジェクト群を効果的に支え、私たちの使命が持続して成功を続けられるようにしなければなりません。

      • 主な成果 WE5.1：第4四半期末（Q4）までに、自動化されたアクセス・チャンネルは既知の開発者またはアプリケーションに起因する割合が50%に達します。
        • 現時点では、自動トラフィックの責任者を特定する方法は限定的で、オンウィキとは異なり利用者との連絡やアクセス権限を規制する方法も限られています。外部からの自動トラフィック量が大幅に増加しており、私たちにとって持続可能ではなく、人間による知識へのアクセスにリスクをもたらすものです。既知のアカウントに起因する自動トラフィックの割合増を目指して、大量の情報スクレーピングと API 使用に対しては階層化したアクセス・レベルに基づいて認証と承認を求める所存です。これによりインフラ保護、公正使用に関する組織統治（ガバナンス）改善のため、コンテンツを大規模に再利用するユーザーを特定し、並行して利用者のニーズにもっと効果的に対応できます。また技術コミュニティをより適切にサポートする方法も検討し、より一貫性のある開発者エクスペリエンスの提供によってコミュニティ参加者の優先アクセスを保護し、開発者に新機能を提供していきます。
      • 主な成果WE5.2：2025 年第4四半期末（Q4）までに、ウィキメディアのウェブ API エンドポイントの 70% を共通インフラでサポートします。、
        • 私たちは開発者パスウェイのエクスペリエンスと持続可能性を向上させようと、ウィキメディアの開発者全員に、一貫性を高め安定していて発見しやすいウェブ API の提供を目指しています。集中化を高めたインフラをコア API 機能に導入して、 API 提供の簡素化と共に、次の事項は一貫したパスウェイとガバナンス実現の対象にするよう目指します。すなわち OpenAPI 仕様と解説文書、開発者の識別とアクセス制御、API に方針を施し、ルーティングとバージョン管理、エラー処理。API 提供の合理化とは、ウィキメディアの使命に役立つツールやボット、研究プロジェクトや機能の構築をより迅速化してより簡単に、そして楽しくすることです。このアプローチにより複数世代にわたる使命の未来を支え、そのために API インフラの管理コスト削減、悪質な行為者に対抗する可視性とアクセス制御の高度化、より強力な開発者コミュニティ育成を実現します。
      • 主な成果 WE5.3：第4四半期末までにウェブ版、アプリ版、音声アシスタントと LLM に新しい帰属フレームワークを公開して、ウィキメディアのサイト全体にリンクを貼り、再利用のデモを2件導入して測定可能な関与を促したり、外部の再利用パートナー1件に最善慣行の帰属を採用してもらいます。
        • 責任ある再利用を促進する明確な最善手法のガイダンスを提供し、ウィキメディアのコンテンツの適切な帰属表示を増やします。これは具体的には主要なプラットフォーム（ウェブサイト、アプリ版、音声やマルチメディア）の帰属表示フレームワークの作成と、実用的な例を少なくとも2件提示することで、ウィキメディアのコンテンツの模範的な適用を強調します。成果の例には、メディア組織を促してウィキメディア・コモンズの画像にクレジットを付与してもらい、関連のあるウィキメディアのデータを検索エンジンにもっと効果的に表示させること、または透明性と責任ある方法で AI アシスタントにウィキペディアの知識を統合させて信頼性を高めることなどがあります。帰属表示の実践を強化すると、一般の認知度が高まり、ウィキメディアのプロジェクト群への関与が進むばかりか、知識のリミックスや、責任を負って誤用を阻止する新しい方法確立にも役立ちます。
      • 主な成果 WE5.4：情報スクレーパーに起因する量は、リクエストのレートで測定値20%、帯域幅で測定値30%を削減します。
        • スクレーピングは昔から行われてきました。利用者に情報を提供しようと検索エンジンがウィキペディアに依存してきた年月は十年どころではないものの、直近では私たちのデータをかき集める別の大きな動機があります。つまりインターネット上で査読済みの多言語知識コンテンツを探すとこれが最大の一式であることと、大規模な言語モデルをトレーニングするには基本のツールだからです。これは私たちがかかえる百科事典のコンテンツと、ウィキメディア・コモンズというマルチメディアのリポジトリの両方に当てはまり、画像を生成する機械学習モデルにとって非常に貴重です。
        • その結果、過去1年にスクレーパーのトラフィック量が大幅に増加し、関連のサイト安定性事案（インシデント）も増加しました。サイト信頼性エンジニアはクローラーのレート制限または禁止をケース・バイ・ケースで繰り返し実施して、インフラを保護しなければなりませんでした。スクレーピングは、私たちの送信帯域幅が2024年に50% 増になる程、非常に顕著になりました。それに加え、最近の分析では、最もコストのかかる※リクエストの少なくとも 65% は、ボットが実行していると判明しました（※＝キャッシュ・サーバでは対応できないためメインのデータベースが提供する）。
        • 私たちが生み出すトラフィック量に比べると、私たちの計算機処理リソースは非常に限られており、それらのリソースを誰に提供するか優先順位をつけなければならないし、優先するなら人間の消費であり、リソースが限られているのだから、ウィキメディアのプロジェクト群と貢献者への対応を優先したいと考えています。

製品を提供する道のりをできるだけ早く（WE6）

  • 目標：ウィキメディア開発者は、迅速かつ確信を持って製品をエンドユーザーに提供すること。 協議する
    • 目標の文脈：戦略の4本の柱を効果的に達成するには、ウィキメディアの開発者は高品質の製品をできるだけ早く提供しようとするなら、効果の高い活動に時間と労力を費やす必要があります。ワークフローが過度に複雑だったり、標準ツールの欠如、あるいはシステム構成要素（コンポーネント）が持続不可能では、これらの成果を妨げるばかりです。
    • この作業の基盤には、過去2年分の計画で得た勢いがあり、メディアウィキをプラットフォームとして、またその開発と展開を支えるソフトウェアとして進化させています。この年の作業の重点は、より信頼性の高い開発環境の提供、プリプロダクトのワークフローの簡素化、プラットフォームとインフラのリスク軽減に置きます。
      • 主な成果WE6.1: 第4四半期末までに、テストウィキのトラックを超越する並列トラックのバグ（train-blocking bugs）の件数を10%削減
        • 2024年には、メディアウィキの展開を妨げる緊急事態が発生したせいで、開発者が作業をやり直さなければならなかった回数は144回でした。バグはこれらの事例の多くでテスト・ウィキに展開後に発見され、つまり問題の及んだ範囲は潜在的な数十億人の利用者でした。バグがあるという事実は私たちには制御できないとしても、バグの早期発見ができたなら、ヒーロー・ワーク（hero work）の必要性が減ります。さらに開発者には、実際の運用に移行しても問題が起こらないという信頼度を植え付ける可能性があります。
        • これらのバグを早期に発見するには、開発および展開のライフサイクル全体を通じて、開発者が自信を持ってコードを配信およびテストする必須環境を提供します。さらに欠かせないのは、これら改善が開発者の速度を犠牲にしないことです。
      • 主な成果 WE6.2：第4四半期末までに、製品版の準備完了評価チェックリストの4ステップを SRE の介入なしに実行できるようにします
        • サービスや機能を新しく本番環境に導入するには、現状で24段階のリストに従わなければならず、各ステップでは通常、SRE（サイト信頼性エンジニアリング）の支援が欠かせません。そこでSRE アンバサダー・プログラムを確立し、開発サイクルの早い段階で介入してもらい開発チーム自体の能力を高めようとしましたが、タスクの多くは完全に自発的に対応であるべきです。現状では、自動化可能なのに手動の反復作業が山積しており、開発チームの件数に応じて線形状に増えていきます。長い目で見ると、これは SRE チームにとって持続可能ではありません。
        • こうした作業の多くは従来は開発チームでは抽象概念とされたままであり、プラットフォームとやり取りする一連の共通ライブラリを共有し、最善手法の維持により、乗り越えてきました。ところが新インフラの Kubernetes に移行したときにこれらは廃止されたきりで、直接の代替手段はないままです。現在、私たちが構築し展開する方法に適用できるように、同様のライブラリや解説文書や研修を提供したなら、サービスや機能を新しく製品環境に展開する前段階で必要な関与の量を SRE（サイト信頼性エンジニアリング）から減らせると考えています。
      • 主な成果 WE6.3：第4四半期末までに、ウィキペディアのページ閲覧数は Parsoid 経由で100%提供すること
        • Parsoid は強化された機能を提供し、ウィキ文の進化とプラットフォームの将来性を保証します。パーサ2つを同時に維持しようとすると技術的負債と複雑さが増してしまい、長期的には持続可能ではありません。さらにウィキ関数（Wikifunctions）など新プロジェクトの成功は、Parsoid が広く利用可能であることに依存しています。
        • 私たちは、小規模なプロジェクトを対象にロールアウトを拡充してきましたが、今年はウィキペディア類に取り組む準備が整う予定です。ウィキペディアのページビュー総計を Parsoid（パーソイド）を使って読み取ること、これが次の最も重要なマイルストーンです。この作業はロールアウト自体に加えて、パフォーマンスの課題解決と、読者や編集者にその影響を効果的に伝えることも含まれます。
      • 主な成果 WE6.4：第2四半期末までに、ウィキの展開や拡張継続の能力を脅かすと特定されたリスクを少なくとも2件、軽減または許容レベルまで削減する作業を完了すること
        • 私たちのプラットフォームと公開プロジェクトの成長と持続可能性に迫る潜在的な脅威としてスケーラビリティや信頼性、またはセキュリティのリスクがいくつか特定されており、それらはターゲットを絞ったいくつかの取り組みで軽減または緩和する予定です。
        • 一例として、今後の数年でウィキメディア・コモンズのコアなデータベースの構造をリファクタリング（訳注：ソースコードの内部構造を整理）して、利用可能なサーバのハードウェアの容量が成長を制限しないようにする予定です。また、メディアウィキと関連サービスを動かすプログラミング言語の PHP は、より新しいバージョンに更新する予定です。特定済みのその他のリスクのせいで、セキュリティ対策を追加してインフラを保護し強化する必要が出てくる可能性はあります。

信号およびデータサービス（SDS）

指標（SDS1）

  • 目標：意思決定者は製品や戦略の決定について、信頼できてタイムリーな指標をより多く活用して、役立てています。 協議する
    • 目標の文脈：私たちは指標を利用し、ウィキメディア運動に最善のサービスを提供するにはどこに私たちの努力を集中させるか、財団の意思決定に情報を伝えます。しかしながら、データのバイプラインには破断しやすいものがあり、データ伝達を遅延しがちです。データに問題が浮上すると、識別までの時間と解決にかかる時間が手に余るほど増大します。私たちのデータセットの多く傾向を容易に調査できるようには最適化されておらず、データの解釈に重要な側面が欠けたままです。これらの問題のせいで私たちの能力に制限がかかり、指標の評価を遅らせます。
    • 2025-26会計年度には特定の年次計画の使用事例に重点を置き、現在のパイプラインにおけるデータ品質の格差解決についてデータ品質の問題を監視して解決するインフラと手順を設定し、意思決定者が傾向を理解できるようにツールを配布します。
    • 一つのユースケースは人間とボットのトラフィックをどのように測定するかという点です。ここ数年の自動トラフィックの増加により、人間がウィキメディアプロジェクトにどの程度関わり、貢献しているかを把握することが難しくなっています。私たちは、計画や製品開発の意思決定において重要な情報となる人間とボットのトラフィックパターンを評価する能力の向上を目指しています。
      • 主な成果 SDS1.1：第1四半期末までに、ページ閲覧指標を用いるアナリストに対し、データ品質ベースライン指標と自動トラフィック検出ヒューリスティクスのパフォーマンス測定にアクセスを設けること
        • この KR で検討する仮説からは、現在のトラフィック検出自動化ヒューリスティクスのギャップは何か、ページ閲覧のトラフィックを適切に分類できない部分はどこか特定し理解しようと目指します。これらの洞察はページ閲覧の指標生成と分類をになうパイプラインの改善に役立ちます。さらにータ品質指標を定義して、データ精度の向上を監視し測定します。
        • この KR はこの段階でパイプラインのどんな改善が必要か特定して、後続の KRの基礎を築くとともに、重点を実装に渡していきます。このフェーズで確立したデータ品質の指標は、将来の機能強化の有効性を評価するベンチマークとして機能するものになります。
      • 主要な結果 SDS1.2：第1四半期末までにコンテンツ履歴データセットの内容を入手するには、週次配信保証（SLO）付きのファイルエクスポート経由で可能にします。エクスポートしたファイルデータの品質（parity）は、従来の XML Dumps 1（ダンプ 1）のエクスポート・パイプラインと同等になるはず。
        • 2024/25年度KR1.4の目標は、最も関連性の高い3つの下流パイプラインについて、毎月更新される mediawiki_wikitext_history および mediawiki_wikitext_history_current データセットへの依存を取り除き、週ごとの SLO が保証された代替データセットを提供することです。
        • 年次計画24/25の KR1.4 では、最も関連性の高い依存パイプラインの信頼性の問題軽減に役立ったものの、信頼性の低いレガシー入力ソースが残ったままのパイプラインもまだあります。これらパイプラインもファイルベースの入力ソースと同様に、ウィキ文の履歴データセットそのものに移行する必要があります。
      • 主な成果 SDS1.3：第2四半期末までに、ボット検出は信号1件を追加して組み込み、異常に対して自動アラートが生成させます。
        • 財団全域の製品や資金提供に関する意思決定は、チームごとに人間の読者と自動トラフィックの違いを判断できるかどうかを基準にしています。データ・プラットフォーム（Data Platform）は、ボット検出シグナルとバッチ分析に用いる中心的なリポジトリです。去る第1四半期と第2四半期に検討した仮説に基づき新たなボット検出シグナルの導入を開始して自動トラフィックの分析をより精緻化、また新たなシグナルの導入プロセス実施を効率化かつ繰り返し可能にする予定です。
      • 主な成果 SDS1.4：第2四半期末までに、意思決定者は組織指標から得る洞察の現状を明確に把握できるようになります。成功の目安とは取締役会で活用できるプレゼン資料を提供できるかどうかで、そこにはウィキメディアのエコシステム全域と、より広範なインターネットの市場におけるトレンドや課題の両方において、指標分析を位置づけて提供します。
        • 組織指標から得る洞察は、財団全体のさまざまな意思決定に活用され、そこには製品の開発方法、インフラ資源の配分方法、また資金調達方法などが含まれます。同時に、インターネットを取り巻く環境は変化しており、特に自動化トラフィックは私たちの指標に影響を及ぼしています。財団のリーダー層は内部指標と外部トレンドの確かな分析に基づき、ウィキメディア・エコ​​システムへの脅威と機会について12月の理事会に明確なストーリーを用意して臨もうと目指しています。そのストーリーは以下の点について洞察、指標、データポイントを収集して確信を持って示唆すると実現します。
          • 内部の読者数測定の傾向（ページビュー）
          • 寄稿者のエコシステムの傾向
          • 外部データと競合相手の基準値の傾向
          • 信頼できる研究ならびに社内外の調査から得る洞察
      • Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
        • In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
          • Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
          • Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).
          • We will need knowledge and calibration from third-parties that specialize in this domain to be able to quantify our current state and prioritize future improvements.
        • In Q3/Q4, we will follow that with three main deliverables:
          • Extend our pageview metric to incorporate a numerical confidence score in addition to the existing labels, computed from at least 2 new signals, which will allow analysts to quantify and convey the nuances of those signals.
          • Curate trusted labels, preferably sourced from a third-party that specializes in this domain, and use it to evaluate our current performance and better understand the new signals.
          • Operationalize a client-side signal, which remains the most promising internally developed detection method.
      • Key result SDS1.6: Deliver a Movement Insights report on a regular basis, with consistent coverage across readership, contributors, and content thematic areas. We’ll know we’re successful when we’ve established the following by the end of Q4:
        • A consistent delivery cadence
        • Most valuable content for our stakeholders
        • Areas for future automation
        • Today, critical signals about the health of the Wikimedia Movement are fragmented across systems and teams. Readership trends, contributor health, brand perception, SEO/AEO, and competitor intelligence are monitored independently, without a consistent process or systems to aid in interpreting them together. We have existing monthly metric monitoring processes but they don’t address the scope and focus that is needed by executive decision-makers. The Movement Trends Brief is a concise, recurring intelligence brief that provides leadership and product teams with a shared understanding of how the Wikimedia movement is evolving week over week. Rather than describing everything that happened, this communication answers the following questions consistently:
          • What meaningfully changed in the past week/2 weeks?
          • Have we learned anything new about existing trends that we’re questioning?
          • Why does it matter now?
          • What requires attention or action?
        • The brief is designed to support situational awareness and provide a forum to present deeper analysis. It surfaces early signals, connects related trends across various data sources, and creates an entry point to inform decision-making.

実験用のプラットフォーム（SDS2）

  • 目標：製品マネージャーは、製品機能の変更がウィキペディアに及ぼす影響を迅速かつ簡単に、自信を持って評価できます。 協議する
    • 目標の文脈：製品機能の開発においてデータに基づく意思決定を可能にし加速するには、製品マネージャーが使える実験プラットフォームが必要で、そこでは機能の定義、対象利用者層の選択、影響測定が可能になります。作業開始から分析までの時間短縮はとても重要であり、学習のタイムラインを短縮すると実験が加速し、最終的には革新（イノベーション）が進むからです。手動タスクと測定に特注のアプローチをするから、スピードアップを妨害すると判明しています。理想としては製品マネージャーが実験の開始から発見まで、技術者やアナリストの手動介入をほとんどもしくはまったく行わないシナリオを採用することです。

来たる会計年度には、コアな体験（Core Experiences）が実験対象として関心を持った分野がウィキペディアである点（組織戦略ではウィキペディアに注力）、また、私たちがウィキペディアに重点を置く理由は、どのチームが、あるいはプロジェクトが進行中か、より明確に示して焦点を絞ることが可能だからです。他のチームも実験プラットフォームの構成要素（コンポーネント）を現在は用いており、今後も使い続けるかもしれませんが、それらにはこの目標で使うために焦点を当てていません。

      • 主な指標 SDS2.1：第2四半期末までに、実験プラットフォームを使用し少なくとも2つの完全な実験サイクルを完了できるようにします。
        • 組織がデータに基づいた製品開発の意思決定をより重視するようになるにつれ、専門的なスキルを持つチームだけでなく、すべての製品チームが実験にアクセスできるようにする必要があります。製品チームには、以下のことを可能にする共通の標準、ツール、そしてインフラストラクチャが必要です。
          • グローバルユーザーベースでアイデアを迅速にテストします。
          • 標準化されたメトリックを使用し製品変更の影響を測定します。
          • 運動の関係者との間での成果を透明に共有します。
        • なぜ「チームを実行可能」し「実験を完了する」に焦点を当てているのでしょうか?
        1. 戦略的調整: プラットフォームの主要な成功指標
        2. データに基づくアプローチ: ユーザー調査 (進行中) では、組織全体でチームの準備状況にばらつきがあることが示されていますが、Webチームが2つの実験に興味を持っていることが確認されています。
        3. リソースの最適化：MVPプラットフォームの展開には、きめ細やかなオンボーディングが必要となるため短期的には複数のチームにまたがって広範囲に展開するのではなく、実験の機会に注力する方が効率的です。一般リリースに向けて進めていく予定であり、可能な限りチームのトレーニングに再度投資することは避けたいと考えています。
        4. 将来を見据えて：完全な実験サイクルからのフィードバックは、部分的または不完全な導入から得られる知見よりプラットフォームの改善に役立ちます。一般公開に向けて前進する過程において実験の完了に注力することで、一時的なアプローチへの投資を避け、再開発の必要性を回避します。
        • 現在、チーム全体のニーズと要件を把握するためのユーザー調査を実施しています。2025年5月後半には、製品チームのニーズを明確にするためのアンケートとインタビューを実施する予定です。調査の完了しだい、次のKR目標と優先順位を設定するために使用できる実験カレンダーを作成します。
      • Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
        • After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
        • Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
        • 年次計画2024/25年版のSDS2期間中にアーキテクチャ上の決定をしてGrowthBookのモジュラー化を実施しており、「実験ラボ」（Experimentation Lab）の一部を序列外に置き換えることが可能、すなわちウィキメディア財団職員はGrowthBook を採用して実装と同時進行で実験の分析ができ、実験の定義にはxLab UI を使います。 さらに現状の実験分析パイプラインとGrowthBookを並行して実行した場合、現実世界のシナリオにおける並列比較やユーザー受容テスト（User Acceptance Testing）が可能になります。
      • Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
        • The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
        • KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
        • This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

将来の観衆（FA）

将来の観衆（FA1）

  • 目標：ウィキメディア財団は私たちの活動が変化を続けるインターネットで新たな視聴者にサービスを提供できるよう、戦略的投資について推奨事項を備えています。 協議する
    • 目標の文脈：ウィキメディア運動は読者や寄稿者を引き付けよう、維持しようとして苦戦しており、それは技術とオンライン利用者の行動が絶えず変化するからです（例：ソーシャル・アプリ経由で情報を入手する傾向の高まり、エデュテインメント人気が短い動画に偏ること、生成型 AI の台頭など）。これらの変化に伴い、情報作成と提供の新しい方法がもたらされて、新しい観衆に提供するサービスも機会も生まれています。しかしながら、私たちはウィキメディア運動として課題を克服して新しい機会をつかみたくても、データに基づいた明確なイメージを持たないままであり、どんな潜在的な戦略があるのか、それぞれの利点とトレードオフを完全には把握できていません。一例として、次のような戦略を採用すべきか、やめておくべきか……。
      • チェットボットなどの新しい大規模な機能に投資してみる？
      • ウィキメディアにある知識と道のりを使って人気のあるサードパーティのプラットフォームに貢献してみませんか？
      • 他にもありますか？
    • ウィキメディアが複数世代にわたるプロジェクトとなるよう、私たちは仮説を検証し – ウィキメディア財団とウィキメディア運動のために – 追求すべき有望な戦略をより深く理解し推奨して、将来の視聴者を引き付け、維持していきます。
      • 主な成果 FA1.1：第3四半期末までに将来の観衆（Future Audiences）の実験的洞察と推奨事項を受けて、将来観衆チーム以外のチーム管轄の目標または主な成果の少なくとも1件を、翌年の年間計画草案に反映すること。
        • 2020年以来、ウィキメディア財団では将来の知識消費者および情報投稿者の世代にサービスを提供し、私たちが無償の知識の活発な運動であり続ける上でその能力に影響を及ぼすであろう外部のトレンドを追跡してきました。将来の観衆（Future Audiences）という小規模な研究開発チームは、次のことを行います。
          • 迅速かつ期限付きの実験（1会計年度あたりに目標とする実験は最低3回）を実施して、これらの傾向に対処する方法を探ること
          • 実験から得た洞察に基づいて、通常の年間計画の期間中に WMF が追求すべき実験的でない新しい投資 – つまり新製品またはプログラムでチーム全体で取り組む必要があるもの – を推奨します。
        • この主要な成果の達成とは、その目標または主要な成果が将来観衆担当以外のチームに管轄され、なおかつ将来観衆チームの推奨事項によって推進された状態で、翌会計年度の年間計画草案に少なくとも1件、記載された場合に成り立ちます。

ソーシャル・ビデオ（FA2）

  • 目的：（25歳未満の）若者はウィキペディアのコンテンツを学んだり関わったりすると、いつも時間を注いでいるお好に入りのオンライン・プラットフォームでそれを共有するのを好んでいます。 協議する
    • 客観的な背景：今年度、将来の観衆（Future Audiences）を対象に短編動画を用いた実験をしたところ、これらプラットフォームなら大勢の若年層観衆に訴求できるという結果と、その反面、ブランド健全度データ（Brand Health data）を調べると、Z 世代観衆の間でウィキペディアの認知度と親近感が低下し続け、それに対抗しようとしても現在の投資ではちっとも足りない点が示唆されます。
    • この対象世代に効果的にアプローチして関与するには、さまざまな戦術の取り組みが必要で、関与を大幅に強化する必要がある分野とは、有料マーケティングやインフルエンサーに対するマーケティング、クリエイティブな感覚を活用したキャンペーン、世の中のトレンドに機敏に反応しつつ、これらチャネルで実験レベルを向上させることなどを考えています。
    • 私たちが直面している課題の克服にはより大きな投資が必要になると予想しており、具体的には広報連絡（コミュニケーション）とマーケティングの取り組みを介してエンゲージメントを増やすこと、なおかつ部門間の協働を促してウィキペディアのブランドとコンテンツの存在感をこれらプラットフォーム上で高めたり新しい製品と体験を生み出すことなどが当てはまります。
      • 主な成果 FA2.1：上半期末（H1）までに、所有するすべてのチャンネルで短編動画コンテンツの視聴回数950万回を達成します。
        • 今年、私たちは TikTok、Instagram、YouTube に置いた @Wikipediaチャンネルからショート動画を公開後3か月以内に、視聴約100万回を達成しました。次の会計年度の始めまでに自前のチャンネルのフォロワー数が増え、効果的で関与したくなるコンテンツをもっと深く洞察して、さらに多くの視聴者にリーチできると期待しています。
        • 今年前半は野心的な目標を設定し、より大きな影響実現を目指したり、新しい戦略／プロセスを作って作業を促進させ、その目標達成のために追加リソースを提唱できるようになることを期待されています。
      • 主な成果 FA2.2：2025/26予算年度末（2026年6月）までに、オフ・プラットフォームのTikTokフォロワー数を中層（フォロワー数10万–25万）からマクロ層（フォロワー数25万–100万）に拡張します。
        • 今年上半期はTikTok フォロワー数の中層（10万–25万）を目指してきましたが、私たちの目標は2025/26予算年度末（2026年6月）までにマクロ層（フォロワー数25万–100万）に到達することです。これら3階層—少数層、中層、マクロ層—とは業界標準ベンチマークであり、観衆の規模とリーチ（普及）を表します。この目標を達成しようとZ世代のフォロワーをより効果的に獲得するようにコンテンツ戦略を洗練させ、コミュニティ管理を通じて全体的な可視性を高めていきます。下半期の戦術において、上半期の業績は指針となり、成長の加速と、このマイルストーン達成を調整します。
      • 主な成果 FA2.3：将来観衆の新しい学習／メディア消費の方法を対象とする製品をプラットフォーム外部で立ち上げ、製品ブランディングおよびマーケティングの共同キャンペーンを介して市場に投入します。
        • 通常、将来の観衆チームが取り組む実験とは最小限の／オーガニックな（organic）マーケティングを土台にした小規模なものです。今年はプラットフォームの外部で若い視聴者をターゲットにして、規模がもう少し大きな新製品 + マーケティングのキャンペーンに時間を確保したいと望んでいます。

製品と技術サポート（PES）

製品と技術サポート（PES1）

  • 目標：WMF製品・技術チームは手順の改善により的確さを増して、私たちの文化に前向きな変化が促されます。 協議する
    • 目標の文脈：この目標は、ウィキメディア財団がより速く、より円滑に、より優れた業務をこなすことです。私たちの仕事のやり方全般に関わります。つまり業務の過程において摩擦や障害（効率の悪さやエラー）を減らし、影響をより早く及ぼすことを意味します。この目標はまた、部門や組織全体が採用できる業務の進め方がいくつからあるなら、それを学ぶことも対象とします。
      • 主な成果 PES1.1：利害関係者チームが情報に基づいた意思決定を行えるように、どの製作サービスの SLO を定義するか信頼性関連作業の優先順位付けに基づいて6件を選び、SLO 定義とその使用法について私たちが得た学びを最大化して盛り込むこと。
        • サービス・レベル目標（SLO＝Service Level Objective）とは、サービス・レベル（信頼性／パフォーマンス）について利害関係者チーム間でかわした合意であり、それぞれのチームは協力してこれを満たします（超過は大幅にならないよう配慮）。たとえば開発チームが信頼性やパフォーマンスの作業を優先または非優先にすべき時期や、問題の構成要素の特定に役立ちます。それぞれのチームで注意する必要があるのは、緊急を要するもの（アラート／事案対応／重大なバグ）とそうでないものの識別です。その目標は機能間（functions）の摩擦軽減にあり、ターゲットの交渉や、優先順位付けを明確に共有し通知することにあります。
      • 主な成果 PES1.2：コミュニティが発する信号（要望リストを含む）はウィキメディア財団に影響を及ぼし、製品のワークストリームを第3四半期（Q3）- 第4四半期（Q4）に少なくとも5件、優先させます。
        • 私たちの目標は、コミュニティの要望に基づいてチームが証拠に基づく作業を優先したときにそれを特定し、称賛することにあります。
        • 仮説2件を立てており、どちらも要望リストに特化しています。これらの目的は信頼の向上、プロセスの効率化、ボランティアの皆さんと職員との参加促進に置いています。仮説はもう1つあり、その実験では「井戸端」などから十分な量の有益な信号を得ているかどうか、そしてシグナルの収集能力を AI は支援できるかどうか、検証するものです。
      • 主な成果 PES1.3：初期段階の部門横断的な実験2件から、外部の観衆として消費者や寄付者、投稿者の検証を受け、財団の年次計画に組み込むこと。
        • この作業は、実験と実験プロセスを作成して組織全体に導入することを見越しています。
        • 財団は、検証済みの初期段階の実験2件を年間計画に組み込み、部門間の実験文化を強化します。

この取り組みは、製品技術部門（Product & Technology）の機能チームを超えて共同作業を促し、組織内の他部門と組む（すなわちコミュニケーション部門やアドバンスメント部門などと）さらなる革新を奨励します。テスト前の新しいアイデアを植え付け、実験のプロセス合理化により、複数チームの生産性を高め、影響を拡大します。成功かどうかは、部門間の実験を年ごとに2件成功させること、それらを将来の OKR 作業に融合させて、実験手法の採用を増やしたかどうかで見極めます。成果の例を挙げるなら新人編集者の成長と生産性を高める新しいプロトタイプであり、実験的な機能で読者や寄付者とウィキペディアとのつながりを深めるものまで含まれます。特定の機会の一例には、手探りで規模も小さな機能同士を結び付けたウィキペディア発足25周年の企画がありました。

      • 主な成果 PES1.4：第4四半期末までに、製品評価チーム（P&T）群の Codex 採用は10%増になると見込まれます。
        • Codex は標準化 UI ライブラリとして、カスタム UI コンポーネントの作成に伴う保守負担、さらに製品UIの実装に要する時間を大幅に削減します。Codexが備える共有語彙は設計と実装を語る上でも利用でき、これにより設計とエンジニアリングの効率が向上します。
        • Codexは採用が増加しない、あるいは採用が普及しない場合は有用性を失うものでおり、現在、ツールが一部のユースケースに対応できないせいで、一部の場所で採用できず広い普及ができていません。さらに目立つ周知や広告や認知度も必要になるかもしれません。この作業が優先事項である理由とは、複数チームではCodexこそなんの抵抗もなく採用できるべきなのに、現在、全てのチームが導入を阻止する障壁を把握して言語化できたわけではありません。
        • We're anticipating that this will mean:
          • Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
          • 改善 - 例：Codex PHP 1.0 がサーバーサイドの採用をブロック解除する点は既知。
          • Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
        • The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
      • 主な成果 PES1.5：サービスSLO類の20%は、第4四半期末までに波及効果のある成果をあげるはず。
        • Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
          • We have 19 SLOs currently.
          • We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
          • データには複数サイクルを望む立場から、1サイクルはそれぞれの四半期として時間枠（タイムボックス）は第4四半期で終わります。そうすることでツールの補強やパイロットのSRE警告などの強化に取り組む余地も生まれます。
        • Success looks like:
          • Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
          • We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
          • Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
          • 重要：SLO群のうち波及効果のある決断を伴わないものの 80% は、そもそもサービスとはほとんどの場合に失敗するべきものではないという観点から、担当チームにとって失敗状態ではありません。
      • 主な成果 PES1.6：リスク分析フレームワークに依拠すると、オーナー未定だが重要なサービスの20%は、第4四半期末までにコミットするオーナーが決まるはず。
        • Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
          • We estimate there are ~20 critical services without owners.
          • We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
          • We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
      • 主な成果 PES1.7：第４四半期末までに、第3・第四半期中に受けた技術要望のうちシップした率を5%改善すること。
        • We calculated that there have been 76 Wishes submitted since Q1 this FY, and 2 have been completed, for a rate of ~2.6%.
        • Commtech can, on average, complete a Wish per quarter (the time varies by size, hence the average).
        • If we assume that over the next 6 months we'll get a similar number of new Wishes, then we can do ~2 more without any other teams contributing. Since the whole point is more teams picking up Wishes, 5% total is roughly 2 more wishes on top of the baseline of 2, for a total of 4 by the end of June. One wish per P&T team would be ~3-4 teams depending on Commtech's contribution. In short, we want to double our Wish completion rate over the next 6 months.
        • Success:
          • Diversity of contribution: we want Wishes to be completed by several teams, not just one. We can count contractor support as one "team." We need to engage teams beyond ad-hoc requests; this is about operationalizing their commitment and delivery.
          • Diversity of Wish: we want a variety of Wishes, including service area, type (bug, feature, etc.), and size.

仮説

第1四半期（Q1）

WMF の年次計画における第1四半期（Q1）とは、7月-9月にあたります。

ウィキ体験の仮説（WE＝Wiki Experiences）

[ WE の主な成果 ]

議論

仮説の短縮名 Q1 本文 詳細と議論
WE1.1.1 編集初学者が外部サイトから文字列を貼り付ける加筆をしようとしていると仮定して、その内容は自身が書いたものかどうか当人に確める場合、その新人ボランティアが新しく公開したコンテンツ編集のうち、WP:COPYVIO（著作権違反方針プラス関連の方針）を根拠にした差し戻しの割合は 10% 以上減少すると見込まれます。
WE1.1.2 おすすめ編集「語調（tone）の改善」の初期ベータ版を提供する場合、このおすすめ編集の新しい形式は新規投稿者による建設的な編集投稿を増やしつつ巡回担当者や評価者（レビュアー）の仲裁（moderation）の負担は増やさずに済む、有意義な方法であるかどうか知ることができます。
WE1.1.3 経験の長い貢献者を対象に、ビジュアル編集機能（モバイル版とデスクトップ版）内で「おすすめモード」を新規ベータ機能として導入しておすすめ編集を3件以上新たに含めると、あらかじめ比較実験を通して – もしあるとすれば – どのような調整が必要かを把握してから、新規（または経験の浅い）ボランティアの体験を評価できると見込まれます。
WE1.1.4 英語版ウィキペディア（en.wiki）で比較実験を通して出典チェック機能（Reference Check）を導入した場合、新規（または経験の浅い）ボランティアが保存する建設的な編集の増加率は10%以上に達すると見込まれ、またこの機能をより広く普及させる上で、巡回担当者やモデレータから十分な支持が得られるかどうか判断できるはずです。
WE1.1.5 新規利用者を対象にした設計プロトタイプを用いて進捗システムをテストできるとすると、やる気を最も高めるにはどのようなマイルストーンやガイダンス、承認が最善と認められるか特定し、これら洞察を活用して将来のパイロット版ウィキ実験の設計最終案を決めることができるはずです。
WE1.1.6 モバイルウェブ編集における主要な技術や社会や行動の障壁や有効な要因を利用者調査とデータ分析をにより精査すると、知識の重要な格差を埋めるために実行可能な洞察を少なくとも3件生成すること、さらに2025/26予算年度の第2半期およびそれ以降に優先するべき製品投資に確信を持つ能力強化ができるはずです。
WE1.2.1 各ウィキ上で共同作業の貢献データを表示する概念を実証できれば、少なくとも貢献者30人からフィードバックを集めることができ、その回答者の70%から、この機能は有用で共同作業の成長促進に役立つというシェアを受けられるはずです。
WE1.3.1 これまでの調査と設計で特定されたニーズを活用し、モデレータ用モジュールの初期モックアップから最も影響力のある上位 X 件を共有すれば、モデレーション操作用のホームページをモデレータの皆さんと協働して調整できるはずです。
WE1.3.2 新規利用者ホームページの変更にあたり、モデレータ用モジュールを条件付きでレンダリングすれば、モデレータ向けホームページ使用の適用性を証明できるはずです。
WE1.4.1 T396489（Phabricatorチケット）で指摘された複数の改善を実施すれば、大規模ウィキにおいて最近の変更（recentchanges）に関するクエリ遅延は X %低減できるはずです。これを受けてモデレータ用ツールは、データベースのパフォーマンスを特に意識せずとも、ホームページモジュールを当該のウィキに展開できるはずです。 T400696
WE2.1.1 小規模ウィキでアクセス数が多いウィキペディアに一斉通知バナーを載せ当該地域の母語話者を対象におすすめ編集（SuggestedEdits）その他の Growth 機能への参加を呼びかけた場合、このアプローチが新たな母語話者の獲得につながる可能性とともに対象者が重要なコンテンツの改善にこれら編集ツールを使ってくれるかどうか評価できるはずです。
WE2.1.2 新規編集者を対象にカスタマイズした翻訳の提案を開発して公開すれば、現在のアプローチと比較してこのアプローチがもたらす翻訳結果のほうがより適切いかどうかテストできるはずです。

これは記事が削除される可能性が高い新人編集者、その人たちが直面しがちな既知の課題に対処するものです。扱いやすいコンテンツの翻訳に誘導すると、翻訳プロセスの複雑さを抑えてもっと分かりやすく紹介しようと目指しています。候補となる記事やその節が優れていると、書式や全体の長さの面は一見するとそれほど複雑でもないように思えるかもしれません。

WE2.1.3 I記事やセクションを新しく作る際の（動機、問題点、新アイデアを盛り込んだ改善版サポートに対する反応など）編集者体験を学ぶと、明らかになった利用者のニーズと行動から実用的な洞察と戦略を導き出し、記事作成体験の向上に役立つ製品や設計、技術に活用できるはずです。
WE2.1.4 参加型ワークショップまたはインタビューを通じて、中規模ウィキペディア3件がどのように知識格差と重要性に取り組んでいるかを調査すると、各コミュニティに関連する「重要な知識」の実用的な定義や枠組みの概念を明らかにできるはずです。
WE2.2.1 Parsoid の展開を前例として、ほとんどのウィクショナリーと一部のトラフィックの少ないウィキペディアにウィキファンクションズ（ウィキ函数）を統合した場合、必要なテストを実施してから大規模なウィキへ確実に展開にできるはずです。
WE2.2.2 HTML テーブルや書式、リンクをウィキファンクションズ（Wikifunctions）で出力できるようにすれば、活用表を表示する特定の関数を介して、ウィクショナリーに単純な変換を超えた新たな知識を生成できると実証できるはずです。
WE2.2.3 ウィキデータ・エンティティ埋め込み関数の呼び出し対応を追加すれば、同エンティティを利用して包摂的な文章を生成する関数が200 以上あらたに有効になり、関数はウィキメディアのプロジェクト群でもっと簡単に利用できるようになるはずです。
WE2.2.4 アーキテクチャ計画を立てて、抽象コンテンツがどこに保存され、ウィキペディアとどのように連携するか示すと、抽象ウィキペディアのプラットフォームの実装によって高品質な百科事典コンテンツの提供を強化する準備がさらに整うはずです。
WE2.2.5 抽象コンテンツ（Abstract Content,）に必要な典拠という製品ニーズを製品技術チーム全体で定義し共有すると、全ウィキへの導入を成功させる上で不可欠な案件として、ウィキメディアの横断的な取り組みを推進し、抽象コンテンツに付加される履歴情報を提供できるはずです。
WE2.2.6 バックエンド内部の要望申請の形式をより簡潔化して表現力豊かにすると、システムの安定性を高め、より広範な展開に対応できるはずです。
WE2.2.7 ウィキファンクションズとウィキデータの呼び出しを用いて自然言語スニペットを生成するプロトタイプのフラグメント（fragments）を提供すれば、プロジェクトの準備が整ったと示し、さらにまた AI の学習活用に対応可能になり、関数について人間はあまり深く考える必要がなくなるはずです。
WE2.2.8 ウィキデータからインポートしたステートメントに修飾子を付与すれば、多面的な（主語／述語／値以上の表現を必要とする）事実を生成できるようになるはずです。これには、ウィキデータに収載した百科事典コンテンツのおよそ 50% が含まれます。
WE2.2.9 取得したウィキデータ・エンティティをキャッシュできるようにすれば、ウィキデータのコンテンツ基盤の機能は平均実行時間が少なくとも 50% 短縮され、タイムアウトや利用者の不満を軽減するはずです。
WE2.2.10 ウィキファンクションズ UIに個別のウィキデータ語彙素センス・コンポーネント（構成要素）を提供すれば、貢献者はプラットフォームおよび／またはウィキファンクションズを離れなくても、関連のある語彙素を識別して選択できるようになり—文脈の切り替えが減り、言語関連の函数をより迅速かつ確実に作成できるようになるはずです。
WE2.2.11 ダバニ語コミュニティがウィキファンクションズをどのようにウィキペディアに統合したかユーザビリティ（使いやすさ）調査の結果を踏まえると、テストを受けた編集者が記事に関数を追加したときに遭遇した重大な使いにくさの問題は減少あるいは全く発生しないとわかるはずです。
WE3.1.1 iOSアプリで改良版タブ・ブラウジング機能をA/Bテストすると、このブラウジング方式の利用者は複数日の利用率が5%増加すると分かるはずです。
WE3.1.3 新しい方法を利用者に提供して記事ページ内で関連の画像や動画コンテンツを閲覧できるようにすると、この機能を利用した利用者のクリックスルー率は少なくとも3%向上するとわかるはずです。
WE3.1.4 ウィキ上の知識ネットワークを巡回する複数のコンセプトを読者に提示すると、今後の開発におけるコンセプト優先順位一覧が得られるはずです。
WE3.1.5 ウェブ読者を対象に、その人自身の言語版のウィキペディアでは利用できないコンテンツの機械翻訳版を表示するオプションを提供した場合、ページ関与（インタラクション）の3%増を測定したら、閲覧の活動が増加したかどうか、ローカル言語版ウィキに引き寄せられた読者が、ローカル言語版の編集活動を増やす可能性があるかどうか把握できるはずです。

これは管理されたA/Bテスト環境として提供し、期間は6ヵ月以内、事前の同意を得たウィキペディア13件で、すでにウィキペディア編集者に提供済みの公開の機械翻訳を使う見込みです。

WE3.2.1 募金活動と連携すると、利用者テストを介して測定されたように、iOS版「1年のまとめ」（Year in Review）には寄付者対象にもっとパーソナライズして統合してあり魅力的なスライドを開発できるはずです。これを受けて第2四半期には仮説を立て、改善版「1年のまとめ」は2024年のそれと比較して寄付額が5%増加すると見込まれます。
WE3.2.2 ウィキペディアの使用状況に応じて、キャンペーン対象外のマーケットの Android アプリ読者に（金額と頻度を）カスタマイズ可能な寄付のリマインダ（備忘通知）を設定するよう促すと、当該のマーケットでアプリ・メニュー経由の寄付が 5% 増えると予測されます。
WE3.2.3 非ログイン利用者を対象にA/Bテストを実施し、モバイル版とデスクトップ版の両方で寄付のエントリーポイントをわずかに変更した場合、処理パスを経由した寄付数は対照群（コントロール）と比べて2%増えると観察できるはずです。
WE3.3.1 2024年にiOS利用者から寄せられた要望で、2025年の「1年のまとめ」（Year-in-Review）に低～中程度の労力を要する個人化要素を追加すると、満足度を測定すると使いやすさテストまたはベータテストで昨年比3%増加するとわかるはずです。
WE3.3.2 Android 版に既存の「編集」タブは、閲覧と編集以外の参加に関するインサイトを含め個人化した活動ハブに拡張した場合、タブの複数日にわたる関与（エンゲージメント）は元のバージョンと比べると 5% 増加すると見込まれます。
WE3.3.3 Android アプリでアカウント所有者対象にロック解除可能なアバターを少なくとも1件導入すると — アバターの獲得は保存した記事の件数がしきい値に達したなど読者にとって有意義な行動が条件 — ログイン利用者は複数日にわたって関連の操作に繰り返し関与する回数が 10% 増えると見込まれます。
WE3.3.4 記事を非公開の閲覧リストに保存する機能をログイン読者に提供すれば、サイトにおける関与（エンゲージメント）が向上して同機能を利用する読者の内部参照トラフィックは5%増が期待され、利用者全体でも統計上の有意な増加が見られるはずです。
WE3.3.5 ウェブ読者を対象に利用者調査を実施し、ウィキペディアからコンテンツを収集／キュレーションできる設定にした場合、2種類以上の異なる種類のコンテンツ（例えば記事、抜粋、メディア）をコレクションに保存する参加者は少なくとも10% いると予想されます。
WE3.4.1 ハイブリッドなポイント・オブ・プレゼンス（PoP/CDN）の展開に向けて取り組んだ場合、必要に応じてフル PoP とミニ PoP（物理およびクラウド）の両方を構築できるようになり、ミニ PoP のプロトタイプに将来の展開基盤を築けるはず。
WE3.6.1 非ログイン利用者の定着率に関する A/A テストを実施すると、今後の四半期に使用できる率のベースラインを確立できるはずです。
WE3.6.2 ログイン読者の定義を作成して公開すれば、この定義を KR WE 3.3 に関してどのチームでも仮説でも使えるようになるはずです。
WE3.6.3 読者のニーズの変化や、インターネット上の知識の本質の変化について、コミュニティの皆さんに議論してもらうと、読者にどのように貢献できるかという共通の焦点を築き、（マルチメディア、検索と発見、機械学習などを含む）さまざまな発想を検証すべきかどうか、またどのように検証すべきかについて協力することができるはずです。
WE3.6.4 読者がウィキペディアその他の知識プラットフォームをいつ、なぜ、どのように利用するのか、その背後にある明確な動機や行動やニーズを調査すれば、消費者戦略の策定と進化に役立つ知見が得られるはずです。
WE4.1.1 非緊急フローで最小限の実行が可能なプロトタイプを作成し、拡張権限を預かる利用者と共同で開発を進めフィードバックの反復的なループを維持すれば、このフローの拡張展開に関してこれらのグループの支持を得られるはず。 Project page
WE4.2.1 信頼できる担当者を対象にアカウント作成に関連する hCaptcha のリスクレベルを提示すれば、不正行為者の特定に必要な時間を短縮し、プラットフォーム上で作成された不正行為者アカウントの検出数が増えるはずです。この仮説の成功を測定するには、アカウントに適用されるブロック率と、hCaptcha リスクレベルとアカウントブロックの整合性の総合点検、役務者から集める定性的なフィードバックが適するはずです。
WE4.2.2 チェックユーザがフォローアップを担当する調査案を生成すれば、不正アカウントの特定にかかる時間は短縮し、不正アカウントの特定数は増えることが分かるはずです。「推奨調査」機能（Suggested investigations）が定期的に利用され、この調査により、また定性調査に寄せられたフィードバックを反映して特定アカウントに適用される緩和策が増加した時点で、それが成功していると判明するはずです。
WE4.2.3 hCaptcha アカウント作成について試行データを分析すると、アカウント作成のファネル（funnel）、hCaptcha のパズルと得点の有効性を理解できるはずで、今後のアカウント作成における hCaptcha の展開に必要なデータが得られると見込まれます。
WE4.2.4 UserInfoCard をすべてのウィキに導入すると、担当者やモデレータに力を与え不正利用アカウントをより効率的に特定して緩和策を講じることができるはずです。 Project page
WE4.2.5 調査を実施しコミュニティと協議し、さらに技術面の解決策を調査すると、ブロック理由の構造化セットは WMF の全ウィキで採用するために定義できるはずです。
WE4.2.6 データプラットフォーム上に OpenSearch 基準のクラスターを展開する機能を開発すれば、この機能を統合する製品機能技術チーム（product feature engineering）は高い自律性、回復力、他の検索ベースシステムから独立したシステムを開発できるはずです。IPoid サービスは当システムの最初で主要なテナントになると見込まれます。
WE4.2.7 パイロット試験として hCaptcha エンタプライズ（Enterprise）統合をウィキペディアの複数の本番環境に導入すれば、hCaptcha エンタプライズの不正使用対策やボット検出、使いやすさやアクセシビリティにおける有効性と価値についてデータを収集できるはずです。
WE4.3.1 新しい「エッジ・ユニーク」（Edge Uniques）cookie 対応を requestctl 、つまりSRE用の不正使用対策エッジルール・エンジンに統合すれば、 DDoS 攻撃やコンテンツ再利用に対する防御力が向上するはずです。
WE4.4.1 パイロット版から得たフィードバックに基づいて改善し全プロジェクトに仮アカウント（Temporary Accounts）を展開すれば、非登録利用者の個人特定情報（IPアドレス）は全プロジェクトにおいて保護し、その露出は（登録）利用者総数の0.1%未満に抑えることができるはずです。 Project page
WE4.4.2 ウィキメディア運動の（ウィキ・コミュニティ群やグローバル担当者を含む）利害関係者との意思疎通が明確かつタイムリーにできれば、残りのすべてのウィキに展開し、土壇場で発見された作業負荷を軽減したり導入のロールバックを回避したりできるはずです。
WE4.4.3 巡回者が各 IP アドレスを基準に仮アカウント（temporary accounts）の操作と活動を簡便に絞り込めるようにすると、仮アカウントの全ウィキ展開が成功するはずです。
WE4.4.4 IPアドレス開示アクセス方針に従い、仮アカウントの IP アドレス開示アクセスを認め、この機能をより多くの場所で利用できるようにした場合、全ウィキに仮アカウントを円滑に展開できるようになるはずです。
WE4.5.1 定性調査を実施し、生成 AI を利用した悪質な行為者による不正使用の事例（例えばスパムや嫌がらせ、長期的な不正行為者や非公開の有償編集、偽情報キャンペーンなど）を特定すると、コミュニティ・モデルに及ぶリスクの評価と、生成 AI を活用したさまざまな不正行為を軽減するアイデアを生み出すことができるはずです。
WE4.6.1 Zendesk 内でアカウント同期プロセスを自動化してパスワード・リセットに使えるようにした場合、信頼安全部（T&S）の負担を軽減し、2ファクタ認証リセットのリクエストをより多く処理できるはずです。
WE4.6.2 複数の認証要素を登録するよう利用者に推奨し支援すると、2ファクタ認証を有効にしている利用者はアカウントにアクセスできなくなる可能性が低くなるはずです。
WE4.6.3 確認済みのメールアドレスがある利用者全員、アカウントで2ファクタ認証を有効にできるようにした場合に、利用者に当該の変更を積極的に通知しないままだと、リカバリ・サポートデスクの負荷は持続可能なレベルに留まルだろうと見込まれます。
WE5.1.1 セッションが認証済みか匿名かそれぞれ異なるストレージ・バックエンドを振り当てた場合、認証ページで作成し CSRF 対策を提供する匿名セッションによって Sessionstore にかかる過負荷を防ぐと、DDoS 攻撃や大量のスクレイパーから Sessionstore を保護できるはずです。 T398814
WE5.1.2 メディアウィキのセッション・クッキーを暗号署名付きの構造化フォーマットに変更すれば、効率的で高いスケーラブル性を備えたエッジで信頼できるセッションの検証ができて、スクレイパー対策においてセッションの存在を保護の要素として活用できるはずです。 T398815
WE5.1.3 API ゲートウェイのレート制限解決策を作成するのに Kubernetes 基盤のローカル開発環境を採用した場合、少なくとも異なるレート制限サービス3件のパフォーマンスと機能を比較し、本番環境トラフィックのテストに最適なオプションはどれか決定できるはずです。 T398913
WE5.2.1 REST API サンドボックス UI を再設計して開発者の情報ニーズをより適切に満たすようになると、説明文書の明瞭さはユーザビリティ・テストで検証したように高まるはずです。
WE5.2.2 rest.php 配下の API をすべて中央ゲートウェイ経由でルーティングすれば、API の集中管理が可能な方法を解き放ち、REST API のトラフィックと使用パターンの継続的な測定ができるし、将来の意思決定や対応に役立つ洞察を得ることができるはずです。
WE5.2.3 If we implement monitoring dashboards and alarms for the MediaWiki REST API,

MediaWiki REST API に対応する監視と警告用ダッシュボードを実装すれば、特に重要な改変の際に有用な、システム動作の可視性を向上させて問題をより早く発見する方法を持続可能で有用かつ再現可能に確立できるはずです。

WE5.3.1 既存のガイドラインのいずれかを更新するかたわらで UX 帰属ガイドラインを拡張し合理化すると、ガイドライン改善版の中核セットを確立して内部テストに備えたり反復的な改良を重ねたりして、より広範な一般利用に備えることができるはずです。
WE5.3.2 サードパーティのコンテンツ再利用者とそのエンドユーザに対する資料を作成してウィキペディアの帰属を明示するメリットを示し、第1四半期末までに再利用パートナーが少なくとも1社、帰属に関する事例研究またはデモの掲載に同意してくれたら、WME4.1 および WME4.2 に対応できるはず。
WE5.4.1 Web リクエストの大部分にエッジユニーク Cookie を付与すれば、ボットや偽造リクエストの識別が容易になるはずです。d requests.
WE5.4.2 既知のクライアントを識別するスケーラブルな方法を構築すれば、発信元検証済みのボットに対して一般的なレート制限の例外を許可し、ルールを体系的に適用できるはず。
WE5.4.3 許可リスト／却下リストに基づくアプローチに従って CDN におけるテキスト申請のフィルタリングを再編成すれば、ボットに対する一般的なレート制限をより厳格に適用し、トラフィックのフィルタリングを効率化できるはずです。
WE5.4.4 統一した測定戦略を策定すれば、「インフラの責任ある利用」に関する複数年戦略の評価が可能になり、ロードマップを定義して指標の開発とレポート機能の指針とすることができます。
WE6.1.1 毎日のイメージ・ビルドをデプロイメント・サーバに再配置し特定のデプロイメント操作に起因するイメージ更新を追加すると、制約が明らかになり、より継続的な実装の実行に必要な時間のベースラインを確立できるはずです。
WE6.1.3 If we add wikifarms to a pre-merge testing environment

マージ前テスト環境にウィキファームを追加すると、開発チームは本番環境向けに複数のウィキを必要とするビルドを行う際にパッチを個別にテストできるため、本番環境前の信頼性が向上し、不具合の見逃しが減るはずです。

WE6.2.1 セルフサービス可能なタスクとともに、特定のサービスが本番環境に対応していると見なす前提条件を明確に定義し本番環境対応チェックリスト（Production Readiness Checklist）を評価して公開した場合、期待される方向性がSRE（サイト信頼性技術）と開発チームの間で一致し、運用効率とスケーラビリティが全体に向上するはずです。
WE6.2.2 開発者にとって多くの面倒なタスクを抽象化する Golang および nodejs ライブラリの作成を発表すれば、開発者は関心を示しフィードバックをくれるはずです。
WE6.2.3 チェックリスト／ワークシートを作成すれば、開発者はデータ永続性の設計評価に向けて事前に十分な準備を行うことができるはずです。
WE6.3.1 第1四半期に言語バリアント対応ウィキを除いたトラフィックの少ないウィキペディアを少なくとも70件展開できると、最終的に上位10件のウィキの展開に信頼が高まり、Parsoid 経由のページ閲覧に大きな影響を及ぼすことができるは図です。
WE6.4.1 Commons の分割リンク・テーブルを独自のクラスターに展開すると、Commons ではデータベース成長の持続可能性を保ち続ける確率が高まるはずです。 T398709
WE6.4.2 メディアウィキの技術担当チームに対して私たち（SRE）が支援の手 - 説明文書の作成、必要なインフラの準備（例えばPHPパッケージ、コンテナ・イメージなど）、ガイダンスと評価 - を差し伸べた場合、同チームは第2四半期の初めまでに、本番環境の PHP 8.3 へのアップグレードについて自信を持って取り掛かれるはずです。 T360995
WE6.4.3 高度のシステム権限を預かる利用者には SSH ログインに物理的な第 2 要素（ハードウェア・セキュリティ キー）を必須とすると、侵入されたラップトップから深刻なセキュリティ侵害を招くリスクを軽減できるはずです。
WE6.4.4 正規ドメイン経由でウィディアのウィキ・サイトのページ閲覧全体を提供してドメイン類を統合すれば、プラットフォームの複雑さをなくし、なおかつモバイルのサブドメインへのリダイレクトを廃止すると検索エンジン最適化（SEO＝Search Engine Optimization）リスクを軽減できるはずです。完了率の測定は、正規ドメインにおけるモバイルページのリダイレクトを100%から0%に減少させて得ます。 T214998
WE6.4.5 PHP 8.3 更新に関連したMediaWiki 上の問題について、MediaWiki 技術チーム（Engineering Team）が監視と修正を積極的に進めた場合、SRE チームは第2四半期開始までにブロックを解除され PHP 8.3 更新の作業進行に戻るはず。 T360995
信号&データ・サービスの仮説（SDS＝Signals & Data Services）

[ SDS の主な成果 ]

議論

仮説の短縮名 第1四半期 本文 詳細と議論
SDS1.1.1 ページ閲覧データセットにおける自動トラフィック検出ヒューリスティックの有効性を分析すると、データ品質指標を開発してそのパフォーマンスを提示し、これらのヒューリスティックにさらに投資する必要があるかどうか判断できるようになるはずです。
SDS1.2.2 XML ダンプのプロセスを現在の「Dumps 1」インフラからメディアウィキのコンテンツ・パイプラインを活用したデータ・パイプラインに移行すれば、SLO を保証し、「Dumps 1」ベースの XML エクスポートを停止できるはず。
SDS1.2.3 メディアウィキのコンテンツ履歴とイベント・プラットフォームおよび／またはイベント・ゲートの SLO をウォークスルーで確認すれば、顧客や指標、それらに依存する関係者を検証し、SLO にどんな改善点が必要か特定できるはずです。これにより週単位の配信保証における格差を明確にできるはずです。
SDS2.1.1 実験を進行中のチームと緊密に連携すると、将来的にシステムをよりセルフサービス化する方法や、同チームが直面するかもしれない概念または技術の課題を把握できるはずです。
SDS2.1.2 イベントログのデバッグを改善できれば、製品チームは実験が期待どおりにイベントデータを収集していると把握でき、実験オーナーの信頼度が向上します。
SDS2.1.3 実験プラットフォームのA/Bテスト・システム（xLab）コンポーネントと、メディアウィキの関連部分のログ記録と観測のしやすさを改善すれば、システムのパフォーマンスにベースラインを確立し、実験関連の障害に対応できるようになるはずです。
SDS2.1.4 実験のストーリーと成果を月に1回、組織全体で共有すれば（製品運用会議(※1)、設計チーム会議(※2)、チーム間発表(※3)を通じて）、実験プラットフォームの有機的な導入を促進できるはずです。（※：1＝製品運用会議。2＝設計チーム会議。3＝チーム間発表）
SDS2.1.5 利用者に対してxLabで作成された機器を使うなら、そこに含まれる属性セットにより各人のリスクカテゴリが変更されると伝える場合、機器利用者による過剰なデータ収集を抑止し、プライバシー評価に求められる属性の組み合わせを明確にできるはずです。
将来の観客の仮説（FA＝Future Audiences）

[ FA の主な成果 ]

議論

仮説の短縮名 第1四半期 本文 詳細と議論
FA1.1.1 もしも 1) メディア収集者を対象にウィキペディア限定の知識を使って各自のプラットフォームを補強する代替策として他のプラットフォーム（例えばLetterboxd、Goodreads、RateMyMusic）を提供する場合、あるいはまた 2) 左記のメディア収集者の関心をひくSNSで共有可能な素材を提供する場合、ウィキペディアの普及をプラットフォーム外で拡大できるはずです。
FA2.1.1 第1四半期（Q1）に内部で短編動画コンテンツを制作する能力を構築できれば（そのためにチーム規模を拡大し、現状の制作プロセスの効率化機会を監査および特定）、2024-25会計年度に制作したコンテンツから学んだことを活用して、2025-26会計年度の第2四半期（Q2）に制作したコンテンツは前年比で普及率が高まると想定されます。
製品と技術支援の主な仮説（PES＝Product and Engineering Support）

[ PES の主な成果 ]

議論

仮説の短縮名 第1四半期 本文 詳細と議論
PES1.1.1 Prometheus（プロメテアス）における SLI 類（サービス・レベル表示器＝Service Level Indicators）の指標定義に xLab、チャート類、ToneCheck を採用し、なおかつ Pyrra（パイリャ）にはそれらサービス・レベル・オブジェクト（SLO＝ Service Level Objectives）を組み込んだ場合、複数の複雑なシナリオでツールの限界と稀なケース（コーナーケース）を学べるし、さらにSLOテンプレートに必要な反復作業を明確にできるはず。これらは、KR計画の6つのSLO対応をより適切にするのに役立つはずです。
PES1.1.2 SLO 警告ダッシュボード2組のパイロット実験を実施した場合、サービスオーナーが各自のやるべきこと（commitments）を正確に把握できるように、適切なツールを展開することの難しさを学べるはずで、さらにまた、別のツールに移行させて固有の SLO には単一の表示のみ提供する必要があるのかどうかも判明するはずです。（前述の2組とは）片方は四半期ごとの報告用ダッシュボード（エラー予算に対応する実際のサービスレベルの同意（Service Level Agreement）を組み込み）、規模が小さめな方は（通称「rolling」という）ダイナミックなダッシュボードで日常業務と警告に対応します。
PES1.1.3 函数ウィキ・プロジェクト（Wikifunctions）で SLO（サービスレベル目標）の下書きを作る際に抽象ウィキペディア・グループ（Abstract Wikipedia group）への支援を続けた場合、複雑な機能に関する（サービスレベル・インジケータの評価指標とともに）SLO ターゲットのリストを定義する方法を学べるはずで、これらは現在、ウィキ類の記事レンダリングという重要な利用者ワークフローに組み込まれています。さらにまたSRE が提供するダッシュボードとモニターを採用したなら、関連するエラー予算をどうすれば適切に視覚化し警告できるか学べるはずです。
PES1.1.4 データ・プラットフォーム・グループ(※)をサポートするため、MediaWiki コンテンツ履歴プロジェクト(※2)のサービスレベル目標（SLO(※3)）を評価し反復作業を実施すると、サービスの所有権に対応する SLO 活用法を学べるはずで、そのためにバッチ処理とストリーム処理の両サービスの組み合わせによりデータセットの更新と維持を一括調整すれば、一貫性を保てるしダウンストリームの利用者も利用できるはずです。（"※"：1＝Data Platform group。2＝MediaWiki Content History project。3＝Service Level Objectives。）
PES1.2.1 要望リストに対象をしぼった改善策を3件実施した場合、要望リストに取り組む個別参加者を 30% 増やせるできるはず
PES1.2.2 要望の受け取りから72時間以内にメンテナー（例：製品マネージャー）を割り当てるために新しい要望とメンテナー・テーブルを相互に照合し、「メンテナー・カテゴリ」を最も関連性の高い製品チームまたは個人に割り当てた場合、評価（却下や明確化、メンテナンス対応漏れのサービスにフラグを立てるなどを含む）を済ませて、メンテナー（例：製品マネージャー）は要望の評価と対応を10日以内に実施できるはずです。
PES1.2.3 コミュニティ信号を全体として特定するパイロット作業を行った場合、情報に基づいた優先順位付けの取り組みに、コミュニティのボランティアの声をさらに多く取り入れることができるはずです。
PES1.2.4 要望リストおよびコミュニティ信号を四半期単位 で評価するパイロット実験に第1四半期（Q1）に3チームで取り組んだ場合、 製品部長（Product Managers）の関与を得て、四半期および年次計画プロセスにコミュニティ信号を統合できるはずです。
PES1.3.1 第1四半期末（Q1）までに当製品チームと広報連絡部門（Communications department）が機能計画ミーティングを3回開き、通知、制作のニーズ（creative needs）、取り組み WP25 のキャンペーン日程表などを固めた場合、キャンペーン実験3件（25YiR、イースターエッグ、WikiRun）すべての制作概要（creative briefs）を確定できるはずです。
PES1.3.2 設計部門と機能技術部門の代表者が構成する運営委員会を設立すれば、Codex への貢献に関してベースライン指標を定義できるはずです：認知度、利用状況、貢献の質、量。これらベースライン指標に基づく評価から洞察を得ると、Codex 貢献者基盤の成長と多様化を促すロードマップ策定の役に立つはずです。

第2四半期（Q2）

ウィキメディア財団における年次計画の第2四半期（Q2）とは、10月12月時期に当たります。

ウィキ体験の仮説（WE＝Wiki Experiences）

[ WE 主な成果 ]

議論

仮説の短縮名 第2四半期（Q2）本文 詳細と議論
WE1.1.1 ペーストチェックA/Bテスト開始から2週間超が経過したら事前に決定した先行指標セットを分析した場合、機能の影響評価前にエンドツーエンドの体験の調整または調査する必要がある側面 – 存在する場合 – はどこか特定できるはずです。
WE1.1.4 英語版ウィキペディア（en.wiki）で比較実験を通して出典チェック機能（Reference Check）を導入した場合、新規（または経験の浅い）ボランティアが保存する建設的な編集の増加率は4%以上に達すると見込まれ、またこの機能をより広く普及させる上で、巡回担当者やモデレータから十分な支持が得られるかどうか判断できるはずです。
WE1.1.7 ペーストチェックA/Bテスト開始から2週間超が経過後に事前に決定した先行指標セットを分析した場合、機能の影響評価前にエンドツーエンドの体験の調整または調査する必要がある側面 – が存在する場合 – はどこか特定できるはずです。
WE1.1.8 公開済みの記事に語調チェック（Tone Check）モデルを適用した場合、（それぞれスコア0.8以上の）語調の問題検出が1万件超に到達するかどうか判断でき、記事の語調を改善する編集者の役に立つよう高品質（精度 ≥ 70%）の提案をプールする要件が満たせます。
WE1.1.10 ウィキペディアの英語版（en.wiki）と同フランス語版（fr.wiki）で巡回／仲裁のワークフロー自動化をめざし、AbuseFilter（および他のガジェット／スクリプト／テンプレート／編集通知）を作成する経験豊富なボランティア10人前後にインタビューした場合、コミュニティがなんのために編集チェックを作成するか3つ以上のパターン／ニーズが特定できれば、価値の提案作りに役立つはずです。
WE1.1.11 新規利用者で成功した500人以上[i]にアンケートを実施し、成功した新規利用者のより広範な集団を代表する高品質なデータを取得した場合、実用的な動作位を4件以上特定して、活動初期体験（オンボーディング）のどの側面を優先的に改善すべきか判断するために活用できます。
WE1.1.12 新言語版10件でトーンチェックの導入検討をするとして、それぞれのボランティア3人以上がサンプル編集を各人30件超、評価できるようにした場合、ボランティアがモデルの予測に同意する割合を把握し、トーンチェック導入をめぐり新ウィキのどこに働きかけるか決定できるはずです。
WE1.1.13 ウィキペディア英語版で「リンクを追加」機能を新規ボランティアの100%に拡張した場合、新規ボランティア維持率向上とその人たちによる建設的な編集が活性化して、その人たちによる建設的な編集の伸び率は4%超になると予想されます。
WE1.2.3 中小規模ウィキでは、イベント登録機能の使用要件で必須とされるイベント主催者（Event Organizer）権限の取得を撤廃した場合、当会計年度末までに中小規模ウィキにおけるイベント作成が少なくともX件超 [*] に達すると予想されます。
  • ＝具体的な基準値／目標値の算出は保留中。
WE1.2.4 共同貢献の Collaborative Contributions MVP に最低2件の改善を反復開発すると、イベント登録（Event Registration）を介して作成される共同作業がもっと増えるはずです。
WE1.2.5 ウィキメディア・コモンズにおけるイベント登録の導入戦略は、第2四半期初期に策定した場合、地域主催者5人にこの機能を利用してもらい、最低1件の大規模キャンペーンの主催者を対象にテストを実施できるはずです。
WE1.3.3 仲裁ダッシュボードを（moderator dashboard）浮上させるため、より新しい編集者を対象に実験を始める場合、 そのダッシュボードを開いた寄稿者の10％には2週続けてそれをくりかえしてもらいます。
WE1.4.1 T396489で定義した改善を実施した場合、大規模ウィキにおける最近の更新クエリ（recentchanges）の遅延を少なくとも30%削減できると見込まれ、これによりコミュニティ技術チーム（Community Tech）がウォッチリストラベルを展開しても、recentchangesデータベースに過負荷をかけずに済むはずです。
WE1.4.3 最近の変更とウォッチリストを計測すると、利用者がページ類をクリックする頻度のベースラインを定義できると見込まれます。
WE1.5.1 貢献者指標7件を調査するダッシュボードを実装し、dbt を用いて1件以上の指標計算を標準化した場合、貢献者製品チームは指標の洞察をセルフサービスで利用し、指標計算ロジック保存の標準を構築できるようになります。
WE1.5.2 第2四半期中に仲裁者（Moderator）の定義に含める仲裁活動を特定すると、運動洞察チーム（Movement Insights）は第3／第4四半期に月間活発仲裁者（Monthly Active Moderators）の指標を構築できます。
WE2.1.3 編集者が新しい記事や節を作成する際に経験することを私たちが学べば（動機、問題点、より良いサポート方法に関する新発想に対する反応など）、利用者のニーズと行動を明らかにし、実用的な洞察と戦略の提供により、記事作成体験の改善に関する情報を製品や設計、技術部門に提供できます。
WE2.2.12 Parsoid が有効なウィキに関数ウィキ（Wikifunctions）を展開した場合、展開範囲が拡大してもシステムのパフォーマンスと使いやすさが維持されるかどうか、継続的にテストできるようになるはずです。
WE2.2.13 ウィクショナリーのコミュニティに対して活用表機能が利用可能だと周知した場合、機能利用の状況に関して貴重なフィードバックを得たり、利用者のペルソナを洞察でき、将来の展開に活用できます。
WE2.2.14 ウィキデータを基礎情報ボックス（infobox）に使おうとするコミュニティのデータボックス作業（Databox）に着目して、関数ウィキが役に立つかどうか調査すると、基礎情報ボックスにウィキ関数を適用する第1回の実験を特定できるはずです。
WE2.2.15 関数ウィキのエラーメッセージを作成したり翻訳できるとコミュニティが気づくようにした場合、便利なエラー・メッセージの件数が増えるはず。
WE2.2.16 既存の意味論的機能を コミュニティに実演してみせた場合、文法的機能は50％増になるはず。
WE2.2.17 関数ウィキからウィキデータの, 声明を表示する固有のコンポーネントを提供した場合、ウィキデータから読み込んだデータをもっと明確に理解できて、あまり圧倒されずに済むはず。
WE2.2.18 メモリ消費が1桁増える臨時のピークを予防できた場合、オーケストレータによるウィキデータのオブジェクト処理が向上し、抽象ウィキペディアに役立つプラットフォームとしてウィキ関数のユーティリティを支持できるはず。
WE2.2.19 特定の関数呼び出しを利用者が — その人自身のインプットも含めて — 共有できるようにした場合、寄稿者は特定の関数について挙動の再現、検証と議論がより簡単にできるようになり、その結果、バグ修正の高速化、テストのワークフロー改善に加え、関数ウィキ（Wikifunctions）コミュニティ全域で問題解決の協働が支持されるはずです。
WE2.3.1 新しいウィキ作成の意向を確定してコミュニティで名前を決めておくと、この新しいウィキ作成を関係者とより広く共有し、製品名を変更したいという希望に備えることもできます。
WE2.3.2 抽象ウィキペディアのプロトタイプ用に MVP（実用最小限の製品）を定義し、バックエンドと NLG 機能のテストが反復設計できるよう最小限の経験を含ませた場合、第3四半期に計画してライブのプロトタイプをリリースできるはず。
WE2.3.3 コミュニティと相談を始めて抽象ウィキ（Abstract wiki）の利用者体験に用いると仮定したデザインを探索すると、第3四半期に作業の進行ができるはずです。
WE2.4.1 WMDE（ウィキメディア・ドイツ協会）ならびに WMF の各チームからウィキデータと WDQS の使用事例を集めた場合、インフラ改善に役立つ製品要件を定義できるはず。
WE2.4.2 ウィキデータとWDQSの既存のサービスレベル目標（SLO※1）と主要業績評価指標（KPI※2）を統合したレポートビューを作成した場合、ウィキデータの重要なユースケースを支える技術インフラの改善に向けて成功基準を明確にし追跡できるはず。

（"※"：1＝service level objectives。2＝key performance indicators。）

WE2.4.3 当四半期中に Blazegraph（ブレイズグラフ）のストア代替のベンチマークと評価に、製品化が現実的な基準を採用して済ませた場合、データに基づく移行を決定し、ロードマップにタイムラインとリソース要件を含めて具体的に明確にできるはず。
WE3.1.1 タブ式ブラウジング機能の改善版を A/B テストにかけた場合、タブ式利用者が複数日にわたる使用は 5% 増になると予測されます。
WE3.1.3 記事のページ内で関連性のある画像コンテンツを見て回る新しい方法を読者に提供した場合、それを一連のウィキ全体で非ログイン利用者のサブセットとのA/Bテストによりテストした場合、この機能を示した利用者層のクリックスルー率は3%以上を示すはず。
WE3.1.4 ウィキの知識ネットワークを横断する複数の概念を読者に示した場合、開発推進に役立つ概念の一覧を優先順位付けして入手できるはず。
WE3.1.5 ウェブ読者にオプションを提供し、利用者の言語版ウィキペディアにはないコンテンツを機械翻訳で処理して表示した場合、閲覧活動の伸びはページ関与（インタラクション）3%増という測定値として把握できると見込まれ、読者をローカルの言語版ウィキに誘導して、そちらの編集活動の増加につながる可能性があります。具体的には期間は6ヵ月未満、事前の同意を得た上でウィキペディア13言語版で対照A/Bテスト環境を提供して、ウィキペディア編集者が既に利用している公開の機械翻訳サービスを採用して実施します。
WE3.1.6 インタフェースのデモ版として配信し、取り組み方を現行と新しい実験的なものと対照し、意味論検索と記事内Q&Aのプロトタイプを作成した場合、読者チームは定性評価により、それぞれのアプローチがさまざまな利用者ジャーニーでどのように機能するか把握し、ギャップやさらなる反復開発の機会を明らかにできるはず。
WE3.1.7 読者の期待とニーズのギャップを埋めるには既存の調査を評価して、ウィキペディアの検索ツールやナビゲーション・ツールを読者がどのように利用し、また外部検索をどのように使ってウィキペディアで知識を見つけようとするか調べると、実用的な推奨事項と調査結果を3つ以上、読者チームに提供でき、検索および発見の MVP の範囲を定めるのに役立つはず。
WE3.1.8 意味論検索プロトタイプ（自然言語検索とよくある質問Q&A）を2件、外部の参加者とともに評価すると、利用者は改善版検索ツールの価値を感じるかどうか把握でき、検索および発見 MVP をどう進めるか推奨事項を読者チームに提供できるはず。
WE3.1.9 ウィキペディアの一般読者10～20人を対象に定性調査を行い、意味論検索を使ってコンテンツを発見する高忠実度（high-fidelity）の設計コンセプトを示した場合、その機能に対する肯定的な反応を得て、さらに人間が書いた短い抜粋を検索クエリに利用する検索・発見MVPの開発推進に必要な確信を得られるはず。
WE3.1.10 気軽に利用する読者10人に対して管理していない利用者調査として、画像閲覧の新しい体験のライブなプロトタイプを提供した場合、この機能の将来の反復開発において UX 改善を1件以上、明らかにできるはず。
WE3.1.11 検索におけるキーワード対照率を緩和した場合、自然言語クエリの対応が向上して製品（チーム）側が当機能を評価できるようになり、作業設計と優先順位付け、提供方法は意味論的検索空間（Semantic Search）に組み込みができるはず。
WE3.1.14 If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3) T409163
WE3.2.5 Android に「1年のまとめ」機能（Year in Review）を導入して利用者への影響を強調したり、寄付者へのメッセージ機能も統合した場合、新たな寄付行動を促し — アプリメニュー経由は対2024年比で 5% 増になると見込まれます。
WE3.2.6 If we make the donor slides in the iOS Year in Review,

iOS 版の「1年のまとめ」（Year in Review）に寄付者向けスライド集を統合してもっとパーソナル化した場合、寄付額は対2024年比で5%増を見込めるはず。

WE3.3.3 Android アプリでアカウント所有者対象にロック解除可能なアバターを少なくとも1件導入すると — アバターの獲得は保存した記事の件数がしきい値に達したなど読者にとって有意義な行動が条件 — ログイン利用者は複数日にわたって関連の操作に繰り返し関与する回数が 10% 増えると見込まれます。
WE3.3.4 ログインした読者は記事を非公開の読書リストに保存できるようになったらサイトへの関与（エンゲージメント）が増えると予想され、増加率はその機能を使った読者の内部参照トラフィック（referral traffic）は5%増、また利用者全体では統計上、有意な増加が見られるはずです。
WE3.3.6 スケーラビリティと可用性の合意要件を満たすサービスを用いて、記事主題の推論データを利用できるようにし、さらに必要データのバックフィル（backfills）も実施した場合、当該のデータに依拠していて将来の読者体験パーソナル化を支えるために必要な技術基盤を確立できるはず。
WE3.3.7 データ・プラットフォームの処理機能を活用してカスタム化した編集者指標と影響データを集約し、そのデータは定義済み SLO を備えた適切なサービスを介して提供した場合、WE3.3.1 1年のまとめ（Year in Review）とWE3.3.2 活動タブ（Activity Tab）の今後の繰り返し開発を強化するはず。
WE3.3.9 もしも「1年のまとめ」（Year in Review）を Android に導入して A/B テストを実施、関与した利用者には特製の読書リスト保存という報酬を用意した場合、特典を受けなかった人たちと比較すると、受けた読者はアプリ全体の保持率が 1% 増になると見込まれます。
WE3.3.10 A/B テストを実施して年のまとめの個人化された読書洞察の表示にアカウントを求めた利用者と求めなかった場合と対照すると、アカウントを要求した利用者全体で定着率は1%増になると見込まれます。
WE3.3.11 iOS にある「活動」（Activity）タブの改良版を A/B テストにかけて、閲覧・編集その他の参加活動に着目した場合、ログイン読者がそのタブを複数日にわたって訪問する率は、試用版と比べると5％増になるはず。
WE3.4.1 ハイブリッドなポイント・オブ・プレゼンス（PoP/CDN）の展開に向けて取り組んだ場合、必要に応じてフル PoP とミニ PoP（物理およびクラウド）の両方を構築できるようになり、ミニ PoP のプロトタイプに将来の展開基盤を築けるはず。
WE3.5.1 製品・技術（Product & Technology）と資金調達（Fundraising）の両チームが連携して私たちのプラットフォーム上から寄付者を識別する技術的アプローチを文書化して評価した場合、プライバシー、可行性（feasibility）、影響をバランさせて短期・長期の解決策を推奨できる見込みです。この共通理解により意思決定を調整したり、プラットフォームを横断した寄付者の承認を続けたり、また将来は募金関連機能をめぐる実験のターゲットをさらに絞り込む上で役立つはずです。
WE3.6.3 読者のニーズの進化、インターネット上の知識の本質の変化をめぐりコミュニティを促して対話した場合、共通の焦点を築いて読者にどのように貢献するかをめぐり、さまざまなアイデアをテストするかどうか（マルチメディア、検索と発見、機械学習などを含む）、またその具体的な方法について協力できるはずです。
WE3.6.4 ウィキペディアその他の知識プラットフォームでは、読者はいつ・なぜ・どのような契機や行動、ニーズが背景にあって利用するのか調べると、消費者戦略に役立つ優先課題分野や具体的な取り組みを提案できるはず。
WE3.6.5 製品&技術と資金調達の両チームが協働し、プラットフォーム上で寄付できる機会を多様化し、さらに寄付した読者を認めて寄り添った場合、目標と指標の設定は明確で目線が揃い、消費者と資金調達戦略を結びつけるはず。
WE3.6.6 統一した測定戦略を策定した場合、消費者による複数年戦略の評価が可能になり、ロードマップを定義して指標開発とレポート機能の指針にできるはず。
WE4.1.1 非緊急フローで最小限の実行が可能なプロトタイプを作成し、拡張権限を預かる利用者と共同で開発を進めフィードバックの反復的なループを維持すれば、このフローの拡張展開に関してこれらのグループの支持を得られるはず。
WE4.1.3 10月末までにウィキペディア7件を更新した場合（イタリア語版、スペイン語版、ドイツ語版、ハンガリー語版、フランス語版、ポーランド語版、ポルトガル語版）、DSA（デジタル署名アルゴリズム）要件に適応した新しい法務フッタ（Legal Footer）展開のフェーズ1が完了するはず。
WE4.1.4 事案報告システム（Incident Reporting System）のMVPを大規模で複雑なコミュニティを中心に15件以上のウィキ類に導入した場合、コミュニティの意図したとおりに利用できるかどうか確認し、それにより緊急ではない事案報告に使える実用的なモデルであると実証できるはず。
WE4.1.5 不正使用対応プロセスをまだ確立していないウィキに不正使用事案報告フロー図を設計した場合、そのようなウィキでも当該ウィキの利用者が明確で実行可能な支援経路を利用できるように、事案報告システムの導入が促進されるはず。
WE4.2.3 hCaptcha アカウント作成試用策から得たデータを分析した場合、アカウント作成ファネルと、hCaptcha のパズルとスコアの有効性が理解でき、アカウント作成において hCaptcha をさらに展開する上で必要なデータが得られるはず。
WE4.2.5 調査を実施し、コミュニティ群から聞き取って技術的な解決策を精査した場合、構造化されたブロック理由のセットで WMF の全ウィキが採用できるものを定義できるはず。
WE4.2.6 データプラットフォーム上に OpenSearch 基準のクラスターを展開する機能を開発すれば、この機能を統合する製品機能技術チーム（product feature engineering）は高い自律性、回復力、他の検索ベースシステムから独立したシステムを開発できるはずです。IPoid サービスは当システムの最初で主要なテナントになると見込まれます。
WE4.2.7 もしも製品版ウィキペディア数件で先行試用版として hCaptcha エンタプライズ統合（Enterprise integration）を導入した場合、hCaptcha エンタプライズの有効性と価値をめぐり、その不正使用防止、ボット検出、使いやすさとアクセス性に関してデータを収集できるようになるはず。
WE4.2.8 hCaptcha のプロキシの可観測性（observability）と提供を改善して製品化段階に持ち込んだ場合、本番環境のウィキペディアに対し第1四半期に、より安定し信頼性の高いサービスを提供できるはず。
WE4.2.9 hCaptcha SDK をネイティブのモバイルアプリに統合し、

ネイティブアプリのユーザー体験（UX）と、hCaptcha チャレンジを有効にしてアカウント作成 API の一部にするかどうかのどちらも評価した場合、十分な情報を得て hCaptcha をアカウント作成 API 向けにさらに展開できるはず。

WE4.2.11 hCaptcha を有効にして、よりリスクが高い編集シナリオにおけるボット検出に充当した場合、hCaptcha は自動化不正行為削減に役立つとわかるはず。
WE4.2.16 WMF の担当チームと協議ができた場合、利用者による非公開データへのアクセスをよりきめ細かく管理する計画を合意のもとに策定して、防御ソフトウェアの非公開ルール導入に対応できるはず。
WE4.2.17 実際の事例を分析してからチェックユーザ（CheckUsers）にインタビューして編集者履歴のプロトタイプから潜在的な不正行為の兆候を2件以上特定してもらうと、製品安全性・完全性チーム（Product Safety and Integrity）はこれらシグナルが価値をもたらすという確信を高め、これらを調査提案機能（Suggested Investigations）に組み込むことができるはず。
WE4.3.2 JA4H フィンガープリントを導入した場合、HTTP クライアントの挙動をまとめさせ、ボットのトラフィックをよりよく識別し分類できるはず
WE4.4.1 パイロット版から得たフィードバックに基づいて改善を実施し仮アカウント（Temporary Accounts）をすべてのプロジェクトに展開できた場合は、私たちの全プロジェクトにおいてアカウント未登録の利用者に関する個人特定に結びつく情報（IPアドレス類）を暴露から保護し、開示対象は（登録済み）利用者全体の 0.1% 未満にできると見込まれます。
WE4.4.2 ウィキメディア運動関連の（Wikiコミュニティやグローバルな役務者含めた）利害関係者と明確かつタイムリーな意思疎通ができた場合、残りのウィキ類全件に展開が可能で、土壇場で発見する作業負荷の軽減、展開のロールバックを回避できるはず。
WE4.4.5 不正行為の実施に仮アカウントを使う悪意の行為者を、巡回者が特定する際の負担を軽減した場合、仮アカウントを採用するウィキ全件において巻き戻し率の増加は測定しないまま、荒らし行為増の防止ができるはず。
WE4.4.6 LiquidThreads 拡張機能を廃止した場合、現状でこの拡張機能を使用中のプロジェクト全件において展開済みの仮アカウント（Temporary Accounts）のブロックを解除できるはず。
WE4.6.1 Zendesk 内でパスワード・リセットに関するアカウント同期プロセスを自動化して使えるようにした場合、信頼安全部（T&S）の負担を軽減し、2ファクタ認証リセットのリクエストをより多く処理できるはず。
WE4.6.3 確認済みのメールアドレスを持つ利用者全員、アカウントで2FAを有効化できるように処置しておいて、それでも利用者にはこの変更を積極的に告知しない場合だと、復旧サポートデスクの負荷は持続可能なレベルに留まるはず。
WE4.6.4 2FA システムにおいて利用者体験のオーバーホールを続けパスキー対応のサポートを提供した場合、より多くの利用者が複数の認証要素を登録し、アカウントへのアクセス失効に対して保護が強化できるはず。
WE4.6.5 当方が一般的なフレームワークを設計・構築し、ローカルまたはグローバルのグループ参加者が満たすべき要件を指定する場合は、同フレームワークを適用し、仮アカウントのIPアドレス開示グループ（temporary-account-ip-viewer）の構成員には、既存の方針要件を必ず満たすことを必須要件とします。
WE4.6.6 拡張権限を持つ利用者（UWER）がユーザー・スクリプトを実際にどのように利用しているか調査してユーザー・スクリプトのシステム・セキュリティを確保する実質的な計画を提案した場合、UWER コミュニティが重要な技術的介入を 1件以上、実施する点に賛成してもらえるはず。
WE4.6.7 OAuth など代替メカニズムを検討し、ネイティブのモバイルアプリ経由のモバイル型サインイン体験を変えてウェブ版プラットフォームと整合させるため、どんなユーザー体験と技術の変更が必要か評価した場合、その統合の実現可能性は、より安全で一貫性のあるユーザー体験の提供に照らして判断できるはず。
WE4.6.8 第1四半期に構築した Zendeskと MediaWiki フォームの影響を監視した場合、今後の四半期単位で、アカウント復旧プロセスの残りの部分をもっと自動化する技術的介入を提案できるはず。
WE5.1.2b 開発者識別と認証に使う複数の方法を API ゲートウェイに統合した場合、ユーザーコホートごとのリクエストを正しく識別し、各リクエストに適切なレート制限の割り当てができるはず。
WE5.1.3b REST ゲートウェイのルート3件以上でレート制限のドライランを実施した場合、リソース消費の観点からレート制限の実現可能性を検証し、利用者への影響を最小限に抑えながら適用できる、初期の制限セットを定義できるはず。
WE5.1.4b APIユーザー分類メカニズム※の提案検証に、より広範なデータセットならびに特定グループの手動評価を採用した場合、その有効性の理解はユーザーコホート確定、使用する計算手法改良によって、より深まるはず。（"※"＝API user segmentation mechanisms。）
WE5.1.5 トラフィック識別と速度制限をめぐりメディアウィキのプラットフォーム・チームと連携した場合、プラットフォーム・チームを支援してこの機能の作成と展開が進展し、製品版におけるドライラン・テストの速度制限を実施できるはず。
WE5.2.1b 新しい REST API 検索機能の見込み利用者と関わったら、これは新設計の使いやすさ、開発者の想定モデルと一致しているかどうかを示す重要なユーザビリティ洞察の特定に役立ちます。
WE5.2.2b アクション API を中央 API ゲートウェイ経由でルーティングすると、洞察を得るためトラフィックと使用パターンを一貫して測定して、将来の意思決定や対策に役立てることができます。
WE5.2.4 API 2件に標準的な説明文書パターンを実装した場合、コンテンツのガイドラインを洗練させ、API オーナーがガイドライン採用のために何を必要とするか理解し、ガイドラインをウィキメディア API の残りの説明文書全件に実装するにはどれほどの労力が求められるか定量化できるはず。
WE5.2.5 MediaWiki REST API において OpenAPI 仕様のリンティングルールを定義し適用する実験を行った場合、プログラムによって API スタイルガイドを強制する手段を実証し、ウィキメディアとコミュニティ全体に公開するAPI の品質と一貫性を向上できるはず。
WE5.3.1 既存のガイドラインを更新しながら UX 帰属ガイドラインの拡張と合理化をおこなった場合、テストと繰り返し改良を内部で重ねて改善版ガイドラインの中核セットを確立し、より広範な一般利用に備えることができるはず。
WE5.3.1b UX ガイドラインの草案と実演を公開し開発を繰り返した場合、中核セットを確立して内部テストに備えたり反復的な改良を重ねたりして、より広範な一般利用に備えることができるはず。
WE5.3.2 サードパーティのコンテンツ再利用者とそのエンドユーザに対する資料を作成してウィキペディアの帰属を明示するメリットを示し、第1四半期末までに再利用パートナーが少なくとも1社、帰属に関する事例研究またはデモの掲載に同意してくれたら、WME4.1 および WME4.2 に対応できるはず。
WE5.4.2b 既知のクライアントを識別するスケーラブルな方法を構築すれば、発信元検証済みのボットに対して一般的なレート制限の例外を許可し、ルールを体系的に適用できるはず。
WE5.4.5 レート制限はクライアントごとの多様なクラスに合わせて適用を始めた場合、インフラ上でクローラーがもたらす負担を軽減するはず。
WE5.4.6 第2四半期末までにスパイダー類 N 件を既知のボットとして分類を済ませると、それらに使われるリソースを量的に制限できるはずです。
WE5.4.7 私たちのメディア・インフラ上で許容されるサムネイルのサイズ標準化セットを策定し、さまざまな画像サイズの生成レートを制限しながら最も高コストのものを事前に生成した場合、

メディア配信インフラの負担を軽減できるはず。

WE6.1.2 プレマージ・テスト環境にウィキファームを追加した場合、本番環境向けに開発のために複数ウィキを必要とする開発チームはパッチを個別にテストできるようになり、結果として本番環境への信頼性は高まり、不具合の見逃しも減少するはず。
WE6.2.1 セルフサービス可能なタスクに加え、特定のサービスを本番環境対応とみなす前提条件を明確に定義した本番環境対応チェックリスト（Production Readiness Checklist）を評価し公開した場合、SRE（サイト信頼性エンジニアリング）と開発チームそれぞれの期待を一致させ、全体的な運用効率とスケーラビリティを向上できるはず。
WE6.2.2 Go（Golang）と Node.js のライブラリを作成し、面倒な作業をたくさん抽象化すると開発者に対して発表した場合、その人たちから関心が寄せられフィードバックがもらえるはず。
WE6.2.4 もしデータ持続性（Data Persistence）設計の評価を実施して積極的に支援した場合、製品化への円滑な道すじを特定できる可能性があります。
WE6.3.2 新たに開発した指標、Parsoidのキャッシュ基盤の改善を「トップ10」ウィキペディアの2件に導入した場合、信頼性フレームワークのパフォーマンス基準が確立し、他の大規模ウィキ類へ導入する準備状況の検証に役立ち、高トラフィックの大規模処理能力を実証できるはず。
WE6.3.3 重要な言語変種（Language Variant）の対応改善を実施し、 Parsoid を言語変種ウィキ3件以上に正常に展開できた場合、確信を得る上で欠かせない主要な技術課題を特定して解決、残りのすべての言語変種ウィキに展開できる見込みです。
WE6.4.6 メディアウィキの技術チームがSREから支援の提供を受けた場合 - 容量とトラフィックの管理、設定変更の準備と評価、問題調査とトラブルシューティングの協働を介して - 私たちは 第2四半期に製品版PHP 8.3 更新を完了し、さらに将来のアップグレードに備えて、重要な経路の SRE 依存を最小限に抑制する一連の勧告を文書化します。 T360995
WE6.4.7 グローバルなルートアクセス権限を備えた利用者全員の少なくとも90%を移行し、ウィキメディアの本番サーバーへのアクセスにハードウェア・バックアップ型のSSHキーを使用してもらった場合、たとえラップトップがウイルスに侵害された場合にも深刻なセキュリティ侵害を引き起こすリスクを軽減できるはず。
WE6.4.8 MediaWiki エンジニアリング・チーム（Engineering Team）が PHP 更新関連の問題を MediaWiki で積極的に監視して修正した場合、SRE チームによる本番環境の PHP 8.3 更新は2025年11月の期限までに完了するはず。 T360995
信号&データ・サービスの仮説（SDS＝Signals & Data Services）

[ SDS 主な成果 ]

議論

仮説の短縮名 第2四半期（Q2）本文 詳細と議論
SDS1.2.1 XML ダンプのプロセスを現在の「Dumps 1」インフラからメディアウィキのコンテンツ・パイプラインを活用したデータ・パイプラインに移行すれば、SLO を保証し「Dumps 1」ベースの XML エクスポートを停止できるはず。
SDS1.2.2 MediaWiki コンテンツ履歴（Content History）ならびにイベント・プラットフォーム／イベントゲート（Event Platform / Event Gate）関連 SLO 類に対してウォークスルーを実施した場合、顧客や指標とそれらに依存する利害関係者を検証でき、SLO に必要な改善点を特定して、週次の納品保証（weekly delivery guarantees）におけるギャップを明確にできるはず。
SDS1.3.1 クライアント側シグナルを導入してサーバ側ウェブリクエスト（webrequest）のログと対照して監査した場合、追加のボット・パターンが見つかりキャラクタ設定ができるはず。
SDS1.3.2 現在のボットと人間の分布を基準として、分布変化を自動アラートで検知した場合、自動トラフィックの予想外のパターンが次にいつ発生するか、検知時間を数週間から数分にまで短縮できるはず。
SDS1.3.3 ウェブ・リクエストのバックフィル・メカニズムを自動化し、5月のログに適用した場合、数ヵ月かかる事案の修復時間を将来は数日に短縮し、「5月のページビュー増加」事案を解決できるはず。
SDS1.3.4 ボット分類の出力結果に対して運用可能で定期な内部監査プロセスを構築した場合、解決策の信頼を築き、トラフィックの自動的に検出されないパターン変化を予測できるようになるはず。
SDS1.3.5 基本的なクライアント側シグナルを分析してヒューリスティクスに組み込んだ場合、データプラットフォームで検出できるボットパターンを追加できるはず。
SDS1.3.6 Spur.us IP 評価をインポートして分析し、ヒューリスティックに組み込むと、データ・プラットフォーム（Data Platform）で検出できるボットパターンを追加できるはず。
SDS1.3.7 エッジからシグナルを1件インポートして分析し、ヒューリスティックに組み込むと、データ・プラットフォーム（Data Platform）で検出できるボットパターンを追加できるはず。
SDS1.4.1 ウィキメディアのエコシステム内のトレンドに関して既存の分析 - ページ閲覧、投稿者と読者の指標、トラフィックなど - を再確認すると、ウィキメディア運動の最も重要な洞察における際立った論点について、自信を持って裏付けができるはずです。
SDS1.4.2 ウィキメディアのエコシステム内のトレンドに関して既存の分析 - ページ閲覧、投稿者と読者の指標、トラフィックなど - を再確認すると、ウィキメディア運動の最も重要な洞察における際立った論点について、自信を持って裏付けができるはずです。
SDS2.1.1 実験を行う各チームと緊密に連携した場合、今後、可能性として、システムをよりセルフサービス化する方法、またどのような概念または技術の課題に直面するか学べるはず。
SDS2.1.2 イベントログに関してより適切なバグ対応を実装できた場合、製品チームは自分たちの実験が期待どおりのイベント・データを収集していると把握し、実験オーナーが寄せる信頼を高めるはず。
SDS2.1.3 実験プラットフォームに組み込んだA/Bテストシステム（xLab）について、そのログ記録と可観測性構成要素と、さらにMediaWikiの関連コンポーネントを改善した場合、同システムのパフォーマンスのベースラインを確立し、実験関連の障害に対応できるようになるはず。
SDS2.1.4 実験のストーリーや成果の共有を組織横断で（製品運用や設計のそれぞれチーム会議、チーム間のプレゼンの場で）毎月1回、共有すると、実験プラットフォームを有機的採用が実現するはず。
SDS2.1.5 xLab で作成された計測器を使う利用者に特定して、その計測器にはリスク・カテゴリを変更する属性セットが含まれていると伝えると、それら利用者によるデータの過剰な収集を抑止でき、プライバシー評価が必要なのはどのような属性の組み合わせか明確になるはず。
SDS2.1.6 Growthチームがエクスペリメント・ラボ（Experiment Lab）を採用しユースケース2件（片方はA/Bテストをしてバケット化機能に関する洞察を取得、別の片方は長期的なインストルメンテーションによりKPIに似た指標対応を習得）のインストルメンテーションに取り組んだ場合、GrowthExperiments のカスタム実験設定の置き換え要件を十分に満たしているかどうか評価できます。
将来の観客の仮説（FA＝Future Audiences）

[ FA 主な成果 ]

議論

仮説の短縮名 第2四半期（Q2）本文 詳細と議論
FA1.1.4 [前予算年度から継続] Roblox でウィキペディアの新しい体験を築くと、これが私たちのブランドを若い観衆（アルファ世代）に紹介する効果的な方法になるかどうか学べるはず。
FA1.1.2 ウィキペディア体験のため itch.io に中心的なハブを新しく構築した場合、利用者でウィキペディアに関心を寄せてはいるがまだアカウントを登録していない50人以上からフィードバックを得て、ゲームでは何が機能し何が機能しないか学ぶのに役立つはず。
FA2.2.1 短編動画のプラットフォーム全体でコミュニティ管理に投資した場合、第2四半期末（2025年12月）までに、TikTokにおける新規視聴者の視聴率（QoQ）は前四半期比で30%増となり — 短編動画プラットフォーム（SFV）全体で外部コンテンツ総体へのブランドコメントに占める反応（エンゲージメント＝いいね！と返信コメント）は合計5万件に達する見込みで、これにより現状はリーチできていない観衆（オーディエンス）の認知度向上と反応促進につながると見込まれます。
FA2.2.2 ウィキペディアのクリエイター・パートナー関係プログラムの内部戦略と外部共有コンテンツを作成し、承認を得た場合は堅牢なクリエイター戦略を確立し（そこにはクリエイターが感じる価値、パートナー関係基準、契約プロセス、そしてクリエイター・コンテンツを所有チャンネルとクリエイター・チャンネルに表示する方法など概要を含めておき）、私たちの知識コンテンツを使いSNS経由で新たな観衆に訴求できるはず。
製品と技術支援の主な仮説（PES＝Product and Engineering Support）

[ PES 主な成果 ]

議論

仮説の短縮名 第2四半期（Q2）本文 詳細と議論
PES1.1.5 メディアウィキのコンテンツ履歴と関数ウィキに関して、サービスレベル目標 (SLOs) を Sloth/Pyrra にオンボードすると、SLO 2件が追加で本番環境に導入できるはず。
PES1.1.6 既存のSLOから再帰的なデータでSlothを試行した場合、Pyrra もしくは Sloth（または他のもの）が私たちの固定枠アプローチがエラー予算枠に適したツールかどうか理解します。SLO指標をセルフサービスで使うアプローチではサービス所有者をどう支援し、意思決定にどう採用するか方法を学びます。
PES1.2.4 第1四半期に四半期ごとの要望とコミュニティのシグナル評価プロセスを3チームで試行する場合は、製品管理者（Product Managers）に参加してもらい 、コミュニティのシグナルを各プロジェクトで四半期および年間の計画プロセスに統合する予定です。
PES1.2.5 要望リスト拡張機能に要望のフィルタと並べ替え機能を追加した場合、タグによる分類と投票機能に加え、これら3つの改善により、要望リストへのユニーク参加者が少なくとも30%増加するはずです。
PES1.3.3 利用者関与（user interactions）を基準にプラットフォーム上で発生させる魅力的な介入を、最低5件作成できた場合、ポータル・ページとバースデー・モードのガジェットのトリガーが定義できます。どの介入がブランドを肯定的に連想させるかは、使いやすさテストによって判明するはずです。この仮説は、10月末のウィキカンファレンス北アメリカまでに終了の予定です。
PES1.3.4 コミュニケーション部門（Comms department）の職員との協力により、キャンペーン対象地域の18歳から34歳のオンライン利用者層をターゲットに没入型ウェブサイト（immersive）を作成してウィキペディアの歴史と現在、未来を探求できるようにした場合、SNSのシェアその他のオンライン活動を介して、ウィキペディアとの繋がりが強化されるはずです。これにより、ブランド存在感（brand presence）を10パーセントポイント向上させるという、コミュニケ部門の主な成果（KR）到達に貢献するはずであり、同時に当方にとっては、コンテンツへの動的アプローチがブランド好感度を向上させるかどうか示唆になるはずです。


第3四半期

ウィキメディア財団の年次計画第3四半期 （Q3）は、2026年1月-3月にあたります。

ウィキ体験（WE＝ Experiences）の仮説

[ WE Key Results ]

議論

Hypothesis shortname Q3 text Details & Discussion
WE1.1.3 If the Editing Team makes an initial set of edit suggestions available within VE via a URL parameter and invites ≥10 newcomers and patrollers to offer feedback about it, we will learn what improvements would need to be made before running a controlled experiment to evaluate the intervention's impact.
WE1.1.4 出典チェック機能（Reference Check）は、比較実験を通して英語版ウィキペディア（en.wiki）に導入した場合、新規（または経験の浅い）ボランティアが建設的な編集を保存する率は4%以上増に達すると見込まれ、また巡回担当者やモデレータから十分な支持が得られるかどうかにより、この機能がより広く普及するかどうか判断できるはずです。
WE1.1.12 If we enable ≥3 volunteers to evaluate ≥30 sample edits each, for each of the 10 new languages we are seeking to scale Tone Check to, we will learn how often volunteers agree with model predictions and be able to decide which new wikis to approach about deploying Tone Check to.
WE1.1.14 If we prompt new(er) volunteers to consider the tone they are writing in when an AI model detects them using non-neutral language, then we will see a ≥4% decrease in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:NPOV (and related policies).
WE1.1.17 If we develop a task generation engine for the Revise Tone structured task, integrate our recent learnings about which content to include or filter out, and provide pipelines that automatically refresh the task list, we'll enable a qualitative evaluation of the tasks generated and an A/B experiment that tests whether this type of task helps newcomer editors to make more constructive edits.
WE1.1.18 If we analyze a pre-predetermined set of leading indicators ~2 weeks after the start of the Revise Tone Structured Task A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature.
WE1.1.19 If we enable people on mobile web to edit any article section, regardless of which edit icon they first tap, then the newcomer mobile edit abandonment rate will decrease by #% because they will be able to more more easily locate the content they tapped edit seeking to change.
WE1.1.20 If the Growth team scales the “Add a Link” task to at least 10 additional Wikipedias, then we can complete leading indicator analysis to confirm that the task is performing as expected and identify any wikis that may require further review.
WE1.1.21 If we deploy the new Add-a-Link model version to both newly onboarded wikis and wikis currently using Add-a-Link, then the Growth team will be able to roll out Add-a-Link as a structured task to wikis where it did not previously exist, and wikis that already had the task will receive an updated model with fresher training data and improved offline performance.
WE1.1.22 If we improve the initial “Welcome to Wikipedia” verification email, the percentage of new accounts that verify their email address will increase. This would allow Growth to re-engage these accounts through follow up emails and ensure they receive talk page notifications.
WE1.1.23 If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.1.24 If we prompt new(er) volunteers pasting text from an external site to confirm whether they wrote the content they are attempting to add, then we will see a ≥4% increase in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:COPYVIO (and related policies).
WE1.2.6 If we develop a goal-setting feature via Event Registration, then more collaborations will be created via Event Registration.
WE1.3.3 If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.3.4 If we deploy the Revert Risk filter to 150+ additional Wikipedias that currently lack damaging/goodfaith models, then we will see an increase in moderator patrol counts for contributors who use the personal moderator dashboard compared to those who don't get access to the dashboard.
WE1.5.1 If we implement a dashboard to explore 7 contributor metrics and standardize the calculation of at least one metric using dbt then we can enable contributor product teams to self-serve metric insights and develop a standard for storing metric calculation logic.
WE1.5.3 If Data Engineering productionizes a data product of edit types by the end of Q3, then the 6 moderator actions that are "Complicated" to measure will become "Simple", allowing Movement Insights to define a monthly active moderator metric as a next step.
WE1.5.4 If we produce a prototype dashboard with active moderator metrics that are currently available, then we will be able to produce a full dashboard by end of Q4.
WE1.6.1 If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE2.2.13 If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.2.20 If we roll Wikifunctions out to wikis that have Parsoid enabled, we will be able to continue testing whether the system remains performant and usable in increasingly broad rollouts.
WE2.2.21 If we allow a limited set of reentrant functions in the evaluator, it will be possible to increase reliance on evaluated implementations, thereby leveraging the most performant part of the backend.
WE2.2.22 If we write an explicit interpreter for the composition language, the orchestrator will be more performant, and further performance-enhancing features will be easier to implement.
WE2.2.23 If we enable contributors to reuse whole composition blocks across functions, we will reduce repetitive work and significantly speed up the creation of new implementations, especially for similar linguistic functions.
WE2.2.24 If we define a clear documentation structure and entry points, function creators will more easily find relevant guidance and experience less friction when creating functions.
WE2.2.25 If we systematically identify the biggest friction points in the function creation experience, we can surface a small set of high-impact improvements that make creating and iterating on functions more efficient.
WE2.2.26 If we introduce a lightweight, local reference solution (via pop-ups) for Abstract Wikipedia, we can establish an initial citation mechanism to inform whether more complex solutions are necessary.
WE2.3.4 If we build and release an initial version of the Abstract Wikipedia platform, we can demonstrate the technical feasibility of the ecosystem working across multiple languages.
WE2.3.5 If we engage with a small number of under-resourced Wikipedia language communities with a concrete example of abstract content, we can validate whether content created outside their local wiki is acceptable and identify conditions needed for adoption.
WE2.3.6 If we design how Abstract Wikipedia content is surfaced and presented within local Wikipedias, and how local communities make integration decisions, we can socialize the proposal, reach agreement, and confidently plan Q4 development work.
WE2.5.1 If we deploy the Blazegraph candidate replacement in eqiad and augment existing evaluation work with production WDQS traffic-replay analysis, then we will confirm that the new backend performs comparably, supports real-world SPARQL queries, and is ready for limited live-traffic exposure once the surrounding ecosystem (UI, monitoring, onboarding, and real-time index update pipeline) is prepared.
WE2.5.2 If we define access guidelines for the Wikidata platform, we will better be able to control the load put on WDQS servers at the time of our backend migration.
WE2.5.3 利用者のペルソナのコホート[※]を定義しておきバックエンドの新システムのテストに備えると、Blazegraph への切り替えにおいてパイロットフェーズ、その後のフェーズに採用できるはずです。（※訳注＝cohort 仮空の人物像で同じ特性や特徴を持つ集まり）
WE2.5.4 If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.5 If we optimize the Wikidata Revert Risk model for low-latency inference and deploy it in a stable, scalable manner on LiftWing, then the Wikimedia Enterprise team will be able to integrate revert risk signals into their product pipeline, enabling customers to receive timely, high-quality model outputs.
WE3.1.8 If we evaluate 2 semantic search prototypes (natural language search, Q&A) with external participants, we can learn whether users see value in improved search tools, and provide the Readers teams with a recommendation on how to move forward with a search and discovery MVP.
WE3.1.12 If we collect a benchmark dataset consisting of a set of representative queries and annotations of relevant search results, we will be able to perform offline (i.e. without user studies) search evaluation of the quality of search results of different search models.
WE3.1.15 If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention
WE3.1.16 If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17 If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.1.18 If we deploy a Qwen3 embeddings inference service that is compatible with our existing OpenSearch stack, then Mobile Apps can experiment with generating article-chunk and query embeddings through Qwen3, which should outperform the embeddings produced by OpenSearch’s built-in models.
WE3.3.6 記事のトピック推論データを提供するとき、スケーラビリティの合意ならびに可用性要件の双方を満たすサービスを使い、しかも必要なデータのバックアップも実施する場合、今後のパーソナル化した閲覧者体験の支援に必要な技術基盤は、当該データに依拠して確立済みと見なされます。
WE3.4.1 If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.2 If we offer donors a badge acknowledging their status, at least 70% of donors who opt-in will report positive sentiment on a linked survey.
WE3.6.5 If Product & Technology and Fundraising collaborate on a shared strategy to diversify on-platform donation opportunities and steward and recognize readers who donate, we will set clear, aligned goals and metrics tied to our consumer and fundraising strategies.
WE3.6.6 If we develop a unified measurement strategy, we will enable evaluation of the consumers’ multi-year strategy and define a roadmap to guide metric development and reporting capabilities.
WE3.6.7 If we run a secondary A/A test on retention rate for logged-out users, we will begin to establish seasonal trends for retention rate that we can use for future quarters
WE3.6.8 If we systematically compare the information seeking needs and behaviors of 1) new and infrequent English Wikipedia readers and non-readers with those of 2) current English Wikipedia readers by simultaneously surveying both populations, we will be able to identify key insights about the demographic characteristics, online information needs, and online platforms used by these audiences, identifying potential opportunities for growing our readership as well as potential threats to our existing readership.
WE3.8.1 If we add additional modules to the activity tab and scale it to all users, we’ll see a 5% increase in overall iOS app account creation compared to before release
WE3.9.1 If we update the Wikipedia iOS app’s visual foundations, component defaults, and navigation behaviours to align with Apple’s Liquid Glass design language—while clearly defining design and behaviour for high-priority fallbacks across OS versions—then downstream engineering implementation will be clearer, lower-risk, and the app will feel more platform-native when Apple forces user switchover
WE3.10.1 If we user test a design prototype of the Explore Feed built with lightweight personalization, clear freshness cues, and repeatable Wikipedia-native patterns (e.g., topical rabbit holes, time-bound highlights, and interactive elements), casual reader participants will report understanding of the proposed feed’s purpose, reach an “aha” moment faster, and show a stronger intent for daily use. The visual design we recommend moving forward with will be described as digestible and aligned with the Wikimedia movement.
WE4.1.3 If we update 6 Wikipedias (English, French, German, Spanish, Italian, Polish) by the end of Q2, we will complete phase 1 of the new Legal Footer roll-out in response to DSA requirements.
WE4.2.5 調査の実施、コミュニティからの聴き取り、技術面の解決策の 精査により、WMFの全ウィキで使用できるブロック理由の構造化セットを定義できるはずです。
WE4.6.8 If we monitor the impact of the Zendesk and MediaWiki forms we built in Q1, then we can propose technical interventions for future quarters that would better automate the rest of the account recovery process.
WE5.1.3c If we roll out rate limiting to all APIs routed through the gateway, we will be able to reduce the number of anonymous API requests that reach our backend infrastructure, by limiting requests based on user classes that give higher limits to authenticated and community users.
WE5.1.5 If we improve the sustainability and reliability of our OAuth 2.0 implementation, we will be able to convince more developers to use OAuth and support the migration of the Wikipedia mobile apps, by increasing confidence that it can be relied upon for high profile applications.
WE5.1.5b If we improve the developer experience for creating and managing OAuth 2.0 clients, we will be able to increase the number of applications that use OAuth 2.0, by deprecating OAuth 1.0 for new applications and promoting OAuth 2.0 as the preferred option for API authentication.
WE5.2.2c If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.6 If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping.
WE5.2.8 If we create dedicated API modules for all API extensions and self-contained functionality within MediaWiki Core, we will enable enforcement for higher quality documentation with independent management and versioning.
WE5.2.9 If we have better separation of concerns for API registration and spec definition processes, we will simplify the complexity of API management and create a better developer experience for API authors.
WE5.2.10 If we conduct a listening tour specifically focused on v2 API consolidation and feature gaps, we will be able to move more quickly with a v2 implementation.
WE5.2.11 If we experiment and establish processes for standardizing documentation currently in the API Portal, we can consolidate sources of information and improve documentation consistency.
WE5.3.1b If we publish and iterate on the draft UX guidelines and demos, we will establish a core framework ready to be internally tested and iteratively refined to be prepared for broader public use.
WE5.3.2b もしウィキメディアの帰属をめぐりパートナー対応の実験用パイロット・プログラムを設立した場合、再利用者による帰属表示が相互にどのように有益な影響を及ぼすか示して、ウィキメディアへの関与と貢献を促すことができるはずです。
WE5.4.6 If by the end of Q2 we've classified the top N spiders as known bots, we can constrain the amount of resources they're using.
WE5.4.8 If we start enforcing rate limits tailored to different classes of individual clients for media files, we will reduce the burden of crawling on our infrastructure.
WE5.4.9 If we add ip-reputation data on residential proxies to our bot detection, it will improve our ability to block scrapers
WE5.4.10 If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure
WE5.4.11 If we identify two high-confidence signals from the December 2025 scraping/DDoS incidents and deliver them to SRE, then SRE will be able to develop more effective automated mitigation rules for future similar incidents.
WE5.4.12 If we are able to attest where and from whom a request for an image is originated, we can make more informed decisions about rate-limiting them
WE6.1.2 If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes.
WE6.1.3 If we resolve the top 5 flaky Selenium tests over the next 90 days, we will increase developer confidence in automated browser testing as a valuable part of the pre-deployment workflow.
WE6.2.4 If we apply, and actively support the Data Persistence design review, we may identify paved pathways to production
WE6.2.5 By collaborating with the SLO group and gathering feedback from teams currently working with them, will help us not only identify gaps and improvements for the Production Readiness checklist, but also adapt it in such a way to directly facilitate SLO adoption and onboarding
WE6.2.6 hCaptcha プロキシサービスの導入については、本番準備チェックリストを試して重要度の高い項目を洗い出すと、未追跡の技術的負債を特定して作業のバックログを見える化します。これにより、フレームワークの価値を示し、さらに再現可能なプロセスを作ってサービス全体で一貫した採用を実現します。
WE6.2.7 By collaboratively refining the production readiness checklist with SRE input and contributions, we will ensure it addresses real operational needs, build shared ownership, and create a practical tool that teams see value in adopting.
WE6.2.8 SLOグループ、hCaptchaプロキシのパイロット、SREとの協働からフィードバックを得て分析すると、より明確な指針や支援リソースが必要なのはどのチェックリスト項目やプロセスのステップか特定し、フレームワーク合理化の次のステップを決定して、12月の年末年始休暇までに実際に採用できるようにします。
WE6.2.9 If we adopt node.js service-utils, we will be able to release, in a tested way, either of: service-mesh routing or OpenTelemetry publishing.
WE6.3.2 If we develop new metrics, improve Parsoid's cache infrastructure, and deploy on two "top-ten" wikipedias, we will develop performance criteria for the confidence framework, which will help validate our readiness for deployment to other large wikis and demonstrate our ability to handle high-traffic volumes at scale.
WE6.3.3 If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.3.4 If we QA, identify, triage, and fix bugs within the reading experience across platforms for Parsoid Read Views, we will maintain the quality of the reading experience and unblock further scaling across wikis
WE6.3.5 If we target a Time To First Byte (TTFB) metric of <= 110% of legacy for parser cache hits and <= 150% of legacy for parser cache misses, we can deploy to all Wikipedias except for Chinese and English by the end of Q3 with no performance complaints. This will help validate our readiness for deployment on English Wikipedia, preparing us to handle high-traffic volumes at scale by understanding our cache capacity.
WE6.4.4 If we unify our domains by serving all page views on MediaWiki sites through a canonical domain, then we will reduce platform complexity and SEO risks by eliminating the mobile-subdomain redirect. Completion is measured by decreasing redirects for mobile visits on canonical domains from 100% to 0%.
WE6.4.7 If we migrate at least 90% of all users with global root access to use a hardware-backed SSH key for accessing Wikimedia production servers, we will reduce the risk that a compromised laptop will cause a severe security breach.
WE6.4.8 If the MediaWiki Engineering Team actively monitors and fixes issues in MediaWiki related to the PHP upgrade, this will enable the SRE team to complete the production PHP 8.3 upgrade by November 2025.
Signals & Data Services (SDS) Hypotheses

[ SDS Key Results ]

議論

Hypothesis shortname Q3 text Details & Discussion
SDS1.5.1 If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2 If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3 If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS2.2.4 If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5 If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.4.2 If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.
Future Audience (FA) Hypotheses

[ FA Key Results ]

議論

Hypothesis shortname Q3 text Details & Discussion
FA1.1.1 If we build a central hub for new Wikipedia experiences on itch.io, then we’ll be able to grow an audience of >50 interested non-Wikipedians giving us feedback, which will help us learn what works and what doesn’t in games.
FA1.1.2 If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.3 If we create 4 TikTok filters and publish them on our TikTok account, we will be able to learn how well we can incentivize creation of Wikipedia content off-platform.
FA1.1.6 If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
FA2.2.1 If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2 If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.
製品と技術の支援における仮説（PES＝Product and Engineering Support）

[ PES 主な成果 ]

議論

Hypothesis shortname Q3 text Details & Discussion
PES1.3.5 If we build community configuration for Easter Eggs, and leverage Reader Experience full time for code review, we’ll be able to launch on Feb 15 and track impact of the project.
PES1.3.6 If we create bespoke social media posts for 25 Years of Wikipedia (25YoW), we can achieve similar success with social impressions as Comms’ existing templates, and prove we can support Comms’ by increasing their capacity. Benchmarking will be off of Truth Collective posts about the same project.
PES1.4.1 もしCodex を主に使用していない 4から5チーム（主に OOUI を使用するチームを含めるが限定条件ではない）との打ち合わせをした場合、Codex を採用する現在および将来のプロジェクト・チームに対して、阻害要件を文書化できるはずです。
PES1.4.2 もし Codex PHP をより使いやすく安定させて、1.0 版をリリースできたなら、担当チームは展開後、サーバー生成UIにCodex PHPを採用します。こうすると Codex PHP の使用率は3件から5件に増加の見込み。
PES1.5.1 Sloth をプロトタイプから Pyrra の代替品にアップグレードする前提として、既存のサービスをオンボードする場合、統合SLOダッシュボードのセットに集約してアラートを洗練させ、SLOオンボーディング体験を効率化できるはずです。
PES1.5.2 ウィキ関数ならびにメディアウィキのコンテンツ履歴（WikifunctionsとMediaWiki Content History）の SLI 指標を引き続きオンボードし、ウィキデータにおけるクエリサービスと編集チェック（WikiData Query Service と EditCheck）の指標の確認を続けたなら、SLO レポートに寄せられる要望は多いのに未対応という、ダッシュボードの報告機能とサービスオーナーの関与をめぐる問題をデバグします。

計画立案を共同で

2025年1月時点の情報更新。

Portrait of Selena

年度計画は、次の年度に実施したいことをウィキメディア財団が説明するものです。私たちは、この計画が参加型で、意欲に満ち、達成可能なものにするために精力的に仕事をしています。毎年私たちは計画を作るため、貢献者の皆さんに、展望、希望、特別の要望をうかがっています。それは、製品チームのコミュニティとの会話、コミュニティの要望リスト、コモンズ会話シリーズのようなコミュニティの会話など様々な方法により、会議やこのようなウィキページを通して行っています。

私たちの次の年次計画では、すなわち2025年7月から2026年6月にわたって、多世代の展望に最もよく貢献する方法を考えており、世界とインターネットの急速な変化、それから無償の知識をめぐる私たちの使命にどのような影響があるかを踏まえています。

昨年申し上げたように、新しい世代の注目を集めようと偽情報や誤情報のまん延するインターネットやプラットフォームで、信頼性の高い情報を提供できるという私たちが他と一線を画す可能性について、注目していくのが必要です。ここには、不公正や差別や偏見により失われた情報も含め、全ての人類の知識の総和を編集し提供するという私たちの目標が含まれます。私たちのコンテンツは、AIや豊富な経験により変化し続けるインターネットの中で、提供され続ける必要があります。そして最後に、私たちの製品のための共有する戦略や資金調達の方策を見つけることで、長期間にわたりこの仕事を支援できます。

次年度の目標をどこに絞るかの選択とトレードオフのため、私たちは質問を設定し、最大限の効果を得るために限られた資源をどこに使うのがよいか考えました。

ここに設定された優先順位に基づいて製品技術部門がどのようなサービスや機能を構築するかに興味をお持ちなら、3月に具体的な目標と主要な結果についてコメントする機会を設けます。 (参考のためここに現在の目標と主要結果を挙げておきます。)

私たちの技術的環境における課題や機会、次年度計画で設定すべき方向性について考えたい方は、下記の質問について一緒に検討ください。

私たちはこれらの質問についての情報を、いろいろなやり方で集め続けています — コミュニティでの会話や、収集したデータや、調査インタビューなどです。そしてこれらについて質問したり学んでいるのは今回が最初ではなく、既に多くの方たちとこれについて作業しています。私たちはここで再び質問をし、学び続けるのが、計画策定時において最重要であると考えているのです。

質問:

  • 指標とデータ
    • データや指標が編集者としてのあなたをどうしたらよりよくサポートできるでしょうか。編集したり、読んだり、整理したりするときのデータを考えてみて、時間の使い方や、注意をする必要を考えるのに役立つものはありますか？これはあなた自身の活動でも他の人の活動のデータでもかまいません。
  • 編集作業
    • 編集作業が報いられたり楽しいと最も感じるのはどういう時ですか？ストレスがたまったり難しかったりするのはどういう時ですか？
    • 私たちは貢献者のみなさんがより多くのフィードバックやこの活動への評価が得られるようにしたいと考えており、ウィキ上で費やした努力を誰も知らないことがないようにしています。どのようなフィードバックや評価があなたを動機づけますか？編集し続けることの後押しはなんでしょう？
    • ウィキはとても巨大なので、誰もが毎日どれに関わるのが最も大事かを決めるのは大変です。どれに関わろうか選ぶのに役立つ情報やツールはどういうものでしょう？あなたが新しい機会を見つけたり、活動を管理したり、あなたの影響力を理解するのに役立つような、一元的でパーソナライズされた場所があったら便利でしょうか？
    • 私たちはウィキ上での連携の経験を促進したいと考えており、バックログのドライブであれ、エディタソンであれ、ウィキプロジェクトであれ、二人だけの共同作業であっても、そうすることで貢献者のみなさんがお互いに知り合い、プロジェクトを一緒に進められると思っています。より多くの貢献者が知り合ったり、繋がったり、協働するにはどうすればいいと思われますか？
  • 閲覧/学習
    • ウィキの読み込みが早いか遅いかは、どこに住んでいるかによります。地球のどの地域の運用を向上させるのが重要だと思われますか？
    • 新しい世代の読者がウィキペディアのコンテンツを興味深く、魅力的に感じるようになるのをどのように支援できるでしょうか。私たちはこれまで、対話型のコンテンツや動画を巡るアイデアを議論してきましたが、今年には図表や ウィキペディアのコンテンツを表に出す新しいやり方に焦点をあてる予定です。このやり方を継続し、ウィキメディア独自の新しいやり方にするにはどうすればよいでしょうか？
  • モデレータ（仲裁者）
    • より多くの人が関わり、巡回者や管理者のような高度なボランティアの役割を果たしてもらうには、ウィキペディアのどこを変えていくのが必要でしょうか。
    • あなたが巡回したり管理の意思決定をより早く簡単に行うには、編集者や利用者に関するどのような情報が必要でしょうか。
  • 外部のトレンド
    • ウィキメディア以外の世界であなたが気付いている最も重要な変化は何でしょう？これは技術面、教育面、あるいは学習方法かもしれません。
    • ウィキメディア・ムーブメントの外側で、あなたが参加しているオンラインコミュニティはありますか？他のコミュニティのプラットフォームのツールや工程から私たちが学べるのはどういうことでしょうか？
    • ウィキメディア活動の内外でAIツールを使っていますか？AIツールは何に役立つと思われますか？
  • コモンズ
    • コモンズのコミュニティと協力して百科事典知識の創出を支援する持続可能なプロジェクトを作るには、どのような意思決定が必要でしょうか。
  • ウィキデータ
    • ウィキデータは将来どのように発展していくと思っていますか？信頼できる百科事典コンテンツ構築のために、ウィキデータをどのように活用できるでしょうか。

–– Selena Deckelmann

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Wikimedia_Foundation_Annual_Plan/2025-2026/Product_%26_Technology_OKRs/ja&oldid=30190882"