Chat-Core システムデザイン完全ガイド｜実装構成からスケール設計・面接対策まで

1. この文書の目的

図は外部画像に頼らず、ページ内で完結する形で示しています。本文と図を合わせて読むと、「画面」「API」「業務処理」「データ保存」「外部サービス」がどのように協力しているかを追えます。

2. Chat-Coreは何をするシステムか

Chat-Coreは、複数の大規模言語モデルを使って会話するサービスを中心に、会話を整理し、再利用し、他の利用者や外部のAIサービスと安全に連携するための機能をまとめたWebアプリケーションです。利用者から見える主な価値は、次の四つの方向に整理できます。

3. まず覚えるべきシステムの部品

システム設計では、処理を役割ごとに分けて考えます。Chat-Coreを大きく分けると、次の部品があります。

4. 全体構成

利用者のブラウザ
    │
    │ HTTPS、Cookie、JSON、SSE
    ▼
公開入口（リバースプロキシ）
    ├──────────────────────┐
    │                      │
    ▼                      ▼
フロントエンド             バックエンド
（Next.js / React）         （FastAPI）
    │                      │
    │ 画面用のAPI呼び出し   ├──────────────┐
    │                      │              │
    │                      ▼              ▼
    │                 PostgreSQL       Redis
    │                 永続データ       セッション・高速状態
    │
    └─────────────── 利用者へ画面を返す

バックエンド ──→ LLM提供者、メール送信、Google認証、Web検索
バックエンド ──→ 添付画像の保存領域
外部AIクライアント ──→ MCP認証 ──→ MCPの公開コンテンツ・メモ・コンテキスト機能

図1 ── ブラウザから外部サービスまでの全体構成。入口は一つ、保存先は用途別に分かれる。

通常の画面表示はフロントエンドが担当します。一方、ログイン状態、ユーザー所有データ、AI生成、公開範囲などの判断はバックエンドが担当します。

5. 1回のリクエストが通る道

利用者が「メッセージを送信する」場合を例にすると、処理は次の順番で進みます。

1. 入力利用者がメッセージを入力する。
2. 送信ブラウザが入力を整え、APIへ送る。
3. セッション復元セッションを復元し、言語やリクエスト情報を準備する。
4. CSRF検査状態を変える操作ならCSRFを検査する。
5. 入力検証入力形式、長さ、添付内容を検証する。
6. 認可ログイン状態、部屋の所有者、利用上限を確認する。
7. 文脈の収集必要な履歴、要約、タスク、プロジェクト指示、記憶を集める。
8. 生成開始LLM生成ジョブを開始し、進行イベントを共有する。
9. 逐次表示ブラウザがSSEで回答を少しずつ表示する。
10. 保存と確定完了した回答と関連情報を保存し、最終状態を返す。

5.1 画面の読み込み

フロントエンドは、ページの枠、共通ナビゲーション、翻訳、テーマ、ネットワーク状態、エラー境界を初期化します。ページごとの部品は、会話、メモ、プロンプト共有、設定などの領域に分かれています。

一覧データの取得にはキャッシュと再検証の仕組みが使われます。画面が再表示されたときに毎回すべてを取り直すのではなく、直近のデータを使いながら必要な部分だけ更新します。

5.2 API通信

通常の読み書きはJSONで行います。状態を変更する通信にはCSRFトークンを付けます。ネットワーク切り替えや一時的な失敗には、タイムアウト、再試行、エラーの標準化を行う共通通信層が対応します。

5.3 非同期処理とブロッキング処理

FastAPIは非同期処理を中心に動きます。ただし、LLM SDK、メール送信、画像変換、文書の文字抽出など、待ち時間のある同期処理も存在します。それらをイベントループ上で直接実行すると、他の利用者の通信まで止まります。そのため、ブロッキング処理は専用の実行枠へ移し、同時実行数を制御します。

6. バックエンドの責務分割

バックエンドは、入口と業務処理と保存処理を分けています。

• ルート層入力を受ける、認証を要求する、応答を整える。
• サービス層業務ルール、クォータ、外部サービス、複数処理の調整。
• リポジトリ層SQL、ORM、トランザクション、所有者条件、検索。
• データストアPostgreSQL / Redis / ファイル保存領域。

エラーは、次の八種類を区別します。

• 入力不正
• 未認証
• 権限不足
• 対象なし
• 利用上限
• 競合
• 外部サービス失敗
• 予期しない内部障害

利用者に見せるメッセージと、ログに残す詳細を分けることで、原因調査に必要な情報を保持しつつ、内部情報を外へ漏らしません。

7. フロントエンドの設計

フロントエンドは、ページ、表示部品、画面状態、API・ブラウザ共通処理の四つに分けて考えると理解しやすくなります。

状態の分割と描画量の制御

チャット画面は特に状態が多いため、入力中、生成中、停止、再接続、再生成、分岐切り替え、モーダル表示などを複数の状態管理へ分割しています。これにより、一つの巨大な画面部品がすべてを管理する構造を避けています。

メッセージが多い部屋では仮想スクロールを使い、画面に必要な範囲だけを描画します。古い履歴は追加読み込みにし、ブラウザへ戻った直後はローカルの一時表示を使ってからサーバーの正式な履歴へ合わせます。これにより、長い会話でも初期表示の遅さとブラウザのメモリ使用量を抑えます。

受け取ったものを信頼しない描画

言語とテーマ

日本語と英語の翻訳カタログを持ち、利用者の言語設定とリクエストの言語情報を使って表示を切り替えます。テーマはライト、ダーク、システム連動を選べ、端末のブラウザ側に保存されるため、端末ごとに設定が異なる場合があります。

サーバー側で先に組み立てる画面

サーバー側で先に内容を組み立てる画面もあります。共有チャット、共有プロンプトの個別ページ、共有メモ、公開プロンプトの一覧・検索ページの4系統は、検索エンジンやSNSのプレビューでも内容を見せやすくするため、バックエンドから取得したデータを安全なHTMLへ変換して初期表示に含めます。あわせて、サイトマップとrobots情報を返す入口も、リクエストのたびにサーバー側で内容を組み立てて返します。ログイン後の操作画面は、ブラウザ側でAPIを呼びながら状態を更新します。

キャッシュと再検証

サーバー由来の一覧は、SWRによるキャッシュと再検証で管理します。前回のデータを表示したまま裏側で更新し、ウィンドウへ戻ったときやネットワーク復帰時に再取得します。テーマ、言語、最後に見ていた部屋、選択中のモデルなどは、表示を速くする目的でブラウザ側に保存されるものがあります。

画面の一覧

画面群には、チャット、認証、設定、メモ、公開プロンプト、共有コンテンツ、管理画面、OAuth同意画面、ヘルプ、規約、プライバシー案内、各機能の紹介ページがあります。運用確認や検索エンジン向けの情報を返す入口もあります。通知設定の画面枠はありますが、現状は将来提供予定の案内が中心です。

8. 認証、セッション、セキュリティ

8.1 ログイン方法

パスワードを常用しない設計で、主に次の三つの方法を使います。

メール確認コードは短時間だけ有効で、試行回数にも上限があります。メールアドレス単位や接続元単位の送信・試行制限も設け、コードの総当たりや大量送信を抑えます。認証に成功すると、未ログイン時に作成したゲスト用プロンプトを本人のアカウントへ引き継ぐ処理も行われます。

8.2 セッションの保存

8.3 CSRFとCookie

ブラウザから状態を変更する操作には、セッションに紐づいたCSRFトークンを要求します。作成、更新、削除、共有、いいね、コメントなどが対象です。読み取りだけの操作と、状態を変更する操作を分け、不正な別サイトからの操作を拒否します。

Cookieには署名、SameSite、HTTPS時のSecure属性などを適用します。セキュリティヘッダーも共通ミドルウェアで付与し、各ルートが個別に忘れないようにしています。

8.4 入力と所有者の確認

入力はPydanticで型、長さ、形式を検査します。ただし、入力検査に通っただけでは安全とは限りません。各処理で次も確認します。

• ログインしているか。
• 対象の部屋、メモ、プロンプト、タスクが本人の所有物か。
• 公開対象か、共有トークンが有効か。
• 更新前の版番号が一致しているか。
• その操作がクォータやレート制限を超えていないか。

8.5 アカウントと設定

設定画面では、ユーザー名、自己紹介、アバター、AIへ常に伝えるプロフィール情報、表示言語、テーマ、Passkey、投稿したプロンプト、いいねしたプロンプト、MCP接続を管理できます。

