AIエージェントまわりの話題で、2026年に入ってから急に見かけるようになった言葉があります
それがハーネスエンジニアリングです

ざっくり言うと、AIモデル本体ではなく、その周りを取り囲む”足場”を設計するという考え方です
ハーネスエンジニアリングとは何なのか、なぜ今この言葉が広まっているのかを、初心者向けにかみ砕いて整理してみます

この記事は「AIの○○エンジニアリング」連載の3本目です
前回はコンテキストをどう積むかという話でしたが、今回はそのコンテキストを積んだり道具を渡したりする外側の仕組みそのものに目を向けます

前回のおさらいをしたい方は、こちらもどうぞ

あわせて読みたい

コンテキストエンジニアリングとは AIに渡す文脈の設計 コンテキストエンジニアリングとは AIのコンテキストウィンドウに何を積むかを設計する考え方です プロンプトエンジニアリングとの違いや システムプロンプト RAG メモリ CLAUDE.md など構成要素を初心者向けに噛み砕いて解説します

ジャベ雄

「モデルが賢い」だけでは説明できない部分の話です

ハーネスエンジニアリングとは?ざっくり言うと

結論から言うと、ハーネスエンジニアリングとは、AIモデル本体をのぞいた「モデルを取り囲むソフトウェア基盤全部」を設計する営みのことです
ツールをつなぐ・途中経過を覚える・入力欄に何を載せるか・失敗したら立て直す、といった裏方の仕組みをまとめて指します

ハーネス(harness)という英単語は、もともと馬具や、登山・パラシュートで体を支える装具を意味します
暴れる馬や高所の体を、道具でしっかり支えて安全に働かせる、そんなニュアンスの言葉です

AIの世界では、この言葉が「賢いけど、そのままだと何もできないモデル」を実際に仕事させるための装具一式という意味で使われます
モデルは頭脳、ハーネスは体や道具や段取り、というイメージが近いです

ここで大事なのは、モデルとハーネスは別モノという点です
同じモデルでも、取り囲むハーネスの出来しだいで、できる仕事の質はかなり変わってきます

この「同じ頭脳なのに、周りの装具で結果が変わる」という感覚が、ハーネスエンジニアリングの一番の勘どころです
あとの章で、その中身を具体的に見ていきます

なぜ2026年に「ハーネス」が主流の言葉になったのか

この言葉がここまで広まった背景には、AIの作り方をめぐる言葉の進化ラダー(はしご)があります
ざっくり言えば、注目される設計対象が少しずつ外側へ広がってきた、という流れです

• プロンプトエンジニアリング:指示文(プロンプト)そのものを工夫する段階
• コンテキストエンジニアリング:入力欄ぜんぶに何を積むかを設計する段階(前回のテーマ)
• ハーネスエンジニアリング:そのコンテキストを扱う外側の仕組みごと設計する段階(今回)

指示文 → 文脈 → 外殻、と設計する範囲がだんだん広がってきたわけです
2026年に入って、この一番外側の「外殻(ハーネス)」に注目が集まった、というのがおおまかな流れになります

背景には、2026年ごろから長く動き続けるエージェントが実用になってきた、という事情もあります
数十分から数時間かけて自律的に作業させると、途中でつまずいたり脱線したりが増えるので、それを支える外側の仕組みの出来が、そのまま成果を左右するようになってきたわけです

「ハーネス」という語自体は公式も使っている

ハーネスという語自体は、一部の界隈で使われているような言葉ではありません

Claude を開発する Anthropic は、2025年11月に公開した記事で、自社のClaude Agent SDK(エージェントを作るための開発キット)を “a general-purpose agent harness”(汎用のエージェントハーネス)とはっきり呼んでいます
つまり「モデルを取り囲む装具」という意味でのハーネスは、公式の文書にも登場する実在の用語です

一次ソースを確認したい方はこちらです
Effective harnesses for long-running agents(Anthropic・英語)

「独立した分野」と呼ぶのは新しめのフレーミング

一方で、「ハーネスエンジニアリング」を一つの独立した専門分野として名指す言い方は、2026年になって広まった新しめの枠づけです
ベンダーのブログや技術記事から広がったフレーミングで、教科書に載っている確立した分類とはまだ言えません

「2024年はプロンプト・2025年はコンテキスト・2026年はハーネス」といったキャッチフレーズも見かけます
これは分かりやすい世代論として語られているだけで、公式に定められた区分ではない、という点は押さえておきたいです

ジャベ雄

語じたいは実在・分野名としては新興、この温度感で読むと安全です

ハーネス(外殻)は大きく6つの部品でできている

ハーネスと言われても、中身が見えないとピンとこないと思います
ここでは、モデルを取り囲む外殻を6つの部品に分けて見てみます

この6つのうち、コンテキスト管理を掘り下げたのが前回のコンテキストエンジニアリングでした
そして次回は、オーケストレーションループを掘り下げるエージェントループの回になります

連載でバラバラに見えていたテーマが、実はハーネスという一つの外殻の部品どうしだった、という見取り図です
今回はその外殻の全体像を押さえておく、という位置づけになります

モデルが賢いのではなく、外殻が賢さを引き出す

ここがこの記事で一番伝えたいところです
モデルの地力だけで決まるのではなく、周りの足場が賢さを引き出しているという見方です
効いているのはモデルと足場の両方で、そのうち足場の側の働きが見落とされがちだと思っています

たとえば同じ人でも、道具も資料も何もない部屋に放り込まれたら、実力を出しきれません
逆に、必要な資料・使い慣れた道具・失敗しても戻れる段取りがそろっていれば、同じ人でもぐっと良い仕事ができます

AIで言えば、資料を丸ごと読めるか・途中結果を覚えておけるか・失敗したときにやり直せるか、そのあたりが「道具のそろった部屋」かどうかにあたります
同じモデルでも、この段取りが足りないと、同じ問いに何度も答えを外す、ということが起きます

AIエージェントも同じで、モデルの地力は同じでも、ハーネスの出来で成果が大きく動きます
ここを混同すると「新しいモデルが賢くなった」と思っていた変化が、実は「周りの足場が良くなっただけ」だった、というズレが起きます

同じモデルでも足場でスコアが動く

この「足場で差がつく」現象は、コード生成の力を測るベンチマーク(性能テスト)でもよく話題になります
プログラムの課題をどれだけ解けるかを測るSWE-bench系のテストがその代表です

ここでは、モデル素の力を比べるために、あえて最小限のハーネスを使う工夫がされています
そのうえで、各社が自前で作り込んだ足場をかぶせると、同じモデルでもスコアが10〜30ポイントほど上がるという報告もあります(公開リーダーボードの一例)

数値は測り方や時期で変わるので鵜呑みは禁物ですが、足場を変えるだけで結果が大きく動くという傾向は、あちこちで共通して見られます
「モデルだけ見ていても半分しか分からない」というのが、ハーネスに注目する理由です

AIで仕事を減らしたい方へPR

AI鬼管理｜Claude Code活用の業務自動化トレーニング

Claude Code を業務の自動化に使うためのトレーニングです
いきなり申し込む形ではなく、まずは無料の業務効率化診断(オンライン面談)から始められます

無料の業務効率化診断を見てみる

Notta｜AI自動文字起こし

会議や動画の音声を自動で文字にするサービスです
議事録や書き起こしの手作業を減らしたいときに

Nottaを見てみる

scaffold(足場)とハーネスはどう違うのか

ハーネスを調べていくと、たいていscaffold(スキャフォールド)という言葉に出くわします
日本語にすると「足場」で、建設現場に組む、あの足場と同じ単語です

結論を先に言うと、scaffold と harness は、ほぼ同じものを指す言葉です
どちらも「モデルを取り囲むソフトウェアの基盤」を意味していて、はっきり線を引ける別物ではありません

違うのは、主にニュアンスと、よく使われてきた場面です
ざっくり並べると、こんな呼び分けになります

おおまかには、scaffold は研究や評価の文脈で長く使われてきた言葉で、harness は製品・実行環境の文脈で2026年に主流化した言葉という住み分けです
新しく記事を読むときは、どちらが出てきても「あぁ、外殻の話ね」と同じ引き出しに入れて大丈夫です

Claude Code はハーネスエンジニアリングの実例

抽象的な話が続いたので、身近な実例に落とします
私が普段使っているClaude Code(Claude にファイル操作やコマンド実行までまかせられるツール)は、まさにハーネスの分かりやすい例です

あらためて振り返ってみると、私がClaude Codeを使いこんで「便利になった」と感じた場面の多くは、モデルが急に賢くなったからではありませんでした
ファイルを読ませる・コマンドを走らせる・失敗したら差し戻す、といった周りの段取り(=ハーネス)が整ったからという感覚のほうが近いです

ちなみに Anthropic 自身も、Claude Code と同じ土台をClaude Agent SDKとして公開していて、これを「エージェントハーネス」と位置づけています
つまり Claude Code は、ハーネスを実際の製品にした一例だと言えます

拡張機構はぜんぶハーネスの部品だった

Claude Code には、いわゆる拡張機構と呼ばれる仕組みがいくつかあり、この記事では代表的な4つを取り上げます
先ほどの「6つの部品」に重ねて見ると、それぞれの位置づけが分かりやすくなります

• MCP:外部の道具やデータにつなぐ規格 → ハーネスのツール統合にあたる
• サブエージェント(Agents):役割ごとに小さな担当を立てて任せる → オーケストレーションにあたる
• Hooks:処理の途中に自動で割り込ませる仕掛け → 検証と回復・権限にあたる
• Skills:再利用できる手順書をまとめておく仕組み → 段取りを部品化する働き

つまり、Claude Code の拡張機構をいじるという作業は、実は自分の手でハーネスを組み替えているのと同じことなんです
拡張機構そのものの入門は、こちらで別途まとめています

Claude Code拡張機構入門(Skills / Agents / MCP / Hooks)
Claude Code設定ファイル早見表

同じ枠組みは Claude 以外にもあります
OpenAI のCodex CLIや Google の Gemini CLI も、モデルの周りに独自のハーネスを組んだ製品で、各社が自前の外殻で腕を競っている、という構図です

なので、これからエージェント系のツールを選ぶときは、モデル名だけでなく、どんなハーネスを積んでいるかにも目を向けると、実際の使い勝手が見えてきます
同じモデルを積んでいても、使える道具の多さや失敗したときの粘り強さで、体感はけっこう変わってきます

ジャベ雄

「賢いモデル選び」と同じくらい「良い足場選び」が効いてきます

ハーネスエンジニアリングのよくある質問

まとめ 次回はハーネスの中の”ループ”を深掘り

最後に、この記事の要点を振り返っておきます

• ハーネスエンジニアリングとは、モデルを取り囲む外殻(足場)を設計する営み
• 定式は Agent = Model + Harness、同じモデルでも足場で成果が変わる
• 外殻はツール統合・メモリと状態・コンテキスト管理・ループ・検証と回復・権限の6部品
• scaffold とハーネスはほぼ同義、語感と使われる場面の違いくらい
• Claude Code はハーネスの実例、拡張機構はその部品

今回は外殻の全体像を押さえました
次回は、その中でも司令塔にあたるオーケストレーションループ、いわゆるエージェントループを一段深く掘り下げます

「考える→動く→結果を見る→また動く」をどう回すか、その設計に注目したエージェントループの話です
続きは次回のループエンジニアリングでどうぞ

あわせて読みたい

エージェントループとは 推論と行動を繰り返す仕組み AIエージェントが自分で考えて動き続ける正体がエージェントループです この記事では推論 行動 観測を停止条件まで繰り返す基本のしくみを ReActの由来やClaude Codeの実例とあわせて解説し 後半では2026年に登場したループエンジニアリングという新しい考え方も等身大で紹介します

連載「AIの○○エンジニアリング」の記事一覧

• 連載ハブ:AIの5つの○○エンジニアリング総まとめ
• 1本目:プロンプトエンジニアリングとは
• 2本目:コンテキストエンジニアリングとは
• 3本目:ハーネスエンジニアリングとは(この記事)
• 4本目:エージェントループの話
• 5本目:グラフエンジニアリングの話

用語をまとめて確認したい方は、AI用語集もあわせてどうぞ

私のおすすめ本PR

VBAPythonAI・ClaudePC仕事術

Excel マクロ&VBA やさしい教科書 Office 2024/2021 Microsoft 365対応

Amazon楽天

てっとり早く確実にマスターできる Excel VBAの教科書 改訂新版

Amazon楽天

Excel マクロ/VBA 今日から使える業務の自動化入門

Amazon楽天

VBAエキスパート公式テキスト Excel VBAベーシック

Amazon楽天

［最速入門］ChatGPTに任せる Excelマクロ&VBA

Amazon楽天

退屈なことはPythonにやらせよう 第3版

Amazon楽天

シゴトがはかどる Python自動処理の教科書

Amazon楽天

もっとシゴトがはかどる Python×Excel×AI 業務自動化の教科書

Amazon楽天

Python2年生 スクレイピングのしくみ 第2版

Amazon楽天

スッキリわかるPython入門 第2版

Amazon楽天

実践Claude Code入門

Amazon楽天

Claude CodeによるAI駆動開発入門

Amazon楽天

開発効率をアップする! Claude Code 実用入門

Amazon楽天

Microsoft 365 Copilot踏み込み活用術

Amazon楽天

できるClaude & Claude Cowork

Amazon楽天

できる人のパソコン仕事術 なんと効率10倍!

Amazon楽天

できるWindows 11パーフェクトブック 困った!&便利ワザ大全 改訂3版

Amazon楽天

できるポケット 時短の王道 ショートカットキー全事典 改訂4版

Amazon楽天

ビジュアル ショートカットキー時短ワザ事典

Amazon楽天

取り急ぎ、パソコン仕事の基本だけ教えてください！

Amazon楽天

ジャンルごとに私のおすすめからランダムで5冊を表示しています

Claudeの設定メニュー、開いてみたら項目が多くて、どこを触ればいいのか迷った経験はありませんか？
Claudeデスクトップアプリの設定は、大区分が3つ・その中に中区分が15項目という構成になっています

この記事では、その15項目をまるごと順番に解説していきます
公式ドキュメントで裏を取りながら、初心者がまず押さえたい設定と、うっかり触ると危ない設定を切り分けて紹介するので、設定画面の全体像がつかめるはずです

設定メニューを開いたところ。左に大区分3つ・全15項目が並びます

本題に入る前に、設定メニューの開き方だけ確認しておきます
迷いやすいのは最初の入り口だけで、開いてしまえばあとは区分を切り替えるだけです

まず前提 この画面は「アプリ全体」の設定です

先に大事な前提を1つ
この設定メニューでは、コード開発（Code）やおまかせ作業（Cowork）といった一部の機能だけでなく、Claudeデスクトップアプリ全体の設定ができます

いまのアプリは画面上部がHome と Code の2つのタブに分かれていて、Homeの中でチャットとCoworkを切り替えます
その全部にまたがる設定が、この1つのメニューにまとまっている、というわけです

アプリの構成はわりと頻繁に変わるので、タブの並びは自分の画面で確認してください

ジャベ雄

つまりここは、コード専用ではなくアプリ全体をまとめて調整する場所なんです

設定メニューの全体像 大区分3・中区分15の早見表

細かい話に入る前に、15項目をひとことずつでまとめた早見表を置いておきます
「今どこの話をしているか」を見失ったら、ここに戻ってきてください

この15個を、上から区分ごとにまとめて見ていきます
ぜんぶ触る必要はないので、気になった項目だけ拾い読みしてもらってもかまいません

【設定】プロフィール・外観・アカウント周り

まずは「設定」区分の入り口、一般から
ここは氏名やアバター、そして「Claudeには何とお呼びしてほしいですか？」という呼び名の設定が並びます

意外と便利なのがClaudeへの指示（カスタムインストラクション）です
ここに書いた内容は、チャットでもCoworkでも常に考慮されます
「説明は簡潔に」「コードにはコメントを付けて」のような自分の好みを一度書いておくと、毎回頼まなくてよくなって楽になります

そのすぐ下には外観（テーマ）やチャットフォント、モーションの設定もあります
外観はシステム・ライト・ダークから選べるので、目が疲れにくい方を選んでおくといいです
さらに下には、音声（言語・速度）や、レスポンス完了などの通知のオン・オフも並びます

