エージェント実行をSQLiteで全部記録する: cost/tokens/dialogue_logs設計パターン

AIに仕事を任せた翌朝、あなたは何を確認しますか？

個人でメディアを運営している友人から、こんな相談を受けました。

「Claude Codeに記事収集と下書きを全部任せたんだけど、怖くて結局毎日手動で中身を見ちゃう。これじゃ自動化の意味がない」

わかります。AIに任せた瞬間、『昨日いくら使った？』『途中で止まってない？』『品質は落ちてない？』という3つの不安が一気に押し寄せてくるんですよね。

ところが、同じ悩みを持っていたある個人運営者は、SQLite（= 軽量なデータベース。Excelに近い感覚で使える1つのファイル）に3つのテーブルを作っただけで、300日以上ノーメンテで本番を回しています。毎朝7時、前日のサマリーが自動でSlackに届く。総コスト、エラーの有無、品質スコアの推移。それだけ見れば、あとは安心してコーヒーを飲める。

この記事は、そのシンプルな設計パターンをまるごと解説する内容です。

なぜSQLiteなのか（PostgreSQLじゃダメ？）

図: 個人運営に必要な3テーブル設計の全体像

個人運営の現場で強いのは、圧倒的にSQLiteです。理由はシンプルで、ファイルが1つで完結するから。サーバーも認証もいらない。バックアップはcpコマンド1発。Dropboxに置いておけば、それだけで冗長化も完了します。

『ちゃんとしたDBを立てなきゃ』という思い込みを捨てるのが、個人運営の最初の一歩です。

[FIGURE:concept:SQLite 3テーブル設計の全体像 — agent_runs（実行記録） / cost_ledger（コスト台帳） / dialogue_logs（判断ログ）+ 日次集計ビュー]

レイヤー1: agent_runs — エージェントの『出勤簿』

まず基礎になるのがagent_runsテーブル。これはエージェント（= 役割を持たせたAIの働き手）の出勤簿だと思ってください。誰が、何時に仕事を始めて、何時に終わって、無事に帰ってこれたか。これを1行ずつ記録します。

CREATE TABLE agent_runs (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  agent_name TEXT NOT NULL,        -- 例: 'fetcher', 'writer', 'reporter'
  started_at TEXT NOT NULL,         -- ISO8601
  finished_at TEXT,
  status TEXT NOT NULL,             -- 'running' / 'success' / 'error'
  error_message TEXT,
  input_tokens INTEGER,
  output_tokens INTEGER,
  model TEXT
);

読めなくても大丈夫。要点はこうです。

• 誰が働いたか（agent_name）
• いつ始めて、いつ終わったか（started_at / finished_at）
• 成功したか、エラーで倒れたか（status）
• 何トークン使ったか（input_tokens / output_tokens）

この1テーブルがあるだけで、『昨日、writerエージェントが途中で落ちてた』みたいな事実が即座に浮かび上がります。

レイヤー2: cost_ledger — コストの『家計簿』

2つ目はcost_ledger。これは家計簿です。重要なポイントが1つあって、ドルと円の両方を記録すること。

CREATE TABLE cost_ledger (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  run_id INTEGER REFERENCES agent_runs(id),
  occurred_at TEXT NOT NULL,
  model TEXT NOT NULL,
  usd_amount REAL NOT NULL,
  jpy_amount REAL NOT NULL,
  fx_rate REAL NOT NULL
);

なぜ両方？ ドルだけだと為替が動いたときに過去の円換算がズレてしまい、確定申告のときに泣くことになります。『その日のレートで円に直した額』を記録しておくのが、個人事業主にとっての正解です。

[FIGURE:comparison:検品なし運用 vs 検品あり運用 — コスト暴走・品質低下を防ぐのは『記録』そのもの]

レイヤー3: dialogue_logs — 判断の『業務日報』

3つ目のdialogue_logsは、少し毛色が違います。これはトレーナー（= あなた自身）がAIの出力にどう判断を下したかを記録する場所です。

CREATE TABLE dialogue_logs (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  run_id INTEGER REFERENCES agent_runs(id),
  logged_at TEXT NOT NULL,
  role TEXT NOT NULL,           -- 'trainer' / 'agent'
  decision TEXT,                 -- 'approve' / 'reject' / 'revise'
  reason TEXT,                   -- 判断理由（自然文）
  quality_score INTEGER          -- 1-10
);

なぜこれが大事か。AIに仕事を任せるとき、一番失われやすいのが『なぜその判断を下したか』という暗黙知です。『この記事は煽りすぎだからボツ』『この見出しは読者に刺さるからOK』——そういうあなたの判断基準そのものを蓄積しておくと、のちのちプロンプトを改善するときの金脈になります。

