AIエージェントと過ごした3ヶ月 — コーディングから業務自動化、自律エージェントまでの実践録

はじめに

2025年末から2026年2月にかけて、コーディングエージェント（Claude Code、Codex等）を業務・個人開発の両方で本格的に使い倒してきた。その過程で「Agentic Engineering」「Spec-driven development」「CLI + Context Engineeringによる業務拡張」「OpenClawとの生活」といった体験を経て、ソフトウェア開発だけでなく自分の働き方そのものが変わった。

本記事では、実践から得た知見を業界データと照らし合わせながら整理する。ポエム寄りではあるが、できる限りエビデンスも添える。

対象読者： コーディングエージェントを使い始めた/使い倒したいエンジニア、AI活用を開発以外に広げたい人

また、この記事は下記のポエム全開のnote記事を元に（もちろんAIと一緒に）執筆しました。

1. Agentic Engineeringとは — Vibe Codingとの違い

定義の整理

2025年2月、Andrej Karpathy（OpenAI共同創設者）がXへの投稿で「Vibe Coding」という言葉を広めた。LLMに身を委ね、コードの存在そのものを忘れて開発するスタイルだ。Collins Dictionaryは2025年のWord of the Yearにこの語を選出した。

ちょうど1年後の2026年2月、Karpathy自身が次のステージの名前を提唱した¹：

"Agentic Engineering" — "agentic"は、コードを直接書くのではなく99%の時間はエージェントをオーケストレーションし監督する側に回るから。"engineering"は、そこに技芸と科学と専門性があることを強調するため。（要旨）

同時期にAnthropicは「2026 Agentic Coding Trends Report」で Agentic Coding という用語を公式に採用した²。定義は本質的に同じで、エンジニアがAIエージェントをオーケストレーションし、エージェントが自律的にコードを書く一方、人間はアーキテクチャ・設計・戦略的監督に集中するソフトウェア開発手法を指す。

Addy Osmani（Google ChromeチームEngineering Leader）は、両者の境界を端的に整理している³：Vibe Coding = YOLO（一か八か）。Agentic Engineering = AIが実装し、人間がアーキテクチャ・品質・正確性を所有する。 Agentic Codingが技術的に中立な用語なのに対し、Agentic Engineeringの方がエンジニアリング規律（テスト、設計、ガバナンス）をより強調する傾向がある。

同レポートでは、開発者はAIを作業の**60%**に統合しつつ、完全委任は0〜20%に留め、大部分を監督していると報告されている⁴。完全自律ではなく「人間の専門性の増幅」が本質であり、ここがVibe Codingとの決定的な違いになる。

Vibe Coding / Agentic Coding / Agentic Engineering の位置づけ

観点	Vibe Coding	Agentic Coding / Agentic Engineering
提唱者	Karpathy（2025年2月）	Anthropic / Karpathy（2026年1〜2月）
アプローチ	会話的・即興的	仕様先行・構造的
主導権	AIとの対話の中で探索	人間が設計を確定、実装をエージェントに委任
適するフェーズ	プロトタイプ、探索	プロダクション開発
品質管理	人間が都度確認	テストスイート + AIレビュー + 人間レビューの多段構成
テスト	ほぼ皆無	テスト駆動が信頼性の根幹（最大の差別化要因）
エージェント構成	単一のチャットLLM	シングル〜マルチエージェント・オーケストレーション

Vibe Codingが悪いわけではない。プロトタイプや探索フェーズでは極めて有効だ。ただし、プロダクション品質のコードを継続的に生産する場合は、Agentic Engineeringの方が再現性と品質の点で優位だと感じている。皮肉なことに、AI支援開発は従来のコーディングよりも優れたエンジニアリングプラクティスをより強く報いる。テスト、設計、ドキュメンテーション、コードレビュー — これらの「退屈な」基盤がある組織ほど、エージェントからの恩恵が大きくなるのだ。

2. Spec-driven Development の実践

Spec-driven Developmentとは

