AIエージェントに「既存APIへ監査ログを追加して」と依頼する。数分後、複数のファイルが更新され、テストまで追加される。以前なら半日かかった実装が、もうレビュー待ちになっている。
しかし差分を開くと、仕事が終わっていないことに気づく。ログに個人情報は含まれないか。失敗時にも記録されるか。リトライで二重登録されないか。既存クライアントとの互換性は保たれるか。そもそも、なぜその設計を選んだのか。
実装が自動化されたとき、ソフトウェアエンジニアには何が残るのか。
答えは「プロンプトを書く仕事」だけではない。AIエージェントによって実装コストは下がるが、ソフトウェアを正しく作る責任はなくならない。価値の中心はコードの入力作業から、何を作らせ、何を守らせ、どの証拠をもって正しいと判断するかへ移っていく。
AIが下げるのは、まず実装コストである
AIエージェントは、定型コード、既存パターンに沿った機能追加、複数ファイルの機械的変更、テストのたたき台、APIの調査、エラーからの修正候補作成を速める。現在のコーディングエージェントは、リポジトリを探索し、ファイルを編集し、コマンドやテストを実行するところまで担当できる。OpenAIやGitHubの公式資料でも、このような複数工程を扱う能力が説明されている。
しかし、開発全体は実装だけではない。
課題の発見
→ 要件の整理
→ 制約の定義
→ 設計
→ 実装
→ レビュー
→ テスト
→ リリース
→ 監視
→ 改善AIが特に圧縮するのは、中央の実装と、その周辺の調査やテスト作成である。要件が曖昧なら、エージェントは曖昧さを消すのではなく、何らかの仮定で埋める。レビューや検証が追いつかなければ、生成速度の向上は大きな差分の滞留に変わる。リリースと監視が弱ければ、問題を本番へ速く届けるだけになる。
したがって、「変更を何分で生成できたか」と「顧客へ安全に価値を届けるまでの時間」は分けて考える必要がある。局所的な実装速度が上がっても、ボトルネックが要件確認、レビュー、テスト環境、承認、デプロイへ移るだけなら、開発全体は同じ比率では速くならない。
「何行書いたか」から「どの判断をしたか」へ
従来はコードを書くこと自体に大きなコストがあった。複雑な機能を短期間で正確に実装できる能力には、分かりやすい希少性があった。しかし生成コストが下がれば、コード量は成果を示す弱い代理指標になる。
むしろ大量生成が容易になるほど、不要な抽象化、重複実装、過剰な変更、既存設計と合わないコードを増やしやすい。「動くコード」は作れても、運用時の失敗、移行、互換性、所有者まで考えられているとは限らない。危険なのは、誰も設計理由を説明できない変更が、テスト成功だけを根拠に採用されることだ。
エンジニアの価値は、次のような判断へ移る。
- 解くべき問題と対象外の問題を分ける
- 変更範囲を適切に限定する
- 守るべき仕様と非機能要件を明文化する
- 設計上のトレードオフを選び、理由を説明する
- 生成された変更から故障経路を見つける
- 本番で安全に動くことを証明する
これは実装力が無価値になるという意味ではない。コードを理解できなければ、差分の妥当性も説明の正しさも判断できない。変わるのは、タイピング量ではなく、技術知識を判断へ変換できるかが評価される点である。
重要になる仕事1：制約を設計する
AIエージェントへの指示は、自然言語で書いた作業依頼に見える。しかし実務では、小さな仕様書兼ガードレールとして扱うべきだ。「何を作るか」だけでなく、「何を変えないか」「どの性質を保存するか」「何をもって完了とするか」を含める。
たとえば、決済Webhookの修正なら次のように書ける。
目的:
同じイベントが複数回届いても、注文確定処理を一度だけ行う。
制約:
- 公開APIとデータベーススキーマを変更しない
- 新しい外部依存を追加しない
- 既存の認証・認可経路を利用する
- 並行処理とリトライ後も冪等性を維持する
- 機密情報をログへ出力しない
- webhookモジュール外を変更する場合は理由を説明する
完了条件:
- 重複、順序逆転、タイムアウト後の再送をテストする
- 回帰テスト、型チェック、静的解析を通す
- 採用した設計と残るリスクを説明するこの指示の価値は、文章が巧みなことではない。曖昧な要求を、観測・検証できる性質へ変換している点にある。
人間同士なら、担当者が過去の障害や口頭の申し合わせを思い出し、「ここは触らない」と補完できる。エージェントは、リポジトリや入力に存在しない事情を知らない。曖昧な依頼にも、もっともらしい実装を返せるが、それは要件を正しく理解した証拠ではない。
今後重要になるのは、要求をコードへ翻訳する能力に加え、要求を不変条件、境界、失敗時の挙動、受け入れ条件へ分解する能力である。良いプロンプトとは魔法の言い回しではなく、良いエンジニアリング判断を明示した入力だ。
重要になる仕事2：コンテキストを整備する
同じモデルでも、対象システムについて参照できる情報が違えば結果は変わる。エージェントが必要な情報を毎回推測する環境では、修正指示の往復が増える。モデル性能の問題に見えて、実際には組織知へアクセスできない問題であることも多い。
整備すべきコンテキストには、次が含まれる。
- システム構成と各モジュールの責務
- コーディング規約と代表的な実装例
- ビルド、テスト、型チェック、静的解析のコマンド
- ドメイン用語、API、データモデルの定義
- ADRなどに残した設計判断と却下した代替案
- 既知の制約、技術的負債、変更禁止領域
- デプロイ、ロールバック、障害復旧の手順
README、ADR、テスト、コードコメント、エージェント向け指示ファイルは、人間向け文書であると同時に、機械が利用できる組織知になる。ただし文書を増やせばよいわけではない。古い情報は、自信を持った誤りを誘発する。所有者、更新契機、正本の所在を決め、実行可能な知識はテストや検査ルールとして表現したい。
たとえば「ユーザー削除は監査ログを必ず残す」という規則は、設計書だけでなく受け入れテストにも落とし込める。エージェントが読む説明とCIが強制する規則が一致すれば、口頭知識への依存を減らせる。
コンテキスト整備は、ドキュメントを書く雑務ではない。将来の変更コストを下げる開発基盤である。一度整えた情報は、熟練者だけでなく、チーム、新メンバー、複数のエージェントが再利用できる。
重要になる仕事3：コードではなく「仮定」をレビューする
AI生成コードのレビューで、構文、命名、フォーマットだけを見ても不十分である。エージェントは不足情報を推測し、その仮定をコードへ固定する。レビュー対象の中心は、「どのような前提なら、この差分が正しいのか」だ。
まずエージェントに、変更概要、設計理由、検討した代替案、未解決のリスクを説明させる。そのうえで次を確認する。
- 要件を狭く、または広く解釈していないか
- 正常系だけでなく失敗、タイムアウト、部分成功を扱うか
- 既存の責務分担や信頼境界を壊していないか
- 差分が必要以上に広くないか
- 一見不要な処理を、意図を確認せず削除していないか
- 並行実行、重複、順序逆転、リトライで不整合が起きないか
- ログや例外に機密情報が入らないか
- ライブラリやAPIの実際の仕様に基づいているか
たとえば、保存後に通知を送るコードが追加されたとする。トランザクションのコミット前に通知すれば、保存失敗時に存在しないデータを知らせる可能性がある。コミット後の同期送信なら、通知障害がユーザーの処理を失敗させるかもしれない。問うべきなのは命名ではなく、整合性モデル、再試行戦略、失敗の所有者である。
GitHubも、コーディングエージェントの出力には誤りや脆弱性が含まれ得るため、人間によるレビューとテストが必要だと明記している。GitHub Copilot AgentsのResponsible Use資料で示されているように、自信のある出力と正しい出力は同じではない。
短時間で生成される差分が増えるほど、コードを読む能力の価値は上がる。プログラミングと設計の知識は、自分で全行を書くためだけでなく、大量の技術判断を監査するためにも必要になる。
重要になる仕事4：「動いた」ではなく「正しい」を検証する
エージェントは実装後にテストを実行し、成功を報告できる。しかし、テスト成功は正しさを支える証拠の一部にすぎない。実装とテストを同じエージェントが同時に作れば、同じ要件誤解が両方へ入り、「誤った仕様に対して整合したコードとテスト」ができる可能性がある。
必要なのは、作業を始める前に証拠を設計することだ。
- 受け入れ条件から独立して導いたテスト
- 境界値、異常系、権限違反、重複、並行実行のテスト
- 既存機能の回帰テスト
- 型チェック、静的解析、依存関係、脆弱性の検査
- 必要に応じた性能比較や負荷試験
- 本番に近い環境での統合確認
- カナリアまたは段階的リリース
- メトリクス、ログ、トレース、アラート
- ロールバックとデータ修復手順の確認
すべての変更へ最大級の検証を行う必要はない。重要なのは、リスクに比例させることだ。文言修正と認可ロジックの変更に同じ証拠を求める必要はない。データ損失、権限昇格、課金、不可逆な移行に関わる変更ほど、独立したテスト、段階的な展開、人間の承認を厚くする。
「テストが通った」という報告だけでなく、実行したコマンド、対象環境、結果、未実施項目も確認する。利用できない外部サービスや資格情報があれば、その範囲は未検証である。成功と未確認を混ぜないことが説明責任の出発点になる。
問いは「AIに何本テストを書かせたか」ではない。「どの証拠があれば、この変更を安全に出せるか」である。検証可能性を先に設計すれば、出力を流暢さや印象ではなく、再現可能な結果で評価できる。
AIエージェントを前提に開発フローを組み直す
AI活用を、従来工程の実装部分へツールを差し込むだけで終わらせない。調査、実装、検証、運用から得た情報を、次の入力へ戻す反復可能な流れを作る。
1. 解決する問題を定義する
2. 変更範囲と制約を明文化する
3. 完了条件と検証方法を先に決める
4. エージェントに調査させ、計画と仮定を確認する
5. 小さな単位で実装させる
6. 差分、判断理由、未解決リスクをレビューする
7. 独立した自動検査と人間のレビューを行う
8. 段階的にリリースし、本番結果を観測する
9. 得られた知識を文書、テスト、ルールへ戻す一度の巨大な依頼より、検証可能な小さな単位のほうが、誤解を早く発見し、差分を戻しやすい。調査段階では既存パターンと影響範囲を示させ、実装前に仮定を確認する。実装後はエージェント自身の説明だけで完結させず、CI、別視点のレビュー、本番観測へ接続する。
人間の役割は、すべてのコードを手で入力する人から、エージェントが安全に反復できる環境を設計する人へ広がる。責任を手放すのではなく、制約、権限、検査、承認、観測へ埋め込むのである。
評価軸も、生成量から安全な成果へ変える
コミット数、変更行数、実装機能数、コーディング時間を生産性の中心に置くと、不要なコードを増やす行動を評価しかねない。生成が安価になるほど、量の指標は成果から離れる。
代わりに見るべきなのは、次のような結果である。
- 要件の曖昧さや重大なリスクを実装前に減らしたか
- リードタイムを短縮しつつ、障害やデグレを増やしていないか
- 変更を観測でき、必要なら安全にロールバックできるか
- テストと検証結果が再現可能か
- 文書、開発環境、ルールがチームで再利用されているか
- エージェントの手戻りや人間のレビュー負荷を減らしたか
- 個人だけでなく、チーム全体の安全な開発能力を高めたか
速度だけでなく変更失敗や復旧も見る考え方は、DORAのソフトウェアデリバリー指標とも整合する。ただし、これらを単一のランキング指標にしてはいけない。障害件数だけを下げれば、「何もリリースしない」が最適になってしまう。速度、品質、回復可能性、学習を組み合わせて評価する必要がある。
評価されるのは、自分だけが速くコードを書く人から、チームとエージェントが安全に速く進める仕組みを作る人へ移っていく。
コードを書く力は、不要になるのではなく使い方が変わる
AIエージェントによって、手でコードを書く時間は減るだろう。しかし、プログラミング、データベース、ネットワーク、分散システム、セキュリティの知識は不要にならない。知識がなければ、AIの仮定、競合状態、権限境界、障害時の挙動を評価できないからだ。
若手が基礎を飛ばしてよいわけでもない。小さなプログラムを自分で書き、デバッガを使い、SQLの実行計画を読み、ネットワーク障害を追う経験は、生成結果を診断する土台になる。一方、経験者も「自分で書いたほうが速い」に留まらず、暗黙知を制約、文書、テスト、観測へ変換する必要がある。
AIエージェント時代の優れたエンジニアとは、最も多くコードを書く人ではない。何を作るべきかを定義し、守るべき制約を与え、生成された結果を検証し、安心して本番へ届けられる人である。