LevelUpGo
ログイン
ブログに戻る
Go · 記事3 分で読めます

今でもコードは手で書くべき？2026 年に AI より手書きが勝つ場面

2026 年、コードの大半は AI に書かせられます。それでも研究によれば、自分で書くべき場面はまだあります。学んでいるとき、自分がデバッグすることになるとき、そしてミスが実際の損失につながるときです。

Patrik Nilsson
LevelUpGo 創業者
2026年9月23日 公開
今でもコードは手で書くべき？2026 年に AI より手書きが勝つ場面

書くべきです。ただし全部ではありません。2026 年の今、よくあるバックエンドサービスなら、コードの大半は AI アシスタントに書かせられます。ボイラープレートやテストの雛形、使い捨てのスクリプトは任せてしまってかまいません。一方で、自分で書いたほうがいい場面もあります。新しいことを学んでいるとき、深夜 2 時にデバッグするのが自分になるとき、バグがデータやお金の流出につながるとき、そしてそのロジックがプロダクトの差別化そのものであるときです。なぜそう言えるのか、2025 年から 2026 年にかけての研究がかなり具体的に説明しています。

要約

  • AI を使って学ぶと、理解が浅くなります。Anthropic のランダム化試験では、AI の助けを借りて新しいライブラリを学んだ開発者の事後クイズの得点は 50% でした。手で書いた開発者は 67% で、差がいちばん大きかったのはデバッグの問題です（Anthropic、2026 年）。
  • 「ほぼ正しい」がいちばんよくある失敗です。開発者の 66% が、最大の不満として「ほぼ正しいけれど完全ではない」AI のコードを挙げました。AI が生成したコードのデバッグのほうが時間がかかるという回答も 45.2% ありました（Stack Overflow Developer Survey、2025 年）。
  • セキュリティは追いついていません。AI が生成したコードがセキュリティチェックを通るのは約 55% です。構文の正しさが 95% を超えてからも、この数字は 45% から 55% の間から動いていません（Veracode、2026 年）。
  • AI が役立っているかどうかは、感覚ではわかりません。METR の 2025 年の試験では、経験豊富な開発者が AI を使うと作業時間は 19% 延びました。それでも本人たちは 20% 速くなったと思っていました（METR、2025 年）。
  • ルール：自分でも書けたはずのコードは AI に書かせる。まだ理解できていないものは手で書く。

AI でコードを書くことについて、研究は何を示しているのでしょうか？

AI を使うとコードは速く書けるようになり、そこから学ぶ力は落ちます。しかも、どちらも起きている最中には本人がなかなか気づけません。

いちばんはっきりした証拠は、Anthropic が 2026 年 1 月に発表した研究です。対象は、毎週 Python を使っている主にジュニアのエンジニア 52 人。全員が触ったことのない非同期ライブラリ Trio を使う課題に取り組み、半数だけが AI アシスタントを使えました。課題のあとで、全員がこのライブラリについてのクイズを受けています。平均点は AI グループが 50%、手で書いたグループが 67% でした。研究者たちはこの差を「成績評価でほぼ 2 段階分」と表現しています（Anthropic、2026 年）。AI グループが課題を終えたのは約 2 分早かっただけで、その差も統計的に有意ではありませんでした。

差がいちばん大きかったのはデバッグの問題です。デバッグは、AI が結局こちらに投げ返してくる仕事です。生成されたコードが壊れたら、原因を突き止めるのは自分です。

プログラミング以外の、もっと規模の大きい研究でも同じ傾向が出ています。約 1,000 人の高校生を対象にした数学のランダム化試験で、素の ChatGPT のようなアシスタントを渡された生徒は、演習の得点が 48% 上がりました。ところが AI なしの試験になると、一度も AI を使わなかった生徒より得点が 17% 低くなりました（Bastani et al., PNAS、2025 年）。こなした課題は多くても、身についたものは少なかったわけです。

学習科学の研究者から見れば、どれも意外な結果ではありません。1978 年に Slamecka と Graf が初めて報告した生成効果によれば、人は読んだだけの情報より、自分で生み出した情報のほうをよく覚えています。検索練習（retrieval practice）も同じです。内容を思い出す練習をした学生は、読み直した学生に比べて直後のテストでは点が低かったのに、1 週間後のテストでは上回りました（Roediger & Karpicke, Psychological Science、2006 年）。AI の提案を受け入れるのは、読み直しにかなり近い行為です。解答を記憶から打ち込むほうが、思い出す練習に近くなります。

