開発ツール on KnightLiブログ

Godot ゲーム開発入門：ノード、シーン、最初の 2D ミニゲームまで

Sun, 17 May 2026 12:37:30 +0800

Godot はオープンソースのゲームエンジンで、2D ゲーム、インディーゲームのプロトタイプ、中規模 3D プロジェクトに向いています。

軽量で起動が速く、ノードとシーンの仕組みが分かりやすいのが特徴です。初心者には Unity より入りやすく、個人開発者にも扱いやすいエンジンです。

まず結論

Godot 入門では、最初から全機能を学ぼうとしないことが大切です。

おすすめの順序は次の通りです。

まず 2D から始める。
ノードとシーンを理解する。
最初は GDScript を使う。
開始、失敗、リスタートがある小さなゲームを作る。
その後でアニメーション、音、UI、ステージ、エクスポートを足す。

小さなゲームを 1 本完成させる方が、断片的なチュートリアルを大量に見るより効果的です。

Godot に向いている人

Godot は、ゲーム開発をゼロから学びたい人、2D インディーゲームを作りたい人、すばやくプロトタイプを作りたい人、大きな商用エンジンの複雑なワークフローを避けたい人に向いています。

大型商用パイプライン、豊富なアセットストア、モバイル広告 SDK、高品質 3D 表現が必要なら Unity や Unreal の方が成熟しています。ただし学習と個人制作には Godot で十分です。

インストールとプロジェクト作成

Godot は公式サイトからダウンロードし、解凍して実行するだけです。

最初のプロジェクトでは、デフォルト renderer、英語名、シンプルなパス、Git 管理をおすすめします。

`1`	`first-godot-game`

エディタでは Scene、FileSystem、Inspector、Script、2D / 3D ビューをまず覚えます。

ノードとシーン

Godot の中心概念はノードとシーンです。

代表的なノード：

Node2D：2D オブジェクトの基礎。
Sprite2D：画像表示。
CollisionShape2D：衝突形状。
CharacterBody2D：操作可能なキャラクター。
Camera2D：2D カメラ。
AudioStreamPlayer：音声再生。
Label：文字表示。

シーンはノードの組み合わせです。プレイヤー、敵、ステージをそれぞれシーンにできます。

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

最初に作るゲーム

最初から RPG、オープンワールド、オンラインゲームを作らない方がよいです。

おすすめは 2D 回避ゲームです。

プレイヤーが上下左右に動く。
敵が画面端から出る。
敵に触れると失敗。
生存時間がスコア。
開始画面、ゲームオーバー、リスタートがある。

これだけで入力、移動、衝突、生成、UI、Timer、音、シーン再読み込みを学べます。

プレイヤー移動

プレイヤーには CharacterBody2D を使います。

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

入力 action：

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

キーコードを直接書かず、action を使うとゲームパッドやキー変更に対応しやすくなります。

衝突と物理

よく使うノード：

CollisionShape2D：衝突範囲。
Area2D：重なり検出。
CharacterBody2D：操作キャラクター。
RigidBody2D：物理で動く物体。
StaticBody2D：壁や地面。

自分で移動を制御するなら CharacterBody2D、接触検出だけなら Area2D が分かりやすいです。

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

敵の生成

シーンは prefab のように実体化できます。

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

Timer と組み合わせれば、一定間隔で敵を生成できます。

UI、スコア、音

UI は Control 系ノードを使います。CanvasLayer、Label、Button、Panel がよく使われます。

スコア例：

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

音は AudioStreamPlayer：

`1`	`$HitSound.play()`

ゲームは機能だけでなく、音、点滅、揺れ、ボタン状態などの反応で気持ちよくなります。

プロジェクト構成

最初から整理しておくと楽です。

res://
├── scenes/
├── scripts/
├── assets/
└── ui/

シーン、スクリプト、画像・音声、UI を分けておきます。

よくある失敗

ノード種類を間違える。
CollisionShape2D を忘れる。
キーを直接書く。
すべてを Main.gd に詰め込む。
最初のゲームを大きくしすぎる。

小さくても完成したゲームの方が、途中で止まった大作より価値があります。

学習順序

エディタ基本操作。
ノードとシーン。
GDScript。
入力 action。
2D 移動。
衝突と Area2D。
Timer と生成。
UI とスコア。
音とアニメーション。
デスクトップまたは Web へのエクスポート。

まとめ

Godot 入門の鍵は、全機能を覚えることではなく、ゲームの組み立て方を理解することです。ノードがシーンを作り、シーンがゲームを作り、スクリプトが動作を与え、シグナルがイベントをつなぎます。

まずは 2D ミニゲームを完成させましょう。移動、衝突、UI、音、リスタートまでできれば、次に TileMap、セーブ、状態機械、3D、Shader、エクスポート最適化へ進めます。

DeepSeek-TUI：DeepSeek V4をターミナル上のコーディングAgentにする

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI は、DeepSeek V4をターミナル開発フローに接続するオープンソースプロジェクトです。単なるチャットの外枠ではありません。Claude CodeやCodex CLIに近い「コマンドラインのコーディングAgent」であり、ファイルを読み、コードを編集し、コマンドを実行し、ツールを呼び出し、TUI上でタスクを継続的に進められます。

すでにエディタとターミナルを行き来している開発者にとって、この種のツールの価値は分かりやすいものです。コードをWebチャットへ何度もコピーする必要がなく、プロジェクト構造を毎回手で説明する必要もありません。タスクを渡せば、現在のワークスペースからコンテキストを読み取り、手順を計画し、変更を実行し、結果をレビュー用に返してくれます。

DeepSeekの利用入口を補う

DeepSeekモデル自体は強い推論能力とコード能力を持っています。ただし、その能力を実際の開発フローに落とし込むには、工程化された外側のレイヤーが必要です。

Webチャットは質問には向いていますが、長時間のプロジェクト編集には向いていません。APIはシステム連携には向いていますが、個人開発者はツール呼び出し、コンテキスト管理、ファイル操作、権限制御を自分で組む必要があります。DeepSeek-TUIが補おうとしているのはこの層です。DeepSeek V4を、ターミナル内で働けるAgentとして包みます。

プロジェクト説明によると、主な機能は次の通りです。

ターミナルTUI;
DeepSeek V4向けの会話とタスク実行;
ツール呼び出しとファイル操作;
1Mコンテキスト対応;
Autoモード;
サブAgent;
サンドボックス実行;
永続タスクキュー。

これらの機能の目的は、モデルの返答をより人間らしくすることではありません。モデルを開発現場に入りやすくすることです。

長いタスクには純粋なCLIよりTUIが向いている

多くのAI CLIツールは、最初はプレーンテキストの対話から始まります。プロンプトを入力し、出力を待ち、コマンドをコピーしたり追加コンテキストを渡したりする方式です。これは単純ですが、タスクが長くなるとすぐ混乱します。

TUIの利点は、会話、ファイル、実行結果、タスク状態をより安定した画面に置けることです。コーディングAgentではこれが重要です。1つのコードタスクは、単なる一問一答ではないからです。多くの場合、次の流れを含みます。

プロジェクト構造を理解する。
関連ファイルを探す。
コードを変更する。
テストやコマンドを実行する。
エラーに基づいて修正を続ける。
変更内容をまとめる。

画面がログの羅列だけだと、ユーザーはAgentが今どこまで進んだのかを判断しにくくなります。TUIは少なくとも、観察し、必要なら引き継ぐための入口を提供します。

Autoモードは境界が明確なタスクに向く

DeepSeek-TUIが言及しているAutoモードは、境界が比較的明確な作業に向いています。たとえば小さなバグ修正、スクリプト追加、設定変更、文書整理、局所的な機能実装です。

こうしたタスクには共通点があります。目標が明確で、確認方法も明確で、影響範囲が制御できます。Agentは自分でファイルを調べ、編集し、コマンドを実行し、結果をユーザー確認に戻せます。

ただし、Autoモードは無制限の権限ではありません。実際のプロジェクトでは、ファイル削除、大規模リファクタリング、データベース移行、デプロイコマンドには明確な確認が必要です。コーディングAgentの効率は自動化から生まれますが、リスクも同じ場所から生まれます。コマンドを実行できるツールほど、サンドボックス、権限境界、人間によるレビューが必要です。

サブAgentの意味はタスク分割にある

サブAgentは新しい概念ではありませんが、コード作業では役に立ちます。

少し複雑なタスクでは、複数の種類の作業が同時に必要になります。コードを読む役、実装を変更する役、テストを確認する役、ドキュメントを整理する役です。従来のマルチAgentシステムが派手に見えるだけで終わりがちなのは、実際のツールやワークスペースを持たず、会話の中で相談しているだけだからです。

サブAgentがファイルシステム、コマンド実行、タスクキューと結びつけば、より現実的なタスク分割の仕組みになります。たとえば、あるサブAgentが依存関係を分析し、別のサブAgentが特定モジュールを変更し、メインAgentが結果を統合する、といった形です。これにより、1つのコンテキストに無関係な情報を詰め込みすぎる問題を減らせます。

もちろん、サブAgentには追加コストもあります。token消費、複雑な状態、追跡しにくい責任境界です。そのため、中程度以上の複雑さを持つタスクに向いており、すべての小さな修正に必要なものではありません。

1Mコンテキストは万能ではないが、プロジェクト理解には役立つ

1Mコンテキストは大げさに聞こえますが、コーディングでは単なる宣伝文句ではありません。

実際のコードベースのコンテキストは細かく分散しています。README、設定ファイル、型定義、テスト、呼び出しチェーン、過去の約束事、エラーログは、どれも1つの修正に影響します。長いコンテキストは、局所だけを見て手を動かす問題を減らし、モデルがより多くのプロジェクト制約を保持する助けになります。

ただし、コンテキストが長いことは判断が正しいことと同義ではありません。コードタスクには依然として検索、選別、検証が必要です。プロジェクト全体をコンテキストに詰め込むことが、関連ファイルを正確に読むことより良いとは限りません。良いコーディングAgentは、長いコンテキストをバッファとして使うべきであり、エンジニアリング判断の代替にすべきではありません。

向いているユーザー

DeepSeek-TUIは次のような人に向いています。

ターミナルでDeepSeekを使ってコード作業をしたい開発者。
ツール呼び出しやファイル操作の枠組みを自分で作りたくない人。
Claude CodeやCodex CLIに慣れており、DeepSeekモデルの入口も試したい人。
Web上のコード断片ではなく、ローカルプロジェクトのコンテキストが必要な人。
AIコーディングの流れをコマンドライン環境に入れたい人。

たまに関数の書き方を聞くだけなら、Webチャットで十分です。モデルに直接プロジェクト変更へ参加してほしいなら、ターミナルAgentの意味が大きくなります。

注意すべきリスク

この種のツールで特に注意すべきことは3つあります。

1つ目は権限です。ツールがファイルを読み書きし、コマンドを実行できるなら、デフォルトでどこにアクセスできるのか、ファイルを削除できるのか、ネットワークに出られるのか、危険なコマンドに確認が必要なのかを把握する必要があります。

2つ目はロールバックです。使う前にGitの作業ツリーをきれいにしておくと、Agentの変更を毎回 git diff で明確に確認できます。未コミットの変更が大量にある状態で、Agentに自動編集させるべきではありません。

3つ目は検証です。Agentがコードを書いたことは、タスク完了を意味しません。テスト、ビルド、lint、人間のreviewは残す必要があります。AIコーディングツールは進行を速めますが、最後のエンジニアリング確認を置き換えるものではありません。

まとめ

DeepSeek-TUIの意味は、また1つチャットクライアントが増えたことではありません。DeepSeek V4を、実際の開発作業に近いターミナル環境へ入れていることです。

開発者にとって、モデル能力は最初の一歩にすぎません。本当に体験を左右するのは、プロジェクトを読めるか、安全にファイルを変更できるか、検証コマンドを実行できるか、長いタスクで状態を保てるか、ユーザーがいつでも引き継げるかです。

DeepSeekを日常的なコード変更、プロジェクト読解、自動化された開発タスクに使いたいなら、DeepSeek-TUIは注目に値します。方向性も明確です。AIコーディングツールは「コードの質問に答える」段階から「プロジェクト実行に参加する」段階へ進んでいます。

Ghostty ドキュメント速読：インストール、設定、日常利用の要点

Fri, 15 May 2026 14:50:11 +0800

Ghostty は新しいターミナルエミュレーターだが、単に「また一つ速いターミナル」が増えたという話ではない。公式ドキュメントによると、Ghostty は速度、機能、ネイティブなデスクトップ体験の三つを同時に満たそうとしている。つまり、GPU アクセラレーションと良好なレンダリング性能を目指しつつ、macOS と Linux ではできるだけ本物のローカルアプリのように振る舞い、すべての操作を独自描画 UI に押し込まない設計を目指している。

iTerm2、Kitty、Alacritty、WezTerm、あるいは OS 標準のターミナルを使っているなら、Ghostty で最も注目すべき点は単一の機能ではない。「すぐ使えること」と「深く設定できること」を同時に備えている点だ。デフォルト設定でもすぐ使える一方、さらに調整したくなったときには、設定ファイル、テーマ、キーバインド、フォント、Shell 統合、ターミナル制御シーケンスまで、公式ドキュメントが一通りの入口を用意している。

まず位置づけを見る

Ghostty の中核的な位置づけは、次の三点にまとめられる。

クロスプラットフォームなターミナルエミュレーターで、現時点では macOS と Linux に重点を置いている。
プラットフォームネイティブ UI を使う。macOS 版は Swift、AppKit、SwiftUI、Linux 版は Zig と GTK4 を使う。
ターミナルの中核は libghostty で、GUI アプリはこの共有コアを中心に構築されている。

この設計は日常体験に影響する。タブ、分割、エラーメッセージ、ウィンドウ状態の復元、システムショートカットなどは、単に「デスクトップアプリらしく見える部品」として作られているのではなく、各 OS の操作習慣にできるだけ近づけられている。macOS と Linux のデフォルトショートカットも、それぞれのプラットフォーム慣習に合わせて分けられている。

インストール：macOS は直接的、Linux はディストリビューション次第

公式のプリビルドバイナリは主に macOS 向けだ。もっとも一般的な方法は .dmg をダウンロードし、開いたあと Ghostty を Applications ディレクトリにドラッグすること。Homebrew ユーザーは、コミュニティが管理する cask も利用できる。

`1`	`brew install --cask ghostty`

Linux はより分散している。Ghostty のドキュメントでは、ディストリビューションごとのパッケージマネージャー、コミュニティバイナリ、ソースビルドが分けて説明されている。Arch、Alpine、Gentoo、NixOS、Snap、Solus、Void などにはそれぞれの経路がある。公式または信頼できるリポジトリがない場合、ドキュメントは第三者バイナリを気軽に入れるより、ソースからビルドする方向を勧めている。

これはサーバーや作業用マシンでは特に重要だ。ターミナルエミュレーターは大量の入出力、クリップボード、リンク、SSH セッション、ローカルファイルパスを扱う。インストール元は保守的に選び、公式 macOS パッケージ、ディストリビューションのリポジトリ、自分で出所を確認できるビルド手順を優先したい。

設定：いきなり大きな dotfiles をコピーしない

Ghostty の設定哲学は「ゼロ設定で使えること」だ。デフォルトフォントには JetBrains Mono が含まれ、Nerd Font もサポートされるため、多くのユーザーは最初に起動した時点で普通に作業できる。ドキュメントでは、主観的ではない設定を変えないと快適でない場合、それはデフォルト動作にすべきではないかと考えることさえ勧めている。

本当にカスタマイズが必要な場合、Ghostty はテキスト設定ファイルを使う。現在の設定ファイル名は config.ghostty で、旧バージョンでは config もサポートされる。代表的なパスは次の通り。

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

macOS では次の場所も読み込まれる。

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

設定構文はとても直接的で、key = value という形だ。

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

実用的な勧めとして、最初から他人の完全な設定をコピーしない方がよい。まず数日そのまま使い、最初はフォント、フォントサイズ、テーマの三つだけを変える。キーバインド、分割、ウィンドウ、Shell 統合で実際に摩擦を感じてから、必要な設定を一つずつ足していく方が安定する。

ドキュメント検索：ローカルでも完全な設定を確認できる

Ghostty には多くの設定項目があり、公式ドキュメントでは Option Reference にまとめられている。Web ページだけでなく、インストール後はローカルからも設定リファレンスを確認できる。

`1`	`ghostty +show-config --default --docs`

このコマンドはデフォルト設定とドキュメントを標準出力に出すため、ページャーにつなぐと検索しやすい。

`1`	`ghostty +show-config --default --docs \| less`

利用可能なフォントを見るには次を使う。

`1`	`ghostty +list-fonts`

内蔵テーマと利用可能なテーマを見るには次を使う。

`1`	`ghostty +list-themes`

デフォルトキーバインドを見るには次を使う。

`1`	`ghostty +list-keybinds --default`

これらのコマンドは、Web 上の断片をコピーするより信頼しやすい。自分が実際にインストールしている Ghostty のバージョンから出力されるからだ。

キーバインド：「アクション」を中心に考える

Ghostty のキーバインド設定形式は次の通り。

`1`	`keybind = trigger=action`

trigger はキー入力のトリガーで、action は Ghostty が実行する動作だ。新しいタブを作る、現在の surface を閉じる、設定を再読み込みする、プロンプトへジャンプする、といったものはすべて action になる。このモデルはわかりやすい。何かのメニュー項目を変更しているのではなく、入力シーケンスを一つの動作に紐づけている。

設定を変更した後は、実行中に再読み込みできる。デフォルトショートカットは次の通り。

Linux：ctrl+shift+,
macOS：cmd+shift+,

ただし、すべての設定が即時反映されるわけではない。新しく作るターミナルにだけ影響するものもあれば、完全な再起動が必要なものもある。「設定を書いたのに変わらない」と感じたら、構文を疑い続ける前に、その項目の説明を確認した方が早い。

テーマとフォント：まず内蔵を使い、その後で微調整する

Ghostty は多数のテーマを同梱しており、システムのライトモード、ダークモードに応じて別テーマへ切り替えることもできる。

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

テーマはカスタムファイルから読み込むこともできる。ドキュメントの注意は明確だ。テーマファイルは本質的には Ghostty の設定ファイルであり、多くの設定項目を指定できるため、信頼できない出所のテーマを安易に使うべきではない。

フォントについては、font-family を複数回指定して fallback フォントを設定できる。多言語環境では便利で、主フォントに英字や記号を担当させ、後続のフォントで中国語、日本語、その他の文字を補える。emoji、太字、斜体、リガチャなどの細部で問題が出たら、Option Reference で対応する項目を確認すればよい。

Shell 統合：SSH ユーザーは特に確認したい

Ghostty は bash、elvish、fish、nushell、zsh 向けに shell integration を自動注入できる。有効にすると、いくつかの体験が自然になる。

新しいターミナルを前のターミナルの作業ディレクトリから開ける。
複雑なプロンプトが resize 時に誤って回り込まず、再描画される。
プロンプトマーカーを使ってコマンド出力の間を移動できる。
プロンプト上で、編集習慣に合ったカーソル挙動が使える。

自動注入したくない場合は、設定で無効にできる。

`1`	`shell-integration = none`

さらに注意したいのは SSH だ。Ghostty は TERM として xterm-ghostty を使うが、多くのリモートホストにはまだ対応する terminfo がない。ドキュメントでは ssh-env と ssh-terminfo という二つの shell integration 機能が用意されており、デフォルトでは無効だが必要に応じて有効化できる。

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

古いサーバー、コンテナ、踏み台、厳格に管理された本番環境へよく接続するなら、これらを有効にする前に公式の Terminfo と Shell Integration ドキュメントを読んでおきたい。ターミナル能力のネゴシエーションは地味だが、問題が起きると色の異常、ショートカットの不具合、全画面プログラムの表示崩れとして現れることがある。

私の試し方

Ghostty が自分に合うかだけを判断したいなら、次の順で試すとよい。