アカウント・請求・使用量

残り3つはお金とアカウントまわりです

• アカウント … 今のプランの確認や、アカウントの削除ができます（削除はプランによって先に解約が必要）
• 請求 … サブスクの契約状況や支払い方法、プラン変更・解約を扱います
• 使用量 … 今の期間でどれくらい使ったか、上限までの余裕を確認できます

使用量については、Claude Codeの画面でもモデル選択の横にある使用量のリングから、コンテキストの消費とプランの使用状況をのぞけます
プランの使用量は複数の画面で共有される点だけ覚えておくと、数字の見方で混乱しません

【設定】プライバシー ここは最初に確認したい

15項目のなかで、私が「まず一度は開いてほしい」と思うのがプライバシーです
ここには「AIモデルの改善にご協力ください」という、自分の会話をAIの学習（モデル改善）に使うかどうかの切り替えがあります

Free・Pro・Maxのプランでは、このデータ学習のトグルを自分でオフにできます
オフにすると新しい会話は学習に使われず、データの保持も標準の30日になります
逆にオンのまま（学習に協力する）だと、最大5年間保持される設計です

ジャベ雄

仕事の内容を入力する人ほど、まずここのトグルを確認しておくのがおすすめです

プライバシーの「AIモデルの改善にご協力ください」が、会話を学習に使うかのスイッチです

【設定】機能 使える道具のオン・オフ

機能のタブは、Claudeが使える道具（能力）のトグルが並ぶ場所です
実機ではいくつかのグループに分かれていて、代表的なのはこのあたりです

• メモリー … 過去のチャットを検索・参照させるか、履歴からメモリーを作るか
• アーティファクト … コードや文書・図を、チャットの隣のパネルに描き出す
• インライン可視化 … 会話の中に直接グラフや図を出す
• クラウドコード実行とファイル作成 … サーバー上でコードを動かして資料やPDFを作る（スキルの利用に必要）
• ツールアクセスモード … 新しい会話でコネクターの道具をどう読み込むか

ひとつ注意点
ウェブ検索やリサーチ、拡張思考のオン・オフは、この「機能」タブではなくチャット入力欄のスイッチ側で切り替えます
並ぶ項目はプランやバージョンで変わるので、実際は自分の画面で確かめてください

AIで仕事を減らしたい方へPR

AI鬼管理｜Claude Code活用の業務自動化トレーニング

Claude Code を業務の自動化に使うためのトレーニングです
いきなり申し込む形ではなく、まずは無料の業務効率化診断(オンライン面談)から始められます

無料の業務効率化診断を見てみる

Notta｜AI自動文字起こし

会議や動画の音声を自動で文字にするサービスです
議事録や書き起こしの手作業を減らしたいときに

Nottaを見てみる

【設定】Claude Code 権限モードがいちばんの肝

Claude Codeまわりで最初に理解したいのが権限モードです
コーディング作業でClaudeにどこまで自動でやらせるか、を決める仕組みです

ここで大事な注意が1つ
権限モードの切り替えそのものは、設定メニューではなく作業画面（送信ボタンの横のセレクタ）で行います
設定メニューのClaude Code項目でできるのは、主に後述の「許可をバイパス」を使えるようにする開放です

まずは権限モードに何があるのか、表で並べてみます

初心者のうちは、作業画面のセレクタを手動のままにして様子を見るのが安全です
Claudeが何をやろうとしているか、1つずつ確認できるので、動きが読めてきます

混同しやすいのが自動と許可をバイパスの2つ
名前は似ていますが、中身はまったく別物です

自動は、裏で安全チェックを回しながら進める、いわば「安全寄りの自動」です
確認の回数を減らしつつ、危なそうな操作は止めてくれるので、慣れてきた人が作業画面で選ぶ常用モードにしやすいです

権限モードのほかに、使うモデルの選択も作業画面（送信ボタンの横）から切り替えられます
モデルも権限モードも作業の途中で変えられるので、「軽い調べ物は素早いモード、複雑な実装は賢いモード」のように場面で使い分けると効率が上がります

この項目には「許可をバイパス」の開放のほかにも、ブラウザツールのオン・オフ、コーディング画面の見た目（テーマ・フォント）、プルリクエストの自動化、作業用のワークツリーの保存場所など、多くのスイッチがまとまっています
権限まわりの考え方をもっと固めたい人は、Claude Codeのセキュリティ設定や、設定ファイルの早見表の記事も合わせてどうぞ

権限モードの切り替えは作業画面側、設定にあるのは「許可をバイパス」を使えるようにする開放です

【設定】Cowork と Claude in Chrome

比較的新しい2つの機能の設定です
まずCoworkは、タスクを丸ごと渡すと、ファイル・カレンダー・メール・つないだツールを横断して、完了まで進めてくれるおまかせ作業の面です
Claude Codeの一般業務版、と考えると分かりやすいです

Coworkはもともとデスクトップ発の機能ですが、2026年にはWebやスマホにも広がってきました
いまのデスクトップアプリでは、Homeタブの中でチャットと切り替えて使う形になっています（外出先から進捗を見て、続きをあとで受け取る使い方も可能）

もう一つのClaude in Chromeは、Chrome拡張との連携です
設定メニューのこの項目で扱えるのはサイト単位の許可です
すべてのサイトで動かすか（拡張機能を許可）と、使わせたくないブロックサイトの登録ができます

一方で「操作のたびに確認するか」といった操作の強さは、設定メニューではなく拡張機能側で選びます

• 都度確認 … 操作のたびに止まって承認を求める（安全寄り）
• 確認なしで実行 … 自分で進め、危なそうなときだけ確認する

購入やアカウント作成のような操作は、そもそも実行できない安全弁も入っています
この機能は進化が速いので、実際の画面は自分の環境で最新を確かめるのが確実です

【デスクトップアプリ】一般・拡張機能・開発者

2つ目の大区分、デスクトップアプリはアプリ本体の設定です
ここは3項目にまとまっています

一般には、スタートアップ時にClaudeを起動するか、システムトレイに常駐させるか、といったアプリ本体の設定が並びます
目玉はコンピュータ使用のトグルで、許可したアプリ上でClaudeが画面を見て、キーボードやマウスを操作できるようになります（既定はオフ、Macだと画面収録などの許可も追加で必要）
ほかに、拒否するアプリの登録や、作業後にウィンドウを元に戻すかどうかの設定もここです

拡張機能は、MCP拡張をワンクリックで入れられる仕組みです
以前は設定ファイル（JSON）を手で書く必要がありましたが、専用の拡張ファイルを選ぶだけで導入・管理できるようになっています

ジャベ雄

MCPって何？という人は、拡張機構の入門記事から読むとつかみやすいです

最後の開発者は、作業中のローカルMCPサーバーを追加・管理する項目です
設定ファイルを直接編集する導線や、開発者向けドキュメントへのリンクが置かれた、ちょっと踏み込んだメニューになります

拡張機構やMCPの全体像は、Claude Code拡張機構の入門記事でまとめて解説しているので、そちらも参考にしてください

【カスタマイズ】スキル・コネクタ・プラグインの違い

3つ目の大区分、カスタマイズはClaudeを自分好みに拡張するメニューです
スキル・コネクタ・プラグインの3つが並びますが、名前が似ていて混乱しやすいので、違いを表で整理します

ざっくり言うと、スキルが個別の能力・コネクタが外部連携・プラグインがそれらの詰め合わせ、という関係です
どれもカスタマイズメニューの「＋」ボタンから一覧を開いて、インストールや接続を進める流れになっています

スキルは関連する場面で自動で読み込まれるほか、入力欄で「/」を打って手動で呼び出すこともできます
コネクタはつなぎたいサービスで認証すれば、Claudeがそのサービスのデータを読んだり操作したりできるようになります

カスタマイズのスキル一覧。同じ並びにコネクタ・プラグインもあります

よくある質問 設定メニューまわり

まとめ まず触る設定・触らない方がいい設定

Claudeデスクトップアプリの設定メニュー15項目を、区分ごとに一周しました
最後に、初心者がまず触るとよい設定と、当面は触らない方がいい設定をまとめておきます

ジャベ雄

全部を触る必要はないので、まずは名前と外観、プライバシーあたりからで十分です

設定画面は更新が速いので、細かい項目名や並びは、この記事を片手に自分の画面で答え合わせしてもらうのがいちばん確実です
Claude自体の使い方から知りたい人は、Claudeの使い方（初心者向け）や、Claude用語集から入ると、設定の意味もより腑に落ちるはずです

私のおすすめ本PR

VBAPythonAI・ClaudePC仕事術

Excel マクロ&VBA やさしい教科書 Office 2024/2021 Microsoft 365対応

Amazon楽天

てっとり早く確実にマスターできる Excel VBAの教科書 改訂新版

Amazon楽天

Excel マクロ/VBA 今日から使える業務の自動化入門

Amazon楽天

VBAエキスパート公式テキスト Excel VBAベーシック

Amazon楽天

［最速入門］ChatGPTに任せる Excelマクロ&VBA

Amazon楽天

退屈なことはPythonにやらせよう 第3版

Amazon楽天

シゴトがはかどる Python自動処理の教科書

Amazon楽天

もっとシゴトがはかどる Python×Excel×AI 業務自動化の教科書

Amazon楽天

Python2年生 スクレイピングのしくみ 第2版

Amazon楽天

スッキリわかるPython入門 第2版

Amazon楽天

実践Claude Code入門

Amazon楽天

Claude CodeによるAI駆動開発入門

Amazon楽天

開発効率をアップする! Claude Code 実用入門

Amazon楽天

Microsoft 365 Copilot踏み込み活用術

Amazon楽天

できるClaude & Claude Cowork

Amazon楽天

できる人のパソコン仕事術 なんと効率10倍!

Amazon楽天

できるWindows 11パーフェクトブック 困った!&便利ワザ大全 改訂3版

Amazon楽天

できるポケット 時短の王道 ショートカットキー全事典 改訂4版

Amazon楽天

ビジュアル ショートカットキー時短ワザ事典

Amazon楽天

取り急ぎ、パソコン仕事の基本だけ教えてください！

Amazon楽天

ジャンルごとに私のおすすめからランダムで5冊を表示しています

もともと私の手元には、自分のサーバー上のデータベースにPythonで接続するモジュールがありました、ただこれが古いライブラリ前提で作られていて、最新の環境に上げようとすると動かない、という状態でずっと固まっていたんです

どうせ作り直すなら、ただの接続モジュールに戻すのはもったいない、せっかくなら Claudeから直接データベースを覗ける道具にしてしまえば便利なのでは? と思いついたのがきっかけでした

その「道具」がMCPサーバーと呼ばれるものになります、この記事では Claude Codeに伴走してもらいながら、自分専用のMCPサーバーを設計から公開まで作った体験を、コードの深い話は抜きにして広めに書いていきます

先に結論を言うと、プログラムをゴリゴリ書ける人でなくても、自分専用の道具は作れます、Claudeに設計から相談して、実装もレビューも任せて、最後に自分が確認するだけで形になりました

ジャベ雄

「自作」って聞くと身構えちゃうけど、やってることの大半は日本語の相談なんですよね

Claude Codeの拡張機構の全体像はClaude Codeの拡張機構入門の記事、AI周辺の用語はAI用語集でまとめているので、言葉でつまずいたらそちらも合わせてどうぞ

そもそもMCPって何 Claudeに道具を持たせる仕組み

まず言葉の整理から、MCP(エムシーピー)はClaudeに「外部の道具」を持たせるための拡張の仕組みの1つです

Claudeはそのままだと、賢く文章を考えたり相談に乗ったりはできても、「私のサーバーにあるデータベースを読んできて」みたいな手元の操作はできません、本体に手足が付いていないイメージです

そこで 道具(=MCPサーバー)を外付けしてあげると、Claudeが単体ではできない操作を、その道具を介してできるようになります、今回私が作ったのは「自分のサーバーのデータベースを読む道具」です

これをClaudeに登録しておくと、あとは日本語で 「このテーブルから昨日のデータを出して」と頼むだけで、Claudeが裏でデータベースへの問い合わせ(SQLという命令文)を組み立てて、結果を返してくれます

ジャベ雄

SQLを自分で書かなくていいの、ここが地味にうれしいんですよ

なぜ既製品でなく自作だったのか

ここで疑問が出ると思います、データベース用のMCPなんて世の中にすでにあるのに、なぜわざわざ自分で作ったのか? という話です

結論から言うと、既製品が私のサーバー環境にそのままでは繋がらなかったからです、この接続の壁が今回いちばんの分かれ道でした

実は最初、私は「わざわざ作らなくても、既にあるものを入れれば一発でしょ」と軽く考えていました、ところがいざ繋ごうとすると、データベースの接続情報を正しく入れているのに、どうやっても弾かれてしまう、ここで「あれ、これ普通のやり方では届かないやつだ」と気づいたわけです

Xserverは「二段構え」でつなぐ必要がある

私が使っているレンタルサーバー(Xserver)は、データベースに直接つなぐのではなく、いったん別のサーバーに安全な経路でログインしてから、その先のデータベースへ繋ぐという二段構えが前提になっています

この「安全な経路を一本通してから、その中を通ってつなぐ」やり方を SSHトンネルと呼びます、外から直接データベースを叩けないようにする、セキュリティ上ありがたい仕組みなんですが、繋ぐ側からするとひと手間多いわけです

一般的なデータベース用のMCPは、この SSHトンネルの機能を持っていません、だからXserverのような二段構えのサーバーには、既製品をそのまま当ててもつながらないんです

既製品は「参考にはするけど、そのままでは私の用途を満たさない」、これが自作に踏み切った理由になります、自分の環境にぴったり合う道具がないなら、作ってしまえばいいという発想です

Claude Codeに全工程を伴走させた流れ

ここからが記事の本題です、私は今回 「バイブコーディング」的に、ほぼ全工程をClaude Codeに伴走させて作りました、ノリと相談で進めていく感じの作り方ですね

AIでアプリを作る体験そのものについてはAIでアプリ開発に挑戦した体験記でも書いているので、雰囲気が気になる方はそちらも、ここでは「道具(MCP)を作るときの流れ」に絞ります

大きく分けると、壁打ち → 設計 → タスクごとに実装 → 最終レビュー → 公開という5ステップで進みました

「先にテストを書く」ってどういうこと

STEP3で「先にテストを書いてから本体を作る」と書きました、これは TDD(テスト駆動開発)という作り方で、ざっくり言うと「合格ラインを先に決めてから中身を作る」やり方です

料理で言えば、完成形の味見の基準を先に決めておいて、その基準を満たすように作る感じですね、こうすると 作ったものが意図どおり動いているかを毎回その場で確認できるので、後からのやり直しが減ります

大事なのは、この段取り自体もClaudeが提案して進めてくれた点です、私が「TDDでやって」と細かく仕切ったわけではなく、相談する中で自然とこの形に落ち着きました

ジャベ雄

「実装する人」と「チェックする人」を分ける、これ人間のチーム開発と同じ発想なんですよね

AIで仕事を減らしたい方へPR

AI鬼管理｜Claude Code活用の業務自動化トレーニング

Claude Code を業務の自動化に使うためのトレーニングです
いきなり申し込む形ではなく、まずは無料の業務効率化診断(オンライン面談)から始められます

無料の業務効率化診断を見てみる

Notta｜AI自動文字起こし

会議や動画の音声を自動で文字にするサービスです
議事録や書き起こしの手作業を減らしたいときに

Nottaを見てみる

最終レビューで「自分のバグ」が見つかった話

この章の話が今回いちばん学びになりました、各タスクのレビューはちゃんと通していたのに、最後の全体レビューで実際のバグが1つ見つかりました

中身を平たく言うと、読み取り専用のはずなのに、ある特殊な書き方をすると書き込み命令が通ってしまう抜け穴でした、「読むだけ」を守らせていたつもりが、すり抜ける経路が残っていたんです

怖いのは、これが 各機能ごとの個別レビューを全部すり抜けていた点です、1つひとつの機能を見ているときには気づけず、全体を改めて厳しい目で見直したときに初めて浮かび上がってきました

