未経験・第二新卒のポートフォリオは、何を作ればいいか——動くだけでは伝わらない

方眼紙の背景に「未経験・第二新卒のポートフォリオ設計」の見出しと、アイソメ図法で描かれたサーバーラックの線画を配したアイキャッチ画像
動くだけでは伝わらない。過程と再現性で証明する6段階の設計図

未経験や第二新卒からインフラエンジニアを目指すとき、ポートフォリオに何を作ればいいのか。「Linux・Webサーバー・SSH・Docker・クラウド」といった項目リストは学ぶ順序としては妥当ですが、そのまま成果物にすると全員が同じものになります。

この記事では、前職の課題を解く小さなWebサービスを1本だけ作り、それを6段階で仕上げる設計を示します。技術力ではなく「過程と説明」で評価されるための組み立て方です。

この記事でわかること

  • 動く成果物が理解の証明にならない理由と、採用側が実際に見ている3つの評価軸
  • 10項目を並べるのではなく、1本に束ねる具体的な工程(6段階・6週間)
  • AIを「使う」のではなく「繋ぐ」ことで、インフラの論点が一通り出てくる仕組み
  • 差がつく3種類の記録(選ばなかった理由・つまずき・AIの誤り)の書き方
  • 2025年以降変わったクラウド無料枠の前提と、学習環境の選び方
目次

未経験のポートフォリオが「動くだけ」では評価されない理由

左は「NginxでHello World」だけの量産型ポートフォリオ、右は水面下に設計思想・自動化スクリプト・つまずきのログを持つ小さなWebサービスを氷山で対比した図
水面上に出る「動くもの」は同じでも、水面下に何があるかで価値が変わる

項目リストが成果物として弱い理由は、2つあります。

ひとつは、全員が同じものを作ること。クラウドに仮想マシンを立ててNginxを入れ、Hello Worldを出したリポジトリは、選ぶ側から見ると何百と同じものが並びます。

もうひとつが本質です。動いている状態は、理解して作った場合となぞって作った場合で区別がつきません。 手順記事を見ながらクリックしても同じ画面が出ます。生成AIに書かせても出ます。だから「動くものを作った」は、それ自体では何も証明していない。

伝わるのは、作った過程と、それを説明する言葉の方です。

採用側が未経験・第二新卒に見ている3つの評価軸

採用側が見る3つの評価軸を示す図。自力構築(Independence)、仕組みの理解(Under the Hood)、記録の形跡(Documentation)
採用側が透かして見ている3つの軸。第二新卒はここに前職の経験が乗る

未経験者・第二新卒に、現在の技術力は期待されていません。技術力で勝負するなら経験者に勝てないので、そこは論点ではない。

見られているのは3つです。

自力で作れるか。 誰にも指示されずに、繋いで、立てて、動かしたことがあるか。規模は問われません。

便利な仕組みの中で何が起きているか、説明できるか。 クラウドもAIのAPIも、中を知らなくても使えます。使えることと分かっていることは別で、障害が起きたときに差が出ます。

残すことの重要性を分かっていて、実際に残しているか。 現場では、自分がやったことを他人が読める形にできるかが問われます。手順、判断、失敗。これができない人は、技術があっても組織で働けません。

第二新卒には、ここに前職の経験が乗ります。同じ数年を過ごしても、何も持ち帰っていない人と、持ち帰って次に活かそうとしている人がいる。 採用側が知りたいのは後者かどうかです。だから「前職で何をしていたか」より、「前職で何に気づき、それをどう使おうとしているか」が伝わる形にします。

そしてポートフォリオの役割は限定的です。書類で落とされない最低ラインを超えること、そして面接で話す材料を作ること。採用側は成果物だけで判断せず、質問して答え方を見ます。完成度は要りません。深く聞ける余地があるものが1つあれば足ります。

前職の課題を解く小さなWebサービスを1本だけ作る(6段階の全体像)

上段は技術ロゴを10個並べたチェックボックス型の学習にバツ、下段は前職の課題×小さなWebサービス×AI(1箇所)=採用担当者が深く聞ける1本の成果物にチェックを付けた図
技術を10個並べる学習ではなく、前職の課題×小さなWebサービス×AI1箇所を1本に束ねる

