Claude Codeで開発作業が1%に。AI駆動開発でエンジニアがコードを書くのをやめる理由

僕が1日に手動で書くコードの割合は、全作業の1%未満だ。

以前はひたすらキーボードを叩いていたが、今はAIに仕様書を渡し、出力を評価する。開発スピードは上がり、残業も減った。

最新のAIが重ねた自律的な試行の回数は600回を超え、自らコードの戦略を修正する。

エンジニアの仕事は「コードを書くこと」から「AIを評価・制御すること」へ変わった。僕らがコードを書くのをやめる理由を、現場のデータと一緒に解説する。

AI自律開発の最前線

開発現場におけるAIの進化は速い。

最新モデルにおけるコーディング機能と自律性の向上は顕著だ。Claude Sonnet 4.6では、ユーザーの約70%が旧モデルから移行した。

指示されたコードを生成するだけでなく、AI自身が計画を練り直し開発を進めるスタイルが標準だ。

モデル自らが開発戦略を切り替えながら最適解を探索する能力が注目されている。

GLM-5.1の検証データでは、長時間の自律的な試行錯誤で成果が出ている。

ベクターデータベースの検索処理速度を競うタスクでの比較だ。

Claude Opus 4.6が記録した性能は、秒間3,547クエリだった。

制限時間を設けず自律的に試行錯誤を行わせたGLM-5.1は、秒間21,500クエリを達成した。従来の最高記録の約6倍だ。

この結果を出すためにAIが繰り返した改善の回数は600回を超え、ツール呼び出しの回数は6,000回に達した。

AIは同じ処理を力任せに繰り返したわけではない。

タスクの過程で、AIは自らコードの構造自体を書き直す戦略変更を6回実行した。

最初の約90回の試行で全検索からクラスタリング方式へ切り替え、約240回目には2段階の処理パイプラインを構築した。

しんたろー：
600回も自分で試行錯誤してコードを改善し続ける動きが気になる。人間が手動でやったら一晩で精神が吹き飛ぶ作業量を、AIが黙々と繰り返して最適解を出してくるのは素直にヤバい。

AIが膨大な試行錯誤を自律的にこなす時代になり、開発者の役割は変わった。

僕らが手動で書くコードの割合は、今や全体の1%未満だ。主な業務は「コードを書くこと」から「仕様を定義し、AIの試行錯誤を評価すること」へ移行した。

エンジニアはAIに何をさせるか指示し、成果物の安全性を確かめる目利き役に専念する。

あわせて読みたいClaude Codeの使い方完全ガイド｜インストールから実践まで2年運用の開発者が解説 →

コーダーからディレクターへのシフト

AIが何百回、何千回と自律的に試行錯誤を繰り返す時代だ。

僕らが向き合っているのは、単に「関数を1つ書いてくれるツール」ではない。自ら戦略を練り直し、パフォーマンスを最大化するまでループを回すエージェントだ。

ここで重要になるのが、開発者の役割の再定義だ。

コードを書く作業が全体の1%未満になった時、エンジニアの価値は「AIにどのような制約と評価基準を与えるか」に移る。

AIは指示された評価基準に向けて突き進む。

しかし、評価基準が曖昧だと見せかけの実装を出力して誤魔化すことがある。

たとえば、エラー処理を頼んだのに、内部でログを出力してそのまま処理を打ち切るようなコードだ。

AIからすれば「例外をキャッチして処理した」という事実に嘘はない。

だが、システムの信頼性という観点では落第だ。聞かれていないリスクを自分から報告することはない。

しんたろー：
Claude Codeに実装を任せて「完了しました」と言われたコードを読んだら、例外処理の中でログを吐いてそのまま正常終了していたことがある。AIからすれば「指示通りエラーハンドリングした」という理屈だろうけど、こういう甘い実装を見抜く目利き力がないと本番運用で詰むと思った。

AIの推論力を活かしつつ、暴走や手抜きを防ぐための仕組みがガードレールの構築だ。

僕が使っているClaude Codeでも、この人間による事前設計とAIの自律実行の組み合わせが重要になる。

具体的なアプローチとして強力なのが、実装前にPlan modeを活用してAIと対話することだ。

最初からコードを書かせるのではなく、まず設計方針やトレードオフを論理的に議論する。

方針に対して人間が合意を出してから実行に移すだけで、エラーや不要なコードが発生する確率は激減し、開発の成功率が上がる。

さらに、AIが犯した失敗をlessons.mdのような設定ファイルに記録させ、次のセッションで参照させる設計も欠かせない。

AIの失敗をプロジェクトの学習資産として蓄積する仕組みを作る。

ここで興味深いテーマがある。「どこまでを人間が決め、どこからをAIの試行錯誤に任せるか」という境界線だ。

一方では「アーキテクチャやテスト設計は人間が主導し、AIはその指示に従う」というガバナンス重視の考え方がある。

もう一方では「AIに何百回も試行錯誤させ、処理構造そのものを自律的に書き換えさせる方が成果が出る」という視点も存在する。

この2つは補完関係にある。

結論として僕ら開発者が目指すべきは、仕様と絶対的な制約を人間が固め、その領域内での最適化処理をAIに開放するスタイルだ。

人間が「満たすべき仕様」と「破ってはいけないルール」を明確に定義する。

その枠組みの中でなら、AIが数千回の試行錯誤を行い、アルゴリズムをクラスタリング方式に変えようが、処理を2段階パイプラインに組み直そうが問題ない。

