オリジンとは｜Webの同一オリジンとgitのoriginを実測で解説

この記事で実際に動かしたもの：127.0.0.1 の 8701・8702 番ポートに立てた自作の Web サーバー2つと Chromium 153（同一オリジン・別オリジンの fetch・Cookie・localStorage・iframe・canvas）、手元に作った空のリポジトリでの git の clone・push・remote 操作、オリジンサーバーの前に置いた自作のキャッシュ中継です。

「オリジン」は、IT の外でも中でも使われる言葉です。困りごとの多くは、いま読んでいる文章が「どのオリジン」の話なのかを取り違えるところから始まります。最初に全体の地図を示します。

flowchart LR
    A[オリジン<br>起源] --> B[Web]
    A --> C[git]
    A --> D[CDN]
    A --> E[配列]
    B --> B1[スキーム・<br>ホスト・ポート]
    C --> C1[clone元の<br>リモート名]
    D --> D1[元データの<br>サーバー]
    E --> E1[数え始め<br>0か1か]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS の上で、Python 3.13.18 の http.server で作った自作の Web サーバーを 127.0.0.1 の 8701 番と 8702 番で同時に起動し、届いたリクエストの Host・Origin・Sec-Fetch-Site・Cookie をすべて記録しました。ブラウザは Chromium 153.0.8010.12（Chrome for Testing）を playwright-core 1.63.0 から日本語の設定で動かし、fetch・localStorage・sessionStorage・Cookie・iframe・postMessage・canvas・window.open・file: のページの挙動を確かめています。URL のオリジンは Chromium の new URL() で求めました。git は 2.43.0 を使い、作業用の一時フォルダーに作った bare リポジトリを clone して、remote・push・fetch・rename の出力とエラー文を取りました。CDN のオリジンサーバーは、自作のキャッシュ中継（8703番）を 8701 番の前に置いて curl 8.5.0 で確かめています。外部のサービスには接続していません。オリジンと同一オリジンポリシーの定義は MDN と web.dev、git の既定の名前は git の公式マニュアルで確かめました。図は mermaid-cli 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

オリジンとは（場面別の意味：ふだんの意味とITの意味）

この節では、「オリジン」という言葉が、ふだんの言葉と IT の各分野でそれぞれ何を指すのかが分かります。

オリジンは英語の origin で、もとの意味は「起源・出どころ・原点」です。 IT の言葉としてのオリジンも、どれも「どこから来たか」「どこが元か」という意味から派生しています。違うのは、何を「元」と見なすかです。

このほか、ゲームの配信サービスの名前や企業名・弁当チェーンの名前としての「オリジン」もありますが、IT の技術の話で出てくるのは上の4つ（Web・git・CDN・配列）がほとんどです。以下では、検索されることの多い Web と git を中心に、実際に動かした結果で説明します。

Webのオリジンとは（スキーム・ホスト・ポートの3つ）

この節では、Web のオリジンが URL のどの部分で決まるのかと、同一オリジン・別オリジンの判定のしかたが分かります。

Web のオリジンは、URL の「スキーム（http・https など）」「ホスト（ドメイン名や IP アドレス）」「ポート番号」の3つの組です。 3つがすべて同じなら同一オリジン、1つでも違えば別オリジン（クロスオリジン）です。パス・クエリ・# 以降・ユーザー名は含みません。

https://www.example.com:8443/blog/post?id=1#top
└─┬──┘   └──────┬──────┘ └┬─┘└──────────┬─────────┘
スキーム       ホスト      ポート   ここから先はオリジンに含まない
└──────────────┬──────────────────┘
          オリジン = https://www.example.com:8443

URL からオリジンを求めた結果（Chromium 153）

Chromium の new URL(…).origin で、いろいろな URL のオリジンを求めました。既定のポート（http は 80、https は 443）は書いても書かなくても同じ扱いになり、表示からは省かれます。

