AI駆動開発時代にエンジニアに求められる「判断力」とドキュメント駆動開発

はじめに

Developers Summit に参加し、AI駆動開発に関する多くのセッションを聴講しました。生成AIがコードを書く時代において、エンジニアの役割はどう変わっていくのか。本記事では、そこで得られた知見のうち、特に「エンジニアに求められる認知・判断」と「ドキュメント駆動開発」という開発手法の変化について整理します。

エンジニアに求められる「判断」とは

生成AIが実装の大部分を担えるようになった今、エンジニアの価値は「コードを書くこと」そのものよりも、AIの出力を評価し、意思決定する力へとシフトしています。セッションでは、具体的に以下のような判断がエンジニアの価値として挙げられていました。

仕様との整合性の判断

生成AIが出力したコードが、要件・仕様通りに実装されているかを見極める力です。 AIは「それっぽいコード」を高速に生成できますが、本当にビジネス要件を満たしているかは別問題です。仕様書を深く理解し、出力されたコードと突き合わせて差分を見抜く力が、これまで以上に重要になります。

設計意図の説明

なぜその設計を選択したのか、技術的な根拠を持って判断し説明できる力です。 AIは複数の実装候補を提示できますが、「どれを選ぶか」「なぜ選ぶか」はエンジニアの責任です。チームや将来の自分に対して設計意図を説明できることは、保守性の観点からも欠かせません。

業務知識の反映

ドメイン知識が機能として正しく実装されているかを評価する力です。 AIは汎用的なコードを書くことは得意でも、自社の業務ルールや暗黙知を完全には理解していません。ドメインエキスパートとしての知見を持ち、AIの出力を業務文脈で評価できることが、エンジニアの大きな価値になります。

AIエージェントの制御

エージェントの能力が高くなるにつれて、それを適切に使いこなすためのエンジニアとしての力が以前にも増して必要になります。自律的に動くエージェントに対して、どのようにタスクを分解し、どのような制約を与え、どこで人間が介入するか。この設計自体がエンジニアリングの重要な一部となりつつあります。

開発手法の変化：ドキュメント駆動開発

AIを活用したシステム開発の手法として、ドキュメント駆動開発が多くのセッションで紹介されていました。

なぜドキュメント駆動なのか

背景にあるのは、AIに自由にコードを書かせると意図通りの結果にならないという課題です。プロンプトだけで指示を与えても、AIは文脈を推測しながら実装するため、プロジェクト固有の設計思想や制約から逸脱しがちです。結果として、動くけれどレビューが通らないコード、既存アーキテクチャと整合しないコードが量産されるリスクがあります。

ガードレールとしてのドキュメント

そこで注目されているのが、設計ドキュメントやルール定義といった「ガードレール」を事前に作成し、AIに制約を与えたうえで実装させるというアプローチです。

具体的には次のようなドキュメントが起点となります。

アーキテクチャ設計書・ADR（Architecture Decision Record）
コーディング規約・命名規則
ドメインモデル・ユビキタス言語の定義
API 仕様・データモデル定義
テスト方針・品質基準

これらを AI が参照できる形（リポジトリ内の Markdown、ルールファイル、プロンプトテンプレートなど）で整備しておくことで、AI の出力は自然とプロジェクトの文脈に沿ったものになります。

ドキュメントを書くこと自体が設計行為に

ドキュメント駆動開発の面白い点は、ドキュメントを書くこと自体が設計行為として再評価されるところです。従来「コードを書いた後に書くもの」「書いても読まれないもの」とされがちだったドキュメントが、AIに読ませる前提になることで、一次成果物としての価値を取り戻します。エンジニアは「何を作るか」「どう作るか」をまずドキュメントとして明確化し、そこから AI と協業して実装に落とし込む流れになります。

おわりに

AI駆動開発は、エンジニアの仕事を奪うのではなく、エンジニアに求められる判断の密度を高める方向に進んでいると感じました。コードを書くスピードはAIに任せつつ、仕様との整合性、設計意図、ドメイン知識といった「判断」の領域で価値を出すこと。そしてその判断の土台となるドキュメントを丁寧に整備すること。これらが、これからの開発チームにとって共通して必要な営みになっていきそうです。

弊社でも、プロジェクトごとに AI に渡すガードレールを整備しながら、AI駆動開発の実践を進めていきたいと思います。