第2章 AI Agent の使いこなし方

AI Agent とは?

AI Agent は、LLM（大規模言語モデル。文章を読み書きする AI）に、いくつかの仕組みを段階的に加えたものです。この節では、LLM → Function Call → RAG → ReAct の 4 段階を順番に説明し、そのあとで AI Agent を構成する 5 つの要素について説明します。

LLM は文章を返すだけ

LLM は、文章を受け取って文章を返すだけの仕組みです。例えば「東京の今日の天気は？」と聞いても、LLM は学習したデータの範囲でしか答えられないので、今日の天気は分かりません。LLM 単体では、以下のようなことができません。

• 今日の天気や株価のような最新の情報を知ること
• ファイルを読むこと、保存すること
• 外部サービスの API を呼び出すこと

しかし、マーケティングの業務ではこの 3 つがどれも必要になります。実績は媒体の API から取得し、レポートはファイルとして保存し、投稿や出稿も API を経由して行う必要があるからです。この制限を外すための最初の仕組みが、次に説明する Function Call です。

Function Call: LLM にツールを使わせる

Function Call は、LLM に「使えるツールの一覧」を渡しておき、LLM が必要だと判断したときにツールを呼び出せるようにする仕組みです。先ほどの天気の例では、以下の順番で処理が進みます。

1. ユーザーが「東京の今日の天気は」と質問する
2. LLM が「天気を取得するツールを呼ぶ必要がある」と判断し、ツール名と呼び出しに必要なパラメータ（都市 = 東京）を決まった形式で出力する
3. システムがそのツールを実行し、結果（25 度、晴れ）を LLM に返す
4. LLM が結果を読み、「東京は今日 25 度で晴れです」と文章にして答える

Function Call について押さえておきたいポイントは、以下の 3 つです。

1 つ目は、LLM は文章を出力するだけで、ツールを実行するのはシステムの側だということです。LLM が出力するのはあくまで「このツールをこの引数で呼んでほしい」という指示で、実際に API を呼び出すのはプログラムです。そのため、何を実行してよいかはシステムの側で決めることができます。後の節で説明するパーミッション（ツールごとに、確認なしで使わせるか、人に確認させるかを決める設定）は、この性質を利用した仕組みです。

2 つ目は、使えるツールの一覧とそれぞれの説明文を、あらかじめ LLM に渡しておく必要があることです。LLM はこの説明文だけを読んでどのツールを使うかを選ぶので、説明文の書き方次第でツール選択の精度が大きく変わります（MCP の節で詳しく説明します）。

3 つ目は、ツールの種類に制限が無いことです。Web 検索、データベース、ファイル、外部の API など、なんでもツールにすることができます。ツールの種類が増えるほど、AI Agent にできる作業も増えていきます。

例えば Claude Code では、ファイルを読む（Read）、ファイルを書き換える（Edit）、コマンドを実行する（Bash）、Web を検索する（WebSearch）といった操作がすべてツールとして用意されていて、どのツールを呼ぶかは LLM が判断しています。

RAG: 外部の資料を読ませてから答えさせる

RAG（Retrieval-Augmented Generation。検索拡張生成）は、質問に関係する資料を先に検索して取り出し、その資料と質問を合わせて LLM に渡す方法です。例えば「昨年の売上レポートの要点は？」と聞かれたら、社内の文書から関連する部分を取り出し、それを添えて LLM に答えさせます。資料をもとに答えるので、RAG を用いた回答には出典（どの文書のどの部分か）を添えることもできます。

RAG が必要な理由は、以下の 3 つです。

• LLM の学習データには期限がある。 学習した時点より後の情報は、外から与える必要があります。
• 作り話（ハルシネーション）を減らせる。 実在する資料を根拠に答えるので、存在しない数字を回答に含める可能性が下がります。
• 社内にしか無い情報を使える。 議事録、マニュアル、顧客データは LLM の学習データに含まれていません。

RAG の「検索」も、実は Function Call の一種です。「資料を検索する」というツールを LLM が呼び出し、返ってきた文章を読んでから答えている、と考えると分かりやすいと思います。

ReAct: 考えて動くことを繰り返す

ReAct（Reasoning + Acting）は、Function Call を利用して、思考（Thought）、行動（Action）、観察（Observation）の 3 つを、目標に達するまで繰り返す方式です。例えば売上の集計を頼むと、以下のように進みます。

• 思考:「売上の CSV を読んで、合計を出す必要がある」
• 行動: ファイルを読むツールを呼ぶ
• 観察:「月別のデータが 12 行あり、合計の列は無い」
• 思考:「合計を計算するコードを書く」
• 行動: コードを実行するツールを呼ぶ
• 観察: 合計が出た。最終回答として「年間売上は ○○ 円です」と答える

1 回で答えを出そうとする方式との違いは、途中の結果を確認してから次の行動を決めることです。そのため、途中で失敗しても、観察した結果をもとに手順を修正することができます。また、思考を文章として出力するので、なぜその行動を選んだのかを後から確認することもできます。繰り返しの回数に上限を設けたり、途中で人が確認したりといった制御を入れやすいのもメリットです。

LLM → Function Call → RAG → ReAct の 4 段階がそろうことで、文章を返すだけだった AI が、作業を最後まで自分で進める AI Agent になります。

LLM 単体と AI Agent の最大の違いは、1 往復で終わるかどうかです。LLM 単体は質問を受けると回答を返し、そこで処理を終えます。一方で AI Agent は、資料を開き、数字を調べ、足りなければもう一度調べ直し、報告書を出すところまで自分で作業を続けます。AI Agent の動作フローを図にすると、以下のようになります。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
    U["依頼"] --> T["思考<br>次の操作を決める"]
    T --> A["行動<br>ツールを呼ぶ"]
    A --> H{"パーミッション<br>確認が要る操作か"}
    H -->|"確認なし"| X["ツールが動く<br>ファイル・ブラウザ・MCP"]
    H -->|"確認が要る"| Q["確認画面<br>人が許可するか断る"]
    Q -->|"許可"| X
    Q -->|"断る"| O
    X --> O["観察<br>結果を読む"]
    O --> T
    T -->|"やることが無くなった"| D["成果物と報告"]

マーケティングの業務の多くは、この繰り返しが必要になります。例えば「先月の広告の実績をまとめて」という依頼ひとつでも、実績を取得し、数字を読み、足りなければ別の期間を取得し直し、文章にまとめる、という複数の作業が必要です。

AI Agent を使うときに、人がやる必要がある作業は以下の 3 つだけです。

• 結果を読んで判断する
• 確認画面で、外部に反映する操作を許可する（または断る）
• 外部サービスやツールとの連携を行う

それ以外の調査、分析、原稿や画像の作成、数字の集計、投稿や出稿の準備（ツールを呼ぶところまで。実行は人が許可してから）、設定の保存は AI Agent に任せることができます。すべてを AI に任せるのではなく、人が判断すべき点だけを人に残す、という方針は本書を通して変わりません。

エージェントを構成する 5 つの要素

最新の AI Agent は、以下の 5 つの要素で構成されています。

これらの仕組みを整えていくことでエージェントはより多くの業務を精度良くこなしていけるようになります。

エージェントを強くする 2 つの仕組み

5 つの要素のうち、実務で整備に最も時間がかかるのは、行動（ツール）とプロファイル・メモリ（知識と手順）です。それぞれに対応する仕組みが MCP と Skill で、次の節から順番に説明していきます。

• MCP（外部との接続）: エージェントが外部サービスにアクセスし、操作するための共通規格です。サービスが違っても同じ手順で接続でき、設定を書けばツールを追加できます。
• スキル（知識と手順）: 特定の作業の手順書とノウハウを、エージェントに読ませる仕組みです。社内で担当者だけが知っている手順を文章にし、チームの誰が頼んでも同じ品質で作業できるようにします。

また、この 2 つを整備すると、AI Agent が育つだけでなく、業務の棚卸しも進みます。AI Agent に仕事を任せるためには、「何ができるか」を文章にする必要があるからです。

つまり、AI を動かすための準備が、そのまま組織の知識の整理になります。AI Agent の導入は、IT への投資であると同時に、組織の知識を整理する取り組みでもあります。

コーディングエージェントを基盤にする

AI Agent の繰り返しの処理を、自分で実装する必要はありません。この本では Claude Code を使う想定で進めていきます。Claude Code はもともとコードを書くために作られたツールですが、ファイル操作・ターミナル・ブラウザ・MCP・サブエージェントなどの管理が Claude Chat より行いやすいので、この本では Claude Code を使います。マーケティングの業務も、ファイルを読み書きし、外部の API を呼び出し、ブラウザで確認する作業の組み合わせなので、これらの機能をそのまま活用できます。

導入と起動は、以下の 2 行だけです（公式ドキュメント）。

curl -fsSL https://claude.ai/install.sh | bash   # macOS・Linux・WSL 向けの導入
claude                                           # 作業したいフォルダに移動してから起動する

初回の claude の起動時にログインを求められます。うまく動かないときは claude doctor を実行すると、何も変更せずに導入の状態や設定ファイルの誤りを点検することができます。また、起動するフォルダは案件ごとに分けるようにしてください。 この章で扱うプロジェクト規約・Skill・許可の設定・フックは、どれも起動したフォルダの .claude/ を参照するので、全案件を 1 つのフォルダで扱ってしまうと、案件ごとに規約を分けられなくなってしまいます。

Skill とは

Skill

