2026年9月1日、AnthropicからClaude Fable 5.1が公開されました
Fable 5の後継にあたるモデルで、入力と出力の単価はFable 5から据え置き、いっしょに発表されたMythos 5.1とは中身が同じモデルという関係

新しいモデルが出ると乗り換えたくなりますが、今回はちょっと事情が変わっていて、公式自身が「まずはOpus 5から」と書いています
要点は3つなんです

Claude Fable 5.1とは 公式スペックをFable 5・Opus 5と並べる

Claude Fable 5.1は、Anthropicが2026年9月1日に出した最上位クラスのモデルで、モデルIDはclaude-fable-5-1です

トークンやコンテキストウィンドウあたりの用語がふわっとしている方は、トークンやコンテキストウィンドウの意味を先に確かめると、この先の表がすんなり読めると思います
公式のモデルページと価格表に載っている数字を、Fable 5とOpus 5の2つと横に並べたのが下の表
表に出てくるeffortは、モデルにどれだけ考えさせるかの強さ設定です

まず目に入るのは、1Mコンテキストが3モデルとも同じという行でしょう
窓の大きさはFable 5.1の売りではなくて、Opus 5もSonnet 5も同じ1Mなんです

ジャベ雄

3モデルとも横並びなので、窓の広さでは選ぶ理由になりません

差が出ているのは知識のカットオフで、Fable 5.1は2026年6月と、現行ラインナップの中でいちばん新しい日付になっています
Opus 5が2026年5月、Fable 5が2026年1月なので、Fable 5から見ると5か月ぶん新しい知識を持っている計算

そのかわり、公式のレイテンシ区分はSlower(現行でいちばん遅い)と書かれています
何秒・何分かかるという公式の数字は出ていないので、待ち時間の具体的なところは触ってみないと分からないでしょう

Fable 5.1で新しくなったところ

公式が能力の伸びとして挙げているのは6つの領域で、コーディングと事務作業まわりに寄っています

• 長時間まかせるエージェント型のコーディング
• 文書・スプレッドシート・スライドを扱う仕事
• リサーチと検索
• 画像の読み取り、PDFの中の密なグラフや表とかも対象
• ロングコンテキスト(長い入力の扱い)
• パソコンの操作

日本語で使う立場でちゃんと見ておきたいのは、この一覧に多言語が入っていないところ
公式は多言語の性能はFable 5と同等と書いていて、日本語が良くなったとは言っていません

ジャベ雄

日本語が良くなったとは公式も書いていないので、期待しすぎないほうが安全です

新機能として公式が挙げているのは5つ
いちばん財布に近いのがキャッシュ読み取りの値下げで、100万トークンあたり$1.00だったものが$0.25になりました

Anthropicはこの値下げについて、APIのようにトークン単位で課金される場面の話として「典型的なワークロードならFable 5より約25%、エージェント色の濃い作業なら最大約45%安くなる」と見込んでいます
実測値ではなく公式の見積もりなので、鵜呑みにはできない数字

しかも安くなるのはキャッシュを使い回す長い作業のほうで、トークン課金で単発のチャットを投げるぶんには1円も変わりません
入力と出力の単価は据え置きですし、定額プランなら月額そのものは変わりません
ただしProなどでFableを使うと、減るのは使用クレジット(実費)のほうです(後述)

残る3つは、APIを自分で叩く人向けの追加です

• 会話の途中でeffortを切り替えても、プロンプトキャッシュを保ったままになりました
  Fable 5はこの指定自体に非対応でエラー、Opus 5は対応済み
• そのターンかぎりのシステムメッセージが置けます
  次のユーザー発言が来ると消える一方で履歴には残るので、キャッシュも思考も壊れない作り
• ツール実行中の進捗を読める形で返す設定が増えました
  既定だと長い処理の途中が無言に見えるので、進捗のテキストだけ受け取れるようにする指定

3つとも、公式の扱いはまだbeta(試験段階)です

5つ目が電子透かし
Fable 5.1とMythos 5.1が作ったテキストには統計的な透かしが入り、コード実行ツールなどで作った対応形式の画像・動画は、Claude APIのFiles API経由で取り出したときにC2PA(コンテンツの出どころを示す業界規格)の来歴情報が付きます
透かしの仕組み自体は前からあるもので、Claudeが出力に印を入れている話は8月の週末メモでも触れました

公式のベンチマーク表にSWE-benchは載っていない

Anthropicの発表ページの比較表に並んでいるのは次の数字だけで、その中にSWE-benchはありません

表の「—」は、公式がその欄の数字を出していないという意味です
数値はどれもAnthropicの自社公表で、この比較表にはeffortの明記がありません(effort別の精度とコストの図は別に出ています)

伸び幅が大きいのはだいたいエージェント系で、Terminal-Bench 4.0がFable 5の42.0%から55.8%まで上がっています
業務ワークフローのAutomationBenchも17.1%から31.4%なので、長く動かし続ける場面ほど差が付く並び

コーディングの話になるとSWE-benchの数字を探したくなりますが、今回の発表ページには入っていません
他所で見かける数字は別のソースのものなので、公式値として扱わないほうが安全だと思います

Fable 5との違い 3つの挙動変更と価格

APIの作りで変わったのは3つで、どれも思考(thinking)とツールの呼び方まわりです

1. 強制ツール利用が使えません
   tool_choiceにanyやtoolを渡すとエラー(autoとnoneは従来どおり)
2. 思考ブロックが作ったモデルに紐づきます
   Fable 5.1は旧モデルの思考を読めますが、旧モデルはFable 5.1の思考を読めない一方通行
3. 過去のターンを編集すると思考ブロックが無効になります
   2026年8月31日以降に作られた新規アカウントで強制される検査

1つ目について公式は、思考がつねにオンなので強制すると思考を飛ばしてしまい、モデルが考えを引数の中に書き込んで引数の質が落ちるから、と説明しています

3つとも重そうに見えますが、過去のターンを編集する話については、Claude Code・claude.ai・Managed Agents・Agent SDKが会話の履歴をそのまま保つ作りなので表に出てきません(公式が名指しで書いています)
残る2つは自分でAPIを呼ぶ側の話で、SDK経由でもtool_choiceをany / toolにしていれば影響を受けます

価格は入力$10・出力$50で据え置き、動いたのはキャッシュ読み取りだけです(詳しくは前の節)

Fable 5はLegacyという扱いに変わり、公式がすすめているのは5.1への移行
ただし引退は2027年6月9日より前にはしないと書かれているので、今すぐ使えなくなるわけではありません

もう1つ、Fable 5で使えたPriority Tier(処理枠を前もって確保する契約)が5.1では非対応になりました
ちょっと誤解しやすいところで、Opus 5も同じく非対応ですし、そもそもPriority Tierのキャパシティ確約は新規購入ができない状態
だから「Opus 5なら使えるのに」は乗り換えの理由にならないでしょう

コードを変えなくても現れる挙動の差

設定を1つも変えていなくても表に出てくる違いが、公式の数えかたで7つあります
チャットで使う人に関係するのは、このあたり

• 太字・見出し・リストといった装飾が減る
• 文章が場所によって密になる(長い文が増えて段落が少なくなる)
• 要約のときに、引用符なしで原文をそのまま再現しがち
• effortをlowにすると、検索せず記憶から答えがち

エージェントとして長く走らせる人に関わるのは、こういうのだったりします

• 並列のツール呼び出しが減って、1ターン1呼び出しになることがある
• 長いツール実行の途中で、進捗の更新が減る(特に高いeffortのとき)
• 小さな修正でも、ファイル全体を書き直しがち

並列のツール呼び出しについて公式は「往復が増えるぶんトークンと実時間はかかるが、答えの質は落ちない」と書いています
ファイル全体の書き直しのほうも「結果はたいてい同じだが、出力トークンと時間を食う」という書き方をしています

チャットの装飾が減る件について公式は、旧モデル向けに書いた「装飾するな」系の指示が、必要な構造まで消してしまうことがあると注意しています
カスタム指示を自分で書いている人には、実害がありそうな話だと思います

ジャベ雄

装飾を減らす指示を書いている人は、いちど見直しどきかもしれません

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

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

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

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

Notta｜AI自動文字起こし

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

Nottaを見てみる

Opus 5との違い 単価は2倍、キャッシュ読み取りだけ逆転

入力・出力ともOpus 5のちょうど2倍で、Fable 5.1が$10 / $50、Opus 5が$5 / $25
やっぱり最初に目が行くのは、この2倍という数字でしょう

ところがキャッシュ読み取りだけは逆転していて、Fable 5.1の$0.25はOpus 5の$0.50の半額なんです
公式の移行ガイドにも「Opus 5のレートの半分」とはっきり書かれています
同じ文脈を何度も読み直させる長い作業だと、この差が積み上がる場面もあるかもしれません

• 思考を切れない
  Opus 5はeffortがhigh以下なら思考をオフにできますが、Fable 5.1はどのeffortでもエラー
• 強制ツール利用の可否
  tool_choiceのany / toolを受け付けるのはOpus 5だけ
• 拒否されたときに返ってくる理由の種類が違う
  Opus 5はサイバーセキュリティ関連だけですが、Fable 5.1は生物学など拒否されうる範囲が広めです
• ZDR(ゼロデータ保持)では原則使えない
  Fable 5.1は30日のデータ保持が必須で(Anthropicの明示許可がある場合を除く)、Opus 5はZDRでも可
• fast modeはOpus 5とOpus 4.8だけ
  出力速度を上げるモードにFable系は入っていません(research previewでClaude APIのみ、申し込みが要ります)
• レイテンシ区分
  Fable 5.1がSlower、Opus 5がModerate

