認知の形式化と中間表現

この章で扱う問い

本章で考えたいのは、「認知や学習についての知見を、どんな表現で書き下せば計算機にも教師にも扱えるものになるのか」という問いです。前章までで取り出した「つまずきの構造」——前提知識・誤概念・認知負荷——を、人間が読み返せて機械が処理できる形にしておかなければ、後続の章で扱う ITS や適応的支援は設計できません。本書の中盤に置かれているのはそのためです。認知モデルの形式化や、ドメイン知識をどう表現するかに関心がある読者には、本章の内容が他章を読む際の見取り図として効いてくると思います。あらかじめ言ってしまえば、形式化とは表現選択の問題であり、各表現は何かを得て何かを失います。本章はその語彙と、選択を統合する「中間表現」の設計原理を整理します。

形式化とは何か

形式化の本質

第1章で述べた通り、形式化は、本書を貫く三つのテーマの一つです。具体的には、暗黙的で曖昧な認知や知識を、明示的で厳密な形式で表現する作業を指します。これは単に「書き下す」こと以上の意味を持ちます。形式化されたものは四つの性質を獲得します。明示性——前提・仮定・概念間の関係が明示的に記述され、暗黙的な部分が最小化されます。厳密性——曖昧さが排除され、定義が厳密になります。構造性——要素間の関係が構造化されて表現されます。操作可能性——形式的記述に基づいて計算や推論が可能になります。

例として、「学習者はループを理解している」という曖昧な記述を考えてみましょう。形式化するなら、まず「理解」を構成要素に分解します（ループの構文を知っている、実行順序を説明できる、適切な状況で使える、典型的なバグを認識できる）。次に各要素の評価基準を定義します（構文知識なら欠落のない for 文を書ける、実行順序なら任意のループのトレースができる、など）。要素間の依存関係を明示し（構文を知らないとトレースはできない）、全体としての「理解度」を各要素のスコアからどう合成するかを定めます。形式化される前は教師の主観の中にしかなかった「理解」が、これにより計算機に判定させ、複数の教師間で議論できる対象になるわけです。

なぜ形式化が困難か

ただし、認知プロセスの形式化は物理現象の形式化とは異なる困難を抱えます。第一に 認知の複雑性 があります。人間の認知は多様で文脈依存的であり、単純な規則では捉えきれません。第二に 観察の間接性 ——認知プロセスは直接観察できず、行動や発話から推論するしかありません（前章で見た think-aloud や行動ログ分析が、この間接性に対する応答です）。第三に 個人差 ——同じタスクでも、学習者によって認知プロセスが異なります。第四に 動的変化 ——学習によって認知構造が変化し、静的なモデルでは不十分です。最後に 多重粒度 ——認知は秒単位の操作から年単位のスキル発達まで、異なる時間スケールと抽象度で理解できるため、適切な粒度の選択が難しいのです。

これらの困難にもかかわらず形式化を追求する理由は単純です。曖昧なままでは、一貫した診断も適応的な支援も不可能だからです。第1章で論じた通り、形式化は「教育研究を再現可能にする工学的処方箋」であり、認知的負荷をかけて書き下すコストを支払う代わりに、検証・批判・蓄積・自動推論という見返りが得られます。

認知構造の形式化

それでは、認知のどの側面を、どの表現で書き下すべきでしょうか。本節では、形式化の対象となる認知構造を概念知識・手続き的知識・因果知識の三系統に分け、それぞれに自然な表現と、その表現が「失うもの」を見ていきます。

概念知識の形式化：オントロジー、ただし手続きは表現できない

概念的知識（declarative knowledge）は、「〜とは何か」「〜は〜である」という形式の知識です。これを形式化するには、第4章で学んだオントロジーの手法が自然にフィットします。

概念の階層構造

下図は、プログラミング教育における概念の階層を形式化した例です。