見つかったあとの流れはシンプルで、指摘 → 修正 → 再レビューでその抜け穴を塞ぎました、ここでもやっているのは「Claudeに直してもらって、もう一度別の目で確認する」という同じ進め方です

AIは賢いんですが、万能で無謬というわけではありません、だからこそ 作る工程とチェックする工程を分けて、最後に全体を見直す、この一手間が安心につながると実感しました

AIにデータベースを触らせるときの安全設計

今のバグの話とつながりますが、AIにデータベースを触らせるなら、安全側に倒した設計が要ります、ここは自作する人だけでなく、既製のMCPを使う人にも役立つ考え方なので少し丁寧に書きます

基本は「読み取り専用」にしておく

私が決めたのは 既定で「読むだけ」にするという方針でした、AIにデータベースを任せるとき、いちばん怖いのはうっかりデータを書き換えられたり消されたりすることです

だから道具の側で「ふだんは読むだけ、書き込みは明示的にスイッチを入れたときだけ許可する」という作りにしました、自分でも「今は書き込みOKにしているぞ」と意識しないと書けない、という ブレーキです

本当の安全弁はデータベース側にある

ただ、ここで大事な考え方があります、道具(アプリ)側のチェックは第一の防御線にすぎません

さっきのバグのように、アプリ側の「読むだけ」設定はすり抜ける経路が残っていることがあります、だから 本当の安全弁は、データベース側に「読み取りしかできない利用者」を用意することです

つまり、そもそも書き込み権限を持たないアカウントで繋いでおけば、仮にアプリ側のチェックを抜けても、データベースが「あなたには書き込み権限がありません」と弾いてくれます、二重のブレーキです

考え方としてはこうです、データベースには、つなぐための利用者(アカウント)を何種類か作れます、ふだんアプリやサーバーの管理に使うのは強い権限を持った利用者ですが、AIに渡すのは「読むことしかできない利用者」を別に1つ用意して、そちらだけを使わせるのが安心です

こうしておくと、構造はとてもシンプルになります、アプリ側の「読むだけ」設定が 第一の防御線、その奥でデータベース側の読み取り専用の利用者が 最後の安全弁として控える、という形です、手前のチェックがうっかり抜けても、いちばん奥で物理的に書き込めない、この奥行きが効いてきます

手順の細かい話は環境ごとに変わるので踏み込みませんが、方針として覚えておきたいのは 「アプリで頑張る」より「権限を持たせない」ほうが強いという一点です、できないように作ってあれば、そもそも事故が起きようがありません、ここは私自身が今回のバグで痛感したところでもあります

使った道具は「最新の保守されたもの」だけ

技術の中身には深入りしませんが、1点だけ、今回 古い(メンテが止まった)接続方式をやめて、今も保守されている方式に乗り換えられたのは大きな前進でした

使ったのは3つで、安全な経路(SSH)を扱う asyncssh、データベースとやり取りする aiomysql、Claudeと話す土台になる FastMCP、それぞれ「SSHを扱う道具」「データベースを扱う道具」「MCPを作る土台」くらいの理解で十分です

名前を覚える必要はありません、ポイントは 今も更新が続いているライブラリだけで動くようにできたこと、古いものに縛られて身動きが取れなかった状態から解放されたのが、地味にいちばん嬉しかったところです

実際に使ってみたらこうなった

道具が完成して、Claudeに登録したあと、さっそく試してみました、頼み方はいたってシンプルで、日本語で「このテーブルから昨日ぶんのデータを抽出して」とお願いするだけです

するとClaudeが裏で問い合わせ(SQL)を自分で組み立てて、結果を返してくれました、私はSQLを1行も書いていません、それでも自分がためているデータがちゃんと取れて、試したときは千件を超える実データが返ってきました

ジャベ雄

自分のデータに話しかけて答えが返ってくる感じ、ちょっと未来っぽくて楽しいんですよ

これで 自分専用の「自分のサーバーのデータベースをClaudeから覗く道具」が手に入りました、欲しかったのはまさにこれです、既製品では届かなかった一歩を、自作で埋められたという達成感もありました

使ってみて地味に効いたのが、データの中身を確認するためにいちいち管理画面を開かなくてよくなったことです、これまでだと「あのデータどうなってたっけ」と思うたびにブラウザでログインして画面をたどっていました、それが今は、Claudeに一言聞けば返ってくる、この距離の近さが思った以上に快適でした

しかも返ってきた結果について「この中で件数が多い順に並べて」とか「先週ぶんと比べてどう?」みたいに、そのまま会話で深掘りできます、データを取り出す道具と、それを読み解く相手が同じ場所にいる、この一体感がふつうのデータベース管理ツールとはひと味違う使い心地でした

もう少し具体の流れを書いておくと、たとえば あるテーブルに対して「ここから昨日ぶんを出して」と日本語で頼むと、Claudeがその指示を読み取って、裏で問い合わせ(SQL)を自分で組み立てます、私が見ているのは「昨日ぶんを出して」という自分の文と、しばらくして返ってくる結果だけです、途中の命令文を意識しなくていいのが、思った以上に身軽でした

ひとつ注意があって、取り出す件数が多いと、既定の上限で途中まで返って打ち切られることがあります、千件を超える量を一気に頼むと、最初のいくらかが返ってきて「ここまでで止めています」という挙動になる感じですね、全部ほしいときは「もっと多く返して」と上限を上げてもらうか、条件を絞って小さく取り直します、いきなり全件をどっと返さない作りは、安全側に倒すうえでもむしろ都合がよかったです

登録自体は数行で済む

「道具を登録」と書くと身構えるかもしれませんが、Claude Codeに道具(MCPサーバー)を教えるのは設定ファイルへの数行の追記です、ファイル名は .mcp.json で、ここに「どの道具を、どう起動するか」を書きます

イメージとしてはこんな形で、サーバーの名前と起動コマンドを書くだけです(中身は環境ごとに変わります)

{
  "mcpServers": {
    "my-db-tool": {
      "command": "（自作した道具を起動するコマンド）"
    }
  }
}

この設定ファイルが何者なのか、ほかにどんな設定ファイルがあるのかはClaude Codeの設定ファイル早見表にまとめています、.mcp.json の置き場所や役割が気になったらそちらをどうぞ

そして設定ファイルを触るのが怖い人へ、ここも Claude自身に「.mcp.jsonにこの道具を登録して」と頼んで書かせるのが楽です、書いてもらった内容を自分で確認してから反映すれば、手で打ち間違える心配も減ります

コードを書けなくても自分専用の道具は作れる

最後にまとめます、今回いちばん伝えたいのは Claude Codeを使えば、設計から実装、レビュー、公開まで伴走してもらいながら、自分専用の道具(MCP)を作れるということです

振り返ると、私が手を動かしたのは「何を作るか相談する」「設計書を読んでOKを出す」「最後の確認をする」あたりで、実装そのものはほとんどClaudeに任せていました、それでもちゃんと動くものが手に入ります

• いきなり書かせず、まず壁打ちで「何を作るか」を言葉にする
• 設計と実装はClaudeに任せ、人間は読んで判断する側に回る
• 「作る役」と「チェックする役」を分け、最後に全体を見直す
• AIにデータを触らせるなら「読み取り専用」を基本に、権限は大本で絞る
• 設定ファイルが怖ければ、Claudeに書かせて内容を確認してから反映する

そして今回の出発点を思い出してほしいんですが、私が作ったのは「既製品が自分の環境に合わなかった」からでした、世の中にある道具が自分の環境にハマらないときこそ、自作の出番です

プログラムをゼロから書ける必要はありません、やりたいことを言葉にして、相談しながら一緒に作っていく、その伴走役としてClaude Codeは頼りになります、興味が出たら、まずは小さな「自分専用の道具」から試してみてはどうでしょうか?

ジャベ雄

「これ既製品じゃ届かないな」って思った瞬間が、自作のスタートラインなんですよね

私のおすすめ本PR

VBAPythonAI・ClaudePC仕事術

Excel マクロ&VBA やさしい教科書 Office 2024/2021 Microsoft 365対応

Amazon楽天

てっとり早く確実にマスターできる Excel VBAの教科書 改訂新版

Amazon楽天

Excel マクロ/VBA 今日から使える業務の自動化入門

Amazon楽天

VBAエキスパート公式テキスト Excel VBAベーシック

Amazon楽天

［最速入門］ChatGPTに任せる Excelマクロ&VBA

Amazon楽天

退屈なことはPythonにやらせよう 第3版

Amazon楽天

シゴトがはかどる Python自動処理の教科書

Amazon楽天

もっとシゴトがはかどる Python×Excel×AI 業務自動化の教科書

Amazon楽天

Python2年生 スクレイピングのしくみ 第2版

Amazon楽天

スッキリわかるPython入門 第2版

Amazon楽天

実践Claude Code入門

Amazon楽天

Claude CodeによるAI駆動開発入門

Amazon楽天

開発効率をアップする! Claude Code 実用入門

Amazon楽天

Microsoft 365 Copilot踏み込み活用術

Amazon楽天

できるClaude & Claude Cowork

Amazon楽天

できる人のパソコン仕事術 なんと効率10倍!

Amazon楽天

できるWindows 11パーフェクトブック 困った!&便利ワザ大全 改訂3版

Amazon楽天

できるポケット 時短の王道 ショートカットキー全事典 改訂4版

Amazon楽天

ビジュアル ショートカットキー時短ワザ事典

Amazon楽天

取り急ぎ、パソコン仕事の基本だけ教えてください！

Amazon楽天

ジャンルごとに私のおすすめからランダムで5冊を表示しています

「AIに記事を書かせて、そのままWordPressに下書き保存できたら楽なのに」と思ったことはないですか？

今回は Claude Code で WordPress に自動投稿する仕組みを MCP（AIに外部サービスを操作させる仕組み）で作りました
投稿先はXserverで動かしている自分のブログで、届くのは下書きの状態
そのMCPサーバー自体、私がPythonを一行ずつ書いたというよりClaude Code本人に「こういうサーバーを作って」と頼んで作ってもらったんです

なので中心になるのは、Claudeにどう頼めばMCPサーバーができあがるのか、どうテストすれば任せられる状態になるのか、のあたり
すぐ動かしたい人向けに、いま動かしている全文も記事の末尾に折りたたんであります

Claude CodeでWordPress自動投稿｜何ができるようになるか

セットアップが終わると、「VLOOKUPの解説記事を書いて、下書きで保存して」の一言でWordPress管理画面の「投稿一覧」に下書きができあがります

「VLOOKUP関数について、初心者向けに1000字くらいで解説記事を書いて、下書きで保存しておいて」

下書きを作るだけでなく、装飾やメタの設定まで会話で済みます

• テーマを伝えるだけで記事の下書きをWordPressに自動投稿
• アイキャッチ画像のアップロードと設定
• カテゴリ・タグの設定（既存から選ぶ・足りなければ新規作成）
• メタディスクリプション（SEO用の説明文）の登録
• テーマ独自のブロック（SWELLのステップ・FAQ・注意ボックスなど）での装飾
• 記事ごとのカスタムCSS（SWELLの投稿別CSS欄）の設定
• 既存記事の取得・編集も会話で完結（タイトル変更・本文追記など）
• 下書き一覧を出してもらって、書きかけ記事の整理も簡単

もちろん公開前のプレビュー確認は管理画面で行いますが、それ以外の編集作業をブラウザでぽちぽち進めなくて済むのは思ったより楽なんです

ジャベ雄

私は下書き作成を、ぜんぶこれに寄せました

テーマ独自のブロックは「見本ページ」を読ませて覚えさせる

1つだけコツがあって、「SWELLのステップブロックで書いて」と頼むだけではClaudeはあなたのテーマの正確なブロックの形までは分かりません
理由は単純で、ブロックの中身（HTML）がテーマごとに違うから

そこで有効なのが、使いたいブロックを並べた見本用の固定ページを1枚だけ作っておく方法です

その見本ページをClaudeに読み取らせると、実際のブロックのHTMLを覚えて、同じ形を記事の中で再現できるようになります

私の場合は、ステップ・FAQ・吹き出し・各種ボックスなどを1ページにまとめた見本を作って、それをClaudeに読ませてから装飾してもらう、という流れにしています

逆に苦手なこと｜任せきれない部分は人がやる

いちばんはっきりしているのが画像で、AIは記事の見た目を見ているわけではないし、必要なスクショを自分で撮ることもできません
「この記事に合うスクショを貼って」と頼んでも、返ってくるのは場所の提案まで

ローカルの画像をアップロードするにしても、メディアライブラリから選ぶにしても、「どれが適切か」の判断はAIには難しいと思います
ここは人の出番

代わりに「キャプチャのメモ」を入れてもらう

まるごと任せられないだけで、下ごしらえは頼めます

「ここにスクショを入れる」という場所と、「何を写したスクショにするか」のメモを、該当箇所に書いておいてもらう使い方です
そうすれば人は、メモ通りにスクショを撮って貼るだけ

実際この記事の画像も、先にAIが「ここにアプリケーションパスワード発行画面のスクショ」とメモを置いておいて、その場所に私が撮ったものを入れています

WordPress REST APIにないことはできない

このMCPはWordPressのREST API（記事・固定ページ・メディア・カテゴリなどを操作する窓口）を通して動いているので、そこに用意されていないこと——サイト全体に適用されるCSSやJavaScript、プラグインの設定、メニューやサイト構成の変更などは反映できません
記事1本ごとのCSSのほうは、後で触れる補助プラグインを入れれば設定できる範囲
JSも同じように開放はできますが、安全を考えるとおすすめしません

「こう変えたい」と相談すれば書き方や手順の提案はしてくれますが、実際に反映するのはテーマ・カスタマイザー・プラグイン側の作業で、MCPの守備範囲の外になります

あえて「触れる範囲」は絞っている

逆に、REST API経由で触れるメタ情報（SEOのディスクリプションなど）は、できる中でもあえて最小限に絞っています
SEOのタイトルやog:imageなども、開放すればMCPから設定できる項目
ただ自動で書き換えられる範囲が広いほど、うっかり上書きや、認証情報が漏れたときの被害も大きくなります
なので「実際に自動化したいものだけ開けておく」のが安全だと思います

具体的には、SEOプラグインのメタディスクリプションやSWELLの投稿別CSSは、標準のWordPressでは外部から書き込めません
そこを開けるための補助プラグインをClaudeに作ってもらって、mu-pluginsという特別なフォルダに置いています（置き場所と中身は記事の末尾に）

この「Claudeに作ってもらって自分で置く」流れは、MCPサーバー本体を作るときと同じ
補助プラグインは1ファイルの短いPHPなので、依頼すればすぐ作ってもらえます

それから、これは「できない」というより最後は人が見ておきたいところですが、仕上がりの見た目
AIはブロックのHTMLを組むところまでで、テーブルの幅やモバイルでの崩れといった実際の表示までは見えていません
ファクトの裏取りと同じ感覚で、公開前にプレビューでさっと目を通しておくと取りこぼしが減ると思います

もう1つ、これはMCPというよりAIに記事を書かせるとき全般のコツですが、「リストには下線を付ける」「画像は影付きスタイルにする」のような自分ルールを決めておくと、AIはそれに合わせて作ってくれます

そもそもMCPって何｜AIと外部サービスを繋ぐ共通規格

「MCP」はModel Context Protocolの略で、Anthropic（Claudeを作っている会社）が提唱しているAIアシスタント業界の新しい標準仕様です

ざっくり言うと、AIに外部のサービスを操作させるための共通言語のようなものになります

MCPで何が変わるのか

これまでもAIに「○○をやって」と頼むことはできましたが、AI自身は実際にWordPressを操作したりファイルを読み書きしたりはできませんでした

MCPサーバーを間に挟むことで、AIから外部システムを「ツール」として呼び出せるようになり、AIが実作業まで進められるようになります

今回作る仕組みの全体像

図にするとこんな流れになります

[あなた] ⇄ [Claude Code] ⇄ [MCPサーバー] ⇄ [WordPress REST API] ⇄ [WordPress]

• Claude Code が「下書きを保存して」というあなたの指示を理解する
• MCPサーバー（自分のPCで動く小さなプログラム）がそれをWordPressが分かる形に翻訳する
• WordPress REST API が実際に記事を作成する