Thoughtworks Technology Radar（Vol.33, 2025年11月）は、Spec-driven development を "Assess" カテゴリの注目技法として掲載した⁵。構造化された仕様書を基盤とし、AIエージェントがコードを生成・検証する開発アプローチだ。

Thoughtworksの Birgitta Böckeler は、Spec-driven development の本質について以下のように述べている⁶：

仕様は「ビジネス要件の記述」ではなく「ソフトウェアの振る舞いの定義」であり、BDD（振る舞い駆動開発）の知見がそのまま活きる。自然言語で書けるようになっただけで、Given/When/Then の構造やドメイン言語の一貫性は依然として重要だ。（要旨）

ただし、Thoughtworksは同時にリスクも指摘している。重い事前仕様化とビッグバンリリースという、古典的なウォーターフォールのアンチパターンへの回帰が、Spec-driven developmentの実践で既に観察されているという⁷。仕様はインクリメンタルなデリバリーを支えるものであり、巨大な事前設計書に化けてはならない。

ツールの動向

Spec-driven developmentを支える環境は急速に整っている。

• Kiro（AWS / Amazon） — VS Code forkのIDE。自然言語からユーザーストーリー・技術設計・タスクリストを自動生成。2025年7月プレビュー、同年12月GA
• GitHub spec-kit — 3ステップのワークフローに加え、configurable promptsと「constitution（不変原則の宣言）」機能を持つ
• Plan Mode — Claude Code、GitHub Copilot、Cursorがそれぞれ実装。コーディング前にコードベースを探索し計画を立てる機能。GitHub社の報告では、Plan Mode使用時に成功率が15%向上⁸

また、Qiitaでもcc-sddのようなツールが紹介されている。

業務での実践

自社プロダクトの新規機能開発でSpec-driven developmentを実践した。プロセスは以下の通り。

1. 要件の言語化 — 会議内容・画面遷移・処理フローからチャットAI（ChatGPT、Claude）と要件を整理
2. 設計ドキュメントの生成 — 詳細設計 → スコープ分割 → タスクリスト化もAIと協働し、開発ドキュメントとして出力
3. 実装の委任 — ドキュメントをリポジトリに配置し、コーディングエージェントにPlan Modeで計画させた上で実装を依頼
4. 多段レビュー — AIレビュー（CodeRabbit + GitHub Copilot）→ 全フィードバックに対応 → 人間レビュー
5. openapi.yml を Single Source of Truth に — APIインターフェースをOpenAPI形式で定義し、バックエンド・フロントエンド双方のコード生成の基盤とした

openapi.yml はBackendのRailsAPIの実装・テストの効率化（committee-rails
）と、フロントエンドのAPIクライアントの生成（openapi-generator
）のために以前から他のプロジェクトでも利用していたが、これらを機械可読な契約（machine-readable contract）として定義することで、エージェントの実装のブレが大幅に減った。これはThoughtworksが言う「仕様はビジネス要件ではなくソフトウェアの振る舞いを定義すべき」という原則と合致している。

ウォーターフォール回帰への注意： Thoughtworksが警告するように、Spec-driven developmentは「重い事前仕様 → ビッグバンリリース」に陥るリスクがある。自社では仕様をスコープ単位で分割し、各スコープを1〜2日で実装・デプロイするサイクルを維持することで、このアンチパターンを回避した。仕様はインクリメンタルなデリバリーの道具であり、巨大な設計書ではない。

成果と課題 — 業界データとの比較

自社実践と業界データを並べてみる。

成果側：

指標	出典	結果
自社開発工数	自社実績	当初見積もり（人間ベース）の半分以下
タスク完了速度	GitHub / Google / Microsoft等の初期研究9	20〜55%高速化
週次マージ数	シカゴ大学 Sarkar (2025)10	39%増（品質劣化なし）

課題側（AI Productivity Paradox）：

Faros AIは10,000人超の開発者・1,255チームのテレメトリデータを分析し、この構造的課題を 「AI Productivity Paradox（AI生産性パラドックス）」 と名付けた¹¹。個人レベルでは生産性が向上するのに、組織レベルでは効果が消失するという現象だ。

