ユースケース

Ayumi の役割は意図的に狭く取ってあります — 思考を捕まえて、Markdown としてディスクに書く。おもしろいのは、そのフォルダの 向こう側 に何を作るかです。

このページは実際に運用されているパターンをまとめたものです。どれも構造は同じです。

捕捉（Ayumi） → Markdown のフォルダ → エージェントやスクリプトが定期的に読む → 自分が実際に見る場所に出力する。

ここに書かれているものは Ayumi の組み込み機能ではありません。Ayumi が引き受けるのは最初のステップを速くすることと、その先のパイプラインが API なしで読める形式でファイルを残すことだけです。

共通の土台

以下のすべては、Ayumi のエントリーの書き方に関する 2 つの事実に依存しています。詳細は Markdown フォーマットを参照してください。

エントリーはジャーナルフォルダ以下に日付でネストされます。

journal/
  2026/09/13/
    2026-09-13_08-12-44-201.md
    2026-09-13_08-12-44-201.assets/
    2026-09-13_21-40-03-118.md

そして各ファイルはフラットな YAML フロントマターで始まります。

---
id: "550e8400-e29b-41d4-a716-446655440000"
created_at: "2026-09-13T17:12:44+09:00"
updated_at: "2026-09-13T17:12:44+09:00"
tags:
  - daily
transcription_model: "gemini-2.5-flash"
transcription_prompt: "Reflection"
---

連携の口はこれだけです。ディレクトリを辿って YAML をパースできるエージェント・スクリプト・エディタなら、何でもあなたのジャーナルを読めます。

ほとんどのパイプラインの出発点になる「直近 24 時間ぶん」の最小の選択方法です。

find "$JOURNAL" -name '*.md' -newermt '24 hours ago' | sort

1. 毎日の振り返りのためのボイスジャーナル

いちばんシンプルなループで、最初に作る価値があるのもこれです。

日中の捕捉はハンズフリーにします。録音を開始 をアクションボタンや背面タップに割り当てておき（iOS ショートカット）、歩きながら、あるいは会議の合間に、頭にあることをそのまま話します。停止は Dynamic Island から。文字起こしが終わると、それぞれの録音がエントリーになります。

夜に、その日を読み返します。エントリーはすでにディスク上にあるので、「読み返す」はアプリを開くだけでも成立しますし、その日をまるごと AI に渡すこともできます。

今日のジャーナルのエントリーを全部読んで、次を出して。
1. 実際に今日考えていたこと（予定していたことではなく）。
2. 二回以上言っていること — 繰り返す心配事はシグナル。
3. 明日答えを出すべき問いを 3 つ。
結果は reviews/2026-09-13-daily.md に書いて。エントリーは変更しないで。

うまく回すためのポイント

選択	理由
自分の言葉を残す文字起こしプリセット	振り返りに必要なのは、きれいな要約ではなく実際に言ったこと。手を入れすぎないプリセットか、逐語で残る Apple のオンデバイス文字起こしを使う。
`daily` タグ	後続のジョブすべてに安価なフィルタを与えられる。
レビューは別フォルダに書く	エントリーは追記のみの記録のまま保ち、そこから派生したテキストは別の場所に置く。

2. 定期実行のエージェントレビューを Slack に届ける

手動での日次レビューが回り始めたら、それを定期実行にします。そのとき、素材の種類ごとに別々の担当へ振り分けるのがポイントです。

全体の形

1 日 1 回（あるいは週 1 回）走るジョブが、直近のエントリーを集めて振り分けます。

1. 直近 24 時間のエントリーを集める。
2. それぞれを分類する: キャリア / 調べ物 / プロダクト / プライベート / ノイズ。
3. 空でないバケツごとに、そのバケツ用に書いたプロンプトで
   サブエージェントにエントリーを渡す。
4. サブエージェントの出力を集約する。
5. reviews/2026-09-13.md に書き出し、短い版を Slack に投稿する。

ここでサブエージェントに分ける意味は、プロンプトが本当に違うからです。キャリアコーチングのパスと調べ物の振り返りのパスは、同じ仕事ではありません。

バケツ	サブエージェントのプロンプト（おおよそ）
キャリアコーチング	「あなたはこの人のジャーナルを半年ぶん読んだキャリアコーチです。この人が避けていることのパターンは何ですか。今週どこを突きますか。具体的に、耳が痛いところまで。」
調べ物の振り返り	「これは私が調べながら考えていた記録です。何が分かったか、何がまだ未解決か、次に何を読むべきかをまとめてください。」
プロダクトアイデア	「具体的なプロダクト／機能のアイデアをすべて抽出して。1 行ずつ、出典のエントリーを添えて。」
プライベート	「自分用にだけ要約して。外部に投稿されるものには絶対に含めないこと。」

スケジューラの繋ぎ込み

スケジューラは好きなものでかまいません。コマンドを定時実行できれば十分です。

Mac の launchd / cron — ジャーナルフォルダに対してエージェント CLI を走らせる。
クラウド側のスケジュール実行エージェント — 同期されたフォルダのコピーを参照させる。
ショートカット のオートメーション — スマホ側で完結する軽いジョブ向け。

Slack への投稿は Webhook か MCP の Slack ツールを使います。エージェントの手元にはすでにテキストとして要約があるので、配送自体は簡単な部分です。通知をどこに出すにせよ、Markdown のコピーはディスクに残しておいてください。Slack は通知チャンネルであってアーカイブではありません。

何を端末の外に出すかを決める