2026年9月に確認した時点では、WordPress公式のMCP Adapterはあるものの、投稿を作る・直す能力までは入っていません（くわしくは後ろの節で）
なので今回はPythonで自作しました
といっても最初はだいたい200行の小さなものをClaudeに作ってもらって、そこから少しずつツールを足していった形です

Claude Code自体の基本的な使い方はまた別記事で書こうと思いますが、その前段としてClaudeの使い方を初心者向けに解説した記事もあるので、Claudeに触ったことがない人はそちらから読んでもらえると入りやすいです

Claudeに「WordPress操作のMCPサーバーを作って」と頼む

MCPサーバーは自分でゼロからコードを書かなくても、Claude Code本人に作ってもらえます

コツは一度に全部を作らせないことで、1つのツールを作る → 動かしてテスト → 次のツールを足すという小さいサイクルで育てていくと失敗しにくいです

ジャベ雄

最初に全部まとめて作らせて、見事にやらかしたんです

最初の依頼：土台と接続確認だけ

まずはこんなふうに、使う技術と認証の方針を伝えて土台を作ってもらいます

PythonでWordPressを操作するMCPサーバーを作りたいです
・FastMCP（mcp.server.fastmcp の FastMCP）を使う
・WordPress REST API（/wp-json/wp/v2/）を叩く
・認証はアプリケーションパスワードで、認証情報は .env から読む（python-dotenv）
・まずは接続確認のツール（サイト名とログインユーザーを返す）だけ作って

ここで認証情報は .env から読むと最初に指定しておくと、あとの作業が楽になります
コードの中にパスワードが残らないので、そのまま公開しても問題ない形

ツールを1つずつ足していく

接続確認が通ったら、記事を作るツールから順番に足していきます

接続確認が通ったので、記事を下書き保存するツール create_post を追加して
デフォルトのstatusはdraft、publishは明示したときだけにして

同じ調子でlist_posts（一覧取得）、update_post（更新）、get_post（取得）と1つずつ頼んでいきます
カテゴリやタグの一覧取得・新規作成も、同じやり方

うまく作ってもらうための小さなコツ

• 一度に全機能を作らせない、1ツールずつ作ってテストしてから次を足す
• 認証情報は最初に「.envから読む」と指定する（コードに直書きさせない）
• 接続確認のツールから作ると、最初の動作確認がすぐできる
• エラーが出たらエラーメッセージをそのまま貼ると、原因を見つけて直してくれる
• 「デフォルトはdraft」のような安全側の仕様も、最初の依頼文に入れておく

Claude Code×WordPress自動投稿のセットアップ手順

Python・Claude Code（Pro以上）・アプリケーションパスワードの3つが揃えば、6ステップで接続確認まで終わります

用意するもの

Claude Codeは有料プラン専用なので、無料で試したい場合はClaudeのコネクタ機能を使う代替手段もあります

Step1：プロジェクトフォルダを作る

任意の場所にフォルダを作ります
私の場合はデスクトップ

C:\Users\ユーザー名\Desktop\blog\

Step2：必要なファイルをClaudeに作ってもらう

前の章で作ってもらったwp_mcp_server.pyに加えて、動かすために次の3ファイルが必要です
いずれもClaudeに頼めば、そのまま作って配置までやってくれます

• requirements.txt（必要なライブラリ一覧）
• .mcp.json（Claude CodeにMCPサーバーの場所を教える設定）
• .env（WordPressの認証情報を書く、中身は次のステップで自分で書く）

こんな感じで頼めばまとめて作ってくれます

このサーバーを動かすのに必要な requirements.txt と .mcp.json も作って、同じフォルダに置いて
.env は中身が認証情報なので、空のテンプレート（WP_BLOG_BASE_URL / WP_BLOG_USERNAME / WP_BLOG_APP_PASSWORD の3つを書く枠）だけ作っておいて

.mcp.json や CLAUDE.md のような設定ファイルがどこに置かれて何をするのかは、最初はちょっと分かりにくいので、別記事で一覧にしてあります

あわせて読みたい

Claude Code 設定ファイル早見表 役割と場所 Claude Codeを触っていると次々に登場する設定ファイル(CLAUDE.md・settings.json・AGENT.md・SKILL.mdなど)を、保存場所と役割で一覧化した早見表記事です、微調整目線で抑えたい初心者〜中級者向けにまとめました

.envの中身（=認証情報）だけは人が書きます
ここはClaudeに渡さない情報なので、空のテンプレートだけ作ってもらって、値は次のステップで自分で埋めるのが安全です

Step3：Pythonライブラリのインストールも頼める

requirements.txtができたら、ライブラリのインストールもClaudeに頼めます

requirements.txt のライブラリをインストールして

これで mcp・requests・markdown などのパッケージが入ります
自分で実行したい場合は、PowerShellで次のコマンドでもOK

cd C:\Users\ユーザー名\Desktop\blog\
python -m pip install -r requirements.txt

Step4：WordPressでアプリケーションパスワードを発行

ここが今回の肝
普段のログインパスワードではなく API専用の使い捨てパスワードを発行します

1. WordPress管理画面にログインして「ユーザー → プロフィール」を開く
2. ページ最下部にある「アプリケーションパスワード」欄まで移動
3. 名前を入力（例：Claude MCP）して「新しいアプリケーションパスワードを追加」をクリック
4. xxxx xxxx xxxx xxxx xxxx xxxx 形式の文字列が表示されるのでコピー

Step5：.envファイルに認証情報を書く

Step2でClaudeに枠だけ作ってもらった .env ファイルを開いて、次の3つの値を自分で埋めます

WP_BLOG_BASE_URL=https://あなたのドメイン
WP_BLOG_USERNAME=WordPressのログインユーザー名
WP_BLOG_APP_PASSWORD=xxxx xxxx xxxx xxxx xxxx xxxx

アプリケーションパスワードはスペース込みのままで大丈夫なので、わざわざ削る必要はありません

末尾に載せた完全版は、旧い名前の WP_BASE_URL / WP_USERNAME / WP_APP_PASSWORD も同じ意味で読みます

Step6：Claude Codeで動作確認

このフォルダでClaude Codeを起動すると、.mcp.json が自動で検出されてMCPサーバーの起動許可を求められます
「Allow」を押してください

その後Claude Codeに次のように頼みます

「WordPressの接続確認をして」

サイト名とログインユーザー名が返ってくれば接続成功
ここでやっとひと息つけます

AIで仕事を減らしたい方へPR

AI鬼管理｜Claude Code活用の業務自動化トレーニング

Claude Code を業務の自動化に使うためのトレーニングです
いきなり申し込む形ではなく、まずは無料の業務効率化診断(オンライン面談)から始められます

無料の業務効率化診断を見てみる

Notta｜AI自動文字起こし

会議や動画の音声を自動で文字にするサービスです
議事録や書き起こしの手作業を減らしたいときに

Nottaを見てみる

作ってもらったサーバーの動作テスト手順

MCPサーバーのテストはClaudeに実際に実行させて、会話で結果を確認するのが一番早いです

ツールを1つ足すたびに次の流れを回しておくと、どこかが壊れた瞬間に気づけます
本格的なテストコード（pytestなど）を書くのは、仕様が固まってからで十分だと思います

この「会話で1ツールずつ叩く」テストの積み重ねが、結局いちばん速くて確実でした

Claude Codeで実際に記事を投稿する流れ

セットアップが終わったら、基本はチャットで会話しながら書いてもらうだけです

「ExcelのVLOOKUPについて、初心者向けに1000字程度で解説記事を書いて、下書きで保存しておいて」

これだけで、Claudeが記事本文を生成してcreate_postツール経由でWordPressに下書きとして投稿してくれます

あとは管理画面でプレビューして、必要なら手直しして「公開」を押すだけです

運用上の3つの注意点

便利な仕組みですが、AIに丸投げで運用する前にいくつか注意点があります

特にハルシネーション対策は、生成AIの裏取りのやり方のところでも書いた通り、AI全般で気をつけたいポイントです

自作しない選択肢｜公式のMCP Adapterと橋渡しプラグイン

2026年9月に確認した限りでは、プラグインを2つ入れるだけでも記事の下書き投稿までは届きます
ただし私の環境で公式ルートを丸ごと動かしてみたわけではないので、ここからは公開されている説明を読んだ範囲での整理

土台になるのがWordPress公式のMCP Adapterで、WordPress側にAIからの窓口を1つ開けるだけの部品みたいな感じです
でも、入れただけで見えるようになるのは discover / get-ability-info / execute の3つで、肝心の能力は既定で非公開のまま

WordPress 6.9本体が持っている能力も、サイト情報・ユーザー情報・環境情報の3つだけ
投稿を作る・直す能力は7.2以降に先送りと公式の提案に書かれていて、読み取り専用のものすら7.1では見送られました

だから、足りないところを外から足す橋渡しプラグインが出てきています（2つとも動かすには WordPress 6.9以上が前提）
Enable Abilities for MCPは投稿の作成・更新・削除を含む112個の能力を足してくれて、Claude.aiから繋ぐためのOAuthコネクタまで入っているとのことでした

MCPやコネクタといった言葉の意味は、Claude用語集のほうにまとめてあります

• SEOのメタは Yoast / Rank Math / SEOPress に対応、SEO SIMPLE PACK は書かれていない
• MCP Adapterの既定の権限チェックはログイン済みなら通る形なので、使うなら権限の設定をちゃんと足すことになる
• MCP Adapterはまだ1.0より前なので、バージョンが上がると書き方が変わることがある
• 旧 Automattic/wordpress-mcp は2026年1月にアーカイブ済み、READMEにも新規で使わないよう書かれている

私は公式ルートに寄せるかでちょっと迷いましたが、結局この記事の自作方式のままです
SEO SIMPLE PACK のメタだったり、3サイトの切り替えだったりが要るので、いまの公式ルートだと足りないままなんです

逆にWordPressは1サイトだけ・SEOはYoastかRank Math・自作は避けたいという条件なら、やっぱり公式ルートのほうが近道だと思います

ジャベ雄

公式が育ったら、自作のほうは引退させる予定です

まとめ｜AIに任せる作業と人間がやるべき作業

AIに渡せたのは、下書き作成・装飾・メタ設定の3つでした

最初の接続確認さえ通れば「テーマを伝える → 下書きが管理画面にできてる」という流れがとても快適です

個人的に思うのは、「AIに全部任せる」じゃなくて、手間のかかる部分をAIに渡して、最後の判断は人間がする、この役割分担がちょうど良い距離感でした

ここまで読むと細かい手順や注意点が多く見えるかもしれませんが、実際にはこの記事で書いたほど細かく指示しなくても、Claudeが自分で判断してよしなに進めてくれる場面が多いです
必要なら途中で「ここはこうして」と相談すれば直してくれるので、まずは小さく頼んで動かしてみるところから始めてみてください

同じくWordPress×AIの自動投稿を試したい方の参考になれば嬉しいです

ジャベ雄

私も最初の1個は、接続確認だけでした

コード全文と設定ファイル｜コピペで使う場合

完全版は18個のツールで、だいたい900行
複数サイトの切り替え・Markdownファイルからの一発入稿・アイキャッチの設定・メディアのアップロードまで入っている形

requirements.txt

mcp>=1.2.0
requests>=2.32.0
python-dotenv>=1.0.0
markdown>=3.6
python-frontmatter>=1.1.0

.mcp.json

{
  "mcpServers": {
    "wordpress": {
      "command": "python",
      "args": ["C:\\path\\to\\wp_mcp_server.py"],
      "env": {}
    }
  }
}

wp_mcp_server.py（最小形の抜粋）

from mcp.server.fastmcp import FastMCP
import os, requests
from dotenv import load_dotenv

load_dotenv()
WP_BASE_URL = os.getenv("WP_BASE_URL", "").rstrip("/")
WP_USERNAME = os.getenv("WP_USERNAME", "")
WP_APP_PASSWORD = os.getenv("WP_APP_PASSWORD", "")
API_BASE = f"{WP_BASE_URL}/wp-json/wp/v2"

mcp = FastMCP("wordpress")

