第4章: AI社員の育成マニュアルを書く

AI社員に「これは覚えておいてね」と伝えたルールが、翌日には完全に忘れられていました。

CC Company（シーシーカンパニー）のマーケティング部に「記事はですます調で統一して」と教えたときのことです。その日は完璧に守ってくれました。翌日、新しいセッションを開いて別の記事を頼んだら、「だ/である調」で書かれた原稿が上がってきました。「昨日も言ったけど、ですます調でお願い」ともう一度伝えました。

翌日。また「である調」です。3日連続で同じ指摘をしました。

人間の部下なら、一度教えれば翌日も覚えています。メモを取るかもしれないし、忘れても「昨日言われたような気がする」くらいの記憶は残ります。しかしAI社員は、セッションが変わるたびに記憶がリセットされます。第3章で紹介したContext Rot（コンテキストロット：文脈の腐食）です。昨日の会話は、今日のAI社員にとって「存在しなかった会話」なのです。

ここから得た教訓が、この章のテーマです。AI社員に仕事を教えるとき、口頭で伝えるのではなく、文書にして渡す。この文書を、本書では育成マニュアルと呼びます。

あなたの現在地を確認する

• AI社員に渡す「仕事の定義書」を文書化している
• その文書に「やってはいけないこと」（禁止事項）が明記されている
• 文書が長くなりすぎていないか、定期的に見直している

3つともチェックが付いた方: 育成マニュアルの基盤はできています。「マニュアルが長すぎると守られない」のセクションで、さらに精度を上げる方法を確認してください。

1〜2個の方: マニュアルはあるが、まだ抜けがある状態です。この章で「何を書くべきか」と「書きすぎた場合の対処」の両方を学べます。

チェックがゼロの方: AI社員に口頭で教えている、または何も渡さずに使っている状態です。この章が最も効く章になります。文書を1枚書くだけで、AI社員の仕事の質が目に見えて変わります。

「覚えておいて」が通じない相手に、どう教えるか

人間の部下であれば、「次からこうしてね」と口頭で伝えれば、たいてい覚えてくれます。忘れたとしても、「あ、それ前に言われたかも」と思い出すきっかけがあります。

AI社員には、それがありません。

セッションが変わるたびに記憶が消えるので、昨日の指示も、先週のフィードバックも、すべてゼロに戻ります。だからこそ、大事なことは「口で教える」のではなく「文書として渡す」必要があります。

育成マニュアルは、いわば新入社員に渡す「入社マニュアル」のようなものです。毎朝、記憶をなくした新入社員が出社してくると思ってください。その社員が読むだけで「自分は何をする人で、何に気をつけて、何をやってはいけないか」が分かる。そんな文書を用意するのです。

CC Companyでは、各部署のフォルダに配置された設定ファイル（CLAUDE.md）がこの役割を果たしています。AI社員はセッション開始時にこのファイルを自動的に読み込み、「自分が何をする社員なのか」を理解してから仕事を始めます。

マニュアルに何を書けばいいのか

CC Companyも、最初からうまく書けたわけではありません。マニュアルの中身は、失敗を重ねるたびに項目が増えていきました。

川島さん（第2章で紹介した、中小企業の営業兼事務の方です）が初めてAI社員にメール対応を任せようとしたときの話をしましょう。

川島さんは「講演依頼メールに丁寧に返信して」とだけ書いたマニュアルを渡しました。AI社員は指示通り、丁寧に返信を書いてくれました。ただし、全てのメールが「お世話になっております。貴社ますますご清栄のこととお慶び申し上げます」で始まる、まるでお役所のような硬い文面でした。

川島さんは笑いながら、マニュアルにこう追記しました。「返信は『ご連絡ありがとうございます』から始める。堅すぎず、かといって馴れ馴れしくない文体で」。これが判断基準です。仕事の中で判断が必要な場面で、何を基準にするかを書いたもの。

ところが次の問題が起きました。講演の費用について問い合わせが来たとき、AI社員がその場で具体的な金額を返信してしまったのです。本来なら、ベース金額だけ伝えて「詳細は電話で」と返すべきところを、見積もりまで出してしまいました。

