AI がコードを書く時代でも、「誰でも作れる」わけではない

AI に任せられるコードを、人間が一行ずつ手で書く必要はなくなりつつあります。しかし、AI に入力できることと、意図したシステムを完成させ、品質を維持できることは同じではありません。人間の仕事は、コードの手入力から、目的を共有し、根拠を集め、決定し、その決定が守られているかを検証することへ移ります。

プログラミングは昔から「入力するだけ」だった

生成 AI が登場してから、「AI に入力するだけだから、誰でも作れる」という説明を見かけるようになりました。

けれど、プログラミングは以前からコンピューターへ文字を入力する仕事でした。技術書や公式ドキュメントを読み、サンプルコードをコピーし、検索で見つけた断片を組み合わせる。かつては「サンプルコードをコピー＆ペーストすれば、誰でも作れる」と言われることもありました。

確かに、決められた条件で一度動くものなら作れます。AI によって、その入口はさらに広くなりました。

しかし、サンプルを書いた人は、すでに多くの判断を済ませています。前提となる環境、採用する設計、エラーの扱い、依存するライブラリなどです。コピーする人が技術的な判断をしなくてよいように見えたのは、その判断を別の誰かが先に引き受けていたからです。

AI も同じです。違うのは、固定されたサンプルを探す代わりに、その場で新しい実装を生成できることです。そのため、借りている判断と、自分で決めなければならないことの境界は、以前より見えにくくなりました。

一行ずつ補完する段階も過ぎつつある

AI による開発は、人間が一行考え、AI が続きを候補として表示し、人間が Tab キーで採用するだけではなくなっています。それは人間によるコーディングを高速化する段階でした。

現在は、変更の目的と制約を渡し、AI にコードベースを調査させ、複数のファイルを変更し、テストを実行し、失敗から修正させられます。人間がコードの全行を指示する必要はありません。

人間が一文字ずつ書く
    ↓
サンプルをコピーする
    ↓
AI が一行ずつ補完する
    ↓
AI へ変更単位で仕事を渡す
    ↓
AI が調査・実装・検証・修正を反復する

AI に任せるより手で直した方が速い数行まで、意地になって生成させる必要はありません。ただし、手で入力したこと自体を品質や努力の証明にする意味もありません。選ぶ基準は、成果までの速度と確実性です。

誰でも作り始められるが、誰でも完成させられるとは限らない

AI を使うと、最初のデモまでは驚くほど速く進みます。問題は、その後です。

修正するたびに別の場所が壊れる
以前できていた機能がなくなる
当初とは違う仕様へ少しずつ変わる
同じ役割の処理が複数の場所に増える
AI が変更した理由を説明できない
変更の影響が分からず、触るのが怖くなる

根本にあるのは、人間と AI の間で「何を作ろうとしているのか」が共有されないまま、変更だけが積み重なることです。

だからといって、最初に完璧なプロンプトや仕様書を用意すれば解決するわけでもありません。人間自身も、作り始める前からすべての条件を言語化できるとは限りません。調査や試作の途中で、初めて分かる制約もあります。

必要なのは、一度で正解を引き出す言葉ではなく、理解を更新し続ける進め方です。

目的を伝える
    ↓
AI に現状を調査させる
    ↓
不明点と選択肢を出させる
    ↓
人間が必要な決定を下す
    ↓
AI に理解した仕様と影響範囲を説明させる
    ↓
小さく実装・検証する
    ↓
結果から目的・仕様・テストを更新する

必要なのはプロンプトの技巧でも会話のうまさでもない

AI との意思疎通が重要だと言うと、長い文章を書ける人、語彙が豊富な人、AI に効く特別な言い回しを知っている人が有利だと受け取られがちです。

しかし、必要なのは雄弁さではありません。

曖昧になっている点を見つける
現在の状態と期待する状態を分ける
守る条件と変えてよい部分を区別する
AI が示した選択肢の違いを理解する
対象外にすることを決める
結果と意図のずれに気づく

説明しにくければ、AI に質問させればよいのです。文章だけでなく、既存コード、画面、ログ、実例と反例、図、テストも、意図を共有するための材料になります。

必要なのは語彙力ではなく、曖昧さを発見し、必要な判断を下し、その判断を検証可能な形に残す能力です。

AI が示す選択肢を人間が決定へ変える

