AIを使ったコーディング・システム開発

速くなったのは「動くものまで」

コーディング支援AIは、この数年で最も実務への影響が大きかった領域です。定型的なコードを書く時間、慣れない言語やライブラリを調べる時間、既存コードを読み解く時間は、実際に大きく短縮されました。

シンプル版のシンプル版を読んだ方は、モードの区別と「動くもの」との差までは同じです。この章が足すのは、レビューとテストの自動化・エージェントによる自律的開発・レガシー統合・生産性の測り方です。

一方で、開発案件が短期間で終わるようになったわけではありません。短縮されたのは着手から動作までの区間だけで、そこから業務に載せるまでの区間はほとんど変わっていません。この非対称が、見積もりと期待値の食い違いを生んでいます。

本章では差の中身を具体的に扱います。第12章(ツールの自作)、第13章(アーキテクチャ)、第14章(テスト)と合わせて、開発・実装編を構成します。前提知識は第2章です。

支援AIの3つの使い方(モード)

コーディング支援AIを製品名で分類すると混乱します。主要な製品はいずれも複数のモードを持つようになっており、製品名と使い方は1対1で対応しません。実際に使うモードで捉えるのが正確です。

重要なのは、同じ製品でもどのモードを使うかで必要な確認工程が変わることです。入力補完を使っているチームと、エージェントに任せているチームでは、レビュー体制もリスクの所在もまったく違います。

したがってツール選定の議論は、製品の比較ではなく「どのモードで、何を任せるか」から始めるべきです。そのうえで、モードごとに確認の方法を決めます。

モードごとの確認の型

• 入力補完 ― 通常のコードレビューで足ります。ただし既存コードに誤ったパターンがある場合、それが増殖する点に注意します。
• 対話 ― 出力されたコードを人が読んで理解できることを条件にします。理解できないコードを取り込むと、保守できなくなります。
• エージェント ― 変更の差分を必ず確認します。加えて、変更してよい範囲を事前に制限することが有効です(触らせないディレクトリ、実行させないコマンド)。

「動くもの」と「使えるもの」の差

デモが動くところから先に何が残っているのかを、項目として列挙します。

右列がすべて「現れない」であることが本質です。デモの完成度と本番品質が違うのは能力の差ではなく、見えている範囲の差です。この一覧を受け入れ条件のひな型として使えば、認識の食い違いは大きく減ります(第9章)。

プロンプトだけでは埋まらない知識

「指示の書き方が上手ければ良いコードが出る」という説明は、半分正しく半分誤りです。指示の精度は結果を変えますが、変わるのは指示した範囲の中身だけです。指示しなかった観点は出力に現れません。

具体例で示します。

• 「この処理を高速化して」と頼めば高速化されます。しかしその高速化がデータ整合性を犠牲にしていないかは、依頼側が知識を持たないと判断できません。
• 「セキュリティに配慮して」と添えたところで、守るべき対象を依頼側が把握していなければ、返ってきた実装の妥当性は判定できません。
• 「テストを書いて」と頼めばテストは出ますが、それが意味のある条件を検証しているかは読める人にしか分かりません。

つまりAIは知っている人の作業を速くする道具です。知らない人が知らないままで完成させられる道具ではありません。この認識は、外注・自作の判断(第12章)と、体制設計(第8章)に直結します。

AIに任せやすい領域と、任せにくい領域

精度が出やすい境界は、実務上かなりはっきりしています。

比較的任せやすいもの

形式と検証のルールが広く定着しており、判断の余地が小さいものです。

• 郵便番号 ― 桁数と形式が固定で、検証方法が確立している。
• 生年月日・日付 ― 妥当性の判定ルールが明確(うるう年を含む)。
• 法人番号 ― 桁数とチェック計算の方法が公開されている。
• 税区分の計算 ― 税率と適用ルールが明文化されている(改正の反映は別途必要)。
• 一般的なデータ変換、定型的な集計、テストコードの雛形、既存コードの説明。

一見定石に見えて、実は難しいもの

「よくある項目だから簡単だろう」と扱われますが、実務データでは苦戦する代表例です。

• メールアドレス ― 厳密な形式判定の規則には例外が多く、正しいアドレスを弾く実装が生まれやすい。
• 住所 ― 表記のゆれ(丁目・番地・ハイフン・ビル名・旧住所)が多く、正規化の正解が一意に決まらない。
• 人名 ― 異体字、外国名、姓名の区切り、ミドルネーム。
• 電話番号 ― 市外局番の桁数が地域で異なり、内線・国際表記も混ざる。

