知識とその表現 ―知識工学の基礎―

この章で扱う問い

ここで議論する「どのような形で知識を書き下すか」というテーマは、本書 6 章（中間表現）のテーマでもあります。本章はその前段として、知識工学が積み上げてきた表現形式の語彙を、まずは古典に立ち戻って整理する章です。本章の主張は、次の一文に要約できます。知識を計算機で扱うには「どんな形で書き下すか」という選択が決定的に重要であり、各表現形式は固有の得手不得手を持つ。 認知学習工学が中心に据える「認知の形式化」は、本質的には「認知を知識として表現する」作業であり、そのための語彙を提供してきたのが知識工学です。

．

知識工学の誕生：エキスパートシステムの挑戦

1970 年代、人工知能研究は新しい局面を迎えていました。それまでの汎用問題解決プログラム（Newell と Simon の General Problem Solver、GPS [Newell1972] が代表）は、ハノイの塔のような閉じた問題は解けても、医療診断や化学分析といった実世界の複雑な問題には太刀打ちできませんでした。GPS は推論手法として強力でも、解くべき領域の知識をほとんど持っていなかったからです。

この状況を変えたのが、Edward Feigenbaum を中心とするスタンフォードのグループが推進した エキスパートシステム（expert systems）の路線です。Feigenbaum [Feigenbaum1977] は「知識工学」という言葉を初めて公的に用い、専門家の知識をコンピュータに移植する方法論の必要性を訴えました。彼の標語はあまりにも有名です――「AI の力の源泉は、賢い推論手法ではなく、豊富な専門知識である」。この標語は、単に技術的な転換を意味するだけでなく、AI 研究の問題設定そのものを「いかに賢く推論するか」から「いかに知識を書き下すか」へと再定義しました。以下に見る MYCIN と DENDRAL は、その新しい問題設定への、最初の説得力ある応答です。

MYCIN：医療診断の先駆者

1970 年代半ば、Bruce Buchanan と Edward Shortliffe らがスタンフォード大学医学部で開発した MYCIN [Buchanan1984] は、エキスパートシステムの古典的な成功例です。MYCIN が対象としたのは血液感染症の診断と抗生物質の推奨で、ベテランの感染症専門医の知識を IF-THEN 形式の プロダクションルール [Newell1972] として書き下しました。最終的にルール数は約 600 に達し、確信度（certainty factor）と呼ばれる数値で各推論の不確実性を扱いました。

MYCIN のルールは具体的にはこのような形をしていました。

IF 患者の感染部位が血液であり AND グラム染色の結果が陰性であり AND 形態が桿菌である THEN 病原体は E. coli である（確信度 0.8）

医師がデータを入力していくと、MYCIN は適合するルールを連鎖的に発火させ、最終的に病原体候補と推奨抗生物質のリストを返します。決定的に重要だったのは、MYCIN が 「なぜそう推論したのか」を説明できる ことでした。医師が「なぜ E. coli と判断したのか」と尋ねれば、MYCIN は適用したルール群を逆向きにたどって示します。Yu らが 1979 年に JAMA で報告した評価実験では、MYCIN の診断精度がスタンフォードの感染症専門医パネルと統計的に有意な差がない範囲にあり、非専門医より明確に優れていることが示されました。法的責任や運用上の問題から MYCIN 自身は実臨床には至りませんでしたが、知識ベースシステムが現実的な専門家性能に到達しうることを実証し、知識工学という分野の基礎を築いたといえます。

DENDRAL：科学的発見の自動化

同じくスタンフォードで Buchanan、Feigenbaum、Lederberg らが開発した DENDRAL [Lindsay1980] は、別種の挑戦でした。質量分析装置から得られるスペクトルデータをもとに、未知の有機化合物の分子構造を推定する。DENDRAL の興味深さは、単に既知の知識を適用するだけでなく、可能な構造仮説を体系的に生成し、それを質量分析の予測パターンと照合して絞り込むという、仮説生成 を含む推論を行った点にあります。Lederberg はこれを「科学的発見の自動化」と呼びました。エキスパートシステムが知識の再利用だけでなく、創造的な問題解決にも貢献できることを示した最初の実例です。

