Skills on KnightLiブログ

主流AI PPTツール総まとめ：自動生成、Webスライド、PPTX、画像ルートをどう選ぶか

Mon, 18 May 2026 22:29:43 +0800

AIでPPTを作ることは、もはや「タイトルを入力してテンプレートを当てる」だけではありません。Claude Code、Codex、CursorのようなAIコーディング環境では、PPT生成はインストール可能で再利用できるAgent Skillの集まりになりつつあります。Webプレゼンを出力するもの、実際に編集可能な .pptx を生成するもの、画像モデルで各ページをビジュアル案として作るもの、MCPを通じてAIにPowerPointファイルを操作させるものがあります。

今回は、主流のPPT関連Skillを整理します。価値があるのは単なる一覧ではなく、これらのツールを納品形態ごとに分けて考えることです。ツールを選ぶ前に、まずこう問いましょう。最終成果物は誰が編集するのか、どこで発表するのか、継続的な共同作業が必要なのか。

いくつかのルート

1. HTML Webプレゼン

代表的なプロジェクトには、frontend-slides、guizang-ppt-skill、html-ppt-skill があります。

このルートの強みは視覚表現力です。CSSアニメーション、Canvas、WebGL、レスポンシブレイアウトを使え、ブラウザで開くだけで発表できます。技術共有、製品発表、Demo Day、個人のスタイルが強い登壇に向いています。

一方で代償も明確です。納品後にクライアントが一文字ずつ修正する用途にはあまり向きません。クライアントが受け取るものがPowerPointファイルではなくHTMLの場合、後続の修正は生成フローに戻ることが多くなります。

HTMLプレゼンだけを見るなら、frontend-slides は高スターの汎用入口に近く、guizang-ppt-skill は美的制約とテーマ性に強く、html-ppt-skill はテーマ数、レイアウト数、発表者モードで優れています。

2. ネイティブPPTX

代表的なプロジェクトには、mckinsey-pptx、ppt-agent-skills、claude-office-skills、ppt-master があります。

これはビジネス納品で最も安定したルートです。クライアントが「PowerPointで文字を直したい、画像を差し替えたい、会社テンプレートを使いたい」と求めるなら、最終的には .pptx に落とす必要があります。

その中でも ppt-master は個別に注目する価値があります。考え方は、まずLLMにSVGを生成させ、それをPowerPointネイティブのDrawingMLオブジェクトへ変換するというものです。目的は、テキストボックス、図形、チャートをPPTX内で引き続き編集できるようにすることです。PDF、DOCX、URL、MarkdownからのPPTX生成にも対応し、テンプレート複製、アニメーション、ナレーション、ローカルプレビューも扱えます。

このルートは、コンサルティング納品、社内報告、ホワイトペーパー発表、長いレポートのPPT化に向いています。欠点は、視覚表現の上限がPowerPoint自体に制約されやすく、複雑な表現ではHTMLや画像ルートほど自由ではないことです。

3. AI画像駆動

代表的なプロジェクトには、NanoBanana-PPT-Skills、gpt_image_2_skill、ppt-image-first があります。

このルートは各スライドをまず1枚のビジュアルとして生成し、その画像をPPTXや別のコンテナに入れます。完成度が高く、特に表紙、SNS画像、ビジュアル提案、拡散向けコンテンツに向いています。

問題は編集性の低さです。ページは本質的に1枚の画像です。あとからタイトルを直す、文案を差し替える、アイコンを動かすとなると、再生成が必要になる場合があります。「見た目をよくしたい」用途には合いますが、「クライアントが何度も修正する」用途には向きません。

4. MCP / プロトコル層

代表的なプロジェクトには、Office-PowerPoint-MCP-Server、PPTAgent があります。

この種のツールは、必ずしも完全なPPTを直接生成するわけではありません。AIにPowerPointを操作するインターフェースを与えます。MCPに接続すると、モデルは .pptx ファイルを読み、修正し、書き込めます。

