学習を始めて数週間たつと、手は動かしているのに「応募書類に書けるものが何も無い」と感じる場面が来ます。やったことは頭と端末の中に散らばったままで、人に見せられる形になっていません。GitHub のプロフィールや草（緑の四角）も、意味が分からないまま放置している人は多いはずです。この記事は、その散らばりを「見える実績」に変える仕組みを整理します。
この記事の結論
- ポートフォリオは完成した1つの大作である必要はなく、学習の積み重ねを見える形にしたものです。
- GitHub のプロフィール README は、自分のユーザー名と同じ名前のリポジトリに README.md を置くと、プロフィール上部に自動で表示される仕組みです。
- コントリビューション（草）は、そのアカウントで行われた一定の活動を日ごとに数えて塗った四角の集まりで、継続の記録にはなっても技量の証明にはなりません。
- 選考で伝わりやすいのは活動量そのものではなく、何を作り、どこで詰まり、どう調べて解決したかという中身です。
- 学習中に残す構築のメモや詰まった点の記録が、そのままポートフォリオの材料になります。
- 未経験のうちは職務経歴書の代わりではなく、学習の姿勢を伝える補助として使います。
ポートフォリオとは何を見せるためのものか
ポートフォリオは、自分が何をしてきたかを第三者が確かめられる形にまとめたものです。実務経験が無い人にとっては、「経験の代わり」ではなく「経験が無い中でどう学んでいるか」を見せる場になります。
ここで大事なのは、大作である必要はないという点です。1つの完成したシステムを作らなくても、次のような小さな記録の集まりで成り立ちます。
- 学んだ概念を自分の言葉で書いたメモ
- 手を動かして試した構築の記録（何を作ろうとして、何が起きたか）
- 詰まった点と、調べて解決した筋道
前提となる Git の動作（変更する・add・commit）は、先に読んでおくと話が早くなります。
READ ALSO — 未経験向け・段0 土台
Git とは何か｜「上書き保存」と「版を残す」の違いを、最初の3つの動作で理解する
目指す職種の全体像は、次の記事で確認できます。ポートフォリオに何を残すかは、目指す仕事の中身から逆算して決まります。
READ ALSO — 未経験向け・段1 入口
クラウドエンジニアとは何か｜設計・構築・運用・自動化の仕事と、インフラエンジニアとの違い
FROM NOTES TO PORTFOLIO学びが見える形になる道
学んだことは4つの駅を通ってポートフォリオになる
-
学ぶ
手を動かして試す
-
リポジトリに残す
メモと記録を置く
-
README に書く
何をしたか1枚に
-
プロフィールに表示
同名リポジトリが拾われる
図のとおり、材料は「学ぶ」ところから始まり、リポジトリ → README → プロフィールの順に、人に見える場所へ運ばれていきます。以降の節で、この後半の3つの駅がどう動くかを見ていきます。
GitHub のプロフィール README はどういう仕組みで表示されるか
GitHub には、プロフィールページの上部に自己紹介を表示する機能があります。プロフィール README と呼ばれ、仕組みは単純です。
- 自分の GitHub ユーザー名とまったく同じ名前のリポジトリを作る
- そのリポジトリに
README.mdを置く - リポジトリを公開（public）にしておく
すると、GitHub がその README.md の内容をプロフィールページの上部に自動で表示します。特別な設定画面があるわけではなく、「ユーザー名と同名のリポジトリの README を拾う」という約束事で動いています。公式ドキュメントでは、作成時に README を追加する選択肢が案内されており、この約束事の説明もそこにあります。
つまり、名前が1文字違うだけで拾われません。表示されないときは、まずリポジトリ名とユーザー名の一致、次に公開設定を疑います。
README には何を書くか
README.md は Markdown で書きます。未経験の段階で入れておくとよいのは、次の程度で十分です。
| 項目 | 書く内容の例 | 狙い |
|---|---|---|
| いま学んでいること | 学習中の領域と、直近で手を動かしたこと | 現在地が伝わる |
| 残した記録への道しるべ | 構築メモや学習ノートのリポジトリへのリンク | 中身に飛べる |
| 連絡の取り方 | 公開してよい連絡先だけ | 次の接点になる |
飾りやバッジを増やすことより、「リンクの先に読める中身がある」ことのほうが効きます。プロフィール README は入口であって、実績そのものは入口の先に置くものです。
CHECK 1ここまでの確認
GitHub のプロフィールに自己紹介の README を表示するには、何をすればよい?
答えと解説
答え: 1. 自分のユーザー名と同じ名前のリポジトリを作り、README.md を置く
プロフィール README は「ユーザー名と同じ名前のリポジトリの README.md」を GitHub が拾って表示する仕組みです。名前が1文字でも違うと拾われません。「プロフィール README はどういう仕組みで表示されるか」の節を読み直してください。
コントリビューション（草）は何を数えていて、何を数えていないか
プロフィールに並ぶ緑の四角の集まりは、コントリビューショングラフと呼ばれます。日ごとの活動の量を色の濃さで表したもので、俗に「草」と呼ばれます。
公式ドキュメントによると、数えられるのは主に次のような活動です。
- 特定の条件を満たすリポジトリへのコミット
- Issue の作成
- プルリクエストの作成
- プルリクエストのレビュー
ただし、コミットが数えられるには条件があります。コミットに使うメールアドレスが自分のアカウントに紐づいていること、対象がリポジトリの既定のブランチ（または一部の公開用ブランチ）であることなどです。フォークしたリポジトリへのコミットは、通常は数えられません。条件の細部は変わりうるので、数え方に迷ったときは公式ドキュメントで確認してください。
草が映していないもの
- コードの難易度や質
- 設計の良し悪し、トラブルを切り分けた力
- 学習の中身（何を理解したか）
草が示すのは「そのアカウントで、数えられる形の活動があった日」だけです。濃いからといって難しいことをしたとは限らず、薄いからといって学んでいないとも限りません。たとえば、画面で試して理解を深めた日や、紙に書いて整理した日は、草には1つも出ません。
だから草は、継続の記録として使うのが正しい読み方です。量の指標を質の指標と取り違えないこと、これが第3節の要点です。
VOLUME VS SUBSTANCE量と中身
選考で伝わるのは草の数ではなく中身
活動量（草の数）
継続の記録
- 日ごとの活動が数えられる
- コードの質は映らない
- 何を考えたかは分からない
中身（README・コミットメッセージ）
考え方の記録
- 何を作ったかが読める
- どこで詰まったかが読める
- どう解決したかが読める
CHECK 2ここまでの確認
草（コントリビューション）が濃いことが直接証明するのは何?
答えと解説
答え: 1. そのアカウントで一定の活動が続いたこと
草は活動を日ごとに数えた記録で、量と継続の指標です。コードの質や難しさは映りません。「草は何を数えていて、何を数えていないか」の節を読み直してください。
選考担当者は活動量と中身のどちらを見ているか
選考担当者がどう見ているかは、採用する側ごとに違い、公表された統計もありません。そのためここでは数字ではなく、情報としてどちらが伝わりやすいかで考えます。
活動量（草の濃さ、リポジトリの数）から読み取れるのは、「手を動かしている人らしい」というところまでです。何を作ったのか、なぜそうしたのか、うまくいかなかったときにどう動いたのかは、数からは出てきません。
一方、中身には次のものがあります。
| 中身の種類 | そこから伝わること |
|---|---|
| 何を作ったか | 目的と範囲を決められる |
| どこで詰まったか | 問題を言葉にできる |
| どう調べて解決したか | 公式ドキュメントなどで裏を取る習慣がある |
| コミットメッセージ | 変更の理由を残す癖がある |
特に「どこで詰まり、どう調べて解決したか」は、実務でも毎日起きる動きそのものです。ここが書いてあると、経験が無くても仕事の進め方が想像できます。反対に、中身の無い大量のコミットは、読む側の時間を使わせるだけで、かえって印象を薄めます。
CHECK 3ここまでの確認
選考の場で伝わりやすいのは、次のどちらの情報?
答えと解説
答え: 2. 何を作り、どこで詰まり、どう調べて解決したかの記録
活動量だけでは、本人が何を考えて手を動かしたかが伝わりません。詰まりと解決の筋道が書かれていれば、中身が読み手に届きます。「活動量と中身のどちらを見ているか」の節を読み直してください。
学習の記録をポートフォリオの材料に変える手順
新しく何かを作らなくても、いま取っている学習のメモを少し整えれば材料になります。手順は4つです。
- 学習用のリポジトリを1つ作る。 概念のメモ、構築の記録、詰まりの記録を、フォルダで分けて置きます。
- 1回の学習を1つのメモにする。 「何をしようとしたか」「何が起きたか」「どう調べたか」「分かったこと」の4行が書ければ十分です。
- コミットメッセージに理由を書く。 「修正」ではなく「セキュリティグループの許可元を絞った（理由：検証後に不要と分かったため）」のように、変更の理由を一言添えます。
- プロフィール README から、そのリポジトリへリンクする。 入口から中身へ、1クリックで届く状態にします。
構築の記録に、AWS のコンソールの画面キャプチャを延々と並べる必要はありません。画面は改定で変わり、記録としてもすぐ古くなります。残すべきなのは「何を確かめたくて、どう考え、何が分かったか」のほうです。手順そのものは公式ドキュメントに任せ、リンクで示せば足ります。
READ ALSO — 未経験向け・段1 入口
未経験がクラウドを学ぶ最初の1か月｜週ごとの順番と、やらないことを先に決める
学習の進め方は上の記事にまとめてあります。週ごとに残すもの（用語のメモ、切り分けの記録、構築の記録、壊して直した記録）がそのままポートフォリオの材料になります。
公開してはいけないものに注意する
記録を公開する前に、次のものが含まれていないかを必ず見ます。
- アクセスキーやパスワードなどの認証情報
- アカウント ID など、環境を特定できる情報
- 勤務先や学習先の内部情報
一度コミットすると履歴に残るため、後から消しても過去の版から読めてしまうことがあります。公開の前に確認し、混ぜない運用にしておくのが安全です。
未経験のうちにやらないこと
ポートフォリオを「作らなければ」という焦りから、逆効果になる動きがあります。
- 草を埋めるためだけのコミットを重ねる。 中身の無い活動は、量の指標を水増しするだけで、読み手には伝わりません。
- 他人のコードをそのまま自分の成果として載せる。 何を自分でやったのかが曖昧になり、説明を求められたときに詰まります。
- 職務経歴書の代わりにしようとする。 書類そのものの書き方は別の題材です。ポートフォリオは学習の姿勢を伝える補助と位置づけます。
- 最初から大作を目指して公開が遅れる。 小さな記録を早く積むほうが、振り返りにも使えます。
最初の目標は、「3か月後の自分が読み返して、何を学んだか分かる記録」にすることです。そこまでできていれば、見せる場面が来たときに、プロフィールからリンクを渡すだけで済みます。
Cloudory 執筆者（AWS 認定 全冠）
ポートフォリオは、見せるために作るものというより、自分の学習を後から読み返せるようにするものだと考えると続けやすくなります。草の色より、1本のメモに「詰まった点」が書いてあるかどうかを大事にしてください。
まとめ
- ポートフォリオは大作ではなく、学習の積み重ねを人が読める形にしたものです。
- プロフィール README は、ユーザー名と同名のリポジトリの README.md を GitHub が拾って表示する仕組みです。
- 草は活動の継続を示すもので、技量の証明ではありません。
- 伝わるのは、何を作り、どこで詰まり、どう解決したかの中身です。
- 次は、AWS の入口の知識と手を動かした記録を並行して積み上げてください。
参照ソース
- GitHub Docs: プロフィール README の管理 — ユーザー名と同名のリポジトリに README.md を置くとプロフィールに表示される仕組みの根拠（2026年10月時点で参照）
- GitHub Docs: プロフィールでのコントリビューションの表示 — コントリビューショングラフが数える活動と、数えられる条件の根拠（2026年10月時点で参照）
