AIに読ませるノートのタイトル設計

AIに読ませる手順ノートのリンクを、「文字起こし」から「録画は日付付きタイトルで保管する」へ直したとします。短い名詞では内容が伝わらないと考えて、主語と行動を含む命題形に変えた状態です。それでもAIはリンク先を開かず、「録画についての一般的な話」として処理を始めることがあります。

対象素材で扱われている観察では、読み飛ばしを分けるのは情報量よりも、既知の一般カテゴリとして補完できる余地です。タイトルの先頭を一般的でない語に変え、末尾にそのノート固有の処理を書きます。一般的な分類を連想できなくなった時点で、それ以上は書き足しません。

命題形でも一般カテゴリから始まれば読み飛ばされる

「文字起こし」のような短い名詞は、多くの意味を含められます。リンク先にその手順だけの条件や判断が書かれていても、タイトルだけを見たAIには、既知の文字起こし一般の知識で続きを補える余地があります。そのため、リンク先を確認せずに処理を続けられてしまいます。

ただし、短さだけを原因と考えて長い命題へ直しても、問題が残る場合があります。「録画は日付付きタイトルで保管する」は、何をどうするかまで書かれています。それでも冒頭の「録画」が一般的なカテゴリへつながるため、後ろにある「日付付きタイトルで保管する」という条件をAIが参照する前に、録画管理の話として補完される余地があります。

説明を増やして文字数を伸ばしても、一般的な言葉の組み合わせなら、AIは前提知識から続きを推測できます。

「録画」を「Zoom録画」に変え、末尾にそのノートだけの具体的な処理を書けば、一般論だけでは内容を決めにくくなります。対象素材は、これを「固有の契約文」と呼んでいます。

すべてのAIやモデルでリンク先を開くことまでは保証できません。成功率やモデルごとの再現条件を示す素材はなく、この設計は対象のWikiLink運用で読み飛ばしの余地を減らすものです。「予測モード」「行動モード」は対象MOCの観察を説明する呼び方で、モデル内部の仕組みとして外部検証されていません。

先頭の語から話題を予測し、末尾の語から行動を補完する

タイトルの先頭にある語は、AIがその後をどの種類の話として読むかに影響します。「タスク」「管理」「処理」「方法」のような一般名詞から始まると、後ろにプロジェクト名や固有の条件があっても、一般的な内容として補完される可能性が残ります。

先頭を固有化するときは、絵文字、プロジェクト名、パス名、固有動詞、具体的な主語などを置きます。「録画」を「Zoom録画」に変えるのも、この操作です。頭トークンで一般カテゴリに一致する余地を減らし、残りを既知の型だけで補いにくくします。

タイトルの末尾に具体的な目的語や完了条件がないと、AIはその後の行動も一般的な型から補えます。「管理する」「実行する」「改善する」のような抽象的な動詞だけで終わる場合が該当します。

末尾には、具体的な目的語、固有名詞、数字を動詞の前に置きます。「管理ノートに1行追記する」なら、対象と処理量が決まります。「〜すべき」「〜が最適」のように規範性のある言葉で終える方法もあります。抽象動詞の手前に、そのノートでしか決まらない処理を書くことが重要です。

中間に固有語を一つ置いても、先頭と末尾の役割は変わりません。たとえば「タスク・ブックカタリスト収録の・管理をする」は、真ん中に固有名詞があります。しかし先頭の「タスク」から一般的な内容だと判断され、末尾の「管理をする」でも処理内容を特定できません。中間を詳しくする前に、両端を直す必要があります。

先頭に一素材、末尾に一素材を置いて書き換える

書き換えは、現在のタイトルを先頭・中間・末尾に分けるところから始めます。最初に先頭の一般名詞を見つけ、絵文字、プロジェクト名、具体的な主語などのうち一つへ置き換えます。次に末尾の抽象動詞を見つけ、具体的な目的語や数字を伴う処理へ変えます。

「録画は日付付きタイトルで保管する」なら、先頭の「録画」を「Zoom録画」へ変え、末尾の「保管する」には保存先や実行する処理を伴わせます。対象素材にある別の型では、「管理する」を「管理ノートに1行追記する」へ変えています。これで、指定されたノートへ指定された量だけ追記する処理を示せます。

固有性を強める素材は一種類に限りません。絵文字とパス名、プロジェクト名と具体数字のように、異なる種類を組み合わせると、一般的な型から外れやすくなります。

ただし、最初から多くの要素を加える必要はありません。目安は先頭に一素材、末尾に一素材です。両端に異なる役割の固有性を置くことを優先します。

ノートの種別に合わせて、固有化を最小限で止める

ノートの種別によって、固有化する端が変わります。命題を扱うPermanentや、具体的な実行を求める手順系ノートでは、先頭と末尾の両方を固有化します。先頭で扱う対象を限定し、末尾に固有の行動や判断を書く必要があるためです。

一方、事実を記録するPersonalでは、先頭の日付や固有名詞によって時点と主体が一意になれば、それだけで足りる場合があります。ノートの役割が事実の記録なら、両端を同じ方法で固める必要はありません。

固有化の長さにも止め時があります。「録画」から「Zoom録画」への変更は、一般カテゴリに一致する余地を大きく減らします。しかし「Zoom会議の録画ファイル.m4a」のように情報を重ね続けても、読み飛ばしを減らす効果が同じだけ増えるとは限りません。

むしろ、人間とAIの双方がタイトルを読み取りにくくなります。

一般カテゴリだけでは補えなくなったところで止めます。そのノートを読まずに一般論だけで処理できないようにするのが目的です。先頭に一素材、末尾に一素材を置いて必要な具体性を確保できたら、追加の条件は本文に書きます。

最初と最後の二〜三文字で固有性を確認する

書き換えた後は、タイトル全体を読み返す前に、最初と最後の二〜三文字だけを取り出します。その二つから「タスク管理」「情報整理」「プロジェクト運用」のような一般カテゴリをすぐ連想するなら、どちらかの端に固有化の余地が残っています。

「タスクの〜を管理する」は、先頭の「タス」と末尾の「理する」だけでもタスク管理を連想できます。中間に固有のプロジェクト名が入っていても、両端だけで一般的な組み合わせが完成しています。この場合は、中間へ説明を足さず、一般カテゴリを連想する側の端を直します。

反対に、先頭が絵文字とプロジェクト名で始まり、末尾にその仕事だけの完了処理が書かれていれば、両端だけから一般カテゴリを組み立てにくくなります。そこで初めて、両端を固有化できたと判断できます。

最後に、書き換えた「Zoom録画〜」の最初と最後の二〜三文字だけを読みます。一般的な「録画管理」を連想しなければ、その時点で変更を終えます。