ウェブログ・ハンドブックの感想を書く前に、Wiki Wayの感想を今は亡きIPWiki（IdeaProcessorWiki）のログ（DBアーカイブの生データしか残ってないよ）からサルベージしておこう。

---

「Wiki way―コラボレーションツールWiki」を買ってきたんで、それを読みつつIPWikiを作る際に参考になりそうな部分をメモしていく。

ブランクページへのリンクを明示する

今のところ、ブランクページへのリンク（まだ存在しないページを[[]]で囲った場合）と存在するページへのリンクは、特に表示上見分けられなくてもいいかな（リンクをクリックした後に解釈する）と思っていた。

けれど、Wiki的なコンテンツ増加アプローチにおいては、ブランクページへのリンクを明示することは重要らしい。ブランクページへのリンクを明示するというのは、そのページは今後（誰かが）記述すべきコンテンツであるということを閲覧者に意識させ、できる限りブランクページをなくさせようとする力となる。

という利点は納得できるものなので、やっぱりブランクページへのリンクはきちんと明示するようにしよう。

検索機能が重要

Wikiにおいては、思ったよりも検索機能が重要なようだ。ページがフラットに管理されていて、目次的な要素がさほど強力でない部分を、すべて検索機能で解決するというアプローチを取っているらしい。 具体的にどういう検索機能でどういう機能を実現しているのかは、もうちょっと読み進めてからまとめてみる。

逆リンク検索

検索機能の一つとして、逆リンク検索がある。あるページにリンクしているページを探すための機能だ。これはWikiシステムにおける重要な検索機能となる。

ある話題に関して検索したい人は、その検索キーワードがタイトルに含まれるページをまず検索する。それによって、その情報への一次情報（である可能性が高い）ページを見つけることができる。さらに、そのページへの逆リンクページを検索することによって、その情報への二次情報（である可能性が高い）ページを見つけることができる。

つまり、このような仕組みによって、コンテンツの全文検索を使わなくても、シンプルで高速なタイトル検索だけで、ある話題に関する主要なページを一通り検索することができるわけだ。Wikiにおいては、「ページ名＝検索キーワード」となるのが自然であることを利用した仕組みだと言えるだろう。

と、逆リンク機能の効用について、勝手に先読みして理解してみたんだけど、オリジナルのWikiでは逆リンクを検索するために、フルテキスト検索をしているみたいだなー。まあ英語だからフルテキスト検索もさほど負荷が高くないし、そういうことになっているのかな。

日本語においてはフルテキスト検索の負荷は高くなりがちだし、上記のような観点から逆リンク検索（ページ間のリンク検索）を充実させる（逆リンク用のインデックスを用意して、検索負荷を軽くする）というのはありかもしれない。

ちなみに、オリジナルWikiでは逆リンク検索機能を通常のリンク表現で記述していたところ、検索エンジンのロボットが検索機能を一通りクローリングしていくため、サーバー負荷が大きくなってしまうという弊害が生じたそうな。で、現在は逆リンク検索機能はわざわざSubmitボタンで表現して検索ロボット対策しているんだとか。

署名を逆リンク検索

署名ページで逆リンク検索を行うと、その人が書いたページが出てくるってのは、なかなか有用な機能だなー。でもIPWikiにおいては署名欄はページ外にあるんで、別インターフェースで管理することになっちゃいそうだ。

日本語対応の検索機能

日本語版において充実した検索機能を実現するためには、何らかの検索インデックスを作成する必要があるだろう。

少なくともページの逆リンク検索などは、フルテキスト検索ではなく、あらかじめ用意した検索インデックスに対して行うように変更した方がいい。ただしそのような検索インデックスを用意することによって、Wikiの手軽さ（ポータビリティ）はある程度失われるだろう。

あるいはNamazuなどのような、外部の日本語全文検索エンジンと連携することも、考える必要があるかもしれない。

キーワード検索の実装例

単純に「あるキーワードが使われているページ」を検索するだけでなく、

• 「あるキーワードが使われているページ」＋「そのページからリンクを張られているページ」＋「そのページにリンクを張っているページ」

まで一気に検索してしまい、そこに（重複して）現れたページを重複数をキーにソートして検索結果として出力することで、

• 「あるキーワードと深い関係がある（けれども、直接そのキーワードは使われていないかもしれない）ページを検索する」

ことができるかも。

たとえばDVD-RAMで検索する場合を考えると、もちろん「DVD-RAM」というキーワードが使われているページは「DVD-RAM」と関係したページだろう。

