2026/11/12
次Phase：AIチャットが仕事をつなぐプロジェクトの作業机（案B）

この資料の読み方

節 何を説明するか
0 提案方針：次Phaseの目的とChat Panel・Agentの役割
1 成長段階：QuickPost・家族招待から作品を育てる
2 現状と目指す体験の差。スクリーンショットの観察
3 案Aと案Bの比較。この節だけが比較資料
4〜5 案Bそのものの操作・画面設計
6 案Bと既存機能の接続、まだ確認が必要な点
7〜8 案Bの実装・評価の進め方と会議で決めること
9〜11 会議説明用の具体例（会議資料・物語・コース・動画・音声・家系図）

0. 提案方針：次Phaseの目的と役割

今回のplanningをシステムの次Phaseとする。コンピュータに不慣れな人が、やりたいことを普段の言葉でAIチャットへ伝え、Agentと協力しながら簡単にタスクを完了できることが目的である。

Chat Panelは、もともとの設計意図である orchestrator（仕事を組み立て、各Agent・ツールへ振り分ける役割） を担う。既存の振り分け機構は AI概要の4.3節 を参照する。次Phaseはこの役割を、素材の引き継ぎ、進行の把握、結果確認、保存、修正・再開まで一貫した利用体験にする。現在すべてが自動連携済みとは扱わない。

担い手 次Phaseでの責務
ユーザー 目的を伝える。必要な事実・内容・届け先を確認する
AIチャット／orchestrator 依頼を理解し、段取りと適切な既存機能を選び、Agent間の引き継ぎと結果を管理する
各Agent・既存ツール 担当する生成・変換・登録などを実行し、結果・状態・失敗理由を返す
プロジェクト画面 素材、今の作業対象、進み具合、保存済み成果物、次の操作を見せる

ユーザーにAgent名・MCP名・IDを覚えさせず、同じ説明や素材選択を何度も要求しない。対象が曖昧なら題名で確認し、チャットの返答だけで完了とせず、実際に結果を開けるところまで追う。既存権限・HostDataSource・bindingの契約は維持する。

次Phaseの評価は「機能があるか」に加え、利用者が依頼から成果物まで進めたか、説明・選択のやり直しが減ったか、中断・失敗から続きを再開できたかで行う。具体的な目標値は現行操作の実測後に決める。会議資料・物語・コース・動画・音声・家系図の各例から最初の実装対象を選び、同じ進め方を段階的に広げる。

決定済み：次Phaseの目的とChat Panelの役割。未決：詳細UI、実装順、各例の対応範囲。 以下の資料はその詳細を検討する提案であり、この文書更新だけで製品機能の実装を開始したとはしない。

状態：次Phaseの方向性はユーザー合意済み（2026-11-12）。詳細設計は会議・エージェントレビュー用の提案。未実装。初版2026-11-11。

対象は /social-ai/projects/[id]。本書では既存の Claude提案 を比較上「案A」と呼ぶ。案Aの5.3節にあるデータ保存方式の「案B」と、本書の案Bは別の意味である。

会議では 投影用ページ を開き、本書の決定表に沿って検討する。HTMLは外部サービス・ネット接続なしで表示・印刷できる。

案Bの基本体験

プロジェクトを開くと、作成途中の記事・教材・動画を選び、その素材、生成結果、次の操作が同じ作業欄に見えるようにする。

「今作っているもの」を画面が保持し、AIパネルや編集画面から戻っても続きが分かる。公開は作品ごとに行い、次の作品へ進む。プロジェクト全体の完了率は必須にしない。

「作品」は設計上の総称。利用者には目的に合わせて「記事」「第2回の教材」「動画」などと表示する。新しいDBモデルの追加をこの提案だけで決定しない。

追加方針（2026-11-12）：主導線は、サイトのプロジェクト画面とAIチャットパネルで会話しながら作成を進めること。チャットが目的の理解・作成・修正を受け持ち、プロジェクト画面が素材・対象・保存結果を見せる。以下の例1：会議資料を作るで具体化する。ユーザー合意は方向性に対するもので、個別機能の実装完了を意味しない。

1. 成長段階：まず使い始め、少しずつ作品を育てる

ユーザー合意（2026-11-11〜12）：全員にプロジェクト作成を求めず、QuickPostだけで投稿を完結できる入口を残す。必要になった人だけ家族・グループやプロジェクトへ進み、人物・家族ストーリー、経験談、教育コース、家系図などへ発展させる。これはユーザー合意に基づく入口方針で、会議決定とは区別する。携帯での利用も含め、各段階の製品対応状況は別途検証する。

