第2章 まずは自分のGitHubを作って動かしてみる
想定学習時間: 13分
GitHubでリポジトリを作成したら、次に整えたいのがREADMEファイルです。READMEは、その名が示す通り「Read Me（私を読んで）」という意味を持ち、リポジトリの説明書としての役割を果たします。
GitHubでリポジトリを開いた際、最初にあなたの目に飛び込んでくるのがこのREADMEです。プロジェクトが何であり、何を目的にしているのか、どのようなファイルが含まれているのか、どのように使えば良いのか、そして今後何を計画しているのかなど、プロジェクトに関する重要な情報を集約する場所となります。
GitHubを使い始めたばかりの頃は、READMEの重要性を見過ごしてしまうかもしれません。例えば、次のような考えが頭をよぎることがあります。
しかし、GitHubを実務で活用するなら、READMEは非常に価値のあるものです。むしろ、初心者であるあなたほど、READMEを書く習慣を身につけるべきです。
READMEを書くことは、あなた自身がそのプロジェクトを深く理解するための効果的な手段となります。AIにコードを生成してもらうと、動くものが驚くほど早く手に入ることがありますが、「これは何のために作ったのか」「どのファイルが何を担当しているのか」「次に何を修正すべきか」といった点が整理されていないと、すぐに混乱してしまう可能性があります。
READMEは、このような混乱を防ぎ、プロジェクトの全体像を把握するための入り口です。
例えば、AIに簡単な問い合わせフォーム付きのWebページを作成してもらったとします。index.html、style.css、script.jsの3つのファイルが生成され、ブラウザで開くと一応それらしく表示される、という状況はよくあります。しかし数日後、そのリポジトリを再び開いたとき、「あれ、これは何のために作ったんだっけ？」と自分でも目的が分からなくなることがあります。
READMEがなければ、こうした疑問を毎回思い出す手間が発生します。しかし、READMEに以下のように記載されていれば、一目でプロジェクトの意味を理解できます。
このリポジトリは、AIで作成した問い合わせフォーム付きLPの試作用です。現在はHTMLとCSSの見た目確認が中心で、フォーム送信機能は未実装です。今後、スマホ表示の調整とフォーム送信処理を追加する予定です。これだけでも、プロジェクトの目的や現状、今後の方向性が明確になります。
READMEは、未来の自分への大切なメモでもあります。今のあなたはプロジェクトの内容を理解しているつもりでも、数週間後、あるいは数ヶ月後に別の作業に追われた後では、詳細を忘れてしまうものです。READMEがあるかどうかで、プロジェクトの再開のしやすさは大きく変わります。
GitHubを使う目的は、作業を積み重ねていくことです。その積み重ねを効率的に支えるのが、READMEなのです。
READMEには、最初から完璧で立派な文章を書く必要はありません。むしろ、最初は短くても構いません。最も大切なのは、プロジェクトの目的が明確に伝わることです。
READMEの基本的な構成要素として、以下のような項目を考えると良いでしょう。
これらすべてを最初から埋める必要はありません。例えば、練習用のリポジトリであれば、プロジェクト名、概要、今後やることだけでも十分に機能します。
GitHubの基本操作を練習するためのリポジトリであれば、次のようなREADMEで構いません。
# GitHub練習用リポジトリこのリポジトリは、GitHubの基本操作を練習するためのものです。## 目的リポジトリ作成、README編集、ファイル追加、コミット履歴の確認を体験します。## やること- READMEを編集する- ファイルを追加する- 変更履歴を見る- コミットメッセージを書く何も書かれていない状態と比べると、これだけでも大きく違います。
READMEは、Markdownという書き方で記述されることが一般的です。Markdownは、簡単な記号を使って見出しや箇条書き、リンクなどを表現できる軽量なマークアップ言語です。GitHubでは、README.mdというファイル名で配置すると、自動的に整形されてきれいに表示されます（.mdはMarkdownの略です）。
Markdownの記法は、最初にすべてを覚える必要はありません。よく使うものから徐々に慣れていきましょう。
# を使います。#の数で階層が変わります。# 大見出し## 中見出し### 小見出し- を使います。- ひとつ目- ふたつ目- みっつ目1. アカウントを作る2. リポジトリを作る3. READMEを書く** で囲みます。**重要**[GitHub](https://github.com/)最初は、これくらいの記法が使えれば十分です。READMEの目的は、きれいに装飾することではなく、読む人が迷わずに情報を得られるようにすることです。そして、その「読む人」には、未来のあなた自身やチームメンバー、さらにはAIも含まれます。
現代において、READMEは人間だけでなく、AIにとってもプロジェクトの入り口となります。AIにリポジトリの内容を見せて作業を依頼する際、READMEにプロジェクトの目的や前提条件が明確に書かれていると、AIは文脈をより正確に把握しやすくなります。
例えば、READMEに次のように書かれているとします。
このリポジトリは、個人事業主向けの問い合わせフォーム付きLPを作るためのものです。現在は静的HTMLのみで、フォーム送信機能は未実装です。今後、スマホ表示の最適化と、問い合わせ内容をメール送信する処理を追加する予定です。このような説明があれば、AIに対して「READMEの『今後やること』に沿って、スマホ表示を改善して」「このプロジェクトの目的に合わせて、フォーム送信機能の実装方針を提案して」といった具体的な指示を出すことができます。
逆にREADMEがない場合、AIはファイルの内容だけを見て推測することになります。ファイル名やコードからある程度の情報は読み取れますが、プロジェクトの真の目的までは理解できません。AIにとって、目的が不明確なプロジェクトは扱いにくく、目的が明確であるほど、AIによる修正や提案の精度は向上します。そのため、AIを活用した開発を行う人ほど、READMEを書くことが推奨されます。
READMEは、AIへの「申し送り」資料としても機能します。人間のチームで仕事をする際に引き継ぎ資料が役立つように、AIに作業を引き継ぐ際も同様です。
こうした情報をREADMEに記載しておくことで、AIに作業を依頼する際のコミュニケーションが格段にスムーズになります。
実務では、READMEに次のような項目を含めると便利です。
例えば、AIアプリの試作であれば、以下のようなREADMEが考えられます。
# AIチャットボット試作このリポジトリは、LINE公式アカウントと連携するAIチャットボットの試作用です。## 目的ユーザーからの問い合わせに対して、AIが一次回答を行う仕組みを検証します。## 現在の状態- 基本的な画面設計のみ- LINE連携は未実装- AI回答部分はダミーデータで検証中## 今後やること- LINE Messaging APIとの連携- OpenAI APIとの接続- 回答ログの保存- 管理画面の作成## 注意点APIキーやパスワードはリポジトリに含めないこと。この程度の情報でも、後から見返したときにプロジェクトの状況を把握しやすくなります。
READMEを書く際に気をつけたいのは、最初から完璧なものを目指しすぎないことです。まだ何を作るか決まっていない、どこまで実装できるか分からない、構成が途中で変わるかもしれない、といった状況はよくあります。それでも構いません。
READMEは、プロジェクトと一緒に成長させていくものです。最初は短く書き始め、作業が進んだら追記し、仕様が変わったら修正し、未実装のものは未実装と明記し、分かっていないことは正直に「分かっていない」と書きましょう。
READMEは、完成品の説明書であると同時に、制作途中の「地図」でもあります。特にAI開発においては、この「途中の地図」が非常に重要です。AIに何かを依頼する際、人間の頭の中にだけある前提は伝わりません。「だいたい分かるだろう」と思っても、AIは書かれている情報やリポジトリの状態に基づいて判断します。だからこそ、READMEに前提や目的、次にやるべきことを明確に記述しておくことで、AIとのやり取りがより安定し、効率的になります。
READMEは、プロジェクトの「玄関」です。玄関が散らかっていたり、何も書かれていなかったりすると、中に入る人は戸惑います。短くても整理されたREADMEがあれば、プロジェクトに入りやすくなります。これは、人間にとってもAIにとっても同じです。
最初のREADMEに必要なのは、立派な文章ではなく、正直な説明です。
この4つの点を書くだけでも、READMEとして十分に役立ちます。
GitHubに慣れていないうちは、READMEを書くこと自体が練習になります。見出しを作成し、箇条書きを使い、文章を少し修正し、コミットしてGitHub上で表示を確認する。この一連の流れだけでも、GitHubの基本操作に慣れることができます。
READMEは、コードが書けない人でも始められるため、GitHub初心者の最初の練習として非常に適しています。AI時代にGitHubを効果的に使うためには、まずREADMEを書く習慣を身につけることが、非常に実用的なアプローチと言えるでしょう。
リポジトリを作成したら、READMEを書き、そこに目的、現状、次にやることなどを明確に記述する。そして、AIに作業を依頼する際も、このREADMEを前提とする。この流れができると、GitHubは単なるファイルの置き場ではなく、プロジェクトの意味が見える場所となり、未来の自分への引き継ぎ、チームや外注先との共有資料、そしてAIに作業を依頼するための入り口へと変わります。
READMEを書くことは、プロジェクトに「言葉」を与えることです。言葉があるからこそ目的が見え、目的が見えるからこそ次の作業が決まり、次の作業が決まるからこそAIにも依頼しやすくなります。
GitHubを使い始めたら、ぜひREADMEを書いてみてください。短くても構いません。途中で変更しても構いません。間違っていても、後で修正すれば良いのです。大切なのは、何もないリポジトリに、最初の意味を与えること。READMEは、そのための最初の一行となるでしょう。
人にたとえると
新しい部署を立ち上げる際、その部署が何をするのか、どう進めるのかをまとめる場面。
部署の責任者が、まず部署の設立趣旨書を作成します。この書類には、部署の目標、現在の準備状況、今後の計画が簡潔に記されています。新しく配属されたメンバーは、この趣旨書を読むことで、すぐに部署の全体像を把握し、自分の役割を理解できます。また、業務をサポートするAIアシスタントも、趣旨書の内容を基に、適切な作業提案や情報整理を行うことができます。これにより、全員が同じ方向を向いてスムーズに業務を開始できます。