セッションのレポートを Obsidian に保存する

このスキルは、いま進めてきたセッションの内容を一本の日本語レポートに再構成し、Obsidian vault に保存する。

想定読者は、数か月後の abekoh 自身である。 会話の流れをなぞった議事録ではなく、結論とその根拠を再構成した文書を書く。 会話中では自明だった前提も、数か月後には失われている。

併用する規範

レポート本文は日本語の技術文書なので、~/.claude/CLAUDE.md の規定どおり、本文を書く前に次の2つのスキルを読んで適用する。

• japanese-tech-writing：整形（一文一行、コードブロック、ダッシュと中黒の扱い）、パラグラフの構成、論証の厳密さ
• cognitive-rhythm-writing：段落の密度、文の拍、駄文の判別

この2つが表記と文章構造の基準になる。 本スキルの「執筆の原則」は、レポートという文書種別に固有の判断（何を書き、何を捨てるか）を扱う。

手順

1. 日付とモデルIDを取得する

date +%Y-%m-%d

モデルIDはシステムプロンプトの「The exact model ID is <id>」から読み取る（例：claude-opus-5）。 フロントマターの model に使う。

2. ファイル名を決める

保存先は次のパスである。

~/obsidian/abekoh/_reports/YYYY/MM/YYYY-MM-DD-{summary}.md

{summary} は日本語で書く。 そのレポートが何についてのものかが、ファイル名だけで判別できることが条件だ。

• 全角10〜20文字程度に収める
• 固有名詞（プロダクト名、ツール名、ライブラリ名）は原表記のまま使う
• 単語をつなぐときはハイフンではなく、そのまま日本語として続ける
• Obsidianとファイルシステムで問題になる文字を使わない：/ \ : * ? " < > | # ^ [ ]、および空白

例：

セッションの内容	ファイル名
newspapers の朝刊が生成されなかった原因調査	2026-08-19-newspapers朝刊のトリアージ障害.md
筋トレ記録アプリのデータモデル検討	2026-07-05-筋トレ記録アプリの設計検討.md
jj (Jujutsu) を触ってみた記録	2026-08-20-jujutsuの基本操作を試す.md
Obsidian レポート用スキルの作り直し	2026-08-20-Obsidianレポートskillの改良.md

デイリーノートに書くウィキリンクは、このファイル名から .md を除いたものと完全に一致させる。 一致しないとリンクが切れる。

3. 本文を書く

フロントマターと # 見出し だけが固定である。

---
tags: [reports]
date: YYYY-MM-DD
model: {モデルID}
---

# {タイトル}

（本文）

タイトルはファイル名の {summary} と同じである必要はない。 ファイル名は一覧で見分けるための短い札、タイトルは中身を的確に言い表す句だと考えて、それぞれ最適なものを選ぶ。

見出し構成は固定しない。 セッションの性質に合った構成を自分で決める。 後述の「執筆の原則」と「構成の型」を判断材料にする。

4. 保存する

_reports/YYYY/MM/ は存在しないことがあるので、必ず先に作る。

mkdir -p ~/obsidian/abekoh/_reports/YYYY/MM

そのうえで Write ツールでファイルを書く。

obsidian-cli の create は中間ディレクトリを作らないため、レポート本体の作成には使わない。 mkdir -p と Write ツールの組み合わせが、CLIの有無にかかわらず確実に動く唯一の経路である。

5. デイリーノートにリンクを追記する

デイリーノートは ~/obsidian/abekoh/_daily/YYYY/MM/YYYY-MM-DD.md にある。 末尾に次のブロックを追記する。冒頭の空行と --- も書式の一部だ。

---
#reports

[[YYYY-MM-DD-{summary}]]

まず obsidian-cli が使えるかを試す。

obsidian daily:read >/dev/null 2>&1

使える場合：

obsidian daily:append content="\n---\n#reports\n\n[[YYYY-MM-DD-{summary}]]"

使えない場合：

Readツールで現在のデイリーノートを読み、末尾にブロックを足してWriteツールで書き戻す。 当日のデイリーノートがまだ存在しないときは、mkdir -p でディレクトリを作り、このブロックだけを内容として新規作成する。

執筆の原則

以下は木下是雄『理科系の作文技術』の考え方を、セッションレポートという用途に合わせたものだ。 仕事の文書は自己表現の場ではなく、情報を正確かつ迅速に伝える道具である。 目指すのは、読者に負担をかけず、一通りにしか読めないように伝えることに尽きる。

