S6：スタッフ管理をAIで行う

人に仕事を渡すとは、その人に情報を渡すことだ。

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

自分・AI・業務委託（パートナー）で組む、4〜5人の小規模プロジェクトを、Ontologyの上で運営できる体制です。その中心にあるのが、会社の状態を一目で見て、その場で次の手を打てる、自分専用のダッシュボードです。あわせて、AI上のデータベースの設計を、人事（人に関する情報）を例にとって学ぶことができます。

1. 会社の操縦席になるダッシュボード（外出先でもスマホから見られる、自分専用の画面。S6の背骨で、以下の2〜6は、どれもこの画面の欄として育てる）
2. データの置き場所と守り方（人に関する情報を、混ぜずに、見られる範囲を決めて置く）
3. チームの構造（誰がどの責任を持つか、何を誰が決めるか）
4. 指示出し（AIと人へ、迷わず動ける指示を出す型）
5. 成果判定（渡した仕事を、合格条件で検収する型）
6. 業績評価（次も頼むか、どう改善するかを、証拠で判断する型）

このスキルが扱わないこと

S6の対象は、小規模プロジェクトの運営です。次のものは対象に入れません。

• 会社全体の労務管理（就業規則の整備、勤怠システム、社会保険の手続きなど）
• 人事部が運用する規模のデータベースと、大規模なセキュリティ基盤
• 大人数の評価制度（等級・多面評価・キャリブレーションなど）

これらを始めると、事業がシステム開発会社（SIer）に寄っていきます。私たちが磨くのは、小さなプロジェクトを、少ない管理コストで回す型です。その型を複数組み合わせれば、大きな組織も作れます（組み合わせ方はS7）。

---

時代背景：働き方がプロジェクト型へ移行している

現代では、あらゆる仕事領域で、「他者」とどうかかわるかというスキルが必須になりつつあります。

なぜか：AIによって、業務が個人化しているから

AIを使うと、1人で扱える業務の範囲が大きく広がります。資料作成も分析もリサーチも、以前は担当を分けていた仕事を1人が持てるようになりました。業務が個人に寄ると、組織の設計も変わります。

大企業でも中小企業でも、組織論の流れはパートナー制です。メンバーそれぞれが、どのプロジェクトに対して責任を取るのかを明確にし、目的ごとに必要な専門家が集まって終わったら解散する、プロジェクト型の働き方が広がっています。1人ひとりが自分の持ち場に責任を持つので、誰と組むのか、誰に何を渡すのかを選ぶ力が、そのまま成果を左右します。

雇用は、以前よりずっと重くなっている

もう1つの背景は、従業員を雇うことの重さです。雇用すると、労務管理や業務評価など、管理する項目が増え続けます。雇うたびに、意思決定の中心から離れて管理の仕事が増えていきます。

2026年度の目安として、従業員1人あたり、最低でも粗利800万円〜1,000万円程度で計算しないと、最低限の時給ですらバランスが取れなくなっています。この水準に届かない事業で人を増やすと、人件費と管理の手間が、稼ぎを上回ります。

だからS6で身につけること

自分の専門性を活かすプロジェクトを自ら企画し、AIと業務委託・パートナーを使って、最少人数で回るシステムを作ること。 プロジェクト型では人の出入りが多くなります。そのぶん、出入りのたびに情報が漏れない設計と、誰に何を渡すかの明確な線引きが要ります。これがS6の順序（まずデータ、次に構造、指示、成果判定、評価）の理由です。そして、その全部を1枚の画面で見られるようにすることが、少ない管理コストで回す鍵になります。

---

Part 1：データベースを設計する

各ステップには、AIエージェントに貼る依頼文（コピペ①〜⑧）を置いています。①から順に、1つずつ貼ります。各コピペは、指示（何をしてほしいか）と詳細（どういう状態で作ってほしいか）の2つでできています。【　】の中を書き換えてから送り、出てきたものは必ず読んで、違うところを直させてから次へ進みます。人に関する情報を扱うので、機微度（公開／社内／限定／預けない）を決めてからデータを入れます。

データベースとは何か

データベースとは、判断の根拠にする情報を、探せる・更新できる・誰が見られるか決められる形で置いた場所です。

高価なシステムは必要ありません。このフレームワークでは、myproject の中のMarkdownファイル群がそのままデータベースです。

一般的なデータベース	myproject での姿
1件のレコード	1つのMDファイル（1人＝1ファイル、1案件＝1ファイル）
項目（列）	ファイル冒頭の項目欄（frontmatter）と見出し
テーブル	フォルダ（people/・customers/ など）
他テーブルとの紐づけ	ファイルのIDやパスを本文に書く
アクセス権限	フォルダ単位の共有設定
変更履歴	クラウドの版履歴、またはGit

MDで持つ利点は、AIがそのまま読めることです。同時に、AIに読ませられる情報は、AIツールと、ファイルを共有した人にも届くという性質があります。便利になるほど、置く場所と守り方を先に決めておく必要があります。

分散したデータと、整理したデータ

「これまで作ってきたOntologyは、もうデータベースではないのか」という疑問は、ほぼ必ず出ます。答えは「半分そう」です。区別しておくと、この先が分かりやすくなります。

	分散したデータ	整理したデータ
姿	議事録・メモ・メール・報告が、フォルダの中に散らばっている	1件＝1ファイルで、同じ項目欄を持ち、IDで紐づいている
得意なこと	情報量が多い。想定外の問いにも、AIが探して答えられる	一覧・集計・比較ができる。画面に並べられる
出口	AIへの質問	ダッシュボード（ダッシュボードの章）

分散したデータは、劣ったものではありません。 整理したデータは、分散したデータの「出口」の1つです。Ontologyに会社の情報が大量に入っていることが、まず財産です。逆に、整理した形だけを残そうとして、報告をダッシュボードの項目に合わせて書かせると、項目に入らない情報が消えて、データとしては弱くなります（Part 4）。

セキュリティはどう担保するか

技術の話の前に、次の考え方を置きます。守るのは、データではなく、そのデータの持ち主です。 顧客や仲間は、自分の情報がここにあることを知っています。信頼を失うのは、漏れたときだけでなく、聞いていない使い方をされたときです。

小規模プロジェクトでは、専門の基盤を作りません。次の5つの層を、手元のルールとして決めます。

① 置かないものを決める

いちばん安全なのは、そもそも置かないことです。次のものはMDファイルに置きません。

• パスワード、APIキー、トークン、秘密鍵（AI利用ガバナンスキットの入力禁止情報と同じ扱い）
• マイナンバー、給与の振込口座、健康情報。給与計算・労務の専用サービスに置き、MDには「専用サービスにある」とだけ書く

② 機微度を4段階に分ける

機微度	中身の例	置き場・共有
公開	公開済みの記事、価格表	誰でも可
社内	手順書、議事録、外注先の一覧	自分とAI。パートナーは必要な範囲で
限定	顧客の相談内容、契約条件、評価の記録	自分とAI。他者には共有しない。AIに渡すときは匿名化を検討する
預けない	マイナンバー、口座、健康情報、認証情報	MDに置かない。専用サービスへ

③ 見られる人を最小にする

フォルダ単位で「読める人」「書ける人」を分けます。初期値は「自分以外は見られない」にして、業務に必要な範囲だけを開けます。書き込み権限は特に絞ります。誤って書き換えられると、AIが間違った情報を根拠にし続けるからです。

顧客・他社・業務委託の相手には、Ontologyを直接触らせません。 Ontologyは会社の情報の集まりなので、直接入れると、必要のない情報まで見られ、持ち出せる状態になります。相手に渡すのは、必要な情報だけをまとめた画面（ダッシュボードの章、Part 10の顧客と共有する画面）か、依頼書・報告書のような書類です。権限の設計はS7で詳しく扱います。

④ AIに渡す範囲を決める

AIツールは入力内容の扱いが契約によって異なります。「限定」以上の情報を渡してよいツールと条件は、ガバナンスキットのツール管理台帳で確認し、確認できないうちは渡しません。

⑤ 終わり方を決める

外注が終わったとき、顧客との取引が終わったとき、パートナーが抜けたときに、アクセスを止め、保存期間を過ぎた情報を消します。期限のないデータは、持ち続けるだけで責任になります。

