45 vulnerabilities (15 moderate, 15 high, 15 critical)
To address all issues (including breaking changes), run:
  npm audit fix --force

Critical、Remote Code Execution (RCE)、Prototype Pollution といった不穏な単語を目にすると、反射的に npm audit fix --force を実行して赤い警告を消したくなります。

しかし、DocusaurusやNext.jsなどの 静的サイトジェネレーター(SSG) をGitHub PagesやAWS S3にデプロイするアーキテクチャでは、この無分別なダウングレードこそが最新フレームワークを破壊する最大の原因になります。

本記事では、静的サイトの脅威モデル (Threat Model) を明確にし、ビルドツールとランタイム脆弱性の本質的な違いを分析した上で、実際に守るべき 4層のセキュリティ対策 を共有します。

1. 3行まとめ：エンジニアリングの判断基準​

1. ビルド時ツール != 本番ランタイム: 警告されたパッケージ（tinypool、serialize-javascript など）は、ローカルPCで npm run build を実行するときだけ動作するバンドラー依存関係です。
2. CDN上に稼働するサーバーはない: ビルド後のGitHub Pagesには純粋なHTML/CSS/JSしか残りません。稼働中のNode.jsデーモンも、リッスンしているポートも、データベース接続も存在しません。
3. --force の危険性: --force で無理に依存関係を書き換えると、Docusaurusが古いバージョン(3.7.0)に巻き戻され、React 19やMDX v3との互換性が完全に壊れます。
4. 静的サイトの本当の脅威: 狙われるのはサーバーではなく、Git履歴内のAPIキー流出、データセット内の個人情報(PII)、クライアントのリファラー漏洩です。

2. 45件の脆弱性の正体：ビルド時 vs ランタイム​

A. Tinypool のプロトタイプ汚染 (GHSA-5gmw-xhrv-c9v3 - Critical)​

• tinypool はビルドタスクをローカルCPUコアに分散するためのライブラリです。入力値は自身の docusaurus.config.ts のみであり、外部の攻撃者がCDN経由でビルドワーカーに悪意あるペイロードを送信することは不可能です。

B. Serialize-JavaScript の RCE (GHSA-5c6j-r48x-rmvq - High)​

• Webpackが静的チャンクを書き出す際に使用します。出力されたJSファイルは単なる静的ファイルとして配信されるだけであり、サーバー上で逆シリアル化が実行されることはありません。

C. PostCSS Selector Parser の DoS (GHSA-rj75-hqrm-r3gf - Moderate)​

• パース対象のCSSは開発者が作成したスタイルシートです。GitHubリポジトリの書き込み権限が奪われない限り、悪意ある外部CSSが混入することはありません。

結論として、SSG環境で npm audit fix --force を叩くことは、存在しない脅威を防ぐために正常に動作しているシステムを破壊する行為に他なりません。

3. 実践的4層セキュリティ・ブループリント​

第1層：Gitプリコミット・シークレットスキャン自動化​

最も致命的なリスクは、APIキー（OpenAI sk-...、GitHub PAT ghp_...、AWS AKIA...）を誤って公開コミットすることです。Gitの追跡ファイルを正規表現で一括検査する監査スクリプト（tools/audit_security.py）を構築し、リリース前にゼロ漏洩を保証します。

第2層：個人情報(PII)とデータセット保護​

AI相談やナンバープレート認識プロジェクトでは、実データの代わりにLLMパイプラインで生成した 合成対話データ (synth_gen) を活用し、医療倫理やプライバシー侵害を根本から排除しています。

第3層：堅牢な .gitignore 設定​

.env、SSL秘密鍵（*.pem, *.key）、CSV解析ダンプファイル（*.csv）が誤って公開リポジトリにプッシュされないよう設定を強化しました。

第4層：クライアント側プライバシー保護​

• 厳格なリファラーポリシー: strict-origin-when-cross-origin を適用し、外部サイトへ遷移する際にブログの詳細URLパスが漏洩しないよう保護。
• Giscus iframeサンドボックス: emitMetadata="0", loading="lazy" を設定し、第三者スクリプトによるセッション干渉を遮断。

4. エンジニアへの提言​

• 赤い警告に惑わされない: その脆弱性が「ローカルのビルドツール」なのか「本番サーバー」なのかを切り分けることがセキュリティの本質です。
• 真の攻撃対象に注力する: シークレットの検出自動化、個人情報の排除、適切なプライバシー設定こそが、技術ブログの信頼性を高める鍵となります。

📌 Key Takeaways (要約)

• 課題: 単一フレームOCRは車体の揺れや光の反射により、一時的な誤認識（64아1511、24가1511など）が不可避です。
• 解決策: 韓国ナンバープレート規格の正規表現（^\d{2,3}[가-힣]\d{4}$）検証と、過去7フレームのバッファで3回以上一致した場合に確定する時間軸多数決投票エンジンを構築しました。
• 成果: 6月5日の初期の文字化け（ACCIIXOY...）から6月7日の完全な「64가1511」確定まで、11段階（v01〜v11）のリファクタリングを経て99.4%の信頼性を達成しました。

1. 韓国ナンバープレート正規表現とEasyOCR​

import easyocr
import re
from collections import deque, Counter

reader = easyocr.Reader(['ko', 'en'], gpu=True)

def parse_korean_plate(plate_img):
    results = reader.readtext(plate_img, detail=0)
    raw_text = "".join(results).replace(" ", "")
    pattern = r'(\d{2,3}[가-힣]\d{4})'
    match = re.search(pattern, raw_text)
    return match.group(1) if match else None

2. 時間軸多数決投票エンジン​

plate_history = deque(maxlen=CONFIG["plate_history_size"])
confirmed_plate = None

def update_plate_voting(detected_text):
    global confirmed_plate
    if detected_text:
        plate_history.append(detected_text)
    if len(plate_history) >= CONFIG["plate_confirm_threshold"]:
        counts = Counter(plate_history)
        most_common_plate, count = counts.most_common(1)[0]
        if count >= CONFIG["plate_confirm_threshold"]:
            confirmed_plate = most_common_plate
    return confirmed_plate

3. v01からv11への進化記録​

4. シリーズ完結​

全5編にわたり、動的車線検出、IoU侵犯判定、階層型YOLO検出、CSRT追跡、EDSR超解像、多数決OCRを統合した堅牢なビジョンパイプラインを完遂しました。

📌 Key Takeaways (要約)

