Skip to content
Published on

30倍AIエンジニアの条件はスピードではなくセンスである

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — なぜ今この記事が話題なのか

2026年上半期、開発者コミュニティで最も多く言及された記事の一つが、Substackに投稿された「How to be a 30x AI engineer with taste」です。Hacker Newsのフロントページに上がり、韓国のテックアグリゲーターGeekNewsでも活発な議論が交わされました。

この記事が特に話題になった背景には、タイミングの絶妙さがあります。2026年現在、Claude Code、Codex、CopilotのようなAIコーディングエージェントはもはや珍しいツールではなく、普遍的な作業環境になりました。数時間にわたり自律的に作業を遂行するフロンティアモデル世代が登場し、OpenAIのモデルとCodexはAWSでも提供され、MicrosoftはMAI-Code-1のようなコーディング特化モデルで競争に参入しています。

コードを生産するスピードそのものは、今や誰にとってもほぼ無料です。それなのに、あるエンジニアはAIツールでチーム全体の成果を引き上げ、別のエンジニアは同じツールで技術的負債を量産します。この差を生むものは何かという問いに、原文の著者は一言で答えます。センス(taste)です。

この記事では原文の論旨を整理し、センスというやや曖昧な言葉を、具体的なスキルとトレーニング法に分解してみます。

核心の主張 — 10xから30xへ、そして数字の罠

まず原文の核心的な主張を要約すると、次のようになります。

  1. AIはコード生産(production)をコモディティ化した。コードを速く書く能力の希少性は急激に下がっている。
  2. ボトルネックは生産から評価(evaluation)へ移動した。何を作るか、作られたものが良いか悪いかを判断する能力が、新しい希少資源である。
  3. この評価能力の総体こそがセンスであり、センスのあるエンジニアとないエンジニアの格差は、ツールが強力になるほどむしろ広がる。
  4. したがって30xという数字はタイピング速度30倍ではなく、良い判断の積み重ねが生み出す成果物の価値の差を意味する。

10xエンジニア論が一人のコーディング生産性についての話だったとすれば、30x論はレバレッジについての話です。AIエージェントという巨大なてこが与えられたとき、支点をどこに置くべきか知っている人と知らない人の差は、てこが長くなるほど大きくなります。

  かつて: 生産がボトルネック            現在: 評価がボトルネック

  アイデア ──> [コーディング: 遅い] ──> 結果   アイデア ──> [コーディング: AI, 速い] ──> 結果
                  ^                                          ^
              ここが高コストだった                    ここはもう安い
                                                             |
                                            [何を作るか / これは良いかの判断]
                                                             ^
                                                    ここが新しいボトルネック

もちろん、30xという数字自体をあまり真剣に受け取る必要はありません。測定された値ではなく、修辞的な装置に近いものです。この点は最後の批判セクションで改めて扱います。

コードがコモディティになるとき — 何が高価になるのか

経済学には古くからのパターンがあります。ある財がコモディティ化すると、その財を補完するものの価値が上がるというものです。写真撮影が無料になると何を撮るかを知る目が高価になり、執筆ツールがありふれたものになると何を書くかを知る編集者的感覚が高価になりました。

コードも同じ道を歩んでいます。2026年の開発現場で実際に高価になったものを並べてみると、次のとおりです。

コモディティ化したもの価値が上がったもの
ボイラープレートの作成システム境界の設計
API連携コードそもそもどのAPIを使うかの判断
テストコードの生成何をテストすべきかを知ること
リファクタリングの実行リファクタリングする価値があるかの判断
ドキュメント草稿の作成読者に本当に必要な情報の選別
プロトタイプの実装プロトタイプで検証する仮説の設計

左の列はAIエージェントに委任できる仕事で、右の列は委任すると事故が起きる仕事です。右の列の共通点こそが評価と判断、すなわちセンスの領域です。

ここで重要なニュアンスがあります。左の列ができなくてもよいという意味ではありません。左を自分の手でやった経験がなければ、右の判断の根拠が消えてしまいます。コモディティ化はその仕事ができることの価値をなくすのではなく、その仕事を手作業でやる時間の価値をなくすのです。

