GitHubを就活で見せる準備|README・公開設定・提出の手順
就活に使うGitHubは、公開してよい代表作を一つ選び、READMEで目的・動かし方・自分の工夫を伝えられる状態にするのがおすすめです。
活動グラフの「草」にはコミット以外の活動も反映されるため、緑の数だけでは作品の完成度や担当範囲はわかりません。見てほしい開発経験は、作品と説明を結び付けて示す必要があります。
公開範囲の確認からREADMEの書き方、ES・履歴書への載せ方まで、相手が作品を確認できる提出準備を解説します。
本記事では、プログラミング作品を持つ就活生に向けて、GitHubの公開前チェック、プロフィールとREADMEの整え方、ES・履歴書への載せ方を解説します。
GitHubは就活で開発経験を伝える資料になる
GitHubは、制作したプログラムと開発の過程を、応募先へ具体的に伝えるための資料になります。
コードや変更履歴を保存するリポジトリに説明を添えれば、使った技術、取り組んだ課題、自分が担当した部分をまとめて示せます。
プロフィールは自己紹介の入口、作品のREADMEは説明書、コミット履歴は変更の記録と考えると、それぞれの役割を整理しやすいです。
たとえば読書記録アプリなら、画面だけでなく、検索機能を実装した理由や入力エラーを直した経緯まで伝えられます。
ただし、GitHubの提出が必要かどうかは応募先の案内によって異なるため、すべての就活生がアカウントを提出する必要はありません。
作品を持っている人は、まず代表作を一つ選び、公開できる範囲と説明の不足を確かめることから始めるのがおすすめです。
作品がまだない場合も、提出欄を埋めるために他人のコードを自分の実績として載せる必要はありません。
自分で説明できる小さな制作から始めましょう。

GitHubの公開前に確認する3つのこと
GitHubの見せ方を整える前に、秘密情報・公開ルール・公開範囲の3点を確認します。
就活のためであっても、研究や共同開発のデータをそのまま公開してよいとは限りません。
- APIキー・個人情報を履歴まで確認する
- 研究・共同開発の公開ルールを確かめる
- リポジトリと公開先の見え方を確認する
APIキー・個人情報を履歴まで確認する
公開前は現在のファイルだけでなく、過去のコミットや実行ログに秘密情報が残っていないかまで確認します。
APIキー、パスワード、個人情報が入ったデータ、設定ファイルは、作品の説明に必要な情報とは分けて扱います。
環境変数をまとめた.envなどは公開せず、使い方を伝えるための設定見本にはダミーの値を入れる方法がおすすめです。
ただし、.gitignoreへ追加しても、すでに記録したファイルや履歴の秘密が消えるわけではありません。
キーを誤って公開した場合は、まず発行元で失効・再発行し、GitHub公式の案内に沿って履歴や共有先への対応を進めてください。
研究・共同開発の公開ルールを確かめる
研究室・授業・インターン・チーム制作の成果物は、公開してよい範囲を先に確かめることが必要です。
自分がコードを書いた場合でも、企業の資料、研究データ、共同制作者の情報まで自由に公開できるとは限りません。
利用した教材や画像、データについても公開条件を確認し、借りた部分と自分が追加した部分を分けて説明します。
許可を確認できない成果物は非公開のままにして、担当教員やプロジェクトの責任者に公開範囲を相談しましょう。
応募先へは、公開可能な概要資料や別の作品で提出できるかを確認すれば、秘密を出さずに開発経験を伝える準備を進められます。
リポジトリと公開先の見え方を確認する
リポジトリをPublicにすると、コードに加えてGitHub Actionsの履歴やログも広く見られる状態になります。
研究用のPrivateリポジトリを丸ごと公開する前に、ファイル・履歴・ログのそれぞれに出せない情報がないか点検してください。
公開範囲を確認できたら、対象リポジトリのSettingsを開き、Danger ZoneにあるChange visibilityから変更します。
表示される影響と対象名を読み、公開するリポジトリに間違いがないことを確かめて進める手順です。
変更後はログアウトしたブラウザでリポジトリとデモを開き、見せたい説明や画面にたどり着けるかまで確認しましょう。

