AI社員の育て方
AI社員の育て方 / 第8章: 業務手順書を作る

第8章: 業務手順書を作る（スキル化と再現性）

月曜日に書かせた記事は92点。水曜日にほぼ同じテーマで書かせた記事は55点。同じAI社員に、同じような指示を出したはずなのに、品質がまるで違う。「なぜ？」と指示の履歴を見比べたとき、原因に気づきました。月曜日は「読者が行動したくなる記事を」、水曜日は「分かりやすい記事を」。私は同じつもりで話していたのに、AI社員には全く別の指示として届いていたのです。

この章は、その「ばらつき」を仕組みで消した話です。料理に例えるなら、毎回その場で味付けを考えるのをやめて、レシピを書いた。ただそれだけのことで、品質が安定しました。

先に混同しやすい2つの用語を整理しておきます。第4章で書いた育成マニュアルは、AI社員の「就業規則」です。部署のルール、判断基準、禁止事項を定めた行動規範で、常に読み込まれています。一方、この章で扱う業務手順書（スキル）は、特定の業務を実行するための「作業マニュアル」です。「この手順で、この順番で、この基準でやれ」と具体的な作業工程を定義します。育成マニュアルが「どんな社員か」を決め、業務手順書が「どう仕事するか」を決める。この2つは別物です。

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

3つともチェックが付いた方: 手順書の仕組みが稼働しています。第9章で「成果物の検証」に進みましょう。

1〜2個の方: 繰り返し業務はあるが、手順書が未整備か、整備しても品質がばらつく状態です。この章で「再現性のある手順書」の書き方を学びましょう。

チェックがゼロの方: AI社員への指示を毎回その場で考えている状態です。品質のばらつきの原因はここにあります。この章が解決策を示します。

月曜と水曜で品質が変わる問題

ここまでの章で、AI社員を育てる基本の型は一通り揃いました。ゴールを決め、仕事を分解し、マニュアルを書き、合格基準を設定し、品質サイクルを回し、専門家を分けて配置する。ところが、ここで想定外の壁にぶつかりました。

同じ業務なのに、日によって品質が大きく振れる。

CC Company（シーシーカンパニー）のnote記事作成がまさにそうでした。ある日は一発で合格ラインを超える記事が出てくる。別の日は3回修正しても合格に届かない。同じAI社員に、同じような記事を頼んでいるはずなのに。

犯人を探してみたら、AI社員ではなく指示を出していた自分でした。人は無意識のうちに言い回しを変えます。「読者が行動したくなる記事を書いて」と「分かりやすい記事を書いて」。私は同じつもりで話していましたが、第3章で紹介した「Prompt Sensitivity（プロンプトセンシティビティ：指示の言い回しに対する過敏さ）」を思い出してください。AI社員は言葉の違いをそのまま受け取ります。「行動したくなる」と「分かりやすい」では、AI社員が組み立てる文章の構成もトーンも変わってしまうのです。

川島さんにも同じことが起きていました。毎週AI社員に議事録を作らせていたのですが、ある週は「要点をまとめて」、別の週は「決定事項を整理して」と、そのとき頭に浮かんだ言葉で指示していたそうです。結果、ある週の議事録は箇条書きでスッキリ、別の週は長文でダラダラ。「先週と同じ形式で」と言っても、AI社員には「先週の記憶」がありません。Context Rot（コンテキストロット：文脈の腐食。第3章参照）で、先週のセッションの記憶は消えているからです。

この問題の根本原因は、指示を毎回その場で考えていることにあります。解決策はシンプルです。指示を毎回考えるのをやめて、一度書いた手順書を毎回読み込ませる。料理のレシピと同じ発想です。プロの料理人は毎回味見をしながら調整しますが、チェーン店では誰が作っても同じ味になるようにレシピを書いています。AI社員に求めているのは後者です。

3行のメモから始まった手順書

CC Companyの記事作成の手順書も、最初はこんなメモでした。

テーマを決めて、書いて、チェックする。

この3行で始めて、実際に使いながら問題が出るたびに項目を足していきました。最初から完璧な手順書を設計しようとしたわけではありません。「ここで毎回つまずく」という場所を見つけるたびに、一行ずつ育てていった結果、今の形になっています。

