なぜ今この議論が起きているのか
AIのコーディング能力は、私たちがそれを使いこなす能力を超えるスピードで進歩しています。SWE-Benchスコアの改善が、エンジニアリングリーダーシップが本当に気にする生産性指標と連動しない理由がここにあります。Anthropicのチームが同じモデルを使って10日間でCoworkを出荷する一方、別のチームが壊れたPoCから先に進めないとしたら、その差は「能力と実践のギャップを埋めているかどうか」です。 Bassimeledath
このギャップを整理する枠組みとして、AIエージェント向け音声・チャット支援システムを開発するBassim Eledathが2026年3月31日に発表した「エージェンティックエンジニアリングの8段階」モデルが広く参照されています。以下はその内容の解説です。
8段階の構造:L1〜L8
L1・L2:タブ補完とエージェントIDE
CopilotやCursorといったツールで始まる最初の2段階です。AIがコードを補完・提案し、マルチファイル編集を容易にします。ただし天井は常にコンテキストにありました。モデルは「見えるもの」しか手伝えず、見るべきコンテキストを見ていないか、見なくていいコンテキストを見すぎている問題が常につきまとっていました。 Bassimeledath
L3:コンテキストエンジニアリング
2025年の流行語となったコンテキストエンジニアリングは、「ノイズの多いコンテキストは仕様が不十分なコンテキストと同様に有害」という認識から生まれました。コンテキストエンジニアリングが触れる表面積は想像以上に広く、システムプロンプトとルールファイル(.cursorrules・CLAUDE.md)、ツールの記述方法、長期稼働エージェントの会話履歴管理、そして1ターンに公開するツールの数まで含まれます。選択肢が多すぎるとモデルを圧倒します——人間と同じように。 Bassimeledath
L4:コンパウンドエンジニアリング
「コンテキストエンジニアリングが現在のセッションを改善するなら、コンパウンドエンジニアリングはその後のすべてのセッションを改善します」。Kieran Klaassenが広めたこの概念は、「計画→委譲→評価→体系化」のループです。LLMはステートレスです。昨日あなたが明示的に削除した依存関係を明日また導入してしまいます——それを禁止する記述をしない限り。学んだことをCLAUDE.mdに書き込むことで、そのレッスンが将来のすべてのセッションに焼き込まれます。 Bassimeledath
L5:MCPとスキル
L3・L4がコンテキストの問題を解くなら、L5は能力の問題を解きます。MCPとカスタムスキルは、LLMにデータベース・API・CIパイプライン・Playwrightによるブラウザテスト・Slackへの通知へのアクセスを与えます。モデルがコードベースについて考えるだけでなく、それに対してアクションを起こせるようになります。PRレビューに複数のサブエージェントを起動するスキルを例に挙げると、データベースとの統合安全性を確認するもの、複雑性分析を行うもの、プロンプトの健全性を検証するもの、リンターを実行するものがそれぞれ独立して動きます。 Bassimeledath
L6:ハーネスエンジニアリング——ここから本番が始まる
コンテキストエンジニアリングがモデルの見るものを調整するものだとすれば、ハーネスエンジニアリングは、エージェントがあなたの介入なく信頼できる作業を行えるよう、環境・ツール・フィードバックループ全体を構築することです。エージェントにはエディターだけでなく、フィードバックループを与えてください。 Bassimeledath
OpenAIのCodexチームは、Chrome DevTools・オブザーバビリティツール・ブラウザナビゲーションをエージェントランタイムに組み込み、スクリーンショットを撮影し、UIパスを操作し、ログを照会し、自分の修正を検証できるようにしました。単一のプロンプトを与えるだけで、エージェントはバグを再現し、動画を記録し、修正を実装します。その後アプリを操作して検証し、PRを開き、レビューフィードバックに対応してマージまで行い、判断が必要なときだけエスカレーションします。 Bassimeledath
この設計を支える概念が「バックプレッシャー」です。型システム・テスト・リンター・プリコミットフックといった自動フィードバック機構が、エージェントが人間の介入なくミスを検出・修正できるようにします。自律性を求めるならバックプレッシャーが必要です。なければ出力品質保証なしの自動生成機械になります。 Bassimeledath
ここでのもう一つの重要な転換は「指示よりも制約」です。ステップバイステップのプロンプティング(「AをしてからBをしてからCをする」)はますます時代遅れになっています。チェックリストを与えるよりも境界を定義するほうが効果的です。エージェントはリストに固執し、そこに載っていないものはすべて無視してしまうからです。より良いプロンプトは「これが私が欲しいものです。すべてのテストを通過するまで取り組んでください」です。 Bassimeledath
L7・L8:バックグラウンドエージェントと自律エージェントチーム
ハーネスが整うと自然に生まれる問いがあります——エージェントが自分の作業を検証し、リポジトリをナビゲートし、あなたなしに間違いを修正できるなら、なぜあなたがそこに座っている必要があるのか? Ralphループ(自律エージェントループがPRD項目をすべて完了するまでコーディングCLIを繰り返し実行し、各反復でクリーンなコンテキストを持つ新しいインスタンスを起動する方式)が一般的なL7の入口ですが、複数のRalphループを並列実行すると、時間がどこに消えているかが見えてきます——エージェントを調整し、作業を順序付け、出力を確認し、軌道修正する作業です。あなたはもうコードを書いていない。ミドルマネージャーになっています。 Bassimeledath
この調整を自動化するのがオーケストレーターエージェントです。ディスパッチするエージェントがロジスティクスを処理し、あなたは意図に集中できます。L8ではこれが完全な自律エージェントチームへと発展します。 Bassimeledath
ハーネスエンジニアリングが「なぜ今」か
この分野が2026年初頭に急速に動いた背景があります。OpenAIのエンジニアRyan Lopopoloによる社内エージェントインフラに関する発表の後、Terraformの作者Mitchell HashimotoがAgent = Model + Harnessという式に蒸留しました。このフォーミュラは実践者に即座に受け入れられました。Thoughtworksエンジニアのbirgitta BöckelerがMartin Fowlerのサイトで公開したガイドが「ガイド(guides)とセンサー(sensors)」の分類法を導入し、これがハーネスコンポーネントについて語る標準的な語彙になっています。 Atlan
TerminalBench 2.0がこれを実証しています。LangChainのDeepAgentのハーネスだけを変更したところ、トップ30圏外から上位5位に浮上しました。エージェント = モデル + ハーネスです。ハーネスはモデル以外のすべてです。 Decodingai
グリーンフィールドチームは初日からハーネス適性を組み込むことができます。一方レガシーチームは、技術的負債が蓄積されたアプリケーションを抱え、より難しい問題に直面します——ハーネスが最も必要な場所こそ、それを構築するのが最も難しい場所です。 Martin Fowler
まとめ:エンジニアに何が求められるか
現時点でL3からL6に該当する実践が最も多く見られます。重要な点は、L3〜L5はその後のすべての基盤であるということです。コンテキストがノイズだらけで、プロンプトが不十分・誤指定で、ツールの記述が貧弱な状態でL6〜L8に進むと、それらのレベルは混乱を増幅させるだけです。 Bassimeledath
もう一つ見落とされがちな点は「マルチプレイヤー効果」です。あなたがL7で複数のバックグラウンドエージェントにPRを量産させていても、リポジトリにL2のチームメンバーの承認が必要なら、あなたのスループットはそこで詰まります。チームを引き上げることが自分自身の利益になります。 Bassimeledath
コードを書くスキルから、エージェントが動く環境を設計するスキルへ——この転換が、今のエンジニアリングチームに問われていることです。