AIエージェントを活用したコーディングが急速に普及しています。Claude Code、GitHub Copilot、Cursorといったツールが次々と登場し、ソフトウェア開発の現場は大きな転換期を迎えています。
弊社でもAIエージェントを日々の開発に取り入れています。その恩恵を肌で実感する一方で、「AIが書いてくれるなら、エンジニアの仕事はどう変わるのか」というご質問をお客様からいただくことも増えてきました。
本コラムでは、AIエージェントを使った開発の最前線で私たちが感じていることを率直にお伝えしながら、これからのシステム開発において本当に重要なことは何かをお話しします。
1ヶ月で景色が変わる、過渡期の真っ只中
AIエージェントを取り巻く状況は、1ヶ月単位で目まぐるしく変化しています。先月まで主流だったツールが今月にはアップデートで別物になり、新しいサービスが毎週のように発表される。私たちエンジニアにとって、この変化のスピードは正直なところ、かなりの負荷です。
新しいツールの使い方を覚えたと思ったら、すぐに次のバージョンが出る。別のツールに乗り換えたほうが良いという情報が飛び込んでくる。このサイクルに振り回されていると、気がつけば「新しいツールを試すこと」自体が目的になり、本来やるべき「お客様にとって良いシステムを作る」という目的が後ろに下がってしまいます。
私たちはこれを「手段の目的化」と呼んでいます。エンジニアとして最も気をつけなければならない状態です。
手段は短命、だから追いすぎなくていい
ここで立ち止まって考えたいのは、今エンジニアが必死にキャッチアップしている「手段」の多くは短命だということです。
たとえば、少し前に「プロンプトエンジニアリング」という言葉が注目されました。AIに対する指示の書き方を工夫することで、より良い出力を得るテクニックです。しかし、AIモデル自体が急速に賢くなったことで、かつて有効だったテクニックの多くは今や不要になりつつあります。
最近では「ハーネスエンジニアリング」という概念が業界で話題になっています。これはAIエージェントが正しく動ける環境を設計する考え方で、制約の設定やフィードバックの仕組みを通じてAIの出力品質を担保するアプローチです。現時点ではエンジニアが意識的に取り組む必要がある領域ですが、こうした制御の仕組みはAIエージェント側に徐々に取り込まれていく可能性が高いと私たちは考えています。もちろん完全になくなるとは限りませんが、少なくとも今の形のままではないでしょう。
つまり、個々の手段やテクニックを追いかけ続けても、その知識の賞味期限は短いのです。大切なのは、手段がどう変わっても揺るがない「軸」を持つことです。
現場で痛感した「設計が8割」という現実
では、その「軸」とは何か。私たちが日々の開発の中で強く実感しているのは、「設計力」こそがエンジニアの軸であるということです。
実際に弊社がAIエージェントを使って開発を進める中で、繰り返し直面した問題があります。それは「作りたいものがなんとなく頭の中にはあるが、きちんと言語化できていない状態で開発に入ってしまう」というケースです。
「作りながら考えればいいや」——この進め方でAIエージェントにコードを生成させると、最初のうちはスムーズに進んでいるように見えます。しかし、機能が増えるにつれて一貫性が失われ、全体としてまとまりのないシステムが出来上がってしまいます。AIは指示された通りにコードを書いてくれますが、全体の整合性を自ら判断してくれるわけではないのです。
この経験を経て、弊社では開発プロセスを見直しました。まず骨格となるOverview（システムの全体像）を言語化し、それを有識者がレビューする。そのうえで主機能単位にフェーズを分割し、段階的に開発を進めるというアプローチです。
骨格を早い段階で言語化してレビューすることには、大きなメリットがあります。有識者の設計思想を開発の初期段階から取り入れることができるのです。「ほぼ見えている」という状態まで設計を詰めないと、そもそもレビューもできないし、AIエージェントへの的確な指示もできない。これは逆説的ですが、AIを活用するほど「事前の設計」の重要性が増すということを意味しています。
また、一気に全機能を作ってからレビューすると、確認すべき範囲が膨大になり、レビュアーもレビュイーも疲弊します。フェーズごとに分割してレビューすることで、一回あたりのレビューの質を高め、手戻りのリスクを減らすことができます。
こうした経験を通じて私たちが実感しているのは、設計が8割、実装が2割——下手をするとその差はさらに広がる、ということです。AIがコードを書いてくれる時代だからこそ、この比率はますます設計側に傾いていくと考えています。
設計力の土台にあるもの
設計力を分解すると、「基礎力」と「実装力」の2つの要素に行き着きます。
「基礎力」とは、コンピューターサイエンスの根本的な理解のことです。ネットワークはなぜつながるのか。プログラムはどのようにしてコンピューター上で動くのか。データはどのような仕組みで管理されているのか。こうした土台があるかないかで、設計の深さがまったく変わってきます。
たとえば、ネットワークの仕組みを理解しているエンジニアは、システム間の連携部分で起こりうるトラブルを事前に想定した設計ができます。プログラムが動く仕組みを理解しているエンジニアは、処理速度やメモリの観点から無理のない構造を描けます。これらは目には見えにくい力ですが、システムの信頼性や長期的な運用コストに直結します。
「実装力」とは、設計パターンやアーキテクチャの知識と、それを適切に使い分ける力のことです。わかりやすく言えば、「保守しやすく、変更に強いシステムをどう構造化するか」を判断する力です。
弊社では、コードレビューの場を単なるバグチェックではなく、設計判断を議論する場として活用しています。「なぜこの構造にしたのか」「将来この機能を拡張するとき、この設計で対応できるか」。こうした問いをレビューの中で繰り返すことで、チーム全体の設計力を底上げしています。AIが生成したコードであっても、この設計レビューのプロセスは変わりません。
だからこそ、今「愚直な学習」が必要である
「結局、地道に勉強するしかないのか」——そう思われた方もいるかもしれません。その通りです。しかし、それは悲観的な話ではありません。
基礎的な知識は、特定のツールやサービスに依存しません。10年前も今日も、そしておそらく10年後も通用する普遍的な知識です。つまり、投資対効果が非常に高い学習なのです。
次々と登場する新しいツールを一つひとつ追いかけるのは、短期的には必要な場面もありますが、長期的にはキリがありません。それよりも、どんなツールが登場しても使いこなせる「土台」を固めることに時間を使うほうが、結果としてお客様により良いシステムを提供できる近道になると私たちは考えています。
弊社では「昨日より今日」という姿勢を大切にしています。華やかな新技術に飛びつくのではなく、毎日少しずつ基礎を固める。その積み重ねが、お客様のシステムをより堅牢で信頼性の高いものにしていくと信じています。
終わりに
AIエージェントによるコーディングは、間違いなくシステム開発の姿を変えていきます。開発のスピードはこれまでとは比較にならないほど速くなるでしょう。
しかし、速く作れることと、良いものを作れることは別の話です。AIが書いたコードの品質を決めるのは、その前段にある設計の品質です。そして設計の品質を決めるのは、エンジニアの基礎体力です。
お客様にとって大切なのは、「速くできた」ことではなく、「長く安心して使えるシステムが手に入る」ことのはずです。弊社は、AIの力を最大限に活用しながらも、その土台となる設計力を磨き続けることで、お客様の期待に応え続けます。
藤沢市で一番技術力の高いシステム会社を目指して、弊社は日々研鑽を積んでいます。システム開発や技術に関するご相談がございましたら、どんな小さなことでもお気軽にお問い合わせください。