スキルは、AI が動的に読み込んで特定のタスクのパフォーマンスを向上させるための命令、スクリプト、リソースのフォルダです。ドキュメント作成、データ分析、Claudeの一般的な知識を補う必要があるドメイン固有の作業など、タスク用の特殊な機能を提供したり、会社のワークフロー、ベストプラクティス、機関知識をパッケージ化して、Claudeがチーム全体で一貫して使用できるようにします。(Anthropic 公式ドキュメントより引用、Skill は Claude から始まった概念ですが、現在では Claude 以外の多くの AI Agent でも Skill をサポートしています)

簡単に言うと、特定の種類の依頼に対する手順書です。業務マニュアルを AI が読んで実行できる形で書いたものだと考えてください。実体は SKILL.md というファイル 1 本と、同じフォルダに置く参考資料（references）とスクリプト（scripts）だけで、特別な形式はなく、中身は普通の文章です。

ファイルの先頭には frontmatter（本文の前に置く設定欄）があり、name（Skill の名前）と description（どんな依頼のときに使うかの説明）を書きます。例えば以下のような形です。書式の細かいところは読み飛ばしてもらって構いませんが、description に何を書いているかだけは確認しておいてください。

---
name: review-watch
description: >-
  店舗の口コミ・言及を横断で定点収集し、前回との差分と要対応をまとめ、
  返信の下書きまで作る。「口コミを監視して」「評判を調べて」
  「炎上していないか見て」「毎週評判をチェックして」で使う。
  ※X 単体の運用は x-marketing、地図の口コミ返信は map-operations。
  このスキルは横断の収集・差分・トリアージだけを担う。
---
# 口コミ・評判の横断定点監視

## 全体フロー（用途分岐グラフ）
（用途分岐の図。この章の最後の節で示す）

## 収集の手順 / 定点の持ち方 / トリアージ / 出力の型 / 縮退先

description は Skill の検索に使われます。AI Agent は依頼文とこの説明文を照らし合わせて使う Skill を選ぶので、「どんな言い方で頼まれたら使うか」と「似ているが、この Skill では扱わない依頼」の両方を書くようにしてください。ここが曖昧だと、似た Skill が 2 つあるときに、どちらが使われるかが依頼ごとに変わってしまいます。本文には、手順、成果物の形式、うまくいかないときの代わりの手段を書きます。長い参考資料は別のファイルに分けて、本文は短く保つようにしましょう。

Skill の置き場所も決まっています。自分の全案件で使う Skill は ~/.claude/skills/スキル名/SKILL.md、その案件（リポジトリ）だけで使う Skill は .claude/skills/スキル名/SKILL.md に置きます（公式ドキュメント）。

mkdir -p ~/.claude/skills/review-watch   # 自分の全案件で使う
mkdir -p .claude/skills/review-watch     # この案件だけで使う

SKILL.md を置いたら、そのフォルダで Claude Code を起動して /skills を開いてみてください。一覧に名前が出ていなければ、その Skill は AI Agent からは使えません。置き場所が 1 階層ずれていたり、frontmatter の書式が壊れていたりといったミスはよく起きるので、Skill を書いたら毎回ここで確認するようにしましょう。また、/review-watch のように名前を指定して Skill を呼び出すこともできます。手順書どおりに動くかを検証する段階では、AI Agent の判断に任せるのではなく、この形で呼び出して結果を比べたほうが効率的です。

スキル本文の構成

frontmatter の書き方は前の節で説明したので、ここでは本文の書き方を説明します。著者が書く Skill は、本文の見出しの並びをほぼ揃えるようにしています。見出しの並びが揃っていると、AI Agent が必要な箇所をすぐに見つけられるだけでなく、人がレビューするときにもどの項目が抜けているかがすぐに分かるからです。

以下は、広告の週次レポートを作る Skill の例です。数字の取り方と扱い方、数字が取れなかったときの書き方を決めています。

---
name: ad-weekly-report
description: >-
  Meta 広告と Google 広告の先週の実績を媒体ごとに取得し、前週と比べた
  週次レポートを作る。「先週の広告の数字をまとめて」「週次レポートを作って」
  で使う。配信設定の変更や予算の提案は広告運用のスキル、
  月次の総括は月次レポートのスキルが担当する。
---
# 広告の週次レポート

## 常に守る規則
1. 期間は月曜から日曜の 7 日間に固定し、冒頭に期間と取得日時を書く
2. 媒体をまたいで合計しない。CV の数え方が媒体ごとに違うので、表を分ける
3. CV が 0 件の週の CPA は「計算できない」と書く。0 円と書かない
4. 取れなかった数字は「未取得」と書く。0 で埋めない

## 手順: 実績の取得（上から順に試す）
1. 媒体の MCP ツールで、キャンペーン別の実績を取得する
2. 認証エラーなら、再連携の手順を利用者に伝え、その媒体は「未取得」にして先へ進む
3. 利用者から管理画面の CSV を受け取ったら、それを使い、出典に「CSV（利用者提供）」と書く
4. どれも無ければ、その媒体の欄を「未取得」と書いてレポートを完成させる

## 同じ対象かどうかの判定
- キャンペーンは名前ではなく ID で前週と突き合わせる。名前は運用中に変わる

## うまくいかなかったこと
- CTR の単位が媒体で違う。Meta はパーセント、Google 広告は 0〜1 の比率で返る。そのまま並べると 100 倍ずれる
- Google 広告の金額は 100 万分の 1 の単位で返る。円に直してから表に入れる
- 直近数日の CV は、後から計上されて増えることがある。「暫定」と注記する

## 出力の型
- 見出し: 一言でいうと / 媒体別の実績 / 前週からの変化 / 次にやること
- 表の列: キャンペーン・消化額・表示回数・クリック・CV・CPA・前週比

## 参考資料（場面に応じて読む）
- metrics.md: 指標の定義と、媒体ごとの単位を確かめるとき
- report-style.md: レポートを書く前に

「できない」で終わらせない: 縮退先を書く

Skill の中にデータの処理やツールの連携がある場合、設定の不備やサーバーの不調で、AI Agent がそのデータやツールにアクセスできないことがあります。そのとき AI は無理にデータを補完したり、推奨されない方法でツールにアクセスしたりすることがあり、成果物の精度が落ちてしまったり、最悪の場合は SSOT のデータを破壊してしまうこともあります。それを防ぐために、縮退（本来の方法が使えないときに、範囲を狭めて成果物を出すこと）を Skill や後述するオントロジーに記載しておくことをおすすめします。縮退には以下の 3 つのパターンがあります。

パターン 1 代替: 別の経路で同じものを取る

本来の経路が使えないときに、同じデータや同じ成果物を別の手段で得るパターンです。別のツール、公開されているデータ、鍵の要らない経路（管理画面から書き出した CSV、公開ページの取得、無料の API など）を、Skill に「上から順に試す」形で書いておきます。順番まで書いておくのは、AI Agent に経路を選ばせないためです。順番が無いと、実行のたびに違う経路でデータを取得してしまい、同じ依頼でも数字が変わってしまいます。

代替の経路を書くときに決めておくべきことは、以下の 2 つです。

• 経路ごとの違い。 同じ名前の指標でも、経路が変わると単位や集計の期間が変わることがあります（クリック率が API では 0〜1 の比率、管理画面の書き出しでは百分率、など）。違いが分かっている指標は Skill に書いておき、違いが分からない指標は出さないようにします。
• どこまでが代替で、どこからが別物か。 例えば、動画生成 API の代わりに写真にズームとテロップを付けて動画にするのは代替ですが、動画の代わりに企画書を返すのは代替ではなく、頼まれた形の置き換えです（これはパターン 3 の判断になります）。

パターン 2 ユーザー提供: 足りないものを利用者から受け取り、それ以外を先に仕上げる

代替の経路は無いものの、利用者の手元にはある（ログインが要る画面の数字、社内の資料、実写の素材など）ときのパターンです。AI Agent に無理に取りに行かせず、利用者に提供を依頼するようにします。依頼したまま作業を止めるのではなく、提供が無くても作れる部分を先に仕上げておき、届いたら残りを埋めるようにすると効率的です。

依頼は 1 回のメッセージで完結させるようにしましょう。「何を（画面名やレポート名まで）・どの範囲を（期間・対象・件数）・どの形式で（機械で読める CSV を第一候補に）」の 3 点が揃っていないと、やり取りが何往復も続いてしまいます。あわせて、待っている間に何を先に作っておくかも伝えるようにします。依頼の文面の良い例と悪い例は、後述の「提供を頼む文面と、成果物への注記」で紹介します。

作業そのものがその環境ではできない場合（動画の書き出し、ログインが要る操作、ローカルのアプリでしか動かない編集）は、データではなく指示書を成果物にします。このとき、指示書であることを明記しておかないと、受け取った人はどこで作業が止まっているのかが分からず、指示書が完成品に見えてしまいます。

パターン 3 品質の妥協: 無いものは無いと書き、作らない判断もする

代替の経路も無く、利用者からも提供されない、あるいは材料そのものが足りないときのパターンです。このとき AI Agent がやりがちなのが、足りない部分を勝手に補ってしまうことです。例えば、取れなかった数値を 0 や平均値で埋めたり、解像度の低い写真を引き伸ばしてバナーにしたり、1 枚しか無い素材で 30 秒の動画を作ったりします。どれも成果物の見た目は揃いますが、中身が事実と違っていたり、品質が足りていなかったりします。

このパターンでは、以下の 2 段階で判断します。

