Codex Skillsの使い方｜繰り返す仕事を手順にする

Codex Skillsは、繰り返す仕事の手順・参照資料・必要な道具をまとめ、呼び出して使うための仕組みです。「会議メモを、根拠付きのタスク表にする」など、一つの完成形から作ると設計しやすくなります。この記事では、保存するファイル、呼び出す依頼文、期待する出力、失敗を見つけるテストまで、同じ題材でつなげます。

設定の仕様は2026年10月10日に公式資料で確認しました。会議・人物・数値は編集部が作成した架空の教材です。掲載する期待結果は採点用の見本であり、Codexの実行結果や成功率を示すものではありません。

Skillsにする仕事・しない仕事

Skillを作る前に、「どの入力を受け取り、何を返したら完了か」を一文で言えるか確認します。「営業を支援する」では範囲が広すぎます。「商談メモから、顧客の要望・未確認事項・次回までのタスクをMarkdownに整理する」なら、入力も完成物も確認できます。

再利用するのは、毎回の答えそのものではありません。判断の順番、参照する資料、必須の出力項目、確認方法です。同じSkillでも入力やモデル、使えるツールが変われば結果は変わるため、「置けば同品質になる」という前提で運用しないことが大切です。

Skillの最小構成と保存先

公式の最小構成は、nameとdescriptionを含むSKILL.mdです。ローカルのプロジェクトでは.agents/skills/、個人共通では~/.agents/skills/が探索先に含まれます。プロジェクト用は作業場所からリポジトリのルートまでが対象です。公式：Skillsの構成と探索先

この教材では、一つの練習プロジェクト内に置きます。エディタで次のフォルダを作ってください。先頭のドットでフォルダが隠れる環境では、エディタのファイル一覧から作成すると場所を確認しやすくなります。

meeting-practice/
  .agents/
    skills/
      meeting-to-actions/
        SKILL.md
        references/
          output-example.md
  samples/
    normal.md
    missing.md
    conflict.md
    not-a-meeting.md
  expected/
    normal.md
    acceptance.md
  drafts/

references/output-example.mdは完成形の見本、samples/は入力、expected/は採点条件、drafts/はCodexが成果物を保存する場所です。入力と生成物を分けると、元の会議メモを上書きしていないかも確認できます。

古い解説や配布版には異なる保存先が登場する場合があります。認識されないときは同じSkillを何か所にも複製するより、使用中のCodexのバージョンと公式案内を照合し、その環境で一覧に出る場所を確かめてください。同名Skillが複数あると、どの定義を試したか分からなくなります。

コピーして作れるSKILL.md：会議メモから行動へ

以下を.agents/skills/meeting-to-actions/SKILL.mdとして保存します。手順の途中に判断条件を入れ、最後に自分で照合すべき内容を指定しています。

---
name: meeting-to-actions
description: 会議メモから決定事項、担当付きタスク、未決事項を根拠付きで整理するときに使う。一般文の要約やメール送信には使わない。
---
# 会議メモを次の行動へ整理する

## 入力
- ユーザーが指定した会議メモだけを対象にする。
- 会議日と本文を読む。日付・担当・期限を推測で補わない。
- 会議メモがない場合は、必要な入力を伝えて終了する。

## 手順
1. references/output-example.md で出力の構成を確認する。
2. 決定済みの内容、実施するタスク、未決の提案を分ける。
3. タスクを「内容・担当・期限・根拠」の表にする。
4. 担当や期限が本文にない場合は「未定」とする。
5. 情報が矛盾する場合は一方を採用せず、両方の記述を
   「要確認」に残す。担当・期限を確定扱いにしない。
6. 期限の年や基準日が不明なら、日付を勝手に補完しない。
7. ユーザー指定の drafts/ 内にMarkdownを保存する。
   既存ファイルがある場合は内容を確認し、上書きの可否を確かめる。