何を伝えるレポートかを、書く前に一文で決める

「今日やったことを書く」ではレポートにならない。 「このレポートは、8/19の朝刊が出なかった原因が、Cron実行エッジの地理的偶然にあると示すために書く」のように、主張を一文で立ててから書き始める。 この一文が、材料を残すか捨てるかの判断基準になる。

一文書一主題を守る。 セッション中に無関係な話題を2つ扱ったなら、レポートも2本に分ける。

結論を先に置く

数か月後の自分は、まず「で、結局どうなったのか」を知りたい。 冒頭に、背景と結論を含む数文の要旨を置く。 そこを読めば、続きを読むべきかどうかを判断できる状態にする。

説明の順序は概観から細部へ向かう。 調査の時系列をそのまま並べると、最後まで読まないと全体像が見えない文書になる。

段落は一つの思想単位にする

段落の最初の文を拾い読みしていくと、それだけで全体の要約になる。 これが理想の状態であり、書き終えたあとに実際に試して検証できる基準でもある。

事実、推測、次のアクションを混ぜない

• 事実：確認した結果。「D1の editions テーブルで 8/19 分だけ status='failed' だった」のように、確認方法とともに書く
• 推測：事実からの推論。「地域制限が原因だと考える」と、判断であることを明示する
• 未確定：裏が取れなかったこと、確かめていない前提。省かずに残す
• 次のアクション：やり残したこと、次に判断すべきこと

この区別を曖昧にすると、数か月後に「これは確認済みなのか、そのとき推測しただけなのか」が分からなくなり、レポートの価値が失われる。

言い回しの上では、責任の所在をぼかす表現を避ける。 「〜と思われる」は、自分の判断なら「〜と考える」、確認済みの事実なら「〜である」と書く。 一方で、本当に不確実なことを断定に変えてはいけない。 確度を落とすのではなく、確度を正確に示す。

再現に必要な具体を残す

数か月後の自分が同じ場所にたどり着けるように、具体的な手がかりを本文に埋める。

• コマンド、APIエンドポイント、クエリ
• ファイルパス、関数名、コミットハッシュ
• 参照したドキュメントのURLと、そこに書かれていた要点
• エラーメッセージの原文

要約しすぎて手がかりを失うより、原文を短く引用するほうが後で役に立つ。

失敗した経路も書く

試して駄目だった方法、検討して却下した選択肢は、その理由とともに残す。 同じ轍を二度踏まないための情報であり、レポートの価値の少なくない部分がここにある。

書かないもの

• セッション中の雑談、脱線、指示のやり取りそのもの
• 「本セッションでは〜について調査しました」のような、内容のない前置き
• 「重要な知見が得られました」のような、中身を伴わない評価
• 埋め草。なくても意味が通る語は一つも書かない

構成の型

型は出発点であって、当てはめる枠ではない。 セッションの性質に合わせて見出しを増やし、減らし、名前を変える。

原因究明・障害調査

# {対象}の{現象}の原因調査
## 概要        （何が起き、何が原因で、どう対処したか／しなかったか）
## 症状と切り分け
## 原因
## 対処と残課題
## 参考資料

技術選定・設計検討

# {対象}の{何を}検討
## 結論        （何を選んだか、なぜか）
## 前提と制約
## 検討した選択肢   （選択肢ごとに、採否の理由を添える）
## 未決事項

学習・調べもの

# {テーマ}
## 要点        （分かったことを数行で）
## {テーマに応じた見出し}
## 分からなかったこと
## 参考資料

実装作業

# {対象}に{機能}を実装
## 概要        （何を作り、どこまで動いているか）
## 設計判断     （なぜその作りにしたか）
## 変更点       （ファイルと変更内容）
## 動作確認
## 残作業

参考資料の節は、URLを並べるだけにしない。 そのページのどこが判断の根拠になったかを一行添えると、後から読み返す価値が生まれる。 参照が一つもなかったなら、節ごと省く。

完成前の点検

書き終えたら、保存する前に次を確認する。

1. 冒頭を読むだけで、結論と背景が分かるか
2. 各段落の第1文を拾い読みすると、全体の要約になるか
3. 事実と推測が区別できるか。確認していないことを断定していないか
4. 読み返さないと意味が取れない長文がないか
5. なくてもすむ語が残っていないか
6. ファイル名の {summary} と、デイリーノートのウィキリンクが完全に一致しているか
7. japanese-tech-writing の表記規範（一文一行、ダッシュと中黒の扱い）に従っているか