S7：AIを中心としたチームを作る

会社は、情報を取りに行かない。上がってきた日報と議事録から、会社の記録を作る。

このスキルで手に入るもの

従業員がいる会社で、一人ひとりが会社全体の決定と動きを見ながら動ける状態。そして、各自の活動が事実として記録され、上長や管理職がそれを見て判断できる状態です。

作るものは2つです。

全社参照アセット：会社の決定台帳、案件ごとの現在地、朝会ブリーフ。従業員が動く前に引くための情報です。
ファクトベースの活動記録：一人ひとりの「何をしたか・何が終わったか・何にヘルプが必要か」を、日報から事実だけ抜き出して残す記録と、期ごとの判断材料シート。上長・管理職が確認するためのもので、判断するのは人間です。

S6では、経営者が自分の操縦席から、AI・業務委託・アルバイトに仕事を出しました。S7では、それを従業員がいる会社の仕組みに広げます。経営者1人が全員を見るのではなく、記録が集まり、上長に例外だけが上がり、全員が同じ決定を引ける形です。

なぜ必要なのか：日報は、書かれず、読まれなかった

日報は昔からある仕組みです。それでも、多くの会社でうまく回ってきませんでした。理由は単純で、書く側にも読む側にも、得がなかったからです。

書く側にとって、日報は「1日の終わりの、もう1つの仕事」でした。疲れた最後に、思い出しながら書く。だから短く、形だけになります。
読む側にとって、日報は「全員分を読まないといけない、量の多い文章」でした。上長は読み切れず、止まっている仕事や助けが要る話が、文章の中に埋もれます。
書いても反応がないと、書く側は「どうせ読まれない」と感じ、さらに形だけになります。

AIで、この前提が変わりました。

書く側：その日の作業の記録から、AIが日報の下書きを作ります。本人は直して出すだけです。
読む側：AIが全員分を読み、止まっている仕事・ヘルプが必要なこと・判断待ちだけを上長に渡します。上長は全部を読まなくてよくなります。
会社：日報と議事録から、決定台帳と案件の現在地が毎日更新されます。従業員は、動く前に「もう決まっていること」を引けます。

ただし、日報は評価につながる文章でもあります。よく見せたい、頑張りを伝えたい、という気持ちが入るのは自然なことです。S7の仕組みは、その気持ちを取り締まるのではなく、事実だけを抜き出して記録することで扱います（後の「ファクトベースの活動記録」）。

このスキルの核心：センターは「集める場所」ではなく「記録を作る場所」

前提：入力は3種類。うち2つは従業員から上がってくる

センターOntology は、従業員の情報を取りに行きません。入力は次の3種類で、最初の2つが従業員から上がってくるもの、3つ目がシステムから流れてくるものです。

入力	性質
日報（成果報告）	本人が自分の言葉で書く。何を書き、どう見せるかは本人が決める。よく見せたい気持ちが入ることが前提
会議の議事録	会議の記録。決定と宿題が残る。ただし、会議の外の活動は写らない
機械の記録	勤怠や、売上・受注などの確定した数字。本人の意図が入らない記録。システムがある会社では最初から存在する

だからセンターの仕事は「正確なデータを集めること」ではありません。書き手の気持ちが入った日報と、会議の記録、そして意図の入らない機械の記録。この入力から、会社として信頼できる記録を作ることが仕事です。機械の記録は、確定の層の土台になります（照合の相手として最も強い）。

組み立て方：新しい書類を持ち込まない

この仕組みは、従業員がすでに書いているものだけで組み立てます。日報、業務報告、会議の議事録。新しい様式や新しい概念を増やすと、現場では「見えないもの」になり、回らなくなります。

すでに日報や週報の形がある会社は、その形をそのまま使います。センター側の扱い（出どころ、2層、照合）は共通でも、報告の形は各社の実物に合わせます。

そして、日報が評価につながる以上、よく見せたくなるのは当然のことです。「書けば書くほど評価が上がる」ように見える仕組みの中で、頑張りを伝えようとするのは欠陥ではなく前提です。だから設計は、それをなくそうとするのではなく、気持ちの入った文章から、事実だけを抜き出して記録する形にします。

恣意的な報告を、構造で扱う

報告に気持ちが入ることを取り締まる設計にすると、従業員は報告を出さなくなります。そうではなく、次の構造で扱います。

① 全部に出どころをつける センターに載る情報はすべて、「誰の・いつの日報か」「どの会議の議事録か」を持つ。出どころのない情報は、会社の情報として扱わない。

② 「言ったこと」と「確定したこと」を分ける

言明の層：日報は、「本人がそう書いた」という形で原文のまま保存する。センターは勝手に書き換えない。
確定の層：議事録、他の人の日報、勤怠や売上などの確定した数字と合ったものだけが、「会社の事実」として上がる。

③ 照合する 日報と議事録、複数人の日報同士、今日の日報と前日の日報、日報と勤怠を突き合わせる。食い違いは、消さずに「食い違いがある」という状態で残す。

④ 上がってこないことも見えるようにする 日報の未提出、議事録の未着は、空白ではなく「まだ上がっていない」という状態で記録する（運営の中だけで扱う）。

⑤ 訂正は履歴つきで受け付ける 黙って書き換えない。「いつ・何が・どう直ったか」が残ることが、記録の信頼になる。

⑥ 見せるのは「人」ではなく「仕事」 活動の記録を集めることと、それを全員に見せることは別です。従業員同士が互いの活動量を見比べる形にすると、「あの人は働いていない」という量によるジャッジが始まり、報告そのものが萎縮します。

