臨時休業したためのんびり作業したが，収穫はそこそこだった。

まず，輪郭選り手抜控機能整備の出振るい後，気になった問題を概ね解消した。これで気持ち良く次の当努に移れる。今後の作業方針についての考えもまとまりつつある。色々な気付きもあったが，早く寝たいので作業時に書く。

• 再描出下書き抜控の読み取りを自我毎に出来ていなかった問題を修正。
• 実質内容のない新規描出下書き抜控が残りやすい問題に暫定対応。
• 知名・描写の片方しか下書き抜控がない場合でも合体選り手を開くように修正。
  • 挙動面でまだ若干混乱があるため暫定対応。
• 新規描出下書き抜控一覧のラベルを「下書き」から「他の下書き」に変更。
  • 再描出下書き抜控一覧とともに「下書き」で統一，波括弧・角括弧のみで区別していたが，性質の違いが分かりにくかった。
  • 付け加え過ぎると冗長感が強くなり，かえって直感的な理解を妨げるのでこのあたりが落とし所か。

長い間課題だった描写拡縮ボタン，輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発で最大化アイコンが出来たことをきっかけに，描写拡縮ボタンの実装イメージが固まり，実装・手定めまで概ね完了した。想像以上に早く上手くまとまった。下見機能との相性も良い。ただし輪郭選り手抜控機能整備が途中であるため未出振るい。

• 描写拡大ボタンの様子・初期状態
• 描写拡大ボタンの様子・スクロール途中
• 描写拡大ボタンの様子・スクロール完了
• 描写拡大ボタンの様子・暗い背景色
• 描写縮小ボタンの様子

描写拡縮は機能的には単純だが，用合い，特に領当てが難しかった。最近，描写部下境界に重ねる形での実装を考えていたが，描写部を飛び出すと他の要素に干渉してしまう。かといって余白を無駄に広げたくない。これは，下部の陰影に重ねつつ，初期化時点でスクロール可能な場合は下余白を追加することで解決した。文字や暗い背景色と重なっても視認出来るように，半透明の白背景を付けた。

拡大ボタンはスクロール可能であることの目印としても効果的なので，これを活かして，スクロール完了時には透明度を上げ，それと分かるようにした。

これで，外観・操作感ともにデライトに調和した描写拡縮ボタンが出来た。描写部の高さ固定は一覧性を確保するために必要なものだったが，用合い上の弊害も小さくなかった。陰影付きスクロール，最大化アイコン，そして描写拡縮ボタンによって，ようやくこの問題が解決した。

輪郭複製機能

輪郭複製機能も課題としてずっと考えていたが，用合い上の難しさがあった。

ボタンを押すことで複製輪郭が出来る，というのは使用頻度を考えると誤操作の懸念の方が大きい。となると，目立たないように置くしかない。かといって，操作手順が増えると，選り手を開いて写し貼りするのと大差ない。

簡単に握接出来て，なおかつ制御しやすい用合いが必要だった。ここで，「知名・描写を複製して新規描出フォームに移動するボタン」があればいいことに気付いた。これなら，自輪郭に常に表示しておいてもいいだろう。

輪郭選り手では×ボタンがある位置に置けそうだ。

前後景一覧は別として，検索語無指定の場合の輪郭一覧で描写のない他輪郭を非表示にすることを検討。以前からあった案だが，いくつか懸念もあり見送ってきた。

輪郭の展示としては知名のみの輪郭は邪魔に見えることが多いが，非表示にする条件の導入により挙動が複雑になることで多少用者の混乱を招くだろう。読みやすくなる代わりに，内容のあることを書かなくてはならないという誤解で書きにくくなるかもしれない。また，知名のみの輪郭での表現にも有用なものはあるので，全て非表示というのももったいない。かといって，後景輪があるものを例外にすると中途半端で現状と大差ない。

いずれにせよ，自我で輪郭一覧の見せ方を変える仕組みは公開設定機能で整える必要があるので，その時に再検討することにした。

大変回答が遅くなってしまい申し訳ありません。色々なことを考えさせられるご質問で，デライトにとって非常に重要な宿題を頂いたように感じています。ありがとうございます。

