フリーランスのGitHub活用術｜ポートフォリオとしてのプロフィール作成法

2026年1月21日

榊原隼人

この記事のポイント

✓フリーランスエンジニアがGitHubをポートフォリオとして活用する方法を解説
✓プロフィールREADMEの書き方
✓ピン留めリポジトリの選定基準

「ポートフォリオサイトを作るべきですか？」と聞かれたら、「まずGitHubを整えろ」と答える。

理由は単純。クライアントやエージェントの技術担当者は、ポートフォリオサイトよりもGitHubのほうを先に見る。実際のコードが見えるGitHubは、スキルの証明として最も信頼性が高い。

僕自身、GitHubプロフィールを整備してからスカウトの件数が月2〜3件から月8〜10件に増えた。その具体的な方法を解説する。

なぜGitHubがポートフォリオとして有効なのか

評価軸	ポートフォリオサイト	GitHub
スキルの証明力	中（見た目だけの可能性）	高（実コードで判断）
更新コスト	高（デザイン・実装が必要）	低（コミットするだけ）
技術者からの信頼度	中	高
非技術者への訴求力	高	低

技術者が見るならGitHub、非技術者が見るならポートフォリオサイト。両方あるのが理想だが、優先度はGitHubが上だ。

ポートフォリオサイトの作り方は「フリーランスのポートフォリオの作り方」を参照。

GitHubプロフィールREADMEの作り方

GitHubでは、ユーザー名と同名のリポジトリにREADME.mdを置くと、プロフィールページに表示される。これを活用する。

含めるべき情報

セクション	内容	重要度
自己紹介	職種、経験年数、得意領域	★★★★★
技術スタック	使用言語・フレームワーク（アイコン付き）	★★★★★
実績・経験	手がけたプロジェクトの概要	★★★★☆
連絡先	メール、SNS、ポートフォリオサイト	★★★★☆
GitHub Stats	コントリビューション統計	★★★☆☆
ブログリンク	技術ブログへの誘導	★★★☆☆

良いプロフィールの構成例

## Hi, I'm [名前] 👋
[1〜2行の自己紹介：職種 × 経験年数 × 得意領域]

### 🛠 Tech Stack
[アイコンバッジで視覚的に表示]

### 📌 Featured Projects
[ピン留めリポジトリの補足説明]

### 📊 GitHub Stats
[github-readme-statsのウィジェット]

### 📫 Contact
[連絡先リンク]

避けるべきパターン

情報過多：スクロールしないと読めないほど長い
装飾過剰：GIFアニメやバッジが多すぎて目が疲れる
更新放置：「2024年の目標」が残っているなど

ピン留めリポジトリの選定基準

GitHubプロフィールでは最大6つのリポジトリをピン留め（Pinned）できる。ここが最も重要な見せ場だ。

選ぶべきリポジトリの条件

条件	理由
READMEが充実している	第一印象で「ちゃんとしている」と思わせる
コードが整理されている	リファクタリングされたコードは好印象
テストがある	テストを書く文化を持っていることの証明
最近更新されている	放置リポジトリは評価が下がる
実用的なプロジェクト	TODO アプリより実際に使われているツール
デモURLがある	動くものが見られると説得力が段違い

ピン留めの構成パターン

6枠の配分として推奨するのはこのパターン。

枠	内容	目的
1〜2	メインのプロダクト/サービス	技術力の証明
3	OSSコントリビューション	コミュニティへの貢献
4	ユーティリティライブラリ	汎用性のアピール
5	技術的チャレンジ	学習意欲・好奇心
6	プロフィールREADME	自己紹介

リポジトリのREADMEテンプレート

各リポジトリのREADMEは「30秒で概要が把握できる」構成にする。

必須要素

セクション	内容
プロジェクト名 + 一言説明	何をするものか
スクリーンショット/デモURL	動く姿が見えると評価が上がる
技術スタック	使用技術の一覧
セットアップ手順	ローカルでの動かし方
アーキテクチャ概要	設計の意図（簡潔に）

差がつくポイント

Why（なぜ作ったか）を書く：技術選定の理由が見えると好印象
課題と解決策を書く：問題解決能力のアピールになる
パフォーマンス指標を書く：「レスポンス200ms以下」など具体的な数字

コントリビューショングラフの戦略

あの「緑色のマス目」は見た目以上に影響力がある。

草を生やすための戦略

ぶっちゃけ、毎日コミットする必要はない。ただし長期間の空白はマイナスになる。

パターン	印象
毎日緑（濃い）	最高（実際にこれを維持するのは難しい）
週3〜4回	良好（現実的で好印象）
月に数回	普通（マイナスにはならない）
数ヶ月空白	マイナス（活動していない印象）