全員に見せるのは、決定と案件の状態（何が決まり、何が止まっているか）。主語は仕事であって、人ではない。
個人の活動記録は、本人・上長・管理職だけが参照する。
助け合いのきっかけは、個人の記録を覗くことではなく、案件の「止まっていること」と「ヘルプが必要なこと」が見えることから作る。

従業員
  日報（自分の言葉・自分の見せ方）
  会議の議事録
        ↓ 上げる
会社のシステム
  機械の記録（勤怠・確定した数字）
        ↓ 流れる
センターOntology
  出どころをつける → 日報は原文のまま保存（言明の層）
        ↓ 事実を抜き出す
  ファクトベースの活動記録（本人・上長・管理職が見る）
        ↓ 照合（日報×議事録／日報×日報／日報×前日／日報×勤怠）
  確定の層（会社の事実）
        ↓ 生成
  決定台帳・案件の現在地・朝会ブリーフ（全員が参照）
  上長の受け取り一覧・判断材料シート（上長・管理職が見る）

ファクトベースの活動記録：何を抜き、何を抜かないか

活動記録は、日報を要約したものではありません。日報から事実だけを抜き出したものです。上長や管理職が見て、「何が進み、何が終わり、どこに手が要るか」がすぐ分かる形にします。

抜き出す（記録する）	抜き出さない（記録しない）
やったこと：何の作業を、どの案件で	気持ち（「大変だった」「つらかった」）
終わったこと：何が完了したか。終わったと分かるもの（納品物・件数・送ったメール）つき	頑張りの強調（「誰よりも頑張った」「必死で」）
決まったこと：会議名と日付つき	自己評価（「うまくできた」「完璧」）
ヘルプが必要なこと：何に・誰の・いつまでに	体調・家庭の事情などの個人の事情
明日の予定と、前日の予定のその後	他の人への評価や不満

日報の原文は、言明の層（reports/）にそのまま残ります。活動記録から外すのは、原文を否定するためではなく、判断に使う記録を事実でそろえるためです。

1つ大事な点があります。「つらかった」は記録しませんが、その中に本当に助けが要る話が含まれていることがあります。「梱包の手が足りない」「この判断ができないと進めない」は、事実として「ヘルプが必要なこと」に入ります。だから日報の型に「ヘルプが必要なこと」の欄を置き、本人がそこに書けるようにします。体調や個人の事情は、記録ではなく上長との面談で扱います。

なぜ「報告」の形にするのか

共有の単位を生のデータではなく「報告」にすることには意味があります。報告とは、誰が・何を・誰に見せるかを、出す側が決めた形です。「会社に公開する」と言っても、会社は一枚岩の宛先ではありません。経営者に見せるもの、同僚に見せるもの、他チームに見せるものは違う。だから報告は、宛先ごとに内容と粒度を変えて作ります。

出す側が「自分の報告は、誰の目にどう映るか」を先に整理できていること。それが、この仕組みが回る条件です。

見え方は、立場ごとに設計する

同じ仕組みでも、立つ位置で見え方はまったく違います。この仕組みが回るかどうかは、両方の立場から「自分にとって得なもの」に見えているかで決まります。

立場	見え方	設計でそう見せるための要点
従業員	「業務で使える AI が会社に入っていて、日報も自動で作ってくれる。自分は確認するだけ。めちゃ楽」	日報の下書きは AI が自動生成し、本人は確認と修正だけにする。日報を「提出の義務」としてではなく、「自分の仕事を楽にする道具」として先に渡す
管理者	「従業員から報告がどんどん集まってくる。個人の情報と業務進捗は分けて保存され、業務進捗と論点は全社員がリアルタイムで参照できる。だから仕事が進む」	保存を2つに分ける。個人の情報は限定側に、業務進捗と論点（止まっていること・決める必要があること）は全員が参照できる側に置く。鮮度は運用サイクルで保つ（日報サイクルなら翌朝に反映された状態を「見られる」状態とする）

ポイントは、従業員側の「楽」が、管理者側の「集まる」の前提になっていることです。下書きを AI が作るから従業員は楽をする。楽だから毎日出る。毎日出るから管理者に集まる。どちらか片方だけの都合で設計すると、もう片方が止まります。

そして、分けて保存する線引きが信頼の条件です。業務進捗と論点は全員に見えるから仕事が進む。個人の情報は分けて守られるから、従業員は安心して日報を出せる。この両立が崩れると、仕組みは回りません。

この教材は、そのまま従業員の研修にもなります。従業員が仕組みの使い方を学ぶ過程で、「自分の日報はどう扱われるか」「活動記録には事実だけが残ること」「個人の情報は分けて保存されること」「活動の量で並べられることはないこと」を知る。ルールが従業員に知られていること自体が、この仕組みの一部です。 守られていることを知っているから、安心して日報を出せる。設計が知られることで機能する、という点が普通の管理の仕組みと違うところです。従業員に渡すときは、Part 3（従業員のアクション）と、上の「ファクトベースの活動記録」の表を中心に使ってください。

Part 1：導入の準備（経営者）

各Partには、AIエージェントに貼る依頼文（コピペ①〜⑭）を置いています。各コピペは、指示（何をしてほしいか）と詳細（どういう状態で作ってほしいか）の2つでできています。【　】の中を書き換えてから送り、出てきたものは必ず読んで、違うところを直させてから次へ進みます。従業員の情報を扱うので、本番のデータを入れる前に Part 6（労務と個人情報）を確認してください。最初は練習用データで試すのがおすすめです。

置き場を作る（最初の1回だけ）