だいぶ時間が経っているのでお考えが変わった部分もあるとは思いますが，他の方の参考にもなるように文章を残しておきます。まずは，ご質問の内容に沿って，出来るだけ端的に書けることを書いてみます。

引き入れについて

宇田川さんは、知名のみの輪郭をよく引き入れられ欄に引き入れているように見受けられます。

まず，「引き入れられ欄に引き入れる」という概念が私の中に無かったので，難しい質問でした。「引き入れる」というのは，ある輪郭の中に他の輪郭を文字通り「引き込むように入れる」，ただそれだけの極めて単純な操作で，それをする方にとっては「引き入れる」，される方にとっては「引き入れられる」ということになります。

例えば，フォルダの中にフォルダを入れる操作に相当します。ただ，多くのツールでは，データの内容とデータ同士の関連性は別々の画面に表示されます（別のウィンドウやサイドバーなど）。輪郭は，輪郭の内容と他の輪郭との関連性を一緒に表示させる仕組みを持っているのが特徴的です。これは，画面を切り替えたり視線を大きく移動することなく，内容と関連性を確認したり修正したり出来るようにする工夫です。

「輪郭をどの輪郭に引き入れたいか」というごく単純な考え方で使えるように設計したつもりでしたが，この見た目が「引き入れ欄に引き入れる」や「引き入れられ欄に引き入れる」という複雑な考え方をさせてしまっているのかもしれません。

このように、知名のみの輪郭を引き入れられ欄に輪括させるのは、主にどのような効果を狙ってのことなのか、ご教示いただけませんか。
あるいは、実際に効果があったと感じた出来事・体験をお伺いしてもよろしいでしょうか。

特に「知名のみの輪郭」という意識をしたこともありませんでした。その時に知名だけで十分なら知名だけの輪郭が出来ますし，当然その後描写に書き加えることもあります。知名があるか描写があるかということに固定的な意味はありません。私にとっては，この「知名のみの輪郭」という意味ありげな概念もどこから生じたのか不思議でした。

t_w さんも書いているように，アウトライナーで項目をざっと書き出していく感覚に近いかもしれません。ある項目をある項目の下位に移動させることも引き入れに似ています。

平面的なアウトライナーに対して，各項目が独立していて，どの角度からでも階層関係（立体階層構造）を作ることが出来る。これがデライトを「立体アウトライナー」と呼ぶ理由です。大袈裟な言い方をすれば，私はこれを使って「（普通のアウトライナーでは不可能な）森羅万象のアウトラインを書き出している」ところです。その単位をそのまま「輪郭（アウトライン）」と呼んでいます。

アウトライナーで最初にざっと書き出してみた項目も，ご質問にある「知名のみの輪郭」も，言ってみれば「情報の種」です。どのようにでも成長していく可能性があり，何がどのように役立つかは予め分かりません。ひたすら蒔いてみるしかないわけです。

「効果」というのも正直困った部分でした。私は息をするようにデライトを使っていて，その恩恵に依存して生きているようなところがあるので，「空気に効果があったと感じた出来事」を聞かれているような感覚でしょうか。

ある言葉に関連する言葉がこういう形で連なっていれば，日々気付かされることは枚挙に暇がありません。思い出せなかったことを思い出すこと，気付いていなかった概念同士のつながりを発見すること……これ自体はデライトのごく基本的な使い方です。

全知検索について

当方が同じ操作を行う場合、短期的には全知検索の検索語として、未来の自分が検索することを見込んでいます。

しかしながら、ただ検索に引っ掛かるためだけに輪郭を増やしていくと、描写のない輪郭が増え、デライトの持つ「同じ知名の輪郭を複数作れる」機能の恩恵を受けられず、形だけの輪括だけが増えていってしまうように感じてしまいます。

これも理解の難しい部分でした。「同じ知名の輪郭を複数作れる機能の恩恵」，「形だけの輪括」が何を指しているのか分かりませんでした。「描写のない輪郭が増えることで何らかの恩恵が受けられない」と感じたこともありませんでした。

そもそも，「同じ知名の輪郭を複数作れる機能の恩恵」というのは，「絶対的な名前のない情報を扱えること」以上でも以下でもない，極めて単純で自然なことだと思っています。例えば，ツイートのような思いのまとまりにいちいち名前を付けていられませんし，同じ文字列で表現されていても異なる物事がたくさんあるのが我々が住んでいるありのままの世界です。ウィキなどでは全ての物事に固有の名前を付けるという極めて不自然なことをしてきたわけです。それを排し，文字通り「なんでも」記述対象に出来るようにしたのがデライトです。

