Claude CodeとPythonで自作ダッシュボードの作り方

自動化スクリプトを数十個も動かしていると、どれが昨日コケたのか把握しきれなくなります。

私もlaunchdに仕事を押しつけすぎて、気づいたら3日前から1本止まっていた経験があります。

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

この泥沼を抜けたくて、Claude CodeとPythonで自分専用のダッシュボードを作りました。

既製のSaaSを使わず、自分の運用に合わせて画面を育てていくやり方です。

この記事では、設計の判断軸から実装・運用まで、実際に動かしているコードをベースに手順を共有します。

自分専用ダッシュボードとは、GrafanaやDatadogのような既製のSaaSに頼らず、Claude CodeとPythonを使って自分の運用に合わせて作る、監視・可視化のためのツールです。

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.~."

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秒でわかる画面になります。派手なグラフは要らず、情報密度が高い方が日常運用には合いました。

Claude Codeで育て続けるダッシュボード運用のコツ

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

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

私の場合は「朝コーヒーを淹れている間にdashboard.mdを開く」を習慣にしました。

わざわざ見に行くのではなく、既存の生活動線に画面を差し込むだけで継続率が変わります。

見る場所が固定されていない画面は、どれだけ便利でも数週間で存在を忘れられます。

定期更新は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分以上の間隔があるエントリを別セッションとして分割し、最初のセッションだけを計測対象にしています。

細かい話ですが、こういう「実運用で気づく歪み」を直していく工程こそ、自作ダッシュボードの醍醐味です。

既製ツールだと同じ悩みは黙って受け入れるしかありません。

よくある質問

Q1. Claude CodeとPythonで自作ダッシュボードを作るのにどれくらい時間がかかりますか？

A1. 設計を紙1枚で先に固めてあれば、雛形の生成からMarkdown出力までは数時間程度で動かせます。ただし継続的に育てる前提のため、初回で完璧を目指す必要はありません。

Q2. StreamlitとMarkdown出力、どちらを選ぶべきですか？

A2. グラフを操作したい・常駐UIが欲しいならStreamlit、毎朝チラッと確認するだけで常駐プロセスを増やしたくないならMarkdown出力が向いています。本記事ではgit管理のしやすさを優先しMarkdown出力を選びました。

Q3. ダッシュボードのデータはSQLiteとJSON、どちらで保存すべきですか？

A3. 数百件程度ならSQLiteは不要です。既存のログファイルをその都度パースする方式でも十分動きます。データが将来的に膨らむ見込みならSQLite、API経由で外部に出す予定ならJSONが扱いやすいです。

Q4. Claude Codeに雛形を作らせるとき、どんなプロンプトを投げればいいですか？

A4. 「いい感じに」のような抽象的な依頼は避け、入力元・出力先・分析期間などの具体的な数字を必ず含めます。たとえば「分析期間は30日、出力先は同ディレクトリのdashboard.md」のように書くと精度が上がります。

Q5. ダッシュボードを継続的に使い続けるコツはありますか？

A5. 生活の中に見る動線を組み込むことが重要です。既存の習慣に画面を差し込み、Claude Codeで機能追加を1回1機能ずつ小さく繰り返すと長続きします。

Q6. 異常検知はどのように実装すればいいですか？

A6. 過去の実行時間の平均を計算し、直近の実行時間がその一定倍数（本記事では3倍）を超えたら異常とみなすシンプルなルールで十分です。短時間ジョブの誤検知を防ぐため、平均が一定値未満のジョブは対象外にする工夫も有効です。

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

Claude CodeとPythonの組み合わせは、自分専用ダッシュボードの自作ハードルを大きく下げてくれました。

ポイントを振り返ると、設計を紙1枚で先に決めること、最小実装から育てること、launchdで毎日呼び出して生活に組み込むことの3つです。

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

私のダッシュボードは今も週に1回くらい手を入れています。画面が自分の問いに答えてくれるたび、「これは買えないやつだな」と実感します。

まずは可視化したい対象を3つ書き出して、Claude Codeに最初のプロンプトを投げるところから始めてみてください。