インストール後、設定を書かずに一日そのまま使う。
font-family、font-size、theme だけを調整する。
まず他人のショートカット表を取り込むのではなく、ghostty +list-keybinds --default でデフォルトを確認する。
SSH をよく使うなら、リモートホストの terminfo 互換性を先に確認する。
最後に分割、ウィンドウ、透明度、タイトルバー、背景画像などの見た目やワークフローの好みを調整する。

Ghostty のドキュメントはかなりエンジニアリング寄りで、「宣伝ページ」ではなく「設定リファレンスマニュアル」として読むのに向いている。多くのユーザーにとって、本当の判断基準は単純だ。デフォルト体験がすでに快適か、日常のエディタ、Shell、SSH、tmux、Zellij が安定しているか。このあたりがうまくいくなら、Ghostty は長期的なターミナル候補に入れる価値がある。

参考リンク

Codex vs Claude Code：2 つの Subagent 設計をどう選ぶか

Fri, 08 May 2026 14:14:01 +0800

AI コーディングツールでは Subagent が重要になっています。これは流行りの機能ではなく、単一 Agent が実際の開発タスクを抱え込むと限界に当たりやすいからです。

1 つの Agent がコードを読み、ログを確認し、実装を変更し、テストを実行し、エラーを分析し、結果をまとめると、main context はすぐ汚れます。検索結果、コマンド出力、テストログ、中間推論が混ざり、後の判断が不安定になります。探索、実装、検証、レビューを 1 本の main thread に押し込むため、並行処理もしづらくなります。

Subagent の本質は Agent の負荷を下げることです。main session はすべてを最後まで行うのではなく、目標を決め、タスクを割り当て、結果を受け取り、最終回答へ統合する coordinator になります。Subagent は探索、実装、検証、レビューなど局所的な仕事を処理し、圧縮した結論を返します。

つまり Subagent は「もう 1 人の自分」ではなく、絡み合った開発作業を明確な役割に分ける仕組みです。

共通する土台

成熟した Subagent system には通常、次の要素が必要です。

Context isolation。
Role specialization。
Project/user level configuration。
Tool and permission boundaries。

Context isolation は前提です。実際のリポジトリでは、検索結果、テストログ、コマンド出力など中間情報が大量に出ます。これをすべて main session に入れると main thread が乱れます。Subagent は局所的な過程を先に消化し、判断に必要な signal だけを返します。

Role specialization も重要です。複数 Agent とは同じモデルを複数起動することではありません。探索役は検索、読解、要約に強くあるべきです。実装役はコード変更に集中します。検証役はチェックを実行し、リスクを見つけ、結果を明確に報告します。

Tool と permission の境界は安全性を決めます。Subagent が main session の全能力を自動継承すべきではありません。読み取り専用の explorer に書き込み権限は不要です。verifier が実装を変更する必要もありません。

Codex と Claude Code はこの問題意識を共有しつつ、異なる道を取っています。

Codex：明示的な委任

Codex の Subagent 設計は抑制的です。

現在の main session を中心に、制御された軽量な分業機構を提供します。いつ委任するか、誰に渡すか、いつ結果を受け取るかは明示的な判断です。制御フローは現在のタスクに残ります。

特徴は次の通りです。

main session が明示的に subtask を委任する。
role set は小さく保たれる。
main session は誰が何をしているか把握できる。
結果は main line に戻ってから判断される。
協作境界が透明。

これは手動 orchestration、予測可能性、実行の確定性を重視するチームに向いています。explorer に call chain を調べさせ、worker に限定的な変更を任せ、main session が結果を統合して次のテストを判断できます。

一方で、分割、委任、回収、統合の負荷は main session に残ります。軽量な協作には心地よいですが、長期的で複雑な workflow では重くなることがあります。

Claude Code：Agent を workstations として扱う

Claude Code はより platform 的です。

Agent を、説明可能、選択可能、設定可能、記憶可能、隔離可能、background 実行可能な正式な object として扱います。Subagent は会話中の一時的な helper ではなく、開発システムの workstation に近い存在です。

Agent list、use case、description、tool boundary をモデルに渡し、モデル自身がその turn に適した role を選ぶことができます。これにより委任はより自動化されます。

この方向性を支える要素はいくつかあります。

第一に role system。explorer、planner、general-purpose、verifier などの role が用途説明、tool restriction、default model、runtime condition を持てます。read-only explorer は編集できず、planner は設計に集中し、verifier は検証に集中します。

第二に inheritance と override。Subagent は完全に自由ではありません。main session の大きな境界を継承しつつ、許可された範囲で局所的に振る舞いを調整します。

第三に memory。memory は単に少し覚えることではなく、scope を持ちます。user memory は長期的な好み、project memory はリポジトリ背景、local memory は現在環境の状態です。

第四に background work と worktree isolation。検証 task は background で走り続けることができ、main thread は待ち続けなくて済みます。強い隔離が必要なときは別 worktree で作業できます。

第五に plugin ecosystem。Agent を first-class object と見るなら、配布、インストール、優先順位、override、安全境界を考える必要があります。plugin agent は入れられますが、permission mode、hooks、MCP servers など高リスク領域は制限されるべきです。

これにより Claude Code は単発 session の協作ツールではなく、Agent runtime に近く見えます。

違い

Codex は制御された分業ツールに近いです。

明示的な委任。
軽量な role set。
明確な制御フロー。
現在 session 中心の subtask。
人が orchestration する確定的な作業に向く。

Claude Code は engineering workstation system に近いです。

Agent が正式に model 化される。
role が体系化される。
memory、background、isolation、plugin が runtime に含まれる。
モデルが role 選択に関与できる。
長期 project や platform 的 workflow に向く。

問題は機能数ではありません。Subagent を「自分が明示的に呼ぶ helper」と見るか、「system に長期存在する workstation」と見るかです。

選び方

明示的な制御、軽量な分業、現在 session 内の安全な並行処理を重視するなら Codex 的な設計が合います。コードレビュー、小さな変更、明確な実装 task、人がリズムを握りたい workflow に向きます。

体系化された role、長期 memory、background execution、worktree isolation、plugin extension、より完全な Agent runtime を求めるなら Claude Code 的な設計が合います。

判断する質問は 2 つです。

モデル自身が誰に仕事を任せるか選ぶことを受け入れられるか。
より完全な Agent runtime が必要か。

1 つ目が不安なら明示的委任が向いています。2 つ目が yes なら、platform 的な workstation system が向いています。

使い方の注意

Subagent を「モデルを増やせば強くなる」と考えない方がよいです。

各 role の task boundary を明確にする。
role ごとの tool を制限する。
raw log ではなく結論を返させる。
最終判断は main session に残す。
background task と worktree isolation を可視化する。
plugin agent に安全境界を置く。

Subagent の価値は数ではなく分業品質です。role が明確で context がきれいなほど、main thread の判断は安定します。

まとめ

Codex と Claude Code は同じ問題に向き合っています。単一 Agent は実際の開発作業をすべて背負いにくい。両者とも context isolation、role specialization、permission boundary、local summarization を重視します。

違いは設計の方向です。Codex は抑制的で、明示的委任と main session の制御を重視します。Claude Code は体系的で、Agent を設定、記憶、隔離、background 実行、plugin ecosystem に対応した正式な workstation として扱います。

選択はブランド勝負ではありません。必要なのが制御された協作ツールなのか、完全な Agent runtime なのかで決まります。

9Router：Claude Code、Codex、Cursor を 1 つの AI ルーターにつなぐ

Fri, 08 May 2026 13:41:15 +0800

9Router は AI コーディングツール向けのローカルルーターです。Claude Code、Codex、Cursor、Cline、Copilot、OpenCode、OpenClaw などを 1 つの OpenAI-compatible endpoint に接続し、そこから複数のモデルや provider に転送します。

目的はチャットクライアントを増やすことではありません。AI コーディングツールとモデル provider の間に入り、API 形式の違い、provider の手動切り替え、ツール出力による token 消費、quota 切れ、複数アカウント管理をまとめて扱います。

README によると、9Router は 40 以上の provider と 100 以上のモデルに対応し、RTK Token Saver、自動 fallback、quota 追跡、複数アカウントのローテーション、形式変換、リクエストログを備えています。JavaScript 製で、Node.js、Next.js、React、Tailwind CSS、LowDB を使い、MIT ライセンスです。

何に向いているか

複数の AI コーディングツールと複数のモデル供給元を同時に使う場合に便利です。

Claude Code はサブスクリプションで使う。
Codex や Cursor にカスタム OpenAI endpoint を設定したい。
Cline、Continue、RooCode に OpenAI-compatible API を渡したい。
無料 provider を試用に使う。
GLM、MiniMax、Kimi などを安価なバックアップにする。
高品質モデルを難しいタスクだけに使う。

通常は各ツールに endpoint、API key、モデル名、fallback を個別設定する必要があります。9Router はそれをローカルのルーティング層に集約します。

API:

`1`	`http://localhost:20128/v1`

Dashboard:

`1`	`http://localhost:20128/dashboard`

インストール

ローカル利用なら npm が簡単です。

1
2

npm install -g 9router
9router

ソースから実行する場合：

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

本番起動：

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

npm パッケージは Node.js >=18.0.0 を要求します。VPS や Docker では JWT_SECRET、INITIAL_PASSWORD、DATA_DIR、API_KEY_SECRET を設定してください。

ツールの接続

一般的な設定：

1
2
3

Base URL: http://localhost:20128/v1
API Key: 9Router Dashboard からコピー
Model: 9Router で設定したモデル名または combo 名

Codex CLI:

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

Cline、Continue、RooCode では OpenAI Compatible を選びます。

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

モデル名は接続済み provider によって変わり、cc/、cx/、gh/、glm/、minimax/、kr/、vertex/ などがあります。

RTK Token Saver

AI コーディングでは以下のようなツール出力が token を大きく消費します。

git diff
git status
grep
find
ls
tree
ログ
長いファイル一覧

9Router の RTK Token Saver は、これらをモデルに送る前に圧縮します。プロジェクト説明では、多くのリクエストで 20%-40% の input tokens を節約できるとされています。

ただし、重要なログや完全なファイル内容が必要な場面では、圧縮が回答品質に影響しないか確認してから使うのが安全です。

自動 fallback

モデルを優先順に並べられます。

1
2
3

1. サブスクリプションモデル
2. 安価な API
3. 無料 provider

例：

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

fallback は作業停止を減らしますが、モデルが変わると出力の一貫性も変わります。大規模リファクタリングや移行では固定モデルを使う方が安全です。

無料 provider の注意点

Kiro、OpenCode Free、Vertex などの無料経路は便利ですが、利用条件、地域制限、サードパーティツールでの利用可否、ban や rate limit、期限を必ず確認してください。9Router はルーティングを管理するだけで、上流 provider の規約は変えません。

デプロイ

