wired raven

文字通りの日記。主に思ったことやガジェットについて

続・Claude Codeをぶん回して開発したらPO兼スクラムマスターになっていた

プログラミング

Claude Codeをぶん回して開発したらPO兼スクラムマスターになっていた - wired ravenの続き。

スクラムのアプローチは正解だった。もちろん、ほかにもいいアプローチはあると思う。

よかったこと

  • チケット管理
    • とりあえず思いついたことは起票しておく
    • 実装中に別対応が必要になったものも起票する
  • チケットの整理
    • 重要度が高いものを優先、前後関係がありそうなものは順番に
  • TDD
    • Claudeが自発的に不具合に気が付き対応してくれる
    • そのテストパターンだとこれ足りないのでは、と気が付いて指摘がしやすい
  • E2Eテスト導入
    • TDDの一環
    • UIの挙動変えたときの品質が担保できる
    • エラーが出たときにClaudeに E2E の何番がこけている。エラーメッセージはこれ、と伝えやすい
  • 意図（CLAUDE.md）と仕様（SPEC.md）の管理
    • これで人間もClaudeも迷う場面が減った
  • 状態遷移図の作成
    • どこが複雑なのかが一目でわかる
    • コードを直す以外のどうやったら状態遷移をシンプルにできるかという観点が持てる
  • 計測、計測、計測
    • 「体感遅い」『理論上はやい』と違う基準で話していたのが実測値で繋がった
  • /review
    • Claude Code のレビューコマンド、いい感じに不具合をみつけてくれる
  • /simplify
    • Claude Code の冗長なコードを排除してくれるコマンド。便利な反面、コード壊す可能性があるので慎重に
  • RETROSPECTIVE.md
    • 作業毎に振り返り
    • フォーマットは「良かったこと、伸びしろ、ネクストアクション」
    • ネクストアクションのうち、ドキュメントで対応できるものはその場で更新
    • 実装が必要なものは issue 作って次
  • 根治 や 徹底的 、 念入りに と強調するワード
    • ソースコードを探索するときの精度があがった、気がする
      • 根治は方針として効いたのか、コードの調査中に不具合に遭遇した時、簡単な修正で終わらせずに不具合の原因を取り除きにいってくれた
    • 強い言葉で指示するより、こういう言葉の方がしっくりくる
    • もしかしたら、ベストを尽くそう、といったらベストを尽くしてくれるかもしれない。ただ、Claudeが本気出したらいくら追加料金払っても足りないので試してない
  • Claude に 着手前に作業手順や仕様で質問ある？ と聞くこと
    • 仕様の確認をお願いされた。コミュニケーション大事

伸びしろ

  • Antigravty + Gemini 3.1 Pro でレビュー・壁打ち・実装
    • 賢すぎるのか、フォルダ構成か何かで判断して、返してくることが多く断念
    • 「深く読みこんで」「処理を把握しながら読み進めて」と言えばやってくれるがしっくりこなかった
    • Antigravity で Claude 呼び出しても挙動が違うので、そもそもの使い方を間違えている可能性が高い
  • 大量のファイル変更で VSCode がクラッシュする
    • ファイルの変更を検知して、文法チェックなどする仕組みが仇になっている
    • Terminal での運用に切り替えて様子見中
  • Web版の Codex 利用
    • 管理がややこしくなってしまったので見送り
    • Codex CLI は仕様レビューやコードレビューで活用している
  • Opusフル活用
    • 最初から最後までOpusのほうがよいのでは、と思ったが、そうでもない
      • これはお金の問題もあるけど、限りある計算機資源を有効に使いましょう、ええ
    • 仕様を固める途中、ややこしい実装や不具合はOpus。調査と実装はSonnetの使い分けでよい
      • 適切な切替タイミングがわかっていない
        • Sonnet が20分はまったら中断して claude --model --resume {hogehoge} するか
        • 同じエラー3回なら Opus 、異なる手順でエラーが出て3回なら仕様や計画見直すとか
  • 「迷いなく実装できる状態が望ましい」が何をもってして迷いなく実装できるのか
    • トークン使い果たしました的なエラーメッセージが出たら検索しすぎなので、ディレクトリ構成やリファレンスを CLAUDE.md に追記する