就活用のGitHubプロフィールを整える3ステップ
就活用のプロフィールは、何に取り組んでいる人なのか、どの作品を見ればよいのかが伝わる入口にします。
短い自己紹介を決めてから詳しい説明を加え、最後に代表作を固定すると進めやすいです。
- STEP1:自己紹介に使える技術と関心を書く
- STEP2:プロフィールREADMEを用意する
- STEP3:代表作をピン留めする
STEP1:自己紹介に使える技術と関心を書く
プロフィールのBioには、実際に使った技術と、興味のある開発分野を短く記載します。
自己紹介を一、二行で読める長さにすると、作品を開く前にどんなことへ取り組んでいる学生かを伝えられます。
使用経験のある言語を並べるだけでなく、何を作ったのかまで一言添えると、技術と経験のつながりが明確になります。
学習中の技術は学習中と書き、授業や個人制作の経験を実務経験のように表現しないことも大切です。
公開プロフィールに自宅の住所や個人の電話番号を載せる必要はなく、作品紹介サイトなど、見てほしい情報へのリンクを選んで設定しましょう。
Bioの記載例
JavaScriptで読書記録アプリを制作しています。Webアプリの画面と操作の分かりやすさに関心があります。

STEP2:プロフィールREADMEを用意する
プロフィール上部に詳しい自己紹介を表示したい場合は、自分のユーザー名と同じ名前の公開リポジトリにREADME.mdを用意します。
右上の「+」からNew repositoryを選び、同名のリポジトリをPublicで作成し、READMEの追加を有効にする流れです。
リポジトリの一番上の階層にREADME.mdを置き、中身を記入すると、プロフィールへ説明を表示できます。
ここには興味のある分野、実際に使った技術、代表作への案内をまとめ、各作品の詳しい実行手順は作品側のREADMEへ分けます。
アイコンやバッジを増やすことより、何を学び、何を作っている人かが文章で伝わる状態を優先するのがおすすめです。

STEP3:代表作をピン留めする
自分が説明できる代表作をピン留めすると、採用担当者が見てほしいリポジトリへ進みやすくなります。
プロフィール画面のCustomize your pinsから対象を選び、見せたい順番に並べて保存する操作です。
固定できるリポジトリとGistは合わせて最大六つですが、枠を埋めるために作品を増やす必要はありません。
まずは目的、担当した範囲、工夫したことを説明できる作品を選び、作品名と短い説明だけでも内容が分かるように整えます。
教材を使って作ったものを選ぶ場合は、学習した内容と自分で変更した箇所を明記し、制作の経緯まで伝わるようにしておきましょう。

就活で伝わるREADMEの書き方
作品のREADMEは、何を作ったか、どう動かすか、自分が何を工夫したかの3点を軸に書きます。
初めて作品を見る人が、概要から動作確認、開発の工夫へ無理なく読み進められる順番にしましょう。

- 目的・機能・画面を最初に見せる
- 使用技術・実行方法・テストをまとめる
- 担当範囲・工夫・改善点を具体的に書く
目的・機能・画面を最初に見せる
READMEの冒頭では、誰のどんな課題を解決する作品なのかを、主な機能と一緒に伝えることが重要です。
使用した技術の一覧から始めるより、作品の目的とできることを先に示すと、コードを読む前に全体像を理解できます。
読書記録アプリなら、読み終えた本の登録やタイトル検索など、実際に動く機能を短く整理する形です。
自分で撮った操作画面や公開できるデモを添えれば、どのように使うものかを具体的に伝えられます。
リポジトリ右側のAboutにも短い説明と必要なURLを設定し、READMEと違う機能や古いデモを案内していないか確認しましょう。
READMEの冒頭例:架空の読書記録アプリ
作品名:読書ログ
目的:読んだ本と感想をまとめ、あとから探しやすくする。
主な機能:本の登録、タイトル検索、感想の編集。
操作画面:自分の作品のスクリーンショットを掲載する。
使用技術・実行方法・テストをまとめる
READMEの実行方法は、ほかの人が同じ手順で動作を確かめられる内容にします。
使用言語や主要なライブラリに加えて、必要なバージョン、準備する設定、インストールから起動までの順序を記載します。
自分の環境だけに保存したファイルや設定を前提にすると、コードを取得しても同じように動かせないためです。
説明に必要な設定値はダミーにし、APIキーなどをREADMEや設定見本へ直接書き込まないようにしてください。
テストの実行方法と確かめた範囲も添え、未実施のテストを実施済みと書いたり、動作しない機能を完成済みとして紹介したりしないことが大切です。
実行方法・テストの記載項目
- 使用技術:言語・ライブラリ・動作確認したバージョン
- 事前準備:必要なソフトとダミーの設定ファイル
- 実行手順:取得→インストール→設定→起動のコマンド
- 確認方法:テストの動かし方と確かめた範囲
- 制約:現在動かない機能や対応していない環境
担当範囲・工夫・改善点を具体的に書く
担当範囲と工夫は、自分が行った判断と、その結果が分かる言葉で書くのがおすすめです。
チーム開発なら全体の機能と自分の担当を分け、個人開発ならどこで悩み、何を確かめて改善したのかを説明します。
「使いやすさを意識した」だけで終えず、入力ミスが起きた箇所と、エラー表示を変更して確かめた内容まで示すと具体的になります。
教材や生成AIのコードを利用した場合も、利用した範囲と自分で理解・修正した部分を整理しておきましょう。
今後追加したい機能は現在できることと分けて書き、面接ではREADMEの説明に沿って制作の経緯を話せるように準備してください。