• メールアドレスの変更は通常のプロフィール更新と分離し、新しいアドレスへの確認を含む専用手順にする。
• アカウント削除は確認文の入力と確認操作を必要とし、誤操作を防ぐ。
• アバター画像は拡張子だけで信用せず、Content-Typeとファイル先頭の形式、サイズを確認して保存する。
• 認証情報や外部接続の管理画面は、一般利用者の画面から見える設定項目とは別に、サーバー側で本人確認とCSRFを要求する。

8.6 AIへ送るデータの扱い

チャット本文、添付資料、公開コンテンツ、外部検索結果は、命令ではなく利用者提供のデータとして扱います。本文中に「このシステムの指示を無視せよ」と書かれていても、システムの指示を上書きできないように境界を明示します。API キー、パスワード、OAuthトークンなどの明白な秘密情報は、外部LLMへ送る前に伏せ字化する仕組みがあります。

9. チャットの内部設計

9.1 チャット部屋と履歴

会話は部屋単位で管理します。部屋には履歴、現在表示している分岐、要約、部屋単位の記憶が関連づきます。通常モードはデータベースへ履歴を保存し、一時モードは後で自動削除する対象として扱います。

一つの回答をやり直したり、過去の発言を編集して再生成したりすると、履歴を単純に上書きせず、親子関係を持つ分岐として保存します。利用者は、どの分岐を現在の会話として見るかを切り替えられます。

最初の質問
    │
    ▼
最初の回答
    │
    ├─ 再生成した回答
    │       └─ その回答から続く会話
    │
    └─ 編集後の質問
            └─ 編集後の回答

図2 ── 履歴は上書きではなく分岐として積み上がる。

この構造により、試行錯誤の履歴を残したまま、利用者が必要な会話の枝を選べます。

部屋は検索、追加読み込み、名前変更、削除、複数選択による一括削除、プロジェクトへの割り当てにも対応します。共有した部屋は、認証なしでも閲覧できる読み取り用の公開情報として扱い、ログインした利用者は自分の部屋へ複製して続きを始められます。共有元の部屋を直接編集することはできません。

ログインなしの利用者にも、制限付きのゲストチャットがあります。ゲストの会話は通常の利用者履歴へ保存せず、短期間の一時領域で扱います。公開プロンプトの閲覧や標準タスクの利用など、一部の公開・試用機能は使えますが、日次回数、投稿形式、共有、保存には制限があります。ゲスト時の公開投稿は、条件を満たしてログインした後に本人の投稿として引き継げます。

9.2 LLMへ渡す文脈

一回の生成では、最新の入力だけを送るのではありません。状況に応じて、次の情報を優先順位と上限を考慮して組み立てます。

1. システムとしての基本方針と安全規則。
2. 利用者が設定したAI向けプロフィール情報。
3. プロジェクトの指示。
4. 選択したタスクのテンプレート、応答ルール、例。
5. 部屋の要約と、直近の会話履歴。
6. 部屋に保存された記憶。
7. 必要に応じたパーソナル・コンテキスト。
8. 添付資料、Web検索結果、画像検索結果などの参照情報。
9. 最新の利用者メッセージ。

9.3 生成ジョブとストリーミング

ブラウザ ── 生成開始 ──→ バックエンド
                          │
                          ├─ 入力、所有者、クォータを確認
                          ├─ 生成ジョブを登録
                          └─ LLMへ要求
                                │
                                ▼
                        生成された断片
                                │
              Redisでイベントと状態を共有
                                │
ブラウザ ←── SSEで断片を受信 ←── バックエンド
    │
    ├─ 画面へ逐次表示
    ├─ 再接続時に状態と未受信イベントを確認
    ├─ 停止操作を送る
    └─ 完了後に履歴を再取得して整合させる

図3 ── 生成の開始・配信・再接続を分離した流れ。

フロントエンドはイベント番号で重複を除き、切断した場合は最後に受信した位置から再接続します。生成開始の応答が届かなかった場合でも、サーバー側にジョブが残っていないか確認して復帰を試みます。SSEが利用できない状況では、完了したJSON応答を処理する経路へ切り替えます。部屋を切り替えた後に古い生成結果が混ざらないよう、生成世代も確認します。

LLM提供者の一時的な失敗には限定的な再試行を行います。利用者が停止した場合は、外部生成とバックグラウンド処理を止め、途中の状態を不整合にしないようにします。サーバー終了時も実行中のジョブを安全に停止し、一定時間で待機を打ち切ります。

9.4 チャットの補助機能

• 部屋名を会話内容から補助的に生成する。
• 長い履歴を要約する。
• 会話から部屋の記憶を抽出する。
• Web検索、URL取得、検索結果の画像候補などを必要に応じて使う。
• 生成中の思考状態や構造化された表示部品（第9.6節の生成UIを含む）を、利用者に安全な形で表示する。
• 回答をコピーし、メモへ保存し、共有する。

9.5 メッセージ添付

テキスト、Markdown、CSV、JSON、HTML、コード、設定、ログなどのテキスト資料と、PDF、Word、Excel、PowerPointなどの文書を扱えます。標準では一度に最大5件1件あたり1MBまでで、抽出後の本文にも上限があります。

文書はそのままLLMへ渡すのではなく、形式を検証し、安全に文字を抽出し、制御文字や過剰な空白を整えます。Office形式はZIP爆弾やパス走査を防ぎ、XMLを安全に解析し、PDFのページ数や表計算のセル数にも上限を設けます。抽出された本文は添付資料として履歴とプロンプトへ組み込みます。

9.6 生成UI（サンドボックスアーティファクト）

通常のMarkdown回答に加えて、AIはHTML・CSS・JavaScriptをひとまとまりにした「アーティファクト」を回答へ埋め込み、チャット画面の中に簡単な図形やシミュレーション、3D表示のようなインタラクティブな表示を差し込めます。ただし、これは通常のテキスト生成より多くの関門を経る、安全側に倒した専用の処理経路です。

1. 必要性を判定するアーティファクトが必要かを別枠で判定する（無し／平面表示／立体表示）。
2. 抽出する応答中の該当ブロックを抽出する。
3. 正規化する表記ゆれ（項目名の違いなど）を吸収して標準形へ整える。
4. 検証する決まったスキーマで検証する（通過しないものは破棄する）。
5. 安全化するHTML・CSS・JavaScriptをそれぞれ個別に安全化する。
6. 受け渡す検証済みの内容だけがメッセージの表示部品として渡る。
7. 隔離実行するブラウザが隔離されたiframeの中だけで実行する。

生成の可否判定

通常の応答生成とは別に、軽量なLLM呼び出しで「アーティファクトが必要か、必要なら平面表示か立体表示か」を判定します。利用者の文章を直接それと解釈するのではなく、専用の判定用プロンプトと出力形式を使うことで、意図しない場面での誤生成を減らしています。

唯一の通過点となる検証

抽出した候補は、まず項目名の表記ゆれを吸収する下処理を経てから、決まったスキーマでの検証に通します。この検証を経ていないデータは、どのような経路であっても画面へは渡りません。検証では、種類・タイトル・高さ・本文の長さに上限を設けます。表示できるアーティファクトは1メッセージあたり最大3件、高さは一定の範囲（160〜900px相当）に丸められ、HTML・CSS・JavaScriptそれぞれと合計の文字数にも上限があり、超えた分は切り詰めます。

個別の安全化

HTML・CSS・JavaScriptは、それぞれ別の検査を通します。JavaScriptは危険とみなせる記述（外部通信の試行など）をコメントや文字列リテラルも踏まえて検出し、該当すれば拒否します。CSSやHTMLも、埋め込み表示として不適切な要素を取り除きます。

サンドボックス実行

ブラウザ側は、検証済みのHTML・CSS・JavaScriptを、隔離されたiframeの中だけで動かします。iframeには、外部通信・フォーム送信・入れ子のフレーム表示などを許可しないセキュリティポリシーを付け、スクリプトの実行だけを許可し、埋め込み元のページの情報へアクセスできない状態で動かします。これにより、アーティファクトの中のコードがブラウザ本体や他のタブの情報へアクセスすることを防ぎます。

ライブラリの扱い

アーティファクトが利用できる外部ライブラリは、あらかじめ許可した一種類（3D表示用のライブラリ）に限られます。外部のCDNから読み込むのではなく、Chat-Core自身が配信する静的ファイルから読み込みます。セキュリティポリシーが外部ホストへの接続そのものを遮断しているため、そもそもCDN読み込みは機能しません。これにより、外部ホストの改ざんや配信停止がアーティファクト表示に影響しない状態と、想定外のライブラリを勝手に読み込まれない状態を両立しています。