ネクストアクション

成功の再現性を見つけること。

いつから使い始めるかで大きくわかれる。

初期から Claude Code 導入

  • 初動はSPEC.mdを作ってレビューを繰り返す
    • 作りたいものはあるか、重複しているものはないか、考慮漏れはないか
  • 実装計画を立て、レビューを繰り返す
    • ここで妙なことに気が付ける
  • ガイドライン作り
    • やりたいことと方針を伝える CLAUDE.md
    • そのプロダクト固有のルール（これは動かしながら拡充してきたけど、実装計画が明確であればあるほど作りやすい、はず）
  • 実装フェーズは小さく作る
    • 最初のコードは徹底的にリファクタリングとレビューを繰り返してきれいなものにする
    • このコードが基準になる
  • テスト基盤を整える＆計測を徹底する
    • これが人間とAIで共通の認識に至れる
    • 手戻りも減らせる
  • ドキュメント類含めて定期的にレビュー
    • やりたいこと書けているか、やってほしいことや守ってほしいことが書いてあるか
    • それらに沿って動いてくれているか（ここは人間が判断する）

既存のプロジェクトへの導入

  • コード分析、仕様書に落とし込む、レビューの繰り返し
    • 大きく全体の構成を掴んで深掘りさせるアプローチだと効率よさそう
  • テスト基盤を整える・テストを増やす
    • リファクタリングするにしても何にしてもまずはこれ
  • 小さく試してみる
    • 意図通り動くかどうかみる
    • 意図と違ったらどうやったらうまくいくのか考える
      • 暗黙の知識やルールを言語化する形になると思う

共通

  • やりたいことを最上段から伝える。小出し、後出しをしない
  • これからやることを一言で表すならどうするか意識する
  • ドキュメント類で人間側が何をしたいのか、何をさせたいのかを理解しておく
  • Claude のリトライが多かったり、熟考する場合は仕様や実装を再検討する
  • 迷いなく実装できる状態とは、これやりたい・これができたらOKを目指す
    • Claudeの実装計画の粒度がＷBSかスクラムのスプリントバックログのチケットぐらいになっているとよい
    • 実装計画はもちろん、レビューしてやりたいことできていることをチェック。不明点あれば聞いてみる
  • 小さく試して小さく振り返り
    • 初手は大体何か起きるのでミニマムで作って、躓いた点を洗い出して、次に活かす
    • 安定してきたら、手順確立した証なので、徐々に大きなタスクを任せる
    • 使う技術や言語の異なる部分は別の躓き方をする点は要注意

雑感

今回は Rust + Tauri と自分にとって未知の領域で試した。知らない言語であっても、計測手段とゴールが揃っていれば任せられるとわかったのは予想外の収穫だった。

UIはどうあるべきなのか。フロントエンドとバックエンドの責務。開発者が欲しい情報とは何か……未知の領域でも今までの経験が活かせることもあった。未知の領域なのでお作法の違いに引っ掛かったりした。公式ドキュメントを読んだり、ChatGPT で Deep Research してみたり、従来通りの手段で対処していたが、Claude がクレートのコードとコメントを読んで揺らぎようのない事実を突き止めたのには唸ってしまった。とても正しい。

タイトルに話を寄せると、ツールはかくあるべしを示し続ける PO の比重が大きかったと思う。

一通り実装し、PR 作ったら振り返り。次は何をしたらよくなるか、何を試すか、を考える。そして、次の振り返りで試した結果はどうだったかを考える。

開発の障害があればそれを取り除いて、Claude が爆速で走れる状態を作るのがとにかく楽しい。

この辺はスクラムマスターとしての経験が活きているし、スクラムマスターが性にあっていたのかもしれない、と改めて感じた。

コツはつかめたと思うので次はどうしようかな。しばらくは今作ったツール2つを使って、ブラッシュアップをしていくのは確定。コードを読んでみるのもいい勉強になりそう。

仕事に関する何か、実利のある何か、と考えたけれど、趣味なんだから楽しいほうがいい。

