はじめに

AI コーディングツールが急速に進化しています。GitHub Copilot、ChatGPT、Cursor、Claude Code...さまざまなツールが登場していますが、「結局どう違うの？」と感じている方も多いのではないでしょうか。

この記事では、自律性レベルという観点で AI コーディングツールを整理し、各ツールの特徴と使いどころを解説します。

この記事で得られること：

AI コーディングツールを分類する考え方
各レベルの代表的なツールと、それぞれ何ができるか
各ツールをいかに使い分けるか

AI コーディングツールとは

AI コーディングツールとは、AI を活用してソフトウェア開発を支援するツールの総称です。

近年は、大規模言語モデル（LLM）の進化により、これらのツールは「コードを書く」だけでなく「開発タスク全体を遂行する」方向へ進化しています。

自律性レベルとは

AI コーディングツールを理解する上で有用な視点が「自律性レベル」です。自動運転車の SAE J3016 標準¹をアナロジーとして、複数のフレームワークが提唱されています²³⁴⁵。

しかし、そもそも「システムが自律性を持つ」とはどういうことでしょうか。この問いを避けて、具体的なツールの「自律性レベル」を語ったとしても、主観的な議論に陥ってしまうような気がします。

そこで、各ツールの話に移る前に、「自律性レベルをはかる条件」について考えてみます。

「自律性」概念について

本記事では、自律性レベルを 「コーディング環境への埋め込み」と「再帰性（フィードバックループ）の有無」 という 2 つの軸で整理します。

Level	推論回数	コーディング環境への埋め込み	再帰性（フィードバックループ）の有無	代表ツール
1	1 回	なし	なし	ChatGPT, Gemini, Claude Web など
2	1 回	あり	なし	GitHub Copilot など
3	複数回	あり	あり	Cursor, Claude Code など

この分類を考えるにあたって、Stan Franklin と Art Graesser による「エージェント」の定義⁶を参考にしました。

自律エージェントとは、ある環境の中に位置し、かつその環境の一部をなすシステムである。それは自身の目的（アジェンダ）を追求するために、時間の経過とともに環境を感知し、環境に対して作用し、将来感知する内容に影響を与えるものである。

原文:

"An autonomous agent is a system situated within and a part of an environment that senses that environment and acts on it, over time, in pursuit of its own agenda and so as to effect what it senses in the future."

この定義を、コーディング作業という文脈で読み替えると（かなりざっくりとですが）：

"Situated within" (環境の中に位置し) → IDE/CLIへの統合 (Level 2の条件)
"Senses that environment and acts on it, over time" (時間の経過とともに環境を感知し、環境に対して作用する) → 推論と行動の反復ループ (Level 3の条件)

という対応関係になります。

この分類は業界標準ではなく、ツールの理解を助けるための概念的な整理です。また、ツールのアップデートにより分類が変わる可能性もあります。

補足 1：コーディング環境への埋め込みとは何か

Level 1 と Level 2 を分ける決定的な違いは、「AI が開発者と同じ『現場（コンテキスト）』を共有しているか」 という点です。

Level 1（環境の外部）： ChatGPT や Gemini の Web インターフェースなどが該当します。これらはコーディング環境（IDE）の外側にいるため、開発者が現在どのファイルを開いているか、カーソルがどこにあるかを知りません。そのため、ユーザーは「コードをコピーして、プロンプトに貼り付け、状況を説明する」という 手動のブリッジ（橋渡し） を行う必要があります。

Level 2（環境の内部）： GitHub Copilot のような IDE プラグインが該当します。これらは開発者のエディタ内部に常駐（Situated）しており、以下のような 「環境の情報」を自動的に感知（Sense） しています。

現在編集中のコードとカーソル位置
別タブで開いている関連ファイル
プロジェクトの言語設定やフレームワーク情報