「検索に引っ掛かるためだけに輪郭を増やしていく」という表現から，どうも全知検索の趣旨が上手く伝わっていないらしいということは分かりました。全知検索というのは，「検索に引っ掛かるように輪郭を増やしていく」こととデライトに知識を蓄積していくことを同一視し，それを促進するための仕組みなのです。

引き入れによってある輪郭からある輪郭への関係が作られるということは，脳内にある情報が輪郭として表現され，それがつながっていくということです。これは頭脳をデータとして再現するということであって，デライトが実現したいことそのものです。それはそのまま検索結果を充実させることにもなるわけです。

たまに「検索用の輪郭」という表現が使われることがありますが，「検索用の輪郭」「検索用ではない輪郭」という分類も全く本質的ではありません。それが有用な分類であればそういう機能にしています。デライトではそれをあえて排しているわけですが，この意図もあまり上手く伝えることが出来ていません。頭の中にある情報は全てが他の情報を引き出す鍵でもあり，その意味では全て検索用です。それをそのままデライト上で表現して欲しいというのが全知検索の趣旨です。

私はデライトを使って自分の頭の中にある全ての物事を紐付ける作業を日々しています。それによって，頭の中で情報を引き出すようにあらゆる情報を自由自在に引き出すことが出来ています。これ以上「恩恵」のあるメモツールを私は知りません。

考え過ぎないこと

どうせ輪括するのであれば、もっと長期的な効果を見込みたく(そこそこの信念を持って輪括したく)、輪郭法を長年使い込んでいる先輩のご意見を頂戴できればと思います。

一つ助言するとすれば，個人知識管理においては「書く前に考え過ぎること」が最大の障害です。

デライトはその障害を最大限排するように設計されています。例えば，名前を付けなくても体裁を考えなくてもまずは書き出してみて，後からいくらでも修正出来るように作られています。こういった点においてデライト以上のものはなかなか無いと思います。

引き入れについても同じで，そこまで思い悩んで使うものとして作っていないのですが，実際にはあれこれ考えさせてしまうことが多いです。これは明確に伝え方の失敗であり，日々反省しているところです。

計画し過ぎないこと

「知名のみの輪郭」「検索用の輪郭」「形だけの輪括」……こうした利用者によって再発明されがちな区別を排して輪郭という単位であらゆる情報を平等化している理由は，情報が持つ役割を決めつけず，「設計」よる破綻を防ぐためです。

近年，Notion のように情報を自由に設計出来るツールが人気を集めています。それもそのはずで，誰でも最初は自分が思い描いたように設計出来ると嬉しいものです。絵に描いた餅を見ているわけですから。ただ，その大半がまず間違いなく失敗していきます。これは Notion どうこうではなく，人間の計画性というのはそんなものだからです。

個人知識管理の実践を重ねていくと，計画というものがいかに破綻しやすいかということを学びます。したがって，経験豊富な人ほど計画に依存しない方法を求めるようになります。これは，差別がなく自由市場のある社会の方が発展しやすいことにも似ています。人と同じで，情報も成り行き任せに育てていった方が強くなります。デライトは，どのツールよりもそこに最適化されたサービスです。

デライトは簡単です

デライトは，その必要性が分からなかった人にとっては「意味不明な用語が多くて分かりにくいサービス」だと思います。見慣れない UI や用語に慣れようという動機が無いからです。

一方で，本当に使いたいと思っている人にとっては実は簡単過ぎるくらいのサービスです。用語といっても小学生でも分かるくらいの表現しか使っていませんし，量も他製品に比べて特に多いとは言えません。登録するのも使うのも実際には「超かんたん」です。というのも，デライトは誰でも使えるようなサービスとして設計され，誰でも理解出来るように努めてきたからです。

ただ，この徹底した「簡単さ」が，デライトの高度な部分に惹かれてきた人ととの間にすれ違いを生んでいるのではないか，という気がしています。小学生でも分かる 1+1 について考え込んでしまう大人がいることに似ているかもしれません。デライトは難しいもの，という先入観があると，簡単さにも構えてしまいます。

