AI Codingとは何か｜コード補完からCoding Agentへ進化した開発の仕組み

2026年のAI Codingは、単に「AIにコードを書かせること」ではありません。

数年前まで中心だったのは、IDEで次の数行を予測するautocompleteでした。その後、Chat形式でコードを質問・生成するassistantが普及し、さらにrepository全体を参照するrepo-awareな支援へ進みました。

現在はその先にあります。

Autocomplete
↓
Chat
↓
Repo-aware Assistant
↓
Coding Agent

Coding Agentは、要求を受け取るだけでなく、repositoryを調査し、複数ファイルを変更し、コマンドを実行し、testを走らせ、結果を確認し、人間がreviewできる状態まで作業を進めます。

2026年2月に公開されたOpenAIのCodex appも、複数agentの並列作業、diff review、worktreeによる隔離を前面に出しています。GitHub Copilot coding agentも、taskを受けて作業し、Pull Requestを作成して人間へreviewを要求するworkflowを公式に採用しています。OpenAI

AI Codingの論点は、もはや、

「AIはコードを書けるか」

ではありません。

「どこまで実行を委譲し、どこに検証・承認・責任の境界を置くか」

です。

今日の到達点

この記事では、次の状態を目指します。

• AutocompleteからCoding Agentまでの発展を説明できる
• Coding Agentを「LLM」ではなく「Model + Tools + Environment」として理解できる
• repository理解、編集、test、reviewの役割を分離できる
• sandbox・permission・rollbackが必要な理由を説明できる
• AIへ委譲可能な処理と、人間が承認すべき処理を設計できる

Autocompleteから始まったAI Coding

初期のAI Codingで中心だったのはautocompleteです。

開発者が、

def calculate_area(radius):

と入力すると、その続きとして、

    return 3.141592653589793 * radius ** 2

のようなコード候補を生成します。

構造は比較的単純です。

Current Code
↓
Model
↓
Completion
↓
Developer Accept / Reject

AIの責務は候補生成です。

実際に採用するかは人間がその場で決めます。

この方式ではAIの権限は非常に小さく、repositoryを書き換えたり、shell commandを実行したりする必要はありません。

Chatで「コードを書く」から「相談する」へ

次に広がったのがChat型Coding Assistantです。

人間が自然言語で、

この関数をasync化して

あるいは、

この例外の原因を説明して

と依頼します。

ここではAIの仕事が、

Code Completion

から、

Explanation
Generation
Refactoring
Debugging

へ広がります。

ただし、Chatだけでは重要な制約があります。

AIが見えているcontextしか理解できないことです。

対象fileだけを渡しても、

別fileのinterface
database schema
test
configuration
dependency

を知らなければ、局所的には正しく見えてもrepository全体では壊れるコードを生成できます。

Repo-awareで局所最適から抜ける

そこで重要になったのがrepo-aware、つまりrepositoryを参照したCoding支援です。

Repository
├─ src/
├─ tests/
├─ docs/
├─ config/
├─ package.json
└─ README.md
        ↓
     AI Coding

AIは対象fileだけでなく、関連fileを検索して、

このfunctionはどこから呼ばれているか

既存testはどこにあるか

projectではどのcoding conventionを使うか

を調べられるようになります。

ここでAI Codingは「コード生成器」からcodebase navigation systemへ変化します。

大規模repositoryでは、コードを書く能力だけでなく、

必要なcontextを正しく探す能力

が重要になります。

Coding Agentで何が変わったのか

Coding Agentになると、AIは提案だけでなくactionを持ちます。

概念的な処理は次のようになります。

flowchart TD
    A[Task] --> B[Inspect Repository]
    B --> C[Plan]
    C --> D[Edit Files]
    D --> E[Run Tests]
    E --> F{Pass?}
    F -->|No| G[Inspect Error]
    G --> C
    F -->|Yes| H[Diff / Pull Request]
    H --> I[Human Review]

ここで重要なのはloopです。

通常のChatなら、

Prompt
↓
Answer

で終わります。

Coding Agentでは、

Observe
↓
Plan
↓
Act
↓
Test
↓
Observe
↓
Revise

を繰り返します。

OpenAIは2026年のCodexについて、大規模codebaseの理解、tool使用、変更、test実行、人間のreviewへ渡すところまでをCoding Agentのworkflowとして説明しています。OpenAI

これは後のDay 6で扱うAI Agentの考え方そのものです。

