はじめに
最近、未経験からエンジニアを目指している人に教える機会があって、最初は「コーディングの基礎から教えよう」と思っていました。
でもすぐに気づいたんです。それ、もうAIがやってくれるやん。
CursorやChatGPTに聞けばコードは出てくる。じゃあ俺はこの人に何を教えるんや？——正直、かなり悩みました。
私はデビューした頃AtCoderやPaizaを解きまくってたのですが、それにどれだけ価値があるのか。
ただ、一緒に学習を進めるうちに見えてきたのは、AIにコードを書かせること自体は誰でもできるけど、「何を聞くか」「出てきたものが正しいか判断する力」がないと一瞬で詰まるということでした。エラーが出ても読めない、構成がわからないからどこを直せばいいかもわからない、そもそもAIに何を伝えればいいかがわからない。
つまりコードを書く力ではなく、コードの周辺にある判断力——これが今、人間が持っておくべき力なんだと思います。
この記事では、私が「最低限これだけ知っていればAIをちゃんと武器にできる」と感じる知識をまとめました。完璧に理解しなくていい。この記事を地図にして、AIと一緒に成長するブースターにしてもらえたら嬉しいです。
全体マップ
1. エディタ・ターミナル操作
2. Git（バージョン管理）
3. デバッグ・エラー対処
4. アプリの構成を理解する（Docker / API / DB / CI/CD / テスト）
5. 設計（mermaid）
6. デザインの参考にする
7. クラウドにデプロイする（AWS）
8. セキュリティの暗黙知
9. AIツールとの付き合い方
10. 技術情報のキャッチアップ
1. エディタ・ターミナル操作
ショートカット（エディタ）
地味ですが、これを知っているかどうかで作業速度が体感3倍変わります。
| ショートカット | 意味 |
|---|---|
Cmd + A |
全選択 |
Cmd + C |
コピー |
Cmd + V |
貼り付け |
Cmd + F |
現在のファイル内を検索 |
Cmd + P |
ファイル名で素早くファイルを開く |
Cmd + Shift + F |
プロジェクト全体をgrep検索 |
特に Cmd + Shift + F（全体grep） は毎日使います。「このAPIどこで定義してたっけ？」「この変数どこで使われてる？」が一瞬で解決できます。
もう一つ、エディタではなくMacの操作ですが Cmd + Ctrl + Shift + 4 も毎日使います。選択範囲のスクリーンショットがクリップボードにコピーされるので、そのまま Cmd + V でSlackやGitHubのIssueに貼り付けられます。エラー画面の共有やUIの確認で重宝するので、覚えておいて損はないです。
（とはいえ最近はPlaywrightでスクリーンショットを自動取得する場面も増えてきたので、手動で撮る頻度は少し減りました。ただ、ちょっとした確認やチャットでの共有にはやっぱりこれが一番速いです。）
AI時代の使い方：Cursorなら「このエラーメッセージが出てる箇所を全部見せて」と自然言語で聞けます。ただgrep的な思考がないと質問すらできないので、感覚だけは掴んでおきましょう。
ショートカット（ターミナル）
エディタと同じくらい、ターミナルを素早く操作できるかどうかで作業効率が変わります。
| ショートカット | 意味 |
|---|---|
Ctrl + R |
過去に打ったコマンドをインクリメンタル検索 |
Ctrl + ← / Ctrl + →
|
単語単位でカーソル移動 |
Ctrl + A |
行の先頭に移動 |
Ctrl + E |
行の末尾に移動 |
Ctrl + R は知らないと損します。「あのコマンド何だったっけ」と毎回打ち直す必要がなくなります。
Tips：ターミナルに長いエラーが出たとき、
Cmd + A→Cmd + CでまるごとコピーしてAIに貼り付けるとデバッグが一気に楽になります。
クリップボード履歴ツール（Raycast）を入れる
Windowsには標準でクリップボード履歴（Win + V）がありますが、Macには標準搭載されていません。そこでおすすめなのが Raycast です。無料で使えて、コピーした内容を履歴として保持・検索できます。
開発中は「さっきコピーしたあのコマンドどこいった」が頻繁に起きるので、入れておくだけで地味にストレスが激減します。クリップボード履歴以外にもアプリ起動・スニペット管理など多機能なので、Mac使いのエンジニアにはほぼ必須ツールです。
拡張機能を積極的に入れる
VSCodeやCursorは拡張機能で育てるエディタです。最初から入れておくと学習効率が上がります。
| 拡張機能 | 役割 |
|---|---|
| ESLint | JS/TSのコード品質チェック。バグの芽を自動で検出 |
| Prettier | コードを自動整形。チームで書き方を統一できる |
| GitLens | 「この行を誰がいつ書いたか」をその場で確認できる |
| Git Graph | ブランチの状態をビジュアルで確認 |
| Thunder Client | VSCode内でAPIリクエストを送れる（Postman不要） |
| Docker | Dockerコンテナの状態管理をGUI操作 |
| Mermaid Preview | mermaidの図をリアルタイムでプレビュー |
| indent-rainbow | インデントを色分けして構造を視覚化 |
| Error Lens | エラーをその行の横にインライン表示 |
Cursorユーザーへ：CursorはVSCodeと拡張機能の互換性があるので、同じものがそのまま使えます。
2. Git（バージョン管理）
チーム開発でも個人開発でも、Gitは空気のような存在です。最低限これだけ覚えてください。
基本操作
git add . # 変更をステージング
git commit -m "" # 変更を記録
git push # リモートに反映
git checkout -b # ブランチを切って作業
git merge # ブランチを統合
git stash # 作業を一時退避
git reset --soft # コミットを取り消す（変更は残す）
コンフリクト解消フロー
チーム開発で必ず起きるのがコンフリクト（衝突）です。
1. git merge でコンフリクト発生
2. VSCode/Cursorで該当ファイルを開く
3. <<<<<<< と >>>>>>> の間を読んで、残すべきコードを選択
4. git add → git commit で解消完了
AI時代の使い方：コンフリクト内容をそのままCursorに貼り付けて「どちらを残すべきか説明して」と聞くと、文脈を踏まえた判断をしてくれます。
3. デバッグ・エラー対処
エラーが読める人と読めない人では、成長速度がかなり違います。
確認する場所の優先順位
① ターミナルのエラーログ
サーバー側のエラーはここに出ます。エラー文をそのままコピーしてAIに投げるだけで解決することも多いです。
② ブラウザの検証ツール（DevTools）
-
Consoleタブ：JSのエラー・警告
-
Networkタブ：APIのリクエスト/レスポンスを確認。ステータスコード（200/400/500）を見る習慣をつける
③ ログファイル
本番環境ではターミナルが見えないので、ログファイルを読む力が必要です。
デバッグのフロー
エラー発生
↓
エラーメッセージを読む（どのファイルの何行目か）
↓
Networkタブでリクエスト/レスポンスを確認
↓
まだわからなければAIに投げる（エラー全文＋関連コードを貼る）
↓
修正して動作確認
AIへの質問精度を上げるコツ：エラー文だけ渡しても精度が低いです。関連するコードも一緒に渡しましょう。文脈があるかどうかで回答の質がまるで変わります。
4. アプリの構成を理解する
「アプリがどういう部品で動いているか」を理解することが、設計・デバッグ・AIとの会話すべての土台になります。
Dockerで環境を統一する
docker-compose.yml で定義するもの：
┌─────────────┐
│ フロントエンド │ ← React など
├─────────────┤
│ バックエンドAPI │ ← Node.js / Python など
├─────────────┤
│ DB（MySQL） │ ← データの永続化
├─────────────┤
│ Redis │ ← キャッシュ・セッション管理
└─────────────┘
DockerfileとDocker Composeを使うと、「自分のPCでは動くのに本番では動かない」問題がなくなります。
フレームワークとnode_modulesの正体
素のJavaScriptやPythonでWebアプリを作ろうとすると、本質的な機能を作る前に「インフラ的なコード」を大量に書く必要があります。フレームワークはその土台をあらかじめ用意してくれているものです。
| フレームワーク | 言語 | 特徴 |
|---|---|---|
| Express | Node.js | 軽量・柔軟。自由度が高い |
| Next.js | React/Node.js | フロントとバックが1つに。今最も使われている |
| FastAPI | Python | 型安全・高速。AI系と相性が良い |
またnpm installを実行すると、1つのライブラリが別のライブラリに依存しているため、芋づる式に大量のコードがインストールされます。これがnode_modulesが数百MBになる理由です。
鉄則：node_modulesは
.gitignoreに追加してGitにコミットしないこと。他の人がnpm installすれば同じ環境が再現できます。
TODOアプリで学ぶべき概念
シンプルなTODOアプリ1つを作るだけで、実務で必要な概念のほとんどが学べます。
| 概念 | 内容 |
|---|---|
| REST API | フロントとバックエンドの通信規則 |
| CRUD | Create / Read / Update / Delete |
| WebSocket | リアルタイム通信（チャット・通知など） |
| JWT認証 | ログイン・セッション管理の仕組み（後述） |
| MVC | コードを役割ごとに分ける基本構造 |
JWT認証の仕組みをTODOアプリで実装する
認証は「なんとなく動く」で済ませがちですが、仕組みを理解しているかどうかが実務で大きく差が出るポイントです。
① ユーザーがメール・パスワードでログイン
② サーバーがDBでユーザーを検索・パスワード照合
③ 一致したらJWTトークンを生成してフロントに返す
④ フロントはトークンをHttpOnly Cookieに保存
（localStorageはXSS攻撃で盗まれるリスクがあるため非推奨）
⑤ 以降のリクエストはヘッダーに Bearer トークン を付けて送る
⑥ サーバーはトークンを検証してユーザーを識別する
| エンドポイント | 役割 |
|---|---|
POST /auth/register |
ユーザー登録（パスワードはbcryptでハッシュ化） |
POST /auth/login |
ログイン・JWTトークン発行 |
GET /todos |
認証ミドルウェアを通過したユーザーのみ取得可能 |
セキュリティの基本：パスワードは絶対に平文でDBに保存しないこと。
bcryptでハッシュ化するのが基本です。「なんとなく動く」実装がセキュリティホールになるのが認証周りです。
アーキテクチャ（DDD・クリーンアーキテクチャ）
最初は「なんとなく知っている」程度でOKです。ただなぜ設計が必要かは押さえておきましょう。
コードが増えるにつれて「どこに何を書けばいいか」が曖昧になり、バグが増え、修正のたびに別の場所が壊れるようになります。それを防ぐのがアーキテクチャの役割です。
CI/CD（GitHub Actions）
「pushしたら自動でテスト・デプロイが走る」仕組みです。チーム開発では今やほぼ標準装備です。
開発者がコードをpush
↓
GitHub Actionsが自動で起動
↓
① テストを自動実行（失敗したらマージできない）
② Lintチェック（コードの書き方が正しいか）
③ mainブランチへのマージ後、本番環境へ自動デプロイ
# .github/workflows/ci.yml
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
- run: npm ci
- run: npm test
「自分のPCでは動いた」が通用しなくなるのがチーム開発です。CI/CDがあれば、バグのあるコードが本番に入ることをシステム的に防げます。
テストの考え方
未経験者が最も後回しにしがちで、かつ「書けると評価が上がる」のがテストです。完璧に書けなくてOKです。ただなぜ書くのかだけは理解しておきましょう。
テストなし：
機能を追加 → 「なんか動いてそう」 → リリース → 別の場所が壊れる → 原因不明
テストあり：
機能を追加 → テスト実行 → どこが壊れたか一瞬でわかる → 安心してリリース
| 種類 | 内容 |
|---|---|
| 単体テスト（Unit Test） | 関数1つが正しく動くかを確認 |
| 統合テスト（Integration Test） | APIエンドポイントが正しく動くかを確認 |
AI時代の使い方：「このコードの単体テストをJestで書いて」とCursorに投げると雛形を出してくれます。テストが読めると、AIの生成コードの品質チェックもできるようになります。
5. 設計：mermaidでフローを可視化する
AIと一緒に開発するなら、設計図をテキストで書ける力が非常に重要です。
Mermaid はMarkdownで図を書ける記法で、GitHubやNotionでそのまま表示されます。
AI時代の使い方：「このシーケンス図を元にAPIを実装して」とCursorに投げると、設計通りのコードを生成してくれます。設計を言語化できる人はAIの活用精度が格段に上がります。
6. デザインの参考にする
コードが書けるようになってくると、次に詰まるのがデザインです。ゼロから考えようとすると沼にハマるので、まずは大手が公開しているデザインガイドラインを参考にするのが一番の近道です。
| リソース | 概要 |
|---|---|
| Google Material Design | Googleが公開しているデザインシステム。色・余白・コンポーネントの使い方が体系的にまとまっている |
| Apple Human Interface Guidelines | Appleのデザイン思想が詰まったガイドライン。iOSに限らずUIの考え方として普遍的に参考になる |
「なんかダサい」「余白がおかしい」と感じたときにこれらを眺めると、理由と改善策がわかることが多いです。コードを書く人間でもデザインの基本を知っているかどうかで、作るものの完成度がかなり変わります。
AI時代の使い方：正直なところ、実務レベルのUIであればClaudeのSkills機能（Frontend Designなど）に任せるだけでかなりいい感じに仕上がります。ただ、AIが出してきたデザインに対して「これ微妙じゃない？」と判断できるかどうかは、上記のガイドラインを一度でも眺めたことがあるかで変わってきます。
7. クラウドにデプロイする（AWS）
ローカルで動くアプリを世界に公開するのがデプロイです。AWSの主要サービスだけ押さえておきましょう。
| サービス | 役割 |
|---|---|
| EC2 | 仮想サーバー。アプリを動かす |
| ECS / ECR | Dockerコンテナの実行・管理 |
| Lambda | サーバーレス関数。サーバーを常時起動せず処理を実行できる |
| S3 | 画像・ファイルの保存 |
| ALB | ロードバランサー。トラフィックを分散 |
| WAF | Webアプリへの攻撃を防ぐ |
| Amplify | フロントエンドの簡単デプロイ |
最初は AmplifyでフロントをデプロイしてEC2でAPIを動かす 構成から始めると理解しやすいです。
インフラをコードで管理する（Terraform）
AWSのリソースをGUIのコンソールからポチポチ作るのは最初はわかりやすいですが、構成が複雑になると「どこに何を作ったか」が管理しきれなくなります。
Terraform はインフラの構成をコードで定義・管理できるツールです（Infrastructure as Code）。
# EC2インスタンスを定義する例
resource "aws_instance" "app" {
ami = "ami-xxxxxxxx"
instance_type = "t3.micro"
}
コードで管理することで以下のメリットがあります。
- 同じ構成を何度でも再現できる
- 変更履歴をGitで管理できる
- 本番と検証環境を同じ構成で立ち上げられる
最初は手動でAWSを触って感覚を掴み、慣れてきたらTerraformに移行するのがおすすめです。
8. セキュリティの暗黙知
技術書にはあまり載っていないけど、実務では当たり前のように意識していること。認証まわりの開発を何度かやってきて、これを知らずに実装すると後で痛い目を見ると感じている項目をまとめます。
秘密鍵・環境変数の扱い
秘密鍵の扱いにはとにかく気をつけてください。 これは何度強調してもしすぎることはないです。
- APIキー・DBのパスワード・JWTの署名鍵などは必ず
.envファイルで管理する -
.envは絶対にGitにコミットしない（.gitignoreに追加する） - GitHubに一度でもpushしてしまったら、そのキーは即座に無効化・再発行する
# .gitignore に必ず追加する
.env
.env.local
.env.production
よくある事故：「ちょっとテストで使っただけ」とベタ書きしたAPIキーをpushしてしまい、数分後にAWSの請求が数十万円になる——これは実際に起きている話です。
JWTと署名鍵
JWTはトークン自体をデコードすれば中身（ユーザーIDなど）は誰でも読めます。ただし署名鍵がなければ改ざんはできないという仕組みです。
つまり署名鍵が漏れると、攻撃者が任意のユーザーになりすましたトークンを生成できてしまいます。JWTを使う場合、署名鍵の管理は最重要事項です。
localStorage・sessionStorageに保存するデータに気をつける
localStorageやsessionStorageはJavaScriptから自由に読み書きできます。つまりXSS攻撃が成立した瞬間に中身が全部盗まれるリスクがあります。
- JWTトークン → HttpOnly Cookieに保存（JavaScriptから読めない）
- localStorage → ユーザーの設定やUIの状態など、漏れても問題ないデータのみ
XSSとCSRFについて
XSS（クロスサイトスクリプティング）：悪意のあるスクリプトをページに埋め込んで実行させる攻撃です。ReactやVueなどのモダンなFWを使っていればほぼ自動でエスケープされるので、素のHTMLにユーザー入力をそのまま展開するような実装をしなければ基本的には問題ないです。
CSRF（クロスサイトリクエストフォージェリ）：ユーザーが意図しないリクエストを別サイトから送らせる攻撃です。HttpOnly CookieでJWTを管理する場合はCookieが自動送信されるため、CSRFトークンによる検証が必要です。
フロントとAPIサーバーを分ける構成（例：app.example.com と api.example.com）について：
これらは共通の親ドメインを持つため、Cookieのコンテキストでは**「Same-Site（同サイト）」として扱われます。そのため、Cookieに Domain=example.com を指定すれば、SameSite=Lax のままでもCookieを共有でき、CSRF対策としても機能します。
一方、完全にドメインが異なる（クロスサイトな）構成では SameSite=None が必須となり、SameSiteによる防御が期待できないため、CSRFトークンによる検証が必須となります。
| 攻撃 | 対策 |
|---|---|
| XSS | FWのエスケープを信頼する・innerHTMLの直接操作を避ける |
| CSRF | CSRFトークン・SameSite Cookie属性 |
| 秘密鍵漏洩 |
.env管理・Gitにコミットしない |
| トークン盗難 | HttpOnly Cookie・localStorageに機密情報を入れない |
9. AIツールとの付き合い方
| ツール | 使い場面 |
|---|---|
| Cursor | コーディング全般・リファクタリング |
| Claude | 設計相談・長文ドキュメントの整理 |
| NotebookLM | 社内ドキュメント・仕様書の要約・Q&A |
| Gemini（Google） | ビジネスアカウントで安全に使えるチャット |
正直「その時一番良いものを使う」が答えです。半年で勢力図が変わる世界なので、特定のツールに依存しないほうがいい。ただ何をどう聞くか設計できる人間が強いのはどのツールを使っても変わりません。
10. 技術情報のキャッチアップ
エンジニアは学び続ける仕事です。でも最初から完璧にキャッチアップしようとしなくていいです。まず1つだけ習慣にしてください。
はてなブックマーク（IT）を毎日見る
はてなブックマーク > テクノロジー は、日本のエンジニアが今何に注目しているかが一目でわかります。
朝5分、ホットエントリーのタイトルだけ眺めるだけでOKです。最初は知らない単語だらけで当然で、半年続けると「あ、これ前も見た概念だ」と繋がり始めます。そこからが本当の成長です。
AI時代の使い方：気になった記事のURLをClaudeやChatGPTに貼って「未経験者向けにこの記事の要点を説明して」と聞くと、難解な技術記事でも理解できるようになります。
X（Twitter）のリスト機能を活用する
はてなブックマークが「記事単位」のキャッチアップなら、Xはリアルタイムの空気感を掴むのに向いています。
リスト機能を使って、興味のある分野を発信しているエンジニアをまとめておくと便利です。タイムラインは雑多な情報が流れてきますが、リストにしておけば技術情報だけを集中して見られます。最初は有名エンジニアを数人リストに入れるだけで十分です。
使い分けのイメージ：深く読みたい記事ははてなブックマーク、今何が熱いかの空気感はX、という感じです。
まとめ
全部を完璧に覚える必要はないし、そもそも無理です。1つを極めるより、広く浅く知っていることの方が大事だと思っています。
「なんとなく聞いたことがある」「なんとなく仕組みはわかる」——その積み重ねがAIとの会話の質を上げて、気づいたら一人で何でも作れるようになっています。
私は最初たくさん点を作るように心がけ時間が経つと線が出来て楽しかった記憶があります。
そしてもう一つ思っていることがあります。AIがコードを書けるようになった今、エンジニアの価値は「コードが書ける」だけでは差別化しづらくなっています。実際、FDE（Field Development Engineer）のような技術と顧客折衝を掛け合わせるポジションが新しく出てきていたり、ビジネスサイドとの接点を持てるエンジニアの需要は明らかに増えています。
技術力に加えて、いろんな業界の知識やドメインへの理解を持っておくことが、これからの時代はちょっとした強みになるんじゃないかと感じています。
知識が増えるほどAIをうまく使えるようになる——それは技術の知識だけじゃなく、その技術を使って何を解決するかの知識も含めて、です。