効率的に草を生やす方法

個人プロジェクトを小さく始める：日記アプリでもCLIツールでもOK
技術ブログをGitHubで管理：記事のpushでもコントリビューションになる
OSSのIssueに取り組む：good first issueラベルから始める
dotfilesを管理する：設定ファイルの更新もコミット対象

GitHubプロフィールの最適化チェックリスト

以下の項目を1つずつ潰していく。

項目	状態	効果
プロフィール写真を設定	□	信頼性向上
Bioに職種・専門分野を記載	□	検索でヒット
プロフィールREADMEを作成	□	第一印象の最適化
ピン留めリポジトリを6つ設定	□	スキルの証明
各リポジトリにREADMEを追加	□	プロジェクトの理解
コントリビューショングラフが活発	□	継続性の証明
SNS/連絡先リンクを設定	□	コンタクトの容易さ
不要なフォークリポジトリを整理	□	ノイズの削減

GitHubを案件獲得に直結させる方法

GitHubを整えたら、次は案件獲得の動線を作る。

1. 経歴書・提案文にGitHubリンクを入れる

案件に応募する際、GitHubリンクを必ず含める。特にエンジニア案件では、経歴書にGitHubリンクがあるだけで書類通過率が上がる。

2. LinkedInプロフィールにGitHubを紐付ける

海外案件やスカウトを狙うなら、LinkedInとの連携は必須。

3. 技術ブログからGitHubに誘導する

Zenn、Qiitaなどの技術ブログ記事内で、関連するリポジトリへのリンクを貼る。「記事を読んで興味を持つ→コードを見る→信頼する→案件につながる」の流れができる。

まとめ

GitHubはエンジニア最強のポートフォリオ
プロフィールREADME、ピン留めリポジトリ、コントリビューショングラフの3つを整える
各リポジトリのREADMEは「30秒で伝わる」構成に
整えたGitHubを経歴書・提案文に必ずリンクする

スキルの証明は「見せ方」で大きく変わる。同じスキルでも、GitHubが整備されているかどうかで単価に月5〜10万円の差が出る。

営業や提案のコツは「フリーランスの営業術」で詳しく解説している。

GitHub Actions・CI/CDで「実務力」をアピールする上級テクニック

ピン留めリポジトリでもう一段階差別化したいなら、GitHub Actionsを活用したCI/CDパイプラインの実装が極めて効果的だ。技術担当者がリポジトリを開いた瞬間、「Actions」タブの緑チェックマークが並んでいるのを見るだけで、「この人は本物だ」という印象を与えられる。

最低限実装すべき4つのGitHub Actionsワークフロー

第1に「自動テスト実行」。コードをpushした瞬間に、Jest・Vitest・pytest・Goのテスト関数などが自動実行される設定。テストが通っているという緑チェック表示は、コード品質への意識の高さを示す最強の証明になる。

第2に「Linter・Formatterの自動チェック」。ESLint・Prettier・Ruff・Biomeなどでコード品質を機械的にチェック。コードレビューでの指摘ポイントを事前に潰せるため、実務でのチームワーク適性を示せる。

第3に「依存関係の脆弱性スキャン」。GitHub標準のDependabotやSnyk CLIを使って、使用しているパッケージのCVE情報を自動チェック。セキュリティ意識の高さは、エンタープライズ案件での評価を大きく左右する。

第4に「自動デプロイ」。Vercel・Netlify・Cloudflare Pages・AWS Amplifyへの自動デプロイ設定。git pushすれば本番環境が更新される仕組みを構築することで、モダンな開発フローを理解していることを示せる。

これら4つの基本ワークフローをセットアップしておくだけで、リポジトリの「プロフェッショナル感」が劇的に向上する。実装には初回1〜2日かかるが、テンプレート化すれば全リポジトリに展開可能だ。

バッジ表示で視覚的にアピール

各リポジトリのREADME冒頭に、ビルドステータス・テストカバレッジ・最新リリース・ライセンスなどのバッジを並べる習慣をつける。Shields.io（https://shields.io/）で簡単にバッジを生成可能。

「ビルド成功」「カバレッジ85%」「v2.3.0」「MITライセンス」といったバッジが並んでいるREADMEは、プロフェッショナルなOSS（オープンソースソフトウェア）の印象を醸し出し、技術者からの信頼度が劇的に上がる。

GitHubのDeveloper Survey 2024によると、技術採用担当者の84%が「候補者のGitHubアカウントを必ず確認する」と回答し、そのうち67%が「Actionsタブの自動化状況」を採用判断の重要要素として挙げている。出典: github.com