センスの解剖 — 三つの構成要素

センスという言葉は格好良いですが曖昧です。実務的に分解すると、少なくとも三つの能力の合成です。

1. プロダクト感覚 (Product Sense)

何を作ればユーザーとビジネスに価値が生まれるかについての直観です。具体的には、次の質問に速く正確に答える能力です。

  • この機能を作ったら、誰が、いつ、なぜ使うのか
  • この問題をコードなしで解決する方法はないか
  • 80パーセントの価値を生む20パーセントの範囲はどこか
  • 今作らなければ何が起きるか(何も起きないなら、作らない)

AIエージェントは指示されたものを作るだけで、指示する価値があるかは問いません。プロダクト感覚のない人が強力なエージェントを握ると、作る必要のなかったものが、ものすごいスピードで作られていきます。

2. コード品質の直観 (Quality Intuition)

生成されたコードを見て、数秒以内に違和感を察知する能力です。AIが作ったコードは概してもっともらしく見えるため、表面的なもっともらしさを突き破って見る直観が必要です。例えば次のコードを見たときを考えてみましょう。

def get_user_orders(user_id: int) -> list[dict]:
    orders = []
    all_orders = db.query("SELECT * FROM orders")  # テーブル全体をロード
    for order in all_orders:
        if order["user_id"] == user_id:            # アプリ側でフィルタリング
            user = db.query(
                f"SELECT * FROM users WHERE id = {order['user_id']}"
            )                                       # ループ内クエリ + インジェクション
            order["user_name"] = user[0]["name"]
            orders.append(order)
    return orders

このコードは動きます。テストも通るかもしれません。しかし熟練した目には三つの問題が即座に見えます。テーブル全体のスキャン、ループ内部のN+1クエリ、そして文字列フォーマットによるSQLインジェクションの可能性です。センスのあるレビュアーなら、次のようなコードを期待していたはずです。

def get_user_orders(user_id: int) -> list[dict]:
    return db.query(
        """
        SELECT o.*, u.name AS user_name
        FROM orders o
        JOIN users u ON u.id = o.user_id
        WHERE o.user_id = %s
        """,
        (user_id,),
    )

品質の直観は、動くかどうかではなくコスト構造を見ます。このコードはデータ100万件でどうなるか、同時リクエスト1000件でどうなるか、半年後にこのコードを直す人は何につまずくか、を問うのです。

3. トレードオフ判断 (Tradeoff Judgment)

すべてのエンジニアリング上の決定はトレードオフです。センスの三つ目の要素は、今この状況でどのトレードオフが正しいかを知る能力です。

  • このプロトタイプにテストをどれだけ書くべきか(答え: ほとんど書かなくてよい)
  • この決済モジュールにテストをどれだけ書くべきか(答え: 執拗に)
  • 抽象化を今導入するか、三回目の重複が出るまで待つか
  • ライブラリを使うか、200行の自前実装で依存を避けるか

AIはベストプラクティスの平均値を出力する傾向があります。しかしベストプラクティスは文脈の上でのみベストです。文脈を握っているのは常に人間の側です。

センスを鍛える具体的なトレーニング法

センスは生まれつきのものではなく、意図的な接触と反復的な評価によって育つものです。原文の提案を拡張し、四つのトレーニングルーチンに整理しました。

トレーニング1 — 良いコードを精読する

良い文章を多く読んだ人が良い文を見分けるように、良いコードを多く読んだ人が良いコードを見分けます。お勧めの方法は次のとおりです。

  • よく作られたオープンソースを一つ決めて、コアモジュールを最初から最後まで読みます。SQLite、Redis、Flask、Tailwind CSSのコードベースがよく推薦されます。
  • 読みながら、なぜこうしたのだろうとメモします。奇妙に見える決定ほど、理由がある確率が高いものです。
  • 同じ問題を解く二つのライブラリのソースを比較します。例えばrequestsとhttpxのコネクション処理方式の比較は、優れた教材です。

週2時間で十分です。重要なのは量ではなく、なぜという問いの密度です。

トレーニング2 — レビューを評価訓練にする

