自作ツールを GitHub で公開する手順｜アカウント作成からライセンスまで

はじめに

自作の Web ツールやスクリプトをブログで公開していると、「オフラインでも使いたい」「手元に置いて使いたい」という声をいただくことがあります。チーム内での共有、勉強会での配布、ポートフォリオとしての公開など、自作ツールを「配布できる形」にしたい場面は意外と多いものです。

こうした場面への 1 つの答えが、ツールを GitHub でオープンソースとして公開し、ライセンスを明確にした上で「誰もが安心して使える形」で配布するという方法です。この記事では、筆者が実際に自作の Web ツール『MTU/MSS 計算ツール』を GitHub で公開した際の作業を例に、アカウント作成からリポジトリ公開、ライセンス付与までの手順を、実際の画面キャプチャとあわせて整理します。GitHub をこれから使い始めるインフラエンジニアの方や、「コードは書くが公開の作法は分からない」という方を想定しています。

結論を先に述べると、Git コマンドを使わなくても、ブラウザ操作だけで自作ツールの公開は完結します。重要なのはツールをアップロードする操作そのものではなく、その前後にある判断です。公開前に「何を外すべきか」（広告コード・API キー・個人情報）を整理すること、公開時にライセンスを明示して権利関係を明確にすること、公開後にメールアドレスなどの意図しない露出がないか確認すること。この 3 点を押さえれば、個人開発のツールを安心して公開・配布できる状態になります。

GitHub で公開するメリットと公開前の判断

手順に入る前に、「なぜ GitHub で公開するのか」と「何を公開してよいのか」を整理します。この判断が、公開作業全体の土台になります。

配布・ライセンス・更新の 3 つが明確になる

自作ツールの配布方法としては、ブログでの公開、ファイルの直接送付、共有フォルダへの設置などが考えられます。GitHub での公開がこれらと異なるのは、配布・権利・更新の 3 点を 1 か所で明確にできることです。

配布の面では、リポジトリの URL を渡すだけで、相手は最新のファイルをいつでもダウンロードできます。メール添付のように「どれが最新版か分からない」という問題が起きません。権利の面では、リポジトリにライセンスファイルを含めることで、「誰が作者で、利用者は何をしてよいのか」が明文化されます。個人開発のツールを第三者に渡す場面では、この明文化が作者と利用者の双方を守ります。更新の面では、変更履歴（コミット履歴）が自動的に残るため、「いつ何を直したか」の説明が不要になります。

GitHub は無料プラン（GitHub Free）で、公開リポジトリ・非公開リポジトリのどちらも数の制限なく作成できます。個人のツール公開が目的であれば、有料プランを検討する必要はありません。

参考: GitHub Docs（GitHub’s plans）
“unlimited collaborators on unlimited public repositories with a full feature set”
（無制限のパブリックリポジトリを、機能制限なく、無制限の共同作業者と利用できる）
https://docs.github.com/en/get-started/learning-about-github/githubs-plans

公開してよいものと外すべきもの

公開作業で最も重要なのは、アップロードの操作ではなく、公開する前に「何を外すべきか」を整理することです。一度 Public リポジトリにアップロードした内容は、たとえ直後に削除しても、履歴や第三者の複製として残る可能性があると考えるべきです。筆者が実際にブログ版ツールを公開用に整理した際は、以下を確認・除去しました。

広告コード

ブログに設置していた AdSense のコードは、公開版から完全に除去しました。広告 ID（ca-pub- から始まる ID）は個人サイトと紐づく情報であり、配布物に含める理由がありません。

API キー・認証情報

今回のツールには含まれていませんが、外部サービスと連携するツールでは最優先の確認項目です。キーを含めたまま公開する事故は後を絶ちません。

個人情報・環境依存の情報

自宅の IP アドレス、環境が推測できるホスト名・パス、メールアドレスなどが、コメントや設定値に紛れ込んでいないかを確認します。

サイト固有の導線

ブログへの内部リンクや SEO 用の構造化データ（JSON-LD）は、配布物としては不要なため外しました。ツール本体の機能と「サイトの都合」を切り分ける作業です。

