We now support rich formatting for all chatbots. Tables, nested lists, inline media, formulas, headers and more — right in Telegram messages. 🔨 Start building! Docs: core.telegram.org/bots/api#r…

ClaudeのMaxプラン($220/月)を契約2日で全額返金してもらった。しかも返金交渉はClaude Code (Opus 4.8) に丸投げ。AnthropicのAIがAnthropicのサポートと話して、Anthropicから返金を受けることができた。やり方も書くので真似できます。以下詳細。 【何が起きたか】 ・6/11の夜にMaxを契約 ・翌6/13の朝、米政府の輸出規制でFable 5が全ユーザー停止と発表 ・自分がMaxに上げた目的はFable 5。実質1日しか使えないまま消えた ・契約直後の仕様変更だし返金案件だろ、とサポートに連絡した 【交渉はClaude Codeにやらせた】 ・手を動かしたのは自分じゃなくClaude Code (Opus 4.8) ・ブラウザ操作系のMCPを繋いで、ログイン済みのChromeをそのまま操作させた ・claude.aiのサポートチャットを開いて返金フローを最後まで完走 ・自分は送る文面を承認して横で見てただけ ・向こうの対応もAI。結局AIが申請してAIが承認した。すごい時代だ。 【自分でやるには】 ・Claude Code (またはブラウザを操作できるエージェント) を用意 ・ブラウザ操作MCP (Chrome DevTools MCP など) を繋ぐ ・自分がログイン済みのChromeを remote-debugging 付きで起動して、そのプロファイルに接続させる ・あとは勝手にコミュニケーション取ってるのを見るだけ 【手順(返金フロー本体・Web課金の場合)】 ・claude.ai 左下メニュー → Get help ・Send us a message → Accept ・カテゴリで「Claude Refund Request」を選択 ・対象プランを確認 ・理由は定型に該当しないので「Other」＋自由記述 【通すコツ】 ・盛らないこと。「全モデルが使えない」とは言わない (Opus 4.8などは普通に使える) ・契約直後 × ほぼ未使用 × 主要モデル停止、この3点に絞って事実だけ書く ・公式の情報源もOpusに渡すと状況理解が早い。ref: x.com/ClaudeDevs/status/2065… ・実際に送ったのは「6/11契約・利用は実質1日・主目的のFable 5が全停止・重大な仕様変更なので全額返金と解約を希望」程度の短文 【結果】 ・$220全額返金が承認 ・請求履歴のステータスも「Refunded」に変わった 【注意点】 ・規約上は原則「非返金」。それでも上の条件が揃えば全額返金の余地はある ・解約は即時反映。期間末まで使えるわけじゃなく、返金と引き換えにMaxは即失効 ・iOS課金はApple、Android(Play)は原則返金不可で窓口が別。Web(Stripe)はこのフローでいける 返金額そのものより、ブラウザを握らせたらサポート交渉まで勝手に走り切ったのが一番面白かった。同じ状況の人は、このツイートをエージェントに読ませて「やって」って言うだけでいけます。

