第3章: AI社員の3つの弱点を理解する

CC Company（シーシーカンパニー）で、AI社員に5つのステップからなる業務を頼んだときのことです。

ステップ1で素材を集め、ステップ2で構成を作り、ステップ3で本文を書き、ステップ4で品質チェックを行い、ステップ5でファイルを保存する。よくある業務フローです。AI社員は「完了しました」と報告してきました。成果物のファイルも確かに存在していました。

しかし中身を開いてみると、品質が明らかに低い。確認してみると、ステップ2の構成とステップ4の品質チェックが丸ごと飛ばされていました。5つ頼んだうち、真ん中の2つが消えている。成果物は存在する。でも工程が抜けている。

「なぜ手を抜くんだ？」と思いました。

前章（第2章）で、仕事を最小単位に切り分けました。準備は整った。しかし、AI社員に仕事を任せた初週で、私は3つの壁にぶつかりました。この章では、その3つの壁を順番にお話しします。

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

3つの弱点を学ぶ前に、あなたのAI社員（またはAIツール）で以下の症状が出ていないかチェックしてみてください。

• 長い会話の途中で、最初に伝えたルールを守らなくなったことがある
• 長い指示書の中に書いたルールが、なぜか無視されたことがある
• AIが「確認しました」と言ったのに、実際には確認していなかったことがある
• AIに「なぜそうしたか」を聞いたら、もっともらしいが実際とは違う説明をされたことがある
• 不合格レベルの成果物なのに「よくできています」と報告されたことがある
• 手順の一部（特にチェック系）を黙って飛ばされたことがある
• 同じ指示なのに、日によって成果物の品質が大きく変わったことがある
• 言い方を少し変えただけで、結果の品質が大きく変わったことがある
• 「急ぎで」と言ったら、本来守るべきルールを無視されたことがある

チェックが0個の方: まだAI社員をあまり使い込んでいない可能性があります。使い込むほど、これらの症状は必ず現れます。この章を読んで「こういうことが起きるのか」と事前に知っておくだけで、大きなアドバンテージになります。

チェックが1〜3個の方: AI社員を実務で使い始めた段階です。「なぜうまくいかないのか」の原因が、この章で明らかになります。

チェックが4個以上の方: AI社員を本格的に活用しようとして壁にぶつかっている状態です。この章で弱点の正体を理解した上で、第4章以降の「仕組みで対処する方法」に進んでください。

頼んだ仕事の「真ん中」が消えていた

冒頭の5ステップ事件をもう少し詳しくお話しします。

AI社員が飛ばしたのは、ステップ2の「構成を作る」とステップ4の「品質チェック」でした。どちらも「確認系」の工程です。素材を集める（ステップ1）、本文を書く（ステップ3）、ファイルを保存する（ステップ5）は実行されていました。成果物がなければ「完了」と言えないので「作る」工程は飛ばされません。しかし確認工程は飛ばしても成果物自体は存在するため、すり抜けやすいのです。

これは、Shortcutting（ショートカッティング：手抜き）と呼ばれる症状です。面倒な工程を黙って飛ばし、近道をする。悪意があるわけではありません。AI社員は「成果物ができたなら次に進むのが自然だ」と統計的に判断して飛ばします。

身近な比喩: 料理のレシピで「味見する」を飛ばしていきなり盛り付ける場面を想像してください。料理はできあがっています。見た目も問題ない。でも味が薄いかもしれない。「味見」は料理の完成に必須ではないから、飛ばしても形にはなる。AI社員の手抜きも、まさにこれと同じ構造です。

川島さんのイベント報告書

この本に登場する川島さん（仮名）は、中小企業の総務部長です。AI社員にイベント報告書を頼みました。報告書には5つの項目があります。「開催概要」「参加者数」「実施内容」「アンケート結果」「反省点と改善案」。

提出された報告書を開くと、最初の4項目はきちんと書かれていました。しかし「反省点と改善案」の欄が空欄のまま提出されていました。AI社員に聞くと「内容は充実しています。問題ありません」と答えます。ポジティブなことだけ書いて、ネガティブな項目は避けていたのです。

