プロローグ · AI は良い開発者をより良く、悪い開発者をより悪くする
Season 5 の 12 編を通して、Lakehouse・ストリーミング・OLAP・オーケストレーション・セマンティックレイヤー・Vector DB・ガバナンス・オブザーバビリティ・組織・文化・FinOps・セキュリティまでを駆け抜けた。すべて ツールとシステム の話だった。最終編は結局 人 の話だ。
2025 年の開発者の現実は二面性を帯びている。
希望
- AI ツールで生産性が 2-5 倍 向上した開発者の事例が続出
- 1 人スタートアップで ARR $1M 達成（Indiehacker 報告）
- ジュニアが数日で複雑な機能を完成
- オープンソース貢献量の急増
不安
- 「AI がコーディングを代替する」というヘッドライン
- スタートアップの開発者削減、ジュニア採用の急減
- 「自分は AI をうまく使えているのか?」という不安
- 海外リモートと国内市場の格差
「AI は良い開発者をより良くし、悪い開発者をより悪くする。」
Season 5 のフィナーレは、そのサバイバル戦略である。
第 1 章 · 2025 年 AI コーディングツールの地形図比較
IDE 組み込み型
(1) GitHub Copilot
- 代表格かつ最も普及。VS Code・JetBrains・CLI
- 2024 年後半 Copilot Workspace, Copilot Extensions
- 2025 年 Copilot Agent Mode（タスク単位の自動実行）
- バックエンド: OpenAI（GPT）+ Anthropic（Claude）+ 自社モデルから選択
- エンタープライズライセンスと SSO が成熟
(2) Cursor
- AI-Native IDE（VS Code fork）
- Composer モードで複数ファイル編集
- Tab 予測 が非常に強力
- スタートアップ・インディ開発者に好まれる
- 2024-2025 年に急成長
(3) Windsurf（Codeium）
- Cursor の対抗馬、Cascade 自動実行モード
- 無料プランが寛大、エンタープライズでも成長
- 2025 年初頭に OpenAI の買収試行が話題
(4) JetBrains AI Assistant
- IntelliJ・PyCharm・WebStorm に内蔵
- JetBrains ユーザーには自然な選択肢
CLI / Agent 型
(5) Claude Code（Anthropic）
- ターミナルで実行する Coding Agent
- ファイルシステム・Git・Bash ツールと連携
- 複数ファイル・大規模リファクタリングに強み
- 2024 年 10 月リリース以降、急成長
(6) OpenAI Codex CLI（2025 年ローンチ）
- OpenAI のターミナルエージェント
- Claude Code の強力なライバル
o1-pro,o3ベースの推論力
(7) Aider
- オープンソースの AI ペアプログラマー
- Git コミットの自動化
- モデル中立（OpenAI, Anthropic, ローカル）
Autonomous Agent
(8) Devin（Cognition Labs）
- 「AI Software Engineer」初のデモとして話題
- 長期タスクを自律実行
- 2025 年時点でもプレミアム、実運用は限定的
(9) OpenHands（旧 OpenDevin）
- Devin のオープンソース代替
- ローカルで Agent 実行
(10) SWE-agent（Princeton）
- 研究用オープンソース、SWE-bench ベンチマーク
総合比較（2025 年 4 月時点、実ユーザー体感）
| ツール | 速度 | 精度 | 大規模変更 | 自律性 | 価格 |
|---|---|---|---|---|---|
| Copilot | 星 5 | 星 4 | 星 3 | 星 2 | $10-39/月 |
| Cursor | 星 4 | 星 4 | 星 4 | 星 3 | $20/月 |
| Windsurf | 星 4 | 星 4 | 星 4 | 星 3 | $15/月 |
| Claude Code | 星 3 | 星 5 | 星 5 | 星 4 | API 課金 |
| Codex CLI | 星 3 | 星 5 | 星 5 | 星 4 | API 課金 |
| Aider | 星 3 | 星 3 | 星 3 | 星 3 | API 課金 |
| Devin | 星 2 | 星 3 | 星 4 | 星 5 | $500/月 |
2025 年の現実的な推奨
- 個人/ジュニア: Cursor または Copilot で開始
- シニア・大規模リファクタリング: Claude Code または Codex CLI
- チーム導入: Copilot（エンタープライズ成熟度）+ Cursor（一部選択肢）
- 自動化実験: Claude Code + カスタム MCP サーバー
第 2 章 · Prompt Engineering から Context Engineering へ
2023 年の話題は「Prompt Engineering」。2025 年の話題は Context Engineering である。
なぜ変わったのか
初期の LLM は 単一プロンプト の設計技術が結果を左右した。しかし 2024-2025 年:
- Context Window が 100k-1M に拡大
- Tool Use, Agent Loop が一般化
- RAG・MCP で外部コンテキストを接続
- モデル自体が既に「よく答える」水準
結果: 「何をどう書くか」より「何をどのコンテキストに入れるか」 が性能を決める。
Context Engineering の 5 つの軸
(1) Retrieval（検索・取得）
- RAG, MCP, ファイルシステムアクセス
- 「関連しないもの」を除外することが核心
- Reranking, Chunking 戦略
(2) Compression（要約・圧縮）
- 長い会話・ドキュメントを圧縮してトークン予算に収める
- Hierarchical summarization, working memory の設計
(3) Structuring（構造化）
- JSON Schema・XML タグでコンテキストを区切る
- 「System, History, Tools, Current Task」を明確に区分
(4) Persona・Priming（セットアップ）
- システムプロンプトで役割・スタイル・制約を設定
- Few-shot 例で望ましいパターンを提示
(5) Feedback Loop（フィードバックループ）
- Agent が実行結果を再びコンテキストに含める
- テスト実行・ツールエラーをループに統合
実例: Claude Code プロジェクト
CLAUDE.mdファイルで プロジェクトのルール・スタイル・禁止事項 を指定.mcp設定で許可されたツールを宣言/memorizeコマンドで作業中に発見した事実を記憶- サブエージェント を使い、隔離されたコンテキストで並列作業
「良いプロンプト」より「良い仕様」
2025 年の核心的な気づき: AI に仕事を任せるのは ジュニア開発者に要件仕様を渡すこと と同じだ。
- 曖昧な依頼 → 曖昧な結果
- 検証可能な仕様 → 検証可能な実装
- 「何が満足条件（acceptance criteria）か」 を明確にする
AI 時代の良いエンジニアは 良い PM・テックライター の資質を兼ね備える。
第 3 章 · シニア・ジュニア開発者の役割の再定義
シニア開発者（7 年以上）
従来の役割
- 設計・レビュー・メンタリング
- 複雑なバグの解決
- 技術選定・意思決定
2025 年に加わる役割
- AI 活用の最大化: Cursor・Claude Code・Codex で生産性 5 倍
- 仕様・文脈の設計: AI に渡すコンテキスト構造を設計
- レビュー対象のシフト: 「人が書いたコード」より 「AI が書いたコード」 のレビュー比率 up
- 自動化アーキテクト: 反復業務を AI で自動化するパイプラインを設計
- ジュニアメンタリングの再設計: 「AI をどう使いこなすか」を教える
ジュニア開発者（0-3 年）
従来の役割
- 簡単なタスクで経験を積む
- シニアからコードレビューを受けながら学習
2025 年の挑戦
- 「AI が簡単なタスクをこなしてしまうと、ジュニアは?」
- 実際 ジュニア採用は急減（2024 後半-2025 初頭）
それでも生き残るジュニアの特徴
- AI を批判的に使う: AI の答えを盲信せず検証
- CS の基礎が堅い: アルゴリズム・OS・ネットワークの理解
- ドメイン知識: ビジネス・顧客・プロダクトの理解
- 実行力: 「作って公開する」習慣
- コミュニケーション: 非同期ドキュメント・レビュー文化への適応
- オーナーシップ: 自分のプロジェクト・ポートフォリオを積む
「2025 年のジュニアは昔のジュニアより多くをこなす必要がある。AI のおかげでそれができる。」
消える職種 vs 伸びる職種
縮小
- 単純な CRUD 開発者
- 単純な翻訳・ドキュメント化
- 一次 QA（手動テスト）
- 初級データアナリスト（SQL を書くだけ）
拡大
- AI Engineer・AI Product Engineer
- Platform / DevEx Engineer
- Security Engineer・AI Safety
- Data / AI Infrastructure
- Developer Tools エンジニア
第 4 章 · チームの AI ツール導入ロードマップ
個人ではなくチーム規模の導入。
Phase 1（Month 1-2）: パイロット
- 1-2 ツール に制限、5-10 名が参加
- ライセンス・法務レビュー（コード学習の可否、セキュリティ）
- Success Metric の設定（PR 速度、レビュー時間、バグ減少）
Phase 2（Month 3-4）: 拡散
- 全社ロールアウト、教育セッション
- AI 利用ガイドライン 文書
- 機密情報のマスキング・除外
- ライセンス・著作権への注意
- コードレビュー基準（AI 生成コードも同じ水準）
- パワーユーザーコミュニティ（週次 Tips 共有）
Phase 3（Month 5-6）: 深化
- カスタム MCP サーバー・会社特化コンテキスト
- 社内 Knowledge Base と連動した RAG
- AI ベースの自社ツール開発（Slack ボット・レビュー ボット）
Phase 4（6 ヶ月以降）: 内在化
- AI ツールが 標準ツールチェーン の一部に
- パフォーマンス評価に「AI 活用生産性」を含める（議論あり）
- 自社 Fine-tuning・Self-Hosting を検討（大規模）
注意点
- 「AI 禁止」 方針は 2025 年には不可能 — 隠れた利用だけが増える
- 過度な監視 は信頼を壊す
- セキュリティ・IP 保護 は明確に、残りは自律に任せる
第 5 章 · 評価・レビュー文化の再設計
AI が多くのコードを書く時代、「行数」のような指標は無意味だ。
新しい開発者評価指標
(1) Outcome ベース
- 実装した機能がユーザー・ビジネスに与えたインパクト
- 行数・PR 数は補助指標
(2) Quality ベース
- バグ発生率、ロールバック率
- テストカバレッジ、レビュー品質
(3) Velocity ベース
- アイデアから本番までの時間
- DORA 4 metrics（Lead Time, Deploy Frequency, Change Failure Rate, MTTR）
(4) Learning・Sharing ベース
- チーム内の知識共有・メンタリング
- ドキュメント・ADR の作成
(5) System Design ベース
- 複雑な問題の解決、抽象化・再利用
- 「削除したコード」も成果
Code Review 文化の再設計
従来の Review
- 「人が書いたコードを人がレビュー」
- スタイル・バグ・設計を指摘
2025 年の Review
- 「AI と書いたコードを人がレビュー」
- 主な関心事:
- AI ハルシネーション のチェック（存在しない API 呼び出し、誤ったロジック）
- セキュリティ（AI がシークレットを露出、安全でないパターンを生成）
- ライセンス: GPL コードの複製の可否
- 意図: なぜこう解いたのかの根拠
- 自動レビュー ボット（CodeRabbit, Greptile）が一次フィルタ
- 人間は 重要なこと に集中
AI 過度依存のアンチパターン
- 「動くけれど理解していない」: レビューで説明できない
- AI の答えに盲従: より良い設計の検討を省略
- 過剰な複雑性: AI が簡単に作るコードを無意味に追加
- テストのスキップ: 「AI が書いたから大丈夫だろう」
第 6 章 · オープンソース貢献の再定義
なぜ今も重要なのか
- ポートフォリオ: 履歴書より GitHub の方が説得力がある
- ネットワーク: グローバルエンジニアとの協業経験
- 学習: 良いコードを読んでパターンを吸収
- 可視性: 採用担当や同僚に発見される
2025 年の貢献の新しい姿
- AI が簡単な PR を量産 → メンテナの負担が増加
- 「Drive-by PR」（単発）への警戒感
- 継続的な関係 と 意味のある問題解決 が重要
効果的な貢献戦略
- Issue First: コードの前に Issue で問題・解決策を議論
- 小さく始める: ドキュメント・テスト・バグ修正から
- 短いフィードバックループ: メンテナと積極的にコミュニケーション
- 一つのプロジェクトに集中: 複数に 1 PR ずつよりも一つを継続
- 韓国コミュニティ: OpenStack Korea, Kubernetes Korea, K-Node, Karrot（당근）オープンソース
オススメのオープンソースプロジェクト（2025）
- dbt-core, Dagster, Dlt: データエンジニアリング
- LangChain, LlamaIndex, Haystack: LLM アプリ
- Kubernetes, Istio, Crossplane: インフラ
- Next.js, Svelte, Astro: フロントエンド
- TanStack, tRPC: フルスタックツール
- Pydantic, FastAPI: Python
- Bun, Deno: ランタイム
- 韓国発: OpenSearch（by Naver）, HyperClovaX（一部）, Toss Slash
第 7 章 · ポートフォリオ — キャリア資産の再構成
2025 年のポートフォリオの要素
(1) GitHub プロフィール
- Pinned Repo 6 個: それぞれ異なる技術・ドメイン
- README: 何を、なぜ、どう、結果
- Contributions: 継続性が重要（毎日である必要はない）
(2) ブログ・Tech Writing
- 自分の失敗・デバッグ・設計判断
- 1 年に 6-12 本が継続ペース
- 英語ブログ の有無がグローバル競争力を決める
(3) Side Projects
- 実ユーザーがいるプロダクト
- 数値で表現（MAU, ダウンロード, コントリビュータ）
- 難しくても デプロイ の経験（Vercel, Fly, Railway）
(4) Conference・Meetup 発表
- 社内発表 → 小さな meetup → 国内カンファレンス → 海外へ
- コミュニティ貢献は シニア応募時の大きな加点
(5) 業務外学習の証拠
- 認定（AWS, GCP, Kubernetes 等）は補助的
- 自分の継続的な関心を示すプロジェクトが強力
過小評価されている資産
- Incident Postmortem 経験: 大規模障害対応のストーリー
- 大規模データ・システム運用経験: 数値化
- クラウドコスト削減事例: CFO から見える
- チームプロセス改善: DORA 指標の向上
第 8 章 · 韓国人開発者のグローバル競争力
2025 年の韓国人開発者の現在地
強み
- 基礎工学教育の水準
- 誠実さ・実行力
- 大規模トラフィックの経験（Naver・Kakao・Coupang・Toss）
- 金融・ゲーム・EC ドメインの深さ
弱み
- 英語コミュニケーション（ドキュメント・ミーティング）
- 非同期ドキュメント文化 の不足
- プロダクト思考・ビジネス感覚（エンジニアリング外の領域）
- グローバルネットワーク の制限
グローバルリモート採用の現実
- 2024-2025 年、韓国人材の海外リモート採用 が増加
- Toptal・Turing・Crossover・Remote・Deel プラットフォーム
- スタートアップ のリモート採用が特に積極的
- 年収: 韓国大企業比 2-3 倍、シリコンバレー比 60-70%
- 時差: 米国企業は韓国 9-11 時 = 米西海岸 17-19 時
海外就職・リモート成功戦略
- 英語 GitHub/LinkedIn を常時メンテナンス
- オープンソース貢献 でグローバルなつながりを築く
- 英語ブログ 3-5 本: 技術的な深さ
- 英語面接の実戦訓練（Interviewing.io, Pramp）
- ネットワーク: 海外 meetup（オンライン）, DevRel と会う
- 特化ドメイン: グローバル需要の大きい分野（Infra, AI, Security）
国内 vs グローバルの選択基準
国内が有利な場合:
- 金融・公共など規制の多いドメイン
- 韓国語・韓国文化ベースの製品
- 家族・生活基盤
- 株式 lock-up・税制で有利
グローバルが有利な場合:
- 技術・年収の上限を経験
- グローバルネットワーク
- リモート・自由度
- 多様性・文化の多様さ
第 9 章 · AI 時代でも変わらないもの
コードは AI が多く書くが、開発者の本質的価値 はむしろ際立つ。
変わらない能力
- 問題定義 — AI は解けるが、定義するのは人
- システム思考 — 全体構造を頭に収める
- 抽象化・モデリング — 複雑な現実をコード化
- コミュニケーション — チーム・ステークホルダーとの整合
- 判断・文脈 — トレードオフの決定
- 学習能力 — 新技術を受け入れる速度
- 倫理的感覚 — 技術の社会的影響
- 粘り強さ・Ownership — 最後まで仕上げる力
「10x 開発者」の再定義
- 過去: 一人で 10 人分のコードを生産
- 現在: AI・ツール・チームメイトを 10 倍に活用する人
- 未来: 10x インパクト を生む人（コード + プロダクト + ビジネス）
AI に代替されにくい領域
- 社内政治・利害関係の調整
- クリエイティブ・プロダクト感覚
- 顧客インタビュー・インサイト抽出
- 道徳的・倫理的判断
- 危機対応のリーダーシップ
仕事と生活の統合
2025 年の開発者は仕事と生活の境界がより曖昧になるが、健康なルーチン が成果を左右する。
- 睡眠・運動 はコーディング生産性の根本
- ディープワーク のための時間ブロック
- Side Project でバーンアウト予防・ポートフォリオ確保
- 家族・友人・趣味 が長期継続の鍵
第 10 章 · Season 5 回顧 — 12 章の旅
Season 5 で我々は次を見た。
- Ep 1: Lakehouse の勝利（Iceberg）
- Ep 2: ストリーミングによるリアルタイムの再定義
- Ep 3: OLAP エンジンの地形図
- Ep 4: データオーケストレーションの成熟
- Ep 5: セマンティックレイヤーとメトリックストア
- Ep 6: Vector・Graph・Time-series DB の融合
- Ep 7: ガバナンス・リネージ・PII
- Ep 8: オブザーバビリティ・OpenTelemetry・LLM Observability
- Ep 9: データ・AI チームの組織とキャリア
- Ep 10: 全社データ文化とその拡散
- Ep 11: データ・AI FinOps
- Ep 12: データセキュリティ・プライバシー
- Ep 13（本日）: AI 時代の開発者サバイバル戦略
結論: 2025 年のデータ・AI スタックは 技術・組織・コスト・セキュリティ・人 が一つの生態系として絡み合う。一軸だけ優れていても失敗する。すべてをバランスよく設計する システム思考 が必要。
第 11 章 · 2026 年への予測
- AI Agent のエンタープライズ標準化 — MCP, A2A プロトコル
- Vector・Graph DB はマルチモーダル DB に統合
- Iceberg v4・Delta 4.0 — テーブルフォーマットのさらなる収束
- Confidential Computing がデフォルト — GPU・LLM に組み込み
- EU AI Act・韓国 AI 基本法の完全施行 → 高リスク AI 監査義務
- 開発者需要は増加、ジュニアは減少 → 中間層ポジションの再構造化
- 韓国の技術ブログ生態系の成長 — 英語化の加速
- リモート採用の正常化（Return-to-Office の一部巻き戻し）
- 「AI-Native スタートアップ」の爆発（1-3 人チームが $10M ARR）
- オープンソースと商用の境界の再設定 — Business Source License の主流化
第 12 章 · 次シーズン予告 — Season 6: 「フロントエンド・デザインシステム・ウェブプラットフォームの現在」
Season 5 がバックエンド・データ・AI 中心だったのに対し、Season 6 は 目に見えるレイヤー。2025-2026 年フロントエンドの現在地。
- React Server Components 定着以後のフロントエンド
- Next.js・Remix・SvelteKit・SolidStart・Astro の選択
- デザインシステムとトークン（Radix・shadcn・Chakra・Tamagui・DaisyUI）
- AI-native UI パターン（Generative UI, Streaming, Feedback）
- Motion・Animation の新時代（Motion One, Framer Motion, View Transitions API）
- ウェブプラットフォーム Container Queries・CSS Nesting・
:has() - Edge Runtime・View Transitions・Popover API
- アクセシビリティ（Accessibility）の実戦
- 国際化・多言語（i18n）・韓国語タイポグラフィ
- パフォーマンス計測・Core Web Vitals・Real-user Monitoring
- フロントエンドエンジニアのキャリア（Product Engineer の流れ）
- モバイル・デスクトップのクロスプラットフォーム（React Native・Expo・Tauri・Flutter）
「バックエンドが見えない骨なら、フロントエンドはユーザーが触れる肌だ。」
Season 6 で会おう。
エピローグ · チェックリスト 12（個人用）
- 自分は 最低 1 つの AI コーディングツール を日常で使いこなしているか?
- Context Engineering の 5 つの軸を理解しているか?
- 自分の GitHub・ブログ・ポートフォリオ はここ 6 ヶ月で更新されているか?
- ここ 6 ヶ月に オープンソース貢献 または サイドプロジェクト があるか?
- 英語コミュニケーション は職場で実戦利用できる水準か?
- システムデザイン面接 への準備はできているか?
- ドメイン専門性（コマース・金融・AI 等）を一つ深く持っているか?
- 睡眠・運動・ディープワーク のルーチンが確立されているか?
- 学習パイプライン（読書・コース・カンファレンス）が運用されているか?
- ここ 1 年で 技術以外の能力（プロダクト・ビジネス・リーダーシップ）に投資したか?
- 1 年・3 年・10 年のキャリアビジョン は文書化されているか?
- 自分の 10x インパクト（コード以外の影響）を測定できるか?
「技術は変わっても原則は残る: 好奇心・誠実さ・他者への敬意・自分だけの基準。」
どれだけツールが発展しても、結局作るのは人だ。
— Season 5 Finale, そして Season 6 の始まり。
読者の皆様、Season 5 を最後までお付き合いいただきありがとうございました。 次のシーズンでまたお会いしましょう。
— Fin.