ポートフォリオの作り方

ポートフォリオのデプロイ（公開）手順と注意点

生田 陸人
監修
LuaGate エンジニア / 現役エンジニア
編集 LuaGate編集部

このレッスンで分かること

  • この記事では「ポートフォリオのデプロイ（公開）手順と注意点」を ポートフォリオ作成 の現場で使える形で整理します
  • ポートフォリオを世界に公開する → デプロイの重要性 をおさえれば、現場で迷ったときに立ち戻れる
  • 1. サービスの選択：どこでデプロイすべきか？ をおさえれば、現場で迷ったときに立ち戻れる
  • 主要なホスティング・クラウドサービス比較 をおさえれば、現場で迷ったときに立ち戻れる
  • 2. 実践的なデプロイ手順の共通フロー をおさえれば、現場で迷ったときに立ち戻れる

ポートフォリオのデプロイ（公開）手順と注意点 とは

ポートフォリオをWeb上に公開するためのデプロイ手順と注意点を徹底解説。VercelやRenderなどのサービス選びから、環境変数の管理、セキュリティ対策、CI/CDの導入まで、エンジニア採用で評価されるためのポイントを網羅しています。

ポートフォリオを世界に公開する → デプロイの重要性

プログラミング学習の集大成として制作したアプリケーション。しかし、ローカル環境（自分のPC上）で動いているだけでは、採用担当者にその成果を見せることはできません。「デプロイ（Deploy）」とは、開発したプログラムをサーバー上に配置し、誰でもアクセス可能な状態にすることを指します。

エンジニア採用において、デプロイ済みのURLが履歴書やGitHubにあることは最低条件と言っても過言ではありません。さらに、単に「公開されている」だけでなく、「どのような構成で公開されているか」「セキュリティや運用を考慮しているか」という点も、あなたの技術力を評価する重要な指標になります。本レッスンでは、最適なホスティングサービスの選び方から、具体的な手順、そしてプロとして絶対に外せない注意点を詳しく解説します。

結論先出し — デプロイは「公開」ではなく「運用の入口」です。サービス選定 → 環境変数 → ビルド → DB マイグレーションという共通フローを押さえれば、どのプラットフォームでも応用できます。

1. サービスの選択：どこでデプロイすべきか？

ポートフォリオを公開するためのプラットフォームは多岐にわたります。プロジェクトの特性（フロントエンドのみか、バックエンドも含むか）に合わせて選択しましょう。

主要なホスティング・クラウドサービス比較

サービス名適したプロジェクトメリットデメリット
Vercel / Netlifyフロントエンド（React, Next.js, Vueなど）GitHub連携が強力、高速、設定が非常に簡単基本的にフロントエンド限定（Next.jsなどは例外）
Render / Railwayフルスタック（Rails, Django, Node.jsなど）無料枠がある、DBも一緒に管理しやすい無料枠だとスリープ（起動が遅くなる）がある
AWS / GCP / Azure全般（インフラ力をアピールしたい場合）業界標準、高い拡張性、技術的評価が高い設定が難解、放置すると課金の恐れがある

おすすめの戦略を次に示す。 初学者の方が「まずは公開したい」と考えるなら、フロントエンドは Vercel、バックエンドを含む場合は Render が最もスムーズです。一方で、バックエンドエンジニアやインフラに関心がある方は、AWS（AmplifyやApp Runner、EC2など）に挑戦することで、技術的な深掘りを強力にアピールできます。

diagram (will load when visible)

2. 実践的なデプロイ手順の共通フロー

どのサービスを利用する場合でも、基本的な流れは共通しています。以下の4つのステップを意識しましょう。

ステップ1：ソースコードをGitHubにプッシュする

現代のデプロイは「GitHub連携」が主流です。ローカルの変更をGitHubのリポジトリに反映させると、自動的にデプロイが走る（CI/CD）設定にするのが一般的です。

ステップ2：環境変数（Environment Variables）の設定

【ポイント】ここが最も重要なポイントです。 データベースの接続情報や外部APIのキー（Stripe, Google Mapsなど）は、ソースコードに直接書いてはいけません。ホスティングサービスの管理画面にある「Environment Variables」セクションで設定します。

ステップ3：ビルドコマンドと実行コマンドの指定

サーバー上でアプリケーションを動かすための命令を設定します。

  • Build Commandはnpm run build や bundle install など
  • Start Commandはnpm start や rails server など

ステップ4：データベースのマイグレーション

バックエンドを含むアプリの場合、サーバー上のデータベースにテーブルを作成する必要があります。多くのPaaS（Platform as a Service）では、デプロイ時に自動で rails db:migrate などのコマンドを実行する設定が可能です。

diagram (will load when visible)

3. デプロイ時に絶対に注意すべき「セキュリティとコスト」

デプロイは「全世界に自分のコードとアプリを晒す」行為です。不備があると、思わぬ被害を招く可能性があります。

① .env ファイルを絶対にコミットしない