• 課題: ドラレコ映像から抽出されたプレート領域は40x20ピクセル以下と極小で、バイキュービック補間では輪郭がぼやけて文字認識が不可能です。
• 解決策: バッチ正規化を除去してテクスチャ復元力を高めたEDSR_x4深層残差ネットワーク（EDSR_x4.pb）を導入し、連続3〜5フレームを平均化するマルチフレーム画像スタッキングを併用しました。
• 成果: プレート解像度を4倍に拡大し文字のエッジを鮮明化、EasyOCRのハングル認識成功率を32%から91%以上へ大幅に向上させました。

1. EDSR_x4深層超解像エンジン​

import cv2
from cv2 import dnn_superres

sr = dnn_superres.DnnSuperResImpl_create()
sr.readModel("EDSR_x4.pb")
sr.setModel("edsr", 4)
enhanced_plate = sr.upsample(plate_roi)

2. マルチフレームスタッキング​

時間軸で連続するフレームを整列・平均化することで、ランダムなノイズを打ち消し、文字のコントラストを強調します。

3. 次回予告​

最終回（第5編）では、EasyOCR韓国ナンバープレート正規表現検証、初期の文字化けから「64가1511」確定に至る多数決投票アンサンブルとv01~v11の進化記録を総括します。

📌 Key Takeaways (要約)

• 課題: 640x480全体から直接小さなナンバープレートを探索すると看板等の誤検出が多発し、フレーム毎の深層学習推論はFPSを10以下に低下させます。
• 解決策: YOLOv3-tinyで車両全体を検出した後、そのROI内部でのみYOLOv5（lp_det.pt）を実行する2段階階層構造を採用。15フレーム毎の再検出とOpenCV CSRT高速トラッカーを統合しました。
• 成果: 背景の誤検出をほぼ完全に排除し、GPU演算負荷を80%削減して50+ FPSの滑らかなリアルタイム追跡を実現しました。

1. 階層型物体検出アーキテクチャ​

vehicle_boxes = detect_vehicles_yolov3(frame, net=vehicle_net, conf_thresh=0.5)

for box in vehicle_boxes:
    x1, y1, x2, y2 = box
    vehicle_roi = frame[y1:y2, x1:x2]
    plate_boxes = plate_model(vehicle_roi)
    for pbox in plate_boxes:
        px1, py1, px2, py2 = pbox
        global_plate_box = [x1 + px1, y1 + py1, x1 + px2, y1 + py2]

2. CSRTトラッカーによるリアルタイム化​

3. 次回予告​

第4編では、ぼやけたプレート画像を復元するEDSR_x4深層超解像ネットワークと、ノイズを低減するマルチフレームスタッキング技術を解説します。

📌 Key Takeaways (要約)

• 課題: ドラレコ映像は路面反射、アスファルトの亀裂、影によって誤検出が多発し、単純な座標判定では車線変更の瞬間を正確に捉えられません。
• 解決策: 消失点基準の台形ROIマスク、傾きフィルタリング（|slope| > 0.5）、および7フレーム移動平均キューを採用しました。侵犯判定は車両接地領域（下部30%）と車線ポリゴン間の幾何学的IoU（> 0.05）で定式化しました。
• 成果: 路面ノイズを95%以上除外しながら、車線侵犯の瞬間をサブフレーム単位で安定して検出することに成功しました。

1. 動的車線検出: Cannyと確率的ハフ変換​

def detect_lanes(frame):
    height, width = frame.shape[:2]
    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
    blur = cv2.GaussianBlur(gray, (5, 5), 0)
    edges = cv2.Canny(blur, 50, 150)
    
    mask = np.zeros_like(edges)
    roi_polygon = np.array([[
        (int(width * 0.1), height),
        (int(width * 0.45), int(height * 0.6)),
        (int(width * 0.55), int(height * 0.6)),
        (int(width * 0.9), height)
    ]], np.int32)
    cv2.fillPoly(mask, roi_polygon, 255)
    masked_edges = cv2.bitwise_and(edges, mask)
    
    return cv2.HoughLinesP(masked_edges, 1, np.pi/180, 20, minLineLength=20, maxLineGap=10)

2. 傾きフィルタリングと平滑化​

線分の傾き m = (y2 - y1) / (x2 - x1) を評価:

• 左車線: m < -0.5
• 右車線: m > 0.5
• 路面ノイズ（横線）: |m| <= 0.5 は即座に棄却

さらに deque(maxlen=7) を用いてフレーム間の揺れ（ジッター）を除去します。

3. 幾何学的IoU侵犯判定​

Footprint = [x_min, y_min + 0.7*h, x_max, y_max]
IoU = Area(Footprint ∩ Lane_Polygon) / Area(Footprint)

def check_lane_intrusion(vehicle_box, lane_polygon, threshold=0.05):
    vx1, vy1, vx2, vy2 = vehicle_box
    vh = vy2 - vy1
    footprint = Polygon([(vx1, vy1 + 0.7*vh), (vx2, vy1 + 0.7*vh), (vx2, vy2), (vx1, vy2)])
    
    intersection = footprint.intersection(lane_polygon).area
    iou = intersection / footprint.area
    return iou > threshold, iou

IoU > 0.05 を超えた段階で侵犯フラグを有効化し、ナンバープレート検出器を起動します。

4. 次回予告​

第3編では、階層的物体検出（YOLOv3 + YOLOv5プレート専用モデル）と、GPU負荷を大幅に削減するCSRT追跡器の統合について解説します。

📌 Key Takeaways (要約)

• 課題: ドラレコの低解像度映像は、車体振動、逆光、モーションブラー、強いH.264圧縮ノイズにより、ナンバープレートが著しく潰れ、車線侵犯のリアルタイム追跡が極めて困難です。
• 解決策: Canny/Hough動的車線抽出 -> YOLOv3車両検出 -> 多角形IoU侵犯判定 -> YOLOv5プレート局所検出 -> EDSR_x4深層超解像復元 -> EasyOCR時間軸多数決投票という6段階の階層型パイプラインを設計しました。
• 成果: 過度なGPU負荷を回避し30 FPS以上を維持しながら、過酷なドラレコ環境下でも侵犯車両のナンバープレートを正確に確定するEnd-to-Endシステムを構築しました。

1. プロジェクト背景: なぜドラレコ映像の認識は難しいのか？​

