第13章: AI社員を定期的に健康診断する

仕組みを作った。チェックも作った。なのに3回連続で同じ問題が起きた

CC Company（シーシーカンパニー）の定期業務チェックが、3回連続で「超過」を報告してきました。

メールの自動チェック、タスクの整合性確認、成長戦略のレビュー。いずれも「毎日」または「毎週」実行すべき定期業務です。チェック用のスクリプトは作ってあります。期限を超えたら「超過」と表示される仕組みも動いています。

問題は「超過を表示する仕組み」にはなっていたが、「完了を記録する仕組み」がなかったことです。

定期業務を実行した後、その完了状態を記録するステップが抜けていました。チェックスクリプトは状態ファイルを「読む」だけ。「書く」仕組みがどこにもなかった。だから、業務を終えても状態は「未完了」のまま。次の日にスクリプトが走ると、また「超過」と表示される。

1回目は「更新を忘れただけ」と思いました。手動で状態ファイルを直しました。2回目も同じことが起きて、「次は気をつけよう」と思いました。3回目。さすがに気づきました。これは忘れっぽさの問題ではなく、仕組みの欠陥だ。

AI社員の記憶力に依存していたのです。第3章で学んだ「Context Rot（コンテキストロット：文脈の腐食）」（AIが長い会話の途中で前の指示を忘れてしまう現象）がここでも起きていました。「業務が終わったら状態を更新してね」という暗黙の期待は、AIには通用しない。

3回目の再発で、専用のスクリプトを作りました。業務名を渡すだけで、正しい状態ファイルに完了を書き込む仕組みです。作った翌日から、超過表示は出なくなりました。

この経験から、1つの教訓を得ました。

仕組みは作った瞬間から劣化が始まる。作ったことに安心して放置すると、静かに壊れていく。

この章は、その「静かな劣化」を早期に発見し、仕組みを健全に保ち続けるための方法をお伝えします。

あなたのAI社員は「作りっぱなし」になっていませんか？

以下の問いに答えてみてください。

• AI社員の業務手順書を作った後、定期的に見直している
• AI社員の出力品質が以前と変わっていないか、確認する仕組みがある
• 「このスキルはもう不要かもしれない」と判断する基準がある
• AI社員の仕組み全体を定期的に棚卸しする習慣がある
• 品質の劣化に「気づいてから対処する」のではなく、「自動で検知する」設計になっている

全部チェックが付いた方: すばらしい。AI社員の長期運用に必要な「メンテナンスの仕組み」がすでに構築されています。この章の「メタ品質管理」の視点で、自社の仕組みをさらに磨いてみてください。

1〜3個の方: AI社員は動いているが、「作って終わり」の部分が残っています。この章で定期健康診断の仕組みを手に入れましょう。

チェックがゼロの方: まだ第1〜12章の段階にいるかもしれません。まずはそちらを実践してから、この章に戻ってきてください。ただし「作った後に劣化する」という事実だけは、今のうちに知っておいてください。

「何も変えていないのに、品質が下がった」

冒頭の定期チェック事件は、仕組みの欠陥が原因でした。しかし、もっと厄介な劣化があります。こちらは何も変えていないのに、AI社員の出力品質が変わってしまうパターンです。

川島さん（第1章から登場している、従業員30名のIT企業で事務を担当する42歳の方です）も、同じ経験をしました。3か月前に作った議事録作成のスキルが、最近どうもおかしい。以前は参加者名に「様」を付けて出力していたのに、最近は敬称なしで出てくる。業務手順書は一文字も変えていません。

原因はAIモデルの更新でした。AIサービスは数週間から数か月おきにモデルを更新しています。多くの場合は性能が向上しますが、特定のタスクで出力の傾向が変わることがあります。2023年にStanford（スタンフォード）大学とUC Berkeley（ユーシーバークレー）の研究チームが、OpenAI（オープンエーアイ）のGPT-4（ジーピーティーフォー）の挙動が数か月で変化したという分析を報告しています（Chen et al., 2023 "How is ChatGPT's behavior changing over time?"）。外から見て「同じモデルなのに出力が変わった」と感じる現象は、研究でも確認されているのです。

厄介なのは、この変化が静かに進行すること。ある日突然ゼロ点になるのではなく、90点が87点になり、85点になり、じわじわと下がっていく。人間には気づきにくい。川島さんも「なんとなく最近変だな」と感じてはいたものの、明確に問題だと認識したのは2か月後でした。

