トラブルシューティング on KnightLiブログ

Codex Skill はディレクトリにあるのに、なぜ表示されないのか？

Wed, 29 Apr 2026 11:18:00 +0800

今回の問題はかなり見落としやすいものでした。~/.codex/skills には複数の skill が置かれているのに、新しい Codex スレッドを開いても、サイドバーには一部しか表示されませんでした。

最初はキャッシュやインデックスの問題に見えました。実際の原因はもっと具体的で、いくつかの SKILL.md ファイルの先頭に UTF-8 BOM が付いていました。Codex 0.111.0 の skill loader はこのバイト列を読み飛ばさず、結果として有効な YAML front matter がないと誤判定していました。

現象

ローカルディレクトリには次の skill がありました。

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

しかし新しいスレッドで実際に公開された skill は次の二つだけでした。

1
2

bilibili-speech-transcriber
product-cutout-normalize

つまり、ファイルが存在することと、現在のセッションで読み込めることは別です。Codex は各 SKILL.md の front matter を先に解析し、解析に失敗した skill はそのまま除外します。

調査

codex exec で新しいセッションを起動すると、より直接的なエラーが見えます。VS Code などの IDE では、こうした log が見えない場合があります。

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

これらのファイルは、見た目には正常な先頭を持っていました。

---
name: post-rewrite
description: ...
---

本当の問題はバイト列にありました。

失敗するファイルの先頭は：

`1`	`EF-BB-BF-2D-2D-2D`

正常に読み込まれるファイルの先頭は：

`1`	`2D-2D-2D`

2D-2D-2D は --- です。その前にある EF-BB-BF が UTF-8 BOM です。

原因

Codex 0.111.0 の skill loader は、SKILL.md の最初のバイトが --- の最初の - であることを期待しています。

ファイルの先頭に UTF-8 BOM があると、実際の先頭は次のようになります。

`1`	`BOM + ---`

そのため loader は、ファイルが front matter の区切りで始まっていないと判断し、最終的に次のエラーを出します。

`1`	`missing YAML frontmatter delimited by ---`

skill の内容が間違っていたわけでも、ディレクトリが間違っていたわけでもありません。エンコーディングの細部が原因で、パーサーがファイルを認識できなかっただけです。

修正

問題のある SKILL.md を BOM なしの UTF-8 に変換します。

PowerShell では次のように処理できます。

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

処理後にファイルヘッダーを確認すると、次の状態から：

`1`	`EF-BB-BF-2D-2D-2D`

次の状態に変わっているはずです。

`1`	`2D-2D-2D`

検証

Codex セッションを再起動すると、表示される skill は次のように戻りました。

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

それでもサイドバーに古い一覧しか表示されない場合は、現在の Codex sidebar またはウィンドウを閉じて、プロジェクトを開き直します。skill 一覧は通常セッション開始時に読み込まれるため、途中でファイルを変更してもすぐには反映されないことがあります。

最後に

この種の問題は、「Codex が再インデックスしていない」または「skill のインストールに失敗した」と誤解しやすいです。

実際に調べるときは、まず次の三点を確認するとよいです。

SKILL.md が正しいディレクトリにあるか
ファイル先頭に有効な --- front matter があるか
ファイルが BOM なしの UTF-8 か

今回のポイントは三つ目です。ファイルは見た目には問題ありませんでしたが、最初のバイトが - ではなかったため、Codex はそれを有効な skill として扱いませんでした。

Tesla V100 に ECC エラーがあるか確認する方法

Thu, 23 Apr 2026 11:50:21 +0800

手元に Tesla V100 があり、まず基本的なヘルスチェックをしたいなら、優先して確認したい項目のひとつが ECC の状態です。

最も手軽な方法は、nvidia-smi でカードの詳細情報を確認することです。

1
2
3

nvidia-smi -q
# 查询第 0 块 GPU
nvidia-smi -q -i 0

見るべきなのは ECC Errors のセクションです。

正常な状態のカードであれば、ECC Errors の下にある代表的な 4 つの統計グループは、いずれも 0 または N/A であるはずです。ここにすでに非ゼロの値がある場合、そのカードは過去に対応する種類の ECC 異常を起こしたことがあるため、引き続き使用してよいか追加で判断する必要があります。

参考出力は次のとおりです。

nvidia-smi -q
    ECC Mode
        Current                          : Enabled
        Pending                          : Enabled
    ECC Errors
        Volatile
            Single Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : N/A
                Total                    : 0
            Double Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : 0
                Total                    : 0
        Aggregate
            Single Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : N/A
                Total                    : 0
            Double Bit
                Device Memory            : 0
                Register File            : 0
                L1 Cache                 : 0
                L2 Cache                 : 0
                Texture Memory           : N/A
                Texture Shared           : N/A
                CBU                      : 0
                Total                    : 0
    Retired Pages

簡単に整理すると、次のように理解できます。

Volatile は今回の通電サイクル内でのエラー統計
Aggregate は累積エラー統計
Single Bit は訂正可能エラー
Double Bit は訂正不能エラーで、よりリスクが高い

素早くふるい分けしたいだけなら、まずは次の基準を覚えておけば十分です。

ほとんどの項目は 0 であるべき
該当しない項目が N/A なのは正常
Double Bit や合計値が 0 でない場合は、売り手の説明だけを鵜呑みにせず、より十分なストレステストと安定性確認を続けるべき

この確認だけで完全な検品にはなりませんが、V100 を入手した直後の第一段階のチェックとしては十分に実用的です。

Windows タスクマネージャーのデータは一時停止され、更新されません。通常、更新速度は一時停止に設定されます。

Thu, 09 Apr 2026 18:15:53 +0800

Windows タスクマネージャーを開くと、[プロセス] または [パフォーマンス] ページのデータがスタックしているように見え、CPU、メモリ、ディスク、またはネットワークの値が長期間変更されていないことがわかることがあります。一見するとシステムの異常のように見えますが、実際に実行されているプログラム、ネットワーク伝送、リソースの使用状況は正常に変化しています。

この状況は通常、システムが実際に停止したことを意味するのではなく、タスクマネージャーの更新頻度が「一時停止」に変更されたことを意味します。

現象

一般的な症状には次のものがあります。

「プロセス」ページの CPU、メモリ、その他のデータがジャンプしなくなりました
「パフォーマンス」ページのカーブが長期間更新されない
明らかにプログラムが実行されていますが、タスクマネージャーは非アクティブになっているように見えます。

問題が発生した場合のインターフェイスの例を次に示します。

理由

タスクマネージャーは、「更新速度」の調整をサポートしており、高速、標準、低速、または一時停止に直接設定できます。

これを「一時停止」に設定すると、インターフェイス上のさまざまな統計情報が更新されなくなるため、CPU、メモリ、またはネットワーク情報がすべて停止したように見えます。

下の図に示すように、このオプションは通常、タスクマネージャーの上部メニューの [表示] にあります。

トラブルシューティング on KnightLiブログ

Codex Skill はディレクトリにあるのに、なぜ表示されないのか？

現象

調査

原因

修正

検証

最後に

Tesla V100 に ECC エラーがあるか確認する方法

Windows タスク マネージャーのデータは一時停止され、更新されません。通常、更新速度は一時停止に設定されます。

現象

理由

Windows タスクマネージャーのデータは一時停止され、更新されません。通常、更新速度は一時停止に設定されます。