graph TD
    Prog[プログラミング概念] --> CS[制御構造]
    Prog --> DS[データ構造]
    Prog --> Func[関数]

    CS --> Loop[ループ]
    CS --> Cond[条件分岐]

    Loop --> For[for文]
    Loop --> While[while文]
    Loop --> DoWhile[do-while文]

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

    Var --> VarDecl[変数宣言]
    Var --> VarAssign[変数代入]

    style Prog fill:#ff9,stroke:#333,stroke-width:3px
    style CS fill:#f9f
    style Loop fill:#9ff
    style For fill:#9f9

図 6-1: 概念の階層構造の形式化

この階層により、for 文 を学ぶには Variable・Condition の理解が前提であることが明示されます。Loop の一般的性質（反復、終了条件など）は、具体的なループ構文（for, while）に継承されます。学習者の理解状態を「Variable は理解しているが for 文 は未習得」と階層的に診断することもできます。第4章で示した OWL/Turtle 記法の ForLoop 定義はまさにこの階層を機械可読に書き下したものであり、推論エンジンは前提関係から「学習順序」を自動生成できます。

概念間の関係

ただし、is-a（包含関係）だけでは捉えきれない関係も多くあります。教育的に意味のある関係を列挙すると、prerequisite-of（A は B の前提）、part-of（A は B の構成要素）、contrasts-with（A と B は対比的概念、例：for と while、再帰と反復）、similar-to（A と B は類似概念、例：配列とリスト）、exemplifies（A は B の具体例）などがあります。

graph LR
    For[for文]
    While[while文]
    Array[配列]
    Var[変数]
    Rec[再帰]
    Iter[反復]

    For -.->|is-a| Loop[ループ]
    While -.->|is-a| Loop

    For -.->|prerequisite-of| NestedLoop[ネストループ]
    Array -.->|prerequisite-of| NestedLoop

    For -.->|contrasts-with| While
    Rec -.->|contrasts-with| Iter

    For -.->|part-of| Iter
    While -.->|part-of| Iter

    Var -.->|prerequisite-of| For
    Var -.->|prerequisite-of| While

    style Loop fill:#ff9
    style For fill:#f9f
    style While fill:#9ff

図 6-2: 概念間の多様な関係

contrasts-with 関係を形式化しておけば、システムは「for と while の違いは何か」という対比的説明を自動生成できます。exemplifies 関係があれば、抽象概念の説明後に具体例を提示するという教授戦略を、概念ごとにハードコードせずに実装できます。

ここで概念知識の形式化が 失うもの を明確にしておきましょう。オントロジーは「何があるか」を記述するのには優れていますが、「どうやって解くか」という手続きは表現に向きません。ForLoop のオントロジーが Variable を前提だと教えてくれても、「学習者がループを書けないとき、どの順序でステップを踏めば書けるようになるか」までは語らないのです。手続き的側面は、別の表現に委ねる必要があります。

手続き的知識の形式化：プロダクションルールとスキーマ

手続き的知識（procedural knowledge）は、「〜をどうやって行うか」という知識です。これを形式化する第一の選択肢が、Anderson の ACT-R 理論 [Anderson1993] における プロダクションルール です。ACT-R では、認知スキルは「ある条件が成立したらこの操作を行う」という多数の小さなルールの集合として表現されます。二次方程式を解くスキルは、たとえば次のようなルール集合となります。

Rule1:
IF goal is (solve ax^2 + bx + c = 0)
   AND a != 0
THEN apply quadratic formula
     x = (-b ± sqrt(b^2 - 4ac)) / (2a)

Rule2:
IF goal is (solve ax^2 + bx + c = 0)
   AND a = 0 AND b != 0
THEN transform to linear equation
     set goal (solve bx + c = 0)

Rule3:
IF goal is (solve bx + c = 0)
   AND b != 0
THEN x = -c / b

この形式化の真価は、学習者の解法プロセスを 適用されたルールの系列として解釈できる 点にあります。第8章で扱う モデルトレーシング では、学習者が打つ各ステップを、このルール集合のいずれの適用に対応するかを照合し、対応するルールがなければ「想定外の手順」として診断します。Cognitive Tutor の中核となった技術です。