高度道路交通システム（ITS）や自動交通違反取締において、**リアルタイム車線侵犯検知と自動ナンバープレート認識（ANPR）**は中核となる技術です。しかし実際の車載ドラレコ映像を処理する際には、多くの光学的・物理的障害に直面します:

1. 極端な低解像度とテクスチャの潰れ: 640x480フレーム内において、対象車両のナンバープレート領域はわずか30x15〜50x25ピクセル程度しかなく、文字の線画が完全に一体化してしまいます。
2. 路面振動とローリングシャッター歪み: 走行中の段差や急ブレーキ、急な車線変更による角度変化が直線の幾何学的推定を妨げます。
3. リアルタイム処理のレイテンシ: 重大なフレーム単位の重層モデル適用は深刻なフレーム落ちを引き起こし、実時間の追跡を破綻させます。

2. 6段階の階層型パイプラインアーキテクチャ​

flowchart TD
    Raw["ドラレコ生フレーム 640x480"] --> L1["第1段階: Canny + Hough 動的車線抽出"]
    Raw --> L2["第2段階: YOLOv3-tiny 車両領域検出"]
    L1 & L2 --> L3["第3段階: 車両底面＆車線ポリゴンIoU侵犯判定"]
    L3 -- 侵犯検知時 --> L4["第4段階: 車両ROI内のYOLOv5プレート局所特定"]
    L4 --> L5["第5段階: EDSR_x4 深層超解像4倍復元"]
    L5 --> L6["第6段階: EasyOCR + 正規表現 + 時間軸多数決投票"]
    L6 --> Result["確定違反ナンバー: 64가1511"]

3. 主要システム設定値 (CONFIG)​

CONFIG = {
    "output_width": 640,
    "output_height": 480,
    "conf_threshold_vehicle": 0.5,
    "nms_threshold_vehicle": 0.4,
    "min_vehicle_w": 70,
    "min_vehicle_h": 70,
    "lane_iou_threshold": 0.05,
    "detection_interval": 15,
    "min_plate_area_for_ocr": 1200,
    "plate_history_size": 7,
    "plate_confirm_threshold": 3,
    "sr_model": "EDSR_x4.pb",
    "yolo_plate_model": "lp_det.pt"
}

4. 次回予告​

第2編では、Cannyエッジ検出、確率的ハフ変換（HoughLinesP）、傾きフィルタリング数学、および車両バウンディングボックスと車線間の動的ポリゴンIoU侵犯判定アルゴリズムを詳しく解説します。

6月に入り、マウムジギチームは1学期の主要な開発をすべて終え、安全網の構築と最終発表の準備に総力を傾けました。

2:1比率の勝利とSafety Wrapperの導入​

「私たちが選んだモデルは何だった？」 「2:1に決定した。Safety Wrapperを適用してメイン大規模言語モデル(LLM)の安全装置として機能させる方法を企画して。」

私たちは「感情対話」と「日常対話」を2:1の比率で混ぜたモデルを最終LLMに選びました。しかし、自殺予防チャットボットという特性上、致命的な誤答は一度たりとも許されません。 これを防ぐため、LLMの入出力を監視する**Safety Wrapper（安全フィルター）**を導入しました。高リスク状況が感知されれば、即座に危機対応プロトコルに転換されるようアーキテクチャを堅固にしました。

クラウドサーバー予算企画と最終発表​

「g5.2xlargeを5ヶ月使用する予算はどうなる？」 「今までの進行状況をもとに、1学期_最終発表_マウムジギ.pptxを作成して！」

夏休み中に実際のサービスと連動させるため、Amazon EC2 GPUサーバーの予算を算出しました。 そして6月18日、これまで開発したバックエンド、フロントエンド、人工知能(AI)のすべての成果を一堂に集め、1学期最終発表資料を完成させました！

これで長く険しかった1学期の開発が成功裏に幕を下ろしました。2学期にはさらに高度化されたサービスで戻ってきます！

5月の最終週（27日〜30日）、私たちは待望の**4次ファインチューニング（fine_tuning_4）**の結果をまとめ、システムの骨格を固める作業に邁進しました。

最終チェックポイント4400とグラフ分析​

日常対話と感情対話を混合して学習させた4次ファインチューニングモデルが、ついに最適の重みであるcheckpoint-4400を吐き出しました。

以前の学習では、日常的な対話を投げても深刻なカウンセリングモードで答えてしまう過学習問題がありましたが、データ混合比率の実験の結果、ついに「空気の読める」チャットボットに生まれ変わりました！すべての評価指標をグラフで視覚化し、性能差を一目で証明しました。

システムアーキテクチャ設計と最終レポート​

「chatbot_architecture.html 生成完了」 「fine_tuning_4の遂行結果をレポート(.docx)で作成して。」

性能検証が終わったモデルを実際のアプリでサービスするため、chatbot_architecture.htmlという名前でシステム全体アーキテクチャとナレッジグラフ統合案を設計しました。

そして5月30日、人工知能(AI)の助けを借りて最終レポートを自動生成しました。レポートには、オリジナルモデルと私たちがファインチューニングしたモデルの実際の回答比較が赤裸々に盛り込まれており、これまでの苦労が無駄ではなかったことを証明してくれました。

これでマウムジギプロジェクトの息苦しかった5月開発日誌がすべて終わりました。6月にはどんな新しい挑戦が待っているのでしょうか？

5月21日と22日、マウムジギチームは大規模データの生成と**4次ファインチューニング（fine_tuning_4）**の準備に突入しました。

感情対話と日常対話の綱引き​

3次ファインチューニングモデルをテストしている時、致命的な問題を発見しました。

「haiku_predデータセットで学習させると、回答が感情カウンセリングに偏りすぎているようです。日常対話の能力を維持するにはどう学習させればいいですか？」

私たちが目標とするのは「温かい共感を伝えるカウンセラー」ですが、ユーザーが「今日の天気は？」といった日常的な質問を投げた時にも過度に深刻に答えてしまう**過学習（Overfitting）**の兆候が見られました。これを解決するために、感情データと日常データを適切な比率で混ぜて学習させる実験を企画しました。

10,000件のv6感情データセット生成​

最高のデータセットを作るために、Anthropic アプリケーションプログラミングインターフェース(API)のバッチモードを使用して、なんと10,000件に達する感情対話データセットを生成しました。APIがバックグラウンドで処理され進行状況が分からないハプニングもありましたが、追加スクリプトで不足分を満たし完成させました。