MYCIN と DENDRAL は、知識を IF-THEN ルールという特定の形式に書き下すという同じアプローチを採りましたが、そのアプローチの限界もすぐに浮き彫りになります。ルールは独立した単位として扱いやすい反面、ルール間の整合性、概念の階層性、典型的な状況の構造――これらをルールだけで表現するのは無理がありました。次節では、こうした限界を補うために生まれた多様な知識表現形式を見ていきます。

知識をどう表現するか

エキスパートシステムの発展とともに、様々な 知識表現（knowledge representation）の手法が開発されました。それぞれの手法は、異なる種類の知識を表現するのに適しています。本節では、ルール、意味ネットワーク、フレームの三系統を、それぞれ動く小さな例とともに見ていきます。

プロダクションルール：条件付き知識

プロダクションルールは IF（条件）-THEN（結論）という形式で知識を表現します。MYCIN の例で見たように、各ルールは独立した単位として追加・修正・削除でき、適用過程を逆向きにたどって説明することも容易です。診断や分類のように「条件が揃えばこの結論」という性質の知識には極めて自然にフィットします。

プログラミング学習者のバグ診断を考えてみてください。学習者が書いた for (i = 0; i <= n; i++) というループが配列の末尾を 1 つ超えて参照してエラーを起こした、という状況を診断するルールは次のように書けます。

Rule_OffByOne_1:
IF ループ終了条件が `i <= n` であり
   AND ループ内で配列 `arr[i]` を参照しており
   AND `n` が `arr.length` または `arr.length - 1` を表す変数である
THEN 診断 = off-by-one error（境界条件の誤り）
   AND 修正案 = 終了条件を `i < n` に変更
   AND 確信度 = 0.85

Rule_OffByOne_2:
IF ループ終了条件が `i < n` であり
   AND ループ内で配列 `arr[i]` を参照しておらず
   AND `arr[i-1]` のような添字操作をしている
THEN 診断 = off-by-one error の可能性
   AND 確信度 = 0.6

このような診断ルール集合は、学習者の出した複数のバグを一貫した「典型的誤りカタログ」として扱えるようにします。第5章で扱う BUGGY 流の体系的バグの考え方とも自然に接続します。プロダクションルールの強みはこの明快さと説明可能性にあります。ただし、ルール数が数千を超えると相互作用や矛盾の管理が極端に困難になり、また「典型的なホテルの部屋とはどんなものか」のような構造化された知識は、こうした条件 → 結論の形には収まりにくいのです。

graph TD
    subgraph "プロダクションルール例"
        R1["Rule 1:<br/>IF プログラムが無限ループする<br/>AND ループ条件が常にtrue<br/>THEN バグ: ループ終了条件の誤り"]
        R2["Rule 2:<br/>IF 配列アクセスエラーが発生<br/>AND ループ変数が配列サイズを超える<br/>THEN バグ: off-by-one エラー"]
        R3["Rule 3:<br/>IF 期待した出力が得られない<br/>AND 変数が初期化されていない<br/>THEN バグ: 変数の初期化漏れ"]
    end

    style R1 fill:#ffe1e1
    style R2 fill:#e1f5ff
    style R3 fill:#e1ffe1

図4-1: プロダクションルールの例：プログラミングバグ診断

意味ネットワーク：概念の関係構造

ルールが「条件→結論」の知識を扱うのに対し、概念どうしの関係そのものを扱うのが 意味ネットワーク（semantic network）[Collins1969] です。Collins と Quillian が 1969 年に提案したこの形式は、概念をノード、概念間の関係をリンクとして表します。人間の長期記憶における概念組織の心理学的モデルとしても、また計算機上の知識表現としても、長く用いられてきました。

最も有名な例は生物の階層です。テキストで書き下すと次のようになります。

動物 ──is-a─→ 生き物
鳥 ──is-a─→ 動物
カナリア ──is-a─→ 鳥

