AI 生成コード導入とエンジニアリング文化の変化について：Ashby エンジニアリング担当ヘッドによる提言

2025 年 8 月以来、Ashby の本番システムに導入される新機能の半分以上は AI が生成したものです。しかし、顧客からの問い合わせ件数は依然として安定しており、世界は崩壊しませんでした。多くの顧客と多数の AI 生成コードが存在する中で、以下のような結果が得られています。

• 安定性: 年間を通じてお問い合わせ件数は安定しており、毎年 3・4 月頃の周期的な変動を除き、大きな問題はありません。
• 品質と生産性: コード品質やエンジニアの生産速度、オンボーディング時間のリグレッションは確認されていません。
• 理解度向上: Anecdotal（事例に基づく）な観察としては、コードベースに対する理解度が向上していると報告されています。

Ashby は、10 万を超える週次アクティブユーザーを擁し、週間数百万件の求職者申請を取り扱う人材採用スイートです（Calendly や Looker に匹敵する機能）。本稿は Ashby の EMEA エンジニアリング担当ヘッドである Colin が執筆したものです。エンジニアリングチームが AI への考え方や働き方の変化について共有しています。

---

私たちの提唱

コード生産のコストはゼロに向かって低下していくという考えです。AI は職務を奪うために来ているのではなく、「機械的な部分」（構文、コネクションコード、キーボード入力など、面白みや挑戦性に欠ける領域）が代替対象となります。エンジニアとしての価値の源泉である判断力や審美眼、そして顧客への理解といった本質的な部分は、ますます重要度を増していきます。

この転換点はすでに訪れています。「私の PR のほとんどは完全に AI に書かれています」「 Entire データ摂取を実装しました（約 40 件の PR）」と、エンジニアの一人 Tom が語っています。

我々は新興技術であることに鑑み、業界全体で AI を効果的に活用してソフトウェアを開発する方法を探求しています。「迅速に進める」ことが「乱暴に進める」ことへ転じるかを避けつつ、共有されたメンタルモデルを構築し、学習を進めていくことを目指しています。

基本的なルール

LLM を使用する度合いが増し、周囲の世界も変化していく中で、以下の二つの基本ルールを提唱します。

• AI で代替できないのは「共感」です。
• あなたは自分が shipping（公開・リリース）するものに対して責任を負います。

共感は AI で代替できません

製品開発とは人間の営みです。LLM は審美眼を持っていません。我々の顧客を知っておらず、悪い製品を使う苦痛や優れた製品を使う喜びを理解することも感じ取ることもできません。そこに依然として判断力が要求されます。機能性のある製品を作ることは容易ですが、それ以上の「素晴らしい製品」を生み出す能力の方が重要になっています。

• ドキュメントとコミュニケーション: 我々は意味のないデザインレビュー会議を開かず、プランニングポーカーも行いません。同僚が読めて理解できるようにドキュメントを書き、変更のレビューにも協力を求めます。共感とは、その人間向けのドキュメントを書くことを忘れないようにすることです。
• AI の限界: LLM は執筆に助力できますが、ガイダンスがない状態では、説得力がありながら人間の読み手にとって読みにくい、重要でない詳細がちりばめられた情熱や知恵を欠いた文章を書いてしまいます。

例：不適切な PR 説明の抜粋 LLM が生成した PR 説明は以下のように冗長で核心から外れていました。

1Added .github/workflows/pr-relevant-test-coverage.yml:
2- Triggers on pull_request (excluding master) and
3workflow_dispatch with pr_number.
4- Resolves PR number, collects changed files, and asks
5Claude to output up to 15 relevant test files.

核心: 「Coverage is intentionally not full-suite coverage; it reflects only Claude-selected relevant tests against changed files」（カバレッジは意図的にフルスイートではありません。変更されたファイルに対して、Claude が選択した関連テストのみを反映しています）。

同僚の時間を敬重しない説明は共感に欠けており、人間向けのドキュメント作成を LLM に委譲してはいけません。

あなたは shipping（公開・リリース）するものに対して責任を負っています

LLM は驚くほど誤ることがあります。自信を持って誤っていること、説明不能な粗忽さもあり得ます。AI の最大のリスクは「間違っている」ことではなく、**「正しそうに聞こえる」**ことです。

例： Claude Code が「tar-stream パッケージを削除したつもりはありません——バックエンド/package.json を編集する際に偶発的な犠牲者でした」と発言しました。

• 責任: どの行が手書きであっても、PR 全体が LLM によって生成されたとしても、そのコードが何を行うのか、なぜそうするのか、そしてそれが破損した際にどのようなことが起きるのかを理解することはあなたの責務です。
• 懐疑的姿勢: LLM を使用する度合いが増すにつれ、懐疑的態度を高める必要があります。代替案を求め、エッジケースについて問い、自らを批評させるよう促し、出力を受け入れる前にその理由を理解してください。

もっと深く考えてください

