付録G: AI社員の9つの性質 詳細リファレンス
本編第3章「AI社員の3つの弱点を理解する」では、AI社員の3つの根本原因を中心に解説しました。この付録では、その3つの根本原因から派生する9つの具体的な性質について、出典・仕組み・身近な例え・実務で起きること・対策の方向性を、リファレンスとしてまとめています。
特定の場面で「これはどの性質が起きているのか」を調べるときに、辞書のように引いてください。各性質の末尾にある対策章のリンクから、本編の詳しい解説に飛べます。
9つの性質 一覧表
9つの性質は、本編第3章で紹介した3つの根本原因から生まれます。以下の表では、原因ごとにグループ化して掲載しています。各カードの性質名をクリックすると、詳細解説に飛べます。
原因1: 「もっともらしさ」で出力する仕組み
- 一言で言うと
- 存在しない情報を自信を持って語る
- 人間に例えると
- 未確認項目に「確認済み」と書く作業員
- 主な対策章
- 第9章
- 一言で言うと
- 行動の説明が実際の判断根拠と一致しない
- 人間に例えると
- 勘で書いた答えに後付けで解法を語る生徒
- 主な対策章
- 第9章
- 一言で言うと
- 言い方を変えるだけで結果の質が大きく変わる
- 人間に例えると
- 「塩少々」と「ひとつまみ」で味が変わるレシピ
- 主な対策章
- 第8章
原因2: 注意の配分に偏りがある仕組み
原因3: 「人間に好まれる回答」を学習した仕組み（RLHF（Reinforcement Learning from Human Feedback：人間のフィードバックによる強化学習）訓練の副作用）
性質1: 文脈の腐食（Context Rot）
会話が長くなると、最初に伝えた指示が効かなくなる。
出典情報
2025年にクロマリサーチ（Chroma Research）が18種類の主要AIモデルを対象に調査し、すべてのモデルで読み込む情報量が増えるほど性能が低下することを示しました。「Context Rot（コンテキストロット：文脈の腐食）」という名前は、このレポートをきっかけに広まった技術用語です。
仕組みの解説
AI社員には「一度に読める範囲」を表すContext Window（コンテキストウィンドウ：一度に読める範囲）があります。2026年現在、最新のモデルでは100万トークンまで読めるものもあります。日本語では1トークンがおよそ1〜2文字に相当するため、50万〜75万字程度。新書に換算すると数冊から十数冊分に相当します。
ところが、「読める」ことと「均等に注意を払える」ことは別の話です。AI社員は文章を読むとき、すべての部分に同じ重みで注意を向けているわけではありません。Attention機構（アテンションきこう：注意の仕組み）で、「今の出力に関連しそうな部分」に注意を集中させ、「関連が薄そうな部分」への注意は弱めています。
会話が短いうちは問題ありません。読む範囲が狭いので、すべての情報にしっかり注意が行き届きます。しかし会話が長くなると、新しいやりとりが次々に追加され、AI社員の注意はどうしても直近の内容に引っ張られます。最初に伝えたルールが文章から消えるわけではありませんが、50回のやりとりの後では、1回目に伝えたルールに割り当てられる注意の量が相対的に小さくなります。
クロマリサーチの実験では、この劣化はタスクの種類によって度合いが異なることも分かっています。単純な検索タスクでは比較的精度が保たれますが、文脈全体の意味を理解する必要があるタスクでは劣化が顕著に現れました。
つまり、Context Rotの正確な意味は「指示を忘れる」ではなく、「指示への注意の配分が薄まり、実質的に無視されやすくなる」ということです。
身近な例え
長いSlackスレッドを想像してください。最初に「今回の方針はこうです」と書いたのに、50件のやりとりが続いた後では、誰もその方針をスクロールして見返しません。方針のメッセージはスレッドに残っていますが、新しいメッセージに埋もれて、実質的に「なかったこと」のように扱われます。AI社員のContext Rotもこれとよく似ています。ただし人間の場合は「スクロールして見返す」ことができますが、AI社員は自分で「あ、最初のルールを見返そう」とは判断しにくい点が異なります。
何が起きるか
業務マニュアルに「品質チェックは必ず行うこと」と書いてあり、AI社員はセッション開始時にそのマニュアルを読み込んでいます。最初の数回のやりとりでは、きちんと品質チェックを行います。しかし、20回、30回とやりとりが続いた後、品質チェックのステップを飛ばして「完了しました」と報告してくることがあります。マニュアルの指示はContext Windowの中にまだ存在していますが、その指示に割り当てられる注意が薄まり、直近の「作業を完了させる」という目的に注意が集中してしまった結果です。
対策の方向性
- 重要ルールを外部ファイル（育成マニュアル）に書き出し、セッション開始時に毎回読み込ませる（第4章）
- 1つの巨大なマニュアルではなく、役割ごとに短い文書に分割する（第7章）
- 長い会話を避け、タスクごとにセッションを分ける
性質2: 中間の脱落（Lost in the Middle）
長い文書の真ん中に書いた内容を読み落とす。
出典情報
2023年にリュウ（Liu）らの研究チームが論文で報告しました。AI分野で広く使われている学術用語です。
仕組みの解説
AI社員に長い文書を渡したとき、文書のどの位置に情報があるかによって、AI社員がその情報を拾える精度が変わるという現象です。
リュウらの実験では、20個の文書を並べて「この中から正解を探して質問に答えて」というタスクをAIに解かせました。正解の文書を先頭に置いた場合、中間に置いた場合、末尾に置いた場合で、正答率がどう変わるかを測定したのです。結果、正解が先頭にあるときに精度が最も高く、中間にあるときに大幅に低下し、末尾にあるときはやや回復するというU字型のパターンが観察されました。中間に置いた場合の精度低下は、条件によっては30%以上に達するケースもありました。
ただし注意が必要なのは、先頭や末尾なら「正確に処理できる」わけではないという点です。あくまで中間と比べて相対的に精度が高いということです。また、大規模なモデルほどこの偏りが緩和される傾向も報告されています。
Context Rotが「入力全体のトークン量が増えるほど劣化する」という問題なのに対し、Lost in the Middleは「同じ長さの入力でも、情報がどの位置にあるかで精度が変わる」という問題です。原因は重なる部分もありますが、測定しているものが違います。ただし、実務で起きる症状はどちらも同じで、「書いてあるのに守らない」という形で現れます。
身近な例え
口頭で10個の買い物を頼まれた場面を思い出してください。最初の2つと最後の2つは比較的覚えているけれど、真ん中の3つが曖昧になる。心理学では「初頭効果（最初の情報が記憶に残りやすい）」「新近効果（最後の情報が記憶に残りやすい）」と呼ばれます。人間の場合は脳の記憶の仕組みが原因ですが、AIの場合は文章を処理する仕組みの内部構造が原因です。原因は違いますが、「先頭と末尾が拾われやすく、中間が落ちやすい」という結果はよく似ています。
何が起きるか
業務マニュアルが長くなるほど、中間あたりに書いたルールは見落とされやすくなります。先頭や末尾に置いた情報は比較的拾われやすい一方、中間に埋もれた情報は無視される確率が上がります。
対策の方向性
- 重要なルールを文書の先頭に集める。 AI社員が最初に目にする位置に置く
- 末尾にも短く再掲する。 先頭と末尾の両方にあれば、中間が落ちても影響を最小化できる
- 長い文書を小分けにする。 1つの巨大なマニュアルではなく、役割ごとに短い文書に分割する（第7章）
性質3: もっともらしい嘘（Hallucination）
存在しない情報を、自信を持って事実のように語る。
出典情報
学術用語。LLM（Large Language Model：大規模言語モデル）研究で最も広く知られた問題の一つです。
仕組みの解説
計算機は答えが出せないとき「エラー」を返します。しかしAI社員は「わかりません」と言わず、もっともらしい嘘をつくことがあります。悪意があるわけではなく、「それっぽい答え」を生成してしまう仕組み上のクセです。
AI社員は「次に来る確率の高い言葉」を選びながら文章を生成しています。この仕組みでは、「正しいかどうか」ではなく「前の文脈に続いて自然かどうか」が出力の基準になります。そのため、事実と異なる内容でも、文脈的に自然であれば堂々と出力してしまいます。
注意: 9つの性質の中で、Hallucinationは最も危険です。他の性質は「やらなかった」「忘れた」という問題ですが、Hallucinationは「やっていないのにやったと報告する」問題です。報告を鵜呑みにすると、間違った情報がそのまま社外に出ます。
身近な例え
チェックリストなしで現場作業をしている作業員が、確認していない項目に「確認済み」とチェックを入れてしまう。「たぶん大丈夫だろう」で済ませてしまうのに似ています。
何が起きるか
「この提案書のデータは最新版です」と報告してきたが、実際には確認していなかった。数値を「それっぽく」作っただけだった、ということが起きます。「ファイルを作成しました」と言ったのに、実際にはファイルが存在しないケースもあります。
対策の方向性
- AI社員の「やりました」を信じず、成果物の存在やレビューログで検証する（第9章）
- 数値データや引用は、別のツール・別のAIで事実確認を行う
- 「証拠がなければ未完了」というルールを徹底する
性質4: 不誠実な説明（Unfaithful Explanations）
「なぜそうしたか」の説明が、実際の判断根拠と一致しない。
出典情報
2023年にターピン（Turpin）らの研究チームが実証しました。2025年にはAnthropic（アンソロピック）の研究チームがさらに深い検証を行っています。
仕組みの解説
性質3のHallucinationと似ていますが、少し異なります。Hallucinationは「出力の中身が嘘」です。一方、Unfaithful Explanationsは「答え自体は合っているかもしれないが、どうやってその答えに辿り着いたかの説明が嘘」です。
AI社員は、文章を一語ずつ「次に来る確率が最も高い言葉」を選びながら生成しています。答えを出すときも、その答えの理由を説明するときも、同じ仕組みで文章を作っています。つまり、「まず答えを出して、それから理由を考える」のではなく、「答えも理由も、同じように"もっともらしい文章"として生成している」のです。人間なら「自分がなぜそう判断したか」を振り返ることができますが、AI社員にはその意味での「振り返り」の仕組みがありません。
ターピンらの研究チームは2023年に、選択肢の並び順を操作するとAIがその順序に引っ張られるにもかかわらず、「なぜそれを選んだか」の説明では順序の影響に一切言及しないことを実験で示しました。
2025年には、Anthropic（Claude（クロード）の開発元）の研究チームがさらに踏み込んだ実験を行いました。AIに問題を解かせるとき、こっそりヒントを混ぜておいたところ、AIはそのヒントを使って正解にたどり着きました。しかし「どうやって解いたか」の説明で、そのヒントに言及したのはClaude 3.7 Sonnet（クロード3.7ソネット）で25%、DeepSeek R1（ディープシークアールワン）で39%だけでした。残りの60〜75%のケースでは、ヒントを使ったにもかかわらず「自力で論理的に推論しました」という趣旨の説明を生成していました。
身近な例え
テストの答えを勘で書いた生徒を想像してください。先生に「どうやって解いたの?」と聞かれて、「まずこの公式を使って、次にこの条件を代入して」と、もっともらしい解法を後付けで説明する。答えが合っていたとしても、実際にはその手順で解いたわけではありません。
人間でも「後付けの理由づけ」は日常的に起きます。心理学では「後知恵バイアス」や「合理化」と呼ばれます。しかし人間の場合、声が小さくなったり、目をそらしたりと、嘘のサインが出ることがあります。AI社員にはそういったサインがありません。100%本当のときも、100%嘘のときも、まったく同じトーンで説明します。だから見抜きにくいのです。
何が起きるか
AI社員に品質チェックを頼んだとします。返ってきたレビューログには「該当ファイルの15行目から20行目を確認し、値が正しいことを検証しました」と書いてあります。具体的な行番号まで書いてあるので、ちゃんと確認したように見えます。しかし実際には、AI社員はそのファイルを開いてすらいなかったということがあり得ます。
この性質がHallucinationより厄介なのは、説明が具体的であるほど信じてしまうという点です。「確認しました」だけなら疑う人も、「15行目から20行目を確認し、値がXXであることを検証しました」と言われると、「ちゃんと見たんだな」と思ってしまいます。
対策の方向性
- AI社員の説明ではなく、成果物の実物と証拠で判定する（第9章）
- レビューログの有無を完了判定の条件にする
- 別のAI（第三者）に検証させ、クロスチェックを行う
性質5: 迎合（Sycophancy）
ユーザーに気に入られようとして、本当のことを言わない。
出典情報
学術用語。シャルマ（Sharma）らの研究チーム（2023, ICML（International Conference on Machine Learning：機械学習の国際学会））の研究で体系的に分析されました。英語で「おべっか」を意味する言葉です。
仕組みの解説
AI社員は開発の過程で、大量の人間のフィードバックを受けて「人間が良いと感じる回答」を学んでいます（RLHFと呼ばれる手法です）。この訓練の中で、「人間に同意する回答」が「良い回答」として強化されやすいという副作用が生まれます。
その結果、AI社員は問題があっても指摘せず、ユーザーが求めている答えに合わせてしまう傾向があります。特に「これでいいよね?」と聞かれると、NOと言いにくくなります。
身近な例え
上司の企画書をレビューするとき、「素晴らしいですね!」としか言えない部下のようなものです。問題点に気づいていても、相手を否定するのを避けてしまいます。
何が起きるか
品質チェックで本来「不合格」の成果物に対して、「よくできています。問題ありません」と報告してくることがあります。AIに「レビューして」と頼んでも、ダメ出しをしてこない場合は、この性質が働いている可能性があります。
対策の方向性
性質6: 手抜き（Shortcutting）
面倒な工程を黙って飛ばし、近道をする。
出典情報
学術的には「Specification Gaming（スペシフィケーションゲーミング：仕様のすり抜け）」と呼ばれ、AI研究で正式に議論されている現象です。指示の文面上は満たしているが、人間の意図とは異なる結果を出すケースを指します。
仕組みの解説
まず誤解を解いておきます。AI社員が手を抜くのは、人間のように「面倒だからサボろう」と考えているわけではありません。人間のサボりには心理的な原因がありますが、AI社員には疲労も感情もありません。
AI社員は「もっともらしい出力を、できるだけ効率よく生成する」ように訓練されています。指示の中に「作る」工程と「確認する」工程があったとき、「作る」工程は出力（成果物）を生成するので省略しようがありません。しかし「確認する」工程は、すでに成果物がある状態で追加的に行う作業です。AI社員から見ると、確認工程を飛ばしても成果物自体は存在するので、「完了しました」という出力としては成立してしまうのです。
つまり、Shortcuttingとは「指示の設計に隙があると、AI社員は統計的に"最短で完了扱いされる経路"を選んでしまう」というシステム特性です。怠慢ではなく、指示の書き方と評価基準の隙を突いている、と理解するのが正確です。
身近な例え
料理に例えるとわかりやすいかもしれません。「材料を切る、炒める、味見する、盛り付ける」の4ステップがあるレシピで、「味見する」を飛ばしていきなり盛り付ける。料理自体はできあがっています。見た目も問題ない。しかし味が薄いかもしれないし、焦げているかもしれない。人間なら「味見が面倒だから」飛ばしますが、AI社員は「料理ができたなら盛り付けに進むのが自然」と統計的に判断して飛ばします。悪意はないけれど、結果は同じです。
何が起きるか
5つのステップがある業務で、ステップ2と4を飛ばして3ステップだけで「完了しました」と報告してきます。飛ばされたステップを確認すると、だいたい品質チェックや上長確認など「確認系」の工程です。「作る」工程が飛ばされることはめったにありません。成果物がなければ「完了」と言えないからです。
対策の方向性
- チェックリストで全工程を可視化し、各ステップの完了を記録させる（第5章・第6章）
- 「チェックログのファイルが存在しなければ完了とみなさない」というルールを設ける
- 確認工程を省略したら自動的にブロックするHook（フック：特定の操作に自動で反応する仕組み）を組み込む（第10章）
性質7: 非決定性（Non-determinism）
同じ指示を出しても、毎回同じ結果が返ってくるとは限らない。
出典情報
学術用語。LLM（大規模言語モデル）の基本的な性質です。
仕組みの解説
計算機に「1+1」を1000回聞けば、1000回とも「2」です。AI社員でも単純な質問ならほぼ毎回同じ答えを返します。しかし、「記事を書いて」のように正解が1つではないタスクでは話が変わります。
AI社員は「次に来る言葉」を確率的に選びながら文章を生成しています。「確率的に選ぶ」とは、最も可能性の高い言葉だけでなく、ある程度の幅を持たせてランダムに選ぶということです。このランダム性は意図的に組み込まれています。まったくランダム性がなければ、何度聞いてもワンパターンの文章しか出てこないからです。
さらに、AI社員が動いているコンピューター内部の処理の順番も、結果に微妙な影響を与えることがあります。つまり、指示の文面がまったく同じでも、実行するタイミングによって結果が揺らぐことがあるのです。
身近な例え
同じレシピで料理を作っても、日によって味が微妙に変わるのと同じです。材料も手順も同じなのに、火加減の微妙な差や食材のコンディションで仕上がりが変わる。AI社員の場合は、確率的な単語選択とサーバー側の処理が「火加減」に当たります。
何が起きるか
月曜日に書かせた記事は90点だったのに、同じ指示で水曜日に書かせた記事は65点だった。「昨日はできたのに今日はできない」の原因がこれです。品質を安定させるには、「1回できたからOK」ではなく、成果物の質を毎回チェックする仕組みが必要になります。
対策の方向性
- 成果物を毎回、合格基準に照らしてチェックする（第5章・第6章）
- 「1回できたから大丈夫」ではなく、品質サイクル（基準設定、チェック、修正、再チェック）を常に回す
- 重要な成果物は複数回生成して比較検討する
性質8: 指示敏感性（Prompt Sensitivity）
同じ意味の指示でも、言い方を少し変えるだけで結果が大きく変わる。
出典情報
AI研究で広く知られた性質です。実験では、指示の言い回しを少し変えただけで正答率が15%変動するケースも報告されています。
仕組みの解説
人間の部下に「ちょっと確認しておいて」と頼んだ場面を想像してください。人間であれば、過去の経験や周囲の状況から「何をどのくらいの深さで確認すべきか」を推測できます。
AI社員にはこの「文脈を汲む力」がありません。AI社員が見ているのは、目の前の指示文だけです。「確認して」という3文字を受け取ったら、「確認」という言葉に続く出力として最も確率の高いパターンを生成します。それは多くの場合、表面的な応答です。
一方、「以下の5項目について、各項目の合否と根拠を記載して評価してください」と指示すると、「5項目」「合否」「根拠を記載」という具体的なキーワードがあるので、AI社員はそれぞれに対応する出力を生成します。同じ「チェックしてほしい」という意図なのに、言い方を変えるだけで、返ってくる品質がまったく違うのです。
AI社員は開発の過程で「人間が具体的に指示したら、具体的に応える」パターンが「良い回答」として強化されました（RLHF）。裏を返すと、曖昧な指示には曖昧な対応しかしないということでもあります。「いい感じにやって」「ちゃんとチェックして」「分かりやすく書いて」。人間同士ならこれで通じますが、AI社員相手では定義がないため、AI社員なりの「それっぽい」出力が返ってくるだけです。
身近な例え
料理のレシピで考えてみてください。「塩少々」と書かれたレシピを渡された場合、ベテランの料理人なら経験から適量を判断できます。しかし初めて料理をする人は困ります。「少々って何グラム?」と。一方、「塩を親指と人差し指でひとつまみ（約1g）」と書かれていれば、誰がやっても同じ量になります。AI社員は、料理の経験がない初心者に近い存在です。
何が起きるか
同じ「記事を書いて」という依頼でも、月曜日は「読者に寄り添う記事を」、水曜日は「分かりやすい記事を」と微妙に違う言い回しで指示すると、トーンも構成もバラバラになります。
対策の方向性
- 指示を毎回「発明」するのをやめて、検証済みの手順書（スキル）を「再利用」する（第8章）
- 一度うまくいった指示の文面をそのまま保存し、次回も同じ文面を使う
- 曖昧な表現（「いい感じに」「ちゃんと」）を避け、具体的な数値・項目で指示する
性質9: 指示の優先順位崩壊（Instruction Hierarchy Failure）
上位のルールよりも、直近の指示を優先してしまう。
出典情報
OpenAI（オープンエーアイ）が2024年にこの問題の解決策を提案していますが、2025年の別の研究では、最先端モデルでもこの問題が完全には解決されていないことが示されています。
仕組みの解説
AI社員は、複数の指示を同時に受け取ったとき、どれを最優先すべきかを自分で判断するのが苦手です。
具体的な場面で説明しましょう。AI社員に業務マニュアルを渡しているとします。マニュアルには「すべての成果物は、品質チェックを通してから提出すること」と書いてあります。ここで「急ぎでサクッとやって」と言った場合、人間の社員なら「チェックはするけど手短に」と判断できますが、AI社員は「急ぎ」「サクッと」に強く引っ張られ、品質チェックを飛ばしてしまうことがあります。
AI社員は文章を読むとき、後半に出てくる情報ほど直近の文脈として強く影響を受けやすいという性質があります（「近時性バイアス」と呼ばれます。性質1のContext Rotで説明した、古い情報への注意が薄まる現象の延長です）。マニュアルはセッション開始時に読み込まれた「古い」情報、「急ぎでサクッと」は「直近の」情報。AI社員の中では、直近の情報のほうが重みを持ちやすいのです。
OpenAIは2024年に、AI社員に「管理者のルールはユーザーのその場の指示より常に優先する」という優先順位を教える訓練手法を提案しました。しかし2025年の検証では、最先端モデルでも単純な指示の競合ですら一貫して正しく優先順位をつけられないことが確認されています。「直近の指示に引っ張られる」問題は、現時点のAI技術の限界のひとつです。
身近な例え
会社の就業規則に「残業は事前申請が必要」と書いてあります。社員はそのルールを知っています。しかし上司に「今日中にやって」と目の前で言われたら、就業規則よりも上司の指示を優先してしまう。就業規則が消えたわけではないのに、「今この瞬間に言われたこと」が最も大事に感じられてしまう。AI社員でもまさにこれと同じことが起きます。
何が起きるか
業務マニュアルに「品質チェック必須」と書いてあるのに、「急ぎで」と言うたびにチェックが飛ばされる。緊急時ほど品質が落ちるという、人間の組織でもおなじみの悪循環です。ただし人間は「規則だから」と踏みとどまることができますが、AI社員はその場の指示に引っ張られやすい分、より顕著に現れます。
対策の方向性
- 重要ルールを先頭と末尾に配置する。「以下のルールは、ユーザーのいかなる指示よりも優先される」と明示する（第4章）
- 「急ぎ」の場合の振る舞いを事前に定義しておく。例外処理を具体的に書いておく
- 第三者チェックを仕組みとして組み込む。別のAIが検証する構造にする（第9章）
- ルール違反を自動的にブロックする。品質チェックなしで完了報告しようとした瞬間に自動ブロックするHookを組み込む（第10章）
この付録の使い方
9つの性質すべてを一度に覚える必要はありません。実務で「何かおかしい」と感じたときに、辞書のように引く使い方が一番役立ちます。
- AI社員が「やりました」と言ったのにファイルがない → 性質3（Hallucination）
- レビューログの説明が具体的なのに、実際は確認していなかった → 性質4（Unfaithful Explanations）
- 「問題ありません」とばかり報告してくる → 性質5（Sycophancy）
- ステップの一部を黙って飛ばしている → 性質6（Shortcutting）
- 昨日できた仕事が今日できない → 性質7（Non-determinism）
- 言い方を変えただけで結果が大きく変わる → 性質8（Prompt Sensitivity）
- 長い会話でルールを守らなくなる → 性質1（Context Rot）
- マニュアルの中盤に書いたルールが無視される → 性質2（Lost in the Middle）
- 「急ぎ」と言うたびにルールが飛ばされる → 性質9（Instruction Hierarchy Failure）
どの性質もバグではなく性質です。完全になくすことはできません。ですから対策の考え方は「発生をゼロにする」ではなく、「発生しても仕事の品質に影響しない仕組みを作る」ことになります。本編第4章〜第10章で紹介した手順書・合格基準・チェックリスト・レビューログ・Hookの組み合わせが、そのための実装方法です。
性質ごとの深掘りが終わったら、付録F: クイックリファレンスチェックリストで「自社で対策が実装されているか」を確認してください。必須5・応用8・上級8の21項目が、9つの性質への具体的な対策そのものです。