冗談、仮名、テスト用のデータは、本番のフォルダに入れない。遊び場と本番を分けることは、S1で決めた原則のままです。

ファイルはどう管理するか

ファイルが増えると、探せない・どれが最新か分からない・誰が変えたか分からない、の3つが起きます。次の5つのルールで防ぎます。

1. 1ファイル＝1件。 1人・1顧客・1案件・1タスクごとにファイルを分けます。1つのファイルに複数を並べると、権限が切れなくなり、削除もできません。

2. 冒頭に必ず項目欄をつける。 S1でつけ始めた項目欄に、review（見直しの期限）を足します。

---
id: person-yamada
type: person
sensitivity: 限定
owner: 自分
updated: 2026-09-21
review: 2027-03
---

sensitivity（機微度）、owner（更新責任者）、updated（最終更新日）、review（見直しの期限）の4つが揃っていれば、AIに「更新が半年以上前で、機微度が限定のファイルを出して」と頼めます。

3. 正本は1か所。 同じ情報を2か所に書きません。写しを置くと、片方だけ更新されて食い違います。別の場所からはファイルのパスで参照します。

4. 添付は本体に埋め込まない。 契約書PDFや請求書は別に保管し、MDにはパスと要点だけを書きます。

5. 変更の履歴とバックアップを残す。 クラウドの版履歴かGitで、誰がいつ変えたかを追えるようにします。バックアップは、元の場所とは別の場所に持ちます。

6. 管理するものすべてに、IDを振る。 顧客・メンバー・案件だけでなく、作って売るもの（製品のロット、出荷した1個）にも番号を振ります。名前で探すと、同姓同名や表記ゆれで、別人・別物が混ざります。

• 顧客のID： 会員登録を求めなくても作れます。注文や申込のときに入力されたメールアドレスを手がかりに、新しいIDを自動で振り、同じ人だと分かったら後から統合します。リピートの分析や、顧客の層分けは、このIDがあって初めてできます。
• 製品のID： 製造番号と、出荷前の写真を紐づけて、品質の保証期間（食品なら賞味期限）まで残します。問い合わせや苦情に、記憶ではなく記録で答えられます。登録は、梱包の直前にボタン1つで済む形にすると続きます。

データの量で、置き場所を変える

数百〜数千件までなら、MDファイルとフォルダで十分です。数万件の顧客を扱う、外部の人が同時に書き込むような規模になったら、専用のデータベースのサービス（SQL系のサービスなど）を検討します。そのときも、項目欄・ID・機微度・正本の考え方は、そのまま持っていけます。最初から大きな仕組みを契約しないことです。

3種類のデータを分けて置く

人に関するデータは、性質の違う3種類があります。混ぜずに、置き場所を分けます。

myproject/
  ├── ontology/
  │     └── people/          関係者・チームメンバー  ← S1で作成済み
  ├── customers/             顧客（S6で追加）
  ├── staff/                 従業員（雇用したときだけ・S6で追加）
  ├── projects/              プロジェクトの運営（Part 2で作成）
  └── outsource/             契約と支払（Part 9で作成）

ontology/ はAIが判断の根拠として広く読む場所です。顧客の個人データや従業員の評価を入れると、外注先やAIツールに渡る範囲が広がりすぎます。そのため、顧客と従業員は ontology/ の外に分けます。

	従業員	顧客	関係者・メンバー
置き場所	staff/	customers/	ontology/people/
持つもの	担当・稼働・契約条件・評価の要点	取得目的に必要な項目だけ（下の設計票）	専門・相談できること・最後に連絡した日・一緒に動いた実績
持たないもの	マイナンバー・口座・健康情報（専用サービスへ）	「いつか使うかも」の項目	本人が見て納得できない評価・推測
機微度の初期値	限定	限定	社内
終わりの扱い	退職で権限を止め、期限で削除	取引終了後、保存期間で削除	関係が終わったら、本人と相談して整理

顧客のデータ。 蓄積を始める前に、次の8項目を1枚に書きます。設計せずに集め始めると、便利になるほど危うくなります。

項目	決めること
取得目的	何のために取るのか。目的外に使わないと決める
最小項目	目的に必要な項目だけ。「いつか使うかも」で増やさない
同意	誰から、どうやって取るか。未成年が対象なら保護者の同意
帰属	法人の業務データと、個人のデータを混ぜない
閲覧権限	誰が見られるか。外注先・AIツールに渡る範囲も含める
保存期間	期限のないデータは持たない
削除・持ち出し	本人から求められたとき、消せるか・渡せるか
AI推論の人間承認	AIの推定をそのまま相手に提示してよい範囲はどこまでか

AIの推定は事実ではありません。 相手の状況を決めつけた提案は、外れたときに一度で信用を失います。個別提案を出す前に人が確認する境界を、先に決めておきます。

関係者・メンバーのデータ。 S1で作った ontology/people/ の人物ファイルを、一緒に動く相手の台帳へ育てます。

## 山田さん（デザイナー）

- 専門：LP・バナーのデザイン
- 頼めること：構成からの初稿制作、修正対応
- 頼みにくいこと：動画編集
- 最後に連絡した日：2026-09
- 契約形態：業務委託（継続）

### 一緒に動いた実績
- 2026-06：LP制作 150,000円 → 公開後の問い合わせが増加
- 関連ファイル：projects/lp-renewal/、outsource/山田さん_LP制作.md

守ることが3つあります。

• 本人に見せても問題ない内容で書く。 「信頼度：高」のような主観の点数は置かず、「何を頼んで、何が返ってきたか」の事実を残します。
• 調べてよいのは公開情報だけ。 AIエージェントに、相手の会社サイトや発表内容をWEBリサーチさせて背景を追記させるのは有効です。ただし、私生活や非公開の情報は集めません。
• 投資対効果はS5の finance/investment/ と紐づける。 「この関係に何を投じ、何が返ったか」を数字で追えると、AIが「このプロジェクトに誰を動かせるか」を根拠つきで提案できます。

このデータ設計は法的助言ではありません。個人情報の利用目的・安全管理・委託先の監督・本人からの請求への対応は、実際に取り扱う前に、顧問の専門家に確認してください。

コピペ①：置き場所を分けて作る

指示：myproject に、顧客・案件・外注の置き場所を作ってください。

詳細：
- 作るフォルダ：customers/・projects/・outsource/（従業員を雇っている場合は staff/ も）
- 顧客と従業員の情報は ontology/ の外に置く
- 各フォルダに README.md を置き、「何を置くか・機微度の初期値（customers と staff は限定）・見られる人」を書く
- マイナンバー・口座・健康情報・パスワードは、どこにも置かないルールも書く

コピペ②：顧客データの設計票を書く（顧客データを持つ場合）

指示：customers/ に顧客データを貯める前に、customers/設計票.md を作ってください。

詳細：
- 次の8項目を、私に1つずつ質問しながら埋める
- 8項目：取得目的／最小項目／同意（未成年なら保護者）／帰属／閲覧権限（外注先・AIツールを含む）／保存期間／削除・持ち出し／AIの推定を相手に出す前に人が確認する範囲

---

Part 2：チームの構造をOntologyにする

4〜5人のプロジェクトを運営するには、まず「このプロジェクトでは、誰が何に責任を持つか」を、ファイルとして持ちます。

相手の契約形態で、運営の強さが変わる

同じ「メンバー」でも、AIエージェント・業務委託・雇用では、指示の出し方、稼働の管理、評価の仕方が変わります。 特に、業務委託の相手に、雇用のような指示や管理をすると、契約の形と実態が食い違います（Part 7で説明）。先に全体を表で押さえます。

	AIエージェント	業務委託・パートナー	雇用（従業員）
指示出し	細かく書く（目的・制約・完了条件）	成果物と条件を渡す。やり方は任せる	業務の指示ができる
稼働の管理	実行ログ・使用量（コスト管理として）	納期とマイルストーンで見る。時間・場所は指定しない	労働時間の管理が必要
成果判定	証拠つきの完了報告を、人が確認	検収（合格条件に照らす）	業務の評価
評価	しない（改善はルールに返す）	次も頼むかの判断（証拠パック）	人事評価