AI は選択肢を作れます。それぞれの利点と欠点を比較し、推奨案を示し、その案を実装することもできます。

しかし、複数の正解がある場面で、何を優先し、どの制約や損失を引き受けるかを決め、その結果に責任を持つのは人間です。

安全性を優先して操作を増やすのか
自動化を優先して誤動作時の影響を受け入れるのか
互換性のために設計の複雑さを残すのか
納期のために一部の機能を後回しにするのか

これらは、コードや資料を調べれば一つの答えが見つかる問題ではありません。AI が質問してくるのは、会話能力を試しているからではなく、人間側の意思がなければ決まらない部分が残っているからです。

ただし、人間が闇雲に選べばよいわけでもありません。決定には、目的、現在の状態、制約、影響範囲、証拠、許容できるリスクの理解が必要です。証拠が足りなければ、小さな実験を行うか、決定を保留する必要があります。

決定力とは即断力ではありません。決めるべきこと、AI へ委ねてよいこと、まだ決めてはいけないことを区別し、結果を見て決定を更新する力です。

暗記は減っても、技術的な理解はなくならない

ここは学校でも試験会場でもありません。コマンド、構文、ライブラリの関数名を何も見ずに書けることは、目的ではありません。資料を見ても、検索しても、AI に聞いても構いません。

一方で、暗記が不要になったことを、理解まで不要になったことにすり替えることはできません。

AI が「この実装で問題ありません」と説明しても、技術的な土台がなければ、次のような問題に気づけません。

認証と認可を混同している
秘密情報の保存場所が適切ではない
データの整合性が壊れる
別のコンポーネントへの影響が抜けている
障害時に復旧できない
ネットワークや実行環境の前提が現実と違う
テストと実装が同じ誤解に基づいている

細かな構文を記憶している必要はありません。しかし、システムがどうつながり、どこに状態があり、どの境界を越え、どこで失敗し得るかというアーキテクトの視点は必要です。

経験とは、長く手を動かした年数だけではありません。どこが壊れやすいか、何を確認しないと危険か、目の前の成功をなぜ疑うべきかを知っていることです。

レビューの単位をコードからシステムへ移す

大局的なレビューは、AI によって新しく生まれたものではありません。本来、レビューが担うべきだった役割です。

人間がコードを書いていたときは、条件の書き忘れ、例外処理の不足、API の誤用など、局所的な実装ミスが頻繁に入りました。レビュー担当者の注意は、差分を一行ずつ追ってバグを探すことに使われます。「そもそも、この変更は正しい問題を解いているのか」へ到達する前に、時間と集中力を使い切ることもありました。

局所的な確認が不要になるわけではありません。ただし、静的解析、テスト、レビュー用 AI、実装 AI の修正ループへ移せる範囲は広がります。人間の限られた注意力は、より大きな問いへ向けるべきです。

この変更は何の問題を解決するのか
AI が置いた前提は正しいか
責任、状態、データ、権限の境界は正しいか
既存機能や他のコンポーネントへ何が影響するか
通信断、再起動、タイムアウト、部分成功時にどうなるか
失敗後に安全な状態へ戻れるか
期待した状態になったと判断できる証拠は何か
まだ確認できていないことは何か

一行ずつ見るともっともらしいコードでも、システム全体としては間違っていることがあります。確認すべきなのは「このコードは正しいか」だけではありません。「この変更によって、システム全体が意図した状態になったと言えるか」です。

AI 時代のレビューは、コードの行ではなく、コードを生み出した前提、意思決定、影響範囲、失敗時の振る舞い、採用を判断するための証拠を見ます。

単体テストだけでは品質を説明できない

単体テストの価値がなくなるわけではありません。複雑な計算、明確な入出力を持つロジック、境界値、例外条件、状態遷移を高速に確認するために有効です。

しかし、AI は実装と同時に大量の単体テストも生成できます。実装とテストが同じ誤解に基づいていれば、間違った仕様を実装し、その間違いを正しいと証明するテストまで作れます。コードカバレッジが高くても、重要な失敗が検証されているとは限りません。

品質を説明するには、複数の軸が必要です。

要求と意思決定を網羅しているか
重要な状態遷移を通っているか
コンポーネント間の契約を確認しているか
権限、秘密情報、データの境界を確認しているか
通信断や部分失敗を扱っているか
再起動、復旧、取り消しの経路を確認しているか
以前の機能が失われていないか
コード上の分岐や境界値を通っているか

