Computer ScienceやAIを目指す高校生にとって、GitHubはプログラム、研究コード、開発記録を公開できる便利なサービスです。
結論から言えば、GitHubのプロジェクトは大学出願で評価される可能性があります。しかし、Repositoryを作ったことや、GitHubのURLを貼ったことだけで高く評価されるわけではありません。
GitHubはActivityそのものではなく成果の証拠
大学が評価する中心は、GitHubというサービスではありません。学生がどのような問題に取り組み、何を設計し、どのように改善したかです。
GitHubは、その成果や開発過程を示す資料として役立ちます。
- 本人が作成したコード
- プロジェクトの目的と使用方法
- 開発中の変更履歴
- 不具合や改善点の記録
- 共同開発における本人の担当部分
大学がGitHubを必ず見るとは限らない
Common AppのActivities欄では、プログラミングや個人開発をActivityとして説明できます。しかし、出願書類にGitHubのリンクを書いても、Admissions Officerが必ず開いて確認するとは限りません。
そのため、リンク先を見なければプロジェクトの価値が分からない書き方は避けます。Activities欄だけでも、目的、本人の役割、成果が伝わるようにまとめることが重要です。
大学によってPortfolioの扱いが異なる
MITでは、創造性、技術力、実際に作る力を示すプロジェクトについて、任意のMaker Portfolioを提出できます。このような大学では、GitHubのコードや開発資料をPortfolioの補足として活用できる場合があります。
一方、Stanfordは、研究論文や特別な制作物などの補足資料を通常の出願ファイルへ追加せず、出願書類内のリンクも審査される保証がないと説明しています。
GitHubの提出方法を考える際は、大学ごとのSupplementやPortfolioの方針を確認する必要があります。
評価されやすいGitHubプロジェクトの特徴
| 弱い見せ方 | 強い見せ方 |
|---|---|
| 練習問題のコードだけを大量に公開する | 一つの問題を解決する完成したプロジェクトを示す |
| 他人のコードをほぼそのまま使用する | 本人が設計・実装・修正した部分を明確にする |
| コードだけで説明がない | READMEで目的、方法、成果、限界を説明する |
| 一度公開して更新していない | 利用者の反応をもとに継続的に改善する |
| 技術名を多数並べる | 技術を使って何を実現したかを示す |
READMEを丁寧に作る
Admissions Officerや専門外の読者がコードを細かく読むとは限りません。そのため、READMEが非常に重要です。
READMEには、次の内容を簡潔に記載します。
- プロジェクト名と目的
- 解決したい問題
- 主な機能
- 使用した言語や技術
- 本人が担当した部分
- 実行方法や画面例
- 成果、限界、今後の改善
プログラミングに詳しくない人でも、プロジェクトの価値を理解できる説明を目指します。
Commit数だけでは評価されない
Contribution Graphを緑色で埋めたり、Repositoryを大量に作ったりしても、それだけで強いActivityにはなりません。
Commit数はコードを細かく分けて保存すれば増やせるため、活動の質を正確に示す指標ではありません。
数よりも、どのような問題を発見し、どのような変更を加え、なぜその判断をしたのかが重要です。
完成度より改善過程を残す
高校生のプロジェクトに、企業レベルの完成度は必要ありません。最初の試作品から改善版へ発展した過程に価値があります。
- 最初にどの問題があったか
- どの機能が動かなかったか
- 利用者からどのような意見を受けたか
- どのように設計やコードを変更したか
- 改善後にどのような変化があったか
Commit履歴、Issues、Release Notesなどを使えば、試行錯誤の過程を残せます。
AI生成コードを使ってもよいのか
ChatGPT、Claude、GitHub Copilotなどを利用して開発すること自体は、直ちに問題になるものではありません。
ただし、AIが生成したコードを理解せず、そのまま本人の成果として公開することは避けるべきです。本人がコードの仕組み、採用した理由、修正内容を説明できる必要があります。
READMEには、必要に応じてAIをどの工程で使い、本人がどのように検証・修正したかを記録します。
共同開発では本人の役割を示す
チームで開発した場合は、プロジェクト全体を一人で作ったように見せてはいけません。
Commit履歴や担当機能を整理し、本人が行った作業を明確にします。
- データ処理部分を設計した
- ユーザー画面を実装した
- AIモデルの評価を担当した
- テストと不具合修正を行った
- 利用者への導入と説明を担当した
コード以外の成果も掲載する
GitHubには、ソースコードだけでなく、プロジェクトを理解するための資料も掲載できます。
- 分析結果のグラフ
- 研究レポート
- 画面のスクリーンショット
- デモ動画への案内
- モデルの性能比較
- 匿名化した利用者アンケートの結果
研究型プロジェクトでは、使用データ、分析方法、再現手順を整理すると、研究の透明性を高められます。
個人情報と著作権に注意する
GitHubは公開設定にすると、誰でも内容を確認できます。生徒の成績、氏名、メールアドレス、研究参加者の情報などを公開してはいけません。
他人のコード、画像、データセットを利用する場合は、ライセンスと利用条件を確認し、出典を明記します。APIキーやパスワードをコード内へ書き込まないことも重要です。
Common AppのActivities欄への書き方
Activities欄では、Repositoryの名前や使用技術だけを書くのではなく、行動と成果を中心にまとめます。
たとえば、「Python、Flask、AIを使用」と書くより、次のような要素を入れます。
- 誰のどの問題を解決したか
- 何を設計・開発したか
- 何回改善したか
- 何人が試用・利用したか
- どのような効果があったか
GitHubは補足的な証拠として使い、Activityの価値は出願書類内で完結して説明します。
AP学習との一貫性を作る
UsUniNavでは、APで学んだ内容をGitHubプロジェクトへ発展させることを推奨しています。
- AP Computer Science A：アルゴリズムやクラス設計を開発へ応用する
- AP Statistics：データ分析とモデル評価を行う
- AP Calculus BC：変化や最適化を数理モデルへ取り入れる
- AP Physics C：実験データ処理やシミュレーションを開発する
AP ScoreとGitHub上の成果がつながれば、試験知識を実際の問題へ応用したことを示せます。
評価されやすいプロジェクト例
- 数学の誤答傾向を分析する学習支援システム
- 公開データを可視化する地域情報サイト
- 実験データを自動処理する研究ツール
- 物理現象を再現するPythonシミュレーション
- 複数のAIモデルを比較する研究プロジェクト
- 学校や地域で継続利用される小規模アプリ
流行の技術を使うことよりも、本人の関心から始まり、長期間改善されていることが重要です。
避けたいGitHubの使い方
- チュートリアルのコードを大量にそのまま掲載する
- 他人やAIが作ったコードを本人の成果として見せる
- Repositoryを増やすことだけを目的にする
- READMEがなく、何のプロジェクトか分からない
- 動作しないコードや機密情報を公開する
- GitHubのリンクを貼れば大学がすべて読むと思い込む
大学出願につなげる7段階
- 本人が関心を持つ問題を選ぶ
- 小さな試作品を完成させる
- GitHubでコードとREADMEを整理する
- 第三者に使ってもらい意見を集める
- Commit履歴を残しながら改善する
- 成果、限界、本人の役割を記録する
- Activities欄で価値を説明し、必要に応じてPortfolioへつなげる
まとめ
GitHubのプロジェクトは、Computer ScienceやAI志望者の大学出願で有力な材料になり得ます。しかし、GitHubアカウントやRepositoryの数そのものが評価されるわけではありません。
評価されるのは、本人が問題を発見し、設計・実装し、失敗を修正し、実際の成果へつなげた過程です。
大学がリンクを確認しなくても価値が伝わるようにActivities欄で説明し、GitHubはその成果と継続性を裏づける資料として活用しましょう。
公式情報
- Common App｜First-Year Application Guide
- MIT Admissions｜Maker Portfolio
- MIT Admissions｜Supplemental Portfolios
- Stanford University｜Supplementary Materials
- Yale University｜Supplementary Materials
※Portfolioや外部リンクの提出方法は、大学と出願年度によって異なります。出願前に各大学の最新の公式要項をご確認ください。
