開発ツール on KnightLiブログ

Codex がコンピューターを操作し始めると、これから何が変わるのか？

Wed, 29 Apr 2026 11:28:25 +0800

今回の Codex で最も注目すべき変化は、普通のボタンが一つ増えたことではありません。Codex が「コンピューターを操作する」方向へ進み始めたことです。

これまで AI を使うとき、多くの場合はチャット欄で質問し、コピーして貼り付け、その後は人間が手動でソフトウェアを操作していました。
今、その境界が外側へ広がり始めています。AI は答えるだけでなく、あなたの目的に合わせてデスクトップアプリを操作できるようになりつつあります。

短期的には新機能の一つです。長期的には、多くの人のコンピューターの使い方を変えるかもしれません。

この機能とは何か

簡単に言えば、Codex のコンピューター操作機能は、デスクトップ環境に触れ、それを操作できるようにするものです。

できることは次のようなものです。

特定のアプリを選択して操作する
自然言語でタスクを受け取る
ブラウザ、AI ツール、ローカルファイル、その他のソフトウェアを開く
テキストを入力し、ボタンをクリックし、結果を待つ
複数の手順を一つのタスクとしてつなげる
ユーザーが一歩ずつ追わなくても、バックグラウンドで実行を続ける

役割は、単に文章を一段落書くことではありません。操作の流れそのものを代行することです。

ここが Agent と普通のチャットボットの大きな違いです。
チャットボットは主に答えを返します。Agent は「目的を受け取り、それを実行する」ものに近づきます。

なぜ重要なのか

これまで多くの自動化には、スクリプトを書く力が必要でした。

たとえば、複数のソフトウェアをまたぐ作業をしたいとします。

Web ページを開く
情報を探す
内容をコピーする
別の AI ツールに渡す
ファイルを保存する
ローカルディレクトリを開いて結果を確認する

従来の方法でこれを自動化するなら、ブラウザスクリプト、API、ローカルプログラム、場合によってはウィンドウ操作まで扱う必要があります。

しかし、多くの一般ユーザーはそうしたものを書けません。
書ける人でも、一時的な作業のために専用スクリプトを書く価値があるとは限りません。

コンピューター操作機能の意味はここにあります。
「スクリプト的な能力」を自然言語の方向へ一歩押し出します。

どこをクリックするかを細かく教える必要はありません。
欲しい結果を伝え、あとは Agent に試してもらう形に近づきます。

どんなワークフローが変わるのか

最初に変わるのは、極めて厳密で高リスクな仕事ではなく、面倒で、細かく、繰り返しが多く、それでも専用プログラムを書くほどではない作業だと思います。

1. ソフトウェア間の情報移動

典型的なのは、複数のソフトウェア間で情報を移動する作業です。

これまでは、ブラウザ、文書、チャット画面、ローカルフォルダを何度も行き来していたかもしれません。
今後は、こうした作業を Agent に任せられるようになります。

ある種類の情報を探す
文書にまとめる
指定フォルダに保存する
結果を開いて確認できる状態にする

この作業は難しくありませんが、注意力を消耗します。
Agent の価値は、こうした細かい操作を吸収することです。

2. 複数の AI ツールの連携

今では、一つの AI ツールだけで完結しない作業も増えています。

たとえば：

あるツールでコードを書く
あるツールで資料を調べる
あるツールで画像を生成する
あるツールで文書を整理する

これまでは、それらの間を人間がコピー&ペーストでつないでいました。
これからは、Agent が中間層になれます。ツールを開き、文脈を渡し、出力を待ち、結果を整理します。

これにより、「複数の AI ツールの協調」は手作業から半自動の流れに変わります。

3. オフィスソフトの自動化

表計算、プレゼン、文書、メールには共通点があります。機能は強力ですが、操作は細かいものが多いということです。

Agent がこれらを安定して操作できるようになれば、オフィス自動化のハードルはかなり下がります。

メニューの場所を覚えたり、複雑なショートカットを覚えたりする必要は薄れます。
必要なのは、目的をはっきり伝えることです。

この表を月報にまとめる
この文書から 1 ページの要約を作る
これらの資料を構造の分かりやすい説明にまとめる

面倒なボタン操作は、少しずつ自然言語の後ろに隠れていくでしょう。

一般ユーザーにとっての意味

一般ユーザーにとって、この種の機能は「モデルが少し賢くなった」ことよりも直接的な影響を持つかもしれません。

下がるのは知識のハードルだけではなく、操作のハードルだからです。

多くの人は、やりたいことを説明できないわけではありません。
どこをクリックすればよいか、ソフトウェアの機能をどう組み合わせればよいかが分からないのです。

Agent がそこを引き受けられるなら、コンピューターの使い方は次のようになります。

1
2
3

私が目的を説明する
Agent がソフトウェアを操作する
私が結果を確認する

これは単なるチャットより、実際の生産性に近い形です。

