……と，イーロン・マスクによる Twitter 改革の懸念は挙げればキリがない。冷静に考えれば安心材料より不安材料の方が圧倒的に多大なので，どちらかと言えば楽観論の方が希望的観測ということになる。

開発では思わぬ収穫があり，デライトの安定稼動に向けた懸念が払拭出来た。

ただ，デライト文書がこのままで新生全知検索整備を完了してもばら成しが悪いので，そろそろ文書整備を並行させることも考えることにした。

（23日の振り返り日記）

新生全知検索整備。

最初の中間出振るいに成功。これにより，全知検索の応答速度，柔軟性，交度品質が大きく向上した。出振るい作業も円滑に進み，手溢れも無く，全体として大成功だった。

輪郭情報取得改良

まず，期待通り，輪郭情報取得方式の改良により応答速度が大きく向上した。体感的にも，この種のサービスとしては並という程度から，はっきり速いと言える程度になり，快適度が数段上がった感覚がある。

これまでのデライト高速化施策の中でも最大級の効果を感じるが，これはボトルネック解消によるところが大きい。6月の Cμ 文字列処理改良あたりから，領下手定め環境での高速化効果の大きさに比べて本番環境での効果がかなり小さいと感じるようになっていた。考えられるボトルネックは，相振り・出場間の通信回数が多過ぎる輪郭情報取得処理だった。

これまで，ページに表示される輪郭情報の取得は，相振りから大体次の流れで行っていた。

1. 輪郭隠しにない吊るし輪郭があれば輪郭情報を取得する（dg_oln()）。
   1. 自我隠しが存在しなければ自我情報を取得する（dg_ego()）。
   2. 前景輪数（n_fg）が1以上なら前景輪情報を取得する（dg_fg()）。
   3. 後景輪数（n_bg）が1以上なら後景輪情報を取得する（dg_bg()）。
2. 輪郭一覧の輪郭情報を取得する（dg_fnd() か，吊るし輪郭の初期状態は dg_fg()，dg_bg()）。
3. 各輪郭の自我情報・前後景輪情報を個別に取得する。
   1. 自我隠しが存在しなければ自我情報を取得する（dg_ego()）。
   2. 前景輪数（n_fg）が1以上なら前景輪情報を取得する（dg_fg()）。
   3. 後景輪数（n_bg）が1以上なら後景輪情報を取得する（dg_bg()）。

この旧方式では，KNEST 隠しも一部でしか活用出来ておらず，中景輪数に応じて求頼が増え過ぎる問題があった。1ページあたり最大45回の求頼が発生する可能性があったことになり，当然，相振り・出場間の通信コストがそのまま応答速度低下に繋がっていた。

KNEST 隠し実装を一段落させた6月30日の開発でまとめた方針に基き，これを次のように改良した。

1. 吊るし輪郭も含めて，ページの表示に必要な全ての輪郭の知番を一括取得する（dg_fnd()）。
   • 出場側では，優先順位を兼ねた検索群類を表す整数値，中景知番，三景のどれかを表す整数値を付与し，相振り側で仕分け出来るようにする。
2. 輪郭隠しにない輪郭情報は一括取得する（dg_oln()）。
3. 自我隠しにない自我情報は一括取得する（dg_ego()）。

この新方式により，求頼は最大でも3回で済み，KNEST 隠しも十分に活用出来るようになった。同期と隠しのばら成しも良く，基礎として理想的だ。あとは必要に応じて HTML 隠しなどで補完すれば十分だろう。

upub を導入した7月から微妙な応答速度低下が気になるようになり，検索演心からのクロール頻度や評価の低下といった悪影響もあったため，輪郭情報取得改良は高速化の特効薬としても新生全知検索整備の最優先当努だった。

最悪見込み違いという不安もなくはなく，これだけ大胆な改良だったので不具合多発の懸念も大きかったが，速度も安定性も申し分ない結果となった。Cμ 文字列処理改良，KNEST 隠し実装，前後景時印の導入といったこれまでの高速化施策がしっかり活かせるようになったのも嬉しい。

検索群類の導入

4月7日10歩から検討していた「検索属性」もここで「検索群類」として導入に成功し，異なる条件の輪郭一覧を結合出来るようになった。

今後の検索結果改良の大きな足場が出来た。

出場・交度整理

最初に着手した b_bg_his の削除もここで本番環境に適用され，上描き履歴は完全に廃止となった。

