AIコーディングの評価軸を変える「委譲レベル」――JetBrainsのAIDEs Frameworkを実務で読み解く

AI開発ツールは「どれだけ賢いか」だけでは測れない

AIコーディングツールを比較するとき、多くの開発者はモデルの性能、コード生成の精度、ベンチマーク結果、対応するIDEなどに注目します。しかし、実際の開発現場で重要なのは、AIが高性能かどうかだけではありません。

自分たちのチームが、どの仕事を、どの程度までAIに任せられるのか。

この問いに焦点を当てたのが、JetBrainsが提唱する「AIDEs Framework（Artificial Intelligent Development Environments Framework）」です。AI開発ツールの進化を、単なる機能追加の歴史ではなく、ソフトウェア作成における仕事の委譲範囲が広がってきた過程として整理しています。

本稿では、AIDEs Frameworkの概要を紹介しながら、AIエージェントを導入するエンジニアや開発組織が、何を基準に評価し、どのように開発プロセスを見直すべきかを考えます。

AI開発の進化は「委譲範囲の拡大」だった

JetBrainsの整理によれば、AI開発ツールはおおむね次のように進化してきました。

• 1行単位のコード補完
• 複数行やコードブロックの生成
• IDE内のチャットアシスタント
• コード編集や検索を統合したAIコードエディター
• 開発タスク全体を実行するコーディングエージェント
• クラウド上で自律的に開発作業を進めるエージェント

これは、AIが「コードを書く機能」を獲得したというだけの話ではありません。人間が担っていた作業のうち、AIに任せる範囲が、アクションからタスク、さらにプロジェクトや機能単位へ広がってきたと見ることができます。

従来の開発ループが、エディター上での「実装、検証、修正」だったとすれば、エージェント型開発では「計画、実行、レビュー」が中心になります。開発者はコードを直接書く時間を減らし、AIに何をさせるか、結果をどう評価するかに多くの時間を使うようになります。

AIDEs Frameworkの3つの軸

AIDEs Frameworkは、AI開発を次の3つの軸で捉えます。

1. ソフトウェア作成の工程

対象となるのは実装だけではありません。AIDEs Frameworkでは、ソフトウェア作成を次のような工程に分けています。

• アイデアやコンセプトの形成
• 要件定義、計画、設計、アーキテクチャ設計
• 実装
• テスト、検証、品質保証
• デリバリー、保守、フィードバック収集

現在、AIの利用はブレインストーミングとコーディングに集中しています。一方で、要件定義、テスト戦略、セキュリティ検証、デプロイ、運用監視などは、まだ十分にAI化されていない領域です。

この偏りは、今後の導入余地を示しています。AI導入を「コード生成の効率化」に限定すると、ソフトウェア開発全体に対する効果を見誤る可能性があります。

2. 委譲レベル

AIDEs Frameworkの中核が、AIに任せる仕事の範囲を示すL1〜L5の分類です。

現在広く利用されているコーディングエージェントは、概ねL3付近に位置づけられます。Claude CodeやCodexのようなツールは、コード作成や低レベルの設計・実装をかなり広く実行できます。

ただし、何を作るべきかという事業上の判断や、複数の選択肢から戦略的な方針を決める仕事まで、無条件に任せられるわけではありません。人間は依然として、タスクの定義、重要な意思決定、成果物のレビューを担います。

L4では、AIが個別タスクではなく、バックエンド開発のような機能単位を担当します。人間は細かな指示を出すのではなく、重要な判断や最終成果を承認する役割に近づきます。

L5は、AIを単なる開発者の代替ではなく、組織内の「能力センター」として扱う段階です。人間が事業目標や成果指標を定め、技術選定や実装方法の大部分をAI側に委譲する世界が想定されています。

3. 開発が行われる組織コンテキスト

同じAIツールでも、個人開発、スタートアップ、エンタープライズでは求められる条件が異なります。

• 個人開発では、導入コストや使いやすさ、試行錯誤の速さが重視される
• 中小企業や自律性の高いチームでは、開発速度と柔軟性が重視される
• 大企業では、セキュリティ、コンプライアンス、既存システムとの統合、監査性が重視される

したがって、「最も賢いツール」を一つ選べばよいわけではありません。自社の開発規模、リスク許容度、コードベースの複雑さ、意思決定の構造を踏まえ、適切な委譲レベルを設計する必要があります。

実務で重要なのは「モデル性能」より「エージェント契約」

AIDEs Frameworkが示す重要なポイントは、委譲レベルがAIだけの属性ではないということです。

同じAIエージェントでも、開発者が単体テスト生成だけを任せるならL2、機能実装全体を任せるならL3になります。さらに、重要な決済処理や認証基盤では、AIの能力が高くてもL2相当まで委譲範囲を狭める判断があり得ます。

つまり、委譲レベルはAIの性能ではなく、人間とAIの間で結ばれる仕事上の契約によって決まります。

実務では、次の項目をタスクごとに定義しておくと、委譲範囲を設計しやすくなります。

• AIが担当する作業の範囲
• 人間が必ず承認する判断
• AIに参照させるコンテキスト
• 成果物の受け入れ条件
• 失敗時に人間へエスカレーションする条件
• ログや変更履歴などの監査方法
• 本番環境へ反映する前の検証手順