とりあえずFableには作ってるプロジェクトの監査をやってもらうことにした。 # fable-review の手順書 このディレクトリには、プロジェクトごとの「現状把握・リファクタリング方針・発展のさせ方」を 1 ファイルずつ保存する。`projects/{name}.md` が最終目標 (ユーザー facing な受け入れ要件) を定め、本ディレクトリの文書はそこへ到達するための現在地と進め方を定める。 `projects/fable-review/{name}.md` は、コーディングエージェント (Codex 等) にそのまま渡して実装作業を開始できる指示書を兼ねる。レビューセッション内の文脈を前提にせず、文書単体で着手できる粒度で書く。 kickoff プロンプトで対象プロジェクト (構想ファイルまたは GitHub repo) が指定される。対象プロジェクトの一覧と実施状況は `projects/fable-review/TARGETS.md` で管理する。 レビューセッションは `claude -p` によるヘッドレス実行を想定する。セッション中にユーザーへ質問できないため、判断が必要な事項で停止せず、自分の判断で決定して先へ進める。プロジェクトを前進させるために必要な変更は、アーキテクチャレベルのものを含めてエージェントに委ねられている。ユーザーにしか決められない事項のみ、文書末尾の「ユーザー判断」セクションに記載し、次回のセッションで解決する。この委任のもとでは、ユーザー判断セクションに載る項目はほとんど発生しない想定である。 ## kickoff プロンプト例 ``` projects/fable-review/README.md の手順に従い、レビューセッションを実施してください。 ``` ``` projects/fable-review/README.md の手順に従い、projects/rust-quotaboard.md を対象にレビューセッションを実施してください。 ``` ``` projects/fable-review/README.md の手順に従い、conao3/seml-mode.el (構想ファイル未作成) を対象にレビューセッションを実施してください。 ``` ## ヘッドレス実行コマンド例 `--output-format stream-json` の JSONL は `claude-stream-filter.sh` (要 jq) で行番号付きの要約に変換して進行を確認する。 ```bash claude -p 'projects/fable-review/README.md の手順に従い、レビューセッションを実施してください。' \ --dangerously-skip-permissions --model claude-fable-5 \ --output-format stream-json --verbose \ | projects/fable-review/claude-stream-filter.sh ``` ## 成果物 - `projects/fable-review/{name}.md` の新規作成または改訂 (本ファイル末尾の構成に従う)。 - `projects/{name}.md` が無い場合、対象 repo のコードから逆算して新規作成する (手順 1 参照)。 - `projects/{name}.md` が有る場合、最終目標そのものに反映すべき発見 (受け入れ要件の欠落、非ゴールの明確化など) があったときのみ編集する。実装方針・進め方は書き込まない。 - 実装コード・リポジトリ作成・外部への投稿は行わない。 ## 手順 ### 0. 対象の確定 (claim) kickoff プロンプトで対象が明示されない場合は、`projects/fable-review/TARGETS.md` の先頭から最初の `TODO` 項目を対象に選ぶ。いずれの場合も、対象項目を `WORKING` に書き換えて即 commit してから作業を始める (`TARGETS.md` の状態管理を参照)。 ### 1. 現状把握 `projects/{name}.md` の内容を確認する。対応する GitHub repo が実在する場合は ghq で取得してコードベースを調査し、実装の現状 (アーキテクチャ、品質、テスト・CI の有無、構想との乖離) を評価する。構想のみの場合は、構想の成熟度 (決定済みの判断と未決の判断の比率) を評価する。本文で参照される競合・参考実装も、設計判断に必要な範囲で調査する (web 検索・DeepWiki・ghq clone 可)。 `projects/{name}.md` が存在しない場合は、対象 repo のコード・README・テストから「このプロダクトはユーザーに何を約束しているか」を逆算し、ユーザー facing な受け入れ要件として `projects/{name}.md` を新規作成する。実装詳細ではなく、あるべき姿 (達成条件) を記述する。ファイル名・書式はプロジェクトメモ (`projects/ghq-github-com-conao3-idea.md`) の規約に従う。 ### 2. ゴール定義 (backcasting) 1年後から逆算して 1ヶ月後、1週間後を決める。 - **1年後**: このプロジェクトが成功していると言える状態。誰が・どの頻度で・何の代替として使っているかを、達成判定できる文で書く。 - **1ヶ月後**: 1年後へ向かう最初のマイルストーン。動作する MVP の具体像。既存実装がある場合はリファクタリング後の姿を含める。 - **1週間後**: 最大リスクの検証 (spike)。「このプロジェクトが頓挫するとしたら何が原因か」を特定し、その検証手順と判定基準を書く。 - **非ゴール**: 1年後ゴールにも含めないもの。 時間軸は締切ではなく優先順位のレンズとして使う。 ### 3. 設計判断の列挙と決定 未解決の設計判断を全て列挙する。明示された「未決事項」だけでなく、本文・コードに暗黙に含まれるもの (「〜を想定」「〜は実装時に決める」等) も拾う。各判断について調査の上で決定と理由 (採らなかった案との tradeoff を 1〜2 行) を書く。アーキテクチャレベルの変更を含め、設計判断は自分で決定する。実測が必要なものは検証手順を添えて未決事項として保持する (1週間 spike や着手指示に組み込む)。ユーザーにしか決められないもの (好み・予算・対外的な判断) のみ「ユーザー判断」セクションへ送る。 ### 4. 敵対的レビュー 確定前に、自分の評価と計画を以下の観点で批判的に検証する (workflow で 1 観点 1 エージェントの並列レビュー可)。指摘は本文に反映し、対応しない指摘はその理由を書き添える。観点は PMBOK の知識エリアと ISO/IEC 25010 の品質特性を個人開発向けに翻案したもの。 個別実装の修正で対処できる指摘より、アーキテクチャレベルの指摘 (後から変更するコストが大きい判断への異議) を優先する。 - **現状把握の妥当性**: 現状把握は repo・構想の実態を反映しているか。コードを確認せず推測で書いた箇所は無いか。 - **スコープ** (PMBOK: スコープ): MVP からさらに外せる機能は無いか。受け入れ要件のうちどのマイルストーンにも対応しない項目は無いか。非ゴールへ移すべき機能は無いか。 - **リスク** (PMBOK: リスク): 1週間 spike は「頓挫の最大原因」を検証しているか。技術以外のリスク (依存ライブラリの保守停止、非公式 API の破壊的変更、プラットフォーム規約の変更) を列挙したか。spike が失敗した場合の代替案を書いたか。 - **アーキテクチャ**: 性能目標・受け入れ要件を現在のアーキテクチャで原理的に達成できるか。データモデル・プロセス境界・描画方式・ストレージ選定など、後から変更するコストが大きい判断を列挙し、それぞれが性能や拡張の上限を決めていないか検証したか。チューニングで対処できる領域と、アーキテクチャ変更でしか対処できない領域を区別したか。 - **パフォーマンス** (ISO/IEC 25010: 性能効率性): 性能目標が数値で定義されているか (起動時間、応答時間、メモリ、対象データの規模)。計測方法と比較対象 (競合の実測ベースライン、fixture) が決まっているか。性能の回帰を CI で検出する計画があるか。 - **品質特性** (ISO/IEC 25010): 信頼性・セキュリティ・保守性・移植性のうち、本プロジェクトで達成判定が必要な特性を選別し、それぞれに受け入れ条件があるか。テスト・CI の整備がマイルストーンに含まれているか。半年後の自分が再開できる設計・ドキュメントか。 - **ユーザー** (PMBOK: ステークホルダー): 想定ユーザーは作者以外に実在するか。競合から乗り換える理由を 1 文で説明できるか。1年後ゴールの利用状態へ到達する経路 (配布手段、告知) が計画に含まれているか。 - **依存選定** (PMBOK: 調達): 主要ライブラリ・外部サービスの選定根拠とライセンス互換を確認したか。メジャー更新へ追従するコストと差し替え可能性 (抽象レイヤの要否) を判断したか。 - **整合性** (PMBOK: 統合): conao3 の既存プロジェクトと重複しないか。既存の開発環境 (nix-flakes、リポジトリ規約) と整合するか。 ### 5. 書き戻しと報告 `projects/fable-review/{name}.md` を書き、`TARGETS.md` の対象項目を `DONE` へ書き換えて、同じ commit に含める (このリポジトリは能動 commit 可)。最後にユーザーへ「決めたこと上位 5 件」「未決事項とその解消方法」「1週間 spike の内容」「projects/ 側を編集・新規作成した場合はその要旨」を報告する。 ## `projects/fable-review/{name}.md` の構成 1. **メタ**: 対象構想ファイル、対象 repo (あれば)、レビュー実施日 2. **現状把握**: 構想の成熟度 / 実装の実態評価 3. **ゴール**: 1年後 / 1ヶ月後 / 1週間後 / 非ゴール 4. **設計判断**: 決定事項 (理由付き) と未決事項 (解消方法付き) 5. **リファクタリング方針**: 既存実装がある場合のみ 6. **発展のさせ方**: マイルストーンの一覧とそれぞれの完了条件 7. **着手指示**: 最初のマイルストーン (1週間 spike を含む) の具体的な作業手順。実施順、検証コマンド、完了条件を、コーディングエージェントが追加の質問なしで開始できる粒度で書く 8. **ユーザー判断**: ユーザーにしか決められない事項。各項目に選択肢・推奨案・決定後に更新すべき箇所を書き、次回のセッションで即決できる形にする。該当が無ければセクションごと省略する ## 書式 - 日本語で書く。プロジェクトメモ (`projects/ghq-github-com-conao3-idea.md`) の書式規約と `notes/wording.md` に従う。 - 現在の結論だけを書く。検討の経緯・没案の物語は書かない (tradeoff の根拠として 1〜2 行添えるのは可)。 - 文書単体で完結させる。対象 repo の URL とローカルパス、参照すべきファイル、ビルド・テストの実行方法を本文に明記し、「セッションで話した通り」のような文脈依存の記述をしない。

As a result of a US government directive, we are suspending access to Claude Fable 5 for all users. You can continue to use all other Claude models. Here’s what this means for you: Across Claude products, new sessions will run on your selected default model or Opus 4.8, and existing Fable 5 sessions will end with an error. On the Claude Platform, requests to Fable 5 will also return an error. Please update your integrations to other Claude models. We know this is a disruption to your workflows; we appreciate your patience and support.

As a result of a US government directive, we are suspending access to Claude Fable 5 for all users. You can continue to use all other Claude models. Here’s what this means for you: Across Claude products, new sessions will run on your selected default model or Opus 4.8, and existing Fable 5 sessions will end with an error. On the Claude Platform, requests to Fable 5 will also return an error. Please update your integrations to other Claude models. We know this is a disruption to your workflows; we appreciate your patience and support.

Claude君、Source of Truthのことを「正本」と言うのは許すけど、Documentsのことを突然「ドシエ」って言いだすのはやめて欲しい。俺達人間の言語文化が汚染される。