Claude Codeをぶん回して開発したらPO兼スクラムマスターになっていた

プログラミング

バイブコーディングの感動体験記はよく見かける。具体的な手法の紹介や、企業の成功事例も増えてきた。でも、感動体験からその先に至るまでに何があったのか、という話はあまり見ない。今回はその「間」の話を書く。

何を作っているの？

Windows向けのコマンドライン型ランチャーアプリで「Snotra」

まず仕様書（SPEC.md）を書いてから実装に入るやり方を採用した。

Claude Code と Spec駆動開発の威力

最初にざっくりやりたいことをまとめた SPEC.md を Claude Code に深掘りしてもらうと、やりたいことが具体的になった SPEC.md が出来上がる。

この SPEC.md をもとに実装して、というとあっという間に動くものができた。機能は最低限、増やしていけばいい。

最初の壁、そして壁越え

最初は確かにざくざく作れて楽しかったのだが、機能が増えてきてから、こちらを直すとあちらが壊れるといったことが増え始めた。

ここでバイブコーディングやSpec駆動開発がダメだ、というつもりはない。人間が実装してもこの問題は起きる。むしろ、月単位や年単位あとの問題に早く遭遇できたのはいいことだ。

軽量のSpec駆動開発はプロトタイプを作る場面に有効そうだ。実際に触ってみて、欲しい機能が揃っているのか、もっと欲しい機能はあるか。逆に要らないものは何かを考えるきっかけになる。実際に触って評価できるのはとても強い。

仕様だけ抽出して一から作り直す方法もあったが、今回はプロトタイプを改良する方法を選んだ。綺麗な設計から綺麗な実装が生まれると考えると、手間も難易度も多いのだが学びも多いだろう、と期待して。

壁の正体

一つのカバンに会社の書類も学校の教科書もお出かけの着替えも突っ込んでいた。着替えを入れ替えたら書類がぐちゃぐちゃになる。書類を整理したら教科書が出てこない。

シンプルに考えたらカバンをわければいい。

テスト自動化

実装中に壊れたことにそもそも気が付けないのがまずい。

コマンドライン型ランチャーなので検索するときはファイル名やフォルダ名を入力する。

頭を抱えたのが

  • C と入力すると検索結果に C:\Windows が表示される
  • C: と入力すると検索結果に何も出てこない
  • C:\ と入力すると検索結果に C:\Windows が表示される

という不具合。

原因は検索クエリの正規化が足りてなかったこと。

想定されるパターンをClaudeと相談しながら修正した。普段、使わないようなパターンも出てくる。

CLAUDE.md にもテストファーストで作る、と明記してから、Claudeがテストを書き、テストにこけたら原因を調査しコードを直す。テストで想定していた条件そのものが誤りの場合、テストコードを修正する。

テストができない部分に関しては人力のテストを依頼してきた。PRにテストのチェックリストが付与されたり、デバッグ中に「10回試してください。100回あると平均とりやすいです」と提案してきたり。*1

仕様の把握

自分が頼んでおいてあれだけど、細かい仕様を把握しきれていなかった。

SPEC.md に片っ端から書き出し、漏れや矛盾がないかClaudeやCodexを使ってあーでもないこーでもないいいながら整理した。

Mermaid記法の状態遷移図は人間にも生成AIにも読みやすい。図を見ながら「この処理は過剰では？」「条件分岐が多すぎないか？」と判断がしやすくなったのはかなり大きい。

調査 -> 計画 -> 実装 -> 振り返り -> ネクストアクション

Claudeと一緒にスクラムをすることにした。

How I Use Claude Code | Boris Tane をベースにスクラムの概念を融合させた形。

調査、計画、実装は詳細はBorisさんの記事を参照してほしい。今なら翻訳する手段がたくさんあるから大丈夫。

Phase 1: 調査（Research）

まずはコードを調査させ、その結果をファイルに出力させるフェイズ。

不具合修正したい時は

アプリ起動から初期表示までのフローを詳細に理解してください。それが終わったら学習内容と発見事項の詳細なレポートを research.md に出力してください。