モデルの更新だけではありません。あなたの会社の業務も変わっていきます。新しいサービスが始まる。組織体制が変わる。取引先のルールが変わる。しかし、AI社員の業務手順書は書いたときのまま。人間の社員なら「あ、前と変わったんだな」と気づいて対応できますが、AI社員は手順書に書いてある通りにしか動きません。

さらに、もう1つ。仕組みの肥大化です。品質を上げようとしてスキルの記述にルールや条件をどんどん追加する。「ですます調で統一」「専門用語には補足を」「体験談を冒頭に」「権威性用語を自然に織り込む」。1つ1つは正しい改善でも、積み重なるとAI社員が優先順位をつけられなくなる。良くしようとした結果、逆に品質が下がる。これも立派な劣化です。

CC Companyでこの肥大化が起きたとき、ある記事スキルの出力品質が下がっていることに気づきました。いつも通りの指示を出したのに、文章の切れ味が鈍い。品質チェックに通すとギリギリ合格ラインは超えているものの、以前より明らかにスコアが落ちている。「先週うまくいった指示を今週出したら、微妙に違うものが出てきた」。こういう経験、ありませんか？

整理すると、仕組みが劣化する原因は3つです。

共通しているのは、「自分では何も悪いことをしていない」という点です。だからこそ気づきにくく、だからこそ仕組みで検知する必要があるのです。

30個のスキルを「健康診断」してみた

CC Companyで記事スキルの品質低下に気づいたとき、ふと思いました。「他のスキルは大丈夫なのか？」

その時点で、CC Companyには30以上の業務手順書（スキル）がありました。記事を書くスキル、SNS投稿を作るスキル、提案書を作るスキル、講演スライドを作るスキル。作ったときはそれぞれ品質チェックを通していますが、その後は使いっぱなしです。

スキルを作った後、一度も見直していなかった。

そこで、全スキルの棚卸しをやりました。1つずつ中身を確認し、3つに分類しました。

• Keep（維持）: 24個。現時点で問題なく動いている
• Improve（改善必要）: 5個。記述が古い、または肥大化している
• Retire（廃止）: 1個。もう使っていない、または不要になった

30個のうち6個、つまり2割に何らかの問題があったのです。そして、棚卸しをするまでそのことに気づいていませんでした。

この棚卸しの中で、もう1つ重要なことが見えてきました。スキルには2つの種類があるということです。

廃止した1個は「日本語の文末表現を自然にする」ための補正スキルでした。作った当時はAIの日本語力が低く、必要だったのですが、モデルが進化してそのスキルなしでも自然な日本語が出るようになっていた。つまり、AIが苦手な分野を補うためのスキルは、モデルの進化で不要になることがある。これを「能力引き上げ型スキル」と呼ぶことにしました。

一方、Keepの24個の大半は「記事を書くときは体験談から入る」「提案書は課題提起→解決策→見積の順番で書く」といった、御社独自の仕事の進め方を定義したものでした。AIが賢くなっても「あなたのやり方」は変わらない。だからこのタイプのスキルは長持ちする。これを「プロセス組み込み型スキル」と呼んでいます。

30以上のスキルを運用してきた経験から言えるのは、実際に運用しているスキルの大半はプロセス組み込み型だということです。つまり、定期健康診断の重点は「まだ動くか」よりも「現実の業務と合っているか」に置くべきです。

「きれいにしたけど、品質は上がったのか？」

棚卸しをして、5個のスキルを改善し、1個を廃止しました。すっきりしました。

しかし、ある日こう思いました。「きれいにしたけど、品質は上がったのか？」

業務手順書の重複を削除する。古くなったルールを更新する。フォーマットを統一する。年末の大掃除と同じで、やれば確実にすっきりします。パソコンで言えば、Defrag（デフラグ：ディスクの中身を並べ替えて動作を速くする処理）のようなものです。

でも、整理しただけでは品質は測れません。記事を書くスキルの手順書を「整理」した結果、以前は95点だった出力が90点に下がっていたとしても、整理作業だけではそれに気づけない。

そこで必要になるのが「定期テスト」です。スキルに決まった入力を与えて、出力の品質を数字で測る。

健康診断に例えるなら、こういうことです。体重を測るだけでは内臓の状態は分かりません。血液検査をして数値で見て初めて、コレステロール値が高いとか、血糖値が上がっているとか分かる。「大掃除」は体重計に乗ること。「定期テスト」は血液検査です。

両方やるのが正解です。ただし、どちらか片方しかできないなら定期テストを優先してください。散らかっていても品質が出ていれば仕事は回りますが、きれいに整理されていても品質が落ちていたら意味がありません。