逆に、残すべきもの・加えるべきものもあります。計算ロジックや注意書きなどツールの本質的な価値はそのまま残し、加えて README（使い方と計算根拠の説明）とライセンスファイルを新たに用意します。この 2 つの書き方は後のセクションで扱います。

公開範囲の考え方（Public と Private）

GitHub のリポジトリには、誰でも閲覧できる Public と、自分（と招待した相手）だけが見られる Private があります。無料プランでどちらも利用でき、作成後に切り替えることも可能です。

今回のように「第三者に渡せる形にする」「OSS として公開する」ことが目的であれば Public 一択です。一方、公開前の準備段階でいったん Private に置き、整理が済んでから Public に切り替えるという使い方もできます。ただし前述のとおり、Public にした時点で全世界に公開されるため、切り替えの前に「外すべきもの」の確認を済ませておくことが前提です。「Private だから雑に置いてよい」と考えるのではなく、最初から公開に耐える状態で置く習慣にしておくと、切り替え時の事故を防げます。

公開の準備（アカウント設計）

アカウントを作り始める前に、「どの名前で、どのメールアドレスで活動するか」を決めておきます。あとから変更できる項目もありますが、コミット履歴に残るメールアドレスのように、最初に設計しておかないと後から消しにくいものがあるためです。ブログやハンドルネームで活動しているエンジニアが、本名や個人のメールアドレスを晒さずに GitHub を運用するための設計を整理します。

匿名運用の設計（アカウント名・表示名の考え方）

GitHub のアカウント作成で本名の登録は必須ではありません。ユーザー名（アカウント名）は、リポジトリの URL（github.com/ユーザー名/リポジトリ名）にそのまま使われるため、ブログ名やハンドルネームなど「公開して見せたい名前」で作るのが基本です。プロフィールの Name 欄も自由入力で、空欄のままでもハンドルネームでも問題ありません。

このとき意識したいのは、「見せる名前」と「連絡用のメールアドレス」を分けて考えることです。ユーザー名は全世界に見せる看板、メールアドレスは認証と通知のための裏方であり、後者は公開する必要がありません。GitHub にはメールアドレスを隠すための設定が標準で用意されているので、後述の秘匿設定とあわせて「表はハンドルネーム、裏のアドレスは非公開」という構成が成立します。

なお、Google アカウント（Gmail）側の姓名欄も同様に自由入力で、本人確認書類との照合はありません。メール送信時の差出人名として表示されるものなので、こちらもハンドルネームやブログ名で登録して差し支えありません。あわせて、電話番号によるアカウント検索を許可する設定は無効にしておくと、既存の個人アカウントとの紐づけを推測されるリスクを減らせます。

メールアドレスの準備と注意点（Gmail の仕様）

公開活動用のメールアドレスを新しく用意する場合、Gmail が手軽な選択肢になります。ただし、アドレスを考える前に知っておきたい仕様が 2 つあります。

1 つ目は、使える文字の制限です。Gmail のユーザー名に使えるのはアルファベット（a〜z）・数字（0〜9）・ピリオド（.）のみで、ハイフン（-）やアンダースコア（_）は使えません。ブログのドメインなどにハイフンが入っている場合でも、Gmail 側ではハイフンを抜いた形になります。

参考: Google（ユーザー名の作成 – Gmail ヘルプ）
「ユーザー名にはアルファベット（a～z）、数字（0～9）、ピリオド（.）を使用できます」
https://support.google.com/mail/answer/9211434?hl=ja

2 つ目は、ピリオドが無視される仕様です。Gmail では、ユーザー名に含まれるピリオドの数や位置が異なっても、すべて同一のアドレスとして扱われます。たとえば my.handle@gmail.com と myhandle@gmail.com は同じ受信箱に届く同一アカウントです。「ピリオドで区切って見やすくする」ことはできますが、ピリオド違いで別アカウントを作ることはできません。希望のユーザー名が取得済みだった場合は、ピリオドではなく、数字や用途を表す語（contact など）を足して調整することになります。

なお、ここで用意したメールアドレスは GitHub の登録と認証に使いますが、次の設定を行えば、公開されるコミット履歴には残りません。

コミットメールアドレスの秘匿設定