この「環境への埋め込み」により、Level 2 のツールはユーザーが説明しなくても、「今書きたいコード」を文脈に合わせて察知し、エディタ上に直接グレー文字（Ghost Text）などで提案を行うことができます。

つまり、「情報を自分から見に行ける（Level 2）」のか、「渡された情報しか見えない（Level 1）」のか、という「感知能力の接合度」の違いがここにあります。

補足 2：再帰性（フィードバックループ）とは何か

Level 2 と Level 3 を分ける決定的な違いは、定義にある 「時間の経過（Over time）」 と 「将来の感知内容への介入（Effect what it senses in the future）」 の有無です。

Level 2（単発の推論）： GitHub Copilot などの Level 2 ツールは、時間軸を持たない「その瞬間ごとのスナップショット」で動作します。ユーザーがコードを書いて（感知）、AI が提案する（作用）というプロセスは 1 回で完結し、AI は「自分の提案がその後どうなったか（エラーが出たか、動いたか）」を確認しません。つまり、「行動」はするが、その結果を「将来感知」しようとはしないのです。

Level 3（時間的持続性のある推論）：一方、Cursor や Claude Code などの Level 3 ツールは、「自分の行動によって、将来の状況（感知する内容）を変えようとする」 性質を持っています。

定義にある "acts... so as to effect what it senses in the future" （将来感知する内容に影響を与えるように作用する）とは、具体的には以下のようなサイクルを指します。

Senses (t1): エラーログを読み取る（「失敗」を感知）
Acts (t1): コードを修正する
Senses (t2): 再度テストを実行し、結果を読み取る（自分の行動によって、感知内容が「失敗」から「成功」に変わったか確認する）

Level 3 のツールは、このサイクルを自律的に繰り返します。「エラー（現在の感知）」を「成功（未来の感知）」に変えるために行動し続ける点こそが、単なる自動化ツールとは異なるエージェント（代理人）としての本質なのです。

各レベルのツール紹介

ここからは、各レベルの代表的なツールを紹介します。

違いを明確にするため、「バグを修正する」 という共通の題材で使用イメージを説明します。

使用する題材

1. 準備（フォルダ作成とインストール）

ターミナルで以下を実行して、最小限の TypeScript 環境を作ります。

mkdir ai-demo
cd ai-demo
npm init -y
npm install -D typescript ts-node @types/node
npx tsc --init

2. 「罠」のあるコードを作成

index.ts を以下の通りに作成。

index.ts

// 仮想のユーザー型定義
// 【罠1】実際は address はオブジェクトだが、string だと思い込んでいる
interface User {
  id: number;
  name: string;
  email: string;
  address: string; 
}

// APIレスポンスの型定義
// 【罠2】実際はデータが直接返ってくるが、dataプロパティに入っていると思い込んでいる
interface ApiResponse {
  data: User;
}

async function fetchUser(userId: number) {
  try {
    const response = await fetch(`https://jsonplaceholder.typicode.com/users/${userId}`);
    
    if (!response.ok) {
      throw new Error(`HTTP error! status: ${response.status}`);
    }

    // ここで型アサーションを使っているため、TSのコンパイルエラーは出ない（実行時エラーになる）
    const json = await response.json() as ApiResponse;

    // 【実行時エラー発生ポイント】
    // json.data は undefined なので、その中身にアクセスしようとして死ぬ
    console.log(`User Name: ${json.data.name}`);
    console.log(`Address: ${json.data.address.toUpperCase()}`);

  } catch (error) {
    console.error("データの取得に失敗しました:", error);
  }
}

fetchUser(1);

ちなみに、実際のデータ構造はこれ（https://jsonplaceholder.typicode.com/users/1）