同一オリジンか別オリジンか（判定表）

基準を http://127.0.0.1:8701/page として、手元で実際に開いた相手との関係を並べます。「サイト」の列は後の節で説明する、オリジンより広いまとまりです。Chromium がリクエストに付けた Sec-Fetch-Site ヘッダーの値をそのまま載せています。

• localhost と 127.0.0.1 は、同じ機械を指していても別オリジンです。 ブラウザはホストを文字列で比べるため、名前が違えば別の相手として扱います。
• www の有無も別オリジンです。 https://example.com と https://www.example.com はホストが違います。

最初の5分：自分のページのオリジンを確かめる

同一オリジンポリシーとは（何を止めて、何を止めないか）

この節では、オリジンという考え方が何のためにあるのかと、ブラウザが別オリジンに対して何を止めるのかが分かります。

同一オリジンポリシー（Same-Origin Policy）は、あるオリジンのページで動くスクリプトが、別のオリジンのデータを勝手に読めないようにするブラウザの決まりです。 たとえば、ふだん見ているサイトのスクリプトが、同じブラウザでログイン中のメールや社内システムの中身を読み取れてしまうと困ります。オリジンは、その「読んでよい範囲」を区切る単位です。

MDN は、オリジンをまたぐやりとりを「書き込み」「埋め込み」「読み込み」の3つに分けて説明しています。手元の結果と合わせると次のようになります。

大事なのは、同一オリジンポリシーが止めるのは主に「読み取り」で、リクエストの送信そのものではないという点です。次の節で、別オリジンへの fetch がサーバーには届いていた記録を示します。

オリジンが違うとfetchはどうなるか（CORSエラーとの関係）

この節では、別オリジンの API を fetch したときに何が起きるのかを、ブラウザの表示とサーバーの記録の両方から確かめた結果が分かります。

別オリジンへの fetch は、相手のサーバーが Access-Control-Allow-Origin で許可しない限り、応答を読めずに失敗します。 これが CORS エラーです。CORS（オリジン間リソース共有）は、同一オリジンポリシーの「読み取り禁止」を、サーバーの許可で緩める仕組みです。

8701番のページから、5通りの fetch を実行しました。

await fetch('/api')                                  // 同一オリジン
await fetch('http://127.0.0.1:8702/api')             // ポート違い・許可なし
await fetch('http://127.0.0.1:8702/api-cors')        // ポート違い・許可あり
await fetch('http://localhost:8701/api')             // ホスト違い・許可なし
await fetch('http://127.0.0.1:8702/api', {mode: 'no-cors'})

許可の無い fetch では、コンソールに次の文言が出ました。

Access to fetch at 'http://127.0.0.1:8702/api' from origin 'http://127.0.0.1:8701' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Failed to load resource: net::ERR_FAILED

文言の中の from origin 'http://127.0.0.1:8701' が、ブラウザが判断に使った「呼び出し元のオリジン」です。ここに出ているオリジンと、サーバーが Access-Control-Allow-Origin に書いた値が1文字でも違えば読めません。 許可した 8702番の応答は、次のヘッダーを付けていました。

HTTP/1.0 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: http://127.0.0.1:8701
Vary: Origin

mode: 'no-cors' はエラーを消しますが、応答は中身の無い「opaque（不透明）」になります。CORS エラーを避ける方法ではありません。CORS エラーの文言ごとの直し方とサーバー側の設定例は、関連記事「CORSエラーの原因と解決方法｜エラーメッセージ別に解説」で扱っています。この記事では、その前提になる「オリジンとは何か」に絞ります。また、Failed to fetch はオリジン以外（サーバーの停止・証明書・広告ブロック）でも出ます。原因の切り分けは関連記事「Failed to fetchの原因と直し方｜fetchエラー」で扱っています。

localStorage・Cookieとオリジン（ポート違いの実測）

