Wikipedia:井戸端

ここはウィキペディアについての議論などを行う場所です

詳しくはWikipedia:井戸端/ヘルプをご覧ください。

このページではウィキペディア日本語版について、運営、方針、新しいアイディアや作業の仕方、その他様々な事で質問や提案、議論、意見交換といった井戸端会議が行われます。

---

This page is for discussion of Japanese Wikipedia, normally in Japanese. But see also Help for Non-Japanese Speakers. If you want to just inform Japanese Wikipedians of something, you can use Wikipedia:お知らせ.

ショートカット:
WP:VP
WP:PUMP
WP:VILLAGE
WP:VILLAGEPUMP
WP:井戸端

相談と質問

• 井戸端
• 利用案内
• 調べもの案内
• 執筆・翻訳者の広場
• For Non-Japanese Speakers

ここに質問を投稿する前に

• 下記の過去ログ検索機能にて、既に似た質問がないか質問前にご確認ください。
• よくある質問（FAQ）や利用案内もご確認ください。なお、この井戸端で頻繁にされている質問があれば、それをFAQに追加するよう、提案してください。
• ウィキペディア日本語版やウィキメディア・プロジェクトと関係のない話題を投稿するのはご遠慮ください。
• 以下に当てはまるものは井戸端よりも適切な場所があるので、そちらにお願いします（「表示」を押すと展開されます）：

他に適切な場所があるもの

ウィキペディア全体に関して

• 利用者へのお知らせ → お知らせ
• 投稿や編集の仕方・方針やガイドラインに関する質問・操作方法に関する質問 → 利用案内
• ウィキペディアでの調べ物に関する質問 → 調べもの案内
• ウィキペディアのバグや不具合 → バグの報告
• 表示に問題がありそうなページの検証や改善について → 表示改善依頼

個々の専門分野に関して

• 意見・質問・確認事項など → ウィキポータル・ウィキプロジェクトの該当分野

個々のページに関して

• そのページのノートページ・執筆・翻訳者の広場
• そのページについての意見の募集 → コメント依頼

個々の利用者（アカウント）に関して

• その利用者の会話ページ・ウィキメール
• その利用者の行動についての意見の募集 → コメント依頼

以前の議論を検索する

• 井戸端タグについては井戸端タグの説明文書をご覧ください。
  
• 井戸端ウォッチリストではサブページを含めた井戸端の投稿状況が確認できます。
• 以下は、►（右向き三角）のクリックによって期間ごとの話題がツリー表示されます。

井戸端の話題/2025年/10月/上旬

井戸端の話題/2025年/10月/中旬

井戸端の話題/2025年/10月/下旬

運営方針

• 投稿された全ての話題はサブページに移動し、Category:井戸端の話題にカテゴライズされています。
• サブページは、最新の投稿から10日間経過するか、最初の投稿から30日が経過すると、井戸端への読み込みが解除されます。

投稿しましょう

新しい話題を投稿する

最後にもう一度「ここに質問を投稿する前に」を確認して問題がなければ、初心者は新しい節を追加して、経験者は新しいサブページを作成して投稿してください。

概要について

参考になる議論など

• Wikipedia:誤った導入部を修正する#日本語版の概要節という考え方 - ButuCCさんが特別:差分/106581869/106611747(2025年9月26日 (金) 17:01ごろ)にて言及。--~2025-27558-92 (会話) 2025年10月4日 (土) 03:21 (UTC)

今回の議論

区切り1

流石に長くなりすぎてるので、区切り入れます。--~2025-27726-78 (会話) 2025年10月5日 (日) 06:57 (UTC)

こんにちは。すみませんがお尋ねします。概要を次から次へと解説に書き換える編集者がいらっしゃいます。自分は全てのWikipediaのページを書き換えるのは無茶でWikipedia全体の体制を崩す行為と考えゲンキーのみ差し戻しました。そして編集争いとなりました。出来る事なら説得を試みたいのですが頭の悪い自分には難しい問題です。例の編集者はこのまま放置するべきかお教えください。えがわもデマ出典を削除するのに数年かかりましたのでゲンキーも同様かなと考えております。--Kazu7878（会話） 2025年9月4日 (木) 20:03 (UTC)

返信 (@Kazu7878 宛) 実例を複数、あれば5個程度記事へのウィキリンクだけでも教えて頂きたい。--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年9月4日 (木) 22:47 (UTC)

返信。ありがとうございます。シャトレーゼ、最上川交通、イカキング、エアカラン、イオン東根店など多数。利用者名は察して下さい。。--Kazu7878（会話） 2025年9月5日 (金) 13:30 (UTC)

出来れば「解説」に変わった時点の編集版指定リンクを、そして当該編集者の名前くらいは明記してほしいです。

• ウィキペディアは前提として百科事典であるため、すべての一般の記事はほぼ全文が解説であり、さらに設題に「解説」と付す意味が不明であることは事実です。

なお、当該利用者のノートページにて警告は済ませましたか？--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年9月5日 (金) 14:45 (UTC)

情報 記事「ゲンキー」については、「ノート:ゲンキー#以前の状態への一部差し戻しについて」で第三者の方が仲介されて議論されているようです。コメント依頼もなされているようです。--Assemblykinematics（会話） 2025年9月5日 (金) 18:46 (UTC)

コメント

• Wikipediaの記事において「概要」節は記事全体の要約を意味するため、記事全体の要約になっていない説明をしている節のタイトルを「概要」以外のものに変更するのは妥当だと考えます（Wikipedia:スタイルマニュアル/導入部#「概要」節を作る場合の注意）。
• ただ「解説」というタイトルですと節の内容が分かりにくいという側面は否めず、編集された方も他に良い案があれば提案して差し支えない旨おっしゃられています。記事全体の要約でないにも関わらず「概要」節としている記事が少なからずあるのは、他に適切な節タイトルを決めにくい場合が多いのかもしれません。適切な節タイトルは個別の記事ごとに検討する必要があり、場合によっては節構成の再編も必要になってくると思います。
• なお、「自分は全てのWikipediaのページを書き換えるのは無茶でWikipedia全体の体制を崩す行為と考え」というのは誤解・杞憂ではないでしょうか。編集された方は機械的に置換している訳ではなく、記事全体の要約になっている「概要」節は編集していないと当該ノートでもおっしゃられています。

--Assemblykinematics（会話） 2025年9月5日 (金) 18:46 (UTC)

ご意見ありがとうございます。--Kazu7878（会話） 2025年9月6日 (土) 00:20 (UTC)

当事者たる利用者「@Yasu」氏に意見願いを致しました。 --シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年9月6日 (土) 10:08 (UTC)

会話ページにお知らせをいただきましたので参上しました。シェン,アーナリー,ン,アーバァ.さん、ご連絡ありがとうございます。

私の編集意図はおおむね Assemblykinematics さんご賢察のとおりですので多くは申しませんが、少々補足させていただきますと、おっしゃるとおり「概要」をすべて「解説」に機械的に書き換えているわけではなく、節の内容から判断して「歴史」などさらに適切な見出しがあると考えた場合は、それを採用しています。例としては、BMW・F15、能登キリコ祭り、池の平小屋、松山郵便局 (山形県) などがあります。ちなみに松山郵便局 (山形県) は、Kazu7878 さんが提示されたイオン東根店とほぼ同時刻の編集なのですが、お気づきいただけなかったようです。いずれにしても先に述べたとおり「解説」に必ずしもこだわるものではありませんので、内容が概要ではない「概要」を置き換える見出しとしてより適したものがありましたら、ぜひお知恵を拝借したく思います。

なお、Assemblykinematics さんがいみじくもご紹介くださったように、そもそも私の意見はすでにノート:ゲンキーでの議論において述べているのですが、当事者である Kazu7878 さんからは何らの反論もなく、また「スタイルマニュアルに反して『概要』とすべき根拠があるのなら説明願いたい」という問いに対するお答えも未だいただけておりません。しかるにこうして本来の議論場所ではないところで、しかも議論の相手方である私に知らせることなく、フォーラム・ショッピングのような行動を取られたことについては、率直に申し上げてたいへん遺憾に思います。Kazu7878 さんにおかれましては、改めて当該ノートでの合意形成に参加し、きちんと説明責任を果たしていただくことを強く希望するものです。もちろん、この井戸端をごらんになった方々からのご意見も歓迎します。--Yasu（会話） 2025年9月6日 (土) 14:58 (UTC)

コメント 当該記事の保護依頼や当該ノートのコメント依頼を提出した者です。当該記事において第三者の立場を維持することや自身以外の第三者コメントが付いていないことから、これ以上新たに当該ノートでコメントをすることは今のところ控えています。また、自身のおおまかな見解は当該ノートで既に述べているのでそちらを参照して頂ければ幸いです。

自身としましては『「概要」節を作る場合の注意』にもあるように、概要節自体を無くして導入部に組み込んでも良いのではないかと考えますが、どうしても節としたいのであれば同ガイドラインの観点からも概要以外の節名を考案しなければなりません。ですが、シェン,アーナリー,ン,アーバァ.さんやAssemblykinematicsさんが解説という節名では百科事典的でない、または分かりにくいとおっしゃっているような意見もごもっともだと思いますので、解説でもない他の候補を編み出す必要がありそうです。「歴史」や「略歴」などでは内容と釣り合わないですし、似たような言葉では「概説（「ある事柄の全体にわたって、そのあらましを説明すること」「物事の内容のだいたいを説明すること」など）」や「概略（「おおよその内容」「物事のだいたいのところ」など）」がありますがどうでしょうか（あくまで個人的な意見ですが）。他にも概要・解説以外の相応しい節名があれば意見が欲しい所ですね。--Nrliw (会話) 2025年9月6日 (土) 15:22 (UTC)

コメント Yasu様、Nrliw様、補足いただきありがとうございます。記事「ゲンキー」における最近の経緯を確認しますと、

1. 2021-01-02T07:23:09(UTC)時点 - 「概要」節はなく導入部に概要が記載されていた。
2. 2021-03-02T05:30:49(UTC)における編集 - 導入部のほとんどが「概要」節として独立される。
3. 2025-03-15T02:49:59(UTC)における編集 - 「概要」節に経営目標などの情報が加筆される。
4. 2024-05-26T02:18:15(UTC)における編集 - 「概要」節に能登半島地震時の情報が加筆される。
5. 2025-08-10T15:04:15(UTC)における編集 - 「概要」節が「解説」節に改題され、さらに情報が加筆される。

といった状況でした。Kazu7878様は古くから当該記事に関わっていて1や2の状態もご存知のため、節タイトルが「概要」であるべきと感じられて当然かと思います。Yasu様は3や4で加筆された後の「概要」節をご覧になったため、記事全体の要約ではないと捉えられて仕方なかったと思われます。Nrliw様も5の状態をご覧になられたので、当該節は記事全体の要約ではなく別の節タイトルにすべきと感じられたはずです。

現状の節構成であればNrliw様の提案される「概説」や「概略」といったタイトルや、場合によっては「基本情報」といった感じの節タイトルが候補になるかもしれません。節構成を再編する場合、個人的には

• 「沿革」節は年表、年譜形式ではなく、複数段落の文章形式で記述し直す。
• 「解説」節の内容を既存の節に分散する。必要に応じて「経営戦略」や「経営方針」といった感じの節を新設したり、既存の節タイトルを変更する（「特徴」節と「不祥事」節はまとめて「特記事項」とするのが望ましい？）。
• 導入部に以前のような記事全体の主要情報をまとめた1段落程度の概要を記載する。文章量が多い場合は新しい「概要」節とする。

といった対応になろうかと思いますが、他のドラッグストアチェーンの節構成との兼ね合いもあり、プロジェクトか何かで調整が必要になるかもしれません。

なお当該記事のノートでの議論から井戸端に議論が派生してしまっていますが、一つの記事に限らない話題なのでそこは差し支えないと思います。前述のように記事全体の要約になっていない「概要」節の存在は気になっていたので、これを機に掘り下げられてよかったと感じています。--Assemblykinematics（会話） 2025年9月7日 (日) 00:11 (UTC)

返信 (@Yasu 宛) まずご参加頂いただけることに感謝いたします。

さて、本議論では@Yasuさんに〈「解説」という設題がなぜ妥当であるか〉についてご意見を頂きたいところです。

1. もちろん @Yasu さんがおっしゃる通り〈「概要」とは、記事全体のまとめ〉でしょう。
2. 他方で〈「解説」とは、ウィキペディアの記事本文の全体のこと〉ではないでしょうか。
   1. ウィキペディアは百科事典であり、節「ギャラリー」や脚注などを除くページの大部分が元より「解説」であるはずです。
3. このとき節「解説」が存在すると、節分けの前提から〈ほかの節は解説ではない〉という構成になってしまいますね。

少なくとも現時点で私は、ウィキペディアが百科事典である前提から〈純粋に「解説」を意味する節を設けることは無意味だ〉と考えます。

@Yasuさんには、節題を「解説」に変えるよりも、次のような積極的な編集をお勧めします。

1. 導入部や節「特徴」へ記述を移動する。
2. むしろ「概要」にふさわしい内容に書き直す。

返信 (@Assemblykinematics Nrliw様 宛) 必ずしも〈「解説」という節題が百科事典的でない〉というわけではありません。

導入部、本文、脚部の三構成部のうち〈本文は一般にすべて解説である〉ため、例えば〈項目を解説するすべての本文を、節「解説」内に記述する百科事典〉というのは妥当でしょう。

たまたま〈ウィキペディアでは本文をすべて単一の節内に収めない〉というだけです。

返信 (@Assemblykinematics 宛)

とはいえ @Assemblykinematicsさんが、おっしゃる通り、ガイドラインにおいて特別な扱いを受ける「概要」に関して、各ポータルやプロジェクトごとに個別のガイドラインを設け、こういった編集に即座に対応できるようにすることは私も望ましく考えるところです。

なお、代案として@Assemblykinematicsさんがおっしゃる「基本情報」の語に関しては、特に法人や食品に関する解説において〈書式化された一律一定の情報〉を指すことがもっぱらではないでしょうか。

• ウィキペディアもこれに習い、InfoBoxテンプレートの邦訳に「基本情報」や「基礎情報」という旨の語をよく用いています。

私は単に脚部の前に節「その他の特筆事項」を設けてしまっても、百科事典の構成として不自然でないように考えます（さすがに「雑記」だと一部の編集者がただの〈雑な記述〉をしそうなので好ましくないですが、下手に記事の頭にズルズル足されるより、雑記に当たる部分を設けてしまうほうが却って読者に優しいという判断です）。

いずれにせよ、概要にもなっていないはずの雑多な記述を、当該項目の「解説」と題することには、違和感を覚えます。--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年9月7日 (日) 01:43 (UTC)　利用者‐会話:シェン,アーナリー,ン,アーバァ.#発言の意図についてご確認でのやり取りに基づき、宛名を修正（取消線・下線部の部分）。--Assemblykinematics（会話） 2025年10月2日 (木) 21:35 (UTC)

まずシェン,アーナリー,ン,アーバァ.さんにお答えしますが、私の意図としては、「解説」という見出しが妥当であるから「概要」を置き換えているというよりも、内容が概要ではないのに「概要」の見出しが付いているのが不適切であるがゆえに、「概要」よりも適切と思われる見出しに変更している、というのが正確なところです。必ずしも「解説」という見出しが最良というわけではないことはすでにお断りしているとおりで、「歴史」など見出しとして適切な用語が他に見当たらない場合において、あくまで便宜的に「解説」を使っているのだとご理解いただければ幸いです。ご提案については、確かにそのような手段をとりうる場合も考えられますし、また実際にそのような編集をすることもある（最近の例としては、親不孝通り、スクエア・ワン・ショッピング・センター、宇出津町など）ことは申し上げておきます。

もっとも、私の見るところ、脚注や外部リンクなどを除くとひとつの節しかない（記事の対象について、歴史や特徴なども含め一節だけで本文を記述している）記事において、その節に「概要」という見出しが付けられているケースは少なくなく（私が編集に関わったものでは、カフェ・リエジョワ、米坂線雪崩直撃事故、能登丼、BMW GROUP Tokyo Bay、松尾八幡平地熱発電所などがあります）、このような場合において当該節の見出しを「解説」とするのはまったく不自然ではないと考えられます（ちなみに立山の歌や高崎市歌など、同様に本文の記述が一節のみの記事で、初版から当該節を「解説」としている例も存在します）。あわせてご理解を求めるものです。

