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

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

概要

  • 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未満は非常に規制されたシステムや億単位のユーザー規模のソフトウェアを除いてはジョークになるだろう。

あなたの投稿がすごく好きで、大体のことには同意してる。ただ、一つだけ完全には納得できない点がある。>「アプリを見て、変更のシーケンスを声に出して説明し、それが目の前で起こるのを見てください。」多くの場合の問題は、あなたが何を望んでいるのか分からないか、伝えられないことだと思う(たいていは、何を望んでいるのか正確には分からないから、うまく伝えられない)。これがすぐにボトルネックになると思うし(すでにボトルネックになっている人もいる)、あなたはこれについてどう思う?今後どうなると思う?それに対してどう準備して、対処すればいいと思う?それとも、これを問題だとは思わない?

Hacker Newsで議論の続きを見る