@mcp.tool()
def create_post(title: str, content: str, status: str = "draft") -> dict:
    """新しい記事をWordPressに作成する（デフォルトは下書き）"""
    resp = requests.post(
        f"{API_BASE}/posts",
        auth=(WP_USERNAME, WP_APP_PASSWORD),
        json={"title": title, "content": content, "status": status},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()

if __name__ == "__main__":
    mcp.run()

この抜粋は旧い名前の WP_BASE_URL のほうを読む形なので、WP_BLOG_* で揃えるなら下のコード全文を使ってください

短いコードですが、仕組みのポイントはこのあたりです

• FastMCP(“wordpress”) でサーバーを1つ定義する
• @mcp.tool() を付けた関数が、そのままClaudeから呼べるツールになる
• 関数の説明文（docstring）が「このツールは何をするか」のClaude向けの説明になるので、日本語で丁寧に書いておく
• 認証・タイムアウト・エラー処理は共通の関数にまとめて、各ツールはそれを呼ぶだけにすると見通しが良い
• 接続先のサイトを引数で切り替えられるようにすると、複数サイトの運用にも対応できる

完成版もこの形で、create_post・update_post・upload_media などのツールを登録しています

このサーバーをそっくり真似しなくても、「こういうツールが欲しい」とClaudeに伝えて1つずつ足していくやり方なら、自分の運用に合った形が作れます

wp_mcp_server.py（コード全文）

.env に書くキーは WP_BLOG_BASE_URL / WP_BLOG_USERNAME / WP_BLOG_APP_PASSWORD の3つ
メタディスクリプションまで書き込みたいときは、次の補助プラグインもセットで要ります

"""WordPress MCP Server (multi-site).

WordPress REST API(`/wp-json/wp/v2/`)とアプリケーションパスワード認証を使い、
Claude Code などの MCP クライアントから 投稿(posts)・固定ページ(pages)・メディア・
カテゴリ / タグ を操作するための MCP サーバー。

複数サイト対応:
  .env に `WP_<NAME>_BASE_URL` / `WP_<NAME>_USERNAME` / `WP_<NAME>_APP_PASSWORD` を置くと、
  `<NAME>` を小文字にしたものがサイト名になる(例: WP_BLOG_* → site="blog")。
  サイトはいくつでも登録でき、各ツールの `site` 引数で切り替える。

任意の環境変数:
  WP_DEFAULT_SITE                : site 省略時に使うサイト名(未設定なら "blog" があれば blog、無ければ最初に見つかったサイト)
  WP_<NAME>_AUTHOR_ID            : 新規作成する投稿・固定ページの著者 user_id(更新には影響しない)
  WP_META_DESCRIPTION_KEY        : frontmatter の meta_description を書き込む post meta キー
                                   (既定 "ssp_meta_description" = SEO SIMPLE PACK。空文字にすると書き込まない)
  WP_<NAME>_META_DESCRIPTION_KEY : 上をサイト別に上書きしたい場合
  ※ 書き込み先の meta キーは REST 公開(register_post_meta の show_in_rest)されている必要がある。
    SEO SIMPLE PACK 用の補助プラグインは mu-plugins/ssp-meta-rest.php を参照。

後方互換: 旧キー WP_BASE_URL / WP_USERNAME / WP_APP_PASSWORD は site="blog" の別名として認識する。
"""

from __future__ import annotations

import os
import re
import sys
from pathlib import Path
from typing import Any

import frontmatter
import markdown as md
import requests
from dotenv import load_dotenv
from mcp.server.fastmcp import FastMCP

ROOT = Path(__file__).resolve().parent
load_dotenv(ROOT / ".env")

TIMEOUT = 30

mcp = FastMCP("wordpress")


# =========================================================================
# サイト別認証情報の解決
# =========================================================================

# サイトは環境変数から自動発見する: WP_<NAME>_BASE_URL の <NAME> を小文字化したものがサイト名
_SITE_KEY_RE = re.compile(r"^WP_([A-Z0-9]+)_BASE_URL$")
_LEGACY_BLOG_KEYS = {"BASE_URL": "WP_BASE_URL", "USERNAME": "WP_USERNAME", "APP_PASSWORD": "WP_APP_PASSWORD"}


def _discover_sites() -> list[str]:
    """登録済みサイト名を列挙する(blog を先頭に、あとは名前順)。"""
    names: set[str] = set()
    for key, val in os.environ.items():
        m = _SITE_KEY_RE.match(key)
        if m and val.strip():
            names.add(m.group(1).lower())
    if os.getenv("WP_BASE_URL", "").strip():
        names.add("blog")  # 旧キー(WP_BASE_URL / WP_USERNAME / WP_APP_PASSWORD)は blog の別名
    return sorted(names, key=lambda n: (n != "blog", n))


def _env_for(site: str, suffix: str) -> str:
    """site 用の環境変数 WP_<SITE>_<suffix> を返す。site="blog" は旧キーにもフォールバックする。"""
    val = os.getenv(f"WP_{site.upper()}_{suffix}", "").strip()
    if not val and site == "blog" and suffix in _LEGACY_BLOG_KEYS:
        val = os.getenv(_LEGACY_BLOG_KEYS[suffix], "").strip()
    return val


def _default_site() -> str:
    env = os.getenv("WP_DEFAULT_SITE", "").strip().lower()
    if env:
        return env
    sites = _discover_sites()
    if not sites or "blog" in sites:
        return "blog"
    return sites[0]


DEFAULT_SITE = _default_site()


def _default_author(site: str) -> int:
    """新規作成時に立てる著者(user_id)。WP_<SITE>_AUTHOR_ID が数値なら送る。
    未設定なら author を送らない(= 認証ユーザーが著者)。更新系は author を送らないので影響しない。"""
    raw = _env_for((site or DEFAULT_SITE).strip().lower(), "AUTHOR_ID")
    return int(raw) if raw.isdigit() else 0


def _meta_description_key(site: str) -> str:
    """frontmatter の meta_description を書き込む post meta キー。空文字なら書き込まない。
    優先順: WP_<SITE>_META_DESCRIPTION_KEY > WP_META_DESCRIPTION_KEY > "ssp_meta_description"(SEO SIMPLE PACK)。"""
    site = (site or DEFAULT_SITE).strip().lower()
    for key in (f"WP_{site.upper()}_META_DESCRIPTION_KEY", "WP_META_DESCRIPTION_KEY"):
        if key in os.environ:
            return os.environ[key].strip()
    return "ssp_meta_description"


def _site_config(site: str) -> dict[str, str]:
    site = (site or DEFAULT_SITE).strip().lower()
    known = _discover_sites()
    if site not in known:
        raise ValueError(
            f"未知の site 名: {site!r}。.env に登録済みのサイト: {known}"
            f"(WP_{site.upper()}_BASE_URL / _USERNAME / _APP_PASSWORD を追加すると使えます)"
        )
    return {
        "site": site,
        "base_url": _env_for(site, "BASE_URL").rstrip("/"),
        "username": _env_for(site, "USERNAME"),
        "password": _env_for(site, "APP_PASSWORD"),
    }


def _require_credentials(site: str) -> dict[str, str]:
    cfg = _site_config(site)
    missing = [
        label
        for label, val in (
            ("BASE_URL", cfg["base_url"]),
            ("USERNAME", cfg["username"]),
            ("APP_PASSWORD", cfg["password"]),
        )
        if not val
    ]
    if missing:
        prefix = f"WP_{cfg['site'].upper()}_"
        env_hint = " / ".join(prefix + label for label in ("BASE_URL", "USERNAME", "APP_PASSWORD"))
        raise RuntimeError(
            f"site={cfg['site']!r} の認証情報が不足: {', '.join(missing)}。"
            f"{ROOT / '.env'} に {env_hint} を設定してください"
        )
    return cfg


def _request(method: str, path: str, *, site: str = DEFAULT_SITE, **kwargs: Any) -> Any:
    cfg = _require_credentials(site)
    url = f"{cfg['base_url']}/wp-json/wp/v2{path}"
    resp = requests.request(
        method,
        url,
        auth=(cfg["username"], cfg["password"]),
        timeout=TIMEOUT,
        headers={"Accept": "application/json", **kwargs.pop("headers", {})},
        **kwargs,
    )
    if not resp.ok:
        raise RuntimeError(
            f"WordPress API [{site}] {method} {path} failed: HTTP {resp.status_code} - {resp.text[:500]}"
        )
    if resp.status_code == 204 or not resp.content:
        return None
    return resp.json()


# =========================================================================
# 汎用ヘルパー
# =========================================================================

def _resolve_terms(taxonomy: str, names_or_ids: list[str | int], *, site: str) -> list[int]:
    """カテゴリ・タグの名前を ID に変換。存在しない名前は新規作成する。"""
    if not names_or_ids:
        return []
    ids: list[int] = []
    for item in names_or_ids:
        if isinstance(item, int):
            ids.append(item)
            continue
        s = str(item).strip()
        if s.isdigit():
            ids.append(int(s))
            continue
        existing = _request("GET", f"/{taxonomy}", site=site, params={"search": s, "per_page": 100})
        match = next((t for t in existing if t.get("name") == s), None)
        if match:
            ids.append(int(match["id"]))
        else:
            created = _request("POST", f"/{taxonomy}", site=site, json={"name": s})
            ids.append(int(created["id"]))
    return ids


def _markdown_to_html(text: str) -> str:
    return md.markdown(
        text,
        extensions=["extra", "sane_lists", "toc"],
        output_format="html5",
    )


def _entity_summary(entity: dict[str, Any]) -> dict[str, Any]:
    """投稿(post)または固定ページ(page)の共通サマリを返す。"""
    return {
        "id": entity.get("id"),
        "status": entity.get("status"),
        "title": (entity.get("title") or {}).get("rendered") or (entity.get("title") or {}).get("raw"),
        "slug": entity.get("slug"),
        "link": entity.get("link"),
        "date": entity.get("date"),
        "modified": entity.get("modified"),
        "type": entity.get("type"),
        "parent": entity.get("parent"),
        "menu_order": entity.get("menu_order"),
        "categories": entity.get("categories", []),
        "tags": entity.get("tags", []),
    }


# =========================================================================
# 接続確認
# =========================================================================

@mcp.tool()
def check_connection(site: str = DEFAULT_SITE) -> dict[str, Any]:
    """WordPress への接続と認証が正しいか確認する。

    Args:
        site: 接続先サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。

    Returns:
        サイト情報とログインユーザー名。エラー時は例外を投げる。
    """
    cfg = _require_credentials(site)
    site_resp = requests.get(
        f"{cfg['base_url']}/wp-json",
        auth=(cfg["username"], cfg["password"]),
        timeout=TIMEOUT,
    )
    site_resp.raise_for_status()
    site_info = site_resp.json()
    me = _request("GET", "/users/me", site=site)
    return {
        "site": site,
        "site_name": site_info.get("name"),
        "site_url": site_info.get("url") or site_info.get("home"),
        "logged_in_as": me.get("name"),
        "user_id": me.get("id"),
        "roles": me.get("roles"),
        "available_sites": _discover_sites(),
    }


# =========================================================================
# Posts (投稿)
# =========================================================================

@mcp.tool()
def create_post(
    title: str,
    content: str,
    status: str = "draft",
    excerpt: str = "",
    slug: str = "",
    categories: list[str | int] | None = None,
    tags: list[str | int] | None = None,
    date: str = "",
    content_is_markdown: bool = False,
    meta: dict[str, Any] | None = None,
    featured_media: int = 0,
    site: str = DEFAULT_SITE,
) -> dict[str, Any]:
    """新しい投稿を WordPress に作成する。

    Args:
        title: 投稿タイトル。
        content: 本文。HTML を想定。Markdown を渡す場合は content_is_markdown=True にする。
        status: "draft" (下書き / デフォルト), "publish" (公開), "future" (予約投稿), "pending", "private" のいずれか。
        excerpt: 抜粋(任意)。
        slug: URL スラッグ(任意)。
        categories: カテゴリ名または ID の配列。名前が存在しなければ新規作成する。
        tags: タグ名または ID の配列。名前が存在しなければ新規作成する。
        date: 予約投稿用の日時 (ISO8601, 例 "2026-06-01T10:00:00")。status="future" 時に指定。
        content_is_markdown: True なら content を Markdown として HTML に変換してから投稿する。
        meta: post_meta に書き込むキー/値の辞書(例 {"ssp_meta_description": "..."})。キーは REST 公開されている必要あり。
        featured_media: アイキャッチ画像のメディア ID(upload_media で取得した id)。0(デフォルト)なら設定しない。
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。

    Returns:
        作成された投稿の概要。
    """
    if content_is_markdown:
        content = _markdown_to_html(content)
    payload: dict[str, Any] = {"title": title, "content": content, "status": status}
    if excerpt:
        payload["excerpt"] = excerpt
    if slug:
        payload["slug"] = slug
    if categories:
        payload["categories"] = _resolve_terms("categories", categories, site=site)
    if tags:
        payload["tags"] = _resolve_terms("tags", tags, site=site)
    if date:
        payload["date"] = date
    if meta:
        payload["meta"] = meta
    if featured_media:
        payload["featured_media"] = featured_media
    author_id = _default_author(site)
    if author_id:
        payload["author"] = author_id
    post = _request("POST", "/posts", site=site, json=payload)
    return _entity_summary(post)


@mcp.tool()
def update_post(
    post_id: int,
    title: str = "",
    content: str = "",
    status: str = "",
    excerpt: str = "",
    slug: str = "",
    categories: list[str | int] | None = None,
    tags: list[str | int] | None = None,
    date: str = "",
    content_is_markdown: bool = False,
    meta: dict[str, Any] | None = None,
    featured_media: int = 0,
    site: str = DEFAULT_SITE,
) -> dict[str, Any]:
    """既存投稿を更新する。空文字を渡したフィールドは変更されない。

    Args:
        post_id: 更新対象の投稿 ID。
        featured_media: アイキャッチ画像のメディア ID(upload_media で取得した id)。0(デフォルト)なら変更しない。
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。
        その他: create_post と同じ。

    Returns:
        更新後の投稿の概要。
    """
    payload: dict[str, Any] = {}
    if title:
        payload["title"] = title
    if content:
        payload["content"] = _markdown_to_html(content) if content_is_markdown else content
    if status:
        payload["status"] = status
    if excerpt:
        payload["excerpt"] = excerpt
    if slug:
        payload["slug"] = slug
    if categories is not None:
        payload["categories"] = _resolve_terms("categories", categories, site=site)
    if tags is not None:
        payload["tags"] = _resolve_terms("tags", tags, site=site)
    if date:
        payload["date"] = date
    if meta is not None:
        payload["meta"] = meta
    if featured_media:
        payload["featured_media"] = featured_media
    if not payload:
        raise ValueError("更新項目が指定されていません")
    post = _request("POST", f"/posts/{post_id}", site=site, json=payload)
    return _entity_summary(post)


@mcp.tool()
def get_post(post_id: int, context: str = "edit", site: str = DEFAULT_SITE) -> dict[str, Any]:
    """投稿 1 件を取得する。

    Args:
        post_id: 取得する投稿 ID。
        context: "view" または "edit" (デフォルト)。
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。

    Returns:
        投稿の全フィールド。
    """
    return _request("GET", f"/posts/{post_id}", site=site, params={"context": context})


@mcp.tool()
def list_posts(
    status: str = "any",
    search: str = "",
    per_page: int = 20,
    page: int = 1,
    category_ids: list[int] | None = None,
    tag_ids: list[int] | None = None,
    orderby: str = "date",
    order: str = "desc",
    site: str = DEFAULT_SITE,
) -> list[dict[str, Any]]:
    """投稿を一覧する。

    Args:
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。
        他引数: 従来通り。
    """
    params: dict[str, Any] = {
        "status": status,
        "per_page": min(max(per_page, 1), 100),
        "page": page,
        "orderby": orderby,
        "order": order,
        "context": "edit",
    }
    if search:
        params["search"] = search
    if category_ids:
        params["categories"] = ",".join(str(i) for i in category_ids)
    if tag_ids:
        params["tags"] = ",".join(str(i) for i in tag_ids)
    posts = _request("GET", "/posts", site=site, params=params)
    return [_entity_summary(p) for p in posts]


@mcp.tool()
def delete_post(post_id: int, force: bool = False, site: str = DEFAULT_SITE) -> dict[str, Any]:
    """投稿を削除する。デフォルトはゴミ箱へ移動。

    Args:
        post_id: 削除する投稿 ID。
        force: True なら完全削除、False (デフォルト) ならゴミ箱へ移動。
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。
    """
    params = {"force": "true"} if force else {}
    result = _request("DELETE", f"/posts/{post_id}", site=site, params=params)
    return {"deleted": True, "force": force, "result": result}


# =========================================================================
# Pages (固定ページ) - /app/ 中心に使用
# =========================================================================

@mcp.tool()
def create_page(
    title: str,
    content: str,
    status: str = "draft",
    excerpt: str = "",
    slug: str = "",
    parent: int = 0,
    menu_order: int = 0,
    date: str = "",
    content_is_markdown: bool = False,
    meta: dict[str, Any] | None = None,
    site: str = DEFAULT_SITE,
) -> dict[str, Any]:
    """新しい固定ページを WordPress に作成する。

    Args:
        title: ページタイトル。
        content: 本文。HTML を想定。content_is_markdown=True なら Markdown を HTML 変換。
        status: "draft" (下書き / デフォルト) / "publish" / "private" / "pending"。
        excerpt: 抜粋(任意)。
        slug: URL スラッグ(任意)。/app/{slug}/ になる。
        parent: 親ページ ID。階層構造を作る場合に指定 (0 ならトップレベル)。
        menu_order: 並び順(数字が小さいほど上)。
        date: 公開日時 (ISO8601)。
        content_is_markdown: True なら content を Markdown→HTML 変換。
        meta: post_meta に書き込む辞書。独自メタキーは事前に register_post_meta(show_in_rest=true) で REST 公開されている必要あり。
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。

    Returns:
        作成された固定ページの概要。
    """
    if content_is_markdown:
        content = _markdown_to_html(content)
    payload: dict[str, Any] = {"title": title, "content": content, "status": status}
    if excerpt:
        payload["excerpt"] = excerpt
    if slug:
        payload["slug"] = slug
    if parent:
        payload["parent"] = int(parent)
    if menu_order:
        payload["menu_order"] = int(menu_order)
    if date:
        payload["date"] = date
    if meta:
        payload["meta"] = meta
    author_id = _default_author(site)
    if author_id:
        payload["author"] = author_id
    page = _request("POST", "/pages", site=site, json=payload)
    return _entity_summary(page)


@mcp.tool()
def update_page(
    page_id: int,
    title: str = "",
    content: str = "",
    status: str = "",
    excerpt: str = "",
    slug: str = "",
    parent: int | None = None,
    menu_order: int | None = None,
    date: str = "",
    content_is_markdown: bool = False,
    meta: dict[str, Any] | None = None,
    site: str = DEFAULT_SITE,
) -> dict[str, Any]:
    """既存固定ページを更新する。空文字 / None を渡したフィールドは変更されない。

    Args:
        page_id: 更新対象の固定ページ ID。
        parent: 親ページ ID を変更する場合に指定(明示的に 0 にすればトップレベル化)。
        menu_order: 並び順を変更する場合に指定。
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。
        その他: create_page と同じ。

    Returns:
        更新後の固定ページの概要。
    """
    payload: dict[str, Any] = {}
    if title:
        payload["title"] = title
    if content:
        payload["content"] = _markdown_to_html(content) if content_is_markdown else content
    if status:
        payload["status"] = status
    if excerpt:
        payload["excerpt"] = excerpt
    if slug:
        payload["slug"] = slug
    if parent is not None:
        payload["parent"] = int(parent)
    if menu_order is not None:
        payload["menu_order"] = int(menu_order)
    if date:
        payload["date"] = date
    if meta is not None:
        payload["meta"] = meta
    if not payload:
        raise ValueError("更新項目が指定されていません")
    page = _request("POST", f"/pages/{page_id}", site=site, json=payload)
    return _entity_summary(page)


@mcp.tool()
def get_page(page_id: int, context: str = "edit", site: str = DEFAULT_SITE) -> dict[str, Any]:
    """固定ページ 1 件を取得する。

    Args:
        page_id: 取得する固定ページ ID。
        context: "view" (公開ビュー) または "edit" (デフォルト、編集用の raw 値を含む)。
        site: 取得先サイト。

    Returns:
        固定ページの全フィールド。
    """
    return _request("GET", f"/pages/{page_id}", site=site, params={"context": context})


@mcp.tool()
def list_pages(
    status: str = "any",
    search: str = "",
    parent: int | None = None,
    per_page: int = 50,
    page: int = 1,
    orderby: str = "menu_order",
    order: str = "asc",
    site: str = DEFAULT_SITE,
) -> list[dict[str, Any]]:
    """固定ページを一覧する。

    Args:
        status: "any", "publish", "draft", "future", "pending", "private"。
        search: タイトル/本文の部分検索キーワード。
        parent: 親ページ ID で絞り込み(0 を指定するとトップレベルのみ取得)。
        per_page: 1 ページあたりの件数 (最大 100)。
        page: ページ番号。
        orderby: "menu_order" (デフォルト・並び順)、"date"、"modified"、"title"、"id"。
        order: "asc" (デフォルト) または "desc"。
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。

    Returns:
        固定ページ概要の配列(id / slug / title / link / parent / menu_order など)。
    """
    params: dict[str, Any] = {
        "status": status,
        "per_page": min(max(per_page, 1), 100),
        "page": page,
        "orderby": orderby,
        "order": order,
        "context": "edit",
    }
    if search:
        params["search"] = search
    if parent is not None:
        params["parent"] = parent
    pages = _request("GET", "/pages", site=site, params=params)
    return [_entity_summary(p) for p in pages]


@mcp.tool()
def delete_page(page_id: int, force: bool = False, site: str = DEFAULT_SITE) -> dict[str, Any]:
    """固定ページを削除する。デフォルトはゴミ箱へ移動。

    Args:
        page_id: 削除する固定ページ ID。
        force: True なら完全削除、False ならゴミ箱へ。
        site: 対象サイト。
    """
    params = {"force": "true"} if force else {}
    result = _request("DELETE", f"/pages/{page_id}", site=site, params=params)
    return {"deleted": True, "force": force, "result": result}


# =========================================================================
# Categories / Tags
# =========================================================================

@mcp.tool()
def list_categories(per_page: int = 100, search: str = "", site: str = DEFAULT_SITE) -> list[dict[str, Any]]:
    """カテゴリを一覧する。"""
    params: dict[str, Any] = {"per_page": min(max(per_page, 1), 100)}
    if search:
        params["search"] = search
    cats = _request("GET", "/categories", site=site, params=params)
    return [
        {"id": c["id"], "name": c["name"], "slug": c["slug"], "count": c.get("count", 0), "parent": c.get("parent", 0)}
        for c in cats
    ]


@mcp.tool()
def create_category(
    name: str, slug: str = "", description: str = "", parent: int = 0, site: str = DEFAULT_SITE
) -> dict[str, Any]:
    """カテゴリを新規作成する。"""
    payload: dict[str, Any] = {"name": name}
    if slug:
        payload["slug"] = slug
    if description:
        payload["description"] = description
    if parent:
        payload["parent"] = parent
    cat = _request("POST", "/categories", site=site, json=payload)
    return {"id": cat["id"], "name": cat["name"], "slug": cat["slug"]}


@mcp.tool()
def list_tags(per_page: int = 100, search: str = "", site: str = DEFAULT_SITE) -> list[dict[str, Any]]:
    """タグを一覧する。"""
    params: dict[str, Any] = {"per_page": min(max(per_page, 1), 100)}
    if search:
        params["search"] = search
    tags = _request("GET", "/tags", site=site, params=params)
    return [
        {"id": t["id"], "name": t["name"], "slug": t["slug"], "count": t.get("count", 0)}
        for t in tags
    ]


@mcp.tool()
def create_tag(name: str, slug: str = "", description: str = "", site: str = DEFAULT_SITE) -> dict[str, Any]:
    """タグを新規作成する。"""
    payload: dict[str, Any] = {"name": name}
    if slug:
        payload["slug"] = slug
    if description:
        payload["description"] = description
    tag = _request("POST", "/tags", site=site, json=payload)
    return {"id": tag["id"], "name": tag["name"], "slug": tag["slug"]}


# =========================================================================
# Markdown ファイル経由(投稿/固定ページ両対応)
# =========================================================================

@mcp.tool()
def post_from_markdown_file(
    file_path: str, override_status: str = "", override_site: str = ""
) -> dict[str, Any]:
    """Markdown ファイル(frontmatter 付き)から投稿または固定ページを作成または更新する。

    frontmatter の `id` フィールドがあれば update、なければ create。
    create 後は元ファイルの frontmatter に `id` を書き戻して、次回以降が update になる。

    frontmatter 共通キー:
      title (str, 必須), status ("draft"/"publish"/...), excerpt, slug,
      date (ISO8601), id (int, 更新用), format ("markdown"/"gutenberg"/"html"),
      meta_description (str, post meta へ書き込む。キーは WP_META_DESCRIPTION_KEY で指定、既定 ssp_meta_description=SEO SIMPLE PACK),
      meta (dict, 任意の post_meta を直接指定。キーは REST 公開されている必要あり),
      site (str, 投稿先サイト名。.env の WP_<NAME>_* で登録した名前)

    投稿(post)用キー(post_type 未指定または "post"):
      categories (list), tags (list)
      featured_media (int): アイキャッチ画像のメディア ID(upload_media で取得した id)。
        指定すると create_post/update_post に渡り投稿に紐づく。未指定なら変更しない。
        ※ 固定ページ(page)側は create_page/update_page 未対応のため非対応。

    固定ページ(page)用キー(post_type / type に "page" を指定):
      parent (int): 親ページ ID
      menu_order (int): 並び順

    Args:
        file_path: 対象 Markdown ファイルの絶対または相対パス。
        override_status: 指定すると frontmatter の status を上書きする。
        override_site: 指定すると frontmatter の site を上書きする。

    Returns:
        作成/更新された投稿または固定ページの概要。
    """
    path = Path(file_path)
    if not path.is_absolute():
        path = ROOT / path
    if not path.exists():
        raise FileNotFoundError(f"ファイルが見つかりません: {path}")

    doc = frontmatter.load(path)
    fm = doc.metadata
    body = doc.content

    title = fm.get("title")
    if not title:
        raise ValueError("frontmatter に title が必要です")

    status = override_status or fm.get("status") or "draft"
    site = (override_site or fm.get("site") or DEFAULT_SITE).strip().lower()
    post_type = (fm.get("post_type") or fm.get("type") or "post").strip().lower()

    fmt = (fm.get("format") or "markdown").lower()
    html = body if fmt in ("html", "gutenberg", "raw") else _markdown_to_html(body)

    post_meta: dict[str, Any] = {}
    # meta_description は _meta_description_key(site) のキーに書き込む
    # (既定は SEO SIMPLE PACK の ssp_meta_description、環境変数 WP_META_DESCRIPTION_KEY で変更可・空文字で無効化)
    # ※ 書き込み先キーは REST 公開されている必要がある(同梱の mu-plugins/ssp-meta-rest.php 参照)
    meta_key = _meta_description_key(site)
    if fm.get("meta_description") and meta_key:
        post_meta[meta_key] = fm["meta_description"]
    # 任意の post_meta を直接指定したい場合は frontmatter の meta(dict)を使う
    if isinstance(fm.get("meta"), dict):
        post_meta.update(fm["meta"])

    import datetime as _dt
    date_val = fm.get("date") or ""
    if isinstance(date_val, (_dt.datetime, _dt.date)):
        date_val = date_val.isoformat()
    elif date_val and not isinstance(date_val, str):
        date_val = str(date_val)

    record_id = fm.get("id")
    excerpt_val = fm.get("excerpt", "") or ""
    slug_val = fm.get("slug", "") or ""
    featured_media_val = int(fm["featured_media"]) if fm.get("featured_media") else 0

    if post_type == "page":
        if record_id:
            result = update_page(
                page_id=int(record_id),
                title=title,
                content=html,
                status=status,
                excerpt=excerpt_val,
                slug=slug_val,
                parent=int(fm["parent"]) if fm.get("parent") is not None else None,
                menu_order=int(fm["menu_order"]) if fm.get("menu_order") is not None else None,
                date=date_val,
                meta=post_meta or None,
                site=site,
            )
        else:
            result = create_page(
                title=title,
                content=html,
                status=status,
                excerpt=excerpt_val,
                slug=slug_val,
                parent=int(fm.get("parent") or 0),
                menu_order=int(fm.get("menu_order") or 0),
                date=date_val,
                meta=post_meta or None,
                site=site,
            )
            doc.metadata["id"] = result["id"]
            path.write_text(frontmatter.dumps(doc), encoding="utf-8")
    else:
        if record_id:
            result = update_post(
                post_id=int(record_id),
                title=title,
                content=html,
                status=status,
                excerpt=excerpt_val,
                slug=slug_val,
                categories=fm.get("categories"),
                tags=fm.get("tags"),
                date=date_val,
                meta=post_meta or None,
                featured_media=featured_media_val,
                site=site,
            )
        else:
            result = create_post(
                title=title,
                content=html,
                status=status,
                excerpt=excerpt_val,
                slug=slug_val,
                categories=fm.get("categories"),
                tags=fm.get("tags"),
                date=date_val,
                meta=post_meta or None,
                featured_media=featured_media_val,
                site=site,
            )
            doc.metadata["id"] = result["id"]
            path.write_text(frontmatter.dumps(doc), encoding="utf-8")

    return result


@mcp.tool()
def markdown_to_html(text: str) -> str:
    """Markdown を WordPress 投稿向けの HTML に変換する(プレビュー用)。"""
    return _markdown_to_html(text)


# =========================================================================
# メディア(画像)アップロード
# =========================================================================

@mcp.tool()
def upload_media(
    file_path: str,
    filename: str = "",
    title: str = "",
    alt_text: str = "",
    site: str = DEFAULT_SITE,
) -> dict[str, Any]:
    """ローカルの画像ファイルを WordPress のメディアライブラリにアップロードする。

    Args:
        file_path: アップロードする画像の絶対/相対パス。
        filename: メディアのファイル名(省略時は元ファイル名)。★Content-Disposition は ASCII 推奨なので、
                  日本語ファイル名のときは英数字+ハイフンの名前(例 "screenshot-01.png")を明示指定する。
        title: メディアのタイトル(任意)。
        alt_text: 代替テキスト(任意、SEO/アクセシビリティ用)。
        site: 対象サイト名(.env の WP_<NAME>_* で登録した名前)。省略時は既定サイト。

    Returns:
        {id, source_url, mime_type, title}。source_url を wp:image ブロックの src に使う。
    """
    import mimetypes

    cfg = _require_credentials(site)
    path = Path(file_path)
    if not path.is_absolute():
        path = ROOT / path
    if not path.exists():
        raise FileNotFoundError(f"ファイルが見つかりません: {path}")

    name = filename or path.name
    ctype = mimetypes.guess_type(name)[0] or mimetypes.guess_type(str(path))[0] or "application/octet-stream"
    data = path.read_bytes()

    resp = requests.post(
        f"{cfg['base_url']}/wp-json/wp/v2/media",
        auth=(cfg["username"], cfg["password"]),
        headers={
            "Content-Disposition": f'attachment; filename="{name}"',
            "Content-Type": ctype,
        },
        data=data,
        timeout=TIMEOUT * 3,
    )
    if not resp.ok:
        raise RuntimeError(
            f"media upload failed [{site}]: HTTP {resp.status_code} - {resp.text[:500]}"
        )
    m = resp.json()

    if title or alt_text:
        patch: dict[str, Any] = {}
        if title:
            patch["title"] = title
        if alt_text:
            patch["alt_text"] = alt_text
        m = _request("POST", f"/media/{m['id']}", site=site, json=patch)

    title_val = m.get("title")
    if isinstance(title_val, dict):
        title_val = title_val.get("rendered") or title_val.get("raw")
    return {
        "id": m.get("id"),
        "source_url": m.get("source_url"),
        "mime_type": m.get("mime_type"),
        "title": title_val,
    }


if __name__ == "__main__":
    try:
        mcp.run()
    except Exception as e:
        print(f"MCP server error: {e}", file=sys.stderr)
        raise

補助プラグイン（mu-plugins 用）

置き場所は /wp-content/mu-plugins/ssp-meta-rest.php、mu-plugins（must-use plugins）フォルダが無ければ wp-content/ の下に自分で作ります
ここに置くと管理画面に項目も出ないまま自動で有効になるので、有効化のクリックは不要
テーマやプラグインを更新しても消えないので、自作の小さな仕組みを常駐させるのにちょうど良い場所

JavaScriptを書き込む機能だけは、あえて公開していません
認証情報が漏れたときに、好きなスクリプトを埋め込まれかねないからです

<?php
/**
 * Plugin Name: SEO SIMPLE PACK Meta REST API Support
 * Description: SEO SIMPLE PACK のメタフィールド + SWELL の投稿別カスタムCSS を WP REST API 経由で読み書きできるようにする補助プラグイン。投稿(post)・固定ページ(page)の両方に対応(/app/ のアプリ庫サイトは固定ページ運用のため page 必須)。
 * Author: Local helper
 * Version: 1.2.0
 *
 * 配置場所: /wp-content/mu-plugins/ssp-meta-rest.php
 *   (mu-pluginsフォルダが無ければ作成すること。配置するだけで自動有効化される)
 *
 * 変更履歴:
 *   1.0.0 - 初版(post のみ対応)
 *   1.1.0 - page 型にも対応(/app/ サイト用)
 *   1.2.0 - SWELL の投稿別カスタムCSS(swell_meta_css)を追加して MCP から記事ごとのCSSを書けるようにした。
 *           ※ JS(swell_meta_js)は「あえて公開しない」: 認証情報(アプリパスワード)が漏れた場合に
 *             サイト訪問者へ任意の JavaScript を注入できてしまう(実質 XSS)リスクがあるため。
 *           ※ そのまま出力フラグ(swell_meta_css_plane / swell_meta_js_plane)も、操作面・事故面を
 *             増やさないため公開しない(CSS は既定=<style> で囲む、で十分)。
 *
 * メタキーの根拠:
 *   - SEO SIMPLE PACK の post meta: ssp_meta_description / ssp_meta_robots(先頭アンダースコアなし)。
 *   - SWELL の投稿別CSS: swell_meta_css(投稿編集画面のメタボックス textarea name="swell_meta_css" より確認)。
 *   いずれも標準では REST 非公開のため、本プラグインで show_in_rest 登録する。
 *   ※ 一括書き戻し前に1記事で読み書きを検証することを推奨。
 */

add_action('init', function () {
    // REST 公開するメタキー(値はすべて文字列)
    $rest_meta_keys = [
        'ssp_meta_description',   // SSP メタディスクリプション(書き戻しの本命)
        'ssp_meta_robots',        // SSP robots(noindex 等。必要な記事のみ)
        'swell_meta_css',         // SWELL 投稿別カスタムCSS(wp_head で出力)。JS はあえて非公開
    ];

    // 対象 post type:post(blog 用)+ page(/app/ 用、SWELL 固定ページ運用)
    $target_post_types = ['post', 'page'];

    foreach ($rest_meta_keys as $key) {
        foreach ($target_post_types as $post_type) {
            register_post_meta($post_type, $key, [
                'type'          => 'string',
                'single'        => true,
                'show_in_rest'  => true,
                'auth_callback' => function () use ($post_type) {
                    // post なら edit_posts、page なら edit_pages の権限チェック
                    return $post_type === 'page'
                        ? current_user_can('edit_pages')
                        : current_user_can('edit_posts');
                },
            ]);
        }
    }
});

更新版は javeo2022/wordpress-mcp-server にも置いています

私のおすすめ本PR

VBAPythonAI・ClaudePC仕事術

Excel マクロ&VBA やさしい教科書 Office 2024/2021 Microsoft 365対応

Amazon楽天

てっとり早く確実にマスターできる Excel VBAの教科書 改訂新版

Amazon楽天

Excel マクロ/VBA 今日から使える業務の自動化入門

Amazon楽天

VBAエキスパート公式テキスト Excel VBAベーシック

Amazon楽天

［最速入門］ChatGPTに任せる Excelマクロ&VBA

Amazon楽天

退屈なことはPythonにやらせよう 第3版

Amazon楽天

シゴトがはかどる Python自動処理の教科書

Amazon楽天

もっとシゴトがはかどる Python×Excel×AI 業務自動化の教科書

Amazon楽天

Python2年生 スクレイピングのしくみ 第2版

Amazon楽天

スッキリわかるPython入門 第2版

Amazon楽天

実践Claude Code入門

Amazon楽天

Claude CodeによるAI駆動開発入門

Amazon楽天

開発効率をアップする! Claude Code 実用入門

Amazon楽天

Microsoft 365 Copilot踏み込み活用術

Amazon楽天

できるClaude & Claude Cowork

Amazon楽天

できる人のパソコン仕事術 なんと効率10倍!

Amazon楽天

できるWindows 11パーフェクトブック 困った!&便利ワザ大全 改訂3版

Amazon楽天

できるポケット 時短の王道 ショートカットキー全事典 改訂4版

Amazon楽天

ビジュアル ショートカットキー時短ワザ事典

Amazon楽天

取り急ぎ、パソコン仕事の基本だけ教えてください！

Amazon楽天

ジャンルごとに私のおすすめからランダムで5冊を表示しています

Claude Code を触っていて、「AIが勝手に書いたコードに、地雷が混じってないか心配」と感じたことはありませんか？

2026年5月26日に Anthropic から公開された security-guidance は、その不安に正面から答える公式のセキュリティ系プラグインです

この記事では、Claude Code Desktop を使い始めた方〜慣れてきた方向けに、security-guidance が何をしてくれて、どう入れて、どう使えばいいのかを一通り解説します

ついでに、このプラグインだけでは守りきれない部分をどう補うか(deny リスト・自動モード・MCP の注意点など)も横展開で触れます

Claude Code のセキュリティ全体像はClaude Code Desktop 初心者向けセキュリティ5選、プラグインを支える土台はClaude Code 拡張機構入門でも扱っているので、合わせて読むと位置づけが立体的になります

そもそも security-guidance って何のプラグイン？

ざっくり言うと、Claude がコードを書いた瞬間に、その内容を別の Claude がセキュリティ目線でレビューしてくれる仕組みです

もう少し正確に言うと、Claude Code には「プラグイン」と呼ばれる拡張パッケージの仕組みがあり、その公式マーケットプレイス claude-plugins-official に並んでいる中の1つが security-guidance です

大事なポイントは次の3つです

• Anthropic 公式のプラグインなので、出どころの安心感が大きい
• 無料・全プラン対応、課金プランでなくても使える
• 導入後は裏で勝手に動く、毎回コマンドを打つ必要はない

公開直後から大きな注目を集め、Claude にコードを書かせる人ほど効きやすい性質のプラグインとして広く紹介されています

何ができる？ 3層のレビューでコードを見張る

security-guidance が偉いのは、3つのタイミングで深さの違うレビューを走らせてくれるところです

レイヤー1:ファイルに書き込んだ瞬間のパターン照合

Claude がファイルを編集するたびに、「危ない書き方」が含まれていないかを高速チェックします

ここは AI の追加呼び出しを伴わない、いわゆる文字列マッチによる照合なので、余分な利用料金は発生しません

「ファイルが書かれたら、その内容を辞書と突き合わせて怪しい言葉が出てきたら警告する」というイメージです

レイヤー2:ターンの終わりにまとめてレビュー

Claude が「はい、ここまでで一区切りです」と返した瞬間、そのターンで変わったファイルをまとめて 別の Claude にセキュリティレビューさせる動きが入ります

ここで言う ターンとは、こちらが1回メッセージを送って、Claude が動いて返事して、その応答が終わるまでの1往復のことです

このレイヤーは、文字列マッチでは見抜けない 権限まわりの抜け穴・脆弱な暗号化・想定外の入力経路みたいな話を拾ってくれます

裏で動くため、Claude の返答自体は遅くなりません、見つかった指摘は次の応答で「ここ直しておきますね」と本人(Claude)が修正してくれるイメージです

レイヤー3:コミットの直前にじっくりレビュー

Claude が git commit や git push を実行しようとしたタイミングでも、もう一段深いレビューが走ります

このレベルになると周辺コード(呼び出し元・サニタイズ処理など)まで読んだ上で「これは実際にヤバいやつ」か「文脈上は安全」かを判定してくれます

このおかげで 「形だけ見ると危なそうだけど、実は文脈的に大丈夫なコード」を誤検出しすぎないように調整されています

どんな脆弱性パターンを見つけてくれる？

レイヤー1(ファイル編集時)で照合される代表的なパターンを、噛み砕いて紹介します

専門用語が多めなので、それぞれ「要は何が問題なのか」をセットで書きます

eval() や new Function() :「文字列を実行コードにしてしまう」系

JavaScript の eval() や new Function() は、文字列をそのままプログラムとして実行する関数です

つまり、外部から渡された文字列がうっかり混ざると、悪意のあるコードがそのまま動いてしまう恐れがあります

child_process.exec() や os.system() :「コマンドをそのまま投げる」系

Node.js の child_process.exec() や Python の os.system() は、シェル(=Windowsで言うコマンドプロンプト的なもの)に命令文を渡す関数です

ユーザーが入力した値をそのまま結合してしまうと、想定外のコマンドが任意に実行される事態になります、いわゆるコマンドインジェクションです

dangerouslySetInnerHTML や innerHTML :「画面表示がそのまま乗っ取られる」系

React の dangerouslySetInnerHTML や、素の JavaScript の .innerHTML = は、HTML を直接埋め込む書き方です

ここに ユーザーが入力した文字列をそのまま入れると、スクリプトタグごと埋め込めてしまう=いわゆる XSS(クロスサイトスクリプティング)の温床になります

pickle :「保存したデータを読むだけのつもりが、コードまで動く」系

Python の pickle は、データを丸ごとファイルに保存して、後で読み戻すための仕組みです

便利な反面、信頼できないファイルを pickle で読み込むと、読み込み処理の中で任意のコードが実行される設計になっています、外部から受け取ったファイルを pickle で開くのは原則として避けるのがおすすめです

.github/workflows/ 配下の編集 :「GitHub Actions の権限を握る」系

GitHub Actions の設定ファイル(.github/workflows/ 配下の YAML)は、ビルドやデプロイの自動化を定義する場所です

ここを書き換えられると リポジトリ単位の権限を握られることになるので、Claude が触ろうとしたら一律で注意喚起されます

ほかにも document.write などの古い書き方をはじめ、いくつかの代表的な落とし穴に反応するようになっています

導入方法 Desktop ユーザーの最短ルート

Claude Code Desktop での導入は、3ステップで終わるかんたんさです

Desktop の「プラグイン」サブメニューは シンプルな作りで、上にインストール済みプラグインが並び、下に 「プラグインを管理」(歯車アイコン)と 「＋ プラグインを追加」のボタンがあるレイアウトです、迷う要素はあまりないので、追加のボタンから順に進めば security-guidance が一覧に並びます

使ってみるとどう動く？ 実際の見え方

導入直後は、基本的に 普段どおりに Claude を使うだけでかまいません

「コードを書いて」「ここを直して」とお願いしている裏で、上で説明した3層レビューが勝手に走っている感じです

レビューで何か見つかった時の会話の流れ

たとえば Claude が JavaScript で eval() を含むコードを書いたとします

すると次のターンの冒頭で Claude が 「security-guidance から指摘が来ました、eval は危ないのでこちらの書き方に直しますね」のような前置きと一緒に、安全な実装に書き換えてくれます

こちらが「セキュリティチェックして」と頼まなくても、コードに変更があった時点でレビューが走るのがこのプラグインの一番の旨味です

プロジェクト固有のルールも足せる

「うちのアプリでは admin ルートには原則として権限チェックを入れたい」みたいな プロジェクト固有のルールも、追加で食わせられます

プロジェクト直下に .claude/claude-security-guidance.md という Markdown を置き、普段の日本語で「これは NG」「ここは原則として通す」と書いておけば、レビュー時に追加のお作法として参照してくれます

そのほか、決まった文字列(例:本番用 API キーの先頭文字列)を機械的に検出したいときは .claude/security-patterns.yaml に独自の正規表現を書く手もあります

ファイル形式の細かい仕様(YAML スキーマ・JSON 形式での代替・User / Project / Project local の3階層での探索順など)は Anthropic 公式ドキュメントのAdd your own rulesセクションに一次情報がまとまっているので、独自ルールを本気で書き込むときはそちらが正本になります

他の安全対策と組み合わせる プラグイン以外の打ち手

security-guidance は強力ですが、これ単体で Claude Code のセキュリティが完成する訳ではありません

あくまで「書いた瞬間に一次レビューを挟む」というレイヤーなので、それと並行して整えておきたい安全策を横並びで紹介します

settings.json の deny リストで「触らせない」枠を作る

Claude Code には settings.json という設定ファイルがあり、ここに「触ったらアウトのファイル」を列挙できます

具体的には permissions.deny セクションで、見られたくない・書き換えてほしくないパスを指定する形です

最低限デフォルトで入れておきたいのは次のあたりです

• .env 系(APIキー・パスワードがよく入っているファイル)
• .pem .key(SSL 証明書・秘密鍵)
• id_rsa(SSH の秘密鍵)
• credentials.json(各種クラウドサービスの認証情報)

イメージとしては次のような書き方になります

{
  "permissions": {
    "deny": [
      "Read(./**/.env)",
      "Read(./**/*.pem)",
      "Read(./**/*.key)",
      "Read(./**/id_rsa)",
      "Read(./**/credentials.json)"
    ]
  }
}

これにより、security-guidance が 「書いた後」にレビューするのに対し、deny リストは 「そもそも触らせない」側のガードを担当します、役割が違うのでセットで使うと安心感が増します

「自動モード」と「許可をバイパス」は別物

Claude Code Desktop の挙動モードでよく混同されるのが、「自動モード」と「許可をバイパス」の2つです

名前が似ていて紛らわしいですが、中身はまるで違います

respectGitignore で .gitignore のファイルを除外する

地味に効くのが respectGitignore: true という公式オプションです

これを settings.json に入れておくと、プロジェクトの .gitignore に書かれているファイルが、そのまま Claude のファイル選択画面からも除外されます

.gitignore は 「Git に管理してほしくない=GitHub にもアップしないでほしい」リストで、もともと .env や ビルド成果物などが入っていることが多いので、それがそのまま Claude の対象外になるのはありがたい挙動です

MCP サーバーを入れる時の確認ポイント

もう1つ、忘れずに整えておきたいのが MCP 関連の確認です

MCP(Model Context Protocol)は、Claude に外部ツールやデータベースを使わせるための仕組みですが、MCP サーバーやプラグインはあなたの権限で任意のコードを実行できる高信頼コンポーネントです

つまり、出どころが怪しい MCP サーバーを入れるのは、得体のしれないソフトをインストールするのと変わりません

• 公式・有名なソース(Anthropic・大手 OSS プロジェクト)からのみ入れる
• 説明文だけで判断せず、READMEやコードに目を通す
• 必要が無くなった MCP サーバーは早めに無効化する

security-guidance 自体は Anthropic 公式なので信頼性の面で気にする必要はありませんが、「プラグインや MCP は全部安心」と勘違いしないのが大事です

このあたりの基本設計はClaude Code 設定ファイル早見表で全体像を整理しているので、深掘りしたい方はそちらもどうぞ

期待しすぎないこと プラグインの限界

ここまで読むと「もう security-guidance を入れておけば安心」と思いたくなりますが、過信は禁物です

正直に言うと、このプラグインは 「コードを書く瞬間によくあるパターンを止める」レイヤーであって、セキュリティ対策のすべてを引き受けてくれる訳ではありません

設計や仕様レベルの脆弱性は別途レビューが要る

例えば「そもそも認証フローがおかしい」「権限の設計が甘い」みたいな話は、文字列マッチでは見つかりません

ターン終了時やコミット時のレビューでは多少ひっかかる可能性はあるものの、設計や仕様レベルの問題は人間のコードレビューや設計レビューで拾うのが原則です

依存ライブラリの脆弱性は対象外

あなたが書いたコード自体は問題なくても、使っているライブラリに脆弱性があったというケースは多々あります

これは security-guidance のスコープ外で、別途 npm audit や Dependabot のような 依存関係チェックの仕組みを並走させるのが現実的です

レビュワーAIも見落とす

レイヤー2・3で動くレビュー側の Claude も、人間と同じく見落とすことがあります

「プラグインが何も言わないから安全」は思考停止のサインです、最終的にはコードを読む(=人間がレビューする)習慣も並行して持っておくのが望ましいです

内部にある上限とモデル設定も知っておく

もう少し細かい話として、レビューには 上限が設けられています、知っておくと「あれ動いてない?」となったときに切り分けやすいです

• ターン終了時のレビューは 1ターン最大30ファイルまで、しかも連続3回までで一旦止まります
• コミット時のレビューは 1時間に20回まで、それを超えると一時的に走らなくなります

大量変更や連続 commit を続けると、全部はカバーしきれないというのを頭の片隅に置いておくと安全です

初心者向けおすすめ運用フロー

「結局、何からやればいいの？」という方向けに、最初に押さえるステップを順に並べておきます

このあたりまで整えると、security-guidance を含めた多層の守りがだいぶ立体的になります

よくある質問(FAQ)

まとめ プラグイン1つで完結はしないけど、入れる価値は十分

security-guidance は、Claude にコードを書かせるなら入れない理由がほぼ無いくらいに気軽に導入できる公式プラグインです

大事なポイントをおさらいします

• Anthropic 公式・無料・全プラン対応、入れない理由はほぼ無い
• 3層レビュー(編集時・ターン終了時・コミット時)で多角的にチェック
• eval / 外部コマンド / XSS / pickle / GitHub Actions など典型的な落とし穴を拾う
• 書き込みを止める訳ではない、Claude にレビュー結果を渡して直してもらう設計
• deny リスト・自動モード・respectGitignore と組み合わせて多層防御に
• 設計・依存ライブラリ・未知の脆弱性は対象外なので過信しない

個人的には、「ちゃんと整えれば、Claude にコードを任せても怖くないラインまで来た」と感じます

Claude Code の安全策を一通り整理したい方はClaude Code Desktop 初心者向けセキュリティ5選、プラグインまわりの土台が気になる方はClaude Code 拡張機構入門、設定ファイルの全体像はClaude Code 設定ファイル早見表もどうぞ

security-guidance を入れたうえで、deny を整えて、自動モードで使う、この3点を押さえておくと、Claude Code との付き合い方がぐっと安心側に寄ります

私のおすすめ本PR

VBAPythonAI・ClaudePC仕事術

Excel マクロ&VBA やさしい教科書 Office 2024/2021 Microsoft 365対応

Amazon楽天

てっとり早く確実にマスターできる Excel VBAの教科書 改訂新版

Amazon楽天

Excel マクロ/VBA 今日から使える業務の自動化入門

Amazon楽天

VBAエキスパート公式テキスト Excel VBAベーシック

Amazon楽天

［最速入門］ChatGPTに任せる Excelマクロ&VBA

Amazon楽天

退屈なことはPythonにやらせよう 第3版

Amazon楽天

シゴトがはかどる Python自動処理の教科書

Amazon楽天

もっとシゴトがはかどる Python×Excel×AI 業務自動化の教科書

Amazon楽天

Python2年生 スクレイピングのしくみ 第2版

Amazon楽天

スッキリわかるPython入門 第2版

Amazon楽天

実践Claude Code入門

Amazon楽天

Claude CodeによるAI駆動開発入門

Amazon楽天

開発効率をアップする! Claude Code 実用入門

Amazon楽天

Microsoft 365 Copilot踏み込み活用術

Amazon楽天

できるClaude & Claude Cowork

Amazon楽天

できる人のパソコン仕事術 なんと効率10倍!

Amazon楽天

できるWindows 11パーフェクトブック 困った!&便利ワザ大全 改訂3版

Amazon楽天

できるポケット 時短の王道 ショートカットキー全事典 改訂4版

Amazon楽天

ビジュアル ショートカットキー時短ワザ事典

Amazon楽天

取り急ぎ、パソコン仕事の基本だけ教えてください！

Amazon楽天

ジャンルごとに私のおすすめからランダムで5冊を表示しています

Claude Code Desktopを使い始めて何記事か触っているうちに、「もっと自動化したい」「設定を整理したい」「ファイル操作を任せる範囲を絞りたい」みたいなことを考え始めますよね

そこから先に進むには 「拡張機構」と呼ばれる仕組みを理解しておくと、できることの幅が一気に広がります

この記事では、Claude Codeに慣れてきた中級者向けに 拡張機構の4本柱(Skills・MCP・Hooks・Subagents)と、その土台になる「ハーネス」という概念を体系的に解説します

応用編では各機能の具体的なテクニックや、CLAUDE.md・Permissions・Worktreesといった日常運用で効いてくる設定を扱う予定なので、まずはこの基礎編で全体像を押さえてもらえると嬉しいです

Claudeの基本的な使い方はClaudeの使い方を初心者向けに解説した記事、AI周辺の用語はClaudeを始める前に知っておきたい用語集でまとめているので、初学者の方はそちらから入るのがスムーズです

そもそも「ハーネス」って何

Claude Code関連の記事を読んでいると、最近 「ハーネス」(harness)という言葉をよく見るようになりました、聞き慣れない単語ですよね

LLM(脳)とハーネス(体・道具・記憶)

Claude本体は厳密にいうと LLM(大規模言語モデル)というテキストを生成するだけのモデルです、ファイルを読んだり、コマンドを実行したり、記憶を保持したりする機能は本体にはありません

それなのにClaude Codeが「ファイルを操作する」「コマンドを実行する」「設定を覚える」みたいな振る舞いができるのは、本体の周りに『体・道具・記憶』に相当するソフトウェア層が組まれているからです、これが「ハーネス」と呼ばれているものになります

例えるなら次のような関係性です

このうち 「脳」以外のすべてがハーネスです、つまり実は Claude Codeのコードの大半はLLMの中身ではなく、このハーネス側にあることになります

だからカスタマイズの自由度が高い

ここが中級者にとって重要な視点で、ハーネス側はユーザーが書き換えられる部分が多いです

LLM本体(Claudeの賢さ)はAnthropicが訓練したものをそのまま使うしかありませんが、周辺のハーネスは settings.json や Skills・Hooks・MCPサーバーなどで 自分の使い方に合わせて自由に拡張できる設計になっています

つまり「Claude Codeをもっと使いこなしたい」というのは ハーネス側をどう構築するかの話とほぼ同義です、ここから先で扱う4本柱はすべてこのハーネス層の構成要素になります

ハーネスエンジニアリングって何

ハーネスを 「設計・構築・最適化する取り組み全般」を ハーネスエンジニアリングと呼びます

Anthropic公式や業界でもよく出てくる用語で、最近は prompt engineering(プロンプトエンジニアリング)から harness engineering へと重心が移ってきている流れがあります

両者の違いをざっくり整理すると次のようになります

ハーネスエンジニアリングが扱う主な範囲はこんな感じです

• 権限ポリシー設計(permissions.deny / allow / askの構造、4階層の使い分け)
• コンテキスト管理戦略(CLAUDE.mdの階層化、auto-compactタイミング設計、Memory運用)
• ツール選定と制限(allow-tools、Subagentごとの権限分離、危険コマンドのdeny)
• 拡張機構の設計(Skills / Hooks / MCP / Subagents の組み合わせ)
• エラー復旧・隔離(worktreeでの隔離戦略、失敗時の挙動設計)
• ロングランニング設計(複数セッションをまたぐタスクのcontext reset、引き継ぎファイル設計)
• 観測・ロギング(エージェントが何をしたかの記録、PostToolUseでのログ出力)

つまりこの記事で紹介している 4本柱の話もすべてハーネスエンジニアリングの構成要素になります

参考までに、Claude Codeのコードベース分析(2026年)では 「AI判定ロジック1.6% / ハーネス層98.4%」というデータもあって、Claude Code自体がハーネスエンジニアリングの結晶みたいな存在になっています

「もっと使いこなしたい」と感じたら、この記事で扱う拡張機構を組み合わせて自分用のハーネスを設計していくフェーズに入ったということになります

拡張機構の4本柱

Claude Codeのハーネスを拡張する仕組みは、現時点で大きく4つあります

1. Skills:再利用可能な指示パターンをまとめる
2. MCP:外部サービスと連携するための共通規格
3. Hooks:イベント発生時に自動でスクリプトを走らせる
4. Subagents:タスクを隔離した別エージェントに委譲する

それぞれが 「困りごと」の解決手段として性格が違うので、ここから1つずつ役割を整理していきます

Skills:再利用可能な指示パターン

Skillsは「よく使うプロンプト指示をテンプレート化して、Claudeに覚えさせる」仕組みです

毎回「コミットメッセージを書くときは○○のフォーマットで、こういう観点で…」と説明するのは面倒、でも一度Skillとして登録しておけば、Claudeがその場面を察知して自動で呼び出してくれたり、こちらから /コマンド名 で呼び出せたりします

ファイルの置き場所は次の2か所

• ~/.claude/skills/<skill-name>/SKILL.md(全プロジェクト共通の個人スキル)
• .claude/skills/<skill-name>/SKILL.md(プロジェクト固有、Gitで共有可)

SKILL.mdの基本構造はこんな感じです

---
name: commit-message
description: Gitのコミットメッセージを書くときに呼び出すスキル。conventional commits形式で、件名と本文を生成
when_to_use: Gitコミット、コミットメッセージ作成、commit
allow-tools: Bash(git diff *) Bash(git status)
user-invocable: true
---

# コミットメッセージ生成スキル

差分を確認した上で、次のルールでコミットメッセージを書いてください

- 件名は50字以内、英語または日本語
- conventional commits形式(feat / fix / docs / chore など)
- 本文は「なぜこの変更が必要だったか」を1〜2文で
- 文末に署名を入れない

トリガー方法の3パターン

Skillsは どうやって発動するかで3つのパターンがあります

自動トリガーを効かせるには description フィールドの書き方が重要で、「いつ使うべきか」を具体的なキーワード付きで書いておくとClaudeの判断精度が上がります

Skillsを使うメリット

• 同じ指示を毎回書かなくて済む(プロンプトの肥大化を防げる)
• チームで共有できる(プロジェクトのSkillsをGit管理)
• スキル単位でツール権限を絞れる(allow-toolsで限定)
• 引数を取れるので汎用的なテンプレートが作れる

個人的にはClaude Codeの4本柱のうち 一番気軽に作り始められるのがSkillsで、Markdownを書くだけで作れるので習作に最適です

MCP:外部サービス連携の共通規格

MCP(Model Context Protocol)は、Claudeが外部のサービスやデータベースとやり取りするための 共通言語です

これがなかった頃は、AIに「WordPressを操作させる」「GitHubのissueを読ませる」みたいなことをやろうとすると、それぞれのサービスごとに 個別のつなぎ込みコードを書く必要がありました

MCPは そのつなぎ込みのインターフェース部分を標準化したものです、MCPに対応した「MCPサーバー」を1個用意すれば、Claudeから自由にその外部サービスを呼び出せるようになります

公式コネクタ vs 自作MCPサーバー

MCPの活用には大きく2つのアプローチがあります

中級者がまず触るなら 公式コネクタからがおすすめ、設定画面からON/OFFするだけで使えます

そこから先「自分のWordPressと連携したい」「社内システムと繋ぎたい」となったら自作MCPサーバーの出番です

MCPが解決する課題

• 「ChatGPT版」「Claude版」みたいに AIごとに連携コードを書き直さなくていい(MCP対応サーバーは複数AIで共通利用可)
• 認証(APIキー・OAuth)の扱いが標準化されている
• ツールの一覧表示・呼び出しも自動で処理される

2026年現在、AIエージェント業界の標準規格として急速に広がっていて、これからますます重要になる仕組みです

Hooks:イベント駆動の自動化

Hooksは、Claudeが何かをするタイミング(イベント)に合わせて 自動でスクリプトを実行する仕組みです

SkillsやCLAUDE.mdが「Claudeにお願いする」性格の機構なのに対して、Hooksは 機械的に発動するのが大きな違いになります、「Claudeの判断に任せず、確実に毎回走らせたい処理」がある場合に効きます

主要なHookイベント

とくに PreToolUse は 危険コマンドの最終防衛線として使えるので、中級者なら覚えておきたいイベントです

設定例:rm -rf を見つけたら強制ブロック

例えば settings.json のdenyリストだけでは不安なので「実行直前に二重チェックして、危ない場合は通知も出したい」みたいなケースで使います

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/block-dangerous.sh"
          }
        ]
      }
    ]
  }
}

