この記事は 2025年、生成AIを使ってみてどうだった？ の企画応募を想定して書いたものでしたが、2月後半の業務都合とPC故障(iPadで書きました......)で作成が遅れてしまったものになります。
1. はじめに：受託開発における生成AI活用
私はこれまで、自社開発・ITコンサル・受託開発と複数の立場を経験してきました。現在は受託開発の現場で、主にPMやチームリードとしてB2BのWeb業務システム案件に携わっています。
昨今の生成AIブームにより、自社開発領域での活用事例を目にしない日はありません。しかし、受託開発ではどうなのか、というと公開にあたっての契約上の問題はありますが、昔から続く「仕様書からの自動生成」や「レガシーシステムのマイグレーション」といったトピックな気がするので、今回記事を書いてみることにしました。
本記事で触れる内容は、あくまで「B2Bの受託開発・中〜小規模案件」という、私自身の限られた観測範囲に基づく気づきです。全ての現場に当てはまる一般論ではありませんが、似たような境遇でハンドルを握る方々の一助になれば幸いです。
まずは、私の受託開発現場における基本的なガードレールを確認しておきます。
- 規約の確認： データの保全・管理がプロジェクト基準を満たしているか
- 学習の制限： 入力データがAIモデルの学習に利用されない設定であるか
- 責任の所在：AIの結果をそのまま利用して問題が発生した場合、責任を負うのは「利用を判断した組織」であること
こうしたハードルがあるため、少なくとも私の関与範囲では2025年時点で、業務範囲での生成AI活用はまだ「ごく限られた範囲」に留まっているのが実情です。
本記事では、この前提を踏まえた上での「現場の気づき」を整理してみたいと思います。
2. 経験のあるエンジニアの「手」となり動く
年次が上がると、どうしてもプロジェクト全体をまとめる役割が期待されます。経験が積まれた頃には、まとまった工数をプログラミングに割くことが難しくなり、プロダクションコードに直接触れることはリスク（副次的な困難）と判断されることも少なくありません。
しかし、現場には「これがあれば便利だが、作る時間がない」という小さなペインポイントが無数に存在します。
- タスク管理やPull Request用のテンプレート作成
- 初期のCI環境やタスクランナーの整備
- 定型作業を自動化するCLIツールの作成
これらに気づくのは、現場の痛みがわかるシニア層です。コーディングエージェントの登場により、 「MTG前の5分で依頼し、MTG中に作っておいてもらう」 という動きが可能になりました。テストや検証は人間が行いますが、ペインポイントを熟知したエンジニアが指示を出すため、そこそこのものが早くできていると思っています。
3. 孤独な判断を支える「壁打ち」の効能と罠
中規模以上のプロジェクトであれば相談相手もいますが、小規模案件ではPM/リードが一人で判断を抱え込みがちです。品質やコストといった重大な決断以外にも、ちょっとした「思考の整理」が必要な場面で、生成AIは優秀な壁打ち相手になります。
ただし、安全に利用していくためにはいくつかの自衛策が必要だと考えています。
- 依存のリスク
- AIに頼りすぎた結果、将来的なコスト増や仕様変更に対応できなくなるのは自分自身です
- 「AIなしでも判断できる軸」を持ち続けることが重要だと考えています
- エコーチェンバー現象
- AIは利用者に寄り添う傾向があるため、相談が「自分の考えを肯定してもらうだけの作業」にすり替わることがあります
- 疲れているときには判断をせず、冷静な時に見返すといった律し方が求められると考えています
- 根拠の検証
- 米デロイトの事例（出典のないレポート提出）のように、生成AIはハルシネーションを含んだ出力が発生します
- 「根拠となる出典の資料やURLを提示するようにしてください」とプロンプトに入れた上で、その出典は別途の確認を取るなどの対策が必要だと考えています
4. 「AI + 経験の浅いエンジニア」が生む歪みと、教育の再定義
生成AIを使えば、経験の浅いエンジニアでも一見「ミドルクラス」に見えるコードを即座に出力できます。しかし、そこには特有のアンバランスさが潜んでいます。特にプロジェクト固有の事情とかみ合っていないことがあります。
この件の詳細な事例は2025年のアドベントカレンダーで紹介されたいえらぶGROUP社の事例(メンティー側, メンター側)によくまとまっていたと思います。
ここで、レビューの特性のうち、フォーカスする箇所が品質担保以外の面も強くなっているということも気が付きました。例えば以下のような内容でしょうか。
- エンジニアリング経験が浅くても何かしらの「自学」の型を持っているか
- 経験がある側が「AI生成コード特有の特性によって現在のコンテキストに沿わない内容」を見抜けるか
生成AI活用によって能力が「自分の野力 + 世の中ベストプラクティス」と「足し算」で増えるフェーズは序盤だけで、そこから先は「自身の基礎力 × 生成AI活用力」という「掛け算」になると思います。経験の浅い層が「自分の知らない知識」をどう取得していくのか。個人の素養によらない組織的な取り組みだと、今のところ従来的な徒弟制になりそうな気がしています。
5. 負のコンテキスト
生成AIは「世の中のベストプラクティス」を元に回答します。しかし、レガシーなシステムには、「当時はそれが最善だった」「諸々の制約でそうせざるを得なかった」という、ADR（意思決定記録）にも残らない経緯🟰負のコンテキストが眠っています。
私が昨年遭遇した事例として内部IDの発番ルールの話があります。初期の数件だけ発番ルールが異なり、以降はルール通りになっている環境。何も知らない「AI + 経験が浅いエンジニア」ペアは、全てを統一的に扱おうとして、結果的に人間が膨大な設定ファイルを書かなければ動かないコードを作成してしまいました。
当時の背景を知るシニアであれば、「初期分は例外として切り離し、現行ルールのみを自動化する」といった、現実的な落とし所を判断できます。こうした 「昔ながらの、泥臭いドメイン知識」を言語化し、AIにコンテキストとして与える作業 は、現代のシニアエンジニアに課せられた、負荷の高い新たな仕事となっています。
6. スループット
「成果物の責任は人間が取る」という大原則がある以上、現状では必ず人間の介入が必要です。局所的なコード生成は早くなりましたが、その分、レビュー担当者に負荷が集中し、全体のスループットが劇的に向上した実感はまだ薄いのが実情です。
"The Software Development Lifecycle is Dead"
と言われるような世界を実現するには、個人のスキル以上に、組織的な「裏支え」が必要だと感じます。
- 監視結果に基づく自動ロールバックなどの高度な自動化
- 「ハーネス・エンジニアリング」 のような、生成AI制御できる仕組み
- AIによる失敗をチームの課題として受け止める文化
このあたりの組織論については、LayerX社の資料「なぜAIは組織を速くしないのか 令和の腑分け」に詳しいのでそちらもご参照ください。
これらが揃って初めて、私たちはAIによる「真の高速化」の恩恵を享受できるのではないでしょうか。
おわりに
生成AIの登場により、エンジニアリングの風景は一変しました。しかし、少なくとも私の現場においては、AIが吐き出したアウトプットを「どう繋ぎ、どう正当性を担保し、どう維持するか」という組織力や個人のスキルを高めていくところからかなと思っています。
生成AIをどうやってうまく使っていくか、というチャレンジはまだまだ始まったばかりです。技術的なことはもちろん、より時間がかかる課題もまだまだあるので2026年も頑張ってやっていきたいと思います。