小規模プロジェクトの中心は、左の2列です。右の列（雇用）は、Part 8の基準を満たしてから検討します。

プロジェクトのフォルダを作る

1つのプロジェクトを1フォルダにします。中身は、指示・検収・振り返りが、1か所にそろう形です。

projects/
  └── lp-renewal/                LP刷新プロジェクト
        ├── project.md           目的・期間・責任者・役割表・予算
        ├── tasks/               指示書（1タスク＝1ファイル）
        ├── acceptance/          検収記録（1納品＝1ファイル）
        └── review.md            振り返り・次も頼むかの判断

project.md の例です。

---
id: project-lp-renewal
type: project
sensitivity: 社内
owner: 自分
updated: 2026-09-21
---

## LP刷新プロジェクト

- 目的：問い合わせ数を、2026年12月までに前年同月の1.5倍にする
- 期間：2026-10-01 〜 2026-12-15
- 予算：300,000円（外注費）
- 責任者：自分

### 役割表
| 誰 | 役割 | 契約形態 | 責任を持つこと |
|---|---|---|---|
| 自分 | プロジェクト責任者 | — | 目的・優先順位・最終判断 |
| AI（実行役） | 構成案・文章の下書き | — | 指示書の範囲の作業と、証拠つきの報告 |
| AI（確認役） | 実行役の成果物の点検 | — | 合格条件との照合と、差分リスト |
| 山田さん | デザイン | 業務委託 | 合意した成果物の納品 |
| 佐藤さん | コーディング | 業務委託 | 合意した成果物の納品 |

ポイントは3つです。

• 責任者は、必ず人にします。 AIは「実行役」と「確認役」にできますが、説明責任は人が持ちます。
• 実行役と確認役を分けます。 実行した本人が自分の成果物を採点すると、見落としが残ります。
• 役割表が、そのままAIへの指示の前提になります。 「project.md を読んで、次に誰に何を頼むべきか整理して」と頼めるようになります。

決定権限：誰が何を決めるか

小規模なチームほど、「これは誰が決めるのか」が曖昧になり、AIが勝手に進めたり、逆に何でも確認が来たりします。decision_rights.md を1枚置いて、3つに分けます。

区分	内容	例
Always（確認なしでやってよい）	間違えても戻せる作業	下書きの作成、議事録の整理、リサーチ、テストの実行
Ask first（先に承認を取る）	戻しにくい、または対外に影響する作業	依頼の送信、公開、費用の発生、大きな仕様の変更
Never（やらない）	人だけが決めること	契約・解除、報酬の決定、採用・関係の打ち切り、認証情報の扱い

採用・報酬・契約の更新や解除は、AIに決めさせません。 AIには、判断材料をそろえる（証拠の整理、抜け漏れの指摘、文案の下書き）ところまでを任せます。

コピペ③：プロジェクトと決定権限を書く

指示：案件の project.md と、決定権限の decision_rights.md を作ってください。

詳細：
- project.md の場所：projects/【案件名】/project.md
- project.md の中身：目的（数字と期限つき）・期間・予算・責任者（人）と、役割表（誰／役割／契約形態／責任を持つこと）
- AIは「実行役」と「確認役」に分ける
- decision_rights.md は myproject 直下に置く
- Always（確認なしでよい）／Ask first（先に承認）／Never（人だけが決める）に、私の仕事を仕分ける案を出す
- 契約・報酬・採用・関係の打ち切りは Never にする

---

ダッシュボード：会社の状態を一目で見る

S6の背骨はダッシュボードです。 Part 1で置いたデータと、Part 2で決めた構造は、画面に並んで初めて「使えるデータ」になります。そして、この先のPart 3〜9は、どれも「ダッシュボードに欄を1つ足すこと」として進みます。

Part 2までで、project.md と decision_rights.md ができました。この2つがあれば、外出先でもスマホから見られる、自分専用のダッシュボードの土台が作れます。

高価なBIツールは要りません。「projects/ の中身を読んで、進行中のプロジェクトと役割表が一目で分かる、1ページのダッシュボードを作って」とAIに頼めば、静的なページができます。有料の業務アプリ（kintoneのような）がしていたことの多くは、Ontologyの中のデータから、自分で作れます。

作る順番：試作→作り込み→Web

1. AIエージェントの中で作る。 Claude CodeなどのAIエージェントは、頼めばその場で画面を作って見せてくれます。ただし、パソコンの中の一時的なサーバーで動いているので、パソコンを閉じると見られなくなり、「前に作ったあの画面はどこだっけ」が起きます。ここは試作の場所です。
2. 使いやすくなるまで作り込む。 何度か使って、「最初の画面で何が分かればいいか」が固まるまで直します。Claudeのアーティファクト（会話の中で作るページ）のように、手軽に直せる場所で形を決めてから次へ進むのが、いちばん早い道です。
3. Webに置いて、スマホから24時間見られるようにする。 Cloudflare Pagesなどに置き、先にログインの保護をかけてから公開します（次の表）。

コピペ④：ダッシュボードの土台を作る

指示：projects/ の中身を読んで、1ページのダッシュボードを作ってください。

詳細：
- 進行中のプロジェクトと役割表が一目で分かる
- 読み取り専用。画面からデータを書き換えない
- 対応が要るもの（期限超過・検収待ち・判断待ち）を上に出す
- お金と給与の数字は写さない
- スマホ幅でも崩さない
- まず、この会話の中で見られる形で作る

何度か使って直したら、見られる範囲（本文の3種類の表）を決め、Webに置く場合は先にログインの保護をかけてから公開します。

見られる範囲を、中身で決める

置き場所を決めるのは、技術の好みではなく、中身の機微度（Part 1）です。

見られる範囲	向くもの	注意
自分のパソコンの中だけ（localhost）	試作、限定情報を含む自分専用の画面	パソコンを閉じると見られない
同じWi-Fiにつながった端末だけ	店舗・事務所の中だけで見せたい画面（例：店内で見られる、今日の残り在庫と待ち時間）	店の外からは見えないが、守りの強さはログインに及ばない
Web（インターネット）	外出先からスマホで見る画面、顧客と共有する画面	ログインの保護が必須。 機微度が「限定」以上の情報は、保護があっても載せすぎない

守り方の基本は、「破られない壁を作る」より、「どこに何を出すかを調整する」ことです。公開する画面には、漏れても致命傷にならない情報（今日の在庫、受付の状況など）だけを載せ、重要な情報は、本人だけが見られる画面か、手元に残します。ログインの保護は、Cloudflare Access（Zero Trust）で、許可したGoogleアカウントだけが入れる形にするのが手軽です。会社のGoogle Workspaceのアカウントを使えば、さらに強くできます。

お金と事業の分け方

お金と給与の数字は、ダッシュボードに写しません。 売上・給与・報酬の明細は、S5の finance/ に置いたままにし、ダッシュボードは、そこを参照して要点だけを出す「表の窓口」にします。数字を画面側に写すと、正本が2つになり、食い違います（Part 1の「正本は1か所」）。

事業が複数あるなら、事業ごとに画面を分けて、横に並べます。 全部を1枚に混ぜると、どの数字がどの事業のものか分からなくなります。会社（または自分）を上に置き、その下に事業ごとのタブやカードを並べる形が、いちばん迷いません。

Partが進むごとに、欄を1つ足す

ここで作るのは、完成形ではなく土台です。 ダッシュボードに載せる項目は、この先のPartが1つ進むごとに、1つずつ増やしていきます。

進んだPart	ダッシュボードに足す項目	元データ
Part 2	進行中のプロジェクトと役割表	projects/*/project.md
Part 3・4	今日の未完了タスク、期限超過・停滞しているタスク	projects/*/tasks/
Part 5	検収待ち・不合格になっている納品	projects/*/acceptance/
Part 6	次も頼むかの判断が要る案件	projects/*/review.md
Part 7・9	取引条件の明示が未完了の案件、今月の外注費と支払期日	outsource/

画面づくりの基本は、次の2つです。

• ダッシュボードは読み取り専用にする。 Part 4の原則と同じで、書き込みは各Partの手順（指示書・検収記録・outsource/など）で行い、ダッシュボードからは直接データを書き換えません。
• 出すのは「いま見るべきもの」だけ。 全項目を並べると、結局見なくなります。期限超過・検収待ち・判断待ちのように、対応が要るものだけを上に出す設計にします。