呼び出されるシェルスクリプトの最小例はこんな感じ

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command')

if echo "$CMD" | grep -qE 'rm -rf|DROP TABLE'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "危険コマンドをHookでブロックしました"
    }
  }'
fi
exit 0

Hookは exit code とJSON出力の組み合わせで「許可/拒否/警告だけ」を制御できる仕組みになっていて、ここの設計が地味に奥深いです

SkillsとHooksの違い

初心者が混乱しがちなのが「SkillsとHooksってどう違うの?」という点なので整理しておきます

Subagents:隔離コンテキストでの委譲

Subagents(サブエージェント)は、メインのClaudeセッションから 別のコンテキストを持つClaudeにタスクを委譲する仕組みです

たとえば「ファイルを50個調査して、関連箇所をまとめて」みたいな重いタスクを、メインの会話に直接やらせると コンテキストウィンドウが調査ログで埋まってしまう問題があります

これをSubagentに任せれば、メインのコンテキストはきれいなまま、結果サマリーだけを受け取れます

AGENT.mdの基本構造

Subagentの定義ファイルは .claude/agents/<agent-name>/AGENT.md に置きます

---
name: code-researcher
description: 大規模リポジトリの調査用エージェント、関連ファイル特定と概要把握を担当
tools: Read Grep Glob Bash(rg *)
model: claude-sonnet
maxTurns: 30
permissionMode: ask
isolation: worktree
---