指標	出典	結果
PRレビュー時間	Faros AI (2025)11	AI高採用チームで91%増
AI生成コードの指摘数	CodeRabbit (2025)12	人間比約1.7倍
PR平均サイズ	Faros AI	154%増
バグ発生率	Faros AI	開発者あたり9%増
DORA指標	Faros AI	AI生成25%超のチームでデリバリー安定性7.2%低下、Elite DORA達成率3分の1

Faros AIはこれを Amdahl's Law（アムダールの法則） で説明している。システム全体の速度はボトルネック（最も遅い工程）で決まる。コード生成がどれだけ高速化しても、レビュー・承認・デプロイのパイプラインが追いつかなければ、組織レベルの生産性は向上しない。

自社でも実装速度が上がるほど人間のレビューがボトルネックになるという課題を実感した。コードを書く速度は劇的に上がったが、次の課題はレビュー・承認・デプロイを含むSDLC（ソフトウェア開発ライフサイクル）全体の再設計だ。

生産性測定の難しさ： METR（Model Evaluation & Threat Research）の2025年7月の研究では、経験豊富なOSS開発者がAI利用時に主観的には20%速くなったと感じたが、客観的計測では19%遅くなったという結果が報告されている。この**39ポイントの知覚ギャップ（perception gap）**は、AI生産性の測定が単純ではないことを示す重要なエビデンスだ。ただし、この研究はCursor Pro + Claude 3.5/3.7 Sonnetを使用した2025年前半のもので、モデル・ツールの進化（Opus 4.5/4.6、GPT-5.x等）やチームレベルの学習効果は反映されていない。タスク種別・経験レベル・ツール・測定方法によって結果は大きく変わる点に留意が必要。

3. コーディングエージェントの進化 — Context Engineeringの視点で

2025年末〜2026年にかけて、コーディングエージェントに搭載された機能群を、Context Engineering の枠組みで整理する。

Context Engineeringとは

Andrej Karpathyの言葉を借りれば、LLMは新しいOSであり、コンテキストウィンドウはRAMに相当する¹³。Context Engineering とは、エージェントが各ステップで適切な判断を下せるよう、コンテキストウィンドウに「正しい情報を、正しいフォーマットで、正しいタイミングで」供給する技術体系だ。

Thoughtworks Technology Radar Vol.33（2025年11月）は、AI支援開発の進化を 「Vibe Coding → Context Engineering」 という流れで捉えている¹⁴。Martin Fowler's blogでも Birgitta Böckeler が「コーディングエージェントにおけるContext Engineering」を詳細に分析している¹⁵。

以下のエージェント機能群は、いずれもContext Engineeringの具体的な実装パターンとして理解できる。

Rules / Custom Instructions（永続的コンテキスト）

エージェントにプロジェクト固有の知識を永続的に供給する仕組み。CLAUDE.md、AGENTS.md、.cursorrules等のファイルでルールを定義する。Martin Fowler's blogではこれを "Instructions"（手続き的記憶） に分類している。

# CLAUDE.md の例
## コーディングルール
- テストは必ずTDD（RED → GREEN → REFACTOR）
- APIレスポンスは統一フォーマットに従う
- PR作成時は必ずCodeRabbitのレビューを通す

Skills（オンデマンド・コンテキスト）

必要に応じてエージェントが自律的にロードする追加コンテキスト。Martin Fowler's blogではこれを "Context Interfaces" と呼び、LLMが「さらにコンテキストが必要」と判断したときにアクセスするリソースとして位置づけている¹⁵。Rulesが常にコンテキストに存在するのに対し、Skillsはタスクの性質に応じて動的にロードされるため、コンテキストウィンドウを効率的に使える。

Subagent / Multi-Agent（コンテキストの分離）

独立したコンテキストウィンドウを持つ子エージェントを生成し、並列・分業で作業する。Claude CodeのAgent Teams、Cursor 2.4のSubagents、CodexのMulti-Agent等。Anthropicのレポートによれば、専門化された個別のコンテキストを持つ複数エージェントが、単一エージェントの実装を上回るケースが多い²。これはContext Engineeringにおける「コンテキストの分離（Isolation）」パターンであり、各サブエージェントが狭いサブタスクに注意を集中できるためだ。ただしAnthropicは、マルチエージェント構成ではシングルエージェントと比較して最大15倍のトークン使用量になるケースも報告しており、コストとのトレードオフが存在する。