段階 利用者がすること AI・作業机が支えること
0. すぐ共有 QuickPostで写真・短い文章を投稿する 最小入力で保存。下書き・公開・届け先を分かりやすくする
1. 一緒に使う 家族／グループを作り、招待する 作成・招待・参加状態を案内。誰に見えるかを確認
2. 置き場を作る （案）必要になったらプロジェクトを作り、名前・目的・参加者を確認する 目的の選択は会議で決める。素材と成果の置き場を案内
3. まず1つ作る 写真1枚の記事、短い録音の話、数人の関係から基本の家系図を作る 素材選択、人物・関係の確認、下書き／図の作成、編集
4. 続きを作る 思い出・経験談・教材、家系図の人物や写真を追加する 前回の続き、既存関係を保つ追記、結果の確認
5. シリーズへ育てる 記事を章・巻にまとめ、家系図を世代・分家ごとに整理する 並び順、目次、家系図の表示範囲、物語との関連
6. 複雑な構成へ 人物・家族・時代・テーマをまたぐ物語・コース・家系図をつなぐ 人物と記事の関連付け、素材の再利用、複数シリーズの整理

この順番は必須の一本道ではない。QuickPostだけで投稿を完結できる入口はユーザー合意済みであり、会議決定とは区別する。家族・グループ・プロジェクトの作成は必要な人だけが選ぶ。プロジェクト目的の選択は未決で、会議で決める。プロジェクトを使う人は素材や作品を後からまとめられる。初回から巻・章・全体構成を要求せず、作品の種類を変更しても既存記事を自動で再生成・移動・公開しない。家系図は基本例に含め、数人の名前と関係から開始できる。写真・全世代・物語記事は初回の必須条件にしない。詳しい家系図例は例7。

flowchart LR
  Q[QuickPostですぐ投稿] --> F[家族・グループを作り招待]
  F --> P[プロジェクトを作り確認]
  Q -->|後で整理したい| P
  Q -->|投稿だけで完了| DONE[QuickPostで完了]
  P --> O[まず1つ：記事・話・基本の家系図]
  O --> C[確認・編集・共有]
  C --> N[次の話・教材・人物を追加]
  N --> S[章・巻・世代・分家で整理]
  C --> Q

携帯では「すぐ投稿・録る」、作業机では「続きを作る・整理する」を中心にする。携帯でも編集・公開でき、PCを必須にしない。図の「必要なら」は、QuickPost単独で完了できる場合と、後から家族・プロジェクトへ進む場合を示す。QuickPostから入る既存データは種別を区別する。

  • 素材として追加：写真・動画・音声・文章を保存。「この素材で作る」「作成中の記事に使う」「後で使う」を案内。
  • 下書きとして追加：既存の下書きIDを関連付け、その続きを開く。
  • 公開済み投稿を関連付け：同じ投稿を参照し、公開状態・届け先を維持。再公開や同じ記事の複製を自動で行わない。

QuickPostの現在のAPIが各経路をどこまで支えるかは実装前に調査する。取り込み先プロジェクトを名前で確認し、権限内で既存のasset/post IDを利用する。通信再試行・連打で投稿や関連リンクを重複させない。別端末への引き継ぎは保存済み素材・下書きから再開できることを目標とし、未保存の入力や再生位置の端末間同期は別の検討事項とする。

シリーズ化は関連と順番の整理から始める。1素材を複数記事で使っても、素材の削除や変更を他作品へ自動波及させない。既存の関係モデル・公開権限を確認し、必要な追加データは後続PRで設計する。

2. 現状と目指す体験の差（スクリーンショットの観察）

Screenshot_60〜66を確認した。60はビルド端末でUI評価対象外。61〜66は画面の観察であり、ブラウザ操作・通信の実測はまだ行っていない。原画像は会議参加者のアカウント名などを含むため本資料へ転載せず、模式図に置き換える。

画面 観察できた事実 案Bでの改善
61 録音 保存した録音と「下書き13本」の案内が並ぶ 直後は今の録音の文字起こし・記事化を主操作にする
62 流れ AI開発コースにも「話にする」の案内。最新一覧にJSON・字幕ファイルが並ぶ 教材に合わせた文言、対象教材の流れ、関連ファイルをまとめた更新履歴
63 作る 機能カードが左側に集中し、同じ「AIパネルで開く」が並ぶ 作りたいものを選び、素材と設定を中央の作業欄で確認する
64 素材 同名の字幕・文字起こしファイルが独立して並ぶ 元素材との対応が確認できるものをまとめる。原ファイルは詳細から参照可能
65 結果 下書きと参照できない記事が大量の同じアイコンカードで混在 作業中・確認待ち・公開済みを整理し、参照不可は別枠で件数と理由を表示
66 ジョブ 同じ種類の過去の実行が多数並ぶ 対象作品の現在の処理を表示し、過去の実行は履歴へ