匿名運用で最も実効性が高いのがこの設定です。Git はコミット（変更の記録）に作成者のメールアドレスを埋め込む仕組みになっており、Public リポジトリではこのメタデータも公開されます。つまり、何も設定せずにコミットすると、登録したメールアドレスがコミット履歴から誰でも参照できる状態になります。

GitHub はこの問題への対策として、本来のアドレスの代わりに使える専用のダミーアドレス（noreply アドレス、ユーザー名@users.noreply.github.com 形式）を提供しています。

参考: GitHub Docs（Email addresses reference）
“you can use a GitHub-provided noreply email address”
（GitHub が提供する noreply メールアドレスを使用できる）
https://docs.github.com/en/account-and-profile/reference/email-addresses-reference

設定は Settings の Emails 画面で行います。「Keep my email addresses private」にチェックを入れると、ブラウザ上で行うコミット（ファイルのアップロードや編集）の作成者アドレスが自動的に noreply アドレスに置き換わります。この記事の手順はブラウザ操作のみで完結するため、実質的にこのチェック 1 つで秘匿は完成します。

あわせて「Block command line pushes that expose my email」にもチェックを入れておくことをおすすめします。こちらは、将来 Git コマンドを使い始めたときに、本来のメールアドレスを含むコミットのプッシュを GitHub 側で拒否してくれる保険です。ブラウザ運用のうちは出番がありませんが、うっかり事故を仕組みで防げるため、アカウント作成直後に両方まとめて有効化しておくのが安全です。

この 2 つの設定は、リポジトリを作る前・最初のコミットを行う前に済ませておくことが重要です。コミット履歴は後から修正が難しく、一度公開したアドレスは削除しても複製が残る可能性があるためです。「リポジトリ作成より先にメール秘匿設定」が、この記事で最も強調したい順序です。

GitHub アカウントとリポジトリの作成手順

準備が整ったら、実際にアカウントとリポジトリを作成します。このセクションの操作はすべてブラウザで完結し、Git コマンドやツールのインストールは不要です。なお、画面のデザインや文言は変更される場合があります（本記事のキャプチャは 2026 年 7 月時点のものです）。

アカウント作成

GitHub のトップページ（https://github.com/）から「Sign up」を選び、案内に沿って進めます。入力するのは、メールアドレス（前セクションで用意した公開活動用のもの）、パスワード、ユーザー名の 3 点が基本です。ユーザー名は前述のとおりリポジトリ URL に使われる「見せる名前」なので、ハンドルネームやブログ名ベースで指定します。入力したメールアドレス宛てに確認用のコードが届くので、画面に入力して認証を完了します。

アカウントが作成できたら、リポジトリを作る前に、前セクションのメール秘匿設定（Settings → Emails の 2 つのチェック）を先に済ませます。この順序を守ることで、最初のコミットから noreply アドレスが使われます。

リポジトリ作成

画面右上の「+」メニューから「New repository」を選び、リポジトリを作成します。設定する項目は次のとおりです。

Repository name

英小文字とハイフンで、ツールの内容が分かる名前にします（例: mtu-mss-calculator）URL の一部になるため、日本語や空白は避けます。

Description

ツールの一行説明です。任意項目ですが、検索結果やリポジトリ一覧に表示されるため、書いておくことをおすすめします。

Public / Private

今回は公開が目的なので Public を選択します。

Add a README file

チェックを入れると、README の空ファイルが自動作成されます。後で内容を書き込むため、チェックを入れておくと手順が 1 つ減ります。

「Create repository」を押すと、リポジトリが作成されます。この時点で github.com/ユーザー名/リポジトリ名 という URL が確定し、全世界からアクセス可能になります。

ファイルのアップロード（ブラウザ完結）

作成したリポジトリのトップページで、ファイル一覧の上にある「Add file」メニューから「Upload files」を選びます。アップロード画面にファイルをドラッグ&ドロップするか、「choose your files」から選択します。ブラウザ経由のアップロードは 1 ファイルあたり 25 MiB まで、一度に 100 ファイルまでという制限がありますが、単一 HTML のツールやスクリプトの公開では通常問題になりません。