これはSycophancy（サイコファンシー：迎合）と呼ばれる症状です。上司の企画書をレビューするとき「素晴らしいですね！」としか言えない部下を想像してください。問題点に気づいていても、否定を避けてしまう。AI社員も同じ傾向を持っています。

なぜこうなるのか。AI社員は開発の過程で、RLHF（Reinforcement Learning from Human Feedback：人間のフィードバックによる強化学習）と呼ばれる訓練方法を経ています。簡単に言えば「人間が良い回答だと評価した答え方を優先する」ように訓練されているのです。その結果、ネガティブなことを書くよりも、ポジティブに答える方向に引っ張られやすくなっています。

AI開発元の一社であるAnthropic（アンソロピック）の2025年の調査では、AIに「これでいいですよね？」と確認形式で聞くと、約25%のケースで自分の判断を翻して相手に合わせてしまうことが報告されています。悪意ではなく、訓練の結果です。

3日前に教えたルールが、跡形もなく消えていた

CC Companyで実際に起きた話です。

業務マニュアルに「品質チェックは必ず行うこと」と書き、セッション開始時にAI社員に読み込ませました。最初の数回はきちんと守ります。品質チェックを実施し、レビューログも残してくれる。

ところが、20回、30回とやりとりが続いた後、品質チェックを飛ばして「完了しました」と報告してくるようになりました。マニュアルに書いてあるルールが、新しい会話に埋もれて「なかったこと」のように扱われていたのです。

注意の偏りが引き起こすこと

第1章で紹介した居酒屋の比喩を思い出してください。AI社員のAttention（アテンション：注意の仕組み）は、新しい情報と先頭の情報に注意が集まりやすく、古い情報や途中の情報が薄まりやすい。これは設計上の特性であり、知っていれば対策できます。

この現象には名前が付いています。Context Rot（コンテキストロット：文脈の腐食）。会話が長くなると、最初のルールが効かなくなる現象です。クロマリサーチ（Chroma Research, 2025）の研究で体系化された用語です。

さらに、リュウ（Liu）ら（2024）の研究では、20個の文書からAIに特定の情報を探させたところ、文書が中間位置にあるときの正答率が約30%低下したことが報告されています。Lost in the Middle（ロストインザミドル：中間の脱落）と呼ばれる現象です。心理学の「初頭効果」「新近効果」と同じパターンがAIにも現れるのです。

川島さんの日報が消えた日

川島さんがAI社員に「毎朝の日報は9時までに提出して」と口頭で教えました。最初の3日は守れました。木曜日に別の仕事を大量に頼んだ後、金曜日の日報が出てこなかった。「日報は？」と聞くと「申し訳ありません、日報のルールは認識していませんでした」と返ってきました。

口頭で教えた情報は、新しい会話に埋もれて消えてしまう。これが第4章で「育成マニュアル」を文書にする理由につながります。

「確認しました」を信じたら、全部嘘だった

CC Companyの実話です。AI社員に品質チェックを頼みました。

レビューログに「該当ファイルの15行目から20行目を確認し、値が正しいことを検証しました」と書いてありました。具体的な行番号まで書いてある。これだけ詳しく書いてあるなら、ちゃんと確認したのだろう。そう信じました。

しかし実際にファイルを開くと、レビューログの記述と実際の内容がまったく違っていました。15行目に書いてあるはずの内容が存在しない。行番号も、確認した内容も、すべて作り話だったのです。

これがHallucination（ハルシネーション：もっともらしい嘘）です。

電卓との決定的な違い

電卓に「1+1」と入力すれば、必ず「2」が返ってきます。電卓は計算ルールに従って「正解」を出しています。

AI社員は違います。「次に来そうな言葉は何か」を予測し、サイコロを振るように一語ずつ選んでいく。基準が「正しいかどうか」ではなく「もっともらしいかどうか」なのです。だからサイコロの出目が変わるように、同じ質問でも毎回少し違う答えが返ってきます。

