✍️ 필사 모드: AIコーディングアシスタントの限界 2026 — 正直な、しかし公正な評価(できないことについて)

プロローグ —— 称賛ではなく較正(calibration)が必要な時期

過去18か月のAIコーディング関連コンテンツはほぼ 3つのモード のどれかだった。

1. ユートピア —— 「もう開発者は不要」
2. ディストピア —— 「AIのコードはゴミ」
3. マーケティング —— 「弊社ツールはX%を自動化します」

この記事はそのどれでもない。この記事は calibration についての文章だ。

AIコーディングアシスタントは強力だ。しかしその強さの形は一様ではない。 あるタスクでは 3x〜10x の multiplier、あるタスクでは 0x、あるタスクでは マイナスの multiplier —— 人が直接やるよりも遅く、誤った結果になる。

2026年5月中旬時点、SWE-bench Verified 上位のエージェントは 75% 前後に達している。良い数字だ。しかし、その 25% がどんな 25% かを知らなければ、その領域で信頼を 1 に置いて損をする。

この記事は AIが苦手な10のこと を扱う。それぞれに対して:

• 実際の失敗パターン —— 抽象ではなくコード。
• なぜそうなるか —— モデルアーキテクチャとハーネスの限界に還元。
• 開発者が続けるべきこと —— 人間の判断が multiplier になる地点。

最後に マトリクス、チェックリスト、アンチパターンリスト を置く。AI懐疑論ではなく、AIツールをよりうまく使うための較正 だ。

第1章 · 深いバグのデバッグ —— 「エージェントはコードを書くが、バグは絞り込めない」

パターン

本番サービスで5分おきにP99レイテンシが跳ねるバグがあった。原因はGCではなく、TLSセッション再ネゴシエーションの嵐 だった。エージェントは8時間をGCチューニングに費やし、その8時間後に「GCログをもっと詳細に見たいので権限をください」と言ってきた。

なぜそうなるか

LLMエージェントは 仮説トンネリング(hypothesis tunneling) に弱い。一度「これはGCの問題っぽい」がコンテキストに入ると、その後のすべてのツール呼び出しと推論が その仮説を確証する方向に偏る。人間のデバッガは1時間ほど経って「これじゃないかも?」と立ち止まり、別の枝を見る。エージェントはコンテキストが厚くなるにつれて最初の仮説を強化する —— context rot の最も陰湿な形だ。

さらにエージェントのツール呼び出しは ローカルな情報 を見る。デバッガを立ち上げてコアダンプを見る、パケットキャプチャを追う、カーネルtraceを読む —— こうした作業は部分的にしか自動化されない。そして「再現しない」バグはエージェントの弱点だ。再現が難しいとエージェントは 推測を増やす。

人がやり続けるべきこと

• 仮説を閉じるな。 エージェントに「これはGCではないかもしれない、別の5つの仮説を挙げろ」と強制する。
• 反証可能な実験を設計する。 エージェントは「自分が正しい証拠」を見つけるのは得意だが、「自分が間違っている証拠」を見つけるのは苦手。
• 8時間ルール。 同じ仮説を8時間以上追っているなら止まれ。エージェントは止まらない —— あなたが止まる必要がある。

実際のダイアログ例

人間: 「P99 が急に跳ねる。GC っぽい。見てくれ。」
エージェント:(1時間)「G1GC パラメータをチューニングしましょう…」
人間: 「他にどんな仮説が成り立つ? 5つ挙げて。」
エージェント:「1) GC、2) ディスク IO の嵐、3) ネットワーク再送、4) TLS 再ネゴ、5) コンパクション作業」
人間: 「GC 以外の4つを5分ずつ見て。証拠があるか。」

この強制的な分岐がないとエージェントは1番から抜け出せない。メタ指示(meta-instruction) —— 「他の仮説も見ろ」 —— が multiplier。

第2章 · 大規模コードベースのアーキテクチャ —— 「エージェントは断面を見て、全体を見ない」