参照不可は「削除済み」と断定しない。権限不足・読込失敗・削除を区別できない場合は「参照できません」とする。

3. 提案の比較：案Aと案B

論点 案A（現文書） 案B
中心 プロジェクト全体の段階と完成までの件数 今選んでいる記事・教材・動画とその続き
次の操作 最も手前の未完了段 選択中の対象を優先、次に前回作業、確認待ち、新規作成
公開後 全部を届けるとプロジェクト完成 その作品は公開済み。修正や次の作成を続けられる
画面 流れタブの段の下に対象と操作 小さな段階案内と、対象のプレビュー・素材・操作を持つ作業欄
データ 既存データの件数集計が中心 既存データに加え、素材と生成結果の対応を確認する必要がある
実装負荷 集計・段階表示の拡張 選択保持・戻り先・生成結果への直接導線が必要

案Aの「既存の読み込みを再利用」「読めないものを0としない」「段の中に具体的な操作を出す」は採用する。

会議後の記録では、プロジェクト作成時に目的を選び、1話ずつ公開して続ける方針が記載されている。案A本文の「全体完成」と整合するよう、採用案決定後に文書を統一する。

4. 案Bの設計：作業の流れ

flowchart LR
  P[プロジェクトを開く] --> C{続きがある？}
  C -->|ある| W[作成中の教材・記事を選ぶ]
  C -->|新しく作る| N[作りたいものを選ぶ]
  N --> M[素材を選ぶ・追加する]
  M --> G[下書き・動画などを作る]
  G --> E[内容を確認・編集する]
  W --> E
  E --> V[公開範囲と内容を確認]
  V --> D[この作品を公開]
  D --> N
  E -->|作り直す| G

上の図は説明用。画面では既存対象の現在の段へ直接進める。すべての作品に録音・文字起こしを強制しない。動画・電子ブックなどは既存の配布・公開機能を確認し、未対応なら「保存」「ダウンロード」までを示す。生成完了と一般公開は別の状態である。

例：録音から記事

  1. 録音停止後、その録音の再生・保存結果を表示。
  2. 文字起こし中も同じ対象を保持。失敗時は「音声は保存済み。文字起こしを再試行できます」。
  3. 文字を確認・修正して「この記事の下書きを作る」。
  4. 完了した記事を直接開き、編集・読み上げで確認。
  5. 題名と届け先（家族・グループ・一般）を確認して公開。
  6. 公開先へのリンクと「次を作る」。

例：資料からコースの1課

資料を選ぶ → 課の題名・対象読者・内容を確認 → 下書き生成 → 本文と画像を編集 → この課を公開。別の録音が未処理でも、この課の公開作業は続けられる。

5. 案Bの設計：画面案とアイコン

AI開発コース                              [共有設定]
[＋ 新しく作る] [素材を追加]                [探す]

作業中のもの          第2回「AIを使うための準備」
──────────────────────────────────────────────
第1回 公開済み        素材 → 作成 → 確認・編集 → 公開
第2回 確認待ち                        ↑
第3回 作成中          本文・画像・音声のプレビュー
                      [編集する] [聞いて確認]
                      使用した素材：資料.pdf、録音
                      [公開前の確認へ]
──────────────────────────────────────────────
素材の棚              [すべて見る]
最近の作業：第2回の下書きができました [開く]

モバイルは対象一覧→選択対象の作業欄の1列。戻ると一覧の選択・検索・スクロール位置を復元する。AIパネルを開いた狭い画面でも横スクロールを要求しない。

意味 資料の記号 実装時の既存MUIアイコン候補 必ず添える文字
素材 📁 FolderOutlined 素材を選ぶ
作成 ✨ AutoAwesome 下書きを作る
編集 ✎ EditOutlined 編集する
確認 ✓ CheckCircleOutline 内容を確認
公開 ↗ PublishRounded この記事を公開
再開 ▶ PlayArrowRounded 続きから