より複雑なスキル——例：プログラムのデバッグ、エッセイの執筆、医療診断——は、個々のルールに分解しきれない階層的構造を持ちます。このようなスキルには 手続き的スキーマ（procedural schema）が用いられます。下図はデバッグスキルを階層的なスキーマとして表現した例です。

graph TD
    Debug[デバッグスキル] --> Reproduce[問題の再現]
    Debug --> Locate[バグ位置の特定]
    Debug --> Fix[修正]
    Debug --> Verify[検証]

    Locate --> Hypothesis[仮説生成]
    Locate --> Test[テスト実行]
    Locate --> Analyze[結果分析]

    Test --> Breakpoint[ブレークポイント設定]
    Test --> Print[print文挿入]
    Test --> Trace[トレース実行]

    Fix --> Understand[原因理解]
    Fix --> Modify[コード修正]

    Verify --> Retest[再テスト]
    Verify --> Regression[リグレッションテスト]

    style Debug fill:#ff9,stroke:#333,stroke-width:3px
    style Locate fill:#f9f
    style Fix fill:#9ff
    style Verify fill:#9f9

図 6-3: デバッグスキルの手続き的スキーマ

「バグを再現する」「原因を絞り込む」「修正する」「検証する」という上位ステップが、それぞれさらに詳細なサブ手続きに分解されます。第5章で扱った階層的タスク分析（HTA）と発想を共有しており、HTA の出力を直接スキーマとして書き下せる関係にあります。階層構造により、学習者がどのレベルでつまずいているか——「原因の絞り込み」全体ができないのか、その下位の「仮説生成」だけができないのか——を区別して診断できます。

ここでも 失うもの があります。プロダクションルールやスキーマは「どう動くか」は書けますが、「なぜそう動くべきか」という因果的・説明的根拠は表現に向きません。学習者に「なぜこの一手なのか」を説明する必要がある場面では、次に見る因果モデルに頼ることになります。

因果知識・説明モデルの形式化：因果ネットワーク

「何」「どうやって」だけでなく、「なぜ」という因果的・説明的知識も学習には不可欠です。物理学における「なぜボールは落ちるのか」への答えは、重力という因果メカニズムを呼び出します。プログラミングにおける「なぜこのプログラムは遅いのか」への答えは、ネストしたループの計算量という因果連鎖を呼び出します。こうした因果知識を形式化するには、因果ネットワーク（causal network）や qualitative reasoning の手法が用いられます。

下図は、プログラムのパフォーマンス問題に関する因果モデルを示したものです。

graph TB
    Slow[プログラムが遅い] --> Loop[ネストしたループ]
    Slow --> Mem[メモリ使用量大]
    Slow --> IO[頻繁なI/O]

    Loop --> Complexity[O_n²の計算量]
    Mem --> Redundant[冗長なデータ構造]
    IO --> FileAccess[ループ内でのファイルアクセス]

    Complexity -.->|解決策| HashTable[ハッシュテーブルの使用]
    Redundant -.->|解決策| Optimize[データ構造の最適化]
    FileAccess -.->|解決策| Batch[バッチ処理]

    style Slow fill:#f99,stroke:#333,stroke-width:3px
    style Loop fill:#fcc
    style Mem fill:#fcf
    style IO fill:#cff

図 6-4: パフォーマンス問題の因果モデル

このモデルにより、「実行時間が長い」という症状から、「ネストしたループ」「不必要な再計算」「不適切なデータ構造」といった原因候補を辿り、各原因を確認する診断質問を生成できます。修正の助言も、対応する因果リンクを示しながら「ネストしたループを線形に書き換えれば速くなる」と説明的に返せます。

因果モデルが 失うもの は、定量精度です。「ネストしたループは遅い」とは言えても、「具体的に何ミリ秒遅くなるか」までは因果ネットワークだけからは出ません。定量予測には、別途プロファイリングデータや計算量の数式モデルを組み合わせる必要があります。

三系統を統合する必要

