今後の生活などについての雑多な考え事をしていた。

昨日，姪達が泊まりにきて風呂が沸いていたので久しぶりに全身浴をしたが，やはり肌の調子が良かった。毎日の全身浴もそろそろ再開したい。

検討作業など。

CSS アイコンを識別するための要素分類名をどうするかという問題があったが，_ 接尾子を使うことを思いついた。

実験では暫定的に .icn を使っていたが，今後干渉する可能性があり，CSS の肥大化を招く選択子の列挙も避けたかった。交度英語としてはこれまで icon や ico を使ってきたが，これを機に icn に統一したい。ico は微妙に使いにくかった。

Cμ では不完全型などの接尾子ということもあり，.icn_ なら簡潔かつ補完が必要な分類名として直感に適う。._icn は特殊性の表現として漠然とし過ぎている。

（進捗時限記録中略）

デライト全体における添付譜類の方針検討で終了。

添付譜類はあくまでも添え物として最小限の役割に留め，エクスポート機能でも実譜類の出力には今後対応しない方針を固めた。

元々添付譜類は添え物として設計しているが，実際に譜類添付機能が出来，エクスポート機能を実装しようとしてみると，実質的な役割の落とし所が意外に難しい。意図に反して，変に使われ過ぎるのも問題だ。

エクスポート機能では，とりあえずは代替 HTML などで済ませ，ゆとりが出来たら実譜類にも対応するか，などと考えていた。そもそも，どんな大企業のクラウドであれ消えて困るような譜類の唯一の保管場所にすべきではないし，そこまで神経質な人が手元に抜控を持っていないということも考えにくいので，実はさほど必要性の高い付徴ではない。とはいえ，エクスポート時の負荷や帯域だけが問題なら金で解決出来るのだから，将来的に対応しないというほどの動機もない。

しかし，添付譜類がエクスポート出来てしまうことで譜類倉庫的な利用が増え，それに伴い譜類保全の責任が増せば，将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた。描出公開原則同様，ここは割り切った用者文化を育てていくべきだろう。

これに気付いてみて，最近，添付譜類の役割を広げようとし過ぎていたことにも気付いた。譜類添付機能のサイズ上限や拡張子制限の緩和も考えていたが，これも最小限に留めることにした。拡張子制限は制危面もあるが，献典として非効率だったり無意味だったりする譜類の上信抑止といった効果も望める（例えば .bmp をそのまま上信して欲しくはない）。

デライトの強みは，知番による意味符号化で文字献典の情報密度を極限まで高め，その軽さを最大限に活かせることだ。譜類倉庫的な方面で消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降，その軸が微妙に揺らいでいることはうっすら感じていた。今日は妙に頭がもやもやしていると思ったら，どうも脳がそれを訴えていたらしい。気付いたら非常にすっきりした。

描出公開原則のように何かこの方針に名前を付けたくなったが，「譜類添付機能」という名前で趣旨は表現出来ているので，それに立ち返るということで十分だろう。

23日の開発から急速に進展したデライト高速化も一段落した。

テーマ切り替えボタンの用合い検討（4歩），新規描出フォームへの移動機能として吹き描き外背景のダブルクリック用合いの復活（10歩），全知検索ページャー周りの調整（16歩），こまごまとした領当て・装体調整（17歩）といった雑多ながら充実した作業を片付け，ついに描写後略機能を一段落させた（21歩）。出振るい・手定め済み。

描写後略機能により，デライト最初期から吹き描きの構造的問題だった「不必要な出与え読み込みの多さ」という問題が解消した。表示速度向上，通信量削減，SEO 強化，迷惑行為対策など多大な効果が見込める。

デライト高速化の現状と今後

昨年末の壊衝不具合修正以後，デライトは速度・安定性ともにウェブ相振りとして十分な水準に達していたが，今回の高速化を経て，明らかにもう一つ壁を越えた感がある。体感として，「ウェブ相振りなら特に不満のない速さ」から「単動相振りと比べても遜色のない速さ」になった。

一昨年4月9日に掲げた「全ページ0.3秒以内表示」という目標は埋め込み利素を考えると現実的ではない気がしてきたものの，軽いページでは200ms台，重いページでも概ね300ms台で応答出来るようになっている。実感として欲しかった速度は手に入れられたし，最適化余地はまだまだ残しているので「埋め込み利素を除いてほぼ全てのページで0.3秒以内表示」なら十分手が届く。いよいよ本格的に，速さがデライトの武器になってきた。

ここで新生デライト開発におけるデライト高速化は一段落とし，今後は機能追加やトラフィックに応じた微調整に留め，別の機能整備に集中することにした。

その先のデライト高速化については，大きなところでは CDN 導入，KNEST による水平拡大，請い手の隠し機能整備，描写 HTML 隠し以外の HTML 隠し実装，そして中途半端な状態で放置しているページ付け求頼改良があるが，どれも現時点での優先順位は低い。

作業方針検討（4歩），閲覧専用模動実装検討（5歩），デラング整備・埋め込み記法処理改良（8歩〜13歩）。

埋め込み記法処理改良

これまで，埋め込み記法処理の中でも oEmbed を利用したものについては，Dex 内で埋め込み交度の取得を行い直接描写 HTML に埋め込んで返していたが，埋め込み交度の取得処理を専用 API /mbd に委ね，前縁 Aejs から利用することにした。結果として，応答速度改善に成功した。

