Claude CodeとPythonで自分だけのダッシュボードを作る手順

自動化スクリプトを20個ほど動かしていると、どれが昨日コケたのか把握しきれなくなります。私もlaunchdに仕事を押しつけすぎて、気づいたら3日前から1本止まっていた経験があります。

ログを順に開く気力もわかないので、結局「だいたい動いてるからいいや」で済ませていました。

この泥沼を抜けたくて、Claude CodeとPythonで自分専用のダッシュボードを作りました。既製のSaaSを使わず、自分の運用に合わせて画面を育てていくやり方です。この記事では、設計の判断軸から実装・運用まで、実際に動かしているコードをベースに手順を共有します。

Claude CodeとPythonでダッシュボードを自作する魅力

自作の最大の利点は、自分の運用に合う形でしか作らないから破綻しないことです。GrafanaやDatadogは便利ですが、私の用途にはオーバースペックで、月額を払うほどの価値を感じられませんでした。

Claude Codeに設計の壁打ちをさせながら、数時間でMVPを組める時代なので、既製ツールを諦める前提がそもそも古くなっています。

既製ツールに合わせる生活から卒業できる

既製のモニタリングツールは「何を測るか」を相手が決めています。私が見たいのは「昨日のlaunchdジョブで失敗した奴だけ」なのに、CPU使用率のグラフが場所を取ってくる。

自作ならこの主従が逆転して、自分の疑問だけが画面に並びます。結果、ダッシュボードを見る時間が5分から30秒に短縮されました。

自動化スクリプトの成果を一画面で見渡せる

ポイントサイト自動クリック、WordPress分析、フィード監視など、自動化スクリプトは積み上がるほど全体像が見えなくなります。実行ログは各ディレクトリに散らばり、Slack通知は流れていく。

ダッシュボードが1枚あるだけで「今週は何が動いて、何が止まっているか」が即答できます。目視コストが下がると、新しい自動化を足す心理的ハードルも下がります。

ダッシュボード作成前に決めておく3つのこと

コードを書く前に決めておくべきことは3つだけです。ここを曖昧にしたままClaude Codeに「いい感じのダッシュボードを作って」と頼むと、目的不明のグラフが大量に並ぶ謎のアプリが出てきます。

私も最初の挑戦で経験しました。先に紙1枚分の設計をしておくと、生成されるコードの精度が段違いです。

何を可視化したいかを書き出す

最初の作業は「自分は何を知りたいか」の言語化です。私は「launchdジョブごとの成功失敗」「直近14日のカレンダー」「実行時間が通常の3倍を超えたら異常扱い」の3つに絞りました。

ここを3つ以内に絞ると、画面がスッキリします。逆に10個書き出したなら、半分に減らせないか自問した方がいいです。

データの保存形式を決める（JSONかSQLite）

データソースをどう持つかで実装難度が変わります。私のケースは既にlaunchdの.plistと各スクリプトの.logファイルが揃っていたので、新しいデータベースは作らず、既存ファイルを毎回パースする方式にしました。

数百件程度ならSQLiteすら要りません。将来的にデータが膨らむならSQLite、API経由で外部に出すならJSONが扱いやすいです。

表示方法を選ぶ（StreamlitかFastAPI+HTML）

私は最終的にMarkdown出力を選びました。理由は3つで、VS Codeのプレビューで即見られる・git管理できる・launchdでcron的に実行すれば常駐プロセスが不要、という点です。

グラフをグリグリ動かしたい用途ではStreamlitが正解ですが、毎朝チラッと確認するだけなら静的Markdownで十分でした。

Claude Codeで雛形を作る最短ステップ

設計が決まったら、雛形作りは一気にClaude Codeに任せます。ここで大事なのは、最初から完璧な仕様を与えるのではなく、「動く最小の形」を先に作ってから肉付けすることです。私の経験上、最初に詰め込みすぎると、Claude Codeも私も迷子になります。

小さく始めて、気に入らない部分を指差しで直していく方が圧倒的に速いです。

プロジェクト初期化と依存パッケージの準備

私はuvで仮想環境を用意しています。軽量でpyproject.tomlも自動生成してくれるので楽です。

mkdir my_dashboard && cd my_dashboard
uv init --no-package --no-readme --python ">=3.10"
uv venv --seed .venv
# 標準ライブラリだけで足りるなら依存追加は不要

自然言語でPythonアプリの土台を生成

次にClaude Codeを起動し、書き出した設計を日本語でそのまま投げます。私が実際に使ったプロンプトはこんな感じでした。

launchdのplistと各ジョブのログを解析して、
成功率・平均実行時間・直近14日のカレンダーをMarkdownに出力する
Pythonスクリプトを dashboard.py に作って。
分析期間は30日、出力先は同ディレクトリの dashboard.md。

抽象的に頼むほど精度は落ちるので、入力・出力・期間などの具体数字を必ず入れます。「いい感じに」は禁句です。