Slack に投稿する定期ジョブは、ローカルファーストなジャーナルがローカルでなくなる地点です。ここは意識的に設計してください。

絶対に転送したくないエントリーはバケツに分け（上の「プライベート」）、サブエージェントの境界で止める。
生のエントリーではなく、蒸留した要約を投稿する。
収集ステップが最初に除外する #private タグを用意しておくのも手。

3. LLM wiki スタイルのナレッジベースに流し込む

ジャーナルはストリームで、wiki は構造です。片方をもう片方に変換するジョブを走らせれば、捕捉の時点で整理について考えないまま、両方を手に入れられます。

役割分担

レイヤー	役割	可変性
Ayumi のエントリー	いつ何を考えたかの記録	追記のみ
wiki のページ	概念・人物・プロジェクト・意思決定ごとに 1 ページ	エージェントが自由に書き換える

wiki は独自のフォルダに置きます。Ayumi のエントリーはもともと Obsidian 互換なので、同じ Obsidian vault の中に置くことも多いでしょう。そして wiki の各ページは、蒸留元になったエントリーへリンクを張り返します。

蒸留パス

新しいエントリーを読んで wiki を更新する、週次のジョブです。

<前回実行時> 以降の各エントリーについて:
  - 触れている概念・プロジェクト・人物を特定する。
  - それぞれについて wiki/<概念>.md を更新する:
      * 新しい考えを既存のページにマージする。
      * ページの記述と矛盾する場合は、両方を残して
        変化した日付を添える — 黙って上書きしない。
      * 出典としてエントリーへのリンクを追記する。
  - まだ存在しないページは作成し、[[wiki リンク]] で繋ぐ。
最後に、触ったページを一覧にする（差分をレビューできるように）。

Ayumi と相性がいい理由

バックリンクがタダで手に入る。 wiki 側の [[Wiki Link]] 記法とエントリーへの相対リンクがあれば、Obsidian のグラフビューが両レイヤーをまたいで機能します。
フロントマターがそのまま構造になる。 tags、created_at、location_place_name が、蒸留側にとって実際に使えるメタデータになります。
wiki は使い捨てられる。 真実の源がエントリー側にあるので、wiki を丸ごと消して、もっと良いプロンプトで作り直せます。2 つのレイヤーを分ける最大の理由がこれです。

4. 話したアイデアからプルリクエストまで

素早い捕捉がいちばん直接的に効くのがこれです — キーボードから離れているときのアイデアが、コードになります。

歩いていて、ふと声に出す。「エクスポートのシート、最後に選んだフォルダを覚えていてほしいな。毎回リセットされるのが地味に面倒」。この一文はもうエントリーになっています。あとは夜間ジョブがプルリクエストに変えてくれます。

パイプライン

毎晩:
  1. 直近 24 時間のエントリーを読む。
  2. 自分のリポジトリへの具体的な変更になるものを抽出する。
     曖昧な願望は無視する — 具体的な挙動の変化を要求すること。
  3. それぞれについて:
       a. リポジトリを特定する。特定が曖昧ならスキップ。
       b. リポジトリを開き、該当コードを読み、変更が本当に
          小さく自己完結しているかを確認する。
       c. 該当すれば: ブランチで実装し、ドラフトのプルリクエストを作る。
          PR の説明に元のジャーナルのエントリーを引用する。
       d. 該当しなければ: 何が大きいのかを添えて backlog.md に書く。
  4. 作成した PR と見送った項目を Slack に投稿する。

放っておいても安全にするためのガードレール

ここが、役に立つパイプラインと 1 週間で止めるパイプラインの分かれ目です。

ガードレール	理由
ドラフト PR のみ、マージはさせない	レビューは必ず自分でする。エージェントの仕事は白紙からのコストを消すことで、出荷することではない。
明示的なリポジトリ許可リスト	名前を挙げたリポジトリだけを触らせる。曖昧なマッチは推測させず、保留にする。
サイズの上限	「N ファイルを超える、あるいは設計判断が必要なら、実装せず backlog に書く」。小さく検証可能な変更だけがうまくいく。
PR を作る前にテストを通す	検証されていない PR は、元のアイデアの価値よりレビューコストの方が高くつく。
PR 本文に出典のエントリーを引用する	3 日後には、なぜこの PR があるのか、自分が本当は何を言いたかったのかを知りたくなる。

捕捉の時点で意図を示す

抽出側に分かりやすいシグナルを与えましょう。専用の文字起こしプロファイルをもう 1 つ作ってもいいですし、そういう録音は「Ayumi のアイデア:」から話し始める、という習慣だけでも分類は十分安定します。#dev タグでもよく、こちらはタップ 1 回で済みます。

自分なりの形を作る

ここまでのパターンは、どれも同じ 4 つの決定のバリエーションです。

何が捕捉のトリガーになるか。 ハードウェアボタン、ショートカット、Apple Watch、ウィジェット — 思いついてから録り始めるまでの間を消せるものなら何でも。
テキストをどんな形にするか。 振り返りなら逐語、抽出なら構造化。これが文字起こしプロンプトプリセットの使いどころです。
何をどのくらいの頻度で定期実行するか。 振り返りは日次、蒸留は週次、自動化は夜間。
出力はどこに着地するか。 必ず見るものは Slack へ、後から検索するものは Markdown へ、仕事になるものはプルリクエストへ。

どのパターンでも、Ayumi の担当範囲は同じです — 思いついた数秒後には、その思考がプレーンな Markdown としてディスクにあること。