これは「やってはいけないこと」を書いていなかったから起きた問題です。川島さんは「費用の詳細は人間が電話で対応する。AI社員はベース金額のみ記載し、調整可能である旨を添える」とマニュアルに追記しました。これが禁止事項です。

さらに、ある日AI社員が依頼主の会社名を間違えたまま返信を下書きしました。誰にも確認されることなく「できました」と報告してきたのです。川島さんは「返信を送る前に、依頼主の会社名・担当者名・日程を原文と照合すること」と追記しました。これが合格基準です。何をもって仕事完了とするかの条件を定めたもの。

2週間で禁止事項が8つ増え、気づけば立派なマニュアルができていました。最初の「丁寧に返信して」の一文から、4つの要素が自然に揃っていったのです。

整理すると、育成マニュアルに必要なのは以下の4つです。

最初から4つを完璧に書く必要はありません。川島さんのように、失敗するたびに追記していけば、2週間で十分なマニュアルが育ちます。大事なのは、「この4つが揃っているか？」を時々チェックすることです。

「いい感じに」が通じない相手への伝え方

マニュアルを書くうえで、多くの人がつまずくポイントがあります。曖昧さです。

人間同士なら「いい感じに」で通じます。「読みやすい記事を書いて」と頼めば、文脈を汲み取ってそれなりのものを出してくれます。しかしAI社員にとって「いい感じ」は、解釈の余地が無限にある指示です。あなたが想像する「いい感じ」と、AI社員が解釈する「いい感じ」が一致する保証はどこにもありません。

CC Companyのマーケティング部で、実際に起きた出来事です。「読みやすい記事を書いて」と指示したら、AI社員は箇条書きだらけの、まるでスライド資料のような記事を作ってきました。AI社員にとっての「読みやすい」は「情報が整理されている」だったのです。こちらが期待していたのは「文章として読み進められる」でした。

この問題を解決するために、マニュアルにはこう書きました。

ですます調で統一する。1文は50字以内を目安にする。専門用語を使うときは必ず説明を添える。具体例を先に出してから原則を説明する。

ここまで具体的に書けば、AI社員は迷いません。

特に重要なのが禁止事項です。AI社員は「やってください」という指示には比較的素直に従いますが、自発的に「これはやめておこう」と判断する力が弱い。第3章で紹介した「人に合わせすぎる」弱点のためです。だからこそ、「やってはいけないこと」は明示的に書かなければなりません。

CC Companyのマーケティング部の育成マニュアルには、たとえば以下のような禁止事項が書かれています。

• ですます調で統一する（だ/である調の混在はNG）
• 全角ダッシュ「——」や長音記号の連続「ーー」で文をつなげる表現を使わない（AI臭の象徴。絶対禁止）
• 専門用語を説明なしで使わない（初出時に必ず括弧書きで平易な説明を添える）
• 「できていなかった」「やっていなかった」等の過度な弱さの開示をしない
• AIっぽい表現の乱用をしない

これらは全部、実際にAI社員がやらかしたから追記されたルールです。ある日、HTMLで書いた書籍の全章を検索したところ、禁止したはずの全角ダッシュが5箇所も残っていたことがありました。マニュアルに書いてあっても、長い作業の中で忘れてしまうのです。この経験から、「禁止事項は書くだけでなく、機械的にチェックする仕組みも必要」という教訓を得ました。

禁止事項は、失敗の記録そのものです。最初から完璧なリストを作る必要はありません。「違う、こういうのはやめてくれ」と思ったら、その場でマニュアルに1行追記する。それを繰り返すだけで、禁止事項は自然に充実していきます。

「覚えておいて」ではなく「ここに書いてある」にする

AI社員と仕事をしていると、会話の中で「あ、次からこうしてね」「これは覚えておいて」と伝えたくなる場面が頻繁にあります。そして、次のセッションで同じミスが出る。「昨日も言ったのに」と思うわけです。

これ、心当たりがありませんか。部下に口頭で指示を出して、翌日「聞いてません」と言われる、あの感覚です。人間の部下なら「ちゃんとメモしてよ」と言えます。AI社員の場合は、あなたがメモ（マニュアル）を書く番です。