GitHubの草・コミット数より説明できる開発履歴を残す
GitHubの活動グラフである「草」は、開発の内容を説明するときの補助情報として考えるのがおすすめです。
グラフにはコミットだけでなく、Issueやプルリクエストなどの活動も関係するため、緑の数だけで作品の完成度や本人の役割まで分かるわけではありません。
非公開リポジトリの活動は表示設定によって件数を示せますが、その詳細を閲覧できるかはアクセス権限によって異なります。
就活で見せるために意味のない変更を繰り返したり、過去の活動を実際より多く見せたりする必要はありません。
それよりも、機能追加や不具合修正の単位で変更を記録し、後から見ても何を直したか分かるメッセージを残しましょう。
チーム開発でIssueやプルリクエストを使っていれば、課題の整理、変更の提案、レビューへの対応も自分の役割を説明する材料になります。
個人制作で使っていない仕組みを無理に増やすより、いまの作品について変更の理由と確認方法を話せる状態にすることが先です。
草が少ないことだけで提出を諦めず、応募先の案内に合わせ、作品とREADMEの中身を整えてください。
GitHubをES・履歴書に載せる3ステップ
GitHubの準備ができたら、応募先の指定に合わせてURLと作品の説明を提出します。
指定の確認、説明の記入、相手から見える状態の点検の順に進めると、URLだけを貼って終わることを防げます。
- STEP1:応募先の指定と提出先を確認する
- STEP2:URLに作品概要と担当を添える
- STEP3:ログアウト状態で表示と説明を見直す
STEP1:応募先の指定と提出先を確認する
最初に、応募フォームがプロフィール・リポジトリ・作品のデモのどのURLを求めているかを確認します。
GitHubアカウントの欄ならプロフィール、特定の成果物を求める欄なら作品のリポジトリなど、指定に沿って提出先を選びます。
必須項目や技術課題の案内がある場合は、その条件に従い、判断できない項目は応募先の窓口へ確認してください。
任意欄に載せる場合も、説明できる作品とREADMEがそろっているかを見直すことが大切です。
非公開の成果物しか持っていない場合は、就活のために無断公開せず、概要資料や許可された範囲の閲覧で対応できるかを確認しましょう。
STEP2:URLに作品概要と担当を添える
URLを載せる欄に説明を添えられる場合は、作品名、主な機能、自分の担当、工夫した点を短く記載します。
リンク先を開く前に何の作品かが分かるため、応募書類で伝えた経験とGitHubの内容がつながりやすくなります。
プロフィールのURLと個別リポジトリのURLは異なるので、開いているページのアドレスを確かめて貼り付けてください。
記述欄の文字数や提出形式を守り、チーム全体の成果を自分一人の担当として書かないことも重要です。
具体的な数字や改善結果を記すときは、自分で確かめた内容だけを使い、READMEと応募書類の説明をそろえておきましょう。
ES・履歴書の記述例:架空の読書記録アプリ
個人制作の読書記録アプリです。本の登録、タイトル検索、感想編集を実装しました。入力ミスに気づけるよう、エラー表示の位置を見直しました。作品の概要と実行方法は、以下のリポジトリに記載しています。
プロフィールURL:github.com/ユーザー名
作品URL:github.com/ユーザー名/リポジトリ名
STEP3:ログアウト状態で表示と説明を見直す
提出前には、ログアウトしたブラウザでURLを開き、採用担当者が見られる状態を確認します。
プロフィールから代表作へ進めるか、READMEの画像が表示されるか、デモのリンクが切れていないかを順番に見直します。
可能ならREADMEの手順で起動やテストも試し、応募書類の説明と実際の機能・担当範囲に食い違いがないか確かめてください。
提出後も選考中はURLやリポジトリ名を安易に変えず、作品の説明を求められたときに開ける状態を保ちましょう。
