SYSTEM ARCHITECTURE / PHASE 04

システム構成設計書

iPhoneを操作画面に、本機をゲーム世界の管理場所に。

承認済み・技術検証は別途継続v1.0 / 2026年9月25日
後続の優先変更:iPhone連携はPC版の後。

2026年9月29日の指示により、同じWi-Fi接続・端末間共有・Safari実機受入を低優先へ移した。以下は承認時の構成設計として保持する。現在の実装との差とPCでの保存改善は、最新の作業報告で管理する。

01 — 推奨する構成と前提

iPhoneのブラウザー+Windows上のゲームサーバー+SQLiteを推奨する。ゲーム処理を一つのサーバー内の機能別モジュールにまとめ、対話相手はプログラムを基本とし、ChatGPT連携を追加候補とする。ローカル生成AIプロセスは設けない。個人利用のため、初版からクラウドや複数サーバーに分ける必要はない。

利用前提:同じWi-Fiでの利用を確認済み

ユーザーの回答により「PCを起動し、同じWi-Fi上のiPhoneで遊ぶ」を採用する。PC停止中はプレイできない。外出先利用・iPhone単独動作は初版の接続要件に含めない。実機での接続動作はまだ未検証。

今回は設計資料を作成し、既存環境を読み取り確認した。アプリのインストール、モデルのダウンロード、サーバーの公開、ファイアウォールの変更はまだ実施していない。

02 — 配置と責務

推奨構成:ゲームの状態はPC側を正本にする
iPhone 17e / Safari画面・入力・結果表示
React + TypeScript/ゲーム状態を直接計算・確定しない
↓ 操作要求・更新番号  ↑ 結果・進捗・最新状態
同一Wi-Fi・同一オリジンのAPI接続
Windows PC / FastAPI認証・入力検証・コマンド受付・画面データ配信
クラブ/選手/契約/試合/育成/商業の各モジュール
ゲーム計算ワーカー日次進行・試合
ルール版+固定した乱数
SQLite+素材フォルダーセーブ・イベント・契約
公式画像・独自デザイン
対話相手モジュールルール+文章テンプレート
ChatGPT連携は追加候補

ゲーム計算ワーカーと対話相手モジュールは結果を返し、ゲーム状態の書込みはサーバーの更新経路に集約する。対話プロバイダーにDB更新権限を与えない。Safariがバックグラウンドになっても、再表示時に処理結果を照会できる。

03 — 本機の確認結果と技術選定

確認対象実測・確認した内容設計への影響
OS・CPUWindows 11 Home / Intel Core i7-1165G7Windowsのローカルプロセスで実行。Dockerは必須にしない。
メモリ・GPU搭載メモリ約15.7GiB / Intel Iris Xe Graphicsローカル生成AIは使わないため、モデル推論用GPUやモデル用メモリの確保は不要。
開発環境Node.js 18.16.0、Python 3.11系、Gitが利用可能。FastAPI・Uvicornは現在のPythonに未導入。プロジェクト専用環境を用意する。現在のNodeは新しいViteの要求を満たさない。
保存・AIPython付属SQLite 3.40.1。OllamaはPATH上で見つからず。ローカルAIの導入は行わない。SQLiteと会話プログラムの動作を検証する。

2026年9月25日にOS情報とコマンドを読み取り確認。GPUの共有メモリ総量やAI推論速度は未測定。PATH検索はPC全体のインストール有無を保証しない。

役割採用案理由・確認事項
操作画面React+TypeScript、Viteでビルド多数の画面・状態を共通部品で扱う。ReactはMITライセンス。ViteのNode要件を満たす環境をプロジェクト用に用意し、既存のNodeを無断で置換しない。
API・ゲーム処理Python+FastAPI+Uvicorn数値計算とゲームルールをPythonにまとめる。FastAPIはMIT。単一APIプロセス+計算プロセスを基本にする。
保存SQLite+Pythonのsqlite3個人利用で独立DBサーバーを不要にする。トランザクションで契約・決済の一括更新を行う。
対話相手ルール・状態遷移・テンプレート+任意のChatGPT連携無料・本機実行で運営が完結する。ChatGPTは対応アカウント・実機・費用条件を確認して採用する。ローカル生成AIと有料APIは必須にしない。
ユニフォーム生成ユーザー指定・プログラムによる配色/模様案+SVGテンプレート本機のGPU性能に依存した画像生成を必須にしない。許可したパラメーターだけを描画し、公式ロゴ素材と独自デザインを区別する。

選定根拠:Reactのライセンス、FastAPIのライセンス、Viteの動作要件、SQLiteのトランザクション、SQLiteの利用条件。依存関係の版と条件は導入時に固定・記録する。

04 — リクエスト・計算・保存