{
  "id": 1,
  "name": "Leanne Graham",
  "username": "Bret",
  "email": "Sincere@april.biz",
  "address": {
    "street": "Kulas Light",
    "suite": "Apt. 556",
    "city": "Gwenborough",
    "zipcode": "92998-3874",
    "geo": {
      "lat": "-37.3159",
      "lng": "81.1496"
    }
  },
  "phone": "1-770-736-8031 x56442",
  "website": "hildegard.org",
  "company": {
    "name": "Romaguera-Crona",
    "catchPhrase": "Multi-layered client-server neural-net",
    "bs": "harness real-time e-markets"
  }
}

Level 1: 対話型アシスタント（ChatGPT）

Level 1 では、AI ツールは開発者の置かれている現場の情報をまったく知らないので、以下の情報をプロンプトに含める必要があります。

実行時エラーが発生したという状況とその内容（スタックトレース）
エラーが発生している対象のコード（ファイルの中身）

今回は、以下のようなプロンプトを作成しました。

このエラーを直してください。

---

(base) $ npx ts-node index.ts
データの取得に失敗しました: TypeError: Cannot read properties of undefined (reading 'name')
    at fetchUser (C:\Users\pbnakao\claude\ai-workspace\qiita_articles\drafts\AIコーディングツール入門\demo\index.ts:29:45)
    at processTicksAndRejections (node:internal/process/task_queues:105:5)

---

index.ts

// ユーザー型定義
interface User {
    id: number;
    name: string;
    email: string;
    address: string;
}

// ...以下、この記事では省略

実際の挙動

さて、実際にリクエストしてみましょう。

正しい指摘が返ってきていそうです。

ChatGPT が提示してきた修正案をそのままコピペしてもいいのですが、今回は提示された修正案と、手元のコードの差異を見比べながら、ひとつひとつ修正を反映していきます。

まず、「間違い1：レスポンスが data に入っていると思い込んでいる」という指摘に基づいて、誤った ApiResponse 型を削除します。

すると、19行目でコンパイルエラーが発生します。

もう一度、修正案と見比べながら、as User に変更します。

すると今度は、23~24行目でコンパイルエラーが発生するので......といった作業を繰り返し、修正の反映が完了しました。

それでは、正しく動作するか再実行してテストします。

うまくいきましたね。

Level 1 ツールを使うことで、何が変わったのか

さて、課題が解決したのでめでたしめでたし......なのですが、ここで一度立ち止まって、私たちがツールをどのように使っているのかを整理してみましょう。

まず、私はここで AI に何を代理させたのでしょうか。比較のために、AI を使わなかった場合に私がやったであろう作業を列挙してみます。

論理的推論（原因の特定）：スタックトレースを読み、console.log 等で変数をダンプし、json.data が undefined であることを突き止める。
知識の検索（仕様の調査）：公式ドキュメントや curl コマンドで実際のレスポンス構造を確認し、自分の型定義が間違っていることに気づく。
環境への変更（実装）：コードを修正する。
変更の検証（テスト）：再実行して確認する。

このうち、Level 1 ツールが代理したのは 「1. 論理的推論」 と 「2. 知識の検索」 です。

逆に言えば、「環境への変更（修正の反映）」 と 「変更の検証（テスト）」 は、依然として人間が担当しています。また、AIを使わなければ必要のなかった 「コンテキストの運搬（コピペ）」 という作業が新たに発生しました。これは Level 2 以降のツールと比較した際の、Level 1 の大きな特徴（制約）です。

これらを単に「面倒な作業」と捉えるのであれば、Level 2 以降のツールに移行することをおすすめします。しかし私は、あえて Level 1 ツールに留まるメリットも存在すると考えています。

ラバーダック・デバッグ効果：コンテキストを第三者（AI）に伝えるために状況を言語化する過程で、自分自身が状況を客観的に整理でき、より本質的な課題に気づくことがある。
記憶の定着：実際に自分の手で修正コードを打ち込むことで、その言語の仕様やプロジェクトの構造が「手癖」として記憶に定着する。
基礎体力の維持： AI の提案を鵜呑みにせず、「提案と手元のコードを見比べる」というレビュープロセスを挟むことで、コーディングスキルが維持・向上する。