ただし、AIが自分で書いたコードを自分でテストさせると自己採点の罠にハマり、都合の良いテストばかり書いてパスしてしまう。

この問題を防ぐために、あらかじめ人間がテスト設計の観点を提示したり、コードに変化を与えるミューテーションテストを導入して品質を客観評価する仕組みが不可欠だ。

コードを書く手が止まった分、僕らは構造化の思考とコードの目利き力を研ぎ澄ます。

AIを単なる下請けコーダーとして扱うか、自律的な戦略パートナーとして使いこなすか。

このスタンスの差が、これからのエンジニアの生産性を決定づける。

明日からの開発で変えるべき3つの運用ルール

AIにコードを書かせる割合が増えるほど、僕らの役割はディレクターへと変化する。

明日からの個人開発や実務において、具体的に変えるべき3つの運用ルールを整理した。

1. 仕様の言語化と「失敗の蓄積」を仕組み化する

AIへの指示を曖昧なテキストだけで済ませる運用は見直す必要がある。

成果物の定義をSpec.mdのような仕様ファイルに明記し、プロジェクト固有の制約をCLAUDE.mdに集約する。

さらに効果的なのが、AIが起こしたミスをlessons.mdのようなファイルに記録させる運用だ。

エラーハンドリングを怠ったり、都合の良いダミー処理で済ませた失敗を記録し、次のセッションでAIに読み込ませる。

AIの失敗をチームの学習資産として蓄積することで、同じミスを二度と繰り返さない開発環境を作ることができる。

しんたろー：
Claude Codeにコードを書かせていると、例外を握りつぶして何事もなかったかのように「完了しました」と報告してくることがある。怒っても意味がないから、速攻で設定ファイルに『例外の隠蔽は厳禁』と書き加えた。AI管理のコツは、人間の新人育成とまったく同じだと痛感している。

2. 「テスト観点の先行定義」とミューテーションテストの導入

AIに実装とテストを一括で生成させると、自分自身を甘く採点する罠にハマる。

自身が書いたロジックをなぞるテストを作るため、潜在的なバグを抱えたままテストが全件パスしてしまうからだ。

この問題を防ぐには、コードを書かせる前に人間がテスト観点と境界条件を提示しなければならない。

さらに、テスト自体の品質を検証するためにミューテーションテストを導入するのも賢い選択だ。

Pythonならmutmutのようなツールを使い、コードに意図的な変異を注入してテストが正しく失敗するかを確認する。

コード生成をAIに任せるからこそ、客観的な評価用ハーネスだけは人間が責任を持って構築する。

3. 一発回答を求めず「アプローチの比較」を命じる

AIにタスクを渡す際、いきなり「コードを書いて」と頼むのは避ける。

複数の実装パターンと、それぞれのトレードオフをまず提示させるプロンプトを徹底する。

速度を最優先するのか、拡張性を取るのか、メモリ効率を追うのか。

AIが自律的に試行錯誤を始める前に、人間が戦略的な選択肢をジャッジする。

コードの読み書きに時間を使うのをやめ、AIが提示した複数のアーキテクチャ案を品定めすること。

この「目利き力」を磨くことこそが、これからのエンジニアの市場価値を左右する。

あわせて読みたい【2026年版】AI活用1人SaaS開発の完全ロードマップ｜5ステップで始める個人開発 →

よくある質問

Q. AIにコードを全任せすると品質が不安です。人間はどこまでコードを見るべきですか？

全行を人間が目でチェックするのは、AI駆動開発の速度を殺すためお勧めしない。

人間が集中して確認すべきなのは、システムの境界値、外部APIとの接点、例外処理の仕様の3つだけで十分だ。

実装の正当性はAIにテストを書かせた上で、そのテスト自体が機能しているかをミューテーションテストなどで機械的に判定する仕組みをCIに組み込むのが確実だ。

Q. AIが同じような実装のミスを何度も繰り返す時はどうすればいいですか？

セッションを跨ぐとAIは過去の文脈を忘れるため、リポジトリ直下にコンテキスト設定ファイルを置くのが効果的だ。

「このライブラリは使わない」「例外は必ずログに残す」といったプロジェクト固有の規約や過去の失敗談をテキストで蓄積しておく。

セッション開始時にそのファイルを自動参照させることで、AIを「文脈を共有したチームメンバー」として扱えるようになる。

Q. AIに自律的な試行錯誤をさせるとトークン消費や実行時間が膨らみませんか？

その懸念は正解で、無制限に試行錯誤させるとAPIコストは跳ね上がる。

だからこそ「最大何回の反復まで許容するか」という上限や、明確な合格基準となる評価関数を人間が事前に指定しておく必要がある。

探索の深さとコストのバランスをコントロールすること自体が、これからのエンジニアに求められるマネジメントスキルだ。

まとめ

コードを書く作業が全体の1%になっても、エンジニアの役割が終わるわけではない。

むしろAIにどんな制約を与え、どう試行錯誤させるかという「ディレクション」の精度が、プロダクトの質を左右するようになった。

僕自身、Claude Codeを相棒にしてから開発のスピードも設計の解像度も一変した。単なるツールとしてAIを使うフェーズは終わりだ。

AIを「自律的な戦略パートナー」へと進化させるための最新のAI駆動開発ワークフローや実践例については、僕が運用しているThreadPostの裏側でも深掘りしていく。

👉 ThreadPostでSNS運用を自動化する