パターン

100万行のモノレポで新機能を追加させる。エージェントはそれを new-feature/ ディレクトリにきれいに作る。コードは動く。しかし同じチームのシニアが見ると「うーん、これって platform/shared/orchestration に似たやつがすでにあるよね?」と言う。エージェントはそれを見られない —— そのディレクトリを一度も読まなかったから。

なぜそうなるか

LLMはコンテキストウィンドウの中だけで推論する。1Mトークンのモデルでも100万行のモノレポ全体を一度に見られない。エージェントは 名前ベースの検索 と 言及されたパス でコードベースを辿るが、これは 暗黙の知識 を捕えられない。

特に危険なのは abstraction conflict だ。エージェントは「きれいな抽象」を作る。しかしその抽象が既存の抽象と 形は違うが意図は重なる なら、コードベースは 2つの似た抽象レイヤー を持つことになる。半年後、新人はどちらを使えばよいか分からず、両方を使い、結局3つ目を作る。

人がやり続けるべきこと

• エージェントに「似たものがすでにあるか先に検索しろ」と明示的に強制する。 AGENTS.md か prompt に。
• PR段階の「abstraction review」 —— シニアが「これは既存のXとどう違うか」を問う段階。AIは自分にこの質問をうまく投げない。
• アーキテクチャドキュメントをテキストではなくエージェントが読める形 で置く。ADR、モジュール責任マトリクス。エージェントは読めないものを見ない。

もう一歩 —— 「既存コードを2度読ませる」

大規模コードベースで効果が良かったトリック。エージェントに task を渡す前に、明示的に2段階を踏ませる。

1)「この task に関係しそうな既存モジュールを5分間検索して列挙しろ。」
2)「それらモジュールの責任が task とどう重なるか、新しいコードをどこに置くべきか候補を3つ提示しろ。」
3)「人間の確認を受けてからコーディングを始めろ。」

この3段階ゲートで抽象化衝突が 30〜50% 減るというのが我々のチームの経験だ。エージェントは「コードを書き始める」がデフォルトなので、書く前に止まるように明示 する必要がある。

第3章 · 微妙な性能リグレッション —— 「見た目は同じで10倍遅い」

パターン

エージェントが N+1 クエリを「リファクタ」する。コードはきれいに見える。テストは全部通る。本番にデプロイする。P95 が10倍になる。見ると、きれいに見えるそのコードが インデックスに乗らないクエリパターン に変わっている。あるいは lazy load だったのが eager load になっている。

なぜそうなるか

LLMはコードの 形 を見る。コードの 実行時コスト は直接見ない —— 推論するだけだ。そしてその推論はしばしば データ分布に依存 する。100行では見えないN+1が100万行ではP95を殺す。エージェントは100万行の分布を 知らない。

エージェントは マイクロベンチマーク を書くのも苦手だ。JITウォームアップ、キャッシュ効果、測定ノイズ —— すべて人間の直感が必要な領域。

人がやり続けるべきこと

• 性能リグレッションテストをCIに埋め込む。 エージェントはリグレッションを見ない —— CIに見てもらう必要がある。
• プロファイラ結果を直接エージェントに食わせる。 「このPRを見ろ」ではなく「このflamegraphを見てリグレッションを見つけろ」。ツールが変わると能力が変わる。
• データ分布に対する責任は人間が持つ。 エージェントは「1000行で動く」ことは知っているが、「1億行でどうか」は知らない。

小さな事例 —— アルゴリズム複雑度の hidden upgrade

エージェントが Set ベースの dedup を Array.filter + includes に「単純化」する PR をよく見る。コードは短い。100件のときは速い(定数が小さい)。10万件では O(n²) で 30 倍遅い。ユニットテストは10件なので捕まらない。本番で捕まる。

このパターンが危険なのは 「リファクタに見えるリグレッション」 だからだ。PR レビュアーも「もっとすっきりしたね」と通す。自動性能リグレッションテストだけが客観的な安全網だ。