このルートは、すでにPPTファイルがあり、AIに修正を手伝わせたいワークフローに向いています。たとえば、書式の一括変更、フィードバックに基づくページの並べ替え、各ページが目的に合っているかのチェックなどです。PPTAgent は反省型生成を重視しています。つまり、各ページを生成したあとに見直します。この方向性は「AI PPTが粗い」問題を減らすヒントになります。

5. 統合デザインプラットフォーム

代表的なプロジェクトには、open-design、docsagent があります。

この種のプロジェクトは、PPT生成そのものを超えています。open-design はローカル優先のデザインプラットフォームに近く、プロトタイプ、slides、images、videosを生成でき、複数のエクスポート形式に対応します。docsagent はPPTツールではありませんが、ローカル文書をインデックス化して対話できるため、PPT生成前の資料整理層として使えます。

単発でPPTを作るだけでなく、資料、デザイン、プロトタイプ、納品までの一連の流れが必要なら、このタイプのプラットフォームはより見る価値があります。

Skillメタ情報

Star数は2026-05-15時点の取得結果に基づくもので、人気度の参考にすぎません。実際に使う前には、リポジトリを開いてメンテナンス状況、README、LICENSEを確認することをおすすめします。

Skill	作者	リンク	Star	言語	ルート
frontend-slides	@zarazhangrui	GitHub: zarazhangrui/frontend-slides	17,530	Shell	HTML Webプレゼン
guizang-ppt-skill	@op7418（歸藏）	サイト内記事: guizang-ppt-skill GitHub: op7418/guizang-ppt-skill	8,832	HTML	HTML Webプレゼン
html-ppt-skill	@lewislulu	GitHub: lewislulu/html-ppt-skill	3,834	HTML/CSS/JS	HTML Webプレゼン
mckinsey-pptx	@seulee26	GitHub: seulee26/mckinsey-pptx	426	Python	ネイティブPPTX
ppt-agent-skills	@sunbigfly	GitHub: sunbigfly/ppt-agent-skills	714	Python	ネイティブPPTX
claude-office-skills	@tfriedel	GitHub: tfriedel/claude-office-skills	631	Python	ネイティブPPTX
ppt-master	@hugohe3	GitHub: hugohe3/ppt-master	16,626	Python	ネイティブPPTX
NanoBanana-PPT-Skills	@op7418（歸藏）	GitHub: op7418/NanoBanana-PPT-Skills	2,668	Python	AI画像駆動
gpt_image_2_skill	@wuyoscar	GitHub: wuyoscar/gpt_image_2_skill	2,102	Python	AI画像駆動
ppt-image-first	@NyxTides	GitHub: NyxTides/ppt-image-first	799	Python	AI画像駆動
Office-PowerPoint-MCP-Server	@GongRzhe	GitHub: GongRzhe/Office-PowerPoint-MCP-Server	1,708	Python	MCP / プロトコル層
PPTAgent	@icip-cas	GitHub: icip-cas/PPTAgent	4,354	Python	MCP / プロトコル層
open-design	@nexu-io	サイト内記事: open-design GitHub: nexu-io/open-design	40,822	TypeScript	統合デザインプラットフォーム
docsagent	@docsagent	GitHub: docsagent/docsagent	687	TypeScript	統合デザインプラットフォーム

選び方

クライアントが継続して編集するなら、ネイティブPPTXルートを優先します。特に ppt-master、mckinsey-pptx、ppt-agent-skills です。

自分で発表し、後続編集より視覚表現を重視するなら、HTMLルートを優先します。特に frontend-slides、guizang-ppt-skill、html-ppt-skill です。

ポスター感、表紙感、拡散用ビジュアルが目的なら、画像ルートを優先します。たとえば ppt-image-first、gpt_image_2_skill、NanoBanana-PPT-Skills です。