動物 ──has─→ 移動能力
鳥 ──has─→ 翼、飛行能力
カナリア ──has─→ 黄色い羽

この表現の妙味は 継承（inheritance）にあります。「カナリアは飛ぶか」と問われたとき、システムはカナリアのノードを直接調べ、なければ親ノード（鳥）に登り、そこに「飛行能力」を見つければ「飛ぶ」と答える――というふうに動きます。一段一段の検索時間が伸びるはずだという Collins と Quillian の予測は、人間の意味検索実験でも一定程度確認され、認知モデルとしての説得力も得ました。

しかし継承は素朴に運用すると破綻します。「ペンギンは鳥である」が「ペンギンは飛ばない」――この例外をどう扱うかが、意味ネットワークの古典的難問です。ペンギンノードに「飛ばない」属性を直接書き込んで上書きするしかないのですが、上書きの優先順位を厳密に定義しようとすると、表現の「直感的さ」という長所自体が失われていきます。意味ネットワークが概念の階層的な可視化には今も有用である一方、形式的な推論基盤としては後の OWL のようなより厳密な枠組みに置き換えられていった理由は、ここにあります。

graph TD
    カナリア -->|is-a| 鳥
    ペンギン -->|is-a| 鳥
    鳥 -->|is-a| 動物
    動物 -->|is-a| 生き物

    鳥 -.->|has-property| 飛ぶ
    カナリア -.->|has-property| 黄色い
    ペンギン -.->|has-property| 飛ばない_例外

    動物 -.->|has-property| 動く
    生き物 -.->|has-property| 代謝する

    style 生き物 fill:#ff9
    style 動物 fill:#f9f
    style 鳥 fill:#9ff
    style カナリア fill:#9f9
    style ペンギン fill:#f99

図4-2: 意味ネットワークの例：生物の階層

フレーム：構造化された知識単位

ルールが断片的、意味ネットワークがリンクの集合とすれば、Marvin Minsky が 1975 年に提案した フレーム（frame）[Minsky1975] は、ある概念や状況についての 典型的な知識を一つのまとまり として構造化するアプローチです。フレームは複数のスロット（属性）と、各スロットが取りうる値の型・デフォルト値・制約を持ちます。「ホテルの部屋」フレームは典型的に次のような形をしています。

表4-1: フレームの例：ホテルの部屋

フレームの強みは、「ホテルの部屋」と聞いた瞬間に人間が想起する典型的な期待――ベッドが普通は 1 つ、浴室があるのが通常――を、デフォルト値という形でそのまま表現できる点にあります。新しい部屋情報が入ってくると、明示されていないスロットは自動的にデフォルトで埋められ、想定と異なる情報があれば例外として目立つようになります。この「典型からのズレに敏感」という性質は、第2章で見たスキーマ理論の発想と非常に近いものです。Minsky 自身もフレームを認知の単位として位置づけていました。

フレームはオブジェクト指向プログラミングのクラスと概念的に近いものです。実際、Smalltalk や CLOS のクラス階層は、AI 研究におけるフレームの考え方から強い影響を受けています。フレームは典型的状況の表現には強いのですが、動的に変化する手続き的知識や、ルールのような条件付き推論を直接表現するのには向きません。

異なる表現手法の比較

ここまでに見た三つの形式と、次節で扱うオントロジーは、それぞれ異なる種類の知識に適しています。表 4-2 は要点を整理したものです。

表4-2: 知識表現手法の特徴比較

実際のシステム開発では、これらの手法を組み合わせて使うことが多いものです。たとえばオントロジーでドメインの概念構造を定義し、プロダクションルールで診断推論を実装し、フレームで典型的な問題状況を表現する、という重ね合わせが典型的です。下図はこれら手法の関係を視覚的に整理したものです。