記号・色だけで意味を伝えない。本文16pxを目安、操作領域44px以上。写真は実サムネイル、記事は題名と抜粋、処理は進行表示とし、すべてを同じ大きなアイコンカードにしない。初期案は主操作1つ、その他の操作を補助ボタンにする。

プロジェクトの公開ボタンは「プロジェクトの表示・共有設定」と区別する。記事公開と同じ意味に見せない。タブの削除・既定タブの変更は会議で決め、既存hashは互換を維持する。

6. 案Bの実現に向けた既存機能・未確認事項

既存の useProjectContents、useProjectJobs、ProjectMaterialsSection、ProjectOutputsSection、AI起動処理、公開ダイアログを再利用する。取得API、HostDataSourceのbinding、権限、データ形式をUI整理のために変更しない。

flowchart TD
  D[既存の素材・記事・ジョブ読み込み] --> R[既存IDで確認できる対応関係]
  R --> S[選択対象と現在の操作]
  S --> UI[作業欄・プレビュー・次の操作]
  UI --> A[既存AI・編集・公開機能]
  A --> F[完了結果のIDと状態を受け取る]
  F --> S

既存コードの確認先：

  • ページ本体：タブと読み込みの接続。
  • flowModel：現行は1話ずつの流れ。
  • deskModel：現在の次操作の選び方。
  • useProjectTab：hashと戻る操作。

上記リンクの実パスは apps/host/...。実装時に以下を調べ、根拠がない関連付けは行わない。

確認事項 分からない場合の表示・対応
素材→ジョブ→記事の既存IDによる対応 独立した素材として表示。ファイル名だけで新しく結び付けない
エディターからの戻り先と未保存状態 既存エディターの保存機構を使い、戻り先の追加は別途検証
完了通知が生成物のIDを返せるか 完了した処理の詳細へ案内。別作品を推測して開かない
project_purposesの保存可否 案Aの5.3節の指摘を最新Ghostで再確認。保存可能と断定しない
再開情報の保存先 同一ブラウザのみか複数端末かを会議で決定

7. 案Bの実装順と合格条件

  1. 対応関係の監査：録音→記事、資料→教材の2例で利用するID・API・戻り先を図にする。
  2. 画面試作：PCと携帯で上記2例を通す。既存機能への入口と結果への戻りを確認する。
  3. 対象保持と再開：タブ移動・AIパネル・編集後も同じ作品を表示。対象削除・権限喪失時は明示する。
  4. 関連素材・処理の整理：関連が確認できるファイルだけをまとめ、履歴と技術ファイルを折りたたむ。
  5. 公開前確認と回帰検証：公開対象・届け先・権限を検証し、旧URL・bindingの既存動作を確認する。
  6. 携帯・QuickPost接続：素材／下書き／公開済みの3経路を確認し、保存済みのものを別端末から開けるようにする。
  7. シリーズへの発展：単発作品を保ったまま順番・章・巻・目次を追加。人物・家族・経験談・その他のシリーズで試す。

追加の受入例：携帯で写真を保存→机で記事化、QuickPostの下書きを継続、公開済み投稿を公開範囲を変えず関連付け、通信再試行でも重複ゼロ、単発記事3本を既存IDと公開状態を保ってシリーズに整理する。これらをブラウザとAPIの実行結果で検証する。

合格条件：初心者に「録音から記事を公開」「資料から教材を作る」「翌日に続きを開く」を説明なしで試してもらい、操作の迷いを記録する。各テストで別作品への誤操作ゼロ、公開前の対象・範囲確認、戻る操作の復元、失敗時に保存済み素材が残ることを確認する。所要時間の目標は現行の実測後に決める。

実行テストはソース文字列の有無だけで済ませない。読み込み中・部分読込・API失敗・viewer・二重クリック・200件超・複数作品の並行生成を含むブラウザ操作で検証する。

8. 案Bの会議・レビューで決めること

30分の会議：現状画像の問題5分、案A/B比較5分、2つの操作例10分、決定事項10分。

決めること 案Bの推奨 決定欄
最初に見せるもの 作業対象の続き＋新規作成 未決
「完成」の単位 個別作品の公開・出力完了。全体完了率は出さない 未決
主な入口 新しく作る／素材を追加／続きから 未決
プロジェクト目的 新規作成時に選ぶ。既存は変更可能 未決
再開情報 最初は同じブラウザでの復元を対象 未決
タブ構成 作業欄を中心に、素材・公開済み・設定を補助として置く 未決
シンプルからシリーズへ育てる方針 初回は1作品、必要に応じ章・巻などを追加 ユーザー合意。詳細UIは未決
携帯・QuickPostとの接続 素材／下書き／公開済みを区別して引き継ぐ 方針合意。API対応・実装順は要確認

