見出し画像

第1章【開発記】：インフラエンジニアが「Claude Code」という言葉に惹かれてAIエージェント基盤を作り始めた話

相沢アイ

■ はじめに

「MCPサーバーを自作するだけ」なら、5分あれば作れます。

実際「5分でMCPサーバーを自作してみた」という記事や動画はすでに数多くあります。これらは、フロントエンドやアプリ開発の視点で書かれたものが多く、動かすことに主眼が置かれます。「これをコピペしてください」と淡々と進み、最後に「よく分からないけど動いた」という状態でゴールします。

その状態で「自作した」と胸を張れるでしょうか。
「これって何？」と聞かれて答えられますか？
「何でPythonで書いたの？」と聞かれて答えられますか？

このシリーズは、そこに全部答えられる状態を目指します。

なぜそのツールを選ぶのか、その設定は環境が変わっても再現するのか、失敗した時に追えるのか。動いただけで満足せず、運用に乗せられる状態かを毎回問い直します。フロントエンド目線ではサラッと流してしまいがちな所を、運用経験サイドから、理由とともに一つずつ押さえていく。それがこのシリーズの進め方です。

■このシリーズのゴール

「MCPサーバを自作すること」だけではありません。AIエージェントの実行基盤を一通り組み上げることです。Claude Desktopから自作のMCPサーバーを呼び、その実行ログをデータベースに残し、履歴を画面で見返せるところを目指します。Claude Codeでの指示の出し方や、実際のコード修正まで見せます。

しかし、本体はそこではなく、最終的に目指すのは「動いた」で終わらせず「なぜこう作ったか」を自分の言葉で説明でき、自分の環境に合わせて応用できる状態をゴールとします。

だから丁寧に進めます。全く何も知らない人がつまずかないよう、１つずつ理由を添えて進めます。その分、多少長くなります。5分では終わりません。

※「Claude Code」を使うには、有料プランへの加入が必要です。Claude Codeより手前の段階、つまり「MCPサーバーの自作」までであれば、有料プランがなくても完成させられます。

■ 今回やること

第1章ではコードを書くことや、画面を開くことはしません。
この章で扱うのは、これから実際に動かすツールと、その比較対象になるツールについて、それぞれの役割と、なぜそのツールを選ぶのかの概要です。

■ 今回出てくるツールと役割

第1章では名前だけ並べておきます。 詳しい説明や比較はシリーズの該当する章でそれぞれ扱います。 ここでは「あ、これ自分も気になっていた」という言葉に、ひとつでも引っかかってもらえれば十分です。

①Claude Desktop：PCにインストールして使うClaudeのデスクトップアプリ。MCPを試す入口になっている。
②Claude Code：ターミナルから使うコード作業向けのAIエージェント。SNSで見かけて「面白そうだ」と思った、そもそものきっかけの言葉。

【エディタ／開発環境】
①VSCode：コードを書くための定番エディタ。AI機能は拡張機能で足す形が中心。
②Cursor：VSCode系の作りに、AI機能を強く統合したエディタ。
③Windsurf：Cursorと並んで名前が挙がる、AI統合型のエディタ。

【MCPの中核概念】
①MCPサーバー：AIから呼び出される側のプロセス。自分の業務に合わせて書ける「ツール置き場」。
②ローカルMCP：自分のPCの中だけで動くMCPサーバー。最初に作るのはこの形。
③Remote MCP：クラウド上で動かして、複数の場所から呼び出せるMCPサーバー。発展形として後の章で扱う。

【プログラミング言語／データ形式】
①Python：最初にMCPサーバーを書く言語。シェルスクリプトの延長として読みやすい。
②JSON：設定ファイルやMCP通信で使われるデータ形式。コメントが書けない素のJSONと、書けるJSONCがある。
③TypeScript：JavaScriptに型を足した言語。Next.js側で使う場面が出てくる。

【JavaScript系のランタイム】
①Node.js：JavaScriptをPC上で動かす定番のランタイム。npmで多くのツールが配られている。
②Bun：Node.jsと互換性を持ちつつ、起動が早い新しめのランタイム。
③Deno：TypeScriptを直接動かせる、Node.jsとは別系統のランタイム。