この節では、ブラウザに保存するデータがオリジンごとに分かれるのか、ポートやホストが違うとどうなるのかが分かります。

localStorage と sessionStorage はオリジンごとに分かれます。Cookie はオリジンではなくホスト名で分かれ、ポートを区別しません。 同じ「ブラウザの保存場所」でも、区切りの単位が違います。

localStorage はポートが違えば見えない

8701番のページで localStorage.setItem('k205', 'set-on-8701') を実行し、同じブラウザで3つの URL を開いて読みました。

開発中に「保存したはずの値が消えた」と感じるとき、多くは開発サーバーのポートが変わったか、localhost と 127.0.0.1 を行き来したことが原因です。値は消えておらず、別の保存場所を見ています。なお sessionStorage は、オリジンに加えてタブごとにも分かれるため、新しいタブではどれも null でした。

Cookie はポートが違っても送られる

8701番で Set-Cookie: c205=from8701; Path=/ を返したあと、各ページを開いたときにサーバーが受け取った Cookie ヘッダーです。

同じ 127.0.0.1 で複数のアプリを別ポートで動かすと、Cookie の名前がぶつかって上書きし合うことがあります。セッション Cookie の名前はアプリごとに変えるのが安全です。保存場所ごとの違い（容量・期限・送信の有無）は関連記事「localStorage・sessionStorage・Cookieの違い｜実測比較」で扱っています。

iframe・canvas・ポップアップとオリジン

この節では、ページの中に別のページや画像を入れたとき、オリジンによって何ができて何ができないのかが分かります。

別オリジンの iframe や画像は「表示」はできますが、スクリプトから「中身を読む」ことはできません。 ページ同士でデータを渡したいときは postMessage を使います。

iframe の中に触れるか

SecurityError: Failed to read a named property 'document' from 'Window': Blocked a frame with origin "http://127.0.0.1:8701" from accessing a cross-origin frame.
SecurityError: Failed to read a named property 'href' from 'Location': Blocked a frame with origin "http://127.0.0.1:8701" from accessing a cross-origin frame.

別オリジンの iframe では contentDocument は null になり、contentWindow.location.href を読むことも止められました。MDN によれば、別オリジンのウィンドウで使えるのは postMessage・close・focus・blur などの限られたメソッドと、location への書き込みなどだけです。sandbox 属性に allow-same-origin を付けないと、同じサーバーのページでもオリジンが null になり、親から中に触れなくなります。iframe の書き方と表示されない原因は関連記事「HTML iframeの使い方｜レスポンシブ・sandbox・表示されない原因」で扱っています。

postMessage では必ず送り主のオリジンを確かめる

message イベントの event.origin には、送り主のオリジンがブラウザによって入ります（上の表の3列目は実際に入った値です）。受け取る側は、想定したオリジンかを最初に確かめます。

window.addEventListener('message', (event) => {
  if (event.origin !== 'http://127.0.0.1:8702') return; // 想定外の送り主は無視
  console.log('受け取った', event.data);
});

canvas は別オリジンの画像で「汚れる」

2×2画素の橙色の PNG を canvas に描き、getImageData で画素を読みました。

画像の加工や書き出し（toDataURL）で SecurityError が出るときは、画像側のサーバーで CORS を許可し、img に crossOrigin を付けます。片方だけでは読めません。

about:blank のポップアップは開いた側のオリジンを受け継ぐ

8701番のページから window.open('about:blank') で開いた窓は、location.href が about:blank のまま、origin は http://127.0.0.1:8701 でした。開いた側から document.body に文字を書き込むこともできました。URL にオリジンの情報が無いページは、作ったページのオリジンを受け継ぎます。

Originヘッダーとサーバーから見たオリジン

この節では、ブラウザがリクエストに付ける Origin ヘッダーと Sec-Fetch-Site ヘッダーが、いつ・どんな値で付くのかが分かります。

