あなたのVaultに「ニンニク入れますか？」── Obsidian とエージェントに指示するときの自家製造語のススメ
本記事は、筆者が所属するクイックイタレート株式会社で社内エージェント環境を構築した際の整理メモをもとにしています。
関連する公開事例は 事例紹介 をご覧ください。
LLM（Local/フロンティアモデル） × エージェントツール × 社内システム連携の
設計・構築・運用のご相談も承っております。
はじめに
ローカル/クラウド LLM をエージェント化し、Obsidian を知識ストアとして運用していると、指示がうまく通らない瞬間に何度も出くわす。
原因をモデルの賢さに求めたくなるが、観察を続けると犯人はたいてい別のところにいる。
こちらがエージェントに渡している「語彙」 だ。
この記事は、その語彙設計についてひとつの結論を提案する ── Obsidian とエージェントに指示するときは、一般的な言葉ではなく 自分で造った語(自家製造語) を使え、という話だ。
そして、なぜそれが「気取り」でも「中二病」でもなく、検索と retrieval の両方に効く合理的な設計判断なのかを、"ラーメン二郎のあの一言"から説明していく。
第1章 ── ラーメン二郎の「コール」という発明
ラーメン二郎では、麺の湯切りが終わるころ、店員がこう聞く。
「ニンニク入れますか？」
これは単なる確認ではない。客が コール を発する合図だ。客はここで「ヤサイマシマシ、ニンニク、アブラ、カラメ」のように、トッピングの構成を一息で宣言する。ヤサイは茹でた野菜の山、マシは増量、アブラは背脂、カラメはタレの追い掛け。何もコールしなければ、すべて「普通」になる。
ここで注目したいのは、この語彙の性質だ。
-
閉じた共有語彙である。
「カラメ」は二郎の文脈の外では通じない。
一般のラーメン店で「カラメ」と言っても厨房は固まる。 -
曖昧さがない。
「野菜は多めで、脂も多めにして、味は濃いめで」という一般語の注文は、解釈の幅を持つ。「多め」がどれだけかは店員の裁量に委ねられる。
対してコールは、店と客が同じ辞書を共有しているから、一意に実行される。 -
強制力がある。
コールは「その形式で言わなければ正しく届かない」。
これは制約であると同時に、伝達の精度を保証する仕組みでもある。
つまり二郎のコールは、
閉じたコミュニティが共有する、曖昧さを排除するための造語体系 だ。
そしてこれは、私たちがエージェントに指示を出すときに直面する問題と、構造がそっくり同じである。
設計の核心①
コールが機能するのは「店が同じ辞書を内面化しているから」だ。
客のコールは、店側の知識ストアがなければ意味を持たない。
造語と知識ストアはセットで初めて働く。
第2章 ── 一般語で指示するとなぜ失敗するか
エージェントに「この 集約 処理を実装して」と指示したとする。「集約」は一般語だ。
すると何が起きるか。
LLM は「集約」について、パラメータの中に膨大な知識を持っている。だからエージェントは、Obsidian のノートを一度も開かずに、それっぽい一般論で答えを組み立ててしまう。
プログラミングでいう キャッシュヒット だ ── パラメトリックな知識空間で「集約」が引っかかってしまい、本物のストア(Obsidian)へ問い合わせが飛ばない。
返ってくる答えは流暢で、一見正しい。だが、それは あなたの言う「集約」ではない。
あなたの設計ノートに書かれた固有の制約や前提を、まったく反映していない。
流暢さと接地のなさが同居した回答 ── これがいちばん危険な失敗モードだ。間違いとして目立たないからである。
造語はこれを構造的に潰す。「時報型集約」という語は、LLM のパラメータ内に ゼロ件 でしか存在しない。だからキャッシュミスが保証される。ミスすれば、エージェントは retrieval に降りるしかない ── つまり Obsidian の定義ノートを引きにいくしかない。
第3章 ── 自家製造語に求める4つの要件
ここまでをふまえると、「Obsidian とエージェントに渡す語」に求めたい性質は、
次の4つに整理できる。
| # | 要件 | 一般語だと | 造語だと |
|---|---|---|---|
| 1 | 自分が意味を忘れない | 忘れにくい(が誤ヒットする) | 部品から再構成できれば保てる |
| 2 | パンチ力(想起の引っかかり) | 弱い・他に埋没する | 強い・固有名として立つ |
| 3 | 他の語と混ざらない | 混ざる・検索結果が汚染される | 混ざらない・検索が一意 |
| 4 | エージェントが Obsidian から引かざるを得ない | パラメトリックに即答されてしまう | キャッシュミスし retrieval を強制 |
重要なのは、
この4つを 同時に(AND で)満たす語は、既存の語彙のなかには存在しない ということだ。
要件3と要件4を満たそうとすると、語は一般語であってはならない。要件1と要件2を満たそうとすると、語は意味不明な記号であってもいけない。
この AND の交点に残る選択肢はひとつだけ ── 自分で造ること である。
自家製造語は、4つの要件から逆算して導かれる必然であって、趣味ではない。
第4章 ── 造語は forcing function である
4つの要件のなかで、いちばん深いのは要件4だ。これは要件3の裏返しでもある。「他の語と混ざらない」を人間の検索の都合で見れば要件3、エージェントの retrieval の都合で見れば要件4になる。同じコインの裏表で、後者のほうが設計目的として本質的だ。
造語のいちばんの働きは、
エージェントが「自分の知識でごまかす」経路を物理的に塞ぐ ことにある。
ソフトウェア設計でいう forcing function ── 望ましい挙動を「選択肢」ではなく「唯一の道」にしてしまう仕掛けだ。
設計の核心②
一般語は、エージェントに「答えてもいいし、ストアを引いてもいい」という分岐を残す。造語は、その分岐を消す。パラメータ内にヒットしないので、ストアを引く以外の道がなくなる。
造語とは、retrieval を「任意」から「強制」に変える制約である。
第5章 ── decodability の綱引き(要件1 vs 要件4)
ただし、ここに微妙な綱引きがある。
要件1(忘れない)と要件4(引かせる)は、完全には両立しない。
造語が「読み解けすぎる」と、つまり「定時データ集約処理」のように部品から意味が完全に復元できてしまうと、エージェントもまた同じように部品分解して「ああ、周期的な集約のことね」とパラメトリックに即答してしまう。forcing function が漏れるのだ。
逆に、完全な記号(Project Zircon のようなコードネーム)にすると、要件4は完璧に満たすが、要件1が死ぬ。半年後の自分が、語の意味を思い出せない。
| 命名の型 | 例 | 要件1(忘れない) | 要件4(引かせる) | 判定 |
|---|---|---|---|---|
| 完全な記号 / コードネーム | Project Zircon |
✕ 忘れたら終わり | ◎ 必ずキャッシュミス | 要件1で死ぬ |
| 完全に部品分解できる句 | 「定時データ集約処理」 | ◎ | △ エージェントも分解し即答 | forcing function が漏れる |
| マーク付きの造語 | 「時報型集約」 | ○ 部品から再構成可 | ○ 非標準で “定義語” と分かる | ★ 狙う帯域 |
良い造語が狙うのは、この狭い帯域だ ── 人間は部品から再構成できるが、エージェントには「これは定義語であって一般句ではない」と見える 程度の、マーク付きの語。
「時報型集約」の「時報型」という修飾子は、十分に非標準なので、ちょうどこの帯域に乗る。人間は「時報のように定時で動くやつ」と再構成でき、エージェントは「“時報型” という標準的でない修飾 ── これは定義済みの語だな」と気づける。
第6章 ── 造語は必要だが十分ではない:運用プロトコル
ここが最後の、そして実務的にいちばん大事な点だ。
造語はキャッシュミスの 機会 を作るだけだ。そのミスを実際に Obsidian まで取りにいくか、それとも部品分解で勝手に埋めるかは、エージェント側のプロトコル次第である。造語だけでは tripwire は完成しない。次の4点を組み合わせて初めて、信頼できる仕掛けになる。
1. wikilink を型注釈として使う
ノート本文で造語を使うときは、[[時報型集約]] と wikilink で書く。
これは単なるナビゲーションではない。「これは定義済みのノード、一般句ではない」という 型注釈 であり、エージェントへのマーク付け信号だ。
2. frontmatter の aliases に自然言語の入口を残す
造語の唯一の失敗モードは「語そのものを忘れる」ことだ。
これを救うために、定義ノートの frontmatter に自然言語の言い回しを流し込んでおく。
---
aliases:
- 定時集約
- スケジュール集計
- 周期ポーリング集約
tags:
- 用語/造語
---
これで、造語を覚えていても、忘れて「定時集約」と打っても、同じノートに着地する。造語の鋭さ(一意性)と、自然語の網羅性を、両取りできる。
3. 用語集 MOC を一枚作る
造語を定義一行付きで並べた索引ノート(MOC)を用意する。「語そのものを完全に忘れた」という最後の失敗モードは、この一覧を眺めることで救われる。検索が無ヒットを返す唯一のケースを、index が拾い上げる。
4. エージェント側に規律を持たせる
システムプロンプトなりルールファイルなりで、こう明示する ── 「制約マーク付きの語(wikilink された語、用語/造語 タグを持つ語)に出会ったら、答える前に必ず定義ノートを retrieval せよ」。造語が tripwire なら、これはそのワイヤーに繋がる回路だ。ワイヤーだけ張っても、回路がなければ何も起きない。
この図は、二郎のカウンターと同じ構造だ。客と店員のあいだに「コール」があり、コールは店の内部システム(辞書)に解決され、その辞書が厨房と客の両方に同じ意味を供給する。
第7章 ── magic string と typed symbol
この記事の主張は、プログラミングの言葉でひとことに圧縮できる。
一般語は magic string だ。 ソースコードに直書きされた文字列リテラル ── コンパイラはその意味を知らず、型チェックもできず、どこで何を指しているか追跡もできない。
自家製造語は、名前空間付きの typed symbol だ。 定義が一箇所にあり(定義ノート)、参照は型付きで(wikilink)、コンパイラ(エージェント)はそれを勝手に別物へ型強制できない。
二郎のコールに戻れば ── 「野菜多めで」は magic string、「ヤサイマシマシ」は typed symbol だ。前者は店の裁量に解釈を委ね、後者は店と客の共有辞書に一意に解決される。
おわりに ── 知能 × 文脈 = 人格
最後に、もう少し大きな枠に接続しておきたい。
筆者はこのシリーズで、エージェントを 「知能 × 文脈 = 人格」 という形で捉えてきた。LLM が抱えるのは知能だけで、知識・特性・制約は外部化される ── という非対称の設計だ。
自家製造語は、この枠のなかで 制約(文脈)の一種 として働く。それは、知能を LLM 側に・意味と知識を Obsidian 側に貼り付けたまま、その境界が漏れないようにするための インターフェースのロック だ。造語は、エージェントが境界を越えて「自分の知能で意味を埋める」ことを防ぐ。
だから、自家製造語を作るという行為は、ノート作成のコストではない。それは検索精度(人間)と retrieval 精度(エージェント)の両方に同時に配当を生む 投資 であり、エージェントの人格をあなたのストアに接地させ続けるための、設計上の必須部品なのだ。
次に Obsidian で新しい概念に名前をつけるとき、思い出してほしい。エージェントは、湯切りを終えてあなたにこう聞いている ── 「ニンニク入れますか？」。
そこで一般語を返すか、それとも、あなたとエージェントだけに通じるコールを返すか。それが、接地した人格を持つエージェントと、流暢なだけのエージェントとを分ける。
私個人は Obsidian や Vault は、日本語と相性が悪く自動音声で捉えられにくいのでVault全体を「ポチノート」と独自に呼称していたりする。 言葉が汚れたり新たな言葉が生まれたりするのではないかと少しだけどきどきしたりする。
関連記事
本記事は、筆者が所属するクイックイタレート株式会社で社内エージェント環境を構築した際の整理メモをもとにしています。
関連する公開事例は 事例紹介 をご覧ください。
LLM（Local/フロンティアモデル） × エージェントツール × 社内システム連携の
設計・構築・運用のご相談も承っております。