思わぬ収穫として，交度整理の大きな進展もあった。

輪郭情報取得改良は一見単純なようで，実際にやってみると意外に複雑な交度が必要だった。当初，dg_fnd() の SQL 周りが最難関だと思い込んでいたため，6日の開発での解決時には一山越えたと思ったが，その後のテンプレート処理の方が大変だった。

この誤算で，長いこと放置していたテンプレート周りの乱雑な交度も整理せざるをえなくなり，結果として自分でも驚くほど整理整頓出来てしまった。

（進捗時限記録中略）

第二次用合い改良。

途中で終了。

急遽，引き入れ欄の複数知番対応を完了。時間対効果的に避けて通れないことに気付いた。

クリップボード履歴から効率的に貼り付けたいという要望は受けていたが，当初はかなり限定的な用途に思えたので優先順位を上げられなかった。ついさっき，描写欄からの貼り付けにも使えることに気付いた。

いつも描写欄に輪符を貼り付けながら文章を書き，最後に一つずつ引き入れするということをしていたのに，なぜか気付かなかった。4時間ほどかけてしまったが，問題にならないくらい劇的に描出効率が向上するだろう。無番輪符対応や輪郭候補窓との組み合わせで更に凄いことになりそうだ。

ただし，負荷や誤操作の懸念が拭えないため，最大10個までという制限を付けた。

応答速度が異常に遅い輪郭についての不具合調査から求頼改良・出場改良のアイデアがまとまり，一気に実装した。

_dg は _dg_oln と結合しないと揃えが出来ず，揃えで極端に遅くなる場合があることは認識していたが，時印を追加することは正規化の観点から避けてきた。

公開設定機能の導入で必要性が低くなった揃え用時印を廃案にすることを最近考えていたが，これに近い役割を持たせた ts_fg，ts_bg を追加することを思い付き，急速にまとまった。単なる複製ならやはり避けたかったが，より抽象的な時印を _dg が持っていることは不自然ではなく，同期も引き入れ・再描出処理で行うだけでいい。

手定めしてみると，低負荷求頼では索引が使われず有意差は見られなかったものの，高負荷求頼では数倍から十倍程度までの高速化が見られた。求頼最適化の選択肢が増えることでサービス全体の負荷抑制が見込める。

領下での実装・手定めは終えたが，稼動させながらの _dg の修正は無理そうなので明日早朝出振るいすることにした。

これにより応答速度が異常に遅い輪郭についても改善が見られたが，異常であることは変わらず，根本的な解決にはならなかった。

当初，輪括が膨大な輪郭特有の問題だろうと思っていたが，一見何でもなさそうな輪郭でも発生している。

これは別途調査することにした。

ここで，検討していた揃え用時印（ts）は正式に廃案とすることにした。

簡単な時印更新が可能になり，公開設定機能で目立たせない再描出も可能になったので必要性を感じなくなった。となると実装と用合いの複雑化の懸念が大き過ぎる。

開発作業もほどほどに，集中して「デライトの歩み」を書き上げた。2ヶ月以上かかったが，非常にすっきりした。

書きながら，8月上旬までの律動的集中生活に入ることを決めた。金風に繋がった昨年同時期の成功体験もある。昨年と異なり，すでに非定時執務は常態化しているため，脳過熱対策で抑制していた執務時間を限界まで最大化することになる。

この調子で開発時間を確保出来るのは8月中旬までの見通しなので，上旬までに出来る限り詰め込み，あとは結果を待てる状態にしたい。ここまでの収穫も多大だったが，やはり第二次知番改良など想定外の収穫が多く，予定していた当努の進捗はやや遅れている。

先日の輪符補完機能についての閃き以後，実装方針についての迷いがほぼ消え，頭を使う時間よりも手を動かす時間が欲しい局面にもなっている。この状況なら脳過熱の懸念も小さい。温存していた体力の使い所だろう。

こう20年の歴史を振り返ってしまうと，もう一頑張りしないわけにもいかない。

（27日の振り返り日記）

写し取りアイコン調整で終了。

ここでいったん切り上げる。

輪郭小窓でも使うので，写し取りアイコンを作り，中景輪符の装体調整などをしておいた。出振るい済み。

輪括弧による写し取りは初見では分かりにくいので，以前から写し取りボタンを付けることは考えていたが，用合いの複雑化の懸念から見送っていた。