表示の統合

生成UIは、回答本文とは別の「メッセージの表示部品」として扱われ、Web検索の画像候補などほかの構造化された表示部品と同じ枠組みで管理されます。同じ返信の中で複数の種類の構造化表示が競合しないよう、表示できる組み合わせにも制約があります。

10. タスク、プロジェクト、再利用

10.1 タスク

タスクは、よく使うプロンプトを再利用するためのテンプレートです。次の要素を持ちます。

名前本文応答ルール出力形式入力例出力例

タスクを選ぶと入力欄へ内容を展開し、必要なら編集して送信できます。標準で用意されたタスクと、利用者が作成したタスクを同じ仕組みで扱います。利用者ごとに独立し、並び替え、編集、削除ができます。

10.2 プロジェクト

プロジェクトは、複数のチャット部屋を一つの目的や案件にまとめる単位です。プロジェクトには名前と指示を設定でき、その指示が属する部屋のAI文脈へ追加されます。部屋をプロジェクトへ割り当てたり、外したり、プロジェクトを削除したりできます。

11. 公開プロンプトとSkillの共有

11.1 公開コンテンツの流れ

1. 入力利用者が投稿内容を入力する。
2. 検証形式、長さ、カテゴリ、メディア種別を検証する。
3. 資料の処理画像やSkillの補助資料を安全に処理する。
4. 保存公開範囲を確認して保存する。
5. 反映一覧、検索、詳細、共有リンクへ反映する。
6. 利用他の利用者が閲覧、いいね、コメント、タスク追加を行う。

どちらも公開投稿として扱える一方、表示形式、必須本文、補助資料の扱いが異なります。投稿にはタイトル、カテゴリ、説明、本文、入力例、出力例、確認したAIモデル、メディア種別などを持たせられます。SkillにはMarkdown本体や補助スクリプトなどの資源を追加できます。

11.2 検索と利用

公開コンテンツは、カテゴリ、形式、メディア種別、キーワードなどで絞り込めます。タイトル、本文、説明、作者情報、SkillのMarkdownを検索対象にし、一覧では短い抜粋を返します。詳細画面では本文、例、資源、作者、評価、コメントを確認できます。

気に入ったプロンプトにはいいねを付け、設定画面から後で確認できます。自分のチャットで使うためのタスクとして追加することもできます。

11.3 コメントとモデレーション

コメントはログイン利用者に限定します。次のような投稿を制限します。

• 短時間の連続投稿
• 重複投稿
• URLを大量に含む投稿

コメントの削除は投稿者本人、対象プロンプトの投稿者、管理者に限り、通報が一定数に達したコメントは自動的に非表示にできます。

11.4 ゲスト投稿

ログイン前の投稿を一時的な識別情報で管理し、後からログインした利用者へ引き継げる仕組みがあります。ゲストの識別情報はそのまま保存せず、ハッシュ化などで濫用防止に使います。引き継ぎ時には、本人が所有する投稿だけを対象にします。

11.5 画像添付の保存境界

プロンプト共有の画像は、利用者が送った原本をそのまま公開しません。

1. アップロード利用者が画像を送信する。
2. 検査完全デコード、形式確認、画素数確認、アニメーション拒否。
3. 正規化EXIF向きの反映、メタデータ除去、サイズ縮小。
4. 派生生成表示用WebPとカード用WebPを生成する。
5. 保存原子書き込みで保存する。
6. 公開判定データベースの添付情報から公開対象を決定する。

現在の保存先は単一ホストの永続ボリュームです。表示用とカード用の二つの派生画像を保存し、投稿のデータベース行が参照元になります。保存途中で失敗しても不完全な画像を残さないよう、原子書き込みと後片付けを行います。データベースから参照されなくなった孤立画像は、猶予時間を置いた定期処理で削除します。

12. メモ機能

メモは、AIの回答や利用者が残した文章を、会話履歴とは別に長く使うための保存場所です。次の操作ができます。

二種類の検索を併用する

メモの検索では、文字列検索用の索引と、文章の意味を数値化した埋め込みを併用します。短い完全一致には通常検索が向き、表現が違っても意味が近い文章にはベクトル検索が向きます。埋め込みを作れない場合でも、メモの保存そのものが失敗しないよう、補助情報と本体を分けています。

版番号による衝突防止

共有中のメモを更新すると公開内容も変わるため、通常の編集より慎重に扱います。共有トークンは撤回可能で、期限切れも判定します。

書き出しの扱い

メモの書き出しは、保存された内容を別の場所で扱うための機能です。書き出した内容は共有リンクとは別物で、ファイルを作っただけで他の利用者へ公開されることはありません。

13. パーソナル・コンテキスト

例として、次の種類があります。

• 利用者の好み。
• 経歴やプロフィール。
• プロジェクトの背景。
• 過去の決定事項。
• 参考資料や再利用したい前提。

一つの事実には、種類タイトル本文重要度状態出典改訂番号があります。有効な事実と無効化した事実を分け、不要になったときも完全削除ではなく無効化して履歴を残します。重要度が高い事実ほど、外部AIへ渡す限られたダイジェストの中で優先されます。

13.1 「部屋の記憶」との違い

第9.1節で触れた「部屋の記憶」と、この章のパーソナル・コンテキストは、どちらも「会話から抽出した長期情報」という点で似ていますが、仕組みも扱いも別物です。混同しやすいため、違いを整理します。

13.2 チャットからの候補抽出

利用者が明示的に有効化した場合、通常チャットの後で、長期的に役立ちそうな利用者自身の文脈を非同期に抽出します。

1. 通常チャット完了やり取りが終わる。
2. バックグラウンド抽出候補抽出を裏側で実行する。
3. 秘密情報の除外明らかな秘密情報を除外する。
4. 重複確認既存の事実や候補と文字列類似検索で重複を確認する。
5. 提示確認待ち候補として表示する。
6. 判断利用者が承認、編集して承認、または却下する。
7. 確定承認されたものだけ正式な事実になる。

13.3 エクスポートとインポート

有効・無効化済みを含む事実をJSONまたはMarkdownで書き出せます。読み込みは、まず件数、重複、状態をプレビューし、利用者が確定した後に追加します。既存データは変更せず、同じ内容は重複として省略します。途中で上限を超えたり不正なデータがあったりした場合は、一部だけを保存せず全体を取り消します。

上限は次のとおりです。

事実：一人あたり最大200件本文：1件あたり最大2,000文字

14. 画面操作を補助するAIエージェント

14.1 何をする機能か

AIエージェントは、通常のチャットとは別に、現在のページの説明と操作補助を行う機能です。画面左下の起動ボタンから呼び出すドラッグ可能なミニチャットとして提供され、チャット本編、プロンプト共有、メモ、設定などのページで使えます。

利用者の依頼
      ↓
現在ページと利用可能な操作のカタログを確認
      ↓
依頼の種類を判定（説明／検索／画面操作）
      ↓
AIが回答または操作計画を作る
      ↓
利用者が計画の各ステップを確認
      ├─ 読み取り・移動中心の操作 → そのまま実行
      └─ 保存・送信・削除など取り消しにくい操作 → 追加確認モーダル後に実行
      ↓
実行後、画面側の状態を検証
      └─ 想定外の結果なら再計画を要求

図4 ── 依頼から実行までの流れ。リスクの高い操作だけ関門が一つ増える。

14.2 依頼の種類を最初に振り分ける

エージェントは一つの汎用チャットではなく、依頼をまず次の4種類に振り分けてから応答を作ります。

14.3 ページと操作のカタログ

エージェントが「何ができるか」を判断する材料は、次の二層のカタログです。

1. ページ定義: URLのパターンごとに、そのページの機能概要と、要素をクリックする・フォーカスするといった旧来のCSSセレクタ操作を列挙したもの。
2. 型付き操作API（ツール）: ページ遷移、入力欄への下書き入力、メッセージ送信、メモ保存のように、コマンド名・引数・検証方法・リスクレベル（low/medium/high）を持つ、より安全な操作の一覧。

このカタログはAPI呼び出しのたびに文章化されてシステムプロンプトへ埋め込まれ、現在のページには目印が付きます。加えて、現在ページのフロントエンド実装の冒頭部分もあわせてLLMへ渡し、実際にどのような入力欄やボタンが存在するかを踏まえて計画を作れるようにしています。

