AIコーディングで小さなアプリを作れても、「これをどう見せればよいのか」「GitHubに公開して大丈夫か」と迷うことがあります。結論から言うと、作品数を増やすより、何を解決する作品か・どう動かすか・どこを自分で確認したかをREADMEとデモで伝えるのが先です。
この記事では、AIを使って作った成果物をGitHubのポートフォリオとして整理する手順を紹介します。採用や案件獲得を保証するものではなく、第三者が内容を確かめやすくするための基本形です。
この記事が向いている人・向いていない人
- 向いている人：AIと一緒に作ったアプリやWebページを、学習記録や応募時の作品例として整理したい人
- 向いていない人：作品を作る前に、ポートフォリオを載せる専用サイトや高度なデザインを完成させたい人。まずはGitHubのREADMEと動作画面だけで十分です
AIコーディングの成果は「作品の説明」で伝わりやすくなる
GitHubのREADMEは、リポジトリを訪れた人にプロジェクトの目的や使い方を伝える場所です。コードだけを置くと、何の課題を解決するのか、起動できるのか、AIに任せた範囲と自分で判断した範囲が見えにくくなります。
まずは公開したい作品を1つ選び、第三者が数分で概要と動作確認の方法をつかめる状態を目指しましょう。AIコーディングの練習段階なら、独学記事の手順に沿って作った小さな成果物から始められます。
公開前に確認する5項目
1. 誰のどんな困りごとを解決するか
「勉強のために作った」だけで終わらせず、想定する利用者と使う場面を一文にします。たとえば「毎日の作業時間を記録し、週ごとの合計を確認する個人用ツール」のように、機能と目的を具体化します。実在の顧客や勤務先の情報を使った場合は、公開してよいかを先に確認してください。
2. 動作画面と試し方を用意する
画面のスクリーンショットを1〜3枚載せ、可能なら安全なデモURLを付けます。デモを公開できない場合は、必要なソフト、起動コマンド、テスト用データをREADMEに記載すれば、読む人が確認する道筋を示せます。ログイン情報や個人データを含む画面は掲載しません。
3. READMEに「目的・機能・起動方法・確認結果」を書く
GitHub公式ドキュメントでも、READMEにはプロジェクトが役立つ理由や使い方、始め方を説明できると案内されています。最初は次の項目を埋めれば形になります。
- 作品名と一文の説明
- 解決したい課題、主な機能
- 画面画像またはデモへのリンク
- 必要な環境と起動手順
- 自分が設計・修正・確認した内容
- 既知の制限と、今後直したい点
機能を大きく見せるより、「どこまで動作を確認したか」を正直に書くほうが、再現する人に役立ちます。テストをしていない部分を、確認済みのように書かないでください。
4. AIの利用範囲と自分の判断を分けて説明する
AIが生成したコードをそのまま作品として説明するのではなく、どの作業でAIを使い、どの部分を自分で選び直したのかを整理します。例として「画面のたたき台とエラー原因の候補出しにAIを利用。入力チェック、表示崩れ、依存パッケージの確認は自分で実施」のように、実際に行った範囲だけを書きます。
公開前に変更差分を読み、使い方と違う動きがないか確かめましょう。AI生成コードの確認項目は公開前に差分・権限・テストを確認する手順、意図しない変更の戻し方はVS CodeとGitで変更を元に戻す方法で詳しく整理しています。
作った機能が動かない場合は、公開前に原因を切り分けます。AIが生成したコードのエラーを確認する手順も参考になります。
5. 公開リポジトリから秘密情報を外す
公開範囲を決める前に、APIキー、アクセストークン、パスワード、個人情報、業務データが含まれていないか確認します。環境変数のファイルをGit管理から外す設定を先に行い、サンプル設定には実際に使える秘密値を入れないでください。
GitHubのpush protectionは対応する秘密情報の誤送信を止める仕組みですが、全ての機密情報を検出できる前提にはできません。保護機能があっても、公開前にファイルと差分を自分で点検します。もし有効なキーを公開してしまった場合、履歴から文字列を消すだけでは不十分なことがあるため、発行元でキーを無効化・再発行し、GitHub公式の機密情報削除手順を確認してください。
会社のコードや未公開データをAIへ入力してよいか迷う場合は、会社コードをAIに渡す前の確認手順も先に確認してください。
GitHubでポートフォリオを見せる手順
- 小さく完成した作品を選ぶ：READMEで説明でき、手順どおりに動作確認できるものを選びます。
- ローカルで最後の確認をする：新しいフォルダーにクローンした想定で起動手順を読み直し、主要機能とテストを確認します。
- 秘密情報・権利・公開範囲を点検する：個人情報や業務データがないか、画像・素材・依存ライブラリを公開利用してよいか、リポジトリを公開してよいか確認します。
- GitHubにリポジトリを作る：プロジェクト名と短い説明を付け、公開または非公開を選びます。作品を見せる目的で公開する場合も、公開して問題のない内容か先に確かめます。
- READMEと画像を追加する：目的・機能・起動方法・確認結果を先頭から読める順に置き、画像の説明も添えます。
- プロフィールから代表作へ案内する：複数作品があるなら、応募先や学びたい分野に関係するものを選んで固定表示します。数を並べるより、代表作の説明を整えるのが先です。
READMEはリポジトリを開いたときに表示され、GitHubプロフィールでは代表リポジトリをピン留めできます。作品を増やす前に、まず1つを最後まで説明できる形にしましょう。
よくある失敗と直し方
機能を詰め込み、何の作品か分からない
最初に伝える機能を1〜3個に絞り、追加予定は「今後の課題」へ分けます。読む人が最初の一文で用途を想像できるか確認します。
READMEがなく、起動方法を探させてしまう
READMEに実行環境、必要な設定、コマンド、確認できる結果を順番に書きます。コマンドを載せるときは、説明文どおりに実行できるか自分でも確認します。
AIを使った事実だけを書き、判断内容が見えない
利用した工程だけでなく、仕様の選択、テスト、修正、既知の制限を説明します。開発過程や成果を誇張せず、確認できる内容に留めてください。
よくある質問
作品が1つだけでもポートフォリオになりますか？
数だけで判断する必要はありません。目的・動作・確認方法を説明できる作品が1つあれば、まずその作品を見せる準備を進められます。応募で評価されるかどうかは、募集内容や相手の判断によります。
AIが書いたコードを公開してもよいですか？
AIを使ったという理由だけで公開可否は決まりません。機密情報がないこと、使用したコードや素材を公開できること、内容を理解して動作を確認したことを確かめ、必要なら利用中のサービスや組織のルールも確認してください。
Webサイトを別に作る必要がありますか？
最初から専用サイトを作る必要はありません。GitHubのREADMEとプロフィールで作品へ案内し、作品が増えてから必要に応じてまとめページを検討できます。
まとめ：まず1作品を説明できる形に整える
AIコーディングの成果を見せるときは、作品数より「何を作ったか」「どう動かすか」「自分でどこを確認したか」を揃えるのが出発点です。GitHubの公開設定を決める前に秘密情報や素材の権利も確認し、READMEを読んだ人が安全に試せる範囲を明記しましょう。
依頼文の組み立てから練習したい人はAIコーディングの指示文テンプレートへ、独学で進める順番を知りたい人はAIコーディングの独学手順へ。学習環境やPCの選び方をまとめて見たい人はAI作業環境のハブも使えます。つまずきが続き、質問先やカリキュラムが必要だと感じた場合は、バイテックGEEKの料金・学習内容と独学の違いで相談や受講が向く条件を比較できます。
