文字装飾記法実装。

出振るい・手定めを完了。一応，入れ子にして組み合わせることも出来るが，短縮記法は後回し。

URL の // が斜体記法に干渉するため，ここで URL に越化処理を加えた。3月12日14歩で考えたように越化参照 &_http;，&_https; を使ったが，// まで含めるようにした。

デライトには「使い方」というページがあるのだが，これは最初の頃からまともに更新出来ていない。デライト開発もありがたいことに快調で，いちいち更新していられないほど変化が激しかった。このあたりも近日中に刷新するので，もうしばらくお待ち頂きたい。

もっとも，多くのデライト初心者が躓いているのは，細かい操作方法というより，どういう考え方で使っていくものなのか，という所なのではないかと思う。デライトで躓きやすい「使い方の考え方」について，このあたりで少し補足しておきたい。

デライトは風変わりで慣れが必要なものではあるが，特に難解なものではない。開発者の力不足による不親切さは多々あるものの，あくまで誰でも使えるものを目指している。まずは，ちょっとしたゲームのルールを覚えるつもりで読んでもらいたい。

なぜ「輪郭」なのか

デライトは，個人の知識をよりよく育て，生活の様々な場面で役立ててもらうためのサービスだ。それを突き詰めた結果として，互いに入れ子に出来る「輪郭」という単位で情報を扱う仕組みを持っている。

ここでいう「輪郭」というのも，まずはごく普通の言語感覚で理解してもらえればいい。ある物事の全体を取り囲むもの，という意味だ。もっと具体的にイメージしたければ，手で輪っかを作り，目に見える風景の一部分を切り取って見てほしい。写真の構図を考える時などに似たことをよくやるが，その時に手で作っている輪っかは，世界のある部分の輪郭だ。

その輪郭を，自由に“保存”出来たらどうだろうか。輪郭の中にまた輪郭を作ることも出来る。一つの輪郭は，他の無数の輪郭を含むものであると同時に，他の無数の輪郭に含まれるものになる。そのようにして，“世界 K#F85E/A-3947}を捉える”ことは{出来ないだろうか。さらに，この考え方をコンピューティングに応用することで，従来の情報管理が抱えていた問題を解決出来るのではないか。ここからデライトの輪郭という仕組みが生まれた。

例えば，ファイルをフォルダ（ディレクトリ）という入れ物で分類管理する仕組みは広く使われているものの，人間が頭の中で扱っているようには情報を扱えない。一つの物事をどこに分類するかは，見方によっていかようにも変わりうるからだ。これは，一つの情報を一つの入れ物に所属させるような「階層構造」一般の問題（こうもり問題）としてよく知られている。

他方，こうした問題を解決するため，より柔軟な「ネットワーク構造」（グラフ構造とも）を利用した仕組みも広く使われている。Wikipedia などで利用されているウィキはその代表例だ。ウィキは，ウェブのハイパーリンクという仕組みを最大限に活かし，縦横無尽にリンクを張り巡らしながら情報を整理出来るように設計されている。しかし，こうした技術も万能ではない。柔軟な分，散漫・乱雑になりがちで，焦点を絞って情報をまとめることには向いていない。

輪郭による「輪郭構造」なら，両方の利点を上手く共存させることが出来る。輪郭はいわば「宙に浮いている輪っか」なので，階層構造を持つフォルダのような入れ物とみなすことも出来るし，輪郭同士の関係はネットワーク構造のように柔軟だ。以前適当に作った雑なものだが，下図を見ればなんとなくは分かるかもしれない。

まとめながらつなげる

一般に，階層構造は少量の情報を明確にまとめることに向き，ネットワーク構造は多量の情報を緩やかにつなげることに向く。

ウィキなどで作られる情報のネットワーク構造は，しばしば，脳の神経細胞群が作る構造に似ていると言われる。情報同士のネットワーク状の結び付き，という大きな括りではその通りだ。しかし，脳はただ漫然とネットワークを広げているわけではない。脳科学・神経科学でも，神経細胞の結び付きには強度差があると考えられている。つまり，脳は優先順位を整理しながら情報をつなげている。「輪郭」を使ってデライトが再現しようとしているのは，この「まとめながらつなげる」脳の機能だ。