画面の上で仕事をする

ダッシュボードは、眺めるためのものではありません。価値は、「予約がスタッフの手に余りそうだ」と気づいた瞬間に、その場でAIと対策を相談し、次の手を打てることにあります。育ってくると、別のブラウザやアプリを開かずに、1日の仕事の多くがこの画面から始まるようになります。

画面に置くもの	何ができるか	守ること
AIへの指示ボタン	よく頼む仕事（週次の棚卸し、報告の取り込みなど）を、指示書（Part 3）の形で登録しておき、ボタンで渡す	渡すのは指示文まで。Always / Ask first / Never は指示書の中に書く
連絡の下書きボタン	状況（納期超過、検収待ちなど）から連絡の案を出し、メールの下書きを作る	送信は、本文を読んでから自分で行う
朝のまとめ（モーニングブリーフ）	受信箱・チャット・予定・引き継ぎの要点を、毎朝決まった欄に出す	表示する欄を固定する。欄が毎回変わると、何が抜けたか気づけない

「読み取り専用」の原則（上記）と、ボタンで仕事を始めることは両立します。ボタンが作るのは、指示文と下書きまでです。データを書き換えるのは、各Partの手順と台帳の側です。

画面にAIを常駐させるなら、APIを使います。 普段使っているチャットやClaude Codeは、月額の定額契約で、自分のパソコンの上で動きます。画面の上で、パソコンを閉じていても24時間AIが答える仕組みにするには、APIという従量課金の契約が別に要ります。始める前に、月の利用額の上限を決めておきます。顧客に一般的な案内を返す程度なら、APIで十分に作れます。APIキー（認証情報）は「預けない」情報です（Part 1）。MDファイルやAIが読むフォルダには置かず、置き場所のサービスの秘密の設定欄に入れます。

見た目は、毎日開きたくなるものにしてよい。 画面は、毎日何度も開くものです。好きな配色や世界観にすることは、続けるための工夫として有効です。ただし、状態を表す色（赤＝対応が要る、など）の意味だけは崩しません。

完成形の型と見本は、事業ダッシュボード・テンプレートにあります。第2回・第3回のミニワークで、自分の会社用に作ります。

---

Part 3：指示を出す

指示は、宛先によって書き方が変わります。

AIエージェントへの指示

AIは、指示が曖昧だと、もっともらしい別のものを作ります。1つの仕事を、次の欄で書きます。projects/{案件}/tasks/ に1タスク1ファイルで置きます。

---
id: task-lp-001
type: task
project: lp-renewal
assignee: AI（実行役）
sensitivity: 社内
updated: 2026-09-21
---

## Goal（結果）
LPのファーストビューの構成案を3案作る。

## Context（読むもの）
- projects/lp-renewal/project.md
- ontology/concepts/ターゲット顧客.md

## Constraints（制約）
- 触ってよいのは projects/lp-renewal/ の中だけ
- 事実の裏づけがない数字は書かない

## Non-goals（やらないこと）
- デザインの決定、実装

## Always / Ask first / Never
- Always：構成案の下書き
- Ask first：外部への共有、費用が発生する調査
- Never：公開、顧客データの参照

## Done when（完了条件）
- [ ] 構成案が3案あり、それぞれに狙いが1行ある
- [ ] 根拠にしたファイルが、案ごとに示されている

## Evidence（証拠）
作ったファイルのパスと、どの完了条件を満たしたかを、一覧で報告する。確認できていないことは「未確認」と書く。

## Handoff（次に渡す）
次の担当が会話を見なくても着手できるよう、残課題を書く。

指示を書くときのTipsです。

1. 結果を書く。手順は書かない。 「何が変われば成功か」を先に置きます。
2. 完了条件は、確認できる形にする。 「ちゃんと確認して」ではなく、「テストが通る」「3案ある」のように、誰が見ても合否が分かる文にします。
3. Always / Ask first / Never を書く。 全部を確認制にすると使えず、全部自由にすると事故が起きます。
4. 短く書く。 常設のルールは短く正確に。長い指示は、守られなくなります。
5. 1つの指示は、1つの成果にする。 複数の成果を混ぜると、確認できません。
6. 複数のファイルにまたがる仕事は、先に計画を出させる。 人が計画を承認してから実行させます。
7. 同じ誤りが2回起きたら、その場の修正ではなく、ルールのファイルを直す。 指摘を成果物にだけ返すと、再発します。
8. 「できた」ではなく証拠を出させる。 コマンドの結果、ファイルのパス、差分の要約です。
9. 実行役と確認役を分ける。 実行した側に、自己採点させません。

AIに全部任せて人は見なくてよい、という運用は、うまくいきません。人が持つのは、目的・優先順位・最終判断・対外の接点です。AIには、下ごしらえと点検を任せます。

コピペ⑤：AIへの指示書を1件書く

指示：projects/【案件名】/tasks/【task-001】.md に、仕事の指示書を作ってください。

詳細：
- 仕事の内容：【例）LPのファーストビューの構成案を3案作る】
- 欄：Goal（結果）／Context（読むもの）／Constraints（制約）／Non-goals（やらないこと）／Always・Ask first・Never／Done when（第三者が合否を判定できる完了条件）／Evidence（証拠の出し方）／Handoff（次に渡すこと）

業務委託・パートナーへの指示

業務委託の相手に渡すのは、指示ではなく、成果物の依頼です。

• 渡すもの： 成果物の内容、合格条件、納期、報酬、修正の回数、検収の方法
• 渡さないもの： 作業の進め方、作業する時間や場所、勤務のような時間管理

「どう作るか」は相手の専門性に任せます。この線引きは、契約の実態を守るためにも重要です（Part 7）。AIに下書きさせるのは、依頼書の文面までです。送信は人が行います。

依頼書には、取引条件の明示事項（Part 7で説明）を含めます。

---

Part 4：労働管理（進捗と稼働）をOntologyで回す

4〜5人のプロジェクトで必要なのは、専用の管理システムではありません。次の3つの習慣で足ります。

1. 原本は1つ。 タスクの原本を projects/{案件}/tasks/ に置き、期限別の一覧や週次のレポートは、原本から毎回作り直します。 一覧を別に更新すると、食い違います。

2. 朝に、未完了だけを見る。 AIに「今日の未完了を、期限順に出して」と頼みます。出てきた一覧を見て、その日の優先順位を決めます。完了したら「task-lp-001 完了」のように、ファイルのIDで指します（一覧の番号は日で変わるので、識別子にしません）。

3. 週に1度、棚卸しする。 「今週の完了・期限超過・停滞・新しく決まったルール」を出させ、必要なものを指示書やルールのファイルへ戻します。

（週次の棚卸しの依頼例）

「projects/lp-renewal/ を読んで、次を出して。
 1. 今週完了したタスク（証拠つき）
 2. 期限を過ぎているタスクと、原因の推定
 3. 3日以上動いていないタスク
 4. 今週決まったルールで、decision_rights.md に反映すべきもの」

AIには、自動で書き込みをさせません。 定期的な実行は、読み取りと一覧の作成までにします。書き込みは、人が内容を見てから指示します。自動で書き換えると、誤りに気づけません。

ダッシュボード（ダッシュボードの章）を作り直す定期実行（例：朝10時と夕方6時）は、読み取りと画面の生成だけなので、この原則の内側です。

報告は、自由な形で受ける

メンバーやパートナーからの報告を、ダッシュボードの項目に合わせた入力フォームにしたくなります。しかし、画面にある項目しか報告されない状態になると、項目に入らない気づきや、相手の迷いが消えます。

• 報告は、自由記述のメール・チャット、または話した内容の議事録（音声の文字起こし）で受けます。
• 受け取った報告は、reports/ に1件1ファイルで保存し、項目への整理はAIに任せます。
• 外注先には、「この形で書いて」より、「メールで送ってください。こちらはAIで整理しています」と伝えるほうが、報告が続きます。

問題があったときだけ上がってくる形にする

全員の動きを常に見張る仕組みは、作る側も見る側も疲れます。小規模プロジェクトでは、例外が起きたときだけ、自分に知らせが来る形を基本にします。