AI Codingは、Agent技術が最も実用化しやすい領域の一つと考えられます。

Coding Agentはモデル単体ではない

Coding AgentをLLMと同一視すると、architectureを見誤ります。

実際には次のようなstackです。

Human
────────────────────
Agent Harness
────────────────────
LLM / Reasoning Model
────────────────────
Repository Search
File Read / Write
Shell
Compiler
Test Runner
Git
Browser / Documentation
────────────────────
Sandbox / Permission
────────────────────
Operating System

LLMは重要ですが、一部にすぎません。

たとえばモデルが正しい修正案を考えても、fileを書き換えるtoolがなければAgentにはなりません。

逆にtoolが強力でも、permission境界がなければ危険です。

したがってAI Codingの性能は、

Model Capability
+
Context Retrieval
+
Tool Use
+
Environment
+
Verification
+
Permission

で決まります。

TestがCoding Agentを強くする

Software EngineeringがAI Agentと相性のよい理由の一つは、結果を機械的に検証しやすいことです。

たとえば、

def add(a, b):    return a + b

に対して、

def test_add():    assert add(2, 3) == 5

というtestがあれば、変更後の動作を自動確認できます。

Agentは、

Edit
↓
pytest
↓
Failure
↓
Error Message
↓
Edit
↓
pytest
↓
Pass

というfeedback loopを作れます。

これは単純な文章生成とは大きく異なります。

AI自身の「たぶん正しい」という判断ではなく、

Compiler
Type Checker
Linter
Unit Test
Integration Test

という外部Verifierを利用できるからです。

ただし、

testが通ることと、仕様が正しいことは同じではありません。

誤った仕様に対するtestなら、誤った実装でもpassします。

Human-in-the-loopは「全部確認する」ことではない

Human-in-the-loopとは、人間がAIのすべての操作を逐一承認することではありません。

それではAutomationの利点が消えます。

重要なのはriskに応じてapproval boundaryを置くことです。

たとえば次のように分けられます。

この境界はprojectによって変わります。

大切なのは、

AIに何をさせるか

だけでなく、

AIに何をさせないか

を設計することです。

Sandboxはなぜ必要なのか

Coding Agentはshell commandを実行できるため、通常のChat AIとはriskが違います。

誤ったcommandを生成すれば、

file削除
credential参照
network送信
意図しないinstall
repository破壊

などが起こり得ます。

そこで使われるのがsandboxです。

sandboxとは、Agentが実行できる範囲をOSなどの機構で制限した実行環境です。

OpenAIはCodexのdefault modeについて、workspace内へのwriteを許可しつつ、network accessなど境界を越える操作を制限する設計を説明しています。Windows版についても2026年5月、Coding Agent向けのOSレベルsandbox設計を公開しました。OpenAI

AnthropicもClaude Codeについて、filesystemとnetworkを制限するsandboxを提供し、各commandを毎回承認する方式によるapproval fatigueを減らしながら安全境界を維持する考え方を説明しています。Anthropic

GitHub Copilotにもfilesystem、network、credential accessを制御するsandbox policyがあります。GitHub Docs

つまりsandboxはAI Coding固有の付加機能ではなく、Agentに実行権限を渡すための基盤技術です。

Permissionは能力を制限する設計変数

Coding Agentへ与えるpermissionを、

Read
Write
Execute
Network
Credential
Deploy

に分解すると考えやすくなります。

最小権限の原則では、

task達成に必要な権限だけを与える

ことを基本にします。

たとえばdocumentation修正なら、

Repository Read
Documentation Write

で十分かもしれません。

Internet accessやproduction credentialは不要です。

一方、dependency updateでは、

Package Registry Access
Lock File Write
Test Execution

が必要になります。

権限を二値の、

AIを信用する
AIを信用しない

で考えるのではなく、capabilityごとに分解することが重要です。

Reviewはコードを読むだけではない

Coding Agentのreviewでは、生成されたコードだけを見るのでは不十分です。

確認対象は少なくとも、

Requirement
↓
Plan
↓
Diff
↓
Tests
↓
Side Effects

です。

GitHub Copilot coding agentでは、Agentがtaskを完了するとPull Requestを作成し、人間をreviewerとして追加するworkflowが公式に案内されています。GitHub自身もAgentの出力を通常のcontributorと同じように人間がreviewすることを求めています。GitHub Docs

ここでGitが非常に重要になります。

main
│
├── agent-task-branch
│      ├── commit
│      ├── commit
│      └── tests
│
└── Human Review
       ↓
      Merge