エージェントレビューでは、案A・会議後方針との整合、データ対応関係の根拠、権限と公開範囲、既存bindingとURL互換、初心者向け文言、検証可能な合格条件を確認する。レビュー承認は実装採用の会議決定とは別であり、本資料の状態を勝手に「決定済み」へ変えない。

9. 例1：プロジェクト内のAIチャットで会議資料を作る

会議で説明する場面

ユーザーはサイトで「プロジェクト画面改善」を開き、そこにあるスクリーンショットと案Aを素材として選ぶ。チャットへ「改善案Bを会議資料にして。比較表、操作の流れ、画面案も入れて、このプロジェクトにまとめて」と頼む。

想定成果物は①提案書、②会議用要約、③決定事項表の3件。これらを1つのプロジェクトに関連付け、内容を確認してサイトの記事として下書き登録する。元のMarkdownや図のファイルは必要に応じ素材として保管する。成果物が3件あっても、プロジェクトを3つに分けない。

会話と画面が一緒に進む

段階 ユーザーとAIの会話例 プロジェクト画面の変化
依頼 人「この素材から案Bの会議資料を作って」 対象プロジェクト名と選択素材を表示
方針 AI「提案書・会議用要約・決定事項表を作ります」 作成予定3件と使う素材を表示。必要な不足情報だけ聞く
作成 AIが本文、比較表、図を組み立てる 「作成中」→プレビュー。「未登録」を明示
修正 人「携帯からの操作例も追加して」 同じ資料のプレビューを更新
登録確認 AI「この3件を、このプロジェクトに下書き登録します」→人「登録して」 登録先と対象を確定
登録完了 AI「3件を下書き登録しました」 実際の登録結果から3件を表示。資料を開く／編集する
続き 人「提案書の比較表を短くして」 選択中の提案書を修正対象にする。曖昧なら題名で確認
公開 人「社内グループに届けたい」 記事・届け先・公開範囲を確認し、既存公開機能へ進む

「自然にできる」条件は、利用者がツール名・ID・ファイル形式を覚えず、同じ対象の続きを指示できること。保存前の草案、保存済み下書き、公開済み記事を画面で区別する。登録後の修正は既存IDを使い、別記事を増やさない。人がエディターで直した内容を古い会話で上書きしないよう、再取得と差分確認が必要。

sequenceDiagram
  actor U as 利用者
  participant P as プロジェクト画面
  participant C as サイトAIチャット
  participant T as 既存ツール・MCP
  participant S as サイトの保存先
  U->>P: プロジェクトを開き素材を選ぶ
  P->>C: プロジェクトと選択素材を引き継ぐ
  U->>C: 案Bの会議資料を作って
  C->>T: 権限内の資料を読む
  T-->>C: 利用できる素材
  C-->>P: 作成予定と資料のプレビュー
  U->>C: 携帯の操作例を追加して
  C-->>P: 同じ資料を修正
  C-->>U: 3件をこのプロジェクトに下書き登録します
  U->>C: 登録して
  C->>T: 確認済みの内容を下書き登録
  T->>S: 記事保存・プロジェクト関連付け
  S-->>T: 保存結果とID
  T-->>P: 成功した資料・編集先・失敗があれば理由
  P-->>U: 登録済み資料を開く・続きを編集
  U->>P: 対象と届け先を確認して公開

PC・携帯の配置例

プロジェクト：画面改善                [素材を追加]
┌ 資料と作業欄 ─────────────────┬ AIチャット ──────────┐
│ 提案書      下書き登録済み       │ 人：比較表を短くして    │
│ 会議用要約  下書き登録済み       │ AI：提案書を修正します  │
│ 決定事項表  下書き登録済み       │                       │
│ 選択：提案書のプレビュー        │ [依頼を入力…]          │
│ [編集する] [公開前の確認]       │ 対象：提案書           │
│ 使用素材：案A・画面写真         │ プロジェクト：画面改善  │
└───────────────────────────────┴───────────────────────┘

携帯は「資料を見る／AIと相談」を切り替える。プロジェクト名・選択資料は保持し、チャットから戻ったときに今修正した資料を表示する。浮動ボタンやキーボードで主操作を隠さない。操作ボタンも同じ対象を引き継ぎ、チャット入力だけを必須にしない。