あなたはコード調査の専門エージェントです

ユーザーから渡されたテーマに沿って、リポジトリ内の関連ファイル・関数・モジュールを特定し
最後に「どこに何があるか」のサマリーをMarkdownで返してください

ファイル変更や書き込みは行わず、読み取り専用で動作してください

主要なフィールド

Subagentsの典型ユースケース

• リサーチタスク:大量ファイルから関連箇所を抽出
• コードレビュー:セキュリティ・パフォーマンスを別の視点で並行チェック
• テスト実行:長時間かかるテストを別エージェントに任せて、メインは設計を続行
• 並列実装:複数モジュールを別エージェントで同時実装

注意点として、Subagentは親のSkillsを継承しない仕様です、必要なSkillはAGENT.mdの中で明示的にプリロードする必要があります

4本柱の使い分けマップ

ここまで4つの拡張機構を見てきましたが、 どの場面でどれを使うかを整理するとこんな感じになります

同じ「自動化したい」というニーズでも、「Claudeの判断を信頼する」のがSkills、「機械的に処理させる」のがHooks、という対称関係を覚えておくと選びやすくなります

同様に 「メイン会話内で完結させる」のが標準、「コンテキストを分けたい」のがSubagents、「Claude内で完結」のが標準、「外部とつなぐ」のがMCP、と対比で覚えると整理しやすいです