ソフトウェアの形にも影響する

この種の Agent 能力が成熟していけば、ソフトウェアそのものも影響を受けます。

これまでソフトウェア設計は、主に人間のクリックに向けられていました。
これからは、Agent による操作も意識する必要が出てきます。

つまり：

UI 要素はより明確である必要がある
操作結果のフィードバックは安定している必要がある
ローカル権限はより細かく管理される必要がある
ソフトウェアは Agent が呼び出しやすいインターフェースを用意するかもしれない
ユーザーは「AI がうまく操作できるか」を気にするようになる

長期的には、アプリ間の境界は薄くなるかもしれません。
ユーザーが気にするのは「どのアプリを開くか」ではなく、「どのタスクを完了したいか」になります。

まだ過度に楽観する段階ではない

もちろん、今すぐ完全に任せる段階ではありません。

この能力には、まだ明確な制限があります。

安定性はまだ見ていく必要がある
複雑なタスクは途中で失敗する可能性がある
権限の境界は慎重に扱う必要がある
アカウント、支払い、ファイル削除のような操作は簡単に任せるべきではない
利用枠の消費も無視できない

そのため現時点で最も向いている使い方は、コンピューター全体を完全に任せることではありません。
低リスクで、確認可能で、手順が多い作業を任せることです。

たとえば：

資料を整理する
下書きを生成する
ツール間で内容を移動する
ファイルを開いて確認する
人間が最後に確認できる半自動フローを実行する

最後に

今回の Codex 更新で本当に重要なのは、AI が「質問に答える」段階から「環境を操作する」段階へ進んだことです。

短期的には、これはコンピューター操作機能です。
長期的には、個人用コンピューターとの関わり方の転換点になるかもしれません。

これから私たちは、ボタンを覚えたり、メニューを探したり、ウィンドウを切り替えたりする時間を減らしていくかもしれません。
その代わりに、目的を伝え、Agent に実行させ、最後に人間が判断する場面が増えていくでしょう。

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 として扱いませんでした。

Codex の ~/.codex/skills とプロジェクト/.codex/skills の違い

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

Codex skills を整理するとき、多くの人がつまずきやすい問題は主に二つあります。

~/.codex/skills と プロジェクト/.codex/skills は何が違うのか
skill はディレクトリにあるのに、なぜ現在のセッションに表示されないことがあるのか

この文章では結論から整理します。

両者の違い

まず短く覚えるなら、こうです。

~/.codex/skills は自分用のグローバルなスキルライブラリ
プロジェクト/.codex/skills はそのリポジトリ用のローカルなスキルライブラリ

`~/.codex/skills`

ここに置くのに向いているもの：

自分が複数プロジェクトで繰り返し使う skill
特定のリポジトリに依存しない汎用的な手順
明らかに個人の作業習慣に属するワークフロー

たとえば：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

このタイプの skill の特徴は、現在のプロジェクトを離れても使えることです。

`プロジェクト/.codex/skills`

ここに置くのに向いているもの：

このリポジトリでだけ成立する手順
現在のプロジェクトのディレクトリ構成、スクリプト、テンプレートに強く結びついたルール
チームで共有したい skill

たとえば：

このリポジトリ固有の公開フロー
このプロジェクト内でしか使えない生成テンプレート
プロジェクト固有のスクリプトに強く依存する自動化手順

このタイプの skill の特徴は、このリポジトリを離れると意味が薄くなることです。

グローバルに置くか、プロジェクトに置くか

判断基準はシンプルです。

個人の作業習慣に関係するなら ~/.codex/skills
リポジトリのルールに関係するなら プロジェクト/.codex/skills
複数プロジェクトで再利用できるなら、まずはグローバル
複数人で共有し、リポジトリと一緒に育てたいなら、プロジェクト側

今回のリポジトリの状態

現在見えている状態では：

ローカル環境には ~/.codex/skills がある
現在のリポジトリには .codex/skills がない

つまり、今は主にグローバル skills に依存しています。

言い換えると、post-rewrite、post-translate、git-commit-push のような手順は、このリポジトリに明示的に含まれているものではなく、あなた個人のワークフローに近いものです。

ディスク上にあるのに、現在のセッションに表示されない理由

ここでは二つの状態を分けて考える必要があります。

ディスク上に存在する：skill ファイルがローカルのディレクトリにある
セッションに公開されている：現在のセッションがそれを利用可能な skill として登録している

この二つは同じではありません。

そのため、次のようなことが起きます。

~/.codex/skills にはすでに skill がある
しかし / の後に出る一覧には表示されない

これは通常、skill が壊れているという意味ではありません。より多い原因は、現在のセッションがそれを再インデックスしていないことです。

現在のセッションに skill を表示させるには

実用上の手順は次の通りです。

1. 正しいディレクトリに置く

グローバル：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

プロジェクト単位：

`1`	`プロジェクト/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` の先頭を認識できる形にする

