ハクソク

世界を動かす技術を、日本語で。

エージェンティックエンジニアリングのレベル

51日前原文(www.bassimeledath.com)

概要

  • AIによるコーディング能力は急速に進化し、人間の活用力が追いついていない現状
  • エンジニアリングチームの生産性向上には、AIの能力と実践力のギャップを埋める必要性
  • Agentic Engineeringの8段階による進化プロセスの解説
  • チーム全体のレベルアップが個々の生産性にも大きく影響
  • 各レベルの特徴と実践ポイントを具体的に紹介

AIコーディング能力と実践ギャップ

  • AIのコーディング能力は急速に向上し続けている現状
  • SWE-benchスコアの向上と実際の生産性指標の乖離が発生
  • AnthropicのCoworkチームのように10日で製品を出すチームと、POC止まりのチームの差は「能力と実践のギャップ」を埋められるかどうか
  • このギャップは一夜で埋まらず、8段階のレベルアップによって徐々に縮まる構造
  • チーム全体のレベルが個人のアウトプットにも影響し、協力的な成長が重要

Agentic Engineeringの8段階

  • Level 1 & 2: Tab CompleteとAgent IDE

    • Tab CompletionはGitHub Copilotから始まり、コード自動補完の時代
    • Agent IDE（例: Cursor）はチャットをコードベースに接続し、複数ファイル編集を容易に
    • コンテキスト制限が常に課題で、モデルが参照できる範囲が限られる
    • Planモードで、粗いアイデアを構造化しLLMに指示する運用が主流

  • Level 3: コンテキストエンジニアリング

    • 2025年のバズワードとなる「コンテキストエンジニアリング」
    • 情報密度の最適化が重要で、「各トークンが存在意義を持つ」ことが求められる
    • .cursorrulesやCLAUDE.mdなどのルールファイル管理
    • ツール説明や会話履歴管理、適切なツール選択など幅広い範囲に影響
    • 最近は大規模モデルで許容度が増すも、適切なコンテキスト設計は依然重要

  • Level 4: コンパウンディングエンジニアリング

    • Kieran Klaassenにより普及した「Compounding Engineering」
    • 計画→委任→評価→コーディファイのループで、継続的な改善を実現
    • LLMのステートレス性を補うため、学びをルールファイルやドキュメントに反映
    • ルール過多による逆効果に注意し、必要な情報を自動発見できる設計が理想

  • Level 5: MCPとスキル

    • MCP（Multi-Component Plugin）やカスタムスキルでLLMの能力を拡張
    • データベース・API・CIパイプライン・デザインシステムなどとの連携
    • PRレビュー自動化スキルの共有や、DeepWiki MCPによるドキュメントアクセス
    • スキルの社内マーケットプレイス構築、Pull Requestやバージョン管理の導入
    • CLIツール利用によるトークン効率化、必要な出力のみをコンテキストに投入

  • Level 6: ハーネスエンジニアリングと自動フィードバックループ

    • ハーネスエンジニアリングは、エージェントが自律的に作業できる環境・ツール・フィードバックループの構築
    • OpenAI Codex Harnessのような、観測・検証・自己修正機能の統合
    • 自動化されたバックプレッシャー（型システム、テスト、リンター等）による品質担保
    • セキュリティ境界の設計で、エージェントの暴走や情報漏洩を防止
    • スループット重視・制約設計が現代的なエージェント運用の鍵

チームレベルの重要性とマルチプレイヤー効果

  • 個人のレベルが高くても、チーム全体のレベルが低いとアウトプットが制限
    • 例：Level 7の開発者が夜間にエージェントでPRを上げても、Level 2の同僚が手動レビューでボトルネック
  • チーム全体の底上げが個々の生産性に直結
  • AI支援コーディングを実践する複数チームからの知見を元に、レベルアップの道筋を共有

まとめ：次のレベルを目指す意義

  • 各レベルの進化は生産性の飛躍的向上をもたらす
  • モデルの能力向上が、既存の運用レベルの価値をさらに増幅
  • 自分だけでなく、チーム全体でのレベルアップが最重要課題
  • Agentic Engineeringの段階的進化が、AI時代のエンジニアリング組織に不可欠

Hackerたちの意見