コードレビューは評価能力を鍛える最良の反復訓練です。ただし、なんとなくやるレビューではなく、構造化されたレビューでなければなりません。次のチェックリストをお勧めします。

レビューチェックリスト(優先順位順)
1. この変更は解こうとしている問題を実際に解いているか?(プロダクト感覚)
2. もっと小さく解けなかったか? 削除したコードはあるか?
3. 失敗経路: このコードはどうやって死ぬか? 死んだとき何が起きるか?
4. データ10倍、トラフィック10倍で何が壊れるか?
5. 半年後の同僚はこのコードの何に驚くか?
6. スタイル/ネーミング(最後に。ツールに任せられるなら任せる)

AIが生成したPRをレビューするときは、一つ追加します。このコードがもっともらしく見える理由と、実際に正しい理由を区別して書いてみることです。この区別の訓練が、AI時代のレビューの核心的な筋肉です。

トレーニング3 — ポストモーテムを教材にする

障害のポストモーテムは、トレードオフ判断を鍛える圧縮された教材です。誤った判断の結果を最も生々しく見せてくれるからです。

  • 自社のポストモーテムを読むときは、どの時点のどの決定がこの障害の種だったのかを追跡します。
  • 公開ポストモーテム集(GitHubのdanluu/post-mortemsリポジトリが有名です)から毎週一編を読み、自分がその場にいたら同じ決定をしただろうかと自問します。
  • 障害でなくても構いません。中止されたプロジェクト、作り直したアーキテクチャも同じ価値を持ちます。

トレーニング4 — デモとプロダクトをたくさん見る

プロダクト感覚は、良いプロダクトと悪いプロダクトを大量に観察することで育ちます。

  • 毎週、新規プロダクトのデモをいくつか見ます。ハッカソンのデモ、ショーケース動画、Product Huntのローンチが良いソースです。
  • 見るたびに三つを評価します。どんな問題を解くのか、なぜ今なのか、自分が作るなら何を削るか。
  • 特に最後の質問が重要です。センスの半分は削る能力です。

スペック作成が新しいコーディングである

AIエージェント時代の実質的なプログラミングインターフェースは、自然言語のスペックです。2026年に入り、CLAUDE.mdやAGENTS.mdを作成してエージェントにコンテキストを供給することが新しい慣行として定着し、プロンプトエンジニアリングという言葉はコンテキストエンジニアリングやループエンジニアリングという言葉に置き換えられつつあります。

悪いスペックと良いスペックの違いを見てみましょう。

悪いスペック:
「注文キャンセル機能を作って」

良いスペック:
## 目標
ユーザーは配送開始前に注文をキャンセルできる。

## 範囲
- 含む: 単件キャンセル、全額返金、キャンセル理由の収集(任意)
- 含まない: 部分キャンセル、交換、配送中キャンセル(来四半期)

## 不変条件
- 返金は冪等でなければならない。同じキャンセル要求が二度来ても返金は一度。
- 注文状態の遷移は PAID から CANCELLED へのみ許可。SHIPPED 以降は不可。
- キャンセルと返金は一つのトランザクション境界ではない。返金失敗時は
  注文を CANCEL_PENDING 状態にして再試行キューに入れる。

## 完了基準
- 同時キャンセル要求テストが通る
- 返金APIタイムアウトシナリオのテストが通る
- 既存の注文照会APIのレスポンススキーマに変更なし

良いスペックの特徴を見ると、コード一行もないのに、システムの難しい決定がすべて入っています。冪等性、状態遷移ルール、トランザクション境界、失敗時の挙動。これらこそAIに委任できない判断であり、スペック作成が新しいコーディングだと言われる理由です。

スペックをうまく書く能力は、すなわち問題を正確に理解する能力なので、センスのトレーニングと同じ根を共有しています。

評価(evals)を書く能力

スペックが入力側の判断だとすれば、evalsは出力側の判断をコードに固定する技術です。AIの成果物を毎回目視で検査する代わりに、良さの基準を実行可能な形で書いておくのです。

最も単純な形は、なじみのあるテストと変わりません。