「自分の手で書く感覚」を重視する人や、AI との対話自体が思考の整理になると感じる人にとって、Level 1 ツールは依然として強力なパートナーであり続けるでしょう。

Level 2: 環境埋め込み型（GitHub Copilot）

Level 1 では「状況を言語化して AI に伝える」必要がありました。 Level 2 である GitHub Copilot 最大の特徴は、ツールが 「環境の中に位置（Situated within）」しており、「コンテキスト（文脈）の共有」 が自動化されている点です。

実際の挙動

同じバグ（APIレスポンスの型不整合）を、GitHub Copilot で直してみましょう。

今回は、エディタ（VS Code）上でコードを選択し、インラインチャット（Cmd+I / Ctrl+I）を呼び出します。入力する指示は一言だけで十分です。

このバグを直して

Level 1 のように、エラーログやファイルの中身をコピペする必要はありません。

Copilot は、以下の情報を自動的に「感知（Sense）」しています。

現在開いている index.ts のコード全体
カーソル位置の文脈
（場合によっては）別タブで開いている関連ファイル

これらを統合して、「あ、ApiResponse の型定義と、実際のアクセス方法が食い違っているな」と推論し、エディタ上に直接修正案（Diff）を提示してくれます。

人間がやるべきことは、提示された変更を確認し、「Accept（承認）」ボタンを押すことだけです。

こんな感じで次々と修正してくれます。

それでは、正しく動作するか再実行してテストします。

うまくいきました。

Level 2 ツールを使うことで、何が変わったのか

Level 1 と同様に、ここでも「何を代理させ、何が人間の役割として残ったか」を整理します。

AI に代理させたこと：

コンテキストの運搬：コピペの手間がゼロになりました。
論理的推論（原因の特定）: Level 1と同様。
知識の検索（仕様の調査）: Level 1と同様。
環境への変更（実装）: 修正案を考えるだけでなく、それをエディタに反映する（タイプする）物理的な作業まで委譲しています。

人間がやるべきこと：

レビュー・承認：変更作業をAIに委譲する代わりに、その変更に対するレビュー・承認の責任を負います。
変更の検証（テスト）：再実行して確認する。

Level 1 との大きな違いとして、「コンテキストを第三者（AI）に伝える手間」 がなくなっています。それによって、エディタから視線を外すことなく、AIの支援を受けることができました。

あえてLevel 2 ツールを使うメリット

「Level 3 のほうが自律度が高いなら、もう Level 2 は不要なのでは？」と思われるかもしれません。しかし、Level 2 のほうが適しているシーンも存在します。

それは、「コーディングのリズムを維持したいとき」 です。

スピードとリズム
Level 3 のエージェントは、指示を受けてから動き出すまでに数秒〜数十秒の「思考時間」を要します。一方、Level 2 の推論はミリ秒単位です。開発者が「えーと」と考えた瞬間に答えが出ています。「変数の名前を変えたい」「定型的なロジックを書きたい」といったマイクロなタスクにおいては、いちいちエージェントに指示を出すよりも、Level 2 の補完を受けながら自分で書くほうが圧倒的に速く、リズムが崩れません。
「説明するより書くほうが早い」領域
コーディングに慣れている人にとっては、「やりたい処理のイメージはあるが、それを自然言語で説明するのは面倒」というケースがあります。Level 2 は、開発者がコードを数文字打ち込むだけで意図を察知します。「言葉による指示（プロンプト）」を必要とせず、「行動（キーストローク）」で指示を出せる 点こそが、Level 2 の最大の強みです。

特徴	Level 2 (Copilot)	Level 3 (Claude Code, Cursor)
得意な粒度	関数の中身、数行のロジック	機能全体、複数ファイルの改修
人間の役割	運転手（ハンドルを握る）	指令官（目的地を伝える）
メリット	速い、リズムを崩さない	複雑な問題を丸投げできる

