開発環境 on ポンコツ地方エンジニアの技術ブログ

VS Code での Git Worktree の使い方

Mon, 13 Jul 2026 00:00:00 +0900

環境

Ubuntu 22.04
Visual Studio Code 1.128.0

事前準備

VS Code の設定で、git.detectWorktrees を ON にします。

ワークツリーの作成だけなら OFF の状態でもできましたが、ワークツリーを切り替えたり削除したりするには ON にする必要がありました。

ワークツリーの作成

ソース管理タブのリポジトリ横のメニューから作成できます。

ブランチの作成と、フォルダの場所を入力します。
デフォルトでは以下のようなフォルダ構成になります。

リポジトリ名
リポジトリ名.worktrees
 └── ブランチ名

ワークツリーが作成されたのが確認できます。

ワークツリーを作業ツリーで開く

作成したワークツリー横のメニューから「現在のウィンドウで作業ツリーを開く」または「新しいウィンドウで作業ツリーを開く」を選択します。

あとはいつも通り変更してコミットなどを行います。

ワークツリーの削除

ソース管理タブのリポジトリにて、ワークツリー横のメニューから作成できます。
（右クリックからでもいけます）

該当のワークツリーを作業ツリーで開いている場合は削除できませんので、その場合はメインリポジトリに切り替えてから削除する必要があります。

Ubuntu で Orca を使う

Sun, 12 Jul 2026 00:00:00 +0900

環境

Ubuntu 24.04

ダウンロード

以下から Linux 用の AppImage をダウンロードします。

https://www.onorca.dev/

実行手順

実行権限を与えて実行するだけです。

chmod +x orca-linux.AppImage
./orca-linux.AppImage

エラーがでた場合

私の環境では以下のエラーが出ました。

libfuse2 がない

エラー内容は以下です。

dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information

libfuse2 が必要みたいなので、以下で追加しました。

sudo add-apt-repository universe
sudo apt update
sudo apt install libfuse2

chrome-sandbox の権限エラー

[40727:0718/110452.982911:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_orca-lhdNQH6/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (コアダンプ)

--no-sandbox をつければとりあえず起動できます。

./orca-linux.AppImage --no-sandbox

原因

Electron製のOrcaは、内部のChromiumプロセスを隔離するため、Linuxでは主に次のいずれかのsandbox方式を使います。

user namespace sandbox 一般ユーザー権限のままLinux namespaceを作成する方式
SUID sandbox chrome-sandbox をroot所有・権限4755で実行する方式

Ubuntu 22.04では1のuser namespace方式がそのまま利用できたため、AppImage内のchrome-sandboxがSUID設定されていなくても起動できました。

Ubuntu 24.04ではAppArmorによる以下の制限が既定で有効になっています。

kernel.apparmor_restrict_unprivileged_userns=1

これによりOrcaがuser namespace sandboxを作れずエラーになります。

制限をUbuntu 22.04相当に戻す方法もありますが、システム上の全アプリケーションに対して非特権user namespaceの制限を解除することになります。

とりあえずは Orca 側の対応待ちという感じです。

以上で無事起動しました。
使い方などは気が向いたらまた別途。

Codex のレート制限リセット権の有効期限の確認方法

Thu, 09 Jul 2026 00:00:00 +0900

Codex で付与されたレート制限リセット権は有効期限が30日間となっていますが、現状、有効期限がいつまでかを簡単に確認する術がないようです。
以下に Windows 環境で確認するためのスクリプトが記載されていたので、これを参考に Ubuntu 用のスクリプトを作成しました。

https://note.com/moz_ai_tech/n/n84feff773b79

スクリプトの作成

ファイル名は何でもよいですが、例えば check_codex_reset_credits.sh として、以下の内容を保存してください。

#!/usr/bin/env bash
set -euo pipefail

AUTH_FILE="${HOME}/.codex/auth.json"
API_URL="https://chatgpt.com/backend-api/wham/rate-limit-reset-credits"

if ! command -v jq >/dev/null 2>&1; then
 echo "ERROR: jq が見つかりません。先にインストールしてください。"
 echo " sudo apt update && sudo apt install -y jq"
 exit 1
fi

if ! command -v curl >/dev/null 2>&1; then
 echo "ERROR: curl が見つかりません。先にインストールしてください。"
 echo " sudo apt update && sudo apt install -y curl"
 exit 1
fi

if [ ! -f "$AUTH_FILE" ]; then
 echo "ERROR: 認証ファイルが見つかりません: $AUTH_FILE"
 echo "Codex にログイン済みか確認してください。"
 exit 1
fi

ACCESS_TOKEN="$(jq -r '.tokens.access_token // empty' "$AUTH_FILE")"
ACCOUNT_ID="$(jq -r '.tokens.account_id // empty' "$AUTH_FILE")"

if [ -z "$ACCESS_TOKEN" ]; then
 echo "ERROR: access_token が取得できませんでした。"
 echo "$AUTH_FILE の形式が想定と異なるか、Codex の認証状態が無効です。"
 exit 1
fi

TMP_RESPONSE="$(mktemp)"
trap 'rm -f "$TMP_RESPONSE"' EXIT

if [ -n "$ACCOUNT_ID" ]; then
 HTTP_CODE="$(
 curl -sS \
 -o "$TMP_RESPONSE" \
 -w "%{http_code}" \
 -H "Authorization: Bearer ${ACCESS_TOKEN}" \
 -H "OpenAI-Beta: codex-1" \
 -H "originator: Codex Desktop" \
 -H "ChatGPT-Account-ID: ${ACCOUNT_ID}" \
 --max-time 30 \
 "$API_URL"
 )"
else
 HTTP_CODE="$(
 curl -sS \
 -o "$TMP_RESPONSE" \
 -w "%{http_code}" \
 -H "Authorization: Bearer ${ACCESS_TOKEN}" \
 -H "OpenAI-Beta: codex-1" \
 -H "originator: Codex Desktop" \
 --max-time 30 \
 "$API_URL"
 )"
fi

if [ "$HTTP_CODE" != "200" ]; then
 echo "ERROR: API 呼び出しに失敗しました。HTTP status: $HTTP_CODE"
 echo "レスポンス:"
 cat "$TMP_RESPONSE"
 echo
 exit 1
fi