ややこしいのは、fast modeの値段の見え方
Opus 5をfast modeで回すと入力と出力の単価が$10 / $50になって、Fable 5.1の標準単価と並びます
でも同じになるのは入力と出力の単価だけで、キャッシュ読み取りはfast modeでも入力単価の0.1倍という倍率のままなので、当てはめると$1.00
Fable 5.1の$0.25とは4倍の開きが残ります
中身も別物で、fast modeは速さを買うもの・Fable 5.1は能力を買うものという違い

ジャベ雄

同じ値段だからどっちでもいい、とはならないところです

公式が示している使い分けの順番は、この3段

プランごとに使えるか Claude Codeの既定は変わらない

Fable 5.1が出ても、Claude Codeの既定モデルは切り替わりません
Fableはどのプランでも、モデルピッカーか/modelから自分で選ぶ形

Freeでは使えないと公式が書いていて、Fable 5と5.1はプラン上の扱いが同じ、とも明記されています

Claude Codeの既定モデルは、主なプランではMax・Teamプレミアム・Enterprise・APIがOpus 5、Pro・Team標準がSonnet 5のままです
今回いちばん実用に近い結論はここで、新しいモデルが出てもClaude Codeの既定は動かないという話なんです
claude.aiのほうは、Fable 5 / 5.1をモデルピッカーから選ぶ、と公式が書いています

じゃあProで使えるのか？というと、選べはします
ただプランの上限枠には含まれず、使用クレジットの消費になります
追加費用なしで回せるのはMaxとTeamプレミアムで、それも週次上限の50%まで、という線引きです

Proで長く回すと、減るのは上限ではなく使用クレジット、つまり実費
Claude Codeでは、Fableのリクエストが使用クレジットに課金される前に同意のプロンプトが出ます(Enterpriseの組織課金では出ません)
一度「クレジットで続ける」を選ぶと、次からは出ないので、安全弁として当てにしすぎないほうが無難です
ここからは私の見立てですが、Proで常用する前提ならプランの見直しも選択肢に入る気がします

ジャベ雄

Proの人は、Fableを回したぶんだけ財布が直接減る、と覚えておくと安全です

まとめ 日常はOpus 5、上振れが要るときだけFable 5.1

使い分けの線は公式がはっきり引いていて、日常のほとんどはOpus 5、届かないときだけFable 5.1という順番です

• 入力・出力の単価はFable 5と同じ、下がったのはキャッシュ読み取りだけ($1.00 → $0.25)
• 「約25%安くなる」はトークン課金の場面でのAnthropicの見積もり、月額は変わらないがProは使用クレジット(実費)が減る
• 知識カットオフは2026年6月でいちばん新しいが、レイテンシ区分はSlower
• 挙動が変わる3点のうち履歴編集の話はClaude Code・claude.aiが吸収してくれる
  残る2つは自分でAPIを呼ぶ側の話
• Claude Codeの既定は変わらない / Proは使用クレジット扱いでMaxでも週次上限の50%まで

6月にFable 5で1日作業してみたときは、トークンの減りがけっこう速かった記憶
ただ5.1では、キャッシュ読み取りが安くなる一方で、往復が増えたりファイル全体を書き直したりでトークンを余分に使う場面も公式が挙げているので、どちらに転ぶかはもう少し使ってみないと分かりません

6月にFable 5を1日まわしたときの体感は、別記事にまとめてあります

あわせて読みたい

Claude Fable 5を1日使った正直レビュー Anthropicの新モデルClaude Fable 5を1日触った体感をまとめました、有能だけどトークンの減りが速い、Opus 4.8とのスペック比較・世間の評価・噂のファクトチェックまで本家ブログらしく等身大で書いています

比較の相手になるOpus 5については、価格据え置きのまま1Mが既定になった回で整理しています

数字や仕様をご自身で確かめたい方へ、一次情報の置き場所は3つ
Fable 5.1単体のスペックと価格は公式概要ページ(日本語版、表は英語のまま)、Fable 5からの変更点はWhat’s newのページ(日本語)、プランごとの扱いはヘルプセンターの記事(英語)にあります

新しいモデルが出ると、とりあえず切り替えたくなるもの
でも今回は公式のほうが「まずOpus 5」と言ってくれているので、私はしばらく既定のまま様子を見るつもりです

Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

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

平川知秀

Amazonで見る楽天で見る

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

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています

Claude Code フォルダ構成は、放っておくとどんどん増えていきます
materials・research・rules・assets、見覚えのない名前が並んでいても、それが何のためにあるのかは分からないまま
このフォルダ、消してしまっていいんでしょうか？

私も気づいたら似たようなフォルダがいくつも並んでいて、どれが本物か分からなくなりました
AIは指示されればフォルダを作りますが、前回どう名付けたかまでは気にしてくれません

この記事では、AIが作るフォルダを3つの層に分けて読み解きます
層が分かると「これは触っていい」「これは触ると壊れる」がその場で判断できるはずです

ジャベ雄

フォルダ名を覚えるより、層で見分けるほうが早いです

Claude Code フォルダ構成は3つの層に分けて読む

結論から言うと、プロジェクトの中にあるフォルダは「誰が決めたか」で3層に分かれます
この分け方が便利なのは、層ごとに「名前を変えたときに何が起きるか」がはっきり違うからです

ややこしいのは、この3層が同じ階層に並んで置かれることです
見た目はどれも同じフォルダなので、開いてみるまで区別がつきません

ちなみに冒頭で挙げた materials と rules も、実は別々の層
rules は公式仕様に載っている第1層、materials は誰も決めていない第3層です、名前の見た目が似ていても扱いはまったく別ものになります

フォルダ構成とディレクトリ構成は同じ意味

調べているとディレクトリ構成という書き方によく出会いますが、これはフォルダ構成とまったく同じ意味です
どちらか一方が正しいわけではありません

ディレクトリのほうが古くからある呼び方で、もともとは「住所録」や「目録」を指す言葉でした
Windows がフォルダという呼び方を広めたあとも、開発の現場では前からの呼び方が残っていて、いまも両方が混在しています

AIも文脈によって呼び分けます
フォルダ名の意味を調べるときは、どちらの言葉でも同じ内容にたどり着くと思っておけば十分でしょう

ジャベ雄

呼び方が2つあるだけで、指しているものは同じです

第1層|公式に決まっているフォルダは名前を変えられない

第1層は Claude Code が仕様として読みに行くフォルダです
名前を変えると、その中身は読み込まれなくなります、置き場所も名前も公式ドキュメントで決まっているので、勝手に変えられません

プロジェクトの中の .claude フォルダ

プロジェクトのフォルダ直下に置く .claude が第1層の本体です
先頭にドットが付いているので、環境によっては隠しフォルダとして見えないこともあります

この中で見落としやすいのが rules です
「AIが勝手に作った雑多なフォルダ」に見えますが、実際は公式に用意された置き場で、テーマごとに指示を分けて書いておくためのものです

もうひとつ、commands というフォルダを見かけることがあります
スラッシュコマンドを置く場所ですが、公式は skills への移行をすすめています、同じ仕組みに統合されたので新しく作るなら skills のほうです

ジャベ雄

rules を「よくわからないから」で消すと、指示が丸ごと効かなくなります

パソコン全体で共通の ~/.claude フォルダ

プロジェクトごとの設定とは別に、パソコンのユーザーフォルダの中にも同じ名前のフォルダがもう1つ
こちらは全プロジェクト共通の設定置き場で、どのプロジェクトを開いても効きます

パスの先頭に付いている ~ は、ホームフォルダ(自分のユーザーフォルダ)を1文字で表す省略記号、読み方は「チルダ」です
この記号で始まっていたら、自分のユーザーフォルダから始まる場所を指しています

Windows なら C:\Users\(ユーザー名) がその場所にあたります
つまり ~/.claude/ と書いてあったら、それは C:\Users\(ユーザー名)\.claude\ のことだと読み替えてください

なぜ Windows なのに / 区切りなのか、と思われたかもしれません
この書き方はもともと Mac や Linux の流儀で、開発の世界では共通語として使われているものです、Claude も説明のときはこちらで書いてきます

ジャベ雄

チルダを見たら「自分のユーザーフォルダのことだな」と思えば大丈夫です

実際に開いてみると、この一覧に載っていないフォルダもいくつか並んでいます
cache・sessions・shell-snapshots のような、アプリが動くために自分で作って自分で使う置き場です

この手のフォルダは説明書に載っていないほうが普通だと考えてください
公開されている仕様は「人が触る前提のもの」だけで、動作の裏側で使う置き場までは案内されません

なお第1層の「ファイル」のほうを詳しく知りたい場合は、設定ファイルだけを一覧にした記事があります
どのファイルがどこに効くのか、継承のルールまで整理してあるのでこちらもどうぞ

あわせて読みたい

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

第2層|業界の慣習で決まっているフォルダ

第2層は、仕様ではないけれどほとんどの開発者が同じ意味で使っているフォルダです
名前を変えても動きますが、読む人が混乱します、いわば共通語のようなものだと思ってください

AIがプロジェクトを組み立てるとき、まず作るのがこの層です
学習したコードの大半がこの慣習に従っているので、指示しなくても自然にこの名前が出てきます

この中でいちばん質問されるのが src です
読み方は「ソース」で、source の母音を抜いた省略形になります、コンパイルが必要な言語で古くから使われてきた作法がそのまま各言語に広がりました

dist と build が両方あって混乱することもあります
どちらも「完成品の置き場」でほぼ同じ意味です、片方しか使わないのが普通なので、両方あるなら片方は使われていない可能性があります

もうひとつ覚えておくと役に立つのが vendor です
「取引先」という意味そのままで、自分で書いていないコードが入っています、ここを直しても更新のたびに上書きされるので触らないのが原則です

フォルダ名の付け方にも慣習がある

名前そのものだけでなく、書き方のほうにもゆるい決まり
自分でフォルダを追加するときも、この形に合わせておくと後々あつかいやすくなります