デライトは簡単に使えるように作られていますし，簡単に使えるものです。

感謝

cat さんは，数少ない初期デライトの重要な貢献者です。

その方から頂いたこの質問を読んだ時，最初から最後まで意味が分からなかったことに頭を抱えました。自分は一体どれだけ利用者について理解していなかったのか，という感じです。それから毎日，開発者と利用者の間にある溝について考えてきました。回答にここまでの時間を要した理由です。

それと同時に，デライトの大きな課題を解決するヒントがここに隠されているのではないか，という気がしています。これも，率直な勇気ある質問がなければ気付けなかったことなので，本当にありがたいことだと思います。

いまデライトは，「新生デライト」に向けて文書整備を一気に進めようとしているところです。cat さんに限らず，皆様には，ふだん疑問に感じていることがあれば遠慮なく投げかけて頂きたいです。どんな疑問であれ，それと向き合うことがデライトの財産になります。

描き直しボタンを押すタイミングで知名・描写が消えてしまう不具合を発見したため応急処置して終了。

一昨日から始めていた輪郭整備と目下の課題だったまとめ作業を統合し，「大輪郭整備」として継続することにした。この上旬中に，昨年から引きずっている全てのまとめ作業を片付けることを目指す。

この期間，開発作業は必要性と時間対効果が十分高い部分に限って行うことにした。大輪郭整備に没頭するため，すぐ片付けられるこまごまとした問題は明日まとめて片付けることにした。

昨日，いったんまとめ作業に集中することにしたが，この時点では前次記法実装をした先月24日からのまとめ作業を想定していた。

しかし，一昨日の輪郭整備の手応えが思いのほか良く，昨日も止まらなかった。この勢いで，昨年から引きずっているまとめ作業も片付くのではないか，と考え始めたのが昨晩就寝直前だった。

数週間ならともかく，数ヶ月の範囲になると局所的な「まとめ作業」では埒が明かない。その上，連日新たな収穫がある。というわけで24日以前のまとめ作業は諦めかけていたが，輪郭整備という形で外堀を埋めるようにまとめていくのが意外と近道かもしれないと思えた。

最近出来たパンくず記法・前次記法の効用がやはり大きい。主たる上位階層はパンくず記法で，下位階層は強調輪符を交えつつ箇条書き記法で，前次関係は前次記法で，と基本的な輪郭間関係が書き込みやすくなり，これまで空になっていた無数の輪郭の描写が急速に充実してきている。

一昨日からは暦関連の輪郭整備が本格化し，これがまとめ作業の効率化に繋がりうることに気付いた。これまで，日記にせよ副日記にせよ，年別や月別には整理されていなかった。ずっとやりたいとは思っていたものの，時間対効果に疑問があった。当然，書き込む手間は多少増すが，今のデラングなら閲覧性と操作性の改善がそれよりずっと大きい。終わらないまとめ作業，十分に成熟したデラング，やるなら今が最良の時期だろう。

当然，現状・課題・当努の整理にも，献典整備にもなるが，もう一つの大きな狙いとして SEO がある。パンくず記法実装をした1月14日頃から顕著に検索演心からの評価が上がり，検索流入も増えている。どう転んでも損はしない作業になるだろう。

（6日の振り返り日記）

（進捗時限記録中略）

不意に閃いた「階層区切り線」についての方針をまとめて終了。

従来の見出し未満の区切り線記法に，見出し階層を越えられる「階層区切り線」を加える。以下のように，唯一通常の区切り線と区別出来る見出し記号 #（全角 ＃ も可）を使う。

* 第1階層
** 第2階層

#========================#

第1階層段落。

#------------------------#

第2階層段落。

#- - - - - - - - - - - - #

第3階層段落。

#. . . . . . . . . . . . #

第4階層段落。

##

第1階層段落（# の数でも調整出来る）。

持ち辺（モチベーション）

従来の区切り線記法は，HTML において対応する <hr> の性質上，見出し未満の区切りにしか使えなかった。

見出し階層を作った後で描写全体に対するフッター的なものを書こうとすると第1階層見出しを作る必要があるが，しばしば大袈裟に感じられることがある。