なお「解説」よりもふさわしい見出しの候補としてすでにいくつかのご提案が出ていますが、「概要」と語感の似た「概説」「概略」といった用語は、概要（記事全体の要約）ではない節の「概要」を置き換えるのに適しているのかどうか疑問であり、個人的には「解説」のほうがまだましではないかとも感じます。引き続きご意見お待ちします。--Yasu（会話） 2025年9月7日 (日) 15:04 (UTC)

コメント - Wikipediaでは古くより「概要」というセクションが「とりあえず最初のセクションでいろいろと書く際に使うラベル」的な雑な扱われ方をしていて、記事全体の要約であるはずなのにそこにしか書かれていない情報があったり、全体の要約にしてはトリビア的なネタが混じっていたりする（たいていは、置き場に困ってこの節に放り込んでいる）ので、方向性としてはそれを是正しようとするYasuさんに賛成です。ただし、元はと言えばその節の記述が概要としての体をなしていないのが原因ですので、単純に節名称を変えていけばOKというわけでもなく、節の内容を再検討して適切な位置に記述を移したりするなどの工事が必要でしょう。場合によっては、そうした施術によって正しい概要に書き換えられるかもしれません。--ButuCC+Mtp 2025年9月8日 (月) 15:53 (UTC)

返信 (@ButuCC 宛) まさにそこです。

返信 (@Yasu 宛) 節題を「解説」に変えるだけでは、@Yasuさんがお察しの通り〈その場しのぎ〉でしかありません。

繰り返しますが〈比較的マシな節題〉へ変えるだけの〈みだりな節改題〉はお控えください。

1. おかしな概要を見つけたら、先ほど紹介したテンプレートを用いて指摘してください。
2. あるいは、@Yasuさん自身で相応しい内容に編集することが本来、望ましい姿勢でしょう。

もし「概要」というには不適切であったとしましょう。

1. 他方で、私が述べたように「解説」というのも矛盾するため不適切でした。
2. さらに〈解説が一つの節だけで終わっている記事〉というのは、内容不足か分割不足でなおさら不適切です。
3. 節「概要」が不適切だったとしても、同時に節「解説」も不適切で、節題を変えるだけでは何の解決にもならないのです。

@Yasuさんは今後ぜひ、問題を報告するか、解決するかして頂きたいです。--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年9月10日 (水) 08:23 (UTC)

返信 (シェン,アーナリー,ン,アーバァ.さん宛) 「先ほど紹介したテンプレート」とおっしゃるのはどのテンプレートのことでしょうか。話の流れから推測するにおそらく {{概要節がおかしい}} かと思いますが、お間違いないでしょうか。以下、正しいという前提で話を進めさせていただきます。

まずは個人的な事情で恐縮ですが、私は日々の調べ物にウィキペディアを活用しており、複数の分野の多くの記事を日頃から読んでいます。そうすると今回のように「概要」と名乗りながらも概要の体をなしていない節など、スタイルに問題がある記事が頻繁に目に入ってきますので、見かけたものについてはなるべく手を入れるようにしています。ただ、私も業としてウィキペディアを編集しているわけではないため、編集のために使える時間には限りがあり、ひとつひとつの記事をすべて理想的な状態にまで持っていけるだけの余裕が必ずしもあるとは限らないのが実情です。言ってみれば、100 点満点で 40 点程度の記事がいくつもある状態で、それらを全部 80 点や 90 点の状態まで改善して回るのは難しく、50 点や 60 点にするのが精一杯というときもあるということです。そういった場合に、「比較的マシ」な状態にするだけの「その場しのぎ」の編集はするな、「相応しい内容」に編集すべし、というのは、50 点ではなく 90 点の状態にする編集をせよ、というようなことかと思いますが、たとえ 40 点が 50 点になるだけの軽微な改善であっても、改善になっているのであればその編集は妥当なものといえると私は考えています。なんとなれば、ウィキペディアでは完璧でない編集も方針によって認められているのであって、記事を理想的な状態にする完璧な編集だけでなく「比較的マシな状態にする」だけの軽微な改善も受け入れられているからです。したがって私としては、今後も状況によっては「比較的マシな状態にする」だけの編集を行わせていただく可能性はあると思いますので、重ねてご理解を求めるものです。もちろん、時間的な余裕が十分あったり特定少数の記事にじっくり取り組める状況にあったりする他の編集者が、最初から完璧な編集を目指すことを否定するものではありません。

なお、ご意見からすると「解説」という見出し自体も不適切である（から改善にはなっていない）というお考えの様子ですが、「概要」という節はスタイルマニュアルにおいて使い方が規定されている一方、「解説」はそうではありません。すなわち、他のみなさんもおっしゃってくださっているように、記事の要約になっていないのに「概要」の見出しが付いている節はルール上不適切で修正の必要があるものの、「解説」という見出し自体は特段ルールに反しているわけではありません。よって、記事の要約ではない「概要」を「解説」に変更することは（わずかではあっても）改善に属する、というのが私の考えです。記事全体が解説なのだから「解説」という見出しでは意味がないというご批判は甘んじてお受けしますが、だからこそ「解説」に代わる意味のある見出しを現在みなさんが検討してくださっているのであって、少なくとも、不適切な「概要」をより適した見出しに変更すること自体は適切な編集であるとおおむね合意に至っているように見受けられます。シェン,アーナリー,ン,アーバァ.さんにもぜひ、「解説」よりも意味のある見出しの候補をお考えいただければ幸いです。念のために申し上げますと、ButuCC さんがおっしゃっているような、節分けの変更など抜本的な対応を行ったほうがよい場合については、最終的にその状態を目指すことにはむろん賛成ではありますが、どのように変更すべきか検討に時間を要する場合、その前段階として、先述のような「比較的マシな状態」にしておくステップを踏む可能性もあり、その際に「概要」に代わる見出しが必要になることも考えられます。ですので、いずれにしても、不適切な「概要」を置き換える見出しについて候補を用意しておくことは決して損にはならないと判断するものです。

最後になりましたが、{{概要節がおかしい}} については、私の力だけでは対処が難しい、他の編集者の考えも聞く必要があると感じたケースにおいては向後使用を検討したいと思います。--Yasu（会話） 2025年9月13日 (土) 14:58 (UTC)

返信 (@Yasu 宛) ご明察通り、話の流れもなにも{{概要節がおかしい}}のことでございます（まさか本心から「どのテンプレートのことでしょうか」と仰せのはずもなく、念のためでしょうから具に深くは追求しませんが）。

1. 先ほどから指摘しておりますが〈節タイトル・見出しはみだりに変えないでください〉という、技術的な制約に伴う方針についてはどのようにお考えでしょうか。
2. 節題を変えたところで、内容が〈雑多な記述の寄せ集め〉であることは改善しないため、いずれにせよ内容そのものの編集が必要であることについてはどのようにお考えでしょうか。
3. また、ご自身で内容の編集ができないならば、問題報告のためテンプレート{{概要節がおかしい}}を貼付したり、加筆依頼を行ったりする必要があることについてどのようにお考えでしょうか。
4. 誤解を招いているため訂正しますが「比較的マシな状態」とは〈概要節がおかしい〉という観点のみからであり、少なくとも「解説」という節は記事全体の構成の上では〈絶対的にマシではない状態〉になることを散々ご説明しましたが、お読み頂けなかったようですね。
5. そしてご自身で「意味のある見出しの候補をお考えいただければ幸いです」というほど〈適切な節題に検討がついていない〉にも関わらず、見出しをみだりに変えないという方針を無視し、適切な問題報告テンプレートを探すこともなく、内容をそのままに節の改題を複数回実行したのであれば、@Yasuさんは客観的に見て「望ましくない編集姿勢だ」と評されるかもしれん。

繰り返しますが、問題を別の問題にするだけであれば、他の編集者を頼ってください。ご存知の通りウィキペディアというものは、@Yasuさんだけが編集して回る必要はございません。仕掛ケであって今後も面倒を見る予定ならいざ知らず、@Yasuさん自身も納得はしていない中途半端な編集をするよりか、@Yasuさんを含む私たち一人ひとりが自信を持って行える、自身が得意とする貢献だけで、ウィキペディアというものはより良くなります。--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年9月14日 (日) 01:50 (UTC)

返信 まず {{概要節がおかしい}} については、「先ほど紹介したテンプレート」とおっしゃっているにもかかわらず、当議論におけるご発言の中で当該テンプレートに言及されている箇所が見当たりませんでしたので、確認のためにお尋ねしたものです。こちらの推測通りでお間違いないのであれば何よりです。もし万が一、実際にご紹介くださっているのを私が見落としていたのでしたらご寛恕ください。

本題について、以下個別にお答えします。

1. 適切でない見出しを適切なものに変更すること自体は、控えめに申し上げても特に問題があるとは考えていません。事実、当議論においても他の編集者の方々が「記事全体の要約になっていない説明をしている節のタイトルを「概要」以外のものに変更するのは妥当だと考えます」「どうしても節としたいのであれば同ガイドラインの観点からも概要以外の節名を考案しなければなりません」とのご意見をお寄せくださっています。「技術的な制約」とは、節の見出しを変更すると他記事からのセクションリンクが機能しなくなる弊害のことをおっしゃっているのかもしれませんが、節分けを変更して「概要」節を解消する場合などでもセクションリンクが切れてしまうのは同様であるため、そのような弊害があることをもって（記事の改善を意図した）見出し変更ができない理由にはならないものと思います。なお「見出しをみだりに変えない」という方針がある、というのは寡聞にして存じませんでしたが、もし実際にそのようなウィキペディアの方針が存在するのであれば、参考のためにぜひその方針ページをお示し願います。
2. ウィキペディアにおいて「雑多な記述の寄せ集め」とは、一般的には WP:TRIVIA に相当するような記述方法のことをいうように思います。歴史や特徴など様々な内容が同一の節で記述されている場合であっても、WP:TRIVIA と違ってしっかりと文章で書かれているのであれば、分割が望ましい分量であるといった事情がないかぎり、やはり問題となるものではないと考えられます。そもそも（正しく記事全体の要約となっている）「概要」節であれば、それ自体、様々な内容が記述された内容におのずとなるはずです。すなわち、「雑多な記述の寄せ集め」というのが「様々な内容が同一の節で記述されている」状態を指すのであれば、それだけをもって「内容そのものの編集が必要である」という前提が成り立つとは必ずしもいえないということになります。様々な内容を同一節で記述すること自体を制限する規定が、スタイルマニュアルなどウィキペディアのルール上に存在するのであれば話は別ですが、私が把握する限りにおいてはそのような規定は見たことがありません。かかる規定が実在するのをもしご存じでしたら、同じく参考までにお示しいただきたく思います。
3. これに関しては前回発言の最後にお答えしたとおりです。
4. ウィキペディアの記事はその全体が解説なのであるから「解説」という節は適切ではない、というご意見は承知していますが、前回の発言で述べたように、「解説」という語そのものが（「概要」とは違い）ウィキペディアにおいては特段の意味を持った節名として規定されていない以上、この見出しを使うことで「絶対的にマシではない状態」になる、というお考えには与しかねます。これは、おそらく「解説」という語（の意味合い）に対する認識の差が影響しているのかとも推測しますので、もしそうであれば意見の一致に至るのは困難であろうと思います。ただ、「解説」に代わるさらに適切な見出しがあればそちらを使うことはすでに繰り返し表明しているのであり、「解説」としたことが問題かどうかにいつまでもこだわり続けるよりも「さらに適切な見出し」を考案する努力をするほうが建設的ではないかとも感じます。「解説」では意味がないのであれば意味のある見出しをご提示いただきたい、と申し上げたのもその一環です。
5. まず「見出しをみだりに変えないという方針」という点については上記 1. で述べたとおりです。私が「適切な設題に検討がついていない」まま改題を行った、とのご指摘ですが、概要になっていない節に付けられた「概要」の見出しを他のものに変更すること自体が適切とされている以上、これらが不適切な編集であったとの認識はありません。少なくともそのような編集を行ったことで批判される理由はないものと思います。また、「歴史」や「特徴」など「解説」よりも適した見出しがあると判断したケースではそれらを使用していることはすでに述べているとおりです。「（節の）内容をそのままに」改題のみ実行することが「望ましくない編集姿勢」であるかどうかはコミュニティの判断に委ねますが、100 点満点で 40 点の記事を 90 点まで引き上げる編集のみならず、ただ 50 点にするだけの編集であっても、方針によって等しく受け入れられているということは重ねて指摘しておきます。

最後段のご意見について、「（私）自身も納得はしていない中途半端な編集」とおっしゃいますが、たとえ 40 点が 50 点になるだけの編集であろうと、わずかながらでもその記事の改善につながっているのであれば、それは意味のある編集であると考えています。もちろん、80 点や 90 点の状態まで引き上げるほうがより理想的であることは否定しませんし、その意味では 50 点の編集が「中途半端」とお考えになるのも理解はできますが、50 点であっても記事の改善になっている（少なくともそう信じて編集を行っている）以上、私としては「納得はしていない」ということはまったくありませんので、その点ご承知おきいただきたく思います。また、ウィキペディアの記事は私だけが編集して回るものではなく、必要なときは他の編集者を頼るべきというのは全くもっておっしゃるとおりですが、「自身が得意とする貢献だけで、ウィキペディアというものはより良くな」るというのが、もし「だからそれ以外に余計なことはするな」との趣旨でのご発言なのでしたら、そのようなお考えに対しては、多様な参加姿勢が受け入れられるというウィキペディアの精神に鑑みて懸念を表明するものです（私の杞憂であることを願います）。

以上をもってシェン,アーナリー,ン,アーバァ.さんへのお答えといたしますが、必ずしもご満足いただけるような回答ではないかもしれません。ご不満であれば、私に対するコメント依頼を提出していただいても差し支えありません。いずれにせよ、私としても他の方々のご意見を拝聴したいところではあります。--Yasu（会話） 2025年9月14日 (日) 15:06 (UTC)

すでに本議論において示しましたことを、またも示せと仰ったり、文の趣旨より字面を重んじたりするのはこちらの文章力の問題ですが、方針絶対主義を採って、私論やそのほかのドキュメント、日本語文章の自然な論理構造を超越するものとするならば、もう私とは方向の異なる哲学をお持ちのようですので、であれば私が申し上げるべきことはございません。--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年9月15日 (月) 08:51 (UTC)

私の意見が「文の趣旨より字面を重んじ」「方針絶対主義を採」るものであるというご指摘ですが、実際にルールの趣旨よりも字面を重んじているかどうかはともかく、ルールという明確な根拠をもとに意見を述べることになんらの問題があるとは考えておりません。少なくとも根拠を示さずに自らの個人的な感覚のみに基づいて意見するよりははるかに望ましい態度であると思います。もしルールの解釈が間違っているというのであればご批判は甘受するところですが、そうでない場合、正式なルールが私論を超越するのはごく当然のことであり、また「日本語文章の自然な論理構造」なるものにも明確な定義がない（個人によって考え方が分かれる）以上、遺憾ながらご意見に理由があると思料するのは困難であると感じます。

前後しますが「すでに本議論において示しましたことを、またも示せと仰った」というのは、私からご提示をお願いした件（みだりに見出しを変更しないという“方針”）のことかと思いますが、私のほうではそのような方針について当議論において言及された形跡が発見できませんでした。「示しました」とおっしゃるからにはかかる方針ページが実在するということになりますが、私が不注意で見落としていたのであれば深くお詫びいたしますので、今一度そのページをご提示いただけますよう、改めてお願いするものです。--Yasu（会話） 2025年9月27日 (土) 14:58 (UTC)

少なくとも私は『概要』を『解説』に置き換える行為は改悪だと思います。『概要』は『前』に置かれるものですが、『解説』は『後』に置かれるものだからです。

たとえば問題集の場合、『解答→解説』という流れですよね。Wikipedia記事においても、『注釈で述べるには長い文章量』の補足を述べるのが『解説』だと思います。つまり、『それまでに述べた説明の深掘り』が『解説』です。

違う名称にしたいなら、『導入』『前置き』『序説』等はどうでしょうか？少なくとも私なら、変える場合は『導入』を選ぶと思います。実際のケースによっても変わる筈なので、一般論としてですが。--~2025-64616-3 (会話) 2025年9月18日 (木) 14:53 (UTC)