どんなつまずきがあったか、実際の経緯を追ってみましょう。

つまずき1: テーマだけ伝えて書かせたら、ぼやけた記事が出てきた

最初の頃は「今日のテーマはAI導入の失敗パターンについて」とだけ伝えて記事を書かせていました。出てきた記事は、AIの教科書のような一般論の羅列でした。私の実体験がどこにも入っていない。

原因は明白でした。「何について書くか」だけ伝えて、「誰に向けて」「何をもとに」「何のために」を伝えていなかったのです。

そこで、手順書の冒頭に前提条件を追加しました。この手順書を実行する前に、以下の4つが揃っているか確認するステップです。

この4つが揃ってから書き始めるようにしただけで、一般論の記事は出なくなりました。レシピに例えるなら、「カレーを作れ」だけでは材料も人数も分からない。「4人分、牛すじカレー、圧力鍋を使って」と前提条件を書けば、料理人は迷いなく動けます。AI社員も同じです。

つまずき2: 前提条件を揃えても、工程の順番でつまずいた

前提条件を整えたことで記事の方向性は定まりました。しかし、次の問題が出ました。AI社員がいきなり本文を書き始めて、構成を考えていないのです。結果、途中で論理が迷子になる記事が量産されました。

「構成を先に作ってから本文を書いて」と口頭で伝えれば、そのセッションでは守ってくれます。しかし翌日のセッションでは、またいきなり本文から書き始める。Context Rotです。

だから手順書にステップを明記しました。「上から順番に、1つずつ実行する」形式です。

ステップ1: 目的確認（この記事はゴールに合っているか？）
ステップ2: ネタの事前評価（書く価値があるかを点数で判断する）
ステップ3: テーマ確定・構成案の作成（見出しと流れを設計し、私の承認を得る）
ステップ4: 下書き執筆
ステップ5: レビュー（私が目を通す）
ステップ6: 品質チェック（100点満点で評価し、80点未満なら修正して再評価）
ステップ7: SNS投稿文・サムネイル画像の作成

ステップ3の「私の承認を得る」とステップ5の「私が目を通す」に注目してください。全工程をAI社員に丸投げするのではなく、要所で人が確認する設計にしています。構成を確認してから本文に進む。下書きを確認してから品質チェックに進む。これだけで、手戻りの量が激減しました。

つまずき3: ステップの途中で品質が落ちたのに気づけなかった

ステップの順番を決めたことで、構成を飛ばす問題は解消しました。ところが新しい問題が出ました。最終的な品質チェックで不合格になったとき、「どのステップで品質が落ちたのか」が分からないのです。

記事全体が70点だったとして、構成が悪いのか、本文の書き方が悪いのか、それとも目的設定がずれていたのか。最後にまとめてチェックするだけでは、原因の特定に時間がかかります。

そこで、各ステップに個別の合格基準を設けました。たとえば構成案のステップなら「見出し構造が完成していること」「私が確認して承認していること」。この基準を満たしていなければ次のステップに進めません。

さらに、手順書全体の最終的な合格基準も定義しました。CC Companyのnote記事であれば、「100点満点評価で80点以上」「ゴール照合3項目すべて合格」「全レビューログが保存されている」。個々のステップをすべて通過しても、最終基準を満たしていなければ完成とは認めません。

こうして、3行のメモは「前提条件」「ステップ」「各ステップの合格基準」「最終合格基準」を備えた手順書に育ちました。使いながら問題が出るたびに一行ずつ足していった結果です。最初から全部を設計したわけではありません。

運用を続けていくと、さらに「あった方がいい」と感じる要素が出てきます。「どのファイルを参照すべきか」の一覧や、「成果物をどこに保存するか」の定義、「通常と違うケースの対応」など。これらも、必要になったタイミングで足していけば十分です。

手順書を4回作り直した話: 講演スライドの失敗

記事作成の手順書は、つまずくたびに一行ずつ育てることでうまくいきました。しかし、もっと劇的な失敗と再建を経験したのが講演スライドの手順書です。この話を通じて、「手順書は失敗の記録である」という原則をお伝えします。