8つのコアスキルに「定期テスト」を入れた

「品質が怪しいと感じたらテストを実行する」。最初はそう考えました。しかし、冒頭の定期チェック事件を思い出してください。「気づいたらやる」は、3回忘れる。

90点が87点にじわじわ下がる変化に、人間は気づけません。だから、人間の判断を介在させずに自動的に定期実行する必要がある。

CC Companyでは、30以上あるスキルの中から特に重要な8つを「コアスキル」と定め、テストケースを作りました。テストケースとは、「このスキルにこの入力を与えたら、こういう条件を満たす出力が出るはずだ」という期待値の定義です。

ソフトウェア開発の世界には「Test-Driven Development（テスト駆動開発）」という考え方があります。プログラムを書いたら、そのプログラムが正しく動くかどうかを確認するテストも一緒に書く。この考え方を、AI社員の業務手順書に応用したのです。

8つのコアスキルに対して、合計101個のチェック項目を定義しました。「記事は体験談から始まっているか」「提案書に課題提起が含まれているか」「SNS投稿が文字数制限内か」。それぞれのスキルが自分の合格基準を持っているので、その基準をそのままテストにしました。

初回のテスト結果は、8スキル全て100%パス。101個のチェック項目が全て合格。これが「今の時点での品質」のベースラインです。

川島さんも、まずは自分が最もよく使う議事録スキルで同じことをやってみました。「参加者名に敬称が付いているか」「決定事項が箇条書きになっているか」「次回アクションが明記されているか」。3つのチェック項目を定義して、月に1回テストを実行する。先月と同じ入力で試したら、今月はフォーマットが微妙に崩れていた。数字で見て初めて変化に気づいたのです。

ポイントは、「ですます調で書かれているか」「体験談が含まれているか」といった個別のチェックは、スキルの中に組み込まれた品質チェッカーが毎回やっていることだ、ということです。定期テストの目的はそこではない。「先月と同じスキルで、同じ水準の品質が出ているか」をスコアで比較すること。これが定期テストの本質です。

ただし、「定期テスト」と言うのは簡単ですが、実際にやろうとすると壁があります。テストを作るには、まず「何をもって合格とするか」の評価軸を業務ごとに定義する必要があります。記事の品質テストと提案書の品質テストでは、評価軸がまったく異なります。テストの設計には、自社の業務を深く理解している人間の判断が不可欠です。CC Companyの評価軸がそのまま御社で使えるとは限りません。

ベンチマーク: 「前回と比べてどうか」を数字で見る

テストを定期的に実行すると、その結果を時系列で比較できるようになります。これがベンチマーク（成績表）です。

CC Companyの初回テストは「8スキル101項目、全て100%パス」でした。これがベースラインです。次回のテストで、たとえば記事スキルが95%に下がったら、何かが変わったということ。原因がモデル更新なのか、スキルの肥大化なのか、業務環境の変化なのかは、数値を見てから切り分ければよい。まずは「変化が起きた」と気づくことが最優先です。

ベンチマークがあれば、以下の判断ができます。

• 安定している: スコアが変動なし。今の手順書で問題ない
• 下降している: スコアが低下傾向。手順書の見直しか、AIモデルの変更への対応が必要
• 向上している: スコアが上昇傾向。AIモデルの進化で品質が上がった。能力引き上げ型スキルなら、不要化の検討対象

ベンチマークなしにスキルを管理するのは、健康診断を受けずに「たぶん健康だろう」と思っているようなものです。数値で見れば、どこに問題があるか一目で分かります。

メタ品質管理: 仕組み自体の品質を管理する

ここで一歩引いて考えてみましょう。

• 第5章〜第6章: 成果物の品質管理（合格基準→チェック→修正→再チェック）
• この章: 品質管理の仕組み自体の品質管理

「品質管理をする仕組みが、ちゃんと動いているかを確認する仕組み」。一見ややこしいですが、考え方は同じです。

第6章で学んだ品質サイクルを思い出してください。

1. 合格基準を定義する
2. 成果物を作る
3. 合格基準に照らしてチェックする
4. 不合格なら修正して再チェック

この品質サイクルを、「スキル（業務手順書）」に対しても適用するだけです。

1. スキルの合格基準を定義する: テストケースを書く
2. スキルを実行する: テストケースの入力で出力を生成
3. 出力を合格基準に照らしてチェックする: 期待する出力と比較
4. 不合格なら修正して再チェック: スキルの記述を見直す