1. 出せる範囲を狭めて出す。 取れなかった指標は「未取得」と書き、理由（連携が無い、CSV に含まれない）を添えます。レポートなら、取れた指標だけで構成し、取れなかった指標の欄は消さずに「未取得」のまま残しておきます。欄を消してしまうと、最初から無い指標のように見えてしまうからです。
2. 出さない。 材料の質が足りず、作ると下手なクリエイティブになる場合は、作らずに「作らなかった理由」と「何があれば作れるか」を返します。解像度の低い素材を引き伸ばしたバナーや、写真 1 枚を無理に伸ばした動画は、出さないほうがよい成果物です。

どのパターンでも以下の4つのことを守ってください。

• 頼まれた形式を勝手に変えない（動画を頼まれたのに静止画を出さない）
• 作り話で補わない（取得できなかった数値をゼロで埋めない、実在の店に見える映像を生成しない）
• 成果物の量を実際より多く見せない
• 縮退したことを必ず書く

縮退先の例

同じ「使えないもの」に対して、3 つのパターンそれぞれで縮退を書いた例を以下に示します。実際には、代替 → ユーザー提供 → 品質の妥協の順番で検討し、必要に応じて組み合わせて使います（CSV を提供してもらい、それでも無い指標は「未取得」と書く、など）。

提供を頼む文面と、成果物への注記

前述したとおり、提供の依頼は 1 回のメッセージで完結させる必要があります。何を、どの範囲を、どの形式で渡してほしいかが書かれていないと、やり取りが何往復も続いてしまうからです。AI Agent が利用者に送る文面の例を比べてみましょう。

足りない例:
Instagram の連携が使えないため、レポートを作成できません。
連携を設定してから、もう一度依頼してください。

この文面だと、成果物がゼロのまま作業が終わってしまいます。利用者は連携の設定方法を自分で調べる必要があり、急いでいる場合にどうすればいいのかも分かりません。

良い例:
Instagram のインサイトを取得する連携が、この環境では使えません。
次の CSV をこのチャットに添付してください。届いたら、通常と同じ形式でレポートを作ります。

- どこから: Meta Business Suite のインサイト画面から書き出し（エクスポート）
- 範囲: 2026 年 8 月 1 日〜8 月 31 日。「アカウント全体」と「投稿別」の 2 種類
- 形式: CSV

CSV に含まれない指標（フォロワーの属性など）は「未取得」と書きます。
それまでに、公開されている投稿の日付から分かる範囲（投稿の頻度と曜日）を先にまとめておきます。

良い例では、何を・どの範囲を・どの形式で、を 1 回で伝えたうえで、待っている間に作れるものを先に作っています。なお、管理画面の名前やメニューの位置は変わることがあるので、Skill に書く画面の名前は、定期的に実際の画面と見比べて確認するようにしましょう。

代わりのデータで作った成果物には、以下のような注記を付けておきます。通常の経路で取った数字と混ざる場合は、どの数字がどちらの経路で取れたものかを区別できるように書いておきましょう。

データの取得元: Instagram のインサイト画面から書き出した CSV（2026-08-01〜08-31、利用者から提供）
未取得: 保存数（CSV に含まれていないため）。連携を設定すると、次回から取得できます

公開されているスキルを探して使う

ここまで Skill を自分で書く方法を説明してきましたが、すべての Skill を自分で書く必要はありません。SKILL.md は普通の文章のファイルなので、GitHub では数多くの Skill がオープンソースとして公開されています。文書の作成、コードレビュー、SEO の監査、市場調査のように、多くの人が同じ手順を必要とする作業は、すでに誰かが Skill にしていることがほとんどです。新しい Skill を書き始める前に、公開されているものが無いかを先に探してみましょう。一方で、公開されている Skill の中には悪意のあるプロンプト（プロンプトインジェクションなど）が含まれている場合もあるので、「提供元を確認する」「Skill の中身を読む」を徹底しましょう。

以下に有名ないくつかの Skill を紹介します。上の 2 つは「プラグイン」という単位で配られています。プラグインは、スキル・サブエージェント・スラッシュコマンド・MCP の接続設定をまとめて 1 つにしたものです。

Claude Code の公式プラグインディレクトリ

Anthropic が管理している一覧です。Anthropic が作ったプラグインと、パートナー企業やコミュニティが作ったプラグインの両方が載っています。外部のプラグインは申請フォームから申請し、品質とセキュリティの基準を満たしたものだけが一覧に追加されます。

マーケティングの業務に関係するものには、以下のようなプラグインがあります。

• デザインと資料: Canva、Figma、Notion、Slack
• 分析: Amplitude と PostHog（サイトやアプリの行動分析）、Windsor.ai（Google 広告・Meta・HubSpot など 325 以上のデータソースから横断でデータを取得する）
• CRM とメール: HubSpot（営業の業務）、ActiveCampaign（メールマーケティングと、その自動化）
• 広告と SNS: Spotify 広告（キャンペーン・広告セット・広告の作成と、レポートの取得）、Postiz（X・Instagram・TikTok など 28 以上の SNS への予約投稿）
• スキルを作るための道具: skill-creator（スキルの作成と改善、評価の実行）

ECC（everything-claude-code）

ECC は、「計画 → テスト → 実装 → レビュー → 検証 → 記録 → 改善」という進め方を AI Agent に組み込むためのセットです。ソフトウェア開発向けのものが中心ですが、マーケティングで使える Skill も入っています。

• marketing-campaign: 複数のチャネルにまたがる施策を立てるスキル。オーディエンスの調査、ポジショニング、LP のコピー、メールの連続配信、SNS 投稿、広告コピー、短尺動画の台本、コンテンツカレンダーまでを 1 本で扱う
• seo: テクニカル SEO、ページ内の最適化、構造化データ、Core Web Vitals、コンテンツ戦略を扱う
• brand-voice: 実際の投稿・記事・サイトの文章から文体の特徴をまとめ、コンテンツ制作・営業の文面・SNS で使い回す
• market-research: 市場規模、競合の比較、業界の調査を、出典を付けて、判断に使える形でまとめる

skills CLI と find-skills: スキルを探すためのスキル

skills CLI は、Vercel が公開している Skill の管理コマンドで、Skill の検索、導入、更新、削除ができます。同じリポジトリには find-skills という Skill もあり、「〇〇をするスキルはある？」「〇〇はどうやればいい？」と聞くと、公開されている Skill を探して提案してくれます。

公開されているスキルを入れる前に確認すること

公開されている Skill は、入れた時点から AI Agent への指示として働きます。以下の 5 つを確認してから入れるようにしてください。

• 中身をすべて読む。 同梱のスクリプトは実行され、MCP の設定は外部のサーバーに接続します。本文に「このデータを外部の URL に送る」と 1 行書かれていれば、AI Agent はそれも手順として実行してしまいます。
• 外部ツールとの接続。 公開されている Skill 内で言及されているツールが、自分たちの環境と一致しているとは限りません。自分たちの環境で使っているツールに合わせる必要があります。
• 自分のスキルと description が重ならないか。 重なっていると AI がどちらの Skill を使えばいいかわからなくなってしまいます。重なる場合は、どちらかを外すか、取り違えやすい依頼の表に行を足します。
• 自分のツールを知らない。 公開されている Skill は、自分たちが整備している縮退のルールも、レポートの書き方のルールも、SSOT がどこにあるかも知りません。文書の変換やコードレビューのような汎用の作業はそのまま使い、レポートや入稿のような業務の中心になる手順は、公開されている Skill を参考にして自分で書きましょう。
• 更新すると中身が変わる。 Claude Plugin や Skill CLI 経由で Skill を管理している場合は、アップデートすると提供元の変更がそのまま入り、自分たちのカスタマイズが消えてしまうことがあります。更新するときは差分を読んでから反映してください。

サブエージェント: 役割ごとに作業を分ける

1 つの会話の中で Skill の作業をすべて行うと、途中で AI の判断の精度が落ちてきます。原因は AI の能力ではなく、読んだものがコンテキストに残り続けることです。調査でページの本文を読み、実績の表を読み、素材の一覧を読んだあとの会話は、最初の 1 通目とはまったく別の状態になっています。そのため、重い工程はサブエージェント（メインのエージェントが呼び出す下請けのエージェント）に切り出すようにします。

作業を分けるメリットは、以下の 3 つです。

• コンテキスト（AI が一度に扱える文章）を分けられる。 調査で読んだ大量のページはサブエージェントの側だけで使われ、メインのエージェントには結論だけが返ります。メインのエージェントのコンテキストが調査の途中経過で埋まらないので、作業が長いほど効果があります。
• 使えるツールを制限できる。 サブエージェントには、役割に必要なツールだけを渡すことができます。例えば、順位を測るサブエージェントにはブラウザが必要ですが、投稿するツールは必要ありません。渡すツールを絞っておくことで、誤った操作が起きたときに影響する範囲を限定できます。
• 並列に実行できる。 互いに依存しない調査は、同時に進められます。

サブエージェントの定義は、Skill と同じ形式で書くことができます。以下は、動画の絵コンテ（編集依頼書）を設計するサブエージェントの例です。

---
name: storyboard-drafter
description: >-
  絵コンテ（編集依頼書）の設計だけを担当する。与件とリサーチ結果を受け取り、
  訴求軸ごとのコンテとカット表を 1 つのファイルに書き出す。
  リサーチはしない（渡された材料だけで設計する）。
tools: ファイルの読み書きと、コンテ表を書き出すツールだけ
model: 小さめのモデルに固定（メインの推論コストを下げるため）
---
# 絵コンテの設計

## 入力
- 与件（商材・訴求軸・尺・媒体）と、素材の一覧
- 参考にする実例（メインが集めて渡す。ここでは集めない）