14.4 操作計画（アクションプラン）のデータ構造

画面操作の依頼に対して、LLMは自由文ではなく決まった形のJSONのみを返すよう指示されます。

{
  "description": "設定画面を開いて表示言語を日本語に変更します",
  "steps": [
    { "action": "navigate", "path": "/settings", "risk": "low",
      "description": "設定ページへ移動" },
    { "action": "app_action", "command": "settings.setLanguage",
      "args": { "language": "ja" }, "risk": "medium",
      "description": "表示言語を日本語に設定" }
  ]
}

ステップの action には次の種類があります。

• app_action — 型付きコマンド実行。
• click / input / focus / scroll / select / check — CSSセレクタに対する低レベルDOM操作。
• navigate — 許可されたページへの遷移。
• wait — 0〜5000msにクランプされる待機。

応答はまずJSONとしてパースを試み、旧テキスト形式で返ってきた場合のフォールバック解析も備えています。各ステップは受け取った直後に検証・正規化され、許可リストにないコマンドや、// で始まる・制御文字を含む・スキーム付きURLのような不正な遷移先はこの時点で除去されます。

14.5 フロントエンドでの受信・確認・実行

バックエンドの応答はSSEで届き、イベント種別は次の4種類です。

処理中の状態操作計画が完成した合図最終回答の確定エラー

ミニチャットは操作計画を受け取ると、メッセージの下にステップ一覧と実行ボタンを表示します。各ステップは行をクリックすると、実行されるコマンドやパラメータ、対象のUI要素などの詳細を開閉できるため、利用者は「何が行われるか」をブラックボックスのまま実行することを避けられます。

実行ボタンが押されると、実行エンジンがステップを順番に処理します。1ステップごとに、次の一連のライフサイクルを経ます。

• ページ遷移と準備待ち必要ならページを移動し、準備が整うまで待つ。
• 確認モーダル必要ならリスクに応じた確認を挟む。
• 実際の操作型付きコマンドの呼び出し、またはDOM操作。
• 状態検証実行後の状態を検証する。

ページ遷移をまたぐ操作列は、ブラウザのセッションストレージへ一時保存し、新しいページの準備が整ったことを確認してから残りのステップを再開します。

14.6 危険な操作への追加確認

すべてのステップが同列に扱われるわけではありません。次のいずれかに該当するステップは、実行前に必ず確認モーダルを挟みます。

• リスクレベルが中または高のステップ（例: メッセージ送信、メモ保存など状態を変更する操作）。
• CSSセレクタに対する生のクリック操作（型を持たない操作は一律に確認対象とする）。
• メモの本文書き換え（常に確認する）。
• 型付きコマンドのうち、あらかじめ「非破壊」と分かっているコマンド（ページ内移動、入力欄への下書き入力、検索など）以外すべて。

14.7 実行結果の検証と誤動作の防止

一つのチェックに頼らず、バックエンドとフロントエンドの双方で多重に防御しています。

14.8 使用するLLMと通常チャットとの違い

エージェントの応答生成も、通常のチャットと同じLLM抽象化層（モデル名からプロバイダを自動振り分けする共通の仕組み）を土台にしていますが、上位の設計は通常チャットと明確に異なります。

補助タスク（依頼の種類判定、メモ編集意図の判定など）に軽量なモデルを固定で使うのは、利用者がどのモデルを選んでいても、画面操作の判定という裏方の処理品質を安定させるためです。第37章で述べた「軽量モデルを分類・要約へ、高品質モデルを複雑な回答へ」という費用対効果の考え方がここにも表れています。

14.9 会話履歴とセッションの性質

バックエンドはエージェントの会話をデータベースへ永続化しません。リクエストのたびに、ブラウザが保持している直近のやり取り（件数・文字数に上限あり）を送り、サーバーはそれを一時的な入力として扱うだけのステートレスな設計です。継続性は主にブラウザ側で演出しています。

14.10 レート制限と月間クォータ

画面操作を伴うため、通常チャット以上に濫用時の影響（誤った大量操作、外部費用の消費）を抑える必要があります。接続元IPアドレス単位、ログイン利用者またはゲストセッション単位の短時間レート制限に加え、全利用者合算の月間クォータを設け、上限に達すると再試行までの待ち時間とともに拒否します。具体的な代表値は第24.1節の上限一覧にまとめています。

15. MCP連携

15.1 MCPとは

15.2 認証と同意

1. 発見・登録外部AIクライアントが接続先を発見し、クライアント登録を行う。
2. ログイン利用者のブラウザでChat-Coreへログインする。
3. 同意要求された権限を同意画面で確認する。
4. 認可コード発行一度だけ使える認可コードを発行する。
5. トークン発行アクセストークンと更新トークンを発行する。
6. 毎回の検証MCPツール呼び出しごとに権限と利用者を確認する。

権限は、公開コンテンツの読み取り、公開投稿、非公開メモの読み取り、メモの編集、パーソナル・コンテキストの読み取り、保存・編集・無効化などに分かれています。

認可コードは短命で一度だけ使い、アクセストークンや更新トークンは生の値をそのままデータベースへ保存しない設計です。OAuthの秘密情報は暗号化やダイジェスト化を使い、鍵の世代交代にも対応できる構造になっています。外部クライアントの登録、リダイレクト先、接続先ホスト、ブラウザOriginも検証します。

15.3 提供する機能

MCPから使える機能は、次の三つの領域に分かれます。

メモ本文は一度に扱える文字数を抑え、長い本文は分割して取得できます。コンテキストのダイジェストは重要度と文字数予算を考慮して返し、全件数、返却件数、省略件数、切り詰めの有無を示します。

更新操作では、Web画面と別のMCP接続が先に変更していないかを版番号で確認します。保存操作には再試行時の重複を防ぐための冪等キーを使えるものがあります。

15.4 MCPの安全性

登録、認可、投稿、読み取り、書き込み、意味検索にはそれぞれ制限があります。これにより、一つの接続や利用者が大量の登録、公開投稿、検索、編集を行ってサービスを圧迫することを防ぎます。

15.5 管理者機能

管理画面は一般利用者の認証とは別の管理者境界を持ちます。管理者ログインには専用のパスワードハッシュ照合と接続元単位の試行制限を適用し、成功時には管理者用セッションを作ります。管理者として認証されていない利用者は、管理画面や管理用APIを利用できません。

管理者はダッシュボードでシステムのデータ状態を確認し、許可された範囲でテーブル一覧、列情報、データのプレビューを確認できます。管理用のテーブル作成・削除、列の追加・削除といった操作もありますが、入力された識別子、型、制約、既定値を厳格に検証し、複数SQL文や未対応の定義を拒否します。

16. データモデルの考え方

PostgreSQLは、関係のあるデータを一貫して保存する中心です。概念上の主なグループは次のようになります。

多くのデータは利用者へ外部キーで紐づきます。利用者を削除したときに一緒に消すもの、履歴として残すもの、公開情報の整合性を保つために別扱いにするものを、データごとに決めています。

16.1 論理削除と履歴

プロンプト、コメント、タスク、コンテキストなどは、削除日時や状態を持つものがあります。

16.2 JSONとベクトル

メモやコンテキストの意味検索には埋め込みベクトルを使い、PostgreSQLのベクトル拡張で近い文章を探します。

16.3 データベース変更

データベースの構造変更は、適用順序を持つマイグレーション履歴で管理します。既に適用された履歴を書き換えず、新しい変更を後から追加します。開発環境では起動時に適用する流れがありますが、本番のBlue/Greenデプロイでは、トラフィック切り替え前に対象環境へ明示的に適用します。

17. PostgreSQL、Redis、ファイル保存の使い分け

• PostgreSQL — 失ってはいけない正本利用者、履歴、メモ、公開情報、権限、版番号。
• Redis — 複数プロセスで共有したい高速状態セッション、キャッシュ、クォータ、ロック、生成イベント。
• 永続ボリューム — データベースの行から参照される大きな派生ファイルプロンプト共有の表示画像とカード画像。

画像本体はデータベースへ大きなバイナリとして詰め込まず、データベースには参照情報と寸法、形式、サイズなどを保存します。データベースが参照元なので、孤立ファイルの掃除や保存先の移行を管理できます。

17.1 クォータとレート制限の共通実装パターン

LLMの日次利用上限、メール送信の日次上限、AIエージェント呼び出しの月間上限、Web検索の月間上限、接続元IPや利用者単位のレート制限など、「一定期間あたりの回数を数え、上限を超えたら拒否する」という機能はサービス内の複数箇所に登場します。これらは機能ごとに個別実装するのではなく、共通の仕組みを使い回しています。

