YAYA Core モジュール調査報告書

調査日: 2025年10月16日
プロジェクト: Ourin (桜鈴)
調査対象: yaya_coreモジュールの存在確認と実装計画策定

2026-06-27 ステータス修正: 本書は2025年時点の履歴文書です。現在の yaya_core は IPC のみではなく、C++パーサー/VM、辞書ロード、 CP932/UTF-8変換、SHIORI IPC、多数の組み込み関数を含みます。ただし 100% 互換ではなく部分互換です。現状は ../yaya_core/IMPLEMENTATION_STATUS.md（公開向け概要）と AUDITS_COMPLETED.md（公開向け概要） / AUDITS_TODO.md（公開向け概要）を参照してください。

エグゼクティブサマリー

調査結果

履歴上の記述: 本調査当時、yaya_coreモジュールは基本フレームワークのみ実装で、 YAYA言語インタプリタ機能は未実装でした。現在はこの記述は古く、parser/VM/builtinの実装が進んでいます。残課題は yaya_core/IMPLEMENTATION_STATUS.md に集約されています。

推奨事項

C++で実装を継続 - 既存のフレームワークを活用し、公式YAYAを参考にmacOS最適化を実施
段階的実装 - MVP（最小機能製品）から開始し、段階的に機能拡張
既存Swift資産を最大活用 - IPCレイヤーは完成しており、変更不要

1. 現状分析

1.1 既存実装の評価

✅ 実装済み部分

コンポーネント	状態	説明
IPCフレームワーク	完成	JSON line-based通信（stdin/stdout）
コマンドディスパッチ	完成	load/request/unloadコマンド処理
Swift統合レイヤー	完成	`YayaAdapter.swift`でプロセス管理
ビルドシステム	完成	CMake + Universal Binary対応

❌ 2025年当時の未実装部分（現在は `IMPLEMENTATION_STATUS.md` を参照）

コンポーネント	優先度	工数見積
辞書パーサー	最高	1週間
YAYA VM	最高	1.5週間
組み込み関数	高	1週間
SHIORI統合	高	0.5週間
文字コード変換	中	0.5週間
配列・ループ	中	1週間
正規表現	低	0.5週間

合計工数見積: Phase 1（MVP）で約3週間、Phase 2で追加2-3週間

1.2 ファイル構成