でも、「DVD-RAM」というキーワードが使われていなかったとしても、「DVD-RAM」というキーワードが使われたページからリンクが張られているページや、「DVD-RAM」というキーワードが使われたページにリンクを張っているページは、もちろんDVD-RAMとなんらかの関係があるページだ。

たとえ「DVD-RAM」というキーワードが使われていなかったとしても、それらのページに重複してリンク・被リンクされているページは、DVD-RAMというキーワードとの関係は非常に大きいと考えられる。

全文検索を実装する代わりに、検索インデックスを充実させて、こういったインテリジェント（？）な検索（だが負荷は全文検索よりは軽い）を実装することによって、Wiki的キーワードのつながりを表現する手もあるだろう。

ページ命名規則

やっぱり英語でもページ名の命名規則については、かなりいろいろな問題があるようだ。重要なキーワードになる部分だけれども自由度が高いから、揺らぎが大きくなっちゃうと大変だもんね。

で、英語においては単数形・複数形という日本語にはない問題があるけれども、それに関してはできるだけ単数形を使おうというポリシーが一般的だそうな。ただし、あくまでもポリシーであって、システム的な制約ではない模様。システム的に警告を出したりする実装もあるらしいけど。

あと、階層構造も名前空間もないWikiにおいては、ユーザーがページ名をつけるときに意識して名前空間ライクなことをしなければならない。あるページから派生したページを作成するときは、元ページ名の後ろに派生要素の単語を付加するような形で、ページ名をつけるというポリシーで対策している場合が多いらしい。

結局最終的にはユーザーがそのあたりを管理しろと言うことらしく、ちょっと初心者には敷居が高い感じがするね。

俺的にはそのあたり、限りなく掲示板ライクな使用感で使えるようにしつつ（適当に投稿するだけ）、使おうと思ったときにはWikiライクに使える（ページ名や他ページへのリンク、再編集などを意識する）ようにしたいなー。

そのためには、ページ名、名前空間＋ページ名、ページsidの3パターンのページに対する表現をうまく使い分けて、ユーザーインターフェースでそのあたりの違いを吸収する方針でいきたい。できれば掲示板ライクに使っていたユーザーも、慣れてくると段階的にwikiライクな使い方ができるようになっていくような、うまいUIが作れればいいんだけど。

主なWiki修飾フォーマット

段落の終端を空白行で表す。おそらくあらゆるブロック要素が空白行で終端となるんじゃないかな？　で、通常の段落の開始は特に明示せず、システムが暗黙のうちに開始する感じだと思われる。

「」ではじまる行は<UL><LI></UL>相当の番号なしリストになる。などと複数個重ねるとリストの階層化ができる。これはそのままサポートしてもいいかな。リストの終端は空白行なんだろうか？　それとも以外で始まる行があったらそこで終わりにするのか？

「#」ではじまる行は、<OL><LI></OL>相当の番号付きリストになる。でも#は一部ソースコードでコメント行の開始を意味するから、あんまり使いたくないなー。

空白（半角スペース？）で始まる行は<PRE></PRE>相当の整形済みテキストになるらしい。けど、ソースコードとかの行頭にいちいち半角スペースを埋めるのはいやだから、これも採用したくないなー。

「----（4つ以上）」は<HR>になる。これは採用してもいいけれども、段落指向な場合は段落中に<HR>なんて使いたくなることがあるだろうか？

「!」ではじまる行は<H1>〜<H6>相当の見出しタグになるらしい。けれども、IPWikiにおいては見出しは段落タイトル＝ページタイトルのみが有効で、段落同士の（ツリー構造による）つながりによって段落の深さが決定される仕組みを採用するので、段落中に見出しタグは書けない方針にする予定。

「:用語:定義」で<DL><DT><DD>相当の定義リストになる。これはちょっといろいろ考えてみないと。リスト関連全体を含めて。段落指向においては、リスト関連はそれ単体で1ページを構成するようにした方が正しいような気もするな。リスト属性をもつページとして、オリジナルのフォーマットを用意してもいいかもしれない。リスト以外の要素は記述できないようにしちゃって。

「||cell||cell||」なんて感じでテーブルを記述できる実装もあるそうな。このあたりはもうページ内に記述させるよりも、テーブル属性をもつページ（段落）を独立した編集させた方がよさそうな気がする。

「""」から始まるブロック（終端は空行か？）は<BLOCKQUOTE>になるそうな。なんかこれもいまいちっぽいな。hnfの方がよほど表現力が高いし、範囲指定も明確だ。

