コーディングエージェントとは

コーディングエージェントとは

コーディングエージェントは、目標に向けて、結果を確認しながら次の作業を自律的に反復するAIです。ソースコードを参照して編集し、コマンドやテストを実行して、その結果から次の作業を決定します。この動きは、Claude Codeの資料で文脈の収集、行動、結果の確認の3段階が重なり合う繰り返しとされています。

たとえば不具合の報告を入力すると、関係するファイルを検索して参照し、修正を記述します。続けて自動テストを実行し、失敗すれば修正して再実行します。最後の変更内容は人に提示されます。採用は承認つきの運用なら人が確認して決定します。正否を自動テストで確認できる作業は、結果を機械で確認できるため、委任の候補にしやすい作業です。後述の判断基準で扱います。

コード補完やチャットのAIとの違い

入力中のコードの続きを提案するコード補完では、提案を適用し、実行し、結果を確認して次の作業を決定するのは人です。コーディングエージェントは、この繰り返しをAIが担う点で異なります。質問に回答するだけのチャットのAIは、コードを実行して検証しないため、別のものです。

コーディングエージェントは、調査から修正と確認までを担当し、結果を報告する担当者に近い存在です。端末上で稼働する製品もクラウド上で稼働する製品もあります。途中で介入して作業を停止したり、方針を変更したりできる製品があります。仕様は製品ごとに異なるため、導入時に確認します。

コード補完やバイブコーディングとの違い

人の作業は目標の指示と結果の確認が中心です。人が提案を適用する支援と、AIが複数の手順を進めて人に確認を依頼する支援が、同じ製品の中で別の機能として提供されている例もあります。

観点	コード補完	コーディングエージェント
参照する範囲	主に現在のファイル	プロジェクト全体と実行結果
次の作業を決定する主体	人	AI。人は途中で介入できる
実行とテスト	人	AI。付与された権限の範囲内
誤りの影響	採用した提案の箇所	権限を付与した範囲全体

バイブコーディングは製品の種類ではなく、AIの出力を精査せずに採用する進め方です。コーディングエージェントを利用しても、変更を確認してテストし、説明できる状態で採用するなら、通常のソフトウェア開発だという整理があります。

効果とリスク

効果

調査、修正、テスト実行を人が1件ずつ行う手間が、作業の種類と環境によっては減少することが効果です。テストの追加では不足箇所の洗い出しと記述が、ライブラリの更新では影響箇所の修正が、調査では関係ファイルの探索が、作業によってはAIの担当になります。

リスク

リスクは運用上のものと、出力そのもののものに分割できます。

運用上のリスク

• レビューの滞留。変更が増加しても、レビューに配分できる時間は自動では増加しない
• 提供の安定性の低下。2025年のDORA（DevOps Research and Assessment）の報告は、AIを利用した開発全般で、利用と提供速度に正の関係があり、安定性とは負の関係が引き続き確認されたとされている。自動テストや版管理などの仕組みが不十分な状態で変更量が増加すると、不安定さを生じるともされている

出力そのもののリスク

• テストが手薄な領域での誤り。エージェントはテストの結果を確認して修正を継続するため、テストが不足している部分では、合格しても正確さを保証しない
• 権限の範囲での誤操作。付与した範囲で、意図に反する削除や送信が実行される
• 外部の文書に混入した命令。課題票などに秘匿した指示でエージェントを操作する攻撃で、プロンプトインジェクションと呼ばれる。製品側の対策には限界があるため、エージェントが取り込む文書は書き込み権限のある人のものに限り、出力される変更とコマンドは人が確認する。これはこの記事の運用上の目安である
• 生成コードの権利とライセンス。権利の扱いは事業者の利用規約に定められている部分があり、生成物が既存のOSS（オープンソースソフトウェア）と一致する場合もある。契約の確認と、社内のライセンス確認の運用を決定する
• 存在しないライブラリ名の提案。コード生成AIが存在しないパッケージ名を出力した例が研究で確認されており、同名の悪意あるパッケージを導入する恐れがある
• 説明できないコードの蓄積。後の修正に時間を要する場合がある

委任してよい作業と人が判断すべき作業はどう区分するか

結果の正否を機械で確認でき、取り消しが可能で、影響が限られる作業から委任します。何を開発するかの判断と取り消しが困難な操作は人が担い、作業の区分は次の3つの問いで判定します。

3つの問い

• 正否を機械で確認できるか。自動テストやビルドの成否など、人のレビュー前に合否を判定できる手段があること。技術者への質問で、主要な機能を網羅する自動テストがあるか、変更のたびに自動で実行されているかを確認できる
• 取り消しが可能か。作業用に分けた履歴であるブランチ上の変更は、破棄すれば元の状態に復旧できる。外部への送信や顧客データの流出は復旧できず、本番への反映や削除も、復旧に大きな手間と費用がかかる
• 影響が限られるか。1回のレビューで通読できる数百行以下の変更が目安になる。これはこの記事の目安である

作業別の扱い

作業の例	扱い	理由
テストの追加、再現手順のある不具合の修正	委任して人がレビュー	自動テストで合否が分かり、取り消しが可能
ライブラリ更新に伴う修正、定型的な書き換え	委任して人がレビュー	変更が機械的で、ビルドとテストで確認できる
コードの調査、影響範囲の洗い出し	委任して結論は人が確認	コードを変更しない
テストのないコードの変更	現状の動作を固定するテストを先に追加させ、人が確認してから委任	正否を確認する手段がない
何を開発するか、優先順位、仕様の解釈	人が決定する	正解がコードの外にあり、事業の判断になる
認可、個人情報、決済に関連する変更	人が設計し、詳細にレビューする	テストに合格しても不十分な場合がある
本番環境の操作、鍵の発行、顧客データの取り扱い	書き込みの権限は付与しない	取り消しが困難