参考: GitHub Docs（Adding a file to a repository）
“You can upload up to 100 files to GitHub at the same time”
（一度に最大 100 ファイルまで GitHub にアップロードできる）
https://docs.github.com/en/repositories/working-with-files/managing-files/adding-a-file-to-a-repository

ファイルを選んだら、画面下部の「Commit message」に変更内容の短い説明（例: Add tool files）を入力し、「Commit directly to the main branch」を選んだまま「Commit changes」を押します。これが Git でいうコミット（変更の記録）にあたる操作で、アップロードと同時に履歴として記録されます。

アップロードが完了したら、リポジトリのトップページにファイルが並んでいること、コミット履歴の作成者が noreply アドレスになっていることを確認します（確認方法は後のセクションで扱います）

README とライセンスの書き方

ファイルを置いただけのリポジトリは、「何のツールで、使ってよいのか分からない」状態です。訪問者が最初に目にする README と、利用条件を定めるライセンスの 2 つを整えて、初めて「配布できる形」になります。

README に書くべきこと

README（README.md）は、リポジトリのトップページに自動表示される説明文です。Markdown 記法で記述します。リポジトリ作成時に「Add a README file」にチェックを入れていれば、ファイル一覧の README 部分にある鉛筆アイコンからブラウザ上で直接編集できます。

自作ツールの README に最低限書いておきたいのは次の 4 点です。

何のツールか

一行の説明と、可能ならスクリーンショット。訪問者は数秒で「自分に関係あるか」を判断します。

使い方

導入手順と操作方法。今回のような単一 HTML のツールなら「ダウンロードしてブラウザで開くだけ」「Web サーバー不要・オフライン動作」といった動作条件を明記します。

根拠・出典

技術系ツールでは、計算や判定のロジックが何に基づいているか（RFC・公式ドキュメント等）を書いておくと、利用者が値の正しさを自分で検証できます。筆者の場合、MTU/MSS 計算ツールの README には、算出根拠を詳しく解説した記事へのリンクも添えました。あわせて情報の最終確認日を記載しておくと、時間が経ったときに利用者が鮮度を判断できます。

保守の方針

「本リポジトリはスナップショット提供であり、更新の予定・保証はない」「改変・再配布はライセンスの範囲で自由」など、期待値を明示します。個人開発のツールでは、この一文が作者を将来の「直してほしい」という要望から守ります。

MIT ライセンスの付け方と著作権者名

ライセンスファイルがないリポジトリは、Public であっても「著作権法の初期状態＝全権利留保」のままです。つまり、コードが見える状態と、使ってよい状態は別物です。

参考: GitHub Docs（Licensing a repository）
“without a license, the default copyright laws apply”
（ライセンスがない場合、デフォルトの著作権法が適用される）
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository

第三者に「自由に使ってよい」と伝えるには、ライセンスの明示が必要です。個人開発ツールの公開でよく使われるのが MIT ライセンスで、「著作権表示を残せば、使用・改変・再配布・商用利用まで自由。ただし無保証」という、短くて分かりやすい条件が特徴です。利用者側から見ても扱いやすいため、迷ったら MIT を選んでおけば大きく外しません。

GitHub には、ライセンスファイルをテンプレートから作成する機能があります。「Add file」→「Create new file」でファイル名に LICENSE（すべて大文字）と入力すると、「Choose a license template」ボタンが現れます。これを押してリストから MIT License を選ぶと、年と著作権者名を埋めるだけで全文が挿入されます。

著作権者名の欄は、本名である必要はありません。ハンドルネームやサイト名による著作権表示も一般に有効とされており、匿名運用の方針であれば GitHub のユーザー名やブログ名で統一するのが自然です（厳密な法的効果が気になる場合は専門家への確認をおすすめします）。コミットすると、リポジトリのトップページに「MIT license」の表示が自動で付き、訪問者がひと目で利用条件を判断できるようになります。

公開後の確認とハマりポイント

リポジトリを公開したら、作業は終わりではありません。「第三者からどう見えているか」を確認して、初めて公開作業が完了します。ここでは公開直後に行いたい 2 つの確認と、作業でつまずきやすいポイントを整理します。

公開ページの見え方確認

まず、ログアウトした状態（またはブラウザのシークレットウィンドウ）でリポジトリの URL を開き、第三者視点での見え方を確認します。チェックしたいのは次の 3 点です。