• すべて小文字で書く(Windows以外では大文字と小文字が別ものとして扱われるため)
• 単語の区切りはハイフンかアンダースコアにする、空白は入れない
• 日本語の名前は避ける、コマンドやツールで扱うときに事故のもとになる
• 複数形か単数形かは、プロジェクトの中で揃える

ジャベ雄

最後の「揃える」が、あとで一番効いてくる決まりです

第3層|AIがその場で作る作業フォルダ

第3層が、この記事でいちばん伝えたいところです
公式仕様でもなく業界の慣習でもない、その場の話の流れでAIが名付けたフォルダがここに入ります

「調べた内容をまとめておいて」と頼めば、AIはどこかに置き場を作ります
そのときの名前は materials かもしれないし research かもしれません、どちらでも間違いではないぶん、決まりようがないわけです

右端の列に注目してください
第3層のフォルダは、ほぼすべてが第2層の誰かと役割が重なっています、output と dist、reference と docs といった具合です

ここが散らかりの発生源になります
慣習の名前を使えば済むところに、AIがその場の言葉で別の名前を作ってしまうからです

とはいえ第3層そのものが悪いわけではありません
コードを書かない使い方だと src も tests も出番がないので、第3層の名前でプロジェクトの大半が構成されることすらあります、問題は名前が揺れることだけです

ジャベ雄

第3層は自由なぶん、放っておくと一番散らかります

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

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

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

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

Notta｜AI自動文字起こし

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

Nottaを見てみる

AIに任せると同義フォルダが増えていく

いくつかのプロジェクトをAIに任せて育ててきた結果、私の手元では同じ役割のフォルダが違う名前で並ぶ状態があちこちにできていました
散らかり方には、はっきりした型があります

test と tests が両方あるのは、我ながらなかなかの散らかり具合でした
どちらにテストを書けばいいのか、開いた瞬間に手が止まりました

画像置き場にいたっては6種類に分かれていました
作業の内容が少しずつ違うので当時はそれぞれ理由があったはずですが、あとから見るとどれを開けばいいのか自分でも分からないありさま

なぜ増えてしまうのか

AIの不注意というより、仕組みから見て起きるべくして起きています
理由は主に4つです

• AIは前回どう名付けたかを見ていない、そのときの会話の流れだけで名前を決める
• 既存のフォルダがあっても、こちらの言い回しが違えば別のフォルダを作ってしまう
• 英語としてはどちらも正しいので、AIから見れば間違いに見えない
• 人が指摘しないかぎり、増えたことに誰も気づかない

3つめが特に厄介です
test も tests も英語として自然なので、AIには直すべき対象として見えていません、つまり待っていても勝手には揃いません

増殖を止める方法

対策はシンプルで、フォルダ名の正本を1か所に書いておくことです
プロジェクト直下の CLAUDE.md か、第1層で紹介した .claude/rules/ の中に書きます

## フォルダの決まり

- テストは tests/(複数形)に置く、test/ は作らない
- 画像は images/ に集約する、figures/ や screenshots/ は作らない
- 調べものは research/ に置く、materials/ は作らない
- 一時ファイルは tmp/ に置く、使い終わったら消してよい

新しいフォルダが必要になったら、勝手に作らず先に相談すること

ポイントは「使う名前」だけでなく「使わない名前」も書くこと
使わないほうを明記しておかないと、別の言い回しで頼んだときにまた作られます

そもそも .claude/rules/ という置き場が公式に用意されているのは、こういう決まりごとを書いておくためです
指示を一度書いておけば毎回読まれるので、同じ注意を繰り返さずに済みます

すでに散らかってしまった場合も、片付け自体を頼めます
「同じ役割のフォルダが複数ないか調べて、統合案を出して」と伝えると一覧にしてくれます、移動や削除は案を見てから自分で判断するのが安全です

ジャベ雄

使わない名前まで書く、これに気づくまで結構かかりました

そのまま使えるフォルダ構成テンプレート2種

ここまでの整理をふまえて、そのままコピーして使える形にしました
おすすめは最初から凝った構成にしないこと

公式ドキュメントも同じ立場で、まずは CLAUDE.md を1枚置くところから始めて、使いながら育てるやり方をすすめています
空のフォルダをいくつも先に作っても、結局は使われずに残るだけ

アプリ・ツールを作る場合

myapp/
├── CLAUDE.md          プロジェクトの決まりごと
├── README.md          このアプリが何なのかの説明
├── .claude/
│   ├── settings.json  権限などの設定
│   └── rules/         テーマ別の指示
├── src/               プログラム本体
├── tests/             動作確認のコード
├── docs/              仕様や手順の文書
├── assets/            画像やアイコンなどの素材
└── scripts/           補助的な小さいプログラム

第2層の慣習だけで組んだ構成
この形にしておけば、初めて見る人にも中身の見当が付きますし、AIも迷わず正しい場所に置いてくれます

dist や build をあえて入れていないのは、必要になったらツールが自動で作るからです
同じ理由で logs や tmp も先に用意しません、使う段になってから増やせば十分です

ブログや資料などを作る場合

myblog/
├── CLAUDE.md          文体や書き方の決まりごと
├── .claude/
│   ├── settings.json  権限などの設定
│   └── rules/         テーマ別の指示
├── articles/          記事の原稿
├── research/          下調べ・調査メモ
├── images/            画像
└── archive/           公開済み・使い終わったもの

コードを書かない使い方だと、src や tests は出番がありません
そのぶん第3層の名前を使うことになるので、どれを使うか先に決めておきたいところ

この構成では、調べものの置き場を research に寄せて materials は作らないことにしています
逆に materials 側に寄せてもかまいません、大事なのはどちらかに決めて書いておくことのほうです

ジャベ雄

迷ったら少なめに作る、足りなくなってから足せば十分です

消していいフォルダ・ダメなフォルダの見分け方

散らかったフォルダを片付けたくなったときの判断基準です
層ごとに扱いが違うので、まずはどの層かを見てから決めます

いちばん多いのは最後の「役割が分からない」です
この場合はフォルダを開いて、中に入っているファイルの拡張子と日付を見るのが早道
そのフォルダ、最後に更新されたのはいつでしょうか？

日付が古いまま止まっていれば、途中で使わなくなった置き場の可能性が高いでしょう
逆にここ数日の日付が並んでいるならいまも動いているということなので、消さずに残します

名前が同じでも中身が違うことがある

もうひとつ注意したいのが、同じ名前でも層が違うケースです
たとえば rules は .claude/ の中にあれば第1層ですが、プロジェクト直下に置かれていれば誰かが作った第3層かもしれません

判断の決め手は名前ではなく置かれている場所です
同じ名前を見つけたら、どの階層にあるのかを先に確認してください

templates や agents も同じように取り違えやすい名前です
.claude/ の外に出ていれば公式仕様とは無関係なので、消しても動作には響きません

消す前の安全弁

そのプロジェクトを Git で管理しているなら、消す前にひと手間かけておくと安心です
Claude に「このフォルダは Git で管理されているか調べて」と頼めば、裏で確認して教えてくれます

• Gitで管理されている → 消しても履歴から戻せる
• Gitで管理されていない → 消したら戻せない、先に別の場所へ退避する

ジャベ雄

迷ったら消さずに archive へ移す、これでたいてい間に合います

まとめ|3層に分ければフォルダ構成は読める

AIが作ったフォルダは、名前をひとつずつ覚えなくても大丈夫です
「誰が決めたのか」で3層に分ければ、初めて見るフォルダでも扱い方の見当が付くはずです

• 第1層(.claude/ の中)は公式仕様、名前を変えると効かなくなるので触らない
• 第2層(src ・ docs ・ tests など)は業界の共通語、慣習に合わせておくと読みやすい
• 第3層(materials ・ research など)は誰も決めていない、だから自分で決める
• 同義フォルダの増殖は、CLAUDE.md か .claude/rules/ に正本を書いて止める
• 消すときは層を確認してから、中身を見てから

最初の一歩としておすすめなのは、いま開いているプロジェクトのフォルダを眺めて、それぞれがどの層かを言ってみることです
言えなかったものが、そのまま整理すべき対象です

ちなみに CLAUDE.md も .claude/rules/ の中身も、すべてマークダウンという形式で書かれています
AIが書いた文書を読んだり直したりする機会は増える一方なので、記法を押さえておくとこのあたりの作業がぐっと楽になるはずです

あわせて読みたい

マークダウンの書き方入門 AIに伝わるmd記法まとめ マークダウン(Markdown)の書き方を初心者向けにまとめました チャットでよく使う基本記法から CLAUDE.md など AIが読むファイルで使う記法まで網羅し 素のMarkdownとGFM拡張の違いやよくある崩れの直し方まで解説しています

第1層で触れた skills や agents が実際に何をするものなのかは、Claude Codeの拡張機構をまとめた記事で解説しています
用語そのものが分からないときはClaude用語集もあわせてどうぞ

Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

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

平川知秀

Amazonで見る楽天で見る

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

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています

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用語集から入ると、設定の意味もより腑に落ちるはずです

Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

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

平川知秀

Amazonで見る楽天で見る

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

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています

もともと私の手元には、自分のサーバー上のデータベースに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は頼りになります、興味が出たら、まずは小さな「自分専用の道具」から試してみてはどうでしょうか?

ジャベ雄

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

Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

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

平川知秀

Amazonで見る楽天で見る

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

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています

最近、Claude Codeと組み合わせて使うツールとしてObsidian(オブシディアン)というメモ管理ツールがよくおすすめされているのをご存じですか？AIに調べてもらった内容や書いてもらった下書きを、そのまま自分の手元に貯めていける受け皿として相性がいいのが理由です