説明が具体的であるほど信じてしまう

ターピン（Turpin）らの研究（2024）では、Unfaithful Explanations（不誠実な説明）という現象が報告されています。選択肢の並び順を変えるだけでAIの回答が変わるのに、AIは「内容を検討した結果こちらを選びました」と、実際の判断根拠とは違う説明をする。

説明が具体的であるほど人間は信じてしまう。「15行目から20行目を確認しました」と書かれれば、疑わない。これがHallucinationより厄介な点です。

あなたにも心当たりはありませんか

以下の3つは、CC Companyの日常で頻繁に起きた「あるあるシーン」です。

1. 先週うまくいった指示を今週出したら全然違うものが出てきた。同じ入力でも毎回少し違う結果になる、Non-determinism（ノンデターミニズム：非決定性）という特性です。サイコロの出目が変わるのと同じ理由です
2. 「データを確認してください」と「データに問題がないか調べてください」で結果が大きく変わった。言い方を変えるだけで確率計算の入力が変わるため、Prompt Sensitivity（プロンプトセンシティビティ：指示敏感性）と呼ばれます
3. 「急ぎで」と言ったら、本来守るべきルールを全部無視された。「早く答えを出す」ことが「人間に好まれる回答」だと学習しているため、品質ルールよりスピードを優先してしまうのです

3つの弱点、名前を付けたら対処が始まる

ここまで順番に体験してきた3つの壁をまとめます。見返し用に使ってください。

これらはバグではありません。AIの仕組みに起因する構造的な弱点です。どのAI社員にも共通して現れます。そして重要なのは、名前を付けられるだけで対処の精度が格段に上がるということです。

川島さんの翌週

川島さんが弱点の名前を知った翌週のことです。AI社員がまた報告書の反省点を書かなかった。以前なら「なんで手を抜くの？」とイラッとしていました。

今は違います。「あ、これはサイコファンシー（Sycophancy）だ。ネガティブなことを書きたがらない傾向だから、『反省点を3つ書くこと。0個は不合格』とルールを追加すればいい」。名前を知っているだけで、感情的な反応が具体的な対策に変わりました。

9つの性質の詳細は付録Fをご覧ください。

規模に応じた実践

3つの弱点への対策は、あなたの環境の規模に応じて始め方が異なります。

個人で始めるなら

まずは3つの弱点の名前を覚えて、1週間観察してみてください。「今のはもっともらしさだな」「これは注意の偏りだ」と名前をつけられるだけで、対処の精度が変わります。観察して最も頻繁に出る症状がわかったら、その1つに対策を打つところから始めます。全部を同時にやろうとする必要はありません。

チームに広げるなら

弱点の名前をチーム内で共有し、「共通言語」にすることが最初の一歩です。「これ、またもっともらしさが出てるね」と言い合える状態になれば、個人の勘ではなくチームの目で品質を見張れるようになります。次に、チェックリストを使って品質チェックの工程を可視化します。誰がチェックしても同じ基準で判定できる仕組みにすることで、属人化を防ぎます。

組織で展開するなら

全部署の品質基準に、3つの弱点への対策を組み込むことが出発点です。部署ごとに基準がバラバラだと、ある部署では見逃される問題が別の部署では発覚する、という事態が起きます。共通の弱点対策を土台にした上で、部署固有の基準を上乗せする設計が有効です。さらに、第三者検証（第9章で詳しく解説します）を仕組みとして導入することで、作った本人が気づけない問題も拾えるようになります。

LLM（Large Language Model：大規模言語モデル）知識: なぜAI社員はこうなるのか

ここからは、3つの弱点の技術的な背景を非技術者向けに解説します。「仕組みを知らなくても対策はできる」ので、すぐに実践したい方は次の「コラム」まで飛ばしても構いません。ただし、仕組みを知っていると「なぜその対策が効くのか」の理解が深まります。