感情 vs 日常の黄金比を探す（fine_tuning_4）​

「Emotion_train_dataset_v6.jsonlが完成しました。では、7:3比率、2:1比率、5:5比率のデータセットを作ってください。」 「今回の学習はデータセットの混合比率基準で進行します。」

4次ファインチューニングは、人工知能(AI)の「日常性」と「専門性（カウンセリング）」を最も完璧に調和させるデータ比率を検証する舞台となりました！

📌 要約 (TL;DR)

• 課題(Problem): マイコン（Arduino Uno ATmega328P）の2KB SRAMによる計算制約、ホイールスリップやセンサノイズ、シミュレータ物理と実機ハードウェア間のSim-to-Realギャップ（Reality Gap）。
• 解決(Solution): PCが高レベルな画像処理とQ-Table推論を担当し、ArduinoはモータPWM駆動のみを担う**分散I/Oアーキテクチャ（HC-06 Bluetooth、115,200 baud）を構築。天井Webカメラの歪み補正とArUcoマーカーホモグラフィ（vision.py）**によるリアルタイム(x, y, θ)位置追跡システムを実装。
• 結果(Result): 仮想環境で学習済みの648-bin Q-Table重みのみを用いて、実機の1.2m × 1.2mアリーナで目標到達成功率86.7%を達成し、ハードウェア展開を完遂。

1. Sim-to-Realの挑戦：シミュレーションと現実の乖離​

仮想環境（Webots）では摩擦係数が均一で、モータは指令通り正確に回転し、距離センサ値に反射ノイズはありません。しかし、現実のハードウェア環境は過酷です：

1. 計算資源の絶対的制約: ロボット本体の**Arduino Uno (ATmega328P)**はフラッシュメモリ32KB、SRAMがわずか2KBであり、ニューラルネットワークはおろか複雑な行列演算すら不可能です。
2. センサノイズと死角: 安価な超音波センサはアクリル壁面への入射角によって音波が反射し、距離を0と誤認するか最大値に跳ねる異常値が頻発します。
3. ホイールスリップと累積誤差（オドメトリドリフト）: 床面の微細な凹凸やバッテリ電圧降下により左右モータの回転数に差が生じ、直進指令でも車体が曲がる物理的誤差が発生します。

2. 分散制御アーキテクチャ：PC（頭脳） ↔ Arduino（筋肉）​

この制約を克服するため、**「頭脳はPC、筋肉はArduino」**という分散制御戦略を採用しました。

flowchart TD
    subgraph CeilingCam["天井カメラシステム (Ceiling Camera)"]
        Cam["FHD Webカメラ (30 FPS)"]
        Aruco["ArUcoマーカー検出 (DICT_4X4_50)<br>ホモグラフィ平面化 (homography.npy)"]
        Cam --> Aruco
    end

    subgraph PC["ホストPC (Python Engine)"]
        Pose["ロボット位置・姿勢推定 (x, y, θ)"]
        Disc["648-bin Discretizer"]
        QL["Trained Q-Table (ε=0)"]
        BT_Host["HC-06 Bluetooth SPP (115200 baud)"]
        
        Aruco --> Pose --> Disc --> QL --> BT_Host
    end

    subgraph Robot["実機モバイルロボット (Real Robot)"]
        BT_Slave["HC-06 Bluetooth受信"]
        MCU["Arduino Uno (Firmware)"]
        Motors["L298Nモータドライバ + DCギアモータ"]
        
        BT_Host <-->|"Action Byte [0..3]<br>Ack/Status"| BT_Slave --> MCU --> Motors
    end

• ホストPCパイプライン: 天井Webカメラでアリーナ全体を俯瞰し、ロボット上部のArUcoマーカーを30fpsで追跡。平面座標(x, y, θ)を計算して648の離散状態にマッピングし、Q-Tableから最適な貪欲行動を抽出。
• HC-06通信最適化: Bluetoothシリアルポートプロファイル（SPP）の往復遅延時間（RTT）を最小化するため、通信ボーレートを標準の9,600から115,200 bpsに引き上げ、30〜50Hzのリアルタイム制御周期を実現。
• Arduinoファームウェア (arduino_firmware.ino): PCから行動バイト（0: 直進, 1: 後退, 2: 左旋回, 3: 右旋回）を受信すると、L298NモータドライバにPWM信号を出力して精密なパルス駆動を実行。

3. 天井WebカメラのホモグラフィとArUcoマーカー視覚追跡​

実アリーナ上でロボットの位置と障害物距離を正確に計測するため、OpenCVベースのコンピュータビジョンパイプラインを構築しました。

📐 透視歪み補正とホモグラフィ変換 (calib_auto.py)​

1. チェッカーボード歪み較正: 広角Webカメラレンズの樽型歪み（Barrel Distortion）を除去するため、チェッカーボードパターンを用いてカメラ内部パラメータ行列(K)と歪み係数(D)を事前算出。
2. ホモグラフィ変換 (Perspective Transform): 傾斜したカメラ画角を1.2m × 1.2mの正方形トップダウンビューに射影するため、アリーナ四隅の座標からホモグラフィ変換行列（homography.npy）を生成。

💻 ArUcoマーカー追跡実装 (vision.py)​

import cv2
import numpy as np

# ArUco辞書および検出パラメータの初期化
aruco_dict = cv2.aruco.getPredefinedDictionary(cv2.aruco.DICT_4X4_50)
parameters = cv2.aruco.DetectorParameters()
detector = cv2.aruco.ArucoDetector(aruco_dict, parameters)

def get_robot_pose(frame, homography_matrix):
    """歪み補正画像からロボットの平面座標(x, y)と方位角(theta)を算出"""
    warped = cv2.warpPerspective(frame, homography_matrix, (600, 600))
    corners, ids, _ = detector.detectMarkers(warped)
    
    if ids is not None and len(ids) > 0:
        c = corners[0][0]
        center_x = float(np.mean(c[:, 0]))
        center_y = float(np.mean(c[:, 1]))
        
        # マーカーの前方エッジベクトルからロボットの向き(theta)を計算
        front_x = (c[0][0] + c[1][0]) / 2.0
        front_y = (c[0][1] + c[1][1]) / 2.0
        theta = np.arctan2(front_y - center_y, front_x - center_x)
        
        return center_x, center_y, theta
    return None

4. トラブルシューティングと実機評価結果​

シミュレーションから実機への移行時に発生した課題と、そのエンジニアリング的解決策は以下の通りです：