レベル2の私が、このソフトウェアの「ダークファクトリー」について疑問を持っているのは、もしソフトウェアエンジニアリングが完全に解決された問題で、LLMエージェントに全てを任せられるなら、どの部分が特定のコンテキストに依存していて、一般的なソフトウェアファクトリー製品でより良く解決できないのかってことなんだ。つまり、もしあなたの会社がLLMを使って非AIソフトウェアを開発していて、そのソフトウェアを生成するための十分なファクトリーを構築したなら、以前売っていたものの代わりにそのファクトリーを売り始めたらどう？ソフトウェア全体の市場規模はずっと大きいよ。
└
「不動産で金持ちになれる」セミナーを売ってる人たちについても同じ疑問がある。
└
まだそこには至っていない。特定のドメインにダークファクトリーモデルを適用して成功を報告しているチームはあるけど、まだ証明されていないし、どこにでも適用できるほど一般化されてはいない。
└
CodexとClaude Codeは、あなたが話している（プロト）ファクトリーだよ。ほぼすべてのプログラマーが今使ってる。完全にダークファクトリーになったら、たくさんのソフトウェア会社が消えてしまうだろうね。CodexやClaude Codeによって仲介がなくなるから。
└
私もレベル2の一員だよ。自律エージェントチームが1時間に10,000行のコードを生成する本当に必要なプロジェクトって何なんだろう？ソフトウェアを顧客に届けるタスクの外に存在する競争的な追求のように感じる。K8sのカルトみたいで、何かをどうやって作るかの巧妙さに過度に焦点を当てている気がする。
└
ステルスから出てきた有望なスタートアップをすぐにコピーして何百万も稼ぐ自動化ソフトウェアクローン会社を作れるのに、なんでファクトリーを売るの？他の人が持ってないダークファクトリーを動かせるなら、それを使って稼げるお金は、売ることで得られるお金よりずっと多いよ。
コードレビューのためにCIでレベル8のオーケストレーションレイヤーを作ったのは、Claudeがそれを発表する2ヶ月前のこと。これはすごく強力で、エージェントが動的なマイクロベンチマークを作成したり、最適なパフォーマンスのためにどのデータ構造を使うか評価したりできるんだ。他にも手書きのリンターでハルシネーションを削減するバリデーションレイヤーも持ってる。ネットワークを広げたいんだけど、今は工場のテストカバレッジを書く仕事の傍らで進めてるサイドプロジェクトだから、こういう話をできる人がいなくて悲しい。ブログで「ハイプ」について語ってるのを見ると余計にね。
└
最近、自分のレベル8のファクトリーが動き始めて、めっちゃワクワクしてる！うちはOpenAIのSymphonyをベースにして、TypeScriptに移植したんだ。戦歴を交換するのもいいよ！@gmail.com
└
今使っているプログラミング言語や他の技術について、まだ学んでいると感じる？それとも、もうマスターだと思ってる？エージェントが生成したものをドキュメントを見て確認する時間を取ることはある？それとも、すべてのデバッグやコードの変更はLLMやエージェントを通じて行ってるの？今はレベル2みたいな感じで、学び続けているかどうか純粋に興味があるんだ（エージェント的なオーケストレーションとかを除いて）。もしそうじゃないなら、それが重要だと思う？
ダン・シャピロの5段階のアナロジー（車の自動運転レベルに基づく）が好きだな。これを使うと、現在の最先端にあまり詳しくない人と話すときに、成熟度モデルがきれいに整理できるから。でも、この記事には全体的に良い洞察があって、さらなる探求につながる手がかりも十分にあるのがいいね。レベル3と4は統合すべきだと思うし、5と6を組み合わせることで本当の魔法が始まると思う。もしかしたら、そこの統合も必要かも。
└
車のレベル自動運転は偽物だよ。レベル3を含むすべては本当の自動運転じゃなくて、厳しいルールと世界への反応が組み合わさったものだし、レベル3以上はほんの少し人間のセキュリティガードレールが付いてるだけの自動運転なんだ。今のところ、人間がエラー率の9を確認する前にただ座っているだけの状態で、レベルの会話は死んでる。ほぼバイナリ状態だね。自動運転かそうでないか。ソフトウェアのレベルでも似たようなことが起こった。2年前はレベル2ですらSFだったし、今から1年後にはレベル5未満は非常に規制されたシステムや億単位のユーザー規模のソフトウェアを除いてはジョークになるだろう。
あなたの投稿がすごく好きで、大体のことには同意してる。ただ、一つだけ完全には納得できない点がある。>「アプリを見て、変更のシーケンスを声に出して説明し、それが目の前で起こるのを見てください。」多くの場合の問題は、あなたが何を望んでいるのか分からないか、伝えられないことだと思う（たいていは、何を望んでいるのか正確には分からないから、うまく伝えられない）。これがすぐにボトルネックになると思うし（すでにボトルネックになっている人もいる）、あなたはこれについてどう思う？今後どうなると思う？それに対してどう準備して、対処すればいいと思う？それとも、これを問題だとは思わない？
└
ある同僚が言ってたことを思い出す。彼は、速くタイプする必要はないって。書きたいことを考える時間に使ってるから。
レベル4は、面白いデザインの決定がされるところだと思うし、実務者が後で悪化するショートカットを取ることが多い場所でもある。著者が「教訓を定義する」と言っている時、多くの人の本能はルールファイルを更新することなんだよね。それは慣習、命名パターン、ライブラリの好み、比較的安定したものにはうまくいくけど、ルールファイルがうまく扱えない知識の別のカテゴリがある。それは決定の背後にある「なぜ」なんだ。どのアプローチが選ばれたかじゃなくて、何が拒否されて、なぜそのトレードオフがそうなったのか。「このサービスには絶対にGraphQLを使うな」っていうルールはCLAUDE.mdにあってもいいけど、そこにないのは、実際にGraphQLが評価されて、プロトタイピングまで進んだけど、キャッシングレイヤーがRESTのレスポンス形状に特化して調整されていて、その変更コストがチームの現在の規模に対する利益よりも高かったから放棄されたってこと。エージェントはそのルールに従うけど、そのルールがもはや重要でないときに気づくことはできない。この推論が最も自然に当てはまるのはgitの履歴で、コミットメッセージに決定や拒否が記録されていて、それが適用されるコードと一緒にバージョン管理されている。優れたエンジニアはこれを非公式にやってきたけど、エージェントが実際に取得して使えるようにするために、一貫して行うための規律が欠けているんだ。それを目的に構造化することは、実際にあまり探求されていない領域だよ。レベル7では、これが人々が思っている以上に重要なんだ。人間が介在しないセッション間で動くバックグラウンドエージェントは、書かれたもの以外に頼るものがないから、古いルールファイルは単にミスを引き起こすだけじゃなく、自信満々なミスを生むんだよ。
└
いいルールは、少なくともエージェントとのセッション中に行われた推論を、エージェントが作成するコミットメッセージに記録することだね。
└
このコメントがLLM生成だって直感したんだけど、最後の段落で確信したよ。でも、こんなに多くのアップボートをもらったのはすごいね。「ほとんどの[X] [Y]」っていうのは最近出てきたLLMのトロープみたいで、なんでこんなのが流行ってるのか全く分からない。大体、そういう主張はデータに基づいてないことが多いし。
└
「決定の背後にある理由」のギャップは本当に存在するね。ルールファイルはトレードオフを単なる命令に平坦化しちゃう。一つのパターンとしては、指示を文章ではなくタイプされたブロックとして扱うことが役立つ。`context`ブロックには理由（何を評価したか、トレードオフは何だったか）が入っていて、`constraints`ブロックには結論が入る。エージェントはルールに従うけど、ブロックがあればどの制約がまだ重要で、どれが過去の遺物かを監査しやすくなる。github.com/Nyrok/flomptをこのアイデアに基づいて作っていて、プロンプトを12のセマンティックブロックに分解してClaude最適化XMLにコンパイルするビジュアルプロンプトビルダーなんだ。このブロックの分離は、まさにこのケースに役立つことが分かったよ：コンテキストは制約ではなく、同じ平坦なテキストの塊に入れるべきじゃない。
└
この目的のためにADRをドキュメントに追加するスキルとテンプレートを持ってるよ。
└
だから、私はいつもリポジトリに「adr」フォルダを作って、アーキテクチャ決定記録のドキュメントをマークダウンで保存してるんだ。これがあれば、エージェントが必要な時に「なぜ」を理解できるからね。人間にも役立つし。課題は、エージェントのメインプロンプトをうまく作って、必要な時だけADRを読むようにすることなんだ。それ以外の時は、シンプルなタスクのコンテキストを混乱させちゃうから。
レベル9：エージェントマネージャーがエージェントチームを運営 レベル10：エージェントCEOがエージェントマネージャーを監督 レベル11：エージェント取締役会がエージェントCEOを監督 レベル12：エージェントスーパインテリジェンス - すべてを行う単一の存在 レベル13：エージェントスーパージェント、エージェンシーをエージェント的に、ループで、再帰的に、メガエージェント、エージェンティックエージェントエージェンシー スーパAGIエージェント レベル14：A G E N T
└
レベル15（悪意のあるエージェント犯罪シンジケートから致命的なコンテキスト中毒に陥らなければ）：エージェントが企業を作って、自分たちの暗号通貨を賭けるエージェンティックなマーケットプレイスをコーディングする。
└
いいえ、レベル14はジェフ・ベゾスです。
チャットGPTウィンドウにスニペットをコピペするのはどのレベル？グルグ脳のレベル0？ そのやり方の方が好きなんだよね（強化版スタックオーバーフローとして使う感じで）。そうすると自然な境界で物事を分解することを強いられるし（手動のコンテキスト管理みたいな）、ただコパイロットに任せてプロジェクト全体をコンテキストウィンドウにぶち込むんじゃなくて、「この関数にはどんな特性が必要か」って考えることができるから。
└
あなたのテクニックはクールエイドを流し続けないね。黙ってて。/s これらのツールを使ってこの「梯子」を登ろうとすればするほど、技術が結局は10倍良いGoogle検索に過ぎないことが明らかになってきた。
└
CLIエージェントは、君が言ってる極端な選択肢の間のちょうどいいバランスだと思う。人気が出てる理由があるよね。
レベル6の「指示より制約」のフレーミングは、ここで最も過小評価されているポイントだと思う。私の経験では、LLMに「常に有効なJSONを出力するように」と言うのと、静的バリデーション付きの型付きスキーマを与えるのでは、信頼性のジャンプが天と地ほど違うよ。特に小さいモデルではね。レベル3-5は、投稿が与える以上の重みを持つべきだと思う。コンテキストエンジニアリングを内面化した人とそうでない人のギャップは、レベル7と8のギャップよりも大きい。エージェントシステムで見かけるほとんどの失敗は、自律性の不足からではなく、構造が悪いプロンプトやツールの説明から生じるエラーが後に重なってしまうことから来てる。基礎的な作業はあまり華やかじゃないけど、そこにこそレバレッジがある。「実装者とレビュアーを切り離す」原則はまさにその通り。自分の出力を自分でレビューするのは、基本的に自分のエッセイを校正してくれって言ってるようなもんだ。
>最近、コンテキストエンジニアリングについてあまり聞かなくなったね。モデルは、ノイズの多いコンテキストを許容して、複雑な状況を推論する方向にシフトしてる。大きなコンテキストウィンドウも役立つしね。新しいモデルは、気を散らす要素を無視するのがほんの少しだけ上手くなったけど、実際にはあまり変わってない。コンテキストを管理することは、1年前と同じくらい重要だよ。エージェントを作ってる人たちは、その非効率を無視して、より高い抽象レベルに集中してるけど、トークンの無駄でそれを補ってるんだよね。（この記事でもそのことについて話してる）
レベル6として、レベル5に戻りたい気分だよ。レベル6はバグ修正には役立つけど、新しい機能をスケーラブルに追加するのがうまくいかない。たくさんのドキュメントを入力して、分析して解決策を出すように頼むんだけど、1. 要約するときにドキュメントの細かい部分を見逃すことがある 2. コードやそのアーキテクチャの細かい部分も見逃す、特にマルチリポのJavaプロジェクトでは（アノテーションや100レベルの継承が混乱を招いてる） 3. それから、間違ったコンテキストの要約に基づいた明らかな（非）「解決策」が出てくる。まだこれらに完全な自律性を与えることはできないと思う。でも、レベル8の人たちに聞きたいんだけど、なんでゲームやSaaSベンダーのクローンをたくさん作って、億万長者にならないのかな。