クラウドアーキテクトのスキルシートの書き方｜面談で評価される実績の見せ方

クラウドアーキテクトのスキルシートは、使ったサービスの一覧より、自分が決めた範囲、比べた案と選んだ理由、またがった環境、費用・可用性・権限についての結果を書くのが基本です。読み手が知りたいのは、「この人にどこまでの判断を任せられるか」だからです。

この記事では、アーキテクトならではの書き方と、架空の記入例を紹介します。スキルシート全体の構成はスキルシートの書き方の基本、各クラウドの構築経験の書き方はAWSのスキルシートの記事、Azureのスキルシートの記事、GCPのスキルシートの記事で扱っています。

構築担当のスキルシートと何が違うか

構築や運用の担当者のスキルシートでは、どのサービスをどの工程で扱ったかが中心になります。アーキテクトのスキルシートでは、それに加えて次の3つが読まれます。

1. 判断の範囲：一つのシステムの構成か、複数のチームが使う共通の土台か、組織全体の方針か
2. 判断の中身：何と何を比べ、何を優先して、何をあきらめたか
3. 判断の結果：運用に入ってから、費用・可用性・統制の面でどうなったか

サービス名の一覧はスキル欄にまとめ、プロジェクト欄では判断の中身に紙面を使うと、読み手が任せられる範囲を判断しやすくなります。

冒頭の要約に書くこと

スキルシートの冒頭には、3〜5行の要約を置きます。アーキテクトの場合は、次の要素を入れると全体像が伝わります。

• 主に扱ってきたクラウドと、深さの違い（例：AWSは設計から運用まで、Azureは接続と権限の設計のみ）
• 担ってきた判断の範囲（共通基盤の設計、移行計画、クラウド利用方針など）
• 得意な分野（ガバナンス、費用の管理、災害対策など）
• 希望する役割（設計の支援か、方針の取りまとめか）

希望する役割を書いておくと、構築の要員として扱われる案件との食い違いを減らせます。

プロジェクト欄に置きたい項目

アーキテクトのプロジェクト欄は、一般的な項目に加えて、次の欄を設けると読みやすくなります。

「決めた範囲」は、特に正直に書き分けることが大切です。面談では「その判断はご自身が決めたのですか」と聞かれることが多く、書いた範囲と答えがずれると評価が下がります。

「マルチクラウド」の経験の書き方

複数のクラウドの経験は、次の2つを書き分けます。

• 別々の案件で経験した：AWSの案件とAzureの案件に、それぞれ参画した
• またいで設計した：同じ組織の中で、複数のクラウドをつなぐ接続やID、共通のルールを設計した

読み手がアーキテクトに期待するのは、後者の経験です。後者がある場合は、何をまたいで決めたのか（ネットワークの接続、IDの連携、ログの集約、タグのルールの統一など）を具体的に書きます。前者だけの場合も、クラウドごとの違いを比べた経験として書けば材料になりますが、「マルチクラウドの設計」とまとめて書くのは避けます。

資格の書き方

設計系の認定資格は、正式名称、取得年月、有効期限をそろえて書きます。

• 正式名称で書く：「SAP」「AZ-305」などの略称ではなく、「AWS Certified Solutions Architect - Professional」「Microsoft Certified: Azure Solutions Architect Expert」のように書く
• 有効期限を添える：2026年10月時点の公式ページでは、AWS Certified Solutions Architect - Professionalは3年間有効とされています。Microsoftの認定は、Microsoft Learnでのオンライン評価に合格して更新する仕組みで、更新しないと期限が切れます
• 前提の認定も書く：Azure Solutions Architect Expertは、Azure管理者アソシエイトの認定が前提条件です。両方を持っている場合は並べて書きます

Google Cloudの認定を含め、各資格の範囲や有効期間はAWS認定ソリューションアーキテクトの記事、Google Cloud認定 Professional Cloud Architectの記事、Azureの認定資格の記事で確かめてください。失効した資格は「取得歴」として分けて書くと、現在も有効だと誤解されません。

プロジェクト欄の記入例

ここでは、複数のクラウドを使う企業で、共通基盤とルールの設計を担当した場合を想定した記入例を示します。以下は書き方を示すための架空の例で、実在の案件や実績ではありません。業界や規模はぼかしています。

期間：20XX年X月〜20XX年X月（1年）
案件概要：小売業向け 複数のクラウドの利用ルールと共通基盤の整備
対象の環境：AWSとAzureの2つのクラウド、一部の業務システムはオンプレミス。事業部ごとにアカウントが増えていた
立場：クラウド基盤チーム（5名）のアーキテクト。方針の決定者は情報システム部門の責任者
決めた範囲：アカウントとサブスクリプションの分け方、権限の付与の単位、ログの集約先、タグのルールを設計し提案。クラウド間の接続方式は比較案を作成し、決定の場に参加
比べた案と理由：ログの集約先を、各クラウドに残す案と一か所に集める案で比べ、監査の手間を優先して一か所に集める案を採った。保管の費用が増える点は、保管期間をログの種類ごとに分けて抑えた
結果：新しいアカウントの払い出しを申請の手順に沿う形に変え、ルールに沿わない設定を検出する仕組みを入れた。費用をタグで事業部ごとに分けて見えるようにした
使用技術：AWS、Azure、Terraform（レビューと一部作成）、各クラウドのポリシー機能

この例では、方針の決定者が別にいることと、接続方式は「比較案を作成し、決定の場に参加」にとどまることを、そのまま書いています。アーキテクトの経験は大きく見せたくなりがちですが、面談では判断の理由を深く聞かれます。答えられる範囲で書くことが、評価の安定につながります。

面談で深掘りされる点に備える

スキルシートに書いた判断は、面談で深掘りされることが多くあります。次の質問に答えられるかを、提出前に確かめておくと安心です。

• その判断の前提は何で、前提が変わったら結論はどう変わるか
• 選ばなかった案を推していた人はいたか、どう合意したか
• 運用に入ってから想定と違ったことはあったか

面談全般の準備はよく聞かれる質問の記事で扱っています。

よくある質問

構成図をスキルシートに添えてもよいですか？

参画先で作った構成図は参画先の資料のため、そのまま添えるのは避けましょう。自分で一般化して描き直す場合も、出してよいかを確かめる必要があります。多くの場合、文章での要約にとどめ、面談で口頭やホワイトボードで説明するほうが無難です。

決定者ではなかった案件は、アーキテクトの経験として書けませんか？

書けます。比較案を作った、決定の場で推した案と理由を説明した、レビューで方針の修正を提案した、という関わり方は、アーキテクトの経験として読まれます。関わり方をそのまま書くことで、面談での説明とずれずに済みます。

費用の削減の成果は、金額で書いたほうがよいですか？

発注元の金額は、守秘義務に触れるおそれがあるため避けましょう。「月々の費用の内訳を事業部ごとに分けて見える化し、使われていない環境を整理した」のように、何をしたかと、割合や傾向の範囲で結果を書けば十分に伝わります。