この相性のよさは、雰囲気だけの話ではありません
Obsidianを作っている開発元のCEO(Steph Angoさん)本人が、2026年にClaude CodeなどのAIエージェントにObsidianを操作させるためのSkills(スキル)を公開しています
MITライセンスの無料・オープンソースで数万のスターを集めていて、作っている当人がClaude Codeとの連携を後押ししているくらいです

そもそも何が嬉しいかというと、Claude Codeが生み出したテキストの置き場所がきれいに片づくところです
調べ物・下書き・設計メモがチャットの履歴に流れたままだと、後から探すのが大変になります
メモ帳にコピペしていくのも量が増えると整理が追いつきません
Obsidianに繋ぐと、その出力がそのままノートとして貯まっていきます

この記事ではObsidianとは何かから始めて、料金まわりの誤解を先に潰し、Windowsへの導入とClaude Codeとの繋ぎ方までを初心者向けに通しで紹介します
難しいコマンドは出てこないので気軽に試せます

Obsidianとは？ローカルにメモを貯める無料ツール

Obsidianは、自分のパソコンの中にノート(メモ)を貯めていくためのツールです
特徴はノートをMarkdown(マークダウン)という軽い書式のテキストファイルとして保存するところでして、特殊な独自形式ではなく、ただの .md ファイルの集まりになります

Markdownというのは、記号をちょっと足すだけで見出しや箇条書きを表せる書き方のことです
「# 見出し」と書けば見出しになる、くらいの軽さです
難しく考えなくても、普通のメモのつもりで書き始められます

Vault(保管庫)はただのフォルダ

Obsidianを使ううえで一度だけ覚えておきたいのがVault(ボールト=保管庫)という言葉です
といってもかまえなくて大丈夫で、Vaultの正体はパソコン上のひとつのフォルダでしかありません

公式の説明でも「ObsidianはノートをMarkdown形式のプレーンテキストファイルとしてVaultに保存する、Vaultとはローカルファイルシステム上のフォルダのこと」と書かれています
つまりノートの実体は、エクスプローラーから普通に開けるフォルダの中の .md ファイルです

このあと出てくるClaude Codeとの連携が壊れにくいのは、まさにこの「中身がただのフォルダとテキストファイル」というシンプルさのおかげです
この点は後でもう一度効いてきます

ノート同士を繋いで地図にできる

Obsidianのもうひとつの売りが、ノート同士をリンクで繋げることです
あるノートの中で別のノートの名前を書いておくと、リンクとして辿れるようになります

リンクで繋いだノートの関係はグラフビューという画面で、点と線の地図のように一覧できます
ノートが増えてきたときに「どれとどれが関係していたか」を見渡せるので、自分専用のミニ百科事典のような感覚で育てていけます

逆向きの繋がりを示すバックリンク(そのノートを参照している側の一覧)や、繰り返し使う書式を雛形にできるテンプレート、図を描けるCanvasといった機能もそろっています
ここで挙げた機能はどれも後で出てくる無料の範囲に入っているので、いまは「そういうものがある」とだけ頭の隅に置いておけば十分です

Obsidianの料金は？本体は全用途で完全無料

ツールを入れる前にいちばん気になるのがお金の話だと思うので、先に確認しておきます
結論から言うとObsidian本体はあらゆる用途で完全に無料です
サインアップ(アカウント登録)もいりません

個人で使うのはもちろん、仕事で使う場合も、非営利の活動で使う場合も費用はゼロです
公式サイトにも「Free for all purposes(あらゆる用途で無料)」と明記されています

「性能を絞った無料版」ではない

無料と聞くと「機能制限された体験版なのでは？」と疑いたくなりますが、Obsidianは違います
グラフビュー・バックリンク・テンプレート・Canvas、それに1000を超えるコミュニティプラグインまで、主要な機能はすべて無料に含まれています

ノートの数や使える端末の台数にも上限はありません
つまり「無料だから本気では使えない」という心配は不要でして、これがObsidianを最初の一歩として勧めやすい理由です

有料なのは任意のクラウドサービスだけ

では何が有料かというと、本体とは別売りの2つの任意サービスだけです
これらは機能のロックを外すものではなく、できあがったノートに後から重ねるクラウドのオプションだと考えてください

SyncはiCloudやSyncthingなどで無料の代わりを用意することもできるので、まずは本体だけで始めて、必要になったら検討する形で問題ありません

ジャベ雄

無料って聞くと逆に不安になりますよね？でもこれ、本体だけで全然いけちゃいます

Obsidianのインストール手順(Windows)

ここからは実際にWindowsへ入れていきます
公式サイトからダウンロードして、インストールして、最初のVault(保管庫)を作るところまでを順番に追っていきましょう

STEP

公式サイトを開いてダウンロード

ブラウザで公式サイト(obsidian.md)を開くと、画面に「Get Obsidian for Windows」というボタンが出ています
これを押すとWindows用のインストーラ(.exe ファイル)がダウンロードされます

ダウンロードされるのは「Obsidian-(バージョン番号).exe」というファイルです
別のOSを使っている場合は「More platforms」から選べます

STEP

インストーラを実行する

ダウンロードした .exe ファイルをダブルクリックすると、インストールが始まります
特に難しい選択肢はなく、案内に従って進めればすぐ終わります

インストールが終わると自動でObsidianが立ち上がります
立ち上がらなかった場合はスタートメニューから「Obsidian」を探して起動してください

立ち上がると、下のように最初に保管庫(Vault)を選ぶ画面が表示されます
ここはこのあとのSTEPで使うので、いったんこのまま開いておいてください

STEP

Vault(保管庫)を新規作成する

さきほどの保管庫を選ぶ画面で、「保管庫を新規作成する」の側にある「作成」を選びます

すると保管庫を作る画面に変わります
「保管庫の名称」にVaultの名前を入れて、「ロケーション」の「閲覧」で保存場所(フォルダの置き場所)を決め、最後に「作成」を押せば完成です
名前は「メモ」でも「notes」でも、自分が分かれば何でも構いません

保存場所は、後でClaude Codeから開くことを考えると、エクスプローラーで辿りやすい分かりやすい場所にしておくのがおすすめです

これでObsidianの導入は完了です
Vaultという名前の空っぽのフォルダに、これからノートを貯めていく形になります

Obsidianの基本操作 最初の一歩

導入できたら、まずは1枚ノートを作ってみましょう
ここを通しておくと、このあとのClaude Code連携が「なるほど」と腑に落ちます

ノートを作ってMarkdownで書く

新しいノートを作ると、白い編集画面が出ます
あとは普通に文章を打つだけでメモになります
ここで覚えておくと便利なMarkdownの記号は、最初は次の3つだけで十分です

• 行の先頭に# を付けると見出しになります(## のように増やすと小見出し)
• 行の先頭に- を付けると箇条書きになります
• 行の先頭に- [ ] と書くと、押せるチェックボックスになります(やることリストに便利です)

記号を覚えていなくても、まずは普通の文章を書くだけで十分です
後から少しずつ覚えていけば大丈夫でして、ここで作ったノートは、Vaultフォルダの中に .md ファイルとして保存されていきます

[[ ]]でノート同士をリンクする

Obsidianらしさが出るのがここです
ノートの中で[[ノート名]]のように二重の角カッコで囲むと、そのノートへのリンクになります

たとえば「Claude」というノートを作っておいて、別のノートで [[Claude]] と書けば、クリックひとつで行き来できるようになります
こうして繋いだリンクが、さきほど紹介したグラフビューに点と線として反映されていきます

最初は1〜2本リンクを張ってみる程度で十分です
ノートが増えるほど、この「繋がり」が後から効いてきます

ObsidianをClaude Codeと繋ぐ方法

ここがこの記事の本題です
ObsidianとClaude Codeを繋ぐといっても、特別な連携設定を入れる必要はありません
いちばん壊れにくいのはVaultフォルダをそのままClaude Codeの作業フォルダにするという方法です

ジャベ雄

難しい設定はひとつもいらないんです、拍子抜けするくらい簡単ですよ

なぜ「作業フォルダにする」だけで繋がるのか

思い出してほしいのが、Vaultの正体はただのフォルダで、ノートはただの .md ファイルだったという点です
Claude Codeは、作業対象として指定したフォルダの中のファイルを読んだり書いたりできます

つまりVaultフォルダをClaude Codeの作業対象(作業フォルダ)として指定すれば、それだけで両者が同じファイルを見ることになります
Claudeが読み書きするファイルと、人がObsidianで開くノートが、パソコンの中でまったく同じものになるわけです

手順 VaultをClaude Codeの作業フォルダにする

やることは「Claude CodeにVaultフォルダを作業対象として指定する」だけです
具体的には、さきほど作ったVaultフォルダを作業フォルダにしてClaude Codeを起動します(そのフォルダを作業対象として開く、と考えてください)

あとはClaudeに、ノートに関するお願いをするだけです
たとえばこんな頼み方ができます

• 調べた内容をノートにまとめてもらう
• 長いノートを要約して別ノートに保存してもらう
• バラバラのメモを整理して見出しを付け直してもらう

Claudeが書き出したテキストは、そのままVaultの中に .md ファイルとして保存されます
Obsidianを開けば、それがちゃんとノートとして並んで見える、という流れです
AIに作らせたメモがそのまま自分の知識の棚に積み上がっていく感覚ですね

Vault直下のCLAUDE.mdは一石二鳥

もうひとつ覚えておくと得をするのがCLAUDE.mdというファイルです
これはClaude Codeに対して「このフォルダではこう振る舞ってね」と伝える指示書の役割を持つファイルでして、いまはVaultを作業フォルダにしているので、その直下に置けばClaudeが読み込みます

面白いのは、このCLAUDE.mdも中身はMarkdownのテキストファイルだという点です
つまりVaultの直下に置けば、Claudeへの指示書としても、Obsidianで開ける普通のノートとしても使えます
ひとつのファイルが二役こなしてくれるわけですね