すでにPPTファイルがあり、AIに読み取り、修正、再配置を手伝わせたいだけなら、MCPルートを見るとよいでしょう。

学術、マーケティング、翻訳、長いレポートの圧縮といった明確な場面では、汎用PPT生成器に無理をさせるのではなく、垂直Skillを探すのもよい選択です。

最後に注意したいこと

オープンソースプロジェクトはStarだけで判断できません。実際に使う前に、次の3点を確認してください。

LICENSEが自分の利用方法を許可しているか。
生成物が納品要件を満たすか。特に編集性。
モデル呼び出し、画像生成、大きなコンテキストモデル、クラウドサービス費用を含めて、コストが許容できるか。

この種のツールは変化が速く、Star数もメンテナンス状況も変わります。それでも選定ロジックは比較的安定しています。まず納品形態を決め、それから具体的なツールを見ることです。PPTが「話すため」なのか、「編集してもらうため」なのか、「見てもらうため」なのか。この3つの答えだけで、選択肢はかなり絞れます。

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

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 として書くことは、一度きりの説明を再利用可能な作業基盤に変えることでもあります。

CC Switch：Claude Code、Codex、Gemini CLI、OpenClawを一元管理するデスクトップツール

Wed, 06 May 2026 09:03:08 +0800

CC Switch は、AIコーディングを日常的に深く使うユーザー向けのデスクトップ管理ツールだ。解決しようとしている問題ははっきりしている。いま多くの人が Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw を同時に使っているが、それぞれ設定形式、Providerの書き方、MCP設定、Skills管理の方法が違う。

1つのツールだけを使うなら、手作業で設定を変えるのもまだ我慢できる。しかし複数のツールを混在させ、そこに公式アカウント、サードパーティAPI、リレーサービス、ローカルモデル、チーム共有設定まで加わると、JSON、TOML、.env を手で編集する作業はすぐに面倒になる。

CC Switch の位置づけは、こうした分散した設定を1つのクロスプラットフォームなデスクトップアプリに集約することだ。

何を解決するのか

現代のAIコーディングツールは、「コマンドラインの中にいる開発仲間」のようになりつつある。ただし、各ツールのエコシステムはまだ完全には統一されていない。

よくある課題は次の通りだ。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawで設定形式が異なる。
API Providerを切り替えるたびに、設定ファイルを何度も変更する必要がある。
MCP serverを複数ツールで重複して設定しがちになる。
CLAUDE.md、AGENTS.md、GEMINI.md のようなプロンプトファイルを統一して保守しにくい。
Skillsのインストール、同期、バックアップ、削除に集中管理の入口がない。
複数アカウント、複数relay、複数モデルサービスの切り替えが混乱しやすい。
設定ファイルを手作業で壊した場合、原因調査のコストが高い。

CC Switch の考え方は、ユーザーに各ツールの設定細部を覚えさせるのではなく、Provider、MCP、Prompts、Skills、Sessions、プロキシを1つの統一画面で管理するというものだ。

対応ツール

READMEに挙げられている主な対応対象は5種類ある。

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

これらのツールは、AIコーディング、Agentワークフロー、コマンドライン上の協働という点で近い位置づけにある。ただし設定体系は異なっており、CC Switch の価値はその違いを包み込むところにある。

複数のAIコーディングツールをよく比較する人にとっては、毎回設定ファイルを手で開くよりかなり楽になる。

Provider管理

CC Switch の第一の機能はProvider管理だ。

50以上のProviderプリセットを内蔵しており、READMEではAWS Bedrock、NVIDIA NIM、各種コミュニティrelayなどが挙げられている。ユーザーはAPI keyをコピーしてワンクリックでインポートし、画面上で切り替えられる。

実用的なポイントは次の通りだ。

Providerをワンクリックで追加できる。
Providerをドラッグで並べ替えられる。
システムトレイから素早く切り替えられる。
Providerのインポートとエクスポートに対応する。
一部の共通Providerは複数アプリへ同期できる。