• 報告が7日以上届かない、納期を過ぎた、検収の期限が近い——のように、「知らせる条件」を先に決めて、条件に当たったものだけをダッシュボードの上に出します。
• 条件に当たらないものは、見なくてよい状態にします。見るべきものが少ないほど、見落としが減ります。

コピペ⑥：週1回、棚卸しする（毎週）

指示：projects/【案件名】/ と reports/ を読んで、今週の進み具合の一覧を出してください。

詳細：
- 出すこと：
  1. 今週完了したタスク（証拠つき）
  2. 期限を過ぎているタスクと、原因の推定
  3. 3日以上動いていないタスク
  4. 7日以上報告が届いていない相手
  5. 今週決まったルールで、decision_rights.md に反映すべきもの
- 書き込みはしない。一覧だけ出す

引き継ぎが切れたら、過去のやり取りから復旧する

担当が急に抜けた、記録を残していなかった——小規模プロジェクトでは、よく起きます。このとき、過去のメールやチャットを、AIにまとめて読ませると、引き継ぎをかなりの精度で復旧できます。

（AIへの依頼例）

「この2か月分の、〇〇さん（顧客）とのメールを全部読んで、次を出して。
 1. 決まっている方針と、その根拠になったメール（日付つき）
 2. 約束したが、まだ実行していないこと（振替・再送・返事待ちなど）
 3. 相手の側で止まっていること
 確認できないことは『未確認』と書いて。推測で埋めないで。」

復旧した内容は、その場で projects/ や customers/ の正本に書き戻します。誰も頼れない状況のときこそ、AIの価値は大きくなります。 そして、二度と同じ復旧をしなくて済むように、報告の置き場所（上記）を決めておきます。

顧客や保護者とのメールには、「限定」の情報が多く含まれます。読ませるAIツールは、Part 1の④で確認したものに限ります。

相手ごとの「稼働」の扱い

• AIエージェント： 実行の記録と使用量を、コストの管理として見ます。使用量を、成果の評価には使いません。
• 業務委託・パートナー： 見るのは、納期とマイルストーンです。「今日は何時間働いたか」は管理しません。進捗は、成果物の完成度で確認します。
• 雇用： 労働時間の管理が法令で必要になります。小規模プロジェクトの対象に入れず、社会保険労務士など専門家に任せます（Part 8）。

---

Part 5：成果を判定する（検収）

渡した仕事が終わったかどうかは、あらかじめ決めた合格条件で判断します。 好みや気分で判断すると、相手も自分も消耗します。

発注時に、1枚で固定する

projects/{案件}/acceptance/ に、納品ごとに検収記録を作ります。発注の時点で、次の項目を書きます。

---
id: acceptance-lp-001
type: acceptance
project: lp-renewal
deliverable: ファーストビューのデザイン初稿
sensitivity: 限定
updated: 2026-10-05
---

## 成果物
- 内容：LPのファーストビューのデザイン（デスクトップ・スマホ）
- 形式：Figmaのリンク
- 納期：2026-10-12

## 合格条件（3〜5個。第三者でも合否が判定できる文で書く）
- [ ] デスクトップとスマホの2種類がある
- [ ] 指定した3つの要素（見出し・画像・申込ボタン）がファーストビューに入っている
- [ ] 指定のブランドカラーとフォントを使っている

## 検収の条件
- 修正の回数：2回まで
- 検収の期間：受領から5営業日
- 検収者：自分
- 期間内に連絡がない場合の扱い：（事前に決めて書く）

## 検収の結果
- 結果：合格 ／ 一部不合格 ／ 不合格
- 不合格の項目：（どの合格条件が、どう足りないか）
- 新しい要望：（合格条件にないものは、変更の依頼として別に扱う）

検収の運用で守ることです。

• 不合格の理由は、合格条件のどれが足りないかだけ。 合格条件にない要望は、変更の依頼として別に扱います。これを混ぜると、修正が終わらなくなります。
• フェーズごとに検収と支払を分ける。 大きな仕事は、成果物を段階に分け、段階ごとに完了条件を決めます。
• 検収は品質のゲート、支払は法令のゲート。 検収に時間がかかっても、支払の期限は動きません（Part 7）。
• AIは、合格条件との照合と、差分のリストまで。 合否は、検収者である人が決めます。AIが作った成果物でも、AIが確認した成果物でも、人が確認を緩めません。

コピペ⑦：外注の依頼と検収記録を、1枚で作る

指示：【相手の名前】さんへの依頼について、発注の1枚 projects/【案件名】/acceptance/【acceptance-001】.md と、依頼メールの下書きを作ってください。

詳細：
- 発注の1枚の項目：成果物／形式／納期／合格条件（3〜5個。第三者でも合否が判定できる文）／修正の回数／検収の期間と検収者／報酬と支払期日
- 取引条件の明示事項（双方の名称・委託日・内容・納期と場所・検収の完了期日・報酬と支払期日・支払方法）に抜けがないかを確認する
- 進め方・作業時間・作業場所は指定しない
- 依頼メールは下書きまで。送信は私がします

---

Part 6：業績評価（次も頼むか、どう改善するか）

小規模プロジェクトの評価は、大企業の人事評価とは別物です。次の3つの型から選びます。

型	向く場面	中身
A：マイルストーン検収型	業務委託・パートナーの仕事	検収（Part 5）の積み重ねが、そのまま評価になる
B：軽量OKR＋週次確認型	チーム全体の方向を揃えるとき	目標（Objective）は1〜3、測定できる結果（KR）は各2〜3。週1回、計画・進捗・詰まりだけを更新する。報酬とは切り離す
C：証拠パック＋AI下書き型	継続する相手の、契約更新の判断、自分の四半期の振り返り	証拠をそろえ、AIが下書きを作り、人が確認して判断する

型Cの進め方

projects/{案件}/review.md に、次の証拠を集めます。

• 成果物の一覧と、それぞれの検収の結果（合格条件ごとの達成状況）
• 納期を守れたか、修正の回数は何回か
• 議事録や、やり取りのリンク

（AIへの依頼例）

「projects/lp-renewal/acceptance/ を全部読んで、山田さんの案件について、
 次の形で下書きを作って。
 1. 成果物ごとの、合格条件の達成状況
 2. 納期と修正回数の一覧
 3. 次も頼むかを判断するための論点（事実だけ。推測は書かない）
 評価の点数や、報酬額の提案は書かないでください。」

コピペ⑧：次も頼むかを判断する材料をそろえる

指示：【相手の名前】さんの案件について、次も頼むかを判断するための下書きを作ってください。

詳細：
- 読むもの：projects/【案件名】/acceptance/ の全部
- 入れること：
  1. 成果物ごとの、合格条件の達成状況
  2. 納期と修正回数の一覧
  3. 次も頼むかを判断するための論点（事実だけ。推測は書かない）
- 評価の点数や、報酬額の提案は書かない
- projects/【案件名】/review.md に保存する。決めるのは私

評価で守ること

1. AIは、評価者にしない。 AIに任せるのは、証拠の抜け漏れのチェック、時系列の整理、文案の下書きまで。契約の更新、報酬、関係の打ち切りは、人が決めます。
2. 活動量を成果と取り違えない。 稼働時間・やり取りの量・AIの使用量・入力の量は、成果ではありません。これらで評価すると、数字を作ることが目的になります。
3. OKRを、報酬や契約更新の自動的な条件にしない。 方向を揃える道具と、報酬の判断は、別に持ちます。
4. 相手にも証拠を見せる。 判断に疑問があれば、根拠を説明できる状態にします。
5. 業務委託の相手には、「人事評価」の形を取らない。 見るのは、成果物の検収と、契約更新の判断です。勤務態度や時間の使い方は、評価の対象にしません。
6. 改善は、ルールに返す。 「毎回こうなる」は、人の問題にせず、指示書のテンプレートや合格条件を直します。

---

Part 7：法的な線引き（小規模で最低限おさえること）

このPartは、公開されている一次情報をもとにした論点の整理です。法的な助言ではありません。契約の形や、個別の判断は、専門家（弁護士・社会保険労務士）に確認してください。

業務委託が、雇用と見なされないために

