書けなくていい。会議で使える知識を持つ。
一言で言うと：「JavaScriptの信頼できる版。Webの実質標準語」
得意な用途：Webフロントエンド・Node.jsサーバー・MCPサーバー・CLIツール・フルスタック開発
選ぶ理由：フロントとバックを同じ言語で書けるためチームの認知コストが下がる。型エラーでバグを事前検出。Webサービス開発では現実的に最有力。
選ばない理由：小さなスクリプトや自動化ツールにはオーバーキル。AIモデル推論など計算集約タスクはPythonの方が圧倒的にライブラリが充実。
さらに詳しく →一言で言うと：「速い・シンプル・並行処理が得意。インフラの言語」
得意な用途：高トラフィックAPIサーバー・インフラ・CLIツール・マイクロサービス・有名事例
選ぶ理由：大量リクエストを捌くAPIに最適。シングルバイナリでデプロイが楽。Rustほど難しくなく、Pythonより速い「ちょうどいい」言語。
選ばない理由：AIアプリのPoCフェーズでは選ばない。Pythonライブラリ（PyTorch等）のエコシステムに勝てない。ジェネリクスが弱く抽象的な設計が難しい場面も。
さらに詳しく →一言で言うと：「速さと安全性を両立する、最難関の言語」
得意な用途：組み込みシステム・OS開発・WebAssembly（Wasm）・ゲームエンジン・グラフィクス・暗号・セキュリティ
選ぶ理由：C/C++の置き換えとして「速くて安全」が必要な場面。メモリリークやバッファオーバーフローをコンパイル時に防げる。長期運用するシステムの信頼性が上がる。
選ばない理由：Web・AI案件のPoCには絶対に向かない。所有権・借用の概念習得に数ヶ月必要。チームにRustが書ける人材を確保することが難しい。
さらに詳しく →一言で言うと：「データを取り出す・集計する・更新するための専用言語」
得意な用途：SELECT（取得）・JOIN（結合）・INDEX（インデックス）・トランザクション
選ぶ理由：自然言語→SQL変換ツールが増えており、生成されたSQLの妥当性を判断するには基礎理解が必須。AIが書いたSQLのレビュー（JOIN方向・インデックス不足）にも知識が必要。**pgvector**のようにPostgreSQLでベクトル検索も可能になり、SQL＋AIの組み合わせが広がっている。
さらに詳しく →一言で言うと：「人間が読みやすい言語。特にAI・データ処理の業界標準語」
得意な用途：機械学習・深層学習・LLMアプリ開発・データ分析・可視化・Web API・自動化スクリプト
選ぶ理由：AI・機械学習のエコシステムがPythonに一極集中。PoCフェーズでのスピードが最速。書きやすく読みやすいためチームへの展開も容易。
選ばない理由：**高トラフィックAPI**（毎秒数万リクエスト超）はGoやRustが有利。**組み込みシステム**にはメモリ効率が悪すぎる。
さらに詳しく →一言で言うと：「1995年生まれ・30年超動いた王道の言語。Write Once, Run Anywhere の原典」
得意な用途：エンタープライズWeb（Spring Boot）・Androidアプリ（既存資産）・大規模基幹システム・ビッグデータ・分散処理・クラウドネイティブ（Quarkus / Micronaut）
選ぶ理由：エコシステムが完成しすぎており、ライブラリ・フレームワーク・情報・人材が豊富。**大規模基幹・ミッションクリティカル**は依然としてJava一択。JVM上で動く**Scala/Kotlin/Clojure** など他言語への布石にもなり、新技術（Virtual Threads・GraalVM）も継続投入されている。
選ばない理由：記法が冗長（getter/setter・例外チェック・型宣言）でコード量が多い。**学習コストが高く、軽量スクリプトには過剰**。起動が比較的遅い（GraalVM ネイティブビルドで改善可）。コンテナとの相性でCold Start に課題が出る場面もある。
さらに詳しく →一言で言うと：「26年進化するMicrosoft主力言語。.NET・Unity・Azureを縦断」
得意な用途：Web API（ASP.NET Core）・ゲーム開発（Unity）・クラウド / Azure 連携・デスクトップ・モバイル（.NET MAUI）・CLI / Worker Service / IoT
選ぶ理由：**Microsoft エコシステム（.NET・Azure・Visual Studio・Unity）との統合度が最強クラス**。ASP.NET Core は TechEmpower ベンチマークで常に最上位。**Nullable Reference Types** による null 安全性・**async/await** の言語サポート・**LINQ** の表現力・**record 型** の簡潔さはモダンな書き心地を実現。Unity 公式・Azure ファーストクラス採用・NativeAOT で起動高速。Visual Studio のデバッグ体験は業界屈指。
選ばない理由：**Microsoft エコシステム外**では .NET の恩恵が薄く、Linux サーバ運用は依然 Java/Go/Rust に劣る場面も。**.NET Framework（Windows のみ）は廃止予定**で新規採用不可、**.NET 8 以降**を選ぶ必要。Mono は歴史あるが .NET 主流への移行が推奨。学習コストは中程度（Java/C++ 経験者には馴染みやすい）。
さらに詳しく →一言で言うと：「37年動いたUnix/Linuxの標準シェル。サーバー運用とデプロイの共通語」
得意な用途：サーバー運用自動化（systemd・cron）・CI/CD パイプライン（Harness / GitHub Actions / GitLab CI）・デプロイ・ビルドスクリプト・ログ集計・テキスト処理パイプライン・開発環境セットアップスクリプト
選ぶ理由：**Unix/Linux のデフォルトシェル**で、サーバー運用・CI/CD・Docker・systemd の**共通語**として外せない。**POSIX シェル標準にほぼ準拠**しつつ、配列・`[[ ]]`・プロセス置換等の実用拡張も持つ。**テキスト処理パイプライン**（grep/awk/sed/jq）はパイプで簡潔に書け、ログ集計やアクセス解析では最速クラス。`set -euo pipefail` と **ShellCheck** で堅牢化も可能。`#!/usr/bin/env bash` のシバン1行で即スクリプト化できる学習コストの低さも強み。
選ばない理由：**大規模アプリケーション本体には不向き**（数百行を超えると保守が困難になり、Python/Go へ移行すべき）。**シェル展開・単語分割・引用**のルールが独特で、`$VAR` と `$VAR "` の違いを誤ると**セキュリティ脆弱性**（コマンドインジェクション）に直結する。**Windows サポートは WSL / Git Bash 経由のみ**で、ネイティブ実行は不可。**対話シェルとしての完成度は zsh / fish に劣る**ため、補完・プロンプトを凝りたい用途には向かない。
さらに詳しく →一言で言うと：「15年動いたモダンJVM。Javaの冗長さを解消し、Android公式となった」
得意な用途：Androidアプリ（現行公式）・サーバーサイド（Ktor / Spring Boot）・Kotlin Multiplatform（iOS / JS / Desktop 共有コード）・CLI / ツール（Kotlin Script）・data class を多用する業務システム
選ぶ理由：**Java の上位互換**として設計され、既存の Java ライブラリ・フレームワーク（Spring・Hibernate 等）を**そのまま呼べる**。**Null安全**（コンパイル時に NullPointerException を検出）・**data class**（equals/hashCode/toString 自動生成）・**拡張関数**（既存クラスの拡張）・**Coroutines**（軽量スレッド・構造化並行性）・**when式**（スマートキャスト付きのパターンマッチ）など、モダン言語機能を**後付けなし**で備えている。**Android の現行公式言語**（Kotlin-first）で、Jetpack Compose・KMP（iOS/Desktop 共有）と組み合わせれば**モバイル・サーバー・デスクトップを単一言語で統一**できる。**K2 コンパイラ**（Kotlin 2.0）でビルド速度も改善済み。
選ばない理由：**ビルドツール Gradle の重さ**が依然課題（特に Android プロジェクトで初回ビルドが数分）。**学習コストは中**だが、Java に無い概念（拡張関数・スコープ関数・sealed class・inline reified 等）が複数あり、**Java も Kotlin も読めないメンバーには導入コスト**がかかる。**Kotlin 固有機能（拡張関数・演算子オーバーロード・DSL）を多用**すると Java 側から見ると**読みづらく**なる（相互運用時の注意）。**コンパイル時間が Java より長い**ケースがあり、大規模プロジェクトの CI 高速化では課題。
さらに詳しく →各言語の6軸評価（実行速度 / AI&ML / 学習容易さ / 型安全性 / フロント対応 / スケーラビリティ）
何ができるか：文章生成・要約・翻訳・コード生成・質問応答。会話形式で指示できる。
主要モデル：GPT-4o（OpenAI）/ Claude 3.5 Sonnet（Anthropic）/ Gemini（Google）/ GLM（Z.AI）
選び方のポイント：用途・コスト・レイテンシ・コンテキスト長で選ぶ。「全部GPT」は最適ではない。
限界：学習データのカットオフ日より新しい情報は知らない（→RAGで補完）。長い文章は末尾を忘れがち。
何をするか：汎用LLMに自社データ・ドメイン知識を追加学習させ、特定タスクの精度を上げる。
必要なもの：大量の教師データ（入力→正解出力のペア）＋GPU計算コスト＋MLエンジニア
いつ選ぶか：プロンプトだけでは精度が出ない時・特定の口調や形式を学習させたい時
いつ選ばないか：まずRAGやプロンプトエンジニアリングで試す。Fine-tuningは最終手段に近い。コストが高い。
仕組み：①ユーザーの質問を受け取る → ②関連ドキュメントをベクトルDBで検索 → ③LLMに質問＋ドキュメントを一緒に渡して回答させる
なぜ使うか：LLMは学習データにない情報（社内文書・最新情報）を知らない。RAGで「今この文書を見ながら答えて」ができる。
ハルシネーション対策：根拠となる文書を渡すことで嘘をつく確率を下げられる。
何をするか：「東京」「Japan's capital」「首都」→ 似た数値ベクトルに変換。意味が近い文章は数値も近くなる。
用途：類似文章検索・RAGの「関連文書を探す」部分・レコメンドエンジン
主要サービス：OpenAI text-embedding-3 / Cohere Embed / Google Vertex AI Embeddings
主要テクニック：
• Few-shot：「例を3つ見せてから本番指示」→ 精度向上
• Chain-of-Thought：「ステップごとに考えて」→ 複雑な推論に有効
• System prompt：「あなたは○○の専門家です」→ キャラクター・制約を設定
• Few-shot + CoT：両方組み合わせると最強
重要な考え方：Fine-tuningの前に必ずプロンプトで試す。コストがゼロで改善できる。
通常のLLMとの違い：LLMは「返答するだけ」。エージェントは「ツールを使いながら自律的に行動する」。
例：「最新のニュースをまとめてSlackに送って」→ Web検索ツール → まとめ生成 → Slack送信ツール を自動で使う
主要フレームワーク：LangChainLLMを使ったアプリを素早く組み立てるPython/TSライブラリ。RAG・エージェント機能を提供 / LlamaIndex / OpenAI Assistants / Claude + MCP
課題：ループ・無限実行・コスト暴走のリスク。品質ゲートと予算上限が必須。
何をするか：Claude / Cursorなどのエージェントが外部サービス（GitHub・Slack・DB等）を統一した形式で呼び出せるようにする規格。
USB-Cのような存在：「どのAIでも、どのツールにも繋げられる標準端子」
サーバー側：ツール提供者がMCPサーバーを実装（Python or TypeScript）
クライアント側：Claude Code / Cursor / Continue等が自動でツールを呼び出す
通常のDBとの違い：通常のDBは「完全一致・条件一致」で検索。ベクトルDBは「意味が近い順」で検索できる。
主要サービス：Pinecone（クラウド）/ Chroma（ローカル・軽量）/ Weaviate / pgvector（PostgreSQL拡張）
使われる場面：RAGの文書検索・類似商品検索・重複検知
| 方式 | メリット | デメリット | 向いてる用途 |
|---|---|---|---|
| サーバーレス （Lambda等） |
管理ゼロ 使った分だけ課金 |
コールドスタート 実行時間上限 |
イベント駆動・軽量API |
| コンテナ （Docker/ECS） |
環境再現性◎ 柔軟 |
オーケストレーション学習コスト | Webアプリ・マイクロサービス |
| VM （EC2等） |
自由度最高 長期稼働に強い |
管理コスト高 起動が遅い |
フル制御が必要な場面 |
何を解決するか：「自分のPCでは動くのに本番で動かない」問題。アプリと依存関係を箱（コンテナ）に詰めて、どこでも同じ動作を保証。
Dockerfile：コンテナの設計図。「このOSにこれをインストールしてこのコマンドで起動」を定義。
docker-compose：複数コンテナ（アプリ＋DB＋Redis等）をまとめて管理するツール。
Dockerとの違い：Dockerは「1台のコンテナを動かす」。K8sは「100台のコンテナを自動管理する」。
できること：コンテナの自動スケール・障害時の自動再起動・ローリングアップデート
いつ必要か：大規模サービス（数十台以上）になってから。小規模PoCには不要。
| サービス | 一言説明 | よく使う場面 |
|---|---|---|
| Lambda | サーバーレス関数実行 | APIエンドポイント・イベント処理 |
| S3 | ファイルストレージ | 画像・動画・ログの保存 |
| RDS | マネージドDB（PostgreSQL等） | 本番DBの定番 |
| ECS | Dockerコンテナ管理 | Webアプリのコンテナ実行 |
| Bedrock | AWS上でLLMを使う | Claude/Llama等をAPI経由で利用 |
| API Gateway | APIの入り口管理 | 認証・レート制限・ルーティング |
| サービス | 一言説明 |
|---|---|
| Cloud Run | コンテナをサーバーレスで実行（AWSのLambda＋ECSの中間） |
| BigQuery | 超高速な大規模データ分析専用DB |
| Vertex AI | GeminiなどのLLM・MLモデルをAPIで提供 |
| Cloud Storage | S3相当のファイルストレージ |
CI（継続的インテグレーション）：コードをpushするたびに自動でテストを実行。壊れた変更を早期発見。
CD（継続的デリバリー）：テストが通ったら自動で本番環境にデプロイ。人手を介さない。
主要ツール：GitHub Actions（最も普及）/ CircleCI / Jenkins
目的：「本当にこの技術で解決できるか？」を少ないコストで確かめること。本番品質は求めない。
PoCで問われること：技術的実現性・コスト・精度・ユーザー受容性
PoC→本番のよくある落とし穴：「PoCは動いたが本番スケールに耐えられない」「精度90%で合格したが本番データでは70%」
今の自分との関連：アサイン・GNUS等の案件はPoCフェーズが多い。「完璧でなくていい・速さが正義」の段階。
PoCとの違い：PoCは「技術の検証」。MVPは「ユーザーに使ってもらって価値を検証するプロダクト」。
原則：機能を削りに削って、コアバリューだけを届ける最小単位で出す。
よくある失敗：「あれもこれも実装してからリリース」→ 時間と資金が尽きる。
スプリント：1〜2週間の開発サイクル。期間内にやることを事前に決め、終わったらレビュー→次のスプリントへ。
デイリースタンドアップ：毎朝15分の進捗共有。「昨日やったこと・今日やること・詰まってること」を共有。
ウォーターフォールとの違い：ウォーターフォールは「全部設計→全部実装→全部テスト」。アジャイルは「小さく作って小さく届ける」。
バックログ：未着手タスクの一覧。優先度順に並べてスプリントで消化していく。
| モノリス | マイクロサービス | |
|---|---|---|
| 構造 | 1つのアプリに全機能 | 機能ごとに独立したサービス群 |
| メリット | シンプル・開発が速い | スケールしやすい・障害が分離 |
| デメリット | 大きくなると管理困難 | 運用複雑・通信コスト |
| 向いてる規模 | スタートアップ・PoC | 大規模・チーム分割時 |
💡 「最初はモノリスで作って、スケールしてから分割」が鉄則。最初からマイクロサービスは過剰設計になりがち。
| 方式 | 特徴 | 向いてる場面 |
|---|---|---|
| REST | URL＋HTTP動詞。最も普及 | Webアプリ・公開API |
| GraphQL | 必要なデータだけ取得できる | モバイルアプリ・複雑なデータ取得 |
| gRPC | 高速・型安全。サービス間通信向け | マイクロサービス同士の内部通信 |
💡 迷ったらREST。GraphQL/gRPCは必要になってから検討。
認証（Authentication）：「あなたは誰ですか？」→ ログイン・本人確認
認可（Authorization）：「あなたには何の権限がありますか？」→ 管理者/一般ユーザーの分岐
JWT（JSON Web Token）：ログイン後にサーバーが発行するトークン。次のリクエストに添付して「認証済み」を証明。
OAuth2：「Googleでログイン」「GitHubでログイン」の仕組み。自分でパスワード管理しなくていい。
何が起きるか：フロント（localhost:3000）がバックエンド（localhost:8000）を呼ぶと、ブラウザがブロックする。
なぜ存在するか：悪意あるサイトが別サイトのAPIを勝手に呼び出すのを防ぐセキュリティ機能。
解決方法：サーバー側のレスポンスヘッダーに「このオリジンからのアクセスは許可」と明示する。
会議で出たら：「バックエンドのCORS設定で許可するオリジンを追加する必要があります」で通じる。
スプリント：1〜2週間の開発サイクル。期間内にやることを確定させ、終わりにデモ＆振り返りを実施。
プロダクトオーナー（PO）：何を作るかを決める役割。ビジネス側の代表者。バックログの優先順位付けをする。
スクラムマスター：チームがスクラムを正しく回せるよう支援する役割。マネージャーではなくファシリテーター。
スプリントレビュー：スプリント終了時にステークホルダーへのデモ。「動くものを見せる」が原則。
レトロスペクティブ（振り返り）：スプリント後にチームで「良かったこと・改善すること」を議論。プロセス改善の核心。
何が問題か：「今急いで作った粗雑なコード」は金融の負債と同様に利息が増える。放置するほど修正コストが膨らむ。
具体例：テストのないコード・ドキュメントのない関数・将来拡張を考慮しないDB設計・古いライブラリの放置
なぜ生まれるか：締め切り優先・人手不足・「後でやろう」の先送り文化
対策：リファクタリングの時間をスプリントに組み込む。テックデット専用スプリントを設ける。SonarQubeなどのコード品質計測ツールを使う。
ベロシティ：スプリントごとに完了したストーリーポイントの平均値。チームの処理能力の目安。「このチームは1スプリントで30ポイントこなせる」。
ストーリーポイント：タスクの複雑さ・リスクを数値化したもの（時間ではなく相対的な難易度）。フィボナッチ数列（1,2,3,5,8,13…）で表すことが多い。
バーンダウンチャート：残タスクが期限に向けて減っていくグラフ。理想ラインより上にあれば遅延のサイン。
注意：ベロシティはチームの生産性を外部から評価する指標ではない。チーム自身のキャパシティ把握と計画精度向上が目的。
SLA（Service Level Agreement）：契約上の約束。「月間稼働率99.9%を保証する。下回ったら返金」。ユーザー・クライアントとの合意。
SLO（Service Level Objective）：内部目標値。「稼働率99.95%を目指す」。SLAより高い目標を社内で設定するのが一般的。
SLI（Service Level Indicator）：実際の測定値。「今月の稼働率は99.97%だった」。
エラーバジェット：SLOとの差分。「99.95%目標なら月0.05%=21.6分まで停止してよい」。このバジェット内で新機能リリースリスクを管理する。
なぜ必要か：コードは書いた後も「読まれる・変更される・テストされる」。保守性の低いコードは変更コストが指数的に増加する。
代表的なリファクタリング手法：
• 関数の抽出：長い関数を小さな関数に分割
• 変数名の改善：x→userEmailAddressなど意味のある名前に
• 重複の除去：同じ処理を共通関数にまとめる（DRY原則）
テストがない状態でのリファクタリングは危険：動作が壊れても気づけない。テスト整備→リファクタリングの順が鉄則。