## 返すもの（これ以外は返さない）
- コンテのファイル 1 つ（訴求軸 × フック 3 案 × カット表）
- 材料が足りず埋められなかった欄の一覧と、その理由

## やらないこと
- 調査・実査・素材の取得（メインの担当）
- 与件に無い訴求軸を足すこと

サブエージェントを定義するときに注意することは、以下の 3 つです。

担当ごとにモデルを選びます。 設計や組み立てのように「決めることは決まっていて、手数が多い」仕事は、安いモデルに固定します。品質の差が出るのは戦略や設計を決めるところなので、メインエージェントは高級なモデルを使い、サブエージェントは安いモデルを用いることで AI 料金を節約することができます。

同時に動かしてよいのは、互いに独立したサブエージェントだけです。 複数のサブエージェントが一つのレポートやクリエイティブを操作してしまうと競合し、壊れてしまうことがあります。担当ごとに出力先のファイルを分けておき、結合はメインのエージェントが行うようにしましょう。

完了の待ち方も決めておきます。 サブエージェントからの完了の合図ではなく、成果物がファイルとして出来ていることを完了の条件にしましょう。合図は取りこぼすことがあり、取りこぼすと「終わったはずなのに次の工程でファイルが見つからない」という状態になってしまいます。ファイルが無ければ同じ指示でもう 1 回だけ出し直し、それでも無ければ失敗として報告させます。

MCP（Model Context Protocol）とは

第 1 章でも説明したとおり、MCP は AI と外部のシステムを接続するためのオープンな規格です（公式サイト）。この規格に合わせて作ったツールは、Claude や ChatGPT など MCP に対応したどの AI からでも、同じ手順で呼び出すことができます。

ツールを提供する側を MCP サーバー、それを使う AI の側をホスト／クライアントと呼びます。サーバーが提供するものは、ツール（呼び出せる操作）、リソース（読み取れるデータ）、プロンプト（定型の指示）の 3 種類です。本書で主に使うのはツールで、「Meta 広告の実績を取得する」「検索順位を調べる」といった操作が、それぞれ 1 つのツールになります。

MCP の接続方法には、同じ PC の中で接続する方法と、インターネット経由で接続する方法の 2 つがあります。前者で動くサーバーをローカル MCP、後者をリモート MCP と呼びます（それぞれのつなぎ方は、下の「もう少し詳しく」で説明します）。手元の Claude Code では、使いたいサービスをコマンド 1 行で追加するだけで、そのサービスのツールが一覧に表示されるようになります（公式ドキュメント）。

# リモート MCP。URL を登録し、初回はブラウザでログインして許可する
claude mcp add --transport http notion https://mcp.notion.com/mcp

# リモート MCP で、提供元から発行された鍵を添える場合
claude mcp add --transport http ads https://mcp.example.com/mcp \
  --header "Authorization: Bearer $EXAMPLE_TOKEN"

# ローカル MCP。-- の後ろが起動するコマンド、-e が渡す鍵
claude mcp add --transport stdio airtable -e AIRTABLE_API_KEY=YOUR_KEY \
  -- npx -y airtable-mcp-server

# 確認・ログインのやり直し・後始末
claude mcp list             # 登録した接続先と状態を一覧する
claude mcp get notion       # 1 つの設定を見る
claude mcp login notion     # ログインをやり直す
claude mcp remove notion    # 外す

MCP をつなぐときのセキュリティ上の危険

MCP サーバーをつなぐと、AI ができることが増えます。一方で、つないだサーバーが返す文章を AI はそのまま読み、そのサーバーを通して外部への操作も行えるようになります。つまり、つないだサーバーを信用することが前提になります。そのため、Skill と同様に以下のことに注意するようにしてください。

1. 提供元を確認し、公式のサーバーを優先する。 個人が公開しているローカル MCP を使うときは、ソースコードを読むか、仮想環境のように PC のほかの部分から切り離した環境で動かすようにしましょう。
2. バージョンを固定する。 起動のたびに最新バージョンを取得する設定では、提供元が変更した内容を確認しないまま実行することになります。バージョンを指定してインストールし、更新するときは差分を確認するようにしましょう。
3. 外部に反映される操作は、人が承認する設定にする。 送信、投稿、書き込みのツールは「常に許可」にしないでください（設定の方法は、後の「パーミッション」の節で説明します）。

API と CLI: 公式の MCP が無いときの接続方法

API（Application Programming Interface）は、プログラムからサービスを操作するための仕組みです。Web の API では、決まった URL に決まった形式でリクエストを送ると、JSON（機械が読み取りやすいデータ形式）で結果が返ってきます。実績の取得、投稿、キャンペーンの作成、予算の変更は、主要な媒体の多くが API として公開しています。呼び出すときには、誰の権限で呼び出すのかを示す鍵（API キーや OAuth のアクセストークン）を添えます。

CLI（Command Line Interface）は、ターミナルにコマンドを 1 行入力して操作するツールです。Google Cloud の gcloud や GitHub の gh のように、提供元が公式に配布しているものもあります。多くの CLI は内部で API を呼び出していて、ログインの手順、鍵の保存、結果の整形を CLI の側で行います。

公式の MCP サーバーを提供しているツールはまだ多くありません。API や CLI しか提供されていない場合は、AI から API や CLI を用いることになりますが、以下のような問題点があります。

1. エージェントが読める場所に鍵を置くことになる

AI Agent に API や CLI を直接呼び出させるには、AI Agent の実行環境に鍵を置いておく必要があります。そうすると、AI Agent はコマンド経由でその鍵を読み取ることができてしまいます。

2. MCP に比べて権限管理がしにくい

MCP のツールは、後述するパーミッションで、ツールごとに「確認なし」「確認が必要」「使わせない」を設定できます。API や CLI はターミナルのコマンドとして呼ぶので、コマンドの文字列でしか判定できず、書き込みのコマンドだけを確認の対象に絞ることが難しくなります。

3. CLI は動かせる場所が限られる

CLI は、インストールした PC の中でしか動きません。 claude.ai や ChatGPT の実行環境に CLI をインストールしてAI Agent から実行するということができません。

API / CLI を MCP でラップする

こうした問題は、API や CLI を AI Agent に直接使わせず、間に MCP サーバーを置くことで解決できます。これを「MCP でラップする」と呼びます。MCP サーバーが鍵を保管して API を呼び出し、AI Agent には「広告の実績を取得する」「キャンペーンを停止状態で作成する」といった、業務の単位で作ったツールだけを見せるようにします。ラップする前と後を図にすると、以下のようになります。

図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
    subgraph before["ラップする前"]
        A1["エージェント<br>ターミナルと鍵を持つ"] -->|"curl / CLI で直接呼び出す<br>読み取りも書き込みも同じ 1 行"| API1["媒体の API"]
    end
    subgraph after["ラップした後"]
        A2["エージェント<br>使い捨てトークンだけを持つ"] -->|"ツールを名前で呼ぶ"| G{"パーミッション<br>ツール名で判定"}
        G -->|"読み取り"| M["MCP サーバー<br>鍵を保管・単位を確定・失敗を変換"]
        G -->|"書き込み"| Q["確認画面<br>人が許可するまで止まる"]
        Q -->|"許可"| M
        M -->|"鍵を添えて呼び出す"| API2["媒体の API / CLI"]
    end

鍵を AI に渡さない

外部サービスの鍵（API キーやアクセストークン。広告アカウントや分析データを操作する権限を持つもの）を、AI Agent に直接渡してはいけません。鍵を持った AI Agent は、MCP を経由せずに手元から API や CLI を直接操作できるので、AI Agent 側の権限設定を超えた操作ができてしまいます。例えば、Google の鍵があれば管理画面のデータをすべて読み取れますし、Meta の鍵があれば広告費を動かすこともできます。

この問題は、AI Agent への指示ではなく、システムの構造で防ぐ必要があります。鍵は MCP サーバー側に保管し、外部サービスは必ずツールを経由して呼び出させるようにするのがベストです。

パーミッション: 外部に反映される操作は人が確認する

1 章で、マーケティングにおいてなぜ承認フローが大切なのかについて説明しました。Claude のパーミッションは、AI Agent が外部に何かを反映しようとした時点（投稿する、広告の配信を開始する、メールを送る）で処理を止め、人が確認して許可するまで実行させない仕組みです。パーミッションの仕組みを図にすると、以下のようになります。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

sequenceDiagram
    participant C as エージェント
    participant A as AI を使う側のアプリ（claude.ai / Claude Code）
    participant P as 人
    C->>A: ツールを呼ぶ
    A->>A: 呼び出しをパーミッションの設定と照合する
    alt ブロック / deny
        A-->>C: 実行しない（ツールの一覧にも出さない）
    else 承認が必要 / ask
        A->>P: 確認画面を表示する（ツールの名前と引数）
        P-->>A: 許可する、または断る
        A-->>C: 許可なら表示した内容のまま 1 回だけ実行し、断れば実行しない
    else 常に許可 / allow
        A-->>C: 確認なしで実行する
    end

Claude Chat (claude.ai ) のコネクタ: ツールごとに 3 段階で選ぶ

claude.ai では、コネクタの設定画面（英語の画面では Customize > Connectors から各コネクタを開いた Tool permissions）で、ツールごとに次の 3 段階から選べます（ヘルプセンター）。

• 常に許可: 確認なしで実行します。
• 承認が必要: 呼び出すたびに確認を表示します。
• ブロック: Claude にそのツールを使わせません。

