インフラ／クラウドエンジニアのポートフォリオ｜アプリを作らずに示す方法

インフラやクラウドを担当していると、転職の準備で必ず一度は詰まる場所があります。「ポートフォリオを出してください」と言われたとき、出すものが手元にない、という状態です。

Webアプリケーションの開発者なら、作ったサービスのURLを渡せば終わります。ところがインフラ職の成果物は、動いているシステムそのものです。それは顧客の環境か自社の本番環境にあり、スクリーンショット1枚すら外に出せません。

この記事では、アプリを作らずにインフラ／クラウド職の実力を示す方法を整理します。何を作るか、どこに置くか、そして業務情報をどこまで一般化すれば安全かという線引きまで扱います。

先に結論

• インフラ職のポートフォリオは「動くもの」ではなく「判断の記録」で成立する。 見られているのは完成度ではなく、なぜその構成を選んだかの説明。
• 4点あれば形になる。 構成図／IaCコード／手順書／小さな検証環境。
• 業務の情報はそのまま出さない。 固有名詞と実アドレスを外し、構成の型だけを取り出して自分で再構築する。
• 職務経歴書の代わりにはならない。 経歴書が主で、ポートフォリオはその補足資料。

なぜアプリを作る必要がないのか

「ポートフォリオ＝Webアプリ」という前提は、アプリケーション開発職の選考から広まったものです。インフラ職の選考で確認されるのは、そもそも別のことです。

面接で聞かれるのは、たとえば次のような問いです。

• なぜその冗長化構成にしたのか。単一構成では何が問題だったのか。
• 監視項目をどう決めたのか。そのしきい値の根拠は何か。
• 障害が起きたとき、どこから切り分けたのか。
• コストと可用性のどちらを優先したのか。その判断は誰と合意したのか。

これらはすべて判断の理由を問う質問です。ToDoアプリを1本作っても、この問いには答えられません。逆に言えば、判断の過程が読み取れる資料さえあれば、アプリがなくても成立します。

アプリを作らずに示せる4つの成果物

① 構成図

最も費用対効果が高いのがこれです。図があるだけで、面接での説明の精度が変わります。

含めておきたい要素を挙げます。

要素	書くこと
ネットワーク境界	VPC／VNet、サブネット分割、パブリックとプライベートの区別
通信経路	どこからどこへ、どのプロトコルで通るか
冗長構成	可用性ゾーンの分散、フェイルオーバーの単位
認証・認可	権限の境界、どのロールが何にアクセスできるか
監視・ログ	メトリクスとログの集約先

作図ツールは何でも構いません。重要なのは図そのものより、図の下に添える2〜3行の判断理由です。「可用性ゾーンを2つに分けた理由」「NATを1つに寄せた理由（コスト）」といった一文があるだけで、読み手が意図を追えます。

② IaCコード

Terraform、Bicep、CloudFormation、Ansibleなど、宣言的に環境を記述したコードです。これはGitHubに置けます。

見られるのはコードの量ではありません。

• 変数の切り方：環境ごとに変わる値を外に出せているか。
• モジュール分割：再利用する単位をどう決めたか。
• stateの扱い：ローカルに置いていないか、ロックをどうしたか。
• README：前提条件、実行手順、想定コストが書かれているか。

READMEがないIaCリポジトリは、読み手が意図を推測するしかなく、評価しづらくなります。逆にREADMEが整っていれば、コードが小さくても「業務でこの粒度で書いている人だ」と伝わります。

③ 手順書・ドキュメント

運用設計の力を示せるのがこれです。構築手順そのものより、次のような文書のほうが差が出ます。

• 障害切り分けのフローチャート：どの事象のとき、どこから見るか。
• リストア手順：バックアップから戻すまでの具体的な操作と、確認方法。
• 変更手順書：作業前の確認、実施、切り戻し条件。

インフラ職の実務は、作る時間より運用する時間のほうが長い。運用を想定した文書が書けることは、そのまま実務適性の証明になります。