graph LR
    subgraph "表現手法の比較"
        A[プロダクションルール]
        B[意味ネットワーク]
        C[フレーム]
    end

    A -->|長所| A1[明快な条件-結論<br/>説明可能性高い<br/>モジュール性]
    A -->|短所| A2[大規模化で管理困難<br/>関係性の表現が苦手]

    B -->|長所| B1[概念間の関係明示<br/>継承メカニズム<br/>視覚的理解]
    B -->|短所| B2[例外処理が困難<br/>推論効率が悪い]

    C -->|長所| C1[構造化された知識<br/>デフォルト値<br/>オブジェクト指向的]
    C -->|短所| C2[柔軟性に欠ける<br/>複雑な推論が困難]

    style A fill:#ffe1e1
    style B fill:#e1f5ff
    style C fill:#e1ffe1
    style A1 fill:#fff0f0
    style A2 fill:#ffe8e8
    style B1 fill:#f0f8ff
    style B2 fill:#e8f4ff
    style C1 fill:#f0fff0
    style C2 fill:#e8ffe8

図4-3: 知識表現手法の視覚的比較

これら三系統の表現形式が確立した後、1990 年代に新しい段階が来ます。それが、概念体系そのものを共有可能な資産として扱う オントロジー の発想です。三本の道具の上に、もう一つ別の階を重ねるイメージで読んでみてください。

オントロジー：知識の体系的構造化

オントロジーとは何か

Thomas Gruber [Gruber1993] は、オントロジーを 「概念化の明示的な仕様」（explicit specification of a conceptualization）と定義しました。やや抽象的に響きますが、噛み砕けば、ある領域における概念・性質・関係を、誰が読んでも同じ意味に解釈できる形で書き下したもの、ということです。

オントロジーが単なる知識ベースと異なる点は三つあります。第一に、オントロジーは個別の事実（「太郎の身長は 170cm」）ではなく、領域の 構造（「人間は生物の一種であり、身長という属性を持つ」）を扱います。第二に、オントロジーは複数のシステムや人間の間で 共有 され、共通の理解基盤を提供します。第三に、オントロジーは機械可読な形式（OWL など）で記述され、推論エンジンによる自動推論が可能です。

たとえば学習支援の領域で、「for 文」概念のオントロジーを OWL の Turtle 記法で書き下すと次のような形になります。

@prefix : <http://example.org/programming#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .

:ControlStructure rdf:type owl:Class .
:Loop rdfs:subClassOf :ControlStructure .
:ForLoop rdfs:subClassOf :Loop ;
         :hasPrerequisite :Variable, :Iteration ;
         :hasComponent :Initialization, :Condition, :Update, :Body .
:WhileLoop rdfs:subClassOf :Loop ;
           :contrastsWith :ForLoop .

:Variable rdf:type owl:Class .
:Iteration rdf:type owl:Class .

この記述から推論エンジンは、たとえば「ForLoop を学ぶには Variable と Iteration の理解が必要」「ForLoop と WhileLoop は対比的に説明できる」といったメタ知識を自動で導けます。手書きで書けばわずか数行のこの定義が、教師・学習者・システム間で共有される共通語彙となる――これがオントロジーの最大の意義です。

オントロジーの構成要素

オントロジーは典型的に、以下の要素から構成されます（下図参照）。

• クラス（Classes）：概念のカテゴリ。例：「人間」「動物」「学習活動」
• 個体（Individuals）：クラスの具体的インスタンス。例：「太郎」「ポチ」
• 属性（Properties）：クラスや個体が持つ特性。例：「年齢」「体重」「難易度」
• 関係（Relations）：概念間の意味的関係。例：「is-a」（〜は〜の一種）、「part-of」（〜は〜の部分）、「prerequisite-of」（〜は〜の前提）
• 公理（Axioms）：概念に関する論理的制約や規則。例：「人間の年齢は 0 以上の整数」