Spotifyのエンジニアリングチームは、Claude Agent SDKを使って数百のリポジトリにまたがる大規模マイグレーションをマルチエージェントで実行し、数千のPRをマージした事例を公開している¹⁶。彼らの知見の核心は、Context Engineeringが本番品質のPRを生み出す鍵だったということだ。

MCP（Model Context Protocol）

外部ツール・データソースへの接続を標準化するオープンプロトコル。Anthropic発で業界標準化が進行中。DB、API、SaaS等をエージェントの「手足」として統合する。Thoughtworks Technology Radar Vol.33では、MCPが事実上のエージェント向け統合プロトコルのスタンダードとして扱われている⁵。

Hooks / Automation（決定論的コンテキスト制御）

ツール実行の前後にカスタムスクリプトを挿入するライフサイクル制御。Martin Fowler's blogでは、コンテキストのロードを「LLM判断」「人間起動」「エージェントソフトウェア起動」の3種に分類しており、Hooksは3番目 — エージェントソフトウェアが決定論的に起動するコンテキスト供給 — に該当する¹⁵。

// ~/.claude/settings.json の例（PostToolUse Hook）
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "npx prettier --write \"$CLAUDE_FILE_PATH\"",
        "description": "編集後にPrettierで自動フォーマット"
      }
    ]
  }
}

これらの機能群が揃ったことで、コーディングエージェントは「補助ツール」から**「自律的な開発チームメイト」**へ進化した。そして、その性能を決定づけるのはモデルの能力だけではなく、いかに適切なコンテキストを設計するか — すなわちContext Engineeringの巧拙だ。

4. Architecture for Disposable Systems — 使い捨て可能なアーキテクチャ

「作って確かめる」コストが限りなくゼロに近づくと、ソフトウェアアーキテクチャも再考が必要になる。tuananh.net の「Architecture for Disposable Systems」は、この変化に対応するアーキテクチャパターンを提唱している¹⁷。

層	役割	特性
Core（中核層）	ビジネスロジック、データモデル	人間が設計。長期的に耐久する "Source of Truth"
Connectors（契約層）	OpenAPI、gRPC等の標準スキーマ	"Immutable contracts" — この層が完璧であることが前提
Disposable（使い捨て層）	UI、グルーコード	契約に従う限り内部品質は問わない。AIで何度でも再生成可能

ピアッザ チェックインでopenapi.ymlをSingle Source of Truthにしたのは、意図せずこの思想と合致していた。CoreとConnectorsが堅牢なら、Disposable層はエージェントが自在に生成・破棄できる。

これはThoughtworksが紹介するTessl Frameworkの思想 — 仕様そのものをメンテナンスすべき成果物として扱い、コードは中間生成物とみなす⁵ — とも共鳴する。Spec-driven developmentの「急進派」と「穏健派」の議論がまさにこのアーキテクチャの各層のどこに "Source of Truth" を置くかの問題であり、Architecture for Disposable Systemsは一つの明快な回答を提示している。

5. コーディングエージェントを開発以外に拡張する

広木大地氏の「AIエージェントと協働するオフィスワーク2026」に着想を得て、コーディングエージェントの活動領域を開発外に拡張する仕組みを個人的に構築してみた。

広木氏の記事ではnoti（DB）、slakky（Slack）、gog（Google系）等のCLIを用いてエージェントに業務遂行能力を与えている。自分も同じアプローチで、自身が日常的に使うサービスをCLIで抽象化した。

なぜCLIか — エージェントとの親和性

CLIはテキストin/outでLLMと親和性が高い。具体的には：

• 実行→結果→次の判断のループがエージェントのReActパターン（Reasoning + Acting）と一致する
• UNIX哲学「一つのことをうまくやる」がエージェントのツール粒度と合致する
• パイプで組み合わせ可能 → エージェントが自律的にワークフローを構築できる