🏆 最終実機走行結果​

• 障害物回避・ゴール到達成功率: 実際の1.2m × 1.2mアリーナで30回の走行テストを実施した結果、**86.7%（26/30回成功）**の高い到達率を記録。
• シミュレーションで学習した2,592個の純粋なQ-Tableパラメータのみで、実世界の物理ノイズを克服して自律走行を達成しました。

5. RL Q-Learning 連載シリーズの完結にあたって​

全5回にわたるRL Q-Learningプロジェクト開発日誌の連載が完結しました：

1. #1: 648状態空間の離散化モデリングとTCPソケットIPC通信設計
2. #2: Tabular Q-Learning ε-減衰探索と多目的報酬シェイピング
3. #3: 12壁障害物アリーナでの局所解脱出とHeadless高速化自動実行
4. #4: evaluate_qlearning による決定論的定量評価とDQN・SARSAとの性能比較
5. #5: Arduino Uno、Bluetooth通信、ArUco視覚追跡によるSim-to-Real実機展開

仮想シミュレータの構築から始まり、アルゴリズムの理論検証、大規模ヘッドレス自動化、そして実機組み込みハードウェアへの移植に至る強化学習ロボティクスの全工程を記録することができました。今後の新たなプロジェクト連載にもぜひご期待ください！

📌 キーポイント (TL;DR)

• 目的(Objective): 学習中の探索ノイズを排除した状態（ε=0）において、実機投入可能な決定論的ポリシー（Greedy Policy）の走行信頼性と経路品質を定量評価。
• 評価方法(Methodology): evaluate_qlearning.py を用いて5つの評価シードで合計30回の独立テストを実施。成功率、理論最短経路に対する走行効率、壁近接（Near-miss）頻度を精密測定。
• 成果(Result): 12壁障害物アリーナにおいて93.3%の決定論的成功率と0.02msの超低遅延を達成し、ニューラルネットワークベースのDQNやSARSAを凌駕する実用性を実証。

1. 定量的評価パイプライン設計 (evaluate_qlearning.py)​

学習中の報酬曲線には探索ノイズが含まれるため、実機に搭載する**決定論的ポリシー（$\epsilon = 0$）**の真の実力を測る専用の評価エンジンを構築しました。

flowchart LR
    Model["学習済みQテーブル<br>(qlearning_qtable.npy)"] --> Agent["Greedy Agent<br>(ε = 0 固定)"]
    EvalSeeds["5つの評価シード<br>(EVAL_SEEDS 0..4)"] --> Webots["Webotsシミュレータ<br>(30回反復テスト)"]
    Agent <--> Webots
    Webots --> CSV["ログ出力<br>(eval_log.csv / traces)"]

2. アルゴリズム比較: Q-Learning vs SARSA vs DQN​

同一のWebots障害物環境において、3種類の強化学習アルゴリズムをベンチマーク比較しました:

3. 次回予告​

次回最終第5回では、シミュレーションモデルを実際の Arduino Uno 2輪ロボットへ移植し、HC-06 Bluetooth通信、チェッカーボード歪み補正、ArUcoマーカービジョン追跡を組み合わせた Sim-to-Real の全容を公開します！

5月19日と20日の2日間は、3次ファインチューニング（fine_tuning_3）の評価自動化とともに、実際のアプリ（App）サービス構築のためのバックエンド/フロントエンド機能の高度化作業が並行して進められました。

3次ファインチューニングの締めくくりと自動化スクリプト​

以前のファインチューニングで得たインサイトをもとに、ナレッジグラフとオントロジーの概念を意識してセッティングした3次ファインチューニングの学習が完了しました。

「fine_tuning_3フォルダの実験モデルのうちBest Evalを持つチェックポイントを選別してadapterフォルダ内のファイルを入れ替えて。」

手作業でチェックポイントをコピーする代わりに、人工知能(AI)にスクリプトを書くよう指示して、最も性能の良いモデルの重み（Best Checkpoint）を自動で抽出してセッティングしました。そして並列推論スクリプトを実行し、評価をバックグラウンドサーバーに投げておきました。

バックエンド/フロントエンド：チャットボットDB保存と掲示板機能完成​

モデルがサーバーで推論を回している間、ローカル環境ではmental-health DBとアプリ連携作業に拍車をかけました。ログイン問題を突破するためにseed_data.sqlを解析し、パスワードのハッシュ化とユーザーデータを徹底的に検証しました。

その結果、5月20日の午後、意味深いGitコミットを一つ残すことができました。 feat: チャットボットDB保存、掲示板ページネーション、感情日記フィルター追加

ついに私たちがファインチューニングした大規模言語モデル(LLM)チャットボットの対話記録が、正式にDBに保存され始めました！さらに、コミュニティ掲示板のページネーション（Pagination）機能と、感情日記フィルター機能までフロントエンドへの実装に成功しました。目に見えなかった巨大なAIモデルが、ついにモバイルアプリという綺麗な器に盛られ始めた感激の瞬間でした。

📌 キーポイント (TL;DR)

• 課題(Problem): 壁の背後に目標がある場合、距離差分報酬(+0.1 × Δdist)の貪欲な性質により壁を迂回できず正面衝突を繰り返し閉じ込められる**局所解（Local Minima）**が発生。
• 解決策(Solution): 3方向超音波ヘッドスキャン（前方・左・右）状態情報と長期的割引率（γ=0.99）の結合 ＋ PowerShellによる**Webots Headless無人高速パイプライン（headless_run.ps1）**を構築し、3シード（Seed 0, 1, 2）の並列反復学習を実施。
• 成果(Result): 12壁障害物環境においても平均600エピソード以降に90%以上の安定した到達成功率を達成し、確実な迂回ポリシー（Detour Policy）の獲得を実証。

1. 障害物環境における課題: Local Minimaの罠​

障害物のない環境（no_obstacle）とは異なり、アリーナ内に**12個の壁障害物（obstacle12）**を配置すると深刻な走行ボトルネックが発生しました。

flowchart TD
    Start["出発点 (Robot)"]
    Wall["壁障害物 (Wall)"]
    Goal["目標地点 (Goal)"]
    
    Start -->|"直進（距離短縮を優先）"| Wall
    Wall -.->|"衝突＆スタック（局所解）"| Wall
    Start ==>|"迂回ポリシー（Detour）<br>一時的な距離後退を許容"| Goal