## 完了の確認
- タスクの各行を入力の記述へ照合する。
- 提案を決定事項に混ぜていないか確認する。
- 担当・期限の不足と矛盾を別々に記載する。
- 保存したファイルを読み直し、保存先と要確認点を報告する。

## このSkillの範囲
- 入力ファイルを変更しない。
- メール送信、カレンダー登録、外部サービスへの更新は行わない。

この例のポイントは「正確に整理する」という希望を、照合可能な動作に分解したことです。たとえば「担当者を捏造しない」だけで終えず、担当が書かれていない場合はどの文字を出すかまで決めています。これなら、出力の担当欄に架空の名前が入ったときに失敗と判定できます。

descriptionは、使う依頼と使わない依頼を区別する

本文の手順を丁寧に書いても、適切な場面で選ばれなければ使われません。説明文には、入力と目的が分かる具体語を入れます。ただし、キーワードを大量に並べればよいわけではありません。

除外条件は、実際に混同した作業に絞って追加します。あらゆる禁止事項を並べると、読みやすさが落ち、何をするSkillなのかが見えにくくなります。

CLIで呼び出し、完成ファイルまで確認する

練習フォルダを作業場所としてCodexを開き、入力欄で/skillsを使うか、$からSkillを選択します。CLI・IDEでは名前による明示呼び出しができます。まず名前を指定して、読み込まれるかと結果を分けて確認しましょう。公式：Skillの呼び出し方

$meeting-to-actions を使って、samples/normal.md を整理してください。
出力先は drafts/normal-actions.md です。
保存後に元メモと照合し、未定や要確認が残る項目も報告してください。

samples/normal.mdには、次の架空メモを保存します。

# 商品ページ改善会議
会議日：2026年10月7日

商品ページの見出しは「初めてでも、ここから始められる」に決定。
佐藤が2026年10月10日までに、商品ページの文言を直す。
画像の差し替えも実施する。ただし担当と締切は未定。
価格の変更は提案段階で、今回は決めていない。

完成形の見本は次のとおりです。根拠欄は元の記述との対応を読者が追える長さにします。元メモを丸ごと複製する必要はありません。

決定事項には見出しの採用、未決事項には価格変更を記載します。「価格を変更する」というタスクが確定事項として追加された場合は、この教材では不合格です。文章が自然でも、会議で決まっていないことを決定に変えてはいけません。

最後はチャットの「保存しました」だけで終えず、drafts/normal-actions.mdをエディタで開きます。ファイルの存在、表の内容、未決事項の有無、入力が変更されていないことを確認してください。画面に表が表示されたことと、指定先に保存できたことは別の確認項目です。

4種類の入力で、失敗の境界を確かめる

正常な会議メモだけを試すと、Skillの弱い部分が見えません。この教材では、情報不足・矛盾・対象外を加えた4種類を用意しました。これは編集部の練習設計です。公式の評価ガイドも、呼び出しと成果物を観測し、期待条件で比較する進め方を説明しています。公式：Skillsを評価する考え方

矛盾の練習には、たとえば「初稿は佐藤が10月12日までに作成」「初稿の担当は田中、期限は10月14日」とだけ書いたメモを使います。変更決定の記録がないため、どちらが有効かは確定できません。古い行と新しい行の関係が分かる場合だけ、その証拠に基づいて整理します。

もう一つ確認したいのが、名前を指定しない場合の選択です。「この会議メモから担当付きのタスク表を作って」と依頼する場合と、「商品の紹介文を短くして」と依頼する場合を分けて試します。後者で会議整理Skillが使われるなら、説明文や対象範囲を見直します。

結果を記録する最小シート

検証日：
Codexのバージョン／利用画面：
Skillの版または変更内容：
入力ファイル：
明示呼び出し／名前なしの依頼：
Skillが選択された根拠：
出力ファイル：
担当と期限の照合：合格／不合格／未確認
未決事項の扱い：合格／不合格／未確認
入力の保全：合格／不合格／未確認
今回見つかった失敗：

