---
title: HTTPS接続は時限爆弾 ― AI時代に全部GitHubへ、なぜSSH一択なのか
tags:  #github #git #生成ai #セキュリティ  
author: [井本 賢](https://www.docswell.com/user/kenimo49)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/57GL5RW2EL.jpg?width=480
description: AI時代、コード以外もGitHubに置く人が増えています。設定ファイル、ナレッジ、契約書、確定申告のPDF……。しかしHTTPS接続のままだと、ファイルが積もったある日、git pull が突然通らなくなります。  このスライドは、その原因（GnuTLS）と、なぜSSH一択なのかを13枚で図解した入門編です。通信スタックのどこが壊れるのか、なぜ設定オプションでは直らないのか、SSHへの切替手順（5分）までを扱います。  ▼関連書籍『実践Claude Code』Zenn Book（¥1,000） https://zenn.dev/kenimo49/books/claude-code-mastery  ▼Kindle版 https://www.amazon.co.jp/dp/B0GPSVW3BJ  著者: ken imoto / kenimoto.dev
published: June 11, 26
canonical: https://www.docswell.com/s/kenimo49/K6NEEE-github-ssh-ai-era
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/57GL5RW2EL.jpg)

GIT × AI 運用
HTTPS接続は、
時限爆弾です
AI時代に全部GitHubへ ― なぜSSH一択な
のか
ken imoto エンジニア / Propel-lab
claude-code
$ claude --init
CLAUDE.md loaded
Context: 15 patterns
$
実践
Claude Code
コンテキストエンジニアリングで
開発が変わる
19章 / 12.6万字 / CLAUDE.mdパターン集
ken imoto
Git × AI : SSH一択
kenimoto.dev

# Page. 2

