AIコーディング — 方法論とベストプラクティス
コード補完からエージェントまでの3世代、Vibe CodingとAgentic Engineering、12の主要ツール、SWE-bench/Aider/Terminal-Bench、CLAUDE.md/AGENTS.md、セキュリティリスクまで。すべて公式情報源と出典URL併記。
AIによるコーディング支援は、2026年5月時点で「実験段階」を完全に抜け、開発者の日常に組み込まれました。Stack Overflow の 2025 年開発者調査（177カ国 49,000名超）では 84% の開発者が AI ツールを使っているか使う予定 と回答しており、約半数が日常的に使っていると報告されています（出典：2025 Stack Overflow Developer Survey: AI / 解説は 第8章 8.5節）。一方で、ツールは乱立し、用語は流動的で、何を選びどう使うべきかの判断は難しくなる一方です。
本章は 方法論とベストプラクティス を主軸に置きます。ツールの紹介や Vibe Coding 論争もカバーしますが、最終的に読者が手にすべきは「何を AI にさせ、何を人間が守るか」という再現可能な型です。すべての事実主張に、可能な限り公式・一次情報の出典URLを併記しています。
AIコーディングの全体像 — 3世代の整理
AIコーディングは断絶を伴いつつ3世代を経てきました。
| 世代 | 主役 | 何ができる | 人間の関与 |
|---|---|---|---|
| 第1世代：コード補完 | GitHub Copilot 初期、Tabnine | 次の数行を補完 | ほぼすべて人間。AIは「賢い補完」 |
| 第2世代：ペアプロ | Cursor、Windsurf、Copilot Chat | ファイル単位の生成・修正、対話的支援 | 人間が主導、AIが相棒 |
| 第3世代：エージェント | Claude Code、Cursor Agent、Devin、Codex CLI | タスク分解・実行・テスト・コミットまで自律 | 人間は監督者・オーケストレーター |
第1世代から第2世代へは 2022 年後半の ChatGPT 公開 が境界、第2世代から第3世代へは 2024-2025 年の Claude Code / Cursor Composer / Devin の登場 が境界です。
重要なのは、新世代が前世代を駆逐するわけではない ということ。2026 年の実務では「補完」「ペアプロ」「エージェント」を1日のなかで切り替えて使うのが標準的な姿になっています。短い関数は Tab 補完、複数ファイルの整合修正はチャット、半日かけるリファクタはエージェント、というように。
Vibe Coding — Karpathy原典と論争
起源と原典
「Vibe Coding」という言葉は、Andrej Karpathy（OpenAI共同創業者、元Tesla AI責任者）が 2025年2月2日 にX（旧Twitter）で投稿したのが原典です18 。
原文の核心：
“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”
Karpathy 自身は具体的なワークフローとして、SuperWhisper（音声入力）でCursor Composerに話しかけ、生成されたdiffを読まず常に「Accept All」を押し、エラーメッセージをそのままコピペで投げ返し、修正できなければ回避策で迂回する という、極めて「コードを見ない」スタイルを描写しています。投稿の結びは「Not too bad for throwaway weekend projects, but still quite amusing.（捨ててもいい週末プロジェクトには悪くない、なかなか面白い）」。
出典：Karpathy原ポスト（2025-02-02） / Wikipedia: Vibe coding
Karpathy 本人は後に「これは shower of thoughts throwaway tweet（シャワー中の思いつきを投げ捨てただけのツイート）」と振り返っており、プロダクション用途として推奨したわけではない ことが繰り返し強調されています。
業界の解釈と論争の年表
| 時期 | 出来事 | 出典 |
|---|---|---|
| 2025-02 | Karpathy 原ポスト（4.5M超View） | X |
| 2025-03 | Simon Willison が「Not all AI-assisted programming is vibe coding」を投稿し、定義の希釈に警鐘 | simonwillison.net |
| 2025-04 | MIT Technology Review が分析記事「What is vibe coding, exactly?」を掲載 | technologyreview.com |
| 2025-05 | LangChain Interrupt カンファレンスで Andrew Ng が用語を批判 | IT Pro |
| 2025-11 | Collins English Dictionary が Word of the Year 2025 に選出 | Collins公式 / CNN |
| 2026年初頭 | Karpathy が Sequoia Ascent 2026 で「agentic engineering」を提示、vibe coding との線引きを公式化 | karpathy.bearblog.dev |
定義の主要な分岐
Vibe Coding の定義は提唱者と批評家で揺れています。
vibesに身を委ねる
「vibesに完全に身を委ね、指数関数的進歩を受け入れ、コードの存在自体を忘れるコーディング」。Karpathy本人による命名時の定義。
レビューしない場合のみ
「LLMが書いたコードをレビューせずに ソフトウェアを構築すること」。レビュー・テスト・理解を伴えばそれは vibe coding ではなく「LLMをタイピングアシスタントとして使った通常のAI支援プログラミング」だと区別。
自然言語での開発
「自然言語によるAIへの指示でソフトウェアを開発する手法」。最も広く一般向けの定義。
実務上は Willisonの厳密定義 が最も実用的です。「レビューするかしないか」で運用ルールがまったく変わるからです。
定量データ — Vibe Coding の限界
「Vibe Coding は楽しいが本番非推奨」という論調を裏付けるデータが、2025〜2026 年に複数報告されています。
| 報告 | 内容 | 出典 |
|---|---|---|
| Lovable プラットフォーム調査（2025-05） | Lovableで構築された1,645個のアプリのうち約170個（約10%）が個人情報漏洩脆弱性を持つことが判明 | Wikipedia |
| METR ランダム化試験（2025-07） | 熟練開発者は AI ツール使用時に 19% 遅くなった | Wikipedia |
| Veracode 報告（2025-10） | AI 生成コードは機能性は向上するがセキュリティ品質は追いついていない | Wikipedia |
| CodeRabbit 調査（2025-12） | AI 生成コードは人が書いたコードに比べ「major issues」が 1.7倍 多い | Wikipedia |
日本における議論
日本のエンジニアコミュニティでも 2025 年春以降、Qiita・Zenn・note で多数の論考が投稿されました。海外のような熱狂的賛否対立より、「使い分け論・現実主義」のトーンが目立つのが特徴です。
- 「Vibe Codingは『革命』か『罠』か」: 革命派と懐疑派を整理し「使い方次第のツール」と結論 — Qiita
- 「【大論争】Vibe Codingは革命か？それとも開発者を殺すのか？」 — Zenn
- 國末拓実「バイブコーディングについてのまとめ」（國末はアンドデジタル Chief AI Evangelist）: 「初心者には絶対お勧めできない」という慎重論 — note
- 「AI時代の技術的負債『Vibe Fixing』」: セキュリティと保守性への警鐘 — Qiita
日本固有の論点として、「ほぼ正しいが完全には正しくない」コード修正のコスト（“生産性税”） や、独自概念 「Safe Vibe Coding」「Vibe Fixing」 の派生があります。
Agentic Coding / Engineering — Karpathy再定義
Karpathy の新フレームワーク（Sequoia Ascent 2026）
2026年初頭、Karpathy 自身が Sequoia Ascent 2026 で Vibe Coding と Agentic Engineering の線引きを公式化しました。
“Vibe coding is about raising the floor for everyone in terms of what they can do in software. Agentic engineering is about preserving the quality bar of professional software.”
- Vibe Coding = 床を上げる（誰もが作れるようにする）
- Agentic Engineering = 天井を上げる（プロが品質を保ったまま桁違いに速くなる）
「agentic」とは「あなたが99%の時間コードを直接書くのではなく、エージェントをオーケストレーション・監督する立場である」こと、「engineering」とは「そこには技芸と科学と専門性が存在する」ことを示すための語選択、と Karpathy は説明しています。
出典：Karpathy: Sequoia Ascent 2026 / The New Stack
対立か補完か
両者は対立というより 階層的補完 です。同じ「LLMでコードを生成する」行為でも、
| 観点 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 用途 | 週末プロジェクト、PoC、個人ツール、ゲーム | 業務システム、SaaS、本番ソフトウェア |
| レビュー | 不要（Accept All） | spec / plan / diff / test / permission / worktree すべてを監督 |
| 失敗時 | 捨てればよい | 説明責任あり |
| 主体 | 「コードの存在を忘れる」 | 「エージェントを指揮する」 |
ただし Simon Willison は 2026年5月のブログで「両者の境界が望ましくないほど近づいてきている」と警鐘を鳴らしています — エージェントの自律性が増し、専門家でも全diffをレビューしきれなくなりつつある、という観察です。
出典：Simon Willison: Vibe coding and agentic engineering（2026-05-06）
Agentic Coding の仕組み
エージェント型コーディングツールは、内部で次のループを回します。
[ユーザー指示]
↓
[計画立案] — タスクを分解、ファイル特定、変更方針を決定
↓
[ツール呼び出し] — read_file / write_file / bash / grep / web_search 等
↓
[結果観察] — 実行結果・エラー・差分を読み取る
↓
[内部評価] — 計画通りか、追加対応が必要か判断
↓
[繰り返し] — 完了条件まで上のループを継続
↓
[完了報告 / コミット]この構造は 第5章 5.5節 で紹介した ReAct（Reasoning + Acting）の実装版です。Claude Code、Cursor Agent、Devin、Codex CLI などはすべてこの系統に属します。
主要ツール比較（2026年5月時点）
12の主要ツールを、提供形態・料金・差別化機能で整理します。料金はUSD、2026年5月時点の公式情報 に基づきます。日本円表記は公式に記載がある場合のみ。
比較表
| ツール | 提供形態 | ベースモデル | 料金（USD） | 差別化 |
|---|---|---|---|---|
| Cursor | IDE / CLI / Web | Claude / GPT / 独自Tab | Hobby無料 / Individual $20〜 / Teams $40 / Enterprise | Tab補完精度、Composer 2.5、Cloud Agent、Bugbot |
| Claude Code | CLI / IDE / Web / Slack | Claude | Pro $17 (年) or $20 / Max $100 / Max $200 | agentic search、長期コードベース理解、ローカル実行 |
| Windsurf | IDE（VSCodeフォーク） | SWE-1.6 + 主要モデル | Free / Pro $20 / Max $200 / Teams $40 | Previews、Devin Cloud統合 |
| GitHub Copilot | IDE / CLI / Web / Mobile | GPT-5 / Claude / Codex選択可 | Free / Pro $10 / Pro+ $39 / Business / Enterprise | GitHub深い統合、外部Agent割当、Workspace |
| Aider | CLI（OSS） | 任意LLM | 無料（API課金別） | Git自動コミット、コードベースマップ、自動lint/test |
| Cline（旧Claude Dev） | IDE拡張 / CLI / SDK | 任意LLM | OSS無料 / Enterprise | Plan-and-Act、MCP、複数モデル |
| Bolt.new | Web | 自動ルーティング | Free / Pro $25 / Teams $30 | ブラウザWebアプリ高速生成、Figmaインポート |
| v0 (Vercel、現 v0.app) | Web / iOS | v0 Mini/Pro/Max | Free / Team $30 / Business $100 | UI生成→Vercelデプロイ、Design Mode |
| Devin (Cognition) | Web / API | 独自 | Free / Pro $20 / Max $200 / Teams $80 | フル自律エージェント、Linear/Jira統合 |
| Replit Agent | Replit統合 | 複数 | Free / Core $20 / Pro $95 | クラウドIDE直結デプロイ |
| OpenAI Codex | CLI / IDE / Web | GPT-5.3-Codex 等 | ChatGPTプラン同梱（$20〜）+ APIトークン課金 | ChatGPT統合 |
| Continue.dev | IDE拡張 + PR SaaS | 任意 | Starter $3/Mトークン〜、Team $20/seat | PR自動チェック |
出典（各公式URL）：
- Cursor: cursor.com/pricing
- Claude Code: claude.com/product/claude-code
- Windsurf: windsurf.com/pricing
- GitHub Copilot: github.com/features/copilot/plans
- Aider: aider.chat
- Cline: cline.bot/pricing
- Bolt.new: bolt.new/pricing
- v0: v0.app/pricing
- Devin: devin.ai/pricing
- Replit: replit.com/pricing
- Codex: developers.openai.com/codex/pricing
- Continue.dev: continue.dev/pricing
シナリオ別の使い分け
「最強」を追うより、シナリオに合った最小構成 を選ぶのが2026年の現実解です。
| シナリオ | 推奨ツール | 理由 |
|---|---|---|
| 個人趣味 | Cursor Hobby / Copilot Free / Aider | 無料枠で完結。OSS派ならAider |
| 個人プロ開発者 | Claude Code Pro ($17) / Cursor Pro ($20) | エージェント機能、コードベース理解、価格妥当 |
| 小規模チーム | Cursor Teams ($40) / Windsurf Teams ($40) / Bolt Teams ($30) | チーム共有ルール・課金一元化 |
| 大企業 | Claude Code Enterprise / Copilot Business+Enterprise / Devin Enterprise / Cursor Enterprise | SAML SSO、SCIM、監査ログ、VPC、SLA |
| プロトタイプ高速作成 | Bolt.new / v0 / Replit Agent | ブラウザ完結でUI〜デプロイまで一貫 |
| 既存大規模コードベース改修 | Claude Code / Cursor / Aider | agentic search、大規模コンテキスト、コードベースマップ |
方法論 — Explore → Plan → Implement → Commit
ここからが本章の中核です。「何を AI にさせ、何を人間が守るか」 の再現可能な型を整理します。
Anthropic 公式ベストプラクティスの4フェーズ
Anthropic の公式ドキュメント「Best practices for Claude Code」は、中核ワークフローを4フェーズで定義しています（公式記載：“The recommended workflow has four phases: Explore, Plan, Implement, Commit”）。
1. Explore — コードベース・既存パターン・関連ドキュメントを読む（plan mode）
2. Plan — 変更の方針・影響範囲・検証方法を立てる（plan mode）
3. Implement — 実際にコードを書く・書かせる（default mode）
4. Commit — 変更を確定し、PRを作成する公式は「コーディングに飛びつくと 間違った問題を解いてしまう 可能性がある」と指摘し、4フェーズを意識的に分離することを推奨しています。
出典：Anthropic公式: Best practices for Claude Code
「検証可能な成功条件」を与える
Anthropic 公式は 「Give Claude a way to verify its work（Claude に作業を検証する手段を与えよ）」 を独立した見出しで強調しています。
“Give Claude a check it can run: tests, a build, a screenshot to compare. It’s the difference between a session you watch and one you walk away from.”
（Claude に実行できるチェックを与えよ：テスト、ビルド、比較対象のスクリーンショット。目を離せないセッションと、立ち去れるセッションを分ける違い）
具体的に有効とされる検証手段は次の通りです（公式記述に基づく）：
- テストスイート
- ビルドの exit code
- linter
- 期待出力との diff スクリプト
- スクリーンショット比較
実装例：
# プロンプトに含めるべき検証条件の例
- npm test を実行し、すべて pass すること
- npm run typecheck で型エラーゼロ
- npm run lint で警告ゼロ
- 主要ユースケースのスクリーンショットを撮影し、design.png と一致すること
- 既存テストの修正は禁止。新規追加のみ可検証条件を強制する手段として、Anthropic 公式は次の4段階を提示しています：
- 同一プロンプト内で実行：プロンプトで「実行してiterateせよ」と指示
- セッション全体のゴール：
/goal機能で、別の評価モデルが各ターン後に検証 - 決定論的なゲート：Stop hook をスクリプトで実装し、検証通過まで終了をブロック
- セカンドオピニオン：検証用 subagent または dynamic workflow で別モデルが反証を試みる
出典：Anthropic公式: Best practices for Claude Code（“Give Claude a way to verify its work”セクション）
TDD と AI — 失敗テスト先行のコミットロック
公式ベストプラクティスのなかには、Writer/Reviewer パターン（別セッションが書いたコードを別セッションがレビューする）と 一方のセッションでテストを書かせ、別セッションで実装コードを書かせる という運用が紹介されています。これを TDD 的に展開すると、次のパターンが実用的です（コミュニティで広く共有されている運用知）：
- 失敗するテストをまず書かせ、commit する（このコミットがチェックポイント）
- プロンプトで「テストを変更してはならない」と明示
- 実装コードのみを書かせ、テストが pass するまでループ
- pass したら別コミット
Claude や Codex はそのままだと 「テストを書き換えて pass させる」 傾向があるため、失敗テストの commit による固定が有効です。Anthropic 公式は「Have Claude show evidence rather than asserting success（成功を宣言させるのではなく、証拠を見せさせよ）」と表現しています。
出典：Anthropic公式: Best practices for Claude Code（“Use multiple Claude sessions”の Writer/Reviewer 表） / 補足解説：DataCamp チュートリアル
Andrew Ng の 4 デザインパターン
DeepLearning.AI の Andrew Ng は、エージェント型 AI の4デザインパターンを提唱しています。これらは Claude Code・Cursor Agent・Devin など主要エージェント系ツールが内部で組み合わせているパターンの整理にも使えます。
| パターン | 概要 | コーディングでの実装例 |
|---|---|---|
| Reflection | 出力を自己評価し改善 | 生成コードを Lint/Test に通して結果を読み、修正 |
| Tool Use | 外部ツールを呼ぶ | bash、ファイル編集、Web検索、テスト実行 |
| Planning | 多段階の計画を立てる | タスクを分解、依存関係を整理、順序を決定 |
| Multi-Agent | 複数エージェントの協調 | 探索担当 + 実装担当 + レビュー担当の分業 |
Ng は「成功の最大予測因子は技術力ではなく、規律ある evaluation プロセスを回せること」を繰り返し強調しています。Build と Analyze の2モードを行き来し、出力を観察して metric を立てよ、というメッセージです。
出典：DeepLearning.AI: Agentic AI コース / コース解説
Context Engineering — Prompt Engineering の進化形
Karpathy（2025-06）と Shopify CEO の Tobi Lütke は、ほぼ同時期に「prompt engineering より context engineering と呼ぶべき」と発信しました。Anthropic 公式も「Effective context engineering for AI agents」（2025-09-29、Anthropic Applied AI team）と題したエンジニアリング記事を公開し、context engineering を次のように定義しています。
“Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all information that may land there outside of prompts.”
（context engineering とは、LLM 推論時に 最適なトークン集合を選定・維持する一連の戦略 — プロンプトの外側に入りうるすべての情報を含む）
Drew Breunig が「How to Fix Your Context」で整理した コンテキスト管理の代表的技法 が実用的です。LangChain の公式ブログでも引用されている分類です。
文脈の隔離
各タスクを専用スレッドに隔離し、機密データやノイズの多い文書を主文脈から分離する。Indirect Prompt Injection 対策にもなる。
文脈の要約
長い会話履歴やコードベース全体を、エージェントに要約させてから次のステップに渡す。
文脈の外部化
詳細をファイルや外部DBに置き、エージェントは必要な時だけツール呼び出しで参照する。CLAUDE.md / AGENTS.md はこの実装。
Breunig は同記事で、コンテキストが長くなることで起きる失敗モードを Context Poisoning（汚染）／Distraction（散漫化）／Confusion（混乱） の3類型に整理し、上の技法がそれぞれの対策になると示しています。
出典：Drew Breunig: How to Fix Your Context（2025-06-26） / LangChain: Context Engineering for Agents / Simon Willison: Context engineering（2025-06-27） / Anthropic Engineering: Effective context engineering for AI agents / Karpathy ツイート（2025-06）
ベストプラクティス — コンテキストファイルと操作の型
CLAUDE.md / AGENTS.md / Cursor Rules — 同じ思想の方言
主要エージェントは、プロジェクトルートに 「常に読まれる文脈ファイル」 を置く規約を持っています。同じ思想（プロジェクト固有の知識を会話開始時に必ず渡す）の異なる実装です。
| ファイル | 主読者 | 配置 | 出典 |
|---|---|---|---|
CLAUDE.md | Anthropic Claude Code | プロジェクトルート＋階層的、~/.claude/CLAUDE.md で global | Anthropic公式 |
AGENTS.md | OpenAI Codex / Amp / Google Jules / Cursor / Factory（オープン標準） | ルート＋階層、override 可 | agents.md / OpenAI公式 |
.cursor/rules/*.mdc | Cursor（現行推奨） | プロジェクト、複数・スコープ可、frontmatter で適用条件指定 | Cursor公式 |
.cursorrules | Cursor（旧形式） | ルート単一ファイル。新規プロジェクトでは .mdc 形式が推奨 | 同上 |
.github/copilot-instructions.md | GitHub Copilot | リポジトリ | GitHub Copilot 公式ドキュメント |
AGENTS.md は OpenAI、Amp、Google Jules、Cursor、Factory が共同で策定したオープン標準で、現在は Linux Foundation 配下の Agentic AI Foundation が運営しています。Codex は実行のたびに ~/.codex/AGENTS.override.md → ~/.codex/AGENTS.md → プロジェクトルートから cwd まで各階層の AGENTS.override.md / AGENTS.md をチェーン状に読みます。
推奨セクション
主要エージェントが共通で期待する CLAUDE.md / AGENTS.md の推奨セクションを、テンプレートとして示します。
# プロジェクト名
## 概要
（このリポジトリが何で、誰のためのものか、3行）
## 技術スタック
- 言語・フレームワーク・主要ライブラリ
- パッケージマネージャ（npm / pnpm / uv / cargo）
## ビルド・テスト・lint コマンド
- `npm install` — 依存導入
- `npm run dev` — 開発サーバ起動
- `npm test` — テスト実行
- `npm run lint` — lint
- `npm run typecheck` — 型チェック
## コーディング規約
- 命名（kebab-case / camelCase / PascalCase）
- インポート順序
- コメント方針（書く / 書かない / どこに書く）
## ディレクトリ構成
- src/components: UIコンポーネント
- src/lib: 純粋関数とドメインロジック
- src/pages: ルーティング
## PRフォーマット
- タイトル: `[領域] 簡潔な動詞 + 名詞`
- 本文: 何を、なぜ、テスト方法
## 禁止事項
- node_modules への直接編集
- src/lib/legacy/ 配下への新規追加
- API キーを .env 以外に書く
## セキュリティ注意点
- 機密情報（API キー、トークン、個人情報）を context に含めない
- 公開 PR でシークレットを含む差分を作らないCursor の @ シンボル — 文脈指定の体系化
Cursor は @ シンボル で文脈を細かく指定する仕組みを公式に体系化しています。
| @記号 | 何を指す |
|---|---|
@Files | 特定ファイル |
@Folders | ディレクトリ |
@Code | コード内シンボル |
@Docs | 外部ドキュメント（事前登録） |
@Codebase | インデックス全体の検索 |
@Web | Web検索結果 |
これらは Rules ファイル .mdc の中でも @myfile.ts のように参照可能です。
出典：Cursor Rules公式 / Cursor: @ symbols
サブエージェントによる「探索」と「実装」の分離
Anthropic 公式は、サブエージェントで「探索」と「実装」のコンテキストを分離する ことを推奨しています。
理由：探索フェーズで膨大なファイルを読むと、実装フェーズの限られたコンテキストが埋まってしまう。サブエージェント（独立した会話セッション）に探索を任せ、要約だけを実装エージェントに渡せば、コンテキストの汚染が防げます。
Geoffrey Huntley の Ralph Loop と spec ドリブン
Geoff Huntley（元 Canva AI Developer Productivity Tech Lead）は、spec → 小ループでの実装 → 自動検証 を機械化することで人間が一桁多くのコードを正しく出荷できる、というアプローチを提唱しています。
具体的なメタは 「Ralph Wiggum Loop」：bash の while true で AI 出力をフィードバックさせ続ける極めてシンプルなループ。Huntley は Claude を3ヶ月この Ralph ループで回し続け、独自のプログラミング言語「cursed」を作り上げたと報告しています。
出典：From Design doc to code: the Groundhog AI coding assistant / everything is a ralph loop / i ran Claude in a loop for three months / the six-month recap（Web Directions 2025講演）
Huntley は Web Directions 2025 講演「the six-month recap」で vibe coding を次のように定義しています。
“For complex systems, ‘vibe coding’ (shipping unverified AI output) is reckless.”
（複雑系では、検証されない AI 出力を出荷する vibe coding は無謀である）
「責任ある AI 開発」は spec と検証で囲い込まれた loop の中でこそ成立する、という立場です。
John Lindquist — rich context と stop hooks
John Lindquist（egghead.io 共同創設者・現 Vercel AI DX）は、clever prompt より rich context を強調しています。Mermaid 図でアプリ全体を圧縮表現させ、stop hooks で自動品質チェック / commit を回す、という具体的なワークフローを Claude Code Workshop で示しています。
出典：egghead.io: Claude Code Workshop / Lenny’s Newsletter ポッドキャスト
評価軸 — ベンチマークの読み方
ベンチマークは「ツールの能力」を測るための重要な指標ですが、1つのベンチを見て全能力を判定するのは危険 です。それぞれが「何を測り、何を測らないか」を理解する必要があります。
SWE-bench 系 — 実 GitHub Issue を解けるか
SWE-bench（Princeton / U. Chicago、Jimenez et al., 2023）19 は、12 の Python OSS リポジトリ（Django, Flask, scikit-learn, sympy 等）から実 GitHub Issue × PR ペア 2,294件 を抽出。エージェントはコードベース + Issue 本文を受け取り、隠された fail_to_pass テストが通り、かつ pass_to_pass テストが回帰しないパッチを生成する、という設計です。
公開当時 SOTA の Claude 2 が 1.96% しか解けず、その後 SWE-bench の派生が複数生まれました。
| バリアント | サイズ | 特徴 | 出典 |
|---|---|---|---|
| SWE-bench Original | 2,294件 | Python OSS の実 Issue | arXiv 2310.06770 |
| SWE-bench Lite | 300件 | コストを抑えた評価 | Hugging Face |
| SWE-bench Verified | 500件 | OpenAI Preparedness が「解決可能・テスト正当」と確認 | OpenAI公式（2024-08） |
| SWE-bench Multimodal20 | 617件 | ビジュアル系 JavaScript ライブラリ、SVG/スクリーンショット入力 | arXiv 2410.03859 |
リーダーボード：swebench.com
2026-05時点の SWE-bench Verified 上位（モデル単体スコア）：
- Claude Mythos Preview 93.9%（2026-05-28時点）
- Claude Opus 4.8 88.6%
- Claude Opus 4.7 (Adaptive) 87.6%
出典：benchlm.ai / llm-stats.com
Aider Polyglot — 複数言語・diff edit format
Aider Leaderboard は Exercism の 225 題（C++, Go, Java, JavaScript, Python, Rust の polyglot）を、各題2回まで挑戦可能（1回目失敗時はテストのエラーがフィードバック）で評価します。
評価種類：
- Polyglot Benchmark（メイン、SEARCH/REPLACE などの diff edit format）
- Whole edit format（ファイル全文書き換え）
- Diff edit format（unified diff）
- Refactoring benchmark（大規模ファイルのリファクタ）
2026-05時点の上位：
- GPT-5 (high reasoning) 88.0%
- GPT-5 (medium) 86.7%
- o3-pro (high) 84.9%
- Gemini 2.5 Pro (32k thinking) 83.1%
出典：Aider公式 / llm-stats.com 集計
限界：Exercism は「自己完結した小問」で、実プロジェクト文脈や長期保守の能力は測りません。コスト/性能比較指標を併載するのが Aider の特徴です。
Terminal-Bench — シェル操作の現実性
Terminal-Bench（Stanford × Laude Institute）は、Docker サンドボックスで「コンパイル、サーバー設定、モデル訓練、ゲームプレイ、デバッグ」など実環境タスクを評価。CLI ツール tb で再現可能に走らせ、最大100ターンまでエージェントが自然言語で操作します。Terminal-Bench 2.0 は 229 タスク中の 89タスク を採用。
SWE-bench がパッチ生成偏重なのに対し、Terminal-Bench は 「シェル操作の現実性」 を測る点で補完的です。
出典：tbench.ai / 論文 arXiv 2601.11868
LiveCodeBench — コンタミ遮断の競プロ
LiveCodeBench は LeetCode, AtCoder, CodeForces から新規問題を継続収集し、各問題に公開日メタデータを付けます。モデルの学習カットオフ以降に出た問題だけで評価すれば、学習データ汚染（コンタミ）を遮断 できるのが売り。v6 で 1000問超。
4つの評価シナリオ：
- Code Generation（Pass@1）
- Self-Repair
- Code Execution（出力予測）
- Test Output Prediction
限界：競プロドメインに偏り、長期保守やリファクタの能力は測らない。
HumanEval — 歴史的指標
HumanEval（Chen et al., 2021）21 は手書き 164問、平均7.7個の unit test。Codex（GPT-3 をコードで微調整）が pass@1 で 28.8%、Codex-S で 37.7%、100サンプリングで 70.2% を記録し、GitHub Copilot の原型となりました。
ただし現在は GPT-4 系で 90% 超に達して飽和し、学習データ混入の疑いもあるため、歴史的指標として参照されるのみ です。
出典：Chen et al. 2021, arXiv 2107.03374
ベンチマークの組み合わせ読み
| 知りたいこと | 見るべきベンチ |
|---|---|
| 実 OSS Issue の修正能力 | SWE-bench Verified（飽和注意） |
| 多言語での実装力 | Aider Polyglot |
| シェル・実環境タスク | Terminal-Bench |
| 競プロ・アルゴリズム | LiveCodeBench |
| 視覚を伴う UI 修正 | SWE-bench Multimodal |
セキュリティとレビュー — AI コーディングの守るべき線
AIコーディングは「便利」と引き換えに、いくつかの新しい攻撃面と既知の欠陥を持ち込みます。
AI 生成コードのバグ率 — 学術データ
| 研究 | 発見 | 出典 |
|---|---|---|
| Pearce et al. 202222 | 89 のセキュリティ関連シナリオで GitHub Copilot の生成コードを評価、約40%にCWE該当の脆弱性 | IEEE S&P 2022 / CACM |
| Copilot 実プロジェクト調査（TOSEM 採択） | 733件の実プロジェクト由来 Copilot コードのうち Python 29.5% / JavaScript 24.2% にセキュリティ弱点。CWE-330（弱乱数）、CWE-94（コード注入）、CWE-79（XSS）、CWE-78（OSコマンド注入）、CWE-89（SQL注入）、CWE-502（安全でないデシリアライズ）等 | arXiv 2310.02059 |
Copilot Chat と静的解析を組み合わせると、最大 55.5% を修正可能 とも報告されています。AI 生成コードはそのままではなく、自動レビュー層をかぶせる ことが前提です。
Indirect Prompt Injection — エージェントへの攻撃面
エージェントは外部のドキュメント・コメント・HTMLを読み込みます。そこに 悪意ある指示が埋め込まれていた場合、エージェントがそれに従ってしまう、というのが Indirect Prompt Injection です。
主な攻撃面：
- HTML コメント
- 不可視 CSS（display:none、color:transparent）
- メタタグ
- アクセシビリティ層（aria-label等）に隠した命令
- README / マークダウンドキュメント
- パッケージの説明文
実害例として、研究 “AIShellJack” では GitHub Copilot や Cursor 等に対する攻撃成功率が 41% から 84% と報告されています。実被害としては クレデンシャル窃取・データ流出・リポジトリへの malicious code 注入・サプライチェーン汚染 が想定されます。2025-2026 年には、Perplexity Comet で不可視のウェブテキストがユーザー認証情報を漏洩させた事例や、MCP ベースの IDE での zero-click RCE、Cursor の CVE-2025-59944 などが現実化しました。
出典：MintMCP: Prompt injection attacks on coding agents（2025-12） / Lakera: Indirect Prompt Injection（2026-04） / CrowdStrike / Architecting Secure AI Agents（arXiv 2603.30016）
Package Hallucination — 依存ライブラリの幻覚
Joseph Spracklen らの USENIX Security 2025 採択論文23 が、16モデル × 576,000サンプルで調査したところ：
- オープンソースモデル：21.7% のパッケージ名が架空
- 商用モデル：少なくとも5.2% が架空
- 累計 205,474種類 のユニークな架空パッケージ名を観測
- 二次解説によれば、幻覚名の相当数が複数クエリで再現 → 攻撃者は「予測可能な架空名」を実 PyPI/npm に malicious package として登録し、開発者を誘導できる（slopsquatting 攻撃）
出典：arXiv 2406.10279 / USENIX解説 / SecurityWeek
実務対策：
pip install/npm installを実行する前に パッケージ名の実在を手動確認- ロックファイル（package-lock.json, poetry.lock 等）を必ずコミット
- 既知の脆弱性スキャナ（npm audit, Snyk 等）を CI に組み込み
- 「初めて見るパッケージ」は npmjs.com / PyPI で 作成日・ダウンロード数・メンテナ を確認
失敗パターン早見表
| パターン | 説明 | 対策 |
|---|---|---|
| 検証なし出荷（vibe shipping） | テスト/レビューせず main に入れる | TDD + 検証可能成功条件 |
| スコープ無限拡張 | 1タスクで別機能まで手を出す | Explore→Plan→Implement→Commitで段階分離 |
| コンテキスト過剰負荷 | 関係ない巨大ファイルで窓を埋める | context engineering、サブエージェント分離 |
| 「一回全部書き直して」型 | 全面書き直しで差分追跡を失う | 小さなdiffのループ |
| テスト先行を破る | エージェントがテスト書き換えてpass | 失敗テストを先にcommit、変更禁止指示 |
| シークレット漏洩 | .envをcontextにコピペ／公開リポにpush | AGENTS.mdのSecurityセクション、/permissions allowlist |
| PR機械承認 | 監督なし自動 merge | 重要操作は人間承認、最小権限 |
| 依存パッケージ幻覚 | モデルが幻覚した名前を pip install | 実在確認、ロックファイル、脆弱性スキャン |
組織導入とコスト
サブスク vs API — どちらが本番運用に効くか
個人なら月 $20 のサブスクで足ります。組織で導入する場合、サブスク（席課金）と API（従量課金）のどちらが合理的かは、用途で分かれます。
| 用途 | サブスク有利 | API有利 |
|---|---|---|
| エンジニアの日常的なペアプロ | ✓ 月20-40ドル/席で使い放題 | — |
| CI/CD パイプラインでのコードレビュー | — | ✓ PR毎の従量、Batch APIで50%引き |
| 大規模リファクタの一括実行 | — | ✓ Prompt Caching で共通文脈を90%引き |
| 顧客向けプロダクトに組み込み | — | ✓ APIしか選択肢がない |
| 個人ツール・社内検証 | ✓ サブスクで十分 | — |
API 料金の感覚値は 第7章 API 料金 を参照。
教育投資 — エンジニアの再武装
AI コーディングツールは「導入したら自動的に生産性が上がる」道具ではありません。METR の試験が示すように、未学習で導入すると熟練者ほど遅くなる ことすらあります。
組織導入で最も投資価値が高いのは、次の3点です。
- 共通 CLAUDE.md / AGENTS.md / Rules の整備：プロジェクトごとに「文脈ファイル」をテンプレ化し、全エンジニアが同じスタートラインから始められるようにする。
- 失敗パターンの社内共有：本章 13.8 の「失敗パターン早見表」のような知見を、社内 Wiki に展開し、定期的に更新。
- 検証可能成功条件のテンプレート化：「lint + test + typecheck + 主要画面スクショ比較」のような検証セットを、プロジェクト初期に組み込む。
責任の所在 — AI が書いたコードのバグは誰のものか
法的には、コードを commit した人間が責任を負う のが現状の通念です。EU AI Act（Regulation (EU) 2024/1689、特に Article 5・Annex III の高リスク領域）やコロラド州 AI 法（SB24-205）も、AI を使った開発の責任を「開発者（developer）・配備者（deployer）」に帰属させる方向で整理しています（詳細は 第10章 規制・倫理・ガバナンス 参照）。
出典：EU AI Act 公式テキスト / Colorado SB24-205
組織でAIコーディングを導入する場合、最低限決めておくべきこと：
- AI 生成コードの レビュー必須範囲（本番に出るコード、外部公開API、認証認可、決済等）
- シークレット・個人情報の取り扱い（context に含めて良い情報・禁止情報の明文化）
- 失敗時のロールバック手順（自動デプロイの一時停止、影響範囲の特定方法）
- 責任分担（実装者・レビュアー・運用者）
- Vibe Coding と Agentic Engineering — Karpathy 原典（X 2025-02-02）と Sequoia Ascent 2026 の再定義
- SWE-bench Original / Verified / Lite / Multimodal — Princeton 論文と OpenAI Verified、リーダーボード読み方
- Aider Polyglot Leaderboard（Exercism 225 題、6 言語）、Terminal-Bench（Stanford × Laude）、LiveCodeBench、HumanEval — 補完的読み
- Anthropic「Best practices for Claude Code」 — Explore→Plan→Implement→Commit、検証可能成功条件、サブエージェント分離
- AGENTS.md オープン標準（Linux Foundation 配下 Agentic AI Foundation 運営）、CLAUDE.md、Cursor Rules（.mdc）
- Drew Breunig「How to Fix Your Context」— Quarantine / Pruning / Summarization / Offloading の4技法と Context Poisoning / Distraction / Confusion の整理
- Anthropic「Effective context engineering for AI agents」、Karpathy / Tobi Lütke の context engineering 提唱
- Geoff Huntley — Ralph Loop、spec ドリブン、six-month recap（vibe shipping 批判）
- Andrew Ng Agentic AI — Reflection / Tool Use / Planning / Multi-Agent と evaluation 中心の方法論
- Pearce et al. 2022（Copilot 脆弱性 40%）、TOSEM 2023（Python 29.5% / JS 24.2% の弱点）、Spracklen et al. USENIX 2025（Package Hallucinations）
- Indirect Prompt Injection — MintMCP（AIShellJack）、Lakera、CrowdStrike、CVE-2025-59944 Cursor 等の実害