レイヤー4: 日次集計ビュー — 『昨日の稼働状況』を一発で

図: 3テーブルから日次サマリーが生成されるまでのデータフロー

ここからが楽しいパートです。3つのテーブルを組み合わせて、日次ビュー（= 毎回SQLを書かなくても『昨日の状況』が見られる仮想テーブル）を作ります。

CREATE VIEW daily_summary AS
SELECT
  date(started_at) AS day,
  COUNT(*) AS total_runs,
  SUM(CASE WHEN status='error' THEN 1 ELSE 0 END) AS errors,
  SUM(input_tokens + output_tokens) AS total_tokens,
  (SELECT SUM(jpy_amount) FROM cost_ledger c 
    WHERE date(c.occurred_at) = date(agent_runs.started_at)) AS jpy_total
FROM agent_runs
GROUP BY day;

要点はこうです。 このビューを作ったあと、SELECT * FROM daily_summary ORDER BY day DESC LIMIT 7;と打つだけで、直近7日間の『稼働数・エラー数・総トークン・総コスト（円）』が一発で出ます。毎朝これを眺めるだけで経営判断ができる。

[FIGURE:flow:毎朝7時、reporterエージェントが日次ビューを読み取り→Slackに投稿するまでの時系列]

レイヤー5: reporterエージェント — 毎朝の自動日報

ここまで来たら、最後にreporterという名前の小さなエージェントを1つ追加します。役割は『毎朝7時に日次ビューを読んでSlackに投稿する』だけ。

launchd（= macOSの定時実行の仕組み。目覚まし時計のようなもの）やVercel Cronで朝7時に起動するよう設定しておけば、あとは何もしなくていい。前日のサマリーが、Slackにそっと届きます。

• 昨日の総コスト: 312円
• 実行回数: 24件（エラー 0件）
• 平均品質スコア: 8.2 / 10
• 気になる兆候: なし

これだけ見れば、朝の5秒で経営状態が把握できる。逆に言えば、この5秒のために3テーブルを用意しているとも言えます。

レイヤー6: 異常検知 — エラー連続発生だけは見逃さない

最後のレイヤーは、例外通知です。正常なときはサマリーだけでいいのですが、『連続3回エラー』『1日のコストが閾値超え』といった異常な状況だけは、即座に別通知で上げます。

SELECT COUNT(*) FROM agent_runs
WHERE status = 'error'
  AND started_at > datetime('now', '-1 hour');

1時間以内のエラー件数を見るだけのシンプルなクエリですが、これが『3』を超えたらプッシュ通知を送る——それだけで夜中の事故が9割防げます。

エンジニアじゃない方へのメッセージ

図: 記録なし運用 vs 3テーブル運用の違い

ここまで読んで『やっぱり難しそう』と感じた方へ。

安心してください。この設計で本当に大事なのは、コードの書き方ではなく、『AIにも出勤簿と家計簿を持たせる』という発想です。

あなたが個人事業主として新入社員を雇ったとしたら、タイムカードと経費精算の仕組みを必ず作りますよね。AIエージェントも同じです。『働いた記録』と『使ったお金』と『判断の理由』——この3つさえ毎日記録されていれば、AIを雇うのはまったく怖くありません。

難しいのはSQLでもSQLiteでもなく、『記録を残す』という習慣を決めること。その習慣さえ決まれば、あとは下の特典zipを解凍して、あなたのメディアに合わせて名前を変えるだけです。

🎁 特典: 設定ファイル一式ダウンロード

この記事で紹介した設計を、そのまま使える形でまとめました。

zipの中身:

• schema.sql — 3テーブル + 日次集計ビューの完全なスキーマ定義
• init.sh — SQLiteファイルを初期化するシェルスクリプト（コピペで実行可）
• queries.sql — 『昨日のサマリー』『週次コスト推移』『品質スコア7日平均』など、よく使う集計クエリ集
• dashboard.html — ブラウザで開くだけで日次ビューをグラフ化できる可視化ダッシュボード（1ファイル完結）
• reporter-template.md — 毎朝のSlack日報を生成するreporterエージェント用プロンプトテンプレート

解凍して、あなたのメディアテーマに合わせてテーブル名や閾値を書き換えるだけで、今日から使えます。

ダウンロード

📚 参考リファレンス

• Claude Code 公式ベストプラクティス
• Anthropic API: Usage & Cost tracking
• SQLite 公式ドキュメント
• awesome-claude-code