センター側の置き場は、次の形を基本にします。ツールは問いません（フォルダ＋Markdown で足ります）。

center-ontology/
  ├── 運用ルール.md
  ├── members/        従業員と担当領域の一覧、期初の目標
  ├── reports/        日報（言明の層）※本人の原文のまま
  ├── minutes/        会議の議事録
  ├── decisions/      決定台帳（確定の層）
  ├── projects/       案件ごとの現在地
  ├── activities/     一人ひとりのファクトベースの活動記録（参照は本人・上長・管理職）
  └── views/          朝会ブリーフ、上長の受け取り一覧、判断材料シート

ポイントは reports/（言明）と decisions/（確定）を分けることです。この2つを混ぜた瞬間に、「誰が言ったことか」と「会社として決まったことか」の区別がつかなくなります。

運用ルールを置く

center-ontology/ の直下に、次のルールファイルをそのまま置いてください。AI にセンターの作業を頼むときは、毎回このルールを前提にさせます。運用する人が変わっても、AI が変わっても、扱いがぶれなくなります。

なお、このルールは従業員にも開示する前提で書きます。秘密の運用ルールにはしません。自分の日報がどう扱われるかを従業員が知っていることが、仕組みの条件だからです。

# センターOntology 運用ルール

## 扱いの原則
1. センターに載る情報には、必ず出どころ（誰の・いつの日報か、どの会議の議事録か）をつける。出どころのない情報は載せない。
2. 日報は「本人がそう書いた」という形のまま reports/ に保存する（言明の層）。書き換えない。
3. 活動記録（activities/）には、日報から事実だけを抜き出して書く。やったこと・終わったこと（証拠つき）・決まったこと・ヘルプが必要なこと・予定。気持ち・頑張りの強調・自己評価・健康や家庭などの個人の事情・他人への評価は書かない。
4. 議事録・他の人の日報・勤怠や売上などの確定した数字と合ったものだけを、確定の層（decisions/、projects/）に載せる。
5. 照合で食い違いがあれば、勝手にどちらかに決めず、両方を出どころつきで並べて「食い違いあり」の状態にする。
6. 訂正は履歴を残す。「いつ・何が・どう直ったか」を追記し、元の記述は消さない。
7. 全員向けの生成物で、個人の活動量を並べない。主語は案件と決定にする。
8. 未提出・未着の一覧は運営内のみで扱う。全員が見られる形では出さない。
9. 判断・評価・所感は書かない。センターの仕事は、記録と材料を揃えるところまで。
10. 個人の情報と業務進捗は分けて保存する。業務進捗と論点は projects/・decisions/ の全員が参照できる側に、個人の活動記録は本人・上長・管理職だけが参照する側に置く。

## フォルダ
- reports/：日報（言明の層・原文のまま）
- minutes/：会議の議事録
- decisions/：決定台帳（確定の層）
- projects/：案件ごとの現在地
- activities/：ファクトベースの活動記録（参照は本人・上長・管理職のみ）
- views/：朝会ブリーフ（全員）、上長の受け取り一覧・判断材料シート（上長・管理職のみ）

コピペ①：置き場と運用ルールを作る

指示：会社のセンターOntologyの置き場と、運用ルールを作ってください。

詳細：
- 作る場所：【会社のフォルダ】/center-ontology/
- 作るフォルダ：members/・reports/・minutes/・decisions/・projects/・activities/・views/
- reports/（日報の原文）と decisions/（確定した決定）は、必ず別のフォルダにする
- 直下に「運用ルール.md」を置き、S7本文の「センターOntology 運用ルール」をそのまま書く
- 作ったら、フォルダの一覧と運用ルールの全文を見せる

ファイルの命名規則を決める

探せることが、この仕組みの生命線です。命名は次の形に統一します。

ファイル	命名
日報	`YYYY-MM-DD_{名前}_日報.md`
議事録	`YYYY-MM-DD_{会議名}_議事録.md`
案件の現在地	`{案件名}_現在地.md`（1案件1ファイル、更新していく）
活動記録	`{名前}_活動記録.md`（1人1ファイル、追記していく）
決定台帳	`決定台帳.md`（1ファイルに追記していく）
期初の目標	`{名前}_目標_{期間}.md`
朝会ブリーフ	`YYYY-MM-DD_朝会ブリーフ.md`
判断材料シート	`YYYY-MM-DD_{名前}_判断材料.md`（期末の日付）

初期ファイルを用意する

次の3つを、空の型として最初に置きます（下のコピペ②）。

決定台帳（decisions/決定台帳.md）：

# 決定台帳

| 日付 | 決定事項 | 出どころ（会議・日付） | 関係する案件 |
|---|---|---|---|

案件の現在地（projects/{案件名}_現在地.md）：

# {案件名}：現在地（最終更新：YYYY-MM-DD）

## 決まったこと
## 動いていること
## 止まっていること（理由・誰の判断待ちか）
## 次の会議
## 関係メンバー

活動記録（activities/{名前}_活動記録.md）：

# {名前}：活動記録

| 日付 | やったこと | 終わったこと（証拠） | ヘルプが必要なこと | 出どころ |
|---|---|---|---|---|

コピペ②：初期ファイルを置く

指示：center-ontology/ に、決定台帳・案件の現在地・活動記録の初期ファイルを置いてください。

詳細：
- decisions/決定台帳.md：表の枠だけ（日付／決定事項／出どころ（会議・日付）／関係する案件）
- projects/【案件名】_現在地.md：見出しだけ（決まったこと／動いていること／止まっていること／次の会議／関係メンバー）
- activities/【名前】_活動記録.md：従業員1人につき1ファイル、表の枠だけ（日付／やったこと／終わったこと／ヘルプが必要なこと／出どころ）
- ファイル名は S7本文の「命名規則」に合わせる
- 中身はまだ入れない