CLAUDE.mdの書き方をもう少し知りたい方は、Claude Codeの設定ファイルガイドでまとめているので合わせてどうぞ

もっと密に繋ぎたい人向けの発展(MCPプラグイン)

「Obsidianを開いたまま、もっと密に連携させたい」という人向けに、専用のプラグインも存在します
obsidian-claude-code-mcpと呼ばれるプラグインで、Obsidianの中で連携用の小さな窓口(MCPサーバー)を立ち上げて、Claude Codeから自動で接続する設計になっています

ただし、このプラグイン方式は連携用にポートを使うぶん、環境によっては別のソフトとポートがぶつかってしまうこともあります
前述の作業フォルダ方式にはこの心配がないので、まずは作業フォルダ方式を主役にして、それで物足りなくなってからプラグインを検討する流れがおすすめです

Claude Codeのプラグインや拡張の仕組み自体に興味が出てきた方は、Claude Code拡張機構入門で全体像を紹介しているので、そちらも覗いてみてください

Obsidianはどんな人に向く？急がなくていい人

ここまで読んで「自分に合いそうか」が気になってきたと思うので、向き不向きを正直に整理しておきます
まずObsidianが特に向いているのは次のような人です

• 調べたことやアイデアを、自分のパソコンのなかにMarkdownで貯めていきたい人
• Claude Codeに作らせた下書きや要約を、流さずに受け止める「置き場」が欲しい人
• クラウド任せにせず、ノートの実体を手元のファイルとして持っておきたい人

逆に、大人数でリアルタイムに共同編集すること自体が主目的という使い方なら、最初からクラウド前提の別ツールのほうがすんなり収まることもあります
Obsidianはローカルのファイルが主役なので、この点は正直にお伝えしておきます

とはいえ、ひとりで貯めていくぶんには無料で始められて、後からSyncやGitで同期を足すこともできます
急いで決める必要はないので、まずは手元にVaultをひとつ作って、合いそうかどうかを試すところからで十分です

ObsidianとClaude Codeのよくある質問

最後に、始める前につまずきやすいところをQ&A形式でまとめておきます

まとめ まずは作業フォルダ方式で試そう

Obsidianとは何か、そしてClaude Codeとどう繋ぐかを通しで見てきました
最後にポイントを振り返っておきます

• Obsidianは、ローカルのMarkdownファイルにノートを貯めるツール、Vaultはただのフォルダ
• 本体はあらゆる用途で完全無料、性能を絞った無料版ではない(有料なのは任意のSync/Publishだけ)
• 商用も無料(「商用は有料」は2025年2月より前の古い情報)
• Claude CodeとはVaultを作業フォルダにするだけで低摩擦に繋がる、プラグインも追加設定も不要
• Vault直下のCLAUDE.mdは、Claudeへの指示書とObsidianのノートを兼ねられる

無料で始められて、性能の出し惜しみもなく、Claude Codeとも壊れにくい形で繋がるのがObsidianを勧めたい理由です
まずは作業フォルダ方式で、AIに作らせたメモが自分のノートとして貯まっていく感覚を試してみてください

ジャベ雄

迷ったら、とりあえずVaultをひとつ作って触ってみるのが早いですよ

PC仕事の時短に効く本PR

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

パソコン博士TAIKI

Amazonで見る楽天で見る

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

法林岳之ほか

Amazonで見る楽天で見る

パソコン仕事術の教科書 改訂新版

中山真敬

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

「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 にも置いています

Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

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

平川知秀

Amazonで見る楽天で見る

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

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています

最近は Claude Code を事務職や企画職の方にも配って、日々の作業を手伝ってもらう会社が増えてきましたよね

ただ、何の準備もせずにそのまま配ってしまうと、思わぬところで事故が起きやすいんです

例えば、認証情報の入ったファイルを読まれてしまったり、消したくないフォルダを巻き込んで操作されてしまったり、といった場面が考えられます

この記事では、Claude Code を一般の社員に配るときのガードレール設計を、情シスや管理者の目線で一通りまとめます、設定ファイルの中身も具体的なコード付きで紹介していきます

「会社で配る予定はないけど、個人で使っていて事故が心配」という慎重派の方にも、そのまま真似できる構成にしているので、肩の力を抜いて読んでみてください

Claude Code のセキュリティの全体像はClaude Code Desktop 初心者向けセキュリティ5選、設定ファイルそのものの整理はClaude Code 設定ファイル早見表でも扱っているので、土台から知りたい方は合わせてどうぞ

なぜ「初期設定なしで配る」と事故るのか

Claude Code は、お願いした内容に応じて自分でファイルを読み書きしたり、裏でコマンド(プログラム命令)を実行したりできます

この自走できる力が便利さの源なんですが、配り方を間違えると、同じ力がそのままリスクにもなります

とくに、コマンドや設定ファイルに慣れていない方が使う場合、こんな場面が起こりがちです

• パスワードやAPIキーの入った .env ファイルを読み込んで、その中身が会話履歴に残ってしまう
• デスクトップやドキュメントなど、消したくないフォルダの中で作業させてしまい、関係ないファイルまで巻き込む
• 「許可をバイパス」する設定をうっかり有効にして、確認なしで何でも実行できる状態になる
• 認証情報をそのまま Git にコミットして、社外に出してはいけない情報が共有リポジトリに載る

どれも「使う人が気をつければ防げる」と言えなくはないんですが、毎回・全員が気をつけ続けるのは現実的じゃないですよね

AIならではの落とし穴もある

ここまでは、普通のソフトでも起こりそうな事故の話でした、ただ、AIを使う以上は、AIならではのリスクも頭に入れておきたいところです

1つめが プロンプトインジェクション です、これは、AIに読ませた文章(PDF・メール・Webページなど)の中に、こっそり別の命令が仕込まれていて、AIがそれを指示として受け取り、変な動きをしてしまう手口です

押さえておきたいのは、AIにとって文章は「情報」であると同時に「命令」にもなりうるという点です、ここが、普通のシステムを入れるときとの大きな違いになります

2つめが 権限の渡しすぎ です、AIの回答がただ間違っているだけなら、人が気づいて止められます、でも、ファイルの削除・メール送信・外部への公開といった「実際に動く権限」まで渡していると、先ほどのプロンプトインジェクションと組み合わさったときに、そのまま実害につながってしまいます

対策の考え方はシンプルで、人と同じようにAIにも必要最小限の権限だけ渡す、そして消す・送るといった大事な操作の前には人が確認する、この2つです、このあと出てくる permissions の deny(禁止)と ask(都度確認)が、まさにこれを設定で実現する道具になります

3つめが コネクターやMCPの扱い です、Google DriveやSlackをつなぐコネクター、外部のツールとつなぐ MCP(外部連携の共通規格)は便利なんですが、つなぎ先の権限設定が雑だと、AI経由で本来見えてはいけない情報まで引き出せてしまいます

つなぐときは、読み込み(閲覧)は許可しても、書き込みは安易に許可しないというふうに、できることを分けて考えるのがおすすめです

だからこそ、使う人の注意力に頼らず、仕組み側であらかじめ守るという発想が大事になります

ハーネス(枠組み)で守るという考え方

ここで言うハーネスは、使う人を包む安全の枠組みくらいに考えてください、車のシートベルトのように、意識しなくても勝手に守ってくれる仕掛けのことです

具体的には、管理者があらかじめ設定ファイルや作業フォルダを用意しておき、使う人はその枠の中で操作する、という形を作ります

この記事で紹介するガードレールは、おおまかに次の6つです、上から順に効果が広いものになっています

1. managed-settings.json で、上書きできない管理ポリシーを配る
2. settings.json の permissions で、できる操作とできない操作を線引きする
3. セキュリティ系プラグインで、書かれたコードを自動でチェックする
4. 作業フォルダの固定で、どこでも実行できる状態を避ける
5. .gitignore の標準配布で、認証情報をうっかり共有させない
6. 初期CLAUDE.md の配布で、社内ルールを最初から読ませる

ここまでやると「ちょっと過剰かな」と感じる場面もあると思います、ただ、事故が心配な環境なら、最初は厚めに守っておいて、慣れてきたら緩めるくらいがちょうどいいんじゃないでしょうか

1. managed-settings.json で上書きできないポリシーを配る

ガードレールの土台になるのが managed-settings.json です、これは管理者が配る「上から決めた設定」で、使う人が自分の設定で上書きできないのが大きな特徴です

Intune や Jamf といった MDM(端末を一括管理する仕組み)を使って、全社員のパソコンに同じファイルを配る、という運用が想定されています

置き場所はOSごとに決まっている

managed-settings.json は、置く場所がOSごとに決まっています、2026年6月時点の公式ドキュメントだと次の通りです

同じ場所に managed-settings.d というフォルダを作って、複数の設定ファイルに分けて置くこともできます、チームごとにポリシーの断片を分担したいときに便利です

中身は通常のsettings.jsonと同じ書き方

ありがたいことに、ファイルの中身は普通の settings.json と同じ書き方で大丈夫です、管理者として「これだけは守らせたい」という最小限のポリシーから始めるのがおすすめです

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

この例だと、認証情報が入りがちなファイルの読み込みをまとめて禁止しつつ、確認なしで何でも実行する「許可をバイパス」モードも封じています、それぞれの中身はこのあとの章で順番に説明します

managed-settings.json に書いた内容は、使う人の設定では上書きできません、なので本当に外してほしくない守りだけをここに集約するのがコツです

読み込み禁止が効く範囲には条件がある

ここで、配る前に押さえておきたい条件が2つあります、どちらも公式ドキュメントに明記されているもので、知らないと「守ったつもり」になりやすいところです

1つめが どこまでのフォルダが対象になるか です、Read(.env) や Read(**/.env) のような書き方が止めるのは、起動したフォルダとその配下にある .env だけです、親フォルダや別プロジェクトの .env は対象外になります