# AIが生成したSQLマイグレーションを検証する簡単なeval
def eval_migration(migration_sql: str) -> list[str]:
    violations = []
    lowered = migration_sql.lower()

    if "drop table" in lowered or "drop column" in lowered:
        violations.append("破壊的変更を含む - 手動承認が必要")
    if "alter table" in lowered and "concurrently" not in lowered:
        if "create index" in lowered:
            violations.append("インデックス作成時にCONCURRENTLY欠落 - ロックリスク")
    if "not null" in lowered and "default" not in lowered:
        violations.append("デフォルトなしのNOT NULL追加 - 既存行で失敗の可能性")

    return violations

LLMの出力そのものを採点するevalは、通常、採点基準(ルーブリック)と採点器を分離します。

RUBRIC = """
生成されたAPIエラーメッセージを1-5点で採点せよ。
5点: 原因、解決方法、ドキュメントリンクがすべてあり、内部情報の漏洩なし
3点: 原因はあるが解決方法が曖昧
1点: スタックトレースの漏洩、または意味のないメッセージ
"""

def eval_error_messages(samples: list[str]) -> float:
    scores = [grade_with_llm(RUBRIC, s) for s in samples]
    return sum(scores) / len(scores)

ここで興味深い循環が生まれます。採点基準を書くには、良いエラーメッセージとは何かについての見解が必要です。つまりevalsを書く能力はセンスを明文化する能力であり、センスがなければevalsも書けません。原文が評価能力を新しいコア・コンピテンシーに挙げる理由がここにあります。

ジュニア開発者へ — 基礎力とツール活用のバランス

この議論で最も難しい位置にいるのはジュニアです。センスは経験から生まれるのに、経験を積む機会だった単純作業をAIが持っていっているからです。

私の考えるバランスポイントは次のとおりです。

時期AIに任せるもの自分でやるもの
1-2年目環境構築、繰り返しのボイラープレートデバッグの全過程、コードの精読、小さな機能を最初から最後まで
3-5年目草稿生成、テストのスキャフォールディング設計の決定、レビュー、障害対応の主導
6年目以降実装の大部分スペック、アーキテクチャ、evals、メンタリング

ジュニア時代に特にお勧めする原則が二つあります。

  1. デバッグだけは自分でやります。デバッグはシステムの実際の挙動を学ぶ、ほぼ唯一の強制装置です。AIに直してもらう前に、最低限、仮説を立てて検証する過程までは自分でやります。
  2. AIの成果物を読まずにマージしません。一行一行説明できるときだけマージします。説明できないコードをマージする習慣は、センスが育つ土壌そのものをなくします。

基礎力を飛ばしてツール活用だけを学んだジュニアは、ツールが間違ったとき、間違っているという事実すら分からなくなります。逆にツールを拒否するジュニアは、ツールを前提に再編されたチームのワークフローから孤立します。どちらも避けるべきです。

アンチパターン — こうなってはいけない

アンチパターン1: ツールコレクター

新しいAIツールが出るたびに乗り換え、ツールの比較には詳しいのに、肝心の深みのある成果物がないタイプです。ツールの切り替えコストは思ったより大きく、センスは一つのツールを深く使い、限界まで追い込むときに育ちます。ツールの変更は四半期に一度、意識的に評価して決める程度で十分です。

アンチパターン2: 無批判な受容者

AIが出した最初の答えをそのまま使うタイプです。短期的には速いですが、二つの複利コストが積み上がります。第一に、コードベースに平均的なコードが蓄積し、システムの一貫性が崩れます。第二に、本人の評価筋力が退化します。AIの出力に対して最低一度は、他の方法はなかったかと問う習慣が防衛線です。

アンチパターン3: センスの誇示者

すべてのPRに主観的なスタイル指摘を浴びせ、センスを権力として使うタイプです。本物のセンスは、重要なものと重要でないものを区別するところに表れます。ネーミング論争に30分を使いながらトランザクション境界の問題を見逃すレビューは、センスではなくノイズです。

批判的視点 — センス論の限界

この記事の論旨に共感するとしても、いくつかの限界は指摘しておくのが公正です。