今でもコードを手で書くべきなのはどんなときでしょうか？

理解していないことで払うコストが、節約できる時間より大きいなら、手で書きましょう。実際にはだいたい次の 6 つの場面です。

言語、ライブラリ、パターンを学んでいるとき

Go を学んでいる途中なら、アシスタントのほうが速く書けるとしても、goroutine やエラーのラップ、interface の定義は自分で書いてください。Anthropic の研究が測ったのはまさにこの状況で、手で書いたグループがはっきり上回りました。

同じ研究では、AI を使えば必ず悪影響が出るわけではないこともわかっています。コードを出してもらったあと、理解できるまで質問を重ねた人や、概念についての質問だけをしてエラーは自分で直した人は、クイズで 65% 以上を保っていました（Anthropic、2026 年）。点が下がったのは、考える作業そのものをアシスタントに渡してしまった人たちです。

自分がデバッグすることになるとき

本番でこのコードが壊れたときに呼び出されるのが自分なら、仕組みを知っておく必要があります。自分で書いたコードなら、どう動くかはもう頭に入っています。受け入れただけのコードだと、障害対応の最中にそれを一から組み立てることになります。Stack Overflow の 2025 年の調査では、開発者の 45.2% がすでに、AI が生成したコードのデバッグは自分のコードより時間がかかると答えています（Stack Overflow、2025 年）。

お金、認証、ユーザーデータを守るコードを書くとき

Veracode が 100 を超えるモデルのコードを調べたところ、サンプルの 45% に OWASP Top 10 の脆弱性が入り込んでいました（Veracode、2025 年）。2026 年春の更新版でも、全体のセキュリティ合格率は 45% から 55% の間で止まったままです。クロスサイトスクリプティングに限ると、安全だったサンプルは 15% しかありません（Veracode、2026 年）。新しいモデルや大きなモデルは構文こそきれいに書きますが、セキュリティの数字は変わっていません。

自信があると、事態はさらに悪くなります。Stanford の研究では、AI アシスタントを使った参加者のほうが安全性の低いコードを書き、しかも自分のコードは安全だと思い込みやすい傾向がありました（Perry et al., ACM CCS、2023 年）。認証、認可、決済処理、入力検証、それに SQL や HTML を組み立てる処理は手で書いてください。せめて、生成されたコードを 1 行残らず、バグがあるはずだと疑うレビュアーの目で読みましょう。

ロジックそのものがプロダクトであるとき

ボイラープレートはどのコードベースでも似たようなものです。一方で、料金ルールやスケジューリングのアルゴリズム、部分的な障害をシステムがどう扱うかは、そのコードベースにしかありません。設計上の判断が詰まっているのはこうしたコードで、書いているうちに仕様が見落としていたエッジケースに気づけます。生成版をレビューしてわかるのは、モデルがそのエッジケースをどう想定したかです。その想定は正しいこともあれば、外れていることもあります。

AI が本当に役立っているのか判断できないとき

METR の 2025 年のランダム化試験では、経験豊富なオープンソース開発者 16 人が、自分のリポジトリにある実際の issue 246 件に取り組みました。AI の使用を認めると、タスクにかかる時間は 19% 延びています。開発者たちは始める前には 24% 速くなると予想し、終わったあとも AI のおかげで 20% 速くなったと思っていました（METR、2025 年）。

ツールの側に立って補足すると、新しいモデルで行った METR の 2026 年 2 月の追跡調査は逆の結果を示しています。経験豊富な開発者は今ならおそらく速くなっている、という推定です。ただし信頼区間はまだゼロをまたいでいます（METR、2026 年）。変わらず当てはまるのは、感覚と実態のずれのほうです。速くなった気がしても、本当に速くなったかどうかはほとんどわかりません。プロンプトを書いては直すループをいつまでも回しているタスクがあったら、いったん止めて自分で書きましょう。

その場に AI がないとき

技術面接、ホワイトボードでのシステム設計、アシスタントの入っていないサーバーでの本番障害対応、考えを口で説明しながら進めるペアプログラミング。どれも AI には任せられません。プロンプト経由でしかコードを書けないと、すぐに見抜かれます。