CC Companyでは、「同じ指摘を2回させたら、1回目の指摘でマニュアルに書き込むべきだった」というルールを掲げています。

ただし正直に言えば、このルールを完璧に守れているわけではありません。指摘した内容をマニュアルに書き込むのを忘れて、結局また同じミスが出る。それは今でも起きます。大事なのは、同じミスが2回目に起きたとき、「なぜマニュアルへの反映が漏れたのか」「どうすれば漏れなくなるか」をAI社員と一緒に考えて、仕組みを試してみることです。

たとえば、セッション終了時に「今日の指摘をマニュアルに反映したか」を確認するステップを追加しました。それでも漏れることはありますが、そのたびに仕組みを改善し続けています。この「改善し続ける」プロセス自体が、第6章で詳しく解説する品質サイクルの原型です。

マニュアルが長すぎると、書いてあっても守られない

「大事なことはマニュアルに書く」。この原則を忠実に守った結果、別の問題が起きました。

CC Companyの秘書室のマニュアルは、運用を続けるうちに509行まで膨れ上がりました。「こういうミスがあったから、このルールを追加しよう」「この手順も書いておこう」「このチェックリストも入れておこう」と、大事なことを書き足していった結果です。

すると、何が起きたか。

509行のマニュアルを持つ秘書AI社員が、品質ゲート（成果物の提出前チェック）を3回連続で飛ばしました。マニュアルの200行目あたりに「品質ゲートは必ず通すこと」と明記してあるにもかかわらず、です。

原因は、第3章で紹介したLost in the Middle（ロストインザミドル：長い文書の中間部分を読み落とす現象）です。509行もの文書の200行目あたりに書かれたルールは、AI社員の注意が最も届きにくい位置にあるのです。書いてあるのに「見えていない」。マニュアルの中身は消えていないのに、実質的に無視されている状態でした。

大事なことを書けば書くほど、マニュアルが長くなる。長くなるほど、中間の情報が埋もれる。書いたのに守られない。これは本末転倒です。

川島さんにも同じことが起きました。メール対応のマニュアルに返信ルール、禁止事項、テンプレート、例外パターンを書き足していくうちに、マニュアルが100行を超えました。すると、AI社員が序盤に書かれた「返信前に会社名を照合する」ルールを飛ばすようになったのです。50行だったころは守れていたルールが、100行になったら守れなくなる。書き足すたびに、既存のルールの遵守率が下がっていく。この矛盾に、川島さんも頭を抱えました。

解決策: 「何を守るか」と「どうやるか」を分ける

この問題の解決策は、意外とシンプルでした。1枚のマニュアルに詰め込んでいた情報を、2種類のファイルに分けたのです。

会社に例えると分かりやすいかもしれません。どんな会社にも「就業規則」と「業務マニュアル」がありますよね。就業規則は「守るべき原則」を短く書いたもの。業務マニュアルは「具体的な作業手順」を詳しく書いたもの。この2つを1枚の紙に詰め込む会社はありません。それぞれ別の文書として管理します。

AI社員でも同じことをしました。CC Companyでは、実際に以下の2種類のファイルで管理しています。

CLAUDE.md（就業規則に相当）: 常に守るべきルールだけを書く。短くする。AI社員はセッション開始時に必ずこのファイルを読み込みます。

• 「合格基準なしに成果物を出すな」
• 「ファイルを削除するな」
• 「品質ゲートを通してから提出しろ」

SKILL.md（業務マニュアルに相当）: 具体的な作業手順を書く。こちらは長くてよい。AI社員は具体的な作業が必要になったときだけ、該当するSKILL.mdを読みに行きます。

• 記事の書き方 → note-article/SKILL.md
• 投稿の管理 → content-publish-tracker/SKILL.md
• 品質チェック → quality-gate/SKILL.md

常に読み込まれるCLAUDE.mdは短く保ち、長い手順はSKILL.mdに分離する。こうすることで、重要なルールがLost in the Middleで埋もれるリスクが大幅に減ります。