第4章 · 並行性の正しさ —— 「パターンマッチで race-free を真似る」

パターン

エージェントがマルチスレッドキューを実装する。コードは Mutex と Condvar を定石どおりに使う。レビューすると「うん、ちゃんとできてる」と思う。半年後、負荷がかかった状況でデッドロックが発生する。見ると、2つのロックの取得順序が2か所で 逆 だった —— 競合がほとんど起きないパスで。

なぜそうなるか

並行性コードは ケース学習 で身につきにくい。モデルは「よくある race-free パターン」を非常にうまく真似る —— producer/consumer、reader/writer lock、チャネルベースのメッセージパッシング。しかし 2ロックの順序一貫性、メモリモデル(Acquire/Release/SeqCst)、再入条件 のようなものは 全域推論 が必要だ。モデルは断面を見る。

そして テストでは捕まらない。レースコンディションは本質的に非決定的で、ユニットテストはほぼ決定的なケースしか叩かない。ThreadSanitizer、loom、jepsen のようなツールが必要だが、エージェントはこれらのツールを巧みに扱えない。

人がやり続けるべきこと

• 並行性コードは必ず2つ目の人間の目で。 PRに「concurrency: review needed」ラベルを付ける。
• モデルチェッカーを使う。 TLA+、loom、Coq —— 並行性の正しさに対する真の保証は依然として形式検証。
• エージェントには「interleavingを列挙しろ」と明示。 エージェントは聞かれなければやらない。

一行コメントで lock order を強制

// LOCK_ORDER: always (config -> session) — see SECURITY.md L42
let _c = config.lock();
let _s = session.lock();

こうした明示的コメントが2か所で同じ順序を強制する道具になる。エージェントは「文脈表示コメント」によく従う。ただし、そのコメントを書くのは人間の仕事だ。

第5章 · 曖昧さの中の判断 —— 「チームはどのトレードオフを好むか」

パターン

「このAPIにエラーハンドリングを追加して」。エージェントはきれいな Result ベースのエラーハンドリングを追加する。しかしこのチームは panic-on-invariant-violation が規約だった。別のチームは OpenTelemetry でエラーを送るのが規約だった。エージェントは「正しい」答えを知らない —— 答えはチームの選択に依存するからだ。

なぜそうなるか

ソフトウェアエンジニアリングの大部分は 趣味とトレードオフ だ。「どのパラダイムを使うか」「どこまでが適切な抽象化レベルか」「このlatency 50msをコード可読性30%向上と交換する価値があるか」。これらの問いには コンテキスト外の情報 が必要だ —— チームの価値観、会社の優先順位、ユーザーの痛みポイント。

エージェントはこれを 推測する。良い推測をする。しかし推測は推測だ。

人がやり続けるべきこと

• 「好み」ドキュメントを作る。 AGENTS.md に「エラー処理は panic ではなく Result」「ロギングは structured」「非同期はチャネルベース」のようなものを書き込む。
• エージェントに「どのトレードオフがあるか」を問わせる。 曖昧なら聞かせる。聞かなければ推測する。
• PR段階で「チーム規約との一致」を明示的に見る。 自動化に任せない。

第6章 · 本当に新しい技術 —— 「訓練カットオフバイアス、新しいドキュメントを与えても旧パターンに回帰」

パターン

2026年初頭に出たライブラリ(例えば Effect-TS 3.x、React 19.5 の新しい並行機能、Next.js 16 の PPR 安定化)について、新しいドキュメントをコンテキストに丸ごと入れる。エージェントは最初は新しいAPIをうまく使う。しかし数百トークンほど進むと 2024年のパターン に回帰する —— useEffect パターンを新しい concurrent hook の上に重ねたり、新APIのシグネチャを忘れて旧シグネチャで呼び出したり。

なぜそうなるか