一度の成功で安定性を証明したことにはなりません。まず同じ入力を残し、Skillを変更したときに再度比較できる状態を作ります。繰り返しの頻度や検証件数は、間違えたときの影響に合わせて決めてください。

動かないときは、問題が起きた場所から直す

変更が反映されない場合は、新しいセッションでも確認します。それでも一覧に現れないなら、説明文を書き足し続けるより、ファイルの場所や構文を調べる方が先です。反対に、Skillが確実に選ばれているのに担当を補完してしまうなら、探索先を変えても成果物の問題は解決しません。

修正は一度に一つの原因へ絞ります。保存先、説明文、出力形式を同時に変えると、どの変更で改善したか判断しにくくなります。変更前のSkillと同じ入力を保存しておけば、戻す判断もしやすくなります。

references・scripts・assetsを増やす判断

最初からすべてのフォルダを作る必要はありません。会議メモ整理なら、手順と出力例だけで試せます。部品を増やすのは、繰り返し発生する問題が見つかってからで十分です。

• references：用語集、分類基準、出力見本。どの工程でどの資料を読むかをSKILL.mdから示します。
• scripts：毎回同じ計算や形式チェックを行う処理。動作に必要な実行環境、入力、出力、失敗時の扱いを一緒に記載します。
• assets：成果物に使うテンプレートや画像など。参照文書と混ぜず、何のためのファイルかが分かる名前にします。

たとえばタスクの件数を数えるだけなら短い処理で固定できますが、「価格変更が決定されたか」は文章の意味の判断です。すべてをスクリプトに置き換える必要はなく、固定できる処理と判断が必要な処理を分けます。外部ツールに依存する場合は、使えないときに何を未完了として返すかも決めてください。

AGENTS.md・Skills・MCP・プラグインの使い分け

この会議整理の教材はローカルファイルを読むため、外部サービスへの接続は前提にしていません。Skillを作るために必ずMCPを設定する、という順番ではありません。必要になった時点で、MCPの設定と確認方法へ進めます。共通ルールの整理はAGENTS.mdの書き方で詳しく説明しています。

チームで使うときは、手順と検証入力を一緒に渡す

SKILL.mdだけを共有すると、受け取った人が何を試せばよいか分かりません。少なくとも、架空の入力例、期待結果、必要な実行環境、既知の制限を一緒に渡します。実案件の会議メモをそのまま教材にせず、個人情報や社内の未公開情報を除いた練習用データを作ってください。

更新時には「文章を改善した」ではなく、「担当未定を参加者名で埋める失敗に対し、根拠照合の工程を追加した」のように理由を記録します。追加したルールがどの失敗を防ぐのか分かれば、不要になった指示も整理できます。

チーム内で同じ名前の異なる版を配らないことも大切です。管理するフォルダと更新担当を決め、以前の入力で比較してから切り替えます。読み込めたか、結果が要件を満たしたか、実際の業務に使ってよいかは、それぞれ別の確認として扱いましょう。

よくある質問

スクリプトを書けないと作れませんか？

この教材はMarkdownの手順と見本から始められます。一定の計算やファイル変換を繰り返し、文章の指示だけでは確認しにくくなったところで補助処理を検討してください。

長く書くほど高品質になりますか？

長さより、入力・判断・完成形・確認方法が具体的であることが重要です。同じ指示の言い換えを増やすより、失敗した入力を一つ残し、その原因に対応する条件を加える方が改善を確認しやすくなります。

Skillに許可を書けば、ツールの制限も解除できますか？

できません。手順書に操作を記載しても、その環境で利用できる権限や接続が増えるわけではありません。接続できない操作や、承認が必要な操作は、その状態を成果物と分けて報告するよう設計します。

他のAIツールにもそのまま渡せますか？

手順や見本は再利用できますが、保存先、呼び出し方、固有設定、利用可能なツールは受け取り側で確認が必要です。移した先でも同じ練習入力と期待結果を使い、動作を確かめてください。