MCP

概要 本ガイドは、個人 Obsidian Vault を Claude Code に統合し、AI Agent が個人ナレッジを 読み取り・書き戻し の両方向で活用する循環構造を実装する手順をまとめる。シリーズ 5 記事の実装ステップを 5 段階のロードマップに整理した、再現用ピラー（土台）ガイド。 5 段階ロードマップ ステップ 1: Vault の機密性に対応した接続方式を選ぶ 方式 接続スコープ 特徴 A. グローバル MCP -s user 全プロジェクト共通。個人プロジェクト中心の人向け B. プロジェクト local MCP -s local（デフォルト） .claude/settings.local.json に gitignored で書く。機密プロジェクトに向く C. symlink .claude/knowledge/ Vault サブセットを安定パスで取り込む。CLAUDE.md からの参照を一貫させる 推奨: 方式 B + C のハイブリッド。symlink で安定パスを提供し、検索・走査は MCP を使う。 1 2 3 4 5 6 mkdir -p <proj>/.claude/knowledge ln -s ~/Documents/ObsidianVault/topics/nextjs <proj>/.claude/knowledge/nextjs echo ".claude/knowledge/" >> .gitignore claude mcp add -s local vault-readonly -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault ステップ 2: CLAUDE.md と Skills を階層別に配置 ~/.claude/CLAUDE.md: 全プロジェクト共通の Vault 参照ルール <proj>/CLAUDE.md: プロジェクト固有の参照ポイント（「個人 Vault がない人でも壊れない逃げ道」を明示する） ~/.claude/skills/: Vault 横断スキル（vault-search, vault-daily-log, summary-back-to-vault） <proj>/.claude/skills/: プロジェクト固有のワークフロー（decision-log など） ステップ 3: 書き戻し（writeback）の安全設計 書き込み用 MCP を読み取り用と分離し、inbox/ にしか書けない よう物理隔離する。 ...

Obsidian Vault を Claude Code に繋ぐ実践編 では、読み取り側（Vault → プロジェクト）の設定パターンを整理しました。本記事はその続編で、書き戻し（writeback）側（プロジェクト → Vault）の設計を扱います。 ここを設計しないと、Vault は「過去の自分が書いたノート集」のまま古びていきます。プロジェクトで詰まったこと・学んだこと・設計判断の根拠が Vault に還流して初めて、AI Agent が「3 ヶ月前のあの話、応用できないか？」を提案できるようになります。 書き戻し設計で外せない3つの原則 具体的なパターンに入る前に、絶対に外せないルールを確認します。 AI に Vault の正本（topics/ や projects/ の本文）を直接書かせない Obsidian の [[リンク]] 構造とノート間の整合は、人間が編集してきた歴史の積み重ねです。AI に直接書かせると、リンク切れ・重複ノート・タグ揺れが一気に発生します。 inbox/ を必ず噛ませる AI は ~/Documents/ObsidianVault/inbox/ にしか書かない。inbox/ は「下書き置き場」と割り切り、人間が後で内容を吟味して Vault 本体に統合します。 書き戻す対象は「リポジトリに収まらない知見」だけ コードや設計書はリポジトリの docs/ に書きます。Vault に書くのは、プロジェクトを跨いで再利用される可能性のあるメタ知識 だけです。 つまり「AI が inbox/ に下書きを溜める → 人間が週次レビューで Vault 本体に統合する」という二段階フローを基本形にします。AI は下書き工場、人間は編集長、という分業です。 permissions と MCP の分離設計 書き戻しを安全に行う最大のコツは、読み取り用 MCP と書き込み用 MCP を別サーバとして分離する ことです。前作で触れた permissions 設計 を一段深めます。 1 2 3 4 5 6 7 # 読み取り専用ルート: Vault 全体を grep / Read できるが書き込みは禁止したい claude mcp add -s local vault-readonly -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault # 書き込み用: inbox/ 限定で AI が書ける claude mcp add -s local vault-inbox -- \ npx -y @modelcontextprotocol/server-filesystem ~/Documents/ObsidianVault/inbox これに加えて、<proj>/.claude/settings.json 側で symlink 越しの書き込みを禁止しておきます（前作で作った <proj>/.claude/knowledge/ — Vault のサブセットを symlink した読み取り専用ディレクトリ — を経由する書き込みを塞ぐ目的）。 ...