「業務委託」という契約の名前があっても、実態で判断されます。 労働基準法上の「労働者」かどうかは、契約の形式ではなく、契約の内容、労務提供の形態、報酬などの要素から、総合的に判断されます。厚生労働省の整理では、次の要素が見られます。

要素	見られること
仕事の依頼への諾否の自由	個々の依頼を断れるか。断れない状態は、指揮監督の関係を推認させる要素になる
業務遂行上の指揮監督	内容と進め方について、具体的な指揮命令を受けているか。通常の注文者が行う程度の指示にとどまる場合は、指揮監督とは見なされない
拘束性	勤務場所と時間を指定され、管理されているか
代替性	本人に代わって他の人が作業できるか、補助者を使えるか
報酬の性質	時間を単位に計算され、働いた時間への対価になっているか
補強する要素	事業者としての性格（自分の機械・道具を持つか）、専属性、採用の過程が従業員と同じか、など

実務での基本は、次の3点です。

• 成果物と条件を依頼し、進め方は任せる。
• 時間と場所を指定して、管理しない。
• 成果物の完成度で見る。稼働時間で報酬を決める形（準委任など）を取る場合は、契約の前に専門家に確認する。

個別の事案は総合判断です。ここに書いた基準を満たしていても、雇用と判断される可能性は残ります。

フリーランス法（取引の適正化）

2024年11月に施行された「特定受託事業者に係る取引の適正化等に関する法律（フリーランス・事業者間取引適正化等法）」は、従業員を使わない個人や1人法人（特定受託事業者）に業務を委託するときのルールを定めています。小規模プロジェクトで、業務委託の相手が個人のとき、ほぼ確実に関係します。

ここで大事なのは、発注する側が「従業員を使用しているか」で、義務の範囲が変わることです。「従業員を使用」とは、1週間の所定労働時間が20時間以上で、31日以上の雇用が見込まれる労働者を雇うことです。

発注する側	義務
従業員を使用していない	取引条件の明示
従業員を使用している	明示に加えて、報酬の支払期日（受領から60日以内）、禁止行為、ハラスメント対策など

小規模プロジェクトで、自分が従業員を雇っていない場合でも、取引条件の明示は必ず必要です。

取引条件の明示：何を、どう伝えるか

業務を委託したら、直ちに、次の事項を、書面またはメールなどの電磁的な方法で明示します。口頭だけは認められません。契約書という名前の書類でなくても、メールでの箇条書きで足ります。ただし、事項が欠けていれば不十分です。

• 双方の名称（商号・氏名）
• 業務を委託した日
• 委託する内容（成果物・提供する役務）
• 納品を受ける期日（期間）と、場所
• 検収をする場合は、検収を完了する期日
• 報酬の額と、支払期日（報酬の額を決められない事情があるときは、算定方法）
• 支払の方法に関する所定の事項（手形・電子記録債権などで払う場合など）
• 決められていない事項があるときは、その理由と、決める予定の日

この項目は、Part 5の検収記録と、そのまま重なります。検収記録のテンプレートを、依頼書としても使える形に作っておくと、明示の漏れを防げます。

契約書に入れる項目（小規模の最小セット）

• 成果物の内容と、合格条件
• 納期と、検収の期間、修正の回数
• 報酬の額と、支払期日、支払の方法
• 著作権など、成果物の権利の帰属
• 秘密の保持と、渡す情報の範囲（Part 1の機微度）
• 契約の終了の条件と、終了時の手続き（アクセスの停止、情報の返却・削除）
• （作ったWebサイトやシステムの運用まで引き受ける場合）運用・保守の範囲と、セキュリティ上の事故が起きたときの責任の範囲。作って渡すだけなら、納品物（ファイル一式）の受け渡しで終わる形にする

対象外にすること

労働時間の管理、就業規則、社会保険、労働契約の詳細は、S6の対象外です。雇用が発生する場合は、専門家に任せます。

---

Part 8：人を正式に雇う基準

外注ではなく「雇用」に踏み切る判断は、慎重に行います。

雇うべきは作業をする人ではなく、管理をする人です。作業はAIと業務委託で回します。外注や業務全体を管理・統括できる人材が必要になったときだけ、雇用を検討します。

費用対効果の目安は、時代背景で挙げたとおり、従業員1人あたり粗利800万円〜1,000万円です。この水準を、雇う人数分まかなえる見込みが立ってから、雇用を検討します。伊藤の運用上の目安であって、法や統計に基づく基準ではありません。自分の事業の数字で見直してください。

S5のStep 1〜2（緊急時資金の確保・高金利負債ゼロ）を完了する前に、固定の人件費を増やすことは、持続可能性を損なうリスクです。

雇用が発生したら、Part 1の staff/ を作ります。労働時間・社会保険・給与の管理は、専用のサービスと専門家に任せ、Ontologyには、役割・担当・契約条件と、判断に使う要点だけを置きます。

外注がまだゼロでも、S6は始められる

S6の習得に、外注の予算は必要ありません。まず「自分・AI・外注」の3区分で、いまの業務を紙の上で整理します。

区分	担当	判断基準
意思決定・戦略	自分	絶対に外に出さない
繰り返し・定型の仕事	AI	まずAIで試す
専門性が必要な単発作業	外注（業務委託）	自分でやろうとしない

最初の外注は、数千円の単発業務で十分です。バナー1枚のデザイン、音声データの文字起こし、データ入力を、クラウドソーシングで小さく1件発注します。「依頼を設計し、進捗を管理し、成果物を検収する」という型は、この1件で完成します。

---

Part 9：契約と支払を、MDファイルで管理する

外注先との契約と支払は、outsource/ フォルダに、1案件につき1ファイルで置きます。仕事の流れ（指示・検収・振り返り）は projects/、約束したこと（契約・報酬・支払・終了時）は outsource/ と、役割を分けます。

myproject/
  └── outsource/
        ├── 山田さん_LP制作.md
        ├── 佐藤さん_コーディング.md
        └── 鈴木事務所_税務.md

テンプレート：

---
id: outsource-yamada-lp
type: outsource
sensitivity: 社内
owner: 自分
updated: 2026-09-21
---

## 山田さん_LP制作

### 基本情報
- 担当者：山田さん（デザイナー）
- 目的：LPのデザイン制作
- 契約形態：業務委託（単発）
- 関連：projects/lp-renewal/

### 取引条件（Part 7の明示事項）
- 委託日：2026-09-21
- 成果物：LPのデザイン（デスクトップ・スマホ）
- 納期・場所：2026-10-12、Figmaで納品
- 検収の完了期日：受領から5営業日
- 報酬：150,000円（一式）、支払期日：納品の受領から60日以内で、できる限り短い具体的な日付を指定
- 明示の方法：メール（2026-09-21送信）

### 渡した情報
- LPの構成案（機微度：公開）

### 進捗
- [x] 依頼書の送信（2026-09-21）
- [ ] 初稿の納品と検収
- [ ] 最終納品・検収
- [ ] 支払

### 終了時
- [ ] 共有していたフォルダ・アカウントのアクセスを止めた
- [ ] 渡した情報の返却・削除を確認した

AIへの依頼例：

• 「outsource/ を読んで、今月の外注費用の合計と、支払期日が近いものを教えて」
• 「終了した案件のうち、アクセス停止が未完了のものを出して」
• 「取引条件の明示事項に、抜けがある案件を出して」

外注コストを finance/ に連携させる

outsource/ の費用データは、月次で S5 の finance/monthly/ に反映します。外注費が収支データとして蓄積されることで、S5のAI分析で「どの外注がコストを押し上げているか」を評価できるようになります。

（AIへの依頼例）

「outsource/ の今月の全案件を読んで、外注費用の合計を計算してください。
その結果を、今月の finance/monthly/ の月フォルダにある収支の
外注費の欄に追記してください。
また、前月と比較してコストが増加している外注先があれば教えてください。」

---

Part 10：関係資本を育てる、toMe

関係資本のサイクル

S1で作った ontology/people/ を、プロジェクトの実績で育てます。

人物ファイルに、一緒に動いた実績を追記する
     ↓
AIエージェントが、公開情報のリサーチで背景を補強する
     ↓
AIが、次のプロジェクトに最適な組み合わせを提案する
     ↓