期初に、目標を置く

期の初めに、一人ひとりの目標を1枚にまとめ、members/{名前}_目標_{期間}.md として置きます。目標は「決まったこと」ではなく期初の約束として扱い、期末の判断材料シート（Part 5）で、活動記録・確定した成果と並べて照合する軸になります。

# 目標：{名前}／{期間}

## 担当案件
## この期に達成すること（数値があるものは数値で）
## 会社と合意した優先順位

Part 2：1日の流れ（日報サイクル）

従業員がいる会社では、日報で回す日次サイクルを基本にします。

日報には、週報にない効果が2つあります。

書く本人の Ontology が強化される：その日の仕事を確定情報として書き出す行為が、本人の情報の整理そのものになる。日報は提出物であると同時に、本人のための記録である。
会社全体のタスク管理の精度が上がる：センターの情報の鮮度が週次ではなく日次になり、止まっている仕事を翌朝には拾える。

1日の流れ

時刻	動き
終業前（例：17:00）	AI がその日の作業記録から日報の下書きを作り、従業員は確認・修正して提出する（Part 3 のコピペ⑥）。提出して終業とする
夜の間	AI が処理する：取り込みと事実の抜き出し（コピペ③）、照合（コピペ④）、決定台帳・案件の現在地・活動記録の更新
翌朝の朝会まで	センターOntology が前日分まで反映された状態になっている。朝会ブリーフと上長の受け取り一覧ができている（コピペ⑤）
朝会	ブリーフを見て「決めること」だけを決める。報告の読み上げはしない

日報を書く時間は、仕事の時間の中に入れます。終業後に書かせる形にはしません（Part 6）。

夜の処理1：取り込みと、事実の抜き出し

提出された日報と議事録を、センターに取り込みます。日報は原文のまま保存し、そこから事実だけを抜き出して活動記録にします（抜き出す・抜き出さないの線引きは、核心の章の表のとおりです）。

コピペ③：日報と議事録を取り込み、事実を抜き出す

指示：今日提出された日報と議事録を、センターOntologyに取り込んでください。

詳細：
- 日報は reports/ に、本人の原文のまま保存する（書き換えない）
- 議事録の決定事項を、decisions/決定台帳.md に出どころ（会議名・日付）つきで追記する
- 日報から事実だけを抜き出し、activities/【名前】_活動記録.md に追記する
  - 抜き出す：やったこと／終わったこと（証拠つき）／決まったこと／ヘルプが必要なこと
  - 抜き出さない：気持ち・頑張りの強調・自己評価・体調などの健康情報・他人への評価
- 案件の現在地（projects/）は、日報にもとづく内容を「〜と報告されている」と分かる形で仮置きする
- 最後に、取り込んだ件数と、判断が必要な事項を一覧で出す

夜の処理2：照合

取り込んだ日報を、議事録・他の人の日報・前日の日報・勤怠の記録と突き合わせます。食い違いは、どちらが正しいかを決めずに並べます。

コピペ④：照合する

指示：今日分のセンターOntologyについて、照合を行ってください。

詳細：
- 日報 × 議事録：会議の決定と日報の内容が合っているか
- 日報 × 日報：同じ案件に関わる複数人の日報で、食い違いがないか
- 日報 × 前日の日報：前日の「明日の予定」の、その後が書かれているか
- 日報 × 勤怠の記録（【勤怠CSVの場所】）：日報の時間の記述と勤怠が合っているか
- 合っていたもの：確定の層（決定台帳・案件の現在地）へ上げる候補として一覧にする
- 食い違い：どちらの記述かを出どころつきで並べる。どちらが正しいかは決めない
- 消えた予定：前日あったのに今日ないものを一覧にする
- 未提出：出勤しているのに日報がない人の一覧は、運営用に別に出す

朝会ブリーフの形

# 朝会ブリーフ：YYYY-MM-DD

## 昨日決まったこと
- （決定事項／出どころ）

## 止まっている仕事
- （案件／何が止まっているか／理由／誰待ちか）

## 今日の朝会で決めること
- （論点／判断する人）

主語は案件と決定です。誰の日報が長かったか、誰が未提出かは、このブリーフには載せません。

コピペ⑤：朝会ブリーフと、上長の受け取り一覧を作る

指示：センターOntologyの前日分から、朝会ブリーフと、上長【上長の名前】さん向けの受け取り一覧を作ってください。

詳細：
- 朝会ブリーフ（全員が見る）：昨日決まったこと／止まっている仕事と理由・誰待ちか／今日の朝会で決めること
- 上長の受け取り一覧（上長だけが見る）：止まっている仕事／上長の判断待ち／ヘルプが必要なこと／照合の食い違い
- 正常に進んでいる仕事は載せない（例外だけ）
- 主語は仕事にする。個人の活動量（日報の長さ・件数）は並べない
- 日報の未提出は、朝会ブリーフに入れない
- 評価や所感は書かない

Part 3：従業員のアクション

従業員がやることは、大きく6つです。どれも「自分の確定した事実から作る」ことが共通しています。この Part は、そのまま従業員研修の教材として渡せます。

STEP M1：報告の宛先と見せ方を決める（最初に1回）

最初に、自分の報告を「誰に・何を・どの粒度で」出すかを決めます。次のシートを自分の言葉で埋めてください。これがあなたの報告の定義書になります。

## 私の報告の定義