といった感じで調べている。

ここは人間が読んで理解する意味合いが強い。

Phase 2: 計画(plan)

設定ウィンドウを開いたら、設定ウィンドウが最前面。検索ウィンドウを背面に表示したいです。実装する方法の概説をした詳細な plan.md を作成してください。

出力された内容を人間が見て内容が妥当か確認、時には指摘やより良い方法のアドバイスをファイルに書き込む。

Planモードとの違いはファイルとして扱えること。コンテクスト圧縮の影響を受けにくいし、他の生成AIにレビューを頼んだりもできるのが強い。

レビューしたら

ドキュメントにメモを追加しました。全てのメモに対処して、ドキュメントを更新してください。実装はしないでください

これで plan.md が最新になるので、改めてレビューする。

Borisさんの記事だとここのサイクルは最大6回まで回すという。

最後にTODOリストの作成を依頼して計画は終わり。

Phase 3: 実装（Implement）

plan.md の TODO に基づいて実装する。

実装からコードレビュー、テストまで含まれている。

コードレビュー

レビューで問題があれば review.md に貼り付けている。

Codex CLI などでコードレビューした指摘事項や実際に動かしてみてイメージと違う点を書き込む。

ここで対処が必要なら「実装」まで戻る。

振り返り

一連の作業のファイルから今回は何がよくて、何がいまいちだったのかを考えるフェイズ。

一連の作業と research.md plan.md review.md を全て読み込み、分析し、得られた洞察を retrospective.md に出力してください

ここで気がつく伸び代は結構ある。

例1

retrospective.md 見ながらの会話。

「レビューで指摘事項たくさんあったけど、どうやったら早く気がつける？」 『メソッド間のつながりがわからずに変更して壊してしまった』 「ドキュメント拡充すると良い？」 『〜のドキュメント更新するといいと思います』 「採用で」

例2

『コマンドの実行エラーがたくさん』 「Windows環境とmacOS環境で開発しているから？」 『それです。環境ごとに手順を分けます』 「ちょっと待って」

ネクストアクション

retrospective.md をもとに次に何をすればいいのか考えるフェイズ。

retrospective.md で得られた洞察をもとによりよくするにどうすればいいのか考え next_action.md に出力してください

調査不足で不具合が増えるなら、調査の時間を増やす、資料を増やす、など考える。

最終的にはCLAUDE.mdやSPEC.md、ナレッジに反映される。

出てきた洞察を取り入れる

テスト自動化セクションで書いた実機テストを繰り返して気がついた。

確かに品質担保の観点では重要なんだけど、都度実機での操作をするのは手間だ。ここで不具合がわかると、実装からやり直しになってしまう。

仕事では手間がかかると後回しになりがちなE2Eテストを導入することにした。これがかなり効果的で実機で確認する時の不具合がかなり減った。

ログを見ていると、Claudeが計画時や実装時にパターンを考え拡充してくれている。

コード固有の知識をナレッジファイルにする

Claude CodeはサブディレクトリのCLAUDE.mdを自動で読み込んでくれる。

例えばこのような構成にして、それぞれのCLAUDE.mdに固有のルールや知識を書いておく。

  • snotra-core/CLAUDE.md
  • src-tauri/CLAUDE.md
  • ui/CLAUDE.md

例によってClaudeと相談しながら書いてもOK。

コードコメントに意図を残す

CLAUDE.md で目標とルール、SPEC.md で仕様、コードコメントでコードの意図を伝える。

コードにコメント不要という話もあるけど、やむを得ない理由で特殊実装するケースもある。

  • 採用しているライブラリの最新版に不具合があるので古いものを使っている
  • 原則、同じコードは書かないようにしているがパフォーマンスのためにここでは同じコードを書いている

こういった背景はコードから読み解けない。ドキュメントに残す手もあるがコードとの距離が遠くて参照が難しいだろう。少なくとも人間には難しかったし、Claudeにタスクに集中してもらうためにもすぐ読める時にあるのが望ましい。

まだ導入段階だけど、手応えはある。

ひらめいたこと