最初に作った手順書は、「テーマを受け取る→構成を考える→各スライドの内容を書く→デザインを指示する→品質チェックする」という5ステップでした。理屈としては正しい。しかし、実行するたびに問題が見つかりました。

1回目: デザインがひどい

AI社員にスライドのデザインをゼロから作らせたところ、出てきたのは文字と四角形だけの素朴なスライドでした。ビジネスの場で見せられるレベルではありません。中学生の発表資料と言われても反論できない出来です。

気づき: AI社員にデザインのセンスを期待してはいけない。 修正として、プロが作ったテンプレートを用意して、AI社員にはテンプレートへの文字の流し込みだけを任せる設計に変更しました。手順書に「デザインはテンプレートを使用すること。ゼロからデザインしないこと」という前提条件を追加。

2回目: 色がプロジェクターで見えない

テンプレートを使って見た目は改善しました。ところが出来上がったスライドを開いてみると、配色に問題がありました。濃い青の背景の上に赤い文字。画面上ではコントラストがあるように見えましたが、プロジェクターで投影したら色が潰れて読めない配色です。薄い色の装飾も、投影すれば消えてしまうレベル。講演本番で使う前に気づけたのは幸運でした。

気づき: 画面で見えるものが、会場で見えるとは限らない。 「濃い色の背景の上に別の濃い色の文字を載せない」「背景の装飾には一定以上の濃さの色しか使わない」という配色ルールを、手順書の合格基準に追加しました。

3回目: テンプレートが足りない

配色は改善しましたが、今度はスライドの構図が単調になりました。「2つの案を比較したい」「3つのポイントを見せたい」という場面で、ぴったりはまるテンプレートがない。無理に既存のテンプレートに押し込むと、不自然な見た目になります。

気づき: テンプレートは最初に全部作るのではなく、足りないものを都度追加する「成長方式」が現実的。 最初は7種類だったテンプレートが、今では20種類になっています。比較用、チェックリスト用、画像フル表示用など、必要になるたびに追加していきました。

4回目: 発想を変えた

ここまで手順書を細かく修正してきましたが、改善には限界を感じていました。どれだけ丁寧に指示を書いても、自分の頭の中にある「こういう感じ」がAI社員に伝わりきらないのです。

そこで発想を逆にしました。実際に講演で使った過去のスライド資料を「お手本」としてAI社員に渡し、「この資料を再現するには、どんな設計ルールが必要か」を逆算させたのです。

すると、自分では言葉にできていなかったルールが次々と出てきました。テンプレートの体系、配色の基準、1スライドあたりの文字数。お手本を1つ渡しただけで、「感覚」でしかなかったものが具体的なルールになりました。

この逆算で得たルールをもとに手順書を作り直した結果、ようやく「自分の講演スライドだ」と感じられるものが出てくるようになりました。旧スキルは役目を終えて引退しています。

この4回の経験で確信したことがあります。手順書は失敗の記録です。 「ここでこう失敗したから、このチェックを入れた」。すべてのステップに理由があり、その理由のほとんどは過去の失敗です。だから最初から完璧な手順書を作ろうとする必要はありません。使って、失敗して、書き足す。そのサイクルの中で手順書は育っていきます。

そして、手順書を磨くだけでは限界がある場合は、「お手本を渡して逆算させる」 という別のアプローチも有効です。完璧な指示書をゼロから書くのは難しくても、正解のお手本が1つあれば、AI社員がそこからルールを抽出してくれます。

川島さんの最初の手順書

川島さんも、問い合わせメール対応のAI社員に手順書を作ることにしました。最初はこう書いたそうです。

お客様からのメールを読んで、丁寧に返信する。

これで1週間運用したところ、3つの問題が出ました。

1つ目。質問に直接答えていない返信がありました。お客様が「納期はいつですか？」と聞いているのに、「お問い合わせありがとうございます。弊社では品質管理を徹底しており…」と、関係のない話から始まる返信が出てきたのです。

2つ目。お客様の立場に合わない文体でした。長年取引のある担当者に「初めまして」で始まるメールを送りそうになりました。

3つ目。返信の最後に「次にどうすればいいか」が書かれていませんでした。お客様は返信を読んだあと、電話すればいいのか、別の人に連絡すればいいのか分からない。