④ 小さな検証環境

クラウド上に自分のアカウントで小さな環境を作り、その記録を残す方法です。規模は必要ありません。

たとえば、こうしたテーマで十分に成立します。

• 静的サイトを配信し、独自ドメインとTLSを適用するまで
• 監視サービスでアラートを設定し、意図的に閾値を超えさせて通知を確認する
• IaCで環境を作り、壊し、同じ状態に再構築できることを示す

いずれも大規模なシステムではありませんが、DNS・証明書・権限・監視という実務で必ず触る領域を通ります。

規模を大きくするより、同じテーマを条件を変えて2回やるほうが学びが残ります。1回目は手順どおりに通し、2回目は構成を変える、あるいは意図的に壊してから復旧させる。2回目で詰まった箇所こそが、自分の理解が浅い部分です。その記録を残しておくと、面接で「どこで詰まり、どう調べたか」を具体的に話せます。手順が通った記録より、詰まった記録のほうが読み手には価値があります。

業務の情報をどこまで出してよいか

ここが最も注意が必要な部分です。実務経験がある人ほど、手元にある材料が業務由来になるためです。

そのまま出してはいけないもの

• 顧客名・システム名・プロジェクト名
• IPアドレス、ホスト名、FQDN、アカウントID、サブスクリプションID
• 実際の構成図、設計書、手順書のファイルそのもの
• 障害の詳細（発生日時、影響範囲、原因の固有情報）

これらは秘密保持契約や社内規程の対象になり得ます。判断を誤ると、転職どころか現職での問題になります。

一般化して出せるもの

業務で得た知見を、固有情報を外した形に置き換えたものです。手順としてはこうなります。

1. 固有名詞をすべて役割名に置き換える（「A社基幹系」→「社内Webシステム」）。
2. 実アドレスをドキュメント用の記述に置き換える。
3. 規模感を丸める（「サーバ143台」→「100台規模」）。
4. その構成を自分の環境で最小構成として作り直す。
5. 作り直したものを成果物として公開する。

4のステップを踏むと、公開しているのは自分で構築した環境になります。ここまでやれば、業務の情報を出さずに「同種の構成を扱える」ことを示せます。

判断に迷うものは公開しないでください。面接の場で口頭で説明する範囲にとどめる、という選択も十分に成立します。職務経歴書での書き方の整理はインフラ／クラウド職の職務経歴書にまとめています。

どこに置くか

置き場所は3つに整理できます。

置き場所	向いているもの	注意点
GitHub	IaCコード、README、手順書	公開範囲の設定ミスに注意。誤って認証情報を含めない
技術ブログ	検証の記録、判断の経緯	記事が散らばると全体像が見えにくい
独自ドメインのサイト	成果物の入口をひとつにまとめる	ドメイン管理と更新の手間が発生する

実務では「GitHubにコード、READMEから記事へリンク」という構成で足ります。無理に自前のサイトを立てる必要はありません。

一方で、独自ドメインを取って公開まで通す作業そのものが、インフラ職の実務と重なるという側面はあります。ドメインを取得し、ネームサーバを設定し、DNSレコードを書き、TLS証明書を適用し、リダイレクトを整える。この一連は、業務でDNSや証明書を扱うときと同じ手順です。実際に自分で通しておくと、面接で証明書の更新やDNSの伝播について聞かれたときに、手順として説明できます。

独自ドメインはお名前.comのようなレジストラで取得できます。料金はTLD（.com、.dev、.jpなど）やキャンペーン内容によって変わり、更新時の金額が初年度と異なる場合があるため、申し込み前に公式サイトで最新の価格と更新条件を確認してください。

なお、目的が「成果物を見せる場所の確保」だけなら、GitHub Pagesなどの標準ドメインで十分です。独自ドメインは、DNS・証明書まわりを自分の手で扱った経験を作りたい場合の選択肢として考えてください。

面接でポートフォリオをどう使うか