Claude Codeは既存のコードを参考にして新しいコードを書く。これを逆手に取れないかと考えた。

SPEC.mdの構造がそのままコードの構造になるなら、仕様の章立てが整理されていれば、自然と役割の明確なコードが生まれるはずだ。

加えて、最初のひとつをきちんと作っておく。

  1. 小さくてもいいからひとつ使える機能を作る
  2. ちゃんと動くか、自動テストは十分か検証する
  3. コードをリファクタリングし、テストの自動化を強化する

この「最初のお手本」が整っていれば、次の機能を作るときにClaude Codeがそれを参考にする。お手本の品質がプロジェクト全体の品質を底上げしてくれる。

完全に今思いついたものだけど、やれそうだという確信がある。次作る時に試すしかない。

雑感

やってみて思ったのはプロダクトオーナー兼スクラムマスターだ。

  • プロダクトオーナー: 欲しいものは何か、やって欲しいことは何かを言語化し伝えること
  • スクラムマスター: 自分たちはこれから何を作るのか計画を立て、Claude Codeが最大効率で開発できるよう障害を取り除くこと

振り返ってみれば全部、Claudeが迷わず走れる道を作る作業だった。

自分にとって良いか悪いかの判断が必要なものなら、どこかで人間が「こうしたい」「こうやると良くなる」と伝えるフェイズは必要不可欠だと思う。いずれ、生成AIがパーソナリティを理解し、最適に近づけてくれるかもしれない。

少なくとも自分の今欲しいものは自分だけが知っている。それをいかに伝えるのかが重要なのだと思う。

*1:100回あるといい、といってきたのはCodex

Web小説「ラッダイトだけはご容赦を」第2部第33話「管理者を解体せよ」公開しました

Info. works ラッダイトだけはご容赦を

カクヨム版

小説家になろう版

Web小説「ラッダイトだけはご容赦を」の新エピソード公開してました

Info. works ラッダイトだけはご容赦を

カクヨム版

小説家になろう版

Web小説「ラッダイトだけはご容赦を」第2部の新エピソード公開しました

Info. works ラッダイトだけはご容赦を

カクヨム版

小説家になろう版

『終わりのクロニクル オリジン』の「パンガイア神話」とは何か？ ヴィッツェル説と作中設定の対応

覚書

私は比較神話学・言語学の専門家ではない。この記事は作品をきっかけに調べた個人的な読書メモで、専門家のレビューを経ていない。誤りや理解不足があり得るので、関心を持った方は参考資料から一次資料に当たってほしい。

現在、カクヨムネクストで連載中の『終わりのクロニクル オリジン（川上 稔） - カクヨム』には、比較神話学と比較言語学を下敷きにした設定が登場する。作中で語られる内容は、どこまでが現実の学術的知見で、どこからが創作なのか。公開されている一次・二次資料（講演録、書評、国内解説）を参照して、対応関係を整理してみた。

この記事はヴィッツェルの提案（仮説）を紹介するもので、学界の合意を主張するものではない。

執筆時点（2026年1月）でオリジンは連載中。以下の考察は現時点で公開されているエピソードに基づく推測を含む。今後の展開によって評価が変わる可能性がある。

ヴィッツェル説（世界神話学）の要点

ヴィッツェル（E. J. Michael Witzel）の「世界神話学」は、世界各地の神話を「地域ごとの特徴」ではなく、神話が共有する構造（物語の並び方）と分布から大まかな層に分けようとする試みである。ここでいう「神話」は、特定の宗教教義というより、口承で伝えられた創世譚・英雄譚・終末譚・儀礼神話を含む広い概念として扱われる。

ヴィッツェルの整理では、神話は以下の層として段階的に分岐したと想定される。

  • パン・ガイア（Pan-Gaean）神話：人類がアフリカにいた時代に形成されたと想定される、最も古い層。ゴンドワナ神話とローラシア神話の共通祖先にあたる。地質学の「パンゲア超大陸（Pangaea）」とは別物で、神話分類上の呼称である点に注意。（以下、パンガイア神話）
  • 出アフリカ（Out-of-Africa）神話：アフリカを出て西アジア〜南アジアへ拡散した段階で現生人類が保持していたと考えられる神話。松村一男はこの用語を「出アフリカ神話」と訳している。
  • ローラシア神話（Laurasian）：創世から始まり、神々や英雄のエピソードを経て、世界の破局や更新（終末）へ至る、通史的な「物語連続（ストーリーライン）」として提示されやすい。
  • ゴンドワナ神話（Gondwanan）：上のような通史的ストーリーラインとして統合されにくい（同じ形式で連結されにくい）という対比で説明される。