検討過程

「空見出し」の挫折

今回の検討当初は，「空見出し」という概念を主に考えていた。区切り線の長さは任意であるべきなので，どう弄っても自然な形で階層を調整出来そうになかった。その点，見出し内容を空に出来れば手っ取り早い。

しかし，等号も星号も区切り線に使う予定なので，== のように第2階層以降で内容を空にすると衝突することになる。

区切り線の方を見直しても，-- が区切り線なら == はやはり二重の区切り線であってほしい。直感性，下線形見出しとの整合性を考えるとこれは捨て難い。星号による区切り線はそれに比べればまだ転用の余地があったが，その代わり * を使う Markdown の区切り線記法との互換性が損われる。

そもそも，「空見出し」という概念にも無理がある。文字を書くから見出しなのだし，実質的に区切り線なのだから，直感的とは言い難い。

「階層区切り線」の閃き

ここで，唯一区切り線記法と被らない見出し記号である番号記号を思い出した。

番号記号による見出しは，ハッシュタグや駒手記法との衝突を避けつつ atx 式見出しとある程度互換性を持たせるため，## のように2個以上を条件に対応していた。個人的に好きな記法ではなかったこともあり，おまけのような扱いで，ここまで気付かなかった。

すでに「空見出し」に難を感じていて，区切り線記法での対応に立ち返っていたことで，この ## が特殊な区切り線とみなせる特徴を持っていることに気付いた。記号を2個以上繰り返す，区切り線に見える記法で，実際，普文の枠線的な装飾に使われることが多い記号でもある。

特に，区切り線記法としての統一感・直感性を保てる2個で第1階層を表せるということは決定的に重要な点で，見出し記号の個数と階層関係が一致しないとどうしてもちぐはぐに見えてしまう。これは，衝突を回避したとしても等号・星号では解決出来ない問題だ。区切り線記号としての最短形が見出し記号としての第1階層に対応しうる唯一の記号が番号記号だった。

ただし，通常の区切り線記号と異なり，個数が階層に対応するため，普文の装飾を兼ねられないという問題があった。上位階層の区切り線を普文上で目立つように書けない。

これは，最新の区切り線記法と下線形見出し記法の検討（9日17歩，19歩）を踏まえ，見出し階層に対応する4種の区切り線と組み合わせる形で解決することにした。つまり，第1階層から順に最短形で #==#，#--#，#- -#，#. .# というように区切り線と組み合わせることが出来るようにする。これがまた都合が良いことに，よくある装飾に見える。

9日15歩以後，見出しの下線と区切り線は長さで区別出来るようになっているため，区切り線の装体にはある程度多様性を持たせて問題ない。一方，見出しの下線は階層を表す装体になっているため，一定の制限が必要になる。この点でもぴったり噛み合った。

別に2個以上で良いだろうと実装した区切り線記法，おまけ感覚で付けた番号記号による見出し記法，最近の拡張方針……何気ない全てがパズルの要素だったかのように思える神秘的な閃きだった。

番号記号見出し仕様の厳密化

この階層区切り線の考案を機に，番号記号による見出しは常に2個を最上位階層とすることにした。つまり，*，= と ## で始まる見出しはともに最上位階層を表す。

これまで，異なる見出し記号を併用することは特に想定しておらず，実際使われていないはずなので，記号の個数は単純に計算していた。見出し階層は相対的な個数で決まるため，* で始まる見出しがあると ## は第2階層になる。これは階層区切り線と整合しない。

特に仕様として決めていたことではないため，ここで厳密化することにした。

実装上の課題

仕様は完璧に思えるが，実装上の課題は残った。

HTML と CSS の機能的には，可接性を保ちつつ見出し要素を隠すことは造作もないが，SEO 上の懸念が多少ある。今の検索演心の評価理積みはそこまで単純ではないだろうが，伝統的に見出し要素は隠すべきではないとされてきただけに，どこまで不利になるか分からない。出来るだけ行儀の良い実装方法を見つけたい。

そもそも見出し要素を空にしてはいけないのか，<section> あたりを使って上手く誤魔化せないか，など色々考えてみたが，どれも多かれ少なかれ怪しさが残る。

見出しの無い階層区切りというのは HTML の想定外だったのだろう。