HTTPS接続は時限爆弾 ― AI時代に全部GitHubへ、なぜSSH一択なのか

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

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

ある日、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

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

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

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

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

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

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

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

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

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

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