オントロジー（概念）、プロダクションルール／スキーマ（手続き）、因果ネットワーク（因果）の三系統は、それぞれ異なる側面を捉え、それぞれ異なるものを失います。ある学習者が連立方程式でつまずいているとき、その診断には概念階層（前提概念の理解状況）、手続きルール（実行ステップの追跡）、因果モデル（なぜそのバグが起きたかの説明）のすべてが要ります。設計者の問題は、これらを どう束ねて単一の中間表現に収めるか です。次節で論じる中間表現の設計原理が、その束ね方の指針を与えてくれます。

中間表現の設計原理

形式化された認知構造を、どのような形で記述・保存・共有するか——これが 中間表現（intermediate representation, IR）の設計です。

三つの設計原理

第1章で述べたように、効果的な中間表現は三つの原理を同時に満たす必要があります。三つは独立ではなく、しばしばトレードオフ関係にあります。

計算可能性（Computability）

中間表現は、コンピュータが自動的に処理できる必要があります。具体的には、構文的明確性（XML や JSON 等の構造化データ形式、あるいは RDF/OWL 等のオントロジー言語で記述される）、意味的厳密性（各要素の意味が厳密に定義され、曖昧性がない）、推論可能性（表現に基づいて自動推論が可能、たとえば前提関係から学習順序を自動生成）、検証可能性（表現の整合性を自動的にチェックできる、たとえば循環的前提関係の検出）が含まれます。前節の ForLoop の OWL 定義は、この計算可能性を最大化した形式です。

可搬性（Portability）

中間表現は、特定のシステムや実装に依存せず、異なる環境で利用できる必要があります。具体的には、プラットフォーム独立性（特定の言語や OS に依存しない標準フォーマットを使う）、標準化された語彙（概念や関係を表す語彙はコミュニティで共有された標準に基づく）、バージョン管理（仕様が進化しても後方互換性が保たれる）、モジュール性（大きなドメインを小さなモジュールに分割でき、必要な部分だけ利用できる）が必要となります。研究の枠組みとしてエコシステムを目指す以上、可搬性は研究グループ間での知見の流通を可能にする生命線です。

解釈可能性（Interpretability）

中間表現は、専門家（教師、教授設計者、認知科学者）が理解・検証・修正できる必要があります。可読性（人間が読んで理解できる形式：テキストベース、図的表現）、視覚化（複雑な構造を図として視覚化するツールの存在）、ドキュメンテーション（各要素の意味と設計意図の文書化）、編集可能性（専門家が GUI ツールやテキストエディタで編集できる）が含まれます。ForLoop の OWL Turtle 表記は、計算機にも読める一方で、Turtle を学んだ教師なら直接読み書きできる——解釈可能性を意識した妥協点といえます。

下図は、これら三原理の関係を示したものです。

graph TD
    IR[中間表現] --> Comp[計算可能性]
    IR --> Port[可搬性]
    IR --> Interp[解釈可能性]

    Comp --> Comp1[構文的明確性<br/>意味的厳密性<br/>推論可能性]
    Port --> Port1[プラットフォーム独立<br/>標準化された語彙<br/>モジュール性]
    Interp --> Interp1[可読性<br/>視覚化<br/>編集可能性]

    Comp -.->|トレードオフ| Port
    Port -.->|トレードオフ| Interp
    Interp -.->|トレードオフ| Comp

    style IR fill:#ff9,stroke:#333,stroke-width:4px
    style Comp fill:#f99
    style Port fill:#9f9
    style Interp fill:#99f

図 6-5: 中間表現設計の三つの原理

三つの原理はしばしばトレードオフ関係に立ちます。計算可能性を最大化しようと一階述語論理で厳密に書き下すと、教師が読めなくなります（解釈可能性の犠牲）。解釈可能性を最大化しようと自然言語で書くと、機械が処理できません（計算可能性の犠牲）。可搬性を最大化しようとあらゆる標準語彙にマッピングすると、構築コストが膨らみます。設計とはこの三角の中で適切な妥協点を見つける作業なのです。

中間表現の具体例