![Page Image](https://bcdn.docswell.com/page/4EQYZV39JP.jpg)

コード以外もGitHubに置く時代
「AIに自分の情報を持たせたい」「どのPCからでも触りたい」― 理
由は正しい。GitHubは最適解です。
エージェントの記憶
設定ファイル・ナレッジ・ログ
会社のナレッジベース
議事録・仕様・ドキュメント
契約書・請求書
PDF・画像で積み上がる
確定申告の書類
スキャンPDF・領収書画像
Git × AI : SSH一択
02
kenimoto.dev

# Page. 3

![Page Image](https://bcdn.docswell.com/page/KJ4W3MNR71.jpg)

ある日、git pullが死ぬ
PDF・画像が十分に積もった瞬間 ― まさにAIに読ませたいその時
に、リポジトリに触れなくなります。
$ git pull
error: RPC failed; curl 56 GnuTLS recv error (-54)
error: 6742 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
PDF・画像 約110ファイル / 35MB を pushした後、別PCで clone すらできなくなった
Git × AI : SSH一択
03
kenimoto.dev

# Page. 4

![Page Image](https://bcdn.docswell.com/page/LE1Y185V7G.jpg)

なぜHTTPS接続は壊れるのか
git clone https:// の内部では4段の通信スタックが動く。壊れるの
は、その3段目です。
git-remote-https
HTTPSクライアント
↓
libcurl
HTTP通信ライブラリ
↓
libgnutls
SSL/TLS暗号化 (Ubuntu標準)
◀ここが壊れる
↓
TCP → GitHub
ネットワーク自体は正常
Git × AI : SSH一択
04
kenimoto.dev

# Page. 5

![Page Image](https://bcdn.docswell.com/page/GEWG8Z53J2.jpg)

GnuTLS の3つの弱点
テキストだけなら問題ない。バイナリが入った瞬間にpackファイ
ルが肥大化し、限界に達します。
1
レコードサイズ制限
バッファが溢れるとセッション全
体を切断。OpenSSLは再試行する
が、GnuTLSはしない
2
chunked転送と相性最悪
巨大なpackファイルのチャンク
に、GnuTLSのTLS処理が追いつか
ない
3
再接続ロジックが無い
一度TLSが切れると、libcurlがリ
トライしてもGnuTLS側が復帰でき
ない
PDF・画像が入る → packファイル肥大化 → GnuTLSの限界
Git × AI : SSH一択
05
kenimoto.dev

# Page. 6

![Page Image](https://bcdn.docswell.com/page/47ZL81NGJ3.jpg)

設定をいくら弄っても直らない
よくある対策は、すべてGit層・OS層の話。GnuTLSのTLS処理層に
は届きません。
× http.postBuffer 拡大
postBufferはpush時の送信バッファ。受信側の
GnuTLS問題には無関係
× lowSpeedLimit 緩和
タイムアウトではなくTLSの異常切断。待ち時間の問
題ではない
× --depth 1 (浅いクローン)
最新コミットのpackファイル自体が大きく、転送量は
ほぼ変わらない
× Swap追加
メモリ不足ではなく通信層の問題。増やしても安定し
ない
問題のレイヤーが、そもそも違う
Git × AI : SSH一択
06
kenimoto.dev

# Page. 7

![Page Image](https://bcdn.docswell.com/page/YJ6WPL8QJV.jpg)

SSHは、まったく別の経路
壊れるレイヤー (GnuTLS) を、そもそも通りません。
HTTPS
git-remote-https
↓
libcurl
↓
libgnutls ← 切断
↓
TCP
SSH
git-remote-ssh
↓
OpenSSH (暗号化+通信)
↓
GnuTLS不使用
↓
TCP
Git × AI : SSH一択
07
kenimoto.dev

# Page. 8

![Page Image](https://bcdn.docswell.com/page/GJ5MK192J4.jpg)

SSHが安定する4つの理由
OpenSSHは25年以上、大容量転送で枯れている。安定性の次元が
違います。
成熟度
25年以上の歴史。大容量転送のバグは出尽くしている
ストリーム転送
リクエスト/レスポンスでなく持続接続。チャンク分割
のオーバーヘッドなし
再接続不要
1セッションでpackを丸ごと転送。TLSハンドシェイ
クを繰り返さない
環境差なし
Linux/macOS/WSL すべてに標準搭載。GnuTLS vs
OpenSSLの差が出ない
Git × AI : SSH一択
08
kenimoto.dev

# Page. 9

![Page Image](https://bcdn.docswell.com/page/LE3WZ1Y1E5.jpg)

切り替えは3コマンド・5分
鍵を作る → GitHubに登録 → リモートURLを差し替える。それだ
けです。
1
鍵を生成
ssh-keygen -t ed25519 -C "you@example.com"
2
公開鍵を登録
# cat ~/.ssh/id_ed25519.pub → GitHub Settings > SSH keys
3
URLを差し替え
git remote set-url origin git@github.com:user/repo.git
Git × AI : SSH一択
09
kenimoto.dev

# Page. 10

![Page Image](https://bcdn.docswell.com/page/8EDKRX5K7G.jpg)

HTTPS vs SSH
初回設定が5分長いだけ。その後のすべてが楽になります。
HTTPS
SSH
大容量ファイル
× GnuTLSが落ちる
√ 安定
認証
トークン/パスワード
鍵認証(秘密鍵はPC内に留まる)
セキュリティ
トークン漏洩リスク
.env にトークンを書かない
長期運用
トークン期限切れの管理
一度設定すれば半永久
Git × AI : SSH一択
10
kenimoto.dev

# Page. 11

![Page Image](https://bcdn.docswell.com/page/V7PKWPG3J8.jpg)

AI時代に、特に効く
エージェントはコンテキストとして大量のファイルを扱う。増える
ほどHTTPSは不安定になります。
トークン管理が不要
エージェントの設定ファイルにト
ークンを書かなくていい
漏洩リスクゼロ
.env にGitHubトークンを置く必
要そのものが消える
落ちない
大量ファイルをpull/pushしても
セッションが切れない
エージェントに任せるなら、SSHが前提になる
Git × AI : SSH一択
11
kenimoto.dev

# Page. 12

![Page Image](https://bcdn.docswell.com/page/2JVV826NJQ.jpg)

何も考えずにSSH
AI時代はファイルが増える一方。最初からSSHで始めてください。
GitHubにPDF・画像を入れるなら、
HTTPSは時限爆弾。設定では直らない。
バイナリが入るとgit
pullが死ぬ
postBuffer等の設定で
は直らない
SSHは別経路。根本解
決・5分
最初からSSHで始める
Git × AI : SSH一択
12
kenimoto.dev

# Page. 13

![Page Image](https://bcdn.docswell.com/page/5EGL5RN5JL.jpg)

SSHは、その第一歩。
AI時代の開発の全体像へ。
Zenn Book ¥1,000
zenn.dev/kenimo49/books/claude-code-mastery
Kindle
amazon.co.jp/dp/B0GPSVW3BJ
『実践Claude Code』― AIにコードを書かせ、コンテキストエンジニ
アリングで開発を変える。全部gitで管理する運用の全体像を体系化。
kenimoto.dev
claude-code
$ claude --init
CLAUDE.md loaded
Context: 15 patterns
$
実践
Claude Code
コンテキストエンジニアリングで
開発が変わる
19章 / 12.6万字 / CLAUDE.mdパターン集
ken imoto
Git × AI : SSH一択
13
kenimoto.dev