LLM を使うと、思考なしに物事を進めてしまうことが容易になってしまいます。そんな衝動には抵抗してください。常に警戒心を保ってください。

問題文を LLM に投げつけ、PR の説明やテストも AI に書いてもらって PR をレビューのために提出する……。そのような流れの中で、根本的に間違っている問題を修正したり、中途半端なソリューションを構築したりしてしまいます。

特に危険なのは、異なるタスクに対して多数のエージェントを並行して実行することです。これを**「ステロイド剤打了たマルチタスキング」**と呼ぶこともあります。

• 非生産性: マルチタスクは非生産的です。人間の脳が複数の高次タスクを同時に集中することはできないため、5 つのエージェントが 5 つの課題に取り組んでいても、最善の意思決定ができているとは限りません。
• ハype サイクルへの抵抗: 現在の潮流では数量と速度が重視されがちですが、品質や創意工夫は無視されます。Ashby は**「何でもあり、そして全てをショートカットできる」という短絡的な世界観**に屈しません。

ショートカットは常に存在しましたが、それらは多くの場合仕事の品質や創意工夫を低下させました（外注による代替、基本機能の開発の省略、早期ローンチなど）。しかし、高品質な人材を採用する時間や、コードを書く代わりに抽象化を考える時間、製品に対して忍耐を持つ時間を費やすことが、代替案よりも大きなインパクトを与えてまいりました。

深く考えることは、今日我々が成功しているスタートアップの要因の一つであり、今後もそれを続けるつもりです。

スペックは依然として人間のために書かれます

LLM にスペックを投与する意向がありますが、人間が必要とするスペックの内容と、LLM が必要とするスペックの内容とは異なります。

• 人間向けのスペック: 時間に対する配慮があり、読み手を惹きつけ、重要度の高い意思決定に集中させるようなものが求められます。
  • 「なぜ Redis を PostgreSQL ではなく採用したのか」という説明。
  • 「新しい列挙型の全ての可能な値を詳細に記載したドキュメント」。
• LLM へのコンテキスト: スペックが提供するコンテキストは有益ですが、共感的なものが必要です。

人間向けのスペック作成は継続して行う必要があります。それは以下のようなことを達成します。

• 変更コストの高い意思決定に焦点を当てます。
• 我々が間違ったものを開発するリスクを低減します。
• 必要とする抽象化を特定します（例：百万を超えるフォームに対して動作を実行する場合、個別実装かバッチ処理機能の向上かの判断）。

スペックは人間のために書かれるものです。LLM はそれを有益な追加コンテキストとして消費しますが、作成主体は人間です。

LLM を考える方法

LLM の仕組みについては多くの文献がありますが（Sam Rose 氏の投稿も推奨）、以下のモデルで運用することをお勧めします。

基本モデル：LLM は「サイコロ」です （超知能という hype と区別してください）

• 得意分野: ドキュメントの要約、パターンの発見と継続（高得点を目指す必要はありません）。
• 苦手分野: 「strawberry」の中の'r'の数を数える、大きな数の乗算など。これらは容易そうに見えますが、サイコロから確実に出るような精度を与えることができません（連続して 6 を出すことは決してないでしょう）。
• 重み付け方法: 良いものの例を示すことで、勝つの Odds を有利にします。

AI と共に働く二つのモード

LLM と共に働く際、大きく分けて 2 つのモードがあります。自分がどのモードにいるかを理解することが最も重要です。

1. Sidekick モード（アシスタント）

• 役割: AI を使用してコードベースを探索し、大量の情報を消化し、書かれた詳細なスペックを実装します。
• 意思決定: 主要な意思決定はあなた自身が行う必要があります。
• 適用領域: データベース移行、求職者データの取り扱い、セキュリティ関連コード、アーキテクチャに関する意思決定などの高リスク領域。
• 注意: 「外見上正しそう」という程度では不十分であり、操縦席に座っている必要があります。

2. Delegate モード（委任）

• 役割: 出力を確認してから（あるいは確認せずに）進めます。
• 適用領域: プロトタイピング、ローカルツール、運用ツールなど影響範囲が小さい場合のみ。
• 注意点: 失敗のコストが低いので迅速に進めることができますが、多くのエンジニアは当初 AI を過剰に委任し、後に修正することで逆に過少な委任を行う傾向があります。

「AI を使うべきか」という問いではなく、**「ここでどれくらい信頼すべきか」**という問いを投げかけ続ける必要があります。コードが間違っていることが起きた場合どうなるかを想像してください（恥になるか？高価になるか？存在に関わる事態か？）。これらの二つのモードの間でブレることが一般的ですが、判断力が重要となります。

タスクを分割する投資も回収できます。例えば、「LLM に新機能のスケレフolding を構築させ → 手書きでいくつかの SQL クエリを実行 → 最後に単体テストを書くために完全委任に戻る」といったハイブリッドなアプローチが有効かもしれません。

現在 AI をどのように活用しているか

