Python×MCPでCursor強化:生活ログ分析を自動化する

毎朝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と対話するインターフェイスに変わる体験は、技術を「自分事」にする感覚をくれます。

一歩踏み出すコストは、週末の半日と好奇心だけ。その投資は、間違いなく元が取れると確信しています。

以上です。