### 宛先：上長
- 出すもの：担当案件の進み具合、終わったこと、止まっていること、ヘルプが必要なこと、判断してほしいこと
- 粒度：要点のみ（詳細は求められれば出す）
- 出さないもの：作業の途中経過の細部

### 宛先：同じ案件のメンバー
- 出すもの：決定事項、宿題の状態、次の動き、共有すべき資料
- 粒度：実務レベルまで
- 出さないもの：他案件の秘情報

### 宛先：他チーム
- 出すもの：会社の決定に関わること、他チームに影響する変更
- 粒度：要点のみ
- 出さないもの：案件の詳細、金額

STEP M2：日報を作る（毎日）

日報は一から書くものではありません。自分の作業記録から AI に下書きを作らせ、直して出します（下のコピペ⑥）。

すでに日報の形がある会社は、新しく作らず、それをそのまま使ってください。型がない場合は、次の形を使います。

# 日報：{名前}／{日付}

## やったこと
- （案件ごとに、何の作業をしたか）

## 終わったこと
- （完了したもの。終わったと分かるもの：納品物・件数・送ったメールなどを添える）

## 決まったこと
- （会議や上長の判断で確定した事項。会議名と日付を添える）

## ヘルプが必要なこと
- （何に・誰の・いつまでに。なければ「なし」）

## 明日の予定
- （昨日の「明日の予定」に書いたことの、その後も含める）

記入例（架空の例です。粒度の目安にしてください）：

# 日報：山田／2026-10-22

## やったこと
- 新商品：パッケージデザインの最終候補を2案に絞った
- A社：契約書の内容を確認し、返送した

## 終わったこと
- A社との契約が完了（契約書受領・2026-10-22）
- A社からの初回発注 480,000円 が確定（発注書受領）

## 決まったこと
- 新商品の価格を 4,800円 に確定（商品会議・2026-10-22）

## ヘルプが必要なこと
- 製造委託先の見積もりが届かない。10/25までに返答がなければ代替先を探したいので、上長の判断がほしい

## 明日の予定
- デザイン最終案を商品会議（10/29）に出す準備
- 昨日の予定「見積依頼」は送付済み。上の通り返答待ち

コピペ⑥：日報の下書きを作る

指示：今日の日報の下書きを作ってください。

詳細：
- 読むもの：私の今日の作業記録（【作業記録の場所：例）actionlog/・カレンダー・チャット】）と、昨日の日報
- 型：やったこと／終わったこと／決まったこと／ヘルプが必要なこと／明日の予定
- 使うのは確定した事実だけ。推測・未確認の話は入れない
- 「終わったこと」には、終わったと分かるもの（納品物・送ったメール・完了した件数など）を添える
- 昨日の「明日の予定」に書いた項目は、その後どうなったかを必ず入れる
- 下書きを見せたら、私が直してから提出する

下書きが出たら、本人の仕事は2つだけです。①事実の誤りを直す ②見せ方を調整する（宛先に合わせて削る・足す）。それで提出します。

気持ちや頑張りを書くのは自由です。原文はそのまま残ります。ただし、活動記録に残るのは事実だけです。伝えたいことがあるなら、「ヘルプが必要なこと」に事実として書くのが、いちばん確実に上長へ届く書き方です。

STEP M3：会議のあと、議事録を上げる

会議の記録（自動メモや文字起こし）は、そのまま上げず、決定と宿題が抜ける形に整えてから上げます。

コピペ⑦：会議メモを議事録に整える

指示：この会議メモを、議事録の形に整えてください。

詳細：
- 会議メモ：【ファイル】
- 抜き出すもの：
  1. 決定事項（何が決まったか）
  2. 宿題（誰が・何を・いつまでに）
  3. 状態が変わったこと（案件や数値の変化）
  4. 決まらなかったこと（未決のまま残った論点）
- 「アイデアとして出た話」を決定事項に混ぜない
- 発言者の訂正がある場合は、訂正後の内容を採用する
- 日時、会議名、参加者を冒頭に書く

STEP M4：動く前に、センターを参照する

自分の案件を動かす前に、センターの決定台帳と案件の現在地を引きます。「もう決まっていること」と「他の案件の動き」とぶつからないかを確認するためです。

コピペ⑧：動く前に、センターを参照する

指示：私がこれからやろうとしていることが、会社の決定や他の案件とぶつからないかを確認してください。

詳細：
- 読むもの：センターOntology（【センターのフォルダ】）の決定台帳と、案件「【案件名】」の現在地
- 私が次にやろうとしていること：【やろうとしていること】
- 教えてほしいこと：
  1. すでに関連する決定が出ていないか
  2. 他の案件の動きとぶつかる点がないか
  3. 先に確認すべき人がいるか

STEP M5：記録を直したいとき（訂正）

自分の日報や活動記録に誤りがあれば、黙って直さず、訂正として出します。

## 訂正：{対象の日報・記録}

- 対象：{いつの・どの日報か}
- 誤り：{元の記述}
- 正しい内容：{訂正後の記述}
- 理由：{なぜ誤ったか}

STEP M6：面談の記録を残す

個人面談の内容は、そのままでは記録に残りません。面談のあと、決まったことと宿題だけを、本人の確認を経て、参照を限定する側（activities/）に残します。感想や評価、体調や個人の事情に関わる部分は残しません。

コピペ⑨：面談の記録を残す

指示：この面談メモから、決まったことと宿題だけを抜いて記録にしてください。

詳細：
- 面談メモ：【ファイル】
- 抜き出すもの：
  1. 決まったこと
  2. 宿題（誰が・何を・いつまでに）