先頭を // にすると、パソコン全体を対象にできます、全社ポリシーとして「どこに置いてある .env でも読ませない」を徹底したいなら、こちらの書き方にしてください、逆に、次の章で紹介する作業フォルダの固定とセットにする前提なら、上の相対的な書き方でも狙いどおりに働きます

2つめが 誰の読み書きを止められるか です、Read と Edit の禁止が効くのは、Claude 自身のファイル操作と、Claude が把握しているファイル系コマンド(cat・head・tail・sed など)までになります

とはいえ、これは「deny が無意味」という話ではありません、うっかり読ませてしまう事故はこれで大きく減らせますし、非エンジニアに配る前提ならスクリプトを書いて回避する場面自体が多くありません、どこまで守れているかを情シス側が正確に把握しておくための条件、と捉えてください

設定の優先順位を押さえておく

Claude Code の設定は何層かに分かれていて、ぶつかったときにどれが勝つかが決まっています、優先順位は上が強いです

大事なのは、禁止(deny)はどの層から付けても効くという点です、ある層で禁止したものは、別の層で許可しても解除されません

つまり管理者は、managed の層で禁止を盛っておけば、使う人がどんな設定をしても穴が開かない、という安心感が得られます

2. permissions で操作範囲を線引きする

次は、Claude Code が「何をしていいか」を細かく決める permissions の話です、ガードレールの中でも一番こまかく効くところです

permissions は3つのリストでできています、それぞれの役割はこんな感じです

判定の順番は deny → ask → allow です、最初に deny にあたれば、後ろで allow に書いてあっても禁止が優先されます、なので禁止したいものは deny に書くのが確実です

危険なコマンドを deny で止める

まず止めておきたいのが、影響範囲の大きいコマンドです、ファイルを一括で消すような命令や、ネットへ自由にアクセスする命令を deny に入れておきます

{
  "permissions": {
    "deny": [
      "Bash(rm *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(git push *)"
    ],
    "defaultMode": "default"
  }
}

Bash というのは、Claude が裏で実行するコマンド(プログラム命令)のことです、ここでは削除の rm、勝手なダウンロードに使われがちな curl と wget、共有リポジトリへの送信になる git push を止めています

ここで大事なのが Bash(rm *) の書き方です、コマンドの照合は前方一致なので、この形だと rm で始まるコマンドをまとめて止められます

WebFetch でアクセス先のドメインを絞る

WebFetch は、Claude がWebページを読みにいく機能です、ここを野放しにすると、どこへでも情報を取りにいけてしまうので、許可するドメインだけ絞るやり方が安心です

{
  "permissions": {
    "allow": [
      "WebFetch(domain:docs.claude.com)",
      "WebFetch(domain:github.com)"
    ],
    "deny": [
      "WebFetch"
    ]
  }
}

書き方は WebFetch(domain:許可したいドメイン) です、この例だと、ドキュメントとGitHub以外への読み込みを止めつつ、業務で必要なところだけ通せます

「許可をバイパス」モードを封じる

Claude Code には、確認をすっ飛ばして次々に実行する「許可をバイパス」モードがあります、便利ではあるんですが、慣れていない方が使うと、止める間もなく操作が進んでしまう危険があります

これを管理者側で封じるのが disableBypassPermissionsMode です、値を “disable” にすると、設定からもコマンドからもこのモードが使えなくなります

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

さらに徹底したいなら、allowManagedPermissionRulesOnly を true にすると、許可・確認・禁止のルールを管理者の設定だけに限定できます、使う人が勝手に許可を増やすのを防げます

「自動モード」を許すかどうかも情シスが決める

「許可をバイパス」と混同されやすいのが 自動モード です、たしかに別物なんですが、安全側のモードだから止めなくていい、と考えるのは正確ではありません

公式ドキュメントのモード一覧を見ると、自動モードで確認なしに実行される範囲は すべて(裏で安全チェックが走る)と書かれています、確認を挟まずに動ける範囲そのものは広いということです

その「裏の安全チェック」を担当しているのは、分類器と呼ばれる判定用のモデルです、あらかじめ決めた許可リストと突き合わせているわけではなく、依頼の内容から外れた操作・見覚えのない接続先・読み込んだ文章に誘導された気配がある操作などを、その都度モデルが判断して止めています

そのうえで、管理者として確実に言えることが1つあります、deny はどのモードでも効くという点です、なので deny に書いた操作は、自動モードでも実行されません

裏を返すと、deny に挙げていない操作は確認なしで走りうるということでもあります、だからこそ、自動モードを許す運用にするなら、deny の作り込みが前提になります

ジャベ雄

自動モードは「確認が減るモード」であって「安全なモード」ではない、と分けて覚えるのがよさそうです

止める判断をした場合は、管理者側で permissions.disableAutoMode を “disable” にすると、組織単位で自動モードを使えなくできます、書き方は「許可をバイパス」を封じるときと同じで、managed-settings.json に並べて書けます

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable"
  }
}

どちらが正解というものではなく、事務職や企画職の方に配る前提なら「自動モードも止めておく」、ある程度分かっている人が使うなら「deny を固めたうえで自動モードは許す」といった具合に、情シスが判断する対象の1つとして扱ってください

permissions まわりをもう少しじっくり知りたい方は、Claude Code 設定ファイル早見表で各ファイルの役割を確認しておくと、どこに何を書けばいいか迷わなくなります

3. セキュリティ系プラグインで自動チェックを足す

設定で操作を縛るだけでなく、書かれたコードそのものを自動でチェックする仕組みも入れておくと安心です、ここで役立つのが公式のセキュリティ系プラグインです

2026年5月に公開された security-guidance は、Claude が書いたコードに危なっかしいパターンが混じっていないかを自動で見てくれるプラグインです、たとえば外部からの入力をそのまま実行してしまう書き方などを拾ってくれます

導入は Claude Code Desktop のプラグイン画面から数クリックで済みます、無料で、どのプランでも使えて、入れたあとは自動で動いてくれるので、配る側としても手間がかからないのが嬉しいところです

security-guidance の検出パターンや、deny リストとの組み合わせ方はsecurity-guidance とは 使い方と運用のコツでくわしくまとめているので、入れる前にざっと目を通しておくと運用イメージがつかみやすいです

プラグインの配布元を管理者で固定する

プラグイン自体は便利なんですが、誰がどこから入れられるかを野放しにすると、出どころの怪しいものが混ざる心配もあります

会社で配るなら、managed-settings.json 側で「入れていいプラグインの棚」を絞っておくのがおすすめです、公式の棚だけ許可しておけば、使う人は安心して選べます

4. 作業フォルダを固定して「どこでも実行」を避ける

地味ですが効くのが、作業する場所をあらかじめ決めておくという対策です

Claude Code は、起動した場所のフォルダを起点に動きます、なので、もしデスクトップやドキュメントの直下で起動してしまうと、大事なファイルが並ぶ場所で操作が走ることになります

そこで、MDM で全社員のパソコンに 所定の作業フォルダ を自動で作っておく、という手を打ちます、たとえばこんな構成です

C:\Users\(ユーザー名)\ClaudeWork\
  ├─ .gitignore        ← 認証情報を除外するリスト
  ├─ CLAUDE.md         ← 社内ルールを書いた初期ファイル
  └─ work\             ← ここで作業する

このフォルダの中で作業してもらうように案内しておけば、関係ないファイルを巻き込むリスクをぐっと減らせます、後で出てくる .gitignore や CLAUDE.md も、最初からこの中に置いておけます

さらに、Claude が触れてよいフォルダを設定で限定したいときは、additionalDirectories という項目で、追加で使ってよい場所をリスト化できます、明示した場所以外には基本的に手を出させない、という運用も組み立てられます

5. .gitignore を標準配布して認証情報を守る

つづいて、.gitignore の標準配布です、これは認証情報のうっかり共有を防ぐための、地味だけど大事な一手です

.gitignore は、Git に「このファイルは管理しないでね(=共有リポジトリにもアップしないでね)」と伝えるためのリストです、ここに書いたファイルは、コミットの対象から外れます

パスワードやAPIキーが入る .env などをここに書いておけば、Git 経由で社外に出てしまう事故を防げます、配布する雛形はこんな内容で十分です

# 認証情報
.env
.env.*
*.pem
*.key
id_rsa
credentials.json

# ローカル設定
.claude/settings.local.json

# 一時ファイル
*.log
tmp/

ポイントは、これを全員に同じ内容で配ることです、一人ひとりに「.gitignore を書いてね」とお願いしても抜けが出ますが、雛形を配ってしまえば、最初から同じ守りが効きます

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

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

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

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

Notta｜AI自動文字起こし

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

Nottaを見てみる

6. 初期CLAUDE.mdを配って社内ルールを読ませる

最後は 初期CLAUDE.md の配布です、ここまでが仕組みで縛る守りだったのに対し、これは「Claud に最初から読ませておく社内ルール」という、もう一段やわらかい守りになります

CLAUDE.md は、Claude Code が作業前に読み込む指示書のようなファイルです、ここに会社のルールや禁止事項を書いておくと、毎回それを踏まえて動いてくれます

配布する雛形には、作業フォルダの説明・やってほしくないこと・困ったときの相談先あたりを入れておくと親切です

# 社内Claude Code 利用ルール

## 作業する場所
- 作業は ClaudeWork\work フォルダの中で行ってください
- このフォルダの外にあるファイルは、勝手に触らないでください

## やってほしくないこと
- .env や鍵ファイル(*.pem / *.key)の中身を会話に出さない
- 共有リポジトリへの送信(git push)はしない
- 設定ファイルを書き換えるときは、内容を私(利用者)に見せてから書く

## 困ったとき
- 操作に迷ったら止まって、情報システム部に相談してください
- 連絡先: jyoshi@example.com

ここで1つ気をつけたいのは、CLAUDE.md はあくまで「お願い」であって、強制力はないという点です