AIを活用して開発の生産性を向上させたいが、あくまでハンドルは自分で握っていたいと考えるエンジニアにとって、Level 2 ツールはちょうどよく手を貸してくれる相棒となるでしょう。

Level 3: 自律エージェント型（Claude Code）

最後に、Level 3 の世界を見てみましょう。 Level 2 との決定的な違いは、「行動 → 観察 → 次の行動」というループを自律的に回せる（再帰性がある） 点です。

今回は、Anthropic 社が提供する CLI ツール Claude Code を例にします。

実際の挙動

ターミナルで claude コマンドを起動し、自然言語で指示を出します。 Level 2 と違い、ここでは「コードの補完」ではなく、「タスクの完遂」 を依頼します。

> index.tsを実行して、エラーが出たら修正して。正しく動くようになるまでやって

まずはフォルダーの構成を確認して、ts-node がインストールされていることを確認してくれました。その上で、コマンドを生成して、実行していいか？と聞いてくれています。

「Yes」を選択して実行させます。少し待つと、期待通りに実行時エラーが発生しました。

すると、すぐに原因を特定し、修正案を提示してくれました。

● エラーの原因がわかりました。JSONPlaceholder APIは{ data: User }形式ではなく、直接Userオブジェクトを返します。また、addressはstringではなくオブジェクトです。

もちろん、関数の中身も整合をとって修正してくれます。（たまにエディタ上ではなく、コンソール上で差分を見せてくるのだけど、なぜなのか・・・）

ここが Level 3 の特徴ですが、修正して終わりではなく、修正が正しく反映されたか検証するところまでやってくれます。

検証が完了したようです。

Level 3 ツールを使うことで、何が変わったのか

それでは、「AIに何を代理させ、何が人間の役割として残ったか」を整理しましょう。

AI に代理させたこと：

コンテキストの運搬： Level 2 と同様。
論理的推論（原因の特定）: Level 1 と同様。
知識の検索（仕様の調査）: Level 1 と同様。
環境への変更（実装）: Level 2 と同様。
変更の検証（テスト）： Level 2 までは人間が手動で行っていた検証も、ついにAIに委譲しました。

人間がやるべきこと：

レビュー・承認：変更作業をAIに委譲する代わりに、その変更に対するレビュー・承認の責任を負います。

重要なのは、たんに「変更の検証」が人間の手から離れたことではなく、それによって 「実行して、エラーを見て、調査して、直して、また実行する」というループ（OODAループ） が完成し、課題解決のプロセス全体をAIに委譲することになったという点です。

Level 2 ツールまでは、人間がAI とともに このループを回していましたが、Level 3 ツールを使うようになった途端、人間はもはやこのループを外から眺めているレビュワー・承認者でしかありません。ここまでくると、もはや「ツールを使う≒自身のOODAループの中に特定の道具を組み込む」というレベルの話ではなく、まさに自律性をもった存在（エージェント）が自分の隣にいる、という状況になっています。

ツールが再帰性（フィードバックループ）を獲得したことは、人間とツールとの関係そのものが変革しているという点で、ひとつの革命だと言っていいでしょう。その意味で、Level 2 と Level 3 の間にある差異は、Level 1 と Level 2 の間にある差異よりも重大です。

まとめ：各ツールをいかに使い分けるか

ここまで、自律性レベルの異なる 3 つのツールを見てきました。最後に、これらを日々の開発でどのように使い分ければよいのか、その指針を整理してこの記事を締めくくりたいと思います。

重要なのは「レベルが高いほど優れている」わけではなく、「今の自分がどういうモードで開発したいか」 に合わせてツールを選ぶことです。

Level 1 (ChatGPT 等): 「あえてゆっくり」進めたいとき

Level 1 ツールの特徴は、コンテキストの運搬や実装の手間を人間が負う点にあります。これは一見非効率ですが、「手を動かすプロセス自体」に価値があるシーン では、最適な選択肢となります。