【Webフレームワーク／画面化】
①Next.js：Reactをベースにしたフルスタック寄りのフレームワーク。実行履歴ビューアの土台にする。
②React：画面を部品（コンポーネント）の組み合わせで作るためのライブラリ。Next.jsの中で使われる。
③Hono：軽量なWebフレームワーク。Cloudflare Workers上で動かすときの選択肢になる。
④FastAPI：PythonでWeb APIを書くためのフレームワーク。Pythonで管理画面寄りのものを作るときの候補。
⑤Streamlit：Pythonだけで画面付きアプリを素早く作れる仕組み。データ可視化や社内ツール向け。

【データの保存／検索】
①SQLite：1ファイルで完結する軽量なRDB。MCPツールの実行ログ保存にちょうどよい。
②PostgreSQL：本格運用向きのRDB。複数ユーザーや外部公開を考えるとき有力。
③gvector：PostgreSQLにベクトル検索を足すための拡張。
④RAG：外部ドキュメントを検索しながらAIに答えさせる仕組み。pgvectorなどと組み合わせて使う。

【他サービスとの連携（参考）】
①Notion：ドキュメントやデータベースをまとめて扱うサービス。MCPサーバーから連携する例としてよく名前が挙がる。

【実行環境／デプロイ先】
①Docker：アプリを箱詰めにして動かすためのツール。MCPサーバーを配るときの選択肢になる。
②Vercel：Next.jsの開発元が運営するデプロイサービス。ローカルから公開に進むときに登場。
③Fly.io：サーバー寄りのアプリを世界中に配るためのサービス。

【Cloudflareスタック（発展形）】
①Cloudflare Workers：Cloudflareのエッジでコードを動かすサーバーレス基盤。Remote MCPのホスト先候補。
②Cloudflare Durable Objects：Workers上で状態を持たせるための仕組み。
③Cloudflare Agents：AIエージェントを動かすためのCloudflare側の枠組み。
④Cloudflare Agents SDK：Cloudflare Agentsを書くためのSDK。 ⑤Cloudflare MCP Agent：CloudflareのインフラでMCPサーバーをエージェントとして動かす形。

【認証】
①Auth.js：Next.jsなどで認証機能を組み込むためのライブラリ。Remote公開に進むときに必要になる。

ここでは、各ツールの関係性まで分からなくても問題ありません。 名前と役割をぼんやり対応づけられれば十分です。

■ 比較：今回の選択肢

「AIを業務に組み込む」やり方には、いくつかの段階があります。 今回は3つに整理します。

①対話型AIをそのまま使う（今までの自分）：
ChatGPTやClaudeをブラウザから使い、文章作成や構成出しに活用する。

②既存のAIツールやプラグインを組み合わせる：
公開されているMCPサーバーや拡張機能を設定して、AIの能力を広げる。

③自分でAIから呼び出せる仕組みを書く：
MCPサーバーを自作し、自分の業務に合わせたツールをAIから使えるようにする。

3つの選択肢を、項目ごとに並べたものが以下です。

①【対話型AIをそのまま使う】
プロンプトで記事を書いたり資料作成や画像作成に使う、皆さんが普段使用しているClaudeのこと。学習コストが低いが成果が早い。ただ、業務固有の処理には届きにくい。普段使い用。

②【既存ツールを組み合わせる】
設定で機能を増やす。 便利になるが中身がブラックボックスになるので今回は見送り。ただし設定ファイルを読む力が活きるため、必要に応じて採用する。

③【自分で仕組みを書く】
AIから呼ばれる側を作る。 学習範囲が広いが業務に最適化できるため、これを最終目標にする。 このシリーズの本筋。

ここで大事なのは、「どれが優れているか」ではないという点です。 今までやってきた「対話型AIをそのまま使う」も立派な活用です。 ただし、ここから一段階進めたいというのが今回の出発点です。

■ なぜ今回はそのツールを選ぶのか

今回は「自分で仕組みを書く」を選びます。 理由は、私の目的が「ChatGPTを業務で活用してきたつもりの自分が、もっと深くAIを使いこなす側に進むこと」だからです。

ここまで私は、ChatGPTをSNS投稿、note記事、Kindle本の構成出しなどで使ってきました。 これだけでも十分に活用してきた「つもり」です。 そんな中SNSで「Claude Code」という言葉を見かけて、シンプルに「これは何だろう、なんだかカッコいい」と思ったのが出発点でした。