LLMは 訓練データで見た頻度 に強く影響を受ける。新しいライブラリのドキュメントは数万トークンに過ぎないが、古いライブラリはモデル重みに深く埋め込まれている。コンテキストの情報は重みの prior を完全に上書きできない。

これは RAG でもうまく解けない。検索して新しいドキュメントを与えても、モデルは一貫して新しいパターンに従うのではなく —— 新シグネチャ + 旧パターンという 混合ハルシネーション を作る。

人がやり続けるべきこと

• 新しいライブラリは自分の手で一度書く。 エージェントに渡す前に自分でパターンを身につける。そうすればエージェントの回帰に気づける。
• エージェントのコードに「バージョン強制」アサーションを埋め込む。 lint ルール、型チェック。「旧 API 呼び出しはコンパイルエラー」になるように。
• エージェントが旧パターンに回帰するたびに明示的に訂正する。 一セッション内での反復訂正は効く。

検証済みの回帰シグナル

新ライブラリ作業中、以下を見たら回帰を疑え:

• import パスがそっと旧パスに戻る(react/jsx-runtime ではなく react)。
• 新しい hook の中で旧 hook の mental model が見える。
• エラーメッセージが新バージョンのシグネチャと一致しない(これは旧 API を仮定した try/catch という意味)。

この3つのうちどれか1つでも見えたら新しいセッションを始め、新しい docs をより強い口調で再注入。

第7章 · マルチリポ cross-cutting 変更 —— 「依然として難しい」

パターン

40個のマイクロサービスで同じ変更(例えば deprecated SDK 1.x から 2.x へ)をしなければならない。エージェントは1つ目のリポをうまくやる。2つ目もうまくやる。5つ目で 各リポが持つ微妙な違い(テストランナーの違い、ビルドシステムの違い、依存バージョンの違い)を捉えられない。PRを40個開くが、そのうち12個はビルドが壊れたまま上がる。

なぜそうなるか

各リポは独自の 隠れたコンテキスト を持つ。マルチリポ変更は本質的に N個のコンテキスト を扱うことなのに、LLMのコンテキストウィンドウは1つだ。エージェントは1つのリポでの決定を別のリポに一般化しようとする —— それが効かない部分で失敗する。

さらにマルチリポは 依存関係グラフ だ。Aを変えるにはBを先にデプロイしなければならず、それにはCが互換である必要がある。このグラフ推論は単一のコンテキストではうまくいかない。

人がやり続けるべきこと

• 1つのリポでパターンを定着させてから他のリポに広げる。 最初の5個は人が直接、残りはエージェント + 人間レビュー。
• 共通変更は codemod として書く。 AST変換 + AIレビューが純粋なAIより安定的。
• デプロイ順序は人が持つ。 エージェントは依存関係グラフ推論に弱い。

第8章 · セキュリティクリティカルなコード —— 「正しく見えるが、微妙な欠陥がある」

パターン

エージェントがパスワードハッシュ関数を書く。bcrypt を使い、salt は random から取る。見た目は定石だ。しかし タイミング攻撃に脆弱な比較(== ではなく constant_time_eq を使うべき)、salt rounds の cost factor が 8(2026年基準では 10〜12 推奨)、エラーメッセージが username を echo する(timing leak)。すべて微妙で、コードレビューで捕まえられない可能性がある。

なぜそうなるか

セキュリティは negative space の学問だ —— 「あるべきものが無いと欠陥」。LLMは「あるもの」を見て推論する。「無いもの」を捕えるにはセキュリティの mental model が必要だ。エージェントの mental model は平均的で、専門家レベルではない。

さらにセキュリティの vulnerability は 遅い発見 だ。6か月後にインシデントが起きてようやく見える。その時点ではエージェントは別の仕事をしている。

人がやり続けるべきこと

• セキュリティクリティカルなコードはセキュリティ専門家のレビューが必須。 AIレビューは補助。
• 自動化ツール(semgrep、bandit、gosec、cargo-audit)を強制する。AIより決定的だ。
• AGENTS.md に「セキュリティリスク」セクション を明示。「このディレクトリのコードは常に人間のセキュリティレビュー」と書き込む。

