そもそも論、ホワイトリスト登録を自動承認制にするとブラックリストと呼ばれるべき機能になる気がします。
ロックダウン機能において編集とコメント投稿の制限を個別にできた方が良いという理由に関して書きます。
経験上、wiki利用者は閲覧のみのユーザーが一番多く、ついでコメントを投稿するユーザー、そして一番少ないのが編集に参加するユーザーのように思われます。提案されているロックダウンの仕様は閲覧のみのユーザーには影響がありせんし、編集に参加する熱心なユーザーにも抵抗感は少ないと思います。 しかし、中間層であるコメントを投稿するユーザーは匿名の場でやり取りを好んでいる傾向があり、アカウントを作成してまで利用し続けようとするユーザーは少数派です。
編集・解説がwikiの大きな役割であることは間違いありませんが、コメントによるユーザー間の交流も人気のコンテンツである事もまた事実です。コメントページのビューの多さからコメントのやり取りを見るために定期的に訪れている閲覧のみのユーザーもかなりの割合存在します。そのためロックダウンで一括して制限をかけた場合、wiki利用者の大部分にとってサービスとしての価値が失われた状態になります。 編集やコメント書き込みなど個別に制限を設定できるというのは選択肢の多さであり、個別設定できないよりも柔軟性があり利便性が高いのは明らかな事実です。
そもそもロックダウン機能は果たして荒らし行為に対して有効な対策なのか？という疑問も主張の根底に存在します。仮に荒らし行為が原因で一括のロックダウンを実施したとして、先述の通り多くのユーザーにとっては利用価値が大きく損なわれた状態にるわけであり、それこそが荒らしの思う壺ではないでしょうか？
仮に編集のみのロックダウンならば大半のユーザーに取って影響はありません。しかし、コメントのようなコミュニケーション部分はロックダウン機能との相性が極端に悪く、どちらかといえばミュート機能やシャドウバン、ユーザーが個別に設定できるNGワードなどより適した手段が存在するように思います。
ホワイトリストの自動登録について反対です。他Wikiでは、編集・利用ルールをちゃんと読んでいるかを確認するためのWiki管理者が用意した質問で、アカウント申請時にWiki管理者へのメッセージ欄を設けて回答を求めるようなところもあります。アカウント申請だけで質問に未回答だったりルール未読と判断出来れば、その時点で却下できます。
この仕組みがあれば、ロックダウンのようにすべての投稿を一律にブロックしなくても、 特定のホスト制限やSMS認証が必要な状況でも、 許可されたアカウントだけはそれらの制限を受けずに投稿できるという柔軟な対応が可能になります。
アカウント申請を全て自動承認にすると、BANされても困らないように大量の捨てメアドを用意して、複数アカウント登録されることが想定されます。上記のようなSMS認証の規制をしても回避できてしまうようになるので反対です。
もう少し柔らかく制限したい場合について
ホワイトリストに入っているアカウントに対して、 「コントロールパネル」の「規制ルール」を回避できるオプションを設けることも検討できます。
また、SMS認証が困難な海外在住ユーザーでも、アカウントを通じて投稿できるようになります。
この仕様についても、引き続きご意見をお待ちしています。
申請者のホワイトリスト自動登録について
実質的には「申請ボタン付きのゲスト投稿」となってしまいます。
本来の目的は、大規模な荒らしが発生した際に、投稿者を一時的に絞り込むための緊急対策です。 そのため、自動でホワイトリストに登録してしまう運用は、本来の意図を損なうことになるのではないかと思います。
安全性を確保するため、申請内容を確認してから許可する手動方式を想定しています。 この仕様についても、引き続き皆さまのご意見をお待ちしています。
また、このホワイトリストは今後、「信頼されたアカウント」としての扱いになる可能性があるため、 慎重に進めていく必要があると考えています。
ご不便をおかけして申し訳ありません。
ご利用のネットワークは、Googleが提供するクラウドサーバー（bc.googleusercontent.com）経由となっております。 この経路からは現在も多数の不正アクセスが確認されているため、特定の操作に一部制限をかけさせていただいております。
お手数ですが、別のネットワーク（ご自宅のWi-Fiやスマートフォンの通信など）からのご利用をお願いいたします。
ご確認ありがとうございます。 今後ともよろしくお願いします。
上記2点の変更をこちらでも確認できました。対応ありがとうございます。
不具合のご報告ありがとうございます。 次のように改善しました。
お手数ですが、ご確認のほどよろしくお願い申し上げます。
ご提案頂いた内容に概ね賛成します。アカウント機能については、現状のzawazawaアカウントと統合・再利用されるような形だと非常に分かりやすく、管理もしやすいのではないかと思います。
>> 23さんの仰っているコメントと編集のロックダウン分離については私も反対します。実際、荒らし行為が発生した際、どちらかのみを規制してももう一方で荒らし行為が継続するケースもあり、わざわざ分離するメリットはないかと思います。
当サービスは、誰でも自由に投稿できることを基本としています。 そのため、アカウントを持つ人だけが投稿できるような恒久的な仕組みは設けない方針です。
賛成します。（Wikiとは本来そういうものです）
>> 23 wiki編集とコメント投稿の制限を個別に設定できたほうが…
反対します。「利便性が高く」とありますが、何の利便性が向上するのでしょうか。
これをやると、編集は身内のみ可、ゲストユーザーはコメント投稿のみ可という閉鎖的なWikiが実現できてしまいます。 この機能（ロックダウン）は、閉鎖的なWikiの実現を目的とするものではなく、 あくまで大規模荒らしに対応するための（一時的な）機能であるべきです。
追記：
投稿できるアカウントは申請制とし、 管理者やサブ・パスワード保持者が申請内容を確認し、許可した場合のみ使用可能とします。
ホワイトリスト方式自体に反対はしませんが、 アカウントを申請すると自動でホワイトリストに登録されるようにした方が、 ユーザーの編集参加に対する敷居が低くなり、 閉鎖的なWikiを作ろうとする管理者の恣意的な運用も避けられるのではと思います。
運営が仰るように、 万が一、許可されたアカウントが不正な投稿を行った場合は、 そのアカウントをホワイトリストから削除することで対処すればよいので。 （リスト削除後に、同じID者の再登録をブロックできる機能がないとダメかな？）
追追記：
ホワイトリストの自動登録については反対意見が多いようですね。 運営自体が否定的な見解をお持ちなので、実現性は低いように思いますし、 別にそれでも構わないのですが、 一つ気になるのが「複数のメルアドで複数のアカウントが持てる」と考えている方が多いということです。
そんなザルのようなシステムなら、自動だろうと手動だろうとホワイトリスト方式自体に賛成できかねます。
申請時には、IPアドレス・Cookie・ブラウザ情報（User-Agentなど）もあわせて送信され、 過去の投稿と照らし合わせて、荒らし等の問題がないかを確認するために使用されます。
「同じID者の再登録をブロックできる機能がないとダメかな？」と書きましたが、 ホワイトリストの（自動）登録には、 同一人物が別のアカウントを持とうとする行為を（自動で）BANできる機能が欠かせないように思います。
素人考えでは可能だと思うのですが、 仮に難しいということであれば、ホワイトリストの自動登録は難しいということになるでしょうし、 容易に複数アカウントが持てるシステムということなら、自動・手動以前の問題でしょう。
手動登録の場合は、上に書いたように、身内以外の申請を全て不許可にすることで、 閉鎖的なWikiを作ろうとする管理者に恣意的に運用される可能性があるため、 諸手を挙げての賛成はできないというのが正直な感想です。
ロックダウン機能に関して投稿・編集を制限できるとのことですが、これにはコメントの書き込みも含まれるのでしょうか？
一括で制限するのではなく、zawazawaのようにwiki編集とコメント投稿の制限を個別に設定できたほうが利便性が高く需要に合うと思います。
ご意見ありがとうございます。 これまでに寄せられたユーザーの皆さまのご要望・議論をふまえ、 総合的に検討した結果、以下のような仕様が適切ではないかと考えております。
ロックダウン機能とアカウント制の導入について、 現時点での案を以下にまとめました。
なお、本仕様はあくまで検討中の内容であり、確定ではありません。 今後、皆さまのご意見をいただきながら、柔軟に見直しを行っていく予定です。
仕様の背景と基本的な考え方
ただし、大規模な荒らし行為が発生した場合に備え、 投稿を一時的に制限できる「ロックダウン」機能の導入により、緊急時の対応を可能にしたいと考えています。
仕様内容（ロックダウンとアカウント制）
ロックダウンは、管理者用のコントロールパネルからON/OFFを切り替えることができます。
ロックダウンがONになると、投稿・編集できるのは 「管理者」「サブ・パスワード保持者」「あらかじめ許可されたアカウント」に限定されます。
閲覧はロックダウン中も制限されず、これまで通り誰でも可能です。
投稿できるアカウントは申請制とし、 管理者やサブ・パスワード保持者が申請内容を確認し、許可した場合のみ使用可能とします（ホワイトリスト方式）。
申請時には、IPアドレス・Cookie・ブラウザ情報（User-Agentなど）もあわせて送信され、 過去の投稿と照らし合わせて、荒らし等の問題がないかを確認するために使用されます。 ※ロックダウン後にアカウントを作成した場合でも、過去の投稿と紐づけて判断できるようにするための仕組みです。
アカウント名は投稿ログ（diff_log）には表示されず、匿名性はこれまで通り維持されます。 ※ただし、管理者用のコントロールパネルではアカウント名を確認できます。
万が一、許可されたアカウントが不正な投稿を行った場合は、 そのアカウントをホワイトリストから削除することで対応します。
アカウント機能の設計について
現在、WIKIWIKIには一般ユーザー向けのアカウント機能は存在していません。 そのため、アカウント制を導入する場合は、新たな設計が必要となります。
一方、多くのユーザーがすでにzawazawaアカウントを利用しており、 別々のアカウントを併用する形にすると、ユーザー・運営の双方に管理負担が生じる可能性があります。
今後、WIKIWIKIとzawazawaは運用基盤の統合を予定しているため、 zawazawaアカウントをWIKIWIKI共通アカウントとして再利用する方向も検討中です。
仕様案についてのご確認
この仕様は、ユーザーの皆さまのご意見やこれまでの議論をもとに、運営として整理・検討中の内容です。 あくまで確定したものではなく、今後の調整にあたってもユーザーの皆さまのご意見を参考にしていきます。
この仕様については、引き続きユーザー同士で自由に議論・意見交換を行っていただければと思います。
#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。 inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりま すか。
#
おっしゃる通り、exceptのcounterを抜いてから、想定している挙動になりました。どうもありがとうございます。自身の検証では指摘内容に気づけませんでした。includexがexceptに合致した行は、無視してカウントする仕様だとは思わずに不具合を疑っていました。
不具合を疑うことになった記述内容 #includex(MenuBar,num=14:,except=_now|counter,titlestr=off) 今回の場合、exceptに合致する行が3行あるので実際に表示させたい参照先の指定行が17行目であっても、14行目にするのが正しい
#includex(MenuBar,num=14:,except=_now|counter,titlestr=off)
参照先にaccordionプラグインでincludexプラグインの行を括ると正しく参照しなくなります。
#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。 inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりますか。 機能を疑うなら検討用のページを作って、シンプルな記述にして検証してみてください。
Steamはメジャーなサービスであるとは言え、基本的にはPCゲーム用の限定的なプラットフォームです。 専用プラグインがあるYoutubeやX(Twitter)はSNSサービスであり、どのWIKIでも汎用的に扱うことができますが、 Steamの場合は限定的な用途となってしまい汎用性に欠けると言わざるを得ません。
要望に関して反対はしませんが、個人的には導入された際のメリットがそれほどあるように思えず、 上記の点も考慮すると実装される見込みは薄いのではないかと思います。
編集差分ログを期間指定でcsvファイルとしてダウンロードできるようにすればいいのではないでしょうか。 ただし、ページ内容を除いた情報のみ。 個人的にはそこまで困ってないので、改善するならという意見です。
ローカル環境のエディターやスプレッドシートで解析する分にはサーバー側の負担はないでしょう。 サーバーで準備された限定的な検索サービスより、スプレッドシートのほうが自由度が高く、統計処理、加工、保存できるので利便性があります。 現状だとIPアドレスなど転記して整理してから処置を検討することになるわけで、そういった工程の削減にもなります。 規制ルール作るにしても荒らし以外の巻き込みも気になるので、全書き込み情報から事前のシミュレーションができます。 ローカル処理で必要なdiffを絞り込めるなら、サーバー側を無駄に叩かれる機会も減るかもしれません。 機能にアクセスできるのは管理者だけなので実行負荷は限定的でしょう。多くても月1回の定期ダウロードか、緊急対応で数日中のログが取れればいいでしょう。
吐き出す内容についてはページ本文を除いた情報でいいと思います。本文は情報量が予想できないので。 csvの各行に当該diffページURL(view?did=日時)を記述すれば、必要に応じてそのページに飛んで内容は確認できます。
@wikiwiki
ご回答ありがとうございます。 「いま起きている問題の把握」に重きを置いているとのことですが、そうだとしても一定期間ごとの絞り込みは必要に感じます。 仮にごく短い期間(1日)を対象にしても、日付を跨いで荒らし行為が発生することもあり、たかが2日分とはいえ1日ごとに検索するのは非常に手間になります。 このような点からも、日付を跨いだ検索機能は実装を強く希望します。
各WIKIの「規制ルール」に登録された情報は、多いところで700〜1000件近くにのぼっていますが、その大半が「ヒット数ゼロ」のまま何年も残っているといった例も少なくありません
こちらについてですが、個人的には荒らし行為が発生したとき、IP、ホスト、Cookie...といったようにひとまず各情報を登録することが多いのではないかと考えています。このような場合、当該ユーザーが再度編集を試みてもある1つのルール(登録順が早いルール？)にヒットし、それ以外はヒットしないというケースが発生するのではないかと思いますし、こうして数年以上ヒットしないルールが存在しているように思えます。
返信が遅くなり申し訳ございません。
編集差分ログの検索機能についてですが、以前の「DIFFANA」ではカレンダーで期間を指定して広く検索できましたが、現在の「コントロールパネル」では、「いま起きている問題の把握」を優先した設計にしています。
というのも、IPアドレスやCookieといった揮発性の情報は、時間が経つと変わってしまうため、古い過去ログの情報を現在の投稿規制対応に活かしにくいケースが多いからです。 そもそもこうした情報は、長期的な追跡にはあまり向いておらず、現在のように直近の動きを素早く確認できることを重視した形にしています。
また、実際の運用状況を見ると、各WIKIの「規制ルール」に登録された情報は、多いところで700〜1000件近くにのぼっていますが、その大半が「ヒット数ゼロ」のまま何年も残っているといった例も少なくありません。 こうした現状からも、揮発性の情報による長期的な規制には限界があると考えており、直近の状況把握を重視した設計としています。
さらに、広範囲の検索を可能にすると、サーバーへの負荷も大きくなるため、あえて「その日ごとの確認」に絞ったシンプルな仕様としています。
もちろん、日をまたいで確認したいケースがあることは承知していますので、今回いただいたご意見は、今後の改善検討の参考にさせていただきます。
@wikiwiki 他ユーザーからも賛同いただけていますので、ご検討のほどよろしくお願いいたします。
しばらく経っても不具合が解消されない場合は、恐れ入りますが「リクエスト広場」までご報告いただけますと、早期対応につながります。ご協力いただけますと幸いです。 https://t.co/ToeQrfIT6E— WIKIWIKI（ウキウキ）【公式】 (@WIKIWIKI_Japan) May 3, 2025
しばらく経っても不具合が解消されない場合は、恐れ入りますが「リクエスト広場」までご報告いただけますと、早期対応につながります。ご協力いただけますと幸いです。 https://t.co/ToeQrfIT6E
一つひとつの操作はそれほど大したことがなくて些細なことでも積み重ねれば都度、繰り返していくうちに億劫に感じがちです。
賛成です。他社WikiサービスでもTOPページからお知らせページにアクセスできるようにしていたりして、誰もが気づくことができます。wikiwikiの利用者が他社SNSサービスを使うことに無料だからといって全員、抵抗がないことはないので運営会社のお知らせ方針について、考え直してほしいです。
各wikiサービス事業者のお知らせ
確かに、wikiwikiのアップデートやメンテナンスなどのニッチ情報をSNSで不特定相手に発信しても余り意味ないし、 （ユーザーはアカウント取って積極的にフォローしてくれってこと？） 自社にwikiとの連携も可能な掲示板サービスがある訳だし、 Xになってから問題だらけの外部サービスに依存し続けるより、 zawazawa（wikiwiki official）に発信先を一本化してくれた方がありがたいです。
それと01vさんや>> 2さん同様、自分もXは利用していないので、 01vさんが仰るようにログインしていないと事実上使い物にならなくなった（時系列順に表示されない等）Xはもう…
なので、自分も賛成に1票です。
同意します。
つい先日実装された管理者ログイン機能もX上で告知されていましたが、 >> 1のコメントにあるようにXを利用しないユーザはアナウンスに気づくことが困難と言えます。 (私もXを利用していないため、コントロールパネルを開こうとした際に初めて気づきました）
従いまして、X以外の媒体でも公式アナウンスを行っていただく必要性があるように感じられます。
アップデートや機能仕様の変更についての案内をzawazawaで行うことは賛成です。 理由としては私はx.comをやっておらず、そちらに何か書かれてもわからないからです。 従来はhttps://zawazawa.jp/wikiwiki/ がお知らせページだったと思いますが、現在ここはあまり使われてないようです。 https://x.com/WIKIWIKI_Japan 、このページは一覧がみれますが私には内容が見えません。 また掲載が日付順になってないため、いつ何が変わったのわかりません。ソートや検索もできません。
メンテや変更点の案内は、wikiwikiの管理人や編集をする一部に向けられるものだと思います。 x.comで不特定多数にアピールしても連絡の確実性は低いのではないでしょうか。 逆に自身のサイトにそれらの情報を掲載しないというのは本末転倒な気もします。
@wikiwiki 本トピックに似た2022年の要望にコメントしています。本トピックにも議論は出尽くしたと思われますので運営さんから回答をもらえたらと思います。
別トピックにて、運営は新たなテーブル構想を打ち出しておりますが、本要望も検討されているのかをお伺いしたいです。
この新しい仕組みでは、将来的に、SQLによるデータ抽出やページ切り替え、並び替え、グラフ表示といった処理にも対応できるような拡張性を持たせることも視野に入れています。
トピック閲覧者へ 別トピックにて、運営は新たなテーブル構想を打ち出しており、次のように回答しております。
以下、トピックに対する回答 賛成です。 あらゆる情報をデータベース化しているテーブルが肥大化するにつれ、従来のままではWiki利用者にとって使いづらくなっていきます。
現状はネットワーク負荷の分散の意味合いも込めて、一つのテーブルに纏めずに分離するしか方法はありません。
編集者目線で行列を取捨選択したテーブルではなく、私が2023年に提案したトピックのように利用者目線で選択したテーブルに出来るようにして欲しいです。
@wikiwiki 本トピックに限らず、テーブルに対する機能の拡張強化の要望がこれまでにも出ています。ご対応をお願いします。
フィルタリング機能を調べていてこちらのリクエストを発見したので、同じように追加を希望します。 現在wikiwikiで使えるテーブルソートだけでは、大きなテーブルで検索をかけるのが非常に厳しい状況です。 https://arknights.wikiru.jp/?★6 こちらのページのような、ソートとフィルターを同時に行えることの出来るTable_editプラグインの実装を考慮して頂けると助かります。
wikiwiki.jpの内容 テキスト量が大きいため、パフォーマンス悪化を防ぐために構文ハイライトモードをOFFにしました。 これに該当するページで再適用させる場合、「確認のOKを押す → 構文ハイライトモードをONに再設定 → 確認のOKを押す」といった作業が毎回必要になるため、とても煩わしいです。
構文ハイライトモード実装によってメリットも感じていますが、トピック主のように煩わしさも同時に感じています。
テキスト量の多いページは有無を言わせずに強制的にダイアログ表示することなく、構文ハイライトモードOFFにしてしまうのも一手かもしれません。その後、編集者が必要に応じて構文ハイライトモードをONに再設定して、ダイアログ表示の確認のOKを押すという感じにすると確認の手間を省略できて時間効率も良い感じになるのではないでしょうか。
>> 2さんと同じく、あまり必要性を感じられません。 無条件にONになってしまうと(初回はOFFだとしても)その時のデバイスの状態によって閲覧が難しくなってしまうリスクもあり、現在の仕様で問題無いかと思っています。 編集に関わる身としてそこまで切り替えに手間を感じませんが、しいていうなら警告メッセージのダイアログ表示は無くてもよいのではと思います(チェックボックス部分に警告メッセージが表記されていれば十分かと)。
「確認の表示を常に非表示にする」という機能については>> 2の方の考えに同意するため、賛成しかねます。
ただ、「構文ハイライトモードを常にONにする」機能については実装をしてほしいと考えます。 テキスト量が多い、ページの描画速度を上げたいなどの理由で編集中一時的に構文ハイライトをoffにしたとき、 次回他のページを編集する際に構文ハイライトがoffの状態から始まるのが煩わしいためです。 また、テキスト量が多いページを含む複数ページを一括で別タブに開いた場合も、テキスト量が多いページ以降に読み込まれたタブが全てハイライトoffになってしまうというケースも度々あります。 かなり限定的な場面での用途になるため、優先度は低いかと思いますが、ご検討をいただきたいです。
現在、回答にお時間をいただいておりますが、 もう少々お待ちいただけますと幸いです。🙇♂️
かつてはページを凍結しても投稿出来ましたが、 2020.04.01から仕様が変わり、投稿不可になりました。 凍結されたまま管理放棄されたWikiの荒らしコメントが削除不可になるのを防ぐためだそうです。 （運営に直接伺いました） 理由があっての仕様変更なので、貴方の要望は叶わないでしょう。
理由については何を言っているのかよくわかりませんが、 コメント欄に画像を入れるのは普通にできますよ。 （入力アシストツールの右から4番目のボタン＝クリップマーク）
ただ、写真提供？を目的にコメントページに画像アップするのは迷惑行為になりかねないのでやめた方が良いと思いますが。 コメント欄に「車両一覧に写真を追加したいので、管理者の方は凍結解除してください」と投稿するのが筋かと。
理由は、例えばそのサイトがバスの車両の一覧wikiだとすると、車両の写真が必要となります。また、嵐防止のため、凍結しているとなると、写真提供ができないため、コメント欄に画像を入れられるようにしていただきたいです。
2025/05/26メンテナンスで修正が確認できたためクローズします
賛成ですね。 やはり、仮に、荒らしに遭った際などに復旧または、荒らしに防止のためにサイト全体の編集制限をすると、管理人の編集もできなくなってしまうので、この機能があった方が良いと思いますので、@wikiwikiの方はこの機能を追加していただきたいと思っております。 どうぞよろしくお願いします🙏
「他社のレンタルWikiとひたすら同じ方向性を打ち出しても仕方ない」という意味では、現状のシンプルで分かりやすい(誰でもすぐ編集できる)方向性は十分に実績を築いていると思います。
でも
荒らし対策の半凍結運用ページ編集時、凍結解除〜即再凍結の流れが面倒 →凍結フラグの扱いが「編集に管理パスワード必須」になれば便利で助かる……
という管理者都合はちょっとあるかも。
Apple Musicを埋め込み形式で表示しようと「Embedプラグイン」と「embedが含まれたURL」の両方で試してみたのですが上手くいきませんでした。
大量のテキストを1ページに詰め込むのは、ページ負荷やソース可読性の観点から好ましい状態とは言えません。
メッセージが表示されるのは、そのような状況に対して注意を促す意図も含まれていると解釈していますので、それを変えてしまうのは賛成しかねます。
また、対策としてページ分割や部分編集を利用するなど運用で十分カバー可能なため、個人的には実装の必要性は感じられません。
そもそも論、ホワイトリスト登録を自動承認制にするとブラックリストと呼ばれるべき機能になる気がします。
ロックダウン機能において編集とコメント投稿の制限を個別にできた方が良いという理由に関して書きます。
経験上、wiki利用者は閲覧のみのユーザーが一番多く、ついでコメントを投稿するユーザー、そして一番少ないのが編集に参加するユーザーのように思われます。提案されているロックダウンの仕様は閲覧のみのユーザーには影響がありせんし、編集に参加する熱心なユーザーにも抵抗感は少ないと思います。
しかし、中間層であるコメントを投稿するユーザーは匿名の場でやり取りを好んでいる傾向があり、アカウントを作成してまで利用し続けようとするユーザーは少数派です。
編集・解説がwikiの大きな役割であることは間違いありませんが、コメントによるユーザー間の交流も人気のコンテンツである事もまた事実です。コメントページのビューの多さからコメントのやり取りを見るために定期的に訪れている閲覧のみのユーザーもかなりの割合存在します。そのためロックダウンで一括して制限をかけた場合、wiki利用者の大部分にとってサービスとしての価値が失われた状態になります。
編集やコメント書き込みなど個別に制限を設定できるというのは選択肢の多さであり、個別設定できないよりも柔軟性があり利便性が高いのは明らかな事実です。
そもそもロックダウン機能は果たして荒らし行為に対して有効な対策なのか？という疑問も主張の根底に存在します。仮に荒らし行為が原因で一括のロックダウンを実施したとして、先述の通り多くのユーザーにとっては利用価値が大きく損なわれた状態にるわけであり、それこそが荒らしの思う壺ではないでしょうか？
仮に編集のみのロックダウンならば大半のユーザーに取って影響はありません。しかし、コメントのようなコミュニケーション部分はロックダウン機能との相性が極端に悪く、どちらかといえばミュート機能やシャドウバン、ユーザーが個別に設定できるNGワードなどより適した手段が存在するように思います。
ホワイトリストの自動登録について反対です。他Wikiでは、編集・利用ルールをちゃんと読んでいるかを確認するためのWiki管理者が用意した質問で、アカウント申請時にWiki管理者へのメッセージ欄を設けて回答を求めるようなところもあります。アカウント申請だけで質問に未回答だったりルール未読と判断出来れば、その時点で却下できます。
アカウント申請を全て自動承認にすると、BANされても困らないように大量の捨てメアドを用意して、複数アカウント登録されることが想定されます。上記のようなSMS認証の規制をしても回避できてしまうようになるので反対です。
もう少し柔らかく制限したい場合について
ホワイトリストに入っているアカウントに対して、
「コントロールパネル」の「規制ルール」を回避できるオプションを設けることも検討できます。
この仕組みがあれば、ロックダウンのようにすべての投稿を一律にブロックしなくても、
特定のホスト制限やSMS認証が必要な状況でも、
許可されたアカウントだけはそれらの制限を受けずに投稿できるという柔軟な対応が可能になります。
また、SMS認証が困難な海外在住ユーザーでも、アカウントを通じて投稿できるようになります。
この仕様についても、引き続きご意見をお待ちしています。
申請者のホワイトリスト自動登録について
実質的には「申請ボタン付きのゲスト投稿」となってしまいます。
本来の目的は、大規模な荒らしが発生した際に、投稿者を一時的に絞り込むための緊急対策です。
そのため、自動でホワイトリストに登録してしまう運用は、本来の意図を損なうことになるのではないかと思います。
安全性を確保するため、申請内容を確認してから許可する手動方式を想定しています。
この仕様についても、引き続き皆さまのご意見をお待ちしています。
また、このホワイトリストは今後、「信頼されたアカウント」としての扱いになる可能性があるため、
慎重に進めていく必要があると考えています。
ご不便をおかけして申し訳ありません。
ご利用のネットワークは、Googleが提供するクラウドサーバー（bc.googleusercontent.com）経由となっております。
この経路からは現在も多数の不正アクセスが確認されているため、特定の操作に一部制限をかけさせていただいております。
お手数ですが、別のネットワーク（ご自宅のWi-Fiやスマートフォンの通信など）からのご利用をお願いいたします。
ご確認ありがとうございます。
今後ともよろしくお願いします。
上記2点の変更をこちらでも確認できました。対応ありがとうございます。
不具合のご報告ありがとうございます。
次のように改善しました。
お手数ですが、ご確認のほどよろしくお願い申し上げます。
ご提案頂いた内容に概ね賛成します。アカウント機能については、現状のzawazawaアカウントと統合・再利用されるような形だと非常に分かりやすく、管理もしやすいのではないかと思います。
>> 23さんの仰っているコメントと編集のロックダウン分離については私も反対します。実際、荒らし行為が発生した際、どちらかのみを規制してももう一方で荒らし行為が継続するケースもあり、わざわざ分離するメリットはないかと思います。
賛成します。（Wikiとは本来そういうものです）
反対します。「利便性が高く」とありますが、何の利便性が向上するのでしょうか。
これをやると、編集は身内のみ可、ゲストユーザーはコメント投稿のみ可という閉鎖的なWikiが実現できてしまいます。
この機能（ロックダウン）は、閉鎖的なWikiの実現を目的とするものではなく、
あくまで大規模荒らしに対応するための（一時的な）機能であるべきです。
追記：
ホワイトリスト方式自体に反対はしませんが、
アカウントを申請すると自動でホワイトリストに登録されるようにした方が、
ユーザーの編集参加に対する敷居が低くなり、
閉鎖的なWikiを作ろうとする管理者の恣意的な運用も避けられるのではと思います。
運営が仰るように、
万が一、許可されたアカウントが不正な投稿を行った場合は、
そのアカウントをホワイトリストから削除することで対処すればよいので。
（リスト削除後に、同じID者の再登録をブロックできる機能がないとダメかな？）
追追記：
ホワイトリストの自動登録については反対意見が多いようですね。
運営自体が否定的な見解をお持ちなので、実現性は低いように思いますし、
別にそれでも構わないのですが、
一つ気になるのが「複数のメルアドで複数のアカウントが持てる」と考えている方が多いということです。
そんなザルのようなシステムなら、自動だろうと手動だろうとホワイトリスト方式自体に賛成できかねます。
「同じID者の再登録をブロックできる機能がないとダメかな？」と書きましたが、
ホワイトリストの（自動）登録には、
同一人物が別のアカウントを持とうとする行為を（自動で）BANできる機能が欠かせないように思います。
素人考えでは可能だと思うのですが、
仮に難しいということであれば、ホワイトリストの自動登録は難しいということになるでしょうし、
容易に複数アカウントが持てるシステムということなら、自動・手動以前の問題でしょう。
手動登録の場合は、上に書いたように、身内以外の申請を全て不許可にすることで、
閉鎖的なWikiを作ろうとする管理者に恣意的に運用される可能性があるため、
諸手を挙げての賛成はできないというのが正直な感想です。
ロックダウン機能に関して投稿・編集を制限できるとのことですが、これにはコメントの書き込みも含まれるのでしょうか？
一括で制限するのではなく、zawazawaのようにwiki編集とコメント投稿の制限を個別に設定できたほうが利便性が高く需要に合うと思います。
ご意見ありがとうございます。
これまでに寄せられたユーザーの皆さまのご要望・議論をふまえ、
総合的に検討した結果、以下のような仕様が適切ではないかと考えております。
ロックダウン機能とアカウント制の導入について、
現時点での案を以下にまとめました。
なお、本仕様はあくまで検討中の内容であり、確定ではありません。
今後、皆さまのご意見をいただきながら、柔軟に見直しを行っていく予定です。
仕様の背景と基本的な考え方
当サービスは、誰でも自由に投稿できることを基本としています。
そのため、アカウントを持つ人だけが投稿できるような恒久的な仕組みは設けない方針です。
ただし、大規模な荒らし行為が発生した場合に備え、
投稿を一時的に制限できる「ロックダウン」機能の導入により、緊急時の対応を可能にしたいと考えています。
仕様内容（ロックダウンとアカウント制）
ロックダウンは、管理者用のコントロールパネルからON/OFFを切り替えることができます。
ロックダウンがONになると、投稿・編集できるのは
「管理者」「サブ・パスワード保持者」「あらかじめ許可されたアカウント」に限定されます。
閲覧はロックダウン中も制限されず、これまで通り誰でも可能です。
投稿できるアカウントは申請制とし、
管理者やサブ・パスワード保持者が申請内容を確認し、許可した場合のみ使用可能とします（ホワイトリスト方式）。
申請時には、IPアドレス・Cookie・ブラウザ情報（User-Agentなど）もあわせて送信され、
過去の投稿と照らし合わせて、荒らし等の問題がないかを確認するために使用されます。
※ロックダウン後にアカウントを作成した場合でも、過去の投稿と紐づけて判断できるようにするための仕組みです。
アカウント名は投稿ログ（diff_log）には表示されず、匿名性はこれまで通り維持されます。
※ただし、管理者用のコントロールパネルではアカウント名を確認できます。
万が一、許可されたアカウントが不正な投稿を行った場合は、
そのアカウントをホワイトリストから削除することで対応します。
アカウント機能の設計について
現在、WIKIWIKIには一般ユーザー向けのアカウント機能は存在していません。
そのため、アカウント制を導入する場合は、新たな設計が必要となります。
一方、多くのユーザーがすでにzawazawaアカウントを利用しており、
別々のアカウントを併用する形にすると、ユーザー・運営の双方に管理負担が生じる可能性があります。
今後、WIKIWIKIとzawazawaは運用基盤の統合を予定しているため、
zawazawaアカウントをWIKIWIKI共通アカウントとして再利用する方向も検討中です。
仕様案についてのご確認
この仕様は、ユーザーの皆さまのご意見やこれまでの議論をもとに、運営として整理・検討中の内容です。
あくまで確定したものではなく、今後の調整にあたってもユーザーの皆さまのご意見を参考にしていきます。
この仕様については、引き続きユーザー同士で自由に議論・意見交換を行っていただければと思います。
おっしゃる通り、exceptのcounterを抜いてから、想定している挙動になりました。どうもありがとうございます。自身の検証では指摘内容に気づけませんでした。includexがexceptに合致した行は、無視してカウントする仕様だとは思わずに不具合を疑っていました。
不具合を疑うことになった記述内容
#includex(MenuBar,num=14:,except=_now|counter,titlestr=off)今回の場合、exceptに合致する行が3行あるので実際に表示させたい参照先の指定行が17行目であっても、14行目にするのが正しい
#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。
inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりますか。
機能を疑うなら検討用のページを作って、シンプルな記述にして検証してみてください。
Steamはメジャーなサービスであるとは言え、基本的にはPCゲーム用の限定的なプラットフォームです。
専用プラグインがあるYoutubeやX(Twitter)はSNSサービスであり、どのWIKIでも汎用的に扱うことができますが、
Steamの場合は限定的な用途となってしまい汎用性に欠けると言わざるを得ません。
要望に関して反対はしませんが、個人的には導入された際のメリットがそれほどあるように思えず、
上記の点も考慮すると実装される見込みは薄いのではないかと思います。
編集差分ログを期間指定でcsvファイルとしてダウンロードできるようにすればいいのではないでしょうか。
ただし、ページ内容を除いた情報のみ。
個人的にはそこまで困ってないので、改善するならという意見です。
ローカル環境のエディターやスプレッドシートで解析する分にはサーバー側の負担はないでしょう。
サーバーで準備された限定的な検索サービスより、スプレッドシートのほうが自由度が高く、統計処理、加工、保存できるので利便性があります。
現状だとIPアドレスなど転記して整理してから処置を検討することになるわけで、そういった工程の削減にもなります。
規制ルール作るにしても荒らし以外の巻き込みも気になるので、全書き込み情報から事前のシミュレーションができます。
ローカル処理で必要なdiffを絞り込めるなら、サーバー側を無駄に叩かれる機会も減るかもしれません。
機能にアクセスできるのは管理者だけなので実行負荷は限定的でしょう。多くても月1回の定期ダウロードか、緊急対応で数日中のログが取れればいいでしょう。
吐き出す内容についてはページ本文を除いた情報でいいと思います。本文は情報量が予想できないので。
csvの各行に当該diffページURL(view?did=日時)を記述すれば、必要に応じてそのページに飛んで内容は確認できます。
@wikiwiki
ご回答ありがとうございます。
「いま起きている問題の把握」に重きを置いているとのことですが、そうだとしても一定期間ごとの絞り込みは必要に感じます。
仮にごく短い期間(1日)を対象にしても、日付を跨いで荒らし行為が発生することもあり、たかが2日分とはいえ1日ごとに検索するのは非常に手間になります。
このような点からも、日付を跨いだ検索機能は実装を強く希望します。
こちらについてですが、個人的には荒らし行為が発生したとき、IP、ホスト、Cookie...といったようにひとまず各情報を登録することが多いのではないかと考えています。このような場合、当該ユーザーが再度編集を試みてもある1つのルール(登録順が早いルール？)にヒットし、それ以外はヒットしないというケースが発生するのではないかと思いますし、こうして数年以上ヒットしないルールが存在しているように思えます。
返信が遅くなり申し訳ございません。
編集差分ログの検索機能についてですが、以前の「DIFFANA」ではカレンダーで期間を指定して広く検索できましたが、現在の「コントロールパネル」では、「いま起きている問題の把握」を優先した設計にしています。
というのも、IPアドレスやCookieといった揮発性の情報は、時間が経つと変わってしまうため、古い過去ログの情報を現在の投稿規制対応に活かしにくいケースが多いからです。
そもそもこうした情報は、長期的な追跡にはあまり向いておらず、現在のように直近の動きを素早く確認できることを重視した形にしています。
また、実際の運用状況を見ると、各WIKIの「規制ルール」に登録された情報は、多いところで700〜1000件近くにのぼっていますが、その大半が「ヒット数ゼロ」のまま何年も残っているといった例も少なくありません。
こうした現状からも、揮発性の情報による長期的な規制には限界があると考えており、直近の状況把握を重視した設計としています。
さらに、広範囲の検索を可能にすると、サーバーへの負荷も大きくなるため、あえて「その日ごとの確認」に絞ったシンプルな仕様としています。
もちろん、日をまたいで確認したいケースがあることは承知していますので、今回いただいたご意見は、今後の改善検討の参考にさせていただきます。
@wikiwiki
他ユーザーからも賛同いただけていますので、ご検討のほどよろしくお願いいたします。
お知らせページが存在すれば、その場で利用者が気づいた点や不具合はフィードバックできます。zawazawaならメンション機能を使えます。現状だと利用者が利用サービスを変えてアクセスしないといけないので手間がかかります。PCならブラウザ内で完結しますがタブ移動は必要です。モバイル端末ではXアプリからブラウザに切替してタブ移動をする必要があります。モバイル端末を使ってブラウザ上でXを閲覧している人も限られているかと思います。また、Xにログインしないとユーザーが過去に発した投稿を検索することもできない不都合があります。
一つひとつの操作はそれほど大したことがなくて些細なことでも積み重ねれば都度、繰り返していくうちに億劫に感じがちです。
賛成です。他社WikiサービスでもTOPページからお知らせページにアクセスできるようにしていたりして、誰もが気づくことができます。wikiwikiの利用者が他社SNSサービスを使うことに無料だからといって全員、抵抗がないことはないので運営会社のお知らせ方針について、考え直してほしいです。
各wikiサービス事業者のお知らせ
確かに、wikiwikiのアップデートやメンテナンスなどのニッチ情報をSNSで不特定相手に発信しても余り意味ないし、
（ユーザーはアカウント取って積極的にフォローしてくれってこと？）
自社にwikiとの連携も可能な掲示板サービスがある訳だし、
Xになってから問題だらけの外部サービスに依存し続けるより、
zawazawa（wikiwiki official）に発信先を一本化してくれた方がありがたいです。
それと01vさんや>> 2さん同様、自分もXは利用していないので、
01vさんが仰るようにログインしていないと事実上使い物にならなくなった（時系列順に表示されない等）Xはもう…
なので、自分も賛成に1票です。
同意します。
つい先日実装された管理者ログイン機能もX上で告知されていましたが、
>> 1のコメントにあるようにXを利用しないユーザはアナウンスに気づくことが困難と言えます。
(私もXを利用していないため、コントロールパネルを開こうとした際に初めて気づきました）
従いまして、X以外の媒体でも公式アナウンスを行っていただく必要性があるように感じられます。
アップデートや機能仕様の変更についての案内をzawazawaで行うことは賛成です。
理由としては私はx.comをやっておらず、そちらに何か書かれてもわからないからです。
従来はhttps://zawazawa.jp/wikiwiki/ がお知らせページだったと思いますが、現在ここはあまり使われてないようです。
https://x.com/WIKIWIKI_Japan 、このページは一覧がみれますが私には内容が見えません。
また掲載が日付順になってないため、いつ何が変わったのわかりません。ソートや検索もできません。
メンテや変更点の案内は、wikiwikiの管理人や編集をする一部に向けられるものだと思います。
x.comで不特定多数にアピールしても連絡の確実性は低いのではないでしょうか。
逆に自身のサイトにそれらの情報を掲載しないというのは本末転倒な気もします。
@wikiwiki
本トピックに似た2022年の要望にコメントしています。本トピックにも議論は出尽くしたと思われますので運営さんから回答をもらえたらと思います。
別トピックにて、運営は新たなテーブル構想を打ち出しておりますが、本要望も検討されているのかをお伺いしたいです。
トピック閲覧者へ
別トピックにて、運営は新たなテーブル構想を打ち出しており、次のように回答しております。
以下、トピックに対する回答
賛成です。
あらゆる情報をデータベース化しているテーブルが肥大化するにつれ、従来のままではWiki利用者にとって使いづらくなっていきます。
現状はネットワーク負荷の分散の意味合いも込めて、一つのテーブルに纏めずに分離するしか方法はありません。
編集者目線で行列を取捨選択したテーブルではなく、私が2023年に提案したトピックのように利用者目線で選択したテーブルに出来るようにして欲しいです。
@wikiwiki
本トピックに限らず、テーブルに対する機能の拡張強化の要望がこれまでにも出ています。ご対応をお願いします。
フィルタリング機能を調べていてこちらのリクエストを発見したので、同じように追加を希望します。
現在wikiwikiで使えるテーブルソートだけでは、大きなテーブルで検索をかけるのが非常に厳しい状況です。
https://arknights.wikiru.jp/?★6
こちらのページのような、ソートとフィルターを同時に行えることの出来るTable_editプラグインの実装を考慮して頂けると助かります。
構文ハイライトモード実装によってメリットも感じていますが、トピック主のように煩わしさも同時に感じています。
テキスト量の多いページは有無を言わせずに強制的にダイアログ表示することなく、構文ハイライトモードOFFにしてしまうのも一手かもしれません。その後、編集者が必要に応じて構文ハイライトモードをONに再設定して、ダイアログ表示の確認のOKを押すという感じにすると確認の手間を省略できて時間効率も良い感じになるのではないでしょうか。
>> 2さんと同じく、あまり必要性を感じられません。
無条件にONになってしまうと(初回はOFFだとしても)その時のデバイスの状態によって閲覧が難しくなってしまうリスクもあり、現在の仕様で問題無いかと思っています。
編集に関わる身としてそこまで切り替えに手間を感じませんが、しいていうなら警告メッセージのダイアログ表示は無くてもよいのではと思います(チェックボックス部分に警告メッセージが表記されていれば十分かと)。
「確認の表示を常に非表示にする」という機能については>> 2の方の考えに同意するため、賛成しかねます。
ただ、「構文ハイライトモードを常にONにする」機能については実装をしてほしいと考えます。
テキスト量が多い、ページの描画速度を上げたいなどの理由で編集中一時的に構文ハイライトをoffにしたとき、
次回他のページを編集する際に構文ハイライトがoffの状態から始まるのが煩わしいためです。
また、テキスト量が多いページを含む複数ページを一括で別タブに開いた場合も、テキスト量が多いページ以降に読み込まれたタブが全てハイライトoffになってしまうというケースも度々あります。
かなり限定的な場面での用途になるため、優先度は低いかと思いますが、ご検討をいただきたいです。
現在、回答にお時間をいただいておりますが、
もう少々お待ちいただけますと幸いです。🙇♂️
かつてはページを凍結しても投稿出来ましたが、
2020.04.01から仕様が変わり、投稿不可になりました。
凍結されたまま管理放棄されたWikiの荒らしコメントが削除不可になるのを防ぐためだそうです。
（運営に直接伺いました）
理由があっての仕様変更なので、貴方の要望は叶わないでしょう。
理由については何を言っているのかよくわかりませんが、
コメント欄に画像を入れるのは普通にできますよ。
（入力アシストツールの右から4番目のボタン＝クリップマーク）
ただ、写真提供？を目的にコメントページに画像アップするのは迷惑行為になりかねないのでやめた方が良いと思いますが。
コメント欄に「車両一覧に写真を追加したいので、管理者の方は凍結解除してください」と投稿するのが筋かと。
理由は、例えばそのサイトがバスの車両の一覧wikiだとすると、車両の写真が必要となります。また、嵐防止のため、凍結しているとなると、写真提供ができないため、コメント欄に画像を入れられるようにしていただきたいです。
2025/05/26メンテナンスで修正が確認できたためクローズします
賛成ですね。
やはり、仮に、荒らしに遭った際などに復旧または、荒らしに防止のためにサイト全体の編集制限をすると、管理人の編集もできなくなってしまうので、この機能があった方が良いと思いますので、@wikiwikiの方はこの機能を追加していただきたいと思っております。
どうぞよろしくお願いします🙏
「他社のレンタルWikiとひたすら同じ方向性を打ち出しても仕方ない」という意味では、現状のシンプルで分かりやすい(誰でもすぐ編集できる)方向性は十分に実績を築いていると思います。
でも
荒らし対策の半凍結運用ページ編集時、凍結解除〜即再凍結の流れが面倒
→凍結フラグの扱いが「編集に管理パスワード必須」になれば便利で助かる……
という管理者都合はちょっとあるかも。
Apple Musicを埋め込み形式で表示しようと「Embedプラグイン」と「embedが含まれたURL」の両方で試してみたのですが上手くいきませんでした。
大量のテキストを1ページに詰め込むのは、ページ負荷やソース可読性の観点から好ましい状態とは言えません。
メッセージが表示されるのは、そのような状況に対して注意を促す意図も含まれていると解釈していますので、それを変えてしまうのは賛成しかねます。
また、対策としてページ分割や部分編集を利用するなど運用で十分カバー可能なため、個人的には実装の必要性は感じられません。