AIの変更を直接productionへ反映するのではなく、branchとdiffを境界にできます。

Rollbackを最初から設計する

AI Codingでは「失敗しないAgent」を目標にするだけでは不十分です。

必ず、

失敗しても戻せること

を設計します。

Software DevelopmentではGitが強力なrollback mechanismになります。

Known Good State
↓
Agent Branch
↓
Changes
↓
Test
↓
Problem
↓
Discard / Revert

この考え方はAI時代にさらに重要です。

Agentは人間より高速に多数fileを変更できるため、誤った方向へ進んだ場合の変更量も大きくなるからです。

安全性は、

AIが間違えない

ではなく、

間違えても検出できる
+
影響範囲を限定できる
+
元へ戻せる

で設計します。

2026年の代表的なCoding Agent

2026年時点では、複数providerがCoding Agentを展開しています。

OpenAIのCodexはCLI、IDE、desktop app、cloudなど複数surfaceを持ち、2026年のCodex appでは複数Agentの並列実行とworktreeによる分離も公式に説明されています。OpenAI

AnthropicのClaude Codeはterminalを中心としたAgent型Coding環境で、permissionとsandboxを明示的な設計要素としています。Anthropic

GitHub のCopilot coding agentは、GitHub Issueやpromptからtaskを開始し、branchまたはPull Requestを介して人間のreviewへ接続します。GitHub Docs

Googleでは2025年のGemini CLIからさらに展開が進み、2026年5月にconsumer向けCLIをAntigravity CLIへ移行しました。Googleはその理由として、単一terminal agentからmulti-agent workflowへ要求が広がったことを挙げています。Google Developers Blog

ここでも重要なのは製品ランキングではありません。

見るべきなのは、

Repository Context
Tool Access
Sandbox
Permission
Test Integration
Git Integration
Human Review
Auditability

というarchitectureです。

AIへ委譲できる仕事

Coding Agentへ比較的委譲しやすいのは、成功条件を機械的に確認できる仕事です。

たとえば、

• test追加
• boilerplate生成
• repetitive refactoring
• documentation更新
• 型エラー修正
• lint修正
• 小規模bug fix
• dependency更新の候補作成

などです。

特に、

明確なRequirement
+
既存Test
+
小さいDiff
+
Rollback可能

というtaskはAgentと相性がよい傾向があります。

要承認にすべき仕事

一方、AIに実行させてもよいが、人間がmerge前に確認すべき領域があります。

• architecture変更
• database schema変更
• security関連コード
• authentication
• dependency追加
• public API変更
• performance-critical code
• deployment configuration

これらは変更自体をAgentへ任せても、影響範囲が広いため人間のreviewを残します。

人間が責任を保持すべき領域

さらに重要なのが、AIへ意思決定責任を移してはいけない領域です。

たとえば、

何を作るべきか
どのriskを受容するか
security requirementは何か
productionへ出してよいか
顧客dataを扱ってよいか

という判断です。

AIは分析材料を作れます。

しかし、組織としてriskを受容する主体にはなりません。

この区別を、

Execution
≠
Accountability

として覚えておくとよいでしょう。

AIへexecutionを委譲しても、accountabilityまで自動的に移るわけではありません。

Coding Agentの評価方法

Coding Agentを評価するとき、単に「良いコードを書いたか」だけでは足りません。

次のように分解できます。

特に重要なのがscope controlです。

10行直せばよいtaskで500行を書き換えるAgentは、正しく動いてもreview costが高くなります。

したがって、

最小の正しい変更を作れるか

も重要な性能指標です。

AI Codingを安全なWorkflowにする

実務での最小構成は、次のように整理できます。

flowchart TD
    A[Issue / Requirement] --> B[Agent]
    B --> C[Repository Inspection]
    C --> D[Plan]
    D --> E[Sandbox]
    E --> F[Edit]
    F --> G[Test / Lint / Build]
    G --> H{Pass?}
    H -->|No| I[Revise]
    I --> F
    H -->|Yes| J[Git Diff / Pull Request]
    J --> K[Human Review]
    K -->|Reject| I
    K -->|Approve| L[Merge]
    L --> M[Deployment Gate]

このarchitectureでは、AIがかなり多くの作業を実行できます。

しかし重要な境界には、

Sandbox
Test
Git
Review
Deployment Gate

があります。

これがspeedとcontrolを両立するAI Codingです。

工学自動化でも同じ設計が使える