プロジェクトの成功が、新しいつながりを生む
     ↓
新しい人物ファイルを追加する（ループ）

背景情報が蓄積されると、AIの提案は次のように変わります。

【背景知識なし】
「山田さんにデザインを頼んでは？」

【背景知識あり】
「山田さんは、LP制作で問い合わせが増えた実績がある。
 今回のプロジェクトは、佐藤さんのコーディングとの組み合わせで、
 初稿から実装まで、期間を短くできる可能性がある。」

toMe：同じ仕組みを顧客に向ける

Part 1で顧客データを設計したら、そのデータを使って、顧客ごとの提案を作れます。S4の toC・toB・toM が「誰に届けるか」の広がりだとすると、toMe は「どう届けるか」の進化です。

toC × toMe → 来店客ごとに最適なメニューを提案する
toB × toMe → 飲食店オーナーの業態・規模に合わせた導入プランを提案する
toM × toMe → 業界イベントの参加者属性に応じた講演内容を変える

toMeを始める条件は1つだけです。データ設計票の8項目を書いてから、蓄積を始めること。

顧客と共有するダッシュボード

toMeのいちばん手前の形は、顧客ごとの画面を作って、本人と共有することです。たとえば不動産の売却を任されている場合、物件ごとに次を出す画面を作り、その顧客だけがログインして見られるようにします。

• 売り出してからの経過日数と、反響（問い合わせ・内覧）の動き
• 次の報告の予定日
• こちらがやること、お客様にお願いしたいこと
• 外部の掲載サイトの情報など、根拠になる数字（出典と日付つき）

「いまどうなっていますか」という電話が減り、報告の約束が守られているかを、相手も自分も同じ画面で確かめられます。

守ることは3つです。

• 1顧客＝1画面、見られるのは本人だけ。 他の顧客の情報が1件でも混ざれば、それは漏えいです。
• 社内の判断材料は載せない。 価格交渉の方針、他の顧客との比較、AIの推定は、顧客の画面に出しません（Part 1の「AIの推定は事実ではない」）。
• 型は共通、中身は案件ごとに変えてよい。 同じテンプレートから作り、土地の売買なら「近隣の取引の動き」、賃貸なら「空室期間」のように、その案件で見守りたい項目に入れ替えます。

---

達成の目安

S6の達成は4段階で確認します。第1〜3段階は、外注がゼロでも完了できます。

第1段階：データの設計

• 「預けない」情報（認証情報・マイナンバー・口座・健康情報）をMDに置いていない
• 機微度の4段階を決め、ファイルの項目欄（sensitivity・owner・updated・review）に入れている
• 従業員・顧客・関係者のデータを、別のフォルダに分けて置いている
• （顧客データを持つ場合）データ設計票の8項目を、蓄積を始める前に書いた
• 顧客・メンバー・案件（製品を扱うなら製品も）に、IDを振っている

第2段階：チームの構造

• プロジェクトのフォルダを作り、project.md に役割表を書いた（責任者は人）
• decision_rights.md に、Always / Ask first / Never を書いた
• 業務を「自分・AI・外注」の3区分で整理できている
• 進行中のプロジェクトと役割表が見える、自分専用のダッシュボード（スマホ対応）の土台を作った
• ダッシュボードの見られる範囲を決め、Webに置く場合は、公開の前にログインの保護をかけた（第2回のミニワーク）
• ダッシュボードに、各メンバーの報告の最終日と経過日数、動く数字（アクセス・申込・クリックなどの外部データ）を載せた（第3回のミニワーク）
• お金・給与の数字をダッシュボードに写さず、finance/ を参照している

第3段階：指示・判定・評価の型

• AIへの指示書を、Goal・Context・Constraints・Done when・Evidence の欄で1件書いた
• 業務委託への依頼を、成果物と合格条件で書き、進め方や時間を指定していない
• 検収記録を、合格条件つきで1件作った
• AIを使って証拠をそろえ、次も頼むかの判断を、人が下した記録がある（review.md）
• 報告を、自由記述のメール・チャット・議事録で受け、reports/ に保存している（項目への整理はAIに任せている）
• 「知らせる条件」（報告の途絶・納期超過など）を決め、条件に当たったものだけがダッシュボードの上に出る

第4段階：外注の運用（最初の1件から）

• 取引条件の明示事項を、書面またはメールで相手に伝えた
• 外注案件を outsource/ で管理している
• 外注した業務の成果物を、少なくとも1件、検収まで終えた
• 案件の終了時に、アクセスを止め、渡した情報の扱いを確認した
• 固定の人件費が最小化されている

---

S6 レッスンプラン例

S6を勉強会や授業で扱う場合は、2時間×3回にすると進めやすいです。各回の最後に、ミニワークを行います。 上の「達成の目安」の残りは、講義のあとに各自の現場で進めます。

ダッシュボードを、S6全体の背骨にします。 実際に3回行ってみて、次のことが分かりました。

• 「データベース」は、触れたことのない人には抽象的すぎて、講義だけでは腹落ちしません。自分のデータが画面に並んだ瞬間に、分散したデータと整理したデータの違いが分かります。第1回のあとに、データベースの補習が必要になったのはこのためです。
• Part 3〜9（指示・進捗・検収・評価・外注・支払）は、法律や型として話すより、「ダッシュボードに、この欄を1つ足す」として話すと、各自の現場に結びつきます。
• 参加者が作った画面を見せ合う時間が、いちばん学びが大きい。教室の運営、不動産の案件管理、菓子の製造と予約の管理と、題材が違うほど、「自分ならこうする」が出ます。各回の後半は、画面の共有に使います。

第1回（2h）データの置き方と守り方

• 扱う範囲：時代背景、Part 1、Part 2（役割表・決定権限まで）
• 到達目標：分散したデータと整理したデータの違い、機微度・3種のデータ・データ設計票・IDの考え方を説明できる。契約形態で運営が変わること、Always / Ask first / Never の考え方が分かる
• ミニワーク：自分のデータベースを作って、運用してみる

第2回（2h）ダッシュボードを作り、外に出す

• 扱う範囲：ダッシュボードの章、Part 3〜9をダッシュボードの欄として概観
• 到達目標：作る順番（エージェントの中→作り込み→Web）と、見られる範囲の3種類が分かる。お金の数字を写さない理由、ボタンで仕事を始める考え方が分かる。Part 3〜9のそれぞれが、画面のどの欄になるかが分かる
• ミニワーク：自分のダッシュボードを、スマホから見られるようにする
• 次回までの課題：Part 5（検収）・Part 8（雇用の基準）・Part 9（契約と支払）を読んでくる

第3回（2h）会社の操縦席に仕上げる

• 扱う範囲：Part 4（報告・例外・引き継ぎ）、Part 6〜7、Part 10（顧客と共有する画面）。冒頭で課題の質問を受ける
• 到達目標：報告を自由な形で受ける理由、例外だけが上がる設計が分かる。AIを評価者にしない理由と、業務委託が雇用と見なされないための要素、取引条件の明示を説明できる。顧客と共有する画面で、出してよいもの・出さないものが分かる
• ミニワーク：会社の操縦席（ダッシュボード）をつくる

第1回のミニワーク：自分のデータベースを作って、運用してみる

お題：在庫管理・資産管理・生徒管理など、自分の現場のオリジナルデータベースを作り、少し運用してみる。（目安20〜30分）

Part 1の設計を、1つの小さなデータベースで通してみます。完璧を目指さず、「置き方を決めて、AIに使わせる」ところまで進めます。

1. 対象を1つ決める。 自分の現場で、いちばん散らばっている情報を選びます。

例	1レコードになるもの	置き場所の目安
在庫管理	商品・材料（1品＝1ファイル）	inventory/
資産管理（事業用）	備品・契約・設備（1件＝1ファイル）	assets/（個人の資産は、S5の finance/ に置く）
生徒（顧客）管理	生徒・顧客（1人＝1ファイル）	customers/

2. 項目欄を決める。 Part 1の4項目（sensitivity・owner・updated・review）に、自分の現場の5項目を足します。「相手（もの）は何か・いまどこにあるか・何に困っているか・制約は何か・次に何をするか」を、自分の言葉に置き換えます。

