第10回 使い続けるための `friend`：help, clean copy, model split, cost report

はじめに

ここまでの連載で、friend はかなり育ってきた。

• 短期記憶
• state 永続化
• summary
• foundation
• project memory
• consistency check
• memory hint

この時点で、思想としてはかなり面白いものになっている。
単なる API 直叩きの窓ではなく、記憶と原則を持つ相棒になりつつある。

しかし、ここで一つの現実が立ちはだかる。

面白いものを作るのと、毎日使えるものにするのは別である。

どれだけ構造が美しくても、

• keymap が増えて覚えにくい
• コードをコピーしたら変なマーカーが混ざる
• API コストが見えない
• 品質は良いが、使いすぎると財布に効く

となれば、結局は日常運用に耐えない。

この回で扱うのは、まさにその「最後の現実」である。
friend を 思想の産物 から 毎日使い続けられる道具 に変えるために入ってきたもの

• help
• clean copy
• usage / cost report
• model split

をまとめて振り返りたい。

これらは一見すると細部の話に見える。
だが、実際にはここが入って初めて、friend は本当に使えるものになった。

1. 機能が増えると、help が必要になる

friend は、育つにつれて当然機能が増えていった。

最初は単に

• 送る
• ログを見る

くらいで足りていた。
だが、後になると少なくとも次のような操作が出てくる。

• save
• reload tail
• older log 読み込み
• summary open
• summary refresh
• foundation open
• memory open
• consistency check toggle
• memory hint refresh
• usage report
• clean copy

これだけ増えると、さすがに覚えきれない。

しかも friend は、単なる補助機能ではなく、すでに一つの subsystem に近くなっている。
ならば当然、その subsystem には 自己説明能力 が必要になる。

ここで導入されたのが help だった。

発想としてはとても自然で、

• key 一覧
• 各レイヤの説明
• どこに何を書くか
• 典型的な workflow

を、その場で見られるようにする。

つまり friend はここで初めて、
自分の使い方を自分で説明できる ようになったのである。

これはかなり大きい。
なぜなら、内部構造が豊かになるほど、
それを人間が思い出せるようにする仕組みが必要になるからだ。

2. help は単なる親切機能ではなかった

最初は「キーが増えてきたから help があると便利かも」という、かなり自然な流れだった。
しかし実際に入れてみると、help はそれ以上の役割を持っていた。

friend の help が担ったもの

• key の一覧
• Foundation / Project Memory / Session Summary / State / Log の区別
• それぞれの意味
• Typical workflow

つまり help は単なるショートカット一覧ではなく、
friend 全体の層構造の説明書 に近かった。

たとえば、help の中にはこんな説明が入る。

• Foundation: global long-term principles
• Project Memory: project-specific long-term assumptions
• Session Summary: medium-term working summary
• State: short-term conversation chain
• Log: official interaction record

これによって、friend はかなり「見通しの良い存在」になる。
機能が増えるほど、内部構造が頭から抜けやすくなる。
その時、help は単なる補助ではなく、
構造を再認識するためのインタフェイス になるのである。

ここは地味だが、とても効いた。

3. 見た目は綺麗、でもコピーすると壊れる

friend の上段、strait-ai は pretty 表示がかなり効いていた。

• タイトル
• 区切り線
• Markdown 風の見た目
• 引用表示
• コードブロック

としては、かなり読みやすい。
実際、見た目の満足度は高かった。

だが、ここで妙な問題が出る。

AI の返答に含まれている Lisp コードをそのままコピーして貼ると、壊れるのである。

原因は、内部的には本文が blockquote 的に保持されていたことだった。
つまり表示上は綺麗に見えていても、実体には > が混ざっている。
表示では隠しているので気づきにくいが、貼るときに初めて露見する。

これがかなり厄介だった。

• 目には見えない
• でも貼ると壊れる
• 毎回手で > を消すのは面倒
• しかも friend を使う頻度が上がるほど、痛みも増える

ここでわかったのは、
表示に成功していても、コピー UX が壊れていると日常利用ではつらい
ということだった。

4. clean copy を M-w に統合する

この問題に対して、最初に考えられたのは

