［開発者向け］AI時代の開発者が伸ばしたい3つのスキル——指示する力・疑う力・判断する力

2026-10-03

はじめに

　GitHubは2026年10月2日、公式ブログで、AIによって変わりつつある開発者の仕事に備えるための3つのスキルを紹介しました。AIエージェントへの指示の出し方、AIの出力の見直し方、そして技術的な判断を仕事の中心に置き続ける方法です。本稿では、各スキルの内容を具体例とともに整理します。

参考記事

タイトル: AI is changing developer work. Here are three skills to strengthen.
著者: Gwen Davis
発行元: GitHub Blog
発行日: 2026年10月2日
URL: https://github.blog/ai-and-ml/ai-is-rewriting-the-developer-career-ladder-heres-how-to-stand-out/

要点

GitHubは、コードを書くことに加えて、AIへの指示、出力の評価、トレードオフの説明、技術的判断の力が開発者にますます求められるとしている
1つ目のスキルは、AIを単に使うのではなく、問題の定義や文脈の提供を通じてAIエージェントを指揮することである
2つ目のスキルは、AIの最初の答えをうのみにせず、別のAIモデルに批評させたうえで自分の判断で評価することである
3つ目のスキルは、AIで浮いた実装の時間を、顧客の課題の理解や設計、判断といったより大きな問題に使うことである

詳細解説

開発者の仕事はどう変わっているか

　GitHubによれば、AIは開発者の働き方とスキルの生かし方を変えつつあります。コードを書くことは依然として欠かせませんが、開発者には次の力がますます求められるようになっています。

AIに指示を出す力
AIの出力を評価する力
トレードオフ（あちらを立てればこちらが立たない関係）を説明する力
適切な技術的判断を下す力

　記事は、今日から準備を始められるとして、3つの重点を挙げています。

　著者のGwen Davis氏はGitHubのシニアコンテンツストラテジストで、開発者体験やAIを活用したワークフロー、技術者のキャリア形成について執筆しています。記事は3分ほどで読める短い内容ですが、各スキルを簡単な図式で示している点が特徴です。

スキル1：AIを「使う」から「指揮する」へ

　1つ目は、AIを単に使うのではなく、指揮することを学ぶことです。記事によれば、AIは「実行」の形を変えつつあります。優れた実行とは、問題を明確に定義し、適切な文脈を与え、AIが生成したコードを評価し、何が出荷できる状態かを判断することだという意味合いが強まっています。AIエージェントが実装の多くを担うほど、こうしたスキルの価値は高まるとしています。

　記事は、新しい認証フローを追加する場合を例に挙げています。従来のワークフローは次のような流れです。

タスク: 認証機能を追加する

→ ブランチを作成する
→ コードを書く
→ テストを実行する
→ プルリクエストを作成する

　AIツールがより高性能になり、日々の作業に深く組み込まれていくと、同じスキルが複数のAIエージェントの調整に役立つようになります。その場合のワークフローは次のように変わります。

ワークスペース: 認証機能を追加する

エージェント1 ✓ 認証機能がレビュー可能な状態
エージェント2 ✓ ドキュメントの草案が完成
エージェント3 ✓ テストスイートが完成

　記事は、成果に責任を持つのは変わらず開発者自身だと強調しています。変わったのは、すべての部分を自分で実装する時間が減り、代わりに作業を定義し、出力をレビューし、全体をまとめる技術的判断を下すことに時間を使うようになる点です。記事はここから、AIエージェントを指揮することを学ぼう、という教訓を導いています。

　こうした複数エージェントを1つの画面で扱う作業環境として、GitHubは6月に「エージェントネイティブ」な開発環境のGitHub Copilot appを公開しており、記事もその入門ガイドへの導線を設けています。本稿としては、ここで求められている「問題の定義」と「文脈の提供」は、チームで後輩に仕事を任せるときに求められる力とよく似ており、マネジメントの基礎として以前から重視されてきたものと重なると考えています。

スキル2：AIの最初の答えを信用しない

　2つ目は、AIの最初の答えを信用しないことです。AIは数秒で見事な解決策を生成できますが、最初の答えが常に最善とは限りません。記事は、きれいで保守しやすいコードを書いてきた経験が、AIの出力を評価する際に役立つとしています。

　具体的な方法として、2つ目のAIモデルに1つ目のモデルの作業を批評させ、そのうえで両方の回答を自分の判断で評価することを勧めています。記事が示す例は次のとおりです。

「各顧客の最新の注文を返すSQLクエリを書いてください」
↓
AIモデル1
✓ クエリを生成する
↓
AIモデル2（批評役）
⚠ 同じタイムスタンプが重複する場合を扱っていない
⚠ インデックスの推奨がない
⚠ 大きなテーブルでは性能が落ちる可能性がある