つまり「パンガイア→出アフリカ→ゴンドワナ／ローラシアへの分岐」という段階を想定し、現生人類の移動史と神話伝播を重ねて理解しようとする枠組みだ。

ヴィッツェル説への批判

この枠組みは大胆な仮説であり、分類基準の適用や推論の妥当性について批判もある。

Tok Thompsonは分類基準の恣意的適用を問題視している。イヌイットやデネの神話に終末論が欠けていてもローラシア型に分類される一方、サン族の神話に同じ要素が欠けていると「ゴンドワナ型の欠如の証拠」とされる。基準が著者の都合に合わせて適用されているという批判だ（Journal of Folklore Research）。Bruce Lincolnは、ヴィッツェル自身が人種差別主義者だとは考えないが、結論に人種差別的含意が生じているという趣旨の批判をしている（Asian Ethnology）。日本語圏でも、データの扱い方や推論の飛躍を疑問視するレビューが出ている（J-STAGE書評）。

また、パンガイア神話の最大の難点は、数万年単位での保持をどう担保するかにある。口承で神話を長期にわたって安定して伝えるには、定型句・韻律・儀礼との結合といった技法が有利で、実際に多用されやすい。けど、これらは痕跡をほとんど残さない。考古学が直接扱えるのは物質的痕跡に限られ、音声・身振り・実演の要素は残りにくい。

さらに厄介なのは、比較神話学には比較言語学ほど強い検証枠組みが整っていないことだ。

比較言語学 比較神話学
音韻対応の法則がある 規則的変化の法則が確立していない
祖語を再構築できる 「原神話」の再構築は推測の比重が大きくなりやすい
借用と継承を区別しやすい 伝播と独立発生の区別が難しく論争になりやすい

比較言語学では、グリムの法則のように「印欧祖語のpがゲルマン語でfになる」といった規則的変化を追跡できる。神話モチーフにも系統推定の手法を適用する研究はある（例：民話の異本を特徴量化して系統樹を作成する試み）けど、比較言語学ほどの確度は得られていない。洪水・死・創造といったテーマは人間の普遍的関心事だから、各地で独立に発生した可能性を排除しにくい。

結局、ゴンドワナ・ローラシアの二分法は、パンガイアまで遡る仮説よりは地理的・時間的に追跡しやすい。けど、パンガイア神話まで遡ると「そうであっても矛盾しない」以上のことが言いにくい。仮説は立てられても、検証が難しい。

制度的にも、比較神話学は単独のディシプリンとしてより、宗教学・人類学・民俗学・古典学の一部として研究されることが多い。方法論的基盤が確立途上であることの反映かもしれない。

作中で語られる内容

主人公・佐山は、人類の神話の成り立ちについて次のように説明する。

  • 人類がアフリカにいた頃、自然信仰を基礎とした「パンガイア神話」があった
  • アフリカを出る過程で「出アフリカ神話」が生まれた
  • その後、「ゴンドワナ神話」と「ローラシア神話」に分岐した

表示枠（作中のAI）は《比較神話学の一説として　間違いありません》と留保をつける。そして大城という人物が、「各G（異世界）との接触が神話の地域差を生んだ」という真相を明かす。

現実の学術的知見との対応

作中の説明は、ヴィッツェル説の再現としては概ね沿っている。段階分け（パンガイア→出アフリカ→二分岐）は、松村一男の整理とも整合する。