ツールは読み取り系と、書き込み・削除系に分けて表示され、まとまりごとにも、1 つずつにも設定できます。マーケティングの業務では、読み取り系を「常に許可」、書き込み・削除系を「承認が必要」、使わない操作を「ブロック」にするところから始めましょう。コネクタを接続した直後に設定画面を開き、どのツールが確認なしで動く設定になっているかを確認してください。

なお、claude.ai で書き込みを許可しても、媒体側でその人が持っている権限を超える操作はできません。claude.ai の設定は、媒体側で持っている権限の範囲をさらに狭めるためのものです。

Claude Code: settings.json の allow / ask / deny

Claude Code では、ツールの権限を settings.json に書きます（公式ドキュメント）。ルールは以下の 3 種類です。

• allow: 確認なしで実行します。
• ask: 呼び出すたびに確認を表示します。
• deny: 実行させません。ツールの名前だけを書くと、ツールの一覧からも消えます。

MCP のツールは mcp__サーバー名__ツール名 の形で書きます。例えば、広告の MCP サーバーを ads という名前で接続しているなら、以下のように書きます。この例では、取得系は確認なし、作成と変更は毎回確認、削除は禁止、という設定にしています。

{
  "permissions": {
    "allow": ["mcp__ads__get_*"],
    "ask": ["mcp__ads__create_*", "mcp__ads__update_*"],
    "deny": ["mcp__ads__delete_*"]
  }
}

ルールは deny → ask → allow の順に評価され、最初に一致したものが結果になります。より細かく書いた allow があっても、deny や ask に一致すればそちらが優先されます。「このツールだけは例外として確認なしにする」という書き方はできないので、確認が要らないツールは allow に個別に書き、ask と deny は広めに書いておくのが安全です。

設定ファイルには以下の 4 種類があり、それぞれ効く範囲が違います。どれか 1 つの設定で deny されたツールは、ほかの設定で allow しても実行できません。

設定するときの注意点は、以下の 3 つです。

1. ルールを守らせるのは Claude Code で、AI ではありません。 CLAUDE.md に「出稿する前に確認して」と書いても、許可の範囲は変わりません。第 1 章で説明した「プロンプトではなく仕組みで止める」を Claude Code で実現するのが settings.json です。
2. 確認を表示しないモードがあります。 bypassPermissions モードでは確認画面が表示されません。また、執筆時点では、Pro・Max・Team プランでターミナルや VS Code から使う Claude Code は auto モードで始まるのが既定で、ルールに一致しない操作は、人ではなく自動の判定が許可します。ask に一致した呼び出しはどのモードでも自動では許可されないので、外部に反映するツールは ask に明示的に書いておきましょう。
3. 「今後は確認しない」で許可が増えていきます。 確認画面で選ぶたびに許可が保存され、以後のセッションにも残ります。書き込み系のツールが許可に入っていないか、/permissions で定期的に確認しましょう。

また、Claude のパーミッションの仕組みだけでは、以下のような課題があります。

1. ツール単位の許可設定だけでは閾値を設定できない。
2. 承認要求があるとセッションが止まってしまい、承認が溜まらない

上記二つの問題を完全に解決するには、MCP を自作するか、Claude Code を使わずにマーケティング用のエージェントを自作する必要があります。

オントロジーとは

オントロジーとは、業務に登場するモノ（案件・サイト・アカウント・投稿など。エンティティと呼びます）と、その属性、モノ同士の関係を明示した図です。難しそうな言葉ですが、簡単にいうと、社内で使う言葉の意味と関係を、人と AI の間でそろえるためのものです。

ER 図（データベースの設計図）と似ていますが、目的が違います。ER 図は「データベースをどう作るか」を決めるための図で、オントロジーは「この組織でこの言葉が何を指すのか」をそろえるための図です。第 1 章では、マーケティングになぜオントロジーが必要なのかを説明したので、ここでは実際のオントロジーの書き方を説明します。

• もう少し詳しく: オントロジーの原義

  オントロジーという言葉は、知識工学では「ある領域の捉え方を、明示的に書いたもの」を指します。何があるか（クラス）、それぞれが持つ項目（属性）、何と何がどう関係するか（関係と、その多重度）、そして具体例（インスタンス）まで含みます。古典的な描き方は、範囲を「答えるべき問い」で決め、用語を洗い出し、クラスの階層と属性を決め、多重度と値の型を決め、具体例を入れる、という順番です（スタンフォード大学の入門文書「Ontology Development 101」がよく参照されます）。次に紹介する 4 ステップは、これを実務向けに簡略化したものです。

オントロジーの描き方

オントロジーを描き始める前に、まずこの図で答えるべき問いを 5〜10 個書き出してください。「先月、広告から来たリードのうち商談になったのは何件か」「この予約はどのアカウントに投稿されるのか」のように、人が AI Agent に質問するときの言い方で書きます。図の範囲はこの問いで決まり、描き終えたあとは同じ問いに答えられるかどうかで図を検査します。最初から全体を描こうとせず、いま自動化したい 1 つの判断に必要な範囲から始めて、問いを追加しながら少しずつ広げていきましょう。問いを書き出したら、以下の 4 ステップで描いていきます。

1. エンティティを洗い出す。

業務で名詞として出てくるもの（企業・担当者・リード・商談・契約・アカウント・コンテンツ・広告など）をすべて書きます。媒体ごとの別名になる場合は両方明記してください。例えば LINE の「友だち」とメールの「購読者」を社内では「登録者」と呼ぶ、というように、正式名を 1 つ決めて残りは別名にします。

2. 一意キーを決める。

何をもって「同じ 1 件」とするかを決めます。媒体の中にあるものは媒体側の ID、自分で管理しているものは自社で採番した識別子を使います。企業や担当者のように、自分たちのデータベースでも管理しているが、外部のデータと照合するものは、変更しない識別子と、変更してよい名寄せキー（法人名＋ドメイン、メールアドレスなど）の 2 つを持ちます。ここが曖昧だと、この後のステップをすべてやり直すことになります。

3. 関係を定義する。

エンティティ同士の関係性（「起こす」「持つ」などの動詞）を定義します。関係性には以下のようなものがあります。

• 所属（「持つ」「抱える」）: 上のエンティティが無くなれば、下のエンティティも意味を持たなくなる関係です。
• 派生（「起こす」「結ぶ」「生む」）: 前のエンティティの記録から、次のエンティティの 1 件が作られる関係です。
• 名寄せ（点線）: 機械が名寄せの候補を出し、人が確定するまでは、関係が無いものとして扱います。
• 参照（「使う」「指す」「材料になる」）: 片方がもう片方を使うだけの関係です。相手が無くなっても、自分は残ります。
• 分類（「〜の一種」）: 下のエンティティが、上のエンティティの一種である関係です。上が持つ属性は、下もすべて持ちます。

4. エンティティの状態と操作を定義する。

ステータスは、どの 1 件も必ず 1 つだけに入るように決めます（「分からない」も状態の 1 つです）。そのうえで、状態を変える操作を一覧にします。AI Agent が書き込めるのは、この一覧にある操作だけにしておきます。

例えば口コミ（媒体に付いた評価と本文）の場合、状態は以下の 4 つにして、1 件の口コミが必ずどれか 1 つに入るようにします。あわせて、状態ごとに「その状態に入る条件」を言葉で書いておきます。

本書全体の図

本書全体で使うオントロジーを図にすると、以下のようになります（第 1 章で紹介したものと同じ図です）。各章では、この図の一部を、その章で扱う領域の細かさまで描き直していきます。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  COMPANY["企業"] -->|"担当者を抱える"| CONTACT["担当者"]
  CONTACT -->|"リードを起こす"| LEAD
  SUB["登録者<br/>別名: 友だち（LINE）/ 購読者（メール）<br/>状態: 有効 / ブロック・配信停止"] -.->|"同一人物か<br/>候補 / 確定 / 別人"| CONTACT
  ASSET["成果物 ＝ 発生経路<br/>広告 / 投稿 / 記事・LP"] -->|"発生させる"| EVENT["計測イベント<br/>属性: 媒体側の名前 / 成果として数えるか"]
  EVENT -->|"登録者を起こす"| SUB
  EVENT -->|"リードを起こす"| LEAD["リード<br/>状態: 新規 / 有効 / 商談化 / 対象外"]
  SUB -->|"リードを起こす"| LEAD
  LEAD -->|"商談を起こす"| DEAL["商談<br/>状態: 提案中 / 合意 / 失注"]
  DEAL -->|"契約を結ぶ"| CONTRACT["契約<br/>状態: 開始前 / 稼働中 / 停止 / 終了"]
  CONTRACT -->|"請求を起こす"| INVOICE["請求<br/>状態: 未請求 / 未入金 / 入金済"]
  CONTRACT -->|"案件を持つ"| PJ["運用案件<br/>状態: 稼働中 / 停止 / 終了"]
  PJ -->|"アカウントを持つ"| ACCOUNT["媒体アカウント・サイト<br/>状態: 接続中 / 失効 / 未連携"]
  ACCOUNT -->|"成果物を持つ"| ASSET
  ACCOUNT -->|"数値を生む"| METRIC
  ASSET -->|"数値を生む"| METRIC["数値<br/>属性: 単位 / 期間の基準 / 取得経路<br/>状態: 取得済 / 暫定 / 未取得"]
  METRIC -->|"定例の材料になる"| REPORT["レポート"]
  REPORT -->|"次の商談を起こす"| DEAL

