8月2日、GartnerのSenior Director AnalystであるShiva Varmaが「A Practical Guide to AI Engineering for Software Engineering Leaders」と題した記事を公開した。LLMブームを経てAIエージェントへの期待が急速に高まる一方、多くの組織では「何を作るべきか」「どこから始めるべきか」という判断そのものが曖昧なままプロジェクトが走り出しているのが現実だ。Gartnerのアナリストとしてエンジニアリング組織の動向を広く観察してきたVarmaは、この問いに対して「AI搭載アプリケーションかAIエージェントか」という最初の選択から始まる実践的な指針を示している。

本記事はAI開発の現場に立つリーダー層に向けて、AIエンジニアリングの「何を作るか」「誰が作るか」「どう広げるか」という3つの問いに実践的な答えを示している。

最初の問い：「AI搭載アプリ」か「AIエージェント」か

記事の核心はここにある。AIエンジニアリングにおける最初の判断は、AI-enabled application（AI搭載アプリケーション）とAI agent（AIエージェント）のどちらを構築するかだ。

AI-enabled applicationは、アプリケーションコードがワークフローを制御し、特定の処理ポイントでモデルを呼び出す構造をとる。入出力が予測可能で、障害モードも把握しやすい。具体例としては以下が挙げられている：

• 文書の要約・情報抽出
• コンテンツの分類とルーティング
• コード補完・インライン提案

対してAIエージェントは、エージェント自身がワークフローを制御する。目標に向けて推論し、計画を立て、ツールを選択し、次に何をすべきかを自律的に決定する。深層調査システム、インシデントのトリアージ・解決エージェント、自律コーディングエージェントなどが例として示されている。

この区別がリーダーにとって重要な理由は明確だ。エージェントは複数ステップにわたる動的な意思決定を行い、状況に応じてアプローチを変える。そのぶん、障害モードも創発的（emergent）になり、監視・テスト・ガバナンス・リスク管理の要件が跳ね上がる。LLMの普及によって「とりあえずエージェントを作ろう」という判断が増えているが、複雑性とリスクが一段高いことをリーダーが正しく認識していないと、ガバナンス設計が後手に回るという問題が業界で繰り返し起きている。

記事はさらに踏み込んで、自律性はバイナリな選択ではなくスペクトラムだと指摘する。「観察して助言するだけ」のシステムから「完全に独立して行動する」システムまで段階がある。ガバナンスの強度は、その自律性のレベルに応じてスケールさせるべきであり、一律に適用するものではない。

構造化・予測可能なワークフローにはAI-enabled application、複数ステップの推論と意思決定が必要なタスクにはエージェント、という使い分けが基本原則として示されている。多くの組織は最終的に両方を活用することになる。

チームのスキル：何を育てるか

AIエンジニアリングの採用には、リーダー層と個人貢献者（IC）の両レベルで新しいコンピテンシーが必要だとされる。

リーダー層が習得すべき領域として記事が挙げるのは以下だ：

• チーム構成とワークフォースプランニング
• スキルギャップの特定とアップスキリングの機会
• トークンエコノミクス、計算コスト、ベンダー選定基準、ビルド vs バイ判断といったAI固有のコスト・リソース考慮事項
• 成功指標の定義、AIのトレードオフと障害モードの理解、ガードレールの設計
• 新たな規制・開示要件への対応

エンジニアリングチーム側には、以下の基礎とスキルが求められる：

• モデルがどのように出力を生成するかの理解、非決定的（nondeterministic）な挙動を前提とした設計
• プロンプティング、AI駆動の問題分解、統合パターン、評価駆動開発（evaluation-driven development）
• データ品質がモデル性能に与える影響、AIシステムへの情報共有におけるプライバシーへの配慮

なお、評価駆動開発とは、AIシステムの出力品質を継続的に評価する仕組みを開発プロセスの中心に置くアプローチを指す。従来のソフトウェア開発におけるテスト駆動開発（TDD）に近い発想だが、LLMの非決定的な挙動に対応するため、定量的・定性的な評価指標の設計と継続的な計測が不可欠になる点が異なる。このスキルはLLMを活用したプロダクト開発において特に重要とされており、記事でも重点的に言及されている。

加えて組織全体で、AIシステムを本番環境に移行する前のプライバシー・セキュリティ・コンプライアンスリスクを審査するプロセスの確立が不可欠だと強調されている。

スケールの条件：利用数ではなく、日常業務への定着

記事が定義する「AIエンジニアリングの成功」は、デプロイしたモデル数やエージェント数ではなく、AIが日常ワークフローにどこまで埋め込まれたかによって測るべきだという点が印象的だ。

スケールを進める際の出発点として推奨されるのは、頻繁に行われるタスク、知識のボトルネック、繰り返しの単純作業といった「リアルなビジネス課題」の解決だ。従業員の働き方を変えることを強制するのではなく、既存のツール・システム・プロセスに直接統合することで摩擦を減らすアプローチが重要とされる。

信頼の構築も採用拡大の鍵だ。透明な推論プロセス、引用、検証パターン、確信度インジケーター、人間による監視の明確なオプションといったメカニズムがユーザーの信頼を育てる。

また、AI活用の早期チャンピオンやパワーユーザーに対して報酬とポジティブなフィードバックを与えることが、より広範な採用を促す戦術として紹介されている。こうしたユーザーはフィードバックの提供、価値の実証、AIへの投資判断への影響力という観点で重要な存在だ。

継続的な指標追跡（タスク完了率、エンゲージメント、AI支援の実行ボリューム等）を通じてビジネスインパクトを測定し続けることで、実験フェーズを脱して企業価値の実現へと移行できる。

詳細はA Practical Guide to AI Engineering for Software Engineering Leadersを参照していただきたい。