jq -r '
 def fmt_time:
 if . == null or . == "" then
 "不明"
 else
 # jq の fromdateiso8601 は小数秒つき ISO8601 で失敗することがあるため除去する
 sub("\\.[0-9]+Z$"; "Z")
 | fromdateiso8601
 | localtime
 | strftime("%Y-%m-%d %H:%M:%S %Z")
 end;

 "利用可能なリセット権: \(.available_count // 0) 個",
 "",
 "状態\t付与日時\t有効期限",
 (
 (.credits // [])
 | map([
 (.status // "不明"),
 (.granted_at | fmt_time),
 (.expires_at | fmt_time)
 ])
 | .[]
 | @tsv
 )
' "$TMP_RESPONSE" | column -t -s $'\t'

実行手順

sudo apt update
sudo apt install -y curl jq

chmod +x check_codex_reset_credits.sh
./check_codex_reset_credits.sh

注意

このスクリプトは、参照記事の PowerShell 版と同じく、~/.codex/auth.json から access_token と account_id を読み取り、https://chatgpt.com/backend-api/wham/rate-limit-reset-credits に GET します。

注意点として、この方法は公式に公開された安定 API ではなく、参照記事でも「内部APIを使った非公式な確認方法」と説明されています。
Codex 側の仕様変更で動かなくなる可能性があります。

OCI や AWS EC2 でセッション切断後も処理を止めないよう tmux を使う

Sat, 30 May 2026 00:00:00 +0900

OCI や AWS EC2 で作業していると、SSH セッションを閉じたタイミングで実行中のプログラムが止まってしまうことがあります。

この問題は、tmux の「セッションを切り離す（detach）」を使うだけでほぼ解決できます。
私は今回初めて tmux を使ったため、必要な操作に限定してメモしておきます。

先にまとめ

「SSH を閉じても処理を動かし続ける」目的なら、tmux は以下だけで運用できます。

SSH ログイン後に tmux セッションを作る
tmux 内でプログラムを起動する
Ctrl+b → d で切り離す
SSH を切断しても処理は継続する
再ログイン後に tmux へ再接続する

コマンドだけ見ると以下です。

# セッション作成
tmux new -s app

# （tmux 内で）プログラム実行
python main.py

# 切り離し: Ctrl+b, d

# いまあるセッション確認
tmux ls

# 再接続
tmux attach -t app

tmux のインストール

Ubuntu 系なら以下で入ります。

sudo apt update
sudo apt install -y tmux

確認（バージョン表示）

tmux -V

まずは 1 回動かしてみる

1. セッションを作る

tmux new -s app

app はセッション名です。
あとで再接続するときに使うので、用途が分かる名前を付けると楽です。

📝 注記

tmux だけ打った場合、もし tmux サーバーがまだ動いていなければ、新しいセッションを作って接続します（デフォルト名で作成）。
すでに tmux が動いていて接続済みでない場合は、最近使われたセッションにアタッチします（新しいセッションは作成されません）。上記のコマンドは明示的に新規の名前付きセッションを作るコマンドになります。

2. プログラムを起動する

tmux の画面の中で、普段どおりコマンドを実行します。

python main.py

たとえば API サーバーなら、以下のように常駐するコマンドでも同じです。

uvicorn app:app --host 0.0.0.0 --port 8000

3. セッションを切り離す（detach）

以下の順でキーを押します。

Ctrl+b
d

これで tmux の外に戻ります。
プログラムは tmux セッション内でそのまま動き続けますので、SSH 自体を切断して問題ありません。
再ログイン後に tmux へ戻れます。

4. 再接続する（attach）

tmux ls でセッション一覧を見て、名前を確認します。

tmux ls

以下のコマンドで再接続します。

tmux attach -t app

セッションを終了して抜ける（プロセスを停止してセッションを閉じる）

tmux をデタッチせずにそのままセッションを終了して抜けたい場合は、主に次の方法があります。

セッション内から終了する（推奨 — プロセスを安全に停止）

tmux attach -t <セッション名> でセッションに戻る
実行中のプロセスを Ctrl+C などで停止する
シェルで exit または Ctrl+D を押すとウィンドウが閉じ、最後のウィンドウが閉じるとセッションは終了します

外からセッションを強制的に終了する（注意: プロセスが強制終了される）

tmux kill-session -t <セッション名>
全てのセッションを終了する場合は tmux kill-server

注意: セッションを閉じると、そのセッション内で動いていたプロセスは終了します。処理を継続させたい場合はデタッチしてください。

今回の用途で最低限覚えるコマンド

用途	コマンド
新規セッション作成	`tmux new -s app`
セッション一覧	`tmux ls`
セッション再接続	`tmux attach -t app`
セッション削除（停止）	`tmux kill-session -t app`

💡 ヒント

セッション内で動いているプロセスを止めたいときは、まず tmux に再接続して Ctrl+c で停止するのが安全です。

キー操作の最小セット

tmux は Ctrl+b を押したあとに次のキーを押す操作が基本です（prefix キー）。

コマンド	内容
`Ctrl+b` → `d`	セッション切り離し
`Ctrl+b` → `c`	新しいウィンドウ作成
`Ctrl+b` → `n`	次のウィンドウへ移動
`Ctrl+b` → `p`	前のウィンドウへ移動
`Ctrl+b` → `,`	ウィンドウ名を変更

最初は Ctrl+b → d だけ覚えれば十分です。

よくあるハマりどころ

SSH を切ったら止まった

tmux の中で起動せず、通常シェルで起動している可能性があります。
tmux attach -t app で戻って、そこで起動し直してください。

`tmux attach` で「no sessions」になる

セッションが存在しない状態です。新しく作成します。

tmux new -s app

セッション名を忘れる

tmux ls

一覧を出して、その名前で attach すれば戻れます。

Claude Code の認証情報とチャット履歴を devcontainer とホストで共有する

Wed, 13 May 2026 00:00:00 +0900

環境

Ubuntu 24.04
VSCode 1.119.0

きっかけ

devcontainer をリビルドするたびに Claude Code に再ログインするのが地味にストレスでした。さらに、ホスト側で進めていた会話の続きが devcontainer 側からは見えず、「あの修正の文脈どこに残してたっけ」となりがちでした。

ゴール構成

ホスト・devcontainer のどちらで起動しても 同じ認証情報 を使える
ホストで途中まで進めた会話を devcontainer 側でも そのまま継続 できる
リビルドしても再ログイン不要

Claude Code が何を見ているかを把握する

設定の前に、Claude Code が以下の 2 つを参照していることを押さえておきます。

種類	場所	役割
認証情報・設定	`~/.claude.json`	API キーなど
セッション履歴	`~/.claude/projects/<エンコードしたパス>/`	プロジェクトごとの会話履歴

ポイントは、セッション履歴の格納先が プロジェクトの絶対パスをスラッシュ → ハイフンに変換した名前 になっていることです。

例えばホスト側で /home/<username>/<project_name> を開いていた場合は、

~/.claude/projects/-home-<username>-<project_name>/

の下に履歴が溜まります。

つまり、履歴を共有したいなら ホストとコンテナで「ワークスペースの絶対パス」を一致させる必要がある ということです。~/.claude だけ bind mount しても、コンテナ側のワークスペースパスがホストと違えば別フォルダ扱いになり、履歴は共有されません。

設定する 2 つのマウント

必要なマウントは性質の違う 2 種類になります。

1. `.claude` / `.claude.json` のマウント (= コンテナ側ユーザーの home に合わせる)

Claude Code は そのプロセスの $HOME/.claude を読みに行きます。devcontainer のデフォルトユーザーは vscode なので、~ は /home/vscode です。したがってターゲットも /home/vscode/.claude にします。

2. ワークスペースのマウント (= ホスト側の絶対パスに合わせる)

こちらはセッション履歴のキーになる「プロジェクトの絶対パス」を一致させるのが目的なので、ターゲットを ホスト側と同じパス にします。ホストの ~/<project_name> を開いているなら、コンテナ内でも /home/<username>/<project_name> にマウントするということです。

ターゲットの基準が違う (ユーザー基準 vs ホスト基準) のがややこしい部分なので、表にしておきます。

マウント	ターゲット	基準
`~/.claude` `~/.claude.json`	`/home/vscode/.claude` `/home/vscode/.claude.json`	コンテナ内ユーザーの home
ワークスペース	`/home/<username>/<project_name>` 等	ホスト側の絶対パス

devcontainer.json の例

上記を踏まえた .devcontainer/devcontainer.json の抜粋です。

{
 "name": "my-devcontainer",
 "build": {
 "dockerfile": "Dockerfile",
 "args": {
 // ホストの $HOME を build arg として Dockerfile に渡す
 // (workspace の親ディレクトリを事前に作るために使う。後述)
 "WORKSPACE_PARENT": "${localEnv:HOME}"
 }
 },

 // ワークスペースのマウント先をホスト側の絶対パスと一致させる。
 // フォルダ名は localWorkspaceFolderBasename で動的解決するので、
 // ホスト側を rename しても devcontainer.json の編集は不要。
 "workspaceMount": "source=${localWorkspaceFolder},target=${localEnv:HOME}/${localWorkspaceFolderBasename},type=bind,consistency=cached",
 "workspaceFolder": "${localEnv:HOME}/${localWorkspaceFolderBasename}",

 "mounts": [
 // .claude / .claude.json はコンテナ内ユーザー (vscode) の home にマウント
 "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind,consistency=cached"
 ],

 "remoteUser": "vscode"
}

${localEnv:HOME} は ホスト側 の $HOME (例: /home/<username>)、${localWorkspaceFolderBasename} は VSCode が開いているフォルダ名 (例: <project_name>) に展開されます。両者を組み合わせることで、ホストで開いているパスと完全に同じ絶対パスをコンテナ内に作れます。

Dockerfile 側で親ディレクトリを用意しておく

workspaceFolder に指定したパスの 親ディレクトリ がコンテナ内に存在しないと、Dev Containers の起動チェックで「ワークスペースが存在しません」とエラーになります。bind mount はマウント時にターゲットを作ってくれますが、Dev Containers のチェックがそれより先に走るためです。

そこで Dockerfile 側で親ディレクトリだけ先に作っておきます。

FROM mcr.microsoft.com/devcontainers/base:bookworm

# devcontainer.json の workspaceFolder (= ホストの $HOME/<フォルダ名>) と
# 同じ絶対パスをコンテナ内に用意しておく。
ARG WORKSPACE_PARENT=/home/vscode
RUN mkdir -p "${WORKSPACE_PARENT}"

ARG のデフォルト値を /home/vscode にしておけば、build arg を渡し忘れても既存ユーザーのホームが使われるだけで build が壊れることはありません。

ユーザーは vscode のままでよい

「ワークスペースが /home/<username>/<project_name> なのに whoami すると vscode になっている」というアンバランスさが気になるかもしれませんが、機能上は問題ありません。

devcontainers/base の vscode ユーザーは UID 1000
ホスト側の Linux ユーザーも通常 UID 1000

UID が一致していれば bind mount したファイルにそのまま読み書きできるためです。vscode ユーザーが自分の home (/home/vscode/) 以外の場所で作業すること自体は何も問題を起こしません。

ユーザー名まで揃えようとすると base image の改造が必要になり、devcontainer features が前提にしている vscode ユーザーが消えて壊れがちです。ホストと揃えるのは「絶対パス」だけで十分 と割り切るのが楽です。

注意点

ホスト側に ~/.claude と ~/.claude.json が存在している必要があります。なければ bind mount に失敗します。ホスト側でも一度 Claude Code を起動して認証を済ませておくのが手っ取り早いです。
セッション履歴を ホストと同時に書き込まない よう注意してください。両方から同じプロジェクトを同時に触ると、ファイルロック等の衝突で履歴が壊れることがあります。基本「どちらか一方で作業する」運用が安全です。
設定変更後は VSCode の Dev Containers: Rebuild Container でリビルドしないと反映されません。

まとめ

Claude Code のセッション履歴は プロジェクトの絶対パスをキー にして格納される。
なので「ホストとセッション共有したい」ならコンテナ内のワークスペースパスをホスト側と完全一致させる必要がある。
マウント先は 2 系統で基準が違う:
- .claude / .claude.json は コンテナ内ユーザーの home に合わせる
- ワークスペースは ホスト側の絶対パス に合わせる
ワークスペースの親ディレクトリは Dockerfile 側で mkdir -p しておく必要がある。
フォルダ名は ${localWorkspaceFolderBasename} で動的解決すれば、rename にも追従する。

GitHub CLI (gh auth login) で Git の HTTPS 認証を安全にする

Mon, 11 May 2026 00:00:00 +0900

環境

Ubuntu 24.04

きっかけ

git remote -v を眺めていたら、Personal Access Token (PAT) が remote URL に丸ごと埋め込まれている状態になっていました。

origin https://ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx@github.com/USER/REPO.git (fetch)
origin https://ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx@github.com/USER/REPO.git (push)

.git/config はリポジトリに含まれないため「push しても外には出ない」ものの、ローカルで露出する経路は意外と多くあります。

シェル履歴 (~/.bash_history ~/.zsh_history)
エディタや CI のログ、画面共有・スクリーンショット
うっかり配布した dotfiles リポジトリ
マルウェアやリモートアクセスで .git/config が読まれる

しかも classic PAT はスコープが粗く、repo 権限があれば private リポジトリ全体の閲覧・書き換え、強制 push による履歴破壊、GitHub Actions secrets の窃取まで可能になります。攻撃者は奪った瞬間には何もせず静かに watch することもできるため、「使われた形跡がない」では安心できません。

これを機に、PAT を URL に埋めず GitHub CLI (gh) の credential helper に任せる構成に切り替えました。

ゴール構成

remote URL は素の https://github.com/USER/REPO.git
認証は gh が credential helper として処理 (トークンは OS のセキュアストア管理)
devcontainer を作り直しても再ログイン不要

手順

1. 露出したトークンを revoke (最優先)

remote URL を書き換える前に、まず GitHub 側でトークンを無効化します。

classic PAT: https://github.com/settings/tokens
fine-grained PAT: https://github.com/settings/personal-access-tokens

該当トークンを Delete した瞬間に無効になります。順序として これを先にやる ことが大切です。後の手順を待っている間に古いトークンが他経路で使われるリスクを断ちます。

2. `gh` をインストール

devcontainer 環境なら ghcr.io/devcontainers/features/github-cli feature で gh がすでに入っています。

ホスト (Ubuntu 24.04) に入れる場合は、以下の記事を参考にしてください。

GitHub CLI (gh) のインストールと基本的な使い方

3. `gh auth login` で認証

gh auth login

対話で以下のように選びます。

? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

Authenticate Git with your GitHub credentials? → Yes が肝で、これが git config --global credential.helper を gh 経由に書き換えてくれます。以後 git push のたびに gh が裏でトークンを取り出して認証してくれます。

devcontainer のようなヘッドレス環境ではブラウザは自動で開きません。表示される 8 桁のワンタイムコードをコピーし、ホスト側のブラウザで https://github.com/login/device に貼って承認します。

✓ Authentication complete.
✓ Logged in as USER

4. remote URL からトークンを除去

git remote set-url origin https://github.com/USER/REPO.git
git remote -v

トークン部分が消えていれば OK です。git fetch origin がパスワードを聞かれずに通れば認証は機能しています。

5. シェル履歴の残骸を確認

revoke 済みでも、ローカル履歴に残ったトークン文字列は気持ちが悪いものです。

grep -rn 'ghp_' ~/.bash_history ~/.zsh_history 2>/dev/null

ヒットしたら該当行を削除します (history -d <行番号> でメモリ上を消した後、ファイルも編集しておきます)。

devcontainer での認証共有

gh の認証情報は ~/.config/gh/hosts.yml (と OS のセキュアストア) に保存されます。devcontainer をリビルドすると ~/.config/gh が消えて再ログインが必要になるため、ホストの設定を bind mount で共有します。

.devcontainer/devcontainer.json:

"mounts": [
 "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.config/gh,target=/home/vscode/.config/gh,type=bind,consistency=cached"
]

前提として ホスト側に ~/.config/gh ディレクトリが存在している必要があります (なければ bind mount に失敗します)。ホストにも gh を入れて gh auth login 済みにしておくのが一番シンプルです。事情があってホスト側で gh を使わない場合でも、空ディレクトリだけ作っておけばマウント自体は通ります。

mkdir -p ~/.config/gh # ホスト側で実行

設定変更後は VSCode の Dev Containers: Rebuild Container でリビルドすると反映されます。

補足: SSH 鍵にしないのか

SSH 鍵認証もアリですが、

鍵ファイル自体の管理 (~/.ssh のパーミッション、複数マシン間の同期) が発生します
GitHub Actions など他用途で gh をどのみち使うことが多いです

そのため、個人開発の HTTPS なら gh auth login ひとつに寄せた方がメンテが楽だと感じています。複数アカウントの切替も gh auth switch で済むのが良いところです。

まとめ

PAT を URL に埋めるのは「公開リポジトリに含まれない」だけでローカル経路の露出リスクは大きいです。露出に気付いた時点で revoke が最優先となります。
gh auth login で credential helper を任せれば URL からトークンを排除でき、トークンは OS のセキュアストアに隔離されます。
devcontainer ではホストの ~/.config/gh を bind mount しておくと、リビルドのたびに再ログインしなくて済みます。

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

Sun, 10 May 2026 00:00:00 +0900

ブラウザを開かずに Issue を確認したり、MR（マージリクエスト）を作成したり、CI/CD パイプラインの状況を監視したりできるため、エンジニアの生産性を大きく向上させてくれます。

1. インストール方法

devcontainer を使っていない場合は、ホスト側に glab をインストールして使います。devcontainer を使う場合は、コンテナイメージに glab をインストールしておくか、devcontainer の Dockerfile / devcontainer.json で導入しておきます。

一般的な手順としては、Dockerfile に curl で glab の公式パッケージを取得して apt install するか、apt リポジトリからインストールする形です。コンテナ内で glab --version を実行して、インストールが正しくできていることを確認してください。

OS ごとの主要なインストールコマンドは以下の通りです。

OS	インストールコマンド
macOS	`brew install glab`
Windows (winget)	`winget install glab`
Windows (scoop)	`scoop install glab`
Linux (Ubuntu/Debian)	`sudo apt install glab`（※公式リポジトリ推奨）

インストール後、glab --version で正常にインストールされたか確認しましょう。

バージョンが古かったり、上記でインストールできない場合は、公式リリースからダウンロードしてインストールします。

https://gitlab.com/gitlab-org/cli/-/releases

例えば以下です。

cd /tmp
wget https://gitlab.com/gitlab-org/cli/-/releases/v1.97.0/downloads/glab_1.97.0_linux_amd64.deb
sudo dpkg -i glab_1.97.0_linux_amd64.deb

2. 初期設定（認証）

インストールが完了したら、GitLab アカウントと連携させます。

glab auth login

実行すると対話形式で以下の項目を聞かれます：

GitLab インスタンスの種類: GitLab.com か自前運用のサーバー（Self-Managed）かを選択。
認証方法: Web を選択するとブラウザが開いて簡単に認証できます。
プロトコル: SSH または HTTPS を選択。

設定が完了すると、~/.config/glab-cli/config.yml に設定が保存されます。

3. devcontainer での認証情報共有

glab の認証情報は ~/.config/glab-cli/config.yml に保存されます。devcontainer をリビルドするとコンテナ内の ~/.config/glab-cli が消えて再ログインが必要になるため、ホスト側の設定を bind mount で共有しておくと便利です。

一般的には、.devcontainer/devcontainer.json の mounts にホストの ~/.config/glab-cli を追加します。例:

"mounts": [
 "source=${localEnv:HOME}/.config/glab-cli,target=/home/vscode/.config/glab-cli,type=bind,consistency=cached"
]

もし gh など別の CLI も devcontainer 内で使うなら、同じように ~/.config/gh を共有することもできます。

ホスト側に ~/.config/glab-cli が存在していれば、ホストで一度 glab auth login しておけばコンテナ側でも同じ認証を使えます。ホストにディレクトリがない場合は、mkdir -p ~/.config/glab-cli で空ディレクトリを作成しておけばマウントが通ります。

このようにしておけば、glab の認証設定をホストと devcontainer で共通化し、コンテナ再構築後も再ログイン不要で作業を続けやすくなります。

4. よく使う基本コマンド集

glab のコマンド体系は glab <リソース名> <アクション> という形式で、gh と非常に似ています。

■ Merge Request (MR) を操作する

開発のメイン作業となる MR 操作です。

MR の一覧表示: glab mr list
MR の作成: glab mr create --fill（現在のブランチから自動入力で作成）
MR の詳細表示: glab mr view <id>
MR を承認: glab mr approve <id>
MR をマージ: glab mr merge <id>

■ Issue (課題) を管理する

Issue 一覧: glab issue list
Issue 作成: glab issue create -t "タイトル" -description "内容"

■ CI/CD パイプラインを確認する

glab 独自の強力な機能の一つが、CI パイプラインのリアルタイム監視です。

パイプラインの状態表示: glab pipeline status
実行中のログをリアルタイム表示: glab pipeline ci view
失敗したジョブの再実行: glab ci retry

4. `gh` と `glab` の主な対応表

GitHub CLI に慣れている方向けのクイック比較です。

機能	GitHub (`gh`)	GitLab (`glab`)
認証	`gh auth login`	`glab auth login`
PR / MR 作成	`gh pr create`	`glab mr create`
PR / MR チェックアウト	`gh pr checkout <id>`	`glab mr checkout <id>`
リポジトリ作成	`gh repo create`	`glab project create`
CI 監視	`gh run watch`	`glab pipeline ci view`

5. 自社運用の GitLab (Self-Managed) で使うコツ

glab は GitLab.com だけでなく、会社などで独自に立てている GitLab サーバーでも使えます。その場合、環境変数でホストを指定しておくと便利です。

export GITLAB_HOST=gitlab.example.com

まとめ

glab を導入することで、「コードを書く → プッシュする → ブラウザで MR を作る → CI の完了を待つ」という一連の流れをターミナルから一歩も出ずに行えるようになります。

まずは glab mr list から始めて、快適な GitLab ライフを送りましょう！

参考リンク:

GitHub CLI (gh) のインストールと基本的な使い方

Sat, 09 May 2026 00:00:00 +0900

GitHub CLI (gh) は、GitHub が公式に提供しているコマンドラインツールです。

ブラウザを開かなくても、リポジトリの clone、Issue の確認、Pull Request の作成、GitHub Actions の実行状況確認などをターミナルから操作できます。Git と組み合わせて使うと、日常の GitHub 作業をかなり短い導線にできます。

この記事では、Windows と Ubuntu で gh をインストールし、最初に覚えておくと便利な基本コマンドをまとめます。

gh でできること

gh を使うと、たとえば以下のような作業をターミナルから実行できます。

GitHub へのログイン
リポジトリの clone / 作成 / 表示
Issue の一覧表示 / 作成 / 表示
Pull Request の一覧表示 / 作成 / checkout / merge
GitHub Actions の workflow / run の確認
ブラウザで現在のリポジトリや PR を開く

GitHub の画面を見に行く回数を減らせるので、コードを書いている流れを止めにくいのが大きなメリットです。

インストール

Windows にインストールする

Windows では、公式手順として WinGet を使う方法が一番簡単です。

PowerShell または Windows Terminal を開いて、以下を実行します。

winget install --id GitHub.cli

インストール後、ターミナルを開き直して確認します。

gh --version

バージョン情報が表示されればインストール完了です。

アップデートする場合は以下です。

winget upgrade --id GitHub.cli

もし WinGet を使わない場合は、GitHub CLI の Releases ページから MSI インストーラーをダウンロードして導入することもできます。

Ubuntu にインストールする

Ubuntu では、標準の apt リポジトリからそのままインストールできます。

まずパッケージ情報を更新してから、gh をインストールします。

sudo apt update
sudo apt install gh

確認します。

gh --version

アップデートする場合は、通常の apt パッケージと同じです。

sudo apt update
sudo apt install gh

もし apt で見つからない場合や、GitHub CLI の最新版を追いたい場合は、GitHub CLI 公式リポジトリを追加する方法もあります。

type -p wget >/dev/null || (sudo apt update && sudo apt install wget -y)
sudo mkdir -p -m 755 /etc/apt/keyrings
wget -nv -O /tmp/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg
sudo cp /tmp/githubcli-archive-keyring.gpg /etc/apt/keyrings/githubcli-archive-keyring.gpg
sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
sudo mkdir -p -m 755 /etc/apt/sources.list.d
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install gh

通常利用なら、まずは sudo apt install gh で十分です。

初期設定: GitHub にログインする

インストールできたら、GitHub アカウントでログインします。

gh auth login

対話形式でいくつか質問されます。個人利用で GitHub.com を使うなら、だいたい以下の選択で問題ありません。

? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

ポイントは、Authenticate Git with your GitHub credentials? で Yes を選ぶことです。これにより、gh だけでなく通常の git push や git fetch の HTTPS 認証も gh に任せられます。

ブラウザが開いたら GitHub にログインして認証します。WSL やサーバー上などブラウザを開きにくい環境では、表示されたワンタイムコードを手元のブラウザで入力して認証します。

ログイン状態は以下で確認できます。

gh auth status

普通の git コマンドでも gh の認証情報は使われる？

使われます。ただし、gh auth login の途中で以下を選んでいることが前提です。

? Authenticate Git with your GitHub credentials? Yes

この設定を有効にすると、gh が Git の credential helper として設定されます。そのため、以下のような普通の Git コマンドでも、gh でログインした認証情報が利用されます。

git fetch origin
git pull
git push origin main

確認するには、Git の credential helper 設定を見ます。

git config --global --get credential.helper

環境によって表示は少し違いますが、gh auth git-credential を使う設定になっていれば OK です。

注意点として、この仕組みが使われるのは基本的に HTTPS の remote URL です。

git remote -v

remote URL が以下のようになっていれば、HTTPS 経由です。

origin https://github.com/OWNER/REPO.git (fetch)
origin https://github.com/OWNER/REPO.git (push)

一方で、git@github.com:OWNER/REPO.git のような SSH の remote URL を使っている場合は、Git の認証は SSH key 側で行われます。この場合でも gh コマンド自体の GitHub API 操作には、gh auth login の認証情報が使われます。

よく使う基本コマンド

ここからは、最初に覚えておくと便利なコマンドです。

リポジトリ操作

リポジトリを clone します。

gh repo clone OWNER/REPO

たとえば GitHub CLI 本体のリポジトリなら以下です。

gh repo clone cli/cli

現在のリポジトリをブラウザで開きます。

gh repo view --web

新しいリポジトリを作成します。

gh repo create

対話形式で公開範囲やローカルディレクトリの扱いを選べます。スクリプト化したい場合は、--public や --private などのオプションを付けて実行できます。

gh repo create my-app --private --source=. --remote=origin

Issue 操作

Issue の一覧を表示します。

gh issue list

Issue の詳細を表示します。

gh issue view 123

Issue を作成します。

gh issue create --title "ログイン画面の文言を修正する" --body "ボタンの表記を変更する"

ブラウザで Issue を開きたい場合は --web を付けます。

gh issue view 123 --web

Pull Request 操作

Pull Request の一覧を表示します。

gh pr list

現在のブランチから Pull Request を作成します。

gh pr create

コミットメッセージやブランチ情報からタイトル・本文を自動入力したい場合は --fill が便利です。

gh pr create --fill

Pull Request の詳細を表示します。

gh pr view 123

Pull Request のブランチをローカルに checkout します。

gh pr checkout 123

レビューや CI の状態を確認します。

gh pr checks 123

マージします。

gh pr merge 123

GitHub Actions 操作

workflow の一覧を表示します。

gh workflow list

実行履歴を表示します。

gh run list

最新の workflow run を確認します。

gh run view

実行中の workflow を待ちます。

gh run watch

失敗したジョブのログを確認する場合は、まず gh run list で run ID を確認してから以下を実行します。

gh run view RUN_ID --log-failed

便利な使い方

現在のページをブラウザで開く

現在のリポジトリを GitHub 上で開きます。

gh browse

Issue や PR の URL を組み立てる必要がないので、地味に便利です。

自分に関係する状況をまとめて見る

自分に関連する Issue、PR、レビュー依頼などを確認できます。

gh status

朝の作業開始時に一度実行すると、見るべきものをざっと把握できます。

エイリアスを作る

よく使うコマンドは短い別名を付けられます。

gh alias set prs 'pr list --author @me'
gh prs

この例では、自分が作成した Pull Request 一覧を gh prs で表示できます。

Windows と Ubuntu で共通して気をつけること

ターミナルを開き直す

Windows ではインストーラーが PATH を更新します。gh が見つからない場合は、Windows Terminal や PowerShell を開き直してください。

Ubuntu でも、インストール後にシェルがコマンドの場所をキャッシュしている場合があります。うまく認識されないときは、ターミナルを開き直すか hash -r を実行します。

Git の認証方式をそろえる

gh auth login で HTTPS を選び、Git の認証にも gh を使う設定にした場合、リモート URL も HTTPS にしておくと扱いやすいです。

git remote -v
git remote set-url origin https://github.com/OWNER/REPO.git

SSH を使いたい場合は、gh auth login の対話で SSH を選び、SSH key の登録も gh に任せることができます。HTTPS と SSH のどちらでも使えますが、チームや自分の環境で片方に寄せておくとトラブルシュートが楽です。

GitHub Enterprise Server を使う場合

会社などで GitHub Enterprise Server を使っている場合は、ホスト名を指定してログインします。

gh auth login --hostname github.example.com

通常の GitHub.com とは認証先が別になるため、gh auth status でどのホストにログインしているか確認しておくと安心です。

まとめ

gh を入れておくと、GitHub 上の操作をターミナルから自然に扱えるようになります。

まずは以下の流れだけ覚えておけば十分です。

gh auth login
gh repo clone OWNER/REPO
gh issue list
gh pr list
gh pr create --fill
gh run list

慣れてきたら gh pr checkout、gh pr checks、gh run watch あたりを使うと、Pull Request と CI の確認がかなり楽になります。

参考 URL

WSL でディストリビューションを削除して再インストール後に起動エラーになる

Fri, 14 Jul 2023 00:00:00 +0900

スタートメニューから Ubuntu 20.04 をアンインストールして、再度 MS ストアからインストールして起動しようとしたら以下のエラーが表示されました。

Error code: Wsl/Service/CreateInstance/MountVhd/ERROR_FILE_NOT_FOUND

まず、インストールされているディストリビューションを確認します。

> wsl -l
Linux 用 Windows サブシステム ディストリビューション:
Ubuntu-20.04 (既定)

アンインストールしたはずのディストリビューションが残っていると思うので、以下のコマンドで登録を解除します。

> wsl --unregister Ubuntu-20.04

これで、再度ディストリビューションを起動すれば OK です。

参考 URL

https://www.techgaku.com/fix-ubuntu-boot-error-on-wsl-after-reinstall/

Microsoft ストア版の WSL をインストールする

Thu, 06 Jul 2023 00:00:00 +0900

WSL について、Windows のコンポーネント（組み込み）として提供されているものと、Microsoft Store で提供されているものがあるのを知りました。

きっかけは、WSL2 上の Ubuntu で systemd を使おうとしたら使えなかったことで、調べていくと WSL 自体のバージョンが 0.67.6 以降だと systemd が使えることがわかりました。

WSL 自体のバージョンは以下のコマンドで確認できるらしいのですが、

> wsl --version

私の環境ではバージョンが表示されず、コマンドの説明が表示されてしまいました。

これは、どうやら WSL のバージョンが古いのが原因らしく、最新版は Microsoft Store からインストールできるらしいと。
ここで、2022年11月に正式版としてリリースされたストア版の WSL を知り、自分が使っていたのは「Windows の機能の有効化または無効化」からインストールしたコンポーネント版で、古いプレビュー版の WSL だということを知りました。

https://qiita.com/omu_kato/items/f9a6b5a02e25f5f2a487

ストア版の WSL は普通に Microsoft Store で検索すれば見つかるので、そこでインストールするだけです。

尚、既にコンポーネント版を使っていてもストア版をインストールして使えるようですが、私の環境では Ubuntu 22.04 を起動しようとすると Error code: Wsl/Service/CreateInstance/MountVhd/ERROR_FILE_NOT_FOUND のエラーが出てしまいました。

これについては、以下を参考に WSL から Ubuntu 22.04 の登録を解除すれば直りました。

https://www.techgaku.com/fix-ubuntu-boot-error-on-wsl-after-reinstall/

参考 URL

VSCode で現在アクティブなタブの背景色を変更する

Mon, 12 Jun 2023 00:00:00 +0900

Visual Studio Code のエディタで現在アクティブなタブの背景色が、デフォルトだと他のタブとあまり変わらなくて分かりづらいので、設定で変更しました。

メニューより、ファイル > ユーザー設定 > 設定を選択します。

設定の検索より workbench.colorCustomizations と入力し、「settings.json で編集」をクリックします。

そして、以下のように tab.activeBackground を追記します。

"workbench.colorCustomizations": {
 "tab.activeBackground": "#1b77cf"
}

参考 URL

https://tekunabe.hatenablog.jp/entry/2021/05/23/134458

WSL2 上の Docker コンテナに外部からアクセスする

Fri, 29 Jul 2022 00:00:00 +0900

Ubuntu で Docker を使っている場合はホストとコンテナのポートマッピングさえ行えば外部からアクセスできました。
しかし、WSL2 を使っている場合は Windows と WSL2(Ubuntu) のポートフォワーディングの設定を行わないと外部からはアクセスできません。

尚、タイトルには「Docker コンテナに外部からアクセス」と書きましたが、Windows と WSL2 の話なので、Docker は関係ありません。

環境

ホスト: Windows 10
WSL2: Ubuntu 20.04

設定方法

WSL2 の IP アドレスを調べる

まずは WSL2 上で以下のコマンドを実行し、eth0 の IP アドレスを調べます。

$ ip addr show dev eth0

または hostname -I でも調べられます。

Windows と WSL2 のポートフォワーディング設定

コマンドプロンプトまたは PowerShell で以下のコマンドを実行します。

> netsh interface portproxy add v4tov4 listenport=<ポート> connectaddress=<WSL2のIPアドレス>

これで外部からアクセス可能になります。
設定ができているか確認したい場合は以下のコマンドを実行します。

> netsh interface portproxy show v4tov4

ipv4 をリッスンする: ipv4 に接続する:

Address Port Address Port
--------------- ---------- --------------- ----------
* 5001 172.20.93.38 5001

設定を削除したい場合は以下のコマンドを実行します。

> netsh interface portproxy delete v4tov4 listenport=<ポート>

設定の自動化

WSL2 の IP アドレスは起動の度に変わるので、Windows 起動時に自動で設定するようにします。

Windows 上で WSL2 の IP アドレスを取得

PowerShell で以下を実行します。

> $IP = wsl -d Ubuntu-20.04 exec hostname -I

しかし、私の環境では複数の IP アドレスが表示されてしまいました。

> $IP
172.20.93.38 172.17.0.1 172.18.0.1

なので、以下のようにスペースで区切って最初の IP アドレスだけを取得できるようにしました。

> $IP = (wsl -d Ubuntu-20.04 exec hostname -I).split(" ")[0]

スクリプトファイルの作成と実行

以上を踏まえ、以下のようなスクリプトファイルを作成します。

$IP = (wsl -d Ubuntu-20.04 exec hostname -I).split(" ")[0]
netsh interface portproxy delete v4tov4 listenport=<ポート>
netsh interface portproxy add v4tov4 listenport=<ポート> connectaddress=$IP

あとはこれをタスクスケジューラーでログオン時に実行するようにすれば OK です。

参考 URL

GitLab CI/CD で Uploading artifacts to coordinator... too large archive のエラーが表示された

Fri, 08 Jul 2022 00:00:00 +0900

GitLab CI/CD で成果物をアップロードする際に、サイズが大きすぎるとのエラーが表示されました。

ERROR: Uploading artifacts to coordinator... too large archive id=XXXX responseStatus=413 Request Entity Too Large status=413 Request Entity Too Large token=XXXXX
FATAL: too large 
ERROR: Job failed: exit status 1

GitLab の設定

まずは GitLab の以下の設定を確認します。

「Settings > Continuous Integration and Deployment > Maximum artifacts size (MB) 」

デフォルトでは 100MB に設定されているので、必要ならここを変更します。

しかし、今回は 7MB 程度のファイルだったので、これが原因ではありませんでした。

リバースプロキシの設定

今回 nginx でリバースプロキシの設定を行っていたのですが、client_max_body_size の設定を行っていなかったのが原因でした。
client_max_body_size のデフォルト値は 1MB だそうです。
とりあえず以下のように 0 を設定して無制限にしておきました。

server {
 listen 80;
 server_name example.com;
 client_max_body_size 0;
}

参考 URL

https://pauledenburg.com/gitlab-ci-upload-artifact-fails-large/

Redmine のチケットを一括で他のプロジェクトに移動させる

Tue, 17 May 2022 00:00:00 +0900

ちょっとだけ迷ったのでメモです。

チケットの一覧で、チケットを複数選択
右クリックして「編集」を選択
プロジェクトを変更する

参考 URL

https://linkerdesign.github.io/journal/2013/01/redmine.html

Redmine に Git のリポジトリを追加したら internal error が表示される

Fri, 13 May 2022 00:00:00 +0900

私の場合ですが、タグ名に日本語を使っていたのが原因のようでした。

環境は以下です。

Redmine 3.4.2
Git 1.8.3.1

ちょっと古いバージョンなので最新バージョンではわかりませんが、この環境下では、ブランチやタグの名前に日本語を使っていると internal error となるようです。
Redmine のログを見ていてタグの表示でエラーになっているっぽかったので気が付きました。

参考 URL

https://plugins.co.jp/2015/05/git%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E3%81%AB%E6%97%A5%E6%9C%AC%E8%AA%9E%E5%90%8D%E3%82%92%E3%81%A4%E3%81%91%E3%82%8B%E3%81%A8redmine%E3%81%AE%E3%83%AA%E3%83%9D%E3%82%B8%E3%83%88%E3%83%AA/

Redmine に Git のリポジトリを追加したら 404 エラーが表示される

Thu, 12 May 2022 00:00:00 +0900

まずはファイルパスが正しいかを疑うべきですが、それが正しい場合はアクセス権が原因の可能性があります。

例えば、私の場合、/home/username/xxxx.git という場所にベアリポジトリを作成していたのですが、xxxx.git のアクセス権しか変更していませんでした。

$ sudo chmod o+rx xxxx.git

しかし、その一つ上の /home/username にアクセス権が設定されていなかったため、Redmine からは見ることができなかったようです。
以下のように設定変更すれば解決しました。

$ sudo chmod o+rx /home/username

参考 URL

https://www.pistolfly.com/weblog/2010/11/redminegit.html

GitLab でプライベートリポジトリの分も草を生やす

Mon, 02 May 2022 00:00:00 +0900

GitLab のプロフィールに表示されるコミットグラフですが、デフォルトでは自分以外の人からは Public なリポジトリの分しか見えません。

Private なリポジトリのコミット分も見えるようにするには、以下の設定を変更します。

Preferences > Profile > Private contributions

参考 URL

https://www.igorkromin.net/index.php/2018/09/13/gitlab-finally-shows-private-project-contributions-in-the-profile-commit-graph/

TortoiseGit で過去のコミットの作者（コミッター）を修正する

Wed, 13 Apr 2022 00:00:00 +0900

間違ったアカウント（メールアドレス）でコミットしてしまった場合に、後から TortoiseGit で修正する方法です。

TortoiseGit で過去のコミットメッセージを変更する方法を以下の記事にまとめていますが、

TortoiseGit でコミットメッセージを変更する

コミットメッセージではなく、コミッターの情報を変更したい場合、ここにもう少し手順が必要です。

まずはコミットメッセージを修正する画面を表示する

上記のページを参考に、まずはコミットメッセージを修正する画面を表示します。

そしたら、「コミットを編集/分割する」にチェックを入れて「Amend」をクリックします。

すると、通常コミット時と同じ画面が表示されるので、「作者を設定」にチェックを入れ、右の欄にユーザー名とメールアドレスを入力してコミットします。

「他のコミットを追加しますか？」という画面が表示されますが、コミッターの修正だけであれば「いいえ」を選択します。

他のコミットも編集する場合は同様に修正していきます。
以上です。

git で clone する場合に 503 エラーが表示される

Tue, 12 Apr 2022 00:00:00 +0900

ローカルネットワークにある GitLab からクローンをしようとした際、503 エラーが表示されました。

ググってみるとプロキシ設定が原因という記事が出てきますが、一応プロキシ設定はしているつもりでした。

しかし、どうやら Git はワイルドカードを使ったプロキシ設定を認識してくれないようです。

今回、環境変数 no_proxy に 192.168.1.* のように設定していたのですが、これを 192.168.1.2 のように指定すると正しく表示されました。

Ubuntu 20.04 に古い NVIDIA Driver と CUDA をインストール

Wed, 30 Mar 2022 00:00:00 +0900

古いグラフィックボードが手に入ったので、それに対応した NVIDIA Driver および CUDA をインストールしたときのメモです。

環境

Ubuntu 20.04
GPU：NVIDIA Quadro 2000

NVIDIA Driver のインストール

以下のコマンドでインストールするドライバーのバージョンがわかります。

$ ubuntu-drivers devices

または、以下のページで必要なドライバーのバージョンを調べることもできます。

https://www.nvidia.com/Download/index.aspx

以上より必要なドライバーは 390 だとわかりました。
ドライバーは上記のページからダウンロードできますが、Ubuntu の場合は apt でインストールしたほうが楽です。

$ sudo apt -y install nvidia-driver-390

一度再起動し、nvidia-smi でドライバーが正しくインストールされたか確認します。

$ nvidia-smi
Tue Mar 15 13:51:47 2022
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 390.144 Driver Version: 390.144 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Quadro 2000 Off | 00000000:01:00.0 On | N/A |
| 30% 48C P12 N/A / N/A | 577MiB / 964MiB | 0% Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes: GPU Memory |
| GPU PID Type Process name Usage |
|=============================================================================|
| 0 1193 G /usr/lib/xorg/Xorg 141MiB |
| 0 2102 G /usr/lib/xorg/Xorg 220MiB |
| 0 2276 G /usr/bin/gnome-shell 206MiB |
+-----------------------------------------------------------------------------+

CUDA のインストール

NVIDIA Driver と CUDA のバージョンの関係は以下で確認できます。

https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html

今回インストールした NVIDIA Driver は 390.144 なので、CUDA は 9.1 インストールします。

CUDA のインストール方法ですが、以下でプラットフォームに応じた方法を調べることができます。

https://developer.nvidia.com/cuda-downloads

Ubuntu 20.04 では以下が表示されました。

$ wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/cuda-ubuntu2004.pin
$ sudo mv cuda-ubuntu2004.pin /etc/apt/preferences.d/cuda-repository-pin-600
$ sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/7fa2af80.pub
$ sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2004/x86_64/ /"
$ sudo apt-get update
$ sudo apt-get -y install cuda

しかし、このコマンドでは CUDA のバージョンが指定されていないため、実行してしまうと最新の CUDA がインストールされてしまいます。
なので、次に示すように、バージョン 9.1 を指定してインストールしてやります。

CUDA 9.1 のインストール

CUDA 9.1 をインストールしたいところですが、apt でインストールできる CUDA の一覧を見てみても 9.1 はありません。
なので、以下を参考に Ubuntu 16.04 用のパッケージをインストールしました。

$ curl -sL http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub | sudo apt-key add

$ wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
$ sudo dpkg -i cuda-repo-ubuntu1604_9.1.85-1_amd64.deb
$ sudo apt update

$ sudo apt --fix-broken install
$ sudo apt install cuda-toolkit-9-1
$ sudo reboot
$ rm cuda-repo-ubuntu1604_9.1.85-1_amd64.deb

注意点として、apt で cuda-9-1 をインストールすると NVIDIA Driver も最新に更新されてしまうので、cuda-toolkit-9-1 をインストールする必要があります。

https://zenn.dev/takeshita/articles/a02402e59d72a7

インストールが完了したら、~/.bashrc の末尾に以下を追記します。

export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="/usr/local/cuda/lib64:$LD_LIBRARY_PATH"

ここで再起動します。

CUDA バージョンの確認

nvidia-smi で確認できるはずなのですが、私の環境では何も表示されました。
ただ、nvcc では確認できたので、インストールはされているんじゃないかと。

$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2017 NVIDIA Corporation
Built on Fri_Nov__3_21:07:56_CDT_2017
Cuda compilation tools, release 9.1, V9.1.85

また、以下でも確認できます。

$ cat /usr/local/cuda/version.txt
CUDA Version 9.1.85

CUDA のインストール後に NVIDIA Driver がおかしくなってしまった場合

前述したように、NVIDIA Driver と CUDA のバージョンが合っていなければ動作がおかしくなります。

以下を参考に NVIDIA Driver と CUDA を削除してからインストールをやり直す必要があります。

https://qiita.com/not_charge/items/dce7512544a7ead04bca

$ sudo apt-get --purge remove nvidia-*
$ sudo apt-get --purge remove cuda-*

docker コンテナ内で GPU が使えるか確認しようとして諦めた

せっかく CUDA がインストールできたので、機械学習で GPU が使えそうか確認します。
まず pytorch を使い、ホスト上で以下のコードで確認してみました。

import torch
print(torch.cuda.is_available())

すると、以下のようにエラーが表示されました。

UserWarning: CUDA initialization: The NVIDIA driver on your system is too old (found version 9010). Please update your GPU driver by downloading and installing a new version from the URL: http://www.nvidia.com/Download/index.aspx Alternatively, go to: https://pytorch.org to install a PyTorch version that has been compiled with your version of the CUDA driver. (Triggered internally at /pytorch/c10/cuda/CUDAFunctions.cpp:115.)
 return torch._C._cuda_getDeviceCount() > 0

PyTorch のバージョンも CUDA に合わせる必要があるようです。
以下のページを参考に pytorch のバージョンを指定してインストールしてみます。

https://varhowto.com/install-pytorch-cuda-9-1/

すると以下のエラーが表示されました。

$ pip3 install torch==1.1.0 torchvision==0.3.0 -f https://download.pytorch.org/whl/cu90/torch_stable.html
Looking in links: https://download.pytorch.org/whl/cu90/torch_stable.html
/usr/share/python-wheels/urllib3-1.25.8-py2.py3-none-any.whl/urllib3/connectionpool.py:999: InsecureRequestWarning: Unverified HTTPS request is being made to host '172.20.16.253'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
ERROR: Could not find a version that satisfies the requirement torch==1.1.0 (from versions: 1.4.0, 1.5.0, 1.5.1, 1.6.0, 1.7.0, 1.7.1, 1.8.0, 1.8.1, 1.9.0, 1.9.1, 1.10.0, 1.10.1, 1.10.2, 1.11.0)
ERROR: No matching distribution found for torch==1.1.0

ここらへんから面倒になり、先に docker コンテナを作ることにしました。
まずは NVIDIA Container Toolkit をインストールしようと以下のページを見ると、

https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/install-guide.html

動作要件が以下のようになっていました。

GNU/Linux x86_64 with kernel version > 3.10
Docker >= 19.03 (recommended, but some distributions may include older versions of Docker. The minimum supported version is 1.12)
NVIDIA GPU with Architecture >= Kepler (or compute capability 3.0)
NVIDIA Linux drivers >= 418.81.07 (Note that older driver releases or branches are unsupported.)

というわけでここで諦めました。

参考 URL

Ubuntu にリモートデスクトップ接続する

Sun, 13 Mar 2022 00:00:00 +0900

Windows から Ubuntu にリモートデスクトップで接続する方法です。

Ubuntu 側

Xrdp サーバーをインストールします。

$ sudo apt -y install xrdp

Windows 側

リモートデスクトップで Ubuntu の IP アドレスを入力して接続します。

画面が真っ暗な場合

同じユーザーで既に Ubuntu にログイン済みの場合、真っ暗な画面が表示されます。

Ubuntu 側で一度ログアウトするか、別途 SSH などで Ubuntu に接続し、以下のコマンドで gnome-session を終了させます。

$ pkill gnome-session

参考 URL

WSL2 で GUI を表示する

Sun, 16 Jan 2022 00:00:00 +0900

Windows に Xサーバーをインストールし、WSL2 上で実行した GUI アプリを表示できるようにする方法です。

環境

Windows 10
WSL2:Ubuntu 20.04

Xサーバーのインストール

Windows にXサーバーをインストールします。私は以下のページを参考に VcXsrv を入れました。

https://rin-ka.net/windows-x-server/

他には MobaXterm も良さそうですね。

あとは、ファイアウォールの設定も許可する必要があります。
設定完了後、VcXsrv 起動時に許可を求める画面が表示されるので、そこで全て許可しました。

WSL2 側の設定

Linux ではおなじみの export DISPLAY=:0 では駄目なようで、IPアドレスを指定する必要があるみたいです。

https://odaryo.hatenablog.com/entry/2020/01/08/114846

以下のようにすれば IP アドレスを読み込んで環境変数をセットしてくれるようです。

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

これを毎回入力するのも面倒なので、.bashrc に書いておけば、WSL2 起動時に自動でセットされるようです。

動作確認

VcXsrv を、Disable access control にチェックを入れて起動し、WSL2 上で以下のコマンドを実行して確認します。

$ xeyes

VSCode + Remote-Containers を使う場合

WSL2 上で VSCode を実行して Remote-Containers を使う場合、WSL2 の DISPLAY の値を Retemo-Containers 側にも引き継げば、Retemo-Containers でも GUI の表示が可能です。

https://qiita.com/y-na-biz/items/af0137532e6e22802f25#%E5%8F%82%E8%80%83devcontainerjson%E8%A8%AD%E5%AE%9A%E4%B8%80%E8%A6%A7

{
	"runArgs": [
		"-e", "DISPLAY=${env:DISPLAY}",
	],

	"mounts": [
		"source=/tmp/.X11-unix/,target=/tmp/.X11-unix/,type=bind",
	],
}

参考 URL

WSL2 のインストール

Sat, 15 Jan 2022 00:00:00 +0900

WSL2 をインストールし、WSL2 上で Ubuntu を動かす方法です。

環境

Windows 10 Pro OSビルド 19042.1466

WSL2 のインストール

公式ドキュメントは以下です。

WSL のインストール

PowerShell を起動し、以下のコマンドを入力します。

> wsl --install

WSL2 にアップデート

以下にアクセスし、wsl_update_x64.msiをダウンロードしてインストールします。

https://aka.ms/wsl2kernel

WSL2 をデフォルトにする

> wsl --set-default-version 2

Ubuntu のインストール

MS Store から Ubuntu で検索してインストールするだけです。

WSL2 で動作しているか確認

> wsl --list --verbose
 NAME STATE VERSION
* Ubuntu Running 2

* が付いているのがデフォルトのディストリビューションです。 VERSION が 2 になっているので、WSL2 で動作しています。

デフォルトのディストリビューションを変更する場合は、以下のように変更します。

> wsl --set-default Ubuntu

WSL のバージョンが2でない場合、以下のようにして設定します。

> wsl --set-version Ubuntu 2

参考 URL

VSCode の Remote-Containers を起動したときに、マウントのパスに無効な文字が含まれているというエラーが表示された

Wed, 01 Sep 2021 00:00:00 +0900

ホストのディレクトリをコンテナにマウントしたかったのですが、以下のようなエラーが表示されました。

docker: Error response from daemon: create /home/user/workspace: "/home/user/workspace" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.

devcontainer.json の mounts の設定は以下です。

"mounts": [
	"source=${localWorkspaceFolder}/workspace,target=/workspace",
],

type を省略してしまっていたのですが、type のデフォルトは volume なので、ボリュームをマウントしようとしてエラーになっていたみたいです。
以下のように type=bind を指定したら上手くいきました。

"mounts": [
	"source=${localWorkspaceFolder}/workspace,target=/workspace,type=bind",
],

参考 URL

git-svn の使い方

Sat, 03 Jul 2021 00:00:00 +0900

社内で未だに SVN で開発しているプロダクトがあるので、git-svn を使ってみました。

環境

Ubuntu 20.04
git 2.25.1
svn 1.13.0

インストール

$ sudo apt install git-svn

クローン

SVN リポジトリを指定してクローンを行います。

$ git svn clone --prefix=svn/ <SVNリポジトリのURL>

--prefix は SVN のブランチに接頭辞をつけるオプションで、一般的に付けたほうがよいとされています。

SVN リポジトリが標準的な構成(trunk, branch, tag) になっている場合は -s オプションを付けます。
標準的な構成になっていない場合は --trunk branches --tags を使用する。
今回はルートが trunk になっており、ブランチも作成していなかったため、以下のように指定しました。

$ git svn clone --trunk=/ --prefix=svn/ <SVNリポジトリのURL>

試しにブランチを表示してみると、以下のようになっていました。

$ git branch -a
* master
 remotes/svn/trunk

コミット

コミットは普通に git を使ってやるのと同じです。

SVN リポジトリにコミットを反映する

git でのプッシュに該当する操作として、SVNにコミットを行います。
コミット前にリベースで git のコミットをまとめておいたほうがいいかもしれません。

$ git svn dcommit

SVN リポジトリから最新のデータを取得

リベースを行うことになるみたいです。

$ git svn rebase

尚、これを行うにはワークディレクトリ内の全ての変更がコミットされている必要があるみたいです。コミットしていない変更があった場合、以下のようなエラーが表示されます。

/workspace/hoge: needs update
update-index --refresh: command returned error: 1

参考 URL

git でコミットを一つにまとめる

Fri, 02 Jul 2021 00:00:00 +0900

Ｗindows 環境では TortoiseGit を使っているので GUI で出来るのですが、Ubuntu で使っている RabbitGit では出来なさそうだったので、コマンドでやりました。

TortoiseGit でのやり方は以下です。

https://kuttsun.blogspot.com/2018/09/tortoisegit.html

環境

Ubuntu 20.04

まずログを確認

$ git log --oneline

以下のように表示されます。

5418fe (HEAD -> master) fuga
f3896f7 piyo
af6639b hoge
b1da633 initial commit

ここで３つのコミット（hoge、piyo、fuga のメッセージのやつ）を一つにまとめてみます。

リベースの開始

まとめたいコミット群の一つ前のコミットに対してリベースを行います。

$ git rebase -i HEAD~3

HEAD~3 は HEAD~~~ やハッシュ値でも構いません。

すると、テキストエディタで編集画面が表示されます。
私の場合は nano で表示されました（vi じゃなくてよかった）。

pick af6639b hoge
pick f3896f7 piyo
pick c5418fe fuga

# Rebase b1da633..c5418fe onto b1da633 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# . create a merge commit using the original merge commit's
# . message (or the oneline, if no original merge commit was
# . specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

-i オプションを指定したので、この画面では Rebase を使って現在と過去の間に残ってるコミットをどう処理するかを聞かれています。

最新以外の pick の箇所を s または squash に変更します。

変更前

pick af6639b hoge
pick f3896f7 piyo
pick c5418fe fuga

変更後

pick af6639b hoge
s f3896f7 piyo
s c5418fe fuga

保存して終了すると、コミットメッセージの編集画面が開きます。
必要に応じて編集し、終了します。

参考 URL

RabbitVCS のインストール

Thu, 01 Jul 2021 00:00:00 +0900

Windows では TortoiseSVN と TortoiseGit を使っていたので、Linux でも GUI で良いのがないかなと探していたら、RabbitVCS というのが Tortoise に似た感じだったので、インストールしてみました。

環境

Ubuntu 20.04

インストール

以下に説明があります。

http://wiki.rabbitvcs.org/wiki/install/ubuntu

以下のコマンドを実行するだけでインストールできました。

$ sudo apt install rabbitvcs-nautilus

これ一つで RabbitVCS SVN RabbitVCS Git RabbitVCS Hg が使えるようになるっぽい。

あとはファイル比較用の Meld とかいうツールも勝手に入ってました。

再起動後には Tortoise と同じように、フォルダにアイコンが表示されるようになっていました。

所感

まだ全然使っていませんが、とりあえず最新のコードをプルしたりだとか、コミットログを見たりだとか、ファイルの差分を閲覧する分には困っていません。

参考 URL

VSCode + Remote-Containers で python の開発環境を作成する

Fri, 18 Jun 2021 00:00:00 +0900

VSCode の Remote-Containers を使い、python 開発用の docker コンテナを作成し、そのコンテナ中で python のデバッグをできるようにします。

環境

Ubuntu 20.04
Visual Studio Code 1.56.2
Remote Development 0.21.0

これらはインストールされている前提です。

設定ファイルの作成

コマンドパレットを開いて(Shift + Ctrl + p)、Remote-Container: Add Development Container Configuration Files を実行します。

Python3 を選択し、続いて Python のバージョンを選択します。
その後、Node.js をインストールするかどうか表示されますが、今回は必要ないのでチェックを外しました。

OK を押すと、以下のファイルが作成されます。

.devcontainer
├── Dockerfile
└── devcontainer.json

コンテナ起動

画面左下のマークを押し、Reopen in Container を選択するとコンテナが起動します。

拡張機能のインストール

Remote-Containers を使う場合、VSCode の拡張機能もコンテナ用に別途インストールする必要があるみたいです。

devcontainer.json の extensions に記載しておけば、コンテナ作成時に自動的に拡張機能もインストールされるようです。
今回は設定ファイル作成時に Python を選択したので、最初から下記の２つが記載されていました。

 "extensions": [
 "ms-python.python",
 "ms-python.vscode-pylance"
 ],

従って、コンテナを起動した時点で python と pylance は最初から入っているはずなのですが、何故か私の環境ではインストールされていません。

仕方がないので、手動でインストールしました。

手動でのインストール

まず、DEV CONTAINER のところの雲のアイコンをクリックします。

ローカルにインストールされている拡張機能一覧が表示されるので、コンテナ内にインストールしたい拡張機能にチェックを入れます。

インストールが完了した後は一度 VSCode を再起動したほうがよいかと思います。

デバッグを開始する

あとはローカル環境で python のデバッグを行う場合と同じです。

https://kuttsun.blogspot.com/2020/01/vscode-python.html

参考 URL

git コマンドのメモ

Mon, 07 Jun 2021 00:00:00 +0900

普段は TortoiseGit を使っており、いざコマンドしか使えない環境のときに困るので、個人的によく使う基本的なコマンドについてメモしておきます。

適宜更新していきます。

設定

現在の設定を確認

$ git config --list

システム全体(system)、ユーザー全体(global)、対象リポジトリのみ(local)を確認したい場合はそれぞれ以下。

$ git config --system --list
$ git config --global --list
$ git config --local --list

ローカルのユーザーとメールアドレスを設定

$ git config --local user.name "My Name"
$ git config --local user.email myname@example.com

リモートリポジトリの情報

リモートリポジトリの名前を表示する

$ git remote

リモートリポジトリの名前と場所(URL）を表示する

$ git remote -v

指定したリモートリポジトリの詳しい情報を表示する

$ git remote show <リポジトリ名>

リモートリポジトリの追加・削除・変更

追加する

$ git remote add <リポジトリ名> <URL>

削除する

$ git remote rm <リポジトリ名>

URL の変更

$ git remote set-url <リポジトリ名> <変更先のURL>

開発中に使うコマンド

クローン

$ git clone <URL>

差分を表示

$ git status

-s を使えると簡略化して表示されます。

コミットの流れ

ステージング

$ git add ファイル名

コミット

$ git commit -m "コメント"

プッシュ

$ git push

最後のコミットのやり直し

$ git commit --amend -m "コミットメッセージ"

変更の破棄

$ git checkout <filename>

全て破棄したい場合は以下

$ git checkout .

参考 URL

Git で HTTPS を使う場合のアカウント情報を記憶させる

Tue, 01 Jun 2021 00:00:00 +0900

毎回打つのが面倒なので。

Windows の場合

クローンするときにユーザー名とパスワードが聞かれますが、一度入力すると資格情報マネージャーに登録されるので、２回目以降はユーザー名とパスワードの入力が不要になります。
もし入力間違いをしてしまった場合は、資格情報マネージャーで削除すれば OK です。

Linux の場合

Ubuntu 20.04 で確認しました。
libsecret をインストールして、credential.helper に設定してやります。

sudo apt-get install libsecret-1-0 libsecret-1-dev
cd /usr/share/doc/git/contrib/credential/libsecret
sudo make
git config --global credential.helper /usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret

これで、一度ユーザー名とパスワードを入力したら、次回以降は入力不要になります。

開発環境 on ポンコツ地方エンジニアの技術ブログ

VS Code での Git Worktree の使い方

環境

事前準備

ワークツリーの作成

ワークツリーを作業ツリーで開く

ワークツリーの削除

Ubuntu で Orca を使う

環境

ダウンロード

実行手順

エラーがでた場合

libfuse2 がない

chrome-sandbox の権限エラー

原因

Codex のレート制限リセット権の有効期限の確認方法

スクリプトの作成

実行手順

注意

OCI や AWS EC2 でセッション切断後も処理を止めないよう tmux を使う

先にまとめ

tmux のインストール

まずは 1 回動かしてみる

1. セッションを作る

2. プログラムを起動する

3. セッションを切り離す（detach）

4. 再接続する（attach）

セッションを終了して抜ける（プロセスを停止してセッションを閉じる）

今回の用途で最低限覚えるコマンド

キー操作の最小セット

よくあるハマりどころ

SSH を切ったら止まった

tmux attach で「no sessions」になる

セッション名を忘れる

Claude Code の認証情報とチャット履歴を devcontainer とホストで共有する

環境

きっかけ

ゴール構成

Claude Code が何を見ているかを把握する

設定する 2 つのマウント

1. .claude / .claude.json のマウント (= コンテナ側ユーザーの home に合わせる)

2. ワークスペースのマウント (= ホスト側の絶対パスに合わせる)

devcontainer.json の例

Dockerfile 側で親ディレクトリを用意しておく

ユーザーは vscode のままでよい

注意点

まとめ

GitHub CLI (gh auth login) で Git の HTTPS 認証を安全にする

環境

きっかけ

ゴール構成

手順

1. 露出したトークンを revoke (最優先)

2. gh をインストール

3. gh auth login で認証

4. remote URL からトークンを除去

5. シェル履歴の残骸を確認

devcontainer での認証共有

補足: SSH 鍵にしないのか

まとめ

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

1. インストール方法

2. 初期設定（認証）

3. devcontainer での認証情報共有

4. よく使う基本コマンド集

■ Merge Request (MR) を操作する

■ Issue (課題) を管理する

■ CI/CD パイプラインを確認する

4. gh と glab の主な対応表

5. 自社運用の GitLab (Self-Managed) で使うコツ

まとめ

GitHub CLI (gh) のインストールと基本的な使い方

gh でできること

インストール

Windows にインストールする

Ubuntu にインストールする

初期設定: GitHub にログインする

普通の git コマンドでも gh の認証情報は使われる？

よく使う基本コマンド

リポジトリ操作

`tmux attach` で「no sessions」になる

1. `.claude` / `.claude.json` のマウント (= コンテナ側ユーザーの home に合わせる)

2. `gh` をインストール

3. `gh auth login` で認証

4. `gh` と `glab` の主な対応表