ご意見は承りましたが、上記シェン,アーナリー,ン,アーバァ.さんへの回答で述べたように、「概要」という語がガイドラインによって使い方が決められている一方で「解説」はそうではありません。よって、少なくとも、不適切な「概要」の代わりに「解説」を使うことが改悪であるというべき理由はないものと思います。「問題集の場合、『解答→解説』という流れ」とのご指摘を否定するものではありませんが、ウィキペディアは百科事典を作るプロジェクトであり、問題集などとはそもそも考え方が違いますので、お考えのような構成がそのままウィキペディアに適用できるとは限りません。また、後段でご提示くださった「導入」「前置き」「序説」といった案についても、たとえば序論→本論→まとめのような構成をとる論文などでは有効かもしれませんが、百科事典であるウィキペディアにおいて「序論」や「導入」などといった節が必要であるとは考えられませんし、実際にスタイルマニュアルもそのような構成を推奨しているわけではありません。畢竟、縷々ご説明いただいたところはなはだ恐縮ではありますが、ご意見を是とすることはできかねます。--Yasu（会話） 2025年9月27日 (土) 14:58 (UTC)

@Assemblykinematicsさん、ButuCCさん、Kazu7878さん、Nrliwさん、Yasuさん、シェン,アーナリー,ン,アーバァ.さん

①『概要→解説』の置き換えは、特別:差分/106515433で述べたように、不適切であるので行わない。

②置き換える場合、『導入』『前置き』『序説』等を選ぶ。

③そもそも冒頭に有るべきではない、『とりあえず概要に入れておいた』ような内容は、別途『余談』セクションを作って、そちらに移動する。

とかはどうでしょうか？--~2025-26483-93 (会話) 2025年9月24日 (水) 05:27 (UTC)

私の場合、直すからには本腰を入れて内容の取捨選択や再配置、本来の概要となるように適切な要約の加筆などを施さねばならないので、そこまで手を施せる見込みがない場合は見かけても放置してますね。もっとも、よくあるパターンとして導入部の記述を一行のみ残し、残りの記述との間に概要節を挿入して概要にしてしまうというものがあります。その場合は簡単です。概要節を撤去し元に戻すだけです。導入部の長さについては様々な考え方があり、一定の目安も存在しますが、一行のみ残して二行目以降を概要にしてしまうのは不適切な場合が多いです。もともと要約として書かれていた記述ではないのですから。

余談ですがとある私論の一節に「日本語版の概要節という考え方」という記述を見つけました。導入部の記述方法と絡んで、日本語版において概要の体をなしていない概要が蔓延した経緯を漠然と語っています。そしてそれ故に、その修正は単純な節名の修正では済まないということも書かれています。--ButuCC+Mtp 2025年9月26日 (金) 17:00 (UTC)

こちらにも回答をしておきます。

1. 不適切な「概要」をほかの見出しに変更すること自体については、すでに複数の方から賛同が得られています。また上記のとおり「解説」という見出しの使い方を制限するルールはありません。したがって、「概要」を「解説」に置き換えることそのものが必ずしも不適切とはいえないものと思います。
2. 同じく上記のとおり、「導入」「前置き」「序説」といった類の見出しは、百科事典であるウィキペディアに適するものではないと考えられます。当該節の内容から判断して、たとえば「歴史」「特徴」など、節の記述に即した見出しがあれば、それを採用するのがよいと思います（私自身そうしていることはすでに述べています）が、歴史や特徴など複数の内容が記述された節であって、複数節に分割するほどの分量がない場合または他節に記述を移動するなどの方策がとれない場合においては、今のところ「解説」とするのもやむを得ない（少なくとも「概要」のままにしておくよりはまし）というのが私見です。
3. 「余談」という節を作ること自体を明確に禁ずるルールは把握していませんが、そもそも「余談」とは本題から外れた無駄話という意味であるため、百科事典であるウィキペディアの記事にあえてそのような節を設けるのはいかがなものかと思います。また「余談」という節は、スタイルマニュアルに反する雑多な内容の箇条書きとなる可能性が高く（Wikipedia:雑多な内容を箇条書きした節を避ける参照）、その点からいってもおよそ積極的に作成すべき節とは考えられません。なお、以前にシェン,アーナリー,ン,アーバァ.さんからも「その他の特筆事項」という案をいただいていますが、同様の理由でやはり好ましいものとは言いがたいように思います。

--Yasu（会話） 2025年9月27日 (土) 14:58 (UTC)

ここまでの議論を踏まえて尚、「概要→解説」を強行する行為には、問題が有ります。よって、事前にノートにて、セクション名の変更の提案を行い、合意形成を成立させた上で変更してください。慣例では1週間(168時間)以内に異論がなければ、それも合意形成の成立とされています。

万が一、『事前の合意形成が行われていない』『変更から1ヶ月が経過していない』ものを見かけた場合、『合意のない変更』として差し戻した(「概要」へと戻した)上で、『どういったセクション名が望ましいか？』をWikipedia:コメント依頼に出す事になると思います。--~2025-27426-53 (会話) 2025年10月2日 (木) 12:04 (UTC)

✕『変更から1ヶ月が経過していない』

○『変更から1週間が経過していない』

予測変換ミスを失礼しました。--~2025-27426-53 (会話) 2025年10月2日 (木) 12:07 (UTC)

コメント 返信が遅くなり恐れ入ります。個人的には「解説」はそこまで悪いものとは感じませんが、拒否反応を示す方がいる場合はWikipedia:合意形成に基づき、事前にノートで合意形成を図る方が無難かもしれません。なお

②置き換える場合、『導入』『前置き』『序説』等を選ぶ。 — ~2025-26483-93 2025年9月24日 (水) 05:27 (UTC)

との提案には反対です。これらはいずれも「解説」同様に不適切ではないでしょうか。特に『導入』については、議論をする際に導入部（冒頭部）と誤解する可能性があります。また、上で一つの案として「基本情報」を提案させていただきましたが、ご指摘を受けたようにいろいろと紛らわしいため、適切ではないとして取り下げたいと思います。

なお、基本的には個々の記事によって適切な節構成・節タイトルが異なるはずです。本井戸端の議論を経て、「ノート:ゲンキー#以前の状態への一部差し戻しについて」では節構成の再編について提案がなされ、議論がまとまりつつあります。基本的には「概要」節がWikipediaにおける「概要」として不適切な場合は、まず“記事全体の”節構成から考え直すというのがベターかと思います。全体の適切な節構成から、その記事にあった節タイトルに自然と収束していくと考えます。--Assemblykinematics（会話） 2025年10月2日 (木) 21:35 (UTC)

返信 (~2025-27426-53 さん宛) 記事全体の要約となっていない「概要」であっても「解説」に改めるのは不適切であるというご意見には理由がないことはすでに説明しました。そして、それに対する反論は今のところありません。よって、そのような「概要」を「解説」に改めることに問題があるとはまったく考えていませんし、したがって事前の合意形成が必須であるとも思われません。もっとも、ゲンキーの一件のように編集合戦となるのは本意ではないので、場合によっては事前にノートで確認する可能性も否定はしませんが、いずれにせよ「解説」という見出しはどうあっても不適とお考えであれば、まずはウィキペディアの記事において「解説」という見出しを使ってはならない根拠をお示しください。確たる根拠もなしに「解説」は不適切だと主張しつづけるのはいつまでも「納得」しないに類する態度であり、むしろそのほうが問題ある行為であると思料します。

なお、私自身はこの議論が始まって以降、「概要」を単純に「解説」に変更する編集は基本的に行っていない（行ったとしてもおそらくわずかな数）と認識していますが、記事全体の要約となっていない「概要」を「解説」にする編集に対してそのまま差し戻しを行うことについては明確に反対します。記事全体の要約ではない「概要」を他の見出しに改めること自体については、複数の方々が賛同している一方で反対意見は出ていないため、この点については合意に至っていると判断できます。すなわち逆に言えば、当該節が記事全体の要約ではない状態のままで「概要」に戻すことは明らかに適切な編集ではありません。ルール上もそのような節に「概要」という見出しは使えない（一方で、「解説」はそのような制限はない）ことは、この議論で繰り返し指摘してきたとおりです。--Yasu（会話） 2025年10月4日 (土) 14:58 (UTC)

口の悪い言い方をするなら「まだやってんのか」という印象です。そもそも（スタブ記事の）節の名前をどうするかというのは枝葉末節、重要なのは本文の充実だ、というスタンスは最低限持ち合わせるべきで、この議論自体、駐輪場の屋根な分色々言いやすいというだけで重要度としては低いと言わざるを得ません。この議論のために費やされた5万バイト分の労力が当のスタブ記事の加筆に向けられていたほうが遥かにWikipediaにとっては有用だったでしょう。Yasuさんは『40 点が 50 点になる』と仰っていますが、ちゃんと出典にあたって加筆するプロセスを経ずに1点でも上積みできると思わないほうが（精神性としては）よいのではないかと思います。

また、Yasuさんの『1.不適切な「概要」をほかの見出しに変更すること自体については、すでに複数の方から賛同が得られています。また上記のとおり「解説」という見出しの使い方を制限するルールはありません。したがって、「概要」を「解説」に置き換えることそのものが必ずしも不適切とはいえないものと思います。』については全面的に反対です。「概要」があまり良くない、というのはその通りかもしれませんが、「解説」ならばOKだ・優れている（から変えていい）という合意がありますか？実際、『概要』を『解説』に置き換える行為は改悪だと思います』（仮アカウントさん）などのコメントもあるではありませんか。私個人としては「概要」は微妙だけどまだ許容範囲、「解説」は違和感大、その他候補（『導入』『前置き』『序説』等）も違うかな、という感覚です。

ここまでの議論ではっきり言えることがひとつあり、「概要」「解説」「導入」「前置き」「基本情報」まあ何でも、これまで出された案では到底合意には至らないだろう、ということです。これはおそらく、そもそも記事の充実度が低く適切な節構成にできていないことに起因するのかと（Assemblykinematicsさんの直近のコメントなどはそのあたりを踏まえたものと認識しています）。ゲンキーなどは比較的内容がある記事だったので、中身を見て議論できたから解消できつつある、という状況かと思われますので、まずは記事の内容の充実から考えるべきです。

この前提のもと 提案 ですが、

・短い記事に使われる「概要」「解説」などの漠然とした節タイトルにおいて推奨できるものは現状ない。いずれを使うべきかについては特に定めず執筆者に任せる。

・いずれかを推奨できない以上、相互の書き換えは自粛する。※これは単にもめごとを起こさないための暫定処置です。

の2点が今決められる限界なのではないかと思われますが、いかがでしょうか。

もちろんこれは「概要」「解説」……のどれが望ましいかの議論を妨げるものではありません。が、結論がすぐには出ないであろうと思われますので、いったん中間の着地点を作っておきませんか？という提案になります。--Capsellanaut（会話） 2025年10月4日 (土) 00:27 (UTC)

この議論にずっと違和感を感じながら横目で見ていましたが、今般のCapsellanautさんのご意見に賛同します。記事全体を見て、「概要」として説明すべき内容か、導入部や他の節に持って行くべき内容か、全体を再構成する必要があるか、そういったことを考えずに「概要」の字面だけをおかしいとして書き換えるのは何ら記事の質の向上に寄与しません。むしろ新たな違和感の原因を作ることにもなりかねないものです。同様に、導入部が短いことをもって単純に==概要==を除去して導入部を増やそうとする編集をする方もしばしば見かけますが、これも杜撰な編集と考えます（当然、逆も然り）。もし概要になっていない概要節があって問題だというのだったら、記事全体を再構成せねばならないはずです。導入部にあるべき文章、概要節に分けるべき文章、他の節に移動すべき文章、全体のバランスや読みやすさも意識して、記事全体の適切な構成を考えるというのはそれなりの時間をかけて行う必要がありますし、それをするつもりがないのだったら、単純な節タイトルの書き換えだけで問題を解決できると思うべきではありません。このような単純な節タイトル相互の書き換えは行うべきでないという提案にも賛同します。--Takisaw（会話） 2025年10月4日 (土) 02:54 (UTC)

「導入部が短いことをもって（中略）導入部を増やそうとする編集（中略）（当然、逆も然り）」という点については既に私が述べたことと一方の面では被りますが、単に「概要」節の抱える問題だけでなく、「導入部の長さはかくあるべきか」という各人の考え方の違いがら生じる複雑な事情があります。最初に筆者が書いた状態を起点として、後から見た別の編集者が「導入部は簡潔であるべき」と考えた場合は導入部の文章を切り取って概要を作り、逆に「導入部が簡潔すぎる」と考える方の場合は概要節から文章を持ってきたりするのです。この場合の論点の主体は概要節ではなく、導入部についての意見の相違ということになります。これは概要節が「とりあえず最初のセクションでいろいろと書く際に使うラベル」として深く考えずに使われている実情に伴うものでもであり、「導入部から除く／導入部へ足す」という主目的を果たすうえで概要という字義を気にせずに文章を行ったり来たりすることに抵抗がなくなっているとも言えます。

もっとも、WP:MOSINTROに「導入部は記事全体の前置きであると同時に、それ自体で完結したひとつの記事であるべき」とあるように、そもそもの話として、概要は2つあるのです。「導入部」で小さな概要を構成し、「概要節」で改めてもう少し詳しい概要、そして本文に続く…という記事構成になるので、概要を二つも用意するほど内容がない場合は「概要節」による二回目の概要が不要になるのです。その点からいって、個人的には導入部削減を優先して概要節を無理に作るのは本末転倒であると考えます。--ButuCC+Mtp 2025年10月5日 (日) 09:45 (UTC)

仰るとおりで、導入部の長さと「概要」節の使い方に関しては、一応の目安が文章化されてはいますが、それとてルールやガイドライン間の整合が十分と言えないのではと思うところもあり、一方で導入部が定義文1文のみという記事も現状でも膨大に存在しており（その姿を好む利用者すら存在する）、wikipedia内でコンセンサスが取れているとは言えない状況と考えています。にも関わらずガイドラインの文面を見て、あるいは自分の考えるあるべき姿だったり、自分の考える問題解決だったりで、導入部の分量や「概要」節の追加／撤去・タイトル修正に強い拘りを持つ利用者がいます。本人はガイドラインに基づいて質の向上を図っているつもりなのかもしれませんが、新たな違和感の原因になったり、記事全体の節構成やバランスを崩してしまっていたり、雑多な記述を導入部や概要に持ってくることになったり、他の利用者にとっては改悪にしか映らないこともあるのですよね。だからこそ記事全体を見ない安易な書き換えや概要節の設置撤去は慎むべきと思うところなのですが。--Takisaw（会話） 2025年10月5日 (日) 12:21 (UTC)

返信 (Capsellanaut さん宛) ご意見は承りましたが、Capsellanaut さんを含め、みなさん「解説」という語に対するご自身のイメージだけで良い悪いを論じていらっしゃるように見受けられます。「私個人としては『解説』は違和感大」というだけでは、率直に申し上げて反対の理由になるとは考えられません。確かに「解説」が優れているという合意は今のところありませんが、「解説」は駄目だから禁止しよう、というご意見にも理由がないことも確かです。

なお、後段のご提案についてですが、繰り返し述べているように、ウィキペディアにおいては「概要」という語の使い方はある程度ルールで規定されています。したがって、その規定から外れた使い方をされている（記事全体の要約となっていない）「概要」節については、積極的に修正するべき（単純に見出しのみ他の語に置き換えるという手段に限らない）というのが私の考えです。「概要」以外の語が「短い記事に使われる……漠然とした節タイトル」に使われている例であれば、それをいちいち他の語に変更するべきではない、という点については同感です。

最後になりましたが、「まだやってんのか」というお考えはよく理解できますし、この議論に要した時間を記事の充実のために使えていたら、というのもまったくおっしゃるとおりです。しかし、確たる理由なしに「不適切な『概要』をより適切な節名に改める」という自由が阻まれるという事態は避けたいので、首肯できないご意見が寄せられた場合は、今後とも引き続き反論させていただく所存です。--Yasu（会話） 2025年10月4日 (土) 14:58 (UTC)

区切り2

流石に長くなりすぎてるので、区切り入れます。--~2025-27726-78 (会話) 2025年10月5日 (日) 06:57 (UTC)

~2025-27426-53です。@Yasuさん『事前にノートにて、セクション名の変更の提案を行い、合意形成を成立させた上で変更してください。慣例では1週間(168時間)以内に異論がなければ、それも合意形成の成立とされています。』と書いたのが読めませんでしたか？こちらは『事前に合意形成さえしていれば、「概要」→「解説」を容認する』と言っているのですよ。それのどこが『いつまでも「納得」しない』に該当するというのでしょうか。