Go の例：AI 補完が間違えるリトライループ

「ほぼ正しい」が実際にどういうものか、例で見てみます。下流サービスへの不安定な呼び出しをリトライするヘルパーを書いていて、アシスタントが本体を補完したとしましょう。

example.gogo
func retry(ctx context.Context, fn func() error) error {
	var err error
	for i := 0; i < 5; i++ {
		if err = fn(); err == nil {
			return nil
		}
		time.Sleep(time.Second)
	}
	return err
}

コンパイルは通りますし、fn が 2 回失敗してから成功するテストにも合格します。それでも 3 か所間違っていて、負荷がかかったときの Go のサービスの挙動を知らないと気づけません。

  1. context.Context を受け取っているのに使っていません。クライアントが切断しても、サーバーがシャットダウンを始めても、この関数はそのあと最大 4 秒間、スリープしては fn を呼び続けます。負荷が高いと、こうして置き去りにされたリトライがどんどん溜まります。
  2. 待ち時間が固定です。下流サービスがすでに苦しいところへ、呼び出し元がそろって 1 秒おきにリトライすれば、状況は悪くなる一方です。待ち時間は少しずつ延ばしたいところです。
  3. 最後の試行のあとにもスリープしています。最後の time.Sleep は、エラーを返すのを意味もなく 1 秒遅らせているだけです。

この 3 つの問題がわかっていれば、書くのは次のようなコードです。

example.gogo
func retry(ctx context.Context, fn func() error) error {
	const maxAttempts = 5
	delay := 100 * time.Millisecond

	var err error
	for attempt := range maxAttempts {
		if err = fn(); err == nil {
			return nil
		}
		if attempt == maxAttempts-1 {
			break
		}

		timer := time.NewTimer(delay)
		select {
		case <-ctx.Done():
			timer.Stop()
			return errors.Join(err, ctx.Err())
		case <-timer.C:
		}
		delay *= 2
	}
	return err
}

アシスタントに 2 つ目のバージョンを書かせることもできます。ただし、そう頼むべきだと自分がわかっていればの話です。その知識（context のキャンセル、バックオフ、負荷がかかったときに何が起きるか）は、この手のループを実際に書いて、それが失敗するのを見てきた経験から身につきます。そういう経験を積みたいなら、Go Concurrency Fundamentals コースで select、タイマー、context のキャンセルを、実際の Go を実行する演習とともに学べます。

AI にコードを書かせてもよいのはどんなときでしょうか？

自分でも書けたはずのコードで、打つよりレビューするほうが速いなら、AI に書かせてかまいません。何を任せるかについては、Go 開発者の間でもだいたい意見がそろっています。2025 年の Go Developer Survey で AI の用途の上位に入ったのは、ユニットテスト、ボイラープレート、補完、リファクタリング、ドキュメントでした（Go Developer Survey、2026 年）。

AI に任せやすいもの：

  • 最初の 2 つを手で書いた後のテーブル駆動テストのケース
  • struct タグ、JSON のマッピングなどの機械的な変換
  • CLI フラグの解析、設定の読み込みなどのグルーコード
  • パターンがすでに明確な場合の、新しい API へのコードベースの移行
  • 明日には消す使い捨てのスクリプト
  • 何かを変更する前に、見慣れないコードベースやエラーメッセージを説明してもらうこと

ただ、同じ調査を見ると、出力のチェックは欠かせないとわかります。AI ツールに満足している Go 開発者は 55% だけで、いちばん多い不満は「動かないコード」（53%）でした。回答者の 4 分の 1 は、コードを書く作業には AI にいっさい関わってほしくないと答えています。調査の中で、AI への抵抗がこれほど強かった作業はほかにありません（Go Developer Survey、2026 年）。

AI を活用した開発のために言語を選んでいるなら、Go が AI の書くコードに最適な言語である理由で、Go の小さな言語仕様、厳しいコンパイラ、安定した API が生成コードに向いている理由を解説しています。チームがそのコードの確認をやめたときに何が起きるかは、AI コーディングツールの負の側面で、本番障害、削除されたデータベース、レビューの過負荷に関する 2026 年のデータとともに解説しています。

シンプルなルール：自分でも書けたかどうか