これは、MCPが標準化しようとしている「外部ツール接続」を、よりシンプルなCLIインターフェースで実現するアプローチとも言える。MCPサーバーを書くほどの汎用性は不要だが、特定のサービスへの接続をエージェントに提供したい場合、CLIは最小コストの選択肢になる。

実際に作成したCLIツール

CLI名	対象サービス	主な用途
slac	Slack	メッセージ投稿・検索・チャンネル管理
ino	Inoreader	RSS購読・記事取得
rdrop	Raindrop	ブックマーク保存・検索
xar	X（旧Twitter）	タイムライン取得・投稿
qiitar	Qiita	記事検索・トレンド取得
zennar	Zenn	記事検索・トレンド取得
plam	PLaMo	LLM APIアクセス
disco	Discord	メッセージ送信・通知
fitb	Fitbit	活動データ取得
swibo	SwitchBot	IoTデバイス制御・センサー値取得

※ 現在もどんどん増え続けている

Context Engineeringとしてのドメイン知識定義

CLIだけでは「何をすべきか」の判断ができない。そこでドメイン知識をMarkdownファイルにカプセル化し、エージェントへのコンテキストとして供給する。これは前述のContext Engineeringにおける**Skills（オンデマンド・コンテキスト）**パターンと同じ構造だ。

# Skill: 朝の情報収集

## 目的
Tech系の重要ニュースを収集・要約し、Slackの #tech-news に投稿する

## 判断基準
- 重要度: AI/LLM関連、自社技術スタックに関連するもの、セキュリティ関連を優先
- 除外: マーケティング記事、プレスリリースのみの内容
- 要約: 1記事あたり2-3行。原文リンクを必ず添付

## 使用CLI
- ino: RSS記事取得（過去24時間）
- xar: Xタイムライン取得（フォロー中のみ）
- rdrop: 選別した記事をRaindropに保存
- slac: #tech-news に要約を投稿

組み合わせの実例

例1: 朝の情報収集 → Slack要約投稿

ino（RSS取得）+ xar（Xタイムライン取得）
  → Skill（重要度評価・要約）
    → rdrop（Raindropに保存）
      → slac（Slackに投稿）

例2: SwitchBot CO2モニター → Discord換気通知

swibo（CO2値取得）
  → Skill（閾値判断: 1000ppm超で通知）
    → disco（Discordへ換気通知）

例3: Gmail → 自動トリアージ

gmail（未読取得）
  → Skill（重要度判断）
    → 低優先度: gmail（アーカイブ）
    → 高優先度: slac（Slack即時通知）

Architecture for Disposable Systemsとの適合

この仕組みは前述のアーキテクチャパターンと高い親和性を持つ。

Architecture for Disposable Systems	CLI + Skill での対応	説明
Core	Skill定義（Markdown）	ドメイン知識・判断基準。めったに変わらない
Connectors	CLIツール群	安定した入出力契約。引数・出力フォーマットが明確で不変
Disposable	ワークフローの組み合わせ方	Skill + CLIが堅牢ならUI層はエージェントが自在に生成・破棄

かつてPerl・Pythonのグルーコードとして人間が書き保守していた「繋ぎの部分」を、エージェントが文脈に応じて動的に再構成する。CoreとConnectorsが堅牢なら、繋ぎ方を変えるだけで対応できる。

6. 自律エージェントの広がり — OpenClawとその先

OpenClawとは

OpenClawは、Peter Steinberger（PSPDFKit創業者）が2025年11月に公開したオープンソース自律型AIエージェント。GitHub Stars 18万超（2026年2月時点）¹⁸。

Discord・Slack等をUIとし、LLMを通じてタスクを自律実行する。最大の特徴は自らスキルを書いて能力を拡張すること — 従来のAIエージェントが事前定義されたツールの範囲内でしか動けなかったのに対し、OpenClawは行動範囲を自律的に広げる。