graph TB
    O[オントロジー] --> C[クラス]
    O --> I[個体]
    O --> P[属性]
    O --> R[関係]
    O --> A[公理]

    C --> C1[人間<br/>動物<br/>学習活動]
    I --> I1[太郎<br/>花子<br/>課題A]
    P --> P1[年齢<br/>体重<br/>難易度]
    R --> R1[is-a<br/>part-of<br/>prerequisite-of]
    A --> A1["年齢≥0<br/>体重>0<br/>難易度: 低/中/高"]

    style O fill:#ff9,stroke:#333,stroke-width:3px
    style C fill:#ffe1e1
    style I fill:#e1f5ff
    style P fill:#e1ffe1
    style R fill:#fff4e1
    style A fill:#f0e1ff

図4-4: オントロジーの構成要素

これらの要素を組み合わせることで、ある領域の知識を「概念とそのつながり」として網羅的に書き下せます。

オントロジーの階層

Guarino [Guarino2009] は、オントロジーを抽象度に応じて四層に整理しています（下図参照）。最も抽象的な層から具体的な層へと並べると、次のようになります。

最上層の トップレベルオントロジー（Top-level ontology）は、時間・空間・物質・イベント・性質など、あらゆる領域に共通する最も基本的な概念を定義します。CYC [Lenat1995] や SUMO [Niles2001] が代表例で、何十年もかけて常識的概念を網羅しようとする巨大プロジェクトです。

その下に ドメインオントロジー（Domain ontology）が位置します。医療、生物学、教育といった特定の領域に特化した概念を定義するもので、学習支援の文脈では、数学・物理・プログラミングなどの教科領域ごとにドメインオントロジーを構築することになります。先ほどの ForLoop の定義は、プログラミングのドメインオントロジーの一断片です。

さらに タスクオントロジー（Task ontology）が、診断・設計・教授といった特定のタスクに関連する概念を定義します。学習支援に引きつければ、「問題解決」「概念理解」「スキル習得」といったタスクのオントロジーが重要になります。

最も具体的な アプリケーションオントロジー（Application ontology）は、特定のアプリケーションのために、ドメインオントロジーとタスクオントロジーを統合・特殊化したものです。「中学2年生向け連立方程式 ITS」のためのオントロジーは、数学のドメインと「問題解決指導」のタスクを組み合わせて構成されます。

graph TD
    A[トップレベル<br/>オントロジー] --> B[ドメイン<br/>オントロジー]
    A --> C[タスク<br/>オントロジー]
    B --> D[アプリケーション<br/>オントロジー]
    C --> D

    A1[時間・空間・物質<br/>イベント・性質] -.-> A
    B1[医療・生物学<br/>教育・工学] -.-> B
    C1[診断・設計<br/>教授・学習] -.-> C
    D1[数学ITS<br/>プログラミング学習<br/>医療診断システム] -.-> D

    style A fill:#ff9,stroke:#333,stroke-width:2px
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style C fill:#9ff,stroke:#333,stroke-width:2px
    style D fill:#9f9,stroke:#333,stroke-width:2px

図4-5: オントロジーの階層

この階層構造によって、上位層を共有しつつ下位層を独自に拡張するという、ソフトウェア工学のレイヤ設計と類似した知識の組み立て方が可能になります。

オントロジー工学の方法論

オントロジーを構築するプロセスは、ソフトウェア工学に類似しています。Studer ら [Studer1998] はオントロジー工学の方法論を体系化し、典型的な工程を以下のように整理しました。最初に 目的の明確化 を行います。何のためのオントロジーか、誰が使うのか、どの範囲をカバーするのかを明確にする。これが曖昧なまま進めると、後で「網羅的に作ったが誰にも使われない」という事態を招きます。次に 概念の同定 として、領域の重要な概念を専門家へのインタビュー、文献調査、既存オントロジーの参照を通じて列挙します。続いて 階層化 で概念間の is-a 関係を定義し、属性と関係の定義 で各概念が持つ属性と概念間の関係を明示する。さらに 制約の記述 として公理や制約条件を論理式で書き下し、最後に 評価と改善 を、専門家レビュー・実データでの検証・継続的改良として繰り返します。

