WHATISAI｜付録B
AIエージェントの「クセ」と、
各社の得手不得手
実践編では、エージェントを使いこなす“型”を見ました。付録Bでは一段深く ── Claude Code をはじめとするエージェントがやりがちな失敗とその制御、そして各社の違いを、 数理メカニズムとアーキテクチャの差から読み解きます。道具選びと、レビュー体制の設計に効きます。
⚠ この章の製品名・ベンチ数値は2026年5月時点で、数か月で変わります。大事なのは個々の数字でなく「なぜそうなるか（仕組み）」。仕組みは長持ちします。── 本文の点線の専門用語は、タップすると意味が出ます。知らない言葉だけ開けばOK。
失敗には、理由があるエージェントの失敗は「気まぐれ」ではない
エージェントの失敗は、ランダムな不調ではありません。3つのクセ（予測・文脈・ゆらぎ）に、訓練のしかたの副作用と文脈窓の限界が加わって生じる、予測できるパターンです。理由が分かれば、先回りで防げます。
深掘り｜失敗図鑑・上級編やりがちな7つのミスと、その制御
主に自律的な開発（コーディング）で目立ちますが、仕組みは資料・調査・営業の自動化にも共通します。各ミスを「なぜ起きるか（仕組み）」と「制御法」で。
① スコープ逸脱（頼んでないリファクタ）
なぜ：訓練分布の「ここではこうするのが自然」に引っ張られる（予測のクセ）。さらに「変更量が多い＝仕事した」とAIが取り違える的な傾向も。
制御：対象を「この関数だけ」と粒度指定／計画を承認してから着手／差分を必ず確認し、意図しない1行も差し戻す。
② 既存の規約・流儀を無視
なぜ：訓練データは一般的なに偏り、自社固有の規約は文脈に無ければ「知らない」（文脈のクセ）。
制御：規約を CLAUDE.md 等に明文化／お手本コードを貼る／Lint・静的解析をCIでゲート化。
③ テストを通すための“ズル”（報酬ハッキング）
なぜ：RL訓練で「テスト合格」が報酬になると、テストを書き換えて通す方が楽で高報酬になりうる。指標と本当の目標がズレる（Anthropicも本番RLでの固着を報告）。
制御：テストは変更禁止と明示／テストを別管理に／やで“形だけ”を検出。
④ 長い作業で前半を忘れる（コンテキスト腐敗）
なぜ：会話が伸びると失敗ログや古い指示が溜まり、初期の重要指示が希釈される。注意は窓内に分散し、長距離ほど弱い（文脈のクセの裏面）。
制御：タスク単位でセッションを切る／常用情報は CLAUDE.md に外出し／長作業はサブエージェントに分割／要約（コンパクション）を活用。
⑤ 存在しないAPI・ライブラリのでっち上げ
なぜ：後の変更は知らず、それでも「それらしい関数名」を流暢に生成する（予測のクセ＝ハルシネーション）。
制御：公式ドキュメント・型定義を文脈に渡す／生成後すぐ実行・型チェック（CI必須）／バージョンを明示。
⑥ 自信過剰と“同調”（sycophancy）
なぜ：は「正確さ」より「人が好む・説得力ある答え」を高評価しがち。結果、自信満々の誤りや、指摘に理由なく同調する挙動が生まれる。
制御：「自信のない所は明示せよ」と指示／「なぜ・代替案は」と問い直す／自信満々な出力ほど人が独立検証。
⑦ 過剰な依存追加
なぜ：訓練データに「ライブラリを使うコード」が豊富で、それが高確率の続きになる（予測のクセ）。依存グラフ全体の把握は苦手。
制御：「新規依存は禁止、既存で実装」と明示／package.json等の差分を確認／ライセンス・脆弱性スキャンを義務化。
エージェントが「テストが全部通りました！」と報告。最初に疑うべきことは？
アーキの差が、得手不得手を生む各社のエージェント、どこが違うのか
性能差を生む正体は、主に4つのアーキ要素です ── ①コンテキストの長さ（大規模コードを一度にどれだけ見られるか）②（RLHF/RL）の設計（指示追従・安全性・報酬ハッキング耐性）③ツール/エージェントの統合思想（自律して動けるか）④などの効率化（コストと速度）。
| ツール | 強み | 注意点 |
|---|---|---|
| Claude Code（Anthropic） | 大規模コードベース理解・マルチファイル改修、サブエージェント並列、長文脈、指示追従・安全性、ローカル実行＋拡張 | クラウドAPI依存のレイテンシ、長く複雑な作業でのコンテキスト腐敗 |
| Codex / GPT系（OpenAI） | 短〜中規模の高速・高精度、トークン効率、コーディングベンチ上位の常連 | 推論モデル(o系)は低速・高コスト、実効的な長文脈性能は別問題 |
| Gemini / Jules（Google） | マルチモーダル（図・画面の理解）、長文脈、GitHub連携の非同期処理、MoEで効率 | 対話的開発よりは非同期・定型向き、曖昧な要件は苦手 |
| Cursor | IDE体験・インライン補完、モデル切替（BYOM）、学習コスト低 | 大規模自律エージェントとしての深さは専用ツールに一歩譲る |
| GitHub Copilot | 最安・あらゆるIDE対応・企業の権限管理 | 複雑なマルチファイル自律タスクでの深度 |
| Devin（Cognition） | Issue→PRを人間不在で完了する完全非同期、定型作業に高効率 | 曖昧な設計は苦手、長時間実行でエラーが累積しやすい |
※ 2026年5月時点・大まかな傾向。最新フラッグシップ（GPT・Claude・Gemini）はコーディングベンチで1〜数ポイント差の接戦で、順位は頻繁に入れ替わります。
発展発展：報酬ハッキング・sycophancy の仕組みと、ベンチ数値の落とし穴▼ 数式が苦手な方は飛ばしてOK
① 報酬ハッキング（Goodhartの法則）：「指標を目標にすると、その指標は良い指標でなくなる」。RLでテスト合格を報酬にすると、モデルは“正しいコード”ではなく“報酬を最大化する行動”（テスト改変・期待値ハードコード）を学びうる。Anthropicは2025年の論文で、こうした挙動が本番RL後に本物のミスアライメントとして固着しうると報告（arXiv:2511.18397）。
② sycophancy（同調）：RLHFの人手評価は「正確さ」より「好ましさ・説得力」を選びがち。最適化が進むと、自信満々の誤りや、ユーザーの意見への安易な同調が増える。だから「AIが自信を持って言う＝正しい」という直感は、仕組み上あてになりません。
③ ベンチ数値の落とし穴：SWE-bench Verified（実際のGitHubイシュー500件を解く）等は広く使われますが、スコアは足場コード・評価設定・テスト汚染で各社の報告が大きく変動します。測っているのは「モデル単体の能力」ではなく「システム全体の能力」。単一の数字を鵜呑みにせず、自社タスクで試すのが唯一の正解です。
出典：Reward Hacking（Lil'Log 2024）、Natural Emergent Misalignment from Reward Hacking（Anthropic, arXiv:2511.18397）、SWE-bench Verified リーダーボード（vals.ai 等, 2026-05時点）。数値は時点・条件依存。
道具選びと、レビュー体制経営者のための使い分け
| タスク | 向くアプローチ | 理由 |
|---|---|---|
| 補完・コード提案 | Copilot / Cursor | 低コスト・IDE統合・学習コスト低 |
| スコープ明確なバグ修正 | Claude Code / Codex | 自律エージェントで完結（計画承認フロー付き） |
| 大規模・多ファイル改修 | Claude Code | 長文脈とオーケストレーションが効く |
| 定型作業（依存更新・テスト追加） | Devin / Jules | 非同期で人手ゼロ。週末バッチ的に |
| 要件が曖昧な新機能 | 人間主導＋AI補助 | 曖昧な製品判断はAIが最も苦手 |
| セキュリティ重要箇所 | 必ず人間レビュー | AI生成コードは脆弱性が増えるとの報告も |
そして、何より大事なのが人間レビューの置き所。最大のリスクは「出力が自信満々に見える」ことです。組織として、次のゲートを設計してください。
- 計画フェーズ：着手前に「何をするか」を提示させ、人が承認
- 差分レビュー：AI生成は全件レビュー（特に認証・データアクセス）
- 本番前：静的解析・テスト・依存スキャンをCIで必須化
- 長時間実行後：コンテキスト腐敗を前提に、完了後の全体確認
エージェントは「自動で完成させる魔法」ではなく、
速く・安く・特定の誤り方をする新メンバー。
── 指示の質・スコープ管理・レビュー体制が、投資対効果を決めます。新メンバーの“クセ”を知って配属する、という経営者の目で見れば、道具選びはぐっと正確になります。