既存機能と追加接続の区別（実装者・レビュー向け）

MCPガイドとチャットコマンドに基づく。以下は接続方針であり、この通し操作が現在すべて動作するという主張ではない。

処理 現在の機能 この例で確認・補うこと
プロジェクト付きAI起動 openAssistant のproject文脈 素材選択・作成対象・修正対象を最後まで保持
下書きの確認と登録 /content の content_draft_preview → content_register_draft、MCPの story.register-draft 任意の会議資料をContentBundleへ構成し、同一projectへ3件登録できることを検証
Markdownからの記事登録 外部MCPの post.markdown-draft Staff Access Token用。サイトのCookieチャットから直接流用しない。サイト内は利用者の認証を保つContentBundle経路で検討
素材ファイルの保存 ブラウザの既存アップロード、外部MCPの asset.upload MCP側から読めないローカルパスを渡さない。ブラウザからの実データ受け渡しを確認
図・会議資料の閲覧 Markdown・記事表示の既存機能 Mermaid・画像・表の保存後表示を確認。HTMLファイル保存だけでサイトページ公開とは扱わない
完了表示 既存のproject内容再読込 登録結果のIDから対象を直接開く。再試行で重複させない
公開 既存の編集・届ける機能 MCPの下書き登録とは別。権限と公開範囲を保持

プレビューの期限切れ・別ホスト・内容変更では再確認する。3件中1件だけ失敗したら、成功済み2件と失敗した1件を分けて表示し、失敗分だけ再開する。チャットを閉じても保存済み資料はプロジェクトから開ける。

会議での説明・評価

5分の説明は、①最初の依頼、②プレビューと会話での修正、③3件の下書き登録、④同じ資料の編集・公開の順に行う。参加者には「今どの資料を直しているか」「サイトに保存されたか」「誰に公開されるか」を各段階で答えてもらう。

受入条件：同じprojectへの登録、素材と対象の保持、本文・図・表の保存後表示、実際の登録件数、部分失敗からの再開、二重登録防止、編集済み本文の保護、携帯での往復を実行検証する。会議資料だけで本番動作を保証したと扱わない。

他の例も同じ書式（依頼→素材→会話と画面→既存機能→成果物→失敗からの再開）に揃える。次節は会議で用途の広がりを比較する例であり、今回すべて実装するタスクリストではない。

10. その他の例：長く育てる仕事と、短く終える仕事

ユーザー要望（2026-11-12）：人物・家族ストーリー、教育コース、短い動画、音声アナウンサー放送を、案Bの具体例として示す。以下の依頼文・長さ・件数は説明用であり、製品の制限や完成済み機能の保証ではない。

例2：人物の物語を1話から育てる

  • 依頼：「父の仕事の思い出を、写真と録音から1話にして。後で人生の物語にまとめたい」
  • 素材：携帯録音、写真、メモ。AIは不明な人名・時期だけ聞き、事実を補作しない。
  • 会話と画面：構成案→本文と写真の配置→「この言い方は父らしくない」で修正→下書き登録。対象の録音と記事を同じ作業欄で確認する。
  • 機能への接続案：既存録音・文字起こしとContent系の下書き経路。準備済みの長編資料には既存の人物物語登録を利用できる。任意の録音からの自動連携は要検証。
  • 成果物と続き：1話の記事を家族に公開。次の録音から2話目を作り、必要になったら時代・章・巻で整理する。
  • 失敗からの再開：文字起こし失敗でも元音声を残し、該当処理だけ再試行。公開済みの話は作り直さない。

例3：家族ストーリー・短い経験談

  • 依頼：「QuickPostの旅行写真とメモから、家族に見せる短い旅行記を作って」
  • 素材：権限内のQuickPost写真・動画・文章。既存投稿か素材かを識別する。
  • 会話と画面：候補を題名や写真で確認→下書き→「子どもの発言を加えて」で修正→家族への公開前確認。
  • 機能への接続案：QuickPostの既存プロジェクト関連付け、ギャラリー、Content系、既存の届ける機能。既存下書き・公開投稿の後付け接続は別途確認する。
  • 成果物と続き：旅行記1件。既存の公開投稿なら重複生成せず関連付けを選べる。後から「家族旅行」シリーズにまとめる。
  • 失敗からの再開：関連付け失敗時は元投稿を保持し、リンク追加だけ再試行する。一般公開へ勝手に変更しない。