[literal][/literal]とか[esc][/esc]なんて表現で、その範囲をレンダリング処理回避ブロックに指定できるんだそうな。これが使えるところでは、htmlタグもそのまま使えちゃったりするのかな？

「''」で囲まれた部分は<EM></EM>相当の強調表現になる。

「'''」で囲まれた部分は<STRONG></STRONG>相当の強調表現になる。

WikiWord文字列はページへのリンクになる。

プロトコル＋アドレス（http://serverなど）は、外部リソースへのハイパーリンクとなる。これはまあこれとして、hnfみたいなリッチなハイパーリンク表現を使いたくなりそうだよなー。でも逆にこういう表現でしか外部リソースへのリンクを張れないからこそ、内部ページリンクとの差別化が図りやすいのかもしれない。

「[-」と「-]」で囲むと<SMALL>相当、「[+」と「+]」で囲むと<BIG>相当になる。

「#-」と「-#」で囲むと<SUB>相当（下付）、「#+」と「+#」で囲むと<SUP>相当（上付）になる。

「-[」と「]-」で囲むと<STRIKE>相当（打ち消し）、「+[」と「]+」で囲むと<INS>相当（挿入）になる。

Wiki的無秩序

Wikiはどうやら「無秩序であることに意義を見いだしている」部分があるようだ。逆リンクなどを使って、後付でページ間の関係を構造化することはできるけれども、編集されていく過程でそのあたりは根本から覆されることまで積極的に認めていく、というコンセプトを採用しているらしい。

俺の目標としては、「コンテンツは基本的に（ある程度）一貫した構造をもちつつも、その構造から大きく逸脱しない範囲において拡張・再編集されていく」ようなコンテンツ管理システムが欲しい。そのことを考えると、やはり俺の作りたいものはWikiというよりは、Wikiの利点を十分に活かした別のコンテンツ管理システムなんだろうな。

となるとポイントとしては、「一貫した構造」と「自由」のバランスをどのあたりに設定して、どういう内部仕様と外部インターフェースを用意するか、というあたりか。

Wikiのセキュリティモデル

既存のWikiシステムに見られるセキュリティモデル。

1. 完全にオープン
2. ロック可能（一部ページの編集に認証が必要）
3. ゲート（一部登録ユーザーを認証して、編集機能を解放）
4. メンバーのみ（すべてのユーザーを認証）
5. ファイアーウォール化（ネットワーク構成を使った制限）
6. 個人用（ネットワークに公開しない。自分のみアクセス可能なネットワークに置く）

俺のイメージとしては、1〜4までを簡単かつ自由に設定できる感じにしたいなー。自由に設定する方針についてはなんとなく見えてきたけれども、簡単にする方針とそれでいてセキュリティ的に強固（重要な機能は解放しない）にする部分は、まだ固まっていない。

セキュリティ対策としてディレクトリを分ける

特権ユーザー向けに別スクリプトを用意することによって、重要な機能を一般ユーザーには使わせないようにできる。特権ユーザーに対しては、スクリプトレベルではなくサーバーレベルあるいはネットワークレベルでの認証を用意すればいい。

同様に、閲覧専用と編集用ではディレクトリを分けて、閲覧側から編集側のCookieを読めないようにしておけば、もしもXSSが見つかってもそう簡単には重要な情報がもれないようになるかも。

ファイルアップロードとかの機能についても、ディレクトリを分けてそのディレクトリにおける設定をがちがちに固めておけば、かなりセキュリティ的な安全度は高まりそう。あるいは直接ファイルへのアクセスはできないようにして、cgi経由でファイルをできるかぎりbinモードで出力するようにしたほうが安全か。

Wikiの敷居の高さ

Wikiは、「（一見取っつきが悪そうな）Wikiフォーマットでページを編集できる＝Wikiに参加できる」という敷居を設けることによって、参加者のレベルをコントロールしている（とWikiWayの筆者は考えている）らしい。

確かにオープンなコミュニティにおける自浄作用の効果を期待するのだとしたら、オープンの範囲をそういう方法で縛る（参加者を選別する）方法は有効だろうし、俺もそういうやり方はスマートで好きだ。

けれども、（本書の表現を借りるところの）「テレビを観て満足している層」も参加することによって、2chのように、コミュニケーションの量的爆発とそれによるある種の成果が得られる可能性も捨てがたい（S/N比は高いが、有用なコンテンツの絶対量も多い）。

でもWikiも捨てがたい

でもWiki的アプローチで得られるものの中にも、捨てがたいものが多いんだよな。掲示板方面からアプローチするとどうしても組み込みにくくなりそうだし。

やっぱりひとまずWiki方面からのアプローチでできることをピックアップして、それらを中心に（掲示板的なやり方じゃないと実現しにくい部分は捨てて）作ってみようかな。

英語であることの利点・欠点

オリジナルのWikiは、基本的にそこで使われる言語が英語であることを前提に考えられている。英語であることの利点をうまく利用しているのが、オリジナルのWikiの実装だ。

Wikiの英語に依存している部分

たった26×2種類の文字（大文字・小文字）で表現でき、単語間が半角スペースで区切られている。そのため、非常にシンプルなパターンマッチによって、WikiNameをはじめとする特徴的なキーワードを設定することができる。

ある短い文章を表現する際の、文章表現上の揺らぎが比較的少ない。そのため、適切なWikiNameを設定することが（日本語と比べると）比較的易しい。たとえば日本語では、類義語の数が多いし、同じ単語でも漢字・カナなどさまざまな表記法がある。動詞の場合はさらに送り仮名の付け方にも揺らぎがある。

文字種類が少ないことから、検索負荷が小さくて済む。また、日本語のように文節の区切りを解析する必要もない。そのため、特に検索インデックスを用意しなくても、ある程度複雑な検索機能をシンプルに実装しやすい。

どのように日本語化するべきか

Wikiシステムはもともと英語という言語の特性に依存している。そのためWikiシステムを日本語化する際には、その部分をどのように対処するかがもっとも重要になる。

単純にシステムを移植するだけでなく、「その機能を割愛する」あるいは「似たような意味を持つ別の機能（日本語に向いた）で置き換える」などといった対処を行うことになる。

英語を使うからこそ手軽で便利に実装できた機能が、日本語にすると複雑で使いにくくなってしまうのだとしたら、それは実装する価値がないのかもしれないからだ。

WikiNameの日本語化

現在日本語化されたWikiシステムにおいては、英語版でのWikiName表現に加えて、一般的な文章ではあまり使われない区切り文字（[[]]など）でWikiNameに相当する部分を囲む（ブラケットネーム）という方法が用いられている。

ただし後者の方法（ブラケットネーム）は、WikiName方式の手軽さに比べると、入力の手間が大きくなってしまう。

WikiNameというのは、単語間の区切りとなる空白をなくすことによって、複数の単語を接続しつつ、単語の区切りとして大文字を使用することによって、コンピュータにも人間にも理解しやすくキーワードを生成することに成功している。

ポイントをまとめてみると、

• 半角空白でキーワードの前後が区切られる
• 大文字小文字を適切な規則で使い分けることによって、その部分がキーワードなのかどうかをシンプルなパターンマッチで判別する

ということになる。これと類似の機能を日本語においても実現可能だろうか？

少なくともキーワードの前後を半角空白で区切るというのは、日本語においてもさほど難しいことではないだろう。では半角空白で区切られた部分がキーワードかどうかをどうやって表現するべきか。

ひとまず思いついたパターンとしては、

1. 接頭辞をつける。たとえば?なんかを使って『このように ?WikiName を使う』
2. 接尾辞をつける。『このように WikiName? を使う』
3. 前後を囲む。ブラケットネーム方式と似ているが、半角スペースという区切りが明確なので、ここでは[[]]ほど一般的ではない文字列を使う必要はない。たとえば『このように 「WikiName」 を使う』
4. 単語＋助詞＋単語（＋助詞＋単語……）。たとえば『このように WikiNameの識別 を行う』。助詞として「は」「の」「が」「を」「に」……などを登録しておき、「単語＋助詞＋単語」形式にマッチした場合のみ、それをWikiNameとする。あまりにも短すぎる（言葉足らずな）WikiNameを排除することができる効果もあるだろう。

などがある。

できるだけ英語風に日本語WikiNameを実装する方法

できるだけ英語での扱いと同じように日本語WikiNameを実装するとなると、WikiNameの日本語化における4のやり方が近いのではないだろうか。ただし、4で述べた方法では誤認識の可能性が大きいので、できるだけ簡便かつ誤認識の可能性を低めた方法を考える必要がある。

ポイントは、半角スペースで区切られた部分にどのような特徴を付加すれば、そこがWikiNameにしたい部分であってほかの文章とは異なるのだということが明示できるか、だろう。

4では「助詞を区切りに使う」としたが、日本語の助詞はさほど明確な区切りとはならない。しかし、下手な記号を使う場合よりも、表現が自然になるというメリットがあるだろう。では助詞以外に、ある程度自然な表現を維持したまま、区別が明示できる要素はあるだろうか。

モーニング娘。方式

たとえば、「モーニング娘。」のように、日本語WikiNameの区切りとして必ず句点をつける、というのはどうだろう。

というのは半分冗談だが、前後に半角スペースをあけ末尾に「。」をつけるという表現は、そんなに悪い案ではないように思う。単語末（文の途中）に「。」がつくことに対する違和感は、多くの日本人にとっては「モーニング娘。」効果で薄れているだろう。

ここで重要なのは、「。」はコンピュータにとって明確な識別子となると同時に、人間が読む場合にそれを暗黙のうちに無視して読解することができる、という点だ。「。」は日本語文章中に混ざっても特に問題のない要素であり、なおかつ日本語環境において入力するのが簡単な要素である。

って、これは4方式ではなくて2方式だな。

日本語WikiNameを実際に実装するとしたら

今のところ一番無難そうに感じるのは、WikiNameの日本語化における1の方法だ。

おそらく4は、複数の半角スペースが一文中に使われた場合、WikiNameにしたい部分とそうでない部分を区別するのが難しくなるだろう。単純に「助詞」ではなく、もう少し特徴的な区切りを設定すれば、なんとか実用的な仕様になるかもしれないが。 では1の仕様を採用して、WikiNameにしたい部分に対して、「その前後に半角スペースを入れる」「WikiNameの頭に“?”をつける」とした場合のメリット・デメリットを考えてみる。

全角で文章を書いているときに、半角スペースを混ぜるのは面倒だという初心者は結構いるかもしれない。たいていのIMEではSHIFT＋スペースで半角スペースが打てるはずなので、それを活用してもらうよう啓蒙すればいいだろう。 WikiNameの部分だけ連文節変換できなくなる（前後に半角スペースを挟むため）というデメリットもあるが、現在のIMEの能力から考えれば（どうせまとめて変換したときの信頼性はそれほど高くない）許される範囲だと思う。

接頭辞の“?”は全角でも半角でも可としておけば、入力が面倒だという人はさほどいないと思う。また、WikiName以外の部分で文頭に“?”を使いたいという場合もほとんどない（外国語の一部に行頭に？を使うのがあった気がするけど）だろう。未解決なページリンクの一般的なWikiにおける表現との親和性も高そうだ。あとでその修飾を削除したい場合も、「s/\s\?([^\s]+)\s/$1/g」なんて感じで一発で消すことができそうだ。

関心空間的アプローチによる日本語化

日本語環境において、英語に依存したWikiシステムをそのまま再現することが難しいのならば、そのエッセンスだけを抜き出して、根本的に違うシステムを構築してしまうという手もある。 たとえばWikiのエッセンスをひとまず、

• 手軽にWebインターフェース上で新規投稿・再編集が可能なコンテンツ管理システム
• コンテンツ内のキーワードを手軽にハイパーリンクでつないでいくことができる

の2点だと捉え、その機能を実現するまったく新しいシステムを構築してしまうことも可能だろう。

そういうアプローチでどのようなシステムを作るかというと、たとえば関心空間的にキーワードをつないで他のコンテンツへと接続するインターフェースを、Wiki的ではない仕様の元に実装してしまえばいい。

コンテンツ管理部分は、普通の掲示板的なものでかまわない。ただし、各投稿は「タイトル」と「本文」を持ち、「タイトル」と「本文」の内容から自動的に（あるいはユーザーが明示的に）検索インデックスとなる「キーワード」を生成する。

あとは、コンテンツを出力する際に、それに関連するキーワードをもつコンテンツへのリンクを表示してやればいい。Wiki風にするならば、本文中のキーワード文字列に対して、そのキーワードに関連したページへのリンクを自動的に付加したり、まだ関連ページが存在しない場合は、そのキーワードに関する新規コンテンツの作成画面へのリンクを付加することも簡単だろう。

英語では入力者が簡単に登録できるキーワード（WikiName）が、日本語においては簡単に登録できないのならば、「入力者が（すべての）キーワードを設定する」という部分をばっさり切り捨て、システムがキーワードとおぼしきものの登録・検索を補助することに特化したシステムを作ってしまうわけだ。