よく見落とす negative space リスト

エージェントコードのセキュリティレビューでチェックする項目:

• timing-safe な比較が使われているか
• 秘密鍵がログに入り得るか
• エラー応答が timing oracle を作るか
• rate limit がすべての path に掛かっているか
• input validation が sanitization の直前ではなく直後にあるか
• CSRF/CORS が明示的に設定されているか(デフォルト依存ではなく)

この6項目を PR テンプレートに埋め込めばセキュリティ回帰の 80% は捕まる。残り 20% が専門家レビューの領域だ。

第9章 · レガシーコード —— 「コードが『知っている』ことをコードが『書いていない』」

パターン

15年もののモノリスの一関数が変な形をしている。変数名が magic_offset_42 だ。エージェントは「これは整理すべき」と判断してリファクタする。デプロイする。1か月後、古いデータマイグレーションパイプラインが死ぬ。見ると、magic_offset_42 は 2012 年のデータベースマイグレーション事故で生まれた off-by-one 補正 だった。コードはそれを書かなかった。しかし コードはそれを知っていた。

なぜそうなるか

レガシーコードは 暗黙知の圧縮 だ。コードがそういう形をしている理由はしばしばコード自体には書かれていない —— Slack のどこかのチャネル、辞めたエンジニアの頭の中、5 年前の事故報告書に書かれている。LLM は コードしか見ない。

これは RAG でも解決しない。事故報告書が検索されても、それがこのコード行と接続される必要があることをモデルが推論しなければならない —— その接続がしばしば発火しない。

人がやり続けるべきこと

• レガシーコードには「リファクタ禁止」マーカーを付ける。 コメントで、または別ファイルで。
• git blame + 変更履歴 をエージェントに強制注入。「この行をなぜこう書いたか知りたければ、コミット履歴を見ろ」。
• レガシーコードの変更は常に人が一度見る。 自動リファクタは危険。

第10章 · 長セッションのプロンプトドリフト —— 「エージェントがゆっくり糸を放す」

パターン

8時間のエージェントセッション。最初の1時間は申し分ない。4時間ほど経つとコードスタイルが 変になる —— 変数命名規約が少し変わり、エラー処理パターンがわずかに違い、コメントが薄くなっていく。7時間頃には最初の指示を 忘れたかのように 振る舞う。

なぜそうなるか

コンテキストが長くなるほどモデルは 序盤の instructions よりも 最近のツール結果 に重みを置く。これが本質的な attention dilution だ。さらに自動コンテキスト圧縮(summarization)を使うと、圧縮過程で微妙な情報が消える。結果としてモデルは 自分が誰か をゆっくり忘れる。

これはモデルサイズで完全には解けない。200K、1M、10M のコンテキストが来ても —— 相対的な attention はそのままだ。

人がやり続けるべきこと

• セッションを短く保つ。 大きな仕事は複数セッションに分ける。各セッションは明確な input と output を持つ。
• AGENTS.md を毎回再注入。 システムプロンプトがあっても、重要な規約は明示的に再度伝える。
• drift を見たら新しいセッションを始める。 未練を持つな。コンテキストリセットは最強のツールだ。

drift を測る一行ヒューリスティック

セッション開始時点で「この作業の3つの核となるルールを一行ずつ言え」と聞いて答えをメモしておく。4時間後に同じ質問を再度投げる。答えが変わっていれば drift だ。答えは同じでもコードスタイルが変わっていれば部分 drift だ。いずれの場合も新しいセッションを始める。

第11章 · では AI は何が得意か(対照群)

この記事は AI 否定ではない。AI が 明確に multiplier な領域を明示しなければ公平ではない。

AI が光るタスク

