コーディング支援AIで、実際に何が変わったのか
AIによるコーディング支援は、この数年で最も実務への影響が大きかった領域です。定型的なコードを書く時間、見慣れない言語やライブラリを調べる時間、既存コードを読み解く時間は、確かに大きく短縮されました。
一方で、開発案件が短期間で終わるようになったわけではありません。「動くものができるまで」は劇的に速くなったのに、「業務で使える状態にするまで」はあまり変わっていない。この非対称が、いまいちばん誤解を生んでいる点です。この章ではその差の中身を具体的に見ます。
使い方は3つのモードで捉える
コーディング支援AIは製品名で分類すると混乱します。主要な製品はいずれも複数のモードを持つようになっており、製品名と使い方は1対1で対応しません。実際に使うモードで捉えるのが正確です。
- 入力補完モード ― エディタで書いている途中に続きを提案します。人が1行ずつ受け入れるかを判断する使い方です。既存の書き方に沿った提案が出るため、レビューの負荷は小さくなります。
- 対話モード ― やりたいことを説明して、コードの塊を書かせます。設計の相談や、エラーの原因調査にも使います。出てきたコードは人が読んで判断します。
- エージェントモード ― 目的を伝えると、複数のファイルの作成・修正・テスト実行までを続けて進めます。人が見るのは結果です。速度は最も高く、レビューの負荷は最も大きくなります。
重要なのは、同じ製品でもどのモードを使うかでレビュー体制とリスクの所在がまったく変わることです。入力補完モードを使っているチームと、エージェントモードに任せているチームでは、必要な確認工程が別物になります。ツール選定の議論をするときは、製品名ではなく「どのモードで、何を任せるか」を決めてください。
「動くもの」と「使えるもの」の差
デモが動くところまでは速い。そこから先に何が残っているのかを列挙します。
- 異常時の動き ― 通信が切れた、想定外の値が来た、同じ処理が二重に走った。正常系だけのコードは、この分岐を持ちません。
- 権限と認証 ― 誰がどのデータを見られるのか。社内ツールでも、人事情報や取引情報が絡めば必須です。
- データの整合性 ― 処理の途中で失敗したときに、中途半端な状態が残らないようにする設計です。
- 性能 ― 10件で動いた処理が、10万件で動くとは限りません。
- 保守できる状態 ― 半年後に別の人が読んで直せるか。テストがあるか。設定が散らばっていないか。
- 運用の受け皿 ― 障害に誰が気づくのか。ログはどこに出るのか。復旧手順はあるか。
この6項目は、いずれも動作確認では現れません。デモの完成度と本番品質が違うのは、能力の差ではなく見えている範囲の差です。そしてこの差は、発注や見積もりの段階で消えることがあります(裏之巻 第4章「発注側が陥りやすい罠 ― 要件定義しか見ない発注」)。
朝凪精機の総務の申請フォームは、当時の担当者が開発支援AIを使って3日で作ったもので、社内の評判もよいものでした。問題が出たのは、その担当者が異動したあとです。仕様を書いた資料がなく、設定値がコードの中に直接書かれていたため、承認者を1人足すだけの変更に2週間かかりました。そのあいだ、総務課の戸田は申請を紙で回していました。3日で作れたことは社内で褒められましたが、紙で回した2週間は誰も数えていませんでした。この件は三月九日、問い合わせ記録の入力画面の発注を話し合う席で、引き継げなかった例として持ち出されています。作るのが速くなったぶん、引き継げる状態にする作業の相対的な重みが増しているということです。
この場面は物語之巻 第4話「仕様書に書いていないこと」に出てきます。
プロンプトだけでは埋まらない知識
「指示の書き方が上手ければ良いコードが出る」という説明は、半分は正しく、半分は誤りです。指示の精度は確かに結果を変えます。しかし変わるのは指示した範囲の中身だけで、指示しなかった観点は出てきません。
たとえば「この処理を高速化して」と頼めば高速化されます。しかし、その高速化がデータの整合性を犠牲にしていないかは、依頼した側が知識を持っていないと判断できません。「セキュリティに気をつけて」と書き添えても、何を守るべきかを自分が知らなければ、出力の妥当性を確認できません。
つまりAIは、知っている人の作業を速くする道具です。知らない人が知らないままで完成させられる道具ではありません。ここを正確に理解しておくことが、外注や自作の判断にも直結します。
AIに任せやすい領域と、任せにくい領域
実務上、精度が出やすい境界はかなりはっきりしています。
比較的任せやすいもの
形式と検証のルールが世の中に広く定着していて、判断の余地が小さいものです。
- 郵便番号 ― 桁数と形式が固定で、検証方法が確立している。
- 生年月日・日付 ― 妥当性の判定ルールが明確(うるう年を含む)。
- 法人番号 ― 桁数とチェック計算の方法が公開されている。
- 税区分の計算 ― 税率と適用ルールが明文化されている(税制改正の反映は別途必要)。
- 一般的なデータ変換、定型的な集計、テストコードの雛形作成。
一見定石に見えて、実は難しいもの
「よくある項目だから簡単だろう」と思われがちですが、実務データでは苦戦する代表例です。
- メールアドレス ― 厳密な形式判定の規則は例外が多く、正しいアドレスを弾いてしまう実装が生まれやすい。
- 住所 ― 表記の揺れ(丁目・番地・ハイフン・ビル名・旧住所)が多く、正規化の正解が一意に決まらない。
- 人名 ― 異体字、外国名、姓名の区切り、ミドルネーム。
- 電話番号 ― 市外局番の桁数が地域で異なり、内線・国際表記も混ざる。
AIが提案する検証ロジックは、必ず実在データのサンプルで突き合わせてください。もっともらしく動くコードが出てくるため、レビューだけでは見逃します。過去1年分の実データを数百件流し、弾かれた件数と内容を確認する。この工程を入れるかどうかで、稼働後の手戻りが大きく変わります。
もう一つの境界 ― 自前ロジック型とサービス連携型
作るものの性質でも、難易度がはっきり分かれます。
- 自前ロジック型 ― 計算や変換を自分のコードの中だけで完結させるもの。AIの提案精度は高く、テストも書きやすい領域です。
- サービス連携型 ― 社内の基幹システムや外部サービスとつなぐもの。相手側の仕様・認証・制限に依存するため、AIが知らない情報が支配的になります。手元にある仕様書や実際の応答を渡さないと、もっともらしい間違いが出ます。
見積もりの精度を上げたいなら、この2つを分けて数えることです。前者は短く見積もれますが、後者は相手の仕様確認と疎通試験に時間がかかります。
セキュリティと保守性 ― 見落とされやすい品質
最後に、動作確認では絶対に現れない2つの品質について触れます。
セキュリティは、指示しなければ考慮されません。入力値の検証、権限の確認、機密情報の扱い、ログに残してよい情報の範囲。これらは「動く」ことと無関係なので、テストが通っても不備は残ります。特に自作ツールでは、社内向けだからという理由で認証が省かれがちです(第5章で扱います)。
保守性は、時間が経ってから請求書が来る性質の品質です。半年後に自分以外が読める状態か、変更が1箇所で済むか、設定が外から変えられるか。AI支援で作る速度が上がったぶん、この観点を意識的に指示に含める必要があります。「動いたら終わり」ではなく、「引き継げる形にする」ところまでを完成条件に含めてください。
生産性の測り方についても一言。書いたコード量や作った機能数で測ると、AI支援の効果は非常に大きく見えます。しかし本当に見るべきは、稼働後に発生した障害件数と修正にかかった時間です。前者だけで判断すると、後から支払う分を見落とします。