川島さんはこの3つの失敗をそのまま手順書に書き足しました。

ステップ1: お客様のメールを読み、質問内容を箇条書きで整理する
ステップ2: 各質問に対する回答を書く。回答がすぐに出せない場合は「確認して○日までにご連絡します」と書く
ステップ3: お客様の名前と過去のやり取りを確認し、文体を合わせる（初めての方には丁寧に、長いお付き合いの方にはやや砕けた口調で）
ステップ4: 返信の最後に「次のアクション」を明記する（例: 「ご不明点があればお電話ください」「○日までにお見積もりをお送りします」）
ステップ5: 送信前に、質問への直接回答があるか、次のアクションが書かれているかを確認する

2週間後には、ステップ5のチェック項目が8つに増えていました。そのすべてが、実際に起きた失敗から追加されたものです。手順書は「こう書くべき」という理想から作るものではなく、「こう失敗した」という現実から育てるもの。川島さんの手順書も、CC Companyの手順書も、成り立ちはまったく同じです。

手順書の効果を数字で見る

CC Companyのnote記事作成を例に取ります。手順書がなかった時期、記事の品質スコアは平均65点でした。手順書を導入した後、平均82点に上がりました。

しかし、数字で見るべきは「平均」よりも「最低点」の方です。手順書がなかった頃は、調子の良い日に85点が出ることもあれば、悪い日は40点台になることもありました。手順書を入れた後は、最低でも70点を下回らなくなりました。つまり「調子が悪い日でも一定の品質は出る」状態になったのです。品質の天井を上げることも大事ですが、品質の底を上げることこそが、手順書の最大の効果です。

川島さんのメール対応でも同じことが起きました。手順書なしの頃は「完璧な返信」と「質問に答えていない返信」が混在していましたが、手順書を入れた後は「最悪でも及第点」の状態が安定しました。

ただし、手順書があれば人が完全にいなくてよいわけではありません。CC Companyの記事作成でも、「構成案の承認」と「下書きのレビュー」は私が確認する工程として残しています。手順書で自分の拘束時間は大幅に減りましたが、品質に対する最終判断は人が握ったままです。手順書は「人を不要にする仕組み」ではなく、「人の関わり方を変える仕組み」です。

規模に応じた手順書の使い方

個人の場合

自分用のチェックリストを作るところから始めます。本格的な手順書でなくて構いません。「記事を書くときにやること」を5〜10項目でリストアップするだけでも、品質の安定感が大きく変わります。

個人で手順書を作る最大のメリットは、「毎回ゼロから考える」コストが消えることです。記事を書くたびに「何から始めよう」と悩んでいた時間が、手順書があれば「ステップ1から始めよう」に変わります。

チームの場合

業務の標準手順書を整備します。チーム内の業務のうち、繰り返し発生するものを手順書化し、全員がアクセスできる場所に保管します。

チームで手順書を運用する際のポイントは、手順書のバージョン管理です。誰がいつ何を変更したかを追跡できるようにしておく。CC CompanyではGit（ギット。ファイルの変更履歴をすべて記録して管理するツール。いつ何を変更したかを遡って確認できます）を使ってすべてのファイルをバージョン管理しています。

組織の場合

全業務をスキル化して再現性を担保します。CC Companyでは、主要な業務のほとんどが業務手順書として登録されています。AI社員は手順書を読み込むだけで即座に業務を開始できます。

組織レベルでは、スキルのライブラリ化が重要です。各部署が作った手順書を一箇所に集約し、他部署でも参照・再利用できるようにする。「営業部の提案書作成スキル」をベースに「マーケティング部の企画書作成スキル」を作る。こうした横展開が、組織全体の品質を底上げします。

手順書が増えると「提出前のチェック」のように全業務に共通する工程が出てきます。これを個別の手順書に何度も書くのは非効率です。CC Companyでは、品質チェックや完了報告といった共通工程を1つの基盤としてまとめ、各手順書はその基盤の上で動く設計にしました。会社でいえば品質管理部門のような存在です。この設計は第10章で詳しく解説します。