最低限、次のような front matter が必要です。

---
name: your-skill-name
description: この skill が何をするものか
---

3. 新規作成または編集後は、新しいセッションを開く

skill が表示されない原因は、ファイルの問題ではなく、現在のセッション開始時に利用可能な skill 一覧がすでに確定していたことかもしれません。

そのため、セッション中に skill を作成しても、ディスク上には存在する一方で、そのセッションでは認識されない場合があります。

いちばん確実な流れは次の通りです。

skill を正しい場所に置く
現在のセッションを終了する
プロジェクトに入り直す
新しいセッションを開く
/ に表示されるか確認する

4. プロジェクト skill は事前に置いておく

プロジェクト/.codex/skills をより安定して認識させたいなら、リポジトリに入り、セッションを開始する前に、それらの skill をプロジェクト内に置いておくのが無難です。

最後に

短くまとめると：

~/.codex/skills は個人用のスキルライブラリ
プロジェクト/.codex/skills はリポジトリ用のローカルルールライブラリ
skill がディレクトリにあることと、現在のセッションに表示されることは別
表示させたいなら、正しいディレクトリに置き、正しい SKILL.md を書き、新しいセッションを開くのが基本

GoAccess最新版の自前ビルドと利用メモ: ソース導入からリアルタイムHTMLレポートまで

Wed, 29 Apr 2026 00:08:00 +0800

整理時点は 2026-04-29 です。
現時点で公式 README に載っている最新安定版は 1.10.2 です。

1. まずビルド依存を入れる

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. 最新ソースパッケージを取得する

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. ビルドオプションを設定する

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

リアルタイムHTMLレポートで TLS も使いたいなら、こちらでもよいです。

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. ビルドしてインストールする

1
2

sudo make
sudo make install

5. バージョンを確認する

1
2

goaccess --version
which goaccess

6. 端末でそのままレポートを見る

Nginx や Apache の一般的な combined ログなら、まずはこれでよいです。

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

Apache のログパスならこちらです。

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. 静的な HTML レポートを生成する

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

カレントディレクトリに出しても構いません。

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. リアルタイム HTML レポートを生成する

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

ポートを変えるなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

ローカルホストだけにバインドするなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. ログを追い続ける

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

ファイル先頭から読んで、そのままリアルタイムで追うなら:

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. 特定のリクエストだけを見る

たとえば firefox を含むリクエストだけ:

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

たとえば 5xx と 3xx だけ:

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. 複数ログをまとめて解析する

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

圧縮済みと未圧縮をまとめて読むなら:

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. マルチスレッドを使う

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

chunk を大きくするなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. 増分処理

まず古いログを永続化しておく:

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

次に現在のログを追加する:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

永続化済みデータだけを読む:

`1`	`goaccess --restore`

14. 自分なら最初に流すコマンド

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

だいたいこれで十分です。
やることが明確なら、最新版をソースから入れて、まず --log-format=COMBINED と --real-time-html を通すところまで進めれば、あとはログパス、出力先、ポートを調整していくくらいです。

開発ツール on KnightLiブログ

Codex がコンピューターを操作し始めると、これから何が変わるのか？

この機能とは何か

なぜ重要なのか

どんなワークフローが変わるのか

1. ソフトウェア間の情報移動

2. 複数の AI ツールの連携

3. オフィスソフトの自動化

一般ユーザーにとっての意味

ソフトウェアの形にも影響する

まだ過度に楽観する段階ではない

最後に

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

現象

調査

原因

修正

検証

最後に

Codex の ~/.codex/skills と プロジェクト/.codex/skills の違い

両者の違い

~/.codex/skills

プロジェクト/.codex/skills

グローバルに置くか、プロジェクトに置くか

今回のリポジトリの状態

ディスク上にあるのに、現在のセッションに表示されない理由

現在のセッションに skill を表示させるには

1. 正しいディレクトリに置く

2. SKILL.md の先頭を認識できる形にする

3. 新規作成または編集後は、新しいセッションを開く

4. プロジェクト skill は事前に置いておく

最後に

GoAccess最新版の自前ビルドと利用メモ: ソース導入からリアルタイムHTMLレポートまで

1. まずビルド依存を入れる

2. 最新ソースパッケージを取得する

3. ビルドオプションを設定する

4. ビルドしてインストールする

5. バージョンを確認する

6. 端末でそのままレポートを見る

7. 静的な HTML レポートを生成する

8. リアルタイム HTML レポートを生成する

9. ログを追い続ける

10. 特定のリクエストだけを見る

11. 複数ログをまとめて解析する

12. マルチスレッドを使う

13. 増分処理

14. 自分なら最初に流すコマンド

Codex の ~/.codex/skills とプロジェクト/.codex/skills の違い

`~/.codex/skills`

`プロジェクト/.codex/skills`

2. `SKILL.md` の先頭を認識できる形にする