- 本人の発言は「本人の言明」として、そのままの形で残す
- 評価・所感、体調や個人の事情にあたる部分は含めない
- 記録は、面談した本人と上長だけが参照する側に置く
- 記録にする前に、本人に内容を確認してもらう

Part 4：上長のアクション

上長の業務管理も、同じ仕組みの上に載せます。考え方は1つで、**上長の仕事は「部下を見ること」ではなく、「仕事の停滞と判断待ちを処理すること」**です。

部下の日報を全部読む形にすると、上長の負担が増え、部下には監視として見えます。そうではなく、センター側の処理を通して、上長には次の4つだけが上がってくる形にします。

止まっている仕事（理由つき）
自分の判断待ち（部下の日報の「ヘルプが必要なこと」のうち、自分宛てのもの）
ヘルプが必要なこと（判断ではなく、人手・資材・調整が要るもの）
照合の食い違い（部下の日報と会議・勤怠・数字が合っていないもの）

正常に流れている仕事は、上長が見る必要はありません。例外だけが上がる。この形なら、上長にとっても「楽」が成立します（チームの日報を全部読まなくていい。決めるべきものだけが届く）。

部下の活動記録を見たいときは、事実だけの記録（ファクトベースの活動記録）を見ます。日報の原文を読み込んで「頑張っているか」を測ることはしません。

なお、上長自身も1人の従業員です。自分の日報は自分の上長に出し、自分の判断待ちの滞留は上の層から見えます。管理の構造は、階層の段数だけ同じ形で繰り返されます。

STEP U1：朝、チームの状態と判断待ちを受け取る

朝会ブリーフと一緒に、上長向けの受け取り一覧を受け取ります（Part 2 のコピペ⑤）。

STEP U2：判断したら、記録して部下に返す

上長の判断は、口頭で終わらせず、決定として記録し、関係者に返します（下のコピペ⑩）。この往復が記録されることが、部下側の「ヘルプを書けば応えてもらえる」という信頼になります。

コピペ⑩：判断を記録して返す

指示：私の判断を、センターOntologyに記録してください。

詳細：
- 判断：【判断の内容】
- 対象：【案件名・誰のヘルプ／相談への回答か】
- 決定台帳に、出どころ（【上長の名前】の判断・日付）つきで追記する
- 案件の現在地の「止まっていること」から、該当項目を解消済みに更新する
- 判断待ちの一覧から、該当項目を消す
- 関係する人への連絡文の下書きを作る（送るのは私）

STEP U3：週に1回、チームの宿題と食い違いを棚卸しする

コピペ⑪：チームの宿題と食い違いを棚卸しする

指示：私のチームの、宿題・食い違い・判断待ちの滞留を棚卸ししてください。

詳細：
- チーム：【チーム名】
- 出すこと：
  1. 宿題の一覧：会議と面談で生まれた宿題のうち、未完了のもの（仕事ごとに、担当・期限・現在の状態）
  2. 照合の食い違い：まだ解消していないもの
  3. 判断待ち・ヘルプの滞留：私宛てのもので、【N】日以上止まっているもの
- 「誰が遅れているか」ではなく「どの仕事が止まっているか」で出す
- 食い違いは、どちらが正しいか決めず、両方の記述を並べる（解消は私が当事者に確認して行う）

STEP U4：期の終わり、部下の判断材料を確認する

会社側が作った判断材料シート（Part 5 のコピペ⑭）について、上長は「記録に漏れがないか」の確認を行います。評価そのものは、会社の評価の場で行います。

コピペ⑫：判断材料シートの漏れを確認する

指示：【名前】さんの判断材料シートに、記録の漏れや食い違いがないかを確認してください。

詳細：
- 読むもの：判断材料シート（【ファイル】）と、私のチームの決定台帳・議事録・活動記録
- 出すこと：
  - シートに載っていない決定・成果で、記録にあるもの
  - シートの記述と記録が食い違うところ
- 漏れと食い違いだけを出す。評価は書かない

Part 5：会社側の処理

会社側（センターの運営）がやることは、取り込み・照合・生成・棚卸し・判断材料の5つです。毎日の分は夜の間に AI が回し、判断そのものは人間が行います。

処理	頻度	使うコピペ
取り込みと事実の抜き出し	毎日（夜）	③（Part 2）
照合	毎日（夜）	④（Part 2）
朝会ブリーフ・上長の受け取り一覧	毎朝	⑤（Part 2）
未提出・未着の棚卸し	週1回	⑬
判断材料シート	期末	⑭

未提出・未着を棚卸しする（週次）

コピペ⑬：未提出・未着を棚卸しする

指示：今週、センターOntologyに上がってくるはずだったもので、まだ上がっていないものを点検してください。

詳細：
- 日報：出勤した日（勤怠の記録）のうち、日報がない日
- 議事録：開催された会議のうち、議事録が未着のもの
- 照合で「消えた予定」になったものの、その後
- 「まだ上がっていないもの」の一覧として出す。理由の推測は書かない（事実だけ）
- この一覧は運営の中だけで扱い、全員が見られる形では出さない

未提出を並べて見せることは、晒すことと同じになります。催促は個別に行います。

判断材料シート（期末）

期の終わりに、一人ひとりの判断材料を並べて出します（下のコピペ⑭）。ここまでが仕組みの仕事で、判断は人間が行います。

コピペ⑭：判断材料シートを作る

指示：【名前】さんの、【開始日】〜【終了日】の判断材料シートを作ってください。