本当に守らせたい禁止は、これまで紹介した managed-settings.json の deny で仕組みとして縛る、CLAUDE.md は方針や心構えを伝える、という役割分担で考えると分かりやすいです

入力していい情報・ダメな情報を3段階で決める

ここまでは「操作」を縛る守りでした、もう1つ、配る前に決めておきたいのが 何を入力していいか の線引きです、これは設定ファイルではなく、社内ルールとして決めておくものになります

細かく決めすぎると運用が回らなくなるので、ざっくり3段階に分けるのがおすすめです

真ん中の「条件つきでOK」は、入力した内容がモデルの学習に使われない契約で、かつアクセス権が守られている範囲で、という前提つきです、Anthropicの公式ドキュメントによると、2026年6月時点では、Team・Enterprise・API といった法人(コマーシャル)契約では、Claude Codeに送ったコードやプロンプトを既定でモデル学習には使わない、とされています(ただし管理者が Developer Partner Program などに自分から参加した場合は、学習の対象になりえます)

それと、学習とは別の話として、やり取りの履歴は手元のパソコンにしばらく残ります(既定で30日ほど)、なので「原則NG」のパスワードや鍵は、学習に使われるかどうか以前に、最初から入力させないのが基本です

この3段階は、先ほどの 初期CLAUDE.md に書いておくと、配るだけで全員に同じ基準が共有できます

ここは設定では止められないと割り切る

1つ、はっきりさせておきたいことがあります、この線引きは 設定で縛れる話ではないという点です

前に紹介した deny の読み込み禁止が止めてくれるのは、あくまで Claude が .env などのファイルを読みにいく動きです、使う人がパスワードを会話欄に直接打ち込む行為は、deny では止まりません

なので、配る前に打ち込んでしまったときの初動まで決めておくのがおすすめです、起きる前提で手順を用意しておくと、現場が慌てずに済みます

ジャベ雄

手元の平文記録は見落としがちです、鍵を替えて会話を消して終わり、にしないところが肝心です

設定のプライバシー画面で学習と位置情報を確認する

前の章は「契約として学習に使われるかどうか」という制度の話でした、ただ、個人プラン(Free・Pro・Max)の方が実際に学習を止めたいときは、設定画面のトグルを一度確認しておくのが早いです

場所は 設定 → プライバシー です、Claude Code Desktop の設定を開いて、左メニューの プライバシー を選ぶと、データの扱いに関する項目がまとまっています

この画面の「設定」という区画に、確認しておきたいトグルが2つ並んでいます

肝になるのが AIモデルの改善にご協力ください です、ここをオンにしていると、個人プランではチャットやコーディングセッションが将来のモデル学習に使われます(Claude Code 経由のやり取りも含みます)、オフにすると、それ以降の新しいやり取りは学習に使われなくなります

同じプライバシー画面を下にスクロールすると あなたのデータ という区画もあります、ここから、これまでのデータのエクスポートや、共有したチャット・アーティファクトの管理ができます、共有したまま忘れていた履歴を見直したいときに開いてみてください

ジャベ雄

契約で守られていても、個人プランはトグル1つで扱いが変わります、配る前にこの画面をそろえておくと安心です

個人でも真似したい最小セット

ここまで会社向けの話をしてきましたが、「うちは会社じゃないし、そこまではいらないかな」という方も多いと思います

そこで、個人で使う慎重派の方が真似する価値のある最小セットを、3つに絞ってまとめておきます

• settings.json の deny に .env 系と危険コマンドを入れる:認証情報の読み込みと一括削除を止める、これだけで事故の多くが防げます
• .gitignore に認証情報を書く:Git を使うなら、.env や鍵ファイルを最初に除外しておく
• 作業フォルダを1つ決める:専用のフォルダの中だけで Claude Code を使うようにして、大事なファイルから離す

managed-settings.json や MDM 配布は会社向けの仕組みですが、個人なら自分の settings.json に同じ deny を書くだけで近い効果が得られます、管理者がいない分、自分が管理者のつもりで一度だけ設定しておく、というイメージです

設定が不安なら Claude 自身に頼む手もある

「設定ファイルを自分でいじるのは怖い」という方は、Claude 自身に書いてもらうのも手です、やりたいことを言葉で伝えれば、中身を用意してくれます

たとえば、こんな感じで頼んでみてください

このプロジェクトの settings.json を作りたいです。
次の方針でお願いします。

・.env や鍵ファイル(.pem / .key)の読み込みを deny で禁止
・rm の一括削除と git push を deny で禁止
・「許可をバイパス」モードは使えないようにする

書き込む前に、設定内容を一度わたしに見せてから保存してください。

最後の「書き込む前に見せてね」の一言がポイントです、内容を確認してから保存すれば、知らないうちに変な設定が入る心配もありません

よくある質問

まとめ

事務職や企画職の方に Claude Code を配るときは、使う人の注意力に頼らず、仕組みで守るのが基本でした

この記事で紹介したガードレールを、もう一度おさらいしておきます

• managed-settings.json:MDMで配る、上書きできない管理ポリシー
• permissions の deny:危険コマンドと認証情報の読み込みを止める
• セキュリティ系プラグイン:書かれたコードを自動でチェックする
• 作業フォルダの固定:どこでも実行できる状態を避ける
• .gitignore の標準配布:認証情報の共有を防ぐ
• 初期CLAUDE.md:社内ルールを最初から読ませる

あわせて、AIならではのリスク(プロンプトインジェクションや権限の渡しすぎ)を頭の片隅に置きつつ、入力していい情報の線引きを社内で決めておくと、守りがぐっと固くなります

それと、設定では止めきれない部分が2つありました、「自動モード」を許すかどうかの方針と、認証情報を打ち込んでしまったときの初動です、どちらも配ったあとに決めようとすると間に合わないので、配る前に情シス側で答えを出しておいてください

会社で配る予定がなくても、deny・.gitignore・作業フォルダの3つは個人でも真似する価値があります、慎重派の方ほど、最初に一度だけ仕込んでおくと、後がずっと気楽になりますよ

関連する話として、Claude Code Desktop 初心者向けセキュリティ5選では使い始めの守り方を、security-guidance とは 使い方と運用のコツではプラグインによる自動チェックをくわしく扱っています、合わせて読むと、自分の環境に合った守りを組み立てやすくなると思います

Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

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

平川知秀

Amazonで見る楽天で見る

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

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています

Anthropicから新しいモデルClaude Fable 5が出たので、さっそく1日まるまる触ってみました

世間の総括をひとことで言うと「遅い・トークンを食う・しかし有能」あたりに落ち着いていて、私の体感もだいたいそこに重なります

ただ、本家ブログでは焦点をひとつに絞りたいので、今回はトークンの減りの速さを記事の背骨にして書いていきます、性能向上そのものは正直地味なんですが、トークンが消えていくスピードはちょっと無視できないなと感じたので

結論を先に薄く置いておくと、こんな感じです

そもそもモデルやトークンってなに？という方は、先にAI用語集に目を通しておくと、この先がぐっと読みやすくなると思います

カタログスペックでOpus 4.8と比べてみる

まずは公式が出している数字から、ひとつ前のClaude Opus 4.8と並べて見てみます、ここはぜんぶ公式発表値です

表を見てまず目に入るのは、API価格がOpus 4.8のちょうど2倍になっているところです、入力$10・出力$50で、Opus 4.8の入力$5・出力$25からきっちり倍ですね

もうひとつ大きいのが思考モードのちがいです、Opus 4.8は思考をオン/オフ選べるんですが、Fable 5はadaptive thinkingという深く考える仕組みが常時オンで無効化できません、AIが内部でじっくり考えるぶん、見えないところで思考用のトークンが乗ってくる作りになっています

速度を上げるFast modeがFable 5には用意されていないのも、地味だけど効いてきます、このあたりが「速さは売りじゃない」を裏づけている感じですね

公式ベンチマークの主役はSWE-bench Pro

性能の数字も見ておきます、Anthropicが公式発表で前面に出しているのはSWE-bench Proというコーディングのベンチマークです

SWE-bench Proで80.3%、Opus 4.8の69.2%から10ポイント以上の上積みなので、数字としてはちゃんと伸びています

世の中の評価はどうなっている？

次に、私の感想に行く前に世間の声を整理しておきます、肯定も否定もはっきり出ていて、両方知っておくとバランスよく判断できると思うので

肯定的な評価

有名な解説者のSimon Willisonさんは「a beast(怪物級)、遅くて高いが、あらゆるタスクを着実に噛み砕き続ける」と評していて、知識の想起についてはOpus 4.8より上だと書いています

大規模な事例だと、Stripeが5,000万行のRubyコードベースを1日で移行したという自己申告もあります、ほかにも、過去モデルが作り込んだバグを複数見つけ出したという報告や、調査の自律性が上がった(他人のブランチまで自分でpullして原因を特定する)という体験談が出ています

共通しているのは「単なるコード生成器ではなく、開発サイクルそのものの運転手になりつつある」という見方で、長時間まかせる使い方ほど評価が高い印象です

否定的・不満の声

一方で、辛口の声もしっかりあります

技術系コミュニティでは「進化は革命的というより漸進的(incremental)」「ベンチマークへの過適合では？」という疑いの声が出ています

そして何より多いのがコストとレート上限への不満です、Willisonさんは初日のAPI利用で$110.42、ほかにも1日で$82.92という報告、$100のMaxプラン枠を約9分で使い切ったという話まで出回っています(このあたりの個人実測値は再現性が確かめられていないので、雰囲気として受け取るのが安全です)

1日触った私の体感

性能・速度・トークン消費の3つの軸で、1日触った正直なところを書いていきます

性能:上がった気はする、でも目に見えてすごいかは分からない