Origin ヘッダーは、リクエストを出したページのオリジンをサーバーに伝えるヘッダーです。 中身はスキーム・ホスト・ポートだけで、パスは含みません。サーバーは CORS の許可を判断するときにこの値を見ます。手元のサーバーで受け取った値を並べます。

MDN の説明どおり、Origin は「オリジンをまたぐ CORS のリクエスト」と「GET・HEAD 以外の同一オリジンのリクエスト」に付きました。curl には Origin も Sec-Fetch-Site も付かないため、curl では CORS のエラーが再現しません。CORS はブラウザの決まりで、サーバーとの通信そのものの決まりではないからです。

サーバー側で Origin を使って判断するときは、許可するオリジンを完全一致の一覧で持ちます。example.com を含むかどうかのような部分一致では、example.com.another.test のような別のホストも通ってしまいます。

ALLOWED = {"https://app.example.com", "http://127.0.0.1:8701"}

def cors_headers(origin):
    if origin in ALLOWED:          # 完全一致で比べる
        return {"Access-Control-Allow-Origin": origin, "Vary": "Origin"}
    return {}

オリジンがnullになる場面と、オリジンとサイトの違い

この節では、オリジンが「null」になるのはどんなときかと、似た言葉の「サイト（same-site）」との違いが分かります。

オリジンが null になる場面

null は「どのオリジンとも同じと見なさない特別なオリジン（不透明なオリジン）」を表す値です。 null 同士も同一オリジンにはなりません。手元で null になったのは次の場面です。

file: で開いたページから同じフォルダーのファイルを fetch すると、次のエラーになりました。HTML を直接ダブルクリックで開いて動かないときは、python3 -m http.server などで http のサーバーから開くと解決します。

Access to fetch at 'file:///dev/shm/t205/f.html' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: chrome, chrome-extension, chrome-untrusted, data, http, https, isolated-app.

なお、Access-Control-Allow-Origin: null で許可するのは避けます。null になる文書は sandbox や data: など誰でも作れるため、「null を許可する」は「出どころの分からない相手を許可する」ことに近くなります。

オリジンとサイトの違い

サイトは、オリジンより広いまとまりで、「スキーム」と「登録できるドメイン（eTLD+1）」で決まります。ポートとサブドメインは区別しません。 web.dev は、.co.jp や .github.io のような公開サフィックスの1つ上（例：example.co.jp）をサイトの単位と説明しています。

手元でも、ポートだけが違う 8702番は Sec-Fetch-Site: same-site、ホスト名が違う localhost は cross-site でした。Cookie の SameSite 属性が見ているのは、名前どおり「サイト」の単位です。SameSite の挙動は関連記事「CSRF対策とSameSite｜Cookie送信をChromeで実測し多層防御を実装」で扱っています。

gitのoriginとは（リモートリポジトリの呼び名）

この節では、git のコマンドに出てくる origin が何者なのかを、実際に clone して設定ファイルを見た結果で説明します。

git の origin は、clone したときに git が自動で付ける「リモートリポジトリの名前」です。 特別な機能があるわけではなく、git push origin main の origin は「origin という名前で登録した URL」の短い呼び名です。git の公式マニュアルは、clone で作るリモートの名前は既定で origin で、--origin（-o）か設定の clone.defaultRemoteName で変えられる、と説明しています。

clone した直後の様子

$ git init -q --bare -b main server.git
$ git clone server.git work
Cloning into 'work'...
warning: You appear to have cloned an empty repository.
done.
$ cd work
$ git remote
origin
$ git remote -v
origin	/dev/shm/t205/g/server.git (fetch)
origin	/dev/shm/t205/g/server.git (push)

origin の正体は、リポジトリの .git/config に書かれた数行です。

[remote "origin"]
	url = /dev/shm/t205/g/server.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
	remote = origin
	merge = refs/heads/main