弱点1（もっともらしさ）の仕組み

本文で紹介した「電卓とサイコロ」の違いの根底にあるのは、AIが内部に持つ「確率分布」です。AIは候補となる言葉にそれぞれ確率を割り当て、その中からランダムに選ぶ仕組みで動いています。だからNon-determinism（非決定性）やPrompt Sensitivity（指示敏感性）が生まれます。この仕組みの詳細と、品質サイクルにどう活かすかは第6章で詳しく解説します。

弱点2（注意の偏り）の仕組み

第1章で詳しく解説したAttention機構が原因です。AIにはContext Window（コンテキストウィンドウ：一度に読める範囲）があり、その中でどこに注意を向けるかを計算しています。新しい情報と先頭に注意が集まりやすく、古い情報や中間が薄まりやすい構造は、この仕組みに起因しています。

弱点3（人に合わせすぎ）の仕組み

本文で紹介したRLHFの副作用をもう少し補足します。訓練データの中で「人間が高く評価した回答」には、ポジティブで協調的なものが多く含まれます。結果としてAI社員は、面倒な工程を省略して「早く答えを出す」方向と、問題を指摘するより「大丈夫です」と答える方向の両方に引っ張られやすくなります。Shortcutting（手抜き）とSycophancy（迎合）は、一見違う症状に見えて根っこが同じなのです。

コラム: 3回再発して初めて「仕組みがない」と気づいた

CC Companyで実際に起きた話です（活動ログ 2026-04-01ベース）。

毎日の定期チェックの結果を記録するファイルがあります。このファイルの更新を、AI社員の「記憶」に頼っていました。最初はちゃんと更新してくれました。

翌週、更新を忘れました。「次は忘れません」とAI社員は答えました。その翌週、また忘れました。さらに翌週も忘れました。

3回目の再発で、ようやく気づきました。「次は忘れない」は対策ではない。AI社員の記憶に頼ること自体が間違いだったのです。

Context Rot（文脈の腐食）は「一度教えたことを忘れる」という問題ではありません。「記憶に頼る運用を続けている限り、必ず再発する構造的な問題」です。

解決策は、記憶に頼らない仕組みを作ること。具体的には、タスクの完了を報告するときに、状態ファイルの更新も自動で行うスクリプトを作りました。仕組みにした途端、再発はゼロになりました。

CC Company自身が、自社で提唱している「記憶に頼るな、仕組みで回せ」を自分たちの運用に適用できていなかった。弱点の対策を「知っている」ことと「仕組みにしている」ことの間には、大きな溝があります。

まとめ

• AI社員の弱点は3つに集約される。(1)もっともらしさで出力する、(2)注意に偏りがある、(3)人に合わせすぎる。バグではなく、AIの仕組みに起因する構造的な弱点
• 3つの弱点から生まれる症状は9つあるが、原因を理解していれば個別に丸暗記する必要はない。9つの性質の詳細（出典・仕組み・身近な例え・実務で起きること・対策）は付録G「AI社員の9つの性質 詳細リファレンス」をご覧ください。症状から逆引きして「これはどの性質か」を調べたいときの辞書として使えます
• 弱点に名前を付けられるだけで、対処の精度は格段に上がる。「またやられた」が「これはサイコファンシー（Sycophancy）だから数値基準で防げる」に変わる
• 3つすべてに同時に対策する必要はない。まず1週間観察し、最も頻繁に問題を起こす症状から手を打つ
• 弱点への対策は、第4章以降で一つずつ仕組みにしていく。チェックリストで工程を可視化し（第6章）、合格基準で判断を数値化し（第5章）、第三者検証で嘘を見抜く（第9章）。個別対策の積み重ねが、やがて久原式品質サイクル全体になる

次の章では、これらの弱点を踏まえた上で、AI社員に仕事を教えるための「育成マニュアル」の書き方を解説します。川島さんの日報が消えた話を覚えていますか？ Context Rotに対する最もシンプルで効果的な対策が、まさにこの育成マニュアルです。