# client-a_定例
#client-a_定例 へのメッセージ＋ Aa @ #
メンバー一人ひとりのClaudeを、Slackアプリとしてワークスペースに登録したときの画面イメージです。 上の場面ボタンを切り替えると、チャンネルの会話が差し替わります。 議事録の自動共有、タスクのリマインド、仕様確認、AI同士のすり合わせまで、「誰のAIが・どの権限で・何をするのか」が会話の流れで分かるように作っています。
個人のAIは、ずっとチャンネルに居座るわけではありません。場面ごとに登場の仕方を使い分けると、うるさくならず、必要なときにだけ現れる存在になります。
本人とのDMだけに現れる形。リマインド、タスク整理、朝のブリーフィングなど、他人に見せる必要のない仕事はここで完結します。
チャンネルには常駐せず、@AI田中 のように呼ばれたときだけ、その人の知識と文脈を持って答えます。仕様確認や過去経緯の照会向き。
会議の終了、カレンダーの予定、タスクの期限など「出来事」をきっかけに自動で投稿します。送り主は個人ボットでなく共用アプリで十分な場面も多い。
メンバー同士のAIが、本人の文脈と制約を持ち寄って論点を先にすり合わせます。人は「決める」ところから入れるので、会議と往復が減ります。
上のモック以外にも、URAKATAの日常業務に寄せると、こういう場面が考えられます。いずれも「AIが下ごしらえ、人が判断と送信」の形に寄せています。
出社前に、自分のAIがDMで「今日の予定3件／返信待ちの重要連絡／昨日の積み残しタスク」を1通にまとめて届ける。全員に同じ時刻ではなく、本人の始業リズムに合わせます。
パートナーデスクの送信前チェックとして、AIが文面の下書きと「宛先・添付・金額」の確認リストを作り、承認者が1人押すだけで送れる状態にする。送信そのものは人が承認します。
休暇中のメンバーのAIが、権限を限定したうえで「担当案件の進捗はここまで」「戻りは月曜、急ぎは平井へ」と一次回答する。本人の代わりに決めることはしません。
金曜夕方、チャンネルの会話とタスクの完了状況から週報の下書きが上がる。メンバーは直すだけ。経営側は全チャンネル分をAIが横断要約し、月曜の会議資料になります。
新しいメンバーが「この案件の経緯は？」と聞くと、共用AIがチャンネル履歴とドキュメントから経緯を要約して返す。先輩の時間を取らず、何度でも聞けます。
月末が近づくと、AIが未提出のメンバーへ個別にDMで催促し、集まったら経理担当のAIが一覧化して渡す。「全体チャンネルで名指し催促」をしなくて済みます。
AI同士が会話できるからこそ、権限の線引きを先に決めることが前提になります。モックの会話も、この4つの前提で描いています。
個人のAIへの実行指示は、その持ち主からのものだけを受けます。他のメンバーからの依頼は「相談・質問」として扱い、実行する前に必ず持ち主に確認を取ります。AI同士の会話も同じで、相手のAIに命令はできません。
AI新井が見られるのは、新井さんが見られるチャンネルと資料まで。本人がアクセスできない情報には、AI経由でも届きません。不在代理のような場合は、読み取り専用など権限を絞った状態で出します。
クライアントへの送信、金額の確定、契約に関わる返答は、AIは下書きまで。最後の送信・承認は人が行い、AIの投稿には「AIが作成」と分かる表示を付けます。
個人のAIも法人環境の中で動かし、扱う情報は線引きルール（B1／B1条件付き／B2／C）に従います。個人アカウントのAIに会社の情報を持ち出さないことが、個人ボットを許可する前提です。
あわせて確認したLINE側の制約です。LINEのグループに入れる公式アカウントは1つまで（LINEの公式仕様）。メンバーごとにボットを入れることは設計上できないため、LINEは全グループ共通の会社名義アカウント「URAKATA｜パートナーデスク」1つが窓口になる形が前提です。 個人のAIが「本人として」登場するのは、Slackだけの話として分けて考えるのが正確です。
プラットフォーム上のアカウントの種別であり、表示される主体（名義）のこと。LINE公式アカウントや、Slackのアプリ／ボットユーザーがこれにあたります。「誰の名前で出るか」の話です。
そのアカウントの裏側で自動投稿・自動応答を行う仕組みのこと。「中の自動化が何をするか」の話です。つまり、公式アカウント＝入れ物と名義、ボット＝中身の自動化、と分けて捉えると両プラットフォームで話が揃います。