作っただけでは効果は出ません。選考の中でどう使うかまで想定しておくと、準備の精度が変わります。

応募書類に1行で置く

職務経歴書の末尾や、応募フォームの自由記述欄に、成果物の場所を1行で書きます。長い説明は不要です。「構成図とIaCコードを公開しています」という事実と、その場所が分かれば十分です。書類選考の段階で全部を読まれることは多くありません。

面接では「説明の起点」として使う

効いてくるのはここです。面接では、経歴について抽象的な質問が来ます。「これまでで一番難しかった構築は何ですか」といった問いです。このとき、頭の中だけで答えると話が散らかりやすい。ポートフォリオで一度整理してあると、どの順番で何を話すかが決まっているので、説明が安定します。

準備しておきたいのは次の3点です。

• 30秒版の説明：何を作ったか、なぜ作ったかを一息で言える形。
• 3分版の説明：構成の判断理由を、図の流れに沿って話す形。
• 想定される突っ込みへの答え：「なぜこの構成にしなかったのか」という代替案への回答。

3つ目が特に重要です。インフラの設計に唯一の正解はなく、面接官は自分と違う判断をしている箇所を必ず突きます。そこで「検討したが、この理由で採らなかった」と答えられるかどうかで、印象がはっきり変わります。逆に「知らなかった」で終わると、そこで話が止まります。

分からないことは分からないと言う

自分で作ったものについて、説明できない部分があるのは避けたい。生成AIや記事のコードをそのまま貼っただけの箇所があると、深掘りされたときに答えられません。説明できない部分は公開物から外すか、「ここは理解が浅い」と自分で先に言うほうが安全です。

よくある失敗パターン

準備の途中で止まってしまう、あるいは作ったのに評価につながらない、という状態にはいくつか型があります。

チュートリアルの完走記録になっている

公式ドキュメントの手順をなぞった記録は、同じものが大量に存在します。差が出るのは、手順から外れた部分です。「別のリージョンで試したら挙動が違った」「権限が足りずに詰まって、こう調べた」といった記述が1つあるだけで、読み物としての価値が変わります。

規模を大きくしようとして終わらない

マイクロサービス構成をフルで組もうとして、完成しないまま数か月が過ぎる、というのが典型です。インフラは、作り込むほど検証にも時間がかかります。先に公開して、後から足すという順番にしたほうが、結果的に見せられるものが早く揃います。

READMEがない

コードだけがリポジトリに置かれていて、何のための構成か書かれていない状態です。読み手は前提が分からないまま読むことになり、評価に至りません。README1枚のほうが、コード100行より先に読まれます。

認証情報を消し忘れる

最も避けたい失敗です。アクセスキー、接続文字列、証明書の秘密鍵などをコミットしてしまう事故は珍しくありません。一度コミットすると履歴に残るため、ファイルを消すだけでは対処になりません。公開前に、コミット履歴を含めた確認を必ず行ってください。

更新が止まっている

1年前の日付で止まっているポートフォリオは、現在の技術水準を示す材料になりません。頻度は高くなくて構わないので、数か月に一度は何かを足す状態にしておくほうが、継続の証跡として機能します。

公開したあとの運用

作って終わりにせず、少ない手間で維持する形にしておくと長く使えます。

更新のきっかけを決めておく

「資格を取ったとき」「新しいサービスを業務で触ったとき」「検証で詰まった問題を解決したとき」など、更新するタイミングをあらかじめ決めておくと、習慣として続きます。転職活動を始めてから慌てて作るより、平常時に少しずつ積むほうが負担が小さくなります。

古くなった記述を残さない

クラウドのサービス名・画面・料金体系は変わります。古い手順が残っていると、かえって「情報を更新していない人」という印象になりかねません。記事の冒頭に確認日を書いておき、内容が古くなったものは日付を添えて注記するか、更新するかを決めてください。

費用が発生していないかを定期的に見る