知番輪結と一体化させた最大化アイコンが成功しているため，閉じ輪括弧に一体化させるようにしてみると，これも上手く行った。さりげなく輪括弧の役割を示唆してくれる（写し取りアイコンの様子）。

ついでに，待っ読小窓の写し取りボタンもこれで統一した（待っ読小窓の様子）。これまでは絵文字（📋）で誤魔化していた。

Safari で文字が小さい入力欄に捕活するとズームが発生し，これで小窓が消えてしまう問題に気付き，一瞬ロックをかけるように修正しておいた。

デライト高速化，KNEST 隠し実装，輪数取得改良。

途中で終了。

多少排他制御周りで懸念があったため交度整理をしていたが，長いこと散らかっていた app_srv.cl.u と周辺の交度もだいぶ整理されてきた。

輪郭選り手抜控機能整備を概ね終え，ようやく出振るい出来た。追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが，抜控機能整備についてはここで一段落とすることにした。

この出振るいにより，中途半端な実装だった輪郭選り手抜控機能に一通りの機能が揃った。下書き抜控一覧も使えるようになり，抜控の把握が容易になった。予てから欲しかった新規描出フォームの消去・復元ボタンも抜控の削除のため追加した。18日の開発で実装した描写拡縮ボタンも使えるようになった。また，周辺の交度整理も大きく進み，理腑としての意義も大きかった。

利便性・信頼性の向上はもちろんのこと，昨年から中途半端な状態で引きずってきた当努が片付いたことによる精神衛生上の効果も大きい。昨年来の他の当努は本格的に着手していないか，着手して間もないので，ここから思考を整理しやすくなる。

抜控機能整備が長引いた最大の原因は，他にやりたいことが多過ぎたことだが，これ自体も決して簡単な作業ではなかった。ただ，この間に設計方針が変わったり深刻な不具合に気付いたりしたので，時間をかけたことで円滑に片付いた面もある。

再描出は知番でいいとして，新規描出の鍵をどうするか，というのは難しい問題の一つだった。昨年7月28日6歩から検索語を鍵に含めるようにして悪くなかったので，基本的にこれを踏襲することにした。ただし，全知検索窓から未送信の検索語まで取っていたため，これを書き換えると意図せず他の抜控を上書きしたり消去してしまう可能性があった（4月28日20歩で書いた消失不具合の原因だろう）。これは求頼文字列から取ることで回避した。

下書き抜控一覧についても，表示条件や領当てなど色々考えることが多かった。検討の結果，再描出下書きは，検索語無しの場合（上部メニュー同様）のみ輪郭一覧の上に表示（画面撮り），新規描出下書きは，他の抜控がある場合のみ新規描出フォームの上に常に表示させることにした（画面撮り）。邪魔になり過ぎない程度に気付きやすい。また，4月10日の開発で決めた通り，一覧は省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが，やはり，用合いの複雑化と抜控を溜め込み過ぎる懸念があるため見送った。抜控の溜め込みは性能低下，消失リスクの増大（あるいはそれを補う作業コストの増大）に繋がる。目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様の設計だった。一応，鍵仕様変更時の更新方法は考えていたが，手間を考えるところころ変えるわけにもいかないので，長期的視野に立って設計する必要があった。これもなんとか落とし所が見つかった。一時，鍵に仕様変更日時を含めることを考えていたが，これは複雑化を招くだけなので廃案とし，Aejs_DG_rev に判別用の文字列を入れておくことにした。新規描出下書き抜控の鍵には自我知番を含め，自我の切り替えにも対応した。

その他，これまで描写のみ保存していたのを知名にも対応する，消去ボタン・復元ボタンを実装する，などこまごまとした問題を片付ける必要があった。

出振るい後，軽微な不具合がいくつか見つかったが，一番気になったのが，鍵仕様の更新処理の失敗だった。領下で十分な手定めをしたつもりだが，本番環境では一部の鍵が1回の処理で更新出来なかった。結果的に，3回実行する必要があった。開発者通類で localStorage の内容を見ても交度を見返しても心当たりがない。

少し迷ったが，時間が経つにつれ重要性が急速に低下する部分なので，調査は打ち切ることにした。最も使用頻度の高い私や常連用者達が出振るい後も普通に使えていることから，深刻な問題は発生していないと判断した。今後，同様の処理を書く際の注意点として記憶しておく。