Claudeが会議への参加を予告。会議後の調査と成果物はどこに置く？
Claudeは11月10日の公式アップデートでMeetingsを「coming soon」と予告しました。今日からGoogle Meetに追加できる、という意味ではありません。目指す方向は明確です。Claudeが通話中にメモを取り、議論に合わせてチームのドキュメントを更新するというものです。
しかし、通話が終わると、もう半分の仕事が始まります。メモに出てきた製品の機能は確認済みでしょうか。「誰かが提案した」が「全員で決めた」に変わっていないでしょうか。同僚が続けて編集する原稿は、どこにあるのでしょう。
記録、ホワイトボード、タスク一覧がそろっても、これらの問題が解決したとは限りません。
Harbor Light Studioの英語のデモ用議事メモと2つの公式情報を使い、会議後の議論をYouMindで検証・編集できる引き継ぎ資料へ進める方法を紹介します。このメモは実際の会議の記録ではありません。事例は英語で、スクリーンショットは実際に操作した中国語UIのままです。
まず成果物を決める。必要なのは、もう1つの議事録ではない
製品コンテンツを担当し、編集者が公開用の説明を書き進められる資料を渡すとします。編集者に必要なのは、議論を最初から聞き直すことではありません。次の3つへの答えです。
- 決まっていて、そのまま進められる執筆方針はどれか。
- 根拠が足りず、まだ本文に入れられない話はどれか。
- 誰が追加調査し、誰が確認し、いつ渡せるのか。
これは「会議を要約して」とは違う仕事です。要約は議論の輪郭を残しますが、引き継ぎ資料は次の人が行動できるようにします。
別の公式記事ではWhiteboardsとSheetsのベータ提供が発表されました。DashboardsはClaude Dataに改称され、一般提供となっています。ただしcertified queriesとlive sharingは引き続きベータです。ホワイトボードで会議中のアイデアを整理することと、Claudeが参加者としてビデオ通話に加わることは別です。
ここで必要なのは、内容についての判断です。提供状況の違う製品を1つの話にまとめず、会議で出た発言をそのまま公開できる事実にしないことです。
メモと根拠を同じ場所に置く。ただし役割は分ける
まずは、1つのプロジェクトに3つの資料を置けば始められます。
ID | 資料 | 答えられる問い |
|---|---|---|
N1 | 英語の会議メモ | 誰が何を述べ、何が決まり、どんな疑問が残ったか。 |
S1 | Meetingsについて公式にはどう説明されているか。 | |
S2 | Introducing Claude Whiteboards, Claude Sheets, and Claude Data | 同時期の別製品では、何が実際に発表されたか。 |
YouMindの資料収集・リサーチ機能では、Webページと元のリンクを同じプロジェクトに保存し、選択した資料について質問して、編集可能な文書を作れます。今回のデモでは、メモと2つの公式情報を非公開のBoard Meeting Follow-through — Evidence to Deliverablesにまとめました。どちらのWebページも、プロジェクト内で全文を読めました。メモ、原文、その後の引き継ぎ資料が3つのチャットに散らばらず、同じ場所に収まっています。
保存するのはリンクだけではありません。今回の具体的な問いも残します。公開用の説明に使える情報は何か、追加の裏づけが必要なのは何か。この問いがあれば、資料を追加する基準ができます。疑問を解く公式説明には価値がありますが、見出しを繰り返すページを増やしても、結論の信頼性は上がりません。
メモ、2つの公式情報、文書が同じプロジェクトにあります。右側では公式情報の本文を読めます。
まず、N1の次の抜粋を確認します。
1DEMO ONLY — FICTIONAL MEETING NOTE — NOT A REAL MEETING OR CUSTOMER2Harbor Light Studio — Weekly product-content standup34Discussion notes5- Mina said several news stories describe Claude Meetings as a Team and Enterprise beta in Google Meet, with Claude joining as a visible participant and leaving if an external guest joins.6- Jordan said we should not publish those details as official product facts until we check Anthropic's own pages. He thought the official articles might describe Meetings as coming soon.7- The team agreed the public post should help readers place follow-up research and an editable deliverable, not teach anyone how to add a bot to a live call.8- Jordan offered to put the meeting note and two official Anthropic pages into a private research board, then separate decisions, claims to verify, and next steps.910Apparent decisions (still must be checked against official sources)11- D1. Treat Claude Meetings as announced, not as a feature we can instruct readers to use today, unless official documentation says otherwise.12- D2. Keep Whiteboards, Sheets, and Data distinct from Meetings.13- D3. Keep this week's working files in one private board: the note, official sources, and the editable brief.14- D4. Do not claim any automatic sync between Claude and the research board.1516Next steps mentioned on the call (excerpt)17- Mina: review a short English brief with three sections — Decisions, To verify, Next steps — before any public draft.
最初の項目で分かるのは、Minaが報道を紹介したことであり、製品の対応プラットフォームではありません。3つ目には明確な編集方針があります。4つ目にはJordanが調査整理を申し出たことが記録されていますが、期限はありません。
メモは議論の記録で、公式ページは製品の事実を確かめる根拠です。 同じ場所に置けば照合できますが、同じ種類の証拠として扱ってよいわけではありません。
成果物を作る前に、3つの区分に分ける
いきなり記事全文を頼まず、まず選択した資料をAIに3つに分けてもらいます。
- Decisions: メモに実際に記録された作業上の決定と、その根拠。
- To verify: 議論には出たが、今の資料では裏づけられない話。
- Next steps: 次に必要な行動、提案・協力を申し出た人、まだ決まっていないこと。
たとえばN1は、「実際の通話への参加手順は書かない」という決定の根拠になります。一方、Google Meet、対象プラン、表示される参加者、ゲストのルール、会議後のファイル保存先はTo verifyに入ります。S1の予告だけでは、これらの仕様は確認できません。流暢な文章で空白を埋めてはいけません。未確認とは、その機能が非対応という意味ではなく、現在の資料では結論を裏づけられないという意味です。
To verifyを疑問の置き場で終わらせないことも大切です。各項目に確認の完了条件を付けます。プラットフォームなら公式の明記、プランなら利用対象の説明が必要です。根拠が見つからなければ、それに依存する記述を外し、確認できた内容で進めます。調査の不足は文書の範囲に反映し、放置された質問一覧にしません。
編集上の提案も分けておきます。AIが3製品の比較図を勧めても、それは会議での合意ではありません。役立つ案ならSuggested follow-upに置いて承認を求め、黙ってDecisionsに加えないようにします。
タスク一覧を埋めるために日付を作らないでください。会議の日付は納期ではなく、「今週話した」は「金曜日が締め切り」を意味しません。Not specified in N1と書き、次の段階で確認できるようにします。
重要な箇所は元のリンクを開いて確認します。タイトルしかない、本文が読めない場合は、必要な原文を入手します。タイトルからAIに内容を推測させてはいけません。
実際に行った資料確認では、公式の「coming soon」を引用し、報道やメモにある未確認の詳細を別に列挙できました。その後、操作者が両方の公式ページを開き、引用と結論を照合しました。
最初に公式の表現を取り出し、次に根拠から書ける内容を判断します。メモで繰り返された発言が、製品仕様になるわけではありません。
プラットフォーム、プラン、参加ルールは未確認と表示されています。「この資料では裏づけられない」と「誤り」を区別した回答です。
次の人が引き継げる文書にする
続いてAIに文書作成を依頼しましたが、画面にはキャンセルと表示されました。最終的には、操作者が確認済みの資料に基づいて手作業で文章を書き、編集可能な文書Harbor Light Studio — Post-meeting brief (DEMO)として保存しました。Decisions、To verify、Next stepsの3節で、調査をその後の編集と引き継ぎに使える形にしています。
受け取る人の仕事から考えます。調査担当には不足と原文リンクを、編集者には使える論点とまだ書けない材料の区別を、確認担当には承認すべき版と状態を残します。同じプロジェクトで引き継げば、人ごとにすべての資料を複製する必要はありません。
3節の文書は手作業で作成・保存しました。出典リンク、未解決の問い、メモにあった次の行動が入っています。
次は再利用できる構成例です。根拠、担当の確定状況、日付が未指定であることも分かるように広げています。
1Harbor Light Studio — Post-meeting brief (DEMO)2Status: working brief; awaiting review, not approved for publication.34Decisions5- D1. Frame Meetings as announced / coming soon, not as a how-to readers can use today.6 Basis: N1, D1; S1, "Claude Meetings is coming soon."7- D2. Keep Meetings distinct from Whiteboards, Sheets, and Data.8 Basis: N1, D2; S2, product launch status.9- D3. Working arrangement: keep the note, sources and working brief in one private board.10 Basis: N1, D3.11- D4. Do not claim an automatic sync.12 Basis: N1, D4. This board does not sync with Claude or Google Meet.1314To verify15- Google Meet support, plan eligibility, visible-participant and guest rules.16- The exact location and format of post-meeting materials.17- Evidence needed: official documentation that explicitly states each detail.1819Next steps20- Research: Jordan offered to collect sources and check wording in N1.21 Confirm acceptance. Due date: not specified in N1.22- Review: Mina is named to review the short brief in N1.23 Confirm the review time and sign-off. Due date: not specified in N1.24- Suggested follow-up: prepare a short public explainer after review.25 Owner: not assigned in N1. Due date: not specified in N1.
N1、S1、S2は上の資料表に対応します。引き継ぎでは、それぞれの根拠から該当箇所やURLへたどれるようにします。末尾に参考資料を積むだけでは足りません。
「Jordanが調査を申し出た」は「Jordanが調査を終えた」ではありません。「Minaが確認する」は「文書が承認済み」でもありません。準備を完了と取り違えないよう、状態を保ちます。
次に、内部向け資料から公開用の説明へ
ここまでできたら、次の執筆作業として、議論に参加していない人向けの公開用の説明を依頼します。
公開用の文章に、社内の担当者や、誰がどのニュースを紹介したか、すべての議論は必要ありません。必要なのは、出典に支えられた明確な判断です。たとえば次のように書けます。
Anthropic has announced Claude Meetings as coming soon, with a stated direction of taking notes and updating team documents during a call. Preparing a draft during a conversation does not, by itself, resolve the research, review and handoff that follow.
1文目はS1に基づきます。2文目は仕事の進め方についての私たちの判断で、Anthropicが約束した製品の成果ではありません。発表内容と推奨する方法を、読者が区別できます。
これは、1つの調査を異なる切り口に使う考え方です。再利用するのは根拠であり、回答ではありません。メモは議論を、内部資料は次の進め方を、公開用の説明は読者が理解すべきことを伝えます。つながった仕事ですが、同じ段落を短くするだけでは全部を果たせません。
共同作業は、添付ファイルを送ることではなく、仕事を続けられること
同僚が必要とするのは、文書とその根拠の両方です。整ったファイルだけを送り、資料や未解決の問いを個人のチャットに残すと、次の人は探し直すことになります。
YouMind 1.2の共同作業アップデートでは、Boardの設定から同僚を招待し、内容の編集、タスクの実行、閲覧のみといった権限を付与できると説明されています。作業はプロジェクト内に残り、再び確認できます。磨き込んだSkillsもBoardで共有できます。
引き継ぎの順序はシンプルに決めます。調査担当が資料と状態を補い、確認担当が未解決項目を処理し、編集者が最終稿を直します。誰が編集でき、誰が公開版を承認するかはチームが決めます。AIが参加者一覧から役割を割り振るべきではありません。
方法が固まったら、「決定を抽出し、出典を確認し、不足を整理し、引き継ぎ資料を作る」を再利用可能なSkillにします。まず今回の引き継ぎを成立させてから、次回を効率化します。
渡す前に、会議に出ていない人に文書を開いてもらい、4つの問いに答えてもらいます。
問い | 文書に残すもの |
|---|---|
なぜこの一文を書けるのか？ | 「会議で誰かが言った」だけではなく、出典と該当箇所。 |
まだ書けないことは何か？ | 具体的な不足と、それを埋めるために必要な根拠。 |
次は誰に確認すればよいか？ | 記録された担当者や協力を申し出た人。未割り当ては未割り当てのままにする。 |
どの段階の文書なのか？ | 下書き、確認待ち、確認済み。文章の生成は承認ではない。 |
結論の根拠をまだチャットで探す必要があるなら、証拠を補います。タスク一覧が埋まっていても担当や期限が未確定なら、先に割り当てを確認します。成果物は、きれいな体裁だけではありません。議論を丸ごと引き継がなくても作業を続けられる必要があります。文書を変えたら状態も更新します。資料の追加は公開原稿の再確認を意味せず、1文の修正だけで未解決の問いが閉じるわけでもありません。
段階ごとに使える、再利用可能な英語プロンプト
以下は、自分の作業で使うための段階的な提案です。N1を自分のメモに差し替え、作業を裏づける資料を選んでください。根拠の確認でいったん止め、その後に執筆を承認します。
1You are my post-meeting research editor.23Inputs:4- N1: the meeting note5- S1, S2...: selected official sources and original URLs6Deliverable: an editable English post-meeting brief7Review date and timezone: [date, timezone]89Stage 1 — Evidence and note status10Check that the source text is readable.11If it is missing, ask for the relevant passage; do not infer12facts from a title or URL.13Extract short exact quotes with source titles and URLs.14Distinguish what the note records from what official sources15establish. A statement made in a meeting is not independent16proof of a product fact.1718Stage 2 — Decisions, questions and actions19List decisions actually recorded in N1, open questions,20and next steps actually mentioned.21Attach evidence IDs to each item.22Mark unsupported product claims [UNVERIFIED].23Keep editorial recommendations under Suggested follow-up,24not Decisions. Do not invent consensus or completed work.25For each action, record the named owner or offer to help.26Use [OWNER NOT ASSIGNED] and [DATE NOT SPECIFIED] when needed.27Do not infer a deadline from the meeting date.2829Stop here. Wait for my approval before drafting.3031Stage 3 — Editable brief32After approval, draft these sections:33- Decisions34- To verify35- Next steps36Keep recorded decisions, source facts and recommendations37visibly distinct. Cite the note and/or original source URL.38Preserve unresolved ownership, dates and review status.39Do not turn an offer into a confirmed assignment.4041For the Harbor Light example, label the document DEMO.42Do not invent Google Meet support, plan limits, guest rules,43file locations or an automatic sync with Claude or YouMind.44Do not write steps for joining a live call.4546Stage 4 — Handoff and optional public draft47Review the brief against the evidence and list remaining gaps.48Propose who should confirm each gap; label this as a proposal.49Only after approval, write a separate public explainer using50approved facts. Exclude private discussion and internal names.51Make editorial judgments distinguishable from source facts.52Do not invite anyone, share a board, publish, or send anything.
残るのは単に「議事録がある」という状態ではありません。次の人が開けば、根拠を見つけ、不足を把握し、原稿を直し、誰に確認すればよいか分かるプロジェクトです。
記録を、次の人が引き継げる仕事に変える。それが会議後に本当に残したいものです。
この記事について質問がありますか？
AIに無料で質問する関連記事
ChatGPTで企業プロフィールを申請できるように。ブランドを正確に説明してもらうには？
仮に利用者から「LinkedInへ直接投稿できますか？」と聞かれたとします。機能ページはSNSコンテンツの作成を説明し、営業資料では「運用の自動化」と要約され、FAQはまた別の説明だったら、どれを信じればよいのでしょうか。 OpenAIが企業プロフィールの申請に対応したことで、この問いはさらに具体的になりました。ただし、 プロフィールの所有権を申請することは、ブランドが情報を提供するための手段であり、ChatGPTの回答を制御する手段ではありません。 正確な紹介を目指すなら、まず自社が公開している事実を検証できる状態にしましょう。 ここではYouMindの公開ページを確認し、資料を Brand Facts — Evidence Before Claims に整理し、編集可能なブランド事実資料とFAQの2つを残します。デモの内容は英語、画面は中国語です。独立系ツールのチーム、クリエイターブランド、マーケティング担当者にも応用できます。 OpenAIの には、Businesses in ChatGPTのベータ版を2026年11月10日に開始したと記載されています。対象企業はBusiness Hubからプロフィールの所有権を申請し、最新情報を提供し、利用可能なインサイトを確認できます。チーム用ワークスペースのプランChatGPT Businessとは別のものです。 3つの境界線を覚えておきましょう。 では、情報の変更には審査が必要で、回答への反映は即時とは限らず、ChatGPTが他の資料も参照し得ると説明しています。 にも、プロフィールを申請しても掲載順位の向上や売上は保証されないと明記されています。 プロフィールやAgentの利用資格がまだ分からない小さなチームでも、ホームページ、機能、料金、FAQが同じ質問に一貫して答えるよう整えることはできます。 今回の操作では3つのリンクをBoardに追加し、AIタスクの資料として選択できました。YouMindの なら、資料と編集可能な下書きを同じプロジェクトに置けます。ウェブページを読みながら、散らばった下書きを探す必要がありません。 同じBoardに3つの資料と2つの文書があります。プレビューにはタイトルとプレースホルダーしか表示されておらず、全文を読み込めた証拠ではありません。 以下は有用な思い出です。 リンクを追加することは、そのキーパスがチェックされたことを意味しません。 オペレーターは公開ページを直接開き、それらを手動で比較し、AI草案のサポートされていない解説を修正し、コピーおよびLinkedInへの投稿に関する指示や、テキスト中に検査中に見つからないビデオプラットフォームの名前を付けた。 The final drafts retained supported claims and marked the rest. 最終的な草案は支持された主張を維持し、残りのものを指定しました。 Not established. この表示は「選択した資料では結論を裏付けられない」という意味で、「その機能が製品にない」という意味ではありません。この区別は重要です。 まずAIにこう尋ねます。 ページ間の矛盾だけを求めないでください。 パラフレーズがさらに一歩進むと、多くのエラーが生じます:編集は出版になり、使用例は主な顧客セグメントになり、またはソースを組織することは自動的な事実検証になります。 今回の確認では、次のように整理できます。 検証の単位は個々の主張であり、ウェブページ全体ではありません。 ページは、「スクリプトを書く」をサポートすることができ、それに付属するすべての約束をサポートすることなく。 根拠を確認した後、結果を編集可能な英語文書にまとめました。 Brand facts and evidence。スクリーンショットには確認済みの機能だけでなく、 What cannot be inferred — Not establishedもあり、後の執筆で境界を見失わないようにしています。 資料は出典と根拠を残し、根拠不足と機能の否定を区別しています。 あなたのブランドのために、この構造を再利用してください: これは再利用のために整理した資料構成で、スクリーンショットの逐語訳ではありません。日付は今回の確認日です。ページにない更新日を作らないでください。 ページを変更すると、全体の紹介文を書き換える必要はありません。 影響を受けた主張を特定し、その後、証拠IDを通じて短編、FAQ、ページを更新します。 紛争したアイテムを所有者とオープンな質問に残し、古いバージョンを静かにデフォルトの答えになることを許すのではなく。 今回の3資料では料金を確認しきれないため、金額は記入していません。自社の確認では料金・ポリシーページも追加し、請求周期、通貨、手数料の条件、含まれる機能と上限、超過時のルール、解約が有効になる時点を確認してください。 機能ページに対応と書かれていても、全プランの利用権が同じだとは限りません。 次の文書は、 Source-backed FAQ draftは、製品の定義、想定される利用者、LinkedInの下書き、動画脚本、直接公開やChatGPTの推薦を意味するか、という5項目を扱います。宣伝の繰り返しではなく、利用者の次の判断を助けるための文書です。 FAQ では、質問、答え、リニア編集のためのソースを保存します。 次の5つのテーマは同じです。 学習と創作のためのAIスタジオです。資料をBoardに保存し、AIで調べ、編集可能な成果物を作ります。 [E1] これらのページでは、資料からの学習、LinkedInコンテンツ、動画脚本の準備が紹介されています。作業が合うかの判断には役立ちますが、特定の層が主要顧客であるとは判断できません。 [E1–E3] はい。LinkedInページでは、メモ、調査、経験を投稿、文書カルーセル、記事にまとめる流れを紹介しています。 [E2] はい。冒頭や切り口を見つけ、物語を構成し、想定するプラットフォームと視聴者に向けて明確な脚本を書くことを紹介しています。脚本の下書きができても、動画の制作や公開が終わったことにはなりません。 [E3] そのようには解釈できません。コンテンツの作成は、プラットフォームへの公開完了を意味しません。この確認では、自動公開、ChatGPTへのFAQ自動送信、推薦の保証は裏付けられていません。それぞれに根拠が必要で、下書きの生成だけでは不十分です。 事実資料とFAQは同じ根拠を使いますが、答える問いは異なります。これは、 と同じ考え方です。内部資料は「何を確認できるか」、FAQは「判断する前に何を知る必要があるか」に答えます。 ホームページ、機能、料金、FAQを並べて、利用者の判断に影響する文章を優先して確認します。 製品記述の書き換えには明確なルールがあります:仕様と主張のための正確なオリジナル材料を使用し、共有する前に結果をチェックします。 公開ページを修正することは、曖昧な導入に新しい入力点を与えるよりも有用です。 Business Hubの利用を検討する適格なチームは、この資料を手作業で情報を整理する際の土台にできます。ただし、この作業によってYouMindからChatGPTへ自動同期されるわけではありません。文書やFAQを作っても、それが採用・引用されるとは限りません。 最初にソースを選択し、監査で停止し、作成前に承認してください。 最後に残すものは2つです。 根拠と確認日付きのブランド事実資料と、回答を1つずつ修正できるFAQ。 プロフィールの申請は、情報を提供する新しい経路にすぎません。ブランドに何ができ、どんな条件があり、利用者が何を行う必要があるのかを明確にすることは、今できる仕事です。
ひとつのリサーチから、同じ段落を5回書き直すのではなく、異なるコンテンツを作るには？
いくつかの資料を読み、自分の見解をまとめる。XとLinkedInに投稿し、YouTube動画にもするつもりです。 そこでAIに頼みます。「短い投稿にして」「もっと専門的に」「話すための台本にして」。 すぐに3本の原稿ができあがります。しかし並べてみると、1本目は結論、2本目は結論を長くしたもの、3本目は結論の読み上げ。最初の投稿を見た人が、次も読む理由はありません。 問題は書き換えの質ではなく、最初から3本とも同じ問いに答えていることです。 再利用すべきなのは調査資料であり、各コンテンツの中心となる問いではありません。 ひとつのリサーチから複数のコンテンツを作れますが、それぞれが新しい理解や、別の判断につながる必要があります。 ここでは「クリエイターは動画の字幕をどう確認するか」を例にします。YouMindの同じBoardに3つの公開資料を集め、問いを分け、根拠を確認してから、英語の短文投稿、論説型の投稿、動画台本に整理します。操作画面は中国語、デモの内容は英語です。 共通のリサーチから、まず異なる問いを作り、それぞれの内容を決めます。 中国語画面の「项目→创建项目→新建项目」から進み、Boardを One Research, Three Content Angles と名付けます。「文件→添加资料」に3つの資料URLを貼り付け、「添加链接」を選択。今回の操作では「已添加3个」（3件追加済み）と確認でき、3つともプロジェクトに表示されました。次に、選択した資料について質問します。YouMindのなら、資料、調査の対話、編集可能な原稿を同じプロジェクトに置けます。 最初に何十件ものリンクを集める必要はありません。問いに答えるための、最小限の根拠リストを作ります。 資料： · · Boardで最初に聞くのは「3本書いて」ではなく、次のことです。 回答を読んだら、重要な文を原文と照合します。URLも確認してください。3番目の資料の実際のタイトルは Edit or remove captions - YouTube Help、つまり「字幕の編集・削除」です。想定とタイトルが違っても、資料が欠けているとは限りません。たとえば「必要な非発話の音声情報を含める」はS2の記述ですが、「引き継ぎ時に確認担当者を決める」は私たちの提案です。どちらも書けますが、まとめて業界標準のように扱ってはいけません。 YouTubeの自動字幕ガイド、W3Cの字幕ガイド、YouTubeの字幕編集・削除ガイドが追加されています。 「動画の字幕」はテーマであって、3つの企画ではありません。読者ごとの状況に当てはめると、問いが見えてきます。 3人が使う資料は同じでも、必要な答えは異なります。1人目には判断、2人目には協働の方法、3人目には見落としやすい細部の理解が必要です。 YouMindのはよい出発点になります。Boardの資料から3〜5個の切り口を提案し、それぞれを支える資料を示す方法です。さらに「見出しが違うだけでなく、異なる読者の問いに答えているか」で絞り込みます。 各問いについて「中心的な主張—根拠ID—読者の得られるもの」を埋めます。視聴成果のデータがなければ成立しない切り口は、データがない限り保留にします。3本そろえるために「視聴完了率が上がる」といった根拠のない結論を足してはいけません。 Evidence brief + three anglesでは、まず資料を確認し、事実、根拠の限界、編集上の提案を分けています。 今回の操作では、調査と切り口を編集可能な文書 Evidence brief + three angles に整理し、X、LinkedIn、YouTubeの3部分を別の編集可能な文書 Three channel drafts に書きました。3本を同じ文書に置くと比較しやすく、プラットフォームごとにファイルを分ける必要はありません。 Three channel draftsは、異なる問いに答える3媒体分の内容を、ひとつの編集可能な文書にまとめています。 表現方法より先に、各原稿に問いを割り当てます。以下は3つの切り口を公開用の例に整えたものです。媒体が変わっても、この3つの問いは成立します。 答えるのはひとつだけ。自動字幕が生成されたことは、確認が終わったことを意味するでしょうか？ S1を使い、生成はシステムの状態、確認は編集の仕事だと区別します。ここで字幕制作の全工程を教える必要はありません。 2本目の役割は確認作業を組み立てることであり、1本目を長くすることではありません。調査を専門的な見解にする際は、YouMindのが参考になります。資料にある観察と自分の解釈を分け、明確な見解にまとめます。 S2とS3を組み合わせ、検収の方法を提案します。「自動字幕は要確認」と知っている読者も、次に編集者へ何を引き継ぎ条件として伝えるかを学べます。 3本目は、発話以外に何が抜け落ちるかを扱います。YouMindでこのを作るときは、映像とナレーションを分けましょう。説明するだけではなく、見せるべき情報が分かります。 シーン1：録画方法のチュートリアルを見せる。 画面の文字： ナレーション： シーン2：タイマーが鳴り、画面を停止する。 ナレーション： シーン3：音が鳴る位置に字幕を入れる。 画面の文字： ナレーション： 最後の画面： S2で音の情報を補う理由を説明し、S3でタイミング調整につなげます。前の2本を読み上げるのではなく、問題が起こる様子を見せる内容です。 3本の下書きがそろったら、次は推敲の前に重複を確認するのがおすすめです。字数や語調ではなく、中心となる答えをYouMindに比較してもらいます。 媒体名を隠しても、3本の役割は異なります。1本目は確認を終えてよいか判断する、2本目は誰が何を確認するか決める、3本目は特定の欠落に気付くための内容です。 反対に、次はよくない書き換えです。 3本に見えても、答えはひとつ。箇条書き、語調、導入は増えましたが、解く価値のある問いは増えていません。 「1本目の後に2本目を読んで、何が新しく分かるか」と自問します。「詳しくなっただけ」なら、問いに戻って修正しましょう。YouMindの原稿は編集を続けられます。この段階で変えるのは数語ではなく、原稿の役割です。 Boardの調査に続けて使えるプロンプトです。執筆より先に切り口を確認し、同じ答えが3種類できるのを防ぎます。 共通の資料はひとつのBoardに、答える問いは3本それぞれに。大事なのは一度に作るバージョンの数ではありません。 ひとつの調査を無理に5本にする必要はありません。異なる2つの問いを支えられるなら2本書く。3つ目の根拠が足りなければ、次の機会に回します。 再利用の目的は、同じ文を何度も出すことではありません。同じリサーチで、答える価値のある問いを増やすことです。
ソロAIコンサルタントがクライアント業務を再利用可能なYouMind Skillsにする方法
新規のクライアントのエンゲージメントはゼロから始まります。 オートメーションスタックをマッピングする方法は既に知っています。 YouLinkedIn0クイックスタートパックを作成しました。 AIエージェントが実行できる何かに混乱の反対プロセスを回す Playbook を書きました。 その後、次のクライアントは、同様の問題に着きます。チャット履歴、プロンプト、および最後のジョブのハーフフィニッシュドドキュメントは、期限の圧力で再オープンしない場所で埋められます。 これは、ソロコンサルティングの静かな税です:メソッドすべてのエンゲージメントで改善しますが、アーティスト次の1つを助けるために十分に長く生き残ります。 この記事は、ポイント・オブ・ビューのメソッド・ピース(顧客ケース・シリーズではなく)をプラスする方法です。 主にチャット・ヘビー・デリバリーのウェブアプリやブラウザの拡張機能など、ライティングやイメージの生成が混在するソロAI自動化コンサルタントをイメージしています。 下のウォークスルーは、評判の良い製品デモ(英語UI、実際の2026-10-26で実行)で、メソッドを Skill としてパッケージする方法を示しています。クライアント名は、顧客の成功事例ではなく、プレースホルダーです。 この種の練習では、4つのワークストリームが再び現れます。 1. ⟦Agent0ビルドとモデルアグノスティック Playbooks. クライアントのワークフローは、再利用可能な「エージェントビルドのステップパック」に壊れています。構造化されたプロンプトと1つのモデルにロックされていない手順。 ⟦Boards0 はプロジェクト材料を保持します。 Chat は Playbook がドラフトしてきつく場所です: どの入力を収集するのか、エージェントが理由、ハンドオフがどのようなものなのか、尋ねるものです。 2. コンサルティング・セールスマッピング 何かを構築する前に, あなたは機会をスコアし、ランク付け: CRM /オートメーション再販業者と導入の世界で, その作品は、再販や実装価値がありますお問い合わせクライアント、ワークフローのギャップが最初に進むべきか。 クライアント間で「スコア/ランク」パターンが繰り返されます。 3. 商業提供のためのマーケティング パック。 Foodservice / Kitchen-ops関連のオファーには、キャンペーンのフラミングと ⟦LinkedIn0-styleのファストスタートパックが含まれます。位置決め、ポストシーケンス、および起動コピー。 類似のパックは、垂直とジオを横断表示します。 4。 社会的およびコミュニティコンテンツエンジン。 X投稿、⟦LinkedIn0パック、コミュニティスタイルのエンゲージメント投稿、リズムで出荷しなければならないコンテンツ。 音声、構造、CTA パターンが納品を繰り返します。 繰り返すタスクタイプパッケージメソッドと同じではありません。 週に空白のチャットから同じ構造を書き換えれば、すでに獲得した判断を捨てています。 階層パターン: Boards は、各エンゲージメントのマテリアルを保持します。 Chat は、ステップと QA をロックします。 Skills は、固定方法を保持し、業界、都市、プルーフポイント、トーンを入力として残します。そのため、次のクライアントは、構造の再構築ではなく、入力のスワップです。 これは、 ⟦YouMind0 の定義にマッチします。: 明確な問題、入力、ステップ、および実行可能で繰り返すAIワークフロー、ユーザーが入力する変数トピック/材料を残して (参照))。 onceChat⟧で一度入力したプロンプトが壊れています。 A ⟦Skill0 は、固定されたものと、次のクライアントがスワップするものを決めた後と同じ方法です。 正式な提案は簡単です: 実行後、あなたは満足しています, と尋ねます Agent プロセスを ⟦Skill0 - 再使用可能なルールをキープ, 入力に毎回変更する部品を回します, その後、異なるトピックと、通常の入力がまだ造船可能なドラフトを生成するかどうかを確認するために不完全な入力. コンサルティング条件:最初のクライアントは、発見と基準のために支払います。 ⟦Skill0は質問リスト、入力フィールド、QAバーを保持します。 次のエンゲージメントは、これらの手順を再使用し、チェック—新しいジョブがまだ ⟦Skill0 のスコープの中にいる限り。 マーケットプレイスプランは必要ありません。 クライアントがすでにやりとりしたワークフローを1つから始めます。 再販業者の機会行列、エージェントビルドのアウトライン、 ⟦LinkedIn0 起動パック、週刊コミュニティエンゲージメントエンジン。 書きます: ソースのメモ、過去の成果物、およびサンプルを Board にドロップすると、コンテキストは頭に閉じ込められません。 デモ Board withNorth Bay0 簡略と品質バーノート クライアントの簡単な文書を開く Chat は、その 0Board0 を使って、混乱の専門知識をクリアなシーケンスに変える: 質問 → 解析 → ドラフト → QA チェックリスト。 プロス上のプレッダ構造。 最後の時間からトリックを覚えているときにのみステップが機能している場合は、トリックを Playbook に書きます。 Run は、実際の(または現実的な)クライアントのシナリオで一度。 壊れたものを固定します。 その反復お問い合わせメソッドを定義します。 注意: inAsk⟧ / ⟦Chat0 モードでは、最初のパックは頻繁にチャットスレッドに滞在する. 保存 ⟦Markdown0 (または他のファイル) に Board は別のステップです。 または、 .Agent⟧/write フロー。 alwaysChat⟧ いつもあなたのために ⟦P11 文書を書きます. Chat attachedBoard0材料チップ付き Chatで1ページをドラフトする位置 Chat は、クライアントを喜んで手渡しする何かを生成するとき、メソッドを ⟦Skill0: 安定した手順と標準をロックします。トピック、ニッチ、オファー、および入力として材料を残します。 ⟦Skill0 は “もはやプロンプト” ではありません。 通常の入力が使用可能な出力を生成するまでテストした作業方法です。 v1を狭く保つ。 「 localLinkedIn0 ローカルフードサービス向けスタートアップパック」が「ソーシャル Skill 」を打ち破る。 名前をつけると、 rememberP1 remember40文字のタイトルフィールドキャップ—フルネームが合わないと、サブタイトルまたは ⟦Instructions0 で詳細を出力します。 ここはウォークスルーです。 良い Chat の実行後、 Agent: “これを ⟦Skill0 に投げる — 手順と QA を固定し、クライアントフィールドを入力させます。” 我々が使用したデモで⟦Create skill → → 0Create with YouMind0privateSkill privateプライベート(0Only me0) 実行からプライベートな ⟦Skill0 を作成することを確認します 1ページの位置(抜粋) 近隣のレストランのオーナーがキッチンの設備を「固定」から「カレンダーの視点」に移動させるお手伝いをします。 最近のメンテナンスフォローアップ(匿名化)から証拠が来ます。 次のステップ:最初の1年限りの契約ではなく20分の検査評価を予約する。 1つの仕上げポスト(意識) ホック: 台所のダウンタイムの時間は部品より失われたカバーの多くを要します。 ボディ:多くの店は緊急事態として修理を扱います。 フィルター、シール、プローブは予測可能なウィンドウを持っています。 「カレンダーに遭遇したときの呼び出し」からシフトし、お客様が選択した時間に夕食のラッシュをオフします。 CTA:レストラン名と近所をDMに「インスペクト」とコメントして、1ページチェックリストを送信します。 イメージノート: クリーンキッチンコーナー+手書きカレンダー(実際の店先なし)。 ありますなし別のマルチフィールド ⟦Skill0 入力フォーム. 可変的な部品は、通常、このように上陸します。 チャンネルがまだステップ1チェックに収まるかどうかは、一般的なコピーフィールドではありません。 上記の表はメソッドスケッチです。コメントはありませんウィジェットを作成します。 スクリーンショットの場合、実行面を ⟦Skill0 詳細ページと組み合わせます。 Skill 実行面: ⟦Input hint + + スキルチップ(マルチフィールドフォームなし) プライベート Skill 詳細: listedInstructions inside 次のエンゲージメントはまだローカルフードサービス - デモでは、例えばクライアント⟦Harbor District Kitchen Supplies0: : : あなたがロックする前に ⟦Skill0: 欠如の証拠 → 尋ねるか、またはスキップします。 決して発明しません。 共有された指示から優先クライアントの事実; 古い会社名とjargonが入力に移動しました。 公開する前に、少なくとも1つのスワップまたはストレステストを実行し、パスバーを書き込みます。 「ローカルフードサービス × 0LinkedIn0 発売パック」 Skill 3つの小テスト(サンプル入力が細かい)Bは外視鏡境界試験です:「業界の言葉をスワッピングし、そのまま再利用する」というわけではありません。 tSkill0 がまだ実行を強制するかどうかを確認します。 Harbor Districtリユースショットは、デモ条件下で同じスコープスワップを示しています。 1つの成功したデモは証明しますお問い合わせ条件 - 時間の節約、収益の上昇、または普遍的な安定性。 ⟦Harbor District Kitchen Supplies0 試験合格後: openP1 open, スワップ入力, 最初のドラフトを取る, それからあなたの声で編集. Boardsはまだこのエンゲージメントの材料を保持しています。 Skillのみメソッドを運びます。 プロダクト先端:⟦Run0開くことができます最後の使用 ⟦Board0, ない notBoard0 whereSkill⟧. 新規クライアントの実行前に、右 ⟦Board0 (またはスイッチ) にあることを確認してください。 方法があなたの練習の外の人々を助ければ、タイトル(≤40 文字)、記述および実質のサンプルを磨くことは、それから考慮します. 出版は任意です;インセンティブは現在のプロダクト規則に従います。 ほとんどのコンサルタントのために、作品のプライベートリユースすでに十分です。テスト後に一度公開します。 単独のオペレータは、タイプにはほとんど時間を無駄にしません。 彼らはそれを無駄に再配達判断: どの質問をするか、CTA がチャネルに合い、QA ゲートが弱いドラフトをキャッチする基準事項をランク付けする。 Skills これらの質問リストとチェックを保存します。 Boardsは、各エンゲージメントのマテリアルを別々に保ちます。 Chatはまだ固定されていない方法のためのワークショップを残します。 一緒に「もうひとつのブランクチャット」から「書かれたプロセスの他の実行」にシフトする作業単位。 あなたはフルタイムになる必要はありません ⟦Skill0作成者. ゼロから再起動するために使用した1つの Playbook が不要です。 同じクライアントのワークフローを再発明し続けると、実際のジョブで一度ループを実行します: キャプチャ → ドラフト →Chat → → (オプション) は、 onlyAgent0 → 不完全な入力でテストをパッケージ化し、必要な場合はスコープから → スワップ入力をスコープ内で実行します。その後、公開するかどうかを決定します。 atSkills Exploreと0Boards0, 読む. 2 回行った 1 つのクライアントプロセスを選択し、5 つの手順を実行します。通常、別の空白のチャットよりも 1 時間より良い。