このルールが曖昧なままエージェントを導入すると、AIが作業を進めても、人間がどこまで責任を持つのか分からなくなります。

AIエージェント導入で変わる開発者の仕事

AIへの委譲が進むと、開発者の役割は単純に「コードを書く人」から「開発作業を設計し、監督する人」へ変わります。

特に重要になるのは、次の能力です。

要件を実行可能な形にする能力

AIは曖昧な依頼よりも、目的、制約、前提条件、受け入れ条件が明確な依頼を得意とします。プロンプトの技巧だけでなく、要件を構造化し、AIが検証できる形に落とし込む能力が重要になります。

アーキテクチャと境界を設計する能力

AIに実装を任せるほど、システム境界、データモデル、依存関係、セキュリティ方針などの上位設計が成果物の品質を左右します。コードを生成する速さよりも、どこに責務を配置するかを判断する力が重要になります。

レビューを効率化する能力

AIが大量のコードを生成する場合、すべての行を人間が同じ深さで確認するのは困難です。レビューは、実装の細部だけでなく、次の観点を中心に再設計する必要があります。

• 要件を満たしているか
• 既存システムとの整合性があるか
• セキュリティ上の問題がないか
• 障害時の振る舞いが定義されているか
• テストがリスクを十分にカバーしているか
• 将来の変更や運用に耐えられるか

コンテキストの欠落を管理する能力

AIに作業を任せるほど、人間がコードの細部を把握する「没入」は低下します。これは生産性向上の裏側にあるリスクです。

そのため、設計書、決定事項、テスト結果、変更理由、運用メトリクスなどを、AIと人間が共有できる形で管理する必要があります。AIに任せる範囲を広げるには、コンテキストを失っても全体を把握できる仕組みが欠かせません。

開発チームが始めるべき実践

AIエージェントを導入する際は、いきなりL4やL5を目指すのではなく、タスクのリスクと委譲レベルを対応させるのが現実的です。

まずはタスクを分類する

次のように、失敗時の影響と必要な判断の深さでタスクを分類します。

• 低リスクの定型作業：L2〜L3
• 独立した小規模機能の実装：L3
• 既存システムに大きく影響する変更：L2〜L3
• 認証、決済、個人情報などの重要領域：人間の承認を必須にする
• 本番環境の変更や運用判断：段階的な自動化と監査を組み合わせる

受け入れ条件を先に定義する

AIに「この機能を作って」と依頼するだけでは、レビューの基準が不明確になります。入力、出力、エラー処理、性能、セキュリティ、テスト条件を先に定義し、AIが自分の成果を検証できる状態を作ります。

AI利用の効果をコード量だけで測らない

生成されたコードの行数やチケット消化数だけでは、AI導入の成果は判断できません。次のような指標を組み合わせるべきです。

• リードタイムの変化
• レビューで発見された不具合の傾向
• リリース後の障害件数
• テストカバレッジとテストの有効性
• 手戻りや再作業の量
• 開発者が要件定義や設計に使える時間

AIがコードを速く生成しても、障害やレビュー負荷が増えれば、チーム全体の生産性は向上しません。

AI導入の次の焦点は、コードの外側にある

AIDEs Frameworkから読み取れるのは、AI開発の競争がコード生成だけで終わらないということです。今後は、要件、設計、テスト、デプロイ、運用、ユーザーフィードバックをつなぐ、より広い開発基盤へとAIの利用範囲が広がる可能性があります。

そのとき、AIは「便利なハンマー」ではなく、ソフトウェア作成に投入する知性のリソースとして扱われるようになります。人間は個々の実装を直接担当する割合を減らし、意図の定義、優先順位付け、品質保証、リスク管理、複数エージェントの調整を担うことになるでしょう。

ただし、これは人間の役割が不要になるという意味ではありません。むしろ、何を作るのか、なぜ作るのか、どの品質を許容するのかを決める責任は、より明確に人間へ残ります。

まとめ：AIツール選びから、委譲設計へ

AIコーディングツールを評価するとき、モデルの性能や機能一覧だけを見ると、導入後の姿を見誤りやすくなります。重要なのは、AIがどれだけ賢いかではなく、チームがどの仕事を、どの条件で、どのレベルまで委譲できるかです。

AIDEs Frameworkは、AI開発を次のように捉え直すための視点を提供します。

• AI導入の対象は実装だけでなく、ソフトウェア作成全体である
• 委譲にはL1からL5まで段階がある
• 委譲レベルはAIの能力ではなく、人間との関係によって決まる
• 委譲を広げるほど、要件定義、設計、監督、品質保証が重要になる
• 組織規模やセキュリティ要件によって、適切な委譲範囲は異なる

これからの開発チームに必要なのは、「最も高性能なAI」を探し続けることだけではありません。自分たちの開発プロセスを分解し、どの工程をAIに任せ、どこに人間の判断を残すのかを設計することです。

AI時代の開発力とは、コードを書く速さだけでなく、適切な仕事を適切なレベルで委譲し、その結果に責任を持つ力へ変わりつつあります。

出典： JetBrains Blog