利用回数を1消費したい
        ↓
Redisが使えるか
    ├─ 使える → キーのINCRとEXPIREを1回のLuaスクリプトでアトミックに実行
    │            （読み取りと書き込みの間に他の処理が割り込んで
    │             上限を超過するのを防ぐ）
    └─ 使えない → ロックで保護したプロセス内カウンタへフォールバック
                    （単一プロセスの範囲でのみ正しく数えられる）
        ↓
消費後の残り回数と、拒否する場合は再試行までの待ち時間を返す

図5 ── 回数消費の共通経路。Redisが落ちてもサービスは止めない。

この一つの仕組みを、日次・月間・短時間（数分単位）など期間の異なるさまざまなクォータへ使い回すことで、機能ごとに個別のカウント処理を実装する手間と、実装ごとの競合バグの発生源を減らしています。

18. 外部サービスとの境界

18.1 LLM提供者

利用者が選んだモデルや機能に応じて、複数のLLM提供者へ振り分けます。通常の会話、タイトルや要約、メモのタイトル案、コンテキスト候補抽出、AI補助などは、用途ごとに適した処理として呼び出します。

18.2 メールとGoogle

メール送信は確認コード、メールアドレス変更などに使います。送信回数、確認コードの期限、試行回数を管理します。Google OAuthでは、認証状態とコールバックの正当性を検証し、成功した利用者をChat-Coreの利用者へ結び付けます。

18.3 WebAuthn

Passkeyの登録と認証では、ブラウザと認証器のチャレンジ、期待するサイト識別子、Origin、ユーザー検証、署名カウンターを検証します。登録や認証の一時情報はセッションに置き、短時間で失効させます。

18.4 Web検索とURL取得

検索やURL取得は、LLMの回答を補助する外部データです。

19. コンテナと運用構成

開発・本番とも、主にコンテナで動かす構成です。

19.1 起動順序

1. PostgreSQL準備完了になる。
2. バックエンド起動待ちののち、必要な環境でマイグレーションを適用する。
3. 準備確認バックエンドの準備状態を確認する。
4. 初期データ投入初期タスクやサンプル公開コンテンツを不足分だけ投入する。
5. フロントエンド起動する。
6. 公開リバースプロキシが公開先を選択する。

初期データ投入は複数ワーカーが同時に行っても重複しないよう、共有ロックと一意制約を使います。起動時には一時チャットの削除や孤立画像の掃除を定期的に行うバックグラウンド処理も開始します。

19.2 ヘルスチェック

フロントエンドにも別のヘルスチェックがあります。

19.3 Blue/Greenデプロイ

本番では、稼働中の色と次に起動する色を分けるBlue/Green方式を取れます。

現在の環境（利用者の通信）
             │
             │ 共通のPostgreSQL / Redis
             ▼
新しい環境を起動
  ├─ マイグレーション
  ├─ バックエンド準備確認
  └─ フロントエンド準備確認
             ↓
リバースプロキシの向き先を切り替え
             ↓
旧環境を停止

図6 ── データストアは共通のまま、実行環境だけを入れ替える。

このBlue/Greenの切り替え自体は、通常はmainブランチへの変更の取り込みをきっかけに、テスト・依存関係の監査・型検査などの継続的インテグレーション（CI）の一連の確認を通過した後で自動的に開始されます。CIを通過しない変更が本番へ流れ込まないようにする点は、この文書が扱うランタイムのシステム設計と表裏一体の運用上の前提です。

20. 起動時・停止時・定期処理

21. テストと品質管理

テストはすべてを一度に実行するより、変更した契約と境界に合わせて絞ります。

バックエンド

• 認証、セッション、Cookie、CSRF、Redis障害。
• チャット入力、所有者、部屋、分岐、SSE、再接続、停止、クォータ。
• タスクの初期投入、言語、並び順、重複、編集履歴。
• 公開プロンプトの投稿、検索、添付変換、いいね、コメント、通報。
• メモの作成、検索、埋め込み、共有、版番号競合。
• コンテキストの候補、承認、却下、ページング、入出力。
• MCPのOAuth、権限、トークン、ツール、レート制限。
• データベース接続、マイグレーション、制約、インデックス。

外部LLM、メール、データベース、Redisは原則モックし、ルートのHTTP動作やエラーを決定的に検証します。実際のDBやRedisを使う統合テストでは、所有者境界、障害時の挙動、トランザクションを確認します。

フロントエンド

• APIレスポンスの正規化、空値、HTTPエラー。
• SSEのイベント解釈、ストリーミング表示、再接続、停止。
• チャットの履歴、部屋、タスク、プロジェクトの状態遷移。
• プロンプト共有、Skill資源、メモ、コンテキストの画面操作。
• 認証、設定、言語、テーマ、MCP同意画面。
• Markdownの安全な表示、モーダル、フォーカス、ネットワーク状態。

22. 設計上の重要な判断

22.1 API契約はバックエンドを正本にする

フロントエンドとバックエンドで同じ型を別々に手書きすると、片方だけ項目が変わる危険があります。バックエンドのPydanticモデルを正本にし、フロントエンドのスキーマを生成することで、契約の二重管理を減らしています。

22.2 セッション本体をRedisへ置く

Cookieへ機密セッションを置くと、読み取りや漏えい時の影響が大きくなります。Redisへ分離することで、Cookieを参照値に限定し、複数ワーカー間で同じログイン状態を共有できます。Redis障害時に安全側へ倒すことも明確になります。

22.3 画像処理と保存先を分離する

画像の安全な変換と、ローカルディスクやオブジェクトストレージへの保存は別の関心事です。変換処理が保存先を知らないことで、保存先を移行しても、検査と投稿のロジックを再利用できます。

22.4 データベース構造を履歴で管理する

起動時に場当たり的なSQLを実行すると、どの環境へ何が適用されたか分かりにくくなります。マイグレーション履歴で順序と適用状態を管理し、既存履歴を改変しないことで、開発、テスト、本番の構造を追跡できます。

22.5 更新競合を版番号で検出する

メモ、コンテキスト、MCPのように複数画面や複数クライアントから編集されるデータは、読んだ時点の版を要求します。古い画面が新しい内容を無意識に上書きしないためです。

22.6 AIが生成した表示は、サーバー検証とサンドボックスの二重で守る

AIが提案する画面操作の計画（第14章）や、AIが生成するインタラクティブな表示（第9.6節の生成UI）は、どちらも「LLMの出力を信頼して即座に実行・表示する」設計を避けています。LLMの応答は決まったスキーマでの検証を必ず経てから使い、実行・表示の段階でも、許可された範囲外の操作やライブラリを機械的に拒否します。

23. 典型的なシナリオ

23.1 メールで登録してチャットする

1. ブラウザでメールアドレスを入力する。
2. バックエンドが送信制限を確認し、6桁コードをメールで送る。
3. コードを一時セッションへ保存する。
4. 利用者がコードを入力すると、期限、試行回数、コードを検証する。
5. 利用者を有効化し、セッションをローテーションする。
6. 標準タスクを利用者用に準備する。
7. 利用者がメッセージを送ると、部屋所有者、クォータ、文脈を確認する。
8. 生成ジョブを開始し、SSEで回答を配信する。
9. 完了後、履歴、タイトル、要約、必要な記憶を更新する。

23.2 プロンプトを投稿してタスクとして使う

1. 利用者がタイトル、カテゴリ、形式、本文、例を入力する。
2. サーバーが投稿制限と入力形を検証する。
3. 参照画像があれば安全な派生画像へ変換する。
4. 公開コンテンツと添付情報をデータベースへ保存する。
5. 他の利用者が検索して詳細を開く。
6. いいね、コメント、共有を行える。
7. 「チャットで使う」を選ぶと、所有者のタスクとして追加される。

23.3 メモをMCP経由で更新する

1. 外部AIクライアントがOAuth同意を得る。
2. MCP呼び出しで本人のメモ一覧を取得する。
3. 対象メモの本文と版番号を読む。
4. 利用者が編集を依頼する。
5. 外部AIクライアントが版番号付きで更新する。
6. Web画面などが先に更新していれば競合として拒否する。
7. 再読込後、最新の版番号で再度更新する。

23.4 会話からコンテキスト候補を承認する

