GitHubのREADME画像が出ないときの確認順
※本サイトの記事にはアフィリエイト広告（PR）を含む場合があります
ポートフォリオのREADMEに画像を入れたのに、GitHubでは表示されない。先に確認するのは画像の保存先とリンクの書き方です。画像を見せるために、非公開のリポジトリを公開へ変える必要はありません。
応募書類を送る前なら、GitHubへ未ログインの人が同じ資料を見られるかも確認します。ただし会社の資料や個人情報を外へ出してよいかは、表示の不具合と別の問題です。社内の画面や未許可の制作物を、確認のためだけに公開しないでください。
画像の場所を一つに決める
READMEと画像の位置関係を、まず紙に書きます。GitHubはREADMEからの相対パスを解釈します。相対パスとは「今読んでいるファイルから、どこへ進むか」を表す書き方です。
たとえば、ルートにREADME.mdがあり、同じ場所のdocsフォルダ内にscreen.pngがあるとします。画像への指定はdocs/screen.pngが基本です。PCのデスクトップへの道順は、GitHub上のファイルの道順とは違います。
ローカルのプレビューだけで見えたときほど注意します。PC内にだけ存在する画像なら、自分の画面で表示できても相手には届きません。GitHubのファイル一覧に、該当画像が実際にあるかを確認してください。
表示の問題を直す最初の単位は、画像一枚です。 全画像の置き換えや、外部の画像サービスへの移動から始めない方が、原因を追いやすくなります。
確認する順番
最初に、GitHubのファイル一覧で画像を開きます。開けなければ、READMEの書式より保存やアップロードの問題が先です。ファイル名を見て、想定している画像そのものか確認します。
次にREADMEを開き、画像への指定と実際の場所を照らし合わせます。フォルダが一つ深くないか、拡張子が違わないか、名前の大文字と小文字が一致するかを見ます。似た名前の別ファイルも確認してください。
READMEがdocs内にある場合は、ルートにあるREADMEと同じ相対パスを流用できるとは限りません。出発点が変わるためです。上の階層へ戻る必要があるなら、その位置関係を先に確認します。
GitHub公式は、現在のファイルを基準にしたパスと、リポジトリのルートを基準にしたパスを説明しています。自分で書き方を混ぜず、どちらを使ったか決めてから直します。
最後に、直したREADMEをGitHubの表示画面で開きます。編集画面のプレビューだけで終えず、保存後の内容を見てください。修正が別のブランチに入っていないかも確認します。
最小の画像記法から確認
装飾を外したMarkdownの記法で、一枚だけ表示を試します。Markdownは文章に簡単な記号で見出しやリンクを付ける形式です。最初から横並びやサイズ指定を加えると、画像の場所と装飾の問題が混ざります。
コードを含める場合は、実際の画像の場所に合わせます。たとえばREADMEと同じ階層のdocs内なら、次の形です。
表示できたら、必要な説明文を付けます。「画像」「スクリーンショット」だけでなく、何を示す画面か分かる説明にしてください。画像が表示されないときにも、内容を伝える手がかりになります。
画面の中へ重要な説明を詰め込まない方が、読み手は判断しやすくなります。操作の目的や設計理由は本文へ書き、画像は具体的な画面を補う役割にします。
他人の画面での確認
応募先へ送る資料は、自分のログイン状態だけで判定しません。閲覧権限のある別の確認者に見てもらうか、許された範囲でログイン状態の違いを確認します。ログインが必要なURLなら、相手も見られるとは限りません。
ただし、非公開の資料を見せるために公開設定を変える行動は避けます。閲覧権限を付けてよい相手か、提出形式に指定があるかを確認してください。企業秘密や個人情報を含む画像なら、元の資料の扱いから見直します。
画面内では、名前、メール、顧客名、管理画面のURLも点検します。ブラウザのタブや通知、サイドバーに別の情報が入っていないかも見ます。ダミーの情報で撮り直せるなら、その方が後から隠す作業を減らせます。
見せたい画面と、見せてよい画面は別です。 README画像の不具合を直した後に、内容の点検も一度通します。
応募前に直す説明
画像が表示できても、何のために作ったアプリか分からないと、作品の意図が伝わりません。READMEの冒頭には、想定する利用者と解決する困りごとを書きます。機能の列挙だけにしないでください。
画像の直前には「何を入力すると、どう変わる画面か」を短く添えます。たとえば家計アプリなら、入力画面と集計結果の関係です。画像二枚を並べるより、操作の順番が分かる文章が役立つ場合があります。
作った範囲と未実装の範囲も分けます。スクール教材を元にした部分と、自分で変更した部分があるなら、その違いを書いてください。動かない機能を、画像だけで実装済みに見せないようにします。
職種自体の方向性を迷っている場合は、IT/Web転職タイプ診断（無料）も整理のきっかけになります。ただし診断結果だけで応募先を決めず、希望する仕事と作品の説明を照らし合わせてください。
フォルダ移動後の実例
例として、READMEをルートからdocsへ移した場面を考えます。画像もdocs内にあるなら、以前のdocs/screen.pngという指定は、移動先からさらにdocsへ進む指定になります。出発点を変えたのに、道順だけを残した状態です。
この例では、READMEのある場所から画像までの位置を描き直します。画像が同じフォルダならscreen.png、下のimages内ならimages/screen.pngです。ファイルをどこへ置くかは一例であり、決まったフォルダ名を使う必要はありません。
GitHubのファイル一覧で画像を開けるなら、そのファイル名をコピーして比較します。自分のPCだけにある絶対パスを、GitHub用の画像リンクへ貼り直さないでください。
修正の記録は「移動前のREADMEの場所」「移動後の場所」「直した画像の指定」の三つで足ります。面接で改善した点を聞かれたときも、表示できた結果だけでなく、原因をどう分けたか説明できます。
よくある質問
スマホでは見えるのにPCで消える？
同じURL、同じブランチ、同じアカウント権限かをそろえます。表示するREADME自体が違っていないか確認し、画像の場所をもう一度開いてください。端末だけの問題と最初から断定しません。
外部サイトの画像URLなら簡単？
保存先の閲覧権限や移動・削除の影響も受けます。自分に保存・再配布する権利がある画像なら、管理する場所と利用条件を決めます。他人の画像を無断でコピーするための解決策にはしません。
応募直前で直し切れない場合は？
提出方法の指定を確認し、必要なら画像を含む別形式を使えるか担当者へ相談します。壊れたURLをそのまま送り、相手側の環境のせいにしないでください。送信前に提出物を開き直す時間を残します。
※本記事は一般的な情報提供を目的としたもので、転職・収入を保証するものではありません。
あわせて読みたい
参考にした情報
- GitHub公式：READMEと画像の相対パス（本文確認日：2026年11月7日）