第一に、測定不可能性です。センスは定義上、定量化が困難です。測定できない能力がコア・コンピテンシーだという主張は反証も不可能であり、採用や評価において、もっともらしい人がセンスのある人にすり替わる経路になり得ます。

第二に、生存者バイアスです。センスで成功したという物語は、大部分が事後解釈です。同じセンスで失敗した人々は記事を書きません。

第三に、30xという数字のマーケティング性です。10x論がそうだったように、30xも測定値ではなく注目を集めるための修辞です。HNのコメント欄でも、この数字への冷笑が最も多くの賛同を得ていました。数字は捨てて方向だけを取るのが健全な読み方です。

第四に、センスにも賞味期限があります。評価能力もまた学習可能なパターンであるなら、長期的にはAIが評価まで上手になる可能性を排除できません。実際、evalsの自動生成研究は急速に進んでいます。センスが永遠の堀である保証はどこにもありません。

それでもなお、少なくとも現時点で評価能力が生産能力より希少になったという観察自体は、現場の感覚と一致します。限界を認識した上で、方向を取ればよいのです。

ケーススタディ — 同じツール、異なる結果

抽象的な話を具体化するため、同じ課題を与えられた二人の仮想エンジニアを比較してみましょう。課題は社内管理画面へのCSVエクスポート機能の追加です。二人とも同一のAIコーディングエージェントを使います。

エンジニアA(スピード重視)            エンジニアB(センス重視)

09:00 エージェントに「CSVエクス      09:00 要件確認: 誰が使う?
      ポート作って」と指示                 -> 精算チーム、月1回、最大50万行
09:20 生成コードを確認、動く         09:20 判断: 50万行なら同期レスポンス不可
09:30 マージ、完了報告                     ストリーミングか非同期ジョブが必要
                                     09:40 1ページのスペックを作成
  -- 2週間後 --                            (エンコーディング、区切り文字、
                                            個人情報カラムのマスキング、
精算チームが45万行のエクスポート            タイムアウトポリシーを含む)
を実行                               10:00 エージェントにスペックを渡し実装委任
-> リクエストタイムアウト、          10:40 生成コードをレビュー: ストリーミング
   メモリスパイク                           確認、マスキング漏れ発見 -> 修正指示
-> 障害チケット、ホットフィックス、  11:30 マージ、完了
   信頼の低下
                                     総所要: 2時間30分、障害ゼロ
総所要: 30分 + 障害対応2日

エンジニアAが怠けていたわけではありません。Aはツールを速く使い、成果物はデモ環境で完璧に動きました。差はただ一つ、誰がどんなデータで使うのかという質問を先に投げたかどうかです。それがプロダクト感覚であり、50万行と聞いて同期レスポンスは無理だと判断したのが品質の直観であり、完璧な非同期パイプラインの代わりにストリーミングで十分だと線を引いたのがトレードオフ判断です。

注目すべきは、Bの優位がコーディング能力から来ていないことです。コーディングは二人ともエージェントがやりました。格差はすべてコードの外側で作られたのです。

チームにセンスを移植する — 個人技をシステムへ

センスが個人の頭の中にしかなければ、その人が休暇に入った瞬間、チームの品質が落ちます。シニアの役割は、自分のセンスをチームのシステムへ移すことです。2026年現在、効果が検証されている方法は三つあります。

第一に、エージェントのコンテキストファイルにセンスをエンコードします。CLAUDE.mdやAGENTS.mdは単なる設定ファイルではなく、チームのセンスをモデルに注入する経路です。

# CLAUDE.md の例(チームのセンスの明文化)

## 我々のコードルール
- 新しい抽象化は同一パターンが3回繰り返された後にのみ導入する
- すべての外部API呼び出しにはタイムアウトと再試行ポリシーを明示する
- エラーメッセージには原因と次の行動を必ず含める
- マイグレーションの破壊的変更は別PRに分離する

## やらないこと
- 呼び出し箇所が一つしかないユーティリティ関数を作る
- テストのためのテスト(カバレッジの数字目的の無意味なテスト)
- コメントでコードを説明する(コードを読みやすく直すこと)