もう一つの境界 ― 自前ロジック型とサービス連携型

作るものの性質でも難易度が分かれます。

• 自前ロジック型 ― 計算・変換を自分のコード内で完結させるもの。提案精度は高く、テストも書きやすい領域です。
• サービス連携型 ― 社内の基幹システムや外部サービスとつなぐもの。相手側の仕様・認証・制限に依存するため、AIが知らない情報が支配的になります。手元の仕様書や実際の応答例を渡さないと、もっともらしい間違いが出ます。

見積もりの精度を上げたいなら、この2つを分けて数えることです。前者は短く見積もれますが、後者は仕様確認と疎通試験に時間がかかります。

コードレビューとテストの自動化

AIはコードを書く側だけでなく、確認する側にも使えます。ただし役割を明確にする必要があります。

AIによるレビューが効く場面

• 機械的な観点の網羅(未処理の例外、リソースの解放漏れ、命名の一貫性)
• 変更の影響範囲の説明(この変更が何に影響するかの列挙)
• 既存コードの意図の説明(レビュー前の理解を助ける)
• テストケースの候補出し(境界値、異常系の洗い出し)

AIによるレビューで代替できない場面

• 業務要件との一致の判断 ― この処理が業務として正しいかは、業務を知る人しか判定できません。
• 設計の妥当性 ― 将来の変更に耐える構造かどうかの判断。
• リスクの受け入れ判断 ― この程度の不備を許容するかどうかは人の決定です。

実務的な組み合わせは、AIが機械的な観点を網羅し、人が業務要件と設計を見る形です。AIのレビューを人のレビューの代わりにすると、業務要件の誤りが通過します。

エージェントによる自律的開発の実際

目的を伝えると、複数ファイルの変更・テスト実行・修正までを続けて進める使い方です。速度は最も高く、注意点も最も多い形です。

実際に起きること

• 最初の8割は非常に速い ― 骨格と基本機能は短時間で形になります。
• 残り2割で手戻りが出る ― 既存システムとの接続、例外処理、権限の扱いは、こちらが情報を渡さないと進みません。
• 指示していない範囲まで変更されることがある ― 関連するファイルを「改善」してしまう場合があります。差分の確認が必須です。
• テストが通ることを目的にした修正が起きる ― テストの条件自体を緩める形の修正が混ざることがあります。テストの変更は特に注意して見ます。

運用の原則

1. 変更範囲を制限する ― 触らせないディレクトリ、実行させないコマンドを事前に設定します。
2. 差分を必ず読む ― 変更されたファイルの一覧と、各変更の内容を確認します。
3. テストの変更を別扱いにする ― テストが緩められていないかを個別に確認します。
4. 外部への操作は人が承認する ― デプロイ、データの削除、外部への送信は自動実行させません(第21章)。
5. 作業の記録を残す ― 何を指示し、何が変更されたかを追える状態にします。

レガシーシステムとの統合

既存の古いシステムとつなぐ場合、AI支援の効きが落ちます。理由は明確で、そのシステムの情報が公開されていないため、AIが知らないからです。

実務的な対処は、情報を渡すことです。

• データベースの定義(テーブル構造、項目の意味)
• 実際のデータのサンプル(機密情報を除いたもの)
• 既存コードの該当部分
• 過去の障害と対処の記録

これらを渡さずに「基幹システムと連携する処理を書いて」と依頼すると、一般的な構成を前提にしたコードが出てきます。動作確認の段階で判明しますが、それまでの時間が無駄になります。

もう一つの注意点は、古いシステムの制約を「改善」しようとしないことです。既存の仕様には理由がある場合が多く、変更の影響が広範に及びます。連携部分は既存の作法に合わせるのが原則です。

ドキュメント生成とコード解説

効果が確実で、リスクが低い用途です。とくに次の場面で価値があります。

• 既存コードの理解 ― 引き継いだコードの構造と処理の流れを説明させる。
• 変更履歴の整理 ― 差分から変更内容の要約を作る。
• 運用手順書の下書き ― コードから設定項目と起動方法を抽出する。
• 設計資料の補完 ― 実装から現状の構成図を作る。

ただし、生成された説明が実装と一致しているかは確認が必要です。とくに「なぜそうしたか」という意図は、コードには書かれていないため推測になります。意図の部分は人が補います。

開発生産性の測定と過信への注意

AI支援の効果を測る指標の選び方で、結論が大きく変わります。

最後の行が最も重要です。本当に見るべきは、稼働後に発生した障害件数と修正にかかった時間です。着手から動作までの時間だけを見ると、後から支払う分を見落とします。