分散させず、1本に集約します。

前職の業務で困っていたことを解く、小さなWebサービス。AIを1か所だけ使う。

これだけです。項目を10個並べるより、1本を通しでやった方が強い。しかも項目の大半は、この1本の中で自然に通ります。

工程は6段階です。

段階やること期間の目安
1サーバーを1台用意し、外から繋がる状態にする1〜2週
2Webサービスを立てる。前職の課題を解く内容にする2週
3AIのAPIを1か所繋ぐ1週
4設計図を書く数時間
5記録を残す随時
6全部消して、作り直す1週

費用はサーバー代が月数百円、ドメイン代が年千円程度、AIの利用料が月数百円から。合わせて月千円台に収まります。

6つのステップと価値の境界線を示す折れ線。ステップ1〜4はチュートリアル・生成AIの限界線より下、ステップ5〜6で急上昇する
6つの段階と「なぞりの領域/プロの領域」。動くところまでは限界線を越えない

段階1:サーバーを1台借り、独自ドメインとHTTPSで公開する(1〜2週)

この段階のゴールは、自分のドメインでHTTPSのページが外から見えること。そして、それを消す手順が用意できていること。

User PCからSSH鍵でインターネット・独自ドメインを経由し、HTTPS(Let's Encrypt)でWebサーバーへ繋がる経路図。最優先事項として削除手順と料金アラートの設定を注意喚起している
段階1の全体像。最優先は削除手順と料金アラートの設定

まずインターネット上にサーバーを1台置き、自宅から繋いで、外の人からも見える状態を作ります。

サーバーは国内VPSかOracle Cloud Always Freeか

選択肢費用特徴
国内VPS月数百円〜手続きが簡単で、空きを待つ必要がない
Oracle Cloud Always Free無料無料トライアル終了後も継続して使える[3]。ただし人気が高く、インスタンス作成時に容量不足のエラーが出ることがある。Always Freeはホームリージョンに限定され後から変更できないため[3]、時間を置くか別の選択肢に切り替える判断が必要になる

転職を目指しているなら、月千円弱を惜しんで空きを待つより、VPSを借りた方が早いという判断はあります。

AWS・Azureの無料枠は2025年以降どう変わったか

AWS・Azure・Oracle Cloud・国内VPSを、期間と費用、リスクと特徴、推奨度で比較した一覧表
環境選定の一覧。無期限で使えるのはOracle Cloud Always Freeと有料VPSだけ

AWSやAzureを使うつもりなら、前提が2025年以降変わっているので先に確認が要ります。ここを知らずに始めて、途中でアカウントが止まる人がいます。

AWSは2025年7月15日に無料利用枠を変更し、以降に作成した新規アカウントは最大6か月・最大200ドルのクレジットという形になりました[1]。クレジットはサインアップ時に100ドル、オンボーディングの5タスク(EC2の起動と削除、RDSの構成、Lambdaのデプロイ、Amazon Bedrockでのプロンプト実行、AWS Budgetsでの予算設定)完了でさらに最大100ドルです[1]。6か月が経過するかクレジットを使い切ると、有料プランに切り替えないかぎりアカウントは閉鎖されます[1]。2025年7月15日より前に作った既存アカウントは、従来どおり12か月の無料枠が続きます[1]。

Azureは30日間有効な200ドル分のクレジットと12か月の無料サービス枠ですが、クレジットを使い切るか30日が過ぎるとサブスクリプションとサービスが無効化されます[2]。

つまりどちらも、ずっと動かし続けるラボには使えません。 クラウド特有の考え方を学ぶ期間として、集中的に使うものと割り切ります。学生であれば、Azure for Studentsがクレジットカード不要で、100ドル分のクレジットが付く条件の良さになります[5]。

ここでやること

  • SSHで繋ぐ。パスワードではなく鍵を使う
  • Webサーバーを入れて、ブラウザから見える状態にする
  • 独自ドメインを取り、そのドメインで開けるようにする
  • HTTPS化する(Let’s Encryptで無料)

ドメインを自分で設定する経験は、他で得にくい割に重要です。名前を入力してからサーバーに届くまでの流れを、設定しながら追うことになります。

最初に削除手順と料金アラートを用意しておきます。 作り方の情報は無数にありますが、止め方は自分で調べる必要があります。ここを先にやっておくと、以降が精神的に楽になります。未経験者が最も抜ける部分です。

段階2:前職の業務課題をWebサービスの要件に翻訳する(2週)

この段階のゴールは、「前職のこの作業が面倒だった」を動くWebサービスの形にすること。

接客業・事務職・営業職・製造業それぞれの業務課題を、入力フォームとデータベース保存、自動振り分けスクリプト、検索・ソート機能付き顧客リスト、データ集計とダッシュボード化というWeb要件へ変換する対応表
前職の「めんどくさい」をWeb要件に翻訳する。他人と被らない唯一の部分

ここが他人と被らない唯一の部分です。技術は誰でも同じものを使えますが、何を作るかは経験からしか出てきません。

業種別:前職の課題をWeb要件に変換する

前職で「これ毎回めんどくさいな」と思っていたことを思い出します。業種は問いません。

  • 接客業:シフト希望の集約、在庫の集計、クレーム内容の分類
  • 事務職:定型メールの仕分け、報告書のフォーマット統一
  • 営業職:訪問記録の整理、見込み客の優先度付け
  • 製造業:日報の集計、不良の記録と傾向把握

小さくて構いません。 完成度より、なぜそれを作ろうと思ったかが説明できることの方が重要です。

なぜこれが効くのか

きっかけ、課題、完成までが一本につながり、他人と被らなくなります。そして業務の内側を知っていることは現場で希少なので、技術が並程度でも価値が出ます。

さらに、これが最初に挙げた3つ目の観点に直結します。前職で何も持ち帰らなかった人と、持ち帰って次に活かそうとしている人の差は、この説明が書けるかどうかで見えてしまいます。

READMEにはこう書きます。

前職の店舗運営で、毎朝の在庫集計を手作業でやっていた。数を数えて紙に書き、Excelに転記する作業に30分かかっていた。これを減らすために作った。

ただし、応募先と接続できる場合に限ります。無関係だと「なぜその経験を捨てるのか」という疑問に反転する。応募先を決めてから語る形にします。

段階3:AIのAPIを1か所だけ繋ぎ、インフラの論点を通す(1週)

この段階のゴールは、AIを機能として使うのではなく、鍵の管理・失敗時の挙動・課金まで込みで「繋ぐ」こと。

AI連携のAPIリクエストから、APIキーの管理(環境変数と.gitignore)、エラーと遅延(フェイルセーフ設計)、従量課金への対応(料金アラート設定)へ分岐するフローチャート
AIを繋ぐと、秘密情報・エラー処理・従量課金というインフラの論点が同時に出てくる

AIを使うのは全員がやっています。差になりません。 ところがAIを繋ぐ——APIキーを取り、安全に保管し、リクエストを投げ、返ってきたものを処理し、エラーと料金を考える——これをやった未経験者は急に減ります。

そしてこの作業の中身は、丸ごとインフラの基礎です。

AIを繋ぐときにやることインフラの論点
APIキーを環境変数に置く秘密情報をコードに書かない
キーをGitに入れない.gitignore、漏洩事故
呼び出しが失敗するエラー処理、再試行、タイムアウト
使いすぎると請求が来る従量課金、上限設定
応答が遅い待ち時間の扱い

AIに任せるのはどの部分か

段階2で作ったサービスの、一部分だけをAIに任せます。

  • 集めたテキストを分類する
  • 内容を要約する
  • 自由記述から必要な項目を抜き出す

1か所で十分です。 全体をAIで作るのではなく、AIでないと難しい部分を1つだけ任せる。この判断ができていること自体が評価対象になります。

APIキー・失敗時の挙動・費用をREADMEに書く

APIキーをどう扱ったか。 環境変数に置いた、.gitignore に入れた、と一言。一度でもGitに入れると履歴に残り、消しても痕跡が残ります。

失敗したときにどうなるか。 APIは落ちますし、遅くなりますし、想定外の形式で返ってきます。そのときサービス全体が止まるのか、その部分だけ諦めて動き続けるのか。設計の判断をしたと言える部分です。

いくらかかったか。 上限を設定したか。従量課金の考え方は、クラウドの料金とまったく同じです。

段階4:構成図をMermaidでコードとして書く(数時間)

この段階のゴールは、経路・サーバー内部・データの保存先・AIの呼び出し位置が、1枚の図とコードで一致していること。

画像を貼り付けるBad Approachと、Mermaid記法でコードとして書きGitで差分管理するGood Approachを対比した図
図は画像で貼らずコードで書く。変更履歴がGitの差分に残る

全体像を1枚にします。ここでAIを道具として使うと楽です。

図はコードで書きます。 Mermaid記法でテキストとして書き、GitHubに置く。画像を貼るより一段強くなります。構成を変えたら図も直せば、変更の履歴がGitの差分に残るからです。

書く内容は次の通り。

  • 利用者のブラウザから、サーバーまでの経路
  • サーバーの中で何が動いているか
  • AIのAPIをどこから呼んでいるか
  • データがどこに保存されているか

図と実態が合っていることが重要です。 AIに丸投げで書かせると、存在しない要素が入ったり、経路が間違ったりします。面接で「この線は何ですか」と聞かれて答えられないと、逆効果になる。自分で確認しながら直す前提で書きます。

段階5:却下理由・つまずき・AIの誤りを記録に残す(評価の核心)

この段階のゴールは、3種類の記録が残っていて、そこから面接で話を広げられること。

残すべき3種類の記録。選ばなかった理由(Decisions)、つまずいた記録(Incidents)、AIの見立てが外れた記録(AI Fails)を並べた図
残す記録は3種類。成果物そのものより、これが実務能力を示す

ここが実際の評価対象です。 成果物そのものより、これを見られています。

3種類だけ書きます。

選ばなかった理由(5件、各2〜3行)

理解は、選んだ理由より選ばなかった理由に出ます。選んだ理由は記事の受け売りでも書けますが、却下の理由は違いを知らないと書けない。

  • データベースをサービスとして借りず、自分で入れた。理由は——
  • AIに全部やらせず、この部分だけにした。理由は——
  • 認証を自作せず、既存の仕組みを使った。理由は——

安くて効く項目です。

つまずいた記録(3本)

何で詰まって、どう調べて、どう解決したか。過程を書くのがすべてです。

症状:ブラウザでアクセスすると証明書のエラーが出る
最初に疑ったこと:証明書の取得に失敗している
確認したこと:ログを見たら取得自体は成功していた
実際の原因:設定ファイルで古い証明書のパスを指したままだった
対処:──
学び:ログを先に見れば5分で済んだ

間違った推測も残しておきます。 最初の見立てが外れた記録は、後から作れません。結果だけ知っている人には書けない形式です。「間違っていた」と書き直せる人だという証拠になります。

AIに聞いて外れた記録

AIに質問して、答えが間違っていた記録が特に価値があります。

AIの見立て:設定ファイルの書式が間違っている
自分で確認:書式は正しかった
実際の原因:ファイルの権限が足りず読み込めていなかった

AIの答えを候補の一つとして扱えている姿勢が伝わります。「AIに聞いたら解決した」だけの記録は何も証明しません。

面接で「これAIで書きましたか」と聞かれたとき、「はい、ただしここは書き換えました。理由は——」と答えられれば十分です。

手順・判断・失敗を他人が読める形に残す作業は、実務では「運用設計」と呼ばれる領域そのものです。何をどこまで書けば運用が回るのかを体系的に押さえたい人は、この一冊が近道になります。

段階6:全部消してスクリプトで作り直し、再現性を証明する(1週)

この段階のゴールは、サーバーを消してもスクリプト1本で同じ状態に戻せること。

手作業での構築、環境の破壊、シェルスクリプトによる自動化、再現性という4フェーズを無限ループの形で示した図
手作業→破壊→スクリプト化→再現性。ここを回ると「なぞり」では到達できない位置に出る

ここが山場です。 ここを越えるかどうかで、成果物の質が変わります。

サーバーを削除して、もう一度ゼロから同じものを立てる。ただし2回目は手作業でやらない。手順をシェルスクリプトにまとめておいて、それを流すだけで戻る状態にします。

なぜスクリプト化が「なぞりでない」証明になるか

冒頭に書いた「なぞりと区別がつかない」問題が、ここで解けます。

手順記事は一回きりの構築しか扱いません。何度実行しても同じ結果になるように書く、という発想がない。だからスクリプト化できているという事実自体が、手順をなぞっただけではないことの証明になります。

そして実務では、これが基本です。1台を手作業で作れる人より、100台を同じ状態で作れる人が求められる。その入口がここにあります。

最初は雑でいい

いきなり洗練された形にする必要はありません。まずインストールと設定のコマンドを順に並べたシェルスクリプト1本で十分です。

余裕が出たら、Ansibleのような専用のツールに置き換えます。ただし必須ではありません。 シェルスクリプトで「消して作り直せる」が成立していれば、示したいことは示せています。

副産物として環境の依存関係が全部見える

作り直しの過程で、自分の環境の依存関係が全部見えます。「これを入れる前にあれが必要だった」「この設定はあの設定に依存していた」。1回目の構築では気づかないことが、2回目で全部出てきます。

この気づきが、つまずいた記録の一番いい材料になります。

消して作り直せる状態をさらに進めると、コードを更新したら自動でテストと反映まで走る形になります。段階6の次に何が待っているかを知っておくと、スクリプトの書き方が変わります。

提出するGitHubリポジトリの構成とREADMEの書き方

my-service配下にREADME.md、setup/、app/、docs/decisions.md、docs/incidents/、.gitignoreを配置したディレクトリ構造と、各ディレクトリが対応する段階を示した図
最終的なリポジトリの形。各ディレクトリが6段階のどこに対応するかが分かる
my-service/
├── README.md          何を作ったか・なぜ作ったか・構成図
├── setup/             構築スクリプト(段階6の成果)
├── app/               サービス本体
├── docs/
│   ├── decisions.md   選ばなかった理由
│   └── incidents/     つまずいた記録
└── .gitignore         APIキーや設定ファイルを除外

READMEの冒頭は技術情報から始めます。構成図、使ったもの、動かし方。前職の話や動機はその後。読む側は最初の数十秒で最低ラインを確認していて、そこで物語を読ませると飛ばされます。

パスワードやAPIキーを絶対に入れないこと。 着手前に .gitignore を用意します。

そしてリポジトリは1つを育てます。 作り直すたびに新しいリポジトリを立てると積み上がりません。コミット履歴が数か月続いていること自体が信号になります。

6週間の進め方と、着手前に決める完了条件

期間やること
1〜2週サーバーを立て、ドメインを繋ぎ、HTTPS化する
3〜4週サービスを作る。前職の課題を解く内容で
5週AIのAPIを1か所繋ぐ
6週設計図を書く。全部消して、スクリプトで作り直す
以降月1回、機能を足すか、壊して直す

着手前に完了条件を書いておきます。 「サービスが動き、スクリプトで作り直せて、つまずいた記録が3本」のように具体的に。個人の学習環境は完了条件が自然には決まらず、無限に続きます。転職に期限があるなら無視できないリスクです。

志望先別に足すもの(SIer・情シス・Web系)

6段階のBase ProjectからWeb系志望、SIer/NW志望、情シス志望へ分岐し、それぞれに足すものを示したマトリクス
基本形は共通で、志望先ごとに足すものだけが変わる
志望先足すもの
ネットワーク、SIer、データセンターCisco Packet Tracerでネットワーク構成を組む。無料のNetworking Academyアカウントを作り、無料コースまたはResource Hubから入手する[6]。実務で使うコマンドの多くをそのまま実行でき、CCNAの学習とも重なる
事業会社の情報システム部門Entra IDのテナントは、Intuneの30日試用版に申し込む形で作れる。サインアップすると新しいEntra IDテナントが自動で作られ、Entra ID P1/P2とIntuneが付く[4]。支払い方法の登録は必要だが、確認目的のみで購入しないかぎり請求されない[4]。多要素認証やアクセス制御を触っておくと会話についていける
Web系基本形のままで十分。作るサービスの中身を厚く

なお2024年10月15日以降、Intune管理センターへのサインインには多要素認証が必須で、これは試用版のサブスクリプションにも適用されます[4]。最初にMFAの設定を済ませておくと詰まりません。

クラウドの解説はAWS前提のものが多いですが、日本の事業会社ではAzureとM365の比率が高い。応募先を決めてから寄せる方が効率的です。

未経験は資格とポートフォリオのどちらを先にやるべきか

書類選考(Gate 1)は資格で通り、面接(Gate 2)はポートフォリオで通ることを示したタイムラインと、手を動かした後に資格勉強をすると暗記が理解に変わることを示す循環図
資格とポートフォリオは二者択一ではなく、通過するゲートが違う

資格とポートフォリオはどちらか、という話をよく見ますが、役割が違います。

書類選考は資格で通り、面接でポートフォリオが効く。未経験者は書類で落ちると何も見てもらえないので、二者択一ではなく順序の問題です。

なお、手を動かした後に資格勉強をすると、暗記が理解に変わります。順序としてはこちらが効率的です。

まとめ|未経験ポートフォリオで差がつく6つのポイント

  • 動くだけでは、なぞりと区別がつかない。過程と説明が伝える
  • 項目を10個並べるより、1本を通しでやる
  • 中身は前職の経験から取る。ここだけは他人と被らない
  • AIは「使う」ではなく「繋ぐ」。秘密情報、エラー、料金が全部出てくる
  • 設計図はコードで書く。記録は3種類、失敗も書く
  • 消して作り直せること。 ここが最大の分かれ目
  • 着手前に、削除手順と完了条件を書く

規模は小さくて構いません。自分で繋いで、自分で立てて、自分で消して、もう一度立てられる。 それが説明できれば、未経験者に求められているものは満たしています。

よくある質問(FAQ)

Q. AWSの無料枠は、まだ12か月使えますか?
2025年7月15日以降に作成したアカウントでは使えません。最大200ドルのクレジットと6か月のFreeプランに変わっており、期間終了かクレジット消尽の時点で有料プランへ切り替えなければアカウントは閉鎖されます[1]。同日より前に作成した既存アカウントは、従来の12か月無料枠が続きます[1]。

Q. サーバーは無料枠と有料VPSのどちらがいいですか?
転職に期限があるなら有料VPSが無難です。Oracle Cloud Always Freeは無料トライアル終了後も使い続けられますが[3]、人気が高くインスタンス作成時に容量不足で弾かれることがあります。Always Freeはホームリージョン固定で後から変更できないため[3]、待つ時間のコストと月数百円を天秤にかけて決めます。

Q. AIに書かせた部分があると評価は下がりますか?
使ったこと自体は問題になりません。差がつくのは、AIの答えをそのまま採用したか、確認して直したかです。AIの見立てが外れた記録を残しておくと、道具として扱えている証拠になります。面接で「AIで書きましたか」と聞かれたら、書き換えた箇所とその理由を答えられれば十分です。

出典

  1. AWS: AWS Free Tier now offers $200 in credits and 6-month free plan(2025年7月15日以降の新規アカウント/最大200ドル・6か月・既存アカウントは従来どおり)
  2. Microsoft Learn: Avoid charges with your Azure free account(200ドル・30日、クレジット切れでサブスクリプションとサービスが無効化)
  3. Oracle: Always Free Resources(アカウント存続中は無期限、Ampere A1は月1,500 OCPU時間・9,000GB時間=Always Freeでは2 OCPU・12GB相当、ブロックストレージ200GB、ホームリージョン限定)
  4. Microsoft Learn: Sign up for Microsoft Intune free trial(30日間・サインアップで新規Entra IDテナントを自動作成・EMS=Entra ID P1/P2+Intune・カードは確認目的のみで購入しないかぎり請求なし・2024年10月15日以降はMFA必須)
  5. Microsoft Azure: Free services / Azure for Students(クレジットカード不要・100ドル分のクレジット)
  6. Cisco Networking Academy: Cisco Packet Tracer(無料アカウントで入手。無料コースまたはResource Hubからダウンロード)