ドメイン知識はすべてAIに引き継げなかった・・・

前回書いたこと

前回、「AIでスケールするって、速さの話じゃない」という記事を書いた。

要点は、判断基準を外部化すれば、自分がいなくても価値が生まれ続ける状態を作れる、という話だった。WorkとTaskを分けて、Taskは判断基準を与えればAIに任せられる、と。

希望を込めて書いた。そして実際に試してみた。

コーディング・テストはうまくいった

まず、コーディングとテストの領域では、AIとの協働がうまく機能している。

手順をスキルとして整備すれば、AIは期待通りに動く。エラーが出れば修正する。フィードバックループが回る。これは「判断基準の外部化」が機能している領域だ。

だから次のステップとして、他の領域にも拡張しようと考えた。

要求から要件へ——そこで壁にぶつかった

試したのは、要求から要件を導出する作業だ。

ここにはドメイン知識が大量に必要になる。業務の背景、過去の経緯、ステークホルダーの関係性、暗黙の制約。これらをAIに渡さないと、適切な判断ができない。

結果、何が起きたか。

レートリミットに達する。

ドメイン知識を詰め込むと、コンテキストが膨らんでトークン制限に引っかかる。全部は渡せない。

Agent分解しても解決しない

「じゃあAgentを分解すればいい」と思うかもしれない。

でも、ドメイン知識は分割できない。どのAgentも同じ文脈を必要とする。分解しても、各Agentにドメイン知識を渡す必要がある。むしろトークン総量は増える。

結局、ある程度待たせる設計にするしかない。AIの即時性という利点を、一部諦める。

それでも想定外の判断が起きる

レートリミットを回避しても、次の問題がある。

AIの判断が想定外になる。

スキルが足りなければ「できない」「エラーになる」と明示的に失敗する。しかしドメイン知識が足りない場合、AIは自信を持って間違った判断をする。しかもその判断は表面上もっともらしく見える。

原因を探ると、ほとんどがドメイン知識の不足だった。

ドメイン知識はなぜ引き継げないのか

ドメイン知識を整備しようとして、いくつかのことに気づいた。

まず、知識そのものだけでは足りない。「Xの場合はYを選ぶ」という知識があっても、なぜYなのか（理由）、AとBが衝突したらどちらを取るか（優先順位）が必要になる。

そしてこの理由と優先順位は、暗黙知だ。人間のエキスパートは無意識に統合して判断しているから、聞かれても後付けの説明しか出てこない。

次に、指摘の問題がある。AIの判断を修正したとき、それが「恒久的に適用すべきドメイン知識」なのか「今回だけの例外」なのか、AIには判断できない。人間側も、指摘している時点では区別していないことが多い。

結果、断片的にドメイン知識が蓄積される。それぞれの関係性は記述されていない。知識AとBが矛盾したときどうするかは不明。全体としての一貫性は保証されない。

そして根本的な問題がある。

人間は、AIに渡さない様々な情報に接することで、断片的な知識を意味づけしている。タスクに直接関係ない会話、組織の空気感、過去の失敗体験。これらの「ノイズ」が、知識をつなぐ接着剤になっている。

AIには「タスクに必要な情報」しか渡せない。しかし人間がドメイン知識を使いこなせるのは、渡されていない膨大な文脈の中でその知識を位置づけているからだ。

渡せないものが、渡したものに意味を与えている。

ドキュメントの問題

ドメイン知識を整備しようとして、ドキュメントについても考えが変わった。

背景情報がないドキュメントには価値がない。

従来のドキュメントは「何をするか」（What）を書く。正確性と網羅性を重視する。背景は「自明」または「別の場所にある」と仮定している。

しかし、Whatを書いただけのドキュメントは、読み手が既に文脈を持っていることを前提にしている。人間同士ならある程度共有できる。AIには、その前提がない。

そしてもう一つ気づいたことがある。

設計書に書いてあることは、コードから読み取れる。

何を作ったか、どう作ったか、現在の構造。これらはコードを見ればわかる。設計書がWhatだけを書いているなら、それはコードの劣化コピーでしかない。しかも時間とともに乖離していく。

本当に必要なのは、コードから読み取れないものだ。

なぜこうしたか（Why）。何を選ばなかったか（What not）。どういう制約下での判断か。何を諦めたか（Trade-offs）。

これらは時間が経つと人間も忘れる。そしてコードには残らない。

AIにとっても、Whatは読めばいい。しかしWhyがないと、「変えていいのか」「ここは触るべきでないのか」が判断できない。

100%を目指さない

ここまで考えて、一つの結論に至った。

100%の引き継ぎを目指してはいけない。

100%を目指すと、言語化コストが際限なく膨らむ。構造化が追いつかず断片が爆発する。メンテナンス不能になる。そして原理的に到達不可能だ。

これは精神論ではない。レートリミットという物理的制約がある。渡せない文脈が意味を与えているという構造的限界がある。

むしろ設計すべきは、AIが判断できる範囲を明確にして、その外側は人間に戻す仕組みだ。境界を意図的に引く。

前回の記事で、WorkとTaskを分けると書いた。Workはステークホルダーとの調整、Taskは調整に必要な活動。

今回の発見は、この区分を補強する。

ドメイン知識の完全移転は原理的に不可能だ。だからこそ、人間が調整を担う設計に必然性がある。100%を目指さないと決めることで、逆に「どこまでをAIに任せるか」の線引きが明確になる。

「不完全で良い」と決めることで、初めて持続可能な協働になる。

コーディングが速い分、他で時間をかける

最終的に見えてきたのは、こういう設計だ。

コーディング・テストは速くできる。AIとの協働が機能する領域だ。

要求から要件への変換は、時間がかかる。ドメイン知識が密に必要で、レートリミットもある。ここは待たせる設計にする。

全体として、「全部速く」ではなく「どこを速くして、どこは待つか」のバランスで成立させる。

AIとの協働は、万能ではない。でも、限界を理解した上で設計すれば、機能する。

前回は希望を書いた。今回は現実を書いた。次は、この現実の中でどう設計するかを考えていく。