詳細：
- 並べるもの：
  1. 期初の目標（members/【名前】_目標_【期間】.md）
  2. 会議で決まったこと（決定台帳・議事録から）
  3. 本人の日報に書かれたこと（活動記録から）
  4. 照合を経て確定した成果（確定の層から）
- 確定した成果が、目標のどれに対応するかを添える
- 活動の量（日報の回数・長さ、会議の回数）は材料に入れない
- 評価や所感は書かない。出どころのない項目は入れない

このシートは、そのまま評価の目線合わせの場（複数の上長で確認する場）の材料になります。シートの形が揃っていること自体が、目線合わせの前提です。

Part 6：導入前に確認すること（労務と個人情報）

従業員の日報や勤怠を AI で扱う仕組みは、労務と個人情報のルールに関わります。導入する前に、社会保険労務士などの専門家と、次の点を確認してください。 ここに挙げるのは確認すべき論点で、結論ではありません。

確認すること	関係する考え方	確認先の例
日報を書く時間の扱い	「提出して終業」とするなら、日報を書く時間を勤務時間の中に入れる必要があるか	厚生労働省「労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン」
日報の提出を義務にするか	就業規則で定める必要があるか、従業員への説明をどうするか	労働基準法（就業規則）、厚生労働省のモデル就業規則
従業員の情報を集めて使う目的	何のために集め、誰が見るか。事前に決めて、従業員に知らせているか	個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」と Q&A（従業者のモニタリング）
AI サービスに従業員の情報を入れてよいか	外部のサービスに渡すことになるか、契約上の扱いはどうか	個人情報保護委員会の生成AIサービスの利用に関する注意喚起、利用するサービスの規約
健康などの情報を記録しないこと	体調・家庭の事情を活動記録に残さない運用を、ルールとして明記しているか	本ページの運用ルール3

S7 の運用ルールを従業員に開示する（Part 1）のは、この確認の一部でもあります。何のために集め、誰が見て、何を記録しないかを、導入前に従業員へ説明してください。

運用カレンダー：いつ・誰が・何を回すか

タイミング	従業員	上長	会社側
導入時（1回）	M1：報告の定義を書く	―	Part 1：置き場・運用ルール・命名・初期ファイル、Part 6 の確認と従業員への説明
期初	―	目標の合意	期初の目標を置く
毎日・終業前	M2：日報を作って出す（⑥）	自分の日報を出す	―
毎日・夜	―	―	③取り込み／④照合
毎朝	朝会ブリーフを見る	U1：受け取り一覧を見る	⑤朝会ブリーフ・受け取り一覧
会議のあと	M3：議事録を整えて上げる	―	―
判断したとき	―	U2：判断を記録して返す	―
案件を動かす前	M4：センターを参照する	―	―
週に1回	―	U3：宿題と食い違いの棚卸し（⑪）	⑬未提出・未着の棚卸し
期の終わり	（訂正があれば M5）	U4：判断材料の漏れを確認（⑫）	⑭判断材料シート

導入の順番は、Part 6 の確認 → Part 1 の準備 → M1 → 日報（⑥）と夜の処理（③④）→ 朝会ブリーフ（⑤）→ 上長の往復（U1・U2、⑩）→ 判断材料シート（⑭）、です。最初から全部を回そうとせず、最初の1か月は「日報が上がり、決定台帳と案件の現在地が毎朝更新される」ところまでを目標にしてください。

達成の目安

従業員

「私の報告の定義」シートを、宛先ごとに書いた
日報を、AI の下書き＋自分の修正で提出した
助けが要るときに、「ヘルプが必要なこと」に事実として書いた
会議のあと、決定と宿題を抜いた議事録を上げた
案件を動かす前に、決定台帳を引いて確認した
記録の誤りに気づいたら、訂正として出した

上長

毎朝、止まっている仕事・自分の判断待ち・ヘルプを受け取っている
判断したら、決定として記録し、部下に返している
週次で、宿題・食い違い・判断待ちの滞留を棚卸しした
部下の状況を、日報の原文ではなく活動記録（事実）で確認している

会社側

導入前に、Part 6 の点を専門家と確認し、従業員に説明した
センターの置き場（言明の層と確定の層を分けた形）と運用ルールを置いた
期初の目標を置いた
日報の取り込み・事実の抜き出し・照合が、毎日回っている
決定台帳・案件の現在地・朝会ブリーフを、従業員が参照できる形で出した
期ごとの判断材料シートを作成した（評価は人間が行った）

S7 レッスンプラン例

S7を勉強会や授業で扱う場合は、2時間×3回にすると進めやすいです。各回の最後に、ミニワークを行います。 ミニワークでは、下の練習用データを使います。自社にまだ従業員がいなくても、日報が上がってくる会社の動きを、手元で一通り試せます。

第1回（2h）センターを置く

扱う範囲：なぜ必要なのか、このスキルの核心（ファクトベースの活動記録まで）、見え方、Part 1
到達目標：言ったことと確定したことを分ける理由、出どころの意味、活動記録に事実だけを残す理由、個人の情報と業務進捗を分けて置く理由を説明できる
ミニワーク：練習用データの日報と議事録を取り込み、決定台帳と活動記録を作る（コピペ①②③）

第2回（2h）1日を回す

扱う範囲：Part 2〜4
到達目標：日報サイクルの1日の流れ、上長に例外だけが上がる形、判断を記録して返す往復が分かる
ミニワーク：照合を回して食い違いを見つけ、朝会ブリーフと上長の受け取り一覧を作る（コピペ④⑤⑩）

第3回（2h）記録を判断の材料にする