進化の観点から考えれば，動物の脳は，環境に合わせて情報を蓄積し，状況に合わせて有用な情報を素早く引き出せるように出来ていなければならない。もちろん生存のためにだ。どれだけたくさん情報を蓄えられても，必要な時に上手く引き出せなければ意味が無いわけだ。大昔から限界が知られている階層構造が，それでも必要とされ続けているのは，情報に優先順位を付けて整理していく，という脳の機能がとらえやすい構造だからだ。

個人知識管理（PKM）の分野でも，ネットワーク構造を活かしたウィキと並んで，階層構造で情報を整理していくアウトライナー（アウトライン プロセッサー）と呼ばれるものがよく使われている。非常に興味深いことに，この二つを抱き合わせたツールが近年のトレンドの一つだ（Roam Research，Obsidian など）。

脳の進化を追うようにツールも進化しているが，デライトが革新的なのは，既存の仕組みを抱き合わせるのではなく，全く新しい一つの仕組みで脳の機能を十分に再現しているからだ。慣れた利用者にとっては，その単純性がこれまでにない直感性につながる。同時に，初心者には分かりにくさの原因となってしまっている。

デライトには「脳のログ」が流れている

デライトは，“人間が触りやすいように”脳の機能を再現することに，どのツールよりも徹底したこだわりを持っている。人の脳は，長い長い進化の過程で無数のテストを通過してきた，情報処理ツールのお手本だ。その脳を使って活動している人間にとって，最も直感的に扱えるのは最も脳に似ているツールだ。そして，保存・検索・共有といった部分での脳の弱点を機械が補えば，これまで不可能だったような高度な知的活動が可能になる。

デライト上に流れている無数の輪郭が，いわば「脳のログ」であることを理解すると，初心者を面食らわせてしまっている部分の多くも理解しやすくなるのではないかと思う。

公開されることもあって，どのような内容をどのくらいの頻度で“描き出し”していいものなのか分からない，というのはデライト初心者が抱きやすい感想だろう。この点においてデライトは，活発なチャットやマイクロブログ（Twitter など）の速さで投稿（輪郭）が流れていくイメージで設計されている。それも，「廃人」達の独り言で埋め尽くされているチャットのような状態を想定している。脳のログならそうなるはずだからだ。

デライト上には，一見意味不明な輪郭も数多くある。脳のログだと考えれば，これもむしろ自然なことだと言える。デライトは，“綺麗に整えたメモ帳”を見せるためのサービスではない。頭の中にある情報を，ありのままに可視化することに意味がある。他人の輪郭を見るということは，他人の頭の中を覗いているようなもので，めまいを覚えるなら正常なのだ。

それでも，ちょっと気になった他人の輪郭から良い刺激が得られることは珍しくない。自分の輪郭を他人の輪郭を絡ませることも出来るので，デライトでは面白い知的交流が日々生まれている。疑似的に再現された脳同士が対話しているわけで，これは疑似的なテレパシーと言えるかもしれない。

新しい順に輪郭が並んでいるのも，もちろん脳のログだからだ。先日の一日一文でも書いたように，デライトは，Twitter のようなマイクロブログにも似ている。そして，マイクロブログはしばしばメモツールとして利用されている。これは，時間軸に沿って記憶を辿るような脳の機能に似ているからだ。

デライトでは，マイクロブログ感覚で思いつくままに輪郭を作り，時にはウィキのように，時にはアウトライナーやマインドマップのように，“まとめながらつなげていく”ことで「脳のログ」を可能にしている。

例えば，釈迦，孔子，ソクラテス，キリスト……あるいはカントでもアインシュタインでも誰でもいいが，後世の人間は文献からあれこれ推測するしかない「偉人」達の記憶が，このような形で残されていたら，と想像してみてほしい。百年後，千年後の人々にとって，「輪郭」は古人について知る何よりの手がかりとなるだろう。あなたにとって偉人以上に大切な人生の記憶をこれほど強く世界に刻み込める道具は他にないのだ。

そして知能増幅へ

工学的に人間の知能を向上させようという研究分野は，古くから「知能増幅」（IA: intelligence amplification）と呼ばれている。今や世界的な流行語である「人工知能」（AI）に比べて，語られることは非常に少ない。脳にチップを埋め込む，遺伝子を書き換えるなど，どの技術にも大きな技術的・倫理的課題があり，実用段階になかったからだ。

デライトは，それを誰でも使えるメモサービスという形で実現している「知能増幅メモサービス」であり，「世界初の実用的な知能増幅技術」だ。今後の一日一文では，この技術の歴史的重要性についても書いていきたい。