例4：教育コースを1課ずつ作る

  • 依頼：「この資料から初心者向けのAI講座を作って。まず第1回だけ見たい」
  • 素材：資料、対象読者、学習目的。全体の章構成は提案しても、最初から全課を一括生成しない。
  • 会話と画面：構成案→第1回の説明・例・練習問題→「専門用語を減らして」で修正→下書き登録→公開。
  • 機能への接続案：既存コース用AI起動、Content系のプレビュー・下書き登録、既存エディター。サイト内は利用者の認証経路を使い、外部MCP専用のMarkdownコース登録を直接流用しない。
  • 成果物と続き：第1回の教材記事。次の課でも対象読者と方針を引き継ぎ、順序・目次を段階的に整える。
  • 失敗からの再開：第2回の生成失敗で第1回を消さない。途中の課だけ再開し、編集済み本文を保護する。

例5：短い動画を作る

  • 依頼：「この30秒の動画に中国語字幕を付けて、会議で見せられるようにして」
  • 素材：既存動画1本、字幕言語。完成する動画と字幕の形式を最初に説明する。
  • 会話と画面：AIがメディア処理へ引き継ぐ→進行表示→動画と字幕のプレビュー→誤訳箇所の修正相談→完成ファイルを開く。
  • 機能への接続案：既存メディアAgentの字幕・翻訳処理。字幕の焼き込み可否、字幕修正後の再生成経路、完成物の配布方法は実装前に確認する。
  • 成果物と続き：対応形式の動画／字幕を同じprojectにまとめる。出力完了は一般公開と区別する。写真だけから新規短動画を合成する用途は、既存機能の対応確認後の別例とする。
  • 失敗からの再開：元動画を保持し、失敗処理だけを再試行。字幕ファイルを新しい独立作品として大量に並べない。

例6：音声アナウンサー放送

  • 依頼：「この記事を、聞きやすいアナウンサー音声にして」
  • 素材：選択記事、言語、利用可能な声。編集対象は記事本文か読み上げ原稿かを明示する。
  • 会話と画面：読み上げ原稿の確認→既存読み上げ機能で生成→その場で試聴→読み方の修正相談→音声を保存して開く。
  • 機能への接続案：ニュース機能が有効なら既存News Agentの読み上げを候補にする。任意記事の受付、修正原稿の入力、projectへの結果関連付けは要確認。未対応のサイトでは実行可能と案内しない。
  • 成果物と続き：元記事と関連する音声。音声ファイル生成と放送先への配信は別。アバター付き動画放送は必要な場合の追加例とする。
  • 失敗からの再開：元記事・確認済み原稿を保持。生成失敗を公開成功と表示せず、試聴できる結果が得られてから完了とする。

例に共通するAIとAgentの役割

flowchart TD
  U[利用者がプロジェクト内で依頼] --> A[AIチャット：目的・素材・対象を把握]
  A --> C[作成内容を提示し必要な点を確認]
  C --> T{既存機能へ引き継ぐ}
  T --> S[人物・家族・経験談：Content系]
  T --> E[教材：コース案内とContent系]
  T --> V[字幕動画：Media系]
  T --> N[音声放送：対応するNews系]
  S & E & V & N --> R[結果を確認・保存・projectに関連付け]
  R --> P[画面で読む・見る・聞く]
  P -->|修正を相談| A
  P --> F[対象と範囲を確認して公開・共有]
  F --> NEXT[次の1件へ／必要ならシリーズへ]

この図のAgent選択・引き継ぎ・結果集約は目指す接続であり、すべてのAgent間連携が実装済みではない。素材や結果のID、権限、機能フラグを確認してから対応範囲を広げる。

会議では例1を通しで説明し、例2〜6を「依頼・使う素材・完成物・次へのつながり」で比較する。短い仕事では章や巻の入力を要求しない。長いシリーズでも、現在の1件の作成・確認・公開は同じ操作で進める。最初に実装する例と、その後に広げる例を会議で選ぶ。

11. 例7：家系図を作り、家族の物語へつなげる

会議説明用の設計例。既存のChart Agentを使い、まず数人から始め、世代・分家・人物の写真や物語を段階的に追加する。利用者にはCSVの操作を要求せず、人の名前と関係で依頼してもらう。

依頼・素材・成果物

「祖父母、両親、私と妹の家系図を作って。このメモと写真を使って、分からないところは聞いて」

素材は文章、家族への聞き取り、写真、既存の表。まずは文章だけでも開始できる。録音・写真中の文字を利用する場合は、読み取り結果を人が確認してから関係データへ渡す。対応していない入力形式を読めると案内しない。