むしろ貴方の『確たる理由なしに「不適切な『概要』をより適切な節名に改める」という自由が阻まれるという事態は避けたいので、首肯できないご意見が寄せられた場合は、今後とも引き続き反論させていただく所存です。』というスタンスこそが、『いつまでも「納得」しない』に該当する可能性が有ります。今までは兎も角、今回の議論で、『編集合戦になりかねない』事は認識されている筈です。それなのに、どうして『ノートで事前合意を取る』という手順を省こうとするのですか？

『事前にノートで提案されておらず、変更から1週間(168時間)が経過していない』場合は差し戻すと言いましたが、今回の議論を経てなお、事前合意プロセスを経ずに改称することは、『腕ずく』であるからです。そして単に戻すだけでなく、『正しい在り方は何なのか』を、提議すると言いました。腕ずく編集を戻してから議論するのは、議論の間に『腕ずく編集が既成事実になる(=腕ずくの成功体験になる)』と考える為です。

なお、『1週間(168時間)以内』という基準は、その間に異論がなければ、追認が成立していると考えるからです。言い換えれば、『事前にノートで合意形成を取った場合、つまり本来の場合は、まだ改称出来てないケース』の場合に、一旦戻すという話です。当然ながら、個別の議論の結果、改めて『解説』にすることは十分有り得るものです。『1週間(168時間)の間に異論がなかった』または『議論で合意できた』上で『解説』へと変更した場合、私はそれを支持します。

以上の点を踏まえた上で、『ノートで事前合意を行う事なく、「概要」→「解説」をしたい』と言われるのであれば、その時こそは明確な『いつまでも「納得」しない』に該当すると判断しますが、いかがですか。繰り返しますが、『ノートで合意形成した上で』「概要」→「解説」の編集を行ってください。貴方は『事前に合意形成を経る』という手順に『納得』しますか、しませんか。--~2025-27726-78 (会話) 2025年10月5日 (日) 06:57 (UTC)

「ウィキペディアで『解説』の見出しを使ってはならない根拠を示してください」というこちらからのお願いにお答えいただけないということは、そのような根拠は存在しないと解釈してよろしいでしょうか。「解説」を使ってはいけない根拠がないのであれば、そもそも事前の合意形成などは必要ありません。にもかかわらず「解説」の使用に一方的に合意形成を要求するのは、Wikipedia:腕ずくで解決しようとしない#いつまでも「納得」しないの「自分の主張や観点が否定された後もぐだぐだと固執し」「自説を通したいがために合意形成の方針を悪用」に該当する可能性があると判断します。したがって、根拠なく「解説」の使用を阻もうとする目的でそのような不当な条件を付そうとする行為こそが「腕ずく」であり、ガイドラインに照らせば当然無効ですから、従う必要はないと考えられます。

なお「首肯できないご意見が寄せられた場合は、今後とも引き続き反論」という発言について少々補足しますと、根拠のない主張が繰り返されているときに沈黙したままでいた場合、その根拠のない主張がまかり通ってしまう、そうなることは避けたいので「その意見には根拠がない」と指摘し続ける必要がある、との趣旨で述べたものです。根拠に基づいたご意見であれば同意できる場合もあるでしょう。「解説」についても、もしこの語を見出しとして使うべきでない具体的客観的な根拠が提示されるのであれば、なるほど確かに事前の合意形成が必要かもしれない、という考えに傾く可能性はあります。

最後に仮アカウントさんにお願いですが、もし今後も継続的に議論に参加するご意向がおありになるのでしたら、説明責任の観点からも、ぜひアカウントを取得のうえでログインして発言いただければと思います。ご検討ください。--Yasu（会話） 2025年10月5日 (日) 15:02 (UTC)

返信 (@Yasu 宛) 話の腰を折って申し訳ないが、

1. 私はすでに「もう私とは方向の異なる哲学をお持ちのようですので、であれば私が申し上げるべきことはございません。」として、本議論から脱しております。

   いつまでも付き合ってられないのでここで改めて明確に、賛否については棄権いたしましょう。

2. なお、@Yasu さんが〈概要説をみだりにいじる根拠〉として用いる〈Wikipedia:スタイルマニュアル/導入部#「概要」節を作る場合の注意〉は、あくまでガイドラインです。

   残念ながらしかし、言ってしまえばウィキペディアの方針でもルールでも何でもありません。

   • したがって尊重することが望ましく、言葉を選ばずに表現すると〈必ずしも絶対視して良いものではありません〉。

ウィキペディアには、規則主義を否定する根拠もありませんが、規則主義を肯定する根拠もありません。--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年10月12日 (日) 03:31 (UTC)

返信 (シェン,アーナリー,ン,アーバァ.さん宛) 「私はすでに……本議論から脱しております」と宣言しつつも私の意見に対しさらに論評されるのであれば、以前から繰り返しお願いしているとおり、「みだりに見出しを変更しないという方針」のページをまずご提示いただきたく思います。念のため申し上げておきますが、もしも万が一、そのような方針は実際には存在しないにもかかわらず存在するものと誤解して発言されたのでしたら、その旨ご申告いただければ、それ以上追及はいたしません。もっとも、「ウィキペディアには……規則主義を肯定する根拠もありません」とおっしゃる方が、一方では「みだりに見出しを変更しないという方針」を論拠とされているのは、率直に申し上げて理解が追いつかないところではあります。

なお、Wikipedia:コミュニティ・ポータルには「ウィキペディア内での方針やルールは方針とガイドラインに書いてあります」と明記されており、またその方針とガイドラインのページには WP:RULES というショートカットもあることから、ガイドラインもウィキペディアの公式なルールの一部であると解することができます。さらに、方針とガイドライン（このページ自体も方針のひとつです）では「編集者はガイドラインに従うように推奨されます」とされているため、特段の理由がないかぎり、ガイドラインであるスタイルマニュアルの規定に沿うようにすることは、少なくとも否定されるような行動ではないはずです。「特段の理由」が本件に関してはあるとお考えなのでしたら、その「特段の理由」をお聞かせください。また、下の ~2025-28570-74 さんへの返信で、Help:セクションがガイドラインであるかのような発言をされていらっしゃいますが、同ページはヘルプページであってガイドラインではありません。今一度、よくご確認いただけますようお願いします。--Yasu（会話） 2025年10月18日 (土) 14:58 (UTC)

『解説』については、現状のルールで規定されていないものと認識しています。制限するルールがない代わりに、妥当性を担保するルールもないということです。(もしも『解説』の妥当性を示す規定がありましたら、教えてください。)

そして『ルールで規定されていない』という点では、『前置き』等の本議論で挙げられた案も等しいです。つまり、『「概要」より「解説」がいいと置き換える』行為と、『「概要」より「前置き」がいいと置き換える』行為は、『規定されていない呼称への変更』という点で全く同じです。『「解説」から「前置き」に置き換える』行為と、『「前置き」から「解説」に置き換える』行為は、『どちらが先だったか』という違いでしかありません。

よって、本当に『解説』の方がいいと思うのであれば、『「概要」節が全体の要約になっていない場合、暫定的に「解説」へと改称するルールの提案』を、しかるべき手順を踏んだ上で提案してください。そのルールを成立させた上でなら、貴方の行為は妥当性があると言えます。逆に、ここまでの議論で『解説』への異論が少なくない事を認識しているにも関わらず、『それまでの数週間、数ヶ月、数年に渡って「概要」だったケースで、事前確認もせずに「解説」へと置き換える』行為は、『あくまでも現時点のルール上は(「解説」名称の規定のない状況下では)』問題視されうるものだと思います。

尚、『そもそも立項時から「解説」だったケース』や、『「概要」節のない状況下で、「解説」節を設けたケース』、『置き換えの前後を問わず、「解説」への置き換えに対する合意形成の成立しているケース』においては、『概要と呼べる内容になっていない限り』解説のままでいいと思います。

私見にはなりますが、『解の説明』である『解説』ではなく、シンプルに『説明』ではいけないのでしょうか？『解の説明』であれば、『解＝それまでの説明』を、更に(深掘りして)説明する形である必要が有ります。問題集の解説ならば、『「解答」という解の説明』ですね。つまり、最初の節名に使うのは、『誤用』と言えます。

しかしながら『説明』は、『説を明らかにする』であり、『読者の主題に対する理解を助ける』という意味しかありません。よって、最初の節名に使うことへの支障はないと考えます。

Wikipediaの記事は、その全てが『何かに対する説明』です。例えば出典は『何を参考に書かれた記事であるか』の説明です。故に、あくまでも個人的には、『概要とは呼べないが、どう呼べばいいか分からない節』は、『説明』とだけ呼べばいいと思いますが、異論は有りますでしょうか？異論がないようであれば、今後は『解説』ではなく『説明』を採用していただければと思います。『全体の要約になっていないのに、全体の要約だと誤解させる』状態が、問題であることは確かなのですから、『誤用』さえなければ文句は言われないように愚考します。

末筆になりますが、特に強く返信を要請されなければ、これ以上のコメントを行うつもりはありません。また、Wikipediaは義務ではないので、その要請に必ずしも気付けるとも限りません。一つだけ言えるのは、井戸端への読み込みが終わった後は、このページを見る可能性は低いということです。それでは、失礼いたします。--~2025-28570-74 (会話) 2025年10月12日 (日) 13:43 (UTC)

この議論において@~2025-28570-74さんは初めましてと存じますが、ひとまず@~2025-27726-78さんと同一人物とみなします。

返信 (@~2025-28570-74 宛) 申し訳ないのですが、

1. おっしゃる〈解説〉と〈説明〉に対する認識は、かなり独特かと考えます。どちらかというと〈とき、ほぐす【解き、解す】〉の意味でむしろより詳細な説明に対する表現かと[1]。
2. また「ウィキペディアは全体として〈説明（解説）〉で構成されているから、それゆえに見出し語は〈説明（解説）〉で良い」というのがいかに暴論かについては再三申し上げるところです。
   • とある節の見出しが〈説明（解説）〉としかいいようのない場合、その内容で節分けをすること自体がガイドライン「Help:セクション」を尊重しておらず、見出しの付け方の問題ではないでしょう。

IP利用者である時点で、首を突っ込んでみただけでしょうし返答は求めませんが、表記法をガイドライン以上の拘束力を以て規定することにつき反対です。--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年10月13日 (月) 08:40 (UTC)

返信 (~2025-28570-74 さん宛) おっしゃるとおり、「解説」という見出しが妥当であるとしてこれを推奨するような規定が存在するとは承知しておりません。ですので「解説」よりも優れた見出しがあるなら提案してほしいと以前から申し上げていますし、また個人的には「歴史」など節の内容に即した見出しがあればそちらを使っていることもお伝えしています。しかしながら、逆に「解説」を「制限するルールがない」のであれば、制限がある「概要」が不適切に使われているケースを置き換えるのに何ら支障がない（事前の合意や確認の必要がない）ということは、これ以上繰り返すまでもないものと思います。また、「前置き」は百科事典であるウィキペディアの見出しとしてふさわしくないと私が指摘した一方で、「解説」に反対の方はそのような観点からの意見ではなく、単にご自身の感覚では「解説」という語がしっくりこない、といっただけの主観的な理由にとどまっているように見受けられる、というのもすでに述べたとおりです。今回のご意見も「問題集の解説」という、百科事典とはおよそ無関係の例を引き合いに出されていることから、「解説」の見出しに問題があることの根拠になっているとはあいにくながら判断できかねます。

ちなみに『日本国語大辞典』では、「解説」とは「物事をわかりやすく説明すること。また、その説明。」と定義されており[2]、おっしゃるような「解の説明」というよりもむしろ、シェン,アーナリー,ン,アーバァ.さんご指摘のように「詳しい説明」と理解すべきと考えられます。したがって、ご提案いただいた「説明」については、詳しい説明（解説）か単なる説明かの違いだけですので、私としては特に反対するものではありません。ついては、「概要とは呼べないが、どう呼べばいいか分からない節」に付す見出しとして「概要」の代わりに「説明」をお使いになりたいのでしたら、ご随意に置き換えされればよろしいかと思います。ただし、そのような場面では、私自身は「解説」を使うであろうと思いますが、それをごらんになって「事前合意や確認がない」といって「説明」にさらに変更するようなことはお控えいただけますよう、ご理解を求めるものです。

最後になりましたが、強く要請されない限りこれ以上コメントしないとのご意向については承知しました。しかし、これはシェン,アーナリー,ン,アーバァ.さんについても同様ですが、「解説」という見出しが適切ではないことの具体的客観的な根拠をご提示いただけないまま議論から離脱されるのでしたら、「解説」の使用についてもはや反対がないものと理解しますが、それでよろしいでしょうか。であれば、この議論もようやく終わりが見えてくることになりますので、私としても歓迎するところです。--Yasu（会話） 2025年10月18日 (土) 14:58 (UTC)

シェン,アーナリー,ン,アーバァ.さん（以下長いのでシェン何とかさん）が、しゃしゃり出てこなければ9月5日で終わっていた話題です。おおむね、Yasuさんの主張に間違いはなく編集の強行もしていません。ただし、利用者からすれば「概要」であろうと「解説」であろうとそんなもの心底どうでもいいです。どちらでも意味が通るので、「概要」節が絶対にその記事にまとめでないといけないとするようには読み取れないので、「概要」か「解説」かは好みのレベルです。

再三申し上げたとシェン何とかさんは言っていますが、読み返してみて下さい、シェン何とかさんに同意する意見など有りません、1人で勝手に言っているだけです。というよりこの話題に限らずシェン何とかさんは文章読解力が低く観点がズレていて、あなたが出てくると話が面倒になるだけです。私も全く人の事は言えないのですが、話を面倒にしておいてその後、「ご勝手に」「あなたがやって下さい」など無礼な言葉を残して去っていくだけですよね？正直、あなたのこれまでの行動全般に対して色々と言いたい事はあるのですが、そういう場ではないのでここではやめておきます。ただ、この場において、あなたに同意している人などいないとう事は理解した方がよろしいかと。そして論点がズレていて迷惑です、「もう私とは方向の異なる哲学をお持ちのようですので、であれば私が申し上げるべきことはございません。」と無礼な事まで述べて去ったならもう二度と出てこないで下さいな。

他人の批判だけで終わるのもどうかと思うため、一応述べますが、そもそも概要節に相当するものが必要なく、「概要」や「解説」に書かれている文章を切り分けるというのは記事が分かりにくくなるだけなのでそれもどうかと思うのです。それであれば「概要」が問題あると思うなら「解説」にすればいい。どっちでもいいです。日本語版の日本料理と英語版の日本料理と見比べて、冒頭に情報がまとめられている英語版に比べ情報が散逸している日本語版は何を説明しているのかわからない状態です。これが概要なり解説を分けてしまう問題点です。導入部が長くて何か問題ありますか。単純に「概要節」の概要の文言を取り除いて導入部にする事の何が問題ですかって感じですね。文章のつながりや情報の重複に気を付ければ、情報を切り分けるよりよほど読者にとって読みやすい記事になるでしょう、まともな概要節であればですが。大事なのは読者の視点で、編集者の好みでどうこうする話ではないでしょう。概要を解説に変更するのも編集者の好みのレベルですが、だからといってそれが記事破壊になっているかといえば、そんな事もなく、それを何故行ったかの説明もまっとうですので、「ずっと概要だったんだから概要の方がいい」なんて主張よりははるかにマシです。概要と解説のどっちがいいかなどと議論するのは無駄で、こんなことで同意を取るだとかバカらしいにも程がある、時間と空間の無駄遣いです。時間をかけて概要を切り分けるなんてのも私からすれば愚行としか思えませんが、その辺りはその記事別に編集者同士で好きにすればいい。概要じゃないとダメだ、概要じゃダメだ、と決めるものではないでしょう、こんなの。そして冒頭の記事の書き方に、それでもルールを作りたいなら、ノート:スタイルマニュアル/導入部]でやって下さい。まあ、揉めるだけで何も決まらずに終わりそうですが--田村悠（会話） 2025年10月13日 (月) 15:51 (UTC) 英語版記事へのリンク冒頭のコロンが欠落していたため追加させていただきました。--Yasu（会話） 2025年10月18日 (土) 14:58 (UTC)