同じパターンが、対象を変えて繰り返されている。これを「Fractal（フラクタル）構造」と呼びます。フラクタルとは、拡大しても縮小しても同じ形が現れる構造のことです。海岸線を遠くから見ても近くで見てもギザギザしているように、品質サイクルという考え方は、成果物にもスキルにも部署全体にも、同じように適用できます。

ISO 9001（アイエスオーきゅうせんいち：品質マネジメントシステムの国際規格）でも、この考え方は「Process Approach（プロセスアプローチ）」として定義されています。個々のプロセスだけでなく、プロセス同士の相互作用や、プロセス自体の改善も品質管理の対象にする。つまり、「仕組みの品質を仕組みで管理する」という発想は、製造業の品質管理で数十年にわたって実証されてきた考え方なのです。AI社員に新しく適用しているように見えますが、根底にある原則は古くから確立されています。

検知は仕組みに、判断は人間に

冒頭の定期チェック3回再発事件を振り返ります。

1回目: 「更新を忘れた。次は気をつけよう」（人間の記憶に依存）

2回目: 「また忘れた。今度こそ」（まだ人間の記憶に依存）

3回目: 「これは仕組みの問題だ」（仕組みで対処することを決意）

「3回同じことが起きたら、それは個人の問題ではなく仕組みの問題」。この教訓は、定期テストの設計思想そのものに通じます。

「品質が怪しいと感じたらテストを実行する」だと、人間の判断が必要です。 忙しくなったら後回しにします。問題がなさそうに見えたらスキップします。そして、実際に問題が起きてから「なぜ気づけなかったのか」と後悔する。

「毎週自動でテストが走り、結果が数値で出る」なら、人間の判断は不要です。 月曜の朝にテスト結果が届き、「先週から記事スキルの品質が5%低下しています」と分かれば、人間は「このスキルの手順書を見直そう」と判断するだけでよい。

「何を・いつ・どのようにチェックするか」をすべて事前に定義しておく。人間は結果を見て「どうするか」だけを判断する。検知は仕組みに、判断は人間に。この分担が、AI社員を長期運用するための設計原則です。

IPA（Information-technology Promotion Agency：情報処理推進機構）が公開している情報セキュリティ対策のガイドラインでも、同じ原則が示されています。定期的な点検と棚卸しを仕組み化し、人間の記憶や注意力に依存しない設計にすること。セキュリティもAI社員の品質管理も、根底にある考え方は同じです。

規模ごとの始め方: 個人・チーム・組織

個人: 川島さんがやったように、まずは自分が最もよく使うスキル（業務手順書）を1つ選び、テストケースを3つ書いてみてください。「このスキルにこの入力を与えたら、こういう出力が出るはずだ」という期待です。月に1回、そのテストを実行して結果をメモするだけで、品質の変化に気づけるようになります。

チーム: チーム全体で使っているスキルの中から、最も重要なもの（売上に直結するもの、顧客対応に使うもの）を「コアスキル」として定義してください。CC Companyでは30以上のスキルから8つを選びました。コアスキルだけでも定期テストを導入すれば、チーム全体の品質安定に大きく効きます。すべてのスキルに一度にテストを作る必要はありません。まずコアスキルから。

組織: 全社展開されているAI活用の仕組みについて、月次または四半期ごとの健康診断サイクルを設けてください。テスト結果をダッシュボード化し、どの部署のどのスキルに問題があるかを一覧で確認できるようにします。問題のあるスキルは担当部署が修正し、修正後にテストを再実行する。品質サイクルを組織全体で回す形です。

コラム: GPTsのメール返信トーンが勝手に変わった日

CC Companyを構築する前の話です。GPTs（ジーピーティーズ：ChatGPT（チャットジーピーティー）で自分専用のAIアシスタントを作れる機能）でメール対応を自動化していた時期がありました。

ある日、1か月ぶりに動かしてみたら、返信のトーンが微妙に変わっていたのです。以前は「ご連絡ありがとうございます」で始めていたのに、「お世話になっております」に戻っている。設定は何も変えていない。

原因を調べると、OpenAIがモデルを更新したタイミングと重なっていました。モデルの性能自体は上がっているのに、自分が意図した出力からはずれてしまう。あのときは原因が分からず困りましたが、今なら分かります。これが「Model Drift（モデルドリフト：AIモデルの出力傾向が時間とともに変化する現象）」です。