同じ操作を再送しても一度だけ確定する
  1. 操作受付操作ID・状態の版
  2. 検証・計算予算・期限・ルール
  3. 一括保存結果・履歴・新しい版
  4. 結果を返す再送時は同じ結果
API例用途と境界
GET /api/saves/{id}/overview日付・未処理通知・状態版・処理中ジョブを返す。
POST /api/saves/{id}/commands戦術変更、移籍提案、契約合意、練習変更など。type / payload / expected_revision / command_idを検証。
POST /api/saves/{id}/advance次の停止点まで進行。処理開始は202とjob_id、入力不備は422、状態競合は409。
GET /api/jobs/{id}待機・実行中・完了・失敗と進捗、確定後の状態版を返す。
GET /api/matches/{id}/eventsカーソル付きの経過とスタッツ。途中経過にも対応。
POST /api/saves/{id}/backup整合したバックアップを作成。完了時にファイルを取得できる。

失敗時の応答にはエラーコード・ユーザー向け説明・再試行可否を含める。AI生成文をHTMLとして直接描画せず、テキストまたは検証済みの構造として表示する。

05 — セーブと復旧

実在データは版を固定した収録DB、プレイはセーブ単位のDB、素材はハッシュ付きファイルとして管理する。セーブDBに世界の状態、イベント、契約、台帳、ジョブ、乱数、スキーマ・エンジン版を保持する。

SQLiteの稼働中バックアップは公式Backup APIを利用する案。データベースの一部ファイルだけをコピーする方式にはしない。

06 — iPhoneからの利用と接続

方式利用条件本設計の扱い
同一Wi-FiのWebアプリPC起動と同一ネットワークが必要。初版の推奨案。PCから画面とAPIを同一オリジンで配信。
外出先からPCへ接続PC起動と安全な到達経路が必要。希望がある場合、無料・OSSの接続方式を別途検証。自動でインターネットへ公開しない。
iPhone単独で動作計算・保存を端末へ移す必要がある。別構成。ローカル対話やデータ容量も再設計する。

LAN上でも短期のペアリングコードで利用端末を登録し、セッション、Origin確認、変更APIのCSRF対策、アクセス範囲を設ける。実利用には端末が信頼するHTTPS経路を用意して接続検証する。HTTPでの接続確認を行う場合は、仮のデータでの到達性検証に限定する。

PWA化はHTTPS・実機確認後の追加とする。Service Workerは安全なコンテキストが必要で、PCのLANアドレスをiPhoneから開くことはlocalhostの例外とは異なる。MDNの仕様説明。PWAにしてもPC側の計算がオフラインで動くわけではない。

07 — 実在情報・公式画像の調達設計

対象はマンチェスター・ユナイテッド/プレミアリーグ2026–27に確定。取得済みの完全なデータセットがあるとは扱わない。まず公式クラブ・リーグ・スポンサー発表などを候補に、項目別の出典と利用条件を確認する。無料で閲覧できることと、素材・データの利用条件は区別する。

対象候補と取得方針不足時の扱い
選手・所属・日程クラブ・リーグの公式情報。基準日、安定ID、名寄せ、所属期間を記録。不明を明示。別の公式発表を確認し、対象範囲変更が必要なら再合意。
能力・成長FC26の能力値・総合値・ポテンシャル・市場価値を初期値に採用。SoFIFAを優先参照。版・日付・原値・単位を保持。FC26版の取得可否を確認し、旧版は無断で混在させない。
スポンサー・契約クラブと企業の公式発表。相手、期間、カテゴリ、公開された金額。金額などの非公開条件はゲーム用推定。実在の確定情報と混在させない。
公式画像プレミアリーグ公式サイトを第一参照先として、選手写真・クラブアイコン・リーグアイコン・スポンサーロゴを選定。画像URL、寸法、形式、出典、条件、更新日を台帳化。取得可否を個別確認。検証中は「画像未取得」と表示し、代替を公式と称しない。初版要件の充足は別途判断。
独自ユニフォームゲーム内の配色・模様・配置と、確認した公式ロゴ素材を合成。独自作成と明示。生成案に存在しない公式契約や公式採用を付与しない。

公式情報の調達候補として、クラブ公式パートナー一覧とプレミアリーグ公式2026–27日程の掲載ページを確認した。契約の全条件、選手写真の取得・利用条件、完全な初期データは未検証。
取込手順:候補収集 → 利用条件の確認 → 正規化 → 重複・所属・契約期間の検査 → プレビュー → データ版の確定。進行中のセーブには現実の移籍を自動上書きしない。

08 — 対話相手:プログラムとChatGPTの接続

自チームの担当者はユーザー。コンピュータは対話相手だけを担当する。相手役の発言・条件提案を生成する共通インターフェースを設け、プログラムとChatGPTのどちらでも同じ契約検証・履歴を利用する。