多くの人にとって、この機能だけでも十分に魅力がある。AIコーディングツールの日常利用で問題になるのは、「モデルを使えない」ことではなく、「今日このkeyをどのツール、どのendpoint、どのアカウントで使うのか」が混乱することだからだ。

ローカルプロキシとフェイルオーバー

設定ファイルを書き換えるだけでなく、CC Switch はローカルプロキシモードも提供する。

この機能の要点は次の通りだ。

Providerのホットスイッチ。
フォーマット変換。
自動フェイルオーバー。
サーキットブレーカー。
Providerのヘルスチェック。
リクエスト補正。

簡単に言えば、対象ツールに設定を書き込むだけでなく、間にローカルプロキシ層を挟み、異なるツールがそのプロキシ経由でモデルサービスにアクセスできるようにする。

これは複数Providerを使うユーザーにとって便利だ。あるサービスが落ちたら別のものへ切り替える。あるモデルが高ければ安いものに変える。リクエスト形式が合わない場合も、プロキシ層で適配できる。

MCP、Prompts、Skills

CC Switch の重要な第二層の機能は、MCP、Prompts、Skillsの一元管理だ。

MCP

複数アプリ間でMCP serverを管理できる統一MCPパネルを提供し、双方向同期とDeep Linkインポートにも対応する。

これはMCPを使っているユーザーにはかなり実用的だ。MCP serverが増えるほど、設定は複数のクライアントに散らばりやすい。統一パネルがあれば、重複設定を減らし、移行もしやすくなる。

Prompts

Prompts部分はMarkdown編集に対応し、異なるツール間で対応するファイルを同期できる。例えば次のようなファイルだ。

CLAUDE.md
AGENTS.md
GEMINI.md

これらは本質的にはAgent向けのプロジェクト説明書だ。一元管理できれば、チームルール、プロジェクトの約束事、グローバルプロンプトをより保守しやすくなる。

Skills

SkillsはGitHubリポジトリやZIPファイルからワンクリックでインストールできる。カスタムリポジトリ管理、シンボリックリンク、ファイルコピーにも対応する。

Claude Code、Codex、OpenClawのようなツールを同時に使う場合、Skillsは複数ディレクトリに散らばったファイル群になりやすい。CC Switch はそれらを集約し、保守コストを下げる。

セッションとワークスペース

READMEではSession ManagerとWorkspace関連の機能にも触れられている。

複数アプリ内のセッション履歴を閲覧、検索、復元できる。AIコーディングツールを長期的に使う人にとって、セッション管理はかなり重要だ。価値のある文脈、デバッグ過程、案の比較が、古い会話の中に埋もれていることが多いからだ。

さらにOpenClaw向けにWorkspace editorも提供し、AGENTS.md、SOUL.md などのagentファイルを編集でき、Markdownプレビューも備える。

これは CC Switch が単なる「key切り替えツール」ではなく、AI Agentワークステーションの方向へ拡張していることを示している。

クラウド同期とデータ保存

CC Switch はDropbox、OneDrive、iCloud、NAS、WebDAV経由でProviderデータを同期できる。

ローカルのデータ保存場所も明確だ。

データベース：~/.cc-switch/cc-switch.db
ローカル設定：~/.cc-switch/settings.json
自動バックアップ：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skillバックアップ：~/.cc-switch/skill-backups/

主要データソースとしてSQLiteを使い、原子的な書き込みと自動バックアップを重視している。目的は、切り替えや書き込みの際に設定ファイルが壊れることを避けることだ。

この設計はヘビーユーザーにとって重要だ。設定管理ツール自体が設定を書き壊した場合、影響を受けるのはすべてのAIコーディングツールだからだ。

インストール方法

CC Switch はTauri 2ベースのクロスプラットフォームデスクトップアプリだ。

おおよそのシステム要件は次の通り。

Windows：Windows 10以降
macOS：macOS 12 Monterey以降
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+などの主要ディストリビューション