　1つ目の指摘は、ある顧客の注文が同じ日時に2件以上ある場合に、「最新の注文」が1件に定まらず、結果が重複したり不定になったりする問題を指していると読めます。2つ目と3つ目は、データ量が増えたときの処理速度に関わる指摘です。参考までに、筆者が補足したサンプルを示します。以下は記事に掲載されたものではなく、動作も環境によって異なるため、考え方の例として見てください。

-- 筆者による補足サンプル(記事には掲載されていません)
-- 顧客ごとに注文日時の新しい順に番号を振り、1番目だけを取り出す
-- 同じ日時の注文がある場合は、注文IDの大きい方を優先して1件に絞る
SELECT customer_id, order_id, ordered_at
FROM (
  SELECT
    customer_id,
    order_id,
    ordered_at,
    ROW_NUMBER() OVER (
      PARTITION BY customer_id
      ORDER BY ordered_at DESC, order_id DESC
    ) AS rn
  FROM orders
) AS ranked
WHERE rn = 1;

-- 大きなテーブルでの検索を速くするため、顧客IDと注文日時に索引を作る例
CREATE INDEX idx_orders_customer_ordered_at
  ON orders (customer_id, ordered_at DESC);

　ROW_NUMBER() はウィンドウ関数（行のまとまりごとに順位などを計算する関数）の1つで、PARTITION BY で顧客ごとに区切り、ORDER BY で並べた順に番号を振ります。並べ替えの条件に注文IDを加えることで、日時が同じ場合でも結果を1件に定められます。

　記事によれば、AIモデルにはそれぞれ得意な分野と見落としやすい点があります。そのため、GitHub Copilotに組み込まれた「Rubber Duck」エージェントは、開発者が次に進む前に、2つ目のモデルを使って計画、コード、テストを批評します。別の視点を入れることで、最初のモデルが見落とした問題に気づけることが多いとしています。

　Rubber Duckについては、異なるモデルが計画をレビューする機能としてCopilot CLIに導入された際にも話題になりました。名前の由来は、ゴム製のアヒルに向かってコードを説明するうちに自分で誤りに気づくという、プログラマーの間で知られる「ラバーダック・デバッグ」です。記事の教訓は、AIを使うには十分信頼しつつも、レビューを省くほどには信頼しない、という一文にまとめられています。本稿としては、批評役のAIの指摘もまた誤りうるため、最後に判断する人間の基礎知識がこれまで以上に問われるという点が、このスキルの核心だと受け止めています。

スキル3：AIでより大きな問題に取り組む

　3つ目は、AIを使ってより大きな問題を解決することです。AIが実装の時間を節約してくれれば、開発者はその時間を、顧客のニーズの理解、トレードオフの評価、より良いシステムの設計、そしてAIが代わりに下すことのできない技術的判断といった、より広い問題に使えるとしています。

　記事は、ダークモードを追加するという課題を例に、AIと開発者の分担を次のように示しています。

Issue #4821
タイトル: ダークモードを追加する

AI
✓ 実装を作る
✓ テストを生成する
✓ ドキュメントを更新する

開発者のチェックリスト
☐ 顧客の課題が本当にあるかを確かめる
☐ 設計上のトレードオフを見直す
☐ アクセシビリティを確認する
☐ 成功の指標を定める
☐ 解決策を承認する

　AIが実装の仕事を多く担うほど、優れたエンジニアを際立たせるスキル、つまり適切な判断、トレードオフのバランス、正しい問題を解くことがさらに重要になると記事は述べています。教訓は、実装の多くをAIに任せ、チームがより良い判断を下すのに役立つ判断力を磨く時間を増やそう、と記事はまとめています。

　チェックリストに「アクセシビリティ（高齢者や障害のある人を含め、誰もが使いやすいかどうか）の確認」が入っている点は、AIが作った画面が見た目は整っていても、色のコントラストやキーボード操作などで配慮が抜けることがあるという実務上の課題を踏まえたものと考えられます。「顧客の課題が本当にあるか」を最初に置いていることも、作れるものが増えたからこそ、何を作るべきかを見極める力が問われるという流れと一致していると思います。

3つのスキルに共通すること

　記事は結びで、開発者のワークフローが変化するなかで、AIと効果的に働く方法を学び、自分自身の技術的判断を強めることが、変化への適応に役立つとしています。

　3つのスキルを並べると、「何をさせるかを決める」「出てきたものを確かめる」「その先の判断を担う」という、仕事の前後を人が押さえる構造になっていることが分かります。本稿としては、これは開発者に限らず、AIを業務に取り入れるあらゆる職種に当てはまる考え方だと受け止めています。一方で、レビューや判断の力は、自分で手を動かしてコードを書く経験から育つ面も大きいため、これから学ぶ人がその経験をどう積むかは、教育の側でも考えていくべき課題だと思います。