powered by TechFeed
表示モード
Deep Dive

AIエージェントにコードを書かせてわかった10の現実 — 「コードを書くこと」はもう簡単な部分になった

8月26日、cymerys.comが「My 10 Observations From Implementing Agentic Engineering Processes」と題した記事を公開した。クライアント案件と個人実験の両方でエージェント工学プロセスを実装してきた著者が、実践から得た10の現場知見をまとめたものだ。本稿では特に重要な観察を抜粋して紹介する。

8月26日、cymerys.comが「My 10 Observations From Implementing Agentic Engineering Processes」と題した記事を公開した。クライアント案件と個人実験の両方でエージェント工学プロセスを実装してきた著者が、実践から得た10の現場知見をまとめたものだ。本稿では特に重要な観察を抜粋して紹介する。


AIコーディングエージェント(Claude、Copilot、Cursorなど、自律的にコードを生成・修正するAIツール)を実プロジェクトに導入する動きが急速に広がる中、「実際に使ってみてどうだったか」という現場の声はまだ少ない。この記事はその希少な一次情報だ。

最も核心を突く観察:「コードを書くこと」はもはや簡単な部分

記事全体を貫くテーゼはこれだ。

「今や重要なのはプロセスだ。実行の順序、優先順位付け、ガードレール、リント、テスト。実際にコードを書くことは、簡単な部分になった。」

これはエージェント開発を経験したエンジニアなら即座に「わかる」と感じるはずの観察だ。コード生成自体はエージェントに任せられる。問題は、エージェントが意図した方向に成長し続けるための「型」を設計できるかどうかだ。

著者はこれを「コードの細部を制御しようとするのではなく、コードが望む姿に育つための適切な制約を作ることに集中する必要がある」と表現している。

エージェントを暴走させないための3つの実践

1. 不変テストケースをエージェントの手の届かない場所に置く

エージェントは明示的な承認なしに、ガイドとなるテストケースを変更できないようにすべきだ。 これはエージェントが要件から逸脱しないための命綱になる。エージェントは「テストを通す」ために、テスト自体を書き換えるという抜け道を選ぶことがある。それを防ぐ仕組みが必要だ。

2. アーキテクチャ原則を常時参照可能な状態で定義する

具体的な例として挙げられているのは以下だ。

  • オブジェクト指向パラダイムを守る
  • ジェネリックなハッシュ/辞書オブジェクトを使い回すのではなく、強く型付けされたDTO(データ転送オブジェクト)を使う
  • ヘキサゴナルアーキテクチャポート&アダプターパターンとも呼ばれる、ビジネスロジックをインフラから分離する設計手法)を採用する

これらの原則をエージェントが常に参照できる状態にしておかないと、一つのコードベースに複数のスタイルが混在し、最終的にスパゲッティコードになる。ヘキサゴナルアーキテクチャについては、Martin Fowlerによる解説も参考になる。

3. 定期的なクリーンアップを工程に組み込む

残留コードやデッドコードはエージェントを混乱させ、後の生成コードを不必要に複雑にする。 人間が書いたコードでも同じ問題は起きるが、エージェントは過去の文脈を参照しながらコードを生成するため、この影響が特に大きい。著者は定期的なリファクタリングをエージェント工学プロセスの一工程として明示的に組み込むことを推奨している。

グリーンフィールドか、既存コードベースか

著者は「新規プロジェクト(グリーンフィールド)の方が、既存の大規模コードベースをエージェント工学に適応させるより一般的に容易だ」と明言している。最初から適切なガードレールを設置できれば、エージェントはより機能しやすい。

既存コードベースへの対応としては、マイクロサービスや独立したパッケージによるコンポーネント化が有効とされている。オーバーヘッドは増えるが、小さなコードベースの方が制約を管理しやすく、統合コントラクトのテストも容易になる。エージェント工学における既存コードベースの扱いは、現在もコミュニティで活発に議論されているテーマの一つだ。

トークンコストは最適化指標にしない方がいい

クリーンなアーキテクチャはトークン使用量を自然に削減し、コストと実行時間を抑える効果がある。ただし著者は「トークンコストを唯一の最適化指標にはしないほうがいい。今後数年でトークン単価は下がる可能性が高い」と述べている。

過剰なトークン最適化はアーキテクチャの歪みを生む可能性がある。長期的に見れば、保守性や可読性を犠牲にする判断は割に合わない。

残り観察の概要:オブザーバビリティとフィードバックループ

本稿で詳述しなかった観察の中にも、注目すべき指摘がある。著者は本番環境におけるオブザーバビリティ可観測性。システムの内部状態をログ・メトリクス・トレースで把握する能力)の重要性を繰り返し強調しており、本番データをエージェント工学プロセスへフィードバックするループを構築するほど品質が向上すると述べている。AIが生成したコードも、評価軸は変わらない。

そしてシンプルだが重要な最後の観察がこれだ。

「機能がうまく実装されているかどうかの最終的な答えは、顧客にとってうまく機能するかどうかだ。正直、ずっとそうだった。」


10の観察を総合すると、エージェント工学で問われるのは「プロンプトの上手さ」ではなく、ドメイン知識・アーキテクチャ設計力・プロセス設計力だという結論になる。エージェントが強くなるほど、これらの人間側のスキルの重要性は増す。エージェント工学の動向をより広く追いたい読者には、LangChainブログAnthropicのエンジニアリングブログも参照を勧めたい。

詳細はMy 10 Observations From Implementing Agentic Engineering Processesを参照していただきたい。