向いているシーン：
- 自己研鑽とスキル習得： AI に教材や課題を作ってもらい、それを自分自身の手でコーディングするとき。あえて AI にコードを書かせず、自分の指でタイプすることで、技術が身体化（記憶に定着）されます。
- 深い理解を伴うコーディング： AI の提案と手元のコードを見比べながら、「なぜこの修正が必要なのか」「他に方法はないか」をじっくり考えつつ、自分の手で修正を適用するプロセス。

ここでの主役はあくまで「人間の学習」です。効率を度外視してでも、理解の解像度を高めたいとき は、あえて Level 1 を選びましょう。

Level 2 (Copilot 等): 「リズムと主導権」を両立したいとき

Level 2 ツールの特徴は、思考のスピードを止めない即応性です。 AI の強力なサポートを受けつつも、タスク進行の 主導権（ハンドル）はあくまで自分が握っておきたいシーン で真価を発揮します。

向いているシーン：
- テスト駆動開発（TDD）：テストケースの作成は、仕様（意図）を確定させる作業そのものです。ここを丸投げせず、自分の意図をテストコードとして書き出しつつ、面倒なボイラープレート記述だけを Copilot に任せることで、リズムよく開発を進められます。
- マイクロ・リファクタリング：「動くけれど汚いコード」を自分で書いた直後に、インラインチャットで「もっときれいに書いて」と指示する。秒単位でフィードバックをもらい、即座に採用・却下を判断するスピード感は Level 2 ならではです。

「速く進みたいが、勝手に決められたくはない」。そんなフロー状態を維持したいときは、Level 2 が最高の相棒になります。

Level 3 (Claude Code 等): 「面倒ごとを丸投げ」したいとき

Level 3 ツールの特徴は、自律的な試行錯誤です。人間が介入する必要がない 抽象度の高いタスク や、逆に人間がやりたくない 泥臭い作業 において、その自律性が輝きます。

向いているシーン：
- 0→1 のプロトタイピング（壁打ち）：「要件を詰めるために、とりあえず動くものが欲しい」という段階。細かいコードの質よりも、まずは形にしてもらい、それを叩き台にして議論を深めるような使い方が向いています。
- 調査と環境構築： Web 上の文献を読み込んで情報を整理させたり、依存関係が複雑な環境構築エラーを解消させたりする作業。「考える」よりも「調べる・試す」に時間がかかるタスクは、エージェントに丸投げする選択も悪くないかもしれません。

自分の脳のリソースを本質的な設計や意思決定に残すために、「それ以外」を任せる のが Level 3 の役割です。

おわりに

AI コーディングツールは、「プログラマを不要にするもの」ではなく、「プログラマが『どこに脳を使うか』を選択可能にするもの」 です。

たしかに、Level 3 ツールの登場は革命的ですが、その能力に過度に依存しすぎるあまり、それを使う人間が「自分の仕事」を見失うようでは本末転倒です。

各ツールの特徴を把握し、自分の状況に合わせて適切に使い分けられること。それが、これからのエンジニアに求められるスキルなのではないでしょうか。

SAE J3016 は自動運転車の自律性を 0〜5 の 6 段階で定義した標準規格です。「人間の関与度」を軸に分類する点が AI エージェントの分類に応用されています。参考: SAE Levels of Driving Automation ↩
Sema4.ai による 5 段階分類。参考: The Five Levels of Agentic Automation ↩
AI Native Dev による自動運転アナロジーを用いた分類。参考: The 5 Levels of AI Agent Autonomy ↩
Knight First Amendment Institute によるユーザー視点での 5 段階分類。参考: Levels of Autonomy for AI Agents ↩
NVIDIA はセキュリティ観点からエージェントの自律性レベルを分類しています。参考: Agentic Autonomy Levels and Security ↩
Is it an Agent, or just a Program?:A Taxonomy for Autonomous Agents ↩