最初の一歩|まず作ってみるなら

4本柱を一気に覚えるのは大変なので、それぞれ 「習作として最初に作るならこれ」というお題を1つずつ紹介します

Skills:コミットメッセージ生成スキル

上で例示したような commit-message スキルが Skills入門に最適です

毎回作業しているうちに「commitメッセージこんな感じで書きたい」という個人の好みが見えてくるので、それをそのままMarkdownに書き出すだけで形になります、5分くらいで完成します

MCP:公式コネクタを1つ試す

自作MCPはハードルが高めなので、まずは 公式コネクタを1つ有効化してみるのがおすすめ

Google Drive・GitHub・Notion など、自分が日常的に使っているサービスのコネクタを設定画面から有効にして、Claude経由でファイル一覧を取ったり検索したりする体験から始めるとMCPの便利さが実感できます

Hooks:危険コマンド通知だけのHook

いきなり複雑なHookを書くより、「危険コマンドを実行しようとしたらデスクトップ通知を出すだけ」みたいな最小Hookから入るのが分かりやすいです

Windowsなら msg、Macなら osascript、シェルスクリプトの記述方法もコピペできるものが多いので、最初の壁は高くありません

Subagents:リサーチ専用エージェント

「リサーチタスク用に tools を Read Grep Glob だけに絞った専用エージェント」を作るのが、Subagentsの威力を体感する最短ルートです

大きめリポジトリで「○○の実装どこにある?」みたいな調査をするとき、メインで進めるのとSubagentに任せるのとで、コンテキスト消費量の違いに驚くと思います

まとめ|拡張機構を押さえると見える世界

長くなりましたが、ポイントをぎゅっと整理するとこんな感じです

1. Claude Codeの大半は 「ハーネス」と呼ばれる周辺ソフトウェア層、ここをいじれるのがカスタマイズの幅
2. 拡張機構は4本柱:Skills(再利用指示)・MCP(外部連携)・Hooks(機械的自動化)・Subagents(隔離委譲)
3. 同じ「自動化」でも Claudeに判断させるのがSkills、機械的に発動させるのがHooksという対称関係
4. 同じ「処理委譲」でも 外部と繋ぐのがMCP、コンテキスト分離するのがSubagentsという対称関係
5. 慣れるまでは Skillsから入るのが最も気軽、Markdown1ファイルで始められる

この基礎編で4本柱の見取り図ができたので、応用編では CLAUDE.mdの深掘り・Memory管理・Permissions応用・Worktreesでの並列開発など、日常運用で効いてくる中級者向けテクニックを掘り下げる予定です

各拡張機構の個別深掘り(Skillsだけで1記事、MCPだけで1記事、というレベル)も今後 順次まとめていく予定なので、興味のある分野があれば追っかけてもらえると嬉しいです

初心者向けの周辺記事として、Claudeの使い方を初心者向けに解説した記事、Claudeを始める前に知っておきたい用語集、Claude Code Desktop初心者向けセキュリティ5選も合わせてどうぞ

私のおすすめ本PR

VBAPythonAI・ClaudePC仕事術

Excel マクロ&VBA やさしい教科書 Office 2024/2021 Microsoft 365対応

Amazon楽天

てっとり早く確実にマスターできる Excel VBAの教科書 改訂新版

Amazon楽天

Excel マクロ/VBA 今日から使える業務の自動化入門

Amazon楽天

VBAエキスパート公式テキスト Excel VBAベーシック

Amazon楽天

［最速入門］ChatGPTに任せる Excelマクロ&VBA

Amazon楽天

退屈なことはPythonにやらせよう 第3版

Amazon楽天

シゴトがはかどる Python自動処理の教科書

Amazon楽天

もっとシゴトがはかどる Python×Excel×AI 業務自動化の教科書

Amazon楽天

Python2年生 スクレイピングのしくみ 第2版

Amazon楽天

スッキリわかるPython入門 第2版

Amazon楽天

実践Claude Code入門

Amazon楽天

Claude CodeによるAI駆動開発入門

Amazon楽天

開発効率をアップする! Claude Code 実用入門

Amazon楽天

Microsoft 365 Copilot踏み込み活用術

Amazon楽天

できるClaude & Claude Cowork

Amazon楽天

できる人のパソコン仕事術 なんと効率10倍!

Amazon楽天

できるWindows 11パーフェクトブック 困った!&便利ワザ大全 改訂3版

Amazon楽天

できるポケット 時短の王道 ショートカットキー全事典 改訂4版

Amazon楽天

ビジュアル ショートカットキー時短ワザ事典

Amazon楽天

取り急ぎ、パソコン仕事の基本だけ教えてください！

Amazon楽天

ジャンルごとに私のおすすめからランダムで5冊を表示しています