Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

プロローグ · 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.