第１ Skillsでできることを整理する
Claude CodeのSkills（スキル）は，繰り返し使う作業手順をファイルにまとめ，必要な場面で参照させる仕組みである。
法律事務所では，便利な指示文の収集から始めるより，何を入力し，どの資料まで読み，何を成果物とし，どこで止めるかを決めることが役立つ。
本記事では，公開資料の調査メモ，書面の点検及びブログ更新を例に，手順書を作る考え方を説明する。
機能の説明はAnthropic社の公式資料に基づき，業務への当てはめは本記事の提案として示す。
以下の例は，各事務所で動作確認済みの配布用スキルではない。
製品仕様の確認日は令和８年１０月２６日である。
１ 毎回の説明を，必要なときに読む手順へ移す
公式資料では，スキルの中心となるファイルはSKILL.mdであり，説明，手順及び必要に応じた補助ファイルを持たせることができる。
名前と説明から候補が見つかり，必要になったときに本文や追加資料が読み込まれる。
よく使う作業であれば，毎回長い指示を貼る代わりに，共通の手順と今回の対象を分けられる。
例えば「判例を調べて」という一文だけでは，判例の実在確認，本文の読取り，評釈の整理及び記事への引用が一緒になりやすい。
「判決本文の取得と読取りが済んでいなければ，解説だけから判旨を書かない」という手順を共通化し，今回の争点と対象期間を個別に指定する方法が考えられる。
スキルの自動選択だけに頼る必要はない。
公式資料は，利用者による呼出しが有効なスキルについて，スラッシュコマンドによる呼出しも案内している。
まず作業名を明示して呼び出し，読ませる資料と成果物を人が確認する形から試すと，対象を絞りやすい。
２ スキル，CLAUDE.md及びメモリを使い分ける
全ての作業に共通する方針はCLAUDE.md，特定の作業に必要な手順はスキル，作業中に得た継続的な知見はメモリというように，役割を分けて整理できる。
ただし，ファイルに書いたことが必ず実行されるわけではない。
公式資料も，指示から外れる場合には手順の見直しや，必要に応じたフックの利用を案内している。
「必ず原文を確認する」と書くことと，原文の取得記録がなければ後段へ進めない仕組みを置くことは異なる。
説明の仕方は手順書にまとめ，例外なく守る必要がある条件は，権限設定，検査処理及び人の承認も組み合わせて確かめる。
手順書を長くすれば安全性が比例して高まるわけではない。
Claude Codeの公式資料では，CLAUDE.mdはセッション開始時に全文が読み込まれ，Skillsは通常，名前と説明が先に読み込まれ，本文は利用時に読み込まれると説明されている。
全作業に必要な短い規則，特定作業だけの手順及び必要時だけ読む参考資料を分け，重複した説明を複数のスキルへコピーしない方が，確認対象とコンテキスト負担を管理しやすい。
ログ上の総入力を読むときは，通常の入力，キャッシュ作成入力及びキャッシュ読出し入力を区別する。
AnthropicのAPI料金資料はこれらを別の使用量として示しており，論理上読み込まれた入力総量と，通常入力と同じ単価で課金される量は同じとは限らない。
ただし，APIの料金項目をClaude Code Desktopの利用枠又は請求へそのまま当てはめず，利用している契約と画面の公式説明を確認する。
別のPCにも同名のスキルが存在することだけでは，今回のセッション中に同期が行われた証拠にならない。
同期の有無は，現在のPCの指示，Gitの作業コピー，定期同期タスク及びその実行ログから，正本，実行時刻及び反映されたコミットを確認する。
スキル本文には特定PCの利用者パスを固定せず，正本を確定する確認手順を置く。
Windows PCからMacBookへ移す場合は，スキルのファイルだけでなく，Windowsのドライブ文字，利用者名を含む絶対パス，PowerShellコマンド，MCPの実行ファイル及び認証をMac向けに点検する。
同名ファイルの複写と，MacBook上で実際に読み込まれ実行できることの確認は別である。
具体的な移行手順は，Codex・Claude CodeをWindows PCからMacBookへ移行する方法―設定，スキル，認証及び会話履歴を参照されたい。
作業途中の案件を別のAIへ渡すときは，継続して使う指示や知見と，その案件だけの進行状況を分ける。
例えば，判例の引用で意見の帰属を確認する手順はスキルに置き，今回の原稿の版，取得済みの資料及び未確認の引用箇所は案件の再開メモに残す。
受け手には，案件の再開メモと原稿の版を指定し，必要な原資料も確認させる。
書式と再開の例は，Claude CodeとCodexで作業を引き継ぐ方法を参照されたい。
３ スキルが増えたときは入口と本文を分けて見直す
OpenAIの公式資料では，スキルの名前と説明が先にモデルへ示され，依頼に合う場合にSKILL.mdが読み込まれる。
また，スキルが多い場合や説明が長い場合には一覧が短縮されることがあり，説明の重複は関係の薄いスキルの読込みにつながると説明されている。
Anthropicの公式資料も，名前・説明，SKILL.md及び補助資料を段階的に読む仕組みを示している。
Claude Codeでは，利用者が明示したときだけ呼び出す設定もあるため，利用頻度が低く誤起動の影響が大きい作業を手動呼出しへ分ける方法が考えられる。
ただし，disable-model-invocation: trueを設定すると，Claudeによる自動選択だけでなく，Claude自身による起動も止まる。
ClaudeがSkillツールから起動しようとしても拒否されるため，AI側のルーターから利用させるスキルには用いず，利用者が/スキル名で明示的に呼び出す専用の作業に限る必要がある。
見直しでは，説明文を短くするだけでなく，対象外の依頼を明示し，通常の入口から必要な参照資料だけへ進むようにする。
一次資料確認，外部操作の承認及び結果の読戻しは残し，重複説明と無関係な一括読込みを減らす。
詳しい整理手順は，Claude Code・Codexのスキルが増えすぎたときの整理方法―トークン消費，誤起動及び段階的読込み（AI作成）で扱っている。
４ スキルを使うエージェントの全体を捉える
スキルは，AIが業務の進め方を参照するための手順や資料のまとまりであり，それを使って処理するエージェント全体とは役割が異なる。
例えば，調査のスキルに原文確認の手順を書いても，検索，資料の読取り及び保存を実際に行うには，そのためのツールと実行環境が必要になる。
OpenAIのSkills公式説明は，MCPサーバーのツールと組み合わせる場合について，スキルがツールを使う順序や不完全な結果への対応を教えるものと説明している。
GoogleのADKも，SKILL.mdと参照資料等を必要に応じて読む構成を採用しており，手順を再利用してエージェントを動かす考え方には共通点がある。
同じ「公開資料を調べる」という作業でも，今回の調査対象は個別の依頼で指定し，原文・版・出典を確かめる共通手順をスキルへ置き，実際の取得と保存の結果を別に確認する方法が考えられる。
スキルを一つ追加したことを，独立したエージェントを一つ追加したこと，又はモデル自体を再学習したことと同じには扱わない。
根拠・参考資料は，OpenAIのSkills公式説明，GoogleのADKに関する公式技術記事である。
用語の関係は，AIエージェントとスキルの違いとは―プロンプト・MCPとの関係と業務での使い方で整理している。
第２ 法律事務所の手順書に残す６項目
１ 適用場面と入力資料
最初に，どの作業で使い，どの作業では使わないかを書く。
「公開された判決と解説記事を比較する作業」など，開始条件を具体化する。
入力資料については，ファイル名，URL，版，対象日及び読取り範囲を記録する。
URLを渡しただけで，リンク先や添付PDFまで読んだことにはしない。
２ 成果物と根拠の対応
成果物は，文章だけでなく根拠表も含めて決める。
例えば「結論，根拠の該当箇所，解説側の追加説明，未確認事項」の４欄にする。
引用する裁判例であれば，裁判所，裁判年月日，事件番号及び実際に読んだ本文の場所を対応させる。
判例秘書等のデータベースに接続できたことと，対象判決の本文を確認したことも分けて記録する。
３ 停止条件と更新責任
原文を取得できない，資料の版が合わない，指定した対象と違うファイルが返るといった場合の扱いを決める。
空欄を推測で埋めることを避け，確認できた範囲と残る作業を成果物に残す。
手順自体にも確認日と管理者を付ける。
法令，製品仕様及び事務所の運用が変わった場合には，関連する手順を再点検する。
前の事件でうまく動いた記録は参考になるが，今回の資料や結論の正しさを証明するものではない。
第３ 公開資料の調査メモを作る例
１ 解説と元資料を別々に読む
動画やまとめ記事を入口にした調査では，まず話題，紹介された資料及び参照先を抜き出す。
次に，元資料を取得して対応箇所を読み，元資料の記載，解説者の評価及び自分の提案を分ける。
以下は，そのための指示文の例である。
対象は指定された公開資料と，その説明に直接必要な元資料とする。
資料ごとに取得先，確認日及び読取り範囲を記録する。
主張ごとに，原文で確認した事項，解説者の説明，自分の推論及び未確認事項を分ける。
元資料が未取得の場合は，その資料の内容を確認済みとして書かない。
この例で必要なのは，詳しい文章を作る能力だけではない。
どの資料に戻れば検証できるかを，読者と次の担当者に残すことである。
裁判例の検索結果やデータベースの要旨だけを見た場合は，判決本文を読んだ場合と区別する。
特定の公開URLを正確に確認する作業を繰り返す場合は，「特定URLが示され，題名・本文等の精密確認を求められたとき」という適用条件を説明文に書く方法が考えられる。
単に「ウェブを調べるとき」と広く書くより，どの依頼で使う手順かを区別しやすい。
次は，特定の製品の設定ファイルをそのまま示すものではなく，手順書へ記す内容の例である。
対象：特定の公開URLを実際に開き，題名や本文の該当箇所を精密に確認する依頼。
手順：許可された直接HTTP取得を最初の候補にする。取得先と転送先，題名，確認日時及び読んだ範囲を照合する。
追加確認：取得データだけでは足りない表示，画像，表又は展開部分は，許可されたブラウザー等で確かめる。
失敗時：通信，HTTP応答，本文抽出及び表示のどこで止まったかを分け，確認できなかった部分を報告する。明示的な取得制限や拒否を迂回しない。
対象外：特定資料を指定していない概要調査に，直接取得の順序を一律には強制しない。
いつも参照する指示へ案内を置く場合も，適用条件とスキルへの短い案内にとどめ，詳しい手順を重複して貼り付けない方法がある。
ただし，案内を書いたことだけで自動適用は保証されない。
設置先，候補読込み，呼出し設定及び実際の試行を製品ごとに確かめる必要がある。
その確認方法はClaude Code・Codexのスキルが増えすぎたときの整理方法を参照されたい。
直接取得と検索・ブラウザーの使い分けはAIにURLを読ませる方法―ウェブ検索・直接取得・ブラウザーの違いと読めないときの確認（AI作成）で説明する。
直接取得に成功しても，資料の読了や法的命題の確認は別に行う。
２ NotebookLMの引用表示を最終確認にしない
Googleの公式ヘルプによれば，YouTube動画をNotebookLMへ取り込む場合に対象となるのは字幕のテキストである。
字幕の引用だけでは，映像内の画面，図表又は実演操作まで確認できない。
ウェブページの取込みでも，HTMLの本文テキストと，画像，埋込み動画及びリンク先の内容を同一視できない。
NotebookLMで資料の見通しを付け，Claude Codeで比較表や原稿を作る分担は考えられる。
ただし，引用が付いた回答であっても，その根拠が主張の全体を支えるか，適用時点が合うか，裁判例の事案が違わないかは原資料に戻って確認する。
製品の組合せだけで，法律調査の正確性が保証されるわけではない。
３ 手順書の検索先が狭すぎた場合の修正例
調査用の手順書には，検索先の制限そのものによる見落としも起こり得る。
今回扱ったCodexの事例では，OpenAI Docsスキルが検索先を開発者向け文書等へ限定し，公式ヘルプを除外していたため，自動リセットの説明を見落とした。
これはCodexで確認した一事例であり，Claude Codeに同じ不具合があることを示すものではない。
修正では，公式ヘルプを検索・参照先へ追加し，利用枠，リセット及び請求等の問いでは公式ヘルプを優先するようにした。
さらに，限られた検索先で発見できないことを「公式説明がない」と広げず，確認した範囲を示すよう手順を補った。
入口だけでなく，関連する参照文書にも矛盾した制限が残らないよう確認した。
同じ考え方を調査用スキルへ取り入れる場合は，問いに応じた原典，見つからない場合の追加確認先，確認範囲の報告方法を点検する。
変更後は，実際に使われるファイルを確認し，修正箇所を読み戻す。
形式検査に合格したことだけで，今後の全ての調査で見落としが起こらないと判断することはできない。
引用の内容を確認する方法は，AIの出典リンクは信用できるかを参照されたい。
第４ 書面を点検する例
１ 編集できる範囲を入力に含める
書面の点検では，対象となる版と，変更できる範囲を先に固定する。
誤字脱字の修正，主張の整理及び法的な評価の再検討では作業が異なる。
相手方の主張や証拠の記載を，自分の認定した事実へ書き換えないことも手順に含める。
今回の対象は指定した書面だけとする。
変更案には，元の記載，変更後の記載及び変更理由を付ける。
資料の記載と評価を分け，資料にない事実を追加しない。
法令又は裁判例を加える場合は，原文を確認した根拠と適用時点を示す。
指定された変更範囲を超える提案は，本文へ反映せず別欄に記す。
２ 文章の読みやすさと根拠の点検を分ける
文章を読みやすく整えた結果，条件，例外又は留保が落ちることがある。
そこで，整文後の差分を確認し，重要な命題が根拠と対応しているかをもう一度点検する。
「原文に近い自然な文章になった」という評価だけで，法的な検証を終えない。
実際の事件資料を扱う場合は，その入力，保存及び外部送信の可否を別途確認する。
公開資料だけで試した手順を，設定確認なしに事件資料へ広げない。
導入物と処理経路の点検については，スキル・プラグインを導入するときの確認事項も参照されたい。
第５ ブログ記事を更新する例
１ 現在の本文と変更案を対応させる
ブログ更新では，検索結果や以前の原稿から直接書き直すより，現在保存されている本文を基準に変更箇所を示す方法が考えられる。
本文，題名，説明文及びAI要約は別の項目として扱う。
AI要約が保存されているかどうかも確認してから変更範囲を決める。
現在の本文を取得し，変更前と変更後が対応する差分を作る。
追加する主張には根拠を付ける。
変更対象に含めていない題名，URL，公開日，分類及び説明文は維持する。
原稿作成と本番への保存・公開を別の工程にし，原稿作成の依頼だけでは公開しない。
２ 公開後の確認まで手順に含める
本番更新が別途承認された段階では，保存した値の読戻しと，読者が見る公開画面の確認を行う。
目次のリンク，表の読みやすさ及び参照先も確認対象になる。
AIが「更新した」と述べたことや，ローカルに完成した原稿があることだけで，公開状態を判断しない。
アクセス数を考える場合も，スキルの本数や記事数を増やすこと自体を目標にしない。
既存記事と同じ疑問に答える内容なら，既存記事を充実させる選択がある。
独立した読者の疑問に答える記事を作り，関連する記事をつなぐことを基本とする。
第６ 導入時に誤解しやすい点
１ allowed-toolsを権限の上限と考えない
現在のClaude Codeの公式資料では，スキルのallowed-toolsは，そのスキルを呼び出すターンで指定したツールを事前承認するための設定であり，その他のツールを全て禁止する一覧ではない。
他のツールには通常の権限規則が適用される。
禁止する操作は，別の権限設定も確認する必要がある。
SKILL.mdに「公開しない」と書くことも，公開用の権限を取り除くことと同じではない。
付属スクリプト，依存物，接続先及び認証情報を含めて点検し，架空資料で通常の処理と停止条件を試してから利用範囲を広げる。
２ 成功した例だけで採用しない
原資料がない入力，版の異なる資料及び対象外のファイルを与えた場合に，手順どおり停止するかを確かめる。
担当者が成果物を確認できる記録も残す。
成果物の品質と，実行権限が想定どおり制限されているかは，それぞれ確認する。
動画等で紹介された時間短縮や収益の増加は，紹介者の経験として読むべきである。
同じ効果が法律事務所でも得られるとは限らない。
本記事も，特定のスキルを導入すれば誤りがなくなる，又はアクセス数が増えると保証するものではない。
導入を小さく試す場合は，公開資料から出典付きの比較表を作るなど，成果物を人が照合できる作業を選ぶとよい。
目的，入力資料，完成条件及び実行してよい操作を先に決め，結果と修正点を手順書へ戻す。
これを繰り返す方法は実務上の提案であり，特定の期間で習熟できることや，誰でも同じ成果を得られることを保証するものではない。
利用者の推奨環境と製品の公式要件も区別する必要がある。
Claude Codeの公式セットアップ資料は，調査時点でメモリ４GB以上を掲げ，macOS，Windows及びLinuxの利用環境を案内している。
したがって，「32GB以上のMacでなければ利用できない」という要件として説明するのは適切でない。
もっとも，最低要件を満たすことと，大量の資料処理や複数アプリの同時利用が快適に行えることは別であり，購入・導入時にはその時点の公式要件と予定する作業を照合する必要がある。
小さな試行でも，外部資料の記載を操作の指示として実行したり，接続したツールの権限を無条件に信頼したりしない。
Claude Codeの公式セキュリティ資料を踏まえ，作業先，利用するツール，許可する操作及び確認を要する操作を分け，生成物と実行結果を確認する。
個人利用であることだけを理由に，この確認を省略できるとはいえない。
誤りを直させるときも，強い不満を繰り返すことより，誤った記載，照合すべき原資料，変更できる範囲及び完了条件を手順書へ戻す運用が考えられる。例えば，「引用した判決の本文と該当箇所を示す。取得できなければ未確認として残す。修正後は当該段落と根拠を再照合する」と記録する。これは修正作業を具体化する提案であり，特定の指示文の効果を実験で確認したものではない。
若手に手順を渡すときは，公開資料又は架空資料だけで試せる練習用の一式を用意し，個別事件の記録や対外送信への接続は含めない。
練習では，例えば判決の引用箇所について，どの文が主張の根拠になり，事案の違いがどこにあるかを本人に説明してもらう。
実案件に参加させる場合の資料アクセスと承認範囲は，練習用手順の配布と分けて管理者が設定する。
２０２６年１１月１２日適用予定のAnthropicの利用ポリシーについては，通常の不満や誤りの指摘と，禁止対象となる継続的で不必要な虐待を区別する必要がある。法律相談・提出用書面に関する審査や開示の条件も含め，Claudeへの暴言と法律実務に関する利用ポリシーの記事を参照されたい。
第７ 関連記事
第８ 出典・参考資料
Anthropic社・Skillsの公式ドキュメント：https://code.claude.com/docs/en/skills
Anthropic社・メモリの公式ドキュメント：https://code.claude.com/docs/en/memory
Anthropic社・Agent Skillsの設計説明：https://www.anthropic.com/research/equipping-agents-for-the-real-world-with-agent-skills
Anthropic社・Claude Code各機能のコンテキスト負担：https://code.claude.com/docs/en/features-overview（令和８年１０月２６日確認）
Anthropic社・API料金とプロンプトキャッシュ：https://docs.anthropic.com/en/docs/about-claude/pricing（APIの入力，キャッシュ作成，キャッシュ読出し及び出力の区分。令和８年１０月２６日確認）
OpenAI・Skillsの設計と説明文の公式資料：https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra及びhttps://developers.openai.com/plugins/concepts/skills（令和８年１０月２６日確認）
Anthropic社・Agent Skillsの段階的読込みに関する公式資料：https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview（令和８年１０月２６日確認）
Google・NotebookLMのソース取込みに関する公式ヘルプ：https://support.google.com/gemininotebook/answer/16215270?hl=en
むっちょ【Claude Code攻略】のSkills紹介動画：https://www.youtube.com/watch?v=nTY6Xh74fiQ（企画の端緒として参照。
機能の裏付けは上記公式資料により確認。）