リポジトリルート/
├── yaya_core/                    # ✅ YAYA Coreモジュール（C++）
│   ├── CMakeLists.txt            # ✅ Universal Binary設定済み
│   ├── README.md                 # 🆕 今回作成
│   └── src/
│       ├── main.cpp              # ✅ IPCエントリポイント
│       ├── YayaCore.{cpp,hpp}    # ✅ コマンド処理
│       └── DictionaryManager.{cpp,hpp}  # ❌ スタブのみ
│
├── Ourin/Yaya/                   # ✅ Swift統合レイヤー
│   └── YayaAdapter.swift         # ✅ プロセス管理・IPC通信
│
├── docs/                         # ドキュメント
│   ├── OURIN_YAYA_ADAPTER_SPEC_1.0M.md  # ✅ IPC仕様
│   ├── OURIN_USL_1.0M_SPEC.md           # ✅ SHIORI Loader仕様
│   ├── YAYA_CORE_IMPLEMENTATION_PLAN.md # 🆕 実装計画（今回作成）
│   └── YAYA_CORE_TECHNICAL_SPEC.md      # 🆕 技術仕様（今回作成）
│
├── emily4/                       # ✅ サンプルゴースト
│   └── ghost/master/*.dic        # YAYA辞書ファイル（50+ファイル）
│
└── CORE_SAMPLES/                 # 参考実装
    └── MacUkagaka.SHIORI/        # C# SHIORI実装（参考用）

2. 技術選定の根拠

2.1 言語選択: C++ vs Swift

推奨: C++ベース実装

理由:

既存資産の活用 - 公式YAYA (C++実装、BSD-3-Clause) のアーキテクチャを参考可能 - 文字列処理・パーサーライブラリが成熟 - IPCフレームワークは既にC++で実装済み
パフォーマンス要件 - 辞書パース: 50+ファイル、数百KB〜数MBのテキスト - VM実行: イベントごとに数千〜数万ステップ - 低レイテンシ要求: OnBoot応答 < 50ms
Universal Binary対応 - CMakeで既にarm64/x86_64対応済み - Swiftでも可能だが、C++の方が設定が簡単
段階的移行が可能 - IPCでプロセス分離されているため、後でSwiftに書き換え可能 - Phase 3以降でSwift VM実装を検討可能

Swift実装の場合のメリット・デメリット

メリット: - Xcodeとの統合が容易 - Swift Concurrency活用 - メモリ安全性（ARCによる自動管理）

デメリット: - パーサー・VMの既存資産が少ない - パフォーマンスチューニングが難しい - 公式YAYAのC++コードを参考にしにくい

結論: Phase 1はC++、Phase 3以降でSwift移行を検討

2.2 依存ライブラリ

ライブラリ	用途	ライセンス	備考
nlohmann/json	JSON IPC	MIT	✅ 既に使用中
ICU	文字コード変換	Unicode	macOSにプリインストール
std::regex	正規表現	-	C++11標準ライブラリ
Google Test	ユニットテスト	BSD-3	推奨

追加依存なし: C++標準ライブラリ + macOSシステムライブラリで実装可能

3. 実装アプローチ

3.1 フェーズ計画

Phase 1: MVP（最小機能製品）- 3週間

目標: Emily4ゴーストを起動できる

[x] プロジェクト調査・計画策定
[ ] 字句解析器（Lexer）実装
[ ] 構文解析器（Parser）実装
[ ] YAYA VM実装
変数ストア
関数レジストリ
基本的な式評価
[ ] 組み込み関数（最小セット）
RAND(), STRLEN(), SUBSTR()
reference[], ARRAYSIZE()
[ ] SHIORI統合
リクエスト解析
レスポンス構築
[ ] Emily4で動作確認

成功基準: - ✅ Emily4が起動する - ✅ OnBootイベントが動作する - ✅ 基本的な対話が可能

Phase 2: 拡張機能 - 2-3週間

[ ] 配列・連想配列
[ ] ループ構造（while/foreach）
[ ] 正規表現サポート
[ ] パフォーマンス最適化
[ ] 包括的テストスイート
[ ] 複数ゴーストでの動作確認

Phase 3: 品質向上（継続的）

[ ] メモリリーク検証
[ ] パフォーマンスプロファイリング
[ ] ドキュメント完成
[ ] (オプション) Swift VM移行検討

3.2 技術アーキテクチャ

┌─────────────────────────────────────────────────────────┐
│                    Ourin.app (Swift)                     │
│  ┌────────────────────────────────────────────────────┐ │
│  │         YayaAdapter.swift (IPC Client)            │ │
│  └──────────────────┬─────────────────────────────────┘ │
└─────────────────────┼───────────────────────────────────┘
                      │ JSON over stdin/stdout
                      │
┌─────────────────────▼───────────────────────────────────┐
│              yaya_core (C++ Executable)                  │
│  ┌────────────────────────────────────────────────────┐ │
│  │  main.cpp (IPC Server)                            │ │
│  └──────────────────┬─────────────────────────────────┘ │
│  ┌──────────────────▼─────────────────────────────────┐ │
│  │  YayaCore (Command Dispatcher)                     │ │
│  │    ├─ load    → DictionaryManager::load()        │ │
│  │    ├─ request → DictionaryManager::execute()     │ │
│  │    └─ unload  → DictionaryManager::unload()      │ │
│  └──────────────────┬─────────────────────────────────┘ │
│  ┌──────────────────▼─────────────────────────────────┐ │
│  │  DictionaryManager                                 │ │
│  │    ├─ Lexer (字句解析)                            │ │
│  │    ├─ Parser (構文解析)                           │ │
│  │    ├─ VM (仮想マシン)                             │ │
│  │    │   ├─ VariableStore (変数管理)               │ │
│  │    │   ├─ FunctionRegistry (関数テーブル)        │ │
│  │    │   └─ BuiltinFunctions (組み込み関数)        │ │
│  │    └─ ShioriAdapter (SHIORI/3.0M変換)            │ │
│  └────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘

3.3 データフロー

1. ゴースト起動
   Ourin → YayaAdapter.load(ghostRoot, dics, "utf-8")
   → JSON {"cmd":"load", ...} → yaya_core
   → DictionaryManager::load()
       ├─ ファイル読み込み（UTF-8/CP932自動検出）
       ├─ Lexer::tokenize()
       ├─ Parser::parse() → AST構築
       └─ FunctionRegistry::register()
   ← JSON {"ok":true}

2. イベント処理
   Ourin → YayaAdapter.request("GET", "OnBoot", refs)
   → JSON {"cmd":"request", "method":"GET", "id":"OnBoot"}
   → DictionaryManager::execute("OnBoot", [])
       ├─ FunctionRegistry::find("OnBoot")
       ├─ VM::execute(function)
       │   ├─ 変数参照・代入
       │   ├─ 組み込み関数呼び出し
       │   └─ 条件分岐・ループ
       └─ 戻り値（SakuraScript文字列）
   ← JSON {"ok":true, "status":200, "value":"\\0\\s[0]Hello\\e"}

3. 終了
   Ourin → YayaAdapter.unload()
   → JSON {"cmd":"unload"}
   → DictionaryManager::unload()
   → プロセス終了

4. リスク分析と対策

4.1 技術リスク

リスク	影響度	確率	対策
YAYA仕様の曖昧さ	高	中	公式実装を参照、実機テスト
パフォーマンス不足	中	低	プロファイリング、最適化
文字コード問題	中	中	ICU使用、包括的テスト
メモリリーク	中	低	Asan/Valgrind検証

4.2 スケジュールリスク

スコープクリープ: Phase 1をMVPに厳格に制限
技術的困難: 公式YAYAのコードを参考にして解決
テスト不足: Emily4を基準に、動作すればPhase 1完了

4.3 互換性リスク

Windows版との差異: 非互換部分を文書化、ログ警告
複数ゴースト対応: Phase 2で検証

5. 次のアクション

5.1 即座に実行

✅ この調査報告書をコミット
✅ 実装計画書をレビュー
⏭️ Phase 1 Week 1の実装開始 - Lexer実装 - Parser基盤

5.2 短期（1週間以内）

[ ] Lexer実装完了
[ ] Parserの基本機能実装
[ ] ユニットテスト環境構築

5.3 中期（3週間以内）

[ ] Phase 1（MVP）完成
[ ] Emily4での動作確認
[ ] ドキュメント更新

6. 結論

6.1 調査結果サマリー

yaya_coreモジュールは存在する（基本フレームワークのみ）
実装方針は明確（C++ベース、段階的実装）
必要なリソースは揃っている（ドキュメント、サンプル、参考実装）

6.2 推奨実装アプローチ

C++で実装を継続 - 既存資産を最大活用
公式YAYAを参考にmacOS最適化 - バイナリ移植ではなく再実装
Swift資産を最大活用 - IPCレイヤーは完成しており変更不要
Universal Binaryで配布 - Intel/M-chip両対応

6.3 成功基準

✅ Emily4ゴーストが起動する
✅ 基本的な対話が機能する
✅ Intel/Apple Silicon両環境で動作する
✅ UTF-8/CP932辞書に対応する

7. 添付ドキュメント

本調査に基づき、以下のドキュメントを作成しました:

実装計画書: docs/YAYA_CORE_IMPLEMENTATION_PLAN.md - 詳細なフェーズ計画 - 技術選定の根拠 - リスク分析
技術仕様書: docs/YAYA_CORE_TECHNICAL_SPEC.md - YAYA言語仕様 - アーキテクチャ詳細 - API仕様
README: yaya_core/README.md - クイックスタート - ビルド方法 - IPC プロトコル

調査者: GitHub Copilot
承認者: (レビュー待ち)
日付: 2025年10月16日

出典と編集について

Ourin / Furin Lab・contributors。文書はCC BY-SA 4.0（第三者の個別表記を除く）。Web版は見出し・リンクの整備とローカルパスの一般化を行っています。更新基準日: 2026-10-30。

元資料: docs/YAYA_CORE_INVESTIGATION_REPORT_ja-jp.md
ソース SHA-256: 0fd84f6c0bb9340806f798031b441ad911817f8c6f9eab80a18b1cb71a702988

ライセンス · 出典一覧 · 資料一覧に戻る