Coding Agentの考え方はsoftwareだけに限定されません。

たとえば設計計算コードをAIに変更させる場合も、

Requirement
↓
Agent
↓
Python Code
↓
Unit Test
↓
Known Engineering Cases
↓
Diff
↓
Engineer Review

とできます。

さらにCAD自動化なら、

Design Rule
↓
Agentが生成ロジック変更
↓
DXF生成
↓
Geometry Validation
↓
Drawing Comparison
↓
Engineer Approval

とできます。

ここで重要なのは、AIがPythonを書けることではありません。

工学知識をtest可能な形へ変換することです。

たとえば設計式について、

def test_known_case():    result = calculate_velocity(flow_l_min=60, diameter_mm=20)    assert abs(result - EXPECTED_VALUE) < TOLERANCE

のような既知ケースを持っていれば、AIが将来コードを変更してもregressionを検出できます。

これはAI Codingと工学知識資産化が接続する重要なポイントです。

AI時代ほどTestが資産になる

人間だけがコードを書く時代でもtestは重要でした。

しかしCoding Agent時代には、価値がさらに上がります。

なぜならAgentは、

Requirement
↓
Code
↓
Test
↓
修正

を高速に繰り返せるからです。

逆にtestがなければ、

AIが変更
↓
人間が全部読む
↓
人間が全部試す

となり、Agent化の効果が小さくなります。

つまりAI Coding時代には、

コードそのものだけでなく、仕様・test・validation ruleが機械可読であること

が競争力になります。

これは単なるCoding技術の話ではありません。

知識を、

文章
↓
Requirement
↓
Rule
↓
Test
↓
Executable Specification

へ変換する話です。

まとめ

AI Codingは、

Autocomplete
↓
Chat
↓
Repo-aware
↓
Coding Agent

へ発展してきました。

Coding AgentになるとAIは、コードを提案するだけでなく、

Read
Plan
Edit
Execute
Test
Revise

をloopできます。

しかし、実行能力が増えるほどriskも増えます。

そのため2026年のAI Codingで重要なのは、

Model
+
Tools
+
Sandbox
+
Permission
+
Tests
+
Git
+
Human Review
+
Rollback

というsystem設計です。

AIにすべてを任せることがAgent化ではありません。

安全な範囲では自律実行させ、境界を越える操作では承認を要求し、結果を機械的に検証し、いつでも戻せるようにすることが実務的なAgent設計です。

そしてAI Codingが進むほど、人間の価値がなくなるのではなく、人間の仕事が変わります。

コードを一行ずつ入力する

ことから、

Requirementを定義する
境界を設計する
Testを書く
結果をreviewする
Riskを判断する

ことへ重心が移ります。

AI Codingの本質は「AIがprogrammerになること」ではありません。

software developmentを、AIへ安全に委譲可能な検証付きworkflowへ再設計することです。

参考情報

• OpenAI「Introducing the Codex app」
• OpenAI「Building a safe, effective sandbox to enable Codex on Windows」
• Anthropic「Making Claude Code more secure and autonomous with sandboxing」
• GitHub Docs「Get started with Copilot agents on GitHub」
• GitHub Docs「Configuring local sandboxing in the GitHub Copilot app」
• Google Developers Blog「Transitioning Gemini CLI to Antigravity CLI」

今日の確認問題／学習課題

1. AutocompleteとCoding Agentの違いを、「入力」「実行権限」「feedback loop」「人間の役割」の4軸で説明してください。
2. 自分が管理する小さなrepositoryを想定し、AIへ自動委譲 / 要承認 / 人間のみの3段階で操作権限を分類してください。
3. 「testが全部passしたので人間reviewは不要」という判断が危険な理由を3つ挙げてください。
4. 既知の計算例を一つ選び、その計算コードをAIが変更しても誤りを検出できるregression testをどう作るか考えてください。

次回予告

Day 6｜AI Agent

次回はCoding Agentから一段抽象度を上げます。

Coding Agentではenvironmentがrepository、shell、test runnerなどに比較的限定されていました。AI Agentではこれを一般化し、

Goal
↓
Observe
↓
Plan
↓
Tool Use
↓
Environment
↓
Feedback
↓
Re-plan

という構造として整理します。

同時に、「決められた順番を実行するWorkflow」と「状況を見て次の行動を選ぶAgent」を分離し、2026年に氾濫しているAI Agentという言葉が、どこから本当にAgentと呼べるのかを技術的に整理します。