実は、この「ルールと手順の分離」は、CC Companyが独自に考えたものではありません。Claude Code（クロードコード）には「スキルクリエイター」というAnthropic（アンソロピック）の公式ツール（Anthropicとは、Claude Codeを開発している会社です）があり、最初から「マニュアル」と「手順書」を別々のファイルとして管理する設計になっています。つまり、この分離はツールの基本設計として組み込まれているのです。

CC Companyでは、509行のマニュアルをこの設計に沿って整理し直しました。結果、秘書のマニュアルは509行から180行に縮小しました。手順書に移した329行分の情報は消えたわけではなく、必要なときに呼び出せる手順書として独立したファイルに整理されています。

効果は数字に表れました。509行時代、品質ゲートの通過率（提出前チェックが正しく実行された割合）は約7割でした。3回に1回はチェックが飛ばされていた計算です。180行に縮小した後、通過率は95%以上に改善しました。マニュアルの行数を6割以上削減しただけで、ルールの遵守率がここまで変わったのです。

川島さんのメール対応マニュアルも同様でした。「常に守るルール」（返信の文体、禁止事項、照合チェック）と「手順の詳細」（テンプレート、例外パターン、過去のやり取り例）を分けたところ、ルールの遵守率が明らかに上がりました。

AI社員同士の引き継ぎ

もう一つ、組織で避けて通れない問題があります。AI社員がAI社員に仕事を頼むときです。

CC Companyでは、秘書のAI社員が他の専門AI社員に作業を依頼する場面がよくあります。「この記事の品質チェックをお願い」「このテーマを調べておいて」と。

ここで問題が起きます。頼まれた側のAI社員は、秘書のマニュアルを読んでいないのです。自分の部署のマニュアルしか読みません。

つまり、秘書が知っている「合格基準なしに成果物を出すな」「レビューログは必ず残せ」というルールが、頼まれた側には伝わっていないのです。秘書にとっては当たり前のルールでも、頼まれた側にとっては「聞いていない」ルールです。

これは人間の組織でも起きる問題です。自社の就業規則を、外注先の業者は知りません。だから、発注書に「うちの最低限のルールはこれです」と添付しますよね。

CC Companyでも同じ発想で解決しました。delegation-preamble.md（委譲プリアンブル）という、全社共通ルール7項目をまとめた1枚のファイルを用意したのです。中身は「品質サイクルを守れ」「レビューログを残せ」「ファイルを削除するな」といった、どの部署でも絶対に守ってほしいルールです。

仕組みはこうです。秘書のAI社員が別のAI社員に仕事を頼むとき、指示文を書きますよね。その指示文の一番先頭に、この7項目を毎回コピーして貼り付けます。頼まれた側のAI社員は、指示文を上から順番に読むので、最初に目に入るのが全社共通ルールになります。相手がルールを「知っている」かどうかに頼るのではなく、毎回の指示の先頭にルールを直接埋め込むことで、伝達漏れを構造的に防いでいるのです。

なぜ先頭なのか。第3章で紹介したLost in the Middleを思い出してください。AI社員は文書の先頭と末尾に注意が集中します。だから大事なルールは先頭に置く。「マニュアルに書いたから大丈夫」ではなく、「指示の先頭に埋め込んで、読まないわけにいかない状態にする」。これが、AI社員を組織的に運用するときに必要な考え方です。

マニュアルの書き方は規模で変わる

個人の場合

自分専用のAI指示書を1枚作ることから始めてください。「私の仕事の概要」「AIにやってほしいこと」「絶対にやってはいけないこと」の3項目があれば十分です。これだけで、AIとのやり取りの質が目に見えて変わります。

チームの場合

共有の指示書テンプレートを作成し、各メンバーがそれをカスタマイズする運用が効果的です。テンプレートには「チーム共通の用語集」「品質基準」「禁止事項」を記載し、個人のカスタマイズ部分には「自分の担当領域」「個人の文体の好み」などを追記します。

組織の場合

CC Companyがまさにこのモデルです。全社共通のルール（組織の就業規則）をルートに配置し、各部署にはそれぞれ固有の育成マニュアルを置く。共通ルールと固有ルールを分離することで、全社的な一貫性を保ちながら、部署ごとの専門性にも対応できます。