公開からわずか3ヶ月後、Steinberger氏のOpenAI入社がSam Altman自身のポストで発表された。個人が作ったOSSが世界最大のAI企業を動かした事例として象徴的だ。

OpenClawのセキュリティについては、CVE-2026-25253の解説記事やセットアップガイドがQiita上にも公開されている。自律エージェントの運用にはセキュリティリスクが伴うため、サンドボックス環境での実行を推奨する。

エージェント同士のインタラクション

OpenClawのようなエージェントが自律的に行動できるようになった先に、さらなる展開が生まれている。

• Moltbook — AIエージェントのみが参加するReddit風フォーラム。人間は閲覧のみ
• SpaceMolt — AIだけのスペースMMO。採掘・交易・戦闘をAIエージェントが行い、人間は観戦のみ
• RentAHuman — AIエージェントが人間を雇うマーケットプレイス。WIRED Japanでも取り上げられた

OpenClawが「自律的に行動」→ Moltbook/SpaceMoltで「エージェント同士がインタラクション」→ RentAHumanで「AIが人間に仕事を依頼」。この3段階がわずか半年で進行している。

個人での活用 — 3体のOpenClawとの生活

現在、用途別に3体のOpenClawを日常的に稼働させている。

エージェント	用途	主な活動
バディ（ボケナス）	汎用	RSS巡回、Slack整理、壁打ち、リサーチ。要件定義→コーディングエージェントへの橋渡し
コーチ	生活改善	fitbで活動データ取得 → Notionに記録 → 週次振り返り・改善提案
トラベラー（ホデナス）	実験	Moltbook・SpaceMoltでの活動。クラウドSandboxに隔離、最小権限で運用

セキュリティと自律性のトレードオフ

自律エージェントを業務に持ち込む際の課題は、Anthropicの2026 Agentic Coding Trends Reportが指摘する 「セキュリティの二面性」 — 防御側にも攻撃側にも同じ能力が使える — と同根だ²。

リスク：

• 自律的なコード実行 → プロンプトインジェクション攻撃の可能性
• APIキー・シークレットの管理が曖昧化
• エージェントが開発者を攻撃した事例の報告¹⁹

対応策：

• サンドボックス環境での実行（必須）
• 人間の承認を最終ゲートにする（Human-in-the-loop）
• 明示的なポリシーと実行権限の宣言（最小権限の原則）
• 監査ログの徹底

正解はまだない。セキュリティ・リスク管理を前提に、自律実行の能力を最大限解放する — この相反する2つのバランスを模索中だ。

8. まとめ — 2025年末〜2026年2月で見えてきたこと

1. コーディングエージェントは実用段階に達した

Opus 4.6（SWE-Bench 80.8%）とGPT-5.3 Codex（Terminal-Bench 77.3%）の同日リリース（2026/2/5）により、LLMの能力がしきい値を超えた。コーディングエージェント運用のノウハウ蓄積と合わせ、Agentic Engineeringの前提条件が揃った。

2. 生産性向上とレビューボトルネックは表裏一体（AI Productivity Paradox）

コード生産速度は劇的に向上（マージ数39%増、タスク完了20〜55%高速化）するが、レビュー時間は91%増加し、AI生成コードの指摘は1.7倍。Amdahl's Lawが示す通り、コード生成だけでなくSDLC全体の再設計が次の課題。Faros AIが報告するDORA指標の悪化は、この構造的課題を定量的に裏付けている。

3. Spec-driven development + 機械可読な契約が効く

仕様を構造化フォーマットで定義し、それをSingle Source of Truthとすることで、エージェントの実装精度が大幅に向上する。ただし、Thoughtworksが警告するウォーターフォール回帰リスクへの注意は忘れてはならない。Architecture for Disposable Systemsの「Immutable contracts」の思想と組み合わせることで、仕様の堅牢さとデリバリーの俊敏さを両立できる。

4. Context Engineeringがエージェント性能の鍵を握る

Rules、Skills、MCP、Hooks、Multi-Agent — これらはすべて「コンテキストウィンドウに何を、いつ、どう供給するか」の設計であり、Context Engineeringとして統一的に理解できる。モデル層の進化と同等以上に、このコンテキスト層の設計がエージェントの実用性を左右する。

