AIに読ませるノートのタイトル設計：WikiLinkの頭と尾を固有化する
手順ノートの中に、内容を示すWikiLinkを丁寧に並べておいたとします。リンク先には実行してほしい具体的な手順が書かれています。ところが、AIはそのリンク先を一度も開くことなく、そのまま作業を完了させてしまうことがあります。
リンク先が読まれない原因は、タイトルの情報量が少ないからではありません。「文字起こし」のような短い名詞をリンクに置くと、AIは訓練データの中にある「文字起こし一般」のカテゴリにマッチさせてしまいます。その結果、自分には十分な前提知識がある、中身を読まなくても補完できると誤認し、「知ってるつもりモード」に入ってしまうのです。
これは、ファイル名を見ただけで中身を確認したつもりになり、結果として誤った内容を作り出してしまう失敗と同じ構造です。タイトルが短く、意味が広すぎるほど、AIが勝手な知識で補完できる余地をタイトルの側に残してしまいます。
タイトルの頭で予測モードを変える
それでは、タイトルを長くして命題の形にすれば解決するでしょうか。そうとは言い切れません。AIはWikiLinkのタイトルを左から順に読みます。そして、頭の数トークンを見た瞬間に予測モードを決め、そのモードで残りを補完してしまいます。
「タスク」「管理」「処理」「方法」のような一般名詞から始まると、たとえ尾に固有語があっても、AIは訓練データの一般パターンに寄せて読み飛ばします。「録画は日付付きタイトルで保管する」というテーゼ形式のタイトルにした場合でも同様です。これでも手順は示されていますが、頭にあるのは「録画」という一般名詞です。AIは冒頭の「録画」で訓練データのカテゴリに接続し、尾部の固有契約を読む前に「録画の話だな」と判断して勝手に動き始めてしまいます。
読み飛ばしを防ぐためには、長さではなく、冒頭の位置で訓練データとのマッチを断つ必要があります。
頭を固有化する手段は、絵文字タグ、プロジェクト名、固有動詞、具体主語などです。先頭の1〜2トークン目に訓練データの平均から外れる要素を置くことで、AIは知ってるつもりモードに入れなくなります。「録画」を「Zoom録画」に変えるだけでも、一般カテゴリにマッチする余地は大きく減ります。冒頭で一般パターンへの接続を塞ぐことで、AIは最後までタイトルを読むしかなくなります。
両端を固有化して行動契約を定める
もっとも、頭を固有化するだけでは十分ではありません。タイトルの頭が予測モードを決めるのだとすれば、尾は行動モードを決めます。
命題の結びが「〜する」「管理する」「実行する」「改善する」のような抽象動詞になっていると、AIは訓練データの一般的な動作パターンで行動を補完してしまいます。指示に対して何かそれらしい動きは返すものの、固有の手順には従わないという結果に終わります。
ここで注意したいのは、タイトルの中間にだけ固有語を挟む形です。たとえば「タスク・ブックカタリスト収録の・管理をする」というタイトルを考えてみます。中間にプロジェクト名が入っていますが、頭は「タスク」、尾は「管理をする」という一般語のままです。これでは、頭の「タスク」で一般の予測モードに入り、尾の「管理をする」で一般的な管理行動を補完してしまいます。固有語は中間に挟んでも効果がありません。両端に置かないと効かないのです。
尾を固有化するためには、具体的な目的語、固有名詞、具体数字を動詞の前に置くか、あるいは「〜すべき」「〜が最適」といった規範性のある語で閉じます。「管理する」で終わらせるのではなく、「管理ノートに1行追記する」のように指定します。訓練データに存在しない固有の行動契約を尾で定義することで、AIが一般的な挙動に流れるのを防ぐことができます。
ノートの種別に応じて最小限で止める
両端の固有化が有効だからといって、どこまでも具体的に書き足せばよいわけでもありません。
「録画」を「Zoom録画」に変えると、一般カテゴリへのマッチは大幅に断たれます。しかし、そこからさらに「Zoom会議の録画ファイル.m4a」まで伸ばしたとしても、AIに読ませる効果はほとんど増えません。かえって人間にとってもAIにとっても読みにくさのコストが勝ってしまいます。固有化の限界効用は逓減するのです。
最適点は、AIが訓練データでマッチできない閾値を超えた地点です。目的は情報量を増やすことではなく、訓練データにない固有の契約を成立させることにあります。マッチを断つ最小の固有性が成立した時点で、それ以上の書き足しは止めるのが適切な設計です。
また、この頭と尾を固有化する設計は、すべてのノート種別に一律に適用するものではありません。
命題を扱うPermanentノートや、手順を扱うALPs管理ノート・notes/alpsタスクファイル名では、尾に抽象動詞があるとAIが勝手に行動を補完するため、頭と尾の両方を固有化する必要があります。
一方で、事実ベースの記録であるPersonalノートであれば、頭の固有化だけで足ります。Personalノートは、頭に日付や固有名詞を置くだけで時点と主体が一意化されます。尾の動詞が「〜した」のような一般動詞であっても、頭の固有性が強ければ訓練データの外にとどまることができます。記録の尾にまで無理に命題性を求めると、かえって記録される体験が歪み、ファイル名を見ただけの確認と同じ捏造のリスクにつながってしまいます。ノートの種別によって、どちらの端を優先するかを見極める必要があります。
頭と尾の2〜3文字で確かめる即席テスト
タイトルが十分に固有化されているかどうかは、簡単な方法で検算できます。
最初の2〜3文字と、最後の2〜3文字だけを拾って読んでみます。その数文字だけで、「タスク管理」「情報整理」「プロジェクト運用」といった訓練データの一般カテゴリが頭に浮かぶなら、固有化が足りていません。AIは両端で予測を決めるため、両端の数文字を見るだけで固有性の判定が成り立ちます。
たとえば「タスクの〜を管理する」というタイトルでは、頭の2文字は「タス」、尾の3文字は「理する」です。これらを並べると、すぐに「タスク管理」が思い浮かびます。この状態では、AIも訓練データの一般パターンで処理してしまいます。
これに対して、「🏕️BC収録の〜を完了処理に置く」というタイトルであれば、頭は「🏕️B」、尾は「に置く」となります。これだけを見ても、一般的なカテゴリは浮かびません。一般カテゴリへの接続が断たれているため、AIは知ってるつもりモードに入れず、WikiLinkを開いて中身を確認するようになります。
AIに読ませるためのタイトル設計とは、単に言葉を尽くして情報を詰め込むことではありません。WikiLinkの頭で安易な予測モードを塞ぎ、尾で固有の行動契約を定義することです。そして、その固有化は一般カテゴリとの接続を断つ最小限にとどめます。両端の数文字を適切に設計して初めて、AIは前提知識による読み飛ばしをやめ、意図した通りの手順を読み進めるようになります。