毎朝5時に起きて朝活の記録をつけ、禁煙の継続日数を手帳に書き留めている。
そんな地道な習慣管理を続けながら、「このデータ、もっとうまく活かせないか」とずっと思っていました。
Markdownで書いた日々のログは、見返すのが面倒で埋もれがち。グラフを作るほどでもないし、かといって放置するのも惜しい。記録はあるのに、活かせていないという微妙なもったいなさが、ずっと引っかかっていたんです。
そこで試してみたのが、PythonでMCPサーバを自作し、Cursorから直接ログを問いかけるという仕組みです。
技術的には決して難しくないのに、体験としては驚くほど便利。今回はその構築手順と、実際に使ってみた感触をシェアします。
MCPでCursorを賢くする
MCP(Model Context Protocol)は、AIアシスタントが外部のデータやツールと安全にやり取りするためのオープンな通信規約(プロトコル)です。
Anthropicが2024年末に公開したもので、簡単に言うと「AIに専用の手足を生やすための標準的な接続口」のようなものです。
CursorはこのMCPに対応しており、自作サーバを登録することで、チャット欄から直接ファイルを読んだり、自分で定義した関数を呼び出したりできるようになります。
生活ログをAIに「直接」渡す
従来のやり方だと、MarkdownやCSVのログをコピーしてチャットに貼り付け、「これを分析して」と頼む必要がありました。
毎回のコピペ作業がじわじわ面倒で、結局やらなくなる——そんな経験、ありませんか。MCPを使えば、Cursorが自作サーバ経由でログファイルを直接参照できます。
「今週の朝活達成率は?」と入力するだけで、AIがファイルを読み、集計し、答えを返してくれる。この体験の差は、続けられるかどうかに直結します。
なぜ今、自作MCPサーバなのか
既製のツールやSaaS連携では、自分のローカルファイルをそのまま扱うのはハードルが高いです。
Pythonで自作するからこそ、ファイルフォーマットや集計ロジックを自分仕様にカスタマイズできる。
しかも学習コストは想像以上に低く、Pythonの基礎があれば週末の半日で動くものが作れます。
技術習得とQOL向上が同時に叶う——そう腑に落ちた瞬間、試さない理由が見当たらなくなりました。
PythonでMCP環境を構築する
実装に入る前に、開発環境を整えましょう。
ここではPython 3.11以上を前提に進めます。
uvとvenvでプロジェクトを立ち上げる
パッケージ管理にはuvを使うのがおすすめです。
pipより高速で、仮想環境の作成と依存関係の管理を一括で扱えます。
概念を示すと、以下のようなイメージです。
# プロジェクトディレクトリを作成
mkdir life-log-mcp && cd life-log-mcp
# uvで仮想環境を作成・有効化
uv venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
# MCP SDKをインストール
uv pip install mcp
[要URL: MCP Python SDK の公式リポジトリ(GitHub)]
プロジェクト構成はシンプルに保ちます。
life-log-mcp/
├── server.py # MCPサーバ本体
├── logs/
│ └── habit.md # 生活習慣ログ
└── pyproject.toml
構成がシンプルであるほど、後から改修しやすくなります。
Cursorにサーバを登録する
Cursorの設定はSettings > MCPから行います。
mcp.jsonに以下のような形式でサーバの起動コマンドを記述します。
{
"mcpServers": {
"life-log": {
"command": "python",
"args": ["/path/to/life-log-mcp/server.py"]
}
}
}
commandにはPythonの絶対パスを指定するほうが、環境差異によるトラブルを防げます。
登録後にCursorを再起動すると、チャット欄でサーバが有効化されていることを確認できます。
サーバの実装コードを読み解く
ここからが本題です。
MCPサーバの実装では、「Tools」としてPython関数を登録することで、AIがその関数を呼び出せるようになります。
ログファイルを読み込む基本構造
以下は、Markdownログを読み込むToolの概念を示す部分スニペットです。
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp import types
import json
app = Server("life-log")
@app.tool()
async def read_habit_log() -> str:
"""生活習慣ログを読み込んで返す"""
try:
with open("logs/habit.md", "r", encoding="utf-8") as f:
return f.read()
except FileNotFoundError:
return "ログファイルが見つかりません"
# 省略
@app.tool()デコレータを付けるだけで、CursorのAIがこの関数を「呼べるツール」として認識します。
集計ロジックをToolとして定義する
ログの読み込みだけでなく、集計処理もToolとして定義するのがポイントです。
AIに生のログを渡して「集計して」と頼むより、Python側で集計まで完結させてAIに結果だけ渡すほうが、精度が安定します。
@app.tool()
async def calc_morning_rate(weeks: int = 1) -> str:
"""直近N週間の朝活達成率を計算する"""
# ログをパースして達成日を抽出するロジック
# ...
achieved = 5 # 例: 達成日数
total = 7 * weeks
rate = round(achieved / total * 100, 1)
return json.dumps({"rate": rate, "achieved": achieved, "total": total})
# 省略
AIが理解しやすい構造化されたJSONで返すことで、回答の品質が上がります。
エラーハンドリングのコツ
ファイルが存在しない・フォーマットが崩れている、といったエラーは必ず起きます。例外を握りつぶさず、AIが「何が起きたか」を理解できるメッセージを返すのが大切です。
except Exception as e:
return json.dumps({"error": str(e), "message": "ログの読み込みに失敗しました"})
こうすることで、AIが「ログが読めなかった」と理解した上で、次のアクションを提案してくれます。
ログ分析を実際に動かす
サーバを起動してCursorを再起動すると、チャット欄からToolを呼び出せるようになります。
実際のプロンプトと結果
試しに「今週の朝活達成率を教えて」と入力すると、Cursorは自動でMCPサーバのcalc_morning_rateを呼び出し、以下のような返答を返してくれました。
数値だけでなく、具体的な改善提案まで返ってくるのには素直に驚きました。今週の朝活達成率は 71.4%(5/7日) です。月・火・木・金・土に達成しています。水曜日と日曜日が未達成でした。来週は水曜日の前日夜にアラームを追加してみるのはいかがでしょう。
禁煙・断捨離の進捗確認
禁煙ログには「最終喫煙日」を記録しておけば、継続日数の計算もToolで自動化できます。
プロンプト例:
- 「禁煙を始めてから何日経った?」
- 「断捨離で手放したアイテム数の合計を教えて」
- 「今月の睡眠時間の平均は?」
「客観的なデータを持ったAI」が習慣の伴走者になるという感覚は、自分でも予想以上でした。
主観的に「今週はまあまあ頑張った」と思っていたのに、データを見ると達成率57%だった——そういう「自己評価のズレ」を可視化してくれることが、最大の価値かもしれません。
技術でQOLを上げる試み
このMCPサーバを作りながら、改めて思ったことがあります。
技術を「自分事」として使う意義
30代で仕事と育児を並走させていると、学習に使える時間は本当に限られています。
そんな中で「業務に直結しないかもしれないけど、自分の生活に役立つ」ツールを作ることが、技術へのモチベーションを維持する一番の近道だと痛感させられます。
机上の勉強より、自分が毎日使うツールを作るほうが、手が動くし、記憶にも残る。
他の学習事項とのシナジー
今回のMCPサーバ構築で培ったPythonの非同期処理や構造化データの扱い方は、Ruby on Railsや画像生成AIのAPI連携にも直接活きてきます。
一見バラバラに見える学習項目が、実はひとつのプロジェクトを通じて繋がっていく。そう腑に落ちた感覚があります。
「自動化の余白」が生む好循環
毎朝のログ集計から解放されることで、その数分を次の技術検証や読書に充てられるようになりました。
自動化が余白を生み、余白が新しい学習を生む——この好循環こそ、エンジニアが自作ツールを持つことの本質的な価値です。
「完璧なシステムを作る」より「自分が毎日使えるものを作る」。そのスタンスで作ったものほど、長く続きます。
最後に
PythonでMCPサーバを自作してCursorと連携させる、というのは聞くと難しそうですが、実際には数十行のコードから始められます。
大事なのは、完成度より「自分が使いたいと思えるかどうか」。
Markdownで書いた生活習慣ログが、AIと対話するインターフェイスに変わる体験は、技術を「自分事」にする感覚をくれます。
一歩踏み出すコストは、週末の半日と好奇心だけ。その投資は、間違いなく元が取れると確信しています。
以上です。






コメントを残す