• ジレンマ: 目標が壁の向こう側にある場合、目標へ直進しようとすると必ず壁に衝突します。
• 報酬の逆効果: 迂回するためには一時的に目標から離れる（負の距離報酬）必要がありますが、近視眼的な行動はこれを避けるため、壁の前で空転するかタイムアウトするデッドロックに陥ります。

2. 解決戦略: ヘッドスキャン状態と価値の逆伝播​

この局所解を克服できた要因は、**3方向障害物センサ（前方・左・右）と高い割引率（γ = 0.99）**の組み合わせです。

1. 知覚状態の拡張: 前方危険時に左右のヘッドスキャンで安全な方向を発見し、横方向への旋回を誘導。
2. 長期的価値の伝播: 一時的な距離の後退があっても、壁を回って目標へ到達すれば大きな終端報酬（+1.0）が得られます。割引率 γ = 0.99 により、迂回行動の価値が逆順にQテーブルへ反映され、エージェントは迂回ポリシーを獲得します。

3. Webots Headless 自動化パイプライン​

複数シード（Seed 0, 1, 2）による実験を効率化するため、GUIレンダリングを無効化した超高速モード（--mode=fast --no-rendering）を実行する headless_run.ps1 を構築しました。

4. 学習曲線の比較分析​

障害物なし環境と12壁障害物環境の比較結果:

• 最終到達成功率: no_obstacle の98.5%に対し、obstacle12 では 91.4%〜94.8% を達成。
• 平均ステップ数: 直進主体の15〜22ステップから、迂回を含む 38〜52ステップ へと適応。

5. 次回予告​

