新生全知検索整備・中間出振るい

領下手定め環境で概ね問題なさそうだったため，新生全知検索整備の中間出振るいに踏み切った。首尾良く完了し，大成功だった。これにより後縁も最新の状態で同期され，自由自在な開発体制を取り戻した。

21時30分出振るい作業開始。断帯は21時30分から約5分。23時頃までには一通り点検・不具合修正を終えた。

その後，動作は極めて安定している。dg_fnd() への輪数取得処理組み込みは今回初出振るいとなるが，高速化効果は，毎回輪数計算が必要になる場合の検索で数十ms（求頼1回分）の短縮なので体感速度向上はあまり期待していなかった。しかし，意外と検索時の軽快感が増している気がする。最初はプラセボ効果に近い開発者心理かと思ったが，自分の全知検索歴と検索頻度を考えれば感じ取れてもおかしくはない。嬉しい誤算だった。

輪符と知番の輪結改良

安心して後縁に手を入れられるようになったので，手始めに，輪符が生成する輪結で，第零番節付き知番がそのまま輪結先などに反映されてしまう問題を修正した。

これにより，輪符の知番が K#9-XXXX/A-YYYY と記述されていても，輪結先は第零番節の削除をした /?fg=KNo.XXXX/YYYY や /KNo.XXXX/YYYY となる。第二次知番改良を経て司組が生成する知番はこれで統一するようになったが，デラングでは大量にある第零番節付き輪符が第零番節付き輪結を生成していたため，クロール効率への悪影響が懸念された。出与え属性を通して輪郭小窓の知番表示にも反映されていたため，用合い上の問題もなくはなかった。

とりあえずは量が多い基本形の輪符と重い強調輪符でのみの対応。

個人知識管理サービスをよく使っているという人のほとんどが数千〜数万ページの利用規模に留まっている。それに対して，一人で数百万ページを扱っている人間がいるデライトの「システム的・文化的な構造の差」は割と明らかだと思う。

転売問題は実態が必ずしも明らかではないので，弊害も憶測で語られている部分が大きい。実際には，売り手は売れるし，買い手もいるから成立する。本当に困っているのは誰なのか？

デライトは，今年の2月13日に2周年を迎えたばかりの若いサービスだ。しかし，その背景には長い長い歴史がある。詳しく書くと書籍数冊分くらいにはなる話だ。デライトの完全な成功を目前にした良い頃合いなので，駆け足で振り返ってみたい。

輪郭法の閃き

技術としてのデライトは，私が17歳の頃，主に哲学と情報学への関心から「輪郭法」を閃いたことに始まる。2002年，もう20年前のことだ。デライトにおける輪郭法の応用については，「デライトの使い方の考え方」で出来るだけ簡単に解説したつもりだが，本来の輪郭法は，“輪郭という概念を中心にした世界の捉え方”であり，哲学用語でいう「弁証法」に近い位置付けの概念だ。

このアイデアが，哲学上の理論に留まらず，極めて実践的で，極めて強大な技術になりうることに気付くのに時間はかからなかった。これを応用することで，計算機科学における長年の最重要課題を解決し，知能増幅（IA）技術の実用化につなげることが出来る（参考）。すでに IT 産業の勢いが明らかだった当時，これは“世界史上最大の成功”と“知識産業革命”への道が開けたことを意味していた。

さらに，アメリカ同時多発テロ事件が起こって間もない頃だ。後の英米政治危機，世界に広がる社会分断，SNS の暴走，そして目下のウクライナ侵攻を予感させる事件だった。

あらゆる争いの背景には，世界の広さに対する人間の視野の狭さと，それによる“心の分断”がある。当時から私はそう考えていた。我々は，世界の一部分をそれぞれの立場から見ているに過ぎない。立場が違えば見える世界も違う。その衝突を回避出来るとすれば，個々人の世界に対する視野を広げるしかない。輪郭法の応用技術にはその可能性があると感じていた。この考え方が現在の KNS という概念につながっている（参考）。

葛藤

この閃きは止まるところを知らなかった。17歳の少年の人生観も世界観も，何もかもを瞬く間に作り替えてしまった。この閃きをどこまで大きく育てられるか，それだけを考える人生になった。適当に金に換えることも出来たかもしれないが，世界にかつてない平和と豊かさをもたらす鍵を手に入れたようなものだ。中途半端な売り物にすることなど，現実には考えられなかった。能う限り最高の状態で世に出さなくてはならないと思った。

もちろん最初は，とんでもない宝くじに当たったような気分だった。天にも昇る心地とはこのことだろう。どんな人生の喜びも，この喜びには勝るまい。少しばかり時間が経ち，冷静になるにつれ，呪いのような重圧に苦しむようになった。

第二次知番改良，ここから自我知番省略機能実装に入る。

作業方針検討で終了。

最近，K#/XXXX 形式の知番は一律自自我の省略とみなし，知番実装に自我知番省略機能を組み込んでしまうことまで考えていたが，これはやめておくことにした。自輪郭内や自輪郭検索など文脈から明らかな場合のみ自自我の省略とみなす。とりあえずは，前縁，デラングや全知検索など，部分的な対応から始める。

将来的に知番が長くなった場合，例えば K#-XXXX や K#/-XXXX のように知番の一部で絞り込みが出来るようにしたい。知名と組み合わせれば十分なことも多いだろう。K#/XXXX もその一種として扱えた方が理解しやすい，と考えると一定の柔軟性を残しておきたい。現状，そこまで長い知番は多くないので，これは「知番略記法」として第三次知番改良の課題にする。

（進捗時限記録中略）

交度（コード）記法と埋め込み記法を組み合わせた「交度埋め込み記法」（仮称）の方針をまとめて終了。

例えば，Mermaid を埋め込みたい場合，以下のような書き方になる（交度部区（コードブロック）記法は「逆括点（バッククォート）2つ以上」にする予定）。

+``mermaid
...
``

あるいは

+mermaid``
...
``

（進捗時限記録中略）

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

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

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

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

検討過程

3つの検討方針

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

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