基本経路と追加候補
ユーザーの発言・条件提示iPhoneのゲーム画面、または連携時のChatGPT会話
↓ 同じ交渉ID・条件版で管理
基本:プログラム意図選択+条件入力
相手の評価・対案・定型文
追加候補:ChatGPTユーザーと相手役が会話
MCP経由でゲームと接続
ゲームサーバー予算・契約を検証
ユーザーの最終承認を確認

プログラム方式は、相手の希望・交渉段階・提示条件・関係性から次の行為を決め、テンプレートで返答する。情報不足なら質問し、必須条件を満たさなければ対案または拒否を返す。ユーザーの発言を自動作成・送信せず、ユーザーの最終承認を相手役の出力から成立させない。

ChatGPTからゲームのMCP機能を呼び出す公式経路は存在する。OpenAI公式の接続手順。これはChatGPT上の会話から接続する仕組みで、独立したゲーム画面からChatGPTアプリを無料の推論APIとして呼べると確認したものではない。

私設サーバーへの接続にはSecure MCP Tunnelも案内されているが、PlatformのAPIキー・権限などが必要。公式の前提条件。現在のアカウント、iPhoneアプリ、追加費用なしでの利用可否は未確認。ローカル生成AIの導入や有料APIへの置き換えは行わない。

連携案では、ChatGPTが会話の相手役を担当し、MCPのget_negotiationで状態を読み、submit_counterparty_turnで相手の発言と提案を返す。ユーザー側の契約確定はゲーム画面の明示操作に残す。相手用ツールにユーザーの承認権限を渡さない。プレイ世界の必要最小限の会話情報だけを渡す。接続・送信はまだ行っていない。

ChatGPT連携を使えない、または追加費用が必要な場合は、ユーザーが許可したプログラム方式を採用する。初版の成立をChatGPTへの接続に依存させない。SNS・試合分析はイベントに基づくテンプレート、ユニフォームはルールで配色・模様を作り、ChatGPT連携が利用可能なら提案を補える。

09 — 技術検証と実装の順序

検証・制作単位完了の判断現在
V1 本機環境CPU・RAM・GPU・主要ランタイムを確認。確認済み。性能ベンチマークは未実施。
V2 実機接続iPhoneから認証・画面・API・再接続・保存を確認。同一Wi-Fiで確定/接続は未検証。
V3 データ・画像対象クラブの少量サンプルで、実在情報と公式素材の出典・条件・表示を検証。対象確定・公式情報の候補ページを確認/データ・画像は未取得。
V4 対話相手プログラムで交渉が成立・破談まで進むことと、ユーザー側の発言・承認を代行しないことを確認。ChatGPT連携は別途実機で確認。公式接続経路を確認。プログラム実装とアカウント・実機での接続検証は未実施。
V5 保存・ゲーム計算中断復帰・再送・二重決済防止・同じ入力での再現を確認。方式設計済み/未実装。
V6 画面設計との整合主要操作・状態表示・APIの過不足を画面試作で確認。工程③の制作で確認。

目標値案:LANの通常操作は1秒以内、画面の初回利用は3秒以内、1試合の計算は5秒以内。AIは非同期。これらは測定結果ではなく、実装後に本機・実機で測る目標。超過時は理由と調整案を示す。

設計合意後の制作順は、環境・保存・接続 → 試合と編成をつないだ試作 → 移籍と他クラブ → 育成・練習・関係性 → 商業・SNS・AI → 1季の総合検証。機能を初版から削る順序ではない。

10 — 承認した構成と残る検証

  1. PCを状態・計算・保存の中心にし、iPhoneからWeb画面を操作する案。
  2. React/Python・FastAPI/SQLiteを基本とし、プログラムの相手役を基本とし、ChatGPT連携を候補にする案。
  3. 現実の出典とゲーム内状態、公式画像と独自デザインを区別して保持する案。
  4. 設計は承認済み。接続・データ・対話の検証を継続し、結果によって設計変更が必要になった場合は影響を示して合意する。
M4 設計合意:完了(2026年9月25日)

ユーザーが機能概要とシステム構成設計を承認。実機接続・画像調達・対話機能などの検証は未完了であり、管理資料で別途追跡する。設計承認を動作検証済みとは扱わない。

11 — 対話基盤・素材選定・画面参照の追加設計

会話処理の契約

Conversation(場・参加者・公開範囲)、Message(話者・本文・元イベント)、Negotiation(段階・条件版・合意状況)、Terms(移籍金・給与・期間・役割など)、Memory(約束・経緯)を保存する。POST /api/conversations/{id}/messagesはmessage_id、expected_terms_revision、本文を受け、選択された対話プロバイダーへ処理を渡す。プログラム方式では即時のルール評価、ChatGPT方式では相手ターンの受信を待つ。返答は台詞、行為、条件差分、根拠ID、必須確認項目を持つJSONとする。