このプロセスは MYCIN のルール書き下しに比べて遥かにコストが高いものですが、得られる成果はそれだけ再利用可能性が高いものになります。本書が随所で言及するエコシステム形成も、こうした共有可能なオントロジー資産の積み重ねに依存します。先に概念の見取り図を粗描きしてから道具に手を伸ばす、という順序を意識しておくと、結局は早く動くオントロジーに辿り着くと言われています。

中間表現としての知識構造

ここまで見てきた知識表現の語彙は、認知学習工学の文脈ではどう使われるのでしょうか。本節ではその接続を、ドメイン知識・認知プロセス・粒度・標準化の四つの観点から見ていきます。第6章で扱う「中間表現」の議論への助走、と思って読んでみてください。

ドメイン知識の形式化

学習支援システムが効果的であるためには、まず教える内容――ドメイン知識――を形式的に表現する必要があります。プログラミング教育における「ループ」概念は、先に示した ForLoop のオントロジー定義のように形式化されます。下図はこれをより視覚的に表現したものです。

graph LR
    Loop[ループ概念] --> For[for文]
    Loop --> While[while文]
    Loop --> DoWhile[do-while文]

    For --> Init[初期化]
    For --> Cond[条件式]
    For --> Update[更新式]
    For --> Body[ループ本体]

    For -.->|前提概念| Var[変数]
    For -.->|前提概念| Iter[イテレーション]
    For -.->|前提概念| CondExpr[条件式]

    For -.->|典型的誤り| Err1[off-by-one]
    For -.->|典型的誤り| Err2[無限ループ]
    For -.->|典型的誤り| Err3[初期化忘れ]

    style Loop fill:#ff9,stroke:#333,stroke-width:3px
    style For fill:#ffe1e1
    style While fill:#e1f5ff
    style DoWhile fill:#e1ffe1

図4-6: プログラミング概念「ループ」のオントロジー例

このような形式化があると、「学習者が for 文を理解するには Variable・Iteration・Condition の理解が前提である」という依存関係が明示され、学習者がどの前提でつまずいているかを診断できます。for と while の構造的な共通点と相違点も :Loop の下位クラスとして自然に表現できますし、off-by-one のような典型的誤りもオントロジーに紐付けて体系的にカタログ化できます。要するに、ドメインオントロジーは個別の問題群を貫く「教えるべき構造」の地図になるわけです。

認知プロセスの形式化

ドメイン知識だけでは半分にすぎません。学習者がそのドメインで実際に何をするのか――問題を読み、計画を立て、実行し、検証するという 認知プロセス そのものも形式化する必要があります。「問題解決」プロセスは、たとえば次のような階層的フレームとして書き下せます。

graph TD
    Start[問題に直面] --> Understand[問題理解]
    Understand --> Plan[解決計画]
    Plan --> Execute[実行]
    Execute --> Evaluate[評価]
    Evaluate --> |成功| End[完了]
    Evaluate --> |失敗| Diagnose[診断]
    Diagnose --> Plan

    Understand -.->|つまずき| U1[問題文の誤読<br/>前提知識の欠如]
    Plan -.->|つまずき| P1[方略選択の誤り<br/>サブゴール設定の失敗]
    Execute -.->|つまずき| E1[手続き的誤り<br/>計算ミス]
    Evaluate -.->|つまずき| EV1[評価基準の不明確さ<br/>部分解の見落とし]

    style Start fill:#e1f5ff
    style End fill:#e1ffe1
    style Understand fill:#fff4e1
    style Plan fill:#f0e1ff
    style Execute fill:#ffe1f5
    style Evaluate fill:#ffe1e1
    style Diagnose fill:#f0f0f0

図4-7: 問題解決プロセスの形式化

このような形式化があると、学習者がプロセスのどこでつまずいているか――問題理解か、計画立案か、実行か、検証か――を区別して診断し、それに応じた支援を提供できます。次の第5章で扱う認知タスク分析は、まさにこの形式化に必要な観察データを得るための方法論です。

知識の粒度と階層化