（進捗時限記録中略・前後）

外部サービス利用者記法についての検討がきっかけで考え始めた，@ と知番・輪符などを組み合わせる「言及記法」についての検討で終了。

最近，返信先を示すのにパンくず記法が使えることに気付いたが，あくまでもさりげなく文脈を示すものなので，もっと明示的に言及（メンション）を表現したい場合に適当な記法が無いと感じていた。引用記法は引用内容を表すものなので使えない。

匿名掲示板などで見られる >> が脳裏をよぎったが，現行の複数段落引用記法以前に，入れ子に出来る引用記法との整合性を考えると良い記法とは言えない。

具体的にどういう装体・機能にするかはまだ定まっていないが，@ が使えることに気付いたのは大きな収穫だった。

（進捗時限記録中略）

昨日，寝る直前にまた脳爆発があり，今朝にかけて文字装飾記法とタグ記法周りの概念整理・仕様整理が急速に進んだ。

文字装飾記法は，「文字装飾を伴う慣用表現」のための記法と位置付けることにした。太字記法（##），斜体記法（//），下線記法（__），打ち消し線記法（~~，翌日のまとめで「打ち消し記法」から改称）の4記法を基本とし，それぞれ所定装体（スタイル）を伴う <b>，<i>，<u>，<s> HTML 要素に対応する。

@ を使った文字サイズ記法，% を使った色記法も検討していたが，タグ記法の概念が出来たことで中途半端なものになるため，これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つの検討方針

実装自体は容易な部類で，記法も概ね固まっていたにもかかわらず文字装飾記法の実装に踏み切れなかった理由として意味論的な問題があり，これが思いのほか難題だった。実装方針は3通り考えられる。

1. 完全に意味論的な記法にする
2. 完全に装飾的な記法にする
3. 意味論と装飾を重ね合わせた記法にする

記法の趣旨からしても，軽量標記（マークアップ）言語の特性を考えても，1つ目に無理があるのは明らかだ。対応する HTML の <b>，<i>，<u>，<s> は，私が何度解説を読んでもややこしく感じる代物だ。それを多くの人が正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系を捨てることになるが，代替案があるわけでもない。

かといって，2つ目ももったいない。要は <span> で装体指定だけにするということだが，例えば，太字にはしたいが <b> にはしたくない場合，打ち消し線は引きたいが <s> にはしたくない場合がどれだけあるのかと考えると，無難を通り越して臆病過ぎる。失う可接性（アクセシビリティ）や応用可能性と釣り合わない。

最終的に採用することになった3つ目も，全く考えなかったわけではないが，柔軟性に欠け，前の2つの悪い所が組み合わされる気もして，有力案にはなっていなかった。

タグ記法による書き分け

この膠着状態を変えたのは，前日に概念としてまとまったばかりのタグ記法だった。

これまで，デラングにおける HTML は，どうしてもデラングで出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで，積極的に使うことを想定していなかった。実際，個人的にはほとんど使っておらず，放置している不具合も多い部分だった。

デラングのタグ記法として間接的に HTML を使うことで，略記法の導入も可能になり，HTML 側の仕様変更に対しても一定の緩衝帯を設けることが出来る。ここに来て初めて，文字装飾記法でも「書き分け」が考えられるようになった。文字装飾記法に対応しうるのが全て1文字要素だったことも幸いした。

昨日の寝る直前に，##太字的な表現## と <{font-weight:bold}>太字</> のように書き分けるよりも，##太字## と <b>太字的な表現</b> のように書き分ける方がマシであることに気付いて，1つ目の実装方針案は完全に潰せた。

これにより一時的に2つ目の実装方針案が再浮上したが，標準的に使う記法として標準的な用途に最適化不足なのはやはり否めなかった。

決着

最終的に，「文字装飾を伴う慣用表現」という用者が自然に理解出来る範囲での意味論的な位置付けを与え，逸脱する用途ならタグ記法で書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針案を洗練させた格好になる。

例えば，##太字## は「太字装体の <b>」に対応する。装体が邪魔なら <b>太字的な表現</b> と書けるし，意味が邪魔なら <{font-weight:bold}>太字</>（略記法は検討段階）のように書けるが，これらの場合が稀少なのは明らかで，記述量に上手く釣り合う。ワープロならともかく，軽量標記言語を手書きしようという人にとって難しい使い分けではないだろう。