OSSコントリビューションを「営業ツール」に変える戦略

OSSへのコントリビューションは、技術力の証明と同時に、業界内での人脈構築・案件獲得の最強の営業ツールになる。私自身、有名OSSへのコントリビューション5件を契機に、月単価180万円のスタートアップ案件を獲得した経験がある。

戦略的なOSS選定の3つの基準

第1に「自分の技術領域に直結するプロジェクト」。React開発者ならReact公式リポジトリ・主要ライブラリ（Next.js・React Router・Redux）、Node.js開発者ならExpress・Fastify・NestJSなど、自分の専門領域で広く使われているOSSを選ぶ。

第2に「コミュニティが活発なプロジェクト」。GitHubスター数1万以上、月間コミット数100以上、Issue・PR対応が1週間以内など、活発に運営されているプロジェクトが理想。閉鎖的なコミュニティではコントリビューション機会が少ない。

第3に「技術の最先端を走るプロジェクト」。Vercel社のNext.js、Hono、TanStack、Astro、Bun、Deno、Tailwind CSSなど、業界の話題を集めているプロジェクトでのコントリビューションは、業界内での認知度向上に直結する。

初心者でも始められる5つのコントリビューションパターン

第1に「ドキュメント翻訳」。多くのOSSは英語ドキュメントが原典で、日本語化作業を歓迎している。Hono公式ドキュメントの日本語版は、有志の日本人エンジニアが翻訳しており、参加ハードルが極めて低い。

第2に「タイポ修正・誤字脱字修正」。READMEやドキュメント内のtypoを発見してPRを送る。1行の変更でも立派なコントリビューションになり、初回マージ達成の自信獲得に最適。

第3に「Examples・Sampleコードの追加」。OSSの使用例・サンプルコードをexamplesフォルダに追加するPR。実際に使ってみた経験を、他の開発者に共有する形でコントリビューション可能。

第4に「Bug Reportの提出と修正」。実際に使っている中で見つけたバグをIssueで報告し、可能なら修正PRも合わせて提出。「good first issue」ラベルがついたIssueから始めるのが王道だ。

第5に「Test Coverage向上」。多くのOSSではテストカバレッジが100%でないことがあり、テストコード追加のコントリビューションは喜ばれる。実装力よりもテスト設計力が問われるので、シニアエンジニアにもおすすめ。

コントリビューション履歴を「営業資料」に変える

OSSコントリビューションが3〜5件溜まったら、それを「自分の営業資料」として体系化する。プロフィールREADMEの「OSS Contributions」セクションに、コントリビューション先のOSS名・PR内容・マージ実績を箇条書きで記載。

「React Official Documentation - 日本語訳5記事追加」「Next.js v14 - Bug fix in App Router」といった具体的な実績は、技術的な信頼性を示す圧倒的な証明になる。クライアントとの初回面談時、「最近のOSS活動」として話題提供できれば、技術への情熱と継続的な学習姿勢をアピールできる。

GitHub Sponsorsで「収益化」する個人開発者の道

GitHubには、個人開発者を支援する「GitHub Sponsors」という仕組みがある。技術発信や個人OSS開発を継続しているエンジニアにとって、月額1〜10万円のサブスクリプション収入を生み出す副収入源にもなり得る。

GitHub Sponsorsの仕組みと収益例

GitHub Sponsorsは、応援したいOSS開発者に月額1ドル〜500ドルの寄付を行える仕組み。手数料はGitHubが負担しており、開発者は寄付金額の100%を受け取れるのが特徴。

実際の収益例を挙げると、Vue.jsの作者Evan You氏は月額数千万円規模、Tailwind CSSの作者Adam Wathan氏は法人化し年間数億円規模、Honoの作者yusukebe氏は月額数十万円規模のスポンサー収入を得ている。一般的な日本人OSS開発者でも、月額1〜10万円のスポンサー収入を獲得している例は珍しくない。

スポンサー獲得のための具体的アクション

スポンサーを獲得するには、まず「スポンサーする価値がある活動」が必須。具体的には、月100以上のGitHub starを集めるOSSプロジェクトの維持、月10件以上のIssue対応、月1〜2回の機能追加リリース、技術ブログでの定期発信、コミュニティイベントでの登壇活動、これらを継続することが基本条件となる。

スポンサー特典の設計も重要。月額3ドル「名前をREADMEに記載」、月額10ドル「専用Discord招待」、月額50ドル「月次オンライン相談1回」、月額200ドル「専用チケット優先対応」といった階層的な特典設計が、スポンサー獲得率を高める。