5. コーディングエージェントは汎用エージェントになり得る

CLI + Skillの仕組みで開発以外の業務自動化が実現可能。AnthropicのCoworkリリースや、Shopifyの全社AI義務化、Microsoftの非エンジニアへのClaude Code導入が示す通り、「エージェント＝エンジニアツール」という認識は急速に過去のものになりつつある。

6. 自律エージェントの時代が始まった

OpenClaw → Moltbook/SpaceMolt → RentAHuman。自律エージェントがインタラクションし、人間と協働（あるいは人間を雇用）する世界が現実になりつつある。そこでは、セキュリティとHuman-in-the-loopの設計が、技術的な能力と同等に重要な課題となる。

参考文献

• Anthropic, "2026 Agentic Coding Trends Report"
• Anthropic, "Eight trends defining how software gets built in 2026"
• Andrej Karpathy, Xポスト（Agentic Engineering提唱）
• Addy Osmani, "Agentic Engineering"
• Thoughtworks Technology Radar Vol.33, 2025年11月
• Thoughtworks, "Spec-driven development: Unpacking one of 2025's key new AI-assisted engineering practices"
• Thoughtworks, "From vibe coding to context engineering: 2025 in software development"
• Martin Fowler's blog, "Context Engineering for Coding Agents"
• LangChain, "Context Engineering"
• Spotify Engineering, "Background Coding Agents: Context Engineering"
• Faros AI, "The AI Productivity Paradox Research Report"
• CodeRabbit, "State of AI vs Human Code Generation Report"
• OECD, "Unlocking productivity with generative AI"
• METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"
• tuananh.net, "Architecture for Disposable Systems"
• 広木大地, "AIエージェントと協働するオフィスワーク2026"
• 梶谷健人, Xポスト（385万view）

1. Andrej Karpathy, Xポスト, 2026年2月4日 ↩

2. Anthropic, "2026 Agentic Coding Trends Report", 2026年1月 ↩ ↩² ↩³

3. Addy Osmani, "Agentic Engineering" ↩

4. Anthropic, "Eight trends defining how software gets built in 2026", 2026年1月 ↩

5. Thoughtworks Technology Radar, "Spec-driven development" ↩ ↩² ↩³

6. Thoughtworks, "Spec-driven development: Unpacking one of 2025's key new AI-assisted engineering practices", 2025年12月 ↩

7. Thoughtworks Technology Radar Vol.33, 2025年11月。「complacency with AI generated code」と並ぶ注意点として言及 ↩

8. GitHub Blog, Copilot Plan Mode関連の発表より ↩

9. OECD, "Unlocking productivity with generative AI", 2025年7月 ↩

10. Rohan Paul氏のXポスト経由。シカゴ大学Booth School of BusinessのSuproteem K. Sarkar氏による、Cursor Agentを導入した24組織 vs 非導入8組織の比較分析 ↩

11. Faros AI, "The AI Productivity Paradox Research Report", 10,000人超の開発者、1,255チームのテレメトリデータに基づく分析（2025年6月時点） ↩ ↩²

12. CodeRabbit, "State of AI vs Human Code Generation Report", 470のオープンソースPR（AI共著320、人間のみ150）を分析。AI生成PRは平均10.83件の指摘、人間PRは6.45件 ↩

13. LangChain, "Context Engineering", 2025年10月 ↩

14. Thoughtworks, "From vibe coding to context engineering: 2025 in software development", 2025年11月 ↩

15. Martin Fowler's blog, "Context Engineering for Coding Agents" ↩ ↩² ↩³

16. Spotify Engineering, "Background Coding Agents: Context Engineering (Honk, Part 2)", 2025年11月 ↩

17. tuananh.net, "Architecture for Disposable Systems", 2026年1月 ↩

18. OpenClaw GitHub、および各種報道より ↩

19. セキュリティ研究者による報告。エージェントが悪意あるプロンプトインジェクションを受け、開発者の環境に対して破壊的操作を実行したケース ↩