開発者にとって、GitHubは事実上の「最強のナレッジベース」になりつつあります。Issue・PR・Wiki・Markdown ドキュメント — 仕事に必要な情報のほとんどがリポジトリの中で完結しており、コードの近くにドキュメントを置く「Docs as Code」のスタイルは、エンジニアリングとして極めて洗練されています。 それでも 2026 年に入ってから、「AI Agent + Obsidian」の組み合わせが開発者コミュニティでホットになり続けています。GitHub で完結しているなら無理に Obsidian を入れる必要はないはずなのに、なぜこれほど話題になるのか。本記事ではその違いを、特に AI Agent に渡せる「文脈の質」 という観点から整理します。 結論を先に書くと、すべてが構造化された「プロジェクト」単位で完結していて、現状の運用にストレスがないのであれば、無理に Obsidian を導入する必要はありません。ただし、「プロジェクトを跨いだ伏線回収」を AI にやらせたい瞬間が来ると、思想の違いが効いてきます。 GitHub方式とObsidian方式の決定的な違い 最大の違いは、情報の「繋がり方」の思想です。 比較軸 GitHub方式（プロジェクト管理型） Obsidian方式（ネットワーク型） 情報の構造 ディレクトリ構造（階層型・縦割り） グラフ構造（網の目型・横断的） 主な単位 リポジトリ / Issue / PR / Wiki ノート（アイディア、ファクト、ログなど） AIとの相性 コンテキストがプロジェクト内に閉じる プロジェクト間を跨いだ「点と点の結合」が得意 向いている情報 目的・ゴール・成果物が明確なもの 抽象的なアイディア、長期的な知見、個人の備忘録 検索の単位 リポジトリ単位の全文検索 Vault 全体のリンク・タグ・全文検索 GitHub は「プロジェクトという箱」に閉じることで一貫性と版管理を担保します。Obsidian は「ノート」というアトミックな単位を Vault 全体にフラットに置き、[[リンク]] で網の目を作ることで横断性を担保します。どちらが優れているという話ではなく、扱う情報の性質によって適切な箱が違うだけです。 「プロジェクトの壁」を越える横断性 GitHub はリポジトリごとに境界線がはっきり分かれています。これは「コードと文脈をセットで版管理する」目的にはとても合っていますが、知識の再利用にはコストがかかります。 GitHub の場合: プロジェクト A で得た「Next.js の認証に関する知見」は、リポジトリ A の docs/ か Wiki か Issue 内コメントに残ります。プロジェクト B を始めたときにそれを再利用するには、「どこに書いたか」を思い出して検索しに行く必要があります。複数リポジトリを横串で検索したい場合は gh search code などに頼ることになります。 Obsidian の場合: 「Next.js の認証」という独立したノートを作っておき、プロジェクト A からも B からもリンクを貼ります。情報がプロジェクトに属するのではなく、知見そのものが独立して進化していく点が決定的に違います。 つまり、GitHub は「プロジェクトに紐づく情報」を蓄積するのに最適で、Obsidian は「プロジェクトから独立した知見」を蓄積するのに最適だ、と整理できます。 ...

GitHubで全部完結する開発者にObsidianは本当に必要か？ では、Obsidian を併用する場合の「思想差」と「AI Agent に渡せる文脈の質」を整理しました。本記事はその実践編です。特定のプロジェクトで Claude Code セッションを行うときに、個人の Obsidian Vault を併用してエージェントに処理させるには、CLAUDE.md / Skills / Settings をどう階層管理すべきか を具体的な設定例で示します。 ポイントは次の3つです。 Claude Code の設定階層（global / project / local）を理解して役割分担する Vault は gitignored 層 で繋ぐ（リポジトリにパスを残さない） CLAUDE.md には安定パスを書く — Vault の生パスを書かない（symlink 経由で参照） Claude Code の3層構造を整理する まず大前提として、Claude Code の設定は 3 層あり、それぞれ用途が違います。 階層 主なファイル Git 管理 使いどころ Global (user) ~/.claude/CLAUDE.md / ~/.claude/skills/ / ~/.claude/settings.json 個人の dotfiles で管理（任意） 全プロジェクト共通の個人スタイル・横断スキル Project <proj>/CLAUDE.md / <proj>/.claude/skills/ / <proj>/.claude/settings.json / <proj>/.mcp.json リポジトリにコミット プロジェクト固有の規約・公開してよい設定 Local <proj>/.claude/settings.local.json .gitignore で除外 Vault パスなど個人秘匿情報を置く claude mcp add の --scope（-s）オプションも、これと同じ 3 値を取ります（local / user / project）。重要なのはデフォルトの挙動です。 ...

Claude Platform on AWS の GA を Amazon Bedrock との比較で整理。ネイティブ API フル機能と AWS IAM・請求の両立がもたらす意味を解説。

