はじめに
ChatGPTをはじめとする生成AIが登場して以来、エンジニアの仕事の価値について議論が続いています。「AIがコードを書いてくれるなら、エンジニアは不要になるのでは？」という声もありますが、実際にはむしろ逆の現象が起きています。
AIによって、誰でも簡単にアクセスできる一般的な知識の価値が急速に低下しているのです。代わりに重要性を増しているのが、ドメイン知識とコンテキスト化された知識です。
本記事では、なぜ一般論が無価値化しつつあるのか、そして技術者として何に価値を置くべきなのかを考えていきます。
一般論が無価値化する理由
誰でもアクセスできる知識
従来、技術書や公式ドキュメントを読んで得られる知識には価値がありました。しかし現在では、AIに質問すれば即座に回答が得られます。
「ReactのuseEffectの使い方」「Pythonでファイルを読み込む方法」といった情報は、もはや知識として持っている必要がありません。必要なときにAIに聞けば済むからです。
ClaudeやGPTが教えてくれること
生成AIが得意とするのは、広く一般的に知られている情報の提供です。
- プログラミング言語の基本文法
- 主要なフレームワークの使い方
- 一般的なアルゴリズムの実装
- よくあるエラーの解決方法
- 標準的なデザインパターン
これらは確かに有用ですが、誰でも同じ回答を得られるため、差別化要因にはなりません。
表面的な知識の限界
AIが提供する回答は、多くの場合「最大公約数的な正解」です。しかし実際のプロジェクトでは、この一般解がそのまま使えないケースが大半です。
なぜなら、現実のシステム開発には以下のような要素が絡むからです。
- 既存システムとの整合性
- チームのスキルセットや開発体制
- パフォーマンス要件やスケーラビリティ
- セキュリティポリシーや規制対応
- 技術的負債や過去の設計判断の影響
- ビジネス要件の優先順位
これらの文脈を無視した一般論は、むしろ有害になることさえあります。
これからの時代に必要な知識とは
ドメイン知識の重要性
ドメイン知識とは、特定の業界や分野に関する深い理解を指します。
例えば、金融システムを開発するエンジニアに求められるのは、単にコードが書けることではありません。
- 金融商品の仕組み
- 会計処理のルール
- 規制要件（金融庁の指針など）
- 業界特有の慣習や用語
- リスク管理の考え方
これらの知識は、AIに簡単に聞けるものではなく、現場での経験や業務を通じて蓄積されていきます。
コンテキスト化された知識の力
コンテキスト化された知識とは、特定の状況や文脈に適応させた知識のことです。
同じ技術スタックを使っていても、プロジェクトごとに最適な判断は異なります。
- このチームの技術レベルなら、この実装方法が保守しやすい
- この予算とスケジュールなら、完璧を目指すより早期リリースを優先すべき
- このサービス規模なら、過度な最適化は不要
- この組織文化では、この進め方が受け入れられやすい
このような判断は、プロジェクトの文脈を深く理解していなければできません。
実践と経験から得られるもの
書籍やドキュメントには書かれていないが、実際に手を動かすことで分かる知識があります。
- なぜこのライブラリは、ドキュメント通りに使っても動かないのか
- このフレームワークの癖や、知っておくべき落とし穴
- パフォーマンスチューニングの勘所
- 障害発生時の効果的なデバッグ手順
- チーム開発における実践的なコミュニケーション
これらは「暗黙知」として蓄積され、経験豊富なエンジニアの強みとなります。
技術領域での具体例
一般的なコードの書き方 vs プロジェクト固有の設計判断
一般論（AIが答えられる）
# ユーザー情報を取得する一般的な実装
def get_user(user_id: int) -> User:
return db.query(User).filter(User.id == user_id).first()
コンテキスト化された実装
しかし実際のプロジェクトでは、以下のような判断が必要になります。
- このシステムでは退会済みユーザーをどう扱うべきか
- 論理削除されたユーザーの取得をどう制御するか
- パフォーマンスのためにキャッシュを挟むべきか
- 監査ログを残す必要があるか
- アクセス権限のチェックをどの層で行うか
# プロジェクトの文脈に合わせた実装
def get_user(
user_id: int,
include_deleted: bool = False,
with_permissions: bool = True
) -> Optional[User]:
"""
ユーザー情報を取得
Notes:
- デフォルトでは退会済みユーザーを除外
- 管理画面からは include_deleted=True で呼び出す
- 権限チェックが必要ない場合は with_permissions=False
"""
query = db.query(User).filter(User.id == user_id)
if not include_deleted:
query = query.filter(User.deleted_at.is_(None))
user = query.first()
if user and with_permissions:
user.permissions = PermissionService.get_user_permissions(user_id)
AuditLogger.log_user_access(user_id)
return user
この実装には、プロジェクトの要件や設計方針が反映されています。
フレームワークの使い方 vs ビジネス要件への最適化
一般論
「Next.jsではSSRを使いましょう」「APIはRESTfulに設計しましょう」
コンテキスト化された判断
実際には、ビジネス要件に応じた柔軟な判断が求められます。
例えば、社内管理ツールであればSEOは不要なため、開発効率を優先してCSRを選択する判断もあり得ます。
ベストプラクティス vs チーム/組織の文化・制約
一般論
「テストカバレッジは80%以上を目指しましょう」「コードレビューは必須です」
コンテキスト化された運用
しかし現実には、チームの状況に応じた落とし所が必要です。
- チームメンバーのスキルレベル
- プロダクトのフェーズ（MVP段階 vs 成熟期）
- リリースまでの期限
- 技術的負債の許容度
- 既存コードの品質
スタートアップの初期フェーズで完璧なテストを書くことより、素早く市場検証することが優先される場合もあります。一方、金融システムや医療システムでは、テストの徹底が必須となります。
エンジニアとして差別化するために
ドメイン知識を深める方法
ドメイン知識は意識的に身につける必要があります。
業務を通じた学習
- ビジネスサイドのミーティングに積極的に参加する
- プロダクトマネージャーやドメインエキスパートと対話する
- 業界の専門書や記事を読む
- 実際にサービスを使い込んでみる
質問する習慣
技術的な実装だけでなく、「なぜこの機能が必要なのか」「ユーザーはどう使うのか」を常に問いかけましょう。
コンテキストを理解する習慣
プロジェクトの背景や制約を理解することが、適切な技術判断につながります。
意識すべきポイント
- このプロジェクトのゴールは何か
- 誰がステークホルダーで、何を重視しているか
- 技術的な制約（既存システム、予算、期限）は何か
- チームの強みと弱みは何か
- 将来的にどう発展させたいか
技術選定や設計判断の際、これらの文脈を踏まえているかどうかで、提案の質が大きく変わります。
実践から学ぶ姿勢
知識を実際に使ってみることで、表面的な理解が深い理解に変わります。
効果的な学習アプローチ
- 新しい技術は小さく試してから導入する
- 失敗から学び、ナレッジを蓄積する
- チーム内で知見を共有する
- 定期的に振り返りを行い、改善する
AIに聞けば答えが出る時代だからこそ、実際に手を動かして得られる経験の価値が高まっています。
まとめ
生成AIの登場によって、一般的な技術知識の価値は急速に低下しています。誰でもアクセスできる情報は、もはや差別化要因にはなりません。
これからのエンジニアに求められるのは、以下の能力です。
- ドメイン知識: 特定の業界や分野に関する深い理解
- コンテキスト化する力: プロジェクトの文脈に応じた最適な判断
- 実践知: 経験から得られる暗黙知や勘所
技術の基礎を学ぶのはAIに任せて、エンジニアは文脈を理解し、ドメインを深掘りし、経験を積むことに時間を使うべきです。
一般論から脱却し、具体的な文脈の中で価値を生み出せるエンジニアこそが、これからの時代に求められる人材だと私は思っています。