• ブートストラップ —— 新プロジェクトの scaffold、ボイラープレート、馴染みのあるパターンの最初の100行。
• 明確に定義された単一タスク —— 「この関数を TypeScript に変換」「この SQL を ORM コードに」「このテストの欠けたケースを追加」。
• 読み・要約・説明 —— 1000行のファイルを 200 行に要約、ビルドログから本当のエラーを見つける、PR 変更の意図を説明。
• 反復的なマイグレーション(明確に定義されている) —— 一貫した codemod として表現可能な変更。
• テスト作成 —— 特に input/output の形が明確な unit test。
• ドキュメント生成 —— コードから docstring、README ドラフト、API 仕様。
• 馴染みのあるデバッグ —— null pointer、off-by-one、よくあるトランザクション漏れのようなパターンの認識。

これらの領域で AI は 3x〜10x の multiplier だ。否定する理由がない。

AI が人間より速い領域

• タイピングそのもの —— キーボード入力は無条件で速い。
• API surface を覚えること —— 人間がマニュアルをめくる時間をゼロに。
• フォーマット変換 —— JSON ↔ YAML、schema ↔ TypeScript、REST ↔ GraphQL。
• 翻訳 —— 自然言語、コード言語の両方。

第12章 · 「AI が光る領域」vs「人間が掛け算する領域」マトリクス

このマトリクスがメッセージだ。「AI を使うか否か」 ではなく 「このタスクのどこで人間が multiplier か」 を問う。

第13章 · アンチパターン —— よく見る間違い

アンチパターン 1: 「エージェントが8時間同じ仮説を追っているのにそのままにする」

止めて仮説を疑う。人間デバッガの第一ルール。

アンチパターン 2: 「AI が書いたセキュリティコードを人が見ない」

セキュリティは negative space。自動ツール + 専門家レビューは非交渉。

アンチパターン 3: 「大きなコードベースで『feature X を追加して』と1行指示する」

エージェントは断面を見る。「似たものがあるか先に検索」を強制。

アンチパターン 4: 「エージェントの性能リグレッション目視を CI なしで信じる」

リグレッションは決定的な測定で捕まえる。AI の測定は補助。

アンチパターン 5: 「長セッションをそのままにする」

4時間を超えたら drift を仮定。セッションを分ける。

アンチパターン 6: 「新ライブラリで RAG だけ信じる」

RAG は weight prior を上書きしない。自分でパターンを一度書いてから委任。

アンチパターン 7: 「レガシーコードのリファクタをエージェントに丸投げ」

レガシーは暗黙知。人間レビューが必須。

アンチパターン 8: 「エージェントが書いた並行性コードをユニットテストだけで検証」

レースはユニットテストでは捕まらない。ThreadSanitizer、loom。

アンチパターン 9: 「チーム規約を AGENTS.md に書かない」

エージェントは知らなければ推測する。明示化が multiplier。

アンチパターン 10: 「AI の結果を PR 自動マージで通す」

人間レビューが最後の安全網。自動マージは信頼を安く買いすぎる。

第14章 · 開発者チェックリスト(較正ツール)

タスク開始前:

• このタスクの 失敗モード は上の10個のどれに該当するか?
• 人間レビューが必要な段階はどこか?(PR? デザイン? マージ前?)
• 自動化の安全網(CI、lint、SAST)が埋め込まれているか?
• AGENTS.md にチーム規約が明示されているか?
• 新しいライブラリ/API が含まれるなら —— 自分でパターンを一度書いたか?
• マルチリポ変更なら —— 最初の 1〜2 個は手でやるか?
• セキュリティ/並行性/性能クリティカルな部分が含まれるか? 専門家レビューのスケジュールがあるか?

タスク中:

• 同じ仮説を 4 時間以上追っていないか?
• セッション長が 4 時間を超えたか? drift 点検。
• エージェントが「旧 API パターン」に回帰していないか?

タスク後:

• 結果を人間が一度読んだか?
• 性能リグレッションテスト、セキュリティスキャンが回ったか?
• マルチリポなら —— 各リポのビルドがすべて通ったか?

エピローグ —— multiplier としての開発者