そもそも，<b>，<i>，<u>，<s> は，古くからある視覚的要素が HTML5 で慣用的な用途を引き継いで意味論化されたものなので，「文字装飾を伴う慣用表現」と非常に相性が良い。相互変換にも全く問題ない。

何より，直感的に入力すれば構造的に出力されるというデラングの理想に適っている。

文字サイズ記法・色記法は廃案へ

文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで，慣用表現を持たない文字サイズ記法・色記法は仲間外れになるが，タグ記法によって出る幕がなくなった感があるので，ここで廃案にすることとした。

第一に，タグ記法で略記法を整備した方が一貫性も応用可能性も高い。特定の値でプロパティを省略出来るようにし，<{white}>白い文字</> のように書ければ，%white%白い文字%% と書くのと記述量も大差ない。

もともとパラメーターを必要とする記法の異質感はあり，文字装飾記法の統一感を損うかという懸念はあったので丁度良かった。

波及的検討

波及的に，いくつかこまごまとした検討も進んだ。

組み合わせは「逆」ではなく「入れ子」へ

これまで，複数の文字装飾記法の組み合わせは #/太字と斜体/# のように，「記号を1つずつ逆さにした終了記号と挟む」といったややこしい説明を考えていたが，##//太字と斜体//## のような「入れ子」を #/太字と斜体/# と短縮出来るという考え方にした方が分かりやすいため改めることにした。

タグ記法の発展

今回の検討で，タグ記法が早くも実践的な役割を持つことになり，デラングにおける存在感が一気に増した。

タグ記法に HTML の仕様変更に対する緩衝的な役割を持たせること，要素名の省略で <span> にすることを考え始めた。

気になったので少し箇条書き部区の装体調整をして終了。

入れ子の <ul>，<ol> に付く0.5emの上下マージンを削除した。

確か，実装時，長い文の箇条書きを読みやすくするために入れたものだが，短い項目を並べた時などに違和感があり，汎用性を損う。

キーボード記法の改良で終了。

従来の二重角括弧を使った [[X]] 記法に加え，アンダースコアを組み合わせた [_X_] 記法を使えるようにした。

旧記法は近いうちに廃止し，ウィキ互換の輪結記法に転用する。ハッシュタグ同様，単純に全知検索に飛ばすだけだが，他サービスからの移行者がデライトに触りやすくなったり，デライト向けに文書を書き直しやすくする効果が見込める。

大きな用途の変更であるため，時印によって適用版存を切り替えることになりそうだ。

11日14歩の検討で方向性は定まっていた。旧記法を導入した昨年3月11日はまだデラング整備の最初期で，あまり他サービス・他言語との互換性は重視しておらず，他サービスで採用例の多かった二重角括弧による輪結をキーボード記法に使うことも，独自性を出すのに良いだろうという程度にしか考えていなかった。

最近のデラングが，デライトにとっての利益を損なわない限り他サービス・他言語との互換性を最大化するという方針になっていることに加え，単純に旧記法の視認性の悪さが気になっていたこともあった。最近ではほとんど自分で使っていなかった。

[[Ctrl]] のようにキー名に長さがあればまだいいが，[[X]] では流石に記号が邪魔臭い。[_X_] という記法は当時検討した記憶があるが，[X] に対して物足りず決め手に欠けると感じたか，なんとなく見送っていた。[[X]] は「キーの立体感を表現しているように見えなくもない」（希哲15年3月11日2歩）と思っていたが，<kbd> の装体はデライトも含めて，四方を線で囲み，立体感を出すため上境界線よりも下境界線を目立たせるという形になることが多いため [_X_] の方がむしろ装体に近い。

逆括点を使った [`X`] という記法の採用例を見かけて悪くないと思ったが，まだ普及度も低い上，これは `[X]` との書き間違いが続出しそうだと感じたたため見送った。[_X_] ならその問題もなく，直感性でこれに勝るものはなさそうだ。

<kbd> は入れ子にすることも出来るので，[_Ctrl_] + [_X_] のような組み合わせも記法として扱うことを考えたが，実用上大きな変化はないはずなので後回し。

デライトの使い方の基本は，思い浮かんだことを文字通り「輪郭」として捉えてそれを入れ子にしていく，ただそれだけのことなのだが，それを「単純なこと」と言ってはいけないのかもしれない。