個人利用なら localhost のみで十分です。VPS や LAN で公開するなら、デフォルトパスワードを変更し、強い JWT_SECRET と API_KEY_SECRET を設定し、Dashboard を公衆インターネットに直接出さず、/v1/* に Bearer API key を要求します。

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

まとめ

9Router は AI コーディングツールのローカル gateway です。Claude Code、Codex、Cursor、Cline などを http://localhost:20128/v1 に集約し、モデル選択、形式変換、token 圧縮、quota 追跡、fallback を処理します。

複数 provider を使う重めの AI コーディングユーザーに向いています。まず 1 つのツールと 1 つの provider から試し、徐々に combo とアカウントを増やすのが無難です。

参考資料

goose：デスクトップ、CLI、API を備えたオープンソース AI Agent

Fri, 08 May 2026 13:41:15 +0800

goose はローカルマシン上で動くオープンソース AI Agent です。コード補完だけでなく、コード、調査、執筆、自動化、データ分析など広いタスクを対象にしています。README ではデスクトップアプリ、CLI、API を提供する Agent として説明されています。

このプロジェクトは block/goose から Linux Foundation の Agentic AI Foundation（AAIF）へ移りました。現在のリポジトリは次の通りです。

`1`	`https://github.com/aaif-goose/goose`

goose は主に Rust と TypeScript で書かれ、Apache-2.0 ライセンスです。GitHub の説明では、コード提案を超えて、install、execute、edit、test を任意の LLM で行える拡張可能な AI agent とされています。

解決する問題

多くの AI コーディングツールは提案や局所的なコード編集に寄っています。goose はより広く、AI agent がローカルマシンでタスクを実行することを目指します。

コード変更とテスト。
ローカル自動化。
調査と執筆。
データ分析。
複数ステップの workflow。
API 経由の埋め込み。
MCP による拡張。

IDE 補完だけなら Copilot 系ツールで十分です。goose は AI をローカルのタスク実行チェーンに入れたい場合に向いています。

3 つの入口

デスクトップアプリは macOS、Linux、Windows に対応し、視覚的に使いたい人に向いています。

CLI はターミナル中心の開発者に向いています。

API は他のシステムや社内ツールに agent runtime として組み込むためのものです。

個人利用ならデスクトップか CLI から始め、チームや自動化基盤では API と custom distribution も検討します。

インストール

デスクトップ版：

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI：

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases には複数プラットフォームのビルドがあります。確認時点の latest release は v1.33.1 で、2026-04-29 に公開され、macOS、Linux、Windows、deb、rpm、Flatpak などの asset が含まれます。

インストール後は公式 Quickstart に従って provider を設定し、まず低リスクなディレクトリで試します。

Provider

goose は Anthropic、OpenAI、Google、Ollama、OpenRouter、Azure、Bedrock など 15 以上の provider に対応します。

API key を使うことも、ACP 経由で既存の Claude、ChatGPT、Gemini サブスクリプションを使うこともできます。

ACP は、既存のサブスクリプションを agent workflow に持ち込める点で重要です。ただし provider の規約、quota、会社コードや機密データでの利用可否は必ず確認してください。

MCP extension

goose は Model Context Protocol extension に対応し、README では 70 以上の extensions に接続できるとされています。

MCP により、agent はチャットやファイル編集だけでなく、ドキュメント、データベース、ブラウザ、社内システム、検索サービス、設計ツール、プロジェクト管理ツールなどと標準プロトコルで接続できます。

チームでは、内部機能を明確な interface として公開する安全な統合層にもなります。

コーディング助手との違い

goose はコード補完ツールというよりローカル agent runtime です。

一般的な助手は補完、説明、関数生成、エディタ内の局所編集に寄ります。goose はローカルタスク実行、複数ステップ workflow、provider 切り替え、extension、デスクトップと CLI、埋め込み API、非コードタスクも重視します。

その分、モデル設定、権限、extension、workspace、ログ、credential 管理を考える必要があります。

Custom distribution

CUSTOM_DISTROS.md では、provider、extension、branding を事前設定した goose distro を作る方法が説明されています。

チームは、許可された provider、社内 MCP server、安全ポリシー、ログ設定、禁止サービス、ブランドやオンボーディングを組み込んだ内部版を作れます。

使い方の勧め

デスクトップ版または CLI を入れる。
1 つの provider を設定する。
テストディレクトリで簡単なタスクを実行する。
読み取るファイルと実行する動作を見る。
MCP extension を追加する。
複雑なリポジトリや自動化 workflow は後で試す。

重要な変更前は git commit し、API key をプロジェクトに書かず、高権限モードは信頼できる workspace に限定します。会社コードではデータ規約と provider ポリシーを確認してください。

まとめ

goose は AAIF/Linux Foundation 傘下のオープンソース AI Agent で、デスクトップ、CLI、API、15 以上の provider、ACP サブスクリプション連携、70 以上の MCP extensions に対応します。

価値はコードを書くことだけではなく、モデル、ツール、extension、ローカル実行環境を 1 つの agent framework にまとめる点にあります。

参考資料

VS Code の表示言語を切り替える方法：中国語、英語、その他の言語

Fri, 08 May 2026 13:18:57 +0800

VS Code は多くの表示言語に対応しています。一般的には、対象の言語パックを先にインストールし、その後コマンドパレットから表示言語を選択します。特定の言語に固定したい場合は、argv.json の locale を手動で変更することもできます。

この方法は簡体字中国語だけでなく、英語、繁体字中国語、日本語、韓国語、フランス語、ドイツ語、スペイン語などにも使えます。

対応する言語パックをインストールする

英語以外のインターフェイスに切り替える場合は、通常、先に言語パックをインストールします。

VS Code 左側の拡張機能パネルを開きます。ショートカット Ctrl+Shift+X も使えます。
検索ボックスに対象言語を入力します。例：Chinese、Japanese、Korean、French。
対応する言語パックを選び、Install をクリックします。
インストール完了後、案内に従って VS Code を再起動します。

簡体字中国語では Chinese (Simplified)、繁体字中国語では Chinese (Traditional) がよく使われます。

コマンドパレットから言語を切り替える

ほとんどのユーザーには、この方法がおすすめです。

コマンドパレットを開きます：Ctrl+Shift+P。
Configure Display Language と入力します。
Configure Display Language コマンドを選択します。
一覧から使用したい言語を選びます。
案内に従って VS Code を再起動します。

再起動後、メニュー、設定画面、一般的なメッセージが選択した言語に切り替わります。対象言語が一覧にない場合は、先に拡張機能パネルから対応する言語パックをインストールしてください。

argv.json で言語を手動指定する

コマンドパレットで切り替えられない場合や、表示言語を明示的に固定したい場合は、VS Code のランタイム引数ファイルを直接編集できます。

コマンドパレットを開きます：Ctrl+Shift+P。
Preferences: Configure Runtime Arguments と入力して選択します。
locale 設定を探すか追加します。
値を対象の言語コードに変更します。
保存して VS Code を再起動します。

英語に切り替える例：

1
2
3

{
  "locale": "en"
}

簡体字中国語に切り替える例：

1
2
3

{
  "locale": "zh-cn"
}

日本語に切り替える例：

1
2
3

{
  "locale": "ja"
}

argv.json は JSON ファイルなので、カンマと引用符に注意してください。設定が間違っていると、VS Code が言語設定を正しく読み取れないことがあります。

よく使う表示言語コード

表示言語	locale
English (US)	`en`
簡体字中国語	`zh-cn`
繁体字中国語	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

言語が反映されない場合

次の順番で確認してください。

対象の言語パックがインストール済みか確認します。
locale に正しい言語コードを書いているか確認します。たとえば簡体字中国語は zh-cn で、zh-CN ではありません。
言語を変更した後、VS Code を完全に終了してから再度開きます。
argv.json を手動で編集した場合は、JSON 構文が正しいか確認します。
設定が混乱している場合は、locale 項目を削除してから Configure Display Language で選び直します。

通常は Configure Display Language で切り替えるのが最も簡単です。特定の言語を強制したい場合や、コマンドパレットでの切り替えが反映されない場合だけ、argv.json の手動編集を検討するとよいでしょう。

参考資料

VScode：VS Code の表示言語を簡体字中国語に変更し、表示言語を切り替える

Claude Code 24の使い方：計画モード、巻き戻し、CLAUDE.md、Skills、Agents、プラグイン

Fri, 08 May 2026 08:54:14 +0800

Claude Code は単なるチャット欄ではない。プロジェクトディレクトリに入り、ファイルを読み書きし、コマンドを実行し、コンテキストを維持できるコーディング Agent に近い。

要求を投げてコード生成を待つだけだと、計画が曖昧、権限確認が多い、コンテキストが長くなる、結果が気に入らない、戻し方が分からない、プロジェクトルールを残せない、といった問題にすぐ当たる。

ここでは、Claude Code を使い始める開発者向けに、よく使う操作を整理する。

まずプロジェクトディレクトリで起動する

Claude Code は、適当な場所で開くより、プロジェクトディレクトリ内で起動するほうがよい。

まずプロジェクト用フォルダを作り、その中でコマンドラインを開いて Claude Code を起動する。

claude

初回に現在のフォルダを信頼するか聞かれたら、確認してから進める。これで Claude Code は現在のプロジェクトを基準にファイルを読み、作成し、コマンドを実行できる。

練習には、写真家のポートフォリオサイトを作らせるようなタスクが向いている。見た目を確認でき、ファイル生成、コマンド実行、巻き戻し、リファクタリングを一通り試せる。

計画モードで方向を先に決める

Claude Code は複雑なタスクでは計画モードに入ることがある。計画モードでは、先に要件を話し合い、手順を分解してから、実行を承認する。

計画が出た後は、よく次のような選択肢が出る。

計画を承認し、以後の編集ツール使用も自動承認する。
計画を承認するが、以後の編集は手動確認する。
実行を止め、計画についてさらに Claude Code と話す。

タスクが明確なら承認して進める。まだ曖昧なら、ページの雰囲気、技術スタック、ディレクトリ構成、インタラクション、受け入れ条件をさらに詰める。

計画モードの利点は手戻りを減らすことだ。いきなり Agent に作業させると多くのファイルが作られるが、方向が間違っていると後で修正が荒れやすい。

Shift + Tab でモードを切り替える

Claude Code では Shift + Tab で作業モードを切り替えられる。よく使うのは、計画モードへの切り替えや、編集ツールの自動承認モードへの切り替えだ。

おすすめの使い分け：

新規プロジェクト、新機能、大きな変更：まず計画モード。
小さな修正、明確なバグ修正：直接実行。
削除、置換、依存関係のインストール：手動確認を残す。

計画モードでは、Claude Code がプロジェクト詳細を質問することがある。方向キーで選び、Enter で確定する。フィードバックを送ると、それに合わせて計画が更新される。

権限確認をすべて開放しない

Claude Code がコマンド実行、ファイル編集、プログラム起動を行うとき、権限を求めることがある。

よくある選択肢：

今回だけ許可。
現在の会話内で同種コマンドを許可。
拒否または一時停止。

ローカルページの起動、開発サーバーの実行、ファイル確認なら必要に応じて許可してよい。ただし、クリックを減らすために「すべて自動許可」で長く使うのは避ける。

完全自動の権限は、リスクが低く、内容を理解しており、Git バックアップがある場合だけに向く。日常利用では、削除、上書き、依存関係インストール、ネットワーク、コミット、スクリプト実行には人間の確認を残す。

ターミナルモードでローカルコマンドを実行する

Claude Code ではターミナルコマンドモードに入り、ローカルコマンドを実行できる。

ページ生成後、HTML ファイルを開く例：

`1`	`start index.html`

start は Windows でファイルを開くコマンドで、後ろにファイル名を付ける。エクスプローラーで探すより速い。

ターミナルモードに向く操作：

生成ページを開く。
ディレクトリを確認する。
開発サーバーを起動する。
テストやビルドを実行する。

一方、再帰削除、ディレクトリ移動、一括上書き、システム環境変更のような高リスク操作には注意する。

結果が違うときは早めに巻き戻す

Claude Code が作ったページやコードが期待と違い、修正するほど乱れていくなら、早めに巻き戻す。

巻き戻しでは、会話やコードを特定の時点へ戻せる。よくある選択肢：

コードと会話を同時に戻す。
会話だけ戻す。
コードだけ戻す。
以前の内容を要約に圧縮する。
キャンセルする。

明らかに方向がずれた場合は、コードと会話を同時に戻すのがおすすめだ。コンテキストとファイル状態を一緒にきれいな位置へ戻せる。

ただし、Claude Code の巻き戻しは通常、内蔵ツールで作成・変更したファイルが対象だ。外部コマンドで作ったファイルは完全には戻らないことがある。重要なプロジェクトでは Git と併用する。

長いプロンプトはエディタで書く

複雑な要件を1行の入力欄に詰め込まない。

長いプロンプトをテキストエディタで編集できる場合は、エディタで要件を書き、保存してから送る。

長いプロンプトには次を書くとよい。

目的。
使用する技術スタック。
してはいけないこと。
残すべきファイル。
完了後の確認方法。
ページや機能の受け入れ条件。

例えば普通の HTML ページを現代的な技術スタックへリファクタリングしたい場合、「リファクタリングして」だけでは足りない。コンポーネント化、見た目の維持、レスポンシブ対応、ビルド確認まで明記する。

終了後は履歴から会話を復元する

途中で Claude Code を終了する必要がある場合は、通常通り終了する。その後、同じプロジェクトディレクトリに戻って再起動する。

claude

以前の記録が直接出ない場合は、履歴関連コマンドで最近の会話を見て、以前の会話を読み込む。

これは中断後の継続に便利だ。ただし会話履歴だけを記憶として頼らない。プロジェクトルール、技術スタック、よく使うコマンド、注意点はプロジェクトファイルに書く。

CLAUDE.md にプロジェクトルールを保存する

CLAUDE.md は Claude Code にとって重要な記憶ファイルだ。通常はプロジェクトルートに置き、プロジェクトルール、技術スタック、ディレクトリ構造、協業上の制約を書く。

初期化は次で行える。

/init

CLAUDE.md に向いている内容：

プロジェクト目標。
技術スタック。
起動、テスト、ビルドのコマンド。
ディレクトリ説明。
コードスタイル。
禁止操作。
コミットとデプロイルール。

各会話で、Claude Code はこの種のルールをコンテキストの一部として利用できる。プロジェクト説明書と考えると分かりやすい。

簡単な検証方法は、CLAUDE.md に明確なルールを追加してから質問することだ。回答がそのルールに従えば、プロジェクト記憶を読んでいる。

@ でファイルを参照する

入力欄で @ を使うと、ファイルや Agent を選び、現在の会話コンテキストに追加できる。

向いている場面：

設定ファイルを読ませる。
特定ページを修正させる。
CLAUDE.md や他の文書に基づいて続けさせる。
「このファイルだけ見て、構造を推測しない」と明示する。

ファイル内容を入力欄に貼るより、@ 参照のほうが明確で漏れにくい。

コンテキストを確認・圧縮する

長時間会話すると、コンテキストは大きくなる。長すぎるとモデルが遅くなったり、初期の細部を無視し始めたりする。

現在の使用状況は次で確認できる。

`1`	`/context`

長くなったら履歴を圧縮する。

`1`	`/compact`

それでも効果が悪い場合は、現在のコンテキストを消す。

/clear

消した後も、Claude Code はプロジェクトファイル、CLAUDE.md、現在のディレクトリから一部を再理解できる。ただし完全な会話履歴は残らない。

実用的には、1つのタスクが終わったら新しい会話にし、プロジェクトルールは CLAUDE.md に書き、臨時の議論を1つのチャットに積み続けない。

Skills：固定フローを説明書にする

Skills は Claude Code の作業説明書と考えられる。一度きりのプロンプトではなく、再利用できるタスクフローだ。

例えば週報をよく作るなら、週報 Skill を作り、次を明記する。

必要な入力。
出力形式。
口調と構成。
必ず残す内容。
捏造してはいけない内容。

Skills は通常、name、description、具体的な指示で構成される。グローバル Skills ディレクトリに入れると、Claude Code は関連タスクで認識して読み込める。

向いている作業：

週報。
コードレビューのテンプレート。
文書整理。
画像の一括処理。
固定形式の記事。
プロジェクト初期化フロー。

同じプロンプトを何度もコピーしているなら、Skill 化を検討するとよい。

Agents：サブタスクを独立した助手へ渡す

Agents は Skills と違う。

Skill は説明書に近く、Claude Code にやり方を教える。Agent は独立した助手に近く、主会話の外で作業し、結果を返す。

Agents の価値はコンテキストの隔離だ。コード点検なら、読み取り専用 Agent を作り、プロジェクトを読むだけでレポートを出させる。ファイルを直接変更しないので、主会話を汚さず、誤操作も減らせる。

Agent 作成時に考えること：

プロジェクト級かユーザー級か。
Claude Code に設定を生成させるか。
どのツール権限を許すか。
どのモデルを使うか。
記憶を保存するか。
Agent のプロンプトが十分明確か。

コード点検 Agent には、まず読み取り権限だけを与えるのがおすすめだ。先にレポートを出させ、その後で主会話が修正するか判断する。

プラグイン：Skills、Agents、MCP、Hooks をまとめる

プラグインは、より完全な能力パッケージだ。中には次が含まれることがある。

Skills
Agents
MCP
Hooks

単体の Skill より、プラグインはまとまった能力に向いている。例えばフロントエンドデザイン用プラグインなら、見た目のルール、レイアウト、コンポーネント習慣、関連 Agent をまとめて持てる。

インストール時には、よく次の場所を選べる。

ユーザーディレクトリ：全プロジェクトで有効。
プロジェクトディレクトリ：プロジェクトと共有。
ローカルプロジェクトディレクトリ：現在の PC だけで有効。

個人で常用する能力はユーザーディレクトリ、チームの約束はプロジェクトディレクトリ、一時テストはローカルに置くとよい。

プラグインは特定タスクの品質を上げる

フロントエンドページ生成では、プラグインは素のプロンプトより安定しやすい。

同じ「写真家の個人サイトを作る」でも、普通のプロンプトだけなら見られるページができる程度かもしれない。フロントエンドデザインプラグインを明示すると、構造、視覚階層、余白、配色、完成度が良くなりやすい。

もちろんプラグインは人間の審美眼を置き換えない。より良い初稿を作らせ、人間が細部を調整するのが現実的だ。

より安定した Claude Code ワークフロー

これらを組み合わせると、安定した流れになる。

プロジェクトディレクトリで claude を起動する。
まず計画モードで要件を話す。
承認前に技術スタックと受け入れ条件を確認する。
高リスク操作は手動確認を残す。
ターミナルモードでプレビューとテストを行う。
方向がずれたら早めに巻き戻す。
プロジェクトルールを CLAUDE.md に書く。
長い会話では定期的にコンテキストを確認・圧縮する。
繰り返す作業は Skills にする。
点検、調査、分析は読み取り専用 Agents に渡す。
特定分野のタスクはプラグインを優先する。
重要プロジェクトでは常に Git のチェックポイントを作る。

こう使うほうが、「一文送って生成を待つ」よりはるかに安定する。

まとめ

Claude Code の効率はモデル能力だけでなく、ワークフロー制御からも生まれる。

計画モードは方向を決め、権限確認はリスクを抑え、巻き戻しは手戻りを減らす。CLAUDE.md はプロジェクトルールを保存し、/context、/compact、/clear はコンテキストを管理する。Skills は固定フローを再利用し、Agents は複雑なサブタスクを隔離し、プラグインはまとまった能力をプロジェクトへ持ち込む。

Claude Code をうまく使うには、明確な境界の中で継続的に作業させることが大事だ。プロジェクト全体を一度に丸投げするのではない。

opencode、Claude Code、Codex の違いとは？オープンソース AI コーディングツールガイド

Fri, 08 May 2026 08:33:37 +0800

opencode は anomalyco が公開しているオープンソースの AI Coding Agent だ。位置づけは明確で、開発者がターミナル内で、プログラム可能で拡張しやすく、複数のモデル提供元に接続できるコードアシスタントを使えるようにする。

Claude Code や Codex と並べて見ると、3つはいずれも同じ種類の問題を解こうとしている。AI を実際のコードベースに入れ、コンテキストを理解し、ファイルを変更し、コマンドやテストを実行できるようにすることだ。ただし、製品としての向きは異なる。

opencode はオープンソース、複数モデル対応、ターミナル TUI を重視する。Claude Code は Anthropic のモデルエコシステムとローカルでの開発協業を重視する。Codex は OpenAI の AI coding agent であり、ターミナル、IDE、Codex app、クラウドタスクから利用できる。

opencode が向いている人

opencode は次のような開発者に向いている。

ターミナル内でコード変更、プロジェクト分析、エンジニアリングタスクを進めたい人。
AI Coding Agent を単一のモデル提供元に縛られたくない人。
オープンソースツールを好み、自分で監査、拡張、二次開発したい人。
Neovim、TUI、コマンドラインワークフローに慣れている人。
将来的にデスクトップ、モバイル、その他のクライアントから同じコーディングエージェントをリモート操作したい人。

重要なのは、単なるチャットウィンドウを作ることではない。開発者が普段使っているターミナルとプロジェクトディレクトリの中に、AI コーディング能力を入れることだ。

インストール方法

公式 README には複数のインストール方法が用意されている。

# 直接インストール
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS と Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# その他
mise use -g opencode
nix run nixpkgs#opencode

公式 README では、古いバージョンの残存による問題を避けるため、インストール前に 0.1.x より前のバージョンを削除することも推奨している。

インストールスクリプトは次の優先順位でインストール先を選ぶ。

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

パスを指定したい場合は、次のように書ける。

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

デスクトップアプリはまだ Beta

コマンドラインツールに加えて、opencode はデスクトップアプリも提供している。ただし現在は Beta 扱いだ。GitHub Releases または opencode.ai/download からダウンロードできる。

デスクトップ版は次のプラットフォームに対応している。

プラットフォーム	ファイル
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` または `.AppImage`

macOS と Windows では、パッケージマネージャーからデスクトップ版をインストールすることもできる。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

2つの内蔵 Agent モード

opencode には2つの内蔵 Agent があり、Tab キーで切り替えられる。

build はデフォルトモードで、完全な開発権限を持つ。コードを直接変更し、コマンドを実行し、エンジニアリングタスクを進める用途に向いている。

plan は読み取り専用モードだ。未知のコードベースを分析し、プロジェクト構造を理解し、変更方針を立てる用途に向いている。デフォルトではファイル編集を拒否し、bash コマンドを実行する前に確認する。

さらに、opencode には複雑な検索や多段階タスクのための general サブ Agent もある。ユーザーはメッセージ内で @general と入力して呼び出せる。

この設計は実用的だ。実際に手を動かす前に plan でプロジェクトを把握し、コードを変更する必要が出たら build に切り替える。大規模リポジトリでは、読み取り権限と書き込み権限を分けることで誤操作を減らせる。

Codex とは

Codex は OpenAI の AI coding agent で、開発者がコードを書き、コードレビューを行い、bug を修正し、エンジニアリングタスクを出荷するのを支援する。

単なるコード補完ツールとは異なり、Codex はコードベースを操作できる Agent に近い。ローカルツール内で開発者とペアになって作業することも、クラウドにタスクを委任することもできる。OpenAI の公式資料では、Codex は CLI、IDE、Codex app、ChatGPT/Codex クラウドなど複数の入口から利用できると説明されている。

開発者にとって、Codex のポイントは次の通りだ。

コードベースを読み、ファイルを編集し、コマンドとテストを実行できる。
ターミナル、IDE、アプリ、クラウドなど複数のインターフェースに対応する。
bug 修正、機能開発、リファクタリング、移行、コードレビュー、テスト補完に向いている。
OpenAI アカウント、モデル、Codex 製品体系との結びつきが強い。
クラウドタスクは、比較的明確な複数のエンジニアリングタスクを並行処理するのに向いている。

opencode が開かれたターミナルエージェントフレームワークに近いとすれば、Codex は OpenAI が提供する一式の AI コーディングワークベンチに近い。ローカルでペア作業でき、クラウドに委任でき、チームはそれをより長いエンジニアリングフローへ組み込める。

3つの主な違い

opencode、Claude Code、Codex はいずれも AI コーディングツールだが、選ぶときはまず次の観点を見るとよい。

ツール	中心的な位置づけ	主な強み	向いている用途
`opencode`	オープンソース AI Coding Agent	オープンソース、複数モデル、TUI、クライアント/サーバー構成	開かれたツールチェーン、交換可能なモデル、ターミナル中心のワークフローを求める開発者
`Claude Code`	Anthropic のコマンドライン型コーディングツール	Claude モデル体験、コード理解、長いコンテキスト、エンジニアリングタスク協業	Claude/Anthropic エコシステムを使っていて、ローカルでコードタスクを進めたい開発者
`Codex`	OpenAI の AI coding agent	CLI、IDE、Codex app、クラウドタスク、複数 Agent ワークフロー	ChatGPT/OpenAI を使っていて、ローカルでのペア作業とクラウド委任を併用したいチーム

簡単に言えば、opencode のキーワードは「オープン」と「交換可能」、Claude Code のキーワードは「Claude エコシステム」と「ローカル開発エージェント」、Codex のキーワードは「OpenAI エコシステム」と「複数入口の協業」だ。

Claude Code との違い

opencode の公式 FAQ は Claude Code と直接比較している。両者の能力はかなり近いが、主な違いは次の通りだ。

第一に、opencode は 100% オープンソースプロジェクトで、コードは GitHub にホストされ、MIT license で提供されている。

第二に、opencode は単一のモデル提供元に縛られない。OpenCode Zen が提供するモデルを推奨しているが、Claude、OpenAI、Google、またはローカルモデルとも組み合わせられる。開発者にとっては、モデルのコスト、能力、可用性が変わっても、特定のプラットフォームにロックインされにくいという意味がある。

第三に、opencode は任意の LSP サポートを内蔵している。コード補完、ジャンプ、診断、プロジェクト理解にとって、LSP は非常に重要な基盤だ。

第四に、opencode は TUI を重視している。Neovim ユーザーと terminal.shop の作成者によって作られており、製品の重心は明らかにターミナル体験にある。

第五に、opencode はクライアント/サーバー構成を採用している。つまり、opencode を自分のコンピューター上で動かし、将来的に TUI、デスクトップ、モバイル、その他のクライアントから制御できる。TUI はそのうちの一つのフロントエンドにすぎない。

opencode、Claude Code、Codex をいつ選ぶか

すでに Claude Code や Codex を使っている場合、opencode がすぐにそれらを置き換える必要はない。より自然な見方は、opencode がオープンで、モデルを交換でき、ターミナル寄りの選択肢を提供しているというものだ。

opencode を優先して検討したい場面は次の通り。

AI コーディングツールをできるだけオープンソースにしたい。
ワークフローを特定のモデル提供元に縛られたくない。
同じツールで Claude、OpenAI、Google、またはローカルモデルを試したい。
TUI が好きで、主要な作業フローをデスクトップアプリやWebアプリに中断されたくない。
クライアント/サーバー構成によるリモート制御能力に関心がある。

Claude Code を優先して検討したい場面は次の通り。

主に Claude モデルを使っている。
長いコンテキスト、コード理解、複雑なエンジニアリングタスク協業を重視している。
ローカルリポジトリ内で変更、テスト、リファクタリングを継続的に進めたい。
Anthropic による Claude Code のデフォルト製品体験を信頼している。

Codex を優先して検討したい場面は次の通り。

すでに ChatGPT または OpenAI アカウント体系を使っている。
同じ coding agent をターミナル、IDE、デスクトップアプリ、クラウドタスクで使いたい。
明確な bug 修正、機能開発、移行、テスト補完をクラウドに委任して並行処理したい。
コードレビュー、バックグラウンドタスク、チーム協業、複数 Agent ワークフローが必要だ。

公式の一体化された体験、デフォルトのモデル設定、企業管理、既製の統合を重視するなら、Claude Code や Codex のほうが楽な場合がある。制御性、オープン性、provider-agnostic を重視するなら、opencode は注目に値する。

注意点

opencode、Claude Code、Codex はいずれも変化が速い。GitHub release、インストールコマンド、デスクトップ版のファイル名、モデルの可用性、プラン権限は変わる可能性がある。インストールや選定の前には、それぞれの公式 README、ドキュメント、リリースページを直接確認するのがよい。

また、opencode のデスクトップアプリはまだ Beta と表示されており、安定した本番用ツールとして最初から扱うべきではない。日常的なエンジニアリングタスクでは、ターミナル版が引き続き主な入口になる。

ツールの流れとして見ると、opencode は AI Coding Agent のオープンツールチェーン方向を代表している。モデルを交換でき、クライアントも交換でき、コアの代理能力をできるだけ開く方向だ。一方、Codex と Claude Code は、モデル企業が coding agent を完成度の高い製品入口として作る方向に近い。開発者にとって、この2つの流れは長く併存するだろう。

参考リンク

opencode GitHub：https://github.com/anomalyco/opencode
opencode 公式サイト：https://opencode.ai
opencode ドキュメント：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

uv インストールガイド：macOS、Linux、Windows、pipx、Homebrew、WinGet の選び方

Thu, 07 May 2026 23:23:58 +0800

uv は Astral が提供する Python ツールチェーンマネージャーです。Python バージョン、仮想環境、依存関係、スクリプト、プロジェクト、ツールを管理できます。インストール方法は多く、公式ドキュメントではスタンドアロンインストーラーのほか、PyPI、Homebrew、WinGet、Scoop、Docker、GitHub Releases、Cargo が案内されています。

すばやく入れたいだけなら、まず公式のスタンドアロンインストーラーを使うのがおすすめです。システムのパッケージマネージャーでバージョンを管理したいなら Homebrew、WinGet、Scoop を選びます。Python ツールを隔離環境に入れる運用に慣れているなら pipx が向いています。

すばやく選ぶ

シーン	推奨方法	コマンド
macOS / Linux で素早くインストール	公式スタンドアロンインストーラー	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux に curl がない	公式スクリプト + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Windows で素早くインストール	PowerShell インストーラー	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Python ツールを隔離して入れる	pipx	`pipx install uv`
一時的または従来型の Python インストール	pip	`pip install uv`
macOS のパッケージ管理	Homebrew	`brew install uv`
macOS の MacPorts ユーザー	MacPorts	`sudo port install uv`
Windows のパッケージ管理	WinGet	`winget install --id=astral-sh.uv -e`
Windows の Scoop ユーザー	Scoop	`scoop install main/uv`
Rust ユーザー	Cargo	`cargo install --locked uv`

汎用的におすすめしやすい選択肢は次の通りです。

macOS / Linux：公式スタンドアロンインストーラー；
Windows：公式 PowerShell インストーラー、または WinGet；
pipx で Python CLI ツールを管理している場合：pipx install uv。

macOS と Linux：公式インストーラー

公式でもっとも直接的な方法は、curl でスクリプトを取得して sh に渡す方法です。

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

システムに curl がない場合は wget を使えます。

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

特定バージョンをインストールしたい場合は、URL にバージョン番号を含めます。たとえば公式例の 0.11.11 は次のようになります。

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

この方法は、ほとんどの個人開発環境に向いています。シンプルでクロスプラットフォームであり、uv 公式の更新機構とも相性が良いからです。

インストーラーは uv、uvx などのバイナリをユーザーディレクトリ配下に配置し、コマンドをターミナルから直接使えるように shell profile を変更する場合があります。PATH を変更されたくない場合は、公式 installer オプションを確認し、たとえば UV_NO_MODIFY_PATH=1 を設定します。

Windows：PowerShell インストーラー

Windows の公式インストール方法は、PowerShell でインストーラースクリプトを実行する方法です。

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

特定バージョンをインストールする場合も、URL にバージョン番号を含めます。

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

ここでの ExecutionPolicy ByPass は、インターネットから取得したインストーラースクリプトを実行できるようにするための指定です。安全のため、実行前にスクリプト内容を確認することもできます。

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

Windows のパッケージマネージャーに慣れているなら、WinGet や Scoop を優先してもよいでしょう。

pipx でインストールする

公式ドキュメントでは、uv が PyPI に公開されていることも説明されています。PyPI からインストールする場合は、pipx などで隔離環境に入れることが推奨されます。

`1`	`pipx install uv`

この方法は、pipx を Python CLI ツールマネージャーとして使っている人に向いています。uv を現在のプロジェクト環境と混ぜずに済みます。

pipx がない場合は、pip を直接使うこともできます。

`1`	`pip install uv`

ただし、uv は多くのプラットフォーム向けに事前ビルド済み wheel を提供していますが、対象 platform の wheel がない場合はソースからビルドされます。その場合は Rust ツールチェーンが必要です。

私のおすすめは、個人マシンでは pip install uv より pipx install uv のほうがきれい、というものです。プロジェクト環境の中では、uv をプロジェクト依存関係として入れないほうがよいでしょう。

Homebrew、MacPorts、WinGet、Scoop

システムのパッケージマネージャーを好む場合、uv は一般的な配布経路にも対応しています。

macOS では Homebrew を使えます。

`1`	`brew install uv`

MacPorts ユーザーは次のコマンドです。

`1`	`sudo port install uv`

Windows では WinGet を使えます。

`1`	`winget install --id=astral-sh.uv -e`

Scoop ユーザーは次の通りです。

`1`	`scoop install main/uv`

これらの方法の利点は、システムのパッケージマネージャーに一元管理できることです。欠点は、更新タイミングが uv 公式インストーラーではなく、各パッケージソースに依存することです。

Docker、GitHub Releases、Cargo

uv は GitHub Container Registry で Docker イメージも提供しています。

`1`	`ghcr.io/astral-sh/uv`

これは CI、Dockerfile、イメージビルド、一時的な実行環境に向いています。実際に使う場合は、公式の Docker 統合ドキュメントも確認するのがおすすめです。

バイナリを手動でダウンロードしたい場合は、GitHub Releases を使えます。各 release ページには通常、対応プラットフォーム向けのバイナリが含まれ、GitHub URL を使ってスタンドアロンインストーラーを呼び出す方法も説明されています。

Rust ユーザーは crates.io からもインストールできます。

`1`	`cargo install --locked uv`

ただし、この方法はソースからビルドするため、互換性のある Rust ツールチェーンが必要です。Rust エコシステムからインストールする明確な理由がない限り、一般ユーザーが Cargo を優先する必要はありません。

uv をアップグレードする

uv を公式スタンドアロンインストーラーで入れた場合は、自己更新コマンドを使えます。

`1`	`uv self update`

公式ドキュメントでは、uv の更新時にインストーラーが再実行され、shell profile が変更される可能性があると説明されています。更新時に PATH を変更されたくない場合は、次を設定します。

`1`	`UV_NO_MODIFY_PATH=1`

別の方法でインストールした場合は、その方法に対応するパッケージマネージャーでアップグレードします。たとえば pip で入れた場合は次の通りです。

`1`	`pip install --upgrade uv`

Homebrew、WinGet、Scoop、MacPorts も、それぞれのアップグレードコマンドを使います。

shell 補完を有効にする

uv は shell 補完に対応しています。公式ドキュメントでは、まず現在の shell を確認することが推奨されています。

`1`	`echo $SHELL`

Bash：

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh：

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish：

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell：

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

uvx もよく使う場合は、uvx の補完を別途有効にできます。

Bash：

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh：

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish：

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell：

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

設定後は shell を再起動するか、対応する設定ファイルを再読み込みします。

uv をアンインストールする

uv をアンインストールする場合は、まずキャッシュと uv が保存しているデータを削除できます。

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

その後、バイナリを削除します。

macOS / Linux：

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows：

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

公式ドキュメントでは、0.5.0 より前の uv は ~/.cargo/bin にインストールされていた点も注意されています。古いバージョンからアップグレードした場合、古いバイナリが残っていることがあるため、手動で削除する必要があります。

インストール後に最初にすること

インストール後は、まずバージョンを確認します。

`1`	`uv --version`

その後、いくつかのよく使うタスクから始められます。

uv python install
uv venv
uv pip install requests
uvx ruff --version

新規プロジェクトなら、次も確認するとよいでしょう。

uv init：プロジェクトを初期化する；
uv add：依存関係を追加する；
uv sync：環境を同期する；
uv run：プロジェクト環境でコマンドを実行する；
uvx：Python CLI ツールを一時的に実行する。

私のおすすめ

個人の開発マシンでは、公式スタンドアロンインストーラーを優先するのがおすすめです。uv 公式ドキュメントにもっとも近く、uv self update も使えるためです。

Windows ユーザーでリモートスクリプトを実行したくない場合は、WinGet や Scoop を使えます。macOS ユーザーでツールをすべて Homebrew に任せたい場合は、brew install uv で問題ありません。

すでに pipx で Python CLI ツールを管理している人は、pipx install uv を使うとよいでしょう。ただし、具体的なプロジェクトの仮想環境内で pip install uv するのはおすすめしません。ツールチェーンとプロジェクト依存関係が混ざりやすくなるからです。

CI やコンテナビルドでは、Docker と GitHub Releases を優先的に確認し、イメージビルドの流れに合わせてバージョンを固定します。

Awesome Codex Skills：Codex CLI を拡張するコミュニティ製スキルカタログ

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ の awesome-codex-skills は、Codex CLI 向けのコミュニティ製スキルカタログです。単なるプロンプト集ではなく、繰り返し使う作業手順をインストール可能で、再利用しやすく、保守しやすい Skill として整理している点に価値があります。

Codex を日常の開発パートナーとして使っているなら、この種のリポジトリの意味はかなり分かりやすいはずです。毎回説明していたルール、コマンド、参照資料、操作手順を一度 Skill にまとめておけば、次回から Codex は同じ文脈で作業を始められます。

このリポジトリが解決すること

Codex Skills は、Codex CLI に「専用の作業モード」を追加する仕組みだと考えると分かりやすいです。通常のプロンプトは一度きりの指示に向いていますが、Skill は長く再利用する作業に向いています。

たとえば、次のような作業です。

決まった形式でコミットメッセージを生成する。
特定の API ドキュメントを参照する。
プロジェクト固有のテストやデプロイコマンドを実行する。
チーム規約に沿って記事を書き直す、翻訳する、資料を整理する。
外部ツールを呼び出して反復的な開発補助作業を行う。

こうした内容を毎回入力するのは負担になります。Skill はそれらのルールを独立したディレクトリに置き、中心となる SKILL.md に手順を書きます。必要に応じてスクリプト、テンプレート、参考資料、アセットも添えられます。Codex は呼び出されたときにその説明を読み、定義された流れに従って作業します。

通常のプロンプトとの違い

通常のプロンプトは「今回はこうしてほしい」という一回限りの指示に近いものです。Skill は「この種類のタスクでは今後この手順で進める」という小さな運用マニュアルに近いものです。

主な利点は次の三つです。

再利用できる：よく使う作業手順を何度も貼り付ける必要がありません。
レビューしやすい：スキルファイルは通常ローカルの Markdown で、直接開いて編集し、バージョン管理できます。
拡張できる：複雑な Skill は自然言語の説明だけでなく、スクリプト、テンプレート、参考資料を含められます。

awesome-codex-skills のようなカタログの価値もここにあります。既存の Skill を探し、自分の作業スタイルに合わせて選び、インストールし、改造できます。

インストールと使い方

リポジトリにはインストールスクリプトが用意されており、手動インストールにも対応しています。典型的な流れは次の通りです。

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

少数の Skill だけを試す場合は、各スキルディレクトリの SKILL.md を先に読み、どの資料を読むのか、どのスクリプトを実行するのか、どのファイルを変更する可能性があるのかを確認してから、ローカルの Codex skills ディレクトリへ入れるのがよいでしょう。

インストール後、Codex はタスクに応じて Skill を自動的に使うこともできますし、明示的に名前を指定して呼び出すこともできます。長く使うなら、まずコミュニティ製 Skill を入れ、その説明を自分のプロジェクト規約に合わせて書き換えるのが実用的です。

注目したい Skill

この種のリポジトリで最初に見るべきなのは、名前が派手な Skill ではなく、反復作業を安定して減らしてくれる Skill です。

優先して見たいのは次のようなものです。

開発フロー系：コードレビュー、テスト、コミット、リリース、依存関係チェック。
ドキュメント処理系：書き直し、翻訳、要約、構造化整理。
ツール連携系：Codex を外部サービス、API、CLI ツールにつなぐもの。
プロジェクト規約系：チームの約束、ディレクトリ構成、命名規則、デプロイ手順を固定フローにするもの。

一文のプロンプトを包んだだけの Skill なら価値は限られます。調査、判断、実行、検証、出力までを安定した流れにできる Skill なら、長く残す価値があります。

注意点

コミュニティ製 Skill は便利ですが、ブラックボックスとしてそのまま実行するべきではありません。特にスクリプトを含む Skill は、インストール前に次の点を確認したいところです。

SKILL.md が Codex に何をさせようとしているか。
ネットワークアクセス、ファイルの読み書き、外部サービス呼び出しを行うスクリプトが含まれているか。
デフォルトのパス、コマンド、権限が自分の環境に合っているか。

Skill は Codex の行動範囲を広げます。よく書かれた Skill は、Codex をプロジェクトに詳しい同僚のようにしてくれます。雑に書かれた Skill は、合わないルールを作業フローへ持ち込むこともあります。理想は大量に入れることではなく、少数を入れ、自分に合うよう調整し、長く保守することです。

所感

awesome-codex-skills はブックマークする価値があります。特に Codex CLI を実際の開発、ドキュメント作成、自動化に使い始めている人には役立ちます。これは公式機能そのものではなく、コミュニティが整理した Skill の入口です。そこから着想を得ることも、普段の作業を自分用のローカル Skill に変えることもできます。

ヘビーユーザーにとって、Codex Skills の重要点は AI に多くを記憶させることではありません。同じ種類のタスクで回り道を減らすことです。ルールを Skill として書くことは、一度きりの説明を再利用可能な作業基盤に変えることでもあります。

Warp オープンソース化：ターミナルから Agentic Development Environment へ

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp は Warp のオープンソースクライアントリポジトリです。Warp は現在、自身を「ターミナルから生まれた agentic development environment」と位置付けています。つまり、ターミナルを土台にしながら、AI coding agent、コードベース索引、タスク管理、開発ワークフローを同じ環境に統合しようとしています。

これは普通のターミナルエミュレータのオープンソースリポジトリではありません。むしろ、Claude Code、Codex、Gemini CLI のような agent が一般化する中で、ターミナル自体が agent を調整し、観察し、管理する開発環境になるべきか、という問いへの答えに近いものです。

Warp の答えは「なるべき」です。

現在のリポジトリ状況

2026年5月7日時点で、warpdotdev/warp は公開リポジトリで、GitHub では約 56k stars、4.1k forks が表示されています。README では、Warp のクライアントコードがオープンソース化され、コミュニティからの貢献を歓迎すると説明されています。

主要言語は Rust です。GitHub の言語統計では Rust が 98% 以上を占めています。これは Warp の位置付けと合っています。Web のラッパーではなく、クロスプラットフォームのネイティブ開発ツールです。

README で重要な点は次の通りです。

Warp は agentic development environment, born out of the terminal。
内蔵 coding agent を使えるだけでなく、Claude Code、Codex、Gemini CLI などの外部 CLI agent にも接続できる。
OpenAI は新しくオープンソース化された Warp リポジトリの founding sponsor。
リポジトリ内の agentic management workflows は GPT models によって駆動される。
Warp UI framework 関連 crate は MIT license、それ以外のコードは AGPL v3。

これらを見ると、Warp のオープンソース化は単にターミナルを公開しただけではなく、agent ワークフローの実験場として運営していることが分かります。

Warp は単なるターミナルではない

従来のターミナルが主に解決していたのは次の三つです。

shell を起動する。
コマンドを実行する。
出力を表示する。

初期の Warp の差別化は、ターミナルをより現代的にすることでした。コマンドブロック、補完、履歴、コラボレーション、UI 的な操作、クロスプラットフォーム体験などです。現在はさらに進み、AI agent を中心に開発フローを組み立てようとしています。

README から見ると、Warp はもはや「より使いやすい terminal」だけを強調していません。次の要素を重視しています。

内蔵 coding agent。
外部 CLI agent 対応。
issue triage。
spec 作成。
PR review。
contributor coordination。
観察可能な agent sessions。

つまり Warp は、ターミナルを「コマンドを入力する場所」から「複数の agent と一緒に働く場所」へ変えようとしています。

Oz とオープンソース管理

README では Oz が何度も登場します。

Warp の contribution overview では、多数の Oz agents が issue triage、spec 作成、実装、PR review に取り組んでいる様子が示されています。これは興味深い設計です。AI agent を「個人のコード作成支援」から「オープンソース協作の管理支援」へ広げているからです。

従来のオープンソースプロジェクトで難しいのは、コードを書くことだけではありません。むしろ維持管理です。

issue が多すぎて分類されない。
bug と feature request が混在する。
新規貢献者が取り組みやすいタスクを見つけにくい。
PR review の負担が大きい。
メンテナーがコミュニティ議論を継続的に追いにくい。

Warp の考え方は、agent にプロジェクト管理と協作作業の一部を先に担わせることです。README には Oz for OSS も登場します。これはメンテナー向けのプログラムで、同様の agentic open-source management workflows をほかのリポジトリへ持ち込むためのものです。

つまり Warp の狙いはターミナル製品だけではなく、AI 時代のオープンソース維持管理モデルの探索にもあります。

リポジトリ構成と技術スタック

リポジトリ構成を見ると、Warp は大規模な Rust プロジェクトです。

ルートには次のようなものがあります。

app/：メインアプリケーション関連コード。
crates/：中核 Rust crates。
assets/：リソースファイル。
command-signatures-v2/：コマンドシグネチャ関連。
docker/、script/、resources/、specs/ などのエンジニアリング用ディレクトリ。
.claude/、.warp/、.agents/skills などの agent 関連設定。

WARP.md にはより詳しいエンジニアリング説明があります。Warp は Rust-based terminal emulator で、自社製 UI framework WarpUI を使っていると説明されています。

主要モジュールはおおよそ次のように理解できます。

app/：ターミナルエミュレーション、shell 管理、AI 統合、Drive、認証、設定、workspace、session。
crates/warp_core/：中核ユーティリティとプラットフォーム抽象。
crates/editor/：テキスト編集機能。
crates/warpui/ と crates/warpui_core/：自社製 UI framework。
crates/ipc/：プロセス間通信。
crates/graphql/：GraphQL client と schema。

WARP.md ではさらに次のような特徴も挙げられています。

Entity-Handle system。
モジュール化された workspace 構造。
macOS、Windows、Linux クロスプラットフォーム、および WASM target。
Agent Mode、文脈認識、コードベース索引を含む AI integration。
Warp Drive クラウド同期。

この複雑さは、従来の軽量 terminal よりも、ほぼ完全な IDE に近いものです。

ローカルビルド

README のローカルビルド手順は簡潔です。

1
2
3

./script/bootstrap
./script/run
./script/presubmit

それぞれ次の役割です。

./script/bootstrap：プラットフォーム別の初期化。
./script/run：Warp をビルドして実行。
./script/presubmit：フォーマット、clippy、テストなどの提出前チェック。

WARP.md にはさらに細かいコマンドもあります。

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

Warp にコードを貢献するなら、./script/presubmit は基本的に必須です。

貢献フロー

Warp の貢献フローは、単に「PR を出せばよい」ではありません。

README では issue から PR までの軽量な流れが説明されています。

まず既存 issue を検索する。
重複がなければ bug または feature request を提出する。
メンテナーが issue を review し、readiness label を付けることがある。
ready-to-spec は、設計を spec として展開できる状態。
ready-to-implement は、設計が比較的明確で実装 PR に進める状態。
貢献者はラベル付き issue を引き受けられる。

この流れは大規模オープンソースに向いています。「アイデア」「設計」「実装」を分けることで、貢献者が最初から違う方向へ実装してしまうリスクを減らせます。

AI agent にも相性が良い流れです。agent はまず issue を整理し、spec を書き、テストを追加してから実装に進めます。Warp 自身もこの方式で agentic project management を示しています。

ライセンス：MIT + AGPL v3

Warp は二つのライセンス構成を採っています。

README では次のように説明されています。

Warp UI framework、つまり warpui_core と warpui crates は MIT license。
リポジトリのそれ以外のコードは AGPL v3。

これは重要です。AGPL v3 はネットワークサービスや配布に対して、より強いオープンソース要件を持ちます。学習、研究、貢献であれば大きな問題はありませんが、Warp のコードを商用製品やクローズドソース派生物に使いたい場合は、license を慎重に読み、必要なら法務相談が必要です。

簡単に言えば、Warp はオープンソースですが、「自由に持っていって閉源商用化できる」タイプの緩いライセンスではありません。

注目すべき点

第一に、Warp はターミナル、agent、プロジェクト管理を一つにまとめようとしています。

多くの AI coding ツールはまだ CLI かエディタプラグインです。Warp はターミナルという入口から、agent タスク、コード実行、コマンド出力、PR ワークフロー、チーム協作を統合しようとしています。

第二に、Warp のオープンソース化は agent ワークフロー観察に向いています。

コードを公開するだけでなく、contribution overview、agent session、issue triage、spec フローも見せています。AI がオープンソース協作にどう参加できるかを研究したい人にとって、このリポジトリ自体がサンプルです。

第三に、Warp は複雑な Rust デスクトップアプリケーションです。

Rust GUI、ターミナルエミュレータ、クロスプラットフォームアプリ、GraphQL client、クラウド同期、AI 統合を学びたいなら、読むべき構造が多くあります。ただし小さなプロジェクトではないため、新規貢献者はまずドキュメントと issue フローを読むべきです。

第四に、Warp は「内蔵 agent」と「bring your own CLI agent」の両方を支援しています。

これは現実的です。開発者が一つの agent だけを使うとは限りません。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw などは共存し続けるでしょう。Warp がそれらの作業台になれるなら、単一目的のターミナル以上の価値があります。

誰が注目すべきか

通常のターミナルユーザーにとって、Warp に注目する意味は、ターミナルがコマンドラインツールから AI ワークベンチへ変わりつつあるかもしれない点です。

AI coding agent をよく使う人にとって、Warp は複数 agent を管理しようとしている点で注目に値します。単なるチャット入口ではありません。

オープンソースメンテナーなら、Oz for OSS の流れを見る価値があります。agent による issue triage、PR review、コミュニティ協作、貢献者案内を試みています。

Rust 開発者にとって、Warp は大型の実例デスクトップアプリです。UI、ターミナル、クラウド同期、AI 統合、クロスプラットフォームコードの構成を研究できます。

単に従来のターミナルをすぐ置き換えたいだけなら、まず正式版をダウンロードして使い、その後でソースを読むか決めるのがよいでしょう。ソースから直接ビルドするのは、貢献者や深いユーザー向けです。

短評

Warp のオープンソース化の要点は、「現代的なターミナルがオープンソースになった」だけではありません。

より正確には、Warp はターミナルを agentic development environment へアップグレードしようとしています。ターミナルが shell、コードベース、コマンド実行、agent、issue、PR、協作フローをつなぐ役割を担う、という考え方です。

AI coding agent がさらに増える中で、開発環境の入口は変わるかもしれません。以前は IDE が開発体験を支配し、ターミナルはコマンド実行を担っていました。今後はターミナルが agent 協作の中心になる可能性があります。Warp のリポジトリは、その可能性を探っています。

Codex App 入門ガイド：インストール、サンドボックス、並列タスク、Skills、MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App は、AI コーディング向けのタスクワークスペースと考えると分かりやすい。従来の IDE でも、単なるチャット画面でもなく、マルチタスク、プロジェクト管理、サンドボックス権限、Git、クラウド実行、プラグイン、Skills、MCP、自動化を 1 つのインターフェイスにまとめている。

すでに Codex CLI、Claude Code、Cursor、その他の coding agent を使っているなら、Codex App の最も注目すべき点は、「複数の agent を並列に動かす」ことをより明確なデスクトップワークフローにしている点だ。

Codex App が向いていること

Codex App の価値は、AI に質問へ答えさせることではなく、プロジェクトディレクトリ内で継続的にタスクを実行させることにある。

コードを編集し、コマンドを実行し、開発サーバーを起動する。
複数のプロジェクトと複数のタスクを管理する。
ローカルまたはクラウドで長いタスクを実行する。
プラグイン、Skills、MCP を呼び出して能力を拡張する。
Git、worktree、PR で変更を管理する。

OpenAI も Codex App を複数の coding agent を管理するためのインターフェイスとして位置付けている。複数のコードタスクを同時に進める人に向いており、特にフロントエンドページ、スクリプト、小規模アプリ、ドキュメント整理、自動化ワークフローと相性がよい。

インストール前の準備

Codex App を使う前に、次の 3 つの基本ツールを用意しておくとよい。

Git
Node.js
VS Code または普段使っている IDE

Codex App は macOS と Windows をサポートしている。インストール後は ChatGPT アカウントでログインする。初回起動時には、プログラミングや日常作業など主な利用シナリオを選択できる。Codex は選択内容に応じて一部のプラグインと Skills を事前に入れ、後から設定やプラグインマーケットで調整できる。

Windows と macOS の主な機能はおおむね同じだが、一部のコンピューター自動化機能はプラットフォームやプラグイン対応に依存する。実際には現在のバージョンに表示される内容を基準にする。

インターフェイス構造：プロジェクト、タスク、チャット

Codex App は典型的な 3 カラム構成になっている。

左側：プロジェクト、タスク、過去のチャット、プラグイン、自動化への入口。
中央：現在のチャット画面。
右側：ファイル、ブラウザー、ターミナル、実行結果などの多機能領域。

1 つのプロジェクトは通常、ローカルフォルダーに対応する。同じプロジェクト内で複数のチャットを開くことも、複数のプロジェクトを同時に開き、異なる agent に並列で作業させることもできる。

タスクリストには状態が表示される。

実行中：agent がまだ作業している。
承認待ち：権限、ネットワーク、依存関係インストール、高リスク操作の確認が必要。
完了：タスクが終了し、結果確認や追加質問ができる。

複数のターミナルを行き来するより直感的で、複数の AI タスクを同時に管理しやすい。

サンドボックスと権限管理

Codex App の権限体系はサンドボックスを中心にしている。デフォルトでは、現在のプロジェクトフォルダーが agent の主な作業範囲になる。

一般的な権限境界は次の通り。

プロジェクトディレクトリ内のファイルを読み書きできる。
デフォルトではプロジェクト外のファイルを自由に変更できない。
ネットワークや高リスクコマンドはデフォルトで制限される。
権限昇格が必要な場合はユーザーに承認を求める。

実用的なのは「自動レビュー」モードだ。低リスク操作は自動で許可し、高リスク操作はユーザー確認に回す。これにより頻繁なポップアップを減らしつつ、危険な操作が知らないうちに実行されることを防げる。

「完全アクセス」は慎重に使うべきだ。agent が何をする必要があるか明確で、プロジェクトが Git でバックアップされ、重要ファイルにも別のバックアップがある場合に向いている。日常的に常時有効にするのはおすすめしない。

コンテキスト、モデル、利用枠

Codex App は現在のチャットのコンテキスト使用状況を表示する。会話が長く、履歴が多いほど、モデルが処理するコンテキストも大きくなる。

実用的な習慣は次の通り。

1 つのタスクが終わったら新しいチャットを開く。
長い会話は手動圧縮できるが、圧縮を万能の記憶と考えない。
複雑なタスクでは、目的、境界、受け入れ条件を先に明確にする。
関係ない大量のログ、エラー、ファイルを一度に詰め込まない。

モデル選択では、タスクの複雑さに応じて推論強度を調整する。簡単な修正、文章整理、反復タスクは必ずしも最高性能モデルを必要としない。アーキテクチャ移行、難しいバグ、複数ファイルにまたがるリファクタリングには、より強いモデルが向いている。

高速モードがある場合は、通常より利用枠を多く消費する点に注意する。急ぎの時には有効だが、日常のデフォルトにする必要はない。

画像生成とマルチモーダル入力

Codex App は画像やファイルをコンテキストとして受け取ることができ、適切な場面では画像生成能力も呼び出せる。

これはフロントエンドやコンテンツ系プロジェクトで役立つ。たとえば Codex に次のことを依頼できる。

スクリーンショットをもとにページスタイルを修正する。
Web ページ内の不適切な画像を置き換える。
商品画像、カルーセル画像、ページ素材を生成する。
UI スクリーンショットから修正すべき位置を指摘する。

より効率的なのは、「もっときれいにして」とだけ言うのではなく、スクリーンショットを使って具体的な問題を示すことだ。たとえば「このカードの余白が大きすぎる」「この画像はサービスシーンに合っていない」「地図エリアをもっと分かりやすくする」といった指示がよい。

Steer：実行中に方向を修正する

Steer は、実行中に方向を引き受ける機能と考えるとよい。agent がすでに作業を始めた後で、方向を誤解していると気づいた場合、すべて終わるまで待ってから直す必要はない。

この機能を使うと、新しい指示を現在の実行フローに挿入し、Codex に進路を修正させられる。

Steer が向いている場面は次の通り。

agent が要件を誤解した。
生成されたページのスタイルが明らかに違う。
実行中の案が重すぎる、またはコストが高すぎる。
途中で重要な制約を追加する必要がある。

通常はデフォルトのキュー動作を維持し、本当に介入が必要な時だけ手動で Steer を使うのがよい。通常のタスクを乱さず、重要な場面で方向を戻せる。

計画モードと内蔵ブラウザー

複雑なタスクでは、まず計画モードを使うのがよい。計画モードでは Codex はすぐにコードを変更せず、先に計画を出し、必要ならカード形式で重要な選択肢を確認する。

計画モードに向いているタスクは次の通り。

React プロジェクトを Next.js に移すようなフレームワーク移行。
大規模リファクタリング。
データベース、認証、デプロイを含む機能。
技術方針がまだ固まっていない要件。

Codex App の右側領域では内蔵ブラウザーを開き、ローカル開発サーバーをプレビューできる。ページ上で注釈を付け、具体的な UI 位置に応じて Codex に修正させられる。この「ページを見る、位置を指す、AI に直させる」流れは、純粋な文章説明よりフロントエンドデバッグに向いている。

Git、IDE、コードのロールバック

Codex App は完全な IDE ではない。コード閲覧や注釈はできるが、手作業での編集は VS Code、Cursor、Windsurf などの IDE の方が向いている。

Codex プロジェクトでは早めに Git を初期化しておくとよい。

Codex に .gitignore を作成または確認させる。
使える状態になったら一度コミットする。
大きな変更の前にはクリーンなコミット地点を作る。
不満があれば Git でコードを戻す。

チャット履歴だけを戻しても、コードは自動では戻らない。安定した方法は、チャットを適切な地点へ戻し、コードは Git commit hash で対応する状態へ戻すことだ。

Worktree：複数方向の並列開発

git worktree は Codex App で並列 agent を使う際に非常に相性がよい。

本質的には、同じリポジトリから複数の独立した作業ディレクトリを作り、それぞれを別ブランチに対応させる仕組みだ。これにより、異なる agent を別フォルダーで同時に作業させても互いに上書きしない。

典型的な使い方は次の通り。

1 つの worktree で顧客レビューコンポーネントを改善する。
1 つの worktree で店舗情報と地図レイアウトを調整する。
2 つのタスクが終わったらそれぞれ main へマージする。
マージ後に一時 worktree を削除する。

同じディレクトリで複数 agent に同時編集させるよりずっと安定する。競合が出た場合も、通常の Git フローで review と merge を行えばよい。

クラウド実行環境

Codex はローカルだけでなく、クラウド環境にもタスクを委任できる。

クラウド実行が向いている場面は次の通り。

外出中で手元にスマートフォンしかない。
agent に長いタスクをバックグラウンドで実行させたい。
コードがすでに GitHub に同期されており、Codex にリモートリポジトリを変更させたい。
PR 形式で変更を確認してマージしたい。

典型的な流れは、ローカルコードを GitHub に push し、Codex がクラウド環境でリポジトリを取得してタスクを実行し、変更を生成し、PR または diff としてレビューに出すというものだ。

ローカルで開発を続ける場合は、リモートの最新変更を取り込むことを忘れない。

記憶システム：AGENTS.md を整える

新しいチャットはデフォルトでは完全な履歴記憶を持たない。プロジェクトが複雑になると、毎回背景を説明し直すのは非効率だ。

最も汎用的な方法は、プロジェクトルートに AGENTS.md を置くことだ。このファイルには次の内容を記録できる。

プロジェクトの目的と主要技術スタック。
よく使うコマンド。
ディレクトリ構成。
コードスタイルと命名規則。
禁止事項、たとえばファイルの一括削除を避けること。
テスト、ビルド、デプロイルール。

Codex にプロジェクトを読ませて AGENTS.md の初版を生成させ、人間が確認する方法もよい。複雑なプロジェクトでは、このファイルを維持する価値が高い。

グローバルルールは慎重に使う。全プロジェクトに共通する安全制約、たとえば「ディレクトリを再帰的に削除しない」「破壊的操作の前に確認する」などに向いている。特定プロジェクトの細部をグローバルルールに入れると、他のプロジェクトを汚染する。

プラグインと自動化

プラグインは、GitHub、Gmail、Google Drive、データベース、デプロイ基盤など外部サービスを Codex に接続する。

価値はコピー&ペーストを減らすことだ。たとえば Codex に次のことをさせられる。

GitHub リポジトリの star 推移を確認する。
メール内容を整理して自分に送る。
定期的なチェックを実行する。
結果を要約として書く。

自動化は繰り返しタスクに向いている。たとえば毎週金曜午後にリポジトリデータを確認し、メールレポートを送るような用途だ。簡単な自動化タスクには最高性能モデルは不要で、軽量モデルで十分なことが多い。

Skills：ワークフローを再利用可能な能力にする

Skills は Codex の「専門的な手順書」だ。一回限りのプロンプトではなく、ある種類のタスクの流れ、規則、スクリプト、注意点をまとめ、Codex が後で安定して再利用できるようにする。

主な入手元は次の 3 種類。

公式 Skills。
サードパーティ Skills。
自分で書いた Skills。

Skill 化に向いている作業は次の通り。

字幕を図解付きノートにする。
会社の形式で週報を書く。
画像や文書を一括処理する。
固定形式のコードレビュー。
特定フレームワークのプロジェクト初期化。

同じプロンプトを何度もコピーしているなら、Skill にする価値がある。

MCP：外部ツールとデータベースを接続する

MCP は、大規模モデル向けの標準化されたツールプロトコルと考えられる。MCP を通じて、Codex は外部サービスを呼び出し、より具体的なタスクを完了できる。

たとえば Supabase を接続すると、Codex に次のことをさせられる。

データベーステーブルを作成する。
データベーススキーマを読む。
バックエンドエンドポイントを変更する。
フロントエンドフォームをデータベースへ送信する。
データベース状態に基づいて問題をデバッグする。

これは強力だが、権限境界に注意が必要だ。データベース、本番環境、デプロイ基盤、メールアカウントは高リスク資源である。初回接続時はテストプロジェクトと低権限アカウントを使うのがよい。

デプロイプラグイン

デプロイ基盤のプラグインを使うと、Codex がビルドと公開を直接完了できる。たとえばフロントエンドプロジェクトを Netlify のような平台へデプロイできる。

この種のプラグインは、小規模サイト、プロトタイプ、社内ツール、デモプロジェクトに向いている。実際に使う時は次の点に注意する。

デプロイ前にローカルビルドを実行する。
環境変数をコードへ直接書かない。
公開後にページが正常に開くか確認する。
本番プロジェクトでは人間の review を残す。

AI は公開フローをつなぐ助けになるが、デプロイ権限は慎重に管理すべきだ。

コンピューター自動化

対応プラットフォームとプラグイン環境では、Codex がブラウザーやデスクトップアプリを操作し、RPA に近いタスクを実行できる。

例：

チャットアプリを開いてメッセージを準備する。
プロジェクトボードを閲覧し、タスク状態を要約する。
英語のブリーフを生成する。
確認後、指定相手へ送信する。
この流れをスケジュール自動化にする。

この機能は想像力を広げるが、最も強い安全境界も必要だ。メッセージ送信、メール送信、フォーム送信、支払い、データ削除に関わる操作では、人間の確認を残すべきだ。

使い方の提案

Codex App の正しい使い方は、すべてを一度に完全自動化させることではない。タスクを明確に分解し、制御された環境で効率よく実行させることだ。

おすすめの習慣：

すべてのプロジェクトで最初に Git を初期化する。
複雑なタスクでは計画モードを使う。
並列タスクでは worktree を優先する。
プロジェクトルールを AGENTS.md に書く。
高リスク操作では人間の確認を残す。
繰り返しワークフローを Skill や自動化にする。
プラグインと MCP はまずテスト環境で検証する。

参考資料

まとめ

Codex App の本質は「もう 1 つの AI チャット画面」ではない。AI コーディングを管理可能なワークスペースにすることだ。ローカルプロジェクト、クラウドタスク、Git、worktree、プラグイン、Skills、MCP、自動化をつなげられる。

うまく使う鍵は、「任せること」と「制御すること」のバランスを取ることだ。小さなタスクは大胆に Codex に渡し、複雑なタスクはまず計画させ、高リスク操作は必ず確認する。そうすれば Codex は、コードを書く助手から、長期的に協力できるエンジニアリングツールへ近づく。

Cline で DeepSeek V4 Pro を呼び出す方法

Fri, 01 May 2026 20:59:06 +0800

Cline はすでに OpenAI Compatible Provider をサポートしています。 DeepSeek API も OpenAI SDK 風の呼び出しに対応しているため、deepseek-v4-pro を Cline に接続するのは難しくありません。OpenAI Compatible を選び、DeepSeek の Base URL、API Key、モデル名を入力すればよいだけです。

以下では、VS Code 拡張機能の画面と Cline CLI の 2 通りで整理します。

DeepSeek API Key を準備する

まず DeepSeek の開放プラットフォームで API Key を作成します。

必要な値は 3 つです。

項目	入力内容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek の公式ドキュメントでは、V4 シリーズは既存の OpenAI 互換インターフェースを使い、base_url は https://api.deepseek.com のまま、呼び出し時に model を deepseek-v4-pro または deepseek-v4-flash に設定すると説明されています。

Cline 拡張機能で設定する

VS Code の Cline 拡張機能を使っている場合は、次の手順で設定できます。

VS Code サイドバーの Cline を開く。
Cline の設定またはモデル設定ページに入る。
Provider で OpenAI Compatible を選ぶ。
API Key に DeepSeek API Key を入力する。
Base URL に次を入力する。

`1`	`https://api.deepseek.com`

Model ID に次を入力する。

`1`	`deepseek-v4-pro`

設定を保存し、Cline のチャット画面に戻って簡単なタスクでテストする。

まずは低リスクな読み取り専用タスクを試すとよいです。

現在のプロジェクトのディレクトリ構造を読み取り、このプロジェクトがどの種類のものか要約してください。ファイルは一切変更しないでください。

正常に読み取りと回答ができれば、モデルの接続は通っています。

Cline CLI で設定する

Cline CLI を使う場合は、cline provider configure openai-compatible で対話式設定に入れます。

例：

`1`	`cline provider configure openai-compatible`

対話中に次を入力します。

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

設定後、読み取り専用タスクでテストできます。

`1`	`cline "Summarize this repository structure without changing files."`

まずコストを下げたい場合は、Model ID を一時的に次へ変更してもよいです。

`1`	`deepseek-v4-flash`

複雑な計画、事実確認、複数ツールの協調、高リスクなコード変更が必要になったら、deepseek-v4-pro に戻します。

推奨するモデルの使い分け

DeepSeek V4 Pro と Flash は、役割を分けて使うほうが向いています。

モデル	向いている場面
`deepseek-v4-flash`	日常的なコード読解、小さな修正の一括処理、スクリプト生成、コンテキスト整理、低リスクなフロントエンド修正
`deepseek-v4-pro`	アーキテクチャ設計、複雑な bug、複数ファイルのリファクタリング、事実確認、複数ツール呼び出し、高リスクな変更

Cline のような Agent ツールでは、主なコストは長いコンテキスト、繰り返しのファイル読み取り、計画生成、複数ラウンドのツール呼び出しから発生します。軽いタスクなら Flash で量をこなし、より強い判断が必要なときに Pro へ切り替えるのが現実的です。

コンテキスト長はどう設定するか

DeepSeek V4 Pro と Flash はどちらも長いコンテキストをサポートします。 Cline で context window を手動入力する必要がある場合は、DeepSeek 公式モデルページにある 1M コンテキストを目安にできます。

実際には、最初からすべてのファイルをコンテキストに入れることはおすすめしません。 Cline はタスクに応じてファイルを読み取るため、通常は次の流れがよいです。

まずディレクトリ構造を確認させる；
次に関連ファイルを特定させる；
最後に対象ファイルだけを中心に修正させる。

このほうが Token を節約でき、タスクの境界も明確に保ちやすくなります。

よくある問題

1. モデルが存在しないと表示される

まず Model ID が次のように書かれているか確認します。

`1`	`deepseek-v4-pro`

DeepSeek V4 Pro、deepseek-v4、その他の表示名を書かないでください。

2. 401 または認証失敗が出る

API Key を確認します。

完全にコピーできているか；
余計な空白が入っていないか；
Cline が現在使っている provider 設定に入力されているか；
DeepSeek アカウントに利用可能な残高があるか。

3. 接続失敗と表示される

Base URL を確認します。

`1`	`https://api.deepseek.com`

末尾に /v1/chat/completions を追加しないでください。 Cline の OpenAI Compatible Provider が互換インターフェースのリクエストを自分で組み立てます。

4. Cline の呼び出しが高くつく

日常タスクは deepseek-v4-flash に切り替え、複雑なタスクだけ deepseek-v4-pro を使うとよいです。

また、タスク説明はできるだけ明確に書きます。

ログインページ関連ファイルだけを修正してください。無関係なモジュールはリファクタリングしないでください。まず計画を提示し、確認後にコードを変更してください。

Agent タスクで最も危ないのは境界が曖昧なことです。境界が明確なほど、読むファイルが少なくなり、ツール呼び出しも減り、コストを制御しやすくなります。

5. reasoning_content must be passed back エラー

次のようなエラーが出る場合があります。

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

これは通常、Key、残高、Base URL の問題ではありません。DeepSeek V4 Pro の thinking mode と、現在のクライアント側の複数ラウンドのツール呼び出し履歴が一致していないことが原因です。

DeepSeek の公式ドキュメントでは、次のように説明されています。

thinking mode はデフォルトで enabled；
thinking mode では reasoning_content が返る；
あるラウンドで tool call が発生した場合、以降のリクエストではその assistant message 内の reasoning_content を API に一緒に返す必要がある；
クライアントが正しく返さない場合、400 が返る。

Cline が OpenAI Compatible Provider 経由で接続している場合、現在のバージョンが DeepSeek の reasoning_content を完全に保持して返していないと、2 ラウンド目やツール呼び出し後にこのエラーが出ることがあります。

試す順序は次のとおりです。

まず Cline を最新版に更新する；
通常の OpenAI provider ではなく、OpenAI Compatible を使っていることを確認する；
Cline がカスタム request body をサポートしている場合、thinking mode を無効化してみる：

{
  "thinking": {
    "type": "disabled"
  }
}

Cline が追加 body パラメータをサポートしていない場合は、当面この問題を起こさないモデルまたは互換プロキシサービスを使う；
Cline が DeepSeek V4 の reasoning_content 返送に対応したら、deepseek-v4-pro に戻す。

注意点として、thinking mode を無効にすると複雑な推論能力の一部は落ちますが、クライアントが reasoning_content を返さない互換性問題は回避できます。

そのままコピーできる設定

Provider: OpenAI Compatible
API Key: sk-あなたの DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

低コストモードにする場合：

Provider: OpenAI Compatible
API Key: sk-あなたの DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

まとめ

Cline で DeepSeek V4 Pro を呼び出す要点は 3 つだけです。

Provider で OpenAI Compatible を選ぶ；
Base URL に https://api.deepseek.com を入力する；
Model ID に deepseek-v4-pro を入力する。

設定後は、まず読み取り専用タスクでテストし、それから実際のコード変更を任せるのがおすすめです。 Agent タスクを頻繁に実行するなら、Flash と Pro を分けて使うとよいです。Flash は高頻度の軽量タスク、Pro は複雑な判断とフォールバックを担当します。

参考情報：

mattpocock/skills：AI コーディング Agent 向けの実用スキル集

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills は、Matt Pocock が公開している AI コーディング agent skills のコレクションです。

これは完全なアプリケーションでも、新しいチャットクライアントでもありません。AI コーディングアシスタントに使わせるための作業スキル集です。考え方は実用的です。AI コーディングでよく起こる問題を小さなスキルに分解し、Agent が適切なタスクで呼び出せるようにします。毎回巨大なプロンプトで無理に支えるのではありません。

Claude Code、Codex、Cursor、または類似の AI コーディングツールをよく使うなら、この種の skills は注目する価値があります。AI コーディング体験に本当に影響するのは、「モデルがコードを書けるか」だけではなく、自分の作業方法に沿ってタスクを進められるかだからです。

解決する問題

AI コーディングアシスタントは強力ですが、問題も起こしやすいです。

よくある状況は次のとおりです。

要件を理解する前にコード変更を始める
一度に多すぎるファイルを変更する
説明は多いが、実際に有用な行動が少ない
エラー後に場当たり的に試す
テストやチェックをすぐに実行しない
プロジェクト内の既存パターンを無視する
タスク完了のために不要な抽象を導入する
コードを書いた後に本当にリスクを review しない

これらは必ずしもモデル能力不足ではありません。ワークフローが十分に制約されていないことが原因の場合も多いです。

mattpocock/skills の価値は、こうした失敗パターンを再利用可能な操作方法に分解し、Agent が場面に応じてより経験あるエンジニア協作者のように振る舞えるようにすることです。

Skills とは何か

AI Agent の文脈では、skill は再利用可能なタスク説明、作業方法、専門的なフローとして理解できます。

必ずしもコードプラグインである必要はなく、外部サービスを呼び出す必要もありません。多くの場合、skill は明確なルールセットです。

いつ使うか
まず何をするか
何をしないか
何を出力するか
タスク完了をどう判断するか

これは通常のプロンプトテンプレートに似ていますが、粒度は「タスク能力」に近いものです。

通常のプロンプトテンプレートは、ユーザーが毎回一時的にコピーして貼り付けるものです。Skills は agent ツールボックスの一部として、Agent がタスクに応じて適切なフローを選ぶ形に向いています。

小さく組み合わせ可能である理由

README では、これらの skills が小さく組み合わせ可能であることを強調しています。

これは重要な方向性です。

1 つの skill がすべてを担当しようとすると、すぐに新しい巨大プロンプトになります。長く、曖昧で、保守しにくいものです。小さなスキルの利点は境界が明確なことです。

たとえば 1 つの skill は次のようなことだけに集中できます。

先に計画する
TypeScript エラーを修正する
テストを実行し、結果に基づいて修正する
コード review を行う
プロジェクト規約を要約する
プロンプトを改善する
不要な抽象を取り除く

これらのスキルはタスクに応じて組み合わせられます。単純なタスクなら 1 つ、複雑なタスクなら複数をつなげます。

これは実際のエンジニアリング作業に近いです。すべての問題を同じフローで処理するのではなく、問題に応じてツールを選びます。

エンジニアの制御を残す

このリポジトリの重要な方向性の一つは、エンジニアが制御権を持ち続けることです。

AI コーディングは、2 つの極端に寄りやすいです。

1 つ目は完全に手動です。AI は数行のコードを書く手伝いをするだけで、コンテキスト、計画、検証はすべて自分が監視します。

2 つ目は完全に放任です。タスクを Agent に投げ、大きく変更させ、最後にレビューしづらい diff と向き合います。

skills はその中間に、より安定した位置を作ります。

AI により多くの反復フローを任せつつ、ルールで制限します。

タスクを理解してから手を動かす
関連ファイルを読んでから変更する
変更範囲を制御可能にする
不確実な場合は報告する
変更後に検証する
見せつけるために無関係なコードをリファクタリングしない

これは AI を弱めるのではありません。AI の行動を人間がレビューし、引き継ぎやすくするものです。

アラインメント問題

AI コーディング失敗の最初の種類は、アラインメント失敗であることが多いです。

ユーザーが求めているのは具体的な変更ですが、Agent はそれを大きなリファクタリングとして理解することがあります。ユーザーは Bug 修正だけを望んでいるのに、スタイルまで変更することがあります。既存アーキテクチャに従ってほしいのに、新しいパターンを導入することもあります。

Skills はタスク開始時に Agent に次のことをさせられます。

目的を言い直す
影響範囲を見つける
既存の実装パターンを識別する
計画を出す
何をしないかを明確にする

これはエンジニアが作業開始前に行うセルフチェックに似ています。

Agent がタスク境界を明確にしないままコードを書き始めると、後でどんどんズレやすくなります。

フィードバックループ問題

AI のコード生成は一回だけに頼るべきではありません。

実際の開発では、フィードバックループが重要です。

小さく変更する
テストまたは型チェックを実行する
エラーを見る
修正する
再検証する

多くの Agent は途中のフィードバックを飛ばすために失敗します。一度に多くを変更し、感覚で「動くはず」とまとめます。

Skills はフィードバックループを明示的にフローへ書き込めます。たとえば Agent に次のことを要求できます。

変更後に関連チェックを実行する
チェックが失敗したら、まずエラーメッセージを読む
無関係なファイルを盲目的に変更しない
各修正後に再検証する
最後に検証結果を報告する

これにより AI コーディングは、一回限りの作文ではなく本物のデバッグに近づきます。

アーキテクチャ制御問題

AI は抽象を生成するのが得意で、過剰に抽象を生成するのも得意です。

小さな要件を満たすために、サービス層、ヘルパー関数、設定オブジェクト、型ラッパー、アダプターを新しく作り、最終的に要件そのものより複雑なコードにしてしまうことがあります。

この問題は大規模プロジェクトで特に危険です。AI が生成した抽象は「専門的」に見えますが、既存のプロジェクトスタイルに合わず、保守コストを増やす可能性があります。

良い skills は Agent に次のことを思い出させます。

既存パターンを優先する
不必要な新しい抽象を導入しない
無関係な領域をついでにリファクタリングしない
変更をタスク規模に合わせる
コードを理解してから構造を設計する

これにより、「見た目はエンジニアリングっぽいが実際は保守しにくい」出力を減らせます。

Review skill が重要な理由

コードを書くこととコードを review することは別の状態です。

Agent がコードを書くとき、自分の実装が成立することを説明しがちです。なぜこの変更で動くかは説明しますが、必ずしもリスクを探すわけではありません。

Review skill の意味は、Agent の役割を切り替えることです。

潜在 Bug を探す
振る舞いの回帰を探す
足りないテストを探す
境界条件を探す
複雑度の上昇を探す
既存規約と不一致な箇所を探す

これは AI コーディングで重要です。AI はコードを高速に生成するため、review がないとユーザーは大量の diff に埋もれやすくなります。

良い review 出力は、まず問題を列挙すべきです。先に実装を褒める必要はありません。エンジニアがその変更をマージできるか判断する助けになるべきです。

通常の rules ファイルとの違い

多くの AI コーディングツールは rules、instructions、memory をサポートしています。

これらのファイルは通常、長期ルールを記録します。

プロジェクト技術スタック
命名規約
テストコマンド
変更してはいけないディレクトリ
回答スタイルの好み

Skills はよりタスクフローに寄っています。

rules は Agent に「長期的にどう振る舞うべきか」を伝えます。skills は Agent に「この種類のタスクをどう実行すべきか」を伝えます。

両方を一緒に使うのがよいです。

たとえば rules にプロジェクトが pnpm test を使うと書き、review skill で変更後にテストカバレッジを確認するよう求めます。すると Agent はコマンドだけでなく、いつ使うべきかも理解します。

向いている場面

mattpocock/skills のようなリポジトリは次の場面に向いています。

AI コーディングツールを頻繁に使う
Agent に実コードベースを扱わせる
AI の範囲外変更を減らしたい
Agent により積極的に結果を検証させたい
自分のエンジニアリング習慣を skills にしたい
他人の agent workflows 設計を学びたい
一時的なプロンプト群を保守可能な skill 集合に整理したい

たまに AI に小さな関数を書かせるだけなら、skills を専用に維持する必要はないかもしれません。

しかし AI を長期的な開発パートナーとして扱うなら、skills は徐々に重要になります。Agent に再利用可能な作業方法を持たせるものだからです。

このリポジトリから学べること

各 skill を直接使わなくても、このリポジトリからいくつか学べます。

第一に、失敗パターンを書き出すことです。

AI が間違えたときにその場で不満を言うだけではなく、よく間違えるパターンをルールに整理します。次回は skill に先回りして防がせます。

第二に、スキルは短くすることです。

1 つの skill は、1 つの明確な問題を解くのが理想です。短いほど正しく呼び出されやすく、保守しやすくなります。

第三に、出力形式を明確にすることです。

Agent に先に計画を列挙し、次に実行し、最後に検証結果をまとめてほしいなら、その構造を明確に書きます。曖昧な要求は曖昧な結果を生みます。

第四に、人間が引き継ぐポイントを残すことです。

良い skill は AI を一人で遠くまで走らせるべきではありません。不確実性、影響範囲の拡大、テスト失敗、プロダクト判断が必要な場合は、止まって状況を説明させるべきです。

利用時の注意

第一に、すべてを skill 化しないことです。

skills が多すぎるとシステムは複雑になり、Agent もどれを選ぶべきか分からなくなります。まずは頻度が高く、痛みの大きい場面から始めるのがよいです。

第二に、skills は反復改善が必要です。

最初に書いた skill が良いとは限りません。AI の実行結果を見て、少しずつ削り、追加し、書き直します。

第三に、skill にエンジニアリング判断を置き換えさせないことです。

Skill はフローを改善できますが、実装の正しさを保証するものではありません。テスト、review、ビルドチェック、人間の判断は依然として重要です。

第四に、Agent ごとの差に注意することです。

Claude Code、Codex、Cursor、Copilot は instructions、skills、rules のサポート方法が異なります。同じ考え方は再利用できますが、具体的な形式はツールに合わせて調整する必要があります。

参考

mattpocock/skills

最後に

mattpocock/skills が注目に値するのは、その中の一つの魔法のプロンプトではありません。エンジニアリング経験を小さなスキルに分解し、Agent に場面ごとに組み合わせて使わせるという実用的な AI コーディングの考え方です。

AI コーディングがたまの補助から日常ワークフローになると、skills は Agent を制約し、エンジニアの制御を保ち、フィードバック品質を高める重要な道具になります。

Compound Engineering Plugin：AI コーディングを計画、実行、レビューの工程ループにする

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin は、Every Inc が公開している AI コーディングワークフロープラグインです。

注目しているのは「AI により速くコードを書かせること」ではありません。AI コーディングを、よりエンジニアリングチームに近いループへ入れることです。まず計画し、次に実装し、その後レビューし、最後に経験を蓄積します。Claude Code、Codex、Cursor、Copilot のようなツールをよく使う人にとって、この種のプラグインはプロンプト問題ではなくワークフロー問題を解決します。

AI コーディングツールは強力になっていますが、実プロジェクトで難しいのはコード生成そのものではありません。AI に継続してプロジェクトルールを守らせ、タスク境界を理解させ、同じ間違いを繰り返させず、複数回の反復でコンテキストを蓄積させることです。

解決する問題

多くの人は AI コーディングアシスタントを次のような流れで使います。

要件を直接説明する
AI にコードを変更させる
結果が動くか確認する
エラーが出たら追加説明する
次のタスクでまた背景を最初から説明する

小さなタスクならこれで十分なこともあります。しかし複雑なプロジェクトでは問題が起こりやすくなります。

要件を整理しないまま AI が編集を始める
コード変更後に体系的な review がない
プロジェクト規約がユーザーの繰り返しの注意に依存する
同じ種類のミスが次回も起こる
複数の Agent ツール間で統一した作業方法がない
経験が再利用可能なルールとして蓄積されない

Compound Engineering Plugin が解決したいのは、この種の問題です。AI コーディングを複数の段階に分け、Agent を単なるコマンド実行者ではなく、より完全なエンジニアリングプロセスの参加者にします。

Compound Engineering とは何か

プロジェクト README の説明から見ると、Compound Engineering は AI 支援ソフトウェア開発の方法と理解できます。

重視するのは次のループです。

計画：目的を理解し、タスクを分解し、方針を確認する
実行：計画に沿ってコードを変更し、コマンドを実行し、問題を処理する
レビュー：実装品質、リスク、テストカバレッジを確認する
学習：経験を後続で再利用できるルールとして蓄積する

このループは実際のエンジニアリングチームの働き方に近いです。

信頼できるエンジニアは、要件を受け取ってすぐに無秩序に変更することはありません。変更後に何も確認せず渡すこともありません。まず影響範囲を判断し、実装し、リスクとテスト結果を確認し、最後に踏んだ落とし穴を記録します。AI Agent にも同じような制約が必要です。

なぜプラグインが必要なのか

プロンプトで AI に「先に計画してから実行してください」と伝えることはできます。しかしプロンプト自体は必ずしも安定しません。

会話が長くなり、コンテキストが複雑になると、モデルは計画を飛ばしたり、ルールを無視したり、タスク完了を急いで過度に自信を持ったりします。プラグインの価値は、ワークフローを固定し、異なる Agent 環境でも似た方法を守れるようにすることです。

この種のプラグインは通常、ワークフローをコマンド、ルール、テンプレート、サブフローに分解します。ユーザーは毎回完全なプロンプトを書く必要がなく、固定された入口から特定の段階を起動します。

たとえば：

まず Agent に計画を生成させる
計画に沿って段階的に実装する
変更後に review を起動する
問題が見つかったら修正に戻る
残す価値のある経験を記憶やルールに書く

これにより AI コーディングは、一回限りのチャットではなく「制御された協作」に近づきます。

対応する Agent 環境

README では、複数の AI コーディング環境をサポートすると説明されています。

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

これは注目すべき点です。

多くのワークフローツールは 1 つのクライアントにだけ結びついており、ツールを替えるとルールを再利用できません。Compound Engineering Plugin は、クロス Agent のエンジニアリング方法に近く、計画、実行、レビューのような流れを異なるツールへ持ち込みます。

複数の AI コーディングアシスタントを同時に使うなら、このような統一ワークフローには価値があります。ツールごとに能力は違っても、プロジェクト規約、レビュー習慣、タスク分解方法はできるだけ一貫している方がよいです。

計画段階の役割

計画段階の価値は、AI が早すぎる段階で手を動かすのを防ぐことです。

複雑なタスクで本当に重要なのは、たいてい次のような問いです。

どのファイルを変更するのか
どのモジュールが影響を受ける可能性があるか
既存のパターンは何か
テストはあるか
リスクはどこにあるか
先に読むべきドキュメントはあるか
より小さなステップに分解できるか

Agent がこれらを考える前にコードを書き始めると、完成しているように見えてもプロジェクト構造から外れた実装になりやすくなります。

計画は長い必要はありません。良い計画は短く、具体的で、実行可能です。目的はドキュメントを増やすことではなく、後続の実装に境界を与えることです。

実行段階で避けるべきこと

AI がコードタスクを実行するとき、よく起こる問題があります。

関係ないコードをついでにリファクタリングする
ユーザーの既存変更を上書きする
happy path だけを処理する
エラーハンドリングを無視する
既存のプロジェクトスタイルに従わない
必要な検証を実行しない
エラー後に場当たり的に試す

ワークフロープラグインはこれらの問題を完全には消せませんが、ルールと段階制約によって発生確率を下げられます。

たとえば、実行段階では Agent に計画どおり段階的に進めさせます。計画範囲外の発見があった場合は、まずリスクを説明します。共有モジュールを変更する場合は、テストを追加するか、少なくとも関連検証を実行します。

この制約は大規模コードベースで特に重要です。AI が速くコードを書くほど、その勢いを制限するプロセスが必要になります。

レビュー段階が重要な理由

多くの AI コーディング失敗は、コードがまったく動かないからではありません。細部に問題があるからです。

境界条件が処理されていない
状態更新が一貫していない
API 契約がこっそり変わっている
テストが重要経路をカバーしていない
エラーメッセージが分かりにくい
性能やセキュリティリスクが触れられていない

レビュー段階は Agent を「作者モード」から「レビューモード」へ切り替えます。

作者モードでは自分の実装を正当化しがちです。レビューモードでは、穴、回帰リスク、テスト漏れを積極的に探すべきです。この 2 つの段階を分ける方が、同じ回答内で実装と自己レビューを同時に行わせるより信頼しやすくなります。

ユーザーにとっても、レビュー出力は価値があります。その変更をマージしてよいか、まだ修正が必要かを素早く判断できます。

学習と記憶の意味

プロジェクト名の “Compound” は、重要な考え方を示しています。エンジニアリング経験は複利的に増えるべきだ、ということです。

AI が毎回のミスをその場で直すだけで、次回また同じミスをするなら、生産性向上は限られます。より良い方法は、価値ある経験を蓄積することです。

このプロジェクトのディレクトリ規約
ある種類のエラーの調査方法
テストコマンドと注意事項
触ってはいけない生成ファイル
コードスタイルの好み
よく使う実装パターン

これらの経験は、ルール、記憶、ドキュメント、テンプレートになります。後続タスクでは、Agent がまずそれらの蓄積を読み、その後作業を始めます。

これが AI コーディングを「一回限りの問答」から「長期協作」へ進める鍵です。

向いている場面

Compound Engineering Plugin は次のような場面に向いています。

AI Agent を長期的に使ってコードを書く
1 つのプロジェクトを何度も、複数回にわたって変更する
AI に先に計画してから実装してほしい
変更後に review 思考へ自動で入ってほしい
チームで AI コーディングフローを統一したい
Claude Code、Codex、Cursor など複数ツールを同時に使う
プロジェクト経験を再利用可能なルールにしたい

たまに小さなスクリプトを AI に書かせるだけなら、完全なフローは重く感じるかもしれません。

しかし AI コーディングアシスタントを日常開発の相棒として使うなら、計画、実行、レビュー、学習のループは明らかに役立ちます。

通常のプロンプトテンプレートとの違い

通常のプロンプトテンプレートは、「タスクをどう明確に伝えるか」を解決します。

たとえば：

一歩ずつ考えてください
先にファイルを読んでください
コードスタイルを揃えてください
テストを実行してください
変更内容を要約してください

これらのプロンプトはもちろん有用です。しかし、毎回ユーザーが正しく使うことに依存しています。

Compound Engineering Plugin は、よりワークフロー層にあります。これらの要求を再現可能なプロセスとして整理し、異なる Agent ツールに適用します。毎回ゼロからプロンプトを書くのではなく、一つのフローの中でタスクを進めます。

簡単に言えば、プロンプトテンプレートはリマインダーであり、ワークフロープラグインは制度に近いものです。

利用時の注意

第一に、フローを負担にしないことです。

小さなタスクに完全な計画と長いレビューが常に必要なわけではありません。良いワークフローはタスクの複雑さに応じて調整できます。単純な問題は素早く処理し、複雑な問題では完全なループを使います。

第二に、レビューはテストの代わりにはなりません。

Agent review は多くの問題を見つけられますが、実行時エラーを見逃すことがあります。最終判断には、テスト、型チェック、ビルド結果、人間のレビューが必要です。

第三に、ルールは継続的に整理することです。

経験の蓄積は重要ですが、ルールが増えすぎるとノイズになります。古いルール、重複ルール、一回のタスクにしか合わなかった一時的な経験は、定期的に整理すべきです。

第四に、ツール間で一貫していることは完全に同じであることではありません。

Claude Code、Codex、Cursor、Copilot などは能力や対話方式が異なります。統一すべきなのは作業方法であり、すべてのコマンドや設定詳細が同じである必要はありません。

向いているチーム

チームがすでに AI Agent に実コードの変更を許可しているなら、「どのモデルが強いか」だけを議論しても不十分です。

より重要なのは次の点です。

AI は変更前にタスクを理解しているか
AI は変更中にプロジェクト境界を守っているか
AI は変更後にリスクを自発的にレビューしているか
AI は過去のミスから学べるか
チームに統一された Agent 利用規約があるか

Compound Engineering Plugin のようなプロジェクトの意味はここにあります。AI コーディングを個人の小技から、チームで再利用できるプロセスへ一歩進めます。

参考

EveryInc/compound-engineering-plugin

最後に

Compound Engineering Plugin が注目に値する理由は、AI コーディングコマンドを一つ増やすことではありません。AI コーディングを、継続的に改善できるエンジニアリングフローとして整理することです。

AI Agent が実プロジェクトに参加し始めると、計画、実行、レビュー、経験の蓄積は、一回限りのコード生成より重要になります。

Claude Code Hooks Mastery：13 個の Hooks ライフサイクルと自動化制御の入門

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery は、Claude Code Hooks を学ぶためのプロジェクトです。

単にいくつかのスクリプトを並べただけではありません。Claude Code の hooks ライフサイクル、設定方法、スクリプトの書き方、よくある自動化シナリオをまとめて説明しています。Claude Code をより制御しやすく、よりエンジニアリング向けの助手として使いたい人にとって、読む価値のある資料です。

Claude Code は標準でもコードを読み、ファイルを編集し、コマンドを実行できます。しかし、特定のタイミングで権限を確認したり、危険な操作を止めたり、プロジェクト規約を注入したり、テストを実行したり、チームルールを思い出させたりしたい場合、チャット指示だけでは安定しません。Hooks の価値は、「毎回 AI に思い出させたいルール」を実行可能なワークフローに変えることです。

Hooks が解決する問題

Claude Code をしばらく使うと、よく次のような課題が出てきます。

新しい会話のたびに同じプロジェクトルールを説明する必要がある
実行してはいけないコマンドを実行しないか不安
ファイル変更の前後で自動チェックしたい
コミット前にフォーマット、テスト、セキュリティスキャンを走らせたい
チーム規約を口頭の注意ではなく固定フローにしたい
ツール呼び出しの前後でコンテキストを取得し、ログやブロックに使いたい
複雑なタスクでサブエージェントや専用スクリプトを起動したい

Hooks は、こうした「決まったタイミングでの自動動作」のためにあります。

Claude Code ワークフロー内のイベントフックとして考えるとわかりやすいです。セッション開始、ユーザーのプロンプト送信、モデルがツールを呼び出す直前、ツール呼び出し完了、エージェント終了直前などのタイミングで、設定したスクリプトを実行できます。

13 個の Hooks ライフサイクル

このプロジェクト README の重要な点の一つは、Claude Code の 13 個の hook イベントを体系的に整理していることです。

これらのイベントは、セッション開始からツール呼び出し、ユーザー入力からエージェント終了まで、複数の段階をカバーします。用途別には、おおまかに次のように分けられます。

セッション起動関連：環境初期化、プロジェクトコンテキスト注入
ユーザー入力関連：プロンプト確認、ルール補足、監査
ツール呼び出し前関連：権限判断、コマンドブロック、安全チェック
ツール呼び出し後関連：結果記録、フォーマット起動、検証実行
タスク終了関連：要約、クリーンアップ、通知、状態保存

このライフサイクル設計により、すべてのルールを長いプロンプトに詰め込む必要がなくなります。

たとえば、権限制御はツール呼び出し前に行うべきです。フォーマットチェックはファイル変更後の方が自然です。プロジェクト規約の注入は、セッション開始時やユーザー入力後が向いています。正しい hook ポイントにルールを置く方が、すべてを system prompt に詰めるより信頼しやすくなります。

設定ファイルの場所

Claude Code の hooks は通常、設定ファイルで構成します。

よく使われる場所は次のとおりです。

ユーザー単位の設定：~/.claude/settings.json
プロジェクト単位の設定：.claude/settings.json

ユーザー単位の設定は、一般的な安全ルール、コマンドブロック、ログパスなど、個人の好みに向いています。

プロジェクト単位の設定は、そのリポジトリに関するルールに向いています。たとえば、必ず実行するテスト、編集禁止のディレクトリ、生成ファイルの扱い、コミット前のチェックなどです。

チームで Claude Code を使うなら、プロジェクト単位の設定をリポジトリに置くのがおすすめです。そうすれば、各自が記憶で AI に注意するのではなく、全員が同じ AI 協作制約を持ってプロジェクトを開けます。

単一ファイルスクリプトが重要な理由

このプロジェクトでは UV の単一ファイルスクリプトが強調されています。

利点はデプロイが簡単なことです。1 つの Python ファイルで依存関係を宣言して実行できるため、1 つの hook のために複雑な環境を維持する必要がありません。多くの hook は小さな処理を 1 つ行うだけなので、この形式は適しています。

コマンドの実行可否を確認する
ファイルパスが安全か判断する
プロジェクト規約を読み、Claude に返す
出力に機密情報が含まれていないか調べる
変更後にフォーマットやテストを実行する
イベントをログに書く

Hook スクリプトは小さいほど保守しやすく、新しい複雑なシステムになりにくくなります。

どんな自動化ができるか

claude-code-hooks-mastery は多くの方向性を示しています。実務でよく使うのは次のようなものです。

1. 権限と安全制御

これは hooks の最も直接的な用途です。

Claude Code がコマンドを実行する前に、その内容をチェックできます。削除、リセット、クリア、上書きなどの高リスク操作が含まれている場合、実行を止めるか、人間の確認を求められます。

同様のルールはファイルパスにも使えます。

本番設定を変更しない
秘密鍵ファイルに書き込まない
マイグレーションスクリプトを削除しない
指定ディレクトリに触れない
未承認のネットワークコマンドを実行しない

この保護をツール呼び出し前に置く方が、「危険な操作をしないで」とプロンプトに書くより確実です。

2. コンテキスト注入

多くのプロジェクトには固定された背景があります。

技術スタック
コーディング規約
テストコマンド
ブランチ戦略
ディレクトリ構造
禁止事項
生成ファイルの扱い

これらを毎回手動で Claude Code に伝えるのは面倒で、漏れやすいです。Hooks を使えば、セッション開始時やユーザーのプロンプト送信後に必要なコンテキストを自動注入できます。

これは Claude Code にプロジェクト単位の作業マニュアルを渡すようなものです。README や開発ドキュメントを置き換えるものではありませんが、AI がタスクを始める前に正しい状態へ入りやすくなります。

3. 変更後の検証

Claude Code がファイルを変更した後、hook で自動チェックを起動できます。

よくある処理は次のとおりです。

フォーマットを実行する
lint を実行する
単体テストを実行する
型エラーを確認する
生成ファイルをスキャンする
Markdown や JSON の形式を検証する

これは低レベルなミスを減らすのに役立ちます。AI が複数ファイルを変更した場合、変更後に軽量な検証を走らせることで、問題を早めに見つけられます。

ただし、hook に重い処理をデフォルトで入れるのは向きません。ファイル変更のたびに完全なテストスイートを走らせると、体験が遅くなります。より実用的なのは、ファイル種別、ディレクトリ、タスクのリスクに応じてチェック範囲を選ぶことです。

4. チームルールの検証

チームに明確な約束があるなら、その一部を hooks に入れられます。

たとえば：

コミットメッセージ形式
コードスタイルルール
特定の生成ファイルを直接変更しない
ドキュメントを同時に更新する
API 変更ではテストも更新する
特定ディレクトリは指定ツールでのみ生成する

これにより Claude Code は、制約のない外部アシスタントではなく、チームワークフローの一部に近づきます。

もちろん、hooks は CI の代わりではありません。ローカルでの早めの注意や前置ブロックに向いています。最終検証は CI、review、テストシステムに任せるべきです。

5. サブエージェントと専用タスク

README ではサブエージェント関連の内容にも触れています。

この使い方は、複雑なタスクをより専門的なフローに分ける場合に向いています。たとえばメイン会話が要求を理解し、hook や設定が専用のチェック、監査、要約、ドキュメント整理タスクを起動します。

個人ユーザーにとって、最初にやる価値があるのは複雑なエージェント編成ではありません。まずは反復的で明確かつ低リスクな処理を hooks に任せることです。ルールが安定してから、より複雑な自動化を検討すれば十分です。

Statusline と出力スタイル

プロジェクトは statusline と出力スタイルも扱っています。

一見すると体験面の細部ですが、Claude Code を長期的に使う場合には重要です。Statusline は現在のコンテキスト、タスク状態、環境情報、ヒントを表示できます。出力スタイルは Claude Code の回答を自分の作業習慣に合わせやすくします。

毎日同じターミナルで AI と協作するなら、こうした細部は効率に影響します。良い状態表示は誤操作を減らし、現在の会話が正しいプロジェクト、正しいブランチ、正しい環境にいるかを素早く判断できます。

hooks を重くしすぎない

Hooks は強力ですが、何でも詰め込む場所ではありません。

良いルールは次のとおりです。

高頻度の処理は速くする
安全ブロックは明確にする
出力は短くする
失敗理由は読みやすくする
スクリプトはできるだけ単一責務にする
重いチェックは明示コマンドや CI に任せる

毎回 10 秒以上かかる hook は、すぐに無効化したくなります。ブロックルールが曖昧な hook も、Claude Code とユーザーの両方にとって次に何をすべきか分かりにくくなります。

Hooks は、境界が明確な処理に最も向いています。許可または拒否、コンテキスト追加、ログ記録、軽量チェック、次の手順提示などです。

向いているユーザー

たまに Claude Code に小さなコード変更を頼むだけなら、hooks を深く学ぶ必要はまだないかもしれません。

しかし、次のような場合はこのプロジェクトを調べる価値があります。

Claude Code を頻繁に使う
AI に実際のプロジェクトコードをよく変更させる
AI が危険なコマンドを実行しないか不安
チーム規約を AI ワークフローに自動注入したい
変更後に自動チェックを走らせたい
繰り返しの注意を設定に変えたい
より安定した AI コーディングフローを作っている

特に複数人で作業するプロジェクトでは、hooks の意味が大きくなります。チーム経験の一部をスクリプトとして残せるため、各メンバーがその場で AI に注意する必要が減ります。

利用時の注意

第一に、安全系 hook から始めることです。

複雑な自動化よりも、コマンドブロック、パス保護、機密ファイルチェックの方が実装しやすく、すぐにリスクを下げられます。

第二に、プロジェクト単位のルールは慎重にコミットすることです。

.claude/settings.json は、そのリポジトリを使う全員に影響します。コミット前に、通常開発を過度に制限しないこと、自分のマシンにしかないパスに依存しないことを確認した方がよいです。

第三に、hook の出力は簡潔にすることです。

Claude Code はその出力を消費します。長すぎるとコンテキストを汚し、曖昧すぎると次の行動を導けません。必要な判断と次の提案だけを返すのがよいです。

第四に、デバッグしやすく保つことです。

Hooks が増えると、問題は設定、スクリプト、権限、パス、依存関係、Claude Code 本体のどこからでも起こり得ます。明確なログを残すと、後の調査がずっと楽になります。

参考

disler/claude-code-hooks-mastery

最後に

Claude Code Hooks の価値は、「AI に毎回覚えていてほしいルール」を、実際に実行されるフローへ変えることです。

すでに Claude Code を実プロジェクトで使い始めているなら、hooks は「会話できるコーディング助手」から「制約を持つエンジニアリング協作者」へ進むための重要な一歩です。

Claude-Mem：Claude Code にセッションをまたぐ長期記憶を追加する

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem は、Claude Code 向けの永続的な記憶システムです。

解決しようとしている問題は明確です。AI コーディングアシスタントは、新しいセッションを始めるたびに、以前話したアーキテクチャ判断、踏んだ落とし穴、プロジェクトの好み、実装背景を忘れがちです。
長く続くプロジェクトでは、毎回同じ文脈を説明し直すのはかなり無駄です。

Claude-Mem の考え方は、Claude Code の会話内容を記憶として圧縮し、ローカルデータベースとベクトルストアに保存し、あとから検索ツールで取り戻すというものです。

何を解決するのか

Claude Code はコードタスクに強いですが、セッションの文脈には限界があります。

よくある課題は次の通りです。

新しいセッションが過去の作業を知らない
プロジェクトの設計判断を何度も説明する必要がある
以前調査した問題を再び踏みやすい
長期タスクに連続した記憶がない
複数の会話にまたがるプロジェクト知識を蓄積しにくい

Claude-Mem はこれらの問題を中心に設計されています。

単にチャットログを保存するのではありません。会話を検索しやすい記憶断片に圧縮します。後で必要になったとき、意味検索で関連する文脈を取り戻せます。

仕組み

README の設計を見ると、Claude-Mem は主にいくつかの部分で構成されています。

第一の部分は hooks です。

Claude Code の会話フローに接続し、適切なタイミングで会話データを捕捉します。

第二の部分はバックグラウンド worker です。

worker は原始的な会話内容を、より短く、検索しやすい記憶へ処理します。

第三の部分はローカルストレージです。

プロジェクトは構造化メタデータの保存に SQLite を使い、ベクトルインデックスには Chroma を使います。これにより、会話記録の基本情報を保ちながら、意味検索にも対応できます。

第四の部分は mem-search です。

これは Claude Code が使う検索入口です。過去の文脈が必要なとき、関連する記憶を検索できます。

全体の流れは次のように理解できます。

Claude Code のセッションで内容が生まれる
hooks が会話データを捕捉する
worker が非同期に圧縮・整理する
記憶を SQLite と Chroma に書き込む
後のセッションで mem-search によって検索する

どんな場面に向いているか

Claude-Mem は長期プロジェクト向けで、一回きりの小さなタスク向けではありません。

たとえば：

ひとつのリポジトリを何日も開発し続ける
コード構造が複雑で、背景説明が多い
プロジェクト規約、命名習慣、アーキテクチャ選択を覚えてほしい
Claude Code に頻繁にバグ修正、機能追加、文書整理を任せる
AI に「以前なぜこう変更したのか」を覚えてほしい

Claude Code に一行だけ直してもらう程度なら、長期記憶の意味は大きくありません。
しかし Claude Code を長期的な協力者として使うなら、これは役に立ちます。

インストールと起動

README では、インストール方法は直接的です。

1
2

npm install -g claude-mem
claude-mem install

起動には次を使います。

`1`	`claude-mem start`

状態確認：

`1`	`claude-mem status`

停止したい場合：

`1`	`claude-mem stop`

これらのコマンドの目的は、記憶システムを長く動くローカルサービスとして Claude Code のワークフローに接続することです。

`mem-search` の使い方

mem-search は記憶を取り戻すための重要な入口です。

普通の検索を置き換えるものではなく、Claude Code が過去の会話内容を意味で検索できるようにするものです。

たとえば Claude Code に次のようなことを検索させられます。

あるモジュールがなぜそのように設計されたのか
ある Bug を当時どう調査したのか
プロジェクトで合意した命名規則
以前議論した技術的な取捨選択
あるリファクタリングの背景

これは単純なキーワード検索とは違います。
記憶圧縮とベクトルインデックスがうまく機能すれば、正確な言い回しを覚えていなくても、意味的に近い内容を取り戻せます。

普通のプロジェクト文書との違い

プロジェクト文書は、安定した結論を記録するのに向いています。

たとえば：

アーキテクチャ説明
デプロイ手順
API 規約
データベース構造
開発ルール

Claude-Mem は、会話過程で生まれる文脈を記録するのに向いています。

たとえば：

なぜある案が却下されたのか
一時的な問題をどう回避したのか
実装の背後にあった議論
まだ文書化されていないプロジェクトの好み
複数の会話で積み重なったタスク背景

両者は互いの代替ではありません。
安定した知識はプロジェクト文書へ書き、過程的な文脈は記憶システムで検索できるようにするのがよいです。

使うときの注意点

第一に、長期記憶は多ければよいわけではありません。

すべての会話を区別なく保存すると、後の検索がノイズだらけになる可能性があります。価値が高いのは、プロジェクト判断、実装背景、問題調査、長期的な好みです。

第二に、記憶はコードや文書の代わりにはなりません。

AI が見つけた古い文脈は参考にすぎません。最終判断は現在のコード、テスト結果、最新の要求に基づくべきです。

第三に、プライバシーとローカルデータに注意が必要です。

会話内容を保存する以上、どのプロジェクトに接続してよいか、どの機密情報を会話に入れるべきでないかを理解しておく必要があります。

第四に、記憶システムにはメンテナンスが必要です。

プロジェクトが進むにつれて、古い記憶は古くなる可能性があります。古い文脈が誤って使われると、後続タスクを誤導することがあります。

この種のツールが注目に値する理由

AI コーディングツールは、「一回限りの質問応答」から「長期的な協力」へ向かっています。

一回限りの質問応答では、モデルは現在の質問に答えれば十分です。
長期的な協力では、プロジェクト履歴、過去の判断、チームの好み、すでに踏んだ落とし穴を知っている必要があります。

Claude-Mem のようなツールの意味はここにあります。「文脈を覚える」ことを、一時的なチャット能力ではなく、インストールし、実行し、検索できるローカルシステムにします。

実際のエンジニアリングプロジェクトでは、単にモデルのコンテキストウィンドウを長くするより実用的です。
多くの情報は一度に文脈へ詰め込めばよいのではなく、必要なタイミングで取り戻せることが重要だからです。

誰が試すべきか

次のような場合は試す価値があります。

Claude Code を高頻度で使っている
同じプロジェクトを日をまたいで扱うことが多い
プロジェクト文脈が複雑
AI に同じ背景を何度も説明している
会話内の経験を蓄積したい

Claude Code をたまに使うだけ、またはプロジェクトが小さい場合は、まだ必要ないかもしれません。

参考

thedotmack/claude-mem

最後に

Claude-Mem の重点は「チャットログを保存すること」ではなく、Claude Code が後続タスクで有用な文脈を取り戻せるようにすることです。

AI コーディングが一回限りのタスクから長期プロジェクト協力へ移るにつれ、記憶システムはますます重要になります。
文書やテストを置き換えるものではありませんが、繰り返し説明を減らし、AI をプロジェクト履歴を理解した助手に近づけます。

UEFI プログラムのコンパイル入門：uefi-simple から最初の .EFI まで

Thu, 30 Apr 2026 19:53:08 +0800

最初の UEFI プログラムをコンパイルするのは、思ったほど簡単ではありません。環境構築には時間がかかり、リンカーエラーも多く、.EFI プログラムは通常のデスクトップアプリのように直感的に編集して実行できるものではありません。

この記事では、入門者向けに整理します。まず自分の最初の UEFI プログラムをコンパイルしたいだけなら、どこから始めるべきか、どの概念を先に理解すべきか、どこで詰まりやすいかを見ていきます。

UEFI プログラムとは何か

UEFI プログラムは通常、.EFI ファイルです。

Windows でダブルクリックして実行する普通の .exe ではありません。UEFI ファームウェア環境で動作する PE/COFF 実行ファイルです。よくある用途には次のようなものがあります。

ブートマネージャー
ハードウェア初期化ツール
ファームウェア更新ツール
起動前診断ツール
カスタムブートフロー

システム起動の早い段階で見える多くの機能は、UEFI アプリケーション、ドライバー、またはファームウェアサービスと関係している場合があります。

初心者は、最初から完全なファームウェア開発を理解する必要はありません。まずは UEFI Shell またはエミュレーターから読み込める .EFI ファイルをコンパイルすることを目標にします。

最初から EDK II に入らないほうがよい理由

本格的な UEFI 開発では EDK II に出会うことがよくあります。

EDK II は機能が充実しており、実際のファームウェア開発にも近いものです。ただし初心者にはあまり優しくありません。

プロジェクト構造が複雑
ビルドシステムに学習コストがある
環境変数やツールチェーン設定が多い
コンパイルエラーを読み解きにくい
コードを書く前に環境構築で詰まりやすい

目的が「最小の UEFI プログラムをまず動かす」ことであれば、軽量なサンプルから始めるほうが向いています。

pbatard/uefi-simple はそのようなプロジェクトです。目的は明確で、シンプルな UEFI Hello World サンプルを提供し、まず .EFI をコンパイルできるようにすることです。

`uefi-simple` は何に向いているか

uefi-simple は UEFI 入門の最初の足場として向いています。

主に 3 つの問題を解決します。

最小限のコンパイル可能な UEFI アプリケーション構造を提供する
最初から大規模なファームウェア工程に触れる複雑さを避けられる
コンパイル、リンク、実行の流れが通るかを先に確認できる

このプロジェクトは Visual Studio 2022 や MinGW/gcc など複数のビルド方法に対応しており、QEMU と OVMF を使ったテストもできます。

つまり、初期段階から実機を何度も再起動して試す必要はありません。まずエミュレーターで動かすほうが安全です。

入門前に用意するもの

最低限、いくつかの種類のツールが必要です。

1 つ目はコンパイラーツールチェーンです。

Windows では、まず次のどちらかを検討できます。

Visual Studio 2022
または MinGW/gcc

2 つ目は UEFI 実行環境です。

主な選択肢は 2 つあります。

実機の UEFI Shell で .EFI を実行する
QEMU + OVMF を使って仮想環境でテストする

3 つ目はサンプルプロジェクトです。

初心者は空ディレクトリからビルドスクリプトを手書きするより、uefi-simple のような最小サンプルを使うほうが、ビルドシステムで詰まる可能性を減らせます。

大まかな流れ

最小 UEFI プログラムの入門手順は、次のように考えると分かりやすいです。

まず、サンプルプロジェクトを取得します。

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

次に、ビルドツールチェーンを選びます。

Visual Studio を使う場合は、プロジェクト内の Visual Studio ソリューションに従ってビルドします。
MinGW/gcc を使う場合は、プロジェクトが提供する Makefile や説明に従います。

次に、.EFI ファイルを生成します。

ここで重要なのは対象アーキテクチャを確認することです。一般的な PC は通常 x86_64、つまり 64 ビット UEFI 環境です。

次に、UEFI Shell からアクセスできる場所へ .EFI を置きます。

実機を使う場合は、通常 FAT32 パーティションまたは USB メモリを用意します。
QEMU を使う場合は、ディレクトリやディスクイメージをマウントできます。

最後に、UEFI Shell で実行します。

実行結果は通常、Hello World のような最小限の出力です。

詰まりやすいところ

UEFI プログラムのコンパイルで詰まりやすいのは、C 言語そのものではなく、環境とリンクです。

よくある問題は次の通りです。

コンパイラーのアーキテクチャが違う
ターゲット形式が違う
リンカー引数が不足している
UEFI エントリーポイントがない
UEFI が読み込める .EFI ではなく通常の実行ファイルを生成している
QEMU または OVMF の設定ができていない
実機の Secure Boot が未署名プログラムの実行を止める

特にリンカーエラーは、初心者にコードの間違いだと思わせがちです。
実際には、エントリー関数、サブシステム、対象アーキテクチャ、リンクスクリプト設定が原因であることも多いです。

そのため最初の段階では、複雑なロジックに急いで進まないほうがよいです。まず元のサンプルがコンパイルでき、実行できることを確認してから、少しずつ出力内容を変えていきます。

テストに QEMU + OVMF をすすめる理由

実機で UEFI プログラムをテストすることはできますが、初心者の段階ではあまり便利ではありません。

何度も次の流れを繰り返すことになります。

コンパイル
USB メモリへコピー
再起動
UEFI Shell に入る
実行
エラーを記録
OS に戻って修正

このループはかなり遅いです。

QEMU + OVMF を使うと、OS の中で直接 UEFI 環境をシミュレートできます。.EFI が読み込めるかをより速く確認でき、実機のブート項目へ影響を与える可能性も低くなります。

プログラムが基本的に動くようになってから実機で試すほうが安定します。

初心者はまずどこを変えるべきか

サンプルプロジェクトで最初の .EFI をコンパイルできたら、すぐに複雑な機能を書き始めないほうがよいです。

おすすめの順番は次の通りです。

まず出力テキストを変え、再コンパイル後のプログラムが本当に反映されているか確認する。
次に UEFI が提供する簡単な情報を読んでみる。
エントリー関数、出力プロトコル、基本サービスを理解する。
最後にファイルシステム、グラフィック出力、ブート項目管理などの複雑な機能を考える。

この順番なら、各ステップを確認できます。
最初から多くを変えると、問題がコードなのか、ビルドなのか、実行環境なのか判断しにくくなります。

普通の C プログラムとの違い

UEFI プログラムは C で書けますが、通常の C プログラムとは実行環境がまったく違います。

通常の C プログラムは OS 上で動き、標準ライブラリ、ファイルシステム、プロセスモデル、システムコールに依存できます。

UEFI プログラムは OS が起動する前に動作します。利用するのは UEFI ファームウェアが提供するサービスです。通常のプログラムで当たり前に使っているものの多くは、ここでは自然に使えるわけではありません。

そのため UEFI プログラムを書くときは、いくつかの違いに慣れる必要があります。

エントリー関数が違う
出力方法が違う
利用できるライブラリが違う
メモリーやファイルアクセスの方法が違う
デバッグ方法が違う

だからこそ、普通の C プログラムの感覚で直接書くのではなく、最小サンプルから始めるのがおすすめです。

現実的な学習ルート

入門だけなら、次の流れが現実的です。

第 1 步：uefi-simple をコンパイルする
第 2 步：QEMU + OVMF で実行する
第 3 步：Hello World の出力を変更する
第 4 步：UEFI Shell が .EFI をどう読み込むか理解する
第 5 步：UEFI のエントリー関数と基本的な出力プロトコルを学ぶ
第 6 步：その後で EDK II やより完整な UEFI 開発資料を見る

このルートの重要点は、まずフィードバックループを作ることです。

ソースから .EFI を生成し、UEFI 環境で出力を確認できれば、最初の大きな壁は越えています。

参考

最後に

最初の UEFI プログラムをコンパイルするときの難しさは、多くの場合「C コードを書くこと」ではなく、ツールチェーン、リンク形式、実行環境をつなげることにあります。

複雑な機能へ急ぐ必要はありません。
uefi-simple のような最小サンプルから始め、まず実行できる .EFI を得てから、UEFI のエントリーポイント、プロトコル、ビルド方法を少しずつ理解していくほうが楽です。

Claude.md は長ければよいわけではない：AI コーディング用のグローバルメモリファイルの書き方

Wed, 29 Apr 2026 21:07:37 +0800

最近、AI コーディング用のグローバルメモリファイルについての議論を見かけました。プロジェクトに Claude.md や AGENTS.md のようなファイルを追加しても、必ずしも結果がよくなるとは限らず、場合によっては成功率が下がり、推論コストも上がるという話です。

一見すると直感に反します。AI にプロジェクト背景、ルール、説明を多く渡せば、より正確にコードを書けるはずだと思いがちです。
しかし本当の問題は、Claude.md が普通のドキュメントではないことにあります。これは毎回の会話でコンテキストに挿入されるグローバルメモリです。内容が多ければ、モデルは毎回それだけ多く読む必要があります。内容が曖昧なら、毎回余計な判断が増えます。本来入れるべきではない手順を書いてしまうと、関係のないタスクでも不要な動作が発火する可能性があります。

つまり、Claude.md を書く難しさは、内容をすべて書き切ることではありません。どの情報が長期的にコンテキストを占有する価値があるかを判断することです。

Claude.md とは何か

AI コーディングツールにおいて、Claude.md や AGENTS.md のようなファイルは、本質的にはグローバルメモリファイルです。

通常の会話もコンテキストに入りますが、コンテキスト長には上限があります。会話が長くなると、履歴は圧縮され、一部の細部は失われます。グローバルメモリファイルの役割は、重要なルールを固定し、モデルが毎回のタスク開始時に参照できるようにすることです。

これは二つの意味を持ちます。

書いた内容は忘れられにくい
書いた内容は毎回のタスクでコストになる

これは必要なときだけ読まれる README とは違います。長期的に有効な作業制約に近いものです。一度入れると、デフォルトで毎回モデルの判断に影響します。

そのため、Claude.md はプロジェクト紹介でも、経験メモでも、すべての開発手順を詰め込む場所でもありません。モデルが知らないと同じミスを繰り返しやすいルールだけを置くべきです。

なぜ逆効果になることがあるのか

グローバルメモリファイルの書き方が悪いと、主に三つの問題が起きます。

一つ目は、コンテキストを消費することです。

Claude.md が一千行ある場合、その一千行は長期的にモデルのコンテキストに入ります。現在のタスクに本当に関係するコード、エラーメッセージ、要求仕様が圧迫されるかもしれません。コンテキストは無料の空間ではありません。グローバルルールが大きいほど、現在のタスクの焦点は薄まりやすくなります。

二つ目は、余計な行動を誘発することです。

たとえば、グローバルファイルに次のように書いたとします。

1
2

毎回タスクを始める前に、プロジェクトディレクトリを完全に読む。
毎回変更後に、完全なエンドツーエンドテストを実行する。

これらは責任ある指示に見えますが、グローバルメモリに置くと「すべてのタスクで実行する」という意味になります。たとえ一行の文言修正であっても、モデルはこのルールに従って不要な探索やテストを行うかもしれません。結果として、作業は遅くなり、コストは上がり、ときには新しい干渉も生まれます。

三つ目は、判断負荷を増やすことです。

「コードをエレガント、簡潔、保守しやすく、拡張しやすく保つ」のような文は正しく聞こえますが、実際の制約としては弱いです。モデルはコードを生成するたびに、何がエレガントで何が拡張しやすいのかを判断しなければなりません。しかし明確な境界は与えられていません。

よりよい書き方は、抽象的な美徳を並べることではなく、具体的な禁止事項や反例を書くことです。たとえば：

1
2
3

単一の呼び出し箇所のために汎用抽象を追加しない。
テストカバレッジなしで共有パース処理を変更しない。
一時スクリプトをアプリケーションのソースディレクトリに置かない。

これらのルールは具体的で、実行しやすいものです。

何を書くべきか

ある内容を Claude.md に書くべきかどうかは、単純な基準で判断できます。

それを書かないと AI が同じ種類のミスを繰り返すなら、書く価値があります。

グローバルメモリファイルに向いている内容には、だいたい次の特徴があります。

長期的に有効である
現在のリポジトリと強く関係している
コード構造から自然には推測できない
モデルの行動を明確に変える
制約、禁止事項、パス規則、固定コマンドであることが望ましい

たとえば：

すべての Hugo 記事では index.zh-cn.md だけを編集し、他言語版を自動生成しない。
記事の front matter には title/date/draft/tags/categories/slug/description が必須。
public/ 配下の生成物を変更しない。
PowerShell でデプロイするときは scripts/deploy.ps1 を使う。

これらは曖昧な助言ではありません。リポジトリの実際の作業方法に結びついています。モデルが知らなければ間違える可能性があり、知っていれば実際に誤操作を減らせます。

書くべきではないもの

多くの人は Claude.md をプロジェクト説明書にしてしまいがちですが、通常それは不要です。

あまり向いていない内容は次のようなものです。

プロジェクトのビジョンや背景紹介
長いディレクトリ構成説明
一時的なタスク計画
一回限りのデバッグ手順
抽象的なコード品質スローガン
一部の状況でしか必要ない長いワークフロー

たとえば「これは商品、注文、ユーザーモジュールを含む EC プロジェクトです」という説明は、具体的なコーディングタスクにはあまり役立ちません。実際の開発では、モデルは現在の要求、仕様書、コード構造、テストに基づいて判断すべきであり、グローバルメモリ内の粗い紹介に頼るべきではありません。

ディレクトリ構成も同じです。「共有コンポーネントはこのディレクトリからのみ参照する」のような特別な約束がある場合を除き、ツリー全体を書く必要はありません。モデルはプロジェクトディレクトリを自分で読めます。静的な構成説明は古くなりやすいだけです。

手順は skills やコマンドに向いている

ある内容が「第一にこれをする、第二にこれをする、第三にこれをする」という手順なら、それは Claude.md に置くべきではないかもしれません。

長期的なワークフローは、skills、スクリプト、コマンドに分離できます。そうすれば、グローバルメモリには名前と発火条件だけを残し、詳細な手順は必要なときだけ読み込めます。

たとえば：

1
2

ユーザーが Hugo 記事の翻訳を依頼したら、post-translate skill を使う。
ユーザーがサイトのデプロイを依頼したら、hugo-rsync-deploy ワークフローを実行する。

完全な翻訳手順やデプロイ手順を Claude.md に書くより軽くなります。グローバルメモリは短く保ち、具体的な流れは起動可能なツールに任せます。

Claude の最近の初期化フローもこの方向に進んでいます。単に Claude.md を生成するだけでなく、再利用可能なワークフローを skills に、固定イベントを hooks に分けようとします。この変化の背景にある考え方は明確です。グローバルメモリは入口だけを担い、詳細は必要に応じて読み込むべきです。

Claude.md は継続的に改善するもの

Claude.md は一度書いて終わりにすべきではありません。

より現実的なのは、最初は短く保ち、実際のタスクの中で問題を露出させることです。あるミスが一度だけ起きたなら、まず人間が処理すれば十分です。同種のミスが二回以上起きたなら、それはグローバルルールとして残す価値があるかもしれません。

最初から大量のルールを書くより、このような反復のほうが効果的です。初期段階では、どのルールが本当に役立つのか、どの内容がノイズになるのか分かりません。プロジェクトが大きくなり、協業が増え、モデルの挙動が安定してきたら、高頻度の問題を少しずつ追加していけばよいのです。

もう一つ重要な傾向があります。モデルが強くなるほど、グローバルメモリファイルは短くあるべきです。

以前はプロンプトに書く必要があった多くの要求を、今のモデルは自然に処理できます。そうした基本要求を Claude.md に入れ続けると、コンテキスト負荷が増えるだけです。グローバルメモリはモデル能力の向上に合わせて縮小し、このリポジトリ固有で、モデルが自動推測できない内容だけを残すべきです。

より実用的な書き方

Claude.md を書くときは、次の順序で考えるとよいです。

このリポジトリにはどんな特別な約束があるか？
モデルがすでに二回以上犯したミスは何か？
誤用してはいけないディレクトリ、ファイル、コマンドは何か？
どの手順は常駐コンテキストではなく、skills、スクリプト、コマンドにすべきか？
どの内容は単なる紹介で、削除できるか？

最終的なファイルは数十行だけかもしれません。プロジェクト全体を説明する必要はありません。行動を正確に制約することが目的です。

よい Claude.md は、たとえば次のようになります。

# 作業ルール

- 現在のタスクに関係するファイルだけを編集する。
- public/ や resources/ のような生成物ディレクトリを変更しない。
- Hugo 記事の書き換えでは index.zh-cn.md だけを処理し、他言語版を生成しない。
- デプロイが関係する場合は、先に Hugo ビルドを実行し、その後既存の rsync スクリプトを実行する。
- 既存のユーザー変更がある場合は、巻き戻さず、現在の状態を前提に続ける。

短いですが、どの行も実際の行動に影響します。こういう内容こそ、長期的にコンテキストを占有する価値があります。

最後に

Claude.md の価値は、AI に「もっと多くを知ってもらう」ことではありません。AI に「決まったミスを減らしてもらう」ことです。

これは知識ベースでもプロジェクト百科でもありません。AI コーディングにおける長期的な制約ファイルです。
具体的で、短く、実際のミスに近いほど役に立ちます。逆に、汎用的で、長く、プロジェクト紹介のようになるほど、モデルを遅くし、結果を悪化させる可能性が高くなります。

グローバルメモリは無限のメモ帳ではなく、希少な資源として扱う。これが、よい Claude.md を書くためのもっとも重要な原則かもしれません。

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 を通すところまで進めれば、あとはログパス、出力先、ポートを調整していくくらいです。