Internal pair-Merge に関する考察
大塚知昇 1
1. Internal pair-Merge の定義
本発表では、Internal pair-Merge を、以下の(1b)と定義した。
(1) a.
XP, YP → <XP, YP>(External pair-Merge)b.
{XP, {…YP…}} → <YP, {XP, {…YP…}}>(Internal pair-Merge)c.
{X, {…Y…}} → {<Y, X>, {…Y…}} (Head Movement)

2. Internal pair-Merge の詳細
本発表では、以下二点の補足的想定を行った：1) SIMPL は Labeling Algorithm の後に生じる、2) pair-Merge
により非可視的となっている要素は”secondary LA”により Label 付けされる。
Chomsky (2004)は、pair-Merge は二要素を非対称的に結合し、順序対(ordered pair)を形成するとした。また順序対の内一方は統語的に非可視的になるとしたが、pair-Merge した要素が非可視的のまま Interfaces に送られると Full Interpretation に違反するため、Transfer の際にこれを集合に戻す操作、SIMPL(ification)が生じる。
これらの想定を Chomsky (2015)の枠組みで捉え直す場合、付加詞要素の Labeling の成功のためには、SIMPLの前に Labeling Algorithm を適用する必要がある。
(2) a.
External pair-Merge: XP, YP → <XP, YP>(YP=invisible)b.
<XP, YP>を含む Phase の完成
c.
Labeling Algorithm <XP, YP> → <XP XP, YP>d.
SIMPL の適用: <XP XP, YP> → {XP XP, YP}e.
Transfer(2)の過程には重要な問題が存在する。もし、pair-Merge の結果非可視的となった(2a)の「YP」部分が Labeling
Algorithm の適用を受けないとすると、この Label は決定されないこととなり、Label を持たない要素は Interfacesで読めないため、Full Interpretation に関して問題となる。
ここで、本発表では、Chomsky (2004)が用いている「順序」の概念に従い、Phase レベルで生じる Labeling
Algorithm が、”primary” plane と”secondary” plane に別々の流れで適用される提案する。以上の議論を踏まえ、Internal pair-Merge は(3)のように進むと考えられる。
(3) a.
Internal pair-Merge: {XP, {…YP…}} → <YP, {XP, {…YP…}}>(YP=invisible)b.
<YP, {XP, {…YP…}}>を含む Phase の完成
c.
Labeling Algorithm: <XP YP, {XP XP, {…YP…}}>d.
SIMPL の適用: <XP YP, {XP XP, {…YP…}}> → {XP YP, {XP XP, {…YP…}}}e.
Transfer
ここで、(3c)において、Labeling Algorithm の結果、同一の YP の Copy が、(4)に示されるように、”primary”
LA と”secondary” LA の二度の Labeling に関わることになる。
(4)“primary” LA
XP<YP,Y“secondary” LA

XP>
X

YP
Y

以下では、これにより生じる二つの Labeled Copy が、Head の候補を二つ持つ特殊な Chain の形成に関わると主張する。

3. Internal pair-Merge が生み出す Chain とその解釈
本発表では、両 Interfaces に統一的な、Labeled Copy に基づく Chain Head の決定方法(5)を提案した。
(5) Labeled Copy に基づく Chain Head の決定: Labeled Copy が Chain Head として解釈される。
(5)の想定のもと、暗黙のうちに想定されていた、C-I と SM と Syntax という 3 つの段階における、冗長的な3 つの最小探査サイクルを無くすことができる。。
先述の通り(4)では YP の Labeled Copy は二つ存在し、(5)のもとではどちらも Chain Head となりうる。ここで Sportiche (2016)の Neglect を援用し、Internal pair-Merge の結果、二つの Chain Head の候補が含まれた構造が作り出されるが、これら二つの候補はそれぞれ C-I Interface、SM Interface で別々に Neglect の対象となり、結果、当該の単一の統語構造を解釈する上で(6)の 3 種類の論理的可能性が現れると提案する。
(6)
C-ISM

(i)

Interpret DP1(Neglecting DP2)

Pronounce DP1(Neglecting DP2)

(ii)

Interpret DP1(Neglecting DP2)

Pronounce DP2(Neglecting DP1)

(iii)

Interpret DP2(Neglecting DP1)

Pronounce DP1(Neglecting DP2)

4. 経験的議論
本発表では、上記 3 つの外在化の可能性が、(6i)=Topicalization(Short Scrambling)、(6ii)=Quantifier Raising(Covert Movement)、(6iii) =Scrambling(Radical Reconstruction)に該当すると提案した。従って本発表では、これらの現象はすべて、同一の統語構造が Interfaces での読み取りの違いにより異なった形で外在化した結果であると主張したことになる。

5. 残された問題：場合分けInternal pair-Merge には、基本的にその併合する位置を制限する要因が存在しない。したがって現状の枠組みのままでは過剰生成を導く可能性がある。本発表の枠組みでは、英語で Internal pair-Merge が適用された際には、当該要素の SM Interface での音声的具現化の位置により Topicalization と QR の二つの外在化の可能性がある。QR についてはどの位置に Internal pair-Merge したとしても、最終的に逆転解釈を得られるか否かという違いしか生じないが、Topicalization については文頭以外の位置への Topicalization が誤って容認されてしまう可能性がある。言い方を変えれば、英語において Scrambling が何故ないのかという疑問とも表裏一体である。また日本語についても、Internal pair-Merge が適用された際、発音が伴えば Scrambling あるいは Topicalization として具現化し、そうでなければ QR となるが、日本語で Scrambling が当該の名詞句をほぼいかなる位置にも置くことができることは都合が良いものの、なぜ自由な QR は日本語では許されないのかという疑問が残る。
興味深い点は、上記の状況が、英語と日本語においてある種の相関関係を示しているように見える点である。
英語では Topicalization には制限があるが QR にはない。しかし日本語では Topicalization/Scrambling には制限がないが QR にはある。さらに英語で副詞の分布について自由度が高いことを踏まえると、日本語と英語、そして項要素と副詞要素の区分に基づき、Internal pair-Merge の可能性に関して、何か大きな一般化が導ける可能性がある。これらの点について、今後さらなる考察が必要であると考える。
1t-otsuka@flc.kyushu-u.ac.jp/hakata.yamakasa715@gmail.com

主要参考文献Chomsky, Noam (2004) “Beyond Explanatory Adequacy,” Structures and Beyond: The Cartography of Syntactic Structures
3, ed. by Adriana Belletti, 104-131, Oxford University Press, Oxford.
Chomsky, Noam (2015) “Problems of Projection: Extensions,” Structures, Strategies and Beyond: Studies in Honour ofAdriana Belletti, ed. by Elisa Di Domenico, Cornelia Hamann, and Simona Matteini, 3-16, John Benjamins,Amsterdam.
Sportiche, Dominique (2016) “Neglect,” ms., UCLA. [lingbuzz/002775]