返信 (@Yasu 宛) すみません。言い過ぎました。--シェン,アーナリー,ン,アーバァ.（お気軽に会話ページへご連絡ください） 2025年10月15日 (水) 11:44 (UTC)

返信 (シェン,アーナリー,ン,アーバァ.さん宛) ご発言のどの部分について「言い過ぎました」とおっしゃっているのかわかりかねますが、上記のお願いに対するご回答を含め、適切に対処していただけることを希望します。--Yasu（会話） 2025年10月18日 (土) 14:58 (UTC)

返信 (田村悠さん宛) 「おおむね、（私）の主張に間違いはなく」「概要を解説に変更するの……を何故行ったかの説明もまっとうです」とのコメント、たいへん心強く拝聴しました。私の立場をご理解いただき感謝します。一点のみ、「「概要」であろうと「解説」であろうと……どちらでも意味が通る」「概要を解説に変更するのも編集者の好みのレベル」とのご意見ですが、私としては、「概要」と「解説」では意味合いが違い、また「概要」という見出しの使い方がスタイルマニュアルで規定されている以上、その規定から外れた使い方は修正すべき、という考えですので、単に「好み」で変更しているわけではなく、スタイルマニュアルに沿うという確たる理由があってやっているのだということをあわせてご理解いただければ幸いです。--Yasu（会話） 2025年10月18日 (土) 14:58 (UTC)

エラー表示の対応（質問）〔日付を year と date に分けずに ……〕

区切り1

彼岸のページなどで標記のエラー表示に気づきました。以下はどなたか、おわかりになりますか？　おかげさまで修正の方法を学べたのですが、自動通知をもらえたら自ら修正できるので助かります。

うっかりしていて当該のページをウォッチリストに入れていなかったものか、通知を受けていません。

1. ボット処理で修正の対応があるのか、手動で修正が必要か。
2. 改変の影響範囲[3]には、どのように通知がある・あったか。
3. ウォッチリストに入れておくと、版が変わったと通知がくる仕掛けかどうか。

エラーの文面

• 〔日付を year と date に分けずに date にまとめて記入してください。（説明）〕
• ご参考：エラーの見た目
  • 「彼岸」の出典 [58]の場合（太字部分の文字は赤色）。

島村鬼吉 編『深川よとみ集』多少庵、1846-弘化3年 エラー: 日付を year と date に分けずに date にまとめて記入してください。（説明）。国立国会図書館書誌ID:233515。「松尾芭蕉の150回忌追善供養句集」

改変に気づかずわざわざエラーを出し続けるのも情けないです。 --Omotecho（会話） 2025年9月22日 (月) 08:00 (UTC)

西暦と和暦が重複していたので、和暦を除去しました。 --Kto2038（会話） 2025年9月22日 (月) 12:06 (UTC)

@Kto2038さん、コメント有り難うございます。ご指摘はテンプレートを使っている個別のページのことでしょうか？　それともテンプレートの改変ですか？

ご参考まで、国会図書館のデータベースなど情報源のデータ形式をみてもらうと、西暦を使っていなかった時代の資料の発行年（yearの変数）の書き方は一意ではありません。

• 和暦西暦を併記したもの
• 写本で書写の和暦の日付（推定）を当てたもの
• 和暦のみ

それら情報を拾うのに和暦西暦を date と year に分けて併記すると都合が良いのです。以前はエラーは出ていませんでした。

書誌情報で和暦と西暦を1件の引数にまとめ分けないという根拠は話し合いがあったのでしょうか。Yearなど出版物につきものの引数ですから、それまでとルールが変わるなら変わるで知らせてもらわなければと困ります。

突き詰めると、西暦に換算して書けという指示でしょうか。私見ながらウェブブラウザの検索窓に和暦を入れて検索をかけると、西暦に換算します。その手間をヒトがしなくてすむ処理をして、西暦がデータ元にない資料も和暦だけ書けば済むと良いです。-- 誤字に横線、訂正Omotecho（会話） 2025年9月22日 (月) 19:57 (UTC) ／ --Omotecho（会話） 2025年9月22日 (月) 18:29 (UTC)

ウィキペディアの出典テンプレートは現在和暦表示に対応していません。year と date を和暦に統一しても「エラー: 日付は和暦ではなく西暦を用いてください」というエラーメッセージが表示されます。和暦をエラーとして扱う議論についてはTemplate‐ノート:Citation/showdate#更新提案_2025年7月をご参照ください。--火乃狐（会話） 2025年9月22日 (月) 21:53 (UTC)

コメント 私見です。元号（和暦）を出典テンプレートに書く引数を作ってください。日本語資料以外にも元号は付いてきます。よしんば裏をかいて未定義の「1」に書いて気がすんだところで検索にヒットしないなら無駄であり、CSに移すときに切り捨てると予見します。

前述と重なったらすみません。和暦として扱っておられますが、元号#コンピュータでの処理を参照され、元号と捉え直してもらえませんか。

• 日本の公文書を調べるなど、元号の利便性は高いです。
• 歴史文書は日本ほか、中国、韓国も使います。古代ローマなども皇帝の名前に年数をそえます。
• 英語圏で「エリザベス2世の何年」など現代は見ませんし、記事内に書き下します。
• エラーのカテゴリにまとまった要修正のページ群の対応もそうですが、検索で元号がヒットするようにしてほしいです。
• 先行例は国立国会図書館データベース、GLAM機関はどうですか？　元号をすべてコメントアウトする処理だけはご勘弁ください（後述）。

お礼が後先になりました。

@火乃狐さん 助かりました、探していた情報です。「CS1移行に都合が良い」とのことが強い根拠のようですね。また元号を出典テンプレートに入れる利用率はとても少ないはずですし、では入れるか入れないか、お示しのリンクだと2012年の投稿があるのですね。

@FlatLanguageさん、おつかれさまです。視点の問題です。これまで元号が議論にならなかったなら、議論しましょう。コメント依頼という書き方が悪かったなら、影響を受ける人への働きかけはポータルなど、絞り込むと声が拾えませんか？　

FlatLanguageさんがご指摘のコメント依頼ならびにその対処とは、コメント依頼とは9月10日の件を指しておられるなら、私の感覚だとまだ2週間ですね。広く合意を得たという判断の根拠は何でしょうか？　これまで一度も俎上に上がらなかったから？

• モジュール‐ノート:Citation/CS1#モジュール更新提案（2025年9月） - 出典表記形式1（CS1）・和書用出典表記形式（CS-ja）テンプレートを実装するモジュールの更新提案--2025年9月10日 (水) 04:36 (UTC)

すでに対処に進まれているのですか？　2025年9月のモジュール‐ノート:Citation/CS1#モジュール更新提案（2025年9月）を見ました。少し待ってくださらないかと感じます。

言いわけです。元号を使いたがる私など技術系に明るいわけではないため、エラー表示が出ても、何がどうダメかわからないのです。元号が無駄、邪魔という感覚はありませんし、システムにどんな負担や害を生むのかピンときません。モジュールを変えるとは、何を指すのか今回、モヤっとわかりました。--Omotecho（会話） 2025年9月23日 (火) 05:21 (UTC)

どうすべきかという点について強い意見は持っていませんが、とり急ぎエラー解消という観点で「特別:差分/106558487/106561484」の編集をしました。 --Kto2038（会話） 2025年9月22日 (月) 22:07 (UTC)

date 引数の形式については、「Template:Cite_book/doc#各引数の解説_2」に「YYYY-MM-DD・YYYY年M月D日・YYYY年M月・YYYY のいずれかの形式で」とあります。 --Kto2038（会話） 2025年9月22日 (月) 22:22 (UTC)

2012年ごろに{{Citation/showdate}}・{{Citation/showdateEN}}が作成されて以来、和暦の入力に対応していたことは一度もありません。{{Citation/showdate}}の方は正しくエラーをだしていましたが、{{Citation/showdateEN}}は|date=のみを出力するということになっていました。Template‐ノート:Citation/showdate#更新提案_2025年7月により{{Citation/showdateEN}}でもエラーが出るようになり、この変更はWikipedia:コメント依頼でも告知されていました。--FlatLanguage（会話 / 投稿） 2025年9月23日 (火) 04:25 (UTC)

返信 (Omotechoさん宛) モジュール‐ノート:Citation/CS1#モジュール更新提案（2025年9月）がこの話とどう関係があるのでしょうか？私が言ったのは特別:差分/105551041これです。「合意」についてはWikipedia:合意形成を参考にしてください。もう一度言いますが出典テンプレートで和暦を入力/表示する機能はいままで一度も作成されたことがありません。無いものを「改変」したり「切り捨てる」ことはしません。必要だと考えるなら自分で実装してください。暦の換算は大変なので、私はやるつもりはありません。--FlatLanguage（会話 / 投稿） 2025年9月23日 (火) 05:36 (UTC)

コメント こんにちは。技術関係に詳しくないので恐縮ですが、西暦と和暦の併記は可能だったとおもいます。というのも、この編集をした時、特にエラー表示は出ていなかったので。なお、後日に見直してエラーに気づいてはいたのですが、私の感覚では、明治以前の元号はともかく、「令和」の前が「平成」、そのまえが「昭和」で、「大正」「明治」にさかのぼるというのは、日本では一般的な知識としてわかりやすいと思っています。ですので、エラー解消の措置は行いませんでした。必要であれば、自身の編集を修正するのはやぶさかでありませんが、『西暦が一般的であり Mediawiki として揃える』という考えであるならば、疑問を感じます。--温厚知新（会話） 2025年9月23日 (火) 08:34 (UTC) 差分表示を入れ替えました。--温厚知新（会話） 2025年9月23日 (火) 08:51 (UTC)

• （和暦の出力対応の必要性）ここはウィキペディア日本語版であって日本版ではない、という細かいツッコミはともかくとして、ガイドラインのWikipedia:出典を明記するには「刊行年は西暦を用いる。元号を使う場合は西暦を併記する」とあります。したがって、あくまでも西暦がメインであり、西暦のみ入力した場合に和暦も表示する機能は不要だと考えられます。
• （和暦の入力対応の必要性）同じガイドラインにより、和暦のみ入力する場合は対応が必須ではありませんが、和暦併記での入力には対応する必要があります。ただし、西暦と和暦が正しく同じ日付を指していることの検証は西暦から和暦への換算が必要なので、実装が困難です（換算テンプレートである{{和暦}}の複雑さを見ればわかるかと思います）。また「1928-昭和3年」「1909年（明治42年）12月25日」など編集者がそれぞれ異なる書式で記入していて、そのままでは対応が不可能なので、実装するとすれば和暦を分けることになります。
  • たとえば、|date=（または|year=）は西暦で入力必須、|date-japan=（または|year-japan=）は和暦で省略可、かつ両者の対応が検証されない形であればあるいはできるかもしれません。上記の例では|date=1909年12月25日|date-japan=明治42年12月25日になります。和暦も日付まで入力しているのは、旧暦を使用すべき時期があるためです。
  • 和書を洋書モードで記載してしまった場合を除き、洋書モードでの和暦入力はほぼみられず、和書モードのみの対応で十分かと思います。
