「コードを書く力」だけでは戦えない時代が来た
GitHubの公開コミットのうち、約4%がClaude Codeによるものだという。1日あたり約13.5万件。2026年末には20%を超えるとの予測もある。
MIT Technology Reviewは2026年の10大ブレークスルー技術に「生成コーディング」を選出した。Microsoftではコードの30%がAI生成。Googleでも25%以上。コードを書くこと自体の希少価値が、急速に下がっている。
じゃあ何が価値になるのか。
僕はこう思う。「AIに正しく任せる力」だ。ゴールを明確にして、タスクを分解して、出力を検証する。この一連の設計力が、エンジニアの生産性を左右する時代になった。
「任せる技術」とは何か — 3つの要素
「AIに任せる」と聞くと、プロンプトを書くだけに聞こえるかもしれない。でも実際はもっと奥が深い。僕が日々の開発で実感している「任せる技術」は、3つの要素に分解できる。
ゴール設計: 何を達成したいかを言語化する
最初にして最大のポイントがこれだ。「何を作りたいか」を言語化すること。
当たり前に聞こえるけど、意外とできていない人が多い。「いい感じにして」「バグを直して」みたいな曖昧な指示を投げて、期待と違う結果が返ってくる。それはAIの問題じゃなく、指示の問題なんだよね。
僕がいつも意識しているのは「人に説明できないことはAIにも伝わらない」ということ。2026年のプロンプトエンジニアリングでも、成功基準と出力契約を定義することが最重要とされている。
具体的には、AIに渡す前にこの3つを決めている。
- 最終的なアウトプットの形（ファイル? 関数? API?）
- 成功と判断する条件（テストが通る? 表示が正しい?）
- やらなくていいこと（スコープ外の明示）
ゴールが曖昧なら、いきなり実装に入らない。まずAIと壁打ちして整理する。「こういう機能を作りたいんだけど、どういうアプローチがある?」と聞くだけで、頭の中が整理されることは多い。
タスク分解: 大きな仕事を小さく切る
ゴールが決まったら、次はタスクの分解。
AIに一発で大きな仕事を任せると、だいたい失敗する。コンテキストが広すぎると精度が落ちるからだ。一つのプロンプトに詰め込むほど、出力のブレが大きくなる。
トランスコスモスの事例がわかりやすい。従来15.5人日の見積もりを、1.5人日で完了させた。87%の工数削減だ。手法は「1人のエンジニアが複数のAIに並行で指示を出し、コンポーネントごとに作業を割り振る」というもの。
ポイントは「並行」と「分割」の組み合わせ。大きなシステムをいきなり作らせず、部品ごとに切って別々の指示として投げる。
僕の場合はこんな感じで分解している。
- フロントとバックエンドを分けて指示する
- 「まずデータ構造を設計して」→「次にAPIを実装して」と段階的に進める
- 1回の指示で触るファイルは3つ以下に絞る
これだけで出力の安定感がまるで違う。
品質ゲート: 出力を検証する仕組み
任せた仕事は、必ず検証する。これが3つ目の要素。
2026年に入って「ハーネスエンジニアリング」という概念が注目されている。HashiCorp共同創業者のMitchell HashimotoやOpenAIが提唱した考え方だ。AIエージェントの行動を「制約・情報提供・検証・修正」するシステムを設計する。
馬の手綱（ハーネス）が語源。「AIという馬をどう操るか」の設計イメージだ。同じAIを使っても、ハーネス設計の質で出力品質が劇的に変わる。
品質ゲートの具体例はこんな感じ。
- AIが書いたコードに対してテストを走らせる
- 型チェックやリンターを通す
- 「このコードをレビューして」と別のプロンプトで検証させる
最後のポイントが特に大事。AIの出力をAIにレビューさせる二重チェック。書く役と読む役を分けることで、単体では見逃すミスを拾える。
僕がClaude Code一本に絞った理由
ここまでの話は一般論に聞こえるかもしれない。でも僕自身、この「任せる技術」の重要性に気づくまで結構な回り道をした。
最初はClineを使っていた。次にCursor、その後Windsurf。AIコーディングツールを渡り歩いて、最終的にClaude Codeに一本化した。
なぜかというと、ツールの数を増やすより「1つのツールへの任せ方を磨く方が生産性が高い」と気づいたからだ。複数ツールを使い分けていた頃は、それぞれの癖を覚えるだけで時間が溶けていた。
Claude Codeに絞ってからは「まずClaude Codeにやらせてみよう」が口癖になった。新機能の実装、バグ調査、リファクタリング。まずAIに投げて、その出力を起点に考える。
36歳で未経験からエンジニアに転職した身としては、正直怖さもある。非エンジニアがAIでコードを書ける時代になったとき、僕の価値は何だろうと考えることもある。
でも、その怖さへの対処として選んだのは「守り」ではなく「攻め」だった。AIを使いこなせるなら、逆に他部署の領域にも踏み込める。マーケの分析ツールや営業用ダッシュボードを作ったり。AIに任せる技術があれば、エンジニアの守備範囲は広がる。
副業でプログラミング講師をしていても感じる。今の受講生に必要なのは「写経力」じゃなく「設計力」だと思う。コードの書き方より、何を作りたいかを言語化する力。それがあればAIが実装を助けてくれる。
それでもAIに丸投げしてはいけない理由
ここで大事なバランスの話をしたい。「AIに任せる」と「AIに丸投げする」はまったく別物だ。
Gartnerは、2026年末までに世界の組織の50%が「AIを使わない」スキル評価を導入すると予測している。AIへの依存が批判的思考力の衰えを招くリスクがあるからだ。
これは実感としてもわかる。AIの出力をそのまま採用し続けると、自分で考える機会が減る。基礎力がないとAIの出力が正しいかどうかを判断できない。「動いてるからOK」は危険なんだよね。
プロンプトエンジニアリングの世界でも「最悪の5%の出力が、運用上の問題の80%を引き起こす」と言われている。平均的な品質を上げるより、致命的な失敗を防ぐことの方が重要だ。
だからこそ品質ゲートが必要になる。任せた結果を検証できるだけの基礎力を、自分自身が持っていないといけない。
最近、技術の勉強が十分にできていない自覚があって、社内で輪読会を始めた。AIに任せる時間が増えた分、基礎を学び直す時間も意識的に確保しないとまずいかもしれない。。
「任せる技術」は、基礎力の上に成り立つものだと思う。
今日から始められる「任せる技術」3ステップ
最後に、今日から実践できる具体的なステップをまとめる。
ステップ1: ゴールを一文で書いてからAIに渡す
AIにタスクを投げる前に「今回のゴールは〇〇」と一文で書く。それだけでいい。一文で書けないなら、ゴールが曖昧な証拠。まずAIと壁打ちして整理してみて。
ステップ2: 大きなタスクは3つ以下に分割して指示する
「全部一気にやって」は禁句。最大でも3つの小タスクに分割して、順番に指示を出す。分割の基準は「1つの指示で触るファイルが3つ以下になるか」。超えたらもう一段分解する。
ステップ3: 出力を毎回レビューして修正パターンを記録する
AIが間違えやすいポイントはパターン化できる。「この種のタスクではこういうミスが出やすい」という知見を貯めていくことが大事。それがハーネスの改善につながる。次に同じ種類のタスクを任せるとき、事前に注意点を指示に含められる。
コードを書く力が不要になるわけじゃない。でも、それだけでは足りない時代になった。AIに正しく任せる力 — ゴール設計、タスク分解、品質ゲート。この3つを磨くことが、エンジニアとしての生産性を引き上げてくれると思う。