2026 年 3 月、Anthropic は Claude Code の思考深度（thinking effort）のデフォルト値を high から medium に静かに変更した。 リリースノートには目立つ記述がなく、多くの開発者は「最近 Claude の質が落ちた気がする」と感じながら原因を見つけられずにいた。 Claude Code の開発者である Boris Cherny 氏が Hacker News でこの変更を認め、その後 AI 開発者コミュニティで 15 の重要設定がまとめられて話題になった。 本記事ではそれらを日本語で解説する。 1. 思考深度（effort level）の復元 問題： 2026 年 3 月以降、デフォルトが medium に変更された。Claude の思考回数が減り、コードの質・ツール呼び出し数・コメントの充実度すべてが低下している。 修正方法： セッション内で一時的に変更する場合は /effort high、恒久的に変更する場合はシェル設定に追記する。 1 export CLAUDE_CODE_EFFORT_LEVEL=high 本格的なコーディング作業では high または max を設定することで、2026 年 2 月以前の品質に戻せる。 2. Adaptive thinking の無効化 問題： 2026 年 2 月以降、Claude はタスクの複雑さを自己判断して推論量を動的に調整するようになった。「簡単なタスク」と判断した場合はほぼ思考せず、バグを見逃すことがある。 ...

HubSpot は API 認証の選択肢が多く、「結局どれを使えばいいのか」が混乱しがちです。特に Claude Code から HubSpot を操作したい場合、現在は 6 種類の認証手段が併存しています: 非公開アプリ（Private App） 旧 API キー（廃止済み） MCP 認証アプリ（HubSpot 公式 MCP Server） パーソナルアクセスキー（Personal Access Key） 開発者 API キー（Developer API Key） サービスキー（Service Key、新規 Beta） この記事では、それぞれの違い・推奨用途・Claude Code から使う場合の選び方を整理します。なお旧 API Key は廃止済みですが、参考情報として記事末尾で触れます（実質的な選択肢は 6 つです）。 結論を先に言うと: 用途で 2 軸に分かれます。 アドホックに自然言語で操作したい（営業・マーケが Claude Code から HubSpot を触る等） → 公式 MCP サーバー 本番運用・バッチ・Webhook など継続的なシステム統合 → REST API 直叩き + Service Key（新規）/ Private App（既存） 両者は競合ではなく補完関係で、実務では併用するのが現実解です。 早見表 認証方式 用途 スコープ トークン寿命 状態 Claude Code から使うなら HubSpot MCP Server（公式） AI エージェントから HubSpot 操作 アプリと同等 OAuth ベース ✅ 2025-2026 リリース ✅ 最も推奨（1 行で接続） Service Key（新） システム間データ連携 アカウント単位の細かい権限 永続 ✅ 2026-02-10 Public Beta ✅ Private App の後継、新規ならこれ Private App 単一アカウント向け統合 アプリ単位で細かく設定 永続 ⚠️ 維持されているが、新規は Service Key 推奨 ✅ シンプルな REST 呼び出し OAuth 2.0（Public App） Marketplace アプリ・複数アカウント scope ベース access 30 分・refresh で更新 ✅ 公式・現役（v3 が新版） △ 自前で OAuth フロー実装が必要 Personal Access Key（PAK） HubSpot CLI 認証 アカウントごと 永続（rotate 可能） ✅ 現役 △ CLI 経由の操作のみ Developer API Key Developer Account 内のアプリ管理 開発者アカウント全体 永続 ✅ 現役 △ アプリ管理用、CRM データには不向き 旧 API Key（参考） 単純な API 呼び出し アカウント全体 永続 ❌ 2022-11-30 廃止 ❌ 使えない 各認証方式の詳細 ① 旧 API Key（廃止済み、参考情報） HubSpot ポータルの「Integrations → API Key」から発行できたアカウント単位の単一キー。 ...

個人開発アプリの認証は「絶対に」WorkOS を使え — MCP 化で知った最強の選択肢 では、WorkOS AuthKit の Dynamic Client Registration（DCR）対応が MCP 認証の決め手になる、という話を書いた。 MCP × OAuth 2.1 の全体像は MCP のセキュリティが OAuth 2.1 で大幅進化 で扱った。本記事はその中で SHOULD/MAY 扱いされている DCR を仕様レベルで深掘りする補足記事だ。 具体的には、DCR を定義する RFC 7591 そのものの仕様と、MCP 認証で必ず連動する周辺 RFC 群（9728 / 8414 / 9068 / 8707 / 7636）の関係 を、Claude Code の自動ログインフローを追いながら整理する。 この記事でわかること: なぜ事前登録なしにクライアントが認可サーバーに繋がってくるのか（RFC 7591 / 9728 / 8414 の連動） Claude Code の自動ログインフローを HTTP リクエスト単位で何が起きているか なぜ JWT の audience 検証で詰まるのか（RFC 9068 / 8707 と DCR の構造的な相性問題） なぜ MCP では Dynamic Client Registration（DCR）が必要なのか 従来の OAuth 2.0（RFC 6749）は、クライアント（アプリ）を事前に手動登録する 前提だった。Google や GitHub の OAuth を使うときに、開発者が「アプリを登録 → client_id と client_secret を発行 → コードに埋め込み」という流れだ。 ...