第二に、レビューコメントを再利用可能な形で蓄積します。同じ指摘を三回したなら、それはlintルール、eval、あるいはコンテキストファイルの一行になるべきです。指摘の自動化率こそがシニアのレバレッジです。

第三に、決定記録(ADR)を軽量に運用します。何を作らないと決めた理由、技術選定で棄却した代替案を、5行でもいいから残します。センスの半分は棄却の記録だからです。

12週間のセンス・トレーニングカリキュラム

トレーニング法を時間割にまとめると次のとおりです。週あたりの投資時間は3時間以内に設計しました。

週集中領域具体的な活動
1-2週品質の直観オープンソースのコアモジュール精読、設計判断のメモ10個
3-4週評価訓練チェックリストに基づくレビュー4件、もっともらしさと正しさの区別メモ
5-6週失敗からの学習公開ポストモーテム4編の分析、決定の分岐点の追跡
7-8週プロダクト感覚デモ12本の視聴、何を削るかのメモ
9-10週スペック作成実務2件をスペック先行で作成しエージェントに委任
11-12週evals繰り返し作業2つのevalスクリプト作成、チームに共有

12週後は1週目に戻るのではなく、各領域で最も効果の大きかった活動だけを残し、個人のルーチンに圧縮します。重要なのは、すべての活動に成果物(メモ、スクリプト、スペック)があるという点です。成果物のないトレーニングは、測定も振り返りも不可能です。

実務への適用 — 今週から始められること

大げさな計画の代わりに、すぐ始められる小さなルーチンを提案します。

  1. 今週のレビュー1件を上記のチェックリストで実施し、項目ごとに一行ずつ書いてみます。
  2. AIに任せた作業を一つ選び、マージ前に別の解き方を一つ、義務的に思い浮かべてみます。
  3. 公開ポストモーテムを一編読み、決定の分岐点を見つけてメモします。
  4. よく任せる作業一つについて、5行のevalスクリプトを書きます。
  5. 次の機能リクエストを受けたら、コードを作る前に上記形式の1ページスペックを先に書きます。

この五つを全部合わせても週3時間かかりません。しかし1年積み重なれば、同じツールを使う同僚との差は、ツールが埋めてくれるものではなくなります。

よくある質問

Q. センスとただの頑固さはどう区別しますか?

根拠の更新可能性で区別します。センスは新しい証拠(ベンチマーク、障害、ユーザーの反応)の前で更新される判断であり、頑固さは証拠と無関係に維持される選好です。自分の判断が最後に変わったのはいつかを思い出してみればよいのです。思い出せないなら、危険信号です。

Q. センスを面接でどう見せればいいですか?

言葉で主張する代わりに、成果物で見せます。レビューコメント集、自分で書いたスペック、evalスクリプト、棄却した設計とその理由を記したADRが最も強力な証拠です。12週間カリキュラムの成果物がそのままポートフォリオになるよう設計した理由でもあります。

Q. チーム全体のセンスが悪い方向に固まっている場合は?

コンテキストファイルとevalsは諸刃の剣です。悪い基準も同じように自動化され、増幅されます。だからこそ基準文書には必ず更新手続き(四半期レビュー、異議申し立ての経路)を一緒に入れるべきです。センスの明文化は一度きりの作業ではなく、運用です。

おわりに

AIコーディングツールの時代に開発者の価値が消えるという不安と、ツールさえ使いこなせばスーパー開発者になれるという楽観は、どちらも半分だけ正しいのです。ツールは生産を民主化しましたが、その結果、判断の価値を劇的に引き上げました。

センスは神秘的な才能ではありません。良いコードを読み、構造化されたレビューを行い、失敗事例を分析し、多くのプロダクトを評価してきた時間の蓄積です。そしてそのセンスは、スペックとevalsという形で明文化されたとき、チームの資産になります。

スピードはもう全員に与えられました。残る問いは一つです。そのスピードでどこへ行くのか。その答えを持つ人が、30xと呼ばれることになるでしょう。

参考資料

Discuss on Twitter • View on GitHub