1. 利用者が自動抽出を有効にする。
2. 通常チャット完了後、バックグラウンド処理が候補を作る。
3. 秘密情報と重複候補を除外する。
4. 利用者が候補を確認する。
5. そのまま承認、編集して承認、却下のいずれかを選ぶ。
6. 承認されたものだけが正式な事実となり、将来のAI文脈へ利用される。

23.5 AIエージェントで画面の設定を変更する

1. 利用者が設定ページでエージェントを開き、「表示言語を日本語にして」と依頼する。
2. バックエンドがレート制限とクォータを確認し、依頼の種類を画面操作と判定する。
3. 現在ページ（設定）の操作カタログとページ構造を踏まえ、遷移とコマンド実行からなる操作計画を作る。
4. ブラウザが計画をSSEで受け取り、ステップ一覧と実行ボタンを表示する。
5. 利用者がステップの内容を確認し、実行を選ぶ。
6. 状態を変更するステップのため、追加の確認モーダルが表示される。
7. 承認後、型付きコマンドで言語設定を変更し、実行結果を画面側で検証する。
8. 反映を確認できたら完了、反映されていなければ最新の画面状態を取り直して再計画する。

24. 初心者が知っておくべき制約

24.1 代表的な上限

次は、設計を理解するときに目安になる主な上限です。運用設定で変更できるものと、入力モデルで固定されているものがあります。

25. 用語集

26. 面接でこのシステムを説明するための前提

26.1 最初の60秒で伝える内容

次のように要約すると、面接官がシステムの中心を理解しやすくなります。

Chat-Coreは、利用者ごとの会話、メモ、公開プロンプト、パーソナル・コンテキストを扱うAIワークスペースです。ブラウザにはNext.js、業務処理にはFastAPI、永続データにはPostgreSQL、セッションと生成中の共有状態にはRedisを使います。通常のAPIはJSON、長時間のLLM生成はバックグラウンドジョブとSSEで配信します。最も重要な不変条件は、利用者の所有データを越境させないこと、生成結果を二重保存しないこと、外部コンテンツを命令として実行しないことです。現在の単一ホスト構成から、負荷が増えれば生成ワーカー、キュー、オブジェクトストレージ、読み取り分離、必要に応じたシャーディングへ段階的に拡張します。

26.2 面接の時間配分

60分程度の面接を想定するなら、次の配分が扱いやすいです。実際の時間は面接官の質問を優先します。

27. 要件定義：最初に確認する質問

27.1 機能要件

面接の冒頭では、次の質問でスコープを固定します。

• 利用者はログイン必須か、ゲスト利用が必要か。
• 会話は保存するか、一時利用を許すか。
• 回答は全文を待ってから表示するか、生成途中から表示するか。
• 生成停止、再生成、編集後の再生成、会話分岐は必要か。
• 添付資料、Web検索、画像検索、メモ参照は必要か。
• プロンプトやメモを他人へ共有するか。共有は期限付きか撤回可能か。
• 外部AIクライアントからメモやコンテキストを操作するか。
• 複数のLLM提供者を使うか。切り替えやフォールバックが必要か。
• 管理者によるモデレーションやデータ確認が必要か。

27.2 非機能要件

機能要件だけでは大規模システムの設計を決められません。次を確認します。

27.3 不変条件

設計の中心に置くルールを、機能ではなく不変条件として説明します。

1. 利用者は、自分が所有するデータまたは明示的に公開されたデータだけを読める。
2. 状態変更は認証、所有者、CSRF、レート制限を通過しなければならない。
3. 一つの生成要求は、同じ回答を履歴へ二重保存しない。
4. 停止、完了、失敗のどれか一つだけが最終状態になる。
5. 外部コンテンツ、添付資料、公開Skill、検索結果は命令ではなくデータである。
6. パーソナル・コンテキストは明示的な同意なしに共有・MCP公開しない。
7. 古い画面が新しいメモやコンテキストを無意識に上書きしない。
8. 画像原本、アクセストークン、秘密情報を不用意に公開しない。
9. LLMや検索の障害で、保存済みの利用者データを壊さない。
10. 監視とログから、障害の原因をリクエスト単位で追跡できる。

28. 面接用の容量見積もり

28.1 見積もりの手順

1. 利用者数を置く
2. 日次の操作数を置く
3. 平均レートを出す1日を秒へ変換する。
4. ピーク係数を掛ける
5. 1操作のコストを掛けるサイズ、処理時間、外部呼び出し数。
6. 余裕を加える可用性のための余裕、再試行、レプリカ。
7. 支配的な資源を見つける

基本式は次のとおりです。

平均RPS = 1日あたりの操作数 ÷ 86,400
ピークRPS = 平均RPS × ピーク係数
同時生成数 = ピーク生成開始レート × 平均生成時間
日次保存量 = 1日あたりの保存件数 × 1件あたりの平均サイズ
帯域 = 同時配信数 × 1秒あたりの平均配信バイト数

28.2 会話の例

登録500万人DAU 50万人うち20%が会話開始1人平均20ターン生成時間30秒ピークは日平均の10倍保存平均12KiB

計算すると、1日のターン数は次のようになります。

500,000人 × 20% × 20ターン = 2,000,000ターン/日
2,000,000 ÷ 86,400 ≒ 23ターン/秒（平均）
23 × 10 ≒ 230ターン/秒（ピーク）
230 × 30秒 ≒ 6,900件（ピーク同時生成）

図7 ── ターン数から同時生成数を導く。

保存量は次のようになります。

2,000,000ターン × 12KiB ≒ 24GiB/日
90日保持なら約2.2TiB（インデックス、レプリカ、検索情報を除く）

28.3 ストリーミング帯域の例

AI回答が平均6KiBで、1ターンを20秒かけて配信すると仮定します。ピーク同時生成が6,900件なら、平均的な配信帯域は次のように概算できます。

6,900件 × 6KiB ÷ 20秒 ≒ 2,070KiB/秒

実際にはSSEイベントのメタデータ、再接続、検索状態、TLS、ピークの偏りが加わります。リバースプロキシの接続数、アイドルタイムアウト、ワーカーのファイルディスクリプタ、Redisのイベント保持量を確認します。

28.4 添付画像の例

1%のターンが平均0.5MiBの画像を1枚添付すると仮定します。

2,000,000ターン × 1% × 0.5MiB = 10GiB/日（原入力の概算）

28.5 見積もりから導く設計判断

この仮定から、次の判断を説明できます。

• LLM生成はAPIワーカーから分離する。
• ストリームイベントは一時共有状態またはイベント基盤へ置く。
• PostgreSQLの接続を長時間占有しない。
• 履歴をパーティションまたはアーカイブで管理する。
• 画像はデータベース本体から分離する。
• LLM提供者ごとの同時実行数とクォータを制御する。
• 利用者ごと、接続ごと、提供者ごとのバックプレッシャーを設ける。

29. SLO、SLI、エラーバジェット

29.1 SLIを分ける

「速い」「安定している」と言うだけでは曖昧です。観測する指標を定義します。

29.2 面接用の目標例

• 読み取りAPIの月間可用性99.9%以上。
• 認証済みの通常APIはp95 300ms以内。ただし外部LLM待ちは除く。
• チャットの初回トークンはp95 2秒以内。ただし提供者障害時を別扱いにする。
• 生成ジョブのp95完了時間は30秒以内を目標にする。
• ストリーム切断の大半を数秒以内に再接続する。
• 正常に保存されたデータのRPOは数分以内、復旧目標は30分以内を目指す。
• 利用者間のデータ越境は0件。

29.3 エラーバジェット

月間可用性99.9%なら、理論上許される停止時間は約43分です。その時間をすべて新機能のデプロイに使うのではなく、障害、移行、依存サービス停止、計画メンテナンスの扱いを決めます。

30. 現状から10倍・100倍へ拡張する

30.1 現状の性質

現在の構成は、単一ホストのDocker Composeを中心に、バックエンド、フロントエンド、PostgreSQL、Redis、画像用永続領域を分けています。Blue/Greenで同一ホスト内の切り替えはできますが、画像保存は単一ホスト制約を持ちます。LLM生成、SSE、Redisセッション、PostgreSQL接続プールが主要なスケール境界です。

30.2 10倍になったときの構成

面接で10倍を聞かれたら、最初から全分散化するのではなく、ボトルネックの順に分離します。

利用者
  ↓