この経験があったからこそ、CC Companyでは最初から「たまに動かして確認する」習慣を組み込みました。そして、その「たまに」を人間の記憶に頼らず、定期テストとして仕組み化した。冒頭の3回再発事件で学んだ「人間の記憶に頼るな」と、このGPTs事件で学んだ「何も変えなくても品質は変わる」。この2つの教訓が組み合わさって、今の定期健康診断の仕組みができたのです。

LLM（Large Language Model：大規模言語モデル）知識: モデルドリフト、なぜAIの出力は「勝手に変わる」のか

AI社員の出力品質が静かに変化する現象は、機械学習の分野では「モデルドリフト」と呼ばれています。もともとはAI全般で使われる概念ですが、生成AIでもまったく同じことが起きます。

AIの出力が変わる3つの原因

1つ目はモデル更新。AIサービスは数週間から数か月おきにモデルを更新しています。バージョンが変わるメジャーアップデートは事前にアナウンスされますが、内部的な調整が行われてもユーザーに通知されないことがあります。先ほど紹介したチェンら（Chen et al., 2023）の研究では、GPT-4の数学的推論能力やコード生成能力が数か月で有意に変化したことが報告されています。

2つ目はData Drift（データドリフト：入力データの傾向変化）。AIに渡す入力データの傾向が変わることです。業務手順書にルールを追加し続けると、入力の構造自体が変わります。同じモデルでも、入力が変われば出力も変わる。CC Companyで起きた「スキルの肥大化による品質低下」は、まさにこのパターンです。

3つ目はConcept Drift（コンセプトドリフト：正解の基準変化）。入力と出力の「正解の関係」が変わることです。たとえば、半年前は「ご連絡ありがとうございます」が正解だったメール冒頭が、顧客層の変化で「お世話になっております」の方が適切になる。AIモデルは変わっていないのに、求められる正解の方が動いている。

Non-determinismとの違い

第3章で学んだ「Non-determinism（ノンデターミニズム：非決定性。同じ入力でも毎回違う出力が出る性質）」とモデルドリフトは別の問題です。Non-determinismは「1回の実行の中での揺れ」。品質サイクルの繰り返し（第6章）で吸収できます。モデルドリフトは「時間の経過に伴う変化」。品質サイクルだけでは吸収できず、手順書（スキル）自体を修正しなければならない場合があります。

定期テストが検知するもの

定期テストは、このモデルドリフトを数値で検知するための仕組みです。先月のテスト結果と今月のテスト結果を比較すれば、品質が変化したことが分かる。原因の切り分けはその後でよい。まずは「変化が起きた」と気づくことが最優先です。

重要なのは、この変化に人間が「気づく」必要がないこと。テストが自動で走り、結果が数値で出る。検知を仕組みに任せ、判断を人間が行う。これが本章の設計思想そのものです。

今の手法は「今の最適解」であり、未来では変わる

この章でお伝えした具体的な手法（定期テスト、ベンチマーク、スキルの2分類）は、2026年時点での最適解です。AIモデルがさらに進化すれば、テストの方法も変わるかもしれません。スキルの分類基準も変わるかもしれません。

しかし、「問題を特定し、仕組みで対処し、定期的に検証する」という考え方は変わりません。

具体的な手法は「賞味期限付きの知識」ですが、仕組みで解決するという考え方は「ずっと使える思考法」です。この違いを知っていることが、AI活用を長く続けるための最大の武器になります。

まとめ

• AI社員の仕組みは放っておくと劣化する。モデル更新、業務環境の変化、仕組みの肥大化が原因
• 「3回同じことが起きたら、個人の問題ではなく仕組みの問題」。検知は仕組みに任せる
• スキルには2種類ある。能力引き上げ型（不要になりうる）とプロセス組み込み型（長持ちする）
• 「手順書の大掃除」は体重計、「定期テスト」は血液検査。両方やるが、優先は定期テスト
• ベンチマーク（成績表）で時系列の変化を追い、下降トレンドを早期発見する
• メタ品質管理: 品質サイクルをスキル自体にも適用するフラクタル構造
• 検知は仕組みに、判断は人間に。この分担が長期運用の設計原則
• 具体的な手法は時代で変わるが、「問題を特定し、仕組みで対処し、定期的に検証する」思考法は普遍的

ここまでの第1〜13章で、1人のAI社員の育成から、複数のAI社員による組織の構築・維持まで、一通りの仕組みが完成しました。ここからは、その組織をさらに活かすための応用編に入ります。AI社員同士を連携させ、提案させ、商品を生み出し、あなたの会社に展開する方法です。