コーディングエージェント時代にソフトウェア設計原則はどう変わる？ 信頼を設計する「ハーネス」と決定論ファースト

【16-B-5】LLMやAIエージェントをソフトウェアに組み込むプラクティス

　生成AIとコーディングエージェントが当たり前になった開発現場では、「便利さの拡大」と「制御の喪失」が同時に進行している。Developers Summit 2026 Summerに登壇した澁井雄介氏は、LLMやAIエージェントをソフトウェアに組み込む際の落とし穴と、それに立ち向かうための方法論を語った。決定論とLLMの役割を切り分け、コーディングエージェントに「作り方の作り方」を守らせる「ハーネス」という考え方から、SOLID原則に代わる新しい設計指針までをレポートする。

開発手法や設計論は、AIエージェントとの共通言語でもある

　「コーディングエージェントが世の中に広まって、昨年はCursorやDevinを使っていた方が多かったと思いますし、今年、昨年後半からはClaude CodeやCodexにどんどん移行してきています」と澁井氏はこう切り出した。澁井氏自身、コーディングを自分でやるのではなくコーディングエージェントに任せることが、本業でも副業でも当たり前になってきているという。

　澁井氏が最初に投げかけたのは、この変化に応じてソフトウェアの開発手法そのものを考え直す必要があるという問題提起だ。ChatGPTの登場から4年が経とうとする今、コーディングという行為はいつの間にか人間の手から自動化されつつある。「今の変化に対する新しいメソドロジーを提唱するのは同時代人の特権である」というスライドの言葉どおり、澁井氏はデザインパターンやマイクロサービスアーキテクチャ、CI/CDといった従来のベストプラクティスが、LLMという確率的に振る舞うものが実装を担う時代にも同じように機能するのかを問い直す。

Snowflake Senior AI/ML Architect, Applied Field Engineering/Field CTO 澁井雄介氏

　方法論には、過去の失敗から得た知見を体系化するという役割に加え、チーム開発における「共通のコミュニケーションツール」としての役割がある。澁井氏はDIパターンを例に挙げる。「あるオブジェクトが依存する関数やオブジェクトを外から注入するように実装してコンポーネント化を促進する作り方で作ってね」と伝えるより、「DIパターンで作ってね」と一言で伝えるほうが圧倒的に速い。これはコーディングエージェントに指示を出す場面でも変わらない。しかし、LLMやAIエージェントをソフトウェアに組み込むための新しい概念には、まだ「DIパターン」のような共通言語が存在しない。「ハーネスエンジニアリング」「コンテキストエンジニアリング」「バイブエンジニアリング」といった言葉が次々と提唱されているのは、その空白を埋めようとする試みだと澁井氏は指摘する。

「便利」の裏側で、静かに増えていく負債

　共通言語の不在は、実際の開発現場で運用負債という形で表面化している。澁井氏によれば、コーディングエージェントの登場によって、これまで人間なら1週間かかっていた機能開発が3時間程度で動くものとして仕上がるようになった。その結果、細かい単位でチケットを切るコストが見合わなくなり、依頼する側は大きな単位でユースケースをまとめて依頼するようになったという。

　エンジニア以外の職種にもこの変化は及んでいる。「PMや営業、人事、経理といった方々がコーディングエージェントを使ってなぜかソフトウェアを作って自分たちの業務を楽にしている」と澁井氏は自身の前職・現職での経験を語る。きれいなUI、高度な分析、高速な開発が実現する一方、その裏側ではレビューされないコード、共通アーキテクチャの不在、セキュリティホール、無制限なトークン消費、シャドーAI、低品質なコードが量産されているというのが実態だ。便利が先行して制御は後回しというのは、人類の進化の歴史の中で経験してきていること。コーディングエージェントの時代にも同じことを経験している」と澁井氏は語る。ではエンジニアはこの状況にどう向き合えばいいのか。次のパートで、澁井氏が提示する具体的な処方箋に迫る。