• （新しいエラーかどうか）温厚知新さんが示した差分はメタデータが間違っている（rft.date=1909年（明治42年）12月25日のようになり、メタデータに必要な1909-12-25の書式になっていない）ので、前からダメだったのがエラーメッセージが表示されるようになったにすぎません。--ネイ（会話） 2025年9月24日 (水) 02:56 (UTC)

  @ネイさん、整理をありがとうございます。何がなんでも元号を使わせろと申しているのではない点を汲んでくださり助かります。

  @FlatLanguageさんが元号の西暦換算は難しくて手を出さないと言われた意味が、ようやくわかりました。

  CS2移行の日程

  ところで、CS2移行という事業はどれくらいの急務なのか、どなたかお分かりにならないでしょうか。

  遅滞すると他言語との対応など、重大な影響が及びますか？ なにごとにも〆切があるし、とても複雑で神経を遣う作業の邪魔をするのは本意ではないです。

  もちろん工程を優先して、あとで元号用の引数を調整する、それが最善ならば議論再開という工程を織り込んでくださらないでしょうか。

  工程優先の場合は、何月ごろに議論再開か、見込みを教えていただけませんか？　

  いったん議論中断、繰り延べのほうが現実的かもしれないですね。細かいことながら「和暦」はWIki用語としても、仮の引数「|date-japan=」は、別の文化圏の元号も書ける（選択肢）とどのくらいの人が便利なのか、手間と効果が評価できずお恥ずかしい。

  別件で、存外、「日本語」を離れるとややこしいです。

  • ア 元号 （Q256408）
  • イ 日本の元号 (Q24706)
  • ウ 中国の元号 (Q845538)
  • エ 即位紀元 (Q17150160) → en:regnal year（英語版）

  • 言語間リンク → （エ）英語版 regnal year → （ア）日本語版 [[:元号]」

  --Omotecho（会話） 2025年9月24日 (水) 06:39 (UTC)
  

  日本版である点のリマインドはありがたく、改めて多文化をうまく取り入れてきた文化圏だと感じます。

  --Omotecho（会話） 2025年9月24日 (水) 06:39 (UTC)

  （日本以外の年号）即位紀元は洋書でもほとんど書かない（大体は西暦で事足りる）一方、中国、韓国、ベトナムの元号は書くこともあるので、拡張性を残してdate-japanではなくdate-regnalなどとしたほうがいいかもしれません。どれにしても検証はしないので、引数名の違いにすぎません。

  （CS1移行の重要性）出典テンプレートの主な移入元である英語版は12年前にCS1に移行しており、主要な出典テンプレートにおける他言語版からの機能追加はほとんどできていません。近年になって細々と移行が進められていますが、Cite bookなどは影響が大きいのもあってまだ移行が済んでいません。日本語版独自である和書モードはともかく、洋書モードは他言語版の追加機能にもある程度対応しなくては翻訳時に不都合が生じます（現状はCite book→Cite book2のように書き換えることで表示が直りますが、編集者全員がそうしているわけではなく、書き換え自体が手間です）。変更点がどんどん溜まるという意味では急を要するし、長年このような状況になっているという意味では急ぎではありません。

  （移行工程の締め切り）ウィキペディアに締め切りはありません。移行を主導してきた編集者の方はある程度の目安を示せるかもしれません（今回の件は主に和書モードに影響を与える議題で、私はCSjaにはあまり関わっていないので存じ上げません）が、議論によって長引いたり早期に移行できたりすることは当然あるでしょう。--ネイ（会話） 2025年9月24日 (水) 10:12 (UTC)

意外とできそうだったので昨日から仕様を考えていますが、特別:差分/106582003・特別:固定リンク/106712914こんなものだと思います。Wikipedia:表記ガイド#西暦・和暦に準じて丸括弧を使って併記し、余分な0などを入れずに正確に入力する必要があります。|date=でのみ対応しています。グレゴリオ暦しか対応していないので、1872年（明治5年）以前ではエラーになります（そんな昔の日付はほとんどの場合|date=ではなく|orig-date=に入力すると思います）。和書モードかどうかは（まだ）判定していません。|df=による変換や、日付範囲には対応していません。

別の引数を使うというのは私には仕様も実装も不明です（|date=Winter 2024–2025 |date-japan=令和7年という入力に対してどう対応するのか）。ほかの暦への対応というのは机上の空論だと思います（現状ですらグレゴリオ暦/ユリウス暦に部分的に対応しているに過ぎない）。

--FlatLanguage（会話 / 投稿） 2025年9月24日 (水) 13:19 (UTC)

私の案は西暦以外の検証を諦める前提なので、単純に「<date引数の表示>（<date-regnalをそのまま出力>）」と表示します。極端な話、|date=31 December 2019 |date-regnal=康熙55年閏3月19日で「2019年12月31日（康熙55年閏3月19日）」のようにまったく別の日付を表示させることもできてしまいますが、実装の複雑さをできる限り減らした結果となります。--ネイ（会話） 2025年9月24日 (水) 13:40 (UTC)

日付が常に正確に入力されることは全く期待できないので、何らかのチェックは必要と考えています。博物館や研究室で歴史資料の原本/写本を直接読んで記事を書く人はそんなに多くなく、多くの場合現代の出版社が編集して出版した物を参照すると思うので、旧暦の入力に大きな需要があるとは思っていません。--FlatLanguage（会話 / 投稿） 2025年9月29日 (月) 15:17 (UTC)

一応、職業プログラマ、かつWikipediaの出典系のテンプレートも何度か使ってきての意見です。実装するのであればFlatLanguageさんの意見に賛同…つまりチェックは必須と考えます。デタラメな値が入力可能というのは美しくない。美しくないという言い方だと美意識のように見えてしまいますが、入力UIとして間違った実装の仕方という事です。バグが出る、エラーが出るから、エラーが出ないようにエラーチェック自体しないようにしようというのは（納期や予算の関係で）現実に密かに行われていたりするのですが、もちろん無責任で許されざる行為です。そして、こういった世界では和暦、元号は嫌われ者で、職業プログラマにとっては公的な世界からは和暦を消せという考えが圧倒的。「日本国版」であれば和暦を求めるというならまだわかるのですが、世界標準のメディアのあくまでも「日本語版」において和暦が何故必要なのか、今のところ説得力のある意見が出ているようには見えません。改元の度に誰かが手を入れるんですか？必要とする人がどれだけいるのか、実装したとしてどれだけ有用なのか、それらを考えると実装そのものに反対です。やるなら勝手にやって下さいではなく、後々面倒な遺産になるので、やらない方がよい案件と考えます。--田村悠（会話） 2025年9月29日 (月) 15:59 (UTC)

Module:Citation/CS1/Date validation/sandboxのgengou_data[]のテーブルに追加すれば更新できるので、もし私がいなくなっても改元時の更新はできると思います。--FlatLanguage（会話 / 投稿） 2025年9月30日 (火) 13:08 (UTC)

私の「日本では…」の発言は「日本語版」を考えていました。日本語版であればこそ、読者はほかの言語ではなく日本の言葉で読むことを考えてのものです。データベースを作るのであれば西暦だけで事足りるものと思いますが、元号があれば時代背景がわかりやすく、出典の信頼性などを判断する要素になると私は思っています。なので、コメントアウトをして元号を入力しても、あまり意味がないと思います。元号の実装が難しいことは、素人ながら理解できます。＜date因数＞はCS1(CS2)？でチェックして、＜date-regnal＞は補足として小さめに表示するとかはどうでしょうか。詳しい仕様などが解っていないので、おかしなことを言っていたら、申し訳ありません。--温厚知新（会話） 2025年9月29日 (月) 18:32 (UTC)

単語の解釈の話はあまりしたくないのですが、たとえば「私」「オレ」「ボク」など複数の一人称の使い分け、これは日本語の仕様ですので日本語版において重要かもしれません。その一方で、元号というのは日本語があろうが無かろうが存在し得ていて、日本国で採用しているものなので、日本語とは直接関係がなく関係があるのは日本国に対してとなります。日本語版で必要なのであれば他言語でも必要になるというのが考え方としては無難かと思いますが、日本国特有の元号のための引数追加など求める他言語編集者はいるのでしょうか？

また、難易度については「難しいからやらない、簡単だからやる」だとかそういう話ではなくて、太陽暦と太陰暦のように日付ごと異なるのでなければ、元年と最後の年の日付チェックと年の変換程度なので特別難しい話でもないです、面倒くさいだけで。問題は誰かの所有物というわけではないので、引継ぎが出来ない事にあります。企業のプログラムであれば、○○の時にこのプログラムは修正必須だとか、もしくは何かあった時（たとえば2000年を迎える際だとかに）全プログラムの調査案件だとかが発生します。仮に1999年以前にWikipediaがあったとして2000年問題対処というのが必要になっていたかもしれません、その際に「何か問題がないかの調査」「調査後の改修」というのは一体誰がやるのでしょうか？といった話です。Wikipediaの記事は間違った内容はいつか誰かが修正するだろうという思想のもとになりたっていますが、プログラムが絡むものにそれが期待出来るか。誰かがやるだろうと無責任な事は言えませんよね？このテンプレートであれば改元時に修正が必要となるはずですが、”改元時に修正が必要です”、という未来の編集者への引継ぎがWikipediaという、誰も責任を持たないといってもいいプロジェクトにおいては”何かある度に改修が必須になる”という縛りが入った物件はそぐわないのです。機能改善は良いのですが、確実に未来において修正が必要になる、といった改修の仕方はよろしくありません。元号が知りたいと思う人は自分で計算すればいいだけの話じゃないのですか？その程度の作業を惜しむ人が元号を知って何かをするという事はあるのでしょうか？--田村悠（会話） 2025年9月30日 (火) 15:40 (UTC)

多少のニーズがあるとしたら、折衷案として、元号はCite系テンプレートの後ろに別記し、Citeでは発行年月日や原出版年の末尾に約物を挿入する引数を追加するのはどうでしょうか。「福沢諭吉「西洋事情（初編）」『福沢全集』 1巻、時事新報社、1898年_※。doi:10.11501/898727。国立国会図書館書誌ID:000000519646。 ※明治31年」のような表示で、元号は素の文です。西暦と離れてしまい元号の見やすさは低下しますが、全く対応しないよりはよいかと。実装の手間は省けますが、元号が左の例で明治32年など誤っていても、Cite系テンプレートは関知しない（執筆者に任せ、今まで通りセルフチェックを期待する）ことになります。--Peka（会話） 2025年9月30日 (火) 10:44 (UTC)

Category:出典の日付が正しくないページを見ればセルフチェックが期待できないことはよく分かりますので、採用しかねます。日付のチェックはこれまでずっとしてきたので、「今まで通り」ではありません。--FlatLanguage（会話 / 投稿） 2025年9月30日 (火) 13:04 (UTC)

パスワード紛失により今はIPですが、以前はアカウントを持っていました。その上で言うのですが、個人設定ガジェットで『出典部分の西暦の後ろに和暦（元号）を付ける』という機能が有ってもいいのではないかとは思いました。確か、署名の日時をJSTで表示するガジェットとかもありましたよね？

また、実際の表示は『2019年』一つという前提で、『平成31年』という入力や、『令和元年』という入力も、許容するのは有りではないでしょうか？--~2025-27426-53 (会話) 2025年10月2日 (木) 12:15 (UTC)

JSTのリンク先変更。--~2025-27426-53 (会話) 2025年10月2日 (木) 12:17 (UTC)

• 元号西暦対照表

『元年』は1年とした上で、

「明治○年」→1897+○年

「大正○年」→1911+○年

「昭和○年」→1925+○年

「平成○年」→1988+○年

「令和○年」→2018+○年

へと変換して表示するイメージです。--~2025-27426-53 (会話) 2025年10月2日 (木) 12:25 (UTC)

中間まとめ

小見出しを立てます。当初の記入は Omotecho による2025年10月3日 (金) 00:31 (UTC) ← --Omotecho（会話） 2025年10月15日 (水) 09:22 (UTC) {{outdent|8}} インデントを戻します。皆さん、お知恵を絞ってくださり大変ありがたいです。ただ、申し訳ない、技術面の理解が追いつきません。いったん、確認させてもらえませんか？　パラメータについて、注釈に書いた山カッコ（〈___〉）の理解で正しいですか？

もっか、気になる点を記します。課題は多く、合意が成立するかどうか1点ずつ潰せたら幸いです。

不明点の整理。以下、コメ注（"※"）はパラメータ名を出典の書式の解説ページより抜粋。

1. ▲日本語版における利便性と、汎用性の両立は？
   1. 日本語版から他言語に翻訳する場合
2. 西暦との対照など統一のルールを設けないと不利点があるのでは？
3. 元号は日本、中国、韓半島、ベトナムで使った歴史あり。
   1. ▲元号を使いたい分野は偏っているが、容認されるか？（推定＝人文系の歴史学、文献学、美学か）
4. Google検索で"元号＋年数"を入力すると西暦年を返すが、信頼性の低い数値か？ 仕掛けを流用できないか？

（i）技術面

引数（パラメータ）の選択肢

• |orig-date=を流用。
• 元号用のregnalを新設。

換算式

• （a）検算する。グレゴリオ暦に揃えた明治以降（明治10年制定か）
• （b）検算しない。パラメータregnalは平文で元号付きの年数を記すのみ。

• （c）西暦との対照（換算）テーブルを作る。
  • どこかに既製でないか？

（ii）典拠の確認（文献学、歴史学など）

• 元号があると大まかに脚注などのエラーが把握しやすい。
• 元号を重宝するのは、グレゴリオ暦との対応をしていない江戸時代以前。

未決の課題

• 太陽太陰暦と西暦の換算。過去の元号の件数×（開始日と最終日）

---

注釈

^ ご参考

• orig-date: 情報源の最初の公表日を指定します。dateまたはyear引数の後ろに角括弧で括られて表示されます。|orig-date=First published 1859〈初版1859年〉や|orig-date=Composed 1904〈1904年作曲〉のようにして「最初の公表日」の意味が分かるように指定してください。日付の書式は|df=に従うか、|date=で指定したものに揃えてください。別名: orig-year、origyear。
• df: 日付の表示形式を指定します。範囲もしくは季節が付いた日付に対しては効果がありません。access-dateとarchive-dateの表示形式も変更されません。以下のいずれかのキーワードが指定可能です：

  dmy（CS1/CS2の既定値） - 公表日が27 January 1982の形式で表示されます。

  mdy - 公表日がJanuary 27, 1982の形式で表示されます。

  ymd - 公表日が1982-01-27の形式で表示されます。

  ja - 公表日が1982年1月27日の形式で表示されます。

---

分岐 --Omotecho（会話） 2025年10月15日 (水) 09:22 (UTC)

--Omotecho（会話） 2025年10月3日 (金) 00:31 (UTC)

---

技術的な事というか、可能かどうかについては、よくわからないという方は気にしなくていいというか、面倒なので“入力にも出力にも対応は出来ます”とだけとりあえず言っておきます。そこはあまり気にしなくていい部分だと思ってます。

可能かどうかではなく、やるべきかどうかの議論が必要で、このタイトルだと、和暦・元号について議論してるとは思わないので、続けるならタイトル変更して建て直しが必要かと思います。個人的に言わせてもらえば、ほぼ害しかなく利点など無いに等しい元号を記事本文であればともかく、出典に入力させる事にはやはり反対ですが。引数を増やせば増やすほどに他言語の同名のテンプレートと差が出てしまう。和暦など馴染のない人がその記事を翻訳しようとした場合の障壁となってしまいます。

その上で、理由はともかく和暦からの変換テンプレートは結果的に廃止されていること、過去にも議論が何度か和暦・元号については議論が行われています。そういった先行議論…Wikipedia:井戸端/subj/元号を使うべき辺りも参考に。

以下、仮に和暦・元号を実装する場合の問題点（まだそこまで考える必要は無いという仕様に関する部分も一応入れてます）

• エラー多発問題：まともに日付さえ入力出来ずエラーが出ても気づかず放置する人が多いため、西暦以上に複数の入力パターンが考えられる元号については「元号＋年（月日）」ではエラー吐きまくるのが目に見えてます。引数を追加するとして元号のみであれば、漢字2文字で入力されようと、アルファベット1文字で入力されようと対応が出来るというかエラー入力が起きにくい。つまり、新引数には何を入力させるのか、元号のみで年（月日）用の引数も追加するのか、元号＋日付なのか。
• 和暦西暦併記問題：和暦入力時は和暦のみとする/和暦と西暦の併記を可とする/和暦を入力する場合においても西暦は併記必須とする
• 日付エラー問題：昭和99年など存在しない年を西暦換算するのか、エラーとするのか（日付もチェックするのであれば昭和64年4月1日のような存在しない日付を許容するのか）。認める場合、昭和100年のような3桁の年を認めるのか。
• 引き継ぎ問題：和暦や元号といった名前の無いテンプレートで密かに和暦西暦変換やチェックが入ってるというのは引き継ぎ観点でよろしくない。行うのであれば別のどこかわかりやすい名前の何かでやるべき（例：Template:Jdateに対するTemplate:Jdate/year）--田村悠（会話） 2025年10月3日 (金) 14:25 (UTC)

環境が違いますが~2025-27426-53です。(特別:差分/106664776/106687000)

前回のコメント後半の意図としては『出典に和暦しかない場合に、西暦に変換する手間を省きたい(記憶違いで年数を間違える可能性もある)』というものです。

{{明治}}{{大正}}{{昭和}}{{平成}}{{令和}}といったテンプレートを作成し、例えば{{平成|31}}や{{令和|1}}は『2019』として出力する、というのは、どうでしょうか？

(かつて使用された{{和暦}}は『このテンプレートの記述は複雑な構成となっています。』との事ですが、今回は『実際の表示は、特別な事情がない限り、西暦に一本化すべき』という考えの元です。元号併記の機能が欲しい方向けのガジェットは有ってもいいとは思いますが、必要不可欠とは思いません)

そして『昭和100年』については、一部の界隈では使われている(ニコニコ動画の例)ので、場合によっては記事本文で使う機会が有るかも知れません。例えば、『昭和が100年まで続いたIF世界の物語』は生まれるかも知れませんし、その場合『昭和100年（2025年）』とせずに『昭和100年（{{昭和|100}}年）』という用法も出来た方が、作中年表を書きやすいと思います。

そして、コレで誤入力するケースは、どうやっても誤入力されるケースだと思います。何故なら、和暦の西暦化を代行するだけのテンプレート案なのですから。『基本的にSUBST展開する(コレ付きで辞書登録しておく)』のはどうか……とも思いましたが『<ref>タグ内ではsubst展開は使用できません』とのことなので、追跡カテゴリーとしてCategory:元号の西暦化テンプレートを使用しているページを検討してもいいかも知れません。(場合によってはCategory:昭和の西暦化テンプレートを使用しているページの方がいいかも？)

最後に述べておきますが、{{和暦}}で言及されている『暦変換WEBツール『換暦』』の存在は、{{明治}}{{大正}}{{昭和}}{{平成}}{{令和}}を作らなくていい理由にはならないと思います。外部サイトの為に、閉鎖しない保証はないですし。そもそもググれば分かる状況下で、それを手間に思って記憶で西暦化する(そして間違える)ケースの解決にはならないですし。--~2025-27601-35 (会話) 2025年10月3日 (金) 20:12 (UTC)

出典テンプレートで実装すべきかの問題なので、特定界隈とか物語の中の話は無関係です。また繰り返しになりますが、Wikipedia:出典を明記するに基づき西暦の入力は（和暦の有無にかかわらず）必須であり、西暦を省略できるようにすべきとも思えません。--ネイ（会話） 2025年10月5日 (日) 03:36 (UTC)

~2025-27426-53、~2025-27601-35です。

『出典に和暦しかない場合』に、『平成30年って2019年だったよな』みたいな間違いを防ぎたいと思ったまでですが、不要ならば強く主張するつもりはありません。

今回はブレインストーミング的にコメントしただけですので。

ただ念のため言っておくと、『2018』という出力を、『2018』と書くことだけ認めるか、『{{平成|30}}』と書けるようにするか、の違いという意図でした。

(勘違いされていたとかでない限り、以後は本議論に関わらない事にしようと思います。少なくとも私個人は、これらのテンプレートは不要ですし)--~2025-27726-78 (会話) 2025年10月5日 (日) 07:18 (UTC)

区切り2

流石に長いので区切り入れます。

結局この議論は、『現状維持』ということでいいのでしょうか？--~2025-28570-74 (会話) 2025年10月12日 (日) 12:53 (UTC)

ポータル類で協議に参加をお願いしました。小見出しの「中間まとめ」を立ててあります。

• Portal:法学
• Portal:歴史

--Omotecho（会話） 2025年10月15日 (水) 09:50 (UTC)

上記のOmotechoさんが提示したかった差分は、以下のものかと思います。

• Portal:法学
• Portal:歴史

参考までに現時点でCategory:出典の日付が正しくないページには 18,270 ページありますが、その中で明治から令和までの元号（漢字表記）を使っているものを検索すると2,000件程度でした。和暦への対応を求めたいのならばTemplate‐ノート:Citation/showdateに提起すべきではないでしょうか。--Kokage si（会話） 2025年10月16日 (木) 15:03 (UTC)

@Kokage siさん、ポータル差分の正解をフォローくださり誠に助かりました。

提言先Template-ノート:Citation/showdate に持ち込む場合は、下記の（1）＝西暦との対応が法制化された明治以降のみ対応する案になると予想しますが、ご指摘を正しく汲んでいるでしょうか？　

法務法学には明るくないので、公文書に必ず元号を示す慣習があるか、出典テンプレートに書き込むのは必須かどうかなど、碩学のご指摘を待ちます。

1. 元号を多用する実業の世界、法曹に特化するなら、必要な元号は明治以降らしい。
2. 歴史関連は元号が資料判断の目処になるので、どの年代も書くのが便利。

ここまででわかったのは、元号の記法が予想以上にバラバラで根が深い点。showdate に決まりを増やす・周知して解決できたら理想的です。--Omotecho（会話） 2025年10月17日 (金) 12:26 (UTC)（返信スレッドを訂正）

「日付を year と date に分けずに date にまとめて記入してください。」というエラーメッセージは和暦とは全く関係ないです。本来は|year=2025|date=10月18日ではなく、|date=2025年10月18日と書くのが正しいというのを伝えることを意図したものです。Omotechoさんの|date=大正12年|year=1923のような使い方は完全に想定外だと思います。|date=令和7年10月18日や|year=大正12年なら「エラー: 日付は和暦ではなく西暦を用いてください。」となります。このエラーに対応しているのは明治から令和までの元号のみで、それ以外だと汎用的な「エラー: 日付が正しく記入されていません。」になります。--Kokage si（会話） 2025年10月18日 (土) 08:38 (UTC)

移動依頼について

「エヂーナヤ・ロッスィーヤ (装甲列車)」の「エヂーナヤ・ロッスィーヤ」への改名提案を行っています。

跡地が不要になると思われるため、リダイレクトを残さない移動を依頼したいのですが、Wikipedia:移動依頼#依頼できないものに「移動先のページが存在しない場合」がありました。こういった場合は移動後にリダイレクトの削除依頼をする以外の方法はないのでしょうか。

なお、ノートページについてはリダイレクトとして存続していただきたいと思います。— 市民武佐（会話） 2025年10月15日 (水) 09:21 (UTC)

リダイレクトの即時削除の方針に合致しない限り、リダイレクトを残さない移動は移動依頼では受け付けていないので、ご自身で移動をしたのち、移動元のリダイレクトが不要であればリダイレクトの削除依頼に出してください。 --Dragoniez (talk) 2025年10月15日 (水) 09:36 (UTC)

了解です。

当初の内容での提案は6日間行いましたが、もう1日待って反対意見がなければ改名作業を行ってよいでしょうか。

それとも再提案すべきでしょうか。— 市民武佐（会話） 2025年10月20日 (月) 08:45 (UTC)

書き忘れていたのですが、井戸端から移動していただき有難うございました。— 市民武佐（会話） 2025年10月20日 (月) 08:46 (UTC) — 下線部追記 — 市民武佐（会話） 2025年10月20日 (月) 08:47 (UTC)

下書き記事のレビュー依頼（TETRAPOT株式会社）

利用者:InfoNavigator2025/下書き にて「TETRAPOT株式会社」という企業記事の下書きを作成しています。  

AFC申請を行いましたが、3か月以上経過してもレビューが行われていないようです。  

内容は中立性と出典（経済界、ミライのお仕事、日本能率協会資料）を重視して構成しております。  

お手すきの際にご確認・ご意見をいただけると幸いです。  

--~~~~--InfoNavigator2025（会話） 2025年10月17日 (金) 03:19 (UTC)

日本語版 Wikipedia には「en:Wikipedia:Articles for creation」のような仕組みはありません。記事のレビューは「Wikipedia:査読依頼」をお使いください。 --Kto2038（会話） 2025年10月17日 (金) 03:32 (UTC)

ご案内ありがとうございます。査読依頼に移行して進めてみます。 --~~~~--InfoNavigator2025（会話） 2025年10月17日 (金) 08:43 (UTC)

既存人物記事における死刑判決の記載基準の明確化について

【提案の趣旨】

現在、死刑判決を受けた人物については「日本における死刑囚の一覧」への記載が定着していますが、既にWikipediaに個別項目が存在する人物が死刑判決を受けた場合、その人物記事にどのように記載すべきかについて、明確な基準が存在しません。 この曖昧さは、以下の課題を生んでいます:

• 編集者ごとの判断のばらつき
• 削除依頼での継続的な議論の発生
• 読者にとっての情報アクセスの一貫性の欠如

本議論は、特定の個別事例とは独立して、一般的な運用基準を明確化することを目的とします。

【議論の範囲】

本議論で扱う範囲:

• 既にWikipediaに項目が存在する人物
• 死刑判決が確定した場合
• その事実を人物記事にどのように記載するか

本議論で扱わない範囲:

• 特定の個別記事の削除・存続の是非
• 「日本における死刑囚の一覧」自体の存廃
• 死刑制度の是非など、百科事典外の価値判断
• 個別記事の編集内容の細部

【現状の確認】

現在、以下の運用状況が確認されます:

1. 一覧記事での扱い - 「日本における死刑囚の一覧」では、死刑判決を受けた人物が記載されています。

2. 人物記事での扱い - 既存の人物記事において、死刑判決の記載基準が明確でないため、記事ごとに扱いが異なります。

3. 関連方針 - WP:BLP（存命人物の伝記）、WP:NPOV（中立的な観点）、WP:V（検証可能性）などが関連しますが、これらの方針間での優先順位や適用範囲が統一されていません。

【論点の整理】

本議論では、以下の論点についての整理を目的とします。

1. 情報の一貫性 - 一覧記事と人物記事で扱いが異なることの妥当性。

2. 特筆性との関係 - 既に項目が存在する（=特筆性が認められた）人物において、死刑判決という事実をどのように扱うべきか。

3. 検証可能性と中立性 - 確定判決という検証可能な事実を、どの程度まで記載できるか。

4. プライバシーと公益性のバランス - WP:BLPの趣旨を踏まえたうえで、どのような表現形式が適切か。

【想定される選択肢】

以下は議論の出発点としての選択肢です（これに限定されません）。

選択肢A:原則記載 - 確定判決は検証可能な重要事実として、簡潔に記載する。（一文程度、中立的表現、犯行詳細は記載しない。）

選択肢B:個別判断 - 統一基準を設けず、削除依頼などで個別に判断する。（現状の運用に近い。柔軟性がある一方、判断基準の明確化という課題は残る）

選択肢C:原則非記載 - 人物記事には記載せず、一覧記事のみに記載する。（情報の取り扱いを一覧に集約することで運用を簡素化）

選択肢D:その他 - 上記以外の基準案。

【議論への参加のお願い】

本議論は、Wikipedia日本語版における情報の一貫性と運用の安定性を高めるためのものです。 感情的な立場論ではなく、方針整合性と検証可能性の観点からの冷静なご意見をお寄せください。--96points（会話） 2025年10月17日 (金) 04:46 (UTC)

二要素認証の回復用コードが1つしか生成されない

Phabricatorで追跡中
タスク T407167
解決済み

Phabricatorで追跡中
タスク T408294
解決済み

最近のMediaWikiのアップデート（リリースノートを見るに2025年9月25日と2025年10月9日）で二要素認証の設定画面が大幅に変更されました。

それで、おそらくgerrit:q/349b16a3の変更によるものかと思われますが、これまで10個供給されていた回復用コードが1つしか生成されなくなっています。

二要素認証の設定を変更するには、次の手順で操作する必要があります。ここで、ブラウザの不具合など何らかの理由でステップ1とステップ2の操作の間に不連続が生じると、管理画面にたどり着く前に回復用コードを使い果たしてしまう恐れがあります。

1. アカウントにログインする。
2. 特別:個人設定から管理画面に移動する。
3. （前回の認証から一定時間が経過している場合）本人確認のため再ログインする。

スマホでもPCでも同じ結果なので環境による影響ではないとは思いますが、私以外の二要素認証の利用者の方ではどんな挙動を示しているかお伺いしたいです。

meta:Help:2FAによれば、今年中に二要素認証機能を全利用者へ開放する方向で動いているようです。偶然にも個人的な関心で関連文書の英語版からの翻訳に取り組んでいましたが、急ピッチで作業を進めることにします。

--T4NeGMp7P4en（会話） 2025年10月17日 (金) 17:44 (UTC)

上記のようにやってみようとしました。

1. アカウントにログインする。→時に二要素認証の認証コードの入力を求められる→ログインする
2. 特別:個人設定から管理画面に移動する。
3. （さっき認証したので、前回の認証から一定時間が経過しているわけではないが）二要素認証の認証コードの入力を求められる→ログインする

となったので、私の読解力不足と技術的知識不足であるだけかもしれませんが、「管理画面にたどり着く前に回復用コードを使い果たしてしまう恐れ」という状態がどういうことなのかよくわかりません。1のログイン時に認証コードの入力に失敗して回復用コードを使用してログインできたとして、管理画面に移動して認証してまた失敗すると、回復コードが1つでは足りないということでしょうか。--柏尾菓子（会話） 2025年10月18日 (土) 02:42 (UTC)

（追記）使い果たしたくないため試していませんが、1の段階で「ブラウザの不具合など何らかの理由」により何度も失敗して回復用コードを使い果たしてしまったとすると、管理画面以前にまずログインができないのでは、と思います。--柏尾菓子（会話） 2025年10月18日 (土) 02:48 (UTC)

返信 挙動についてご報告いただきありがとうございます。私の日本語力の低さ故、混乱を招いてしまい申し訳ございません。質問にお答えします。

「管理画面にたどり着く前に回復用コードを使い果たしてしまう恐れ」という状態がどういうことなのか

体験していただいた通り、再認証が発生すると、設定画面にたどり着くまでに二要素認証を2回実行する形になります。その一方で、回復用コードは1回しか利用することができません。最初のログインで回復用コードを行使すると、設定画面への入場時に再認証を求められた場合、（有効な回復用コードがもう残されていないため）提供できる資格情報が一切なくなってしまうというわけです。

旧仕様では、設定画面入場後の無効化処理時にワンタイムパスワードの入力が必須であったため、回復用コードを少なくとも2個用意しなければなりませんでした。このため、Help:二要素認証#注意事項では特に未使用の回復用コードの個数が3個以下になった場合速やかに回復用コードを再生成するよう案内しています。

ちなみに、X（旧Twitter）もリカバリーコードは1個しか発行されませんが、こちらは再認証時はパスワードしか求めないため、上記のような懸念は発生しません。

1の段階で「ブラウザの不具合など何らかの理由」により何度も失敗して回復用コードを使い果たしてしまったとすると、管理画面以前にまずログインができないのでは

ちょうどこの返信を執筆中に https://upload.wikimedia.org がダウンしてしまいまして、すべての画像が一時的に表示されなくなりました。また、利用者側の環境に一時的な不具合が発生することもあるでしょう。障害箇所がサーバーなのかクライアントなのかに関係なく、回復用コードを使ってログインした後に何らかのトラブルですぐ設定画面にたどり着けない、すなわち再認証をトリガーしてしまうリスクがあることを考慮しなければなりません。

そして、柏尾菓子様の「最初のログインから時間をおかずに設定画面に入ったのに再認証が求められた」という事例から、単純なタイマーではなくリスクベース認証で再認証の要否を判定している可能性が考察されます。こうなると、不具合云々関係なく、運次第で設定画面から締め出される場合があるといえるかと思います。

「そんな"もしも"は気にしなくて良い」との意見も出るかもしれませんが、このようにしてアカウントがロックアウトされてしまうと、もはやVRTに強制解除を依頼するしか道がありません。当然大きな手間がかかりますし、確認済みメールアドレスの失効などにより本人確認ができなかった場合はアカウントを失う羽目になります。二要素認証を設定しているのが私のようにスチュワードさんに利用申請を行ってまで機能を試そうとする人だけなのであれば最悪それでも良いのかもしれませんが、柏尾菓子様のように権限上二要素認証の利用が必須化されている人にとっては、ご本人にとってもコミュニティにとっても一大事です。メタウィキでの発表通り全利用者に二要素認証が開放されるのであれば、前述の懸念はさらに切迫したものとなります。

以上が、私がここまで騒ぎ立てている理由です。回復用コードでログインした場合は自動で設定画面に遷移するようにすることが提唱されているようですが、私感としてはそれでも物足りないという印象です。一応Phabricatorでバグ報告を提出しましたが、回復用コードの数が1つのまま変わらないのであれば、既存の二要素認証の利用者全員に個別で注意喚起したり、（こちらはそもそも仕様変更に伴う大幅な書き換えが必要ですが）先日私が翻訳したHelp:二要素認証に説明を付したりと、厳重な対応を要するものと思料します。

返答が長文になりましたこと、お詫び申し上げます。

--T4NeGMp7P4en（会話） 2025年10月18日 (土) 08:24 (UTC)

コメント 毎回ではないですが、ログインしてしばらく(10分ぐらい?)してから二要素認証の管理画面に遷移しようとすると再認証が発生しました。ところでここの挙動がどうであるかはあまり重要ではないものとおもいます。指摘の通り回復コードは再利用できないため、設定画面にたどり着けないシナリオは他にもいろいろあります。

• ログインは成立したがブラウザが落ちた、ネットワークが切れたとか、(今まさに起きたのですが)何らかの理由でログイン状態が失われてしまった、など起きると再ログインしようとしてももうできません。
• wikimedia.orgのセッション管理は一部不審な挙動があり、ログインしたはずが画面は未ログイン状態、ということも割と発生します。これを誤認してブラウザを閉じるとアウトです。

「回復用コードでログインした場合は自動で設定画面に遷移」はこれらの救済には(ほぼ)なりません。--Strangetail（会話） 2025年10月19日 (日) 05:36 (UTC)

返信 (利用者:Strangetailさん宛) まさにおっしゃる通りです。回復用コードが1つしか生成されないのは単なるバグなのかもしれないと願っていた部分もありましたが、phab:F65750465を見る限り完全に仕様っぽいんですよね……。ようやく実世界が落ち着いたので、Help:二要素認証の改訂作業に大至急取り掛かります。二要素認証試験者ではないStrangetailさんが二要素認証機能にアクセスできているということは、メタウィキの予告通り二要素認証の一般開放が徐々に進んできているということですし……。--T4NeGMp7P4en（会話） 2025年10月19日 (日) 08:38 (UTC)

コメント こちらでも試してみました。表示されている回復コードは、私が控えていた10個のコードとは異なっていたため、古いコードは無効になったものと思っていましたが、実際にはログイン時に使用することができました。
その後、Special:AccountSecurityにアクセスした際には再び回復コードの入力を求められたため、やはり複数のコードが必要なようです。新しい方の回復コードを使用してみたところ自動で再発行されてますが、これを確認するにはたしかにphab:T406281の実装を待つ必要がありそうですね。 --なノな15どバと（会話） 2025年10月20日 (月) 06:33 (UTC)

 追記 私のサブアカウントである利用者:なのな15どばと（会話 / 投稿記録）でも有効化できそうでしたので、おっしゃるとおり一般開放は進んでいそうです。 --なノな15どバと（会話） 2025年10月20日 (月) 06:35 (UTC)

返信 (なノな15どバとさん宛)

新しい回復用コードが発行されていたものの、依然として旧仕様時代の回復用コードが利用できたということでしょうか？非常に興味深いですね。回復用コードを再生成したり認証手段の構成を弄ったりしたので検証できるか分かりませんが、私の方でも試してみます。貴重な回復用コードを使って情報をお寄せいただきましたこと、心より感謝申し上げます。

phab:T406281については私も以前見かけました。「回復用コードでログインした場合に新しい回復用コードを自動で提供できるようにする」という提案であると認識しております。これについては、Strangetailさんが指摘されていたように、あまり意味がないかもしれません。

副アカウントでの挙動についてもお知らせくださりありがとうございます！危機感が増しますね……。--T4NeGMp7P4en（会話） 2025年10月20日 (月) 07:47 (UTC)

@なノな15どバとさん 古い回復コードのセットを試したところ、教えていただいた通り確かにログインできました。ただ、2個目以降が通らなくなったんですよね……。本当に本当に恐縮なのですが、なノな15どバとさんのほうでも検証していただくことは可能でしょうか？--T4NeGMp7P4en（会話） 2025年10月20日 (月) 18:18 (UTC)

返信 (T4NeGMp7P4enさん宛) 2個目以降とは、同一のログインセッション内でという意味でしょうか。私の環境では、ログアウト後に再ログインする際、2つ目の旧仕様回復コードを問題なく使用できました。なお、「特別:ログイン」から直接ログインするのではなく、「特別:AccountSecurity」経由でログインした場合は、1つの回復コードでも管理画面にアクセスできそうです。 --なノな15どバと（会話） 2025年10月22日 (水) 00:30 (UTC)

返信 (なノな15どバとさん宛) 試していただきありがとうございます！単に2個目以降が使えるかどうかが問題だったので……そうすると恐らくですが、セキュリティキーを有効にしている場合でも、認証アプリを削除すると旧仕様の回復コードは全て失効するようです。

特別:AccountSecurityを介する方法は確かにアリなのですが、誤ってjawikiに画面を移してしまうと（ロゴに触れてしまう等）、確実に再認証が発動するんですよね。ちょっと怖いです。--T4NeGMp7P4en（会話） 2025年10月22日 (水) 01:45 (UTC)

メモ 一旦ここまでの情報をまとめます。

• 2025年10月9日にローンチされた更新以後、発行される回復コードの数が1つだけになってしまった。
• 設定画面に入場するために再認証が求められる場合があり、検証によればその発生頻度は無視できない程度に高い。
• Help:二要素認証の書き直しを要する。現在、T4NeGMp7P4enにより鋭意作業中。

本案件はphab:T407167でも並行して議論を進めています。拙い英語ですが、何とか状況を伝えることには成功しました。--T4NeGMp7P4en（会話） 2025年10月22日 (水) 08:20 (UTC)

済 gerrit:1198042にて、回復コードの個数が10個に復元されました！皆様本当にお疲れさまでした。引き続き議論したい点は次の2点です。

• Help:二要素認証の改訂について。
• 一時的に回復コードの数が1個となっていた件について、コミュニティ全般にお知らせすべきか否か。

--T4NeGMp7P4en（会話） 2025年10月22日 (水) 13:58 (UTC)

I'm the WMF product manager overseeing the account security updates. I'm sorry to use auto-translated Japanese, but wanted to reply quickly.

Thanks to @T4NeGMp7P4en for reporting these issues. As mentioned, we have reverted the behavior back to generating 10 codes. Our goal was to simplify how recovery codes worked -- and we had lengthened the re-authentication timer to go along with this, to make it harder to get locked out -- but this was clearly not careful enough. Our apologies, and we'll be more cautious with how we change this behavior going forward.

The change back to 10 codes is not retroactive, so if you were already given just 1 recovery code, you will need to go regenerate them manually to get issued 10 more. This applies to people who have set up 2FA, or managed their 2FA, since we made the change to one recovery code on October 9. EMill-WMF（会話） 2025年10月22日 (水) 14:32 (UTC)

--

アカウントセキュリティアップデートを担当するWMFプロダクトマネージャーです。自動翻訳の日本語を使用し、申し訳ありませんが、すぐに返信したかったのです。

これらの問題を報告してくださった@T4NeGMp7P4enさんに感謝します。前述の通り、10個のコードを生成する動作に戻しました。リカバリーコードの仕組みを簡素化することを目指し、ロックアウトされにくくするために再認証タイマーを長くしていましたが、明らかに十分な配慮が行き届いていませんでした。お詫び申し上げます。今後は、この動作の変更についてより慎重に対応いたします。

10個のコードへの変更は遡及適用されません。既にリカバリーコードを1個しか取得していない場合は、手動で再生成して10個追加する必要があります。これは、10月9日にリカバリーコードを1個に変更して以降、2FAを設定または管理しているユーザーに適用されます。EMill-WMF（会話） 2025年10月22日 (水) 14:32 (UTC)

返信 (EMill-WMFさん宛) Thank you for your message! We are just starting to discuss about how to inform about this change to who generate the codes between 10/09 ~ 10/22. I hope that some notification are provided to every project in local about the change of phab:T401774. --T4NeGMp7P4en（会話） 2025年10月22日 (水) 14:48 (UTC)

コメント 回復コードが10個生成され、使用できることを確認しました。提議・提出ありがとうございました。

改訂の詳細に関しては、Help‐ノート:二要素認証での議論でよいかと思います。また、お知らせについては、10月9日以降に有効化した場合は旧仕様の回復コードもないですし、再生成も含めた案内をしておくべきであると考えます。--なノな15どバと（会話） 2025年10月22日 (水) 14:44 (UTC)

返信 (なノな15どバとさん宛) 改訂の議論は確かにHelp‐ノート:二要素認証に譲るべきですね。どのようなお知らせを流すべきか議論してこの場は終結しましょうか。要点としては……

• 二要素認証が一般開放されつつある。
• 10月9日～10月22日に二要素認証の有効化や回復コードの再生成を行った場合、発行される回復コードの個数が極端に少なくなっている。
• すべての二要素認証ユーザーに回復コードの再生成を強く推奨する。

--T4NeGMp7P4en（会話） 2025年10月22日 (水) 14:54 (UTC)

報告 Help:二要素認証の改訂草案が仕上がりました。Help:二要素認証/sandboxに保管されています。議論場所はこちらです。併せてぜひご参加ください。--T4NeGMp7P4en（会話） 2025年10月23日 (木) 18:39 (UTC)

報告 残念ながら、新たなバグが発生しました。回復コードを再生成すると、新しいコードが表示されないばかりか、既存のコードが1個ずつ消滅していきます。10回再生成して全消しするとようやく新しいコードが表示されます。phab:T408294で報告済みです。さすがに不安定にもほどがあるので、Wikipedia:お知らせに注意喚起を掲示します。--T4NeGMp7P4en（会話） 2025年10月25日 (土) 14:55 (UTC)

「利便性を犠牲にしてでもセキュリティを優先すべきだ」というそこそこ過激な考えの持ち主なので、正直まさか自分が『二要素認証を無効化することを強くおすすめします』なんてセリフを吐く日が来るとは思いませんでした。本当に、勘弁してほしいです……。--T4NeGMp7P4en（会話） 2025年10月25日 (土) 15:39 (UTC)

済 解決したとのことです。ただ、修正してくださった方のコメントを見るに、楽観視は不可能ですね。

I've found numerous other bugs... So many tasks filed off the back of this :(
（他にも数多くのバグが見つかったよ……。今回の件から派生したタスクが山積みだ。）

—Reedy、Regeneration of Recovery Codes doesn't work properly、phab:T408294#11309423

--T4NeGMp7P4en（会話） 2025年10月25日 (土) 18:51 (UTC)

「削除の方針」および「存命人物の伝記」の制度的整合性に関する再検討

本提案の目的

本提案は、現行の削除の方針（WP:DP）および存命人物の伝記（WP:BLP）の運用上の課題を整理し、方針体系全体の整合性と透明性を高めることを目的とします。特定の記事や利用者を対象とするものではなく、制度・運用面における再検討を趣旨とします。

特筆性と記載範囲の関係

特筆性は「記事の存否」を決める基準であり、記載内容や表現の妥当性を保証するものではありません。現状では、特筆性が認められる人物・団体であっても、WP:BLPに抵触する内容が含まれる場合があり、記載範囲の適切な統制が課題となっています。

存命人物の伝記の適用範囲

存命人物の伝記は、名誉・プライバシー・人格権の保護を目的とし、真実性や出典の有無にかかわらず、本人に対する不当な不利益を回避することを重視します。しかし、現行の運用では「検証可能であれば記載可能」とする解釈が優先される場面があり、法的・倫理的観点との調整が十分でないことが指摘されています。

削除方針における制度的整合性の課題

削除方針は「削除に値するかどうか」を判断するための枠組みですが、方針文書中の一部表現（例：「伝統的に削除されている」）は、制定時点の限定的議論に由来し、その法的根拠や運用目的が明確に整理されていません。このため、削除依頼における解釈や適用範囲が参加者間で乖離する事例が見られます。

「伝統的運用」と50%ルールの成立経緯

「伝統的運用」という表現の導入経緯

削除方針における「伝統的に削除されている」という表現は、2004年11月24日の方針文加筆提案に初出します。

ひとまず今回のところは、伝統的に削除されている例と削除されていない例の提示に済ませて（後略）
提案文：下記に、ウィキペディア日本語版で伝統的に削除されている例を挙げます。 （中略）29日以降の警告消去時に書き換えます。

—ノート:削除の方針/2005年4月9日までの議論

この表現は、当時の合意形成を経た定着概念ではなく、将来的に方針文書へ追加を予定していた暫定的文言に過ぎません。したがって、「伝統的運用」という語が現在に至るまで権威的根拠として扱われることには、再検討の余地があります。

法的根拠の明示の遅延と未解決化

同時期の議論では、個人情報保護法や民法（709条等）への言及がありましたが、法的根拠の具体的整理は「後日に行う」とされたまま未了でした。

細かい判例などは書き加えなくても大丈夫でしょう。もし加えるならば、29日以降に再度提案します。

—同上

しかし、この「29日以降」に法的根拠の詳細な整理が行われた記録は、方針ノートの過去ログに確認できません。結果として、削除方針における法的根拠の明示は曖昧なまま現在に至っており、これが後年の削除依頼における判断基準の不統一をもたらした一因と考えられます。

「高度の蓋然性」概念との関係

「50%ルール」と呼ばれる判断基準は、1975年（昭和50年）10月24日の最高裁判決（東大病院ルンバール事件・昭和48(オ)517）における「高度の蓋然性」概念を参考にして形成されたと考えられます。

訴訟上の因果関係の立証は、一点の疑義も許されない自然科学的証明ではなく、経験則に照らして全証拠を総合検討し、特定の事実が特定の結果発生を招来した関係を是認しうる高度の蓋然性を証明することで足りる。

—最高裁 昭和50年10月24日判決（ルンバール事件）

しかし、これは民事訴訟法上の証明度に関する法理であり、百科事典における記述の公開可否や倫理的衡量とは目的を異にします。両者を混同したまま援用した結果、Wikipedia内での「50%ルール」運用が形式化し、本来の趣旨を逸脱する恐れが生じています。

結論

制度的課題の整理 本提案では、こうした初期理念と現行運用との間に生じた制度的齟齬を整理し、方針体系全体の整合性を再検討します。

経緯のまとめ 以上の経緯から、「伝統的運用」および「50%ルール」という語法は、制定当初の限定的な文脈や法概念の転用により、削除判断の基準が明確化されないまま運用されてきたと考えられます。

本提案の目的 本提案は、これらの運用史を踏まえ、削除判断における実質的検討と透明性の確保を目的とするものです。 具体的には、

• 法的根拠の再明確化
• 倫理的配慮と検証可能性の調整
• 判断基準の予測可能性向上

を通じて、より持続的な方針運用を目指します。

論点の整理

以下の点について、コミュニティでの再検討が望まれます：

論点1：「伝統的運用」という表現の妥当性 - 制定経緯を踏まえ、この表現を現行方針にどのように位置づけるべきか。

論点2：法的根拠の明確化 - 個人情報保護法および民法上の根拠条文を、方針文書に明記すべきか。

論点3：「高度の蓋然性」概念の適用範囲 - 民事訴訟法上の概念を、記事の記載判断にどのように適用すべきか。

論点4：倫理的衡量基準の明文化 - 削除判断における倫理的配慮について、より明確な基準を設けるべきか。

議論のお願い

本提案は、削除方針および存命人物に関する方針における「伝統」「蓋然性」「法的根拠」の三点について、制度的な整理を通じて、より透明で予測可能な運用を実現することを目指します。特に以下の点について、皆様のご意見を伺いたく存じます。

• 「50%ルール」の本来の意図と適用範囲
• 「可能性」と「蓋然性」の概念的区別
• 方針文書の明確化・修正の必要性と方法

これらは20年にわたる運用の中で形成されてきた重要な論点であり、多様な視点からの建設的な議論を期待しております。

参考資料

本提案は、以下の資料に基づいています。

方針文書

• WP:DP（削除の方針）
• WP:BLP（存命人物の伝記）
• WP:V（検証可能性）
• WP:NPOV（中立的な観点）
• WP:N（独立記事作成の目安）

過去の議論

• Wikipedia‐ノート:削除の方針/2004年2月16日までの議論 - 50％ルール初出
• Wikipedia‐ノート:削除の方針/2004年4月5日までの議論 - 50%ルールに関する議論
• Wikipedia‐ノート:削除の方針/2005年4月9日までの議論 -「伝統的運用」の提案・法的根拠の先送りに関する議論

判例

• 最高裁昭和48(オ)517判決（東大病院ルンバール事件） - 民集29巻9号1417頁「高度の蓋然性」概念の出典

関連する法令

• 個人情報保護法
• 民法第709条（不法行為）
• 憲法第13条（幸福追求権）

--96points（会話） 2025年10月19日 (日) 06:00 (UTC)

執筆依頼で相次ぐ荒らしについて

参考:「Wikipedia:執筆依頼」の変更履歴（差し戻し済みのもののみ）

先月（2025年9月）下旬から、Wikipedia:執筆依頼のページにおいて荒らしが相次いでいます。私も当該ページをウォッチリストに入れていたため、これまで何度も差し戻しを行ってきました（現在管理活動に起因する自主謹慎期間のため、私の対応は原則差し戻しなどにとどめていました。詳しくは私の利用者ページ・会話ページをご覧ください）。ただ、数日おきに似たような種類の荒らしが発生する状況を見て「これは単なる偶発的なものではないのでは?」と感じました。荒らしが依然相次いでいることから早急な対応が必要と考え、皆様の知恵をお借りしたくこちらの節を立てさせていただきました。（なお、以降に出てくる「本ページ」はWikipedia:執筆依頼のことを指します。）

本ページの荒らしは、こちらの編集を皮切りに、数日に1件以上の頻度で発生するようになりました。内容は主に、ページ中に記事の下書き、あるいは無意味な文や単語などを書くといったものであり、既存の内容を除去せずにちょろっと書くもの（例）と、既存の内容の一部またはすべてを除去したうえで書くもの（例）とがあります。

荒らしをおこなった利用者について気になるところがありました。各利用者について軽く調べてみたところ、本ページあるいは本ノートの荒らし以外に投稿記録がない利用者が23人中13人いることや、「悪意があって荒らしたというより、下書き投稿などを意図して行ったように見える」利用者も一定数いることなどがわかりました。前者に関してはWP:SOCKの可能性も高いですが、アカウントごとに書いている内容・分野がてんでバラバラなことを考えると、SOCKと断定するにはなんだか不自然だと感じました。さらに後者について、複数の善良と思われる利用者が"同じような形で"間違った投稿をしている点も気になります。

ここからはあくまで私の個人的な憶測・邪推にすぎませんが、ウィキペディア外部（SNSや掲示板など）で「ウィキペディアの執筆依頼を荒らそう」あるいは「執筆依頼ページに下書きを投稿しよう」といった呼びかけが行われている可能性も、完全には否定できないのではと感じています。あるいは、何らかの誤った案内（「記事の下書きは執筆依頼ページに書くといい」など）が拡散されているのかもしれません。もちろん、実際には全く別の原因である可能性も高く、私の見立てが誤っている可能性も十分にあります。

なぜこのページで荒らしが頻発しているのか、どのような対策が考えられるかについて、皆様のご意見・ご助言をいただければ幸いです。--Cookie4782（会話 | 投稿記録） 2025年10月20日 (月) 15:01 (UTC)

一般的な対応としては、まずは保護依頼に提出することでしょうか。外部でどのような呼びかけが行われていても、荒らしが狙っているとしても、一般的な対処をまずは考えるべきです。不適切な投稿があまりに気になりすぎるようでしたら、ウォッチリストから外すことをお勧めします。もし本気で自主謹慎期間を掲げてらっしゃるのであれば尚更。--むじんくん（会話） 2025年10月22日 (水) 01:14 (UTC)

返信 コメントありがとうございます。おっしゃる通りです。ウォッチリストからは外しておきました。自主謹慎と言っておきながらある程度管理活動を行ってしまっていたことは面目ない限りです。今後も荒らしが続くようであれば保護依頼はかけますが、昨日一日は荒らしがなかったことも踏まえ今はわたしは何もしないことにしたいと思います。--Cookie4782（会話 | 投稿記録） 2025年10月22日 (水) 03:37 (UTC)

アカウントのノートページを自動で過去ログ化するにはどうすればいいのでしょうか

私のアカウントのノートページは、現在手動で過去ログ化していますが、spボットに過去ログ化をしてもらうにはどうすればいいのでしょうか。FAQを私が見た限りはこの話題の節はありませんでした。--by 221tamtam/Talk 2025年10月24日 (金) 07:46 (UTC)

「Help:過去ログ#自動過去ログ化」をご参照ください。 --Kto2038（会話） 2025年10月24日 (金) 10:11 (UTC)