埋め込み記法（+[URL]）の URL が oEmbed を必要とする場合，Dex では適当な分類名を付与した <div> に出与え属性で URL を埋め込んで描写 HTMLを返す。Aejs ではそれを検知し，URL を /mbd に転送する。/mbd は URL に対応したサービスの埋め込み交度を oEmbed で取得して返す，という流れになる。過剰な立求を抑止するため，Aejs には簡易的な隠しも持たせておいた。

想像していたよりすっきり実装出来た。

そもそものきっかけは，先日の SlideShare 対応だった。oEmbed が必要になったので，埋め込みツイートで使っていた Dex 内の oEmbed 埋め込み方法を取り急ぎ使った。ただ，記法処理範枠に同期通信処理を組み込むというのは正気の沙汰ではない。なんでこんな実装になっているのか，引っかかりはあった。

KNEST 隠しを使った SSR 的なことを考えていたことはあるので，その辺の都合だったのだろうと思ったが，現状，そこまで最適化する必要も時間も無い。出来たとして，隠しを有効利用出来る握接パターンは限られている。いずれにせよ，この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで，いったん，埋め込み処理は前縁に移すことにした。

無理をしないと書いたそばから，調子が良いを通り越して過熱気味で，また寝るのが遅くなってしまった。

開発では輪郭選り手の改良に熱中し，輪郭整備もまたお預けとなった。ただ，描出効率の大きな向上が見込める改良となり，今後の輪郭整備を考えればむしろ良かった。きっかけは昨日の開発での不具合修正で，これも怪我の功名だった。

輪郭選り手改良に意識が向いたのは，最近，執筆環境としてのデライトへの期待が高まっていたからかもしれない。もちろん，デライト文書整備が念頭にある。

デライトの完全な成功までの「最後の壁」だと思っていたものを突破しては次の壁にぶつかるということを繰り返してきたので，“その時”が来るまで，結局何が「最後の壁」なのかは分からないだろう。

用者が大きく増えないままデライトが進歩し，洗練されるたびに不思議な感覚を覚えてきた。こんなに凄いものをこんなに少人数で使っていることに，罪悪感に近いものを覚える。隠しているわけでもないのに独占しているみたいだ。事実，デライトほど構想的・技術的に高度で，高品質で，なおかつ無名なサービスは他に無いだろう。

現在のデライトを俯瞰した時，明らかに欠けている大きな部分はもはや一つしかない。それが“文書”だ。

正式離立から適当な状態のまま，ほとんど手を入れていないデライト文書の整備を遅らせてきたことには，修正回数を最小限に抑えるという戦略的な理由があった。実際，ここまでのデライトの急激な変化にいちいち文書を追随させていたら，デライト開発自体がここまでの速さで進んでいないだろう。第二次快調期と第四次宣伝攻勢を経て，安定感が出てきた今が一番効率的・効果的に文書整備を進められる時期なのは間違いない。

若干肉体的な疲労感が残っていたため，ゆっくり大輪郭整備をして過ごした。

これまで，特定時刻の少し前・少し後を表現するのに「〜前」「〜過ぎ」を使っていたが，「〜前」は特に分に付くと誤解されやすいため「〜近く」を使うことにした。

最近，たまたま口に出すことがあって紛らわしさに気付いた。よくある問題だったらしい。

最近，SEO でも興味深い動きがある。

「なんでもメモ」での Google 検索結果でデライトが上位安定してきている。粘れば首位も狙えそうだ。一方，相変わらず「デライト」ではほぼ圏外という不思議な状況が続いている。

今日気付いて驚いたのは，「希哲」で『希哲辞典』（dict.kitetu.com）が首位になっていたことだった。世界一「希哲」を重視してきたにもかかわらず，希哲館事業発足からろくに上位に入らなかったので半ば諦めていた。ここで適当に作った『希哲辞典』が浮上するとは思わなかった。

（進捗時限記録中略）

崩れっぱなしだった『希哲辞典』（dict.kitetu.com）の装体を最低限整え直し，希哲館訳語に誘導する文言を入れておいた（『希哲辞典』の様子）。

画面記録のため kn upl を使おうとした時，初めて認証失敗した。場筋からの知番の抽出に失敗している様子だったため kn kno を簡単に修正したが，今後要注意。

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

輪郭法の閃き

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

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

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

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

葛藤

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

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

輪郭小窓実装，不具合修正など。

最近増えていた壊衝の原因が判明，修正した（16歩）。

矢継ぎ早の付徴追加などで心当たりが多過ぎ，切り分けと絞り込みに時間がかかった。KNEST 隠しの排他制御を疑っていたが，もっと単純な問題だった。

ついでに，体感速度低下の問題も改善した。upub の導入後，Google のクロール統計でも平均応答速度の明らかな低下が見られたため，これが原因だろうと思い込んでいたが，体感速度に関しては壊衝で隠しが失われていたことが大きかったようだ。壊衝問題は以前集中的に対策してからしばらく安定していたため注意不足だった。今後，監視を強める。

どちらも思い込みから原因を見誤っていた。気分転換の輪郭整備兼一日一文が功を奏したか。