CDN / リバースプロキシ
  ├─ フロントエンドの静的・SSR配信
  └─ APIの負荷分散
          ↓
   複数のステートレスAPI
      ├─ Redisまたはマネージド共有状態
      ├─ PostgreSQL主系・読み取りレプリカ
      ├─ 生成ジョブキュー
      ├─ 生成ワーカー群 ── LLM提供者ゲートウェイ
      ├─ オブジェクトストレージ ── CDN
      └─ 検索・ベクトル検索基盤

図8 ── 10倍規模の構成。ステートを外へ出し、生成を専用群へ寄せる。

変更の順番は次のようにします。

1. APIをステートレスにするセッションと生成イベントを共有状態へ置く。
2. 生成を分離するキューと専用ワーカーへ分ける。
3. Redisを冗長化する接続数、メモリ、イベント保持期間を監視する。
4. PostgreSQLを強化する接続プーラー、読み取りレプリカ、適切なインデックスを導入する。
5. 画像を外へ出すオブジェクトストレージへ移し、CDNと署名付き配信を使う。
6. 検索を検討する埋め込み検索や公開フィードを独立した検索基盤へ移すか検討する。
7. LLMをゲートウェイへ集約する提供者ごとのレート制御とフォールバックをまとめる。

30.3 100倍になったときの構成

100倍では、単にAPIの台数を増やすだけでは足りません。

• チャット履歴を利用者または部屋のハッシュで分割する。
• 履歴を時間でパーティションし、古いデータを低コストストレージへ移す。
• 公開フィードを読み取り専用の検索インデックスへ複製する。
• メモやコンテキストの意味検索を専用ベクトル基盤へ分離する。
• LLM生成を地域、モデル、優先度、クォータでスケジューリングする。
• 接続が長いストリームを専用ゲートウェイで扱う。
• 利用者のホームリージョンを決め、データ所在地を固定する。
• リージョン障害では読み取り専用または別リージョンへ切り替える。

30.4 スケールのトレードオフ

分散化すると、次の代償が増えます。

• サービス間通信の失敗が増える。
• 分散トレーシングとデバッグが必要になる。
• データの二重化と結果整合性を管理する必要がある。
• デプロイ、マイグレーション、ロールバックが難しくなる。
• 運用費と監視費が増える。

31. 一貫性、競合、冪等性

31.1 機能ごとの一貫性

31.2 生成ジョブの状態機械

作成済み
   ↓
実行中 ─────────────→ 失敗
   │                    ▲
   │ 停止要求            │
   ▼                    │
停止処理中 ─────────────┘
   │
   ├─ 停止完了
   └─ 先にLLMが終わった場合 → 完了

図9 ── 停止要求とLLM完了が競合しても、終端状態は一つに定まる。

31.3 冪等性

ネットワークが切れると、ブラウザは「送信できたか分からない」状態になります。新規生成、メモ保存、コンテキスト保存、MCP投稿には、必要に応じて再試行を識別する一意な要求IDを使います。

32. 障害マトリクス

33. セキュリティ深掘り

33.1 脅威モデル

33.2 テナント分離

安全策は一つだけに依存させません。

1. ルート層ログイン利用者を得る。
2. サービス層対象操作と利用者の関係を確認する。
3. リポジトリ層取得・更新条件にも利用者を含める。
4. 返却前所有者や公開状態を再確認する。
5. テスト異なる利用者のテストデータで横断アクセスを検証する。
6. 経路の分離管理者、ゲスト、MCP利用者で権限経路を分ける。

33.3 Prompt Injectionへの答え

• システム指示、利用者指示、参照データを明確に区切る。
• 参照データの命令はデータとして読むようLLMへ指示する。
• 参照データから直接ツールを呼ばせない。
• ツールは機能ごとの許可表、利用者権限、対象所有者、確認を通す。
• 外部ページから取得したURLへ自動送信や自動投稿をしない。
• 重要操作は利用者の確認を必要にする。
• LLMが守れる範囲と、サーバーで強制する範囲を分ける。

33.4 SSRFへの答え

利用者やLLMが指定したURLをサーバーから取得すると、内部ネットワークを探られる危険があります。防御はURL文字列の確認だけでは不十分です。

• HTTPとHTTPSだけを許可する。
• localhost、ループバック、プライベートネットワーク、クラウドメタデータ用アドレスを拒否する。
• DNS解決後のIPを検証し、接続時に再び別IPへ解決されないようにする。
• リダイレクトごとに同じ検査をする。
• 応答サイズ、時間、コンテンツ種別、リンク追跡深さを制限する。
• HTML本文をサニタイズし、スクリプトを実行しない。

34. API、イベント、互換性

34.1 APIの分け方

成功、入力不正、未認証、権限不足、競合、上限、外部障害を、HTTPステータスと安定したエラー種別で区別します。

34.2 SSEイベントの契約

SSEでは、各イベントに少なくとも「順序を確認する識別情報」「イベントの種類」「データ本体」を持たせます。種類には、進行状態、回答断片、検索情報、表示部品、完了、停止、エラーなどがあります。

生成ジョブ
  ↓
イベント番号付きの進行イベント
  ↓
ブラウザが番号を確認して重複排除
  ↓
接続断なら最後の番号から再接続
  ↓
完了または停止を一度だけ確定

図10 ── イベント番号が重複排除と再接続の両方を支える。

34.3 ページングと検索

履歴、公開フィード、メモ、コンテキストは、すべてを一度に返しません。作成時刻と一意なIDなどを組み合わせたカーソルで、次のページを安定して取得します。ページング中に新しいデータが追加されても、同じ行が重複したり欠落したりしにくい順序を選びます。

検索結果は、本人の所有条件、公開状態、削除状態、検索語、カテゴリ、順位、カーソルを一つの契約として扱います。

34.4 APIの進化

1. 任意で追加新しい項目を任意で追加する。
2. 旧クライアント確認旧クライアントが無視できることを確認する。
3. スキーマ再生成バックエンドの契約からフロントエンドのスキーマを再生成する。
4. テスト更新ロジック、SSE解析、画面テストを更新する。
5. 旧項目の廃止十分な移行期間を置いてから廃止する。

35. データベースと検索の深掘り

35.1 なぜPostgreSQLか

Chat-Coreでは、利用者、所有権、部屋、履歴、分岐、共有、コメント、版番号、OAuthの関係が多く、書き込みの一貫性が重要です。PostgreSQLを使う理由は、次の関係と制約を一つのトランザクションで扱いやすいからです。

• 利用者と所有データの外部キー。
• 部屋と履歴の親子関係。
• プロンプトとコメント、いいねの整合性。
• メモとコレクションの関係。
• 版番号を条件にした更新。
• 一意制約による二重いいねや重複タスクの防止。

35.2 ホットスポット

大量利用時に集中しやすい場所は、最新メッセージ、人気プロンプト、閲覧数カウンター、生成イベント、メモ検索、OAuthのレート制限です。

35.3 パーティションとアーカイブ

履歴が増え続ける場合、部屋や作成時刻でパーティションを分けます。古いデータを別ストレージへ移す場合は、次を決めます。

• 画面から過去履歴を読み戻せるか。
• 検索対象に残す期間。
• 要約だけをホット領域へ残すか。
• 共有リンクが古い履歴を参照できるか。
• 削除要求をアーカイブにも反映できるか。
• バックアップと復元で正本とアーカイブを同時に戻せるか。

36. 運用、可観測性、復旧

36.1 監視するメトリクス

利用者操作
  ↓
リクエストID
  ├─ APIレイテンシ、ステータス、エラー種別
  ├─ DBプール使用率、クエリ時間、ロック待ち
  ├─ Redisメモリ、ヒット率、接続、イベント遅延
  ├─ 生成キュー長、待ち時間、同時実行数
  ├─ LLM提供者別の成功、429、5xx、費用
  ├─ SSE切断、再接続、完了、停止
  ├─ 添付変換失敗、保存容量、孤立画像
  └─ OAuth同意、更新、失効、権限エラー

図11 ── 一本のリクエストIDから全レイヤーの指標をたどる。

36.2 アラート

• API可用性低下 → 直近デプロイ、DB、依存先を確認し、必要なら切り戻す。
• DBプール枯渇 → 長いトランザクション、接続数、重い検索を調べる。
• Redisメモリ逼迫 → TTLのないキャッシュ、イベント保持、セッション量を確認する。
• 生成キュー増大 → LLM提供者の429、ワーカー数、利用者クォータを確認する。
• SSE再接続急増 → リバースプロキシのタイムアウト、ネットワーク、ワーカー停止を確認する。
• テナント越境の疑い → 即時に該当機能を止め、監査と影響範囲調査を行う。
• 添付容量急増 → 大量投稿、孤立掃除、ユーザー別クォータを確認する。