検証環境を消したつもりで、一部のリソースが残っていることがあります。ロードバランサ、パブリックIP、ストレージ、スナップショットなどは、使っていなくても課金対象になる場合があります。月に一度は請求画面を確認しておくと安全です。

成果物を置く場所として独自ドメインを使う場合も、ドメインは年単位の契約で自動更新されるのが一般的です。更新料と更新時期は取得時に確認しておいてください。

職務経歴書との役割分担

ポートフォリオを作ると、経歴書に書くことと重複しがちです。役割を分けておくと両方が読みやすくなります。

書類	役割
職務経歴書	何を、どの規模で、どの立場で担当したかの事実
ポートフォリオ	その判断の理由と、自分で手を動かせる範囲の証跡

経歴書には「〇〇の設計・構築を担当」としか書けない部分を、ポートフォリオで「その設計をどう考えたか」に展開する。この関係にしておくと、面接で深掘りされたときの説明がそのまま資料と対応します。両方に同じ内容を書き写す必要はありません。経歴書は事実の一覧、ポートフォリオはその中の1〜2件を深く掘った資料、という濃淡をつけたほうが読み手の負担が小さくなります。

面接で実際に聞かれる質問の傾向はエンジニア面接で聞かれた質問に整理しています。資格との使い分けについてはインフラ系の資格は転職で評価されるかも参考になります。

作る順番

限られた時間で用意するなら、次の順番が効率的です。

1. 構成図を1枚（数時間）：直近で担当した領域を一般化して図にする。
2. READMEを書く（半日）：その構成を再現するための前提と手順を文章化する。
3. IaCで小さく再現（数日）：図の一部でよい。全部を作る必要はない。
4. 公開する（半日）：GitHubに置き、必要なら記事にする。

1と2だけでも面接での説明材料になります。3以降は時間が取れる範囲で進めれば十分です。完成を待って公開を遅らせるより、途中経過を公開して更新していくほうが、継続的に学習している証跡になります。

未経験・経験が浅い場合

実務経験がない場合、ポートフォリオの位置づけは変わります。示すものが実績ではなく、学習の継続性と手を動かす習慣になるためです。

この場合に効くのは、次のような要素です。

• 一定期間、継続して更新されている記録（コミット履歴や記事の日付）
• チュートリアルをなぞるだけでなく、条件を変えて試した形跡
• うまくいかなかったときの調査過程

逆に、完成度の高い成果物が1つだけあって、それ以降の更新がない状態は、継続性の判断材料になりません。小さくても続いているほうが読み取れる情報が多くなります。週に1コミットでも、数か月分積み上がれば十分に傾向として読み取れます。量より、途切れていないことのほうが重視されます。

未経験からの転職で実際に何が見られるかは未経験からITエンジニアになれるのか、学習手段としてスクールを検討する場合はプログラミングスクールに数十万円払う価値はあるかを参照してください。

まとめ

インフラ／クラウド職のポートフォリオは、アプリケーションを作らなくても成立します。

• 見られているのは完成度ではなく、判断の理由。
• 構成図・IaCコード・手順書・小さな検証環境の4点で形になる。
• 業務由来の情報は固有名詞と実アドレスを外し、自分の環境で作り直してから公開する。
• 経歴書が主、ポートフォリオは補足。役割を分けると両方が読みやすくなる。
• 完成を待たず、途中経過を公開して更新していくほうが継続の証跡になる。

成果物を置く場所を自分で用意したい場合は、お名前.comなどで独自ドメインを取得し、DNSと証明書の設定まで自分で通してみる方法があります。料金・更新条件は変更されることがあるため、申し込み前に公式サイトで最新の内容を確認してください。

キャリアの方向性そのものを整理したい場合は、クラウドエンジニアのキャリアパスやインフラエンジニアの年収相場もあわせて確認してみてください。

※本記事の内容は2026年8月2日時点の情報をもとに整理しています。各サービスの料金・提供条件は変更される場合があるため、最新情報は各公式サイトでご確認ください。