README が正しく表示されているか

Markdown の見出しやリストが意図どおりに描画されているか、スクリーンショットの画像リンクが切れていないかを確認します。

ライセンス表示が付いているか

リポジトリ上部に「MIT license」の表示が出ていれば、GitHub がライセンスファイルを正しく認識しています。表示されない場合は、ファイル名が LICENSE になっているか、テンプレートの文面を大きく改変していないかを確認します。

ファイル一式が揃っているか

配布物として必要なファイル（ツール本体・README・LICENSE）が過不足なく並んでいるかを見ます。

あわせて、実際にファイルをダウンロードして動作確認しておくと確実です。リポジトリのトップページにある「Code」ボタンから「Download ZIP」を選ぶと、利用者と同じ手順で一式を取得できます。展開したファイルが手元で問題なく動けば、配布状態として完成です。

メールアドレスが露出していないかの確認

匿名運用で最も重要な確認です。リポジトリのコミット履歴（ファイル一覧上部のコミット数表示、または時計アイコン）から任意のコミットを開き、作成者情報を確認します。より確実に確認したい場合は、コミット詳細ページの URL 末尾に .patch を付けて開く方法があります。コミットの生のメタデータがテキスト表示され、From: 行に記録されているメールアドレスがそのまま見えます。

ここで ユーザー名@users.noreply.github.com 形式のアドレスが表示されていれば、秘匿設定が機能しています。もし本来のメールアドレスが表示されている場合は、秘匿設定（Settings → Emails）を確認した上で、露出したコミットを含むリポジトリの扱いを検討します。履歴の修正は難しいため、公開直後でファイル数が少ないうちなら、リポジトリを削除して作り直すのが結果的に早い対処になります。最初のコミットの直後にこの確認を行うことで、被害を最小限にできます。

つまずきやすいポイント

作業の流れの中で引っかかりやすい点をまとめます。

希望のユーザー名が取得済み

GitHub のユーザー名は早い者勝ちです。取れない場合は、数字や用途語を足すよりも、まずハイフンの有無や語順の入れ替えを試すと、見た目の自然さを保ちやすくなります（GitHub のユーザー名はハイフンが使えます。Gmail と仕様が異なる点に注意してください）

「Choose a license template」ボタンが出ない

ファイル名が正確に LICENSE（すべて大文字）になっていない場合、テンプレート選択ボタンは表示されません。license や License.txt では出ないため、まずファイル名を確認します。

README の画像が表示されない

手元の Markdown エディタでは表示されていた画像が、GitHub 上ではパス切れになるケースです。画像ファイルもリポジトリにアップロードし、README からは相対パス（例: images/screenshot.png）で参照するのが確実です。

Public にする心理的ハードル

「完璧になってから公開したい」と考えると、いつまでも公開できません。README とライセンスが揃っていれば配布物としては成立しています。細かな改善は公開後にコミットを重ねる形で問題なく、その履歴自体がリポジトリの信頼性になります。

自作ツールは、今回のような計算ツールに限りません。筆者が公開しているサブネット計算ツールのような、日々の実務で使う小さなツールほど、同じ手順で気軽に公開できます。

まとめ

自作ツールの GitHub 公開は、Git コマンドを使わずブラウザ操作だけで完結します。作業の本質はアップロードではなく、公開前に「外すべきもの」を整理し、公開時にライセンスで権利関係を明確にし、公開後に意図しない露出がないか確認するという 3 つの判断です。この流れを一度経験しておくと、次のツールからは迷わず公開できるようになります。

• 公開前に広告コード・API キー・個人情報・サイト固有の導線を除去
• 見せる名前（ユーザー名）と連絡用メールアドレスは分離して設計
• Gmail はハイフン不可・ピリオド無視という 2 つの仕様に注意
• リポジトリ作成より先に Settings → Emails でメール秘匿設定を有効化
• アップロード・README 編集・ライセンス付与はすべてブラウザで完結
• ライセンスがなければ全権利留保のままで、MIT ライセンスの明示が配布の前提
• 公開後は第三者視点の表示確認と noreply アドレスの確認を実施

以上、最後までお読みいただきありがとうございました。