Specialty AI Architectureの完成

Knowledge FoundationのRuntime検証を重ねる中で、Knowledge Structuring AIへEntity抽出・Relation生成・Knowledge生成・更新判定など多くの責務を集約した構成では、Promptが大規模化し、LLMがEvidenceよりもルールやSchemaを優先して解釈してしまうことが分かりました。SchemaSelectorによる対象Schemaの絞り込み、Prompt改善、JSON構造の見直しなど様々な対策を行いましたが、本質的な改善には至りませんでした。

そこで設計を根本から見直し、1つのAIにすべてを任せる構成を廃止しました。代わりに、User・Company・Project・ParentTask・ChildTask・AI・Document・Codeといった専門領域ごとに処理を分けるSpecialty構成へ移行し、共通実行基盤であるGenericCandidateBuilder、CandidateValidator、判定処理、Knowledge Repositoryへ接続する新しいアーキテクチャへ切り替えました。専門領域ごとに個別のAIを作るのではなく、共通の実行基盤の上で、専門領域ごとの定義（Definition）とPromptによって処理を切り替える方式としています。

また、LLMの役割も根本から見直し、従来のようにEntity全体を生成させる構成を廃止しました。LLMの責務はEvidenceから必要な値（Values）の抽出のみに限定し、抽出された値をプログラム側で共通テンプレートへ組み立て、Validation・判定・保存までを一貫した共通処理で実行する構成へ変更しています。これにより、LLMの出力を最小限に抑えながら、Entity構造や保存処理の一貫性をコード側で保証できるようになりました。

この変更により、専門領域ごとの処理は共通Runtime上で動作できるようになり、Promptの小型化、品質の安定化、保守性・拡張性の向上を実現しました。専門領域を追加する際も、共通実行基盤を再利用しながら、専門領域の定義とPromptを中心に拡張できる構成を目指しています。

Knowledge Foundationは、単一AIへ多くの責務を集中させる構成から、LLMとプログラムの責務を明確に分離したアーキテクチャへ進化しました。LLMはEvidenceから必要な値（Values）の抽出に専念し、抽出された値を共通テンプレートへ組み立てる処理、検証、判定、保存は共通実行基盤が担うことで、LLMの確率的な出力に依存しにくい再現性の高いRuntimeを目指しています。これにより、本アーキテクチャはKnowledge OSの中核となる知識基盤として、継続的な機能追加や将来的な発展にも対応しやすい構成へ進化しました。