• 表示方式そのものを変える
• 手で > を消す
• clean 抽出コマンドを作る

といった案だった。

結果的に、一番良かったのは
clean copy を M-w に統合する
という案だった。

これはかなり重要な判断だった。

もし専用キーにしていたら、

• 普通の Emacs 操作とは別のことを覚えなければならない
• UI が一段重くなる

一方、strait-ai バッファだけ M-w を friend 専用にすれば、

• 普通に選択して
• 普通に M-w
• 普通に C-y

で済む。

つまり、UX 的にはまったく自然である。
内部的にだけ、

• >
• ## ...
• ``

などの表示用マーカーを落として、clean text を kill-ring に入れる。

これで、見た目の良さは維持したまま、
コピーだけ賢くなる。

これはまさに
表示モデルを壊さずに、操作性だけ改善する
という、非常に良い修正だったと思う。

5. 親切さは、ショートカットよりも習慣に乗せた方がよい

help と clean copy の両方に共通していたのは、
「機能を増やす」よりも
既存の習慣の上に賢さを載せる
という方向だった。

• help は、必要なときにその場で見られる
• clean copy は、M-w という既存操作に乗せる

これはかなり大事だった。

もし friend が新しいルールばかり要求してくると、
どれだけ中身が優れていても、使い続けるのがしんどくなる。
だからこそ、

• 既存の手触りを壊さない
• でも中では少し賢くする

という設計が効いた。

このあたりから friend は、
内部の多層記憶や原則だけでなく、
外側の操作感まで含めて相棒らしく なっていったのだと思う。

6. そして最後の現実問題：API コスト

friend がすこぶる調子良くなってくると、
別の意味での「困りごと」が出てくる。

API なので、使えば使うほどコストがかかる。

これは実に現実的な問題だった。
ChatGPT の Web 版とは違って、API に「使い放題」はない。
調子に乗って使っていると、ちゃんと財布に返ってくる。

だが、これはある意味、
friend が「本当に使えるものになってきた」証拠でもあった。

もし使いづらければ、そんなに連続して使わない。
しかし、実際には

• main conversation が快適
• summary も効く
• hint も気が利く

となると、自然に使用量が増える。

ここで必要だったのは、単に「節約しよう」ではない。
まずは、

何にどれくらいコストがかかっているのかを見えるようにする

ことだった。

7. usage log と usage report の意味

そのために入ってきたのが、

• ai-usage.log
• usage report

である。

ここで記録するのは、各 API 呼び出しについての

• task_type
• model
• elapsed_ms
• input_tokens
• output_tokens
• total_tokens
• reasoning_tokens
• cached_tokens

などである。

この仕組みが入ると、
friend の改善は「なんとなく」ではなくなる。

たとえば、

• main は高いが納得感がある
• summary は意外と重い
• hint は軽い
• cached_tokens はまだ 0 が多い

といったことが、数字で見えるようになる。

これは非常に大きい。

なぜなら、ここに来て初めて friend は、
自分の賢さだけでなく、自分の運用コストも観測できる
ようになったからだ。

8. model split 第一段階は、とても現実的だった

usage report が入ると、次の問題もかなり明確になる。

• 何を高いモデルに残すべきか
• 何を cheaper model へ逃がせるか

ここで導入されたのが、第一段階の model split だった。

main conversation

• gpt-5.4

summary refresh

• gpt-5.4-mini

memory hint

• gpt-5.4-nano

この分け方が良かったのは、
いきなり main conversation に手を入れなかったことだ。

main は、friend の「賢さ」の本体である。
ここを cheap 化し始めると、体感品質が崩れやすい。
一方で summary や hint は、補助タスクとしてかなり分離しやすい。

つまり、

• 価値の高い本体は守る
• 補助タスクから先に安くする

という、非常に現実的な順序になっていた。

この段階で得られた感触は、かなり面白かった。
summary と hint を cheaper model に逃がしても、
main conversation の「すこぶる調子が良い」感じはそのまま保てたからだ。

9. 「賢さ」と「持続可能性」の両立

ここで重要なのは、cost optimization は
単なるケチではない、ということだ。