• url：origin が指す先。GitHub なら https://github.com/… や git@github.com:… が入ります。
• fetch：リモートの refs/heads/*（ブランチ）を、手元の refs/remotes/origin/* に写す、という決まり。これが origin/main の出どころです。
• [branch "main"]：手元の main が、origin の main を追いかける（追跡する）という設定。git push -u origin main で書き込まれます。

名前は変えられる

-o を付けて clone すると、origin 以外の名前になりました。名前が違っても動きは同じです。

$ git clone -o hub server.git w2
$ cd w2
$ git remote -v
hub	/dev/shm/t205/g/server.git (fetch)
hub	/dev/shm/t205/g/server.git (push)
$ git branch -a
* main
  remotes/hub/HEAD -> hub/main
  remotes/hub/main

remote の追加・変更・削除と、push が拒否されたときの対処は関連記事「git remoteの変更・追加・削除とpush rejectedの対処法」で扱っています。この記事では「origin とは何か」までに絞ります。

origin/main・origin main・upstreamの違い（gitのorigin）

この節では、似た書き方の origin/main と origin main の違いと、fork でよく出る upstream との関係が分かります。

origin/main（スラッシュあり）は「最後に通信したとき、origin の main がどこにあったか」を手元に記録したブランチです。origin main（スペースあり）は、コマンドに「origin というリモートの、main ブランチ」と2つの引数を渡す書き方です。

origin/main は fetch するまで更新されない

別の clone（w2）から新しいコミットを push したあと、work で確かめました。fetch する前は、手元の記録が更新されていないため「差は無い」と表示されます。

$ git status -sb
## main...upstream/main
$ git log --oneline -1 upstream/main
0a926a7 second
$ git fetch upstream
From /dev/shm/t205/g/server
   0a926a7..d69e947  main       -> upstream/main
$ git status -sb
## main...upstream/main [behind 1]

git status の「up to date」は、リモートと比べた結果ではなく、手元の記録と比べた結果です。 最新の状態と比べたいときは、先に git fetch を実行します。fetch は記録を更新するだけで、手元のブランチは動かしません。

push -u で追跡の設定が入る

$ git push -u origin main
To /dev/shm/t205/g/server.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.
$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

-u で追跡を設定しておくと、次からは git push・git pull だけで origin の main が相手になります。git remote show origin では、その設定がまとめて見えます。

* remote origin
  Fetch URL: /dev/shm/t205/g/server.git
  Push  URL: /dev/shm/t205/g/server.git
  HEAD branch: main
  Remote branch:
    main tracked
  Local branch configured for 'git pull':
    main merges with remote main
  Local ref configured for 'git push':
    main pushes to main (fast-forwardable)

fork したときの origin と upstream

GitHub などで fork して clone すると、origin は自分の fork を指します。fork 元の更新を取り込むために、元のリポジトリを upstream という名前で足すのが慣習です。名前は決まりではなく、git remote rename origin upstream のように付け替えても、追跡の設定は新しい名前に合わせて書き換わりました（git branch -vv の表示が [upstream/main: ahead 1] に変わった）。

CDNのオリジンサーバーと0オリジン・1オリジン

この節では、Web と git 以外でよく出る「オリジンサーバー」と「0オリジン・1オリジン」の意味が分かります。

オリジンサーバー（CDN の奥にある元のサーバー）

オリジンサーバーは、CDN やキャッシュの中継が「元のデータを取りに行く先」のサーバーです。 利用者のリクエストはまず近くの中継（エッジ）が受け、手元に無いときだけオリジンサーバーに取りに行きます。8701番をオリジンサーバー、8703番を自作のキャッシュ中継にして、同じ URL を3回取得しました。

$ for i in 1 2 3; do curl -s -D - -o /dev/null http://127.0.0.1:8703/api | grep -i x-cache; done
X-Cache: MISS
X-Cache: HIT
X-Cache: HIT

3回のうち、オリジンサーバー（8701番）に届いたリクエストは最初の1回だけでした。CDN を使っているサイトで「更新したのに前の内容が出る」のは、中継がオリジンに取りに行かず、手元の写しを返しているためです。Web のオリジン（スキーム・ホスト・ポート）とは別の意味で、こちらは「元データの置き場所」という意味です。

0オリジン・1オリジン（数え始めの番号）

0オリジンは「最初の要素を0番と数える」、1オリジンは「1番と数える」という意味です。 言語やツールによって違うため、取り違えると1つずれます。手元で「abc の最初の文字」を取り出しました。

シェルスクリプトから SQL や awk を呼ぶと、1つの処理の中に0オリジンと1オリジンが混ざります。「何番目」を扱う箇所には、どちらで数えているかを書いておくと読み違いを防げます。

オリジンでよくあるエラーとつまずき（原文つき）

この節では、Web と git でオリジンが原因になる代表的なエラーの原文と、原因・直し方が一覧で分かります。

git の does not appear to be a git repository は、手元では次の原文でした。「アクセス権」の話が書かれていますが、名前の登録が無いだけでも同じ文が出ます。

fatal: 'origin' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

判断表：どの「オリジン」の話かを見分ける

この節では、目の前の文章やエラーに出てくる「オリジン」がどの意味なのかを、順に当てはめて判断できます。

1. 1git のコマンドや出力の中にある → git のリモートの名前git push origin・origin/main・remote origin
2. 2CORS・iframe・Cookie・ブラウザのエラーの中にある → Web のオリジンfrom origin '…'・cross-origin・同一オリジン
3. 3HTTP のヘッダーとして出てくる → Web のオリジンOrigin:・Access-Control-Allow-Origin:
4. 4CDN・キャッシュ・エッジと一緒に出てくる → オリジンサーバーオリジンの負荷・オリジンへのフェッチ
5. 5配列・添字・何番目の話 → 0オリジン・1オリジン最初が0番か1番か
6. 6どれでもない → ふだんの意味（起源・出どころ）商品名・作品名・物事の始まり

Web のオリジンについて、作る側が判断に迷いやすい場面を表にしました。

• 1エラーに出ているオリジンを書き写すfrom origin '…' の値が、ブラウザが判断に使った呼び出し元
• 2呼び出し先とスキーム・ホスト・ポートを比べるhttp と https、localhost と 127.0.0.1、ポートの数字
• 3サーバーのログで届いているかを見る届いていれば、止めているのはブラウザの読み取り
• 4git なら git remote -v を最初に見るorigin という名前があるか、URL が正しいか

よくある質問

Q. オリジンとドメインは同じですか？ A. 違います。ドメイン（ホスト名）はオリジンを作る3つの部品の1つです。オリジンはそこにスキーム（http・https）とポート番号を加えた組なので、同じドメインでも https と http、8080番と443番は別オリジンです。

Q. オリジンと URL の違いは何ですか？ A. URL はページ1つずつの住所で、オリジンはその中の「スキーム・ホスト・ポート」の部分だけです。https://example.com/a と https://example.com/b は URL が違いますが、オリジンは同じ https://example.com です。

Q. ポート番号を省略した URL と、:443 を書いた URL は同一オリジンですか？ A. 同一オリジンです。https の既定のポートは 443、http は 80 なので、書いても書かなくても同じ扱いです。Chromium で new URL('https://example.com:443/').origin を求めると、https://example.com と省いた形で返りました。

Q. 同じパソコンで動かしているのに、なぜ CORS エラーになるのですか？ A. ブラウザは機械が同じかではなく、URL のスキーム・ホスト・ポートで判断するためです。手元でも、同じ 127.0.0.1 の 8701番から 8702番への fetch は読めず、localhost:8701 への fetch も読めませんでした。

Q. curl では成功するのに、ブラウザでは失敗します。 A. CORS はブラウザが守る決まりだからです。curl は Origin ヘッダーを付けず、応答の読み取りを止めることもしません。手元のサーバーでも、curl のリクエストには Origin・Sec-Fetch-Site が付いていませんでした。

Q. git の origin は消してもよいですか？ A. 消せます。git remote remove origin で消えるのは手元の呼び名と設定だけで、リモートのリポジトリ自体は消えません。ただし、そのあと git push origin main は 'origin' does not appear to be a git repository になります。

Q. origin という名前でなければいけませんか？ A. いいえ。origin は clone のときの既定の名前で、git clone -o hub のように別の名前にもできます。手元でも hub という名前で clone し、remotes/hub/main ができました。チームの手順書が origin を前提にしていることが多いため、特に理由が無ければ origin のままが分かりやすいです。

Q. origin と upstream の違いは何ですか？ A. どちらもリモートの名前で、git の機能としての違いはありません。fork して開発するとき、自分の fork を origin、fork 元を upstream と呼ぶのが慣習です。また git には「追跡先のブランチ（upstream branch）」という用語もあり、git push -u の u はこちらを指します。

Q. Access-Control-Allow-Origin に * を書けば解決しますか？ A. 誰でも読める公開データなら選択肢になりますが、Cookie などの認証情報を送るリクエストでは * は使えません。ログインが関わる API は、許可するオリジンを1つずつ書きます。

Q. 「オリジンの負荷を下げる」と言われました。どのオリジンですか？ A. CDN の話であれば、オリジンサーバー（元のデータを持つサーバー）のことです。キャッシュが効くほど、オリジンサーバーに届くリクエストは減ります。手元の中継でも、3回の取得のうちオリジンに届いたのは1回でした。

まとめ

• オリジンのもとの意味は「起源・出どころ」。IT では、Web のオリジン・git の origin・CDN のオリジンサーバー・0オリジン/1オリジンの4つがよく出てくる。
• Web のオリジンは「スキーム・ホスト・ポート」の組。1つでも違えば別オリジンで、localhost と 127.0.0.1、ポート違いも別オリジンになる。
• 同一オリジンポリシーが止めるのは主に読み取り。別オリジンへの fetch はサーバーに届いていたが、許可が無いと応答を読めなかった。localStorage はオリジンごとに分かれ、Cookie はポートを区別しなかった。
• git の origin は clone 元のリモートに付く既定の名前で、正体は .git/config の数行。origin/main は手元の記録なので、最新と比べるには先に fetch する。
• 迷ったら、Web は location.origin とエラーの from origin '…'、git は git remote -v を最初に確かめる。

次に読むとよい記事です。CORS の設定は関連記事「CORSエラーの原因と解決方法｜エラーメッセージ別に解説」で、git のリモートの操作は関連記事「git remoteの変更・追加・削除とpush rejectedの対処法」で扱っています。

参考・出典

確認日はいずれも 2026年10月29日です。

• MDN「Origin（オリジン）」：https://developer.mozilla.org/ja/docs/Glossary/Origin
• MDN「同一オリジンポリシー」：https://developer.mozilla.org/ja/docs/Web/Security/Same-origin_policy
• MDN「Origin」（HTTP ヘッダー）：https://developer.mozilla.org/ja/docs/Web/HTTP/Reference/Headers/Origin
• MDN「オリジン間リソース共有 (CORS)」：https://developer.mozilla.org/ja/docs/Web/HTTP/Guides/CORS
• web.dev「same-site と same-origin について」：https://web.dev/articles/same-site-same-origin?hl=ja
• WHATWG「HTML Standard」Origin：https://html.spec.whatwg.org/multipage/origin.html#origin
• IETF「RFC 6454 The Web Origin Concept」：https://www.rfc-editor.org/rfc/rfc6454
• Git「git-clone Documentation」（--origin・clone.defaultRemoteName）：https://git-scm.com/docs/git-clone
• Git「git-remote Documentation」：https://git-scm.com/docs/git-remote

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。