知識を形式化する際、粒度（granularity）の選択が決定的です。粗すぎる粒度――たとえば「プログラミングができる」――では診断も支援も粗くなります。逆に細かすぎる粒度――「変数名の最初の文字を小文字にできる」――では管理が煩雑になり、知識ベースの保守自体が破綻してしまいます。

適切な粒度は目的と文脈に依存します。初学者向けシステムでは粗い粒度（「ループの基本概念」）、上級者向けシステムでは細かい粒度（「ジェネレータと反復子の違い」）が適することが多いものです。重要なのは、異なる粒度のレベルを 階層的に構造化し、必要に応じて詳細化・抽象化 できるようにすることです（下図）。オントロジーの is-a 階層と part-of 関係は、まさにこの可変粒度を支える基盤になります。

graph TD
    L1[粗い粒度:<br/>プログラミング能力] --> L2[中程度:<br/>制御構造の理解]
    L2 --> L3[細かい:<br/>for文の理解]
    L3 --> L4[非常に細かい:<br/>for文の初期化部の理解]

    L1 -.->|適用| U1[コース全体の評価]
    L2 -.->|適用| U2[章レベルの診断]
    L3 -.->|適用| U3[概念レベルの支援]
    L4 -.->|適用| U4[詳細なエラー診断]

    style L1 fill:#ff9
    style L2 fill:#f9f
    style L3 fill:#9ff
    style L4 fill:#9f9

図4-8: 知識の粒度と階層化

標準化と相互運用性

知識表現を一つの研究室の中だけで使うのでなく、研究コミュニティ全体の資産として育てるには、標準化 が不可欠です。異なる研究グループや開発チームが構築したオントロジーやドメインモデルを相互に利用できれば、知見の蓄積と再利用が一気に加速します。

W3C が策定した OWL（Web Ontology Language）[McGuinness2004] は、オントロジー記述の事実上の国際標準です。教育分野では IEEE LOM や IMS Learning Design といった学習リソース記述標準も存在します。本書全体としては、こうした既存標準を活用しつつ、認知構造の形式化に特化した語彙をどう揃えていくかを主要な問題として掲げています。第6章で扱う「中間表現」の議論は、この標準化問題に正面から取り組みます。

まとめ

本章は「知識を計算機で扱うには表現形式の選択が決定的であり、各形式は固有の得手不得手を持つ」という主張を貫いてきました。MYCIN と DENDRAL が示したのは、専門知識を IF-THEN ルールとして書き下せばエキスパート性能に到達しうるという可能性です。プロダクションルール・意味ネットワーク・フレームという三系統の表現形式は、それぞれ条件付き推論・概念関係・典型的状況に強みを持ち、互いに補完し合います。1990 年代以降のオントロジー工学は、これら個別形式を統合する共有可能な概念体系の構築方法論として発展してきました。

これらの語彙は、認知学習工学の文脈ではドメイン知識と認知プロセスの双方を形式化し、学習者の状態を診断し、適切な支援を選択するための基盤になります。

次章への橋渡し

ここまでで、知識を「どう書き下すか」の語彙は揃いました。しかし、実際に書き下すべき認知プロセスそのものは、外から直接見えるものではありません。学習者が何を考え、どこでつまずき、どんな誤解を抱えているか――これらをまず観察可能な対象に変える方法論がなければ、形式化のしようがないのです。

次章からは、こうした知識表現の語彙を実際に使って、認知プロセスをどう分析し、どう形式化し、どう学習環境として実装するかという方法論に踏み込みます。まず第5章では、形式化以前の段階として、認知プロセスをそもそもどう観察するか――認知タスク分析、プロトコル分析、エラー分析――を扱いましょう。

さらに学ぶために

• Studer, R., Benjamins, V. R., & Fensel, D. (1998). Knowledge engineering: Principles and methods. Data & Knowledge Engineering, 25(1-2), 161-197.
• Guarino, N., Oberle, D., & Staab, S. (2009). What is an ontology? In S. Staab & R. Studer (Eds.), Handbook on Ontologies (pp. 1-17). Springer.
• Noy, N. F., & McGuinness, D. L. (2001). Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory.（オンラインで入手可能）