friend の目的は、安さだけではない。
むしろ大事なのは、

使い続けられる賢さ

である。

どれだけ賢くても、高すぎて日常運用できなければ意味がない。
逆に、安くても main conversation の質が落ちてしまえば、friend らしさがなくなる。

だから usage report と model split の導入は、
単なるコスト削減ではなく、

• 品質
• 体感
• コスト
• 運用継続性

のバランスを取るための仕組みだった。

ここに来て friend は、
記憶や原則だけでなく、
現実世界で持続可能に使うための知恵 まで持ち始めたのである。

10. 第10回の意味

ここまで見てくると、この回で扱ったものは一見バラバラに見える。

• help
• clean copy
• usage report
• model split

だが、実は全部ひとつのテーマにまとまっている。

それは、

friend を “毎日使えるもの” にする

というテーマである。

help

内部構造を見失わないため

clean copy

日常の作業を邪魔しないため

usage report

コストを見えるようにするため

model split

賢さを保ちつつ安く回すため

つまりこの回は、
記憶と原則を持つ存在を、実際の道具として成立させる話
だったのだと思う。

思想的な設計だけでは、相棒にはなれない。
最後には必ず、

• 手触り
• 可視性
• 継続性
• コスト

という現実の壁がある。
第10回は、その壁を越えるための話だった。

おわりに

この回では、friend を日常運用に耐えるものにするために入ってきた、

• help
• clean copy
• usage / cost report
• model split

をまとめて振り返った。

ここまでで friend は、かなり本格的に

• 覚える
• 原則を持つ
• ツッコむ
• 気づかせる
• 使いやすい
• しかも現実に運用できる

存在になってきた。

次回はいよいよ最終回。
ここまで積み上げてきたものを振り返りながら、

friend は何になったのか
何を設計していたのか

を、少し落ち着いて総括したい。

次回予告

第11回

friend は何になったのか：記憶と原則を持つ相棒の設計

• API クライアントから collaborator へ
• 記憶層の意味
• 原則層の意味
• friend の哲学
• 今後の展望

付録：本稿で扱った運用改善関連コード断片

help

(defun appsdk-friend-help ()
  "Show Friend help."
  (interactive)
  (appsdk-log-show
   (concat
    "Friend Help\n\n"
    "Layers\n\n"
    "  Foundation      : ~/.friend/foundation.md\n"
    "  Project Memory  : <project>/.friend/ai-interaction.memory.md\n"
    "  Session Summary : <project>/.friend/ai-interaction.summary.md\n"
    "  State           : <project>/.friend/ai-interaction.state.json\n"
    "  Log             : <project>/.friend/ai-interaction.log\n\n"
    "Friend keys (strait-ai)\n\n"
    (appsdk-help-from-annotations appsdk-friend-strait-mode-map))
   "FRIEND HELP"
   t))

clean copy

(defun appsdk-friend-copy-clean (&optional beg end)
  "Copy cleaned Friend text to kill-ring.
If region is active, use region.
Otherwise copy current Friend block."
  (interactive)
  (let* ((bounds (if (use-region-p)
                     (cons (region-beginning) (region-end))
                   (appsdk-friend--current-block-bounds)))
         (raw (buffer-substring-no-properties
               (or beg (car bounds))
               (or end (cdr bounds))))
         (clean (appsdk-friend--clean-text raw)))
    (kill-new clean)
    (when (use-region-p)
      (deactivate-mark))
    (message "[AppSDK] friend: copied clean text")))

usage report

(defun appsdk-friend-usage-report ()
  "Show Friend usage/cost summary report."
  (interactive)
  ...)

model split のイメージ

(defcustom appsdk-friend-main-model "gpt-5.4"
  "Model used for main Friend conversation."
  :type 'string
  :group 'appsdk-friend)

(defcustom appsdk-friend-summary-model "gpt-5.4-mini"
  "Model used for summary refresh."
  :type 'string
  :group 'appsdk-friend)

(defcustom appsdk-friend-hint-model "gpt-5.4-nano"
  "Model used for memory hint generation."
  :type 'string
  :group 'appsdk-friend)