.env ファイルには機密情報が含まれています。必ず .gitignore に追加し、GitHub上に公開されないようにしてください。もし誤ってプッシュしてしまった場合は、単に削除するだけでなく、APIキーを無効化（ローテーション）し、GitHubの履歴からも削除する必要があります。

避けたい例

JavaScript

// 悪い例：APIキーをソースコードに直接書いている（ハードコード） const apiKey = "sk_test_51MzX...ABC"; fetch(`https://api.example.com/data?key=${apiKey}`);

良い例

JavaScript

// 良い例：環境変数から読み込むようにしている const apiKey = process.env.STRIPE_API_KEY; fetch(`https://api.example.com/data?key=${apiKey}`);

② 無料枠の制限と課金アラート

「無料で使える」と聞いて使い始めたサービスでも、アクセスが急増したり、設定を間違えたりすると課金が発生することがあります。特にAWSなどのクラウドサービスを利用する場合は、必ず「請求アラート」を設定し、一定額を超えたら通知が来るようにしましょう。

③ 独自ドメインとSSL（HTTPS）

デフォルトのドメイン（例：my-app.vercel.app）でも問題ありませんが、独自ドメインを取得して設定すると、一気にプロフェッショナルな印象になります。 また、HTTPS化（通信の暗号化）は現代のWebでは必須です。ほとんどのモダンなホスティングサービスでは自動でSSL証明書が発行されますが、必ずブラウザで「鍵マーク」が出ているか確認してください。

ここまでの要約 — 公開と同時に「秘密情報の管理」「課金監視」「HTTPS」の3点はゼロ日目に必ず仕込んでおきます。事故ってからでは取り返しがつきません。

4. 評価を高めるための「プラスアルファ」の工夫

単に「動く」だけでなく、以下の要素を盛り込むと、エンジニアとしての運用能力をアピールできます。

  • GitHub ActionsによるCI/CDの構築はコードをプッシュした際に、自動でテストが実行され、成功した場合のみデプロイされる仕組みを作ると非常に高評価です。
  • 死活監視・エラー監視の導入はSentry（エラー検知）や UptimeRobot（死活監視）を導入し、「サービスを安定稼働させる意識」を見せましょう。
  • READMEへの記載はデプロイ手順や、採用したインフラの構成図、なぜそのサービスを選んだのかという理由をREADMEに記載してください。

まとめ：デプロイは「運用」の始まり

デプロイが完了した瞬間は非常に感動するものですが、そこがゴールではありません。公開したURLを自分で触ってみて、表示速度は遅くないか、スマートフォンで見ても崩れていないか、本番環境特有のエラーが出ていないかを必ずチェックしましょう。

デプロイ作業は、最初はエラーとの戦いになることが多いです。でも、それを乗り越えて自分の作ったものが世界中から見られるようになった時の感動はひとしおです。ログをしっかり読んで、焦らずに対処していきましょう！

次のアクションを示す。 まずは、自分のプロジェクトに最適なサービスを選び、デプロイに挑戦してみてください。エラーが出たら、サーバーのログ（Logs）を確認する癖をつけましょう。デプロイを乗り越えることで、あなたは「ローカル開発者」から「Webアプリケーション開発者」へと一歩前進します。

現場でよくある具体例

  1. Aさん (受託企業内定) は GitHub の README 冒頭に「誰の何を解決するか」を 3 行で書き、デプロイ URL を最上段に置いた。それだけで書類通過率が 2 倍に
  2. Bさん (自社開発内定) は技術選定理由を README の「Why this stack?」セクションに明記。面接が「決定根拠の深掘り」中心になり、暗記質問が消えた
  3. Cさん (落選続き → 内定) はテーブルを切ってコミット履歴を整理。「feat: 機能追加」のような Conventional Commits に変えた途端、レビュー観点での評価が上がった

次にとるべきアクション

  1. 今のポートフォリオを採用視点で 30 秒見直す — README・デプロイ URL・スクショの 3 点が即座に伝わるか確認する
  2. 改善ポイントを GitHub Issue 化する — 「ポートフォリオのデプロイ（公開）手順と注意点」で得た観点を、自分のリポジトリの Issue として 3 件登録する
  3. 実装/修正を次の 1 週間で完了させる — Issue を Pull Request に落とし込み、コミットメッセージにも改善理由を残す

次のレッスン

次は ポートフォリオの「デザイン」をプロっぽく見せるコツ で、ポートフォリオの「デザイン」をプロっぽく見せるコツ を学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

  1. PFデプロイ手順 の要点を自分の言葉で説明できる
  2. このレッスンの最小コード (または操作手順) を見ずに書ける
  3. 練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. PFデプロイ手順 とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン

参考にした出典

学習を加速したい方へ

未経験エンジニア向けポートフォリオ作成ガイドを体系的にマスターするなら、chotdekiru の無料学習ポータル で実際に手を動かして学習を始めるのがおすすめです。質問・つまずきも現役エンジニアが伴走します。

復習ミニクイズ

ポートフォリオを公開する際、APIキーなどの機密情報を含む `.env` ファイルを誤って GitHub にプッシュしてしまった場合の、エンジニアとして最も適切な対処法はどれですか？

参考リンク