Windowsユーザーは .msi インストーラーまたはポータブル版の圧縮パッケージをダウンロードできる。

macOSユーザーはHomebrewでインストールできる。

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新は次の通り。

`1`	`brew upgrade --cask cc-switch`

Linuxユーザーは .deb、.rpm、AppImageを選べる。Arch Linuxユーザーは paru -S cc-switch-bin でもインストールできる。

2026年5月6日時点で、リポジトリページに表示されている最新releaseは CC Switch v3.14.1 で、公開日は2026年4月23日だ。

技術スタック

リポジトリ構成を見ると、CC Switch は典型的なTauriデスクトップアプリだ。

フロントエンド：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
バックエンド：Tauri 2、Rust、SQLite、Tokio
テスト：Vitest、MSW、Testing Library

主な設計パターンは次の通り。

SQLiteをSingle Source of Truthとして使う。
デバイス単位のローカル設定はJSONで保存する。
切り替え時に対象ツールのlive configへ書き込む。
現在のProviderを編集する際はlive configから回填する。
一時ファイルとrenameを使って原子的に書き込む。
データベース接続をロックし、並行書き込み問題を避ける。

この構成から、プロジェクトは単なるスクリプトではなく、長期利用を前提にしたデスクトップツールとして設計されていることがわかる。

誰に向いているか

CC Switch が向いているのは次のようなユーザーだ。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawを同時に使う。
公式アカウント、サードパーティrelay、ローカルモデル、チームProviderを頻繁に切り替える。
すでにMCPを多用し始めている。
CLAUDE.md、AGENTS.md、GEMINI.md を統一して保守したい。
Skillsを頻繁にインストール、テスト、移行する。
複数ツールのセッション履歴や利用状況を見たい。

もしAIコーディングツールを1つだけ使い、常に公式ログインで、Provider、MCP、Skillsをあまり触らないなら、価値はそれほど明確ではないかもしれない。

しかしすでに「複数ツール、複数アカウント、複数Provider、複数プロジェクト」の状態に入っているなら、細かな設定作業をかなり減らせる。

注意点

この種のツールは便利だが、境界も意識する必要がある。

第一に、複数のAI CLI設定を管理するため、このツールとその書き込みロジックを信頼できるか確認する必要がある。

第二に、API key、relay endpoint、MCP serverはいずれも機微な設定だ。クラウド同期を有効にする前に、同期先ディレクトリやWebDAVサービス自体が安全で信頼できるか確認したい。

第三に、Providerを切り替えた後、多くのツールでは変更を反映するためにターミナルやCLIの再起動が必要になる。READMEでは、Claude CodeはProviderデータのホットスイッチに対応するとされているが、他のツールでは通常再起動が必要だ。

第四に、公式ログインへ戻す場合は、プロジェクト説明に沿ってofficial providerを追加し、対応するツールのログインフローを改めて実行するのがよい。

まとめ

CC Switch の価値は、また別のAIコーディングツールを作ったことではない。AIコーディングのエコシステムが、すでに複数ツール共存の段階に入ったという現実を認めている点にある。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClawにはそれぞれ独自の設定システムがあり、MCP、Skills、Prompts、Providerも急速に広がっている。設定を手作業で変え続けるやり方は、いずれ負担になる。

CC Switch はこれらを1つのデスクトップアプリに集約し、Providerの切り替え、MCPの同期、Skillsの管理、プロンプトファイルの保守、セッション確認をより簡単にする。AIコーディングを重く使う人にとって、この種のツールは「任意の小道具」から「日常の基盤」へ変わっていく可能性が高い。

参考資料

farion1231/cc-switch

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 は、コードを書く助手から、長期的に協力できるエンジニアリングツールへ近づく。

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 を制約し、エンジニアの制御を保ち、フィードバック品質を高める重要な道具になります。

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 を書き、新しいセッションを開くのが基本