それでは、実際にどのような中間表現が可能でしょうか。ForLoop を、二つの異なる形式で書き下し、それぞれが三原理のどこに重みを置いているかを見てみましょう。

XML/JSON ベースの表現：解釈可能性に寄せる

最も直接的なのは、XML や JSON で構造化データとして表現する方法です。

<Concept id="for-loop" domain="programming">
  <Name lang="en">For Loop</Name>
  <Name lang="ja">for文</Name>

  <Prerequisites>
    <Prerequisite id="variable" strength="strong"/>
    <Prerequisite id="iteration" strength="strong"/>
    <Prerequisite id="condition" strength="medium"/>
  </Prerequisites>

  <Components>
    <Component id="init" name="Initialization"/>
    <Component id="cond" name="Condition"/>
    <Component id="update" name="Update"/>
    <Component id="body" name="Loop Body"/>
  </Components>

  <Misconceptions>
    <Misconception id="off-by-one" frequency="high">
      <Description>
        Incorrect boundary condition (e.g., i &lt;= n vs i &lt; n)
      </Description>
      <DiagnosticPattern>
        Loop executes one more or one fewer iteration than intended
      </DiagnosticPattern>
    </Misconception>
  </Misconceptions>

  <LearningActivities>
    <Activity type="example" difficulty="easy">
      Write a loop to print numbers 1 to 10
    </Activity>
    <Activity type="debug" difficulty="medium">
      Fix off-by-one error in given code
    </Activity>
  </LearningActivities>
</Concept>

この XML は、計算可能性（XML パーサで処理可能）と解釈可能性（教師が見出しから内容を追える）の双方をある程度満たしますが、可搬性は限定的です。Prerequisite という要素名は独自定義であり、他のシステムが同じ意味で使っているとは限りません。前章の第4章で見た「ホテルの部屋」フレームの発想を XML 構文で展開したもの、と理解するとわかりやすいでしょう。

RDF/OWL ベースのオントロジー：計算可能性と可搬性に寄せる

より意味的に豊かで、可搬性も高い表現には、セマンティックウェブの標準技術である RDF [Klyne2004] と OWL [McGuinness2004] が使えます。

@prefix : <http://example.org/programming#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

:ForLoop rdf:type :ControlStructure ;
         rdfs:subClassOf :Loop ;
         :hasPrerequisite :Variable, :Iteration ;
         :hasComponent :Initialization, :Condition, :Update, :LoopBody ;
         :difficulty "medium" .

:WhileLoop rdf:type :ControlStructure ;
           rdfs:subClassOf :Loop ;
           :contrastsWith :ForLoop .

RDF/OWL の利点は、標準的な推論エンジンを利用でき、既存のオントロジー（教育メタデータ標準など）とリンクできる 点です。たとえば :hasPrerequisite 関係を IEEE LOM や IMS Learning Design の対応する関係にマッピングすれば、別の機関が作った教材オントロジーと自動的に接続できます。可搬性が大きく上がる代わりに、解釈可能性は XML/JSON より下がります——名前空間や URI のリテラシーを教師に求めるのは現実的でない場面も多いでしょう。

同じ ForLoop を二つの形式で書いたとき、どちらが「正しい」かではなく、用途に応じてどちらを選ぶかが問題です。研究室内で教師と密に協働する場面では XML/JSON、エコシステムとして広く流通させる場面では RDF/OWL、というのが標準的な使い分けとなります。

一つの実例：情報構造アプローチと中間表現の設計原理