Anthropic のエンジニアとされる人物が Claude Code を使って Polymarket（予測市場プラットフォーム）向けの取引 bot を構築し、$200（約3万円）を $14,300（約200万円）に成長させたという事例が話題を集めている。ただし本人の公的な確認は取れておらず、複数の紹介ツイートも「伝えられるところによると」という留保を付けている点は注意が必要だ。 単純に取引回数を増やすのではなく、「勝てる場面だけを選ぶ」判断を AI に委ねるという設計思想が注目ポイントだ。 Polymarket とは Polymarket は分散型の予測市場プラットフォームで、政治・経済・スポーツなど様々なイベントの結果に対してポジションを取れる。各イベントの結果確率を市場参加者が売買することで価格が形成される仕組みになっている。 bot のアーキテクチャ このシステムは Claude Code をベースに、以下の3つの機能を組み合わせて動作する。 1. 大規模な取引データ分析 8,600万件の取引データを AI で分析 過去のパターンから「どういう取引が利益を出しやすいか」を学習 2. ウォレットランキング Polymarket の 14,000 以上のウォレットを数分でスキャン 各ウォレットの勝率・利益率を算出し、ランキング化 高勝率ウォレット（クジラ）が動いたタイミングを検出する 3. 厳選した取引実行 1日あたりわずか 10 回のみ取引を実行 勝率の高いクジラが動いた相乗りポジション、かつクジラより早く Exit（手仕舞い） 高確率の取引だけに絞ることでドローダウンを最小化 設計思想：「勝てる場面だけ選ぶ」 このシステムが興味深いのは、取引頻度ではなく取引品質を最大化している点だ。 多くのアルゴリズムトレードは「できるだけ多くの機会を捉える」方向に走りがちだが、このボットは逆の方針を選んでいる。 力技で数をこなす → 採用しない 「勝てる場面だけ選ぶ」判断を AI に任せる → 採用 1日10回という制約は、シグナルの質を落とさないための意図的な設計といえる。 Claude Code + Skills + MCP の連携 このような bot を実際に構築するには、Claude Code 単体ではなく、Skills や MCP（Model Context Protocol） を組み合わせた拡張が必要になる。Claude Code だけでは外部 API への接続や大規模データパイプラインを扱いきれないためだ。 ...

中国在住のあるユーザーが、Claude Code を「従業員」として使い、数十の Instagram アカウントを 24 時間体制で自動管理することで月 3 万ドル超を稼いでいるという事例が SNS で注目を集めている。AI を使った収益化が「すでにゲームのルール」になりつつある現状を、この事例から読み解く。 Claude Code による Instagram 自動管理で月 3 万ドル超 AI インフルエンス・オペレーターを名乗る @Jouhatsu_ai が X（旧 Twitter）で紹介したこの事例では、Claude Code が以下の作業を自律的にこなしている。 数十の Instagram アカウントを 24 時間運用: 投稿スケジュール管理、コンテンツ生成、エンゲージメント対応 トレンドリサーチを常時実施: バズっている数百のアカウントを継続的にモニタリングし、流行を把握 退屈な反復作業を全自動化: ユーザー本人は実務から解放され、戦略立案やチェックに集中できる 本人は「AI にすべての面倒な作業を任せ、自分は一日中のんびりできる」と話しており、Claude Code が文字通り自律エージェントとして機能している様子が伝わる。 英語圏では月 1.5 万〜4.2 万ドルの受託案件も @Jouhatsu_ai の引用ツイートによれば、英語圏の Claude Code ヘビーユーザーはこうした AI 自動化システムを構築・運用することで、クライアントから 月 1 万 5,500〜4 万 2,000 ドル を請求しているという。 さらに「Anthropic がこのやり方を 30 分の公式コンテンツでほぼすべて説明している」とも言及しており、公式ドキュメントや事例を参照すれば再現性のある手法として学べることを示唆している。 Claude Code が自律エージェントとして機能する理由 Claude Code がこうした自動化ビジネスに適している背景には、いくつかの技術的特性がある。 長期タスクの継続実行 Claude Code はコマンドラインから起動し、ファイル操作・Web 検索・API 呼び出しなどを連続して実行できる。単発の質問応答に留まらず、複数ステップにわたる業務フローを自律的にこなす。 ...