調べていくうちに「MCPサーバー」という言葉に出会いました。 これがAIと外部のファイルやツールをつなぐ仕組みだと知ったとき、頭の中で点と点がつながった感覚がありました。 インフラエンジニアとしてファイル、コマンド、ログを日常的に扱ってきた自分にとって、「AIから自分の作業環境にアクセスさせる仕組み」というのは、まさに自分の得意な領域で考えられる話だったからです。

「③自分で仕組みを書く」を選んだ理由は3つあります。

１つ目は、自分の業務に合わせて仕組みを作れるという点です。 ChatGPTやClaudeをそのまま使うのも便利ですが、自分の業務固有のファイル、ログ、コマンドにそのまま繋がる訳ではありません。 自分の業務にAIを当てに行くには、その間をつなぐ仕組みが要ります。 MCPサーバーは、その「間」を自分で書ける仕組みです。

２つ目は、インフラエンジニアの感覚がそのまま使えるという点です。 プロセス、標準入出力、JSON、ログ、設定ファイル。 MCPサーバーの中身は、突き詰めるとこの組み合わせでできています。 学生時代のC++やJavaで学んだプロセスの概念、実務で書いてきたPowerShellやUNIX/Linuxシェルスクリプトの呼び出し感覚、SQLでのデータ操作。 これらがAIから呼ばれる側を書くときの土台になります。

３つ目は、純粋に面白そうだという点です。 SNSで見かけた「Claude Code」という一言が、調べるほど自分のスキルとつながる話に行き着きました。 学生時代に習った言語と、実務で書いてきたスクリプトの先に、AIから呼ばれるツール群が並ぶ。 この景色を実際に触ってみたいというのが正直なところです。

「対話型AIをそのまま使う」のはこれからも続けます。 ChatGPTで原稿のたたき台を作る作業は引き続き有効です。 そのうえで、その下のレイヤー、つまりAIと外部をつなぐ部分を自分の手で組んでいきます。 最初に動かす場所がClaude Desktop、最初に書く言語がPython、最終的に画面化するのがNext.jsという構成です。

■ 実際に作るもの

最終的に作るのはローカルAIエージェント実行ダッシュボードで、構成のイメージは以下のとおりです。

[Claude Desktop / Claude Code]
            │
            │  MCP経由で呼び出し
            ▼
   [自作MCPサーバー (Python)]
            │
            ├─► 自分の業務に関係するファイル操作
            ├─► テキスト検索ツール
            └─► 実行ログ書き込み
                       │
                       ▼
                  [SQLite]
                       │
                       ▼
        [Next.jsで作る実行履歴ビューア]
     （実行履歴 / 結果 / エラーを画面で確認）

業務効率化の観点で言い直すと以下のようになります。
①AIが自分の業務に必要なファイルや情報に直接触れるようになる。
②AIが何をしたかが自分のSQLiteに残る。
③何が成功し、何が失敗したか、が画面で見える。
④仕組みが分かっているので、業務で使う際の判断が自分でできる。

ChatGPTでnote記事のたたき台を作っていた自分から、AIが自分の環境の中で動き、実行ログまで自分で管理する自分へ。 インフラエンジニアとして馴染みのある「動く仕組み＋運用ログ」という発想をAI側にも持ち込む形です。

■ 次章でやること

第2章では、自分が「促されるままに入れた」Claude Desktopがいったい何なのかを正面から扱います。 具体的には次の4つを区別します。

①Claude.ai（ブラウザで皆が使っているやつ）。
②Claude Desktop（PCに入れたやつ）。
③Claude API（開発者向けの呼び出し口）。
④Claude Code（私が最初に興味を持ったコード作業向けのAIエージェント）。

合わせてエディタ側の整理として、VSCode、Cursor、Windsurfの位置関係にも触れます。 名前が似ているもの同士を、ここで一度ほどいておきます。 そのうえで、なぜMCPを試す最初の場所としてClaude Desktopが選ばれているのかを確認します。 そのために設定画面を開いて、設定ファイルの場所まで実際に確認します。 ここから画面を開く作業が始まります。

■次回

第2章【開発記】：促されるままに入れたClaude Desktopが何者かを設定ファイルから確かめた


いいなと思ったら応援しよう！