さらに、正しい実装でテストが通るだけでは不十分です。わざと壊したときにテストが落ちることも確かめます。たとえば削除する処理なら、処理の前にあったものが処理の後に消えていることまで確認する。分岐を反転させる。応答を欠落させる。mutation testing や、意図的に失敗する条件を置く陰性対照によって、テストが本当に誤りを検出できることを確かめます。

テスト仕様書を品質の契約書へ変える

AI が具体的なテストケースやテストコードを展開できるなら、人間が最初に定義すべきものは、操作手順の一覧より一段上にあるテスト観点です。

各観点について、次の内容を残します。

何を守るための確認か
どの要求、設計判断、リスクに由来するか
常に成立すべき性質は何か
どんな失敗を想定するか
どの利用者、状態、環境が対象か
何を観測できれば成功か
起きてはいけない状態は何か
欠陥を検出できることをどう確かめるか
今回は何を確認せず、どのリスクが残るか

AI には、観点を具体的な要件とテストケースへ展開させ、組み合わせ、境界値、矛盾、未対応の要件を確認させます。さらに別のレビューでは、「このテストをすべて通りながら、要求を満たしていない実装を作れるか」と問えます。見つかった抜け道は、新しいテスト観点になります。

重要な合格条件を、実装を担当する AI が自由に書き換えられる状態にはしません。要求変更なのか、テストの修正なのかを分け、変更理由を残します。

テスト仕様書は、手順を並べた作業指示書から、AI が実装、検証、修正を反復するための品質の契約書へ変わります。

一人開発では「生きた品質台帳」を残す

一人で開発していると、設計、実装、テスト、レビューを明確な期間に分けることは困難です。同じ日に何度も行き来します。

役割を人や期間で分ける代わりに、残す成果物と通過条件を分けます。最初に、状態遷移、権限、外部との境界、障害と復旧、互換性など、プロジェクトで外せないテスト観点を定めます。そして変更のたびに、AI へ次を求めます。

今回影響するテスト観点を特定する
各観点を具体的で検証可能な要件へ落とす
新しい判断が必要なら、推測せず質問する
既存の決定や要件との矛盾を確認する
必要なテストを追加して実行する
要件、テスト、実行結果の対応を更新する
未確認事項、対象外、残存リスクを記録する

この記録は、チャットの中だけに残してはいけません。次の AI セッションでも読めるよう、プロジェクトの成果物として保存します。

テスト観点
    ↓
今回の具体的な要件
    ↓
対応するテスト
    ↓
実行結果と証拠
    ↓
未確認事項・残存リスク

最初からすべての観点を見つけることはできません。開発中や運用中に新しい失敗を発見したら、一度限りの修正で終わらせず、品質台帳へ戻します。経験を個人の記憶や過去の会話ではなく、以後も検証される仕組みとして蓄積します。

人間の仕事はコードを書くことから決めることへ移る

AI によって、コードを書くための摩擦は大きく下がりました。暗記や手入力を技術力の中心に置く必要もありません。局所的な実装ミスの発見と修正も、AI へ移せる範囲が広がります。

その結果、人間に残るのは、AI へ指示を入力するだけの仕事ではありません。

未知の問題に向き合う
本当に解くべき問題を定める
技術的な仕組みと制約を理解する
AI の質問に必要な判断を返す
根拠を集めて決定する
システム全体への影響を確認する
品質の観点と合格条件を定義する
証拠と残存リスクを見て採用を決める

AI は選択肢を作り、比較し、推奨案を示せます。その中から何を選び、どの結果を引き受けるかを決め、責任を持つのは人間です。そして人間に必要なのは、闇雲に決める力ではなく、問題解決、IT リテラシー、アーキテクチャの知識と経験に基づいて決める力です。

誰でも AI へ入力できます。誰でも何かを生成できます。しかし、生成物を一貫したシステムへ収束させ、変化の中でも品質を維持するには、目的、決定、検証をつなぐ方法が必要です。

コードを一行ずつ手で書く必要性が減っているのであって、考える必要性まで減っているわけではありません。

手作業を手放した後に何を学び、どこへ進むのかは、CAT5e のケーブルを自作した私たちは、AI 時代に何を学ぶのかでも考えています。