作中で言及される学術用語

  • 印欧祖語：実在する。年代推定には仮説によって幅がある。代表的な整理として、ステップ（クルガン）仮説は約6000年前、アナトリア仮説は約8000〜9500年前とされる（例：Bouckaert et al., 2012）。作中の「9000年前〜6000年前」は、こうした幅をまとめて言っている、と読める。なお、言語系統推定に計算的手法を導入する意義や限界については、概説として(村脇有吾 2017)が参考になる。
  • ゲルマン祖語：実在する。印欧祖語からの派生という説明も正確。
  • ゴンドワナ神話・ローラシア神話：マイケル・ヴィッツェルが提唱した神話分類の枠組み。
  • パンガイア神話：ゴンドワナ神話とローラシア神話の共通祖先を「パンガイア神話」と呼ぶ。ヴィッツェルが提案する「超系統」の呼称として用いられている。

各Gとの接触（作中設定）

「祖語が形成される段階で異世界との接触があり、神話の地域差に影響を与えた」——これが作品の核心的な創作設定。現実世界で「なぜか説明できない」部分を、物語内ロジックで「答え」として提示している。

日本語の系統について（作中設定）

大城は日本語を「幾つもの言語のミックス」と表現する。言語学では、日本語は琉球諸語とともに「日本語族（Japonic）」として扱われ、外部との系統関係は未確定とされている。「ミックスだと判明している」わけではない。

作中には「神州世界対応論」という設定がある。日本は複数のGと繋がっているため、言語も複数の影響を受けているという説明は成立すると思う。

なぜこの学説を採用したのか

ヴィッツェルの「世界神話学」は2000年代以降に体系化された新しい研究潮流だ。国際比較神話学会（IACM）は、2006年5月に北京大学で開催された設立会議を端緒として、2008年ごろに正式に組織化されたと紹介されている。ヴィッツェルは創設者として運営に関与している。国際会議は各地で開催され、2009年には東京（國學院大学）でも開催された。日本でも後藤明『世界神話学入門』（講談社現代新書、2017年）が刊行されるなど、紹介が進んでいる。

学術的な不確定性は、創作においてはむしろ利点となる。

  • 検証が難しい → 創作で補強する余地がある
  • 空白の数万年 → 「各Gとの接触」で埋められる
  • 規則的変化が確立していない → 異世界からの影響という変数を導入できる

作中で表示枠が《比較神話学の一説として》と留保をつけているのは、この学術的不確実性を反映しているのかもしれない。

そして大城は「真実を知っている」立場から、学術的仮説が「正しい理由」を明かす。現実世界では証明できない仮説が、作中では「各Gとの接触」という隠れた変数によって真実として成立する構造だ。

佐山がなぜパンガイア神話説を「知っていて」「選んだ」のかは少々、気になった。比較神話学を知っている人間なら、デュメジルの三機能説やキャンベルのモノミスなど、もっとメジャーな枠組みから説明しそうなものだ。

これはおそらく作劇の効率を優先した判断だろう。佐山に別の説を語らせても、最終的にパンガイア神話に到達させる必要があり、会話が長くなるだけで意味がない。学術的な自然さより、読者への説明効率を取った。

個人的には佐山がメジャーな説を出して、大城に違うと言われ、佐山が大城を真っ向から否定する漫才めいたやり取りを期待したかったのだけれど、テンポが悪いと言われるとその通り。

オリジンでのTop-G未言及と補強の可能性

現時点で公開されている『終わりのクロニクル オリジン』では、Top-Gという語は登場していない。

電撃文庫版ではTop-G／Low-Gが後半で重要な争点になるため、オリジンで比較言語学・比較神話学の説明が先に補強されていることは、上位概念を導入するための足場作りとして読むこともできる。

ただし、これは連載中作品に対する推測であり、あたっているかどうかは今後のお楽しみである。

総評

作中の用語運用と大枠の分類は、ヴィッツェル周辺の一次・二次資料に概ね沿っている。用語・枠組みは実在し、講演録で確認できる。ただし、ヴィッツェル説自体は野心的な仮説で、学界での評価は定まっていない。

オリジンでの言及は2000年代以降の最新の学説を下敷きにした大胆な加筆だと思う。

参考資料

PDFは上から順に参照、全体像を掴むなら松村一男のPDFが詳しい。