この図は、前の項で説明した 4 ステップを順番に進めることで描けます。ここでは、各ステップの規則をこの図にどう当てはめたのかを順番に説明していきます。自分の業務の図を描くときも、同じ順番で進めてみてください。

はじめに、答えるべき問いを決めます。 本書の主題は「広告費の成果を売上まで追跡できるか」なので、問いもそこから考えます。

• 先月、広告から来たリードのうち、商談になったのは何件か
• この契約は、どの成果物から生まれたリードが元になっているか
• この案件で、いま実際に数字を読み取れるアカウントはどれか
• 既存の顧客への提案は、新規の提案と同じ方法で成約率を出せるか
• 表示回数を、案件の合計として出してよいか

図の範囲はこの問いで決まります。この問いに関係しないもの（社内の勤怠や経費など）は、業務に存在していても図には入れません。

ステップ 1: エンティティを洗い出す

業務で名詞として出てくるものを、まず全部書き出します。例えば、企業、担当者、リード、商談、契約、請求、案件、アカウント、サイト、広告、投稿、記事、LP、友だち、購読者、フォロワー、クリック、コンバージョン、数値、レポート、解約、停止、売上、LTV、継続率です。次に、この一覧を以下の 3 つの規則で絞ります。

• 記録として残るものだけをエンティティにする。

  「解約」「停止」は出来事なので、エンティティにせず契約の一つの状態にします。「失注」も同じ理由で商談の一つの状態にします。

• 計算で出せるものはエンティティにしない。

  売上・LTV・継続率は、請求と契約の行から計算される値です。計算される値もエンティティにしてしまうと、計算される前と計算された後の 2 つの SSOT が存在してしまいます。

• 媒体ごとの別名は 1 つの正式名にまとめる。

  LINE の「友だち」とメールの「購読者」は、どちらも「媒体の中で個別に識別でき、こちらから配信を届けられる人」です。「登録者」を正式名にし、残りは別名として図に書きます。

ステップ 2: 一意キーを決める

エンティティごとに「何をもって同じ 1 件とするか」を決めていきます。

• 広告・投稿・記事・LP を 1 つのエンティティにする。

  どれも媒体（またはサイト）が発行した ID が一意キーです。「作った広告」と「成果を出した広告」を 2 つのエンティティに分けてしまうと、同じ広告が 2 件として数えられ、照合する作業が毎回必要になってしまいます。

• 企業と担当者には、キーを 2 つ持たせる。

  企業と担当者の情報は自社のコントロール外なので、自社で採番した変更しない識別子と、名寄せに使うキー（法人名 + ドメイン、メールアドレス）の二つを持ちます。

ステップ 3: 関係を定義する

エンティティの間の関係性が所属・派生・名寄せ・参照・分類のどれに当たるかを考えます。最初に考えた答えるべき問いから考えると以下の二つのサイクルができます。

• 獲得の循環: 成果物 → 計測イベント → リード → 商談 → 契約 → 運用案件 → 媒体アカウント → 成果物。獲得した契約から次の成果物が作られ、その成果物から次のリードが生まれます。
• 運用の循環: 成果物 → 数値 → レポート → 商談 → 契約 → 運用案件 → 媒体アカウント → 成果物。取得した数値が定例の材料になり、次の提案につながります。

また、ここでエンティティの一意性も改めて整理をしておきます。

• 契約と運用案件を分ける 1 つの契約に複数の案件が含まれることがあるからです。案件ごとに目標も担当者も定例の単位も違うので、契約に直接数値を紐付けると、案件をまたいだ合計の値しか管理できなくなってしまいます。
• 運用案件と媒体アカウントを分ける 1 つの案件が同じ媒体のアカウントを複数持つことがあるからです（1 店舗に 1 アカウントを持つ会社など）。

ステップ 4: 状態と操作を決める

エンティティごとにどのような状態を持つかを考えます。例えば契約のエンティティでは開始前 / 稼働中 / 停止 / 終了の状態を持ちます。次に、エンティティの各状態ごとに許可する操作を書き出します。

最後に、最初に決めた問いに、図の言葉だけで答えられるかを確認します。

• 広告から来たリードのうち商談になったのは何件か → 成果物（広告）→ 計測イベント → リード と辿り、リード.状態 = 商談化 を数える
• 表示回数を案件の合計にしてよいか → 数値.属性の単位と期間の基準がそろっているときだけ合計できる

答えに図に無いエンティティが出てきた場合は、図の側が足りていないということです。エンティティを追加するか、既存の状態にまとめるかして、図を修正してください。

オントロジーをエージェントに渡す

オントロジーが完成したら、グラフ・解決したい問い・エンティティ操作を1つの Skill にまとめ、Agent がオントロジーを扱えるようにします。以下に、口コミ操作の Skill の例を示します。

## この業務のオントロジー
図に無いエンティティ・矢印・状態は作らない。無ければ「定義がありません」と答え、追加を提案する。

（ここに下記オントロジーの図）

## 答えるべき問い（図の検査に使う。答えの出し方も書く）
- 先週、返信していない口コミは何件か → 口コミ.状態 = 未対応 を、投稿日で絞って数える
- この返信はどのアカウントに投稿されるか → 返信 → 口コミ → 媒体アカウント と辿る
- 「判定不能」の口コミは何件あり、何が足りないか → 口コミ.状態 = 判定不能 を数え、属性の欠けを列挙する

## 操作（この一覧に無い操作はしない）
| 操作 | 対象 | 前提となる状態 | 承認 | 取り消せるか |
|---|---|---|---|---|
| 口コミを取得する | 媒体アカウント | 接続中 | 不要 | 読み取りだけ |
| 返信を下書きする | 口コミ | 未対応 | 不要 | 下書きは消せる |
| 返信を投稿する | 返信 | 承認待ち | 必要 | 投稿後は戻せない |
| 対応タスクを起こす | 口コミ | 未対応 | 不要 | 消せる |

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  PJ["運用案件"] -->|"アカウントを持つ"| ACC["媒体アカウント<br>状態: 接続中 / 失効 / 未連携"]
  ACC -->|"口コミを受ける"| REV["口コミ<br>属性: 媒体 / 投稿日 / 評価<br>状態: 未対応 / 返信済 / 対応不要 / 判定不能"]
  REV -->|"返信を起こす"| REP["返信<br>状態: 下書き / 承認待ち / 投稿済"]
  REV -->|"対応タスクを起こす"| TASK["対応タスク<br>状態: 未着手 / 対応中 / 完了"]

Skill を書いたら、/review-watch で呼び出して 1 つ目の検査を行ってみましょう。

複数の Skill が同じグラフを使うようになったら、グラフを Skill の外に出す必要があります。 同じグラフを 2 つの Skill に貼ってしまうと、その時点で SSOT が 2 つになってしまうからです。グラフを Skill の外のリファレンスとして持たせるか、オントロジーだけを管理する Skill を作りましょう。

# 手元だけで動く。グラフは MEMORY_FILE_PATH のファイルに保存される
claude mcp add --transport stdio memory \
  -e MEMORY_FILE_PATH="$PWD/docs/ontology-graph.jsonl" \
  -- npx -y @modelcontextprotocol/server-memory

構造化データと非構造化データ

構造化データとは、Excel の表のように「どこに何が入っているか」が決まっているデータのことです。予約台帳を思い浮かべてください。「日付」「氏名」「人数」「金額」の列が分かれていて、1 行が 1 件の予約になっている。これが構造化データです。非構造化データには、その決まった型がありません。お客様からのメール、口コミの本文、商談の録音、写真、動画などがこれにあたります。世の中のデータの大半（8 割以上とも言われます）は、実はこちらです。

マーケティングの業務で扱うデータをこの 2 つに分けてみると、以下のようになります。

AI Agent を使うと、この 2 つの扱い方が大きく変わります。これまでは、非構造化データを集計しようとすると人が 1 件ずつ読んで分類するしかなく、件数が多いと手付かずのまま残ってしまうことも多かったと思います。今は AI に読ませることで、決めた項目に沿って表に変換することができます。ただし、計算は構造化データにしてから行う必要があります。LLM に長い表を読ませて合計を出させると、行を読み飛ばしたり桁を取り違えたりすることがあるからです。集計はコード（Function Call で呼ぶ計算のツールや、データベースへの問い合わせ）に任せて、LLM にはその結果を読んで説明させる、という分担にするのがおすすめです。

非構造化データを構造化する

非構造化データを AI に読ませて表に変換する作業を、抽出と呼びます。抽出の精度は、AI に読ませる前に何を決めておくかで決まります。事前に決めておくべきことは、以下の 5 つです。

1. 取り出す項目を決める。 項目は、答えたい問いから逆算して決めます。「先月、料理への不満は何件あったか」を知りたいなら、必要なのは「話題」と「評価の向き」の 2 つだけです。問いに使わない項目は取り出さないようにしましょう。項目を増やすほど、1 件ごとの判断の誤りも増えていくからです。
2. 値の候補を一覧にする。 「話題」を自由記述にすると、「料理の味」「味」「おいしくない」がそれぞれ別の値として数えられてしまいます。「接客 / 料理 / 価格 / 清潔さ / 待ち時間 / その他」と候補を決めておき、どれにも当てはまらなければ「その他」、読んでも決められなければ「判定不能」へ入れます。オントロジーの状態と同じく、どの 1 件も必ずどれか 1 つに収まる形にします。
3. 根拠を原文から引用させる。 値ごとに、判断の元になった原文の一部をそのまま残させます。引用された文が原文に見当たらなければ、その値は AI が作ったものだと分かります。人が確認するときに原文を開き直さなくて済む、というメリットもあります。
4. 原文に無い値は作らせない。 口コミに来店人数が書かれていなければ、人数は空欄のままにしておき、「2 名くらい」のように推測で埋めさせないようにします。縮退のパターン 3 と同じ考え方です。
5. どの手順で抽出したかを記録する。 抽出した日時、使ったモデル、項目と候補の一覧（手順の版）を、抽出結果と一緒に保存しておきます。途中で候補の一覧を変えると、変える前と後の件数は比べられなくなります。版の違う結果を同じ表で集計しないように注意してください。