そのまま使えるテンプレート集

自社で育成マニュアルを書き始めるときに、ゼロから設計する必要はありません。本書の付録C「育成マニュアルテンプレート集」に、15部署分のひな形（秘書室・CEO・プロジェクト管理・マーケティング・営業・開発・クリエイティブ・経理・法務・人事・情報システム・リサーチ・ナレッジ・コンサルティング・レビュー）を用意しています。「役割・判断基準・禁止事項・合格基準」の4要素が各部署に揃っており、そのままコピーして自社の情報に書き換えるだけで出発点になります。Phase 1の3部署（秘書室・CEO・プロジェクト管理）から始める導入ロードマップも付録Cに含めています。

コラム: 活動ログが3日連続で消えた日

CC Companyの初期、秘書AI社員に活動ログの記録を任せようとしたときの話です。

秘書との会話の中で「作業が終わったら、必ず活動ログに記録してね」と伝えました。秘書は「分かりました」と返答し、そのセッションではきちんと記録してくれました。

翌日、新しいセッションを開始して仕事を頼みました。作業が終わった後、活動ログを確認すると、記録されていませんでした。「昨日も言ったけど、活動ログは必ず記録してね」ともう一度伝えました。

その次のセッション。やはり記録されていませんでした。

解決策は3段階でした。

まず、秘書の育成マニュアルに「活動ログの記録は全セッションで必須」と明記しました。これで、セッションが変わっても秘書はマニュアルを読み込む時点で「活動ログを記録しなければならない」と認識するようになりました。

しかし、それでも完璧ではありませんでした。会話が長くなったり、複雑な作業に集中したりすると、マニュアルに書いてあっても記録を忘れることがありました。

そこで、もう一段階の対策を講じました。セッション終了時に「おつかれ」と声をかけると、/review-sessionという専用スキル（決まった手順を自動実行する仕組み）が自動的に起動し、活動ログの記録、コンテンツの種（記事ネタのメモ）の抽出、Google Tasks（グーグルタスクス）の更新、コミット（変更の保存）までを一括で実行する仕組みにしたのです。

マニュアルによるルールの明示と、終了時スキルによる一括処理。この組み合わせによって、活動ログの記録漏れは大幅に減りました。ただし正直なところ、「おつかれ」と言い忘れてセッションを閉じてしまうことは今でもたまにあります。完璧ではありませんが、仕組みがなかった頃に比べれば記録の精度は格段に上がっています。

「伝えた」は「できる」ではない。仕組みで強制するまで安心してはいけない。

LLM（Large Language Model：大規模言語モデル）知識: なぜマニュアルの「長さ」が問題になるのか

本文で触れたContext RotとLost in the Middleについて、技術的な補足をしておきます。

Context Rotは、AIの内部で処理できる情報量（コンテキストウィンドウ）に上限があることに起因します。会話が長くなるにつれて古い情報が「押し出され」、AIの注意が新しい情報に偏っていきます。ただし、これは物理的に消えるのではなく、注意の配分が薄まるという現象です。だからこそ、重要なルールを「毎回読み込まれるファイル」に書くことで、常にAI社員の注意の先頭に配置できるのです。

Lost in the Middleについては第3章で紹介したとおり、リュウ（Liu）ら（2023）の研究で、中間部分に置かれた情報は最大で20%程度精度が低下する場合があると報告されています。CC Companyで509行マニュアルの200行目付近のルールが無視されたのは、この研究知見と一致する現象でした。

さらに興味深いのは、プロンプト（AIへの指示文）が長くなるほど、指示への遵守率が低下するという傾向です。Anthropic社のドキュメントでも、システムプロンプト（AIの基本設定）は簡潔に保つことが推奨されています。CC Companyが秘書のマニュアルを509行から180行に縮小して遵守率が改善したのは、この原則に沿った結果でもあります。マニュアルは「全部書く」のではなく「常に参照すべきことだけ書く」のが正解です。

マニュアルを書いて渡しました。AI社員は仕事を始めてくれます。しかし、出てきた成果物が「合格」かどうか、何をもって判断しますか。次の章では、この「合格基準」の設計について解説します。