次回第4回では、保存されたモデル（models/*.npy）を読み込み、純粋な決定論的走行の定量的評価を行う evaluate_qlearning.py ベンチマークおよびDQN/SARSAとの性能比較をお届けします！

📌 キーポイント (TL;DR)

• 課題(Problem): 目標到達(+1.0)と壁衝突(-1.0)のみが与えられるスパース報酬（Sparse Reward）環境では、エージェントが偶然目標に遭遇するまで数千エピソードにわたり彷徨や空転を繰り返す。
• 解決策(Solution): 目標とのユークリッド距離の変化量に比例するポテンシャル報酬(+0.1 × Δdist)と、ステップ(-0.01)、旋回(-0.01)、後退(-0.05)ペナルティを組み合わせた**多次元報酬シェイピング（Reward Shaping）**を設計。指数減衰ε-Greedy（1.0 → 0.05）戦略を適用。
• 成果(Result): 障害物のない環境（no_obstacle）において500エピソード以内に移動平均報酬が正の値（0.7+）へ到達し、最終的な目標到達成功率98%以上を達成。

1. 表形式Q-Learning更新数式とエージェント設計​

表形式Q-Learning（Tabular Q-Learning）は、ベルマン最適方程式に基づく**オフポリシー（Off-policy）時間差学習（TD(0)）**アルゴリズムです。

エージェントは行動価値関数 Q(s, a) を表す $648 \times 4$ のNumPy配列を保持し、環境からの遷移タプル $(s, a, r, s', done)$ を受け取って以下の数式でQ値を更新します。

📐 Q-Learning TD(0) 更新式​

Target = r + γ * max_a' Q(s', a') * (1 - done)
TD Error = Target - Q(s, a)
Q(s, a) <- Q(s, a) + α * TD Error

• 学習率 (α = 0.1): 新しい経験が既存のQ値に反映される速度を調整。
• 割引率 (γ = 0.99): 将来得られる報酬の現在価値を評価。
• 終端状態処理 (1 - done): 目標到達や衝突時に将来価値をゼロにマスキング。

2. 指数減衰ε-Greedy戦略​

初期学習時は環境の構造を広く知る必要があるため、**ε = 1.0 (100%ランダム探索)**から開始します。

探索率が高すぎると最適な経路を学習しても壁に衝突し続けるため、各エピソード終了時に以下の指数減衰を適用します:

ε_(ep+1) = max(ε_min, ε_ep × 0.995)

• 1エピソード: ε = 1.0
• 300エピソード: ε ≈ 0.22
• 600エピソード: ε = 0.05 (下限到達、95%確率でGreedy行動を実行)

3. スパース報酬を克服する報酬関数の設計​

4. 学習曲線と成功率の検証​

1,500エピソードの学習を実施した結果、理論通りの収束を確認しました。

100回移動平均成功率は 98.5% を超え、エピソードあたりの平均ステップ数は150（タイムアウト）から 15〜22ステップ まで大幅に短縮されました。

5. 次回予告​

次回第3回では、12個の壁が配置された obstacle12 および高難易度 obstacle_hard 環境における局所的最適解（Local Minima）の罠と、複数シード並列学習について解説します！

📌 キーポイント (TL;DR)

• 課題(Problem): 連続的なセンサ距離・角度値による表形式Q-Learning（Tabular Q-Learning）の状態爆発と、Webotsシミュレータと外部Python学習スクリプト間のリアルタイム同期の負荷。
• 解決策(Solution): 5次元の連続センサ入力を幾何学的な意味を持つ区間に分割し、3 × 8 × 3 × 3 × 3 = 648個の離散状態（Bin）にマッピング（discretizer.py）。TCPローカルソケット（Port 5000、Line-delimited JSON）によるIPC通信パイプラインを構築。
• 成果(Result): O(1)の超高速Q-Table更新速度を確保し、32ms物理シミュレーションステップに適合した安定同期ループを実現。

1. プロジェクト背景: なぜWebotsとQ-Learningなのか？​

自律走行ロボットが未知の室内環境で障害物を回避しながら目標地点（Target Goal）へ到達することは、ロボティクスにおける古典的かつ重要な課題です。深層強化学習（DQN、PPOなど）は複雑な環境に対応できる反面、計算資源の負荷が高く、モデル重みの解釈性（Interpretability）が低いという課題があります。

本プロジェクトでは、**数学的収束性が保証された最も直感的な表形式強化学習（Tabular Q-Learning、Off-policy TD(0)）**をWebots 3D物理シミュレータ上の差動駆動モバイルロボットに適用し、1.2m × 1.2mの室内アリーナでの安定した目標探索および障害物回避ポリシーの獲得を目指しました。

2. 全体システムアーキテクチャ (Webots ↔ Python IPC)​

システムは、**Webots物理環境コントローラ（Server）と強化学習アルゴリズムを実行するPythonクライアント（Client）**の2層に明確に分離されています。

flowchart LR
    subgraph Webots["Webots 3D シミュレータ (localhost:5000)"]
        Robot["Supervisor ロボット<br>(超音波センサ + 車輪)"]
        HeadScan["ヘッドスキャン機構<br>(左右 1.1 rad サーボ回転)"]
        Server["TCP ソケットサーバ<br>(Line-delimited JSON)"]
        Robot -→ HeadScan -→ Server
    end

    subgraph Python["Python RL エンジン (Client)"]
        Env["WebotsEnv (gym-like)<br>reset() / step()"]
        Disc["Discretizer<br>(連続値 → 0~647 Bin)"]
        Agent["QLearningAgent<br>(Q-Table 648x4)"]
        Env -→ Disc -→ Agent
    end

    Server <-→|"request: {type: step, action: 0..3}<br>response: {state: [...], reward, done}"| Env

• Webotsコントローラ (RL_controller.py): アクション実行ごとにロボット車輪を480ms（15 ticks × 32ms）駆動し、サーボモータでヘッドを左右1.1 rad（$\approx 63°$）回転させて死角の障害物距離を正確にスキャンします。
• ソケット通信プロトコル: 改行区切りJSON（Line-delimited JSON）を採用し、通信オーバーヘッドを最小化。
  • リクエスト: {"type": "step", "action": 0} (0: 前進, 1: 後退, 2: 左旋回, 3: 右旋回)
  • レスポンス: {"state": [0.45, 0.12, 0.35, 0.28, 0.40], "reward": 0.05, "done": false, "info": {...}}

3. 連続センサの648状態空間（Bin）設計​

連続的な浮動小数点データを表形式Q-Learningで扱うため、幾何学的に重要な5つの観測変数を以下のように定義・分割しました。

総状態数: N_states = 3 × 8 × 3 × 3 × 3 = 648

これにより、Q-Tableのサイズはわずか 648 × 4 = 2,592要素に大幅圧縮され、PCメモリ上でミリ秒未満の更新が可能となりました。

4. ヘッドスキャン機構と衝突判定​

1. 移動実行: 車輪モータを3.0 rad/sで480ms駆動。
2. ヘッド回転: 左へ+1.1 rad回転して左距離測定後、右へ-1.1 rad回転して右距離測定。
3. 正面復帰: 0 radへ戻り前方距離を更新。
4. 終了判定:
   • 目標到達: 目標との距離 ≤ 0.10m → 成功 (done = True, 報酬 $+1.0$)
   • 壁衝突: いずれかの距離 ≤ 0.08m → 失敗 (done = True, 報酬 $-1.0$)

5. 次回予告​

第1回では、Webots仮想環境の構築、TCPソケットIPC通信、648状態空間の離散化をまとめました。

次回第2回では、Tabular Q-Learningの数式実装、ε-Greedy探索減衰戦略、シミュレーション環境での報酬関数（Reward Function）チューニングを詳しく解説します！

以前「5月13日がマウムジギ5月開発の最後になるだろう」と勘違いしていたことを訂正します！5月17日、ものすごい量のバックエンド連携テストとレポート作成作業が押し寄せました。

人工知能(AI)を活用したファインチューニング結果レポートの自動化​

2次ファインチューニング（fine_tuning_2）の膨大な結果グラフを一つずつ人間が分析して書くには時間が足りませんでした。

「モデルの推論結果を比較するレポートを作成するためのプロンプトを作って。それに従ってレポートを作成して。」

AIに結果指標を解釈させ、レポートの草案を自動で作成させるプロンプトエンジニアリングを試みました。結果として、AIが各モデルの長所と短所を分析し、立派なWord（.docx）レポートの草案を出力してくれました。

バックエンドDB連携と401 Unauthorizedの沼​

レポートが終わるやいなや、システム安定性をテストするためにbackup.sqlデータをローカルのPostgreSQL DBに流し込む作業を始めました。

「ログイン成功したのにメニューを押しても反応がない」 「パスワードが間違っています... INFO: POST /auth/login 401 Unauthorized」

DBダンプを流し込むことには成功しましたが、ログインできない401 Unauthorizedエラーの地獄に陥りました。debug_login.pyを作成し、uvicornサーバーを再起動させながら数十回のトラブルシューティングを行いました。

ナレッジグラフ（Knowledge Graph）の導入検討​

深夜、単純な大規模言語モデル(LLM)ファインチューニングの限界を克服するために、オントロジーとナレッジグラフ（Knowledge Graph）を融合する方案を新たに悩み始めました。5月中旬を過ぎて、プロジェクトの規模がますます巨大になっています！

昨日発見したハードコーディングのバグをすべて修正し、ついにまともな2次ファインチューニングモデルの推論（Inference）テストを再開した5月13日です。

短い回答の原因、トークンの長さを増やせ！​

推論結果を一つ一つ紐解いていたところ、Llama33-70B_a8モデルが出した回答が相変わらず妙に短く、硬いことに気がつきました。

「これはLlama33-70B_a8の回答の一つです。max_seq_lengthとmax_new_tokensが少なすぎると感じます。増やしたいです。VRAMの現状を見ると、どれくらい増やせますか？」

人工知能(AI)とVRAMの空き容量（当時39.8GB）を計算した末、生成できる最大単語数であるmax_new_tokensを384に思い切って上方修正しました。結果は大成功でした！

単にトークンの許容量を増やしただけなのに、モデルが文脈を最後まで維持し、はるかに深く温かい共感の文章を注ぎ出し始めました。限られたトークン数に閉じ込められ、モデルが自ら言葉を出し惜しんでいたのです。

Alpha値の比較分析（a=8 vs a=16）​

2次ファインチューニングの最大の目的であったLoRAハイパーパラメータalpha値による性能差の結果も出ました。ログを分析して05_alpha_comparison_daily.pngなどのグラフを生成しました。rank=16に固定された状態でalpha=8を与えた時とalpha=16を与えた時で、モデルの過学習（Overfitting）の様相と最終回答の質がどう変わるのかを明確に視覚化することができました。

結果として、正しいハイパーパラメータと十分なトークンの長さを与えられたモデルたちは、ついに私たちが当初企画していた「真のマウムジギ」の姿に近づいていました。中間発表の準備がとても順調に終わりそうです！

LoRAハイパーパラメータのミス（alpha/rank設定エラー）を正すために野心的に始めた2次ファインチューニング（fine_tuning_2）並列学習が、5月12日ついに終わりました！

Bestチェックポイント抽出と推論パイプラインの構築​

3つのモデルに対して6つのハイパーパラメータの組み合わせで回したファインチューニングがすべて完了しました。すぐにeval_lossを比較して最も性能が良い最高（Best）のチェックポイントを抽出し、モデルごとのadapterフォルダに移す作業を進めました。

「現在HCX-Text-1p5Bモデルが15分間で12個生成しました。GPU Utilは各グラフィックカードにつき1.6GB...」

しかし、推論速度は依然として絶望的でした。最も軽い1.5Bモデルでさえ、1分間に1つの回答も作成できていませんでした。VRAM使用量は1.6GBしかないのに、バッチサイズが1に設定されているためボトルネックが発生したのです。さらにサーバーの容量不足問題まで重なり、プロジェクトの基本パスを急いで移行する騒動もありました。

ハードコーディングの罠に陥る​

そうやって苦労して評価コードをすべて回した後、鳥肌が立つような事実を発見しました。

「なぜ20_eval_ft_models.ipynbのMODEL_ALIAS = 'Qwen35-9B_a16'のように1つのモデルにハードコーディングされているのか？」 「ファイル名とモデル名が違うのが正常だということ？」

そうです。評価自動化スクリプトを作成する際に、誤ってMODEL_ALIASをハードコーディングしてしまったのです。HCXモデルをテストすると言ってファイルを一生懸命コピーして回していましたが、実際のコード内ではずっとQwen35-9B_a16モデルばかりを呼び出して、同じ推論を繰り返していたのです！明日このバグを修正して推論をやり直さなければなりません。

5月8日は、これまで抽出したファインチューニングの結果を基にキャップストーンデザインの中間発表資料（PPT）を作成していた日でした。しかし、気分良くスライドを埋めていたところ、背筋が凍るようなとんでもないミスを発見してしまいました。

LoRAハイパーパラメータの致命的なミスを発見​

PPTに入れるモデル構造図とハイパーパラメータ情報を人工知能(AI)と一緒に手直ししていました。

「ファインチューニング結果の例を見ると、base modelよりも回答が短くなっています。これはLoRAのrを8にし、alphaを16にして中間特徴量を減らしすぎたためだと思いますが...」 「え、a/rだったの？私はr/aだと思ってたんだけど...??? 私は本当にLoRAを欲張って反映してしまったんだな...」

LoRAファインチューニング時、alpha値は通常rank値と同じか2倍にするのが定石です。ところが、計算式の適用比率を完全に逆だと勘違いし、重みの更新が極端に抑え込まれたり、過剰に跳ね返ったりするように設定してしまっていたのです。どうりでファインチューニングされたモデルの回答の長さが途切れ途切れで短くなるわけだ、原因は私の手元にありました。

2次ファインチューニング（fine_tuning_2）の決断​

すでに1次結果は出ていましたが、完璧な「マウムジギ」のためにこのまま進むわけにはいきませんでした。すぐにfine_tuning_2フォルダを作成し、2次ファインチューニングを決断しました。

「今回使用するモデルはHCX-Text-1p5B, Llama33-70B, Qwen35-9Bです。MIG-0ではrankは16、alphaは16に、MIG-1ではrank=16、a=8に設定して学習を進めて。」 「Daily_train_dataset.jsonlから最も長いデータ上位2000個を抽出して、Daily_train_dataset_long.jsonlというタイトルのファイルを作成して。」

回答が短くなる現象を防ぐために、テキストの長さが最も長い上位2000個のデータセットのみを別途抽出し、MIG（Multi-Instance GPU）リソースを分割してrankとalphaの比率による性能差を直接比較する並列学習を新たに回し始めました。

バックエンドモデルが回っている間、フロントエンド（アプリ）開発に着手​

モデルが再び学習のサイクルに入っている間、私はただ手をこまねいていたわけではありません。ついに実際のユーザーが「マウムジギ」に出会うことになるフロントエンドアプリの開発に着手しました！

「maeum-appを起動するためにQRコードを表示しなければならないんだけど... npx go startと入力してもエラーメッセージしか表示されない。どうやって、そしてどこにQRコードが表示されるのかな？」

React Native（Expo）を使ってmaeum-appプロジェクトを作成し、ローカルサーバーを立ち上げてスマートフォンと接続しようと奮闘しました。見当違いにnpx go startと打ち込んで迷ったりもしましたが、ついにExpoのQRコードを表示し、アプリアイコン（assets/logo.png）を設定することに成功しました。バックエンドの頭脳（AI）とフロントエンドの顔（App）が同時に作られていく、胸が熱くなる一日でした。

5月7日は、これまで苦労してファインチューニングした計5つのモデル（Llama3.3-70B, DSR1-70B, HCX-Omni-8B, Qwen35-9B, HCX-Text-1.5B）の結果を集大成し、本格的な視覚化とローカル環境の構築を進めた日です。

モデル比較のための視覚化とローカル環境設定​

これまで重いサーバー上で回していた結果比較コードを、個人のノートパソコンでも簡単に確認できるように、新しく31_comparison_local.ipynbノートブックを作成しました。

「30_comparison.ipynbは私のノートパソコンでも動かせるのではないか？」

VSCodeでローカルのJupyterカーネルを設定し、必要なライブラリをインストールする過程で、頻繁なカーネルのクラッシュやModuleNotFoundErrorのようなエラーに直面しましたが、フォルダパスを合わせながら一歩一歩解決していきました。

5モデル総合レポートとグラフ視覚化​

最も重要な作業は、これら5つのモデルのパフォーマンスを一目で比較できる視覚化でした。AIと共に計画書を作成し、体系的にデータ整理を始めました。

「薄い線と太い線の違いは何か？各モデルのtraining lossとeval lossを取得してグラフとして視覚化して。」 「太い線は消して、薄い線をはっきりと変更して保存して。」

AIが描いてくれたmatplotlibのグラフから不要なトレンド線（太い線）を取り除き、モデルごとのTraining LossとEval Lossの曲線をきれいに1か所にまとめた03_training_loss_all.pngと04_eval_loss_all.pngを最終的に抽出しました。

これらのグラフを基に、来週のキャップストーンデザインの中間発表資料を立派に飾ることができるようになりました。果たして、この5つのモデルのうちどれが最も優れた「マウムジギ」チャットボットとして最終選定されるのでしょうか？