AI時代でも変わらないエンジニアリングの本質
服部氏は、AIエージェント時代における開発スタイルの変化について、2025年版の視点からアップデートされた知見を披露した。従来から語られてきたように、人間によるレビューやテストがボトルネックとなる以上、「小さなコードチャンクによる段階的な作業」は今後も不可欠だ。しかし近年、その作業の一部をAIが担うようになってきた点に変化がある。
2024年までは、開発者が都度「AIに渡す文脈」を意識し、都度コードを分割・整理する必要があった。だが、GitHub Copilotのエージェントをはじめ、AIが自律的に情報を収集し、コード提案や変更を自動で行う割合が飛躍的に増えている。つまり、AIがより「能動的な開発者」になりつつあるのだ。
ただし、AIの情報収集にも限界がある。AIが文脈を取得するために使われる代表的な手法には、語彙ベースの「レキシカル検索」と意味ベースの「ベクトル検索」があるが、いずれもコード構造が乱雑で依存関係が複雑な場合、正確な関連情報の取得は困難になる。加えて、トークン長の制限という技術的ハードルも健在だ。大量のコードが存在すれば、AIの出力精度は著しく低下する可能性がある。
これらの課題に対して、服部氏は「AIにとっても読みやすく、操作しやすいコードを書く」こと──いわば「AIフレンドリー」な設計を提案する。AIエージェント時代においては、命名やドキュメントの記述、ディレクトリ構成の整理など、AIが扱いやすい情報設計こそ、今後の開発者に求められる視点だという。
特に執筆時点において多くのAIツールが用いる情報収集手法を前提にすれば、「記述的で意味が明確な命名」は不可欠だ。コードの説明を補助するコード内ドキュメントも、過剰に書くのではなく、AIが簡単に理解でき、かつ余計なノイズを含まない最小限の情報設計が合理的である。
また、AIの利用にはコストも伴う。強力なモデルや大きなトークンウィンドウをサポートするモデルほど実行単価が高い傾向があり、試行錯誤の回数に比例してコストが膨らむ。だからこそ、最初からAIが解釈しやすい構造を用意して、AIに対するタスク難易度を下げておくことが、「パフォーマンスとトークン節約の両面で合理的だ」と服部氏は指摘する。
さらに服部氏は、コードを書くコストが大幅に下がった今、これからはメンテナンス──特に品質保証の比重が高まっていく、とも指摘する。レビューや保守の効率を高めるには、ドキュメントの過剰な記述も避けなければならない。なぜなら、ドキュメントもコードと同様にメンテナンス対象であり、情報が古くなればAIも人間も誤った判断をする可能性があるからだ。そして最終的にこのドキュメントが正しいことの保証をするのも人間である。ただし、この点においても、AIとの協働が活きる場面が増えるだろうと服部氏は付け加えた。
加えて、「AIに触れさせてよいコード」と「触れさせないコード」の分離設計の重要性も指摘する。人間がAIに対して小規模な修正を指示した場合でも、AIは裏で数百行規模のコードを再生成している可能性がある。また、AIが自律的に操作を行った結果、多数のファイルに影響が波及することもある。人間が「毎回」AIによって編集された広範囲のコードとその依存関係を調査することは困難である。このリスクを回避するためには、AIが操作する領域を明示的に制限できるアーキテクチャ設計が不可欠である。
とりわけ巨大なコードベースでは、AI支援が難航しがちだ。服部氏は、AIが扱いやすい粒度にコードを分割し、再利用可能な単位として切り出すことの重要性を説く。これは単なるAI対応にとどまらず、将来的な拡張性の確保にもつながる設計思想だ。
服部氏は、AIエージェント時代におけるエンジニアリングの本質を、「ガードレール設計」というキーワードに集約した。AIが自律的にコードを生成する今、誤動作や誤判断を防ぐための枠組みは、開発の初期段階からアーキテクチャに織り込むべきだという。これはテスト駆動開発（TDD）やアジャイルの思想にも通じうる考え方であり、「失敗を許容しながらも進化可能な構造を備えること」が前提となる開発観にほかならない。
品質保証の観点でも、AIにすべてを委ねることはできない。「AIは"それらしいコード"を出力することはできるが、それが本当に正しいかどうかは、結局のところ人間が判断するしかない」。服部氏はそう断言し、レビューやテストの責任を担えるのはあくまで人間であると強調した。
服部氏が最後に強調したのは、「コードの価値のシフト」という視点だ。生成AIによって大量のコードが容易に生み出されるようになった現在、むしろ「AIには作れないコード」──すなわちプロプライエタリ（企業に特有のクローズドな資産）な領域に根ざした、競争優位性を生むコードにこそ、エンジニアリングの価値が集中していく可能性がある。それは特異な技術領域や、レビュー済みの信頼されているシステムコードかもしれない。「中長期的には、『AIが簡単に作れないであろう成果物は何か』を見極めることが重要になる」と服部氏は語る。
そのうえで提唱するのが、「AIに再発明させない設計」というアプローチである。記述的で再利用可能なコードを資産として蓄積し、品質の高い"社内オープンソース"として維持していく。この実現に向けて有効なのが、「インナーソース」という考え方だ。オープンソース的な文化を社内に根付かせ、継続的なメンテナンスと情報の透明性を両立させる。これは開発効率の向上だけでなく、組織の独自価値を次世代へと継承していくための戦略的な取り組みでもある。
セッションの締めくくりとして、服部氏はこう総括した。
「AIエージェント時代も、エンジニアの役割や開発の大枠は変わらない。ただし、特定のライブラリやフレームワークを知っていることだけではなく、本質的なエンジニアリングやビジネスの理解がより重要になる。そのためには自社の競争優位性や技術に関する深い知見、ビジネスドメインを意識し、より深化させていく必要がある」
どれだけAIが進化しようと、開発の手綱を握るべき存在は人間だ。しかし、そこにはAIとの協働が不可欠である。エンジニアはより良いプロダクトを生み出すために、AIとの共同作業をリードするために重要な存在であり続けるだろう。服部氏のこの実践知は、技術が加速度的に進化する時代においても変わることのないエンジニアの本質として、次世代開発においても求められていくに違いない。