生成コードをレビューして意図を伝え直す

生成直後のコードは、だいたい7割の出来で残り3割が自分の好みと合いません。私の場合は「異常検知の閾値をモジュール定数に出して」「ログパーサーはdataclassで型を明示して」のような細かい修正を指示しました。

Claude Codeは文句も言わず直してくれます。ここで妥協すると半年後の自分が泣くので、違和感を放置しないのがコツです。

自分のデータをダッシュボードに取り込む実装例

ここからは実際に動いているコードの要点を紹介します。私のダッシュボードはlaunchdジョブ管理用ですが、対象が何であっても「ソースを読む→集計する→整形して出す」の3段構えは同じです。

この骨格を押さえておけば、後から対象を増やすのが楽になります。

launchdジョブの実行ログを読み込む

私はplistlibでplistを直接パースしてジョブ情報を集めています。標準ライブラリだけで済むのがPythonの強みです。

import plistlib
from pathlib import Path

LAUNCHD_PREFIX = "com.suzukitomohiro."

def parse_plist_jobs(launchd_dir: Path) -> list[dict]:
    jobs = []
    for plist_path in sorted(launchd_dir.glob(f"{LAUNCHD_PREFIX}*.plist")):
        with open(plist_path, "rb") as f:
            plist = plistlib.load(f)
        jobs.append({
            "label": plist.get("Label"),
            "working_dir": plist.get("WorkingDirectory", ""),
        })
    return jobs

集計処理を関数化してテストしやすくする

集計ロジックはdataclassで1レコードの型を固めてから、プロパティで派生値を計算する形にしました。こうしておくとテストが書きやすく、Claude Codeに修正を頼むときも指示が一意になります。

たとえば異常検知は「過去の実行時間平均の3倍を超えたら異常」というシンプルなルールです。

ANOMALY_THRESHOLD = 3.0

@property
def is_anomaly(self) -> bool:
    durations = [r.duration_seconds for r in self.runs if r.duration_seconds]
    if len(durations) < 3:
        return False
    past_avg = sum(durations[:-1]) / len(durations[:-1])
    if past_avg < 5.0:  # 短時間ジョブの誤検知対策
        return False
    return durations[-1] > past_avg * ANOMALY_THRESHOLD

グラフ・テーブルで状態を可視化する

Markdown出力なので、表現はテーブルと絵文字で済ませています。成功は✅、失敗は❌、未実行は⚪。これだけで「昨日何が起きたか」が3秒でわかる画面になります。派手なグラフは要らず、情報密度が高い方が日常運用には合いました。

育て続けるための運用のコツ

ダッシュボードは一度作って終わりだと確実に腐ります。私の最初のバージョンも、3週間で「もう見なくていいや」状態になりました。

自分の生活リズムに自然に組み込まれる仕掛けを作ることと、Claude Codeで小さな改善を継続的に回すことの2点が、生き残らせるコツです。

定期更新はlaunchdかcronに任せる

Macを使っているなら、launchdのStartCalendarIntervalで毎朝自動生成するのが手軽です。以下は毎日朝7時に動くplistの例です。書き終えたdashboard.mdをGitHubにpushすれば、iPhoneからも見られます。

<key>StartCalendarInterval</key>
<dict>
    <key>Hour</key><integer>7</integer>
    <key>Minute</key><integer>0</integer>
</dict>

Claude Codeで機能追加を小さく繰り返す

追加機能は1回1機能を厳守しています。「異常検知ルールを調整したい」「月次ジョブ用のセクションを足したい」といった粒度で、Claude Codeに1つずつ依頼します。

まとめて頼むとデグレの温床になるので、面倒でも分けます。PR相当の粒度で日記に残しておくと、半年後に「なぜこう書いたんだっけ」と迷わずに済みます。

つまずきポイントと改善した設計判断

最初は同日に手動実行と定期実行が混ざると、実行時間が不正確になる問題がありました。対策として、10分以上の間隔があるエントリを別セッションとして分割し、最初のセッションだけを計測対象にしています。

細かい話ですが、こういう「実運用で気づく歪み」を直していく工程こそ、自作ダッシュボードの醍醐味です。既製ツールだと同じ悩みは黙って受け入れるしかありません。

まとめ：ダッシュボードは作って終わりじゃない

Claude CodeとPythonの組み合わせは、自分専用ダッシュボードの自作ハードルを大きく下げてくれました。ポイントを振り返ると、設計を紙1枚で先に決めること、最小実装から育てること、そしてlaunchdで毎日呼び出して生活に組み込むこと。

この3つを押さえれば、数時間で動かして半年以上使い続けられます。

私のダッシュボードは今も週に1回くらい手を入れています。画面が自分の問いに答えてくれるたび、「これは買えないやつだな」と実感します。まずは可視化したい対象を3つ書き出して、Claude Codeに最初のプロンプトを投げるところから始めてみてください。