Webデザインや受け答えの質は、Opus 4.8より上がった気はします、ただ、目に見えてすごい向上かと言われると、正直よく分かりませんでした

たぶんこれは、私が一般的な用途でそこまで高難易度の使い方をしていないだけかもしれません、世間でも「単発のタスクだと差が見えにくい」という見方は共通していて、差が出るのは長時間の自律タスクや大規模なコードベースを扱うときみたいです

Stripeの5,000万行みたいな規模感だと真価が出るんでしょうが、日常の使い方だとそこまで実感しづらい、というのが私の体感です

速度:それなりに時間はかかる、〇倍速いみたいな体感はない

速度については、それなりに時間はかかる、という印象です、Opusと比べて速度が何倍も速いみたいな体感はありませんでした

これは私が日頃からeffort(どれだけ手間をかけて考えるかの設定)を高めにしているのも要因です、effortを上げているぶん深く考えるので、そのぶん待ち時間も伸びます

世間でも「effortをmediumにしてもOpus 4.8のxhighより倍以上かかる」という声があって、ここは私の体感と一致しています、Fable 5はadaptive thinkingが常時オンで深く考える設計なので、遅く感じるのは仕様どおりとも言えます、速くしたいならeffortを下げる、というのが公式の指針です

トークン消費:噂以上に速く減る、PROだと厳しいと思う

そして本題のトークン消費です、ここがいちばん言いたいところでした

SNSでも噂されているとおり、かなりの速さで減ります、しかも私の体感では、5〜10倍かそれ以上の勢いで減っていく感覚でした、世間でよく言われる「3〜5倍」よりも、自分のケースはもっと激しかったです

感覚としては、MAXプラン($110)でも厳しい、PROプランだとすぐ5時間の上限に達して、ほぼ使えないんじゃないかなと思います

もちろん、これも私がeffortを高めにしているのが要因のひとつなので、effortを下げれば減りは緩やかになります、ただ「思っていたより全然速い」というのが1日触っての正直な感想です

「トークンが速く減る」噂をファクトチェックする

では、なぜそんなにトークンが減るのか、「3〜5倍速く減る」という噂を分解してみます、結論から言うと、方向性は正しいけれど「モデルが勝手に食う」というより複数の要因の掛け算でそうなっています

ざっくり計算すると、重み約2倍 × トークナイザ約30%増 = 約2.6倍が構造的な下限になります、ここにhigh effortと常時オンの思考、並列ワークフローが乗ると、体感3〜5倍に届く、という内訳です

つまり「3〜5倍速く減る」は、ひとつの巨大な原因ではなく、重み × トークナイザ × effort × 思考 × 運用の合算だった、というのがファクトチェックの答えです

そして私のように、effortを高めにしてワークフローやサブエージェントも多用していると、この合算がさらに上振れします、自分の体感が3〜5倍ではなく5〜10倍に感じたのも、たぶんこの上振れぶんなんだろうなと、分解してみて腑に落ちました

たぶん、一般的な用途だと1タスクあたりの旨味が出にくくて、1トークンあたりのコスト感だけがダイレクトに来てしまう、これが私の「割に合わない感」やSNSの不満の正体なんだと思います、Claude固有の用語をもう少し押さえたい方はClaude用語集もあわせてどうぞ

まとめ:日常はOpus 4.8、長期・大規模はFable 5

1日触ってみての私なりの結論は、使い分けがいちばん現実的、というところに落ち着きました

• 日常の軽い作業や単発のタスクは、半額のOpus 4.8で十分
• 長期・複雑・大規模なコードをまるごとまかせるならFable 5の出番
• トークンを節約したいなら、effortを下げる・Sonnetを併用する

Fable 5が有能なのは間違いないんですが、その有能さを引き出せるのは長時間まかせる大きな仕事のときで、日常使いだとコストの重さばかりが目立ちやすい、というのが正直な体感でした

新しいモデルが出るたびにワクワクしますが、Fable 5は「とりあえず一番新しいから使う」よりも、自分の用途に合うかを見極めてから取り入れる方が幸せになれそうだなと感じた1日でした

Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

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

平川知秀

Amazonで見る楽天で見る

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

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています

noteに記事を書くとき、見出しを付けて、段落を整えて、画像を貼って…という手作業、地味に時間が掛かりますよね

そのあたりをまるっと任せたくて、note自動投稿ツールnote Posterを作ってみました

Windowsで動く無料ツールで、しかも大半はClaude(AIアシスタント)に話しかけるだけで操作できます、「note 自動投稿」と聞くと身構えるかもしれませんが、note Posterが作るのは下書きまでです

この記事では、何ができて、どんな感じで使えるのかを広く浅く紹介していきます、詳しい導入手順やダウンロードは、別途用意したアプリ庫ページにまとめてあるので、最後にそちらへ案内しますね

note Posterを作ったきっかけ

きっかけは、ふだんの記事づくりの流れでした、Claudeに頼めば、情報を集めて記事のタタキ(下書きのたたき台)を作るところまでは、わりとすぐに用意できます

そこまでできるなら、最後のnoteへの下書き入稿までAIに任せた方が効率的じゃないか？と思うわけです、ところがClaudeに「noteに投稿して」とそのまま頼んでも、これがなかなかうまくいきません

noteのエディタはAIが直接ポチポチ操作できる作りではないので、あいだをつなぐ道具が要る、というわけでClaudeからの指示でnoteの下書きを組み立てる係として作ったのがnote Posterです

ちなみにAIでサクッとアプリを作る感覚は、以前AIでアプリ開発に挑戦した体験記でも書いているので、興味があればそちらもどうぞ

note Posterでできること

ざっくり言うと、note PosterはWindows上でnoteへの下書き作成を自動化するツールです

裏でChrome(ブラウザ)を動かして、noteのエディタに原稿を流し込む仕組みになっています、できることをまとめると、こんな感じです

• noteの記事の下書きを自動で組み立てる
• 見出し・段落・箇条書き・引用・コード・画像まで流し込める
• 有料エリアの区切り(ここから有料、という境界)も指定できる
• Claudeと組み合わせれば、会話だけで原稿づくりから下書き化まで頼める

note記事でよく使う要素は一通りカバーしているので、簡単なテキスト記事から画像入りの記事まで、わりと幅広く下書きにできます

Claudeから会話で使えるのが肝

note Posterのいちばんの推しポイントは、ここだと思っています

zipの中にはClaude向けの説明ファイル(CLAUDE.md)が同梱されていて、これがClaudeにnote Posterの使い方を教えてくれます、なので利用者は細かい操作を覚えなくても、Claudeに普通の言葉で頼むだけで大丈夫です

たとえば、こんな頼み方ができます

原稿のテーマだけ伝えれば、Claudeが本文を書いて、そのままnote Posterを呼び出してnoteの下書きにしてくれる、という流れですね

note Posterが用意するのは、本文と、頼めば「ここから有料」という区切りまでです、ハッシュタグや価格、公開するかどうかは、下書きができてからnoteの画面で自分で決めます

Claudeでの操作にあたってはClaude Codeを使います、Claude Code自体に不慣れな方は、Claudeの使い方を初心者向けにまとめた記事から雰囲気をつかんでおくと入りやすいと思います

基本はClaudeとセットで使うツール

ひとつ正直に書いておくと、note PosterはClaudeとセットで使うことを前提にしたツールです、単体でも動かせますが、その場合は自分でnoteに書いた方がたぶん早いと思います

一応、Claudeを使わない手動の方法もあります、テンプレートのarticle.jsonにタイトルや本文の要素を書き込んで、run.batをダブルクリックすれば下書きが組み上がります、書き方のサンプルはsamplesフォルダに入っています

ただ、JSONを手で書くくらいなら、Claudeに「こんな記事をnoteの下書きにして」と頼んでしまった方がずっとラクです、なのでこのツールは、本文づくりをClaudeに任せる使い方でこそ力を発揮します

使い方ダイジェスト

導入の流れも、ざっくりだけ触れておきます、細かい画面つきの手順はアプリ庫ページにまとめてあるので、ここでは全体像だけ眺めてもらえればと思います

動作に必要なのは、Windows 11・Google Chrome・noteアカウント・ネット接続、そしてClaudeから使うならClaude Codeです、特別な開発環境は要りません

公開の考え方と注意したいこと

最後に、使うときの心構えのような話を少しだけ

先にも書いたとおり、note Posterが作るのは下書きまでです、プレビューで中身を確かめてから、公開ボタンは自分の手で押す、という使い方を想定しています

それと、noteの規約まわりも軽く触れておくと、自動で下書きを作ること自体がはっきり禁止されているわけではありません、ただ、過度な投稿はやめておくのが無難だと思います

1日にたくさん投稿しすぎない、といった「ほどほど」を意識して、気持ちよく使えるといいですね

まとめ 詳しい手順とダウンロードはこちら

note Posterは、noteの下書き作成を自動化する無料ツールです、Claudeから会話で頼めるのが便利で、見出しや画像入りの記事も下書きまで一気に組めます

この記事では広く浅く紹介してきましたが、認証キーの発行・ダウンロード・画面つきの導入手順・よくある質問は、アプリ庫の専用ページにまとめてあります、実際に試してみたい方は、そちらから始めてみてください

PC仕事の時短に効く本PR

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

パソコン博士TAIKI

Amazonで見る楽天で見る

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

法林岳之ほか

Amazonで見る楽天で見る

パソコン仕事術の教科書 改訂新版

中山真敬

Amazonで見る楽天で見る

私のおすすめからランダムで3冊を表示しています

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 との付き合い方がぐっと安心側に寄ります

Claude・生成AIを学べる本PR

実践Claude Code入門

西見公宏・吉田真吾・大嶋勇樹

Amazonで見る楽天で見る

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

平川知秀

Amazonで見る楽天で見る

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

大澤文孝

Amazonで見る

私のおすすめからランダムで3冊を表示しています