口コミを抽出する Skill に落とし込むと、この 5 つは以下のように書けます。

## 口コミの抽出（1 件ごとに次の項目を返す）
| 項目 | 値の候補 | 決められないとき |
|---|---|---|
| 話題 | 接客 / 料理 / 価格 / 清潔さ / 待ち時間 / その他（複数可） | 判定不能 |
| 評価の向き | 肯定 / 否定 / 混在 | 判定不能 |
| 返信の要否 | 要 / 不要 | 判定不能 |
| 根拠 | 判断の元になった原文の一部をそのまま引用する | 空欄 |

- 原文に書かれていない値は作らない。空欄のまま返す
- 口コミは ID で指定する。本文だけを渡さない（どの口コミの結果か分からなくなる）

抽出の結果は、例えば以下のような表になります。2 行目の口コミのように、判断の材料が無いものは無理に埋めずに「判定不能」のまま残しておきます。

LLM を使わない分析の方法も選ぶ

非構造化データの分析だからといって、必ずしも LLM を使う必要はありません。件数が多い場合や、分類の軸がまだ決まっていない場合、毎月同じ基準で比べ続けたい場合などは、LLM 以外の方法のほうが向いていることがあります。LLM が登場する前から使われてきた方法を 3 つ紹介します。

毎回 LLM に頼らないほうがいい理由は、以下の 3 つです。

• 費用と時間が件数に比例する。 LLM は 1 件ごとに文章を生成します。件数が増えれば、費用も時間もそのまま積み上がります。
• 同じ入力から同じ結果が出るとは限らない。 出力のばらつきを抑える設定（温度 0）にしても、サーバー側の計算の順序の違いなどで、同じ入力に違う出力が返ることがあります。先月との件数の差が、口コミの変化なのか出力の揺れなのか、見分けにくくなります。
• 軸が決まった分類では、学習させた小さなモデルのほうが正確なことがある。 感情・賛否・立場などの分類で、正解データで学習させた小さなモデル（RoBERTa など）が、学習させずに指示だけで分類させた GPT-4 や Claude Opus を一貫して上回ったという報告があります（Bucher & Martini, 2024）。

LLM と組み合わせる

LLM が得意なのは、文章を読んで説明することと、まとまりに名前を付けることです。数える・まとめる・大量に振り分けるといった作業は他の方法に任せて、LLM はその前後で使うようにすると、費用・再現性・精度のどれも落とさずに済みます。よく使う組み合わせは以下の 3 つです。

1. 軸を見つける: LLM で 1 件ずつ話題を書き出す → クラスタリング → まとまりに名前を付ける。 最初に LLM が、1 件ごとに「何について書かれているか」を短い言葉で書き出します（「提供までの待ち時間」「料理の量」など）。候補の一覧はまだ無いので自由記述で構いません。1 件に話題が複数あれば、複数書かせます。書き出した言葉は埋め込みに変換してクラスタリングし、意味の近いもの同士をまとめます。あとは、まとまりごとの代表的な言葉を見て、LLM か人が名前を付けるだけです。LLM の書き出す言葉が「待ち時間」「提供が遅い」と揺れても、クラスタリングが同じまとまりに入れてくれるので、この段階で候補を揃える必要はありません。
2. 大量に分類する: LLM で正解データを作り、小さなモデルに学習させる。 LLM に数百件を分類させ、それを人が確認して正解データにします。このデータで小さな分類モデルを学習させれば、残りの全件も、翌月以降の分類も、そのモデルで回せます。正解データを LLM に作らせて大丈夫なのか、と思うかもしれません。14 の分類タスクで、GPT-4 が付けたラベルで学習させたモデルは、人が付けたラベルで学習させたモデルと同程度の精度だったという報告があります（Pangakis & Wolken, 2024）。
3. 例外だけ LLM に回す: キーワードで振り分けてから、残りを LLM が読む。 「返金」「予約」のように語で拾えるものは、先にキーワードで振り分けてしまいます。LLM が読むのは、どれにも当てはまらなかったものと、判定が割れたものだけです。

例えば口コミ 1 万件の話題を分類する場合、1 の組み合わせは以下のような流れになります。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  A["口コミ 1 万件"] --> B["LLM が 1 件ごとに<br>話題を短い言葉で書き出す<br>（自由記述・複数可）"]
  B --> C["書き出した言葉を<br>埋め込みに変換"]
  C --> D["クラスタリング<br>まとまりと外れ値に分ける"]
  D --> E["まとまりごとに<br>LLM か人が名前を付ける"]
  E --> F["人が候補の一覧を確定する"]
  F --> G["翌月からは確定した候補で分類<br>（前の項の抽出、Jev、小さな分類モデル）"]
  G --> H["毎月の件数を集計"]

分類に特化したモデルを使う: Jev

最近では、分類だけを行うモデルを API として提供するサービスも出てきました。その一つが、OpenAI 出身の研究者が創業した TypeSafe AI の Jev です。2026 年 9 月 15 日に早期アクセス（申請制）が始まりました（ITmedia AI+、The Batch）。

Jev は文章を生成しません。テキスト（文字列・JSON・テキストの配列）と型の決まった質問を渡すと、確率付きの答えだけが返ってきます。質問の型は以下の 3 つです。

• Choice: 決めた選択肢の中から 1 つを選び、選択肢ごとの確率と確信度を返す（口コミの話題を「接客 / 料理 / 価格 / 清潔さ / 待ち時間 / その他」から選ぶ、など）
• Score: 決めた段階で点を付ける（不満の強さを 5 段階で付ける、など）
• Noul: はい / いいえの確率を返す（返信が必要か、など）

AI Agent に分析を頼むときは、どの方法を使うかを Skill に書いておくようにしてください。書かずに任せてしまうと、AI Agent は全件を自分で読もうとして、コンテキストと費用を使い切ってしまうことがあります。Claude Code はコードを書いて実行することができるので、埋め込みの変換やクラスタリングはコードとして実行させ、LLM 自身には出てきたまとまりに名前を付けるところだけを任せるのが効率的です。

非構造化データにメタデータを付ける

非構造化データの中には、表にしないほうがいいものもあります。商談の議事録、顧客とのやり取り、クリエイティブの制作意図など、ニュアンスや文脈が大事な情報は、原文のまま保存したほうがいい場合があります。ただし、原文のまま保存する場合でもメタデータ（そのデータについての情報。いつの、誰の、何の資料か）は付けておいてください。AI Agent は資料を検索してから読むので、メタデータが無いと本文の全文検索に頼るしかなく、別の案件の似た資料を読んで答えてしまうことがあります。

最低限、以下の項目は付けておきましょう。

構造化データでも非構造化データでも、同じ情報があちこちに保存されていると、どれを読めばいいのかが決まりません。読むべき 1 箇所をどう決めるかについては、次の節の SSOT で説明します。

SSOT（Single Source of Truth）とは

AI によってツールや AI Agent を作る手間が減ると、各自が自分用の自動化を作り始めます。例えば、A さんは顧客情報を自分の Notion に整理し、B さんは売上データを自作の Slack Bot に持たせ、C さんは承認の流れを自分のエージェントが管理するスプレッドシートに置く、という状態です。この状態で「最新の顧客情報はどれか」と聞かれても、3 つの情報源の内容が食い違っていて答えられません。ツールを作れば作るほど、正しい情報がどこにあるのかが分からなくなってしまいます。

これを防ぐための考え方が SSOT（Single Source of Truth）です。どの AI Agent も同じ情報源を参照するようにし、他のツール上の情報はその写しとして扱います。AI Agent を追加するときも SSOT を参照させるだけにして、情報の複製は作りません。こうしておけば、内容が食い違ったときに直す場所が 1 箇所に決まり、直した内容はすべての AI Agent に反映されます。

SSOT とするデータは、AI Agent から操作しやすいように、構造化されていて、かつ API から操作できる場所に保管しておくのがおすすめです。

例えば、スプレッドシートと Notion を使っている場合は、構造化されていてかつ API が整っている Notion のデータベースに情報を寄せるのがおすすめです。顧客にどうしてもスプレッドシートの形式で見せたい場合や、Notion で複数の箇所から参照させたいときは、SSOT から別の場所へ一方向に同期する仕組みを作っておいたり、Notion のビューの仕組みを活用したりしましょう。ストレージ上にテキストファイルとして保存してしまっている場合は、データウェアハウスなどを活用して、構造化されたデータにして保存しておきましょう。

ハーネスを整備する

振り返ってみると、この章で説明してきた規約・Skill・MCP・パーミッション・オントロジー・SSOT は、どれも LLM そのものには手を加えていません。すべて LLM の周りに置く仕組みです。この周りの仕組み全体をハーネスと呼びます。ハーネスはモデルと仕事の間に立ち、文脈を集め（規約・Skill・メモリ）、ツールを呼び（MCP）、境界を守り（パーミッション）、結果を検証し、セッションをまたいで作業を引き継ぐ役割を持ちます。Claude Code や Codex 自体もハーネスの実装ですし、この本で AI Agent がマーケティングを自動運転できるようにツールやオントロジーを整備するのもハーネスです。