36.3 バックアップと復元

PostgreSQL、画像、Redisは復元の性質が異なります。

• PostgreSQL最優先の正本。定期バックアップ、世代管理、暗号化、復元検証が必要。
• 画像データベースの添付情報と対応する時点でバックアップする。
• Redis再構築でログイン再認証や生成イベント消失が起こることを、利用者影響として受け入れるか決める。
• 復元訓練バックアップだけでなく、実際に別環境へ復元できるか定期的に確認する。

36.4 マイグレーションの安全な流れ

1. 変更の設計
2. 追加新しい列・新しい構造を追加する（旧コードでも動く）。
3. 両読み対応アプリを新旧両方読めるように更新する。
4. バックフィル低速・再開可能に実行する。
5. 書き込み確認新しい形式への書き込みを確認する。
6. 監視期間
7. 削除旧列・旧構造を削除する。

37. コストと性能のトレードオフ

37.1 コストを下げる方法

• 古い会話を要約し、毎回送るトークンを減らす。
• 同じ公開検索やタイトル案を短時間キャッシュする。
• 軽量モデルを分類、要約、タイトル案へ使う。
• 高品質モデルを複雑な回答だけへ使う。
• 埋め込みを同期処理せず、変更時だけ再生成する。
• Web検索を必要な質問に限定する。
• 利用者・機能・期間ごとにクォータを設ける。
• 失敗時の自動再試行が外部費用を二重化しないようにする。

37.2 性能との交換条件

38. 主要な選択肢とトレードオフ

39. 想定される深掘り質問と回答の骨子

Q1. なぜセッションをCookieだけに保存しないのか

結論: Cookieには参照値だけを置き、機密情報をRedisへ分離します。

複数ワーカーで共有でき、認証コード、OAuth状態、Passkeyチャレンジ、管理者状態をブラウザへ露出しません。Redis障害時は安全側に倒して再認証を求めます。大規模化では、Redisを冗長化し、セッション専用の可用性を確保します。

Q2. Redisが落ちたら全機能を止めるのか

結論: 用途別に縮退します。

キャッシュや意味検索はなくても処理できますが、セッション本体と生成協調は影響が大きいので、偽のログイン状態を作らず、再認証や生成再接続を案内します。

Q3. LLMの回答が二重に保存されない保証はどこにあるか

結論: 開始時の重複拒否と、終端状態への条件付き遷移の二段構えです。

生成ジョブに利用者・部屋・要求IDの組み合わせを持たせ、開始時の重複を拒否します。イベント配信は重複しても番号で捨て、最終保存は終端状態への条件付き遷移と一意条件で一度だけ行います。停止と完了の競合は、最初に確定した終端状態を採用します。

Q4. SSEが切断したら回答を失わないか

結論: 生成はHTTP接続の寿命と分離されているため失いません。

イベントに番号を付け、ブラウザは最後に受信した番号から再接続します。再接続できない場合でも、ジョブ状態と保存済み部分回答を確認します。長期的には、イベント基盤の保持期間、再生位置、接続ゲートウェイのタイムアウトを設計します。

Q5. 6,900件の同時生成をどう処理するか

結論: APIワーカーは生成を直接実行せず、キューへ入れます。

生成ワーカーは提供者ごとの同時実行上限、利用者クォータ、優先度、公平性でスケジュールします。キュー長と待ち時間がSLOを超えたら、軽量モデルへの切り替え、待機表示、利用者ごとの制限を行います。ストリーム接続は生成ワーカーと分け、状態を共有します。

Q6. なぜチャット履歴を全部LLMへ渡さないのか

結論: 入力上限、費用、遅延、秘密情報の露出が増えるためです。

古い履歴を要約し、直近の会話と重要な記憶を残します。要約は派生データなので原文を置き換えず、必要なら再構築できます。要約が失敗しても直近履歴だけで回答できる縮退を用意します。

Q7. 他の利用者のメモをどう防ぐか

結論: すべての読み書きで利用者IDと対象IDを同時に条件へ入れます。

ルート、サービス、リポジトリで防御を重ねます。共有メモだけは有効な共有状態を別途検証します。キャッシュキーにも利用者の境界を含め、他人のレスポンスを再利用しないようにします。二人以上の利用者を使った越境テストを必須にします。

Q8. Prompt Injectionを完全に防げるか

結論: LLMだけでは完全には防げません。

参照データと命令を分離し、外部コンテンツのツール利用を許可表で制限し、保存・送信・公開などの重要操作はサーバー認可と人の確認を通します。

Q9. URL取得のSSRFをどう防ぐか

結論: 文字列検査ではなく、解決後のIPまで検証します。

スキームを限定し、DNS解決結果のIPがループバック、プライベート、メタデータ用でないことを検証します。リダイレクトごとに再検査し、接続時のDNS再解決による変化も防ぎます。応答サイズ、時間、コンテンツ種別、リンク追跡深さを制限します。

Q10. 画像をデータベースへ保存しない理由は何か

結論: 大きなバイナリと、所有権・公開状態・投稿メタデータは異なる性質だからです。

データベースには参照情報を置き、画像は安全な派生形式として保存します。小規模ではローカルボリュームで単純に始められますが、複数ホストではオブジェクトストレージとCDNへ移行します。

Q11. いいねと閲覧数は同じ一貫性でよいか

結論: 別でよい。機能ごとに一貫性とコストを選びます。

Q12. MCPは通常のWeb APIと何が違うか

結論: 外部AIクライアントが利用する機械向けのツール境界です。

ブラウザCookieではなくOAuthトークンを使い、ツールごとにスコープ、利用者、所有権、レート制限を検証します。メモとコンテキストの更新には版番号を要求し、公開投稿は直ちに公開されることを同意画面で明示します。

Q13. データベースのマイグレーション中に旧環境が動いていたらどうするか

結論: 旧環境が新しい列を知らなくても動く追加から始めます。

新旧両方を読めるコードをデプロイし、バックフィル後に新形式の書き込みへ切り替え、監視してから旧形式を削除します。Blue/Greenの切り替え前に検証し、破壊的な変更を一回のデプロイへ詰め込みません。

Q14. 最も大きい現在の弱点は何か

結論: 単一ホストのローカル画像保存と、バックアップ・復元訓練の運用です。

画像はオブジェクトストレージへ移し、データベースと画像を整合した状態でバックアップします。RPOとRTOを決め、実際の復元訓練を行うまで「災害対策済み」とは言いません。

Q15. 何を最初に測るか

結論: 利用者体験、費用、データ安全性に直結する指標から測ります。

API可用性p95遅延初回トークン時間生成キュー待ち時間LLM提供者別エラー率SSE再接続率DBプール使用率Redisメモリテナント越境

これらは次のスケール投資の判断材料になります。

Q16. AIが生成したUIをそのまま実行して安全なのか

結論: そのまま実行はしません。検証と隔離という機械的な仕組みで担保します。

LLMの応答からアーティファクト候補を抽出した後、決まったスキーマでの検証を必ず通し、HTML・CSS・JavaScriptをそれぞれ個別に安全化します。この検証を通過したものだけが、外部通信・フォーム送信・入れ子フレームを禁止したセキュリティポリシー付きの隔離されたiframeの中で動きます。利用できる外部ライブラリも一種類に限定し、CDNからではなく自オリジンの静的ファイルから配信します。

40. 現状実装と面接上の発展案を分けて話す

現在はRedisでイベントとジョブ状態を共有しています。6,900同時生成まで増えるなら、Redisの一時イベントだけに依存せず、生成キューと長期再生可能なイベント基盤を導入します。ただし、その分、再生位置、保持期間、重複、運用費が増えます。

41. 面接前の実践チェックリスト

42. まとめ

理解の順番としては、次のように追うと分かりやすくなります。

• 1. 境界フロントエンドとバックエンドの境界。
• 2. 認可認証と所有者確認。
• 3. 中心経路チャット生成とストリーミング。
• 4. 拡張メモ、公開コンテンツ、コンテキスト、MCP。

面接では、機能をたくさん知っていることよりも、要件を確認し、規模を数値化し、中心経路を一貫して設計し、障害と安全性を先回りして説明し、規模に応じてトレードオフを選べることが重要です。この文書を使うときは、各章を暗記するのではなく、自分の言葉で図を描き、仮定を置き、計算し、面接官の深掘りに合わせて一つの論点を掘り下げる練習をしてください。