提案を受け入れる前に、自分に 1 つだけ聞いてみてください。もう少し時間があれば、これを自分で書けただろうか。

書けたなら、受け入れて、読んで、先へ進みましょう。AI を速いキーボード代わりに使っているだけなので、間違いがあれば自分で気づけます。

書けなかったなら、それこそ手で書くべきコードです。少なくとも、提案を読んだあとで記憶を頼りに組み立て直してください。学びが起きるのはこういうコードで、バグを見逃しやすいのもこういうコードです。

Microsoft Research と Carnegie Mellon が 2025 年に 319 人のナレッジワーカーを対象に行った調査も、同じ結論を出しています。「GenAI への信頼が高いほど批判的思考は少なくなり、自分自身への信頼が高いほど批判的思考は多くなる」（Microsoft Research、2025 年）。自分でも書けるとわかっているからこそ、コードを批判的に読み続けられます。すでに毎日 AI を使っていて、この力を保ちたいなら、AI がコードを書く時代にコーディングスキルを鈍らせない方法で、AI を使わない練習を毎週のルーティンとして紹介しています。

LevelUpGo の役割

LevelUpGo は、この「手で書く」部分を軸に作っています。どのレッスンも左に解説、右に本物のエディタがあり、書いた Go のコードがコンパイルを通ってテストに合格すると次へ進めます。エディタに自動補完はないので、ミスをするのも直すのも自分です。まずは無料の Go Fundamentals コースから始めてみてください。慣れてきたら Training Ground に単発の演習があります。仕事ではボイラープレートを AI に任せつつ、腕がなまらないようにしておけます。

どこから手をつけるか迷っているなら、2026 年のプログラミング勉強法で AI を近道ではなく家庭教師として使う方法を、Go でよくある間違い 10 選で生成コードの中から見抜けるようにしておきたいバグを紹介しています。AI に考えることを任せたとき学習に何が起きるかは、脳を AI に外注しないをご覧ください。

よくある質問

AI がコードを書ける今でも、プログラミングを学ぶ価値はありますか？

あります。AI が書くコードは「ほぼ正しい」ことが多く、開発者の 66% がそれを AI に対する最大の不満に挙げています（Stack Overflow、2025 年）。間違っている部分を見つけて直すには、自分で書くのと同じだけの理解が要ります。今プログラミングを学ぶのは、コードを書くためだけではありません。コードの良し悪しを判断できるようになるためでもあります。

AI を使うとプログラマーとしての力は落ちますか？

考える手間を省くために使うなら、落ちることがあります。Anthropic の 2026 年の研究では、学習中に AI に任せきりにした開発者は、理解度の得点が 17 ポイント低くなりました。AI を使って概念的な質問をし、自分のエラーは自分で直した開発者は、手でコードを書いた開発者とほぼ同じ得点でした（Anthropic、2026 年）。

初心者は AI コーディングアシスタントを使うべきですか？

自動補完ではなく、家庭教師として使ってください。エラーを説明してもらう、2 つのやり方を比べてもらう、概念についてクイズを出してもらう、といった使い方です。解答は自分で書きます。基礎を学んでいる間は、インライン補完は切っておくのがおすすめです。提案を受け入れると前に進んだ気になりますが、記憶に定着させる肝心の部分を飛ばしてしまいます。

どのコードを必ず 1 行ずつレビューすべきですか？

認証、認可、決済、入力検証、そして SQL クエリ、HTML、シェルコマンドを組み立てるコードすべてです。AI が生成したコードは今でもおよそ半分の確率でセキュリティチェックに不合格となり、クロスサイトスクリプティング対策が合格するのはわずか 15% です（Veracode、2026 年）。

経験豊富な開発者にとって、AI は本当に速いのですか？

おそらく速いですが、感覚ほどではありません。METR の 2025 年の試験では 19% の遅延が測定された一方で、開発者たちは 20% 速くなったと信じていました。2026 年の追跡調査によると、新しいツールでは多少速くなっているようですが、不確実性はまだ大きいままです（METR、2026 年）。感覚に頼らず、自分のタスクで実際に測ってみてください。

出典

シニアエンジニアのように Go を書く

ブラウザで学べるインタラクティブなレッスン。最初のレッスンは無料です。

無料レッスンを試すまたは無料アカウントを作成