ChatGPTやCodexに相談する機会が増えると、それらの相談内容がどのセッションに含まれるのか分からなくなり、キーワードで検索したりする。また、プロジェクトに関連するセッションをまとめてプロジェクト名で区別しやすくしようとするが、1つのセッション内に複数の相談を含めてしまうこともある。また、各相談の結果、つまり、回答で得られた内容を実行することにしたのか、保留としたのかなど、「その後、自分はどうすることにしたのか」を残したくなります。
AIに設定方法を調べてもらった。いくつかの案を比較してもらった。実機で確かめる項目も整理できた。しかし数日後には、その相談がどのセッションに入っていたのか、採用した案はどれだったのか、まだ実行していない作業は何だったのかを探し直している。相談が増えるほど、こうした振り返りが難しくなります。
そこで、ChatGPTとCodexの相談履歴を、相談テーマごとのObsidianノートに整理し、要約・元チャットへのリンク・自分の判断・予定・タスクを一緒に管理する仕組みを考え、Codexに実装を依頼しました。
初回の実装では、正式ノート10件とAI抽出タスク20件を保存できました。さらに、判断状況に応じて表示を切り替える「相談一覧」を追加し、毎日午前3時にSkillを実行する設定まで進みました。
ただし、取得できた履歴の範囲や、手編集を保護できる範囲には制約もあります。本記事では、構想から実装までの相談の流れをたどりながら、できたこと、確認できたこと、今後改善したいことを整理します。
注）本記事の内容は正確性を保証するものではありません。
（2026年9月4日 追記）YouTube動画を追加しました。 https://youtu.be/BVgo4WEYNCc
1. 最初の相談は「直近2週間の相談を一覧にしたい」だった
出発点は、過去の相談を振り返るための表を作りたい、という依頼でした。
対象は直近2週間のChatGPTとCodex。チャット名称、相談日時、質問・回答の要約、元チャットへのリンクを一覧で確認できる形を考えました。
この段階から、数え方には条件を付けていました。
- 1つのセッションに別のテーマが含まれていれば、別々の相談として扱う。
- 同じテーマを掘り下げる連続したQ&Aは、1つの相談としてまとめる。
例えば、Home Assistantの更新について話すチャットでも、「更新内容を理解すること」と「比較記事のために事前撮影する画面を決めること」は、後から別々に参照したくなる内容です。
一方、Obsidianの同期について「iPhoneではどうか」「Mac miniではどうか」「アプリを閉じても動くか」「常時稼働ならどの方式を使うか」と質問を重ねた場合は、一連の検討として読む方が自然です。
大事なのは、会話の往復数ではなく、何を理解し、何を決めようとしていたかを単位にすることでした。
最初のChatGPTの回答では、2026年8月21日〜9月3日の相談が表に整理されました。
しかし、元チャットのURLは取得できず、「取得不可」として残りました。
相談の要約ができることと、その出典へ確実に戻れることは別の課題だったのです。
表から、後で育てられるノートへ
一覧表は全体を把握するのに便利ですが、個々の相談へ判断や予定を書き足すには、1テーマ1ページの方が扱いやすくなります。
そこで次に、相談テーマごとにObsidianページを作ることと、Codexから元チャットのリンクを取得できるかを相談しました。
この段階で、整理先はMarkdownファイルを置くObsidian Vault、作業担当はそのフォルダへアクセスできるCodex、という方向が固まりました。リンクについては取得できる情報を確認し、分からないURLは作らない方針にしました。
2. 「回答の保存」に、自分の判断と予定を加える
ノート化の案に対して、さらに追加したかったのが次の内容です。
- 提案を採用するか、一部だけ採用するか、保留するか。
- 実行するか、検討後に実行するか、実行しないか。
- いつ実施する予定か。
- 相談の範囲内で、今後の課題や未完了タスクがあるか。
- タスクにはチェックボックスを付ける。
例えば、AIが「更新前にバックアップを取るとよい」と答えたとしても、それだけで本人が更新を決めたことにはなりません。「その案を採用する」「今回は実施しない」といった判断を、回答とは分けて記録したいと考えました。
そこで、ページは大きく4つの役割を持つことにしました。
| 役割 | 残す内容 |
|---|---|
| 相談の記録 | 何を確認したかったか、どんな質問をしたか |
| 回答の整理 | 得られた結論、条件、注意点、検討の経緯 |
| ユーザー判断 | 採用・保留などの判断、実行可否、コメント、予定 |
| 行動の管理 | AIが抽出した課題と、自分で追加したタスク |
AIは、本人が明確に述べた判断や完了報告を反映できます。ただし、曖昧な発言から「採用」「完了」と決めてはいけません。判断が分からないときは「未判断」のままにすることを指示しました。
タスクを増やしすぎない
回答に出てきた行動をすべてタスクにすると、実施するつもりのない作業まで一覧に並んでしまいます。
タスク候補にするのは、追加調査、実機確認、設定変更、撮影、テストなど、相談の文脈で必要性や本人の実行意図が確認できる事項です。「後で確認する」「次に試す」と明示された作業も対象になります。
一方、単なる参考例、一般的な注意事項、AIが可能性として挙げただけの案、用語の説明だけで完結した質問は、原則として未完了タスクにしません。完了したことが明確な作業は、必要に応じてチェック済みの記録として残します。
こうして、相談を読めば「何を知ったか」と「何が残っているか」の両方が分かる構成にしました。
3. Codexへ渡した指示書で、先に決めておいたこと
ここまでの相談を実装へつなげるため、ChatGPTにCodex向けの指示書を作ってもらいました。
元の相談もコンテキストとして渡し、仕様の背景を参照できるようにしています。
指示書は、ページの見た目だけでなく、履歴の取得方法、相談の分割、元URL、更新時の保護、テストまで含む内容になりました。
| 項目 | 指示したこと |
|---|---|
| 整理単位 | 1相談テーマにつき1ページ。連続Q&Aは不要に分割しない |
| 対象期間 | 初期運用は直近14日。日数や日付範囲を指定できる構成 |
| 出典 | 相談日、サービス、チャット名称、URL、識別IDを記録 |
| 保存場所 | 既存Vaultを確認し、相談記録を年・年月で整理 |
| ユーザー判断 | 明示された事実以外は勝手に確定しない |
| タスク | AI抽出分とユーザー追加分を分ける |
| 更新 | 重複を防ぎ、手入力と完了チェックを保持する |
| 関連ノート | 関連の強い相談を内部リンクで結ぶ |
| 全体の把握 | 判断状況や未完了タスクを確認するダッシュボードを作る |
| 安全確認 | dry-run、少数テスト、正式保存、再実行確認の順で進める |
| 継続利用 | Skillとして呼び出せる形にする |
特に重視したのは、更新するたびに、自分が書き込んだ内容が消えないことです。
一度きれいなノートを作れても、次回の同期で判断やチェックが初期化される仕組みでは使い続けられません。
自動生成する部分と、人が編集する部分を分けるルールを、実装前から明確にしました。
指示書の要点を短く書くなら
以下は、実際の長い指示書を記事向けに再構成した要約版です。元指示書の全文引用ではありません。
ChatGPTとCodexの相談履歴を、相談テーマ単位でObsidianへ整理する。
同じテーマの連続Q&Aはまとめ、明確に異なるテーマは分ける。
各ノートに、相談日、元サービス、チャット名称、確認できたURL、
質問・回答の要約、相談の経緯、関連ノートを記録する。
URLが取得できない場合は空欄とし、未解決であることを残す。
ユーザー判断、実行可否、判断コメント、予定を追記できる欄を設ける。
AIは本人の判断を推測して確定しない。
タスクはチェックボックス付きにし、AI抽出分とユーザー追加分を分ける。
再実行では既存ノートを識別し、手入力欄と完了チェックを保持する。
更新前のバックアップと実行ログを残す。
まず書き込みなしのプレビューを行い、3〜5件をテストフォルダへ出力する。
確認後に正式保存し、同じ入力で再実行して重複がないことを確かめる。
最後に継続利用できるSkillとしてまとめる。実装依頼で追加した条件
実装時には、Vaultを次の場所に指定しました。
/Volumes/TEKQPHYE748/obsidian/ssd_vaultまた、ブログ用の横長アイキャッチ画像の作成依頼や、スラッグ提案依頼などは、相談記録から除外するよう追加しました。
記事制作では細かな依頼が多く発生します。これらをすべて意思決定用ノートとして残すより、後で検討を再開したい相談を中心にしたかったためです。
実装された除外ルールは、画像・スラッグに加えて記事構成、図解・挿絵、画像形式変換なども対象にしています。
この範囲は今回の運用に合わせたものです。構成検討そのものを知識として残したい場合は、除外条件を見直す必要があります。
4. 実装は「相談を読み解く処理」と「ファイルを更新する処理」に分かれた
Codexの実装記録で特徴的だったのは、すべてを1本のプログラムへ詰め込まず、役割を分けたことです。
前半では、Codexがアプリのチャット・タスク一覧と本文を読み、対象期間の相談を選びます。そしてテーマを分け、質問・回答を要約し、タスク候補を整理します。
後半では、その結果をJSONの「マニフェスト」にまとめ、PythonのCLIへ渡します。マニフェストとは、各ノートに何を書くかを整理した中間データです。
Python側は、日付範囲による絞り込み、除外判定、既存ノートとの照合、Markdown生成、バックアップ、ログ保存を担当します。
Pythonだけ実行しても、新しい会話は取得されない
この役割分担は運用時にも重要です。
同じマニフェストを使ってPythonを再実行した場合、保存済みの相談データを再反映するだけです。新しいチャットを見つけるには、その前にCodexが履歴を読み、マニフェストを更新する工程が必要になります。
「保存用スクリプトの再実行」と「履歴取得から始めるSkillの実行」は、処理する範囲が違います。
保存先の構成
主な配置は次のようになりました。.backupsは既存ノートを更新するときに作られる退避先です。
ssd_vault/
├── 相談記録/
│ ├── 2026/
│ │ ├── 2026-08/
│ │ └── 2026-09/
│ │ └── YYYY-MM-DD 相談テーマ.md
│ ├── 相談管理ダッシュボード.md
│ ├── 相談一覧.md ← 後から追加
│ ├── _logs/
│ └── .backups/
├── 相談記録_TEST/
└── 06_Scripts/
└── sync_ai_consultations_to_obsidian/
├── sync_consultations.py
└── manifest.jsonSkill名はsync-ai-consultations-to-obsidianです。個人のSkillフォルダへ配置され、同期スクリプトとマニフェストの仕様も同梱されました。
5. 1つの相談ノートには、何が入るのか
実装では、ノート先頭にFrontmatterを置きます。これは、タイトルや日付、出典などを本文とは別に記録する領域です。
その後に、自動生成領域とユーザー編集領域が続きます。実際の並びは、要約・AI抽出タスク・関連相談を自動生成領域へまとめ、その下に判断・予定・ユーザー追加タスクを置く形です。
以下は、実装の構造に合わせた説明用サンプルです。相談の内容や予定日は例であり、実データの転載ではありません。
URL未取得の場合を示しています。
---
type: ai_consultation
consultation_id: "example-update-comparison"
title: "更新前後の比較画面を準備する"
date: 2026-09-03
source: "ChatGPT"
source_id: "説明用の識別子"
chat_title: "更新前後の比較について"
chat_url: ""
url_status: "unresolved"
status: "未判断"
tags:
- "Home-Assistant"
- "ChatGPT"
---
<!-- AUTO-GENERATED:START -->
# 更新前後の比較画面を準備する
## 相談内容
更新による変化を比較するため、事前に保存する画面を検討した。
## 質問・回答の要約
### 主な質問
- 更新前にどの画面を記録しておくとよいか。
### 回答要約
- 比較対象を決め、更新前後で同じ条件の画面を残す方針を整理した。
## 相談の経緯
変更点を確認した後、比較に必要な画面の準備へ論点が移った。
## AIが抽出した今後の課題・タスク
- [ ] 更新前の比較用画面を保存する
## 関連する相談
特になし
<!-- AUTO-GENERATED:END -->
<!-- USER-EDITABLE:START -->
## ユーザー判断
### 判断状況
- [ ] 採用
- [ ] 一部採用
- [ ] 保留
- [ ] 不採用
### 実行可否
- [ ] 実行する
- [ ] 検討後に実行
- [ ] 実行しない
### 判断・コメント
<!-- ここに自分の判断を書く -->
### 予定
<!-- 実施予定日や計画を書く -->
## ユーザー追加タスク
- [ ]
<!-- USER-EDITABLE:END -->自分が書く場所が決まっている
日常的に追記するのは、下側のユーザー編集領域です。
例えば「一部採用」にチェックし、コメントに「比較用の撮影は行うが、更新日は後で決める」と書く。
予定には実施日や作業内容を記入する。自分で気付いた確認事項は「ユーザー追加タスク」に足します。
AIが作ったタスクを完了したときは、そのタスクへチェックを付けます。Markdown上では- [ ]が未完了、- [x]が完了になります。
関連ノート欄はあるが、初回はリンク未設定
実装は、マニフェストのrelatedに指定されたノート名を[[ノート名]]形式で出力できます。
ただし、確認した初回マニフェストには関連ノートの指定がありませんでした。したがって、初回から相談同士が自動で網の目のようにつながった、とは言えません。関連欄の器は用意され、内容の付与やリンク先の確認は今後充実させる部分です。
6. 再実行で手入力を消さないための仕組み
更新時に保護する対象は、大きく2つあります。
1つ目は、USER-EDITABLE:STARTとUSER-EDITABLE:ENDで囲んだユーザー編集領域です。既存ノートからこの部分を取り出し、更新後のノートへ引き継ぎます。
2つ目は、AI抽出タスクの完了チェックです。既存ノートに同じ文言のチェック済みタスクがあれば、入力データ上では未完了でも、完了状態を残します。
例えば、次の状態で同期し直しても、同じタスク文言ならチェックを維持する仕組みです。
- [x] 更新前の比較用画面を保存する保護される範囲には境界がある
ここは、構想と初期実装を区別しておく必要があります。
元の指示書では、削除や書き換えもできるだけ保持したいとしていました。しかし、初期実装はタスク本文を照合して完了状態を引き継ぐ方式です。
- AI抽出タスクの文言を変更すると、同じタスクとして認識されない可能性があります。
- AI抽出タスクを手動で削除しても、次回の入力に残っていれば再生成されます。
- 次回のマニフェストからタスク自体がなくなれば、以前の完了タスクを恒久保存する仕組みにはなっていません。
- Frontmatterは入力データから再生成されるため、そこへ直接追記した判断や独自項目は、ユーザー編集領域と同じ保護を受けません。
- 領域を区切るコメントを削除すると、手入力部分の識別ができなくなるおそれがあります。
したがって、自分の判断や補足は指定のユーザー編集領域へ、自由に追加・編集したい作業はユーザー追加タスクへ書くのが、初期版に合った使い方です。
この保護範囲は、実装コードと実装レポートを照合して確認したものです。「どこを書き換えても完全に保護される」とは捉えないようにします。
重複判定はタイトルだけに依存させない
既存ノートの識別にはconsultation_idを使います。入力側のtopic_idがあればそれを利用し、なければ元チャットIDとテーマ名から識別子を作る構成です。
同じ入力を2回処理して重複を作らないことは確認されています。ただし、異なる言い回しの相談を意味の類似性だけで自動統合する実装ではありません。同じ相談には同じtopic_idを維持する運用が重要です。
同日・同名で内容が異なる相談、テーマ名やIDを変更したケースなどは、今後追加で検証したい条件です。
7. 元チャットURLは、確認できた識別情報から記録する
元の相談ではリンクを取得できませんでしたが、Codexの実装ではアプリから会話IDを取得できたChatGPT会話について、通常チャットURLを記録できました。
この場合は、url_statusをresolved_from_conversation_idとし、確認できたIDを使っていることを残します。
一方、Codexタスクではアプリ内のsource_idを保持し、実際のURLを取得できなければchat_urlを空欄にする方針です。ChatGPTのURL形式をそのままCodexタスクへ当てはめることはしません。
今回の実装レポートでは、ChatGPT通常URLは10件と報告されています。ただし、これはIDに基づいてURLを記録できた件数であり、10件すべてのリンクを開いて到達確認したという意味ではありません。
また、初回の正式ノート10件は、マニフェスト上ではすべてChatGPT由来でした。ChatGPTとCodexを扱う設計ではありますが、両方の実データを同じだけ取り込んで検証した結果ではありません。
8. 実装中に分かったこと――日付指定だけでは履歴を網羅できない
今回の大きな制約は、履歴の取得範囲でした。
元の相談は9月3日を基準にしていたため、直近2週間は8月21日〜9月3日でした。実装は翌9月4日に行われ、CLIで指定した期間は8月22日〜9月4日になっています。
しかし、その実装時に使ったCodexアプリの一覧取得は最大50件で、一覧上で確認できた最古の項目は8月27日でした。初回の相談は、その一覧から本文を読めた範囲で選ばれています。
| 区別すべき範囲 | 今回の内容 |
|---|---|
| 最初にChatGPTへ相談した対象期間 | 2026年8月21日〜9月3日 |
| 初回実装時の指定期間 | 2026年8月22日〜9月4日 |
| 初回取得一覧の最古項目 | 2026年8月27日 |
| 実際にノート化した範囲 | 取得一覧から本文確認・選定できた相談 |
CLIは14日、30日、任意日付範囲を扱えます。ただし、それは入力された相談データを日付で選別できるという意味です。
入力に存在しない会話を、日数指定によって追加取得するものではありません。
さらに、一覧に8月27日の項目があることも、8月27日以降の全履歴を網羅した証明にはなりません。
運用では、保存したノート数だけでなく、指定期間と実際に確認できた履歴の範囲をセットで残す必要があります。
初回10件は、14日間の相談の総件数ではありません。
混在チャットの除外には、本文の読み分けが必要だった
実装中には、残すべき相談の要約に「図解作成依頼は除外した」と書かれているだけで、その相談全体が除外されかねない問題も見つかりました。
そこで、CLIの除外パターン照合は要約本文ではなくタイトル等を対象にする形へ修正されました。例えば、Studio Code Serverの相談について、要約に除外対象の言葉が含まれていても残せることをテストしています。
ただし、混在チャットの細かなテーマ分割は前段のCodexが担当します。キーワード判定だけで意味を理解できるようになったわけではありません。初回のdry-runで、残すべきテーマまで除外されていないかを見ることが重要です。
検証環境の違いも確認した
Skillの検証時には、標準Python環境にPyYAMLがないため、検証に使う実行環境を切り替えた記録があります。
保存用のPythonスクリプト自体は標準ライブラリを使っています。同期スクリプトに必要なものと、Skillの形式を検証するツールに必要なものを分けて把握する必要がありました。
9. テストは、少数出力から再実行まで段階的に行った
初回は、ローカルでの検証、テスト用フォルダへの出力、正式保存、再実行確認という順で進めています。
まず5件を生成し、Vault内の「相談記録_TEST」でも、Frontmatter、自動生成領域、ユーザー編集領域、チェックボックスがそろっていることを確認しました。その後、正式な「相談記録」へ10件を保存しています。
実装レポートに残った結果
| 確認項目 | 記録された結果 |
|---|---|
| テストノート | 5件 |
| 正式ノート | 10件 |
| AI抽出タスク | 20件 |
| 除外記録 | 2件（画像作成依頼・スラッグ提案依頼） |
| ChatGPT通常URLの記録 | 10件 |
| Pythonの単体テスト | 4件成功 |
| Skillの形式検証 | 合格 |
| 同じ入力での再実行確認 | 新規0、更新0、変更なし10、除外2 |
ここでの「変更なし10」は相談ノートの判定結果です。正式同期ではログの新規保存やダッシュボードの同期時刻更新もあるため、フォルダ内の全ファイルが一切変化しないこととは区別します。
4件の単体テストが確認していたこと
保存されたテストコードは、次の内容を扱っています。
- アイキャッチ画像作成の依頼を、作成対象から除外する。
- 残す相談の要約に除外対象への言及があっても、その相談を残す。
- 回答を更新しても、ユーザー編集領域と同じタスクの完了チェックを保持する。
- 同じ入力を再処理しても、重複ノートを作らない。
最初の指示書には、1チャットから3テーマを分離すること、同じテーマの5往復をまとめること、用語質問から不要なタスクを作らないことなど、10種類の確認項目がありました。
それらすべてが自動テストで検証されたわけではありません。テーマ分割や要約の品質はCodexが作るマニフェストに依存するため、生成ノートと元会話を見比べる確認も必要です。
この記事のために、本番Vaultで同期をやり直したわけではありません。テストの成功件数は当時の実装レポートに基づき、テスト内容は保存されているコードと照合しています。
10. 追加で作った「相談一覧」――今、検討するものを見渡す
ノートを作った後、次に欲しくなったのは、各相談の状態を一目で確認できる一覧でした。
追加依頼では、相談日付、名称、状況、実行可否、予定を表にし、新しいノートも反映するよう求めました。
また、「不採用」または「実行しない」にした相談は、一覧から外すことにしました。
ここで実装されたのは、元ノートを削除する処理ではありません。一覧の表示対象から外し、ノートは残す動作です。
チェックを外すと、再び表示されます。
| 操作・状態 | 相談一覧の動作 |
|---|---|
| 新しい相談ノートが追加される | 一覧に反映される |
| 判断や予定を編集する | 表示内容へ反映される |
| 「不採用」にチェックする | 一覧から外れる |
| 「実行しない」にチェックする | 一覧から外れる |
| 除外のチェックを外す | 他の除外条件がなければ再表示される |
| 予定が空欄 | 「未定」と表示する |
| 判断状況が未選択 | Frontmatterのstatusを参照する |
追加一覧には、既存のDataviewを使った
初期のノートと「相談管理ダッシュボード」は、プラグインに依存しないMarkdownとして作られています。
一方、後から追加した「相談一覧.md」はDataviewJSを使っています。実装時のVaultでは、DataviewとTasksがすでに存在し、Dataviewの自動更新とJavaScript表示も有効だったことが確認されています。追加一覧のために新しくプラグインを導入したという記録ではありません。
一覧のコードは、相談記録の中からtype: ai_consultationのノートを読みます。さらに本文の「判断状況」「実行可否」「予定」を取り出し、相談日の新しい順に並べます。ログやバックアップ用の場所は一覧対象から除いています。
見出し名を手動で変えると、その欄を読み取れなくなる可能性があるため、入力欄の名前は維持して使います。
2つの一覧ページの違い
| ページ | 作り方 | 主な用途 |
|---|---|---|
| 相談管理ダッシュボード.md | 同期時の入力データからMarkdownを生成 | 同期対象の状態を分類して見る |
| 相談一覧.md | DataviewJSで既存ノート本文を読む | 手で変更した判断・実行可否・予定を見る |
初期ダッシュボードは、その回の入力データをもとに作られます。ノート本文の手動チェックを常時読み取るものではないため、日々の判断確認では、後から追加した相談一覧の方が目的に合っています。
相談一覧は10件の表示がObsidian上で確認されています。保存された確認コードには、除外条件、予定の読み取り、新規ノート、バックアップ除外などのチェックがあります。ただし、将来のすべての編集形式やプラグイン更新まで保証するものではありません。
11. 日々の使い方――一覧を開き、判断と予定を書き足す
日常運用でユーザーが行う操作は、次の流れです。
- Obsidianで「相談記録／相談一覧」を開く。
- 気になる相談の名称をクリックする。
- 要約を読み、必要なら元チャットで条件や文脈を確認する。
- 「判断状況」と「実行可否」にチェックを付ける。
- 「判断・コメント」と「予定」に、自分の言葉で追記する。
- 実行したタスクへ完了チェックを付ける。
例えば、更新前後の比較準備について相談したノートなら、次のように記入できます。
### 判断状況
- [x] 一部採用
### 実行可否
- [x] 検討後に実行
### 判断・コメント
2026-09-04
比較用の画面撮影は行う。更新日はバックアップ確認後に決める。
### 予定
- 2026-09-05 比較対象の画面を決める
## ユーザー追加タスク
- [ ] 撮影画像の保存先を決めるこれは記入例です。AIに予定を推測させず、本人が決めた内容を追記します。
判断状況と実行可否は、現在の版では通常のチェックボックスです。ラジオボタンのように1つだけ選ぶ制御はないため、矛盾する選択を同時に付けないように使います。
また、チェックを付ける操作がFrontmatterのstatusまで自動更新するわけではありません。相談一覧は本文のチェックを優先して表示するため、日常的な判断入力は本文側へ統一すると混乱を減らせます。
履歴を取り込み直すときはSkillへ依頼する
履歴取得から更新したい場合は、Codexへ次のように依頼します。
$sync-ai-consultations-to-obsidian
直近14日間の相談履歴を確認し、相談テーマごとにObsidianへ整理してください。
取得できた期間と取得上限を報告し、ユーザー判断・予定・追加タスク・
完了チェックを保持してください。最初にdry-runと少数テストを行ってください。これは利用時の依頼例です。Skillが見つからない場合は、配置したSkillが現在のCodexに読み込まれているかを確認します。実装レポートでは、個人Skillフォルダへインストール済みで、再読み込み後に一覧へ反映される旨が記されています。
保存処理だけ確認する場合のdry-run
次は、実装レポートに記載された保存処理の確認コマンドです。--dry-runではノートを書き換えず、作成・更新・変更なし・除外などの予定を表示します。
python3 "/Volumes/TEKQPHYE748/obsidian/ssd_vault/06_Scripts/sync_ai_consultations_to_obsidian/sync_consultations.py" \
--manifest "/Volumes/TEKQPHYE748/obsidian/ssd_vault/06_Scripts/sync_ai_consultations_to_obsidian/manifest.json" \
--vault "/Volumes/TEKQPHYE748/obsidian/ssd_vault" \
--root 相談記録 --days 14 --dry-runこのコマンドは今回の環境専用のパスを含みます。別の環境では保存先とファイルの配置を合わせる必要があります。また、前述のとおり新しい会話を取得するコマンドではありません。
--days 14は実行日を終点とするため、後日同じ入力で試すと対象件数が変わることがあります。実装時の期間を確認したい場合は、日数指定の代わりに次の指定を使います。
--from-date 2026-08-22 --to-date 2026-09-04正式反映は、内容確認後に同じコマンドから--dry-runを外して行います。更新された相談ノートは更新前に.backups/<日時>/へ保存され、実行結果は_logsへJSON形式で記録されます。これはノート更新時の退避であり、Vault全体のバックアップを置き換えるものではありません。
12. 毎日午前3時の実行と、料金の考え方
追加依頼では、毎晩3時ごろにSkillを実行する設定と、その場合のAPI料金についても確認しました。
共有記録では、毎日午前3時、日本時間での定期実行を設定したと報告されています。これは履歴を読み直して整理するSkillの定期実行であり、保存用Pythonだけを動かす説明ではありません。
ただし、記録から確認できるのは設定完了までです。実際に夜間の処理が継続して成功しているか、取得できるツールや書き込み権限が実行時にもそろうかは、実行履歴で確認する必要があります。
API料金とCodex利用枠を区別する
今回の実装は、保存用スクリプトから別途OpenAI APIを呼ぶ方式ではありません。ChatGPTアカウントでCodexを利用する場合、履歴の読み取り・要約などはCodexの利用枠を消費します。利用枠内の実行と、追加クレジットの利用、APIキー方式による従量課金は分けて考える必要があります。料金条件は変更されるため、運用時にはOpenAI公式の料金説明を確認します。
保存用Pythonを動かすこと自体と、AIが履歴を読み解くことでは、必要な処理が異なります。毎日広い期間の会話を読み直す設計なら、対象件数や会話の長さによって利用量も変わります。本実装の1回あたりの費用や利用枠消費量は、測定結果がないため数値を示せません。
外部SSDを使うため、実行時のローカル環境が必要
今回の保存先は、Macにつながった外部SSDです。夜間実行には、Macと実行するデスクトップアプリが動作し、対象Vaultへアクセスできる必要があります。ローカルファイルを使う定期実行ではコンピューターとアプリを稼働させる必要があることは、OpenAI公式の定期実行説明にも記載されています。
朝に確認するのは、単に「午前3時の予定があるか」ではなく、実行結果、取得範囲、新規・更新・除外件数、エラーの有無です。SSD未接続や利用枠不足などで進まなかった場合も、成功と混同しないようにします。
13. この仕組みで得られるメリット
相談を探す軸が、テーマと行動になる
相談した時期やチャット名を正確に覚えていなくても、テーマ名、タグ、判断状況から探せます。
長いチャットの中に埋もれていた相談が、個別ノートとして見えるようになります。
AIの提案と、自分が選んだことを区別できる
「この方法がある」と回答されたことと、「この方法で進める」と本人が決めたことを並べて残せます。
不採用にした理由や、保留した条件も、次に検討するときの材料になります。
後からAIがユーザーの判断・選択を読み取れるため、その後の提案をより本人の意向に沿ったものにできます。
未完了の作業を思い出しやすい
質問への回答と、その後の実機確認や撮影を同じページで見られます。何のためのタスクだったかを、相談の要約からたどれる点が便利です。
ブログ記事の材料へ戻りやすい
調査した内容、採用した方法、未解決の点、追加で撮るべき画面などを整理しておけば、後から記事を作るときの入口になります。関連ノートを整備していけば、構想・実装・検証といった複数の相談を結び付けることもできます。
Markdownとして残る
相談ノートの本文はMarkdownなので、一覧機能の表示方法とは切り離して内容を読めます。DataviewJSを使う一覧が動かない場合でも、個々の要約や判断記録まで読めなくなる構成ではありません。
これらは構成から期待できる利点です。検索時間が何分短くなったか、タスク完了率がどれだけ上がったかといった効果は、今回の実装記録では測定していません。
14. 使い続ける前に、把握しておきたい注意点
初期版の使い方を整理すると、次のようになります。
| 注意点 | 現在の扱い方 |
|---|---|
| 14日指定でも履歴が不足する | 取得一覧の範囲を記録し、取り込めていない期間を残す |
| 要約・テーマ分割には解釈が入る | 重要な判断前に元チャットを確認する |
| 自動タスクの削除・改変を完全には保持しない | 自分の作業はユーザー追加タスクへ書く |
| 同じ相談の識別には安定したIDが必要 | 再抽出時にtopic_idを維持する |
| 関連ノートは初回未設定 | 実在するノートを確認してリンクを付ける |
| 相談一覧はDataviewJSを使う | 同じ表示を再現する環境条件を確認する |
| 判断欄は複数選択できる | 矛盾するチェックを付けない |
| 定期実行は設定と成功が別 | 実行履歴とログを見る |
15. 今後は、取得範囲と更新の確実性を高めたい
当初の構想には、Stream Deckからの起動、Tasks連携、未完了タスク通知、Home Assistant連携、相談テーマの統計、ブログ記事候補の抽出なども含まれていました。
今回の共有記録で完了したのは、初期同期、Skillの配置、相談一覧、午前3時の定期実行設定までです。
Stream Deckのボタンからの実動作や外部通知は、未実装です。
次の拡張では、まず記録の欠落や編集の取り違えを減らしたいと考えます。
取得できなかった履歴を補えるようにする
一覧取得に上限がある場合の追加取得方法を整え、どこまで処理済みなのかを管理します。実行した時刻だけでなく、確認できた会話と未確認の範囲を残せると、取得漏れを追いやすくなります。
タスクにも安定したIDを付ける
文言ではなくタスクIDで照合できれば、文章を直しても完了状態を維持しやすくなります。ユーザーが削除したタスクを再生成しないための記録や、完了済みタスクの履歴保持も合わせて検討したい部分です。
人が編集する項目の更新ルールを広げる
Frontmatterの独自項目、手動タグ、判断状況の扱いを決め、本文とプロパティの食い違いを減らします。既存ノートの探索ではバックアップとの区別、同名ファイルの衝突、同時実行時の書き込みなども確認対象になります。
関連ノートを実用的につなぐ
同じプロジェクトの構想、実装、トラブル対応などを、実在するリンク先と照合して結び付けます。タイトルが似ているだけの相談へ大量にリンクするのではなく、後から読む順序が分かるつながりを作りたいところです。
動的な一覧と通知を育てる
未完了タスクや予定日をより確実に集計できるようにし、必要なものだけを通知する構成へ広げられます。通知先や期限の解釈は、本人が書いた予定と結び付けて設計する必要があります。
自動化の効果を測る
最後に、運用を続けながら、新規ノート数だけでなく、取得漏れ、要約の修正件数、再生成された不要タスク、利用枠の消費なども確認したいと考えています。実際の困りごとを記録することで、どの拡張から進めるべきか判断できます。
16. 相談の後に、自分の言葉を残せるようにする
今回の構想は、過去2週間の相談を表にする依頼から始まりました。そこからテーマ別のObsidianページへ進み、ユーザー判断、予定、チェックボックス付きタスク、元チャットURL、相談一覧、定期実行へと形になりました。
実装を通じて分かったのは、ノートを生成することに加えて、取得範囲を正しく伝えること、AIの提案と本人の判断を分けること、再実行でも手入力を守ることが必要だという点です。
まずは相談一覧を開き、気になっていたノートに「今回は保留」「この部分だけ採用」「来週確認する」と書き足してみる。
その短い追記が、後で相談を再開するときの手がかりになります。
AIとの会話を積み重ねながら、自分がどう考え、何を選び、何を終えたのかも同じ場所に残す。
今回作った仕組みを、そのための入口として育てていこうと思います。