中間表現の設計が具体的にどのように営まれてきたか、一つの実例として、平嶋らが提案する 情報構造アプローチ（Information Structure Approach）と、そこから派生してきた一連の枠組みを紹介します [Hirashima2015]; [Horiguchi2020]。情報構造アプローチは、学習課題を「学ぼうとしている対象（外的表現）の情報構造」として捉え、学習活動を「その情報構造への構造的操作」として再定義します。たとえば算数の文章題なら、文章を「物語の量・関係・問い」という情報構造に分解し、学習者にその構造を組み立てさせる作問活動を学習タスクとして設計します。この発想は Open Information Structure Approach (OISA) や Open Domain Model (ODM) として、より一般のドメインに拡張され、近年では学習者が外的表現を再構成しながら内的表現を組み替える Recomposition-Based Learning (RBL) [Hirashima2025] として理論化されつつあります。系譜としては、定性物理 [DeKleer1984] や、機能・振舞い・構造を分けて記述する FBS（Function-Behavior-Structure）形式 [Sasajima1996]; [Kitamura2004] など、オントロジー工学・定性推論で培われた表現論の流れに連なるものです。

僕 (古池) はこの系譜のなかで研究をしてきたので、ここから引いた一例として書いておきましょう。中間表現を設計する際、僕は 計算可能性・可搬性・認知的忠実性 の三つを設計原理として明示することを提案しています [Koike2026]。前二者は本節で論じた通りですが、三つ目の「認知的忠実性」は、表現が学習者・教師の認知にとって自然か、操作したときに直観に反しないか、という観点を指します。ここまで述べた解釈可能性をさらに学習科学側に寄せた言い方と思っていただければよいでしょう。これは、複数あり得る IR の articulate のしかたの一例であり、唯一の枠組みというわけではありません。他にも複数のアプローチがあります。本書16章でいくつか具体例を見ていきます。

形式化のプロセス

それでは、実際に認知構造を形式化するプロセスはどのようなものでしょうか。

トップダウンとボトムアップの往還

形式化には二つのアプローチがあります。トップダウンアプローチ では、理論（認知科学、教育学）から演繹的に構造を設計します。たとえば Bloom のタキソノミー [Bloom1956] に基づいて学習目標を「想起・理解・応用・分析・評価・創造」と階層化する、という具合です。利点は理論的根拠が明確で、一貫性が高いこと。欠点は、実際の学習データと乖離するリスクです。教科書的に正しくても、実際の学習者がどこで詰まるかを反映していないことがあります。

ボトムアップアプローチ では、実際の学習データ（学習者の応答、エラーパターン、行動ログ）から帰納的に構造を抽出します。BUGGY が引き算の誤答群から「Smaller-From-Larger」のような体系的バグを見出したのが典型例です。利点は実データに根ざしているため実用性が高いこと。欠点は、一般化や理論的解釈が困難な場合があり、ある学校で見つけたパターンが別の学校でも成り立つかが保証されない点にあります。

最も効果的なのは、両アプローチを往還させることです。理論に基づいて初期の構造を設計し、実データで検証・改善し、理論を精緻化する、というサイクルを回します。この往還そのものを設計プロセスの中心に据えるのが、第15章で扱う Design-Based Research の発想と整合します。

flowchart TD
    theory[理論的基盤<br/>認知科学・教育学の知見]
    topdown[トップダウンアプローチ<br/>演繹的に構造を設計]
    ir[中間表現の構築<br/>形式化・検証]
    bottomup[ボトムアップアプローチ<br/>実データから帰納的に抽出]
    data[学習データ<br/>応答・エラーパターン]
    refine[検証・改善・理論精緻化]

    theory --> topdown
    topdown --> ir
    ir --> bottomup
    bottomup --> data
    data --> refine
    refine -- 反復的改善 --> theory

図 6-7: 形式化のプロセス：理論と実践の往還

具体的なステップ

実務として認知構造を形式化する典型的なステップは以下の通りです。

領域分析：対象ドメインの範囲を定め、重要な概念・スキルをリストアップ
文献調査：認知科学・教育学の先行研究を調査し、理論的基盤を確認
専門家インタビュー：ドメイン専門家や熟達教師から知識を引き出す（第5章の CTA を活用）
学習者分析：実際の学習者の理解状態、つまずきパターンを観察・分析（第5章のプロトコル分析・エラー分析を活用）
階層構造の設計：概念間の is-a, prerequisite などの関係を定義
手続き的知識の抽出：問題解決の手順、スキルをプロダクションルール等で表現
誤りモデルの構築：典型的誤りとその原因を体系化
形式的記述：中間表現の形式（XML, OWL, JSON-LD など）で記述
検証と評価：専門家レビュー、実データでの検証
反復的改善：フィードバックに基づいて継続的に改善

