構造思考の人間（structural thinker）は、あらゆる事象の構造化を試みる。Markdownだったり、表形式だったり、プログラミング表現だったり。しかし残念ながら、人間の思考や言語表現は完全にモデリングすることは不可能である。それで私のような重度の構造思考者はモヤることがしばしばだ。本稿では言語学や計算機科学の知見を借りてモヤの原因を解明しつつ、可能な限り人間の思考や自然言語表現を構造化することを試みる。
構造（structure） vs 文脈（context）
人間は文章を読むとき、書かれたことだけを読み取るのではなく、書かれてないことまで自然に読み取ったり類推したりする能力がある。人間が読み取る書かれていない内容を文脈（context）という。ちなみに、構造思考の対比として文脈を読みとることに長けている文脈思考の人間（contextual thinker）も一定数いるらしい。
構造（Structure）
- 明示情報
- プログラムに近い
- 再現性が高い
- 誰が読んでも同じ意味になることを目指す
文脈（Context）
- 暗黙情報
- 推論に依存
- 再現性が低い
- 読み手によって意味が変わる
- 構造思考者のモヤモヤの源
Contextの分類
重要なContextは以下の4つ：
- Frame（評価環境）
動詞や名詞が前提として要求する「役割セット」。
buy の Frame には buyer / seller / goods / money が含まれる - Presuppoisiton（前提）
自動的に共有されていることになっている前提
John stopped smoking. から John used to smoke. が前提知識として読み取れる。
文を否定しても前提は生きる。
John didn't stop smoking. でも John used to smoke. といえる - Discourse relations（談話接続）
文と文を繋ぐ暗黙に読み取れる接続関係。命題の仕組みを説明した後、本稿の後半で詳述する - Implicature（推論結果）
言語化されていないが、受け手が（協調原理で）自動的に推測する内容
Some of the students passed. から The others failed. が読み取れる
しかし、それは必ずしも正しいとは限らない。
Some of the students passed, but actually all of them passed. な場合もある
談話、文、命題の違い
- 文
文字や発話で言語化された表現：「私は今疲れてる。」 - 命題
真偽が判定できる意味内容。
文に「誰が・いつ・どこで」などの文脈情報を補うと命題になる。
：「話者Aは時刻Tに疲労状態である。」 - 談話
複数の文or命題が文脈（話し手の意図・聞き手の推論を含む）で結びついた言語活動：
「私は今疲れてる。今日は外に出たくない。」
命題の構造
命題は真偽が判定できる意味内容だが、その意味内容には内部構造が存在する。
ここでは命題を構造を支える基本的な属性について整理する。
命題は「誰が・何を（Thematic Roles）」「いつ（Tense）」「どの段階(Aspect)」「どんな態度（Mode）」だけでなく、対象の特性（Semantic Features）、指示対象（Deixis）、そして集合の量化（Quantifiers）によって構造化される。
Thematic Roles
まず、命題の骨格を与える要素をThematic Roles（意味役割）という。
誰が・何を・どうやってという5W1Hが有名だが、ここではさらに多岐に渡る構造要素を意識して文脈情報を補う。
ただし補いすぎると言語表現が冗長になりすぎるため、文脈が確実に誤解なく働く場合は適宜省略してもよい。
Core Roles
- Agent（AGT）：動作を行う実体
- Theme/Patient（OBJ）：動作を受ける実体（Themeは第4文型の第一目的語）
- Experiencer（EXP）：経験を得る実体
- Stimulus（STI）：経験をもたらす実体
- Recipient（REC）：対象の受領実体（give A to BのB）
- Beneficiary（BEN）：利益を得る実体（buy A for BのB）
- Instrument（INS）：動作に使う道具
Adjunct Roles
- Location（LOC）：動作が起こる場所（where）
- Source（SRC）：動作の起点
- Destination（GOL）：動作の終点
- Path（PTH）：経由地点
- Time（TIM）：動作が起きた時間（when）
- 開始タイミング
- 終了タイミング
- Manner（MAN）：動作の方法（how）
- Comitative（COM）：動作の共同実行者
文の動詞ごとにどのRoleが使われるかが決まることが多い。
ここでは複数のRoleを使う例をいくつか挙げる。
Taro threw the ball to Hanako with his left hand.
throw
AGT = Taro
OBJ = Ball
GOL = Hanako
INS = his left hand
Taro taught Hanako mathematics using examples.
teach
AGT = Taro
EXP = Hanako
OBJ = mathematics
MNR = examples
このようにThematic Rolesでは行為（AGT→OBJ）と経験（STI→EXP）を分けて考える。
行為と経験は脳が全く別のイベントとして処理しているため：
- 行為（物理的因果関係）は運動野・前頭前野の領域
- 経験（心理的因果関係）は扁桃体・帯状皮質の領域
Tense（時制）
- 過去
- 現在
- 未来
Aspect（アスペクト）
命題は状態そのものではなく、状態がどのように変化しているか（Aspect）も含みうる。
特にイベントやプロセスを表す文は動作の開始、進行、完了などの状態の明確化を意識する。
- Pre-inchoative（PRE）：開始前（before doing）
- Inchoative（INC）：開始（start doing）
- Progression（PRG）：進行中（is doing、～している）
- End（END）：終了・完了（stop/finish doing、have done、～していた）
- Habit（HAB）：習慣（usually do）
- State（RES）：状態・結果（is done, state verb）
Mode（モード）
英語・日本語にはたくさんの助動詞があるが意識するべきはこの5つだけ。
Modeは「話し手がその命題をどう判断してるか」を表すメタ情報。命題の真偽そのものではないが、意思決定や推論では重要な補助情報となる。
- Indicative（IND）：モードなし。命題の純度が最も高い（真偽が確定する）状態として扱う
- Must（MST）：義務
- Want（WAN）：願望
- Can（CAN）：能力
- May（MAY）：可能性
Must、Wantは事実ではなく話者の判断となるので命題ではなくなる（使うときは慎重に）。
Mayは真偽が判定できないので命題の強度は弱まるが、現実世界の意思決定は確定結果ではなく可能性をもとに行われることが多いため、モーダルな命題も論理接続の要素になりうる。
#「雨が降るかもしれないから、明日の試合は中止とします。」
if prob(rain) > 0.4:
cancel(game)
Semantic Feature（特性）
主に形容詞や副詞の特性を表す
- KND：種類（Kind）：分類
wooden, digitalなど。 ENUM的特性で分類して記述できるので安全に使える - QTY：量（Quantity）：離散スケール・相対スケール
big, small, manyなど。big/smallの基準が曖昧にならないよう、基準を定量的に明示するとよい - DEG：程度（Degree）：連続スケール
good, bad, tall, shallowなど。50cm tallなど値を添えて定量化するとよい。ここには数値化不能な主観的評価を表す形容詞が非常に多いので要注意（後述）
Deixis & Referent（指示語）
- Deixis（指示の遠近）
- This：これ（話者の近く）
- That：それ（聞き手の近く）
- Yon：あれ（両者から遠い）
- Referent（指示対象）：
- Entity：実体
- Event：出来事
- Prop：命題
「これ」・「それ」・「あれ」だけでは指示対象の文脈依存性が強くなり曖昧になることがある。
指示対象のEntity/Event/Propを区別を意識して必要に応じて明示することを心がける。
Look at this. # Entity
That happened yesterday. # Event
I cannot believe that. # Proposition
Quantifiers（集合の量化）
- ALL（全称）
- ANY/SOME（存在）
- NONE（無量化）
- EXACTLY-ONE（一意性）
- RANGE（範囲）
- MOST（大多数）
数えられる対象物については、集合（範疇）の中の量を意識する。
ANY/SOMEやMOSTは曖昧なので、数値や基準を明示したほうがよい。
ALL/NONEについても、All engineers know this.は本当に全集合なのかを確認すべきだし、感情的表現になってないかも留意する。
例文
Yesterday, I carefully showed this new device to one of our testers in the lab.
She told me that many users had already experienced that issue.
I think we should immediately fix that component for all customers.
- Sentence 1:
Yesterday, I carefully showed this new device to one of our testers in the lab.
show(tense=過去)
AGT = I
PAT = this new device（DX=THIS, KND=new）
REC = one of our testers（Quantifier＝EXACTLY-ONE）
LOC = in the lab
TMP = yesterday
MNR = carefully(DEG)
- Sentence 2:
She told me that many users had already experienced that issue.
tell(tense=過去, ASP=CMP)
AGT = she
REC = me
PROP:
experience(tense=過去)
EXP = many users（QTY = MANY）
STI = that issue（DX = THAT）
- Sentence 3:
I think we must immediately fix that component for all customers.
think(現在)
AGT = I
PROP:
fix(TNS=現在、ASP=INC, MODE=MUST)
AGT = we
PAT = that component（DX = THAT）
BEN = all customers（QTY = ALL）
MNR = immediately(DEG)
文・命題の接続
前節で、命題の内部構造（Thematic roles / Tense / Aspect / Mode / Sematic features / Deixis / Quantifiers）を整理した。
次に、命題どうしを構造的・談話的に繋ぐ方法を考える。
構造的な接続（優先して使う）
| 接続方法 | 説明 | 接続詞 | 論理学的記述 | プログラミング記述 |
|---|---|---|---|---|
| 1. AND 追加・並列 | 同レイヤーの情報を増やす | また | 可 | collection |
| 2. BUT 対立・制限 | 有効範囲を制限する | しかし、だだし | 不可 | 不可 |
| 3. CAUSAL 因果・目的 | 原因⇔結果 | だから、なぜなら、〜のために | 可 | 不可 |
| 4. COND 条件・仮定 | if then構造 | もし〜なら | 可 | if else |
| 5. TEMP 時間・展開 | 手順・プロセス | まず、次に、同時に | 可 | sequence |
| 6. RESTATE 再構成・要約 | 例示・汎化・換言 | 例えば、つまり | 不可 | 不可 |
- 例文
通知方式にはプッシュ方式とポーリング方式の2種類があります（AND）。
まずはプッシュ方式の到達率を検証し、次にポーリング方式の安定性を確認する、という順で評価します（TEMP）。
もし プッシュ方式が「通知到達率99%以上」という要件を満たす場合は、採用候補になります（COND）。
しかし、プッシュ方式はネットワークが不安定な環境では通知が欠落しやすく、（BUT）
その結果、要件を満たせないケースが実際に発生します（CAUSAL）。
一方で、ポーリング方式は即時性には劣るものの、安定した到達率を維持できます。
つまり、即時性を優先するならプッシュ方式、確実性を優先するならポーリング方式という整理になります（RESTATE）。
2．対立・制限の but は論理記号ではない。
Penguins are bird, but they don't fly.のように命題を制限するものである。
人間には「鳥は飛ぶものだ」というImplicatureがあるから、その推論を破壊するのが目的。
（プログラム言語には and はあるが but は無い）
3．原因CAUSALは、実は4.COND, 5.TEMP、モーダルMAYの合成で表現できる。
「雨が降るかもしれないから、明日の試合は中止とします。」
- TEMP：雨が降る→試合の判断が行われる
- COND：もし雨が降るなら試合は中止となる
- MAY（オプション）：雨が降るかもしれない
CAUSAL=COND,TEMP,MAYを合成した自然言語のマクロ
談話的な接続（補助的に使う）
- 補足説明（Ellaboration）
John bought a car. It's a red Toyota. - 背景設定（Background）
John was driving home. It was raining heavily. - 評価（Evaluation）
John missed the deadline. That was a serious mistake. （単なる感想） - 根拠（Evidence）
John must be home. His lights are on.（推論の根拠） - 物語的接続（Narrative）
He opened the door. He walked inside.
原因・理由・根拠の違い
原因：結果を引き起こす客観的な出来事
理由：結果や判断について、話し手が提示する談話的な説明。構造接続としては扱わない。
根拠：判断を支持するための観察情報。推論の材料であり説明ではない。
「評価」はとくに要注意！
動物は感覚器を得た瞬間からgood/badの単純評価で行動判断をしてきた。
その要求にあわせて自然言語でも評価を表す語彙が発達してきた。
評価は談話レイヤーなため、構造的表現を阻害するノイズになるだけでなく、評価→即判断に繋がり、思考停止に陥りやすいので特に注意が必要だ。
形容詞
- 記述形容詞：red, wooden, small, internal, remote
- 評価形容詞：good, bad, terrible, serious, appropriate
観察可能性で分別できる：記述形容詞は観察可能、評価形容詞は観察不可能
評価形容詞を使いそうになったら、なぜその評価をしたのかを掘り下げるとよい。
This design is good. # 主観判断→思考停止
The design satisfies requirements A, B and C. # 記述的 & 構造的
副詞
副詞についても同様である。
- 評価副詞：fortunately, surprisingly, obviously
- 記述副詞：quickly, simultaneously, manually
観察可能性で分別できる：記述形容詞は観察可能、評価副詞は観察不可能、
Unfortunately, the system failed. # Unfortunatelyは評価副詞
The system failed at 03:21 due to a timeout.
名詞
- 記述名詞：car, system, state, user, database
- 評価名詞：problem, mistake, success, risk
名詞は物体だけではく抽象概念や定義なども現れるので、観察or測定or定義可能性で分別する。どれにも当てはまらなければ評価名詞である。
We faced a problem. # problem は評価名詞
The system consumed 100% CPU and stopped responding.
抽象名詞の罠
「必要」、「リスク」、「問題」、「成功」などの抽象名詞は、実際は評価語+モダリティの合成すぎず構造を損なうものである。
| 抽象名詞 | 隠れた意味 |
|---|---|
| 必要 | MUST |
| リスク | MAY(bad) |
| 問題 | bad thing |
| 成功 | desirable result |
さらにモダリティMUSTの真の意味を構造的に記述するとこうなる。
You must do = AGT(I) strongly think it's good for BEN(X) that you do
評価語goodが隠れてるし、真のAGT（主語）「私」が隠れてるし、BEN（利益を受ける実体）は隠れている上に文脈依存である。（多くの場合、それは「社会」だったり「組織」だったりで、暗黙的に同調圧力をもたらす。）
以上のように、人間は安易に評価をしがちな上に、自然言語にも評価語が多いので気をつける。これらの評価語は対象物の特性を記述している風に見えて、判断主体（発話者）の主観が隠れるから厄介だ。
評価をするなら、ひととおり事象を構造的に記述した上で、最後に談話として付け足すのがよいだろう。その際、英語なら「I think」、日本語なら「〜と考える。」のように評価主体を明示することを薦める。
終わりに
自然言語はどうしても文脈を伴うので構造的に記述するのは難しい。しかし、本稿で示したように、文を命題として十分に情報化し、その命題を構造的に接続していけば、読みやすく、意味がブレにくい文章になる。
大事なのは、安易に個人的な評価や感情を混ぜないこと。事実と構造を先に立てておけば、文脈のノイズに流されず、結果として相手により正確に伝わるはずだ。