手順書を自分でゼロから書くのは大変です。実は、手順書の作成自体を手伝ってくれるツール（スキルクリエイター）があります。「どんなステップが必要か」「合格基準は何か」を対話しながら整理し、手順書の形にまとめてくれます。なお、第7章でも述べた通り、手順書の長さは500行以内に収めます。長すぎる手順書は途中のステップが飛ばされるリスクが高まります。

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

すぐに手を動かしたい方のために、付録E「業務手順書テンプレート集」によく使う3業務分のひな形（コンテンツ作成／SNS投稿／調査レポート）を用意しています。本章で紹介した4要素（前提条件・ステップ・各ステップの合格基準・最終合格基準）がすべて揃った形で、そのままコピーして自社の業務名・条件に書き換えられます。また、「3行のメモから育てる」考え方や、手順書を育てるサイクルの進め方も付録Eにまとめています。

コラム: 宅配便と完了報告

手順書を設計するときに忘れがちなのが、「成果物を作り終えた後」の工程です。

CC Companyで、AI社員が「記事完成しました」と報告してきたので確認しようとしたら、品質チェックのログファイルがどこにもない、ということがありました。「チェックしました」と言うだけで、記録を残していなかったのです。第5章で触れた「Hallucination（ハルシネーション：もっともらしい嘘）」を思い出してください。AI社員は本当にチェックしていなくても「完了しました」と言えてしまいます。

この経験から、手順書の最終ステップには「完了報告」の工程を必ず含めるようにしました。具体的には3つです。まず、各ステップの品質チェック記録がすべて揃っているか確認する。次に、管理者に「終わりました」と報告する。最後に、管理者が成果物を確認して「確かに受け取りました」と記録する。

宅配便と同じです。届いた荷物を開けて中身を確認して、はじめて「届いた」になる。AI社員が「終わりました」と言っただけでは、仕事が終わったことにはなりません。

LLM（Large Language Model：大規模言語モデル）知識: なぜ「1つずつ消化させる」方式がAIに効くのか

第3章で、AIは長い文章の中間部分への注意が薄まること（「Lost in the Middle」（長い文書の中間が見落とされる現象））を学びました。手順書が効く理由は、この特性の裏返しです。ポイントは自由形式の指示とチェックリスト形式の指示の違いにあります。

自由形式の指示:

「DX（Digital Transformation：デジタル技術を使って仕事や会社の仕組みを変えること）について、中小企業の経営者向けに、分かりやすく、具体例を交えて、30スライド程度の講演資料を作成してください。」

この指示には「DXについて」「中小企業の経営者向け」「分かりやすく」「具体例を交えて」「30スライド程度」という5つの要求が1つの文に詰め込まれています。人間でも「あれもこれも同時にやって」と言われると、どれも中途半端になりがちです。AIも同じで、結果としてどの要求にも十分に応えられない出力になりやすいのです。

チェックリスト形式の指示:

ステップ1: テーマの確認。「DXとは何か」を中小企業の経営者が理解できる言葉で定義する。
ステップ2: 聴講者の課題を3つリストアップする。
ステップ3: 各課題に対する解決策を、具体例付きで記述する。
...

この形式では、AI社員はステップ1の時点では「テーマの確認」だけに集中できます。ステップ2では「課題のリストアップ」だけに集中できます。1つずつ順番にこなすので、各ステップでAIの注意が分散せず、それぞれの出力の品質が上がります。

これが「チェックリスト駆動」の根拠です。「全部一度にお願い」ではなく「1つずつ順番にお願い」する方が、AIは良い仕事をする。シンプルですが、効果は絶大です。

さらに、チェックリスト形式には進捗の可視化という副次的な効果もあります。10ステップのうち何番目まで完了したかが明確なので、途中でセッションが切れても「ステップ6から再開」と指示するだけで続きが実行できます。自由形式では「どこまでやったか」の判断すら曖昧になります。

CC Companyの全手順書がチェックリスト形式で書かれているのは、AIのこの特性を最大限に活用するためです。「1つずつ消化させる」。この単純な方式が、AIの仕組みに最も合った指示の出し方なのです。

手順書ができて、品質が安定するようになりました。ところがある日、AI社員が「品質チェック合格しました」と報告してきたので、念のためレビューログを確認しようとしたら、ファイルがどこにもありませんでした。