検証に失敗した返答は条件表へ適用せず、修正を一度試みた後に保留する。表示された合意文だけで契約を成立させず、条件版に紐づく確定コマンドを使用する。ユーザーの自由入力や取込記事から、システム指示・金銭処理・非公開の相手評価が上書きされないよう役割とデータを分離する。

データと素材の参照先

SoFIFAの選手一覧を能力・市場価値の参照候補として確認した。検索結果に現れた版は「FC26 / 2026年7月23日」で、ルートページの取得も失敗した。ユーザーがFC26版の採用を許可したため、参照候補として進める。実データ取込は未完了。取得できたと仮定して設計・資料を埋めない。

画像はプレミアリーグ公式を第一参照先とする。スポンサーなど必要素材が揃わない場合は、クラブ・企業の公式素材を補完候補として記録する。画面を切り抜いたサムネイルではなく、掲載元が提供する原画像・高解像度版を選定する。

素材選定基準検証項目
クラブ・リーグアイコン公式SVGを優先。ラスターなら最大表示サイズ×端末の画素密度を満たす原寸。透過、輪郭、余白、縦横比、明暗背景での視認性。
選手写真公式プロフィール写真を優先。高解像度・同じ構図で揃え、顔や頭部を欠かさない。選手ID・所属・基準日、切り抜き品質、拡大時のぼけ。
スポンサーロゴ公式のベクターまたは十分な解像度の透過画像。白抜き・カラー版の用途を区別。契約の掲載枠、原色・比率、小さなシャツ表示での可読性。

解像度の目安は、たとえば200 CSS pxの表示なら3倍密度用に600px以上。これは選定の基準例で、実機の必要サイズは画面設計で決める。画像を無理に拡大して高解像度と扱わない。元画像を保持し、表示用の軽量版を別途作る。素材台帳にはファイルの寸法・容量・ハッシュ・出典・用途・採否理由を残す。今回、画像の取得・解像度検査・見た目の選定はまだ行っていない。

SNS・スタッツ画面の参考

Sky Sports Footballとプレミアリーグのスタッツを工程③のデザイン参照にする。サイトのニュース・試合・スタッツの情報構成を確認した。具体的な配色・余白・モバイル表示の視覚比較は画面設計で行う。

追加する技術検証

FC26データ版と単位の確認/公式素材の原寸・透過確認/AI交渉の多ターン一貫性・条件抽出・再開/曖昧な金額への聞き返し/同意なしの契約確定を防ぐ検証/スポンサー変更時の新旧ユニフォーム版の保持/重要場面以外で試合が停止しないこと。これらはM4・試作段階の検証項目として追跡する。

12 — 承認の記録

2026年9月25日、ユーザーがシステム構成設計を明示的に承認。PCサーバー・iPhone・同一Wi-Fi・SQLiteを基本方針として継続する。同時指示でローカル生成AIを撤回し、ChatGPT連携候補/プログラム方式へ更新。設計の承認と、未完了の技術検証は分けて管理する。

13 — 試合計算の粒度の改訂

2026年9月26日:試合ワーカーは時間帯の集約評価と重要イベントを扱う。個別のピッチ動作・座標のエンジンは作らない。PC・iPhone・SQLite・保存と再現性の基本構成は維持する。初版ブランドは2026年9月26日にTOUCHLINEを採用。共通の名称・配色・アイコンはブランドメタ情報を参照する。

追加指示:情報源・采配・戦術・一日の体験

2026年9月26日:選手メタ情報(氏名・生年月日・国籍・所属・背番号・ポジション・写真・公開実績)はプレミアリーグ公式サイトを基準とする。公式FPLのID・写真は照合補助とし、本体収録では選手・クラブ公式ページとシーズン基準日を確認する。SoFIFAは従来合意したFC26の能力・ポテンシャル・初期市場価値に限定し、メタ情報を補完しない。不明項目は未確認と記録する。

75分の定時停止は撤回。得点・退場・負傷・ハーフタイム等の必要な場面と任意の一時停止で采配する。戦術は保持・非保持の配置、チーム指示、個人役割、切替、セットプレー、相手別対策まで詳細化。試合後は履歴から得点者・個人成績・チーム統計を再確認する。

一日はボタン一つで練習を消化する方式にせず、状態確認、計画、選手への伝達、実施中の観察と対応、結果と振り返り、午後の商談・視察・関係づくりを扱う。毎日同じイベントを繰り返す完成仕様にはせず、疲労・試合間隔・人物・計画に応じて変化させる。今回の試作はその1日の例。