最初の成果物は、確認できた人物・関係の表と家系図。写真なしでも図を完成できる。元資料と出力を同じプロジェクトに残し、その後、人物ごとの経験談・家族ストーリーと関連付ける構想へ広げる。

会話と画面の通し例

段階 会話例 プロジェクト画面
読む AI「6人の名前を読み取りました。『花子』さんは祖母ですか、母ですか？」 人物候補と不明な関係を表示。未確認を勝手に確定しない
整理 人「母です。祖母は春子です」 名前と親子・配偶者関係を修正し、確認用の表を表示
作成 AI「この関係で家系図を作ります」 対象の表→Chart処理の進行→作成された図
確認 人「妹の名前を直して。祖父母の枝を見たい」 対象人物を特定し、修正内容と表示対象を確認。操作対応は要検証
写真 人「この写真を祖母のところに入れて」 指定写真と人物の対応を確認して反映。顔だけで人物を断定しない
拡張 人「父方の親戚も追加したい」 既存の図を保持して追加候補を示す。同名人物は別人か確認する
物語 人「祖父の話も残したい」 対象人物の資料から記事の下書きへ。家系図とのリンクは追加接続として検討
共有 人「家族だけに見せたい」 図・写真・記事それぞれの共有範囲を確認。対応する既存機能で共有

AIと既存Agentの連携図

flowchart TD
  U[チャットで家系図を依頼] --> M[メモ・写真・既存の表を選ぶ]
  M --> D[人物と関係を整理]
  D --> Q{不明・矛盾がある？}
  Q -->|ある| ASK[名前と関係を人に確認]
  ASK --> D
  Q -->|確認できた| CSV[Chart Agent：関係の表を作る]
  CSV --> CHECK[表を確認・修正]
  CHECK --> CHART[Chart Agent：家系図にする]
  CHART --> VIEW[プロジェクト内で図を確認]
  VIEW -->|追加・修正| D
  VIEW --> PHOTO[必要なら写真を対応付け]
  PHOTO --> VIEW
  VIEW --> STORY[人物の話をContent系で記事化：追加接続案]
  VIEW --> SHARE[共有機能と権限を確認して家族へ]
  STORY --> SHARE

既存機能を使える範囲と追加設計

根拠：agentTasks.ts のChartタスク定義。タスクが存在することと、自然言語による全工程の連続実行ができることは別である。

段階 現在の機能 接続前に確認・補うこと
名前と関係から表を作る csv-create 同名人物、関係の曖昧さ、既存表への追記・修正の扱い
肖像を探す image-fetch（Wikimedia Commons） 歴史上の人物向けの候補。私人の家族写真の代用として自動検索しない
写真と人物を対応付ける image-attach 手持ちの家族写真を選択して渡せるか、対象人物のIDを維持できるか
表から家系図を作る csv-import 確認した表の引き継ぎ、結果ページのID、再試行時の重複防止
既存の家系図を取り込む page-migrate 元の人物・関係と配置の保持、対象プロジェクトへの関連付け
人物と物語をつなぐ Content系の記事生成・projectリンク 人物単位の安定したリンク、記事編集後も関係が維持される仕組み
家族だけに共有 各コンテンツの既存権限・公開経路 家系図ページ・画像・記事の権限を個別に確認。project公開だけで共有完了にしない

段階的に充実させる

  1. 数人の名前と関係だけで、表と図を作る。
  2. 写真、時期、説明を確認しながら加える。
  3. 世代や分家を追加し、大きい図は見たい範囲へ移動できるUIを検討する。
  4. 人物の経験談、家族の出来事、シリーズ記事を関連付ける。

AIが不明な生年月日・関係を創作しない。追加操作で既存人物のIDや人が直した関係を置き換えない。表作成・画像対応・図生成のどこで失敗したかを示し、成功済みの表や素材から再開する。図の生成完了と家族への共有完了は分けて表示する。

会議で確かめること

「6人のメモから作る→同名人物を確認→写真を追加→父方の枝を追加→祖父の記事を関連付け→家族への共有を確認」の順で説明する。機能の拡張はこの例全体を一度に実装する約束ではなく、まず表と図までの経路から選ぶ。

受入例：関係が曖昧なら確認が入る、既存IDと手修正を保持する、写真なしでも進める、誤った写真対応を直せる、再試行で人物・図を重複させない、別人の資料を誤用しない、図と関連写真・記事の閲覧権限が一致することをブラウザとAPIで確認する。