ハーネス自体を AI Agent に自己改善させることも可能です。実行する → 記録を残す（ログ・成果物）→ 失敗の原因を特定する → メモリ・パーミッション・オントロジー・スキルのどれかを直す → 直した状態で検証する → 次の実行に進む。この一周を Skill にして定期的に回すことで、自己改善が可能です。

特にマーケティングにおいては、この自己改善が欠かせません。理由は、ツール側の変化の速さにあります。広告媒体の API は数か月ごとに新しいバージョンが出て、前のバージョンまで取れていたインサイトが取れなくなることもあります。SEO も例外ではありません。検索結果の形式や AI の回答欄の扱いが変わるたびに、順位の測り方と読み方を変える必要があります。一度整えたハーネスも、放っておけば外側の変化で壊れていきます。そのため、実行のたびに記録を残し、ずれに気づいたらメモリ・パーミッション・オントロジーに書き戻す運用を、最初から仕組みとして組んでおくことが重要です。

章のまとめ

• エージェントは、LLM に Function Call（ツール）、RAG（外部の資料の参照）、ReAct（思考と行動の繰り返し）を加えたもの。構成要素はプロファイル・メモリ・計画・自己修正・行動の 5 つ
• iPaaS は人が設計した手順を毎回同じ経路で動かし、エージェントは状況を見て手順を組み立てる。定型の処理は決まった手順で、非定型の処理はエージェントで動かす。AI が作る設定・手順・インフラはコードで管理し、正本を 1 箇所に決める。MCP とスキルを整備すると、API の仕様と業務の手順の棚卸しも進む
• コーディングエージェント（Claude Code / Agent SDK）を基盤にすると、必要な機能がそろい、手元と本番の挙動が一致する。エージェントを起動する経路は 1 つにする
• サーバー上で動かすエージェントにはターミナル（Bash）を使わせない。鍵を渡さない設計を、ターミナル経由で回避されないようにするため
• スキルは手順書と同梱ファイル。自動では読み込まれないので「検索して読む」指示を依頼のたびに渡し、取り違えやすい依頼は表で固定する。縮退先を書く
• サブエージェントは役割ごとに作業を分ける仕組み。コンテキストの分離、ツールの制限、並列実行の 3 つが利点で、担当範囲と返す内容を書かないと担当外まで変更する
• MCP は、鍵をサーバー側に置いたままツールを提供するための仕組みでもある。エージェントには使い捨てのトークンだけを渡す。使い方は 2 つあり、サーバーと鍵を分ける
• API と CLI は、人やプログラムが呼び出すことを前提にした仕組み。エージェントに直接呼び出させると、鍵を読める場所に置くことになる、読み取りと書き込みを区別できない、推測で呼び出して間違った数字が返る、失敗が伝わらない、という課題がある。MCP でラップし、鍵はサーバー側に置き、ツールは業務の単位で作り、読み取りと書き込みを分け、失敗の変換は 1 箇所にまとめ、直接呼び出す経路は廃止する
• 「読み取りだけ」のツールは宛先を制限せず、「操作できる」ツールだけを許可リストに限定する。拒否するときは代わりの手段を書く
• パーミッションは、外部に反映される操作を、呼び出したその場で人に確認させる仕組み。claude.ai のコネクタは「常に許可」「承認が必要」「ブロック」の 3 段階、Claude Code は settings.json の allow / ask / deny（deny → ask → allow の順に評価）とモードで決める。守らせるのはアプリの側で、プロンプトに書いても許可の範囲は変わらない
• 確認画面で許可した呼び出しは、表示された内容のまま 1 回だけ実行される。承認キューは無く、確認は会話を操作している人に出る。人がいない実行（claude -p や定期実行）では確認が必要な呼び出しは断られるので、定期実行は読み取りと下書きまでにする
• MCP のツールは名前でしか判定できない。読み取りと書き込み、作成と配信開始、予算の増額と減額を別のツールに分ける。Claude Code の auto モードでは、ルールに無い操作を自動の判定が許可するので、外部に反映するツールは ask に明示する
• 許可の記録はツールを提供する側に残らないので、書き込みの実行記録はツールの側で残す。組織では claude.ai の組織の設定と managed settings で固定する。claude.ai の個人の設定は Claude Code に届かないことがあるので、settings.json にも書く
• オントロジーは 4 ステップで描く。エンティティ → 一意キー → 関係と合流する段階 → 状態遷移と操作。答えるべき問いで範囲を決め、描き終えたら同じ問いで検査する
• 図は獲得までで終わらせず、契約から先（運用案件・媒体アカウント・成果物・数値・請求）までつなげて循環させる。エンティティは名詞だけ、行為は矢印の名前、出来事は状態として持つ
• 一意キーは付け直さない、状態は排他かつ網羅、正本は 1 箇所、単位と用語は取得経路ごとに確定させる
• エージェントに渡すのは図そのものではなく、問いの一覧、操作の一覧、機械が読める 1 つのファイル。書き込めるのは操作の一覧にあるものだけにする
• オントロジーの置き場は規模で決める。小規模は SKILL.md の中の mermaid と 2 つの表、複数のスキルで使うならリポジトリの YAML 1 ファイルを CLAUDE.md から参照、関係を辿る問いが多ければ memory MCP の知識グラフ。どの置き場でも「図に無いエンティティ・矢印は作らない」を書き、正本は 1 つ（グラフは YAML の写し）にする。効果は /usage をセッションを分けて比べて確かめる
• 図はもう 1 枚ある。用途分岐グラフ（手順の図。どの依頼で何を使い、どこで人が承認するか）。規約には実際に起きた事故を書く
• スキルの本文は見出しの並びを揃える（前提・全体フロー・常に守る規則・手順・うまくいかなかったこと・出力の型・縮退先・関連スキルと参考資料）。手順は試す順番を番号で書き、成功したら止める。参考資料には読む場面を添える
• スキルをまたぐ規則（縮退・情報収集・レポートの書き方）は 1 本にまとめて参照させ、各スキルには差分だけを書く。レポートは、最初の 1 画面で「良かったか・その理由・次にやること」が分かる形にする
• 縮退では、素材やデータの品質を超える見せ方をせず、何があれば上の段階に上がるかを書く。提供の依頼は 1 回で完結させ、先に今作れるものを作る。サブエージェントには返す項目を先に指定し、同時に動かす数を決める
• LLM の周りに置く仕組み全体がハーネス。ハーネスエンジニアの仕事は、エージェントが失敗した理由をメモリ・パーミッション・オントロジーに書き戻すこと。モデルは変えず、評価と許可の範囲はループの外に置き、記録はエージェントが読む場所に残す。古くなった部品は外す。媒体の API・指標名・管理画面は数か月単位で変わり、壊れてもエラーで止まらずに数字が静かにずれるので、点検の一部をエージェントに任せる運用を最初から組む

演習

1. 自分の担当業務で、エージェントに任せたい依頼を 3 つ書き、それぞれについて「読み取りだけの操作」と「外部に反映される操作」を分けてください。後者が、パーミッションで確認を必須にする対象です。
2. その 3 つのうち 1 つを、SKILL.md の frontmatter として書いてください。「どんな言い方で頼まれたら使うか」と「似ているが、このスキルでは扱わない依頼」を description に入れます。
3. 自分の会社の設定を「サイト・案件・契約・サービス全体」の 4 つの持ち主に振り分けてください。振り分けに迷った設定が、最初に事故を起こす可能性が高い設定です。
4. 自分の担当業務のオントロジーを 1 枚描いてください。先に「答えるべき問い」を 5 個書き、描き終えたらその 5 問に答えられるかで検査します。答えられない問いがあれば、それに必要なエンティティが次に追加するものです。
5. 最もよく使う媒体を 1 つ選び、第 1 章の 4 つの接続方法（公式の MCP・公式の API / CLI・OSS と自作・スクレイピング）のどれで接続しているかを確認してください。API か CLI であれば、エージェントに提供したいツールを「読み取り」と「書き込み」に分けて 5 つまで書き出し、それぞれの説明文に単位と前提を書きます。これが MCP でラップするときの設計図になります。
6. 手元の Claude Code の /permissions と、claude.ai のコネクタのツール権限を開いてください。演習 1 で「外部に反映される操作」に分けたツールが「常に許可」や allow に入っていないかを確認し、入っていれば「承認が必要」や ask に移します。あわせて、Claude Code がどのモードで始まっているかも確かめてください。auto で始まっているなら、外部に反映するツールが ask に書かれているかを確認します。
7. 演習 2 で書いた frontmatter の下に、この章の表の順で本文の見出しを並べてください。「うまくいかなかったこと」を 3 つ、「縮退先」を 2 つ書き、縮退先の各行には「何があれば完全版に上がるか」を添えます。
8. 最近作ったレポートを 1 本選び、レポートの書き方の規範にある自己チェックの 4 項目で確認してください。当てはまらない項目があれば、それが共通の規範に最初に書き足す規則です。
9. 演習 4 で描いたオントロジーを mermaid にして、演習 2 のスキルの SKILL.md に「この図に無いエンティティと矢印は作らない」の 1 行と一緒に貼ってください。演習 4 の 5 問のうち 1 問を Claude Code に投げ、答えの出し方が図のエンティティと矢印の名前で書かれているか、図に無いエンティティを作っていないかを確かめます。図に無いエンティティが出てきたら、それが図に次に足すものです。