注釈は人間のために書く。

// GetUser retrieves a user by ID from the database.
func GetUser(id string) (*User, error) {

この注釈は人間が読めば役に立つ。しかし機械が読むと何もわからない。“retrieves"がReadなのかSearchなのかわからない。“user"がどのエンティティなのかわからない。この関数がServiceパターンなのかRepositoryパターンなのかわからない。

注釈が叙述だからだ。

関数が10,000個あるとき

関数が10個なら問題ない。人間が全部読めばいい。

関数が10,000個あるときは違う。「決済関連の関数を全部見せて」と言ったとき、人間も見つけられないし機械も見つけられない。名前に"payment"が入っているものだけ見つける。名前に入っていなければ見落とす。

AIエージェントがコードを修正するときも同じだ。Claude Codeに「PaymentFailedエラー処理を修正して」と言えば、エージェントはコード全体を読み直す。毎回。関数10,000個を毎回最初から把握する。昨日読んだコードを今日また読む。注釈があっても同じだ。注釈が人間用の叙述だから。機械が叙述から意味を抽出するには推論が必要だ。コストがかかる。

注釈がインデックスなら

// CreateOrder processes a new order creation.
//
// # Pattern: Service, Transactional
// # Entity: Order
// # Action: Create
// # Input: CreateOrderRequest {items:[]Item, userID:string}
//          pre: items>0 userID!=''
// # Output: *OrderResponse, error
//          errs: [StockInsufficient, PaymentFailed]
// # Deps: InventorySvc, PaymentGateway
func (s *OrderService) CreateOrder(req CreateOrderRequest) (*OrderResponse, error) {

この注釈は人間も読めるし、機械も読める。

「Serviceパターンの全関数」→ Patternフィールド検索。即座に。 「Orderエンティティ関連の全関数」→ Entityフィールド検索。即座に。 「PaymentFailedを発生させる関数」→ errsフィールド検索。即座に。

フルスキャンがインデックス検索に変わる。O(n)がO(1)になる。

人間が書く必要はない

このインデックスを人間が作成する必要はない。

コードが修正されると自動的に検知する。ファイルウォッチング。 修正された関数をASTで分離する。機械的。 関数本体を小型LLMに渡す。「この関数のパターン、エンティティ、アクションを判断せよ。」 判断結果を決められたフォーマットで挿入する。機械的。

人間は何もしない。コードを書くだけでいい。インデックスは自動的に付く。

パイプライン全体でLLMが介入するポイントはたった一つ — 関数の意味を判断すること。残りはすべて決定的コードだ。

推論からルールへ

ここからもう一段階進む。

小型LLMが同じパターンに同じインデックスを繰り返し付けると — その繰り返しを検知する。「Service suffixにreceiver methodならPattern:Service」が100回繰り返されたら、ルールとして固定する。以降LLMを呼び出さない。ルールが処理する。

LLM呼び出しが徐々に減る。ルールが徐々に増える。コストが0に収束する。

注釈が叙述からインデックスに変わり、 インデックスが手動から自動に変わり、 自動が推論からルールに変わる。

なぜ可能なのか：デザインパターンというコードブック

これが可能な理由がある。

プログラミングにはすでに標準化された意味語彙がある。デザインパターンだ。

Singleton、Factory、Observer、MVC、Service。GoFが1994年に23個のパターンを整理して以来、ソフトウェア業界は30年間この語彙を拡張し標準化してきた。

GoF 23パターン。Enterprise Application Patterns。Cloud Design Patterns。Go Concurrency Patterns。すべてすでに整理されている。

この語彙は曖昧ではない。SingletonはSingletonだ。開発者によって解釈が異なることはない。定義が合意されており、実装条件が明確であり、違反すればコードレビューで指摘される。

この語彙体系がインデックスのコードブックになる。新たに作る必要はない。すでにある。

自然言語にはこれがない。「偉大だ」は辞書に定義があるが人によって使い方が違う。コードではServiceが人によって異なる使われ方をしない。

なぜコードが最も簡単なドメインなのか

GEULのコンテキストパイプライン — 明確化、インデックス化、検証、フィルタリング、整合性、探索 — を自然言語に適用するのは難しい。コードに適用するのは簡単だ。

明確化：自然言語は曖昧だ。コードはコンパイラが通せば意味が確定している。 インデックス化：自然言語のエンティティは文脈を見なければわからない。コードのエンティティはASTがすでにパースしている。 検証：自然言語の有効性は定義できない。コードの有効性はコンパイラが判断する。 フィルタリング：自然言語の関連性はLLMが判断しなければならない。コードの関連性はコールグラフで機械的に判断できる。 整合性：自然言語の矛盾は推論して初めて発見される。コードの矛盾は型システムとテストが検出する。 探索：自然言語の知識は平面的だ。コードはパッケージ → ファイル → 型 → メソッドの階層構造がすでにある。

同じパイプラインが、コードドメインではるかに低いコストで動作する。最も簡単なところでまず証明し、難しいところへ拡張する。これが工学だ。

まとめ

注釈はもともと人間のためのものだった。 今は機械のためのものでもなければならない。 人間が読めて、機械が検索できる注釈。 叙述であり、インデックスでもある注釈。

コードにはすでに意味があり、すでに構造があり、すでに語彙がある。 ないのはインデックスだけだ。 注釈がそのインデックスになればいい。