このプロセスは、第4章で紹介した Studer らのオントロジー工学方法論 [Studer1998] を、認知プロセスまで含むよう拡張したものと位置づけられます。

形式化の課題と展望

現在の課題

認知の形式化と中間表現には、まだ多くの未解決問題があります。

第一に 形式化のコスト です。高品質な中間表現の構築には、専門家の多大な時間と労力が必要です。Cognitive Tutor の代数モデルが百人時を超える専門家投入を要したことは知られており、この投入コストが「形式化された ITS が稀少な存在に留まる」最大の理由です。自動化や半自動化の手法が求められています。

第二に 表現の限界 です。人間の認知のすべてを形式的に捉えることは原理的に不可能です。直感、創造性、文脈依存的な理解、暗黙の身体性など、形式化に馴染まない側面をどう扱うか、あるいはどこで形式化を諦めるかは、未解決の哲学的問題でもあります。

第三に 標準化の欠如 です。コミュニティレベルで合意された標準的な中間表現がまだ確立されていません。各研究グループが独自の表現を使っており、相互運用性が低いのが現状です。さまざまな提案が並立する状態にあり、収束には時間がかかります。

第四に 評価の困難 です。形式化の「良さ」をどう評価するか、明確な基準がありません。網羅性（重要な概念を漏らしていないか）、精度（学習者の状態を正しく診断できるか）、有用性（その診断が教育的介入に役立つか）などの多面的評価が必要であり、単一の指標では捉えきれません。

AI による形式化支援の可能性

近年の自然言語処理や機械学習の進展は、形式化プロセスを支援する新たな可能性を開いています。大規模言語モデル（LLM）の活用 により、教科書や論文から概念を抽出し、概念間関係を提案し、初期オントロジーを自動生成する試みが進んでいます。もちろん LLM の出力にはハルシネーションが含まれうるため、専門家による検証が不可欠です。学習データからの知識発見 では、大量の学習者ログから、よくあるエラーパターンや概念間の学習依存関係を統計的に抽出します。半自動形式化 では、人間の専門家と AI が協働し、AI が初期案を生成し、専門家がレビュー・修正することで、効率と質を両立させます。

これらの技術は、形式化のコストを下げ、教育 AI 研究のエコシステムの成長を加速する可能性を持ちます。第1章で論じた「データ駆動と理論駆動の統合」が、まさに形式化支援という具体的な接点で実装されつつあります。

まとめ

本章は「形式化は表現選択の問題であり、各表現は何かを得て何かを失う」という主張を貫いてきました。概念知識にはオントロジーが、手続き的知識にはプロダクションルールやスキーマが、因果知識には因果ネットワークが、それぞれ自然な表現としてフィットします。しかし各表現は、捉える側面と引き換えに、別の側面を失います。中間表現の設計とは、これら異なる表現を統合し、計算可能性・可搬性・解釈可能性という三つの原理の間でトレードオフを取りながら束ねていく作業です。情報構造アプローチや FBS のような系譜は、その束ね方の一つの実例を提供してくれます。

次章への橋渡し

形式化された認知構造はそれ自体が目的ではなく、学習者の前にどんな課題・活動を置くかという設計に橋渡しされて初めて意味を持ちます。次章では、その「学習活動の設計」を、認知負荷理論と望ましい困難の二つの軸から考えていきます。

さらに学ぶために

Anderson, J. R., & Lebiere, C. (1998). The Atomic Components of Thought. Lawrence Erlbaum Associates.（ACT-R による認知の形式化）
Studer, R., et al. (1998). Knowledge engineering: Principles and methods.（知識工学の方法論）
Mizoguchi, R., & Bourdeau, J. (2000). Using ontological engineering to overcome common AI-ED problems. International Journal of Artificial Intelligence in Education.

古池謙人流『教育AIの見取り図』