私たちは積極的にエンジニアに AI ツールの利用を促しており、教育、ワークショップ、ペアプログラミングを通じて推進しております。

• 自由な利用: AI の利用を義務化したり、トークン使用量を測定したりはしておりません（「スロップ（下品な出力）」を助長する恐れがあるため）。安全性はインフラストラクチャに組み込まれるべきであり、規律として強制されるものではありません（スイスチーズモデル：各レイヤーの穴が異なる位置にあるため、総合的に安全になる）。
• 利用環境: 全てのエンジニアに AI コード生成ツールのアクセス権を与えています（Cursor, Claude Max, Codex, Various agent frameworks など）。トークン制限もありません。
• 品質保証: リンターや DangerJS および AI をコードレビュー支援に使用しています。CodeRabbit などのサードパーティ製ツールと自社開発のコードレビューツールを組み合わせて、エッジケースのバグを検出しています。
• 共有インフラ: Git メタデータを主要リポジトリから複製した SQLite データベースをエンジニアに提供し、「以前にもこのようなバグを見たことがありますか？」といった質問に対してより迅速かつ正確に回答できるようにしています。
• 他部門とのコラボレーション: 内部モデルで顧客問い合わせの自動振り分けを行い、Claude Code をタスク割り当ててバグの原因分析やレポート作成を自動化しています。これによりサポートチームが数時間かかる問題を 10 分以内に解決できるよう支援しています。

これからの展望

DevEx とツール投資を継続し、AI が高品質なコードを生成しつつ人間の負担を低減することを確保しています。

コードレビューの見直し

出力量の増加は我々のレビュー能力を上回ります。「なぜコードをレビューするのか」という問いに対して批判的な視点を持つ必要があります。レビュー時間を高価値なターゲットに集中させる必要があります。

• 自己レビューと自動ツールの活用: 人間はバグを見逃すことに長けていませんが、コンポーネント内で

  useMemo

  が適切に使われているかについて考える時間は費やす必要はありません。自己レビューとその他のツール（リンティング）が 90% を担当すべきです。
• 重点レビュー項目:
  • その変更は妥当か？
  • 高リスク領域はどこか？そのリスクをどう低減できるか？
  • パフォーマンス特性はどうなのか？
  • 抽象化は合理的か？十分に抽象化しているか？

**LLM は既存のものを再利用するよりも新しいコードを生成することにバイアスがあります。**監視されないまま放置すれば、動作はしても誰一人としてナビゲートすることができないコードベースを構築してしまいます。シンプルさへの推進は、現在レビュアーができる最も価値あることの一つです。

自動検証

記述は安価になりましたが、検証がボトルネックになりつつあります。AI はテスト作成のコストもゼロに向かって低下させています。

• テストの自動化: QA チームとエンジニアが連携し、Playwright を使用して E2E テストを作成しています（過去 4 週間に 65 の新規テストケースが作成され、そのうち 70% は QA チーム外のメンバーが貢献）。
• 静的解析の重要性増大: ファズテストとフロントエンド単体テストが必要であり、ノイズを管理し、人間が重要な意思決定に集中できるようにする必要があります。AI による AI のレビューも必要になります（パフォーマンス、PII 処理、エラー処理、セキュリティに焦点を当てた自動レビュー）。

閉じ

コードベースには新しい読者——LLMが加わりました。全てのパターン、名前、モジュール境界は今や LLM と人間双方によって読み込まれます。そして LLM はそれを見つけたものを直訳的に受け取ります。乱雑なコードベースは単に同僚の動作を遅くするだけでなく、AI 生成コードの品質を低下させます。

AI がコードを生成することに抵抗感を抱いている場合、それは理解できます。しかし実際に何が楽しいか考えてみてください——コードを手打ちすることなのか、それとも適切な抽象化がハマった瞬間なのか。AI は前者を取り扱います。後半部分はこれまで以上に重要になりつつあります。そして問題の理解や解決対象となる誰かを理解していない限り、正しい抽象化を構築することはできません。顧客理解はコアなエンジニアリングスキルとなります。

したがって、エンジニアたちは今より多くの時間を他のことに費やすようになりました：

• ユーザーセッションリプレイの観察
• 顧客インタビューの観察
• 内部ユーザーとの話し合い
• サポート会話の読み込み

問題領域を理解するエンジニアは、間違ったものを構築するために浪費する時間が減り、高品質で独立性の高い意思決定を行えます。実装速度は健全な判断力を乗数として働きます——AI は注文処理チームを過剰にしつつも、我々のようなチームをより強力にします。

当社のエンジニアはこの変化に適しています。彼らを採用した理由は純粋に技術的才能だけでなく、製品思考を持ち、良好なコミュニケーション能力があり、健全な判断力を持っているからです。今や単独のエンジニアが持つレバレッジは不釣り合いほど大きく、しかもそれは増し続けています。

お気に召しますか？我々はヨーロッパと米大陸全域を跨いだ完全リモートエンジニアを募集しています。