扱う範囲：Part 5・6、運用カレンダー、応用
到達目標：未提出の扱い（運営の中だけ）、判断材料シートの並べ方、AI を評価者にしない理由、導入前に確認する労務と個人情報の論点が分かる
ミニワーク：1人分の判断材料シートを作る（コピペ⑭）。続けて、自社に入れる場合の「導入の順番」と「従業員への説明文」を書く

各回の後半は、出てきた記録や一覧を見せ合う時間に使います。同じデータでも、AI への頼み方で抜き出され方が変わるので、比べると学びが大きくなります。

練習用データ：ひなた工房の1年後

S6の見本に出てきた架空のひとり会社「ひなた工房」が、1年後に雑貨店の事業を伸ばし、従業員を雇った、という設定のデータです。人物・会社・数字は、すべて架空です。

まとめて受け取る：s7-practice.zip

中身	内容
`company.md`	会社と案件の設定（雑貨店の店長1人と従業員5人）
`members/`	従業員の一覧と、2人分の期初の目標
`reports/`	2日分の日報
`minutes/`	商品会議と朝会の議事録
`kintai.csv`	2日分の勤怠の記録

データには、照合で見つけてほしい点がいくつか入っています（食い違い、消えた予定、未提出、事実と気持ちが混ざった日報など）。答えは配りません。AI に照合させ、見つかったものを見せ合ってください。

応用1：パートナー型の組織では、週報で回す

従業員が同じ就業時間で動く会社では日報、パートナーや業務委託が各自の時間で動く組織では週報、と組織の形に合わせて選びます。どちらが正しいという話ではありません。仕組みの本体（出どころ・2層・照合・事実の抜き出し）は共通です。

週報で回す場合は、日報サイクルの「毎日・夜」の処理を週1回にし、朝会ブリーフの代わりに「今週の会社」ダイジェスト（今週の決定、新しい動き、止まっているもの）を出します。

参考：週報の3つの形

週報の形は、会社ごとに違います。次の3社は、実際に回っている週報をもとに、社名と中身を架空に置き換えた例です。

会社（架空）	週報の形	特徴
あおば商事（架空）	週次進捗報告。要約のあと、事業ごとに進捗・確定した数値（原価、目標額など）・リンク・相談事項	事業が複数あるため事業別の構成。相談事項は事業ごとに置く
こもれび住宅（架空）	週次報告。主な成果・進捗（案件ごと）／お金の動き／次回までの予定／定例会議で確認したいこと	最も簡潔な形。定例会議の前に届き、会議は「確認したいこと」を決める場になる
たねや製菓（架空）	週次財務。今月売上（累計）／現金残高／大きなお金の動き（実績・予定）／今週の意思決定／トピック・相談事項	財務を中心にした形。未確定の数値には「要確認」の印をつけて出す

3社に共通する骨格は、進捗・成果（案件ごと）／お金の動き／決まったこと／相談事項／次回までの予定です。日報の型（STEP M2）も、この骨格を1日分に縮めたものです。

もう1点、実物から学べる扱いがあります。センター側では、届いた週報をメール本文の転記として保存し、冒頭に「出どころ（送信元・受信日時・対象期間）」を付けて管理しています。これが、原則①「全部に出どころをつける」の実地の形です。

応用2：規模が大きくなったら

従業員が数十人を超えると、照合と棚卸しを1か所で回すのは重くなります。そのときは、部門ごとにセンターを置き、会社全体のセンターは部門センターの確定情報（決定と案件の状態）だけを集める2段構えにします。

センターの運営は、人事評価を担う部署ではなく、事業の運営を担う側が持つほうが、日報の萎縮を避けられます。人事は、判断材料シートを使う側の一つに置きます。

S6との分担と、このスキルが扱わないこと

S7 のセンターOntology は、以前「共有Ontology」と呼んでいた考え方の発展形です。全員が同じ実体を直接触るのではなく、日報と議事録、機械の記録を集めて、センターが会社の記録を作る形に置き直しました。

S6 との分担は次の通りです。

	S6	S7
対象	4〜5人の小規模プロジェクト。自分・AI・業務委託・アルバイト	従業員がいる会社の全体
中心	経営者本人のダッシュボード（自分専用の操縦席）	センターOntology と、全員が参照する情報
扱うこと	指示出し、成果判定、業績評価の型	日報と議事録からの記録の作り方、照合、全員が参照する情報、上長への上がり方、判断の材料
扱わないこと	会社全体の労務管理、人事部が運用する規模の仕組み	左に同じ。加えて、評価の型そのもの

S7 は労務管理そのもの（勤怠システムの運用、就業規則の作成、社会保険の手続き）は扱いません。勤怠の記録は、照合の材料として参照するだけです。また、成果判定と業績評価の「型」は S6 の担当で、S7 はその判断に使える記録と材料を作るところまでです。

3つの主権との関係

この設計は、SOVREN の根にある「個人の3つの主権」を、会社の仕組みの中で守るためのものです。

自己主権：日報の原文は本人の言葉のまま残り、訂正する権利は本人にある。センターは出どころを明らかにし、事実だけを記録する。
声の主権：何を、誰に、どう見せるかは、本人が決める。センターは原文を書き換えない。
資本主権：活動と成果は、照合を経た事実の記録として残る。評価は印象や頑張りのアピールではなく記録に基づく。自分の働きの証跡が、自分の資産として残る。

管理の仕組みは、普通、会社の都合で個人の情報を吸い上げる形に作られます。この設計が目指すのは逆で、個人の主権が守られたまま、会社の情報が循環する形です。それが AI 時代のカンパニーの姿だと考えます。