（在庫の例）
---
id: item-packing-box-s
type: inventory
sensitivity: 社内
owner: 自分
updated: 2026-09-21
review: 2026-12
---
品名：梱包用の箱（Sサイズ）
在庫数：320枚（2026-09-20時点）
発注の目安：100枚を切ったら発注
仕入れ先：（人物ファイルのパス）
次にやること：10月分の発注数を決める

3. 機微度を決める。 生徒や顧客を扱う場合は、データ設計票の8項目（特に、取得目的・最小項目・同意）を先に埋めます。未成年が対象なら、保護者の同意も確認します。個人を特定できる情報を、AIに渡す前に匿名化するかも決めます。

4. 3〜5件だけ入れる。 実際のデータを全部入れる必要はありません。AIに聞き取りをさせて、ファイルにしてもらいます。

（AIへの依頼例）
「私が今から、在庫を1品ずつ話すので、上の形式で、inventory/ に
 1品1ファイルで作ってください。項目が足りなければ、聞き返してください。」

5. 運用してみる。 作ったデータベースに、次のような質問をします。

• 「inventory/ を読んで、在庫が発注の目安を切っているものを出して」
• 「更新が3か月以上前のファイルを出して」（updated があるから聞ける）
• 「来月の発注の候補を、理由つきで提案して。決めるのは私」

6. 更新のルールを1行で決める。 「誰が・いつ・何をきっかけに更新するか」を決めます（例：入荷したら、その日のうちに自分がAIに伝える）。更新の責任者が決まっていないデータベースは、数週間で使われなくなります。

共有（数名）： 「何を対象にしたか」「機微度をどう決めたか」「運用して、AIに何が聞けるようになったか」を、順に話します。

第2回のミニワーク：ダッシュボードを、スマホから見られるようにする

お題：第1回のデータベース（またはOntologyの中の分散したデータ）から、1枚のダッシュボードを作り、スマホで開けるところまで進める。（目安40〜60分）

1. 何を見たいかを1文で決める。 未来の計画より、過去の動きが記録として溜まっているものを選ぶと、すぐに形になります（例：「毎日の授業が予定どおり行われたか」「各案件が、いまどこまで進んだか」「今週の予約と、製造の予定」）。

2. AIエージェントの中で作らせる。 細かい指定はせず、まず頼みます。

（AIへの依頼例）
「projects/（または inventory/、customers/）の中身を読んで、
 いま進行中のものと、止まっているものが一目で分かる、1ページのダッシュボードを作って。」

3. 2〜3回、使いながら直す。 画面の写し（スクリーンショット）をAIに渡して、「最初の画面に、〇〇が入っていない」「この欄は見ない」と直させます。直すのは、画面ではなく、指示と元データです。

4. 見られる範囲を決める。 ダッシュボードの章の3種類の表で、中身の機微度から決めます。限定情報を含むなら、自分のパソコンの中に留めるか、ログインの保護をかけてからWebに置きます。

5. Webに置く場合は、保護→公開→確認の順で。 Cloudflare Pagesに置くなら、先にCloudflare Accessで自分のGoogleアカウントだけを許可し、公開後に、ログインしていないブラウザ（シークレットウィンドウ）で開いて、中身が見えないことを確かめます。 スマホから開けたら完了です。

共有（数名）： 「何を見たかったか」「最初に出てきた画面と、直したあとの画面の違い」「見られる範囲をどう決めたか」を、画面を見せながら話します。

第3回のミニワーク：会社の操縦席（ダッシュボード）をつくる

お題：会社の情報を一覧でき、AI・業務委託・パートナーそれぞれの仕事ぶりを見られる、自分専用のダッシュボードをつくる。（目安40〜60分）

第1回で作ったデータベースと、Part 2〜9で育てた台帳・報告・外注の記録を、1枚の画面にまとめます。完成形の型は事業ダッシュボード・テンプレートにあります（架空のひとり会社「ひなた工房」の見本の画面つき）。見本をなぞるのではなく、自分の会社の問いから作ります。

1. 画面で答えたい問いを、3つ決める。 項目を並べる前に決めます。例：

• 「どの事業が、いま動いていて、どれが止まっているか」
• 「誰（AI・業務委託）から、最後にいつ報告が来たか」
• 「お客さんは、増えているか、減っているか」（アクセス・申込・問い合わせ・クリック）

2. 元データ（正本）を置く。 画面に載せる情報は、すべて元のファイルから読みます。画面の数字を、手で書き写しません。フォルダの形は、テンプレートのフォルダの形をそのまま使えます。

3. 「動く数字」を、事業ごとに2〜4個選ぶ。 外から入ってきて、毎週変わる数字です（アクセス数、申込数、広告クリック、注文数、登録者数など）。「商品が何種類あるか」「設定が済んでいるか」のような仕様は、動かないので載せません。数字の見せ方（折れ線・前週比など）は、テンプレートのチャートの形を参照します。

4. 報告の置き場と、更新のルールを決める。 報告が届いたら、reports/ に1ファイル足します。週次の報告なら、目安は7日です。

5. AIに作らせる。 見本を読ませて、自分用に直させます。

（AIへの依頼例）

「この見本（build_dashboard.py と sample/）を読んで、私の会社用のダッシュボードを作って。
 ・元データは myproject/ の members・businesses・reports・metrics・tasks にある。足りない項目は聞き返して
 ・最初の画面に、各事業の状態・動く数字・最終更新・報告の経過日数を全部出す。並びは更新が新しい順だけ
 ・AIエージェントの直近の作業は、省略せずに出す
 ・載せるのは、ボールが私にある行だけ。相手の宿題や、人の点数・順位は作らない
 ・読めない数字は『未取得』、記録がなければ『記録なし』と出す。推測で埋めない
 ・出力は、読み取り専用のHTML 1枚。スマホ幅でも崩さない」

6. 見て、直す。 最初の画面だけで、手順1の3つの問いに答えられるかを確かめます。答えられなければ、元データか指示を直して、作り直します。画面を手で直しません。

7. 外から見られる場所に置くなら、保護が先。 第2回のミニワークの手順5と同じです。顔写真や実名を載せるときは、本人の了承を取ります。

8. 設計の決まりで確かめる。 実際に使いながら固まった16個の決まりが、事業ダッシュボード・テンプレートの設計の決まりにあります。特に次の5つは、最初から守ります。

• ファーストビューに、各事業の状態・動く数字・最終更新を全部載せる
• 台帳に載せるのは、ボールが自分にある行だけ。人の点数や順位は作らない
• 数字には出典と日付をつける。読めなければ「未取得」。推測で埋めない
• 画面は読み取り専用の生成物にする。直すときは元データを直して作り直す
• お金と給与の数字は写さず、finance/ を参照する

共有（数名）： 「最初の問い3つは何か」「動く数字に何を選んだか」「作ってみて、見えなかったものと、見えて驚いたものは何か」を、順に話します。

参考にする一次情報

• 厚生労働省「労働基準法における労働者性判断に係る参考資料集」（令和6年10月時点）：https://www.mhlw.go.jp/content/001462701.pdf
• 公正取引委員会 フリーランス法特設サイト：https://www.jftc.go.jp/freelancelaw_2025/
• 公正取引委員会・中小企業庁「フリーランス・事業者間取引適正化等法 説明資料」：https://www.chusho.meti.go.jp/keiei/torihiki/download/freelance/law_02.pdf
• 公正取引委員会 フリーランス法 Q&A：https://www.jftc.go.jp/fllaw_limited/fllaw_qa.html

制度や基準は変わります。実際に契約・運用に使う前に、最新の内容と、顧問の専門家の確認を通してください。

関連スキル

• 前提となる → S5：お金のデータを構築する（雇用の判断基準は、Wealth Ladderのはじめの2段階と連動する）
• 前提となる → S1：自分の情報体系を構築する（people/ フォルダ・ontology/ の使い分けはここで作る）
• 型を見る → 事業ダッシュボード・テンプレート（第3回のミニワークの見本）
• ルールの続き → AI利用ガバナンス設計キット（AIに渡してよい情報の線引き）
• 次に学ぶ → S7：AIを中心としたチームを作る（小さなプロジェクトを組み合わせて、組織にする）