技術者が1人の場合

技術者が1人の場合はレビューする人がいないため、自動テストと静的解析を必須にし、変更の範囲を限定して、事後に別の担当が確認する形で補完します。コードを理解して説明できる人が社内にいない場合は、本番に関連する変更を委任せず、試作や社内の小さなツールに限って利用します。

権限・レビュー・機密情報の決め方

権限は段階的に付与する

• 読み取りのみ。コードの閲覧と調査
• 作業用ブランチへの書き込みと、ローカル環境でのテスト実行
• 外部との通信、ライブラリの追加、共有ブランチへの反映。人の承認つき
• 本番環境、顧客データ、課金、削除、外部への送信。付与しない

最初は上の2段階だけを付与し、3段階目は実績を確認してから、承認つきで追加します。4段階目は人が実行します。共有ブランチへの反映で本番へ自動公開される構成なら、3段階目を付与する前に、承認なしでは公開されない形にします。

3段階目へ拡大する基準は開始前に自社の合格ラインとして決定し、差し戻しの理由を種類別に記録して評価します。修正が少ないことは書き込みの安全性の証明になりません。

デフォルトの権限は製品ごと、バージョンごとに異なり、更新で変わることがあります。承認の可否を別のAIモデルが代行する自動のモードを持つ製品もあり、その場合は人の承認になりません。段階付与を維持するには、起動時のモードの固定が必要です。製品の資料で、デフォルトの権限を導入時に最新の内容で確認します。

レビューは依頼者と別の人が実施する

プルリクエストは変更を確認し、承認後にプロジェクトのコードへ統合するための依頼です。依頼した本人がエージェントのプルリクエストを承認できないようにして、必須承認の規則が想定する統制を維持している製品があります。自社でも承認は別の人が行い、次の点を確認します。

• 変更の範囲が依頼と一致しているか
• テストの削除や条件の緩和、ライブラリの追加、設定や権限の変更がないか
• 秘密情報がコードに直接書かれていないか

機密情報は契約と作業環境で保護する

モデルを事業者のサービスで処理する製品では、端末で稼働していても、指示文とモデルが参照したコードが事業者に送信されます。クラウドで実行する製品では、さらにリポジトリが事業者の環境に複製される場合があります。同じ製品でも契約によって扱いが異なり、個人向けのプランと法人向けの条件では、学習への利用の扱いが違うことがあります。業務のコードは会社の契約で利用し、私的なアカウントでは利用しません。契約条件では次の3点を確認します。

• 学習への利用
• データの保存期間
• 通信の範囲

サンドボックスはエージェントが実行するシェルコマンドを隔離する機能で、アクセスできる範囲を制限します。デフォルトで無効の製品があり、有効にしても、デフォルトの設定では認証情報のファイルを含む範囲を読み取れる場合があります。作業用の端末に本番の鍵を保管せず、作業専用の鍵だけを利用します。

導入後に継続するコスト

• 利用料。モデルの選択、コードの規模、使い方で大きく変わる。処理量に応じた課金では特に見積もりにくいため、小さな試験導入で測定する。費用の目安は製品の資料で最新の内容を確認する
• レビューの工数と前提の整備。変更の量に応じてレビューが増加し、自動テスト、ビルド手順、エージェントに参照させる作業ルールの文書も必要になる
• 権限と記録の管理。担当者を決定し、付与した権限と実行の記録を定期的に確認する。機能、デフォルトの権限、料金、モデルの挙動は更新で変化するため、その追従も含む
• 人材。指示を記述し、結果を評価できる技術者の時間が必要になる

試験導入の範囲と記録

試験導入はソースコードと変更履歴を保管する1つのリポジトリで、数人が1か月から2か月を目安に行います。開始前に、同種の作業を人が行ったときの所要時間、レビュー時間、統合後の不具合と取り消しを数件記録しておきます。試験導入では次の項目を記録します。

• 統合された割合
• 差し戻しの回数
• 1件あたりのレビュー時間
• 利用料
• 統合後の不具合と取り消し

レビュー時間と利用料を含めた1件あたりの費用が、人が行う場合の費用を下回る作業の種類だけ、範囲を拡大します。ただし、統合後の不具合と取り消しが、人が行う場合より増加していないことが条件です。件数が少ない間は件数の比較ではなく内容を個別に確認します。これは出典のない、この記事の目安です。

よくある誤解

利用すれば確実に作業時間が短縮される

実際は作業と環境ごとに異なります。非営利団体のMETR（Model Evaluation and Threat Research）は、経験豊富なOSS開発者16人を対象に実験しました。チャット、Cursorのエージェントモード、補完を含む2025年初めのツール（主にCursor）を自分のリポジトリの課題で利用すると、完了まで19%長くかかりました。この結果は最新ではないと注記されており、現在の製品にそのまま当てはまるとは限りません。2026年2月の更新では、参加者との会話に基づく推測として、作業が高速化している可能性が高いものの、程度を示す強力な証拠はないとされています。自社の効果は試験導入で測定します。

製品の安全機能があれば設定やレビューは不要

実際は製品の安全機能を人の確認の代わりにはできません。Claude Codeの資料は、承認の前にコードとコマンドの安全性を確認するのは利用者の責任だとし、どの仕組みも攻撃を完全には防止できないと明記しています。

技術者が不要になる

実際は技術者が不要になるわけではありません。何を開発するかの判断、レビュー、権限の設計は人が担います。人が確認しながら利用する形が主流だと、2026年のStack Overflowの調査でも示されています。