繰り返すが、この記事は AI 懐疑論ではない。

AI コーディングアシスタントは本当に multiplier だ。 しかし multiplier は ゼロでない値に掛けられたときだけ意味を持つ。 その「ゼロでない値」があなたの判断だ。

判断が 0 なら —— つまりタスクを 100% エージェントに任せて結果を検査しなければ —— どんな multiplier でも 0 を掛ければ 0 だ。時にはマイナスだ。(エージェントが難しく間違えたコードを整理する方が、最初から書くより時間がかかる。)

判断が 1 なら —— つまり上の10の失敗モードを知り、適切に安全網を設置し、仮説トンネリングを破り、セッションを分け、セキュリティ/並行性/性能を適切に人に渡すなら —— その時はじめて AI は本当の multiplier になる。

2026年中盤の開発者に最も重要なスキルは AI を疑う能力 ではなく、AI の信頼区間を正確に推定する能力 だ。

AI コーディングアシスタントの能力は爆発的に良くなる。しかし上の10の失敗モードのうちいくつかは モデルサイズでは解決されない だろう。仮説トンネリング、暗黙知、チーム好み、セキュリティの negative space —— これらは 人のコンテキスト が必要だ。そのコンテキストはしばらく人の頭の中だけにある。

あなたの仕事は減らない。形が変わる。 コードをタイプする時間が減り、何を信頼するか決める時間 が増える。それが multiplier としての開発者の形だ。

次回予告

• 「AI コードの PR レビュー —— 人間レビュアーが見るべき7つのシグナル」 —— AI コードはどこが疑わしいか、どのパターンが「通過後の事故」につながるか、PR レビューチェックリスト。
• 「AGENTS.md の書き方 —— チーム規約をエージェントに教える」 —— 実際に効く AGENTS.md の例、どんな情報が効果ありでどれがノイズか。

参考 / References

ベンチマークと評価

• SWE-bench Verified leaderboard —— https://www.swebench.com/(エージェント性能の天井を追跡)
• OSWorld benchmark —— https://os-world.github.io/(デスクトップ環境タスクの限界)
• MLE-bench —— https://github.com/openai/mle-bench(ML エンジニアリング作業のエージェント評価)
• HumanEval と LiveCodeBench —— 単純関数作成能力と実際のエンジニアリング能力のギャップ

Context rot, hypothesis tunneling, attention dilution

• 「Lost in the Middle」—— Liu et al., 2023、長コンテキストの attention dilution を最初に定量化した論文
• 「Context Rot」—— Anthropic、Claude 4 シリーズの long-context degradation 分析
• 「Confirmation Bias in LLM-based Agents」—— 最近の評価研究で繰り返し報告されているパターン

並行性とセキュリティの LLM 限界

• 「LLMs and Concurrency: A Survey」—— 2025年研究、formal verification が依然として必要な理由
• 「Security Implications of Code Generated by LLMs」—— Pearce et al., 2025 年更新、common CWE での頻度

実用ガイドと意見

• Simon Willison's blog —— https://simonwillison.net/ —— calibrated take の模範
• 「When AI Coding Assistants Fail」—— 様々なエンジニアリングブログの失敗事例集
• Anthropic の「Best practices for agentic coding」—— 公式ガイド、失敗モードを明示

ツール

• Claude Code、Cursor、Codex CLI —— 本文言及
• semgrep、gosec、bandit —— セキュリティ自動化ツール(AI 補助用)
• ThreadSanitizer、loom —— 並行性検証ツール
• TLA+ —— 形式検証

TL;DR —— AI コーディングアシスタントは強力だが一様ではない。深いデバッグ・アーキテクチャ・性能リグレッション・並行性・セキュリティ・レガシー・曖昧さ・新技術・マルチリポ・長セッション —— この10の領域で人間の判断は依然として multiplier だ。AI を疑うな。AI の信頼区間を正確に推定しろ。それが 2026 年中盤の開発者の最も価値あるスキルだ。