2026-10-22-01(Build mainly with Claude Code: 茶々入れ 2026-5)
前提条件
本シリーズの元ネタはBuilt with Claude: Japan 2026です。
そもそも趣味勢が全国の250の枠を取り合いに行くのもちょっと顰蹙かなぁと思いまして、勝手に横で走ることにしました。
いまどこ・用語
- 三部品(書く側・置き場の型・読む側)のうち、今回は置き場の型(手順型の見本二号と、叩き台の現行)です。
- 台本=聞き取りの質問集(書く側の正本)/弾=聞き取りの回(第一弾〜第三弾)/芯=台本の基本方針/叩き台=マニュアル書式の案(置き場の型)/見本一号・二号=叩き台を当てて書いたマニュアルの実例/茶々入れ係=横で口を出す他社 LLM たち
- わーさんが解説を入れていない難しそうな言葉=クロードコードさんが調べてきたなんかすごい論文とか(要するにわーさんも咀嚼しきれていないので解説しきれない何か)
ではいつもの前書きを。
yobimizuというプロジェクトの進捗報告です。
目標は、LLMが人間に質問を重ねて引継ぎっぽいものを作り、検索できるようにするシステム。
初回の記事でも書きましたが、本気でClaude Code(以下コードさん)だけで走るといつか提出したくなるであろうことも目に見えていたので、敢えてレギュレーションから脱線する部分もあります。
これは当記事のタイトル見たら察せられますね。
Build mainly with Claude Code: 茶々入れ 2026。
ええ、全力で我が家らしく、あちこちのLLMたちと楽しく茶々を入れていきましょうぞ……!
(※お財布に自信のない皆さまは安易に真似しないようにお願いいたします、マジで)
で、今回のネタは?
前回の記事では、マニュアルっぽいもの第一号ができて、次こそちゃんとした手順として、わーさん宅のWindowsで動いている某PCの再起動後のルーチンを題材に一周してみようという話でした。
結論から言いますと、実際に10/20に走り切りました。
雑記の日付が遅れているのは、そこでわーさんがリアル事情も重なりちょっとダウンしていたからです。
いやあ、横で茶々入れするって決めておいて良かったぁ。
前回のマニュアルとの差
前回は決まった手順が頭の中になかったこともあってちょっともたつきましたが、流石にルーチンはサクサク進みましたね。
どこで作業が大まかに切り分けられるか、どこに注意しているか。
そこに悩むことはほぼなかったです。
一方で面白かったのが「それを間違えたらどうなりますか」とか「どう間違えますか」系の質問。
ルーチン化しすぎて記憶に薄かったり、「す、スキップしちゃうんだろうなぁ???」だったり。
前回は間違った時の記憶もあったから「あーね、それはね」と答えていたものが、逆に「なるほど?」になる瞬間というか。
実聞き取りも最初ここに貼りまくってたんですが、うーんまあ長いのなんのってことで、読み直して消しました。
今回聞き取りはコードさんだけで進めましたが、他のLLMたち(メンツの詳細はこの記事)でもまた走ってみたいところ……いやまあ、本来の企画はコードさんが主役だからこれでも良いのかもですが。
実際のマニュアルは?
こんな感じです。長いので畳みます。
本文長文にて畳み
---
title: Windowsが再起動された後にやるべきルーチン
created: 2026-10-20
updated: 2026-10-20
summary: わーさん宅の Windows ミニ PC が再起動された後に、本人が順にやること。五段と、各段で見る物と、飛ばすと困る所。
aliases: [再起動された後にやるべきルーチン, 再起動後のルーチン, 立ち上げ直し, 再ログイン後, 鯨, ドッカーが詰まっている, Docker が起動しない, オブシディアンジットがオフ, 落ち着くのを待つ, タスクトレイ]
questions:
- 再起動した後に何をすればいいか
- 再起動後に何か忘れていないか
- タスクトレイに鯨がいない
- Docker が詰まった時どうする
- Obsidian の Git プラグインがオフになっている
- bot に話しかけると遅い
- 再起動後にローカル LLM の更新が来ていたらどうする
- 時間がない時はどこまでやればいいか
- bot をいつ落としていつ上げ直すか
- Docker を立て直すのに何が要るか
readers: [再起動時に自信がなくなったわーさん本人]
series: WindowsミニPCシリーズ
related: []
modified: 2026-10-20
---
# Windowsが再起動された後にやるべきルーチン
## 0. この手順書の前提
- 読むのは、わーさん本人です。再起動の直後、画面の前にいて「次は何だっけ」と自信がなくなった時に開いてください。
- 入り口は、再起動が済んで再ログインした所です。出口は、タスクトレイに鯨がいて、常駐の物が上がっている状態です(常駐プログラムの処理、節 5)。
- やらない条件: 時間がない時は、そもそも再起動を後回しにしてください。「時間のないときにパソコンを立ち上げ直すのがおかしい」。時間がなくて焦っている時に手順を飛ばすと、後で原因の分からない不調に悩みます(やらないこと、節 6)。
- この手順書は 2026-10-20 時点の構成で書いています。道具(Obsidian・Docker・bot)が変われば手順ごと変わります。この日の構成は「この日の構成」(節 8)にあります。
- 骨組みも小段も、実機を見ながら語った物ではありません。次に再起動した時に照らして、違う所があれば直してください。〔仮: 実機を見ずに語った〕
### 全体の流れ
五段あります。主語はわーさんです。節の番号と段の番号は同じです。
1. ログイン(節 1)
2. バックグラウンドプログラムの処理(節 2)
3. オブシディアン関連の処理(節 3)
4. ドッカーの処理(節 4)
5. 常駐プログラムの処理(節 5)
大きな流れは毎回同じです。細かい所は状況で飛んだり戻ったりします。順番の決まり:
- オブシディアンはドッカーより先に済ませてください。これは癖ではなく必須です。ドッカーの再起動手順は覚えられないので、オブシディアンのメモを開いていないとドッカーの処理が進みません(段をまたぐ組、節 7)。
- バックグラウンドの更新で bot を落としたら、常駐プログラムの処理で上げ直します。間に二段挟まるので忘れやすい所です(段をまたぐ組、節 7)。
## 1. ログイン
- 再ログインします。これ以上分かれません。
## 2. バックグラウンドプログラムの処理
注意: この段の更新で bot を落としたら、最後の常駐プログラムの処理(節 5)で上げ直すことを忘れないでください。
- 2-1. ログイン時に起動するけれど普段使っていない窓(液タブの管理プログラム・ツアーボックスの管理プログラム・スチームなど)が開いたら閉じていきます。
- 2-2. ローカル LLM 起動のために必要なバックグラウンドプログラムが起動するのを目視します。タスクトレイにアイコンが出る物と、窓として立ち上がる物があります。窓の方は、更新が来ていなければ、普段使っていない窓と同じように閉じて、タスクトレイにアイコンが残っているのを見ます。〔空欄: どのプログラムがどちらの型か〕
- 2-3. ローカル LLM 利用の常駐 bot も、ここで起動していることが多いです。これはわーさんがやることではなく、起きていることです。
- 2-4. ワンドライブやタスクトレイのアイコンが落ち着く(増えたり、アイコンが変化しなくなる)のを待ちます。
- 2-5. ローカル LLM を走らせるプログラムに更新が来ていたら、bot を落とし、バックグラウンドプログラムを更新・再起動します。更新は、窓に出ているか、タスクトレイが通知を出してきます。
- 注意: 先に bot を落としてください。後から落として立ち上げ直しても直りますが、落とし忘れると「更新した」ということ自体を忘れて、エラーに悩むことになります。
- 落とし忘れた時の手掛かり: bot に話しかけるとやたら時間が掛かります。bot は起動時に、規定より多くのコンテキストを準備した状態でローカル LLM を常駐させる仕様です。後からバックグラウンド側(API を担う方)が再起動すると、その準備が無かったことになるからです。
- 時間がなくて焦っている時は、この更新は見送って構いません(やらないこと、節 6)。〔空欄: 見送った更新をいつやるか〕
- 2-6. もう一回タスクトレイを確認します。
- 済んだ合図: ワンドライブの雲アイコンが同期完了の姿で、アイコンが 15 個くらい揃っていて、数秒眺めても増えてこない。〔仮: 15 個は 2026-10-20 時点〕
## 3. オブシディアン関連の処理
注意: 焦っていると、コミュニティプラグインの設定を開いてから Git の同期を見るまで(3-2〜3-5)を丸ごと飛ばすことがあります。飛ばすと Git がオフのまま保管庫を使うことになり、気付く機会がほとんどありません(やらないこと、節 6)。
- 3-1. オブシディアンを起動します。
- 3-2. コミュニティプラグインの設定画面を開きます。コアプラグインではなく、コミュニティプラグインの方です。設定窓がオーバーサイズで、隣のモニターに少しはみ出るので、ドラッグで持ち帰って、改めて最大化ボタンで枠に収め直します。〔仮: はみ出る原因は、Obsidian 用のモニターが他の二枚より少し小さいから、かもしれない〕
- 3-3. 更新確認ボタンを押し、更新があればまとめて更新ボタンを押します。
- 3-4. オフになっているプラグインをオンに切り替えます。ほぼ確実に Git と Templater が、たまにルビ振りプラグインがオフになっています。
- 3-5. Git がファイルを同期するのを目視します。
- 済んだ合図: オブシディアンの画面に小さな通知がポコポコ出ます。
- 3-6. 保管庫の「Dockerが起動しないときの操作」を開きます。次のドッカーの処理(節 4)で見ながら使います。
## 4. ドッカーの処理
注意: この節はオブシディアン関連の処理(節 3)を済ませてからです。そこで開いたメモが無いと、コマンドの送信が進みません(段をまたぐ組、節 7)。
- 4-1. タスクトレイの中に鯨(Docker のアイコン)がいないことを確認します。
- 4-2. ターミナル(パワーシェル)を起動します。
- 4-3. 開いてある「Dockerが起動しないときの操作」の手順に従い、ターミナルにコマンドを 3 回送信します。中身は、Docker 関連のプロセスを全部落とす、WSL をシャットダウンする、Docker Desktop を起動し直す、の三つです。UAC(管理者昇格)が出たら「はい」。〔資料: Dockerが起動しないときの操作。コードさんが書き、わーさんが 2026-06-30 に保管庫に貼った。以後未編集〕〔仮: コマンドはこの手順書に写さず、メモを見る形にした〕
- 4-4. Docker デスクトップが出てくるので、各ドッカープログラムの起動を目視します。一覧に archiveteam-warrior と vault-search が見えて、vault-search をクリックすると中に qdrant_vault と meili_vault が入っています。〔仮: vault-search の綴りは話し手が「多分そう」。構成は 2026-10-20 時点〕
- 4-5. Docker デスクトップは一旦閉じます。開けたままだと、うっかり誤クリックでコンテナを止める可能性があるからです。
- 4-6. タスクトレイに鯨を目視します。
- 済んだ合図: タスクトレイの鯨です。この節は「鯨がいない」で始まり「鯨がいる」で終わります。
- 補足: やる所は、ターミナルの起動とコマンドの送信の二つです。他(鯨がいないことの確認・起動の目視・デスクトップを閉じる・鯨の目視)は確認で、飛ばしても害が少ないです。やる所を飛ばすと、後から保管庫の検索ができなくなっていることに気付くはずです。〔仮: 実際にそうなったことはまだない〕
## 5. 常駐プログラムの処理
注意: バックグラウンドの更新で bot を落としていたら、ここで上げ直してください。落としたことを忘れて飛ばしやすい所です。
- 5-1. ローカル LLM の bot を、ここまでで落としている場合は再起動します。`前略/launch_bot.ps1` を右クリックし、「PowerShell で実行」を選びます。
- 注意: これは Windows でしか動いていません。他の常駐は出先でも代替手段がありますが、これだけは出先から直せません。
- 5-2. Discord が未起動だったり、アップデートが来ている場合は再起動します。窓が出ていなければ未起動です。アップデートが来ていると、右上に更新アイコンが出ています。〔仮: 自動起動していると思われる〕
- 5-3. クロードさんのデスクトップアプリを起動します。
- 5-4. クロードさんのアプリで「ご利用状況」を開きます。主にコードさんの使用量を確認するためです。
- 済んだ合図: ここまでで出口です。
## 6. やらないこと・飛ばしてよいこと
- 時間がない時に再起動しない。「そもそも時間のないときにパソコンを立ち上げ直すのがおかしい」。
- 時間がなくて焦っている時は、ローカル LLM のバックグラウンドの更新(節 2 の 2-5)は飛ばしてよい。事故のもとになりやすいからです。
- 焦っていても、コミュニティプラグインの更新と Git のオン(節 3 の 3-2〜3-5)は飛ばさない。飛ばすと気付く機会がほとんどありません。気付く経路は、スマホから GitHub のコミットを見に行って更新が無いことに気付くか、何かの拍子にコードさんが指摘するか、の二つだけです。スマホは普段リモートシンクで保管庫を見ているので、どちらも滅多に起きません。
- ドッカーの処理(節 4)のうち、確認の段(鯨の確認・起動の目視・デスクトップを閉じる・鯨の目視)は飛ばしても害が少ない。やる段(ターミナルの起動とコマンドの送信)は飛ばさない。
- Docker デスクトップを開けたままにしない。誤クリックでコンテナを止めないためです。
## 7. 段をまたぐ組
離れた段どうしで、片方をやったらもう片方も要る組です。
- バックグラウンドの更新で bot を落とす(節 2)⇔ 常駐プログラムの処理で bot を上げ直す(節 5)。間にオブシディアンとドッカーが挟まるので忘れます。
- オブシディアンで「Dockerが起動しないときの操作」を開く(節 3)→ ドッカーの処理でそのメモを見ながらコマンドを送る(節 4)。オブシディアンが先、ドッカーが後。順番ではなく依存です。
## 8. この日の構成(日付を書かないと嘘になる所)
手順の寿命は道具の寿命と同じです。「全ての手順がほぼそう」なので、節ごとに日付を打つ代わりに、ここに一覧で置きます。2026-10-20 時点。
- 保管庫: Obsidian。コミュニティプラグインに Git・Templater・ルビ振り
- 検索: Docker 上の vault-search(qdrant_vault・meili_vault)。同じ Docker に archiveteam-warrior
- ローカル LLM: バックグラウンドプログラム(API 担当)と、その上で動く常駐 bot(`localLLM-bot`、launch_bot.ps1 で起動)
- Docker の立て直しメモ: 「Dockerが起動しないときの操作」(2026-06-30 貼付、未編集)
- タスクトレイの落ち着いた時のアイコン数: 15 個くらい
- 常駐: Discord、クロードさんのデスクトップアプリ
- 画面: モニター三枚、うち一枚を Obsidian に充てている
- ログイン時に勝手に開く物: 液タブの管理プログラム、ツアーボックスの管理プログラム、スチーム
## 9. 似ているけど別のもの
- 一段大きいまとまりは「WindowsミニPCシリーズ」です(設定欄の series)。
- 似ているけど別の場面として「WindowsのIMEがバグったら」があります(未作成)。
- 再起動の種類(Windows Update の強制・自分で再起動・停電)で手順が変わるかは聞いていません。〔空欄〕
## 10. 空欄
聞き取りで埋まらなかった所です。次に再起動した時に照らして埋めてください。
- バックグラウンド(節 2): ローカル LLM のプログラムのうち、どれがトレイ型でどれが窓型か
- バックグラウンド(節 2): 見送った更新をいつやるか
- ドッカー(節 4): コマンドを手順書に写すか、メモを見る形のままか(仮のまま)
- ドッカー(節 4): 実際にコンテナを誤って止めたことがあるか
- 常駐(節 5): Discord は本当に自動起動しているか(仮のまま)
- 似ているけど別のもの(節 9): 再起動の種類で手順が変わるか
- 全体: 実機を見ずに語った分の抜け(前提、節 0 の仮)
記録:パスを含むので省略
いやあ、何だかちゃんとした手順書だ……!(前回のテーマがひどすぎただけです
因みに上記のマニュアルは実は一回整理された後の物です。背後では、このようなコードさんの記録があったとかなかったとか。
記録四本から本文を書いた(151 行・設定欄 9 項目・節 0〜11)。書式は叩き台と見本一号に合わせた。
わかりやすさの確認(読み手=話し手本人):
話し手: すごいちゃんとマニュアルっぽい!
話し手: 詰まったところというか、手順を数字で示されると迷子になりますね……
〔確認の結果。本文の参照(「3-5 で落とした bot を 6-1 で」「4-2 から 4-5 を飛ばす」「節 7」)が、読む人には案内になっていなかった。番号は索引と反応のための名前であって、人の案内は言葉。→ 本文の参照を全部「言葉を先、番号は括弧で後ろ」に直した。例: 「コミュニティプラグインの設定を開いてから Git の同期を見るまで(4-2〜4-5)」「やらないこと(節 7)」〕
〔書式への持ち帰り: 叩き台 §3 の「(節 7)と書く」は機械の都合。人向けには見出しの言葉を添える決まりが要る。小段の行頭の番号(3-1 など)は「残して問題ない」(話し手)。迷子になるのは文中の参照で、行頭の名前ではない〕
〔書式への持ち帰り 2: 見本一号の慣例(節 0 前提・節 1 全体の流れ)だと段 N が節 N+1 になり、聞き取りで呼んでいた「2-5」が本文で「3-5」になる。番号が名前なら、段と節を揃える方が人にも機械にも楽。見本二号の書式の論点〕〔引継ぎ記載後に続けて見本二号へ: 本文を段=節に組み直した(節 0 に全体の流れ、節 1〜5 が段、小段は 2-5 のように記録と同じ番号に戻った)。書式の論点は叩き台 §11・§12〕
なお、叩き台の現状
正式な題としては:置き場の型(マニュアルの書式)— 叩き台(サブエージェント案・2026-10-19。2026-10-20 に見本二号の結果 §11・§12 を本体が §1〜§7 に畳み込み、わーさん了承済み)
まあ、これも前回の記事で長すぎるから載せないって書いたものではあるんですが、今回は本文が薄いので、伏せて載せちゃうことにします。
本文長文にて畳み
案であって決定ではない。材料は台本第二稿・聞き取り02 の三本(本文と記録二本)・聞き取り01 メモの二節・refs/README・imozuru の印と見本・引き継ぎの未決と段取り 2-2。新しく探していない。「要相談」は決めずに両案を置いた所で、「寄り」はコードさんの傾き。
1. フォルダ構成
<置き場>/
manuals/ … マニュアル本文。1 ファイル=1 題材(聞き取り一本の出来上がり)
<題名>.md
records/ … 聞き取りの記録。1 ファイル=1 回(弾)。索引は読まない
<題名>/<日付>-<弾>.md
reactions.md … 引いた答えへの反応・渡す時の一言(追記のみ。§7)
reader.html … 読む側の 1 枚(生成物。手で直さない)
- 索引のコードに渡すのは
<置き場>のパスだけ。読むのはmanuals/*.md。フォルダ名は使う人が変えてよい(コードの引数にする。パスを決め打ちしない) - 単位: ファイル=題材、節=索引の単位。ファイルは人が開く単位、節は検索が落とす単位(DITA の一話題一単位と OHMS の区切りごとの索引の折衷)
- 索引の生成物は
reader.htmlに埋め込む(file://で別置き JSON を読めないことが多い)。要相談: 人が読める中間物index.jsonも並べて出すか。寄り: 最初は埋め込みだけ - 記録は索引に入れない。記録には言い間違い・〔聞き手の整理〕・未確認がそのまま残っていて、検索に出すと答えに混ざる。記録へは本文から辿る(§5)
2. 設定欄(frontmatter)
台本の 6 項目を芯にして 3 つ足す。
---
title: 題名(話し手の言葉から。ファイル名と同じ)
created: 2026-10-19
updated: 2026-10-19
summary: 一文の要約
aliases: [別名, 読み手の言い方, 画面の文字]
questions: [こう聞かれたらこれを出す, …]
readers: [誰が読むか]
series: 一段大きいまとまりの名前
related: [似ているけど別の物の題名, …]
---
| 項目 | 意味・書き方 | 索引の使い方 |
|---|---|---|
| title | 題名。ファイル名と一致させる | 結果の見出し。参照の宛先(§5) |
| created | 初版の日。改訂しても変えない | 「いつの話か」を結果に添える |
| updated(足す) | 最後に直した日。無ければ created を使う。道具に依存する題材で「日付が要る所が全部」なら、本文に任意の節「この日の構成」(§3)を置き、updated は本文を直した日に使う | 同上。締めの札「日付を書かないと嘘になる所」の受け皿 |
| summary | 一文。DITA の shortdesc と同じ役 | 結果の一行目。本文を開く前の当たり |
| aliases | 採らなかった言い方(NDL の「を見よ」)。言い換えずそのまま | 検索語に当てる。title と同じ重さ |
| questions | 想定質問。質問文のまま | 検索語に当てる |
| readers | 読み手。複数可。LLM も人も | 結果の絞り込み |
| series(足す) | 上位語(NDL の BT)。無ければ省く | 結果をまとまりで束ねる |
| related(足す) | 関連語(RT)。無ければ省く | 結果の末尾に「似ているけど別」を出す |
- 足した理由: series・related は締めの札「一段大きいまとまりは?」「似ているけど別の物は?」の答えの置き場。本文の節に書くだけでは機械で束ねられない
- 足さなかった物: 型(手順/仕組み/心得)… 混ざる題材が多く、索引が使わない/状態(下書き等)… 空欄の節(§3)で分かる/話し手名… 公開の可能性があるので既定にしない
- 独自ルールの余地: 上の項目以外は索引が無視する。使う人は好きな項目を足してよい(例: Obsidian の
tags:。聞き取りの記録が既にそうなっている)。既定の項目の意味は変えない - 書き方の縛り(§6 のため): 1 行 1 項目、値は 1 行、一覧は
[a, b]。項目の中に,を使わない(読点は、)。-の箇条書きも許す(questions が 10 を超えると 1 行は読みにくい。1回目のネタは 11、再起動は 10。二号で採用・10-20 確定)
3. 本文の決まり
# 題名を 1 つ。節は## 番号. 見出し。節の中の###は許すが索引の単位にしない- 節の粒度: 検索から直接飛び込まれて、前の節を読まずに分かる大きさ。手順なら一つの段、仕組みなら一つの部品、心得なら一つの教え
- 番号は改訂しても変えない。番号は順番ではなく名前(読む側の記録と反応が「題名+節番号」でつながる前提)
- 足す時: 未使用の次の番号。並びは番号順でなくてよい(途中に挟んでよい)
- 消す時: 見出しを残して「(廃止。節 N へ)」の一行。番号を使い回さない
- 割る時: 元の番号は片方が引き継ぎ、もう片方は新番号
- 節 0 は前提(推奨・番号固定): 誰が読むか・いつ読むか・入口と出口・揃っている物(環境・道具・権限)・やらない条件(人に戻す所)・「分からなければ止まって聞く」の一文(読み手が本人なら「次にやる時に照らして直す」)。読み手に LLM が入る時は必須(台本 芯 5)。全体の流れ(段の一覧・順番の揺れ・依存)は節 0 の中に
###で含めてよい。手順の型ではそうして、段 N = 節 N に揃える(聞き取りで呼んだ番号と本文の番号がずれない。10-20 二号) - 最後の節は「空欄」(見出しの語を固定): 埋まらなかった所の一覧。各行に節番号を添える。「後で埋める/空けたまま」の答えもここに
- 手順の節の中の順: 注意 → 指示 → 補足 → 済んだ合図(DITA・台本 芯 4)。行頭の札で書く
注意: …その節で効く物だけ。節をまたいだら繰り返す。短く保つ(かさばる繰り返しは嫌われる)済んだ合図: …何を見れば終わったと分かるかやらない: …節 0 にまとめず、効く節に置く時
- 解説(なぜ)は手順の流れを止めず、節の後ろか別の節へ。一文一義・三つ以上は箇条書き・読み手一人に能動で
- 文中の参照は見出しの言葉を先に、番号は括弧で後ろ: 「やらないこと(節 6)」「コミュニティプラグインの設定を開いてから Git の同期を見るまで(3-2〜3-5)」。数字だけ(「3-5 で落とした bot を 6-1 で」「(節 7)」)だと読み手が迷子になる(10-20 二号・本人の指摘)。機械が拾う形(§6)は括弧の中に残るので壊れない
- 手順の節の中の小段は、行頭に
- N-M.(節 N の M 番目)を置いてよい(任意。索引は拾わない。人と反応の行が指すための名前。行頭の番号は迷子の元にならない、と本人) - 任意の節(型が合う時だけ): 「全体の流れ」(節 0 に含めてよい)/「やらないこと」/「段をまたぐ組」(離れた節どうしの依存・対。片方をやったらもう片方も要る)/「この日の構成」(使っている道具の一覧と日付。道具に依存する題材で、節ごとの日付の代わり)/「似ているけど別のもの」(related の説明)
- 仮と空欄の印(本文で必須・形を固定):
〔仮: 理由〕〔空欄: 何が無いか〕。理由が無い時も〔仮〕〔空欄〕。読む側が節ごとに「仮あり・空欄あり」を出せる - 別名を本文に残す形: 話し手の言葉を本文で言い換えない(台本 芯 1)。正式な言い方を決めた時は初出で「正式(話し手の言い方)」と並記し、話し手の言い方は aliases にも入れる。要相談: OHMS のように節ごとのキーワード欄を置くか。寄り: 置かない(本文の言葉を全文検索で拾えば足りる。要るなら二周目)
- 読み手がしない段(相手・機械・他人が動く段)は、そう書いて短く済ませてよい
4. 出どころの印
- 出どころ(誰が言ったか)と確かさ(どこまで固まったか)を分ける。確かさの印は §3 の〔仮〕〔空欄〕
- 出どころの印は 記録では必須、本文では任意。本文の既定は書き手が責任を負う一つの声(一般の指針 4 本の側)。本文に残すのは話し手が望んだ時(わーさん流の列)
- 印。imozuru の〔論文〕〔本人〕〔観察〕〔まとめ〕〔公式〕は資料の種類の印なので、聞き取り向けに「話し手からの距離」の印に置き換える:
| 印 | 意味 | 記録での形 |
|---|---|---|
| (印なし) | 話し手が自分でやった・確かめた | **話し手:** の引用そのまま |
| 〔伝聞〕 | 話し手が人から聞いただけ | 引用の末尾に付ける |
| 〔資料: 名前〕 | 見せてもらった物・既にあった文章から | 「ここは誰が書きましたか」を聞いてから付ける |
| 〔聞き手: …〕 | 聞き手の整理・推測 | 〔 〕で囲む。推測は末尾に「? 未確認」 |
- 現行の記録は〔 〕=聞き手で足りているので
聞き手:の頭は省いてよい。新しく足すのは〔伝聞〕〔資料〕だけ - 本文に出す時は文末に
〔伝聞〕〔資料: 名前〕。〔聞き手〕は本文に出さない(確かめて印なしにするか、〔仮〕にする) - 〔資料: 名前〕は 10-20 の二号で本文に初めて出た(「誰が書きましたか」を聞いて、書き手・貼った人・日付が揃った)ので確定。〔伝聞〕はまだ出番がなく保留(手順の題材でも出なかった。仕組み・心得の題材で見る)
- 機械で読む分: 全部
〔…〕の形。索引が数えるのは〔仮〕〔空欄〕だけで、他は人向け
5. 参照・シリーズ・似て非なる物
- 同じマニュアルの中: 本文に「(やらないこと、節 7)」のように見出しの言葉を添えて書く(§3)。読む側は「節 7」を節へのリンクにできる
- 別のマニュアルへ:
[[題名]]。節を指す時は「[[題名]] の節 3」と言葉で。要相談:[[題名]]か[題名](題名.md)か。寄り:[[ ]](Obsidian で開く人が多く、正規表現で拾いやすい。読む側は両方拾ってよい) - 宛先は題名=ファイル名。題名を変えると参照が切れるので、変える時は aliases に旧題名を残す。番号 ID は足さない(設定欄が増え、人が参照を書く時に引けない)
- 記録への参照: 本文の末尾に「記録: records/<題名>/」の一行(任意)。記録から本文へは記録の冒頭に
[[題名]] - シリーズ:
series:に名前。シリーズ自体の案内が要る時は、同じ名前のマニュアルを 1 本書く(節 0 に子の一覧)。要相談: シリーズをフォルダにするか項目にするか。寄り: 項目(フォルダだと一本が二つのシリーズに入れない) - 似て非なる物:
related:に題名、違いは節「似ているけど別のもの」に一言。まだ書かれていない物は related に入れず、節の中に「(未作成)」
6. 機械で拾う所(実装は書かない)
| 拾う物 | 書式のどこ | 形 |
|---|---|---|
| 設定欄 | 1 行目の --- から次の --- まで |
key: value 1 行 1 項目。一覧は [a, b](- 行を許すなら両対応)。知らない key は無視。YAML の全機能は要らない(標準ライブラリで足りる) |
| 節 | ^## (\d+)\. (.+)$ |
番号・見出し・次の ## までの本文。### は本文の一部 |
| 題名 | 設定欄の title | # の行は使わない(ずれても壊れない) |
| 仮・空欄 | 〔仮 〔空欄 で始まる印 |
節ごとに数える |
| 札 | 行頭(- の後も可)の 注意: 済んだ合図: やらない: |
任意。読む側で目立たせるだけ |
| 節内参照 | 節 ?(\d+) |
同じファイルの節へ |
| 外部参照 | \[\[([^\]|#]+) |
題名→ファイル |
| 反応 | reactions.md の行(§7) |
題名と節番号で本文に結ぶ |
- 索引の 1 件=1 節。各件にファイルの設定欄(summary / aliases / questions / readers / series / updated)を写して持たせる(OHMS の区切りが題・要約・キーワードを持つ形)
- 文字コードは UTF-8(BOM があっても落ちない)。改行は LF でも CRLF でも
7. 改訂の余地(最小限)
- 日付は
updated:だけ。履歴は置き場の仕組み(git・Obsidian の履歴など)に任せ、書式では持たない -
反応の置き場:
<置き場>/reactions.mdに 1 行追記。読む側が 1 行の文字列を出し、人がコピーして貼る(サーバーなしの帰り道)- 2026-10-20 | 鯨がいない | Windowsが再起動された後にやるべきルーチン | 節 4 の 4-1 | 役に立った | - 2026-10-20 | IME 壊れた | | | | 出なかった- 区切りは
|。2 つ目は検索語(§10 の足す物。出なかった検索語はここだけ埋めて他を空にする)。4 つ目は「節 N」か「節 N の N-M」か空(機械は節番号だけ読む)。5 つ目は 役に立った/部分的/見当違い/渡した(渡す時の一言もこの行)。6 つ目は一言 - 見直しの合図: 同じ題名・節番号に「部分的」「見当違い」が溜まった所から直す(KCS「使われることが見直し」)。引かれない節は直さない
- 要相談: 反応を 1 ファイルに集めるか、
records/<題名>/に題材ごとに分けるか。寄り: 1 ファイル(追記先が一つ・索引が読む物が一つ) - 改訂で本文を直したら、空欄の節から消す・〔仮〕を外す・updated を直す。番号は触らない
- 区切りは
8. 確かめ(1回目のマニュアルを当てた時)
合わない・足りない所(書式側で受ける):
updatedseriesrelatedが無い。「わーさんを甘やかすシリーズ」が aliases と節 11 に書かれている → series へ移す。似て非なる物は題名が無い → related は空、節 11 に「(未作成)」- 仮・空欄の印の形がばらばら(〔仮〕〔仮。具体例は出ていない〕〔それ以上は空欄〕〔飛ばす時の見分けは空欄〕)→
〔仮: …〕〔空欄: …〕に揃える - 節 12「空欄」に節番号の無い行がある(「3・4・5 を飛ばす時の見分け」→ 節 1)
- questions が 11 個で 1 行 →
-の箇条書きを許すか(§2 要相談)に関わる - 読み手 LLM の「前提(どの環境でも同じか)」が節 0 でなく空欄の節に落ちている → 書式は空欄として正しく受けている
- 合っていた所: 節 1 の「(節 2)」の形/「注意:」が節 0 と節 9 で繰り返されている/節 2・8 が一行(読み手がしない段)/本文に出どころの印が無い(一つの声)/記録は〔 〕のみで〔伝聞〕〔資料〕の出番がなかった
1回目のネタ特有で、一般の決まりにしてはいけない所:
- 「主語は LLM です」「わーさん側のアクション」: 読み手が手を動かさない段がある、は手順一般にもあるが、その書き方(主語の明記)までは決めない
- 読み手が LLM 一人: 書式は人・複数の読み手も受ける(readers が一覧なのはそのため)
- 準備する物・助けてくれる相手・画面の文字が無い: 手順・仕組みの型では出る。節 0 と aliases に置き場はあるが、項目として強制しない
- 心得が多く手順が短い: 手順の型で「注意 → 指示 → 補足 → 済んだ合図」の順が効くかは、この題材では確かめられていない
9. 決めた理由
| 決まり | 元にした材料 |
|---|---|
| ファイル=題材、節=索引の単位 | DITA の一話題一単位・OHMS の区切りごとの索引(refs/README)、引き継ぎ未決「索引単位は節」 |
| 設定欄の 6 項目 | 台本 芯 4 |
| summary を結果の一行目に | DITA の shortdesc(聞き取り01 メモ・先人その2) |
| aliases=を見よ、series=上位語、related=関連語 | NDL 件名標目表(refs/README、聞き取り01 メモ) |
| updated | 締めの札「日付を書かないと嘘になる所」 |
| 知らない項目は無視 | 原則「置き場は使う人が決める」(AGENTS.md)、記録の tags: が既に独自項目 |
| 番号は名前・改訂しても変えない | 台本 芯 4、引き継ぎ未決「節ごとに変わらない番号」 |
| 節 0 前提・「止まって聞く」 | 台本 芯 5、甘やかし節 0 |
| 注意 → 指示 → 補足 → 済んだ合図、注意は節ごと・短く | DITA の手順の順、聞き取り01 メモ「注意は節ごと」「前述は同じページの中」「長さの但し書き」 |
| 解説は流れを止めない・一文一義・能動 | Diátaxis・やさしい日本語・平易な文章の指針(聞き取り01 メモの「一致」の列) |
| 本文は一つの声、印は望んだ時 | 聞き取り01 メモ「確かさの印」はわーさん流の列、台本 芯 4「流儀は望んだ時だけ」 |
| 記録では出どころ必須 | 台本 芯 1・芯 4、引き継ぎ「記録の段階で出どころを分ける」 |
| 印の形 〔…〕 | 台本の〔 〕、imozuru の〔本人〕〔観察〕… |
| 反応は 1 行追記、使われた所から直す | KCS「使われることが見直し」、読む側サーバーなし(AGENTS.md) |
| 索引は標準ライブラリで足りる形 | 原則「索引に集めるのはただのコード」 |
| 感情題材に寄せない | 聞き取り01 メモ「既定は一般寄り」、引き継ぎ 2-2 |
10. 本体の判定(2026-10-19・わーさん「幾つか回してみないと判断難しい」)
要相談 7 件は、コードさんの寄りのまま暫定で進める(回して決める。確定ではない): 1 埋め込みだけ/2 - 箇条書きも許す/3 キーワード欄は置かない/4 〔伝聞〕は手順の題材で出番を見てから/5 [[題名]]/6 シリーズは項目/7 反応は 1 ファイル。
足す物(依頼文の漏れ): §7 の反応の行に検索語の欄。構想メモ 2026-10-17-01-03(構想メモ・yobimizu 読む側の出来事の記録と改訂のきっかけ) の「出なかった検索語も一緒に残す」に合わせる。見当違い=別名の不足を直すには、引いた語が要る。形は要検討(例: - 日付 | 検索語 | 題名 | 節 N | 反応 | 一言、題名以降は空でよい=出なかった検索語の行)。
§8 の直しは、1回目のマニュアルに適用済み(updated・series・related の追加、aliases からシリーズ名を series へ、questions を - 箇条書きに、〔仮: 〕〔空欄: 〕の形に統一、空欄の節に節番号、節 11 に「(未作成)」、末尾に記録への参照)。これが見本の一号。
11. 確かめ(再起動ルーチンのマニュアルを当てた時・2026-10-20・本体)
見本二号。手順の型・読み手は本人・小段 22・資料あり。§8 と同じ形で。
合わない・足りない所(書式側で受ける):
- 文中の参照が数字だけだと読み手が迷子になる(わかりやすさの確認で本人が指摘。「3-5 で落とした bot を 6-1 で」「4-2 から 4-5」「(節 7)」)。§3 の「(節 7)と書く」は機械の都合で、人の案内になっていない → 参照は見出しの言葉を先に、番号は括弧で後ろ(「やらないこと(節 6)」「コミュニティプラグインの設定を開いてから Git の同期を見るまで(3-2〜3-5)」)。機械が拾う形
節 ?(\d+)は括弧の中に残るので壊れない。行頭の小段番号(- 2-5.)は「残して問題ない」(本人) - 段と節の番号がずれる。見本一号の慣例(節 0 前提・節 1 全体の流れ)だと段 N が節 N+1 になり、聞き取りで呼んでいた「2-5」が本文で「3-5」になった → 見本二号では「全体の流れ」を節 0 の中の
###に入れ、段 N = 節 N に揃えた。§3「節 0 は前提」に「全体の流れを含めてよい(### で)」を足す。見本一号は節番号を既に使っているので触らない(番号は名前) - 日付が要る所が「全部」の題材(道具に依存する手順。「オブシディアンを使わなくなればその部分は変わる」)。節ごとに日付を打つ形も updated 一つも合わない → 任意の節「この日の構成」(使っている道具の一覧と日付)を書式に足す。updated は残す(本文を直した日)。created と「この日の構成」の日付は別物になりうる
- 〔資料: 名前〕を本文で初めて使った(4-3。コードさんが書きわーさんが貼った 6/30 のメモ)。§4 の要相談「四種にするか」に実例が一つ。〔伝聞〕はまだ出番なし → 印は〔資料〕を先に確定、〔伝聞〕は保留のまま
- 小段の番号の形:
- N-M.を行頭に置いた(節 N の M 番目)。§6 は拾わない(索引の単位は節)。人と反応の行が指すための名前として任意で許す。要相談: 反応の行の「節 N」に「節 N の N-M」まで書けるようにするか。寄り: 書けるようにする(文字列なので機械は節番号だけ読めばよい) - 「観察」の段(話し手の動作でない段。2-3「常駐 bot もここで起動していることが多い」): 「これはあなたがやることではなく、起きていることです」の一文で済ませた。§3「読み手がしない段はそう書いて短く」で受かる。印は要らない
- 「やる段」と「見る段」を話し手が自分で分けた(段 4)。本文では「補足: やる所は〜の二つ。他は確認で、飛ばしても害が少ない」。札にはしない(題材による)
- 塊に付く注意(3-2〜3-5 が丸ごと飛ぶ): 注意は節の冒頭に一つで足りた。§3「注意はその節で効く物だけ」で受かる
- 合っていた所: 設定欄 9 項目(series・related を最初から使えた)/questions を
-箇条書き(10 件)/〔仮: 〕〔空欄: 〕の形/空欄の節に節番号/末尾に記録四本への[[ ]]/注意 → 指示 → 補足 → 済んだ合図の順が手順の型で素直に書けた(§8 で「確かめられていない」とした所)/任意の節「やらないこと」「似ているけど別のもの」に加えて「段をまたぐ組」を立てた(§3 の任意の節の例に足してよい)
再起動ルーチン特有で、一般の決まりにしてはいけない所:
- 環境情報(パス・コンテナ名・モニター三枚・プログラム名)が本文に入る。置き場が本人の保管庫なので問題ないが、リポの見本にする時は合成に置き換える(AGENTS.md の禁則)。置き換えても「この日の構成」の形が残るかが、見本として出す時の見所
- 「鯨」「ポコポコ」「オーバーサイズ」は話し手の言葉。aliases と本文に残したが、書式はこれを強制しない(台本 芯 1-5 の結果)
- 読み手が本人一人で芯 5(LLM 読み手)を使っていない。「分からなければ止まって聞く」の代わりに「次に再起動した時に照らして直す」を節 0 に置いた。読み手が本人の時の節 0 の形として一例
12. 暫定 7 件の見直し(2026-10-20・本体。二号を当てた後)
| # | 暫定 | 二号での実績 | 判定 |
|---|---|---|---|
| 1 | 索引は埋め込みだけ | 出番なし(読む側は未着手) | 据え置き |
| 2 | questions は - 箇条書きも許す |
10 件を - で書いた。読みやすい |
採用寄りを強める |
| 3 | 節ごとのキーワード欄は置かない | 「鯨」「ポコポコ」が本文にあり、全文検索で拾える | 据え置き |
| 4 | 〔伝聞〕は手順の題材で出番を見てから | 〔資料〕は出た、〔伝聞〕は出なかった | 〔資料〕を先に確定。〔伝聞〕は保留 |
| 5 | 参照は [[題名]] |
記録四本への参照で使用 | 据え置き |
| 6 | シリーズは項目 | series: WindowsミニPCシリーズ。フォルダにしなくて済んだ | 据え置き |
| 7 | 反応は 1 ファイル | 出番なし | 据え置き |
新しく足す物(§11 から): 文中参照は見出しの言葉を先に/節 0 に全体の流れを含めてよい(段=節)/任意の節「この日の構成」/〔資料〕の確定/小段番号 N-M. を任意で許す/任意の節の例に「段をまたぐ組」。どれも案。茶々入れ係に見せる前に、わーさんが一度読む。
→ 2026-10-20 夜、わーさん了承済みで §1〜§7 に畳み込み済み(§2 箇条書き確定・updated の但し書き/§3 節 0 に全体の流れ・段=節・参照は言葉先・小段番号・任意の節に「段をまたぐ組」「この日の構成」/§4 〔資料〕確定・〔伝聞〕保留/§5 参照の形/§7 反応の行に検索語と小段)。§8〜§12 は経緯として残す。次に直すのは茶々入れ係の指摘が来てから。
次回どうするの?
今後ですが、一応最低限のマニュアルサンプルが作成できたので、実際にBuilt with Claude: Japan 2026が11/2に始まるまでは、質問とマニュアル作成の叩き台を他茶々入れさんたちとも走ってみての、ブラッシュアップしつつマニュアル候補を増やしていく感じかなぁと思います。
で、ハッカソン期間が始まったら、一番最初に検討した通り、コードさんにコードそのものを書く作業……すなわち検索・表示システムを作成してもらって、実際に検索できるものなのか、テストする感じですね。